|
Hi Michael,
I know that grouping multiple SMTP servers by DNS MX records long time
ago. :-) Although it failover is built in SMTP protocol, MTA will try the
second mail server (or the other) when the first receiving mail server is
down or overloaded. I see that the shortcomings of this solution is
possible load imbalance among mail servers, just like Round-Robin DNS web
cluster (we just talk about load here). And, mail server failure probing
will increase internet traffic too.
You point out that LVS add an extra layer in load balancing SMTP traffic,
and the shortcoming is that LVS might fail, it is true if the LVS director
fails. As long as the LVS director will not become the bottleneck and not
fail, the central load balancing solution is better than multiple DNS MX
methods in resource utilization. Right?
Although most mail clusters are using mutilple MX method in this world
now, I think that it is worth trying a central load balancing SMTP
solution for better resource utilization.
For example, mx.domain.com is the load balancing SMTP service (receiving
side) by from mx1.domain.com to mx6.domain.com servers. If you worry about
that mx.domain.com (the lb director) might fail, you can put
mx?.domain.com in the DNS MX records too, but with low priority,
such as
domain.com IN MX 1 mx.domain.com
IN MX 10 mx1.domain.com
...
IN MX 10 mx6.domain.com
If the mx.domain.com fails, mx1..mx6 will be tried, just in the original
way.
Regards,
Wensong
On Tue, 15 May 2001 Michael_E_Brown@xxxxxxxx wrote:
> Wensong,
>
> I agree, but... :-)
>
> 1) You can configure most mail programs to start refusing connections when
> load rises above a certain limit. The protocol itself has built-in
> redundancy and error-recovery. Connections will automatically fail-over to
> the secondary server when the primary refuses connections. Mail will
> _automatically_ spool on the sender's side if the server experiences
> temporary outage.
>
> 2) Mail service is a special case. The protocol/RFC itself specified
> application-level load balancing, no extra software required.
>
> 3) Central load balancer adds complexity/layers that can fail.
>
> I maintain that mail serving (smtp only, pop/imap is another case entirely)
> is a special case that does not need the extra complexity of LVS. Basic
> Queuing theory aside, the protocol itself specifies load-balancing,
> failover, and error-recovery which has been proven with years of real-world
> use.
>
> LVS is great for protocols that do not have the built-in protocol-level
> load-balancing and error recovery that SMTP inherently has (HTTP being a
> great example). All I am saying is use the right tool for the job.
>
> --
> Michael Brown
>
> -----Original Message-----
> From: Wensong Zhang [mailto:wensong@xxxxxxxxxxxx]
> Sent: Tuesday, May 15, 2001 9:40 AM
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Cc: Joseph Mack
> Subject: Re: mail farm?
>
>
>
>
> On Mon, 14 May 2001, Michael E Brown wrote:
>
> >
> >
> > On Mon, 14 May 2001, Joseph Mack wrote:
> >
> > > Michael E Brown wrote:
> > >
> > > > > As far as I am aware DNS should respond with all MX records for a
> > > > > request. The MTA should then choose one at random from the same
> > > > > piority.
> > >
> > > > The above statement is correct.
> > >
> > > And if the machine for that MX record happens to be down, the MTA
> > > will pick another MX record and try to deliver it there? (This has
> > > to be true, I'm sure I read this in the Bat book).
> >
> > Yes. (As long as there _are_ multiple MX records :-)
> >
>
> I think that central load balancing is more efficient in resource
> utilization than randomly picking up servers by clients, basic queuing
> theory can prove this. For example, if there are two mail servers grouped
> by multiple DNS MX records, it is quite possible that a mail server of
> load near to 1 still receiving new connections (QoS is bad here), in the
> mean while the other mail server just has load 0.1. If the central load
> balancing can keep the load of two server around 0.7 respectively, the
> resource utilization and QoS is better than that of the above case. :)
>
> Regards,
>
> Wensong
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
