Fiabilidade no Azure DocumentDB

O Azure DocumentDB é um serviço de base de dados NoSQL totalmente gerido para desenvolvimento de aplicações modernas com compatibilidade com MongoDB. O Azure DocumentDB suporta uma configuração de alta disponibilidade (HA) com réplicas de reserva ativas replicadas de forma síncrona e redundância entre zonas. Também disponibiliza uma réplica de leitura opcional noutra região do Azure e cópias de segurança automáticas com retenção para um ponto específico no tempo, para proteger contra a perda acidental de dados.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Azure DocumentDB resiliente a vários potenciais cortes e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade, interrupções regionais e manutenção de serviços. Descreve também o comportamento das cópias de segurança e fornece informações-chave sobre HA e replicação entre regiões.

Recomendações de implantação de produção para confiabilidade

Para uma lista de recomendações para melhorar a fiabilidade do seu cluster, consulte Melhores práticas para alta disponibilidade (HA) e replicação entre regiões no Azure DocumentDB.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

O principal recurso que implementas é um cluster do Azure DocumentDB. Para cada cluster, escolhe uma camada de computação e configura o armazenamento. O seu nível selecionado determina as capacidades disponíveis para funcionalidades de fiabilidade, como a alta disponibilidade (HA), e também afeta a forma como planeia a capacidade para cenários de resiliência.

As aplicações ligam-se a um cluster usando cadeias de ligação e endpoints. O Azure DocumentDB fornece pontos finais de ligação para operações de leitura e escrita e, quando configurado, pontos finais para clusters de réplicas de leitura. Estes endpoints permitem que a sua aplicação continue a usar padrões de ligação estáveis enquanto o serviço gere o comportamento de failover nos bastidores.

Dentro de cada cluster, os seus dados estão organizados em bases de dados, coleções e documentos. Este modelo de dados compatível com MongoDB é a base para decisões de design ao nível da carga de trabalho, como estratégia de fragmentação, padrões de leitura e escrita, e âmbito de backup e restauro.

Arquitetura física

O Azure DocumentDB executa o seu cluster em shards, que representam nós (máquinas virtuais) que executam o serviço. Podes implantar um fragmento ou escalar para vários fragmentos. Implantar múltiplos fragmentos melhora a capacidade de escala, mas por si só não fornece HA.

Quando ativa o HA, o Azure DocumentDB aprovisiona um conjunto correspondente de shards em espera. Cada fragmento primário tem um fragmento de reserva. O serviço replica os dados de forma síncrona entre cada par primário-secundário e promove o fragmento secundário se o fragmento primário falhar. Para mais informações sobre o HA, consulte Alta disponibilidade no Azure DocumentDB.

O Azure DocumentDB utiliza o Armazenamento do Azure para a durabilidade dos shards. Se o HA estiver desativado, cada shard utiliza armazenamento localmente redundante (LRS). O LRS mantém três cópias dos dados, mas não é resistente à perda de uma zona de disponibilidade. Para detalhes da durabilidade do LRS, veja Resumo das opções de redundância.

Para mais informações, consulte Disponibilidade e recuperação de desastres (DR) no Azure DocumentDB: Nos bastidores.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

O Azure DocumentDB é compatível com o protocolo MongoDB, pelo que as aplicações normalmente ligam-se usando drivers MongoDB. É responsável por configurar as definições de nova tentativa do driver da sua aplicação para lidar com falhas transitórias, especialmente interrupções na ligação e breves interrupções de escrita durante eventos de comutação pós-falha. Siga estas diretrizes:

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Para utilizar o suporte de zonas de disponibilidade no Azure DocumentDB, ative a alta disponibilidade (HA). Quando ativares a HA numa região que suporta zonas de disponibilidade, o teu cluster torna-se redundante entre zonas, porque o Azure DocumentDB coloca os fragmentos em espera numa zona de disponibilidade diferente da dos respetivos fragmentos primários. Os fragmentos de espera não recebem pedidos de cliente, a menos que o respetivo fragmento principal falhe.

Se desativares o HA, o Azure DocumentDB não coloca shards de espera noutra zona de disponibilidade, por isso uma falha na zona de disponibilidade pode tornar o teu cluster indisponível.

Requirements

• Suporte por região: Para utilizar zonas de disponibilidade com o Azure DocumentDB, escolha uma região que suporte tanto o Azure DocumentDB como zonas de disponibilidade. Verifique os produtos disponíveis por região e compare com regiões que suportam zonas de disponibilidade.

• Alta disponibilidade: Tem de ativar a alta disponibilidade no cluster. O HA exige que o cluster utilize o nível de computação M30 (ou superior).

Considerações

Embora algumas APIs do Azure DocumentDB incluam referências a modos de implementação na mesma zona, o Azure DocumentDB não suporta implementações HA na mesma zona. O serviço suporta implantações de HA redundantes por zona.

Distribuição de instâncias entre zonas

A Microsoft seleciona duas zonas de disponibilidade para o cluster. Em implementações de HA redundantes por zona, o Azure DocumentDB coloca todos os shards primários numa zona e todos os shards de espera na outra zona.

Custo

Quando o HA está ativado, o Azure DocumentDB fornece um shard de reserva para cada shard primário, o que aumenta o custo de computação e armazenamento do seu cluster. Em regiões que suportam zonas de disponibilidade, a HA também torna a zona do cluster redundante. Em alguns modos de implementação, o Azure DocumentDB ativa o HA por defeito. Para cargas de trabalho em produção, mantenha o HA ativado. Para cargas de desenvolvimento e testes, podes desativar o HA para reduzir custos. Para detalhes de preços, consulte preços do Azure DocumentDB.

Configurar o suporte à zona de disponibilidade

• Crie um novo cluster do Azure DocumentDB com redundância entre zonas: Quando criar um cluster numa região que suporta zonas de disponibilidade, ative a HA para tornar o cluster redundante entre zonas. Para passos detalhados, veja Quickstart: Criar um cluster Azure DocumentDB usando o portal Azure.

• Ative a redundância de zonas num cluster Azure DocumentDB existente: Pode ativar o HA num cluster existente. Não há tempo de inatividade na base de dados quando a alta disponibilidade está ativada ou desativada num cluster Azure DocumentDB. Para passos detalhados, consulte Escalar um cluster do Azure DocumentDB.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar ao configurar um cluster do Azure DocumentDB para HA numa região que suporta zonas de disponibilidade, e todas as zonas estão operacionais.

• Operação entre zonas: Os shards primários servem todos os pedidos dos clientes. Os fragmentos em espera numa zona de disponibilidade diferente não recebem pedidos de clientes, a menos que o principal falhe.

• Replicação de dados entre zonas: A replicação entre fragmentos primários e de reserva é síncrona. As escritas são guardadas tanto nos shards primários como nos shards em espera antes de o serviço devolver a resposta.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando configura um cluster do Azure DocumentDB para HA numa região que suporta zonas de disponibilidade, e há uma falha numa das zonas.

• Deteção e resposta: A Microsoft monitoriza o estado de funcionamento do shard e trata, por si, da deteção e das operações de failover. Se um shard primário ficar indisponível devido a uma falha numa zona, o Azure DocumentDB promove automaticamente o shard em espera e, em seguida, recompõe a redundância criando um novo shard em espera.

• Notificação: A Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo sobre problemas.

• Pedidos ativos: Pedidos em voo que não foram reconhecidos antes do failover podem falhar e devem ser tentados novamente pelo cliente. Se a sua aplicação tratar falhas transitórias, estas repetições normalmente são concluídas automaticamente.

• Perda de dados esperada: O Azure DocumentDB replica os dados de forma síncrona entre os shards primário e de espera, pelo que não se espera perda de dados.

• Tempo de inatividade previsto: Não se espera tempo de inatividade para operações de leitura. Para operações de escrita, pode ocorrer uma breve interrupção enquanto o failover termina. Se a sua aplicação repetir corretamente as tentativas em caso de falhas transitórias, isto manifesta-se normalmente como uma breve desaceleração.

• Redistribuição: A cadeia de ligação não muda, por isso os clientes continuam a usar o mesmo endpoint. O serviço redireciona automaticamente o tráfego para shards de espera promovidos e reconstrói novos shards de espera.

Recuperação de zona

Quando a zona de disponibilidade recupera, o Azure DocumentDB restaura automaticamente as operações normais em todas as zonas utilizadas pelo cluster.

Teste de falhas de zona

A plataforma Azure DocumentDB gere o encaminhamento de tráfego, o failover e a recuperação de zonas para clusters redundantes de zona. Não é necessário iniciar ou validar processos de falha da zona de disponibilidade.

Resiliência a falhas em toda a região

Implementas cada cluster do Azure DocumentDB numa única região do Azure. Para suportar a resiliência a falhas de região, configure a replicação entre regiões adicionando um cluster de réplica noutra região.

Replicação entre regiões

O Azure DocumentDB suporta replicação entre regiões através de um cluster réplica. O cluster réplica aparece como um cluster separado no teu grupo de recursos. Pode utilizar este cluster de réplica para recuperação após desastre e escalabilidade de leitura. O Azure DocumentDB replica automaticamente e de forma assíncrona as alterações de dados do cluster principal para o cluster réplica.

Se a sua região principal falhar, o cluster réplica pode ser promovido para se tornar o cluster de leitura-escrita. A cadeia de ligação global de leitura/escrita é atualizada automaticamente para passar a apontar para o cluster promovido.

Esta secção resume as considerações de fiabilidade para a replicação entre regiões. Para mais informações, consulte Gerenciar replicação entre regiões e na mesma região no seu cluster Azure DocumentDB e Melhores práticas de replicação entre região e na mesma região no Azure DocumentDB.

Alternância entre regiões (failover)

O Azure DocumentDB suporta três modos de promoção:

• Promoção forçada: Promove imediatamente o cluster de réplica para aceitar operações de escrita e redireciona o tráfego de escrita de entrada através da cadeia de ligação global de leitura-escrita. Este modo minimiza o tempo de inatividade, mas pode resultar em perda de dados, uma vez que se perdem quaisquer operações de escrita não replicadas.

• Failover gerido por serviços: Pode configurar o seu cluster para usar failover gerido por serviços. A Microsoft monitoriza o seu cluster principal e aciona automaticamente uma promoção forçada se o cluster principal não estiver saudável.

• Promoção controlada: Evita a perda de dados, mas requer algum período de inatividade enquanto as operações de escrita ainda não replicadas são replicadas. A promoção sem interrupção exige que ambos os clusters estejam operacionais, pelo que não a pode efetuar durante uma falha numa região.

Para mais informações, consulte Modos de failover entre regiões no Azure DocumentDB.

Requirements

• Suporte por região: Pode usar replicação entre regiões em todas as regiões do Azure que suportam o Azure DocumentDB.

• Nível de computação: A replicação entre regiões requer o nível de computação M30 ou superior.

Considerações

• Acesso à rede: Clusters réplica não herdam as definições de rede do cluster principal. Configure regras de firewall ou endpoints privados separadamente no cluster réplica e teste a conectividade antes de um failover. Para mais informações, consulte Gravações contínuas, operações de leitura em réplicas do cluster e cadeias de ligação.

• Suporte a funcionalidades: Clusters réplica não suportam restauração pontual no tempo (PITR) nem HA na região.

  Se o HA estiver ativado no cluster principal, és responsável por reativar o HA no cluster promovido.

  Para mais informações, consulte os limites e quotas de serviço do Azure DocumentDB.

Custo

A replicação entre regiões acrescenta custos aos recursos de computação e armazenamento do cluster réplica. Também se aplicam taxas de transferência de dados entre regiões. Para detalhes de preços, consulte preços do Azure DocumentDB e preços de largura de banda.

Configurar suporte multirregional

• Crie um cluster réplica: Para permitir a replicação entre regiões, crie um cluster réplica a partir do seu cluster principal. Podes criar um cluster réplica quando criares o cluster principal ou depois. Para os passos, consulte Gerir replicação entre regiões e na mesma região no seu cluster do Azure DocumentDB.

• Configure o failover automático: Se quiser que o Azure promova automaticamente a réplica durante as interrupções da região principal, ative o failover gerido por serviços. Para mais informações, consulte Ativar failover gerido por serviços.

  Observação

  A Microsoft normalmente ativa o failover gerido por serviços apenas em eventos extremos, como uma interrupção de toda a região ou um grande número de clientes afetados. Pode haver um atraso antes de o failover ser ativado. Se precisar de restaurar a disponibilidade rapidamente, recomendamos que gere o processo de failover usando uma promoção forçada iniciada pelo cliente.

Comportamento quando todas as regiões estão saudáveis

Esta secção descreve o que esperar quando configura um cluster do Azure DocumentDB para replicação entre regiões e todas as regiões estão operacionais.

• Operação entre regiões: O cluster principal serve todo o tráfego de leitura e escrita. O cluster de réplica processa tráfego apenas de leitura, que pode utilizar para expandir as cargas de trabalho de leitura ou para manter o tráfego de leitura localizado numa região específica. A cadeia de ligação global de leitura e escrita aponta sempre para o cluster atualmente gravável, pelo que os clientes não precisam de saber qual é a região primária.

• Replicação de dados entre regiões: A replicação entre o cluster primário e o cluster réplica é assíncrona. As escritas são confirmadas no cluster primário e reconhecidas ao cliente antes de serem replicadas para o cluster réplica. Esta abordagem impede que a latência de rede entre regiões afete o desempenho de escrita. Como a replicação é assíncrona, espera-se algum atraso de replicação entre os clusters primário e réplica, e quaisquer escritas não replicadas podem ser perdidas durante um failover forçado.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando configura um cluster do Azure DocumentDB para replicação entre regiões e há uma falha na região do cluster principal.

• Deteção e resposta: A responsabilidade pela deteção da falha e resposta depende do tipo de failover que o seu cluster utiliza.

  • Se o failover gerido por serviços estiver ativado, o Azure DocumentDB deteta a falha e executa automaticamente uma promoção forçada do cluster réplica.
  • Se o failover gerido por serviços não estiver ativado, és responsável por detetar a falha e desencadear uma promoção forçada.

  Para mais informações, consulte Modos de failover entre regiões no Azure DocumentDB.

• Notification: A Microsoft não o notifica automaticamente quando uma região está inoperante. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

• Pedidos ativos: Quaisquer pedidos ativos para a região primária falhada podem falhar. Após a conclusão do failover, as aplicações devem restabelecer a ligação e repetir as tentativas no cluster promovido.

• Perda de dados esperada: Os failovers durante falhas de região são não planeados, pelo que as escritas não replicadas podem ser perdidas porque a replicação é assíncrona.

• Tempo de inatividade esperado: O tempo de inatividade global depende do tempo de deteção, do modo de failover e do comportamento de reconexão do cliente.

  Para a promoção forçada iniciada pelo cliente, o tempo total de inatividade inclui o tempo necessário para detetar a falha e iniciar os seus processos de resposta, bem como o tempo para concluir a promoção.

  Uma vez iniciada uma promoção, normalmente conclui-se em poucos minutos.

• Redirecionamento: A cadeia de ligação global de leitura e escrita aponta automaticamente para o cluster promovido após a promoção. Aplicações que utilizam cadeias de ligação específicas do cluster podem necessitar de atualizações de configuração para direcionarem o tráfego para o cluster saudável.

Recuperação da região

O Azure DocumentDB não retorna automaticamente à região original depois de recuperar. Para devolver as operações de escrita à região original, efetue outra promoção após restabelecer a sua topologia preferida. Utilize uma promoção controlada para evitar a perda de dados durante o retorno ao sistema primário. Uma transição sem problemas requer um curto período de inatividade, e pode efetuá-la na altura que escolher, por exemplo durante uma janela de manutenção. Para mais informações, consulte Iniciar uma promoção controlada.

Teste para falhas regionais

Teste regularmente o seu processo de recuperação de desastres promovendo o cluster de réplicas num ambiente controlado.

• Utilize promoção forçada para simular o comportamento de indisponibilidade. Este teste pode resultar em perda de dados, por isso considere executá-lo num ambiente sem produção. Para mais informações, consulte Desencadear uma promoção forçada.

• Utilize a promoção graciosa para simulações planeadas de comutação, se pretender evitar a perda de dados. Para mais informações, consulte Iniciar uma promoção controlada.

Backup e restauração

A replicação e o suporte para zonas de disponibilidade ajudam a manter um cluster disponível durante falhas de infraestrutura. O Azure DocumentDB aceita automaticamente backups contínuos, que abordam um risco diferente ao permitir a recuperação pontual no tempo (PITR) após apagar ou modificar acidentalmente os dados. O Azure DocumentDB faz cópias de segurança sem afetar o desempenho ou a disponibilidade das operações da base de dados. Para mais informações sobre como a replicação e o backup abordam diferentes riscos, consulte redundância, replicação e backup.

O Azure DocumentDB armazena backups separadamente dos dados de origem. Nas regiões que suportam zonas de disponibilidade, o serviço armazena instantâneos de backup em três zonas de disponibilidade. O Azure DocumentDB gere estas cópias de segurança, e não podes exportá-las. O serviço mantém cópias de segurança durante 35 dias para clusters ativos, 7 dias para clusters ativos burstable-tier (M10, M20, M25) e 7 dias para clusters eliminados.

Podes restaurar um backup para um novo cluster. Depois de o ter feito, tem de realizar um conjunto de tarefas pós-restauração.

Para mais informações, consulte Restaurar um cluster no Azure DocumentDB.

Resiliência à manutenção de serviços

A Microsoft aplica regularmente atualizações de serviço e realiza outras manutenções. A plataforma Azure gere estas atividades automaticamente, garantindo que a manutenção é fluida e transparente para si. Não é esperado qualquer tempo de indisponibilidade durante os eventos de manutenção, a menos que tenha sido informado através da manutenção planeada do Azure Service Health.

Eventos de manutenção planeada ainda podem causar falhas breves e transitórias nas operações do cliente. A sua aplicação deve processar estes eventos utilizando as orientações sobre repetição em Resiliência a falhas transitórias.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para mais informações, consulte Acordos de Nível de Serviço (SLA) para serviços online.

Para o Azure DocumentDB, os SLAs de disponibilidade aplicam-se apenas quando o seu cluster tem alta disponibilidade (HA) ativada. Diferentes SLAs de disponibilidade aplicam-se às seguintes configurações:

• Clusters habilitados por HA que abrangem múltiplas regiões do Azure usando replicação entre regiões.

• Clusters habilitados para HA numa única região.

Conteúdo relacionado

• Compatibilidade de funcionalidades com o MongoDB
• Migrar de MongoDB para Azure DocumentDB
• Criar um cluster do Azure DocumentDB
• Fiabilidade em Azure