通过

CAS Load-Balancing Best Practices (Part 2)

  • 项目

CAS Load Balancing Best Practices (Part 2: Load balancing Intranet aka "Non-Internet facing" sites):

For Part 1 of this post, go here: CAS Load-Balancing Best Practices (Part 1)

You need to understand CAS->CAS Proxying before you try to understand load-balancing proxy CAS's.  Please read the following technet documentation if you don't understand CAS->CAS Proxy before proceeding:

Understanding Proxying and Redirection

The first big question is whether or not load balancing is required in the second site. Originally it was thought that the CAS in the first site would do load balancing and redundancy for the individual CAS's at an application layer.  We later found out that this is 100% true for OWA and Exchange Web Services Proxy but untrue for Activesync and Unified messaging proxy.

So, to get full load-balancing and redundancy for all services, you must deploy load balancing in the proxy sites as well as pictured below:

CAS Proxy with NLB

The trickiest part to this is not conifguring the NLB, it is knowing how to configure all of the URL parameters for the destination CAS.

Our documentation topic on technet "Understanding Proxying and Redirection" covers this in some detail.  I'm leveraging our chart below for reference on how to set the individual parameters for the Virtual Directories.

Virtual directory settings for non-Internet-facing Client Access servers in an organization that uses NLB

Virtual directory InternalURL setting

/OWA

https://computername/OWA

/OAB

https://NLBname/OAB

/UnifiedMessaging

https://NLBname/UnifiedMessaging

/Microsoft-Server-ActiveSync*

https://NLBname/Microsoft-Server-ActiveSync

/EWS**

https://NLBname/EWS

* NOTE: This does NOT work in RTM for ActiveSync due to some Keberos issues. You must set the InternalUrl to https://computername/Microsoft-Server-Activesync and you get no fault tolerance if a CAS in the seond site goes down. We corrected these Kerberos issues in SP1 so you should be able to set the InternalUrl to the NLBname at that time.

** NOTE: EWS does not use the InternalUrl for proxying core EWS traffic and instead uses the InternalNLBBypassUrl configured on the Virtual Directory (this should always be configured to the machine FQDN). Proxying for the Availability service will use the InternalUrl but affinity is not required.

Note in regard to Affinity settings
OWA and EWS are "stateful" applications.  Because of this, they must maintain the connection with the same CAS throughout a users session.  However, because OWA and EWS use application-level load-balancing and failover and do not route through your load-balancer in the remote site, Affinity on the load balancer should not be an issue.  EAS and UnifiedMessaging are stateless and can be handled by any CAS on subsequent requests so for them, the load balancing affinity can be set to "None" in the proxy site to ensure even distribution of requests.

Have fun deploying your CAS Proxy + NLB Solutions!

Comments