test

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

Capítulo 2 Desarrollo de un servicio de datos

Este capítulo proporciona información detallada sobre cómo desarrollar un servicio de datos.

En este capítulo se tratan los temas siguientes:

Análisis de la validez de la aplicación

El primer paso en la creación de un servicio de datos es determinar si la aplicación de destino satisface los requisitos para poder tener una alta disponibilidad y escalabilidad. Si la aplicación no cumple todos los requisitos, es posible que se pueda modificar el código fuente de la aplicación para que los cumpla.

La siguiente lista resume los requisitos que debe cumplir una aplicación para poder tener una alta disponibilidad y escalabilidad. Si necesita más detalles o tiene que modificar el código fuente de la aplicación, consulte el Apéndice B, Listados del código del servicio de datos de ejemplo.

Nota –

Un servicio escalable debe cumplir todas las condiciones que se indican a continuación para ofrecer una alta disponibilidad, además de ciertos criterios adicionales.

Además, los servicios escalables deben cumplir los requisitos siguientes.

Para un servicio escalable, las características de la aplicación determinan también la política de equilibrio de cargas. Por ejemplo, la política de equilibrio de cargas LB_WEIGHTED, que permite que cualquier instancia responda a las solicitudes del cliente, no funciona para una aplicación que utilice una memoria caché integrada en el servidor para las conexiones de cliente. En este caso, se debe especificar una política de equilibrio de cargas que restrinja el tráfico de un cliente determinado a una instancia de la aplicación. Las políticas de equilibrio de cargas LB_STICKY y LB_STICKY_WILD envían repetidamente todas las solicitudes de un cliente a la misma instancia de la aplicación, siempre que puedan utilizar una memoria caché integrada. Tenga presente que si hay múltiples solicitudes de cliente, provenientes de clientes distintos, RGM distribuye las solicitudes entre las instancias del servicio. Consulte Implementación de un recurso a prueba de fallos para obtener más información sobre el establecimiento de la política de equilibrio de cargas de los servicios de datos escalables.

Elección de la interfaz

El paquete de soporte del desarrollador de Sun Cluster (SUNWscdev) proporciona dos conjuntos de interfaces de codificación de los métodos de los servicios de datos:

El paquete de soporte del desarrollador de Sun Cluster incluye también SunPlex Agent Builder, una herramienta que automatiza la creación de un servicio de datos.

El enfoque recomendado para desarrollar un servicio de datos es:

  1. Decidir si se va a codificar con el shell C o el Korn. Si opta por el shell Korn, no podrá utilizar la DSDL, que proporciona sólo una interfaz para C.

  2. Ejecutar Agent Builder, especificar las entradas solicitadas y generar un servicio de datos, que incluya código fuente y ejecutable, un archivo RTR y un paquete.

  3. Si el servicio de datos generado requiere personalización, puede agregar código de DSDL a los archivos fuente generados. Agent Builder indica, con comentarios, los lugares específicos, dentro de los archivos fuente, en los que se puede agregar un código propio.

  4. Si el código requiere una personalización avanzada para admitir la aplicación objetivo, puede agregar funciones de RMAPI al código fuente.

En la práctica, es posible adoptar diferentes enfoques para crear un servicio de datos. Por ejemplo, en lugar de agregar un código propio en los puntos específicos del código generado por Agent Builder, puede sustituir completamente uno de los métodos generados o el programa de supervisión generado por un programa que se haya escrito desde cero con las funciones DSDL o RMAPI. Sin embargo, al margen de la opción elegida, prácticamente en cualquier caso es práctico utilizar Agent Builder, por las razones siguientes:

Nota –

A diferencia de RMAPI, que proporciona un conjunto de funciones C y un conjunto de comandos para utilizar en secuencias, DSDL proporciona sólo una interfaz de función C. Por tanto, si especifica una salida del shell Korn (ksh) en Agent Builder, el código fuente generado realiza llamadas a RMAPI, porque no hay órdenes ksh de DSDL.

Configuración del entorno de desarrollo para escribir un servicio de datos

Antes de empezar el desarrollo de un servicio de datos, debe tener instalado el paquete de desarrollo de Sun Cluster (SUNWscdev) para tener acceso a los archivos de biblioteca y cabecera de Sun Cluster. Aunque este paquete ya está instalado en todos los nodos del clúster, generalmente se realiza el desarrollo en una máquina separada, de desarrollo sin clúster, no en un nodo del clúster. En ese caso, debe utilizar pkgadd para instalar el paquete SUNWscdev en la máquina de desarrollo.

Cuando compile y vincule el código, deberá establecer opciones concretas para identificar los archivos de cabecera y biblioteca.

Nota –

No se puede mezclar código C++ compilado con modo de compatibilidad con codigo C++ compilado con modo estándar en el sistema operativo Solaris y los productos de Sun Cluster. En consecuencia, si pretende crear un servicio de datos basado en C++ para usarlo con Sun Cluster, deberá compilar el servicio de datos de esta forma:

Una vez finalizado el desarrollo (en un nodo sin clúster), puede transferir el servicio de datos terminado a un clúster, para ejecutarlo y comprobarlo.

Nota –

Asegúrese de que está usando el desarrollador o el grupo de software de distribución completo de Solaris 5.8 o una versión posterior del sistema operativo de Solaris.

Utilice los procedimientos de esta sección para:

Configuración del entorno de desarrollo

Este procedimiento explica cómo instalar el paquete SUNWscdev y establecer las opciones de compilación y vinculación para el desarrollo del servicio de datos.

  1. Conviértase en superusuario o asuma un papel equivalente y cambie el directorio al directorio del CD-ROM que desee. 


    # cd directorio_CD-ROM

  2. Instale el paquete SUNWscdev en el directorio actual. 


    # pkgadd -d . SUNWscdev

  3. En Makefile, especifique las opciones de compilación y vinculación que identifican los archivos de biblioteca e inclusión del código del servicio de datos.

    Especifique las opciones -I, para identificar los archivos de cabecera de Sun Cluster, -L, para especificar la ruta de búsqueda de la biblioteca de tiempo de compilación en el sistema de desarrollo, y -R, para especificar la ruta de búsqueda de biblioteca del enlazador del tiempo de ejecución del clúster. 

    # Makefile para un servicio de datos de ejemplo
... 

-I /usr/cluster/include

-L /usr/cluster/lib

-R /usr/cluster/lib
...

Transferencia de un servicio de datos a un clúster

Cuando haya terminado el desarrollo de un servicio de datos en una máquina de desarrollo, debe transferirlo a un clúster para realizar comprobaciones. Para reducir las posibilidades de error, la mejor forma de realizar la transferencia es empaquetar el código del servicio de datos con el archivo RTR e instalar el paquete en todos los nodos del clúster.

Nota –

Tanto si usa pkgadd como cualquier otro método para instalar el servicio de datos, deberá poner el servicio de datos en todos los nodos de clúster. Agent Builder empaqueta automáticamente juntos el archivo RTR y el código del servicio de datos.

Establecimiento del recurso y las propiedades del tipo de recurso

Sun Cluster proporciona un conjunto de propiedades de tipo de recurso y de recurso que se utilizan para definir la configuración estática de un servicio de datos. Las propiedades de tipo de recurso especifican el tipo de recurso y su versión, la versión de la API, etc., así como las rutas a cada uno de los métodos de rellamada. Propiedades del tipo de recurso enumera todas las propiedades de los tipos de recursos.

Las propiedades de recurso, como Failover_mode, Thorough_probe_interval y los tiempos de espera del método definen también la configuración estática del recurso. Las propiedades dinámicas del recurso, como Resource_state y Status, reflejan el estado activo de un recurso gestionado. Propiedades de recurso describe las propiedades del recurso.

Las propiedades del recurso y del tipo de recurso se declaran en el archivo de registro del tipo de recurso (RTR), que es un componente esencial del servicio de datos y que define la configuración inicial del servicio de datos en el momento en que el administrador del clúster registra el servicio de datos en Sun Cluster.

Se recomienda utilizar Agent Builder para generar el archivo RTR para el servicio de datos porque Agent Builder declara un conjunto de propiedades útiles y necesarias para cualquier servicio de datos. Por ejemplo, algunas propiedades (como Resource_type) se deben declarar en el archivo RTR si se quiere que el registro del servicio de datos resulte satisfactorio. Otras propiedades, aunque no sean necesarias, no estarán disponibles para el administrador del sistema si no se declaran en el archivo RTR; otras propiedades estarán disponibles, tanto si se declaran como si no, porque RGM las define y proporciona un valor predeterminado. Para evitar este nivel de complejidad, puede utilizar Agent Builder sencillamente para garantizar la creación de un archivo RTR adecuado que, más tarde, podrá editar para cambiar algún valor concreto, si fuera necesario.

En el resto de esta sección se muestra el desarrollo de un archivo RTR de ejemplo, creado por Agent Builder.

Declaración de las propiedades del tipo de recurso

El administrador del clúster no puede configurar las propiedades del tipo de recurso que el usuario declare en el archivo RTR, ya que forman parte de la configuración permanente del tipo de recurso.

Nota –

Hay una propiedad del tipo de recurso, Installed_nodes, que el administrador del sistema puede configurar. De hecho, sólo la puede configurar éste, y no es posible declararla en el archivo RTR.

La sintaxis de las declaraciones del tipo de recurso es: 


nombre_propiedad = valor;
Nota –

RGM no diferencia entre mayúsculas y minúsculas en los nombres de las propiedades. La convención para las propiedades en los archivos RTR suministrados por Sun, salvo los nombres de métodos, es la utilización de mayúscula en el inicio del nombre y minúscula en el resto. Los nombres de métodos (y los atributos de las propiedades) contienen sólo mayúsculas.

A continuación figuran las declaraciones de tipo de recurso del archivo RTR de un servicio de datos de ejemplo (smpl): 

# Plantilla de Sun Cluster Data Services Builder versión 1.0
# Información de registro y recursos para ejemplo
#
#NOTA: las palabras clave no diferencian mayúsculas y minúsculas;
#éstas se pueden usar indistintamente.
#
Resource_type = "smpl";
Vendor_id = SUNW;
RT_description = "Servicio de ejemplo de Sun Cluster";
RT_version ="1.0"; 
API_version = 2;
Failover = TRUE;

Init_nodes = RG_PRIMARIES;

RT_basedir=/opt/SUNWsmpl/bin;

Start           =    smpl_svc_start;
Stop            =    smpl_svc_stop;

Validate        =    smpl_validate;
Update          =    smpl_update;

Monitor_start   =    smpl_monitor_start;
Monitor_stop    =    smpl_monitor_stop;
Monitor_check   =    smpl_monitor_check;
Consejo –

Debe declarar la propiedad Resource_type como la primera entrada del archivo RTR, de lo contrario, el registro del tipo de recurso no será satisfactorio.

El primer conjunto de declaraciones del tipo de recurso proporciona información básica sobre el tipo de recurso, como se indica a continuación:

Resource_type y Vendor_id

Indique un nombre para el tipo de recurso. Puede especificarlo sólo con la propiedad Resource_type (smpl) o con Vendor_id como un prefijo con un “.” que lo separe del tipo de recurso (SUNW.smpl), como en el ejemplo. Si utiliza Vendor_id, use el símbolo bursátil de la empresa que define el tipo de recurso. El nombre de éste debe ser exclusivo, dentro del clúster.

Nota –

Por convención el nombre del tipo de recurso (Resource_typeVendor_id) se usa como nombre del paquete. Los nombres de los paquetes están limitados a nueve caracteres, por lo que se recomienda limitar el número total de caracteres en estas dos propiedades a nueve caracteres o menos, aunque RGM no imponga este límite. Agent Builder, por el contrario, genera explícitamente el nombre del paquete a partir del nombre del tipo de recurso, por lo que aplica el límite de nueve caracteres.

RT_version

Identifica la versión del servicio de datos de ejemplo.

API_version

Identifica la versión de la API. Por ejemplo, API_version = 2, indica que el servicio de datos se ejecuta en Sun Cluster, versión 3.0.

Failover = TRUE

Indica que el servicio de datos no se puede ejecutar en un grupo de recursos que pueda estar en línea en varios nodos al mismo tiempo, es decir, especifica un servicio de datos a prueba de fallos. Consulte Transferencia de un servicio de datos a un clúster para obtener más información.

Start, Stop, Validate, etc.

Proporciona las rutas a los programas de métodos de rellamada correspondientes llamados por RGM. Estas rutas son relativas al directorio que especifica RT_basedir.

Las restantes declaraciones del tipo de recurso proporcionan información de configuración:

Init_nodes = RG_PRIMARIES

Especifica que RGM llama a los métodos Init, Boot, Fini y Validate sólo en los nodos que pueden controlar el servicio de datos. Los nodos especificados por RG_PRIMARIES son un subconjunto de todos los nodos en los que está instalado el servicio de datos. Establezca el valor en RT_INSTALLED_NODES para especificar que RGM llame a estos métodos en todos los nodos en los que está instalado el servicio de datos.

RT_basedir

Apunta a /opt/SUNWsmpl/bin como la ruta del directorio para completar las rutas relativas, como las rutas de los métodos de rellamada.

Start, Stop, Validate, etc.

Proporciona las rutas a los programas de métodos de rellamada correspondientes llamados por RGM. Estas rutas son relativas al directorio que especifica RT_basedir.

Declaración de las propiedades del recurso

Al igual que las propiedades del tipo de recursos, las del recurso se declaran en el archivo RTR. Por convención, las declaraciones de las propiedades del recurso van después de las del tipo de recurso en el archivo RTR. La sintaxis de las declaraciones de los recursos es un conjunto de pares de valores de atributos entre llaves:


{
    Atributo = Valor;
    Atributo = Valor;
             .
             .
             .
    Atributo = Valor;
}

Para las propiedades del recurso proporcionadas por Sun Clúster, denominadas propiedades definidas por el sistema, es posible modificar determinados atributos en el archivo RTR. Por ejemplo, Sun Cluster proporciona propiedades de tiempo de espera del método para cada uno de los métodos de rellamada y especifica valores predeterminados. En el archivo RTR se pueden especificar valores predeterminados diferentes.

También se pueden definir nuevas propiedades de recursos en el archivo RTR, denominadas propiedades de extensión, con un conjunto de atributos de propiedades suministrado por Sun Cluster. Atributos de las propiedades de recursos enumera los atributos para cambiar y definir las propiedades de los recursos. Las declaraciones de las propiedades de extensión van después de las declaraciones de propiedades definidas por el sistema en el archivo RTR.

El primer conjunto de propiedades de los recursos definidas por el sistema especifica los valores de tiempo de espera de los métodos de rellamada: 

...

# Las declaraciones de propiedades de los recursos aparecen como una lista de
# entradas entre llaves después de las declaraciones del tipo de recurso.
# La declaración del nombre de la propiedad debe ser el primer atributo
# después de la llave de apertura de una entrada de propiedad del recurso.
#
# Establezca el valor mínimo y predeterminado de los tiempos de espera
# de los métodos.
{
        PROPERTY = Start_timeout;
        MIN=60;
        DEFAULT=300;
}

{
        PROPERTY = Stop_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Validate_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Update_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Start_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Stop_timeout;
        MIN=60;
        DEFAULT=300;
{
        PROPERTY = Monitor_Check_timeout;
        MIN=60;
        DEFAULT=300;
}

El nombre de la propiedad (PROPERTY = valor) debe ser el primer atributo para cada declaración de propiedad del recurso. Las propiedades del recurso se pueden configurar, dentro de los límites que definen los atributos de propiedad del archivo RTR. Por ejemplo, el valor predeterminado para cada tiempo de espera del método del ejemplo es 300 segundos. Un administrador puede cambiar este valor; sin embargo, el valor mínimo permitido, especificado con el atributo MIN, es 60 segundos. Atributos de las propiedades de recursos contiene una lista de atributos de propiedad de los recursos.

El siguiente conjunto de propiedades del recurso define las propiedades que tienen usos específicos en el servicio de datos. 

{
        PROPERTY = Failover_mode;
        DEFAULT=SOFT;
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Thorough_Probe_Interval;
        MIN=1;
        MAX=3600;
        DEFAULT=60;
        TUNABLE = ANYTIME;
}

# El número de reintentos que se debe realizar en un periodo determinado antes de
# concluir que no se puede iniciar correctamente la aplicación en este nodo.
{
        PROPERTY = Retry_Count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME; 
}

# Establezca Retry_Interval como un múltiplo de 60, ya que se convierte de segundos
# a minutos, redondeando hacia arriba. Por ejemplo, un valor de 50 (segundos)
# se convierte en 1 minuto. Utilice esta propiedad para cronometrar el número de
# reintentos (Retry_Count).
{
        PROPERTY = Retry_Interval;
        MAX=3600;
        DEFAULT=300;
        TUNABLE = ANYTIME;
}

{
        PROPERTY = Network_resources_used;
        TUNABLE = WHEN_DISABLED;
        DEFAULT = "";
}
{
        PROPERTY = Scalable;
        DEFAULT = FALSE;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_policy;
        DEFAULT = LB_WEIGHTED;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_weights;
        DEFAULT = "";
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Port_list;
        TUNABLE = AT_CREATION;
        DEFAULT = ;
}

Estas declaraciones de propiedades de los recursos agregan el atributo TUNABLE, que limita las ocasiones en las que el administrador del sistema puede cambiar sus valores. AT_CREATION significa que el administrador sólo puede especificar el valor cuando el recurso se crea y que no lo puede cambiar más tarde.

Para la mayoría de las propiedades puede aceptar los valores predeterminados como Agent Builder los genera, salvo que tenga algún motivo para cambiarlos. A continuación se incluye información sobre estas propiedades (para obtener información adicional, consulte Propiedades de recurso o la página de comando man r_properties(5)):

Failover_mode

Indica si RGM debería reubicar el grupo de recursos o abortar el nodo en caso de un fallo de un método Start o Stop.

Thorough_probe_interval, Retry_count, Retry_interval

Utilizado en el supervisor de fallos. Tunable es igual que ANYTIME, por lo que un administrador de sistema puede ajustarlos si la supervisión de fallos no está funcionando correctamente.

Network_resources_used

Una lista de recursos de dirección compartida o nombre lógico de sistema utilizados por el servicio de datos. Agent Builder declara esta propiedad para que un administrador del sistema pueda especificar una lista de recursos, si los hubiera, al configurar el servicio de datos.

Scalable

Se fija en FALSE para indicar que este recurso no utiliza el recurso de conexión a red de clúster (dirección compartida). Esta configuración cuadra con la propiedad del tipo de recurso Failover fijada en TRUE, para indicar un servicio a prueba de fallos. Consulte Transferencia de un servicio de datos a un clúster y Implementación de los métodos de rellamada para obtener información adicional sobre cómo utilizar esta propiedad.

Load_balancing_policy, Load_balancing_weights

Declara automáticamente estas propiedades; sin embargo, no tienen ninguna función en un tipo de recurso a prueba de fallos.

Port_list

Identifica la lista de puertos en los que recibe el servidor. Agent Builder declara esta propiedad para que un administrador del sistema pueda especificar una lista de puertos al configurar el servicio de datos.

Declaración de las propiedades de extensión

Al final del archivo RTR de ejemplo hay propiedades de extensión, como muestra el listado siguiente 

# Propiedades de extensión
#

# El administrador del clúster debe establecer el valor de esta propiedad para que apunte
# al directorio que contiene los archivos de configuración que utiliza la aplicación.
# Para esta aplicación, smpl, especifique la ruta del archivo de configuración de
# PXFS (generalmente, named.conf).
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "La ruta del directorio de configuración";
}

# Estas dos propiedades controlan el inicio del supervisor de fallos..
{
        PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Número de reinicios PMF permitidos para el supervisor de fallos";
}
{
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "TVentana de tiempo (minutos) para reinicios del supervisor";
}
# Valor de tiempo de espera para el análisis en segundos.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Valor de tiempo de espera para el análisis (segundos)";
}

# Nivel de supervisión de procesos subordinados para PMF (opción -C de pmfadm).
# Default = -1 significa que no se usará la opción -C de pmfadm.
# Un valor 0 o mayor indica el nivel deseado de supervisión del
# proceso subordinado.
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Nivel de supervisión de subordinados para PMF";
}
# Código añadido por el usuario -- BEGIN VVVVVVVVVVVV
# Código añadido por el usuario -- END   ^^^^^^^^^^^^

Agent Builder crea algunas propiedades de extensión, útiles para la mayoría de los servicios de datos:

Confdir_list

Especifica la ruta al directorio de configuración de la aplicación, que es una información útil para muchas aplicaciones. El administrador del sistema puede indicar la ubicación de este directorio al configurar el servicio de datos.

Monitor_retry_count, Monitor_retry_interval , Probe_timeout

Controla los reinicios del supervisor de fallos, no del daemon de servidor.

Child_mon_level

Fija el nivel de supervisión que debe ejercer PMF. Consulte pmfadm(1M) para obtener más información.

Puede crear propiedades de extensión adicionales en la zona delimitada por los comentarios del código añadido por el usuario.

Implementación de los métodos de rellamada

Esta sección proporciona información relativa a la implantación de los métodos de rellamada en general.

Acceso a la información de las propiedades de los recursos y grupos de recursos

Generalmente, los métodos de rellamada requieren acceso a las propiedades del recurso. RMAPI proporciona comandos de shell y funciones de C que se pueden usar en métodos de rellamada para acceder a las propiedades de los recursos, tanto las de extensión como las definidas por el sistema. Consulte las páginas de comando man scha_resource_get(1HA) y scha_resource_get(3HA).

DSDL proporciona un conjunto de funciones de C (una para cada propiedad) para acceder a propiedades definidas por el sistema y una función para acceder a las propiedades de extensión. Consulte las páginas de comando man scds_property_functions(3HA) y scds_get_ext_property(3HA).

No se puede utilizar el mecanismo de propiedad para almacenar información de estado dinámico para un servicio de datos porque no hay funciones de API disponibles para establecer las propiedades de recursos (aparte de para establecer Status y Status_msg). En su lugar, se debe almacenar la información de estado dinámico en los archivos globales.

Nota –

El administrador del clúster puede establecer determinadas propiedades de recurso con la orden scrgadm o, si los tiene disponibles, con una orden o una interfaz administrativas gráficas. Sin embargo, no invoque scrgadm desde ningún método de rellamada porque scrgadm falla durante la reconfiguración de clúster, es decir, cuando RGM invoca el método.

Idempotencia de métodos

En general, RGM no llama a un método más de una vez seguida en el mismo recurso y con los mismos argumentos. Sin embargo, si un método Start falla, RGM podría llamar a un método Stop en un recurso, aunque éste no se haya iniciado nunca. Del mismo modo, un daemon de recurso podría terminarse de forma autónoma y RGM podría aún invocar su método Stop en él. Lo mismo se aplica a los métodos Monitor_start y Monitor_stop.

Por esta causa, se debe aplicar la idempotencia a los métodos Stop y Monitor_stop. Repetidas llamadas de Stop o Monitor_stop en el mismo recurso con los mismos parámetros logran los mismos resultados que una sola llamada.

Una implicación de la idempotencia es que Stop y Monitor_stop debe devolver 0 (satisfactorio) aunque el recurso o supervisor ya esté detenido y no haya ninguna tarea que realizar.

Nota –

Los métodos Init, Fini, Boot y Update debe ser también idempotentes. No es necesario que lo sea el método Start.

Servicio genérico de datos

Un servicio genérico de datos (GDS) es un mecanismo para hacer que las aplicaciones simples tengan una alta disponibilidad o escalabilidad, cuando se conectan al marco del gestor de grupos de recursos de Sun Cluster. Este mecanismo no requiere codificación de un agente, que es el método habitual para dotar una aplicación de alta disponibilidad y escalabilidad.

El modelo GDS se basa en un tipo de recurso compilado previamente, SUNW.gds, para interactuar con el marco de RGM

Consulte el Capítulo 10, Servicio de datos genérico para obtener información adicional.

Control de una aplicación

Los métodos de rellamada permiten que RGM controle el recurso subyacente (aplicación) cuando los nodos estén uniéndose o separándose del clúster.

Inicio y parada de un recurso

Una implementación de un tipo de recurso requiere, como mínimo, un método Start y un método Stop. RGM invoca programas del método del tipo de recurso en los momentos pertinentes y en los nodos adecuados para poner los grupos de recursos en línea y fuera de línea. Por ejemplo, tras la caída de un nodo del clúster, RGM mueve todos los nodos que ese nodo controla a uno nuevo. Debe implementar un método Start para que RGM pueda reiniciar cada recurso en el nodo principal superviviente.

No se debe devolver un método Start hasta que se haya iniciado el recurso y esté disponible en el nodo local. Asegúrese de que en los métodos Start se haya especificado un tiempo suficiente para los tipos de recursos que requieren un periodo de inicialización prolongado (establezca los valores predeterminado y mínimo para la propiedad Start_timeout en el archivo de registro de tipo de recurso).

Debe implementar un método Stop para situaciones en las que RGM ponga un grupo de recursos fuera de línea. Por ejemplo, suponga que un grupo de recursos se pone fuera de línea en el Nodo1 y se pone en línea en el Nodo2. Mientras pone el grupo de recursos fuera de línea, RGM llama al método Stop para que los recursos del grupo detengan todas sus actividades en el Nodo1. Después de que los métodos Stop de todos los recursos se hayan terminado en el Nodo1, RGM vuelve a poner en línea el grupo de recursos en el Nodo2.

Un método Stop no se debe devolver hasta que el recurso haya detenido por completo toda su actividad en el nodo local y se haya apagado totalmente. La manera más segura de implementar un método Stop es dar tiempo a que todos los procesos del nodo local relacionados con el recurso se completen. Para los que requieren mucho tiempo para apagarse se debería establecer un tiempo de espera suficientemente prolongado en su método Stop. Establezca la propiedad Stop_timeout en el archivo de registro del tipo de recurso.

Cuando un método Stop no es satisfactorio o su tiempo de espera se agota, el grupo de recursos entra en un estado de error que requiere la intervención del operador. Para evitar esto, las implementaciones de los métodos Stop y Monitor_stop deberían intentar la recuperación de cualquier condición de error posible. Idealmente, estos métodos deberían salir con un estado de error 0 (satisfactorio), una vez que se haya detenido satisfactoriamente toda la actividad del recurso y su supervisor en el nodo local.

Elección de los métodos Start y Stop que se van a utilizar

Esta sección ofrece algunos consejos sobre cuándo se deben utilizar los métodos Start y Stop en lugar de los métodos Prenet_start y Postnet_stop. Debe conocer perfectamente el protocolo de conexión de red de cliente-servidor del servicio de datos y del cliente para decidir qué métodos se deben emplear.

Es posible que los servicios que utilizan recursos de dirección de red necesiten que se realicen las operaciones de inicio o parada en un orden determinado, dependiendo de la configuración de dirección de nombre lógico de servidor. Los métodos de rellamada opcionales Prenet_start y Postnet_stop permiten que la implementación de un tipo de recurso realice acciones especiales de encendido y apagado antes y después de asignar o desasignar las direcciones de red del mismo grupo de recursos.

RGM invoca métodos para conectar (pero no configurar) las direcciones de red antes de invocar el método Prenet_start de los servicios de datos. RGM invoca métodos para desconectar las direcciones de red, después de invocar los métodos Postnet_stop de los servicios de datos. RGM pone un grupo de recursos en línea con la siguiente secuencia de acciones:

  1. Conectar direcciones de red.

  2. Invocar el método Prenet_start de los servicios de datos (si lo hubiera).

  3. Configurar las direcciones de red que activar.

  4. Invocar el método Start de los servicios de datos (si lo hubiera).

El proceso para poner un recurso fuera de línea es el contrario:

  1. Invocar el método Stop del servicio de datos (si lo hubiera).

  2. Configurar las direcciones de red que desactivar.

  3. Invocar el método Postnet_stop de los servicios de datos (si lo hubiera).

  4. Desconectar las direcciones de red.

En el proceso de decidir cuál de los métodos Start, Stop, Prenet_start o Postnet_stop se va a usar, se ha de tener en cuenta primero el lado del servidor. Cuando se pone en línea un grupo de recursos que contiene recursos de aplicación del servicio de datos y de dirección de red, RGM invoca métodos para configurar las direcciones de red que activar antes de llamar a los métodos Start del recurso del servicio de datos. Por tanto, si un servicio de datos requiere que se configuren las direcciones de red en el momento del inicio, utilice el método Start para iniciar el servicio de datos.

Del mismo modo, al poner fuera de línea un grupo de recursos que contenga recursos del servicio de datos y de direcciones de red, RGM invoca métodos para configurar las direcciones de red como inactivas después de invocar los métodos Stop del recurso del servicio de datos. Por tanto, si un servicio de datos requiere que se configuren direcciones de red como activas en el momento de la parada, utilice el método Stop para detener el servicio de datos.

Por ejemplo, para iniciar o detener un servicio de datos, es posible que haya que invocar las bibliotecas o utilidades administrativas del servicio de datos. En ocasiones, el servicio de datos tiene bibliotecas o utilidades administrativas que utilizan una interfaz de red cliente-servidor para realizar la administración. Es decir, una utilidad administrativa realiza una llamada al daemon del servidor, por lo que es posible que la dirección de red tenga que estar activa para utilizar la biblioteca o utilidad administrativa. En este caso, utilice los métodos Start y Stop.

Si el servicio de datos requiere que se configuren direcciones de red como inactivas en el momento en que se inicia y se detiene, utilice los métodos Prenet_start y Postnet_stop para iniciar y detener el servicio de datos. Tenga en cuenta si el software cliente responderá de modo diferente en función de que sea la dirección de red o el servicio de datos el que se ponga en línea primero, tras una reconfiguración del clúster (scha_control() con el argumento SCHA_GIVEOVER o una conmutación con scswitch). Por ejemplo, la implementación de cliente puede hacer unos reintentos mínimos, y desistir pronto, una vez haya determinado que el puerto del servicio de datos no está disponible.

Si el servicio de datos no requiere que la dirección de red se configure como activa al inicio, inícielo antes de que se configure la interfaz de red. Esto garantiza que el servicio de datos podrá responder inmediatamente a las solicitudes de cliente, en cuanto se haya configurado la dirección de red, y es menos probable que los clientes dejen de realizar nuevos intentos. En este caso, utilice el método Prenet_start en lugar del método Start para iniciar el servicio de datos.

Si utiliza el método Postnet_stop, el recurso del servicio de datos seguirá activo en el punto en que se haya desconfigurado la dirección de red. El método Postnet_stop sólo se invoca después de la inactivación de la dirección de red. Así, el puerto de servicio UDP o TCP del servicio de datos o su número de programa RPC, siempre aparecen como disponibles para los clientes de la red, salvo cuando la dirección de red tampoco responda.

Nota –

Si desea instalar un servicio RPC en el clúster, el servicio no debe utilizar los siguientes números de programas: 100141, 100142 y 100248. Estos números se reservan para los daemons de Sun Cluster rgmd_receptionist, fed y pmfd, respectivamente. Si el servicio RPC que instale utiliza uno de estos números de programas, deberá cambiar el servicio para que utilice un número de programa diferente.

La decisión de utilizar los métodos Start y Stop, en lugar de Prenet_start y Postnet_stop, o de utilizar ambos métodos, debe tener en cuenta los requisitos y el comportamiento del servidor y el cliente.

Métodos Init, Fini y Boot

Tres métodos opcionales, Init, Fini y Boot, permiten que RGM ejecute el código de inicialización y finalización en un recurso. RGM invoca el método Init para realizar una inicialización del recurso una sola vez, cuando éste pase a ser gestionado, tanto cuando el grupo de recursos al que pertenece pasa de un estado no gestionado a un estado gestionado como cuando se crea en un grupo de recursos que ya está gestionado.

RGM invoca el método Fini para reorganizar después del recurso, cuando éste pase a no estar gestionado, ya sea cuando el grupo de recursos al que pertenece pase a un estado no gestionado ya sea cuando se elimina de un grupo de recursos gestionado. La reorganización debe ser idempotente, es decir, que si se ha realizado ya, Fini devuelve 0 (satisfactorio).

RGM invoca el método Boot en nodos que se han unido al clúster recientemente, es decir, que han sido arrancados o rearrancados.

El método Boot suele realizar la misma inicialización que Init. Ésta debe ser idempotente, es decir, que si ya se ha inicializado el recurso en el nodo local, Boot y Init devuelven 0 (satisfactorio).

Supervisión de un recurso

Generalmente, se implementan los supervisores para que realicen análisis periódicos de fallos en los recursos, para detectar si funcionan correctamente. Si falla un análisis de fallos, el supervisor puede intentar un reinicio local o solicitar una operación de recuperación de fallos del grupo de recursos afectado, invocando las funciones scha_control() de RMAPI o scds_fm_action() de DSDL.

También se puede supervisar el rendimiento de un recurso y ajustar o realizar un informe del rendimiento. Escribir un supervisor de fallos específico del tipo de recurso es totalmente opcional. Incluso si decide no escribir un supervisor de fallos así, el tipo de recurso estará bajo la supervisión básica del clúster que realiza el propio Sun Cluster que detecta fallos del hardware del sistema, fallos graves del sistema operativo principal y los fallos de comunicación de un sistema en sus propias redes públicas.

Aunque RGM no invoca directamente al supervisor de recursos, permite el inicio automático de los supervisores de los recursos. Cuando se pone un recurso fuera de línea, RGM invoca el método Monitor_stop para detener el supervisor de recursos en los nodos locales antes de detener el recurso en sí. Cuando se pone un recurso en línea, RGM invoca el método Monitor_start después de que se haya iniciado el recurso en sí.

Las funciones scha_control() de RMAPI y scds_fm_action() de DSDL (que invoca scha_control()) permiten que los supervisores de recursos soliciten una operación de recuperación de fallos de un grupo de recursos a un nodo diferente. Dentro de las comprobaciones de validez, scha_control() invoca Monitor_check (si se ha definido), para determinar si el nodo solicitado es lo suficientemente fiable para controlar el grupo de recursos que contiene el recurso. Si Monitor_check informa que el nodo no es fiable, o que el método agota el tiempo de espera, RGM busca otro nodo para poder realizar la solicitud de recuperación de fallos. Si Monitor_check falla en todos los nodos, se cancela la recuperación de fallos.

El supervisor de recursos puede establecer las propiedades Status y Status_msg para reflejar la vista del supervisor del estado del recurso. Utilice la función scha_resource_setstatus() o la orden scha_resource_setstatus de RMAPI o la función scds_fm_action() de DSDL para establecer estas propiedades.

Nota –

Aunque Status y Status_msg son especialmente útiles para un supervisor de recursos, cualquier programa puede establecer estas propiedades.

Consulte Definición de un supervisor de fallos para ver un ejemplo de un supervisor de fallos implementado con RMAPI. Consulte Supervisor de fallos SUNW.xfnts para ver un ejemplo de un supervisor de fallos implementado con DSDL. Consulte Sun Cluster Data Service Planning and Administration Guide for Solaris OS para obtener información sobre los supervisores de fallos que se integran en los servicios de datos que suministra Sun.

Adición del registro de mensajes a un recurso

Si desea registrar los mensajes de estado en el mismo archivo de registro que los demás mensajes del clúster, utilice la función scha_cluster_getlogfacility() para recuperar el número del recurso que se utiliza para registrar los mensajes de clúster.

Utilice este número de recurso con la función syslog() normal de Solaris para escribir los mensajes en el registro del clúster. También puede acceder a la información del recurso de registro del clúster a través de la interfaz genérica scha_cluster_get().

Provisión de la gestión de los procesos

RMAPI y DSDL proporcionan recursos de gestión de procesos para implementar supervisores de recursos y rellamadas de control de recursos. RMAPI define los siguientes recursos (consulte las páginas de comando man para obtener detalles sobre cada uno de estas órdenes y programas):

recurso del supervisor de procesos: pmfadm y rpc.pmfd

El recurso del supervisor de procesos (PMF) permite supervisar los procesos y sus descendientes, y reiniciarlos si se terminan; incluye la orden pmfadm para iniciar y controlar los procesos supervisados y el daemon rpc.pmfd.

halockrun

Un programa para ejecutar otro subordinado mientras se retiene un bloqueo de archivo. Este comando es práctico en las secuencias de shell.

hatimerun

Un programa para ejecutar un programa subordinado con control de tiempo de espera. Es un comando práctico para las secuencias de shell.

DSDL proporciona la función scds_hatimerun para implementar hatimerun.

DSDL proporciona un conjunto de funciones (scds_pmf_*) para implementar la función PMF. Consulte Funciones de PMF si desea obtener información general sobre la función PMF de DSDL y una lista de las funciones individuales.

Provisión de soporte administrativo de un recurso

Las acciones administrativas aplicables a los recursos incluyen el establecimiento y la modificación de las propiedades de los recursos. La API define los métodos de rellamada Validate y Update para que se pueda enlazar con estas acciones administrativas.

RGM invoca el método opcional Validate cuando se crea un recurso y cuando una acción administrativa actualiza las propiedades del recurso o del grupo que lo contiene. RGM pasa los valores de propiedad del recurso y su grupo de recursos al método Validate. RGM invoca Validate en el conjunto de nodos del clúster que indica la propiedad Init_nodes del tipo de recurso (consulte Propiedades del tipo de recurso o la página de comando man de rt_properties(5)) para obtener información sobre Init_nodes. RGM invoca Validate antes de que se aplique la creación o la actualización, y un código de salida de fallo desde el método en cualquier nodo provoca un fallo en la creación o la actualización.

RGM invoca Validate sólo cuando se cambian las propiedades del recurso o del grupo mediante una acción administrativa, no cuando RGM establece propiedades ni cuando un supervisor establece las propiedades de recurso Status y Status_msg.

RGM invoca el método opcional Update para notificar a un recurso en ejecución que se han modificado las propiedades. RGM invoca Update después de que una acción administrativa establezca satisfactoriamente las propiedades de un recurso o del grupo al que pertenece. RGM invoca este método en los nodos en los que el recurso está en línea. Este método puede utilizar las funciones de acceso de la API para leer los valores de propiedad que pueden afectar a un recurso activo y ajustar el recurso en ejecución según corresponda.

Implementación de un recurso a prueba de fallos

Un grupo de recursos a prueba de fallos contiene direcciones de red, como la dirección compartida y el nombre lógico de servidor integrados de los tipos de recursos, y recursos a prueba de fallos como los recursos de aplicación de los servicios de datos para un servicio de datos a prueba de fallos. Los recursos de dirección de red, junto con sus recursos de los servicios de datos dependientes, se mueven de uno a otros nodos del clúster cuando se produce una operación de recuperación de fallos o conmutación en los servicios de datos. RGM proporciona diversas propiedades que respaldan la implementación de un recurso a prueba de fallos.

Establezca la propiedad de tipo de recurso booleano Failover en TRUE para que el recurso no se pueda configurar en un grupo de recursos que pueda estar en línea en más de un nodo simultáneamente. Esta propiedad tiene el valor predeterminado de FALSE, por lo que hay que declararla TRUE en el archivo RTR para un recurso a prueba de fallos.

La propiedad del recurso Scalable determina si el recurso utiliza el recurso de dirección compartida del clúster. Para un recurso a prueba de fallos, establezca Scalable en FALSE, porque los recursos a prueba de fallos no utilizan direcciones compartidas.

La propiedad de grupo de recursos RG_mode permite al administrador del clúster identificar un grupo de recursos como a prueba de fallos o escalable. Si RG_mode es FAILOVER, RGM fija la propiedad Maximum_primaries del grupo en 1 y limita el grupo de recursos a un único nodo maestro. RGM no permite que se cree un recurso con la propiedad Failover fijada en TRUE en un grupo de recursos cuyo RG_mode sea SCALABLE.

La propiedad del grupo de recursos Implicit_network_dependencies especifica que RGM debe imponer dependencias fuertes implícitas de recursos que no sean dirección de red a todos los recursos de dirección de red (dirección compartida y nombre lógico de servidor) del grupo. Esto significa que para los recursos que no sean de dirección de red (servicios de datos) del grupo no se invocarán los métodos Start hasta que se configure la activación de las direcciones de red del grupo. La propiedad Implicit_network_dependencies tiene el valor predeterminado TRUE.

Implementación de un recurso escalable

Un recurso escalable puede estar en línea en varios nodos simultáneamente. Los recursos escalables incluyen servicios de datos, como Sun Cluster HA para Sun One Web Server y HA-Apache.

RGM proporciona diversas propiedades que admiten la implementación de un recurso escalable.

Establezca la propiedad del tipo de recurso booleano Failover en FALSE para permitir que el recurso se configure en un grupo de recursos que pueda estar en línea en varios nodos simultáneamente.

La propiedad del recurso Scalable determina si el recurso utiliza el recurso de dirección compartida del clúster. Establezca esta propiedad en TRUE porque los servicios escalables utilizan los recursos de dirección compartida para que las diversas instancias del servicio escalable aparezcan ante el cliente como un único servicio.

La propiedad del grupo de recursos RG_mode permite al administrador del clúster identificar un grupo de recursos como a prueba de fallos o escalable. Si RG_mode es SCALABLE, RGM permite que Maximum_primaries tenga un valor superior a 1; esto quiere decir que el grupo puede tener varios nodos maestros simultáneamente. RGM permite que un recurso cuya propiedad Failover sea FALSE se lance en un grupo de recursos cuyo RG_mode sea SCALABLE.

El administrador del clúster crea un grupo de recursos escalables para que contenga los recursos de servicio escalables y un grupo de recursos a prueba de fallos independiente para que contenga los recursos de dirección compartida de los que dependerán los recursos escalables.

El administrador del clúster utiliza la propiedad del grupo de recursos RG_dependencies para especificar el orden en el que los grupos de recursos se ponen en línea y fuera de línea, dentro del nodo. Este orden es importante para el servicio escalable, porque los recursos escalables y los de dirección compartida de los que dependen están en grupos de recursos diferentes. Un servicio de datos escalables requiere que los recursos de dirección de red (dirección compartida) se asignen antes de su inicio. Por tanto, el administrador debe establecer la propiedad RG_dependencies (del grupo de recursos que contiene el servicio escalable) para que incluya el grupo de recursos que contiene los recursos de dirección compartida.

Cuando se declara la propiedad escalable en el archivo RTR de un recurso, RGM crea automáticamente el siguiente conjunto de propiedades escalables para el recurso:

Network_resources_used

Identifica los recursos de dirección compartida que utiliza este recurso. Esta propiedad acude de modo predeterminado a la secuencia vacía, por lo que el administrador del clúster debe aportar la lista real de direcciones compartidas que usa el servicio escalable cuando cree el recurso. El comando scsetup y SunPlex Manager proporcionan funciones para configurar automáticamente los recursos y grupos necesarios para los servicios escalables.

Load_balancing_policy

Especifica la política de equilibrio de cargas del recurso. Puede establecer explícitamente la política del archivo RTR (o permitir la predeterminada, LB_WEIGHTED). En ambos casos, el administrador del clúster puede modificar el valor al crear el recurso (salvo que se establezca Tunable para Load_balancing_policy en NONE o FALSE en el archivo RTR). Los valores legales son:

LB_WEIGHTED

La carga se distribuye entre varios nodos, de acuerdo con los pesos establecidos en la propiedad Load_balancing_weights.

LB_STICKY

Un cliente determinado (identificado por la dirección IP de cliente) del servicio escalable se envía siempre al mismo nodo del clúster.

LB_STICKY_WILD

Un cliente determinado (identificado por la dirección IP de cliente) que se conecta a una dirección IP de un servicio adherente con comodín, siempre se envía al mismo nodo del clúster, independientemente del número de puerto al que llegue.

Para un servicio escalable con Load_balancing_policy LB_STICKY o LB_STICKY_WILD cambiar Load_balancing_weights con el servicio en línea puede provocar la puesta a cero de las afinidades existentes del cliente. En ese caso, un nodo diferente puede servir una solicitud posterior de un cliente, aunque antes éste haya sido atendido por otro nodo del clúster.

Del mismo modo, iniciar una nueva instancia del servicio en un clúster puede poner a cero las afinidades existentes del cliente.

Load_balancing_weights

Especifica la carga que se enviará a cada nodo. El formato es peso@nodo,peso@nodo, donde peso es un número entero que refleja la parte relativa de carga distribuida al nodo especificado. La fracción de carga distribuida a un nodo es el peso de este nodo dividido entre la suma de todos los pesos de las instancias activas. Por ejemplo, 1@1,3@2 especifica que el nodo 1 recibe 1/4 de la carga y el nodo 2, 3/4.

Port_list

Identifica los puertos en los que recibe el servidor. Esta propiedad acude de modo predeterminado a la secuencia vacía. Puede indicarse una lista de puertos en el archivo RTR. En caso contrario, el administrador del clúster debe suministrar la lista real de puertos al crear el recurso.

Es posible crear un servicio de datos que el administrador pueda configurar para que sea de tipo escalable o a prueba de fallos. Para ello, declare la propiedad del tipo de recurso Failover y la propiedad del recurso Scalable FALSE en el archivo RTR del servicio de datos. Especifique la propiedad Scalable para que se pueda ajustar en el momento de la creación.

El valor de propiedad Failover (FALSE) permite que el recurso se configure como grupo de recursos escalables. El administrador puede habilitar direcciones compartidas, cambiando el valor de Scalable a TRUE al crear el recurso, creando así un servicio escalable.

Por otra parte, aunque Failover se establezca en FALSE, el administrador puede configurar el recurso en un grupo de recursos a prueba de fallos para implementar un servicio a prueba de fallos. El administrador no cambia el valor de Scalable, que es FALSE. Para admitir esta contingencia, debe proporcionar una comprobación en el método Validate de la propiedad Scalable. Si Scalable es FALSE, compruebe que el recurso esté configurado como grupo de recursos a prueba de fallos.

Sun Cluster Concepts Guide for Solaris OS contiene información adicional sobre los recursos escalables.

Comprobaciones de validación de los servicios escalables

Siempre que se crea o actualiza un recurso con la propiedad escalable fijada en TRUE, RGM valida diversas propiedades de recursos. Si éstas no están debidamente configuradas, RGM rechaza el intento de creación o actualización. RGM realiza las comprobaciones siguientes:

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.