Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 4
DRBD, OpenVZ und Heartbeat
In dieser Folge der Artikelreihe werden wir dem Titel gerecht und werden, nachdem alle grundsätzlichen Überlegungen gemacht wurden, Entscheidungen fällen und den Cluster von Grund auf neu aufsetzen. Als Virtualisierungslösung wird OpenVZ verwendet, wobei die Option für Xen grundsätzlich weiterbesteht. Da DRBD, OpenVZ und Heartbeat stark miteinander verzahnt werden, werden sie in diesem Artikel gemeinsam abgehandelt.
Überdenken der bisherigen Erkenntnisse
RAID
Ursprünglich hatte ich nur einen virtuellen Server geplant. Daher hatte ich RAID5 für die Festplatten vorgesehen, um den Ausfall einer Platte verkraften zu können. Dann kam der zweite Server hinzu, was für mich sehr wichtig war. Denn ein einzelner Rechner hat viele »Single Points of Failure« (SPOFs). Einen Ausfall von CPU, Mainboard oder Netzteil verkraftet er beispielsweise nicht. Natürlich kann man in einer Privatwohnung nicht jeden »Single Point of Failure« eliminieren. Aber etwas besser als ein einzelner Server kann man es schon machen.
Die beiden Server sollen mittels DRBD gekoppelt werden. Im Grunde ist DRBD eine Art RAID1 übers Netz. Demnach hätte ich zwei RAID5-Systeme, die über RAID1 nochmals gespiegelt werden. Ist das nicht etwas viel Redundanz? In der Tat, warum sollte man die geringere Leistung und den Kapazitätsverlust von RAID5 in Kauf nehmen, wenn sowieso alle Daten gespiegelt werden? (Unabhängig davon werden alle wichtigen Daten auch noch täglich gesichert.) Sollte man nicht lieber die drei Platten im RAID0-Modus mit Striping betreiben, womit man die volle Kapazität bei der dreifachen Übertragungsrate einer einzelnen Platte nutzen kann?
Um die Frage zu beantworten, überlegen wir nur kurz einmal, was passiert, wenn eine Platte ausfällt. Bei RAID0 fällt der betroffene Server einfach aus. Das macht nichts, da der zweite Server sofort an seine Stelle tritt. In der Zwischenzeit kann die ausgefallene Platte ersetzt werden. Wie würde man hierbei vorgehen? Ich würde ausschließen, dass man die neue Platte an den zweiten Server klemmt und die entsprechende Platte dieses Rechners kopiert. Denn erstens müsste man dazu auch den zweiten Server herunterfahren, zweitens dauert das Kopieren von 400 GB eine Weile, und drittens wäre, falls man beim Kopieren einen Fehler macht, möglicherweise auch der zweite Server ruiniert. Ein besserer Weg wäre daher, die neue Platte einzubauen, von Hand zu formatieren, die erste Partition von einer der beiden anderen Platten zu kopieren und den Rest neu zu formatieren. Das dürfte eine Sache von Minuten sein. Dann startet man den Server neu, und prompt sollte seine Datenpartition von DRBD synchronisiert werden. In diesem Fall hieße das, dass im Hintergrund der ganze Inhalt des Volumes vom zweiten auf den ersten Server zurücktransferiert wird. Das kann Stunden dauern, aber sofern kein weiterer Fehler auftritt, laufen alle Dienste ohne Unterbrechung weiter.
Eine zweite Möglichkeit wäre, eine Kopie der ausgefallenen Platte anzufertigen. Erfahrungsgemäß fällt eine Platte selten komplett aus. Der Ausfall kündigt sich eher mit Schreibfehlern an. Ich habe es schon mehrfach geschafft, den Inhalt von ausgefallenen Platten komplett - oder ohne ernsthafte Verluste - auf eine neue Platte zu kopieren. Hierfür sollte man ddrescue verwenden. Wenn einzelne Sektoren nicht gelesen werden können, ersetzt das Tool diese mit Nullen. Ein abschließender Dateisystem-Check bringt alles wieder in einen konsistenten Zustand, wobei aber Dateien verlorengehen könnten. Aus diesem Grund ist diese Methode höchstens zweite Wahl, zumal sie auch sehr langwierig ist.
Betrachten wir nun die Situation mit RAID5. Auch hier müsste man die ausgefallene Platte ersetzen, die Partitionen anlegen und den Teil der Platte, der nicht dem RAID5 angehört, kopieren. Danach kann man den Rechner wieder in Betrieb nehmen, wobei das RAID5 im Hintergrund regeneriert wird. DRBD dürfte davon gar nichts mitbekommen.
Es könnte hilfreich sein, die in den Schrank gelegte Ersatzplatte bereits vor einem Ausfall vorzubereiten. Man könnte z.B. einmal im Monat eine Wartung einplanen, bei der der primäre Server kurz heruntergefahren wird (der sekundäre übernimmt die Dienste), die Ersatzplatte eingebaut, mit einer Kopie der Bootplatte überbügelt und dann wieder in den Schrank gelegt wird. Ob man den Server dafür zweimal kurz oder einmal länger herunterfährt, hängt davon ab, was man alles kopiert. Im Minimalfall legt man nur die Partitionen an. Die Daten, die sich ohnehin häufig ändern, kopiert man erst bei einem Ausfall.
Der Unterschied zwischen beiden RAID-Arten liegt nur darin, dass einmal lokal und einmal übers Netz regeneriert wird. Falls nur eine Platte ausfällt, ist der Unterschied zwischen beiden Konfigurationen vernachlässigbar. Wenn jedoch zum Zeitpunkt des Ausfalls die beiden Rechner nicht synchron waren, dann kann man nur noch hoffen, dass die ausgefallene Platte im sekundären Rechner steckt - oder dass der Stand des sekundären Rechners nicht allzu alt ist. Doch dieser Fall mit dem doppelten Fehler ist unwahrscheinlich, hofft man zumindest. Soll man dafür 33% der Kapazität und 30 bis 50% der Geschwindigkeit opfern? Ich habe mich letztlich dagegen entschieden. Damit vereinfacht sich auch die Konfiguration etwas.
Virtualisierung
Bei den virtuellen Maschinen hat sich die Auswahl aufgrund meiner Vorüberlegungen auf Xen und OpenVZ reduziert. Ich machte dann auch ein paar anfängliche Tests mit Xen und brachte auch die Dom0 (das Hostsystem) zum Laufen. Dann verzichtete ich aber aus Zeitgründen darauf, ein Gastsystem anzulegen, und installierte OpenVZ. Über OpenVZ werde ich im Verlauf dieses Artikels noch berichten. Xen dagegen werde ich wohl später noch einmal aufgreifen. Mein Cluster wird auf jeden Fall erst einmal mit OpenVZ produktiv gehen.
