Fiabilidade nos Hubs de Eventos do Azure

O Azure Event Hubs é um serviço nativo na cloud que pode transmitir milhões de eventos por segundo com baixa latência, de qualquer fonte para qualquer destino. Use Hubs de Eventos para ingerir e armazenar dados de streaming e integre-se a aplicativos cliente criados para Apache Kafka ou aplicativos que usam os SDKs de cliente de Hubs de Eventos.

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 o Event Hubs é resiliente a uma variedade de potenciais interrupções e problemas, e como pode configurá-lo para ser resistente a outros, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Descreve também as opções de backup e recuperação, e destaca algumas informações-chave sobre o acordo de nível de serviço (SLA) dos Azure Event Hubs.

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

Para saber como implantar Hubs de Eventos para dar suporte aos requisitos de confiabilidade da sua solução e entender como a confiabilidade afeta outros aspetos da sua arquitetura, consulte 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 aspetos importantes sobre como os Hubs de Eventos funcionam de uma perspetiva de confiabilidade. Ele apresenta a arquitetura lógica, que inclui recursos e funcionalidades que se implantam e utilizam. 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 de Hubs de Eventos serve como 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 da rede e habilitar a resiliência geográfica e a recuperação de desastres geográficos, no nível do namespace.

Dentro de um namespace, você pode organizar eventos em um hub de eventos. O ecossistema Apache® Kafka refere-se a este tipo de entidade como um tópico. O hub ou tópico de eventos é um log distribuído somente de acréscimo de 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 processamento paralelo e dimensionamento horizontal. Os Hubs de Eventos garantem apenas a encomenda dentro de uma única partição. O particionamento desempenha um papel fundamental no design de confiabilidade do seu aplicativo. Ao projetar seu aplicativo, faça um compromisso entre maximizar a disponibilidade e a consistência. Para maximizar o tempo de atividade para a maioria das aplicações, evite aceder a partições diretamente das suas aplicações cliente. Para obter mais informações, consulte Disponibilidade e consistência em Hubs de Eventos.

Os consumidores que leem a partir 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 em Hubs de Eventos, consulte Recursos e terminologia em Hubs de Eventos.

Arquitetura física

Na arquitetura física, um namespace de Hubs de Eventos é executado dentro de 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 recebe 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 Visão geral da camada dedicada dos Hubs de Eventos. Independentemente da camada e do tipo de 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 alta disponibilidade e otimização de desempenho, todos os dados são armazenados em três réplicas de armazenamento. Para dimensionar os recursos de computação do namespace, implante unidades de taxa de transferência (TUs), unidades de processamento (PUs) ou unidades de capacidade (CUs), dependendo da camada. Para obter mais informações, consulte Dimensionamento com Hubs de Eventos.

Os clusters abrangem várias máquinas físicas e racks, o que reduz o risco de falhas catastróficas que afetam seu namespace. Em regiões com zonas de disponibilidade, os clusters se estendem por datacenters físicos separados. Para mais informações, veja Resiliência a falhas em zonas de disponibilidade.

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.

Os Hubs de Eventos implementam mecanismos transparentes de deteção de falhas e failover para que o serviço continue a operar dentro dos níveis de serviço garantidos, normalmente sem interrupções percetí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 Hubs de Eventos e os SDKs do Apache Kafka repetem de forma automática as operações para erros recuperáveis, como tempos limite de rede, respostas de restrição, ou quando o servidor está sobrecarregado. Para evitar sobrecarregar desnecessariamente o serviço, eles implementam backoff exponencial por padrão.

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

• Implemente o ponto de verificação no processador de eventos para acompanhar o progresso e permitir 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 de rede transitórios em mensagens individuais.

• Use Apache Kafka SDKs se você trabalha 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 na zona de disponibilidade

As 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.

Os Hubs de Eventos oferecem suporte a implantações com redundância de zona em todas as camadas de serviço. Quando você cria um namespace de Hubs de Eventos em uma região com suporte, a redundância de zona é habilitada automaticamente sem custo extra. Mas com a camada Dedicada, as zonas de disponibilidade são suportadas apenas com um mínimo de três CUs. O modelo de implantação com redundância de zona aplica-se a todos os recursos de Hubs de Eventos, incluindo Captura, Registro de Esquema e suporte ao protocolo Kafka.

Os Hubs de Eventos replicam de forma transparente sua configuração, metadados e dados de eventos em três zonas de disponibilidade na região. A redundância de zona fornece failover automático sem necessitar de qualquer intervenção da sua parte. 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 a operar sem perda de dados ou interrupção de aplicativos de streaming.

O diagrama mostra um cluster de Hubs de Eventos distribuído em três zonas de disponibilidade. Cada zona contém um namespace compartilhado e o cluster abrange todas as zonas para fornecer alta disponibilidade.

Suporte de região

Os namespaces de Hubs de Eventos com redundância de zona podem ser implantados em qualquer região do Azure que ofereça suporte a zonas de disponibilidade.

Requerimentos

• Os níveis Standard e Premium suportam zonas de disponibilidade sem necessidade de configuração extra.

• 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 oferecem suporte automático à redundância de zona quando implantados em regiões com suporte. Não é necessário efetuar mais configurações.

Comportamento quando todas as zonas estão íntegras

Quando os namespaces de 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 os 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, o Hub de Eventos grava-o em réplicas em várias zonas antes de confirmar ao cliente que a operação de gravação está concluída. Essa abordagem garante perda zero de dados, mesmo se uma zona inteira ficar indisponível. A abordagem de replicação síncrona oferece fortes garantias de consistência e, ao mesmo tempo, mantém 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 da zona de disponibilidade, espere o seguinte comportamento:

• Deteção e resposta: Os Hubs de Eventos são responsáveis por detetar automaticamente uma falha em uma zona de disponibilidade. Não é necessário iniciar um failover de zona.

• Notificação: a Microsoft não o notifica 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 sobre problemas.

• Solicitações ativas: Durante uma falha de zona, os Hubs de Eventos podem descartar 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.

• Reencaminhamento do tráfego: Os Hubs de Eventos detetam a perda da zona e redirecionam automaticamente novas solicitações para outra réplica em uma das zonas de disponibilidade íntegra.

  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 reintegram 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.

Teste de falhas de zona

Os Hubs de Eventos gerem o roteamento de tráfego, o failover e a recuperação de zona em caso de falhas de zona, portanto, não é necessário validar processos de falha de zona de disponibilidade ou fornecer informações adicionais.

Resiliência a falhas em toda a região

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

• A replicação geográfica (níveis Premium e Dedicado) 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 geográfica de desastres de metadados (nível padrão e superiores) fornece replicação ativa-passiva de configuração e metadados entre uma região primária e secundária, mas não replica dados de eventos. Use a recuperação de desastres geográficos 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.

Tanto a replicação geográfica quanto a recuperação de desastres geográficos de metadados exigem que você inicie manualmente o failover ou a promoção de uma região secundária para se tornar a nova região primária. A Microsoft não executa automaticamente failover ou promoção, mesmo que sua região principal esteja inativa.

Georreplicação

Os níveis Premium e Dedicated suportam replicação geográfica. Esse recurso replica metadados (como entidades, configuração e propriedades) e dados (como cargas úteis de eventos) para o namespace. Você configura a abordagem de replicação para a configuração do namespace e os dados de eventos. 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 metadados e dados do registro de esquema.

Use a replicação geográfica para cenários que exigem resiliência a interrupções de região e têm baixa tolerância à 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 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 reapontam 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, que pode resultar em perda de dados.

Observação

A replicação geográfica dos Hubs de Eventos usa o termo promoção porque representa melhor o processo de promover uma região secundária para uma região primária (e depois rebaixar uma região primária para uma região secundária). Você também pode ver o termo failover usado para descrever o processo geral.

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

Suporte de região

Você pode escolher qualquer região do Azure que ofereça suporte a 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.

Requerimentos

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 do 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 finais privados: Se o utilizador usar pontos de extremidade privados para ligar-se ao seu namespace, também precisará configurar a rede de comunicações nas suas regiões principal e secundária. Para obter mais informações, consulte Endereços privados.

Custo

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

Configurar 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 num novo namespace. Para configurar a replicação ativa-ativa num espaço de nomes existente, consulte Ativar replicação geográfica num espaço de nomes existente.

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

• Desative a replicação geográfica. Para desabilitar a replicação geográfica para 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 de 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, de outro modo, permanece passiva no modo de espera.

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

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

    Esse modo fornece a maior garantia de que os dados do evento estão seguros, pois devem ser confirmados na região primária e secundária. No entanto, a replicação síncrona aumenta substancialmente a latência de gravação para eventos de entrada. Ele 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, 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 as 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 e, ao mesmo tempo, permitir operações de gravação na região primária. No entanto, se a região primária tiver uma interrupção, os dados que ainda não foram replicados para a região secundária poderão não estar disponíveis ou perdidos.

    Ao configurar a replicação assíncrona, você configura o tempo de atraso máximo 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 da replicação assíncrona aumentar além do máximo especificado, a região primária começará a limitar as solicitações de entrada para que a replicação possa se atualizar. Para evitar essa situação, é importante selecionar regiões secundárias que não estejam demasiado distantes geograficamente e assegurar que a sua capacidade seja suficiente para a largura de banda.

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

Comportamento durante uma interrupção regional

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

• Deteção e resposta: És responsável por decidir quando promover a região secundária do teu 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 se houver uma interrupção de região. Para obter mais informações sobre como promover uma região secundária para novo primário, consulte Promover Região 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 espera que a região secundária recupere antes de aceitar novo tráfego. Essa abordagem elimina a perda de dados, mas introduz tempo de inatividade.

  Durante uma falha na região principal, geralmente é necessário realizar uma promoção compulsória. Se a região principal estiver disponível e tu acionares uma promoção por outro motivo, poderás escolher uma promoção planificada.

• Notificação: A Microsoft não notifica automaticamente quando uma região está fora de serviço. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

  Use essas informações e outras métricas para decidir quando promover uma região secundária a 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 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 da 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 alguma região secundária não estiver disponível.

    • Se usar o modo de replicação assíncrona, o seu namespace será limitado e não aceita novos eventos quando o lag de replicação atinge o máximo que configurou.

    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íncrona ou assíncrona):

  • Promoção prevista: Nenhuma perda de dados é esperada. No entanto, durante uma interrupção da 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 enfrentar alguma perda de dados para eventos recentes que não são replicados para a região secundária. A quantidade depende do atraso na replicação. Para verificar o atraso de replicação atual, use as métricas do Azure Monitor.

  Caso efetue uma promoção forçada, não pode recuperar dados perdidos, mesmo após a região principal estar disponível.

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

  • Promoção prevista: A primeira etapa de 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 entradas e replicarem totalmente seus registros para os clientes.

    A região principal 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 requer 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 que a replicação de dados seja 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 os clientes.

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

• Reencaminhamento do 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 tempo de vida (TTL) dos registros DNS do namespace.

  Em algumas situações, deve-se configurar as aplicações 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 da região

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

Se realizou uma promoção forçada durante a falha da região, não conseguirá recuperar os dados perdidos, mesmo depois que a região principal se tornar disponível.

Teste para falhas regionais

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 o mínimo de interrupção.

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

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

Recuperação de desastres geográficos de metadados

A camada Padrão e superior suporta 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 eventos. Para dar suporte à recuperação de desastres, esse recurso garante que um namespace em outra região esteja pré-configurado e pronto para aceitar imediatamente eventos de clientes. A recuperação geoespacial de desastres serve como uma solução de recuperação unidirecional e não oferece suporte ao retorno para a região primária prévia.

A recuperação de desastres geográficos 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 representarem leituras do sensor que você agregará posteriormente, você poderá decidir que pode perder alguns eventos de uma região com falha se puder retomar rapidamente o processamento de novos eventos em outra região.

Importante

A recuperação de desastres geográficos permite a continuidade de operações que têm a mesma configuração, mas não replicam dados de eventos. Se você precisar replicar dados de eventos, considere o uso da replicação geográfica.

Ao configurar a recuperação de desastres geográficos 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 principal por padrão.

Se a região primária falhar ou ocorrer outro tipo de desastre, você poderá iniciar manualmente uma mudança de failover unidirecional única da região primária para a região secundária a qualquer momento. O failover é concluído quase instantaneamente. Durante o processo de failover, o alias de recuperação de desastres geográficos reaponta para o namespace secundário e o emparelhamento é removido.

Esta seção resume aspetos importantes da recuperação de desastres geográficos. Consulte a documentação completa para entender exatamente como funciona. Para obter mais informações, consulte Recuperação de desastres geográficos dos Hubs de Eventos.

Suporte de região

Você pode selecionar qualquer região do Azure que ofereça suporte a 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.

Requerimentos

• Camada de namespace principal: Seu namespace principal 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 oferece suporte a combinações específicas de camadas para os namespaces primário e secundário. Para obter mais informações, consulte Pares de namespace suportados.

Considerações

• Atribuições de funções: 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.

• Registo de esquema: Os metadados do Registo de esquema são replicados quando se utiliza a recuperação de desastres geográficos de metadados, mas os esquemas registados no Registo de esquema não são replicados.

• Desenho da aplicação: A recuperação de desastres geográficos requer considerações específicas ao projetar seus aplicativos cliente. Para obter mais informações, consulte Considerações.

• Private endpoints: Se utilizar endpoints privados para se conectar ao seu namespace, configure a rede tanto na região primária como na secundária. Para obter mais informações, consulte Endereços privados.

Custo

Ao habilitar a recuperação de desastres geográficos de metadados, você paga pelos namespaces primário e secundário.

Configurar suporte a várias regiões

• Crie emparelhamento de metadados para recuperação de desastres geográficos. Para configurar a recuperação de desastres entre namespaces principais e secundários, consulte Configuração e fluxo de transferência de serviço.

• Desative a recuperação de metadados em caso de desastres geográficos. Para interromper o emparelhamento entre namespaces, consulte Configuração e fluxo de failover.

Planejamento e gerenciamento de capacidade

Ao planejar implantações em várias regiões, certifique-se de que ambas as regiões tenham capacidade suficiente para lidar com a carga total 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 de Hubs de Eventos é configurado para recuperação de desastres geográficos 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 de desastres geográficos para seu namespace e suas rotas de tráfego 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 de acesso a 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 interrupção regional

Esta secção descreve o que esperar quando um namespace do Event Hubs é configurado para recuperação de desastres geográficos e há uma interrupção na região primária.

• Deteção e resposta: Você é responsável por monitorar a integridade da região e iniciar o failover manualmente. A Microsoft não executa failover ou promove uma região secundária automaticamente, mesmo que a região principal esteja inativa.

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

  O failover é uma operação unidirecional, portanto, é necessário restabelecer o emparelhamento de recuperação contra desastres geográficos mais tarde. Para obter mais informações, consulte Recuperação de região.

• Notificação: A Microsoft não notifica automaticamente quando uma região está fora de serviço. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

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

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

• Perda de dados esperada:

  • Metadados: A configuração e os metadados normalmente são replicados para o namespace secundário. Mas a replicação de metadados ocorre de forma assíncrona, portanto, as alterações recentes podem não ser replicadas, especialmente as alterações complexas. Verifique a configuração do seu 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 ficar inativa, os eventos em seu namespace principal ficarão indisponíveis.

    Os eventos não são perdidos permanentemente, a menos que uma catástrofe cause perda total da região primária. Se a região se recuperar, você poderá recuperar eventos do namespace principal mais tarde.

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

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

Recuperação da 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 desastres geográficos com a região recuperada como secundária e, em seguida, execute outro failover se quiser retornar à região original. Este processo envolve a potencial perda de dados de 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 podem ser irrecuperáveis. Em outros cenários, os dados do evento permanecem recuperáveis no namespace principal antes de ocorrer 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 na sua região secundária.

Teste para falhas regionais

Para testar seus processos de resposta e recuperação de desastres, execute um failover planejado durante uma janela de manutenção. Inicie o failover do namespace principal para o namespace secundário e verifique se os aplicativos podem se conectar e processar eventos do novo namespace principal.

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

Compreenda o tempo de inatividade potencial e a perda de dados que você pode enfrentar durante e após o processo de failover. Teste a replicação geográfica em um ambiente que não seja de produção que espelhe a configuração do seu 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, além de suportarem a maioria das cargas de trabalho. Algumas camadas de Hubs de Eventos não oferecem suporte a esses recursos, ou você pode precisar de replicação personalizada ou necessidade de manter várias regiões ativas simultaneamente.

Vários padrões de design podem alcançar diferentes tipos de suporte a várias regiões em 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 multissite e multirregião.

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 persiste-os em outro sistema de armazenamento de dados. Você pode configurar o período de retenção de dados para seu hub de eventos com base em seus requisitos e na camada que seu namespace usa. Para obter mais informações, consulte Retenção de eventos.

Se precisar de manter uma cópia dos seus eventos, considere utilizar a Captura de Hubs de Eventos, que guarda cópias de eventos numa conta de Armazenamento de Blobs do Azure.

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 obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

O SLA de disponibilidade do seu namespace é maior quando ele usa as camadas Premium ou Dedicado.

Conteúdo relacionado

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