Overview

Messaging applications are more business critical than ever and many of the new features in Exchange 2010 improve the availability and management of Exchange, including better uptime and simplified administration. These enhancements bring new deployment and capacity guidance to customers.

In Exchange 2010, end-users no longer connect directly to the Mailbox servers, even when using Microsoft® Office® Outlook® in native MAPI mode, versus RPC over HTTP. Instead, all user access is serviced through the Client Access Servers (CAS). This change allows 100% of the user traffic to be optimized and load balanced by F5.

Database Availability Groups (DAG) provide Mailbox availability and automatic database recovery in the event of failure. Continuous replication and monitoring of all group members allow for quick detection and recovery of a Mailbox database. If an active member fails, DAG will bring up the passive database copy on another server and resume services, minimizing the impact to end-users. For disaster recovery (DR), DAG members may be located in different sites that are geographically separated, for example Remote Office/Branch Office (ROBO), and interconnected by a wide area network (WAN). This change allows DAG replication traffic to be WAN optimized by F5.

These new features combined with F5 BIG-IP systems can improve performance and availability, and simplify the administration of Exchange, helping to maximize uptime and ensuring that end-users have reliable access to Exchange services.

In the TechCenter we did some basic testing of BIG-IP scalability and high availability for both DAG and CAS roles. We documented our lab experiences and the wiki page is organized as follows:

• Overview
• Exchange 2010 and the benefits of BIG-IP
• Lab Environment Configuration
• Testing, Results and Lessons Learned

Exchange 2010 and the benefits of BIG-IP

What are the Exchange 2010 server roles and the associated benefits of using F5 BIG-IP?

The Edge Transport Server Role is the SMTP relay service for Exchange that provides external mail flow for an organziation. This is an optional role.

• BIG-IP benefits: Load balancing based on built-in or customized LB methods. Advanced methods are able to query server available resources via WMI or SNMP. For example, this may be helpful if Edge servers are busy performing virus scanning and the load needs to be distributed to the most available/least busy Edge server.

The Hub Transport Server Role provides internal e-mail routing and allows admins to implement e-mail filtering, compliance, archiving and monitoring. In smaller deployments it is often co-located on the same hardware as the CAS role. For large deployments the role can be located on dedicated hardware. This is a required role.

The Mailbox Server Role provides data storage and self-replication technologies. In contrast with previous versions of Exchange, clients no longer talk to the Mailbox servers. DR capabilities are now simplified, using a single TCP-based replication process called Database Availability Group or DAG. This is a required role.

• BIG-IP benefits: WAN optimization, acceleration and encryption of DAG traffic as it crosses wide area networks. Features include compression, de-duplication, encryption, tunneling and TCP optimizations. WOM scales to very high bandwidths (up to 1 Gbps).
• Why chose F5 WOM over the Exchange built-in compression and encryption? Exchange Server 2010 provides compression and encryption for DAG partners located on different IP subnets. These features are built-in, cost-efficient, and effective at helping to reduce the amount of network traffic and ensure the privacy of the transfers, but both are resource intensive and take away server processing power from the primary application. In addition, compression alone does not address poor performance associated with problematic WAN conditions. Specialized technologies such as F5 BIG-IP WOM are required to effectively overcome poor WAN replication performance and offload the tasks of compression and encryption from the Mailbox servers. Consider F5 WOM if you want to enable DAG replication over a wide area network with almost any combination of limited bandwidth, high latency and packet loss.

The Client Access Server Role, known as CAS, provides Exchange connectivity for all clients regardless of client type or protocol. Including Outlook Web App, ActiveSync, POP3, IMAP4, RPC Client Access (MAPI) and Outlook Anywhere. This is a required role.

• BIG-IP benefits: High availability and scalability of these services including datacenter failover, local datacenter load distribution, SSL offload, web acceleration, secure remote access, TCP optimization, web application firewall and others.
• Why chose LTM over NLB for CAS load balancing? It is possible for administrators to load balance Client Access servers using Microsoft Windows® Network Load Balancing (NLB) clustering, which provides a cost effective choice for some configurations. However, administrators should consider using F5 BIG-IP Local Traffic Manager™ (LTM) application delivery controllers for environments that contain eight or more Client Access servers, with servers running more than one Exchange server role, or when Exchange servers are running Microsoft Cluster Service (MSCS)—running NLB and MSCS on the same hardware is not recommended. Also, LTM offers a greater choice of persistence methods (cookie, arbitrary headers, etc.), load-balancing methods (e.g. least connections, predictive, etc.) than does NLB, as well as very flexible iRules for separating traffic, logging, etc. F5 also supports hardware compression in higher-end models and hardware encryption.

Unified Messaging Role adds audio component to Exchange and integrates voicemail functionality. This is an optional role.

• BIG-IP benefits: BIG-IP is commonly used in UC deployments to provide application delivery, and the same BIG-IP hardware that is used for Exchange can be used for Microsoft Office Communications Server (OCS), Microsoft SharePoint and other applications.

Helpful Links:
Microsoft's TechNet web pages
Understanding Load Balancing in Exchange 2010

Affinity (persistence) requirements for 2010 CAS

Understanding Proxying and Redirection in Exchange 2010

And take a look at the F5 Deployment Guide for a complete step-by-step on how to configure BIG-IP for Exchange 2010. Recently updated!!

Lab Environment Configuration

Our F5 testing is focused on three specific areas and they are reflected in the design of the lab set up, shown in figures 1 and 2:

• WAN optimization for DAG replication using BIG-IP WAN Optimization Module (WOM)
• Local datacenter application scaling and high availability for CAS using BIG-IP Local Traffic Manager (LTM). We are focusing on CAS Outlook Web App (OWA) and RPC Client Access (MAPI) services.
• Datacenter availability and failover using BIG-IP Global Traffic Manager (GTM)

Test lab equipment:

• 3 x Dell PowerConnect 6248 Switches
• 3 x Dell PowerEdge R710 Servers
• 1 x Dell EqualLogic PS Series iSCSI SAN (PS4000XV)
• 1 x Dell EqualLogic PS Series iSCSI SAN (PS6000XV)
• 1 x F5 BIG-IP 1600 Global Traffic Manager (GTM)
• 2 x F5 BIG-IP 3600 Local Traffic Manager (LTM) + WAN Optimization Module (WOM)
• 1 x LANForge 5.0.2 WAN Emulator set for DS3 at 45Mbps, 100ms latency and 1% packet loss (10K packets per million)

Software:

• VMware ESX, vCenter and vSphere (Version 4.1.0 Build 241717)
• Microsoft Windows Server 2008 R2
• Microsoft Active Directory
• Microsoft Exchange 2010
• Microsoft LoadGen Beta, .NET Framework 3.51 and Filter Pack (installed locally on Exchange servers)

Figure 1. Dell | F5 | Exchange 2010 - TechCenter test lab network and equipment layout

Figure 2. Dell | F5 | Exchange 2010 - Datacenter load balancing and failover, CAS load balancing and DAG WAN acceleration

Testing, Results and Lessons Learned

Refer to figures 1 and 2 above for equipment, network, site and server layout.

To get started, we install Exchange 2010 and create/initialize a new database using LoadGen. Our target database for the test is 50 users each with a 250MB mailbox, creating a 12.5GB database. Limiting the database size is intentional because we do not have time to wait around for processing a large database. During the set up we encounter some errors with the LoadGen initialization process but after several attempts we are able to get a database built with 50 users each with a 100MB mailbox; yielding a 5GB test database. Not ideal but we are happy with it.

The test team references the F5 Deployment Guide for detailed instructions on how to configure BIG-IP Global Traffic Manager (GTM), BIG-IP Local Traffic Manager (LTM) and BIG-IP WAN Optimization Module (WOM) for Exchange 2010. For the CAS roles, we use the sections describing Outlook Web App and RPC Client Access. Note: In order to offload the compression and encryption processing from the Exchange mailbox servers to the BIG-IP, we disable DAG compression and encryption using the Exchange Shell command "Set-DatabaseAvailabilityGroup". We found some good information on MSExchange.org and this page was particulalry helpful.

Database Availability Groups

As shown in figure 3, we create a DAG called f5-dell-DAG and add the servers B1 (Branch Office server) and C1 (Central Office server). These Exchange servers are now part of the DAG and their databases are now maintained on both servers for improved availability. You can also see the Network called DAGNetwork4 using subnets 10.0.40.0/24 for Central Office and 10.0.50.0/24 for Branch Office. This is the network dedicated to the DAG traffic. From our lab experience, we conclude that a dedicated DAG network is not only recommended but required as we cannot get DAG to work without it.

Figure 3. Dell | F5 | Exchange 2010 - Mailbox DAG configuration screen

As soon as the DAG is created, Exchange goes to work building the passive/backup copy of the database. It is at this point that we see the BIG-IP WAN Optimization Module encrypt and accelerate the DAG traffic as Exchange sends the log files across the WAN from server B1 to server C1. Once the logs are successfully copied, they are replayed in to the passive/backup copy of the database and the passive copy comes up and shows as Healthy. As shown in figure 4, the active/primary database is mounted on the branch office server B1 (Copy Status = Mounted) and the passive/backup database is located on the central office server C1 (Copy Status = Healthy).

During our testing we change the location of the active/primary database numerous times to see how long it takes to activate the backup copy. BIG-IP WAN Optimization Module speeds up DAG not only during the replication of data but also when performing DAG administrative task such as promoting a database copy. In our tests, without WOM we wait for over 30 minutes for the DB promotion and with WOM it takes less than 3 minutes.


Figure 4. Dell | F5 | Exchange 2010 - Mailbox Database Management configuration screen

CAS Load Balancing

To demontrate external hardware load balancing for CAS using BIG-IP LTM, we build three CAS servers for our Central Office site. Figure 5 shows the Exchange Shell cmdlet output from the Get-ClientAccessArray command. Server C1 is running all of the required roles (CAS/Hub/MB) while the CAS1 and CAS2 servers run only the CAS and Hub roles. We have configured the CAS servers for the DNS name rpc.dell-f5 so that all three handle client connections for the Central site. In hindsight we can see that the rpc.dell-f5 DNS name is misleading and we should named it something more generic, like cas-central.dell-f5, that does not reference a specific CAS service.

BIG-IP LTM is configured to load balance Outlook Web App (OWA) and RPC Client Access (MAPI) following the F5 deployment guide. The BIG-IP Virtual Server is configured and the CAS servers are added as members of the BIG-IP Pool.

Our tests are very simple but we are able to make OWA connections using Internet Explorer through the BIG-IP where the HTTP traffic is SSL accelerated and load balanced to the CAS servers. Success!


Figure 5. Dell | F5 | Exchange 2010 - Exchange Management Shell "Get-ClientAccessArray" output

Datacenter Availability and Failover

The F5 deployment guide shows the configuration of Global Traffic Manager (GTM) for the Exchange Edge role but since we are not testing the Edge role (SMTP relay) in our lab, we adapted the instructions to demonstrate GTM datacenter availability for RPC Client Access.

As shown in figure 2 above, the CAS servers are positioned behind the BIG-IP LTM's in each datacenter and they are continually monitored for health. And both BIG-IP LTM's and their associated Virtual Servers are continually monitored by GTM. Using the Global Availability load balancing method in GTM provides an active | standby configuration where the primary datacenter (dc1) IP address 172.16.44.20 is always handed out to client DNS requests. But in the event of a failure of the primary datacenter, GTM begins handing out the standby datacenter (dc2) IP address 172.16.46.20 to client DNS requests. This functionality provides client failover across datacenters/sites for CAS services. The Edge role (SMTP relay) can also benefit from this feature although we did not test this in our lab.

For our test, we pull the network cable on the primary datacenter (dc1) server and GTM automatically detects the failure. At this point, GTM immediately begins resolving DNS requests with the IP address 172.16.46.20 of the BIG-IP Virtual Server for the secondary datacenter (dc2). Figure 6 shows the GTM management screen during the failure and you can see that dc1 is red/down and dc2 is green/up.


Figure 6. Dell | F5 | Exchange 2010 - F5 BIG-IP Global Traffic Manager datacenter failover

Links

F5 Networks on Dell TechCenter