DNS settings for Fault Tolerance

[BenArmour]

As I understand it, FT recommends having two service consoles on your ESX hosts with seperate IP addresses. This is fine, but how do you deal with this in DNS and avoid a round robin situation?

ben

[Troy_Clavell]

I don't believe so, you should have atleast 3 NICs, one dedicated to FT

See below blog for some great insight

http://communities.vmware.com/blogs/vmroyale/2009/05/18/vmware-fault-tolerance-requirements-and-limi...

[BenArmour]

I have read that blog before. My concern lies with how you create you DNS entries for the host. If I make an entry for one host name with two IP addresses, they will round robin. If one of console addresses becomes unavailable, DNS will not intelligently discover the failure, and could still end up resolving the failed address.

I know this won't prevent FT from functioning correctly, but if you need to connect to that host, you'd have to use the IP address for the online console instead of the hostname.

Maybe I'm chasing my tail on this one. I don't know.

ben

[Gleed]

There is no FT requirement for multiple DNS entries.

It is an HA best practice to have a redundant service console/management network.  This can be done with NIC teaming or by creating a secondary management network.  I've always used NIC teaming.

In addition to the need for a redundant service console/management network for HA heartbeat traffic, FT also requires a dedicated logging network, which to avoid any SPOFs should also have redundancy (again I recommend NIC teaming).  The FT logging NICs will need to have their own IPs, but I don't believe there is a requirement that they be in DNS.

Keep in mind the FT logging network should be dedicated to FT (i.e. separate from the vMotion and management traffic).

Have you read through the vSphere Availability Guide?  Read the sections on HA as well as FT.  It covers the network requirements in good detail and even includes an example.

Regards,

-Kyle

[MillardJK]

I think you may misunderstand the FT suggestion, and because "Fault Tolerance" is actually a VM feature, it may not be clear which "FT" you're attempting to address.

From a host fault-tolerance standpoint, you don't actually need multiple networks for console access; you're looking to have multiple paths into the host for admin access in the event of NIC failure. To accomplish that, make sure that the vSwitch that hosts the service console port has at least 2 active physical adapters allocated to it.

In my cluster, I don't even fool around with multiple vSwitches: we set up one, then hang all the physical adapters and port groups on it. From the host's standpoint, we get multiple, redundant access into the service console for management. Yeah, we don't have a dedicated network for management, nor for vMotion, but with limited port resources in both the host and the switch it uplinks into, it's the best balance between utilization and redundancy.

At some point, I may break out the VMkernel ports for vmotion and storage to their own dedicated vSwitch & physical adapters (we're currently using FC for storage, and the data needs of even our busiest hosts don't cause VMotion any problems), but that's currently not warranted at this time.