Az Azure Stack HCI gazdagéphálózati követelményei

  • Cikk

A következőkre vonatkozik: Azure Stack HCI, 23H2 és 22H2 verzió

Ez a témakör az Azure Stack HCI gazdagéphálózati szempontjait és követelményeit ismerteti. Az adatközpont-architektúrákkal és a kiszolgálók közötti fizikai kapcsolatokkal kapcsolatos információkért lásd: Fizikai hálózati követelmények.

A gazdagépek hálózati ATC-vel történő egyszerűbb hálózatkezeléséről a Gazdagépek hálózatkezelésének egyszerűsítése a hálózati ATC-vel című témakörben olvashat.

Hálózati forgalom típusai

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

  • Felügyeleti forgalom: A helyi fürtre vagy azon kívülről érkező forgalom. Például a tárreplika forgalmát vagy a fürt felügyeletére a rendszergazda által használt forgalmat, például a Távoli asztalt, a Windows Admin Center, 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: Kiszolgálói üzenetblokkot (SMB) használó forgalom, például Közvetlen tárolóhelyek 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" forgalomhoz, hasonlóan a hagyományos fájlmegosztásokhoz.

Hálózati adapter kiválasztása

A hálózati adaptereket a hálózati adatforgalom-típusok (lásd fent) alapján minősítik, amelyek használata támogatott. A Windows Server-katalógus áttekintése során a Windows Server 2022 minősítése most az alábbi szerepkörök közül egy vagy többre utal. Mielőtt megvásárol egy kiszolgálót az Azure Stack HCI-hez, legalább egy olyan adapterrel kell rendelkeznie, amely felügyeletre, számításra és tárolásra alkalmas, mivel az Azure Stack HCI-n mindhárom forgalomtípusra szükség van. 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 ezen a hivatkozáson talál további információt.

Fontos

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

Level Felügyeleti szerepkör Számítási szerepkör Tárolási szerepkör
Szerepköralapú megkülönböztetés Kezelés Compute Standard Storage Standard
Maximális díj Nem alkalmazható Compute Premium Storage Premium

Megjegyzés

Az ökoszisztéma bármely adapterének legmagasabb szintű minősítése tartalmazza a Felügyeleti, a Számítási prémium és a Storage Premium minősítést.

Képernyőkép a

Illesztőprogram-követelmények

A beérkezett üzenetek illesztőprogramjai nem támogatottak az Azure Stack HCI-vel való használathoz. Annak megállapításához, hogy az adapter postaládás illesztőprogramot használ-e, futtassa a következő parancsmagot. Ha a DriverProvider tulajdonság a Microsoft, akkor az adapter egy beérkezett üzenetek illesztőprogramját használja.

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

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

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

  • Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ vagy d.VMMQ)
  • Távoli közvetlen memória-hozzáférés (RDMA)
  • Vendég RDMA
  • Beágyazott összevonás váltása (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 a Switch Embedded Teaming szükséges.

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

Szükséges tanúsítványok: Számítás (Prémium)

A Dinamikus VMMQ egy intelligens, fogadóoldali technológia. A virtuálisgép-üzenetsor (VMQ), a virtuális fogadóoldali 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 processzormag használatával.
  • A hálózati forgalom processzormagokra történő automatikus finomhangolása, ami lehetővé teszi, hogy a virtuális gépek megfeleljenek és fenntartsák a várt átviteli sebességet.
  • Lehetővé teszi, hogy a "megnövekedett" számítási feladatok a várt mennyiségű forgalmat fogadják.

A Dinamikus VMMQ-ról további információt a Szintetikus gyorsítások blogbejegyzésben talál.

RDMA

Az RDMA egy hálózati verem kiszervezése a hálózati adapternek. Lehetővé teszi, hogy az SMB-tároló forgalma 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. 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: gazdagéptároló

Szükséges tanúsítványok: Tárolás (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ég számítási feladatokkal való használatáról a cikk "Vendég RDMA" című szakaszában talál további információt.

Az Azure Stack HCI 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 más RDMA-adapterekkel működnek, amelyek ugyanazt az RDMA protokollt (iWARP vagy RoCE) implementálják.

A szállítóktól származó hálózati adapterek közül nem minden 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ő adapterek megkereséséhez tekintse meg a Windows Server katalógusát .

Megjegyzés

Az InfiniBand (IB) nem támogatott az Azure Stack HCI-ben.

Hálózati adapter szállítója iWARP RoCE
Broadcom Nem Igen
Intel Yes Igen (néhány modell)
Marvell (Qlogic) Igen Yes
Nvidia Nem Igen

Az RDMA gazdagépen 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ésről további információt az SDN GitHub-adattárban talál.

iWARP

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

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 vannak olyan üzemelő példányai, amelyek iWARP-t használnak.
  • 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:

  • Az adatközpontban már vannak roCE-beli üzemelő példányai.
  • 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: Számítás (Prémium)

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

  • Cpu-kiszervezés a hálózati adapterre 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.

Beágyazott összevonás váltása (SET)

A SET egy szoftveralapú összevonási technológia, amely Windows Server 2016 óta szerepel a Windows Server operációs rendszerében. 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, és ugyanabban a csapatban legfeljebb nyolc adapterrel támogatott.

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

Szükséges tanúsítványok: Számítás (Standard) vagy Compute (Prémium)

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

Az Azure Stack HCI nem támogatja a hálózati adapterek összevonását a régebbi terheléselosztással/feladatátvétellel (LBFO). Az Azure Stack HCI-beli LBFO-ról az Azure Stack HCI-ben való összevonásról szóló blogbejegyzésben talál további információt.

A SET az Azure Stack HCI számára fontos, mert ez az egyetlen olyan összevonási technológia, amely lehetővé teszi a következőket:

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, hogy a kiválasztott adapterek aszimmetrikusak-e. Az adapterek szimmetrikus azonosításának legegyszerűbb módja, ha a sebesség és a felület leírása pontos egyezés. Csak a leírásban szereplő 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 listázza.

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

Name Felület leírása Hivatkozás sebessége
NIC1 1. hálózati adapter 25 Gb/s
NIC2 Hálózati adapter #2 25 Gb/s
NIC3 3. hálózati adapter 25 Gb/s
NIC4 Hálózati adapter #4 25 Gb/s

Megjegyzé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 a SET összes szükséges konfigurációját végrehajtja.

RDMA-forgalommal kapcsolatos szempontok

Ha DCB-t implementál, gondoskodnia kell arról, hogy a PFC és az ETS konfigurációja 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-hoz.

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-alapú Azure Stack HCI-implementációkhoz három PFC-forgalomosztályt kell konfigurálni, beleértve az alapértelmezett forgalmi osztályt is a hálón és az összes gazdagépen.

Fürt forgalmi osztálya

Ez a forgalmi osztály biztosítja, hogy elegendő sávszélesség van fenntartva a fürt szívveréséhez:

  • Kötelező: Igen
  • PFC-kompatibilis: Nem
  • Ajánlott forgalom prioritása: 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éget foglaljon le 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. vagy 4. prioritás
  • Ajánlott sávszélesség-foglalás: 50%

Alapértelmezett forgalmi osztály

Ez a forgalmi osztály a fürtben vagy AZ RDMA forgalmi osztályokban nem definiált összes többi forgalmat hordozza, beleértve a virtuális gépek forgalmát é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)-kompatibilis: 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ép-konfigurációra)

Tárolási forgalmi modellek

Az SMB számos előnnyel jár az Azure Stack HCI tárolási protokolljaként, 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 az SMB Multichannel által használható összes lehetséges kapcsolaton a forgalom multiplexált.

Megjegyzés

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

Vegyük az alábbi példát egy négy csomópontos fürtre. Minden kiszolgáló két tárolóportot (bal és jobb oldalt) biztosít. Mivel minden adapter ugyanazon az alhálózaton és VLAN-on található, az SMB Többcsatornás rendszer az összes elérhető kapcsolat között elosztja a kapcsolatokat. Ezért az első kiszolgáló bal oldali portja (192.168.1.1) kapcsolatot létesít a második kiszolgálón lévő bal oldali porttal (192.168.1.2). Az első kiszolgálón lévő jobb oldali port (192.168.1.12) a második kiszolgálón lévő jobb oldali porthoz csatlakozik. Hasonló kapcsolatok jönnek létre a harmadik és negyedik kiszolgálókhoz.

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öbbvázlatos kapcsolati aggregációs csoport vagy MC-LAG) kapcsolatnál. Tekintse meg a következő ábrát:

Egy négycsomópontos fürtöt ábrázoló diagram ugyanazon az alhálózaton.

Az ajánlott módszer a különálló alhálózatok és VLAN-k használata minden adapterkészlethez. 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 fürtöt jelenít meg a különböző alhálózatokon.

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

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

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 kell kezelni, nem pedig támogatási követelménynek.

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

  • Csapatonként két adapter van.

  • Storage Bus Layer (SBL), fürt megosztott kötete (CSV) és Hyper-V (élő migrálás) forgalom:

    • Használja ugyanazokat a fizikai adaptereket.
    • Használja az SMB-t.

  • Az SMB 50 százalékos 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%-á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%-á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, a tömörítéssel csökkentheti az áramkimaradás idejé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 másodpercenként bájtban (Bps) veszi fel a bejegyzést, míg a hálózati adapterek bit/másodpercben (bps) 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

    Megjegyzés

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

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

Hálózati adapter sebessége Csoportosított sávszélesség SMB-sávszélesség-foglalás** SBL/CSV % SBL/CSV sávszélesség Élő áttelepítés %- Maximális élő áttelepítési sávszélesség Szívverés %-a Szívverés sávszélessége
10 Gbps 20 Gb/s 10 Gbps 70% 7 Gb/s ** 200 Mbit/s
25 Gb/s 50 Gb/s 25 Gb/s 70% 17,5 Gb/s 29% 7,25 Gb/s 1% 250 Mbps
40 Gbps 80 Gb/s 40 Gbps 70% 28 Gb/s 29% 11,6 Gb/s 1% 400 Mbps
50 Gb/s 100 Gbps 50 Gb/s 70% 35 Gb/s 29% 14,5 Gb/s 1% 500 Mbit/s
100 Gbps 200 Gbit/s 100 Gbps 70% 70 Gb/s 29% 29 Gb/s 1% 1 Gbps
200 Gbit/s 400 Gb/s 200 Gbit/s 70% 140 Gb/s 29% 58 Gb/s 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.

Kinyújtott fürtök

A kinyújtott fürtök több adatközpontra kiterjedő vészhelyreállítást biztosítanak. A legegyszerűbb formájában egy kinyújtott Azure Stack HCI-fürthálózat a következőképpen néz ki:

Egy kinyújtott fürtöt ábrázoló diagram.

Rugalmas fürtkövetelmények

A kinyújtott fürtök a következő követelményekkel és jellemzőkkel rendelkeznek:

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

  • Az ugyanazon a helyen található kiszolgálóknak ugyanabban az állványban és 2. rétegbeli határban kell elhelyezkedniük.

  • A helyek közötti gazdagép-kommunikációnak át kell haladnia egy 3. rétegbeli határt; A stretched Layer-2 topológiák nem támogatottak.

  • Elegendő sávszélességet biztosít a számítási feladatok másik helyen való futtatásához. Feladatátvétel esetén a másik helynek minden forgalmat le kell futtatnia. Javasoljuk, hogy a rendelkezésre álló hálózati kapacitás 50 százalékában építse ki a helyeket. Ez azonban nem követelmény, ha képes elviselni az alacsonyabb teljesítményt a feladatátvétel során.

  • A helyek közötti replikáció (északi/déli forgalom) ugyanazokat a fizikai hálózati adaptereket használhatja, mint a helyi tároló (keleti/nyugati forgalom). Ha ugyanazokat a fizikai adaptereket használja, ezeket az adaptereket a SET szolgáltatással kell összehozni. Az adaptereknek további virtuális hálózati adaptereket is ki kell építeniük a helyek közötti forgalom számára.

  • 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 ki kell építenie a saját alhálózatában, a VLAN-t pedig fizikai hálózati adapterenként.

    • A helyek közötti útválasztáshoz a saját alhálózatukon és VLAN-jukon kell lenniük.

    • Az RDMA-t le kell tiltani a Disable-NetAdapterRDMA parancsmag használatával. Azt javasoljuk, hogy a parancsmag használatával kifejezetten megkövetelje a tárreplika számára, Set-SRNetworkConstraint hogy adott interfészeket használjon.

    • Meg kell felelnie a tárreplika további követelményeinek.

Stretched cluster example

Az alábbi példa egy rugalmas fürtkonfigurációt mutat be. Annak érdekében, hogy egy adott virtuális hálózati adapter egy adott fizikai adapterhez legyen leképezve, használja a Set-VMNetworkAdapterTeammapping parancsmagot.

A rugalmas fürttárolót bemutató ábra.

Az alábbiakban a példaként használt kiterjesztett fürtkonfiguráció részleteit mutatjuk be.

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 megjelenített konfigurációtól. Ez csak referenciakonfigurációként használható, amely a környezethez igazítható.

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

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

SiteB – Helyi replikáció, RDMA engedélyezve, nem módosítható a helyek között

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

SiteA – Elosztott replikáció, RDMA le van tiltva, a helyek között nem érhető el

Csomópont neve virtuális hálózati adapter neve Fizikai hálózati adapter (leképezve) IP-cím és alhálózat Forgalom hatóköre
NodeA1 1. szakasz pNIC01 173.0.0.1/8 Helyek közötti routable
NodeA2 1. szakasz pNIC01 173.0.0.2/8 Többhelyes irányítható
NodeA1 2. szakasz pNIC02 174.0.0.1/8 Többhelyes irányítható
NodeA2 2. szakasz pNIC02 174.0.0.2/8 Többhelyes irányítható

SiteB – Többhelyes replikáció, RDMA le van tiltva, a helyek között irányítható

Csomópont neve virtuális hálózati adapter neve Fizikai hálózati adapter (leképezve) IP és alhálózat Forgalom hatóköre
NodeB1 1. szakasz pNIC01 175.0.0.1/8 Többhelyes irányítható
NodeB2 1. szakasz pNIC01 175.0.0.2/8 Többhelyes irányítható
NodeB1 2. szakasz pNIC02 176.0.0.1/8 Többhelyes irányítható
NodeB2 2. szakasz pNIC02 176.0.0.2/8 Többhelyes irányítható

Következő lépések