Director Product Research and Innovation KEMP Technologies Load Balancing Exchange and Lync Server 2013 DMI308 Agenda Load Balancing Basics Load Balancing Exchange 2013 Load Balancing Lync 2013 ID: 220557
Download Presentation The PPT/PDF document "Bhargav Shukla" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1Slide2
Bhargav ShuklaDirector – Product Research and InnovationKEMP Technologies
Load Balancing Exchange and Lync Server 2013
DMI308Slide3
AgendaLoad Balancing Basics
Load Balancing Exchange 2013Load Balancing Lync 2013Slide4
Load Balancing BasicsSlide5
What is Load Balancing?
Method for distributing workloads across multiple computing resourcesSlide6
History of Load Balancing
From Mainframes to dot-comx86 platform adoption and affordability
Service availability and scale outSlide7
Evolution of Load Balancing Solutions
DNS round-robinWindows NT Load Balancing ServiceWindows 2000 Network Load Balancing
Clustered solutions
Network based solutions
Application Delivery ControllersSlide8
DNS round-robin
Cost effectiveEasy to configureLacks service awareness
Lacks persistence and scheduling mechanisms
DNS caching by servers/clients cause problemsSlide9
Windows NLB
Feature included with WindowsCost effectiveCan not be combined with clustering
Multi-Role servers with DAG use clustering
Doesn’t detect service outage
Only source IP persistence
May result in port flooding
NLB Limitations referenced in Exchange 2013 Load Balancing article - http
://
bit.ly/nlblimitationsSlide10
Load Balancers / ADCs
Purpose built hardware/software solutionApplication awareness
Multiple scheduling options
Granular persistence
SSL Offload/Bridging
Intrusion Prevention/Caching/CompressionSlide11
Load Balancing Mechanisms
Layer 4Simpler configurationHigher throughput
No application layer visibility
Servers must be on same subnet as load balancer
Advanced application logic can’t be applied
Layer 7
Application 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 softwareSlide12
Load Balancing Basics
One-armConnects to network via single interfaceServers reside on same Layer 2 network as
l
oad 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.10
10.0.0.51
10.0.0.1
10.1.0.51Slide13
Load Balancing Basics
Two-armConnects to network via “client” and “farm side” interfacesServers 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.10
10.0.0.51
10.0.0.1
10.1.0.51
10.1.0.10Slide14
Load Balancing Basics
Transparent ConnectivityLoad balancer preserves source IP from clientImportant 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
10.0.0.12
10.0.0.13
10.0.0.14
10.0.0.10
192.168.0.51
192.168.0.10Slide15
Load Balancing Basics
Non-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.10
192.168.0.51Slide16
Load Balancer Basics
Direct Server Return (DSR)Server and client are on different subnetsServer 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 balancerSlide17
Load Balancer Basics
Enable 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/stronghostSlide18
Load Balancing Basics
SchedulingSelect server for new client connectionRound 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…Slide19
Load Balancer Basics
SSL Offload and BridgingSSL OffloadClient 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
Can be very helpful with CA/B Forum baseline requirements
Took effect on July 1, 2012
CA can’t issue certificate with expiry date later than Nov. 1, 2015 with reserved IP or internal server name
Certificate 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.htmSlide20
Load Balancing Exchange 2013Slide21
What’s New in Exchange 2013
CAS Array is no more!Client Access is stateless proxyLoad balancing requirements are simplified
SSL Termination at load balancer isn’t required
Session affinity isn’t required enabling even distribution of connections
Service Pack 1
SSL Offloading is now possible
MAPI/HTTP is new transport mechanism
Account for this if using
vDir
filtering at firewall/load balancerSlide22
Windows NLB
Known limitations discussed earlierTechNet article has documented NLB limitationshttp://bit.ly/nlblimitations
External load balancer still plays an important role
Can detect server and protocol level failures and remove it from handling client connectionsSlide23
DNS Round Robin
Common 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 RR
Client’s DNS caching behavior (IE caches DNS records for ~20 minutes)
No service awareness, suboptimal client experience during server failures and maintenanceSlide24
Namespace Planning
Unbounded model – single namespace preferredBounded model – two namespaces per datacenter
Regional – one namespace per region
Directly impacts load balancer placement and sizing
Also impacts SSL certificate planning
Namespace planning in Exchange 2013 - http
://
bit.ly/e15namespaceSlide25
Managed Availability
Monitors end user experienceProvides 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 intelligenceSlide26
Load Balancing Scenarios
Layer 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 4Slide27
Load Balancing Scenarios
Layer 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 Termination
CAS
LB forwards traffic to CAS with no idea of final URL
Illustration Credits:
Ross Smith IV/MicrosoftSlide28
Load Balancing Scenarios
Layer 4 with Single NamespaceHealth check
autodiscover.contoso.com
User
Layer 4LB
mail.contoso.com
health check
CAS
OWA
ECP
EWS
EAS
OAB
MAPI
RPC
AutoD
Illustration Credits: Ross Smith IV/MicrosoftSlide29
Load Balancing Scenarios
Layer 4 with Single NamespaceHealth check
autodiscover.contoso.com
User
Layer 4LB
mail.contoso.com
health check
CAS
OWA
ECP
EWS
EAS
OAB
MAPI
RPC
AutoD
Illustration Credits: Ross Smith IV/MicrosoftSlide30
Load Balancing Scenarios
Layer 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 4Slide31
Load Balancing Scenarios
Layer 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
CAS
OWA
ECP
EWS
EAS
OAB
MAPI
RPC
AutoD
autodiscover.contoso.com
LB sees: IP address/Port
No SSL Termination
Illustration Credits: Ross Smith IV/MicrosoftSlide32
Load Balancing Scenarios
Layer 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 productSlide33
Load Balancing Scenarios
Layer 7 with Single Namespace
Layer
7 LB
User
Client makes request to FQDN:
/
ews
/Exchange.asmx on TCP 443
LB sees: IP
address/Port/URL
SSL
Termination
CAS
LB forwards traffic to
CAS
Illustration Credits: Ross Smith IV/MicrosoftSlide34
Load Balancing Scenarios
Layer 7 with Single NamespaceHealth check
User
Layer
7 LB
mail.contoso.com
CAS
OWA
ECP
EWS
EAS
OAB
MAPI
RPC
AutoD
autodiscover.contoso.com
Illustration Credits: Ross Smith IV/MicrosoftSlide35
SSL Offloading
Must be configured manuallyCan coexist with Exchange 2007 and Exchange 2010If
MRSProxy
is in use, EWS can’t be offloaded
How to configure SSL offload
http://bit.ly/e15ssloffloadSlide36
Important Notes
CAS servers use self signed certificate OOBcadata*
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 promptsSlide37
DemoLoad Balancing Exchange 2013Slide38
Load Balancing Lync 2013Slide39
What’s new in Lync 2013
Load balancing requirements are simplifiedCookie-based affinity requirements greatly reduced
Source IP affinity is now an preferred option
Coexistence with Lync 2010 requires cookie persistenceSlide40
What to load balanceClient to server traffic
Best candidate for load balancingDNS load balancing for Front-End and Director pools
External “hardware” load balancing for web services and Office Web Apps servers
Server to server traffic
Topology aware, doesn’t need load balancingSlide41
Lync Architecture
Protocol Flow – Internal Client
Authentication
Audio
Web Conference
Web Services
Dialin
/Meet
Office Web AppSlide42
Load balancing Front End/Director Pools
Use DNS Load Balancing for SIP TrafficConfigure 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 validationSlide43
Load balancing Front End/Director Pools
Health CheckUse load balancer monitoring port if configured in topology
Otherwise check port 5061
Timeouts
20 minute TCP session timeout
Session state is maintained through client usage/application interaction
30 minutes TCP idle timeout
Persistence
Cookie persistence is not required
Source IP persistence is recommended
Which one is best
?Slide44
Load balancing Front End/Director Pools
PersistenceIf using cookie persistenceLoad balancer must issue cookie to each incoming request that didn’t have a cookie
Don’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 environmentSlide45
Load balancing Front End/Director Pools
Load 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/1185YvqSlide46
Lync Architecture
Protocol Flow – External Client
Authentication
Audio
Web Conference
Web Services
Dialin
/Meet
Office Web AppSlide47
Load balancing Edge pool
Can use DNS or external load balancerUse same method for internal and external interfaces
External load balancer required for
Federation partners running OCS 2007 or OCS 2007 R2
PIM connectivity e.g. Skype
Connectivity with XMPP providersSlide48
Load balancing Edge pool
If using “hardware” load balancing, configureExternal Edge InterfacesAccess Edge InterfaceSource NAT can be used
SIP (External Client) – TCP 443
SIP (
Federration
/PIM) – TCP 5061
XMPP –TCP
5269
Web Conferencing Interface
Source NAT can be used
PSOM –
TCP 443
AV Edge Interface
Can’t use NAT
Use load balancer as default gateway, DSR isn’t supported
STUN/MSTURN – TCP 443
STUN/MSTURN – UDP
3478Slide49
Load balancing Edge pool
If 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 forwardingSlide50
Load balancing Edge pool
If using “hardware” load balancing, configureInternal 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 SharingSlide51
Load balancing Edge pool
If 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 balancerSlide52
Reverse Proxy
Load balancer can act as Reverse ProxyLoad balance port 80 and 443Translate 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 5061Slide53
DemoLoad Balancing Lync 2013Slide54
Key Takeaways
Load balancing terminologyLayers (Layer 4 vs Layer 7), Network configuration (One-Arm vs Two-Arm)Transparency, DSR, Scheduling
SSL offloading vs bridging
Load Balancing Exchange 2013
Self-Signed CAS certificates
Layer 4 vs Layer 7 configuration, when and why
Load Balancing Lync 2013
Keep it simple
Watch out for Edge requirements
Load balancer can be a Reverse ProxySlide55Slide56
©
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.