Update June 21st 2021 – Including VMware Cloud on Dell EMC
vRealize Automation Cloud and vRealize Automation 8.4 (v3 as well) are now tested and certified to work with VMware’s hosted cloud solutions on Microsoft Azure, Google Cloud Platform, Oracle Cloud and Dell EMC, called Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Solution (OCVS) and VMware Cloud on Dell EMC respectively, and of course don’t forget that VMware Cloud on AWS (VMC on AWS) has been supported for quite some time.
This means that VMware native workloads, the same kind you have in your private vSphere Cloud can be running seamlessly on Azure VMware Solution, Google Cloud VMware Engine, VMware Cloud on AWS , Oracle Cloud VMware Solution and VMware Cloud on Dell EMC then managed by vRealize Automation after setting up the appropriate vCenter and NSX-T cloud accounts.
This capability delivers value and opens up multiple use cases for your future datacenter expansion from private clouds to multiple public clouds, disaster recovery, business continuity, modern application development projects and integration to Public Cloud Native Services.
Well, that seems very straight forward and in fact, it is. However there are a few things to keep in mind and minor differences to be aware of that I will share in the following lines. So let’s take a look at the integration and vRealize Automation configuration and let’s explore also how you could leverage native Public Cloud Resources in this kind of set ups.
For the most part, the integration to vRealize Automation is pretty much the same as adding any vSphere endpoint or an on-prem NSX-T instance (if you are using vRealize Automation Cloud you also will need to deploy a Cloud Proxy).
There is an exception (a positive one), in the case of VMware Cloud on AWS, you only need to provide the VMware Cloud on AWS API token, then vRealize Automation will pull the associated vSphere endpoint and NSX-T instance available at your VMware Cloud on AWS‘s SDDC. All you need to do is to provide the password for your vCenter and/or change your default vCenter username.
You also need to keep in mind that each Public Cloud provider will supply you with your own private cloud that contains VMware vSphere clusters, vCenter Server, vSAN and NSX-T, that are built on their dedicated bare-metal public cloud infrastructure.
Simply put, there may be different VMware SDDC releases supported depending on the Cloud Provider. In fact, at the time of publishing this blog, the latest versions available were the following:
- CGVE: VMware vSphere version 7.0 | NSX-T version 3.0
- AVS: VMware vSphere version 6.7U3I | NSX-T version 2.5.2
- OCVE: VMware vSphere version 7.0 U1 | NSX-T version 3.0.2.0
- VMC: VMware vSphere version 7.0.2 | NSX-T version 3.0.3
- VMC on Dell: VMware vSphere version 7.0
This has implications on the way you integrate vRealize Automation. For Example whenever you add an NSX-T endpoint above version 3.0, you have the option to select the NSX-Mode : Policy or Manager, Policy is the newer API definition that also enables newer vRealize Automation capabilities. such as being able to create NSX-T security groups.
Please note that NSX is not exposed as an endpoint in VMware Cloud on Dell EMC. Therefore, vRealize Automation cannot interact directly with the NSX Manager in the VMware Cloud on Dell EMC environment and only vSphere networks are available. Additionally, the DNS configuration mode in your VMware Cloud on Dell EMC’s SDDC must be set up properly for resolving your FQDN vCenter public or private IP, depending on your environment needs.
There are also different levels of access and roles implemented by the Public Cloud Provider for the VMware SDDC solution, especially around of specific lower level functionality. For example, Azure VMware Solution implements a CloudAdmin role similar to VMware Cloud on AWS but there are differences, Azure VMware Solution uses “No Access” to Management VMs/Resource Pools in the Host and Clusters and Folders view in vSphere client. As a result, the Management VMs are not visible to the CloudAdmin role.
From this point, creating and configuring vRealize Automation components (i.e., Cloud Zones, Networks / Storage Profiles, Flavors / Images Mappings, Projects, etc.) is the same experience across the different platforms.
Ok, what if we deployed the same workload on all the Public Clouds (Azure VMware Solution, Google Cloud VMware Engine, VMware Cloud on AWS and Oracle Cloud VMware Solution) and Private Cloud (my on-prem vSphere) and see how it plays out ?
For this purpose, let’s deploy a single Cloud Template that provisions a new NSX NAT Network , several Disk Volumes, and a Sphere VM (having attached those Disk Volumes by explicitly indicating the associated SCSI Controller and Unit Numbers), in other words, this little guy here :
I also want to emphasize that I am using the very same Cloud Template, one single artifact that would be deployed by vRealize Automation on Azure VMware Solution, Google Cloud VMware Engine, VMware Cloud on AWS and Oracle Cloud VMware Solution Public Clouds and Private Cloud (my On-Prem vSphere)
Additionally, when deployed by vRealize Automation, the same user experience is present, regardless of the “Hyperscaler” Cloud Provider selected,
Day 2 operations, even my custom ones, become available for all the resources, Extensibility actions are executed seamlessly for all the environments, Custom Properties and naming convention as per Project are honored. Same tagging and matching Governance Policies are enforced. Note that the expiration day is same for all the deployments regardless of the Cloud Provider by simply applying a vRealize Automation Organization policy around Cloud.vSphere.Machine. I could also define more specific policies, based on the “Hyperscaler” Cloud Provider or other criteria.
As you can see, there really is no difference when it comes to the user experience, allowing you to scale or off-load your Private Cloud Workloads into the Public Cloud provider(s) of your preference without having to experience changes in your vRealize Automation implementation.
How about Cloud Public Native Services? Let’s try it. For this I created another Cloud Template, (see below) that will deploy an Azure Resource Group, Azure SQL Server and Azure SQL Database then a FrontEnd vSphere VM at Azure VMware Solution that would consume the Azure SQL Database (and take advantage of their scalability, security, resilience, etc.)
Something similar could be done with VMware Cloud on AWS and RDS, as another example, also, I am not going into the specific details of setting up the appropriate networking connectivity, as per your vendor. In my example, I am using Azure VMware Solution Backbone Network to provide the IP connectivity via VNETs for Azure VMware Solution and Azure Native Services.
Finally I want to point out that the vRealize Automation Project hosting this Cloud Template has access to the Azure VMware Solution Cloud Zone as well as native Azure Cloud Zone where native Azure resource could be created.
When deployed, you can see how a single Cloud Template could be used to deploy a complex workload combining VMware Solution in Public Cloud with Native Cloud Services, all with the Governance and curated Self-Service Catalogs, etc.
From the vSphere VM, I can connect to my Azure MS SQL and insert, update and query data from our newly created Azure Native SQL DB.
sqlcmd -S tcp:moff-sql-server.database.windows.net,1433 -d acctest-db-d -U myadministrator -N -l 30
I ran the following T-SQL statements to update the DriverID and OriginCity columns
1> UPDATE Drivers SET OriginCity='Boston' WHERE DriverID=123;
2> GO (1 rows affected)
We can verify the update with a simple query 1> SELECT DriverID, OriginCity FROM Drivers;
2> GO
DriverID OriginCity
123 Boston
You could take it one step further by passing the Azure MS SQL output into the vSphere VM and turn it into a FrontEnd WebServer via Cloud-Init or vRealize SaltStack Configuration
By the way, you may notice a Terraform Construct in there, I wanted to secure the MS SQL Database access and limit access only to the IP allocated at the FrontEnd vSphere VM, and I could have done this using an ABX Extensibility Action (my personal favorite) but the Terraform Azure Firewall Rule already existed and It will also remove the rule at Deployment delete, so I used this instead.
Conclusion:
Having vRealize Automation Cloud and vRealize Automation 8.4 (v3 as well) certified to work with Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Solution (OCVS), VMware Cloud on AWS (VMC on AWS) and VMware Cloud on Dell EMC simplifies and enhances your journey to Hybrid Cloud.
Related Links:
Announcing vRealize Automation 8.4
Announcing What’s New in vRealize 8.4
VMware vRealize Cloud Management tested and certified with Azure VMware Solution.
Google Cloud VMware Engine and vRealize Cloud Management.
Azure VMware Solution documentation.
