Designing High Availability with Microsoft Exchange Server 2010

Pulling It All Together

The following sections review how each of this book’s case studies implement their high-availability Exchange 2010 environment.

Contoso Case Study

The first case study is from Chapter 2, as shown in Figure 11-18.

FIGURE 11-18 Contoso logical architecture

In light of high-availability requirements, Contoso proposes deploying a two-server high-availability solution. This two-server solution has both servers running Client Access, Hub Transport, and Mailbox server roles and is configured in a DAG. A file server in the site is the witness server. Although Contoso needs to purchase a third-party load-balancing solution because NLB is not supported on the same servers running Windows Failover Clustering, the money saved by purchasing half the number of servers more than makes up for the cost of the hardware load balancer, as shown in Figure 11-19.

The administrator creates an RPC Client Access array object named outlook.contoso.com and ensures that the each mailbox database has the RpcClientAccessServer property set to that value for the Outlook clients. The internal and external URLs also need to be updated with the load-balanced FQDN, including the AutoDiscoverServiceInternalURI. Because there are no proxy sites, all services should use the load-balanced FQDN. The ExternalHostname for Outlook Anywhere should be configured to match the certificate principle name, mail.consoto.com. An administrator will configure the load balancer with two virtual IP addresses (VIPs) that load balances both servers. The administrator will then create a DNS A record entry for mail.contoso.com and outlook.contoso.com, both pointing to separate VIPs on the load balancer.

The Contoso IT staff members have decided to deploy RAID-protected storage for each server to ensure adequate data resiliency in the event of a disk failure.

FIGURE 11-19 Proposed Contoso architecture

Fabrikam Case Study

The second, more complex case study from Chapter 2 is Fabrikam. As shown in Figure 11-20, Fabrikam has two main datacenters that will host Exchange services for all of their other sites. The Mailbox servers on the Denver site will host mailboxes for users in Phoenix, Portland, and Denver. The Mailbox servers on the Miami site will host mailboxes for user located in London, Toronto, and Miami.

In the Denver and Miami datacenters Fabrikam has deployed two hardware load-balanced Client Access servers, and the Mailbox servers are configured in a DAG. The network between the datacenters is adequate to host all client traffic both for everyday operations and in the event of a failover.

One of the key requirements for the Exchange 2010 deployment was providing a site-resilient solution. Therefore, Fabrikam has decided to migrate from their two Exchange 2007 Single Copy Clusters to a single DAG that spans both sites as shown in Figure 11-21. In case of a Denver site failover, DAC mode is enabled and an alternate witness server is configured for a server on the Miami site.

FIGURE 11-20 Fabrikam logical view

FIGURE 11-21 The Fabrikam high-availability deployment configuration

The Fabrikam Exchange 2007 deployment team followed best practice and chose to use a separate namespace for each Active Directory site. Fabrikam users in Denver access OWA using https://mail.denver.fabrikam.com/owa, whereas users in Miami use https://mail.miami.fabrikam.com/owa. To reduce confusion and support requests, Fabrikam has decided to consolidate the namespace and only instruct users to use https://mail.fabrikam.com for OWA, EWS, and IMAP communication. They have chosen to use GSLB to load-balance mail.fabrikam.com and autodiscover.fabrikam.com and configure the GSLB to send client computer connections to the site that is geographically closest. For example, a user connecting over the Internet from Atlanta will be directed to the IP address for the Miami Client Access servers; a user connecting from Fresno will be directed to the Denver Client Access servers. In the event that a client is connected to a site that does not host the active copy of the user’s mailbox, the Client Access server will be able to use the connectivity between the datacenters because the DAG has been configured to allow cross-site direct connect.

Fabrikam has approximately 7,000 mailboxes evenly distributed between the two sites. Twenty-four databases will be created, and each will handle almost 300 mailboxes, all with a 1-GB storage quota. The database high-availability plan defines that each database will have two copies on the primary site and one copy on the secondary site. Table 11-8 summarizes the database high-availability plan. The plan does not provide for three mailbox database copies at each site; therefore, the team has chosen to deploy RAID-protected storage for all of their mailbox database storage.

TABLE 11-8 Fabrikam’s Mailbox Database Copy High-Availability Plan

Fabrikam uses a hosted service for all inbound e-mail traffic. The hosted service provides redundancy and an SLA that meets the business and technical requirements for Fabrikam’s Exchange 2010 deployment project. To provide redundancy for inter- and intra-site message transport, two Hub Transport servers will be deployed to each site.

Litware Case Study

The last case study is for the global company Litware, Inc., as shown in Figure 11-22.

FIGURE 11-22 Litware, Inc., logical view

To reduce network costs, Litware uses regional namespaces to ensure that client traffic does not traverse the company WAN. Litware will deploy a high-availability solution within the regional datacenter, either with a software or hardware load balancer. Only the three hub sites—Fresno, Berlin, and Tokyo—have Exchange servers. The spoke sites, such as Kobe, Prague, and Madrid, will not have Exchange servers locally. Fresno, Berlin, and Tokyo will replace Region with the region-specific information. Tokyo, for example, will use Tokyo.litwareinc.com as their URL for OWA.

To provide e-mail message ingress and egress traffic to the Internet, the Edge Transport servers in Fresno and Berlin will all have a single MX record published using GSLB. When a request for the MX record for fabrikam.com is processed by GSLB, it will return the IP address for the MX record for the Edge Transport server closest to the sender. For example, if a SMTP server in Leipzig is sending an e-mail to Jeff@Fabrikam.com, GSLB will return the IP address for one of the Edge Transport servers in Berlin.

The Exchange deployment team at Litware decided to deploy their DAG using JBOD and without backups, which requires a 12-node DAG to be deployed in Fresno, Berlin, and Tokyo. To support the DAG in each location, nine Client Access servers are needed. This number was determined by using the CPU core ratio of four Mailbox server CPU cores for every three Client Access server CPU cores, will be deployed. Also, using the CPU core ratio of five Mailbox server CPU cores for every one CPU core on a Hub Transport server that is also running antivirus, five Hub Transport servers will be deployed at each location, as shown in Figure 11-23.

FIGURE 11-23 Litware high-availability deployment configuration

To meet Litware’s business and technical requirements, each mailbox database will have three current copies and one database copy lagged for 14 days. This configuration provides enough data redundancy to eliminate having to RAID database storage and provides a lagged copy in case a point-in-time copy is required. Because of the large number of mailbox copies required, the copies will be distributed randomly across the DAG nodes and each month the Exchange administers will run an automated report to examine server load and copy distribution to determine whether adjustments need to be made to the copy distribution.