\[Editor's Note: Email your Exchange Server and Outlook solutions (400 words maximum) to R2R at [email protected]. Please include your phone number. We edit submissions for style, grammar, and length. If we print your contribution, you'll get $100.\]
In Reader to Reader, "Multiple Hosts on the IMS," March 2001, Fred Homa describes load-balancing SMTP services through the use of a round-robin process. Although Fred's implementation might be masterful in the use of the Internet Mail Service (IMS) and DNS, I would hate for less experienced readers to think that round-robin DNS is load balancing. The problem with a round-robin process is that it doesn't determine whether the SMTP host is up—it just uses the next server in line, regardless of whether the box is up. Therefore, the result might be mail failures and nondelivery reports (NDRs) and, to top it off, the failures and NDRs would be inconsistent.
Load-balancing email has many facets. I'll describe what my team has done in Exchange Server 5.5 and why I think our scheme works. (This technique works in Exchange Server 5.5; because Exchange 2000 Server is completely different, it requires a different solution.) First, the core of our Exchange environment is an Exchange site (SMTP-A) that houses only Exchange servers with SMTP connectors and other connectors to other Exchange sites—a hub-and-spoke configuration. If you place your SMTP Exchange boxes in one site, the other sites (mailbox servers) will use their routing table to locate the site and servers that have an IMS. When mail arrives at the SMTP-A site, if one server is down, mail will continue to flow out.
To handle outbound mail for non-Exchange mailbox users (e.g., UNIX, OpenVMS, other systems that use SMTP for internal communication), we've currently configured these foreign systems not to do smart lookups. These systems simply forward all mail to mail.mydomain.com or mailhost.mydomain.com. Forwarding the mail is the only lookup those boxes do because their primary function isn't handling mail. All companies don't need to handle non-Exchange mail the way we do, but we want all email traffic to funnel in and out of the company through one pipe and we want servers doing the job we design them to do. Our scheme makes management easier in many aspects, especially when gathering metrics on SMTP and other services.
In this environment, a round-robin process won't provide load balancing if an SMTP box goes down. Instead, you need to use either load-balancing software or hardware, such as Microsoft Windows NT Load Balancing Service (WLBS), F5 Networks' BIG-IP Controller, or Cisco Systems' MultiNode Load Balancing (MNLB) system. These products will truly load-balance your SMTP service because they let you configure the load-balancing solution to be port specific. For example, the UNIX systems send mail to mailhost.mydomain.com, which resolves to an IP address on BIG-IP. BIG-IP determines which SMTP server is available and will accept the SMTP request the fastest.
WLBS works similarly but incurs a small amount of overhead on the SMTP boxes and typically isn't as robust as a hardware solution. However, because WLBS is free, you might consider it for load-balancing simple services such as HTTP or SMTP. Be warned that with Layer 2 switches, WLBS has certain problems, such as increasing broadcast traffic on your LAN. See the Microsoft articles "Configuration Options for WLBS Hosts Connected to Layer 2 Switches (http://support.microsoft.com/support/kb/articles/q193/6/02.asp) and "MS Windows NT Load Balancing Service Whitepaper" (http://www.microsoft.com/technet/winnt/winntas/technote/wlbswp.asp) for details, and investigate the product's pros and cons before you implement it.
Your servers can and will have hardware or software failures. Therefore, if your customers and users depend on email, you need to research solutions other than the one that Fred proposes.
The load balancing that I described had to do with the features that I used in our SMTP relay host that uses proprietary software. My goal was to explain how administrators can use their IMS more effectively in the absence of more expensive solutions. I never claimed that this undocumented IMS feature is the only way to accomplish redundancy and load balancing.
