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 muestra 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 transfieren a un sistema de archivos de un clúster de alta disponibilidad para que el servidor que permanezca activo pueda acceder a ellos en caso de producirse un fallo en uno de los servidores. Consulte información sobre los sistemas de archivos del clúster en Sun Cluster: Guía de conceptos para el SO Solaris.
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 de host lógico, 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 host.
Este apéndice abarca los siguientes temas:
Datos de hosts múltiples
Los dispositivos de los sistemas de archivos del clúster de alta disponibilidad se alojan en diferentes hosts para que, en caso de caída de un host físico, uno de los hosts activos pueda acceder al dispositivo. Para que una aplicación sea de alta disponibilidad, sus datos también deben serlo. Por lo tanto, los datos de la aplicación deben ubicarse en sistemas de archivos a los que se pueda acceder desde varios nodos del clúster. Entre los ejemplos de sistemas de archivos de alta disponibilidad compatibles con Sun Cluster, se incluyen los sistemas de archivos globales HA, el sistema de archivos de recuperación ante fallos (Failover File System, FFS) y, en un entorno que utilice clústeres reales de aplicaciones de Oracle, un sistema de archivos compartidos QFS.
El sistema de archivos del clúster está montado en grupos de dispositivos creados como entidades independientes. Puede elegir utilizar algunos grupos de dispositivos como sistemas de archivos montados del clúster y otros como dispositivos básicos para utilizarlos con un servicio de datos, como HA Oracle.
Es posible que una aplicación pueda incluir archivos de configuración o conmutadores de línea de comandos que señalen a la ubicación de los archivos de datos. Si esa aplicación utiliza nombres de ruta invariables, puede cambiar los nombres de ruta por vínculos simbólicos a un archivo de un sistema de archivos del clúster sin necesidad de cambiar el código de la aplicación. Consulte Utilización de vínculos simbólicos para la colocación de datos de varios hosts para obtener información más detallada sobre el uso de vínculos simbólicos.
En el peor de los casos, debe modificarse el código fuente de la aplicación para proporcionar un mecanismo que señale a la ubicación real de los datos. Cree argumentos de línea de comandos adicionales para implementar este mecanismo.
El software de Sun Cluster admite el uso de sistemas de archivos UFS de UNIX y dispositivos básicos HA configurados en un administrador de volúmenes. Al instalar y configurar el software de Sun Cluster, el administrador del clúster debe especificar los recursos de disco que se van a utilizar en los sistemas de archivos UFS y los que se utilizarán en 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 hosts
A veces los nombres de ruta de los archivos de datos de una aplicación no se pueden modificar, ni existe ningún mecanismo para anularlos. Para evitar modificar el código de la aplicación, en ocasiones se pueden usar vínculos 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 vínculo simbólico cuyo valor señale a un archivo de uno de los sistemas de archivos del host lógico. Puede establecer la ruta mediante un vínculo simbólico a /global/phys-schost-2/mydatafile.
Es posible que se produzca un problema si se utilizan así los vínculos simbólicos cuando la aplicación, o uno de sus procedimientos administrativos, modifique el nombre del archivo de datos y su contenido. Por ejemplo, suponga que la aplicación crea el nuevo archivo temporal /etc/mydatafile.new para realizar una actualización. A continuación, la aplicación cambia el nombre del archivo temporal por un nombre de archivo real mediante una llamada del sistema a la función rename() (o con el comando mv). Al crear el archivo temporal y cambiar su nombre por uno real, el servicio de datos intenta garantizar la integridad del contenido del archivo de datos.
Desgraciadamente, la acción rename() destruye el vínculo simbólico. El nombre /etc/mydatafile es ahora un nombre de archivo normal y reside en el mismo sistema de archivos que el directorio /etc, pero no en el sistema de archivos del clúster. Dado que el sistema de archivos /etc es privado para cada host, los datos no estarán disponibles después de una operación de recuperación de errores o conmutación.
El problema subyacente es que la aplicación actual no reconoce la existencia del vínculo simbólico, ya que no se ha creado para administrar este tipo de vínculos. Para utilizar éstos a fin de redirigir el acceso a los datos en los sistemas de archivos de hosts lógicos, la implementación de la aplicación debe comportarse de forma que no anule los vínculos simbólicos. Por lo tanto, los vínculos simbólicos no suponen una solución completa para el problema de la inclusión de los datos en los sistemas de archivos del clúster.
Nombres de host
Hay que determinar si el servicio de datos necesita conocer en algún momento el nombre de host del servidor en el que se está ejecutando. Si es así, es posible que deba modificarse el servicio de datos para que utilice un nombre de host lógico en lugar de uno físico. En este sentido, un nombre de host lógico es aquél que se configura en un recurso de nombre de host lógico ubicado en el mismo grupo que el recurso de la aplicación.
En ocasiones, en el protocolo cliente-servidor de un servicio de datos, el servidor devuelve su propio nombre de host 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 host devuelto, el cual, para que resulte utilizable tras una operación de recuperación de errores o conmutación, debería ser un nombre de host lógico del grupo de recursos, no el nombre de host físico. En este caso, es necesario modificar el código del servicio de datos para devolver el nombre de host lógico al cliente.
Hosts multienlace
El término host multienlace describe un host ubicado en más de una red pública. Un sistema así tiene varios nombres de host y direcciones IP. Tiene una combinación de nombre de host y dirección IP para cada red. Sun Cluster está diseñado para permitir que un host 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 de host físico tiene varios pares de nombre de host y dirección IP, cada grupo de recursos puede tener también varios pares de estos elementos para cada red pública. Cuando Sun Cluster transfiere un grupo de recursos de un host físico a otro, también se transfiere el conjunto completo de pares de nombre de host y dirección IP de ese grupo.
Este conjunto de pares del grupo de recursos se configura en forma de recursos de nombre de host lógico incluidos en el grupo. El administrador del clúster especifica estos recursos de dirección de red al crear y configurar el grupo de recursos. La API del servicio de datos de Sun Cluster contiene utilidades para consultar los pares de nombre de host y dirección IP.
La mayoría de los daemons de servicios de datos ya preparados, que se han escrito para el sistema operativo Solaris, administran adecuadamente los hosts multienlace. 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 enlaza eficazmente a todas las direcciones IP configuradas actualmente en la máquina. No es necesario modificar un daemon del servicio de datos que utilice INADDR_ANY para administrar las direcciones de red lógicas de Sun Cluster.
Enlace a INADDR_ANY en contraposición al enlace a las direcciones IP específicas
Aun cuando se utilicen hosts 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. La máquina sólo dispone de una dirección IP para su propio host físico y una dirección IP adicional para cada recurso de dirección de red (nombre de host lógico) 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 funcionan correctamente en Sun Cluster al enlazarse a 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 necesiten esta función, debe declararse la propiedad Network_resources_used en el archivo RTR del tipo de recurso.
Cuando RGM ponga en línea o fuera de línea el grupo de recursos, esta herramienta seguirá un orden específico para la instalación y desintalación, y la activación y desactivación de las direcciones de red en relación al momento en que RGM llama a los métodos de los recursos del servicio de datos. Consulte Selección de los métodos Start y Stop que deben utilizarse.
Cuando se devuelva el método Stop del servicio de datos, éste debe detenerse utilizando 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 logran su cometido mediante la desactivación y reinicio de los daemons del servicio de datos, este servicio se detendrá e iniciará correctamente mediante las direcciones de red.
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 host 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 ya pueden manejar el caso de la caída y reinicio de un único servidor, también podrán encargarse de que se produzca una recuperación de fallos o una conmutación del grupo de recursos que los contiene. 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.
- © 2010, Oracle Corporation and/or its affiliates