X

News, tips, partners, and perspectives for the Oracle Solaris operating system

Mejora de la disponibilidad de Sun Java System Application Server con Solaris Cluster

Guest Author

Introducción

Sun Java System Application Server es uno de los productos middleware líderes del mercado gracias a su sólida arquitectura, estabilidad y facilidad de uso. El diseño de Application Server cuenta con algunas funciones de alta disponibilidad (HA) en forma de agentes de nodo (NA) que se extienden en múltiples nodos para evitar un único punto de fallo (SPoF). Un ejemplo sencillo del diseño:




Sin embargo, tal y como podemos observar en el diagrama de bloques anterior, el servidor DAS (Domain Administration Server) no dispone de gran disponibilidad. Si el servidor DAS deja de funcionar, no se podrán realizar las tareas administrativas. A pesar de que las conexiones de clientes se desvían a otras instancias del clúster, en el caso de que se produzca un error NA o de instancia o falta de disponibilidad, sería aconsejable una recuperación automatizada para reducir la carga del resto de instancias del clúster. También se producen casos de error de red, SO y hardware que deben tenerse en cuenta en implementaciones fundamentales, en las que el tiempo de actividad supone uno de los requisitos principales.  

¿Por qué se necesita una solución de alta disponibilidad?

Se necesita una solución de alta disponibilidad para manejar los errores que Application Server o cualquier aplicación userland no pueda solucionar, como por ejemplo, errores de red, hardware y sistema operativo, así como errores humanos. Además, existen otros casos, como el suministro de servicio ininterrumpido incluso cuando se realizan actualizaciones y/o mantenimiento del SO o hardware.

Además de estos errores, una solución de gran disponibilidad contribuye a que la implementación saque el máximo partido de otras funciones del sistema operativo, como la distribución de carga de nivel de red, la detección de errores de enlace y la virtualización, etc.

¿Cómo decidir cuál es la mejor solución?

Una vez que los clientes deciden que su implementación será mejor atendida por una solución de alta disponibilidad, deben decidir qué solución del mercado elegir. La respuesta a las siguientes preguntas ayudará a la hora de tomar una decisión:

¿Es la solución muy sólida y estable?

¿El proveedor ofrece un Agente que está diseñado especialmente para Sun Java System Application Server?

¿La solución puede utilizarse e implementarse de forma sencilla?

¿La solución resulta económica?

¿Es la solución completa? ¿Puede ofrecer alta disponibilidad para componentes asociados, tales como
Cola de mensajes?

Y lo más importante, ¿pueden obtener una excelente ayuda en forma de documentación, servicio de atención al cliente y un único punto de asistencia?

¿Por qué elegir Solaris Cluster?


Solaris Cluster es la mejor solución de alta disponibilidad para la plataforma Solaris. Ofrece una excelente integración con el Sistema Operativo Solaris y ayuda a los clientes a utilizar nuevas funciones introducidas en Solaris sin realizar modificaciones en sus implementaciones. Solaris Cluster admite aplicaciones que se ejecutan en contenedores, ofrece un gran abanico de sistemas de archivos que pueden utilizarse, opciones de arquitectura de procesadores, etc. Entre algunas de las características principales se incluyen:

Integración a nivel nuclear para utilizar funciones de Solaris como contenedores, ZFS, FMA, etc.

Una amplia cartera de agentes para proporcionar asistencia sobre las aplicaciones más utilizadas del mercado.

Mecanismo de detección de errores rápido y muy sólido y estabilidad incluso durante grandes cargas.

Equilibrio de carga y detección de errores de red basados en IPMP.

Se puede utilizar el mismo agente tanto para Sun Java Application Server como para Glassfish.

Asistentes de configuración de servicios de datos para las tareas más comunes de Solaris Cluster.

Mecanismo de cercado sofisticado para evitar la corrupción de datos.

Detección de pérdida de acceso al almacenamiento supervisando las rutas de discos.

¿Cómo ofrece Solaris Cluster una disponibilidad alta?

Solaris Cluster ofrece una alta disponibilidad utilizando componentes redundantes. El almacenamiento, el servidor y la tarjeta de red son redundantes. La siguiente ilustración muestra un clúster sencillo de dos nodos que cuenta con las interconexiones redundantes recomendadas, almacenamiento accesible a ambos nodos e interfaces de red públicas. Es importante tener en cuenta que esta es la configuración recomendada y que la configuración mínima puede contar con un solo almacenamiento compartido, interconexión e interfaz de red pública. Solaris Cluster ofrece incluso la flexibilidad de contar con un clúster de un único nodo que además se basa en las necesidades individuales.

LH =  nombre de host lógico, tipo de IP virtual utilizada para trasladar direcciones IP en NIC.

RAID =  cualquier mecanismo RAID basado en software o hardware apropiado que ofrece redundancia y rendimiento.

Se puede optar por proporcionar una disponibilidad alta sólo para el servidor DAS o también para el agente de nodos. La elección se basa en el entorno. La escalabilidad de los agentes de nodos no constituye un problema gracias las implementaciones de alta disponibilidad, dado que pueden implementarse varios agentes de nodos en una única instalación de Solaris Cluster. Estos agentes de nodos se configuran en varios grupos de recursos, cada uno de los cuales cuenta con un único host lógico, HAStoragePlus y recurso de nodos de agentes. Dado que los agentes de nodos se extienden en varios nodos en una implementación normal, no es necesario hardware adicional, ya que se está utilizando una arquitectura de alta disponibilidad. El almacenamiento puede convertirse en redundante con RAID basado en software o hardware.

Pasos en la conmutación por error de Solaris Cluster en caso de error

Solaris Cluster ofrece un conjunto de algoritmos sofisticados que se aplican para determinar si es necesario reiniciar una aplicación o conmutar el nodo redundante. Habitualmente, la dirección IP, el sistema de archivos en el que residen los datos y binarios de la aplicación y el recurso de aplicaciones se agrupan en una entidad lógica denominada grupo de recursos (RG). Tal y como el nombre sugiere, la dirección IP, el sistema de archivos y la propia aplicación se consideran recursos y cada uno se identifica por un tipo de recurso (RT) considerado normalmente como agente. El mecanismo de recuperación, por ejemplo, el reinicio o la conmutación por error a otro nodo, se determina según una combinación de tiempos de inactividad, número de reinicios e historial de conmutaciones por error. Por lo general, un agente debe iniciar, detener y validar métodos que se utilizan para iniciar, detener y verificar requisitos previos cada vez que la aplicación cambia de estado. También incluye una prueba que se ejecuta en un periodo de tiempo predeterminado para determinar la disponibilidad de la aplicación.

Solaris Cluster cuenta con dos RT o agentes para Sun Java System Application Server.  El tipo de recurso SUNW.jsas se utiliza para el servidor DAS y SUNW.jsas-na, para el agente de nodos. El mecanismo de prueba implica la ejecución de los comandos ?asadmin list-domain? y ?asadmin list-node-agents? y la interpretación de la salida para determinar si el servidor DAS y los agentes de nodos se encuentran en el estado deseado. El software Application Server, el sistema de archivos y la dirección IP se trasladan al nodo redundante en el caso de se produzca una conmutación por error. Consulte la guía de Servicios de datos de Sun Cluster (http://docs.sun.com/app/docs/doc/819-2988) para obtener información adicional.

A continuación, se muestra un ejemplo sencillo de conmutación por error en caso de que el servidor deje de funcionar.
 

En la configuración mencionada anteriormente, Application Server no se conmuta por error al segundo nodo si
uno de los NIC falla. El NIC redundante, que forma parte del mismo grupo de IPMP, aloja al host lógico que los servidores DAS y NA utilizan. Se observará un retraso de red temporal hasta que el host lógico se desplace de nic1 a nic2.

En las implementaciones de Application Server se recomienda utilizar el sistema de archivos global (GFS), dado que la actividad de escritura es escasa a parte de los registros en el sistema de archivos, en el que se instalan los archivos de configuración y, en determinadas implementaciones, los archivos binarios. Dado que GFS se instala siempre en todos los nodos, se obtiene mejores tiempos de conmutación por error y un inicio más rápido de Application Server en caso de que se produzca un error en el nodo o problemas similares.

Mantenimiento y actualizaciones

Las mismas propiedades que ayudan a Solaris Cluster a proporcionar una recuperación en el caso de que se produzca un fallo pueden utilizarse para ofrecer continuidad de servicio en caso de que se realicen tareas de mantenimiento y actualización. 

Durante cualquier actualización o mantenimiento de SO planificado, los RG se cambian al nodo redundante y el nodo que necesita mantenimiento se reinicia en el modo de no clúster. Se realizan las acciones planificadas y el nodo se reinicia en el clúster. Se puede repetir el mismo procedimiento para el resto de nodos del clúster.

El mantenimiento o actualización de Application Server depende del modo en que se almacenen los binarios y los archivos de datos y de configuración. 

1.) Almacenamiento de los binarios en el disco duro interno del nodo y almacenamiento de archivos relacionados con el agente de nodos y del dominio en el almacenamiento compartido. Se recomienda este método para entornos en los que se necesita realizar actualizaciones frecuentemente. La desventaja es la posibilidad de inconsistencia en los binarios de la aplicación, debido a diferencias en los parches o actualizaciones

2.) Almacenamiento de binarios y datos en el almacenamiento compartido. Este método proporciona datos consistentes en todo momento, pero hace que sea difícil llevar a cabo actualizaciones y mantenimiento sin que se produzcan interrupciones.

Debe realizarse la elección teniendo en cuenta los procedimientos y procesos que sigue la organización.

Otras funciones

Solaris Cluster proporciona también funciones que pueden utilizarse en servicios de colocación basados en el concepto de afinidades. Por ejemplo, puede utilizar afinidad negativa para evacuar el entorno de prueba si un entorno de producción se cambia a un nodo o utilizar afinidad positiva para desplazar los recursos de Application Server en el mismo nodo en el que se aloja el servidor de bases de datos para obtener así mayor rendimiento, etc.

Solaris Cluster dispone de una herramienta de administración de GUI intuitiva y fácil de utilizar denominada Sun Cluster Manager, que puede utilizarse para llevar a cabo la mayoría de las tareas de administración.

Solaris Cluster cuenta con una función integrada de telemetría que puede utilizarse para supervisar el uso de recursos, tales como la CPU, la memoria, etc.


Sun Java Application Server no requiere ninguna modificación para Solaris Cluster, ya que el agente está pensado para esta situación.

También se puede utilizar el mismo agente para Glassfish.

Message Queue Broker también puede estar disponible gracias a la alta disponibilidad (HA) del agente Sun Java Message Queue.

De acuerdo con la filosofía de Sun, se ha liberado el código abierto del producto en fases y los agentes ya están disponibles con la licencia CDDL.

Está disponible un producto de código abierto basado en el mismo código para las versiones de OpenSolaris denominadas Clúster de alta disponibilidad abierto. Para obtener información adicional acerca del producto y la comunidad, visite http://www.opensolaris.org/os/communities/ohac .

El producto de código abierto incluye también un completo conjunto de pruebas que ayuda a los usuarios a probar la implementación de forma satisfactoria. Para obtener información adicional, consulte el http://opensolaris.org/os/community/ha-clusters/ohac/Documentation/Tests/.


Resumen

Para entornos fundamentales, contar con disponibilidad frente a todos los tipos de errores supone un criterio muy importante. Solaris Cluster tiene el diseño más apropiado para ofrecer la más alta disponibilidad para Application Server en virtud de su integración con el SO de Solaris y su estabilidad, además de contar con un agente diseñado especialmente para Sun Java System Application Server.
 

Madhan Kumar
Ingeniería de Solaris Cluster

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.