Udostępnij za pośrednictwem

Wymagania dotyczące sieci fizycznej dla usługi Azure Local

  • Artykuł

Dotyczy: Azure Local, wersje 23H2 i 22H2

W tym artykule omówiono zagadnienia i wymagania dotyczące sieci fizycznej (sieci szkieletowej) dotyczące usługi Azure Local, szczególnie w przypadku przełączników sieciowych.

Uwaga

Wymagania dotyczące przyszłych wersji lokalnych platformy Azure mogą ulec zmianie.

Przełączniki sieciowe dla usługi Azure Local

Firma Microsoft testuje usługę Azure Local do standardów i protokołów zidentyfikowanych w sekcji Wymagania dotyczące przełącznika sieciowego poniżej. Chociaż firma Microsoft nie certyfikowa przełączników sieciowych, współpracujemy z dostawcami w celu identyfikowania urządzeń, które obsługują wymagania lokalne platformy Azure.

Ważne

Chociaż inne przełączniki sieciowe korzystające z technologii i protokołów, które nie zostały wymienione w tym miejscu, mogą działać, firma Microsoft nie może zagwarantować, że będą współpracować z platformą Azure Lokalnie i mogą nie być w stanie pomóc w rozwiązywaniu problemów, które występują.

Podczas zakupu przełączników sieciowych skontaktuj się z dostawcą przełącznika i upewnij się, że urządzenia spełniają wymagania lokalne platformy Azure dotyczące określonych typów ról. Następujący dostawcy (w kolejności alfabetycznej) potwierdzili, że ich przełączniki obsługują wymagania lokalne platformy Azure:

Kliknij kartę dostawcy, aby wyświetlić zweryfikowane przełączniki dla każdego z typów ruchu lokalnego platformy Azure. Te klasyfikacje sieci można znaleźć tutaj.

Ważne

Aktualizujemy te listy w miarę informowania o zmianach przez dostawców przełączników sieciowych.

Jeśli przełącznik nie jest dołączony, skontaktuj się z dostawcą przełącznika, aby upewnić się, że model przełącznika i wersja systemu operacyjnego przełącznika spełniają wymagania w następnej sekcji.

Wymagania dotyczące przełącznika sieciowego

W tej sekcji wymieniono standardy branżowe, które są obowiązkowe dla określonych ról przełączników sieciowych używanych we wdrożeniach lokalnych platformy Azure. Te standardy pomagają zapewnić niezawodną komunikację między węzłami we wdrożeniach lokalnych platformy Azure.

Uwaga

Karty sieciowe używane do obsługi ruchu obliczeniowego, magazynu i zarządzania wymagają sieci Ethernet. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące sieci hosta.

Poniżej przedstawiono obowiązkowe standardy i specyfikacje IEEE:

Wymagania dotyczące roli 23H2

Wymaganie Zarządzanie Storage Compute (Standard) Obliczenia (SDN)
Wirtualne sieci LAN ✓ ✓ ✓ ✓
Sterowanie przepływem priorytetu ✓
Rozszerzony wybór transmisji ✓
Identyfikator sieci VLAN portu LLDP ✓
Nazwa sieci VLAN protokołu LLDP ✓ ✓ ✓
Agregacja łącza LLDP ✓ ✓ ✓ ✓
Konfiguracja systemu ETS LLDP ✓
Zalecenie dotyczące systemu ETS w ramach protokołu LLDP ✓
Konfiguracja protokołu PFC protokołu LLDP ✓
Maksymalny rozmiar ramki LLDP ✓ ✓ ✓ ✓
Maksymalna jednostka transmisji ✓
Protokół Border Gateway Protocol ✓
DHCP Relay Agent ✓

Uwaga

Funkcja RDMA gościa wymaga zarówno obliczeń (w warstwie Standardowa) jak i magazynu.

Standardowa: IEEE 802.1Q

Przełączniki Ethernet muszą być zgodne ze specyfikacją IEEE 802.1Q definiującą sieci VLAN. Sieci VLAN są wymagane w przypadku kilku aspektów usługi Azure Local i są wymagane we wszystkich scenariuszach.

Standardowa: IEEE 802.1Qbb

Przełączniki Ethernet używane na potrzeby ruchu magazynu lokalnego platformy Azure muszą być zgodne ze specyfikacją IEEE 802.1Qbb, która definiuje priorytetową kontrolę przepływu (PFC). Funkcja PFC jest wymagana, gdy używane jest mostkowanie centrum danych (DCB). Ponieważ funkcja DCB może być używana zarówno w scenariuszach RoCE, jak i iWARP RDMA, 802.1Qbb jest wymagana we wszystkich scenariuszach. Wymagane są co najmniej trzy priorytety klasy usług (CoS) bez obniżania możliwości przełącznika lub szybkości portów. Co najmniej jedna z tych klas ruchu musi zapewnić bezstratną komunikację.

Standardowa: IEEE 802.1Qaz

Przełączniki Ethernet używane na potrzeby ruchu magazynu lokalnego platformy Azure muszą być zgodne ze specyfikacją IEEE 802.1Qaz definiującą ulepszoną transmisję select (ETS). SYSTEM ETS jest wymagany, gdy jest używana funkcja DCB. Ponieważ dcB może być używany zarówno w scenariuszach RoCE, jak i iWARP RDMA, 802.1Qaz jest wymagany we wszystkich scenariuszach.

Co najmniej trzy priorytety cos są wymagane bez obniżania możliwości przełącznika lub szybkości portu. Ponadto jeśli urządzenie zezwala na definiowanie stawek QoS ruchu przychodzącego, zalecamy, aby nie konfigurować stawek ruchu przychodzącego ani konfigurować ich do dokładnie takiej samej wartości jak stawki ruchu wychodzącego (ETS).

Uwaga

Hiperkonwergentna infrastruktura ma wysoką zależność od komunikacji w warstwie Wschodnio-Zachodnia-2 w tym samym stojaku i w związku z tym wymaga systemu ETS. Firma Microsoft nie testuje usługi Azure Local z wyróżnionym punktem kodu usług (DSCP).

Standardowa: IEEE 802.1AB

Przełączniki Ethernet muszą być zgodne ze specyfikacją IEEE 802.1AB, która definiuje protokół LLDP (Link Layer Discovery Protocol). Protokół LLDP jest wymagany w przypadku usługi Azure Local i umożliwia rozwiązywanie problemów z konfiguracjami sieci fizycznej.

Konfiguracja wartości typu LLDP (TLV) musi być włączona dynamicznie. Przełączniki nie mogą wymagać dodatkowej konfiguracji poza włączeniem określonego TLV. Na przykład włączenie podtypu 802.1 powinno automatycznie anonsować wszystkie sieci VLAN dostępne na portach przełącznika.

Niestandardowe wymagania TLV

Protokół LLDP umożliwia organizacjom definiowanie i kodowanie własnych niestandardowych wirtualnych woluminów TLV. Są one nazywane specyficznymi dla organizacji przełącznikami TLV. Wszystkie typy TLV specyficzne dla organizacji zaczynają się od wartości typ TLV LLDP 127. W poniższej tabeli przedstawiono, które podtypy niestandardowe TLV (TLV typu 127) specyficzne dla organizacji są wymagane.

Organizacja Podtyp TLV
IEEE 802.1 Identyfikator sieci VLAN portu (podtyp = 1)
IEEE 802.1 Nazwa sieci VLAN (podtyp = 3)
Co najmniej 10 sieci VLAN
IEEE 802.1 Agregacja łącza (podtyp = 7)
IEEE 802.1 Konfiguracja ETS (podtyp = 9)
IEEE 802.1 Zalecenie ETS (podtyp = A)
IEEE 802.1 Konfiguracja PFC (podtyp = B)
IEEE 802.3 Maksymalny rozmiar ramki (podtyp = 4)

Maksymalna jednostka transmisji

Maksymalna jednostka transmisji (MTU) to największa ramka lub pakiet, który można przesyłać za pośrednictwem łącza danych. Do hermetyzacji sieci SDN wymagany jest zakres od 1514 do 9174.

Protokół Border Gateway Protocol

Przełączniki Ethernet używane na potrzeby ruchu obliczeniowego lokalnej sieci SDN platformy Azure muszą obsługiwać protokół BGP (Border Gateway Protocol). Protokół BGP to standardowy protokół routingu używany do wymiany informacji o routingu i osiągalności między co najmniej dwiema sieciami. Trasy są automatycznie dodawane do tabeli tras wszystkich podsieci z włączoną propagacją protokołu BGP. Jest to wymagane do włączenia obciążeń dzierżawy z siecią SDN i dynamiczną komunikacją równorzędną. RFC 4271: Border Gateway Protocol 4

DHCP Relay Agent

Przełączniki Ethernet używane na potrzeby ruchu zarządzania lokalnego platformy Azure muszą obsługiwać agenta przekaźnika DHCP. Agent przekazywania DHCP jest dowolnym hostem TCP/IP, który służy do przesyłania żądań i odpowiedzi między serwerem DHCP a klientem, gdy serwer jest obecny w innej sieci. Jest to wymagane w przypadku usług rozruchowych PXE. RFC 3046: DHCPv4 lub RFC 6148: DHCPv4

Ruch sieciowy i architektura

Ta sekcja dotyczy głównie administratorów sieci.

Usługa Azure Local może działać w różnych architekturach centrum danych, w tym w 2-warstwowej (Spine-Leaf) i 3-warstwowej (Core-Aggregation-Access). Ta sekcja odnosi się bardziej do pojęć z topologii spine-leaf, która jest często używana z obciążeniami w hiperkonwergentnej infrastrukturze, takiej jak Azure Local.

Modele sieciowe

Ruch sieciowy można sklasyfikować według jego kierunku. Tradycyjne środowiska sieci magazynowania (SAN) są mocno północno-południowe, gdzie ruch przepływa z warstwy obliczeniowej do warstwy magazynowania w granicach warstwy 3 (IP). Infrastruktura hiperkonwergentna jest bardziej mocno wschodnio-zachodnia, gdzie znaczna część ruchu pozostaje w granicach warstwy 2 (VLAN).

Ważne

Zdecydowanie zalecamy, aby wszystkie maszyny lokalne platformy Azure w lokacji znajdowały się fizycznie w tym samym stojaku i podłączone do tych samych przełączników top-of-rack (ToR).

Uwaga

Funkcja klastra rozproszonego jest dostępna tylko w wersji lokalnej platformy Azure w wersji 22H2.

Ruch północno-południowy dla platformy Azure — lokalny

Ruch północno-południowy ma następujące cechy:

  • Ruch przepływa z przełącznika ToR do kręgosłupa lub z kręgosłupa do przełącznika ToR.
  • Ruch opuszcza stojak fizyczny lub przekracza granicę warstwy 3 (IP).
  • Obejmuje zarządzanie (program PowerShell, centrum administracyjne systemu Windows), obliczenia (maszynę wirtualną) i ruch klastra rozproszonego między lokacjami.
  • Używa przełącznika Ethernet do łączności z siecią fizyczną.

Ruch wschodnio-zachodni dla usługi Azure Local

Ruch wschodnio-zachodni ma następujące cechy:

  • Ruch pozostaje w obrębie przełączników tor i granicy warstwy 2 (VLAN).
  • Obejmuje ruch magazynu lub ruch migracji na żywo między węzłami w tym samym systemie i (jeśli korzystasz z klastra rozproszonego) w tej samej lokacji.
  • Może używać przełącznika Ethernet (przełączonego) lub bezpośredniego (bez przełącznika), zgodnie z opisem w dwóch następnych sekcjach.

Używanie przełączników

Ruch północno-południowy wymaga użycia przełączników. Oprócz korzystania z przełącznika Ethernet obsługującego wymagane protokoły dla usługi Azure Local, najważniejszym aspektem jest odpowiedni rozmiar sieci szkieletowej sieci szkieletowej.

Należy zrozumieć przepustowość sieci szkieletowej "nieblokująca", którą mogą obsługiwać przełączniki Ethernet, i zminimalizować (lub najlepiej wyeliminować) nadmierną subskrypcję sieci.

Typowe punkty przeciążenia i podsubskrypcja, takie jak grupa agregacji linków z wieloma obudowami używanymi do nadmiarowości ścieżki, można wyeliminować poprzez odpowiednie użycie podsieci i sieci VLAN. Zobacz również Wymagania dotyczące sieci hosta.

Skontaktuj się z dostawcą sieci lub zespołem pomocy technicznej sieci, aby upewnić się, że przełączniki sieciowe zostały prawidłowo dopasowane do obciążenia, które zamierzasz uruchomić.

Korzystanie z przełącznika bez przełącznika

Usługa Azure Local obsługuje połączenia bez przełączników (bezpośrednie) dla ruchu wschodnio-zachodniego dla wszystkich rozmiarów systemu, o ile każdy węzeł w systemie ma nadmiarowe połączenie z każdym węzłem w systemie. Jest to nazywane połączeniem "full-mesh".

Diagram przedstawiający łączność bez przełącznika z pełną siatką

Para interfejsu Podsieć Sieć VLAN
Wirtualna nazwa sieciowa hosta mgmt Dostosowane do potrzeb klienta Dostosowane do potrzeb klienta
SMB01 192.168.71.x/24 711
SMB02 192.168.72.x/24 712
SMB03 192.168.73.x/24 713

Uwaga

Korzyści wynikające z wdrożeń bez przełączników zmniejszają się w przypadku systemów większych niż trzy węzły ze względu na wymaganą liczbę kart sieciowych.

Zalety połączeń bez przełączników

  • Żaden zakup przełącznika nie jest konieczny dla ruchu wschodnio-zachodniego. Przełącznik jest wymagany dla ruchu północno-południowego. Może to spowodować obniżenie kosztów kapitałowych (CAPEX), ale zależy od liczby węzłów w systemie.
  • Ponieważ nie ma przełącznika, konfiguracja jest ograniczona do hosta, co może zmniejszyć potencjalną liczbę wymaganych kroków konfiguracji. Ta wartość zmniejsza się wraz ze wzrostem rozmiaru systemu.

Wady połączeń bez przełączników

  • W przypadku schematów adresów IP i podsieci wymagany jest więcej planowania.
  • Zapewnia tylko dostęp do magazynu lokalnego. Ruch związany z zarządzaniem, ruchem maszyny wirtualnej i innym ruchem wymagającym dostępu do północy na południe nie może używać tych kart.
  • Wraz ze wzrostem liczby węzłów w systemie koszt kart sieciowych może przekroczyć koszt korzystania z przełączników sieciowych.
  • Nie skaluje się daleko poza trzywęźle systemy. Więcej węzłów wiąże się z dodatkowymi okablowaniami i konfiguracją, które mogą przekroczyć złożoność korzystania z przełącznika.
  • Rozszerzanie systemu jest złożone, wymagając zmian konfiguracji sprzętu i oprogramowania.

Następne kroki