smaller reset larger        English         

Main Menu

All times are in GMT -8 (DST) :: The time is now 1:16 pm.

Sub Menu

Article Data
Article Ref
8680-TICB-4409
Written By
Philip Slater
Date Created
Thu, 12th Nov 2009
 
(Lost?)

   Distributed Domains Overview

Question 

How do you handle email that are to be handled on different geographically located servers?

Answer 

Distributed Domain is a domain that has accounts hosted on multiple servers. Most likely this is due to the servers being in different geographical locations. Accordingly, mail is routed to any of the servers based on the MX record. This may be a geographic MX record, regular MX record or MX record with multiple entries like a backup MX record. In order to set up a distributed domain, each CGP server involved must have a 'remote root unit' for the LDAP records and must have a 'node name' for the main domain name. The domain which is to be hosted will be created as a secondary domain. The reason for each of these is that in the LDAP record for the account the server name is part of the account properties.

Sample remote servers
moscow.wilhelm.scr
mv.wilhelm.scr
berlin.wilhelm.scr

LDAP server
ldap.wilhelm.scr

Mail domain
wilhelm.scr

Each of the remote servers have a remote root pointed at ldap.wilhelm.scr and directory integration is enabled. This means as the account ccolton@wilhelm.scr is created on mv.wilhelm.scr an LDAP entry for the account is created on ldap.wilhelm.scr with the uid=ccolton,cn=wilhelm.scr and hostServer=mv.wilhelm.scr. Another example is the account wwatson@wilhelm.scr being created on moscow.wilhelm.scr with the entry on ldap.wilhelm.scr showing the hostServer being moscow.wilhelm.scr.

On each servers Settings/General/Cluster page there is an option at the very bottom for Directory Based Clustering which needs to be set to enabled.

This means that for every mail that comes in to CGP the router will check against the accounts that are on the local server and any account not on the local system will be checked against the LDAP server for proper routing. So an email that comes in to mv.wilhelm.scr for wwatson (on moscow) and ida (on berlin) and ccolton (on mv) the mv.stalekr.com server will locally deliver to the account ccolton and then relay the message to the moscow and berlin server for delivery. Same thing happens when roman (on moscow) sends an email to the above three addresses: moscow handles wwatson, mv handles ccolton and berlin handles ida.

Now this means you can also have geographic MX records i.e. everything in North & Souther America goes to mv.wilhelm.scr all of EMEA goes to berlin.wilhelm.scr and all of Russia goes to moscow.wilhelm.scr. This will keep mail from Italy from being relayed off of mv.wilhelm.scr and can make the direct path to berlin.wilhelm.scr.

There is also a nice level of backup with this as all three servers can be in the MX record so if the primary server is down it can go to one of the other regional servers and be held there until the server comes back online.

Point of failure of course is the LDAP server as this must be available at all times otherwise mail will fail to route correctly and unknown account messages/rejects will occur if there is a failure.

Licensing: Each remote server handling mail must have a unique license with node name i.e. not wilhelm.scr and must be mv.wilhelm.scr for example.
LDAP server: It is highly recommended that the LDAP server be a CGP server in 'free mode'. Reason: It works, easy for support to trouble shoot and more importantly has all the necessary object classes and attributes needed. This can be made semi redundant with hot standby and backups of the /var/CommuniGate/Directory directory.

Relevant documentation and images can be found at http://www.communigate.com/CommuniGatePro/CentralDir.html#DirectoryDomains

How Useful Was This Article?      (Rating: 0    Votes: 0)  

Select a Rating

Article Comments 

There are currently no comments.