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:
Abwarten einer vom Server hergestellten TCP-Verbindung,
Akzeptieren der eingehenden Verbindung vom Server,
Warten auf eine SC_EVENT-Meldung vom Server
Lesen einer SC_EVENT-Meldung vom Server
Erhalten einer Anzeige, dass der Server die Verbindung beendet hat (Lesen von 0 Bytes vom Socket),
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.
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.
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.
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 |