Udostępnij za pośrednictwem

Wymagania dotyczące sieci hosta dla rozwiązania Azure Stack HCI

  • Artykuł

Dotyczy: Azure Stack HCI, wersje 23H2 i 22H2

W tym temacie omówiono zagadnienia dotyczące sieci hostów i wymagania dotyczące rozwiązania Azure Stack HCI. Aby uzyskać informacje na temat architektur centrów danych i połączeń fizycznych między serwerami, zobacz Wymagania dotyczące sieci fizycznej.

Aby uzyskać informacje na temat upraszczania sieci hostów przy użyciu usługi Network ATC, zobacz Upraszczanie sieci hostów przy użyciu usługi Network ATC.

Typy ruchu sieciowego

Ruch sieciowy usługi Azure Stack HCI można sklasyfikować według zamierzonego celu:

  • Ruch zarządzania: ruch do lub spoza klastra lokalnego. Na przykład ruch repliki magazynu lub ruch używany przez administratora do zarządzania klastrem, takiego jak pulpit zdalny, Centrum administracyjne systemu Windows, Active Directory itp.
  • Ruch obliczeniowy: ruch pochodzący z maszyny wirtualnej lub kierowany do maszyny wirtualnej.
  • Ruch magazynu: ruch przy użyciu bloku komunikatów serwera (SMB), na przykład Miejsca do magazynowania bezpośredniej lub opartej na protokole SMB migracji na żywo. Ten ruch jest ruchem warstwy 2 i nie jest routingu.

Ważne

Replika magazynu używa ruchu SMB opartego na funkcji RDMA. To i kierunkowy charakter ruchu (Północ-Południe) sprawia, że jest ściśle dopasowany do ruchu "zarządzania" wymienionego powyżej, podobnie jak w przypadku tradycyjnego udziału plików.

Wybieranie karty sieciowej

Karty sieciowe są kwalifikowane przez typy ruchu sieciowego (patrz powyżej), z którymi są obsługiwane. Podczas przeglądania wykazu systemu Windows Server certyfikacja systemu Windows Server 2022 wskazuje teraz co najmniej jedną z następujących ról. Przed zakupem serwera dla rozwiązania Azure Stack HCI musisz mieć co najmniej jedną kartę, która jest kwalifikowana do zarządzania, obliczeń i magazynu, ponieważ wszystkie trzy typy ruchu są wymagane w usłudze Azure Stack HCI. Następnie możesz użyć usługi Network ATC , aby skonfigurować karty dla odpowiednich typów ruchu.

Aby uzyskać więcej informacji na temat tej kwalifikacji karty sieciowej opartej na rolach, zobacz ten link.

Ważne

Używanie adaptera spoza kwalifikowanego typu ruchu nie jest obsługiwane.

Poziom Rola zarządzania Rola obliczeniowa Rola magazynu
Rozróżnienie oparte na rolach Zarządzanie Obliczenia w warstwie Standardowa Magazyn w warstwie Standardowa
Maksymalna nagroda Nie dotyczy Obliczenia w warstwie Premium Storage Premium

Uwaga

Najwyższa kwalifikacja każdej karty w naszym ekosystemie będzie zawierać kwalifikacje do zarządzania, obliczeń w warstwie Premium i magazynu Premium .

Zrzut ekranu przedstawia kwalifikacje

Wymagania dotyczące sterowników

Sterowniki skrzynki odbiorczej nie są obsługiwane do użycia z rozwiązaniem Azure Stack HCI. Aby określić, czy karta używa sterownika skrzynki odbiorczej, uruchom następujące polecenie cmdlet. Karta używa sterownika skrzynki odbiorczej, jeśli właściwość DriverProvider to Microsoft.

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

Omówienie kluczowych możliwości karty sieciowej

Ważne możliwości karty sieciowej używane przez usługę Azure Stack HCI obejmują:

  • Dynamiczna kolejka maszyny wirtualnej (dynamic VMMQ lub d.VMMQ)
  • Zdalny bezpośredni dostęp do pamięci (RDMA)
  • RdMA gościa
  • Przełącznik osadzone tworzenia zespołu (SET)

Dynamiczny program VMMQ

Wszystkie karty sieciowe z kwalifikacjami obliczeń (Premium) obsługują dynamiczną karty VMMQ. Dynamiczna funkcja VMMQ wymaga użycia tworzenia zespołu osadzonego przełącznika.

Odpowiednie typy ruchu: obliczenia

Wymagane certyfikaty: Obliczenia (Premium)

Dynamic VMMQ to inteligentna technologia po stronie odbieranej. Opiera się na swoich poprzednikach kolejki maszyn wirtualnych (VMQ), skalowaniu po stronie odbierającej wirtualnej (vRSS) i VMMQ, aby zapewnić trzy podstawowe ulepszenia:

  • Optymalizuje wydajność hosta przy użyciu mniejszej liczby rdzeni procesora CPU.
  • Automatyczne dostrajanie przetwarzania ruchu sieciowego do rdzeni procesora CPU, co umożliwia maszynom wirtualnym spełnienie i utrzymanie oczekiwanej przepływności.
  • Umożliwia "bursty" obciążeń odbieranie oczekiwanej ilości ruchu.

Aby uzyskać więcej informacji na temat dynamicznego VMMQ, zobacz wpis w blogu Syntetyczne przyspieszenia.

Dostęp RDMA

RDMA to odciążanie stosu sieciowego do karty sieciowej. Umożliwia to obejście ruchu magazynu SMB w celu obejścia systemu operacyjnego do przetwarzania.

Funkcja RDMA umożliwia korzystanie z sieci o wysokiej przepływności i małych opóźnieniach przy użyciu minimalnych zasobów procesora CPU hosta. Te zasoby procesora CPU hosta mogą być następnie używane do uruchamiania dodatkowych maszyn wirtualnych lub kontenerów.

Odpowiednie typy ruchu: magazyn hostów

Wymagane certyfikaty: Magazyn (Standardowa)

Wszystkie karty z kwalifikacjami magazynu (Standardowa) lub Magazynu (Premium) obsługują funkcję RDMA po stronie hosta. Aby uzyskać więcej informacji na temat korzystania z funkcji RDMA z obciążeniami gościa, zobacz sekcję "RdMA gościa" w dalszej części tego artykułu.

Usługa Azure Stack HCI obsługuje funkcję RDMA z implementacjami protokołu IWARP (Internet Wide Area RDMA) lub RDMA over Converged Ethernet (RoCE).

Ważne

Karty RDMA działają tylko z innymi kartami RDMA, które implementują ten sam protokół RDMA (iWARP lub RoCE).

Nie wszystkie karty sieciowe od dostawców obsługują funkcję RDMA. W poniższej tabeli wymieniono tych dostawców (w kolejności alfabetycznej), którzy oferują certyfikowane karty RDMA. Jednak na tej liście nie ma dostawców sprzętu, którzy również obsługują funkcję RDMA. Zapoznaj się z katalogiem systemu Windows Server, aby znaleźć karty z kwalifikacją Storage (Standardowa) lub Storage (Premium), które wymagają obsługi RDMA.

Uwaga

Rozwiązanie InfiniBand (IB) nie jest obsługiwane w usłudze Azure Stack HCI.

Dostawca karty sieciowej iWARP RoCE
Broadcom Nie. Tak
Intel Tak Tak (niektóre modele)
Marvell (Qlogic) Tak Tak
Nvidia Nie. Tak

Aby uzyskać więcej informacji na temat wdrażania funkcji RDMA dla hosta, zdecydowanie zalecamy użycie usługi Network ATC. Aby uzyskać informacje na temat ręcznego wdrażania, zobacz repozytorium GitHub SDN.

iWARP

System iWARP korzysta z protokołu TCP (Transmission Control Protocol) i można go opcjonalnie ulepszyć za pomocą kontroli przepływu opartego na priorytcie (PFC) i rozszerzonej usługi transmisji (ETS).

Użyj protokołu iWARP, jeśli:

  • Nie masz doświadczenia w zarządzaniu sieciami RDMA.
  • Nie zarządzasz przełącznikami top-of-rack (ToR).
  • Po wdrożeniu nie będziesz zarządzać rozwiązaniem.
  • Masz już wdrożenia korzystające z protokołu iWARP.
  • Nie masz pewności, którą opcję wybrać.

RoCE

RoCE używa protokołu UDP (User Datagram Protocol) i wymaga pfC i ETS w celu zapewnienia niezawodności.

Użyj roCE, jeśli:

  • Masz już wdrożenia z roCE w centrum danych.
  • Dobrze zarządzasz wymaganiami sieci DCB.

RdMA gościa

Funkcja RDMA gościa umożliwia wykonywanie obciążeń SMB dla maszyn wirtualnych w celu uzyskania tych samych korzyści związanych z używaniem funkcji RDMA na hostach.

Odpowiednie typy ruchu: magazyn oparty na gościu

Wymagane certyfikaty: Obliczenia (Premium)

Podstawowe korzyści wynikające z używania funkcji RDMA gościa to:

  • Odciążanie procesora CPU do karty sieciowej na potrzeby przetwarzania ruchu sieciowego.
  • Bardzo małe opóźnienie.
  • Wysoka przepływność.

Aby uzyskać więcej informacji, pobierz dokument z repozytorium GitHub SDN.

Przełącznik osadzone tworzenia zespołu (SET)

SET to technologia tworzenia zespołu oparta na oprogramowaniu, która została uwzględniona w systemie operacyjnym Windows Server od systemu Windows Server 2016. SET to jedyna technologia tworzenia zespołu obsługiwana przez usługę Azure Stack HCI. Zestaw działa dobrze z ruchem obliczeniowym, magazynowym i zarządzania i obsługuje maksymalnie osiem kart w tym samym zespole.

Odpowiednie typy ruchu: obliczenia, magazyn i zarządzanie

Wymagane certyfikaty: Obliczenia (Standardowa) lub Obliczenia (Premium)

SET to jedyna technologia tworzenia zespołu obsługiwana przez usługę Azure Stack HCI. Zestaw działa dobrze z ruchem obliczeniowym, magazynem i zarządzaniem.

Ważne

Rozwiązanie Azure Stack HCI nie obsługuje tworzenia zespołu kart interfejsu sieciowego ze starszym równoważeniem obciążenia/trybem failover (LBFO). Aby uzyskać więcej informacji na temat rozwiązania LBFO w usłudze Azure Stack HCI, zobacz wpis w blogu Teaming in Azure Stack HCI (Tworzenie zespołu w usłudze Azure Stack HCI ).

ZESTAW jest ważny dla usługi Azure Stack HCI, ponieważ jest to jedyna technologia tworzenia zespołu, która umożliwia:

Funkcja SET wymaga użycia kart symetrycznych (identycznych). Symetryczne karty sieciowe to te, które mają takie same cechy:

  • producent (dostawca)
  • model (wersja)
  • szybkość (przepływność)
  • konfiguracja

W wersji 22H2 usługa Network ATC automatycznie wykryje i poinformuje Cię, czy wybrane karty są asymetryczne. Najprostszym sposobem ręcznego określenia, czy karty są symetryczne, jest to, czy szybkość i opisy interfejsów są dokładne dopasowania. Mogą one odbiegać tylko w liczbach wymienionych w opisie. Użyj polecenia cmdlet , aby upewnić się, że zgłoszona Get-NetAdapterAdvancedProperty konfiguracja zawiera te same wartości właściwości.

Zobacz poniższą tabelę, aby zapoznać się z przykładem opisów interfejsów, które odbiegają tylko od liczb (#):

Nazwisko Opis interfejsu Szybkość łącza
NIC1 Karta sieciowa nr 1 25 Gb/s
NIC2 Karta sieciowa nr 2 25 Gb/s
NIC3 Karta sieciowa nr 3 25 Gb/s
NIC4 Karta sieciowa 4 25 Gb/s

Uwaga

Zestaw obsługuje tylko konfigurację niezależną od przełącznika przy użyciu algorytmów równoważenia obciążenia dynamicznego lub portu funkcji Hyper-V. Aby uzyskać najlepszą wydajność, zaleca się używanie portu funkcji Hyper-V na wszystkich kartach sieciowych, które działają z szybkością co najmniej 10 Gb/s. Usługa NETWORK ATC wykonuje wszystkie wymagane konfiguracje dla zestawu.

Zagadnienia dotyczące ruchu RDMA

W przypadku implementacji dcB należy upewnić się, że konfiguracja PFC i ETS jest prawidłowo zaimplementowana na każdym porcie sieciowym, w tym na przełącznikach sieciowych. DcB jest wymagany dla roCE i opcjonalne dla iWARP.

Aby uzyskać szczegółowe informacje na temat wdrażania funkcji RDMA, pobierz dokument z repozytorium GitHub SDN.

Implementacje usługi Azure Stack HCI oparte na protokole RoCE wymagają konfiguracji trzech klas ruchu PFC, w tym domyślnej klasy ruchu w sieci szkieletowej i wszystkich hostach.

Klasa ruchu klastra

Ta klasa ruchu zapewnia wystarczającą przepustowość zarezerwowaną dla pulsów klastra:

  • Wymagany: Tak
  • Włączona funkcja PFC: Nie
  • Zalecany priorytet ruchu: priorytet 7
  • Zalecana rezerwacja przepustowości:
    • 10 GbE lub niższe sieci RDMA = 2 procent
    • 25 GbE lub wyższe sieci RDMA = 1 procent

Klasa ruchu RDMA

Ta klasa ruchu zapewnia wystarczającą przepustowość zarezerwowaną dla bezstratnej komunikacji RDMA przy użyciu protokołu SMB Direct:

  • Wymagany: Tak
  • Włączono funkcję PFC: Tak
  • Zalecany priorytet ruchu: priorytet 3 lub 4
  • Zalecana rezerwacja przepustowości: 50 procent

Domyślna klasa ruchu

Ta klasa ruchu przenosi cały inny ruch, który nie jest zdefiniowany w klastrze lub klasach ruchu RDMA, w tym ruchu maszyny wirtualnej i ruchu zarządzania:

  • Wymagane: domyślnie (nie jest wymagana konfiguracja na hoście)
  • Sterowanie przepływem (PFC)-enabled: Nie
  • Zalecana klasa ruchu: domyślnie (priorytet 0)
  • Zalecana rezerwacja przepustowości: domyślnie (nie jest wymagana żadna konfiguracja hosta)

Modele ruchu magazynu

Protokół SMB zapewnia wiele korzyści, ponieważ protokół magazynu dla rozwiązania Azure Stack HCI, w tym SMB Multichannel. Funkcja SMB Multichannel nie została omówiona w tym artykule, ale ważne jest, aby zrozumieć, że ruch jest multipleksowany w każdym możliwym linku, którego może używać funkcja SMB Multichannel.

Uwaga

Zalecamy używanie wielu podsieci i sieci VLAN do oddzielania ruchu magazynu w usłudze Azure Stack HCI.

Rozważmy następujący przykład klastra z czterema węzłami. Każdy serwer ma dwa porty magazynu (po lewej i prawej stronie). Ponieważ każda karta znajduje się w tej samej podsieci i sieci VLAN, funkcja SMB Multichannel rozłoży połączenia na wszystkie dostępne łącza. W związku z tym port po lewej stronie pierwszego serwera (192.168.1.1) spowoduje nawiązanie połączenia z portem po lewej stronie na drugim serwerze (192.168.1.2). Port po prawej stronie pierwszego serwera (192.168.1.12) połączy się z portem po prawej stronie na drugim serwerze. Podobne połączenia są ustanawiane dla trzeciego i czwartego serwera.

Jednak powoduje to niepotrzebne połączenia i powoduje przeciążenie w interlinku (grupa agregacji łącza z wieloma obudowami lub MC-LAG), która łączy przełączniki ToR (oznaczone symbolem Xs). Zobacz następujący diagram:

Diagram przedstawiający klaster z czterema węzłami w tej samej podsieci.

Zalecaną metodą jest użycie oddzielnych podsieci i sieci VLAN dla każdego zestawu kart. Na poniższym diagramie porty po prawej stronie używają teraz podsieci 192.168.2.x /24 i VLAN2. Dzięki temu ruch na portach po lewej stronie pozostanie na TOR1, a ruch na portach po prawej stronie pozostanie na tor2.

Diagram przedstawiający klaster z czterema węzłami w różnych podsieciach.

Alokacja przepustowości ruchu

W poniższej tabeli przedstawiono przykładowe alokacje przepustowości różnych typów ruchu przy użyciu typowych szybkości kart w usłudze Azure Stack HCI. Należy pamiętać, że jest to przykład rozwiązania konwergentnego, w którym wszystkie typy ruchu (obliczenia, magazyn i zarządzanie) działają na tych samych kartach fizycznych i są zespołowane przy użyciu zestawu.

Ponieważ ten przypadek użycia stanowi najwięcej ograniczeń, reprezentuje dobry punkt odniesienia. Jednak biorąc pod uwagę permutacje liczby kart i szybkości, należy to uznać za przykład, a nie wymaganie obsługi.

W tym przykładzie przyjmuje się następujące założenia:

  • Istnieją dwie karty na zespół.

  • Ruch warstwy magistrali magazynu (SBL), udostępnionego woluminu klastra (CSV) i funkcji Hyper-V (migracja na żywo):

    • Użyj tych samych kart fizycznych.
    • Użyj protokołu SMB.

  • Protokół SMB otrzymuje alokację przepustowości na 50 procent przy użyciu funkcji DCB.

    • SBL/CSV jest najwyższym priorytetem ruchu i otrzymuje 70 procent rezerwacji przepustowości SMB.
    • Migracja na żywo (LM) jest ograniczona przy użyciu Set-SMBBandwidthLimit polecenia cmdlet i otrzymuje 29 procent pozostałej przepustowości.

      • Jeśli dostępna przepustowość migracji na żywo wynosi >= 5 Gb/s, a karty sieciowe są w stanie, użyj funkcji RDMA. Aby to zrobić, użyj następującego polecenia cmdlet:

        Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

      • Jeśli dostępna przepustowość migracji na żywo wynosi < 5 Gb/s, użyj kompresji, aby skrócić czas zaciemnienia. Aby to zrobić, użyj następującego polecenia cmdlet:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

  • Jeśli używasz funkcji RDMA dla ruchu migracji na żywo, upewnij się, że ruch migracji na żywo nie może korzystać z całej przepustowości przydzielonej do klasy ruchu RDMA przy użyciu limitu przepustowości protokołu SMB. Należy zachować ostrożność, ponieważ to polecenie cmdlet przyjmuje wpis w bajtach na sekundę (Bps), podczas gdy karty sieciowe są wymienione w bitach na sekundę (bps). Użyj następującego polecenia cmdlet, aby ustawić limit przepustowości 6 Gb/s, na przykład:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

    Uwaga

    W tym przykładzie 750 MB/s odpowiada 6 Gb/s.

Oto przykładowa tabela alokacji przepustowości:

Szybkość karty sieciowej Przepustowość zespołowa Rezerwacja przepustowości protokołu SMB** SBL/CSV % Przepustowość SBL/CSV Procent migracji na żywo Maksymalna przepustowość migracji na żywo % pulsu Przepustowość pulsu
10 Gb/s 20 Gb/s 10 Gb/s 70% 7 Gb/s * 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

* Użyj kompresji, a nie RDMA, ponieważ alokacja przepustowości dla ruchu migracji na żywo wynosi <5 Gb/s.

** 50 procent jest przykładową rezerwacją przepustowości.

Klastry rozproszone

Klastry rozproszone zapewniają odzyskiwanie po awarii obejmujące wiele centrów danych. W najprostszej formie rozciągnięta sieć klastra azure Stack HCI wygląda następująco:

Diagram przedstawiający rozproszony klaster.

Wymagania dotyczące klastra rozproszonego

Ważne

Funkcja klastra rozproszonego jest dostępna tylko w usłudze Azure Stack HCI w wersji 22H2.

Klastry rozproszone mają następujące wymagania i cechy:

  • Funkcja RDMA jest ograniczona do jednej lokacji i nie jest obsługiwana w różnych lokacjach ani podsieciach.

  • Serwery w tej samej lokacji muszą znajdować się w tym samym stojaku i granicy warstwy 2.

  • Komunikacja między lokacjami musi przekraczać granicę warstwy 3; topologie rozproszone warstwy 2 nie są obsługiwane.

  • Mieć wystarczającą przepustowość, aby uruchamiać obciążenia w innej lokacji. W przypadku przejścia w tryb failover witryna alternatywna będzie musiała uruchomić cały ruch. Zalecamy aprowizowania lokacji na poziomie 50% ich dostępnej pojemności sieciowej. Nie jest to jednak wymagane, jeśli można tolerować niższą wydajność podczas pracy w trybie failover.

  • Karty używane do komunikacji między lokacjami:

    • Może to być wirtualna lub fizyczna (wirtualna sieć sieciowa hosta). Jeśli karty są wirtualne, musisz aprowizować jedną wirtualną kartę sieciową we własnej podsieci i sieć VLAN na fizyczną kartę sieciową.

    • Musi znajdować się we własnej podsieci i sieci VLAN, która może kierować się między lokacjami.

    • Funkcja RDMA musi być wyłączona Disable-NetAdapterRDMA przy użyciu polecenia cmdlet . Zalecamy jawne wymaganie, aby replika magazynu korzystała z określonych interfejsów przy użyciu Set-SRNetworkConstraint polecenia cmdlet .

    • Musi spełniać wszelkie dodatkowe wymagania dotyczące repliki magazynu.

Następne kroki