The basic idea behind mailing cluster is not that difficult to understand: if the load is too high for a single machine to handle it, we try to split the load over multiple machines, or, if we need a very reliable service, we try to put up many machines able to take over in case one of them fails.
Actually, the first kind of cluster is also known as ``high scalability cluster'', while the second kind is known as ``high availability cluster'' (HA -- sometimes the terms ``vertical cluster'' or ``horizontal cluster'' are also being used, but in some environments they take the meaning of how nodes are added, or of how power is added to the system, talking about ``vertical scalability'' and ``horizontal scalability''). The most aimed result for a ISP is usually a very scalable and very reliable cluster, something in between the two, probably one of the hardest results to achieve.
Now, let's say we want to build up some kind of cluster for mailing systems. The only thing we can be sure of is that the cluster will be made of multiple computers (or, at, least it will look like).
As being made by multiple machines, we will probably split up services among those machines, and we will find some way to make those services coexist and share information happily. Yes, because in order to work, they need to share lots of data...
So, let's say we have a single machine handling the load of a whole mail server. Let's say this machine is not able to handle the load anymore, and we want to split it up over a cluster of machines.
We have one, very simple solution at no cost: configuring a second machine as a mail server, and move part of the domains over this second machine. However, this solution has a few disadvantages:
first of all, a single domain can be handled only by a single machine. If we have a very large domain, we cannot split it over more than one machine, so it doesn't scale very well...
it requires us to choose on which machine we want to store each domain. Even in case there is some automatic procedure, we will still have to check that the load is well balanced.
if at a certain time a given domain grows very large, we need to move it from one server to another, not always quite easy to do...
we would need to give some customers some configurations to download their emails, while others would have different configurations, making customer care a pain.
in case the load grows even more, we are still over.
Keep also in mind that the delivery process with the described configuration is not changed at all. It is just like having many mail servers to administer and configure, while taking an eye over load and balancing.
Ok, so what is a real mail cluster? Well, while there are many discording opinions, it is usually meant to be a group of machines handling the load of a given service ``transparently'', that may look like as a single entity both to end users and administrators, where it is easy to add/remove nodes (machines) and where each node, even if we have few users/domains, concurs in handling the load of the whole cluster.
So, how do I build up a mail cluster? Well, there are a few things you will need for sure:
ok, if users, in a way or another, see my own cluster as a single machine, well, all connections will go to that machine. So, there will be some kind of device/appliance/extraterrestrial technology able to distribute (balance) the connections over the cluster of machines. There are many technologies to achieve this result, from the simple DNS round robin balancing (one record that points to many servers) to more complex setups using Linux IPVS or expensive appliances.
Well, if we have a couple machines handling the load, they all need to know who the users/domains being managed are, so, for sure, control data will be shared.
We have seen before that both the SMTP and IMAP/POP3 server need to access the storage. The first one, in order to store new emails, while the second one to give emails back to users. So, in a mail cluster, the SMTP and IMAP/POP3 server will still need to access a shared storage. To make things harder, SMTP and IMAP/POP3 are now split over many machines, and still need to access a shared storage. Well, pay attention, by accessing a shared storage I don't necessary mean accessing a shared file system. There are many alternative ways to make a storage accessible to many machines.
So, what happens when new mails come in? Well, the remote server tries to establish a connection to our own server. While opening the connection, some way or another, the balancer gets in the middle and sends the connection to one of the clustered servers.
And when a customer tries to connect to the IMAP/POP3 server or to the web interface? Same thing as above.