Seite wählen

DRBD 9 – NEW Features

von | Mrz 26, 2013 | Linux, OSDC, DRBD

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.

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Linux | OSDC | DRBD

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: "Welches Linux ist das Beste?". Also für mich ganz persönlich. Nicht...

Ansible – Testing roles with Molecule

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation. If used in complex or...

NETWAYS Support Collector Roadmap

Den Support Collector konnte ich bereits in meinem letzten Blogpost vorstellen. Für alle die den Beitrag verpasst haben, hier kurz umrissen was es ist: Bei dem Tool handelt es sich um einen von uns geschriebenen Datensammler, welche alle möglichen Support relevanten...