Gazdagép hálózati követelményei a Azure Stack HCI

A következőkre vonatkozik: Azure Stack HCI 21H2 és 20H2 verziókra

Ez a témakör a gazdagépek hálózatra vonatkozó szempontjait és követelményeit ismerteti a Azure Stack HCI. További információ az adatközpontok architektúráiról és a kiszolgálók közötti fizikai kapcsolatokról: Fizikai hálózati követelmények.

További információ a gazdagépek hálózatának hálózati ATC használatával való egyszerűsítésével kapcsolatban: A gazdagép-hálózat egyszerűsítése hálózati ATC-val.

Hálózati forgalom típusai

Azure Stack HCI hálózati forgalom a rendeltetése szerint besorolható:

  • Számítási forgalom: Virtuális gépről (VM) származó vagy az arra vezető forgalom.
  • Storage forgalom: Közvetlen Tárolóhelyek (S2D) forgalma, SMB használatával.
  • Felügyeleti forgalom: A fürtkezelés (például a felügyeleti központ, a felügyeleti központ Active Directory, Távoli asztal, Windows és a fürtkezelés Windows PowerShell.

Hálózati adapter kiválasztása

Azure Stack HCI olyan hálózati adaptert kell választania, amely elérte a Windows Server Software-Defined Data Center (SDDC) standard vagy Prémium Minősítés (AQ) minősítését. Ezek az adapterek támogatják a legfejlettebb platformszolgáltatásokat, és a hardverpartnereink tesztelték a legnagyobbat. Az ilyen szintű ellenőrzés általában a hardverrel és az illesztővel kapcsolatos minőségi problémák csökkenését eredményezi. Ezek az adapterek a közvetlen Tárolóhelyek is megfelelnek.

A Standard vagy Prémium AQ-val Windows adapter azonosításához tekintse át az adapterhez tartozó Windows-kiszolgálókatalógus bejegyzést és az operációs rendszer megfelelő verzióját. Az alábbi példa az AQ-val Prémium meg:

Screenshot of Windows Certified options, with a Premium AQ option highlighted.

A fő hálózati adapterek képességeinek áttekintése

A hálózati adapterek által használt fontos Azure Stack HCI többek között:

  • Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ vagy d.VMMQ)
  • Távoli közvetlen memória-hozzáférés (RDMA)
  • Vendég RDMA
  • Switch Embedded Teaming (SET)

Dinamikus VMMQ

Az AQ-val Prémium hálózati adapterek támogatják a Dinamikus VMMQ-t. A Dinamikus VMMQ-nak a Switch Embedded Teaming használatát kell használnia.

Alkalmazható forgalomtípusok: számítás

Szükséges tanúsítványok: Prémium

A dinamikus VMMQ egy intelligens, fogadási oldali technológia. A szolgáltatás a virtuálisgép-várólista (VMQ), a virtuális fogadási oldali skálázás (vRSS) és a VMMQ elődjeire épít:

  • Kevesebb processzormag használatával optimalizálja a gazdagép hatékonyságát.
  • A hálózati forgalom feldolgozásának automatikus finomhangolása a processzormagok számára, így a virtuális gépek teljesítik és fenntartják a várt átviteli sebességet.
  • Lehetővé teszi, hogy a "nagy forgalmú" számítási feladatok a várt mennyiségű forgalmat kapják meg.

A dinamikus VMMQ-val kapcsolatos további információkért tekintse meg a szintetikus gyorsítások blogbejegyzését.

RDMA

Az RDMA egy hálózati verem kiszervezése a hálózati adapterre. Lehetővé teszi az SMB-tároló forgalmának az operációs rendszer megkerülését feldolgozás céljából.

Az RDMA lehetővé teszi a nagy átviteli sebességet és a kis késleltetésű hálózatokat a gazdagép minimális processzor-erőforrásainak használatával. Ezek a gazdagép cpu-erőforrásai további virtuális gépek vagy tárolók futtatására használhatók.

Alkalmazható forgalomtípusok: gazdatároló

Szükséges tanúsítványok: Standard

A Standard vagy AQ Prémium adapterek támogatják az RDMA-t. Az RDMA az ajánlott üzembe helyezési választás a Azure Stack HCI tárolási számítási feladataihoz, és opcionálisan engedélyezhető a virtuális gépek tárolási számítási feladataihoz (SMB használatával). További információt a cikk későbbi, "Vendég RDMA" című szakaszában talál.

Azure Stack HCI rdMA-t az Internet Wide Area RDMA Protocol (iWARP) vagy az RDMA over Converged Ethernet (RoCE) protokoll-implementációk használatával támogatja.

Fontos

Az RDMA-adapterek csak olyan más RDMA-adapterekkel működnek, amelyek ugyanazt az RDMA-protokollt (iWARP vagy RoCE) valósítják meg.

Nem minden gyártótól származó hálózati adapter támogatja az RDMA-t. Az alábbi táblázat azokat a szállítókat sorolja fel (betűrendben), amelyek minősített RDMA Prémium kínálnak. A listában azonban nem szerepelnek olyan hardverszállítók, amelyek támogatják az RDMA-t is. Az RDMA Windows támogatás ellenőrzéséhez tekintse meg a következőt: Windows-kiszolgálókatalógus.

Megjegyzés

Az InfiniBand (IB) nem támogatott a Azure Stack HCI.

Hálózati adapter szállítója iWARP RoCE
Broadcom Nem Igen
Valamintsio Igen Nem
Intel Igen Igen (egyes modellek)
Fogl (Qlogic/Cavium) Igen Igen
Nvidia (Mellanox) Nem Igen

Az RDMA telepítésével kapcsolatos további információkért töltse le a dokumentumot az SDN-GitHub adattárból.

iWARP

Az iWARP Transmission Control Protocol (TCP) protokollt használ, és opcionálisan továbbfejleszthető a Prioritásalapú Flow Control (PFC) és a Enhanced Transmission Service (ETS) szolgáltatással.

Akkor használja az iWARP-t, ha:

  • Kevés vagy semmilyen hálózati tapasztalattal nem rendelkezik, vagy nem kezeli a hálózati kapcsolókat.
  • A top-of-rack (ToR) kapcsolókat nem Ön vezéreli.
  • A megoldást az üzembe helyezés után nem fogja majd kezeli.
  • Már vannak olyan üzemelő példányai, amelyek az iWARP-t használják.
  • Nem biztos benne, hogy melyik lehetőséget válassza.

RoCE

A RoCE a User Datagram Protocolt (UDP) használja, és a megbízhatóság érdekében PFC és ETS szükséges hozzá.

Akkor használja a RoCE-t, ha:

  • A RoCE-val már rendelkezik üzemelő példányokkal az adatközpontban.
  • Ön kényelmesen kezeli a DCB hálózati követelményeit.

Vendég RDMA

A vendég RDMA lehetővé teszi az SMB számítási feladatok virtuális gépek számára, hogy az RDMA gazdagépen való használatával azonos előnyöket szerezzenek.

Alkalmazható forgalomtípusok: Vendégalapú tárolás

Szükséges tanúsítványok: Prémium

A vendég RDMA használatának elsődleges előnyei a következőek:

  • Cpu-kiszervezés a hálózati adapterre a hálózati forgalom feldolgozásához.
  • Rendkívül alacsony késés.
  • Nagy átviteli sebesség.

További információért töltse le a dokumentumot az SDN-GitHub adattárból.

SET

A SET egy szoftveralapú csoportkezelő technológia, amely a Windows Server operációs rendszer része a Windows Server 2016. A SET nem függ a használt hálózati adapterek típusától.

Alkalmazható forgalomtípusok: számítás, tárolás és felügyelet

Szükséges tanúsítványok: nincs (a SET be van építve az operációs rendszerbe)

A SET az Azure Stack HCI által támogatott egyetlen összevonási technológia. A SET jól működik a számítási, tárolási és felügyeleti forgalommal.

Fontos

A terheléselosztás/feladatátvétel (LBFO) egy másik, az Windows Serverrel gyakran használt csoportmunka-Azure Stack HCI. Az LBFO-ről további információt az Azure Stack HCI teaming in Azure Stack HCI.

A SET azért Azure Stack HCI, mert ez az egyetlen olyan csoportmunka-technológia, amely lehetővé teszi a következőt:

  • RDMA-adapterek összeadása (ha szükséges).
  • Vendég RDMA.
  • Dinamikus VMMQ.
  • További fontos Azure Stack HCI funkciók (lásd: Teaming in Azure Stack HCI).

Vegye figyelembe, hogy a SET használatához szimmetrikus (azonos) adapterek használata szükséges. Az aszimmetrikus adapterek összeadása nem támogatott. A szimmetrikus hálózati adapterek ugyanazok:

  • gyártó (szállító)
  • modell (verzió)
  • sebesség (átviteli sebesség)
  • konfiguráció

Az adapterek szimmetrikus azonosításának legegyszerűbb módja, ha a sebességek megegyeznek, és az interfész leírásai megegyeznek. Csak a leírásban szereplő számban térnek el. A parancsmag használatával győződjön meg arról, hogy Get-NetAdapterAdvancedProperty a jelentett konfigurációban ugyanazok a tulajdonságértékek vannak felsorolva.

Az alábbi táblázatban egy példát láthat arra, hogy a felület leírásai csak számmal (#) térnek el:

Name Interfész leírása Hivatkozás sebessége
NIC1 1. hálózati adapter 25 Gbit/s
NIC2 2. hálózati adapter 25 Gbit/s
NIC3 3. hálózati adapter 25 Gbit/s
NIC4 4. hálózati adapter 25 Gbit/s

Megjegyzés

A SET csak a kapcsolóktól független konfigurációt támogatja dinamikus vagy Hyper-V-port terheléselosztási algoritmusok használatával. A legjobb teljesítmény érdekében a Hyper-V-port használata javasolt a legalább 10 Gb/s-es hálózati adapterek esetében.

RDMA-forgalommal kapcsolatos szempontok

DCB implementációja esetén gondoskodnia kell arról, hogy a PFC és az ETS konfigurációja minden hálózati porton, beleértve a hálózati kapcsolókat is, megfelelően legyen megvalósítva. A ROCE-hez DCB szükséges, iWARP esetén pedig nem kötelező.

Az RDMA telepítésével kapcsolatos részletes információkért töltse le a dokumentumot az SDN-GitHub adattárból.

A RoCE-Azure Stack HCI implementációihoz három PFC forgalmi osztályt kell konfigurálni, beleértve az alapértelmezett forgalomosztályt is a hálóban és az összes gazdagépen.

Fürt adatforgalmi osztálya

Ez a forgalomosztály biztosítja, hogy elegendő sávszélesség legyen lefoglalva a fürt szívverései számára:

  • Kötelező: Igen
  • PFC-kompatibilis: Nem
  • Ajánlott forgalom prioritása: 7-es prioritás
  • Ajánlott sávszélesség-foglalás:
    • 10 GbE vagy alacsonyabb RDMA-hálózatok = 2 százalék
    • 25 GbE vagy magasabb RDMA-hálózatok = 1 százalék

RDMA forgalmi osztály

Ez a forgalomosztály biztosítja, hogy elegendő sávszélesség legyen fenntartva a veszteségmentes RDMA-kommunikációhoz az SMB Direct használatával:

  • Kötelező: Igen
  • PFC-kompatibilis: Igen
  • Ajánlott forgalom prioritása: 3-as vagy 4-es prioritás
  • Ajánlott sávszélesség-foglalás: 50%

Alapértelmezett forgalomosztály

Ez a forgalomosztály a fürtben vagy RDMA-forgalomosztályban nem meghatározott összes többi forgalmat tartalmazza, beleértve a virtuális gépek forgalmát és a felügyeleti forgalmat is:

  • Kötelező: Alapértelmezés szerint (nincs szükség konfigurálásra a gazdagépen)
  • Flow (PFC)-kompatibilis: Nem
  • Ajánlott forgalomosztály: Alapértelmezés szerint (0-s prioritás)
  • Ajánlott sávszélesség-foglalás: Alapértelmezés szerint (nincs szükség gazdagép-konfigurációra)

Storage forgalmi modellek

Az SMB számos előnyt biztosít, mint az SMB Azure Stack HCI, beleértve a többcsatornás SMB-t is. A többcsatornás SMB-t ez a cikk nem fedi le, de fontos tisztában lennie vele, hogy a forgalom minden, a Többcsatornás SMB által használható kapcsolaton multiplexált.

Megjegyzés

Javasoljuk, hogy több alhálózatot és VLAN-t is használ a tárterület forgalmának Azure Stack HCI.

Vegyük példaként a következő négy csomópontfürtöt. Minden kiszolgáló két tárolóporttal rendelkezik (bal és jobb oldalon). Mivel minden adapter ugyanazon az alhálózaton és VLAN-on található, a többcsatornás SMB el fogja terjeszteni a kapcsolatokat az összes elérhető kapcsolat között. Ezért az első kiszolgáló bal oldali portja (192.168.1.1) kapcsolatot létesít a második kiszolgáló bal oldali portjához (192.168.1.2). Az első kiszolgáló jobb oldali portja (192.168.1.12) a második kiszolgáló jobb oldali portjához fog csatlakozni. Hasonló kapcsolatok vannak létesítve a harmadik és a negyedik kiszolgálóhoz is.

Ez azonban szükségtelen kapcsolatokat hoz létre, és torlódást okoz a tor kapcsolókat (X-ekkel jelölt) torlódást okoz a tor kapcsolókat összekötő (több vázú kapcsolati aggregációs csoport vagy MC-LAG) között. Lásd az alábbi ábrát:

Diagram that shows a four-node cluster on the same subnet.

Az ajánlott módszer az egyes adapterkészletek külön alhálózatának és VLAN-jának használata. Az alábbi ábrán a jobb oldali portok a 192.168.2.x /24 alhálózatot és a VLAN2 alhálózatot használják. Ez lehetővé teszi, hogy a bal oldali portokon a forgalom a TOR1-re, a jobb oldali portokon pedig a TOR2-re maradjon.

Diagram that shows a four-node cluster on different subnets.

Forgalom sávszélesség-kiosztása

Az alábbi táblázat a különböző típusú forgalom általános adaptersebességek használatával történő sávszélesség-kiosztását mutatja be a Azure Stack HCI. Vegye figyelembe, hogy ez egy példa egy konvergensmegoldásra, amelyben minden forgalomtípus (számítási, tárolási és felügyeleti) ugyanazon fizikai adapteren fut, és a SET használatával van összeállítva.

Mivel ez a legtöbb korlátozást ez a felhasználás jelenti, jó alapkonfigurációt jelent. Az adapterek és a sebességek számának permutációit figyelembe véve azonban ezt példaként kell tekinteni, nem pedig támogatási követelményként.

Ehhez a példához a következő feltételezések állnak elő:

  • Csapatonként két adapter van.

  • Storage réteg (SBL), Fürt megosztott kötete (CSV) és Hyper-V (Élő áttelepítés) forgalma:

    • Használja ugyanezeket a fizikai adaptereket.
    • Használja az SMB-t.
  • Az SMB 50%-os sávszélesség-lefoglalást kap a DCB használatával.

    • Az SBL/CSV a legmagasabb prioritású forgalom, és az SMB sávszélesség-foglalásának 70%-át kapja meg.
    • Élő áttelepítés (LM) a parancsmag használatával korlátozott, és a fennmaradó sávszélesség Set-SMBBandwidthLimit 29%-át kapja meg.
      • Ha a rendelkezésre álló sávszélesség Élő áttelepítés = 5 Gb/s, és a hálózati > adapterek képesek, használja az RDMA-t. Használja a következő parancsmagot:

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB
        
      • Ha a rendelkezésre álló sávszélesség Élő áttelepítés 5 Gb/s, használja a tömörítést a < áramkimaradások számának csökkentéséhez. Használja a következő parancsmagot:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • Ha RDMA-t használ Élő áttelepítés forgalomhoz, győződjön meg arról, hogy az Élő áttelepítés-forgalom nem tudja használni az RDMA forgalmi osztályhoz lefoglalt teljes sávszélességet egy SMB sávszélességkorlát használatával. Legyen óvatos, mivel ez a parancsmag bájt/másodpercben (Bps) vesz fel bejegyzést, a hálózati adapterek pedig bit/másodpercben (b/s) vannak felsorolva. A következő parancsmag használatával 6 Gbit/s sávszélesség-korlátot állíthat be, például:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
    

    Megjegyzés

    Ebben a példában a 750 MBps 6 Gb/s-ot jelent.

Példa a sávszélesség-kiosztási táblázatra:

Hálózati adapter sebessége Sávszélességek összecsoportosodva SMB-sávszélesség foglalása** SBL/CSV % SBL/CSV sávszélesség Élő áttelepítés % Maximális Élő áttelepítés sávszélesség Szívverés (% ) Szívverés sávszélessége
10 Gbps 20 Gbit/s 10 Gbps 70% 7 Gbit/s * * 2% 200 Mbit/s
25 Gbps 50 Gbit/s 25 Gbps 70% 17,5 Gbit/s 29% 7,25 Gbit/s 1% 250 Mbps
40 Gbps 80 Gbit/s 40 Gbps 70% 28 Gbit/s 29% 11,6 Gbit/s 1% 400 Mbps
50 Gbit/s 100 Gbps 50 Gbit/s 70% 35 Gbps 29% 14,5 Gbit/s 1% 500 Mbps
100 Gbps 200 Gbit/s 100 Gbps 70% 70 Gbit/s 29% 29 Gbit/s 1% 1 Gbps
200 Gbit/s 400 Gbit/s 200 Gbit/s 70% 140 Gbit/s 29% 58 Gbps 1% 2 Gbps

* Az RDMA helyett használjon tömörítést, mert az adatforgalom sávszélesség-Élő áttelepítés < 5 Gb/s.

** Az 50 százalék példa a sávszélesség-foglalásra.

Többszakaszos fürtök

A több adatközpontra is kiterjesztett fürtök vészhelyreállítást biztosítanak. Legegyszerűbb formájában a több Azure Stack HCI fürthálózat így néz ki:

Diagram that shows a stretched cluster.

A többágú fürtre vonatkozó követelmények

A kiterjesztett fürtökre a következő követelmények és jellemzők vonatkoznak:

  • Az RDMA egyetlen webhelyre korlátozódik, és nem támogatott különböző helyeken vagy alhálózatok között.

  • Az azonos helyen található kiszolgálóknak ugyanabban az állványon és 2. rétegben kell lennie.

  • A helyek közötti gazdakommunikációnak a 3. réteg határán kell átesnie; A stretched Layer-2 topológiák nem támogatottak.

  • Elegendő sávszélesség a számítási feladatok másik helyen való futtatásához. Feladatátvétel esetén a másik helynek kell futtatnia az összes forgalmat. Javasoljuk, hogy a rendelkezésre álló hálózati kapacitás 50%-ában létesítsen helyeket. Ez azonban nem követelmény, ha a feladatátvétel során alacsonyabb teljesítményt tud tűrni.

  • A helyek közötti replikáció (északi/déli forgalom) a helyi tárolóval (keleti/nyugati forgalom) azonos fizikai hálózati hálózati tartományvezérlőket használhat. Ha ugyanazon fizikai adaptereket használja, ezeket az adaptereket össze kell állítani a SET-sel. Az adaptereken emellett további virtuális hálózati adaptereket kell kiépíteni a helyek közötti forgalom átirányítása érdekében.

  • A helyek közötti kommunikációhoz használt adapterek:

    • Lehet fizikai vagy virtuális (gazda vNIC). Ha az adapterek virtuálisak, egy vNIC-et kell kiépítenünk a saját alhálózatukon, és a VLAN-t fizikai hálózati adapterenként.

    • A saját alhálózatukon és VLAN-jukon kell lennie, amely képes a helyek közötti útválasztásra.

    • Az RDMA-t le kell tiltani a Disable-NetAdapterRDMA parancsmaggal. Javasoljuk, hogy explicit módon követeli meg Storage replika számára, hogy adott interfészeket használjon a Set-SRNetworkConstraint parancsmag használatával.

    • Meg kell felelnie a replika Storage követelményeinek.

Példa kiterjesztett fürtre

Az alábbi példa egy kiterjesztett fürtkonfigurációt mutat be. Annak biztosításához, hogy egy adott virtuális hálózati adapter egy adott fizikai adapterre legyen leképezve, használja a Set-VMNetworkAdapterTeammapping parancsmagot.

Diagram that shows an example of stretched cluster storage.

Az alábbiakban a példa kiterjesztett fürtkonfiguráció részletei láthatóak.

Megjegyzés

A pontos konfiguráció, beleértve a hálózati adapterek nevét, az IP-címeket és a VLAN-okat, eltérhet a bemutatotttól. Ez csak referenciakonfigurációként használatos, amely az Ön környezetéhez igazított.

SiteA – Helyi replikáció, RDMA engedélyezve, nem átirányítható helyek között

Csomópont neve virtuális hálózat neve Fizikai hálózati adapter (leképezve) VLAN IP és alhálózat Forgalom hatóköre
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Csak helyi hely
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Csak helyi hely
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Csak helyi hely
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Csak helyi hely

B hely – Helyi replikáció, RDMA engedélyezése, nem átirányítható helyek között

Csomópont neve vNIC neve Fizikai hálózati adapter (leképezve) VLAN IP és alhálózat Forgalom hatóköre
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Csak helyi hely
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Csak helyi hely
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Csak helyi hely
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Csak helyi hely

SiteA – Stretched replication, RDMA disabled, routable between sites

Csomópont neve vNIC neve Fizikai hálózati adapter (leképezve) IP és alhálózat Forgalom hatóköre
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Helyközi Routable
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Helyközi Routable
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Helyközi Routable
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Helyközi Routable

SiteB – Stretched replication, RDMA disabled, routable between sites

Csomópont neve vNIC neve Fizikai hálózati adapter (leképezve) IP és alhálózat Forgalom hatóköre
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Helyközi Routable
NodeB2 Stretch1 pNIC01 175.0.0.2/8 Helyközi Routable
NodeB1 Stretch2 pNIC02 176.0.0.1/8 Helyközi Routable
NodeB2 Stretch2 pNIC02 176.0.0.2/8 Helyközi Routable

Következő lépések