Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS

Verfahren für Ereigniszustellungen vom Server an den Client

Wenn innerhalb des Clusters Ereignisse generiert werden, stellt sie der CRNP-Server jedem Client zu, der die Ereignisse dieser Typen anforderte. Die Zustellung besteht im Senden einer SC_EVENT-Meldung an die Rückmeldeadresse des Clients. Jedes Ereignis wird über eine neue TCP-Verbindung zugestellt.

Unmittelbar nach der Client-Registrierung für einen Ereignistyp sendet der Server über eine SC_CALLBACK_REG-Meldung mit einer ADD_CLIENT-Meldung bzw. einer ADD_EVENT-Meldung dem Client das neueste Ereignis des entsprechenden Typs. Der Client kann den aktuellen Status des Systems bestimmen, aus dem die nachfolgenden Ereignisse stammen.

Wenn der Server eine TCP-Verbindung mit dem Client herstellt, sendet er genau eine SC_EVENT-Meldung über die Verbindung. Der Server führt eine Vollduplexbeendigung durch.

Der Client führt zum Beispiel folgende Aktionen aus:

  1. Abwarten einer vom Server hergestellten TCP-Verbindung,

  2. Akzeptieren der eingehenden Verbindung vom Server,

  3. Warten auf eine SC_EVENT-Meldung vom Server

  4. Lesen einer SC_EVENT-Meldung vom Server

  5. Erhalten einer Anzeige, dass der Server die Verbindung beendet hat (Lesen von 0 Bytes vom Socket),

  6. Beenden der Verbindung.

Wenn sich alle Clients registriert haben, müssen sie jederzeit ihre Rückmeldeadressen (IP-Adresse und Port-Nummer) abhören, um eine eingehende Verbindung für die Ereigniszustellung abzuwarten.

Wenn der Server keinen Kontakt mit dem Client aufnehmen kann, um ein Ereignis zuzustellen, versucht der Server eine vom Benutzer definierte Anzahl von Malen innerhalb eines definierten Zeitintervalls erneut, das Ereignis zuzustellen. Wenn alle Versuche fehlschlagen, wird der Client aus der Client-Liste des Servers entfernt. Der Client muss sich auch erneut registrieren, indem eine andere SC_CALLBACK_REG-Meldung gesendet wird, die eine ADD_CLIENT-Meldung enthält, bevor der Client weitere Ereignisse erhalten kann.

Garantie der Ereigniszustellung

Es gibt eine Gesamtanforderung der Ereignisgenerierung innerhalb des Clusters, die in der Reihenfolge der Zustellung an jeden Client beibehalten wird. Mit anderen Worten: Wenn Ereignis A innerhalb des Clusters vor Ereignis B generiert wird, erhält Client X Ereignis A, bevor dieser Client Ereignis B erhält. Die gesamte Ereigniszustellung an alle Clients wird jedoch nicht beibehalten. Das heißt, dass Client Y beide Ereignisse A und B erhalten kann, bevor Client X das Ereignis A erhält. Dadurch wird sichergestellt, dass langsame Clients nicht die Zustellung an alle Clients aufhalten.

Alle Ereignisse, die der Server zustellt (mit Ausnahme des ersten Ereignisses für eine Unterklasse und von Ereignissen, die auf Serverfehler folgen), sind eine Reaktion auf die tatsächlichen Ereignisse, die der Cluster generiert, es sei denn, beim Server tritt ein Fehler auf, durch den er im Cluster generierte Ereignisse nicht erfasst. In diesem Fall generiert der Server ein Ereignis für jeden Ereignistyp, das den aktuellen Zustand des Systems für diesen Typ darstellt. Jedes Ereignis wird an Clients gesendet, die Interesse an diesem Ereignistyp registriert haben.

Die Ereigniszustellung folgt der “Mindestens einmal”-Semantik. Das heißt, der Server kann dasselbe Ereignis mehr als einmal an einen Client senden. Diese Berechtigung ist erforderlich in Fällen, in denen der Server vorübergehend heruntergefahren wird, und wenn er wieder hochgefahren wird, nicht bestimmen kann, ob der Client die aktuellsten Informationen erhalten hat.

Inhalt einer SC_EVENT-Meldung

Die SC_EVENT-Meldung enthält die tatächliche Meldung, die innerhalb des Clusters generiert wird, so übersetzt, dass sie in das SC_EVENT-XML-Meldungsformat passt. Die folgende Tabelle beschreibt die vom CRNP zugestellten Ereignistypen, einschließlich der Namens- und Wertepaare, Herausgeber und Hersteller.


Hinweis –

Die Positionen der Array-Elemente für state_list sind mit denjenigen der node_list synchronisiert. Das heißt, der Zustand für den Knoten, der im node_list-Array zuerst aufgelistet ist, ist im state_list-Array auch zuerst aufgelistet.

Zusätzliche Namen, die mit ev_ beginnen, und deren zugeordnete Werte können vorhanden sein, sind aber nicht für die Verwendung durch den Client vorgesehen.


Klasse und Unterklasse 

Herausgeber und Hersteller 

Namens- und Wertepaare 

EC_Cluster

ESC_cluster_membership

Herausgeber: rgm 

Hersteller: SUNW 

Name: node_list

Werttyp: Zeichenketten-Array 

Name: state_list

Die state_list enthält nur Zahlen, die in ASCII dargestellt sind. Jede Ziffer stellt die aktuelle Zusammensetzungsnummer für diesen Knoten im Cluster dar. Wenn die Nummer die gleiche wie die in einer vorhergehenden Meldung erhaltene Nummer ist, hat sich die Beziehung des Knotens zum Cluster nicht geändert (gelöscht, beigetreten bzw. erneut beigetreten). Wenn die Zusammensetzungsnummer –1 ist, so ist der Knoten kein Cluster-Mitglied. Wenn die Zusammensetzungsnummer keine negative Zahl ist, handelt es sich beim Knoten um ein Cluster-Mitglied.

Werttyp: Zeichenketten-Array 

EC_Cluster

ESC_cluster_rg_state

Herausgeber: rgm 

Hersteller: SUNW 

Name: rg_name

Werttyp: Zeichenkette 

Name: node_list

Werttyp: Zeichenketten-Array 

Name: state_list

Die state_list enthält Zeichenkettendarstellungen des Zustands der Ressourcengruppe. Gültige Werte sind diejenigen, die Sie mit den Befehlen scha_cmds(1HA) abrufen können.

Werttyp: Zeichenketten-Array 

EC_Cluster

ESC_cluster_r_state

Herausgeber: rgm 

Hersteller: SUNW 

Name: r_name

Werttyp: Zeichenkette 

Name: node_list

Werttyp: Zeichenketten-Array 

Name: state_list

Die state_list enthält Zeichenkettendarstellungen des Zustands der Ressource. Gültige Werte sind diejenigen, die Sie mit den Befehlen scha_cmds(1HA) abrufen können.

Werttyp: Zeichenketten-Array