BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Filip Hanik em Comunicação de Cluster Heterogêneos usando Apache Tribes

por Srini Penchikala , traduzido por Flávia Castro de Oliveira em 16 Fev 2009 |

Apache Tribes, um módulo do Tomcat 6, suporta comunicação de grupos no servidor cluster. Filip Hanik falou sobre os desafios em clusters heterogêneos e como Tribes ajuda com requisitos de comunicação de grupos do Tomcat clusters. Ele fez uma apresentação na conferência SpringOne Americas sobre o framework de messaging Tribes.

Filip iniciou a apresentação dizendo que existem diversos projetos open source para comunicação de grupos incluindo Appia, Spread, Erlang e JGroups. Ele falou sobre o modelo de grupo uniforme onde todos nós em um cluster são idênticos e eles processam, enviam e recebem mensagem da mesma maneira. Muitos módulos de comunicação de grupo são construídos para um modelo de comunicação uniforme. Mas na maioria das implementações de clusters heterogêneos isto frequentemente não é a melhor solução para alcançar a performance e a escalabilidade que é necessário no cluster.

Um modelo de comunicação de grupo não uniforme é a melhor solução quando os processos em cada nó do cluster são dinâmicas e estão em execução em ambiente hardware heterogêneo. As mensagens são enviadas com diferentes prioridades e níveis de garantia.

Tribes é um framework de messaging com capacidades de comunicação de grupo que foi criado a partir do código de replicação do cluster/session do Tomcat 5. É o framework de comunicação para implementação de cluster do Tomcat. Um de seus objetivos é simplificar a comunicação peer-to-peer e peer-to-group para aplicações distribuídas. Tribes suporta dois tipos de entrega de mensagem, uma entrega de mensagem concorrente que pode ser usado até mesmo entre dois nós e uma entrega paralela que pode ser usada para enviar mensagens para nós múltiplos.

Outas características no Tribes framework são:

  • Entrega de Mensagem Garantida: A implementação default é baseada em TCP e usa pacotes java.io e java.nio.
  • Níveis de Garantia: Tribes suporta 3 níveis de garantia de entrega da mensagem (NO_ACK, ACK, and SYNC_ACK).
  • Per message delivery semantics: Esta semântica permite que cada mensagem seja entregue de maneira diferente bem como usar um nível diferente de garantia por mensagem.
  • Interceptores Plugáveis: Este pode ser usado para interceptar qualquer evento através de métodos definidos e reagir em atributos de mensagem (flags). A classe ChannelInterceptorBase pode ser usada para minimizar o código redundante para métodos não interceptados.
  • Entrega de Feedback: Tribes visa entregar feedback para cada mensagem e cada semântica de entrega (NO_ACK, ACK, SYNC_ACK). Entrega de mensagem pode ser síncrona ou assíncrona.
  • Entrega Concorrente & Paralela: Entrega Concorrente é mais do que uma mensagem que pode ser enviada ou recebida em qualquer momento. Não existe "message blocking" significando que uma mensagem de 10 MB com nível de garantia SYNC_ACK não vai parar um nível de garantia NO_ACK de 10 KB. Entrega Paralela permite enviar uma mensagem para vários destinos em paralelo usando uma thread (NIO).
  • Fixed Node Hierarchy: Esta funcionalidade suporta a habilidade para determinar o determine cluster leadership, grupos auto merge, e a descoberta de nó onde multicast pode não funcionar.
  • Detecção de falha: Este inclui um interceptor simples TcpFailureDetector para fornecer feedback quando um membro do cluster cai. Não há necessidade de esperar por timeout e sem riscos de pings de nós ficarem presos em uma rede ocupada.

Tribes também suporta funcionalidades como mensagem RPC e um Canal JNDI para ligar um canal em um JNDI tree. A arquitetura do framework inclui os seguintes componentes:

  • Canal: Este é o primeiro interceptor na cadeia. Contém uma lista de um ou mais ChannelListeners e MembershipListeners. Ele serializa e deserializa mensagens e suporta ByteMessage para transferênca de pure byte[] data.
  • Interceptors: Alguns exemplos de interceptors são failure detection/static membership, por ordem total ou por ordem do membro, leadership election/message data encryption, message dispatch (mensagens assíncronas) e todas ou nenhuma garantia de entrega.
  • Coordenador: Este é o último interceptor na cadeia. Ele coordena componentes I/O tais como Sender, Receiver e Membership.

Na apresentação, Filip também demonstrou uma aplicação de exemplo mostrando como habilitar clustering no Tomcat e as opções de configuração para habilitar um webapp para replicação de sessão e contexto. O arquivo server.xml inclui a configuração para elementos cluster como Cluster, Session Manager (DeltaManager ou BackupManager), Channel (Tribes), Membership (suporta duas formas de membership: Dynamic membership que usa multicasting para descobrir outros nós em tempo real e Static membership onde definimos cada nó no server.xml), Messaging (acontece no TCP; cada nó tem um receiver e um sender), Receiver (recebe mensagens de clusters), Sender (envia mensagens de cluster), Interceptors (semelhante a valves em termos de funcionalidade), Valves (iniciam a replicação da sessão no final de cada request), e ClusterListener (suporta custom messaging listeners para certos tipos de mensagens).

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT