Earlier this week I spoke about our efforts to failover vCenter Operations Manager (vCops) between two sites. In that article I stated that we used vApp containers at DR site, and added vApp variables to the Analytics and UI VMs at the recovery site. While this was painstaking to set up initially, it did provide us with the ability to failover vCops seamlessly to the DR site, with the vApp VMs inheriting their network settings via the vApp construct. At the end of that post, I mentioned a KB article, 2031891, which discusses the DR of vCops using IP Customization via SRM Recovery Plans. This also used a Resource Pool to hold the vCops VMs rather than a vApp. I will cover our experiences with that approach in this post.
I just spent a very useful week looking at how our customers might be able to protect vCenter Operations Manager (vCops) with VMware’s vSphere Replication (vR) and Site Recovery Manager (SRM) products. It was quite tricky to get this to work, if I’m perfectly honest, but that was the whole point of the exercise. What we learnt is being fed back to the various business units within VMware, to see if we can make this more intuitive and less complex to achieve, but if you are interested in knowing how to configure your DR infrastructure to protect vCops, please read on.
I’ve been doing a bit of work over the past number of weeks on the adapters for vCenter Operations (vC OPs) with my old pal Paudie. We are working on vCenter Operations 5.8 and using a vSphere 5.5U1 environment. Since we have a Brocade Fibre Channel switch and an EMC VNX array in our lab, I wanted to get the Management Pack for Storage Devices (MPSD) and the Brocade SAN Analytics Management Pack deployed, and see what information we could glean from those extension packs. When we completed the configuration, we were able to go into the vC OPs customs view and see details like the following Brocade – Health Overview and Storage Components Heatmap:
Caution: We spent a lot of time trying to figure out why the MPSD adapter would not connect to the CIMOM service on Brocade’s Network Advisor. This boiled down to networking/DNS configuration issues. The MPSD release notes for vC OPs describe the issue. As they say, I should have RTFM. Anyhow, here are the steps we went through to get this setup going. I’m afraid it is rather long, but hopefully you will find the information in here useful.
Continuing on my set of posts related to Virtual SAN (VSAN) interoperability, let’s take a look at how vCenter Operations Manager (vC Ops for short) integrates with Virtual SAN. vC Ops version 5.8, which was released in December 2013, recognizes the VSAN datastore and can report various characteristics, as you might expect. Although vC Ops 5.8 was released around 3 months before VSAN GA’ed, this release works with ESXi 5.5U1 and vCenter 5.5U1, the vSphere release which introduced VSAN. However, this release of vC Ops does not present all the ‘storage’ metrics for VSAN like it does for datastores based on other storage types. But, having said that, there are still a number of useful vC Ops views and metrics that you might find useful which this post will cover.
In a post on the vSphere blog, I spoke about how to use maintenance mode. As a follow on request, a number of people asked me how they should safely shutdown a VSAN cluster. In this post, I will address that question and share my observations.
On my three-node VSAN cluster, I had a number of virtual machines as well as a vApp running vCenter Operations Manager VMs. My first step was to shut down all virtual machines in my cluster.
In a few recent posts, I’ve been looking at performance counters in vSphere 5.1. One of my colleagues, Hugo Strydom, reached out to me about doing a vCenter Operations (vCOps) custom dashboard to monitor the new Storage I/O Control (SIOC) counters in vSphere 5.1 which I detailed here. Hugo has done a whole series of great blog posts on vCOps on his blog site. I thought it would really cool to get this setup on my environment and take a look.