Confiabilidade nos Hubs de Notificações do Microsoft Azure
Este artigo descreve o suporte à confiabilidade nos Hubs de Notificação do Azure e abrange a resiliência regional com zonas de disponibilidade e 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 de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas 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 é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.
Em uma região que dá suporte a zonas de disponibilidade, os Hubs de Notificação dão 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 nas regiões em que eles estão disponíveis. Para obter uma lista de regiões que dão suporte a zonas de disponibilidade, consulte o Serviço de zona de disponibilidade e o suporte regional.
As zonas de disponibilidade têm suporte por padrão apenas em camadas específicas. Para saber quais camadas dão suporte a implantações de zonas de disponibilidade, consulte [Preços dos Hubs de Notificação](https://azure.microsoft.com/pricing/details/notification-hubs.
Aprimoramentos do SLA
O suporte a zonas de disponibilidade gera um custo adicional sobre os preços da camada existente. Para obter mais informações sobre nosso SLA, consulte o SLA dos Hubs de Notificação.
Experiência de zona inoperante
Durante uma interrupção em toda a zona, nenhuma ação é necessária durante a recuperação de zona. Os Hubs de Notificação se recuperam e se reequilibram para aproveitar automaticamente a zona íntegra.
Habilitar as Zonas de Disponibilidade
Você só pode habilitar zonas de disponibilidade em novos namespaces. Como os Hubs de Notificação não dão 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ções do Azure no portal do Microsoft Azure.
Migrar para o suporte às zonas 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 diretrizes em Mover recursos entre regiões do Azure.
Recuperação de desastre entre regiões e continuidade dos negócios
A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.
Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.
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 dão suporte para Região de Recuperação Flexível.
Quando um cenário de recuperação de desastres é disparado, 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 para 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 destino de failover para o namespace primário. Você pode escolher entre a lista de regiões com suporte. 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 é disparado, 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 ao namespace primário são redirecionadas para o namespace secundário, e as notificações por push são entregues a partir do namespace secundário.
As regiões a seguir dão suporte à Região de Recuperação Flexível:
- Oeste dos EUA 2
- Norte da Europa
- Leste da Austrália
- Brazil South
- Sudeste da Ásia
- Norte da África do Sul
Faça backup dos dados de registro
A recuperação de região emparelhada e flexível só faz backup de metadados. Implemente uma solução para preencher esses dados novamente em seu hub após a 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 você faça backup de seus registros 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 criado em outra região: use esta opção para fazer backup de seus registros. Como um hub de trabalho, você pode implementar o código para alternar para essa cópia. Para manter um hub de notificação secundário em sincronia com o hub de notificação primário, você pode usar uma das seguintes opções para fazer backup de seus registros:
- Para instalações: use um back-end de aplicativo que crie e atualize 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 ao cenário de replicação. Para obter mais informações, confira este código de exemplo.
- Para registro: Use um back-end de aplicativo que obtenha um despejo regular de registros do hub de notificação principal como um backup. Ele pode realizar uma inserção em massa no hub de notificação secundário. Confira Exportar e importar em massa registros dos Hubs de Notificações do Microsoft Azure.
O hub de notificação secundário pode ter registros expirados. Quando o push é feito para um identificador expirado, os Hubs de Notificação limpam automaticamente o registro de registro associado no hub de notificações 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 tem um back-end, quando o aplicativo inicia nos dispositivos de destino, eles executam 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 durante o qual os dispositivos com aplicativos não abertos não recebem notificações.
Habilitar a recuperação de desastre entre regiões
Para habilitar a recuperação de desastres para um novo namespace, siga o procedimento em Criar um hub de notificações do Azure no portal do Microsoft Azure.
Para habilitar ou desabilitar a recuperação de desastres em um namespace existente:
Entre 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ções, selecione o namespace para o qual você quer modificar as configurações de recuperação de desastre.
Na página Namespace do Hub de Notificações do namespace, é possível ver a configuração de recuperação de desastre atual na seção Noções Básicas.
No exemplo a seguir, a região de recuperação flexível está habilitada. Clique na seleção da região de recuperação de desastre atual para exibir o pop-up de edição.
No pop-up Editar Recuperação de Desastre, altere suas seleções. Salve suas alterações.
Observação
Com uma região de recuperação emparelhada, a região é exibida, mas esmaeecida. Não é possível editar a região.
