Part 11: Using vRealize Operations Manager to Monitor the Cluster Nodes

In the series on vRealize Operations, I wrote about the Architecture of vRealize Operations Manager which allows you to have Master and Replica nodes in a vROps Cluster. This not only allows you to distribute the adapters or solutions to more than one collectors present on each host, but also gives you resiliency in case the Master Node in the cluster fails.

With this post, I will actually share a failure which has been seen in my lab because of a couple of services failing on the master node. This resulted in a fail-over and the Replica switched over to become the Master Server. All this is possible because just like the previous releases, each and every service on your vROps nodes in being monitored by vROps itself.

Let me give you a brief description of my lab before I begin:

Part 4 - vRealize Operations Manager Deployment Models!

Now that we are aware of the new features and the architecture of vRealize Operations Manager, with this post I will talk about the various deployment models which are possible while deploying vROps 6.0 in your infrastructure. I will be writing about the options available to those who are already running on vCOps 5.x for moving to vROps 6.0 in the next part, however with this part I am focused on talking about the deployment architecture of the solution by considering various deployment scenarios.

While talking about the Cluster Architecture of vROps, I also pointed out to the fact that the scalability and performance of vROps 6.0 comes form the in-memory database - "GemFire" which allows you to access hot data from the memory layer making it fast and also allows you to stripe this data across multiple nodes.

Here are a few design principles which we need to consider while choosing the deployment model:-

• vROps 6.0 Cluster Nodes are required to be in a Local Area Network.

• For collection from remote vCenter Servers you would require a REMOTE COLLECTOR

• Deploying a Cluster Architecture is not a compulsion. It is done only when scalability & resiliency is required.

• For 100% resiliency it is important to protect the MASTER NODE by using a MASTER REPLICA.

• Each node in a cluster has to be of the EXACT SAME configuration (CPU, MEMORY & STORAGE)

Now let's look at some of the deployment scenarios and what would be the architecture of vROps.

Deployment Example 1 - Multiple vCenter servers in one datacenter location!

With a single datacenter with one or Multiple vCenter Servers you would deploy either one or more than one node in the cluster depending on how you want to scale the cluster for monitoring more resources and also increasing the resiliency by enabling the HA feature. All the users login to this one site.

Deployment Example 2 - Multiple vCenters in one location & vCenters in many other different datacenter location.

With the above scenario, you can either choose to have an individual vROps instance (clustered or non-cluster) in each site or you could have one centralized vROps instance in the major location, while you can have remote collectors in each of the other sites which have vCenter Servers in them. If the centralized deployment is used then all the users will have a unified view through the centralized datacenter. With vROps instance in each site, the users will login to the site they wish to access.

Deployment Example 3 - Multiple vCenters in two main locations.

In this third and final example, each datacenter has a number of vCenter Servers hence you can choose to deploy a separate instance of vROps cluster in each datacenter. In this case, the users will login to their local vROps instance to access the resources they are monitoring.

With the next part, I will take you through the steps to install & configure the vROps appliance and then we will look through the various options available within the solution.

Till then..

Share & Spread the Knowledge!!

Part 3: High Availability options with vRealize Operations Manager!

With this part of the series, I will start right from where I left in my last article. In the previous post, I spoke about the architecture of vROps along with the various services and node types which are available with this release. At the end of that article, I spoke about the benefit of having a cluster like architecture which not only provides scalability to the entire solution, but also allows you to protect the solution by building in resiliency.

The cluster architecture of vROps is not about scaling the various services within the solution, however it is about making these services modular by using a uniform measure to scale them. This uniform measure is a DATA NODE. Hence, instead of scaling out let's say just the PERSISTENCE layer by adding more memory, you would basically look at adding a new DATA NODE which will automatically add scale to all the services in an equal amount. This not only makes the solution modular, it also ensures that standardisation is maintained during scale resulting in a predictable and optimised performance.

For ease lets take a scenario where we have One Master Node, One Master Replica and one Data Node as shown in the figure below:-

Taking the above architecture let us discuss a few scenarios which are handled by the vROps cluster for data distribution, redundancy and resiliency.

HOW DATA ARRIVES INTO vROps CLUSTER

The resource will be assigned to one Node and all the analytics work regarding that resource will be done by that node itself. Only in case of failure the standby node which has the replicated data will become the Active Node for that resource.

HOW DATA IS RETRIEVED FROM vROps CLUSTER

With this architecture the data retrieval for 'HOT DATA' is extremely fast since the data is in the 

"in-memory database" layer of the cluster. Now that we know how the data is collected and retrieved, we can look at various failure scenarios which a vROps cluster can survive.

MASTER NODE FAILURE - If the master node fails, the complete responsibility of the master is taken over by the Master Replica. The Replica gets promoted and ensures that the solution is available at all the time. In case the Master Node failed due to a hardware failure and is back online with the help of vSphere HA, this node will be configured as the Replica Node thereafter.

DATA NODE FAILURE - If the Data Node fails, then the owning resources of that node are promoted on the surviving nodes which have a replica copy of these resources. The new owning node is responsible for collection of data from here onwards. If a data node has failed due to hardware failure and vSphere HA brings it back on a surviving ESXi node in the vSphere cluster, then this node automatically joins the vROps cluster and the data points are synced on this node. If a data node has been out of a cluster for a long time (more than 24 hours), it would be a better idea to re-create that node from the scratch rather than rebuilding/re-syncing the data.

IMPACT ON DATA FLOWS DURING FAILURE - If a node fails while the data is being queried or collected in the vROps cluster, it would not have any impact on data failure or availability as the surviving nodes will serve that data requirement through the replicated resources on them.

The placement of each node of the cluster should be done on a separate ESXi host using anti-affinity DRS rules to ensure that a host failure should not impact more than one Node in the cluster to avoid any data loss / availability issues.

Now that we know how vROps cluster architecture works, in the next part of this series we will have a look at the various deployment models which can come into picture when you plan to deploy vROps 6.0 in your infrastructure.

Till then.... Stay Tuned :-)


Share & Spread the Knowledge!!