Ao executar uma implementação em uma edição, você substitui uma edição ativa por uma nova edição. A nova edição pode ser uma modificação simples para o aplicativo ou conter uma mudança mais substancial.
Se a nova edição for compatível com versões anteriores, você poderá executar um lançamento para substituir a edição ativa sem afetar os clientes existentes. Para executar uma implementação em uma nova edição, você deve primeiro instalar a edição do aplicativo com as informações da nova edição.
Antes de Iniciar
Você deve ter uma edição de aplicativo instalada e iniciada e ter privilégios de
configurador ou
administrador para executar uma implementação.
- A execução de uma implementação falha quando dois IDs do usuário nos dois consoles administrativos tentam executar o processo em paralelo.
- Sintonize as propriedades do conector SOAP para configurar o valor de tempo limite do pedido para o gerenciador de implementação para ser maior do que o tempo total necessário para execução de uma transferência em seu sistema, e reinicie o gerenciador de implementação. Não configurar a propriedade pode fazer com que um processo de lançamento falhe quando o valor de requestTimeout expirar. A fórmula para estimar o valor a ser configurado é número-grupos-para-transferência * (intervalo-drenagem + tempo-limite-quiesce-interno-aproximadamente-5minutos + tempos-reinicialização-aplicativo-ou-servidor-aproximadamente-10minutos). Alternativamente, é possível configurar o valor como zero para desativar o tempo limite.
- Se estiver executando uma transferência dentro do console administrativo, configure a expiração de sessão para o console administrativo para um valor maior que o total de tempo necessário para todo o processo de transferência terminar. Multiplique o valor de tempo limite do pedido pela quantidade de grupos processados durante a transferência. Para obter mais informações sobre expiração de sessão para o console administrativo, leia sobre alteração da expiração da sessão do console.
- É necessário definir uma política de roteamento de múltiplos clusters para cada nova edição que você instalar antes de executar uma transferência. Use as tarefas administrativas para incluir políticas de roteamento de múltiplos clusters para suas novas edições. Para obter informações sobre políticas de roteamento de diversos clusters, leia sobre regras para tarefas administrativas de política de roteamento de ODR.
Sobre Esta Tarefa
Você também pode usar o gerenciador de edição de aplicativo se você desejar executar um lançamento nos aplicativos em lote. Estes são os aplicativos Java Enterprise Edition 5 (Java EE 5) que são compatíveis com um dos modelos de programação do lote.
Procedimento
- Instale a nova edição. Utilize as mesmas etapas que são descritas em instalando uma edição de aplicativo, mas especifique as novas informações de edição. Por exemplo, digite 2.0 no campo Edição de Aplicativo e Segunda Edição no campo Descrição do Aplicativo.
Selecione os mesmos destinos de implementação que são utilizados para a edição atual.
- Salve e sincronize seus nós.
- Especifique as configurações de transferência. Clique em . Selecione a nova edição, por exemplo, 2.0 e clique em Implementar.
Especifique as configurações a seguir para aplicativos corporativos ou outros aplicativos middleware:
- 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, é possível executar a transferência em grupo com um tamanho de
grupo especificado por meio de script. Para obter mais informações sobre a transferência em grupo, leia sobre as tarefas administrativas de gerenciamento de edição de aplicativo. 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.
Utilize uma estratégia de reconfiguração 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 tanto a memória do processo quanto 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 de 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 Intelligent Management prolongam o intervalo de drenagem efetivo, porque o servidor não será parado até que estas unidades de trabalho estejam concluídas. Aplicativos com atividades desconhecidas para o Intelligent Management podem usar a notificação iniciada em modo quiesce do MBean AppEditionManager como um acionador para iniciar o processamento de encerramento e usar o intervalo de drenagem como um período de tempo no qual concluir o encerramento. 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. Configure esse valor como
0 para esperar a conclusão de sessões para todas as solicitações em andamento. Para esperar a conclusão do
intervalo de drenagem ou de sessões para todas as solicitações em andamento, configure o intervalo de drenagem como
um valor maior que 0.
O
gerenciador de quiesce de edição de aplicativo pode não aguardar a duração integral
do intervalo de drenagem. As estatísticas de Performance Monitoring Infrastructure (PMI)
estão disponíveis para o gerenciador de quiesce para determinar se todas as
solicitações ativas em um servidor foram colocadas em modo quiesce. Se todas as solicitações forem
colocadas em modo quiesce antes do intervalo de drenagem, o gerenciador de quiesce de edição
de aplicativo não precisará aguardar o intervalo de drenagem integral. Para forçar uma reconfiguração flexível a aguardar o intervalo de drenagem inteiro, é possível configurar a propriedade de sistema appedition.rollout.softreset.fulldrainageinterval como true no gerenciador de implementação.
O intervalo de drenagem permite que sessões existentes sejam concluídas. No entanto, no final do intervalo de drenagem, um período existe durante o qual as solicitações 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 quiesce. 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 utilizar a propriedade customizada com.ibm.ws.webcontainer.ServletDestroyWaitTime para definir a quantidade de tempo que o contêiner de web aguarda as solicitações serem concluídas. Para obter informações adicionais, leia sobre as propriedades customizadas de contêiner da web.
É possível utilizar a propriedade customizada com.ibm.ejs.sm.server.quiesceTimeout para definir a quantidade de tempo que a instância do servidor aguarda as solicitações serem concluídas antes de iniciar o encerramento. Para obter mais informações sobre a propriedade de tempo limite, leia sobre as propriedades customizadas da Java virtual machine. Você deve configurar tanto as propriedades customizadas com.ibm.ws.webcontainer.ServletDestroyWaitTime e com.ibm.ejs.sm.server.quiesceTimeout em cada uma das instâncias do servidor nas quais as edições do aplicativo forem implementadas.
Especifique as configurações a seguir para os aplicativos SIP (Session Initiation Protocol):- Escolha uma estratégia de suspensão. A estratégia de suspensão especifica como servidores antigos ou membros de cluster que hospedam a edição atual são removidos. Essa configuração não afeta a nova edição que está sendo transferida.
- Colocar em modo quiesce os membros de servidor ou de cluster após todas as sessões ou diálogos ativos serem concluídos:
- Remove o membro de servidor ou de cluster quando todas as sessões e diálogos ativos desse membro de servidor ou de cluster
forem concluídas.
- Colocar em modo quiesce um membro de servidores ou cluster após o intervalo especificado:
- Remove o membro de servidor ou de cluster após um período de tempo especificado.
Especifique um período de tempo, em segundos, minutos ou horas.
Atenção: A execução de uma implementação não é suportada para aplicativos SIP que estão implementados em um cluster dinâmico que foi convertido de um cluster estático.
- Inicie a implementação. Clique em OK.
Esta ação ativa uma substituição sem interrupção da edição anterior pela nova edição.
Resultados
Para uma edição que não está no modo de validação, a nova edição substitui a edição atual após a conclusão da transferência.
Uma edição que está na validação é transferida no destino de implementação original
e o ambiente clonado é excluído. As regras de roteamento são atualizadas para começar o roteamento para a nova edição.
Durante o processo de lançamento do aplicativo, os erros que ocorrerem
no primeiro grupo de destinos serão manipulados de forma diferente dos erros que ocorrerem em grupos posteriormente. Nos
lançamentos atômicos, o primeiro grupo é a primeira metade dos destinos em que a nova edição é ativada. Nos lançamentos do
grupo, o primeiro grupo refere-se ao primeiro grupo de destinos no qual a nova edição é ativada.
Se ocorrer um erro
durante o lançamento no primeiro grupo de destinos (por exemplo, um aplicativo ou um servidor falhar ao iniciar),
o processo de lançamento falhará. A edição de aplicativo atual
permanece no estado ativo.
Se ocorrer um erro
após o lançamento no primeiro grupo de destinos,
o processo de lançamento será concluído com sucesso. A nova
edição do aplicativo está agora no estado ativo. A edição de aplicativo antigo
muda para o estado inativo.
O que Fazer Depois
Para validar os resultados, clique em . A nova edição é a edição ativa no destino de implementação. A nova edição é iniciada automaticamente, porque
ela substitui uma edição em execução.
Quando você executa uma implementação em uma edição no modo de validação, os nome de ligação são alterados novamente para os valores originais. Por exemplo, /clusters/cluster1-validation/jdbc/CustomerData é alterado novamente para /clusters/cluster1/jdbc/CustomerData.