Escritura y comprobación de los servicios de datos

Esta sección proporciona información sobre la escritura y comprobación de los servicios de datos.

Utilización de keep-alives

En el lado del servidor, la utilización de keep-alives de TCP evita que el servidor malgaste recursos de sistema en un cliente inactivo (o con partición de red). Si estos recursos no se reorganizan (en un servidor que permanezca activo el tiempo suficiente), los recursos malgastados aumentan sin límite, a medida que los sistemas de los clientes se caen y rearrancan.

Si la comunicación cliente-servidor utiliza un canal TCP, tanto el cliente como el servidor 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 lado del cliente, la utilización de mecanismos keep-alive de TCP permite que el cliente reciba un aviso cuando se haya producido una recuperación de fallos o una conmutación de un recurso de dirección de red, desde un sistema 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 de TCP del cliente no necesita seguir transmitiendo la solicitud y se bloquea la aplicación del cliente, mientras se espera la respuesta.

Siempre que sea posible, además de utilizar el mecanismo keep-alive TCP, la aplicación del cliente debe realizar su propia acción periódica keep-alive en este nivel, porque el mecanismo keep-alive de TCP no es perfecto en todas las situaciones de limitación posibles. La utilización de un mecanismo keep-alive en una aplicación suele requerir que el protocolo cliente-servidor admita una operación nula, o al menos una operación eficiente de sólo lectura, como 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. Necesita acceso a una configuración de prueba de Sun Cluster para que el trabajo de comprobación no afecte a las máquinas de producción.

Compruebe que el servicio de datos de alta disponibilidad se comporte adecuadamente en todos los casos en los que un grupo de recursos se desplaza entre los sistemas físicos. 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

En ocasiones, el servicio de datos cliente-servidor realiza solicitudes a otro servicio de datos cliente-servidor mientras responde a una solicitud de un cliente. Informalmente, un servicio de datos A depende de un servicio de datos B si, 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 detalles.

Si los recursos de su tipo de recurso dependen de los recursos de otro tipo, tendrá que indicar al usuario que configure los recursos y grupos de recursos adecuadamente o proporcionar las secuencias o herramientas para configurarlos correctamente. Si el recurso dependiente debe ejecutarse en el mismo nodo que el recurso del que depende, ambos deben estar configurados en el mismo grupo de recursos.

Decida si se van a usar dependencias explícitas de recursos o si prefiere omitirlas y consultar la disponibilidad de otro(s) servicio(s) de datos en el código del servicio de datos de alta disponibilidad. 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, la consulta es necesaria, porque no es posible configurar dependencias de recursos entre varios grupos.

Algunos servicios de datos no almacenan ningún dato directamente, sino que dependen de otro servicio de datos de componente trasero para almacenar 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, supongamos un servicio de agenda de citas cliente-servidor hipotético que mantenga todos sus datos en una base de datos SQL, como 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. Después, puede escribir métodos simples para iniciar y detener el daemon de la agenda de citas. Su usuario final registra el tipo de recurso de agenda de citas en Sun Cluster.

Si la aplicación de agenda de citas se debe ejecutar en el mismo nodo que la base de datos Oracle, el usuario final configura el recurso de agenda de citas en el mismo grupo de recursos que el recurso HA-ORACLE y hace que el recurso de agenda de citas dependa de éste. Esta dependencia se especifica con la etiqueta de propiedad Resource_dependencies en scrgadm.

Si el recurso HA-ORACLE puede ejecutarse en un nodo diferente que el recurso de agenda de citas, el usuario final los configura en grupos de recursos separados. El usuario final puede configurar una dependencia de grupo de recursos del grupo de recursos de agenda en el grupo de recursos Oracle. Sin embargo, las dependencias de grupo de recursos sólo son eficaces cuando se inician o detienen ambos grupos de recursos en el mismo nodo simultáneamente. 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 normalmente devolverá un resultado satisfactorio en este caso, porque si el método Start estuviera bloqueado indefinidamente, pondría su grupo de recursos en un estado ocupado, que impediría que hubiera otros cambios de estado (como ediciones, recuperaciones de fallos o conmutaciones) en el grupo. Sin embargo, si el método Start del recurso de agenda agotara su tiempo de espera o devolviera un valor diferente de cero, podría hacer que el grupo de recursos pasara de uno a otro nodo, mientras la base de datos Oracle no estuviera disponible.