Osvědčené postupy pro onboarding a nasazení síťových funkcí v Azure Operator Service Manageru
Microsoft vyvinul mnoho osvědčených postupů pro správu síťových funkcí (NFS) pomocí Azure Operator Service Manageru. Tento článek obsahuje pokyny, podle kterého můžou dodavatelé NF, operátoři telco a jejich partneři postupovat při optimalizaci návrhu. Mějte tyto postupy na paměti při onboardingu a nasazení NF.
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 mít například graf, který má 1 000 hodnot a přizpůsobíte 100 z nich. Ujistěte se, že ve vrstvě schématu skupiny konfigurace (CGS) (probírané podrobněji v následujících částech) zveřejníte 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.
- Web Azure Operator Service Manager je logický koncept, který představuje cíl nasazení. Příkladem je cluster Kubernetes pro kontejnerizované síťové funkce (CNF) nebo rozšířené vlastní umístění operátora Azure pro virtualizované síťové funkce (VNFs). 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, což usnadňuje kombinování s ADO nebo jinými nástroji kanálu.
Důležité informace o vydavateli
Doporučujeme vytvořit jednoho vydavatele pro jednoho dodavatele NF. Tento postup poskytuje optimální možnosti podpory, údržby a zásad správného řízení u všech dodavatelů a zjednodušuje návrh síťových služeb, pokud se skládá z více NF od více dodavatelů.
Po otestování a schválení požadované sady prostředků a artefaktů vydavatele Azure Operator Service Manageru pro produkční použití doporučujeme označit celou sadu jako neměnnou, aby se zabránilo náhodným změnám a zajistilo konzistentní prostředí nasazení. Zvažte možnost spoléhat se na neměnnost schopností rozlišovat mezi prostředky a artefakty používanými v produkčním prostředí a s možnostmi používanými pro účely testování a vývoje. 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 Tenanti vydavatele, předplatná, oblasti a správa verze Preview.
Mějte na paměti následující logiku:
- Pokud je funkce návrhu síťové služby (NSDV) označená jako neměnná, musí být CGS označena také jako neměnná. Jinak volání nasazení selže.
- Pokud je verze návrhu 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 neměnný pouze manifest artefaktu nebo CGS, volání nasazení proběhne úspěšně bez ohledu na to, jestli jsou NFDV a NSDV označené jako neměnné.
- Označení manifestu artefaktu jako neměnné zajišťuje, že všechny artefakty uvedené v tomto manifestu (obvykle, grafy, obrázky a šablony Azure Resource Manageru [šablony ARM]) jsou také označené neměnným vynucením potřebných oprávnění v úložišti artefaktů.
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.
Důležité informace o skupině definicí síťových funkcí a verzích
Skupina definic síťových funkcí (NFDG) představuje nejmenší komponentu, kterou chcete opakovaně používat nezávisle na více službách. Všechny části NFDG se vždy nasazují společně. Tyto části jsou volána networkFunctionApplications. Je například přirozené připojit jeden NF složený z více grafů Helm a obrázků jako jeden NFDG, pokud tyto komponenty vždy nasadíte dohromady. V případech, kdy se vždy nasadí více NF, je vhodné mít pro všechny z nich jedinou skupinu NFDG. Jedna skupina NFDG může mít několik NFDV.
Pro verze definic kontejnerizovaných síťových funkcí (CNF NFDV) networkFunctionApplications může seznam obsahovat pouze balíčky Helm. Pokud jsou balíčky helmu vždy nasazené a odstraněné společně, je vhodné zahrnout více balíčků Helm.
V případě verzí definic virtualizovaných síťových funkcí (VNF NFDV) networkFunctionApplications musí seznam obsahovat alespoň jednu VhdImageFile a jednu šablonu ARM. Šablona ARM by měla nasadit jeden virtuální počítač. Pokud chcete nasadit několik virtuálních počítačů pro jeden VNF, nezapomeňte pro každý virtuální počítač použít samostatné šablony 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
Poznámka:
U šablon ARM, které obsahují cokoli nad rámec předchozího seznamu, všechna volání PUT a re-PUT na VNF způsobí chybu ověření.
Běžné případy použití, které aktivují podverzi návrhu síťové funkce nebo aktualizaci hlavní verze
- Aktualizace hodnot CGS/konfigurační skupiny (CGV) pro stávající verzi, která aktivuje změnu
deployParametersMappingRuleProfile. - Aktualizace hodnot, které jsou pevně zakódované v NFDV.
- Označení komponent neaktivní, aby se zabránilo jejich nasazení prostřednictvím
applicationEnablement: Disabled. - Nová verze NF, jako jsou grafy a obrázky.
Poznámka:
Minimální počet změn požadovaných při každé datové části dané změny NF. Menší nebo hlavní verze NF bez zveřejnění nových parametrů CGS vyžaduje pouze aktualizaci manifestu artefaktů, nasdílení nových obrázků a grafů a zvýšení verze NFDV.
Důležité informace o skupině a verzi návrhu síťových služeb
Skupina NSDG (Network Service Design Group) je složená z jedné nebo více skupin NFDG a všech komponent infrastruktury (například Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] a virtuálních počítačů) nasazených současně. Síťová služba lokality (SNS) odkazuje na jednu síťovou službu NSDV. Takový návrh zaručuje konzistentní a opakovatelné nasazení síťové služby do dané lokality z jedné sítě SNS PUT.
Příkladem NSDG je:
- Funkce ověřovacího serveru (AUSF) NF
- Sjednocené Správa dat (UDM) NF
- Správa virtuální počítač podporující AUSF/UDM
- Funkce správy relací Unity Cloud (UC) (SMF) NF
- Cluster NAKS, 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.
Běžné případy použití, které aktivují podverzi návrhu síťové služby nebo aktualizaci hlavní verze
- Vytváření nebo odstraňování CGS
- Změny v šabloně ARM NF přidružené k některému z nasazovaných NF
- Změny v šabloně ARM infrastruktury, například AKS/NAKS nebo virtuální počítač.
Poznámka:
Změny ve NFDV by neměly aktivovat aktualizaci NSDV. Hodnota NFDV by měla být zpřístupněna jako parametr v rámci CGS, aby operátoři mohli řídit, co se má nasadit, pomocí CGV.
Důležité informace o schématu skupiny konfigurace
Doporučujeme, abyste vždy začali s jedním CGS pro celý systém NF. Pokud existují parametry specifické pro lokalitu nebo instanci, přesto doporučujeme je uchovávat v jediné službě CGS. Pokud existuje více komponent (zřídka NF, běžněji infrastruktura) nebo konfigurace sdílených mezi více NF, doporučujeme rozdělit na několik sad CGS. Počet CGS definuje počet CGV.
Scénář
- FluentD, Kibana a Splunk (běžné komponenty třetích stran) se vždy nasazují pro všechny NSD v rámci NSD. Tyto komponenty doporučujeme seskupit do jediné skupiny NFDG.
- NSD obsahuje několik NF, které sdílejí několik konfigurací (umístění nasazení, název vydavatele a několik konfigurací grafů).
V tomto scénáři doporučujeme použít jednu globální CGS k zveřejnění společné konfigurace komponent NF a třetích stran. Podle potřeby můžete definovat CGS specifické pro NF.
Zvolte parametry, které chcete zveřejnit.
- CGS by měl mít jenom parametry, které používají NF (konfigurace dnů 0/N) nebo sdílených komponent.
- Parametry, které jsou zřídka nakonfigurované, by měly mít definované výchozí hodnoty.
- Pokud se používá více CGS, doporučujeme, aby se parametry nepřekrývaly. Pokud se vyžaduje překrývání, ujistěte se, že názvy parametrů jsou jasně rozlišitelné mezi CGS.
- Co je možné definovat prostřednictvím rozhraní API (Azure Operator Nexus, Azure Operator Service Manager) by se mělo zvážit pro CGS. Na rozdíl od například definování těchto konfiguračních hodnot prostřednictvím souborů CloudInit.
- Pokud si nejste jisti, dobrým výchozím bodem je zveřejnit parametr a mít přiměřené výchozí hodnoty zadané v CGS. Následující příklad ukazuje ukázkové CGS a odpovídající datové části CGV.
- Ve všech šablonách ARM NF by se měla používat jedna spravovaná identita přiřazená uživatelem a měla by být zpřístupněna prostřednictvím CGS.
Datová část CGS:
{
"type": "object",
"properties": {
"abc": {
"type": "integer",
"default": 30
},
"xyz": {
"type": "integer",
"default": 40
},
"qwe": {
"type": "integer" //doesn't have defaults
}
}
"required": "qwe"
}
Odpovídající datová část CGV předaná operátorem:
{
"qwe": 20
}
Výsledná datová část CGV vygenerovaná nástrojem Azure Operator Service Manager:
{
"abc": 30,
"xyz": 40,
"qwe": 20
}
Důležité informace o hodnotách skupiny konfigurace
Před odesláním vytvoření prostředku CGV můžete ověřit, že schéma a hodnoty podkladového souboru YAML nebo JSON odpovídají tomu, co odpovídající CGS očekává. K tomu je jednou z možností použití rozšíření YAML pro Visual Studio Code.
Aspekty rozhraní příkazového řádku
Rozšíření Azure Operator Service Manager CLI pomáhá s publikováním 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 síťové službě lokality
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 NAKS/AKS a virtuální počítače) a pak nasadit NFs požadované nahoře. Takový návrh zaručuje konzistentní a opakovatelné nasazení síťové služby do dané lokality z jedné sítě SNS PUT.
Doporučujeme, aby se všechny služby SNS nasazovaly se spravovanou identitou přiřazenou uživatelem, a ne se spravovanou identitou přiřazenou 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. Další informace najdete v tématu Vytvoření a přiřazení spravované identity přiřazené uživatelem.
Mapování prostředků Service Manageru operátora Azure na případ použití
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 NAKS.
Rozpis prostředků:
- NFDG: Pokud lze komponenty používat nezávisle, dva NFDG, jeden na součást. Pokud jsou komponenty vždy nasazené společně, pak jedna skupina NFDG.
- NFDV: Podle potřeby na základě případů použití uvedených v předchozích částech "Běžné případy použití", které aktivují aktualizace podverze NFDV nebo hlavní verze.
- NSDG: Single. Kombinuje NF a definice clusteru Kubernetes.
- NSDV: Podle potřeby na základě případů použití uvedených v předchozích částech "Běžné případy použití", které aktivují aktualizace podverze NSDV nebo hlavní verze.
- CGS: Single. Doporučujeme, aby služba CGS obsahovala pododdíly pro každou komponentu a infrastrukturu, která se nasazuje pro snadnější správu, a obsahuje 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 NAKS se nasadí několik NF s některými sdílenými a nezávislými komponentami.
Rozpis prostředků:
- NFDG:
- NFDG pro všechny sdílené komponenty.
- NFDG pro každou nezávislou součást nebo NF.
- NFDV: Více na každý NFDG na případ použití uvedený v předchozích částech "Běžné případy použití", které aktivují aktualizace podverze NFDV nebo hlavní verze.
- 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ě případů použití uvedených v předchozích částech "Běžné případy použití", které aktivují aktualizace podverze NSDV nebo hlavní verze.
- CGS:
- Svobodný/svobodná. Globální pro všechny komponenty, které mají sdílené hodnoty konfigurace.
- NF CGS 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.
Aspekty upgradu softwaru
Za předpokladu, že NF podporují místní nebo in-service upgrady, pro soubory CNF:
- Pokud se přidají nové grafy a obrázky, Azure Operator Service Manager nainstaluje nové grafy.
- Pokud se některé grafy a obrázky odeberou, 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:
- 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 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čů:
- Každý virtuální počítač se nasadí pomocí vyhrazené šablony ARM.
- Ze šablony ARM je potřeba vystavit dva parametry prostřednictvím CGS: název virtuálního počítače, který umožňuje indikovat, která instance je primární/sekundární, a zásady nasazení, které řídí, jestli je nasazení virtuálního počítače povolené, nebo ne.
- V NFDV a
templateParametersmusí být parametrizován tak,deployParametersaby bylo možné zadat jedinečné hodnoty pomocí CGV pro každý.
Důležité informace o vysoké dostupnosti a zotavení po havárii
Azure Operator Service Manager je regionální služba nasazená napříč zónami dostupnosti v oblastech, které je podporují. Všechny oblasti, ve kterých je dostupný Service Manager operátora Azure, najdete v produktech Azure podle oblastí. Seznam oblastí Azure, které mají zóny dostupnosti, najdete v tématu Volba správné oblasti Azure.
Vezměte v úvahu následující požadavky na vysokou dostupnost a zotavení po havárii:
- 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ů, abyste měli jistotu, že jsou artefakty a prostředky vydavatele synchronizované napříč oblastmi.
- Název vydavatele musí být jedinečný pro každou oblast na tenanta Microsoft Entra.
Poznámka:
Pokud oblast přestane být dostupná, můžete NF nasadit (ale ne upgradovat) pomocí prostředků vydavatele v jiné oblasti. Za předpokladu, že artefakty a prostředky jsou identické mezi vydavateli, stačí změnit networkServiceDesignVersionOfferingLocation hodnotu v datové části prostředku SNS.
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
Informace o odstraňování potíží
Během instalace a upgradu jsou ve výchozím nastavení nastaveny truemožnosti atomické a čekání a časový limit operace je nastaven na 27 minutes. Během připojování doporučujeme nastavit atomický příznak, aby false se zabránilo vrácení helmu při selhání. Optimální způsob, jak toho dosáhnout, je v šabloně ARM NF.
Do šablony ARM přidejte následující část:
"roleOverrideValues": [
"{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]
Název komponenty je definován v NFDV:
networkFunctionTemplate: {
nfviType: 'AzureArcKubernetes'
networkFunctionApplications: [
{
artifactType: 'HelmPackage'
name: 'fed-crds'
dependsOnProfile: null
artifactProfile: {
artifactStore: {
id: acrArtifactStore.id
}
Důležité informace o vyčištění
Odstraňte prostředky operátoru v následujícím pořadí, abyste měli jistotu, že žádné osamocené prostředky zůstanou za sebou:
- SNS
- Site
- CGV
Důležité
Před odstraněním NFDV se ujistěte, že je SNS odstraněna.
Odstraňte prostředky vydavatele v následujícím pořadí, abyste měli jistotu, že nezachovají žádné osamocené prostředky:
- CGS
- NSDV
- NSDG
- NFDV
- NFDG
- Manifest artefaktů
- Úložiště artefaktů
- Publisher
Další kroky
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro