Using "Shrink Cluster" feature of vRealize Operations 6.7

vRealize Operations 6.7 comes with a new functionality which allows you to reduce the number of nodes in your vRealize Operations cluster. This feature of vRealize Operations is to meet the following use cases:

1. Scale up your vRealize Operations nodes to extra-large nodes - If you wish to scale down the number of nodes in the cluster and scale them up to extra-large configuration

2. Rightsizing a large cluster - A cluster which is deployed for more nodes than required. This would also include clusters where you would want to take the benefit of scale improvements of 6.7 and hence want to reduce the number of nodes now.

Note - This process will bring the cluster offline, once the data is copied over from the node which needs to be removed. It is recommended to run this operation during a planned downtime.

This option of shrinking a cluster is available in the admin UI.

a) Login to the Admin User Interface with https://vrops-ip/admin/ using the admin credentials

b) Click on the Shrink Cluster button.

c) Once the Shrink Cluster wizard, review the nodes in the cluster and select the node which you want to remove from the cluster. This will also show you the space used by each node. 

Note - Before the node is removed all the data from this node will be copied over to the remainder of the nodes in the cluster.

d) Upon clicking next, you can see all the adapter instances which are being hosted by the node you are trying to remove. These instances will automatically failover to the remainder of the nodes in the cluster. 

e) Put a check against I understand the risk and click on Next.

f) Click on Shrink Cluster.

g) From here on the process is automatic. The data migration will start. In my environment, the node was using 13 GB space since it was a new deployment. It hardly took 5 minutes to copy data over.

h) Once the data was copied over, the cluster went offline.

i) After a few minutes, the shrunk node was removed from the cluster and the cluster was ready to be brought online again. Click on Bring online.

j) BOOM, the cluster is back online with a single node and ZERO data loss.

Here are some recommendations for using this feature in your environments:

1. Please ensure you have done a sizing excercise to determine the number of nodes and node sizes required for your environment.

2. This operation might run for hours if you have a large amount of data to copy from the node, hence please schedule this during non-business hours to lower impact.

3. The users will only be impacted when the cluster goes offline. It is recommended to open a change or inform the users about the expected downtime.

4. Ensure you have enough storage available on the remainder of the nodes.

5. The removed node will be in an unusable state. It is recommended to destroy the node and re-build if you plan to re-use them.

6. You can cancel the operation till the time the option is available on the UI, post that, it is an irreversible process.

7. If you have ran this feature to shrink the cluster to upsize the cluster to extra-large nodes, please upsize all the remainder of the nodes before bringing the cluster back online.

8. It is recommended not to run this process during backup process of vRealize Operations.

Click here to download your copy of vRealize Operations 6.7.

Scaling up vRealize Operations Manager Nodes!

This is a quick note to give you tips around scaling up vRealize Operations Nodes. In one of the vROps Webinar episodes we did touch upon the topic of Design Considerations for vRealize Operations Manager. 

During that discussion, I do talk about the fact that you can scale out or scale up the vROps cluster depending upon the requirement. While Scale Out is simple and you can do it by adding new nodes to the cluster, scale up can be trivial in some cases.

While working with a customer, where we decided to scale up the vROps nodes from Medium to Large, I found out that the small and medium vROps appliances when deployed for the first time are deployed with hardware version 7. This means that the appliances cannot go beyond 8 vCPUs as hardware version 7 has a configuration maximum of 8 vCPU for a virtual machine. This means that when you try to upgrade from a Small or Medium node to a Large vROps node, you will hit a wall unless you upgrade the hardware version of the appliance.

In this case, while you can update the hardware version, please ensure that you do not touch the VMware tools version. In other words you can update the hardware version to move from 8 vCPUs to 16 vCPUs without any issues. Needless to say that the hardware version upgrade would include a downtime. Just to be clear on the sequence of steps:

• 1- Make sure you have a Full Backup of your appliances ( a general recommendation before hardware version upgrade).

• Bring the vROps Cluster offline from the Admin UI.

• Shut down the appliance(s) gracefully using the vSphere Client.

• Right click on the appliance(s) and chose the option of upgrading the hardware version. I would encourage you do this using vSphere Web Client to get to the latest supported version.

• Make the nodes of large configuration i.e. from 8 to 16 vCPUs and 32 GB to 48 GB.

• Power on the appliance(s).

• Bring the cluster back online.

This process will automatically increment all memory configurations for Java Processes associated with Cassandra, Collector and other services within the application configuration files.

Please ensure that you to stick with the VMware recommended (tested) sizes of Small / Medium / Large as per the following KB article.

Share & Spread the knowledge!!

Right Sizing vCenter Operations Manager vApp For Efficient Performance !!

Out of a recent engagement on vCenter Operations Manager, the most important discussion point which came out was the sizing of vCOPS vAPP. There were other discussions as well which are interesting and I would write and share about those facts, however I thought this should be a good start towards understanding what vCOPS can do for you and how the solution should be sized for best results.

If you are new to vCOPS and need to understand the basics about vCOPS, you should refer to one of my previous article about vCOPS - vCenter Operations Manager - Solving Performance, Capacity and Configuration Problems!!

After going through that post you would know that vCOPS is available as a packaged vAPP which consists of two Virtual Machines. These machines are called:-

Analytics Virtual Machine and UI Virtual Machine

The diagram below shows the architecture of this vAPP:-

In this article I will not explain each of these components as it is clearly defined in a free VMware MyLearn training on the following link - VMware vCenter Operations Manager Fundamentals [V5.X]. I would highly recommend this training to anyone who wants to learn about vCOPS to understand the basics of this solution.

Now, coming back to sizing these virtual machines. 

Analytics VM - On a high level you need to understand that the Analytics VM is the one which does most of the work and also gets all the data in form of Raw Metrics. All the algorithms regarding the Performance Analytics run in this virtual machine and the same are stored in separate database which are hosted on this virtual machine.

UI (User-Interface) VM - This is where the Capacity IQ is hosted along with the Admin User-Interface, vSphere User-Interface and the Custom User-Interface. The Capacity related data is stored in a database which is a part of this virtual machine.

Now, the question which rises out from here is that how do we size these virtual machines in terms of CPU & Memory resources and how much storage should be assigned to these Virtual Machines to ensure that all the components of this application are able to run successfully and also perform all the tasks which you expect them to.

Since we know that vCOPS extends its offering to vSphere and Non vSphere environments, we need to look at sizing requirements from both perspectives:-

a) Based on the number of VMs – Works well for a vSphere-centric Environment.

b) Based on the number of Metrics – Works well when adding non vSphere adapters

Let's look at the numbers for a vSphere Environment for CPU, RAM & Storage

In case you are using a collector to collect metrics data from Non-vSphere environment, then you would need to calculate and add CPU, Memory & Disk resources on the basis of the recommended numbers below:-

I hope this will help you to size your vCOPS vAPP appropriately at the time of deployment. Right sizing will ensure that you do not face any issues with this application while it's monitoring the performance, showcasing capacity and ensuring standard configurations and compliance in your vSphere & Non-vSphere environment.