Serviços Essenciais do Cluster JBoss AS

O cluster JBoss AS envolve um conjunto exclusivo de MBeans, além de modifi- cações sobre as configurações de vários dos MBeans que já existiam nas confi- gurações não-clusterizadas.

Vamos então ser apresentados aos principais MBeans que foram os serviços clusterizados do JBoss AS:

O arquivo cluster-service.xml define os serviços essenciais do cluster JBoss AS, que compartilham um mesmo canal JGroups, e formavam a totalidade do cluster em versões mais antigas do servidor de aplicações

● DefaultPartition (jboss:service=DefaultPartition) – encapsula um

canal JGroups e permite que membros de um mesmo cluster se encon- trem e passem a trocar mensagens de sincronização. A maioria dos ser- viços do JBoss AS irá compartilhar este mesmo canal de comunicação multiponto;

● HASessionState (jboss:service=HASessionState) – replica o estado

de SFSBs EJB 2 entre os membros de um cluster, utilizando para isso o canal JGroups definido em DefaultPartition. Note que este MBean, ao contrário de outros serviços clusterizados, não utiliza o JBossCache;

● HAJNDI (jboss:service=HAJNDI) – é o serviço de diretório do cluster. Em

vez de replicar os objetos publicados entre todos os membros, ele ape- nas repassa as buscas para os demais membros do cluster, de modo que mesmo componentes não-clusterizados sejam localizados.

9.1.1.

Invocadores cluserizados

O arquivo cluster-service.xml também define versões clusterizadas para os invocadores RMI (JRMPInvokerHA) e JBoss Remoting (UnifiedInvokerHA). Ele são referenciados por configurações de container e de invocador clusterizadas definidos em standardjboss.xml.

Os invocadores clusterizados, por sua vez, consultam o DefaultPartition para manter os proxies dos clientes atualizados em relação à topologia do cluster e permitir que os clientes remotos realizem fail-over sem necessidade de ajuda externa.

9.1.2.

Clientes (Java) do Cluster

O cliente de um cluster JBoss AS difere do cliente de uma instância de JBoss AS stand-alone apenas por se conectar ao HAJNDI em vez de ao JNDI local da instância.

O arquivo de configuração do acesso ao diretório, jndi.properties, passa a relacionar várias URLs de conexão, que devem indicar o IP de vários membros do cluster e para cada um a porta do serviço HAJNDI (por padrão 1100) em vez da porta do JNDI stand-alone (por padrão 1099).

9.1. Serviços Essenciais do Cluster JBoss AS

Caso o cliente se conecte ao JNDI stand-alone, ele receberá proxies não-clus- terizados, que permitirão o acesso apenas ao membro que gerou o próprio proxy. Mas, caso ele se conecte ao JNDI cluserizado, receberá um proxy capaz de realizar balanceamento de carga e fail-over entre os membros ativos do cluster.

A relação de membros não precisa ser completa. No primeiro acesso, o clien- te recebe uma relação completa dos membros, que é atualizada pelo Default- Partition sempre que houver alguma mudança. Então o cliente sempre “sabe” quais são suas opções.

Depois de receber a relação completa de membros, ou seja, a topologia do cluster, o proxy decide qual membro ele irá utilizar para realizar as chamadas remotas. Os proxies não necessitam se comunicar entre si nem com o cluster para tomar esta decisão.

E, em caso de erro de rede, o próprio proxy seleciona um novo membro dentre os disponíveis para uma nova tentativa ou fail-over.

Entretanto, em caso de parada de todos os membros do cluster, ou algo que se pareça com isto (por exemplo uma queda de link ou roteador) o proxy acaba fi- cando com uma lista vazia de membros e não consegue se recuperar disto. O jeito é reiniciar o cliente para que ele possa fazer um novo “primeiro contato” e reinicializar sua relação de membros.

De acordo com o serviço acessado pelo proxy, ele pode respeitar “afinidade de sessão”, utilizando o mesmo membro do cluster para todas as chamadas remo- tas, ou alterar entre os membros disponíveis. O primeiro seria o caso de um proxy para um SFSB, enquanto que o segundo seria o proxy para um SLSB.

9.1.3.

Singleton de cluster

O MBean HASingletonDeployer (jboss.ha:service=HASingletonDeployer) definido em deploy-hasingleton-service.xml, que também utiliza o canal JGroups do DefaultPartition, tem dois propósitos:

3. Possibilitar a criação de serviços ativo-passivo, que são bem mais sim- ples de se implementar do que serviços ativo-ativo;

4. Evitar que ocorra processamento duplicado em vários membros de um cluster, quando isto for indesejado. A idéia é que certos serviços possu- am semântica equivalente ao design pattern Singleton, só que para o cluster como um todo, em vez de para uma única JVM.

Serviços Singleton não tem nada de especial: eles apenas são deployados em uma pasta em separado, chamada deploy-hasingleton.

O HASingletonDeployer irá realizar o deployment dos serviços e componen- tes de aplicação em sua pasta apenas no membro controlador do cluster. Caso o membrocontrolador mude, assim que um novo controlador for eleito (o que costuma ocorrer em poucos segundos), os serviços são iniciados no novo con- trolador.

Isto garante que haja sempre um membro do cluster rodando os serviços Sin- gleton, mas apenas um.

9.1.4.

Caches Clusterizados para EJB, Hibernate e Web

O suporte a EJB 3 utiliza duas instâncias do JBossCache, cada uma com seu próprio canal JGroups. A primeira é definida em ejb3-clustered-sfsbcache- service.xml e serve para replicar instâncias de SFSBs.

A segunda está em ejb3-entity-cache-service.xml e é nada mais do que um cache de segundo nível do Hibernate, como foi visto no Capítulo 5. Caso sejam definidos caches adicionais para o Hibernate, poderão ser definidos também canais JGroups adicionais.

Por fim, o pacote SAR jboss-web-cluster.sar define uma instância do JBoss- Cache, e seu respectivo canal JGroups, exclusivo para a replicação de sessões HTTP.

Então um único cluster de servidores JBoss AS forma quatro clusters lógicos, ou seja, quatro canais JGroups, sendo que três destes são comandados por suas próprias instâncias clusterizadas de JbossCache.

Apenas os caches de EJB 2 (para SFSB e Entity Beans) não usam JBoss Cache nem possuem seus próprios canais JGroups. Eles compartilham o canal do De- faultPartition.

Todos os serviços Java EE do JBoss AS, exceto o JBoss MQ, rodam em modo ativo-ativo, oferecendo escalabilidade e também tolerância à falhas.

Caso seja necessário modificar ou tunar configurações de rede do JGroups, po- derá ser necessário modificar os quatro clusters, isto é, as quatro configura- ções de canais JGroups.