Este tópico descreve como substituir uma edição ativa por uma nova.
A nova edição pode ser uma modificação simples no aplicativo, como a correção de um erro ou uma alteração mais significativa. Desde que a nova edição seja retrocompatível, ela pode ser consolidada para substituir a edição ativa sem afetar os clientes existentes.
Para consolidar uma nova edição, primeiro você deve instalar a edição de aplicativo
com as informações da nova edição.
Antes de começar
Antes de iniciar, é necessário ter uma edição de aplicativo instalada e
iniciada.
Por que e quando realizar esta tarefa
Para consolidar uma edição, faça o seguinte:
- Clique em Aplicativos > Instalar Novo Aplicativo.
- Especifique o novo arquivo EAR a ser instalado e clique em Avançar.
- No campo Edição de Aplicativo, especifique as informações de sua
nova edição. Por exemplo, digite 2.0.
- No campo Descrição do Aplicativo, especifique o tipo de
nova edição que está sendo instalada. Por exemplo, digite Segunda
Edição.
- Preencha os campos restantes e clique em Avançar. Para obter
informações adicionais sobre como utilizar o assistente de instalação do aplicativo, consulte o WebSphere Application Server Information Center.
- Na página Mapear Módulos para Servidores, na lista Clusters
e Servidores, selecione o mesmo destino de implementação utilizado para a edição
atual. As mesmas etapas básicas se aplicam para consolidar uma edição, independentemente
do tipo de destino de implementação, cluster dinâmico, cluster estático ou servidor
independente. Para este tutorial, clique no cluster dinâmico BTDC1.
- Na lista Clonar Classes de Trabalho Existentes a partir Desta Edição de Aplicativo,
selecione a classe de trabalho da edição 1.0 e clique em Avançar. Quando
instalar uma edição de aplicativo, uma classe de trabalho padrão será designada a ela.
A classe de trabalho estabelece as regras de roteamento padrão para a edição de aplicativo.
As classes de trabalho de um aplicativo formam a política de roteamento desse aplicativo.
Ao instalar edições subseqüentes, é possível designar uma classe de trabalho de sua
escolha. No entanto, ao efetuar a consolidação de edição, é recomendável manter
as mesmas informações da classe de trabalho. Cada edição tem sua própria definição
de classe de trabalho independente. Para este tutorial, clone a classe de trabalho da edição 1.0 para estabelecer a classe de trabalho para a edição 2.0.
- Conclua o assistente de instalação.
- Salve e sincronize seus nós.
- Clique em Aplicativos > Centro de Controle de Edições.
- Selecione sua nova edição, edição 2.0 e clique em Consolidar.
Selecione Atômico ou Agrupado.
Utilize a consolidação de grupo para substituir edições em membros do cluster de destino em um grupo de um. Como alternativa, você pode efetuar a consolidação de grupo com um tamanho especificado por meio de script. Para obter informações adicionais, consulte AdminTasks
para gerenciamento de edições de aplicativos. Durante a consolidação de grupo, os usuários podem ser atendidos por qualquer edição
até que a nova edição tenha substituído totalmente a antiga. Utilize a consolidação atômica para substituir
uma edição por outra na metade do cluster de uma vez. Isto atende todos os pedidos de usuários
com uma edição consistente do aplicativo. No entanto, isto significa que seu
cluster é executado em meia capacidade. Se seu cluster for muito grande,
a consolidação de grupo poderá atender melhor suas necessidades. O modo atômico também pode ser utilizado com um
único destino de implementação do servidor, com as ações executadas na segunda metade
do cluster que está sendo omitido.
Selecione a estratégia de reconfiguração. A estratégia de reconfiguração
instrui o gerenciador de edições de aplicativos sobre como cada destino de implementação
carrega a nova edição para o tempo de execução do servidor. Utilize uma estratégia Flexível para
reconfigurar o aplicativo, parando ou reiniciando o aplicativo em cada servidor do
cluster conforme a próxima edição substitui a antiga nesse servidor.
Com a reconfiguração flexível, as bibliotecas nativas não são descarregadas da memória. A reconfiguração
flexível geralmente é segura para aplicativos que não utilizam bibliotecas nativas. Quando a reconfiguração flexível
for utilizada em um ambiente de produção, monitore o processo do servidor de aplicativos
para assegurar que exista memória virtual suficiente.Uma reconfiguração brusca recicla todo o
servidor de aplicativos, atualizando a memória do processo e as bibliotecas nativas
utilizadas pelo aplicativo. Isto evita o esgotamento do armazenamento virtual
e permite que novas versões de bibliotecas nativas sejam carregadas. Ao consolidar uma
edição de aplicativo que esteja acompanhada por novas versões de bibliotecas nativas
das quais ela depende, é necessário selecionar a reconfiguração brusca como sua
estratégia de reconfiguração. Utilize uma estratégia Brusca para reconfigurar o aplicativo, parando ou
reiniciando cada servidor do cluster conforme a próxima edição substitui a edição
antiga nesse servidor.
- Configurar o Intervalo de Drenagem em Segundos.
O intervalo de drenagem especifica o período de tempo que um servidor de aplicativos
atende clientes com afinidade para esse servidor após o início do processo de consolidação
e antes do início da estratégia de reconfiguração. Afinidades, como transação,
atividade e escopo de compensação e atividades desconhecidas no WebSphere Extended
Deployment aumentam o intervalo de drenagem efetivo, porque o servidor não
será parado até que estas unidades de trabalho estejam concluídas. Os aplicativos com atividades
desconhecidas no Extended Deployment podem utilizar a notificação iniciada pelo quiesce do AppEditionManager
MBean como um acionador para iniciar o processamento de encerramento e explorar
o intervalo de drenagem como um período de tempo durante o qual o encerramento será concluído.
- Clique em OK. Isto ativa uma substituição sem interrupção
de edição 1.0 por edição 2.0.
Resultado
Uma edição que está na validação é consolidada no destino de implementação original
e o ambiente clonado é excluído.
Se ocorrer uma falha durante a consolidação,
o gerenciador de edições de aplicativos tentará desfazer as ações desempenhadas.
Por exemplo, se a edição 1.0 tiver sido substituída
pela edição 2.0 em dois de três servidores em um cluster
de três membros, e ocorrer uma falha ao substituir a edição no terceiro servidor,
o gerenciador de edições de aplicativos substituirá a edição 2.0 pela edição
1.0 no primeiro e segundo servidores.
O que fazer depois
Para ver os resultados, retorne ao centro de controle de edições, selecione
seu aplicativo e clique em
Gerenciar Implementações de Edições. A
edição
2.0 substitui a
1.0 como a edição ativa no destino de
implementação
BTDC1. A nova edição é iniciada automaticamente, porque
ela substitui uma edição em execução.
Quando uma edição de aplicativo no modo de validação
for consolidada, os nomes de ligações deverão ser alterados novamente para os originais,
por exemplo: /clusters/cluster1-validation/jdbc/CustomerData deve
ser alterado novamente para /clusters/cluster1/jdbc/CustomerData.