Recently I received a question on twitter how the vSphere HA advanced option “das.isolationaddress” should be used. This setting is used when there is the desire or a requirement to specify an additional isolation address. The isolation address is used by a host which “believes” it is isolated. In other words, if a host isn’t receiving heartbeats anymore it pings the isolation address to validate if it still has network access or not. If it does still have network access (response from isolation address) then no action is taken, if the isolation address does not respond then the “isolation response” is triggered.
Out of the box the “default gateway” is used as an isolation address. In most cases it is recommended to specify at least one extra isolation address. This would be done as follows:
- Right click your vSphere Cluster and select “Edit settings”
- Go to the vSphere HA section and click “Advanced options”
- Add “das.isolationaddress0” under the option column
- And add the “IP Address” of the device you want to use as an isolation address under the value column
Now if you want to specify a second isolation address you should add “das.isolationaddress1”. In total 10 isolation addresses will be used (0 – 9). Keep in mind that all of these will be pinged in parallel! Many seem to be under the impression that this happens sequential, but that is not the case!
Now if for whatever reason the default gateway should not be used you could disable this by adding the “das.usedefaultisolationaddress” to “false”. A usecase for this would be when the default gateway is a “non-pingable” device, in most scenarios it is not needed though to use “das.usedefaultisolationaddress”.
I hope this helps when implementing your cluster,
It is my understanding that you start at das.isolationaddress1 and not 0 whenever you add extra isolation addresses
das.isolationaddress0 being the default GW that you modify whenever you set das.usedefaultisolationaddress to false.
But I might be wrong though…
B.
The start is 0 and the last is 9. The default GW is not part of that. Don’t know who informed you about this, but that is not correct.
Duncan,
Good information to know. Which interface does the ping originate from (Service Console port or a VMkernel port)?
Regarding the das.isolationaddress1-10 I’ve seen this in the vCenter 5 Availability Guide at http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-50-availability-guide.pdf page 30
Also KB Setting Multiple Isolation Response Addresses for VMware High Availability at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002117
Followed by KB Advanced Configuration options for VMware High Availability at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006421
And this KB VMware High Availability cluster reports the error: Could not reach isolation address at http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1002787
tells me that das.isolationaddress must be used with das.usedefaultisolationaddress when the GW is not pingable.
On your own web site, you say in HA Architecture Series – Advanced Settings (5/5) at http://www.yellow-bricks.com/2011/07/28/ha-architecture-series-advanced-settings-55/ to pair das.usedefaultisolationaddress and das.isolationaddress0
Surely you get the same result I guess, but it is confusing to say the least…
B.
I will get the KB articles corrected Bart to ensure the message is consistent and makes sense. Thanks for spotting that and taking the time to list them, much appreciated.
I removed several comments from this post as they were not appropriate. Any future comments that are not appropriate will also be removed without warning. I would again like to point to my disclaimer. Although I am a VMware employee all views expressed on this site are strictly mine and not the opinion / views of VMware and as such my recommendations may differ from VMware’s recommendations.
@Bart: All KB articles, documentation and the best practices guide will be corrected. I have validated it again and 0 – 9 is indeed what should be used. Also the recommendation to have at a minimum 2 isolation address (default gateway + 1 das.isolationaddress) will be properly documented.
Thanks for pointing these out, much appreciated!
Duncan, as always I appreciate all of your articles.
A couple questions. First off, how does this recommendation relate to the new HA feature in vSphere 5, storage heartbeat? Wouldn’t this new feature remove the recommendation of needing a second isolation address entirely?
Also, in almost all VMware environments I’ve been involved with, all hosts are multi-homed, redundantly connected to a pair of stacked switches or separate blades. With this setup I have not been creating a second isolation address because if an individual switch goes out, all hosts can communicate on the other switch in the stack. If a single port goes out, that particular host would use the other stacked switch. In this case, am I properly protecting the environment by only having one isolation address due to the sheer redundancy being implemented? There’s an assumption that the gateway is located on the stacked switches or on a router with full network redundancy back to it (ie; multiple interfaces into separate blades/switches).
I would assume that only when you have single points of failures in the networking that the secondary isolation address is significant?
Do a search on my blog, datastore heartbeats don’t prevent isolation but help determining the state of a host instead.
Thanks Duncan, not sure how I missed your post on it. I guess I keep on, keeping on, with designing for host network isolation whether it’s network redundancy or isolation address redundancy (multiple isolation addresses).
Datastore Heartbeating and preventing Isolation Events?:
http://www.yellow-bricks.com/2011/10/03/datastore-heartbeating-and-preventing-isolation-events/
The KB article http://kb.vmware.com/kb/1002117 says that you should increase the das.failuredetectiontime when having multiple das.isolationaddress specified (for the reason of allowing more time to ping the different addresses), but when we discussed this about a year ago the conclusion was that this was not necessary and really did not improve anything.
http://rickardnobel.se/archives/441
The recommendation is still in the KB, so do you know what the official status of this is?
I will get the KB article updated. That info is outdated. Info I provided is correct.
Regarding this statement:
Many seem to be under the impression that this happens sequential, but that is not the case!
Personally, I was under this impression based on this guide:
http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-501-availability-guide.pdf
Which states:
Specifying too many addresses makes isolation detection take too long
The statement that additional addresses increases the detection timout implies these tests are sequential, and is probably the source of that confusion – although I have independantly confirmed your advise here is correct.