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.

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.

• Tanto las aplicaciones habilitadas para red (modelo cliente-servidor) como las no habilitadas para red (sin cliente) son candidatas potenciales para convertirse en aplicaciones de alta disponibilidad y escalabilidad en el entorno Sun Cluster. Sin embargo, Sun Cluster no puede proporcionar una mayor disponibilidad en entornos en los que hay un reparto de tiempo, en los que las aplicaciones se ejecutan en un servidor al que se accede mediante telnet o rlogin.

• La aplicación debe ser tolerante a caídas del sistema. Es decir, debe recuperar datos del disco (si fuera necesario) cuando se reinicie después de una terminación de nodo inesperada. Además, el tiempo de recuperación tras una caída del sistema debe ser limitado. La tolerancia a caídas del sistema es un prerrequisito para hacer que una aplicación tenga una alta disponibilidad, porque la capacidad de recuperar el disco y reiniciar la aplicación es un problema que afecta a la integridad de los datos. El servicio de datos no es necesario para poder recuperar las conexiones.

• La aplicación no debe depender del nombre físico de servidor del nodo en el que se ejecuta. Consulte Nombres de sistema para obtener información adicional.

• La aplicación debe funcionar correctamente en entornos en los que se asignan múltiples direcciones IP; por ejemplo, entornos con sistemas principales con varios directorios iniciales, en los que el nodo está en más de una red pública y los entornos con nodos en los que se asignan múltiples interfaces lógicas en una sola interfaz de hardware.

• Para tener una alta disponibilidad, los datos de la aplicación deben residir en el sistema de archivos del clúster; consulte Datos de sistemas múltiples.

  Si la aplicación utiliza un nombre de ruta invariable para la ubicación de los datos, es posible cambiar la ruta por un enlace simbólico que señale hacia una ubicación del sistema de archivos del clúster, sin cambiar el código fuente de la aplicación. Consulte Utilización de vínculos simbólicos para la colocación de datos de varios sistemas para obtener información adicional.

• Las bibliotecas y binarios de aplicación pueden residir localmente, en cada nodo, o en el sistema de archivos del clúster. La ventaja de residir en el sistema de archivos del clúster es que basta una única instalación. La desventaja es que el despliegue de las actualizaciones se vuelve problemático, porque los binarios están en uso mientras se ejecuta la aplicación bajo el control de RGM.

• El cliente debería tener cierta capacidad para reintentar automáticamente una consulta si se agota el tiempo de espera del primer intento. 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. Consulte Reintento del cliente para obtener información adicional.

• La aplicación no debe tener zócalos de dominio Unix ni conducciones con nombres en el sistema de archivos del clúster.

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

• La aplicación debe poder ejecutarse en varias instancias, que trabajen, todas ellas, con los mismos datos de aplicación del sistema de archivos del clúster.

• La aplicación debe ofrecer coherencia de los datos para un acceso simultáneo desde múltiples nodos.

• La aplicación debe implementar un bloqueo suficiente, con un mecanismo visible desde cualquier punto, como el sistema de archivos del clúster.

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.