by Robert Martin, Lead Principal Consultant
Given the complexity of integrating Microsoft Exchange and IBM Domino environments in a cohesive coexistence solution, it’s not surprising that one thing Messaging Engineers struggle with is providing for Highly Available and Load Balanced designs in their coexistence infrastructure.
In the following post, I will describe the various techniques for providing both High Availability and Load Balancing in a coexistence design utilizing the Binary Tree CMT for Coexistence toolset. I’ll discuss the major components of coexistence and how each component can be configured to provide the necessary level of availability and throughput required by the customer. The major components are:
- Mail/Calendar Routing
- Free/Busy Connectivity
- Directory Synchronization
- Application Remediation
In some instances, providing for one need (such as load balancing) will naturally follow through with the other (high availability). In other instances, this will not be the case, and each need will have to be configured and will operate independently of the other.
Load Balancing and Fault Tolerance of Mail and Calendar Message Routing
This post will discuss setting up a load-balanced solution within a single Domino Domain. I will discuss leveraging it for multiple Domino Domains in a future post. Because CMT for Coexistence utilizes native transport protocols for both IBM Domino and Microsoft Exchange, the techniques for providing load balancing differ significantly depending on the direction of message flow. The following describes how to configure load balancing in each direction:
Domino to Exchange Message Load Balancing
In most coexistence scenarios, message traffic requirements and the duration that coexistence must be maintained does not warrant the use of more than one CMT for Coexistence Domino server acting as the messaging coexistence gateway. Other scenarios may require the deployment of more than one CMT for Coexistence Domino server to serve a Domino Domain.
An example of one such instance may be when the Domino environment is geographically separated by slow or saturated WAN links. If the corresponding Exchange servers are deployed to mirror the Domino environment, it may not make sense for a message from one site to traverse a slow WAN link in order to cross the coexistence gateway, only to have to traverse the same WAN link to be relayed to the intended recipient. This is extremely inefficient and a large amount of traffic can quickly overwhelm the link. Optimally, the message traffic should be relayed to a coexistence server within the same site as illustrated below.
READ MORE >>
Another scenario may be that the high volume of mail traffic necessitates the deployment of multiple Messaging Coexistence servers. Although a properly sized and configured Domino Coexistence server can easily process and relay more than 20,000 messages per hour, extremely large organizations can quickly reach this level of messaging traffic once they’ve migrated a large number of their users to Microsoft Exchange. In this scenario, a single Domino Coexistence gateway is not enough to handle the amount of mail traffic generated. Message traffic from mail servers in the environment needs to be balanced across multiple coexistence servers as illustrated below:
Both scenarios involve deploying multiple Coexistence servers within the Domino Domain and then directing a subset of mail servers to specifically use one of them and not the other.
Because CMT for Coexistence
requires that Notes routing (NRPC) be used between Domino mail and coexistence servers, deploying multiple coexistence servers requires creating multiple Foreign Domain
documents. Since there is no field within a Foreign Domain document to restrict its use to a particular mail server, and because the Mail Server field within that document does not support Domino Cluster or Server Group names, we must limit which Foreign Domain document is replicated to any given mail server.
Limiting the replication of a Foreign Domain document is accomplished by setting the '$Readers' field within the document to allow only specific servers to have read access to it. There are three (3) other standard readers fields on the Foreign Domain document that may allow a user or server to read the document. They are the:
The DocumentAccess field is set to [NetModifier] by default. The LocalAdmin and ListOwner fields correspond to the Owner and Administrators fields on the Administration tab. Because all servers within a Domino Domain are members of the LocalDomainServers group by default, and that group is assigned the [NetModifier] role, it is necessary to change the DocumentAccess field to some other value to keep it from replicating to all servers in the Domain. Unfortunately, there is no direct way to edit this field, as it is not included on the Foreign Domain document form. A simple action agent can be written to adjust this field to another value, such as a distribution hub server.
The following steps describe how to deploy two (2) different Foreign Domain documents within a Domino Domain in support of the mail flow shown in the illustration above: