“VMware vRealize® Operations™ delivers intelligent operations management across physical, virtual, and cloud infrastructure—from VMware vSphere® and Hyper-V to Amazon Web Services. It correlates data from applications to storage in a unified, easy-to-use management tool that provides control over performance, capacity, and configuration, with predictive analytics driving proactive action, and policy-based automation.” – VMware / vROPs Datasheet
vROPs can collect metrics from a multitude of applications, services, and firmware in the enterprise. It’s a modular service, open to a wide ecosystem of partners and vendors providing adapters / management packs that feed open and/or proprietary metrics. As the VMware datasheet eludes, vROPs is able to analyze data from much more than just VMware components.
Fundamentally, vROPs collects metric values from IT services components (referred to as objects), stores the information, performs analytics, evaluates based on policy to determine if action is required, and provides a historical repository for analysis and reporting, based on long-term trends.
Among the benefits vROPs provides:
- Understand if capacity is being over or under-utilized ((CAPEX, OPEX, CSAT)
- Accurately plan budget requirements and reduce CAPEX/OPEX by avoiding under-provisioned infrastructure (Agility, CAPEX, OPEX)
- Model outcomes based on what-if requirement inputs and/or projection based on historical growth (CAPEX, OPEX, CSAT)
- Quickly and accurately identify anomalies or stressed resources, and the cause (SLA, CSAT, OPEX)
- Automate load balancing based on historical patterns (CSAT, OPEX)
In this first vROPs post, I’m covering the basic components and how they interact to build a foundation for understanding more advanced facets. Let’s begin with the high-level functions of the vROPs service outlined above.
vROPs 6.x is designed as a distributed in-memory database with clustered memory for computational work. A master node maintains persistent data in traditional disk-bound databases. Due to its distributed memory model, traditional backup and restore procedures may prove challenging.
When you first install vROPs, you create the first node. This node is the master node that maintains persistent data and provides specific management functions. To scale out, you simply install another node and relate it to the master. These additional nodes are referred to as data nodes. They form an analytic cluster with the others and balance the work of collecting and analyzing data.
You can elect one of the data nodes to be a replica of the master. This provides fault tolerance. Due to the clustered compute architecture of master and data nodes, they must be placed on the same L2 segment. To analyze metrics from remote networks, you implement a remote collection node. These nodes perform no analytics, they simply forward the collected data to the analytics cluster.
Whether it’s a master, data, or remote collection node, an adapter is installed to collect data from specific IT components (objects in vROPs terminology).
Without data, we have nothing. So, we need processes that can recognize and collect data. To allow vROPs the ability to collect data from virtually anything you might be interested in, the architecture defines an adapter interface via API that allows conforming software to collect and provide data into vROPs via the controller.
This software can be referred to as adapters, management packs, or solution packs. The adapter is what provides an interface to the data and collections mechanism. Solution/management packs generally imply that dashboards and other content are included with the adapter as a package. I’ll refer to the adapter from here on.
I don’t intend to get into the weeds on how an adapter is implemented at an API level because it’s not relevant to the audience I’m writing for. What is important for any implementer or operations role is that each adapter is somewhat unique in behavior with regards to configuration, metric values collected and implications on sizing and optimizing your vROPs implementation. We will discuss those nuances in a future post all about adapters.
Adapters are implemented based on the metric values you need to collect. This might be a vROPs bundled adapter to collect vCenter data, an adapter from the VMware Solutions Exchange to collect vRealize components data, an adapter from a 3rd party storage vendor to collect storage data, or an adapter from a commercial publisher like BlueMedora to collect SAP data.
Metric values collected by adapters are structured into metric packages. Metrics have quantifiable values and thus allow us to make decisions based on value boundaries called thresholds.
I won’t delve into the nitty-gritty of the internal processes vROPs uses in analyzing metric since it’s really not important to operationalizing and administering vROPs. Analytics is where any operations management endeavor becomes more complex. This facet requires an understanding of the metrics, their relationships, and what they tell us.
The vROPs installation provides the vCenter solutions package consisting of the adapter to connect to vCenter and the set of predefined dashboards. This model accelerates the operational use of vROPs as it provides the user with metrics that are already grouped and analyzed based on external knowledge and then presented in a convenient dashboard format.
Many solutions packages are available to provide this benefit. As mentioned earlier, some are free and some are developed for profit. The advantage is that you can quickly exploit the benefits of vROPs without needing a great deal of expertise in the underlying objects and metric values.
Analysis is performed on metrics from an object or a group of objects (object group). We apply a policy to tell vROPs what thresholds, problem definitions, alerts, etc. are important. A policy is the set of rules applied to analyze and display information about the objects. An alert definition comprises one or more symptom definitions and is associated with a set of recommendations and actions that help you resolve the problem.
I will dedicate multiple posts to working with object groups, metric values/packages, policies, symptoms, thresholds, and all other components of analytics. In my opinion, this is the single most important topic relative to operationalizing vROPs.
vROPs has two primary storage resources, in-memory and on disk. There are advanced in-memory database and memory clustering components, with traditional disk-bound database tables for longer term storage. Adapters send collected data to the vROPs analytic cluster where the service determines the storage location(s).
While vROPs (as of version 6.4) can still be deployed on a Windows server, Red Hat host, or as a VMware appliance, it is designed to be managed like an appliance in any deployment option. The underlying components for compute and storage are the same and managed through the vROPs management interface. It is important to note that the Windows and Linux deployment options are being phased out and you should be moving toward the appliance.
In future posts , I’ll cover some of the reasons vROPs components have the requirements they do. Some of the requirements are based on the underlying GemFire fabric that serves to provide the memory and compute clustering for scalability. This should not be a factor to the deployment and operations of vROPs due to the appliance nature. But an understanding assists in understanding the vROPs Analytics Cluster concept and how it differs from a vCenter cluster.
Adapters collect data for the Analytics Cluster where it is then stored by the vROPs controller in-memory initially. As the data becomes cold, it will be written to disk, where it remains for a term based on your retention policy. The Analytics Cluster can be a single or numerous appliances. It is where all vROPs data is held and analyzed.
Dashboards, Notifications, and Reporting
To make use of our analyzed data, we rely on dashboards, notifications, and reports. We can utilize reusable views and widgets to build out our dashboards and reports.
A dashboard presents current status in a visually hierarchical format. Allowing you to see anomalies or problems, and then click down to the root cause. Widgets are the building blocks that make up a dashboard.
As mentioned earlier, many adapters are provided in a solution pack that includes predefined dashboards. You will likely have multiple dashboards and they will likely focus on infrastructure in one case and a specific service in another.
Reports allow us to publish summary to detailed histories of metric collection and object status. Alerts are fairly self-explanatory.
We’ve covered the basic components of vROPs 6.x and discussed how they work together to provide us with operational insight and intelligence.
You deploy an appliance to your vSphere data center, install and configure adapters for the objects you want to collect data from, set a policy to define how, when, and in what combinations that data is important to you, use dashboards to view recent analysis and reports to convey historical analysis.
There are many great resources on the topic of vROPs, including other blogs and the VMware online resources. Here are a few:
The book VMware vRealize Operations Performance and Capacity Management by Iwan Rahabok is an excellent read. It was written for the vSphere 5.5 and earlier version of vROPs 6x, but is still a great source to develop a deeper understanding of core metrics and the relationships to performance and capacity. It’s available for purchase as an eBook here:
Another great book that provides excellent information on operationalizing vROPS is available for purchase as an eBook here:
I highly recommend both books to anyone that is implementing and using vROPs. Even if you have a good working knowledge already.
I won’t post on installation since it’s covered well in the VMware Information Center link. I may cover some nuances related to sizing when 3rd party adapters are in play and v6.4 release notes.
The net/net in getting value out of vROPs 6.x:
- It’s extremely simple to deploy, begin collecting data, and performing analytics.
- There are numerous out-of-the-box dashboards aligned with predefined health checks, alerts, and alarms.
- It provides prescriptive remediation and capacity optimization recommendations without configuration.
- Investing time in learning about the metrics and thresholds specifically important to your services is required in order to extend the value of vROPs.
I think the next post will diverge a bit from vROPs fundamentals and cover the new Predictive DRS feature, available with vROPs 6.4 and vSphere 6.5. Predictive DRS extends the proactive enablers in vROPs to the vSphere foundation capability of the Distributed Resource Scheduler. Why wait for contention to trigger automatic resource balancing when you can predict it?