Para consolidação manual do aplicativo, o roteamento da carga de trabalho é controlado
parando o servidor de aplicativos no qual o membro de cluster que está sendo atualizado
reside. Isso resulta em um
repouso desse servidor. Todos os pedidos existentes já no servidor têm permissão para
serem concluídos, mas nenhum pedido novo será aceito. O Sysplex Distributor e o plug-in de servidor da web do WebSphere Application Server roteiam o trabalho para outro local que não o servidor que foi colocado em modo quiesce. Após todo o trabalho ser concluído,
você inicia o processo de atualização do aplicativo nesse servidor.
Antes de Iniciar
Determine quais servidores de aplicativos estão sendo hosts dos membros de cluster
que precisam de atualização.
Sobre Esta Tarefa
Se você tiver um aplicativo de alta disponibilidade cujas atualizações deseja controlar manualmente, poderá usar este processo ou usar o comando Modify do MVS para pausar os listeners dos servidores de aplicativos afetados. Consulte informações sobre como pausar um servidor de aplicativos para atualizar manualmente um aplicativo de alta disponibilidade.
Para controlar manualmente a consolidação do aplicativo e o roteamento da carga de trabalho em um ambiente de alta disponibilidade:
Procedimento
- Desative todos os formulários de sincronização automática em todos os nós
na célula e salve as alterações. Execute um dos seguintes processos para concluir essa etapa:
- No console
administrativo:
- Clique em node_agent_name > Serviço de
sincronização de arquivos.
- Cancele a seleção das opções Sincronização Automática e Sincronização de Inicialização.
- Selecione a opção Sincronizar Alterações com Nós.
- Clique em Salvar.
- Utilize o script wsadmin para especificar os seguintes comandos e, em
seguida, reinicie todos os agentes de nó afetados:
set node NODE
set na_id [$AdminConfig getid /Node:$node/Server:nodeagent/]
set syncServ [$AdminConfig list ConfigSynchronizationService $na_id]
$AdminConfig modify $syncServ {{autoSynchEnabled false}}
$AdminConfig modify $syncServ {{synchOnServerStartup false}}
$AdminConfig save
set nodeSync [$AdminControl completeObjectName type=NodeSync,node=$node,*]
$AdminControl invoke $nodeSync sync
Evitar Problemas: Para um ambiente de produção, é
compreensível que sempre execute o agente de nó com a sincronização automática desativada. Entretanto, é aconselhável que a sincronização de inicialização seja ativada para o
agente de nó de modo que possa adquirir atualizações de configuração que ocorrem quando o
agente de nó está desativado. A Sincronização de Inicialização pode permanecer ativada, desde que você assegure
que não reiniciará o agente do nó manualmente, por meio da automação, ou por meio do gerenciador de reinicialização
automática durante o processo de atualização do aplicativo.
gotcha
- Atualize o aplicativo no Repositório de Configuração Principal no
servidor do gerenciador de implementação. Execute um dos seguintes processos para concluir essa etapa:
- No console
administrativo:
- Clique em Aplicativos > Aplicativos Corporativos.
- Selecione o aplicativo que você deseja atualizar.
- Conclua o processo de atualização do aplicativo.
- Salve suas alterações na configuração master. NÃO selecione a opção Sincronizar
Alterações com Nós.
- Utilize o script wsadmin para emitir o seguinte comando:
set app_loc /path/to/app
set app_options {application options ie: -appname app}
set options [list -update] lappend options $app_options
$AdminApp install $app_loc $options
$AdminConfig save
Neste momento, você atualizou a versão do seu
aplicativo (App v2 na seguinte figura) na sua Configuração Mestre. Entretanto, a versão original do seu aplicativo (App v1 na seguinte figura) ainda está
sendo executada no cluster que possui membros Cluster no LPAR1 e LPAR2.
Figura 1. Instalar
Atualização do Aplicativo.
Esta figura ilustra o primeiro estágio de uma
atualização de aplicativo em um ambiente de alta disponibilidade.
- Pare o Servidor de Aplicativos no LPAR1 e sincronize manualmente o nó para a versão atualizada do aplicativo. É possível que essa etapa leve um tempo para ser concluída, porque o servidor deve esperar a conclusão de todos os itens de trabalho atualmente designados antes de encerrar.
Execute um dos seguintes processos para concluir essa etapa:
- Sincronize o nó. Execute um dos seguintes processos para concluir essa etapa:
Conforme ilustrado na seguinte figura, a versão atualizada do aplicativo
(App v2) agora reside no nó no LPAR1.
Figura 2. Atualize o nó no LPAR1.
Esta figura ilustra o primeiro
estágio de uma atualização de aplicativo em um ambiente de alta disponibilidade com dois
LPARs.
- Reinicie o servidor no LPAR1. Execute um dos seguintes processos para concluir essa etapa:
- No console
administrativo:
- Clique em .
- Selecione o servidor que deseja iniciar e clique em INICIAR.
- Utilize o script wsadmin para emitir os seguintes comandos:
set node NODE
set server SERVER
$AdminControl startServer $server $node
- Emita o seguinte comando a partir do MVS Console:
START procname,JOBNAME=server_short_name.ENV=cell_short_name.node_short_name.server_short_name
Por
exemplo:START BBO6ACR,JOBNAME=BBOS001,ENV=PLEX1.SY1.BBOS001
Quando o servidor ficar ativo novamente, será executado na nova versão do aplicativo (App v2), Figura 3. Reinicie o Servidor no LPAR1.
Esta figura ilustra a conclusão do primeiro estágio de uma atualização de aplicativo em um ambiente de alta disponibilidade.
- Com a nova versão do aplicativo sendo executada no LPAR1, repita as três
etapas anteriores nos outros LPARs no cluster para atualizá-las com a nova versão do aplicativo. A seguinte figura ilustra como será a aparência de sua
configuração em um cluster de dois LPARs.
Figura 4. Atualize o nó no LPAR2.
Esta figura ilustra o
segundo estágio de uma atualização de aplicativo em um ambiente de alta disponibilidade.
Resultados
O processo de atualização do aplicativo será concluído quando a nova versão do aplicativo estiver sendo executada em todos os membros do cluster. A figura a seguir ilustra como será a aparência de um cluster de dois LPARs depois que o servidor for reiniciado no LPAR2.
Figura 5. Reinicie o Servidor no LPAR2.
Esta figura ilustra como será a aparência de um cluster de dois LPARs depois que o servidor for reiniciado no LPAR2.