Defekte Platten richtig austauschen

Hat eine Platte das Zeitliche gesegnet (oder ist durch den Defekt von mehreren Platte ein RAID-Verbund kaputtgegangen), braucht es nach dem Hardware-Tausch noch ein paar DRBD-Handgriffe, um wieder klare Verhältnisse zu schaffen. Der Artikel geht an dieser Stelle davon aus, dass die kaputte Hardware ausgetauscht ist und dass im System die Storages so aussehen wie vor dem Ausfall. War zwischen DRBD und der Hardware noch eine Zwischenschicht eingezogen, beispielsweise LVM, so ist auch diese entsprechend wiederherzustellen.

Nach dem Hardwaretausch ist die lokale DRBD-Ressource im Grunde nicht mehr vorhanden, vor allem dann nicht, wenn sie interne Metadaten genutzt hat. Aber auch, wenn externe Metadaten in Verwendung waren – die Daten, die zu diesen Metadaten gehören, sind nichtsdestotrotz auf dieser Seite des Clusters schlichtweg weg.

Der Tausch der Platte funktioniert so wie das Anlegen einer neuen Ressource. Auf dem Rechner mit der ausgetauschten Platte führen die folgenden Befehle zum Ziel: »drbdadm create-md  Ressource « legt die Metadaten an (externe Metadaten der vorherigen Ressource sind zu überschreiben »drbdadm up Ressource « sorgt für den Start der Ressource. Weil der andere Clusterknoten als Diskstate »UpToDate« hat, erkennt DRBD automatisch, dass der reparierte Knoten aktuelle Daten braucht, und startet eine komplette Synchronisation. Bereits während diese läuft, ist es übrigens möglich, Primary-Rolle und Secondary-Rolle wieder zu vertauschen, falls das notwendig sein sollte.

DRBD nachträglich installieren

Das Thema Hochverfügbarkeit wird immer wichtiger, und viele Setups, die zuvor als SPOFs ihr Dasein fristeten, sollen redundant werden. DRBD kommt da gerade recht: Es ist einerseits eine sehr günstige Lösung für redundante Daten, andererseits lässt es sich ohne größere Mühen auch auf existierende Setups anwenden, wenn die richtigen Tipps Beachtung finden.

Fakt ist: Nutzt eine DRBD-Ressource interne Metadaten, dann liegen diese am Ende der Ressource. Um auf ein vorhandenes Storage DRBD anzuwenden, muss es also entweder möglich sein, das Backing Device zu vergrößern (bei LVs in einer LVM-Volume-Group, in der noch Platz ist, ist das die eleganteste und sicherste Lösung) oder das darauf residierende Dateisystem zu verkleinern. Wer XFS verwendet, kann die Verkleinerungsvariante vergessen, denn XFS lässt sich ob seiner Eigenschaft als extent-basiertes Dateisystem grundsätzlich nicht schrumpfen.

Ist kein Plattenplatz für die Vergrößerung des Devices mehr vorhanden und kann das Dateisystem nicht verkleinert werden, bleibt als letzter Ausweg nur die Variante mit externen Meta-Daten.Wenn interne Meta-Daten möglich sind, ist der Rest des Vorgangs quasi das berühmte Schema F: Am Ende des zukünftigen Backing Devices ist so viel Platz freizuschaufeln, dass die Meta-Daten Platz haben.

Wie groß die Metadaten im schlimmsten Falle werden, lässt sich mit der Faustformel "32 kByte pro repliziertem Gigabyte" ungefähr herausfinden. Wenn sicher ist, dass genug freier Platz am Ende des Backing Devices vorhanden ist und für die Ressource eine brauchbare Konfigurationsdatei existiert, geht es mit »drbdadm create-md Ressource « wie gewohnt weiter. »drbdadm up Ressource « setzt die Ressource in Gang, »drbdadm -- --force primary Ressource « versetzt sie in den »Primary« -Modus. Ab sofort sind über die Ressource die gleichen Daten verfügbar, die vorher direkt vom Backing Device kamen. Im Anschluss kann der neue Clusterpartner folgen – fertig ist das Setup.