My Thoughts on EMC EHC – Part 2 – Pod Architecture.

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.

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.

Components of the EHC Core Pod

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.

Components of the EHC Automation Pod

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.

Components of the EHC NEI Pod.

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.

2 Comments

Just to clarify some points:
The vCAC/vRA Identity Server is not used in the EHC solution. The SSO service on the Cloud vCenter Server is used instead.

The EMC ViPR appliance is now located in the Automation Pod, not the Core Pod.

An external VMware vCO instance is required in the Automation Pod. The embedded vCO in the vCAC appliance is not currently supported in EHC v2.5.1.

EMC Data Protection Advisor and EMC Avamar (including the Proxy VMs) are not part of the Foundation EHC Solution and are an optional/modular Data Protection Backup add-on to the EHC solution if required.