Seleccione el tipo de despliegue Atómico o Agrupado.
Utilice el despliegue agrupado para sustituir las ediciones en miembros del clúster de destino de un grupo de uno. El despliegue de grupo es la opción más típica y es muy útil cuando el clúster contiene cuatro o más miembros.
De modo alternativo, puede realizar un despliegue de
grupo con un tamaño de grupo específico mediante scripts. Si desea más información, consulte Tareas administrativas de gestión de ediciones de aplicaciones
. Cuando la nueva edición esté disponible durante el
despliegue de grupo, todas las solicitudes se dirigen a la nueva edición.
Utilice el despliegue atómico para sustituir una
edición por otra en mitad del clúster en un instante de tiempo.
Este tipo de despliegue atiende a todas las solicitudes de usuario con una edición coherente de la aplicación. Dado que todas las solicitudes de usuario se sirven como una edición coherente, el clúster se ejecuta a mitad de su capacidad. Si el clúster tiene cuatro o más miembros,
considere dividir el clúster en grupos más pequeños realizando un despliegue de grupo. También se puede utilizar la modalidad atómica con un único destino de despliegue de servidor. En un solo destino de despliegue del
servidor, las acciones que se realizan con la segunda mitad del clúster se omiten. Si detiene los destinos de despliegue antes de iniciar el despliegue atómico, los destinos de despliegue se inician cuando la nueva edición sustituye la edición activa independientemente de la estrategia de restablecimiento que elija.
Este procedimiento proporciona una mayor disponibilidad a las solicitudes a las que se presta servicio durante el periodo de despliegue.
Impedir problema: Antes de realizar un despliegue atómico,
determine la capacidad de carga del clúster de servidores de destino. Un despliegue atómico activa la nueva edición en primer lugar en la mitad del clúster y, a continuación, activa la edición en la otra mitad restante del clúster. Mientras la primera mitad del clúster
está fuera de línea y actualizada, las solicitudes de aplicación se direccionan a la segunda mitad del clúster. Verifique que la mitad del clúster puede manejar toda la carga durante el periodo de despliegue.
gotcha
Seleccione la estrategia de restablecimiento.
La estrategia de restablecimiento indica al gestor de ediciones de aplicaciones cómo cada destino de despliegue carga la nueva edición en el motor de ejecución del servidor. Utilice una estrategia Suave para restablecer la aplicación deteniendo o reiniciando la aplicación en cada servidor del clúster, a medida que la siguiente edición sustituye la antigua edición de ese servidor. El restablecimiento suave es la opción más típica y el restablecimiento de aplicación con un rendimiento óptimo porque carga la nueva edición reciclando la aplicación en el servidor de aplicaciones en ejecución. El servidor permanece
encendido durante este proceso. Con el restablecimiento suave, no se descargan las bibliotecas nativas de la memoria. El
restablecimiento suave es seguro generalmente para aplicaciones que no utilizan bibliotecas
nativas. Cuando se utilice un restablecimiento suave en un entorno de producción,
supervise el proceso del servidor de aplicaciones para asegurarse de que haya suficiente
memoria virtual.
Una estrategia de restablecimiento drástico recicla cada uno de los servidores de aplicaciones del clúster al completo ya que la edición siguiente sustituye la edición anterior en el servidor y se renuevan la memoria de procesos y también las bibliotecas nativas que utiliza la aplicación. Esta estrategia impide que se agote el almacenamiento virtual y permite cargar nuevas versiones de bibliotecas nativas. Seleccione el restablecimiento duro como estrategia de restablecimiento cuando realice un despliegue en una edición que dependa de nuevas versiones de bibliotecas nativas u otras dependencias que sólo se renuevan reciclando todo el servidor de aplicaciones, o si tiene aplicaciones mayores que
consumen mucha memoria para la compilación JIT (Just-In-Time).
Establezca el intervalo de drenaje en segundos.
El intervalo de drenaje permite que se complete el tiempo de las sesiones HTTP antes de que se restaure la aplicación o el servidor. El intervalo de drenaje especifica el período de tiempo que espera el gestor de ediciones de aplicaciones antes de iniciar la estrategia de restablecimiento.
Las afinidades como, por ejemplo, la transición, la actividad y el ámbito de compensación y las actividades desconocidas para WebSphere Virtual Enterprise, alargan el intervalo de drenaje efectivo porque el servidor no se detiene hasta que se completen estas unidades de trabajo. Las aplicaciones con actividades desconocidas para WebSphere Virtual Enterprise pueden utilizar la notificación iniciada de inmovilización del MBean AppEditionManager
como un desencadenante para empezar el proceso de finalización y aprovechar
el intervalo de drenaje como un periodo de tiempo durante el cual completar la finalización. Este proceso no es necesario para las sesiones persistentes, por ejemplo, las que se copian en la base de datos o se duplican a través del DSR (Distributed Resource Scheduler) de VMware, pero es importante para las sesiones
transitorias (en memoria).
El objetivo del intervalo de drenaje es permitir que se completen las solicitudes con
afinidades y las solicitudes en curso.
Para evitar la pérdida de sesiones
transitorias, establezca el intervalo de drenaje para que sea mayor que el intervalo
de tiempo de espera de sesiones de aplicación. Una vez iniciado el despliegue, a medida que se actualiza cada servidor, se marca el servidor como no seleccionable para comenzar sesiones nuevas. Establezca este valor en 0 para no esperar a que finalicen
las sesiones.
Para un restablecimiento suave, el gestor de inmovilización de ediciones de aplicaciones
espera la longitud completa del intervalo de drenaje para asegurarse de que se pueden completar las sesiones existentes. El gestor de inmovilización de ediciones de aplicaciones espera si existen sesiones pendientes o si las sesiones se completan antes del tiempo del intervalo de drenaje definido.
Para el restablecimiento duro, el gestor de inmovilización de ediciones de aplicaciones podría no esperar la longitud completa del intervalo de drenaje. Las estadísticas de PMI (Performance Monitoring
Infrastructure) están disponibles para el gestor de inmovilización para determinar si todas las solicitudes activas de un servidor se han inmovilizado.
Si todas las solicitudes se han inmovilizado antes del intervalo de drenaje, el gestor de inmovilización de ediciones de aplicaciones no tendrá que esperar el intervalo de drenaje completo.
El intervalo de drenaje permite completar las sesiones existentes. Sin embargo, al final del intervalo de drenaje, existe un periodo de tiempo durante el cual las solicitudes en curso pueden seguir llegando.
En dichos casos, el direccionador On Demand (ODR) proporciona un valor de tiempo de espera de
60 segundos dentro del cual completar la operación e inmovilización. Si las solicitudes finalizando dentro de 60 segundos o caducan los 60 segundos, la aplicación o el servidor, en el caso de una estrategia de restablecimiento duro, se detiene. A continuación, las solicitudes en curso siguen sin finalizar, WebSphere Application Server Network Deployment proporciona un tiempo de inmovilización de 60 segundos antes de detener la aplicación o la instancia del servidor.
Para estrategias de restablecimiento duro, WebSphere Application Server Network Deployment proporciona un tiempo de interrupción de 180 segundos antes de detener la instancia del servidor.
Puede utilizar la propiedad personalizada com.ibm.ws.webcontainer.ServletDestroyWaitTime para definir la cantidad de tiempo que espera el contenedor web para que se completen las solicitudes. Si desea más información, consulte Propiedades personalizadas del contenedor web.
Puede utilizar la propiedad personalizada
com.ibm.ejs.sm.server.quiesceTimeout para definir la cantidad de tiempo que espera la instancia del servidor hasta que se completan las solicitudes antes de iniciar la conclusión.
Para obtener más información, consulte Propiedades personalizadas de la máquina virtual Java. Debe definir las propiedades personalizadas
com.ibm.ws.webcontainer.ServletDestroyWaitTime y com.ibm.ejs.sm.server.quiesceTimeout en cada instancia del servidor en el que que desplieguen las ediciones de aplicaciones.