Condividi tramite

Concetti di base per Azure Operator Service Manager

Questo articolo illustra le procedure consigliate per eseguire l'onboarding e la distribuzione di funzioni di rete (NFS) con Azure Operator Service Manager. Seguendo queste linee guida di base, fornitori, operatori e partner possono ottimizzare i servizi di rete distribuiti in Azure Operator Nexus. Prendere in considerazione questi concetti all'inizio di qualsiasi processo di pianificazione dell'onboarding delle funzioni di rete.

Considerazioni generali

È consigliabile eseguire prima l'onboarding e distribuire NF più semplici (uno o due grafici) usando gli avvii rapidi 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ù NF con un set di parametri che corrisponda alle esigenze della rete. Ad esempio, è possibile personalizzare 100 valori in un grafico con 1.000 valori. Assicurarsi che nel livello Schema del gruppo di configurazioni (CGS) (descritto più ampiamente nelle sezioni successive) si esponga 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. Gli esempi includono un cluster Kubernetes per le funzioni di rete containerizzate o una località personalizzata estesa di Azure Operator Nexus per le funzioni di rete virtualizzate. 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 consentono di combinarla con Azure DevOps o altri strumenti della pipeline.
  • L'estensione dell'interfaccia della riga di comando di Azure Operator Service Manager consente di pubblicare definizioni di funzioni di rete (NFD) e NSD. 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 server di pubblicazione

  • Si consiglia di creare un singolo editore per fornitore NF, o un editore per tipo NF per ogni fornitore NF, nel caso in cui il fornitore NF possa fornire più di un tipo di NF. Questa pratica;
    • Fornisce il supporto, la manutenzione e l'esperienza di governance più ottimali, impedendo la proliferazione degli editori. In particolare durante le attività di aggiornamento in cui la stessa azione viene spesso eseguita in molte NFS.
    • Riduce i costi operativi totali riducendo il numero di risorse di backup dell'editore, ad esempio Registro Azure Container o Account di archiviazione.
    • Semplifica la progettazione del servizio di rete (NSD), dove può consistere in molteplici NF di diversi fornitori.
  • Dopo aver testato e approvato il set desiderato di risorse dell'editore di Azure Operator Service Manager per l'uso in produzione, è consigliabile contrassegnare l'intero set come non modificabile. Contrassegnare il set come non modificabile consente di evitare modifiche accidentali e garantisce un'esperienza di distribuzione coerente. I contrassegni di immutabilità consentono di distinguere tra:
    • Risorse e artefatti usati nell'ambiente di produzione
    • Risorse e artefatti usati per il test e lo 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 Funzionalità di gestione dell'anteprima delle risorse di pubblicazione.

Tenere presente la logica seguente:

  • Se la versione di progettazione del servizio di rete (NSDV) è contrassegnata come non modificabile, anche il CGS deve essere contrassegnato come non modificabile. In caso contrario, la chiamata di distribuzione non riesce.
  • Se la versione della definizione della funzione di rete (NFDV) è contrassegnata 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 il CGS è contrassegnato come non modificabile, la chiamata di distribuzione ha esito positivo indipendentemente dal fatto che NFDV e NSDV siano contrassegnati come non modificabili.
  • Il contrassegno di un manifesto di artefatti come immutabile garantisce che tutti gli artefatti elencati in quel manifesto siano contrassegnati come immutabili applicando le autorizzazioni necessarie all'archivio di artefatti. Gli elementi elencati in genere includono grafici, immagini e modelli di Azure Resource Manager (modelli arm).
  • Prendere in considerazione l'uso di convenzioni di denominazione concordate e tecniche di governance per risolvere eventuali lacune rimanenti.

Disponibilità elevata e ripristino di emergenza di Publisher

Il publisher di Azure Operator Service Manager è un servizio regionale distribuito esclusivamente nelle zone di disponibilità locali delle regioni supportate. Considerare i seguenti requisiti di disponibilità elevata e ripristino di emergenza di Publisher:

  • Per garantire la ridondanza geografica, assicurarsi di disporre di un server di pubblicazione in ogni area in cui si prevede di distribuire NF. È consigliabile usare le pipeline per mantenere sincronizzati gli artefatti e le risorse dell'editore tra le aree.
  • Il nome dell'editore deve essere univoco per ogni tenant di Microsoft Entra in ogni area.

Considerazioni su NFDG e NFDV

Il gruppo di definizione della funzione di rete (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 elementi. 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ù NF vengono sempre distribuiti insieme, è ragionevole avere un unico NFDG per tutti. I singoli NFDG possono avere più NFDV.

  • Per i NFDV CNF, l'elenco networkFunctionApplications può contenere solo pacchetti Helm.
    • È ragionevole includere più pacchetti Helm se vengono sempre distribuiti ed eliminati insieme.
  • Per i VNF NFDV, l'elenco networkFunctionApplications deve contenere almeno un valore VhdImageFile e un modello di ARM.
    • Per distribuire più macchine virtuali (VM) per un singolo VNF, assicurarsi di usare un modello Azure Resource Manager (ARM) separato per ogni macchina virtuale.

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

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

Per i modelli ARM che contengono elementi diversi dall'elenco precedente, tutte le chiamate PUT sul VNF si traducono in un errore di convalida.

Aggiornamenti secondari o principali di NFDV

NFDV rappresenta una versione del NFDG di base ed è associata a una versione univoca. Man mano che le NF cambiano nel tempo, molti NFDV vengono usati per registrare funzionalità, in un determinato momento. Le modifiche tipiche che attivano un nuovo NFDV possono includere:

  • Aggiornamento di artefatti NF, ad esempio nuove versioni di grafici o immagini.
  • Aggiornamento di CGS o dei valori dei gruppi di configurazione (CGV) che cambiano deployParametersMappingRuleProfile.
  • Aggiornare i valori predefiniti codificati nel codice sorgente nel NFDV.
  • Aggiornamento dell'abilitazione del componente per impedire la distribuzione tramite applicationEnablement: Disabled.

Nota

Una versione NF che non espone nuovi parametri CGS richiede solo l'aggiornamento del manifesto dell'artefatto, il push di nuove immagini e grafici e l'urto della NFDV.

Considerazioni su NSDG e NSDV

Un gruppo di progettazione dei servizi di rete (NSDG) è un composito di uno o più gruppi NFDG e di tutti i componenti dell'infrastruttura distribuiti contemporaneamente. Questi componenti possono includere cluster e macchine virtuali in Nexus Kubernetes o nel servizio Azure Kubernetes. Un servizio di rete del sito (SNS) fa riferimento a un singolo NSDV. Tale progettazione fornisce una distribuzione coerente e ripetibile del servizio di rete in un sito da una singola chiamata SNS PUT .

Un esempio di NSDG può essere costituito da:

  • Funzione server di autenticazione (AUSF) NF
  • Gestione Unificata dei Dati (UDM) NF
  • Macchina virtuale amministrativa che supporta AUSF o UDM
  • Funzione di gestione delle sessioni nel cloud (SMF) di Unity
  • Cluster Nexus Kubernetes in cui vengono distribuiti AUSF, UDM e SMF

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

Aggiornamento secondario o principale di NSDV

L'NSDV rappresenta una versione del NSD di base ed è associato a una versione univoca. Le modifiche NSDV sono meno frequenti delle modifiche NFDV e, in alcuni casi, un singolo NSDV supporta l'intero ciclo di vita di un servizio di rete del sito. Tuttavia, le modifiche al servizio seguenti richiedono una nuova NSDV:

  • Creazione, eliminazione o aggiunta di valori in CGSs.
  • Modifica del modello NF ARM usato da una risorsa distribuita del servizio di rete del sito.
  • Modifica del modello ARM dell'infrastruttura usato da una risorsa del sito di deployment.

Nota

Esporre il valore NFDV come parametro all'interno del CGS, in modo che gli operatori possano controllare cosa distribuire usando i CGV, riducendo ulteriormente la frequenza di modifica NSDV.

Considerazioni su SNS

È consigliabile disporre di un singolo servizio SNS per l'intero sito, inclusa l'infrastruttura. SNS deve implementare qualsiasi infrastruttura necessaria (ad esempio, cluster e macchine virtuali in Nexus Kubernetes o AKS), e quindi implementare le NF necessarie. Tale progettazione fornisce una distribuzione coerente e ripetibile del servizio di rete in un sito da una singola chiamata 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 possedere il ruolo di Operatore identità gestita su di essa stessa. Per altre informazioni, vedere Creare e assegnare un'identità gestita assegnata dall'utente.

Considerazioni relative allo schema delle risorse

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 Nexus Kubernetes. Ecco la suddivisione delle risorse:

  • NFDG: se i componenti possono essere usati in modo indipendente, due gruppi NFDG con uno per componente. Se i componenti vengono sempre distribuiti insieme, un singolo NFDG.
  • NFDV: In base ai casi d'uso che richiedono aggiornamenti della versione secondaria o principale di NFDV.
  • NSDG: singolo. Combina le definizioni NF e dei cluster Kubernetes.
  • NSDV: in base alle esigenze dei casi d'uso che attivano gli aggiornamenti della versione secondaria o principale di NSDV.
  • CGS: singolo. Per semplificare la gestione, è consigliabile che il CGS includa sottosezioni per ogni componente e infrastruttura che si sta distribuendo. Si raccomanda anche che il CGS includa le versioni per NFD.
  • CGV: singolo in base al numero di CGS.
  • SNS: singolo per NSDV.

Scenario: più funzioni di rete

Più NF con alcuni componenti condivisi e indipendenti vengono distribuiti in un cluster Nexus Kubernetes. Ecco la suddivisione delle risorse:

  • NFDG:
    • Unico per tutti i componenti condivisi.
    • Singolo per ogni componente indipendente o NF.
  • NFDV: multiplo per ciascun NFDG per caso d'uso che attiva gli aggiornamenti delle versioni secondarie o principali dell'NFDV.
  • NSDG: singolo. Combina tutte le NF, i componenti condivisi e indipendenti e l'infrastruttura (cluster Kubernetes o qualsiasi macchina virtuale di supporto).
  • NSDV: in base alle esigenze dei casi d'uso che attivano gli aggiornamenti della versione secondaria o principale di NSDV.
  • CGS:
    • Singolo. Globale per tutti i componenti.
    • Singolo per NF, inclusa la versione dell'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

Supponendo che gli NF supportino gli aggiornamenti in loco e operativi, si applicano le seguenti considerazioni per i CNF.

  • Se si aggiungono nuovi grafici e immagini, Azure Operator Service Manager installa i nuovi grafici.
  • Se si rimuovono alcuni grafici e immagini, Azure Operator Service Manager elimina i grafici non 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.

Le considerazioni seguenti si applicano alle VNF:

  • 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 un 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:
    • Distribuire ogni macchina virtuale usando un modello di ARM dedicato.
    • Dal modello ARM, è necessario esporre due parametri tramite CGS:
      • Nome macchina virtuale, per consentire l'indicazione dell'istanza primaria o secondaria
      • Criteri di distribuzione, per controllare se la distribuzione delle macchine virtuali è consentita o meno
    • Nella NFDV è necessario parametrizzare deployParameters e templateParameters in modo da poter fornire i valori univoci usando ICGV per ognuno.

Considerazioni relative alla risoluzione dei problemi

Durante l'installazione e l'aggiornamento, per impostazione predefinita:

  • Le opzioni atomic e wait sono impostate su true.
  • Il timeout dell'operazione è impostato su 27 minutes.

Durante la configurazione iniziale, solo mentre si sta ancora eseguendo il debug e sviluppando i prodotti, consigliamo di impostare il flag atomic su false. Questa impostazione impedisce il rollback di Helm in caso di errore e mantiene tutti i log o gli errori che potrebbero altrimenti essere persi. Il modo ottimale per eseguire questa operazione è nel modello ARM del NF. Nel modello di ARM aggiungere la sezione seguente:

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

Il nome del componente è definito in NFDV:

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

Importante

Assicurarsi di reimpostare atomic e wait su true dopo il completamento dell'onboarding iniziale.

Considerazioni sulla pulizia

Quando si pulisce le risorse, l'ordine è importante. L'eliminazione di risorse non in ordine può comportare la rimozione di risorse orfane.

Risorse dell'operatore

Come primo passaggio per la pulizia di un ambiente distribuito, eliminare le risorse dell'operatore nell'ordine seguente:

  1. SNS
  2. Sito
  3. CGV

È possibile procedere all'eliminazione di altre risorse di ambiente, ad esempio il cluster Nexus Kubernetes, solo dopo aver eliminato correttamente queste risorse dell'operatore.

Risorse dell'editore

Come primo passaggio per pulire un ambiente di cui è stato eseguito l'onboarding, eliminare le risorse dell'editore nell'ordine seguente:

  1. NSDV
  2. NSDG
  3. NFDV
  4. NFDG
  5. Manifesto dell'artefatto
  6. Archivio artefatti
  7. Publisher

Importante

Assicurarsi di eliminare l'SNS prima di eliminare l'NFDV.

Azure Operator Service Manager non elimina i namespace in alcuna operazione di eliminazione. Di conseguenza, dopo l'eliminazione di tutte le risorse, alcuni artefatti potrebbero rimanere nel cluster. Per rimuovere tutti gli elementi rimanenti, è necessario eliminare tutti gli spazi dei nomi dei carichi di lavoro creati nel cluster. L'inclusione di questa operazione di eliminazione dello spazio dei nomi come parte della pipeline del flusso di lavoro è consigliata per automatizzare l'azione.

  • Last updated on