VMware vSphere

 View Only
  • 1.  Microsoft NLB cluster

    Posted Sep 24, 2012 10:01 PM

    Is anyone here running a Microsoft NLB cluster in ESXi?


    We want to load balance a web site with two virtual servers, using Microsoft NLB.

    I have seen these articles. so it looks like Multicast is the way:

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

    http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1006558

    I am interested to know how many NICs you have assigned to each virtual machine? How did you set them up, both NICs on the same subnet with regards to IP addressing, with the 2nd NIC hosting the virtual load balanced IP?

    Thanks in advance



  • 2.  RE: Microsoft NLB cluster

    Posted Sep 24, 2012 10:39 PM

    Hi,

    I have plenty of environments running this one.

    One NIC per VM, setup with multicast NLB, IP addressing like:

    VM 1: 10.0.0.2

    VM 2: 10.0.0.3

    NLB IP: 10.0.0.4

    Make sure you have a physical switch that supports static MAC addresses and define them accordingly.



  • 3.  RE: Microsoft NLB cluster

    Posted Sep 24, 2012 10:54 PM

    Thanks for replying.

    I have found quite a few articles that mention using 2 NICs ... is there any benefit to using 2?

    I'm trying to find something around best practice on this setup, do you have any URLs or official VMware / Microsoft docs saying use 1 NIC or 2 NICs?


    Thanks



  • 4.  RE: Microsoft NLB cluster

    Posted Sep 24, 2012 11:03 PM

    I doubt you'll find much of a VMware paper on it, although I could be wrong. It's a Microsoft technology that integrates seamlessly into the guest OS, and doesn't really involve VMware.

    The "2 NICs" situation is somewhat misleading. If you use Unicast mode, you must use a dedicated NLB NIC, and therefore the guests require a "normal" NIC. This is because a Unicast NLB NIC cannot talk to another Unicast NLB NIC, due to the basic network principle of how ARP works. Accordingly, Unicast configuration requires two NICs, so that the servers can heartbeat to each other.

    I don't see the point - Multicast NLB "just works".



  • 5.  RE: Microsoft NLB cluster

    Posted Sep 24, 2012 11:35 PM

    A further question, have you disabled the "Notify switches" option in the NIC teaming? Or did you create a separate port group for the NLB machines and disable it on there as per this: http://www.vankeyenberg.be/?p=119



  • 6.  RE: Microsoft NLB cluster

    Posted Sep 24, 2012 11:48 PM

    GlennL10 wrote:

    A further question, have you disabled the "Notify switches" option in the NIC teaming? Or did you create a separate port group for the NLB machines and disable it on there as per this: http://www.vankeyenberg.be/?p=119

    This looks like some sort of workaround for avoiding the Microsoft standard implementation I referred to earlier - set the MAC addresses on your switch port. You don't have some sort of managed switch don't you?

    What he said isn't really true, preventing a switch learning the MAC address isn't really a goal on any existing implementation. Refer to Cisco's guide:

    http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml



  • 7.  RE: Microsoft NLB cluster

    Posted Sep 24, 2012 11:53 PM

    Yes we have switches that will do the static MAC address.


    Did you disable that option or do you have it enabled? I'm asking as I'm seeing conflicting statements on that.



  • 8.  RE: Microsoft NLB cluster

    Posted Sep 25, 2012 12:11 AM

    GlennL10 wrote:


    Did you disable that option or do you have it enabled? I'm asking as I'm seeing conflicting statements on that.

    Hi,

    I've probably done two dozen deployments without ever thinking about it. So the answer would be enabled (default).

    Again, the article you found only refers to a workaround for people who, for whatever reason, can't follow the standard best practise of configuring a physical switch properly.