The Service Console: Part 2 – Redundancy

Now that we’ve discussed what the service console is and what it does for you. We’ll talk about making it redundant, why Service Console Redundancy is important, and some ways of going about that. Another “Pretty Big Task” but one worth sticking around for (at least for the cookies at the end).

The Department of Redundancy Department

What is redundancy? I think perhaps that redundantly describing redundancy in an article on making redundant things redundant would be… well, redundant. Enough of that! In the context of the Service Console, redundancy is simply a means to provide continuous access to the Service Console and it’s services. A big task considering everything that was covered in Part 1 (link).

So why is this important? Lets cover it on an item by item basis from part 1:

Communications: Losing communication with your ESX host may not seem to be that big a deal. After all, your Virtual Machines will continue to run, wont they? If you’ve separated your Virtual Machine network from your Service Console network, then they (the VM’s that is) are still communicating with the remainder of the network. So why is losing communication with the Service Console bad? Well, you lose connectivity to the following:

• Command Line Interface (CLI)
• SSH Access
• Web Management (this includes SOAP, and the other various API’s)
• Using the VMware Infrastructure Client
• Communication with Virtual Center

So in some environments this may not be an issue, but alas, one has to manage and monitor the ESX host, so already you need… well all of them. Further, if you have this host in a cluster of ESX hosts this will very well likely break High Availability. What? My HA? My Precious HA? You mean I spent all of that money on HA licensing, and something as simple as service console communication can take that out? Look again at the last bullet point there, go ahead, I’ll wait. So knowing that the service console is responsible for communicating with virtual center, and knowing that the Virtual Center checks for HA, and communicates HA decisions back to ESX, it then becomes critical that you have redundant service consoles. At least if you don’t want your VM’s rebooting for no reason.

How do I make it redundant?

There are as many was to do this as there are episodes of Seinfeld. Really.  That said, we’ll go over a few of those ways.

Redundant NICS

That’s right, as simple as that.  On your Service Console vSwitch, just add a second  NIC and away you go. What this does is setup a fail over pair, and open up the opportunity for load balancing, should you also have VM traffic flowing over that NIC.

Redundant vSwitches

This one takes a bit more doing, as it requires two (or more) networks, and at least two NICs as well. Having two vSwitches, with one separate for management is a best practice anyways.  To implement redundant SC’s in this setup, is to add a Service Console to both your management vSwitch and your VM vSwitch.  While you may be mixing traffic in this case (management with the VM’s) your risk should be mitigated by the ESX firewall and strong user/passwords, as this service console would only be used in emergencies. Please note, this can be any network that supports VM traffic, so if you have a network on your ESX host(s) dedicated to Backup, you can likely put the additional Service Console there.

Redundant NICS with Redundant vSwitches

Ok, so this one was to be a neat little pain in the rear, really.  It’ basically combines both of the above, by throwing redundant nic’s onto the redundant vSwitches.  While we’re at it, to make it more redundant, lets throw in redundant Physical switches on the uplink end as well.  🙂

For further discussion on Service Console Redundancy, I’d like to point you at yellow-bricks. (Note: We’ve been talking about option 3 for most of ours)