Host Based Mirror und Cluster-Filesystem

Eine häufig gestellte Frage bei Diskussionen um HA Architekturen ist: Ist es möglich, in einem 2-Node Cluster, wo die Hosts den zentralen SAN Storage mittels Host-Based Mirror über zwei Standorte spiegeln, ein Cluster-Filesystem einzusetzen?

Zur Erklärung:

Ein Host-based Mirror ist, genau wie ein RAID-1, ein synchroner Spiegel über zwei gleichartige (zumindest gleich große) Storageeinheiten. Der Begriff Host-based Mirror wird aber üblicherweise bei externem, über SAN angebundenem Storage verwendet, während bei RAID-1 meistens zwei interne Festplatten gemeint sind.

Ein Cluster-Filesystem ist ein Filesystem, bei dem mehrere Hosts blockbasiert Zugriff zum gemeinsamen Storage erhalten und das Filesystem gleichzeitig nutzen (mounten). Bekannte Cluster-Filesysteme sind z.B. OCFS2(Oracle Cluster Filesystem 2) von Oracle, GFS (Global File System) von RedHat oder GPFS (General Parallel File System) von IBM (International Business Machines). Im Gegensatz dazu unterstützen herkömmliche Filesysteme wie ext4 oder NTFS nur den Zugriff von einem Host.

Hinter der Architektur steckt der Wunsch, Dienste bei voller Redundanz im Active-Active Mode betreiben zu können. Das heißt, im Normalfall teilen sich beide Server die Last der zu bearbeitenden Aufgabe und reizen somit die zur Verfügung stehende Leistung maximal aus. Die Architektur soll jedoch

Die kurze Antwort auf obige Frage ist “Nein”. Die lange Antwort: Nein, aber es ist trotzdem leicht möglich, den gewünschten Effekt zu erzielen.

Auf den ersten Blick sieht es einfach aus. Zwei Hosts erhalten über SAN Zugriff auf zwei Storageeinheiten (LUN) an zwei Standorten. Auf den Hosts wird ein Host-based Mirroring eingerichtet. Das Ergebnis ist ein logisches Device pro Host. Über die beiden Hosts wird ein Cluster-Filesystem angelegt (vgl. Abb. 1).

Dieser Cluster funktioniert zunächst problemlos. Beide Server schreiben Änderungen an den gespeicherten Daten stets synchron auf beide Storagesysteme. Der jeweils andere Server sieht stets einen intakten Spiegel und hat auf alle Änderungen sofort Zugriff. Fällt ein Server aus, kann der andere alleine weiter Arbeiten; beim Wiederanlauf kann der ausgefallene Server sofort auf den aktiven Datenbestand zugreifen und weiter arbeiten. Fällt ein Storagesystem aus, dann nehmen beide Hosts es aus der Spiegelung; nach dem Wiederanlauf oder dem Austausch einer Festplatte muss der Spiegel neu erzeugt werden, aber das kann parallel zu den laufenden Arbeiten geschehen.

Sobald aber Pfade ausfallen (was ja in einem Host-Based Mirror Szenario vorkommen darf und Teil der Redundanz ist), gibt es Probleme. Angenommen, es fällt der Pfad von Server 1 zu Storage B sowie von Server 2 zu Storage A aus (vgl. Abb. 2).

Der Server 1 schreibt nun Änderungen nur noch auf den Storage A, die der Server 2 nicht sehen kann, weil er nur mit Storage B verbunden ist. Das Ergebnis ist ein Split-Brain Szenario. Das heißt, die Clusterknoten sehen unterschiedliche Daten, obwohl sich die Anwendungen darauf verlassen können müssen, stets die selben Daten zu sehen.

Aber es gibt dennoch eine Möglichkeit, das gewünschte Setup zu realisieren: anstatt des Host-based Mirrors verbindet man jeden Server nur mit einem Storagesystem. Die beiden Storages spiegelt man an den Servern mittels DRBD im Primary/Primary Modus. Das Resultat ist ein gemeinsames Device, auf das sich gefahrlos ein Cluster-Filesystem legen lässt (vgl. Abb. 3).

Auch diese Architektur hat die oben geforderten Eigenschaften. Beide Server können im Normalfall gleichzeitig auf den Daten arbeiten. Fällt ein Host aus, arbeitet der andere mit seinem Teil des Storage weiter; beim Wiederanlauf muss der Storage neu synchronisiert werden, das geschieht bei DRBD aber im Hintergrund. Fällt ein Storagesystem aus, können beide Server über DRBD auf dem anderen Storagesystem weiter arbeiten und das erste nach dem Wiederanlauf neu synchronisieren. Auch der Ausfall eines gesamten Standorts (ein Server und das dazugehörige Speichersystem) arbeitet das System noch. Anders bei dem obigen Szenario kann der Ausfall der SAN Leitungen durch den Ausfall eines Storagesystems modelliert werden.

Was diese Architektur nicht mehr toleriert, ist ein gleichzeitiger Ausfall “über Keuz”, z.B. von Storage A und Server 2. Dieser Nachteil ist jedoch gegenüber dem Betriebsrisiko der oben dargestellten Architektur leicht zu verschmerzen.