Yellow Bricks

by Duncan Epping

ha

VMware HA Implementation notes update!

· ·

A few weeks ago I posted a document which contains valuable information on implementing VMware HA. I just received an update on this document and uploaded it. I’ve also changed the link in the original post.

As most of you know I work for VMware which means I receive a huge amount of email and documents with excellent technical info. Some I can’t blog about but some I can. Last week I received this VMware HA implementations notes document by Seva Semouchin. Seva is a Technical Account Manager based in Germany!

This document deals about VMware HA clusters and all the advanced options you have with the use cases for these options. And that’s what makes this document very useful, the use cases! So everyone dealing with HA clusters should definitely read this document. Thanks Seva for letting me distribute it, and thanks for a great document!

VMware Communities Roundtable podcast tonight!

· ·

I’m really looking forward to the podcast tonight. We’ve got Chad Sakac from EMC joining in to elaborate on topics like:

  • What VMware, EMC and Cisco are doing together around the Next Generation Datacenter
  • What’s coming in vStorage
  • Reference Architectures for Tier 1 applications like Exchange, SQL Server, Sharepoint
  • What we’re seeing around Disaster Recovery for VMware
Most of you probably discovered Chad’s blog by now, if you didn’t check it out. Especially his post on vStorage gives you an idea what Chad and his team are working on. But also the more technical posts like this one on VMFS Resignaturing contain really valuable info.
Anyway join us on the podcast. Wednesdays noon PST / 3pm EST / 8pm GMT. You can find live Connect info here. (For those like me having trouble converting time to your time zone click here.)

HA best practices

· ·

So I’ve been collecting some HA best practices lately. I just wanted to have them all in one place so I can use them myself for the VMTN forum and/or customers. The first two are obvious in my opinion but still often overlooked:

  1. Your ESX host-names should be in lowercase and use fqdn’s
  2. Provide Service Console redundancy
  3. If you add an isolation validation address with “das.isolationaddress”, add an additional 5000 to “das.failuredetectiontime”
  4. If your Service Console network is setup with “active / standby” redundancy then your “das.failuredetectiontime” needs to be set to 60000
  5. If you ensured Service Console redundancy by adding a secondary service console then “das.failuredetectiontime” needs to be set to 20000 and you need to setup an additional “das.isolationaddress”
  6. If you setup a secondary Service Console use a different subnet and vSwitch then your primary has
  7. If you don’t want to use your default gateway as an isolation validation address or can’t use it because it’s a non-pingable device then disable the usage by setting das.usedefaultisolationaddress to false and add a pingable “das.isolationaddress”
  8. Change default isolation response to “power off vm” and set restart priorities for your AD/DNS/VC/SQL servers
So if you’ve got more, add them into the comments and I will update the list!

das.failuredetectiontime for active/standby COS vswitch

· ·

It used to be a best practice to increase the “das.failuredetectiontime” to 30000 for an active/standby setup. This way when a failover to another nic occurs one would have atleast 30 seconds to switch over before HA starts shutting down VM’s. The default value is 15000 by the way.

If it’s not really clear I’m talking about a setup like this:

  • vSwitch0 – 2 Physical nics(vmnic0 & vmnic2) – 2 Portgroups (Service Console & VMkernel)
    Service Console active on vmnic0 and standby on vmnic2
    VMkernel active on vmnic2 and standby on vmnic0
    Each portgroup has a VLAN assigned and runs dedicated on its own nic, only in the case of a fault it’s switched over to the standby nic, but it will return to the original nic when the connection is up again. 

I just noticed in the Resource Management Guide pdf that the best practice is to increase it to 60000. In other words, it can take up to 60 seconds before your HA starts restarting machines. For a secondary service console you only need to  increase by 5 seconds cause of the fact that an additional isolation address needs to be checked. In other words a secondary service console saves you 30 seconds when isolation occurs which can be a lot in a 7×24 environment.

So like I blogged three months ago, going for a secondary service console is definitely the best option you have for service console redundancy today! Keep in mind though that your secondary service console needs to be in a different subnet than the primary!

VMware HA implementations notes

· ·

As most of you know I work for VMware which means I receive a huge amount of email and documents with excellent technical info. Some I can’t blog about but some I can. Last week I received this VMware HA implementations notes document by Seva Semouchin. Seva is a Technical Account Manager based in Germany!

This document deals about VMware HA clusters and all the advanced options you have with the use cases for these options. And that’s what makes this document very useful, the use cases! So everyone dealing with HA clusters should definitely read this document. Thanks Seva for letting me distribute it, and thanks for a great document!