DRBD 9 – NEW Features

drbd_logo_smallDRBD 9 wird eigentlich ja mit zwei neuen Features assoziiert – mehr als zwei Knoten in einer Ebene (ohne Stacking), und “auto-promote” (“Primary”-Rolle beim Öffnen, wenn sonst kein Knoten darauf arbeitet). Diese Kombination eröffnet nun eine große Menge an neuen Anwendungsgebieten – die so vorneweg einmal gar nicht so offensichtlich sind.
Beispiel 1: Rebalancing
Wenn man einen bestehenden Storage-Cluster mit z.B. 3 Knoten hat, diese alle Daten 3-fach halten, und der Platz eng wird, kann man 3 neue Maschinen anschaffen. Oder: es wird nur ein Knoten hinzugefügt; bei bestehenden DRBD-Resourcen wird die Redundanz kurzfristig erhöht, um die Daten auf dem neuen Knoten ebenfalls zu erhalten, dann kann die Datenhaltung wieder auf 3-fach reduziert werden – mit dem Ergebnis, dass auf den “alten” Knoten Platz freigeworden ist, in dem man neue DRBD-Resourcen anlegen kann.
Also anstatt von N auf 2*N aufrüsten zu müssen, reicht einmal N+1. Und wenn im Zuge mehrerer Upgrades dann doch einmal 2*N Knoten herumstehen, können die Resourcen (falls notwendig) im Betrieb so verschoben werden, dass sich zwei unabhängige Cluster mit jeweils N Knoten ergeben – und das Upgrade-Spiel kann von neuem beginnen.
Beispiel 2: DRBD Client
Bei DRBD 8 war ja der Ausfall des Storage am Primary-Knoten schon ein erlaubter Zustand – alle IO-Operationen wurden dann eben nur noch über den Secondary durchgeführt. Diese Funktion kann mit DRBD 9 nun per Design verwendet werden: ein Rechner, der auf DRBD-Resourcen zugreift, ohne selber lokales Storage dafür zu verwenden, ist ein DRBD Client.
Die Palette an Anwendungen dafür ist enorm:

  • Ein Cluster kann einfach um weitere Knoten erweitert werden, ohne notwendigerweise die Redundanz (und damit den Platzverbrauch) zu erhöhen. Alle Maschinen können auf dieselben Daten zugreifen, unabhängig davon, ob die Daten lokal liegen oder “nur” über andere Knoten zur Verfügung gestellt werden.
  • Ein paar Storage-Knoten im Hintergrund, die Frontend-Maschinen die Daten für VMs liefern. Die Vorteile dabei sind: auf den Storage-Knoten ist nur DRBD notwendig, kein Cluster-Manager, kein iSCSI, etc.; und, durch das seit 8.4.1 verfügbare read-balancing kann die IO-Last auf den Storages einfach aufgeteilt werden.
  • Für Zwecke der Konfigurationsverwaltung kann es sinnvoll sein, das komplette /etc in einem VCS aufzubewahren [siehe z.B. etckeeper, fsvs, git-home-history, etc.]. Wenn das Repository dabei über Automounter über alle Rechner des Clusters “geteilt” werden kann, ist Integration/Nachverfolgen/Fehlersuche wesentlich komfortabler.

Weitere Ideen? Bitte diese bei LINBIT bspw. im Kontaktformular einbringen, damit wir diese in unserer zukünftigen “DRBD 9 Features”-Reihe anfügen können.
Wer mehr zur DRBD erfahren möchte, dem sei der DRBD-Workshop im Rahmen der kommenden OSDC ans Herz gelegt.