Anhang E Anforderungen für Anwendungen ohne Cluster-Unterstützung

Eine gewöhnliche Anwendung ohne Cluster-Unterstützung muss bestimmte Anforderungen erfüllen, um als hoch verfügbare Anwendung (HA-Anwendung) eingesetzt zu werden. Abschnitt Analysieren der Eignung einer Anwendung listet diese Anforderungen auf. Dieser Anhang enthält weitere Einzelheiten zu bestimmten Elementen in der Liste.

Eine Anwendung wird hoch verfügbar, indem ihre Ressourcen in Ressourcengruppen konfiguriert werden. Die Anwendungsdaten werden in einem hoch verfügbaren globalen Dateiystem abgelegt, in dem ein noch betriebsbereiter Server auf sie zugreifen kann, falls ein anderer Server ausfällt. Informationen über Cluster-Dateisysteme finden Sie im Sun Cluster Concepts Guide for Solaris OS.

Für den Netzwerkzugriff durch Clients im Netzwerk wird eine logische Netzwerk-IP-Adresse in logischen Hostnamenressourcen konfiguriert, die sich in derselben Ressourcengruppe wie die Datendienstressource befindet. Die Datendienstressource und die Netzwerkadressressourcen führen das Failover gemeinsam aus. Anschlie?end greifen die Netzwerk-Clients des Datendienstes auf die Datendienstressource auf ihrem neuen Host zu.

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.

Hostnamen

Sie müssen festlegen, ob Situationen möglich sind, in denen der Datendienst den Hostnamen des Servers kennen muss, auf dem er ausgeführt wird. Wenn dies der Fall ist, muss der Datendienst möglicherweise dahingehend geändert werden, dass er anstelle des realen Hostnamens einen logischen Hostnamen verwendet (das heißt, einen Hostnamen, der in eine logische Hostnamenressource konfiguriert wurde, die in derselben Ressourcengruppe wie die Anwendungsressource residiert).

Manchmal gibt der Server im Client/Server-Protokoll für einen Datendienst als Teil des Meldungsinhalts an den Client seinen eigenen Hostnamen zurück. Bei diesen Protokollen kann es sein, dass der Client von diesem zurückgegebenen Hostnamen abhängt, ihn also für die Verbindungsherstellung mit dem Server verwenden muss. Damit der zurückgegebene Hostname auch nach einem Failover bzw. Switchover noch verwendet werden kann, muss es sich um einen logischen Hostnamen der Ressourcengruppe handeln, und nicht um den Namen des realen Hosts. In diesem Fall müssen Sie den Datendienstcode dahingehend ändern, dass der logische Hostname an den Client zurückgegeben wird.

Multihomed Hosts

Der Begriff Multihomed Host beschreibt einen Host, der sich in mehr als einem öffentlichen Netzwerk befindet. Ein solcher Host hat mehrere Hostnamen und IP-Adressen. Für jedes Netzwerk verfügt er über ein Hostname-IP-Adressenpaar. Sun Cluster ist dafür ausgelegt, das Vorhandensein eines Hosts in einer beliebigen Anzahl von Netzwerken zuzulassen, einschließlich einem einzigen Netzwerk (der Nicht-Multihomed-Fall). Genau wie der reale Hostname über mehrere Hostname-IP-Adressenpaare verfügt, kann jede Ressourcengruppe mehrere Hostnamen-IP-Adressenpaare haben, also eines für jedes öffentliche Netzwerk. Wenn Sun Cluster eine Ressourcengruppe von einem realen Host auf einen anderen verschiebt, wird gleichzeitig der vollständige Satz Hostname-IP-Adressenpaare für diese Ressourcengruppe mit verschoben.

Der Satz Hostname-IP-Adressenpaare für eine Ressourcengruppe wird als logische Hostnamenressource innerhalb der Ressourcengruppe konfiguriert. Diese Netzwerkadressressourcen werden vom Systemverwalter beim Erstellen und Konfigurieren der Ressourcengruppe angegeben. Die Sun Cluster-Datendienst-API bietet Möglichkeiten zum Abfragen dieser Hostname-IP-Adressenpaare.

Die meisten handelsüblichen Datendienst-Dämone, die für das Solaris-Betriebssystem geschrieben wurden, verarbeiten Multihomed Hosts bereits korrekt. Viele Datendienste führen ihre gesamte Netzwerkkommunikation durch Binden an die Solaris-Platzhalteradresse INADDR_ANY durch. Durch das Binden wird automatisch bewirkt, dass die Datendienste alle IP-Adressen für alle Netzwerkschnittstellen verarbeiten. INADDR_ANY sorgt für eine effektive Bindung an alle aktuell auf dem Rechner konfigurierten IP-Adressen. Bei einem Datendienst, der INADDR_ANY verwendet, ist im Allgemeinen keine Änderung erforderlich, um die logischen Netzwerkadressen von Sun Cluster verarbeiten zu können.

Binden an INADDR_ANY im Vergleich zu Binden an spezifische IP-Adressen

Auch wenn Nicht-Multihomed Hosts verwendet werden, ermöglicht das Sun Cluster-Konzept der logischen Netzwerkadressen dem Rechner, mit mehr als einer IP-Adresse zu arbeiten. Der Rechner verfügt über eine IP-Adresse für seinen eigenen realen Host und über weitere IP-Adressen für jede Netzwerkadressressource (logische Hostname-Ressource), die er aktuell unterstützt. Wenn ein Rechner als Master einer Netzwerkadressressource eingesetzt wird, erhält er dynamisch weitere IP-Adressen. Sobald er nicht mehr Master einer Netzwerkadressressource ist, gibt er die IP-Adressen dynamisch wieder auf.

Einige Datendienste funktionieren in einer Sun Cluster-Umgebung nicht richtig, wenn sie an INADDR_ANY gebunden sind. Solche Datendienste müssen den Satz der IP-Adressen, an die sie gebunden sind, dynamisch ändern, sobald die Ressourcengruppe unterstützt bzw. nicht mehr unterstützt wird. Eine Möglichkeit zum Erzielen dieser Neubindung besteht darin, dass die Start- und Stop-Methoden dieser Datendienste das Stoppen der Datendienst-Dämone erzwingen und sie neu starten.

Die Ressourceneigenschaft Network_resources_used ermöglicht dem Endbenutzer das Konfigurieren eines spezifischen Satzes Netzwerkressourcen, an die eine Anwendungsressource zu binden ist. Für Ressourcentypen, bei denen diese Funktion erforderlich ist, muss die Eigenschaft Network_resources_used in der entsprechenden RTR-Datei deklariert werden.

Wenn RGM die Ressourcengruppe online bringt bzw. offline nimmt, folgt er einer bestimmten Reihenfolge für das Anmelden, Abmelden und Aktiv- bzw. Inaktiv-Konfigurieren im Zusammenhang mit dem Aufruf der Datendienst-Ressourcenmethoden. Weitere Einzelheiten finden Sie unter Bestimmen der zu verwendenden Start- und Stop-Methoden.

Bei Rückgabe der Stop-Methode muss der Datendienst die Verwendung der Netzwerkadressen der Ressourcengruppe eingestellt haben. Analog dazu muss der Datendienst bei Rückgabe der Start-Methode mit der Verwendung der Netzwerkadressen begonnen haben.

Wenn der Datendienst anstelle von einzelnen IP-Adressen an INADDR_ANY gebunden wird, spielt die Reihenfolge, in der die Datendienstressourcenmethoden und die Netzwerkadressmethoden aufgerufen werden, keine Rolle mehr.

Wenn die Stop- und Start-Methoden ihre Aufgabe ausführen, indem sie das Stoppen der Datendienst-Dämone erzwingen und diese neu starten, beendet bzw. beginnt der Datendienst die Verwendung der Netzwerkadressen zu den richtigen Zeitpunkten.

Client-Wiederholversuch

Für einen Netzwerk-Client wirkt ein Failover bzw. Switchover wie ein Absturz des logischen Hosts, gefolgt von einem schnellen Neustart. Im Idealfall sind die Client-Anwendung und das Client/Server-Protokoll so strukturiert, dass mehrere Wiederholversuche unternommen werden. Wenn die Anwendung und das Protokoll bereits den Absturz und Neustart eines einzelnen Servers unterstützen, können sie auch Takeover bzw. Switchover der Ressourcengruppe unterstützen. Einige Anwendungen unternehmen möglicherweise eine endlose Anzahl an Wiederholversuchen. Komplexere Anwendungen benachrichtigen den Benutzer darüber, dass ein lang andauernder Wiederholvorgang läuft, so dass der Benutzer entscheiden kann, ob er fortfährt oder den Prozess abbricht.