Email Setup
I would like to have three servers, each with their own function.
1) MySQL database to contain information about which domains to accept mail for, user authentication, aliases, etc. (I already have a central DB server)
2) Mail store server for actually holding the messages. Eventually I would like to be able to have redundant mail stores and be able to load balance between the multiple servers.
3) Mail exchange for receiving messages and delivering them to the mail store. All outbound email would be directed through this server also.
I've tried to figure out how to adapt the existing guide to this situation, but I'm having a difficult time figure out how to tie everything together on separate servers. Any help would be appreciated. If you have recommendations for using different software, I would be open to changes.
7 Replies
But try
Richard
If you really need such a system you should get the books for each component of the setup and read up on them. If you are running something important here you really need to understand each part of it, if it's for any company you should document it as well.
@sednet:
It can all be done. My question would be why 3 servers? How much mail are you handling here? Are you running mail for a 100 person company or bigger?
Several reasons.
1) I am a security guy. I like to keep each piece of a system separate because the more pieces there are on a single server the more likely it is to be compromised.
2) I already have a centralized database, so why not utilize it instead of placing the load of another database on one of the mail servers?
3) I have some projects I am working on that could potentially result in a large number of incoming emails.
4) My primary job is in the energy sector. We are very big into redundancy and being able to easily recover if there is a failure. By designing my system in a way like I have described (with more pieces than I described) then I can easily scale my system to handle more mail and to recover if any single piece fails.
5) Three 512s are cheap compared to buying a physical server that won't provide the redundancy, so why not?
@carmp3fan:
4) My primary job is in the energy sector. We are very big into redundancy and being able to easily recover if there is a failure. By designing my system in a way like I have described (with more pieces than I described) then I can easily scale my system to handle more mail and to recover if any single piece fails.
I hope the "more pieces" includes doubling everything you mention and implementing HA and fail-over between them. Otherwise, three per-function single points of failure aren't materially different in terms of protection from one single point of failure for multiple functions. And given the way you're dividing things, fail-over would actually require a full mesh of failure possibilities which is pretty complicated. Certainly much more engineering than I'd want to do until I absolutely needed it, and even then I'd hope I had gone through other simpler configurations to gain experience before that point. Otherwise, you're adding a lot more complexity to the system (which has its own cost and risks of failure if you get it wrong) for minimal gain.
> 5) Three 512s are cheap compared to buying a physical server that won't provide the redundancy, so why not?
I'm not sure I see the redundancy in your proposal for your overall functionality. You still have a single database, a single receiver and a single message store. Yes, you've divided the functionality of the system horizontally, so have some increased protection against host outages, but that's different than application redundancy. A single failure of any one of these three nodes would still take down your end-to-end system. E.g., what's your message receiver going to do with inbound messages when the message store is down or when it can't talk to the database to decide if it should accept the message it's processing? Won't matter much at that point that the node with the mail receiver is still operating.
This approach could make sense if you're dividing the functionality, not for redundancy, but due to not having enough resource on a single node to do all three things. I'm not actually sure that's likely to be the case though. Mail receipt/delivery will largely be I/O bound, the mail store needs disk space, and the database needs CPU and disk space. Seems entirely plausible to put them on a single node.
Of course, if as you say, you've already got a database on another node you can point at, that's fine and no reason not to take advantage of it. But as long as you depend on that database answering for the functioning of your system, don't assume that having it on another node is adding to the redundancy/reliability of your system at all. (Statistically it's probably making it marginally worse since you have a second host whose failure could take you down)
If you want real redundancy it's probably simpler to set up a single node with all three components, and then duplicate the whole thing, including replicating the database and message store among the two mirror nodes. Normal operation just uses the one node but in an outage the other node takes over (either through pre-set HA fail-over, or a manual process).
So in terms of your current mail system, rather than dividing into thirds, just cloning your current setup and implementing the needed replication and fail-over might be an effective strategy.
Of course, if the overall load gets high enough, it would probably be plausible to extract the database to a dedicated machine (plus its mirror, so 4 machines total) but I suspect it might also be simpler to grow the initial pair of nodes vertically for a while first.
– David
The guides are only going to get you so far, they are not written for anyone attempting a setup like yours. There is no substitute for getting a good book on each component of your system and spending the time and effort understanding how each part works. None of it is too tricky but all of it together can get hard. People here will know about the individual parts of your setup and be willing to help but getting all the parts working together is your problem.
Personally I'd use postfix as the MTA with DNSBL's, clamd, spf, spamassassin and cyrus as the backend store. Adding redundant MTA's and cyrus servers is certainly possible. Integrating postfix and cyrus with mysql isn't something I've ever done but it should be possible.