1) O documento discute clustering e alta disponibilidade no JBoss, incluindo definição de clusters, partições, canais de cache e interceptadores do lado do cliente. 2) É apresentada a arquitetura do JGroups e como ele fornece comunicação entre os nós do cluster. 3) Serviços como sessões HTTP, EJBs e mensageria podem ser clusterizados no JBoss.

1. JBoss Clustering Alta disponibilidade Open-Source para software de missão crítica

2. Sobre o palestrante Márcio Alves Marinho Profissional com mais de 15 anos de experiência no mercado de T.I, trabalhando diversas empresas públicas e privadas, em uma grande variedade de domínios de negócio, tais como engenharia civil, automação comercial, finanças, forças armadas, dentre outros. Seu perfil inclui gerenciamento de projetos e equipes, arquitetura de software, design, OOAD, SOA, EAI, Web Services, revisão de código, mentoring, coaching, Scrum, XP, Java, JavaEE, C++, .NET Framework, C#, ASP.NET, ASP.NET MVC, Ruby, Rails, Webphere AS, Websphere MQ, JBoss, Weblogic, dentre outos. Pós-graduado pelo NCE/UFRJ IBM SOA Certified Solution Designer Certified Scrum Master Sun Certified Enterprise Architect Sun Certified Business Components Developer Sun Certified Web Components Developer Sun Certified Java Programmer LinkedIn  http://www.linkedin.com/in/marciomarinho Twitter  http://twitter.com/marciomarinho Facebook  http://www.facebook.com/marcio.a.marinho Blog : www.marciomarinho.com Contato : [email_address] / 8115-9884

3. Agenda Introdução Definição de cluster Partições Canais de cache Serviços clusterizados Session Beans clusterizados Entity Beans clusterizados Serviços de http Cluster de mensageria Demo

4. Introdução

5. Introdução Alta disponibilidade é uma palavra simples para explicar um conceito bastante complexo : “ Como manter o(s) sistema(s) no ar quando mais precisamos dele !”

6. Introdução Alta-disponibilidade é o temo utilizado para sistemas disponíveis certo percentual ?% de tempo. Disponibilidade Downtime por ano Downtime por mês Downtime por semana 90% 36.5 Dias 72 Horas 16.8 Horas 95% 18.25 Dias 36 Horas 8.4 Horas 98% 7.30 Dias 14.4 Horas 3.36 Horas 99% 3.65 Dias 7.20 Horas 1.68 Horas 99,5% 1.83 Dias 3.60 Horas 50.4 Min 99,8% 17.52 Horas 86.23 Min 20.16 Min 99,9% 8.76 Horas 43.2 Min 10.1 Min 99,95% 4.38 Horas 21.56 Min 5.04 Min 99,99% 52.6 Min 4.32 Min 1.01 Min 99,999% 5.26 Min 25.9 s 6.05 s 99,9999% 31.5 s 2.59 s 0.605 s

7. Introdução Redundância – Recursos a mais disponíveis para momentos de necessidade. Gerenciabilidade – Soluções de cluster geralmente dão o benefício de gerenciamento centralizado como entidade única. Confiabilidade – Os serviços estarão sempre disponíveis. Escalabilidade – Se a carga aumentar, então podemos fazer com que o sistema responda a esta nova demanda com a mesma eficiência.

8. Definição de clusters JBoss Clustering

9. Definição de clusters Um cluster é um conjunto de nós que comunicam-se entre si e trabalham juntos por um objetivo comum. Dentro do vocabulário do JBoss, um cluster de servidores é também conhecido como “partição”, e um nó é uma instância de um application server.

10. Definição de clusters

11. Definição de clusters A comunicação entre os nós é de responsabilidade da biblioteca Jgroups , com o Jgroups channel provendo a funcionalidade básica de saber quem está no cluster, e realizar trocas de mensagens confiáveis com os membros do cluster. Os canais Jgroups que possuem a mesma configuração e nome tem a habilidade de descobrir outros participantes dentro de um grupo.

12. Definição de clusters Em uma mesma rede, e mesmo para o mesmo serviço, podemos ter clusters diferentes.

13. Multicast O Jboss usa multicast para descobrir outros nós automáticamente, e para realizar a comunicação no cluster.

14. Serviços de clustering

15. Arquitetura do JGroups Na arquitetura do JGroups existem dois componentes principais o channel e stack . O channel possibilita que as aplicações conectem-se umas as outras e enviem mensagens para outros membros do cluster. O stack é um conjunto de camadas que formam um protocolo. No JGroups um protocolo não precisa corresponder exatamente a um protocolo de transporte.

16. Partições

17. Partições Partições ( HAPartition ) é um serviço usado por uma variedade de tarefas no Jboss clustering. No fundo, o mesmo se resume a uma abstração criada sobre o Jgroups channel que provê suporte ao envio e recebimento de invocações RPC ( Remote Procedure Calls ) de ou para um membro do cluster. Este serviço possui o suporte para registro distribuído de qual serviço clusterizado está rodando em um membro do cluster. Também provê notificações para listeners que estiverem interessados quando um membro do cluster muda de estado ou quando o registro de serviço clusterizado muda.

18. Partições HAPartition é o coração de vários serviços de clustering, incluindo o smart client-side clustered proxy, Entity cache management, farming, HA-JNDI e HA singletons.

19. Partições ( configuração ) <mbean code=&quot;org.jboss.ha.framework.server.ClusterPartition&quot; name=&quot;jboss:service=DefaultPartition&quot;> <! -- Name of the partition being built --> <attribute name=&quot; PartitionName &quot;> ${jboss.partition.name:DefaultPartition} </attribute> <! -- The address used to determine the node name --> <attribute name=&quot;NodeAddress&quot;>${jboss.bind.address}</attribute> <! -- Determine if deadlock detection is enabled --> <attribute name=&quot;DeadlockDetection&quot;>False</attribute> <! -- Max time (in ms) to wait for state transfer to complete. Increase for large states --> <attribute name=&quot;StateTransferTimeout&quot;>30000</attribute> <! -- The JGroups protocol configuration --> <attribute name=&quot;PartitionConfig&quot;> ... ... </attribute> </mbean>

20. Partições ( atributos ) PartitionName – (opcional) para especificarmos o nome do cluster, ex : “P1”. Onde o valor default é DefaultPartition. Para executar o JBoss com um nome diferente de partição é só usar o parâmetro -g . NodeAddress – (opcional) usado para gerar um nome único para o nó. DeadlockDetection – (opcional) que configura o JGroups para executar o algorítimo de detecção de deadlock para cada request. O valor default é false.

21. Partições ( atributos ) StateTransferTimeout – (Opcional) especifica o timeout para replicação de estado entre o cluster em milisegundos. O valor default value é 30000. PartitionConfig – Elemento para especificar as configurações do JGroup para o cluster corrente.

22. Canais de cache

23. Canais de cache O JBoss Cache é um framework de cache distribuído que pode ser utilizado dentro de qualquer servidor de aplicações ou em modo standalone. O JBoss AS integra o JBoss Cache para prover serviços de cache para sessões http, EJB 3 (session e entity). Cada um destes serviços de cache é definido em um Mbean separado, onde cada um cria o seu próprio canal.

24. Canais de cache

25. Interceptadores do lado do cliente

26. Interceptadores do lado do cliente A maioria dos serviços providos pelo JBoss ( JNDI, EJB, JMS, RMI, JBoss Remoting ) necessitam que o cliente obtenha um objeto stub ( proxy ). Este objeto (stub) é gerado no servidor e implementa a interface de negócio do serviço, então o cliente é capaz de invocar localmente os métodos deste objeto. A stub faz o roteamento automático das invocações através da rede e invoca os serviços gerenciados no servidor.

27. Interceptadores do lado do cliente

28. Interceptadores do lado do cliente Em um ambiente de cluster, as stubs geradas no servidor incluem um interceptador que sabe como rotear as várias chamadas no cluster. O objeto stub descobre como achar o nó apropriado, empacotar e desempacotar os parâmetros, e retornar o resultado para o cliente.

29. Interceptadores do lado do cliente O interceptor stub mantém as informações sobre o cluster atualizada. Ela possui o conhecimento do endereço IP de todos os nós do cluster, o algoritmo para distribuir a carga entre os servidores, e como executar um failover no caso de um nó não estiver disponível. A mesma trata das as requisições, e se o cluster mudar ( adicionar ou remover nó ), então ela será atualizada com as últimas alterações do cluster. Todo este trabalho é transparente para o cliente.

30. Interceptadores do lado do cliente

31. Interceptadores do lado do cliente Round-Robin – Cada invocação é despachada para um nó diferente, e as invocações seguintes seguem sequencialmente a lista de nós. O primeiro nó é escolhido aleatóriamente da lista. Random-Robin – Para cada invocação um nó é escolhido aleatóriamente. First Available – Um nó disponível é eleito como o servidor a ser invocado e será usado para todas as chamadas subsequentes. Quando a lista de nós muda um novo nó é escolhido, a menos que o nó corrente ainda esteja disponível. Cada stub de cliente elege o seu próprio servidor independente das outras stubs, ou seja, caso um cliente faça download de duas stubs para um mesmo serviço ( EJB ), cada stub irá pegar o seu servidor independentemente. First Available Identical All Proxies – Possui o mesmo comportamento de “First Available” mas o servidor é eleito é compartilhado por todas stubs dentro da mesma VM do cliente.

32. Load Balancer

33. Load Balancer Alguns outros serviços do JBoss, e em particular serviços baseados em HTTP não necessitam que o cliente faça download algum. O cliente apenas acessará um web-browser, enviará a requisição e receberá a resposta diretamente. Neste caso, um load balancer externo se faz necessário, afim de processar todas as requisições e despachá-las para os nós do cluster.

34. Load Balancer O cliente precisa somente saber como contactar o load balancer, e o mesmo não possui algum conhecimento das instâncias do JBoss por trás do load balancer. O load balancer também faz parte do cluster, mas nós o chamamos de recurso “externo” por que ele não roda no mesmo processo como um cliente ou como as outras instâncias do JBoss.

35. Load Balancer Um load balancer pode ser implementado por software ou hardware. Podemos utilizar como exemplo de software de load balancer o mod_jk do Apache. NGINX Um load balancer externo implementa o seu próprio mecanismo para entender a configuração do cluster e provêr sua forma de balanceamento de carga e failover.

36. Load Balancer

37. Políticas de balanceamento de carga Ambos stub do cliente e servidor de balanceamento de carga possuem políticas de balanceamento de carga.

38. Política externa de balanceamento de carga Um load balancer externo provê sua própria forma de balanceamento, e é possível plugarmos um novo load balancer no JBoss. O único requisito para tal é que o load balancer suporte afinidade de servidor.

39. Deployment

40. Farming Deployment Sem dúvidas é a forma mais simples e fácil de fazer a instalação ( deployment ) de uma aplicação em um cluster. Isto significa fazer o hot-deploy de uma aplicação empacotada ( EAR, WAR, ou SAR), somente colocando o arquivo no diretório all/farm de qualquer membro do cluster, após isso a aplicação será copiada para todos os nós do mesmo cluster. Se um mais um nó for adicionado mais tarde, então o mesmo receberá o novo pacote da aplicação no momento do startup. Se uma aplicação for removida de um diretório farm/ de um determinado nó, a aplicação então será desinstalada dos outros nós ( a remoção deverá ser feita manualmente caso o nó não estiver conectado no cluster ).

41. Serviços clusterizados

42. Serviços clusterizados A JNDI é o serviço mais importante provido pelo servidor de aplicações. O JBoss HÁ-JNDI ( High Availability JNDI ). Provê failover transparente para operações com nomes. Caso uma HA-JNDI naming context estiver conectada a um serviço em uma instância do JBoss, e o serviço falhar ou cair, então a HA-JNDI do cliente pode proceder com o failover automático para outro servidor. Load balance de operações com nomes. Uma HA-JNDI naming context irá balancear os requests entre todas as HÁ-JNDI para os servidores dentro do cluster.

43. Serviços clusterizados Discovery automático de servidores HA-JNDI usando multicast. Visão unificada da árvore JNDI do cluster. Onde um cliente pode executar um lookup e a HA-JNDI do servidor possui a habilidade de achar coisas que estão na JNDI de qualquer outro nó do cluster. Árvore replicada entre os servidores. Um objeto dentro de uma HA-JNDI será replicado por todo cluster, e uma cópia do objeto estará disponível dentro da VM de cada nó no cluster.

44. Session Beans clusterizados

45. Session Beans clusterizados Configuração exageradamente simples para Stateless session , pois não existe estado envolvido, e as invocações podem ser fácilmente balanceadas para qualquer nó ( desde que o bean esteja instalado lá).

46. Session Beans clusterizados ( jboss.xml ) @Stateless @Clustered public class MyBean implements MySessionInt { public void test() { } } <jboss> <enterprise-beans> <session> <ejb-name>NonAnnotationStateful</ejb-name> <clustered>true</clustered> <cluster-config> <partition-name>FooPartition</partition-name> <load-balance-policy> org.jboss.ha.framework.interfaces.RandomRobin </load-balance-policy> </cluster-config> </session> </enterprise-beans> </jboss>

47. Session Beans clusterizados A clusterização de Stateful Session é mais complexa, pois o JBoss precisa manter o estado do mesmo. O estado de todos estes beans são replicados e sincronizados no cluster a cada vez que o estado do mesmo muda. O JBoss usa o MBean HASessionState para gerenciar a distribuição de estado no cluster.

48. Session Beans clusterizados ( jboss.xml ) @Stateful @Clustered @CacheConfig(maxSize=5000,removalTimeoutSeconds=18000) public class MyBean implements MySessionInt { private int state = 0; public void increment() { System.out.println(&quot;counter: &quot; + (state++)); } }

49. Entity Beans clusterizados (2.X) Não faça isso !  Exposição de objeto remoto de granularidade fina. Sincronização de dados entre servidores.

50. Entity Beans clusterizados (3.0) Usa cache distribuido ( 2nd level cache  TreeCache ) Se uma entidade for persistida via EntityManager com o cache ligado, então a mesma será inserida no cache. Se uma entidade for atualizada via EntityManager com o cache ligado, então a mesma será atualizada no cache. Se uma entidade for removida via EntityManager com o cache ligado, então ela também será removida do cache.

51. Serviços de HTTP

52. Serviços de HTTP A replicação do HTTP session é usada para replicar o estado assiciado com os clientes web nos outros nós do cluster. Caso o servidor caia, outro servidor no cluster será responsável pela recuperação. Onde duas ações deve ser realizadas Replicação de sessão Balanceamento de carga de invocações

53. Serviços de HTTP Toda replicação de estado é feita pelo próprio JBoss. Quando é utilizada a configuração all a replicação do estado é automática. A única coisa que precisa ser feita é configurar a aplicação web com o atributo <distributable> no web.xml

54. Serviços de HTTP O load-balancing acontece de forma diferente, pois o mesmo não é tratado pelo JBoss, mas por algum dispositivo externo. O mesmo pode ser realizado por algum hardware, ou por software, como é o caso do mod_jk para o apache.

55. Cluster de mensageria

56. Cluster de mensageria Mensageria em clusters com a configuração all devem funcionar sem problemas, com pequenos ajustes. Unique server peer id Cada nó deve possuir um número único Clustered destinations Os tópicos e filas são clusterizados transparentemente no cluster. Uma mensagem enviada para uma fila ou tópico distribuído em um determinado nó pode ser consumida por outros nós. Para dizer que um destino é clusterizado simplesmente configure o deployment descriptor para true.

57. Cluster de mensageria Clustered durable subscribers As assinaturas duráveis também podem ser clusterizadas. Isto significa que vários assinantes podem consumir a mesma assinatura durável de diferentes nós no cluster. A assinatura será clusterizada se o tópico também for. Clustered temporary destinations O JBoss Messaging suporta clustering de tópicos e filas temporários. Servidores não clusterizados Se não desejarmos que os nós participem de um cluster, ou se só temos um nó não clusterizado, então podemos configurar o atributo clustered para false no postoffice. Clustered connection factories Se o atributo supportsLoadBalancing do objeto connection factory estiver configurado para true, então as tentativas de criação da conexão irão ser divididas entre os servidores disponíveis (round robin). O primeiro nó a será tentado de forma randômica.

58. Cluster de mensageria

59. DEMO Setup do ambiente Exibição do exemplo

60. Setup do ambiente A configuração all, usando o comando –c, já possui a feature de clustering ativada (e a mesma é automática para máquinas na mesma rede). ./run.sh –c all –b 192.168.1.140 –Djboss.messaging.ServerPeerID=1 Se você só tem uma máquina, então faça o seguinte : Linux : bind one cluster node para localhost, e outro com o hostname da sua máquina

61. Linux Faça o bind de um nó do cluster para localhost, e outro com o hostname da sua máquina : ./run.sh –c node1 –b localhost –Djboss.messaging.ServerPeerID=1 ./run.sh –c node1 –b marcio-desktop –Djboss.messaging.ServerPeerID=1

62. Windows Criar dois IP’s “fake” com Microsoft Loopback adapter. Vá em adicionar hardware no painel de controle. Selecione sim, eu tenho o hardware conectado. Vá para o fim da lista de hardwares instalados e selecione “adicionar novo dispositivo de hardware” Selecione a opção de instalação manual. Selecione dispositivos de rede. Selecione Microsoft como fabricante e Microsoft Loopback Adapter como dispositivo de rede. Depois de adicionar o dispositivo, vá em conexões de rede no painel de controle renomeie o seu dispositivo recém adicionado para algum nome mais semântico (se quiser). Clique em dispositivo loopback, vá em properties e então para TCP/IP. Especifique um endereço de IP não roteável (192.168.1.140), com uma máscara de sub-rede (255.255.255.0) Clique em avançado e adicione outro IP (192.168.1.141)

63. Bibliografia JBossAS Clustering Guide http://community.jboss.org/wiki/jBossAS5ClusteringGuide Jboss in Action http://www.amazon.com/JBoss-Action-Configuring-Application-Server/dp/1933988029/ref=sr_1_1?ie=UTF8&s=books&qid=1267201317&sr=8-1 Apache MOD_JK http://tomcat.apache.org/connectors-doc/ NGINX http://wiki.nginx.org/Main

64. FIM P & R ?