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
TRANSCRIPT
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
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
Load Balancing ScenariosLayer 4 with Single Namespace
Health check
autodiscover.contoso.com
User
Layer
4LB
mail.contoso.com
health check
CASOWA
ECP
EWS
EAS
OAB
MAPI
RPC
AutoD
Illustration Credits: Ross Smith IV/Microsoft
Load Balancing ScenariosLayer 4 with Single Namespace
Health check
autodiscover.contoso.com
User
Layer
4LB
mail.contoso.com
health check
CASOWA
ECP
EWS
EAS
OAB
MAPI
RPC
AutoD
Illustration Credits: Ross Smith IV/Microsoft
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
autodiscover.contoso.com
LB sees: IP address/Port
No SSL Termination
Illustration Credits: Ross Smith IV/Microsoft
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
Load Balancing ScenariosLayer 7 with Single Namespace
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
Illustration Credits: Ross Smith IV/Microsoft
Load Balancing ScenariosLayer 7 with Single Namespace
Health check
User
Layer
7 L
B
mail.contoso.com
CASOWA
ECP
EWS
EAS
OAB
MAPI
RPC
AutoD
autodiscover.contoso.com
Illustration Credits: Ross Smith IV/Microsoft
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
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.