JBoss Clustering

6,883 views

Published on

Estes são os slides de minha apresentação no RioJUG em 25/02/2009 sobre JBoss Clustering.

Published in: Technology

JBoss Clustering

  1. 1. JBoss Clustering Alta disponibilidade Open-Source para software de missão crítica
  2. 2. Sobre o palestrante <ul><li>Márcio Alves Marinho </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><ul><li>Pós-graduado pelo NCE/UFRJ </li></ul></ul></ul><ul><ul><ul><li>IBM SOA Certified Solution Designer </li></ul></ul></ul><ul><ul><ul><li>Certified Scrum Master </li></ul></ul></ul><ul><ul><ul><li>Sun Certified Enterprise Architect </li></ul></ul></ul><ul><ul><ul><li>Sun Certified Business Components Developer </li></ul></ul></ul><ul><ul><ul><li>Sun Certified Web Components Developer </li></ul></ul></ul><ul><ul><ul><li>Sun Certified Java Programmer </li></ul></ul></ul><ul><ul><li>LinkedIn  http://www.linkedin.com/in/marciomarinho </li></ul></ul><ul><ul><li>Twitter  http://twitter.com/marciomarinho </li></ul></ul><ul><ul><li>Facebook  http://www.facebook.com/marcio.a.marinho </li></ul></ul><ul><ul><li>Blog : www.marciomarinho.com </li></ul></ul><ul><ul><li>Contato : [email_address] / 8115-9884 </li></ul></ul>
  3. 3. Agenda <ul><li>Introdução </li></ul><ul><li>Definição de cluster </li></ul><ul><li>Partições </li></ul><ul><li>Canais de cache </li></ul><ul><li>Serviços clusterizados </li></ul><ul><li>Session Beans clusterizados </li></ul><ul><li>Entity Beans clusterizados </li></ul><ul><li>Serviços de http </li></ul><ul><li>Cluster de mensageria </li></ul><ul><li>Demo </li></ul>
  4. 4. Introdução
  5. 5. Introdução <ul><li>Alta disponibilidade é uma palavra </li></ul><ul><li>simples para explicar um conceito </li></ul><ul><li>bastante complexo : </li></ul><ul><li>“ Como manter o(s) sistema(s) no ar quando mais precisamos dele !” </li></ul>
  6. 6. Introdução <ul><li>Alta-disponibilidade é o temo utilizado para sistemas disponíveis certo percentual ?% de tempo. </li></ul>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. 7. Introdução <ul><li>Redundância – Recursos a mais disponíveis para momentos de necessidade. </li></ul><ul><li>Gerenciabilidade – Soluções de cluster geralmente dão o benefício de gerenciamento centralizado como entidade única. </li></ul><ul><li>Confiabilidade – Os serviços estarão sempre disponíveis. </li></ul><ul><li>Escalabilidade – Se a carga aumentar, então podemos fazer com que o sistema responda a esta nova demanda com a mesma eficiência. </li></ul>
  8. 8. Definição de clusters JBoss Clustering
  9. 9. Definição de clusters <ul><li>Um cluster é um conjunto de nós que comunicam-se entre si e trabalham juntos por um objetivo comum. </li></ul><ul><li>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. </li></ul>
  10. 10. Definição de clusters
  11. 11. Definição de clusters <ul><li>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. </li></ul><ul><li>Os canais Jgroups que possuem a mesma configuração e nome tem a habilidade de descobrir outros participantes dentro de um grupo. </li></ul>
  12. 12. Definição de clusters <ul><li>Em uma mesma rede, e mesmo para o mesmo serviço, podemos ter clusters diferentes. </li></ul>
  13. 13. Multicast <ul><li>O Jboss usa multicast para descobrir outros nós automáticamente, e para realizar a comunicação no cluster. </li></ul>
  14. 14. Serviços de clustering
  15. 15. Arquitetura do JGroups <ul><li>Na arquitetura do JGroups existem dois componentes principais o channel e stack . </li></ul><ul><li>O channel possibilita que as aplicações conectem-se umas as outras e enviem mensagens para outros membros do cluster. </li></ul><ul><li>O stack é um conjunto de camadas que formam um protocolo. No JGroups um protocolo não precisa corresponder exatamente a um protocolo de transporte. </li></ul>
  16. 16. Partições
  17. 17. Partições <ul><li>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. </li></ul><ul><li>Este serviço possui o suporte para registro distribuído de qual serviço clusterizado está rodando em um membro do cluster. </li></ul><ul><li>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. </li></ul>
  18. 18. Partições <ul><li>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. </li></ul>
  19. 19. Partições ( configuração ) <ul><li><mbean code=&quot;org.jboss.ha.framework.server.ClusterPartition&quot; </li></ul><ul><li>name=&quot;jboss:service=DefaultPartition&quot;> </li></ul><ul><li><! -- Name of the partition being built --> </li></ul><ul><li><attribute name=&quot; PartitionName &quot;> </li></ul><ul><li>${jboss.partition.name:DefaultPartition} </li></ul><ul><li></attribute> </li></ul><ul><li><! -- The address used to determine the node name --> </li></ul><ul><li><attribute name=&quot;NodeAddress&quot;>${jboss.bind.address}</attribute> </li></ul><ul><li><! -- Determine if deadlock detection is enabled --> </li></ul><ul><li><attribute name=&quot;DeadlockDetection&quot;>False</attribute> </li></ul><ul><li><! -- Max time (in ms) to wait for state transfer to complete. </li></ul><ul><li>Increase for large states --> </li></ul><ul><li><attribute name=&quot;StateTransferTimeout&quot;>30000</attribute> </li></ul><ul><li><! -- The JGroups protocol configuration --> </li></ul><ul><li><attribute name=&quot;PartitionConfig&quot;> </li></ul><ul><li>... ... </li></ul><ul><li></attribute> </li></ul><ul><li></mbean> </li></ul>
  20. 20. Partições ( atributos ) <ul><li>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 . </li></ul><ul><li>NodeAddress – (opcional) usado para gerar um nome único para o nó. </li></ul><ul><li>DeadlockDetection – (opcional) que configura o JGroups para executar o algorítimo de detecção de deadlock para cada request. O valor default é false. </li></ul>
  21. 21. Partições ( atributos ) <ul><li>StateTransferTimeout – (Opcional) especifica o timeout para replicação de estado entre o cluster em milisegundos. O valor default value é 30000. </li></ul><ul><li>PartitionConfig – Elemento para especificar as configurações do JGroup para o cluster corrente. </li></ul>
  22. 22. Canais de cache
  23. 23. Canais de cache <ul><li>O JBoss Cache é um framework de cache distribuído que pode ser utilizado dentro de qualquer servidor de aplicações ou em modo standalone. </li></ul><ul><li>O JBoss AS integra o JBoss Cache para prover serviços de cache para sessões http, EJB 3 (session e entity). </li></ul><ul><li>Cada um destes serviços de cache é definido em um Mbean separado, onde cada um cria o seu próprio canal. </li></ul>
  24. 24. Canais de cache
  25. 25. Interceptadores do lado do cliente
  26. 26. Interceptadores do lado do cliente <ul><li>A maioria dos serviços providos pelo JBoss ( JNDI, EJB, JMS, RMI, JBoss Remoting ) necessitam que o cliente obtenha um objeto stub ( proxy ). </li></ul><ul><li>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. </li></ul><ul><li>A stub faz o roteamento automático das invocações através da rede e invoca os serviços gerenciados no servidor. </li></ul>
  27. 27. Interceptadores do lado do cliente
  28. 28. Interceptadores do lado do cliente <ul><li>Em um ambiente de cluster, as stubs geradas no servidor incluem um interceptador que sabe como rotear as várias chamadas no cluster. </li></ul><ul><li>O objeto stub descobre como achar o nó apropriado, empacotar e desempacotar os parâmetros, e retornar o resultado para o cliente. </li></ul>
  29. 29. Interceptadores do lado do cliente <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Todo este trabalho é transparente para o cliente. </li></ul>
  30. 30. Interceptadores do lado do cliente
  31. 31. Interceptadores do lado do cliente <ul><li>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. </li></ul><ul><li>Random-Robin – Para cada invocação um nó é escolhido aleatóriamente. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  32. 32. Load Balancer
  33. 33. Load Balancer <ul><li>Alguns outros serviços do JBoss, e em particular serviços baseados em HTTP não necessitam que o cliente faça download algum. </li></ul><ul><li>O cliente apenas acessará um web-browser, enviará a requisição e receberá a resposta diretamente. </li></ul><ul><li>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. </li></ul>
  34. 34. Load Balancer <ul><li>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. </li></ul><ul><li>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. </li></ul>
  35. 35. Load Balancer <ul><li>Um load balancer pode ser implementado por software ou hardware. </li></ul><ul><li>Podemos utilizar como exemplo de software de load balancer o mod_jk do Apache. </li></ul><ul><li>NGINX </li></ul><ul><li>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. </li></ul>
  36. 36. Load Balancer
  37. 37. Políticas de balanceamento de carga <ul><li>Ambos stub do cliente e servidor de balanceamento de carga possuem políticas de balanceamento de carga. </li></ul>
  38. 38. Política externa de balanceamento de carga <ul><li>Um load balancer externo provê sua própria forma de balanceamento, e é possível plugarmos um novo load balancer no JBoss. </li></ul><ul><li>O único requisito para tal é que o load balancer suporte afinidade de servidor. </li></ul>
  39. 39. Deployment
  40. 40. Farming Deployment <ul><li>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. </li></ul><ul><li>Se um mais um nó for adicionado mais tarde, então o mesmo receberá o novo pacote da aplicação no momento do startup. </li></ul><ul><li>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 ). </li></ul>
  41. 41. Serviços clusterizados
  42. 42. Serviços clusterizados <ul><li>A JNDI é o serviço mais importante provido pelo servidor de aplicações. O JBoss HÁ-JNDI ( High Availability JNDI ). </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  43. 43. Serviços clusterizados <ul><li>Discovery automático de servidores HA-JNDI usando multicast. </li></ul><ul><li>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. </li></ul><ul><li>Á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. </li></ul>
  44. 44. Session Beans clusterizados
  45. 45. Session Beans clusterizados <ul><li>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á). </li></ul>
  46. 46. Session Beans clusterizados ( jboss.xml ) <ul><li>@Stateless </li></ul><ul><li>@Clustered </li></ul><ul><li>public class MyBean implements MySessionInt { </li></ul><ul><li>public void test() { } </li></ul><ul><li>} </li></ul><ul><li><jboss> </li></ul><ul><li><enterprise-beans> </li></ul><ul><li><session> </li></ul><ul><li><ejb-name>NonAnnotationStateful</ejb-name> </li></ul><ul><li><clustered>true</clustered> </li></ul><ul><li><cluster-config> </li></ul><ul><li><partition-name>FooPartition</partition-name> </li></ul><ul><li><load-balance-policy> </li></ul><ul><li>org.jboss.ha.framework.interfaces.RandomRobin </li></ul><ul><li></load-balance-policy> </li></ul><ul><li></cluster-config> </li></ul><ul><li></session> </li></ul><ul><li></enterprise-beans> </li></ul><ul><li></jboss> </li></ul>
  47. 47. Session Beans clusterizados <ul><li>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. </li></ul><ul><li>O JBoss usa o MBean HASessionState para gerenciar a distribuição de estado no cluster. </li></ul>
  48. 48. Session Beans clusterizados ( jboss.xml ) <ul><li>@Stateful </li></ul><ul><li>@Clustered </li></ul><ul><li>@CacheConfig(maxSize=5000,removalTimeoutSeconds=18000) </li></ul><ul><li>public class MyBean implements MySessionInt { </li></ul><ul><li>private int state = 0; </li></ul><ul><li>public void increment() { </li></ul><ul><li>System.out.println(&quot;counter: &quot; + (state++)); </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  49. 49. Entity Beans clusterizados (2.X) <ul><li>Não faça isso !  </li></ul><ul><li>Exposição de objeto remoto de granularidade fina. </li></ul><ul><li>Sincronização de dados entre servidores. </li></ul>
  50. 50. Entity Beans clusterizados (3.0) <ul><li>Usa cache distribuido ( 2nd level cache  TreeCache ) </li></ul><ul><li>Se uma entidade for persistida via EntityManager com o cache ligado, então a mesma será inserida no cache. </li></ul><ul><li>Se uma entidade for atualizada via EntityManager com o cache ligado, então a mesma será atualizada no cache. </li></ul><ul><li>Se uma entidade for removida via EntityManager com o cache ligado, então ela também será removida do cache. </li></ul>
  51. 51. Serviços de HTTP
  52. 52. Serviços de HTTP <ul><li>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 </li></ul><ul><ul><li>Replicação de sessão </li></ul></ul><ul><ul><li>Balanceamento de carga de invocações </li></ul></ul>
  53. 53. Serviços de HTTP <ul><li>Toda replicação de estado é feita pelo próprio JBoss. Quando é utilizada a configuração all a replicação do estado é automática. </li></ul><ul><li>A única coisa que precisa ser feita é configurar a aplicação web com o atributo <distributable> no web.xml </li></ul>
  54. 54. Serviços de HTTP <ul><li>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. </li></ul>
  55. 55. Cluster de mensageria
  56. 56. Cluster de mensageria <ul><li>Mensageria em clusters com a configuração all devem funcionar sem problemas, com pequenos ajustes. </li></ul><ul><li>Unique server peer id </li></ul><ul><ul><li>Cada nó deve possuir um número único </li></ul></ul><ul><li>Clustered destinations </li></ul><ul><ul><li>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. </li></ul></ul>
  57. 57. Cluster de mensageria <ul><li>Clustered durable subscribers </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Clustered temporary destinations </li></ul><ul><ul><li>O JBoss Messaging suporta clustering de tópicos e filas temporários. </li></ul></ul><ul><li>Servidores não clusterizados </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Clustered connection factories </li></ul><ul><ul><li>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. </li></ul></ul>
  58. 58. Cluster de mensageria
  59. 59. DEMO Setup do ambiente Exibição do exemplo
  60. 60. Setup do ambiente <ul><li>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). </li></ul><ul><ul><li>./run.sh –c all –b 192.168.1.140 –Djboss.messaging.ServerPeerID=1 </li></ul></ul><ul><li>Se você só tem uma máquina, então faça o seguinte : </li></ul><ul><ul><li>Linux : bind one cluster node para localhost, e outro com o hostname da sua máquina </li></ul></ul>
  61. 61. Linux <ul><li>Faça o bind de um nó do cluster para localhost, e outro com o hostname da sua máquina : </li></ul><ul><ul><li>./run.sh –c node1 –b localhost –Djboss.messaging.ServerPeerID=1 </li></ul></ul><ul><ul><li>./run.sh –c node1 –b marcio-desktop –Djboss.messaging.ServerPeerID=1 </li></ul></ul>
  62. 62. Windows <ul><li>Criar dois IP’s “fake” com Microsoft Loopback adapter. </li></ul><ul><ul><li>Vá em adicionar hardware no painel de controle. </li></ul></ul><ul><ul><li>Selecione sim, eu tenho o hardware conectado. </li></ul></ul><ul><ul><li>Vá para o fim da lista de hardwares instalados e selecione “adicionar novo dispositivo de hardware” </li></ul></ul><ul><ul><li>Selecione a opção de instalação manual. </li></ul></ul><ul><ul><li>Selecione dispositivos de rede. </li></ul></ul><ul><ul><li>Selecione Microsoft como fabricante e Microsoft Loopback Adapter como dispositivo de rede. </li></ul></ul><ul><ul><li>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). </li></ul></ul><ul><ul><li>Clique em dispositivo loopback, vá em properties e então para TCP/IP. </li></ul></ul><ul><ul><li>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) </li></ul></ul><ul><ul><li>Clique em avançado e adicione outro IP (192.168.1.141) </li></ul></ul>
  63. 63. Bibliografia <ul><li>JBossAS Clustering Guide </li></ul><ul><ul><li>http://community.jboss.org/wiki/jBossAS5ClusteringGuide </li></ul></ul><ul><li>Jboss in Action </li></ul><ul><ul><li>http://www.amazon.com/JBoss-Action-Configuring-Application-Server/dp/1933988029/ref=sr_1_1?ie=UTF8&s=books&qid=1267201317&sr=8-1 </li></ul></ul><ul><li>Apache MOD_JK </li></ul><ul><ul><li>http://tomcat.apache.org/connectors-doc/ </li></ul></ul><ul><li>NGINX </li></ul><ul><ul><li>http://wiki.nginx.org/Main </li></ul></ul>
  64. 64. FIM P & R ?

×