Exchange Server 2013 : Building an Available Messaging System (part 1) - Transport, Namespace Planning

When setting a high-availability goal, consider your recovery priorities; that is, do you want to recover quickly? Do you want to recover to the exact point of failure? Or do you want to do both? Also consider which services are critical and require a level(s) of redundancy or higher availability.

The following sections examine major Exchange concepts or features in the light of high availability.

1. Transport

Transport is the superset of features and functions of the Hub Transport role, including the sending and receiving of messages via SMTP as well as the redundancy features included in Exchange 2013, such as shadow redundancy and shadow transport.

Due to the automation capabilities in Safety Net and shadow redundancy, very little else needs to be considered—except for the location of the transport queue. If you are planning for an outage of any sort that may cause email to queue or to be deferred, as in the case of Safety Net, make sure that you allocate enough storage on the volume containing the storage queues. Safety Net and shadow redundancy both transport lower RPO. Transport itself, however, may cause an outage if the queue location has not been taken into account.

During an outage, email queues may grow considerably. If Exchange is installed on the system volume, or the queues are not located on a dedicated volume, then an outage may be exacerbated considerably by a disk-full condition on an Exchange server.

Your availability concerns for transport will include:

• Transport queue location
• Transport queue volume sizing

2. Namespace Planning

Namespace planning is often a misunderstood topic. The impactions for high availability, however, are substantial. The cheaper side of misunderstanding this topic is an incorrect set of names on a Subject Alternate Name (SAN) certificate. The more expensive side is a total lack of system availability after a failover event has occurred.

The minimum number of name spaces we need for Exchange 2013 has fallen to two. For example, using our Exchange-D3.com name space in a single datacenter scenario, we need the following:

• autodisover.exchange-D3.com
• mail.exchange-D3.com

A graphical representation of the minimum number of name spaces required including a single internet protocol name space is shown in Figure 1. The details of each protocol may be found in Table 1.

FIGURE 1 Single name space

TABLE 1: Name spaces and protocols—single name space

Similarly, if we use a global load balancer or even Round Robin DNS, we are able to utilize a single name space. Table 1 is still valid in this scenario, because two virtual IPs representing each datacenter are stored in the global load balancer and presented to the external client simultaneously. The client will then attempt to access each datacenter's IP address as shown in Figure 2.

FIGURE 2 Single name space with global load balancer

We could quite easily extrapolate this example out to three, four, or more datacenters within a single name space. However, this assumes that connectivity from any point around the globe is roughly equal and that connectivity between datacenters is high speed in order to guarantee a good user experience.

For both of these examples, our SAN certificate entries remain simple:

• autodisover.Exchange-D3.com
• mail.Exchange-D3.com

Assuming, however, that you would like to present a different name space for Exchange housed in different datacenters, as shown Figure 3, the entries on your SAN certificate would read as follows:

• autodisover.Exchange-D3.com
• uk.Exchange-D3.com
• us.Exchange-D3.com

FIGURE 3 Single name space across two datacenters

You may choose to forego SAN certificates altogether and choose to implement a wildcard certificate; however, you are still required to plan your name spaces and define these in DNS.

Availability concerns for name space planning include:

• Internal and external DNS
• Networking (reverse proxy, firewall)
• Load balancer
• Exchange Client Access Servers (CAS)