[Postfixbuch-users] OT: Dovecot Mailstore extern

[Peer Heinlein]

Am Mittwoch, 29. September 2010, 11:16:31 schrieb Oliver Pürsten:


> Keiner sonst irgentwelche Erfahrungen mit Dovecot und den Mails nicht auf
> der der lokalen Machine?

Ja, hatten wir vor einigen Jahren mal mit 30.000 Accounts, allerdings freue 
ich mich hier auch auf mittlerweile direkte SAN-Anbindung per FC.

Ein anderer Kunde hat 130.000 Accounts im SAN und gibt das per NFS-Kopf an 
die IMAP-Server frei.

Ich hätte mir da eine schönere Lösung gewünscht, aber wegen verschiedener 
Hakeleien sollte das am Ende dann bei NFS bleiben. Im Prinzip läuft dort 
alles prima nachdem wir NFS zwei Runden lang ordentlich gepimpt haben, auch 
wenn raw vielleicht etwas schneller wäre.

In meinen Augen ist NFS zu unrecht als lahm und böse verschriene. NFS 
**KANN** auch sehr schnell und gut sein. Das ist in aller Regel eine Frage 
der NFS-Implementierung (Linux, Sun, NetApp -- da sind schon Unterschiede 
und unterschiedliche Versionen sowieso nochmal) und dann auch eine Frage des 
NFS-Tunings.

Gerade mit den Blockgrößen zum Lesen und Schreiben (rsize & Co) habe ich da 
beim pimpen gute Erfahrungen gemacht.

Das Problem ist halt: NFS liest die Blöcke einer Datei sequentiell, also 
nacheinander. Und dort entsteht halt Latenz. Die entsteht prinzipiell auch 
bei einer Festplatte (darum gibt es ja auch readahead), nur kommen da eben 
keine Zeiten zusammen. Bei 20-40 ms Paketlaufzeit im Netzwerk aber durchaus.

Wenn ich eine Blockgröße rsize=1024 habe und jede Mail ist 1500 Bytes groß, 
dann sind das zwei nacheinander gelesene Blöcke. Anfordern - Empfangen - 
Bestätigen - Anfordern - Empfangen - Bestätigen.

Wenn man sowas durch rsize=2048 in einen Block packt, sieht sowas sofort 
ganz anders aus.

Die Default-Blockgrößen sind sehr schlecht und widersprüchlich dokumentiert. 
In aller Regel haben moderne Kernel heute sowieso schon 8192 Bytes und damit 
kriegt man dann 95% der Mails in einem Rutsch gelesen/geschrieben, so daß 
Latenz kaum Auswirkungen hat.

Hier darf man halt eine Rückschlüsse von uralt-Systemen auf heute Systeme 
schließen, bzw. von suboptimaler Konfiguration auf optimale.

Wenn ich bei IP eine MTU von 280 Bytes habe, dann kann ich schließlich auch 
beweisen, daß TCP/IP scheiße weil lahm ist. Gar kein Problem, wenn jedes IP-
Paket erstmal fragmentiert und mit Overhead übertragen werden muß. Und 
genauso sehe ich das auch bei NFS.

Ein anderer Punkt ist die Fragem, wieviele parallele NFS-Requests die kernel 
wohl können, sprich: Was machen sie noch parallel, was dann schon wieder 
sequentiell.

Wenn Dovecot 200 Dateien anfordert und die auch parallel kriegt, dann ist 
die Latenz pro Datei nicht mehr so wirklich wichtig. Wenn er aber nur 
maximal 8 oder 16 parallel kriegt und das ganze also in 25 sequentiellen 
Slots a 8 parallele Requests abgearbeitet wird, dann ist es eklig.

Und das sind dann halt Sachen, wo eine NetApp durch eine hervorragende udn 
absolut optimierte NFS-Serverimplementierung punkten kann. Darum sind sie 
(IMHO) so schnell im NFS.

> Hatte eigentlich gedacht das ein paar mehr Leute die Mails auf einem
> externen Storage speichern und nicht lokal auf der Maschine.

Ja, doch, aber da habe ich jetzt nix großes zu jammern... Geht halt und 
130.000 Accounts sind jetzt auch noch so wenig.

Auf jeden Fall ist mir hier NFS tausendmal lieber als ein Cluster-FS, denn 
das wäre die Alternative, wenn wirklich viele iMAP-Köpfe parallel arbeiten.

a) Cluster-FS sind nicht auf kleine Dateien optimiert
b) Cluster-FS hat für Absprachen und Cache-Validierung ebenfalls 
(schlimmere?) Latenzen
c) Ich mag es simple und rock-solid

Also dann lieber NFS und alles ist gut. Wir betreiben auch große Apache-
Cluster mit ordentlich Bandbreite und Load per NFS. Tut auch prima. Die 
kleinen Nachteile sind IMHO geringer, als wenn man hier eine andere Lösung 
geht wählt. Ist halt immer eine Frage des kleinsten Übels.

 
Peer

P.S.: Ich habe viel versucht darüber zu lernen und zu lesen. Man findet kaum 
was sinnvolles, was nicht an anderer Stelle dementiert wird. Wirklich 
unschön. Für meine obigen Aussagen will ich nicht die Hand dafür ins Feuer 
legen, doch ist das nach vielen Stunden und Tagen Debugging und Analyse die 
hier bei uns im Team vorherschende Meinung/Kenntnis zu der Sache. Einen 
echten NFS-Guru der das mal wirklich auf 110%ige Gewißheit alles klären 
kann, habe ich leider noch nicht gefunden.


-- 

Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting
http://www.heinlein-support.de

Tel: 030/405051-42
Fax: 030/405051-19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg, 
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin