Confiabilidade nos Hubs de Notificação do Azure
Este artigo descreve o suporte à confiabilidade nos Hubs de Notificação do Azure e aborda a resiliência regional com zonas de disponibilidade, recuperação de desastres e continuidade de negócios
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas duas zonas restantes.
As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.
Em uma região que oferece suporte a zonas de disponibilidade, os Hubs de Notificação oferecem suporte a uma implantação com redundância de zona por padrão. Quando você implanta com zonas de disponibilidade, os dados de registro e os metadados são replicados em todas as zonas da região especificada.
Pré-requisitos
Os Hubs de Notificação do Azure usam zonas de disponibilidade em regiões onde estão disponíveis. Para obter uma lista de regiões que oferecem suporte a zonas de disponibilidade, consulte Serviço de zona de disponibilidade e suporte regional.
As zonas de disponibilidade são suportadas por padrão apenas em camadas específicas. Para saber quais camadas oferecem suporte a implantações de zona de disponibilidade, consulte [Preços dos Hubs de Notificação](https://azure.microsoft.com/pricing/details/notification-hubs.
Melhorias no SLA
O suporte a zonas de disponibilidade incorre em um custo adicional além do preço de nível existente. Para obter mais informações sobre nosso SLA, consulte o SLA dos Hubs de Notificação.
Experiência de zoneamento
Durante uma interrupção em toda a zona, nenhuma ação é necessária durante a recuperação da zona. Os Hubs de Notificação se auto-recuperam e se reequilibram para aproveitar automaticamente a zona íntegra.
Ativar zonas de disponibilidade
Você só pode habilitar zonas de disponibilidade em novos namespaces. Como os Hubs de Notificação não oferecem suporte à migração de namespaces existentes, não é possível desabilitar a redundância de zona depois de habilitá-la em seu namespace.
Para saber como configurar um novo namespace com zonas de disponibilidade, consulte Criar um hub de notificação do Azure no portal do Azure.
Migrar para o suporte à zona de disponibilidade
Para saber como mover um recurso existente dos Hubs de Notificação para uma nova região com suporte à zona de disponibilidade, siga as orientações em Mover recursos entre regiões do Azure.
Recuperação de desastres entre regiões e continuidade de negócios
A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.
Os Hubs de Notificação fornecem cobertura de recuperação de desastres de metadados por meio da replicação entre regiões de metadados, como o nome dos Hubs de Notificação, a cadeia de conexão e outras informações críticas.
Você pode usar a região emparelhada do Azure ou escolher em uma lista de regiões que oferecem suporte à Região de Recuperação Flexível.
Quando um cenário de recuperação de desastres é acionado, os dados de registro são o único segmento da infraestrutura dos Hubs de Notificação que é perdido. Consulte a seção Fazer backup de dados de registro para obter opções para preservar os dados de registro do seu namespace e como restaurá-los.
Região de recuperação flexível
A Região de Recuperação Flexível é uma solução simples que permite configurar um namespace secundário como um destino de failover para seu namespace principal. Você pode escolher na lista de regiões suportadas. No caso de regiões com zonas de disponibilidade, mas sem região emparelhada, você pode usar a recuperação flexível para selecionar uma região secundária. Quando o failover é acionado, o namespace secundário se torna o namespace ativo e o namespace primário se torna o namespace passivo. Todas as solicitações e mensagens enviadas para o namespace primário são redirecionadas para o namespace secundário e as notificações por push são entregues do namespace secundário.
As seguintes regiões suportam a Região de Recuperação Flexível:
- E.U.A. Oeste 2
- Europa do Norte
- Leste da Austrália
- Sul do Brasil
- Ásia Sudeste
- Norte da África do Sul
Fazer backup dos dados de registro
A recuperação de região emparelhada e flexível faz backup apenas de metadados. Você deve implementar uma solução para preencher novamente os dados de registro em seu hub pós-recuperação.
Os Hubs de Notificação do Azure dão suporte a dois tipos de registros de dispositivo: instalações e registros. Recomendamos que faça uma cópia de segurança dos seus registos para:
- Uma solução de armazenamento de sua escolha: se ocorrer um evento de DR, haverá algum tempo de inatividade para atividades de restauração.
- Outro hub que você cria em outra região: use esta opção para fazer backup de seus registros. Como um hub de trabalho, você pode implementar código para alternar para essa cópia. Para manter um hub de notificação secundário sincronizado com o hub de notificação principal, você pode usar uma das seguintes opções para fazer backup de seus registros:
- Para instalações: use um back-end de aplicativo que cria e atualiza simultaneamente instalações em ambos os hubs de notificação. As instalações permitem que você especifique seu próprio identificador de dispositivo exclusivo, tornando-o mais adequado para o cenário de replicação. Para obter mais informações, consulte este código de exemplo.
- Para registros: use um back-end de aplicativo que obtém um despejo regular de registros do hub de notificação principal como backup. Em seguida, ele pode executar uma inserção em massa no hub de notificação secundário. Consulte Exportar e importar registros dos Hubs de Notificação do Azure em massa.
O hub de notificação secundário pode ter registros expirados. Quando o envio por push é feito para um identificador expirado, os Hubs de Notificação limpam automaticamente o registro de registro associado no hub de notificação principal, com base na resposta recebida do servidor PNS. Você pode limpar registros expirados da solução de backup de sua escolha adicionando lógica personalizada que processa comentários de cada envio e remove registros expirados.
Se você não tiver um back-end, quando o aplicativo for iniciado nos dispositivos de destino, os dispositivos executarão um novo registro no hub de notificação secundário. Eventualmente, o hub de notificação secundário terá todos os dispositivos ativos registrados.
Há um período de tempo durante o qual os dispositivos com aplicações não abertas não recebem notificações.
Habilite a recuperação de desastres entre regiões
Para habilitar a recuperação de desastres para um novo namespace, siga o procedimento em Criar um hub de notificação do Azure no portal do Azure.
Para habilitar ou desabilitar a recuperação de desastres para um namespace existente:
Inicie sessão no portal do Azure.
No menu esquerdo, selecione Todos os serviços.
Na seção Internet das Coisas, selecione Namespaces do Hub de Notificação.
Na página Namespaces do Hub de Notificação, selecione o namespace para o qual você deseja modificar as configurações de recuperação de desastre.
Na página Namespace do Hub de Notificação do seu namespace, você pode ver a configuração atual de recuperação de desastres na seção Essentials.
No exemplo a seguir, uma região de recuperação flexível está habilitada. Clique na seleção de região de recuperação de desastres atual para exibir o pop-up de edição.
No pop-up Editar recuperação de desastres, você pode alterar suas seleções. Guardar as suas alterações.
Nota
Com uma região de recuperação emparelhada, a região é exibida, mas acinzentada. Não é possível editar a região.
