BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Filip Hanik em Comunicação de Cluster Heterogêneos usando Apache Tribes

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

Favoritos

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).

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT