LoadBalancer and Exchange 2013

Lasse Pettersson LoadBalancer and Exchange 2013 Lasse Pettersson

Load Balancing Load Balancing basics Load balance previous version of Exchange Load Balance Exchange 2013

introduction What is LoadBalancing? Distribute workloads to multiple computing resources Redundancy if configured correctly History of LoadBalancing In the early days we simply scaled up to a bigger box Then there was n-tier appl which gave us more scale but still a single endpoint for clients Almost no client understand multiple endpoints which is a big problem when we scale out

Evolution of loadbalancing DNS round-robin Windows NT Load Balancing Service Windows 2000 Network Load Balancing Clustered solutions Network based solutions Application Delivery Controllers

DNS Round Robin Cheap Easy No service awarness No persistence No Scheduling Cache is problem Name servers Client

Windows NLB Built into windows Cheap Can not be combined with clustering DAG use clustering Doesn t detect service outage, only when complete box is dead Only source IP persistence Can be tricky to configure in some network Port flooding

Application Delivey Controllers / Load Balancers Specially built software Application awareness (health monitoring) Multiple scheduling options Granular persistence SSL Offload/Bridging Intrusion Prevention/Caching/Compression

LoadBalancer mechanics Layer 4, simply TCP/UDP connections Easy High performance, less load on LoadBalancer No application layer visibility Advanced application logic can t be applied Layer 7, application layer Can see application traffic Advanced application logic helps improve service response and availability Higher CPU utilization on LoadBalancer, dedicated hardware can help Configuration most often require deeper understanding of application and load balancer software

Load Balancer basics One armed Connects to network via single interface Servers reside on same Layer 2 network as load balancer Clients could reside on same network as servers and load balancer SNAT or Direct Server Return (DSR) is required Load Balancer can be used as Default Gateway, only for clients from different subnet Very rare unless smaller networks

Load Balancer basics Two armed Connects to network via client and farm side interfaces Servers are connected on farm side network segment Clients could reside on same network as servers and load balancer SNAT or Direct Server Return (DSR) is required Most of the time

Load Balancer basics Transparent Connectivity Load balancer preserves source IP from client Important requirement for workloads such as SMTP with IP filtering enabled Routing configuration is critical to transparent connectivity Typically load balancer is configured as default gateway Direct Server Return is required if load balancer isn t default gateway 10.0.0.11 Servers must be on same subnet as load balancer 192.168.0.10 10.0.0.12 192.168.0.51 10.0.0.10 10.0.0.13 10.0.0.14

Load Balancer basics Non-Transparent Connctivity Load balancer replaces source IP with its own Load balancer NATs source IP (SNAT) Enables servers to reside in different subnet from load balancer Client IP can be preserved with additional headers such as X-ClientSide or X- Forwarded-For Layer 7 and application inspection 10.1.0.11 10.0.0.12 10.0.0.13 10.0.0.14

Load Balancer basics Direct Server Return (DSR) Using load balancer as default gateway isn t desired or possible Each server being load balanced must be configured for DSR Servers must be located on same subnet as load balancer Server and client are on different subnets Server has route to client with or without NAT Disable strong host model Uncommon

DSR

Loadbalancer will be configured to do NAT in 99% of times

Load Balancer basics Scheduling Select server for new client connection Round Robin Least Connections Response Time And more Persistence Persist a connection from same client to same server selected earlier Source IP Address HTTP Headers Server or load balancer generated cookie And more

Load Balancer basics SSL Offload Client session is terminated at load balancer New session established to the server without re-encryption of data Servers must be configured to expect unencrypted data SSL Bridging Client session is terminated at load balancer New session established to the server; data is encrypted Certificate presented to client can be different from one installed on server Internal Names in CA issued certificates - http://www.digicert.com/internal-names.htm

Load balance previous versions of Exchange POP, IMAP, SMTP has always been there but do they need to pass a LB? Exchange 4 5.5 MAPI direct to store Some Vdir came along, /Exchange /public Exchange 2000 FE/BE but nothing really change Exchange 2003 outlook anywhere, EAS Exchange 2007 EWS, OAB, autodiscover, OWA Exchange 2010 Very complex, almost every VDIR/Appl need its own configuration in LB You can cut corners but load will not spread evenly

Whats new in Exchange 2013 CAS Array is no more! Client Access is stateless proxy Load balancing requirements are simplified Simple Layer 4 connection is OK No affinity needed Always even distribution of connections Service Pack 1 / CU4 SSL Offloading is now possible MAPI/HTTP can be enabled

How come we dont need affinity/stickiness CAS servers use self signed certificate OOB Replace self-signed certificate with valid certificate cadata* cokies issued by CAS is encrypted with cert on IIS Assign same certificate to all CAS servers behind same load balancer to avoid repeated authentication prompts

DNS round robin Common arguments for DNS RR Client protocols are now HTTP (RPC/HTTP, MAPI/HTTP) HTTP commonly times out when a server fails and tries next server when using DNS RR Problems when using DNS RR Client s DNS caching behavior (IE caches DNS records for ~20 minutes) No service awareness, suboptimal client experience during server failures and maintenance Not distributed evenly

Managed Availability Monitors end user experience Provides built in monitoring and recovery actions Provides health state of Exchange components Administrator can manage component state for maintenance Each component also has dynamic healthcheck.htm e.g. /owa/healthcheck.htm, /ews/healthcheck.htm etc. Load balancer should leverage this intelligence

Scenarios Layer 4 with Single Namespace Simple configuration No SSL termination on load balancer Reduced resource consumption on load balancer, Higher scalability Only one health probe possible (e.g. /owa/healthcheck.htm) Totaly depends on what LB is capable of Entire server removed from pool when health probe fails Pre-authentication is not possible at Layer 4

Layer 4LB Scenarios Layer 4 single name space No healthcheck LB sees: IP address/port No SSL Termination User CAS Client makes request to FQDN: /ews/exchange.asmx on TCP 443 LB forwards traffic to CAS with no idea of final URL

Layer 4LB Scenarios Layer 4 with Single Namespace Single Healthcheck User mail.contoso.com health check CAS OWA ECP EWS autodiscover.contoso.com EAS OAB RPC MAPI AutoD

Layer 4LB Scenarios Layer 4 with Single Namespace Single Healthcheck User mail.contoso.com health check CAS OWA ECP EWS autodiscover.contoso.com EAS OAB RPC MAPI AutoD

Scenarios Layer 4 with Multiple Namespace Health probe per workload (owa/ews/rpc etc) Granular control over failures Better resource usage on servers No SSL termination on load balancer SSL certificates require more names, increase in cost One IP per workload, more public IP addresses needed Costly, sometimes restrictive due to public IP availability Pre-authentication is not possible at Layer 4

Layer 4LB Layer 4, multiple name spaces User mail.contoso.com ecp.contoso.com ews.contoso.com eas.contoso.com CAS OWA ECP EWS EAS oab.contoso.com oa.contoso.com mapi.contoso.com autodiscover.contoso.com OAB RPC MAPI AutoD

Scenarios Layer 7 with Single Namespace Health probe per workload (owa/ews/rpc etc) Granular control over failures Better resource usage on servers SSL termination on load balancer Simplified SSL certificate requirements Use of single public IP possible even with multiple namespaces Pre-authentication and single sign-on with multiple workloads is possible Higher resource consumption on load balancer compared to Layer 4 Load Balancer configuration may require deeper understanding of product

Layer 7 LB Scenarios Layer 7, single name space LB sees: IP address/port/url SSL Termination User CAS Client makes request to FQDN: /ews/exchange.asmx on TCP 443 LB forwards traffic to CAS

Layer 7 LB Scenarios Layer 7, single namespace User mail.contoso.com CAS OWA ECP EWS EAS OAB RPC MAPI autodiscover.contoso.com AutoD

Health monitoring/probes

SSL Offloading Must be configured manually Can coexist with Exchange 2007 and Exchange 2010 If MRSProxy is in use, EWS can t be offloaded How to configure SSL offload http://technet.microsoft.com/en-us/library/dn635115(v=exchg.150).aspx

Reverse proxy Most loadbalancers can act as a reverseproxy Perhaps a replacement for TMG/UAG

healtheck.htm is your friend

Lasse Pettersson SMTP/SIP lars.pettersson@knowledgefactory.se http://anewmessagehasarrived.blogspot.com