WAS NetWork Deployment en Pocas Palabras

Parte importante de la infraestructura (plataforma) que soporta a SOA y BPM son lo servidores de aplicaciones, y las aplicaciones sobre estas tecnologia demanda alta disponibilidad y un alto desempeño, por lo tanto deben contemplar una configuración adecuada. A continuación analizaremos los principales conceptos de una plataforma de este tipo, y especialmente nos centraremos en como lo maneja la solución de IBM.

El WebSphere Application Server Network Deployment (WAS ND) es una configuración que provee: alta disponibilidad (HA High Availability), tolerancia a fallas (FailOver), mejoras de desempeño (performance), mejoras de Seguridad, y escalabilidad (simplifica crecimiento servidores). Esto a través de:

§ manejo de clúster

§ balanceo de carga (WLM WorkLoad Management)

§ WebServices GateWay (versión 6.0)

§ manejo de cache (antememoria) para los recursos Web y J2ee (java).

§ Backup Clúster

WAS ND puede manejar varios nodos (servidores WAS), en cada nodo puede haber varios servidores de aplicaciones (lógicos), y en cada servidor varias aplicaciones.

WebSphere Application Server Network Deployment

Alta Disponibilidad a nivel de Servidor de Aplicaciones, hay que destacar que WAS-ND es una solución para manejo de clúster de servidores de aplicaciones, no para servidores Web (IBM Http Server) para este último existen otros productos o tecnología como IP Sprayer , o WebSphere Edge Server. Luego WAS-HD esta orientado a distribuir las solicitudes (request) J2EE: Servlet Request , y EJB request.

Clusters conjunto de servidores de aplicaciones (lógicos) que tienen instaladas las mismas aplicaciones, cada clúster es un clon de un servidor de aplicaciones (lógico), un clúster sirve para balanceo de carga (WLM), y alta disponibilidad.

Celda (cell) aquí corresponde al conjunto (dominio) de nodos según una agrupación lógica con el fin de facilitar la administración, por ejemplo sirve para sincronizar los clusters (clones de Serv. app lógicos).

Deployment Manager es el panel de control y de administración del ambiente WAS-ND, el Deployment Manager es un WAS de administración, pero “no” participa directamente en la distribución de los request (Servlet o EJB Request), luego este modulo no participa directamente en balanceo de carga, son otros los componeles de WAS-ND que participan en la distribución de los request: el “HTTP PlugIn”, y el “WLM PlugIn”. El Deployment Manager es el encargado de sincronizar la configuración y el deployment entre los distintos nodos y clusters, luego su participación es en tiempo de deployment.

WAS Network Deployment WorkLoad

HTTP PlugIn modulo que se asocia al “Http Server”, encargado de rutear y balancear los Servlet Request. Este plugin determina que clúster (servidor app lógico clonado) atenderá el request según un esquema de balanceo de carga.

Balanceo Carga del Http Plugin si el request tiene “session” lo rutea directamente al clúster que esta manejando dicha session (para que no se pierda), si no tiene “session” entonces selecciona un clúster según un criterio de balanceo que se basa: en un peso especifico para cada clúster (que el usuario administrador asigna) y la carga de trabajo que tiene en el momento cada clúster, según esquema de round robin (recorrido circular).

Persistencia de Session, y Alta Disponibilidad: la session no se pierde porque siempre se asigna el mismo clúster, pero que sucede si ese clúster se encuentra abajo (el proceso o el nodo no responden), entonces se le debe asignar otro clúster. El WAS-ND maneja distintos esquemas para la persistencia de la session en estos casos: in memory (sin persistencia), in database (sesión en la base de datos), y memory2memory (a través de mensajes JMS). El problema es que la persistencia de datos degrada el performance, y no asegura consistencia 100%, además en el caso de la base datos agrega un punto falla: sin base de datos no hay sesiones, y el sistema no va a funcionar. Sin persistencia de sesión puede haber mejor performance con el manejo de clusters, pero “no” va haber alta disponibilidad al 100%(el usuario va a tener que volver a logearse). La persistencia de sesión se puede configurar a nivel de aplicación, o a nivel servidor de aplicación lógico (se define en un app server, y sesión compartida por clústeres).

WLM PlugIn es el modulo que se encarga de rutear y balancear los “EJB request”. Este plugin determina que clúster atenderá el request de acuerdo a un algoritmo de balanceo. Este modulo se encuentra en todo Nodo del WAS ND, porque en este caso un nodo puede ser cliente o servidor (clúster) de los EJB.

Balanceo Carga WLM PlugIn si el request tiene una transacción, se asigna al mismo clúster que inicio la transacción, si el request corresponde a un objeto existente en un clúster se le sigue asignando es clúster, si el request corresponde a la creación de un objeto entonces se le asigna un clúster según un esquema round robin (mismo de Http PlugIn), pero con la posibilidad de manejo de la siguiente condición previa (preferencias): “in Process” (mismo clúster cliente), “Prefer Local” (mismo nodo cliente).

Persistencia de EJB, y Alta Disponibilidad: existen 3 tipos de EJB los Entity Beans, los Session Bean Stateless, y los Session Bean Stateful, en los 3 casos se mantiene su persistencia debido a que siempre se asigna el mismo clúster en el cual se crearon, pero cuando ese clúster no responde se le asigna otro clúster, ¿Que pasa entonces con la persistencia del EJB?, la respuesta depende del tipo de EJB: si es Entity Bean no se pierde porque esta se mantiene en la base de datos, si es un Session Bean Stateless tampoco hay problema porque no hay nada que perder (no maneja datos en la sesión), pero si es Session Bean Stateful en WAS 6.0 se debe configurar un esquema memory2memory de persistencia, y en WAS 5.0 simplemente se pierde el estado de este session bean (usuario debe volver a logearse).

Escalabilidad Vertical: definir múltiples clones de un servidor de aplicaciones (lógico) en la misma maquina. En ciertos casos un servidor de app. que se implementa con un solo proceso JVM no utiliza todo el poder de la CPU llevando la carga de la cpu al 100%, la escalabilidad vertical permite crear múltiple procesos JVM, utilizando todo el poder de CPU, y obteniendo failover a nivel de procesos.

WAS Network Deployment Vertical Clusters

Escalabilidad Horizontal: definir múltiples clones de un servidor de aplicaciones (lógico) en distintas maquinas, esta solución incrementa el performance.

WAS Network Deployment Horizontal Clusters

Advertisements

2 thoughts on “WAS NetWork Deployment en Pocas Palabras

  1. Excelente post!
    Agradecería me indiques donde puedo encontrar la bibliográfica necesaria para poder configurar todo lo mencionado.

    Gracias.

    Like

  2. Excelente post!!! Muchas Gracias.
    Tengo una pregunta: ¿El WAS network deployment es un instalador aparte o ya viene dentro del instalador de WAS. ?

    Gracias

    Like

Comments are closed.