Überblick über CRNP

CRNP stellt Mechanismen und Dämonen bereit, die Cluster-Rekonfigurationsereignisse generieren, diese durch den Cluster routen 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. Diese Dämone verwenden syseventd( 1M), um Ereignisse an jeden lokalen Knoten zu übertragen. Der cl_apid-Dämon verwendet XML (Extensible Markup Language) über TCP/IP, um mit den interessierten Clients zu kommunizieren.

Das folgende Diagramm stellt einen Überblick über den Ereignisfluss zwischen den CRNP-Komponenten dar. 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.

Abbildung 12–1 Funktionsweise des CRNP

Überblick über das CRNP-Protokoll

CRNP definiert die Anwendungs-, Darstellungs und Sitzungsschichten des standardmäßigen OSI-Protokollstapels mit sieben Ebenen (OSI, Open System Interconnect). Die Transportschicht muss TCP und die Netzwerkebene muss IP sein. 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.

Semantik des CRNP-Protokolls

Die Clients leiten die Kommunikation ein, indem sie eine Registrierungsmeldung (SC_CALLBACK_RG) an den Server senden. Diese Registrierungsmeldung gibt die Ereignistypen an, über welche die Clients benachrichtigt werden möchten, sowie den Port, an den die Ereignisse gesendet werden. 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.

Das folgende Diagramm zeigt den Kommunikationsfluss zwischen einem Client und einem Server.

Abbildung 12–2 Kommunikationsfluss zwischen einem Client und einem Server