Confiabilidade no Azure DocumentDB

Azure DocumentDB é um serviço de banco de dados de NoSQL totalmente gerenciado para desenvolvimento de aplicativos modernos com compatibilidade do MongoDB. O Azure DocumentDB oferece suporte a uma configuração de alta disponibilidade (HA) com réplicas em espera ativa replicadas sincronamente e redundância de zona. Ele também fornece uma réplica de leitura opcional em outra região Azure e backups automáticos com retenção pontual para proteger contra perda acidental de dados.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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 Azure DocumentDB resiliente a várias possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções na região e manutenção do serviço. Ele também descreve o comportamento do backup e fornece informações importantes sobre HA e replicação entre regiões.

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

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

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

O recurso primário que você implanta é um cluster do DocumentDB Azure. Para cada cluster, você escolhe uma camada de computação e configura o armazenamento. Sua camada selecionada determina os recursos disponíveis para recursos de confiabilidade, como alta disponibilidade (HA), e também afeta como você planeja a capacidade para cenários de resiliência.

Os aplicativos se conectam a um cluster usando cadeias de conexão e pontos de extremidade. O Azure DocumentDB fornece endpoints de conexão para operações de leitura e gravação e, quando configurado, endpoints para clusters de réplicas de leitura. Esses endpoints permitem que seu aplicativo continue usando padrões de conexão estáveis enquanto o serviço gerencia o comportamento de failover em segundo plano.

Em cada cluster, seus dados são organizados como bancos de dados, coleções e documentos. Esse modelo de dados compatível com o MongoDB é a base para decisões de design no nível da carga de trabalho, como estratégia de fragmentação, padrões de leitura e gravação e escopo de backup e restauração.

Arquitetura física

O Azure DocumentDB executa o cluster em partições, que representam nós (máquinas virtuais) que executam o serviço. Você pode implantar um shard ou expandir para vários shards. A implantação de vários fragmentos melhora a capacidade de escala, mas por si só não fornece HA.

Quando você habilita a HA, Azure DocumentDB provisiona um conjunto correspondente de fragmentos em espera. Cada fragmento primário tem um fragmento em espera. O serviço replica dados de forma síncrona entre cada par de espera primário e promove o fragmento em espera se o fragmento primário falhar. Para obter mais informações sobre HA, consulte Alta disponibilidade no Azure DocumentDB.

O Azure DocumentDB usa o Armazenamento do Azure para garantir a durabilidade dos fragmentos. Se a HA estiver desabilitada, cada fragmento usará O LRS (armazenamento com redundância local). O LRS mantém três cópias dos dados, mas não é resiliente à perda de uma zona de disponibilidade. Para obter detalhes de durabilidade do LRS, consulte Resumo das opções de redundância.

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

Resiliência a falhas transitórias

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

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

Azure DocumentDB é compatível com o protocolo MongoDB, portanto, os aplicativos normalmente se conectam usando drivers MongoDB. Você é responsável por configurar as definições de nova tentativa do driver da sua aplicação para lidar com falhas transitórias, principalmente interrupções de conexão e interrupções breves de gravação durante eventos de failover. Siga estas diretrizes:

  • Use drivers do MongoDB que ofereçam suporte a novas tentativas automáticas em caso de falhas transitórias de conectividade.

  • Configure novas tentativas com retirada exponencial e limite o número de repetições.

  • Quando possível, projete as operações de gravação para serem idempotentes, de modo que seja seguro repeti-las. Para obter orientações gerais de implementação sobre idempotência, consulte o padrão Consumidor Idempotente.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Para usar o suporte à zona de disponibilidade no Azure DocumentDB, habilite a HA (alta disponibilidade). Quando você habilita a HA em uma região que dá suporte a zonas de disponibilidade, o cluster se torna com redundância de zona porque Azure DocumentDB coloca os fragmentos em espera em uma zona de disponibilidade diferente de seus fragmentos primários. Os fragmentos em espera não recebem solicitações de cliente, a menos que o fragmento primário falhe.

Se você desabilitar a HA, Azure DocumentDB não colocará fragmentos em espera em outra zona de disponibilidade, portanto, uma falha na zona de disponibilidade pode tornar o cluster indisponível.

Diagrama de um cluster do Azure DocumentDB com redundância de zona, com shards primários e de standby em zonas de disponibilidade separadas.

Requirements

Considerations

Embora algumas APIs do DocumentDB Azure incluam referências a modos de implantação da mesma zona, Azure DocumentDB não dá suporte a implantações de HA da mesma zona. O serviço dá suporte a implantações de HA com redundância de zona.

Distribuição de instâncias entre zonas

Microsoft seleciona duas zonas de disponibilidade para o cluster. Em implantações de HA com redundância de zona, Azure DocumentDB coloca todos os fragmentos primários em uma zona e todos os fragmentos em espera na outra zona.

Custo

Quando a HA está habilitada, Azure DocumentDB provisiona um fragmento em espera para cada fragmento primário, o que aumenta o custo de computação e armazenamento do cluster. Em regiões que oferecem suporte a zonas de disponibilidade, a alta disponibilidade (HA) também faz com que o cluster tenha redundância entre zonas. Em alguns modos de implantação, Azure DocumentDB habilita a HA por padrão. Para cargas de trabalho de produção, mantenha a HA habilitada. Para cargas de trabalho de desenvolvimento e teste, você pode desativar a HA para reduzir custos. Para obter 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 de zona: Ao criar um cluster em uma região que oferece suporte a zonas de disponibilidade, habilite a alta disponibilidade para tornar o cluster redundante entre zonas. Para obter etapas detalhadas, consulte Início Rápido: Criar um cluster Azure DocumentDB usando o portal Azure.

  • Habilitar a redundância de zona em um cluster do DocumentDB Azure existente: você pode habilitar a HA em um cluster existente. Não há tempo de inatividade do banco de dados quando a alta disponibilidade está habilitada ou desabilitada em um cluster do Azure DocumentDB. Para obter etapas detalhadas, consulte Dimensionar um cluster do DocumentDB Azure.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando você configura um cluster Azure DocumentDB para HA em uma região que dá suporte a zonas de disponibilidade e todas as zonas estão operacionais.

  • Operação entre zonas: Os fragmentos primários atendem a todas as solicitações do cliente. Fragmentos em espera em uma zona de disponibilidade diferente não recebem solicitações de cliente, a menos que o primário falhe.

  • Replicação de dados entre zonas: A replicação entre fragmentos primários e em espera é síncrona. As gravações são mantidas em fragmentos primários e em espera antes que o serviço retorne uma resposta.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando você configura um cluster Azure DocumentDB para HA em uma região que dá suporte a zonas de disponibilidade e há uma interrupção em uma das zonas.

  • Detecção e resposta: A Microsoft monitora a integridade do shard e gerencia as operações de detecção e failover por você. Se um fragmento primário ficar indisponível devido a uma interrupção de zona, Azure DocumentDB promoverá automaticamente o fragmento em espera e, em seguida, recriará a redundância criando um novo fragmento em espera.

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

  • Requisições ativas: Requisições em andamento que não foram confirmadas antes do failover podem falhar e devem ser reenviadas pelo cliente. Se o aplicativo lidar com falhas transitórias, essas novas tentativas normalmente serão concluídas automaticamente.

  • Perda de dados esperada: Azure DocumentDB replica dados de forma síncrona entre os fragmentos primário e em espera, portanto, nenhuma perda de dados é esperada.

  • Tempo de inatividade esperado: Nenhum tempo de inatividade é esperado para operações de leitura. Para operações de gravação, uma breve interrupção pode ocorrer durante a conclusão do failover. Se o aplicativo tentar novamente falhas transitórias corretamente, isso geralmente aparecerá como uma pequena desaceleração.

  • Redistribuição: O cadeia de conexão não é alterado, portanto, os clientes continuam usando o mesmo ponto de extremidade. O serviço redireciona automaticamente o tráfego para fragmentos em espera promovidos e recria novos fragmentos em espera.

Recuperação de zona

Quando a zona de disponibilidade é recuperada, Azure DocumentDB restaura automaticamente as operações normais em todas as zonas usadas pelo cluster.

Testar falhas em zonas

A plataforma Azure DocumentDB gerencia o roteamento de tráfego, o failover e a recuperação de zona para clusters com redundância de zona. Você não precisa iniciar nem validar processos de falha de zona de disponibilidade.

Resiliência a falhas em toda a região

Você implanta cada cluster do Azure DocumentDB em uma única região do Azure. Para dar suporte à resiliência a falhas de região, configure a replicação entre regiões adicionando um cluster de réplica em outra região.

Replicação entre regiões

Azure DocumentDB dá suporte à replicação entre regiões por meio de um cluster de réplica. O cluster de réplica aparece como um cluster separado em seu grupo de recursos. Você pode usar este cluster de réplica para recuperação de desastres e escalabilidade de leitura. Azure DocumentDB replica automaticamente e de forma assíncrona as alterações de dados do cluster primário para o cluster de réplica.

Diagrama de replicação assíncrona de um cluster primário do Azure DocumentDB para um cluster de réplica de leitura em outra região.

Se a região primária falhar, o cluster de réplica poderá ser promovido a cluster de leitura e gravação. A string de conexão global de leitura/gravação é atualizada automaticamente para apontar para o cluster promovido.

Diagrama de uma réplica Azure DocumentDB promovida que atende ao tráfego após a falha da região primária.

Esta seção resume as considerações de confiabilidade para replicação entre regiões. Para obter mais informações, consulte Gerenciar a replicação entre regiões e a mesma região em seu cluster Azure DocumentDB e práticas recomendadas de replicação entre regiões e da mesma região em Azure DocumentDB.

Failover entre regiões

Azure DocumentDB dá suporte a três modos de promoção:

  • Promoção forçada: Promove imediatamente o cluster de réplica para aceitar operações de gravação e redireciona o tráfego de gravação recebido usando a cadeia de conexão global de leitura/gravação. Esse modo minimiza o tempo de inatividade, mas pode resultar em perda de dados porque perde gravações não duplicadas.

  • Failover gerenciado pelo serviço: Você pode configurar o cluster para usar o failover gerenciado pelo serviço. A Microsoft monitora o cluster primário e aciona automaticamente uma promoção forçada se o cluster primário não estiver saudável.

  • Promoção graciosa: Impede a perda de dados, mas requer algum tempo de inatividade enquanto gravações não replicadas são replicadas. A promoção normal exige que os dois clusters sejam íntegros; portanto, você não pode executá-lo durante uma interrupção de região.

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

Requirements

  • Suporte à região: Você pode usar a replicação entre regiões em todas as regiões de Azure que dão suporte a Azure DocumentDB.

  • Camada de computação: A replicação entre regiões requer a camada de computação M30 ou superior.

Considerations

  • Acesso à rede: Os clusters de réplica não herdam as configurações de rede do cluster primário. Configure separadamente as regras de firewall ou os pontos de extremidade privados no cluster de réplica e teste a conectividade antes de realizar um failover. Para obter mais informações, consulte Gravações contínuas, operações de leitura em réplicas de cluster e cadeias de conexão.

  • Suporte a recursos: Os clusters de réplica não dão suporte à PITR (restauração pontual) ou à HA na região.

    Se a HA estiver habilitada no cluster primário, você será responsável por reabilitar a HA no cluster promovido.

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

Custo

A replicação entre regiões adiciona custos para os recursos de computação e armazenamento do cluster de réplica. Os encargos de transferência de dados entre regiões também se aplicam. Para obter detalhes sobre preços, consulte preços do Azure DocumentDB e preços da largura de banda.

Configurar o suporte a várias regiões

  • Criar um cluster de réplica: Para habilitar a replicação entre regiões, crie um cluster de réplica do cluster primário. Você pode criar um cluster de réplica ao criar o cluster primário ou posterior. Para ver as etapas, consulte Gerenciar a replicação entre regiões e na mesma região no seu cluster do Azure DocumentDB.

  • Configurar o failover automático: Se você quiser que Azure promova automaticamente a réplica durante interrupções da região primária, habilite o failover gerenciado pelo serviço. Para obter mais informações, consulte Habilitar failover gerenciado pelo serviço.

    Note

    A Microsoft normalmente aciona o failover gerenciado pelo serviço somente em eventos extremos, como a indisponibilidade de uma região inteira ou um grande número de clientes afetados. Pode haver um atraso antes que o failover seja acionado. Se você precisar restaurar a disponibilidade rapidamente, recomendamos que você gerencie o processo de failover usando a promoção forçada iniciada pelo cliente.

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

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

  • Operação entre regiões: O cluster primário atende a todo o tráfego de leitura/gravação. O cluster de réplicas atende ao tráfego de somente leitura, e você pode usá-lo para escalar horizontalmente as cargas de trabalho de leitura ou para manter o tráfego de leitura localizado em uma região específica. A string de conexão global de leitura/gravação sempre aponta para o cluster gravável atual, portanto os clientes não precisam acompanhar qual região é a primária.

  • Replicação de dados entre regiões: A replicação entre o cluster primário e o cluster de réplica é assíncrona. As operações de gravação são efetivadas no cluster primário, e o cliente recebe a confirmação antes que elas sejam replicadas para o cluster de réplica. Essa abordagem impede que a latência de rede entre regiões afete o desempenho de gravação. Como a replicação é assíncrona, é esperado algum atraso de replicação entre os clusters primário e de réplica e as gravações não duplicadas podem ser perdidas durante um failover forçado.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando você configura um cluster Azure DocumentDB para replicação entre regiões e há uma interrupção na região do cluster primário.

  • Detecção e resposta: A responsabilidade de detectar a interrupção e responder depende do tipo de failover usado pelo cluster.

    • Se o failover gerenciado pelo serviço estiver habilitado, o Azure DocumentDB detectará a indisponibilidade e realizará automaticamente uma promoção forçada do cluster de réplicas.
    • Se o failover gerenciado pelo serviço não estiver habilitado, você será responsável por detectar a indisponibilidade e acionar uma promoção forçada.

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

  • Notificação: A Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas na região, e pode configurar alertas Service Health para notificar você sobre problemas.

  • Solicitações ativas: Qualquer solicitação ativa para a região primária com falha pode falhar. Após a conclusão do failover, os aplicativos devem se reconectar e repetir a tentativa no cluster promovido.

  • Perda de dados esperada: Os failovers durante falhas de região não são planejados; portanto, as gravações não duplicadas podem ser perdidas porque a replicação é assíncrona.

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

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

    Depois que uma promoção é iniciada, ela normalmente é concluída em poucos minutos.

  • Redistribuição: A cadeia de conexão global de leitura e gravação aponta automaticamente para o cluster promovido após ser promovido. Os aplicativos que usam strings de conexão específicas do cluster podem exigir atualizações de configuração para direcionar o tráfego para o cluster saudável.

Recuperação de região

O Azure DocumentDB não faz failback automático para a região original após a recuperação. Para retornar as operações de gravação para a região original, execute outra promoção depois de restabelecer sua topologia preferida. Use uma promoção normal para evitar a perda de dados durante o failback. Uma promoção normal exige uma pequena quantidade de tempo de inatividade e você pode executá-la quando preferir; por exemplo, durante uma janela de manutenção. Para saber mais, confira Disparar uma promoção normal.

Teste de falhas na região

Teste o processo de recuperação de desastre regularmente promovendo o cluster de réplica em um ambiente controlado.

  • Use promoção forçada para simular o comportamento de interrupção. Esse teste pode resultar em perda de dados, portanto, considere executar esse teste em um ambiente de não produção. Para obter mais informações, consulte Acionar uma promoção forçada.

  • Use promoção normal para análises de substituição planejadas quando desejar evitar a perda de dados. Para saber mais, confira Disparar uma promoção normal.

Backup e restauração

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

Azure DocumentDB realiza automaticamente backups contínuos que permitem a PITR (recuperação pontual). Esses backups automáticos ajudam você a recuperar versões originais depois de excluir ou modificar dados acidentalmente. Azure DocumentDB faz backups sem afetar o desempenho ou a disponibilidade das operações de banco de dados.

Azure DocumentDB armazena backups separadamente dos dados de origem. Em regiões que dão suporte a zonas de disponibilidade, o serviço armazena instantâneos de backup em três zonas de disponibilidade. Azure DocumentDB gerencia esses backups e você não pode exportá-los. O serviço retém backups por 35 dias para clusters ativos, por 7 dias para clusters ativos da camada burstable (M10, M20, M25) e por 7 dias para clusters excluídos.

Você pode restaurar um backup para um novo cluster. Depois de fazer isso, você precisa executar um conjunto de tarefas pós-restauração.

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

Resiliência à manutenção do serviço

A Microsoft aplica regularmente as atualizações de serviço e executa outras manutenções. A plataforma Azure manipula essas atividades automaticamente, garantindo que a manutenção seja perfeita e transparente para você. Não se espera tempo de inatividade durante eventos de manutenção, a menos que você tenha sido avisado por meio de manutenção planejada do Integridade do Serviço do Azure.

Eventos de manutenção planejados ainda podem causar falhas breves e transitórias nas operações do cliente. Seu aplicativo deve lidar com esses eventos usando as diretrizes de repetição em Resiliência para falhas transitórias.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de 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 obter mais informações, consulte SLAs para serviços online.

Para Azure DocumentDB, os SLAs de disponibilidade se aplicam somente quando o cluster tem alta disponibilidade (HA) habilitada. SLAs de disponibilidade diferentes se aplicam às seguintes configurações:

  • Clusters habilitados para HA que abrangem várias regiões de Azure usando a replicação entre regiões.

  • Clusters habilitados para HA em uma única região.

Conteúdo relacionado

  • Last updated on