Main Area and Open Discussion > General Software Discussion

NLB and Load Balancing

<< < (2/2)

x16wda:
We implemented Microsoft's NLB freebie for an Exchange implementation a year or so ago.  The company wanted redundancy so we spun up two CAS servers with NLB in front (plus two pairs of mailbox servers in a DAG, but NLB is irrelevant there).  It's free, but is very basic in that it does not guarantee session persistence to a particular node.  A lot of applications are OK with that, others aren't.  A few years back we put a Big IP box up in front of a web app because the application vendor insisted on load balancing and stated the application needed the session persistence.

It sounds like you have a front end box (the specialized switch?) to do the load balancing, hopefully it'll handle that.  Should make troubleshooting a little easier if the client connection is sticking around on one machine.

wraith808:
Yes... I guess.  At least, they said that if we were connecting to SomeServerCluster with n number of servers, if we needed to test a particular server, we could connect to SomeServerCluster-onlyserver1 and guarantee what we're connecting to.  But yeah... they said something about it doesn't know the state, so can't guarantee what is being connected to- it's largely round robin and based on availability than truly load balanced.  And they did mention that bit about session persistence in relation to DCOM, which seems a bit scary considering how DCOM works.  But when you use a 16 year old technology (I really wish we could deprecate that) you have to be willing to deal with/expect a few scary moments...

Stoic Joker:
Yoikes! That sounds more than a little outside my area of expertise or experience. I doubt I could do more than toss out a few generalities about load balancing on that one as given. ;D

Stoic? You maybe wanna tackle it? :)
-40hz (November 14, 2013, 02:13 PM)
--- End quote ---

Zoiks! That one is out of my range as well. IIRC everything session wise pivoted on the quorum drive so it would be available to the next machine as/if the load shifted due to a spike or outage. But specifics regarding how to get legacy apps to play nice in that environment I'd be afraid to guess. The Quorum drive sits on the SAN and is the session/connection holding (center of the star basically) area for the front line and backend systems.

NLB over simplified is just an isolated IP network between backend systems that handles only heartbeat packets allowing servers A, B, & C to know if one of them goes down, comes back up, or gets overloaded so they can respond accordingly. The response is/would be to either pluck or hand off some of the machine X session workload which is pooled in the quorum.

Sorry wraith, that's all I got.

wraith808:
Well thanks for the insight in any case :)  Hopefully it won't be an issue.  :-\

Navigation

[0] Message Index

[*] Previous page