Postfix SMTP relay server in master-slave or master-master mode for load-balancing
Our Customer have MS Exchange as mail server and using sendmail on rhel5.2 as smtp relay server.
We are planning to upgrade the systems to RHEL6.x and need 2 or multiple smtp relay servers in either master-slave or master-master (for load-balancing).
I think postfix smtp relay would be better option but not sure about master-slave or master-master smtp relay configuration.
Is smtp fall_back going to be helpful ? What would be configuration if
My mail server hostname is ----->> mail.example.com
My postfix smtp relay hostnames are ----->> relay1.example.com and relay2.example.com
Do I need to do anything at DNS side ?
Thanks in advanced for reply or update on this
Responses
Guru
6435 points
I'm having trouble determining what you're trying to accomplish. Normally, when I deal with mixed Exchange/Postfix designs, Postfix is acting as a lightweight, inline, inbound-filter to protect Exchange, not generally as an SMTP relay (outbound) for Exchange (are you relaying to Postfix from Exchange to support some kind of policy-enforcement engine?).
Inbound is generally "easy" to do: just set up appropriate MX (DNS) records to distribute load across a set of the filter hosts.
Outbound is a touch trickier, depending on what else is available in your infrastructure. For example, if you have a load-balancer like an F5 solution, setting up a redundant relay service can be as easy as place 2+ Postfix servers behind a managed alias and pointing your relay clients to that alias. Similarly, you could set up round-robin DNS so that relay-clients notionally get balanced across your 2+ relay nodes ("notional" because things like NSCD and other client-side settings can cause any given client to "prefer" to continue mailing through a given SMTP relay node in a round-robin group).
Also, unless you use a clustered mail-queue across your SMTP relay nodes, you have the potential that mail queued on a given relay-node can end up stuck or lost if you lose that node (temporarily or permanently). Depending on your performance needs, however, a clustered queue can slow things down unacceptably.
Overall, to provide guidance, we'd need clearer descriptions of what flow-cases you're looking to handle (i.e., inbound and/or outbound), what kind of performance you're looking for, what kind of resilience you're looking for and what kinds of infrastructure you have to support any given solution-set.
Guru
6435 points
Just for clarity:
- You've got a pair of Postfix servers that act as authoritative MX servers for your Exchange server (presumably, your Exchange server has no MX records pointing to it or, if it does, there's no way for unauthorized hosts to actually talk to it)
- You're now wanting your Exchange server to relay back out through your Postfix servers, preferably in a round-robin fashion
Is the above a fair assessment of your situation?
It should be noted that your Exchange server, after it performs its name lookup of the relay, will most likely continue to attempt to connect to only one of your relays. Windows caches DNS results and will continue to use the results of the first lookup for as long as that result stays in its local cache. Whether or not it attempts a further lookup (before the cache TTL is reached) if the server its becomes unresponsive is unknown to me. That said, I vaguely recall (it's been a decade since I've configured an Exchange server) that you could configure it to load-balance outbound traffic through the use/definition of multiple relay connectors.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.