Activity Log

DRBD löst dieses Problem über eine Journaling-Implementation, im DRBD-Jargon Activity Log (AL) genannt. Über das Activity Log markiert ein Primary-Knoten bestimmte Bereiche des Device als aktiv, also unmittelbar von laufenden Schreiboperationen betroffen. Kommt es zu einem Ausfall des Primary-Knotens (und Übernahme der Applikation durch den anderen Knoten) mit anschließender Wiederherstellung des ausgefallenen Knotens, synchronisiert der zurückgekehrte Knoten die als aktiv markierten Bereiche zwangsweise nach (siehe Kasten „Activity Log“).

Die Synchronitäts-Bitmap und das Activity Log gemeinsam bilden jene Elemente von DRBD, die ein wesentliches Leistungsmerkmal der Software ausmachen: Bei richtiger Konfiguration halten sie nämlich die maximale Resynchronisationsdauer nach einem Crash nahezu konstant. Das ist ein unumgängliches Feature, denn wäre diese Zeit proportional zur Device-Größe, wären die Einsatzmöglichkeiten von DRBD bei großen Volumes äußerst eingeschränkt.

Split-Brain-Robustheit

Der Alptraum jedes Cluster-Administrators ist die Split-Brain-Situation: der Ausfall aller Netzwerkverbindungen zwischen den beiden Cluster-Knoten, während die Knoten selbst von keinem Ausfall betroffen sind. In einer solchen Situation muss die Cluster-Management-Software auf beiden Knoten annehmen, für den einzigen noch verfügbaren Cluster-Knoten verantwortlich zu sein. Sie reißt sämtliche Cluster-Ressourcen an sich. Bei der Verwendung konventioneller Shared-Storage-Hardware hat das potenziell desaströse Folgen: Über den vielleicht noch aktiven I/O-Pfad mounten nun beide ClusterKnoten ein normales Dateisystem mit Leseund Schreibzugriff und beschädigen es dadurch unausweichlich. Um derartige GAUs zu vermeiden, müssen Planer von Cluster-Systemen Node-Fencing-Strategien sehr genau planen, die den exklusiven Zugriff auf solche Ressourcen garantieren sollen.

DRBD schwächt dieses Problem massiv ab: Weil es zwei synchrone Replikate anstelle einer einzigen, geteilten Dateninstanz verwendet, ist die Zerstörung von Daten durch gleichzeitigen Schreibzugriff hier praktisch ausgeschlossen. Stattdessen entstehen durch die Split-Brain-Situation zwei divergente Datenstände. Das ist immer noch eine Situation, die eine rasche Bereinigung erfordert, aber bedeutend weniger dramatisch als die Zerstörung von Daten, wie sie beim Split Brain in Cluster-Architekturen mit Shared Storage auftreten kann. DRBD verfügt übrigens über mehrere automatische Bereinigungsstrategien nach Split Brain, die einen manuellen Eingriff überflüssig machen können.