Schreiben und Testen von Datendiensten

Verwenden des TCP-Keep-Alive-Mechanismus für den Serverschutz

Wenn Sie auf Serverseite einen TCP-Keep-Alive-Mechanismus verwenden, wird der Server geschützt und es werden keine Systemressourcen für einen heruntergefahrenen (oder netzwerk-partitionierten) Client verschwendet. Wenn diese Ressourcen nicht auf einem Server bereinigt werden, der lange genug ausgeführt wird, wachsen die verschwendeten Ressourcen beim Absturz und Neustart von Clients endlos an.

Wenn für die Client-Server-Kommunikation ein TCP-Stream verwendet wird, sollten sowohl der Client als auch der Server den TCP-Keep-Alive-Mechanismus aktivieren. Dies gilt auch für einzelne Nicht-HA-Server.

Andere verbindungsorientierte Protokolle können ebenfalls über einen Keep-Alive-Mechanismus verfügen.

Wenn auf Client-Seite TCP-Keep-Alive verwendet wird, wird der Client benachrichtigt, wenn für eine Netzwerkadressressource ein Failover oder Switchover von einem physikalischen Host an einen anderen stattfindet. Diese Übertragung der Netzwerkadressressource bricht die TCP-Verbindung ab. Wenn der Client allerdings das Keep-Alive nicht aktiviert hat, wird die Verbindungsunterbrechung möglicherweise nicht festgestellt, wenn die Verbindung zu diesem Zeitpunkt ruhte.

Angenommen, der Client wartet zum Beispiel auf die Antwort des Servers auf eine langfristige Anforderung, und die Anforderungsmeldung des Clients ist bereits beim Server angekommen und wurde auf TCP-Ebene bestätigt. In diesem Fall muss das TCP-Modul des Clients die Anforderung nicht ständig erneut übertragen. Außerdem ist die Client-Anwendung blockiert und wartet auf eine Antwort auf die Anforderung.

Die Client-Anwendung muss, wenn mögich, nicht nur den TCP-Keep-Alive-Mechanismus verwenden, sondern auch eigene Keep-Alives auf seiner Ebene durchführen. Der TCP-Keep-Alive-Mechanismus ist nicht in allen möglichen Grenzfällen die optimale Lösung. Wenn Sie einen Keep-Alive-Mechanismus auf Anwendungsebene verwenden, ist es in der Regel erforderlich, dass das Client-Server-Protokoll eine Null-Operation unterstützt oder zumindest eine effiziente schreibgeschützte Operation, wie z.B. eine Statusoperation.

Testen von HA-Datendiensten

Dieser Abschnitt enthält Vorschläge zum Testen einer Datendienstimplementierung in der HA-Umgebung. Die Testfälle sind Beispiele und daher nicht umfassend. Sie benötigen Zugang zu einer Sun Cluster-Testkonfiguration, sodass die Tests die Produktionsmaschinen nicht beeinträchtigen.

Testen Sie, ob sich der HA-Datendienst in allen Fällen richtig verhält, in denen eine Ressourcengruppe zwischen den physikalischen Hosts verschoben wird. Diese Fälle schließen Systemabstürze und die Verwendung des scswitch-Befehls mit ein. Testen Sie, ob die Client-Rechner nach diesen Ereignissen weiterhin Dienste erhalten.

Testen Sie die Idempotenz der Methoden. Ersetzen Sie zum Beispiel jede Methode vorübergehend mit einem kurzen Shell-Skript, das die Originalmethode zwei oder mehrere Male aufruft.

Koordinieren von Abhängigkeiten zwischen Ressourcen

Manchmal stellt ein Client-Server-Datendienst Anforderungen an einen anderen Client-Server-Datendienst, während er eine Anforderung für einen Client erfüllt. Datendienst A ist zum Beispiel von Datendienst B abhängig, wenn Datendienst B seinen Dienst bereitstellen muss, damit Datendienst A seinen Dienst bereitstellen kann. Um dieser Anforderung zu entsprechen, lässt Sun Cluster die Konfiguration von Ressourcenabhängigkeiten innerhalb einer Ressourcengruppe zu. Die Abhängigkeiten wirken sich auf die Reihenfolge aus, in der Sun Cluster Datendienste startet und stoppt. Einzelheiten finden Sie in der Online-Dokumentation unter scrgadm(1M).

Wenn die Ressourcen Ihres Ressourcentyps von einem anderen Typ abhängig sind, müssen Sie den Cluster-Administrator anweisen, die Ressourcen und Ressourcengruppen richtig zu konfigurieren. Liefern Sie als Alternative Skripts oder Tools für die richtige Konfiguration. Wenn die abhängige Ressource auf demselben Knoten wie die “depended-on”-Ressource ausgeführt werden muss, müssen beide Ressourcen in derselben Ressourcengruppe konfiguriert werden.

Entscheiden Sie, ob Sie ausdrückliche Ressourcenabhängigkeiten verwenden möchten oder ob Sie sie auslassen möchten und die Verfügbarkeit der anderen Datendienste im Code des HA-Datendienstes abfragen möchten. Falls die abhängige Ressource und diejenige, von der sie abhängt, auf unterschiedlichen Knoten laufen können, werden sie in unterschiedlichen Ressourcengruppen konfiguriert. In diesem Fall ist das Abfragen erforderlich, weil eine Konfiguration der Ressourcenabhängigkeiten über mehrere Gruppen hinweg nicht möglich ist.

Einige Datendienste speichern die Daten nicht direkt selbst. Stattdessen sind sie von einem anderen Backend-Datendienst abhängig, der alle ihre Daten speichert. Ein solcher Datendienst überträgt alle Lese- und Aktualisierungsanforderungen in Aufrufe an den Backend-Datendienst. Stellen Sie sich zum Beispiel einen hypothetischen Client-Server-Terminkalenderdienst vor, der alle Daten in einer SQL-Datenbank, z.B. Oracle, speichert. Der Terminkalenderdienst verfügt über ein eigenes Client/Server-Netzwerkprotokoll. Es kann zum Beispiel ein Protokoll unter Verwendung einer RPC-Spezifikationssprache definiert haben, wie ONC RPC.

In der Sun Cluster-Umgebung können Sie HA-ORACLE verwenden, um die Backend-ORACLE-Datenbank hoch verfügbar zu machen. Anschließend können Sie einfache Methoden zum Starten und Stoppen des Terminkalender-Dämons schreiben. Der Cluster-Administrator registriert den Terminkalender-Ressourcentyp bei Sun Cluster.

Wenn die Terminkalenderanwendung auf demselben Knoten ausgeführt werden muss wie die Oracle-Datenbank, konfiguriert der Cluster-Administrator die Terminkalenderressource in derselben Ressourcengruppe wie die HA-ORACLE-Ressource und macht die Terminkalender-Ressource abhängig von der HA-ORACLE-Ressource. Diese Abhängigkeit wird mit dem Resource_dependencies-Eigenschaftstag in scrgadm angegeben.

Wenn die HA-ORACLE-Ressource auf einem anderen Knoten als die Terminkalenderressource ausgeführt werden kann, konfiguriert sie der Cluster-Administrator in zwei separate Ressourcengruppen. Der Cluster-Administrator könnte eine Ressourcengruppenabhängigkeit der Kalenderressourcengruppe in der Oracle-Ressourcengruppe konfigurieren. Ressourcengruppenabhängigkeiten sind jedoch nur dann effektiv, wenn beide Ressourcengruppen auf demselben Knoten gleichzeitig gestartet bzw. gestoppt werden. Daher kann der Kalender-Datendienstdämon nach dem Starten das Warten auf die Verfügbarkeit der Oracle-Datenbank aufrufen. In diesem Fall gibt die Start-Methode des Kalenderressourcentyps in der Regel Erfolg aus. Wenn die Start-Methode unendlich lange blockieren würde, würde diese Methode jedoch ihre Ressourcengruppe in einen "Besetzt"-Zustand versetzen. Dieser Zustand würde alle weiteren Zustandsänderungen verhindern, z.B. Bearbeitungen, Failover oder Switchover in der Gruppe. Wenn die Start-Methode der Kalenderressource jedoch die Zeit überschritten hat oder mit einem Nicht-Null-Status beendet wurde, kann dies zu einem "Ping-Pong" der Ressourcengruppe zwischen zwei oder mehr Knoten führen und die Oracle-Datenbank nicht mehr verfügbar sein.