Do I need a 2nd Service Console?

[bdoellefeld]

Reading through a few posts today put some doubts in my mind about how I have my service console setup along with HA. This on a 3 host cluster. Currently I have only one service console connection on vswitch0. vswitch0 is associated to 2 separate pNICs connected to separate switches (same VLAN) in failover. Obviously I only want HA to trigger if I lose both my primary and standby connection. vswitch1 is connected to an isolated switch with only the 3 hosts attached. If this doesn't look right, does anyone have suggestions? thanks!

Message was edited by:

bdoellefeld - changed generic term "service console" to "service console connection" for clarity.

[langonej]

HA will only kick in if vmnic0 AND vmnic2 fail in your scenario.

If vmnic0 fails but vmnic2 successfully becomes the active, you will not lose enough packets to trigger HA.

[esiebert7625 · Accepted solution]

You might want to check out this post...

Second Service Console NIC - http://www.vmware.com/community/thread.jspa?messageID=536518&#536518

[VirtualNoitall]

Looks good to me. Two pnics on your vswitch0 will give you the redundancy you are looking for. HA will only trigger if the heartbeat fails and with two nics on two switches you have done pretty much all you can.

[bdoellefeld]

Thank you for helping put my mind at ease.

[nitinsahi]

Well, I think the question for 2nd service console is still unanswered.

As far as my skills click we need to have another(4th) physical NIC where we can configure backup for Service Console.

Rest Physical NIC 1 and 2 are teamed up or bonded nicely for HA to actually happen.

In this scenario , I'm not sure if we can arrange service console backup somewhere by playing with these nic's....any suggestion ??

Thanks

Nitin

[langonej]

I personally don't see a need for a second vswif (Service Console network interface).

If you have setup your VI3 server correctly in the first place, your should have a virtual switch with two physical NICs going to separate switching networks (there lies your redundancy). Your Service Console port group is in this virtual switch. Your vswif (Service Console network interface) is placed in this port group.

What else do you need?

If it's a blade (e.g. HP) make sure that one physical switch is on board and the other is mezzanine (vmnic0 and vmnic2, for example).

[nitinsahi]

Well, I was looking for Service console's redundancy. What say ??

Nitin

[sbeaver]

YOu have that with the dual nic bond. No need to create another vswitch with another service console port group

[Erik_Zandboer]

Agree with uh... well... about all repliers that you don't need a second vSwitch.

However, I should consider (if you have not already) to connect both physical SC nics to different switches. Because with a single switch, if the switch fails, all ESX nodes will bring down their VMs.

[mreferre]

As far as my skills click we need to have another(4th) physical NIC where

we can configure backup for Service Console.

Are you worried about bandwidth or high-availability? If you are worried about HA then as all other posters have said you already have that in the picture outlined above. If you are concerned about bandwidth than consider that management through the Service Console link is not meant to be very network intensive so that you can share it for other duties such as backup etc etc....

I have this feeling that there is a trend among many user to super-spec their config in terms of NIC I/O. While it's true that a NIC is not very expensive ...... why would you anyway configure every ESX with 12 ports (and 12 cables and 12 pSwitch ports etc etc) when you can do with 2 or 4 ?

Anyway.....

Massimo.

[Erik_Zandboer]

I am with king. You can setup a very decent connectivity plan using a limited number of NICS.

You could even decide to use a single VSWITCH, put all of your NICs in team on that Vswitch, use a trunk with VLANs, and set a prefered path for each functionality (setting the other NICs to standby for each portgroup).

This works very well, bandwidth is guaranteed with all NICs "up". As one or more NICs become unavailable, the system starts to share more and more functinality over the remaining NICs, but since this can beconsidered an errornous condition its acceptable for most clients. It is very flexible!

[Ken_Cline]

set a prefered path for each functionality (setting the other

NICs to standby for each portgroup).

Why go to all that trouble? There are very few situations where I've seen the need to configure active/standby pNICs - and most of those could be attributed to paranoia

I'm a big fan of keeping things as simple as possible - if you don't have[/u] to change a default behavior, then DON'T!

[Erik_Zandboer]

Ken, I agree on the KISS principle. However, what I sketched was using a SINGLE vSwitch (KISS), and then specifying a preferred path for each fuctionality (a little less KISS). It is no more complex than having several vSwitches without preferred paths. It is simply a different approach, and I have seen this work very well when there are only a limited number of NICs in ESX hosts.

And yes, you DO want to set preferred paths in this "single-vSwitch" setup. Simply because you want to avoid having a backup running through the service console, and performing a VMotion, and having your 10.000+ users FTP site all running through the same physical Gbit NIC (which COULD happen if you do not set preferred paths).

[Ken_Cline]

Thanks Erik. Your approach does make sense...with the explanation. And yes, I typically do two vSwitches, which accomplishes essentially the same thing - nothing wrong with either approach (that's the beauty of this stuff!)

[Erik_Zandboer]

In Holland we have a saying... There are many roads that lead to Rome... 😛

[mreferre]

Sorry Erik but that would be OUR! saying .... not yours!!

Massimo.

[admin]

Not exactly off topic here but ...

We're having the vmkernel hang on boot here (it comes up in debug mode). It looks like their config's similar to the one above.

Is there any issue with the VMKernel switch being named something besides VMKernel ? (i.e. "vmotion") ?

Is there any reason to separate the service console from the vmkernel? Thats how its done in the example above. I'm used to ESX 2.5 so I don't understand the reason for doing this.

Incidentally enough that example above is also how someone else set it up here.

[Erik_Zandboer]

Hi,

There is no reason whatsoever that a different vSwitch name could induce a vmkernel hang. I change the name to VMotion all the time (it is clearer for customers if they don't use IP-storage I think).

Separating the service console and the VMkernel is very usefull. When using IP storage, you might even use two VMkernel networks. One to perform VMotion, the other to perform IP storage connections. This is because you don't want a VMotion (which bursts heavily on the network) to have impact on IP storage performance.

The same goes for the service console: You might be running backups through the SC (ESXranger and such). You might want to avoid VMotion impacting performance here (especially when you use DRS which can start VMotions automagically).

I often use a single vswitch for both service console and VMotion, and create a team of two pNICs to conect to it. Using that setup you could also set preferred paths for the SC and VMotion, so that each functionality uses a different pNIC by default (until one of the pNIC links fails).