Conceptos sobre CRNP
CRNP define las capas de aplicación, presentación y sesión de la pila de protocolos de interconexión de sistemas abiertos (OSI, Open System Interconnect) estándar, compuesto por siete capas. La capa de transporte debe ser TCP y la de red debe ser IP. CRNP es independiente de las capas física y de enlace de datos. Todos los mensajes de capa de aplicación intercambiados en CRNP se basan en XML 1.0.
Funcionamiento de CRNP
CRNP proporciona mecanismos y daemons que generan eventos de reconfiguración del clúster, enrutan dichos eventos a través del clúster y los envían a los clientes interesados.
El daemon cl_apid interactúa con los clientes. El Gestor de grupos de recursos (RGM) de Sun Cluster genera eventos de reconfiguración del clúster. Este daemon utiliza syseventd para transmitir los eventos en cada nodo local. El daemon cl_apid utiliza un lenguaje de marcado extensible (XML, Extensible Markup Language) a través de TCP/IP para establecer comunicación con los clientes interesados.
El siguiente diagrama muestra el flujo de eventos entre los componentes de CRNP. En este diagrama, un cliente se está ejecutando en el nodo del clúster 2 y el otro en un ordenador que no forma parte del clúster.
Figura 12–1 Flujo de eventos entre componentes de CRNP
Semántica de CRNP
Los clientes establecen comunicación mediante el envío de un mensaje de registro (SC_CALLBACK_RG) al servidor. Este mensaje especifica los tipos de eventos sobre los cuales los clientes desean recibir notificaciones y el puerto al que se pueden enviar los eventos. La IP origen de la conexión de registro y el puerto especificado forman conjuntamente la dirección de retrollamada.
Siempre que se genera un evento que pueda interesar a un cliente en el clúster, el servidor se pone en contacto con el cliente en su dirección de rellamada (IP y puerto) y le envía el evento (SC_EVENT). El servidor tiene una alta disponibilidad y se ejecuta en el propio clúster. El servidor almacena los registros del cliente en un almacenamiento que se conserva incluso después de rearrancar el clúster.
Los clientes anulan sus registros mediante el envío de un mensaje de registro (SC_CALLBACK_RG que contiene un mensaje REMOVE_CLIENT) al servidor. Cuando el cliente recibe un mensaje SC_REPLY del servidor, cierra la conexión.
El siguiente diagrama muestra el flujo de comunicación entre un cliente y un servidor.
Figura 12–2 Flujo de comunicación entre un cliente y un servidor
Tipos de mensajes de CRNP
CRNP utiliza tres tipos de mensajes basados en XML. El uso de estos mensajes se describe en la siguiente tabla. Estos tipos de mensaje y su sintaxis se explican con más detalle
|
Tipo de mensaje de CRNP |
Descripción |
|---|---|
|
SC_CALLBACK_REG |
Este mensaje adopta cuatro formas: ADD_CLIENT, REMOVE_CLIENT , ADD_EVENTS y REMOVE_EVENTS. Cada una de ellas contiene la información siguiente:
ADD_CLIENT, ADD_EVENTS y REMOVE_EVENTS también contienen una lista ilimitada de tipos de eventos; cada uno de ellos incluye la siguiente información:
La clase y la subclase de evento definen conjuntamente un “tipo de evento” exclusivo. La definicion de tipo de documento (DTD) a partir de la que se generan las clases de SC_CALLBACK_REG es SC_CALLBACK_REG. Esta DTD se describe de forma más detallada en Apéndice F, Definiciones de tipos de documentos de CRNP. |
|
SC_REPLY |
Este mensaje contiene la información siguiente:
La DTD a partir de la que se generan las clases deSC_REPLY es SC_REPLY. Esta DTD se describe de forma más detallada en Apéndice F, Definiciones de tipos de documentos de CRNP. |
|
SC_EVENT |
Este mensaje contiene la información siguiente:
Los valores en SC_EVENT no tienen un tipo. La DTD a partir de la que se generan las clases deSC_EVENT es SC_EVENT. Esta DTD se describe de forma más detallada en Apéndice F, Definiciones de tipos de documentos de CRNP. |
- © 2010, Oracle Corporation and/or its affiliates