WebSphere Virtual Enterprise, Version 6.1.1
             Sistemas operativos: AIX, HP-UX, Linux, Solaris, Windows


Realización de un despliegue en una edición

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. Siempre y cuando la nueva edición sea compatible con versiones anteriores, podrá realizar un despliegue para sustituir la edición activa sin repercutir en 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 comenzar

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.
Impedir problema: El despliegue falla cuando dos ID de usuario en dos consolas administrativas intentan completar el proceso en paralelo. gotcha
Impedir problema: Ajuste las propiedades del conector SOAP para establecer el valor de tiempo de espera de la solicitud para que el gestor del despliegue sea superior al tiempo total necesario para llevar a cabo un despliegue de supresión en el sistema e inicie el gestor de despliegue. Si no se define la propiedad puede hacer que el proceso de despliegue de supresión falle cuando caduque el valor requestTimeout. La fórmula para calcular el valor que se debe establecer es número-de-grupos-a-desplegar * (intervalo-drenaje + tiempo-espera-inmovilización-interna-aproximadamente-5minutos + hora-reinicio-aplicación-o-servidor-aproximadamente-10minutos). De forma alternativa, puede establecer el valor en cero para inhabilitar el tiempo de espera.
  • Si está realizando el despliegue de supresión utilizando la herramienta wsadmin, ajuste el valor del tiempo de espera de solicitud definiendo la propiedad com.ibm.SOAP.requestTimeout en soap.client.props en el perfil del gestor de despliegue. El valor predeterminado es de 180 segundos y se debería aumentar adecuadamente.
  • Si está llevando a cabo el despliegue de supresión utilizando la consola administrativa, ajuste el valor de tiempo de espera de solicitud pulsando Administración del sistema > Gestor de despliegue > Servicios de administración > Conectores JMX > SOAPConnector > Propiedades personalizadas > requestTimeout. El valor predeterminado es de 600 segundos y se debería aumentar adecuadamente.
Para obtener más información, consulte Propiedades del conector Java Management Extensions.gotcha

Si está llevando a cabo un despliegue de supresión en la consola administrativa, defina la caducidad de la sesión de la consola administrativa en un valor superior a la cantidad de tiempo necesario para que finalice todo el proceso de despliegue de supresión. Multiplique el valor de tiempo de espera de solicitud por el número de grupos procesados durante el despliegue de supresión. Para obtener más información, consulte Cambio de la caducidad de la sesión de consola.

[Version 6.1.1 and later] Impedir problema: Debe definir una política de direccionamiento de varios clústeres para cada edición nueva que instale antes de llevar a cabo un despliegue de supresión. Utilice las tareas administrativas para añadir políticas de direccionamiento de varios clústeres para sus ediciones nuevas. Si desea más información, consulte Reglas para las tareas administrativas de política de direccionamiento de ODR . gotcha

Acerca de esta tarea

También puede utilizar el gestor de ediciones de aplicaciones si utiliza el componente Compute Grid y desea realizar un despliegue en aplicaciones de Compute Grid. Estas son aplicaciones Java Enterprise Edition 5 (Java EE 5) que se ajustan a uno de los modelos de programación de cuadrícula.

Procedimiento

  1. Instale la nueva edición. Utilice los mismos pasos que se describen en Instalación de ediciones , pero especifique la información de la nueva edición. 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.
  2. Guarde y sincronice los nodos.
  3. Especifique los valores de despliegue. Pulse Aplicaciones > Centro de control de ediciones > nombre_aplicación. Seleccione la nueva edición, por ejemplo, 2.0, y pulse Desplegar.

    Especifique los valores siguientes para empresa o para otras aplicaciones de middleware:

    1. 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
    2. 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).

    3. 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.

    Especifique los valores siguientes para las aplicaciones SIP (Session Initiation Protocol):
    1. 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 la nueva edición que se está desplegando.
      • Inmovilizar 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.
  4. Inicie el despliegue. Pulse Aceptar. Esta accion 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.

Para una aplicación Compute Grid, después del tiempo de drenaje, el planificador de trabajos cancelará estos trabajos (de la aplicación del despliegue) que se siguen ejecutando en los puntos finales inmovilizados.

Qué hacer a continuación

Para validar los resultados, pulse Aplicaciones > Centro de control de ediciones > nombre_aplicación. 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.

Atención: La validación de ediciones no funciona correctamente para las aplicaciones que se despliegan en un clúster dinámico que se ha convertido a partir de un clúster estático.



Conceptos relacionados
Conceptos del gestor de ediciones de aplicaciones
Tareas relacionadas
Instalación de ediciones
Realización de una retrotracción en una edición
Activación de ediciones simultáneas
Validación de ediciones
Referencia relacionada
Políticas de direccionamiento y servicio
Privilegios y roles administrativos
Tareas administrativas de gestión de ediciones de aplicaciones
Tema de tarea    

Condiciones de uso | Comentarios

Última actualización: 22-sep-2009 09H38' EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/appedition/tappedroll.html