Udostępnij za pośrednictwem

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

Dotyczy: Azure Local 2311.2 i nowsze

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 zgodnie ze standardami i protokołami zidentyfikowanymi w poniższej sekcji Wymagania dotyczące przełącznika sieciowego. 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 przetwarzania, przechowywania 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 24H2

Wymaganie Zarządzanie Magazyn Obliczenia (Standard) Funkcje obliczeniowe (SDN)
Wirtualne sieci LAN ✓ ✓ ✓ ✓
Sterowanie ruchem priorytetowym ✓
Rozszerzony wybór transmisji ✓
Identyfikator VLAN portu LLDP ✓
Nazwa VLAN protokołu LLDP ✓ ✓ ✓
Agregacja łącza LLDP ✓ ✓ ✓ ✓
Konfiguracja systemu ETS LLDP ✓
Zalecenie LLDP ETS ✓
Konfiguracja PFC LLDP ✓
Maksymalny rozmiar ramki LLDP ✓ ✓ ✓ ✓
Maksymalna jednostka transmisji ✓
Border Gateway Protocol ✓
Agent przekazywania DHCP ✓

Uwaga

RDMA gościa wymaga zarówno obliczeń w Standardzie, jak i pamięci masowej.

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 tam, gdzie stosowane jest Data Center Bridging (DCB). Ze względu na to, że DCB może być używane zarówno w scenariuszach RoCE, jak i iWARP RDMA, 802.1Qbb jest wymagane 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ą ulepszony wybór transmisji (ETS). ETS jest wymagany tam, gdzie używany jest DCB. Ponieważ DCB może być używany zarówno w scenariuszach RoCE, jak i iWARP RDMA, 802.1Qaz jest wymagany w każdym z tych scenariuszy.

Wymagane są co najmniej trzy priorytety CoS bez obniżania możliwości przełącznika i 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

Infrastruktura hiperkonwergentna ma wysoką zależność od komunikacji w warstwie 2 w kierunku Wschód-Zachód w ramach tego samego regału i w związku z tym wymaga systemu ETS. Microsoft nie testuje Azure Local z Differentiated Services Code Point (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 Typ-Długość-Wartości (TLV) dla LLDP powinna być dynamicznie włączana. Przełączniki nie mogą wymagać żadnej dodatkowej konfiguracji oprócz włączenia określonego TLV. Na przykład włączenie podtypu 802.1 Typ 3 powinno automatycznie ogłaszać wszystkie sieci VLAN dostępne na portach przełącznika.

Niestandardowe wymagania TLV

Protokół LLDP umożliwia organizacjom definiowanie i kodowanie własnych niestandardowych TLV. Nazywa się je specyficznymi dla organizacji TLV. Wszystkie TLV specyficzne dla organizacji rozpoczynają się od wartości typu TLV LLDP o numerze 127. Poniższa tabela pokazuje, które podtypy Niestandardowych TLV Specyficznych dla Organizacji (Typ TLV 127) 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 Linków (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.

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 umożliwienia pracy z obciążeniami najemców w zakresie SDN i dynamicznego peeringu. RFC 4271: Border Gateway Protocol 4

Agent przekazywania DHCP

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 pamięci masowej (SAN) charakteryzują się znacznym ruchem typu północ-południe, gdzie ruch przepływa z warstwy obliczeniowej do warstwy magazynowania, przekraczając granicę warstwy 3 (IP). Infrastruktura hiperkonwergentna jest bardziej zdominowana przez ruch poziomy, gdzie znaczna część ruchu pozostaje w obrębie granicy warstwy drugiej (VLAN).

Ważne

Wymagamy, aby wszystkie lokalne maszyny platformy Azure w miejscu były fizycznie umieszczone 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 w osi północ-południe dla usługi Azure Local

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

  • Ruch sieciowy przepływa z przełącznika ToR do rdzenia i z powrotem z rdzenia do przełącznika ToR.
  • Ruch sieciowy opuszcza fizyczną szafę 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 granic warstwy 2 (VLAN).
  • Obejmuje ruch związany z przechowywaniem danych lub ruch związany z migracją Live między węzłami w tym samym systemie oraz (jeśli używa się klastra rozproszonego) w tej samej lokalizacji.
  • Może używać przełącznika Ethernet (z przełączaniem) lub bezpośredniego połączenia (bez przełączania), 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.

Należy zrozumieć przepustowość "nieblokującego" mechanizmu przenoszenia danych, którą mogą obsługiwać przełączniki Ethernet, i zminimalizować (lub najlepiej wyeliminować) przeciążenie sieci.

Typowe punkty przeciążenia i nadsubskrypcja, takie jak grupa agregacji linków wielopłaszczyznowych używana 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 bez użycia 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. Nazywa się to połączeniem „pełnej siatki”.

Diagram przedstawiający pełnomeszową łączność bezprzełącznikową

Para interfejsów Podsieć 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 oraz innym ruchem, który wymaga dostępu od północy do południa, nie może korzystać z tych kart.
  • W miarę wzrostu liczby węzłów w systemie, koszt adapterów sieciowych może przekroczyć koszt użycia przełączników sieciowych.
  • Nie skaluje się dobrze poza systemy trzywęzłowe. 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