Continuation of VMware vCloud Availability for Cloud-to-Cloud DR – Pairing and Usability (1 of 2)

This post covers pairing and usability of VMware vCloud Availability for Cloud-to-Cloud DR.

Previous blog posts:

Blog Post – what is vCloud Availability for Cloud-to-Cloud DR? 

Blog Post – vCloud Availability for Cloud-to-Cloud DR – Installation and Setup

1. Part 2:
   1. Initial authentication between the two sites
   2. Migrating a workload in the same site
   3. Protecting a workload between two sites
   4. Testing the protected workload
   5. Edit Options
   6. Failing Over

Initial authentication between the two sites

1. This is pretty simple and very similar (if not exactly) like vCAv-DR2C. Go to Paired Clouds -> click the actions button to authenticate on the paired remote site. For me, this is SiteB. 
2. We need to provide the organization name, the username of the org admin, and password. Note this must be an organization admin for pairing. 
3. Complete! 
4. Now, I can do the same on my second site, SiteB. 

Migrating a workload in the same site

1. So let’s work through a use case where I want to migrate a vApp or VM between two different oVDCs in the SAME vCloud Director instance. This question came up on the vExpert Slack channel and I thought this was supported, but wanted to make 100% sure. The answer is yes – fully supported. So let’s go through how I made this happen.
2. From the DR Workloads tab, let’s click on the Discovery button – 
3. From here, our source is going to be our same site, which is SiteA/Org1, which should show host in parenthesis. 
4. Let’s select my test vApp, which is properly named “vApp_test” for this exercise. 
5. Now our destination is the same vCD instance, or SiteA/Org1. Let’s select it –
6. 
7. We can now see the other org VDC available, which is my Org1-Gold-oVDC. This is the only selection available as we cannot move it to the same oVDC and I do not have more than two oVDC’s inside of this organization. From here, we can also select the Storage Profile, Target PRO, and if we want to add in any Point-in-Time instances along with data connection type. 
8. Once we click finish, we get our setup screen… 
9. We can now see the vApp is being configured and in the “Protecting” status. 
10. Complete! All green and in the “Protected” state so it’s ready for migration over to my destination oVDC. 
11. Let’s go ahead and click Failover and get the confirmation window on what we want to do. I can select the DR Network (I didn’t set up networking for this test) and if I want to turn on the target VM. 
12. We can now see the status has changed to “Failing Over” – 
13. From my vCD instance, I can see the vApp being imported… 
14. Source/Original vApp is being powered off.. 
15. Under Tasks on the vCAv portal, I can see the migration tasks underway – 
16. Complete! We have successfully migrated over the vApp to the new orgVDC. We also see the original/source vApp was completely powered off, or in the Stopped state. 
17. In conclusion, very simple and intuitive to migrate between the same vCD instance. Theoretically, you could deploy this at a single site and use this for local migration.

Protecting a workload between two sites

1. So let’s cover migration between the two sites – SiteA and SiteB. In this exercise, we will be protecting a workload in SiteB and protecting it to SiteA. This is very similar to our exercise above (migrating between the same site) while we are selecting the paired site for protection.
2. Let’s go ahead and click on Discovery and select our source site (SiteB) – 
3. Now we can select our vApp that we will be protecting to SiteA – 
4. Select our destination, which mine is SiteA/Org1 – 
5. From our final screen, we can select the appropriate oVDC, storage profile, and my target RPO. For this exercise, I’ll be adding in some Point-in-Time instances too. Click OK and let’s get to protecting…
6. I tried to grab the transition log, but it was too fast. But I do see the initial replication succeeded along with my protected vApp showing “Protected” – awesome! 
7. I also like the event pop up we get when something changes. We can see this in the above screenshot that shows my newest protected vApp is good to go.

Testing the protected workload

1. Testing is the ability to bring up the protected workload at the destination site in an isolated network of your choosing – this allows the application owner to verify everything is operational and could be used for regulatory purposes too.
2. Testing is pretty easy – it can be orchestrated from either site (source or destination) and it’s with a click of a button –
3. 
4. We get the confirmation screen and the choice of our test network we want to utilize. Once I hit the Start button, I can see the status changes to “Failover Testing Initializing.” 
5. On my SiteA, I can see within the logs the failover testing is underway while we have a transition of a vApp inside of SiteA – 
6. Alright, now it shows Failover Test Ready which is great. Now, my app owner can test their app on the destination and verify functionality. 
7. One of the nice additions is the quick launch buttons on the test workload – we can hover over the two icons and see quick launch buttons to get to each site. Very nice addition. 
8. Finally, when our testing is done, we can click the Cleanup button to remove the test VM and go back to our normal, Protected state. Pretty straightforward. 

Edit Options on protected workload

1. Clicking the Edit button provides us with the ability to make changes to a current protected workload –
2. 
3. From the options pane, we can see the following – 
4. We get our standard RPO slider – from 5 minutes to 24 hour RPO selection – while providing the ability to keep point-in-time instances for further retention.
5. Moreover, all traffic is encrypted but we can also further optimize by compressing data. Very similar to vSphere Replication, the replicators will attempt to compress the data to minimize network traffic.
6. Last of all, we have the ability to quiesce the operating system by using VMware Tools.

Failing Over

1. In our last example, we will fail over my core-B vApp from SiteB to SiteA. Failover can be done from either site (especially important if I lost my source site) and very straightforward.
2. Let’s select Failover from the UI – 
3. As discussed before, our standard options and what network we want to select. 
4. We can see it transitioned to Failing Over… 
5. Voila! Failed over. Now we can click the quick launch shortcut and start doing whatever we need to do. 
6. Another thing to note – even with a failed over workload, we can reverse the replication and reprotect it back to our original site, assuming the site is still operational. This is done by selecting the Reverse button. Now, this will show as outgoing from my SiteA to SiteB.
7. 
8. 

That’s it, folks! My hope is this was informational for any providers that are considering to utilize Cloud to Cloud for migration and DR needs for their multi-site vCloud Director environments. It’s a great tool and is very intuitive for our tenants and providers.

Thanks!

-Daniel

As a continuation of my vCloud Availability for Cloud-to-Cloud DR (vCAv-C2C) series, we will be covering the initial pairing and usage of C2C in this blog post.

Blog Post – what is vCloud Availability for Cloud-to-Cloud DR? 

Blog Post – vCloud Availability for Cloud-to-Cloud DR – Installation and Setup

I will break this post into the following sections and into two blog posts:

1. Part 1:
   1. The pairing of the two vCD/vCAv sites
   2. Logging into the vCAv Portal and Portal Overview
   3. Provider view of the vCAv Portal
2. Part 2:
   1. Initial authentication between the two sites
   2. Migrating a workload in the same site
   3. Protecting a workload between two sites
   4. Testing the protected workload
   5. Edit Options
   6. Failing Over

The pairing of the two vCD/vCAv Sites

1. First, the Provider must set up an association between the two vCAv sites before the tenant can authenticate within the vCAv portal.
2. This is done in the Replication Manager portal – point your browser to https://<vcav-rep-mgr>:8046, authenticate, and click on Sites -> New site
3. We then assign a Site name, the full URL of the respective peer replication manager, and the appliance password. Within my setup, I did this on both sites, SiteA and SiteB. 
4. 
5. Once we hit OK, you will receive a Task succeeded message – 
6. Now, if we click on the Sites subsection, we can now see our local site along with our newly peered site. From SiteA and SiteB, I can see each respective site. 
7. Complete! Now we are ready to log into the vCAv Portal.

Logging into the vCAv Portal and Portal Overview

1. Point your browser to the fully qualified domain name along with port 8443 – this is the default port the portal runs (can be changed). 
2. Logging in is very similar to vCAv-DR2C – you utilize the username@org-name parameter. For my SiteA, I have an “Org1” while my SiteB is “Org2” – for SiteA, I am logging in as org1admin@org1 with the appropriate password.
3. Once authenticated, I get the very clean interface that shows the Cloud Topology. We haven’t started any replications/migrations yet, so I don’t have any ingress/egress traffic yet.  
4. On the home page, you get a very clear view of the topology, workload statistics, and even the Organization VDC status. I thought this was a very efficient use of current oVDC utilization along with what’s being used within each oVDC. 
5. Under the DR Workloads tab, we would be able to see incoming and outgoing protected workloads. Since we haven’t set up any yet, nothing to show yet. 
6. Paired Clouds shows available vCD/vCAv instances and their authentication status. Since the Provider paired with SiteB, we have it available but it shows unauthenticated. We still need to authenticate with the appropriate credentials that reside on SiteB. 
7. Last of all, Tasks will show any previous or current tasks and the event log. This will show logs for any connected site, so very easy to see exactly is going on between the paired sites. 
8. For those of you that have used vCAv-DR2C, this is very similar to that experience with a few minor enhancements. The learning curve is very minimal and we will go through a few test scenarios.

Provider view of the vCAv Portal

1. The development team did a great job from a provider view on providing very useful information.
2. First of all, we get to see a current status ticker that shows state of the vCAv environment. I thought this was extremely useful and intuitive to gain an operational understanding of the health of the current environment. 
3. I didn’t mention this in the previous portal post, but this is also available there too. You can expand and see the details of the current replications/migrations between sites. This is done by clicking the carrot icon in the top right corner. 
4. If you scroll down also, you get to see the pVDC view of the current environment with a resource utilization rollup. Very similar experience to what we see now in vCD 9.1 Multi-Site. 
5. Under the Orgs tab, we get to see the current organization and any registered vApps and current status. 
6. One very nice item is that shield/checkmark icon. If we click that, we can actually impersonate the organization admin and assist with any tasks that the organization may be having trouble with. All done through this single interface! 
7. I won’t cover DR Workloads as it’s the same as the tenant view, but just a macro-rollup of all protected workloads. However, under Administration, we get to see Configuration and Registration. From here, we can actually register other components to monitor from this dashboard along with resource threshold display. Very nice! 

Onto the next post, where we will review migrations and protection operations. Thanks!

-Daniel