Požadavky na síť hostitele pro Azure Stack HCI

Platí pro: Azure Stack HCI, verze 21H2 a 20H2

Toto téma popisuje požadavky na síť hostitele a požadavky na Azure Stack HCI. Informace o architekturách Datacenter a fyzických připojeních mezi servery najdete v tématu požadavky na fyzickou síť.

Informace o tom, jak zjednodušit hostitelské sítě pomocí síťového ATC, najdete v tématu zjednodušení sítě hostitele pomocí síťového ATC.

Typy síťových přenosů

Azure Stack může být síťový provoz HCI klasifikován podle zamýšleného účelu:

  • Výpočetní provoz: Provoz pocházející z nebo určený pro virtuální počítač (VM).
  • Storage provoz: provoz pro Prostory úložiště Direct (S2D) pomocí protokolu SMB (Server Message Block).
  • Provoz správy: provoz je důležitý pro správce správy clusterů, jako je služba Active Directory, vzdálená plocha, Windows centrum pro správu a Windows PowerShell.

Vyberte síťový adaptér.

Azure Stack HCI vyžaduje výběr síťového adaptéru, který dosáhl certifikace Windows serveru Software-Defined datového centra (SDDC) se standardní nebo Premiumou kvalifikací (AQ). Tyto adaptéry podporují nejvíce pokročilých funkcí platformy a prošly tím nejvyšším testováním našimi hardwarovými partnery. Tato úroveň kontroly obvykle vede k omezení potíží s kvalitou hardwaru a ovladačů. tyto adaptéry také splňují požadavky sítě, které jsou zavedené pro Prostory úložiště Direct.

adaptér, který má Standard nebo Premium AQ, můžete zjistit tak, že zkontrolujete položku katalogu Windows serveru pro adaptér a příslušnou verzi operačního systému. tady je příklad zápisu pro Premium AQ:

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

Přehled schopností síťových adaptérů pro klíč

Důležité možnosti síťového adaptéru, které používá Azure Stack HCI, zahrnují:

  • Dynamická vícenásobná fronta virtuálních počítačů (dynamická VMMQ nebo d. VMMQ)
  • Přímý přístup do paměti vzdáleného počítače (RDMA)
  • Host RDMA
  • Switch Embedded Teaming (SET)

Dynamické VMMQ

všechny síťové adaptéry s Premium AQ podporují dynamickou VMMQ. Dynamické VMMQ vyžaduje použití seskupování vloženého přepínače.

Použitelné typy provozu: COMPUTE

Požadované certifikace: Premium

Dynamická VMMQ je inteligentní technologie pro přijímání na straně příjmu. Sestaví na základě jejich předchůdců Fronta pro virtuální počítače (VMQ) (VMQ), virtuálního škálování na straně příjmu (vRSS) a VMMQ, aby poskytoval tři primární vylepšení:

  • Optimalizuje efektivitu hostitele pomocí menšího počtu jader procesoru.
  • Automatické ladění zpracování síťového provozu na jádra procesoru, čímž umožníte virtuálním počítačům naplnit a udržovat očekávanou propustnost.
  • Povoluje "shluky" úloh pro příjem očekávaného objemu provozu.

Další informace o dynamických VMMQ najdete v blogovém příspěvku syntetických zrychlení.

RDMA

RDMA je přesměrování síťového zásobníku na síťový adaptér. Umožňuje provoz úložiště protokolu SMB obejít operační systém ke zpracování.

RDMA umožňuje sítě s vysokou propustností a nízkou latencí pomocí minimálních prostředků procesoru hostitele. Tyto prostředky hostitelského procesoru pak můžete použít ke spouštění dalších virtuálních počítačů nebo kontejnerů.

Použitelné typy provozu: úložiště hostitele

Vyžadované certifikace: Standardní

všechny adaptéry se standardem nebo Premium AQ podporují RDMA. RDMA je doporučený výběr nasazení pro úlohy úložiště v Azure Stack HCI a může být volitelně povolen pro úlohy úložiště (pomocí protokolu SMB) pro virtuální počítače. Další informace najdete v části "host RDMA" dále v tomto článku.

Azure Stack HCI podporuje RDMA pomocí implementace protokolu iWARP (Internet WAN Area RDMA Protocol) nebo RDMA přes sblížené sítě Ethernet (RoCE).

Důležité

Adaptéry RDMA fungují jenom s ostatními adaptéry RDMA, které implementují stejný protokol RDMA (iWARP nebo RoCE).

Ne všechny síťové adaptéry od dodavatelů podporují RDMA. v následující tabulce jsou uvedeni dodavatelé (v abecedním pořadí), které nabízejí Premium certifikované adaptéry RDMA. V tomto seznamu ale nejsou k dispozici dodavatelé hardwaru, kteří také podporují RDMA. ověřte podporu RDMA v katalogu Windows serveru .

Poznámka

InfiniBand (IB) není u Azure Stack HCL podporováno.

Dodavatel síťových adaptérů iWARP RoCE
Broadcom Ne Ano
Chelsio Ano Ne
RSS Ano Ano (některé modely)
PERC (QLogic/Cavium) Ano Ano
NVIDIA (Mellanox) Ne Ano

další informace o nasazení RDMA získáte stažením dokumentu z úložiště SDN GitHub.

iWARP

iWARP používá protokol TCP (Transmission Control Protocol) a dá se volitelně rozšířit pomocí řízení Flow založeného na prioritách (PFC) a služby enhanced Transmission Service (ETS).

IWARP použijte, pokud:

  • Máte málo nebo žádné síťové prostředí nebo se Uncomfortable Správa síťových přepínačů.
  • Neřídíte přepínače pro rozvaděče (Top-of-rack).
  • Po nasazení nebude řešení spravovat.
  • Už máte nasazení, která používají iWARP.
  • Nejste si jisti, kterou možnost si vybrat.

RoCE

RoCE používá protokol UDP (User Datagram Protocol) a vyžaduje PFC a ETS k zajištění spolehlivosti.

RoCE použijte, pokud:

  • V datacentru už máte nasazení pomocí RoCE.
  • Jste obeznámeni se správou požadavků na DCB sítě.

Host RDMA

Host RDMA umožňuje úlohám SMB pro virtuální počítače získat stejné výhody použití RDMA na hostitelích.

Použitelné typy provozu: Úložiště založené na hostovi

Požadované certifikace: Premium

Primární výhody použití hosta RDMA jsou:

  • Přesměruje zatížení procesoru na síťovou kartu pro zpracování síťového provozu.
  • Extrémně nízká latence.
  • Vysoká propustnost.

pokud chcete získat další informace, stáhněte si dokument z úložiště SDN GitHub.

SET

sada je softwarově založená technologie pro seskupování, která je součástí operačního systému Windows serveru od Windows Server 2016. SADA není závislá na typu používaných síťových adaptérů.

Použitelné typy provozu: výpočty, úložiště a Správa

Požadované certifikace: žádné (sada je integrovaná do operačního systému)

SET je jediná technologie seskupování podporovaná v Azure Stack HCI. SET dobře funguje s výpočetním, úložným a řídicím provozem.

Důležité

Vyrovnávání zatížení nebo převzetí služeb při selhání (LBFO) je další technologie sesouvání, která se běžně používá s Windows Serverem, ale nepodporuje se Azure Stack HCI. Další informace o LBFO v Azure Stack HCI najdete v blogovém příspěvku Sesouvání v Azure Stack HCI.

Set je pro Azure Stack HCI důležitý, protože je to jediná technologie sesouvání, která umožňuje:

  • Sesouvání adaptérů RDMA (v případě potřeby)
  • Rdma hosta.
  • Dynamické funkce VMMQ.
  • Další klíčové Azure Stack HCI (viz Sesouvání v Azure Stack HCI).

Všimněte si, že set vyžaduje použití symetrických (identických) adaptérů. Sesouvání asymetrických adaptérů se nepodporuje. Symetrické síťové adaptéry jsou ty, které mají stejné:

  • značka (dodavatel)
  • model (verze)
  • speed (propustnost)
  • konfigurace

Nejjednodušší způsob, jak zjistit, jestli jsou adaptéry symetrické, je, pokud jsou rychlosti stejné a popisy rozhraní se shodují. Mohou se odchýlit pouze číslicemi uvedenými v popisu. Pomocí rutiny Get-NetAdapterAdvancedProperty zajistěte, aby hlášená konfigurace vypíše stejné hodnoty vlastností.

Příklad popisů rozhraní, které se odchylují jenom číslicemi (#), najdete v následující tabulce:

Name Popis rozhraní Rychlost propojení
NIC1 Síťový adaptér č. 1 25 Gb/s
NIC2 Síťový adaptér č. 2 25 Gb/s
NIC3 Síťový adaptér č. 3 25 Gb/s
NIC4 Síťový adaptér č. 4 25 Gb/s

Poznámka

SET podporuje pouze konfiguraci nezávislou na přepínači pomocí dynamických algoritmů nebo algoritmů vyrovnávání zatížení portů Hyper-V. Pokud chcete dosáhnout nejlepšího výkonu, doporučuje se u všech síťových karet, které fungují rychlostí 10 Gbps a více, použít port Hyper-V.

Důležité informace o provozu RDMA

Pokud implementujete DCB, musíte zajistit, aby konfigurace PFC a ETS byla správně implementovaná napříč všemi síťovými porty, včetně síťových přepínačů. Pro RoCE se vyžaduje DCB a pro iWARP je volitelné.

Podrobné informace o tom, jak nasadit RDMA, najdete v dokumentu z GitHub SDN.

Implementace přenosů založené Azure Stack HCI RoCE vyžadují konfiguraci tří tříd přenosů dat PFC, včetně výchozí třídy provozu, napříč všemi hostiteli a infrastruktury.

Třída provozu clusteru

Tato třída přenosů zajišťuje, že je pro heartbeaty clusteru vyhrazená natolik velká šířka pásma:

  • Požadováno: Ano
  • S podporou PFC: Ne
  • Doporučená priorita provozu: Priorita 7
  • Doporučená rezervace šířky pásma:
    • 10 GbE nebo nižší sítě s rdma = 2 %
    • 25 GbE nebo vyšší sítě RDMA = 1 %

Třída provozu RDMA

Tato třída přenosů zajišťuje, že je k dispozici dostatek šířky pásma vyhrazené pro bezstavovou komunikaci s přímým přístupem do paměti vzdáleného počítače (RDMA) pomocí funkce SMB Direct:

  • Požadováno: Ano
  • S podporou PFC: Ano
  • Doporučená priorita provozu: Priorita 3 nebo 4
  • Doporučená rezervace šířky pásma: 50 procent

Výchozí třída provozu

Tato třída přenosů přenáší všechny ostatní přenosy, které nejsou definované ve třídách provozu clusteru nebo RDMA, včetně provozu virtuálního počítače a provozu správy:

  • Povinné: Ve výchozím nastavení (na hostiteli není nutná žádná konfigurace)
  • Flow řízení přístupu (PFC): Ne
  • Doporučená třída provozu: Ve výchozím nastavení (Priorita 0)
  • Doporučená rezervace šířky pásma: Ve výchozím nastavení (nevyžaduje se konfigurace hostitele)

Storage modelů provozu

Protokol SMB poskytuje řadu výhod jako protokol úložiště pro Azure Stack HCI, včetně SMB Multichannel. Protokol SMB Multichannel není v tomto článku zahrnutý, ale je důležité pochopit, že provoz je multiplexovaný napříč všemi možnými odkazy, které smb Multichannel může použít.

Poznámka

K oddělení provozu úložiště v síti doporučujeme použít více podsítí a sítí VLAN Azure Stack HCI.

Představte si následující příklad clusteru se čtyřmi uzly. Každý server má dva porty úložiště (levá a pravá strana). Vzhledem k tomu, že každý adaptér je ve stejné podsíti a síti VLAN, smb Multichannel rozprostří připojení mezi všechna dostupná propojení. Proto levý port na prvním serveru (192.168.1.1) se na druhém serveru (192.168.1.2) pro připojení k portu na levé straně. Pravý port na prvním serveru (192.168.1.12) se připojí k portu na pravé straně druhého serveru. Podobná připojení jsou vytvořena pro třetí a čtvrtý server.

Tím se ale vytvoří nepotřebná připojení a způsobí zahlcení mezilinku (agregační skupina propojení s více skříněmi nebo MC-LAG), která propojuje přepínače ToR (označené X). Podívejte se na následující diagram:

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

Doporučeným přístupem je použití samostatných podsítí a sítí VLAN pro každou sadu adaptérů. V následujícím diagramu teď porty na pravé straně používají podsíť 192.168.2.x /24 a síť VLAN2. To umožňuje, aby provoz na portech na levé straně zůstal na TOR1 a provoz na portech na pravé straně zůstal na TOR2.

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

Přidělení šířky pásma provozu

Následující tabulka ukazuje příklad přidělení šířky pásma pro různé typy přenosů s využitím běžných rychlostí adaptéru v Azure Stack HCI. Všimněte si, že toto je příklad konvergovanéřešení, kde všechny typy provozu (výpočetní prostředky, úložiště a správa) běží přes stejné fyzické adaptéry a jsou sesouvány pomocí příkazu SET.

Vzhledem k tomu, že tento případ použití představuje největší omezení, představuje dobrý směrný plán. Vzhledem k permutacím počtu adaptérů a rychlostí by se to ale mělo považovat za příklad, a nikoli za požadavek na podporu.

Pro tento příklad se předpokládá následující:

  • Pro každý tým existují dva adaptéry.

  • Storage Bus Layer (SBL), sdílený svazek clusteru (CSV) a hyper-V (Migrace za provozu):

    • Používejte stejné fyzické adaptéry.
    • Použití protokolu SMB.
  • Protokolu SMB se přidělí 50% šířka pásma pomocí DCB.

    • SBL/CSV je provoz s nejvyšší prioritou a přijímá 70 % rezervace šířky pásma protokolu SMB.
    • Migrace za provozu (LM) je omezený pomocí rutiny a Set-SMBBandwidthLimit obdrží 29 % zbývající šířky pásma.
      • Pokud je dostupná šířka pásma Migrace za provozu je = 5 Gb/s a síťové adaptéry jsou > schopné, použijte RDMA. Použijte k tomu následující rutinu:

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB
        
      • Pokud je dostupná šířka pásma pro Migrace za provozu < 5 Gb/s, použijte kompresi, aby se zkrátily výpadky. Použijte k tomu následující rutinu:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • Pokud používáte RDMA pro přenosy dat Migrace za provozu, ujistěte se, že provoz protokolu Migrace za provozu nemůže využívat celou šířku pásma přidělenou třídě přenosů RDMA pomocí omezení šířky pásma protokolu SMB. Buďte opatrní, protože tato rutina přijímá položky v bajtech za sekundu (b/s), zatímco síťové adaptéry jsou uvedené v bitech za sekundu (b/s). K nastavení limitu šířky pásma 6 Gb/s použijte následující rutinu, například:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
    

    Poznámka

    750 MB/s v tomto příkladu se rovná 6 Gb/s.

Tady je příklad tabulky přidělení šířky pásma:

Rychlost síťové karty Seskutá šířka pásma Rezervace šířky pásma protokolu SMB** SBL/CSV % Šířka pásma SBL/CSV Migrace za provozu % Maximální Migrace za provozu šířky pásma Heartbeat % Šířka pásma heartbeatu
10 Gb/s 20 Gb/s 10 Gb/s 70 % 7 Gb/s * * 2 % 200 Mb/s
25 Gb/s 50 Gb/s 25 Gb/s 70 % 17,5 Gb/s 29% 7,25 Gb/s 1 % 250 MB/s
40 Gb/s 80 Gb/s 40 Gb/s 70 % 28 Gb/s 29% 11,6 Gb/s 1 % 400 Mb/s
50 Gb/s 100 Gb/s 50 Gb/s 70 % 35 Gb/s 29% 14,5 Gb/s 1 % 500 Mb/s
100 Gb/s 200 Gb/s 100 Gb/s 70 % 70 Gb/s 29% 29 Gb/s 1 % 1 Gb/s
200 Gb/s 400 Gb/s 200 Gb/s 70 % 140 Gb/s 29% 58 Gb/s 1 % 2 Gb/s

* Místo RDMA používejte kompresi, protože přidělení šířky pásma pro Migrace za provozu přenosů dat < je 5 Gb/s.

** 50 procent je příkladem rezervace šířky pásma.

Roztažené clustery

Roztažené clustery poskytují zotavení po havárii, které zahrnuje více datacenter. V nejjednodušší podobě vypadá roztažená síť Azure Stack HCI clusterů podobně jako tato:

Diagram that shows a stretched cluster.

Požadavky na roztažený cluster

Roztažené clustery mají následující požadavky a vlastnosti:

  • RDMA je omezený na jednu lokalitu a nepodporuje se v různých lokalitách ani podsítích.

  • Servery ve stejné lokalitě se musí nacházet ve stejném racku a hranici vrstvy 2.

  • Komunikace mezi lokalitami hostitele musí překročit hranici vrstvy 3. Roztažené topologie vrstvy 2 se nepodporují.

  • Mít dostatek šířky pásma pro spouštění úloh v jiné lokalitě. V případě převzetí služeb při selhání bude muset alternativní web spustit veškerý provoz. Doporučujeme zřídit lokality s 50 % jejich dostupné síťové kapacity. Není to ale povinné, pokud během převzetí služeb při selhání dokážete tolerovat nižší výkon.

  • Replikace mezi lokalitami (provoz sever/jih) může používat stejné fyzické síťové připojení jako místní úložiště (provoz východ/západ). Pokud používáte stejné fyzické adaptéry, musí být tyto adaptéry sesouovány pomocí sady SET. Adaptéry musí mít také další virtuální síťové karty zřízené pro směrovatelný provoz mezi lokalitami.

  • Adaptéry používané ke komunikaci mezi lokalitami:

    • Může to být fyzický nebo virtuální (hostitelský virtuální virtuální síť). Pokud jsou adaptéry virtuální, musíte zřídit jeden virtuální síťový adaptér ve vlastní podsíti a síť VLAN pro každou fyzickou síťovou kartu.

    • Musí být ve vlastní podsíti a síti VLAN, které mohou směrovat mezi lokalitami.

    • RDMA musí být zakázané pomocí rutiny Disable-NetAdapterRDMA . Doporučujeme, abyste výslovně vyžadovali, Storage replika používá konkrétní rozhraní pomocí Set-SRNetworkConstraint rutiny .

    • Musí splňovat všechny další požadavky pro Storage repliky.

Příklad roztaženého clusteru

Následující příklad znázorňuje konfiguraci roztaženého clusteru. Pokud chcete zajistit mapování konkrétní virtuální síťové karty na konkrétní fyzický adaptér, použijte rutinu Set-VMNetworkAdapterTeammapping.

Diagram that shows an example of stretched cluster storage.

Následující obrázek ukazuje podrobnosti o příkladu konfigurace roztaženého clusteru.

Poznámka

Vaše přesná konfigurace, včetně názvů síťových adaptérů, IP adres a sítí VLAN, se může lišit od toho, co se zobrazuje. Používá se jenom jako referenční konfigurace, kterou je možné přizpůsobit vašemu prostředí.

SiteA – místní replikace, povolená funkce RDMA, nesmyšitelná mezi lokalitami

Název uzlu Název virtuálníhonicu Fyzická síťový adaptér (namapovaná) REŽIM IP adresa a podsíť Rozsah provozu
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Pouze místní lokalita
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Pouze místní lokalita
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Pouze místní lokalita
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Pouze místní lokalita

SiteB – místní replikace, povolení RDMA, Nesměrovatelné mezi lokalitami

Název uzlu název vNIC Fyzická síťová karta (namapovaná) REŽIM IP adresa a podsíť Rozsah provozu
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Pouze místní lokalita
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Pouze místní lokalita
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Pouze místní lokalita
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Pouze místní lokalita

Lokalita – roztažená replikace, zakázaná, směrovatelný mezi lokalitami

Název uzlu název vNIC Fyzická síťová karta (namapovaná) IP adresa a podsíť Rozsah provozu
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Směrování mezi weby
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Směrování mezi weby
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Směrování mezi weby
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Směrování mezi weby

SiteB – roztažená replikace, zakázaná, směrovatelný mezi lokalitami

Název uzlu název vNIC Fyzická síťová karta (namapovaná) IP adresa a podsíť Rozsah provozu
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Směrování mezi weby
NodeB2 Stretch1 pNIC01 175.0.0.2/8 Směrování mezi weby
Uzel B1 Roztažení 2 pNIC02 176.0.0.1/8 Směrovatelné mezi weby
NodeB2 Roztažení 2 pNIC02 176.0.0.2/8 Směrovatelné mezi weby

Další kroky