Hello World, 

Today, we will speak a little bit about the new Exchange 2010 High Availability (HA) features. 

Exchange 2010 has simplified the way you can achieve HA. High availabilty and site resilience is achieved using the same technology, the same interface and the same concepts.  Another improvement with the HA feature is that you do not need to have expensive shared storage (SAN). You can create your HA Exchange server solution with only local disks. Isn’t it cool ? 

Compared to Exchange 2007,  we can immediately notice an improvement in the way you need to create a HA solution.  In the past, you could build up a Single Copy cluster (SCC), a Cluster Continuous replication (CCR) or a standby cluster replication (SCR) to achieve either HA or site resilience. Exchange 2010 has unified all these concepts and solutions into a single HA/Site resilence concept based on the log shipping technology introduced in Exchange 2007.  

Exchange 2010 HA – New Concepts and Features

Exchange 2010 introduces the concept of database mobility.  The database is not attached anymore to a server. So, you can move your database easily within your Exchange Organization.  Using the log shipping technology and the concept of database mobility, an administrator can “replicate” a database from one server to one or multiple other servers. If the server hosting the source database fails or crashes, one of the replica will be activated and the service will be available quickly. Note also that Exchange 2010 does not use anymore the concept of Storage Groups. 

Another improvement of the HA is that you can perform a incremental deployment.  This means that you can add on the fly a cluster to your Exchange Organization.  With previous versions, you would need to setup a Cluster first, then install the Exchange cluster aware version.  In Exchange 2010, you can decide at any moment if you want to have HA solution without installing a underlying Cluster infrastructure.  Exchange 2010 has still a dependency with cluster layer but it’s minimum. Exchange 2010 will use the clustering heartbeat component , the cluster networks and the cluster database to check the health status. You do not need to create the cluster before enabling HA feature.  Exchange 2010 setup routine will take care of that  for you.  

An Exchange 2007 clustered mailbox servers couldn’t have only 2 hosts (CCR) and could not host any other Exchange server roles. If you implement a cluster Exchange 2007, you cannot install the CAS or HT role on it.  you need to install these roles on a different computer.  This is not the case with Exchange 2010.  You can now co-locate the Mailbox roles (in a cluster) and Client Access (CAS) or Hub Transport Role on the same computer. 

Exchange 2007 was using the concept of Transport dumpster (when a cluster was present) to ensure that no messages were lost.  The transport dumpster is basically a queue of recent emails sent maintained on the Hub Server.  In case of failure, the Hub server would be using this queue to resend messages and minimize the impact of the loss of service.  Exchange 2010 is using a similar concept called shadow redundancy. Here the Hub transport server will wait for delivery acknowlegement of a message before deleting the message for it’s queue. 

Note also that you can have Exchange servers located on different subnets/Different Active Directory Site and still be able to create a HA availability.  This has become a supported configuration with Exchange 2010.  

Exchange 2010 introduces the concept of Database availability Groups (DAG).  When you implement the HA solution, you will create a DAG.  The DAG will contain/group the source database and the replicas involved in the continous replication process.   The DAG can contains up to 16 MBX servers. Each mailbox servers can hold a maximum of 100 database (active and passive) excluding for the restore object. 

Exchange 2010 is using the Active Manager as a replacement of the cluster resource model. Each Mbx server member of a DAG has the Active Manager component “installed” . in a DAG, we will have a Primary Active Manager (PAM) and Secondary Active Manager (SAM).  The PAM is the master of the DAG and can notify other group members about changes.  By default, the PAM server is the server that own the cluster quorum.  The Exchange replication service is used in the DAG concept and perform health check of the DAG.  Active Manager is a smart component. if a database failure occur, before performing the failover operation, the manager will try to find the best source location for the log files.  He will try to find the copy last logs attempts (CLLA) on one of the servers.  If all logs files are available, the failover can start and there no loss (lossless situation). If not all log files can be retrieved, the system will check its configuration and will look for the automoundial value (best performance, best availability…). If the appropriate value is found, the failover can happens, if not a manual intervention will be required. 

Database availability Groups in Details

This section will quickly provides important information about the DAG. We will mention some limitations or things you need to know in order to have a smooth DAG implementation. Let’s go  

• 1 Database can have up to 16 copies within a DAG. Note also that these DB have all the same GUID
• Mailbox servers participating in a DAG must be member of the SAME Domain
• Database copies aren’t supported if round trip network latency is greater than 250 milliseconds. In other words, you need good connectivity
• Log shipping is not using SMB protocol but TCP protocol
• Database Path should be identical on Mbx servers member of a DAG.  If you want to replicate the Database c:\MyDB from server 1 to Server 2, the database path on server 2 should be set to c:\MyDB
• You cannot have 2 copies of the same database on the same server
• A Domain controller hosting also the Mailbox Server role cannot be member of a DAG
• DAG name cannot be more than 15 characters. DAG name will become a computer AD object
• Exchange Standard and Exchange Enterprise Edition can use the DAG technology. however, remember that you need Clustering component of the Operating System. Thus, you need to use a Windows 2008 Enteprise Edition for the Underlying Operating System.
• 1 or more network card supported.  a single network card is supported. However, it’s recommended that each Mailbox server participiating in a DAG should have 2 network cards.  We will be able to create 2 DAG networks : a Single MAPI network and a single Replication network.  You can have only one MAPI network but multiple replication network.  You cannot choose preferred replication network if multiple are present.  The system will randmonly pickup one. By using 2 networks card, you provide fault tolerance.  if the replication network fails, replication can occur through the MAPI network

Note :

• If an administrator wants to activate a database copy, we will speak of a switchover.  (manual intervention)
• Failover process will happen when a database has encountered a problem and the system activate a replica of the database (automatic intervention)   

 

Site Resiliency

You can achieve site resiliency using the DAG concepts.  However, to avoid the split brain syndrom, you need to enable additonal settings.  When you have 3 or more server in a DAG and if you have multiple sites, you need to enable the Datacenter Activation Coordination (DAC). This setting is disabled by default.  In a split brain syndrom scenario, each location can think that they have the quorum and they can start their normal operations.  This will lead to conflicts in the replication process. 

To avoid this situation, Exchange 2010 uses the DAC and the Datacenter Activation coordination Protocol (DACP).  In a few words, when the DAC is enabled, Active Manager store a bit value (0 or 1) in memory.  In DAC configuration, when the Active Manager starts, the value is set to 0. Before a server can mount a database, it needs to take contact with all members of the DAG group and check if there is no server returning the bit value of 1.   If a datacenter crashes and come back to life after a while, the DACP will ensure that only one location can proceed normal activities.

To enable DAC mode , you use the Exchange shell and you type something like this :  Set-DatabaseAvailabilityGroup -Identity DAG2 -DatacenterActivationMode DagOnly 

For more information, have a look here 

HA for Other servers Roles

You cannot achieve high availability if you only cluster you mailbox servers.  Other Exchange Server Roles are needed and you need to take into account that these servers roles might be configured in a redundant manner to ensure a real high available environment.

Edge Transport Role

To achieve redundancy and high availability, you can

• Install multiple Edge Servers
• Configure Network load balancing or DNS Round robin

Hub Transport Role

To achieve redundancy and high availability, you can

• Install multiple Hub Servers
• nothing to configure Exchange automatically load balance traffic between Hub Servers

Client Access Server Role

To achieve redundancy and high availability, you can

• Install multiple Client Access Servers
• Configure Network load balancing or DNS Round robin or third party load balancer

Important Note :

If you are running DAG servers and you want to co-locate CAS/HT on them, you have to know that you cannot use NLB and Failover cluster concurrently on the same machine. So, to achieve High availability with CAS, you need to use a third party load balancer.  One option could be the use of ISA server 2006

Final words

That’s it for this post.  I know i have presented a lot of information but this might be useful as a reminder in case you need to quickly check something.  In a future post, we will provide a step by step guide on how to perform a DAG installation and configure DAG networks

Till next time

See ya