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

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.
sptcfgRevise la información de planificación de la migración. Consulte Knowledge Collection: Migration planning for WebSphere Application Server.
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.
- 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).
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.


Procedimiento
- 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.
- Vaya al directorio raíz_perfil_gestor_despliegue/bin.
- Ejecute el mandato backupConfig con los parámetros
adecuados y guarde la configuración de perfil actual en un archivo. Por ejemplo:
raíz_servidor_apl_versión_anterior\v70dmgr01\bin\ backupConfig.bat \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.raíz_servidor_apl_versión_anterior/v70dmgr01/bin/backupConfig.sh /copia_host_antiguo/v70dmgr01backupBeforeV90migration.zip -username miusuario -password micontraseña -nostop
- Para cada nodo de la configuración, vaya al directorio raíz_perfil_nodo/bin.
- Ejecute el mandato backupConfig con los
parámetros adecuados y guarde la configuración de perfil actual en un
archivo. Por ejemplo:
raíz_servidor_apl_versión_anterior\v70node01\bin\backupConfig.bat \copia_host_antiguo\v70node01backupBeforeV90migration.zip -username miusuario -password micontraseña -nostop
raíz_servidor_apl_versión_anterior/v70node01 /bin/backupConfig.sh /copia_host_antiguo/v70node01rbackupBeforeV90migration.zip -username miusuario -password micontraseña -nostop
- 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.
- 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: 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
- 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.
- Cree el archivo .jar de migración remota
- En el indicador de mandatos, escriba: cd $WAS_HOME/bin/migration/bin
- 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
- Prepare el sistema remoto para el mandato WasPreUpgrade.
- Envíe el archivo .jar al sistema en el que reside el perfil de origen.
- Extraiga el archivo en una ubicación temporal.
- 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.
- 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: 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: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
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
- 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.
- 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:
<vía de acceso a jar de migración remota>\migration\bin\WASPreUpgrade.bat \copia_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.<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
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: 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
- 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.
- 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:
- Archive el directorio de seguridad creado por el
mandato WASPreUpgrade.
Avoid trouble: No utilice la herramienta de archivado de Windows porque no es compatible con una migración de WebSphere Application Server.gotcha
- 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/
- Traslade el archivo de archivado a la máquina de destino.
- Cree un directorio en la máquina de destino y extraiga el
archivo de archivado en el nuevo directorio. Por ejemplo:
donde copia_host_nuevo es el directorio al que migra los archivos.mkdir /copia_host_nuevo cd /copia_host_nuevo /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
- Utilice la herramienta de archivado de su elección para
crear un archivo comprimido del directorio de copia de seguridad. Por ejemplo:
- 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.
- 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:
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
donde copia_host_nuevo es el directorio desde donde se migran los archivos de configuración del perfil de origen.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
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.
- 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: 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
- 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:
- 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: 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
- Vaya al directorio raíz_perfil_gestor_despliegue/bin
- 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:
raíz_perfil_versión_9\profiles\v70toV90dmgr01\ bin\backupConfig.bat\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.raíz_perfil_versión_9/profiles/v70toV90dmgr01/bin/backupConfig.sh / copia_host_nuevo/v70toV90dmgr01backupMigratedDmgrOnly.zip -username miusuario -password micontraseña
- Detenga e inhabilite el gestor de despliegue en el host
antiguo.
- Detenga el gestor de despliegue en el host antiguo.
- 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
- Inicie el gestor de despliegue de la Versión 9.0 en el nuevo host.
- Vaya al nuevo directorio Versión 9.0 raíz_perfil_gestor_despliegue/bin.
- Ejecute el mandato startManager.
- 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.
- Asegúrese de que el gestor de despliegue de la Versión 9.0 esté en ejecución.
- 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.
- Detenga el agente de nodo.
- 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.
- Ejecute el mandato syncNode desde el
directorio bin. Por ejemplo:
raíz_instalación_agente_nodo\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
raíz_instalación_agente_nodo/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username miusuario -password micontraseña
- Si la sincronización ha sido satisfactoria, inicie el agente de nodo.
- Migre los plug-ins para servidores web.
- Asegúrese de que el gestor de despliegue de la Versión 9.0 esté en ejecución.
- Actualice la versión del plug-in del servidor web que se utiliza en la célula.
- Consulte la información de soporte que se aplica a su tipo y versión de servidor web.
- 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.
- Identifique todos los host de cliente que debe migrar.
- Instale el cliente de aplicaciones de WebSphere Versión 9.0.
- 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
- 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
- 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: 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
- 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.
- Cree el perfil de nodo de destino. Ejecute el mandato
manageprofiles con los parámetros correspondientes para crear un perfil
gestionado nuevo. Por ejemplo:
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
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
- 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.
- 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:
<vía de acceso a jar de migración remota>\migration\bin\WASPreUpgrade.bat \copia_host_antiguo\v70toV90node1 \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
<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
- 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.
- 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:
cd /copia_host_antiguo /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
- Traslade el archivo de archivado a la máquina de destino.
- Cree un directorio en la máquina de destino y extraiga el
archivo de archivado en el nuevo directorio. Por ejemplo:
donde copia_host_nuevo es el directorio desde el que se migran los archivos de configuración del perfil.mkdir /copia_host_nuevo cd /copia_host_nuevo /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
- Detenga los servidores de aplicaciones en el nodo antiguo y luego detenga el agente de nodo en el nodo antiguo.
- 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
- 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:
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
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
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.
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
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
- 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.
- 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.
- Inicie el agente de nodos migrado de la Versión 9.0.
- 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.
- Opcional: Sincronice la célula si el proceso de sincronización automática no está habilitado.
- Inicie los servidores de aplicaciones adecuados en el nodo migrado de la Versión 9.0.
- Ejecute el
mandato backupConfig y guarde la configuración del perfil de la
Versión 9.0 en un archivo. Por ejemplo:
raíz_perfil_versión_9\v70toV90node1\bin\backupConfig.bat \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.raíz_perfil_versión_9/v70toV90node1/bin/backupConfig.sh /copia_host_nuevo/v70toV90node1.zip -username miusuario -password micontraseña -nostop
- 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:
raíz_perfil_versión_9\v70toV90dmgr01\bin\backupConfig.bat \copia_host_nuevo\v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -usernamemiusuario-passwordmicontraseña
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. - 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.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_migrate_remote_commandline
File name: tmig_migrate_remote_commandline.html