Guide du développeur de services de données Sun Cluster pour SE Solaris

Concepts du protocole CRNP

Le protocole CRNP définit les couches application, présentation et session de la pile de protocoles 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.

Fonctionnement du protocole CRNP

Le protocole CRNP propose des mécanismes et des démons qui génèrent des événements de reconfiguration de cluster, les acheminent via le 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, Resource Group Manager) de Sun Cluster génère des événements de reconfiguration de cluster. Ce démon utilise syseventd pour transmettre des événements à chaque noeud local. Le démon cl_apid communique avec les clients intéressés, via le protocole TCP/IP, en langage XML (Extensible Markup Language).

Le schéma suivant met en évidence 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 Flux d'événements entre les composants CRNP

Schéma illustrant le fonctionnement du protocole CRNP

Sémantique du protocole CRNP

Les clients débutent des communications en envoyant un message d'enregistrement (SC_CALLBACK_RG) au serveur. Ce message indique le type d'événements dont les clients souhaitent être avertis, 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 à 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 client en mémoire et en conserve la trace même après la réinitialisation du cluster.

Les clients annulent leur enregistrement en envoyant un message d'enregistrement (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 schéma suivant met en évidence le flux de communications entre un client et un serveur.

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

Organigramme présentant le flux de communications entre un client et un serveur

Types de messages utilisés par le protocole CRNP

Le protocole CRNP utilise trois types de messages XML. Leur utilisation est décrite dans le tableau suivant. Ces trois types de messages sont également décrits plus en détail dans ce chapitre.

Type de message utilisé par le protocole CRNP	Description
`SC_CALLBACK_REG`	Ce message se présente sous quatre formes : `ADD_CLIENT`, `REMOVE_CLIENT` , `ADD_EVENTS` et `REMOVE_EVENTS`. Elles contiennent toutes les informations suivantes : version du protocole ; port de rappel au format ASCII (et non au format binaire). `ADD_CLIENT`, `ADD_EVENTS` et `REMOVE_EVENTS` contiennent également une liste non bornée de types d'événements, comprenant chacun les informations suivantes : classe de l'événement ; sous-classe de l'événement (facultative) ; liste des paires nom/valeurs (facultative). La classe et la sous-classe d'événement définissent un “type d'événements” unique. La DTD (définition du type de document) qui permet de générer les classes de `SC_CALLBACK_REG` est `SC_CALLBACK_REG`. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP.
`SC_REPLY`	Ce message contient les informations suivantes : version du protocole ; code d'erreur ; message d'erreur. La DTD qui permet de générer les classes de `SC_REPLY` est `SC_REPLY`. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP.
`SC_EVENT`	Ce message contient les informations suivantes : version du protocole ; classe de l'événement ; sous-classe de l'événement ; fournisseur ; éditeur ; liste des paires nom/valeurs (0, 1 ou plusieurs structures de données de paires nom/valeurs) : nom (chaîne de caractères) ; valeur (chaîne de caractères ou tableau de chaînes de caractères). Les valeurs d'un message `SC_EVENT` ne sont pas typées. La DTD qui permet de générer les classes de `SC_EVENT` est `SC_EVENT`. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP.

Type de message utilisé par le protocole CRNP

Description

SC_CALLBACK_REG

Ce message se présente sous quatre formes : ADD_CLIENT, REMOVE_CLIENT , ADD_EVENTS et REMOVE_EVENTS. Elles contiennent toutes les informations suivantes :

version du protocole ;
port de rappel au format ASCII (et non au format binaire).

ADD_CLIENT, ADD_EVENTS et REMOVE_EVENTS contiennent également une liste non bornée de types d'événements, comprenant chacun les informations suivantes :

classe de l'événement ;
sous-classe de l'événement (facultative) ;
liste des paires nom/valeurs (facultative).

La classe et la sous-classe d'événement définissent un “type d'événements” unique. La DTD (définition du type de document) qui permet de générer les classes de SC_CALLBACK_REG est SC_CALLBACK_REG. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP.

SC_REPLY

Ce message contient les informations suivantes :

version du protocole ;
code d'erreur ;
message d'erreur.

La DTD qui permet de générer les classes de SC_REPLY est SC_REPLY. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP.

SC_EVENT

Ce message contient les informations suivantes :

version du protocole ;
classe de l'événement ;
sous-classe de l'événement ;
fournisseur ;
éditeur ;
liste des paires nom/valeurs (0, 1 ou plusieurs structures de données de paires nom/valeurs) :
- nom (chaîne de caractères) ;
- valeur (chaîne de caractères ou tableau de chaînes de caractères).

Les valeurs d'un message SC_EVENT ne sont pas typées. La DTD qui permet de générer les classes de SC_EVENT est SC_EVENT. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP.