Compartilhar via


Confiabilidade nos Hubs de Eventos do Azure

Esse artigo descreve o suporte à confiabilidade nos Hubs de Eventos do Azure e aborda a resiliência intra-regional com zonas de disponibilidade e recuperação de desastre entre regiões e continuidade dos negócios. Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, confira Confiabilidade do Azure.

Suporte à zona de disponibilidade

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

Para obter mais informações sobre zonas de disponibilidade no Azure, veja O que são zonas de disponibilidade?.

Os Hubs de Eventos implementam mecanismos transparentes de detecção de falhas e failover para que, quando ocorrer falha, o serviço continue operando dentro dos níveis de serviço garantidos e sem interrupções perceptíveis. Se você criar um namespace dos Hubs de Eventos em uma região que dê suporte a zonas de disponibilidade, a redundância de zona será habilitada automaticamente. Com a redundância de zona, a tolerância a falhas é aumentada e o serviço tem reservas de capacidade suficientes para lidar com a interrupção de uma instalação inteira. Os metadados e os dados (eventos) são replicados nos datacenters da zona de disponibilidade.

Pré-requisitos

O suporte à zona de disponibilidade está disponível apenas em regiões do Azure com zonas de disponibilidade.

Criar um recurso com zonas de disponibilidade habilitadas

Quando você usa o portal do Azure, a redundância de zona é habilitada automaticamente. Ao criar um namespace, você vê a seguinte mensagem realçada quando seleciona uma região com zonas de disponibilidade.

Captura de tela mostrando a página Criar Namespace com uma região que tem zonas de disponibilidade

Habilitar as Zonas de Disponibilidade

O portal do Azure não dá suporte à desabilitação de zonas de disponibilidade. Para desabilitar zonas de disponibilidade, use um dos seguintes métodos:

Migração da zona de disponibilidade

Quando você cria zonas de disponibilidade em uma região que dá suporte a elas, as zonas de disponibilidade são habilitadas automaticamente. Se você quiser saber como mover o namespace dos Hubs de Eventos para uma nova região que dê suporte a zonas de disponibilidade, consulte Realocar Hubs de Eventos para outra região.

Recuperação de desastre entre regiões e continuidade dos negócios

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é 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 de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

O modelo de cluster dos Hubs de Eventos do Azure totalmente ativo com suporte à zona de disponibilidade fornece resiliência contra interrupções de hardware e datacenter. No entanto, se ocorrer um desastre em que uma região inteira e todas as zonas se tornem indisponíveis, você poderá usar a recuperação de desastre geográfico para recuperar a carga de trabalho e a configuração do aplicativo.

Há dois recursos que fornecem recuperação de desastres geográficos nos Hubs de Eventos do Azure.

  • Recuperação de Desastre Geográfico (DR de Metadados), que fornece apenas a replicação de metadados.

    A recuperação de desastre geográfico garante que toda a configuração de um namespace (Hubs de Eventos, Grupos de Consumidores e configurações) seja replicada continuamente de um namespace primário para um secundário quando emparelhado.

    O recurso de recuperação de desastre de área geográfica dos Hubs de Eventos do Azure é uma solução de recuperação de desastre. Os conceitos e o fluxo de trabalho descritos neste artigo se aplicam a cenários de desastre e não a interrupções temporárias. Para uma discussão detalhada sobre a recuperação de desastre no Microsoft Azure, consulte este artigo.

    Com a recuperação de desastre geográfico, você pode iniciar uma migração de failover única do primário para o secundário a qualquer momento. A migração de failover aponta para o namespace secundário o nome do alias escolhido para o namespace. Após a migração, o emparelhamento é removido. O failover é quase instantâneo depois de iniciado.

    Para obter informações detalhadas, amostras e documentação adicional sobre a Recuperação de desastre geográfico nos Hubs de Eventos, consulte Hubs de Eventos do Azure – Recuperação de desastre geográfico.

  • A replicação geográfica (versão prévia pública), que fornece replicação de metadados e dados, replica as informações de configuração e todos os dados de um namespace primário para um ou mais namespaces secundários. Quando um failover é executado, a região secundária selecionada se torna a região primária e a região primária anterior se torna uma região secundária. Quando desejado, os usuários podem executar um failover de volta para a região primária original.

    Para obter informações detalhadas, exemplos e documentação adicional, sobre replicação geográfica nos Hubs de Eventos, consulte Replicação geográfica.

Próximas etapas