NAS-Speicher mit einer Kapazität von einigen Dutzend Terabyte, wie sie sich für mittelständische Anwender eignen, nimmt die ADMIN-Redaktion in der Ausgabe ... (mehr)

Vorbereitungen

Für sämtliche Fencing-Methoden gilt es, die passenden Vorbereitungen zu treffen. Was in Sachen Redundanz für den normalen Pacemaker-Betrieb gilt, gilt im Fencing-Kontext um so mehr: Die einzelnen Knoten eines Clusters sollten mehrere, voneinander unabhängige Kommunikationspfade haben. Kommt DRBD zum Einsatz, ist das meist kein größeres Problem: Häufig findet sich in Zwei-Knoten-Clustern mit DRBD ein eigener Back-to-Back-Link, über den die DRBD-Kommunikation läuft. Diese Verbindung zusammen mit der "normalen" Verbindung zur Außenwelt, über die der jeweils andere Clusterknoten ebenso erreichbar ist, sorgt für ein zuverlässiges redundantes Netzwerk-Setup. Denn damit alle Kommunikationspfade sterben, müsste einerseits der Switch kaputtgehen, über den die beiden Knoten kommunizieren. Und andererseits müsste auch die direkte Netzwerkverbindung Schaden nehmen, beispielsweise weil ein Chip auf einer Netzwerkkarte versagt. Kommunikationspfade heißen im Pacemaker-Kontext Ring, folglich ist ein Setup wie das beschriebene ein Redundant Ring Setup.

Auch wenn kein DRBD zum Einsatz kommt, sollte es mehr als einen Ring geben, über den die Clusterknoten miteinander kommunizieren können. Dabei sei vor Setups gewarnt, die letztlich wieder zu einem gemeinsamen Single Point of Failure führen: Zwei Kommunikationsringe, die durch denselben Switch führen, sind Augenwischerei, denn ein Ausfall des Switches bewirkt dann den Ausfall beider Kommunikationspfade.

Resource Level Fencing mit DRBD

DRBD beherrscht wie bereits erwähnt das Fencing auf Ressourcen-Ebene. Im Falle eines Falles hat Pacemaker so die Möglichkeit, die DRBD-Resource auf einem Clusterknoten temporär unbrauchbar zu machen. Das Feature ist nützlich, um Pacemaker bei Ausfall des DRBD-Replikationslinks richtig reagieren zu lassen.

Im Normalfall wird eine DRBD-Ressource auf dem einen Knoten die Primary-Rolle haben und auf dem anderen die Secondary-Rolle. Solange der Datenaustausch funktioniert und der Disk-State der Ressource auf den Knoten »UpToDate« ist – überprüfen lässt sich das über den Inhalt von »/proc/drbd« – ist für DRBD die Welt in Ordnung. Bricht der DRBD-Link allerdings weg, gerät die Replikationslösung in Schwierigkeiten. Denn dass der Secondary-Knoten dann immer weiter hinterherhinkt, bemerkt er nicht. Ohne fremden Eingriff wäre es denkbar, dass zu einem späteren Zeitpunkt der Primary-Knoten ausfällt, Pacemaker dann einen Failover durchführt und anschließend mit den alten Daten des Secondary-Knotens weiterarbeitet, der sich problemlos in die Primary-Rolle schalten lässt.

comments powered by Disqus
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