Información general sobre CRNP

CRNP proporciona mecanismos y daemons que generan eventos de reconfiguración del clúster, los encamina a través del clúster y los envía 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. Estos daemons utilizan syseventd(1M) para transmitir eventos en todos los nodos locales. El daemon cl_apid utiliza Lenguaje de marcas extensible (XML) en TCP/IP para comunicarse con los clientes interesados.

El diagrama siguiente presenta información general sobre 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 Cómo funciona CRNP

Información general sobre el protocolo de CRNP

CRNP define las capas de aplicación, presentación y sesión de la pila estándar del protocolo de interconexión de sistema abierto (OSI) de siete capas. La capa de transporte debe ser TCP y la de red, 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.

Semántica del protocolo de CRNP

Los clientes inician una comunicación mediante el envío de un mensaje de registro (SC_CALLBACK_RG) que especifica los tipos de evento para los que los clientes quieren recibir notificaciones, así como un puerto al cual pueden entregarse 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 diagrama siguiente 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