[tapg] Fragen zum Aufbau des neuen Mailservers

[Martin Schitter]

Am 2013-10-06 12:29, schrieb Jogi Hofmüller:
> * neue Hardware ist bestellt.  Intel Server Barebone mit 8x1TB 2,5"
> SATA3 Disks, die in zwei unabhängigen RAID1-Verbänden verwendet werden.

2 x RAID10 ist sicher mehr als ausreichend! -- RAID5 würde ich eher 
vermeiden...

btrfs-RAID ist zwar vom ansatz her -- dh. von der fehlererkennung und 
duplizierung der relevanten daten -- viel ausgeklügelter, hat aber in 
den praxis den großen nachteil, dass man es a) nicht so einfach degraded 
booten kann, b) entsprechende warnungen/störungen nicht per mail meldet 
etc. in dieser ganz pragmatischen hinsicht ist also klassisches linux 
md-RAID deutlich ausgereifter. ich bin mir nicht sicher, ob ich im falle 
einer einer derartig sensiblen produktionsmaschine bereits auf die 
zukunftsweisendere variante setzen würde? technisch spricht sicher 
manches dafür -- und irgendwie wird man es vermutlich auch bändigen 
können. von der performance her macht es ohnehin keinen nennenswerten 
unterschied.

> * Der POP/IMAP-Server wird dovecot mit Maildir in den /home/-Verzeichnissen.

ein /home bzw. ldap-einbindung sollte es auf alle fälle am 
entsprechenden server geben, weil sonst pigeonhole (=die passende sieve 
imeplementierung fürs dovecot) probleme macht.

auch maildir-folder an der default location machen sinn.

ich bin mir nur nicht sicher, ob das mergen per automount in der ansicht 
für die user am login.mur.at reibungslos und ohne große abstriche 
klappen wird? zb. werden die betreffenden snapshots auf diesem weg 
vermutlich nicht zugänglich gemacht werden können etc.
das sind aber wirklich kleinigkeiten, über die man sich nicht zu sehr 
den kopf zerbrechen sollte...

jedenfalls sollte

lda_mailbox_autocreate
lda_mailbox_autosubscribe

od.ä. helfen, damit nicht wie bisher, mailboxen am imap-server jedesmal 
explizit eingerichtet werden müssen...

(achtung, könnte mit lmtp probleme machen!)

> * Als Filesystem werden wir btrfs verwenden mit LZO-Kompression verwenden.
> * In kurzen (alle 5 Minuten?) Intervallen synchronisieren wir den
> Bestand der Mails auf ein ext4 Verzeichnis.  Sollte also etwas völlig
> schiefgehen, können wir in kurzer Zeit /home unmounten und /backup
> mounten, und verlieren dabei maximal die letzten 5 Minuten Mails ...
>
> Worüber wir noch nachdenken ist, wie genau wir die Synchronisation
> durchführen werden.  Bei rsync gibt's Bedenken was die Geschwindigkeit
> angeht.  IOhannes schlug letzten inotify vor, was wir uns noch ansehen
> werden.  Wenn Du eine gute Idee hast, wir hören ;)

was diesen punkt betrifft, hab ich leider einige bedenken.

ich glaube auch nicht, dass es sinn macht, entsprechende umständliche 
bzw. systembelastenede synchronistationen in derart hohem rhythmus 
einzuplanen. das schadet nicht nur der allgemeinen performance, sondern 
lässt auch die platten vorzeitig altern.

ich würde mich eher nach den praktischen erfordernissen richten:
eine große anzahl von automatischen snapshots macht am imap-server 
tatsächlich sinn! es ist vermutlich der einzige ort, wo wir schon bisher 
regelmäßig usern erklären mussten, dass wir ihre daten nicht oder nur 
unvollständig wiederherstellen können, wenn sie mit einem 
versehentlichen pop3 zugriff od.ä. ihre mailbestände zerstört haben.

für eine zweites sicherheitsnetz darunter -- sollte es mit dem aktiven 
filesystem ernste probleme geben -- scheint mir aber ein 24 stündiges 
synchronisationsintervall völlig ausreichend.

rsync ist sicher keine besonders schöne lösung für diesen zweck, aber 
zur not bzw. mit der nötigen zurückhaltung (einmal in der nacht von 
einem snapshot aus...) vermutlich akzeptabel. btrfs send/receive od.ä. 
wäre für höhere replikationsfrequenzen fast eine zwingende 
voraussetzung. ich würde aber auf einer derart kritischen maschine eher 
die finger davon lassen, wenn man vorher nicht damit ein klein wenig 
erfahrung (bspw. beim backupen der büro-desktops) gesammelt hat.

übrigens besitzt dovecot auch intern replikationsfeatures, die evtl. für 
backups herangezogen werden könnten. auch hier würde ich allerdings 
gefühlsmäßig eher auf bewährte filesystem basierende mechanismen setzten.

ein ein ganz wesentlicher punkt, der mit dieser ganzen synchronisiererei 
eng verknüpft ist, wurzelt in der frage, ob man den relevanten teil der 
sich verändernden bzw. abzugleichenden daten nicht haus aus viel kleiner 
und evtl. unkomprimiert halten kann/soll?

das wirkliche problem auf unserem server sind nämlich ständig nur ein 
paar wenige benutzer, die ihre mails+attachments über jahrzehnte hinweg 
am server zu archivieren. das ist ein unfug, der selbst bei bester 
indizierung und optimieren mialboxformaten eine ganze menge an 
folgeproblemen nach sich zieht. vernünftig bemessene quotas sind hier 
ein lösungsansatz, der noch viel wirksamere dürfte aber darin bestehen, 
einen tiered storage modell zu verfolgen -- dh. zwischen aktuellen mails 
und archivbestand zu unterscheiden.

eine transparentes mergen solcher unterschiedlicher mail-locations ist 
leider momentan unter dovecot nur bei der verwendung des proprietären 
dbox formats möglich. davon würde ich aber eher die finger lassen, weile 
das im falle von groben fehlern eine eher ungünstige prognose bzgl. der 
wiederherstellung mit sich bringen dürfte. sehr wohl macht es aber sinn, 
die entsprechenden mechanismen (dsync bietet erlaubt eine aufttrennung 
der mails nach ihrem alter als nächtlichen batch job) nutzt, um 
archiv-matrial einfach in einen zweiten mailspool/namespace auszulagern...

ich bin mir nicht sicher, ob dieser ansatz in der angestrebten kürze 
reibungslos umgesetzt werden kann, trotzdem glaube ich, dass er dem 
eigentlichen problem eher gerecht werden dürfte.

> Soweit so gut, ich hoffe ich habe nichts wesentliches vergessen.  Ich
> halte Euch auf dem Laufenden.

naja -- wie gesagt: aus meinen bisherigen versuchen weiß ich leider nur 
zu gut, dass sich in der praxis beim migrieren dann ständig neue 
probleme zeigen, die man ursprünglich überhaupt nicht erwartet hätte -- 
leider!!!

ich hoffe, dass einige ganz entsetztliche bugs im dsync mittlerweile der 
vergangenheit angehören. wenns't in den archiven der 
dovecot-mailinglisten stöberst, wirst ohnehin auf bug-reports von mir 
stoßen, die hier ursächlich für manches nachbessern stehen könnten. ein 
bisserl skeptisch bin ich allerdings trotzdem. speziell auch deshalb, 
weil das im debian verfügbare dsync der 2.1er linie schon seit mind. 1-2 
jahren nicht mehr weiterentwickelt wird/wurde, während das entsprechende 
nachfolge tools in 2.2 praktisch from scratch neu gestrickt wurden. es 
kann also gut möglich sein, dass die migration in wahrheit nur über den 
umweg eines 2.2er dovecots effizient durchführbar ist, auch wenn dann im 
betrieb die 2.1er version aus debian beständen völlig ausreichen dürfte...

wie gesagt: diese einschätzung wurzelt in der ganz praktischen erfahrung 
von haarsträubenden problemen, die ich damit bereits erlebt habe! 
hoffentlich hat sich hier einiges zum bessern hin gewendet.

so viel auf die schnelle von meiner seite...

martin