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

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 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 peer-to-peer. Qualquer nó no banco de dados pode fornecer a mesma funcionalidade que qualquer outro nó. Este design contribui para a robustez e resiliência da Cassandra. Este artigo fornece dicas sobre como otimizar a alta disponibilidade e como abordar a recuperação de desastres.

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

Contanto que você tenha os seguintes elementos, o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) geralmente são baixos, próximos de zero:

• Uma implantação em várias regiões com replicação entre regiões e um fator de replicação de 3.
• Zonas de disponibilidade ativadas. Configure essa opção ao criar um cluster no portal do Azure ou usando a CLI do Azure.
• Configurado o failover ao nível da aplicação usando a política de balanceamento de carga no driver do cliente ou o failover ao nível do balanceamento de carga usando o Azure Traffic Manager ou o Azure Front Door.

RTO é quanto tempo o sistema está inativo durante uma falha. É baixo porque o cluster é resiliente em ambas as zonas e regiões. Além disso, o Apache Cassandra em si é um sistema peer-to-peer altamente tolerante a falhas, onde todos os nós podem escrever 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 centros de dados. A perda de dados em uma interrupção seria mínima.

Zonas de disponibilidade

A arquitetura peer-to-peer de Cassandra traz tolerância a falhas desde o início. A Instância Gerenciada do Azure para Apache Cassandra fornece suporte para zonas de disponibilidade em regiões selecionadas. Este apoio aumenta a resiliência ao 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 evita que uma interrupção zonal afete seu banco de dados ou aplicativo. Recomendamos ativar as zonas de disponibilidade sempre que possível.

Redundância multirregião

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 se 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 da sua aplicação também precisam ser distribuídas ou disponibilizadas com mecanismos adequados para permitir a continuidade do serviço em caso de falha (failover). Se seus usuários estiverem espalhados por vários locais geográficos, uma implantação de data center em várias regiões para seu banco de dados tem o benefício adicional de reduzir a latência. Todos os nós em todos os centros de dados no cluster podem atender tanto a leituras como a gravações da região que lhes é mais próxima.

Se o aplicativo estiver configurado para ser ativo-ativo, considere como o Teorema do CAP se aplica à consistência dos seus dados entre réplicas (nós) e as compensações necessárias para assegurar alta disponibilidade.

Em termos do teorema CAP, Cassandra é por padrão um sistema de banco de dados tolerante a partições (AP) disponível, com consistência altamente ajustável. Para a maioria dos casos de uso, recomendamos usar LOCAL_QUORUM para leitura.

• No ativo-passivo para gravações, há um trade-off entre confiabilidade e desempenho. Para garantir confiabilidade, recomendamos o QUORUM_EACH, mas para a maioria dos utilizadores, o LOCAL_QUORUM ou QUORUM é um bom compromisso. Se houver uma interrupção regional, algumas gravações podem ser perdidas em LOCAL_QUORUM.

• Se uma aplicação for executada em paralelo, prefira gravações QUORUM_EACH na maioria dos casos para garantir a consistência entre os dois centros de dados.

• Se seu objetivo é favorecer a consistência, ou RPO mais baixo, em vez de latência ou disponibilidade, ou RTO mais baixo, suas configurações de consistência e fator de replicação devem refletir esse objetivo.

  Em geral, o número de nós de quorum necessário 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.

Replicação

Recomendamos auditar keyspaces e as suas configurações de replicação periodicamente para garantir que a replicação necessária entre data centers esteja configurada. Nos estágios iniciais de desenvolvimento, recomendamos que faças 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ê configura um segundo data center onde um data center existente já tem dados, determine se 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, esta abordagem pode fornecer apenas 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. 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 garante que não haja degradação do desempenho. 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, portanto, o failover deve acontecer no nível do balanceador de carga.

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, o dimensionamento vertical e horizontal pronto para uso facilita a ampliação na Instância Gerenciada do Azure para Apache Cassandra. 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. Seu data center secundário atua como um modo de espera quente de baixo custo. Adotar essa abordagem precisa ser balanceado em relação ao tempo necessário para restaurar o sistema à capacidade total se ocorrer uma interrupção. É importante testar e praticar o que acontece quando uma região é perdida.

Agendamentos de backup

Os backups são automáticos na Instância Gerenciada do Azure para Apache Cassandra. Você pode escolher sua própria programação 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. Dependem da carga de trabalho e da estratégia de compactação escolhida.

Próximo passo