Apéndice E Requisitos para aplicaciones no habilitadas para el clúster

Una aplicación normal, no habilitada para el clúster, debe cumplir ciertos requisitos para poder adquirir una alta disponibilidad (HA). La sección Análisis de la validez de la aplicación enumera estos requisitos. Este apéndice proporciona detalles adicionales sobre elementos específicos de esta lista.

Una aplicación adquiere alta disponibilidad cuando la configuración de sus recursos se transforma en grupos de recursos. Los datos de la aplicación se sitúan en un sistema global de archivos de alta disponibilidad, lo que permite que los datos estén accesibles desde un servidor encendido en caso de que falle el otro. Consulte la información sobre los sistemas de archivos del clúster en Sun Cluster Concepts Guide for Solaris OS.

Para que los clientes de la red dispongan de acceso, se debe configurar una dirección IP de red lógica en recursos de nombre lógico de servidor, contenidos en el mismo grupo de recursos que el recurso del servicio de datos. El recurso de servicio de datos y los recursos de dirección de red experimentan una recuperación de fallos simultáneamente, lo que hace que los clientes de red del servicio de datos accedan al recurso del servicio de red en su nuevo servidor.

Datos de sistemas múltiples

Los conjuntos del disco de sistemas globales de archivos de alta disponibilidad se alojan en diferentes sistemas para que, en caso de caída de un sistema físico, uno de los sistemas activos pueda acceder al disco. Para que una aplicación tenga una alta disponibilidad, sus datos deben también tenerla, por lo que deben residir en los sistemas globales de archivos de HA (alta disponibilidad).

El sistema global de archivos está montado en grupos de discos creados como entidades independientes. El usuario puede elegir utilizar algunos grupos de discos como sistemas globales de archivos montados y otros como dispositivos básicos para utilizarlos con un servicio de datos, como HA Oracle.

Una aplicación puede tener conmutadores de línea de órdenes o archivos de configuración que apunten a la ubicación de los archivos de datos. Si la aplicación utiliza nombres de rutas invariables, es posible cambiar los nombres de éstas por vínculos simbólicos que señalen a archivos del sistema global de archivos, sin cambiar el código de aplicación. Consulte Utilización de vínculos simbólicos para la colocación de datos de varios sistemas para ver más detalles sobre la utilización de los vínculos simbólicos.

En el peor de los casos, el código fuente de la aplicación se debe modificar para proporcionar un mecanismo de direccionamiento a la ubicación real de los datos. Esto se puede hacer implementando conmutadores de líneas de órdenes adicionales.

Sun Cluster admite la utilización de sistemas UFS de UNIX y dispositivos básicos de alta disponibilidad, configurados en un gestor de volúmenes. Durante la instalación y configuración, el administrador del sistema debe especificar qué recursos de disco se deben utilizar con los sistemas de archivos UFS y cuáles con los dispositivos básicos. Generalmente, los dispositivos básicos sólo los utilizan servidores de bases de datos y servidores multimedia.

Utilización de vínculos simbólicos para la colocación de datos de varios sistemas

En ocasiones, los nombres de ruta de los archivos de datos de una aplicación son invariables y no existe ningún mecanismo para anularlos. Para evitar modificar el código de la aplicación, en ocasiones se pueden usar enlaces simbólicos.

Por ejemplo, supongamos que la aplicación le asigna al archivo de datos el nombre de ruta invariable/etc/mi_archivo_de_datos. Esa ruta se puede modificar de un archivo a un enlace simbólico cuyo valor señale a un archivo de uno de los sistemas de archivos del servidor lógico. Por ejemplo, se puede establecer un enlace simbólico a /global/phys-schost-2/mi_archivo_de_datos.

Es posible que se produzca un problema si se utilizan así los enlaces simbólicos cuando la aplicación, o uno de sus procedimientos administrativos, modifique el nombre del archivo de datos y su contenido. Por ejemplo, supongamos que la aplicación realiza una actualización, creando primero un archivo temporal nuevo, /etc/mi_archivo_de_datos.nuevo. Después, renombra el archivo temporal para que tenga el nombre del archivo real, con la llamada al sistema rename(2) (o el programa mv(1)). Al crear el archivo temporal y darle el nombre del archivo real, el servicio de datos intentará garantizar que el contenido del archivo de datos siempre esté bien formado.

Desgraciadamente, la acción rename(2) acaba con el enlace simbólico. El nombre /etc/mi_archivo_de_datos ahora es un archivo regular y está en el mismo sistema de archivos que el directorio /etc, no en el sistema global de archivos del clúster. Dado que el sistema de archivos /etc es privado para cada sistema, los datos no estarán disponibles después de una operación de recuperación de errores o conmutación.

El problema subyacente en esta situación es que la aplicación no conoce la existencia del enlace simbólico y no se ha escrito teniendo presentes los enlaces simbólicos. Para utilizar éstos a fin de redirigir el acceso a los datos en los sistemas de archivos de servidores lógicos, la implementación de la aplicación debe comportarse de forma que no anule los enlaces simbólicos. Por tanto, éstos no resuelven totalmente el problema de situar los datos en los sistemas globales de archivos del clúster.

Nombres de sistema

Hay que determinar si el servicio de datos necesita conocer en algún momento el nombre de sistema del servidor en el que se está ejecutando. En caso afirmativo, es posible que haya que modificar el servicio de datos para que utilice un nombre lógico de servidor (es decir, un nombre de sistema configurado en un recurso de nombre lógico de servidor que resida en el mismo grupo de recursos que el recurso de aplicación), en lugar del nombre físico.

En ocasiones, en el protocolo cliente-servidor de un servicio de datos, el servidor devuelve su propio nombre del sistema al cliente, en el contenido de un mensaje. En esos protocolos, es posible que, para ponerse en contacto con el servidor, el cliente tenga que usar este nombre de sistema devuelto, el cual, para que resulte utilizable tras una operación de recuperación de errores o conmutación, debería ser un nombre lógico de servidor del grupo de recursos, no el nombre del servidor físico. En este caso, es necesario modificar el código del servicio de datos para devolver el nombre lógico de servidor al cliente.

Sistemas multienlace

La expresión sistema multienlace describe un sistema que se encuentra en más de una red pública. Un sistema así tiene varios nombres de sistema y direcciones IP. Tiene un par nombre de sistema-dirección IP para cada red. Sun Cluster está diseñado para permitir que un sistema aparezca en tantas redes como se desee, o en una sola (el caso de los sistemas que no tienen varios directorios iniciales). Al igual que el nombre físico de servidor tiene varios pares nombre de sistema-dirección IP, cada grupo de recursos puede tener múltiples pares nombre de sistema-dirección IP, uno para cada red pública. Cuando Sun Cluster mueve un grupo de recursos de un servidor físico a otro, el juego completo de pares nombre de sistema-dirección IP de ese recurso se mueve también.

El conjunto de pares de nombre de sistema-dirección IP de un grupo de recursos se configura como recursos de nombre lógico de servidor contenidos en el grupo de recursos. Estos recursos de dirección de red los especifica el administrador del sistema cuando se crea y configura el grupo de recursos. La API del servicio de datos de Sun Cluster contiene recursos para consultar estos pares de nombre de sistema-dirección IP.

La mayoría de los daemons de servicios de datos ya preparados, que se han escrito para el sistema operativo Solaris, gestionan adecuadamente los sistemas principales con varios directorios iniciales. Muchos servicios de datos realizan todas sus comunicaciones de red mediante el vínculo con la dirección comodín de Solaris INADDR_ANY. Esta vinculación hace, automáticamente, que los servicios de datos manejen todas las direcciones IP de todas las interfaces de red. INADDR_ANY se vincula efectivamente con todas las direcciones IP configuradas actualmente en la máquina. Un daemon de servicio de datos que utiliza INADDR_ANY generalmente no necesita cambios para manejar las direcciones de red lógicas de Sun Cluster.

Vinculación con INADDR_ANY frente a vinculación con direcciones IP específicas

Aún cuando se utilicen sistemas que no tengan varias direcciones iniciales, el concepto de dirección lógica de Sun Cluster permite que la máquina disponga de más de una dirección IP, una para su propio servidor físico y varias adicionales para cada recurso de dirección de red (nombre lógico de servidor) que controla actualmente. Cuando una máquina se convierte en maestro de un recurso de dirección de red, adquiere dinámicamente direcciones IP adicionales. Cuando renuncia a ser maestro de un recurso de dirección de red, dinámicamente cede las direcciones IP.

Algunos servicios de datos no pueden funcionar adecuadamente en un entorno Sun Cluster si están vinculados con INADDR_ANY. Estos servicios de datos deben modificar dinámicamente el conjunto de direcciones IP al que están vinculados, según si el grupo de recursos tiene un maestro o no. Una estrategia para lograr volver a establecer los vínculos consiste en hacer que los métodos de inicio y parada de esos servicios de datos terminen y reinicien los daemons del servicio de datos.

La propiedad del recurso Network_resources_used permite que el usuario final configure un conjunto específico de recursos de direcciones de red con los que se debe vincular el recurso de aplicación. Para los tipos de recursos que requieran esta función, la propiedad Network_resources_used debe declararse en el archivo RTR del tipo de recurso.

Cuando RGM pone el grupo de recursos en línea o fuera de línea, sigue un orden específico para conectar, desconectar, asignar y desasignar direcciones de red dependiendo de cuándo invoca los métodos de recurso del servicio de datos. Consulte Elección de los métodos Start y Stop que se van a utilizar.

Para cuando el método Stop del servicio de datos retorna, éste debe haberse detenido con las direcciones de red del grupo de recursos. Del mismo modo, para cuando el método Start retorna, el servicio de datos debe haber empezado a utilizar las direcciones de red.

Si el servicio de datos se vincula con INADDR_ANY en lugar de con direcciones IP individuales, el orden en el que se invocan los métodos del recurso del servicio de datos y los métodos de la dirección de red no tiene importancia.

Si los métodos de inicio y parada del servicio de datos cumplen su labor, terminando y reiniciando los daemons del servicio de datos, el servicio de datos se detiene e inicia mediante las direcciones de red, en los momentos adecuados.

Reintento del cliente

Para un cliente de red, una operación de recuperación de errores o conmutación aparece como una caída del servidor lógico, seguida de un rearranque rápido. Idealmente, la aplicación del cliente y el protocolo cliente-servidor se estructuran para realizar un cierto número de reintentos. Si la aplicación y el protocolo se ocupan del caso de un único servidor que se desconecta y se reinicia, se encargarán también del caso de un grupo de recursos que está experimentando una operación de control o conmutación. Algunas aplicaciones optan por realizar un número infinito de reintentos. Las aplicaciones más complejas notifican al usuario que hay un reintento prolongado en curso y permiten que sea él quien elija si desea continuar.