Das CRNP definiert die Anwendungs-, Präsentations- und Sitzungsschichten des OSI-Standardprotokollstapels mit sieben Schichten. Die Transportschicht muss TCP sein und die Netzwerkschicht IP. Das CRNP ist von den Datenverbindungs- und realen Schichten unabhängig. Alle Meldungen der Anwendungsschicht, die im CRNP ausgetauscht werden, basieren auf XML 1.0.
Das CRNP bietet Mechanismen und Dämonen, die Cluster-Rekonfigurationsereignisse generieren, die Ereignisse über den Cluster weiterleiten und sie an interessierte Clients senden.
Der cl_apid-Dämon arbeitet interaktiv mit den Clients zusammen. Sun Cluster-Ressourcengruppen-Manager (RGM) generiert Cluster-Rekonfigurationsereignisse. Dieser Dämon verwendet syseventd, um die Ereignisse an jedem lokalen Knoten zu übertragen. Der cl_apid-Dämon verwendet Extensible Markup Language (XML) via TCP/IP für die Kommunikation mit interessierten Clients.
Im folgenden Diagramm wird der Fluss der Ereignisse zwischen den CRNP-Komponenten dargestellt. In diesem Diagramm wird ein Client auf Cluster-Knoten 2 ausgeführt, und der andere Client läuft auf einem Computer, der nicht zum Cluster gehört.
Die Clients initiieren die Kommunikation, indem eine Registrierungsmeldung (SC_CALLBACK_RG) an den Server gesendet wird. Diese Registrierungsmeldung gibt die Ereignistypen an, für die Clients Benachrichtigungen erhalten möchten, sowie den Port, an den die Ereignisse zugestellt werden können. Das Quell-IP der Registrierungsverbindung und der angegebene Port bilden zusammen die Rückmeldeadresse.
Immer wenn im Cluster ein Ereignis eintritt, das für den Client von Interesse ist, kontaktiert der Server den Client über die Rückmeldeadresse (IP und Port) und stellt dem Client das Ereignis (SC_EVENT) zu. Der Server ist hoch verfügbar und wird im Cluster selbst ausgeführt. Der Server speichert Clientregistrierungen in einem Speicher, der auch bei einem Neustart des Clusters nicht gelöscht wird.
Clients können sich deregistrieren, indem sie eine Registrierungsmeldung (SC_CALLBACK_RG mit einer REMOVE_CLIENT-Meldung) an den Server senden. Nachdem der Client eine SC_REPLY-Meldung vom Server erhalten hat, beendet er die Verbindung.
Im folgenden Diagramm wird der Kommunikationsfluss zwischen einem Client und einem Server dargestellt.
Das CRNP verwendet drei Typen von XML-basierten Meldungen. Die Verwendung dieser Meldungen wird in der folgenden Tabelle beschrieben. Weitere Einzelheiten zu diesen Meldungstypen werden weiter unten in diesem Kapitel beschrieben.
CRNP-Meldungstyp |
Beschreibung |
---|---|
SC_CALLBACK_REG |
Diese Meldung kann in vier Formen vorkommen: ADD_CLIENT, REMOVE_CLIENT , ADD_EVENTS und REMOVE_EVENTS. Jede dieser Formen enthält folgende Informationen:
ADD_CLIENT, ADD_EVENTS und REMOVE_EVENTS enthalten auch eine uneingeschränkte Liste mit Ereignistypen, von denen jeder die folgenden Informationen umfasst:
Die Ereignisklasse und die Ereignisunterklasse definieren zusammen einen einmaligen “Ereignistyp.” Die Dokumenttypdefinition (DTD, Document Type Definition), aus der die Klassen von SC_CALLBACK_REG generiert werden, lautet SC_CALLBACK_REG. Diese DTD wird detailliert in Anhang F, Dokumenttypdefinitionen für das CRNP beschrieben. |
SC_REPLY |
Diese Meldung enthält folgende Informationen:
Die DTD, aus der die Klassen von SC_REPLY generiert werden, lautet SC_REPLY. Diese DTD wird detailliert in Anhang F, Dokumenttypdefinitionen für das CRNP beschrieben. |
SC_EVENT |
Diese Meldung enthält folgende Informationen:
Die Werte in einem SC_EVENT werden nicht eingegeben. Die DTD, aus der die Klassen von SC_EVENT generiert werden, lautet SC_EVENT. Diese DTD wird detailliert in Anhang F, Dokumenttypdefinitionen für das CRNP beschrieben. |