If you would like to read the other parts in this article series please go to:
- Uncovering the Exchange 2007 Edge Transport Server (Part 1)
- Uncovering the Exchange 2007 Edge Transport Server (Part 2)
- Uncovering the Exchange 2007 Edge Transport Server (Part 3)
- Uncovering the Exchange 2007 Edge Transport Server (Part 4)
- Uncovering the Exchange 2007 Edge Transport Server (Part 5)
Introduction
In most Enterprises around the world, e-mail is the most mission critical application. Thousands, and in some cases even millions, of messages are sent and received by users within large enterprises on a daily basis. In addition, internal line of business applications and so on, are dependent on being able to successfully relay messages through the Exchange 2007 Hub Transport servers deployed within the enterprise. This would mean that you must deploy a solid and responsive Exchange 2007 transport infrastructure, that is not only redundant but also load balanced at all levels.
These large enterprises typically receive just as many messages from external recipients such as business partners and customers. Because of this, the Internet facing mail gateways located in the perimeter network should be just as solid and responsive as the internally deployed transport infrastructure. The Internet mail gateways should be available at all times, and just as importantly, configured in a load balanced manner so that inbound messages are distributed equally across the servers.
In this article I will describe how you can configure your Exchange 2007 Edge Transport servers with redundancy and load balancing in mind. Actually, the steps in this article can be used for almost any type of Internet mail gateway solution you may have or may wish to deploy in your environment.
The Solution
For the purpose of this article, the described environment consists of an Internet mail gateway solution consisting of four Exchange 2007 Edge Transport servers spread across two datacenters. Both datacenters are active as shown in Figure 1.
Figure 1: Four Edge Transport Servers spread across two datacenters
As those of you who read the previous articles in this series uncovering the Exchange 2007 Edge Transport role already know an Edge Transport server can be subscribed to an Active Directory site containing one or more Hub Transport servers. Because Hub Transport servers are resilient by default, inbound messages from the Edge Transport servers in the perimeter network will be delivered to a Hub Transport server in the AD site to which the respective Edge Transport server that received an inbound message is subscribed via an Edge Subscription (see part 3 in this articles series for more info on Edge Subscriptions). Since you subscribe an Edge Transport server to an AD site and not to a Hub Transport server in an AD site, and because Hub Transport servers have resiliency and load balancing mechanisms built-in, you do not need to perform any additional configuration in order to archive resiliency and load balancing in an AD site. When you have at least two Hub Transport servers in each AD site, an Edge Transport server is clever enough to deliver the message to one of the other Hub Transport servers should the first one contacted be too busy or down. This happens in a round robin fashion. More specifically, each Hub Transport server in the AD site to which an Edge Transport server is subscribed is listed as smart host for the send connector (known as the inbound Send connector) that is created between the Edge Transport server and the respective AD site.
Note:
When adding a new Hub Transport server to an AD site, you must create a new Edge Subscription to that particular AD site.
So how do we archive resiliency and load balancing from the Internet to the internet-facing Edge Transport servers? This can be accomplished in several ways. The most simple is perhaps to use a hardware load balancer in front of the Edge Transport servers, but since this load balancer also needs to be redundant, you must deploy at least two. Hardware load balancers are not cheap, so do we have a less expensive solution? Yes we do and in fact that is the one I am going to cover in this article.
We simply create two MX records mail1.exchangehosting.dk and mail2.exchangehosting.dk and point both of these to our domain, which for the purpose of this article is exchangehosting.dk. Then we configure each of these MX records with an equal cost (such as a cost of 10). Finally, we add two A-records (Edge Transport hosts) to each MX record. Each MX records should include an A-record from datacenter 1 and datacenter 2. This configuration is illustrated in Figure 2 below.
Figure 2: MX records with equal cost and two A-records each
Two MX records with an equal cost pointing to the same SMTP domain will make sure they will be picked randomly using a DNS round robin fashion. But why two A-records per MX record some of you might ask? Because some message transfer agents (MTAs) will always pick the same MX record no matter how many MX records you have configured for a given domain. In regards to Exchange Server, this hasn’t been a problem for many years (not since Exchange 2000), but unfortunately there are still MTAs out there that still have this design flaw. So no matter which MTA is trying to deliver a message to an Exchangehosting.dk address, all SMTP connections are distributed using a combination of DNS round robin and load balancing.
Providing Fault Tolerance and Load Balancing for Outbound Messages
So how do you load balance as well as provide fault tolerance for outbound mail flow (i.e. Messages leaving the Exchange organization)? Actually this is very easily accomplished. You just have to make sure more than one Edge Transport server is subscribed to an AD site so that they get added under the Source Server tab of the Send Connector which routes messages on to the Edge Transport server(s) in your perimeter network.
Note:
The Edge Transport servers will automatically be added under the Send connector property page, and the settings will automatically be propagated to the Edge Transport servers listed under the Source Server tab.
To verify the Edge Transport servers are present under the Send Connector, you need to open the Exchange Management Console (EMC), and then expand the Organization Configuration work center node in the navigation tree in the left side of the EMC. Here, you should select Hub Transport and then click the Send Connector tab. Next, you should open the property page for the respective Send Connector, and then click the Source Server tab (Figure 3).
Figure 3: Subscribed Edge Transport Server listed under the Source Server tab
All outbound messages will now be load balanced between the source servers and if one is down, for maintenance or other reasons, the Hub Transport server that needs to deliver messages to recipients outside of the organization will select the next source server in a round robin fashion.
Note:
If the Send Connector that routes messages out of your organization is configured to deliver the messages to a smart host, please be sure to add multiple smart hosts, so that you eliminate all single point of failures in your outbound message routing topology.
Summary
In part 6 (which by the way was the last one) in this article series uncovering the Edge Transport server roles, I explained how you can archive true redundancy and load balancing for the message flow between the Internet and the Edge Transport servers located in the perimeter network as well as from there to the AD sites containing your Hub Transport servers.
If you would like to read the other parts in this article series please go to:
