Selecione o tipo de transferência Atômico ou Agrupado.
Utilize transferência em grupo para substituir edições em membros do cluster de destino em um grupo de um. Uma transferência em grupo é a opção mais típica e é útil quando o cluster contém quatro ou mais membros.
Como
alternativa, você pode executar a transferência em grupo com um tamanho de
grupo especificado por meio de script. Para obter informações adicionais, leia sobre o Tarefas Administrativas de Gerenciamento da Edição de Aplicativos
. Quando a nova edição se torna
disponível durante a transferência em grupo, todos os pedidos são direcionados à nova
edição.
Utilize transferência atômica para substituir
uma edição por outra na metade do cluster de uma vez. Esse tipo de transferência atende a todos os pedidos de usuários
com uma edição consistente do aplicativo. Como todos os pedidos de usuário atendem a uma edição consistente, seu cluster é executado com metade da capacidade. Se o cluster tiver quatro ou mais membros, considere a divisão do cluster em grupos menores executando uma transferência em grupos. O modo atômico também é usado com um destino de implementação de servidor único. Em
um destino de implementação de servidor único, as ações que são executadas na segunda
metade do cluster são omitidas. Se você parar os destinos de implementação antes de iniciar a implementação atômica, os destinos de implementação serão iniciados quando a nova edição substituir a edição ativa, independentemente da estratégia de reconfiguração escolhida.
Esse procedimento fornece melhor disponibilidade para os pedidos que são atendidos durante o período de implementação.
Evitar Problemas: Antes de executar uma implementação atômica, determine a capacidade de carregamento do cluster do servidor de destino. A execução de uma implementação atômica ativa a nova edição na metade do cluster primeiro e, em seguida, ativa a edição na metade restante do cluster. Enquanto a primeira metade do cluster for mantida off-line e atualizada, os pedidos de aplicativos serão roteados para a segunda metade do cluster. Verifique se a metade do cluster pode tratar o carregamento inteiro durante o período de implementação.
gotcha
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. Use 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.
A reconfiguração flexível é a opção mais comum e a reconfiguração de aplicativo de
melhor desempenho, porque resulta no carregamento da nova edição reciclando o aplicativo no servidor de
aplicativos em execução. O servidor permanece ativo durante esse processo. 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 estratégia de reconfiguração Brusca recicla todo o
servidor de aplicativos do cluster à medida que a próxima edição substitui a edição anterior no servidor, atualizando a memória do processo e as bibliotecas nativas utilizadas pelo aplicativo. Essa estratégia evita o esgotamento do armazenamento virtual
e permite que novas versões de bibliotecas nativas sejam carregadas. Selecione a reconfiguração brusca como sua estratégia de reconfiguração quando você executar uma implementação em uma edição que dependa de novas versões de bibliotecas nativas ou outras dependências que são atualizadas apenas reciclando todo o servidor de aplicativos ou se você tiver aplicativos grandes que consomem muita memória para compilação just-in-time (JIT).
Configurar o Intervalo de Drenagem em Segundos.
O intervalo de drenagem fornece às sessões de HTTP tempo para concluir antes de o aplicativo ou o servidor ser reconfigurado. Esse intervalo especifica o período de tempo que o gerenciador de edição do aplicativo aguarda antes de iniciar a estratégia de reconfiguração. Afinidades, como transação, atividade e escopo de compensação e atividades desconhecidas para o WebSphere Virtual Enterprise prolongam 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 para o WebSphere Virtual Enterprise podem usar a notificação iniciada pela suspensão 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. Esse processo é desnecessário para sessões persistentes, por exemplo, aquelas reservadas no banco de dados ou replicadas através do Distributed Resource Scheduler (DRS) de VMware, mas é importante para sessões temporárias (na memória).
O objetivo do intervalo de drenagem é permitir que pedidos com afinidades e pedidos em andamento sejam concluídos. Para evitar a perda de sessões temporárias, defina o intervalo
de drenagem para exceder o intervalo de tempo limite de sessão do aplicativo. Depois de
iniciada a transferência, conforme cada servidor for atualizado, ele será marcado
como inelegível para iniciar qualquer nova sessão. Defina esse valor como 0
para não aguardar a conclusão das sessões.
Para uma reconfiguração flexível, o gerenciador de suspensão de edição de aplicativo aguarda a duração integral do intervalo de drenagem para garantir que quaisquer sessões existentes sejam concluídas. O gerenciador de suspensão de edição de aplicativo aguardará, se alguma sessão pendente existir ou se as sessões forem concluídas antes do tempo de intervalo de drenagem definido.
Para a reconfiguração bruta, o gerenciador de suspensão de edição de aplicativo pode não aguardar a duração completa do intervalo de drenagem. As estatísticas de Performance Monitoring Infrastructure (PMI) estão disponíveis para o gerenciador de suspensão para determinar se todos os pedidos ativos em um servidor foram suspensos.
Se todos os pedidos forem suspensos antes do intervalo de drenagem, o gerenciador de suspensão de edição de aplicativo não precisará aguardar pelo intervalo de drenagem integral.
O intervalo de drenagem permite que sessões existentes sejam concluídas. No entanto, no final do intervalo de drenagem, existe um período de tempo durante o qual os pedidos em andamento ainda podem chegar. Nesses casos, o On Demand Router (ODR) fornece um valor de tempo limite de 60 segundos no qual concluir a operação de suspensão. Se os pedidos terminarem em 60 segundos ou os 60 segundos vencerem, o aplicativo ou o servidor será interrompido, no caso de uma estratégia de reconfiguração bruta. Em seguida, se os pedidos em andamento ainda não terminaram, o WebSphere Application Server Network Deployment fornecerá um tempo de fechamento de 60 segundos antes de interromper os aplicativos ou a instância do servidor.
Para estratégias de reconfiguração brusca, o WebSphere Application Server Network Deployment oferece um tempo de quiesce de 180 segundos antes de parar a instância do servidor.
É possível usar a propriedade customizada com.ibm.ws.webcontainer.ServletDestroyWaitTime para definir a quantidade de tempo que o contêiner de Web aguarda para que os pedidos sejam concluídos. Para obter informações adicionais, consulte Propriedades Customizadas do Contêiner de Web.
Você pode usar a propriedade customizada com.ibm.ejs.sm.server.quiesceTimeout para definir a quantidade de tempo que a instância do servidor espera pela conclusão dos pedidos antes de iniciar o encerramento. Para obter informações adicionais, consulte Propriedades customizadas da Java Virtual Machine. É necessário configurar tanto a propriedade customizada com.ibm.ws.webcontainer.ServletDestroyWaitTime quanto com.ibm.ejs.sm.server.quiesceTimeout em cada uma das instâncias do servidor nas quais as edições do aplicativo forem implementadas.