Obtenha alta disponibilidade com o Cosmos DB

APLICA-SE A: API do SQL API do Cassandra API do Gremlin API de Tabela API do Azure Cosmos DB para MongoDB

Para compilar uma solução com alta disponibilidade, você precisa avaliar as características de confiabilidade de todos os seus componentes. O Cosmos DB foi projetado para fornecer vários recursos e opções de configuração para alcançar alta disponibilidade para todas as necessidades de disponibilidade de todas as soluções.

Usaremos os termos RTO (Objetivo de Tempo de Recuperação), para indicar o tempo entre o início de uma paralisação que afeta o Cosmos DB e a recuperação para disponibilidade total, e RPO (Objetivo do Ponto de Recuperação), para indicar o tempo entre a última gravação restaurada corretamente e o tempo do início da paralisação que afeta o Cosmos DB.

Observação

Os RPOs e RTOs máximos esperados dependem do tipo de paralisação que o Cosmos DB está enfrentando. Por exemplo, uma paralisação de um único nó terá RTO e RPO esperados diferentes de uma paralisação de toda a região.

Este artigo detalha os eventos que podem afetar a disponibilidade do Cosmos DB e as opções de configuração do Cosmos DB correspondentes para atingir as características de disponibilidade necessárias para sua solução.

Manutenção de réplica

O Cosmos DB é um serviço multilocatário gerenciado que gerencia todos os detalhes de nós de computação individuais de forma transparente. Os usuários não têm que se preocupar com nenhum tipo de correção e manutenção planejada. O Cosmos DB garante SLAs para disponibilidade e latência P99 por meio de todas as operações de manutenção automática executadas pelo sistema.

Consulte a seção de SLAs para ver os SLAs de disponibilidade garantida.

Paralisações de réplica

As paralisações de réplica referem-se a paralisações de nós individuais em um cluster do Cosmos DB implantado em uma região do Azure. O Cosmos DB reduz automaticamente as paralisações de réplica, garantindo pelo menos três réplicas de seus dados em cada região do Azure para a sua conta dentro de um quórum de quatro réplicas. Isso resulta em RTO = 0 e RPO = 0, para paralisações de nó individuais, sem alterações ou configurações de aplicativos necessárias.

Em muitas regiões do Azure, é possível distribuir seu cluster do Cosmos DB entre zonas de disponibilidade, o que resulta em SLAs aumentados, pois as zonas de disponibilidade são fisicamente separadas e fornecem fontes de energia distintas, rede e resfriamento. Veja Zonas de Disponibilidade. Quando uma Cosmos banco de dados é implantada usando zonas de disponibilidade, Cosmos DB fornece RTO = 0 e RPO = 0 mesmo em uma paralisação de zona.

Quando os usuários implantam em uma única região do Azure, sem nenhuma entrada de usuário extra, o Cosmos DB é resiliente a paralisações de nó. A habilitação da redundância entre zonas de disponibilidade torna o Cosmos DB resiliente a paralisações de zonas, com um custo maior de encargos. Tanto os SLAs quanto o preço são relatados na seção SLAs.

A redundância de zona só pode ser configurada ao adicionar uma nova região a uma conta do Azure Cosmos. Para regiões existentes, a redundância de zona pode ser habilitada ao remover a região e adicioná-la novamente com a redundância de zona habilitada. Para uma conta de região única, isso requer a adição de uma região para realizar o failover temporário e, em seguida, a remoção e a adição da região desejada com redundância de zona habilitada.

Por padrão, uma conta do Cosmos DB não usa várias zonas de disponibilidade. Você pode habilitar a implantação em várias zonas de disponibilidade das seguintes maneiras:

Se a conta do Azure Cosmos for distribuída entre N regiões do Azure, haverá pelo menos N x 4 cópias de todos os dados. Para obter uma visão geral mais detalhada da distribuição de dados, consulte Distribuição de dados global nos bastidores. Ter uma conta do Azure Cosmos em mais de 2 regiões melhora a disponibilidade do aplicativo e fornece baixa latência entre as regiões associadas.

Consulte Distribuição global com o Azure Cosmos DB- os bastidores para obter mais informações sobre como o Cosmos DB replica dados em cada região.

Paralisações de região

As paralisações de região referem-se a paralisações que afetam todos os nós do Cosmos DB em uma região do Azure, em todas as zonas de disponibilidade. Nos raros casos de paralisações de região, o Cosmos DB pode ser configurado para dar suporte a vários resultados de durabilidade e disponibilidade.

Durabilidade

Quando uma contas do Cosmos DB é implantada em uma única região, geralmente não ocorre dados e o acesso aos dados é restaurado após os serviços do Cosmos DB se recuperarem na região afetada. A perda de dados pode ocorrer apenas com um desastre irrecuperável na região do Cosmos DB.

Para proteção contra a perda completa de dados que pode resultar de desastres catastróficos em uma região, o Azure Cosmos DB fornece dois modos de backup diferentes:

  • Backups contínuos garantem que o backup seja feito em cada região a cada 100 segundos e forneçam a capacidade de restaurar seus dados para qualquer ponto desejado no tempo com segunda granularidade. Em cada região, o backup depende dos dados confirmados nessa região.
  • Backups periódicos têm backups completos de todas as partições de todos os contêineres em sua conta, sem sincronização entre partições. O intervalo de backup mínimo é de 1 hora.

Quando uma conta do Azure Cosmos DB é implantada em várias regiões, a durabilidade dos dados depende do nível de consistência configurado na conta. A tabela a seguir detalha o RPO da Cosmos DB implantado em pelo menos duas regiões, para todos os níveis de consistência.

Nível de coerência RPO em caso de paralisação de região
Sessão, Prefixo Consistente, Eventual < 15 minutos
Desatualização limitada K&T
Forte 0

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

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

Para contas de várias regiões, o valor mínimo de K e T é de 100 mil operações de gravação ou 300 segundos. Isso define o RPO mínimo de dados ao usar a desatualização limitada.

Consulte Níveis de consistência para obter mais informações sobre as diferenças entre níveis de consistência.

Disponibilidade

Se sua solução exigir disponibilidade contínua durante paralisações de região, o Cosmos DB poderá ser configurado para replicar seus dados em várias regiões e fazer failover transparente para regiões disponíveis quando necessário.

Contas de uma única região poderão perder disponibilidade após uma indisponibilidade regional. Para garantir a alta disponibilidade em todos os momentos, é recomendável configurar sua conta do Azure Cosmos DB com uma única região de gravação e pelo menos uma segunda região (leitura) e habilitar o failover gerenciado pelo serviço.

O failover gerenciado pelo serviço permite que o Cosmos DB faça failover da região de gravação da conta de várias regiões, a fim de preservar a disponibilidade à custa da perda de dados conforme a seção de durabilidade. Os failovers regionais são detectados e manipulados no cliente do Azure Cosmos DB. Eles não exigem alterações do aplicativo. Consulte Como gerenciar uma conta do Azure Cosmos DB para ver instruções de como habilitar várias regiões de leitura e o failover gerenciado pelo serviço.

Importante

É fortemente recomendável configurar as contas do Azure Cosmos usadas para cargas de trabalho de produção para habilitar o failover gerenciado pelo serviço. Isso permite que o Cosmos DB faça failover automaticamente dos bancos de dados da conta para regiões disponíveis. Na ausência dessa configuração, a conta passará por perda de disponibilidade de gravação durante toda a interrupção da região de gravação, pois o failover manual não terá sucesso devido à falta de conectividade da região.

Várias regiões de gravação

O Azure Cosmos DB pode ser configurado para aceitar gravações em várias regiões. Isso é útil para reduzir a latência de gravação em aplicativos geograficamente distribuídos. Quando uma conta do Cosmos DB é configurada para várias regiões de gravação, não há suporte para consistência forte e podem surgir conflitos de gravação. Consulte Tipos de conflito e políticas de resolução ao usar várias regiões de gravação para obter mais informações sobre como resolver conflitos em várias configurações de região de gravação.

Considerando a arquitetura interna do Azure Cosmos DB, o uso de várias regiões de gravação não garante a disponibilidade de gravação durante uma paralisação de região. A melhor configuração para obter alta disponibilidade durante uma paralisação de região é uma única região de gravação com failover gerenciado pelo serviço.

Região de resolução de conflitos

Quando uma conta do Cosmos DB é configurada com gravações de várias regiões, uma das regiões atuará como um árbitro em caso de conflitos de gravação. Quando esses conflitos ocorrem, eles são roteados para essa região para uma resolução consistente.

O que se esperar em uma interrupção da região

O cliente de contas de uma única região terá perda de disponibilidade de leitura e gravação até que o serviço seja restaurado.

As contas de várias regiões terão comportamentos diferentes dependendo da tabela a seguir.

Configuração Interrupção Impacto na disponibilidade Impacto na durabilidade O que fazer
Região única de gravação Paralisação da região de leitura Todos os clientes redirecionarão automaticamente as leituras para outras regiões. Nenhuma perda de disponibilidade de leitura ou gravação para todas as configurações, exceto 2 regiões com consistência forte que perde a disponibilidade de gravação até que o serviço seja restaurado ou, se o failover gerenciado pelo serviço estiver habilitado, a região será marcada como falha e ocorrerá um failover. Sem perda de dados. Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura.

Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme apropriado.

Região única de gravação Paralisação da região de gravação Os clientes redirecionarão as leituras para outras regiões.

Sem o failover gerenciado pelo serviço, os clientes terão perda da disponibilidade de gravação até que ela seja restaurada automaticamente após a interrupção.

Com o failover de gerenciamento de serviço, os clientes terão perda de disponibilidade de gravação até que os serviços gerenciem um failover para uma nova região de gravação selecionada de acordo com suas preferências.

Se o nível de coerência forte não estiver selecionado, alguns dados poderão não ter sido replicados para as regiões ativas restantes. Isso depende do nível de consistência escolhido, conforme descrito nesta seção. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura.

Não acione um failover manual durante a interrupção, pois ele não terá êxito.

Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme apropriado. As contas que usam APIs do SQL também podem recuperar os dados não replicados na região com falha do feed de conflitos.

Várias regiões de gravação Qualquer interrupção regional Possibilidade de perda de disponibilidade de gravação temporária, de forma análoga a uma única região de gravação com failover gerenciado pelo serviço. O failover da região de resolução de conflitos também pode causar uma perda de disponibilidade de gravação se um alto número de gravações conflitantes ocorrer no momento da paralisação. Os dados atualizados recentemente na região com falha podem ficar indisponíveis nas regiões ativas restantes, dependendo do nível de consistência selecionado. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego adicional.

Quando a interrupção terminar, você pode ajustar novamente as RUs provisionadas conforme apropriado. Se possível, o Cosmos DB vai recuperar automaticamente dados não replicados na região com falha usando o método de resolução de conflitos configurado para contas de API do SQL e Última Gravação Prevalece para contas usando outras APIs.

Informações adicionais sobre paralisações de área de leitura

  • A região afetada será desconectada automaticamente e será marcada como offline. Os SDKs do Azure Cosmos DB redirecionarão as chamadas 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 chamadas retornarão automaticamente à região de gravação atual.

  • Não é necessária nenhuma alteração no código do aplicativo para lidar com a interrupção da região de leitura. Quando a região de leitura afetada ficar online novamente, ela será automaticamente sincronizada com a região de gravação atual e estará disponível novamente para fornecer solicitações de leitura.

  • As próximas leituras são redirecionadas para a região recuperada sem exigir nenhuma alteração do código do aplicativo. Durante o failover e o reingresso de uma região anteriormente com falha, as garantias de coerência de leitura continuam a ser cumpridas pelo Azure Cosmos DB.

  • Mesmo em um evento raro e infeliz, quando a região do Azure tornar-se permanentemente irrecuperável, não haverá perda de dados se a conta do Azure Cosmos de várias regiões estiver configurada com consistência forte. No caso raro de uma região de gravação permanentemente irrecuperável, as características de durabilidade de uma conta do Azure Cosmos de várias regiões estão especificadas na seção Durabilidade.

Informações adicionais sobre paralisações de área de gravação

  • Durante uma interrupção da região de gravação, a conta do Azure Cosmos promoverá automaticamente uma região secundária para ser a nova região de gravação primária quando o failover automático (gerenciado pelo serviço) estiver configurado na conta do Azure Cosmos. O failover ocorrerá em outra região na ordem de prioridade de região que você especificou.

  • Observe que o failover manual não deve ser disparado e não terá sucesso na presença de uma interrupção da região de origem ou de destino. Isso ocorre devido a uma verificação de consistência exigida pelo procedimento de failover que requer conectividade entre as regiões.

  • Quando a região afetada anteriormente estiver novamente online, todos os dados de gravação que não foram replicados quando a região falhou serão disponibilizados por meio do feed de conflitos. Aplicativos podem ler o feed de conflitos, resolvê-los com base na lógica específica do aplicativo e gravar os dados atualizados de volta no contêiner do Azure Cosmos conforme apropriado.

  • Depois que a região de gravação anteriormente afetada se recupera, ela fica automaticamente disponível como uma região de leitura. Você pode alternar de volta para a região recuperada como a região de gravação. Você pode alternar as regiões usando o PowerShell, CLI do Azure ou portal do Azure. Não há perda de dados ou disponibilidade antes, durante ou depois que você alterna a região de gravação e o aplicativo continua a ser altamente disponível.

SLAs

A tabela a seguir resume a capacidade de alta disponibilidade de várias configurações de conta:

KPI Região única sem AZs Região única com AZs Várias regiões, gravações de região única sem AZs Várias regiões, gravações de região única com AZs Várias regiões, gravações de várias regiões com ou sem AZs
SLA de disponibilidade de gravação 99,99% 99,995% 99,99% 99,995% 99,999%
SLA de disponibilidade de leitura 99,99% 99,995% 99,999% 99,999% 99,999%
Falhas de zona – perda de dados Perda de dados Sem perda de dados Sem perda de dados Sem perda de dados Sem perda de dados
Falhas de zona – disponibilidade Perda de disponibilidade Sem perda de disponibilidade Sem perda de disponibilidade Sem perda de disponibilidade Sem perda de disponibilidade
Interrupção regional – perda de dados Perda de dados Perda de dados Dependente do nível de consistência. Consulte Compensações de consistência, disponibilidade e desempenho para obter mais informações. Dependente do nível de consistência. Consulte Compensações de consistência, disponibilidade e desempenho para obter mais informações. Dependente do nível de consistência. Consulte Compensações de consistência, disponibilidade e desempenho para obter mais informações.
Interrupção regional – disponibilidade Perda de disponibilidade Perda de disponibilidade Nenhuma perda de disponibilidade para a falha de região de leitura, temporária para falha de região de gravação Nenhuma perda de disponibilidade para a falha de região de leitura, temporária para falha de região de gravação Sem perda de disponibilidade
Preço (1) N/D Taxa de RU/s x 1,25 provisionada Regiões de RU/s x n provisionadas RU/s provisionados x taxa de 1,25 x n regiões (2) Taxa de gravação de várias regiões x n regiões

1 Para contas sem servidor, as unidades de solicitação (RU) são multiplicadas por um fator de 1,25.

2 A taxa 1,25 se aplica somente a essas regiões nas quais AZ está habilitado.

Importante

Considerando a arquitetura interna do Azure Cosmos DB, o uso de várias regiões de gravação não garante a disponibilidade de gravação durante uma paralisação de região. A melhor configuração para obter alta disponibilidade em caso de paralisação de região é uma única região de gravação com failover gerenciado pelo serviço.

Criando aplicativos altamente disponíveis

  • Analise o comportamento esperado dos SDKs do Azure Cosmos durante esses eventos e quais são as configurações que o afetam.

  • Para garantir a alta disponibilidade de leitura e gravação, configure a conta do Azure Cosmos para abranger pelo menos duas ou três regiões, caso esteja usando uma consistência forte. Lembre-se que a melhor configuração para obter alta disponibilidade para uma paralisação de região é uma única região de gravação com failover gerenciado pelo serviço. Para saber mais, consulte Tutorial: Configurar a distribuição global do Azure Cosmos DB usando a API do SQL.

  • Para contas do Azure Cosmos de várias regiões configuradas com uma única região de gravação, habilite o failover gerenciado pelo serviço usando a CLI do Azure ou o portal do Azure. Depois de habilitar o failover gerenciado pelo serviço, sempre que houver um desastre regional, o Cosmos DB fará failover da sua conta sem qualquer entrada de usuário.

  • Mesmo se a conta do Azure Cosmos estiver altamente disponível, o aplicativo poderá não ser corretamente projetado para permanecer altamente disponível. Para testar a alta disponibilidade de ponta a ponta do aplicativo como parte de seus testes de aplicativo ou simulações de DR (recuperação de desastre), desabilite temporariamente o failover gerenciado pelo serviço para a conta, invoque o failover manual usando o PowerShell, a CLI do Azure ou o portal do Azure e monitore o failover do aplicativo. Ao final, é possível fazer failback para a região primária e restaurar o failover gerenciado pelo serviço para a conta.

Importante

Não invoque o failover manual durante uma interrupção de Cosmos DB nas regiões de origem ou de destino, pois ele exige conectividade de regiões para manter a consistência dos dados e ele não terá êxito.

  • Em um ambiente de banco de dados distribuído globalmente, há uma relação direta entre a durabilidade dos dados e o nível de consistência no caso de uma interrupção em toda a região. À medida que você vai desenvolvendo o plano de continuidade dos negócios, precisará saber qual é o tempo máximo aceitável antes que o aplicativo se recupere completamente após um evento de interrupção. O tempo necessário para o aplicativo se recuperar totalmente é conhecido como RTO (objetivo de tempo de recuperação). Também é necessário saber o período máximo de atualizações de dados recentes que o aplicativo pode perder sem maiores problemas durante a recuperação após um evento de interrupção. O período de tempo de atualizações que você pode perder é conhecido como RPO (objetivo de ponto de recuperação). Para ver o RTO e o RPO do Azure Cosmos DB, confira Níveis de consistência e durabilidade dos dados

O que se esperar em caso de uma interrupção da região do Cosmos DB

Em contas de região única, os clientes passarão por perda de disponibilidade de leitura e gravação.

As contas de várias regiões terão comportamentos diferentes dependendo da tabela a seguir.

Regiões de gravação Failover gerenciado pelo serviço O que esperar O que fazer
Região única de gravação não ativado No caso de uma paralisação em uma região de leitura quando não estiver usando consistência forte, todos os clientes serão redirecionados para outras regiões. Sem perda de disponibilidade de leitura ou gravação. Sem perda de dados. Ao usar consistência forte, a paralisação da região de leitura poderá afetar a disponibilidade de gravação se menos de duas regiões de leitura permanecerem.

No caso de uma interrupção na região de gravação, os clientes terão perda de disponibilidade de gravação. Se o nível de coerência forte não estiver selecionado, alguns dados poderão não ter sido replicados para as regiões ativas restantes. Isso depende do nível de consistência escolhido, conforme descrito nesta seção. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos.

O Cosmos DB vai restaurar automaticamente a disponibilidade de gravação quando a interrupção terminar.

Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura.

Não acione um failover manual durante a interrupção, pois ele não terá êxito.

Quando a interrupção terminar, ajuste novamente as RUs provisionadas conforme apropriado.

Região única de gravação habilitado No caso de uma paralisação em uma região de leitura quando não estiver usando consistência forte, todos os clientes serão redirecionados para outras regiões. Sem perda de disponibilidade de leitura ou gravação. Sem perda de dados. Ao usar consistência forte, a paralisação da região de leitura poderá afetar a disponibilidade de gravação se menos de duas regiões de leitura permanecerem.

No caso de uma interrupção na região de gravação, os clientes sofrerão perda de disponibilidade de gravação até o Cosmos DB eleger automaticamente uma região como a nova região de gravação de acordo com suas preferências. Se o nível de coerência forte não estiver selecionado, alguns dados poderão não ter sido replicados para as regiões ativas restantes. Isso depende do nível de consistência escolhido, conforme descrito nesta seção. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos.

Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego de leitura.

Não acione um failover manual durante a interrupção, pois ele não terá êxito.

Quando a interrupção terminar, você poderá mover a região de gravação de volta para a região original e ajustar novamente as RUs provisionadas conforme apropriado. As contas que usam APIs do SQL também podem recuperar os dados não replicados na região com falha do feed de conflitos.

Várias regiões de gravação Não aplicável Os dados atualizados recentemente na região com falha podem ficar indisponíveis nas regiões ativas restantes. Os níveis de consistência de sessão, eventual e de prefixo consistente garantem uma desatualização de <15 minutos. A desatualização limitada garante menos de K atualizações ou T segundos, dependendo da configuração. Se a região afetada sofrer perda permanente de dados, os dados não replicados poderão ser perdidos. Durante a interrupção, verifique se há RUs suficientes provisionadas nas regiões restantes para dar suporte ao tráfego adicional.

Quando a interrupção terminar, você pode ajustar novamente as RUs provisionadas conforme apropriado. Se possível, o Cosmos DB vai recuperar automaticamente dados não replicados na região com falha usando o método de resolução de conflitos configurado para contas de API do SQL e Última Gravação Prevalece para contas usando outras APIs.

Próximas etapas

Em seguida, você poderá ler os artigos a seguir: