One common misconception about Public Cloud is that things like backup and security are automatically taken care of for you. Most cloud providers operate under a shared responsibility model, meaning they provide only up to a certain level of responsibility for security, availability, data protection, etc. This means that cloud architects must plan for backup and security of the environments they build for the cloud.
VMware Cloud on AWS (VMC) is no exception to this. While it is true that the management components of VMC (vCenter, NSX, vSAN) are completely managed and backed up by VMware, the compute workloads running within VMC still require the same type of data protection that would be expected for on-premises workloads.
Veeam has always been tightly coupled with VMware, and as a software only data protection option it makes a lot of sense to look at Veeam for protecting VMC workloads. On the one hand, it is almost as easy to configure Veeam within VMC as it would be for an on-prem environment, but there are still some things about the VMC platform that require unique design considerations. The Veeam 3-2-1 rule states that you should have three copies of data using two types of media, and one copy of your data should be off-site. What if that production data is already off-site? One of the great features with VMC is direct access to AWS native. That gives VMC customers easy access to a cloud environment that inherently allows for building out as much of that 3-2-1 rule as you deem necessary. One noteworthy item is that the inability of VMC to utilize NFS storage does limit some of Veeam’s functionality (Instant Restore, Data Labs, etc).
Creating the Backup environment
The first step to running Veeam within VMC is deploying the Veeam Backup and Replication (B&R) server. Veeam B&R is easily accessible within the VMware Solution Exchange, or you can simply deploy a VM into VMC from a Windows template and install Veeam B&R manually. Once Veeam B&R is deployed, the fun comes in designing the rest of the backup infrastructure to meet your needs. At the most basic level, Veeam B&R can act as the backup server, backup proxy and repository server all in one. In the case of VMC, you would never want your backup data to reside on the exact same storage as your production workloads, so the easiest logical step is to spin up an EC2 instance with attached EBS storage in AWS native. For the purpose of a simple demo, I utilized a Linux instance in AWS and added the attached EBS volume as a repository to B&R. My demo architecture looked like this:
It makes sense to spin up a Veeam B&R VM within VMC because you are already paying for that compute. VMC hosts pack a lot of punch when it comes to compute, so definitely utilize that where you can. Also, there is networking and security to consider for communication between VMC and AWS native, which requires B&R to be as close to the vCenter it is protecting as possible.
The great thing about the direct link to AWS is the number of possibilities for how to protect your data. My demo utilized a repo in the same Availability Zone as my production data in VMC for the sake of a quick POC. To protect against and AZ failure, you could spin up a Veeam proxy into the same AZ as VMC to allow for communication into AWS, then have your repo in a different AZ that talks to the proxy via the native VPC. Further enhancing the 3-2-1 strategy is the use of Cloud Tier (shown above but not implemented for the demo). AWS could allow for a fleet of repositories across AZs configured as a Scale Out Backup Repository (SOBR), with the ability for tiering to S3. Cloud Tier enhancements coming in v10 will only further strengthen this story.
Networking and Security in the Cloud
From a firewall perspective, VMC needs to allow the traffic for B&R to communicate with vCenter. Since VMC has a separate NSX-T gateway for both management and compute, none of the compute workloads can talk with the management components out of the gate. That means allowing Veeam B&R and vCenter to communicate via firewall rules. For the Compute Gateway, I allowed the B&R server full access to VMC management:
Within the Management Gateway, I had to allow Veeam access to vCenter over port 443 and ESXi over port 902:
At the same time, I needed to take the networking between VMC and AWS native into consideration as well. From within my connected AWS VPC, I made sure that I had a route to both my VMC management network and the compute network segment where Veeam B&R was running:
This also meant allowing all traffic (both inbound and outbound) between VMC and AWS native within the Compute firewall, so that Veeam B&R could communicate with the EC2 repo in AWS native:
Putting Veeam to the test
With the environment seemingly ready to go, I built out a simple demo consisting of one Linux VM and one Windows VM within VMC. I then connected Veeam B&R to the VMC vCenter and was able to view the demo VMs within my Compute-ResourcePool:
I logged into my LinuxTest01 VM and created a real quick file called VMC-Linux that contained the text “this Linux VM is running in VMC and is backed up by Veeam.” I then added the EC2 instance as a new Linux Repository…
…and created a simple backup job containing both my WindowsTest01 and LinuxTest01 VMs to save to the EC2 repository. Once I ensured the backup job completed successfully, it was time for some destruction!
After logging into my VMC vSphere client, I found LinuxTest01 and deleted it from disk. Once I was sure that it was gone for good, I went through the process of performing a full VM restore:
As the restore was running, I was able to see vCenter going through the motions within the Recent Tasks window:
The restore completed successfully, and I was able to log back in to the recovered LinuxTest01 VM and see that my original text file was still there, as expected:
This was a fairly simple demo, but once again goes to prove the point that when it comes to the bread and butter stuff, Veeam “just works.” The great thing about Veeam being software based is the flexibility to work for many different scenarios. VMC fits very well as one of those scenarios, but has it’s own intricacies that require a little bit more configuration than your typical vSphere environment. Hopefully this demo can help VMC customers through those wrinkles and on to protecting their production workloads running in the VMware Cloud.