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
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 megfontolások
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ózatiszolgáltatás-tervezési verzió (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
Feljegyzé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.
Feljegyzé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
- Az AUSF/UDM-et támogató rendszergazdai 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.
Feljegyzé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:
- Nőtlen. 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.
Feljegyzé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 minutes
van állítva. A kezdeti előkészítés során csak akkor javasoljuk, hogy az atomi jelzőt a hibakeresés és az összetevők fejlesztése közben állítsa be a következőre false.
: Ez megakadályozza a helm visszaállítását a hiba esetén, és megőrzi az egyéb módon elvesző naplókat vagy hibákat. 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 }
Fontos
Győződjön meg arról, hogy az atomi és várakozási idő vissza van állítva a true
kezdeti előkészítés befejezése után.
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
- Hely
- 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
- Összetevőjegyzék
- Összetevő-tároló
- Publisher
Megfontolandó szempontok, ha az NF cert-managert futtat
Fontos
Ez az útmutató csak bizonyos kiadásokra vonatkozik. Ellenőrizze a megfelelő viselkedést a verzióban.
Az 1.0.2728-50-es kiadástól a 2.0.2777-132-es verzióig az AOSM tanúsítványokat tárol és forgat. A módosítás részeként az AOSM üzembe helyez egy tanúsítványkezelő operátort, és crD-ket társít az azurehybridnetwork névtérben. Mivel több, akár külön névtérben üzembe helyezett cert-manager operátor is működik az összes névtérben, csak egy tanúsítványkezelő futtatható hatékonyan a fürtön.
A tanúsítványkezelőt a fürtre a számítási feladatok üzembe helyezésének részeként telepíteni próbáló felhasználók üzembe helyezési hibát kapnak, amely azt a hibát eredményezi, hogy a CRD "létezik, és nem importálható az aktuális kiadásba". A hiba elkerülése érdekében javasoljuk, hogy hagyja ki a cert-manager telepítését, ehelyett függjön a cert-manager operátortól és az AOSM által már telepített CRD-ről.
Egyéb megfontolandó konfigurációmódosítások
A régi felhasználói tanúsítványkezelőhöz társított NfApp letiltása mellett más módosításokra is szükség lehet;
- Ha az egyik NfApp a tanúsítványkezelőt és a hitelesítésszolgáltató telepítését is tartalmazza, azokat két NfApps-fájlra kell bontani, hogy a partner letilthassa a tanúsítványkezelőt, de engedélyezze a hitelesítésszolgáltató telepítését.
- Ha bármely más NfApps rendelkezik DependsOn-hivatkozásokkal a régi felhasználói tanúsítványkezelő NfApp-ra, ezeket el kell távolítani.
- Ha bármely más NfApps hivatkozik a régi felhasználói tanúsítványkezelő névtérértékére, ezt az új azurehybridnetwork névtérértékre kell módosítani.
A Cert-Manager verziókompatibilitása és kezelése
A cert-manager operátor esetében a jelenlegi üzembe helyezett verzió az 1.14.5. A felhasználóknak tesztelni kell a verzióval való kompatibilitást. A jövőbeni cert-manager-operátorfrissítések az NFO bővítményfrissítési folyamatán keresztül támogatottak lesznek.
A CRD-erőforrások esetében a jelenlegi üzembe helyezett verzió az 1.14.5. A felhasználóknak tesztelni kell a verzióval való kompatibilitást. Mivel egy közös fürt CRD-jének kezelése általában egy fürt rendszergazdája által kezelt dolog, dolgozunk a CRD-erőforrások frissítésének engedélyezésén a standard Nexus bővítményfolyamaton keresztül.
NfApp szekvenciális rendezési viselkedés
Áttekintés
Alapértelmezés szerint a tárolóalapú hálózati függvényalkalmazások (NfApps) telepítése vagy frissítése a hálózati függvények tervezési verziójában (NFDV) megjelenő sorrend alapján történik. Törlés esetén az NfApps fordított sorrendben lesz törölve. Ha a közzétevőnek az alapértelmezetttől eltérő NfApps-sorrendet kell meghatároznia, a dependsOnProfile használatával egyedi sorrendet határozhat meg a telepítési, frissítési és törlési műveletekhez.
A dependsOnProfile használata
A közzétevők az NFDV-ben található dependsOnProfile használatával szabályozhatják az NfApps helm-végrehajtásának sorrendjét. A következő példában az NfApps telepítése a következő sorrendben történik: dummyApplication1, dummyApplication2, majd dummyApplication. A frissítési művelet során az NfApps a következő sorrendben frissül: dummyApplication2, dummyApplication1, majd dummyApplication. A törlési művelet során az NfApps a következő sorrendben lesz törölve: dummyApplication2, dummyApplication1, majd dummyApplication.
{
"location": "eastus",
"properties": {
"networkFunctionTemplate": {
"networkFunctionApplications": [
{
"dependsOnProfile": {
"installDependsOn": [
"dummyApplication1",
"dummyApplication2"
],
"uninstallDependsOn": [
"dummyApplication1"
],
"updateDependsOn": [
"dummyApplication1"
]
},
"name": "dummyApplication"
},
{
"dependsOnProfile": {
"installDependsOn": [
],
"uninstallDependsOn": [
"dummyApplication2"
],
"updateDependsOn": [
"dummyApplication2"
]
},
"name": "dummyApplication1"
},
{
"dependsOnProfile": null,
"name": "dummyApplication2"
}
],
"nfviType": "AzureArcKubernetes"
},
"networkFunctionType": "ContainerizedNetworkFunction"
}
}
Gyakori hibák
A mai napon, ha az NFDV-ben megadott DependsOnProfile érvénytelen, az NF művelet érvényesítési hibával meghiúsul. Az érvényesítési hibaüzenet a műveletállapot-erőforrásban jelenik meg, és az alábbi példához hasonlóan jelenik meg.
{
"id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
"name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
"resourceId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourceGroups/xinrui-publisher/providers/Microsoft.HybridNetwork/networkfunctions/testnfDependsOn02",
"status": "Failed",
"startTime": "2023-07-17T20:48:01.4792943Z",
"endTime": "2023-07-17T20:48:10.0191285Z",
"error": {
"code": "DependenciesValidationFailed",
"message": "CyclicDependencies: Circular dependencies detected at hellotest."
}
}