Rendimiento y alta disponibilidad con WSO2.

Uno de los temas menos avanzados según lo que he visto en materia de arquitectura en algunas instituciones que he revisado son los de alta disponibilidad a través de la clusterización.

Concretamente en un trabajo realizado un colega de trabajo y yo hemos logrado configurar un entorno de clusterización basado en el enfoque actual de WSO2:

1. Se usa el ELB o Elastic Load Balancer para el tema del balanceo de carga. Algo interesante es que 1 solo ELB puede servir para diferentes clústeres de las herramientas de WSO2.
2. Se pueden configurar dominios y subdominios en cada herramienta en dos configuraciones básicas: management y workers. Los management tienen la tarea de gestionar los artefactos clusterizados, sirve para añadir un artefacto, modificarlo o eliminarlo. Es quien escribe en el mecanismo de sincronización. Los workers son los que sirven a las peticiones realizadas al clúster y se actualizan del mecanismo de sincronización.
3. Como mecanismo de sincronización se usa el subversion, los management tienen permiso de escritura y los workers tienen permiso de lectura.

Pueden ver en esta imagen el esquema que hemos probado y la configuración básica en el ELB. En este caso hemos usado el Application Server de WSO2 versión 5.0.0 y el ELB versión 2.0.3.

Hemos montado un entorno local, lo que implica por un lado que no existe latencia en la red significativa pero por otro existe una limitación y competencia por los recursos de mi laptop.

Aquí pueden ver algunas corridas que he realizado desde un cliente en el Eclipse a un servicio desplegado en 1 manager, que no sirve a las peticiones, y 2 workers que si sirven las peticiones enviadas por el ELB. La cantidad de peticiones hechas es de 100 000.

Tengan en cuenta que tengo todo esto corriendo en 4GB lo siguiente:

1 ELB, 1 AS como manager, 3 AS como workers y una instancia del eclipse con un cliente del servicio. Este cliente ejecuta un ciclo de 100 000 peticiones.

Algunas gráficas de los datos anteriores.

Estoy esperando a poder montar este  esquema en un ambiente real. Donde cada nodo esté en un server diferente y tengamos la red de por medio para poder valorar realmente este despliegue.

Queremos implementar este esquema a nivel empresarial como parte de una Arquitectura de Integración que propongo.

Algunas pruebas de su funcionamiento hasta el momento son:

1. Balancear las peticiones entre nodos workers.
2. Añadir un nuevo nodo cuando se están procesando peticiones. Funciona muy bien.
3. Eliminar un nodo cuando se están procesando peticiones. Funciona muy bien.

Como el ELB es elástico, o sea que se puede configurar para que en función de la carga pueda agregar o eliminar nodos, una de las cosas más interesantes a realizar será probar esta funcionalidad.

Posted in alta disponibilidad, ELB, rendimiento, WSO2