Choosing Network Failover Options with VMware and Cisco UCS- Part 2

Part 1 of this post covered the built-in redundancy of the Cisco UCS.

How the UCS failover works with VMware’s redundancy is the key to realizing the full potential of these two technologies. As we move into these second and third virtualization layers as presented by the UCS, monitoring and control become the issues. One of the past problems was MAC addressing and failover. These seem to be solved in the UCS-VMware chain and I’m not going to get into that here. There are other articles out there about passing MAC address through the infrastructures. In the following scenarios, MAC addressing is not a problem.

The UCS configures Fabric Failover and VMware uses NIC failover. We know that each vNIC a VMware host uses is connected to dual Fabric Extenders and Fabric Interconnects and therefore has two connections to the northbound LAN. We also know that the UCS monitors its virtual network and will be proactive in determining failures and failing over to the alternate fabric.

Option 1: UCS and VMware failover is configured, which negates VMware

In this case, the UCS will initiate fabric failover if a FE or FI fails. It is a layer above VMware, so there really is no way for a VMware NIC to fail. We may get notice if email alerts on the UCS have been configured correctly. In the VMware world everything is green and running fine. Since all the VMware vNICs have two connections (east and west bound Fabric Extenders), VMware will not see a failure since all vNICs have an active network connection. This shouldn’t effect virtual port or MAC addressing because the FE’s and FI’s basically pass traffic and are not switches; all that has changed is the path to the Fabric Interconnects.

Option 2: VMware is configured, UCS failover is disabled

This may look, on the surface, as wasting a feature on a very expensive Cisco purchase, but it really isn’t. One of the great things about the UCS architecture is the built in physical redundancy. If we let VMware detect failures and switch paths we will have a better insight into what is going on in the virtual environment. Now, I’m not using a Nexus 1000v or VMware’s NSX. I’m talking about a straight forward physical layer 2 and 3 network northbound of the Cisco Fabric Interconnects.

To take advantage of the Cisco redundancy in VMware, each VMware host will need at least two vNICs per virtual switch. One vNIC will connect to Fabric A and one to Fabric B. These configurations are done via the Cisco UCSM, the java based Manager.

vNIC Template

In the UCSM, navigate to the LAN tab. Scroll down to Policies–>root–>NIC Templates. From here, choose your vNIC and the fabric it attaches to.

vNIC Template 2

You’ll want to uncheck the “Enable Failover” option, since we have one VMware vNIC on each Fabric link. This setup allows VMware to monitor the connections and make changes based on availability. The advantage to not using dual failover mechanisms is broken down to visibility and monitoring.

Advertisements


Categories: Cisco, VMware

Tags: , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Brad Hedlund

stuff and nonsense

MyVirtuaLife.Net

Every cloud has a silver lining.

Live Virtually

A Storage and Virtualization Blog

Virtualization Team

VMware ESX/ESXi - ESX server - Virtualization - vCloud Director, tutorials, how-to, video

www.hypervizor.com/

Just another WordPress.com site

VirtualKenneth's Blog - hqVirtual | hire quality

Virtualization Blog focused on VMware Environments

Virtu-Al.Net

Virtually everything is POSHable

Gabes Virtual World

Your P.I. on virtualization

Yellow Bricks

by Duncan Epping

Wahl Network

Technical Solutions for Technical People

Joking's Blog

Phoenix-based IT guy with too much to say...

%d bloggers like this: