Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Maybe OT: Load Balance MX

19 views
Skip to first unread message

Duracom Lists

unread,
Oct 18, 2007, 5:41:08 PM10/18/07
to
If this is off topic please ignore and forgive me.

I am trying to compare the options for "Load Balancing" incoming email. I
currently have the following:

10 Mx1.domain.com.
20 mx2.domain.com.

The postfix server with the lower preference gets all the email, no email
hardly flows to mx2. The issue is that when under a heavy load mx1 postfix
keeps accepting mail and mail will not flow to mx2 postfix. I am trying to
decide which offers the best load balancing technique.

First:

10 mx1.domain.com.
10 mx2.domain.com.

Same level MX preferences, which from what I understand the sending MTA has
control of the order of preference. What if one of the mx's gets overloaded
or goes down?

Second:

10 mx.domain.com

mx.domain.com A 192.168.1.1
A 192.168.1.2

Use one mx record with multiple A records, which from what I understand BIND
now controls the balancing technique. What if one of the mx's gets
overloaded or goes down?


What are the good and the bad with the above based on Real World Experience?
What would you guys suggest for fairly high incoming volume?


K

Noel Jones

unread,
Oct 18, 2007, 6:31:25 PM10/18/07
to
At 04:41 PM 10/18/2007, Duracom Lists wrote:
>I am trying to compare the options for "Load Balancing" incoming email. I
>currently have the following:
>
>10 Mx1.domain.com.
>20 mx2.domain.com.
>
>The postfix server with the lower preference gets all the email, no email
>hardly flows to mx2. The issue is that when under a heavy load mx1 postfix
>keeps accepting mail and mail will not flow to mx2 postfix.

The above is the common "backup MX" setup. The normal result is
nearly all (but less than 100%) legit mail goes to MX1, and MX2
becomes a spam attractor.

Other MTAs will automatically try MX2 if MX1 doesn't respond.

>I am trying to
>decide which offers the best load balancing technique.
>
>First:
>
>10 mx1.domain.com.
>10 mx2.domain.com.
>
>Same level MX preferences, which from what I understand the sending MTA has
>control of the order of preference. What if one of the mx's gets overloaded
>or goes down?

With the above, mail will be randomly assigned to either server by
the client MTA. If one server is slow but still responds, it will
still get its share of connections unless/until it gets so overloaded
that incoming connections time out. When one server doesn't respond
for any reason, MTA clients will automatically try the other
one. One server can be taken down for maintenance without
significantly affecting service (assuming the remaining servers are
sufficient to handle the load).

This is the common setup for gateway MX's that want load sharing and failover.

>Second:
>
>10 mx.domain.com
>
>mx.domain.com A 192.168.1.1
> A 192.168.1.2
>
>Use one mx record with multiple A records, which from what I understand BIND
>now controls the balancing technique. What if one of the mx's gets
>overloaded or goes down?

When a single hostname resolves to multiple A records, some MTA
clients[1] might assume it's a single multi-homed host and skip the
second IP if the first doesn't work. Other than that possible
drawback, behavior should be the same as "multiple equal-weight MX
records" option.

[1] it's been reported that (some version of)? Sendmail behaves this
way, and possibly other MTA software. Postfix does not make this
assumption and will consider all IPs.

You need to use a hardware load balancer to choose between back ends
when one is "slow but working". MX records can only even out the
number of connections, not the actual amount of data processed (but
it usually averages out pretty close anyway).

--
Noel Jones

Victor Duchovni

unread,
Oct 18, 2007, 6:56:53 PM10/18/07
to
On Thu, Oct 18, 2007 at 05:31:25PM -0500, Noel Jones wrote:

> When a single hostname resolves to multiple A records, some MTA
> clients[1] might assume it's a single multi-homed host and skip the
> second IP if the first doesn't work.

Where "doesn't work" means returns a 4XX response leaving more recipients
to deliver. If connections fail, typically the second address will be
tried.

> Other than that possible
> drawback, behavior should be the same as "multiple equal-weight MX
> records" option.
>
> [1] it's been reported that (some version of)? Sendmail behaves this
> way, and possibly other MTA software. Postfix does not make this
> assumption and will consider all IPs.

Sendmail will try a second connection, but not a second delivery attempt
after 4XX when multiple A records share a single name.

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Noel Jones

unread,
Oct 18, 2007, 7:03:32 PM10/18/07
to
At 05:56 PM 10/18/2007, Victor Duchovni wrote:
>On Thu, Oct 18, 2007 at 05:31:25PM -0500, Noel Jones wrote:
>
> > When a single hostname resolves to multiple A records, some MTA
> > clients[1] might assume it's a single multi-homed host and skip the
> > second IP if the first doesn't work.
>
>Where "doesn't work" means returns a 4XX response leaving more recipients
>to deliver. If connections fail, typically the second address will be
>tried.
>
> > Other than that possible
> > drawback, behavior should be the same as "multiple equal-weight MX
> > records" option.
> >
> > [1] it's been reported that (some version of)? Sendmail behaves this
> > way, and possibly other MTA software. Postfix does not make this
> > assumption and will consider all IPs.
>
>Sendmail will try a second connection, but not a second delivery attempt
>after 4XX when multiple A records share a single name.
>
>--
> Viktor.

Thanks for the clarification, I'll keep that in mind.

--
Noel Jones

0 new messages