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.

Hálózattervezési keretrendszer

Az alábbi ábra azOkat a döntéseket és lépéseket mutatja be, amelyek meghatározzák az Azure Local-példány hálózattervezési keretrendszerét – a fürt méretét, a fürttároló-kapcsolatot, a hálózati forgalom szándékait, a felügyeleti kapcsolatot és a hálózati adapter konfigurációját. Minden tervezési döntés lehetővé teszi vagy megengedi a következő lépésekben elérhető tervezési lehetőségeket.

1. lépés: A fürt méretének meghatározása

Az Azure Local-példány méretének meghatározásához használja az Azure Local sizer eszközt, amellyel meghatározhatja a profilját, például a virtuális gépek (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 az Azure Virtual Desktopot, az SQL Servert vagy az AKS-t.

Az Azure Local machine requirements (Azure Local machine requirements ) című cikkben leírtak szerint az Azure Local-példányon támogatott gépek maximális száma 16. 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.

• Ha a számítási feladatok négy vagy több csomópontot igényelnek: Nem helyezhet üzembe és nem használhat kapcsoló nélküli konfigurációt a tárolóhálózati forgalomhoz. 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 három vagy kevesebb csomópontot igényelnek: Választhat kapcsoló nélküli vagy átváltott konfigurációkat a tárolási kapcsolatokhoz.

• Ha később háromnál több csomópontra szeretne vertikálisan felskálázni: fizikai kapcsolót kell használnia a tárolóhálózat forgalmához. A kapcsoló nélküli üzemelő példányok horizontális felskálázási műveleteihez manuális hálózati kábelezésre van szükség azon csomópontok között, amelyeket a Microsoft nem érvényesít aktívan az Azure Local szoftverfejlesztési ciklusának részeként.

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

Döntés	Megfontolás
Fürt mérete (fürtönkénti csomópontok száma)	Az Azure Portalon vagy az Azure Resource Manager-sablonokon keresztüli kapcsoló nélküli konfiguráció csak 1, 2 vagy 3 csomópontfürthöz érhető el. A 4 vagy több csomóponttal rendelkező fürtök fizikai kapcsolót igényelnek a tárolóhálózat forgalmához.
Horizontális skálázási követelmények	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.

2. lépés: Fürttárolókapcsolat meghatározása

A fizikai hálózati követelményeknek megfelelően az Azure Local kétféle kapcsolatot támogat a tárolóhálózati forgalomhoz:

• A forgalom kezeléséhez használjon fizikai hálózati kapcsolót.
• Közvetlenül csatlakoztassa a csomópontokat közöttük crossover hálózattal vagy szálkábelekkel a tárolóforgalomhoz.

Az egyes lehetőségek előnyeit és hátrányait a fent hivatkozott cikkben dokumentáljuk.

Ahogy korábban már említettük, csak akkor dönthet a két lehetőség közül, ha a fürt mérete három vagy annál kevesebb csomópont. A négy vagy több csomóponttal rendelkező fürtök automatikusan üzembe lesznek helyezve egy hálózati kapcsolóval a tároláshoz.

Ha a fürtök kevesebb, mint három csomóponttal rendelkeznek, a tárolási kapcsolatról hozott döntés befolyásolja, hogy a következő lépésben meghatározható hálózati szándékok száma és típusa milyen lehet.

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 crossover kábeleket használó kelet-nyugati kommunikáció tárolási forgalma 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.

Az alábbiakban összefoglaltuk a fürttároló csatlakozási döntésével kapcsolatos szempontokat:

Döntés	Megfontolás
Nincs kapcsoló a tárolóhoz	Az Azure Portalon vagy a Resource Manager-sablon üzembe helyezésén keresztüli kapcsoló nélküli konfiguráció csak 1, 2 vagy 3 csomópontfürt esetén támogatott. 1 vagy 2 csomópontos, kapcsoló nélküli tárolófürtök telepíthetők az Azure Portal vagy a Resource Manager-sablonok használatával. 3 csomópontos tárolókapcsoló nélküli fürtök csak Resource Manager-sablonok használatával telepíthetők. A vertikális felskálázási műveletek nem támogatottak a kapcsoló nélküli üzembe helyezésekkel. A csomópontok számának az üzembe helyezés utáni módosítása manuális konfigurációt igényel. A tárkapcsoló nélküli konfiguráció használatakor legalább 2 hálózati szándékra van szükség.
Hálózati kapcsoló a tároláshoz	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. Ezt az architektúrát tetszőleges számú csomóponttal használhatja 1 és 16 között. Bár nincs kényszerítve, egyetlen szándékot használhat az összes hálózati forgalomtípushoz (felügyelet, számítás és tárolás)

Az alábbi ábra a különböző üzemelő példányokhoz elérhető tárolási kapcsolati lehetőségeket foglalja össze:

3. lépé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. Ha többet szeretne megtudni a hálózati szándékokról és azok hibaelhárításáról, 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, valamint azt, hogy ezek hogyan befolyásolják a keretrendszer következő lépését. Felhőbeli üzemelő példányok esetén 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. Az elérhető lehetőségek a fürt csomópontjainak számától és a használt tárolókapcsolati típustól függenek.

A rendelkezésre álló hálózati célbeállítási lehetőségeket a következő szakaszok ismertetik.

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. Az Azure Portal 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.

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. Az Azure Portal 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.

Az alábbi ábra a különböző telepítésekhez elérhető hálózati szándék lehetőségeket foglalja össze:

4. lépés: A felügyeleti és tárolási hálózati kapcsolat meghatározása

Ebben a lépé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 proxy- vagy VLAN-azonosító követelmény a csomópontok számára az internethez és más intranetes szolgáltatásokhoz, például a tartománynévrendszerhez (DNS) vagy az Active Directory-szolgáltatásokhoz való kimenő kapcsolathoz.

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.

Azok az Arc Resource Bridge fenntartott IP-címtartományok, amelyeket el kell kerülnie az Azure helyi infrastruktúraösszetevők esetében

Az Azure Local üzembe helyezésekor a rendszer automatikusan félretesz bizonyos IP-címtartományokat az Azure Resource Bridge (ARB) és az AKS szolgáltatást használó belső Kubernetes-szolgáltatások számára. Ha az Azure Local-konfiguráció olyan IP-címeket használ, amelyek átfedésben vannak ezekkel a fenntartott tartományokkal, előfordulhat, hogy az üzembe helyezés meghiúsul, vagy csatlakozási problémákat tapasztal, amelyeket nehéz elhárítani.

Fenntartott tartományok – Nem használható

Az alábbi IP-tartományok belsőleg vannak fenntartva az Arc Resource Bridge-hez, és nem használhatók az Azure Local infrastruktúra-összetevőkhöz az alábbiak szerint:

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 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 infrastruktúra IP-készlete	Medence kezdete 10.100.0.1 beleesik 10.96.0.0/12
A csomópontkezelési IP-címek	Csomópont ütközik a 10.244.1.50 podhálózattal
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

Kapcsolódó tartalom

• Az AKS IP-címtervezési követelményei
• Az Arc-erőforráshíd kijelölt IP-tartományai

Hálózati adapter illesztőprogramjai

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.

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. Ezek 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 az alapértelmezett felügyeleti IP-készlet átjáróra. Győződjön meg arról, hogy az alapértelmezett átjáró engedélyezi az ICMP-forgalmat az Azure Local Management alhálózatról.

Az infrastruktúra alhálózatához tartozó IP-készlet üzembe helyezése során a következő feltételeknek kell teljesülniük:

#	Feltétel
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ó.
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.
3	A felügyeleti IP-készlethez definiált alapértelmezett átjárónak kimenő kapcsolatot kell biztosítania az internethez.
4	A DNS-kiszolgálóknak gondoskodniuk kell a névfeloldásról az Active Directoryval és az internettel.
5	A felügyeleti IP-címekhez kimenő internet-hozzáférés szükséges.
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.

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 konfigurálja 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ó nem állítható be a felhőbeli üzembe helyezés során az Azure Portalról, mivel ez a csomópontok és az Azure közötti kapcsolat megszakadásának kockázatát hordozza magában, ha a virtuális hálózatok fizikai kapcsolója nem megfelelően van irányítva.

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 Hype-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. Virtuális kapcsoló létrehozása 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ók nevét ugyanazzal az elnevezési konvencióval nevezzük el. A virtuális kapcsolók ajánlott neve a következő:

""ConvergedSwitch($IntentName), 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 az összes csomóponthoz szükséges hálózati ATC-elnevezési konvencióval

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 az Mgmt Azure Portalon.

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. A VLAN-azonosító konfigurálása az összes csomópont virtuális hálózati adapterének felügyeletéhez

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 célból az üzembe helyezés során

Bár az újonnan létrehozott virtuális hálózati adapter elérhetőként jelenik meg az Azure Portalon való ü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álasztanunk 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ások
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.
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.
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.
4	Nincs VLAN-azonosító bemeneti paraméter az Azure Portal üzembe helyezéséhez vagy a Resource Manager-sablon üzembe helyezéséhez.
5	A felügyelethez használni kívánt összes adapternek ugyanazzal a VLAN-azonosítóval kell rendelkeznie.

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 az alábbi 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 akkor érhető el, ha ARM-sablonokkal helyez üzembe fürtöket, és a következő paramétereket kell megadnia a sablonban.

• enableStorageAutoIP: Ez a paraméter, ha nincs megadva, igaz értékre van állítva. Ha egyéni tároló IP-címeket szeretne engedélyezni az üzembe helyezés során, ezt a paramétert hamis értékre kell állítani.
• storageAdapterIPInfo: Ez a paraméter függőséggel rendelkezik az "enableStorageAutoIP" paraméterrel, és mindig szükség van rá, ha a tároló automatikus IP-paramétere hamis. Az ARM-sablon "storageAdapterIPInfo" paraméterén belül meg kell adnia az "ipv4Address" és az "subnetMask" paramétereket az egyes csomópontokhoz és hálózati adapterekhez saját IP-címekkel és alhálózati maszkkal.
• vlanId: A táblázatban leírtaknak megfelelően ez a paraméter a Hálózati ATC alapértelmezett VLAN-jait fogja használni, ha nem kell módosítania őket. Ha azonban ezek az alapértelmezett VLAN-fájlok nem működnek a hálózaton, minden egyes tárolóhálózathoz megadhat saját VLAN-azonosítókat.

Az alábbi ARM-sablon egy példát tartalmaz egy két csomópontos Azure Local-példányra a tároló hálózati kapcsolójával, ahol a tároló IP-címei testre vannak szabva , 2 csomópont üzembe helyezése egyéni tároló IP-címekkel

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

Az Azure helyi példány esetében két lehetősége van IP-címek hozzárendelésére: egyrészt a gép csomópontjaihoz, másrészt 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 a megadott IP-tartomány ugyanazon alhálózatán kell lenniük.

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ő kapcsolatokhoz és arcregisztrációhoz használt IP-cím azonosítása érdekében az Azure Portal ellenőrzi, hogy egynél 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, és ez 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/24-től 192.168.1.30/24-ig 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 DHCP-foglalást létrehozni 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 sikertelen lesz, 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.

A fürtcsomópont IP-címének szempontjai

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

#	Megfontolások
1	A csomópont IP-címeinek a megadott felügyeleti IP-készlet tartományának ugyanazon alhálózatán kell lenniük, függetlenül attól, hogy statikus vagy dinamikus címekről van-e szó.
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.
3	A csomópontokhoz a lehető legnagyobb mértékben használjon DHCP-foglalásokat.
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.
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.

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. Az Azure Resource Bridge vezérlősík virtuális gépe és az AKS vezérlősíkja ugyanazokat a DNS-kiszolgálókat fogja használni a névfeloldáshoz. Az üzembe helyezés befejezése után nem támogatott a DNS-kiszolgálók IP-címeinek módosítása, és nem lehet frissíteni a címeket az 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, hogy Azure-beli helyi virtuális gépként futtassák őket.

A DNS-kiszolgálók címeire vonatkozó összefoglalt szempontok:

#	Megfontolások
1	A fürt összes csomópontjának DNS-kiszolgálóinak azonosnak kell lenniük.
2	Az infrastruktúra IP-címtartományának DNS-kiszolgálóinak azonosnak kell lenniük a csomópontokhoz.
3	Az 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 fogja használni.
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.
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ó.
6	Nem támogatott az Azure Local infrastruktúra által használt DNS-kiszolgálók futtatása az Azure Local-példányon futó virtuális gépeken.
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.
8	Az összes konfigurált DNS-kiszolgáló nem fedheti egymást a fenntartott ARB alhálózati tartományokkal (10.96.0.0/12 és 10.244.0.0/16)

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

Proxykövetelmények

A helyszíni infrastruktúrán belül valószínűleg proxyra van szükség az internet eléréséhez. Az Azure Local csak a nem hitelesített proxykonfigurációkat támogatja. Mivel az Azure Arcban a csomópontok regisztrálásához internet-hozzáférés szükséges, a proxykonfigurációt az operációs rendszer konfigurációjának részeként kell beállítani a gép csomópontjainak regisztrálása előtt. További információ: Proxybeállítások konfigurálása.

Az Azure Stack HCI operációs rendszer három különböző szolgáltatással rendelkezik (WinInet, WinHTTP és környezeti változók), amelyek ugyanazt a proxykonfigurációt igénylik ahhoz, hogy az összes operációsrendszer-összetevő hozzáférhessen az internethez. A csomópontokhoz használt proxykonfiguráció automatikusan át lesz helyezve az Arc Resource Bridge virtuális gépre és az AKS-be, biztosítva, hogy az üzembe helyezés során internetkapcsolatuk legyen.

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

#	Megfontolás
1	A csomópontok Azure Arcban való regisztrálása előtt a proxykonfigurációt végre kell hajtani.
2	Ugyanezt a proxykonfigurációt kell alkalmazni a WinINET, a WinHTTP és a környezeti változók esetében.
3	A Környezet-ellenőrző biztosítja, hogy a proxykonfiguráció konzisztens legyen az összes proxyösszetevőben.
4	Az Arc Resource Bridge virtuális gép és az AKS proxykonfigurációját a vezénylő automatikusan elvégzi az üzembe helyezés során.
5	Csak a nem hitelesített proxyk támogatottak.
8	Az Azure Helyi 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)

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
1	A csomópontok Azure Arcban való regisztrálása előtt tűzfalkonfigurációt kell végezni.
2	A környezet-ellenőrző önálló módban használható a tűzfal konfigurációjának ellenőrzésére.

5. lépés: A hálózati adapter konfigurációjának meghatározása

A hálózati adapterek a használt hálózati forgalomtípus (felügyelet, számítás és tárolás) alapján vannak minősítve. A Windows Server-katalógus áttekintése során a Windows Server 2022 tanúsítvány azt jelzi, hogy az adapterek mely hálózati forgalomra vannak minősítve.

Mielőtt megvásárol egy gépet az Azure Local-hoz, rendelkeznie kell legalább egy olyan adapterrel, amely a felügyelethez, a számításhoz és a tároláshoz szükséges, mivel mindhárom forgalmi típusra szükség van az Azure Local-ban. 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.

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 lehetőségek felülírhatók az Azure Portal vagy a Resource Manager-sablonok használatával, ha szükséges:

• 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.
• Közvetlen hálózat: Állítsa ezt az értéket hamis értékre, ha le szeretné tiltani az RDMA-t a hálózati adaptereken.
• 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.

A hálózati adapter konfigurálásának összesítő szempontjai:

#	Megfontolás
1	A lehető legnagyobb mértékben használja az alapértelmezett konfigurációkat.
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.
3	Győződjön meg arról, hogy a hálózati adapterek támogatottak az Azure Local esetében a Windows Server-katalógus használatával.
4	Az alapértelmezett beállítások elfogadásakor a hálózati ATC automatikusan konfigurálja a tárolóhálózati adapter IP-címeit és VLAN-jait. Ezt storage auto IP-konfigurációnak nevezzük. 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.

Következő lépések

• Tudnivalók az Azure Local üzembe helyezéséről.