Como migrar o Cassandra on premises para cloud?
Introdução
Essa é uma das perguntas que tenho visto bastante ultimamente. Cassandra é um banco de dados poderoso, linearmente escalável. Porém a mão de obra é realmente escassa e nem toda empresa opta por ter um DBA Cassandra dedicado, pelo menos não as não gigantes. Somado a isso, outros pontos são levados em consideração quando pensamos em uma migração: a modernização da infraestrutura e custos. Então, como migrar nosso Cassandra para cloud?
Visão geral
Algum tempo atrás migrar seu workload para nuvem, seja banco de dados ou não, era quase obrigatório. Pessoas tinham vergonha de dizer que ainda rodavam on-premises.
Depois começou aparecer o custo do exagero ou da arquitetura mal planejada. Alguns movimentos contrários começaram a surgir, com empresas caprichando em suas clouds privadas.
Uma coisa é certa, provedores de cloud pública ou empresas especializadas (usando a infraestrutura de uma cloud pública) começaram a ofertar com sucesso seus serviços gerenciados, e aqui falaremos especialmente dos serviços de Cassandra. É menos trabalhoso para sustentar, rápido para começar a usar, porém é consideravelmente mais caro. Já ouvi casos de ser até impraticável, mas é uma conversa para outro momento.
Primeiro passo, portanto, falando em migração do Cassandra para cloud, temos que escolher entre duas opções: migrar seu ambiente on premises para VMs (IaaS) e você continua a administrar seu ambiente ou migra para serviços gerenciados, como AWS Keyspace, Datastax AstraDB e paga um pouco mais caro por todo o conjunto de infraestrutura e administração. Vamos discutir um pouco mais sobre cada opção.
IaaS - Você administra seu ambiente
Este modelo de migração é muito simples se os ambientes on premises e cloud conseguirem se conversar. Podemos usar features nativas do Cassandra para atingir esse objetivo. Você pode adicionar suas VMs na Cloud como outro Datacenter (DC) no Cassandra, mudar o Replication Factor para que tenhamos réplicas nos novos DCs e sincronizar os dados entre DCs. Com isso teremos réplicas dos nossos dados nos DCs on premises e réplicas na cloud. O próximo passo é remover as réplicas e os servidores on premises do nosso cluster, sobrando somente os DCs na cloud.
E tudo isso a gente consegue usando apenas features nativas, como dito anteriormente. Vamos apenas adicionar e remover nodes do cluster. Precisamos de um pequeno cuidado para que eles fiquem em DCs diferentes, visto que conseguimos controlar o número de réplicas por DC. O lado bom dessa estratégia é que temos zero downtime e um esforço muito pequeno.
Caso desejado, podemos conviver com os dois ambientes sem problema nenhum. Algo como minha aplicação usando o Cassandra na cloud e replicando para o DC on premises como ambiente de DR. O Cassandra ficará responsável por replicar os dados e possui uma ferramenta nativa para garantir o sincronismo de dados.
Serviço gerenciado
Neste caso você deseja que o provedor ofereça a infraestrutura e administre o seu ambiente. Não há opção de adicionar nodes no cluster existente e precisamos de uma outra opção para migração.
Se você conferir as sugestões da Amazon para migração talvez você fique desanimado. Isso porque a forma como eles propõem requer downtime proporcional ao volume de dados, que acaba sendo impraticável em muitos casos.
Por outro lado, a Datastax oferece uma complexa arquitetura que permite a migração com um mínimo downtime, possui algumas limitações sim, como quando há uma coluna counter, mas é a minha solução favorita para migrações de Cassandra. Essa ferramenta, na verdade, permite migração de qualquer ambiente Cassandra (você encontra algumas distribuições aqui) para qualquer outro ambiente, como você pode ver nessa mesma referência.
No caso do ScyllaDB, a ideia é semelhante, mas ele supõe que você fique responsável por reescrever seu código para atualizar o ambiente novo e antigo (double write). Eu nunca testei essa migração, então pode ser que eu esteja não incluindo algo importante, mas aqui tem todos os detalhes.
Normalmente estes serviços gerenciados impõem limitações e você precisa ter certeza de que isso não vai ter um empecilho. Exemplo: o Amazon Keyspace não oferece suporte a User Defined Type, você não pode truncar tabelas. O AstraDB tem vários guardrails para tentar manter seu Cassandra mais estável possível. Esteja atento a isso antes de começar.
Conclusão
Tratando-se de migrações, os cenários em que a migração pode ser realizada usando as features nativas do Cassandra são os mais tranquilos. Sua aplicação normalmente precisa apenas apontar para um DC novo e nada muda, você vai ter o novo ambiente rodando com a mesma versão.
Para os casos de serviços gerenciados, precisamos de algo mais elaborado. Nisto a opção da Datastax é a minha preferida. Vamos tentar descrever o passo em um próximo post, mas ela resolve todo o problema de fazer um double write enquanto você consegue migrar seus dados usando uma estratégia de sua preferência. Você faz o deploy dos workers e da monitoração, que usa grafana, com ansible. Tudo rapidinho e pronto para o uso.
E qualquer que seja sua opção, o procedimento de volta será idêntico ao processo de ida. Se for Add/Remove nodes, você adiciona seus nodes antigos e remove os novos, se for uma migração lógica, você precisa de uma nova migração para o ambiente antigo.
Você também pode gostar
Login com: Google