Migrando Configurações de Células para Novas Máquinas Host Usando a Ferramenta de Linha de Comandos

Antes de Iniciar

Configurações suportadas Configurações suportadas:

Este artigo trata da migração da configuração de perfil. Para migrar seus aplicativos para a versão mais recente, use o Kit de Ferramentas de Migração do WebSphere Application Server. Para obter mais informações, consulte o Kit de ferramentas de migração no WASdev.

sptcfg

Revise as informações de planejamento de migração. Veja Coleção de conhecimento: Planejamento de migração para o WebSphere Application Server.

Estas informações descrevem a migração de células para uma máquina diferente. Para obter informações sobre como migrar células na mesma máquina, veja Migrando células usando as ferramentas de linha de comandos.

Sobre Esta Tarefa

Esta tarefa descreve como migrar cada perfil em uma configuração de célula de uma versão anterior do WebSphere Application Server para o WebSphere Application Server Versão 9.0 hospedado em uma máquina diferente. A configuração da célula consiste em um gerenciador de implementação com um ou mais nós, um servidor da web e um aplicativo cliente. Todas as portas são migradas em direção à nova configuração. As máquinas host de origem e de destino não precisam executar o mesmo sistema operacional.

Se o WebSphere Application Server Versão 9.0 não for instalado na máquina host de origem, você deve gerar um arquivo .jar de migração remota na máquina host de destino que corresponda ao sistema operacional da máquina de origem. O arquivo .jar de migração remota fornece ao host de origem a ferramenta WASPreUpgrade do Versão 9.0, que é usada para criar o diretório de backup de migração para o perfil.

O comando WASPreUpgrade deve ser executado a partir da liberação do WebSphere Application Server de "destino". A máquina de "origem" não terá a versão do comando WASPreUpgrade. Você deve executar uma das seguintes ações:
  • OPÇÃO 1: Instale a liberação de "destino" na máquina de "origem"
  • OPÇÃO 2: Crie o jar de migração remota (que é realmente o comando WASPreUpgrade e os arquivos necessários para suportar a execução, incluindo JAVA, coletados a partir da instalação de "destino").
Depois que você tiver o jar de migração remota, é possível executá-lo na máquina de "origem".
Nota: Essa OPÇÃO 2 é mais fácil, pois uma instalação integral não é necessária. Depois que o archive é criado, ele pode ser usado para diversas máquinas de "origem". No entanto, se as máquinas de "destino" e "origem" estiverem em diferentes arquiteturas de sistema operacional (Linux, WINDOWS, AIX, HP ou Sun e com as arquiteturas sendo de 32 ou 64 bits), a opção 1 será necessária porque o archive de migração remoto é específico da arquitetura do sistema operacional.

Quando todas as diversas máquinas de "origem" têm as mesmas arquiteturas de sistema operacional, mas diferentes da máquina de "destino", somente uma máquina de "origem" precisa ter a liberação de "destino" instalada. A partir daquela máquina de "origem", o jar de migração remota pode ser criado e usado nas outras máquinas de "origem".

Esse procedimento supõe que a configuração anterior esteja em execução e que você esteja migrando todos os perfis para uma máquina host diferente.

Evitar Problemas Evitar Problemas: Assegure que sua configuração para o número máximo de arquivos abertos seja 10000 ou maior. Se o número de arquivos abertos for muito baixo, isto poderá causar uma variedade de falhas de migração.gotcha
Para Usuários de Transição Para Usuários de Transição: Anteriormente, os seguintes produtos precisavam de ferramentas de migração separadas, mas agora são migrados como parte dos procedimentos de migração padrão:
  • WebSphere Extended Deployment Compute Grid ou Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise ou Intelligent Management
Para obter informações adicionais sobre essas mudanças, consulte O que há de novo para migração.trns
Restrição: Migração remota no IBM® i NÃO é suportada.

Procedimento

  1. Faça backup do gerenciador de implementação e de todos os nós antigos No caso de falha durante a migração, salve o gerenciador de implementação e a configuração do nó atuais em um arquivo que pode ser usado posteriormente para propósitos de recuperação.
    1. Altere para o diretório deployment_manager_profile_root/bin.
    2. Execute o comando backupConfig com os parâmetros apropriados e salve a configuração do perfil atual em um arquivo. Por exemplo:
      [Windows]
      previous_version_app_server_root\v70dmgr01\bin\
      backupConfig.bat \mybackup_old_host\v70dmgr01backupBeforeV90migration.zip 
      -username myuser -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      previous_version_app_server_root/v70dmgr01/bin/backupConfig.sh 
      /mybackup_old_host/v70dmgr01backupBeforeV90migration.zip -username 
      myuser -password mypass -nostop
      em que mybackup_old_host é o local no qual os pontos de restauração da configuração são armazenados.
    3. Para cada nó na configuração, altere para o diretório node_profile_root/bin.
    4. Execute o comando backupConfig com os parâmetros apropriados e salve a configuração do perfil atual em um arquivo. Por exemplo:
      [Windows]
      previous_version_app_server_root\v70node01\bin\backupConfig.bat 
      \mybackup_old_host\v70node01backupBeforeV90migration.zip -username
       myuser -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      previous_version_app_server_root/v70node01
      /bin/backupConfig.sh /mybackup_old_host/v70node01rbackupBeforeV90migration.zip 
      -username myuser -password mypass -nostop
  2. Instale WebSphere Application Server Versão 9.0
    1. Instale o WebSphere Application Server Network Deployment, BaseVersão 9.0 em cada host de destino em um novo diretório. Para obter informações adicionais, consulte a documentação sobre como instalar um ambiente de entrega de aplicativos.
  3. Crie o arquivo .jar de migração remota Esse arquivo .jar contém os arquivos necessários para executar o comando WASPreUpgrade em um sistema que não tem o WebSphere Application Server Versão 9.0 instalado.
    Evitar Problemas Evitar Problemas: Você deve criar o arquivo .jar de migração remota no mesmo sistema operacional e arquitetura em que instalou a origem. Como o archive que é gerado contém código específico do sistema operacional, ele é executado somente nessa arquitetura.gotcha
    1. Identifique o sistema operacional e a arquitetura do perfil de origem. Se o sistema operacional e a arquitetura do perfil de origem forem diferentes do sistema operacional ou da arquitetura do perfil de destino, então, você deve instalar o WebSphere Application Server Versão 9.0 em um sistema que corresponda ao perfil de origem antes da criação do jar de migração remota. Após gerar o jar de migração remota, ele funcionará em qualquer sistema que corresponda ao sistema operacional e arquitetura.
    2. Crie o .jar de migração remota.
      1. No prompt de comandos, insira: cd $WAS_HOME/bin/migration/bin
      2. Para criar o arquivo .jar, execute: createRemoteMigrJar.bat(sh) -targetDir <dir for the remote migration jar> . Isto cria o arquivo a seguir: WAS_V90_OS.arch_RemoteMigrSupport.zip. Por exemplo: WAS_V90_windows.x86_RemoteMigrSupport.zip
    3. Prepare o sistema remoto para o comando WasPreUpgrade.
      1. Envie o arquivo .jar ao sistema no qual seu perfil de origem reside.
      2. Extraia o arquivo para um local provisório.
      3. Execute cd para o diretório bin no local provisório.
      4. Agora está pronto para executar o comando WASPreUpgrade com relação ao perfil de origem. No entanto, não emita esse comando até ser solicitado em uma etapa posterior.
  4. Crie o perfil de gerenciador de implementação de destino O perfil de gerenciador de implementação de destino é um novo perfil de gerenciador de implementação que é o destino da migração.
    Evitar Problemas Evitar Problemas: Os nomes de células e de nós do Versão 9.0 devem corresponder aos nomes de células e de nós da configuração anterior. Se você criar células e nós com novos nomes de células e de nós, então, a migração falhará.gotcha
    1. Execute o comando manageprofiles com os parâmetros apropriados para criar um perfil de gerenciador de implementação. Por exemplo:
      [Windows]
      version_8.5_install_root\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]
      version_8.5_install_root/bin/manageprofiles.sh -create 
      -profileName v70toV90dmgr01 -templatePath /opt/WebSphereV90/profileTemplates/
      management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName 
      -cellName currentCellName -hostName mydmgrhost.company.com
  5. Salve a configuração do gerenciador de implementação atual no diretório de backup da migração Para salvar a configuração do gerenciador de implementação atual no diretório de backup de migração, execute o comando WASPreUpgrade. O comando WASPreUpgrade não muda a configuração antiga.
    1. Execute o comando WASPreUpgrade com o parâmetro -machineChange true para salvar a configuração atual do gerenciador de implementação em um diretório de backup de migração. Exemplo:
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90dmgr01 
      \opt\WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90dmgr01 
      /opt/WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      em que mybackup_old_host é o diretório no qual os arquivos de configuração do perfil são copiados em preparação para a migração para o novo host.

      Se você estiver migrando da Versão 8.0 para a Versão 9.0 e seu perfil for um gerenciador de implementação, o perfil da Versão 8.0 será interrompido quando WASPreUpgrade for executado. O gerenciador de implementação é iniciado antes da conclusão de WASPreUpgrade somente se você fornecer -keepDmgrEnabled true na linha de comandos ou especificar a opção correspondente no assistente de Migração.

      Evitar Problemas Evitar Problemas: Se especificar -machineChange true, você deve atualizar a URL do gerenciador de tarefa para todos os recursos (como outros gerenciadores de implementação ou servidores de aplicativos) que são gerenciados pela função do gerenciador de tarefa do gerenciador de implementação Versão 8.0 após a migração. gotcha
    2. Revise avisos ou erros na saída de console e nos logs de WASPreUpgrade. Após o comando WASPreUpgrade ser concluído, verifique na saída de console se há a ocorrência das mensagens Falhou com erros ou Concluído com avisos. Em seguida, verifique os arquivos de log a seguir em busca de quaisquer avisos ou erros:
      • mybackup_old_host/v70toV90dmgr01/logs/WASPreMigrationSummary.log
      • mybackup_old_host/v70toV90dmgr01/logs/WASPreUpgrade.timestamp.log
      • mybackup_old_host/v70toV90dmgr01/logs/WASPreUpgrade.trace

      Se houver erros, corrija os erros e execute o comando WASPreUpgrade novamente. Verifique se os avisos afetam qualquer outra atividade de migração ou de tempo de execução no Versão 9.0.

      Se o comando for concluído com sucesso, não será necessário verificar os logs em busca de erros ou avisos.

  6. Arquive o diretório de backup criado pelo comando WASPreUpgrade
    Evitar Problemas Evitar Problemas: Não use a ferramenta de archive do Windows porque ela não é compatível com uma migração do WebSphere Application Server.gotcha
    1. Use a ferramenta de archive se sua opção para criar um arquivo compactado do diretório de backup. Por exemplo:
      cd /mybackup_old_host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90dmgr01.jar v70toV90dmgr01/
    2. Mova o arquivo arquivado para a máquina de destino.
    3. Crie um diretório na máquina de destino e extraia o arquivo arquivado para o novo diretório. Exemplo:
      mkdir /mybackup_new_host
      cd /mybackup_new_host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      em que mybackup_new_host é o diretório para o qual você está migrando seus arquivos.
  7. Restaure a configuração do gerenciador de implementação anterior Execute o comando WASPostUpgrade a partir do novo diretório bin do perfil de gerenciador de implementação para restaurar a configuração do gerenciador de implementação anterior salva no diretório de backup de migração. Se usar as opções mostradas no exemplo, todas as portas serão transferidas e todos os aplicativos instalados.
    1. Execute o comando WASPostUpgrade para restaurar a configuração do gerenciador de implementação salva no novo perfil do gerenciador de implementação do Versão 9.0. Exemplo:
      [Windows]
      version_8.5_install_root\bin\WASPostUpgrade.bat \
      mybackup_new_host\v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 
      70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -scriptCompatibility TRUE 
      -keepDmgrEnabled TRUE -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_8.5_install_root/bin/WASPostUpgrade.sh /
      mybackup_new_host/v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile
       70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -scriptCompatibility TRUE 
      -keepDmgrEnabled TRUE -username myuser -password mypass
      em que mybackup_new_host é o diretório a partir do qual os arquivos de configuração do perfil de origem são migrados.
    2. Revise os avisos ou erros na saída do console e nos logs do WASPostUpgrade. Após o comando WASPostUpgrade ser concluído, verifique a saída do console para a ocorrência de mensagens Falhou com erros ou Concluído com avisos. Em seguida, verifique os arquivos de log a seguir em busca de quaisquer avisos ou erros:
      • mybackup_new_host/v70toV90dmgr01/logs/WASPostMigrationSummary.log
      • mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.timestamp.log
      • mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.trace

      Se houver erros, corrija os erros e execute o comando WASPostUpgrade novamente. Verifique se os avisos afetam qualquer outra atividade de migração ou de tempo de execução no Versão 9.0.

      Se o comando for concluído com sucesso, não será necessário verificar os logs em busca de erros ou avisos.

    Evitar Problemas Evitar Problemas:
    • O sinalizador de compatibilidade do script em seu gerenciador de implementação deve ser igual ao sinalizador que usado em seus clientes. Salve o valor do sinalizador de compatibilidade do script para uso posterior.
    • Após o comando WASPostUpgrade ser concluído com sucesso, não inicie o novo gerenciador de implementação. Você deve concluir mais algumas etapas antes de iniciar o novo gerenciador de implementação.
    gotcha
  8. Salve a configuração do gerenciador de implementação migrada da Versão 9.0 em um arquivo Para salvar a configuração do gerenciador de implementação migrado do Versão 9.0 para um arquivo, execute o comando backupConfig no gerenciador de implementação do Versão 9.0.
    Evitar Problemas Evitar Problemas: Se encontrar uma falha de migração do nó, é possível restaurar a configuração da célula para o ponto antes da falha. É possível aplicar ações reparatórias e tentar a migração do nó novamente.gotcha
    1. Altere para o diretório deployment_manager_profile_root/bin
    2. Execute o comando backupConfig com os parâmetros apropriados e salve a configuração de perfil do Versão 9.0 em um arquivo. Por exemplo:
      [Windows]
      version_8.5_profile_root\profiles\v70toV90dmgr01\
      bin\backupConfig.bat \mybackup_new_host\v70toV90dmgr01backupMigratedDmgrOnly.zip 
      -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_8.5_profile_root/profiles/v70toV90dmgr01/bin/backupConfig.sh /
      mybackup_new_host/v70toV90dmgr01backupMigratedDmgrOnly.zip -username 
      myuser -password mypass
      em que mybackup_new_host é o local no qual os pontos de restauração da configuração são armazenados.
  9. Pare e desative o gerenciador de implementação no host antigo Assegure que o gerenciador de implementação não seja usado no host antigo. Para obter informações adicionais, consulte

    Para obter mais informações, consulte Comando clientUpgrade

    .
    1. Pare o gerenciador de implementação no host antigo.
    2. Desative o gerenciador de implementação no host antigo. Para desativar esse gerenciador de implementação, você deve renomear o arquivo serverindex.xml associado, conforme indicado nas informações a seguir:
      Nome antigo
      $PROFILE_ROOT/config/cells/cell_name/nodes/deployment_manager_node_name/serverindex.xml
      Novo nome
      $PROFILE_ROOT/config/cells/cell_name/nodes/deployment_manager_node_name/serverindex.xml_disabled
  10. Inicie o gerenciador de implementação do Versão 9.0 Inicie o gerenciador de implementação no novo host.
    1. Mude para o novo diretório deployment_manager_profile_root/bin da Versão 9.0.
    2. Execute o comando startManager.
    3. Enquanto o gerenciador de implementação estiver em execução, verifique o arquivo SystemOut.log para avisos ou erros.
      Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.
      Verifique os avisos para ver se eles afetam qualquer atividade de migração do nó ou de tempo de execução quando o gerenciador de implementação do Versão 9.0 for iniciado.
    4. Assegure que o gerenciador de implementação do Versão 9.0 seja iniciado com sucesso.
  11. Sincronize manualmente todos os nós Você deve sincronizar os nós antigos com o novo gerenciador de implementação do Versão 9.0. Assegure que o gerenciador de implementação do Versão 9.0 no novo host esteja em execução. Você deve efetuar login na máquina que contém os nós antigos e executar o comando syncNode.
    1. Pare o agente do nó.
    2. Obtenha o host e o número da porta do gerenciador de implementação e atualize o arquivo node_agent_profile_root/properties/wsadmin.properties. Mude o valor de com.ibm.ws.scripting.host para o novo host. Mude o valor de com.ibm.ws.scripting.port para a nova porta.
    3. Execute o comando syncNode a partir do diretório bin. Por exemplo:
      [Windows]
      node_agent_install_root\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      node_agent_install_root/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
    4. Inicie o agente do nó se a sincronização for bem-sucedida.
  12. Migre plug-ins para servidores da web
    1. Assegure que o gerenciador de implementação do Versão 9.0 esteja em execução.
    2. Faça upgrade da versão do plug-in do servidor da web que é usado na célula.
    3. Consulte as informações de apoio que são aplicáveis para seu tipo e sua versão do servidor da web.
  13. Migre instalações do aplicativo cliente Migre recursos do cliente para recursos no nível do Versão 9.0. Se o cliente do WebSphere Application de origem for da Versão 7.0, deve-se também executar os comandos WASPreUpgrade e WASPostUpgrade para migrar as configurações de segurança existentes.
    Evitar Problemas Evitar Problemas: O comando clientUpgrade não é suportado para migrações entre sistemas operacionais. Esta etapa aplica-se somente a máquinas host do WebSphere Application Client. Em qualquer uma de suas máquinas host do cliente, você deve executar a mesma migração de host.gotcha
    1. Identifique todos os hosts clientes que você deve migrar.
    2. Instale o e WebSphere Versão 9.0 Application Client.
    3. Execute o comando clientUpgrade nos arquivos archive corporativos (EAR) do aplicativo cliente.
    4. Execute o comando WASPreUpgrade da Versão 9.0 para salvar as configurações de segurança do aplicativo cliente para um diretório de backup de migração. Exemplo:
      /opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup_client/v70clientToV90 /opt/AppClientV70
    5. Execute o comando WASPostUpgrade da Versão 9.0 para restaurar as configurações de segurança do aplicativo cliente para o novo cliente da Versão 9.0. Exemplo:
      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup_client/v6clientToV90 
      Evitar Problemas Evitar Problemas: O sinalizador de compatibilidade do script em seu gerenciador de implementação deve ser igual ao sinalizador que usado em seus clientes.gotcha
  14. Migrar Nós Estas etapas aplicam-se somente a migrações entre máquinas. Se não estiver executando uma migração entre máquinas de um nó, consulte as informações sobre como migrar os nós em Migrando Células Usando as Ferramentas de Linha de Comandos. Assegure que o gerenciador de implementação do Versão 9.0 esteja em execução. Para cada nó que planeja migrar para Versão 9.0, execute as etapas a seguir:
    Evitar Problemas Evitar Problemas: Para a migração ser bem-sucedida, deve-se usar o mesmo nome do nó de origem, mas um nome de célula temporário diferentepara cada nó que você migrar para o Versão 9.0 ou posterior.gotcha
    1. Instale o WebSphere Application Server Versão 9.0. Instale a versão correta do WebSphere Application Server Network Deployment, Base em cada host de destino. Para obter informações adicionais, consulte a documentação sobre como instalar um ambiente de entrega de aplicativos.
    2. Crie o perfil do nó de destino. Execute o comando manageprofiles com os parâmetros apropriados para criar um novo perfil gerenciado. Por exemplo:
      [Windows]
      version_8.5_install_root\bin\manageprofiles.bat 
      -create -profileName node1 -templatePath \opt\
      WebSphereV90\profileTemplates\managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
      [AIX][HP-UX][Linux][Solaris]
      version_8.5_install_root/bin/manageprofiles.sh 
      -create -profileName node1 -templatePath 
      /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
    3. Use o arquivo .jar de migração remota criado para migrar o gerenciador de implementação para que o comando WASPreUpgrade seja disponibilizado na máquina do nó atual.
      Nota: Esta etapa precisa ser executada somente se o nó de origem e o gerenciador de implementação não estiverem na mesma máquina, e esta etapa pode ser executada somente se a arquitetura da máquina for a mesma.
      Para obter informações adicionais, consulte a etapa 3 deste cenário, Crie o arquivo .jar de migração remota.
    4. Execute o comando WASPreUpgrade com o parâmetro -machineChange true para salvar a configuração do nó X atual em um diretório de backup da migração. Escolha um novo diretório para os arquivos de backup. Por exemplo:
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90node1 
      \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90node1 
      /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
    5. Verifique a saída do console WASPreUpgrade para ocorrência de mensagens de erro e de aviso. As mensagens a seguir podem ser localizadas: "Falhou com erros" ou "Concluído com avisos". Além disso, consulte os arquivos de log a seguir para mensagens de erro ou de aviso:
      • myback_old_host/v70toV90node1/logs/WASPreMigrationSummary.log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.< timestamp >.log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.trace

      Se o comando WASPreUpgrade for bem-sucedido, não será necessário verificar os arquivos de log para mensagens de erro ou de aviso.

    6. Use a ferramenta de archive de sua escolha para criar um arquivo compactado do diretório de backup que foi criado pelo comando WASPreUpgrade. Por exemplo:
      cd /mybackup_old_host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
    7. Mova o arquivo arquivado para a máquina de destino.
    8. Crie um diretório na máquina de destino e extraia o arquivo arquivado para o novo diretório. Exemplo:
      mkdir /mybackup_new_host
      cd /mybackup_new_host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      em que mybackup_new_host é o diretório a partir do qual os arquivos de configuração de perfil são migrados.
    9. Pare os servidores de aplicativos no nó antigo, em seguida, pare o agente do nó no nó antigo.
    10. Pare e desative o nó no host antigo. Assegure que o nó não seja usado no host antigo. Para desativar o nó, você deve renomear o arquivo serverindex.xml associado, conforme indicado nas informações a seguir:
      Nome antigo
      $PROFILE_ROOT/config/cells/cell_name/nodes/node_X/serverindex.xml
      Novo nome
      $PROFILE_ROOT/config/cells/cell_name/nodes/node_X/serverindex.xml_disabled
    11. Execute o comando WASPostUpgrade para restaurar a configuração salva do nó X no novo perfil gerenciado do Versão 9.0. Por exemplo:
      [Windows]
      version_8.5_install_root\bin\WASPostUpgrade.bat \
      mybackup_new_host\v70toV90node1 -profileName v70toV90node1 
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -includeApps TRUE -scriptCompatibility 
      TRUE -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_8.5_install_root/bin/WASPostUpgrade.sh /
      mybackup_new_host/v70toV90node1 -profileName v70toV90node1 
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig 
      TRUE -includeApps TRUE -scriptCompatibility TRUE 
      -username myuser -password mypass
      Evitar Problemas Evitar Problemas: O sinalizador de compatibilidade do script em seu gerenciador de implementação deve ser igual ao sinalizador que usado em seus clientes.gotcha
    12. Verifique a saída de console de WASPostUpgrade para as mensagens a seguir. As mensagens a seguir podem ser localizadas: "Falhou com erros" ou "Concluído com avisos". Além disso, consulte os arquivos de log a seguir para mensagens de erro ou de aviso:
      • mybackup_new_host/v70toV90node1/logs/WASPostMigrationSummary.log
      • mybackup_new_host/v70toV90node1/logs/WASPostUpgrade. <target profile>.< timestamp >.log
      • mybackup_new_host/v70toV90node1/logs/WASPostUpgrade.< target profile name >.trace
      Nota: Se o comando WASPostUpgrade falhar, pode ser necessário restaurar o gerenciador de implementação do Versão 9.0 a partir do arquivo de configuração de backup. Se o processamento de comando WASPostUpgrade executou o comando syncNode, o gerenciador de implementação está ciente de que o nó X foi migrado. O nó X não pode ser migrado novamente até o gerenciador de implementação ter sido restaurado para o estado antes da migração do nó X.
    13. Verifique o arquivo SystemOut.log do gerenciador de implementação do Versão 9.0 para mensagens de erro ou de aviso.
      Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.
    14. Inicie o agente do nó X Versão 9.0 migrado.
    15. Verifique o arquivo SystemOut.log do gerenciador de implementação e do nó X do Versão 9.0 para mensagens de erro ou de aviso.
    16. Opcional: Sincronize a célula se o processo de sincronização automática não estiver ativado.
    17. Opcional: Inicie os servidores de aplicativos apropriados no nó X migrado do Versão 9.0.
    18. Execute o comando backupConfig e salve a configuração de perfil do Versão 9.0 em um arquivo. Por exemplo:
      [Windows]
      version_8.5_profile_root\v70toV90node1\bin\backupConfig.bat 
      \mybackup_new_host\v70toV90node1.zip -username myuser 
      -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      version_8.5_profile_root/v70toV90node1/bin/backupConfig.sh 
      /mybackup_new_host/v70toV90node1.zip -username myuser 
      -password mypass -nostop
      Toda vez que você executar o comando backupConfig em um nó específico, use um novo nome de arquivo de backup.
    19. Salve a configuração do gerenciador de implementação usando o comando backupConfig. No host do gerenciador de implementação do Versão 9.0, altere para o diretório deployment_manager_profile_root/bin. Execute o comando backupConfig e salve a configuração de perfil do Versão 9.0 em um arquivo. Exemplo:
      [Windows]
      version_8.5_profile_root\v70toV90dmgr01\bin\backupConfig.bat 
      \mybackup_new_host\v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip 
      -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_8.5_profile_root/v70toV90dmgr01/bin/backupConfig.sh 
      /mybackup_new_host/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip 
      -username myuser -password mypass
      Nota: Para cada nó migrado, faça backup da configuração do Versão 9.0 Deployment Manager em um novo arquivo de backup.
    20. Repita as etapas anteriores para nós adicionais.

Resultados

Você usou as ferramentas de migração para migrar as configurações de células de uma versão anterior do WebSphere Application Server para novas máquinas host que executam o WebSphere Application Server Versão 9.0.


Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_migrate_remote_commandline
Nome do arquivo: tmig_migrate_remote_commandline.html