Re: OT: Mailspool ueber NFS?

On Wed, Jul 23, 2003 at 10:18:36PM +0200, Olaf Hoyer wrote:
> Moin!
>
> nachdem sich die Wellen der letzten MTA-Diskussion etwas gelegt haben,
> wollte ich ebenfalls nochmal die Neuauflage eines auch haeufiger
> angesprochenen Themas anstossen...
>
> Einiges davon sei nur mal als prinzipiell machbare Theorie aufgefasst,
> bzw. ich moechte auch mal einige Praxisberichte hoeren, wie bestimmte
> Sachen laufen etc. (Mailinglistenarchive von teilweise vor 2000 koennen
> Inhalte wiedergeben, die sich laengst geaendert haben)
>
>
> Situation:
> MTA, der auf dem host keine lokal angelegten User mit /var/mail/$USER
> hat, sondern seinen ausgehenden Spool unter /var/spool/mqueue ablegt.
> (Nicht-sendmail entsprechend anders)
>
> Aus Platzgruenden/Redundanzgruenden soll dieses Verzeichnis per NFS von
> einem grossen Filer gemountet werden, also Kiste mit dickem RAID oder
> Storageloesung wie NetApp etc.

Eine mqueue ist normalerweise recht leer.
Wenn nicht, dann läuft etwas komplett falsch oder du versorgst offline
Systeme.

> - Die Meinung darueber ging etwas auseinander, wie ich bisher gelesen
> hatte. Unterm Strich konnte ich herauslesen, dass aehnliche Setups
> (sofern vernuenftiges Locking gegeben ist) recht gut laufen.
> OS waere hier FreeBSD, evtl. Solaris im Backend, teilweise gemischt.

Genau - von daher würde ich auch davon abraten.
lockd ist erst bei FreeBSD-5.1 potentiell brauchbar - allerdings habe
ich da immer noch Zweifel.
Eine 5.1 ist eh nicht für Produktionsbetrieb zu empfehlen.

> Weitere Ferkeleien, die mir noch so durch den Kopf geschossen sind:
>
> Was passiert, wenn man sendmail eingehende Mail nur queuen laesst, und
> der annehmenden Maschine untersagt, queue-runs zu machen, den spool dann
> gleichzeitig per nfs auf eine andere Maschine exportiert, die explizit
> nur fuer queue-runs zustaendig ist? Kommen die sich noch irgendwie ins Gehege,
> oder ist das unfallfrei?

Wenn locking funktioniert, dann ist das realisierbar.
Macht aber wenig bis gar keinen Sinn.
Besser ist es die Mails per internem SMTP weiter zu leiten, dann kann
der Outgoing MTA wenigstens sofort loslegen, da er Kenntnis von der
Mail hat und wartet nicht erst zum nächsten Queue-Run.
Wenn dich die zusätzliche Received Zeile stört, dann konfiguriere die
weg.

> Und als gesteigerte Verferkelung: Was passiert, wenn mehrere Maschinen
> als queue-Runner gleichzeitig das selbe Verzeichnis leerraeumen wollen?
> Bzw. was passiert dann bei den unvermeidlichen Kollisionen?

Kein Problem - dafür sorgt das locking.

> (Der Gedanke ist, dass man bei aus irgendwelchen Gruenden vollgelaufenen
> Queues kurzzeitig andere Maschinen "ausleiht", um die aufgelaufene
> Mailqueue beschleunigt abzuarbeiten)

Rausschicken von Mails ist Platten-IO und Netzwerk.
Ich sehe keinen Nutzen darin mit mehreren Maschinen zu arbeiten, die
auf den gleichen Platten werkeln.
Wenn es dir ums Balancing geht, dann brauchst du auch eindeutig
getrennte queue Platten am besten auch lokale - dann erst kann man
über mehrere Maschinen nachdenken.
1. Massnahme für Performance ist mit mehreren Queues auf unterschied-
lichen Partitionen zu arbeiten.
Backup einer Queue kann man sowieso vergessen - das geht nur mit RAID
abzusichern - natürlich mit SCSI, geht ja nicht um billigen Platz,
sondern um Performance mit vielen Prozessen und Files gleichzeitig,
da macht es auch nichts aus, wenn man für Geld einer 18G Platte eine
200G hätte haben können - den Platz braucht man nicht.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message