Betrouwbaarheid voor Azure Private 5G Core
In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Private 5G Core beschreven. Het omvat zowel regionale tolerantie als beschikbaarheidszones en herstel na noodgevallen in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een overzicht van betrouwbaarheid in Azure.
U kunt Azure Private 5G Core ook implementeren als een maximaal beschikbare (HA)-service op een paar Azure Stack Edge-apparaten (ASE). Zie De vereiste taken voor het implementeren van een privé mobiel netwerk voltooien voor meer informatie.
Ondersteuning voor beschikbaarheidszone
Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.
Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?
De Azure Private 5G Core-service wordt automatisch geïmplementeerd als zone-redundant in Azure-regio's die beschikbaarheidszones ondersteunen, zoals vermeld in de beschikbaarheidszoneservice en regionale ondersteuning. Als een regio beschikbaarheidszones ondersteunt, kunnen alle Azure Private 5G Core-resources die in een regio zijn gemaakt, worden beheerd vanuit een van de beschikbaarheidszones.
Er is geen verdere werkzaamheden vereist voor het configureren of beheren van beschikbaarheidszones. Failover tussen beschikbaarheidszones wordt automatisch uitgevoerd.
Vereisten
Zie Producten die beschikbaar zijn per regio voor de Azure-regio's waar Azure Private 5G Core beschikbaar is.
Zone-down-ervaring
In een zonebreed storingsscenario moeten gebruikers geen impact ondervinden, omdat de service automatisch zal profiteren van de gezonde zone. Aan het begin van een zonebrede storing ziet u mogelijk een time-out voor ARM-aanvragen die in uitvoering zijn of mislukken. Nieuwe aanvragen worden omgeleid naar knooppunten die geen invloed hebben op gebruikers en mislukte bewerkingen moeten opnieuw worden uitgevoerd. U kunt nog steeds nieuwe resources maken en bestaande resources bijwerken, bewaken en beheren tijdens de storing.
Veilige implementatietechnieken
De toepassing zorgt ervoor dat alle cloudstatus wordt gerepliceerd tussen beschikbaarheidszones in de regio, zodat alle beheerbewerkingen zonder onderbreking worden voortgezet. De pakketkern wordt uitgevoerd op de Edge en wordt niet beïnvloed door de zonefout, dus blijft de service voor gebruikers bieden.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.
Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.
Azure Private 5G Core is alleen beschikbaar in regio's met meerdere regio's (3+N). De service repliceert automatisch SIM-referenties naar een back-upregio in dezelfde geografie. Dit betekent dat er geen gegevens verloren gaan in het geval van een storing in de regio. Binnen vier uur na de fout zijn alle resources in de mislukte regio beschikbaar om te bekijken via de Azure-portal en ARM-hulpprogramma's, maar zijn ze alleen-lezen totdat de mislukte regio is hersteld. De pakketkern die in Edge wordt uitgevoerd, blijft werken zonder onderbreking en de netwerkverbinding blijft behouden.
Microsoft is verantwoordelijk voor storingsdetectie, meldingen en ondersteuning voor de Azure-cloudaspecten van de Azure Private 5G Core-service.
Detectie, melding en beheer van storingen
Microsoft bewaakt de onderliggende resources die de Azure Private 5G Core-service in elke regio leveren. Als deze resources fouten of waarschuwingen voor statuscontrole weergeven die niet beperkt zijn tot één beschikbaarheidszone, verplaatst Microsoft de service naar een andere ondersteunde regio in dezelfde geografie. Dit is een actief-actief patroon. De servicestatus voor een bepaalde regio vindt u in Azure Service Health (Azure Private 5G Core wordt vermeld in de sectie Netwerken ). U ontvangt een melding over eventuele regiofouten via normale Azure-communicatiekanalen.
De service repliceert automatisch SIM-referenties die eigendom zijn van de service naar de back-upregio met behulp van Schrijfbewerkingen in meerdere regio's van Cosmos DB, zodat er geen gegevens verloren gaan in het geval van een storing in de regio.
Azure Private 5G Core-resources die zijn geïmplementeerd in de mislukte regio, worden alleen-lezen, maar resources in alle andere regio's blijven ongewijzigd werken. Als u altijd resources moet kunnen schrijven, volgt u de instructies in Herstel na noodgevallen en detectie van storingen instellen om uw eigen herstelbewerking na noodgevallen uit te voeren en de service in een andere regio in te stellen.
De pakketkern die in Edge wordt uitgevoerd, blijft werken zonder onderbreking en de netwerkverbinding blijft behouden.
Herstel na noodgevallen en detectie van storingen instellen
In deze sectie wordt beschreven welke actie u kunt ondernemen om ervoor te zorgen dat u een volledig actief beheervlak hebt voor de Azure Private 5G Core-service in het geval van een regiofout. Dit is vereist als u uw resources wilt kunnen wijzigen in het geval van een regiofout.
Houd er rekening mee dat dit tot een storing van uw pakketkernservice leidt en de netwerkverbinding met uw UE's maximaal acht uur onderbreekt. Daarom raden we u aan deze procedure alleen te gebruiken als u een bedrijfskritieke reden hebt om resources te beheren terwijl de Azure-regio uitvalt.
Voorafgaand aan een noodherstel-gebeurtenis moet u een back-up maken van uw resourceconfiguratie naar een andere regio die Ondersteuning biedt voor Azure Private 5G Core. Wanneer de regiofout optreedt, kunt u de pakketkern opnieuw implementeren met behulp van de resources in uw back-upregio.
Voorbereiding
Er zijn twee typen Azure Private 5G Core-configuratiegegevens waarvan een back-up moet worden gemaakt voor herstel na noodgevallen: configuratie van mobiele netwerken en SIM-referenties. U wordt aangeraden dat u:
- De SIM-referenties in de back-upregio bijwerken telkens wanneer u nieuwe SIM's toevoegt aan de primaire regio
- Maak minstens één keer per week een back-up van de configuratie van het mobiele netwerk of vaker als u regelmatig of grote wijzigingen aanbrengt in de configuratie, zoals het maken van een nieuwe site.
Configuratie van mobiel netwerk
Volg de instructies in Resources verplaatsen naar een andere regio om uw Azure Private 5G Core-resourceconfiguratie te exporteren en deze te uploaden naar de nieuwe regio. U wordt aangeraden een nieuwe resourcegroep voor uw back-upconfiguratie te gebruiken om deze duidelijk te scheiden van de actieve configuratie. U moet de resources nieuwe namen geven om deze te onderscheiden van de resources in uw primaire regio. Deze nieuwe regio is een passieve back-up, dus om conflicten te voorkomen, moet u de pakketkernconfiguratie nog niet koppelen aan uw edge-hardware. Sla in plaats daarvan de waarden op uit het veld packetCoreControlPlanes.platform voor elke pakketkern op een veilige locatie die toegankelijk is voor iedereen die de herstelprocedure uitvoert (zoals een opslagaccount waarnaar wordt verwezen door interne documentatie).
SIM-gegevens
Om veiligheidsredenen retourneert Azure Private 5G Core nooit de SIM-referenties die aan de service worden verstrekt als onderdeel van het maken van sim. Daarom is het niet mogelijk om de SIM-configuratie op dezelfde manier te exporteren als andere Azure-resources. We raden u aan dat wanneer er nieuwe SIM's worden toegevoegd aan de primaire service, dezelfde VM's ook worden toegevoegd aan de back-upservice door het proces nieuwe VM's inrichten voor het mobiele back-upnetwerk te herhalen.
Meer informatie
Uw Azure Private 5G Core-implementatie kan gebruikmaken van Azure Key Vaults voor het opslaan van SIM-versleutelingssleutels of HTTPS-certificaten voor lokale bewaking. U moet de Documentatie van Azure Key Vault volgen om ervoor te zorgen dat uw sleutels en certificaten beschikbaar zijn in de back-upregio.
Herstel
In het geval van een regiofout controleert u eerst of alle resources in uw back-upregio aanwezig zijn door een query uit te voeren op de configuratie via Azure Portal of API (zie Resources verplaatsen naar een andere regio). Als alle resources niet aanwezig zijn, stopt u hier en volgt u de rest van deze procedure niet. Mogelijk kunt u de service niet herstellen op de edge-site zonder de resourceconfiguratie.
Het herstelproces wordt onderverdeeld in drie fasen voor elke pakketkern:
- Koppel het Azure Stack Edge-apparaat los van de mislukte regio door een reset uit te voeren
- Het Azure Stack Edge-apparaat verbinden met de back-upregio
- Installeer de installatie opnieuw en valideer deze.
U moet dit proces herhalen voor elke pakketkern in uw mobiele netwerk.
Let op
De herstelprocedure veroorzaakt een storing in uw pakketkernservice en onderbreekt de netwerkverbinding met uw UE's gedurende maximaal acht uur voor elke pakketkern. We raden u aan deze procedure alleen uit te voeren wanneer u een bedrijfskritieke noodzaak hebt om de Azure Private 5G Core-implementatie via Azure te beheren tijdens de regiofout.
Koppel het Azure Stack Edge-apparaat los van de mislukte regio
Het Azure Stack Edge-apparaat voert momenteel de pakketkernsoftware uit en wordt beheerd vanuit de mislukte regio. Als u de verbinding met het Azure Stack Edge-apparaat van de mislukte regio wilt verbreken en de actieve pakketkern wilt verwijderen, moet u de instructies voor opnieuw instellen en opnieuw activeren volgen in Reset en opnieuw activeren van uw Azure Stack Edge-apparaat. Houd er rekening mee dat hiermee ALLE software die momenteel wordt uitgevoerd op uw Azure Stack Edge-apparaat wordt verwijderd, niet alleen de pakketkernsoftware, dus zorg ervoor dat u de mogelijkheid hebt om andere software op het apparaat opnieuw te installeren. Hiermee wordt een netwerkstoring gestart voor alle apparaten die zijn verbonden met de pakketkern op dit Azure Stack Edge-apparaat.
Het Azure Stack Edge-apparaat verbinden met de nieuwe regio
Volg de instructies in het AKS-cluster van de Commissie om het Azure Kubernetes Service-cluster opnieuw te implementeren op uw Azure Stack Edge-apparaat. Zorg ervoor dat u een andere naam gebruikt voor deze nieuwe installatie om conflicten te voorkomen wanneer de mislukte regio wordt hersteld. Als onderdeel van dit proces krijgt u een nieuwe aangepaste locatie-id voor het cluster, die u moet noteren.
Opnieuw installeren en valideren
Maak een kopie van de waarden van packetCoreControlPlanes.platform die u hebt opgeslagen in Voorbereiding en werk het veld packetCoreControlPlane.platform.customLocation bij met de aangepaste locatie-id die u hierboven hebt genoteerd. Zorg ervoor dat packetCoreControlPlane.platform.azureStackEdgeDevice overeenkomt met de id van het Azure Stack Edge-apparaat waarop u de pakketkern wilt installeren. Volg nu Een pakketkern wijzigen om de kern van het back-uppakket bij te werken met de platformwaarden. Hiermee wordt een pakketkernimplementatie op het Azure Stack Edge-apparaat geactiveerd.
Volg het normale proces voor het valideren van een nieuwe site-installatie om te bevestigen dat de UE-verbinding is hersteld en dat alle netwerkfunctionaliteit operationeel is. U moet met name bevestigen dat in de sitedashboards in Azure Portal UE-registraties worden weergegeven en dat de gegevens door het gegevensvlak stromen.
Mislukte regio hersteld
Wanneer de mislukte regio wordt hersteld, moet u ervoor zorgen dat de configuratie in de twee regio's gesynchroniseerd is door een back-up uit te voeren van de actieve back-upregio naar de herstelde primaire regio, volgens de stappen in Voorbereiding.
U moet ook controleren op en verwijderen van resources in de herstelde regio die niet zijn vernietigd door de voorgaande stappen:
- Voor elk Azure Stack Edge-apparaat dat u naar de back-upregio hebt verplaatst (volgens de stappen in Herstel), moet u de oude ARC-clusterresource zoeken en verwijderen. De id van deze resource bevindt zich in het veld packetCoreControlPlane.platform.customLocation van de waarden waarvan u een back-up hebt gemaakt in Voorbereiding. De status van deze resource wordt verbroken omdat het bijbehorende Kubernetes-cluster is verwijderd als onderdeel van het herstelproces.
- Voor elke pakketkern die u naar de back-upregio hebt verplaatst (volgens de stappen in Herstel), moet u eventuele NFM-objecten in de herstelde regio zoeken en verwijderen. Deze worden vermeld in dezelfde resourcegroep als de resources van het pakketkernbesturingsvlak en de waarde Regio komt overeen met de herstelde regio.
Vervolgens hebt u twee opties voor doorlopend beheer:
- Gebruik de operationele back-upregio als de nieuwe primaire regio en gebruik de herstelde regio als back-up. Er is geen verdere actie vereist.
- Maak de herstelde regio de nieuwe actieve primaire regio door de instructies in Resources verplaatsen naar een andere regio te volgen om terug te keren naar de herstelde regio.
Testen
Als u uw noodherstelplannen wilt testen, kunt u de herstelprocedure voor één pakketkern op elk gewenst moment volgen. Houd er rekening mee dat dit tot maximaal vier uur een servicestoring van uw pakketkernservice veroorzaakt en de netwerkverbinding met uw UE's onderbreekt. Daarom raden we u aan dit alleen te doen met niet-productiepakketkernimplementaties of op een moment dat een storing uw bedrijf niet nadelig beïnvloedt.