Udostępnij za pośrednictwem

Wymagania dotyczące sieci hosta dla platformy Azure Local

  • Artykuł

Dotyczy: Azure Local 2311.2 i nowsze

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 wykorzystywany przez administratora do zarządzania systemem, taki jak Zdalny Pulpit, Windows Admin Center, Active Directory itp.
  • Ruch obliczeniowy: ruch pochodzący z maszyny wirtualnej lub kierowany do maszyny wirtualnej.
  • Ruch magazynu: Ruch związany z użyciem bloku komunikatów serwera (SMB), na przykład Zasadnicze Miejsca do Przechowywania lub migracji na żywo opartej na SMB. Ten ruch jest ruchem warstwy drugiej i nie można go routować.

Ważne

Replika pamięci używa ruchu SMB nieopartego na RDMA. To i kierunkowy charakter ruchu (Północ-Południe) sprawia, że jest ściśle dostosowane do ruchu "zarządzania" wymienionego powyżej, podobnie jak w tradycyjnym udziale plików.

Wybieranie karty sieciowej

Karty sieciowe są kwalifikowane na podstawie typów ruchu sieciowego, do których zostały przeznaczone (patrz powyżej). Podczas przeglądania katalogu Windows Server, certyfikacja Windows Server 2022 teraz wskazuje na jedną lub więcej z następujących ról. Przed zakupem maszyny dla Azure Local musisz mieć co najmniej jedną kartę, która jest kwalifikowana do zarządzania, obliczeń i przechowywania, ponieważ wszystkie trzy typy ruchu są wymagane w 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 kwalifikacji karty sieciowej opartej na rolach, zobacz ten wpis na 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 Standard obliczeń Standard Przechowywania
Maksymalna nagroda Nie dotyczy Obliczenia w warstwie Premium Storage Premium

Uwaga

Najwyższa kwalifikacja dla dowolnego adaptera w naszym ekosystemie będzie zawierać Zarządzanie, Compute Premium i Storage Premium.

Zrzut ekranu przedstawia kwalifikacje „Certyfikowane dla systemu Windows”, w tym funkcje Zarządzanie, Obliczenia Premium i Magazyn Premium.

Wymagania dotyczące sterowników

Sterowniki skrzynki odbiorczej nie są obsługiwane do użycia z platformą Azure Local. Aby określić, czy adapter używa wbudowanego sterownika, uruchom następujące polecenie cmdlet. Karta używa wbudowanego sterownika, 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ą:

  • Dynamiczny wielokolejkowy układ maszyn wirtualnych (dynamic VMMQ lub d.VMMQ)
  • Zdalny bezpośredni dostęp do pamięci (RDMA)
  • RDMA gość
  • Przełącznik osadzonego zespołowego (SET)

Dynamiczny program VMMQ

Wszystkie adaptery sieciowe z kwalifikacją Compute (Premium) obsługują Dynamic VMMQ. Dynamiczna funkcja VMMQ wymaga użycia technologii Switch Embedded Teaming.

Odpowiednie typy ruchu: przetwarzanie

Wymagane certyfikaty: Obliczenia (Premium)

Dynamic VMMQ to inteligentna technologia po stronie odbioru. Bazuje na swoich poprzednich wersjach Virtual Machine Queue (VMQ), Virtualnego Skalowania po Stronie Odbierającej (vRSS) i VMMQ, aby zapewnić trzy podstawowe ulepszenia:

  • Optymalizuje wydajność hosta przy użyciu mniejszej liczby rdzeni.
  • Automatyczne dostrajanie przetwarzania ruchu sieciowego do rdzeni procesora CPU, co umożliwia maszynom wirtualnym spełnienie i utrzymanie oczekiwanej przepływności.
  • Umożliwia skokowym obciążeniom 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 przeniesienie funkcji stosu sieciowego na kartę sieciową. Umożliwia to ruchowi magazynu SMB ominięcie systemu operacyjnego w celu bezpośredniego 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 (Standard)

Wszystkie adaptery z certyfikacją magazynową (Standardowa) lub magazynową (Premium) obsługują funkcję RDMA po stronie hosta. Aby uzyskać więcej informacji na temat korzystania z RDMA z obciążeniami gościa, zobacz sekcję "Guest RDMA" 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) ani nie czujesz się komfortowo, zarządzając nimi.
  • 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 oraz ETS w celu zapewnienia niezawodności.

Użyj RoCE, jeśli:

  • Masz już wdrożenia z RoCE w swoim centrum danych.
  • Swobodnie 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: magazynowanie oparte na gościach

Wymagane certyfikaty: Przetwarzanie (Premium)

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

  • Przerzucenie zadań z procesora na kartę sieciową w celu przetwarzania ruchu sieciowego.
  • Bardzo małe opóźnienie.
  • Wysoka przepływność.

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

Zespołowe osadzanie przełączników (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. SET działa dobrze z ruchem obliczeniowym, magazynowym i zarządzającym i obsługuje maksymalnie osiem adapterów w tym samym zespole.

Odpowiednie typy ruchu: przetwarzanie, przechowywanie i zarządzanie

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

SET to jedyna technologia tworzenia zespołu obsługiwana przez platformę Azure Local. SET działa dobrze w zakresie ruchu obliczeniowego, przechowywania i zarządzania.

Ważne

Usługa Azure Local nie obsługuje zespolenia kart sieciowych z starszym rozwiązaniem Load Balancing/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 ).

Platforma SET jest istotna dla Azure Local, ponieważ jest to jedyna technologia teamingu, która umożliwia:

Funkcja SET wymaga użycia symetrycznych (identycznych) adapterów. 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ę, jeśli wybrane karty są niesymetryczne. Najprostszym sposobem ręcznego określenia, czy adaptery są symetryczne, jest sprawdzenie, czy szybkości i opisy interfejsów są dokładnie dopasowane. Mogą one odbiegać tylko w liczbach wymienionych w opisie. Użyj cmdlet Get-NetAdapterAdvancedProperty, aby upewnić się, że zgłoszona 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 numer 2 25 Gb/s
NIC3 Karta sieciowa Nr 3 25 Gbps
NIC4 Karta sieciowa #4 25 Gb/s

Uwaga

SET obsługuje tylko konfigurację niezależną od przełącznika przy użyciu algorytmów równoważenia obciążenia: dynamicznego lub Hyper-V Port. 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 SET.

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 opcjonalny 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 niezdefiniowany w klasach ruchu systemowego lub RDMA, w tym ruch maszyn wirtualnych i zarządzający.

  • Wymagane: domyślnie (nie jest wymagana konfiguracja na hoście)
  • Sterowanie przepływem (PFC) włączone: 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 oferuje wiele korzyści jako protokół magazynowania dla usługi Azure Local, 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 danych magazynowych w Azure Local.

Rozważmy następujący przykład systemu czterech węzłów. Każda maszyna ma dwa porty pamięci (po lewej i prawej stronie). Ponieważ każdy adapter znajduje się w tej samej podsieci i sieci VLAN, SMB Multichannel rozprowadzi 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 przeciąża łącze międzysieciowe (grupa agregacji łączy wielokrotnej obudowy lub MC-LAG), która łączy przełączniki ToR (oznaczone symbolem X). 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 sieciowych. 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 (przetwarzanie, przechowywanie i zarządzanie) działają na tych samych kartach fizycznych i są zespołowane przy użyciu SET.

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

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

  • Są dwa adaptery na zespół.

  • Ruch Storage Bus Layer (SBL), Cluster Shared Volume (CSV) i Hyper-V (migracja na żywo):

    • Użyj tych samych adapterów fizycznych.
    • Użyj protokołu SMB.

  • SMB otrzymuje alokację przepustowości wynoszącą 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 za pomocą polecenia cmdlet Set-SMBBandwidthLimit i otrzymuje 29 procent pozostałej przepustowości.

      • Jeśli dostępna przepustowość migracji na żywo wynosi >= 5 Gb/s i karty sieciowe obsługują RDMA, 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. Uważaj, ponieważ to polecenie cmdlet przyjmuje wpis w bajtach na sekundę (Bps), a karty sieciowe są podane 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ść sygnału pulsacyjnego
10 Gbps 20 Gbps 10 Gb/s 70% 7 Gb/s * 200 Mb/s
25 Gb/s 50 Gbps 25 Gbit/s 70% 17,5 Gb/s 29% 7,25 Gb/s 1% 250 Mb/s
40 Gb/s 80 Gb/s 40 Gbps 70% 28 Gbps 29% 11,6 Gb/s 1% 400 Mb/s
50 Gb/s 100 Gb/s 50 Gb/s 70% 35 Gbps 29% 14,5 Gb/s 1% 500 Mb/s
100 Gbps 200 Gb/s 100 Gb/s 70% 70 Gbps 29% 29 Gbps 1% 1 Gbps
200 Gbps 400 Gbps 200 Gbps 70% 140 Gb/s 29% 58 Gbps 1% 2 Gbps

* 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 w granicach warstwy 2.

  • Komunikacja między witrynami musi przekraczać granicę sieciową warstwy 3; rozciągnięte topologie warstwy 2 nie są obsługiwane.

  • Mieć wystarczającą przepustowość, aby uruchamiać obciążenia na innej lokalizacji. W przypadku przełączenia awaryjnego witryna alternatywna będzie musiała obsłużyć cały ruch. Zalecamy aprovisionowania witryn 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.

  • Adaptery używane do komunikacji między stronami:

    • Może być fizyczna lub wirtualna (vNIC hosta). Jeśli adaptery są wirtualne, musisz skonfigurować jedną wirtualną kartę sieciową w jej własnej podsieci i VLAN dla każdej fizycznej karty sieciowej.

    • Musi znajdować się we własnej podsieci i sieci VLAN, która umożliwia routowanie między lokacjami.

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

    • Musi spełniać wszelkie dodatkowe wymagania dotyczące Repliki magazynowej.

Następne kroki