Melhores práticas de alta disponibilidade e recuperação de desastre
A Instância Gerenciada do Azure para Apache Cassandra é um serviço totalmente gerenciado para clusters Apache Cassandra de código aberto puro. O serviço também permite que as configurações sejam substituídas, dependendo das necessidades específicas de cada carga de trabalho, permitindo o máximo de flexibilidade e controle quando necessário.
O Apache Cassandra é uma ótima opção para criar aplicativos altamente resilientes devido à natureza distribuída e à arquitetura – sem mestre que qualquer nó no banco de dados pode fornecer exatamente a mesma funcionalidade que qualquer outro nó – que contribua para a robustez e resiliência do Cassandra. Este artigo fornece dicas sobre como otimizar a alta disponibilidade e como abordar a recuperação de desastres.
RPO e RTO
RPO (objetivo de ponto de recuperação) e RTO (objetivo de tempo de recuperação), normalmente serão baixos (próximo a zero) para Apache Cassandra, desde que você tenha:
- Uma implantação de várias regiões com replicação entre regiões e um fator de replicação de 3.
- Zonas de disponibilidade habilitadas (selecione a opção ao criar um cluster no portal ou por CLI do Azure).
- Configurado o failover no nível do aplicativo usando a política de balanceamento de carga no driver cliente e/ou failover no nível do balanceamento de carga usando o gerenciador de tráfego/a front door do Azure.
O RTO (“quanto tempo você está em uma interrupção”) será baixo porque o cluster será resiliente em zonas e regiões e porque o Apache Cassandra em si é um sistema altamente tolerante a falhas e sem mestre (todos os nós podem gravar) por padrão. O RPO (“quantos dados você pode perder em uma interrupção”) será baixo porque os dados serão sincronizados entre todos os nós e data centers, portanto, a perda de dados em uma interrupção seria mínima.
Observação
Teoricamente, não é possível obter RTO=0 e RPO=0 por Teorema CAP. Você precisará avaliar a troca entre consistência e disponibilidade/desempenho ideal – isso parecerá diferente para cada aplicativo. Por exemplo, se o aplicativo tiver muita leitura, talvez seja melhor lidar com o aumento da latência de gravações entre regiões para evitar a perda de dados (favorecendo a consistência). Se a aplicação for pesada e com um orçamento de latência apertado, o risco de perder algumas das gravações mais recentes em uma grande interrupção regional poderá ser aceitável (favorecendo a disponibilidade).
Zonas de disponibilidade
A arquitetura sem mestre do Cassandra gera tolerância a falhas do zero, e a Instância Gerenciada do Azure para Apache Cassandra fornece suporte para zonas de disponibilidade em regiões selecionadas para aprimorar a resiliência no nível da infraestrutura. Dado um fator de replicação de 3, o suporte à zona de disponibilidade garante que cada réplica esteja em uma zona de disponibilidade diferente, impedindo assim que uma interrupção zonal afete seu banco de dados/aplicativo. Recomendamos habilitar zonas de disponibilidade sempre que possível.
Redundância de várias regiões
A arquitetura do Cassandra, juntamente com o suporte a zonas de disponibilidade do Azure, oferece algum nível de tolerância a falhas e resiliência. No entanto, é importante considerar o impacto das interrupções regionais para seus aplicativos. É altamente recomendável implantar clusters de várias regiões para proteger contra interrupções no nível da região. Embora sejam raros, o impacto potencial é grave.
Para a continuidade dos negócios, não é suficiente fazer apenas o banco de dados de várias regiões. Outras partes do aplicativo também precisam ser implantadas da mesma maneira por serem distribuídas ou com mecanismos adequados para fazer failover. Se os usuários estiverem espalhados por muitas localizações geográficas, uma implantação de data center de várias regiões para seu banco de dados terá o benefício adicional de reduzir a latência, pois todos os nós em todos os data centers em todo o cluster poderão atender a leituras e gravações da região mais próxima deles. No entanto, se o aplicativo estiver configurado como “ativo-ativo”, é importante considerar como teorema CAP se aplica à consistência de seus dados entre réplicas (nós) e as compensações necessárias para fornecer alta disponibilidade.
Em termos de teorema CAP, o Cassandra é, por padrão, um sistema de banco de dados AP (tolerante a partições disponíveis), com consistência altamente ajustável. Para a maioria dos casos de uso, é recomendável usar local_quorum para leituras.
- Em ativo-passivo para gravações, há uma compensação entre confiabilidade e desempenho: para confiabilidade, recomendamos QUORUM_EACH mas para a maioria dos usuários LOCAL_QUORUM ou QUORUM é um bom comprometimento. No entanto, observe que, no caso de uma interrupção regional, algumas gravações podem ser perdidas em LOCAL_QUORUM.
- No caso de um aplicativo ser executado em paralelo as gravações QUORUM_EACH são preferenciais para a maioria dos casos para garantir a consistência entre os dois data centers.
- Se sua meta for favorecer a consistência (RPO inferior) em vez de latência ou disponibilidade (RTO inferior), isso deverá ser refletido em suas configurações de consistência e fator de replicação. Como regra geral, o número de nós de quorum necessários para uma leitura mais o número de nós de quorum necessários para uma gravação deve ser maior do que o fator de replicação. Por exemplo, se você tiver um fator de replicação de 3 e quorum_one em leituras (um nó), deverá fazer quorum_all em gravações (três nós), de modo que o total de 4 seja maior que o fator de replicação de 3.
Observação
O operador do plano de controle da Instância Gerenciada do Azure para Apache Cassandra será implantado em uma única região (a região selecionado ao implantar inicialmente o primeiro data center). No caso improvável de uma interrupção total da região, confirmamos um tempo de recuperação de 3 horas para fazer failover do plano de controle para outra região. Isso não afeta o SLA de disponibilidade do serviço, pois os data centers ainda devem continuar funcionando. No entanto, durante esse período, talvez não seja possível fazer alterações na configuração do banco de dados por meio do portal ou das ferramentas do provedor de recursos.
Replicação
Recomendamos auditar keyspaces e suas configurações de replicação de forma periódica para garantir que a replicação necessária entre data centers tenha sido configurada. Nos estágios iniciais do desenvolvimento, recomendamos testar se tudo funciona conforme o esperado fazendo testes simples usando cqlsh. Por exemplo, inserir um valor enquanto estiver conectado a um data center e lê-lo do outro.
Em particular, ao configurar um segundo data center em que um data center existente já tem dados, é importante determinar se todos os dados foram replicados e o sistema está pronto. Recomendamos monitorar o progresso da replicação por meio de nossos comandos DBA com nodetool netstats. Uma abordagem alternativa seria contar as linhas em cada tabela, mas tenha em mente que, com tamanhos de Big Data, devido à natureza distribuída do Cassandra, isso só pode dar uma estimativa aproximada.
Balanceando o custo da recuperação de desastre
Se seu aplicativo for “ativo-passivo”, ainda recomendamos que você implante a mesma capacidade em cada região para que seu aplicativo possa fazer failover instantaneamente em um data center “em espera frequente” em uma região secundária. Isso garante que não haja degradação de desempenho no caso de uma interrupção regional. A maioria dos drivers de cliente do Cassandra fornece opções para iniciar o failover no nível do aplicativo. Por padrão, eles pressupõem que a interrupção regional significa que o aplicativo também está inoperante, e nesse caso o failover deve ocorrer no nível do balanceador de carga.
No entanto, para reduzir o custo de provisionamento de um segundo data center, talvez você prefira implantar um SKU menor e menos nós na região secundária. Quando ocorre uma interrupção, o dimensionamento é facilitado na Instância Gerenciada do Azure para Apache Cassandra por meio do dimensionamento vertical e horizontal pronto para uso. Enquanto seus aplicativos fazem failover para a região secundária, você pode escalar horizontalmente e verticalmente de forma manual os nós em seu data center secundário. Nesse caso, seu data center secundário atua como um modo de espera de custo mais baixo. Essa abordagem precisaria ser equilibrada em relação ao tempo necessário para restaurar o sistema para a capacidade total no caso de uma interrupção. É importante testar e praticar o que acontece quando uma região é perdida.
Observação
Escalar verticalmente os nós é muito mais rápido do que escalar horizontalmente. Tenha isso em mente ao considerar o equilíbrio entre a escala vertical e horizontal e o número de nós a serem implantados em seu cluster.
Agendamentos de backup
Os backups são automáticos na Instância Gerenciada do Azure para Apache Cassandra, mas você pode escolher a própria agenda para os backups diários. Recomendamos escolher horários com menos carga. Embora os backups estejam configurados para consumir apenas CPU ociosa, eles podem, em algumas circunstâncias, disparar compactações no Cassandra, o que pode levar a um aumento no uso da CPU. As compactações podem ocorrer a qualquer momento com o Cassandra e dependem da carga de trabalho e da estratégia de compactação escolhida.
Importante
A intenção dos backups é apenas atenuar a perda acidental de dados ou a corrupção de dados. Não recomendamos backups como uma estratégia de recuperação de desastre. Os backups não são com redundância geográfica e, mesmo que fossem, pode levar muito tempo para recuperar um banco de dados de backups. Portanto, recomendamos fortemente uma implantação de várias regiões, juntamente com a habilitação de zonas de disponibilidade sempre que possível, para mitigar em cenários de desastre e ser capaz de se recuperar efetivamente delas. Isso é especialmente importante nos cenários raros em que a região com falha não pode ser abordada, em que pode haver perda de todos os dados, sem replicação de várias regiões.
Próximas etapas
Neste artigo, apresentamos algumas práticas recomendadas para a criação de aplicativos resilientes com o Cassandra.