WebSphere Virtual Enterprise, Version 6.1.1
             Sistemas Operacionais: AIX,, HP-UX, Linux, Solaris, Windows


Executando uma Implementação em uma Edição

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. Desde que a nova edição seja compatível com versões anteriores, é possível executar uma implementação 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 Começar

Você deve ter uma edição de aplicativo instalada e iniciada e ter privilégios de configurador ou administrador para executar uma implementação.
Evitar Problemas: A execução de uma implementação falha quando dois IDs do usuário nos dois consoles administrativos tentam executar o processo em paralelo. gotcha
Evitar Problemas: 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. Se a propriedade não for configurada pode fazer com que um processo de transferência falhe quando o valor 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, você pode configurar o valor como zero para desativar o tempo limite.
  • Se estiver executando a transferência usando a ferramenta wsadmin, ajuste o valor de tempo limite do pedido configurando a propriedade com.ibm.SOAP.requestTimeout no perfil do gerenciador de implementação soap.client.props. O valor-padrão é 180 segundos e deve ser aumentado adequadamente.
  • Se estiver executando a transferência usando o console administrativo, ajuste o valor de tempo limite de pedido clicando em Administração do sistema > Gerenciador de implementação > Serviços de Administração > Conectores JMX > SOAPConnector > Propriedades Customizadas > requestTimeout. O valor-padrão é de 600 segundos e deve ser aumentado adequadamente.
Para obter informações adicionais, consulte Propriedades do conector Java Management Extensions.gotcha

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 informações adicionais, consulte Alteração da expiração da sessão do console.

[Version 6.1.1 and later] Evitar Problemas: É 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. Consulte o Regras para Tarefas Administrativas de Política de Roteamento do ODR para obter informações adicionais. gotcha

Sobre Esta Tarefa

Você também pode usar o gerenciador de edição de aplicativo, se estiver usando o componente do Compute Grid e desejar executar uma implementação no aplicativos de Compute Grid. Eles são os aplicativos Java Enterprise Edition 5 (Java EE 5) que são compatíveis com um dos modelos de programação de grade.

Procedimento

  1. Instale a nova edição. Use as mesmas etapas descritas no Instalando uma Edição , mas especifique as informações da nova 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.
  2. Salve e sincronize seus nós.
  3. Especifique as configurações de transferência. Clique em Aplicativos > Centro de Controle de Edição > application_name. 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 de middleware:

    1. 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
    2. 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).

    3. 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.

    Especifique as configurações a seguir para os aplicativos SIP (Session Initiation Protocol):
    1. 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.
      • Suspenda o servidor ou de membros de cluster depois que todas as sessões ou todos os diálogos ativos forem concluídos.: Remove o servidor ou o membro de cluster quando todas as sessões e todos os diálogos ativos para o servidor ou o membro de cluster são concluídos.
      • Suspenda os servidores ou do membro de cluster após o intervalo especificado: Remove o servidor ou o membro 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.
  4. 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.

Para um aplicativo Compute Grid, após o tempo de drenagem, o planejador de tarefas cancelará essas tarefas (do aplicativo de transferência) que ainda estão em execução nos terminais em suspensão.

O que fazer depois

Para validar os resultados, clique em Aplicativos > Centro de Controle de Edição > application_name. 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.

Atenção: A validação da edição não funcionará corretamente para aplicativos implementados em um cluster dinâmico que tenha sido convertido de um cluster estático.



Conceitos relacionados
Conceitos sobre o Gerenciador de Edição de Aplicativo
Tarefas relacionadas
Instalando uma Edição
Executando um Retrocesso em uma Edição
Ativando Edições Simultâneas
Validando uma Edição
Referências relacionadas
Políticas de Serviço e de Roteamento
Funções e Privilégios Administrativos
Tarefas Administrativas de Gerenciamento da Edição de Aplicativos
Tópico de Tarefa    

Termos de Uso | Feedback

Última atualização: 24/09/2009 14h14min58s EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/appedition/tappedroll.html