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

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.