What’s New with VMware vCloud Availability 3.5?

Our team has officially released VMware vCloud Availability 3.5 this week. This is a jam-packed release that has quite a bit of value based on Cloud Provider feedback and customer consumption.

Download Page

Release Notes

In this post, I’m going to highlight the new technical additions that are now part of the VMware vCloud Availability 3.5. VMware vCloud Availability 3.5, or vCAv, is a comprehensive Disaster Recovery as a Service and Migration platform.

New to vCAv? Check out this introductory post.

Summary:

1. Bandwidth UI Visibility
2. Automatic vCAv Metering by Usage Meter
3. Regional Data Center Support and Flexible Network Connectivity
4. Enhanced Grouping and Protection Workflows
5. Operational Enhancements

Let’s jump into the technical details.

Bandwidth UI Visibility

First, VMware is now providing several enhancements to the VMware Cloud Director (VCD) vCAv plugin and the vSphere vCAv plugin.

Within the Provider User Interface (UI), we can see traffic utilization on a per organization basis, but also on a per-VM/vApp basis.

Moreover, these traffic statistics can be exported out to a tab-delimited file (TSV) for ease of consumption.

Within the on-premises vSphere plugin, we can see similar data available on a per-org or workload basis.

Automatic vCAv Metering by Usage Meter

Next, I wrote a post about this recently discussing this new capability. This is delivered via a hot patch (in-place upgrade) for vCloud Usage Meter 3.6.1. We will utilize this method for monitoring vCAv consumption data on a monthly basis.

Once your Usage Meter instance has the hot patch installed, one can add vCloud Availability 3.5 (or 3.x) instances to Usage Meter –

From there, any protected workload during the calendar month will count towards the Monthly Usage Units. It will be depicted in the Monthly Usage Report –

Last of all, Usage Meter will record any faulted collections too. Note that any certificate installs require a re-authentication from Usage Meter 🙂

Regional Data Center Support and Flexible Network Connectivity

Regional Data Center Support

One of the main requests was the ability to optimally route vCAv traffic. This is extremely important for multiple regional data centers inside of a single VCD instance. Let’s start off with a diagram that lays out this scenario.

Before

Previously, we could only deploy a single vCAv instance per VCD platform. In the diagram below, we have multiple Texas-based data centers where workloads and organizations reside.

If we had an on-premises customer that wanted to protect workloads to Austin, this would have to traverse to El Paso first (since the vCAv stack resides there), then route to Austin. Not an efficient use of resources. Moreover, this did not work when crossing multiple SSO domains.

With vCAv 3.5

With 3.5, the logic and foundation has been changed to allow for multiple vCAv deployments per VCD instance. Moreover, we can optimally route traffic directly to Austin once control traffic traverses the VCD instance. Therefore, we now have a design like the following –

Moreover, this allows for support multiple SSO domains.

The team went a step further and allow distinct control at the Provider VDC (pVDC) layer for vCAv. We can map each vCAv stack to each respective pVDC, or regional data center. This is done in Provider UI, under Configuration -> Accessible Provider VDCs. By default, a vCAv can access all Provider VDC’s, so be aware of this.

This is an excellent addition that supports various VCD models. However, this pairs well with the next addition I’m going to discuss, which is flexible network connectivity for Cloud Providers.

Flexible Network Connectivity

Next, let’s discuss this new enhancement for flexible northbound connections for Cloud Providers. It is very evident that Cloud Provider want to control replication (protection) traffic and consume across multiple northbound links – Wide Area Networks (WAN), Virtual Private Network (VPN), Direct Connection, and so forth.

With vCAv 3.5, the platform introduces flexibility to allow for multiple endpoint inbound connections. Let’s review the diagram below –

As depicted above, we can see we have our traditional WAN connectivity that terminates to the Tunnel via a DNAT rule for inbound connections. Nothing different there.

However, we now can to route other types of northbound traffic. In the example above, we have a dedicated VPN connection. The traffic routes to the vCAv Tunnel which then terminates on the Cloud Replication Manager (CRM) instance.

Previously, this was not allowed. All traffic had to route through the external endpoint URL, which typically sat on the WAN.

The result is further flexibility for Cloud Providers that allows for optimal routing of vCAv traffic.

Enhanced Grouping and Protection Workflows

Next, let’s discuss some new additions for logical grouping and some of the new functions within the protection workflow.

First, we can group on-premises VM’s into a single vApp. This allows for boot priority on recovery as shown below –

During the protection workflow, one can select Advanced Settings and select specific VMDK’s they want to protect or exclude –

vApp Network Properties

With vCAv 3.5, we are now able to replicate some vApp network characteristics within the vApp. The following list is what is available for protection:

• Network Type (Isolated/Routed/Direct)
• Gateway/DNS
• Connection Type
• Edge Firewall and NAT
• DHCP
• Static Pools
• Guest OS Customization
• OVF properties

Based on my testing, I was able to recover a vApp with the specific vApp networks and vApp Edge Firewall rules –

I am looking forward to further advanced functionality here, especially logical grouping and VCD network constructs.

Operational Enhancements

There’s been a multitude of operational enhancements that I’m going to highlight. These are pertinent to VMware Cloud Providers and tenants as they do add value to overall lifecycle management of vCAv.

Wizard Driven Installation Process

While this was introduced in one of our 3.0.x releases, I thought it was necessary to call this out again. There is a wizard-driven template for the Provider deployment on vCAv.

Once you authenticate into the Cloud Replication Manager (CRM) UI, a wizard is present for deployment. Each of these steps aids on establishing a vCAv instance for production. Once complete, each of these items are checked off and shown within the dedicated page –

You can always access this page at any time by going to the following URL:

https://fdqdn/ui/guide/checklist/dedicated

This provides a very intuitive deployment experience, especially for providers that are deploying vCAv for the first time.

Plugin Visibility

We’ve changed the default behavior of vCAv plugin visibility within VCD. If an organization does not have a vCAv policy set, they will not see the plugin within their VCD context switching menu.

In my below example, organization ETF is assigned to my default “No Access Policy” which prohibits outgoing and incoming replications.

We can see within the ETF organization, the vCAv plugin does not exist.

Therefore, vCAv will take care of any presentation of the plugin on a per-organization basis. You can always view the current state under the Plugin Manager for VCD –

UI Additions

vSphere Plugin

The vSphere UI plugin has been enhanced that shows our certified DRaaS VMware Cloud Providers along with distinct subtabs at the top –

You can also register additional on-premises appliances to allow for multiple Cloud Provider connections from a single vCenter instance –

SSH Accessibility

All appliances can control SSH access from the UI. For the CRM instance, we can also restrict Administrator API access by source IP.

Logging Levels

Within the UI, we can also control what’s logged and the established defaults. This is under the Configuration page for all appliances.

Certificate Management

This has been improved – ability to import a well-signed/CA certificate for the CRM instance to allow for proper trust.

Maintenance Operations

We’ve introduced a few new operation related activities within vCAv 3.5.

​Datastore Evacuation

To start, let’s discuss datastore operations. We can now migrate protected instances to another storage policy (datastore) for operational maintenance activities. This allows our tenants to continue to meet their specified recovery point objectives (RPOs) while not disrupting any existing protected workload.

For a provider to execute a datastore evacuation, select Datastores on the left panel. From there, it’s easy as hitting the Execute button and selecting your destination Storage Policy.

Replicator Maintenance Mode

vCAv can put a replicator in maintenance mode during any operational activities. Again, this minimizes any potential tenant/organization disruption. The Cloud Provider executes on these operations within the Replication Manager UI from the CRM instance.

To execute on a replicator maintenance mode operation, select the specified replicator and click “Enter Maintenance Mode” from the UI –

We can see the task running –

Upon completion, we can see my replicator in maintenance mode while all traffic is now residing on my remaining replicator instance for this specific site –

Once your maintenance operation has been completed, we can then exit Maintenance Mode.

Rebalancing of Replications

Using the Replication Manager UI, we have the option to rebalance protected workloads between replicator instances. This is as simple as selecting the replicators and executing on a Rebalance operation.

Previously, we had 3 running on my first Site-A replicator. After the rebalancing operation, 1 instance was moved to the second replicator.

Extensibility

Within the Provider UI, there is now a Swagger UI available. This is an intuitive way of learning how to utilize the extensible capability of vCAv. Moreover, this provides a view into what’s publicly available for the vCAv API.

I am looking forward to more capabilities within the vCAv API.

Summary

This was a significant addition to an intuitive, self-service DRaaS/Migration platform for our VMware Cloud Providers. I look forward to working with many of you on getting vCloud Availability 3.5 in your environments.

-Daniel