Az Azure Stack HCI fizikai hálózati követelményei
A következőkre vonatkozik: Azure Stack HCI, 23H2 és 22H2 verzió
Ez a cikk az Azure Stack HCI fizikai (hálós) hálózati szempontjait és követelményeit ismerteti, különösen a hálózati kapcsolók esetében.
Megjegyzés
Az Azure Stack HCI jövőbeli verzióira vonatkozó követelmények változhatnak.
Hálózati kapcsolók az Azure Stack HCI-hez
A Microsoft az Azure Stack HCI-t az alábbi Hálózati kapcsolók követelményei szakaszban meghatározott szabványoknak és protokolloknak megfelelően teszteli. Bár a Microsoft nem minősíti a hálózati kapcsolókat, a szállítókkal együttműködve azonosítjuk az Azure Stack HCI-követelményeket támogató eszközöket.
Fontos
Bár az itt nem felsorolt technológiákat és protokollokat használó egyéb hálózati kapcsolók működhetnek, a Microsoft nem tudja garantálni, hogy együttműködnek az Azure Stack HCI-vel, és előfordulhat, hogy nem tudnak segíteni a felmerülő problémák elhárításában.
Hálózati kapcsolók vásárlásakor forduljon a kapcsoló gyártójához, és győződjön meg arról, hogy az eszközök megfelelnek a megadott szerepkörtípusokra vonatkozó Azure Stack HCI-követelményeknek. A következő szállítók (betűrendben) megerősítették, hogy kapcsolóik támogatják az Azure Stack HCI követelményeit:
Kattintson a szállító fülre az egyes Azure Stack HCI-forgalomtípusok érvényesített kapcsolóinak megtekintéséhez. Ezek a hálózati besorolások itt találhatók.
Fontos
Ezeket a listákat úgy frissítjük, hogy értesülünk a hálózati kapcsolók szállítóinak változásairól.
Ha a kapcsoló nem szerepel a csomagban, forduljon a kapcsoló gyártójához, és győződjön meg arról, hogy a kapcsoló modellje és a kapcsoló operációs rendszerének verziója támogatja a következő szakaszban szereplő követelményeket.
Hálózati kapcsolókra vonatkozó követelmények
Ez a szakasz azOkat az iparági szabványokat sorolja fel, amelyek kötelezőek az Azure Stack HCI-üzemelő példányokban használt hálózati kapcsolók adott szerepköreihez. Ezek a szabványok segítenek megbízható kommunikációt biztosítani az Azure Stack HCI-fürtök üzemelő csomópontjai között.
Megjegyzés
A számítási, tárolási és felügyeleti forgalomhoz használt hálózati adapterekhez Ethernet szükséges. További információ: Gazdagép hálózati követelményei.
Íme a kötelező IEEE-szabványok és -specifikációk:
23H2 szerepkörkövetelmények
| Követelmény | Kezelés | Tárolás | Compute (standard) | Számítás (SDN) |
|---|---|---|---|---|
| Virtuális LAN-k | ✓ | ✓ | ✓ | ✓ |
| Prioritási folyamat vezérlője | ✓ | |||
| Továbbfejlesztett átviteli kijelölés | ✓ | |||
| LLDP-port VLAN-azonosítója | ✓ | |||
| LLDP VLAN-neve | ✓ | ✓ | ✓ | |
| LLDP-hivatkozás összesítése | ✓ | ✓ | ✓ | ✓ |
| LLDP ETS-konfiguráció | ✓ | |||
| LLDP ETS-javaslat | ✓ | |||
| LLDP PFC-konfiguráció | ✓ | |||
| LLDP maximális keretmérete | ✓ | ✓ | ✓ | ✓ |
| Maximális átviteli egység | ✓ | |||
| Border Gateway Protocol | ✓ | |||
| DHCP-továbbítóügynök | ✓ |
Megjegyzés
A vendég RDMA számítást (Standard) és Storage-t is igényel.
Standard: IEEE 802.1Q
Az Ethernet-kapcsolóknak meg kell felelniük a VLAN-okat definiáló IEEE 802.1Q specifikációnak. Az Azure Stack HCI számos aspektusához VLAN-okra van szükség, amelyek minden forgatókönyvben szükségesek.
Standard: IEEE 802.1Qbb
Az Azure Stack HCI-tárolóforgalomhoz használt Ethernet-kapcsolóknak meg kell felelniük az IEEE 802.1Qbb specifikációnak, amely meghatározza a prioritási folyamatvezérlést (PFC). PFC-re van szükség, ha adatközpont-áthidaló (DCB) elemet használnak. Mivel a DCB roCE és iWARP RDMA forgatókönyvekben is használható, minden forgatókönyvben 802.1Qbb-ra van szükség. A váltási képességek vagy a portsebességek leminősítése nélkül legalább három Szolgáltatási osztály (CoS) prioritásra van szükség. Ezen forgalmi osztályok közül legalább egynek veszteségmentes kommunikációt kell biztosítania.
Standard: IEEE 802.1Qaz
Az Azure Stack HCI-tárolóforgalomhoz használt Ethernet-kapcsolóknak meg kell felelniük az IEEE 802.1Qaz specifikációnak, amely meghatározza a Enhanced Transmission Select (ETS) értéket. A DCB használata esetén ETS szükséges. Mivel a DCB RoCE- és iWARP RDMA-forgatókönyvekben is használható, minden forgatókönyvben 802.1Qaz szükséges.
Legalább három CoS-prioritásra van szükség a kapcsolóképességek vagy a portsebesség leminősítése nélkül. Továbbá, ha az eszköz engedélyezi a bejövő forgalom QoS-sebességének meghatározását, javasoljuk, hogy ne konfigurálja a bemeneti sebességeket, és ne konfigurálja őket pontosan a kimenő forgalom (ETS) sebességével megegyező értékre.
Megjegyzés
A hiperkonvergens infrastruktúra nagyban támaszkodik East-West 2. rétegbeli kommunikációra ugyanazon az állványon belül, ezért ETS-t igényel. A Microsoft nem teszteli az Azure Stack HCI-t a differenciált szolgáltatások kódpontjával (DSCP).
Standard: IEEE 802.1AB
Az Ethernet-kapcsolóknak meg kell felelniük az IEEE 802.1AB specifikációnak, amely meghatározza a Link Layer Discovery Protocol (LLDP) protokollt. Az LLDP szükséges az Azure Stack HCI-hez, és lehetővé teszi a fizikai hálózati konfigurációk hibaelhárítását.
Az LLDP Type-Length-Values (TLV-k) konfigurációjának dinamikusan engedélyezve kell lennie. A kapcsolók nem igényelnek további konfigurációt egy adott TLV engedélyezésén túl. A 802.1 3. altípus engedélyezésének például automatikusan meg kell hirdetnie a kapcsolóportokon elérhető összes VLAN-t.
Egyéni TLV-követelmények
Az LLDP lehetővé teszi a szervezetek számára, hogy saját egyéni TLV-ket definiáljanak és kódoljanak. Ezeket szervezetileg specifikus TLV-nek nevezzük. Minden szervezetileg specifikus TLV 127-es LLDP TLV-típusértékkel kezdődik. Az alábbi táblázat bemutatja, hogy mely szervezetileg specifikus egyéni TLV-altípusokra (TLV Type 127) van szükség.
| Szervezet | TLV-altípus |
|---|---|
| IEEE 802.1 | Port VLAN-azonosítója (altípus = 1) |
| IEEE 802.1 | VLAN-név (altípus = 3) Legalább 10 VLANS |
| IEEE 802.1 | Hivatkozás összesítése (altípus = 7) |
| IEEE 802.1 | ETS-konfiguráció (altípus = 9) |
| IEEE 802.1 | ETS-javaslat (altípus = A) |
| IEEE 802.1 | PFC-konfiguráció (altípus = B) |
| IEEE 802.3 | Maximális keretméret (altípus = 4) |
Maximális átviteli egység
A maximális átviteli egység (MTU) az adatkapcsolaton keresztül továbbítható legnagyobb méretű keret vagy csomag. Az SDN-beágyazáshoz 1514–9174 tartomány szükséges.
Border Gateway Protocol
Az Azure Stack HCI SDN számítási forgalmához használt Ethernet-kapcsolóknak támogatniuk kell a Border Gateway Protocol (BGP) protokollt. A BGP egy szabványos útválasztási protokoll, amellyel útválasztási és elérhetőségi információkat cserélhet két vagy több hálózat között. A rendszer automatikusan hozzáadja az útvonalakat az összes olyan alhálózat útvonaltáblájához, amelyen engedélyezve van a BGP-propagálás. Ez a bérlői számítási feladatok SDN-vel és dinamikus társviszony-létesítéssel való engedélyezéséhez szükséges. RFC 4271: Border Gateway Protocol 4
DHCP-továbbítóügynök
Az Azure Stack HCI felügyeleti forgalmához használt Ethernet-kapcsolóknak támogatniuk kell a DHCP-továbbítóügynököt. A DHCP-továbbítóügynök bármely TCP/IP-gazdagép, amely a DHCP-kiszolgáló és az ügyfél közötti kérések és válaszok továbbítására szolgál, ha a kiszolgáló egy másik hálózaton található. A PXE rendszerindítási szolgáltatásokhoz szükséges. RFC 3046: DHCPv4 vagy RFC 6148: DHCPv4
Hálózati forgalom és architektúra
Ez a szakasz elsősorban hálózati rendszergazdáknak szól.
Az Azure Stack HCI különböző adatközpont-architektúrákban képes működni, beleértve a kétrétegű (Spine-Leaf) és a háromrétegű (Core-Aggregation-Access) architektúrákat. Ez a szakasz a Spine-Leaf topológia azon fogalmaira hivatkozik, amelyeket gyakran használnak hiperkonvergens infrastruktúrákban, például az Azure Stack HCI-ben használt számítási feladatokhoz.
Hálózati modellek
A hálózati forgalom az iránya alapján besorolható. A hagyományos tárolóhálózati (SAN-) környezetek erősen North-South, ahol a forgalom egy számítási szintről egy tárolási rétegre halad át egy 3. rétegbeli (IP-) határon. A hiperkonvergens infrastruktúra nagyobb mértékben East-West, ahol a forgalom jelentős része a 2. réteg (VLAN) határain belül marad.
Fontos
Határozottan javasoljuk, hogy a helyek összes fürtcsomópontja fizikailag ugyanabban az állványban legyen, és ugyanahhoz a top-of-rack (ToR) kapcsolóhoz legyen csatlakoztatva.
North-South forgalom az Azure Stack HCI-hez
North-South forgalom a következő jellemzőkkel rendelkezik:
- A forgalom egy ToR-kapcsolóból a gerincre vagy a gerincről egy ToR-kapcsolóra áramlik.
- A forgalom elhagyja a fizikai állványt, vagy átlép egy 3. rétegbeli határt (IP).
- Magában foglalja a felügyeletet (PowerShell, Windows Admin Center), a számítást (VM) és a helyek közötti, többhelyes fürtforgalmat.
- Ethernet-kapcsolót használ a fizikai hálózathoz való csatlakozáshoz.
East-West forgalom az Azure Stack HCI-hez
East-West forgalom a következő jellemzőkkel rendelkezik:
- A forgalom a tor kapcsolókon és a 2. rétegbeli határon (VLAN) belül marad.
- Magában foglalja a tárolási forgalmat vagy az élő áttelepítési forgalmat az ugyanabban a fürtben és (ha többhelyes fürtöt használ) ugyanazon a helyen található csomópontok között.
- Használhat Ethernet-kapcsolót (kapcsolóval) vagy közvetlen (kapcsoló nélküli) kapcsolatot a következő két szakaszban leírtak szerint.
Kapcsolók használata
North-South forgalomhoz kapcsolókra van szükség. Az Azure Stack HCI-hez szükséges protokollokat támogató Ethernet-kapcsoló használata mellett a legfontosabb szempont a hálózati háló megfelelő méretezése.
Elengedhetetlen megérteni a "nem blokkoló" háló sávszélességét, amelyet az Ethernet-kapcsolók támogathatnak, és hogy minimalizálja (vagy lehetőleg kiküszöböli) a hálózat túljelentkezését.
Az alhálózatok és a VLAN-k megfelelő használatával kiküszöbölhetők a gyakori torlódási pontok és túljelentkezések, például a többvázas kapcsolat összesítési csoportja , amelyet az útvonalredundanciához használnak. Lásd még: Gazdagép hálózati követelményei.
A hálózati szállítóval vagy a hálózattámogatási csapattal együttműködve győződjön meg arról, hogy a hálózati kapcsolók megfelelően méretezettek a futtatni kívánt számítási feladathoz.
Kapcsoló nélküli használat
Az Azure Stack HCI támogatja a kapcsoló nélküli (közvetlen) kapcsolatokat az összes fürtméret East-West forgalmához, amennyiben a fürt minden csomópontja redundáns kapcsolatot létesít a fürt minden csomópontjához. Ezt "teljes hálós" kapcsolatnak nevezzük.
| Adapterpár | Alhálózat | VLAN |
|---|---|---|
| Mgmt-gazdagép virtuális hálózati adaptere | Ügyfélspecifikus | Ügyfélspecifikus |
| SMB01 | 192.168.71.x/24 | 711 |
| SMB02 | 192.168.72.x/24 | 712 |
| SMB03 | 192.168.73.x/24 | 713 |
Megjegyzés
A kapcsoló nélküli üzemelő példányok előnyei a szükséges hálózati adapterek száma miatt csökkennek a három csomópontnál nagyobb fürtök esetében.
A kapcsoló nélküli kapcsolatok előnyei
- A forgalom East-West nincs szükség kapcsolóvásárlásra. A forgalom North-South kapcsolóra van szükség. Ez alacsonyabb tőkekiadást (CAPEX) eredményezhet, de a fürt csomópontjainak számától függ.
- Mivel nincs kapcsoló, a konfiguráció a gazdagépre korlátozódik, ami csökkentheti a szükséges konfigurációs lépések számát. Ez az érték a fürt méretének növekedésével csökken.
A kapcsoló nélküli kapcsolatok hátrányai
- További tervezésre van szükség az IP- és alhálózat-címzési sémákhoz.
- Csak helyi tárhozzáférést biztosít. A felügyeleti forgalom, a virtuálisgép-forgalom és a North-South hozzáférést igénylő egyéb forgalom nem használhatja ezeket az adaptereket.
- A fürt csomópontjainak számának növekedésével a hálózati adapterek költsége meghaladhatja a hálózati kapcsolók használatának költségeit.
- Nem skálázható túl jól a háromcsomópontos fürtökön. Több csomóponthoz további kábelezés és konfiguráció szükséges, amelyek meghaladhatják a kapcsolók használatának összetettségét.
- A fürtbővítés összetett, és hardver- és szoftverkonfigurációs módosításokat igényel.
Következő lépések
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: