Az Azure Local felhőbeli üzembe helyezésének hálózati szempontjai

A következőkre vonatkozik: Azure Local hiperkonvergens telepítésekre

Ez a cikk ismerteti, hogyan kell tervezni és kialakítani egy Azure helyi rendszerhálózatot a felhőbeli üzembe helyezéshez. A folytatás előtt ismerkedjen meg a különböző Azure Local hálózati mintákkal és az elérhető konfigurációkkal.

Miért érdemes hálózattervezési keretrendszert létrehozni?

Egy Azure Local-példány gazdagéphálózatának tervezése több mint 10 összekapcsolási döntéssel jár: kapcsolati mód, architektúra, fizikai topológia, fürtméret, tárolókapcsolat, hálózati adapter portok, hálózati forgalom szándékai, IP-címzés, VLAN-k, biztonsági mentés, kimenő kapcsolatok és szoftveralapú hálózatkezelés. A strukturált keretrendszerek a következőkben segítenek:

  • Minden döntést egyszer, a megfelelő sorrendben kell meghoznia, hogy a korábbi döntések korlátozzák és egyszerűsítse a későbbieket.
  • Már korán kiszűrheti az érvénytelen kombinációkat, például az architektúra, a tárolási típus és a célok nem támogatott kombinációit.
  • Közös szókincs létrehozása az építészek, a műveletek és a helyszíni környezetek között.
  • Alkalmazzon egy megismételhető folyamatot az egycsomópontos peremfürttől a 64 csomópontos, többállványos telepítésig.

Hálózattervezési keretrendszer

A hálózattervezési keretrendszer 11 döntés sorozata a Azure Local-példányhoz. Először döntse el a csatlakozási módot, majd válasszon olyan architektúrát, amely a tervet hiperkonvergens (HCI) vagy diszaggregált (DA) irányba tereli. Minden későbbi döntés az útvonalakat is dokumentálja, és a tervezési szempontok listájával zár:

  1. Kapcsolati mód meghatározása
  2. Architektúra meghatározása
  3. Fürttopológia meghatározása
  4. Fürt méretének meghatározása
  5. Tárolókapcsolat meghatározása
  6. Hálózati adapter portjának és konfigurációjának meghatározása
  7. Hálózati forgalom szándékainak meghatározása
  8. Felügyeleti IP-címek és infrastruktúra-hálózat meghatározása
  9. Biztonsági mentési hálózat meghatározása
  10. A kimenő kapcsolat ellenőrzése
  11. Szoftveralapú hálózatkezelés (SDN) meghatározása

1. döntés: Kapcsolati mód meghatározása

A kapcsolati mód határozza meg, hogy a Azure Local példány hogyan éri el a Azure a regisztrációhoz, számlázáshoz és életciklus-kezeléshez. Ön dönti el először, mert a hiperkonvergens és a nem összesített architektúrákra egyaránt vonatkozik, és befolyásolja a kimenő kapcsolat kialakítását a 10. határozatban.

  • Csatlakoztatott: A csomópontok és az infrastruktúra-szolgáltatások az interneten keresztül érik el a Azure – közvetlenül, vállalati proxyn keresztül, az Azure Arc átjárón keresztül vagy ExpressRoute/S2S VPN-en keresztül. Ez a leggyakoribb mód, és a standard felhőbeli üzembe helyezéshez szükséges. A kimenő kapcsolatok részleteit a 10. határozatban tervezheti meg.
  • Kapcsolat nélküli (internettől leválasztott): Szuverén, szabályozott vagy internettől leválasztott környezetek esetén az Azure Local kapcsolat nélküli működése helyi autonóm felhőbeli végpontot biztosít a nyilvános Azure-végpontok helyett. A leválasztott üzembe helyezés egy helyszíni Azure Arc vezérlősíkot használ, amely egy dedikált 3 csomópontos felügyeleti fürtön fut.

Az alábbiakban összefoglaltuk a kapcsolati mód döntésének szempontjait:

# Megfontolás A következőkre vonatkozik:
1 A csatlakoztatott telepítések kimenő hozzáférést igényelnek az Azure-hoz az Arc-regisztrációhoz, a számlázáshoz és az életciklus-kezeléshez. Tervezze meg a kimenő topológiát a 10. határozatban. Both
2 A leválasztott telepítések az Azure Local leválasztott működési módját használják egy helyi Autonomous Cloud-végponttal, és nem igényelnek nyilvános Azure-végpontokat. Both
3 A leválasztott környezetben történő telepítésekhez egy dedikált, háromcsomópontos felügyeleti fürtre, valamint egy vagy több munkaterhelési fürtre van szükség. Both
4 A kapcsolati mód a 2. határozatban kiválasztott hiperkonvergens és nem összesített architektúrákra is vonatkozik. Both

2. döntés: Architektúra meghatározása

Az architektúra döntése két útvonal egyikére alakítja át a tervet. Meghatározza a tárarchitektúrát, a fürt méretét és a jelen cikk további részében elérhető hálózati szándékokat.

Architecture Tárolási architektúra Jellemző skálázás Mikor érdemes használni?
Hiperkonvergens (HCI) Helyi NVMe-/SSD-/HDD-meghajtók Közvetlen tárolóhelyek (S2D) használatával tárolókészletbe szervezve. Tárolóforgalom RDMA-n keresztül. 1–16 csomópont, egyállványos vagy állványérzékeny A legtöbb telepítés. A számítás és a tárolás együtt skálázható.
Hyperconverged (HCI) – hibrid tárolási változat S2D és egy külső SAN egymás mellett. Válassza ki a számítási feladatonkénti tárolási típust. 1–16 csomópont, egy állvány Egy hiperkonvergens fürt, amely adott számítási feladatokhoz SAN-alapú köteteket is igényel. A SAN-t a kezdeti telepítést követően kell csatlakoztatni; a rackszintű topológia figyelembevétele nem támogatott.
Nem összesített (DA) Külső SAN – Fibre Channel (FC) vagy IP-alapú SAN. Nincs S2D. Számítási és tárolási skálázás egymástól függetlenül. 1–8 állvány, állványonként legfeljebb 16 csomópont és fürtenként 64 csomópont Már SAN-alapú tárolást üzemeltet, vagy a számítási és a tárolókapacitást egymástól függetlenül kell skáláznia.

A hiperkonvergens architektúra opcionális hibrid tárolóvariánssal is rendelkezik, amely egy külső SAN-t futtat párhuzamosan az S2D-vel, így számítási feladatonként kiválaszthatja a tárolási típust. Ez egy csak hiperkonvergens konfiguráció, amelyet a kezdeti üzembe helyezés után csatol. Az 5. döntés ismerteti a tervezés részleteit és a támogatott külső tárolóintegrációkat.

A keretrendszer minden döntése egymás mellett dokumentálja mindkét architektúrát, külön hiperkonvergens (HCI) és nem összesített (DA) szakaszokkal. Kövesse az itt kiválasztott architektúrához tartozó tervezési döntéseket.

Az architektúra döntésének összesítő szempontjai:

# Megfontolás A következőkre vonatkozik:
1 A választott architektúra határozza meg a későbbi lépésekben elérhető tárolási kapcsolatokat, hálózati adapterportokat és hálózati forgalom szándékait. Both
2 A hiperkonvergens infrastruktúra (HCI) támogat egy állványtudatos változatot, amely a fürtöt két helyiségre vagy rendelkezésre állási zónára terjeszti ki, míg a szétválasztott (DA) több állványon keresztül skálázható. A fizikai elrendezést a 3. döntésben határozhatja meg. Both
3 A hiperkonvergens (HCI) a helyi meghajtókkal működő Közvetlen tárolóhelyeket használ. A számítás és a tárolás együtt skálázható, legfeljebb 16 csomópont. HCI
4 A hibrid tárolás kizárólag hiperkonvergens változat: a fürt S2D-vel üzemel egy külső SAN-nal párhuzamosan. A külső san-t a kezdeti üzembe helyezés (2. nap) után csatolja, nem az első üzembe helyezés során. HCI
5 A szétválasztott (DA) külső SAN-t használ — Fiber Channel (FC) vagy IP-alapú SAN-t — Közvetlen tárolóhelyek nélkül. A számítási kapacitás és a tárolókapacitás egymástól függetlenül skálázható 1–8 állványon, állványonként legfeljebb 16 csomóponttal, klaszterenként pedig legfeljebb 64 csomóponttal. DA

3. döntés: Fürttopológia meghatározása

A fürttopológia döntése határozza meg a csomópontok és kapcsolók fizikai elrendezését. Az elérhető lehetőségek a 2. határozatban kiválasztott architektúrától függenek.

Mindkét architektúra szabványos fizikai alakzata egyetlen állvány, amelyen egy pár top-of-rack (ToR) kapcsoló található:

  • Egy pár, MLAG-gel konfigurált ToR kapcsoló, amely ugyanabban az állványban legfeljebb 16 csomópontot kezel.
  • Egy alaplapi felügyeleti vezérlő (BMC) kapcsoló a sávon kívüli felügyelethez a ToRs felett.
  • A meglévő magkapcsoló, útválasztó vagy tűzfal felé irányuló felcsatlakozások.

Hiperkonvergens (HCI)

A hiperkonvergens fürtök egyetlen állványt vagy állványérzékeny elrendezést használnak:

  • Egy állvány: Az összes csomópont és a ToR kapcsolópár egy állványban található, és legfeljebb 16 csomópontot támogat. A váltott minták esetében az összes gazdaforgalom – a felügyelet, a számítás és a tárolás – ugyanazon a kapcsolópáron fut.

  • Racktudatos (két zóna): A racktudatos fürt a hiperkonvergens telepítést két helyiség vagy rendelkezésre állási zóna között osztja el:

    • Páros számú csomópont oszlik el két helyiség között, legfeljebb 8 csomóponttal, a klaszter két rendelkezésre állási zónájához rendelve.
    • Az S2D-replikáció helyiségei között kevesebb mint 1 ms késés szükséges.
    • Az RDMA-tárolóforgalom a ToR-rétegben marad, és soha nem halad át a gerincen.

    Négy uplinklehetőség érhető el a rack-aware fürtök esetében:

    Option Topology Jegyzetek
    1. Dedikált tárolóhivatkozások 2 ToR szobánként (összesen 4) TOR1↔TOR3 a VLAN 711-en, TOR2↔TOR4 a VLAN 712-en.
    2. Összesített tárolási hivatkozások 2 ToR szobánként (összesen 4) A tároló LAG/vPC-t használ a helyiségek között; az 1. opcióhoz képest további ugrás és nagyobb RDMA-késleltetés lehetséges.
    3. Helyiségenkénti csomópontkapcsolatok 1 toR szobánként (összesen 2) Mindkét tárolóhálózat helyiségenként ugyanazt a ToR-t használja; kötegelt helyiségek közötti kapcsolat.
    4. Helyiségközi csomópontkapcsolat 1 toR szobánként (összesen 2) Minden gép mindkét helyiségben lévő ToR-ekhez van bekábelezve; ez csökkenti a ToR-ek közötti függőséget, de növeli a kábelezési igényt.

Nem összesített (DA)

A nem összesített fürtök 1–8 állványra terjedhetnek ki:

  • Egy állvány: Egy kétkapcsolós HSRP-pár legfeljebb 16 csomóponthoz elegendő. A fürthálózatok önálló hálózati portokon futnak, és a hálózati ATC nem kezeli.
  • Több állvány: Több mint 16 csomópont esetén terjessze a fürtöt akár 8 állványra, amelyeket egy levél-gerinc (Clos) háló köt össze: mindegyik állvány két számítási levélkapcsolóval rendelkezik, két gerincvel és két szolgáltatási levélkapcsolóval az állványok felett. Minden rack egyenként legfeljebb 16 csomópont befogadására képes, a fürt pedig összesen legfeljebb 64 csomópontig bővíthető. Csak a hálóalapú SDN támogatott; Microsoft SDN nem támogatott.

A levél-gerinc háló architektúrájáról, a forgalomról és a nem összesített minták kiválasztásáról további információt a hálózathivatkozási minták áttekintésében talál a nem összesített üzemelő példányok esetében, és válassza ki a hálózati referenciamintát a nem összesített üzemelő példányokhoz.

A fürttopológia döntésének összesítési szempontjai a következők:

# Megfontolás A következőkre vonatkozik:
1 Egyetlen, egy pár ToR kapcsolóval rendelkező állvány mindkét architektúra esetén akár 16 csomópontot is támogat. Both
2 A hiperkonvergens, egyállványos fürtökben az összes gazdaforgalom — a felügyeleti, a számítási és a tárolási forgalom — ugyanazon, MLAG-gal konfigurált ToR-kapcsolópáron halad át. Ne használjon külön, csak tárolásra szolgáló kapcsolópárt. HCI
3 A hiperkonvergens, állványszintet figyelembe vevő fürtök két helyiséget vagy rendelkezésre állási zónát fognak át, páros számú, legfeljebb 8 csomópontból állnak, és a helyiségek közötti késleltetés 1 ms-nál kisebb. A racktudatos fürtök nem támogatottak külső SAN- (hibrid) tárolóval. HCI
4 Hiperkonvergens, állványtudatos fürtök esetében válassza a négy uplinkbeállítás egyikét. A dedikált tárolókapcsolatok (1. lehetőség) a legalacsonyabb késéssel tartják az RDMA-forgalmat a ToR-rétegben. HCI
5 A szétválasztott fürtök 1–8 állványt foglalnak magukban, amelyeket leaf-spine (Clos) hálózat köt össze, állványonként legfeljebb 16, fürtönként pedig legfeljebb 64 csomóponttal. DA
6 Több mint 16 nem összesített csomóponthoz használjon levél-gerinc hálót több állványon. Csak a hálóalapú SDN támogatott. DA

4. döntés: A fürt méretének meghatározása

A Azure Local-példány méretének meghatározásához használja a Azure Local Odinben található Azure Local méretező eszközt vagy közösségi eszközméretítőt, ahol meghatározhatja a profilját, például a virtuális gépek számát (virtuális gépek számát), a virtuális gépek méretét és a virtuális gépek számítási feladatainak használatát, például a Azure Virtual Desktop, SQL Server vagy AKS.

A Azure Local gépkövetelményekről szóló cikkben leírtak szerint az egyetlen hiperkonvergens (HCI) Azure Local példányban támogatott gépek maximális száma 16. A külső SAN-t használó diszaggregált telepítések legfeljebb 64 csomópontra skálázhatók. A számítási feladatok kapacitástervezésének befejezése után tisztában kell lennie a számítási feladatok infrastruktúrán való futtatásához szükséges gépcsomópontok számával.

Hiperkonvergens (HCI)

A hiperkonvergens fürtök 1–16 csomópontot támogatnak. A csomópontok száma az 5. határozatban határozza meg a tárolási csatlakozási lehetőségeket:

  • Ha a számítási feladatokhoz négy vagy több, S2D-tárolóval rendelkező csomópont szükséges: Nem használhat kapcsoló nélküli konfigurációt a tárolóhálózat forgalmához. A tárolóforgalom kezeléséhez olyan fizikai kapcsolót kell használnia, amely támogatja a távoli közvetlen memória-hozzáférést (RDMA). Az Azure Local Instance hálózati architektúrával kapcsolatos további információkért lásd a hálózati referenciaminták áttekintését.
  • Ha a számítási feladatok négy vagy kevesebb csomópontot igényelnek: Választhat kapcsoló nélküli vagy átváltott konfigurációkat a tárolási kapcsolatokhoz. A kapcsoló nélküli tárolás 1–4 csomópontból álló fürtök esetében támogatott.
  • Ha a kapcsoló nélküli konfiguráción túl később szeretné kibővíteni a skálázást: Fizikai kapcsolót kell használnia a tárolóhálózat forgalmához. A kapcsoló nélküli üzembe helyezések bármely horizontális bővítési művelete a csomópontok közötti hálózati kábelezés kézi konfigurálását igényli, amelyet a Microsoft nem validál aktívan az Azure Local szoftverfejlesztési ciklusának részeként.

Nem összesített (DA)

A diszaggregált fürt a számítási kapacitást és a tárolást egymástól függetlenül skálázza 1–8 racken, rackenként legfeljebb 16 csomóponttal, fürtönként pedig legfeljebb 64 csomóponttal. A tárolókapacitás független a csomópontok számától, mivel a tárolást a külső san biztosítja, nem pedig a helyi meghajtók.

Támogatott üzembehelyezési alakzatok

A csomópontok száma és a tárolási beállítás kombinációja határozza meg, hogy támogatott-e az üzembe helyezési alakzat, és hogy Resource Manager sablonokat igényel-e:

Nodes Nincs kapcsoló a tárolóhoz (S2D kapcsoló nélküli) Hálózati kapcsoló a tároláshoz (S2D kapcsoló) Külső SAN (FC vagy IP-alapú)
1 csomópont ✅ (alapértelmezett) ✅ ✅
2 csomópont ✅(Azure portál- vagy ARM-sablonok) ✅ ✅
3 csomópont ✅ (csak ARM-sablonok) ✅ ✅
4 csomópont ✅ (csak ARM-sablonok) ✅ ✅
5–16 csomópont ❌ ✅ ✅
Több mint 16 csomópont (többállványos) ❌ ❌ ✅

A fürtméret meghatározásának összefoglalt szempontjai:

# Megfontolás A következőkre vonatkozik:
1 Az S2D-tárolót használó 4-nél több csomóponttal rendelkező hiperkonvergens fürtök fizikai kapcsolót igényelnek a tárolóhálózat forgalmához. HCI
2 Ha a fürtöt az orchesztrátorral szeretné kibővíteni, fizikai kapcsolót kell használnia a tárolási hálózati forgalomhoz. HCI
3 A diszaggregált fürtökben a számítási és tárolási kapacitás egymástól függetlenül skálázható 1–8 rack között, rackenként legfeljebb 16 csomóponttal, fürtönként pedig legfeljebb 64 csomóponttal. A tárolókapacitás független a csomópontok számától, mert a külső SAN biztosítja. DA

5. döntés: A tárkapcsolat meghatározása

A fizikai hálózati követelményeknek megfelelően a tárolási csatlakozási lehetőségek a 2. határozatban kiválasztott architektúrától függenek. Ha nem felülbírálja őket Resource Manager sablonokkal, az összes Közvetlen tárolóhelyek (S2D) minta a következő hálózati ATC-tárolási alapértelmezett értékeket használja:

Tárolóhálózat Alapértelmezett VLAN Alapértelmezett alhálózat
Tárolóhálózat 1 711 10.71.1.0/24
2. tárolóhálózat 712 10.71.2.0/24
3. tárolóhálózat (ha van) 713 10.71.3.0/24

Hiperkonvergens (HCI)

A hiperkonvergens telepítések a Közvetlen tárolóhelyeket használják a két tárolókapcsolati típus egyikével:

  • Kapcsolóalapú tároló: A tárolóforgalom kezeléséhez használjon fizikai hálózati switchet. A switched storage 1–16 csomópontot támogat, és támogatja a vertikális felskálázást.
  • Kapcsoló nélküli tárolás: Közvetlenül csatlakoztassa a csomópontokat közöttük crossover hálózati vagy szálkábelekkel a tárolási forgalomhoz. A kapcsoló nélküli tárolás csak 1–4 csomópontból álló fürtök esetén támogatott – ez egy szigorú felső korlát –, és nem támogatja a vertikális felskálázást.

A kapcsoló nélküli és kapcsoló nélküli lehetőségek előnyeit és hátrányait a fent hivatkozott cikkben dokumentáljuk.

A kapcsoló nélküli és a kapcsoló nélküli tárolás között csak akkor dönthet, ha a fürt mérete négy vagy kevesebb csomópont. Minden négynél több csomóponttal rendelkező S2D-fürt automatikusan kerül üzembe helyezésre a tároláshoz hálózati kapcsoló használatával.

Important

Kapcsolós hiperkonvergens üzembe helyezések esetén a tárolóforgalmat ugyanazon a top-of-rack (ToR) kapcsolópáron vezesse, amely a felügyeleti és a számítási forgalmat is továbbítja. A tárolási szándékhoz külön, dedikált kapcsolópár használata nem támogatott. A felügyeleti és számítási hálózattól elkülönített csak tárolókapcsolópárok megosztott fürthelyzethez vezethetnek, mivel a csomópontok elveszíthetik a tárolási (kelet-nyugati) elérési utat, miközben megtartják a felügyeleti útvonalat, vagy fordítva. Az összes szándékdefiníciót rackenként egyetlen MLAG-konfigurált ToR-kapcsolópáron tartsa.

Ha a fürtök négy vagy kevesebb csomópontból állnak, a tárolókapcsolatra vonatkozó döntés befolyásolja, hogy a 7. döntésben milyen számú és típusú hálózati szándékot adhat meg. A kapcsoló nélküli konfigurációk esetében például két hálózati forgalmi szándékot kell meghatároznia. A kelet-nyugati kommunikációhoz használt tárolóforgalom a crossover kábelek használatával nem rendelkezik észak-déli kapcsolattal, és teljesen el van különítve a hálózati infrastruktúra többi részétől. Ez azt jelenti, hogy meg kell határoznia egy második hálózati szándékot a kimenő felügyeleti kapcsolatokhoz és a számítási feladatokhoz.

Bár az egyes hálózati szándékokat csak egy fizikai hálózati adapterporttal lehet definiálni, ez nem biztosít hibatűrést. Ezért mindig azt javasoljuk, hogy minden hálózati szándékhoz használjunk legalább két fizikai hálózati portot. Ha úgy dönt, hogy hálózati kapcsolót használ a tároláshoz, az összes hálózati forgalmat csoportosíthatja, beleértve a tárolást is egyetlen hálózati szándék szerint, amelyet hiperkonvergens vagy teljes mértékben konvergens gazdagéphálózat-konfigurációnak is neveznek.

Tárolási IP-tervezés kapcsoló nélküli fürtökhöz

A kapcsoló nélküli tárolás esetében a táralhálózatok száma a csomópontok számával nő, mivel minden csomópontnak közvetlen kapcsolatra van szüksége minden más csomóponttal. A tárolási alhálózatok száma N × (N − 1), ahol N a csomópontok száma:

Kapcsoló nélküli csomópontok Tárolási alhálózatok Tároló automatikus IP-címe
2 2 Automatikusan támogatott
3 6 A Tároló automatikus IP-címének letiltása és az Resource Manager-sablonban található összes tároló IP-cím definiálása
4 12 A Tároló automatikus IP-címének letiltása és az Resource Manager-sablonban található összes tároló IP-cím definiálása

Az egyéni tároló IP-címeinek definiálásáról további információt az Egyéni IP-címek a tároláshoz című témakörben talál.

Hibrid tárolás (S2D és külső SAN)

Azure Local támogatja, hogy külső SAN-t csatoljon egy hiperkonvergens fürthöz, hogy a SAN-alapú tároló a beépített Közvetlen tárolóhelyek (S2D) mellett működjön. A külső SAN-t mindig az üzembe helyezés utáni (day-2) műveletként csatlakoztatják: először üzembe helyeznek egy standard, S2D-t használó hiperkonvergens fürtöt, majd ezt követően csatlakoztatják a SAN-t. Már a kezdetektől nem telepíthető hibrid konfiguráció, ezért a SAN-infrastruktúrát és az adaptereket előre meg kell tervezni, bár csak azután csatlakoztatja őket, hogy a fürt már működik. Ez lehetővé teszi az S2D- vagy külső SAN-kötetek kiválasztását számítási feladatonként virtuális gépek, AKS-fürtök és Azure Virtual Desktop (AVD) esetében. Több SAN-kötet Cluster Shared Volume-ként (CSV-ként), NTFS-re formázva jelenik meg, és minden CSV egy mappaútvonalként látszik, amelyet a virtuális gépek tárolási útvonalaként rendel hozzá. Általában két integráció érhető el:

  • Fiber Channel (FC) SAN-tárolótömbök: Minden csomópont két, egymástól független Fiber Channel-hálózaton (Fabric A és Fabric B) keresztül csatlakozik a SAN-hoz a redundancia biztosítása érdekében, az egyes gazdagépeken található gazdagépbusz-adapterek (HBA-k) használatával. A SAN-alapú kötetek NTFS CSV-ként vannak felderítve, és csomópontok között vannak megosztva, a számítási és tárolási skálázás pedig egymástól függetlenül történik.
  • IP-alapú (Ethernetes) SAN: Minden csomópont az Ethernet-alapú tárolóhálózaton keresztül csatlakozik a tömbhöz — szabványos iSCSI-iniciátort vagy a gyártó által biztosított tároló kliensprogramot használva —, és a távoli blokk-köteteket a fürtben redundáns hálózati szöveteken keresztüli többutas I/O-val csatolja fel. A kötetek NTFS CSV-ként jelennek meg, és csomópontok között vannak megosztva, a számítási és tárolási skálázás pedig egymástól függetlenül történik. Ezek a megoldások általában dedikált tárolóalhálózatokat, jumbo-kereteket és hálózati adapterek kötését/összevonását használják. Az, hogy ezek a tárolóalhálózatok útválasztással elérhetők-e, az Ön tárolóhálózati architektúrájától függ: egyes telepítésekben a gazdagépek közvetlenül dedikált tárolókapcsolókhoz csatlakoznak elkülönített, nem routolható alhálózatokon, míg más esetekben a tárolóforgalmat az adatközponti hálózaton keresztül vezetik be. A támogatott csomópontok száma, a méretezési korlátok és a jumbo-frame MTU pontos mérete a tároló szállítójától és Azure Local érvényesítésétől függ.

Hálózattervezési szempontból:

  • Az S2D tárolóhálózat változatlan marad az eredeti, kapcsolós vagy kapcsoló nélküli üzembe helyezéshez képest.
  • A SAN-kapcsolódás különálló fabricokat és adaptereket (FC HBA-kat vagy NIC-eket IP-alapú SAN-hoz) használ, és nem a Network ATC kezeli. Tervezzen dedikált portokat a SAN-kapcsolathoz, valamint az IP-alapú blokktároláshoz dedikált tárolóalhálózatokat jumbo frame-ekkel (a tárolóhálózati architektúrától függően útválasztható vagy nem útválasztható módon).
  • A racktudatos fürtök nem támogatottak külső SAN-tárolóval rendelkező hiperkonvergens telepítések esetén.

További információkért lásd: Külső tárolók támogatása az Azure Localhoz.

Nem összesített (DA)

Ha külső SAN-t használ — Fiber Channel- vagy IP-alapú SAN-t (például iSCSI-t vagy PowerFlex SDC-t) —, akkor nem használható a Közvetlen tárolóhelyek, és nincs a Network ATC által kezelt RDMA-tárolási szándék. Mindkét esetben:

  • A felügyeleti és számítási forgalom a hálózati ATC-n keresztül van konfigurálva a Switch Embedded Teaming (SET) virtuális kapcsolóval.
  • A fürthálózatok – a fürt megosztott kötete (CSV) és az SMB többcsatornás élő migrálási forgalom – különálló hálózati portokat használ, amelyeket a Network ATC nem kezel. Dedikált VLAN-okat és alhálózatokat tervezhet ezekhez a hálózatokhoz. Az alapértelmezett fürt VLAN-ja 1711 és 1712.
  • Konfigurálja az Ethernet szolgáltatásminőségét (QoS) a fürthálózatok számára. A 6. döntés a javasolt szolgáltatási (CoS-) prioritási sémát és sávszélesség-kiosztást ismerteti.

A tárolóháló san típusonként különbözik:

  • Fibre Channel (FC): A tároló teljes egészében az FC hálón fut, az Ethernet-hálózattól elkülönítve. Nincs szükség Ethernet-tárolási QoS-re, prioritási folyamatvezérlésre (PFC) vagy veszteségmentes Ethernetre – az összes fürtforgalom TCP az SMB Multichannelen keresztül.
  • IP-alapú SAN: A tároló dedikált Ethernet-adaptereken fut az IP-alapú san eléréséhez. Felváltja a Közvetlen tárolóhelyeket, és megszünteti az RDMA használatát, továbbá mivel az összes forgalom (az IP-alapú SAN-forgalom, a CSV, az élő migráció és a fürtszívverés) TCP felett zajlik, a veszteségmentes Ethernet és a PFC nem szükségesek. Ellenőrizze, hogy a SAN-tömbmodell támogatott-e az üzembe helyezés előtt.

Az iSCSI-telepítések ezt az érvényesített mintát követik, amelyet a 6. döntésnél választ ki:

  • 6 portos dedikált elérési út: A dedikált portok az ISCSI A és a B elérési utat hordozzák, a fürthálózatoktól elkülönítve. Ez a minta egy opcionális dedikált biztonsági mentési hálózatot támogat.

A külső SAN csatlakoztatásával kapcsolatos további információkért, beleértve a Fiber Channel és az iSCSI gazdaoldali és tömboldali konfigurációját, lásd: Külső tárolótömb csatlakoztatása az Azure Localhoz és Külső tárolók támogatása az Azure Localhoz.

iSCSI-gazdagép statikus útvonalai

iSCSI-telepítések esetén csak a felügyeleti interfész rendelkezik alapértelmezett átjáróval. A fürt és az iSCSI-interfészek alapértelmezett átjáró nélkül rendelkeznek IP-címekkel. Az egy vagy több 3. rétegbeli ugrásnyira lévő iSCSI-célok eléréséhez konfiguráljon minden gazdagépen minden egyes iSCSI-cél IP-címéhez egy állandó /32 statikus útvonalat úgy, hogy a következő ugrás az iSCSI VLAN-on lévő leaf switch átjárója (kapcsoló virtuális interfésze) legyen, és az útvonal a tárolóadapterhez legyen kötve. A statikus útvonalak az iSCSI-forgalmat a tárolóadapteren keresztül terelik, és megakadályozzák, hogy az a felügyeleti hálózatra szivárogjon. Többutas I/O (MPIO) konfiguráció esetén minden iSCSI-útvonalnak saját statikus útvonalra van szüksége ugyanazon célokhoz a megfelelő VLAN-ján keresztül. Ha egy tömb számos cél IP-címet tesz elérhetővé ugyanabban az alhálózatban, a cél alhálózatát átirányíthatja a megfelelő útvonalátjárón ahelyett, hogy célonként egy útvonalat ad hozzá. Az operációs rendszer telepítése során konfigurálhatja az iSCSI-kezdeményezőt, a statikus útvonalakat és az MPIO-t.

Feljegyzés

Külső SAN-tároló esetén a Közvetlen tárolóhelyek nincs használatban, így az RDMA-tól függő tárolási szándék beállításai nem érhetők el. Használja a felügyeleti és számítási célokat, valamint a fent leírt önálló fürthálózatokat.

Egyéni IP-címek tároláshoz

Alapértelmezés szerint a Hálózati ATC automatikusan hozzárendeli a tároló ip-címeit és VLAN-jait a következő táblázatból:

Tárolóadapter IP-cím és alhálózat VLAN
pNIC1 10.71.1.x 711
pNIC2 10.71.2.x 712
pNIC3 10.71.3.x 713

Ha azonban az üzembehelyezési követelmények nem felelnek meg az alapértelmezett IP-címeknek és VLAN-oknak, használhatja a saját IP-címeit, alhálózatait és VLAN-jait a tároláshoz. Ez a funkció csak arm-sablonokkal rendelkező fürtök üzembe helyezésekor érhető el, és a sablonban a következő paramétereket kell megadnia:

  • enableStorageAutoIP: Ha ez a paraméter nincs megadva, az értéke true lesz. Ha az üzembe helyezés során engedélyezni szeretné az egyéni tároló IP-címeket, ezt a paramétert falsea következőre kell állítani: . A tároló automatikus IP-címe kétcsomópontos kapcsoló nélküli fürtök esetén támogatott; a 3 csomópontos és a 4 csomópontos kapcsoló nélküli fürtök esetében ezt a paramétert false explicit módon kell beállítania, és meg kell határoznia az összes tárolási IP-címet.
  • storageAdapterIPInfo: Ez a paraméter függőséggel rendelkezik a enableStorageAutoIP paraméterrel, és mindig szükség van rá, ha a tároló automatikus IP-paramétere be van állítva false. Az ARM-sablon storageAdapterIPInfo paraméterében szintén meg kell adnia a ipv4Address és subnetMask paramétereket minden csomóponthoz és hálózati adapterhez, a saját IP-címeivel és alhálózati maszkjával.
  • vlanId: A fenti táblázatban leírtak szerint ez a paraméter a Hálózati ATC alapértelmezett VLAN-jait használja, ha nem kell módosítania őket. Ha azonban ezek az alapértelmezett VLAN-fájlok nem működnek a hálózaton, mindegyik tárolóhálózathoz megadhat saját VLAN-azonosítókat.

A következő ARM-sablon egy tárolási célú hálózati kapcsolóval rendelkező, kétcsomópontos Azure Local-példány példáját tartalmazza, ahol a tárolási IP-címek testre vannak szabva: 2 csomópontos telepítés egyéni tárolási IP-címekkel.

Az alábbiakban összefoglaljuk a tárkapcsolati döntéssel kapcsolatos szempontokat:

# Megfontolás A következőkre vonatkozik:
1 A Azure portálon keresztüli kapcsoló nélküli konfiguráció 1 vagy 2 csomópontfürt esetén támogatott. A 3 és 4 csomópontos tárolókapcsoló nélküli fürtök csak Resource Manager sablonok használatával telepíthetők. HCI
2 A horizontális felskálázási műveletek nem támogatottak a kapcsoló nélküli telepítések esetén. A csomópontok számának bármilyen módosítása az üzembe helyezés után manuális konfigurációt igényel. HCI
3 A tároló hálózati kapcsolója tetszőleges számú csomóponttal használható 1-től 16-osig, és egyetlen szándék képes az összes forgalomtípus hordozására. HCI
4 Hiperkonvergens telepítések esetén a tárolási konfigurációnak ugyanazt a ToR switchpárt kell használnia, mint a felügyeleti és számítási forgalom. Az elkülönített, kizárólag tárolási célú kapcsolópár nem támogatott, és a fürt split-brain állapotát okozhatja. HCI
5 A szétválasztott (DA) egy külső SAN-t – Fiber Channel (FC) vagy IP-alapú SAN-t (például iSCSI vagy PowerFlex SDC) – használ arra, hogy a fürtöt külső tárolóhoz csatlakoztassa. Nincs Közvetlen tárolóhelyek, és a számítási és tárolási skálázás egymástól függetlenül legfeljebb 64 csomópontig terjedhet. DA
6 Az iSCSI-telepítések ezt a mintát használják: egy 6 portos dedikált elérési út (dedikált iSCSI-portok, opcionális biztonsági mentési hálózat). DA
7 Az iSCSI-nek célonkénti /32 állomásonkénti statikus útvonalakat és MPIO-t kell használnia, hogy a tárolási forgalom a tárolóadapteren maradjon. Az iSCSI TCP-n fut, így nincs szükség PFC-re és veszteségmentes Ethernetre. DA

6. döntés: Hálózati adapter portjának és konfigurációjának meghatározása

A hálózati adaptereket az általuk használt hálózati forgalomtípus (felügyelet, számítás és tárolás) minősíti. Az OEM-sel együttműködve állapítsa meg, hogy mely adapterek érhetők el és vannak minősítve a hardver minden szándékához (felügyelet, számítás és tárolás).

Mielőtt megvásárol egy gépet Azure Local, legalább két olyan adapterrel kell rendelkeznie, amely rendelkezik felügyeletre, számításra és tárolásra, mivel a Azure Local mindhárom forgalmi típusra szükség van. A felhőbeli üzembe helyezés a hálózati ATC-vel konfigurálja a hálózati adaptereket a megfelelő forgalomtípusokhoz, ezért fontos a támogatott hálózati adapterek használata.

Miután telepítette az operációs rendszert, és mielőtt konfigurálta volna a hálózatkezelést a csomópontokon, győződjön meg arról, hogy a hálózati adapterek rendelkeznek az OEM vagy a hálózati adapter gyártójának legújabb illesztőprogramjával. Előfordulhat, hogy a hálózati adapterek fontos képességei nem lesznek felszínre az alapértelmezett Microsoft-illesztőprogramok használatakor.

A hálózati ATC által használt alapértelmezett értékeket a cluster hálózati beállításai dokumentálják. Javasoljuk, hogy az alapértelmezett értékeket használja. Ezzel az alábbi beállítások felülírhatók a Azure portálon vagy szükség esetén Resource Manager sablonok használatával:

  • Tárolási VLAN-ok: Állítsa be ezt az értéket a tároláshoz szükséges VLAN-okra.
  • Jumbo-csomagok: Meghatározza a jumbo-csomagok méretét. Az RDMA-tárforgalomhoz 9216 bájtos maximális átviteli egység (MTU) ajánlott. Konfigurálja ugyanazt az MTU-t a fizikai kapcsolókon. Külső SAN (hibrid vagy nem összesített) tárolóhálók esetén a szükséges jumbo-frame MTU a tároló gyártójától függ, és eltérhet az S2D-értéktől – például 9216 bájt RDMA-tárolóhálókhoz, valamint egy szállító által megadott érték (például 9014 bájt) az IP-alapú blokktároló-hálózatok esetében. Használja a tárolórendszer gyártója által megadott MTU-t, és állítsa be ugyanerre az értékre végponttól végpontig a gazdagépeken és a kapcsolókon.
  • Network Direct: Állítsa ezt az értéket false értékre, ha le szeretné tiltani az RDMA-t a hálózati adapterekhez.
  • Közvetlen Hálózati Technológia: Állítsa be ezt az értéket a RoCEv2 vagy iWarp értékre.
  • Traffic Priorities Datacenter Bridging (DCB): Állítsa be az igényeinek megfelelő prioritásokat. Javasoljuk, hogy az alapértelmezett DCB-értékeket használja, mivel ezeket a Microsoft és az ügyfelek érvényesítik.

Hiperkonvergens (HCI)

A hiperkonvergens üzembe helyezések csomópontonként 2, 4, 6 vagy 8 hálózati adapterportot használnak, attól függően, hogy hogyan csoportosítja a forgalmat szándékokba a 7. döntésben. Az egyes portok sebességének és RDMA-képességének meg kell egyeznie az általa hordozott forgalommal:

  • 2 port: Az összes forgalom szándékának egyetlen csoportosítása . A SET az első két fizikai adaptert egy csoportba fogja (például a pNIC01 és a pNIC02 adaptert). Minden forgalomtípus ugyanazokkal a portokkal rendelkezik. Legalább 10 Gb-ot igényel; 25 GbE vagy újabb használata ajánlott.
  • 4 port: Felügyeleti és számítási szándék az 1. és a 2. porton (SET), valamint egy dedikált tárolási szándék a Port3-on és a Port4-en. A tárolási cél nem a SET-et használja, hanem az SMB Multichannelt a hibatűrés és a sávszélesség-összesítés érdekében.
  • 6 port: Különálló kezelési (Port1 és Port2, SET), számítási (Port3 és Port4, SET) és tárolási (Port5 és Port6, SMB Multichannel) célok.
  • 8 port: Adjon hozzá egy második számítási vagy biztonsági mentési szándékot a többi porthoz a további forgalomelválasztás érdekében.

Kapcsolt topológiák esetén a ToR kapcsolóknak meg kell felelniük a fizikai kapcsolókra vonatkozó követelményeknek. A kapcsoló nélküli minták esetében a tárolóadapterek közvetlen csomópont–csomópont hálót alkotnak, így nincs szükség tárolókapcsolókra; minden egyes tárolási alhálózathoz egyedi VLAN szükséges, és az alhálózatok száma az 5. határozatban leírtak szerint növekszik.

Nem összesített (DA)

A szétválasztott telepítések Ethernet-portkiosztása a SAN típusától függ. A kialakítást a hálózati portok száma és az egyes portok szerepköre határozza meg, nem pedig a fizikai adapter formájának tényezője alapján. Minden esetben két hálózati port szolgálja ki a felügyeleti és számítási célú forgalmat (egy, a Network ATC által felügyelt SET-csoportban), és egy külön hálózati portpár szolgálja ki a fürthálózatokat – a fürtszívverést, a Cluster Shared Volume-ot (CSV), valamint az SMB Multichannelen keresztüli Live Migrationt – önálló portokként, amelyeket a Network ATC nem kezel. A portok fizikai adapterek közötti elosztásának lehetősége OEM-választás: egyetlen többportos adapterből (például négyportos OCP-ből), két különálló adapterből (például egy beépített OCP-ből és egy bővítményadapterből) vagy két beépített adapterből is származhatnak. Az alapértelmezett fürt VLAN-ja 1711 és 1712. Minden különálló fürt és tárolóport egyetlen VLAN-t hordoz, így ezt a VLAN-t beállíthatja hozzáférési (natív) VLAN-ként a ToR-porton, és a gazdafelületet felügyelet nélkül hagyhatja – lásd: Fürt és tárolási QoS. Az egyes SAN-típusokhoz tartozó teljes kapcsoló-, kábelezési és portelrendezéshez tekintse meg a nem összesített hálózati referenciamintákat.

Fibre Channel (FC)

Az FC-telepítések csomópontonként 4 vagy 6 portos Ethernet-kiosztást használnak. Minden kiszolgáló kétportos FC gazdabuszadaptereket (HBA-kat) (A port–FC A kapcsoló, B port– FC kapcsoló B) is használ a SAN-kapcsolathoz, az Ethernet hálózati portoktól elkülönítve:

  • 4 port: Felügyelet és számítás az 1. és 2. hálózati porton (SET), valamint a fürthálózatokon a különálló 3. és 4. hálózati porton.
  • 6 port (vendég biztonsági mentés): Megegyezik a 4 portos elrendezéssel, kiegészítve egy Vendég biztonsági mentés compute intenttel az 5. és 6. hálózati porton (SET) a vendégbiztonsági mentési forgalom számára. További információ: 9. határozat.

iSCSI

Az iSCSI-telepítések ezt az érvényesített mintát használják. A tárolóadaptereknek legalább 10 GbE-nak (nagy átviteli sebességű számítási feladatok esetén legalább 25 GbE-nak) kell lenniük:

  • 6 portos dedikált elérési út: Két hálózati port a felügyelethez és a számításhoz (SET), két különálló hálózati port a fürthálózatokhoz (1711-es és 1712-es VLAN-ok), valamint két további különálló hálózati port a dedikált ISCSI-útvonalhoz (VLAN 300) és a B elérési úthoz (VLAN 400). Ez a minta támogatja a 9. határozatban leírt opcionális biztonsági mentési hálózatot.

Klaszter- és tároló QoS

Az összes nem összesített tároló- és fürtforgalom TCP-n fut: SMB Multichannel a fürthálózatokhoz (CSV, Élő migrálás és szívverés) és iSCSI TCP-n keresztül a tároláshoz. A TCP saját újraküldési és torlódásvezérlési mechanizmusaival kezeli a torlódást, és helyreáll a csomagvesztés után, így ehhez a kialakításhoz nincs szükség veszteségmentes Ethernetre vagy hosztoldali forgalomalakításra. Ne konfigurálja a következőket a fürtön és a tárolóportokon:

  • prioritásalapú folyamatvezérlés (PFC) vagy veszteségmentes sorok A PFC veszteségmentességet biztosít az RDMA/RoCE esetében, amelyet a diszaggregált telepítések nem használnak. TCP-alapú hálózatban a PFC növeli a működési kockázatot — a szünetjelzések tovaterjedése, a sor eleji blokkolás és az érintett adatfolyamok révén —, miközben semmilyen előnyt nem nyújt.
  • Gazdagépoldali adatközpont-áthidalás (DCB) vagy továbbfejlesztett átviteli kijelölés (ETS). A gazda ETS-e és a 802.1p szolgáltatási osztálya (CoS) hopról hopra működő, 2. rétegbeli mechanizmusok. Ezek csak a gazdagép-levél kapcsolatra vannak hatással, és a sávszélesség-garanciáik nem terjednek ki az egész hálóra.

Important

Több rackes leaf-spine kiépítés esetén a rackek közötti fürt- és tárolóforgalom a 3. rétegen, a VXLAN EVPN overlay hálózaton keresztül van irányítva. A hoszt által beállított 802.1p CoS csak a 802.1Q VLAN-címkén belül létezik, ezért eldobódik, amikor egy leaf kapcsoló útválasztja és újraenkapszulálja a keretet – a spine kapcsolók a külső csomagfejléc alapján ütemeznek, nem a hoszt CoS-értéke alapján. Ezért a gazdagép ETS-e nem képes megvédeni az iSCSI- vagy a fürtforgalmat a spine-hálózati vagy incast torlódással szemben, konfigurálása pedig hamis biztonságérzetet kelt.

A fürt- és tárolóforgalom kifogástalan állapotban tartása az egész hálóban:

  • Tervezd meg a hálót a kapacitás érdekében. A leaf-spine topológiát alacsony vagy nulla túlterheléssel alakítsa ki, a spine uplinkeket méretezze a tárolóforgalom kiugró terheléseihez, és a tároló- valamint a klaszterforgalmat dedikált portokon tartsa, ahol ezt a portkiosztás lehetővé teszi. A TCP-alapú torlódásszabályozással együtt ez a fő védelmi mechanizmus az állványok közötti forgalom esetén.

Feljegyzés

Egy egyállványos, nem összesített fürtön (2. réteg egy ToR-páron), vagy egy több adattípust szállító konvergens gazdagép-uplinken a gazdagép ETS-je továbbra is ezen a helyi kapcsolaton működik, és képes megtartani a tömeges CSV-t vagy az élő áttelepítést az éhező fürt szívverésétől. Ha dedikált portokat használ a fürt- és tárolóhálózatokhoz – ahogy a többállványos elrendezések javasolják –, ezeken a kapcsolatokon alig van versengő forgalom, így a gazdagépen konfigurált ETS elhagyása elhanyagolható hatással jár. A hoszt ETS mindenütt történő eltávolítása tudatos egyszerűsítés az útválasztott, TCP-alapú hálózati szövet esetében.

A jumbo frame-ek továbbra is hasznosak, és függetlenek a fenti QoS-döntéstől, mert a fürtportokon a CSV és az élő migrálás SMB-n keresztül fut — ezek olyan nagy mennyiségű adatátvitelek, amelyeknél előnyös a kevesebb, de nagyobb csomag használata. Ezeket nem kell manuálisan konfigurálnia: az Azure Local az Azure Portalon vagy az ARM-sablonban megadott jumbo-frame MTU-t az üzembe helyezés során alkalmazza a gazdagépadapterekre, így nincs szükség adapterparancsok futtatására a csomópontokon. A switch fizikai portjain is önnek kell ugyanazt az MTU-t beállítania, mert az Azure Local nem konfigurálja a switcheket – gyakori beállítás, hogy a hoston 9000, a switchen pedig 9216 az MTU.

Mivel nincs hostoldali QoS, a különálló fürt- és tárolóportoknak nem kell megőrizniük az 802.1p prioritást, és mindegyik port csak egyetlen VLAN-t kezel. Ezért beállíthatja ezt a VLAN-t hozzáférési (natív) VLAN-ként a ToR-porton, és a gazdagép interfészét hagyhatja címkézetlenül – a gazdagépeken nincs szükség VLAN-címkézésre:

  • Fürthálózatok: állítsa be a két fürtportot a fürt VLAN-jaira (például 1711 és 1712).
  • iSCSI, 6 portos dedikált elérési út: állítsa be a két dedikált iSCSI-portot a tároló VLAN-jaira (például 300 és 400).

A felügyeleti és számítási portok külön vannak kezelve – a Network ATC által felügyelt SET-csoportban maradnak, és trunk üzemmódban vannak, ha egynél több VLAN-t szállítanak. A további követelményekért kövesse a tároló gyártójának útmutatását.

Fizikai kapcsolókra vonatkozó követelmények

Kapcsolt (hiperkonvergens) és diszaggregált telepítések esetén a fizikai top-of-rack (ToR) kapcsolóknak támogatniuk kell a következő funkciókat a fürtforgalom megbízható továbbításához:

  • Prioritási folyamatvezérlés (PFC) veszteségmentes RDMA-forgalomhoz (IEEE 802.1Qbb).
  • Továbbfejlesztett átviteli kijelölés (ETS) a forgalomosztályok közötti sávszélesség-kiosztáshoz (IEEE 802.1Qaz).
  • Jumbo-keretek legalább 9216 bájtos MTU-val.
  • Explicit Congestion Notification (ECN) RoCEv2-telepítésekhez.
  • Multi-Chassis Link Aggregation (MLAG) redundáns ToR-párokhoz való.

Feljegyzés

A PFC-, ETS- és ECN-képességek a kapcsolóalapú hiperkonvergens (RDMA-)telepítésekre vonatkoznak. A szétválasztott telepítések az összes tárolási és fürtforgalmat TCP-n keresztül továbbítják, ezért nincs szükségük PFC-re, veszteségmentes Ethernetre, illetve gazdaoldali és kapcsolóoldali ETS-re. Támaszkodhat a megfelelő hálókapacitásra és a TCP-torlódások szabályozására. A nem összesített hálónak továbbra is szüksége van jumbo keretekre, MLAG-re vagy virtuális portcsatornára (vPC), valamint MPIO-kompatibilis VLAN-támogatásra az iSCSI statikus útválasztásával.

Az alábbiakban összefoglaljuk a hálózati adapter konfigurációs döntésével kapcsolatos szempontokat:

# Megfontolás A következőkre vonatkozik:
1 A lehető legnagyobb mértékben használja az alapértelmezett hálózati ATC-konfigurációkat. Both
2 A fizikai kapcsolókat a hálózati adapter konfigurációjának megfelelően kell konfigurálni. Lásd az Azure Local fizikai hálózati követelményeit. Both
3 Működjön együtt OEM-partnerével annak megállapításához, hogy az Azure Localban mely hálózati adapterek támogatottak és minősítettek az egyes célokhoz. A támogatott lista korlátozottabb, mint a Windows Server-katalógus. Both
4 Az RDMA- vagy iSCSI-tárolóforgalom támogatásához legalább 10 Gb/s hálózati adapter szükséges. Javasoljuk a legalább 25 GbE-s hálózati kapcsolatot. Both
5 Az alapértelmezett beállítások elfogadásakor a hálózati ATC automatikusan konfigurálja a tárolási hálózati adapter IP-címeit és VLAN-jait (Storage Auto IP- cím). Egyes esetekben a Tároló automatikus IP-címe nem támogatott, és minden tárolóhálózati adapter IP-címét Resource Manager-sablonokkal kell deklarálnia. HCI
6 A nem összesített tároló- és fürtforgalom TCP-n keresztül fut, ezért a prioritási folyamatvezérlés (PFC) és a gazdagépoldali ETS/DCB nem szükséges. A gazdagép ETS-ének csak a gazdagép-levél kapcsolatra van hatással, és nem érvényes az irányított levél-gerinc hálóra; az állványok közötti forgalom védelmére szolgáló mérnökháló-kapacitás. DA
7 Mivel a szétválasztott telepítések nem használják a host QoS-t, minden önálló fürt- és tárolóport egyetlen VLAN-t használ, és a ToR kapcsolón hozzáférési (natív) VLAN-t használhat — például 1711-et és 1712-t a fürthálózatokhoz, illetve 300-at és 400-at a dedikált iSCSI-hez —, így a host interfészeknek nincs szükségük VLAN-címkékre. DA

7. döntés: A hálózati forgalom szándékainak meghatározása

Az Azure Local esetében az összes üzembe helyezéshez a gazdagép hálózati konfigurációja a Network ATC-re támaszkodik. A hálózati szándékok automatikusan konfigurálva lesznek az Azure Local Azure Portalon keresztüli üzembe helyezésekor. A hálózati szándékokkal és azok hibaelhárításával kapcsolatos további információkért tekintse meg a gyakori hálózati ATC-parancsokat.

Ez a szakasz a hálózati forgalom szándékaira vonatkozó tervezési döntés következményeit ismerteti. Az elérhető lehetőségek az architektúrától, a fürt csomópontjainak számától és a használt tárolókapcsolati típustól függenek.

Feljegyzés

A hálózati ATC SET virtuális kapcsolókat hoz létre a felügyelethez és a számítási forgalomhoz. Az S2D-telepítések tárolóforgalma az SMB Multichannelt használja, és nem SET-kapcsolón keresztül halad.

Hiperkonvergens (HCI)

A hiperkonvergens üzemelő példányok esetében négy lehetőség közül választhat a hálózati forgalom egy vagy több szándékba való csoportosításához.

Hálózati szándék: Az összes forgalom csoportosítása

A hálózati ATC egy egyedi szándékot konfigurál, amely magában foglalja a felügyeleti, számítási és tárolási hálózati forgalmat. Az ehhez a szándékhoz rendelt hálózati adapterek az összes hálózati forgalom sávszélességét és átviteli sebességét megosztják.

  • Ehhez a beállításhoz fizikai kapcsolóra van szükség a tárolóforgalomhoz. Ha kapcsoló nélküli architektúrára van szüksége, nem használhatja ezt a szándéktípust. A Azure portál automatikusan kiszűri ezt a beállítást, ha kapcsoló nélküli konfigurációt választ a tárolókapcsolathoz.
  • A magas rendelkezésre állás biztosítása érdekében legalább két hálózati adapterport ajánlott.
  • A tároló RDMA-forgalmának támogatásához legalább 10 Gb/s hálózati adapter szükséges. Javasoljuk a legalább 25 GbE-s hálózati kapcsolatot.

Hálózati szándék: Csoportkezelés és számítási forgalom

A Network ATC két célt konfigurál. Az első szándék magában foglalja a felügyeleti és számítási hálózati forgalmat, a második szándék pedig csak a tárhálózat forgalmát. Minden intencióhoz eltérő hálózati adapter portokkal kell rendelkeznie.

Ezt a lehetőséget a kapcsoló nélküli és a kapcsoló nélküli tárolókapcsolatokhoz is használhatja, ha:

  • A magas rendelkezésre állás biztosítása érdekében minden szándékhoz legalább két hálózati adapterport érhető el.
  • Az RDMA fizikai kapcsolót használ, ha a hálózati kapcsolót a tároláshoz használja.
  • A tároló RDMA-forgalmának támogatásához legalább 10 Gb/s hálózati adapter szükséges.

Hálózati szándék: Számítási és tárolási forgalom csoportosítása

A Network ATC két célt konfigurál. Az első szándék magában foglalja a számítási és tárolási hálózati forgalmat, a második szándék pedig csak a felügyeleti hálózati forgalmat. Minden műveletnek más hálózati adapterportokat kell használnia.

  • Ez a beállítás fizikai kapcsolót igényel a tárolási forgalomhoz, mivel ugyanazok a portok vannak megosztva a számítási forgalommal, amelyek észak-déli kommunikációt igényelnek. Ha kapcsoló nélküli konfigurációra van szüksége, nem használhat ilyen típusú szándékot. A Azure portál automatikusan kiszűri ezt a beállítást, ha kapcsoló nélküli konfigurációt választ a tárolókapcsolathoz.
  • Ehhez a beállításhoz fizikai kapcsolóra van szükség az RDMA-hoz.
  • A magas rendelkezésre állás biztosítása érdekében legalább két hálózati adapterport ajánlott.
  • Az RDMA-forgalom támogatásához legalább 10 Gb/s-os hálózati adapterek ajánlottak a számítási és tárolási szándékhoz.
  • Még akkor is, ha a felügyeleti szándék számítási szándék nélkül van deklarálva, a hálózati ATC létrehoz egy Switch Embedded Teaming (SET) virtuális kapcsolót, amely magas rendelkezésre állást biztosít a felügyeleti hálózat számára.

Hálózati szándék: Egyéni konfiguráció

Legfeljebb három szándékot definiálhat saját konfigurációval, amennyiben a szándékok közül legalább egy magában foglalja a felügyeleti forgalmat. Javasoljuk, hogy akkor használja ezt a lehetőséget, ha második számítási szándékra van szüksége. A második számítási szándékra vonatkozó követelmény forgatókönyvei közé tartozik a távoli tárterület-forgalom, a virtuális gépek biztonsági mentési forgalma vagy a különböző számítási feladatokhoz tartozó különálló számítási szándék.

  • Ha a tárolási szándék eltér a többi szándéktól, használja ezt a beállítást a kapcsoló nélküli és a kapcsoló nélküli tárolókapcsolatokhoz is.
  • Ezt a lehetőséget akkor használja, ha egy másik számítási szándékra van szükség, vagy ha teljesen el szeretné különíteni a különböző típusú forgalmat a különböző hálózati adaptereken.
  • Minden szándékhoz használjon legalább két hálózati adapterportot a magas rendelkezésre állás biztosításához.
  • Az RDMA-forgalom támogatásához legalább 10 Gb/s-os hálózati adapterek ajánlottak a számítási és tárolási szándékhoz.

Nem összesített (DA)

A nem összesített üzemelő példányok esetében a tárolótömb a Fibre Channel vagy az iSCSI protokollon keresztül érhető el, így nincs RDMA tárolási szándék. Használja az alábbiakat:

  • A Network ATC-ben, egy SET virtuális kapcsoló használatával konfigurált felügyeleti és számítási szándék.
  • Fürthálózatok (a fürt állapotjelzése, a CSV és az SMB Multichannelen keresztüli élő migrálás), amelyek a Network ATC-n kívül, különálló hálózati portokon működnek, az 5. döntésben leírtak szerint.
  • iSCSI esetén az iSCSI-útvonalak különálló portok, amelyeket a hálózati ATC nem kezel. A 6 portos elrendezésben vannak fenntartva.
  • Választható vendég biztonsági mentési szándék a 6 portos (FC) vagy a 6 portos dedikált útvonal (iSCSI) elrendezés használatakor, a 9. határozatban leírtak szerint.

Támogatott szándékcsoportok

Az alábbi táblázat összefoglalja, hogy mely szándékcsoportok támogatottak az egyes tárolókapcsolati lehetőségek esetében:

Szándék csoportosítása S2D kapcsoló nélküli S2D kapcsolt Külső SAN (FC vagy IP-alapú)
Az összes forgalom csoportosítása (felügyelet, számítás, tárolás) ❌ ✅ ❌
Csoportkezelés és számítás, külön tároló ✅ ✅ ❌
Számítás és tárolás csoportosítása, külön felügyelet ❌ ✅ ❌
Egyéni konfiguráció (legfeljebb három szándék) ✅ ✅ ❌
Felügyeleti és számítási, valamint a Network ATC által nem felügyelt fürthálózatok ❌ ❌ ✅

Az alábbiakban összefoglaltuk a hálózati forgalom szándékának döntésével kapcsolatos szempontokat:

# Megfontolás A következőkre vonatkozik:
1 A magas rendelkezésre állás biztosításához szándékonként legalább két hálózati adapterportot használjon. Both
2 A kapcsoló nélküli hiperkonvergens fürtök legalább két szándékot igényelnek (felügyelet és számítás, plusz tárolás). HCI
3 A Összes forgalom csoportosítása és a Számítási és tárolási erőforrások csoportosítása beállítás fizikai kapcsolót igényel a tárolási forgalomhoz, és nem érhető el kapcsoló nélküli fürtök esetén. HCI
4 A szétválasztott üzembe helyezések felügyeleti és számítási célokat, valamint a Network ATC-n kívül futó fürthálózatokat használnak. DA
5 iSCSI esetén az iSCSI-útvonalak különálló, dedikált, a Network ATC-n kívüli portok. DA

8. döntés: A felügyeleti IP-címek és az infrastruktúra-hálózat meghatározása

Ebben a döntésben meghatározza az infrastruktúra alhálózati címterét, a címek fürthöz rendelésének módját, valamint azt, hogy van-e VLAN-azonosítóra vonatkozó követelmény a csomópontokhoz. Ez a döntés a hiperkonvergens és a nem összesített architektúrákra is vonatkozik.

Az üzembe helyezés megkezdése előtt az alábbi infrastruktúra-alhálózat-összetevőket kell megtervezni és definiálni, hogy előre jelezhesse az útválasztási, tűzfal- vagy alhálózati követelményeket.

Fenntartott IP-tartományok elkerülése

A Azure Local üzembe helyezésekor a platform két belső Kubernetes-CIDR-t foglal fenn–10.96.0.0/12 a Kubernetes-szolgáltatásokhoz és 10.244.0.0/16 a podok hálózatkezeléséhez. A Azure Resource Bridge (ARB) vezérlősík ezen a belső Kubernetes-platformon fut, és az üzembe helyezett Azure Kubernetes Service (AKS) fürtök ugyanazokat a tartományokat használják. Ha a Azure Local konfigurációja átfedésben van ezekkel a tartományokkal, az üzembe helyezés meghiúsulhat, vagy csatlakozási problémákat tapasztalhat, amelyeket nehéz elhárítani.

Mivel 10.96.0.0/12 a platform belső Kubernetes Service-hálózata, nincs Azure Local infrastruktúra IP-címe, és a fürtnek elérhető alapvető infrastruktúra-szolgáltatások, például a DNS és a proxy sem tartozhatnak bele. A csomópontok és az infrastruktúra virtuális gépei között a címekre 10.96.0.0/12 küldött forgalom belsőleg lesz kezelve, és soha nem éri el a valódi célt. Rendezze el az alábbiakat úgy, hogy mindegyik a(z) 10.96.0.0/12 elemen kívül legyen:

  • A fürtcsomópont IP-címei és a fürt IP-címe.
  • A Azure Resource Bridge virtuális gép és a többi infrastruktúra virtuális gép IP-címe, valamint a felügyeleti IP-készlet, amelyből származnak.
  • Az infrastruktúra által használt DNS-kiszolgálók és proxykiszolgálók.

A 10.244.0.0/16 podtartomány ugyanazzal a korlátozással jár: az ott található infrastruktúra IP-címe, csomópont IP-címe vagy logikai hálózata ütközik a podhálózattal.

Ha az AKS-t Azure Local helyezi üzembe, ugyanezek a fenntartott tartományok két további követelményt is hozzáadnak az AKS-számítási feladatokhoz:

  • Az AKS logikai hálózata nem fedheti át a fenntartott tartományokat. Az a logikai hálózat (LNET), amelybe AKS-fürtöket telepít, nem fedheti át a 10.96.0.0/12-t (Kubernetes-szolgáltatások) vagy a 10.244.0.0/16-et (podok).
  • Az AKS nem érheti el a privát végpontokat belül 10.96.0.0/12. Bármely privát végpont, amelytől az AKS-munkaterhelések függenek – például az Azure Container Registry (ACR), az Azure Key Vault vagy az Azure Storage végpontjai – nem rendelkezhet a(z) 10.96.0.0/12 tartományba eső IP-címmel. Az AKS vezérlősík virtuális gépéről vagy feldolgozó csomópontjáról ez a tartomány a belső Kubernetes Service-hálózat, így a benne lévő címekre érkező forgalom belsőleg lesz kezelve, és soha nem éri el a valódi végpontot. Ha a környezet már elhelyez privát végpontokat vagy más szolgáltatásokat, amelyeket az AKS-nek el kell érnie ebben a térben, helyezze ki őket az AKS üzembe helyezése előtt.

A szolgáltatás és a pod CIDR-tartományai jelenleg nem változtathatók meg, ezért úgy tervezze meg a hálózatot, hogy elkerülje ezeket a tartományokat, és ne arra számítson, hogy később megváltoznak. Az Azure Local infrastruktúrán, az általa elérendő végpontokon és az AKS-en túl ezek a tartományok nem foglalják le és nem korlátozzák az adatközpont címtartományának fennmaradó részét – csak azoknak a szolgáltatásoknak kell ezeket elkerülniük, amelyekhez maga a fürt csatlakozik. Az AKS-címtervezés teljes követelményeiről, beleértve a többállványos telepítéseket is, lásd: IP-címek tervezése az Azure Localon futó AKS-hez.

Fenntartott tartományok kerülendők

Az alábbi IP-tartományokat a Kubernetes-platform (az Arc Resource Bridge és az AKS is használja) belsőleg fenntartja, és nem használható Azure Local infrastruktúra-összetevőhöz:

Fenntartott tartomány Alkalmazási cél
10.96.0.0/12 Kubernetes belső szolgáltatások (klaszter IP-címek)
10.244.0.0/16 Kubernetes podok hálózatkezelése

Mit érdemes ellenőrizni az üzembe helyezés előtt?

Győződjön meg arról, hogy a következő Helyi Azure-infrastrukturális IP-címek egyike sem tartozik a fenti fenntartott tartományokba:

Ennek ellenőrzése Példa egy problémára
A csomópontkezelési IP-címek Csomópont ütközik a 10.244.1.50 podhálózattal
A klaszter IP-címe A klaszter IP-címe 10.96.0.5 nem érhető el a csomópontokról
A Azure Resource Bridge virtuális gép és infrastruktúra IP-készlete Medence kezdete 10.100.0.1 beleesik 10.96.0.0/12
A DNS-kiszolgáló IP-címeit A DNS a 10.96.1.10 címnél ütközést okozna
A proxykiszolgáló IP-címe A proxykiszolgáló a(z) 10.97.10.25-nál/nél ütközne
Az alapértelmezett átjáró Az átjáró összeütközésbe kerülne 10.96.0.1-val
Logikai hálózatok virtuális gépek számára A virtuálisgép-alhálózat 10.244.100.0/24 átfedésben van a pod hálózattal

Használandó biztonságos IP-tartományok

Íme néhány példa a gyakran használt privát IP-tartományokra, amelyek nem ütköznek:

Biztonságos tartomány Jegyzetek
192.168.x.x A leggyakoribb a kis telepítéseknél
172.16.x.x és 172.31.x.x Jó közepes méretű hálózatokhoz
10.0.x.x és 10.95.x.x Biztonságos – a fenntartott 10.96.0.0 határ alatt marad
10.112.x.x és magasabb Biztonságos – a fenntartott 10.111.255.255 határ felett

IP-tervezési hivatkozások

Felügyeleti IP-készlet

Az Azure Local-példány kezdeti üzembe helyezésekor meg kell határoznia az alapértelmezetten üzembe helyezett infrastruktúra-szolgáltatásokhoz tartozó, egymást követő IP-címek IP-tartományát.

Ahhoz, hogy a tartomány elegendő IP-címmel rendelkezzen a jelenlegi és a jövőbeli infrastruktúra-szolgáltatásokhoz, legalább hat egymást követő elérhető IP-címet kell használnia. Ezeket a címeket a fürt IP-címéhez, az Azure Resource Bridge virtuális géphez és annak összetevőihez használják.

Ha várhatóan más szolgáltatásokat is futtat az infrastruktúra-hálózaton, javasoljuk, hogy rendeljen hozzá egy további puffert az infrastruktúra IP-címeinek a készlethez. Ha az eredetileg tervezett készlet mérete kimerül, az infrastruktúra-hálózat üzembe helyezése után további IP-készleteket is hozzáadhat a PowerShell használatával.

Az üzembe helyezés során a környezet ellenőrzője teszteli az ICMP-kapcsolatot a felügyeleti IP-készlet címéről a felügyeleti IP-készlet alapértelmezett átjárója felé. Győződjön meg arról, hogy az alapértelmezett átjáró engedélyezi az ICMP-forgalmat a Azure Local felügyeleti alhálózatról.

A felügyeleti IP-készlettel kapcsolatos összesítési szempontok:

# Megfontolás A következőkre vonatkozik:
1 Az IP-tartománynak egymást követő IP-címeket kell használnia, és az összes IP-címnek elérhetőnek kell lennie ezen a tartományon belül. Ez az IP-tartomány az üzembe helyezés után nem módosítható. Both
2 Az IP-címek tartományának nem szabad tartalmaznia a fürtcsomópont-felügyeleti IP-címeket, de ugyanazon az alhálózaton kell lennie, mint a csomópontok. Both
3 A felügyeleti IP-készlethez definiált alapértelmezett átjárónak kimenő kapcsolatot kell biztosítania az internethez. Both
4 A DNS-kiszolgálóknak gondoskodniuk kell a névfeloldásról az Active Directoryval és az internettel. Both
5 A felügyeleti IP-címekhez kimenő internet-hozzáférés szükséges. Both
6 A környezetellenőrző ellenőrzi, hogy az ICMP-forgalom az alapértelmezett átjárón válaszol-e az Azure helyi kezelési IP-tartományából. Both

Felügyeleti VLAN-azonosító

Javasoljuk, hogy az Azure Local-példány felügyeleti alhálózata használja az alapértelmezett VLAN-t, amely a legtöbb esetben 0 VLAN-azonosítóként van deklarálva. Ha azonban a hálózati követelményeknek egy adott felügyeleti VLAN-t kell használniuk az infrastruktúra-hálózathoz, azokat a felügyeleti forgalomhoz használni kívánt fizikai hálózati adaptereken kell konfigurálni.

Ha két fizikai hálózati adaptert szeretne használni a felügyelethez, mindkét adapteren be kell állítania a VLAN-t. Ezt a gépek rendszerindítási konfigurációjának részeként kell elvégezni, és mielőtt regisztrálnák őket az Azure Arcra, annak érdekében, hogy sikeresen regisztrálhassa a csomópontokat ezzel a VLAN-nal.

A VLAN-azonosító fizikai hálózati adaptereken való beállításához használja a következő PowerShell-parancsot. Ez a példa a 44-es VLAN-azonosítót állítja be a fizikai hálózati adapteren NIC1:

Set-NetAdapter -Name "NIC1" -VlanID 44

Miután beállította a VLAN-azonosítót, és a csomópontok IP-címei konfigurálva lettek a fizikai hálózati adaptereken, a vezénylő beolvassa ezt a VLAN-azonosítót a felügyelethez használt fizikai hálózati adapterből, és tárolja azt, így használható az Azure Resource Bridge virtuális géphez vagy az üzembe helyezés során szükséges egyéb infrastruktúra-virtuális gépekhez. A felügyeleti VLAN-azonosítót nem lehet beállítani a felhőalapú üzembe helyezés során az Azure Portalon keresztül, mivel ez annak a kockázatával jár, hogy megszakad a kapcsolat a csomópontok és az Azure között, ha a fizikai kapcsoló VLAN-jai nincsenek megfelelően útvonalazva.

Gondosan tervezze meg a felügyeleti VLAN-azonosítót, mert az üzembe helyezés után nem módosítható. A felügyeleti VLAN-azonosítót a Azure Resource Bridge virtuális gép és a többi infrastruktúra virtuális gép is örökli, így azokra is vonatkozik. Az infrastruktúra-hálózat VLAN-azonosítójának az üzembe helyezés utáni módosítása nem támogatott, és megszakítaná a csomópontok, az infrastruktúra-szolgáltatások és a Azure közötti kapcsolatot.

Kezelési VLAN-azonosító virtuális kapcsolóval

Bizonyos esetekben az üzembe helyezés megkezdése előtt létre kell hozni egy virtuális kapcsolót.

Feljegyzés

Mielőtt létrehoz egy virtuális kapcsolót, engedélyezze a Hyper-V szerepkört. További információ: Szükséges Windows-szerepkör telepítése.

Ha virtuális kapcsolókonfigurációra van szükség, és egy adott VLAN-azonosítót kell használnia, kövesse az alábbi lépéseket.

  1. Hozza létre a virtuális kapcsolót az ajánlott elnevezési konvencióval.

    Az Azure helyi üzembe helyezései a hálózati ATC-n alapulnak a virtuális kapcsolók és a virtuális hálózati adapterek felügyeleti, számítási és tárolási szándékokhoz való létrehozásához és konfigurálásához. Alapértelmezés szerint amikor a Network ATC létrehozza a virtuális kapcsolót a szándékokhoz, egy adott nevet használ a virtuális kapcsolóhoz.

    Javasoljuk, hogy a virtuális kapcsolót ugyanazzal az elnevezési konvencióval nevezzük el. A virtuális kapcsolók ConvergedSwitch($IntentName)ajánlott neve az, ahol $IntentName meg kell egyeznie a portálon az üzembe helyezés során beírt szándék nevével. Ennek a sztringnek meg kell egyeznie a felügyelethez használt virtuális hálózati adapter nevével is, a következő lépésben leírtak szerint.

    Az alábbi példa bemutatja, hogyan hozhatja létre a virtuális kapcsolót a PowerShell használatával a javasolt elnevezési konvencióval $IntentName. A hálózati adapterek neveinek listája a felügyeleti és számítási hálózati forgalomhoz használni kívánt fizikai hálózati adapterek listája:

    $IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

    Feljegyzés

    Az Azure Local-példány üzembe helyezése után a felügyeleti szándék vagy a virtuális kapcsoló nevének módosítása nem támogatott. Ugyanazt a szándéknevet és virtuális kapcsolónevet kell használnia, ha frissítenie vagy újra létre kell hoznia a szándékot az üzembe helyezés után.

  2. Konfigurálja a felügyeleti virtuális hálózati adaptert a szükséges hálózati ATC-elnevezési konvencióval az összes csomóponton.

    A virtuális kapcsoló és a társított felügyeleti virtuális hálózati adapter létrehozása után győződjön meg arról, hogy a hálózati adapter neve megfelel a hálózati ATC elnevezési szabványainak.

    A felügyeleti forgalomhoz használt virtuális hálózati adapter nevének a következő konvencióknak kell lennie:

    • A hálózati adapternek és a virtuális hálózati adapternek a nevét kell használnia vManagement($intentname).
    • Ez a név kis- és nagybetűérzékeny.
    • $Intentname lehet bármilyen sztring, de a virtuális kapcsolóhoz használt névnek kell lennie. A szándéknév meghatározásakor győződjön meg arról, hogy ugyanazt a sztringet használja a Mgmt Azure portálon.

    A felügyeleti virtuális hálózati adapter nevének frissítéséhez használja a következő parancsokat:

    $IntentName = "MgmtCompute"

# Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

# Rename NetAdapter because during creation, Hyper-V adds the string "vEthernet" to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

    Feljegyzés

    Az üzembe helyezés ellenőrzése során minden csomóponton található virtuális kapcsolónak rendelkeznie kell a megfelelő virtuális hálózati adapterrel. Ha vannak virtuális kapcsolók, de nincsenek egyező virtuális hálózati adapterek, a művelet a következő hibával meghiúsul:

    "Nem sikerült végrehajtani a műveletet. 200: Vannak virtuális kapcsolók a csomópontokon, de nincsenek virtuális hálózati adapterek, ez a forgatókönyv nem támogatott.

    Győződjön meg arról, hogy az adapterek neve megegyezik a Get-NetAdapter és Get-VMNetworkAdapter -ManagementOS kimenetek között. Ha nem egyeznek, nevezze át a hálózati adaptereket az üzembe helyezés újrapróbálkozása előtt.

  3. Konfigurálja a VLAN-azonosítót a felügyeleti virtuális hálózati adapteren az összes csomóponton.

    A virtuális kapcsoló és a felügyeleti virtuális hálózati adapter létrehozása után megadhatja az adapterhez szükséges VLAN-azonosítót. Bár a VLAN-azonosító virtuális hálózati adapterhez való hozzárendelésének különböző lehetőségei vannak, az egyetlen támogatott lehetőség a Set-VMNetworkAdapterIsolation parancs használata.

    A szükséges VLAN-azonosító konfigurálása után hozzárendelheti az IP-címet és az átjárókat a felügyeleti virtuális hálózati adapterhez annak ellenőrzéséhez, hogy más csomópontokkal, DNS-sel, Active Directoryval és internettel van-e kapcsolata.

    Az alábbi példa bemutatja, hogyan konfigurálhatja a felügyeleti virtuális hálózati adaptert úgy, hogy az alapértelmezett helyett VLAN-azonosítót 8 használjon:

    Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

  4. Hivatkozzon a fizikai hálózati adapterekre a felügyeleti szándékhoz az üzembe helyezés során.

    Bár az újonnan létrehozott virtuális hálózati adapter elérhetőként jelenik meg a Azure portálon keresztül történő üzembe helyezéskor, fontos megjegyezni, hogy a hálózati konfiguráció a hálózati ATC-n alapul. Ez azt jelenti, hogy a felügyelet vagy a felügyeleti és számítási szándék konfigurálásakor továbbra is ki kell választania az adott szándékhoz használt fizikai hálózati adaptereket.

    Feljegyzés

    Ne válassza ki a hálózati szándékhoz tartozó virtuális hálózati adaptert.

    Ugyanez a logika vonatkozik az Azure Resource Manager-sablonokra is. Meg kell adnia a hálózati szándékokhoz használni kívánt fizikai hálózati adaptereket, és soha nem a virtuális hálózati adaptereket.

A VLAN-azonosító összesített szempontjai a következők:

# Megfontolás A következőkre vonatkozik:
1 A VLAN-azonosítót a fizikai hálózati adapteren kell megadni a felügyelethez, mielőtt regisztrálja a gépeket az Azure Arcban. Both
2 Ha virtuális kapcsolóra van szükség a gépek Azure Arcra való regisztrálása előtt, kövesse az adott lépéseket. Both
3 A felügyeleti VLAN-azonosító a gazdagép konfigurációjából az infrastruktúra virtuális gépeibe kerül át az üzembe helyezés során. Both
4 Nincs VLAN-azonosító bemeneti paraméter az Azure Portal üzembe helyezéséhez vagy a Resource Manager-sablon üzembe helyezéséhez. Both
5 A felügyelethez használni kívánt összes adapternek ugyanazzal a VLAN-azonosítóval kell rendelkeznie. Both
6 A felügyeleti (infrastruktúra-) VLAN-azonosító az üzembe helyezés után nem módosítható. Az Azure Resource Bridge virtuális gép és a többi infrastruktúra virtuális gépe is ezt örökli, ezért ezt előre meg kell terveznie, mielőtt regisztrálja a gépeket az Azure Arcba. Both

Csomópont- és fürt IP-kiosztása

Egy Azure Local példány esetében két lehetőség közül választhat, hogy IP-címeket rendeljen a gép csomópontjaihoz és a fürt IP-címéhez:

  • A statikus és a dinamikus gazdakonfigurációs protokoll (DHCP) protokoll is támogatott.
  • A megfelelő csomópont IP-hozzárendelése kulcsfontosságú a fürt életciklusának kezeléséhez. A csomópontok Azure Arcban való regisztrálása előtt döntsön a statikus és a DHCP-beállítások között.
  • Az infrastruktúra virtuális gépei és szolgáltatásai, például az Arc Resource Bridge és a hálózati vezérlő folyamatosan statikus IP-címeket használnak a felügyeleti IP-készletből. Az azt jelenti, hogy még akkor is, ha úgy dönt, hogy a DHCP-t használja az IP-címek csomópontokhoz és a fürt IP-jéhez történő hozzárendeléséhez, továbbra is szükség van a felügyeleti IP-készletre.

Az alábbi szakaszok az egyes lehetőségek következményeit ismertetik.

Statikus IP-hozzárendelés

Ha statikus IP-címek használatosak a csomópontok számára, a felügyeleti IP-készletből automatikusan kiválasztódik egy elérhető IP, amely az üzembe helyezés során hozzárendelésre kerül a fürt IP-címeihez.

Fontos, hogy olyan csomópontokhoz használjon felügyeleti IP-címeket, amelyek nem részei a felügyeleti IP-készlethez definiált IP-tartománynak. A gépcsomópont IP-címeinek ugyanazon az alhálózaton kell lenniük, mint a megadott IP-címtartomány.

Javasoljuk, hogy csak egy felügyeleti IP-címet rendeljen hozzá az alapértelmezett átjáróhoz és a konfigurált DNS-kiszolgálókhoz a csomópont összes fizikai hálózati adapteréhez. Ez biztosítja, hogy az IP-cím ne változzon a felügyeleti hálózati szándék létrehozása után. Ez biztosítja azt is, hogy a csomópontok megtartsák kimenő kapcsolatukat az üzembe helyezési folyamat során, beleértve az Azure Arc-regisztráció során is.

Az útválasztási problémák elkerülése és a kimenő kapcsolathoz és arcregisztrációhoz használt IP-cím azonosítása érdekében a Azure portál ellenőrzi, hogy több alapértelmezett átjáró van-e konfigurálva.

Ha az operációs rendszer konfigurációja során virtuális kapcsolót és felügyeleti virtuális hálózati adaptert hoztak létre, a csomópont felügyeleti IP-címét hozzá kell rendelni a virtuális hálózati adapterhez.

DHCP IP-hozzárendelés

Ha a csomópontok IP-címei DHCP-kiszolgálóról vannak beolvasva, a fürt IP-címéhez dinamikus IP-címet is használ a rendszer. Az infrastruktúra virtuális gépei és szolgáltatásai továbbra is statikus IP-címeket igényelnek, ami azt jelenti, hogy a felügyeleti IP-címtartományt ki kell zárni a csomópontokhoz és a fürt IP-címéhez használt DHCP-hatókörből.

Ha például a felügyeleti IP-tartomány 192.168.1.20 és 192.168.1.30 között van definiálva az infrastruktúra statikus IP-címei esetében, a 192.168.1.0/24 alhálózathoz definiált DHCP-hatókörnek a felügyeleti IP-készlettel egyenértékű kizárással kell rendelkeznie az infrastruktúra-szolgáltatásokkal való IP-ütközések elkerülése érdekében. Azt is javasoljuk, hogy DHCP-foglalásokat használjon csomóponti IP-címekhez.

A felügyeleti IP-cím felügyeleti szándék létrehozása utáni meghatározásának folyamata magában foglalja a hálózati szándékhoz kiválasztott első fizikai hálózati adapter MAC-címének használatát. Ezt a MAC-címet ezután hozzárendeli a felügyeleti célokra létrehozott virtuális hálózati adapterhez. Ez azt jelenti, hogy az első fizikai hálózati adapter által a DHCP-kiszolgálóról beszerzett IP-cím ugyanaz az IP-cím, amelyet a virtuális hálózati adapter a felügyeleti IP-címmel használ. Ezért fontos, hogy DHCP-foglalást hozzon létre a csomópont IP-címéhez.

A felhőbeli üzembe helyezés során használt hálózati érvényesítési logika meghiúsul, ha több fizikai hálózati adaptert észlel, amelyek konfigurációjában alapértelmezett átjáró található. Ha DHCP-t kell használnia a gazdagép IP-hozzárendeléseihez, előzetesen létre kell hoznia a SET (switch embedded teaming) virtuális kapcsolót és a felügyeleti virtuális hálózati adaptert a fent leírtak szerint, így csak a felügyeleti virtuális hálózati adapter szerez be IP-címet a DHCP-kiszolgálótól.

Az IP-címek összesített szempontjai a következők:

# Megfontolás A következőkre vonatkozik:
1 A csomópont IP-címeinek ugyanabban az alhálózatban kell lenniük, mint a meghatározott felügyeleti IP-készlet tartományának, függetlenül attól, hogy statikus vagy dinamikus címek-e. Both
2 A felügyeleti IP-készlet nem tartalmazhat csomópont IP-címeket. DHCP-kizárások használata dinamikus IP-hozzárendelés használatakor. Both
3 A csomópontokhoz a lehető legnagyobb mértékben használjon DHCP-foglalásokat. Both
4 A DHCP-címek csak a node IP-címek és a cluster IP-cím esetében támogatottak. Az infrastruktúra-szolgáltatások statikus IP-címeket használnak a felügyeleti készletből. Both
5 Az első fizikai hálózati adapter MAC-címe a felügyeleti virtuális hálózati adapterhez lesz rendelve a felügyeleti hálózati szándék létrehozása után. Both

A DNS-kiszolgáló szempontjai

Az Active Directoryn alapuló Helyi Azure-üzemelő példányokhoz olyan DNS-kiszolgálóra van szükség, amely képes feloldani a helyszíni tartományt és az internetes nyilvános végpontokat. Az üzembe helyezés részeként meg kell határoznia ugyanazokat a DNS-kiszolgálókat a csomópontokon konfigurált infrastruktúra IP-címtartományához. A Azure Erőforrás-híd vezérlősík virtuális gépe és az AKS vezérlősíkja ugyanazokat a DNS-kiszolgálókat használja a névfeloldáshoz. Az üzembe helyezés befejezése után nem támogatott a DNS-kiszolgáló IP-címeinek módosítása, és nem lehet frissíteni a címeket a Azure Local platform veremén.

Az Azure Localhoz használt DNS-kiszolgálóknak az üzembe helyezés előtt külsőnek és működőképesnek kell lenniük. Nem támogatott az összes konfigurált DNS-kiszolgáló virtuális gépként való futtatása ugyanazon a Azure Local példányon, amely tőlük függ. Mivel a fürtcsomópontoknak, Azure Erőforrás-hídnak és AKS-nek névfeloldásra van szükségük a rendszerindítás során, és mielőtt a számítási feladat virtuális gépei futnak, a konfigurált DNS-kiszolgálók közül legalább egynek a Azure Local-példányon kívül kell futnia. Az a fürt, amely kizárólag a saját magán üzemeltetett DNS-virtuális gépekre támaszkodik, nem képes a névfeloldásra teljes leállítás, újraindítás vagy helyreállítás közben, amikor ezek a virtuális gépek még nem érhetők el. Ha a dns-t virtuális gépként futtatja a fürtben a helyi megoldás érdekében, tartsa meg legalább egy független külső DNS-kiszolgálót a konfigurált listában.

A DNS-kiszolgálói címekre vonatkozó összesítési szempontok:

# Megfontolás A következőkre vonatkozik:
1 A fürt összes csomópontjának DNS-kiszolgálóinak azonosnak kell lenniük. Both
2 Az infrastruktúra IP-címtartományának DNS-kiszolgálóinak azonosnak kell lenniük a csomópontokhoz. Both
3 A Azure Resource Bridge virtuális gép vezérlősíkja és az AKS vezérlősík az infrastruktúra IP-címtartományán konfigurált DNS-kiszolgálókat használja. Both
4 A DNS-kiszolgálók az üzembe helyezés után nem módosíthatók. Az Azure Local üzembe helyezése előtt mindenképpen tervezze meg a DNS-stratégiát. Both
5 Ha több DNS-kiszolgálóból álló tömböt határoz meg egy ARM-sablonban az infrastruktúra-hálózathoz, győződjön meg arról, hogy minden érték "" idézőjeleken belül van, és vesszővel van elválasztva, ahogyan az alábbi példában is látható. Both
6 Nem támogatott az összes konfigurált DNS-kiszolgáló virtuális gépként való futtatása ugyanazon a Azure Local-példányon. Legalább egy beállított DNS-kiszolgálónak a fürtön kívül kell futnia, hogy a névfeloldás működjön rendszerindítás, leállítás, újraindítás és helyreállítás közben, amikor a fürt által hosztolt virtuális gépek nem érhetők el. Both
7 Minden konfigurált DNS-kiszolgálónak fel kell oldania az infrastruktúrához szükséges helyszíni tartományokat. A nyilvános DNS-kiszolgálók, például a 8.8.8.8 nem támogatottak. Both
8 Az összes konfigurált DNS-kiszolgáló nem fedheti át a fenntartott ARB-alhálózat tartományait (10.96.0.0/12 és 10.244.0.0/16). Both 
"dnsServers": [
    "10.250.16.124",
    "10.250.17.232",
    "10.250.18.107"
]

9. döntés: Biztonsági mentési hálózat meghatározása

Döntse el, hogy az üzembe helyezéshez dedikált biztonsági mentési hálózat szükséges-e a vendég (VM) biztonsági mentési forgalmához. Ez a döntés a hiperkonvergens és a nem összesített architektúrákra is vonatkozik.

  • Nincs külön biztonsági mentési hálózat: A vendégek biztonsági mentési forgalma a meglévő számítási célú hálózatot használja. Ez elegendő kisebb telepítésekhez, illetve olyan esetekben, amikor a biztonsági mentési forgalom volumene alacsony.
  • Biztonsági mentési hálózat engedélyezése: Csomópontonként két további hálózati adapterporttal rendelkező dedikált biztonsági mentési hálózat hozzáadása. A dedikált biztonsági mentési hálózat elkülöníti a biztonsági mentési forgalmat az éles számítási és tárolási forgalomtól, ami védi a számítási feladatok teljesítményét a biztonsági mentési időszakok során.

Hiperkonvergens (HCI)

Hiperkonvergens telepítésekhez adjon hozzá egy dedikált biztonsági mentési hálózatot második számítási célként a 7. döntésben ismertetett Egyéni konfiguráció szándékmodell használatával. Rendeljen hozzá két további hálózati adapterportot a biztonsági mentési célhoz a magas rendelkezésre állás biztosítása érdekében.

Nem összesített (DA)

A biztonsági mentési hálózat támogatása a 6. határozatban kiválasztott SAN-típustól és adapterelrendezéstől függ:

  • Szálcsatorna: Használja a 6 portos elrendezést, amely hozzáad egy vendég biztonsági mentési számítási szándékot az 5. és a 6. hálózati porton (SET) a felügyeleti és számítási szándékon és a fürthálózatokon kívül.
  • iSCSI 6-portos (dedikált elérési út):: Támogatja az opcionális biztonsági mentési hálózatot. Ha engedélyezi a biztonsági mentést, a felügyeleti és számítási portok (az 1-es és 2-es hálózati port) egy NetworkATC által felügyelt SET-kapcsolóba vannak integrálva, amely a felügyeleti gazdagép vNIC-jét hosztolja, és trönkként kezeli a bérlői biztonsági mentési VLAN-t. A dedikált klaszter- és iSCSI-portok (a 3-as, 4-es, 5-ös és 6-os hálózati port) nem érintettek. Az ügyfél manuálisan hozza létre a Guest Backup vNIC-et a gazdagépen, a Network ATC által felügyelt virtuális kapcsolón.

A Fibre Channel biztonsági mentési és biztonsági mentés nélküli referenciamintáiért lásd: Fibre Channel disaggregated pattern with backup network and Fibre Channel disaggregated pattern without backup network.

Az alábbiakban összefoglaltuk a biztonsági mentési hálózati döntéssel kapcsolatos szempontokat:

# Megfontolás A következőkre vonatkozik:
1 Hiperkonvergens telepítések esetén adja hozzá a mentési hálózatot második számítási szándékként az egyéni konfigurációs szándékmodell használatával, vagy hozzon létre manuálisan egy további vNIC-et a Management & Compute virtuális kapcsolón. HCI
2 Diszaggregált telepítések esetén egy vendég biztonsági mentési hálózat hozzáadásához használja a 6 portos (Fiber Channel) vagy a 6 portos dedikált útvonalas (iSCSI) elrendezést. DA

10. döntés: Kimenő kapcsolat meghatározása

Tervezze meg, hogy az Azure Local csomópontjai és infrastruktúra-szolgáltatásai hogyan érik el az Azure-t a regisztrációhoz, a számlázáshoz és az életciklus-kezeléshez. Ez a döntés mindkét architektúrára vonatkozik, és az 1. határozatban kiválasztott kapcsolati módra épül. Azure Local öt kimenő kapcsolati topológiát támogat: négy nyilvános elérési utat és egy teljesen privát útvonalat.

# Topology Vállalati proxy Arc-átjáró Összefoglalás
1 Közvetlen kimenő Nincs konfigurálva Nincs konfigurálva A csomópontok közvetlenül az interneten keresztül érik el Azure. A peremhálózati tűzfalon több mint 100 FQDN szükséges. Legjobb tesztkörnyezetekhez vagy kis elszigetelt környezetekhez.
2 Vállalati proxy Konfigurálva Nincs konfigurálva Az összes gazdagép HTTP/HTTPS-jének átirányítása a vállalati proxyn keresztül történik. Ehhez továbbra is 100-nál több FQDN engedélyezése és az SSL-vizsgálat letiltása szükséges az Azure Local-végpontokhoz.
3 Arc-átjáró Nincs konfigurálva Konfigurálva Az Arc-átjáróalagútjai támogatták az Azure felé irányuló HTTPS-forgalmat, így a tűzfal engedélyezési listáján kevesebb mint 30 végpont szerepelt.
4 Vállalati proxy és Arc-átjáró Konfigurálva Konfigurálva Új éles telepítésekhez ajánlott. Központosított proxyházirend és minimális engedélyezési lista.
5 Privát elérési út Beállítva (Azure Firewall explicit proxy) Konfigurálva A csomópontok Azure ExpressRoute vagy helyek közötti VPN-en keresztül csatlakoznak Azure. A proxy minden esetben Azure Firewall Explicit Proxy, és az Arc gateway szükséges.

Légréses környezetek esetén használja az Azure Local leválasztott működési módját, amely a nyilvános Azure-végpontok helyett egy helyi Autonomous Cloud-végpontot biztosít. További információ: 1. határozat.

Important

A Azure Local infrastruktúra-regisztráció teljes magánúton (Azure ExpressRoute vagy helyek közötti VPN-en) történő üzembe helyezése jelenleg nem támogatott. Használjon nyilvános elérésiút-topológiát az üzembe helyezéshez. Továbbra is használhat privát kapcsolatot számítási feladatokhoz és privát végpontokhoz.

Azure Arc átjáró

Az Azure Arc átjáró 100-nál többről 30-ra csökkenti a Azure Local üzembe helyezéséhez és működtetéséhez szükséges nyilvános végpontok számát. Az Arc-gateway-kompatibilis üzembe helyezés négy összetevőre támaszkodik:

  • Arc-ügynök: Minden csomóponton fut, és csatlakoztatja a Azure Arc vezérlősíkhoz.
  • Arc-proxy: Az Arc-ügynökség részét képező és minden csomóponton futó helyi továbbítási proxyszolgáltatás. Ha az Arc-átjáró engedélyezve van Azure Local, az Arc-proxy átirányítja a támogatott HTTPS-forgalmat az Arc-átjáró alagútján keresztül. A csomópontok helyileg, a localhost:40343 címen érik el a saját Arc-proxyjukat, míg az Azure Resource Bridge virtuális gépe, valamint az AKS vezérlősík és a munkavégző virtuális gépek a fürt IP-címén keresztül, a 40343-as porton érik el azt.
  • Cluster IP: az Azure Resource Bridge és az AKS által használt egyetlen továbbító. A magas rendelkezésre állás érdekében a csomópontok között lebeg, így az átirányított Azure Resource Bridge virtuális gép és az AKS virtuális gép HTTPS-forgalma mindig az Arc-proxyn halad át azon a csomóponton, amely az adott pillanatban a fürt IP-címét birtokolja. A forgalom hibaelhárításakor elemezze az Arc-proxynaplókat azon a csomóponton, amely jelenleg a fürt IP-címét birtokolja, ne a többi csomóponton.
  • Arc Gateway-erőforrás: az Azure által felügyelt belépési pont, amely a következő címen érhető el: <gatewayId>.gw.arc.azure.com.

Ha az Arc-átjáró engedélyezve van, minden összetevő egy adott proxyn keresztül irányítja át a kimenő forgalmat. A csomópont operációs rendszerének HTTPS-forgalma a csomópont helyi Arc-proxyját (http://localhost:40343) használja, míg az Azure Resource Bridge virtuális gépe, valamint az AKS vezérlősíkja és munkavégző virtuális gépei a fürt IP-címét használják a 40343-as porton. Az Arc-kompatibilis Azure Local virtuális gépek saját dedikált Arc-proxyt használnak. Az Arc-proxy minden esetben csak a támogatott Microsoft felügyelt HTTPS-végpontokat továbbítja az Arc-átjáróalagúton keresztül.

Az Arc-átjáró által nem engedélyezett végpontokra irányuló HTTPS-forgalom – beleértve a külső és OEM-szolgáltatásokat, például a hardverszállítói frissítési szolgáltatásokat vagy a csomópontokra telepített egyéb ügynököket – átirányítja a vállalati proxyra vagy tűzfalra. Ezeket a végpontokat kifejezetten a követelményeknek megfelelően kell engedélyeznie. A HTTP-forgalom soha nem bújtatható, és mindig a vállalati proxyra vagy tűzfalra kerül.

Az Arc-átjáró működéséről és az átjáróerőforrás létrehozásáról további információt a Azure Local Azure Arc átjáróról szóló cikkben talál. Ha a gépeket az átjárón keresztül szeretné regisztrálni, olvassa el Azure Local gépek regisztrálása Azure Arc az Arc-átjáróval című témakört. Az egyes kimenő forgalom (csomópont operációs rendszere, Azure Erőforráshíd, AKS és Azure Local virtuális gépek) diagramokkal való részletes lebontásához tekintse meg az Arc Gateway kimenő kapcsolatának részletes áttekintését.

A csomópontok regisztrálása előtt végezze el ezeket az előfeltételeket:

  • Hozza létre az Arc-átjáró erőforrását abban az előfizetésben, amelyben üzembe szeretné helyezni Azure Local.
  • Nyissa meg a tűzfalat az Arc-átjáró végpontjaihoz, és tiltsa le rajtuk az SSL-ellenőrzést.
  • Vállalati proxy használata esetén az Arc-regisztráció előtt adja hozzá a szükséges alhálózatokat, csomópontneveket, fürtnevet és bármely privát végpont teljes tartománynevét a proxy megkerülő listájához.

Az Arc-átjáró használata esetén is körülbelül 23 FQDN marad a peremhálózati tűzfal vagy a proxy engedélyezési listáján, beleértve a következőket:

  • Két bootstrap- és hat Arc-regisztrációs teljes tartománynév.
  • Az Arc-átjáró végpontja (<gatewayId>.gw.arc.azure.com).
  • A visszavont tanúsítványok listája (CRL) végpontjai csak HTTP-n keresztül, mivel az Arc-átjáró csak HTTPS-t kezel.
  • az Azure Key Vaultot (vault.azure.net) és a tanúsítóként szolgáló tárfiókot (blob.core.windows.net) a telepítéshez.

A teljes, aktuális végpontlistát a Tűzfal követelményei című témakörben találja.

Feljegyzés

Az AKS üzembe helyezésekor az AKS-alhálózatnak látnia kell az infrastruktúra alhálózatát a 22-es, 6443-as, 40343-as, 55000-es és 65000-es TCP-porton.

Az Arc-átjáróval kapcsolatos összesítési szempontok:

# Megfontolás A következőkre vonatkozik:
1 A proxy megkerülő listájának megtervezése az üzembe helyezés előtt. Tartalmazza a támogatott privát kapcsolatvégpontokat, valamint a horizontális felskálázáskor hozzáadni kívánt csomópontneveket és IP-címeket. Both
2 Az SSL-ellenőrzés az Arc-átjáróvégpontok esetében nem támogatott. Ha végződtető proxyt használ, nem mellőzheti az Arc-átjáró végpontjánál a TLS-vizsgálatot, mert a proxy nem tudja elfogni a beágyazott TLS-alagút forgalmát. Both
3 Ne konfigurálja manuálisan a proxyt. Az Arc regisztrációs szkript automatizálja a WinINET, a WinHTTP és a környezeti változók proxykonfigurációját. Both
4 Az üzembe helyezés után nem frissítheti a proxy megkerülő listáját új végpontok vagy gépek hozzáadásához. Both
5 Használja ugyanazt a proxykonfigurációt az összes Azure Local gépen. Both
6 Az Arc-átjáró által nem engedélyezett végpontok HTTPS-forgalmát, beleértve a külső és AZ OEM-szolgáltatásokat, a rendszer átirányítja a vállalati proxyra vagy tűzfalra. Explicit módon engedélyezze ezeket a végpontokat. Both
7 Az átirányított Azure Resource Bridge virtuális gép és az AKS virtuális gép forgalma mindig a fürt IP-címét birtokló csomóponton halad át. Elemezze az Arc-proxy naplóit erre a forgalomra vonatkozóan azon a csomóponton, amely jelenleg a fürt IP-címét birtokolja. Both

Proxykövetelmények

A helyszíni infrastruktúrából valószínűleg proxyra van szükség az internet eléréséhez. Az Azure Local 2506 óta nem kell manuálisan konfigurálnia a gazdagép proxyját. Ehelyett a vállalati proxykiszolgálót és a proxy megkerülő listáját egyszer kell megadnia az Arc-regisztráció során, és az Arc regisztrációs szkript automatikusan konfigurálja a proxyt mindhárom operációsrendszer-összetevőre – WinINET, WinHTTP és környezeti változókra – minden csomóponton. A proxy részleteit az Arc regisztrációs szkripttel vagy interaktív módon is megadhatja a Configurator alkalmazáson keresztül. További információ: Proxybeállítások konfigurálása.

Ugyanez a proxykonfiguráció automatikusan át lesz helyezve az Arc Resource Bridge virtuális gépre és az AKS-be az üzembe helyezés során, így ezek az összetevők további manuális lépések nélkül internet-hozzáféréssel rendelkeznek. Az Arc-átjáró használatakor a regisztrációs szkript beállítja a gazdagép HTTPS-proxyját a helyi Arc-proxyra (http://localhost:40343), és a HTTP-forgalmat a vállalati proxyhoz irányítja, és automatikusan hozzáfűzi a szükséges belső végpontokat az egyes összetevők megkerülő listájához.

Csak a nem hitelesített proxyk támogatottak. A proxy automatikus konfigurációs (PAC) fájljai és a tartományt .local (például http://proxy.contoso.local) használó proxyvégpontok nem támogatottak.

A proxy megkerülő listájának megadásakor kövesse az alábbi formázási szabályokat, hogy a belső forgalom megfelelően haladjon át a proxyn:

  • Adja meg legalább az egyes Azure Local gépek IP-címét, a fürt IP-címét és az infrastruktúrahálózat IP-címeit. Az Arc Resource Bridge, az AKS és a jövőbeli infrastruktúra-szolgáltatások ezeket az IP-címeket használják. Másik lehetőségként megkerülheti a teljes infrastruktúra-alhálózatot.
  • Adja meg az egyes gépek és a fürt NetBIOS-nevét.
  • Belső tartományok esetén használhatja a tartománynevet egy kezdő csillag (*) helyettesítő karakterrel, például *.contoso.com. Alhálózatok esetén használjon helyettesítő karaktereket, például 192.168.1.*.
  • Vesszővel elválasztott bejegyzések. Az alhálózatok megkerülésére használható CIDR-jelölés nem támogatott.

A proxykonfiguráció összesítési szempontjai a következők:

# Megfontolás A következőkre vonatkozik:
1 Az Azure Local 2506 óta nem kell manuálisan konfigurálnia a gazdagép proxyját. Az Arc regisztrációs szkript automatikusan konfigurálja a WinINET, a WinHTTP és a környezeti változók között. Both
2 Az Arc-regisztráció során, a csomópontok Azure Arcnál történő regisztrálása előtt, egyetlen alkalommal kell megadni a vállalati proxykiszolgálót és a proxykivételi listát. Both
3 A proxy részleteit az Arc regisztrációs szkripten keresztül vagy interaktív módon is megadhatja a Configurator alkalmazáson keresztül. Both
4 Az Arc-regisztrációs szkript az üzembe helyezés során átadja a proxykonfigurációt az Arc Resource Bridge virtuális gépnek és az AKS-nek. Both
5 Csak a nem hitelesített proxyk támogatottak. A tartományt tartalmazó .local PAC-fájlok és proxyvégpontok nem támogatottak. Both
6 A Azure Local csomópontokhoz konfigurált proxykiszolgáló nem fedheti át a fenntartott ARB alhálózati tartományokat (10.96.0.0/12 és 10.244.0.0/16). Both
7 A proxykivételek listájába vegye fel az egyes gépek IP-címét, a fürt IP-címét és az infrastruktúra alhálózatát, továbbá a gép és a fürt NetBIOS-nevét. Különítse el a vesszővel ellátott bejegyzéseket, 192.168.1.*és használjon helyettesítő karaktereket (például ), mert a CIDR-jelölés nem támogatott. Both

Privát végpontok

Az Azure Private Link privát végpontjait használhatja arra, hogy a támogatott, platform mint szolgáltatásként (PaaS) nyújtott Azure-szolgáltatások forgalmát privát hálózati útvonalon, az Azure ExpressRoute-on vagy helyek közötti VPN-en keresztül tartsa. A privát végpontok mind az öt kimenő topológiában támogatottak, például Azure Storage (Blob), Azure SQL, Azure Key Vault, Azure Container Registry (ACR) és Azure Site Recovery. A támogatott forgatókönyvekről és azok forgatókönyvenkénti konfigurációjáról további információt a Azure privát végpontok Azure Local című témakörben talál.

Important

Az Azure Arc Private Link nem támogatott az Azure Local infrastruktúra (csomópontok és Azure erőforráshíd), az Azure Local virtuális gépek és az AKS esetében. Az arcregisztrációnak a nyilvános Arc-végpontokat kell használnia. Az infrastruktúra DNS-ének az Arc FQDN-jeit (például gbl.his.arc.azure.com) nyilvános IP-címekre kell feloldania. Ha a vállalati DNS privát IP-címeket ad vissza ezekhez az FQDN-ekhez, használjon külön DNS-kiszolgálót az Azure Localhoz. Ha a DNS privát IP-címet ad vissza (például a 10.x, a 172.16.x vagy a 192.168.x tartományban) egy gazdagépen lévő Arc-végpont esetében, a konfiguráció nem támogatott.

Privát végpontok tervezésekor kövesse az alábbi szabályokat:

  • Kerülje a fenntartott tartományokkal való átfedést: A privát végpontok IP-címei nem eshetnek a 10.244.0.0/16 (AKS-podok) vagy a 10.96.0.0/12 (Kubernetes-szolgáltatások) tartományába. Az átfedésben lévő végpontok belső fürtforgalomként vannak kezelve, és soha nem hagyják el a virtuális hálózatot. Például egy 10.244.1.4 végpont nem működik, míg a 10.245.0.5 helyesen van irányítva.
  • Az üzembe helyezés során tartsa nyilvánosan a kritikus szolgáltatásokat: Az üzembe helyezés befejezéséig hagyja engedélyezve a nyilvános hozzáférést Azure Key Vault és a tanúsító tárfiókon, majd korlátozza azokat privát hálózatokra.
  • Privát végpontok hozzáadása az elkerülő listához: Vállalati proxy használatakor az Arc-regisztráció során adjon hozzá privát végpontok teljes tartományneveit a proxy megkerülő listájához. AKS-számítási feladatok esetén vegye fel őket a környezeti változók megkerülő listájára az Arc regisztrációja után.
  • Ne használjon helyettesítő karaktereket: Az olyan helyettesítő karakterek, mint amilyenek *.azurecr.io nem támogatottak az elkerülő listában. Az üzembe helyezés előtt adja meg a regiszterek pontos FQDN-jeit, mert az Azure Resource Bridge és az AKS ezeket használja a tárolóképek lekéréséhez.
  • Privát végpontok átirányítása az Arc-átjárón kívül: A privát végpontok nem az Arc-átjárón keresztül lesznek irányítva. Az olyan szolgáltatások esetében, mint a Azure Site Recovery, tiltsa le az SSL-ellenőrzést a vállalati proxyn, vagy lehetőleg adja hozzá a végpontot a proxy megkerülő listájához.

Az alábbi táblázat szolgáltatásonkénti privát végpont-útmutatást nyújt:

Service FQDN Guidance
Azure Key Vault vault.azure.net Az üzembe helyezéshez szükséges (titkos kulcsok konfigurálása). Tartsa engedélyezve a nyilvános hozzáférést az üzembe helyezés során; utána korlátozza.
Azure Storage blob.core.windows.net Kétcsomópontos telepítéshez szükséges (felhőtanú). A beállítás befejezéséig hagyja engedélyezve a nyilvános hozzáférést.
Azure Container Registry azurecr.io Az AKS-rendszerképek lekéréséhez elengedhetetlen. A kivételek listáján nem használhatók helyettesítő karakterek; az üzembe helyezés előtt adja hozzá a regisztrációs adatbázis konkrét FQDN-jeit.
Azure Site Recovery privatelink.siterecovery.* Az Arc-átjárón keresztül nem engedélyezett. Tiltsa le az SSL-ellenőrzést a proxyn, vagy adja hozzá a végpontot a proxy megkerülő listájához.

Tűzfalkövetelmények

Jelenleg több internetes végpontot kell megnyitnia a tűzfalakban, hogy az Azure Local és összetevői sikeresen csatlakozhassanak hozzájuk. A szükséges végpontok részletes listájáért tekintse meg a tűzfal követelményeit.

A tűzfalkonfigurációt a csomópontok Azure Arcban való regisztrálása előtt kell elvégezni. A környezet-ellenőrző önálló verziójával ellenőrizheti, hogy a tűzfalak nem blokkolják-e a végpontokra küldött forgalmat. További információkért tekintse meg az Azure Local Environment Checkert az Azure Local üzembe helyezési készültségének felméréséhez.

Az alábbiakban összefoglaltuk a tűzfallal kapcsolatos szempontokat:

# Megfontolás A következőkre vonatkozik:
1 A csomópontok Azure Arcban való regisztrálása előtt tűzfalkonfigurációt kell végezni. Both
2 A környezet-ellenőrző önálló módban használható a tűzfal konfigurációjának ellenőrzésére. Both

11. döntés: Szoftveralapú hálózatkezelés (SDN) meghatározása

A szoftveralapú hálózatkezelés (SDN) egy választható számítási feladat-hálózati réteg, amelyet a gazdahálózat (1–10. döntések) után kell alkalmazni. A Azure Local az SDN-t a Azure Arc engedélyezi, és két képességre terjed ki: az SDN logikai hálózatokra (LNET-ek), amelyek szoftveralapú hálózati szegmenseket biztosítanak a számítási feladatokhoz, és amelyeket a fizikai hálón lévő VLAN-ok, valamint a hálózati biztonsági csoportokon (NSG-k) keresztüli mikrosegmentáláson keresztül biztosítanak. Döntse el, hogy a számítási feladatoknak programozható hálózati szegmentálásra és elosztott biztonsági szabályzatra van-e szükségük, és győződjön meg arról, hogy az architektúra támogatja-e a szükséges SDN-modellt.

Important

Az Arc által felügyelt SDN a Azure Local nem támogatja a virtuális hálózatokat (VNET-eket), a szoftveres Load Balancer (SLB) vagy a RAS/GRE-átjárókat. Csak az LNET-k és az NSG-k támogatottak. Ha a számítási feladatokhoz VNET, SLB, GRE vagy teljes Microsoft SDN-átjáró verem szükséges, akkor a Azure Local nem ajánlott platform. Ehelyett használjon Windows Server SDN-telepítést, ahol a teljes hálózati vezérlő verem támogatott, beleértve a VNET-eket, az SLB-eket és az átjárókat.

Hiperkonvergens (HCI)

Az 1–16 csomópontos hiperkonvergens telepítések támogatják az Azure Arc által engedélyezett Microsoft SDN-t:

  • Az SDN vezérlősík csak LNET-eket és NSG-ket biztosít. Az engedélyezés bekapcsolja a Azure Virtuális szűrés bővítményt a számítási feladat virtuális kapcsolóján.
  • Az LNET-eket a fabricben VLAN-ok támogatják, ezért minden logikai hálózathoz konfigurálja a megfelelő VLAN-okat, és állítsa trunk módba azokat a ToR kapcsolókon.
  • A hálózati vezérlő fürtszolgáltatások készleteként fut a Azure Local-példányon, nem különálló infrastruktúra-virtuális gépekként.

Az SDN csak a következő hálózati ATC-szándékmintákon támogatott a 7. határozatban:

Szándékminta Leírás Támogatott SDN
Az összes forgalom csoportosítása Egyetlen szándék, amely a felügyeletet, a számítást és a tárolást is magában hordozza. Csak kapcsolt tárhely esetén támogatott. ✅
Csoportkezelés és számítás, külön tárolási szándékkal Egy kezelési és számítási szándék, egy másik pedig a tárolásra vonatkozó szándék. ✅
A számítás és a tárolás csoportosítása külön felügyeleti szándékkal A számítás és a tárolás egy szándékot oszt meg, a felügyelet pedig külön szándékot használ. ❌
Egyéni konfiguráció Bármely egyéni csoportosítás, amely elválasztja a számítási erőforrásokat a felügyelettől az intentek között. ❌

Nem összesített (DA)

A szétválasztott telepítések nem használják a Microsoft SDN-hálózatvezérlőt. Az SDN logikai hálózatok a külső levél-gerinc hálón VXLAN EVPN átfedéssel vannak kiépítve, összhangban a 3. határozat többállványos topológiájával:

  • Tervezze meg a hálózati struktúra VRF-jét és fedőhálózatát a szükséges logikai hálózatok átviteléhez.
  • Az AKS logikai hálózatoknak 3. rétegbeli elérhetőségi rétegre van szükségük a felügyeleti logikai hálózat számára.
  • Az SDN-t nagy léptékben nem igénylő egyállványos, nem összesített fürtök az egyszerűbb kétkapcsolós topológián maradhatnak.

A leaf-spine hálózat VRF- és VXLAN-overlay kialakításával kapcsolatos további információkért lásd a Hálózati referenciaminták áttekintése szétválasztott üzembe helyezésekhez.

Az alábbiakban összefoglaljuk az SDN-döntéssel kapcsolatos szempontokat:

# Megfontolás A következőkre vonatkozik:
1 Az SDN nem kötelező, és az üzembe helyezést követően a gazdagép-hálózat fölé épül. Döntse el, hogy a számítási feladatoknak SDN logikai hálózatokra (LNET-ekre) vagy mikrosegmentációra (NSG-kre) van-e szükségük. Both
2 Az Arc által felügyelt SDN az Azure Localban kizárólag az LNET-eket és az NSG-ket támogatja. A VNET-, SLB- és RAS-/GRE-átjárók nem támogatottak. HCI
3 A helyszíni eszközök által felügyelt SDN-t használó, Azure Localon futó, nem felügyelt virtuális gépek nem alakíthatók át Azure Local virtuális gépekké. HCI
4 Az LNET-eket a hálón lévő VLAN-k biztosítják. Konfigurálja, és állítsa be trönkként az egyes logikai hálózatokhoz tartozó megfelelő VLAN-okat a fizikai kapcsolókon. HCI
5 Ha a számítási feladatok VNET-t, SLB-t, GRE-t vagy teljes Microsoft SDN-átjáró vermet igényelnek, Azure Local helyett használjon Windows Server SDN-üzembe helyezést. HCI
6 A nem összesített (DA) külső szövetalapú SDN-t (VXLAN EVPN- t) használ a levél-gerinc hálón. A Microsoft SDN hálózati vezérlő nincs használatban. DA

Következő lépések

  • Last updated on