Virtual Machine Restart Priority

We are all guilty of doing this, we design and install a beautifully crafted vSphere 5 environment following best practises for HA, host isolation responses and we setup our admission control to meet the clients requirements.  When then pass the VMware environment back to the client to manage and maintain themselves.

The client has a hardware failure and the VM’s are restarted on an alternative host, excellent we say.  However the client is far from happy as we didn’t mention or configure ‘virtual machine restart priority’ and they encountered complications as the VM’s came up in the wrong order.

In essence virtual machine restart priority enables selected virtual machines to start before other virtual machines over riding the clusters default settings.  To configure virtual machine restart priority:

– Right Click Cluster
– Edit Settings
– Virtual Machine Options
– Virtual Machine Settings > VM Restart Priority

Lets look at the following scenario.

Scenario A

Client has VMware Standard licensing, which means they don’t have DRS.  They have two Exchange 2010 email servers, one running the CAS/Hub role and the other running Mailbox role.  They reside on the same host as someone thought this would a ‘good idea’.

The physical host fails and it’s a free for all for the VM’s to restart, as a result the CAS/Hub server comes up before the Mailbox server.  As a result Outlook Client connectivity, OWA and Active Sync take longer than anticipated to connect resulting in an extended downtime.

Scenario B

Same client has configured virtual machine restart priority with the following settings:

Mailbox server – High
CAS/Hub server – Medium

The VM’s restart in the right order and the client has less downtime.

Best Practices

Naturally every environment is different, but as a general rule of thumb, I recommend using the following guidelines.

Exchange

– CAS/Hub – High Priority
– Mailbox – Medium Priority

Domain Controllers

– If FSMO role holder – High Priority
– If Global Catalogue – High Priority

SQL

– SQL Server – High Priority
– Applications relying on SQL e.g. BES – Medium Priority

Citrix

– Data Collector – High Priority
– Web Server – Medium Priority
– License Server – Medium Priority
– Farm Members – Low Priority (as you want everything else to be up and running before users login).

Debunking the Myths of Virtualizing Your Business Critical Applications

They say fear is good.

Fear can be a healthy thing—it can keep you from getting in over your head, taking unnecessary risks, and it can even save your life. In IT, that fear—maybe better framed as ‘caution’—has its place. It ensures that we consult with others, adhere to processes and standards, and balance risk with reward. Caution in IT ensures that business keeps moving forward—because if it doesn’t, revenue is at risk (and necks are on the line). So, we proceed with caution.

In the world of virtualization, there is fear—but, for the most part, it’s misplaced. Many companies that have fully embraced the benefits of virtualization are still missing the greatest value because they think it’s too risky to virtualize business critical applications (BCAs).

Read more here

VMware vSphere Metro Storage Cluster

Today VMware have annouced the support for ‘stretched storage cluster’ and have produced a white paper to this effect.

The purpose behind a ‘stetched storage cluster’ is to have two different geographical sites which reside on the same subnet (stretched VLAN) to enable routine tasks as high availability, vMotion and Storage vMotion to take place.  It is not intended to replace VMware Site Recovery Manager.

Essentially, you need to have an array which has the ability to perform reads to and writes to both locations at the same time.  The white paper mentions latency values up to 5ms, however, my experience with synchronous SAN based replication is that we encountered performance hits with latency above 2ms.

The white paper can be found at VMware vSphere Metro Stroage Cluster