NLB Cluster Address

earweed

I was just going over the Configuring Clusters Trainsignal video. The question I have is that you assign an address to the cluster, which is different from any of the servers in the cluster, what device (network) actually has that address? Is it the first server you assign to the cluster?
The video never quite explained that (Hopefully I'm not just being dense)

By the way the Trainsignal video, while complemanting the MS Press book somewhat, doesn't cover configuring failover clusters but just kind of explains how they function and why they're used.

Essendon

That address is the cluster's address, it's not the first server's address. Quick example,

node1.domain.local = 10.10.10.11
node2.domain.local = 10.10.10.12
nlb.domain.local = 10.10.10.13 (this is the cluster's address and host name). It doesnt belong to a physical machine. Also, add a host record to DNS for the cluster.

Claymoore

Every host has that IP and MAC, which is how every host can respond to requests. NLB implements it differently depending on whether you are using Unicast or Multicast mode.

Unicast will cause the switch to see responses from the same MAC on different ports and essentially flood the switch and turn it into a hub. I only use it if I am working with virtual machines on the same physical host so I am only flooding the virtual switch. You will also need multiple adapters in the NLB members so that you can connect to them on their own IP address to manage those servers.

Multicast has its own challenges, the biggest of which is the network team itself. (I have only met one team who understood multicasting and embraced my request to implement it for Windows 7 deployments.) You can statically map the multicast MAC to the physical ports on the switch or implement IGMP snooping with NLB multicast in IGMP mode and let everything work itself out automagically.

Best way to learn it is to work with NLB. I first tried it with a test Sharepoint cluster and struggled with it. I finally got it working and the experience came in handy when I started working with Exchange 2007 Client Access and Hub Transport NLB implementations. My experience with MS NLB has actually made me a big fan of hardware load balancers such as a Citrix NetScaler or an f5 from Big-IP.

earweed

Thanks Claymoore, I read the Sybex book on NLB after reading MS Press and watching the Trainsignal. The Sybex book explained it much the way you did and in my opinion both MS and TS were both a big fail in this area. TS video never made a mention about Multicast/unicast or having 2 network adapters on each host.
I even did the labbing the way the TS guy did (with just 2 hosts) and it worked but still left me with questions on how. I'm going to lab it tomorrow with more hosts and set them all up with 2 network adapters to try it the right way.
I'm thinking it'll help me to take longer than a month on this test. I've already spent a week really studying and labbing first 2 chapters. 3 days of that were spent setting up Hyper-V and reading up on it and playing around with it.

it_consultant

I wonder if something else was wrong with Claymore's set up. When you do a NLB cluster you essentially set up three servers, two physical (the two physical nodes) and one virtual server; which is the cluster IP. That virtual has a MAC associated with it to prevent the switch from going haywire.

In the case of doing an NLB for a product like sharepoint, I suspect the problem comes from the nature of sharepoint itself. Its really not NLB appropriate; I would recommend using failover clustering in a one up one down config. If you are really serious about high availability you should also have Enterprise SQL clustered on top of two clustered nodes in a failover config.