Completare le attività preliminari per la distribuzione di una rete mobile privata

In questa guida pratica si eseguiranno tutte le attività da completare prima di poter distribuire una rete mobile privata usando Azure Private 5G Core.

Strumenti e accesso

Per distribuire la rete mobile privata usando Azure Private 5G Core, è necessario:

• Un PC Windows con accesso a Internet
• Un account di Windows Amministrazione istrator su tale PC
• Interfaccia della riga di comando di Azure
• PowerShell
• kubectl

Ottenere l'accesso ad Azure Private 5G Core per la sottoscrizione di Azure

Contattare il tecnico delle versioni di valutazione e chiedere loro di registrare la sottoscrizione di Azure per l'accesso ad Azure Private 5G Core. Se non si ha già un tecnico di prova e si è interessati alla valutazione di Azure Private 5G Core, contattare il team dell'account Microsoft o esprimere l'interesse tramite il modulo di registrazione del partner.

Scegliere il tipo di tecnologia principale (5G, 4G o combinato 4G e 5G)

Scegliere se ogni sito nella rete mobile privata deve fornire copertura per 5G, 4G o apparecchiature utente combinate 4G e 5G. Se si distribuiscono più siti, ognuno può supportare diversi tipi di tecnologia di base.

Scegliere una distribuzione standard o a disponibilità elevata

Azure Private 5G Core viene distribuito come cluster del servizio Azure Kubernetes servizio Azure Kubernetes. Questo cluster può essere eseguito in un singolo dispositivo Azure Stack Edge (A edizione Standard) o in una coppia di dispositivi A edizione Standard per un servizio a disponibilità elevata.This cluster can run on a single Azure Stack Edge (A edizione Standard) device, or on a pair of A edizione Standard devices for a highly available (HA). Una distribuzione a disponibilità elevata consente di gestire il servizio in caso di errore hardware A edizione Standard.

Per una distribuzione a disponibilità elevata, è necessario distribuire un router gateway (rigorosamente un dispositivo con supporto di livello 3, ovvero un router o un commutatore L3 (router/commutatore ibrido) tra il cluster A edizione Standard e:

• apparecchiature RAN nella rete di accesso.
• le reti dati.

Il router gateway deve supportare il rilevamento dell'inoltro bidirezionale (BFD) e gli SSP compatibili con Mellanox (moduli collegabili a fattori di forma di piccole dimensioni).

È necessario progettare la rete per tollerare un errore di un router gateway nella rete di accesso o in una rete dati. AP5GC supporta solo un singolo indirizzo IP del router del gateway per ogni rete. Pertanto, solo una progettazione di rete in cui è presente un singolo router gateway per rete o in cui i router del gateway vengono distribuiti in coppie ridondanti in una configurazione attiva/standby con un indirizzo IP del gateway mobile è supportato. I router gateway in ogni coppia ridondante devono monitorarsi tra loro usando VRRP (Virtual Router Redundancy Protocol) per fornire il rilevamento dell'errore del partner.

Topologie di rete del cluster

AP5GC HA si basa su una piattaforma che comprende un cluster a due nodi di dispositivi A edizione Standard. Le A edizione Standard sono connesse a un dominio di trasmissione L2 comune e a una subnet IP nella rete di accesso (oppure due domini L2 comuni, uno per N2 e uno per N3, usando VLAN) e in ognuna delle reti principali. Condividono anche un dominio di trasmissione L2 e una subnet IP nella rete di gestione.

Quorum e server di controllo del cluster

Un cluster A edizione Standard a due nodi richiede un cluster di controllo, in modo che se uno dei nodi A edizione Standard ha esito negativo, il cluster di controllo account per il terzo voto e il cluster rimane online. Il cluster di controllo viene eseguito nel cloud di Azure.

Per configurare un server di controllo cloud di Azure, vedere https://learn.microsoft.com/windows-server/failover-clustering/deploy-cloud-witness. Il campo Replica deve essere impostato sull'archiviazione con ridondanza locale. I firewall tra il cluster A edizione Standard e l'account di archiviazione di Azure devono consentire il traffico in uscita a https://.core.windows.net/ sulla porta 443 (HTTPS).

Allocare subnet e indirizzi IP

Azure Private 5G Core richiede una rete di gestione, una rete di accesso e fino a dieci reti dati. Queste reti possono far parte della stessa rete più grande o possono essere separate. L'approccio usato dipende dai requisiti di separazione del traffico.

Per ognuna di queste reti, allocare una subnet e quindi identificare gli indirizzi IP elencati. Se si distribuiscono più siti, è necessario raccogliere queste informazioni per ogni sito.

A seconda dei requisiti di rete, ad esempio se è disponibile un set limitato di subnet, è possibile scegliere di allocare una singola subnet per tutte le interfacce di Azure Stack Edge, contrassegnate con un asterisco (*) nell'elenco seguente.

Rete di gestione

Accedere alla rete

Sarà necessaria una subnet IP per il traffico del piano di controllo e una subnet IP per il traffico del piano utente. Se il piano di controllo e il piano utente si trovano nella stessa VLAN (o non sono contrassegnati con VLAN), è possibile usare una singola subnet IP per entrambi.

Reti di dati

Allocare gli indirizzi IP seguenti per ogni rete dati nel sito:

• Indirizzo di rete nella notazione CIDR.
• Gateway predefinito.
• Un indirizzo IP per l'interfaccia del piano utente.
  • Per il 5G, questa è l'interfaccia N6
  • Per il 4G, questa è l'interfaccia SGi.
  • Per la combinazione di 4G e 5G, questa è l'interfaccia N6/SGi.

Gli indirizzi IP seguenti devono essere usati da tutte le reti dati nel sito:

Indirizzi IP virtuali aggiuntivi (solo disponibilità elevata)

Per una distribuzione a disponibilità elevata sono necessari gli indirizzi IP virtuali seguenti. Questi indirizzi IP NON DEVONO trovarsi in nessun piano di controllo o subnet del piano utente. Vengono usati come destinazioni di route statiche nei router del gateway di rete di accesso. Ovvero, possono essere qualsiasi indirizzo IP valido non incluso in alcuna subnet configurata nella rete di accesso.

• Un indirizzo virtuale da usare come indirizzo N2 virtuale. L'apparecchiatura RAN è configurata per l'utilizzo di questo indirizzo.
• Un indirizzo virtuale da usare come endpoint del tunnel virtuale nel punto di riferimento N3.

VLAN

Facoltativamente, è possibile configurare il dispositivo Azure Stack Edge Pro con tag VLAN (Virtual Local Area Network). È possibile usare questa configurazione per abilitare la separazione del traffico di livello 2 nelle interfacce N2, N3 e N6 o negli equivalenti 4G. Ad esempio, il dispositivo A edizione Standard ha una singola porta per il traffico N2 e N3 e una singola porta per tutto il traffico di rete dati. È possibile usare tag VLAN per separare il traffico N2 e N3 o separare il traffico per ogni rete dati connessa.

Allocare gli ID VLAN per ogni rete in base alle esigenze.

Se si usano VLAN per separare il traffico per ogni rete dati, è necessaria una subnet locale per le porte rivolte alla rete dati che coprono la VLAN predefinita (VLAN 0). Per la disponibilità elevata, è necessario assegnare l'indirizzo IP del router del gateway all'interno di questa subnet.

Allocare pool di indirizzi IP di apparecchiature utente (UE)

Azure Private 5G Core supporta i metodi di allocazione degli indirizzi IP seguenti per le entità utente.

• Dinamico. L'allocazione di indirizzi IP dinamici assegna automaticamente un nuovo indirizzo IP a un UE ogni volta che si connette alla rete mobile privata.

• Statico. L'allocazione degli indirizzi IP statici garantisce che un UE riceva lo stesso indirizzo IP ogni volta che si connette alla rete mobile privata. Gli indirizzi IP statici sono utili quando si vuole che le applicazioni IoT (Internet of Things) siano in grado di connettersi in modo coerente allo stesso dispositivo. Ad esempio, è possibile configurare un'applicazione di analisi video con gli indirizzi IP delle fotocamere che forniscono flussi video. Se queste telecamere hanno indirizzi IP statici, non sarà necessario riconfigurare l'applicazione di analisi video con nuovi indirizzi IP a ogni riavvio delle telecamere. Gli indirizzi IP statici verranno allocati a un'UE come parte del provisioning della sim.

È possibile scegliere di supportare uno o entrambi questi metodi per ogni rete dati nel sito.

Per ogni rete dati che si sta distribuendo:

• Decidere quali metodi di allocazione degli indirizzi IP si desidera supportare.

• Per ogni metodo che si vuole supportare, identificare un pool di indirizzi IP da cui è possibile allocare gli indirizzi IP alle ENTITÀ. È necessario specificare ogni pool di indirizzi IP nella notazione CIDR.

  Se si decide di supportare entrambi i metodi per una determinata rete dati, assicurarsi che i pool di indirizzi IP siano della stessa dimensione e non si sovrappongano.

• Decidere se si vuole abilitare Network Address and Port Translation (NAPT) per la rete dati. NAPT consente di convertire un ampio pool di indirizzi IP privati per gli utenti finali in un piccolo pool di indirizzi IP pubblici. La traduzione viene eseguita nel punto in cui il traffico entra nella rete dati, ottimizzando l'utilità di una fornitura limitata di indirizzi IP pubblici.

Configurare i server DNS (Domain Name System)

DNS consente la conversione tra i nomi di dominio leggibili e i relativi indirizzi IP leggibili dal computer associati. A seconda dei requisiti, sono disponibili le seguenti opzioni per la configurazione di un server DNS per la rete dati:

• Se sono necessari gli oggetti delle apparecchiature utente connessi a questa rete dati per risolvere i nomi di dominio, è necessario configurare uno o più server DNS. È necessario utilizzare un server DNS privato se si desidera la risoluzione DNS di nomi di host interni. Se si fornisce accesso a Internet solo a nomi DNS pubblici, è possibile utilizzare un server DNS pubblico o privato.
• Se non è necessario che le apparecchiature utente eseguano la risoluzione DNS o se tutte le unità utente nella rete useranno i propri server DNS configurati in locale (anziché i server DNS segnalati dal core del pacchetto), è possibile omettere questa configurazione.

Configurare

Preparare le reti

Per ogni sito che si sta distribuendo:

• Assicurarsi di disporre di almeno un commutatore di rete con almeno tre porte disponibili. Ogni dispositivo Azure Stack Edge Pro verrà connesso allo switch(es) nello stesso sito come parte delle istruzioni riportate in Ordine e configurare i dispositivi Azure Stack Edge Pro.
• Per ogni rete in cui si è deciso di non abilitare NAPT (come descritto in Allocare pool di indirizzi IP UE), configurare la rete dati per instradare il traffico destinato ai pool di indirizzi IP UE tramite l'indirizzo IP allocato all'interfaccia del piano utente dell'istanza di base del pacchetto nella rete dati.

Configurare le porte per l'accesso locale

Requisiti delle porte per Azure Stack Edge

Requisiti delle porte per IoT Edge

Requisiti delle porte per Kubernetes in Azure Stack Edge

Porte del firewall in uscita necessarie

Esaminare e applicare le raccomandazioni del firewall per i servizi seguenti:

La tabella seguente contiene i modelli di URL per il traffico in uscita di Azure Private 5G Core.

Registrare i provider di risorse

Per usare Azure Private 5G Core, è necessario registrare alcuni provider di risorse aggiuntivi con la sottoscrizione di Azure.

1. Accedere all'interfaccia della riga di comando di Azure con un account utente associato al tenant di Azure in cui si distribuisce Azure Private 5G Core:

   az login
   

   Suggerimento

   Per istruzioni complete, vedere Accedere in modo interattivo.

2. Se l'account ha più sottoscrizioni, assicurarsi di averne una corretta:

   az account set --subscription <subscription_id>
   

3. Controllare la versione dell'interfaccia della riga di comando di Azure:

   az version
   

   Se la versione dell'interfaccia della riga di comando è inferiore alla 2.37.0, è necessario aggiornare l'interfaccia della riga di comando di Azure a una versione più recente. Vedere Come aggiornare l'interfaccia della riga di comando di Azure.

4. Registrare i provider di risorse seguenti:

   az provider register --namespace Microsoft.MobileNetwork
   az provider register --namespace Microsoft.HybridNetwork
   az provider register --namespace Microsoft.ExtendedLocation
   az provider register --namespace Microsoft.Kubernetes
   az provider register --namespace Microsoft.KubernetesConfiguration
   

Recuperare l'ID oggetto (OID)

È necessario ottenere l'ID oggetto (OID) del provider di risorse percorso personalizzato nel tenant di Azure. È necessario specificare questo OID quando si crea il servizio Kubernetes. È possibile ottenere l'OID usando l'interfaccia della riga di comando di Azure o Azure Cloud Shell nel portale. È necessario essere un proprietario della sottoscrizione di Azure.

1. Accedere all'interfaccia della riga di comando di Azure o ad Azure Cloud Shell.

2. Recuperare l'OID:

   az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv
   

Questo comando esegue una query sul percorso personalizzato e restituisce una stringa OID. Salvare questa stringa per usarla in un secondo momento quando si esegue il commissioning del dispositivo Azure Stack Edge.

Ordinare e configurare i dispositivi Azure Stack Edge Pro

Completare le operazioni seguenti per ogni sito da aggiungere alla rete mobile privata. Le istruzioni dettagliate per eseguire ogni passaggio sono incluse nella colonna Istruzioni dettagliate, se applicabile.

Passaggi successivi

È ora possibile commissionare il cluster servizio Azure Kubernetes (AKS) nel dispositivo Azure Stack Edge Pro 2 o Azure Stack Edge Pro GPU per prepararlo alla distribuzione di Azure Private 5G Core.

• Creare un cluster del servizio Azure Kubernetes