Fault Tolerance switch port guidelines

[vmproteau]

I am configuring our Lab to test Fault Tolerance. I plan on using a sperate isolated FT vSwitch and seperate FT VLAN. Are there specific guidelines for siwthc port configutation settings I can give to my Network group. I just want to make sure the physical ports are idelly configured before I begin testing.

[peterdabr]

I would make sure that the following is in place:

-no traffic shaping policies in place

-nic team for vswitch's uplink (etherchanneled on physical switch if both nics in a team are uplinked to the same physical switch)

-load-based teaming ( if you have vCenter 4.1 and ESX(i) 4.1)

-Network IO Control with with higher shares for FT traffic (only vCenter 4.1 and ESX(i) 4.1)

[vmproteau]

We will have 2 pNICs for the FT vSwitch and won't do traffic shaping. On the other 2...

Load based teaming....exactly what are you referring to here. The vSwitch will be using a teaming policy is there something additonal this refers to?

Network I/O control...this will be an isolated vSwitch only used for Fault Tolerace so I assume this won't be necessary?

I appreciate the comments but my initial questions was more specfic to the physical switch port configuration. Are there any best practices or guidlines for Cisco switch port config for these FT ports?

[peterdabr · Accepted solution]

I didn't know your plan was to use dedicated vSwitch only for FT traffic and nothing else.

As a result, I recommended using "Load-based teaming" (new feature in 4.1) for better traffic distribution between pNICs on vswitch as well as Network I/O contol for partitioning the link between different types of traffic. But you are right, as long as the vswitch is dedicated for FT, no need to use it.

As far as Cisco switch port config, if you run both pNICs, to the same switch, you can use etherchannel, although single 1Gb/s link is more than enough for FT traffic. Also, I recommend enabling portfast on involved ports to avoid interruption when other devices get added on the network, triggering spanning-tree protocol recalucations.

For traffic to

be distributed in nic teaming, configure the virtual switch through which the logging

traffic flows to use the Route based on IP hash policy. This policy uses

both source and destination IP addresses of the traffic flow to

determine the uplink. FT pairs between different ESX hosts use more than

one source and destination address pair for the FT logging.

To use the Route based on IP hash policy, the ports on the physical switch must be configured in etherchannel mode.

[vmproteau]

Great thanks....we do go to seperate physical Cisco siwtches so it sounds like the same configuration as our other vSwitches. Thanks for the note on "Route based on IP hash policy" as we use the default "Route based on the originating port ID" for other switches. I assume the policy recommendation is the same even when going to 2 physical switches.

Excuse my networking ignorance but, this note "To use the Route based on IP hash policy, the ports on the physical switch must be configured in etherchannel mode". Is this something I need to be concerned with if I am going to 2 seperate physical switches?

[peterdabr]

Assuming you've configured FT for multiple VMs on host A in ESX cluster, using "Route based on the orginal port ID" with nic teaming will always use only one nic in a NIC teamed configuration, therefore no benefit here. For NIC teaming with physical link aggregation (etherchannel, LACP, etc) vSwitch must be set to "Route based on IP hash".

In your case of using two physical switches for the same nic teaming, you will still benefit greatly by using this policy as host A could communicate FT traffic to other hosts in the cluster using different pNICs in nic team, based on the srcIP<->targetIP hash, which would be different for hostA<->hostB, hostA-hostC, etc...