Re: Heartbeat, DRBD Mailserver Cluster
Hallo,
S. Kremer <sk71@gmx.de>:
>D.h. also, dass ich bei einem Mailserver Cluster mit Postfix und Dovecot, wo immer nur ein
>Server aktiv ist, ohne weiteres auch ein ext3 oer xfs Filesystem einsetzen kann?
Ja. DRBD wird dabei im Primary-Secondary Modus betrieben; auf der jeweiligen
Primary Seite wird das FS gemountet.
>Die angedachte Lösung soll so sein, dass zwei gleich konfigurierte Server laufen, wo jedoch
>immer nur einer von beiden aktiv ist und der zweite erst dann zum Einsatz kommt, wenn der
>erste ausfällt.
Prinzipiell sinnvoll. Man kann die Ressourcenausnutzung noch ein wenig
verbessern, indem man z.B. Postfix+Dovecot normalerweise auf dem einen und
Apache auf dem anderen Knoten laufen lässt; nur wenn ein Server ausfällt,
übernimmt der andere alle Dienste.
>Reicht es aus, nur die Partition mit den Mailboxen über DRBD synchronisieren zu lassen oder
>welche Daten sollten idealerweise ebenfalls gleichzeitig auf beide Server geschrieben
>werden?
Der interne Postfix Spool sollte ebenfalls per DRBD synchronisiert werden.
Wenn der Spool nur lokal liegt, dann bleiben beim Ausfall eines Servers die
gespoolten Mails solange liegen, bis der Server wieder läuft. Bei einem
gespiegelten Spool geht es nahtlos weiter.
Je nach geplantem Web-Dienst kann es sinnvoll sein, auch den Webspace mit
DRBD zu spiegeln; z.B. bei Applikationen wie Dokuwiki, die selber Dateien
anlegen und verändern.
>Gibt es über DRBD die Möglichkeit alle Änderungen, die auf Server1 durchgeführt werden,
>z.B. Konfigurationsdateien etc., direkt auf Server2 schreiben zu lassen? Oder wie wird so
>etwas in einer Produktivumgebung idealerweise realisiert?
Man muss prinzipiell zwischen einem Service Cluster und einem OS Cluster
unterscheiden.
Beim Service Cluster sind alle Dienste auf beiden Maschinen separat
installiert. Auf dem Shared Storage liegen die Daten (Mailboxen, Spool,
Webspace), evtl. auch die Konfiguration und/oder die Logs. Die
Clustersoftware kümmert sich darum, dass auf der jeweils aktiven Seite das
Filesystem gemountet, die virtuelle IP-Adresse aktiviert und der Dienst
gestartet wird.
Beim OS-Cluster wird eine komplette, minimale Linux-Installation incl. der
Dienste auf dem Shared Storage abgelegt. Diese wird auf der jeweils aktiven
Seite in einem Container gestartet, wobei dabei auch die virtuelle IP-Adresse
aktiviert und die Dienste gestartet werden. Als Container-Technologie eignen
sich z.B. Linux-VServer, LXC oder OpenVZ. Prinzipiell gehen auch komplette
Virtualisierungen wie KVM, Xen oder VirtualBox, allerdings ist das meistens
Overkill.
Der Service Cluster hat den Vorteil, dass man auf beiden Seiten die Software
getrennt updaten und die Konfiguration separat verändern kann. Somit kann
die jeweils inaktive Seite für Tests verwendet werden. Der Nachteil ist
allerdings, dass man nach dem Abschluss von Tests und Updates dafür sorgen
muss, beide Seiten wieder zu synchronisieren. Wenn man das vergisst oder
einen Fehler macht, ist oft kein automatischer Schwenk mehr möglich; der
Cluster verliert seine Daseinsberechtigung.
Beim OS-Cluster finden alle Änderungen innerhalb des Containers statt; die
Umgebung sieht stets genau gleich aus, egal auf welchem Knoten sie läuft.
Auf den Hosts selber läuft lediglich die Clustersoftware. Somit ist es
relativ einfach möglich, nachträglich weitere Knoten in den Cluster zu
bringen. Nachteile des OS-Clusters sind der höhere Bedarf an Storage (eine
Linux-Basisinstallation pro Dienst) und RAM (pro Container ein eigener
syslogd, cron, ggf. weitere Dienste wie sshd, nscd, atd, nrpd, ...).
Für Anwendungsdienste wie Web, Mail, Datenbank etc. empfehle ich meinen
Kunden in den meisten Fällen einen OS Cluster. Bei systemnahen Diensten
ist dagegen oft der Service Cluster die bessere (oder sogar einzige) Wahl,
z.B. NFS Server, Load Balancer oder Firewall.
Gruß, Harald
Reply to: