vRealize Operations provides admins a multitude of capabilities to help them manage and simplify their IT environments. One of the most powerful features, relationship mapping, often goes a little unnoticed by some of the users. Behind the scenes, vRealize Operations relationship maps out the relationship between each resource kind within vRealize Operations.
A common example of such a relationship is when you select a virtual machine from the Environment Overview widget. You notice right away that vRealize Operations automatically locates and highlights the ESXi host on which the virtual machine resides. Then it identifies the related Datastore and Cluster objects.
What many admins don’t know is that vRealize Operations relationships don’t end there. The next step for a VI admin is to extend these relationships beyond the virtual layer – up and down the application stack to the compute, storage and network layers; gaining true visibility across their entire environment.
Figure 1 – Blue Medora’s vRealize Operations Product Portfolio
Extended visibility is enabled via the addition of either VMware or 3rd party “Management Packs”. For us at VMware, third-party independent software vendors, like Blue Medora, have created many robust Management Packs for vRealize Operations to extend the core capabilities of the platform. Each of these Management Packs sheds light on another layer of the stack and creates links tying these layers together. This provides complete visibility from the application layer all the way to the hardware it’s hosted on.
Figure 2 – Visualizing relationships in vRealize Operations
Gain True Visibility
Take a look at our system in Figure 2. We have installed the Management Pack for Oracle Enterprise Manager, the Management Pack for Cisco UCS, and the Management Pack for NetApp Storage. We created a custom dashboard showing our critical production databases (in this case, three Oracle Databases). These automatic vRealize Operations relationships show us where those Oracle Databases are virtualized, and the datastore they are connected to and dependent on. This is vital information, which will be critical if we need to debug any performance issues. We also know exactly which Cisco UCS chassis and blade this Oracle DB is running on. Finally, we can see the NetApp storage array backing our Oracle Databases. Now we can see the Oracle Database all the way down to the individual physical disks it is using. At a glance, you are able to understand the health and performance of every component of the application stack.
Now take a look at the Cisco UCS chassis. You will notice there is a potential health issue. We can click to see what is going on.
Figure 3 – Smart Alerts in vRealize Operations
It looks like this particular Cisco UCS chassis is down to a single functioning power supply unit. This is obviously sub-optimal. A single functioning power supply unit puts our production Oracle Databases at risk. Now that we have identified the infrastructure-wide impact, we can begin to remediate the issue.
This level of visibility and understanding is achieved thanks to vRealize Operations relationship mapping. It is now possible to eliminate the finger-pointing that can occur between teams (application owner, DBA team, storage team, VI Admins, etc.) by simplifying and accelerating issue resolution.
Relationships are the real unsung heroes of the vRealize platform. Not only do they aid the administrator in quickly identifying any issues that may be occurring within the environment, but they also enable the VI admin to have a complete app-to-hardware view of their infrastructure.
