Fiabilité pour Azure Private 5G Core

Cet article décrit la prise en charge de la fiabilité dans Azure Private 5G Core. Cela couvre la résilience régionale avec des zones de disponibilité et la reprise d’activité de récupération d’urgence inter-régions et continuité d’activité. Pour obtenir une vue d’ensemble de la fiabilité dans Azure, consultez Fiabilité Azure.

Vous pouvez également déployer Azure Private 5G Core en tant que service haute disponibilité (HA) sur une paire d’appareils Azure Stack Edge (ASE). Pour plus d’informations, consultez Effectuer les tâches préalables pour le déploiement d’un réseau mobile privé.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes de centres de données physiquement séparés au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Pour plus d’informations sur les zones de disponibilité dans Azure, consultez Que sont les zones de disponibilité ?.

Le service Azure Private 5G Core est automatiquement déployé en mode redondant interzone dans les régions Azure qui prennent en charge les zones de disponibilité, comme indiqué dans Régions Azure avec prise en charge des zones de disponibilité. Si une région prend en charge les zones de disponibilité, toutes les ressources Azure Private 5G Core créées dans une région peuvent être gérées à partir de n’importe quelle zone de disponibilité.

Aucune tâche supplémentaire n’est requise pour configurer ou gérer les zones de disponibilité. Le basculement entre les zones de disponibilité est automatique.

Prérequis

Consultez Produits disponibles par région pour les régions Azure où Azure Private 5G Core est disponible.

Expérience en cas de panne de zone

Dans un scénario de panne à l’échelle de la zone, les utilisateurs ne doivent subir aucun impact puisque le service se déplace automatiquement pour tirer parti de la zone saine. Au début d’une panne à l’échelle de la zone, vous pouvez voir les demandes ARM en cours arriver à expiration ou échouer. Les nouvelles demandes sont dirigées vers des nœuds sains, sans aucun impact sur les utilisateurs, et toute opération ayant échoué doit être retentée. Vous pouvez toujours créer des ressources et mettre à jour, monitorer et gérer les ressources existantes pendant la panne.

Techniques de déploiement sécurisées

L’application garantit la réplication totale de l’état du cloud entre les zones de disponibilité de la région afin que toutes les opérations de gestion se poursuivent sans interruption. Le Packet Core s’exécute à la périphérie et n’est pas affecté par la défaillance de la zone. Il continue donc à fournir un service aux utilisateurs.

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes en charge de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Azure Private 5G Core est uniquement disponible dans les zones géographiques multirégions (3+N). Le service réplique automatiquement les informations d’identification SIM dans une région de sauvegarde dans la même zone géographique. Cela signifie qu’il n’y a aucune perte de données en cas de défaillance de la région. Dans les quatre heures suivant la défaillance, toutes les ressources dans la région ayant échoué peuvent être consultées par le biais du portail Azure et d’outils ARM. Toutefois, elles sont en lecture seule jusqu’à ce que la région ayant échoué soit récupérée. Le Packet Core en cours d’exécution à la périphérie continue de fonctionner sans interruption et la connectivité réseau est maintenue.

Microsoft est responsable de la détection, de la notification et de la prise en charge des pannes pour les aspects cloud Azure du service Azure Private 5G Core.

Détection, notification et gestion des pannes

Microsoft monitore les ressources sous-jacentes qui fournissent le service Azure Private 5G Core dans chaque région. Si ces ressources commencent à générer des défaillances ou des alertes de monitoring de l’intégrité qui ne sont pas limitées à une seule zone de disponibilité, Microsoft déplace le service vers une autre région prise en charge dans la même zone géographique. Il s’agit d’un modèle actif-actif. L’intégrité du service pour une région particulière est visible dans Azure Service Health (Azure Private 5G Core est listé dans la section Réseaux). En cas de défaillance d’une région, vous êtes notifié par le biais des canaux de communication Azure normaux.

Le service réplique automatiquement les informations d’identification SIM détenues par le service dans la région de sauvegarde à l’aide d’écritures multirégions Cosmos DB. Il n’y a donc aucune perte de données en cas de défaillance d’une région.

Les ressources Azure Private 5G Core déployées dans la région ayant échoué passent en lecture seule, mais les ressources de toutes les autres régions continuent de fonctionner sans être affectées. Si vous devez être en mesure d’écrire des ressources à tout moment, suivez les instructions fournies dans Configurer la reprise d’activité et la détection des pannes pour effectuer votre propre opération de reprise d’activité et configurer le service dans une autre région.

Le Packet Core en cours d’exécution à la périphérie continue de fonctionner sans interruption et la connectivité réseau est maintenue.

Configurer la reprise d’activité et la détection des pannes

Cette section décrit les actions que vous pouvez effectuer afin de disposer d’un plan de gestion entièrement actif pour le service Azure Private 5G Core en cas de défaillance d’une région. Ces actions sont obligatoires si vous souhaitez être en mesure de modifier vos ressources à la suite de la défaillance d’une région.

Notez toutefois qu’elles provoquent une panne de votre service Packet Core et interrompent la connectivité réseau à vos UE pendant au maximum huit heures. Nous vous recommandons donc de n’utiliser cette procédure que s’il est vital pour l’entreprise de pouvoir gérer les ressources quand la région Azure est indisponible.

Avant un événement de reprise d’activité, vous devez sauvegarder la configuration de vos ressources dans une autre région qui prend en charge Azure Private 5G Core. Quand la région échoue, vous pouvez redéployer le Packet Core à l’aide des ressources de votre région de sauvegarde.

Préparation

Il existe deux types de données de configuration Azure Private 5G Core qui doivent être sauvegardées pour la reprise d’activité : la configuration du réseau mobile et les informations d’identification SIM. Nous vous recommandons :

• Mettre à jour les informations d’identification SIM dans la région de sauvegarde chaque fois que vous ajoutez de nouvelles cartes SIM à la région primaire
• Sauvegarder la configuration du réseau mobile au moins une fois par semaine, ou plus souvent si vous apportez des modifications fréquentes ou importantes à la configuration, comme la création d’un site

Configuration du réseau mobile

Suivez les instructions fournies dans Déplacer des ressources vers une autre région pour exporter votre configuration de ressources Azure Private 5G Core et la charger dans la nouvelle région. Nous vous recommandons d’utiliser un nouveau groupe de ressources pour votre configuration de sauvegarde afin de le séparer clairement de la configuration active. Vous devez attribuer de nouveaux noms aux ressources pour les distinguer des ressources de votre région primaire. Cette nouvelle région étant une sauvegarde passive, ne liez pas tout de suite la configuration Packet Core à votre matériel de périphérie pour éviter les conflits. Au lieu de cela, stockez les valeurs du champ packetCoreControlPlanes.platform pour chaque Packet Core dans un emplacement sécurisé accessible à toute personne effectuant la procédure de récupération (par exemple, un compte de stockage référencé par la documentation interne).

Données SIM

Pour des raisons de sécurité, Azure Private 5G Core ne retourne jamais les informations d’identification SIM fournies au service dans le cadre de la création d’une carte SIM. Il n’est donc pas possible d’exporter la configuration SIM de la même façon que d’autres ressources Azure. Chaque fois que de nouvelles cartes SIM sont ajoutées au service principal, nous vous recommandons d’ajouter les mêmes cartes SIM au service de sauvegarde en répétant le processus Provisionner de nouvelles cartes SIM pour le réseau mobile de sauvegarde.

Autres ressources

Votre déploiement Azure Private 5G Core peut utiliser Azure Key Vault pour stocker les clés de chiffrement SIM ou les certificats HTTPS à des fins de monitoring local. Vous devez suivre la documentation Azure Key Vault pour vous assurer que vos clés et certificats seront disponibles dans la région de sauvegarde.

Récupération

En cas de défaillance d’une région, vérifiez d’abord que toutes les ressources de votre région de sauvegarde sont présentes en interrogeant la configuration par le biais du portail ou de l’API Azure. Pour cela, consultez Déplacer des ressources vers une autre région. Si toutes les ressources ne sont pas présentes, arrêtez-vous ici et ne suivez pas le reste de cette procédure. Vous ne pourrez peut-être pas récupérer le service sur le site de périphérie sans la configuration de la ressource.

Le processus de récupération est divisé en trois étapes pour chaque Packet Core :

1. Déconnecter l’appareil Azure Stack Edge de la région ayant échoué en effectuant une réinitialisation
2. Connecter l’appareil Azure Stack Edge à la région de sauvegarde
3. Réinstaller et valider l’installation.

Vous devez répéter ce processus pour chaque Packet Core dans votre réseau mobile.

Attention

La procédure de récupération provoque une panne de votre service Packet Core et interrompt la connectivité réseau à vos UE pendant au maximum huit heures pour chaque Packet Core. Nous vous recommandons d’effectuer cette procédure uniquement s’il est vital pour l’entreprise de pouvoir gérer le déploiement d’Azure Private 5G Core via Azure quand la région est en panne.

Déconnecter l’appareil Azure Stack Edge de la région ayant échoué

L’appareil Azure Stack Edge exécute actuellement le logiciel Packet Core et est contrôlé à partir de la région ayant échoué. Pour déconnecter l’appareil Azure Stack Edge de la région ayant échoué et supprimer le Packet Core en cours d’exécution, vous devez suivre les instructions de réinitialisation et de réactivation fournies dans Réinitialiser et réactiver votre appareil Azure Stack Edge. Notez que tous les logiciels en cours d’exécution sur votre appareil Azure Stack Edge sont supprimés, pas seulement le logiciel Packet Core. Vous devez donc vérifier que vous pouvez réinstaller les autres logiciels sur l’appareil. Une panne de réseau est déclenchée pour tous les appareils connectés au Packet Core sur cet appareil Azure Stack Edge.

Connecter l’appareil Azure Stack Edge à la nouvelle région

Suivez les instructions fournies dans Commissionner le cluster AKS pour redéployer le cluster Azure Kubernetes Service sur votre appareil Azure Stack Edge. Veillez à utiliser un nom différent pour cette nouvelle installation afin d’éviter les conflits lors de la récupération de la région ayant échoué. Dans le cadre de ce processus, vous obtiendrez un nouvel ID d’emplacement personnalisé pour le cluster. Notez-le.

Réinstaller et valider

Effectuez une copie des valeurs packetCoreControlPlanes.platform que vous avez stockées à l’étape Préparation et mettez à jour le champ packetCoreControlPlane.platform.customLocation avec l’ID d’emplacement personnalisé que vous avez noté ci-dessus. Vérifiez que packetCoreControlPlane.platform.azureStackEdgeDevice correspond à l’ID de l’appareil Azure Stack Edge sur lequel vous souhaitez installer le Packet Core. À présent, suivez les instructions fournies dans Modifier un Packet Core pour mettre à jour le Packet Core de sauvegarde avec les valeurs de la plateforme. Un déploiement de Packet Core est déclenché sur l’appareil Azure Stack Edge.

Vous devez suivre le processus normal de validation d’une nouvelle installation de site pour vérifier que la connectivité aux UE a été restaurée et que toutes les fonctionnalités réseau sont opérationnelles. En particulier, vous devez vérifier que les inscriptions des UE figurent dans les tableaux de bord de site du portail Azure et que les données transitent par le plan de données.

Région ayant échoué restaurée

Quand la région ayant échoué est récupérée, vous devez vérifier que la configuration dans les deux régions est synchronisée. Pour cela, effectuez une sauvegarde de la région de sauvegarde active vers la région primaire récupérée en suivant les étapes décrites dans Préparation.

Vous devez également rechercher et supprimer toutes les ressources de la région récupérée qui n’ont pas été détruites par les étapes précédentes :

• Pour chaque appareil Azure Stack Edge que vous avez déplacé vers la région de sauvegarde (en suivant les étapes décrites dans Récupération), vous devez rechercher et supprimer l’ancienne ressource de cluster ARC. L’ID de cette ressource se trouve dans le champ packetCoreControlPlane.platform.customLocation et provient des valeurs que vous avez sauvegardées dans Préparation. L’état de cette ressource est déconnecté dans la mesure où le cluster Kubernetes correspondant a été supprimé dans le cadre du processus de récupération.
• Pour chaque Packet Core que vous avez déplacé vers la région de sauvegarde (en suivant les étapes décrites dans Récupération), vous devez rechercher et supprimer tous les objets NFM dans la région récupérée. Ceux-ci sont listés dans le même groupe de ressources que les ressources du plan de contrôle Packet Core et la valeur Région correspond à la région récupérée.

Vous avez ensuite deux options pour la gestion continue :

• Utiliser la région de sauvegarde opérationnelle comme nouvelle région primaire et utiliser la région récupérée comme sauvegarde. Aucune action supplémentaire n’est requise.
• Faire de la région récupérée la nouvelle région primaire active en suivant les instructions fournies dans Déplacer des ressources vers une autre région pour revenir à la région récupérée.

Test

Si vous souhaitez tester vos plans de reprise d’activité, vous pouvez suivre à tout moment la procédure de récupération d’un Packet Core unique. Notez que cela provoquera une panne de votre service Packet Core et interrompra la connectivité réseau à vos UE pendant au maximum quatre heures. Nous vous recommandons donc de suivre cette procédure uniquement avec des déploiements Packet Core hors production ou à un moment où une panne n’affectera pas votre activité.

Étapes suivantes

• Fiabilité dans Azure