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.
Feljegyzé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 teszteli az Azure Stack HCI-t az alábbi Hálózati kapcsoló követelmények szakaszában meghatározott szabványoknak és protokolloknak. Bár a Microsoft nem minősít hálózati kapcsolókat, a gyártó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 is 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 a hálózati kapcsolók szállítói értesülnek a változásokró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ómodell és a kapcsoló operációs rendszerének verziója támogatja a következő szakaszban ismertetett követelményeket.
Hálózati kapcsolókra vonatkozó követelmények
Ez a szakasz az Azure Stack HCI-üzemelő példányokban használt hálózati kapcsolók meghatározott szerepköreihez kötelező iparági szabványokat sorolja fel. Ezek a szabványok segítenek megbízható kommunikációt biztosítani az Azure Stack HCI-fürt üzemelő csomópontjai között.
Feljegyzé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 | Menedzsment | Tárolás | Compute (standard) | Számítás (SDN) |
|---|---|---|---|---|
| Virtuális LANS | ✓ | ✓ | ✓ | ✓ |
| Prioritási folyamatvezérlés | ✓ | |||
| Továbbfejlesztett átvitel kiválasztása | ✓ | |||
| 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 Relay-ügynök | ✓ |
Feljegyzés
A vendég RDMA-nak számításra (Standard) és Storage-ra is szüksége van.
Standard: IEEE 802.1Q
Az Ethernet-kapcsolóknak meg kell felelniük a VLAN-okat meghatározó IEEE 802.1Q specifikációnak. Az Azure Stack HCI számos aspektusához VLAN-okra van szükség, és minden forgatókönyvben szükség van gombra.
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 az adatközpont áthidaló (DCB) használata esetén. Mivel a DCB roCE és iWARP RDMA-forgatókönyvekben is használható, minden forgatókönyvben 802.1Qbb szükséges. A kapcsoló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 legalább egyikének 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 az Enhanced Transmission Select (ETS) paramétert. A DCB használatához ETS szükséges. Mivel a DCB roCE és iWARP RDMA-forgatókönyvekben is használható, a 802.1Qaz minden forgatókönyvben kötelező.
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ő QoS-sebességek meghatározását, javasoljuk, hogy ne konfigurálja a bejövő sebességeket, és ne konfigurálja őket pontosan ugyanolyan értékre, mint a kimenő forgalom (ETS).
Feljegyzés
A hiperkonvergens infrastruktúra nagyban támaszkodik a 2. rétegbeli kelet-nyugati 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 Azure Stack HCI-hez LLDP szükséges, é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élyezni kell. 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.
| Organization | 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 | Csatolási összesítés (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ához, amelyen engedélyezve van a BGP propagálása. Ez szükséges a bérlői számítási feladatok SDN-vel és dinamikus társviszony-létesítéssel való engedélyezéséhez. RFC 4271: Border Gateway Protocol 4
DHCP Relay-ügynök
Az Azure Stack HCI-forgalomhoz 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érelmek é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ásaihoz szükséges. RFC 3046: DHCPv4 vagy RFC 6148: DHCPv4
Hálózati forgalom és architektúra
Ez a szakasz elsősorban a hálózati rendszergazdák számára készült.
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úra számítási feladataihoz, például az Azure Stack HCI-ben.
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 észak-déliek, 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 Kelet-Nyugat, ahol a forgalom jelentős része a 2. réteg (VLAN) határán belül marad.
Fontos
Erősen javasoljuk, hogy a helyek összes fürtcsomópontja fizikailag ugyanabban az állványban legyen, és ugyanahhoz a felső állványkapcsolóhoz (ToR) csatlakozik.
Feljegyzés
A kiterjesztett fürtfunkciók csak az Azure Stack HCI 22H2-es verziójában érhetők el.
Észak-déli forgalom az Azure Stack HCI-hez
Az észak-déli 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ügyelet (PowerShell, Windows Felügyeleti központ), a számítás (VM) és a helyek közötti feszített fürtforgalom.
- Ethernet-kapcsolót használ a fizikai hálózathoz való kapcsolódáshoz.
Kelet-nyugati forgalom az Azure Stack HCI-hez
A kelet-nyugati forgalom a következő jellemzőkkel rendelkezik:
- A forgalom a ToR kapcsolókon és a 2. réteg határán (VLAN) belül marad.
- Magában foglalja a tárolási forgalmat vagy az élő áttelepítési forgalmat az ugyanazon fürt csomópontjai és (ha egy kifeszített fürtöt használ) ugyanazon a helyen.
- 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
Az észak-déli 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.
Feltétlenül tisztában kell lennie a "nem blokkoló" háló sávszélességével, amelyet az Ethernet-kapcsolók támogathatnak, és hogy minimalizálja (vagy lehetőleg kiküszöbölje) a hálózat túlméretezé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 a túlhasználat, például a többvázas kapcsolat összesítési csoportja . Lásd még a gazdagép hálózati követelményeit.
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 lettek méretezve a futtatni kívánt számítási feladathoz.
Kapcsoló nélküli használat
Az Azure Stack HCI minden fürtmérethez támogatja a kelet-nyugati forgalom kapcsoló nélküli (közvetlen) kapcsolatait, 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.
| Illesztőpár | Alhálózat | VLAN |
|---|---|---|
| Mgmt gazdagép vNIC-je | Ü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 |
Feljegyzés
A kapcsoló nélküli üzemelő példányok előnyei a szükséges hálózati adapterek száma miatt három csomópontnál nagyobb fürtökkel csökkennek.
A kapcsoló nélküli kapcsolatok előnyei
- A kelet-nyugati forgalomhoz nincs szükség kapcsolóvásárlásra. Az észak-déli forgalomhoz kapcsoló szükséges. Ez alacsonyabb tőkeköltséget (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árterület-hozzáférést biztosít. A felügyeleti forgalom, a virtuálisgép-forgalom és más, észak-déli hozzáférést igénylő 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át.
- Nem méretez túl jól a háromcsomópontos fürtökön. A további csomópontok további kábelezést és konfigurációt igényelnek, 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: