Share via

Best practices voor Azure Operator Service Manager voor onboarding en implementatie van netwerkfuncties

  • Artikel

Microsoft heeft veel bewezen procedures ontwikkeld voor het beheren van netwerkfuncties (NF's) met behulp van Azure Operator Service Manager. Dit artikel bevat richtlijnen die NF-leveranciers, telco-operators en hun partners kunnen volgen om het ontwerp te optimaliseren. Houd rekening met deze procedures wanneer u uw NF's onboardt en implementeert.

Algemene overwegingen

U wordt aangeraden eerst uw eenvoudigste NFs (een of twee grafieken) te onboarden en te implementeren met behulp van de quickstarts om vertrouwd te raken met de algehele stroom. U kunt de benodigde configuratiegegevens toevoegen in volgende iteraties. Houd rekening met de volgende punten tijdens het doorlopen van de quickstarts:

  • Structureer uw artefacten om te worden afgestemd op gepland gebruik. Overweeg om globale artefacten te scheiden van de artefacten die u wilt variëren per site of instantie.
  • Zorg voor servicesamenstelling van meerdere NF's met een set parameters die voldoen aan de behoeften van uw netwerk. U hebt bijvoorbeeld een grafiek met 1000 waarden en u kunt er slechts 100 aanpassen. Zorg ervoor dat in de CGS-laag (Configuration Group Schema) (uitgebreider behandeld in secties die volgen) dat u slechts 100 beschikbaar maakt.
  • Denk vroeg na over hoe u infrastructuur (bijvoorbeeld clusters) of artefactarchieven en -toegang tussen leveranciers wilt scheiden, met name binnen één service. Zorg ervoor dat uw set uitgeversbronnen overeenkomt met dit model.
  • Azure Operator Service Manager-site is een logisch concept, een weergave van een implementatiebestemming. Voorbeelden zijn een Kubernetes-cluster voor containernetwerkfuncties (CNF's) of een uitgebreide aangepaste locatie van Azure Operator Nexus voor gevirtualiseerde netwerkfuncties (VNF's). Het is geen weergave van een fysieke randsite, dus u hebt gebruiksvoorbeelden waarbij meerdere sites dezelfde fysieke locatie delen.
  • Azure Operator Service Manager biedt verschillende API's, waardoor het eenvoudig is om te combineren met ADO of andere pijplijnhulpprogramma's.

Overwegingen voor uitgevers

  • U wordt aangeraden één uitgever per NF-leverancier te maken. Deze procedure biedt optimale ondersteuning, onderhoud en governance-ervaring voor alle leveranciers en vereenvoudigt het ontwerp van uw netwerkservice wanneer deze bestaat uit meerdere NF's van meerdere leveranciers.

  • Nadat de gewenste set uitgeversresources en artefacten van Azure Operator Service Manager is getest en goedgekeurd voor productiegebruik, raden we u aan om de volledige set als onveranderbaar te markeren om onbedoelde wijzigingen te voorkomen en een consistente implementatie-ervaring te garanderen. Overweeg te vertrouwen op onveranderbaarheidsmogelijkheden om onderscheid te maken tussen resources en artefacten die worden gebruikt in productie versus de artefacten die worden gebruikt voor test- en ontwikkelingsdoeleinden. U kunt de status van de uitgeversresources en de artefactmanifesten opvragen om te bepalen welke zijn gemarkeerd als onveranderbaar. Zie Publisher-tenants, abonnementen, regio's en preview-beheer voor meer informatie.

    Houd rekening met de volgende logica:

    • Als de netwerkserviceontwerpfunctie (NSDV) is gemarkeerd als onveranderbaar, moet CGS ook worden gemarkeerd als onveranderbaar. Anders mislukt de implementatieoproep.
    • Als NFDV (Network Function Design Version) is gemarkeerd als onveranderbaar, moet het artefactmanifest ook als onveranderbaar worden gemarkeerd. Anders mislukt de implementatieoproep.
    • Als alleen artefactmanifest of CGS als onveranderbaar is gemarkeerd, slaagt de implementatieaanroep, ongeacht of NFDV en NSDV zijn gemarkeerd als onveranderbaar.
    • Als u een artefactmanifest markeert als onveranderbaar, zorgt u ervoor dat alle artefacten die in dat manifest worden vermeld (meestal grafieken, afbeeldingen en Azure Resource Manager-sjablonen [ARM-sjablonen]) ook zijn gemarkeerd als onveranderbaar door de benodigde machtigingen af te dwingen voor het artefactarchief.

  • Overweeg om overeengekomen naamconventies en governancetechnieken te gebruiken om eventuele resterende hiaten te verhelpen.

Overwegingen voor netwerkfunctiedefinitiegroep en -versie

Network Function Definition Group (NFDG) vertegenwoordigt het kleinste onderdeel dat u onafhankelijk van meerdere services opnieuw wilt gebruiken. Alle onderdelen van een NFDG worden altijd samen geïmplementeerd. Deze onderdelen worden genoemd networkFunctionApplications. Het is bijvoorbeeld natuurlijk om één NF te onboarden die bestaat uit meerdere Helm-grafieken en -installatiekopieën als één NFDG als u deze onderdelen altijd samen implementeert. In gevallen waarin meerdere NF's altijd samen worden geïmplementeerd, is het redelijk om één NFDG te hebben voor alle NF's. Eén NFDG's kunnen meerdere NFDV's hebben.

Voor Containerized Network Function Definition Versions (CNF NFDVs) kan de networkFunctionApplications lijst alleen helm-pakketten bevatten. Het is redelijk om meerdere Helm-pakketten op te nemen als ze altijd samen worden geïmplementeerd en verwijderd.

Voor VNETF NFDV's (Virtualized Network Function Definition Versions) moet de networkFunctionApplications lijst ten minste één VhdImageFile en één ARM-sjabloon bevatten. De ARM-sjabloon moet één virtuele machine (VM) implementeren. Als u meerdere VM's voor één VNF wilt implementeren, moet u afzonderlijke ARM-sjablonen voor elke VIRTUELE machine gebruiken.

De ARM-sjabloon kan alleen Resource Manager-resources implementeren van de volgende resourceproviders:

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

Notitie

Voor ARM-sjablonen die verder gaan dan de voorgaande lijst, resulteren alle PUT-aanroepen en Opnieuw plaatsen op het VNF-resultaat in een validatiefout.

Veelvoorkomende gebruiksvoorbeelden die een secundaire of primaire versie-update voor de ontwerpversie van de netwerkfunctie activeren

  • CGS-/configuratiegroepwaarden (CGV's) bijwerken voor een bestaande release die het wijzigen deployParametersMappingRuleProfileactiveert.
  • Waarden bijwerken die in code zijn vastgelegd in de NFDV.
  • Onderdelen inactief markeren om te voorkomen dat ze worden geïmplementeerd via applicationEnablement: Disabled.
  • Nieuwe NF-release, zoals grafieken en afbeeldingen.

Notitie

Minimaal aantal wijzigingen dat vereist is telkens wanneer de nettolading van een bepaalde NF wordt gewijzigd. Voor een secundaire of primaire NF-release zonder nieuwe CGS-parameters beschikbaar te stellen, hoeft u alleen het artefactmanifest bij te werken, nieuwe afbeeldingen en grafieken te pushen en de NFDV-versie te stoten.

Overwegingen voor groep en versie van netwerkserviceontwerp

Network Service Design Group (NSDG) is een samengestelde van een of meer NFDG's en infrastructuuronderdelen (zoals Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS]-clusters en virtuele machines) die tegelijkertijd zijn geïmplementeerd. Een sitenetwerkservice (SNS) verwijst naar één NSDV. Een dergelijk ontwerp garandeert een consistente en herhaalbare implementatie van de netwerkservice naar een bepaalde site vanaf één SNS PUT.

Een voorbeeld van een NSDG is:

  • Verificatieserverfunctie (AUSF) NF
  • Unified Gegevensbeheer (UDM) NF
  • Beheer VM die AUSF/UDM ondersteunt
  • Unity Cloud (UC) Session Management Function (SMF) NF
  • NAKS-cluster waarnaar AUSF, UDM en SMF worden geïmplementeerd

Deze vijf onderdelen vormen één NSDG. Eén NSDG kan meerdere NSDV's hebben.

Veelvoorkomende use cases die secundaire of primaire versie van Network Service Design Version activeren

  • CGS's maken of verwijderen.
  • Wijzigingen in de NF ARM-sjabloon die is gekoppeld aan een van de NFs die worden geïmplementeerd.
  • Wijzigingen in de ARM-infrastructuursjabloon, bijvoorbeeld AKS/NAKS of VM.

Notitie

Wijzigingen in NFDV mogen geen NSDV-update activeren. De NFDV-waarde moet worden weergegeven als een parameter in de CGS, zodat operators kunnen bepalen wat er moet worden geïmplementeerd met behulp van CGV's.

Overwegingen voor schema voor configuratiegroepen

U wordt aangeraden altijd te beginnen met één CGS voor het hele NF. Als er sitespecifieke of instantiespecifieke parameters zijn, wordt u nog steeds aangeraden deze in één CGS te bewaren. We raden u aan om te splitsen in meerdere CGS's wanneer er meerdere onderdelen (zelden NF's, vaker, infrastructuur) of configuraties zijn die worden gedeeld over meerdere NFS. Het aantal CGS's definieert het aantal CGV's.

Scenario

  • FluentD, Kibana en Splunk (algemene onderdelen van derden) worden altijd geïmplementeerd voor alle NF's binnen een NSD. U wordt aangeraden deze onderdelen te groeperen in één NFDG.
  • NSD heeft meerdere NF's die allemaal een paar configuraties delen (implementatielocatie, naam van uitgever en enkele grafiekconfiguraties).

In dit scenario raden we u aan om één globale CGS te gebruiken om de algemene NF- en onderdeelconfiguraties van derden beschikbaar te maken. U kunt indien nodig NF-specifieke CGS definiëren.

Parameters kiezen om beschikbaar te maken

  • CGS mag alleen parameters hebben die worden gebruikt door NFs (dag 0/N-configuratie) of gedeelde onderdelen.
  • Parameters die zelden zijn geconfigureerd, moeten standaardwaarden hebben gedefinieerd.
  • Als er meerdere CGS's worden gebruikt, raden we weinig tot geen overlap tussen de parameters aan. Als overlapping is vereist, moet u ervoor zorgen dat de parameternamen duidelijk onderscheid kunnen maken tussen de CGS's.
  • Wat kan worden gedefinieerd via API (Azure Operator Nexus, Azure Operator Service Manager) moet worden overwogen voor CGS. In tegenstelling tot bijvoorbeeld het definiëren van deze configuratiewaarden via CloudInit-bestanden.
  • Als u niet zeker weet, is het een goed uitgangspunt om de parameter beschikbaar te maken en een redelijke standaardwaarde te hebben die is opgegeven in de CGS. In het volgende voorbeeld ziet u de voorbeeld-CGS en bijbehorende CGV-nettoladingen.
  • Er moet één door de gebruiker toegewezen beheerde identiteit worden gebruikt in alle NF ARM-sjablonen en moet worden weergegeven via CGS.

CGS-nettolading:

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

Bijbehorende CGV-nettolading doorgegeven door de operator:

{
"qwe": 20
}

Resulterende CGV-nettolading gegenereerd door Azure Operator Service Manager:

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

Overwegingen voor waarden voor configuratiegroepen

Voordat u de CGV-resource maakt, kunt u controleren of het schema en de waarden van het onderliggende YAML- of JSON-bestand overeenkomen met wat de bijbehorende CGS verwacht. Hiervoor kunt u de YAML-extensie voor Visual Studio Code gebruiken.

Cli-overwegingen

De Azure Operator Service Manager CLI-extensie helpt bij het publiceren van NFD's en NSD's. Gebruik dit hulpprogramma als uitgangspunt voor het maken van nieuwe NFD's en NSD's. Overweeg om de CLI te gebruiken om de eerste bestanden te maken. Bewerk ze vervolgens om infrastructuuronderdelen op te nemen voordat u publiceert.

Overwegingen voor sitenetwerkservices

U wordt aangeraden voor de hele site één SNS te hebben, inclusief de infrastructuur. De SNS moet alle vereiste infrastructuur implementeren (bijvoorbeeld NAKS/AKS-clusters en virtuele machines) en vervolgens de vereiste NF's implementeren. Een dergelijk ontwerp garandeert een consistente en herhaalbare implementatie van de netwerkservice naar een bepaalde site vanaf één SNS PUT.

U wordt aangeraden om elke SNS te implementeren met een door de gebruiker toegewezen beheerde identiteit in plaats van een door het systeem toegewezen beheerde identiteit. Deze door de gebruiker toegewezen beheerde identiteit moet machtigingen hebben voor toegang tot de NFDV en moet de rol van Managed Identity Operator op zichzelf hebben. Zie Een door de gebruiker toegewezen beheerde identiteit maken en toewijzen voor meer informatie.

Azure Operator Service Manager-resourcetoewijzing per use-case

In de volgende twee scenario's ziet u de resourcetoewijzing van Azure Operator Service Manager.

Scenario: Enkele netwerkfunctie

Een NF met een of twee toepassingsonderdelen wordt geïmplementeerd in een NAKS-cluster.

Uitsplitsing van resources:

  • NFDG: Als onderdelen onafhankelijk kunnen worden gebruikt, twee NFDG's, één per onderdeel. Als onderdelen altijd samen worden geïmplementeerd, wordt één NFDG gebruikt.
  • NFDV: Indien nodig op basis van de use cases die worden vermeld in de voorgaande secties 'Veelvoorkomende use cases' die NFDV-secundaire of primaire versie-updates activeren.
  • NSDG: enkelvoudig. Combineert de NFs en de Kubernetes-clusterdefinities.
  • NSDV: Indien nodig op basis van de gebruiksvoorbeelden die worden vermeld in de voorgaande secties 'Veelvoorkomende use cases' die NSDV-secundaire of primaire versie-updates activeren.
  • CGS: enkel. Het is raadzaam dat CGS subsecties bevat voor elk onderdeel en elke infrastructuur die voor eenvoudiger beheer wordt geïmplementeerd en de versies voor NFD's bevat.
  • CGV: Enkel gebaseerd op het aantal CG's.
  • SNS: Één per NSDV.

Scenario: Meerdere netwerkfuncties

Meerdere NFs met een aantal gedeelde en onafhankelijke onderdelen worden geïmplementeerd in een NAKS-cluster.

Uitsplitsing van resources:

  • NFDG:
    • NFDG voor alle gedeelde onderdelen.
    • NFDG voor elk onafhankelijk onderdeel of NF.
  • NFDV: Meerdere per NFDG per use case vermeld in de voorgaande secties 'Algemene use cases' die NFDV-secundaire of primaire versie-updates activeren.
  • NSDG: enkelvoudig. Combineert alle NFs, gedeelde en onafhankelijke onderdelen en infrastructuur (Kubernetes-cluster of eventuele ondersteunende VM's).
  • NSDV: Indien nodig op basis van de gebruiksvoorbeelden die worden vermeld in de voorgaande secties 'Veelvoorkomende use cases' die NSDV-secundaire of primaire versie-updates activeren.
  • CGS:
    • Alleenstaand. Globaal voor alle onderdelen met gedeelde configuratiewaarden.
    • NF CGS per NF, inclusief de versie van de NFD.
    • Afhankelijk van het totale aantal parameters kunt u overwegen om alle CGS's te combineren tot één CGS.
  • CGV: gelijk aan het aantal CGS's.
  • SNS: Één per NSDV.

Overwegingen voor software-upgrades

Ervan uitgaande dat NF's ondersteuning bieden voor in-place/in-service-upgrades, voor CNFs:

  • Als er nieuwe grafieken en afbeeldingen worden toegevoegd, installeert Azure Operator Service Manager de nieuwe grafieken.
  • Als sommige grafieken en afbeeldingen worden verwijderd, verwijdert Azure Operator Service Manager de grafieken die niet meer zijn gedeclareerd in de NFDV.
  • Azure Operator Service Manager valideert dat de NFDV/NSDV afkomstig is van dezelfde NFDG/NSDG en dus dezelfde uitgever. Upgrades voor meerdere uitgevers worden niet ondersteund.

Voor VNF's:

  • In-place upgrades worden momenteel niet ondersteund. U moet een nieuwe VNF instantiëren met een bijgewerkte afbeelding naast elkaar. Verwijder vervolgens de oudere VNF door de SNS te verwijderen.
  • Als VNF is geïmplementeerd als een paar virtuele machines voor hoge beschikbaarheid, kunt u de netwerkservice zodanig ontwerpen dat u VM's één voor één kunt verwijderen en upgraden. We raden het volgende ontwerp aan om het verwijderen en upgraden van afzonderlijke VM's mogelijk te maken:
    • Elke VIRTUELE machine wordt geïmplementeerd met behulp van een toegewezen ARM-sjabloon.
    • Vanuit de ARM-sjabloon moeten twee parameters worden weergegeven via CGS: VM-naam, om aan te geven welk exemplaar primair/secundair is en implementatiebeleid, waarmee wordt bepaald of de VM-implementatie is toegestaan of niet.
    • In de NFDV deployParameters , en templateParameters moet op een zodanige manier worden geparametriseerd dat u de unieke waarden kunt opgeven met behulp van CSV's voor elk.

Overwegingen voor hoge beschikbaarheid en herstel na noodgevallen

Azure Operator Service Manager is een regionale service die wordt geïmplementeerd in beschikbaarheidszones in regio's die deze ondersteunen. Zie Azure-producten per regio voor alle regio's waar Azure Operator Service Manager beschikbaar is. Zie De juiste Azure-regio voor u kiezen voor de lijst met Azure-regio's met beschikbaarheidszones.

Houd rekening met de volgende vereisten voor hoge beschikbaarheid en herstel na noodgevallen:

  • Als u georedundantie wilt bieden, moet u ervoor zorgen dat u een uitgever hebt in elke regio waar u van plan bent NFS te implementeren. Overweeg het gebruik van pijplijnen om ervoor te zorgen dat uitgeversartefacten en -resources gesynchroniseerd blijven tussen de regio's.
  • De naam van de uitgever moet uniek zijn per regio per Microsoft Entra-tenant.

Notitie

Als een regio niet beschikbaar is, kunt u een NF implementeren (maar niet upgraden) met behulp van uitgeversbronnen in een andere regio. Ervan uitgaande dat artefacten en resources identiek zijn tussen de uitgevers, hoeft u alleen de networkServiceDesignVersionOfferingLocation waarde in de nettolading van de SNS-resource te wijzigen.

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

Overwegingen voor probleemoplossing

Tijdens de installatie en upgrade zijn standaard atomische en wachtopties ingesteld op true, en de time-out van de bewerking is ingesteld 27 minutesop . Tijdens de onboarding raden we u aan de atomische vlag in te stellen om false te voorkomen dat helm wordt teruggedraaid bij fouten. De optimale manier om dat te bereiken is in de ARM-sjabloon van het NF.

Voeg in de ARM-sjabloon de volgende sectie toe:

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

De onderdeelnaam wordt gedefinieerd in de NFDV:

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

Overwegingen voor opschonen

Verwijder operatorbronnen in de volgende volgorde om ervoor te zorgen dat er geen zwevende resources achterblijven:

  • SNS
  • Site
  • CGV

Belangrijk

Zorg ervoor dat SNS wordt verwijderd voordat u de NFDV verwijdert.

Verwijder publisher-resources in de volgende volgorde om ervoor te zorgen dat er geen zwevende resources achterblijven:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • Artefactmanifest
  • Artefactarchief
  • Publisher

Volgende stappen