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 Private 5G Core di Azure.
Suggerimento
Requisiti di progettazione della rete mobile privata contiene i requisiti di progettazione di rete completi per una rete personalizzata.
Strumenti e accesso
Per distribuire la rete mobile privata usando Private 5G Core di Azure, è necessario:
- Un PC Windows con accesso a Internet
- Un account amministratore di Windows in tale PC
- Interfaccia della riga di comando di Azure
- PowerShell
- kubectl
Ottenere l'accesso a Private 5G Core di Azure per la sottoscrizione di Azure
Contattare il tecnico delle versioni di valutazione e chiedergli di registrare la sottoscrizione di Azure per l'accesso a Private 5G Core di Azure. Se non si ha già un tecnico delle versioni di prova e si è interessati alla valutazione di Private 5G Core di Azure, contattare il team dell'account Microsoft o esprimere il proprio interesse tramite il modulo di registrazione partner.
Scegliere il tipo di tecnologia principale (5G, 4G o 4G e 5G combinate)
Scegliere se ogni sito nella rete mobile privata deve fornire copertura per apparecchiature utente 5G, 4G o 4G e 5G combinate. Se si distribuiscono più siti, ognuno può supportare diversi tipi di tecnologia principale.
Scegliere una distribuzione standard o a disponibilità elevata
Private 5G Core di Azure viene distribuito come cluster del servizio Azure Kubernetes. Questo cluster può essere eseguito in un singolo dispositivo Azure Stack Edge (ASE) o in una coppia di dispositivi ASE per un servizio a disponibilità elevata. Una distribuzione a disponibilità elevata consente di mantenere il servizio in caso di errore hardware ASE.
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 ASE e:
- l'apparecchiatura RAN nella rete di accesso.
- le reti dati.
Il router gateway deve supportare il rilevamento dell'inoltro bidirezionale e gli SFP (moduli collegabili a fattore di forma ridotto) compatibili con Mellanox.
È necessario progettare la rete per tollerare un errore di un router gateway nella rete di accesso o in una rete dati. P5GC di Azure supporta solo un singolo indirizzo IP del router gateway per ogni rete. Pertanto, è supportata solo una progettazione di rete in cui è presente un singolo router gateway per ogni rete o in cui i router gateway vengono distribuiti in coppie ridondanti in una configurazione attiva/standby con un indirizzo IP del gateway mobile. I router gateway in ogni coppia ridondante devono monitorarsi tra loro usando il protocollo VRRP (Virtual Router Redundancy Protocol) per fornire il rilevamento dell'errore del partner.
Topologie di rete di cluster
La disponibilità elevata di P5GC di Azure si basa su una piattaforma che comprende un cluster a due nodi di dispositivi ASE. Gli ASE sono connessi a un dominio broadcast L2 comune e a una subnet IP nella rete di accesso (oppure a 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.
Vedere Topologie di rete supportate. È consigliabile usare l'Opzione 1 - Porta 1 e Porta 2 sono in subnet diverse. Vengono creati commutatori virtuali separati. La Porta 3 e la Porta 4 si connettono a un commutatore virtuale esterno.
Vedere Topologie di rete supportate. È consigliabile usare l'Opzione 2 - Usare commutatori e gruppo NIC per la massima protezione dagli errori. È anche accettabile usare un solo commutatore se lo si preferisce (Opzione 3), ma ciò comporterà un rischio maggiore di tempo di inattività in caso di errore di un commutatore. L'uso della topologia senza commutatore (Opzione 1) è possibile, ma non è consigliato a causa del rischio ancora più elevato di tempi di inattività. L'Opzione 3 fa sì che ogni ASE crei automaticamente un commutatore virtuale Hyper-V (vswitch) e vi aggiunga le porte.
Quorum del cluster e cluster di controllo
Un cluster ASE a due nodi richiede un cluster di controllo, in modo che se uno dei nodi ASE ha esito negativo, il cluster di controllo rappresenta il terzo voto e il cluster rimane online. Il cluster di controllo viene eseguito nel cloud di Azure.
Per configurare un cloud di controllo di Azure, vedere https://learn.microsoft.com/windows-server/failover-clustering/deploy-cloud-witness. Il campo Replica deve essere impostato su Archiviazione con ridondanza locale. I firewall tra il cluster ASE 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
Private 5G Core di Azure richiede una rete di gestione, una rete di accesso e fino a dieci reti dati. Queste reti possono far parte di un'unica 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.
Nota
I requisiti aggiuntivi per una distribuzione a disponibilità elevata sono elencati in linea.
Rete di gestione
- Indirizzo di rete nella notazione CIDR (Classless Inter-Domain Routing).
- Gateway predefinito.
- Un indirizzo IP per la porta di gestione (porta 2) nel dispositivo Azure Stack Edge Pro 2.
- Disponibilità elevata: quattro indirizzi IP (due per ogni dispositivo Azure Stack Edge).
- Sei indirizzi IP sequenziali per i nodi del cluster del servizio Azure Kubernetes in Azure Stack HCI (AKS-HCI).
- Disponibilità elevata: sette indirizzi IP sequenziali.
- Un indirizzo IP del servizio per l'accesso agli strumenti di monitoraggio locali per l'istanza Packet Core.
Indirizzi IP aggiuntivi per il cluster Azure Stack Edge a due nodi in una distribuzione a disponibilità elevata:
- Un indirizzo IP virtuale per ACS (Azure Consistency Services).
- Un indirizzo IP virtuale per NFS (Network File Services).
- Indirizzo di rete nella notazione CIDR (Classless Inter-Domain Routing).
- Gateway predefinito.
- Un indirizzo IP per la porta di gestione
- Scegliere una porta tra 2 e 4 da usare come porta di gestione del dispositivo Azure Stack Edge Pro GPU come parte della configurazione del dispositivo Azure Stack Edge Pro.*
- Disponibilità elevata: due indirizzi IP (uno per ogni dispositivo Azure Stack Edge)
- Sei indirizzi IP sequenziali per i nodi del cluster del servizio Azure Kubernetes in Azure Stack HCI (AKS-HCI).
- Disponibilità elevata: sette indirizzi IP sequenziali.
- Un indirizzo IP del servizio per l'accesso agli strumenti di monitoraggio locali per l'istanza Packet Core.
Indirizzi IP aggiuntivi per il cluster Azure Stack Edge a due nodi in una distribuzione a disponibilità elevata:
- Un indirizzo IP virtuale per ACS (Azure Consistency Services).
- Un indirizzo IP virtuale per NFS (Network File Services).
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.
- Indirizzo di rete nella notazione CIDR.
- Gateway predefinito.
- Un indirizzo IP per l'interfaccia del piano di controllo.
- Per il 5G, si tratta dell'interfaccia N2
- Per il 4G, si tratta dell'interfaccia S1-MME.
- Per la combinazione di 4G e 5G, si tratta dell'interfaccia N2/S1-MME.
- Un indirizzo IP per l'interfaccia del piano utente.
- Per il 5G, si tratta dell'interfaccia N3
- Per il 4G, si tratta dell'interfaccia S1-UE.
- Per la combinazione di 4G e 5G, si tratta dell'interfaccia N3/S1-U.
- Un indirizzo IP per la porta 3 nel dispositivo Azure Stack Edge Pro 2.
- Piano di controllo a disponibilità elevata:
- indirizzo IP del router gateway.
- due indirizzi IP (uno per ogni ASE) da usare come indirizzi vNIC nelle funzioni AMF.
- Piano utente a disponibilità elevata:
- indirizzo IP del router gateway.
- due indirizzi IP (uno per ogni ASE) da usare come indirizzi vNIC nelle interfacce UPF alla subnet di accesso locale.
- Indirizzo di rete nella notazione CIDR.
- Gateway predefinito.
- Un indirizzo IP per l'interfaccia del piano di controllo.
- Per il 5G, si tratta dell'interfaccia N2
- Per il 4G, si tratta dell'interfaccia S1-MME.
- Per la combinazione di 4G e 5G, si tratta dell'interfaccia N2/S1-MME.
- Un indirizzo IP per l'interfaccia del piano utente.
- Per il 5G, si tratta dell'interfaccia N3
- Per il 4G, si tratta dell'interfaccia S1-UE.
- Per la combinazione di 4G e 5G, si tratta dell'interfaccia N3/S1-U.
- Un indirizzo IP per la porta 5 nel dispositivo Azure Stack Edge Pro GPU.
- Piano di controllo a disponibilità elevata:
- indirizzo IP del router gateway.
- due indirizzi IP (uno per ogni ASE) da usare come indirizzi vNIC nelle funzioni AMF.
- Piano utente a disponibilità elevata:
- indirizzo IP del router gateway.
- due indirizzi IP (uno per ogni ASE) da usare come indirizzi vNIC nelle interfacce UPF alla subnet di accesso locale.
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, si tratta dell'interfaccia N6
- Per il 4G, si tratta dell'interfaccia SGi.
- Per la combinazione di 4G e 5G, si tratta dell'interfaccia N6/SGi.
Gli indirizzi IP seguenti devono essere usati da tutte le reti dati nel sito:
- Un indirizzo IP per tutte le reti dati sulla porta 3 nel dispositivo Azure Stack Edge Pro 2.
- Un indirizzo IP per tutte le reti dati sulla porta 4 nel dispositivo Azure Stack Edge Pro 2.
- Disponibilità elevata: indirizzo IP del router gateway.
- Disponibilità elevata: due indirizzi IP (uno per ogni ASE) da usare come indirizzi vNIC nelle interfacce UPF alla rete dati.
- Un indirizzo IP per tutte le reti dati sulla porta 5 nel dispositivo Azure Stack Edge Pro GPU.
- Un indirizzo IP per tutte le reti dati sulla porta 6 nel dispositivo Azure Stack Edge Pro GPU.
- Disponibilità elevata: indirizzo IP del router gateway.
- Disponibilità elevata: due indirizzi IP (uno per ogni ASE) da usare come indirizzi vNIC nelle interfacce UPF alla rete dati.
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 nessuna subnet del piano di controllo o del piano utente. Vengono usati come destinazioni di route statiche nei router gateway di rete di accesso. Ovvero, può trattarsi di 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 (LAN virtuale). È 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 ASE 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 gateway all'interno di questa subnet.
Allocare pool di indirizzi IP di apparecchiature utente
Private 5G Core di Azure supporta i metodi di allocazione degli indirizzi IP seguenti per le apparecchiature utente.
Dinamico. L'allocazione di indirizzi IP dinamici assegna automaticamente un nuovo indirizzo IP a un'apparecchiatura utente ogni volta che si connette alla rete mobile privata.
Statico. L'allocazione degli indirizzi IP statici garantisce che un'apparecchiatura utente 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 delle cose) 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'apparecchiatura utente 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 apparecchiature utente. È 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 NAPT (Network Address and Port Translation) per la rete dati. NAPT consente di convertire un ampio pool di indirizzi IP privati per le apparecchiature utente in un piccolo pool di indirizzi IP pubblici. La conversione 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)
Importante
Se non si configurano i server DNS per una rete dati, tutte le apparecchiature utente che usano tale rete non potranno risolvere i nomi di dominio.
DNS consente la conversione tra i nomi di dominio leggibili e i relativi indirizzi IP associati leggibili dal computer. 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 al commutatore o ai commutatori nello stesso sito come parte delle istruzioni riportate in Ordinare 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 delle apparecchiature utente), configurare la rete dati per instradare il traffico destinato ai pool di indirizzi IP delle apparecchiature utente tramite l'indirizzo IP allocato all'interfaccia del piano utente dell'istanza Packet Core nella rete dati.
Configurare le porte per l'accesso locale
Le tabelle seguenti contengono le porte da aprire per l'accesso locale a Private 5G Core di Azure. Questo include l'accesso alla gestione locale e la segnalazione del piano di controllo.
È necessario configurarle in aggiunta alle porte necessarie per Azure Stack Edge (ASE).
Private 5G Core di Azure
Porta | Interfaccia ASE | Descrizione |
---|---|---|
TCP 443 In ingresso | Gestione (LAN) | Accesso agli strumenti di monitoraggio locali (dashboard Packet Core e traccia distribuita). |
5671 In ingresso/uscita | Gestione (LAN) | Comunicazione con Hub eventi di Azure, protocollo AMQP |
5672 In ingresso/uscita | Gestione (LAN) | Comunicazione con Hub eventi di Azure, protocollo AMQP |
UDP 1812 In ingresso/uscita | Gestione (LAN) | Autenticazione con un server AAA RADIUS. Obbligatorio solo quando RADIUS è in uso. |
SCTP 38412 In ingresso | Porta 3 (rete di accesso) | Segnalazione di accesso del piano di controllo (interfaccia N2). Obbligatorio solo per le distribuzioni 5G. |
SCTP 36412 In ingresso | Porta 3 (rete di accesso) | Segnalazione di accesso del piano di controllo (interfaccia S1-MME). Obbligatorio solo per le distribuzioni 4G. |
UDP 2152 In ingresso/uscita | Porta 3 (rete di accesso) | Accedere ai dati del piano utente di rete (interfaccia N3 per 5G, S1-U per 4G o N3/S1-U per 4G e 5G combinate). |
Tutto il traffico IP | Porte 3 e 4 (reti dati) | Dati del piano utente di rete dati (interfaccia N6 per 5G, SGi per 4G o N6/SGi per 4G e 5G combinate). Obbligatorio solo sulla porta 3 se le reti dati sono configurate su tale porta. |
Le tabelle seguenti contengono le porte da aprire per l'accesso locale a Private 5G Core di Azure. Questo include l'accesso alla gestione locale e la segnalazione del piano di controllo.
È necessario configurarle in aggiunta alle porte necessarie per Azure Stack Edge (ASE).
Private 5G Core di Azure
Porta | Interfaccia ASE | Descrizione |
---|---|---|
TCP 443 In ingresso | Gestione (LAN) | Accesso agli strumenti di monitoraggio locali (dashboard Packet Core e traccia distribuita). |
5671 In ingresso/uscita | Gestione (LAN) | Comunicazione con Hub eventi di Azure, protocollo AMQP |
5672 In ingresso/uscita | Gestione (LAN) | Comunicazione con Hub eventi di Azure, protocollo AMQP |
UDP 1812 In ingresso/uscita | Gestione (LAN) | Autenticazione con un server AAA RADIUS. Obbligatorio solo quando RADIUS è in uso. |
SCTP 38412 In ingresso | Porta 5 (rete di accesso) | Segnalazione di accesso del piano di controllo (interfaccia N2). Obbligatorio solo per le distribuzioni 5G. |
SCTP 36412 In ingresso | Porta 5 (rete di accesso) | Segnalazione di accesso del piano di controllo (interfaccia S1-MME). Obbligatorio solo per le distribuzioni 4G. |
UDP 2152 In ingresso/uscita | Porta 5 (rete di accesso) | Accedere ai dati del piano utente di rete (interfaccia N3 per 5G, S1-U per 4G o N3/S1-U per 4G e 5G combinate). |
Tutto il traffico IP | Porte 5 e 6 (reti dati) | Dati del piano utente di rete dati (interfaccia N6 per 5G, SGi per 4G o N6/SGi per 4G e 5G combinate). Obbligatorio solo sulla porta 5 se le reti dati sono configurate su tale porta. |
Requisiti delle porte per Azure Stack Edge
N. porta | In/Out | Ambito porta | Richiesto | Note |
---|---|---|---|---|
UDP 123 (NTP) | Verso l'esterno | WAN | In alcuni casi | Questa porta è necessaria solo se si usa un server NTP locale o un server basato su Internet per ASE. |
UDP 53 (DNS) | Verso l'esterno | WAN | In alcuni casi | Vedere Configurare i server DNS (Domain Name System). |
TCP 5985 (WinRM) | Out/In | LAN | Sì | Obbligatorio per la connessione di Gestione remota Windows ad ASE tramite PowerShell durante la distribuzione di P5GC di Azure. Vedere Eseguire il commissioning di un cluster del servizio Azure Kubernetes. |
TCP 5986 (WinRM) | Out/In | LAN | Sì | Obbligatorio per la connessione di Gestione remota Windows ad ASE tramite PowerShell durante la distribuzione di P5GC di Azure. Vedere Eseguire il commissioning di un cluster del servizio Azure Kubernetes. |
UDP 67 (DHCP) | Verso l'esterno | LAN | Sì | |
TCP 445 (SMB) | In | LAN | No | ASE per P5GC di Azure non richiede un file server locale. |
TCP 2049 (NFS) | In | LAN | No | ASE per P5GC di Azure non richiede un file server locale. |
Requisiti delle porte per IoT Edge
N. porta | In/Out | Ambito porta | Richiesto | Note |
---|---|---|---|---|
TCP 443 (HTTPS) | Verso l'esterno | WAN | No | Questa configurazione è necessaria solo quando si usano script manuali o il servizio Device Provisioning di Azure IoT. |
Requisiti delle porte per Kubernetes in Azure Stack Edge
N. porta | In/Out | Ambito porta | Richiesto | Note |
---|---|---|---|---|
TCP 31000 (HTTPS) | In | LAN | Sì | Obbligatorio per il dashboard di Kubernetes per monitorare il dispositivo. |
TCP 6443 (HTTPS) | In | LAN | Sì | Obbligatorio per l'accesso kubectl |
Porte del firewall in uscita obbligatorie
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 Private 5G Core di Azure.
Modello URL | Descrizione |
---|---|
https://*.azurecr.io |
Obbligatorio per eseguire il pull delle immagini del contenitore per i carichi di lavoro di Private 5G Core di Azure. |
https://*.microsoftmetrics.com https://*.hot.ingestion.msftcloudes.com |
Obbligatorio per il monitoraggio e la telemetria per il servizio Private 5G Core di Azure. |
Registrare i provider di risorse
Per usare Private 5G Core di Azure, è necessario registrare alcuni provider di risorse aggiuntivi con la sottoscrizione di Azure.
Suggerimento
Se l'interfaccia della riga di comando di Azure non è installata, vedere le istruzioni di installazione in Come installare l'interfaccia della riga di comando di Azure. In alternativa, è possibile usare Azure Cloud Shell sul portale.
Accedere all'interfaccia della riga di comando di Azure con un account utente associato al tenant di Azure in cui si distribuisce Private 5G Core di Azure:
az login
Suggerimento
Per istruzioni complete, vedere Accedere in modo interattivo.
Se l'account ha più sottoscrizioni, assicurarsi di averne una corretta:
az account set --subscription <subscription_id>
Controllare la versione dell'interfaccia della riga di comando di Azure:
az version
Se la versione dell'interfaccia della riga di comando è precedente 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.
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 del 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.
Accedere all'interfaccia della riga di comando di Azure o ad Azure Cloud Shell.
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.
Passaggio n. | Descrizione | Istruzioni dettagliate |
---|---|---|
1. | Completare l'elenco di controllo per la distribuzione di Azure Stack Edge Pro 2. | Elenco di controllo della distribuzione per il dispositivo Azure Stack Edge Pro 2 |
2. | Ordinare e preparare il dispositivo Azure Stack Edge Pro 2. | Esercitazione: Preparare la distribuzione di Azure Stack Edge Pro 2 |
3. | Installare in rack e cablare il dispositivo Azure Stack Edge Pro 2. Quando si esegue questa procedura, è necessario assicurarsi che il dispositivo abbia le porte connesse come segue: - Porta 2 - Gestione - Porta 3 - Rete di accesso (e facoltativamente, reti dati) - Porta 4 - Reti dati |
Esercitazione: Installare Azure Stack Edge Pro 2 |
4. | Connettersi al dispositivo Azure Stack Edge Pro 2 usando l'interfaccia utente Web locale. | Esercitazione: Connettersi ad Azure Stack Edge Pro 2 |
5. | Configurare la rete per il dispositivo Azure Stack Edge Pro 2. Nota: quando un ASE viene usato in un servizio Private 5G Core di Azure, la porta 2 viene usata per la gestione anziché per i dati. L'esercitazione collegata presuppone un ASE generico che usa la porta 2 per i dati. Se l'operatore RAN e Packet Core si trovano nella stessa subnet, non è necessario configurare un gateway per la porta 3 o la porta 4. È anche possibile configurare facoltativamente il dispositivo Azure Stack Edge Pro per l'esecuzione dietro un proxy Web. Verificare che le connessioni in uscita dal dispositivo Azure Stack Edge Pro agli endpoint di Azure Arc siano aperte. Non configurare commutatori virtuali, reti virtuali o IP di calcolo. |
Esercitazione: Configurare la rete per Azure Stack Edge Pro 2 (facoltativamente) Configurare il proxy Web per Azure Stack Edge Pro Requisiti di rete di Azure Arc Requisiti dell'agente di Azure Arc |
6. | Configurare un nome, un nome DNS e (facoltativamente) le impostazioni dell'ora. Non configurare un aggiornamento. |
Esercitazione: Configurare le impostazioni del dispositivo per Azure Stack Edge Pro 2 |
7. | Configurare i certificati e configurare la crittografia dei dati inattivi per il dispositivo Azure Stack Edge Pro 2. Dopo aver modificato i certificati, potrebbe essere necessario riaprire l'interfaccia utente locale in una nuova finestra del browser per impedire che i vecchi certificati memorizzati nella cache causino problemi. | Esercitazione: Configurare i certificati per Azure Stack Edge Pro 2 |
8. | Attivare il dispositivo Azure Stack Edge Pro 2. Non seguire la sezione Distribuire carichi di lavoro. |
Esercitazione: Attivare Azure Stack Edge Pro 2 |
9. | Abilitare la gestione della macchina virtuale dal portale di Azure. L'abilitazione di questa opzione subito dopo l'attivazione del dispositivo Azure Stack Edge Pro 2 causa occasionalmente un errore. Attendere un minuto e riprovare. |
Passare alla risorsa ASE nel portale di Azure, passare a Servizi perimetrali, selezionare Macchine virtuali e selezionare Abilita. |
10. | Eseguire i test di diagnostica per il dispositivo Azure Stack Edge Pro 2 nell'interfaccia utente Web locale e verificare che vengano superati tutti. Potrebbe essere visualizzato un avviso relativo a una porta disconnessa e inutilizzata. È consigliabile risolvere il problema se l'avviso si riferisce a una di queste porte: - Porta 2 - Gestione - Porta 3 - Rete di accesso (e facoltativamente, reti dati) - Porta 4 - Reti dati Per tutte le altre porte, è possibile ignorare l'avviso. In caso di errori, risolverli prima di continuare con i passaggi rimanenti. Sono inclusi eventuali errori correlati a gateway non validi sulle porte inutilizzate. In questo caso, eliminare l'indirizzo IP del gateway o impostarlo su un gateway valido per la subnet. |
Eseguire la diagnostica, raccogliere i log per risolvere i problemi dei dispositivi Azure Stack Edge |
Importante
È necessario assicurarsi che il dispositivo Azure Stack Edge Pro 2 sia compatibile con la versione di Private 5G Core di Azure che si intende installare. Vedere Compatibilità di Packet Core e Azure Stack Edge (ASE). Se è necessario aggiornare il dispositivo Azure Stack Edge Pro 2, vedere Aggiornare Azure Stack Edge Pro 2.
Passaggio n. | Descrizione | Istruzioni dettagliate |
---|---|---|
1. | Completare l'elenco di controllo per la distribuzione di Azure Stack Edge Pro GPU. | Elenco di controllo della distribuzione per il dispositivo Azure Stack Edge Pro GPU |
2. | Ordinare e preparare il dispositivo Azure Stack Edge Pro GPU. | Esercitazione: Preparare la distribuzione di Azure Stack Edge Pro con GPU |
3. | Installare in rack e cablare il dispositivo Azure Stack Edge Pro GPU. Quando si esegue questa procedura, è necessario assicurarsi che il dispositivo abbia le porte connesse come segue: - Porta 5 - Rete di accesso (e facoltativamente, reti dati) - Porta 6 - Reti dati Inoltre, è necessario avere una porta connessa alla rete di gestione. È possibile scegliere una porta qualsiasi da 2 a 4. |
Esercitazione: Installare Azure Stack Edge Pro con GPU |
4. | Connettersi al dispositivo Azure Stack Edge Pro GPU usando l'interfaccia utente Web locale. | Esercitazione: Connettersi ad Azure Stack Edge Pro con GPU |
5. | Configurare la rete per il dispositivo Azure Stack Edge Pro GPU. Seguire le istruzioni per un Dispositivo a nodo singolo per una distribuzione standard o un Cluster a due nodi per una distribuzione a disponibilità elevata. Nota: quando un ASE viene usato in un servizio Private 5G Core di Azure, la porta 2 viene usata per la gestione anziché per i dati. L'esercitazione collegata presuppone un ASE generico che usa la porta 2 per i dati. Se l'operatore RAN e Packet Core si trovano nella stessa subnet, non è necessario configurare un gateway per la porta 5 o la porta 6. È anche possibile configurare facoltativamente il dispositivo Azure Stack Edge Pro GPU per l'esecuzione dietro un proxy Web. Verificare che le connessioni in uscita dal dispositivo Azure Stack Edge Pro GPU agli endpoint di Azure Arc siano aperte. Non configurare commutatori virtuali, reti virtuali o IP di calcolo. |
Esercitazione: Configurare la rete per Azure Stack Edge Pro con GPU (facoltativamente) Configurare il proxy Web per Azure Stack Edge Pro Requisiti di rete di Azure Arc Requisiti dell'agente di Azure Arc |
6. | Configurare un nome, un nome DNS e (facoltativamente) le impostazioni dell'ora. Non configurare un aggiornamento. |
Esercitazione: Configurare le impostazioni del dispositivo per Azure Stack Edge Pro con GPU |
7. | Configurare i certificati per il dispositivo Azure Stack Edge Pro GPU. Dopo aver modificato i certificati, potrebbe essere necessario riaprire l'interfaccia utente locale in una nuova finestra del browser per impedire che i vecchi certificati memorizzati nella cache causino problemi. | Esercitazione: Configurare i certificati per Azure Stack Edge Pro con GPU |
8. | Attivare il dispositivo Azure Stack Edge Pro GPU. Non seguire la sezione Distribuire carichi di lavoro. |
Esercitazione: Attivare Azure Stack Edge Pro con GPU |
9. | Abilitare la gestione della macchina virtuale dal portale di Azure. L'abilitazione di questa opzione subito dopo l'attivazione del dispositivo Azure Stack Edge Pro causa occasionalmente un errore. Attendere un minuto e riprovare. |
Passare alla risorsa ASE nel portale di Azure, passare a Servizi perimetrali, selezionare Macchine virtuali e selezionare Abilita. |
10. | Eseguire i test di diagnostica per il dispositivo Azure Stack Edge Pro GPU nell'interfaccia utente Web locale e verificare che vengano superati tutti. Potrebbe essere visualizzato un avviso relativo a una porta disconnessa e inutilizzata. È consigliabile risolvere il problema se l'avviso si riferisce a una di queste porte: - Porta 5. - Porta 6. - La porta scelta nel passaggio 3 per connettersi alla rete di gestione. Per tutte le altre porte, è possibile ignorare l'avviso. In caso di errori, risolverli prima di continuare con i passaggi rimanenti. Sono inclusi eventuali errori correlati a gateway non validi sulle porte inutilizzate. In questo caso, eliminare l'indirizzo IP del gateway o impostarlo su un gateway valido per la subnet. |
Eseguire la diagnostica, raccogliere i log per risolvere i problemi dei dispositivi Azure Stack Edge |
Importante
È necessario assicurarsi che il dispositivo Azure Stack Edge Pro GPU sia compatibile con la versione di Private 5G Core di Azure che si intende installare. Vedere Compatibilità di Packet Core e Azure Stack Edge (ASE). Se è necessario aggiornare il dispositivo Azure Stack Edge Pro GPU, vedere Aggiornare Azure Stack Edge Pro GPU.
Passaggi successivi
È ora possibile eseguire il commissioning del cluster del servizio Azure Kubernetes nel dispositivo Azure Stack Edge Pro 2 o Azure Stack Edge Pro GPU per prepararlo alla distribuzione di Private 5G Core di Azure.