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 describe cómo conseguir que una aplicación tenga alta disponibilidad o escalabilidad, y 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 puede cumplir todos los requisitos, es posible que deba modificar el código fuente de la aplicación para que ofrezca alta disponibilidad o escalabilidad.

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

Nota –

Un servicio escalable debe cumplir las siguientes condiciones para ofrecer alta disponibilidad, así como algunos criterios adicionales, como se muestra en la lista.

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

Para un servicio escalable, las características de la aplicación determinan también la directiva de equilibrio de cargas. Por ejemplo, la directiva de equilibrio de cargas Lb_weighted, que permite que cualquier instancia pueda responder a las solicitudes de cliente, no funciona para una aplicación que utiliza una caché en memoria para las conexiones de cliente en el servidor. En este caso, se debe especificar una directiva de equilibrio de cargas que restrinja el tráfico de un cliente determinado a una instancia de la aplicación. Las directivas de equilibrio de cargas Lb_sticky y Lb_sticky_wild envían varias veces todas las solicitudes de un cliente a la misma instancia de aplicación, en la que se puede utilizar una caché en memoria. 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 de recuperación ante fallos para obtener más información sobre cómo establecer la directiva de equilibrio de cargas para 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 Agent Builder de SunPlex, una herramienta que automatiza la creación de un servicio de datos.

A continuación se muestra el enfoque que se debe seguir al desarrollar un servicio de datos:

  1. Decida 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. Ejecute Agent Builder, especifique la información solicitada y genere un servicio de datos que incluya el 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 su propio código en determinadas ubicaciones del código generado por Agent Builder, puede sustituir uno de los métodos generados o el programa del supervisor generado por un programa escrito desde cero utilizando las funciones DSDL o RMAPI. Sin embargo, independientemente de la opción que lleve a cabo, en casi todos los casos, es recomendable comenzar con Agent Builer, por los siguientes motivos:

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 comandos ksh de DSDL.

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

Antes de empezar a desarrollar el servicio de datos, debe instalar el paquete de desarrollo de Sun Cluster (SUNWscdev) para tener acceso a los archivos de encabezado y biblioteca de esta herramienta. Aunque este paquete ya está instalado en todos los nodos del clúster, debe desarrollar normalmente el servicio de datos en una máquina de desarrollo independiente sin clúster y no en un nodo del clúster. En este caso, debe utilizar el comando 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 encabezado 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. Por lo tanto, si intenta crear un servicio de datos C++ para utilizarlo en Sun Cluster, debe compilarlo de la siguiente forma:

Cuando haya finalizado el proceso de desarrollo (en un nodo sin clúster), debe transferir el servicio de datos completado a un clúster para probarlo.

Nota –

Asegúrese de utilizar la versión para desarrolladores o completa del grupo de software del sistema operativo Solaris 8 o posterior.

Los procedimientos de esta sección describen cómo completar las siguienter tareas:

ProcedureCómo configurar el 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.

Pasos

  1. Conviértase en superusuario o asuma una función similar.

  2. Cambie al directorio del CD-ROM que desea utilizar. 


    # cd cd-rom-directory

  3. Instale el paquete SUNWscdev en el directorio actual.

    • Si utiliza el sistema operativo Solaris 10 en un entorno de zonas, escriba el siguiente comando como administrador global en la zona global: 


      # pkgadd -G -d . SUNWscdev

      El paquete SUNWscdev se agrega a la zona global, siempre que su contenido no afecte a ningún área de la zona global compartida con la zona no global.

    • Si utiliza otra versión de Solaris o la versión 10 en un entorno que no sea de zonas, escriba el siguiente comando: 


      # pkgadd -d . SUNWscdev

  4. En el makefile, especifique el compilador y las opciones de vinculación para identificar los archivos de inclusión y biblioteca del código del servicio de datos.

    Especifique la opción -I para identificar los archivos de encabezado de Sun Cluster, -L para especificar la ruta de búsqueda de la biblioteca de tiempo de compilación y -R para especificar la ruta de búsqueda de la biblioteca a la opción de vinculación de tiempo de ejecución del clúster. 

    # Makefile for sample data service
...

-I /usr/cluster/include

-L /usr/cluster/lib

-R /usr/cluster/lib
...

Transferencia de un servicio de datos a un clúster

Una vez completado el servicio de datos en una máquina de desarrollo, debe transferirlo a un clúster para probarlo. Para reducir las posibilidades de error durante la transferencia, combine el código del servicio de datos y el archivo RTR en un paquete e instale este 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. Tenga en cuenta que Agent Builder crea automáticamente este paquete.

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 especifican el tipo de recurso, su versión, la versión de la API, así como las rutas a cada uno de los métodos de rellamada. Propiedades del tipo de recurso muestra todas las propiedades de tipos de recursos.

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

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.

Utilice Agent Builder para generar el archivo RTR del servicio de datos, puesto que esta herramienta declara el conjunto de propiedades necesarios, y útiles, para los servicios de datos. Por ejemplo, determinadas propiedades, como Resource_type, deben declararse en el archivo RTR. De lo contrario, fallará el registro del servicio de datos. Otras propiedades, aunque no son necesarias, no estarán disponibles para el administrador del clúster a menos que éste las declare en el archivo RTR. Algunas propiedades siempre están disponibles independientemente de si se declaran o no, ya que RGM las define y proporciona los valores predeterminados. Si desea evitar este nivel de complejidad, utilice Agent Builder para garantizar la generación de un archivo RTR correcto. Más adelante, puede editar el archivo RTR y cambiar los valores específicos si es necesario.

El resto de esta sección muestra 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 se han declarado en el archivo RTR, ya que forman parte de la configuración permanente del tipo de recurso.

Nota –

Sólo el administrador del clúster puede configurar la propiedad del tipo de recurso Installed_nodes. No se puede declarar Installed_nodes en el archivo RTR.

La sintaxis de las declaraciones del tipo de recurso es la siguiente: 

property-name = value;
Nota –

Los nombres de los tipos de recursos, los recursos y los grupos de recursos no distinguen entre mayúsculas y minúsculas. Puede utilizar cualquier combinación de mayúsculas y minúsculas al especificar los nombres de las propiedades.

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

# Sun Cluster Data Services Builder template version 1.0
# Registration information and resources for smpl
#
#NOTE: Keywords are case insensitive, i.e., you can use
#any capitalization style you prefer.
#
Resource_type = "smpl";
Vendor_id = SUNW;
RT_description = "Sample Service on 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, fallará el registro del tipo de recurso.

El primer conjunto de declaraciones del tipo de recurso proporciona información básica sobre el mismo.

Resource_type y Vendor_id

Indique un nombre para el tipo de recurso. Puede especificar el nombre del tipo de recurso sólo con la propiedad Resource_type (smpl ) o utilizando la propiedad Vendor_id como prefijo, seguido de “.” para separarlo del tipo de recurso (SUNW.smpl), como se muestra en el ejemplo. Si especifica Vendor_id, utilice el símbolo de valor de la compañía que define al tipo de recurso. El nombre de éste debe ser exclusivo, dentro del clúster.

Nota –

Según las convenciones, el nombre del tipo de recurso (vendoridApplicationname) se utiliza como nombre de paquete. A partir de la versión 9 del sistema operativo Solaris, la combinación de Id. del proveedor y nombre de la aplicación puede superar los nueve caracteres. Sin embargo, si utiliza una versión anterior de Solaris, esta combinación no puede superar los nueves caracteres.

Por otro lado, Agent Builder genera explícitamente en todos los casos el nombre del paquete a partir del nombre del tipo de recurso; por lo tanto, impone la línea de nueve caracteres.

RT_description

Describe brevemente el tipo de recurso.

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 puede ejecutarse en cualquier versión de Sun Cluster a partir de Sun Cluster 3.0. API_version = 5 indica que el servicio de datos puede instalarse en cualquier versión de Sun Cluster a partir de la versión 3.1 9/04. Sin embargo, API_version = 5 también indica que el servicio de datos no puede instalarse en cualquier versión de Sun Cluster anterior a la versión 3.1 9/04. Esta propiedad se describe de forma más detallada en la entrada de API_version en Propiedades del tipo de recurso.

Failover = TRUE

Indica que el servicio de datos no puede ejecutarse en un grupo de recursos que esté en línea simultáneamente en varios nodos. En otras palabras, esta declaración especifica un servicio de datos de recuperación ante fallos. Esta propiedad se describe de forma más detallada en la entrada de Failover en Propiedades del tipo de recurso.

Start, Stop y Validate

Proporciona la ruta al método de rellamada correspondiente, invocado por RGM. Estas rutas son relativas en relación con el directorio especificado por RT_basedir.

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

Init_nodes = RG_PRIMARIES

Especifica que RGM debe llamar únicamente a los métodos Init, Boot, Fini y Validate en los nodos que puede controlar el servicio de datos. Los nodos especificados por RG_PRIMARIES forman 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 debe llamar 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 y Validate

Proporciona las rutas a los programas de métodos de rellamada correspondientes llamados por RGM. Estas rutas son relativas en relación con el directorio especificado por RT_basedir.

Declaración de las propiedades del recurso

Al igual que con las propiedades del tipo de recurso, debe declarar las propiedades del recurso 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: 

{
    attribute = value;
    attribute = value;
             .
             .
             .
    attribute = value;
}

Puede cambiar atributos específicos para las propiedades de recursos proporcionadas por Sun Cluster, conocidas también como propiedades definidas por el sistema, en el archivo RTR. Por ejemplo, Sun Cluster proporciona valores predeterminados para las propiedades de tiempo de espera de cada método de rellamada. 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 mediante un conjunto de atributos de propiedades proporcionado por Sun Cluster. Atributos de las propiedades de recursos muestra los atributos que permiten cambiar y definir las propiedades del recurso. 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 recursos definidas por el sistema especifica los valores de tiempo de espera para los métodos de rellamada. 

...

# Resource property declarations appear as a list of bracketed
# entries after the resource type declarations. The property 
# name declaration must be the first attribute after the open
# curly bracket of a resource property entry.
#
# Set minimum and default for method timeouts.
{
        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 = value) debe ser el primer atributo de cada declaración de las propiedades de recursos. Puede configurar las propiedades dentro de los límites definidos por los atributos de propiedades en el archivo RTR. Por ejemplo, el valor predeterminado para cada tiempo de espera del método del ejemplo es 300 segundos. El administrador del clúster 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 las propiedades del recurso.

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;
}

# The number of retries to be done within a certain period before concluding
# that the application cannot be successfully started on this node.
{
        PROPERTY = Retry_count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME; 
}

# Set Retry_interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of
# retries (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 = ANYTIME;
        DEFAULT = ;
}

Estas declaraciones de las propiedades de recursos incluyen el atributo TUNABLE, que limita el número de veces que el administrador del clúster puede cambiar el valor de la propiedad a la que está asociada el atributo. Por ejemplo, el valor AT_CREATION implica que el administrador del clúster solo puede especificar el valor cuando se crea el recurso y no puede modificarlo más adelante.

Puede aceptar los valores predeterminados generados por Agent Builder para la mayoría de las propiedades, a menos que tenga algún motivo para modificarlos. A continuación, se ofrece información sobre estas propiedades. Consulte Propiedades de recurso o la página de comando man r_properties(5) para obtener más información.

Failover_mode

Indica si RGM debe cambiar la ubicación del grupo de recursos o anular el nodo en cado de fallo del método Start o Stop.

Thorough_probe_interval, Retry_count y Retry_interval

Utilizado en el supervisor de fallos. Tunable es como ANYTIME, por lo que un administrador del clúster los puede ajustar si el supervisor de fallos no funciona de forma óptima.

Network_resources_used

Una lista de recurso de dirección compartida o nombre de host lógico utilizados por el servicio de datos. Agent Builder declara esta propiedad para que el administrador del clúster pueda especificar una lista de recursos, si hay alguna, al configurar el servicio de datos.

Scalable

Se establece en FALSE para indicar que este recurso no emplea la utilidad de red (dirección compartida) del clúster. Si se establece en FALSE, la propiedad Failover del tipo de recurso debe establecerse en TRUE para indicar la existencia de un servicio de recuperación ante fallos. Consulte Transferencia de un servicio de datos a un clúster y Implementación de los métodos de rellamada para obtener más información sobre el uso de esta propiedad.

Load_balancing_policy y Load_balancing_weights

Estas propiedades se declaran automáticamente. Sin embargo, no se utilizan en los tipos de recursos de recuperación ante fallos.

Port_list

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

Declaración de las propiedades de extensión

Las propiedades de extensión aparecen al final del archivo RTR de ejemplo. 

# Extension Properties
#

# The cluster administrator must set the value of this property to point to the 
# directory that contains the configuration files used by the application.
# For this application, smpl, specify the path of the configuration file on
# PXFS (typically named.conf).
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "The Configuration Directory Path(s)";
}

# The following two properties control restart of the fault monitor.
{
        PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Number of PMF restarts allowed for fault monitor.";
}
{
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time window (minutes) for fault monitor restarts.";
}
# Time out value in seconds for the probe.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time out value for the probe (seconds)";
}

# Child process monitoring level for PMF (-C option of pmfadm).
# Default of -1 means to not use the -C option of pmfadm.
# A value of 0 or greater indicates the desired level of child-process.
# monitoring.
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Child monitoring level for PMF";
}
# User added code -- BEGIN VVVVVVVVVVVV
# User added code -- END   ^^^^^^^^^^^^

Agent Builder crea las siguientes propiedades de extensión, de gran utilidad 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 clúster puede proporcionar la ubicación de este directorio al configurar el servicio de datos.

Monitor_retry_count, Monitor_retry_interval y Probe_timeout

Controla los reinicios del supervidor de fallos, aunque no los del daemon del servidor.

Child_mon_level

Establece el nivel de supervisión que llevará a cabo PMF. Para obtener más información, consulte la página de comando man pmfadm(1M).

Puede crear propiedades de extensión adicionales en el área delimitada por los comentarios del código agregado por el usuario, User added code.

Implementación de los métodos de rellamada

Esta sección proporciona información general sobre la implementación de los métodos de rellamada.

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

Normalmente, los métodos de rellamada necesitan acceder 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 la páginas de comando man scha_resource_get(1HA) y scha_resource_get(3HA).

DSDL proporciona un conjunto de funciones de C (una función para cada propiedad) para acceder a las 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 la información de estado dinámico del servicio de datos, ya que no hay disponible ninguna función de la API que permita establecer otras propiedades de recursos diferentes a 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 las propiedades de recursos con el comando scrgadm, o mediante una interfaz o comando administrativo gráfico. Sin embargo, no se debe invocar scrgadm desde ningún método de rellamada porque scrgadm fallará durante la reconfiguración del clúster, es decir, cuando RGM llame al 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 Start falla, RGM puede llamar al método Stop en un recurso, aunque éste nunca se haya iniciado. Del mismo modo, un daemon del recurso puede desactivarse espontáneamente y, aún así, RGM puede seguir ejecutando el método Stop en él. Esto mismo se aplica también a los métodos Monitor_start y Monitor_stop.

Por estos motivos, se puede lograr que los métodos Stop y Monitor_stop sean idempotentes. Varias llamadas de Stop or Monitor_stop en el mismo recurso con los mismos argumentos logran los mismos resultados que una única 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 deben también ser idempotentes. No es necesario que lo sea el método Start.

Servicio genérico de datos

Un servicio génerico de datos (GDS) es un mecanismo que permite que las aplicaciones simples tengan alta disponibilidad o escalabilidad mediante su conexión a la estructura del Gestor de grupos de recursos de Sun Cluster. Este mecanismo no requiere la creación de código para el servicio de datos, lo que suele ser habitual para lograr que una aplicación ofrezca alta disponibilidad o escalabilidad.

El modelo GDS utiliza un tipo de recurso precompilado, SUNW.gds, para interactuar con la estructura de RGM. Consulte el Capítulo 10, Servicios genéricos de datos para obtener información adicional.

Control de una aplicación

Los métodos de rellamada permiten que RGM asuma el control del recurso subyacente (es decir, la aplicación) cada vez que los nodos se unan o abandonen el 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 llama a los programas de métodos del tipo de recurso en el momento y nodos correctos para poner los grupos de recursos en línea o fuera de línea. Por ejemplo, después de producirse un bloqueo de un nodo del clúster, RGM transfiere los grupos de recursos controlados por ese nodo 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 se han establecido tiempos de espera lo suficientemente largos en los métodos Start para los tipos de recursos que requieren un periodo de inicialización prolongado. Para ello, establezca los valores predeterminados y mínimos para la propiedad Start_timeout en el archivo RTR.

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 Nodo 1 y se vuelve a poner en línea en el Nodo 2. Al establecer fuera de línea el grupos de recursos, RGM llama al método Stop en los recursos del grupos para detener toda actividad en el Nodo 1. Una vez que se han completado los métodos Stop de todos los recursos en el Nodo 1, RGM vuelve a poner en línea los grupos de recursos en el Nodo 2.

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 implementación más segura del método Stop finaliza todos los procesos relacionados con el recurso en el nodo local. Los tipos de recursos que requieren un largo tiempo para cerrarse deberían disponer de tiempos de espera lo suficientemente prolongados en los métodos Stop. Establezca la propiedad Stop_timeout en el archivo RTR.

Si falla el método Stopo se agota el tiempo de espera, el grupo de recursos presenta un estado de error que requiere la intervención del administrador del clúster. 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.

Selección de los métodos Start y Stop que deben utilizarse

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 en profundidad tanto el cliente como el protocolo de red de cliente-servidor del servicio de datos para decidir los métodos correctos que deben utilizarse.

Es posible que los servicios que utilizan recursos de dirección de red necesiten que los procesos de inicio o parada se realicen en un determinado orden en relación con la configuración de dirección de nombre de host lógico. 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 inicio y cierre antes y después de configurar la activación o desactivación de 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. A continuación se muestra la secuencia que permite que RGM ponga en línea un grupo de recursos:

  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.

Al optar por los métodos Start, Stop, Prenet_start o Postnet_stop, debe tener en cuenta primero la parte 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 la activación de las direcciones de red antes de llamar a los métodos Start del recurso del servicio de datos. Por tanto, si un servicio de datos requiere que se configure la activación de 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 configure la activación de direcciones de red 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 recomendable ejecutar las bibliotecas o las 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. Utilice los métodos Start y Stop en esta situación.

Si el servicio de datos requiere que se configuren las 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 se configure la activación de la dirección de red, inícielo antes de que se configure la activación de la interfaz de red. Si se inicia el servicio de datos de esta forma, asegúrese de que el servicio de datos responde inmediatamente a las solicitudes del cliente tan pronto como se configure la activación de la dirección de red. Como resultado, es poco probable que los clientes dejen de intentarlo. 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 ejecuta después de configurar la desactivación de la dirección de red. A consecuencia de esto, el puerto del servicio TCP o UDP del servicio de datos, o su número de programa RPC, aparecerá siempre disponible para los clientes de la red, excepto cuando no responda la dirección de red.

Nota –

Si instala un servicio RPC en el clúster, éste no debe utilizar los siguientes números de programa: 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 instalado utiliza uno de estos números de programa, cámbielo.

A la hora de decidirse por el uso de los métodos Start y Stop o de los métodos Prenet_start y Postnet_stop, o ambos, debe tener en cuenta los requisitos y el comportamiento de el 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 ejecuta el método Init para efectuar una única inicialización del recurso cuando éste se administra como resultado de una de las siguientes condiciones:

RGM ejecuta el método Fini para efectuar tareas de limpieza en el recurso al convertirse en un recurso no administrado, como consecuencia de una de las siguientes condiciones:

El proceso de limpieza debe ser idempotente. Es decir, si la limpieza ya se ha realizado, Fini sale satisfactoriamente.

RGM ejecuta el método Boot en los nodos que se acaban de unir al clúster, es decir, que acaban de iniciarse o reiniciarse.

El método Boot suele realizar la misma inicialización que Init. La inicialización debe ser idempotente, es decir, si el recurso ya se ha inicializado en el nodo local, Boot e Init salen satisfactoriamente.

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 reiniciar de forma local el grupo de recursos afectado o realizar una recuperación ante fallos. El supervisor solicita la recuperación ante fallos mediante una llamada a la función scha_control() de RMAPI o la función scds_fm_action() de DSDL.

También se puede supervisar el redimiento de un recurso, y ajustarlo o informar sobre él. La escritura de un supervisor de fallos específico del tipo de recurso es 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 host, fallos graves del sistema operativo principal y los fallos de comunicación de un host en sus propias redes públicas.

Aunque RGM no llama directamente a un supervisor de recursos, sí proporciona funciones para iniciar automáticamente supervisores de 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í. Al poner en línea un recurso, RGM llama al método Monitor_start una vez iniciado el recurso.

La función scha_control() de RMAPI y la función scds_fm_action () de DSDL (que llama a scha_control()) permiten a los supervisores de recursos solicitar una operación de recuperación ante fallos del grupo de recursos en un nodo diferente. Al igual que una de sus comprobaciones de integridad, scha_control() llama a 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 de que el nodo no es fiable o de que se ha agotado el tiempo de espera del método, RGM busca un nodo diferente al que enviar la solicitud de recuperación ante fallos. Si Monitor_check falla en todos los nodos, se cancela la recuperación ante fallos.

El supervisor de recursos puede establecer las propiedades Status y Status_msg para reflejar el estado el recurso proporcionado por el supervisor. Utilice la función scha_resource_setstatus() de RMAPI, el comando scha_resource_setstatus o la función scds_fm_action() de DSDL para establecer estas propiedades.

Nota –

Aunque las propiedades Status y Status_msg son específicas del supervisor de recursos, cualquier programa puede establecerlas.

Consulte Definición de un supervisor de fallos para obtener un ejemplo de un supervisor de fallos implementado con RMAPI. Consulte Supervisor de fallos SUNW.xfnts para obtener un ejemplo de un supervisor de fallos implementado con DSDL. Consulte Sun Cluster Data Services 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().

Administración de los procesos

RMAPI y DSDL proporcionan recursos de administración de procesos para implementar supervisores de recursos y rellamadas de control de recursos. RMAPI define las siguientes utilidades:

Utilidad de supervisor de procesos (PMF): pmfadm y rpc.pmfd

Proporciona medios para supervisar procesos y sus descendientes, y reiniciar procesos en caso de desactivarse. La utilidad está formada por el comando pmfadm que permite iniciar y controlar procesos supervisados y el daemon rpc.pmfd.

DSDL proporciona un conjunto de funciones (precedido por el nombre scds_pmf_) para implementar la función PMF. Consulte Funciones de PMF para obtener información general de la función PMF de DSDL y una lista de las funciones individuales.

Las páginas de comando man pmfadm(1M) y rpc.pmfd(1M) describen de forma más detallada este comando y el daemon.

halockrun

Un programa para ejecutar otro subordinado mientras se retiene un bloqueo de archivo. Este comando es adecuado para su uso en secuencias de comandos de shell.

La página de comando man halockrun(1M) describe de forma más detallada este comando.

hatimerun

Programa para ejecutar un programa secundario bajo el control de un intervalo de tiempo de espera. Este comando es adecuado para su uso en secuencias de comandos de shell.

DSDL proporciona la función scds_hatimerun() para implementar hatimerun.

La página de comando man hatimerun(1M) describe de forma más detallada este comando.

Asistencia administrativa para un recurso

Entre las acciones que el administrador realiza en los recursos, se incluyen el establecimiento y la modificación de las propiedades de recursos. La API define los métodos de rellamada Validate y Update para que pueda crear un código vinculado a estas acciones administrativas.

RGM llama al método opcional Validate cuando se crea un recurso y el administrador del clúster actualiza sus propiedades o el grupo de recursos que lo contiene. RGM pasa los valores de propiedad del recurso y su grupo de recursos al método Validate. RGM llama a Validate en el conjunto de nodos del clúster indicado por la propiedad Init_nodes del tipo de recurso. Consulte Propiedades del tipo de recurso o la página de comando man rt_properties(5) para obtener información sobre Init_nodes. RGM llama a Validate antes de efectuar la creación o aplicar la actualización. Un código de salida de fallo proveniente del método en cualquier nodo provoca que falle la creación o la actualización.

RGM sólo llama a Validate cuando el administrador del clúster cambia las propiedades de un recurso o un grupo de recursos, y no cuando lo hace RGM, o cuando un supervisor establece las propiedades de recursos 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 ejecuta Update una vez que el administrador del clúster ha establecido con éxito las propiedades de un recurso o su grupo. 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 de recuperación ante fallos

Un grupo de recursos de recuperación ante fallos contiene direcciones de red, como los tipos de recursos integrados LogicalHostname y SharedAddress , y recursos de recuperación ante fallos, como los recursos de aplicación para un servicio de datos de recuperación ante fallos. Los recursos de dirección de red, junto con los recursos del servicio de datos dependientes, se transfieren de un nodo del clúster a otro, cuando una recuperación ante fallos o una operación de conmutación del servicio de datos. RGM proporciona diversas propiedades que respaldan la implementación de un recurso de recuperación ante fallos.

Establezca la propiedad booleana Failover del tipo de recurso en TRUE para impedir que un recurso se configure en un grupo de recursos que esté en línea en más de un nodo a la vez. El valor predeterminado de esta propiedad es FALSE, por lo que debe declararlo como TRUE en el archivo RTR para un recurso de recuperación ante fallos.

La propiedad de recurso Scalable determina si el recurso utiliza la función de dirección compartida del clúster. Si utiliza un recurso de recuperación ante fallos, establezca Scalable en FALSE, ya que esta clase de recurso no utiliza direcciones compartidas.

La propiedad RG_modede grupo de recursos permite al administrador del clúster identificar un grupo de recursos como de recuperación ante fallos o escalable. Si RG_mode es FAILOVER, RGM establece la propiedad Maximum_primaries del grupo en 1 y limita el grupo para que lo controle un solo nodo. RGM no permite que un recurso con una propiedad Failover establecida en TRUE se cree en un grupo de recursos cuyo RG_mode sea SCALABLE.

La propiedad de grupo de recursos Implicit_network_dependencies determina que RGM debe forzar el uso de las dependencias fuertes implícitas de los recursos que no son de dirección de red en todos los recursos de dirección de red (LogicalHostname y SharedAddress) del grupo. Como resultado, no se llama a los métodos Start de los recursos que no son de dirección de red (servicio de datos) hasta que se haya configurado la activación de las direcciones de red. La propiedad Implicit_network_dependencies se establece de forma predeterminada en TRUE.

Implementación de un recurso escalable

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

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

Establezca la propiedad booleana Failover del tipo de recurso en TRUE para permitir que un recurso se configure en un grupo de recursos que pueda estar en línea en más de un nodo a la vez.

La propiedad de recurso Scalable determina si el recurso utiliza la función de dirección compartida del clúster. Establezca esta propiedad en TRUE, ya que el servicio escalable utiliza un recurso de dirección de red para hacer que las diversas instancias del servicio aparezcan como un único servicio para el cliente.

La propiedad del grupo de recursos RG_mode permite al administrador del clúster identificar un grupo de recursos como de recuperación ante fallos o escalable. Si RG_mode es SCALABLE, RGM permite que Maximum_primaries tenga un valor superior a 1, por lo que el grupo puede ser controlado por varios nodos simultáneamente. RGM permite que un recurso cuya propiedad Failover sea FALSE cree una instancia en un grupo de recursos cuya propiedad RG_mode sea SCALABLE.

El administrador del clúster crea un grupo de recursos de recursos escalables para incluir los recursos del servicio escalable y un grupo de recursos de recuperación ante fallos independiente para incluir los recursos de dirección compartida de los que depende el recurso escalable.

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 activen antes de su inicio. Por lo tanto, el administrador del clúster debe establecer la propiedad RG_dependencies (del grupo de recursos que contiene el servicio escalable) para incluir el grupo de recursos que contiene los recursos de dirección compartida.

Al declarar la propiedad Scalable 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 utilizados por este recurso. La propiedad se establece de forma predeterminada en una cadena vacía para que el administrador del clúster pueda proporcionar la lista real de direcciones compartidas que utiliza el servicio escalable al crear 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 directiva de equilibrio de cargas del recurso. Se puede establecer de forma explícita la directiva en el archivo RTR (o permitir el valor predeterminado LB_WEIGHTED). En ambos casos, el administrador del clúster puede cambiar el valor al crear el recurso (a menos que se establezca la propiedad Tunable de Load_balancing_policy en NONE o FALSE en el archivo RTR). Estos son los valores permitidos que puede utilizar:

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 concreta 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 de la dirección IP a la que llegue.

En un servicio escalable con una propiedad Load_balancing_policy de LB_STICKY o LB_STICKY_WILD, si se cambia Load_balancing_weights mientras el servicio está en línea puede provocar que se restablezcan las afinidades de cliente existentes. En ese caso, es posible que un nodo diferente deba atender la solicitud de cliente, aunque otro nodo del clúster haya atendido previamente a ese cliente.

Del mismo modo, si se inicia una nueva instancia del servicio en un clúster, es posible que se restablezcan las afinidades de cliente existentes.

Load_balancing_weights

Especifica la carga que se enviará a cada nodo. El formato es weight@node,weight@node, donde weight es un número entero que refleja la parte relativa de la carga distribuida al nodo especificado, node. 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 un cuarto de la carga y el nodo 2, los restantes tres cuartos.

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.

Puede crear un servicio de datos que el administrador del clúster puede configurar como escalable o de recuperación ante fallos. Para ello, declare la propiedad Failover del tipo de recurso y la propiedad Scalable del recurso como 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 FALSE de la propiedad Failover permite configurar el recurso en un grupo de recursos escalable. El administrador del clúster puede habilitar las direcciones de red cambiando el valor de Scalable a TRUE al crear el recurso para crear un servicio escalable.

Por otro lado, aunque Failover se estableza en FALSE, el administrador del clúster puede configurar el recurso en un grupo de recursos de recuperación ante fallos para implementar un servicio de este tipo. El administrador del clúster no cambia el valor de Scalable, que es FALSE. Para poder llevar a cabo esto, debe proporcionar una comprobación del método Validate en la propiedad Scalable. Si Scalable es FALSE, compruebe que el recurso se ha configurado en un grupo de recursos de recuperación ante fallos.

Sun Cluster: Guía de conceptos para el SO Solaris 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

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.