Affidabilità per Azure Private 5G Core
Questo articolo descrive il supporto per l'affidabilità in Azure Private 5G Core. Copre sia la resilienza a livello di area con le zone di disponibilità che il ripristino di emergenza tra aree e la continuità aziendale. Per una panoramica dell'affidabilità in Azure, vedere Affidabilità di Azure.
Supporto della zona di disponibilità
Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.
Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.
I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.
Il servizio 5G Core privato di Azure viene distribuito automaticamente come con ridondanza della zona nelle aree di Azure che supportano le zone di disponibilità, come indicato in Servizio zona di disponibilità e supporto a livello di area. Se un'area supporta le zone di disponibilità, tutte le risorse di Base 5G private di Azure create in un'area possono essere gestite da una qualsiasi delle zone di disponibilità.
Non sono necessarie altre operazioni per configurare o gestire le zone di disponibilità. Il failover tra le zone di disponibilità è automatico.
Prerequisiti
Vedere Prodotti disponibili in base all'area per le aree di Azure in cui è disponibile Azure Private 5G Core.
Esperienza di riduzione della zona
In uno scenario di interruzione a livello di zona, gli utenti non devono avere alcun impatto perché il servizio si sposta per sfruttare automaticamente la zona integra. All'inizio di un'interruzione a livello di zona, è possibile che vengano visualizzate richieste ARM in corso di timeout o errori. Le nuove richieste verranno indirizzate a nodi integri senza alcun impatto sugli utenti e le eventuali operazioni non riuscite devono essere ritentate. Sarà comunque possibile creare nuove risorse e aggiornare, monitorare e gestire le risorse esistenti durante l'interruzione.
Cassaforte tecniche di distribuzione
L'applicazione garantisce che tutto lo stato del cloud venga replicato tra le zone di disponibilità nell'area, in modo che tutte le operazioni di gestione continuino senza interruzioni. Il core del pacchetto è in esecuzione in Edge e non è interessato dall'errore della zona, quindi continuerà a fornire il servizio per gli utenti.
Ripristino di emergenza tra aree e continuità aziendale
Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.
Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.
Azure Private 5G Core è disponibile solo in aree geografiche (3+N). Il servizio replica automaticamente le credenziali SIM in un'area di backup nella stessa area geografica. Ciò significa che non si verifica alcuna perdita di dati in caso di errore dell'area. Entro quattro ore dall'errore, tutte le risorse nell'area non riuscita sono disponibili per la visualizzazione tramite gli strumenti di portale di Azure e ARM, ma saranno di sola lettura fino al ripristino dell'area non riuscita. Il core di pacchetto in esecuzione in Edge continua a funzionare senza interruzioni e la connettività di rete verrà mantenuta.
Microsoft è responsabile del rilevamento delle interruzioni, delle notifiche e del supporto per gli aspetti cloud di Azure del servizio 5G Core privato di Azure.
Rilevamento, notifica e gestione di interruzioni
Microsoft monitora le risorse sottostanti fornendo il servizio 5G Core privato di Azure in ogni area. Se queste risorse iniziano a mostrare errori o avvisi di monitoraggio dell'integrità che non sono limitati a una singola zona di disponibilità, Microsoft sposterà il servizio in un'altra area supportata nella stessa area geografica. Si tratta di un modello Attivo-Attivo. L'integrità dei servizi per una determinata area è disponibile in Integrità dei servizi di Azure (Azure Private 5G Core è elencato nella sezione Rete ). Si riceverà una notifica di eventuali errori di area tramite i normali canali di comunicazione di Azure.
Il servizio replica automaticamente le credenziali SIM di proprietà del servizio nell'area di backup usando le scritture in più aree di Cosmos DB, quindi non si verifica alcuna perdita di dati in caso di errore dell'area.
Le risorse di Base 5G private di Azure distribuite nell'area non riuscita diventeranno di sola lettura, ma le risorse in tutte le altre aree continueranno a funzionare senza modifiche. Se è necessario poter scrivere sempre le risorse, seguire le istruzioni in Configurare il ripristino di emergenza e il rilevamento di interruzioni per eseguire un'operazione di ripristino di emergenza personalizzata e configurare il servizio in un'altra area.
Il core di pacchetto in esecuzione in Edge continua a funzionare senza interruzioni e la connettività di rete verrà mantenuta.
Configurare il ripristino di emergenza e il rilevamento di interruzioni
Questa sezione descrive l'azione che è possibile eseguire per assicurarsi di avere un piano di gestione completamente attivo per il servizio 5G Core privato di Azure in caso di errore dell'area. Questa operazione è necessaria se si vuole essere in grado di modificare le risorse in caso di errore dell'area.
Si noti che questo causerà un'interruzione del servizio di base del pacchetto e interromperà la connettività di rete alle entità utente per un massimo di otto ore, pertanto è consigliabile usare questa procedura solo se si ha un motivo critico per gestire le risorse mentre l'area di Azure è inattiva.
Prima di un evento di ripristino di emergenza, è necessario eseguire il backup della configurazione delle risorse in un'altra area che supporta Azure Private 5G Core. Quando si verifica l'errore dell'area, è possibile ridistribuire il core del pacchetto usando le risorse nell'area di backup.
Preparazione
Esistono due tipi di dati di configurazione 5G Core privati di Azure di cui è necessario eseguire il backup per il ripristino di emergenza: configurazione della rete mobile e credenziali SIM. È consigliabile:
- Aggiornare le credenziali SIM nell'area di backup ogni volta che si aggiungono nuovi SIM all'area primaria
- Eseguire il backup della configurazione della rete mobile almeno una volta alla settimana o più spesso se si apportano modifiche frequenti o di grandi dimensioni alla configurazione, ad esempio la creazione di un nuovo sito.
Configurazione della rete mobile
Seguire le istruzioni in Spostare le risorse in un'area diversa per esportare la configurazione della risorsa 5G Core di Azure privata e caricarla nella nuova area. È consigliabile usare un nuovo gruppo di risorse per la configurazione di backup per separarlo chiaramente dalla configurazione attiva. È necessario assegnare alle risorse nuovi nomi per distinguerle dalle risorse nell'area primaria. Questa nuova area è un backup passivo, quindi per evitare conflitti non è necessario collegare ancora la configurazione del core del pacchetto all'hardware perimetrale. Archiviare invece i valori del campo packetCoreControlPlanes.platform per ogni core di pacchetto in un percorso sicuro accessibile da chiunque esegua la procedura di ripristino, ad esempio un account di archiviazione a cui fa riferimento la documentazione interna.
Dati SIM
Per motivi di sicurezza, Azure Private 5G Core non restituirà mai le credenziali SIM fornite al servizio durante la creazione della SIM. Pertanto, non è possibile esportare la configurazione sim nello stesso modo delle altre risorse di Azure. È consigliabile che ogni volta che vengono aggiunti nuovi SIM al servizio primario, vengono aggiunti anche gli stessi SIM al servizio di backup ripetendo il processo Provisioning di nuovi SIM per la rete mobile di backup.
Altre risorse
La distribuzione di Azure Private 5G Core può usare Azure Key Vault per archiviare chiavi di crittografia SIM o certificati HTTPS per il monitoraggio locale. È necessario seguire la documentazione di Azure Key Vault per assicurarsi che le chiavi e i certificati siano disponibili nell'area di backup.
Ripristino
In caso di errore dell'area, verificare prima di tutto che tutte le risorse nell'area di backup siano presenti eseguendo una query sulla configurazione tramite l'API o la portale di Azure (vedere Spostare le risorse in un'area diversa). Se tutte le risorse non sono presenti, arrestare qui e non seguire il resto di questa procedura. Potrebbe non essere possibile ripristinare il servizio nel sito perimetrale senza la configurazione della risorsa.
Il processo di ripristino viene suddiviso in tre fasi per ogni core di pacchetto:
- Disconnettere il dispositivo Azure Stack Edge dall'area non riuscita eseguendo una reimpostazione
- Connessione il dispositivo Azure Stack Edge nell'area di backup
- Reinstallare e convalidare l'installazione.
È necessario ripetere questo processo per ogni core di pacchetto nella rete mobile.
Attenzione
La procedura di ripristino causerà un'interruzione del servizio di base del pacchetto e interromperà la connettività di rete agli UES per un massimo di otto ore per ogni core del pacchetto. È consigliabile eseguire questa procedura solo in cui è necessario gestire la distribuzione di 5G Core privato di Azure tramite Azure durante l'errore dell'area.
Disconnettere il dispositivo Azure Stack Edge dall'area non riuscita
Il dispositivo Azure Stack Edge esegue attualmente il software di base del pacchetto ed è controllato dall'area non riuscita. Per disconnettere il dispositivo Azure Stack Edge dall'area non riuscita e rimuovere il core del pacchetto in esecuzione, è necessario seguire le istruzioni di reimpostazione e riattivazione in Reimpostare e riattivare il dispositivo Azure Stack Edge. Si noti che questo rimuoverà tutto il software attualmente in esecuzione nel dispositivo Azure Stack Edge, non solo il software di base del pacchetto, quindi assicurarsi di avere la possibilità di reinstallare qualsiasi altro software nel dispositivo. Verrà avviata un'interruzione di rete per tutti i dispositivi connessi al core del pacchetto in questo dispositivo Azure Stack Edge.
Connessione il dispositivo Azure Stack Edge nella nuova area
Seguire le istruzioni riportate in Commission the AKS cluster to ridistribuire il cluster servizio Azure Kubernetes nel dispositivo Azure Stack Edge. Assicurarsi di usare un nome diverso per questa nuova installazione per evitare conflitti quando l'area non riuscita viene ripristinata. Nell'ambito di questo processo si otterrà un nuovo ID percorso personalizzato per il cluster, che è necessario annotare.
Reinstallare e convalidare
Copiare i valori packetCoreControlPlanes.platform archiviati in Preparazione e aggiornare il campo packetCoreControlPlane.platform.customLocation con l'ID percorso personalizzato annotato in precedenza. Assicurarsi che packetCoreControlPlane.platform.azureStackEdgeDevice corrisponda all'ID del dispositivo Azure Stack Edge in cui si vuole installare il core del pacchetto. A questo fine, seguire Modificare un core di pacchetto per aggiornare il core del pacchetto di backup con i valori della piattaforma. Verrà attivata una distribuzione di base di pacchetti nel dispositivo Azure Stack Edge.
È consigliabile seguire il normale processo per convalidare una nuova installazione del sito per verificare che la connettività UE sia stata ripristinata e che tutte le funzionalità di rete siano operative. In particolare, è consigliabile verificare che i dashboard del sito nella portale di Azure mostrino registrazioni UE e che i dati vengano trasmessi attraverso il piano dati.
Area non riuscita ripristinata
Quando l'area non riuscita viene ripristinata, è necessario assicurarsi che la configurazione nelle due aree sia sincronizzata eseguendo un backup dall'area di backup attiva all'area primaria ripristinata, seguendo i passaggi descritti in Preparazione.
È anche necessario verificare e rimuovere tutte le risorse nell'area ripristinata che non sono state eliminate definitivamente dai passaggi precedenti:
- Per ogni dispositivo Azure Stack Edge spostato nell'area di backup (seguendo la procedura descritta in Ripristino) è necessario trovare ed eliminare la risorsa cluster ARC precedente. L'ID di questa risorsa si trova nel campo packetCoreControlPlane.platform.customLocation dai valori di cui è stato eseguito il backup in Preparazione. Lo stato di questa risorsa verrà disconnesso perché il cluster Kubernetes corrispondente è stato eliminato come parte del processo di ripristino.
- Per ogni core di pacchetto spostato nell'area di backup (seguendo la procedura descritta in Ripristino) è necessario trovare ed eliminare tutti gli oggetti NFM nell'area ripristinata. Questi verranno elencati nello stesso gruppo di risorse delle risorse del piano di controllo di base del pacchetto e il valore region corrisponderà all'area ripristinata.
Si hanno quindi due opzioni per la gestione continuativa:
- Usare l'area di backup operativa come nuova area primaria e usare l'area ripristinata come backup. Non è richiesta alcuna azione ulteriore.
- Rendere l'area ripristinata la nuova area primaria attiva seguendo le istruzioni riportate in Spostare le risorse in un'area diversa per tornare all'area ripristinata.
Test in corso
Per testare i piani di ripristino di emergenza, è possibile seguire la procedura di ripristino per un singolo core di pacchetti in qualsiasi momento. Si noti che ciò causerà un'interruzione del servizio di base del pacchetto e interromperà la connettività di rete alle UES per un massimo di quattro ore, quindi è consigliabile farlo solo con distribuzioni core di pacchetti non di produzione o in un momento in cui un'interruzione non influisce negativamente sull'azienda.