Schreiben und Testen von Datendiensten

Dieser Abschnitt enthält einige Informationen zum Schreiben und Testen von Datendiensten.

Verwenden von Keep-Alives

Auf der Serverseite schützt die Verwendung von TCP-Keep-Alives den Server vor der Verschwendung von Systemressourcen an einen heruntergefahrenen bzw. netzwerkpartitionierten Client. Wenn diese Ressourcen nicht bereinigt werden (auf einem Server, der lange genug aktiv bleibt), wachsen die verschwendeten Ressourcen schließlich unkontrolliert an, während die Clients abstürzen und neu starten.

Wenn die Client/Server-Kommunikation einen TCP-Strom verwendet, 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.

Auf der Clientseite ermöglicht die Verwendung von TCP-Keep-Alives dem Client, eine Benachrichtigung zu erhalten, wenn eine Netzwerkressource ein Failover bzw. Switchover von einem realen Host zu einem anderen ausgeführt hat. 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 dieser Situation braucht das TCP-Modul des Clients die Anforderung nicht immer neu zu übertragen, und die Client-Anwendung ist blockiert, während sie die Antwort auf die Anforderung abwartet.

Womöglich sollte die Client-Anwendung zusätzlich zur Verwendung des TCP-Keep-Alive-Mechanismus ebenfalls in regelmäßigen Abständen ihr eigenes Keep-Alive ausführen, da der TCP-Mechanismus nicht in allen möglichen Grenzfällen perfekt funktioniert. Für die Verwendung eines Keep-Alive auf Anwendungsebene muss das Client/Server-Protokoll normalerweise einen Null-Vorgang unterstützen, oder zumindest einen effizienten schreibgeschützten Vorgang, wie einen Statusvorgang.

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 Zugriff auf eine Testkonfiguration von Sun Cluster, damit sich das Testen nicht auf die Produktionsrechner auswirkt.

Testen Sie, ob sich der HA-Datendienst in allen Fällen richtig verhält, wenn eine Ressourcengruppe zwischen realen 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 gleichzeitig einer Client-Anforderung nachkommt. Grob gesagt hängt ein Datendienst A von einem Datendienst B ab, wenn A seinen Dienst nur bereitstellen kann, sofern B seinen Dienst bereitstellt. 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 Ressourcen Ihres Ressourcentyps von Ressourcen eines anderen Typs abhängen, müssen Sie den Benutzer anweisen, die Ressourcen und Ressourcengruppen entsprechend zu konfigurieren bzw. Skripts oder Tools für die korrekte Konfiguration bereitstellen. Wenn die abhängige Ressource auf demselben Knoten wie diejenige Ressource, von der sie abhängt, läuft, müssen beide Ressourcen in derselben Ressourcengruppe konfiguriert werden.

Sie müssen entscheiden, ob Sie explizite Ressourcenabhängigkeiten verwenden möchten oder darauf verzichten und sich für die Verfügbarkeit von anderen Datendiensten im eigenen Code Ihres HA-Datendienstes entscheiden. 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 ein Abruf erforderlich, da keine Ressourcenabhängigkeiten zwischen Gruppen konfiguriert werden können.

Einige Datendienste speichern keine Daten direkt, sondern hängen von einem anderen Backend-Datendienst für das Speichern aller Daten ab. Ein solcher Datendienst überträgt alle Lese- und Aktualisierungsanforderungen in Aufrufe an den Backend-Datendienst. Ein Beispiel wäre ein Client/Server-Terminkalenderdienst, der alle Daten in einer SQL-Datenbank wie Oracle aufbewahrt. 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. Dann können Sie einfache Methoden für das Starten und Stoppen des Terminkalenderdämons schreiben. Der Endbenutzer registriert den Terminkalender-Ressourcentyp bei Sun Cluster.

Wenn die Terminkalenderanwendung auf demselben Knoten wie die Oracle-Datenbank laufen muss, konfiguriert der Endbenutzer die Terminkalenderressource in derselben Ressourcengruppe wie die HA-ORACLE-Ressource und macht die Terminkalenderressource von der HA-ORACLE-Ressource abhängig. Diese Abhängigkeit wird über die Eigenschaftsmarkierung Resource_dependencies in scrgadm angegeben.

Wenn die HA-ORACLE-Ressource auf einem anderen Knoten als die Terminkalenderressource laufen kann, konfiguriert der Endbenutzer sie in zwei getrennten Ressourcengruppen. Der Endbenutzer kann eine Ressourcengruppenabhängigkeit der Terminkalendergruppe von der Oracle-Ressourcengruppe konfigurieren. Die Ressourcengruppenabhängigkeiten sind jedoch nur dann wirksam, wenn beide Ressourcengruppen gleichzeitig auf demselben Knoten gestartet bzw. gestoppt werden. Daher kann der Kalender-Datendienstdämon nach dem Starten das Warten auf die Verfügbarkeit der Oracle-Datenbank aufrufen. Die Start-Methode des Kalenderressourcentyps gibt in einem solchen Fall in der Regel einfach Erfolg zurück, da eine unbegrenzte Sperre der Start-Methode ihre Ressourcengruppe in einen belegten Zustand versetzen würde. Dann wären keine weiteren Zustandsänderungen der Gruppe wie zum Beispiel Bearbeitungen, Failover oder Switchover mehr möglich. Wenn jedoch die Zeit für die Start-Methode der Kalenderressource überschritten bzw. als Nicht-Null beendet wird, könnte es vorkommen, dass die Ressourcengruppe in eine Schleife zwischen zwei oder mehr Knoten gerät, während die Oracle-Datenbank nicht verfügbar bleibt.