Confiabilidade nos Hubs de Eventos do Azure

Os Hubs de Eventos do Azure são um serviço de nuvem nativo que pode transmitir milhões de eventos por segundo com baixa latência, de qualquer origem para qualquer destino. Use os Hubs de Eventos para ingerir e armazenar dados de streaming e integrar com aplicativos cliente criados para Apache Kafka ou aplicativos que usam os SDKs de cliente dos Hubs de Eventos.

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 os Hubs de Eventos são resilientes a uma variedade de possíveis falhas e problemas e como você pode configurá-los para serem resilientes a outros, incluindo falhas transitórias, interrupções em zonas de disponibilidade e falhas regionais. Ele também descreve as opções de backup e recuperação e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) dos Hubs de Eventos do Azure.

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

Para saber como implantar Hubs de Eventos para dar suporte aos requisitos de confiabilidade da solução e entender como a confiabilidade afeta outros aspectos da arquitetura, consulte as práticas recomendadas de arquitetura para Hubs de Eventos no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Esta seção descreve aspectos importantes sobre como os Hubs de Eventos funcionam de uma perspectiva de confiabilidade. Apresenta-se a arquitetura lógica, que inclui recursos e funcionalidades que você utiliza e implanta. Ele também explica a arquitetura física, que fornece detalhes sobre como o serviço gerencia as operações internamente.

Arquitetura lógica

Um namespace dos Hubs de Eventos serve como o contêiner de gerenciamento para um ou mais hubs de eventos. Você configura o serviço, como alocar capacidade de streaming, configurar a segurança de rede e habilitar a resiliência geográfica e a recuperação de desastre geográfico, no nível do namespace.

Em um namespace, você pode organizar eventos em um hub de eventos. O ecossistema do Apache® Kafka refere-se a esse tipo de entidade como um tópico. O hub de eventos ou tópico é um log distribuído apenas de anexação para os seus eventos.

Cada hub de eventos contém uma ou mais partições, que são logs de eventos sequenciais. Um hub de eventos pode usar várias partições para executar o processamento paralelo e o dimensionamento horizontal. Os Hubs de Eventos garantem apenas a ordenação em uma única partição. O particionamento desempenha um papel fundamental no design de confiabilidade do aplicativo. Ao projetar seu aplicativo, faça uma compensação entre maximizar a disponibilidade e a consistência. Para maximizar o tempo de atividade para a maioria dos aplicativos, evite acessar partições diretamente através dos seus aplicativos cliente. Para obter mais informações, consulte Disponibilidade e consistência nos Hubs de Eventos.

Os consumidores que leem do hub de eventos podem ler seus eventos sequencialmente mantendo seu próprio ponto de verificação, que identifica o último evento recebido.

Para obter mais informações sobre partições e outros conceitos fundamentais nos Hubs de Eventos, consulte Recursos e terminologia nos Hubs de Eventos.

Arquitetura física

Na arquitetura física, um namespace dos Hubs de Eventos é executado em um cluster. Um cluster fornece os recursos de computação e armazenamento subjacentes. A maioria dos namespaces é executada em clusters que outros clientes do Azure compartilham. Quando você usa a camada Premium, o namespace é alocado recursos dedicados em um cluster compartilhado. Quando você usa a camada Dedicada, um cluster é dedicado aos seus namespaces. Para obter mais informações sobre clusters dedicados, consulte a visão geral da camada dedicada dos Hubs de Eventos. Independentemente do tipo de camada e cluster, a Microsoft gerencia os clusters e suas máquinas virtuais e armazenamento subjacentes.

Para obter redundância, cada cluster tem várias réplicas que processam solicitações de leitura e gravação. Para otimização de desempenho e alta disponibilidade, todos os dados são armazenados em três réplicas de armazenamento. Para dimensionar os recursos de computação do namespace, implante TUs (unidades de taxa de transferência), PUs (unidades de processamento) ou CUs (unidades de capacidade), dependendo da camada. Para obter mais informações, consulte Dimensionamento com Hubs de Eventos.

Os clusters abrangem vários computadores físicos e racks, o que reduz o risco de falhas catastróficas que afetam seu namespace. Em regiões que têm zonas de disponibilidade, os clusters se estendem entre datacenters físicos separados. Para obter mais informações, consulte Resiliência a falhas de zona de disponibilidade.

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, confira Recomendações para tratamento de falhas transitórias.

Os Hubs de Eventos implementam mecanismos transparentes de detecção de falhas e failover para que o serviço continue operando dentro dos níveis de serviço garantidos, normalmente sem interrupções perceptíveis quando ocorrem falhas.

Ao projetar aplicativos cliente para trabalhar com Hubs de Eventos, siga estas diretrizes:

• Use políticas de repetição integradas. Os SDKs dos Hubs de Eventos e do Apache Kafka repetem automaticamente as operações para erros passíveis de nova tentativa, como tempos limite de rede, respostas de limitação de taxa ou quando o servidor está ocupado. Para evitar sobrecarregar desnecessariamente o serviço, eles implementam a retirada exponencial por padrão.

• Configure valores de tempo limite apropriados com base nos requisitos do aplicativo. O tempo limite padrão normalmente é de 60 segundos, mas você pode ajustá-lo com base em seu cenário.

• Implemente o ponto de verificação no processador de eventos para acompanhar o progresso e habilitar a recuperação da última posição processada após falhas transitórias.

• Use o envio em lote para operações de envio para melhorar a taxa de transferência e reduzir o impacto de problemas transitórios de rede em mensagens individuais.

• Use os SDKs do Apache Kafka se você trabalhar com o protocolo Kafka. Os SDKs do Kafka também implementam políticas de repetição e outras práticas recomendadas que ajudam a lidar com falhas transitórias.

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 passar para uma das zonas restantes.

Os Hubs de Eventos dão suporte a implantações com redundância de zona em todas as camadas de serviço. Quando você cria um namespace dos Hubs de Eventos em uma região com suporte, a redundância de zona é habilitada automaticamente sem custo adicional. No entanto, com a camada Dedicada, as zonas de disponibilidade têm suporte apenas com um mínimo de três CUs. O modelo de implantação com redundância de zona se aplica a todos os recursos dos Hubs de Eventos, incluindo o suporte ao protocolo Capture, Schema Registry e Kafka.

Os Hubs de Eventos replicam de forma transparente seus dados de configuração, metadados e eventos em três zonas de disponibilidade na região. A redundância de zona fornece failover automático sem nenhuma intervenção necessária por parte do usuário. Todos os componentes dos Hubs de Eventos, incluindo computação, rede e armazenamento, são replicados entre zonas. Os Hubs de Eventos têm reservas de capacidade suficientes para lidar instantaneamente com a perda completa de uma zona. Mesmo que toda uma zona de disponibilidade fique indisponível, os Hubs de Eventos continuarão operando sem perda de dados ou interrupção em aplicativos de streaming.

Suporte de regiões

Namespaces de Hubs de Eventos com redundância de zona podem ser implantados em qualquer região do Azure que dê suporte a zonas de disponibilidade.

Requirements

• As camadas Standard e Premium dão suporte a zonas de disponibilidade sem a necessidade de configuração adicional.

• Para a camada Dedicada, as zonas de disponibilidade exigem um mínimo de três CUs.

Custo

A redundância de zona nos Hubs de Eventos não adiciona custo extra.

Configurar o suporte à zona de disponibilidade

Os namespaces dos Hubs de Eventos dão suporte automaticamente à redundância de zona quando implantados em regiões com suporte. Nenhuma configuração adicional é necessária.

Comportamento quando todas as zonas estão saudáveis

Quando os namespaces dos Hubs de Eventos usam redundância de zona e todas as zonas de disponibilidade operam normalmente, espere o seguinte comportamento:

• Roteamento de tráfego entre zonas: Os Hubs de Eventos operam em um modelo ativo-ativo em que a infraestrutura em três zonas de disponibilidade processa simultaneamente eventos de entrada.

• Replicação de dados entre zonas: Os Hubs de Eventos usam replicação síncrona entre zonas de disponibilidade. Quando um produtor de eventos envia um evento, os Hubs de Eventos gravam em réplicas em várias zonas antes de reconhecer ao cliente que a operação de gravação está concluída. Essa abordagem garante a perda de dados zero, mesmo que uma zona inteira fique indisponível. A abordagem de replicação síncrona fornece fortes garantias de consistência, mantendo a baixa latência por meio de protocolos de replicação otimizados.

Comportamento durante uma falha de zona

Quando os namespaces dos Hubs de Eventos usam redundância de zona e ocorre uma interrupção de zona de disponibilidade, espere o seguinte comportamento:

• Detecção e resposta: Os Hubs de Eventos são responsáveis por detectar automaticamente uma falha em uma zona de disponibilidade. Você não precisa iniciar um failover de zona.

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

• Solicitações ativas: Durante uma falha de zona, os Hubs de Eventos podem remover solicitações ativas. 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: Nenhuma perda de dados ocorre durante uma falha de zona porque os Hubs de Eventos replicam eventos de forma síncrona entre zonas antes da confirmação.

• Tempo de inatividade esperado: Uma falha de zona pode causar alguns segundos de tempo de inatividade. 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.

• Redirecionamento de tráfego: Event Hubs detectam a perda da zona e redirecionam automaticamente novas solicitações para outra réplica em uma das zonas de disponibilidade saudáveis.

  Os SDKs de cliente dos Hubs de Eventos normalmente lidam com o gerenciamento de conexões e a lógica de repetição de forma transparente.

Recuperação de zona

Quando uma zona de disponibilidade é recuperada, os Hubs de Eventos reinserem automaticamente a zona na topologia de serviço ativa. A zona recuperada começa a aceitar novas conexões e processar eventos ao lado das outras zonas. Os dados que foram replicados para zonas sobreviventes durante a interrupção permanecem intactos e a replicação síncrona normal é retomada em todas as zonas. Você não precisa tomar medidas para recuperação e reintegração de zona.

Testar falhas em zonas

Como os Hubs de Eventos gerenciam totalmente o roteamento de tráfego, o failover e a recuperação de zona para falhas de zona, você não precisa validar os processos de falha da zona de disponibilidade ou fornecer qualquer entrada adicional.

Resiliência a falhas em toda a região

Os Hubs de Eventos fornecem dois tipos de suporte para várias regiões:

• A replicação geográfica (camadas de serviço Premium e Dedicada) fornece replicação ativa-ativa de metadados e dados de eventos entre uma região primária e uma ou mais regiões secundárias. Use a replicação geográfica para a maioria dos aplicativos que precisam permanecer resilientes a interrupções de região e têm baixa tolerância à perda de dados de eventos.

• A recuperação de desastre geográfico de metadados (camadas de serviço Standard e superiores) fornece replicação ativo-passivo de configuração e metadados entre uma região primária e uma região secundária, mas não replica dados de eventos. Use a recuperação de desastre geográfico para aplicativos que podem tolerar alguma perda de dados de eventos durante um cenário de desastre e que precisam retomar rapidamente as operações em outra região.

A replicação geográfica e a recuperação de desastre geográfico de metadados exigem que você inicie manualmente o failover ou promova uma região secundária para torná-la a nova região primária. A Microsoft não realiza failover ou promoção automaticamente, mesmo que a região primária esteja inoperante.

Geo-replication

As camadas Premium e Dedicada dão suporte à replicação geográfica. Esse recurso replica metadados (como entidades, configuração e propriedades) e dados (como cargas de evento) para o namespace. Você configura a abordagem de replicação para a configuração do namespace e os dados de evento. Esse recurso garante que seus eventos permaneçam disponíveis em outra região e permite que você alterne para a região secundária quando necessário. Ele também replica os metadados e os dados do registro de esquema.

Use a replicação geográfica para cenários que exigem resiliência para interrupções de região e têm uma tolerância baixa para perda de dados de eventos.

O namespace se estende essencialmente entre regiões. Uma região serve como primária e as outras regiões servem como secundárias. Sua assinatura do Azure mostra um único namespace, não importa quantas regiões secundárias você configure para replicação geográfica.

A qualquer momento, você pode promover uma região secundária para uma região primária. Quando você promove uma região secundária, os Hubs de Eventos redirecionam o FQDN (nome de domínio totalmente qualificado) do namespace para a região secundária selecionada e rebaixam a região primária anterior para uma região secundária. Você decide se deseja executar uma promoção planejada, o que significa que você aguarda a conclusão da replicação de dados ou uma promoção forçada, o que pode resultar em perda de dados.

Esta seção resume aspectos importantes da replicação geográfica. Examine a documentação completa para entender exatamente como ela funciona. Para obter mais informações, consulte a replicação geográfica dos Hubs de Eventos.

Suporte de regiões

Você pode escolher qualquer região do Azure que dê suporte aos Hubs de Eventos como sua região primária ou regiões secundárias. Você não precisa usar regiões emparelhadas do Azure, portanto, pode escolher regiões secundárias com base em seus requisitos de latência, conformidade ou residência de dados.

Requirements

Para habilitar a replicação geográfica, seu namespace deve usar a camada Premium ou Dedicada.

Considerações

Ao habilitar a replicação geográfica, considere os seguintes fatores:

• Formato de ponto de verificação: O formato dos pontos de verificação muda. Para obter mais informações, consulte Replicação geográfica: Consumindo dados.

• Pontos de extremidade privados: Se você usar pontos de extremidade privados para se conectar ao namespace, também precisará configurar a rede em suas regiões primárias e secundárias. Para obter mais informações, veja Pontos de extremidade privados.

Custo

Para entender como os preços funcionam para replicação geográfica, consulte Preços.

Configurar o suporte a várias regiões

• Habilite a replicação geográfica em um namespace novo ou existente. Para configurar a replicação ativa-ativa para um namespace recém-criado, consulte Ativar replicação geográfica em um novo namespace. Para configurar a replicação ativa-ativa em um namespace existente, consulte Ativar a replicação geográfica em um namespace existente.

• Altere a abordagem de replicação. Para alterar entre os modos de replicação síncrona e assíncrona, consulte Alternar modo de replicação.

• Desabilite a replicação geográfica. Para desabilitar a replicação geográfica em uma região secundária, consulte Remover uma região secundária.

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

Esta seção descreve o que esperar quando um namespace dos Hubs de Eventos é configurado para replicação geográfica e a região primária está operacional.

• Roteamento de tráfego entre regiões: Os aplicativos cliente se conectam por meio do FQDN para seu namespace e suas rotas de tráfego para a região primária.

  Somente a região primária processa ativamente eventos de clientes durante operações normais. A região secundária recebe eventos replicados, mas, caso contrário, permanece passiva no modo de espera.

• Replicação de dados entre regiões: O comportamento de replicação de dados entre as regiões primária e secundária depende de você configurar o emparelhamento de replicação para usar a replicação síncrona ou assíncrona.

  • Síncrono: Os eventos são replicados para a região secundária antes da conclusão da operação de gravação.

    Esse modo fornece a maior garantia de que os dados do evento são seguros, porque eles devem ser confirmados nas regiões primária e secundária. No entanto, a replicação síncrona aumenta substancialmente a latência de gravação para eventos de entrada. Também requer que a região secundária esteja disponível para aceitar a operação de gravação, portanto, uma interrupção em qualquer região secundária faz com que a operação de gravação falhe.

    • Assíncrono: Os eventos são gravados na região primária e, em seguida, a operação de gravação é concluída. Pouco tempo depois, ele replica os eventos para a região secundária.

    Esse modo fornece uma taxa de transferência de gravação maior do que a replicação síncrona porque não há latência de replicação entre regiões durante operações de gravação. Além disso, o modo de replicação assíncrona pode tolerar a perda de uma região secundária enquanto ainda permite operações de gravação na região primária. No entanto, se a região primária tiver uma interrupção, todos os dados que ainda não foram replicados para a região secundária poderão estar indisponíveis ou perdidos.

    Ao configurar a replicação assíncrona, você configura o tempo máximo de retardo aceitável para a replicação. A qualquer momento, você pode verificar o atraso de replicação atual usando as métricas do Azure Monitor.

    Se o atraso de replicação assíncrona aumentar além do máximo que você especificar, a região primária começará a limitar as solicitações de entrada para que a replicação possa ser atualizada. Para evitar essa situação, é importante selecionar regiões secundárias que não estejam muito distantes geograficamente e garantir que a sua capacidade seja suficiente para a taxa de transferência.

    Para obter mais informações, consulte os modos de replicação.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando um namespace dos Hubs de Eventos é configurado para replicação geográfica e há uma interrupção na região primária ou secundária.

• Detecção e resposta: Você é responsável por decidir quando promover a região secundária do namespace para se tornar a nova região primária. A Microsoft não toma essa decisão nem inicia o processo para você, mesmo que haja uma interrupção na região. Para obter mais informações sobre como promover uma região secundária para a nova principal, consulte a seção Promover secundária.

  Ao promover uma região secundária, escolha se deseja realizar uma promoção planejada ou uma promoção forçada. Uma promoção planejada aguarda que a região secundária se atualize antes de aceitar o novo tráfego. Essa abordagem elimina a perda de dados, mas introduz o tempo de inatividade.

  Interrupções na região primária normalmente tornam necessário realizar uma promoção forçada. Se a região primária estiver disponível e você iniciar uma promoção por uma razão diferente, poderá optar por uma promoção planejada.

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

  Use essas informações e outras métricas para decidir quando promover uma região secundária para uma região primária.

• Solicitações ativas: O comportamento depende se a interrupção da região ocorre na região primária ou em uma região secundária:

  • Interrupção da região primária: Se a região primária não estiver disponível, todas as solicitações ativas serão encerradas. Os aplicativos cliente devem repetir as operações após a conclusão da promoção.

  • Interrupção de região secundária: Uma interrupção na região secundária pode causar problemas para solicitações ativas nas seguintes situações:

    • Se você usar o modo de replicação síncrona, a região primária não poderá concluir as operações de gravação se qualquer região secundária não estiver disponível.

    • Se você usar o modo de replicação assíncrono, o namespace limitará e não aceitará novos eventos depois que o atraso de replicação atingir o máximo configurado.

    Para continuar usando o namespace na região primária, remova o namespace secundário da configuração de replicação geográfica.

• Perda de dados esperada: A quantidade de perda de dados depende do tipo de promoção que você executa (planejada ou forçada) e do modo de replicação (síncrono ou assíncrono):

  • Promoção planejada: Nenhuma perda de dados é esperada. No entanto, durante uma interrupção de região, uma promoção planejada pode não ser possível porque exige que todas as regiões primárias e secundárias estejam disponíveis.

  • Promoção forçada, replicação síncrona: Nenhuma perda de dados é esperada.

  • Promoção forçada, replicação assíncrona: Você pode ter alguma perda de dados para eventos recentes que não são replicados para a região secundária. O valor depende do atraso de replicação. Para verificar o atraso de replicação atual, use as métricas do Azure Monitor.

  Se você executar uma promoção forçada, não poderá recuperar os dados perdidos, mesmo depois que a região primária estiver disponível.

• Tempo de inatividade esperado: A quantidade de tempo de inatividade esperada depende de você executar uma promoção planejada ou forçada:

  • Promoção planejada: A primeira etapa em uma promoção planejada replica dados para a região secundária. Esse processo geralmente é concluído rapidamente, mas em algumas situações, pode levar até o comprimento do atraso de replicação. Após a conclusão da replicação, o processo de promoção normalmente leva cerca de 5 a 10 minutos. Às vezes, pode levar mais tempo para os servidores DNS (Sistema de Nomes de Domínio) atualizarem as entradas e replicarem totalmente seus registros para os clientes.

    A região primária não aceita operações de gravação durante todo o processo de promoção.

    Essa opção pode não ser possível durante uma interrupção de região porque exige que todas as regiões primárias e secundárias estejam disponíveis.

  • Promoção forçada: Durante uma promoção forçada, os Hubs de Eventos não esperam a replicação de dados ser concluída e iniciam a promoção imediatamente. O processo de promoção normalmente leva cerca de 5 a 10 minutos. Às vezes, pode levar mais tempo para que as entradas DNS sejam totalmente replicadas e atualizadas entre clientes.

    A região primária não aceita operações de gravação durante todo o processo de promoção.

• Redirecionamento de tráfego: Após a conclusão da promoção, o FQDN do namespace aponta para a nova região primária. Mas esse redirecionamento depende da rapidez com que os registros DNS dos clientes são atualizados, inclusive para que seus servidores DNS honrem o TTL (tempo de vida útil) dos registros DNS do namespace.

  Em algumas situações, você deve configurar aplicativos de consumidor para se comportarem de forma consistente após a promoção da região. Para obter mais informações, consulte Replicação geográfica: Consumindo dados.

Recuperação de região

Depois que a região primária original for recuperada, se você quiser retornar o namespace para sua região primária original, siga o mesmo processo de promoção de região.

Se você realizou uma promoção forçada durante a interrupção da região, não poderá recuperar dados perdidos, mesmo após a região primária ficar disponível.

Teste de falhas na região

Para testar a replicação geográfica, promova temporariamente a região secundária para primária e valide se os aplicativos cliente podem alternar entre regiões com interrupção mínima.

Monitore a duração da promoção e valide se os seus runbooks e automação funcionam corretamente. Após o teste, você pode fazer failback para a configuração original.

Entenda o tempo de inatividade potencial e a perda de dados que você pode experimentar durante e após o processo de promoção. Teste a replicação geográfica em um ambiente de não produção que espelha a configuração do namespace de produção.

Recuperação de desastres geográficos de metadados

As camadas Standard e superiores oferecem suporte à recuperação de desastres geográficos de metadados. Esse recurso melhora a recuperação de cenários de desastre, incluindo a perda catastrófica de uma região. A recuperação de desastres geográficos replica apenas a configuração e os metadados do seu namespace. No entanto, ele não replica dados de evento. Para dar suporte à recuperação de desastre, esse recurso garante que um namespace em outra região esteja pré-configurado e pronto para aceitar eventos imediatamente de clientes. A recuperação de desastre geográfico serve como uma solução de recuperação unidirecional e não dá suporte ao retorno para a região primária anterior.

A recuperação de desastre geográfico de metadados funciona melhor para aplicativos que não precisam estritamente manter todos os eventos e podem tolerar alguma perda de dados durante um cenário de desastre. Por exemplo, se os eventos representam leituras de sensor que você vai agregar posteriormente, você pode decidir que pode eventualmente perder alguns eventos de uma região com falha, desde que possa retomar rapidamente o processamento de novos eventos em outra região.

Ao configurar a recuperação de desastre geográfico de metadados, você cria um alias ao qual os aplicativos cliente se conectam. O alias é um FQDN que direciona todo o tráfego para o namespace primário por padrão.

Se a região primária falhar ou houver outro tipo de desastre, você poderá iniciar manualmente uma movimentação de failover unidirecional de tempo único da região primária para a secundária a qualquer momento. O failover é concluído quase instantaneamente. Durante o processo de failover, o alias de recuperação de desastre geográfico é redirecionado para o namespace secundário e o emparelhamento é desfeito.

Esta seção resume aspectos importantes da recuperação de desastre geográfico. Examine a documentação completa para entender exatamente como ela funciona. Para obter mais informações, consulte a recuperação de desastre geográfico dos Hubs de Eventos.

Suporte de regiões

Você pode selecionar qualquer região do Azure que dê suporte aos Hubs de Eventos como seu namespace primário ou secundário. Você não precisa usar regiões emparelhadas do Azure, portanto, pode escolher regiões secundárias com base em seus requisitos de latência, conformidade ou residência de dados.

Requirements

• Camada de namespace principal: Seu namespace primário deve estar na camada Standard ou superior para usar a recuperação de desastres geográficos de metadados.

• Camada de namespace secundária: A recuperação de desastres geográficos de metadados dá suporte a combinações específicas de camadas para o namespace primário e secundário. Para obter mais informações, consulte pares de namespace com suporte.

Considerações

• Atribuições de função: As atribuições de RBAC (controle de acesso baseado em função) do Microsoft Entra para entidades no namespace primário não são replicadas para o namespace secundário. Crie atribuições de função manualmente no namespace secundário para proteger o acesso a elas.

• Registro de esquema: os metadados do registro de esquema são replicados quando você usa a recuperação de desastre geográfico de metadados, mas os esquemas registrados no registro de esquema não são replicados.

• Design do aplicativo: A recuperação de desastre geográfico requer considerações específicas ao projetar seus aplicativos cliente. Para obter mais informações, confira as Considerações.

• Pontos de extremidade privados: Se você usar pontos de extremidade privados para se conectar ao namespace, configure a rede na região primária e secundária. Para obter mais informações, veja Pontos de extremidade privados.

Custo

Quando você habilita a recuperação de desastre geográfico de metadados, você paga pelos namespaces primário e secundário.

Configurar o suporte a várias regiões

• Criar emparelhamento de metadados para recuperação de desastres geográficos. Para configurar a recuperação de desastre entre namespaces primários e secundários, consulteFluxo de instalação e failover.

• Desabilite a recuperação de desastre geográfico de metadados. Para interromper o emparelhamento entre namespaces, consulte Configuração e processo de failover.

Planejamento e gerenciamento de capacidade

Quando você planeja implantações de várias regiões, verifique se ambas as regiões têm capacidade suficiente para lidar com a carga completa se uma região falhar. A região secundária permanece passiva durante as operações normais, mas deve lidar imediatamente com o tráfego após o failover. Planeje como dimensionar a capacidade do namespace secundário para que ele possa receber tráfego de produção sem demora. Se você puder tolerar tempo de inatividade extra durante o processo de failover, poderá optar por dimensionar a capacidade do namespace secundário durante ou após o failover. Para reduzir o tempo de inatividade, provisione a capacidade no namespace secundário com antecedência para que ele permaneça pronto para receber a carga de produção.

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

Esta seção descreve o que esperar quando um namespace dos Hubs de Eventos é configurado para recuperação de desastre geográfico e a região primária está operacional.

• Roteamento de tráfego entre regiões: Os aplicativos cliente se conectam por meio do alias de recuperação geográfica de desastres para seu namespace, e o tráfego deles é direcionado para o namespace primário na região primária.

  Somente o namespace primário processa ativamente eventos de clientes durante operações normais. O namespace secundário permanece passivo no modo de espera e todas as solicitações para acessar dados falham.

• Replicação de dados entre regiões: Somente os metadados de configuração são replicados entre os namespaces. A replicação da configuração ocorre de forma contínua e assíncrona.

  Todos os dados de evento permanecem apenas no namespace primário e não são replicados para o namespace secundário.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando um namespace dos Hubs de Eventos é configurado para recuperação de desastres geográficos e ocorre uma interrupção na região primária.

• Detecção e resposta: você é responsável por monitorar a integridade da região e iniciar o failover manualmente. A Microsoft não executa failover nem promove uma região secundária automaticamente, mesmo que sua região primária esteja inoperante.

  Para obter mais informações sobre como iniciar o failover, consulte Manual failover.

  O failover é uma operação unidirecional, então é necessário reestabelecer o emparelhamento de recuperação de desastre geográfico posteriormente. Para obter mais informações, consulte Recuperação de Região.

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

  Use essas informações e outras métricas para decidir quando fazer failover para a região secundária.

• Solicitações ativas: As solicitações ativas em andamento terminam quando o failover é iniciado. Os aplicativos cliente devem repetir as operações após a conclusão do failover.

• Perda de dados esperada:

  • Metadados: Normalmente, a configuração e os metadados são replicados para o namespace secundário. Mas a replicação de metadados ocorre de forma assíncrona, portanto, alterações recentes podem não ser replicadas, especialmente alterações complexas. Verifique a configuração do namespace secundário antes que os clientes o acessem.

  • Dados do evento: Os dados do evento não são replicados entre regiões. Se a região primária falhar, os eventos no namespace primário ficarão indisponíveis.

    Os eventos não são permanentemente perdidos, a menos que um desastre catastrófico cause perda total da região primária. Se a região se recuperar, você poderá recuperar eventos do namespace primário mais tarde.

• Tempo de inatividade esperado: O failover normalmente ocorre dentro de 5 a 10 minutos. Pode levar mais tempo para os clientes replicarem e atualizarem totalmente as entradas DNS.

• Redirecionamento de tráfego: Clientes que usam o alias de recuperação geográfica de desastres para se conectar ao namespace redirecionam-se automaticamente para o namespace secundário após o failover. Mas esse redirecionamento depende de servidores DNS que respeitam a TTL dos registros DNS do namespace e clientes que recebem esses registros DNS atualizados.

Recuperação de região

Depois que a região primária original for recuperada, você deverá restabelecer manualmente o emparelhamento e, opcionalmente, fazer failback. Crie um novo emparelhamento de recuperação de desastre geográfico com a região recuperada como secundária e execute outro failover se desejar retornar à região original. Esse processo envolve a potencial perda de dados dos eventos enviados para o primário temporário.

Se o desastre causar a perda de todas as zonas na região primária, seus dados poderão ser irrecuperáveis. Em outros cenários, os dados do evento permanecem no namespace primário e continuam recuperáveis mesmo após o failover. Você pode obter eventos históricos do namespace primário antigo depois de restaurar o acesso. Você é responsável por configurar seus aplicativos para receber e processar esses eventos. A Microsoft não os restaura automaticamente em sua região secundária.

Teste de falhas na região

Para testar seus processos de resposta e recuperação de desastre, execute um failover planejado durante uma janela de manutenção. Inicie o failover do namespace primário para o namespace secundário e certifique-se de que seus aplicativos podem se conectar e processar eventos do novo primário.

Monitore a duração do failover e valide se os runbooks e automação funcionam corretamente. Após o teste, você pode fazer failback para a configuração original.

Entenda o tempo de inatividade potencial e a perda de dados que você pode experimentar durante e após o processo de failover. Teste a replicação geográfica em um ambiente de não produção que espelha a configuração do namespace de produção.

Soluções personalizadas de várias regiões para resiliência

A replicação geográfica e a recuperação de desastres geográficos de metadados fornecem resiliência a interrupções de região e outros problemas e dão suporte à maioria das cargas de trabalho. Algumas camadas de Hubs de Eventos não dão suporte a esses recursos ou você pode exigir replicação personalizada ou precisar manter várias regiões ativas simultaneamente.

Vários padrões de design podem obter diferentes tipos de suporte de várias regiões nos Hubs de Eventos. Muitos dos padrões exigem a implantação de vários namespaces e o uso de serviços como o Azure Functions para replicar eventos entre eles. Para obter mais informações, consulte Federação de múltiplos sites e regiões.

Backup e restauração

Os Hubs de Eventos não foram projetados como um local de armazenamento de longo prazo para seus dados. Normalmente, você armazena dados em um hub de eventos por um curto período de tempo e, em seguida, processa-os ou os persiste em outro sistema de armazenamento de dados. Você pode configurar o período de retenção de dados para o hub de eventos com base em seus requisitos e na camada que o namespace usa. Para obter mais informações, confira Retenção de eventos.

Se você precisar manter uma cópia de seus eventos, considere usar a Captura de Hubs de Eventos, que salva cópias de eventos em uma conta de Armazenamento de Blobs do Azure.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O SLA de disponibilidade do namespace é maior quando usa as camadas Premium ou Dedicada.

Conteúdo relacionado

• Documentação dos Hubs de Eventos
• Visão geral da confiabilidade do Azure