Présentation générale du protocole CRNP

Le protocole CRNP offre des mécanismes et des démons qui génèrent des événements de reconfiguration du cluster, les acheminent au sein du cluster et les transmettent aux clients intéressés.

Le démon cl_apid interagit avec les clients. Le gestionnaire de groupe de ressources (RGM) de Sun Cluster génère des événements de reconfiguration du cluster. Ces démons utilisent syseventd( 1M) pour transmettre les événements à chaque noeud local. Le démon cl_apid communique avec les clients intéressés via le protocole TCP/IP au moyen du langage XML (Extensible Markup Language).

Le diagramme suivant présente de façon générale le flux d'événements entre les composants CRNP : un client est exécuté sur le noeud 2 du cluster tandis que l'autre fonctionne sur un ordinateur n'appartenant pas au cluster.

Figure 12–1 Fonctionnement du protocole CRNP

Présentation générale du protocole CRNP

Le protocole CRNP définit les couches application, présentation et session de la pile de protocoles de communication OSI (Open System Interconnect/interconnexion de systèmes ouverts) standard constituée de sept couches. La couche transport doit utiliser le protocole TCP et la couche réseau le protocole IP. Le protocole CRNP est indépendant des couches liaison de données et physique. Tous les messages de la couche application échangés au moyen du protocole CRNP utilisent le langage XML 1.0.

Sémantique du protocole CRNP

Les clients initient des communications en envoyant un message de connexion (SC_CALLBACK_RG) au serveur. Ce message spécifie le type d'événements dont les clients souhaitent être notifiés, ainsi que le port auquel ces événements peuvent être transmis. L'IP source de la connexion d'enregistrement et le port spécifié constituent l'adresse de rappel.

Chaque fois qu'un événement susceptible d'intéresser un client est généré au sein du cluster, le serveur contacte le client sur son adresse de rappel (IP et port) et lui transmet l'événement (SC_EVENT). Le serveur est hautement disponible car il fonctionne sur le cluster lui-même. Il enregistre les connexions clients en mémoire et en conserve la trace même après la réinitialisation du cluster.

Les clients se déconnectent en envoyant un message de connexion (SC_CALLBACK_RG contenant un message REMOVE_CLIENT) au serveur. Lorsque ce dernier leur renvoie le message SC_REPLY, les clients ferment leur connexion.

Le diagramme suivant illustre le flux de communications entre un client et un serveur :

Figure 12–2 Flux de communications entre un client et un serveur