Re: OT: Mailspool ueber NFS?

On Fri, Jul 25, 2003 at 10:48:56PM +0200, Olaf Hoyer wrote:
> On Thu, 24 Jul 2003, Bernd Walter wrote:
>
> > On Thu, Jul 24, 2003 at 10:15:22AM +0200, Olaf Hoyer wrote:
> > > On Thu, 24 Jul 2003, Bernd Walter wrote:
> > 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.
>
> Moin!
>
> Ok, jetzt habe ich etwas mehr Zeit als die letzten Tage...
>
> Kannst Du die hostdb etwas erlaeutern?
> Auf sendmail.org fand ich da irgendwie nicht wirklich was zu...
> Oder nennt sich diese hier nur anders?

Der speichert sich den Status einer Zustellung und wenn sendmail
nochmal mit dem System zu tun hat, dann weiss er, ob es sich lohnt
zuzustellen oder besser gleich zu queuen.
Das hat Sendmail schon immer pro Prozess im Speicher gemacht und nun
kann man die Information über Prozessgrenzen hinweg nutzen.

> > > 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.
>
> Gibts da irgendwo vernuenftige Dokumentation/kaeuflich zu erwerbende
> Literatur zu? sendmail.org ist da nicht wirklich ne grosse Hilfe...
> Und soweit ich mich erinnere, war dieses in dem letzten O'Reilly, den
> ich mit der Fledermaus drauf hatte, auch nicht das grosse Thema...

Die beste Doku schlechthin:
/usr/share/sendmail/cf/README
/usr/src/contrib/sendmail/doc/op

Das Bat-book von O'Reilly braucht man normalerweise nicht.

> > 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...
>
>
> Einige der Gedanken, die ich mal durchgespielt hatte, betrafen auch
> Szenarien, in denen gewissen Volumen an mail zu bewaeltigen sind.

Das ist absolut nicht genug Information um ein System aufzubauen.
Als erstes musst du wissen, was für Features du brauchst und danach
machst du eine Abschätzung auf die Anzahl und Art der Mails die auf
das jeweilig genutzte Feature zulaufen.
Entscheidend dabei ist auch wieviel Manpower in die Wartung gesteckt
wird - eine gute Wartung und Pflege ersetzt einiges an Maschinen-
leistung - sehr viel mehr, als man glauben mag.
Mit dem Wissen bist du dann ausgerüstet eine Kapazitätsplanung zu
machen.
Das dynmail.de System ist mehrstufig aufgebaut und je nach zunehmenden
Bedarf kann jede Stufe mit weiteren Systemen problemlos aufgerüstet
werden.
Machbar ist alles - nur eine Aufwandsfrage.

> Der Gedanke war, mehrere kleine, billige Systeme mit einer recht
> einfachen Konfiguration ins Frontend zu stellen, die CPU-intensive
> Taetigkeiten (und Wartezeiten wegen z.B. lahmen DNS oder langsamer
> Gegenstellen) abhandeln, und die I/O-intensiven Taetigkeiten andere
> Maschinen (z.B. dicke SUNS) machen lassen.

Lass IO intensive Dinge besser Systemen machen, die das könnnen.
Also FreeBSD oder NetApp Filer - Sun ist da die falsche Wahl.
Wobei ich in einer Mailqueue mittels NFS keinen Sinn sehe.

> Einige der Gedanken, die ich mir mal so als Konzept gemacht hatte,
> betrafen auch Mailrouting mittels LDAP, sowie die Einbindung von
> Virenscanner/Spamfilterservern, fuer die man zumindest konzeptionell
> einen Hook schaffen sollte, wenns schonmal um getrennte Systeme geht.

LDAP ist erst mal langsammer als eine lokale Berkeley DB.
Bei derartiger Kapazitãtsplanung hast du aber eh Automatismen zur
Konfiguration, da macht es nichts aus wie die Daten hinterlegt werden.

-- 
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