Beispiel-Cluster

Als Beispiel für diesen Beitrag wird ein DreiKnoten-Cluster mit manuellem Fencing konfiguriert. Die beteiligten Rechner haben die Hostnamen »testX.beispiel.de« (X=1, 2, 3) und die IP-Adressen 192.168.1.21Y (Y=0, 1, 2). Das Beispiel verwendet den Distributed Lock Manager. Die in Listing 2 gezeigte Datei »cluster.conf« befindet sich auf allen Rechnern im Verzeichnis »/etc/cluster«. Der Daemon »ccsd« ist gestartet, das Kernel-Modul »lock_dlm.ko« geladen, und alle Rechner sind dem Cluster über das Kommando »cman_tool join« beigetreten.

<?xml version="1.0"?>
<cluster config_version="1" name="gfs2">
   <fence_daemon post_fail_delay="0" post_join_delay="3"/>
   <clusternodes>
      <clusternode name="test1.beispiel.de" nodeid="1" votes="1">
         <fence>
            <method name="1">
               <device name="manual" nodename="test1.beispiel.de"/>
            </method>
        </fence>
      </clusternode>
   <clusternode name="test2.beispiel.de" nodeid="2" votes="1">
       <fence>
            <method name="1">
               <device name="manual" nodename="test2.beispiel.de"/>
            </method>
        </fence>
      </clusternode>
   <clusternode name="test3.beispiel.de" nodeid="3" votes="1">
        <fence>
           <method name="1">
                <device name="manual" nodename="test3.beispiel.de"/>
           </method>
        </fence>
   </clusternode>
</clusternodes>
<cman/>
   <fencedevices>
      <fencedevice agent="fence_manual" name="manual"/>
   </fencedevices>
   <rm>
      <failoverdomains>
         <failoverdomain name="default"/>
      </failoverdomains>
      <resources/>
   </rm>
</cluster>

Bevor ein Rechner auf ein GFS2 zugreifen kann, muss der Fence Daemon auf diesem Knoten laufen. Dies erledigt das Kommando »fence_tool join«. Sind alle drei Rechner der Fence-Domain beigetreten (so heißt dieser Vorgang im ClusterJargon), ist der Cluster bereit für den Zugriff auf ein GFS2.

Für einen Funktionstest simuliert das Herunterfahren der Schnittstelle »eth0« den Ausfall der Netzwerkkarte. Im Syslog eines anderen Knotens vermerkt der Cluster-Manager, dass zu viele Heartbeats dieses Knotens fehlen und weist an, ihn aus der Liste der aktiven Knoten auszutragen. Mit dem Kommando »cman_tool nodes« kann man sich den Status der Cluster-Nodes anschauen (Listing 3). Aktive Knoten kennzeichnet ein »M« (Member), den fehlerhaften Rechner dagegen ein »X« (Excluded).

GFS2-Innenansicht Ohne Hilfsmittel kann GFS2 nicht mehrere physikalische Massenspeicher gleichzeitig ansprechen. Ist das SAN durch mehrere Dateien im Verzeichnis »/dev« repräsentiert, ist eine logische Zwischenschicht notwendig. Der für GFS2 vorgeschriebene Weg ist die Verwendung des Cluster Logical Volume Managers (CLVM). Der CLVM ist ein um Cluster-Fähigkeiten erweiterter LVM2. Seine Aufgabe ist es, die Volume-Metadaten im gesamten Cluster sichtbar zu machen und Inkonsistenzen durch konkurrierende Schreibzugriffe zu vermeiden. Die Cluster-Erweiterung des LVM2 sind für den Anwender völlig transparent. Der Admin benutzt die gleichen Kommandos – die konfigurierten Volumes auf dem SAN sind aber im gesamten Cluster sichtbar und nicht nur auf einem Knoten.

Der CLVM-Daemon eines jeden Cluster-Rechners hat eine Kopie der Metadaten aller Volumes. Zur Vermeidung von Inkonsistenzen verwendet der CLVM einen Locking-Mechanismus. Ändert ein Knoten die Eigenschaften eines Volume, sorgt der Cluster Lock Manager (CLM) dafür, dass die beteiligten Speichermedien für Schreibzugriffe weiterer Rechner im Cluster gesperrt sind. Die aktualisierten Metadaten des Volume verteilt der CLVM auf alle Cluster-Knoten und weist den Lock-Manager danach an, die Schreibsperre wieder aufzuheben.

Der GFS2-Superblock enthält wie gewohnt die Basisinformationen des Dateisystems: GFS2Formatversion, Blockgröße, Inodes von Spezialdateien und eine eindeutige Nummer (UUUID). Die Superblockdaten schreibt GFS2 erst ab dem 6. KByte auf den Speicher. Die ersten 64 KByte sind aus purer Vorsicht freigelassen worden, um möglichen Kollisionen mit inkompatibler Volume-Management-Software vorzubeugen, die Informationen in die ersten Blöcke schreiben könnte. Sieht man vom Superblock ab, ist das GFS2 in Resource Groups (RG) und Journals unterteilt.

Die RG entsprechen in etwa den Zylindergruppen eines klassischen Unix-Dateisystems. Jede Resource Group verwaltet eine eigene Block-Allokierungs-Statistik, eine BlockAllokierungs-Bitmap und natürlich die Blöcke selbst. Die Standardgröße einer RG beträgt 256 MByte und kann zwischen 32 und 2048 MByte variieren. Die tatsächliche Größe richtet sich nach dem zu allokierenden Speicher. Je nach Funktion unterscheidet man Datenblöcke und Metadatenblöcke. Die Allokierung der Metadatenblöcke erfolgt dynamisch. Ein frisch angelegtes GFS2 besitzt nur ein paar Metadatenblöcke.

Journale

Die Journale sind temporäre Kopien der Metadatenblöcke aus den Resource Groups. Pro Cluster-Knoten, der das GFS2 mountet, muss ein Journal existieren. Die Anzahl der Journale legt der Admin beim Anlegen des GFS2 fest. Ohne zusätzlichen Storage ist eine nachträgliche Erhöhung der Journal-Anzahl nicht möglich. Die physikalische Lage der Journale ist beliebig, in der Standardeinstellung reserviert GFS2 128 MByte pro Journaldatei. Prinzipiell verwaltet jeder Knoten zunächst sein eigenes Journal, hat aber auch Zugriff auf die Journal-Dateien der anderen Cluster-Nodes. Im Fall eines gecrashten Cluster-Rechners kann ein anderer Knoten das fremde Journal lesen und entsprechende Dateisystem-Recovery-Aktionen durchführen. Jedes Global File System enthält eine Handvoll Spezialdateien in Form von versteckten Inodes. Dazu gehört der Index der Resource Groups, der Index der Journale, Quota-Informationen des gesamten Dateisystems und natürlich der Root-Inode. Ein frisch generiertes GFS2 enthält nur die Spezial-Inodes – die Inodes für neu anzulegende Dateien allokiert GFS2 dynamisch.