Allen Unkenrufen zum Trotz ist die E-Mail nach wie vor das Kommunikationsmedium Nummer eins im Unternehmen. Deshalb geben wir in der Februar-Ausgabe eine ... (mehr)

Radikaler Umbau

Um das Versprechen der "n-fachen Replikation" zu erfüllen, hat das Team von Entwicklern im Inneren von DRBD 9 kaum einen Stein auf dem anderen gelassen. Tatsächlich warf die Entwicklung von DRBD 9 bereits in der letzten Version von DRBD 8 ihre Schatten voraus: DRBD 8.4 war die erste DRBD-Version, bei der eine DRBD-Ressource mehrere Festplatten gleichzeitig verwalten konnte. Bis zur Version 8.3 existierte das Mantra "Ein Device, eine Ressource". Das Device konnte freilich ein RAID-Laufwerk sein, das sich über mehr als eine Platte erstreckt. Aus Entwickler-Sicht ging es beim Feature aber so oder so viel weniger um physische Devices als um Netzwerkverbindungen. Das Pooling mehrerer Laufwerke zu einer gemeinsamen DRBD-Ressource hat nämlich die Möglichkeit eröffnet, die Replikation für mehrere DRBD-Laufwerke an derselben Stelle abbrechen zu lassen. Das ist für Admins deshalb sehr wichtig, weil sie im Falle eines Ausfalls den letzten Zustand aller Daten auf allen DRBD-Ressourcen kennen. Sie müssen nicht davon ausgehen, dass die Replikation einer Ressource möglicherweise kurzzeitig länger möglich war als einer anderen, sodass unterschiedliche Restore-Ansätze nötig wären.

Vorrangig sorgte diese neue Funktionalität für eine Vielzahl von Änderungen im DRBD-Netzwerkcode. Und genau auf diese Änderungen hat Linbit für DRBD 9 zurückgegriffen.

Replikation über beliebige Knoten

Mit DRBD 9 stellt Linbit eine Software vor, bei der die Replikation über mehr als zwei Knoten keine Anomalie mehr darstellt. Wer das überlieferte Schema von "Primary"- und "Secondary"-Knoten kennt, muss sich für DRBD 9 erstmal umgewöhnen. Zwar kann es bloß einen einzelnen primären Knoten für eine Ressource geben – bei DRBD 8 waren über eine Sonderkonstruktion nebst separater Konfigurationseinträge Dual-Primary-Setups möglich. Dafür sind aber beliebig viele sekundäre Cluster-Teilnehmer vorgesehen. Und auch die Limitation auf einen primären Knoten wollen die Linbit-Entwickler in Zukunft wieder los werden, sodass ein Betrieb mit beliebig vielen primären wie sekundären Knoten denkbar ist.

Über Sinn und Unsinn von Multiple-Primary-Lösungen ist freilich gut streiten. Shared Storages dieser Kategorie benötigen fast immer Software für die Koordination von Schreibzugriffen, die ein Setup sehr schnell verkompliziert. Wer die Funktionalität aber braucht und sich nicht scheut, Worte wie OCFS2 oder GFS2 in den Mund zu nehmen, wird sich über die Linbit-Roadmap gebührend freuen.

Technisch sind die nötigen Umbauten von DRBD 8 zu DRBD 9 freilich wesentlich umfassender, als die Netzwerk-Änderungen vermitteln können. Das Handling von mehreren Netzwerk-Verbindungen pro Ressource war quasi nur ein Baustein; ein zweiter, mindestens so wichtiger Baustein sind massive Änderungen im Hinblick auf das "Activity Log" von DRBD. Hinter diesem Begriff versteckt sich eine für DRBD-Ressourcen lebenswichtige Eigenschaft: Das Activity Log ist der Teil von DRBD, der partielle Resyncs möglich macht.

Fällt im Zwei-Knoten-Cluster ein Knoten aus, kann es zu einer unangenehmen Situation kommen: Während der gerade aktive Server möglicherweise eine Veränderung noch nicht auf seine lokale Platte geschrieben hat, hat der passive (also sekundäre) Knoten den Schreibvorgang bereits erledigt. Fällt in diesem Moment der primäre Knoten aus, wäre der sekundäre Knoten dem primären Knoten einen Schreibvorgang voraus.

Im Storage-Umfeld gibt es aber die All-or-Nothing-Regel: Weiß ein Admin nicht mit hundertprozentiger Sicherheit, dass ein Datenträger konsistent ist, muss er davon ausgehen, dass er den kompletten Datensatz verwerfen und aus dem Backup wiederherstellen muss. Deshalb muss sich der vormals sekundäre und im Anschluss primäre Clusterknoten darum kümmern, dass der ausgefallene Knoten in dem Moment, in dem er den Cluster wieder betritt, den passenden Write nachgereicht bekommt.

Storage-Systeme kennen dafür eine Reihe von Ansätzen. Früher war es absolut üblich, eine komplette Synchronisation zwischen den beiden Knoten anzustoßen, um Inkonsistenzen auszuschließen. Das ist angesichts von Datensätzen mehrerer TByte Größe offenbar nicht mehr opportun. DRBD verzeichnet deshalb im Activity Log die Blöcke, bei denen zuletzt Aktivität vorhanden war. Wenn die Clusterknoten ihre Verbindung verlieren, können sie nach der Behebung des Problems einfach im Activity Log nachschlagen, welche Blöcke vor dem Ausfall "heiß" waren. Nur diese werden denn repliziert – die Wartezeit nach einem Ausfall ist entsprechend gering, trotzdem steht die Integrität der Daten zu keiner Zeit in Frage. Für DRBD war das Activitiy Log deshalb auch ein sehr kniffliges Unterfangen. Wo es sich zuvor lediglich um zwei Knoten kümmerte (auch beim "Stapeln" von Ressourcen existierte eine DRBD-Verbindung stets nur zwischen zwei Knoten), muss es plötzlich die Kommunikation einer großen Summe von Knoten überwachen und aufzeichnen. Ebenso muss DRBD auf jedem Knoten wissen, was es im Recovery-Fall zu tun hat. Laut Philipp Reisner war gerade jener Teil ein ordentliches Stück Arbeit, der mittlerweile überwunden scheint.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023