If your business has ever suffered an email outage, you already learned the hard way why a backup plan is important. Email downtime is not just an inconvenience anymore: according to ITIC's 2024 Hourly Cost of Downtime Survey, 90% of firms say one hour of downtime costs more than $300,000, and 41% say it costs $1 million to over $5 million. To help protect against that kind of interruption, MDaemon Email Server can be configured in a multi-node cluster.
How MDaemon clustering works
MDaemon's Cluster Service shares configuration between two or more MDaemon servers on your network. One node is designated Primary, and the rest are Secondary nodes that replicate the Primary's configuration. Mail folders and public folders are not replicated by the cluster service itself; they must be located on shared network storage that every node can reach. Load balancing hardware or software then routes mail (and, depending on your setup, Webmail and MDaemon Remote Administration (MDRA) traffic) to a secondary node if the primary node goes down.
MDaemon can also mirror mail queues to Secondary nodes and, depending on how you configure Multi-Node Mail Routing, distribute mail handling across the cluster, which helps prevent messages from getting stuck in the queue if a server goes offline. Neither of these is enabled by default; both queue mirroring and Multi-Node Mail Routing are optional settings you can enable in the Cluster Service console.
If the Primary node needs to come out of rotation, whether for planned maintenance or an unplanned failure, a Secondary node can be promoted to Primary using the Promote option in the Cluster Service console, and the former Primary rejoins the cluster as a Secondary once it's back online. In setups with more than one Secondary node, the additional Secondary nodes may need to be removed and re-added to the cluster after a promotion.
What to plan for before you configure clustering
A few requirements are worth knowing before you set up a cluster:
- Shared storage. Mailboxes, public folders, and related directories must be located in a shared network path accessible to every node in the cluster. Moving existing mailbox and folder data into that shared path is a manual step; MDaemon does not automate the migration for you.
- Matching versions. Every node in the cluster must run the same version of MDaemon, and each node requires its own MDaemon registration key.
- Sticky sessions. Webmail, MDRA, and XMPP traffic aren't cluster-aware, so your load balancer must use sticky sessions to keep a given session routed to the same node for its duration. We recommend routing all HTTP and XMPP traffic to the Primary node as the simplest setup.
- Certificates and time zones. SSL certificates and certificate settings replicate automatically from the Primary to Secondary nodes. All nodes must be set to the same time zone and kept to the exact same time.
- Attachment linking. This feature cannot be used in a cluster and is automatically disabled when clustering is enabled.
- Storage performance. Because clustering depends on shared network storage, we recommend testing that storage's latency and I/O performance under real-world load before going live.
Why it's worth setting up clustering in MDaemon
With email still handling the bulk of business-critical communication, clustering multiple MDaemon servers together can help reduce the risk of downtime and improve redundancy across your mail environment.
Watch our video for a quick overview of MDaemon’s clustering features, or click here to download the MDaemon Clustering How-to Guide.
