Sun Cluster: Guía del desarrollador de los servicios de datos del sistema operativo Solaris

Cómo se registra un cliente en un servidor

Esta sección describe cómo un administrador debe configurar el servidor, cómo se identifican los clientes, cómo se envía información por las capas de aplicación y sesión y las condiciones de error.

Supuestos sobre cómo los administradores configuran el servidor

El administrador del sistema debe configurar el servidor con una dirección IP de alta disponibilidad (es decir, una dirección IP que no esté vinculada a una máquina concreta del clúster) y un número de puerto. El administrador debe publicar esta dirección de red para los clientes potenciales. CRNP no define cómo se pone este nombre de servidor a disposición de los clientes. Los administradores deberán utilizar un servicio de nombres, que permitirá a los clientes buscar la dirección de red del servidor de forma dinámica, o agregarán el nombre de red a un archivo de configuración que podrá leer el cliente. El servidor se ejecutará dentro del clúster como un tipo de recurso a prueba de fallos.

Cómo identifica el servidor a un cliente

Cada cliente está identificado de forma exclusiva por una dirección de rellamada, es decir, su dirección IP y número de puerto. El puerto se especifica en los mensajes SC_CALLBACK_REG y la dirección IP se obtiene de la conexión de registro TCP. CRNP asume que los siguientes mensajes SC_CALLBACK_REG con la misma dirección de rellamada provienen del mismo cliente, aunque el puerto de origen desde el que se envíen los mensajes sea diferente.

Cómo se pasan los mensajes SC_CALLBACK_REG entre el cliente y el servidor

Un cliente inicia un registro, abriendo una conexión TCP con la dirección IP y el número de puerto del servidor. Una vez establecida la conexión TCP y lista para escribir, el cliente debe enviar su mensaje de registro. Éste debe ser un mensaje SC_CALLBACK_REG de formato correcto que no contenga bytes adicionales antes ni después del mensaje.

Una vez escritos todos los bytes en el canal, el cliente debe mantener la conexión abierta para recibir la respuesta del servidor. Si el cliente no le da el formato correcto al mensaje, el servidor no registrará el cliente y le enviará una respuesta de error. Si el cliente cierra la conexión de zócalo antes de que el servidor envíe una respuesta, éste registra el cliente como normal.

Un cliente puede ponerse en contacto con el servidor en cualquier momento. Cada vez que un cliente se pone en contacto con el servidor, el cliente debe enviar un mensaje SC_CALLBACK_REG. Si el servidor recibe un mensaje con formato erróneo, fuera de servicio o no válido, envía una respuesta de error al cliente.

Un cliente no puede enviar un mensaje ADD_EVENTS, REMOVE_EVENTS o REMOVE_CLIENT antes de enviar el mensaje ADD_CLIENT. Un cliente no puede enviar un mensaje REMOVE_CLIENT antes de haber enviado un mensaje ADD_CLIENT.

Si un cliente envía un mensaje ADD_CLIENT y el cliente ya está registrado, es posible que el servidor tolere el mensaje. En este caso, el servidor sustituye silenciosamente el registro anterior del cliente por el nuevo, especificado en el segundo mensaje ADD_CLIENT.

En la mayoría de los casos, un cliente se registra sólo una vez en el servidor, al comenzar, con un mensaje ADD_CLIENT. El cliente sólo cancela su registro una vez, enviando un mensaje REMOVE_CLIENT al servidor. Sin embargo, CRNP proporciona una mayor flexibilidad a aquellos clientes que tengan que modificar dinámicamente la lista de tipos de eventos.

Contenido de un mensaje SC_CALLBACK_REG

Cada mensaje ADD_CLIENT, ADD_EVENTS y REMOVE_EVENTS contiene una lista de eventos. La tabla siguiente describe los tipos de eventos que acepta CRNP, incluidos los valores requeridos de nombre y valor.

Si un cliente:

En ambos casos el servidor ignora discretamente estos mensajes.

Clase y subclase  

Pares nombre-valor 

Descripción  

EC_Cluster

ESC_cluster_membership

Necesario: ninguno 

Opcional: ninguno  

Registra todos los eventos de cambio en los miembros del clúster (terminación de nodo o unión) 

EC_Cluster

ESC_cluster_rg_state

Uno necesario, como sigue: 

rg_name

Tipo de valor: cadena 

Opcional: ninguno  

Registra todos los eventos de cambio de estado del grupo de recursos nombre

EC_Cluster

ESC_cluster_r_state

Uno necesario, como sigue: 

r_name

Tipo de valor: cadena 

Opcional: ninguno  

Registra todos los eventos de cambio de estado del recurso nombre

EC_Cluster

Ninguno 

Necesario: ninguno  

Opcional: ninguno 

Registra todos los eventos de Sun Cluster