Cuando se realiza un despliegue en una edición, se sustituye una edición activa por una nueva edición.
La nueva edición podría ser una simple modificación de la aplicación, o contener un cambio más sustancial.
Si la nueva edición es compatible con versiones anteriores, podrá realizar un despliegue
para sustituir la edición activa sin afectar a los clientes existentes.
Para realizar el despliegue en una nueva edición, en primer lugar, debe instalar la edición de la aplicación con la información de la nueva edición.
Antes de empezar
Debe tener una edición de aplicación que esté instalada e iniciada, y tener los privilegios de
configurador o
administrador para realizar un despliegue.
- El despliegue falla cuando dos ID de usuario en dos consolas administrativas intentan completar el proceso en paralelo.
- Ajuste las propiedades del conector
SOAP para definir el valor de tiempo de espera de la solicitud para el gestor de despliegue para que sea mayor que el tiempo total necesario para realizar un despliegue en el sistema y reiniciar el gestor de despliegue.
Si no se define la propiedad es posible que falle el proceso de despliegue cuando caduque
el valor de requestTimeout.
La fórmula para calcular el valor para definir es número-de-grupos-para-desplegar * (intervalo-drenaje + tiempos-de-espera-inactividad-interna-aproximadamente-5minutos + tiempos-reinicio-aplicación-o-servidor-aproximadamente-10minutos).
De forma alternativa, puede definir el valor en cero para inhabilitar el tiempo de espera.
- Si está realizando un despliegue dentro de la consola de administración, defina la caducidad de sesión para la consola de administración en un valor mayor que la cantidad de tiempo necesaria para que finalice todo el proceso de despliegue.
Multiplique el valor de tiempo de espera de solicitud por el número de grupos procesados durante el despliegue.
Para obtener más información sobre la caducidad de la sesión de la consola de administración, consulte el tema sobre cambiar la caducidad de la sesión de la consola.
- Debe definir una política de direccionamiento de varios clústeres para cada nueva edición que instale antes de poder realizar un despliegue.
Utilice las tareas administrativas para añadir las políticas de direccionamiento de varios clústeres para nuevas ediciones.
Para obtener más información acerca de las políticas de direccionamiento de varios
clústeres, consulte el tema sobre las reglas para las tareas administrativas de políticas
de direccionamiento de ODR.
Acerca de esta tarea
También puede utilizar el gestor de ediciones de aplicación si desea realizar
un despliegue en aplicaciones por lotes.
Estas son aplicaciones Java Enterprise Edition 5 (Java EE 5) compatibles con uno de los modelos de programación de proceso por lotes.
Procedimiento
- Instale la nueva edición. Utilice los mismos pasos que se
describen en la instalación de una edición de aplicaciones, pero especifique la
información de la edición nueva.
Por ejemplo, escriba 2.0 en el campo Edición de la aplicación y Segunda edición en el campo Descripción de la edición.
Seleccione los mismos destinos de despliegue que se utilizan para la edición actual.
- Guarde y sincronice los nodos.
- Especifique los valores de despliegue. Pulse . Seleccione la nueva edición, por ejemplo, 2.0, y pulse Desplegar.
Especifique los valores siguientes para empresa o para otras aplicaciones de
middleware:
- 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.
Para obtener más información
sobre el despliegue de grupo, consulte el tema sobre las 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 cada vez.
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.
Avoid trouble: 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 de restablecimiento 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 activo 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 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 duro recicla
el servidor 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 Intelligent Management, alargan el intervalo de drenaje efectivo porque el servidor no se detiene hasta que se completan estas unidades de trabajo.
Las aplicaciones con actividades desconocidas para
Intelligent Management 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 se completa el proceso de conclusió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 DRS (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 esperar a que transcurra el intervalo de drenaje o a que se completen las sesiones
para las solicitudes en curso, establezca el intervalo de drenaje en un valor mayor que 0.
Es posible que el gestor de inmovilización de ediciones de aplicaciones no
espere el periodo completo 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.
Para forzar un restablecimiento suave para esperar el
intervalo de drenaje completo, puede establecer la propiedad del sistema
appedition.rollout.softreset.fulldrainageinterval en true en el gestor de despliegue.
El intervalo de drenaje permite completar las sesiones existentes.
Sin embargo, al final del intervalo de drenaje, existe un periodo durante el cual las
solicitudes en curso pueden seguir llegando.
En estos 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, si las solicitudes en curso continúan 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 las estrategias de restablecimiento drástico, WebSphere Application Server Network Deployment proporciona un tiempo de inactividad
de 180 segundos antes de detener la instancia de 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.
Para
obtener más información, consulte el tema sobre las propiedades personalizadas de
contenedor web.
Puede utilizar la propiedad personalizada
com.ibm.ejs.sm.server.quiesceTimeout para definir el periodo de tiempo que espera la
instancia de servidor a que se completen las solicitudes antes de iniciar la
conclusión.
Para obtener más información
sobre esta propiedad de tiempo de espera, consulte la información sobre las propiedades personalizadas de máquina virtual
Java. Debe definir la propiedad personalizada
com.ibm.ws.webcontainer.ServletDestroyWaitTime y la propiedad
personalizada com.ibm.ejs.sm.server.quiesceTimeout en cada una de las
instancias de servidor en las que se despliegan las ediciones de aplicación.
Especifique los valores siguientes para las aplicaciones SIP (Session Initiation
Protocol):- Seleccione una estrategia de inmovilización. La estrategia de inmovilización especifica cómo se suprimen los servidores antiguos o miembros del clúster que alojan la edición actual.
Este valor no afecta a la nueva edición que se está desplegando.
- Inmovilizar el servidor o miembros de clúster después de que se completen todas las
sesiones activas o diálogos:
- Elimina el servidor o el miembro de clúster cuando se han completado todas las sesiones activas o diálogos del servidor o miembro del clúster.
- Inmovilizar servidores o miembros del clúster después del intervalo:
- Suprime el servidor o miembro del clúster después de un período de tiempo especificado.
Especifique un período de tiempo, en segundos, minutos u horas.
Atención: No está soportado un despliegue para las aplicaciones
SIP que se despliegan en un clúster dinámico que se ha convertido a partir de un clúster dinámico.
- Inicie el despliegue. Pulse Aceptar.
Esta acción inicia una sustitución
sin interrupciones de la edición anterior por la nueva edición.
Resultados
Para una edición que no está en modalidad de validación, la nueva edición sustituye la edición actual después de que se haya completado el despliegue.
Una edición que está en validación se despliega en el destino de despliegue original y se suprime el entorno clonado.
Las reglas de direccionamiento se actualizan para iniciar el direccionamiento a la nueva
edición.
Durante el proceso de despliegue de aplicaciones, los errores que se
producen en el primer grupo de destinos se manejan de forma diferente que los errores que
se producen en los grupos más adelante.
En despliegues atómicos, el primer grupo es la
primera mitad de los destinos donde se activa la nueva edición.
En despliegues de grupo,
el primer grupo hace referencia al primer grupo de destinos donde se ha activado la nueva
edición.
Si se produce un error durante el despliegue del primer grupo de destinos (por
ejemplo una aplicación o un servidor no se inicia), el proceso de despliegue falla.
La
edición de la aplicación actual permanece en estado activo.
Si se produce un error después
del despliegue en el primer grupo de destinos, el proceso de despliegue se completa
satisfactoriamente.
La nueva edición de aplicación está ahora en estado activo.
La
edición de la aplicación antigua pasa a estado inactivo.
Qué hacer a continuación
Para validar los resultados, pulse .
La nueva edición es la edición activa en el destino de despliegue.
Se inicia automáticamente la nueva edición, porque
sustituye a una edición en ejecución.
Cuando se realiza un despliegue en una edición en la modalidad de validación, los nombres de enlace se vuelven a cambiar a los valores originales.
Por ejemplo, /clusters/cluster1-validation/jdbc/CustomerData se vuelva a cambiar a /clusters/cluster1/jdbc/CustomerData