vRealize Operation

Architect & Extend vRealize Operations for VMware Cloud on AWS

Consistency of Architecture and Operations between on-premises data & AWS public cloud is one of the most compelling reason for customers adopting VMware Cloud (VMC) on AWS for their Hybrid Cloud strategy. It not only provides the same  “Software Defined Datacentre”(SDDC) which customers are using for many years in their private cloud powered by vSphere, vSAN and NSX  as a platform in VMC but also give them a choice to extend the similar “Cloud Management” tools from vRealize portfolio like vRA and vROPS to perform the automation and day-2 operations. This is a huge advantage for organizations as they need not to change their operational procedures or re-skill people in this new hybrid cloud world.

Consistent Operations Across Private & Public Cloud

In this post I will discuss how organizations can use vROPS Self-Driving Operations as they embarked on their Hybrid Cloud journey with VMware Cloud (VMC) on AWS. Customer ability to have consistent & unified Day-2 operations across their on-premises and VMC on AWS Software-Defined Data Center (SDDC) can help them gain rapid time to value by using hybrid cloud management capabilities including cost optimisation, capacity utilization and future forecast needs of VMC on AWS on-demand service.

Existing vROPS customers who are already using it for Self-Driving Operations of their private cloud SDDC and are now considering it for VMC on AWS have following 2 choices.

  1. Extend their existing vROPS deployment from private Cloud to VMC on AWS SDDC over IPsec-VPN or DX (Direct Connect).
  2. Deploy a new dedicated cluster of vROPS in VMC on AWS SDDC.

In my opinion both approaches are appropriate based on the specific use case but require attention to some technical design consideration.

Let’s first discuss some of these important considerations like Capacity requirement, network architecture, ingress-egress traffic, and VMware licensing for both these options so that you can make an informed decision.

1.Capacity- I reckon this is first and most important consideration for an organization to decide their vROPS design and placement in Hybrid Cloud. If you already have fairly large on-prem. deployment of vROPS with a large Analytic Cluster (Master Node, Replica Node & Data Nodes) it would not make lot of sense to deploy a new analytic Cluster in VMC on AWS SDDC as well specifically when you just to monitor couple of hundred workloads. As even a small Master and Replica node (with HA) will cost you 4 vCPU and 16 GB of memory per node from your cloud SDDC capacity. Deploying a standard remote collector with 2 vCPU and 4 GB of memory and connecting it with your on-prem. vROPS cluster will be more economical and less time consuming in this case.

Based on your version of vROPS you can refer to the below KB article for sizing requiremnets.


Please note as a vROPS design best practice a Remote Collector (RC) should be deployed in case you want extend your exiting vROPS Cluster to VMC on AWS. As in this case AWS Availability Zone (AZ) will be like another datacenter connected over internet or DX to your on-premises environment.

2. vROPS Customization-I have worked with many large customers in the past and have also help them to highly customize their vROPS environment based on specific business requirements and operational procedures. If you are using Super Metrics, Custom Dashboards, Management packs, Custom Policies, Dynamic Groups, Custom Reports, custom alerts ,symptom definitions etc and have also done 3rd Party integrations with solutions like SNOW then you would like to carry on all this great work  for day-2 operation of your VMC on AWS workloads as well. Although most of these customizations can be exported & imported today (with recent vROPS releases) you should still keep that in mind for making a deployment choice. Probably a situation like this will also pivot towards just deploying a RC in VMC on AWS to leverage all the customization done in the past without much additional effort.

3. Network Connectivity & Egress traffic- There is another design consideration for deploying a RC in VMC on AWS. If you want to use the existing vROPS Analytic Cluster you need to do some additional network configuration both on the prem. datacenter as well as on VMC on AWS SDDC, so that RC can communicate with existing analytic cluster. This will involve configuring the gateways and setting up your firewall rules on both the sides.

Whereas if you are deploying an independent new vROPS cluster in your cloud SDDC the network preparation will be minimal (no changes required on-prem.). Moreover while there is no data ingress cost for AWS Availability zones but there is cost for any type of egress traffic from AWS to your private cloud. And as a Remote Collector will be sending metric data collected from VMs running in AWS SDDC to your on-prem. analytic cluster, it will be an additional cost to your network bill from AWS. Although I would say this will not be a significant traffic and depend upon the no of objects and metrics being collected and RC also does normalization on the data before sending it to the Analytic cluster, but it is still a important design consideration.

Also make sure that the network latency between the RC and analytic cluster is less than 200 ms in case of internet-based IPsec VPN links.

4. VMware Licensing– It also important to pay attention to vRealize Operations license compatibility and compliance while choosing between the above two design options.

This a detailed topic and I would advise you to consult with your VMware rep. before making any decisions based on your situation.

But on a high level vROPS license is available in following 3 editions.

  • Standard-vSphere only
  • Advance- Entire SDDC, VMware Cloud on AWS and VCPP based hybrid clouds
  • Enterprise- Entire SDDC, VMware Cloud on AWS, hybrid clouds and multi-cloud

As you can see apart from the feature different there are also restrictions where these licenses can be used. Hence first of all only Advance and Enterprise license can be used for VMC on AWS.

Then there are three different licensing models in which you may have purchased a vROPS license.

  • Portable licensing units (PLU): This is the licensing metric for vCloud Suite and vRealize Suite.
  • Per processor with unlimited VMs: This is the licensing metric for the standalone products: vRealize Operations Standard and Advanced editions
  • Per virtual machine or physical server (OSI): This is the licensing metric for the following standalone products: vRealize Operations Standard, Advanced and Enterprise

As PLU based license can also be interchangeably used for 15 OSI, depending on the edition (only advance & enterprise) both PLU and OSI based licenses can be used for virtual machines running in VMC on AWS SDDC. However, it will not make commercial sense to extend your vCloud Suite licenses to VMC on AWS as you are already paying the cost for your vSphere license in AWS SDDC as part of your VMC on AWS subscription.

In summary a standalone OSI based Advance or Enterprise edition license will be compatible and most cost efficient.

You can find more details above licensing and editions at below link.


5. vROPS for Native AWS Monitoring- Now this an interesting use case for which I have recently seen lot of interest from my customers are who are either already using lot of AWS native services or are looking forward for building hybrid applications using VMC on AWS and native AWS services like ELB, Dynamo DB etc. in their application transformation journey.

Such customer can use vROPS AWS Management Pack by Blue Medora to get visibility beyond cloud watch metrics in pre-configured dashboards and generates intelligent alerts based on operational best practices.

Currently following AWS services are supported by this management pack.

You can find more details about this management pack at following link.

AWS Management Pack Supported Services

In this situation deploying a new vROPS instance inside VMC on AWS SDDC will be a great choice to get visibility for VMware SDDC as well as native AWS services from a single console.

The biggest benefit of this solution is that you will get Sub-Millisecond latency via AWS Elastic Network Interfaces (ENI) and VPC Endpoints for monitoring native AWS services and there will be No Cost ingress/egress data transfers within AZ for monitoring these applications.

Monitoring Native AWS Services by vROPS

I hope the above arguments will help you in your decision making to justify your placement choice for vROPS in this new Hybrid world. In the next blog I will talk about the actual preparation and deployment details for both the design options.

Leave a Reply