Load Balancer design options

As I visit companies, I run into many that are doing different designs when it comes to leveraging load balancers. I’m not a network engineer and there is just way too much information to present in one article, but here are some thoughts at a high level design I’d like to share.

TCP ports 80/443. In Exchange 2013, we leverage Outlook Anywhere to assist in minimizing disconnects and provide greater up time with access to the Exchange backend environment. Many people are familiar with these ports and leverage LB’s for Exchange and other web based applications.

TCP port 25 – SMTP. As applications are developed, sometimes coders use any SMTP relay server they can find and they simply just see which Exchange server their Outlook is connected to, and low and behold, it may also allow relay. They then hardcode the conical name and/or IP address into their code. Guess what happens when that server gets upgraded, or simply goes down? This is where an LB with a generic conical name (SMTP.contoso.com) and an IP that doesn’t need to change comes in handy. The downside is, the Exchange servers no longer see the sender specifically in the header information, but this setting depends on how you configure the LB. At least the LB logs the information.

TCP port 389 – LDAP. What about applications that request LDAP information? Usually application developers once again use their workstation and simply look up which Domain Controller (DC) they are logged into, subsequently, they usually then hardcode the conical name and/or IP into their application code. Then when that DC gets upgraded, guess what stops working? How about telling your development team to always use: LDAP.contoso.com with a single IP address from now on? Set that IP to an LB, and viola, no more apps break when you upgrade DC’s. (I see it all the time; a DC with multiple IP’s on the NIC, or a DNS entry from the old DC name that points to a new DC.)

UDP port 53 – DNS. Yep, you can VIP (Virtual IP) DNS. I’ve run into two Active Directory RAP as a Service engagements with companies that we flag where the DC’s only have one DNS search order IP listed. Usually this is an issue; however, with an LB involved, this solves many upgrade concerns. How many of you changed the primary/secondary DNS search order IP’s in your DHCP scopes? How about just using one IP for all DNS searches from here on out? Sure there are considerations on physical site locations, etc., but something to think about.

Closing thoughts

But what’s wrong with DNS round robin? Nothing, other than there is no intelligence behind it. If you use DNS round robin for servers A, B, and C, the network packets go to servers A, B, and C; and when server A goes offline, the network packets still try to go to servers A, B, and C. It’s nice to have logic somewhere that says server A is offline, and to be able to stop sending network packets to it.

So there you go, more than just one reason to purchase an LB. Sure your Exchange engineers currently need one, but some companies don’t continue the thoughts into how else they can leverage LB’s and be a more advanced company with less changes to deal with over the next 5, 10, 20, or more years. How nice it would be to have less to modify.

Certainly this implementation can be complex: more moving parts, extra engineers involved, added pieces to troubleshoot, but the payoff may be worth the additional layers in the long run.