Designing High Availability for Mailbox Server: DAG
A DAG is a logical grouping of servers that can be used to provide high availability for mailbox databases. A DAG can contain up to 16 servers. A mailbox database has a single active copy on one of the servers in the DAG. Client requests are serviced by the active database copy.
Each mailbox database in a DAG can have one or more passive copies. Log shipping is used to copy each full transaction log of the active database copy to servers with a passive copy of the database. The logs are played on passive copies of the database to update them with the same information as the active copy of the database.
You can manually switch the active copy of a mailbox database from one server in the DAG to another. When you do this, the current transaction log, which has not yet been replicated, is copied to ensure that no data is lost.
Failover occurs when the active copy of the database becomes unavailable. During failover, it may not be possible to access the current transaction log for the database. Nonreplicated messages are recovered from the transport dumpster on Exchange Server 2010 Hub Transport servers. The transport dumpster keeps a copy of messages until they are replicated.
DAGs require the Windows Server 2008 clustering feature. However, the Active Manager component of the DAG is responsible for directing Client Access servers to the active copy of the database. The Active Manager runs on all Mailbox servers that are DAG members, and runs as either the primary active manager or a standby active manager. The primary active manager is the Active Manager in a DAG that decides which copies will be active and passive, and it is responsible for processing topology change notifications and reacting to server failures.
Designing High Availability for Hub Transport Server: Shadow Redundancy
Each Active Directory site with an Exchange Server 2010 Mailbox server requires at least one Hub Transport server to process the delivery of messages. If there is no Hub Transport server available in an Active Directory site, Exchange Server users with mailboxes in that site will not be able to send or receive messages.
High availability for message transport is particularly important for Hub sites. When a Hub site exists on a routing path, all messages are forced to go through a Hub Transport server in that site. If no Hub Transport servers are available in a Hub site, then messages cannot be delivered on that routing path.
To implement high availability for message transport in a site, you need to install multiple Hub Transport servers in the site. No additional configuration is required. If one Hub Transport server in a site is unavailable, Exchange services will automatically use the other Hub Transport server for message transport.
Applications that use a Hub Transport server for message relaying will not automatically failover to another Hub Transport server unless the application can be configured with multiple destinations. To provide high availability for applications, you must configure a load-balancing cluster for the Hub Transport servers.
When a Hub Transport server fails, it may have messages in a queue waiting to be delivered. These messages will be lost. However, shadow redundancy ensures that messages are not lost. With shadow redundancy, messages remain in the transport dumpster of other Hub Transport servers until they are notified that the message has been delivered.
You need to determine how many Hub Transport servers are justified for high availability. In branch offices with a single server performing multiple roles, high availability for message transport may not be important. For a main site with a large data center hosting mailboxes for thousands of users, you might decide that three Hub Transport servers are necessary to provide the necessary level of redundancy. The Hub Transport server role is commonly combined with the Client Access server role.
Designing High Availability for Client Access Server: Array
To implement high availability for a Client Access server, you use load balancing between the Client Access servers and also create a client access array. You can use hardware-based load balancing or software-based load balancing. Windows Server 2008 includes the NLB feature. Your organization can select the type of load balancing that you are most comfortable with. However, be aware that you cannot implement the NLB feature if the server is also a DAG member. You will need to use hardware load balancing.
All Client Access servers in the array must be configured with the same Secure Sockets Layer (SSL) certificate. This is because all Client Access servers use the name specified in the client access array.
For Internet users, you need to consider redundant Internet connections as part of your design. You can have two separate Internet service providers and allow access through both to the Client Access servers in your organization. If one Internet service provider experiences a failure, users can access their mailbox content by using the alternate Internet service provider at a different domain name.
Alternatively, if you configure each Active Directory site to be available directly from the Internet, the failure of a single Internet connection will affect connectivity only to one Active Directory site. This mitigates the damage caused by failure, but does not provide complete redundancy.
Designing High Availability for Edge Transport Server: MX Load balancing
The failure of an Edge Transport server can prevent an organization from receiving new Internet messages. It can also prevent Exchange Server 2010 users from sending messages to Internet recipients. In many cases, an interruption in Internet e-mail is considered a critical business event.
To make the Edge Transport server role highly available, you can install a second Edge Transport server. For external message delivery, no additional configuration is required. For message reception, you must configure an additional MX record for the second Edge Transport server. If both MX records have the same priority, then incoming messages are load-balanced between the two Edge Transport servers.
To provide network redundancy for message delivery to the Internet, you can use two ISPs. Many firewalls are capable of failing over to a second Internet connection when the primary connection fails. To receive messages on the second Internet connection, you must create additional MX records.
If your Exchange Server organization has multiple points of contact with the Internet and multiple locations with Edge Transport servers, this does not provide redundancy for outgoing messages. Messages are delivered only on the lowest cost path. If the Edge Transport servers on the lowest cost path are unavailable, the messages are queued on a Hub Transport server for delivery to the Edge Transport server. Routing paths are not recalculated based on availability.
Designing High Availability: Multiple Roles Server
Exchange Server 2010 allows you to combine multiple server roles on a single Exchange server. For example, a branch office may have only a single Exchange server that performs the Mailbox, Client Access, and Hub Transport server roles. Even in larger organizations it is common to combine the Client Access and Hub Transport server roles on a single Exchange server.
An Exchange server with multiple server roles can be a member of a DAG or a client access array. However, a DAG member cannot also be a member of a NLB cluster. In this case, you can use hardware-based load balancing instead of NLB.
When planning capacity and optimizing performance, you need to consider not only the roles that are running on the server now, but the additional load that will be placed on the server when another server fails. For example, a single server that is a member of a DAG and in a client access array will experience a load increase if another server in the DAG or another server in the client access array fails. This makes performance planning more complex.