[AIX Solaris HP-UX Linux Windows]

Migración de células a máquinas host nuevas utilizando la herramienta de línea de mandatos

Antes de empezar

Supported configurations Supported configurations:

En este artículo se describe la migración de la configuración de perfil. Para migrar sus aplicaciones a la versión más reciente, utilice WebSphere Application Server Migration Toolkit. Para obtener más información, consulte Migration Toolkit en WASdev.

sptcfg

Revise la información de planificación de la migración. Consulte Knowledge Collection: Migration planning for WebSphere Application Server.

Consejo: En lugar de especificar los parámetros individuales en los mandatos de migración, puede especificar el parámetro -properties nombre_archivo.properties para especificar un archivo de propiedades. Para obtener más información, consulte Definición de la migración mediante las propiedades.

En esta información se describe la migración de células a una máquina distinta. Para obtener información sobre cómo migrar células en la misma máquina, consulte Migración de células utilizando las herramientas de línea de mandatos.

Acerca de esta tarea

Esta tarea describe cómo migrar cada perfil en una configuración de célula de una versión anterior de WebSphere Application Server a WebSphere Application Server Versión 9.0 alojado en una máquina distinta. La configuración de célula consta de un gestor de despliegue con uno o más nodos, un servidor web y un cliente de aplicaciones. Todos los puertos se migran hacia la nueva configuración. No es necesario que las máquinas de host de origen y de destino ejecuten el mismo sistema operativo.

Si WebSphere Application Server Versión 9.0 no está instalado en la máquina del host de origen, se debe generar un archivo .jar de migración remota en la máquina del host de destino que coincida con el sistema operativo de la máquina de origen. El archivo .jar de migración remota proporciona al host de origen la herramienta Versión 9.0 WASPreUpgrade, que se utiliza para crear el directorio de copia de seguridad de migración para el perfil.

El mandato WASPreUpgrade se debe ejecutar desde el release de destino de WebSphere Application Server. La máquina de origen no tendrá la nueva versión del mandato WASPreUpgrade. Debe realizar una de las siguientes acciones:
  • OPCIÓN 1: Instale la versión del producto de destino en la máquina de origen
  • OPCIÓN 2: Cree el archivo .jar de migración remota (que realmente es el mandato WASPreUpgrade y los archivos necesarios para soportar la ejecución, incluido Java, recopilado de la instalación de destino).
Una vez creado el archivo .jar de migración remota, puede ejecutarlo en la máquina de origen.
Nota: Esta OPCIÓN 2 es más fácil, pues no es necesaria una instalación completa. Una vez creado el archivo jar, se puede utilizar para muchas máquinas de origen. Pero si las máquina de origen y de destino están en arquitecturas de sistema operativo diferentes, es necesaria la opción 1, pues el archivo jar de migración remota es específico de la arquitectura de sistema operativo.

Cuando varias máquinas de origen tienen todas las mismas arquitecturas de sistema operativo, pero diferente de la máquina de destino, solamente una máquina de origen necesita tener instalado el release de destino. El archivo .jar de migración remota se puede crear a partir de esa única máquina de origen y ser utilizado en otras máquinas de origen.

En este procedimiento se supone que se está ejecutando la configuración anterior y que migra todos los perfiles a una máquina host diferente.

Avoid trouble Avoid trouble: Asegúrese de que el valor para el número máximo de archivos abiertos sea 10000 o superior. Si el número de archivos abiertos es demasiado bajo, esto puede producir diversos errores de migración.gotcha
For transitioning users For transitioning users: WebSphere Virtual Enterprise e Intelligent Management antes requerían herramientas de migración independientes, pero ahora se migran como parte de los procedimientos de migración estándar.trns
Restricción: La migración remota desde IBM® i o z/OS no está soportada.

Procedimiento

  1. Realice una copia de seguridad del gestor de despliegue y de todos los nodos antiguos. En caso de error durante la migración, guarde el gestor de despliegue actual y la configuración de nodo en un archivo que puede utilizar más tarde para fines de recuperación.
    1. Vaya al directorio raíz_perfil_gestor_despliegue/bin.
    2. Ejecute el mandato backupConfig con los parámetros adecuados y guarde la configuración de perfil actual en un archivo. Por ejemplo:
      [Windows]
      raíz_servidor_apl_versión_anterior\v70dmgr01\bin\
      backupConfig.bat
      \copia_host_antiguo\v70dmgr01backupBeforeV90migration.zip
      -username miusuario -password micontraseña -nostop
      [AIX][HP-UX][Linux][Solaris]
      raíz_servidor_apl_versión_anterior/v70dmgr01/bin/backupConfig.sh 
      /copia_host_antiguo/v70dmgr01backupBeforeV90migration.zip
      -username
      miusuario -password micontraseña -nostop
      donde copia_host_antiguo es la ubicación en la que se han guardado los puntos de restauración de la configuración.
    3. Para cada nodo de la configuración, vaya al directorio raíz_perfil_nodo/bin.
    4. Ejecute el mandato backupConfig con los parámetros adecuados y guarde la configuración de perfil actual en un archivo. Por ejemplo:
      [Windows]
      raíz_servidor_apl_versión_anterior\v70node01\bin\backupConfig.bat 
      
      \copia_host_antiguo\v70node01backupBeforeV90migration.zip
      -username
       miusuario -password micontraseña -nostop
      [AIX][HP-UX][Linux][Solaris]
      raíz_servidor_apl_versión_anterior/v70node01
      /bin/backupConfig.sh
      /copia_host_antiguo/v70node01rbackupBeforeV90migration.zip
      -username miusuario -password micontraseña -nostop
  2. Instale WebSphere Application Server, Network Deployment Versión 9.0 en cada host de destino en un directorio nuevo.

    Para obtener más información, consulte la documentación sobre instalación.

  3. Cree el archivo .jar de migración remota. Este archivo .jar contiene los archivos necesarios para ejecutar el mandato WASPreUpgrade en un sistema que no tenga instalado WebSphere Application Server Versión 9.0.
    Avoid trouble Avoid trouble: Debe crear el archivo .jar de migración remota en el mismo sistema operativo y la misma arquitectura en que ha instalado el origen. Puesto que el archivo que se genera contiene código específico del sistema operativo, sólo se ejecuta en esta arquitectura.gotcha
    1. Identifique el sistema operativo y la arquitectura del perfil de origen. Si el sistema operativo y la arquitectura del perfil de origen son distintos del sistema operativo o la arquitectura del perfil de destino, debe instalar WebSphere Application Server Versión 9.0 en un sistema que coincida con el perfil de origen antes de crear el jar de migración remota. Una vez generado el jar de migración remota, funcionará en cualquier sistema que coincida con el sistema operativo y la arquitectura.
    2. Cree el archivo .jar de migración remota
      1. En el indicador de mandatos, escriba: cd $WAS_HOME/bin/migration/bin
      2. Para crear el archivo .jar, ejecute: createRemoteMigrJar.bat(sh) -targetDir <dir para el jar de migración remota> . De este modo se crea el archivo siguiente: WAS_V90_OS.arch_RemoteMigrSupport.jar. Por ejemplo: WAS_V90_windows.amd64_RemoteMigrSupport.jar
    3. Prepare el sistema remoto para el mandato WasPreUpgrade.
      1. Envíe el archivo .jar al sistema en el que reside el perfil de origen.
      2. Extraiga el archivo en una ubicación temporal.
      3. Vaya al directorio bin en la ubicación temporal.

      Ahora está preparado para ejecutar el mandato WASPreUpgrade en el perfil de origen. No obstante, no emita este mandato hasta que se le indique que debe hacerlo en un paso posterior.

  4. Cree el perfil del gestor de despliegue de destino. El perfil del gestor de despliegue de destino es un perfil de gestor de despliegue nuevo que es el destino de la migración.
    Avoid trouble Avoid trouble: Los nombres de célula y nodo de la Versión 9.0 deben coincidir con los nombres de célula y nodo de la configuración anterior. Si crea células y nodos con nombres nuevos, la migración fallará.gotcha

    Para crear un perfil del gestor de despliegue, ejecute el mandato manageprofiles con los parámetros adecuados.

    Por ejemplo:
    [Windows]
    raíz_instalación_versión_9\bin\manageprofiles.bat -create
    -profileName v70toV90dmgr01 -templatePath \opt\WebSphereV90\profileTemplates\
    management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName 
    -cellName currentCellName -hostName mydmgrhost.company.com
    [AIX][HP-UX][Linux][Solaris]
    raíz_instalación_versión_9/bin/manageprofiles.sh -create
    -profileName v70toV90dmgr01 -templatePath /opt/WebSphereV90/profileTemplates/
    management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName 
    -cellName currentCellName -hostName mydmgrhost.company.com
  5. Guarde la configuración del gestor de despliegue actual en el directorio de copia de seguridad de la migración. Para guardar la configuración actual del gestor de despliegue en el directorio de seguridad de la migración, ejecute el mandato WASPreUpgrade. El mandato WASPreUpgrade no modifica la configuración antigua.
    1. Ejecute el mandato WASPreUpgrade con el parámetro -machineChange true para guardar la configuración actual del gestor de despliegue en un directorio de seguridad de la migración. Por ejemplo:
      [Windows]
      <vía de acceso a jar de migración remota>\migration\bin\WASPreUpgrade.bat \copia_host_antiguo\v70toV90dmgr01
      \opt\WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <vía de acceso a jar de migración remota>/migration/bin/WASPreUpgrade.sh /copia_seguridad_host_antiguo/v70toV90dmgr01
      /opt/WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      donde copia_host_antiguo es el directorio donde se copian los archivos de configuración de perfil como preparación de la migración hacia el nuevo host.

      Si está migrando desde la Versión 8.0 a Versión 9.0 y el perfil es un gestor de despliegue, el perfil de la Versión 8.0 se detiene cuando se ejecuta WASPreUpgrade. El gestor de despliegue sólo se inicia antes de que WASPreUpgrade finalice si especifica -keepDmgrEnabled true en la línea de mandatos o especifica la opción correspondiente en el asistente de migración.

      Avoid trouble Avoid trouble: Si especifica -machineChange true, después de la migración debe actualizar el URL del gestor de trabajos para todos los recursos (tales como otros gestores de despliegue o servidores de aplicaciones) que son gestionados por la función del gestor de trabajos del gestor de despliegue de la Versión 8.0.gotcha
    2. Revise los avisos o errores en la salida de la consola y los registros de WASPreUpgrade. Cuando el mandato WASPreUpgrade finalice, compruebe si la salida de la consola contiene los mensajes Ha habido errores o Se ha completado con avisos. A continuación, compruebe si los archivos de registro siguientes contienen avisos o errores:
      • copia_host_antiguo/v70toV90dmgr01/logs/WASPreMigrationSummary.log
      • copia_host_antiguo/v70toV90dmgr01/logs/WASPreUpgrade.fecha_hora.log
      • copia_host_antiguo/v70toV90dmgr01/logs/WASPreUpgrade.trace

      Si hay errores, corrija los errores y vuelva a ejecutar el mandato WASPreUpgrade. Compruebe si los avisos afectan a alguna migración u otras actividades en tiempo de ejecución en la Versión 9.0.

      Si el mandato ha finalizado correctamente, no es necesario comprobar si existen errores o avisos en los registros.

  6. Archive el directorio de seguridad creado por el mandato WASPreUpgrade.
    Avoid trouble Avoid trouble: No utilice la herramienta de archivado de Windows porque no es compatible con una migración de WebSphere Application Server.gotcha
    1. Utilice la herramienta de archivado de su elección para crear un archivo comprimido del directorio de copia de seguridad. Por ejemplo:
      cd /mybackup_old_host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90dmgr01.jar v70toV90dmgr01/
    2. Traslade el archivo de archivado a la máquina de destino.
    3. Cree un directorio en la máquina de destino y extraiga el archivo de archivado en el nuevo directorio. Por ejemplo:
      mkdir /copia_host_nuevo
      cd /copia_host_nuevo
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      donde copia_host_nuevo es el directorio al que migra los archivos.
  7. Restaure la configuración de gestor de despliegue anterior.

    Ejecute el mandato WASPostUpgrade desde el directorio bin del perfil del gestor de despliegue nuevo para restaurar la configuración del gestor de despliegue anterior que ha guardado en el directorio de copia de seguridad de la migración. Si utiliza las opciones que se muestran en el ejemplo, se incluirán todos los puertos y se instalarán todas las aplicaciones.

    1. Ejecute el mandato WASPostUpgrade para restaurar la configuración de gestor de despliegue guardada en el nuevo perfil de gestor de despliegue de la Versión 9.0. Por ejemplo:
      [Windows]
      raíz_instalación_versión_9\bin\WASPostUpgrade.bat \
      copia_host_nuevo\v70toV90dmgr01
      -profileName v70toV90dmgr01 -oldProfile
      70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE
      -keepDmgrEnabled TRUE -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      raíz_instalación_versión_9/bin/WASPostUpgrade.sh /
      copia_host_nuevo/v70toV90dmgr01 -profileName
      v70toV90dmgr01 -oldProfile
       70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE
      -keepDmgrEnabled TRUE -username myuser -password mypass
      donde copia_host_nuevo es el directorio desde donde se migran los archivos de configuración del perfil de origen.

      [AIX Solaris HP-UX Linux Windows]Si desea continuar utilizando el perfil antiguo después de que se migre, especifique el parámetro -clone TRUE. Si especifica una migración de clon para el gestor de despliegue, también debe clonar todos sus nodos federados.

    2. Compruebe si hay avisos o errores en la salida de la consola y los registros de WASPostUpgrade. Cuando el mandato WASPostUpgrade finalice, compruebe si la salida de la consola contiene los mensajes Ha habido errores o Se ha completado con avisos. A continuación, compruebe si los archivos de registro siguientes contienen avisos o errores:
      • copia_host_nuevo/v70toV90dmgr01/logs/WASPostMigrationSummary.log
      • copia_host_nuevo/v70toV90dmgr01/logs/WASPostUpgrade.nombre_perfil_destino.fecha_hora.log
      • copia_host_nuevo/v70toV90dmgr01/logs/WASPostUpgrade.nombre_perfil_destino.trace

      Si hay errores, corrija los errores y vuelva a ejecutar el mandato WASPostUpgrade. Compruebe si los avisos afectan a alguna migración u otras actividades en tiempo de ejecución en la Versión 9.0.

      Si la configuración se ha migrado correctamente, pero las aplicaciones no se han instalado, puede ejecutar el mandato WASMigrationAppInstaller para instalar sólo las aplicaciones que no se han migrado. Para obtener más información, consulte Mandato WASMigrationAppInstaller.

      Si el mandato ha finalizado correctamente, no es necesario comprobar si existen errores o avisos en los registros.

    Avoid trouble Avoid trouble: Después de que el mandato WASPostUpgrade se complete satisfactoriamente, no inicie el gestor de despliegue nuevo. Antes de iniciarlo, debe completar algunos pasos más.gotcha
  8. Guarde la configuración del gestor de despliegue migrado de la Versión 9.0 en un archivo ejecutando el mandato backupConfig en el gestor de despliegue de la Versión 9.0.
    Avoid trouble Avoid trouble: Si se produce un error de migración de nodo, puede restaurar la configuración de la célula hasta punto anterior donde se produjo el error. Puede aplicar acciones correctivas e intentar de nuevo la migración del nodo. gotcha
    1. Vaya al directorio raíz_perfil_gestor_despliegue/bin
    2. Ejecute el mandato backupConfig con los parámetros adecuados y guarde la configuración de perfil de la Versión 9.0 en un archivo. Por ejemplo:
      [Windows]
      raíz_perfil_versión_9\profiles\v70toV90dmgr01\
      
      bin\backupConfig.bat\copia_host_nuevo\v70toV90dmgr01backupMigratedDmgrOnly.zip
      -username miusuario -password micontraseña
      [AIX][HP-UX][Linux][Solaris]
      raíz_perfil_versión_9/profiles/v70toV90dmgr01/bin/backupConfig.sh /
      copia_host_nuevo/v70toV90dmgr01backupMigratedDmgrOnly.zip
      -username
      miusuario -password micontraseña
      donde copia_host_nuevo es la ubicación donde se almacenan los puntos de restauración de la configuración.
  9. Detenga e inhabilite el gestor de despliegue en el host antiguo.
    1. Detenga el gestor de despliegue en el host antiguo.
    2. Inhabilite el gestor de despliegue en el host antiguo. Para inhabilitar este gestor de despliegue, debe renombrar el archivo serverindex.xml asociado, tal como se indica en la información siguiente:
      Nombre antiguo
      $PROFILE_ROOT/config/cells/nombre_célula/nodes/nombre_nodo_gestor_despliegue/serverindex.xml
      Nombre nuevo
      $PROFILE_ROOT/config/cells/nombre_célula/nodes/nombre_nodo_gestor_despliegue/serverindex.xml_disabled
  10. Inicie el gestor de despliegue de la Versión 9.0 en el nuevo host.
    1. Vaya al nuevo directorio Versión 9.0 raíz_perfil_gestor_despliegue/bin.
    2. Ejecute el mandato startManager.
    3. Mientras se está ejecutando el gestor de despliegue, consulte si hay avisos o errores en el archivo SystemOut.log.
      Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.
      Compruebe si los avisos afectan a una migración de nodo o actividad de ejecución cuando se inicia el gestor de despliegue de la Versión 9.0.
    4. Asegúrese de que el gestor de despliegue de la Versión 9.0 esté en ejecución.
  11. Sincronice manualmente los nodos antiguos con el nuevo gestor de despliegue de la Versión 9.0.

    Asegúrese de que el gestor de despliegue de la Versión 9.0 en el nuevo host se está ejecutando. Debe iniciar sesión en la máquina que contiene los nodos antiguos y ejecutar el mandato syncNode.

    1. Detenga el agente de nodo.
    2. Obtenga el host y el número de puerto del gestor de despliegue y actualice el archivo raíz_perfil_agente_nodo/properties/wsadmin.properties. Cambie el valor de com.ibm.ws.scripting.host por el nuevo host. Cambie el valor de com.ibm.ws.scripting.port por el nuevo puerto.
    3. Ejecute el mandato syncNode desde el directorio bin. Por ejemplo:
      [Windows]
      raíz_instalación_agente_nodo\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      raíz_instalación_agente_nodo/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username miusuario -password micontraseña
    4. Si la sincronización ha sido satisfactoria, inicie el agente de nodo.
  12. Migre los plug-ins para servidores web.
    1. Asegúrese de que el gestor de despliegue de la Versión 9.0 esté en ejecución.
    2. Actualice la versión del plug-in del servidor web que se utiliza en la célula.
    3. Consulte la información de soporte que se aplica a su tipo y versión de servidor web.
  13. Migre las instalaciones de cliente de aplicaciones.

    Si el cliente de WebSphere Application de origen es de la versión 7.0, también debe ejecutar los mandatos WASPreUpgrade y WASPostUpgrade para migrar los valores de seguridad existentes.

    1. Identifique todos los host de cliente que debe migrar.
    2. Instale el cliente de aplicaciones de WebSphere Versión 9.0.
    3. Ejecute el mandato WASPreUpgrade de la Versión 9.0 para guardar los valores de seguridad del cliente de aplicaciones en un directorio de copia de seguridad de migración. Por ejemplo:
      /opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup_client/v70clientToV90 /opt/AppClientV70
    4. Ejecute el mandato WASPostUpgrade de la Versión 9.0 para restaurar los valores de seguridad del cliente de aplicaciones de la Versión 9.0 del cliente. Por ejemplo:
      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup_client/v70clientToV90 
  14. Migre los nodos.
    Importante: Estos pasos solo se aplican a migraciones entre máquinas. Si no está realizando una migración entre máquinas de un nodo, consulte la información sobre la migración de nodos en Migración de células utilizando las herramientas de línea de mandatos. Asegúrese de que el gestor de despliegue de la Versión 9.0 esté en ejecución. Para cada nodo que tiene previsto migrar a la Versión 9.0, realice los pasos siguientes.
    Avoid trouble Avoid trouble: Para que la migración sea satisfactoria, debe utilizar el mismo nombre de nodo de origen pero un nombre de célula temporal distinto para cada nodo que migre a la Versión 9.0 o posterior. gotcha
    1. Instale WebSphere Application Server Versión 9.0 en cada host de destino. Para obtener más información, consulte la documentación sobre la instalación de un entorno de servicio de aplicaciones.
    2. Cree el perfil de nodo de destino. Ejecute el mandato manageprofiles con los parámetros correspondientes para crear un perfil gestionado nuevo. Por ejemplo:
      [Windows]
      raíz_instalación_versión_9\bin\manageprofiles.bat 
      -create -profileName node1 -templatePath \opt\
      WebSphereV90\profileTemplates\managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
      [AIX][HP-UX][Linux][Solaris]
      raíz_instalación_versión_9/bin/manageprofiles.sh 
      -create -profileName node1 -templatePath 
      /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
    3. Utilice el archivo .jar de migración remota que ha creado para migrar el gestor de despliegue para hacer que el mandato WASPreUpgrade esté disponible en la máquina del nodo actual.
      Nota: Este paso sólo es necesario realizarlo si el nodo de origen y el gestor de despliegue no están en la misma máquina y este paso sólo puede llevase a cabo si la arquitectura de la máquina es la misma.
      Para obtener más información, consulte el paso 3 de este caso de ejemplo, Cree el archivo .jar de migración remota.
    4. Ejecute el mandato WASPreUpgrade con el parámetro -machineChange true para guardar la configuración del nodo actual en un directorio de seguridad de la migración. Elija un directorio nuevo para los archivos de copia de seguridad. Por ejemplo:
      [Windows]
      <vía de acceso a jar de migración
      remota>\migration\bin\WASPreUpgrade.bat
      \copia_host_antiguo\v70toV90node1
      \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <vía de acceso a jar de migración remota>/migration/bin/WASPreUpgrade.sh /copia_seguridad_host_antiguo/v70toV90node1
      /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
    5. Consulte si hay mensajes de error y aviso en la salida de consola de WASPreUpgrade. Puede encontrar los mensajes siguientes: "Ha habido errores" o "Se ha completado con avisos". Además, consulte si hay mensajes de error o de aviso en los siguientes archivos de registro:
      • copia_host_antiguo/v70toV90node1/logs/WASPreMigrationSummary.log
      • copia_host_antiguo/v70toV90node1/logs/WASPreUpgrade.fecha y hora.log
      • copia_host_antiguo/v70toV90node1/logs/WASPreUpgrade.trace

      Si el mandato WASPreUpgrade se ha realizado correctamente, no es necesario que compruebe si hay mensajes de aviso o de error en los archivos de registro.

    6. Utilice la herramienta de archivado de su elección para crear un archivo comprimido del directorio de copia de seguridad que se ha creado mediante el mandato WASPreUpgrade. Por ejemplo:
      [AIX Solaris HP-UX Linux Windows]
      cd /copia_host_antiguo
      /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
    7. Traslade el archivo de archivado a la máquina de destino.
    8. Cree un directorio en la máquina de destino y extraiga el archivo de archivado en el nuevo directorio. Por ejemplo:
      mkdir /copia_host_nuevo
      cd /copia_host_nuevo
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      donde copia_host_nuevo es el directorio desde el que se migran los archivos de configuración del perfil.
    9. Detenga los servidores de aplicaciones en el nodo antiguo y luego detenga el agente de nodo en el nodo antiguo.
    10. Detenga e inhabilite el nodo en el host antiguo. Asegúrese de que no utiliza el nodo en el host antiguo. Para inhabilitar el nodo, debe renombrar el archivo serverindex.xml asociado, tal como se indica en la información siguiente:
      Nombre antiguo
      $PROFILE_ROOT/config/cells/nombre_célula/nodes/nombre_nodo/serverindex.xml
      Nombre nuevo
      $PROFILE_ROOT/config/cells/nombre_célula/nodes/nombre_nodo/serverindex.xml_disabled
    11. Ejecute el mandato WASPostUpgrade para restaurar la configuración de nodo guardada en el nuevo perfil gestionado de la Versión 9.0. Por ejemplo:
      [Windows]
      raíz_instalación_versión_9\bin\WASPostUpgrade.bat \
      copia_host_nuevo\v70toV90node1 -profileName v70toV90node1
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -includeApps TRUE 
      -usernamemiusuario-passwordmicontraseña
      [AIX][HP-UX][Linux][Solaris]
      raíz_instalación_versión_9/bin/WASPostUpgrade.sh /
      copia_host_nuevo/v70toV90node1
      -profileName v70toV90node1
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig 
      TRUE -includeApps TRUE 
      -usernamemiusuario-passwordmicontraseña

      [AIX Solaris HP-UX Linux Windows]Si ha clonado el gestor de despliegue, también debe clonar todos los nodos federados. Especifique el parámetro -clone TRUE y el nuevo nombre de host del gestor de despliegue y el puerto SOAP o RMI. No clone los nodos federados a menos que se clone el gestor de despliegue.

      [Windows]
      raíz_instalación_versión_9\bin\WASPostUpgrade.bat \
      copia_host_nuevo\v70toV90node1 -profileName v70toV90node1
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -includeApps TRUE 
      -username myuser -password mypass
      -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
      [AIX][HP-UX][Linux][Solaris]
      raíz_instalación_versión_9/bin/WASPostUpgrade.sh /
      copia_host_nuevo/v70toV90node1
      -profileName v70toV90node1
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig 
      TRUE -includeApps TRUE 
      -username myuser -password mypass
      -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
    12. Compruebe si hay los mensajes siguientes en la salida de la consola de WASPostUpgrade. Puede encontrar los mensajes siguientes: "Ha habido errores" o "Se ha completado con avisos". Además, consulte si hay mensajes de error o de aviso en los siguientes archivos de registro:
      • copia_host_nuevo/v70toV90node1/logs/WASPostMigrationSummary.log
      • copia_host_nuevo/v70toV90node1/logs/WASPostUpgrade.nombre_perfil_destino.fecha_hora.log
      • copia_host_nuevo/v70toV90node1/logs/WASPostUpgrade.nombre_perfil_destino.trace
      Nota: Si el mandato WASPostUpgrade falla, puede ser necesario restaurar el gestor de despliegue de la Versión 9.0 a partir del archivo de configuración de copia de seguridad. Si el proceso del mandato WASPostUpgrade ha ejecutado el mandato syncNode, el gestor de despliegue sabrá que se ha migrado el nodo. El nodo no se puede migrar de nuevo hasta que el gestor de despliegue se haya restaurado al estado anterior a la migración del nodo.

      Si la configuración se ha migrado correctamente, pero las aplicaciones no se han instalado, puede ejecutar el mandato WASMigrationAppInstaller para instalar sólo las aplicaciones que no se han migrado. Para obtener más información, consulte Mandato WASMigrationAppInstaller.

    13. Compruebe si el archivo SystemOut.log del gestor de despliegue de la Versión 9.0 contiene mensajes de error o de aviso.
      Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.
    14. Inicie el agente de nodos migrado de la Versión 9.0.
    15. Compruebe si el archivo SystemOut.log del gestor de despliegue y del nodo de la Versión 9.0 contienen mensajes de error o de aviso.
    16. Opcional: Sincronice la célula si el proceso de sincronización automática no está habilitado.
    17. Inicie los servidores de aplicaciones adecuados en el nodo migrado de la Versión 9.0.
    18. Ejecute el mandato backupConfig y guarde la configuración del perfil de la Versión 9.0 en un archivo. Por ejemplo:
      [Windows]
      raíz_perfil_versión_9\v70toV90node1\bin\backupConfig.bat 
      \copia_host_nuevo\v70toV90node1.zip
      -username miusuario
      -password micontraseña -nostop
      [AIX][HP-UX][Linux][Solaris]
      raíz_perfil_versión_9/v70toV90node1/bin/backupConfig.sh 
      /copia_host_nuevo/v70toV90node1.zip
      -username miusuario
      -password micontraseña -nostop
      Cada vez que ejecute el mandato backupConfig en un nodo específico, utilice un nombre de archivo de copia de seguridad nuevo.
    19. Guarde la configuración del gestor de despliegue utilizando el mandato backupConfig. En el host del gestor de despliegue de la Versión 9.0, vaya al directorio raíz_perfil_gestor_despliegue/bin. Ejecute el mandato backupConfig y guarde la configuración del perfil de la Versión 9.0 en un archivo. Por ejemplo:
      [Windows]
      raíz_perfil_versión_9\v70toV90dmgr01\bin\backupConfig.bat 
      \copia_host_nuevo\v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip
      -usernamemiusuario-passwordmicontraseña
      [AIX][HP-UX][Linux][Solaris]
      raíz_perfil_versión_9/v70toV90dmgr01/bin/backupConfig.sh 
      /copia_host_nuevo/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip
      -usernamemiusuario-passwordmicontraseña
      Nota: Para cada nodo que ha migrado, realice una copia de seguridad de la configuración del gestor de despliegue de la Versión 9.0 en un archivo de copia de seguridad nuevo.
    20. Repita los pasos anteriores para nodos adicionales.

Resultados

Ha utilizado las herramientas de migración para migrar las configuraciones de célula de una versión anterior de WebSphere Application Server a máquinas de host nuevas que se ejecutan en WebSphere Application Server Versión 9.0.


Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tmig_migrate_remote_commandline
File name: tmig_migrate_remote_commandline.html