Základní koncepty pro Azure Operator Service Manager

Tento článek obsahuje doporučení osvědčených postupů pro onboarding a nasazení síťových funkcí (NF) pomocí Azure Operator Service Manageru. Podle těchto základních pokynů můžou dodavatelé, operátoři a jejich partneři optimalizovat síťové služby nasazené pro operátory Azure Nexus. Zvažte tyto koncepty na začátku jakéhokoli procesu plánování onboardingu síťových funkcí.

Obecné aspekty

Doporučujeme, abyste nejprve nasadili a nasadili nejjednodušší NF (jeden nebo dva grafy) pomocí rychlých startů, abyste se seznámili s celkovým tokem. Do následných iterací můžete přidat potřebné podrobnosti o konfiguraci. Při procházení rychlých startů zvažte následující body:

Strukturujte artefakty tak, aby odpovídaly plánovanému použití. Zvažte oddělení globálních artefaktů od artefaktů, které se mají lišit podle lokality nebo instance.
Zajistěte, aby se složení služby více NF s sadou parametrů, které odpovídají potřebám vaší sítě. Můžete například přizpůsobit 100 hodnot v grafu, který má 1 000 hodnot. Ujistěte se, že ve vrstvě schématu skupiny konfigurace (CGS) (probírané podrobněji v následujících částech) zveřejňujete pouze 100.
Nejprve se zamyslete nad tím, jak chcete oddělit infrastrukturu (například clustery) nebo úložiště artefaktů a přístup mezi dodavateli, zejména v rámci jedné služby. Nastavení sady prostředků vydavatele odpovídá tomuto modelu.
Stránka Azure Operator Service Manager je logický koncept, který představuje cíl nasazení. Mezi příklady patří cluster Kubernetes pro kontejnerizované síťové funkce (CNFs) nebo rozšířené vlastní umístění operátora Azure pro virtualizované síťové funkce (VNF). Nejedná se o reprezentaci fyzického hraničního webu, takže máte případy použití, kdy několik webů sdílí stejné fyzické umístění.
Azure Operator Service Manager poskytuje různá rozhraní API, která vám pomůžou ho kombinovat s Azure DevOps nebo jinými nástroji pro pipeline.
Rozšíření rozhraní příkazového řádku Azure Operator Service Manageru (CLI) pomáhá s publikováním definic síťových funkcí (NFD) a NSD. Tento nástroj použijte jako výchozí bod pro vytváření nových NFD a NSD. Zvažte použití rozhraní příkazového řádku k vytvoření počátečních souborů. Před publikováním je pak upravte tak, aby zahrnovaly součásti infrastruktury.

Důležité informace o vydavateli

Doporučujeme vytvořit jednoho vydavatele pro každého dodavatele NF, nebo pro každý typ NF u každého dodavatele NF, pokud jeden dodavatel NF může poskytovat více než jeden typ NF. Tento postup;
- Poskytuje optimální podporu, údržbu a zásady správného řízení tím, že brání šíření vydavatelů. Zejména při aktivitách upgradu, kdy se stejná akce často provádí v mnoha NF.
- Snižuje celkové provozní náklady snížením počtu podpůrných prostředků vydavatele, jako je Azure Container Registry (ACR) nebo účty úložiště.
- Zjednodušuje návrh síťových služeb (NSD), kde se může skládat z několika NF od více dodavatelů.
Po otestování a schválení požadované sady prostředků vydavatele Azure Operator Service Manageru pro použití v produkčním prostředí doporučujeme označit celou sadu jako neměnnou. Označení sady jako neměnné pomáhá zabránit náhodným změnám a zajistit konzistentní prostředí nasazení. Označení neměnnosti pomáhají rozlišovat mezi:
- Prostředky a artefakty používané v produkčním prostředí
- Prostředky a artefakty používané k testování a vývoji

Můžete se dotazovat na stav prostředků vydavatele a manifesty artefaktů, abyste zjistili, které prostředky jsou označené jako neměnné. Další informace najdete v tématu Správa prostředků publisheru ve verzi Preview.

Mějte na paměti následující logiku:

Pokud je verze návrhu síťové služby (NSDV) označená jako neměnná, musí být CGS také označena jako neměnná. Jinak volání nasazení selže.
Pokud je verze definice síťové funkce (NFDV) označená jako neměnná, musí být manifest artefaktu také označen jako neměnný. Jinak volání nasazení selže.
Pokud je jako neměnný označen pouze manifest artefaktů nebo CGS, volání nasazení proběhne úspěšně bez ohledu na to, zda jsou NFDV a NSDV označeny jako neměnné.
Označení manifestu artefaktu jako neměnného zajišťuje, že všechny artefakty uvedené v tomto manifestu jsou také označeny jako neměnné vynucením nezbytných oprávnění v úložišti artefaktů. Uvedené artefakty obvykle zahrnují grafy, obrázky a šablony Azure Resource Manageru (šablony ARM).
Zvažte použití odsouhlasených zásad vytváření názvů a technik zásad správného řízení, které vám pomůžou vyřešit případné zbývající mezery.

Vysoká dostupnost vydavatele a zotavení po havárii

Vydavatel Azure Operator Service Manager je regionální služba nasazená pouze v místních zónách dostupnosti v podporovaných regionech. Zvažte následující požadavky na vysokou dostupnost a zotavení po havárii vydavatele:

Pokud chcete zajistit geografickou redundanci, ujistěte se, že máte vydavatele v každé oblasti, ve které plánujete nasadit NF. Zvažte použití kanálů k udržování artefaktů a prostředků vydavatele v synchronizaci napříč regiony.
Název vydavatele musí být jedinečný pro každého tenanta Microsoft Entra v každé oblasti.

Důležité informace o NFDG a NFDV

Skupina definic síťových funkcí (NFDG) představuje nejmenší komponentu, kterou chcete použít nezávisle na více službách. Všechny části NFDG se vždy nasazují společně. Tyto části se nazývají networkFunctionApplications položky. Je například přirozené připojit jeden NF, který se skládá z několika Helm chartů a image jako jediného NFDG, pokud tyto komponenty vždy nasadíte dohromady. V případech, kdy se vždy nasadí několik NF společně, je rozumné mít pro všechny z nich jednu NFDG. Jedna skupina NFDG může mít několik NFDV.

V případě souborů CNF NFDV networkFunctionApplications může seznam obsahovat pouze balíčky Helm.
- Pokud se balíčky Helm nasazují a odstraňují vždy společně, je rozumné zahrnout jich několik.
V případě VNF NFDV musí seznam obsahovat alespoň jednu hodnotu networkFunctionApplications a jednu šablonu ARM.
- Pokud chcete nasadit několik virtuálních počítačů pro jeden VNF, nezapomeňte pro každý virtuální počítač použít samostatnou šablonu ARM.

Šablona ARM může nasadit pouze prostředky Resource Manageru z následujících poskytovatelů prostředků:

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

U šablon ARM, které obsahují cokoli nad rámec předchozího seznamu, všechna PUT volání VNF způsobí chybu ověření.

Dílčí nebo hlavní aktualizace NFDV

NFDV představuje vydání základního NFDG a je spojena s jedinečnou verzí. S tím, jak se NF mění v průběhu času, se mnoho NFDV používá k zachycení schopností v kterémkoli okamžiku. Mezi typické změny, které aktivují nový NFDV, můžou patřit:

Aktualizace artefaktů NF, například nových grafů nebo verzí obrázků
Aktualizace hodnot CGS nebo hodnot konfiguračních skupin (CGV), které se mění deployParametersMappingRuleProfile.
Aktualizace všech výchozích hodnot pevně zakódovaných do NFDV
Aktualizace povolení komponent, aby se zabránilo jejich budoucímu nasazení prostřednictvím applicationEnablement: Disabled.

Poznámka:

Verze NF, která nezpřístupňuje nové parametry CGS, vyžaduje pouze aktualizaci manifestu artefaktů, nabízení nových obrázků a grafů a zvýšení NFDV.

Aspekty NSDG a NSDV

Skupina návrhu síťových služeb (NSDG) je složená z jedné nebo více skupin NFDG a všech komponent infrastruktury nasazených současně. Tyto komponenty můžou zahrnovat clustery a virtuální počítače ve službě Nexus Kubernetes nebo Azure Kubernetes Service (AKS). Síťová služba lokality (SNS) odkazuje na jednu síťovou službu NSDV. Takový návrh poskytuje konzistentní a opakovatelné nasazení síťové služby do lokality z jednoho volání SNS PUT .

Příkladem skupiny zabezpečení sítě může být:

Funkce ověřovacího serveru (AUSF) NF
Sjednocená správa dat (UDM) NF
Virtuální počítač pro správu, který podporuje AUSF nebo UDM
Funkce správy relací cloudu Unity (SMF) NF
Cluster Nexus Kubernetes, do kterého se nasazují AUSF, UDM a SMF

Těchto pět komponent tvoří jednu skupinu zabezpečení sítě. Jedna skupina NSDG může mít několik NSDV.

Dílčí nebo hlavní aktualizace NSDV

NSDV představuje vydání základního NSD a je přidruženo k jedinečné verzi. Změny NSDV jsou méně časté než změny NFDV a v některých případech jeden NSDV podporuje celý životní cyklus síťové služby lokality. Následující změny služby ale vyžadují nové NSDV:

Vytváření, odstraňování nebo přidávání hodnot v CGS
Změna šablony ARM NF použité prostředkem síťové služby nasazeným na lokalitě
Změna ARM šablony infrastruktury používané nasazovacím prostředkem stránky.

Poznámka:

Zveřejnění NFDV jako parametru v rámci CGS, aby operátoři mohli řídit, co se má nasadit pomocí CGV, a dále snížit frekvenci změn NSDV.

Doporučujeme mít jeden SNS pro celou lokalitu, včetně infrastruktury. SNS by měl nasadit veškerou požadovanou infrastrukturu (například clustery a virtuální počítače v Nexus Kubernetes nebo AKS) a potom nasadit požadované NF nahoře. Takový návrh poskytuje konzistentní a opakovatelné nasazení síťové služby do lokality z jednoho volání SNS PUT .

Doporučujeme nasadit všechny služby SNS se spravovanou identitou přiřazenou uživatelem místo spravované identity přiřazené systémem. Tato spravovaná identita přiřazená uživatelem musí mít oprávnění pro přístup k NFDV a musí mít roli operátora spravované identity na sobě. Další informace najdete v tématu Vytvoření a přiřazení spravované identity přiřazené uživatelem.

Aspekty schématu prostředků

Následující dva scénáře znázorňují mapování prostředků Service Manageru operátora Azure.

Scénář: Jedna síťová funkce

NF s jednou nebo dvěma komponentami aplikace se nasadí do clusteru Nexus Kubernetes. Tady je rozpis prostředků:

NFDG: Pokud lze komponenty používat nezávisle, dva NFDG s jedním pro každou komponentu. Pokud jsou komponenty vždy nasazené společně, pak jedna skupina NFDG.
NFDV: Podle potřeby na základě případů použití, které aktivují aktualizace menší nebo hlavní verze NFDV.
NSDG: Single. Kombinuje NF a definice clusteru Kubernetes.
NSDV: Podle potřeby na základě jednotlivých případů použití, které aktivují aktualizace podverze nebo hlavní verze NSDV.
CGS: Single. Pro snadnější správu doporučujeme, aby služba CGS obsahuje pododdíly pro každou komponentu a infrastrukturu, kterou nasazujete. Doporučujeme také, aby služba CGS obsahovala verze pro NFD.
CGV: Jeden na základě počtu CGS.
SNS: Jeden na NSDV.

Scénář: Více síťových funkcí

Do clusteru Nexus Kubernetes se nasadí několik NF s některými sdílenými a nezávislými komponentami. Tady je rozpis prostředků:

NFDG:
- Jedna pro všechny sdílené komponenty.
- Jeden pro každou nezávislou součást nebo NF.
NFDV: Různé pro každý NFDG podle případů použití, které spouštějí aktualizace menší nebo větší verze NFDV.
NSDG: Single. Kombinuje všechny NF, sdílené a nezávislé komponenty a infrastrukturu (cluster Kubernetes nebo všechny podpůrné virtuální počítače).
NSDV: Podle potřeby na základě jednotlivých případů použití, které aktivují aktualizace podverze nebo hlavní verze NSDV.
CGS:
- Svobodný/svobodná. Globální pro všechny komponenty.
- Jeden na NF, včetně verze NFD.
- V závislosti na celkovém počtu parametrů zvažte kombinování všech CGS do jediného CGS.
CGV: Rovná se počtu CGS.
SNS: Jeden na NSDV.

Úvahy o upgradu

Za předpokladu, že NF podporují místní a in-service upgrady, platí pro soubory CNF následující aspekty:

Pokud přidáte nové grafy a obrázky, Azure Operator Service Manager nainstaluje nové grafy.
Pokud některé grafy a obrázky odeberete, Azure Operator Service Manager odstraní grafy, které už nejsou deklarovány v NFDV.
Azure Operator Service Manager ověřuje, že NFDV/NSDV pochází ze stejné skupiny NFDG/NSDG, a proto stejného vydavatele. Upgrade mezi vydavateli se nepodporuje.

Pro VNFs platí následující aspekty:

Místní upgrady se v současné době nepodporují. Musíte vytvořit instanci nového VNF s aktualizovanou imagí vedle sebe. Potom odstraňte starší VNF odstraněním služby SNS.
Pokud je virtuální systém VNF nasazený jako dvojice virtuálních počítačů pro zajištění vysoké dostupnosti, můžete síťovou službu navrhnout tak, abyste je mohli odstranit a upgradovat jeden po druhém. Doporučujeme následující návrh, který umožňuje odstranění a upgrade jednotlivých virtuálních počítačů:
- Nasaďte každý virtuální počítač pomocí vyhrazené šablony ARM.
- Ze šablony ARM musíte prostřednictvím CGS zveřejnit dva parametry:
  - Název virtuálního počítače, aby bylo možné určit, která instance je primární nebo sekundární
  - Zásady nasazení pro řízení, jestli je nebo není povolené nasazení virtuálního počítače
- V NFDV je nutné parametrizovat deployParameters a templateParameters takovým způsobem, abyste mohli pro každý zadat jedinečné hodnoty pomocí CGV.

Informace o odstraňování potíží

Během instalace a upgradu ve výchozím nastavení:

Možnosti atomic a wait jsou nastaveny na true.
Časový limit operace je nastavený na 27 minutes.

Během počátečního onboardingu doporučujeme, abyste příznak atomic nastavili na false pouze v době, kdy stále ladíte a vyvíjíte artefakty. Toto nastavení brání vrácení Helm při selhání a zachovává všechny záznamy nebo chyby, které by jinak byly ztraceny. Optimální způsob, jak toho dosáhnout, je v šabloně ARM pro NF. Do šablony ARM přidejte následující část:

<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>

Název komponenty je definován v NFDV:

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

Důležité

Po dokončení počátečního onboardingu nezapomeňte vrátit atomic a wait zpět na true.

Důležité informace o vyčištění

Při čištění prostředků je pořadí důležité. Odstraněním prostředků mimo pořadí může dojít k tomu, že osamocené prostředky zůstanou za sebou.

Prostředky operátora

Jako první krok k vyčištění nasazeného prostředí odstraňte prostředky operátora v následujícím pořadí:

Můžete pokračovat odstraněním jiných prostředků prostředí, jako je cluster Kubernetes Nexus, až po úspěšném odstranění těchto prostředků operátora.

Zdroje informací o vydavateli

Jako první krok směrem k vyčištění nasazeného prostředí odstraňte prostředky vydavatele v následujícím pořadí:

NSDV
NSDG
NFDV
NFDG
Manifest artefaktů
Úložiště artefaktů
Vydavatel