Connect & Share

Corporate Clustered Mail Server Setup

Organizations with huge staff or even medium sized organizations with heavy mailing activity usually use a clustered setup for handling their mails. Proper internal and client Communication is the core need for any such company and so mail server uptime is of utmost importance for them. I am going to present a case study of the architecture of an actual mail server cluster setup we designed for one of our clients. Environment:
  • The organization is a medium enterprise with work area related to Engineering drawing and CAD designing.
  • The employee strength is around 250.
  • Their mailing activity is heavy as the huge design files are being passed along internally within the organization and even to their end clients mostly using mails and heavy attachments.
  • The staff is located in two different countries with almost the same strength at each office.
Our Task and Resources: Our primary task to build a robust and fail over enabled cluster for their mailing activity. The volume of mails being sent via this cluster was substantial due to the fact that mails were the most important aspect of their daily chores. We were approved to use a six node cluster for their mails. Even though this was a corporate setup, we had to use open source softwares as the client wanted to keep it cost effective.  We used a qmail, vpopmail etc for their cluster preventing the use of any paid softwares. [singlepic=30,320,240,,center] The Setup: As we were allowed to use six nodes for the cluster, we decided to use two nodes for outbound mails ,two nodes for inbound mails and one node for a pop3/imap connector and one as a mail gateway. The hardware configurations for all these nodes was as below:
  • Intel Pentium Dual Xeon 2.8Ghz
  • 2GB DDR2 RAM, 2x500GB SATA Drives
  • Fedora Linux Base OS, 100Mbps Uplink on each node
The setup flow was as below: [singlepic=9,320,240,,] The Actual Functionality: As you can see above, the domain was setup to use seperate nodes to send and receive the mails. A brief explanation of how it all worked together and each node's function is below: MX Records: The domain had two MX records. One was the primary MX which accepted the mails for the domain and prepared them to be fetched by the pop3 connector. The second backup MX record's node was a failover to the primary MX and stored the inbound mails while the primary MX was down. SMTP Servers: The company had a very high volume of outbound mails and so two smtp servers needed to be used. As they had two offices, each of them got a dedicated SMTP server to use. Mail Gateway: Both the SMTP servers were connected to a single Qmail based mail gateway. The mail gateway provided functions like archiving mails to monitor employee activity, filtering content and proper monitoring of the outbound mail stats for the entire company. Pop3 connector: The pop3 connector retrieved and redistributed the mails received by the primary MX server for the domain to the user mailboxes which were made available via webmail or regular POP3 as well as IMAP based mail clients to the employees. This particular mail setup did not require use of round robin DNS as failover functionality was more important than distribution of traffic. This type of setup also gives us the scope of expansion if there is a surge in the mail activity for the client. Another SMTP server for outbound mails or another node to act as the primary mail server can always be added due to the architecture used. I hope you find this case study useful for deploying mail server clusters. Comments are always welcome :)

Leave a Reply