10.0.0.11 10.0.0.12 10.0.0.13 10.0.0.14 10.0.0.1010.0.0.51 10.0.0.1 10.1.0.51

Bhargav ShuklaDirector – Product Research and InnovationKEMP Technologies

Load Balancing Exchange and Lync Server 2013

DMI308

AgendaLoad Balancing Basics

Load Balancing Exchange 2013

Load Balancing Lync 2013

Load Balancing Basics

What is Load Balancing?

Method for distributing workloads across multiple computing resources

History of Load BalancingFrom Mainframes to dot-com

x86 platform adoption and affordability

Service availability and scale out

Evolution of Load Balancing SolutionsDNS round-robin

Windows NT Load Balancing Service

Windows 2000 Network Load Balancing

Clustered solutions

Network based solutions

Application Delivery Controllers

DNS round-robinCost effective

Easy to configure

Lacks service awareness

Lacks persistence and scheduling mechanisms

DNS caching by servers/clients cause problems

Windows NLBFeature included with Windows

Cost effective

Can not be combined with clusteringMulti-Role servers with DAG use clustering

Doesn’t detect service outage

Only source IP persistence

May result in port floodingNLB Limitations referenced in Exchange 2013 Load Balancing article - http://bit.ly/nlblimitations

Load Balancers / ADCs

Purpose built hardware/software solution

Application awareness

Multiple scheduling options

Granular persistence

SSL Offload/Bridging

Intrusion Prevention/Caching/Compression

Load Balancing MechanismsLayer 4Simpler configuration

Higher throughput

No application layer visibility

Servers must be on same subnet as load balancer

Advanced application logic can’t be applied

Layer 7Application layer visibility

Advanced application logic helps improve service response and availability

Higher throughput maintained with dedicated hardware configurations

Configuration may require deeper understanding of application and load balancer software

Load Balancing BasicsOne-armConnects 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.0.0.11

10.0.0.12

10.0.0.13

10.0.0.14

10.0.0.1010.0.0.51

10.0.0.110.1.0.51

Load Balancing BasicsTwo-armConnects 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

10.0.0.11

10.0.0.12

10.0.0.13

10.0.0.14

10.0.0.1010.0.0.51

10.0.0.110.1.0.51

10.1.0.10

Load Balancing BasicsTransparent ConnectivityLoad 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 balancer10.0.0.11

10.0.0.12

10.0.0.13

10.0.0.14

10.0.0.10192.168.0.51

192.168.0.10

Load Balancing BasicsNon-Transparent ConnctivityLoad 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

10.1.0.11

10.0.0.12

10.0.0.13

10.0.0.14

10.0.0.10192.168.0.51

Load Balancer BasicsDirect Server Return (DSR)Server and client are on different subnets

Server has route to client with or without NAT

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

Load Balancer BasicsEnable DSR on a Windows ServerInstall loopback adapter

Configure load balanced service IP on loopback adapter

Set routing interface metric to “254”

Enable weak host behavior

Strong and weak host behavior explained – https://bit.ly/stronghost

Load Balancing BasicsSchedulingSelect server for new client connection

Round Robin

Least Connections

Response Time

And more…

PersistencePersist 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 BasicsSSL Offload and BridgingSSL Offload

Client session is terminated at load balancerNew session established to the server without re-encryption of dataServers must be configured to expect unencrypted data

SSL BridgingClient session is terminated at load balancerNew session established to the server; data is encryptedCertificate presented to client can be different from one installed on serverCan be very helpful with CA/B Forum baseline requirements

Took effect on July 1, 2012CA can’t issue certificate with expiry date later than Nov. 1, 2015 with reserved IP or internal server nameCertificate containing reserved IP or internal server name can’t be issued after Nov. 1, 2015

Internal Names in CA issued certificates - http://www.digicert.com/internal-names.htm

Load BalancingExchange 2013

What’s New in Exchange 2013CAS Array is no more!Client Access is stateless proxyLoad balancing requirements are simplifiedSSL Termination at load balancer isn’t required

Session affinity isn’t required enabling even distribution of connections

Service Pack 1SSL Offloading is now possible

MAPI/HTTP is new transport mechanism

Account for this if using vDir filtering at firewall/load balancer

Windows NLBKnown limitations discussed earlierTechNet article has documented NLB limitationshttp://bit.ly/nlblimitations

External load balancer still plays an important roleCan detect server and protocol level failures and remove it from handling client connections

http://bit.ly/nlblimitations

DNS Round RobinCommon arguments for DNS RRClient 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 RRClient’s DNS caching behavior (IE caches DNS records for ~20 minutes)

No service awareness, suboptimal client experience during server failures and maintenance

Namespace PlanningUnbounded model – single namespace preferredBounded model – two namespaces per datacenterRegional – one namespace per regionDirectly impacts load balancer placement and sizingAlso impacts SSL certificate planning

Namespace planning in Exchange 2013 - http://bit.ly/e15namespace

Managed AvailabilityMonitors end user experienceProvides built in monitoring and recovery actionsProvides health state of Exchange componentsAdministrator can manage component state for maintenanceEach component also has dynamic healthcheck.htme.g. /owa/healthcheck.htm, /ews/healthcheck.htm etc.

Load balancer should leverage this intelligence

Load Balancing ScenariosLayer 4 with Single NamespaceSimple 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)

Entire server removed from pool when health probe fails

Pre-authentication is not possible at Layer 4

Load Balancing ScenariosLayer 4 with Single Namespace

Layer

4LB

User

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

LB sees: IP address/Port

No SSL TerminationCAS

LB forwards traffic to CAS with no idea of final URL

Illustration Credits: Ross Smith IV/Microsoft


Health check

autodiscover.contoso.com

User

Layer

4LB

mail.contoso.com

health check

CASOWA

ECP

EWS

EAS

OAB

MAPI

RPC

AutoD



Health check


User

Layer

4LB

mail.contoso.com

health check

CASOWA

ECP

EWS

EAS

OAB

MAPI

RPC

AutoD


Load Balancing ScenariosLayer 4 with Multiple NamespaceHealth 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

Load Balancing ScenariosLayer 4 with Multiple Namespace

mapi.contoso.com

User

Layer

4LB

mail.contoso.com

ecp.contoso.com

ews.contoso.com

eas.contoso.com

oab.contoso.com

oa.contoso.com

CASOWA

ECP

EWS

EAS

OAB

MAPI

RPC

AutoD


LB sees: IP address/Port

No SSL Termination


Load Balancing ScenariosLayer 7 with Single NamespaceHealth 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 L

B

User

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

LB sees: IP address/Port/URLSSL Termination

CAS

LB forwards traffic to CAS



Health check

User

Layer

7 L

B

mail.contoso.com

CASOWA

ECP

EWS

EAS

OAB

MAPI

RPC

AutoD



SSL OffloadingMust 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://bit.ly/e15ssloffload

Important NotesCAS servers use self signed certificate OOB

cadata* cokies issued by CAS are encrypted

Replace self-signed certificate with valid certificate

Assign same certificate to all CAS servers behind same load balancer to avoid repeated authentication prompts

Demo

Load Balancing Exchange 2013

Load BalancingLync 2013

What’s new in Lync 2013Load balancing requirements are simplified

Cookie-based affinity requirements greatly reduced

Source IP affinity is now an preferred option

Coexistence with Lync 2010 requires cookie persistence

What to load balanceClient to server trafficBest candidate for load balancing

DNS load balancing for Front-End and Director pools

External “hardware” load balancing for web services and Office Web Apps servers

Server to server trafficTopology aware, doesn’t need load balancing

Lync ArchitectureProtocol Flow – Internal Client

Lync 2013 Mobile Client

Windows 8 Lync App

Lync 2013 Desktop client

Load Balancer

Internet DMZ Internal Network

Active Directory

Lync 2013 Mobile Client Lync 2013 Desktop client

Lync Front-End Pool

Mirrored Back-End Servers

Office Web Apps Server

Load Balancer

Lync Edge Pool

Reverse Proxy

AuthenticationAudioWeb Conference

Web ServicesDialin/Meet

Office Web App

Load balancing Front End/Director PoolsUse DNS Load Balancing for SIP Traffic

Configure web services override FQDN in topology

Load balance TCP port 80,8080,443 and 4443

Also load balance TCP port 444 if Director is deployed

Used for client certificate publishing and validation

Load balancing Front End/Director PoolsHealth CheckUse load balancer monitoring port if configured in topology

Otherwise check port 5061

Timeouts20 minute TCP session timeout

Session state is maintained through client usage/application interaction

30 minutes TCP idle timeout

PersistenceCookie persistence is not required

Source IP persistence is recommended

Which one is best?

Load balancing Front End/Director PoolsPersistenceIf using cookie persistence

Load balancer must issue cookie to each incoming request that didn’t have a cookieDon’t use cookie optimization

Cookie must be named MS-WSMAN

Cookie must not expire

Cookie must not be marked httpOnly

Cookie must not have expiration time

Cookie persistence is useful in co-existence scenario when Lync 2013 and Lync 2010 servers exist in same environment

Load balancing Front End/Director PoolsLoad Balancer only configurationPreferred method is to use DNS for SIP and load balancer for web services

Load balance the following TCP ports

5061, 444, 135, 80, 8080, 443, 4443, 448, 5070-5073, 5075-5076, 5080

Hardware Load Balancer Ports if Using Only Hardware Load Balancing - http://bit.ly/1185Yvq

http://bit.ly/1185Yvq

Lync ArchitectureProtocol Flow – External Client

Lync 2013 Mobile Client

Windows 8 Lync App

Lync 2013 Desktop client

Load Balancer

Internet DMZ Internal Network

Active Directory

Lync 2013 Mobile Client Lync 2013 Desktop client

Lync Front-End Pool

Mirrored Back-End Servers

Office Web Apps Server

Load Balancer

Lync Edge Pool

Reverse Proxy

AuthenticationAudioWeb Conference

Web ServicesDialin/MeetOffice Web App

Load balancing Edge poolCan use DNS or external load balancer

Use same method for internal and external interfaces

External load balancer required forFederation partners running OCS 2007 or OCS 2007 R2PIM connectivity e.g. SkypeConnectivity with XMPP providers

Load balancing Edge poolIf using “hardware” load balancing, configureExternal Edge InterfacesAccess Edge Interface

Source NAT can be usedSIP (External Client) – TCP 443SIP (Federration/PIM) – TCP 5061XMPP –TCP 5269

Web Conferencing InterfaceSource NAT can be usedPSOM – TCP 443

AV Edge InterfaceCan’t use NATUse load balancer as default gateway, DSR isn’t supportedSTUN/MSTURN – TCP 443STUN/MSTURN – UDP 3478

Load balancing Edge poolIf using “hardware” load balancing, configureExternal Edge InterfacesOther considerations

Turn off TCP nagling for internal and external TCP port 443

Turn off TCP nagling for external port range TCP 50,000-59,999

Do not use NAT on internal or external interfaces

Internal and external interfaces must be on separate networks that aren’t routed

External interfaces must use publicly routable IP addresses, do not use NAT or port forwarding

Load balancing Edge poolIf using “hardware” load balancing, configure

Internal Edge InterfacesAccess SIP – TCP 5061

Used by Directors, FE Pools

AV Authentication SIP – TCP 5062

Any FE Pool and SBA

AV Media Transfer – UDP 3478

Preferred path for A/V media transfer

AV Media Transfer – TCP 443

Fallback path for A/V media transfer

File Transfer

Desktop Sharing

Load balancing Edge poolIf using “hardware” load balancing, configureInternal Edge InterfacesOther considerations

No NAT means transparent connectivity

Routing becomes important since DSR isn’t supported

Configure routing to ensure traffic passes through load balancer

Reverse ProxyLoad balancer can act as Reverse ProxyLoad balance port 80 and 443

Translate to server ports 8080 and 4443

Do not use pre-authentication

No persistence required

Use 20 minute TCP session timeout

Use 30 minutes TCP idle timeout

Use hardware load balancer monitoring port from topology or check port 5061

Demo

Load Balancing Lync 2013

Key TakeawaysLoad balancing terminology

Layers (Layer 4 vs Layer 7), Network configuration (One-Arm vs Two-Arm)Transparency, DSR, SchedulingSSL offloading vs bridging

Load Balancing Exchange 2013Self-Signed CAS certificatesLayer 4 vs Layer 7 configuration, when and why

Load Balancing Lync 2013Keep it simpleWatch out for Edge requirementsLoad balancer can be a Reverse Proxy

© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Documents

10.0.0.11 10.0.0.12 10.0.0.13 10.0.0.14 10.0.0.1010.0.0.51 10.0.0.1 10.1.0.51