Multihost-Daten

Die Plattensätze der hoch verfügbaren globalen Dateisysteme haben mehrere Hosts (Multihost). Wenn also ein realer Host abstürzt, kann einer der noch funktionsfähigen Hosts auf die Platte zugreifen. Damit eine Anwendung hoch verfügbar sein kann, müssen auch ihre Daten hoch verfügbar sein, sich also in den globalen HA-Dateisystemen befinden.

Das globale Dateisystem wird in Plattengruppen eingehängt, die als unabhängige Einheiten erstellt werden. Der Benutzer kann festlegen, dass einige Plattengruppen als eingehängte globale Dateisysteme verwendet werden und andere als im raw-Modus betriebene Geräte für die Verwendung mit einem Datendienst wie HA Oracle.

Eine Anwendung kann über Befehlszeilenschalter oder Konfigurationsdateien verfügen, die auf den Speicherort der Datendateien zeigen. Wenn die Anwendung fest verdrahtete Pfadnamen verwendet, können Sie die Pfadnamen in symbolische Verknüpfungen ändern, die auf die Dateien in einem globalen Dateisystem zeigen, ohne dabei den Anwendungscode zu ändern. Weitere Einzelheiten zur Verwendung von symbolischen Verknüpfungen finden Sie unter Verwenden von symbolischen Verknüpfungen für Multihost-Datenablage.

Im schlimmsten Fall muss der Anwendungsquellcode geändert werden, um einen Mechanismus bereitzustellen, der auf den tatsächlichen Datenspeicherort zeigt. Eine Möglichkeit hierfür ist das Implementieren zusätzlicher Befehlszeilenschalter.

Sun Cluster unterstützt die Verwendung von UNIX UFS-Dateisystemen und im raw-Modus betriebenen HA-Geräten, die in einem Datenträger-Manager konfiguriert werden. Bei der Installation und Konfiguration muss der Systemverwalter angeben, welche Plattenressourcen für UFS-Dateisysteme bzw. für im raw-Modus betriebene Geräte verwendet werden. In der Regel werden im raw-Modus betriebene Geräte nur von Datenbank- und Multimedia-Servern verwendet.

Verwenden von symbolischen Verknüpfungen für Multihost-Datenablage

In manchen Fällen sind die Pfadnamen der Datendateien einer Anwendung fest verdrahtet, und es ist kein Mechanismus zum Übersteuern dieser fest verdrahteten Pfadnamen vorhanden. Um Änderungen am Anwendungscode zu vermeiden, können manchmal symbolische Verknüpfungen verwendet werden.

Beispiel: Angenommen, die Anwendung benennt ihre Datendateien mit dem fest verdrahteten Pfadnamen /etc/mydatafile. Diesen Pfad können Sie in eine symbolische Verknüpfung ändern, deren Wert auf eine Datei in einem der Dateisysteme des logischen Hosts zeigt. Sie können zum Beispiel eine symbolische Verknüpfung mit /global/phys-schost-2/mydatafile herstellen.

Bei der Verwendung von symbolischen Verknüpfungen kann jedoch ein Problem auftreten, wenn die Anwendung bzw. eines ihrer Verwaltungsverfahren neben dem Inhalt auch den Namen der Datendatei ändert. Angenommen, die Anwendung nimmt zunächst eine Aktualisierung vor, indem sie eine neue temporäre Datei /etc/mydatafile.new erstellt. Dann benennt sie die temporäre Datei mit dem Systemaufruf rename(2) bzw. dem Programm mv(1) um, um ihr den echten Dateinamen zu geben. Durch das Erstellen der temporären Datei mit anschließender Umbenennung in die echte Datei versucht der Datendienst sicherzustellen, dass der Datendateiinhalt immer richtig gebildet wird.

Leider wird die symbolische Verknüpfung jedoch durch die rename(2)-Aktion zerstört. Der Name /etc/mydatafile ist nun eine reguläre Datei in demselben Dateisystem wie das /etc-Verzeichnis, nicht im globalen Dateisystem des Clusters. Da das /etc-Dateisystem für jeden Host privat ist, stehen die Daten nach einem Failover bzw. Switchover nicht zur Verfügung.

Das zugrunde liegende Problem in diesem Fall ist, dass die vorhandene Anwendung die symbolische Verknüpfung nicht wahrnimmt. Sie wurde nicht im Hinblick auf symbolische Verknüpfungen geschrieben. Wenn symbolische Verknüpfungen für die Umleitung des Datenzugriffs auf die Dateisysteme des logischen Hosts verwendet werden sollen, muss sich die Anwendungsimplementierung so verhalten, dass sie die symbolischen Verknüpfungen nicht löscht. Symbolische Verknüpfungen sind also keine völlig zufriedenstellende Lösung für das Problem, wie Daten im globalen Cluster-Dateisystem abgelegt werden können.