LoadBalancer and Exchange 2013

(1)

LoadBalancer and

Exchange 2013

Lasse Pettersson

(2)

Load Balancing

• Load Balancing basics

(3)

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

(4)

Evolution of loadbalancing

• DNS round-robin

• Windows NT Load Balancing Service

• Windows 2000 Network Load Balancing

• Clustered solutions

• Network based solutions

(5)

(6)

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

(7)

Application Delivey Controllers / Load Balancers

• Specially built software

• Application awareness (health monitoring)

• Multiple scheduling options

• Granular persistence

• SSL Offload/Bridging

(8)

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

(9)

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

(10)

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

(11)

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

• Servers must be on same subnet as load balancer 10.0.0.11

(12)

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 ClientSide or X-Forwarded-For

• Layer 7 and application inspection 10.1.0.11

10.0.0.12

10.0.0.13

(13)

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

(14)

(15)

(16)

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

(17)

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

(18)

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

(19)

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

(20)

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

(21)

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

(22)

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.

(23)

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

(24)

Scenarios

• Layer 4 single name space

• No healthcheck La ye r 4 LB User

Client makes request to FQDN: /ews/Exchange.asmx on TCP 443

LB sees: IP address/Port No SSL Termination

CAS

(25)

Scenarios

• Layer 4 with Single Namespace

(26)

Scenarios

• Layer 4 with Single Namespace

(27)

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

(28)

(29)

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

(30)

Scenarios

• Layer 7, single name space

La ye r 7 L B User

Client makes request to FQDN: /ews/Exchange.asmx on TCP 443

LB sees: IP address/Port/URL SSL Termination

CAS

(31)

Scenarios

• Layer 7, single namespace

(32)

(33)

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

(34)

Reverse proxy

• Most loadbalancers can act as a reverseproxy

(35)

(36)

(37)