O servidor JMS pode ser configurado para funcionar em um Cluster de servidores gerenciados, com isto ganhamos vários benefícios:
- Balanceamento de carga para os servidores do Cluster
- O administrador pode configurar um balanceamento de carga através dos servidores de um Cluster através da configuração de alvos. Cada servidor será capaz de responder para um grupo de destinos;
- Esta configuração não é dinâmica, o administrador deverá escolher quais alvos irão balancear (o sistema não utiliza todos os servidores e vai balanceando de acordo com a necessidade);
- Alta disponibilidade dos destinos (High availability of destinations)
- Destinos distribuídos: oferecem capacidades de balanceamento de carga (load balance) e tolerância a falhas do que um destino normal. Além de manter as mensagens armazenadas, mesmo que o destino esteja indisponível, sem causar falhas e, assim que o destine se torne disponível, envia as mensagens;
- Armazenar e encaminhar (Store-And-Forward): é capaz de enviar mensagens para filas ou tópicos remotos. Caso o servidor remoto não esteja disponível, as mensagens não irão apresentar erros, mas ficarão armazenadas até que o servidor remoto volte a operar;
- Tolerância a falhas automática (Automatic failover): Os serviços podem ser migrados, de forma manual ou automática, no nível servidor, para outra máquina pertencente ao Cluster;
- Acesso transparente de qualquer servidor do Cluster (Cluster Wide)
o O acesso pode para os recursos no cluster é feito de forma transparente à complexidade do Cluster, bastando para isto configurar utilizar uma Connection Factory padrão para cada servidor ou configurando uma ou mais Connection Factories e associando elas através do alvo aos servidores do Cluster ou ao Cluster inteiro. Desta forma cada Connection Factory será implantada (Deployed) em múltiplas instâncias de servidores Weblogic;
- Escalabilidade
- Permite balanceamento de carga entre múltiplos servidores de um cluster, como já visto;
- Distribuição da carga da aplicação entre múltiplos servidores JMS através de Connection Factories, reduzindo a carga individual de cada servidor JMS;
- Opcionalmente o multicast pode ser utilizado, reduzindo drasticamente o número de mensagens necessárias para a entrega aos servidores JMS. Assim o servidor JMS só enviará uma mensagem para cada grupo definido no grupo multicast;
- Capacidade de migração
- Como visto, existe o suporte a migração, mas não é o servidor JMS quem migra, mas o servidor onde ele está configurado, ou seja, a instância inteira é migrada, levando com ela o servidor JMS;
- A migração pode ocorrer de forma manual ou automática;
- O serviço “exactly-once”, que permite que o servidor JMS tire vantagem do framework de migração do Weblogic em um ambiente em Cluster. Isto permite que o servidor JMS responda corretamente ao processo de migração, tornando o servidor JMS online e offline de forma ordenada;
- As migrações de servidores JMS podem ocorrer com agenda manual ou migrações automáticas em resposta de uma falha de uma instância de servidor;
- Afinidade nos servidores para Clientes JMS
- Existem três algoritmos de balanceamento de carga: round-robin-affinity, weight-based-affinity e random-affinity, que oferecem afinidade para os clientes que se conectam a ele. Uma vez que um cliente se conecta em um servidor JMS, ao efetuar novas conexões, ele sempre será encaminhado à mesma instância;
Podemos concluir que o Cluster do Weblogic possibilita várias configurações, desde uma versão simples até um nível bem sofisticado e complexo. O modo mais simples de garantir a disponibilidade é configurar dois servidores gerenciados (Servidor S1 e Servidor S2), ambos fazendo parte de um Cluster. Configuramos este Cluster para que migre os recursos de S1 para S2, caso S1 pare de responder.
Desta forma, basta criar um Servidor JMS com alvo apontado para o Servidor S1 Migrável (tem que ser o Servidor migrável, caso contrário não irá funcionar, na lista de servidores o Servidor S1 irá aparecer duas vezes, uma como “Servidor S1” e outra como “Servidor S1 (Migrável)”).
Todos os recursos criados nos módulos e as subimplantações (Subdeployments) devem ser criados e seus alvos configurados para o Cluster. Assim quando o Servidor S1 falhar, os serviços podem ser migrados para o Servidor S1 (manualmente, feito pelo Administrador ou, se os servidores forem configurados corretamente, de forma automática).