Udostępnij za pośrednictwem


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

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

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

Uwaga

Wymagania dotyczące przyszłych wersji rozwiązania Azure Stack HCI mogą ulec zmianie.

Przełączniki sieciowe dla rozwiązania Azure Stack HCI

Firma Microsoft testuje rozwiązanie Azure Stack HCI 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ń obsługujących wymagania rozwiązania Azure Stack HCI.

Ważne

Chociaż inne przełączniki sieciowe korzystające z technologii i protokołów, które nie zostały wymienione tutaj, mogą działać, firma Microsoft nie może zagwarantować, że będą współpracować z usługą Azure Stack HCI 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 dotyczące rozwiązania Azure Stack HCI dla określonych typów ról. Następujący dostawcy (w kolejności alfabetycznej) potwierdzili, że ich przełączniki obsługują wymagania dotyczące rozwiązania Azure Stack HCI:

Kliknij kartę dostawcy, aby wyświetlić zweryfikowane przełączniki dla każdego z typów ruchu rozwiązania Azure Stack HCI. 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 rozwiązania Azure Stack HCI. Te standardy pomagają zapewnić niezawodną komunikację między węzłami we wdrożeniach klastra rozwiązania Azure Stack HCI.

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 rozwiązania Azure Stack HCI i są wymagane we wszystkich scenariuszach.

Standardowa: IEEE 802.1Qbb

Przełączniki Ethernet używane do ruchu magazynu rozwiązania Azure Stack HCI 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 do ruchu magazynu rozwiązania Azure Stack HCI 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 rozwiązania Azure Stack HCI 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 dla usługi Azure Stack HCI 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 SDN usługi Azure Stack HCI 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 rozwiązania Azure Stack HCI 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.

Rozwiązanie Azure Stack HCI może działać w różnych architekturach centrów danych, w tym w 2-warstwowej (Spine-Leaf) i 3-warstwowej (Core-Aggregation-Access). Ta sekcja dotyczy bardziej pojęć z topologii Spine-Leaf, która jest często używana z obciążeniami w hiperkonwergentnej infrastrukturze, takiej jak Azure Stack HCI.

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 węzły klastra 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 usłudze Azure Stack HCI w wersji 22H2.

Ruch północno-południowy dla usługi Azure Stack HCI

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 Stack HCI

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 klastrze 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 Stack HCI, 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

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

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

Para interfejsu Podsieć Sieci 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 klastró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 wydatków kapitałowych (CAPEX), ale zależy od liczby węzłów w klastrze.
  • 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 klastra.

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 klastrze koszt kart sieciowych może przekroczyć koszt korzystania z przełączników sieciowych.
  • Nie skaluje się daleko poza trzywęźle klastry. 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 klastra jest złożone i wymaga zmian konfiguracji sprzętu i oprogramowania.

Następne kroki