Condividi tramite

Procedure consigliate di Azure Operator Service Manager per eseguire l'onboarding e la distribuzione di funzioni di rete

  • Articolo

Microsoft ha sviluppato molte procedure comprovate per la gestione delle funzioni di rete usando Azure Operator Service Manager. Questo articolo fornisce linee guida che i fornitori NF, gli operatori telco e i loro partner possono seguire per ottimizzare la progettazione. Tenere presenti queste procedure quando si esegue l'onboarding e si distribuiscono le NFS.

Considerazioni generali

È consigliabile eseguire prima l'onboarding e distribuire le NFS più semplici (uno o due grafici) usando le guide introduttive per acquisire familiarità con il flusso complessivo. È possibile aggiungere i dettagli di configurazione necessari nelle iterazioni successive. Quando si esaminano le guide introduttive, considerare i punti seguenti:

  • Strutturare gli artefatti per allinearsi all'uso pianificato. Valutare la possibilità di separare gli artefatti globali dagli elementi che si desidera variare in base al sito o all'istanza.
  • Assicurarsi che la composizione del servizio di più NFS con un set di parametri che corrisponda alle esigenze della rete. Ad esempio, si potrebbe avere un grafico con 1.000 valori e personalizzare solo 100 di essi. Assicurarsi che nel livello CGS (Configuration Group Schema) (descritto più ampiamente nelle sezioni successive) sia possibile esporre solo 100.
  • Si pensi in anticipo a come separare l'infrastruttura (ad esempio, i cluster) o gli archivi artefatti e l'accesso tra i fornitori, in particolare all'interno di un singolo servizio. Impostare il set di risorse dell'editore in modo che corrisponda a questo modello.
  • Il sito di Azure Operator Service Manager è un concetto logico, una rappresentazione di una destinazione di distribuzione. Alcuni esempi sono un cluster Kubernetes per le funzioni di rete in contenitori o un percorso personalizzato esteso di Nexus operatore di Azure per le funzioni di rete virtualizzate.Examples are a Kubernetes cluster for Containerized Network Functions (CNFS) or an Azure Operator Nexus extended location for Virtualized Network Functions (VNFs). Non è una rappresentazione di un sito perimetrale fisico, quindi si hanno casi d'uso in cui più siti condividono la stessa posizione fisica.
  • Azure Operator Service Manager offre varie API che semplificano la combinazione con ADO o altri strumenti di pipeline.

Considerazioni sul server di pubblicazione

  • È consigliabile creare un singolo editore per ogni fornitore NF. Questa procedura offre un supporto ottimale, manutenzione e un'esperienza di governance in tutti i fornitori e semplifica la progettazione del servizio di rete quando sono composte da più NFS da più fornitori.

  • Dopo che il set desiderato di risorse e artefatti dell'editore di Azure Operator Service Manager viene testato e approvato per l'uso in produzione, è consigliabile contrassegnare l'intero set come non modificabile per evitare modifiche accidentali e garantire un'esperienza di distribuzione coerente. Prendere in considerazione la possibilità di basarsi sulle funzionalità di immutabilità per distinguere le risorse e gli artefatti usati nell'ambiente di produzione rispetto a quelli usati per scopi di test e sviluppo. È possibile eseguire una query sullo stato delle risorse del server di pubblicazione e dei manifesti dell'artefatto per determinare quali sono contrassegnati come non modificabili. Per altre informazioni, vedere Tenant del server di pubblicazione, sottoscrizioni, aree e gestione dell'anteprima.

    Tenere presente la logica seguente:

    • Se la funzione di progettazione del servizio di rete (NSDV) è contrassegnata come non modificabile, CGS deve essere contrassegnato anche come non modificabile. In caso contrario, la chiamata di distribuzione non riesce.
    • Se network function design version (NFDV) è contrassegnato come non modificabile, anche il manifesto dell'artefatto deve essere contrassegnato come non modificabile. In caso contrario, la chiamata di distribuzione non riesce.
    • Se solo il manifesto dell'artefatto o CGS è contrassegnato come non modificabile, la chiamata di distribuzione ha esito positivo indipendentemente dal fatto che NFDV e NSDV siano contrassegnati come non modificabili.
    • Contrassegnare un manifesto di artefatto come non modificabile garantisce che tutti gli artefatti elencati in tale manifesto (in genere, grafici, immagini e modelli di Azure Resource Manager [modelli arm]) siano contrassegnati come non modificabili applicando anche le autorizzazioni necessarie per l'archivio artefatti.

  • Prendere in considerazione l'uso di convenzioni di denominazione concordate e tecniche di governance per risolvere eventuali lacune rimanenti.

Considerazioni sulla versione e sul gruppo di definizioni di funzioni di rete

Network Function Definition Group (NFDG) rappresenta il componente più piccolo che si prevede di riutilizzare in modo indipendente tra più servizi. Tutte le parti di un NFDG vengono sempre distribuite insieme. Queste parti sono denominate networkFunctionApplications. Ad esempio, è naturale eseguire l'onboarding di un singolo NF composto da più grafici Helm e immagini come singolo NFDG se si distribuiscono sempre questi componenti insieme. Nei casi in cui più NFS vengono sempre distribuite insieme, è ragionevole avere un singolo NFDG per tutti. I singoli NFDG possono avere più NFDV.

Per le versioni delle definizioni di funzione di rete in contenitori (CNFV), l'elenco networkFunctionApplications può contenere solo pacchetti Helm. È ragionevole includere più pacchetti Helm se vengono sempre distribuiti ed eliminati insieme.

Per le versioni delle definizioni delle funzioni di rete virtualizzate (VNFV), l'elenco networkFunctionApplications deve contenere almeno uno VhdImageFile e un modello di Resource Manager. Il modello di Resource Manager deve distribuire una singola macchina virtuale (VM). Per distribuire più macchine virtuali per un singolo VNF, assicurarsi di usare modelli di Resource Manager separati per ogni macchina virtuale.

Il modello di Resource Manager può distribuire solo le risorse di Resource Manager dai provider di risorse seguenti:

  • Microsoft.Compute
  • Microsoft.Network
  • Microsoft.NetworkCloud
  • Microsoft.Storage
  • Microsoft.NetworkFabric
  • Microsoft.Authorization
  • Microsoft.ManagedIdentity

Nota

Per i modelli arm contenenti qualsiasi elemento oltre l'elenco precedente, tutte le chiamate PUT e Re-PUT sul VNF generano un errore di convalida.

Casi d'uso comuni che attivano l'aggiornamento della versione secondaria o principale della versione della funzione di rete

  • Aggiornamento dei valori del gruppo di configurazione/CGS per una versione esistente che attiva la modifica di deployParametersMappingRuleProfile.
  • Aggiornamento di valori hardcoded in NFDV.
  • Contrassegno dei componenti inattivi per impedire la distribuzione tramite applicationEnablement: Disabled.
  • Nuova versione NF, ad esempio grafici e immagini.

Nota

Numero minimo di modifiche necessarie ogni volta che il payload di un determinato NF cambia. Una versione NF secondaria o principale senza esporre nuovi parametri CGS richiede solo l'aggiornamento del manifesto dell'artefatto, il push di nuove immagini e grafici e l'urto della versione NFDV.

Considerazioni sul gruppo di progettazione e sulla versione dei servizi di rete

Network Service Design Group (NSDG) è un composito di uno o più gruppi NFDG e di tutti i componenti dell'infrastruttura (ad esempio Nexus servizio Azure Kubernetes [NAKS]/servizio Azure Kubernetes [servizio Azure Kubernetes] distribuiti contemporaneamente. Un servizio di rete del sito (SNS) fa riferimento a un singolo NSDV. Tale progettazione garantisce una distribuzione coerente e ripetibile del servizio di rete in un determinato sito da un singolo SNS PUT.

Un esempio di NSDG è:

  • Funzione server di autenticazione (AUSF) NF
  • UDM (Unified Gestione dati) NF
  • Amministrazione macchina virtuale che supporta AUSF/UDM
  • Funzione di gestione delle sessioni (SMF) di Unity Cloud (UC) NF
  • Cluster NAKS, in cui vengono distribuiti AUSF, UDM e SMF

Questi cinque componenti formano un singolo NSDG. Un singolo NSDG può avere più NSDV.

Casi d'uso comuni che attivano l'aggiornamento della versione secondaria o principale della versione del servizio di rete

  • Creazione o eliminazione di CGS.
  • Modifiche apportate al modello arm NF associato a una delle funzioni di rete distribuite.
  • Modifiche apportate al modello arm dell'infrastruttura, ad esempio servizio Azure Kubernetes/NAKS o macchina virtuale.

Nota

Le modifiche apportate a NFDV non devono attivare un aggiornamento NSDV. Il valore NFDV deve essere esposto come parametro all'interno del CGS, in modo che gli operatori possano controllare cosa distribuire usando ICGV.

Considerazioni sullo schema del gruppo di configurazione

È consigliabile iniziare sempre con un singolo CGS per l'intero NF. Se sono presenti parametri specifici del sito o specifici dell'istanza, è comunque consigliabile mantenerli in un singolo CGS. È consigliabile suddividere in più CGS quando sono presenti più componenti (raramente NFS, più comunemente, infrastruttura) o configurazioni condivise tra più NFS. Il numero di CGS definisce il numero di CGV.

Scenario

  • FluentD, Kibana e Splunk (componenti di terze parti comuni) vengono sempre distribuiti per tutte le NFS all'interno di un NSD. È consigliabile raggruppare questi componenti in un singolo NFDG.
  • NSD include più NFS che condividono tutte alcune configurazioni (percorso di distribuzione, nome editore e alcune configurazioni del grafico).

In questo scenario, è consigliabile usare un singolo CGS globale per esporre le configurazioni comuni dei componenti di terze parti e NF. È possibile definire CGS specifici di NF in base alle esigenze.

Scegliere i parametri da esporre

  • CGS deve avere solo parametri usati da NFS (configurazione giorno 0/N) o componenti condivisi.
  • I parametri configurati raramente devono avere valori predefiniti definiti.
  • Se vengono usati più CGS, è consigliabile non sovrapporsi tra i parametri. Se è necessaria la sovrapposizione, assicurarsi che i nomi dei parametri siano chiaramente distinguibili tra i CGS.
  • Ciò che può essere definito tramite API (Azure Operator Nexus, Azure Operator Service Manager) deve essere considerato per CGS. Anziché, ad esempio, definire tali valori di configurazione tramite file CloudInit.
  • In caso di dubbi, un buon punto di partenza consiste nell'esporre il parametro e avere un valore predefinito ragionevole specificato in CGS. L'esempio seguente illustra il CGS di esempio e i payload CGV corrispondenti.
  • Una singola identità gestita assegnata dall'utente deve essere usata in tutti i modelli arm NF e deve essere esposta tramite CGS.

Payload CGS:

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

Payload CGV corrispondente passato dall'operatore:

{
"qwe": 20
}

Payload CGV risultante generato da Azure Operator Service Manager:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

Considerazioni relative ai valori dei gruppi di configurazione

Prima di inviare la creazione della risorsa CGV, è possibile verificare che lo schema e i valori del file YAML o JSON sottostante corrispondano a quanto previsto dal CGS corrispondente. A tale scopo, un'opzione consiste nell'usare l'estensione YAML per Visual Studio Code.

Considerazioni sull'interfaccia della riga di comando

L'estensione dell'interfaccia della riga di comando di Azure Operator Service Manager è utile per la pubblicazione di NSD e NFD. Usare questo strumento come punto di partenza per la creazione di nuovi NSD e NFD. Prendere in considerazione l'uso dell'interfaccia della riga di comando per creare i file iniziali. Quindi modificarli per incorporare i componenti dell'infrastruttura prima della pubblicazione.

Considerazioni sul servizio di rete del sito

È consigliabile disporre di un singolo servizio sns per l'intero sito, inclusa l'infrastruttura. Sns deve distribuire qualsiasi infrastruttura necessaria (ad esempio, cluster NAKS/servizio Azure Kubernetes e macchine virtuali) e quindi distribuire le NFS necessarie. Tale progettazione garantisce una distribuzione coerente e ripetibile del servizio di rete in un determinato sito da un singolo SNS PUT.

È consigliabile distribuire ogni servizio SNS con un'identità gestita assegnata dall'utente anziché un'identità gestita assegnata dal sistema. Questa identità gestita assegnata dall'utente deve avere le autorizzazioni per accedere alla NFDV e deve avere il ruolo di Operatore identità gestita su se stesso. Per altre informazioni, vedere Creare e assegnare un'identità gestita assegnata dall'utente.

Mapping delle risorse di Azure Operator Service Manager per caso d'uso

I due scenari seguenti illustrano il mapping delle risorse di Azure Operator Service Manager.

Scenario: singola funzione di rete

Un NF con uno o due componenti dell'applicazione viene distribuito in un cluster NAKS.

Suddivisione delle risorse:

  • NFDG: se i componenti possono essere usati in modo indipendente, due gruppi NFDG, uno per componente. Se i componenti vengono sempre distribuiti insieme, un singolo NFDG.
  • NFDV: in base ai casi d'uso indicati nelle sezioni precedenti "Casi d'uso comuni" che attivano gli aggiornamenti della versione secondaria o principale di NFDV.
  • NSDG: single. Combina le definizioni dei cluster Kubernetes e NFS.
  • NSDV: in base ai casi d'uso indicati nelle sezioni "Casi d'uso comuni" precedenti che attivano gli aggiornamenti della versione secondaria o principale di NSDV.
  • CGS: singolo. È consigliabile che CGS includa sottosezioni per ogni componente e infrastruttura da distribuire per una gestione più semplice e include le versioni per i dischi NFD.
  • CGV: singolo in base al numero di CGS.
  • SNS: singolo per NSDV.

Scenario: più funzioni di rete

Più NFS con alcuni componenti condivisi e indipendenti vengono distribuiti in un cluster NAKS.

Suddivisione delle risorse:

  • NFDG:
    • NFDG per tutti i componenti condivisi.
    • NFDG per ogni componente indipendente o NF.
  • NFDV: più per ogni NFDG per caso d'uso menzionato nelle sezioni precedenti "Casi d'uso comuni" che attivano aggiornamenti della versione secondaria o principale di NFDV.
  • NSDG: single. Combina tutte le funzioni di rete, i componenti condivisi e indipendenti e l'infrastruttura (cluster Kubernetes o qualsiasi macchina virtuale di supporto).
  • NSDV: in base ai casi d'uso indicati nelle sezioni "Casi d'uso comuni" precedenti che attivano gli aggiornamenti della versione secondaria o principale di NSDV.
  • CGS:
    • Single. Globale per tutti i componenti con valori di configurazione condivisi.
    • NF CGS per NF, inclusa la versione del NFD.
    • A seconda del numero totale di parametri, valutare la possibilità di combinare tutti i CGS in un singolo CGS.
  • CGV: uguale al numero di CGS.
  • SNS: singolo per NSDV.

Considerazioni sull'aggiornamento software

Supponendo che le NFS supportino gli aggiornamenti sul posto/nel servizio, per le funzioni cnfs:

  • Se vengono aggiunti nuovi grafici e immagini, Azure Operator Service Manager installa i nuovi grafici.
  • Se alcuni grafici e immagini vengono rimossi, Azure Operator Service Manager elimina i grafici che non sono più dichiarati nella vista NFDV.
  • Azure Operator Service Manager convalida che il valore NFDV/NSDV proviene dallo stesso NFDG/NSDG e quindi dallo stesso server di pubblicazione. Gli aggiornamenti tra server di pubblicazione non sono supportati.

Per le VNFS:

  • Gli aggiornamenti sul posto non sono attualmente supportati. È necessario creare un'istanza di un nuovo VNF con un'immagine aggiornata affiancata. Eliminare quindi il VNF precedente eliminando SNS.
  • Se VNF viene distribuito come coppia di macchine virtuali per la disponibilità elevata, è possibile progettare il servizio di rete in modo da poter eliminare e aggiornare le macchine virtuali una alla volta. È consigliabile usare la progettazione seguente per consentire l'eliminazione e l'aggiornamento di singole macchine virtuali:
    • Ogni macchina virtuale viene distribuita usando un modello di Resource Manager dedicato.
    • Dal modello di Resource Manager, è necessario esporre due parametri tramite CGS: nome macchina virtuale, per consentire l'indicazione dell'istanza primaria/secondaria e dei criteri di distribuzione, controllando se la distribuzione di macchine virtuali è consentita o meno.
    • Nella NFDV deployParameters e templateParameters devono essere parametrizzati in modo da poter fornire i valori univoci usando ICGV per ognuno.

Considerazioni relative alla disponibilità elevata e al ripristino di emergenza

Azure Operator Service Manager è un servizio a livello di area distribuito tra le zone di disponibilità nelle aree che le supportano. Per tutte le aree in cui è disponibile Azure Operator Service Manager, vedere Prodotti Azure per area. Per l'elenco delle aree di Azure con zone di disponibilità, vedere Scegliere l'area di Azure appropriata.

Considerare i requisiti di disponibilità elevata e ripristino di emergenza seguenti:

  • Per garantire la ridondanza geografica, assicurarsi di disporre di un server di pubblicazione in ogni area in cui si prevede di distribuire NFS. Prendere in considerazione l'uso delle pipeline per assicurarsi che gli artefatti e le risorse dell'editore vengano mantenuti sincronizzati tra le aree.
  • Il nome dell'editore deve essere univoco per area per ogni tenant di Microsoft Entra.

Nota

Se un'area non è più disponibile, è possibile distribuire (ma non aggiornare) un NF usando le risorse del server di pubblicazione in un'altra area. Supponendo che gli artefatti e le risorse siano identici tra i server di pubblicazione, è sufficiente modificare il networkServiceDesignVersionOfferingLocation valore nel payload della risorsa SNS.

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

Considerazioni relative alla risoluzione dei problemi

Durante l'installazione e l'aggiornamento per impostazione predefinita, le opzioni atomiche e di attesa sono impostate su truee il timeout dell'operazione è impostato su 27 minutes. Durante l'onboarding, è consigliabile impostare il flag atomico su false per evitare il rollback helm in caso di errore. Il modo ottimale per eseguire questa operazione si trova nel modello arm di NF.

Nel modello di Resource Manager aggiungere la sezione seguente:

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

Il nome del componente è definito in NFDV:

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

Considerazioni sulla pulizia

Eliminare le risorse dell'operatore nell'ordine seguente per assicurarsi che non siano state lasciate risorse orfane:

  • SNS
  • Site
  • CGV

Importante

Assicurarsi che SNS venga eliminato prima di eliminare il valore NFDV.

Eliminare le risorse del server di pubblicazione nell'ordine seguente per assicurarsi che non siano state lasciate risorse orfane:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • Manifesto artefatto
  • Archivio di artefatti
  • Publisher

Passaggi successivi