Those who attended VMworld 2012 last week and witnessed the launch of the new vCloud Suite, may have heard about the changes and new technology features added to the products in the platform.

One of the features mentioned during the presentation “Architecting a Cloud Infrastructure”, which was delivered by @DuncanYB, @AidersD, @DaveHill99, and @ccolotti, and myself, is the high availability setting for the vShield Edge devices.

Prior to the release of the vCloud Suite, the recommendations used FT to protect the vShield Manager appliance in order to mitigate the single point of failure in the vCloud and security domain. The new release of vCloud Director 5.1 and vShield 5.1 provides capabilities to mitigate those risks, but only for the vShield Edge Gateway devices that are deployed within the cloud.

One of the many noticeable changes introduced with the new release of the vCloud Suite and the vShield Manager appliance is that the appliance is now deployed with 2 vCPUs. While the support of FT for workloads with multiple vCPUs is under technical review, FT is currently not supported with multiple vCPU workloads.

Because of the workload design change in the vShield appliance, the previous recommendation, which required using FT to protect the vShield Manager appliance, no longer applies. Because of this change, there has to be an immediate focus on the proper backup and maintenance procedures of this key component of the vCloud infrastructure. vShield backups configuration options are illustrated in the screen shot below.

vShield Backup Configuration Options

The new vShield Edge Gateway design leverages a new active/passive architecture for the deployment of vShield Edge Gateway devices within vCloud Director 5.1. This new design provides better scalability and flexibility for variably sized environments, and it reduces the risks of security service outages in vCloud environments. While leveraging the new vShield Edge Gateway HA capability addresses availability concerns, it is important to plan for the effects, which include an impact on capacity management, resource allocation, and overall infrastructure manageability. The screen shot below illustrates the wizard in vCloud Director with the option to deploy the vShield Edge Gateway device with HA mode.

vCloud Wizard: vShield Edge Gateway device HA Option

There are two different options for deploying vShield Edge Gateway devices within vCloud Director 5.1: Compact and Full.  While the use cases for these different options are outside the scope of this post, I do want to point out the effect this will have in terms of resource capacity consumption.

Each vShield Edge Gateway device is comprised of certain amounts of resource reservation, which should be considered when decisions are made to deploy vShield Edge Gateway devices in HA mode. A vShield Edge Gateway Compact instance is assigned a memory reservation of 128 MB, and a CPU reservation of 64 MHz. While a vShield Edge Gateway Full instance contains a memory reservation of  512 MB, and a CPU reservation of 128 MHz.

vShield Edge Gateway Devices Resource Reservation (Compact, and Full)

From a capacity perspective, vCloud architectures with large numbers of organizations and networks would be heavily impacted. Such architectures are impacted the most because the usable capacity of a provider virtual datacenter is reduced by the resource reservation of each vShield Edge Gateway device. As an unplanned consequence of using vShield Edge Gateway devices in HA mode, a large amount of resource capacity will be utilized to maintain the infrastructure, thus depleting the capacity for workloads in the cloud.

Keeping this consequence in mind, vCloud Provider vDCs and allocation models should be analyzed and adequately planned and designed for the support of vShield Edge Gateway in HA configurations. The resources allocated to all of the vShield Edge Gateway devices are assigned from the Providers vDCs, and they can be found in a Resource Pool construct named “System vDC” of each vCloud organization.

System vDC Resource Pool Construct

Capacity management is key for the success of every virtualized environment. It’s also crucial to understand the positive and negative effects of different configurations made to any environment. Because of the dynamic nature of resources allocation in vCloud, its important to understand how the utilization of some of the new features can affect the services provided to customers, as well as provider’s resource procurement and management cycles.

Indeed, vShield Edge Gateway HA mode improves availability, but at the cost of capacity. In virtualized and cloud infrastructure architectures, everything is relational – the more we consider the relationship between different cloud designs and configurations the better our solutions will be. Enjoy

 

 

Share →

5 Responses to Design Considerations for vShield Edge Gateway HA feature in vCloud 5.1

  1. [...] Director 5.1 released – what’s new (ESX Virtualization) Design Considerations for vShield Edge Gateway HA feature in vCloud 5.1 (Punching Clouds) Announcing VMware vCloud Director 5.1! (VMware vSphere [...]

  2. Ross Johnson says:

    Hi,
    we have a vSphere management cluster that contains the vCenter for management VMs and a vCenter also hosted on this management cluster that manages the vCD vSphere hosts (i.e. that vCenter is managed by vCD). The question is whether to place the vShield Manager (vCNS 5.1) on the management cluster or the vCD managed cluster?
    regards
    Ross

  3. Rawlinson says:

    Ross, I would recommend hosting the VCNS Appliance in the Management cluster where everything currently resides. Now the one point I want to make to you is that when you’re registering VCNS with the vCenter Server, you are to point VCNS to the vCD vCenter which is that one that manages the resources for vCD and not the vCenter for the management cluster. I hope that makes sense.

    thanks

    Rawlinson

  4. Ross Johnson says:

    Hi Rawlinson,
    thanks i understand which vCenter. There is a lack of design documentation for what i would think should be the standard practice of having a management and vCD cluster. While it appears obvious where management servers and appliances should reside, its good to back this up with some expert advice.
    thanks
    Ross

  5. Rik says:

    Hi ,

    First off it appears to me that HA is a step back versus FT in terms of convergence times in general – I suspect (hope) that VSE HA is not stateless ? Other then that – the original point made on “resource reservation” for failing primary devices (whether they run on X86 kernel or at a designated appliance like an external FW context) is not new – we (as in the traditional NW world ) have taken this onboard as design KPI’s for ages. Sure, we were not talking shares/dram/cpu pooled resources but rather “HA” at the appliance level – so leevling down to CAPEX (extra FW’s and licenses) and OPEX (power, cooling, mgmt resources) ..but at a 3000 miles view it’s more of the same. The point made is still good though, HA in general on functionality like VSE doesn’t come for “free” even when it runs on X86.

    regards

    Rik

Leave a Reply