Architecture, scalability, and resilience

Like most solutions from VMware, vRealize Operations Manager is delivered as a virtual appliance based on SUSE Linux.

Note

vRealize Operations Manager can also be installed on Windows or Linux. However, that needs special consideration, so is outside the scope of this book.

Appliance nodes and components

The basic building block of vRealize Operations is the virtual appliance node. The solution can be scaled from a single node to a maximum of 16 nodes, to support larger scale deployments or high availability (HA). Remote collector nodes can also be additionally installed to collect the metric data from remote datacenters with limited bandwidth connectivity.

Regardless of the role of a node, the same OVF is used to deploy the virtual appliance, and, as of vRealize Operations Manager 6.0, there is no longer the requirement to host remote collectors on Linux or Windows.

To a great extent, this has made the design, implementation, and management of vRealize Operations very straightforward, relative to the complexity and capabilities the solution provides.

The preceding diagram shows the different roles the nodes can take. Although they are all installed using the same virtual appliance OVA file and contain the same code, the nodes will only run the services required to fulfill their role. The roles are as follows:

• Master Node: The first node you install in the cluster. This is the controlling node for the cluster.
• Data Node: This adds additional scale to the cluster. Multiple data nodes are deployed under the following circumstances:
  • If the scalability limits of a single large node is reached.
  • When a larger number of smaller nodes is desired. For example, the ESXi hosts for the nodes may not be able to support the size of the VM required by a large node.
• Master Replica Node: This is a copy of the Master Node, containing the Global xDB, and it will take over the operation of the cluster if the Master Node fails.
• Remote Collector Node: This resides in a remote datacenter to collect the metrics and properties from a remote vCenter. This is used under the following circumstances:
  • When bandwidth to the remote datacenter is limited. A Remote Collector Node reduces the bandwidth requirements by approximately 65%.
  • If a firewall is in place between the Master Node and the vCenter server, and the appropriate ports cannot be opened.

The components running within the nodes are as follows:

• Product and Admin User Interface: The Product UI is the main UI used to access vRealize Operations and is available on all the nodes except for Remote Collectors. The Admin UI is used for cluster administration and is available on all the nodes.
• REST API: A pluggable service used by the vRealize Operations adapters to collect data and metrics. The API also allows the external services to interface with vRealize Operations.
• Controller: It ensures insertion of the collected data to the correct resources, and retrieves the data queries when requested. It also ensures consistency of the data across all the nodes.
• Analytics: The analytics engine performs metric calculation when the metrics are ingested, and runs the nightly Dynamic Threshold jobs. Analytics is also responsible for triggering alerts.
• Persistence: Every node persists its own set of data to the local disk for processing.
• FSDB: It is the data store for metric data.
• xDB: It stores the alerts and the alarm data, as well as the Historical Inventory Service (HIS), which is responsible for storing the resource properties and relationships.
• Global xDB: It contains the cluster configuration data.

Architecture

Once a vRealize Operations cluster is established, solutions are configured to connect the cluster to the infrastructure to be managed, as can be seen in the following diagram.

The first solution to be configured will be to one or more vSphere environments, connecting the built in adapter to the vCenter Server(s) supporting those environments.

Extending the solution to provide performance and health monitoring, and the capacity planning for storage is enabled, either by using the generic vRealize Operations Management Pack for Storage Devices, or one of the specific Management Packs from the storage vendor or third party developers. More information on these integrations can be found in Chapter 7, vRealize Operations Manager Solutions.

Note

Management Packs written by VMware are included with editions of vRealize Operations, depending on the edition licensed. Management packs written by third parties are provided and supported by the third party and may require an additional license fee.

If vCloud Air or Amazon EC2 are used, Management Packs are available to connect the solution to these environments.

Integration with the other vRealize components, such as vRealize Hyperic or End Point Operations and vRealize Log Insight is also enabled using the Management Packs.

Finally, if there are remote datacenters, remote collector nodes can be configured to collect the metrics if low bandwidth conditions exist.

Scalability

One of the design goals of vRealize Operations was to meet the scalability requirements of the largest infrastructures, which can run to tens of thousands of VMs and other resources.

Every 5 minutes, vRealize collects and stores about 250 metrics per VM, 500 metrics per host, and, typically, 50 or more metrics for the other object types. As a result, the total quantity of stored data, and the volume of the metrics being analyzed every night, can become significant.

Note

An environment with 1,000 VMs will typically have over 300,000 metrics being collected every 5 minutes and analyzed every night. With the default 6 month data retention period and HA in place, that means over 30 billion data points being stored!

VMware provides detailed sizing guidelines, and it is very important that these are followed. If insufficient resources are made available for vRealize Operations, it will cease to function correctly!

The latest version of vRealize Operations Manager, version 6.1, supports up to 120,000 objects and 30,000,000 metrics, with 16 nodes in a non-HA configuration. If an HA environment is required then these figures are halved.

VMware publishes links to the most up to date sizing guidelines and spreadsheets at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2093783.