Confiabilidade no Azure Private 5G Core
Este artigo descreve o suporte à confiabilidade no Azure Private 5G Core. Ele abrange a resiliência regional com zonas de disponibilidade e a recuperação de desastre entre regiões e continuidade dos negócios. Para ter uma visão geral da confiabilidade no Azure, confira Confiabilidade do Azure.
Você também pode implantar o Azure Private 5G Core como um serviço de HA (Alta Disponibilidade) em um par de dispositivos ASE (Azure Stack Edge). Para saber mais, confira Concluir as tarefas de pré-requisito para implantar uma rede móvel privada.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos de datacenters fisicamente separados em cada região do Azure. Quando uma zona falha, os serviços podem fazer failover para uma das zonas restantes.
Para obter mais informações sobre zonas de disponibilidade no Azure, consulte O que são zonas de disponibilidade?.
O serviço Azure Private 5G Core é implantado automaticamente como com redundância de zona nas regiões do Azure que dão suporte às zonas de disponibilidade, conforme listado em Regiões do Azure com suporte da zona de disponibilidade. Se uma região der suporte às zonas de disponibilidade, todos os recursos do Azure Private 5G Core criados em uma região poderão ser gerenciados em qualquer uma das zonas de disponibilidade.
Nenhum trabalho adicional é necessário para configurar ou gerenciar as zonas de disponibilidade. O failover entre as zonas de disponibilidade é automático.
Pré-requisitos
Confira Produtos disponíveis por região para as regiões do Azure nas quais o Azure Private 5G Core está disponível.
Experiência de zona inoperante
Em um cenário de interrupção em toda a zona, os usuários não enfrentarão nenhum impacto, porque o serviço será movido para aproveitar a zona íntegra automaticamente. No início de uma interrupção em toda a zona, talvez você observe as solicitações do ARM em andamento atingirem o tempo limite ou falharem. As novas solicitações serão direcionadas para os nós íntegros sem nenhum impacto aos usuários, e todas as operações com falha deverão ser repetidas. Você ainda poderá criar recursos, bem como atualizar, monitorar e gerenciar os recursos existentes durante a interrupção.
Técnicas de implantação segura
O aplicativo garante que todo o estado da nuvem seja replicado entre as zonas de disponibilidade da região, de modo que todas as operações de gerenciamento continuem sem interrupção. O núcleo de pacotes está em execução na borda e não é afetado pela falha de zona e, portanto, continuará fornecendo serviço aos usuários.
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 desastres 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.
O Azure Private 5G Core só está disponível em geografias de várias regiões (3+N). O serviço replica automaticamente as credenciais do SIM em uma região de backup na mesma geografia. Isso significa que não há perda de dados em caso de falha da região. No prazo de até quatro horas após a falha, todos os recursos na região com falha ficam disponíveis para exibição por meio do portal do Azure e das ferramentas do ARM, mas serão somente leitura até que a região com falha seja recuperada. O núcleo de pacotes em execução na borda continuará operando sem interrupção, e a conectividade de rede será mantida.
A Microsoft é responsável pela detecção de interrupções, pela notificação e pelo suporte dos aspectos de nuvem do Azure do serviço Azure Private 5G Core.
Detecção, notificação e gerenciamento de interrupção
A Microsoft monitora os recursos subjacentes que fornecem o serviço Azure Private 5G Core em cada região. Se esses recursos começarem a mostrar falhas ou alertas de monitoramento de integridade que não estejam restritos a uma só zona de disponibilidade, a Microsoft migrará o serviço para outra região com suporte na mesma geografia. Esse é um padrão ativo-ativo. Encontre a integridade do serviço para uma região específica em Integridade do Serviço do Azure (o Azure Private 5G Core está listado na seção Rede). Você será notificado sobre qualquer falha de região por meio dos canais normais de comunicação do Azure.
O serviço replica automaticamente as credenciais do SIM pertencentes ao serviço na região de backup usando gravações de várias regiões do Cosmos DB. Portanto, não há perda de dados em caso de falha da região.
Os recursos do Azure Private 5G Core implantados na região com falha passarão a ser somente leitura, mas os recursos de todas as outras regiões continuarão funcionando sem impacto. Caso precise gravar recursos o tempo todo, siga as instruções descritas em Configurar a recuperação de desastre e a detecção de interrupções para executar sua operação de recuperação de desastre e configurar o serviço em outra região.
O núcleo de pacotes em execução na borda continuará operando sem interrupção, e a conectividade de rede será mantida.
Configurar a recuperação de desastre e a detecção de interrupções
Esta seção descreve qual ação você poderá executar para garantir que tenha um plano de gerenciamento totalmente ativo para o serviço Azure Private 5G Core, em caso de falha de uma região. Isso será necessário se você desejar conseguir modificar seus recursos em caso de falha de uma região.
Observe que isso causará uma interrupção no serviço de núcleos de pacotes e interromperá a conectividade de rede com os UEs por até oito horas. Portanto, recomendamos que você use esse procedimento somente se tiver um motivo comercialmente crítico para gerenciar os recursos enquanto a região do Azure estiver inativa.
Antes de um evento de recuperação de desastre, você precisa fazer backup da configuração de recursos em outra região que dê suporte ao Azure Private 5G Core. Quando a falha da região ocorrer, você poderá reimplantar o núcleo de pacotes usando os recursos na região de backup.
Preparação
Há dois tipos de dados de configuração do Azure Private 5G Core que precisam ser copiados em backup para a recuperação de desastre: configuração de rede móvel e credenciais do SIM. É recomendável que você:
- Atualize as credenciais do SIM na região de backup sempre que adicionar novos SIMs à região primária
- Faça backup da configuração de rede móvel, pelo menos, uma vez por semana ou com mais frequência se estiver fazendo alterações frequentes ou grandes na configuração, como a criação de um site.
Configuração de rede móvel
Siga as instruções descritas em Mover recursos para outra região para exportar sua configuração de recurso do Azure Private 5G Core e carregá-la na nova região. Recomendamos que você use um novo grupo de recursos para sua configuração de backup para separá-lo claramente da configuração ativa. Você precisa dar novos nomes aos recursos para distingui-los dos recursos da região primária. Essa nova região é um backup passivo. Portanto, para evitar conflitos, você ainda não precisa vincular a configuração do núcleo de pacotes ao hardware de borda. Em vez disso, armazene os valores do campo packetCoreControlPlanes.platform para cada núcleo de pacotes em um local seguro que possa ser acessado por quem executará o procedimento de recuperação (como uma conta de armazenamento referenciada pela documentação interna).
Dados do SIM
Por motivos de segurança, o Azure Private 5G Core nunca retornará as credenciais do SIM fornecidas ao serviço como parte da criação do SIM. Portanto, não é possível exportar a configuração do SIM da mesma forma que outros recursos do Azure. Recomendamos que sempre que novos SIMs forem adicionados ao serviço primário, os mesmos SIMs também sejam adicionados ao serviço de backup repetindo o processo Provisionar novos SIMs para a rede móvel de backup.
Outros recursos
Sua implantação do Azure Private 5G Core pode usar cofres de chaves do Azure para armazenar as chaves de criptografia do SIM ou certificados HTTPS para o monitoramento local. Siga a documentação do Azure Key Vault para garantir que as chaves e os certificados fiquem disponíveis na região de backup.
Recuperação
No caso de uma falha de região, primeiro, valide se todos os recursos na região de backup estão presentes consultando a configuração por meio do portal do Azure ou da API (confira Mover recursos para outra região). Se todos os recursos não estiverem presentes, pare aqui e não siga o restante deste procedimento. Talvez você não consiga recuperar o serviço no site de borda sem a configuração do recurso.
O processo de recuperação é dividido em três fases para cada núcleo de pacotes:
- Desconectar o dispositivo Azure Stack Edge da região com falha executando uma redefinição
- Conectar o dispositivo Azure Stack Edge à região de backup
- Reinstale e valide a instalação.
Você precisa repetir esse processo para cada núcleo de pacotes na rede móvel.
Cuidado
O procedimento de recuperação causará uma interrupção do serviço de núcleo de pacotes e interromperá a conectividade de rede com os UEs por até oito horas para cada núcleo de pacotes. Recomendamos que você execute esse procedimento somente quando tiver uma necessidade comercialmente crítica de gerenciar a implantação do Azure Private 5G Core por meio do Azure durante a falha da região.
Desconectar o dispositivo Azure Stack Edge da região com falha
No momento, o dispositivo Azure Stack Edge está executando o software do núcleo de pacotes e é controlado na região com falha. Para desconectar o dispositivo Azure Stack Edge da região com falha e remover o núcleo de pacotes em execução, siga as instruções de redefinição e reativação em Redefinir e reativar seu dispositivo Azure Stack Edge. Observe que isso removerá TODOS os programas de software em execução no dispositivo Azure Stack Edge, não apenas o software do núcleo de pacotes. Portanto, verifique se você tem a capacidade de reinstalar qualquer outro software no dispositivo. Isso iniciará uma interrupção de rede para todos os dispositivos conectados ao núcleo de pacotes nesse dispositivo Azure Stack Edge.
Conectar o dispositivo Azure Stack Edge à nova região
Siga as instruções descritas em Ativar o cluster do AKS para reimplantar o cluster do Serviço de Kubernetes do Azure no seu dispositivo Azure Stack Edge. Use um nome diferente para essa nova instalação a fim de evitar conflitos quando a região com falha for recuperada. Como parte deste processo, você obterá uma nova ID de local personalizada para o cluster, que deverá anotar.
Reinstalação e validação
Faça uma cópia dos valores de packetCoreControlPlanes.platform armazenados em Preparação e atualize o campo packetCoreControlPlane.platform.customLocation com a ID de local personalizada anotada acima. Verifique se packetCoreControlPlane.platform.azureStackEdgeDevice corresponde à ID do dispositivo Azure Stack Edge no qual deseja instalar o núcleo de pacotes. Agora, siga Modificar um núcleo de pacotes para atualizar o núcleo de pacotes de backup com os valores da plataforma. Isso vai disparar uma implantação do núcleo de pacotes no dispositivo Azure Stack Edge.
Você deve seguir o processo normal para validar uma nova instalação de site a fim de confirmar se a conectividade do UE foi restaurada e se toda a funcionalidade de rede está operacional. Em particular, você deve confirmar se os painéis do site no portal do Azure mostram os registros do UE e se os dados fluem pelo plano de dados.
Região com falha restaurada
Quando a região com falha for recuperada, você deverá garantir que a configuração nas duas regiões esteja sincronizada fazendo um backup da região de backup ativa para a região primária recuperada seguindo as etapas descritas em Preparação.
Você também precisará verificar e remover todos os recursos da região recuperada que não foram destruídos pelas etapas anteriores:
- Para cada dispositivo Azure Stack Edge que você moveu para a região de backup (seguindo as etapas descritas em Recuperação), você precisará encontrar e excluir o recurso de cluster do ARC antigo. A ID desse recurso está no campo packetCoreControlPlane.platform.customLocation dos valores copiados em backup em Preparação. O estado desse recurso será desconectado, porque o cluster do Kubernetes correspondente foi excluído como parte do processo de recuperação.
- Para cada núcleo de pacotes que você moveu para a região de backup (seguindo as etapas descritas em Recuperação), encontre e exclua os objetos NFM na região recuperada. Eles serão listados no mesmo grupo de recursos dos recursos do painel de controle do núcleo de pacotes e o valor de Região corresponderá à região recuperada.
Em seguida, você terá duas opções para o gerenciamento contínuo:
- Usar a região de backup operacional como a nova região primária e usar a região recuperada como backup. Nenhuma ação do usuário é necessária.
- Torne a região recuperada a nova região primária ativa seguindo as instruções descritas em Mover recursos para outra região para voltar à região recuperada.
Teste
Se quiser testar seus planos de recuperação de desastre, siga o procedimento de recuperação para um só núcleo de pacotes por vez. Observe que isso causará uma interrupção do serviço de núcleo de pacotes e interromperá a conectividade de rede com os UEs por até quatro horas. Portanto, recomendamos fazer isso apenas com implantações de núcleos de pacotes que não sejam de produção ou em um período em que uma interrupção não afetará negativamente seus negócios.