I recently had the opportunity to run through a VMware Cloud on Disaster Recovery deployment with a customer and thought I’d run through the basics. It’s important to note that there a variety of topologies supported with VCDR, and many things that need to be considered before you click deploy, and this is just one way of doing it. In any case, there’s a new document outlining the process on the articles page.
In this edition of Things My Customers Have Asked Me (TMCHAM), I’m going to delve into some questions around managing VMs running on the VMware-managed VMware Cloud on AWS platform, and talk about vCenter plugins and what that looks like when you move across to VMware Cloud on AWS.
How Can I Access vCenter?
VMware vCenter has been around since Hector was a pup, and the good news is that it can be used to manage your VMware Cloud on AWS environment. It’s accessible via a few different methods, including PowerCLI. If you want to access the HTML5 UI via the cloud console, you’ll need to ensure there’s a firewall rule in place to allow access via your Management gateway – the official documentation is here. If the rule has already been created and you just need to add your IP to the mix, here’s the process.
The first step is to find out your public IP address. I use WhatIsMyIP.com to do this.
In your console, go to Networking & Security -> Inventory -> Groups.
Under Groups, make sure you select Management Groups.
You’ll find a Group that was created that stores the IP information of folks wanting to access vCenter. In this example, we’ve called it “SET Home IP Addresses”.
Click on the vertical ellipsis and click Edit.
Click on the IPs section.
You’ll then see a spot where you can enter your IP address. You can do a single address or enter a range, as shown below.
Click Apply and then click Save to save the rule. Now you should be able to open vCenter.
Can I run RVTools and other scripts on my VMC environment?
Yes, you can run RVTools against your environment. In terms of privilege levels with VMware Cloud on AWS, you get CloudAdmin. The level of access is outlined here. It’s important to understand these privilege levels, because some things will and won’t work as a result of these.
Can I lockdown my VMs using PowerShell?
You will have the ability to set these advanced settings on your VMs in the SDDC, but this is limited to per-VM, rather than on a per-cluster basis. So if you normally ran a script on a pre-VM basis to harden the VM config, you’d need to run that on each VM individually, rather than on a per-cluster level.
What about vCenter plugins?
We don’t have a concept of vCenter plugins in VMware Cloud on AWS, so there are different ways to get the information you’d normally need. vROps, for example, has the ability to look at VMware Cloud on AWS, using either the on-premises version or the cloud version. There’s information on that here, but note that the plugin isn’t supported with VMC vCenter.
What about my Site Recovery Manager plugin? The mechanism for managing this will change depending on whether you’re using SRaaS or VCDR to protect your workloads. There’s some good info on SRaaS here, and some decent VCDR information here. Again, there is no plugin available, but the element managers are available via the cloud console.
What about NSX-V? VMware Cloud on AWS is all NSX-T, and you can access the NSX Manager via the cloud console.
Conclusion
A big part of the reason people like VMware Cloud on AWS is that the management experience doesn’t differ significantly from what you get VMware Cloud Foundation of VMware Validated Designs on-premises. That said, there are a few things that do change when you move to VMware Cloud on AWS. Things like plugins don’t exist, but you can still run many of the scripts you know and love against the platform. Remember, though, it is a fully managed service, so some of the stuff you used to run against your on-premises environment is no longer necessary.
In this episode of “Things My Customers Have Asked Me” (or TMCHAM for short), I’m going to dive into a few questions around VMware Cloud Disaster Recovery (VCDR), a service we offer as an add-on to VMware Cloud on AWS. If you’re unfamiliar with VCDR, you can read a bit more about it here.
VCDR Roles and Permissions
Can RBAC roles be customised? Not really, as these are cascaded down from the Cloud Services hub. As I understand it, I don’t believe you have granular control over it, just the pre-defined, default roles as outlined here, so you need to be careful about what you hand out to folks in your organisation. To see what Service Roles have been assigned to your account, in the VMware Cloud Services, go to My Account, and then click on My Roles. Under Service Roles, you’ll see a list of services, such as VCDR, Skyline, and so on. You can then check what roles have been assigned.
VCDR Protection Groups
VCDR Protection Groups are the way that we logically group together workloads to be protected with the same RPO, schedule, and retention. There are two types of protection group: standard-frequency and high-frequency. Standard-frequency snapshots can be run as often as every 4 hours, while high-frequency snapshots can go as often as every 30 minutes. You can read more on protection groups here. It’s important to note that there are some caveats to be aware of with high-frequency snapshots. These are outlined here.
30-minute RPOs were introduced in late 2021, but there are some caveats that you need to be aware of. Some of these are straightforward, such as the minimum software levels for on-premises protection. But you also need to be mindful that VMs with existing vSphere snapshots will not be included, and, more importantly, high-frequency snapshots can’t be quiesced.
Can you have a VM instance in both a standard- and high-frequency snapshot protection group? Would this allow us to get the best of both worlds – e.g. RPO could be as low as 30 minutes, but with a guaranteed snapshot of 4 hours? Once you do a high-frequency snap on a VM, it keeps using that mechanism thereafter, even if it sits in a protection group using standard protection. Note also that you set a schedule for a protection group, so you can have snapshots running ever 30 mins and kept for a particular period of time (customer selects this). You could also run snapshots at 4 hours and keep those for a period of time too. While you can technically have a VM in multiple groups, what you’re better off doing is configuring a variety of schedules for your protection groups to meet those different RPOs.
Quiesced Snapshots
What happens to a VM during a quiesced state – would we experience micro service outages? The best answer I can give is “it depends”. The process for the standard, quiesced snapshot is similar to the one described here. The VM will be stunned by the process, so depending on what kind of activity is happening on the VM, there may be a micro outage to the service.
Other Considerations
The documentation talks about not changing anything when a scheduled snapshot is being run – how do we manage configuration of the SDDC if jobs are running 24/7? Seems odd that nothing can be changed when a scheduled snapshot is being run? This refers more to the VM that is being snapped. i.e. Don’t change configs or make changes to the environment, as that would impact this VM. It’s not a blanket rule for the whole environment.
Like most things, success with VCDR relies heavily on understanding the outcomes your organisation wants to achieve, and then working backwards from there. It’s also important to understand that this is a great way to do DR, but not necessarily a great way to do standard backup and recovery activities. Hopefully this article helps clarify some of the questions folks have around VCDR, and if it doesn’t, please don’t hesitate to get in contact.