Programming4us
         
 
 
Applications Server

Exchange Server 2010 : Availability Planning for Mailbox Servers (part 8) - Designing and Configuring DAGs

12/15/2010 11:56:51 AM

3. Designing and Configuring DAGs

When deploying a CCR environment in Exchange 2007, the sizing was straightforward—the databases were running on one node or the other. In Exchange 2010, which offers you the ability to have 16 members with up to 1,600 databases, sizing and designing the layout is far more complex. The obvious rule is that the more servers you have in a DAG the more options you have for laying out your database copies efficiently and resiliently. Consider the implications of a three-copy, six-server DAG versus two DAGs with three servers and three copies of each database. More servers in a single DAG give you more flexibility in creating copies and to balancing load. To illustrate, if a single server fails with three active databases in a three-member DAG, the two remaining servers need to service the load from the first server, as shown in Figure 10.

As compared to two 3-member DAGs, a 6-member DAG can more effectively spread the results of failure across multiple servers as well as to sustain more member failures.

Figure10. Three-node DAG failover


In Figure 10 the DAG was designed to sustain a single-node failure; if more than one member was down at least two databases would be offline. Simply adding a member to a DAG does not automatically enable it to sustain multiple failures, as Figure 11 shows. Here, servers are configured to mirror each other in a four-member DAG. If either A and B or C and D fail, a large number of databases will be unavailable. This configuration provides no better member redundancy than having two 2-member DAGs.

You should design the databases copies with the worst-case failure needed to meet your agreed-upon SLAs. The following two rules apply for redundancy:

  1. One-member failure requires two or more high-availability copies, two or more servers, and a witness server.

  2. Two-member failure requires three or more high-availability copies, four or more servers, and a witness server.

Rather than mirroring database copies on two servers it is better to stripe copies across the members or create copies randomly across the DAG to reduce the likelihood of a low number of failures causing outages for databases.

Figure 11. A four-node mirrored configuration


When determining the copy design plan for the worst case, ensure that the members can handle all of the hosted database copies becoming active. If you plan on oversubscribing the members, you can set a maximum number of simultaneous active databases on each member to ensure that more copies than the server can handle do not come online by using the Set-MailboxServer cmdlet with the -MaximumActiveDatabase parameter. When the Mailbox server has reached the maximum, no additional database mounts will be successful. If the Active Manager attempts to mount a database on the server the mount will fail and Active Manager will attempt to mount the database copy on another member if one is available. Also, as usage profiles change over time it is important to periodically evaluate the appropriate level of oversubscription and whether the number of active database copies should be modified to accommodate for hardware and usage changes.

Over the course of time, when maintenance is performed active mailbox databases may end up active on servers that they were not intended for. As part of routine maintenance activities remember to activate the database copies across the DAG. You may also use RedistributeActiveDatabases.ps1, which is included in SP1, to automatically load-balance active database copies across DAG members.

Deciding the number and location of database copies also involves the storage infrastructure and the operational maturity of your IT department. Assuming the operational challenges can be overcome, you should consider a few best practices when choosing whether to use RAID (Redundant Array of Independent Disks) or JBOD as summarized in Table 2.

Table 2. Choosing Between RAID and JBOD in a Single-Site Deployment
NUMBER OF COPIESSTORAGE OPTIONS
Two high availabilityRAID
Three or more high availabilityRAID or JBOD
One active and one lagged copyRAID

When a large number of databases are hosted on each server in a DAG, disk management can become complicated, especially when you are using JBOD storage. Only 23 drive letters are available to mount additional disk drives—A and B are reserved and most likely the operating system is installed on C. When planning a DAG that will require a number of volumes, it is a best practice to use volume mount points rather than drive letters. Volume mount points allow volumes to be mounted as directories rather than drive letters. For example, you may want to mount a 1-TB volume in D:\Databases\Dallas-MB01 to store the Dallas-MB01 database files. You could then mount another 1-TB volume in C:\Databases\Dallas-MB-02 for storing the Dallas-MB02 database files. This way you are no longer constrained by the number of drive letters available.

Using mount points introduces a problem: if the drive that contains the mount points fails, you lose connectivity to all of the other drives. The best practice is to protect the volume that contains the mount points using RAID to reduce the likelihood of a single disk failure taking the entire server offline.

Other -----------------
- Exchange Server 2010 : Achieving High Availability
- BizTalk Server 2009 : Using asynchronous services in WCF (part 3) - Building a client-side asynchronous experience
- BizTalk Server 2009 : Using asynchronous services in WCF (part 2)
- BizTalk Server 2009 : Using asynchronous services in WCF (part 1) - Creating the synchronous service
- Exchange Server 2010 : Troubleshooting Federated Delegation (part 3) - Troubleshooting Calendar and Contacts Sharing
- Exchange Server 2010 : Troubleshooting Federated Delegation (part 2) - Troubleshooting Organization Relationships
- Exchange Server 2010 : Troubleshooting Federated Delegation (part 1) - Troubleshooting the Federation Trust
- Exchange Server 2010 : Federation Scenarios (part 3) - Federating with Online Services
- Exchange Server 2010 : Federation Scenarios (part 2) - Calendar and Contacts Sharing
- Exchange Server 2010 : Federation Scenarios (part 1) - Free/Busy Access
- Active Directory Domain Services 2008: View Settings Defined in Password Settings Objects
- Active Directory Domain Services 2008: Delete Password Settings Objects
- Active Directory Domain Services 2008: Create Password Settings Objects
- Exchange Server 2010 : Fundamentals and Components of Federated Delegation (part 4)
- Exchange Server 2010 : Fundamentals and Components of Federated Delegation (part 3) - Organization Relationships
- Exchange Server 2010 : Fundamentals and Components of Federated Delegation (part 2)
- Exchange Server 2010 : Fundamentals and Components of Federated Delegation (part 1)
- Introduction to Federated Delegation in Exchange Server 2010
- BizTalk Server 2009 : Service-oriented endpoint patterns (part 2)
- BizTalk Server 2009 : Service-oriented endpoint patterns (part 1)
 
 
Most View
- SQL Azure : Azure Server Administration (part 1) - Server Information
- iPad SDK : New Graphics Functionality - We Are All Tool Users (part 1)
- Windows Phone 7 : Setting Your Website Preference
- Windows Phone 7 : Customizing Your E-Mail Signature
- Configure IPv6 in Windows Server 2008
- Windows Home Server 2011 : Using the Local Group Policy Editor (part 3) - Increasing the Size of the Recent Documents List, Enabling the Shutdown Event Tracker
- Exchange Server 2010 : Availability Planning for Mailbox Servers (part 7) - Managing Database Copies
- Exchange 2010 : Managing Exchange Recipients (part 2)
- Windows 7 : Setting Up One-Click Restarts and Shutdowns
- Windows Server 2008: Performance and Reliability Monitoring (part 2)
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS