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. Diese Anforderungen werden Im Abschnitt Analysieren der Eignung einer Anwendung aufgelistet. 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 Daten der Anwendung werden auf einem hoch verfügbaren Cluster-Dateisystem abgelegt. Im Falle eines Serverausfalls kann dann der verbleibende Server auf die Daten zugreifen. Weitere Informationen über die Cluster-Dateisysteme finden Sie im Sun Cluster Konzepthandbuch für 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.

Dieser Anhang behandelt die folgenden Themen:

• Multihost-Daten

• Hostnamen

• Multihomed Hosts

• Binden an INADDR_ANY im Gegensatz zum Binden an bestimmte IP-Adressen

• Client-Wiederholversuch

Multihost-Daten

Die Geräte der hoch verfügbaren Cluster-Dateisysteme haben mehrere Hosts (Multihost). Wenn also ein realer Host abstürzt, kann einer der noch funktionsfähigen Hosts auf das Gerät zugreifen. Damit eine Anwendung hoch verfügbar ist, müssen auch ihre Daten hoch verfügbar sein. Deshalb müssen sich die Anwendungsdaten in Dateisystemen befinden, auf die von mehreren Cluster-Knoten aus zugegriffen werden kann. Beispiele für hoch verfügbare Dateisysteme, die von Sun Cluster unterstützt werden, sind u.a. globale HA-Dateisysteme, Failover File System (FFS) und - in einer Umgebung, die Oracle Real Application Cluster verwendet – das gemeinsam genutzte QFS-Dateisystem.

Das Cluster-Dateisystem wird in Gerätegruppen eingehängt, die als unabhängige Einheiten erstellt werden. Der Benutzer kann festlegen, dass einige Gerätegruppen als eingehängte Cluster-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 verweisen. Wenn die Anwendung Pfadnamen verwendet, können Sie die Pfadnamen in symbolische Verknüpfungen ändern, die auf eine Datei in einem Cluster-Dateisystem verweisen, ohne den Anwendungscode zu ändern. Weitere Informationen zur Verwendung von symbolischen Verknüpfungen finden Sie im Abschnitt Verwenden von symbolischen Verknüpfungen für Multihost-Datenablage .

Im schlimmsten Fall muss der Quellcode der Anwendung geändert werden, um einen Mechanismus zum Verweisen auf den tatsächlichen Datenspeicherort anzubieten. Sie könnten diesen Mechanismus implementieren, indem Sie zusätzliche Befehlszeilenargumente erstellen.

Die Sun Cluster-Software unterstützt die Verwendung der UNIX UFS-Dateisysteme und der im raw-Modus betriebenen HA-Geräte, die in einem Datenträger-Manager konfiguriert werden. Bei der Installation und Konfiguration der Sun Cluster-Software muss der Cluster-Administrator angeben, welche Plattenressourcen für die UFS-Dateisysteme und welche Plattenressourcen für im raw-Modus betriebene Geräte verwendet werden müssen. 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

Gelegentlich sind die Pfadnamen von Anwendungsdatendateien so geschützt, dass sie nicht überschrieben werden können. 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 den Pfad z.B. in die symbolische Verknüpfung /global/phys-schost-2/mydatafile ändern.

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. Beispiel: Angenommen, die Anwendung führt ein Update durch, indem zuerst die neue temporäre Datei /etc/mydatafile.new erstellt wird. Anschließend benennt die Anwendung die temporäre Datei in den echten Dateinamen um. Dazu wird der Systemaufruf rename() (bzw. der Befehl mv) verwendet. Durch Erstellen der temporären Datei und Umbenennen in den echten Dateinamen versucht der Datendienst sicherzustellen, dass sein Datendateiinhalt immer richtig strukturiert ist.

Unglücklicherweise zerstört die rename()-Aktion die symbolische Verknüpfung. Der Name /etc/mydatafile bezeichnet jetzt eine normale Datei, die sich im selben Dateisystem wie das Verzeichnis /etc befindet, nicht jedoch im Cluster-Dateisystem. 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 besteht darin, dass die bereits vorhandene Anwendung die symbolische Verknüpfung nicht wahrnimmt und nicht für symbolische Verknüpfungen geschrieben wurde. 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 kein Allheilmittel für das Problem der Datenablage in den Dateisystemen des Clusters.

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. Ist dies der Fall, muss der Datendienst eventuell so geändert werden, dass er einen logischen Hostnamen und keinen physikalischen Hostnamen verwendet. In diesem Sinne ist ein logischer Hostname ein Hostname, der als logische Hostnamenressource konfiguriert ist, die sich in derselben Ressourcengruppe wie die Anwendungsressource befindet.

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. Er verfügt für jedes Netzwerk über ein Hostnamen–IP-Adressen-Paar. 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). So wie der physikalische Hostname aus mehreren Hostnamen–IP-Adressen-Paaren besteht, kann jede Ressourcengruppe über mehrere Hostnamen–IP-Adressen-Paare verfügen, nämlich jeweils eine für jedes öffentliche Netz. Wenn Sun Cluster eine Ressourcengruppe von einem physikalischen Host auf einen anderen physikalischen Host verschiebt, wird der komplette Satz von Hostnamen–IP-Adressen-Paaren für diese Ressourcengruppe verschoben.

Der Satz von Hostnamen–IP-Adressen-Paaren für eine Ressourcengruppe ist als logische Hostnamenressourcen konfiguriert, die in der Ressourcengruppe enthalten sind. Diese Netzwerkadressressourcen werden bei der Erstellung und Konfiguration der Ressourcengruppe vom Cluster-Administrator angegeben. Die Sun Cluster-Datendienst-API enthält Möglichkeiten zur Abfrage dieser Hostnamen–IP-Adressen-Paare.

Die meisten handelsüblichen Datendienst-Dämone, die für die Solaris-Umgebung 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. Ein Datendienst-Dämon, der INADDR_ANY verwendet, muss im Allgemeinen nicht geändert werden, um die logischen Sun Cluster-Netzwerkadressen zu verarbeiten.

Binden an INADDR_ANY im Gegensatz zum Binden an bestimmte 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 physikalischen Host und weitere IP-Adressen für jede Netzwerkadressressource (logischer Hostname), für die er derzeit als Master eingesetzt ist. 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 können in einer Sun Cluster-Umgebung nicht ordnungsgemäß ausgeführt werden, 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, die diese Funktion benötigen, muss die Eigenschaft Network_resources_used in der RTR-Datei für den Ressourcentyp deklariert sein.

Wenn RGM die Ressourcengruppe online oder offline bringt, wird für folgende Aktionen eine bestimmte Reihenfolge eingehalten: das Aktivieren bzw. Deaktivieren sowie das Konfigurieren von Netzwerkadressen nach oben oder unten im Verhältnis zu den RGM-Aufrufen von Datendienstressourcenmethoden. Weitere Informationen finden Sie im Abschnitt Verwendung von Start- und Stop-Methoden.

Sobald die Stop-Methode des Datendienstes zurückgegeben wird, muss der Datendienst anhand der Netzwerkadressen der Ressourcengruppe angehalten worden sein. 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 des Datendienstes ihre Arbeit durch Beenden und Neustarten der Datendienstdämonen fertig stellen, stoppt und startet der Datendienst unter Verwendung der Neztwerkadressen zum richtigen Zeitpunkt.

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 Fall eines einzelnen Serverabsturzes und -neustarts unterstützen, sind sie auch für das Failover bzw. Switchover der darin enthaltenen Ressourcengruppe geeignet. 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.