Escritura y comprobación de los servicios de datos

Uso de mecanismos de mantenimiento de conexiones (Keep-alive) de TCP para proteger el servidor

En el servidor, el uso de mecanismos de mantenimiento de conexiones (keep-alive) impide que el servidor malgaste los recursos del sistema en caso de existir un cliente desactivado (o con partición en red). Si no se limpian los recursos de un servidor que ha permanecido activo durante un largo periodo, es posible que, con el tiempo, aumente el número de recursos malgastados de forma ilimitada a medida que los clientes se bloquean y reinician.

Si la comunicación entre el cliente y el servidor utiliza una secuencia TCP, ambos deberían habilitar el mecanismo keep-alive de TCP. Esta disposición se aplica incluso a los casos en los que no hay una alta disponibilidad y sólo hay un servidor.

Otros protocolos orientados a la conexión pueden disponer también de mecanismos keep-alive.

En el cliente, el uso de mecanismos keep-alive de TCP permite notificar al cliente cuándo se ha realizado una recuperación ante fallos o una conmutación por error del recurso de dirección de red de un host físico a otro. Esa transferencia del recurso de dirección de red interrumpe la conexión de TCP. Sin embargo, salvo que el cliente haya habilitado el mecanismo keep-alive, no siempre recibirá información de la interrupción de la conexión, si ésta parece inactiva en ese momento.

Por ejemplo, suponga que el cliente está esperando una respuesta del servidor a una solicitud que requiere mucho tiempo y que el mensaje de solicitud del cliente ha llegado ya al servidor y se ha reconocido en la capa de TCP. En esta situación, el módulo TCP del cliente no tiene que seguir transmitiendo la solicitud. Además, el cliente se encuentra bloqueado, esperando una respuesta a la solicitud.

Si es posible, además de utilizar el mecanismo keep-alive de TCP, el cliente de aplicación debe realizar su propio mecanismo de mantenimiento de conexión periódico en su nivel. El mecanismo keep-alive de TCP no es perfecto en todos posibles casos de limitaciones. Si se utiliza un mecanismo keep-alive en el nivel de la aplicación, será necesario generalmente que el protocolo de cliente-servidor admita una operación nula (null) o, al menos, una operación de sólo lectura eficaz como, por ejemplo, una operación de estado.

Comprobación de los servicios de datos de alta disponibilidad

Esta sección aporta sugerencias sobre cómo comprobar una implementación de un servicio de datos en un entorno de alta disponibilidad. Los ejemplos de comprobación son sólo sugerencias y no cubren todas las posibilidades. Debe acceder a una configuración de Sun Cluster compatible con las pruebas para que ésta no afecte a las máquinas de producción.

Compruebe que el servicio de datos de alta disponibilidad muestra un comportamiento correcto en todos los casos en los que el grupo de recursos se transfiera de un host físico a otro. Estos ejemplos incluyen caídas de sistemas y la utilización del comando scswitch. Compruebe que las máquinas clientes sigan recibiendo servicio tras estos acontecimientos.

Compruebe la idempotencia de los métodos. Por ejemplo, sustituya los métodos temporalmente con una secuencia breve de shell que llame al método original dos o más veces.

Coordinación de dependencias entre los recursos

A veces un servicio de datos de cliente-servidor realiza solicitudes en otro servicio a la vez que satisface una solicitud de un cliente. Por ejemplo, el servicio de datos A depende del servicio de datos B; para que A proporcione su servicio, B debe proporcionar el suyo. Sun Cluster facilita que esto se realice permitiendo que las dependencias de recursos se configuren dentro de un grupo de recursos. Las dependencias afectan al orden en el que Sun Cluster inicia y detiene los servicios de datos. Consulte la página de comando man scrgadm(1M) para obtener más información.

Si los recursos del tipo de recurso dependen de los recursos de otro tipo, debe indicar al administrador del clúster que configure correctamente los recursos y grupos de recursos. De forma alternativa, puede proporcionar secuencias de comandos o herramientas para configurarlos correctamente. Si el recurso dependiente debe ejecutarse en el mismo nodo que el recurso “del que depende”, ambos deben configurarse en el mismo grupo.

Decida si desea utilizar dependencias de recursos explícitas, u omitirlas y consultar la disponibilidad del otro servicio de datos en el código del servicio de datos HA. En caso de que el recurso dependiente y aquél del que depende se puedan ejecutar en nodos diferentes, configúrelos en grupos de recursos separados. En este caso, es necesario realizar la consulta, porque no se pueden configurar dependencias de recursos entre varios grupos.

Algunos servicios de datos no almacenan directamente los datos. En su lugar, dependen de un servicio de datos de fondo para almacenar todos sus datos. Este servicio de datos traduce todas las solicitudes de lectura y actualización a llamadas en el servicio de datos de componente trasero. Por ejemplo, imagine un hipotético servicio de agenda de citas de cliente-servidor que almacena todos sus datos en una base de datos de SQL como, por ejemplo, Oracle. El servicio de agenda de citas tiene su propio protocolo de red cliente-servidor. Por ejemplo, su protocolo se puede haber definido con un idioma de especificación RPC, como ONC RPC.

En el entorno de Sun Cluster, puede utilizar HA-ORACLE para que la base de datos Oracle de componente trasero tenga una alta disponibilidad. A continuación, puede escribir métodos sencillos para iniciar y detener el daemon de la agenda de citas. El administrador del clúster registra el tipo de recurso de agenda de citas con Sun Cluster.

Si la aplicación de agenda debe ejecutarse en el mismo nodo que la base de datos de Oracle, el administrador del clúster configura el recurso de la agenda de citas en el mismo grupo que el recurso HA-ORACLE y hace que el recurso de la agenda dependa del recurso HA-ORACLE. Esta dependencia se especifica con la etiqueta de propiedad Resource_dependencies de scrgadm.

Si el recurso HA-ORACLE puede ejecutarse en un nodo distinto al del recurso de la agenda, el administrador del clúster los configura en dos grupos independientes. Es posible que el administrador del clúster configure una dependencia para el grupo de recursos de agenda en el grupo de recursos de Oracle. Sin embargo, las dependencias de grupos de recursos se aplican únicamente cuando los grupos se inician o detienen en el mismo nodo al mismo tiempo. Por tanto, el daemon del servicio de datos de agenda, una vez iniciado, puede interrogar, esperando que la base de datos Oracle esté disponible. El método Start del tipo de recurso de agenda devuelve normalmente un mensaje satisfactorio en este caso. Aunque el método Start se bloquee indefinidamente, este método establece el estado de este grupo de recursos como ocupado. El estado ocupado impide que se realicen cambios adicionales en los estados como, por ejemplo, modificaciones, recuperaciones ante fallos o comutaciones en el grupo. Sin embargo, si se ha agotado el tiempo de espera del método Start del recurso de la agenda o si el método ha salido con un estado diferente a cero, es posible que uno de estos dos estados provoque que el recurso se transfiera constantemente entre dos o más nodos mientras que la base de datos de Oracle sigue sin estar disponible.