Ao Utilizar um Gerenciador de Alta Disponibilidade
Um gerenciador de alta disponibilidade consome recursos de sistema valiosos, como ciclos de CPU, memória heap e sockets. Esses recursos são consumidos pelo gerenciador de alta disponibilidade e pelos componentes de produtos que utilizam os serviços fornecidos pelo gerenciador de alta disponibilidade. A quantidade de recursos que o gerenciador de alta disponibilidade e os componentes desse produto consomem aumenta de maneira não linear à medida que o tamanho de um grupo principal aumenta.
Para grandes grupos principais, a quantidade de recursos que o gerenciador de alta disponibilidade consome pode tornar-se significativa. Desativar o gerenciador de alta disponibilidade libera esses recursos. No entanto, antes de desativar o gerenciador de alta disponibilidade, é necessário uma investigação completa sobre as necessidades atuais e futuras do sistema para garantir que a desativação desse gerenciador também não desative outras funções utilizadas que o requeiram. Por exemplo, tanto a replicação de sessão de memória para memória, como o RRD (Remote Request Dispatcher) requerem a ativação do gerenciador de alta disponibilidade.
O recurso para desativar o gerenciador de alta disponibilidade é mais útil para topologias em que nenhum dos serviços fornecidos pelo gerenciador de alta disponibilidade é utilizado. Em determinadas topologias, somente alguns processos utilizam os serviços que o gerenciador de alta disponibilidade fornece. Nessas topologias, é possível desativar o gerenciador de alta disponibilidade em uma base por processo, que otimiza a quantidade de recursos que o gerenciador de alta disponibilidade utiliza.
Não desative o gerenciador de alta disponibilidade nos processos administrativos, como agentes de nó e gerenciador de implementação, a menos que o gerenciador de alta disponibilidade seja desativado em todos os processos do servidor de aplicativos no grupo principal.
Alguns dos serviços que o gerenciador de alta disponibilidade fornece são baseados em cluster. Portanto, como os membros do cluster devem ser homogêneos, se você desativar o gerenciador de alta disponibilidade em um membro de um cluster, você deve desativá-lo em todos os outros membros desse cluster.
- Réplica de memória para memória
- Failover de Singleton
- Roteamento do gerenciamento de carga de trabalho


Réplica de memória para memória
Replicação de memória para memória é um serviço baseado em cluster que você configura ou ativa no nível do servidor de aplicativos. Se a replicação de memória para memória for ativada em qualquer membro do cluster, o gerenciador de alta disponibilidade deverá ser ativado em todos os membros do cluster. A replicação de memória para memória é ativada automaticamente se:
- A replicação memória-a-memória está ativada para sessões de HTTP de contêiner da Web.
- A replicação de cache for ativada para o serviço de cache dinâmico.
- O failover do bean de sessão com preservação de estado do EJB for ativado para um servidor de aplicativos.
Failover de Singleton
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- O cluster é configurado para utilizar o gerenciador de alta disponibilidade para gerenciar a recuperação de logs de transação.
- Uma ou mais instâncias do provedor de sistemas de mensagens padrão estiverem configuradas para execução no cluster. O provedor de sistemas de mensagens padrão que é fornecido com o produto é também conhecido como barramento de integração de serviços.
Failover de singleton é um serviço baseado em cluster.
O gerenciador de alta disponibilidade deverá ser ativado em todos os membros de um cluster se uma ou mais instâncias
do provedor de sistemas de mensagens padrão estiver configurada para ser executada no cluster. O provedor do sistema de mensagens padrão é o mecanismo do sistema de mensagens que é fornecido com o produto.
Gerenciamento da carga de trabalho
Informações de roteamento para tráfego IIOP do enterprise bean.
- Informações de roteamento para o mecanismo do sistema de mensagens padrão, que também é referido como barramento de integração de serviços.
- Solicitações de HTTP de roteamento por meio do servidor proxy IBM® WebSphere Application Server.
- Roteamento de solicitações de Endereçamento de Serviços da Web por meio do servidor proxy IBM WebSphere Application Server.
- Roteamento de pedidos de SIP (Session Initiation Protocol).
O WLM utiliza o gerenciador de alta disponibilidade para propagar as informações de roteamento e torná-las disponíveis. Embora as informações de roteamento do WLM normalmente sejam aplicadas a recursos de cluster, elas também podem ser aplicadas a recursos sem cluster, como mecanismos de sistemas de mensagens independentes. Geralmente, você deve deixar o gerenciador de alta disponibilidade ativado em qualquer servidor de aplicativos que produza ou consuma informações de roteamento de IIOP ou do mecanismo do sistema de mensagens.
- O produtor de informações de roteamento for um aplicativo de bean corporativo que resida no cluster 1.
- O consumidor das informações de roteamento for um servlet que resida no cluster 2.
Quando o servlet no cluster 2 chamar o aplicativo de enterprise bean no cluster 1, o gerenciador de alta disponibilidade deverá ser ativado em todos os servidores em ambos os clusters.
O MBeans ClusterMgr e o Cluster de gerenciamento de carga de trabalho podem retornar informações básicas sobre um cluster. No entanto, se o gerenciador de alta disponibilidade for desativado em qualquer parte da topologia, não será possível modificar as configurações atuais e propagar as modificações a outros membros do cluster.
O gerenciamento de carga de trabalho fornece uma opção para construir e exportar estaticamente tabelas de rotas para o sistema de arquivos. Utilize essa opção para eliminar a dependência do gerenciador de alta disponibilidade.

Por exemplo, como não há nenhuma replicação de dados entre os membros de um cluster de proxy, o failover entre servidores proxy no cluster não é suportado. Se um servidor proxy estiver inativo, todas as conexões ativas que são propriedade do servidor proxy serão perdidas e os pedidos recebidos falharão. No entanto, como os servidores proxy e os clusters de proxy suportam a alta disponibilidade e o failover de servidores backend, o servidor proxy pode detectar se um servidor backend está desativado e, em seguida, encaminhar as solicitações para um servidor que possuir a sessão replicada.
gotchaSaída do exemplo:
myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)