Megosztás a következőn keresztül:

Az Azure Local hálózati követelményei

  • Cikk

A következőkre vonatkozik: Azure Local 2311.2 és újabb verziók

Ez a témakör az Azure helyi gazdagép-hálózatkezelési szempontjait és követelményeit ismerteti. Az adatközpont-architektúrákról és a gépek közötti fizikai kapcsolatokról további információt a Fizikai hálózati követelmények című témakörben talál.

A gazdagépek hálózatkezelésének a hálózati ATC használatával történő egyszerűsítéséről további információt a Gazdagépek hálózatkezelésének egyszerűsítése a hálózati ATC-vel című témakörben talál.

Hálózati forgalomtípusok

Az Azure Helyi hálózati forgalom a rendeltetése szerint besorolható:

  • Felügyeleti forgalom: A helyi rendszer felé vagy kívülről érkező forgalom. Például a tárreplika forgalmát vagy a rendszergazda által a rendszer felügyeletéhez használt forgalmat, például a Távoli asztalt, a Windows Felügyeleti központot, az Active Directoryt stb.
  • Számítási forgalom: Virtuális gépről vagy virtuális gépre irányuló forgalom.
  • Tárolási forgalom: A kiszolgálói üzenetblokkot (SMB) használó forgalom, például Tárolóhelyek közvetlen vagy SMB-alapú élő áttelepítés. Ez a forgalom 2. rétegbeli forgalom, és nem irányítható.

Fontos

A tárreplika nem RDMA-alapú SMB-forgalmat használ. Ez és a forgalom iránya (Észak-Dél) szorosan igazodik a fent felsorolt "felügyeleti" forgaloméhoz, hasonlóan a hagyományos fájlmegosztáséhoz.

Hálózati adapter kiválasztása

A hálózati adaptereket azok a hálózati forgalomtípusok minősítik (lásd fent), amelyek használata támogatott. A Windows Server-katalógus áttekintése során a Windows Server 2022 minősítés most az alábbi szerepkörök egyikére vagy többre utal. Mielőtt megvásárol egy gépet az Azure Local-hoz, legalább egy olyan adapterrel kell rendelkeznie, amely felügyeletre, számításra és tárolásra alkalmas, mivel mind a három forgalmi típusra szükség van az Azure Local-on. Ezután a hálózati ATC használatával konfigurálhatja az adaptereket a megfelelő forgalomtípusokhoz.

A szerepköralapú hálózati adapterek minősítéséről további információt ebben a Windows Server-blogbejegyzésben talál.

Fontos

A minősített forgalmi típuson kívüli adapter használata nem támogatott.

Szint Felügyeleti szerepkör Számítási szerepkör Tárolási szerepkör
Szerepköralapú megkülönböztetés Menedzsment Számítási Standard Tárolási Szabvány
Maximális díj Nem alkalmazható Compute Premium Prémium szintű tárterület

Feljegyzés

Az ökoszisztémánk bármely adapterének legmagasabb szintű minősítése tartalmazza a Felügyeleti, a Compute Premium és a Storage Premium minősítéseket.

Képernyőkép a

Illesztőprogram-követelmények

A beérkezett üzenetek illesztőprogramjai nem támogatottak az Azure Local használatához. Annak megállapításához, hogy az adapter postaládás illesztőprogramot használ-e, futtassa az alábbi parancsmagot. Az adapter egy beérkezett üzenetek illesztőprogramot használ, ha a DriverProvider tulajdonság a Microsoft.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

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

Az Azure Local által használt fontos hálózati adapter-képességek a következők:

  • Dinamikus virtuális gép többsoros várakozási sor kezelő (dinamikus VMMQ vagy d.VMMQ)
  • Távoli közvetlen memóriahozzáférés (RDMA)
  • Vendég RDMA
  • Beágyazott csapatozás kapcsoló (SET)

Dinamikus VMMQ

A Compute (Premium) minősítéssel rendelkező összes hálózati adapter támogatja a dinamikus VMMQ-t. A dinamikus VMMQ használatához szükség van a Switch Embedded Teaming használatára.

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

Szükséges tanúsítványok: Compute (Premium)

A dinamikus VMMQ egy intelligens, fogadóoldali technológia. A virtuális gép sor (VMQ), a virtuális fogadási oldal skálázás (vRSS) és a VMMQ elődjeire épül, hogy három elsődleges fejlesztést biztosítson:

  • Optimalizálja a gazdagép hatékonyságát kevesebb processzormagot használva.
  • A hálózati forgalom feldolgozásának automatikus finomhangolása processzormagokra, így lehetővé teszi a virtuális gépek számára a várt átviteli sebesség teljesítését és fenntartását.
  • Lehetővé teszi a hirtelen megugró terhelések számára a várt forgalom fogadását.

A dinamikus VMMQ-ról további információt a szintetikus gyorsításokat ismertető blogbejegyzésben talál.

RDMA

Az RDMA a hálózati verem átvitele a hálózati adapterre. Lehetővé teszi, hogy az SMB-tárolóforgalom megkerülje az operációs rendszert feldolgozás céljából.

Az RDMA lehetővé teszi a nagy átviteli sebességet és az alacsony késésű hálózatkezelést minimális gazda CPU-erőforrások használatával. További virtuális gépek vagy tárolók futtatására lehet használni ezeket a gazdagép CPU-erőforrásait.

Alkalmazható forgalomtípusok: gazdagéptároló

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

A Storage (Standard) vagy a Storage (Premium) minősítéssel rendelkező összes adapter támogatja a gazdagépoldali RDMA-t. Az RDMA vendégterhelésekkel való használatáról a jelen cikk későbbi, "Vendég RDMA" szakaszában olvashat bővebben.

Az Azure Local támogatja az RDMA-t az Internet Wide Area RDMA Protocol (iWARP) vagy az RDMA over Converged Ethernet (RoCE) protokoll implementációival.

Fontos

Az RDMA-adapterek csak olyan RDMA-adapterekkel működnek, amelyek ugyanazt az RDMA protokollt implementálják (iWARP vagy RoCE).

Nem minden gyártó hálózati adaptere támogatja az RDMA-t. Az alábbi táblázat felsorolja azokat a szállítókat (betűrendben), amelyek minősített RDMA-adaptereket kínálnak. Vannak azonban olyan hardvergyártók, amelyek nem szerepelnek ebben a listában, amelyek szintén támogatják az RDMA-t. Az RDMA-támogatást igénylő Storage (Standard) vagy Storage (Premium) minősítéssel rendelkező adaptereket a Windows Server katalógusában találja.

Feljegyzés

Az InfiniBand (IB) nem támogatott az Azure Local szolgáltatásban.

NIC beszállító iWARP RoCE
Broadcom Nem Igen
Intel Igen Igen (néhány modell)
Marvell (Qlogic) Igen Igen
Nvidia Nem Igen

Az RDMA gazdagéphez való üzembe helyezésével kapcsolatos további információkért javasoljuk, hogy használja a hálózati ATC-t. A manuális üzembe helyezéssel kapcsolatos információkért lásd az SDN GitHub-adattárat.

iWARP

Az iWARP a Transmission Control Protocol (TCP) protokollt használja, és igény szerint bővíthető prioritásalapú folyamatvezérléssel (PFC) és továbbfejlesztett átviteli szolgáltatással (ETS).

Használja az iWARP-t, ha:

  • Nincs tapasztalata az RDMA-hálózatok kezelésében.
  • Nem kezeli vagy kényelmetlenül kezeli a top-of-rack (ToR) kapcsolókat.
  • Az üzembe helyezés után nem fogja felügyelni a megoldást.
  • Már rendelkezik iWARP-t használó üzembe helyezésekkel.
  • Nem biztos benne, hogy melyik lehetőséget válassza.

RoCE

A RoCE a User Datagram Protocol (UDP) protokollt használja, és megköveteli a PFC-t és az ETS-t a megbízhatóság biztosításához.

Használja a RoCE-t, ha:

  • Ön már rendelkezik RoCE-vel történő üzembe helyezésekkel az adatközpontban.
  • Kényelmesen kezelheti a DCB hálózati követelményeit.

Vendég RDMA

A vendég RDMA lehetővé teszi, hogy a virtuális gépek SMB-számítási feladatai ugyanazokat az előnyöket élvezik, mint az RDMA használata a gazdagépeken.

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

Szükséges tanúsítványok: Compute (Premium)

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

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

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

Beágyazott Hálózati Összevonás (SET)

A SET egy szoftveralapú összevonási technológia, amely a Windows Server operációs rendszer részét képezi a Windows Server 2016 óta. A SET az azure local által támogatott egyetlen csapatozási technológia. A SET jól működik a számítási, tárolási és felügyeleti forgalommal, és akár nyolc adapterrel is támogatott ugyanabban a csapatban.

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

Szükséges tanúsítványok: Compute (Standard) vagy Compute (Premium)

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

Fontos

Az Azure Local nem támogatja a hálózati adapterek összevonását a régebbi terheléselosztással/feladatátvétellel (LBFO). Az LBFO-ról az Azure Local-ban további információért lásd a Teaming in Azure Local című blogbejegyzést.

A SET azért fontos az Azure Local számára, mert ez az egyetlen olyan összevonási technológia, amely lehetővé teszi:

SET esetén követelmény a szimmetrikus (azonos) adapterek használata. Szimmetrikus hálózati adapterek azok, amelyeknél megegyeznek a következők:

  • gyártmány (szállító)
  • modell (verzió)
  • sebesség (teljesítmény)
  • konfiguráció

22H2-ben a hálózati ATC automatikusan észleli és tájékoztatja, ha a kiválasztott adapterek aszimmetrikusak. Az adapterek szimmetrikus voltának manuális azonosításának legegyszerűbb módja az, ha a sebességek és a felület leírásai pontos egyezést mutatnak. Csak a leírásban felsorolt számban térhetnek el. Get-NetAdapterAdvancedProperty A parancsmaggal győződjön meg arról, hogy a jelentett konfiguráció ugyanazokat a tulajdonságértékeket sorolja fel.

Az alábbi táblázatban a csak számokkal (#) eltérő felületleírásokra talál példát:

Név Felület leírása Csatolás sebessége
NIC1 Hálózati adapter #1 25 Gbps
NIC2 Hálózati adapter #2 25 Gbps
NIC3 Hálózati adapter #3 25 Gb/s
NIC4 Hálózati adapter #4 25 Gbps

Feljegyzés

A SET csak a kapcsoló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. A hálózati ATC minden szükséges konfigurációt végrehajt a SET-hez.

RDMA-forgalommal kapcsolatos szempontok

Ha DCB-t implementál, gondoskodnia kell arról, hogy a PFC és az ETS konfiguráció megfelelően legyen implementálva minden hálózati porton, beleértve a hálózati kapcsolókat is. A DCB szükséges a RoCE-hoz, és nem kötelező az iWARP-hez.

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

RoCE-alapú Azure Local-implementációkhoz három PFC forgalmi osztályt kell konfigurálni, beleértve az alapértelmezett forgalmi osztályt is a hálózati szöveten és az összes gazdagépen.

Rendszerforgalmi osztály

Ez a forgalmi osztály biztosítja, hogy elegendő sávszélesség van fenntartva a rendszer szívveréseihez:

  • Kötelező: Igen
  • PFC-kompatibilis: Nem
  • Ajánlott forgalmi prioritás: 7. 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 forgalmi osztály biztosítja, hogy elegendő sávszélesség áll rendelkezésre a veszteségmentes RDMA-kommunikációhoz az SMB Direct használatával:

  • Kötelező: Igen
  • PFC-kompatibilis: Igen
  • Ajánlott forgalmi prioritás: 3. vagy 4. prioritás
  • Ajánlott sávszélesség-foglalás: 50 százalék

Alapértelmezett forgalmi osztály

Ez a forgalmi osztály a rendszer- vagy RDMA-forgalmi osztályokban nem definiált összes többi forgalmat hordozza, beleértve a virtuálisgép-forgalmat és a felügyeleti forgalmat:

  • Kötelező: Alapértelmezés szerint (nincs szükség konfigurációra a gazdagépen)
  • Folyamatvezérlés (PFC) engedélyezve: Nem
  • Ajánlott forgalmi osztály: Alapértelmezés szerint (0. prioritás)
  • Ajánlott sávszélesség-foglalás: Alapértelmezés szerint (nincs szükség gazdagépkonfigurációra)

Tárolási forgalmi modellek

Az SMB számos előnnyel jár, mint az Azure Local tárolási protokollja, beleértve az SMB Multichannelt is. A többcsatornás SMB-ről ebben a cikkben nem olvashat, de fontos tisztában lenni azzal, hogy a forgalom multiplexált minden lehetséges hivatkozáson, amelyet az SMB Multichannel használhat.

Megjegyzés

Javasoljuk, hogy több alhálózatot és VLAN-t használjon a tárolási forgalom elkülönítéséhez az Azure Local-ban.

Tekintse meg a következő példát egy négy csomópontos rendszerre. Minden gép két tárolóportot (bal és jobb oldalt) használ. Mivel minden adapter ugyanazon az alhálózaton és VLAN-on található, az SMB Többcsatornás rendszer az összes elérhető hivatkozás között elosztja a kapcsolatokat. Ezért az első gép bal oldali portja (192.168.1.1) kapcsolatot létesít a második gépen lévő bal oldali porttal (192.168.1.2). Az első gép jobb oldali portja (192.168.1.12) a második gép jobb oldali portjához csatlakozik. A harmadik és negyedik géphez hasonló kapcsolatok jönnek létre.

Ez azonban szükségtelen kapcsolatokat hoz létre, és torlódást okoz a ToR kapcsolókat (X-ekkel megjelölt) összekötő MC-LAG (többvázú kapcsolat aggregációs csoport) kapcsolatnál. Tekintse meg a következő ábrát:

Egy négycsomópontos rendszert ábrázoló ábra ugyanazon az alhálózaton.

Az ajánlott módszer az, hogy minden egyes adaptercsoporthoz külön alhálózatokat és VLAN-okat használjon. Az alábbi ábrán a jobb oldali portok mostantól a 192.168.2.x /24 és a VLAN2 alhálózatot használják. Ez lehetővé teszi, hogy a bal oldali portok forgalma a TOR1-en maradjon, a jobb oldali portok forgalma pedig a TOR2-n maradjon.

Diagram, amely egy négycsomópontos rendszert mutat be a különböző alhálózatokon.

Forgalom sávszélességének lefoglalása

Az alábbi táblázat a különböző forgalomtípusok sávszélesség-kiosztását mutatja be gyakori adaptersebességek használatával az Azure Local-ban. Vegye figyelembe, hogy ez egy konvergens megoldás példája, ahol az összes forgalomtípus (számítás, tárolás és felügyelet) ugyanazon fizikai adaptereken fut, és a SET használatával vannak csoportosítva.

Mivel ez a használati eset jelenti a legtöbb korlátozást, jó alapkonfigurációt jelent. Figyelembe véve azonban az adapterek és a sebességek számának permutációit, ezt példaként és nem támogatási követelménynek kell tekinteni.

A példához a következő feltételezések tartoznak:

  • Csapatonként két adapter található.

  • Storage Bus Layer (SBL), fürtmegosztott kötet (CSV) és Hyper-V (Live Migration) forgalom:

    • Használja ugyanazokat a fizikai adaptereket.
    • SMB használata.

  • Az SMB 50%-os sávszélesség-kiosztá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 százalékát kapja meg.
    • Az élő áttelepítés (LM) a Set-SMBBandwidthLimit parancsmag használatával korlátozott, és a fennmaradó sávszélesség 29 százalékát kapja meg.

      • Ha az élő áttelepítéshez >rendelkezésre álló sávszélesség = 5 Gb/s, és a hálózati adapterek képesek, használja az RDMA-t. Ehhez használja a következő parancsmagot:

        Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

      • Ha az élő áttelepítéshez < rendelkezésre álló sávszélesség 5 Gb/s, tömörítéssel csökkentheti az áramkimaradási időt. Ehhez használja a következő parancsmagot:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

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

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

    Feljegyzés

    Ebben a példában a 750 MBps 6 Gb/s-nak felel meg.

Íme a példa sávszélesség-foglalási táblára:

Hálózati kártya sebessége Csoportos sávszélesség SMB sávszélesség-foglalás** SBL/CSV % SBL/CSV sávszélesség Élő áttelepítés % Élő áttelepítés maximális sávszélessége Szívverés %-a Szívverés sávszélessége
10 Gbit/s 20 Gbps 10 Gbit/s 70% 7 Gbps * 200 Mbit/s
25 Gbps 50 Gbps 25 Gbps 70% 17,5 Gb/s 29% 7,25 Gbps 1% 250 Mb/s
40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11,6 Gb/s 1% 400 Mb/s
50 Gbps 100 Gbit/s 50 Gbps 70% 35 Gbps 29% 14,5 Gb/s 1% 500 Mbit/s
100 Gbit/s 200 Gbit/s 100 Gbit/s 70% 70 Gbps 29% 29 Gbps 1% 1 Gbps
200 Gbit/s 400 Gbps 200 Gbit/s 70% 140 Gbps 29% 58 Gbps 1% 2 Gbps

* Használjon tömörítést RDMA helyett, mert az élő áttelepítési forgalom sávszélesség-kiosztása <5 Gb/s.

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

Tágított klaszterek

A kiterjesztett fürtök több adatközpontot átfogó katasztrófa-helyreállítást biztosítanak. Legegyszerűbb formájában az Azure Local egy kinyújtott fürtje így néz ki:

Kifeszített fürtöt ábrázoló diagram.

Kiterjesztett fürtkövetelmények

Fontos

A kiterjesztett fürtfunkciók csak az Azure Local 22H2-es verziójában érhetők el.

A feszített fürtök a következő követelményekkel és jellemzőkkel rendelkeznek:

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

  • Az ugyanazon a helyen lévő gépeknek ugyanabban az állványban és 2. rétegbeli határban kell lenniük.

  • A helyek közötti gazdagép-kommunikációnak át kell haladnia a 3. réteghatáron; a kiterjesztett Layer-2 topológiák nem támogatottak.

  • Elegendő sávszélességet biztosít a számítási feladatok futtatásához a másik helyen. Feladatátvétel esetén a tartalék helyszínnek minden forgalmat kezelnie kell. Javasoljuk, hogy a helyszíneket a rendelkezésre álló hálózati kapacitás 50 százalékának kihasználásával építse ki. Ez azonban nem követelmény, ha el tudja viselni az alacsonyabb teljesítményt a feladatátvétel során.

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

    • Lehet fizikai vagy virtuális (gazdagép vNIC). Ha az adapterek virtuálisak, egy virtuális hálózati adaptert kell kiépnie a saját alhálózatában, a VLAN-t pedig fizikai hálózati adapterenként.

    • A saját alhálózaton és VLAN-on kell lenniük, amelyek képesek az útválasztásra a helyek között.

    • Az RDMA-t le kell tiltani a Disable-NetAdapterRDMA parancsmag használatával. Javasoljuk, hogy a Set-SRNetworkConstraint parancsmag használatával kifejezetten előírja a Storage Replica számára bizonyos interfészek használatát.

    • Meg kell felelnie a tárolóreplika további követelményeinek.

Következő lépések