Changes

Jump to: navigation, search

Load balancing Microsoft Exchange

1,955 bytes added, 17:13, 10 February 2018
no edit summary
== Exchange 2010 ==
This guide, written by [mailto:[email protected] Jonas Back], describes load balancing of two (or more) Exchange 2010 servers, using a single-NIC load balancer; both on the inside network and Internet. The load balancer could be either a [[supported hardware|hardware appliance]], or a virtual machine. To simplify this guide, SSL offloading is not used and therefore all SSL is terminated at the Exchange servers where we have the certificates installed.
=== Network overview ===
Both Exchange servers are multi-role running CAS/MB/HT. CAS is running in a CAS Array, MBX is running in a DAG and we will also load balance internal SMTP for 3rd party applications. The Halon SR load balancer can be used in a cluster (high availability) setup, but this is not a requirement. Configuration is the same no matter if it’s a single-node or a clustered load balancer.
=== Configure static port mapping ===
Exchange 2010 uses different protocols for different clients:
{| class="wikitable"
! Client !! Protocol !! TCP ports|| Security zone
|-
| Outlook || RPC || Random|| Internal only
|-
| OWA (web) , ActiveSync, Outlook Anywhere, EWS || HTTPS || 443|| External
|-
| ActiveSync Third-party clients || HTTPS POP3, IMAP4 || 443110, 143, 993, 995 || External
|-
| OA (anywhere) Mail transfer || SMTP || HTTPS 25 || 443 External (MX, doesn't need load balancer)
|}
By default, Exchange 2010 uses the TCP End Point Mapper port (tcp/135) and the dynamic RPC port range (6005-59530) for outgoing inbound connections every time an Outlook clients establish a connection to Exchange. Creating a load balancer configuration for this can get quite complex, so therefore it’s recommended to configure Exchange to use dedicated ports for RPC client communications. This can easily be configured on the Exchange SP1+ servers by adding the following registry keys. The ports values can be any value you want, but we recommend the below values to be able to easily follow this guide. In this example RPC Client Access Service will use tcp/TCP port 59532 and Address Book Service will use tcp/TCP port 59533. As before, tcp/TCP port 135 is still in use for the initial communication. Note that we assume you are running Exchange 2010 SP1 or newer. Otherwise, see the link below.
{| class="wikitable"
! Path !! Type !! Name !! Value
Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer “outlook.lab.local”
Then you need to create a DNS A record so that outlook.lab.local points to the VIP (Virtual IP) that we will configure shortly. In the meantime, you could configure the DNS A record to point to one of the CAS servers which will result in all clients going to this server.
Please note that all Outlook profiles configured prior to this are using the old server name for their Outlook profiles. They need to be re-configured so that they use the CAS Array name rather than the old server name. If you want to know more regarding the CAS Array and how it’s used, we recommend reading the Exchange team blog post Demystifying the CAS Array Object[http://blogs.technet.com/b/exchange/archive/2012/03/23/demystifying-the-cas-array-object-part-1.aspx].
=== Firewall and load balancer setup ===
## Hosts (nodes): the IP address of the Exchange CAS servers, one on each line
# Press "Add" (this will create the load balancer for HTTPS)
# Press Set the plus (+) icon mode the load balancer is using to the right "Source hash" on the "Listen onForward to" table three times, and add the ports 135, 59532 and 59533
# Press "Save"
# Go to "System -> Load balancer", click on "Add.. -> Relay (Layer 4+)" and do the same procedure for the other ports
# Deploy the working copy on Configuration > Deploy working copy and commit
# You might get temporarily disconnected, because you changed the web interface settings
The resulting configuration could should look similar to
interface vic0 {
address 192.168.1.100
load-balancer {
table <exchange> { 192.168.1.101 192.168.1.102 }
relay "exchangeHTTPS" {
listen on 0.0.0.0 port 443
forward to <exchange> check tcp mode source-hash
}
relay "POP3" {
listen on 0.0.0.0 port 110
forward to <exchange> check tcp mode source-hash
}
relay "POP3S" {
listen on 0.0.0.0 port 995
forward to <exchange> check tcp mode source-hash
}
relay "IMAP" {
listen on 0.0.0.0 port 143
forward to <exchange> check tcp mode source-hash
}
relay "IMAPS" {
listen on 0.0.0.0 port 993
forward to <exchange> check tcp mode source-hash
}
relay "RPCLS" {
listen on 0.0.0.0 port 135
forward to <exchange> check tcp mode source-hash
}
relay "RPCCAS" {
listen on 0.0.0.0 port 59532
forward to <exchange> check tcp mode source-hash
}
relay "RPCABS" {
listen on 0.0.0.0 port 59533
forward to <exchange> check tcp mode source-hash
}
}
system {
authentication {
root-user "admin" { password "fooadmin" }
}
dns {
ssh-server
}
The final step is to forward traffic to the load balancer and if the firewall is active making sure that there are firewall rules allowing traffic in to the SR on the ports that are going to be load balanced. Because the ''security router'' software contains both a firewall and a load balancer, both these features can be integrated as one. Having one (or more) MX record pointing at multiple address will result in an even traffic distrubition among all cluster nodes. However, if you really feel like doing so, you can of course add port 25 to the load balancer, too.
 
==== Persistance and session affinity ====
In the example above, persistance is implied by "source-hash" mode, which essentially means that a given client (address) always reaches the same server using source address hashing. If you choose to use layer 3 (redirect) instead of layer 4+ (relay) using for example the "least-states" mode, it needs [[Load_balancing#Redirect_sticky_address|sticky-address]] and source tracking timeout settings.

Navigation menu