My love/hate relationship with Cisco Nexus 1000v Part 1

Over a year ago, we deployed Cisco Nexus 1000v virtual switching into our VMware cluster. I love some of the features it offers, but the problems we have run across still haunt me.

The first time I deployed into our environment, it was into a virtualized vCenter instance. We were running it on a separate SQL server VM in the cluster. This was all fine and dandy - until we had a major power outage that took the entire cluster offline. The problem with this scenario is that it leads to recursive and cascading failures if not carefully designed. Even if it is carefully designed, it can still make for an unpleasant scenario. Think this through with me. In the event of a complete power outage, what is the recovery process with a typical virtualized vCenter installation? I believe it looks something like this:
1) Power the hosts back up
2) Power up AD server (physical)
3) Locate and power up SQL server (unless this is on-box with vCenter)
4) Locate the vCenter VM and boot it up

What about with Nexus 1000v?
1) Power the hosts back up
2) Power up AD server (physical)
3) Locate and power up SQL server (unless this is on-box with vCenter)
4) Locate the vCenter VM and boot it up
5) Locate the VSMs and power them up

But wait, what if your standard server port profiles aren't configured with System VLANs to match how the servers are configured? That potentially means that you can power up your AD & SQL servers, but they will not have network connectivity until the VSMs are up - the VEMs (the hosts) will keep the VM network ports in a blocked status until VSM connectivity can be restored.

Ok, so you put your SQL server into a subnet that is living on a System VLAN. Then you can power them up, power up vCenter and the VSMs (which should both be on System VLANs), then the VEMs should come online and restore connectivity to the remainder of your VMs.

However, what is the downside of putting VMs on the System VLAN? If I understand correctly, that means that traffic will bypass any ACLs, QoS configuration, and potentially other features if the VSMs become unreachable. In my book, this isn't a particularly appealing solution either.

Another option is to go ahead and run SQL server on-box with your vCenter VM. I think this is certainly a better option than putting multiple servers on System VLANs. Or, you can do what we did: create a physical vCenter server with on-box SQL server. Then, your recovery process is:
1) Power up vCenter server & AD server (both physicals)
2) Power hosts back up
3) Power up VSM VMs

Sure, it isn't really any shorter in the long run, but it's a heck of a lot easier to document in case you want someone other than yourself to be able to start things back up again.

Comments

Post a Comment

Popular posts from this blog

Installing Cisco CallManager 4.1(3) on VMware in 2025

Getting Creative Again – and Reinstalling 2005 in 2025 It’s certainly been a while—and a lot has changed in my life. But I’ve been wanting to get back into more creative projects, especially the kind that mix creativity with something deeply technical. This one definitely checks both boxes. Get ready to Collaborate like it's 2005! Please check out my YouTube video . Installing Cisco CallManager 4.1(3) on VMware in 2025 When I first had this idea, I figured it would be a quick weekend project—knock it out in a couple of days and move on. Many months later, I can finally call it a success. The Classic Method (That No Longer Works) Historically, you'd follow a guide like this one to install CallManager 4.x. It relied on: Installing vanilla Windows 2000 Server Modifying the registry to bypass hardware checks Applying Cisco OS update files like win-OS-Upgrade-K9.2000-2-6sr4.exe But in 2025? These Cisco OS update files have vanished from the internet. Despite...
Read more

Why is Cisco Licensing so terrible?

Well, it's been a while since I've written anything here. Since my last post, a lot of things have happened. One of those things perfectly illustrates a poorly thought out aspect of Cisco Licensing, especially for Unified Communications running on VMware. I've believed forever that using the Primary DNS and NTP servers as part of the License MAC generation was a bad idea, but I never really thought about how unpleasant it could be. I recently traveled to Brazil to deploy our UC-on-UCS environment there, and built out all of the servers. When I first arrived onsite, I contacted our systems team and requested they send me the DNS/NTP information that I would need to use for the build (and licensing). They sent me the information without any hassle, which was a huge bonus. Fast forward, installation is done, I'm back home, and I set up RTMT. Low and behold, I'm getting alarms that the Primary NTP server is inaccessible. Hmmm, that's odd, but sure enough, I can...
Read more

Installing Linux on a Cisco Content Engine

Concept I originally thought about this after reading this article , and soon I set off to install Linux on my Cisco CE560. My first attempts to install using Sarge failed, since Etch is now the current version, and Sarge is now " oldstable ". I was also unable to successfully boot the floppy install of Etch for some reason. Using some of the steps from the aforementioned article, I was able to successfully install Mandrake 10.1 on my content engine. Hardware The Cisco CE560 has the following hardware characteristics : Intel Pentium III 600 MHz 2x512 MB SDRAM Symbios sym53c8xx SCSI controller 2x36GB 80-pin Ultra2 LVD SCSI Hard Drives Asiliant 69000 Video Adapter with 16-pin output header (pinout unknown) 2xIntel 82559 Ethernet Adapters (Linux driver is e100) RJ-45 Serial Console port at 9600,8,N,1 Note: Can only boot from floppy or SCSI! Preparation In order to pull this off, I used the following items: Cisco Console cable A laptop with Windows using Hyperterminal Floppy Dri...
Read more