Partilhar via

Práticas recomendadas para alta disponibilidade e recuperação de desastres

  • Artigo

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 a máxima flexibilidade e controle onde necessário.

O Apache Cassandra é uma ótima opção para a construção de aplicativos altamente resilientes devido à sua natureza distribuída e arquitetura sem mestre – qualquer nó no banco de dados pode fornecer exatamente a mesma funcionalidade que qualquer outro nó – contribuindo 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 (Recovery Point Objetive) e RTO (Recovery Time Objetive), ambos normalmente serão baixos (perto de zero) para o Apache Cassandra, desde que você tenha:

O RTO ("quanto tempo você está inativo em uma interrupção") será baixo porque o cluster será resiliente em ambas as zonas e regiões, e porque o próprio Apache Cassandra é 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.

Nota

Não é teoricamente possível alcançar tanto RTO=0 como RPO=0 por Teorema de Cap. Você precisará avaliar a troca entre consistência e disponibilidade/desempenho ideal - isso será diferente para cada aplicativo. Por exemplo, se o seu aplicativo tiver leitura pesada, 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 escrita 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 pode ser aceitável (favorecendo a disponibilidade).

Zonas de disponibilidade

A arquitetura masterless da Cassandra traz tolerância a falhas desde o início, e a Instância Gerenciada do Azure para Apache Cassandra fornece suporte para zonas de disponibilidade em regiões selecionadas para melhorar 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, evitando assim que uma interrupção zonal afete seu banco de dados/aplicativo. Recomendamos ativar as zonas de disponibilidade sempre que possível.

Redundância multirregião

A arquitetura da 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 basta tornar o banco de dados multirregional. Outras partes do seu aplicativo também precisam ser implantadas da mesma maneira, seja sendo distribuídas ou com mecanismos adequados para failover. Se seus usuários estiverem espalhados por muitos locais geográficos, uma implantação de data center em várias regiões para seu banco de dados terá o benefício adicional de reduzir a latência, já que todos os nós em todos os data centers no cluster podem atender leituras e gravações da região mais próxima deles. No entanto, se o aplicativo estiver configurado para ser "ativo-ativo", é importante considerar como o 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 do teorema CAP, Cassandra é por padrão um sistema de banco de dados AP (Available Partition-tolerant), com consistência altamente ajustável. Para a maioria dos casos de uso, recomendamos o uso do local_quorum para leituras.

  • No ativo-passivo para gravações há um compromisso entre confiabilidade e desempenho: para confiabilidade, recomendamos QUORUM_EACH mas para a maioria dos usuários LOCAL_QUORUM ou QUORUM é um bom compromisso. Note, no entanto, 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 QUORUM_EACH as gravações são preferidas para a maioria dos casos para garantir a consistência entre os dois data centers.
  • Se o seu objetivo é favorecer a consistência (RPO mais baixo) em vez de latência ou disponibilidade (RTO mais baixo), isso deve ser refletido nas configurações de consistência e no 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), para que o total de 4 seja maior do que o fator de replicação de 3.

Nota

O operador do plano de controle da Instância Gerenciada do Azure para Apache Cassandra só será implantado em uma única região (a região selecionada ao implantar inicialmente o primeiro data center). No caso improvável de uma interrupção total da região, comprometemo-nos a um tempo de recuperação de 3 horas para fazer o 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 a partir das ferramentas do portal ou do provedor de recursos.

Replicação

Recomendamos a auditoria keyspaces e suas configurações de replicação de tempos em tempos para garantir que a replicação necessária entre data centers tenha sido configurada. Nos estágios iniciais de desenvolvimento, recomendamos testar se tudo funciona como esperado, fazendo testes simples usando cqlsho . 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 onde um data center existente já tem dados, é importante determinar se todos os dados foram replicados e se 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 de Cassandra, isso só pode dar uma estimativa aproximada.

Equilibrando o custo da recuperação de desastres

Se seu aplicativo for "ativo-passivo", geralmente ainda recomendamos que você implante a mesma capacidade em cada região para que seu aplicativo possa fazer failover instantaneamente em um data center "hot standby" em uma região secundária. Isso garante que não haja degradação do desempenho no caso de uma interrupção regional. A maioria dos drivers de cliente 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, caso em que o failover deve acontecer no nível do balanceador de carga.

No entanto, para reduzir o custo de provisionamento de um segundo data center, talvez você prefira implantar uma SKU menor e menos nós em sua região secundária. Quando ocorre uma interrupção, a expansão é facilitada na Instância Gerenciada do Azure para Apache Cassandra por dimensionamento vertical e horizontal turnkey. Enquanto seus aplicativos fazem failover para sua região secundária, você pode expandir e dimensionar manualmente os nós em seu data center secundário. Nesse caso, seu data center secundário atua como um modo de espera quente de baixo custo. Adotar essa abordagem precisaria ser balanceado com o tempo necessário para restaurar o sistema à capacidade total no caso de uma interrupção. É importante testar e praticar o que acontece quando uma região é perdida.

Nota

A expansão de nós é muito mais rápida do que a expansão. 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 sua própria agenda para os backups diários. Recomendamos escolher horários com menos carga. Embora os backups sejam configurados para consumir apenas CPU ociosa, eles podem, em algumas circunstâncias, acionar compactações em Cassandra, o que pode levar a um aumento no uso da CPU. As compactações podem acontecer a qualquer momento com Cassandra, e dependem da carga de trabalho e da estratégia de compactação escolhida.

Importante

A intenção dos backups é puramente mitigar a perda acidental de dados ou corrupção de dados. Não recomendamos backups como estratégia de recuperação de desastres. Os backups não são redundantes geograficamente e, mesmo que fossem, pode levar muito tempo para recuperar um banco de dados a partir de backups. Portanto, recomendamos fortemente implantações em várias regiões, juntamente com a habilitação de zonas de disponibilidade sempre que possível, para mitigar cenários de desastre e poder se recuperar efetivamente deles. Isso é particularmente importante nos raros cenários em que a região com falha não pode ser coberta, onde, sem replicação de várias regiões, todos os dados podem ser perdidos.

Captura de tela da página de configuração de agendamento de backup.

Próximos passos

Neste artigo, apresentamos algumas práticas recomendadas para criar aplicativos resilientes com Cassandra.

Criar um cluster usando o Portal do Azure