Arquitetura do Cassandra – Topologia de Rede

Olá Pessoal,

Continuando nossas discussões sobre Cassandra, hoje vamos abordar o tema de topologia de rede. O Cassandra possui um característica chamada Rack Awareness (também encontrada em outras tecnologias, como o Hadoop), que basicamente é uma forma de saber quem são os nodes mais “próximos”.

Isto é feito via dois atributos: Rack e Datacenter. Desta forma, ele espera que se comunicar com alguém do mesmo Rack é mais rápido, seguido de alguém do mesmo DC e por último alguém de outro DC.

Como o Cassandra consegue descobrir estes atributos? Quem faz isso é uma combinação entre um parâmetro do cassandra.yaml – endpoint_snitch e um arquivo de propriedades (properties).
Para ambientes on-premisses, temos duas opções mais comuns PropertyFileSnitch e GossipingPropertyFileSnitch e outras menos utilizadas Dynamic Snitching, SimpleSnitch e RackInferringSnitch.

Vamos falar das mais comuns:

• PropertyFileSnitch: precisamos descrever no arquivo cassandra-topology.properties como os nodes estão distribuídos pelos Racks e DCs.

Veja um exemplo:

E ao verificarmos o nodetool status, temos:

O ponto fraco desta configuração, e que a torna inviável em um ambiente produtivo, é que para cada alteração na configuração, o arquivo precisa ser replicado para todos os nodes e o Cassandra restartado.
Nada atrativo, não é? E antes de ler o próximo tópico, ja parou para pensar como você resolveria isso?

• GossipingPropertyFileSnitch: O Cassandra utiliza o protocolo Gossip em alguns pontos para saber a saúde dos membros do cluster, e aqui também é utilizado.
  Neste formato de snitch, informamos no arquivo cassandra-rackdc.properities em qual rack e DC o node se encontra. Esta informação é espalhada via Gossip, onde o node “diz” para os demais que está no DC=DC1 e no rack=Rack1.
  A vantagem aqui é que cada node entrando no cluster só precisa saber sobre si mesmo (via property file). Sobre os demais, ele é informado via Gossip
  e a cada nova configuração (add ou decomission), não há necessidade de restart.
  O arquivo fica assim:

E o nodetool status responde:

Sobre os demais formatos de snitch, vou apenas descrever brevemente:

• Dynamic snitching: O Cassandra monitora o tempo de resposta entre os nodes e, baseado neste histórico,   atribui a “proximidade” entre eles.
• SimpleSnitch: Neste formato, o Cassandra não conhece informações a respeito de Rack e DC. Portanto, deve ser utilizado apenas para deploys single DC.
• RackInferringSnitch: Aqui o IP de cada node é levado em consideração, onde seus octetos indicam a localização.

Para finalizar, em ambientes clouds tem surgido tipos de snitches que facilitam ainda mais a vida. Eles são capazes de buscar via metadados da instance as informações referentes a região e zona de disponibilidade, não sendo necessário,  nenhum arquivo de configuração (em alguns casos opcional). Os tipos são: Ec2Snitch, Ec2MultiRegionSnitch, GoogleCloudSnitch e CloudstackSnitch. Veja como fica o nodetool com o Ec2Snitch, repare que o Datacenter está associado ao nome da Região e o Rack com a Zona de Disponibilidade (AZ):

Bom, espero ter conseguido explicar um pouco da diferença entre os vários tipos de snitches. Qualquer dúvida ou sugestão (mesmo de temas), entre em contato.

Até a próxima.

Abraços,

Adriano Bonacin