Metodtips för Azure Operator Service Manager för att registrera och distribuera nätverksfunktioner

  • Artikel

Microsoft har utvecklat många beprövade metoder för att hantera nätverksfunktioner (NFs) med hjälp av Azure Operator Service Manager. Den här artikeln innehåller riktlinjer som NF-leverantörer, telekomoperatörer och deras partner kan följa för att optimera designen. Tänk på dessa metoder när du registrerar och distribuerar dina NF:er.

Allmänna överväganden

Vi rekommenderar att du först registrerar och distribuerar dina enklaste NF:er (ett eller två diagram) med hjälp av snabbstarterna för att bekanta dig med det övergripande flödet. Du kan lägga till nödvändig konfigurationsinformation i efterföljande iterationer. Tänk på följande när du går igenom snabbstarterna:

  • Strukturera artefakterna så att de överensstämmer med planerad användning. Överväg att separera globala artefakter från de artefakter som du vill variera beroende på plats eller instans.
  • Kontrollera tjänstsammansättningen för flera NF:er med en uppsättning parametrar som matchar nätverkets behov. Du kan till exempel ha ett diagram som har 1 000 värden och du bara anpassar 100 av dem. Kontrollera i CGS-lagret (Configuration Group Schema) (mer ingående i avsnitten nedan) att du bara exponerar 100.
  • Tänk tidigt på hur du vill separera infrastruktur (till exempel kluster) eller artefaktlager och åtkomst mellan leverantörer, särskilt inom en enda tjänst. Gör så att din uppsättning utgivarresurser matchar den här modellen.
  • Azure Operator Service Manager-platsen är ett logiskt begrepp, en representation av ett distributionsmål. Exempel är ett Kubernetes-kluster för Containerized Network Functions (CNFs) eller en Azure Operator Nexus utökad anpassad plats för virtualiserade nätverksfunktioner (VNFs). Det är inte en representation av en fysisk gränswebbplats, så du har användningsfall där flera webbplatser delar samma fysiska plats.
  • Azure Operator Service Manager innehåller olika API:er som gör det enkelt att kombinera med ADO eller andra pipelineverktyg.

Överväganden för utgivare

  • Vi rekommenderar att du skapar en enskild utgivare per NF-leverantör. Den här metoden ger optimal support, underhåll och styrning för alla leverantörer och förenklar din nätverkstjänstdesign när den består av flera NF:er från flera leverantörer.

  • När den önskade uppsättningen Azure Operator Service Manager-utgivarresurser och artefakter har testats och godkänts för produktionsanvändning rekommenderar vi att du markerar hela uppsättningen som oföränderlig för att förhindra oavsiktliga ändringar och säkerställa en konsekvent distributionsupplevelse. Överväg att förlita dig på oföränderlighetsfunktioner för att skilja mellan resurser och artefakter som används i produktion jämfört med de som används för testning och utveckling. Du kan köra frågor mot utgivarresursernas tillstånd och artefaktmanifesten för att avgöra vilka som är markerade som oföränderliga. Mer information finns i Publisher-klientorganisationer, prenumerationer, regioner och förhandsgranskningshantering.

    Tänk på följande logik:

    • Om NSDV (Network Service Design Function) har markerats som oföränderlig måste CGS också markeras som oföränderlig. Annars misslyckas distributionsanropet.
    • Om NFDV (Network Function Design Version) har markerats som oföränderlig måste artefaktmanifestet också markeras som oföränderligt. Annars misslyckas distributionsanropet.
    • Om endast artefaktmanifestet eller CGS har markerats som oföränderliga lyckas distributionsanropet oavsett om NFDV och NSDV har markerats som oföränderliga.
    • Om du markerar ett artefaktmanifest som oföränderligt ser du till att alla artefakter som anges i manifestet (vanligtvis diagram, bilder och Azure Resource Manager-mallar [ARM-mallar]) också markeras som oföränderliga genom att framtvinga nödvändiga behörigheter för artefaktarkivet.

  • Överväg att använda överenskomna namngivningskonventioner och styrningstekniker för att åtgärda eventuella återstående luckor.

Överväganden för nätverksfunktionsdefinitionsgrupp och version

NFDG (Network Function Definition Group) representerar den minsta komponent som du planerar att återanvända oberoende av flera tjänster. Alla delar av en NFDG distribueras alltid tillsammans. Dessa delar kallas networkFunctionApplications. Det är till exempel naturligt att registrera en enda NF som består av flera Helm-diagram och avbildningar som en enda NFDG om du alltid distribuerar dessa komponenter tillsammans. I de fall då flera NF:er alltid distribueras tillsammans är det rimligt att ha en enda NFDG för dem alla. Enskilda NFDG:er kan ha flera NFDV:er.

För definitionsversioner av containerbaserade nätverksfunktioner (CNF NFDV:er) networkFunctionApplications kan listan bara innehålla helm-paket. Det är rimligt att inkludera flera helm-paket om de alltid distribueras och tas bort tillsammans.

För Virtualized Network Function Definition Versions (VNF NFDVs) networkFunctionApplications måste listan innehålla minst en VhdImageFile och en ARM-mall. ARM-mallen ska distribuera en enskild virtuell dator (VM). Om du vill distribuera flera virtuella datorer för en enda virtuell dator måste du använda separata ARM-mallar för varje virtuell dator.

ARM-mallen kan bara distribuera Resource Manager-resurser från följande resursprovidrar:

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

Kommentar

För ARM-mallar som innehåller allt utanför föregående lista resulterar alla PUT-anrop och Re-PUT på VNF i ett valideringsfel.

Vanliga användningsfall som utlöser delversion av nätverksfunktionsdesign eller större versionsuppdatering

  • Uppdaterar CGS/Configuration Group Values (CGV:er) för en befintlig version som utlöser ändring av deployParametersMappingRuleProfile.
  • Uppdaterar värden som är hårdkodade i NFDV.
  • Markera komponenter som är inaktiva för att förhindra att de distribueras via applicationEnablement: Disabled.
  • Ny NF-version, till exempel diagram och bilder.

Kommentar

Minsta antal ändringar som krävs varje gång nyttolasten för en viss NF ändras. En mindre eller större NF-version utan att exponera nya CGS-parametrar kräver endast uppdatering av artefaktmanifestet, push-överföring av nya bilder och diagram och stöter på NFDV-versionen.

Överväganden för nätverkstjänstdesigngrupp och version

NSDG (Network Service Design Group) är en sammansättning av en eller flera NFDG:er och eventuella infrastrukturkomponenter (till exempel Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS]-kluster och virtuella datorer) som distribueras samtidigt. En platsnätverkstjänst (SNS) refererar till en enda NSDV. Sådan design garanterar konsekvent och repeterbar distribution av nätverkstjänsten till en viss plats från en enda SNS PUT.

Ett exempel på en NSDG är:

  • Autentiseringsserverfunktion (AUSF) NF
  • Enhetlig Datahantering (UDM) NF
  • Virtuell administratörsdator med stöd för AUSF/UDM
  • Unity Cloud (UC) Sessionshanteringsfunktion (SMF) NF
  • NAKS-kluster som AUSF, UDM och SMF distribueras till

Dessa fem komponenter utgör en enda NSDG. En enda NSDG kan ha flera NSDV:er.

Vanliga användningsfall som utlöser delversion av nätverkstjänstdesign eller större versionsuppdatering

  • Skapa eller ta bort CGS.
  • Ändringar i NF ARM-mallen som är associerad med en av de NF:er som distribueras.
  • Ändringar i infrastrukturens ARM-mall, till exempel AKS/NAKS eller VM.

Kommentar

Ändringar i NFDV bör inte utlösa en NSDV-uppdatering. NFDV-värdet ska exponeras som en parameter i CGS, så att operatorerna kan styra vad som ska distribueras med hjälp av CGV:er.

Överväganden för konfigurationsgruppschema

Vi rekommenderar att du alltid börjar med en enda CGS för hela NF. Om det finns platsspecifika eller instansspecifika parametrar rekommenderar vi fortfarande att du behåller dem i en enda CGS. Vi rekommenderar att du delar upp i flera CGS när det finns flera komponenter (sällan NF:er, oftare infrastruktur) eller konfigurationer som delas mellan flera NF:er. Antalet CGS definierar antalet CGV:er.

Scenario

  • FluentD, Kibana och Splunk (vanliga komponenter från tredje part) distribueras alltid för alla NF:er i en NSD. Vi rekommenderar att du grupperar dessa komponenter i en enda NFDG.
  • NSD har flera NF:er som alla delar några konfigurationer (distributionsplats, utgivarens namn och några diagramkonfigurationer).

I det här scenariot rekommenderar vi att du använder en enda global CGS för att exponera vanliga NF- och tredjepartskomponentkonfigurationer. Du kan definiera NF-specifika CGS efter behov.

Välj parametrar som ska exponeras

  • CGS bör endast ha parametrar som används av NF:er (dag 0/N-konfiguration) eller delade komponenter.
  • Parametrar som sällan konfigureras bör ha standardvärden definierade.
  • Om flera CGS används rekommenderar vi liten eller ingen överlappning mellan parametrarna. Om överlappning krävs kontrollerar du att parameternamnen är tydligt åtskiljbara mellan CGS:erna.
  • Vad som kan definieras via API (Azure Operator Nexus, Azure Operator Service Manager) bör övervägas för CGS. I stället för att till exempel definiera dessa konfigurationsvärden via CloudInit-filer.
  • När du är osäker är en bra utgångspunkt att exponera parametern och ha en rimlig standard som anges i CGS. I följande exempel visas exemplet CGS och motsvarande CGV-nyttolaster.
  • En enda användartilldelad hanterad identitet ska användas i alla NF ARM-mallar och ska exponeras via CGS.

CGS-nyttolast:

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

Motsvarande CGV-nyttolast som skickas av operatorn:

{
"qwe": 20
}

Resulterande CGV-nyttolast som genereras av Azure Operator Service Manager:

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

Överväganden för konfigurationsgruppvärden

Innan du skickar cgv-resursen kan du verifiera att schemat och värdena för den underliggande YAML- eller JSON-filen matchar vad motsvarande CGS förväntar sig. För att åstadkomma detta är ett alternativ att använda YAML-tillägget för Visual Studio Code.

CLI-överväganden

Azure Operator Service Manager CLI-tillägget hjälper till med publicering av NFD:er och NSD:er. Använd det här verktyget som utgångspunkt för att skapa nya NFD:er och NSD:er. Överväg att använda CLI för att skapa de första filerna. Redigera dem sedan för att införliva infrastrukturkomponenter innan du publicerar.

Överväganden för platsnätverkstjänst

Vi rekommenderar att du har en enda SNS för hela platsen, inklusive infrastrukturen. SNS ska distribuera all infrastruktur som krävs (till exempel NAKS/AKS-kluster och virtuella datorer) och sedan distribuera de NF:er som krävs ovanpå. Sådan design garanterar konsekvent och repeterbar distribution av nätverkstjänsten till en viss plats från en enda SNS PUT.

Vi rekommenderar att varje SNS distribueras med en användartilldelad hanterad identitet i stället för en systemtilldelad hanterad identitet. Den här användartilldelade hanterade identiteten måste ha behörighet att komma åt NFDV och måste ha rollen hanterad identitetsoperator på sig själv. Mer information finns i Skapa och tilldela en användartilldelad hanterad identitet.

Azure Operator Service Manager-resursmappning per användningsfall

Följande två scenarier illustrerar resursmappning i Azure Operator Service Manager.

Scenario: Enskild nätverksfunktion

En NF med en eller två programkomponenter distribueras till ett NAKS-kluster.

Resursuppdelning:

  • NFDG: Om komponenter kan användas oberoende av varandra, två NFDG:er, en per komponent. Om komponenter alltid distribueras tillsammans kan du använda en enda NFDG.
  • NFDV: Vid behov baserat på de användningsfall som nämns i de föregående avsnitten "Vanliga användningsfall" som utlöser NFDV-delversioner eller större versionsuppdateringar.
  • NSDG: Enkel. Kombinerar NF:er och Kubernetes-klusterdefinitionerna.
  • NSDV: Vid behov baserat på de användningsfall som nämns i de föregående avsnitten "Vanliga användningsfall" som utlöser NSDV-delversioner eller större versionsuppdateringar.
  • CGS: Enkel. Vi rekommenderar att CGS har underavsnitt för varje komponent och infrastruktur som distribueras för enklare hantering och innehåller versionerna för NFD:er.
  • CGV: Enkel baserat på antalet CGS.
  • SNS: Enkel per NSDV.

Scenario: Flera nätverksfunktioner

Flera NF:er med vissa delade och oberoende komponenter distribueras till ett NAKS-kluster.

Resursuppdelning:

  • NFDG:
    • NFDG för alla delade komponenter.
    • NFDG för varje oberoende komponent eller NF.
  • NFDV: Flera per varje NFDG per användningsfall som nämns i de föregående avsnitten "Vanliga användningsfall" som utlöser NFDV-mindre eller större versionsuppdateringar.
  • NSDG: Enkel. Kombinerar alla NF:er, delade och oberoende komponenter och infrastruktur (Kubernetes-kluster eller eventuella virtuella datorer som stöds).
  • NSDV: Vid behov baserat på de användningsfall som nämns i de föregående avsnitten "Vanliga användningsfall" som utlöser NSDV-delversioner eller större versionsuppdateringar.
  • CGS:
    • Ensamstående. Global för alla komponenter som har delade konfigurationsvärden.
    • NF CGS per NF, inklusive versionen av NFD.
    • Beroende på det totala antalet parametrar kan du överväga att kombinera alla CGS till en enda CGS.
  • CGV: Lika med antalet CGS.
  • SNS: Enkel per NSDV.

Överväganden för programvaruuppgradering

Förutsatt att NF:er stöder uppgraderingar på plats/i tjänsten för CNF:er:

  • Om nya diagram och avbildningar läggs till installerar Azure Operator Service Manager de nya diagrammen.
  • Om vissa diagram och bilder tas bort tar Azure Operator Service Manager bort de diagram som inte längre deklareras i NFDV.
  • Azure Operator Service Manager verifierar att NFDV/NSDV kommer från samma NFDG/NSDG och därmed samma utgivare. Uppgraderingar mellan utgivare stöds inte.

För virtuella hårddiskar:

  • Uppgraderingar på plats stöds för närvarande inte. Du måste instansiera en ny VNF med en uppdaterad avbildning sida vid sida. Ta sedan bort den äldre virtuella hårddisken genom att ta bort SNS.
  • Om VNF distribueras som ett par virtuella datorer för hög tillgänglighet kan du utforma nätverkstjänsten på ett sådant sätt att du kan ta bort och uppgradera virtuella datorer en i taget. Vi rekommenderar följande design för att tillåta borttagning och uppgradering av enskilda virtuella datorer:
    • Varje virtuell dator distribueras med hjälp av en dedikerad ARM-mall.
    • Från ARM-mallen måste två parametrar exponeras via CGS: VM-namn, för att kunna ange vilken instans som är primär/sekundär och distributionsprincip, som styr om VM-distribution tillåts eller inte.
    • I NFDV deployParameters och måste parametriseras på ett sådant sätt att du kan ange de unika värdena med hjälp av CGV:er för var och templateParameters en.

Överväganden för hög tillgänglighet och haveriberedskap

Azure Operator Service Manager är en regional tjänst som distribueras mellan tillgänglighetszoner i regioner som stöder dem. Information om alla regioner där Azure Operator Service Manager är tillgängligt finns i Azure-produkter efter region. Listan över Azure-regioner som har tillgänglighetszoner finns i Välj rätt Azure-region åt dig.

Överväg följande krav på hög tillgänglighet och haveriberedskap:

  • För att tillhandahålla geo-redundans kontrollerar du att du har en utgivare i varje region där du planerar att distribuera NF:er. Överväg att använda pipelines för att se till att utgivararartefakter och resurser hålls synkroniserade mellan regionerna.
  • Utgivarens namn måste vara unikt per region per Microsoft Entra-klientorganisation.

Kommentar

Om en region blir otillgänglig kan du distribuera (men inte uppgradera) en NF med hjälp av utgivarresurser i en annan region. Förutsatt att artefakter och resurser är identiska mellan utgivare behöver du bara ändra networkServiceDesignVersionOfferingLocation värdet i SNS-resursnyttolasten.

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

Överväganden vid felsökning

Under installationen och uppgraderingen som standard är atomiska alternativ och väntealternativ inställda på true, och tidsgränsen för åtgärden är inställd på 27 minutes. Under registreringen rekommenderar vi att du ställer in atomflaggan för att false förhindra Helm-återställningen vid fel. Det optimala sättet att åstadkomma detta är i ARM-mallen för NF.

Lägg till följande avsnitt i ARM-mallen:

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

Komponentnamnet definieras i NFDV:

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

Rensningsöverväganden

Ta bort operatorresurser i följande ordning för att se till att inga överblivna resurser finns kvar:

  • SNS
  • Site
  • CGV

Viktigt!

Kontrollera att SNS har tagits bort innan du tar bort NFDV.

Ta bort utgivarresurser i följande ordning för att se till att inga överblivna resurser lämnas kvar:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • Artefaktmanifest
  • Artefaktarkiv
  • Publisher

Nästa steg