Azure Stack HCI gazdagép hálózati követelményeiHost network requirements for Azure Stack HCI

A következőre vonatkozik Azure Stack HCI, Version 20H2Applies to Azure Stack HCI, version 20H2

Ez a témakör Azure Stack HCI-gazdagép hálózatkezelési szempontjait és követelményeit tárgyalja.This topic discusses Azure Stack HCI host networking considerations and requirements. 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.For information on data center architectures and the physical connections between servers, see Physical network requirements.

Hálózati forgalom típusaiNetwork traffic types

Azure Stack a HCI hálózati forgalmat a kívánt céllal lehet osztályozni:Azure Stack HCI network traffic can be classified by its intended purpose:

  • Számítási forgalom – virtuális GÉPHEZ (VM) származó vagy oda irányuló forgalomCompute traffic - traffic originating from or destined for a virtual machine (VM)
  • Tárolási forgalom – közvetlen TÁROLÓHELYEK (S2D) forgalma a Server Message Block (SMB) használatávalStorage traffic - traffic for Storage Spaces Direct (S2D) using Server Message Block (SMB)
  • Felügyeleti forgalom – a rendszergazdák számára fontos a fürtözési felügyelet, például a Active Directory, a távoli asztal, a Windows felügyeleti központ és a Windows PowerShell.Management traffic - traffic important to an administrator for cluster management, such as Active Directory, Remote Desktop, Windows Admin Center, and Windows PowerShell.

Hálózati adapter kiválasztásaSelecting a network adapter

Azure Stack HCI esetén olyan hálózati adaptert kell választani, amely a Windows Server Software-Defined adatközpont (SDDC) minősítését a standard vagy prémium szintű kiegészítő minősítéssel (AQ) valósította meg.For Azure Stack HCI, we require choosing a network adapter that has achieved the Windows Server Software-Defined Data Center (SDDC) certification with the Standard or Premium Additional Qualification (AQ). Ezek az adapterek támogatják a platform legfejlettebb funkcióit, és a hardveres partnereink általi tesztelésen estek át.These adapters support the most advanced platform features and have undergone the most testing by our hardware partners. Ez a vizsgálati szint általában a hardver és az illesztőprogrammal kapcsolatos minőségi problémák csökkenését eredményezi.Typically, this level of scrutiny leads to a reduction in hardware and driver-related quality issues.

A standard vagy prémium AQ-vel rendelkező adapterek azonosításához tekintse át az adapterhez tartozó Windows Server Catalog bejegyzést, valamint az operációs rendszer megfelelő verzióját.You can identify an adapter that has Standard or Premium AQ by reviewing the Windows Server Catalog entry for the adapter and the applicable operating system version. Alább látható egy példa a prémium AQ jelölésére:Below is an example of the notation for Premium AQ:

Windows Certified

A legfontosabb hálózati adapterek képességeinek áttekintéseOverview of key network adapter capabilities

Azure Stack HCI által kihasznált hálózati adapterek fontos funkciói a következők:Important network adapter capabilities leveraged by Azure Stack HCI include:

  • Dinamikus virtuális gép – több várólista (dinamikus VMMQ vagy d. VMMQ)Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ or d.VMMQ)
  • Távoli közvetlen memória-hozzáférés (RDMA)Remote Direct Memory Access (RDMA)
  • Vendég RDMAGuest RDMA
  • Beágyazott összevonás (SET) váltásaSwitch Embedded Teaming (SET)

Dinamikus VMMQDynamic VMMQ

A prémium AQ-vel rendelkező összes hálózati adapter támogatja a dinamikus VMMQ.All network adapters with the Premium AQ support Dynamic VMMQ. A dinamikus VMMQ a Switch beágyazott összevonásának használatát igényli.Dynamic VMMQ requires the use of Switch Embedded Teaming.

Alkalmazható adatforgalmi típusok: számításApplicable traffic types: compute

Szükséges minősítések: prémiumCertifications required: Premium

A dinamikus VMMQ olyan intelligens fogadási technológia, amely a virtuálisgép-várólista (VMQ), a virtuális fogadó oldali skálázás (vRSS) és a VMMQ három fő újításának előállítására épül:Dynamic VMMQ is an intelligent receive-side technology that builds upon its predecessors of Virtual Machine Queue (VMQ), Virtual Receive Side Scaling (vRSS), and VMMQ to provide three primary improvements:

  • Optimalizálja a gazdagép hatékonyságát a CPU-magok használatávalOptimizes host efficiency by use of CPU cores
  • A hálózati forgalom feldolgozásának automatikus finomhangolása a CPU-magokon, így lehetővé téve a virtuális gépek számára a várt átviteli sebesség teljesítését és karbantartásátAutomatic tuning of network traffic processing to CPU cores, thus enabling VMs to meet and maintain expected throughput
  • Engedélyezi a "feltört" számítási feladatokat, hogy megkapják a forgalom várható mennyiségétEnables “bursty” workloads to receive the expected amount of traffic

A dinamikus VMMQ kapcsolatos további információkért tekintse meg a szintetikus gyorsításokutáni blogbejegyzést.For more information on Dynamic VMMQ, see the blog post Synthetic Accelerations.

RDMARDMA

A RDMA egy hálózati verem, amely lehetővé teszi, hogy a hálózati adapter az SMB-tároló forgalmát az operációs rendszer kihagyása céljából dolgozza fel.RDMA is a network stack offload to the network adapter allowing SMB storage traffic to bypass the operating system for processing.

A RDMA lehetővé teszi a nagy átviteli sebességű, kis késleltetésű hálózatkezelést a minimális gazda CPU-erőforrások használata mellett.RDMA enables high-throughput, low-latency networking while using minimal host CPU resources. Ezek a gazda CPU-erőforrások később további virtuális gépek vagy tárolók futtatására is használhatók.These host CPU resources can then be used to run additional VMs or containers.

Alkalmazható adatforgalmi típusok: gazdagép tárterületeApplicable traffic types: host storage

Szükséges minősítések: standardCertifications required: Standard

A standard vagy prémium AQ-vel rendelkező összes adapter támogatja a RDMA (távoli közvetlen memória-hozzáférés).All adapters with Standard or Premium AQ support RDMA (Remote Direct Memory Access). A RDMA ajánlott üzembe helyezési lehetőség a Azure Stack HCI-ben tárolt tárolási feladatokhoz, és opcionálisan engedélyezhető a virtuális gépekhez használható tárolási feladatokhoz (SMB használatával).RDMA is the recommended deployment choice for storage workloads in Azure Stack HCI and can be optionally enabled for storage workloads (using SMB) for VMs. Tekintse meg a vendég RDMA szakaszt később.See the Guest RDMA section later.

Azure Stack HCI támogatja a RDMA a iWARP vagy a RoCE protokoll implementációjának használatával.Azure Stack HCI supports RDMA using either the iWARP or RoCE protocol implementations.

Fontos

A RDMA-adapterek csak olyan más RDMA-adapterekkel működnek, amelyek ugyanazt a RDMA protokollt (iWARP vagy RoCE) implementálják.RDMA adapters only work with other RDMA adapters that implement the same RDMA protocol (iWARP or RoCE).

A szállítók nem minden hálózati adaptere támogatja a RDMA.Not all network adapters from vendors support RDMA. A következő táblázat felsorolja azokat a szállítókat (betűrendben), amelyek prémium szintű tanúsítvánnyal rendelkező RDMA-adaptereket kínálnak.The following table lists those vendors (in alphabetical order) that offer Premium certified RDMA adapters. Vannak azonban olyan hardvergyártók, amelyek nem szerepelnek a listán, és a RDMA is támogatják.However, there are hardware vendors not included in this list that also support RDMA. A RDMA támogatásának ellenőrzéséhez tekintse meg a Windows Server catalogt .See the Windows Server Catalog to verify RDMA support.

Megjegyzés

A InfiniBand (IB) Azure Stack HCI esetében nem támogatott.InfiniBand (IB) is not supported with Azure Stack HCI.

NIC-szállítóNIC vendor iWARPiWARP RoCERoCE
BroadcomBroadcom NemNo IgenYes
ChelsioChelsio IgenYes NemNo
IntelIntel IgenYes Igen (egyes modellek)Yes (some models)
Marvell (Qlogic/Cavium)Marvell (Qlogic/Cavium) IgenYes IgenYes
NVIDIA (Mellanox)Nvidia (Mellanox) NemNo IgenYes

Megjegyzés

A szállítók nem minden adapter támogatja a RDMA.Not all adapters from the vendors support RDMA. Ellenőrizze, hogy a RDMA-támogatás megfelel-e az adott hálózati kártya gyártójával.Please verify RDMA support with your specific network card vendor.

A RDMA telepítésével kapcsolatos további információkért töltse le a Word Doc alkalmazást az Sdn GitHub-adattárból.For more information on deploying RDMA, download the Word doc from the SDN GitHub repo.

Internetes nagykiterjedésű RDMA protokoll (iWARP)Internet Wide Area RDMA Protocol (iWARP)

a iWARP a Transmission Control Protocol (TCP) protokollt használja, és opcionálisan kibővíthető az adatközpont-áthidalás (DCB) prioritáson alapuló Flow Control (PFC) és a bővített átviteli szolgáltatás (ETS) használatával.iWARP uses the Transmission Control Protocol (TCP), and can be optionally enhanced with Data Center Bridging (DCB) Priority-based Flow Control (PFC) and Enhanced Transmission Service (ETS).

Javasoljuk, hogy a iWARP a következőket használja:We recommend that you use iWARP if:

  • Kevés vagy semmilyen hálózati élmény van, vagy kényelmetlen a hálózati kapcsolók kezelése.You have little or no network experience or are uncomfortable managing network switches
  • Nem szabályozza a ToR-kapcsolókatYou do not control your ToR switches
  • Az üzembe helyezést követően nem fogja kezelni a megoldástYou will not be managing the solution after deployment
  • Már rendelkezik üzemelő példányokkal a iWARP használatávalYou already have deployments using iWARP
  • Nem biztos benne, hogy melyik lehetőséget kell választaniaYou are unsure which option to choose

RDMA konvergált Etherneten (RoCE)RDMA over Converged Ethernet (RoCE)

A RoCE a User Datagram Protocol (UDP) protokollt használja, és megköveteli, hogy az adatközpont-áthidalás a PFC és az ETS használatával biztosítson megbízhatóságot.RoCE uses User Datagram Protocol (UDP), and requires Data Center Bridging PFC and ETS to provide reliability.

Javasoljuk, hogy a RoCE a következőket használja:We recommend that you use RoCE if:

  • Már rendelkezik a RoCE-vel rendelkező üzemelő példányokkal az adatközpontbanYou already have deployments with RoCE in your data center
  • Ön ismeri a fizikai hálózati követelményeketYou are knowledgeable with your physical network requirements

Vendég RDMAGuest RDMA

A vendég RDMA lehetővé teszi az SMB-munkaterhelések számára a virtuális gépek számára, hogy ugyanazokat az előnyöket használják a gazdagépeken a RDMA használatával.Guest RDMA enables SMB workloads for VMs to gain the same benefits of using RDMA on hosts.

Alkalmazható adatforgalmi típusok: számításApplicable traffic types: compute

Szükséges minősítések: prémiumCertifications required: Premium

A vendég RDMA használatának elsődleges előnyei a következők:The primary benefits of using Guest RDMA are:

  • A hálózati forgalom feldolgozására szolgáló hálózati ADAPTERre történő kiszervezésCPU offload to the NIC for network traffic processing
  • Rendkívül alacsony késésExtremely low latency
  • Nagy átviteli sebességHigh throughput

A vendég RDMA üzembe helyezésével kapcsolatos további információkért töltse le a Word Doc-ját az Sdn GitHub-adattárból.For more information including how to deploy Guest RDMA, download the Word doc from the SDN GitHub repo.

Beágyazott összevonás (SET) váltásaSwitch Embedded Teaming (SET)

A Switch Embedded Teaming (SET) egy szoftveres összevonási technológia, amelyet a Windows Server operációs rendszer a Windows Server 2016 óta tartalmaz.Switch Embedded Teaming (SET) is a software-based teaming technology that has been included in the Windows Server operating system since Windows Server 2016. A készlet nem függ a használt hálózati adapterek típusától.SET is not dependent on the type of network adapters used.

Alkalmazható adatforgalmi típusok: számítás, tárolás és felügyeletApplicable traffic types: compute, storage, and management

Szükséges minősítések: nincs (az operációs rendszerbe építve)Certifications required: none (built into the OS)

A SET az egyetlen, Azure Stack HCI által támogatott összevonási technológia.SET is the only teaming technology supported by Azure Stack HCI. A terheléselosztás/feladatátvétel (LBFO) egy másik, a Windows Servert használó összevonási technológia, amelyet a Azure Stack HCI nem támogat.Load Balancing/Failover (LBFO) is another teaming technology commonly used with Windows Server but is not supported with Azure Stack HCI. A Azure Stack HCI-LBFO kapcsolatos további információkért tekintse meg a Azure stack HCI- ben elérhető blogbejegyzéseket.See the blog post Teaming in Azure Stack HCI for more information on LBFO in Azure Stack HCI. A SET jól működik a számítási, tárolási és felügyeleti forgalom esetében egyaránt.SET works well with compute, storage, and management traffic alike.

A SET fontos a Azure Stack HCI esetében, mivel ez az egyetlen összevonási technológia, amely a következőket teszi lehetővé:SET is important for Azure Stack HCI as it is the only teaming technology that enables:

  • RDMA-adapterek összevonása (ha szükséges)Teaming of RDMA adapters (if needed)
  • Vendég RDMAGuest RDMA
  • Dinamikus VMMQDynamic VMMQ
  • Egyéb fontos Azure Stack HCI-funkciók (lásd: összevonás Azure stack HCI-ben)Other key Azure Stack HCI features (see Teaming in Azure Stack HCI)

A SET további funkciókat biztosít a LBFO felett, beleértve a minőségi és a teljesítménybeli tökéletesítéseket is.SET provides additional features over LBFO including quality and performance improvements. Ehhez be kell állítani a szimmetrikus (azonos) adapterek használatát – az aszimmetrikus adapterek összevonása nem támogatott.To do this, SET requires the use of symmetric (identical) adapters – teaming of asymmetric adapters is not supported. A szimmetrikus hálózati adapterek azonosak:Symmetric network adapters are those that have the same:

  • Gyártmány (szállító)make (vendor)
  • modell (verzió)model (version)
  • sebesség (átviteli sebesség)speed (throughput)
  • konfigurációconfiguration

A legegyszerűbb módszer annak azonosítására, hogy az adapterek szimmetrikusak-e, ha a sebességek megegyeznek, és a csatoló leírása megegyezik.The easiest way to identify if adapters are symmetric is if the speeds are the same and the interface descriptions match. Csak a leírásban felsorolt számokban térhetnek el.They can deviate only in the numeral listed in the description. A Get-NetAdapterAdvancedProperty parancsmag használatával győződjön meg arról, hogy a megadott konfigurációban ugyanazok a tulajdonságértékek szerepelnek.Use the Get-NetAdapterAdvancedProperty cmdlet to ensure the configuration reported lists the same property values.

Tekintse meg az alábbi táblázatot, amely egy példát mutat be a csak számokból (#) álló illesztőfelület-leírásokra:See the following table for an example of the interface descriptions deviating only by numeral (#):

NameName Interfész leírásaInterface Description Kapcsolat sebességeLink Speed
NIC1NIC1 Hálózati adapter #1Network Adapter #1 25 GB/s25 Gbps
NIC2NIC2 Hálózati adapter #2Network Adapter #2 25 GB/s25 Gbps
NIC3NIC3 Hálózati adapter #3Network Adapter #3 25 GB/s25 Gbps
NIC4NIC4 Hálózati adapter #4Network Adapter #4 25 GB/s25 Gbps

RDMA-forgalom szempontjaiRDMA traffic considerations

Az adatközpont-áthidalás (DCB) megvalósítása esetén gondoskodnia kell arról, hogy a PFC-és ETS-konfiguráció megfelelően legyen implementálva minden hálózati porton, beleértve a hálózati kapcsolókat is.If you implement Data Center Bridging (DCB), you must ensure that the PFC and ETS configuration is implemented properly across every network port, including network switches. DCB szükséges a RoCE, és nem kötelező a iWARP.DCB is required for RoCE and optional for iWARP.

A RDMA telepítésével kapcsolatos részletes információkért töltse le az Sdn GitHub-tárházból a doc szót.For detailed information on how to deploy RDMA, download the Word doc from the SDN GitHub repo.

A RoCE-alapú Azure Stack HCI implementációk három PFC forgalmi osztály konfigurációját igénylik, beleértve az alapértelmezett forgalmi osztályt a hálón és az összes gazdagépen:RoCE-based Azure Stack HCI implementations requires the configuration of three PFC traffic classes, including the default traffic class, across the fabric and all hosts:

Fürt forgalmi osztályaCluster traffic class

Ez a forgalmi osztály biztosítja, hogy elegendő sávszélesség legyen fenntartva a fürt szívveréséhez:This traffic class ensures there is enough bandwidth reserved for cluster heartbeats:

  • Kötelező: IgenRequired: Yes
  • PFC engedélyezve: nemPFC enabled: No
  • Ajánlott forgalmi prioritás: 7. prioritásRecommended traffic priority: Priority 7
  • Ajánlott sávszélesség-foglalás:Recommended bandwidth reservation:
    • 10 GbE vagy alacsonyabb RDMA hálózat = 2%10 GbE or lower RDMA networks = 2%
    • 25 GbE vagy újabb RDMA hálózat = 1%25 GbE or higher RDMA networks = 1%

RDMA Traffic osztályRDMA traffic class

Ez a forgalmi osztály biztosítja, hogy elegendő sávszélesség legyen fenntartva a veszteségmentes, közvetlen SMB-kommunikációhoz:This traffic class ensures there is enough bandwidth reserved for lossless RDA communications using SMB Direct:

  • Kötelező: IgenRequired: Yes
  • PFC engedélyezve: igenPFC enabled: Yes
  • Ajánlott forgalmi prioritás: 3. vagy 4. prioritásRecommended traffic priority: Priority 3 or 4
  • Ajánlott sávszélesség-foglalás: 50%Recommended bandwidth reservation: 50%

Alapértelmezett forgalmi osztályDefault traffic class

Ez a forgalmi osztály minden egyéb, a fürtön és a RDMA-forgalomban nem meghatározott forgalmat is magában foglal, beleértve a virtuális gépek forgalmát és a felügyeleti forgalmat:This traffic class carries all other traffic not defined in the cluster or RDMA traffic classes, including VM traffic and management traffic:

  • Kötelező: alapértelmezés szerint (nincs szükség konfigurációra a gazdagépen)Required: By default (no configuration necessary on the host)
  • A Flow Control (PFC) engedélyezve: nemFlow control (PFC) enabled: No
  • Ajánlott forgalmi osztály: alapértelmezés szerint (0. prioritás)Recommended traffic class: By default (Priority 0)
  • Ajánlott sávszélesség-foglalás: alapértelmezés szerint (nincs szükség gazdagép-konfigurációra)Recommended bandwidth reservation: By default (no host configuration required)

Tárolási forgalmi modellekStorage traffic models

Az SMB számos előnnyel jár, mint a Azure Stack HCI tárolási protokollja, beleértve a többcsatornás SMB-t is.SMB provides many benefits as the storage protocol for Azure Stack HCI including SMB Multichannel. Míg a többcsatornás SMB a jelen témakörön kívül esik, fontos tisztában lennie azzal, hogy a forgalom a többcsatornás SMB által használható összes lehetséges kapcsolaton alapul.While SMB Multichannel is out-of-scope for this topic, it is important to understand that traffic is multiplexed across every possible link that SMB Multichannel can use.

Megjegyzés

Azt javasoljuk, hogy több alhálózatot és VLAN-t használjon a tárolási forgalom elkülönítéséhez Azure Stack HCI-ben.We recommend using multiple subnets and VLANs to separate storage traffic in Azure Stack HCI.

Vegye figyelembe a következő példát egy négy csomópontos fürtre.Consider the following example of a four node cluster. Minden kiszolgáló két tárolási portot tartalmaz (a bal és a jobb oldalon).Each server has two storage ports (left and right side). Mivel minden egyes adapter ugyanazon az alhálózaton és VLAN-on található, a többcsatornás SMB az összes elérhető hivatkozáson keresztül terjeszti a kapcsolatokat.Because each adapter is on the same subnet and VLAN, SMB Multichannel will spread connections across all available links. Ezért az első kiszolgáló bal oldali portja (192.168.1.1) csatlakozik a bal oldali porthoz a második kiszolgálón (192.168.1.2).Therefore, the left-side port on the first server (192.168.1.1) will make a connection to the left-side port on the second server (192.168.1.2). Az első kiszolgáló (192.168.1.12) jobb oldali portja a második kiszolgáló jobb oldali portjához fog csatlakozni.The right-side port on the first server (192.168.1.12) will connect to the right-side port on the second server. Hasonló kapcsolatok vannak kialakítva a harmadik és a negyedik kiszolgálókhoz.Similar connections are established for the third and fourth servers.

Ez azonban szükségtelen kapcsolatokat hoz létre, és az összekapcsolás (több alvázos kapcsolati összesítési csoport vagy az MC-LAG) által a rack (ToR) kapcsolók összekapcsolásához (a (z) XS-vel jelölt) kapcsolókat eredményező torlódást okoz.However, this creates unnecessary connections and causes congestion at the interlink (multi-chassis link aggregation group or MC-LAG) that connects the top of rack (ToR) switches (marked with Xs). Lásd a következő ábrát:See the following diagram:

négy csomópontos fürt azonos alhálózata

Az ajánlott módszer külön alhálózatok és VLAN-ok használata az egyes adapterekhez.The recommended approach is to use separate subnets and VLANs for each set of adapters. A következő ábrán a jobb oldali portok mostantól a 192.168.2. x/24 alhálózatot és a VLAN2-t használják.In the following diagram, the right-hand ports now use subnet 192.168.2.x /24 and VLAN2. Ez lehetővé teszi, hogy a bal oldali portok forgalma a TOR1 maradjon, és a jobb oldali portok forgalma a TOR2 maradjon.This allows traffic on the left-side ports to remain on TOR1 and the traffic on the right-side ports to remain on TOR2. Lásd a következő ábrát:See the following diagram:

négy csomópontos fürt eltérő alhálózatai

Forgalmi sávszélesség kiosztásaTraffic bandwidth allocation

Az alábbi táblázat a különböző adatforgalmi típusok (például a közös adapterek sebessége, Azure Stack a HCI) sávszélesség-elosztását mutatja be.The table below shows example bandwidth allocations of various traffic types, using common adapter speeds, in Azure Stack HCI. Vegye figyelembe, hogy ez egy konvergens megoldás, amelyben az összes forgalmi típus (számítási, tárolási és felügyeleti) ugyanazon a fizikai adaptereken fut, és a készlet használatával van összefoglalva.Note that this is an example of a converged solution where all traffic types (compute, storage, and management) run over the same physical adapters and are teamed using SET.

Mivel ez a használati eset a legtöbb korlátozást jelenti, jó alapkonfigurációt jelent.Since this use case poses the most constraints, it represents a good baseline. Az adapterek és a sebességek számának tekintetében azonban figyelembe kell venni egy példát, nem pedig a támogatási követelményt.However, considering the permutations for number of adapters and speeds, this should be considered an example and not a support requirement.

Ehhez a példához a következő feltételezések történnek:The following assumptions are made for this example:

  • A csapatnak két adaptere vanThere are two adapters per team

  • Storage Bus Layer (SBL), Fürt megosztott kötete (CSV) és Hyper-V (Élő áttelepítés) forgalom:Storage Bus Layer (SBL), Cluster Shared Volume (CSV), and Hyper-V (Live Migration) traffic:

    • Azonos fizikai adapterek használataUse the same physical adapters
    • SMB használataUse SMB
  • Az SMB 50%-os sávszélesség-kiosztást kap az adatközpont-áthidalás használatávalSMB is given a 50% bandwidth allocation using Data Center Bridging

    • A SBL/CSV a legmagasabb prioritású forgalom, és az SMB-sávszélesség foglalásának 70%-át fogadja, valamint:SBL/CSV is the highest priority traffic and receives 70% of the SMB bandwidth reservation, and:
    • Élő áttelepítés (LM) korlátozott a parancsmag használatával Set-SMBBandwidthLimit , és a fennmaradó sávszélesség 29%-át kapjaLive Migration (LM) is limited using the Set-SMBBandwidthLimit cmdlet and receives 29% of the remaining bandwidth
      • Ha a rendelkezésre álló sávszélesség Élő áttelepítés >= 5 GB/s, és a hálózati adapterek képesek a RDMA használatára.If the available bandwidth for Live Migration is >= 5 Gbps, and the network adapters are capable, use RDMA. Ehhez használja a következő parancsmagot:Use the following cmdlet to do so:

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB
        
      • Ha a rendelkezésre álló sávszélesség Élő áttelepítés 5 GB/s <, az áramszünetek csökkentése érdekében használjon tömörítést.If the available bandwidth for Live Migration is < 5 Gbps, use compression to reduce blackout times. Ehhez használja a következő parancsmagot:Use the following cmdlet to do so:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • Ha a RDMA-et Élő áttelepítés használatával használja, ügyeljen arra, hogy Élő áttelepítés forgalom ne használja fel a RDMA forgalmi osztály számára lefoglalt teljes sávszélességet az SMB sávszélesség-korlátjának használatával.If using RDMA with Live Migration, ensure that Live Migration traffic cannot consume the entire bandwidth allocated to the RDMA traffic class by using an SMB bandwidth limit. Ügyeljen arra, hogy a parancsmag másodpercenként bájt/másodperc (b/s) értéket vegyen fel, míg a hálózati adapterek a bit/másodperc (bps) értékben vannak felsorolva.Be careful as this cmdlet takes entry in bytes per second (Bps) whereas network adapters are listed in bits per second (bps). A következő parancsmaggal állíthatja be a 6 GB/s sávszélesség-korlátot, például:Use the following cmdlet to set a bandwidth limit of 6 Gbps for example:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
    

    Megjegyzés

    750 MBps ebben a példában 6 GB/s750 MBps in this example equates to 6 Gbps

Az alábbi példában a sávszélesség-foglalási táblázat látható:Here is the example bandwidth allocation table:

Hálózati adapter sebességeNIC Speed Összevont sávszélességTeamed Bandwidth SMB-sávszélesség foglalása * *SMB Bandwidth Reservation** SBL/CSV%SBL/CSV % SBL/CSV-sávszélességSBL/CSV Bandwidth Élő áttelepítés%Live Migration % Maximális Élő áttelepítés sávszélességMax Live Migration Bandwidth SzívverésHeartbeat % Szívverési sávszélességHeartbeat Bandwidth
10 Gbps10 Gbps 20 GB/s20 Gbps 10 Gbps10 Gbps 70%70% 7 GB/s7 Gbps * * 2%2% 200 Mbit/s200 Mbps
25 GB/s25 Gbps 50 GB/s50 Gbps 25 GB/s25 Gbps 70%70% 17,5 GB/s17.5 Gbps 2929% 7,25 GB/s7.25 Gbps 1%1% 250 Mbps250 Mbps
40 Gbps40 Gbps 80 GB/s80 Gbps 40 Gbps40 Gbps 70%70% 28 GB/s28 Gbps 2929% 11,6 GB/s11.6 Gbps 1%1% 400 Mbps400 Mbps
50 GB/s50 Gbps 100 Gbps100 Gbps 50 GB/s50 Gbps 70%70% 35 GB/s35 Gbps 2929% 14,5 GB/s14.5 Gbps 1%1% 500 Mbps500 Mbps
100 Gbps100 Gbps 200 Gbit/s200 Gbps 100 Gbps100 Gbps 70%70% 70 GB/s70 Gbps 2929% 29 GB/s29 Gbps 1%1% 1 Gbps1 Gbps
200 Gbit/s200 Gbps 400 GB/s400 Gbps 200 Gbit/s200 Gbps 70%70% 140 GB/s140 Gbps 2929% 58 GB/s58 Gbps 1%1% 2 Gbps2 Gbps

* – a RDMA helyett tömörítést kell használnia, mivel Élő áttelepítés forgalom sávszélesség-kiosztása <5 GB/s*- should use compression rather than RDMA as the bandwidth allocation for Live Migration traffic is <5 Gbps

* *-50%-os sávszélesség-foglalás példa erre a példára**- 50% is an example bandwidth reservation for this example

Kiterjesztett fürtök szempontjaiStretched cluster considerations

A kifeszített fürtök biztosítják a több adatközpontra kiterjedő vész-helyreállítási feladatsort.Stretched clusters provide disaster recovery that spans multiple data centers. Legegyszerűbben a kifeszített Azure Stack HCI-fürt hálózata így néz ki:In its simplest form, a stretched Azure Stack HCI cluster network looks like this:

Kifeszített fürt

A kiterjesztett fürtök a következő követelményekkel és jellemzőkkel rendelkeznek:Stretched clusters have the following requirements and characteristics:

  • A RDMA egyetlen helyre korlátozódik, és nem támogatott a különböző helyeken vagy alhálózatokban.RDMA is limited to a single site, and is not supported across different sites or subnets.

  • Az azonos helyen található kiszolgálóknak ugyanabban az állványban és 2. rétegbeli határban kell lenniük.Servers in the same site must reside in the same rack and Layer-2 boundary.

  • Helyek közötti kommunikáció – 3. rétegbeli határ; a kifeszített Layer-2 topológiák nem támogatottak.Communication between sites cross a Layer-3 boundary; stretched Layer-2 topologies are not supported.

  • Ha egy hely RDMA használ a tároló adapterekhez, ezeknek az adaptereknek külön alhálózaton és VLAN-on kell lenniük, amely nem tud útvonalakat átirányítani a helyek között.If a site uses RDMA for its storage adapters, these adapters must be on a separate subnet and VLAN that cannot route between sites. Ez megakadályozza, hogy a tárolási replika a RDMA-t használja a helyek között.This prevents Storage Replica from using RDMA across sites.

  • A helyek közötti kommunikációhoz használt adapterek:Adapters used for communication between sites:

    • Fizikai vagy virtuális (Host vNIC) lehet.Can be physical or virtual (host vNIC). Ha virtuális, egy vNIC kell kiépítenie a saját alhálózatában és VLAN-ban fizikai hálózati adapteren.If virtual, you must provision one vNIC in its own subnet and VLAN per physical NIC.
    • A saját alhálózatán és VLAN-on kell lennie, amely képes a helyek közötti útválasztásra.Must be on their own subnet and VLAN that can route between sites.
    • A RDMA le kell tiltani a Disable-NetAdapterRDMA parancsmag használatával.RDMA must be disabled using the Disable-NetAdapterRDMA cmdlet. Javasoljuk, hogy a parancsmag használatával explicit módon megkövetelje a tárolási replika használatát adott felületek használatához Set-SRNetworkConstraint .We recommend that you explicitly require Storage Replica to use specific interfaces using the Set-SRNetworkConstraint cmdlet.
    • Meg kell felelnie a tárolási replika további követelményeinek.Must meet any additional requirements for Storage Replica.
  • Ha feladatátvételt hajt végre egy másik helyre, gondoskodnia kell arról, hogy elegendő sávszélesség álljon rendelkezésre a munkaterhelések futtatásához a másik helyen.In the event of a failover to another site, you must ensure that enough bandwidth is available to run the workloads at the other site. A biztonságos megoldás az, ha a helyek a rendelkezésre álló kapacitásuk 50%-ában vannak kiépítve.A safe option is to provision sites at 50% of their available capacity. Ez nem nehéz követelmény, ha a feladatátvétel során el tudja viselni az alacsonyabb teljesítményt.This is not a hard requirement if you are able to tolerate lower performance during a failover.

További lépésekNext steps