In part 1 we saw the various components that make up the EHC Solution. In this blog, lets discuss how these components interact to make up the solution pod architecture.
The Pod Architecture:
Pods are a fancy name for a cluster (in EHC) which perform a very specific and distinguished function in EHC. There are 3 management pods which are created in EHC.
- EHC Core Pod
- EHC Automation Pod
- EHC NEI Pod
In addition to the above, there is usual “EHC Tenant Pod” which is exclusively used for the end users or to host multiple Business Groups or Tenants.
To make it simpler, lets think that there are going to be 3 management clusters and n number of resource clusters.
EHC Core Pod:
The components of the EHC Core Pod can be deployed in an existing environments. Although this is the only pod that can be deployed on existing hardware, all the other pods have to be deployed on a green fields environment. Not sure how the expansion aspect of this will play out but lets tackle that when we get to it.
The EHC Core Pod has the following components:
- External vCenter Server – Manages the EHC Core Pod (Can exist on an external environment depending on whether it’s an existing or greenfields deployment).
- Cloud vCenter Server – Manages everything else. Acts as the endpoint for vCAC/vRA to deploy end user machines.
- SQL Server 2012 – Hosts the respective SQL Server databases used by the External vCenter Server, Cloud vCenter Server, VMware Update Manager and VMware vCAC IaaS databases. .
- NSX Manager VM – Used to deploy and manage the Tenant Resource Pod and the management infrastructure virtual networks (see NSX Release notes, architecture for more info on this).
- EMC ViPR – Provides Automated Storage provisioning for the Cloud Infrastructure. Provides a single pane management for Storage provisioning across multiple hardware systems (XtremIO, VMAX and VNX).
- SMI-S VM – Provides the interface for ViPR to talk to the Physical Storage systems.
The core pod is deployed on storage that is not managed by ViPR. It can be deployed on existing EMC storage. If using the same storage as the cloud resources, EMC VSI client (on vSphere) can be used to deploy storage for this environment.
Though not mandatory, Fibre Channel connectivity between the EHC Core Pod and the EMC Enterprise Hybrid Cloud array is strongly recommended. All storage should be RAID protected and all ESXi servers should be configured with EMC PowerPath/VE for automatic path management and load balancing. This storage configuration applies to all the pods except the “tenant pods”which will have the storage provisioned by ViPR.
EHC Automation Pod:
EHC Automation Pod hosts all the VMs required for automating and managing the cloud infrastructure. This doesn’t manage or automate any of the components of the EHC Core pod. The EHC Automation Pod is managed and controlled by the Cloud vCenter Instance. Although this is the case, the automation pod hardware is disntinctly separate and will NOT be used by the vCAC/vRA endpoints. From a storage point of view, none of the components here are deployed on ViPR provisioned Storage.
The EHC Automation Pod has the following components:
- VMware vCAC/ vRA Appliance VM
- VMware vCAC/vRA Identity Server VM
- VMware vCAC/vRA IaaS Server Windows VM
- VMware vCOps/vROps Instance (2 VM vApp)
- VMware vCenter Log Insight VM
- VMware ITBM Suite VM
- EMC Powerpath/VE Server VM
- EMC Data Protection Advisor VM
- EMC Avamar Proxy Server 01 VM
- EMC Avamar Proxy Server 02 VM
Most of the components above are self explanatory. If further clarification is required, then please visit VMware/EMC Documentation for the appropriate products.
EHC NEI Pod:
EHC NEI (Network Edge Infrastructure) Pod is used to host all the Networking and Security components for the virtualised network. These are responsible for the North-South communications. If using NSX for virtualising network, it also hosts the NSX Controllers.
This environment becomes the point of convergence for physical and virtual networks. Dedicated vSphere clusters will be used to simplify the configuration. Dedicated environment eliminates contention among the networking resources.
This environment is also provisioned on non-ViPR provisioned storage. This environment is managed by the Cloud vCenter Instance. As with the Automation Pod, this is also hosted on separate hardware.
The following components are deployed in EHC NEI Pod:
- NSX Controllers ( if NSX is used)
- NSX Edge Appliances.
- vCNS Components.
EHC Tenant Pod:
This is exclusively used to deploy the end user machines. This environment will be completely automated and managed by
- vCAC – Compute and Automation
- ViPR – Storage Virtualisation and Performance Management
- NSX. – Network Virtualisation
That’s end of Part 2 folks..
In the next blog I will cover the architecture and integration in more detail.