Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A recuperação de desastres geográficos é uma funcionalidade de recuperação de desastres no Hubs de Eventos do Azure que replica continuamente a configuração do seu espaço de nomes (hubs de eventos, grupos de consumidores e definições) de um espaço de nomes primário para um espaço secundário. Esta funcionalidade permite-lhe iniciar um failover do namespace primário para o secundário durante interrupções regionais.
Nota
Este artigo descreve a funcionalidade de recuperação de desastres geográficos que replica exclusivamente os metadados. Para informações sobre a característica de geo-replicação, que replica tanto dados como metadados, veja Geo-replicação.
O modelo de cluster de 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 toda uma região e todas as zonas não estejam disponíveis, pode usar a recuperação de geo-desastre para recuperar a sua carga de trabalho e configuração da aplicação.
Os conceitos e o fluxo de trabalho descritos neste artigo aplicam-se a cenários de desastre, não a interrupções temporárias. Para uma discussão detalhada sobre recuperação de desastres em Microsoft Azure, veja Disaster recovery for Azure applications. Com a recuperação de desastre geográfico, pode iniciar um único processo de failover do primário para o secundário a qualquer momento. O processo de failover direciona o alias escolhido para o namespace para o namespace secundário. Após a mudança, o par é removido. O failover é quase instantâneo uma vez iniciado.
Importante
- O recurso permite a continuidade instantânea de operações com a mesma configuração, mas não replica os dados do evento. A menos que o desastre tenha causado a perda de todas as zonas, os dados de eventos preservados no hub primário após o failover são recuperáveis e os eventos históricos podem ser obtidos a partir daí assim que o acesso for restaurado. Para replicar dados de eventos e operar namespaces correspondentes em configurações ativas/ativas para lidar com falhas e desastres, não se apoie neste conjunto de funcionalidades de recuperação de desastres geográficos, mas siga as orientações de replicaçã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.
Para configurar o emparelhamento para recuperação geodésica de desastres e iniciar o failover, consulte Configurar recuperação geodésica de desastres.
Conceitos e termos básicos
A funcionalidade de recuperação de desastres implementa a recuperação de desastres de metadados e baseia-se em namespaces primários e secundários de recuperação de desastres. A funcionalidade de recuperação de desastres geográficos está disponível apenas para os níveis padrão, premium e dedicado. Não é necessário fazer alterações na cadeia de conexão, pois a conexão é feita por meio de um alias.
Os seguintes termos são usados neste artigo:
- Alias: o nome de uma configuração de recuperação de desastres que você configurou. O alias fornece uma única cadeia de conexão estável FQDN (Fully Qualified Domain Name). Os aplicativos usam essa cadeia de conexão de alias para se conectar a um namespace.
- Namespace primário/secundário: os namespaces que correspondem ao alias. O namespace primário está ativo e recebe mensagens (pode ser um namespace existente ou novo). O namespace secundário é passivo e não recebe mensagens. Os metadados entre ambos estão sincronizados, para que ambos possam aceitar mensagens sem qualquer código de aplicativo ou alterações na cadeia de conexão. Para garantir que apenas o namespace ativo receba mensagens, você deve usar o alias.
- Metadados: entidades como hubs de eventos e grupos de consumidores e suas propriedades do serviço associadas ao namespace. Somente entidades e suas configurações são replicadas automaticamente. As mensagens e os eventos não são replicados.
- Failover: O processo de ativação do namespace secundário.
Pares de namespace suportados
As seguintes combinações de namespaces primário e secundário são suportadas:
| Camada principal de namespace | Camada de namespace secundária permitida |
|---|---|
| Standard | Padrão, Dedicado |
| Premium | Premium |
| Dedicado | Dedicado |
Importante
Não é possível emparelhar namespaces que estejam no mesmo cluster dedicado. Você pode emparelhar namespaces que estão em clusters separados.
Considerações sobre failover
Ao planear o failover, considere os seguintes pontos:
Por projeto, a recuperação em caso de desastre geográfico dos Event Hubs não replica dados. Portanto, não podes reutilizar o valor antigo de deslocamento do teu hub de eventos principal no hub secundário. Reinicie o seu receptor de eventos usando um dos seguintes métodos:
- EventPosition.FromStart() - Se quiser ler todos os dados no seu hub secundário de eventos.
- EventPosition.FromEnd() - Se quiser ler todos os dados novos desde o momento da ligação ao seu hub secundário de eventos.
- EventPosition.FromEnqueuedTime(dateTime) - Se quiser ler todos os dados recebidos no seu hub secundário de eventos a partir de uma data e hora.
Considere o fator tempo no seu planeamento de recuperação de falhas. Por exemplo, se você perder a conectividade por mais de 15 a 20 minutos, poderá decidir iniciar o failover.
Como nenhum dado é replicado, as sessões ativas atuais não são replicadas. Além disso, a deteção de duplicados e mensagens agendadas podem não funcionar. Novas sessões, mensagens agendadas e novos duplicados funcionam.
Deves ensaiar falhas numa infraestrutura distribuída complexa pelo menos uma vez.
A sincronização de entidades pode levar algum tempo, aproximadamente 50-100 entidades por minuto.
Alguns aspetos do plano de gerenciamento para o namespace secundário tornam-se somente leitura enquanto o emparelhamento de recuperação geográfica está ativo.
O plano de dados do namespace secundário é apenas de leitura enquanto o emparelhamento de recuperação geográfica está ativo. O plano de dados do namespace secundário aceita pedidos GET para permitir a validação da conectividade do cliente e dos controlos de acesso.
Endereços finais privados
Esta secção fornece considerações ao utilizar recuperação de desastres geográficos para namespaces que usam endpoints privados. Para saber mais sobre como usar pontos de extremidade privados com Hubs de Eventos em geral, consulte Configurar pontos de extremidade privados.
Novos emparelhamentos
Se você tentar criar um emparelhamento entre um namespace primário com um ponto de extremidade privado e um namespace secundário sem um ponto de extremidade privado, o emparelhamento falhará. O emparelhamento será bem-sucedido somente se os namespaces primário e secundário tiverem pontos de extremidade privados. Use as mesmas configurações nos namespaces primário e secundário e em redes virtuais onde cria endpoints privados.
Nota
Quando tenta emparelhar o namespace primário com um endpoint privado e um namespace secundário, o processo de validação só verifica se existe um endpoint privado no namespace secundário. Não verifica se o endpoint funciona ou funcionará após o failover. É sua responsabilidade garantir que o namespace secundário com ponto de extremidade privado funcione conforme o esperado após o failover.
Para testar se as configurações dos endpoints privados são as mesmas nos namespaces primários e secundários, envie um pedido de leitura (por exemplo: Get Event Hub) para o namespace secundário a partir de fora da rede virtual e verifique se recebeu uma mensagem de erro do serviço.
Emparelhamentos existentes
Se já existir um emparelhamento entre o namespace primário e o secundário, a criação de endpoints privados no namespace primário falha. Para resolver o erro, crie primeiro um endpoint privado no namespace secundário e depois crie um para o namespace primário.
Nota
Embora possas aceder ao namespace secundário em modo de leitura, podes atualizar as configurações dos endpoints privados.
Configuração recomendada
Quando criar uma configuração de recuperação de desastres para a sua aplicação e para os namespaces dos Event Hubs, crie endpoints privados tanto para os namespaces primários como secundários dos Event Hubs. Estes endpoints privados ligam-se a redes virtuais que alojam tanto instâncias primárias como secundárias da sua aplicação.
Suponha que tem duas redes virtuais, VNET-1 e VNET-2, e estes namespaces primário e secundário: EventHubs-Namespace1-Primary e EventHubs-Namespace2-Secondary. Conclua as seguintes etapas:
- No
EventHubs-Namespace1-Primary, crie dois endpoints privados que utilizem sub-redes deVNET-1eVNET-2 - No
EventHubs-Namespace2-Secondary, crie dois pontos de extremidade privados que usam as mesmas sub-redes deVNET-1eVNET-2
A vantagem desta abordagem é que o failover pode ocorrer na camada de aplicação independentemente do namespace dos Event Hubs. Considere os seguintes cenários:
Failover exclusivo para aplicações: Neste cenário, a aplicação não existe em VNET-1, mas é transferida para VNET-2. Como ambos os endpoints privados estão configurados em ambos VNET-1 e VNET-2 para os namespaces primário e secundário, a aplicação funciona simplesmente.
Failover exclusivo de namespace nos Event Hubs: Neste cenário, como ambos os endpoints privados estão configurados em redes virtuais para namespaces primários e secundários, a aplicação simplesmente funciona.
Nota
Para obter orientação sobre a recuperação de desastres geográficos de uma rede virtual, consulte Rede virtual - Continuidade de negócios.
Controlo de acesso baseado em funções (RBAC)
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.