Az Azure Operator Nexus fizikai redundanciát biztosít a verem minden szintjén.
Az Operátor Nexus üzembe helyezésének megtervezéséhez kövesse az alábbi lépéseket.
Határozza meg a kezdeti számítási feladatkészletet (Network Functions), amelyet az üzembe helyezésnek gazdagépre kell méreteznie.
Határozza meg az egyes számítási feladatok kapacitási követelményeit, ami lehetővé teszi az egyes számítási feladatok redundanciáit.
Ha a számítási feladatok támogatják a vezérlősík és az adatsík elemei közötti felosztást, fontolja meg, hogy különállóan tervezzen-e vezérlősík-helyeket, amelyek nagyobb számú szélesebb körben elosztott adatsík-helyet szabályozhatnak. Ez a lehetőség valószínűleg csak a nagyobb üzemelő példányok számára lesz vonzó. Kisebb üzemelő példányok vagy olyan számítási feladatokkal rendelkező üzemelő példányok esetén, amelyek nem támogatják a vezérlősík és az adatsík elválasztását, nagyobb valószínűséggel használ homogén helyarchitektúrát, ahol minden hely azonos.
Tervezze meg a számítási feladatok példányainak elosztását az egyes helytípusokhoz szükséges állványok számának meghatározásához, ami lehetővé teszi, hogy az egyes állványok operátori Nexus zónák. A platform kikényszerítheti az affinitás/affinitás-ellenes szabályokat ezen zónák hatókörében, hogy a számítási feladatok példányai úgy legyenek elosztva, hogy rugalmasak legyenek az egyes kiszolgálók vagy állványok hibáival szemben. Ebben a cikkben további információt talál az affinitás/affinitás-ellenes szabályokról. A Nexus Azure Kubernetes Service (NAKS) operátorvezérlő automatikusan elosztja a csomópontokat egy zónában elérhető kiszolgálók között, a lehető legegyenletesen, más korlátozásokon belül. Ennek eredményeképpen egyetlen kiszolgáló meghibásodása minimális hatással van a fennmaradó teljes kapacitásra.
A küszöbérték-redundancia tényezője, amely a frissítés során az egyes helyeken szükséges. Ez a konfigurációs beállítás azt jelzi a vezénylési motor számára, hogy a platformfrissítés sikeresnek és folytathatónak minősüljön, a feldolgozó csomópontok minimális számának rendelkezésre kell állnia. Ezeknek a csomópontoknak a lefoglalása bármilyen kapacitási fejtérbe beépül. A magasabb sáv beállítása csökkenti a teljes üzembe helyezés rugalmasságát az egyes csomópontok meghibásodásával szemben, de javítja a rendelkezésre álló kapacitás kihasználtságának hatékonyságát.
A Nexus operátor helyenként 1 és 8 állványt támogat, amelyek mindegyike 4, 8, 12 vagy 16 kiszolgálót tartalmaz. Minden állványnak azonosnak kell lennie a kiszolgálók száma szempontjából. A számítási feladatokhoz elérhető erőforrás jellemzőiről itt olvashat. Az alábbi ábrán és ebben a cikkben további korlátozásokat és kvótákat is bemutatunk, amelyek hatással lehetnek a kvótákra.
A Nexus operátor egy vagy két tárolóberendezést támogat. Ezek a tömbök jelenleg a Kubernetes-csomópontokként futó számítási feladatok NF-jei számára érhetők el. A virtuális gépekként futó számítási feladatok helyi tárolót használnak a példányosított kiszolgálóról.
Egyéb megfontolandó tényezők a rendelkezésre álló fizikai helyek száma, valamint a helyekre vonatkozó korlátozások, például a sávszélesség vagy a teljesítmény.
1. ábra – Operátori Nexus-elemek egyetlen helyen
A kapacitástervezés a legtöbb esetben iteratív folyamat. Együttműködhet a Microsoft-fiók csapatával, amely eszközkészlettel segíti a folyamat egyszerűbbé tétele érdekében.
Mivel az infrastruktúra iránti kereslet idővel növekszik, akár az előfizetői növekedés, akár a platformra migrált számítási feladatok miatt, az Operátor Nexus üzembe helyezése skálázható további állványok meglévő helyekhez való hozzáadásával, vagy új helyek hozzáadásával, olyan feltételektől függően, mint bármely hely korlátozása (teljesítmény, hely, sávszélesség stb.).
A számítási feladatok redundanciára vonatkozó követelményeinek figyelembe vétele
Azt javasoljuk, hogy méretezi az egyes számítási feladatokat az állványon belüli egyetlen kiszolgáló meghibásodása, egy teljes állvány meghibásodása és egy teljes webhely meghibásodása érdekében.
Fontolja meg például a 3 hely üzembe helyezését, mindegyik helyen 4 állvány, az egyes állványokon pedig 12 kiszolgáló található. Fontolja meg azt a számítási feladatot, amely a teljes üzembe helyezés során 400 csomópontot igényel a hálózati igények csúcsterheléskor való kielégítése érdekében. Ha ez a számítási feladat a kritikus infrastruktúra része, előfordulhat, hogy nem szeretné továbbadni a "felskálázást" a hibák kezeléséhez a csúcsterhelés idején. Ha mindig készen szeretne állni a szabad kapacitásra, félre kell tenni a kihasználatlan, tétlen kapacitást.
Ha redundanciát szeretne végezni a hely, az állvány és az egyéni kiszolgáló meghibásodása esetén, a számítások a következőképpen fognak kinézni:
A számítási feladathoz összesen 400 csomópontra van szükség a teljes üzemelő példányon, hogy a hálózati igényeket csúcsterheléskor kielégítse.
Ahhoz, hogy három helyen 400 csomópont legyen elosztva, webhelyenként 134 csomópontra van szükség (a rögzített költségek figyelmen kívül hagyásával). Egy hely meghibásodásának engedélyezése webhelyenként 200 csomópontra nő (így egyetlen hely meghibásodása 400 csomópontot hagy futni).
Ahhoz, hogy egy helyen belül 200 csomópont legyen, négy állvány között elosztva állványonként 50 csomópontra van szükség állványszintű redundancia nélkül. Egy állvány meghibásodásának engedélyezése állványonként 67 csomópontra növeli a követelményt.
Ha állványonként 67 csomópontot szeretne használni, amely 12 kiszolgáló között oszlik el, kiszolgálónként hat csomópontra van szükség, két kiszolgálónak pedig hétre van szüksége ahhoz, hogy az állványon belül egy kiszolgáló meghibásodhasson.
Bár a kezdeti követelmény az üzembe helyezés 400 csomópontja volt, a terv valójában 888 csomóponttal végződik. Az ábrán az egyes szintek csomópontszámához való hozzájárulás látható.
Egy másik számítási feladat esetében dönthet úgy, hogy nem "rétegezi" a redundancia több szintjét, figyelembe véve azt a nézetet, hogy az egyik hely egyidejű meghibásodására, egy másik helyen lévő állványra és egy másik, ugyanazon a helyen található egy másik állvány kiszolgálójára való tervezés túlzás. Végső soron az optimális kialakítás a számítási feladat által kínált adott szolgáltatástól, valamint a számítási feladat részleteitől, különösen a terheléselosztási funkciótól függ. Ha a szolgáltatást Markov-láncokkal modellezi a különböző hibamódok azonosítására, a kapcsolódó valószínűségekkel együtt, az is segít meghatározni, hogy mely hibák fordulhatnak elő reálisan egyszerre. Előfordulhat például, hogy egy olyan számítási feladat, amely képes háttérterhelést alkalmazni, ha egy adott hely kiszolgálóhiba miatt csökkentett kapacitással rendelkezik, akkor a forgalom átirányítható a még teljes redundanciával rendelkező helyek egyikére.
Hely üzembe helyezése és kapcsolata
Minden operátori Nexus-hely egy Azure-régióhoz csatlakozik, amely az Azure-on belüli erőforrásokat üzemelteti, például a Cluster Managert, az Operátor Nexus Fabric Controllert stb. Ideális esetben csatlakoztassa az egyes operátori Nexus-helyeket egy másik Azure-régióhoz annak érdekében, hogy maximalizálja az Operátor Nexus üzemelő példányának rugalmasságát az Azure-régiók megszakításával szemben. A földrajzi helyzettől függően valószínű, hogy kompromisszum jön létre a különböző Azure-régiók számának maximalizálása között, amelyektől az üzemelő példány függőséget vállal, valamint az adattárolásra vagy a szuverenitásra vonatkozó egyéb korlátozások között. Vegye figyelembe azt is, hogy a helyszíni példányok és a Fürtkezelő közötti kapcsolat nem feltétlenül 1:1. Egyetlen fürtkezelő több helyen is kezelheti a példányokat.
A virtuális gépek, beleértve a virtuális hálózati függvényeket (VNF-eket) és az operátori Nexus Azure Kubernetes Service -t (AKS), valamint a helyszínen üzemeltetett szolgáltatásokat a Nexus operátoron belül, magas rendelkezésre állású kapcsolatokon keresztül biztosítják a kapcsolattal. Ez a továbbfejlesztett kapcsolat redundáns fizikai kapcsolatok használatával érhető el, amelyeket zökkenőmentesen támogatnak a Virtual Function Link Aggregation (VF-Lag) technológiát alkalmazó egyetlen gyökérszintű bemeneti/kimeneti virtualizálási (SR-IOV) interfészek.
A VF-Lag technológia lehetővé teszi a virtuális függvények (VF-ek) logikai összekapcsolási aggregációs csoporttá (LAG) való összesítését a fizikai hálózati adapter (NIC) portpárja között. Ez a képesség robusztus és megbízható hálózati teljesítményt biztosít egyetlen, magas rendelkezésre állású virtuális függvény felfedésével. Ez a technológia nem igényel konfigurációt a felhasználók számára, hogy kihasználják az előnyeit, egyszerűsítve az üzembe helyezési folyamatot és növelve az általános felhasználói élményt.
Egyéb hálózatkezelési szempontok a rendelkezésre álláshoz
A Nexus operátor infrastruktúrája és számítási feladatai széles körben használják a tartománynévrendszert (DNS). Mivel az Operátor Nexus platformon belül nincs mérvadó DNS-válaszadó, nincs mit válaszolni a DNS-kérelmekre, ha az Operátor Nexus webhelye leválasztva lesz az Azure-ról. Ezért ügyeljen arra, hogy minden DNS-bejegyzés rendelkezzen élettartammal (TTL), amely összhangban van a kívánt maximális leválasztási időtartammal, amely jelenleg általában 72 óra.
Győződjön meg arról, hogy a Nexus operátor útválasztási táblái előre vannak konfigurálva redundáns útvonalak, nem pedig arra támaszkodva, hogy az útválasztási táblák a hálózati hibákhoz való igazodás érdekében módosíthatók legyenek. Bár ez a konfiguráció általánosan ajánlott eljárás, az Operátor Nexus esetében fontosabb, mivel az Operátor Nexus Network Fabric Controller nem lesz elérhető, ha az Operátor Nexus webhelye leválasztva lesz az Azure-régióról. Ebben az esetben a hálózati konfiguráció hatékonyan le van fagyasztva, amíg az Azure-kapcsolat vissza nem áll (a törésüveg funkció használatának tiltása). Azt is ajánlott biztosítani, hogy a háttérforgalom alacsony szintje folyamatosan áthaladjon a biztonsági mentési útvonalakon, hogy elkerülje ezeknek az útvonalaknak a "csendes hibáit", amelyek észrevétlenül haladnak, amíg szükség nem lesz rájuk.
Identitás és hitelesítés
A leválasztási esemény során a helyszíni infrastruktúra és számítási feladatok nem érik el az Entrát a felhasználói hitelesítés végrehajtása érdekében. A kapcsolat bontásának előkészítéséhez biztosíthatja, hogy az összes szükséges identitás, valamint a hozzájuk tartozó engedélyek és felhasználói kulcsok előre konfigurálva legyenek. A Nexus operátor egy API-t biztosít, amellyel az operátor automatizálhatja ezt a folyamatot. Ezen információk előre konfigurálásával biztosítható, hogy az infrastruktúra hitelesített felügyeleti hozzáférése továbbra is akadálytalanul folytatódjon az Entra-kapcsolat megszakadása miatt.
Platformfrissítés kezelése
A Nexus operátor frissítését az ügyfél kezdeményezi, de ezt követően maga a platform kezeli. Rendelkezésre állás szempontjából a következő pontok a legfontosabbak:
Az ügyfél teljes mértékben felügyeli a frissítést. Dönthetnek például úgy, hogy elindítják a frissítést egy karbantartási időszakban, és implementálhatják a saját biztonságos üzembehelyezési folyamatukat. Például egy új verzió fokozatosan üzembe helyezhető egy tesztkörnyezetben, majd egy kis üzemi helyen, majd nagyobb üzemi helyeken, lehetővé téve a tesztelést, és szükség esetén a visszaállítást.
A folyamat egyszerre csak egy állványon aktív a kijelölt helyen. Bár a frissítés helyben történik, a frissítés során továbbra is hatással van a munkavégző csomópontokra az állványon.
A frissítési folyamatról további információt ebben a cikkben talál. A vezérlősíkok rugalmasságának biztosításával kapcsolatos további információkért tekintse meg ezt a témakört.
Magas rendelkezésre állású számítási feladatok tervezése és üzemeltetése a Nexus operátorhoz
A számítási feladatoknak ideális esetben natív felhőbeli kialakítást kell követnie, natív N+k fürtökkel, amelyek több csomóponton és állványon is üzembe helyezhetők egy helyen, a Nexus operátor zóna koncepciójának használatával.
Az Azure-ban a kritikus fontosságú és a szolgáltatói szintű számítási feladatokra vonatkozó Well Architected Framework-útmutató a Nexus operátor számítási feladataira is vonatkozik.
A magas rendelkezésre állású számítási feladatok tervezése és implementálása bármely platformon felülről lefelé történő megközelítést igényel. Kezdje a megoldás egészéhez szükséges rendelkezésre állás ismeretével. Vegye figyelembe a megoldás legfontosabb elemeit és előrejelzett rendelkezésre állását. Ezután határozza meg, hogyan kell kombinálni ezeket az attribútumokat a megoldásszintű célok eléréséhez.
Számítási feladatok elhelyezése
A Nexus operátor széles körű támogatást nyújt a Kubernetes-vezénylőnek a számítási feladatok rendelkezésre álló munkavégző csomópontokon való üzembe helyezésének szabályozásához. A részletekért tekintse meg ezt a cikket .
Konfigurációs frissítések
Az Operátor Nexus platform az Azure Resource Manager használatával kezeli az összes konfigurációs frissítést. Ez lehetővé teszi, hogy a platform erőforrásai ugyanúgy kezelhetők legyenek, mint bármely más Azure-erőforrás, ami konzisztenciát biztosít a felhasználó számára.
A Nexus operátoron futó számítási feladatok hasonló modellt követhetnek, és saját erőforrás-szolgáltatókat (RP-ket) hozhatnak létre, hogy kihasználhassák a Resource Manager által kínált lehetőségeket. A Resource Manager csak akkor alkalmazhat frissítéseket a helyszíni NF-ekre, ha az Operátor Nexus-webhelye csatlakozik az Azure Cloudhoz. A leválasztási esemény során ezek a konfigurációfrissítések nem alkalmazhatók. Ez elfogadhatónak tekinthető az Operátor Nexus RP-k számára, mivel nem gyakori, hogy éles környezetben frissítik a konfigurációjukat. A számítási feladatok ezért csak akkor használják a Resource Managert, ha ugyanaz a feltételezés érvényes.
Számítási feladatok frissítése
A nyilvános felhőkörnyezetekkel ellentétben hibrid felhőplatformként a Nexus operátor korlátozottabb a rendelkezésre álló kapacitás tekintetében. Ezt a korlátozást figyelembe kell venni a számítási feladatpéldányok frissítési folyamatának tervezésekor, amelyet az ügyfélnek vagy potenciálisan a számítási feladat szolgáltatójának kell felügyelnie a Telco-ügyfél és a számítási feladat szolgáltatója közötti megállapodás részleteitől függően.
A számítási feladatok frissítéséhez különböző lehetőségek állnak rendelkezésre. A kapacitás szempontjából a leghatékonyabb és legkevésbé hatékony az, ha a NAKS által támogatott standard Kubernetes-folyamatokat használja az egyes számítási feladatok fürtjének "helyben" történő folyamatos frissítésére. Ez a folyamat által elfogadott operátor Nexus undercloud maga. Javasoljuk, hogy az ügyfél rendelkezik elérhető tesztkörnyezettel és előkészítési környezetekkel, hogy az üzemszintű számítási feladatok szoftvere érvényesíthető legyen az ügyfél pontos hálózatában a laborforgalom érdekében, majd korlátozott léptékben, mielőtt a teljes éles üzemet üzembe helyezheti.
Másik lehetőségként az uplevel szoftverkiadást "zöldmezős" fürtként kell üzembe helyezni, és egy adott időszakban át kell váltani a forgalmat a fürtre. Ez azzal az előnnyel jár, hogy elkerüli a "vegyes szintű" fürtök minden olyan időszakát, amely peremes eseteket eredményezhet. Emellett lehetővé teszi a forgalom óvatos átvitelét a leről a felső szintű szoftverekre, valamint egy egyszerű és megbízható visszaállítási folyamatot, ha bármilyen probléma merül fel. Ehhez azonban elegendő kapacitásra van szükség ahhoz, hogy két, párhuzamosan futó fürtöt támogatjon. Ez úgy érhető el, hogy leskálázzák a lefelé irányuló fürtöt, eltávolítva a redundancia egy részét vagy egészét, valamint a folyamat csúcsterheléseinek mértékét.
Az Azure HPC a HPC & AI számítási feladatok célhoz kötött felhőalapú képessége, amely élvonalbeli processzorokat és HPC-osztályú InfiniBand-összekapcsolásokat használ, így a legjobb alkalmazásteljesítményt, méretezhetőséget és értéket nyújtja. Az Azure HPC lehetővé teszi a felhasználók számára az innovációt, a termelékenységet és az üzleti rugalmasságot a magas rendelkezésre állású HPC & AI-technológiák révén, amelyek az üzleti és technikai igények változásával dinamikusan lefoglalhatók. Ez a képzési terv o
