The other articles in this series are:
- Introduction to Load Balancing for Exchange and Other Workloads
- How to Configure General Settings on the KEMP Virtual LoadMaster
- How to Configure an L7 KEMP Virtual Load Balancer (VLB) for Exchange 2013
- How to Configure an L4 KEMP Virtual Load Balancer (VLB) for Exchange 2013 (this article)
- How to Restrict Exchange Admin Center Access From the Internet Using KEMP VLB
My first article explains the basics of load balancing and how to download a free copy of KEMP Virtual Load Master for your home lab. As a refresher, here's a brief explanation of the differences between Layer 7 and Layer 4 load balancing.
When an incoming connection goes through a load balancer, the load balancer needs to NAT the connection to the real servers so that the reply comes back through the load balancer, otherwise the real servers will respond directly to the client and the session will break. For example, imagine you, Sally, and Tim are in the same room. You ask Sally a direct question, but Tim responds. You ignore Tim's response because it's out of order.
The computer above communicates with the VIP on the load balancer and expects the response to come from that same IP address. The only three ways to make this to happen are:
Layer 7 Load BalancingIn my second article I showed you how to configure the general settings for the LoadMaster. This includes configuring Ethernet settings, the Web UI, time and DNS settings, and SSL certificates. These settings are common to all types of load balancing configurations. Now I'm ready to show you how to configure the VLB as a Layer 4 load balancer for Exchange 2013. But first, I need to get some potentially confusing things out of the way.
L7 load balancing happens at the application layer. Health checks are performed on the applications (for example OWA, EWS, ActiveSync, etc.). The SSL connection must terminate on the load balancer, the content is inspected, and then re-encrypted back to the real servers. This requires that the L7 load balancer has to have an understanding of the applications being load balanced. It also usually involves some sort of persistence, such as cookie-based or source IP. Because of all this, L7 load balancing is more complex. Exchange 2010 required L7 load balancing due to the different ways that each application protocol handled persistence. Exchange 2013 does not require persistence even when using L7 load balancing.
Layer 4 Load Balancing
L4 load balancing happens at the network layer after routing is compete (Routing occurs at Layer 3). Health checks are performed on the servers, not the applications. Layer 4 load balancers do not decrypt, inspect, and re-encrypt SSL traffic. This means L4 load balancers have higher performance and are less complex, but the load balanced application must support it. Exchange 2013 CAS is designed for L4 load balancing, but also supports L7 load balancing.
When an incoming connection goes through a load balancer, the load balancer needs to NAT the connection to the real servers so that the reply comes back through the load balancer, otherwise the real servers will respond directly to the client and the session will break. For example, imagine you, Sally, and Tim are in the same room. You ask Sally a direct question, but Tim responds. You ignore Tim's response because it's out of order.
The computer above communicates with the VIP on the load balancer and expects the response to come from that same IP address. The only three ways to make this to happen are:
- Use Network Address Translation (NAT) - The incoming client traffic is sent to the real server after performing address translation, which causes server to respond back to the load balancer. The load balancer then forwards the response back to the client.
- Configure the load balancer as the Default Gateway on the real servers - This forces all outgoing traffic to external subnets back through the load balancer, but has many downsides. For example, you must size load balancer to account for all traffic for given server. While this configuration may be supported for Exchange, it isn't best practice.
- Use Direct Server Return (DSR) - DSR is a complex load balancing method that has many drawbacks, including the inability to insert cookies or do port translation. It is not supported for Exchange or Lync deployments.
Of these options, only NAT is a viable option. In an interesting choice of wording, KEMP calls this an "L7 connection" to the load balancer. KEMP verbiage is referring to actual TCP layer functionality where the KEMP load balancer accepts the client’s TCP connection and creates a new TCP connection to the server. This is required in order to perform NAT.
While the term can be confusing, and I hope that KEMP is able to change it so it isn’t so, from an Exchange perspective this is still Layer 4 load balancing. The load balancer is not decrypting SSL connections, the client connections can still be configured to be distributed evenly in round robin fashion across the CAS servers with no affinity or persistence requirement, and the traffic is not inspected by the load balancer. As a matter of fact, the SSL certificate doesn't even need to be installed on the load balancer for this to work, which makes it truly "light weight" operation when compared to L7 load balancing which results in much higher resource requirements due to SSL decryption and re-encryption. I'm going to lengths to explain this because when you see "Force L7" in the LoadMaster configuration, I want you to understand why it doesn't translate to Layer 7 load balancing in the way Microsoft refers to it.
OK, so now that's done, let's start configuring the KEMP LoadMaster for Layer 4 load balancing Exchange 2013. There are basically two options for doing this. Option 1 configures a single VIP to load balance all virtual services for all the real servers. This is useful for home lab scenarios where you have a simple consumer-grade router and can only forward all SSL traffic to one IP address. Option 2 configures a different IP address for each virtual service on the real servers.
While the term can be confusing, and I hope that KEMP is able to change it so it isn’t so, from an Exchange perspective this is still Layer 4 load balancing. The load balancer is not decrypting SSL connections, the client connections can still be configured to be distributed evenly in round robin fashion across the CAS servers with no affinity or persistence requirement, and the traffic is not inspected by the load balancer. As a matter of fact, the SSL certificate doesn't even need to be installed on the load balancer for this to work, which makes it truly "light weight" operation when compared to L7 load balancing which results in much higher resource requirements due to SSL decryption and re-encryption. I'm going to lengths to explain this because when you see "Force L7" in the LoadMaster configuration, I want you to understand why it doesn't translate to Layer 7 load balancing in the way Microsoft refers to it.
OK, so now that's done, let's start configuring the KEMP LoadMaster for Layer 4 load balancing Exchange 2013. There are basically two options for doing this. Option 1 configures a single VIP to load balance all virtual services for all the real servers. This is useful for home lab scenarios where you have a simple consumer-grade router and can only forward all SSL traffic to one IP address. Option 2 configures a different IP address for each virtual service on the real servers.
Note: Neither of these L4 options use the KEMP application templates. Those are only used in Layer 7 load balancing.
Option 1 - Use a Single VIP
Log into the LoadMaster with the bal account and navigate to Virtual Services > Add New. Enter the new virtual IP address, set the port to 443, and enter a Service Name. Then click the Add this Virtual Service button.
Under Standard Options, leave "Force L7" checked and uncheck "Transparency". Keep the default values for Persistence (None) and Scheduling Method (Round Robin).
Confirm that SSL Properties > SSL Acceleration is disabled (unchecked). Leave Advanced Properties and ESP Options with their default settings.
Expand Real Servers. Since we're doing L4 load balancing we cannot configure vSubs and you can only monitor one virtual server (OWA, ActiveSync, MAPI, etc.). In this example, I will monitor the OWA virtual server.
Enter /owa/healthcheck.htm for the URL to health check and click the Set URL button. Change the "HTTP Method" to GET and enter OK for the "Reply 200 Pattern". Then click the Set Pattern button.
Now it's time to add your real servers. Click the Add New button. Add the first real server's IP address and click the Add This Real Server button. Repeat for each of your real servers. When you're done click <-Back twice.
Now you will see the new Exchange 2013 virtual service that L4 load balances the real servers. Ignore the fact that it shows L7 for the Layer, as this is really only the connection type (see explanation above). Note that the SSL certificate is installed on the real servers, not the load balancer.
That's all there is for this configuration. As noted earlier, we're only monitoring the OWA virtual server on the real servers for health checks. If another virtual server, say ActiveSync, goes offline on one of the real servers the load balancer will still direct traffic to it. Likewise, if the OWA virtual server goes offline on one of the real servers that server will be marked as down and no traffic will be directed to it, even though other virtual servers may be healthy.
Option 2 - Use Separate VIPs for Each Virtual Server
This option requires nine separate VIPs on the load balancer, one for each Exchange 2013 virtual server. It also requires nine different names on the SAN certificate or use of a wildcard cert.
Log into the LoadMaster with the bal account and navigate to Virtual Services > Add New. Enter a new virtual IP address, set the port to 443, and enter a Service Name (i.e, EX2013 ActiveSync). Then click the Add this Virtual Service button.
Under Standard Options, leave "Force L7" checked and uncheck "Transparency". Keep the default values for Persistence (None) and Scheduling Method (Round Robin).
Confirm that SSL Properties > SSL Acceleration is disabled (unchecked). Leave Advanced Properties and ESP Options with their default settings.
Expand Real Servers. Enter /microsoft-server-activesync/healthcheck.htm for the URL to health check and click the Set URL button. Change the "HTTP Method" to GET. Enter OK for the "Reply 200 Pattern" and click the Set Pattern button.
Now it's time to add your real servers. Click the Add New button. Add the first real server's IP address and click the Add This Real Server button. Repeat for each of your real servers. When you're done click <-Back twice.
Repeat for each Exchange 2013 virtual server: Autodiscover, ECP, EWS, MAPI, OAB, OWA, PowerShell, and RPC. Nine virtual services in all.
Thankfully you can make this easier on yourself by duplicating VIPs. Select a Virtual Service in View/Modify Services and click the Duplicate VIP button. Enter the new virtual IP address and click the Duplicate VIP button. Change the "Service Name" and click the Set NickName button, then change the health check URL and click the Set URL button. Rinse and repeat for each virtual server.
Note that the SSL certificate is installed on the real servers, not the load balancer.
With this configuration the load balancer will direct traffic to any available virtual server on any real server. The downside to this approach is that it requires your router to send traffic for each namespace to a different VIP and you have many more names to manage on your SSL certificates.
This concludes the Layer 4 setup options for Exchange 2013. My final article in the series will explain how to restrict Exchange Admin Center access from the Internet.
No comments:
Post a Comment
Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.