Marc Haber wrote:
> On Sun, Jan 27, 2008 at 09:57:59PM +0100, Sven Hartge wrote:
>> Alles in allem sind die Queues in unseren drei MXen immer recht voll und
>> wie bekannt ist, performt Exim4 hier nicht mehr wirklich gut, sobald
>> einen gewisse kritische Menge überschritten ist.
>> So, nach dem langen Vorwort nun meine Fragen:
>> Was tun? Separaten Mailout einrichten? Dort z.B. Postfix benutzen? Der
>> soll ja ein besseres Queue-Management im Grenzbereich haben. Oder gar
>> einen ganz anderen, nur auf Mailout spezialisierten MTA benutzen
>> (ZMailer fällt mir da ein).
> Die kanonische Lösung ist wohl, Mails, die schon eine bestimmte Zeit
> in der Queue liegen, per Sonderrouter oder einer der neueren
> Fallback-Optionen an einen Extra-Exim weiterzuschieben, auf dem die
> lange Queue wenigstens die Performance nicht tötet.
"neue Fallback-Option"? Oha, da ist wohl etwas an mir vorbei gegangen.
> Tony Finch hat auf der Exim-Konferenz 2005 die in Cambridge
> eingesetzte Exim-Konferenz vorgestellt, die ist voller sehr feiner
> Tricks und Kniffe für das Management einer größeren Installation.
>
> http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/talks/2005-02-eximconf/
Soweit so gut. So sieht unsere Struktur auch schon fast aus. Wir haben 3
MXe (die derzeit auch den mailout machen), einen extra Webmailer, einen
Client-Server (extern), einen Client-Server (intern), die beiden
letzteren haben auch einen perdition drauf und proxyen damit IMAP und
POP auf den separaten mailstore-server.
Das ganze via LDAP angebunden, damit die Mails gleich direkt von z.B.
dem Webmailer zum Storage oder nach aussen über die MXe gerouter werden
können, ohne "Ehrenrunden" durch die Server drehen zu müssen.
Auch machen die MXe im Falle einer Weiterleitung diese auch gleich
(steht ja im LDAP), so dass die Mails, die das Netz eh wieder verlassen,
_nicht_ erst bis zum mailstore müssen, um dort dann ein .forward (o.ä.)
zu finden.
Alles in allem ist der Kram schon recht optimiert und aufgedröselt.
>> Oder gibt es Empfehlungen, wie man Exim4 hier brauchbar "tunen" kann,
>> ohne durch 200 Queue-Runner die MX-Maschinen zu Tode zu bringen?
>
> Aus Sicht des sites eingehende und ausgehende Mails zu trennen ist
> immer eine gute Idee.
Aufgrund das Spams (über 90% bei uns) und der ganzen dafür nötigen
Rechenpower haben wir mittlerweile 3 MXe hinter einem LVS-Loadbalancer.
Vorher hatten wir mx1, mx2 und mx3, jeweils mit gleicher Priorität und
die Spammer haben sich immer auf mx1 herumgetrieben, die anderen MXe
hatten nur 10% der Reject-Zahlen von mx1.
Und meinen Statistiken nach beanspruchen diese 3 MXe in Kombination mit
dem separaten MySQL-Backend für den SpamAssassin eine Rechenpower, die
zwei Opteron-Kernen mit 2.8GHz entspricht (laut Xen-Statistik von munin).
Und das für 10.000 "echte" eMails pro Tag. So langsam ist das doch echt
nicht mehr normal, was für Mengen an CPU-Power man auf den Kram werfen
muss, damit die Sache noch anständig läuft.
Und als nächstes kommen 2 Mailouts dazu.
....
Ah, sorry für mein unmotiviertes Gerante. Manchmal frage ich (und meine
Kollegen) mich/uns, was wir da eigentlich machen, wenn man doch eh nur
gegen Windmühlenflügel kämpft.
Grüße,
Sven.
