VMware Metro Storage Cluster
VMware Metro Storage Cluster (vMSC) allows vCenter to stretch across two data centers in geographically dispersed locations. In normal circumstances, in vSphere 5.5 and below at least, vCenter would be deployed in Link-Mode so two vCenters can be managed as one. However, with vMSC it’s possible to have one vCenter manage all resources across two sites and leverage the underlying stretch storage and networking infrastructures. I’ve done previous blogs on NetApp MetroCluster to describe how a stretched storage cluster is spread across two disparate data centers. I’d also recommend reading a previous post done on vMSC by Paul Meehan over on www.virtualizationsoftware.com. The idea behind this post is to provide the VMware view for the MetroCluster posts and to give a better idea on how MetroCluster storage links into virtualization environments.
The main benefit of a stretched cluster is that it enables workload and resource balancing across datacenters. This helps companies to reach almost zero RTO and RPOs and ensure uptime of critical systems as workloads can be migrated easing using vMotion and Storage vMotion. One thing to keep in mind regarding vMSC, it’s not really sold as a disaster recover solution but rather a disaster avoidance solution when linked with the underlying storage. Some of the other benefits of a stretched cluster are:
- Workload mobility
- Cross-site automated load balancing
- Enhanced downtime avoidance
- Disaster avoidance
- System uptime and high availability
There are a number of storage vendors that provide the back-end storage required for a vMSC to work. I won’t go into the entire list but you can find out more on the VMware Compatibility Matrix site. The one that I have experience with is NetApp MetroCluster but I know of others from EMC and Hitachi at least. So what components make up a vMSC? It comes down to an extended layer 2 network across data centers so that vMotions can take place with ease and also a resilient storage platform connected to ESXi via VMFS or NFS datastores. VMware vCenter itself does need some configuration changes but it’s nothing outside the scope of what a regular VMware admin can implement. A view of what a vMSC looks like is below. The networking and storage components have been simplified.
VMware announced over the weekend that some major security vulnerabilities have been identified in vCenter and ESXi 5.0, 5.1 and 5.5 as well as version 6.0. 6.0 Update 1 is not affected. Only the JMX RMI Remote code execution is an issue in vSphere 6.0. 3 vulnerabilities have been identified and the affect different versions in total.
ESXi OpenSLP Remote Code Execution
- Allows unauthenticated users to execute code remotely on ESXi host
vCenter Server JMX RMI Remote Code Execution
- An unauthenticated remote attacker that is able to connect to the service to execute arbitrary code on the vCenter server
vCenter Server vpxd denial-of-service vulnerability
- Can allow a remote user to create a denial of service on the vpxd service through unsanitized heartbeat messages
The announcement was broken on both the VMware and TheRegister sites and I’d recommend viewing more information on both of those sites. TheRegister also gives some great background on how the issues were originally identified. The full advisory details including links to the CVE references can be viewed on the VMware Security Advisories site for VMSA-2015-0007.
If you are running vSphere 5.0 the recommendation is to upgrade to v5.0 Update 3e. For vSphere 5.1 upgrade to v5.1 Update 3. For vSphere 6 the recommendation is to patch with Update 1. vSphere 5.5 however has some issues. In order to fix the denial-of-service or the OpenSLP issues it’s advised to upgrade to vSphere 5.5 Update 2. However, to resolve the JMX RMI issue VMware have confirmed that vSphere 5.5 Update 3 which was released in early September as being the fix. But, a new bug has been identified with Update Patch 3 regarding snapshots. If a snapshot is deleted in vCenter it causes the VM to crash. Considering that the majority of snapshot related backup solutions utilise VMware snapshots it means that all VMs would reboot each night. Considering uptime is always a business and IT priority then it’s really not a feasible solution.
My advice would be to at least upgrade to vSphere 5.5 Update 2 if you can. Upgrade to vSphere 6.0 Update 1 if possible but that may require considerable research and interoperability checks and may not be on your roadmap just yet. Do not install ESXi 5.5 Patch 3 if your backup software depends on VMware snapshots.
Other posts in this series:
Step 20: Upgrade the ESXi hosts using Update Manager
20.1: The first step to carry out is to create a new baseline with the ESXi image. To do this go to Update Manager from the home page on the vSphere client
20.2: Click on the ESXi Images tab as you’ll need to upload the image before configuring a new baseline. Select Import ESXi image
20.3: Select the ESXi image that was downloaded earlier and click Next
Other posts in this series:
Step 13 : Upgrade SRM
13.1: Upgrade the SRM server software first and once that has been completed update the SRA. Select the SRM software and run it.
13.2: Click Ok on the language settings
13.4: Go to C:WindowsSysWOW64 and run odbcad32 and check which server and database the connector is directed to. You can then run the normal 64bit ODBC from Administrative Tasks and add a new connection under System DSN
Click next to continue
13.5: Click Next
Other posts in this series:
Step 10: Upgrade vCenter Inventory Service on Primary
10.1: Select vCenter Inventory Service and click Install
10.2: Leave the default language settings and click Ok
10.3: Click Next on the initial screen
10.4: Accept the EULA and click Next
10.5: Select to keep the existing data and click next