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 permite que as configurações sejam substituídas, dependendo das necessidades de cada carga de trabalho, o que permite a máxima flexibilidade e controle quando necessário.

O Apache Cassandra é uma ótima opção para criar aplicativos altamente resilientes devido à sua natureza distribuída e à arquitetura ponto a ponto. Qualquer nó no banco de dados pode fornecer a mesma funcionalidade que qualquer outro nó. Esse design contribui para a robustez e a resiliência do Cassandra. Este artigo fornece dicas sobre como otimizar a alta disponibilidade e como abordar a recuperação de desastres.

Objetivo do ponto de recuperação e objetivo de tempo de recuperação

Desde que você tenha os seguintes elementos, o RPO (objetivo do ponto de recuperação) e o RTO (objetivo de tempo de recuperação) geralmente são baixos, próximos a zero:

• 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. Configure essa opção ao criar um cluster no portal do Azure ou usando a CLI do Azure.
• Configurado o failover no nível do aplicativo usando a política de balanceamento de carga no driver do cliente ou failover no nível do balanceamento de carga usando o Gerenciador de Tráfego do Azure ou o Azure Front Door.

RTO é o tempo de duração de uma interrupção. É baixo porque o cluster é resiliente tanto entre zonas quanto entre regiões. Além disso, o próprio Apache Cassandra é um sistema altamente tolerante a falhas e ponto a ponto, onde todos os nós podem gravar por padrão.

RPO é a quantidade de dados que você pode perder em uma interrupção. É baixo porque os dados são sincronizados entre todos os nós e data centers. A perda de dados em uma interrupção seria mínima.

Observação

Não é possível alcançar RTO=0 e RPO=0 conforme o Teorema CAP. Avalie a compensação entre consistência e disponibilidade ou desempenho ideal.

Esse equilíbrio é diferente para cada aplicativo. Por exemplo, se o aplicativo for muito lido, talvez seja melhor lidar com o aumento da latência de gravações entre regiões para evitar a perda de dados, o que favorece a consistência. Se o aplicativo tiver uma carga intensa de gravações com requisitos rigorosos de latência, o risco de perder algumas das gravações mais recentes em uma grande interrupção regional poderá ser aceitável, o que favorece a disponibilidade.

Zonas de disponibilidade

A arquitetura ponto a ponto do Cassandra oferece tolerância a falhas desde a base. A Instância Gerenciada do Azure para Apache Cassandra fornece suporte para zonas de disponibilidade em regiões selecionadas. Esse suporte aprimora a resiliência no nível da infraestrutura. Para um fator de replicação de 3, o suporte à zona de disponibilidade garante que cada réplica esteja em uma zona de disponibilidade diferente. Essa abordagem impede que uma interrupção zonal afete seu banco de dados ou 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 um nível de tolerância a falhas e resiliência. Considere também o impacto das interrupções regionais para seus aplicativos. Para proteger contra interrupções no nível da região, é altamente recomendável implantar vários clusters de região. Embora sejam raros, o impacto potencial é grave.

Para a continuidade dos negócios, não é suficiente usar um banco de dados de várias regiões. Outras partes do aplicativo também precisam ser distribuídas ou com mecanismos adequados para failover. Se os usuários estiverem espalhados por várias 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. Todos os nós em todos os data centers em todo o cluster podem atender a leituras e gravações da região mais próxima deles.

Se o aplicativo estiver configurado como ativo-ativo, considere como o teorema CAP se aplica à consistência dos seus dados entre réplicas (nós) e as compensações necessárias para oferecer 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 compromisso. Se houver uma interrupção regional, algumas gravações poderão ser perdidas em LOCAL_QUORUM.

• Se um aplicativo for executado em paralelo, prefira gravações QUORUM_EACH para a maioria dos casos para garantir a consistência entre os dois data centers.

• Se sua meta for favorecer a consistência ou o RPO inferior, em vez de latência ou disponibilidade, ou RTO inferior, suas configurações de consistência e o fator de replicação devem refletir essa meta.

  Em 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 só é implantado em uma única região. A região é a selecionada quando você implanta 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.

Como os data centers ainda devem continuar funcionando, esse problema não afeta o SLA de disponibilidade do serviço. Durante esse período, talvez não seja possível fazer alterações na configuração do banco de dados no portal do Azure ou nas 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 esteja configurada. Nos estágios iniciais do desenvolvimento, recomendamos que você faça testes simples usando cqlsh. Por exemplo, insira um valor enquanto estiver conectado a um data center e leia-o do outro.

Em particular, quando você configurar um segundo data center em que um data center existente já tem dados, determine que você replicou todos os dados e se o sistema está pronto. Recomendamos que você monitore o progresso da replicação por meio de nossos comandos DBA com nodetool netstats. Uma abordagem alternativa seria contar as linhas em cada tabela. Tenha em mente que, com grandes volumes de dados, devido à natureza distribuída do Cassandra, essa abordagem pode dar apenas 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. Essa abordagem ajuda seu aplicativo a fazer failover instantaneamente para um data center em espera ativa em uma região secundária. Se ocorrer uma interrupção regional, essa abordagem garantirá que não haja degradação de desempenho. A maioria dos drivers de cliente do Cassandra fornece opções para iniciar o failover no nível do aplicativo. Por padrão, eles assumem que a interrupção regional significa que o aplicativo também está inativo, portanto, o failover deve ocorrer no nível do balanceador de carga.

Para reduzir o custo de provisionamento de um segundo data center, você pode preferir implantar um SKU menor e menos nós em sua região secundária. Quando ocorre uma interrupção, a escala vertical e horizontal pronta para uso facilita o aumento da escala na Instância Gerenciada do Azure para Apache Cassandra. Enquanto seus aplicativos fazem o failover para a região secundária, você pode escalar horizontalmente e escalar verticalmente os nós no seu data center secundário de forma manual. Seu data center secundário atua como uma espera passiva de custo mais baixo. Essa abordagem precisa ser equilibrada em relação ao tempo necessário para restaurar o sistema para a capacidade total se ocorrer 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. Você pode escolher sua 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. Compactações podem ocorrer a qualquer momento com o Cassandra. Eles 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. Mesmo que estivessem, pode levar muito tempo para restaurar um banco de dados a partir de backups. Portanto, recomendamos fortemente várias implantações de região, juntamente com a habilitação de zonas de disponibilidade sempre que possível, para atenuar cenários de desastre e ser capaz de se recuperar efetivamente delas. Essa abordagem é particularmente importante nos raros cenários em que a região com falha não pode ser recuperada. Sem a replicação de várias regiões, todos os dados podem ser perdidos.

Próxima etapa

Criar um cluster usando o portal do Azure