Monthly Archives: January 2009

Verteiltes Dateisystem GlusterFS

Durch den Post vom vom 12.01.2009 / https://www.netz-guru.de/2009/01/12/die-ultimative-e-mail-losung-the-ultimate-e-mail-solution/ und die Kommentare darauf angeregt, habe ich versucht das gleiche Setup auch ohne dbmail zu versuchen. Sirko hatte in seinem Kommentar erwähnt, dass man mit einem verteilten Filesystem auch so einen Mailcluster betreiben kann. Bis zu diesem Zeitpunkt war mir eigentlich nur DRBD als einziges Filesystem bekannt, welches maximal 2 Nodes zu einer Art Netzwerk-RAID1 verbindet.

Gänzlich unbekannt war mir bis heute jedoch GlusterFS, welches ebenfalls ein verteiltes Filesystem über das fuse-Modul bereitstellt. Hier hat man jedoch keine Limitierung auf max. 2 Nodes. GlusterFS bietet Automatic File Replication auch über mehr als 2 Nodes. Weiterhin kann man mit Unify mehrere RAID1-Knoten zu einem einzigen FS zusammenfassen. GlusterFS bietet noch mehr Möglichkeiten, hier mal ein Überblick:

Mit einem Setup wie unter “Distributed Replicated Storage” beschrieben, lässt sich so ein gemeinsammes /var/spool für die Mailserver generieren. Die Konfiguration der Server kann man dann entweder in einer Datenbank oder LDAP ablegen, oder man verwendet die vom MTA vorgegebenen Konfig-Files, diese kann man auch auf einem verteiltem Filesystem speichern.

Den Source für GlusterFS kann man sich hier downloaden:

http://europe.gluster.org/glusterfs/2.0/LATEST/

Die Entwickler empfehlen ausserdem ein gepatchtes fuse-Kernel-Modul, welches GlusterFS erheblich beschleunigen soll:

http://europe.gluster.org/glusterfs/fuse/

Das Setup an sich ist relativ einfach. Unter Debian Etch fuse-Source entpacken, ./configure –enable-kernel-module –prefix=/usr  && make && make install && ldconfig

Dann glusterfs entpacken und ./configure –with-fuse=/usr/src/pfadzufuser &&  make && make install

Konfigurationsbeispiele gibt es unter www.gluster.org. Es sind auch kombinierte AFR,Stripe,Unify Filesysteme möglich, allerdings ist das Setup dann etwas komplizierter.

Weiterhin bietet GlusterFS neben normalem TCP/IP  auch direkte Verbindung über Infini-Band an. Auch redundante Verbindungen zur Storage werden unterstützt. Die Maximale Größe des Filesystems kann bis zu mehrere Petabytes betragen.

Möchte man viele kleine Dateien in glusterfs speichern, so kann glusterfs diese im DBD Berkeley DB Format speichern.

GlusterFS ist unter der GNU GPL v3 lizenziert.

Weitere Infos zu GlusterFS gibts auch bei der Wikipedia.

Die ultimative E-Mail Lösung – The ultimate E-Mail Solution

Es war einmal ein Mailserver…

Wenn man Administrator eines produktiv genutzten Mailservers ist, macht man sich schon ab und zu mal Gedanken, wie man die Probleme, welche beim Betrieb des Servers auftreten oder auftreten könnten, mit möglichst wenig Aufwand – jetzt im Sinne von möglichst wenig Aufwand in der Zukunft – lösen kann. Ich betreibe einen kostenlosen E-Mail Dienst mit derzeit ca. 12.000 Usern. Seit 1998 hat sich das Setup des Mailservers eigentlich kaum geändert. Damals war sendmail noch das Nonplusultra, man war stolz dass SMTP-Auth und diverse Workarounds wie POP-Before-SMTP etc funktionierten, und im Allgemeinen gab es auch weniger SPAM. Zu dieser Zeit hatte quickemail.de ca. 500 User und die Welt der Flat-File Konfiguration war noch in Ordnung.

Irgendwann reicht das jedoch nicht mehr aus – Flat-Files werden schnell unübersichtlich und es musste eine Lösung her, um zumindest die E-Mail Accounts und User zu verwalten. Eine mySQL Datenbank war schnell aufgesetzt und mit ein paar Scripts und Cronjobs wuchs die Userbase dann immer weiter an. Da gingen dann aber auch die Probleme los.

SPAM von Botnets == DDOS?

Wenn man mehrere tausend User auf einer physikalischen Maschine hat, bringt das diverse Probleme mit sich. Zum einen braucht man ständig größere Festplatten, zum anderen natürlich auch mehr CPU und RAM. Das lässt sich eigentlich auf normaler Hardware noch relativ einfach erweitern. Problematisch wird das ganze dann, wenn man distributed SPAM von diversen Botnets abbekommt. Nicht nur der Mailserver an sich ist hier dann überfordert – bei jedem Connect wird ein nslookup durchgeführt, was sich auch wieder mit erhöhter Last auf den Nameservern auswirkt. Irgendwann ist dann jedoch Schluss – bei 200 gleichzeitigen Connects und einer Load von >100 kann es schon mal ein paar Minuten dauern, bis man diverse Services gestoppt hat um zumindest die Maschine wieder administrieren zu können.

SPOFs am laufenden Band

Eine einzelne Maschine zu verwenden ist natürlich auch nicht gerade von Vorteil. Fällt die Hardware aus, oder sind die Platten voll, steht die Maschine und nichts geht mehr. Klar kann man solche Ausfälle durch gutes Monitoring minimieren, spätestens jedoch beim nächsten Upgrade steht der Dienst erst mal wieder.

Wie man diese Probleme in den Griff bekommt?

Nun, wenn man nicht gerade im Lotto gewonnen hat, braucht man hier eine günstige Lösung die dennoch gut skaliert und fehlertolerant ist, also die Mails an sich redundant speichert, sowie mehrere Server zur Verfügung stellt um bei einem ausgefallenen System dennoch den Dienst aufrecht erhalten zu können. Das gestaltet sich jedoch gar nicht so einfach. Alleine dafür zu sorgen, dass die Daten auf allen Maschinen synchron sind, ist eine Herausforderung.

Es gibt diverse Lösungen mit NAS oder DRBD, proprietäre Lösungen von diversen Herstellern, Backup-Mailserver, etc – aber eine wirkliche günstige Alternative die mit normaler x86er Hardware auskommt, und bei der man nicht Tausende Euro Lizenzgebühren zahlen muss, hatte ich bisher noch nicht gefunden.

Deshalb habe ich mich mal eine Woche intensiv damit beschäftigt, das Mailproblem, zumindest für mich, ein für alle mal zu Lösen.

Continue reading Die ultimative E-Mail Lösung – The ultimate E-Mail Solution