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)

Die Konfigurationsdateien

Seit Version 8.3.7 unterstützt DRBD Configuration Sniplets. Das heißt, dass die vormalige Hauptkonfiguration »/etc/drbd.conf« bloß noch Verweise auf Dateien im Ordner »/etc/drbd.d« enthält. In diesem liegt dann eine Datei namens »global_common.conf« sowie die Konfiguration der einzelnen DRBD-Ressourcen – jeweils eine pro Datei, wobei diese Dateien die Endung ».res« haben. Gegenwärtige DRBD-Versionen sind bereits auf dieses System hin ausgerichtet.

Die Datei »global_common.conf« unterteilt sich in zwei Konfigurationsabschnitte – einerseits jenen, der auf den Namen »global« getauft ist. In ihm legt DRBD selbst Konfigurationsparameter fest.

Weitere Einstellungen müssen im Global-Abschnitt zunächst nicht vorgenommen werden. Wichtiger ist der Common-Abschnitt: Er enthält Parameter, die die einzelnen DRBD-Ressourcen direkt betreffen. Allerdings lassen sich die Einstellungen der »common« -Sektion später für einzelne Ressourcen in deren Konfigurationsdateien überschreiben. Wichtig ist, dass im Abschnitt »net« das Protokoll auf C gesetzt ist; dann zumindest, wenn es sich um einen lokalen Zwei-Knoten-Cluster mit Back-to-Back-Link handelt. Die Zeile »protocol C;« erledigt das. Es empfiehlt sich auch, die »Syncer-Rate« zu setzen; diese legt fest, mit welcher Geschwindigkeit die Resynchronisation vonstatten gehen darf. Ein passender Eintrag wäre »resync-rate 50M« , diesmal im »disk« -Abschnitt. Hier gibt man allerdings nicht »Megabit« an, sondern »Megabyte« . Das heißt: Der genannte Eintrag würde DRBD für die Resynchronisation maximal 50 Megabyte pro Sekunde zugestehen.

Wenn die »global« - und die »common« -Einträge passend geändert sind, kann es losgehen mit der ersten Ressource.

DRBD-Ressource

Eine DRBD-Ressourcen-Konfiguration besteht aus aus mindestens einer » volume« -Definition, die selbst wenigstens die Optionen »device« , »disk « sowie »meta-disk« festlegen muss. Hinzu kommen zwei Abschnitte, welche mit »on hostname {« eingeleitet werden und wenigstens die IP-Adresse sowie den Port festlegen, damit DRBD anschließend mit diesen Angaben eine Verbindung zum Cluster-Partner aufbauen kann. Die Volume-Definition kann wahlweise innerhalb oder außerhalb dieser »on« -Blöcke liegen. Wenn die Parameter für die genannten Einträge »device« , »disk« und »meta-disk« auf beiden Computern identisch sind, empfiehlt es sich, den Volume-Eintrag außerhalb der On-Blöcke zu pflegen. Die gesamte Ressourcen-Konfiguration ist mit eingerahmt von einem »resource Name« -Statement und geschwungenen Klammern.

Für das folgende Beispiel gelten diese Bedingungen: Angelegt wird eine simple DRBD-Ressource, die »nfs« heißt und genau ein Volume enthält. Dieses Volume nutzt auf beiden Clusterknoten das Logical Volume »nfs« der Volume Group »vg« als Backing Device. Es kommen interne Metadaten zum Einsatz. Der erste Clusterknoten, Alice, hat als IP-Adresse auf dem internen Interface 10.42.0.1 und soll den Port 7788 benutzen, der zweite Knoten, Bob, hat die Adresse 10.42.0.2, und der Port ist ebenfalls 7788. Auf beiden Seiten soll das DRBD-Device die Minor-Nummer 0 bekommen, sodass es später im System als »/dev/drbd0« erscheint. Die komplette Konfiguration der Ressource zeigt Listing 1. Diese Ressource könnte selbstverständlich zu einem späteren Zeitpunkt um weitere Volumes ergänzt werden; diese müssten analog zum Volume 0 ebenfalls in die Konfigurationsdatei eingetragen werden. Wollte der Admin statt eines LVs ein physikalisches Speicherlaufwerk verwenden, würde er bei »disk« das passende Device eintragen, beispielsweise: »disk /dev/sda1« . Speichern sollte man die Konfiguration in einer Datei namens »nfs.res« , die im Ordner »/etc/drbd.d« landet – selbstverständlich auf beiden Clusterknoten.

Listing 1

Konfiguration einer DRBD-Ressource

 

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019