Overview of VMware vCloud Availability 3.0 – Introduction, Roles, Deployment Process

In this series of blog posts, I will be discussing the new release of VMware vCloud Availability 3.0 (vCAv). This is a very exciting release for the VMware Cloud Provider team. vCAv 3.0 will be out shortly (by end of our fiscal quarter) and I want to provide my insight into this platform. I will be focusing on the following points –

  1. Introduction to vCAv 3.0
  2. High-Level Architecture
  3. vCAv 3.0 Service Roles
  4. Deployment Process
  5. Deployment Approach for Provider
  6. Deployment for Tenant (On-Premises)
  7. Protection Workflow
  8. Resources

Introduction to vCAv 3.0

First off, let’s discuss what vCAv provides from a functionality perspective. vCAv is what I like to call “functional convergence.” In the past, we had many different products that provided some level of availability or migration capability –

In my opinion, this was a duplication of appliances and could be confusing to customers. The team has done a great job of putting forth a significant investment into vCAv 3.0 to simplify the architecture. Therefore, here’s where we are today –

Therefore, no need for multiple tools for migration, DR from/to Cloud, or between Clouds. We now have a single solution that answers all of the above.

vCAv 3.0 Key Functionality

So what does vCAv 3.0 provide?

  1. Simple, Unified Architecture
    1. There is a single OVF for the Provider and the Tenant. On the Provider side, each role can be easily deployed used by the vSphere Client or CLI.
    2. Deployment is very intuitive and scalable – each role can be quickly deployed in a matter of minutes.
    3. On-Premises Appliance is unified and provides vCenter UI integration for management.
  2. On-Premises Migration and Protection
    1. On-Premises appliance provides the same UI experience as connected to the Cloud instance, but built into vCenter.
    2. Migration and/or protection of workloads can be done with a few clicks.
    3. Allows for protection/migration to and from vCloud instances.
  3. Cloud to Cloud Migration and Protection
    1. Very similar behavior to C2C 1.5, we can protect workloads (vApps and VM’s) between vCD instances.
  4. Network Mapping and Re-Addressing
    1. One of the new additions is the ability to re-address and map out protected workflows for faster recovery at the destination site.
    2. This maps to existing vCD oVDC Network constructs such as Static IP pools.
  5. Scale
    1. As discussed before, the team is aware of scalability requirements for Providers. For this version, here is the stated guidelines:
      1. 300 tenants with active protections paired to vCloud Director instance
      2. 20 vCAv Replicator instances per instance
      3. 500 active protections per vCAv Replicator instance
      4. 9,500 active protections across tenants to a Cloud
      5. 5TB protected VM size (contingent upon Cloud storage)

Business Value

Direct and native vCloud Director integration for providers and tenants – with the ability to provide self-service, this provides a unique experience that meets DRaaS requirements and migration functionality.


Ease of Operationalization – I’ve done several deployments during the development process and it’s one of the easiest VMware Cloud Provider solutions to deploy. Once we review the roles and concepts, anyone should be able to operationalize this with ease.

Cost-Effective Approach – vCAv 3.0 will be part of the VMware Cloud Provider Program (VCPP). This is based on the monthly consumption of points, which is a very cost-effective solution that can be modeled and productized for DRaaS and migration offerings.

High-Level Architecture

In the following diagram, we can see how this all comes together with a single, on-premises vCenter along with two vCD instances. One can pair this up with vCD multi-site federation capability.

Moreover, this pairs very well with existing vCD services such as CrossVDC Networking or L2VPN connectivity between on-premises and organization VDCs.

vCAv 3.0 Service Roles

Let’s review the distinct service roles of vCAv 3.0.

Provider

On the Provider side, we have the following –

  1. Cloud Replication Management
    1. This is a logical entity that consists of the core of vCAv 3.0.
    2. vCloud Availability Portal – User Interface for the tenant and provider. All UI configuration ingresses from this service and applies all to all necessary connected components.
    3. vCloud Availability vApp Replication Manager – communicates directly to vCD and understands tenancy constructs such as organizations, vApps, etc. Also responsible for enabling protections or migrations.
    4. vCloud Availability Replication Manager – understands vCenter and ESXi concepts and will interoperate between the replicators and protected vCenters.
  2. vCloud Availability Replicator – lightweight node responsible for executing on the host-based replication from a specific host. Typically, you deploy a replicator per vCenter.
  3. vCloud Availability Tunnel – this is the tunneling service that is responsible for providing secure connectivity between on-premises vCenter(s) and connected vCD instances.

Each of these roles can be deployed separately or in a combined virtual appliance. For production deployments (which we will review later), the recommendation is standalone deployments for each role.

Tenant / On-Premises

On the tenant side, we have a single appliance that has a combined appliance approach –

  1. vCloud Availability Replicator – just like on the Provider side, the Replicator is responsible for executing the host-based replication (HBR) process
  2. vCloud Availability Tunnel – provides secure connectivity between on-premises and vCloud environment. All traffic securely ingresses and egresses through this service.
  3. vCloud Availability Plugin – this plugin provides local vCenter UI management that is the same experience as connecting the vCAv Cloud environment.

Deployment Process

While this blog series will cover the Provider and On-Premises side in further detail, we will have the following steps to execute on for a successful deployment.

Provider:

  1. Deployment of Cloud Replication Management (CRM) Instance
  2. Deploy vCAv Replicator(s)
  3. Deploy vCAv Tunnel
  4. Configuration of CRM instance and start of site wizard
  5. Configuration of Replicator
  6. Configuration of Tunnel
  7. Validation

Tenant:

  1. Deploy vCAv On-Premises Appliance
  2. Start configuration wizard
  3. Connect to vCAv Cloud Tunnel
  4. Configuration of local placement
  5. Validation

Next up, I will review the Provider deployment process in further detail while providing the step-by-step procedures. Stay tuned!

-Daniel

How does VMware vCloud Availability for Cloud-to-Cloud 1.5 interoperate with vCD Cross-VDC Networking?

I get this question quite a bit due to the new vCloud Director 9.5 Cross-VDC networking functionality – does vCloud Availability for Cloud-to-Cloud 1.5 (C2C) work with stretched networking inside of Cross-VDC networking?

The answer is: yes!

This is another great addition for recoverability considerations as one could fail over between vCloud Director instances without modifying the guest OS IP address. Furthermore, based on the application architecture, one could have active-active applications and ensure replication/failover in the event of a disaster.

Let’s go through my example high-level design I’ve worked up in my lab –

Example Cross-VDC setup with vCloud Availability for Cloud-to-Cloud 1.5

In the above diagram, we can see I have two active vCloud Director instances, Site-A and Site-B. I have two organizations, “Daniel” that resides in Site-A along with “Daniel-B” that resides in Site-B.

C2C is deployed on each site in the combined model and I have multi-site pairing completed so I can easily manage this between my two sites –

Within my Cross-VDC networking setup, I currently have my active egress setup to Site-A as depicted in the diagram above.

Last of all, I ran a protected workflow from Site-A to Site-B for my Stretched-vApp-VM –

From there, one can either migrate or failover the workload and without any guest OS IP changes. I am going to do a video shortly, but here’s a short GIF I created that shows the ease of use of failing over between my Site-A and Site-B –

via GIPHY

After failover, I can then access Stretched-vApp-VM from the new NAT address on Site-B.

An Organization Administrator could also configure active/active or active/passive egress points for additional resiliency. This provides further capability inside of vCloud Director, especially with stretched networking and a complementary availability solution.

Thanks!

-Daniel

Managing access to the VMware vCloud Availability for Cloud-to-Cloud Plugin to vCloud Director 9.5

With C2C 1.5, a new plugin was introduced inside of the vCloud Director 9.x context switching menu. By default, all organizations and org admins receive this plugin once C2C is installed. Moreover, C2C will also upgrade any existing (older) plugins and register the new one insie of vCD (or if the plugin is missing for some reason, it will register and publish to all). 

What if we wanted to restrict/control access and mask this from specific tenants? Well, I plan on walking through how this is done using the new /cloudapi inside of 9.5.

Recently, I was in my lab environment researching the ability to control access to the Availability plugin. 

So, this led me to investigate further and discover the full capacity of the plugin management from the new vCloud Director 9.5 API (with the help of Jeff Moroski)

With vCD 9.5, we introduced the use of bearer tokens for authentication. Tomas Fojta did a great job of writing up a how-to guide on using bearer tokens inside of Postman while embedding the token after login.

First off, how did I control accessibility to the Availability plugin? Let’s walk through the API and discuss how one can control access to the plugin.

Steps

First off, POST to your vCD instance to grab the access token –

https://vcd-fqdn/api/sessions


From there, I’m ready to run a GET to see what extensions are registered to this vCD instance (remember, uncheck the Accept/XML header since this is JSON) –

https://vcd-fqdn/cloudapi/extensions/ui

We can see my plugin has a identifier associated of –

"id": "urn:vcloud:uiPlugin:c450bdf8-764f-4631-a319-1c849873c176",

So, let’s see which tenants have access to this now. Here’s my GET API string –

https://vcd-fdqn/cloudapi/extensions/ui/urn:vcloud:uiPlugin:c450bdf8-764f-4631-a319-1c849873c176/tenants

As shown above, I can see all of my tenants have access to the Availability plugin. If I needed to force publish to all (for any other type of plugin), Jeff stated that I needed to append “publishAll” to propagate to all tenants.

Let’s go ahead and remove access to the “Daniel” organization for C2C. Right now, I see this in my UI –

This requires a POST command with the JSON body that has the “Daniel” organization inside of it –

https://vcd-fqdn/cloudapi/extensions/ui/urn:vcloud:uiPlugin:c450bdf8-764f-4631-a319-1c849873c176/tenants/unpublish

[
	{
        "name": "Daniel",
        "id": "urn:vcloud:org:aa663210-b11f-4c14-8dca-1efab8dec429"
    }
]

I received a 200 OK message, so it looks like it worked, let’s go check.

A quick refresh, voila! Gone.

Again, this is a great way to verify and control the accessibility to the Availability plugin (or any vCD plugin) in vCloud Director 9.5. Cheers!

-Daniel

VMware vCloud Availability for Cloud to Cloud 1.5 is announced! What’s New?

I am excited to announce that vCloud Availability for Cloud to Cloud 1.5 (vCAv-C2C) will be released for VMware Cloud Providers at end of September. This has been a long and fruitful journey between strategic design partners and our internal teams.

In this post, I will review what’s new inside of vCloud Availability for Cloud to Cloud 1.5.

Don’t know what vCloud Availability for Cloud to Cloud is – don’t worry, check out this intro post!

To start, our lightboard video as an intro to C2C and what’s new with 1.5 –

A quick summary of what I’ll be discussing:

    1. Enterprise Scale
    2. Service Provider Policies for Offer Management
    3. Seamless and unified experience with integration to vCloud Director
    4. vRealize Orchestrator Integration (Compatible with C2C 1.0)
    5. vRealize Operations Day 2 Monitoring Pack (Compatible with C2C 1.0)
    6. Public API
    7. Enhanced Usage Reporting

Scale

Let’s talk about scalability for C2C for a moment. The BU has certified the following for C2C 1.5 –

  • 110 concurrent failover protections
  • Over 3,000 active protections across 100 tenants. This is a variable number as it will depend on the number of active tenants along with protected operations. However, in discussing this with Engineering, we’ve seen 4,000 VM’s protected by vCAv-C2C.
  • Scale up to 7 tested replication instances.

Again, this has been an important enhancement as we have received multiple requests regarding scale. I would also say this is the maximum configuration we’ve tested so far. This does not mean our technology is limited to these numbers. If there’s something specific you’d like to see, please talk to your VMware Cloud Provider field team.

Policies

With C2C 1.5, Cloud Service Providers (CSPs) can now manage access control for vCloud Availability – Cloud to Cloud DR on per tenant organization basis. By default, all tenant organizations are disabled and CSPs can choose to enable C2C DR service for one or many organizations. This allows CSPs to deliver Cloud to Cloud DR as a value-added service to their tenants.

As we can see from above, I have the Default Policy along with “Org1 Policy” that I created that I applied to my Org1 organization.

So, if an org that has not been whitelisted for Cloud to Cloud usage, what do they see? Well, they would get an error when attempting outgoing or incoming replications such as the below:

In addition to white-listing organizations, C2C DR also allows a CSP to create and assign new policies for select organization, thus giving them an opportunity for tiered offering and providing them better control on their capacity management. Following new policies have been added:

  1. Limit the maximum number of outgoing and/or incoming replications per organization
  2. Limited maximum number of replicated VM’s per organization
  3. Limited maximum number snapshots created by VM
  4. Allow to set lower limit on RPO per organization

Again, providing a granular application to specific orgs. We could create multiple policies and have different policies associated with each of them.

Last of all, we can see the compliance state on each org –

Integrated vCD UI

While using the vCloud Director portal extensibility capability, the team has now introduced an integrated C2C plugin for vCD!

Once C2C is deployed and registered to your vCD instance, we will see the Availability link in the context switching menu (or what we like to call the hamburger menu).

From there, the tenant user can navigate to C2C from the vCD interface, thus providing fully integrated and seamless experience and alleviating need of any console hopping.

vRealize Orchestrator Integration

While this is something that will be released post version 1.5, this is an awesome addition as now we can provide unique workflows on a per tenant/use-case basis in an automated fashion. Now, combine this with the power of the new vRO/vCD integration within the Content Library!

From vRO, we can see we have a new section vCloud Availability –

The first thing we would need to do is connect to each respective site –

From here, we have multiple options available that were built by our team, including IP address change after failover:

vRealize Operations Day 2 Monitoring Pack

We are now introducing a management pack for vRealize Operations. This will be also released post version 1.5, however, this will allow the Provider team to have a single monitoring and analytics tool for providing vCAv-C2C statistics and rollups of the environment.

There a few out of the box dashboards available –

From here, we can get a picture of what’s going on from an operational perspective, including any RPO violations set by vCAv policies. While my test environment is clean, this gives you an idea of what to expect.

As a last note – vRealize Orchestrator and vRealize Operations plug-in have their own release cycles and would typically lag a little bit behind the core Cloud to Cloud releases. The vRO and vROPs plug-ins for Cloud to Cloud are currently supported only for C2C 1.0 release). Please reach out to your VMware Cloud Provider field team if you’d like to discuss these further.

Public API

There is now an API available for C2C operations. Public API are generated through Swagger which is quickly becoming a de-facto standard for generating APIs. This allows for additional extensibility to Providers on managing C2C operations along with potential opportunity to integrate their Cloud to Cloud DR use-cases into their own Cloud management portal if this wish to do so.

Start off by going to the API documentation here

The steps to set up the Swagger client is fairly easy. I was able to do this in a Windows environment by using the PowerShell commands.

Start with downloading the JSON file –

Then, download the swagger-codegen client and run the generate command to generate the Java client –

And now the build is ready for .java files with the C2C parameters. I hope to have time to play around with this further.

Enhanced Usage Reporting

While Usage Meter integration is underway, we can pull reports from the C2C appliances by logging into the application console – documentation is here. 

We start by SSH’ing or opening the console to the C2C appliance. From there, we need to authenticate again in the h4 context so we can type in the ‘usage-report’ command –

Now, I am able to run ‘usage-report’ and find out my usage –

Again, a lot of great content and additions to C2C 1.5. Please check it out!

-Daniel