One of the things that has always bugged me about blogs on “how to” is that most of them (mine included) are derived from lab environments – and while that is great, they don’t always show “real” life for a “real” environment. Close, but not really.
I recently did a project with Lync Server 2010 where DNSLB was used internally. And HLB, of course, was used for the web services – both internal and external access feed through the HLB. Most of the examples you find out there in the blogosphere show DNSLB, or they show how to setup with all the load-balancing going through the HLB. So, what I am going to demonstrate here is DNSLB for the Enterprise Pool, along with HLB for just the web services (internal and external) AND use a live environment. I have redacted the actual domain name, and I changed the actual external IP. But other than that, this is a working environment supporting all workloads.
The environment has split-dns, and uses the same name internally as externally; that is, domain.net is the AD DS name as well as the SIP domain name internally and for remote access and federation purposes.
The final architecture was two Enterprise Edition FE, with a SQL cluster. Only one Edge was used as the remote access/federation was not seen as business critical. An Archiving/Monitoring server was deployed to support IM history and compliance. A pair of Kemp VLM-100 appliances provide Load Balancing for the FE pool. All servers are virtual.
Here is what the Internal DNS and IP layout looks like. Note that two of the entries are actually pointing internal clients to the outside – specifically, internal wireless Lync clients need to be able to find and route to the external side of the Reverse Proxy.
Hardware Load Balancer
The client chose to use a pair of Kemp load balancers. They proved to be very easy to configure for High Availability. Literally, mere minutes. We used this document here for the configuration of the units into HA, and this document for the configuration of the load balancers for Lync.
Here is the main setup from member HA1.
If you read the documentation, you will be told to setup some miscellaneous options for the Layer 7 work…
Here is all you need to get a DNSLB pair of Lync Enterprise Edition pool with two members load balanced from the HLB perspective.
Each virtual server get’s these options:
The virtual server that handles the traffic from the reverse proxy (Lync external web services) needs to have a certificate – you can export the certificate from one of the Enterprise pool members. Import that into the load balancer. The aforementioned documentation does a good job of walking your through that.
Also note that for Lync Mobility, you need to have a cookie set. In Kemp parlance, the settings on the :4443 virtual server look like this:
And finally, because the traffic is coming in from the reverse proxy and is destined for the Lync Web External site on port 4443, there would be no point in checking for the service being available on port 443, so the virtual server for 4443 gets a minor change in the “checked port” section of the virtual server.
Lync Server 2010 can use DNSLB very effectively, but the Lync Web Services still need a Load Balancer. The Lync Server 2010 documentation presents all the information you need. The Kemp load balancer documentation does a great job of helping you configure their products. Interestingly, support for the products is also important; if you need help with a configuration there is nothing like a knowledgeable engineer on the phone to help you figure things out. In this case the Kemp support folks patiently helped my client discover that the original virtual server address we were using was already in use by an undocumented network device which, of course, made the HLB look like it had something wrong.
Lesson learned from that? In addition to planning out the IP space(s), the DNS (internal and external), the physical network in terms of devices and addressing needs to be nailed also.
Post a Comment