post

VMware Metro Storage Cluster Overview

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.

fabric metro cluster diagram

 

Read More

VMware – Security vulnerability VMSA-2015-0007

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.

post

How To: VMware vCenter 5.0 to 5.5 Update 2 Upgrade – Part 6

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

vCenter Upgrade Update Manager

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

Update Manager Import ISO Image

20.3: Select the ESXi image that was downloaded earlier and click Next
Update Manager Import ISO Image Select Image Read More

post

How To: VMware vCenter 5.0 to 5.5 Update 2 Upgrade – Part 4

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.

Update SRM 5.5

13.2: Click Ok on the language settings

Update SRM 5.5 Step 2

Update SRM 5.5 Step 3 Update SRM 5.5 Step 4

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

Update SRM 5.5 Step 5

13.5: Click Next

Update SRM 5.5 Step 6 Read More

How To: VMware vCenter 5.0 to 5.5 Update 2 Upgrade – Part 3

Other posts in this series:

 Step 10:  Upgrade vCenter Inventory Service on Primary

10.1: Select vCenter Inventory Service and click Install

vCenter Inventory Service installation

10.2: Leave the default language settings and click Ok

vCenter Inventory Service installation step 2

10.3: Click Next on the initial screen

vCenter Inventory Service installation Step 3

10.4: Accept the EULA and click Next

vCenter Inventory Service installation Step 4

10.5: Select to keep the existing data and click next

vCenter Inventory Service installation Step 5 Read More