Udostępnij za pośrednictwem

Wymagania dotyczące sieci hosta dla platformy Azure Local

  • Artykuł

Dotyczy: Azure Local, wersje 23H2 i 22H2

W tym temacie omówiono zagadnienia i wymagania dotyczące sieci hostów dla platformy Azure Local. Aby uzyskać informacje na temat architektur centrów danych i połączeń fizycznych między maszynami, 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 lokalny platformy Azure można sklasyfikować w zamierzonym celu:

  • Ruch zarządzania: ruch do lub spoza systemu lokalnego. Na przykład ruch repliki magazynu lub ruch używany przez administratora do zarządzania systemem, takiego jak pulpit zdalny, Windows Admin Center, 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 maszyny dla usługi Azure Local 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 Local. 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 wpis w blogu systemu Windows Server.

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 Storage Standard
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 platformą Azure Local. 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 Local 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 Local 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

Funkcja InfiniBand (IB) nie jest obsługiwana w usłudze Azure Local.

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 platformę Azure Local. 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 platformę Azure Local. Zestaw działa dobrze z ruchem obliczeniowym, magazynem i zarządzaniem.

Ważne

Usługa Azure Local 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 LBFO w środowisku lokalnym platformy Azure, zobacz wpis w blogu Teaming in Azure Local (Tworzenie zespołu w usłudze Azure Local ).

ZESTAW jest ważny dla platformy Azure Local, 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 lokalne platformy Azure oparte na protokole RoCE wymagają konfiguracji trzech klas ruchu PFC, w tym domyślnej klasy ruchu w sieci szkieletowej i wszystkich hostach.

Klasa ruchu systemowego

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

  • 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 niezdefiniowane w klasach ruchu systemowego lub RDMA, w tym ruchu maszyny wirtualnej i 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 usługi Azure Local, w tym protokół 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 Local.

Rozważmy następujący przykład systemu czterech węzłów. Każdy komputer 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 na pierwszej maszynie (192.168.1.1) spowoduje nawiązanie połączenia z portem po lewej stronie na drugiej maszynie (192.168.1.2). Port po prawej stronie pierwszego komputera (192.168.1.12) połączy się z portem po prawej stronie drugiej maszyny. Podobne połączenia są ustanawiane dla trzeciej i czwartej maszyny.

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 system 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 system 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 adapterów w usłudze Azure Local. 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 rozproszony klaster usługi Azure Local 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 wersji lokalnej platformy Azure 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.

  • Maszyny 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