Re: OT: Mailspool ueber NFS?

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Thu, 24 Jul 2003 10:45:36 +0200

On Thu, Jul 24, 2003 at 10:15:22AM +0200, Olaf Hoyer wrote:
> On Thu, 24 Jul 2003, Bernd Walter wrote:
>
> > > 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.
>
> Moin!
>
> Normalerweise. Es sei denn, einige Systeme sind offline, oder die
> Maschine hat zu hohe load und queued erstmal eine Weile.

Du machst Tuning für den Fehlerfall.
Sendmail hat dafür die hostdb und bei Bedarf kannst du die Mails
gleich in eine extra Queue spoolen, wenn das Ziel bereits als offline
bekannt ist.

> > > - 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.
>
>
> Gibt es irgendwo brauchbare Ressourcen, die NFS (gerade BSD-zentrisch)
> etwas naeher im Kurz/Mittelformat beleuchten?
>
>
> Von der Theorie her wird ja die Mail auf z.B. /nfs/mqueue geschrieben.
> Sendmail hat dort einzelne Dateien liegen, die eindeutige Namen haben,
> sollte also kein Problem sein, zumindest dort reinzuschreiben.
> Oder welche Probleme koennen sich ergeben, ausser, dass der nfs-Server
> nicht erreichbar ist?

Sendmail locked das qf vor der Zustellung um zu verhindern, daß ein
anderer Prozess darauf zugreift und die gleiche Mail zustellt.
Wenn locking nicht stabil läuft, dann kannst du mit allem rechnen.
Beim Eingang passiert ähnliches, um einen Eindeutigen Namen zu haben.

> > > 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.
>
> Prinzipiell ist ein Konstrukt mit Smarthost via mailertable oder
> FallbackMXHost sinniger.

Nein, weil schwer zu pflegen.
Wenn du tunen willst, dann möchstest du zwingend eine sauber getrennte
Konfiguration der ausgehenden MTAs haben.

> Ich dachte an Faelle, wo man z.B. durch SPAM-Attacken vollgelaufene
> Mailspools hat, die man noetigenfalls separiert und von anderen
> Maschinen abarbeiten laesst.

Getrennte Queues.
Sendmail kann mehrere Queues und Queuegruppen verwalten.
Für den Fall ein sehr leistungsstarkes Feature.

> > > 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.
>
> Ich setze hier mal groessere RAID's voraus, so dass Platten-I/O
> ausreichend da ist.
> Der Engpass waere hier die CPU-Zeit, wenn man beim Mailversand auch noch
> so typische Probleme hat wie DNS-timeouts etc.

Die hast du nur einmal, danach weißt du, daß der DNS down ist.
Sendmails hostdb sorgt dann dafür, daß es bei der Erkenntniss bleibt.

Mit dynmail.de verteile ich Mails für einige hundert offline Systeme,
die teilweise auch eine Dynamische IP haben.
Alles kein Problem.

> Die Preisfrage ist:
> Was kostet mehr, dass der MTA eine Datei im queue-run anfasst, versucht
> diese zuzustellen (incl. MX-lookup etc) und diese dann evtl. wieder in
> die queue stellt, oder das exportieren derselben Datei(en) per nfs?

Der Zugriff ist entscheidend - ob Inhalt angefordert wird oder nicht
macht erst bei sehr großen Mails einen Unterschied.
Da eine durchschnittliche Mail aber nicht sonderlich groß ist...

-- 
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
Received on Thu 24 Jul 2003 - 10:45:45 CEST

search this site