Share via

Az Azure Operator Service Manager ajánlott eljárásai a hálózati függvények előkészítéséhez és üzembe helyezéséhez

  • Cikk

A Microsoft számos bevált eljárást fejlesztett ki a hálózati függvények (NF-ek) Azure Operator Service Manager használatával történő kezelésére. Ez a cikk irányelveket tartalmaz, amelyeket az NF-szállítók, a telco-operátorok és partnereik követhetnek a kialakítás optimalizálásához. Tartsa szem előtt ezeket a gyakorlatokat az NF-k előkészítésekor és üzembe helyezésekor.

Általános szempontok

Javasoljuk, hogy először a legegyszerűbb NF-eket (egy vagy két diagramot) helyezze üzembe a gyorsútmutatók használatával, hogy megismerkedjen a teljes folyamattal. A további iterációkban hozzáadhatja a szükséges konfigurációs adatokat. A rövid útmutatók végighaladtával vegye figyelembe a következő szempontokat:

  • Az összetevők strukturálása a tervezett használathoz igazodva. Érdemes lehet elkülöníteni a globális összetevőket azoktól az összetevőktől, amelyeket hely vagy példány szerint szeretne megkülönböztetni.
  • Győződjön meg arról, hogy több NF szolgáltatásösszetétele a hálózat igényeinek megfelelő paraméterekkel rendelkezik. Előfordulhat például, hogy egy 1000 értéket tartalmazó diagramot csak 100-et szab testre. Győződjön meg arról, hogy a konfigurációs csoport sémája (CGS) rétegben (a következő szakaszokban részletesebben is lefedve) csak 100-et tesz elérhetővé.
  • Gondolja át, hogyan szeretné elkülöníteni az infrastruktúrát (például fürtöket) vagy az összetevők tárolóit, valamint a szállítók közötti hozzáférést, különösen egyetlen szolgáltatáson belül. Adja meg, hogy a közzétevői erőforrások készlete megfeleljen ennek a modellnek.
  • Az Azure Operator Service Manager-hely egy logikai fogalom, egy üzembehelyezési cél ábrázolása. Ilyen például egy Kubernetes-fürt a tárolóalapú hálózati függvényekhez (CNF-ekhez), vagy egy Azure Operator Nexus kiterjesztett egyéni hely a virtualizált hálózati függvényekhez (VNF-ekhez). Ez nem egy fizikai peremhálózati hely ábrázolása, ezért olyan eseteket használ, amelyekben több hely osztozik ugyanazon a fizikai helyen.
  • Az Azure Operator Service Manager különböző API-kat biztosít, így egyszerűen kombinálható az ADO-val vagy más folyamateszközökkel.

Közzétevői szempontok

  • Javasoljuk, hogy NF-szállítónként hozzon létre egyetlen közzétevőt. Ez a gyakorlat optimális támogatást, karbantartást és szabályozási élményt nyújt az összes beszállító számára, és leegyszerűsíti a hálózati szolgáltatás kialakítását, ha több szállító több NF-éből áll.

  • Miután tesztelte és jóváhagyta az Azure Operator Service Manager közzétevői erőforrásainak és összetevőinek kívánt készletét éles használatra, javasoljuk, hogy a teljes készletet nem módosíthatóként jelölje meg a véletlen módosítások elkerülése és a konzisztens üzembe helyezés biztosítása érdekében. Fontolja meg a nem módosítható képességeket az éles környezetben használt erőforrások és összetevők és a tesztelési és fejlesztési célokra használt erőforrások és összetevők megkülönböztetése érdekében. Lekérdezheti a közzétevő erőforrásainak állapotát és az összetevő-jegyzékeket annak megállapításához, hogy mely erőforrások vannak módosíthatatlanként megjelölve. További információ: Publisher-bérlők, előfizetések, régiók és előzetes verzió kezelése.

    Tartsa szem előtt a következő logikát:

    • Ha a Hálózati szolgáltatástervező függvény (NSDV) nem módosíthatóként van megjelölve, a CGS-t is módosíthatatlanként kell megjelölni. Ellenkező esetben az üzembe helyezési hívás meghiúsul.
    • Ha a hálózati függvények tervezési verziója (NFDV) nem módosíthatóként van megjelölve, az összetevő-jegyzékfájlt is módosíthatatlanként kell megjelölni. Ellenkező esetben az üzembe helyezési hívás meghiúsul.
    • Ha csak az összetevőjegyzék vagy a CGS van módosíthatatlanként megjelölve, az üzembe helyezési hívás sikeres lesz, függetlenül attól, hogy az NFDV és az NSDV nem módosíthatóként van-e megjelölve.
    • Ha módosíthatatlanként jelöl meg egy összetevő-jegyzékfájlt, azzal biztosítja, hogy a jegyzékben felsorolt összes összetevő (általában diagramok, képek és Azure Resource Manager-sablonok [ARM-sablonok]) is módosíthatók legyenek a szükséges engedélyek kikényszerítésével az összetevő-tárolóban.

  • Fontolja meg a megállapodás szerinti elnevezési konvenciók és szabályozási technikák használatát a fennmaradó hiányosságok megoldásához.

Hálózati függvénydefiníciós csoport és verzió szempontjai

A hálózati függvénydefiníciós csoport (NFDG) azt a legkisebb összetevőt jelöli, amelyet önállóan szeretne felhasználni több szolgáltatásban. Az NFDG minden része mindig együtt lesz üzembe helyezve. Ezeket a részeket nevezik networkFunctionApplications. Természetes például egy több Helm-diagramból és lemezképből álló NF előkészítése egyetlen NFDG-ként, ha ezeket az összetevőket mindig együtt helyezi üzembe. Azokban az esetekben, amikor több NFs mindig együtt van üzembe helyezve, ésszerű, hogy mindegyikhez egyetlen NFDG legyen. Egyetlen NFDG-nek több NFDV-je is lehet.

A tárolóalapú hálózati függvénydefiníciós verziók (CNF NFDV-k) esetében a networkFunctionApplications lista csak helm-csomagokat tartalmazhat. Érdemes több helm-csomagot is tartalmazni, ha mindig együtt vannak üzembe helyezve és törölve.

Virtualizált hálózati függvénydefiníciós verziók (VNF NFDV-k) esetén a networkFunctionApplications listának tartalmaznia kell legalább egy VhdImageFile és egy ARM-sablont. Az ARM-sablonnak egyetlen virtuális gépet kell üzembe helyeznie. Ha több virtuális gépet szeretne üzembe helyezni egyetlen VNF-hez, mindenképpen használjon külön ARM-sablonokat minden egyes virtuális géphez.

Az ARM-sablon csak a következő erőforrás-szolgáltatóktól telepíthet Resource Manager-erőforrásokat:

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

Megjegyzés:

Az előző listán kívül mást tartalmazó ARM-sablonok esetében a PUT-hívások és a VNF-re való ismételt üzembe helyezése érvényesítési hibát eredményez.

Gyakori használati esetek, amelyek a hálózati függvények alverziójának vagy főverziójának frissítését váltják ki

  • A CGS/konfigurációs csoport értékeinek (CGV-k) frissítése egy meglévő kiadáshoz, amely aktiválja a módosítást deployParametersMappingRuleProfile.
  • Az NFDV-ben keményen kódolt értékek frissítése.
  • Az inaktív összetevők megjelölése, hogy megakadályozzák az üzembe helyezésüket.applicationEnablement: Disabled
  • Új NF-kiadás, például diagramok és képek.

Megjegyzés:

A szükséges módosítások minimális száma minden alkalommal, amikor egy adott NF hasznos adatai megváltoznak. Egy kisebb vagy nagyobb NF-kiadáshoz az új CGS-paraméterek közzététele nélkül csak az összetevő-jegyzék frissítése, az új képek és diagramok leküldése és az NFDV-verzió ütközése szükséges.

A hálózati szolgáltatás tervezési csoportjának és verziójának szempontjai

A hálózati szolgáltatástervezési csoport (NSDG) egy vagy több NFDG-ből és minden infrastruktúra-összetevőből (például Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] fürtökből és virtuális gépekből) álló összetett, egyszerre üzembe helyezett. A helyhálózati szolgáltatás (SNS) egyetlen NSDV-ra hivatkozik. Az ilyen kialakítás garantálja a hálózati szolgáltatás konzisztens és megismételhető üzembe helyezését egy adott helyre egyetlen SNS PUT-ből.

Példa egy NSDG-ra:

  • Hitelesítési kiszolgálói függvény (AUSF) NF
  • Egyesített adatkezelés (UDM) NF
  • Rendszergazda AUSF/UDM-et támogató virtuális gép
  • Unity Cloud (UC) munkamenet-kezelési függvény (SMF) NF
  • NAKS-fürt, amelyre az AUSF, az UDM és az SMF telepítve van

Ez az öt összetevő egyetlen NSDG-t alkot. Egyetlen NSDG több NSDV-vel is rendelkezhet.

Általános használati esetek, amelyek elindítják a Hálózati szolgáltatás tervezési verziójának alverziója vagy főverzió frissítését

  • CGS-k létrehozása vagy törlése.
  • Az üzembe helyezett NF-ekhez társított NF ARM-sablon módosításai.
  • Az infrastruktúra ARM-sablonjának változásai, például AKS/NAKS vagy virtuális gép.

Megjegyzés:

Az NFDV változásai nem indíthatnak NSDV-frissítést. Az NFDV-értéket paraméterként kell elérhetővé tenni a CGS-ben, így az operátorok a CGV-k használatával szabályozhatják a telepítést.

Konfigurációs csoport sémájának szempontjai

Javasoljuk, hogy mindig egyetlen CGS-vel kezdje a teljes NF-hez. Ha vannak helyspecifikus vagy példányspecifikus paraméterek, akkor is javasoljuk, hogy tartsa őket egyetlen CGS-ben. Ha több összetevő (ritkán NFs, gyakrabban infrastruktúra) vagy konfigurációk vannak megosztva több NF-ben, javasoljuk több CGS-re való felosztást. A CGS-k száma határozza meg a CGV-k számát.

Eset

  • A FluentD, a Kibana és a Splunk (közös külső összetevők) mindig üzembe vannak helyezve az NSD-n belüli összes NF-ben. Javasoljuk, hogy ezeket az összetevőket egyetlen NFDG-be csoportosítsa.
  • Az NSD több NF-et tartalmaz, amelyek mindegyike rendelkezik néhány konfigurációval (üzembe helyezési hely, közzétevő neve és néhány diagramkonfiguráció).

Ebben a forgatókönyvben azt javasoljuk, hogy egyetlen globális CGS használatával tegye közzé a közös NF- és külső összetevők konfigurációit. Igény szerint meghatározhatja az NF-specifikus CGS-t.

A közzéteendő paraméterek kiválasztása

  • A CGS-nek csak olyan paraméterekkel kell rendelkeznie, amelyeket az NF-ek (0/N-konfiguráció) vagy megosztott összetevők használnak.
  • A ritkán konfigurált paramétereknek meg kell határozniuk az alapértelmezett értékeket.
  • Ha több CGS-t használ, javasoljuk, hogy ne legyen átfedés a paraméterek között. Ha átfedésre van szükség, győződjön meg arról, hogy a paraméternevek egyértelműen megkülönböztethetők a CGS-k között.
  • Az API-n (Azure Operator Nexus, Azure Operator Service Manager) keresztül definiálható értékeket figyelembe kell venni a CGS-hez. Ellentétben például a konfigurációs értékekkel a CloudInit-fájlokon keresztül.
  • Ha nem biztos benne, a jó kiindulási pont a paraméter felfedése, és a CGS-ben meg van adva egy ésszerű alapértelmezett érték. Az alábbi példa a CGS mintáját és a megfelelő CGV hasznos adatokat mutatja be.
  • Egyetlen felhasználó által hozzárendelt felügyelt identitást kell használni az összes NF ARM-sablonban, és a CGS-en keresztül kell elérhetővé tenni.

CGS hasznos adatok:

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

Az operátor által átadott megfelelő CGV hasznos adat:

{
"qwe": 20
}

Az Azure Operator Service Manager által létrehozott CGV-hasznos adatok:

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

Konfigurációs csoport értékeinek szempontjai

A CGV-erőforrás létrehozása előtt ellenőrizheti, hogy a mögöttes YAML- vagy JSON-fájl sémája és értékei megegyeznek-e a megfelelő CGS által várt értékkel. Ennek egyik lehetősége a Visual Studio Code YAML-bővítményének használata.

CLI-szempontok

Az Azure Operator Service Manager CLI-bővítménye segít az NFD-k és NSD-k közzétételében. Ezzel az eszközzel hozhat létre új NFD-ket és NSD-ket. Fontolja meg a parancssori felület használatát a kezdeti fájlok létrehozásához. Ezután a közzététel előtt szerkessze őket infrastruktúra-összetevők beépítéséhez.

Helyhálózati szolgáltatással kapcsolatos szempontok

Javasoljuk, hogy egyetlen SNS-t használjon a teljes webhelyhez, beleértve az infrastruktúrát is. Az SNS-nek minden szükséges infrastruktúrát üzembe kell helyeznie (például NAKS/AKS-fürtöket és virtuális gépeket), majd üzembe kell helyeznie a szükséges NF-eket. Az ilyen kialakítás garantálja a hálózati szolgáltatás konzisztens és megismételhető üzembe helyezését egy adott helyre egyetlen SNS PUT-ből.

Javasoljuk, hogy minden SNS egy felhasználó által hozzárendelt felügyelt identitással legyen üzembe helyezve, nem pedig rendszer által hozzárendelt felügyelt identitással. Ennek a felhasználó által hozzárendelt felügyelt identitásnak rendelkeznie kell az NFDV elérésére vonatkozó engedélyekkel, és magában kell rendelkeznie a felügyelt identitáskezelő szerepkörével. További információ: Felhasználó által hozzárendelt felügyelt identitás létrehozása és hozzárendelése.

Azure Operator Service Manager-erőforrás-leképezés használati esetenként

Az alábbi két forgatókönyv az Azure Operator Service Manager erőforrás-leképezését mutatja be.

Forgatókönyv: Önálló hálózati függvény

Egy egy vagy két alkalmazásösszetevővel rendelkező NF van üzembe helyezve egy NAKS-fürtben.

Erőforrások lebontása:

  • NFDG: Ha az összetevők egymástól függetlenül használhatók, akkor két NFDG,egy összetevőnként. Ha az összetevők mindig együtt vannak üzembe helyezve, akkor egyetlen NFDG lesz.
  • NFDV: Szükség szerint az előző "Gyakori használati esetek" szakaszban említett használati esetek alapján, amelyek NFDV-alverzió- vagy főverziófrissítéseket aktiválnak.
  • NSDG: Egyszemélyes. Egyesíti az NF-eket és a Kubernetes-fürtdefiníciókat.
  • NSDV: Szükség esetén az NSDV-al- vagy főverziófrissítéseket aktiváló előző "Gyakori használati esetek" szakaszban említett használati esetek alapján.
  • CGS: Önálló. Javasoljuk, hogy a CGS minden üzembe helyezett összetevőhöz és infrastruktúrához tartalmaz alszakaszokat a könnyebb felügyelet érdekében, és tartalmazza az NFD-k verzióit is.
  • CGV: A CGS-k száma alapján önálló.
  • SNS: NSDV-nként önálló.

Forgatókönyv: Több hálózati függvény

Több NF van üzembe helyezve néhány megosztott és független összetevővel egy NAKS-fürtben.

Erőforrások lebontása:

  • NFDG:
    • NFDG az összes megosztott összetevőhöz.
    • NFDG minden független összetevőhöz vagy NF-hez.
  • NFDV: Az NFDV-al- vagy főverziófrissítéseket aktiváló előző "Gyakori használati esetek" szakaszban említett használati esetenként több NFDG-nként.
  • NSDG: Egyszemélyes. Egyesíti az összes NF-t, megosztott és független összetevőt és infrastruktúrát (Kubernetes-fürt vagy bármely támogató virtuális gép).
  • NSDV: Szükség esetén az NSDV-al- vagy főverziófrissítéseket aktiváló előző "Gyakori használati esetek" szakaszban említett használati esetek alapján.
  • CGS:
    • Egyetlen. Globális minden olyan összetevőhöz, amely megosztott konfigurációs értékekkel rendelkezik.
    • NF CGS/NF, beleértve az NFD verzióját is.
    • A paraméterek teljes számától függően érdemes lehet az összes CGS-t egyetlen CGS-be egyesíteni.
  • CGV: Egyenlő a CGS-k számával.
  • SNS: NSDV-nként önálló.

Szoftverfrissítési szempontok

Feltételezve, hogy az NF-k támogatják a helyszíni/a szolgáltatáson belüli frissítéseket a CNF-ekhez:

  • Ha új diagramokat és rendszerképeket ad hozzá, az Azure Operator Service Manager telepíti az új diagramokat.
  • Ha egyes diagramok és képek el lettek távolítva, az Azure Operator Service Manager törli a már nem deklarált diagramokat az NFDV-ben.
  • Az Azure Operator Service Manager ellenőrzi, hogy az NFDV/NSDV ugyanabból az NFDG/NSDG-ből származik-e, és így ugyanaz a közzétevő. A közzétevők közötti frissítések nem támogatottak.

VNF-ekhez:

  • A helyszíni frissítések jelenleg nem támogatottak. Egymás mellett kell létrehoznia egy új VNF-et egy frissített képpel. Ezután törölje a régebbi VNF-et az SNS törlésével.
  • Ha a VNF virtuális gépek párjaként van üzembe helyezve a magas rendelkezésre állás érdekében, úgy tervezheti meg a hálózati szolgáltatást, hogy egyenként törölheti és frissítheti a virtuális gépeket. Az egyes virtuális gépek törlésének és frissítésének engedélyezéséhez a következő kialakítást javasoljuk:
    • Minden virtuális gép üzembe helyezése dedikált ARM-sablonnal történik.
    • Az ARM-sablonból két paramétert kell elérhetővé tenni a CGS-en keresztül: a virtuális gép nevét, hogy meg lehessen adni, hogy melyik példány elsődleges/másodlagos, és az üzembe helyezési szabályzat határozza meg, hogy engedélyezett-e a virtuális gép üzembe helyezése.
    • Az NFDV-ben, és templateParameters úgy kell parametrizálnia, deployParameters hogy az egyedi értékeket CGV-k használatával adja meg mindegyikhez.

Magas rendelkezésre állás és vészhelyreállítási szempontok

Az Azure Operator Service Manager egy regionális szolgáltatás, amelyet a rendelkezésre állási zónákban helyeznek üzembe az őket támogató régiókban. Az összes régióban, ahol az Azure Operator Service Manager elérhető, tekintse meg az Azure-termékeket régiónként. A rendelkezésre állási zónákkal rendelkező Azure-régiók listáját a megfelelő Azure-régió kiválasztása című témakörben találja.

Vegye figyelembe a következő magas rendelkezésre állási és vészhelyreállítási követelményeket:

  • A georedundancia biztosításához győződjön meg arról, hogy minden régióban rendelkezik közzétevővel, ahol NF-eket szeretne üzembe helyezni. Fontolja meg a folyamatok használatát annak érdekében, hogy a közzétevői összetevők és erőforrások szinkronban legyenek a régiók között.
  • A közzétevő nevének régiónként egyedinek kell lennie a Microsoft Entra-bérlőnként.

Megjegyzés:

Ha egy régió elérhetetlenné válik, üzembe helyezhet (de nem frissíthet) egy NF-et egy másik régió közzétevői erőforrásainak használatával. Feltételezve, hogy az összetevők és az erőforrások azonosak a közzétevők között, csak az SNS-erőforrás hasznos adataiban kell módosítania az networkServiceDesignVersionOfferingLocation értéket.

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

Hibaelhárítási megfontolások

A telepítés és a frissítés során alapértelmezés szerint az atomi és a várakozási beállítások be vannak állítva true, és a művelet időtúllépése a következőre 27 minutesvan állítva. Az előkészítés során javasoljuk, hogy állítsa be az atomi jelzőt, hogy false megakadályozza a Helm sikertelen visszaállítását. Ennek optimális módja az NF ARM-sablonjában van.

Az ARM-sablonban adja hozzá a következő szakaszt:

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

Az összetevő neve az NFDV-ben van definiálva:

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

Tisztítási szempontok

Törölje az operátor erőforrásait a következő sorrendben, hogy biztosan ne maradjon árva erőforrás:

  • SNS
  • Site
  • CGV

Fontos

Az NFDV törlése előtt győződjön meg arról, hogy az SNS törlődik.

Törölje a közzétevő erőforrásait a következő sorrendben, hogy biztosan ne maradjon árva erőforrás:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • Lelet manifesztum
  • Műtárgy áruház
  • Publisher

További lépések