[AIX Solaris HP-UX Linux Windows][IBM i]

Clusters de Backup

Os clusters de backup espelham os clusters de servidores principais. O suporte de cluster espelhado é apenas para pedidos EJB (Enterprise JavaBeans).

Recurso Reprovado Recurso Reprovado: Os clusters de backup estão descontinuados no WebSphere Application Server Versão 9. Em vez de utilizar Clusters de Backup baseados em IIOP através de múltiplas Células usando CoreGroupBridges, você deverá considerar o agrupamento de recursos do EJB com interfaces REST. Em seguida, utilize o balanceamento de carga front-end, como On Demand Router, para equilibrar a carga. depfeat

Quando todos os membros de um cluster não estiverem mais disponíveis para pedidos EJB (Enterprise JavaBeans) de serviço, nenhum cliente que deva interagir com um dos servidores EJB (Enterprise JavaBeans) do cluster funcionará. Os clusters espelhados ativam um cluster EJB (cluster principal) para failover em outro cluster EJB (Enterprise JavaBeans) (cluster de backup) quando nenhum dos servidores de aplicativos EJB (Enterprise JavaBeans) do cluster principal for capaz de atender a um pedido. O cluster de backup permite que o cliente continue funcionando quando todos os membros de cluster no cluster principal não estão disponíveis.

O retorno de falha é automático. Não é necessário iniciar o retorno de falha para o cluster principal após reiniciar os servidores no cluster principal. O cluster de backup pára os pedidos de serviço assim que o cluster principal torna-se disponível. No entanto, todos os gerenciadores de implementação devem estar funcionais para suporte ao cluster de backup e o cluster primário deve ser definido como backup para o cluster de backup.

Para que o cluster de backup transfira os pedidos de serviço com êxito:
  • Os objetos e recursos disponíveis para o cluster principal também devem estar disponíveis para o cluster de backup.
  • É preciso utilizar o mesmo nome de cluster, instalar os mesmos aplicativos, utilizar os mesmos nomes de aplicativos e definir os mesmos recursos do cluster principal no cluster de backup.
  • O cluster principal e o cluster de backup devem residir em células separadas porque um cluster deve ter um nome exclusivo na célula.
  • Os clusters principal e de backup devem possuir um cluster de backup configurado e cada cluster deve especificar o cluster oposto como cluster de backup.

Como os clusters principal e de backup residem em células diferentes, com a versão atual do produto, os clusters residem também em grupos principais diferentes. É necessário configurar o serviço de ponte do grupo principal para permitir a comunicação entre grupos principais. O serviço de ponte do grupo principal elimina o requisito de um gerenciador de implementação em execução e um agente de nó para o suporte ao cluster de backup. No release anterior, se o gerenciador de implementação fosse parado, não era possível redirecionar novos pedidos ao cluster de backup após a falha do cluster principal. Qualquer servidor de ponte do grupo principal configurado na célula que contém o cluster primário pode fornecer informações sobre o cluster de backup. O suporte ao cluster de backup falha somente se os servidores de ponte do grupo principal em uma célula não estiverem em execução.

Para que o failover e o fail back do cluster funcionem conforme esperado, todos os servidores, incluindo o gerenciador de implementação, os agentes de nós e os servidores de aplicativos, do cluster principal e do cluster de backup devem estar em um release e um nível que forneça suporte a cluster espelhado.

O suporte ao cluster espelhado não é configurado por padrão. Para utilizar o suporte ao cluster espelhado, você deve especificar os clusters de backup na configuração. Cada cluster pode ter apenas um cluster de backup, que deve ser configurado antes de ser especificado como um cluster de backup.

Para configurar um cluster de backup em um cluster, você deve especificar um nome e um endereço de auto-inicialização de domínio. O host do bootstrap é o host que contém o gerenciador de implementação no qual o cluster de backup está configurado. A porta de auto-inicialização é a porta de auto-inicialização para esse gerenciador de implementação.

O cluster principal e o cluster de backup devem residir em células separadas. Para colocar clusters espelhados em células separadas, configure o endereço de auto-inicialização de domínio do cluster de backup apropriado. O bootstrap do cluster de backup e a porta determinam qual célula contém o cluster de backup.

É possível configurar um cluster de backup utilizando o console administrativo ou o bean gerenciado por ExtendedCluster (MBean). Para configurar um cluster de backup utilizando o console administrativo:
  • Utilize a guia Configuração na página Endereço de Auto-inicialização de Domínio para definir estaticamente o cluster de backup; o valor estático é consumido toda vez que o gerenciador de implementação é iniciado.
  • Utilize a guia Tempo de Execução na página Endereço de Auto-inicialização de Domínio para definir o cluster de backup quando o cluster estiver em execução. Quando o gerenciador de implementação pára, as informações que definem o cluster de backup de tempo de execução são descartadas.

Como os clusters principal e de backup residem em células diferentes, com a versão atual do produto, os clusters residem também em grupos principais diferentes. Você deve configurar o serviço de ponte do grupo principal para permitir a comunicação entre grupos principais. Utilize um grupo de ponto de acesso para unir os dois grupos principais. No gerenciador de implementação para a célula principal, configure um grupo de ponto de acesso que possui o ponto de acesso do grupo principal para a célula de backup como um ponto de acesso do período. No gerenciador de implementação para a célula de backup, crie um grupo de ponto de acesso que possui o mesmo nome do grupo de ponto de acesso criado na célula principal. Inclua um ponto de acesso de período que se refira ao ponto de acesso de grupo principal na célula principal.

Se estiver configurando um cluster de backup utilizando o ExtendedCluster MBean, é possível alterar apenas a configuração de tempo de execução. A alteração do MBean não afeta a configuração estática. É possível utilizar a operação setBackup no ExtendedCluster MBean para alterar a configuração do tempo de execução. Por exemplo, é possível utilizar o seguinte código Java para definir o cluster de backup do cluster principal:

ac.invoke(extendedCluster, "setBackup", new Object[] {
  backupClusterName, backupBootstrapHost, backupBootstrapPort},
  new String[] {
    "java.lang.String", "java.lang.String", "java.lang.Integer"});

Nessa amostra, ac é AdminClient e extendedCluster é o ExtendedClusterObjectName para o cluster principal.

Há dois cenários que afetam o suporte ao retorno de falha do cluster.
  • No primeiro, os pedidos são feitos pelo cliente para o cluster principal, que pára eventualmente de aceitar pedidos. Os pedidos são, então, roteados para o cluster de backup. O cliente inicialmente enviou pedidos ao cluster principal e, portanto, possui informações sobre o cluster principal. Como resultado, quando o cluster principal está disponível novamente, ocorre o retorno de falha dos pedidos para o cluster principal.
  • No segundo cenário, o cliente não inicia o envio de pedidos até depois do cluster principal estar inativo e os pedidos vão diretamente para o cluster de backup. Nesse caso, o cliente possui informações apenas sobre o cluster de backup. Como o cliente sabe apenas sobre o cluster de backup, quando o cluster principal torna-se disponível, os pedidos desse cliente continuam a rotear para o cluster de backup e não retornam a falha ao cluster principal ao tornarem-se disponíveis. Esse cenário ocorre quando um objeto é criado no cluster de backup. Nesse caso, o cluster de backup torna-se o cluster principal para esse objeto.
Esses dois cenários poderão ocorrer no mesmo cliente e ao mesmo tempo, se o cliente estiver enviando pedidos para objetos existentes e criando novos objetos após a parada de processamento do cluster principal.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_wlm_backupcluster
Nome do arquivo: crun_wlm_backupcluster.html