Was das Backup wert war, erweist sich, sobald man es versucht ganz oder teilweise wiederherzustellen. Spätestens dann macht sich die Wahl des richtigen Tools ... (mehr)

Ressource startklar

Wenn alle Voraussetzungen geschaffen sind, kann man die DRBD-Ressource aktivieren. Das leistet das Userland-Werkzeug »drbdadm« . Neben Drbdadm gibt es zwei weitere Userland-Werkzeuge, um DRBD-Ressourcen händisch zu bearbeiten: »drbdsetup« , für das »drbdadm« ein benutzerfreundliches Frontend ist, sowie »drbdmeta« . Weder Drbdsetup noch Drbdmeta sind im Normalfall nötig, das Werkzeug der Wahl ist Drbdadm. Einen recht guten Überblick gewährt »drbd-overview« .

Drbdadm lässt sich verwenden, um DRBDs Metadaten anzulegen. Meta-Daten sind notwendig, weil DRBD Platz auf der Platte braucht, um Informationen wie den aktuellen Zustand der Ressource auf beiden Clusterknoten zu speichern. Ebenso schreibt DRBD die Bitmap in die Metadaten, sollte ein Clusterknoten ausgefallen sein. Die Metadaten liegen jeweils am Ende des Backing-Devices. Man legt die Metadaten auf beiden Seiten des Clusters an, indem man den Befehl »drbdadm create-md nfs« ausführt. Wenn die Metadaten angelegt sind, erscheint eine entsprechende Erfolgsmeldung.

Der nächsten Schritt startet die Ressource mit »drbdadm up nfs« auf beiden Clusterknoten. Wer nun »cat /proc/drbd« eingibt, sieht, dass eine DRBD-Ressource existiert. Im Feld »ds« , das Disk State beschreibt, steht auf beiden Seiten »Inconsistent« . Bisher ist ja noch nicht festgelegt, welche Seite die guten Daten enthält. Im letzten Schritt gilt es also zu definieren, welche Seite zum ersten Mal im Leben dieser DRBD-Ressource primär werden soll. Sind beide Backing Devices leer, ist es freilich egal, welchen Knoten man auswählt. Wird aber DRBD nachträglich auf einem Device installiert, sollte man den Knoten auswählen, der bereits die richtigen Daten hat – sonst werden die überschrieben. Wenn klar ist, welcher Knoten primär werden soll, führt man im Beispiel dieses Kommando aus: »drbdadm -- --force primary nfs« . Ein erneuter Blick nach »/proc/drbd« verrät, dass das DRBD nun auf einem Knoten primär ist und dass der sogenannte »Initial Fullsync« bereits läuft. Nutzen kann man die Ressource aber bereits jetzt – sogar ein Rollentausch wäre möglich: Dazu führt der Admin auf dem gleichen Rechner, den er gerade zum Primary-Knoten erklärt hat, den Befehl »drbdadm secondary nfs« aus und auf dem anderen »drbdadm primary nfs« . Daten, die eventuell noch nicht synchronisiert sind, würde DRBD sich vom anderen Clusterknoten holen.

Ressource verwenden

Die einfachste Möglichkeit das gerade angelegte DRBD zu nutzen, ist wohl ein Dateisystem darauf anzulegen. Das tut man mittels »mkfs« für ein Dateisystem der Wahl mit dem Pfad »/dev/drbd Minor-Number « . Hat die Ressource mehrere Volumes, dann gibt es entsprechend im Ordner »/dev« auch mehrere DRBD-Einträge .

Sein volles Potenzial entfaltet DRBD freilich im HA-Cluster erst dann, wenn Sie es mit einem Clustermanager verbinden. Diesem Thema widmet sich der Artikel auf S. 68.

Neues in DRBD 8.4

Dieser Artikel beschäftigt sich ausschließlich mit DRBD 8.4, das jetzt erschienen ist. DRBD 8.4 bringt im Vergleich zu vorherigen DRBD-Versionen einige Neuerungen, die der Erwähnung bedürfen. Grundsätzlich gilt: DRBD 8.4 kann auch mit den Konfigurationsdateien von DRBD 8.3 verwendet werden, nicht aber umgekehrt.

Die wichtigste Änderung in DRBD 8.4 sind zweifellos die Replication Volumes. Bis einschließlich DRBD 8.3 konnte eine einzelne DRBD-Resource lediglich ein Storage-Device bereitstellen. In DRBD 8.4 ist das anders. Denn hier hat man die Möglichkeit, Volumes zu erstellen, die mehrere Storage-Devices umfassen.

Alle Storage-Volumes, die zu einer DRBD-Ressource gehören, verwenden die gleiche TCP/IP-Verbindung. Diese Funktion ist von großer Bedeutung, wenn Datenbankdaten DRBD nutzen: Bricht die Verbindung zwischen zwei Rechnern ab, kann man für sämtliche Volumes einer DRBD-Ressource sicher annehmen, dass die Verbindung exakt an der gleichen Stelle abgerissen ist. Ist die Datenbank auf diverse DRBD-Ressourcen verteilt, ist das wichtig: Der Admin kann dann nämlich definitiv voraussetzen, dass die Inhalte der einzelnen Tablespaces tatsächlich mit den Metadaten der Datenbank übereinstimmen.

DRBD 8.4 bringt weitere Neuerungen. Viele Konfigurationsparameter sind aus Gründen der Konsistenz umbenannt worden – alle Parameter, die ein »no-« vor dem Namen hatten ( »no-md-flushes« , »no-disk-flushes« ), haben dieses Präfix in DRBD 8.4 verloren und sind jetzt Boolsche Konfigurationsparameter. Die vorher eigenständige Protokolldefinition wandert aus dem Konfigurationsblock einer Ressource in den Net-Block ab.

Und auch in Sachen Performance hat sich einiges getan; so kann DRBD 8.4 ab sofort beliebig große »max-bio-size« -Einträge benutzen – implizit bedeutet das, dass DRBD nativ 4k-Blöcke unterstützt. Die Anzahl der maximal erlaubten Activity-Log-Extents ist auf über 6000 angewachsen.

Ausführliche Informationen zu DRBD 8.4 und den Veränderungen im Vergleich zu den Vorgängerversionen finden Sie im aktualisierten DRBD User's Guide, der kurz nach der Veröffentlichung von DRBD 8.4.0 verfügbar sein wird.

comments powered by Disqus
Mehr zum Thema

Workshop: Neue Features in DRBD 9

Im medialen Dauerfeuer um Ceph, GlusterFS & Co. gehen herkömmliche Lösungen wie DRBD bisweilen unter. Sehr zu unrecht: DRBD 9 verspricht eine große Zahl neuer Funktionen – und sticht verteilten Netzwerkspeicher aus, wenn es um geringe Latenzen geht.
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