WebSphere Extended Deployment Compute Grid, Version 6.1.1
             Sistemas Operacionais: AIX,, HP-UX, Linux, Solaris, Windows ,


Transferindo uma Edição

Para utilizar o gerenciador de edição de aplicativos para transferir aplicativos do Compute Grid, é necessário ter o componente WebSphere Extended Deployment Operations Optimization. Aplicativos do Compute Grid são aplicativos J2EE (Java 2 Platform Enterprise Edition) compatíveis com um dos modelos de programação de grade. Ao transferir uma edição, você substitui uma edição ativa por uma nova.

Antes de Começar

É necessário ter uma edição de aplicativo instalada e iniciada e ter os privilégios administrativos configurador ou administrador para executar essa tarefa.
Nota: A transferência de edição de aplicativo falhará quando dois IDs de usuário em dois consoles administrativos tentarem uma transferência de edição de aplicativo paralela.

Sobre Esta Tarefa

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.

Procedimento

  1. Instale a nova edição. Especifique suas novas informações sobre a 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 sua nova edição, por exemplo, 2.0, e clique em Transferir.

    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. A transferência em grupo é a opção mais comum, sendo útil quando o cluster é grande. 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 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 for muito grande, considere a divisão da transferência em grupos menores, utilizando a transferência em grupo. O modo atômico também pode ser utilizado 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.

    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.

      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. A reconfiguração flexível é a opção mais comum e a reconfiguração de aplicativo de melhor desempenho, porque carrega a 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ê transferir uma edição de aplicativo 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 JIT (determinado momento).

    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 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. Isso é desnecessário para sessões persistentes, por exemplo, aquelas reservadas no banco de dados ou replicadas através de DRS, mas é importante para sessões temporárias (na memória). 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.

    Especifique as configurações a seguir para os aplicativos SIP (Session Initiation Protocol):
    1. Escolha uma estratégia de quiesce. A estratégia de quiesce 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.
      • Faça quiesce do 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.
      • Faça quiesce de 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.
  4. Ative a transferência. Clique em OK. Esta ação ativa uma substituição sem interrupção da edição mais antiga 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. Para um aplicativo do Compute Grid, após o tempo de esvaziamento, o planejador de tarefas cancelará as tarefas (do aplicativo de transferência) que ainda estiverem em execução nos terminais em quiesce.

O que fazer depois

Para validar os resultados, clique em Aplicativos > Centro de Controle de Edição > application_name. A nova edição deve ser 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 uma edição de aplicativo no modo de validação é transferida, os nomes de ligação devem ser alterados novamente para os valores originais. Por exemplo: /clusters/cluster1-validation/jdbc/CustomerData deve ser alterado novamente para /clusters/cluster1/jdbc/CustomerData.




Informações relacionadas
Gerenciando Tarefas de Compute Grid e seu Ambiente
Tópico de Tarefa    

Termos de Uso | Feedback

Última atualização: 24/09/2009 14h24min35s EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/scheduler/tcgappedroll.html