Quer executar o Cassandra em um container? Você precisa resolver esses 4 problemas primeiro

O Apache Cassandra, desenvolvido inicialmente no Facebook, é um banco de dados NoSQL distribuído de código aberto, projetado para lidar com grandes quantidades de dados em servidores de commodities. Além do Facebook, ele é usado em empresas conhecidas por suas operações em larga escala, como o CERN e o Instagram e, consequentemente, é um dos bancos de dados de acesso para algumas das maiores aplicações do mundo.

Como parte fundamental dos aplicativos baseados em microserviços, o Cassandra pode se beneficiar de ser “conteneirizado”. Por isso o banco de dados é uma das imagens mais populares no DockerHub com mais de 5 milhões de pulls.

No entanto, executar o Cassandra em um container requer algumas considerações especiais. Se você puder resolver esses problemas, terá trilhado a maior parte do caminho rumo a uma implementação bem sucedida do Cassandra em containers.

Alcançando o melhor desempenho de leitura/escrita com hiper-convergência

Quando executamos o Cassandra, o desempenho de leitura e gravação importam. O Cassandra foi projetado para ser executado em ambientes bare metal, onde cada servidor oferece seu próprio disco como mídia de armazenamento. A ideia de executar um aplicativo na mesma máquina onde acontece seu armazenamento é chamada de “hyper-convergence”. O Cassandra sempre obterá o melhor desempenho usando esta configuração devido ao seu uso intenso de disco durante as operações principais, como escritas, leituras e operações de bootstrap. O armazenamento compartilhado também coloca pressão nessas operações.

Um ponto de partida para uma implementação de container Cassandra bem sucedida será permitir que o banco de dados seja executado em bare metal ou VMs com armazenamento conectado diretamente, sem sacrificar a flexibilidade de automatização de tarefas de agendamento através de uma estrutura de orquestração como Kubernetes, Mesosphere DC/OS ou Swarm.

Simplificando implementações usando a estratégia de posicionamento Network Topology

A execução do Cassandra com armazenamento em anexo direto confere o melhor desempenho, mas também é preciso pensar na confiabilidade. Para garantir a confiabilidade, você deve certificar-se de implementar o Cassandra ring usando a chamada “estratégia de Network Topology”, resistente a modos de falha altamente correlacionados, como falhas de zona de rack ou disponibilidade, falhas de resfriamento ou partições de rede.

O problema com a estratégia de Network Topology é que é complicado implementá-la manualmente. Além disso, se colocar os containers na topologia da rede otimizada, não poderá aproveitar o agendamento automatizado. A segunda questão para chegarmos a um cluster Cassandra conteneirizado será o posicionamento automatizado das réplicas, de acordo com a estratégia de topologia de rede.

Melhorando o tempo de recuperação do cluster após a falha do nó

Outra consideração ao executar o Cassandra em produção é o tempo de recuperação do cluster em caso de interrupção ou falha. O Cassandra é, por si só, capaz de replicar dados. Se um nó morre, um novo nó colocado no cluster será preenchido com dados de outros nós saudáveis – um processo conhecido como bootstrapping.

Como vimos acima, o processo de bootstrap coloca carga no cluster, pois os recursos são usados para transmitir dados para novos nós. Essa carga reduz o desempenho de leitura/gravação do Cassandra, reduzindo também o desempenho do aplicativo. A chave para o bootstrapping é concluir o mais rápido possível, mas isso é cada vez mais difícil, pois o cluster está sob stress. Então, a terceira questão a ser superada para executar o Cassandra em containers são operações rápidas de bootstrap.

Aumentando a densidade do container executando com segurança vários anéis nos mesmos hosts

As melhores práticas operacionais acima descritas objetivam a confiabilidade e o desempenho. Agora podemos focar na eficiência. A maioria das organizações usa vários anéis Cassandra. No entanto, uma vez que o Cassandra é uma aplicação intensiva em recursos, os custos de operação de vários anéis podem ser consideráveis. Seria ideal se vários anéis pudessem ser executados nos mesmos hosts.

Containers leves são uma ótima maneira de fazer isso, mas é necessário habilitar cada container para usar seu próprio volume e garantir que não sejam alocados dados para duas instâncias de Cassandra que pertençam ao mesmo anel no mesmo nó. Em vez disso, você deseja que cada um dos seus anéis se espalhe por todo o cluster, maximizando a resiliência face a falhas de hardware.

Fonte: insideBIGDATA

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.