[Postfixbuch-users] Postfix - cluster und shared queues

[Thomas Krieger]

Am Sa Mai 17 2008 schrieb Peer Heinlein:
> Am Freitag, 16. Mai 2008 schrieb Torsten Olschewski:
> > Server möglichst in einer gemeinsamen Queue (NFS Share o.ä. )arbeiten,
> > sodass beim Ausfall eines Servers keine Mail liegenbleiben.
>
> Diese Idee höre ich alle naselang wieder und ich kriege da alle naselang
> auch immer wieder eine Gänsehaut dabei. :-)
>
> Ich kann davor nur dringend abraten. Ganz gleich, was man macht, ein
> solches Setup würde unter dem Strich eher Mails verlieren und für
> Ausfälle sorgen, als wenn man einzelne autarke Nodes macht.
>
> > Kann man jetzt eine Queue von mehreren Servern/Instanzen nutzen?
>
> Ganz grundsätzlich: Nein. Mehrere simultan in einer Queue arbeitende qmgr
> können für einen Mailverlust sorgen.
>
> Ich kenne jemanden, der behauptet, sein Setup auf Basis von DRBD würde
> seit Jahren stabil laufen und alles wäre prima. Trotzdem mag ich mich
> damit nicht anfreunden, ich gehe davon aus, daß er einen gewissen
> Mailverlust hat, aber das nur nicht merkt, zumal dort sehr die Frage ist,
> wie sich dieses Setup unter Vollast verhalten würde -- vermutlich geht es
> erst dann richtig schief, wenn die Queue mal > 100.000 Mails voll ist.
> Mit ein paar wenigen Mails scheint es jedoch halbwegs zu klappen,
> zumindest so, daß es nicht auffällt.
>
> Viel wichtiger ist aber für mich die Frage: Warum sollte man das tun?!
>
> Auf dem Mailrelay befindet sich jede Nachricht fast immer nur wenige
> Millisekunden. Rein-Raus und gut ist. '*Wenn* ein Mailrelay in den ewigen
> Hardware-Himmel aufsteigen sollte, so nimmt es natürlich die zu diesem
> Zeitpunkt in /var/spool/postfix liegenden Mails mit. Doch
>
> a) wieviele Mails sind das überhaupt?
> und
> b) das sind wahrscheinlich eher irrelevante Mails (unzustellbare Bounces &
> Co).
>
> Der Prozentsatz "erwünschter" Mails ist in der deferred-Queue
> erfahrungsgemäß doch eher gering.
>
> Zudem steht es jedem frei, bei einem Crash /var/spool/postfix auszulesen
> und die dort liegenden Mails beim Ersatzrelay nochmal einzuschleusen.
> Insofern droht ein Mailverlust nur bei einer irreparablen Zerstörung der
> Festplatte. Die Zeitverzögerung durch das Recovern der Mails dürfte zu
> vernachlässigen sein -- mit hoher Wahrscheinlichkeit waren das eh bereits
> deferred Mails.

zwei Gedanken möchte ich Peers Ausführungen noch hinzufügen: ein Cluster 
benötigt ein shared Filesystem. Damit schreiben alle Nodes Deines Clusters 
auf dasselbe Filesystem. Das hat aus meiner Sicht zwei Nachteile:
a) Ein Ausfall dieses Filesystems sorgt für eine komplette Downtime
b) Disk-IO: bei sehr vielen gleichzeitig ankommenden Emails musst Du sehr 
   viele Schreibzugriffe parallel auf dem Cluster Filesystem handeln

Die Lösung mit mehreren autarken Mailservern verteilt den Disk-IO automatisch 
auf mehrere Spindeln, was der Performance des Filesystems sicher zuträglich 
ist. Außerdem hast Du keinen Single Point of Failure mit dem Cluster 
Filesystem.

der zweite Gedanke: Ein Cluster Filesystem kann nicht beliebig viele Nodes 
bedienen. Du beschränkst Dir damit die Skalierbarkeit. Autarke Mailserver 
(Mailrelays) kannst Du beliebig aufstocken, wenn Du Performanceprobleme hast

Servus

Thomas