Confiabilidade na Grade de Eventos do Azure e no namespace da Grade de Eventos
Este artigo contém informações detalhadas sobre a resiliência regional do namespace Grade de Eventos e da Grade de Eventos com zonas de disponibilidade, recuperação de desastres entre regiões e continuidade de negócios.
Para obter uma visão geral da arquitetura da confiabilidade no Azure, consulte Confiabilidade do Azure.
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas duas zonas restantes.
As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.
As definições de recursos da Grade de Eventos para tópicos, tópicos do sistema, domínios e assinaturas de eventos e dados de eventos são replicadas automaticamente em três zonas de disponibilidade. Quando há uma falha regional em uma das zonas de disponibilidade, os recursos da Grade de Eventos fazem failover automaticamente para outra zona de disponibilidade sem intervenção humana. Atualmente, não é possível controlar (ativar ou desativar) esse recurso. Quando uma região existente começa a oferecer suporte a zonas de disponibilidade, os recursos existentes da Grade de Eventos são automaticamente submetidos a failover para aproveitar esse recurso. Não é precisa qualquer ação da parte do cliente.
O namespace da Grade de Eventos do Azure também alcança alta disponibilidade dentro da região usando zonas de disponibilidade.
Pré-requisitos
Para suporte à zona de disponibilidade, os recursos da Grade de Eventos devem estar em uma região que ofereça suporte a zonas de disponibilidade. Para analisar quais regiões oferecem suporte a zonas de disponibilidade, consulte a lista de regiões suportadas.
Preços
Como a Grade de Eventos oferece suporte a zonas de disponibilidade automaticamente em regiões que oferecem suporte a zonas de disponibilidade, não há alterações no preço.
Criar um recurso com zonas de disponibilidade ativadas
Como a Grade de Eventos oferece suporte a zonas de disponibilidade automaticamente em regiões que oferecem suporte a zonas de disponibilidade, não há nenhuma configuração de configuração necessária.
Migrar para o suporte à zona de disponibilidade
Se realocar os recursos da Grelha de Eventos para uma região que suporte zonas de disponibilidade, receberá automaticamente suporte para a zona de disponibilidade. Para saber como realocar seus recursos para outra região que ofereça suporte a zonas de disponibilidade, consulte o seguinte:
- Realocar tópicos do sistema de Grade de Eventos do Azure para outra região
- Realoque tópicos personalizados da Grade de Eventos do Azure para outra região
- Realocar domínios da Grade de Eventos do Azure para outra região
Recuperação de desastres entre regiões e continuidade de negócios
A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.
A recuperação de desastres normalmente envolve a criação de um recurso de backup para evitar interrupções quando uma região não se torna íntegra. Durante esse processo, uma região primária e secundária dos recursos da Grade de Eventos do Azure será necessária em sua carga de trabalho.
Há diferentes maneiras de se recuperar de uma perda grave da funcionalidade do aplicativo. Nesta seção, descrevemos a lista de verificação que você precisará seguir para preparar seu cliente para se recuperar de uma falha devido a um recurso ou região não íntegros.
A Grade de Eventos suporta recuperação de desastres geográficos (GeoDR) manual e automática no lado do servidor. Você ainda pode implementar a lógica de recuperação de desastres do lado do cliente se quiser um maior controle sobre o processo de failover. Para obter detalhes sobre GeoDR automático, consulte Recuperação de desastres geográficos do lado do servidor na Grade de Eventos do Azure. Para obter detalhes sobre como implementar a recuperação de desastres do lado do cliente, consulte Implementação de failover do lado do cliente na Grade de Eventos do Azure.
A tabela a seguir ilustra o failover do lado do cliente e o suporte à recuperação de desastres geográficos na Grade de Eventos.
| Recurso Grade de Eventos | Suporte a failover do lado do cliente | Suporte de recuperação de desastres geográficos (GeoDR) |
|---|---|---|
| Tópicos Personalizados | Suportado | Cross-Geo / Regional |
| Tópicos do sistema | Não suportado | Ativado automaticamente |
| Domínios | Suportado | Cross-Geo / Regional |
| Namespaces de parceiros | Suportado | Não suportado |
| Espaços de nomes | Suportado | Não suportado |
Namespace da grade de eventos
O namespace Grade de Eventos não oferece suporte a DR entre regiões. No entanto, você pode obter alta disponibilidade entre regiões por meio da implementação de failover do lado do cliente criando namespaces primários e secundários.
Com uma implementação de failover do lado do cliente, você pode:
Implemente um processo personalizado (manual ou automatizado) para replicar namespace, identidades de cliente e outras configurações**, incluindo certificados de CA, grupos de clientes, espaços de tópicos, associações de permissão, roteamento, entre regiões primárias e secundárias.
Implemente um serviço de concierge que forneça aos clientes endpoints primários e secundários realizando uma verificação de integridade nos endpoints. O serviço de concierge pode ser um aplicativo Web replicado e mantido acessível usando técnicas de redirecionamento de DNS, por exemplo, usando o Gerenciador de Tráfego do Azure.
Obtenha uma solução de DR Ativo-Ativo replicando os metadados e equilibrando a carga entre os namespaces. Uma solução de DR Ativo-Passivo pode ser obtida replicando os metadados para manter o namespace secundário pronto para que, quando o namespace primário estiver indisponível, o tráfego possa ser direcionado para o namespace secundário.
Configurar a recuperação após desastre
Para regiões emparelhadas, a Grade de Eventos oferece um recurso para fazer failover do tráfego de publicação para a região emparelhada para tópicos personalizados, tópicos do sistema e domínios. Nos bastidores, a Grade de Eventos sincroniza automaticamente as definições de recursos de tópicos, tópicos do sistema, domínios e assinaturas de eventos para a região emparelhada. No entanto, os dados do evento não são replicados para a região emparelhada. No estado normal, os eventos são armazenados na região selecionada para esse recurso. Quando há uma interrupção de região e a Microsoft inicia o failover, novos eventos começam a fluir para a região emparelhada geograficamente e são despachados de lá sem a sua intervenção. Os eventos publicados e aceitos na região original são enviados de lá depois que a interrupção é mitigada.
Você pode escolher entre duas opções de failover, failover iniciado pela Microsoft e iniciado pelo cliente. Para obter etapas detalhadas sobre como definir essas duas configurações, consulte Configurar residência de dados.
O failover iniciado pela Microsoft é exercido pela Microsoft em situações raras para fazer failover de recursos da Grade de Eventos de uma região afetada para a região emparelhada geograficamente correspondente. A Microsoft reserva-se o direito de determinar quando esta opção será exercida. Esse mecanismo não envolve um consentimento do usuário antes que o tráfego do usuário seja submetido a failover.
Habilite essa funcionalidade atualizando a configuração para seu tópico ou domínio. Selecione Cross-Geo (padrão) para habilitar o failover iniciado pela Microsoft.
O failover iniciado pelo cliente é definido pelo seu plano de recuperação de desastres personalizado para tópicos e domínios da Grade de Eventos do Azure, e nenhum dado de qualquer tipo é replicado para outra região pela Microsoft. Embora essa opção de failover exija um pouco mais de esforço, ela permite um failover mais rápido e você controla a escolha de regiões secundárias. Se você quiser implementar a recuperação de desastres do lado do cliente para tópicos da Grade de Eventos do Azure, consulte Criar sua própria recuperação de desastres do lado do cliente para tópicos da Grade de Eventos do Azure.
Há algumas razões pelas quais você pode querer desabilitar o recurso de failover iniciado pela Microsoft:
- O failover iniciado pela Microsoft é feito com base no melhor esforço.
- Alguns pares geográficos não atendem aos requisitos de residência de dados da sua organização.
Habilite essa funcionalidade atualizando a configuração para seu tópico ou domínio. Selecione Regional.
Se você usar uma região não emparelhada, independentemente da configuração de residência de dados selecionada, seus metadados só serão replicados dentro da região.
Experiência de failover de recuperação de desastres
A recuperação de desastres é medida com duas métricas, RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e RTO (Recovery Time Objetive, objetivo de tempo de recuperação).
O failover automático da Grade de Eventos tem diferentes RPOs e RTOs para seus metadados (tópicos, domínios, assinaturas de eventos) e dados (eventos). Se você precisar de especificações diferentes das seguintes, ainda poderá implementar seu próprio failover do lado do cliente usando as APIs de integridade do tópico.
Objetivo de ponto de recuperação (RPO)
RPO de metadados: zero minutos. Para recursos aplicáveis, quando um recurso é criado/atualizado/excluído, a definição de recurso é replicada de forma síncrona para o par geográfico. Quando ocorre um failover, nenhum metadados é perdido.
RPO de dados: quando ocorre um failover, novos dados são processados da região emparelhada. Assim que a interrupção é mitigada para a região afetada, os eventos não processados são despachados de lá. Se a recuperação da região exigisse mais tempo do que o valor de tempo de vida definido nos eventos, os dados poderiam ser descartados. Para atenuar essa perda de dados, recomendamos que você configure um destino de letra morta para uma assinatura de evento. Se a região afetada for perdida e irrecuperável, haverá alguma perda de dados. Na melhor das hipóteses, o assinante está acompanhando a taxa de publicação e apenas alguns segundos de dados são perdidos. O pior cenário seria quando o assinante não está processando ativamente eventos e com um tempo máximo de vida de 24 horas, a perda de dados pode ser de até 24 horas.
Objetivo de tempo de recuperação (RTO)
RTO de metadados: a tomada de decisão de failover é baseada em fatores como a capacidade disponível em região emparelhada e pode durar no intervalo de 60 minutos ou mais. Assim que o failover é iniciado, dentro de 5 minutos, a Grade de Eventos começa a aceitar chamadas de criação/atualização/exclusão de tópicos e assinaturas.
RTO de dados: As mesmas informações acima.
Importante
- No caso de recuperação de desastres do lado do servidor, se a região emparelhada não tiver capacidade extra para receber o tráfego adicional, a Grade de Eventos não poderá iniciar o failover. A recuperação é feita com base no melhor esforço.
- A utilização desta funcionalidade é gratuita.
- A recuperação de desastres geográficos não é suportada para namespaces de parceiros e tópicos de parceiros.
Próximos passos
Crie sua própria recuperação de desastres do lado do cliente para tópicos da Grade de Eventos do Azure.