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.

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

• Tanto las aplicaciones habilitadas para red (modelo cliente-servidor) como las no habilitadas para red (sin cliente) son candidatas potenciales para ofrecer alta disponibilidad o escalabilidad. Sin embargo, Sun Cluster no puede proporcionar una mayor disponibilidad en entornos de tiempo compartido en el 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 un bloqueo del sistema debe ser limitado. La tolerancia a bloqueos del sistema es un requisito previo 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. No es necesario que el servicio de datos sea capaz de recuperar conexiones.

• La aplicación no debe depender del nombre de host físico del nodo en el que se esté ejecutando. Consulte Nombres de host para obtener más información.

• La aplicación debe funcionar correctamente en entornos en los que se configure la activación de varias 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 configura la activación de múltiples interfaces lógicas en una sola interfaz de hardware.

• Para ofrecer alta disponibilidad, la aplicación debe ubicarse en los sistemas de archivos del clúster. Consulte Datos de hosts múltiples.

  Si la aplicación utiliza un nombre de ruta inalterable para la ubicación de los datos, puede cambiar esa ruta por un vínculo símbolico que señale a la ubicación del archivo del clúster. Consulte Utilización de vínculos simbólicos para la colocación de datos de varios hosts para obtener más información.

• Los binarios y las bibliotecas de la aplicación pueden ubicarse en cada nodo o en el sistema de archivos del clúster. Esta última ubicación ofrece la ventaja de que sólo es necesaria una instalación. Por el contrario, su mayor inconveniente es que, al realizar una actualización por turnos, los binarios se estarán utilizando mientras la aplicación se esté ejecutando 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 controlar una situación de bloqueo y reinicio de un único servidor, también podrán encargarse de que se realice una recuperación ante fallos o una conmutación del grupo de recursos que los contiene. Consulte Reintento del cliente para obtener más información.

• La aplicación no debe tener sockets de dominio UNIX® ni conducciones con nombres en el sistema de archivos del clúster.

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

• La aplicación debe poder ejecutarse en varias instancias, que trabajen, todas ellas, con los mismos datos de aplicación del sistema de archivos de 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 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.