Reliability in Azure Cosmos DB

Azure Cosmos DB para NoSQL é um serviço de base de dados distribuído globalmente e multi-modelo que suporta modelos de dados documentais com esquemas flexíveis. O Azure Cosmos DB oferece funcionalidades abrangentes de fiabilidade, incluindo múltiplos níveis de consistência que permitem equilibrar desempenho e disponibilidade, implementações redundantes por zona que protegem contra falhas em zonas de disponibilidade, replicação multi-região com failover gerido por serviços ou pelo cliente, e opções de backup contínuo e periódico para proteção 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 Cosmos DB resiliente a vários potenciais cortes e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade, interrupções regionais e manutenção de serviços. Descreve também como utilizar backups para recuperar de outros tipos de problemas e destaca informações chave sobre o acordo de nível de serviço (SLA) do Azure Cosmos DB.

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

O Azure Well-Architected Framework fornece recomendações sobre fiabilidade, segurança, custo, operações e desempenho. Para compreender como estas áreas se influenciam mutuamente e contribuem para uma solução Azure Cosmos DB fiável, consulte as melhores práticas Architecture para Azure Cosmos DB.

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 Azure Cosmos DB account. Cada conta pode ter múltiplas bases de dados com vários contentores. Os contentores servem como unidades lógicas de distribuição e escalabilidade. Pode criar contentores como coleções, tabelas e grafos, dependendo da API que usa para interagir com o Azure Cosmos DB. Para mais informações sobre o modelo de recursos, consulte Bases de dados, contentores e itens em Azure Cosmos DB. Cada contentor utiliza particionamento, que suporta grande escala e alto desempenho.

Configuras o throughput, que representa a quantidade de recursos do sistema que podes usar para consultar e trabalhar com os teus dados. Pode provisionar manualmente o throughput, usar autoescala para dinamicamente ajustar a capacidade com base nos requisitos da sua carga de trabalho, ou usar o tipo de conta sem servidor para ser cobrado pelo seu uso real.

Uma única conta pode abranger várias regiões Azure, o que aumenta a tua resiliência a falhas de regiões. Podes configurar várias regiões para leitura e, se usares o nível Business Critical, podes usar várias regiões para escrever. O Azure Cosmos DB geo-replica automaticamente os seus dados. O comportamento da geo-replicação é afetado pela configuração que utiliza, como o nível de consistência, que indica como pretende fazer compromissos entre consistência, disponibilidade, latência e rendimento dos dados. Diferentes níveis de consistência otimizam para diferentes preocupações, suportam diferentes garantias e fornecem diferentes tipos de replicação entre regiões.

Arquitetura física

Azure Cosmos DB armazena múltiplas réplicas dos seus dados para redundância. O serviço mitiga automaticamente as falhas de réplicas ao manter o quórum entre réplicas em cada região. Esta abordagem garante alta disponibilidade e protege contra a perda de dados durante falhas individuais de nós, sem necessidade de alterações ou configuração da aplicação.

Internamente, o Azure Cosmos DB gere os seus dados através de vários construtos, incluindo partições físicas, conjuntos de partições e conjuntos de réplicas. Para informações mais detalhadas sobre como Azure Cosmos DB funciona, veja Distribuição global de dados com Azure Cosmos DB - under the hood.

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.

Recomendamos que utilize os SDKs do Azure Cosmos DB. Os SDKs implementam automaticamente suporte para uma série de considerações de resiliência, incluindo o tratamento de falhas transitórias através de tentativas automáticas e o cumprimento das respostas de limites de taxa enviadas pelo serviço. Para obter mais informações, consulte Conceba aplicações resilientes com os SDKs do Azure Cosmos DB.

Ao trabalhar com uma conta multirregional, o SDK também suporta uma estratégia de disponibilidade baseada em limiares, também chamada hedging, onde envia pedidos de leitura paralelos para múltiplas regiões e aceita a resposta mais rápida. Esta abordagem pode melhorar o desempenho da aplicação quando uma região sofre temporariamente uma latência superior ao habitual.

Resiliência a falhas na zona de disponibilidade

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.

O Azure Cosmos DB dá suporte à redundância de zona. Quando você habilita a redundância de zona, o Azure distribui as réplicas de seus dados em várias zonas de disponibilidade, fornecendo resiliência a problemas e interrupções do datacenter. A Microsoft seleciona as zonas de disponibilidade a utilizar.

Uma conta Azure Cosmos DB pode usar múltiplas regiões (localizações) para distribuição global, escala e failover. Configura a redundância de zonas separadamente para cada região na sua conta.

Usar redundância de zonas no Azure Cosmos DB não tem impacto discernível no desempenho ou na latência. Não requer quaisquer ajustes no modo de consistência selecionado, nem qualquer modificação no código da aplicação.

Recomendamos o uso de redundância de zona em regiões onde ela é suportada, especialmente para contas de uma única região. Como as zonas de disponibilidade são fisicamente separadas e fornecem fonte de alimentação, rede e resfriamento distintos, os SLAs de disponibilidade do Azure Cosmos DB são maiores para contas com redundância de zona do que contas que não usam zonas de disponibilidade.

Se não ativares a redundância de zonas, a conta é não zonal nessa região. Contas não zonais podem localizar réplicas numa única zona de disponibilidade, levando a potenciais indisponibilidades se essa zona específica apresentar um problema.

Requirements

• Region support: Pode ativar a redundância de zonas nas regiões do Azure que suportam zonas de disponibilidade. Para ver se a sua região suporta zonas de disponibilidade, consulte a lista de regiões suportadas.

  A redundância de zona não é uma configuração ao nível de conta. As contas Azure Cosmos DB podem abranger várias regiões, e cada região pode ser configurada independentemente para usar zonas de disponibilidade. As regiões que não suportam zonas de disponibilidade não impedem de ativar redundância de zonas noutras regiões dentro da mesma conta.

• Contas sem servidor: Pode configurar contas sem servidor redundantes por zona apenas no momento da sua criação. Não podes converter contas serverless existentes sem zonas de disponibilidade para uma configuração de zona de disponibilidade. Para workloads de missão crítica, recomendamos que utilize throughput provisionado.

Considerações

• Múltiplas interrupções simultâneas em zonas: Uma conta numa única região com redundância de zonas pode manter a disponibilidade de leitura e escrita se uma interrupção afetar uma única zona de disponibilidade. No entanto, se a interrupção afetar múltiplas zonas de disponibilidade ou toda a região, as contas de uma única região perdem o acesso de leitura e escrita até que o serviço seja restaurado. Considere implementar uma conta multi-região se precisar de ser resiliente a falhas em várias zonas ao mesmo tempo.

• Contas multi-regionais: Se tiver uma conta multi-região, pode opcionalmente ativar a redundância de zonas em qualquer uma ou todas as regiões da conta que suportam zonas de disponibilidade. Recomendamos vivamente ativar a redundância de zonas quando a sua conta estiver configurada para usar uma única região, ou se estiver configurada para usar uma única região de escrita com múltiplas regiões de leitura.

Custo

As regiões onde a redundância de zonas está ativada são cobradas a um preço premium. No entanto, o preço premium para zonas de disponibilidade é dispensado para contas configuradas com escritas multi-região e para coleções configuradas para usar o modo de escalonamento automático de throughput. Para obter mais informações, consulte Preços do Azure Cosmos DB.

Configurar o suporte à zona de disponibilidade

Para a maioria das contas, só se ativa a redundância de zonas quando se adiciona uma nova região a uma conta do Azure Cosmos DB. Para permitir o suporte de zonas de disponibilidade numa conta existente, adicione uma região e ative a redundância de zona. Pode seguir um processo para adicionar uma região temporária e assim configurar a redundância de zonas na sua região original. Para passos detalhados, veja Ativar redundância de zonas numa conta Azure Cosmos DB.

Para contas serverless, tens de ativar a redundância de zonas ao criar a conta.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar ao configurar uma conta Azure Cosmos DB para redundância de zonas, e todas as zonas estão operacionais.

• Cross-zone operation: Azure Cosmos DB encaminha automaticamente pedidos para réplicas entre zonas de disponibilidade, para que qualquer réplica possa servir uma solicitação.

• Replicação de dados entre zonas: Quando um cliente faz uma alteração a qualquer dado, essa alteração é aplicada a múltiplas réplicas em diferentes zonas para alcançar quórum. Esta abordagem é designada por replicação síncrona. A replicação síncrona assegura um elevado nível de consistência dos dados, o que reduz a probabilidade de perda de dados durante uma falha de zona. As zonas de disponibilidade estão localizadas relativamente próximas umas das outras, o que significa que há um efeito mínimo na latência de rede ou na largura de banda.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando configura uma conta Azure Cosmos DB para redundância de zonas, e há uma falha numa das zonas.

• Deteção e resposta: A plataforma Azure Cosmos DB é responsável por detetar uma falha numa zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.

• Notificação: A Microsoft não te informa automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.

• Solicitações Ativas: Quando uma zona de disponibilidade se torna indisponível, Azure Cosmos DB termina quaisquer pedidos em curso ligados a réplicas na zona afetada, e a aplicação deve tentar novamente esses pedidos. Certifique-se de que a sua candidatura está preparada, seguindo as orientações de tratamento de falhas transitórias.

• Perda de dados esperada: Não se espera perda de dados devido a uma falha de zona.

• Tempo de inatividade previsto: Durante as interrupções de zona, as ligações podem sofrer interrupções breves que normalmente duram alguns segundos enquanto o tráfego é redistribuído. Certifique-se de que seus aplicativos estejam preparados seguindo as diretrizes de tratamento de falhas transitórias.

• Redistribution: Azure Cosmos DB redireciona automaticamente os pedidos recebidos para réplicas saudáveis noutras zonas de disponibilidade. Quando uma zona de disponibilidade sofre uma falha, a plataforma realoca automaticamente a largura de banda provisionada para outras réplicas.

Recuperação de zona

Quando a zona de disponibilidade recupera, o Azure Cosmos DB restaura automaticamente as réplicas na zona de disponibilidade e redireciona o tráfego entre réplicas normalmente.

Teste de falhas de zona

A gestão de failover e recuperação das zonas de disponibilidade do Azure Cosmos DB é totalmente feita pela Microsoft. Não é necessário iniciar ou validar processos de falha de zona de disponibilidade.

Resiliência a falhas em toda a região

Quando implementa uma conta Azure Cosmos DB numa única região, uma falha regional que afeta todos os nós do Azure Cosmos DB normalmente não causa perda de dados, mas impede que a sua aplicação aceda aos seus dados. O Azure Cosmos DB restaura o acesso aos dados depois de o serviço recuperar na região afetada. A perda de dados ocorre apenas se a região sofrer um desastre irrecuperável.

Para se preparar para os raros casos de interrupções regionais, pode configurar o Azure Cosmos DB para suportar vários níveis de durabilidade e disponibilidade, utilizando uma destas abordagens:

• Múltiplas regiões de leitura com uma única região de escrita. Pode, opcionalmente, ativar o failover gerido por serviços ou o failover automático por partição (PPAF).
• Múltiplas regiões de escrita.

A tabela seguinte resume as opções de recuperação disponíveis com base na configuração da conta e no tipo de falha. Secções posteriores deste artigo fornecem detalhes extensos sobre estas opções e o comportamento associado.

SDKs e resiliência

Os SDKs do Azure Cosmos DB são uma parte importante da estratégia de resiliência da sua aplicação. Quando tem uma conta multi-região, a configuração do SDK afeta a forma como os pedidos são encaminhados entre regiões, incluindo as regiões preferidas para se ligar e as regiões que devem ser excluídas. Os SDKs monitorizam a disponibilidade de regiões e partições, e podem reconfigurar-se dinamicamente para usar regiões e partições saudáveis, como através do disjuntor ao nível da partição.

Para mais informações sobre como o SDK suporta alta disponibilidade, consulte a documentação de alta disponibilidade do SDK que utiliza:

• Azure Cosmos DB .NET SDK v3
• Azure Cosmos DB Java SDK v4
• SDK Python do Azure Cosmos DB

Perda potencial de dados durante interrupções regionais

Quando implementas uma conta Azure Cosmos DB em várias regiões, a durabilidade dos dados depende do nível de consistência que configuras na conta. A tabela seguinte detalha, para todos os níveis de consistência, o objetivo do ponto de recuperação (RPO) de uma conta Azure Cosmos DB que esteja implementada em pelo menos duas regiões. O RPO representa a potencial perda de dados durante uma interrupção regional.

K = O número de versões (ou seja, atualizações) de um item.

T = O intervalo de tempo desde a última atualização.

Para contas de várias regiões, o valor mínimo de K e T é 100.000 operações de gravação ou 300 segundos. Esse valor define o RPO mínimo para os dados quando se utiliza a obsolescência limitada.

Para obter mais informações sobre as diferenças entre os níveis de consistência, consulte Níveis de consistência no Azure Cosmos DB.

Múltiplas regiões de leitura com uma única região de escrita

Se a sua solução exigir tempo de funcionamento contínuo durante interrupções regionais, pode configurar o Azure Cosmos DB para replicar os seus dados em várias regiões, com as escritas tratadas pela sua região principal. Pode, opcionalmente, configurar as suas aplicações para se ligarem a regiões de leitura específicas, o que pode ajudar a melhorar o seu desempenho. Se uma região tiver uma falha, a conta pode continuar a operar a partir de regiões saudáveis.

Alternância entre regiões (failover)

Podes configurar o SDK do Azure Cosmos DB com uma lista prioritária de regiões de leitura. O SDK liga a sua aplicação à primeira região disponível na lista. Durante uma falha de região de leitura, o SDK deteta a falha de região através de códigos de resposta do backend, marca-a como indisponível e encaminha operações futuras para a próxima região disponível na lista de preferências. Certifique-se de que a lista de regiões preferenciais está definida corretamente e alinha-se com os requisitos do seu negócio e de latência. Para orientações detalhadas, consulte Resolver problemas de disponibilidade do SDK do Azure Cosmos DB.

Failover é o processo de tornar uma das regiões da sua conta indisponível, total ou parcialmente. O efeito de um failover depende se a região é uma região de escrita ou uma região de leitura:

• Se uma região de escrita se tornar indisponível, outra região torna-se região de escrita.
• Se uma região de leitura ficar indisponível, essa região não pode servir pedidos de leitura e outras regiões são usadas para operações de leitura.

O Azure Cosmos DB fornece múltiplos tipos de failover:

• Failover automático por partição (PPAF): Internamente, o Azure Cosmos DB distribui os seus dados por várias partições físicas. Se surgir um problema na infraestrutura que suporta uma partição, outras partições podem não ser afetadas. O PPAF permite que contas de região de escrita única mudem automaticamente partições individuais para uma região secundária enquanto mantém as partições saudáveis na região primária. O PPAF pode ajudar a minimizar o tempo de inatividade e permitir uma recuperação mais rápida durante uma falha parcial da região. Para mais informações, consulte Como integrar e adotar Per-Partition Failover Automático (PPAF) para Azure Cosmos DB.

  Note

  O Failover Automático por Partição está em pré-visualização pública. Este recurso é fornecido sem um contrato de nível de serviço. Para mais informações, consulte Termos Suplementares de Utilização para Microsoft Azure Previews.

• Failover forçado: Podes desligar uma das regiões da tua conta. Isto também é referido como um failover gerido pelo cliente, ou uma operação de região offline. Esta é a abordagem recomendada para restaurar rapidamente a disponibilidade durante uma interrupção. És responsável por detetar a falha e desencadear o failover. Também pode usar falhas forçadas para simular cenários de falha de região durante testes, como num exercício de recuperação de desastres.

  Se desligar a região de escrita, a região de leitura com a próxima prioridade mais alta torna-se a nova região de escrita. Se desconectares uma região de leitura, as tuas aplicações podem ligar-se a qualquer outra região de leitura na conta.

  Um failover forçado da sua região de gravação acarreta a possibilidade de perda de dados para quaisquer operações de escrita não replicadas.

  Após um failover forçado, a Microsoft tem de voltar a pôr a região online. Para regiões saudáveis, este processo é automatizado, mas pode demorar vários dias. Se a região não voltar a operar dentro de um ou dois dias, abra um processo de apoio para pedir assistência.

• Alterar a região de escrita: Quando as regiões estiverem saudáveis, pode alterar a região de escrita da sua conta. Esta alteração é, na prática, um failover planeado da região de escrita da sua conta.

  Alterar a região de escrita não resulta em perda de dados, porque a replicação de dados consegue acompanhar antes de a nova região de escrita ser promovida. Pode haver uma breve interrupção, mas os clientes que utilizam lógica de tentativa novamente e outras técnicas de tratamento de falhas transitórias normalmente não experimentam impacto significativo.

  Esta operação exige que as regiões estejam saudáveis, por isso não pode ser usada durante uma interrupção regional.

• Failover gerido por serviços: Quando a sua conta utiliza failover gerido por serviços, a Microsoft é responsável por decidir quando fazer failover entre as regiões. Para permitir o failover gerido por serviços, especifica prioridades para cada região. No entanto, o processo de declarar uma interrupção e de ativar o failover gerido pelo serviço pode demorar bastante tempo – potencialmente uma hora ou mais. Para uma recuperação mais rápida, realize um failover forçado em vez de esperar que o failover gerido pelo serviço seja iniciado.

  Se a Microsoft ativar o failover gerido pelo serviço para a região de escrita da conta, quaisquer escritas não replicadas podem ser perdidas.

  Após um failover gerido pelo serviço, a Microsoft tem de voltar a pôr uma região online. A Microsoft disponibiliza automaticamente a região online, mas este processo pode demorar vários dias.

Requirements

Region support: Pode configurar qualquer região Azure como região de leitura para a sua conta Azure Cosmos DB.

Custo

Adicionar uma região adicional de leitura a uma conta Azure Cosmos DB aumenta os seus custos existentes para cada região. Para obter mais informações, consulte Preços do Azure Cosmos DB.

Configurar múltiplas regiões de leitura

• Adicionar regiões de leitura a uma conta: Pode configurar várias regiões na sua conta ao criar a conta ou a qualquer momento após a sua criação. Para mais informações, consulte Adicionar/remover regiões da sua conta de base de dados.

• Ativar o failover: Alguns tipos de failover devem ser configurados antecipadamente:

  • Failover Automático por Partição: Para mais informações, consulte Como incorporar e adotar Failover Automático por Partição (PPAF) para Azure Cosmos DB.

  • Failover gerenciado por serviços: Primeiro, ative o failover gerido por serviços. De seguida, defina prioridades de failover para cada região da sua conta.

Planejamento e gerenciamento de capacidade

Se a sua aplicação dispersar os pedidos entre regiões e uma região ficar offline, as restantes regiões experienciam um volume de pedidos mais elevado. Utilize a escalabilidade automática do débito para ajustar dinamicamente a capacidade com base na demanda. Se usar largura de banda provisionada, planeie capacidade adequada para lidar com a perda de uma região sem degradação do serviço e considere o superprovisionamento. Para obter mais informações, consulte Gerenciar a capacidade com provisionamento excessivo.

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

Esta secção descreve o que esperar quando configura uma conta Azure Cosmos DB com múltiplas regiões de leitura, e todas as regiões estão operacionais.

• Operação entre regiões: A sua aplicação configura a região que deve receber operações de leitura. Pode configurar a sua aplicação com uma lista prioritária de regiões, ou excluir algumas regiões. Para mais informações sobre como funciona a seleção de regiões, consulte Diagnosticar e resolver a disponibilidade de SDKs de Azure Cosmos DB em ambientes multirregionais.

  Todas as operações de escrita são direcionadas para a região de escrita da sua conta.

• Replicação de dados entre regiões: Todas as operações de escrita ocorrem na região principal da sua conta. As operações de escrita são replicadas para as outras regiões de leitura conforme o nível de consistência configurado na conta. Para informações sobre o atraso máximo de replicação, consulte Perda potencial de dados durante interrupções regionais.

Comportamento durante uma falha de região de leitura

Esta secção descreve o que esperar quando configura uma conta Azure Cosmos DB com múltiplas regiões de leitura e há uma falha numa das regiões de leitura da conta.

• Deteção e resposta: A responsabilidade de detetar a falha e responder depende do tipo de failover que a sua conta utiliza.

  • PPAF: Normalmente, o PPAF não se aplica a interrupções em regiões de leitura. No entanto, para contas com forte consistência e apenas duas regiões, perder a região de leitura reduz a conta a uma única região, que não consegue manter quórum dinâmico. Neste cenário, o PPAF pode ativar-se para preservar a disponibilidade, deslocando as partições afetadas para a região saudável.

  • Failover forçado: És responsável por realizar um failover forçado. Para obter passos detalhados, veja Execute falha controlada para a sua Conta Azure Cosmos DB.

    Se não realizar um failover, o comportamento da sua conta depende do seu nível de consistência:

    • Consistência forte: A consistência forte requer duas ou mais regiões para manter quórum dinâmico. Se houver menos de duas regiões disponíveis e não fizer um failover, a conta perde disponibilidade de escrita até à restauração do serviço.

    • Consistência de estagnação limitada: A consistência de estagnação limitada baseia-se na manutenção de um limiar específico de estagnação entre regiões. Se a duração da interrupção da região ultrapassar o limiar, o sistema não consegue garantir a consistência das operações de escrita. Se não fizer um failover, a conta perde disponibilidade de escrita até à restauração do serviço.

  • failover gerido por serviços: Se o failover gerido por serviços estiver ativado, Microsoft eventualmente deteta a falha e inicia um failover da sua conta. No entanto, este processo pode demorar um tempo considerável, potencialmente uma hora ou mais. Para uma recuperação mais rápida, realize um failover forçado em vez de esperar que o failover gerido pelo serviço seja iniciado.

• Notificação: A Microsoft não o notifica automaticamente quando uma região está inativa. No entanto:

  • Você pode usar a Integridade dos Recursos do Azure para monitorar a integridade de um recurso individual e pode configurar alertas de Integridade de Recursos para notificá-lo sobre problemas.

  • Pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas Service Health alerts para o notificar de problemas.

• Pedidos ativos: Quaisquer pedidos ativos podem ser terminados e precisam de ser tentados novamente pelo cliente após a conclusão do failover. Se seus clientes lidarem adequadamente com falhas transitórias , tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: Uma falha numa região de leitura não causa perda de dados. O Azure Cosmos DB continua a respeitar as garantias de consistência de leitura.

• Tempo de inatividade previsto: A quantidade de tempo de inatividade que a sua conta tem depende do tipo de failover que a sua conta utiliza.

  • PPAF: Quando o PPAF está ativado, o sistema deteta e recupera automaticamente da falha, normalmente em 3 minutos, sem qualquer intervenção manual.

  • Failover forçado: O tempo de inatividade é determinado por:

    • Quanto tempo demora a descobrir a falha e iniciar um failover.

    • Quanto tempo demora o failover, que normalmente é de alguns segundos.

      Advertência

      Não realize quaisquer operações de configuração (plano de controlo) na região afetada durante cenários de interrupção, pois resultam em inconsistência da conta e atrasos na recuperação. Alguns exemplos de operações no plano de controlo a evitar incluem:

      • Alterar a região de escrita ou modificar a prioridade de failover
      • Atualize a conta para configuração de escrita múltipla
      • Atualização de níveis de consistência ou outras definições da conta
      • Atualização de configurações de endpoints privados ou definições de rede
      • Atualização do rendimento da conta ou operações de escalabilidade
      • Qualquer outra operação que modifique a configuração da conta ou as definições da região

  • failover gerido por serviços: Microsoft é responsável por iniciar o failover gerido por serviços, e o tempo de inatividade da sua conta baseia-se no tempo que demora Microsoft a declarar a interrupção e iniciar o failover. Em algumas situações, pode demorar uma hora ou mais. Se a sua conta sofrer interrupções nas escritas e precisar de restaurar rapidamente a disponibilidade de escrita, faça um failover forçado.

• Redistribuição: Para um failover forçado ou um failover gerido pelo serviço, a região afetada é desconectada e assinalada como offline.

  Nenhuma alteração é necessária no código do aplicativo para lidar com interrupções de região de leitura. Os SDKs Azure Cosmos DB redirecionam as operações de leitura para a próxima região disponível na lista de regiões preferenciais. Se nenhuma das regiões na lista de regiões preferenciais estiver disponível, as operações de leitura recuam automaticamente para a região de escrita atual da conta, conforme configurada no serviço.

  Note

  Se utilizar endpoints privados com uma conta Azure Cosmos DB, certifique-se de que o DNS privado está a routar corretamente após a operação da região offline. Para orientações detalhadas, veja Considerações de failover para endpoints privados.

Comportamento durante uma falha na região de escrita

Esta secção descreve o que esperar quando configura uma conta Azure Cosmos DB com múltiplas regiões de leitura, e há uma falha na região de escrita da conta.

• Deteção e resposta: A responsabilidade de detetar a falha e responder depende do tipo de failover que a sua conta utiliza.

  • PPAF: Microsoft deteta automaticamente a falha e inicia um failover de algumas partições, se apropriado. A sua aplicação não precisa de realizar qualquer ação.

  • Failover forçado: És responsável por realizar um failover forçado. Para obter passos detalhados, veja Execute falha controlada para a sua Conta Azure Cosmos DB.

    Se não fizer um failover, a conta perde disponibilidade de escrita até à restauração do serviço.

    Se houver uma falha na região de escrita da sua conta, evite realizar uma operação de alteração da região de escrita . As alterações na região de escrita não têm sucesso se houver uma falha na região de origem ou destino. A razão é que o procedimento de mudança de região inclui uma verificação de consistência que requer conectividade entre as regiões.

  • Service-managed failover: A Microsoft deteta automaticamente a falha e inicia um failover da sua conta. A sua aplicação não precisa tomar nenhuma ação.

• Notificação: A Microsoft não o notifica automaticamente quando uma região está inativa. No entanto:

  • Você pode usar a Integridade dos Recursos do Azure para monitorar a integridade de um recurso individual e pode configurar alertas de Integridade de Recursos para notificá-lo sobre problemas.

  • Pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas Service Health alerts para o notificar de problemas.

• Pedidos ativos: Quaisquer pedidos ativos podem ser terminados e precisam de ser tentados novamente pelo cliente após a conclusão do failover. Se seus clientes lidarem adequadamente com falhas transitórias , tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: Se configurar a sua conta com forte consistência, não ocorre perda de dados. Caso contrário, podem perder-se quaisquer escritas que não tenham sido replicadas após a conclusão do failover. Para informações sobre a perda máxima de dados esperada durante uma interrupção regional, consulte Perda potencial de dados durante interrupções regionais.

• Tempo de inatividade previsto: A quantidade de tempo de inatividade que a sua conta tem depende do tipo de failover que a sua conta utiliza.

  • PPAF: Quando o PPAF está ativado, espere uma breve interrupção, que normalmente dura cerca de 3 minutos.

  • Failover forçado: O tempo de inatividade depende de:

    • Quanto tempo demora para detetar a falha e iniciar um failover.
    • Quanto tempo demora o failover, que normalmente é de alguns segundos.

  Advertência

  Não realize quaisquer operações do plano de controlo na região afetada durante cenários de interrupção, pois resultam em inconsistências nas contas e atrasam a recuperação. Alguns exemplos de operações no plano de controlo a evitar incluem:

  • Alterar a região de escrita ou modificar a prioridade de recuperação de falha
  • Atualize a conta para configuração de escrita múltipla
  • Atualização de níveis de consistência ou outras definições da conta
  • Atualização de configurações de endpoints privados ou definições de rede
  • Atualização do rendimento da conta ou operações de escalabilidade
  • Qualquer outra operação que modifique a configuração da conta ou as definições da região
  • failover gerido por serviços: Microsoft é responsável por iniciar o failover gerido por serviços, e o tempo de inatividade da sua conta baseia-se no tempo que demora Microsoft a declarar a interrupção e iniciar o failover. Em algumas situações, pode demorar uma hora ou mais. Para restaurar rapidamente a disponibilidade de escrita, realize um failover forçado.

• Redistribuição: A redistribuição de tráfego de escrita depende do tipo de failover que a sua conta utiliza.

  • PPAF: O Azure Cosmos DB transfere automaticamente a partição não saudável para uma região saudável.

  • Failover forçado: Ao realizar um failover forçado, a região de escrita da sua conta é alterada para a região que especificar.

  Note

  Se utilizar endpoints privados com uma conta Azure Cosmos DB, certifique-se de que o DNS privado está a routar corretamente após a operação da região offline. Para orientações detalhadas, veja Considerações de failover para endpoints privados.

  • Failover gerido pelo serviço: O Azure Cosmos DB promove automaticamente uma das regiões secundárias da conta para se tornar a nova região de escrita principal. O failover ocorre para outra região, seguindo a ordem de prioridade que especificou para as regiões.

Recuperação da região

A Microsoft tem de reativar uma região. Quando uma região recupera após uma falha, a Microsoft coloca automaticamente a região online. No entanto, este processo pode demorar vários dias.

Depois de a região estar online, as ações que tomas são diferentes dependendo se a interrupção foi numa região de leitura ou de escrita.

• Interrupções de leitura na região: Quando a região afetada está novamente online, sincroniza-se com a região de escrita atual e volta a estar disponível para atender pedidos de leitura depois de estar totalmente sincronizada. As leituras subsequentes são redirecionadas para a região recuperada sem necessidade de alterar o código da aplicação. Durante o failover e a rejunção de uma região com falha anterior, o Azure Cosmos DB continua a honrar as garantias de consistência de leitura.

• Após as falhas de região de escrita: Quando a região afetada está novamente online, a região aparece como "online" no portal Azure e fica disponível como região de leitura. Neste ponto, é seguro mudar a região de escrita de volta para a região recuperada.

  Importante

  A região recuperada não será automaticamente promovida de volta como região de escrita assim que for recuperada. É tua responsabilidade voltar para a região recuperada como região de escrita, assim que for seguro fazê-lo.

  Não há perda de dados ou disponibilidade antes, enquanto ou depois de mudar a região de escrita. Seu aplicativo continua a estar altamente disponível.

  Se algumas operações de escrita não foram replicadas antes da região ficar offline, pode ler as operações de escrita não replicadas do feed de conflito. A sua aplicação pode ler o feed de conflitos, resolver quaisquer conflitos com base na lógica específica da aplicação e escrever os dados atualizados de volta no contentor conforme apropriado.

Teste para falhas regionais

A sua aplicação pode não gerir corretamente os failovers de região, mesmo que a sua conta do Azure Cosmos DB esteja altamente disponível. Para testar a alta disponibilidade completa do seu aplicativo como parte dos testes de aplicativos ou exercícios de recuperação de desastres (DR), desative temporariamente o failover gerenciado pelo serviço para a conta. Invocar o failover forçado usando o PowerShell, o CLI do Azure ou o portal Azure, e, em seguida, monitorize a sua aplicação. Depois de concluir o teste, pode voltar automaticamente à região principal assim que a região estiver online e depois restaurar o failover gerido pelo serviço para a conta. Se a região não voltar a operar dentro de um ou dois dias, abra um processo de apoio para pedir assistência.

Se a sua conta usar PPAF, pode simular um failover de partição. Para mais informações, consulte Testar a configuração PPAF (simular falha).

Várias regiões de gravação

Você pode configurar o Azure Cosmos DB para aceitar escritas em várias regiões. Esta configuração pode proporcionar uma resiliência muito elevada a falhas regionais. Também é útil para reduzir a latência de escrita em aplicações geograficamente distribuídas.

Quando se configura uma conta do Azure Cosmos DB para múltiplas regiões de escrita, não há suporte para consistência forte e podem surgir conflitos de escrita. A região hub atua como árbitro em conflitos de escrita. Para obter mais informações sobre como resolver esses conflitos, consulte Tipos de conflito e políticas de resolução ao usar várias regiões de gravação.

É importante considerar o design da sua aplicação e como ela funciona com múltiplas regiões de escrita. Revise as melhores práticas para escrita multi-região.

Requirements

Region support: Pode configurar qualquer região Azure como região de leitura ou escrita para a sua conta Azure Cosmos DB.

Custo

Adicionar uma região de escrita adicional a uma conta Azure Cosmos DB aumenta os custos existentes para cada região. Para obter mais informações, consulte Preços do Azure Cosmos DB.

Configurar múltiplas regiões de escrita

Pode configurar várias regiões de escrita na sua conta ao criar a conta ou a qualquer momento após a sua criação. Para mais informações, consulte Configurar múltiplas regiões de escrita.

Para usar eficazmente múltiplas regiões de escrita, a sua aplicação também precisa de ser configurada adequadamente. Veja Configurar escritas multirregião em aplicações que utilizam a Azure Cosmos DB.

Planejamento e gerenciamento de capacidade

Se a sua aplicação dispersar os pedidos entre regiões e uma região ficar offline, as restantes regiões experienciam um volume de pedidos mais elevado. Utilize a escalabilidade automática do débito para ajustar dinamicamente a capacidade com base na demanda. Se usar largura de banda provisionada, planeie capacidade adequada para lidar com a perda de uma região sem degradação do serviço e considere o superprovisionamento. Para obter mais informações, consulte Gerenciar a capacidade com provisionamento excessivo.

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

Esta secção descreve o que esperar quando configura uma conta Azure Cosmos DB com múltiplas regiões de escrita, e todas as regiões estão operacionais.

• Operação entre regiões: Quando uma conta é configurada com múltiplas regiões de escrita, a sua aplicação configura a região que deve ser usada para operações de leitura e escrita. Pode configurar a sua aplicação com uma lista prioritária de regiões, ou excluir algumas regiões. Para mais informações sobre como funciona a seleção de regiões, consulte Diagnosticar e resolver a disponibilidade de SDKs de Azure Cosmos DB em ambientes multirregionais. Para aprender a configurar a sua aplicação, veja Configurar escritas multi-região em aplicações que utilizam Azure Cosmos DB.

• Replicação de dados entre regiões: Os dados são replicados entre regiões de forma assíncrona. O atraso na replicação depende do nível de consistência da conta. Não é possível usar consistência forte para escritas em várias regiões. Para mais informações, consulte Potencial perda de dados durante interrupções regionais.

  Quando uma conta está configurada para múltiplas regiões de escrita, aplicações em diferentes regiões podem fazer alterações que entram em conflito entre si. O Azure Cosmos DB oferece capacidades de resolução de conflitos. Para mais informações, consulte Tipos de conflitos e políticas de resolução ao utilizar múltiplas regiões de escrita. Para saber como configurar a sua própria política de resolução de conflitos, consulte Gerenciar políticas de resolução de conflitos em Azure Cosmos DB.

  Note

  Atualizar frequentemente o mesmo ID do documento, ou recriar o mesmo ID de documento com frequência após o seu TTL expirar ou ser eliminado, afeta negativamente o desempenho da replicação devido ao aumento do número de conflitos gerados no sistema.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando configura uma conta Azure Cosmos DB com múltiplas regiões de escrita e há uma falha numa das regiões de leitura ou escrita da conta.

• Deteção e resposta: A sua aplicação deteta a perda da região. Os SDKs do Azure Cosmos DB fornecem capacidades automáticas de seleção de regiões que encaminham operações de leitura e escrita para regiões saudáveis.

• Notificação: A Microsoft não o notifica automaticamente quando uma região está inativa. No entanto:

  • Você pode usar a Integridade dos Recursos do Azure para monitorar a integridade de um recurso individual e pode configurar alertas de Integridade de Recursos para notificá-lo sobre problemas.

  • Pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas Service Health alerts para o notificar de problemas.

• Pedidos ativos: Quaisquer pedidos ativos podem ser terminados e precisam de ser tentados novamente pelo cliente após a conclusão do failover. Se seus clientes lidarem adequadamente com falhas transitórias , tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: Dados recentemente atualizados podem tornar-se indisponíveis noutras regiões. Para informações sobre a perda máxima de dados esperada durante uma interrupção regional, consulte Perda potencial de dados durante interrupções regionais. No improvável caso de a região afetada sofrer perda permanente de dados, pode perder dados não replicados.

• Tempo de inatividade previsto: Não há tempo de inatividade esperado em configurações multi-escrita, desde que os SDKs estejam corretamente configurados com ApplicationRegions ou PreferredRegions.

  Dica

  Para melhores resultados, as aplicações distribuídas globalmente devem ser encaminhadas por um serviço global de balanceamento de carga, como o Azure Front Door ou o Gestor de Tráfego do Azure. Estes serviços podem detetar degradação regional e encaminhar automaticamente o tráfego para instâncias de aplicação numa região saudável.

• Redistribution: Os SDKs Azure Cosmos DB detetam automaticamente que a região está insalubre e redirecionam as operações de leitura e escrita para a próxima região disponível na lista de regiões preferenciais. Não são necessárias alterações no seu código de candidatura.

  Dica

  Se a sua aplicação for antecedida pelo Azure Front Door ou pelo Traffic Manager, esses serviços também detetam degradação regional e encaminham o tráfego para uma região saudável.

Recuperação da região

Quando a região afetada está novamente online, a região aparece como "online" no portal Azure e volta a estar disponível.

Qualquer dado de escrita que não tenha sido replicado quando a região falhou fica disponível através do feed de conflito. Os aplicativos podem ler o feed de conflitos, resolver os conflitos com base na lógica específica do aplicativo e gravar os dados atualizados de volta no contêiner do Azure Cosmos DB, conforme apropriado.

Teste para falhas regionais

Para testar cenários de failover de escrita multirregional, pode desativar uma região de escrita usando um failover forçado. Este processo simula uma interrupção regional, e pode observar como a sua aplicação responde.

Backup e restauração

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

A perda de dados pode ocorrer devido a eliminações acidentais ou outros problemas na sua aplicação que causam corrupção de dados. Quando usa uma conta de uma única região, pode também ocorrer perda de dados devido a um desastre irrecuperável na região do Azure Cosmos DB. Para o ajudar a proteger-se contra a perda de dados, o Azure Cosmos DB oferece um conjunto de capacidades de backup e restauro. Pode configurar backups e retenções com base nos requisitos de recuperação e custos. Para obter mais informações, consulte Backup online e restauração de dados sob demanda no Azure Cosmos DB.

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

O Azure Cosmos DB gere de forma transparente todos os detalhes dos nós de computação individuais e realiza automaticamente patches e outros tipos de manutenção planeada. Os SLAs do Azure Cosmos DB para disponibilidade e latência aplicam-se em todas as operações automáticas de manutenção que o sistema realiza.

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.

O Azure Cosmos DB fornece SLAs para uma variedade de configurações e características de serviço, incluindo disponibilidade, latência, taxa de transferência e consistência.

Os SLAs de disponibilidade variam consoante o uso de alguma das seguintes capacidades do produto:

• Capacidade de processamento provisionada
• Conta de região única com suporte de zonas de disponibilidade (redundância de zona)
• Contas que utilizam múltiplas regiões de leitura
• Contas que utilizam múltiplas regiões de escrita (Nível Crítico de Negócio)

Conteúdo relacionado

• Fiabilidade do Azure
• Azure Cosmos DB visão geral
• Níveis de consistência no Azure Cosmos DB
• Distribuição global de dados com Azure Cosmos DB
• Diagnosticar e solucionar problemas de disponibilidade dos SDKs do Azure Cosmos DB em ambientes multirregionais