Najlepsze praktyki projektowania tkanin Spine Leaf dla centrów danych

Najlepsze praktyki projektowania tkanin Spine Leaf dla centrów danych

Projektowanie wytrzymałych tkanin liściowo-grzbietowych

Projektowanie wytrzymałych tkanin liściowo-grzbietowych
  • W miarę jak obciążenia centrów danych stają się coraz bardziej rozproszone, wrażliwe na opóźnienia i intensywnie eksploatowane na osi wschód-zachód, architektura Leaf-Spine stała się domyślną architekturą dla nowych projektów i projektów modernizacji. Jednak wiele zespołów wciąż zmaga się z problemem przełożenia założeń wysokiego poziomu – skalowalności, odporności i przewidywalnej wydajności – na konkretne decyzje dotyczące topologii, modeli routingu i domen awarii w środowiskach wielu dostawców.

    W tym artykule skupimy się na praktycznych decyzjach projektowych dotyczących odpornej struktury typu leaf-spine: jak ustrukturyzować topologię fizyczną i logiczną, wybrać strategie routingu i ECMP oraz znaleźć równowagę między prostotą a skalowalnością. Na przykładowych platformach, takich jak Cisco Nexus, Juniper QFX i Aruba CX, przeniesiemy te opcje na rzeczywiste scenariusze wdrożeń, aby umożliwić standaryzację projektu struktury, który jest powtarzalny, obsługiwany i gotowy na przyszły rozwój.

Kompromisy w projektowaniu tkanin grzbietowo-liściowych

Zaprojektowanie struktury typu „grzbiet–liść”, która jest skalowalna, szybko zbieżna i pozostaje sprawna przez długi czas, jest ograniczone wyborem sprzętu, trasowaniem i potrzebami w zakresie odporności.

Kompromisy w projektowaniu tkanin grzbietowo-liściowych
  • Równoważenie skali, opóźnień i nadsubskrypcji

    Określanie prędkości portów spine/leaf, rozgałęzień i szerokości ECMP w celu spełnienia wymagań SLA dotyczących wzrostu i opóźnień bez nadmiernej rozbudowy lub tworzenia punktów zapalnych.

  • Złożoność polityki routingu i odporności

    Wybór pomiędzy warstwą 2, warstwą 3 lub EVPN-VXLAN oraz dostrajanie ECMP, szybkiej konwergencji i domen awarii bez kruchych konfiguracji.

  • Ryzyko związane z cyklem życia, interoperacyjnością i migracją

    Ewolucja od starszych projektów rdzeniowych do rozwiązań typu leaf-spine w mieszanych rodzinach przełączników, przy jednoczesnym unikaniu blokad, przerw w działaniu i fragmentacji operacji.

Projektowanie tkanin o strukturze grzbietu i liścia

Kluczowe decyzje projektowe mające na celu stworzenie skalowalnych, wytrzymałych tkanin grzbietowo-liściowych o przewidywalnym działaniu.

Najpierw prawa topologia

Wyrównanie poziomów grzbietu i liści, nadsubskrypcji i portów do przepływów wschód–zachód aplikacji.

Trasowanie zbudowane z myślą o skalowalności

Użyj ECMP i EVPN-VXLAN, aby uprościć rozwój i zapewnić interoperacyjność wielu dostawców w ramach Nexus, QFX i Aruba CX.

Odporność w projektowaniu

Projektuj z myślą o szybkiej konwergencji, izolowaniu awarii i konserwacji bez przestojów we wszystkich węzłach sieci.

Porównanie rodziny platform tkaninowych Spine-Leaf

Porównaj przełączniki Cisco, Juniper i Aruba Spine–Leaf pod kątem skali, odporności i zgodności operacyjnej EVPN-VXLAN.

Cecha Cisco Nexus Spine & Leaf Liść-kolce jałowca QFX
Aruba CX Data Center Fabric (gorąca)
Wynik dla Ciebie
Główny cel projektu Wysoka gęstość 25/40/100/400G dla dużych struktur Clos i centrów danych obsługujących dużą liczbę protokołów ECMP. EVPN-VXLAN-centryczny układ leaf-spine z silną skalą routingu i segmentacją struktury. Skalowalna, zorientowana na wysoką dostępność infrastruktura z uproszczonym cyklem życia, telemetrią i automatyzacją. Dopasuj platformę do tego, czy Twoim głównym czynnikiem jest przepustowość, skala trasowania czy prostota operacyjna.
Idealny rozmiar i etap wdrożenia Najlepiej sprawdza się w przypadku dojrzałych lub szybko rozwijających się centrów danych wymagających bardzo dużej liczby portów i konstrukcji wielomodułowych. Dobrze nadaje się do wdrażania nowych sieci EVPN i migracji poprzemysłowych wymagających zaawansowanych zasad routingu. Optymalne rozwiązanie dla organizacji, które wdrażają standaryzację w oparciu o nowoczesne rozwiązania typu spine-leaf, ale chcą wprowadzać je stopniowo i bezproblemowo. Wybierz Nexus na bardzo dużą skalę, QFX w przypadku struktur opartych na polityce, Aruba CX w przypadku pragmatycznego, etapowego wdrażania.
Możliwości EVPN-VXLAN i routingu Solidne wsparcie VXLAN/EVPN, doskonałe do ról bram L2/L3 i dużych domen ECMP. Bogaty zestaw funkcji EVPN (typ 5, zaawansowane zasady), duża skalowalność płaszczyzny sterowania dla projektów obejmujących wiele segmentów. Kompleksowa sieć EVPN-VXLAN ze szczególnym naciskiem na łatwość konfiguracji i spójność pomiędzy różnymi rolami infrastruktury. Wybierz QFX, jeśli potrzebujesz zaawansowanych zasad EVPN; Aruba CX, jeśli zależy Ci na wydajnej zasadzie EVPN z prostszą konfiguracją.
Odporność i konwergencja Dojrzały ECMP, szybka konwergencja, obsługa opcji multi-chassis i zaawansowane funkcje HA. Szybkie przełączanie awaryjne z precyzyjnymi kontrolami routingu; świetne rozwiązanie w przypadku złożonych scenariuszy awarii podkładu/nakładek. Wbudowane najlepsze praktyki HA, opcje aktualizacji bez błędów i przejrzyste przepływy pracy operacyjnej dla zmian struktury. Wszystkie trzy są odporne; Aruba CX kładzie nacisk na przewidywalne ulepszenia i prostsze radzenie sobie z awariami.
Automatyzacja i operacje dnia 2 Bogate możliwości programistyczne (NX-API, narzędzia NX-OS); większe wysiłki na rzecz standaryzacji w dużych zespołach. Zaawansowana automatyzacja i skryptowanie Junos; potężne, ale może wymagać głębszej wiedzy na temat sieci. Zunifikowany system operacyjny i narzędzia z intuicyjną automatyzacją struktury, telemetrią i widokami rozwiązywania problemów. Jeśli kompetencje operacyjne są zróżnicowane, Aruba CX może obniżyć ryzyko i skrócić czas potrzebny do osiągnięcia wartości w porównaniu ze wysoce spersonalizowanymi rozwiązaniami.
Zestaw umiejętności i dopasowanie do ekosystemu Dobrze dopasowane, jeśli już obsługujesz sieci i narzędzia Cisco DC (TAC, DCNM/NDFC itp.). Najlepiej sprawdza się w sytuacjach, gdy Junos jest standardem lub zespoły cenią sobie dogłębność CLI/netconf i kulturę otwartej automatyzacji. Dostępne dla zespołów o różnym poziomie doświadczenia, płynnie integruje się z szerszymi środowiskami Aruba/HP. Pozostań przy znanym Ci dostawcy, aby szybciej wdrożyć nowe rozwiązanie, lub wykorzystaj Aruba CX, aby uprościć operacje międzyzespołowe.
Całkowity koszt posiadania i rozważania dotyczące cyklu życia Wybór sprzętu jest szeroki; licencjonowanie i poziomy funkcji mogą powodować zwiększenie złożoności całkowitego kosztu posiadania (TCO) w perspektywie długoterminowej. Konkurencyjny sprzęt; wartość jest maksymalna, gdy wykorzystujesz zaawansowane możliwości routingu/EVPN. Zaprojektowano w celu zmniejszenia kosztów operacyjnych poprzez prostsze operacje, spójny system operacyjny i przewidywalne ścieżki rozbudowy infrastruktury. Jeśli dominują OpEx i ryzyko operacyjne, Aruba CX często zapewnia lepszą ekonomikę cyklu życia.
Kiedy ustalić priorytety Stosuj, gdy potrzebujesz rozwiązania typu spine–leaf o bardzo dużej gęstości i wielu lokalizacjach ze ścisłą integracją z ekosystemem Cisco. Stosuj, gdy głównymi czynnikami wyróżniającymi są bogactwo zasad EVPN i skala routingu. Stosuj, gdy chcesz mieć nowoczesny grzbiet – liść o dużej sprężystości, ale musi on zachować prostą konstrukcję i obsługę. Określ, czy najważniejsza jest przepustowość, wyrafinowanie routingu czy prostota obsługi, a następnie dokonaj wyboru odpowiednio.

Potrzebujesz pomocy? Eksperci techniczni dostępni od zaraz.

  • +1-626-655-0998 (Stany Zjednoczone)
    UTC 15:00-00:00
  • +852-2592-5389 (Hongkong)
    UTC 00:00-09:00
  • +852-2592-5411 (Hongkong)
    UTC 06:00-15:00
Potrzebujesz pomocy? Eksperci techniczni dostępni od zaraz.

Przykłady zastosowań tkaniny grzbietowo-liściowej

Zaprojektowane dla centrów danych i lokalizacji brzegowych, które wymagają skalowalnych struktur typu spine–leaf z przewidywalnym opóźnieniem, odpornym routingiem ECMP i operacjami gotowymi do automatyzacji.

Struktury centrów danych w chmurze i wirtualizowane

Struktury centrów danych w chmurze i wirtualizowane

  • Zbuduj skalowalną infrastrukturę typu leaf-spine dla klastrów chmury prywatnej obsługujących zwirtualizowane obciążenia, z jednakowym opóźnieniem wschód-zachód i nieblokującą się przepustowością między szafami serwerów.
  • Wdrażaj sieci nakładkowe EVPN-VXLAN na bazie stabilnego systemu bazowego Leaf-Spine, aby segmentować użytkowników i aplikacje w środowiskach wielostanowiskowych lub wielopodowych.
  • Standaryzacja oparta na przełącznikach Cisco Nexus lub Juniper QFX 25/100/400G o wysokiej gęstości na poziomie szkieletu i liścia pozwala uprościć rozbudowę infrastruktury w miarę dodawania nowych szaf obliczeniowych i pamięci masowej.
Klastry AI/HPC i obliczenia o niskim opóźnieniu

Klastry AI/HPC i obliczenia o niskim opóźnieniu

  • Projektuj deterministyczne topologie typu leaf–spine w celu połączenia węzłów GPU i HPC, zapewniając niskie opóźnienia i wysoką przepustowość ruchu wschód–zachód na potrzeby rozproszonego szkolenia i obciążeń o wysokiej wydajności.
  • Wykorzystaj routing oparty na ECMP i inżynierię ruchu wielodrogowego w przełącznikach szkieletowych, aby unikać punktów zapalnych i zachować przewidywalne czasy realizacji zadań podczas intensywnych obliczeń lub sztucznej inteligencji.
  • Wykorzystaj szybkie łącza uplink 100/200/400G na serwerach Nexus, QFX lub Aruba CX, aby skalować moduły AI lub wyspy HPC w miarę wzrostu rozmiarów klastrów bez konieczności przeprojektowywania rdzenia sieci.
Odświeżenie rdzenia przedsiębiorstwa i centrum danych kampusowych

Odświeżenie rdzenia przedsiębiorstwa i centrum danych kampusowych

  • Zmodernizuj starsze, trójwarstwowe rdzenie centrów danych przedsiębiorstw, przekształcając je w struktury Leaf-Spine zapewniające przewidywalną przepustowość na potrzeby wirtualizacji, VDI i krytycznych aplikacji biznesowych.
  • Wdrożenie routingu opartego na EVPN-VXLAN na warstwie liściowej pozwala uprościć segmentację sieci między zasobami kampusu, brzegu sieci WAN i centrum danych, przy jednoczesnym zachowaniu centralizacji zasad routingu.
  • Wprowadź redundantne szkielety i zróżnicowane łącza uplink przy użyciu platform Aruba CX lub Cisco Nexus, aby planowana konserwacja lub awarie pojedynczych urządzeń nie wpłynęły na dostępność aplikacji korporacyjnych.
Centra danych brzegowych dla wielu najemców i dostawców usług

Centra danych brzegowych dla wielu najemców i dostawców usług

  • Twórz kompaktowe, ale skalowalne struktury Leaf-Spine w lokalizacjach metropolitalnych lub brzegowych, aby obsługiwać obciążenia wielu dzierżawców, węzły CDN lub funkcje sieciowe z jednolitą łącznością między szafami.
  • Użyj EVPN-VXLAN na przełącznikach QFX lub Nexus, aby tworzyć wirtualne struktury izolowane od użytkowników, jednocześnie zachowując prostą warstwę bazową IP, którą łatwo zautomatyzować i obsługiwać na dużą skalę.
  • Zaprojektuj redundantne pary szkieletowe i podwójne sieci liściowe skierowane do dostawców nadrzędnych, aby dostęp, agregacja i usługi skierowane do klientów pozostały dostępne podczas awarii łączy lub urządzeń.
Kolokacja i środowiska rackowe o wysokiej gęstości

Kolokacja i środowiska rackowe o wysokiej gęstości

  • Zapewnij spójną przepustowość wschód–zachód między klatkami lub rzędami w obiektach kolokacji, stosując standaryzację struktur typu spine–leaf zamiast doraźnych projektów ToR i agregacji.
  • Zaoferuj elastyczne prędkości portów na przełącznikach bazowych, takie jak łącza downlink 10/25G i łącza uplink 40/100/400G, aby obsługiwać różne profile serwerów klientów bez konieczności ponownego okablowania rdzenia struktury.
  • Użyj redundantnych łączy uplink do wielu rdzeni i szybkich projektów routingu konwergentnego, aby połączenia krzyżowe skierowane do klientów i ścieżki między stojakami pozostały stabilne podczas zaplanowanych i nieplanowanych zdarzeń.

Najczęściej zadawane pytania

Jak wybrać pomiędzy przełącznikami Cisco, Juniper i Aruba dla mojej struktury Spine–Leaf?

  • W strukturze typu spine-leaf zazwyczaj preferowanym rozwiązaniem jest Cisco Nexus (na przykład N9K-C9316D-GX, N9K-C9364C, N9K-C93240YC-FX2), gdy system Cisco NX-OS jest już standardem, konieczna jest ścisła integracja z łańcuchami narzędzi Cisco DC lub wymagane jest bardzo gęste zagęszczenie portów spine 100/400G.
  • Protokół Juniper QFX (np. JNP:QFX5120-48Y-AFI, QFX5200-32C-AFO, JNP:QFX5210-64C-D-AFI2) jest często wybierany, gdy planujesz architekturę EVPN-VXLAN-first i preferujesz spójność routingu opartą na protokole Junos w całym centrum danych i sieci WAN.
  • Aruba CX (na przykład ARB:S0F84A, ARB:R8Z96A, ARB:JL708C) to doskonały wybór, jeśli szukasz skalowalnego, ekonomicznego rozwiązania typu leaf-spine z systemem operacyjnym Aruba CX, automatyzacją struktury AOS-CX lub ścisłą integracją z kampusem/brzegiem sieci Aruba.
  • Z praktycznego punktu widzenia, podejmując decyzję, należy wziąć pod uwagę posiadane umiejętności operacyjne (NX-OS vs Junos vs AOS-CX), zaplanowaną nakładkę (EVPN-VXLAN vs L3-only), pożądane prędkości portów (10/25/40/100/400G) oraz stos automatyzacji. Następnie możemy przyporządkować te wymagania do konkretnych jednostek SKU w każdej rodzinie.

Czy mogę mieszać przełączniki różnych dostawców w tej samej strukturze spine-leaf, zachowując przy tym ECMP i odporność?

  • Tak, technicznie rzecz biorąc, możliwe jest tworzenie struktur typu spine-leaf obejmujących wielu dostawców, jeśli podkład będzie oparty na standardach (na przykład BGP lub OSPF z ECMP, standardowym MTU i spójnych zasadach haszowania).
  • Popularnym wzorcem jest rdzeń/spine oparty na Cisco Nexus (N9K-C9316D-GX lub N9K-C9364C) z Juniper QFX lub Aruba CX na warstwie liściowej, ale zwiększa to złożoność projektowania i rozwiązywania problemów, dlatego zwykle zalecamy zachowanie jednorodności co najmniej każdej warstwy (spine vs leaf).
  • Jeśli planujesz sieć EVPN-VXLAN obejmującą wielu dostawców, musisz zweryfikować interoperacyjność każdej wersji systemu operacyjnego pod kątem rodzin adresów BGP EVPN, typów tras i wszelkich rozszerzeń dostawców. Zalecamy przeprowadzenie walidacji laboratoryjnej przed rozpoczęciem produkcji i przypięciem wersji dla wszystkich urządzeń.

Ile rdzeni i jaki współczynnik nadsubskrypcji powinienem zaplanować dla tych modeli przełączników?

  • W przypadku większości sieci korporacyjnych zbudowanych z przełączników takich jak N9K-C93180YC-FX3S, JNP:QFX5120-48Y-AFO lub ARB:R8P14A na skrzydle minimalna liczba rdzeni to dwa rdzenie, natomiast w celu zapewnienia większej odporności i elastyczności konserwacji standardowo stosuje się cztery rdzenie.
  • Gęstość portów szkieletowych (na przykład 32x100G w modelu QFX5200-32C-AFO lub 64x100G w modelu JNP:QFX5210-64C-D-AFI2) zwykle ogranicza liczbę liści obsługiwanych w pełnej siatce, więc liczba liści i liczba łączy w górę dla każdego liścia (2, 4 lub 8) bezpośrednio determinują model szkieletowy i liczbę.
  • Przypominamy, że podczas projektowania należy obliczyć jawny współczynnik nadsubskrypcji (liczba łączy w dół w porównaniu do liczby łączy w górę na ToR) na podstawie profilu obciążenia, a nie dążyć do teoretycznej struktury nieblokującej, która rzadko jest konieczna w przypadku mieszanych obciążeń przedsiębiorstwa.

O jakich zastrzeżeniach dotyczących wdrażania należy pamiętać, włączając EVPN-VXLAN na przełącznikach typu spine–leaf?

  • Cisco Nexus, Juniper QFX i Aruba CX obsługują technologię EVPN-VXLAN tylko na określonych platformach i wersjach oprogramowania, więc pierwszym krokiem jest potwierdzenie, że konkretne kody SKU i wersje systemu operacyjnego, które planujesz (na przykład N9K-C93180YC-FX i N9K-C93180YC-FX3S lub QFX5100-48S-AFO i QFX5120-48Y) mają parzystość funkcji dla typów tras EVPN, multihomingu (jeśli jest wymagany) i skalowania płaszczyzny sterowania.
  • Należy również wyrównać zasady MTU i haszowania na wszystkich szlakach (pines) i liściach (leaf), zarezerwować TCAM na potrzeby przekazywania VXLAN/EVPN oraz zdefiniować spójny plan VNI/VLAN. Niedopełnienie tego warunku jest częstą przyczyną powstawania okresowych czarnych dziur w ruchu lub asymetrycznych ścieżek w środowiskach ECMP.
  • W przypadku złożonych projektów, takich jak struktury EVPN wielomodułowe lub wielostanowiskowe, zalecamy wczesne zaangażowanie doświadczonego architekta; nasz bezpłatne wsparcie CCIE może pomóc w weryfikacji specyfikacji materiałowej i projektu ogólnego przed zakupem sprzętu. Uwaga: Szczegółowe warunki gwarancji i usługi wsparcia mogą się różnić w zależności od produktu i regionu. Aby uzyskać szczegółowe informacje, zapoznaj się z oficjalnymi informacjami. W celu uzyskania dalszych informacji prosimy o kontakt: router-switch.com.

A co z cyklem życia, ryzykiem EOL i przyszłą skalowalnością tych przełączników typu spine-leaf?

  • Wybierając przełączniki takie jak N9K-C92300YC, N9K-C9332C, QFX5100-48S-AFO lub ARB:JL708C do nowej struktury, należy upewnić się, że nie zbliża się koniec ich sprzedaży lub zakończenia wsparcia technicznego, aby nie zablokować nowych usług na kurczącej się platformie.
  • Praktycznym podejściem jest sprawdzenie każdego kandydującego SKU w naszym Sprawdzanie EOL/EOSL i faworyzują platformy, które mają jeszcze długą mapę rozwoju oprogramowania i sprzętu, zwłaszcza jeśli planujesz stopniowe dodawanie kolejnych platform typu spine lub leaf w ciągu najbliższych 3–5 lat.
  • Aby zapewnić skalowalność, należy wziąć pod uwagę wzrost prędkości portu (na przykład przyszłe przejście na 100G/400G), skalę tras (liczbę VRF i VNI) oraz wymagania bufora/TCAM dla EVPN. Może to skłonić Cię do wyboru nowszych rodzin rozwiązań, takich jak N9K-C93180YC-FX3, QFX5210 lub najnowszej linii centrów danych Aruba CX.

Jakie są główne ryzyka związane z zakupem, wysyłką i wsparciem technicznym podczas tworzenia nowego materiału typu spine-leaf z wykorzystaniem tych kodów SKU?

  • Stan magazynowy konkretnych modeli, takich jak N9K-C93240YC-FX2, JNP:QFX5110-48S-D-AFO2 lub ARB:R8Z96A, może się różnić, dlatego czas realizacji zamówienia będzie zależał od dostępności produktu i miejsca docelowego. Aktualny widok opcji wysyłki i regionów, które możemy obsługiwać, można znaleźć w naszej witrynie. metody wysyłki.
  • Podatki importowe, cła i lokalne przepisy mogą mieć wpływ na całkowity koszt i proces dostawy; zalecamy zapoznanie się z naszymi wskazówkami dotyczącymi podatki i cła i skoordynować działania z wewnętrznym działem logistyki lub agentem celnym przed złożeniem dużego zamówienia na tkaninę.
  • W przypadku ryzyka związanego z serwisem i sprzętem zapoznaj się z naszą Polityka gwarancyjna równolegle z wszelkimi umowami wsparcia technicznego oferowanymi przez dostawcę, z których planujesz skorzystać, i upewnij się, że masz jasny proces RMA; szczegółowe kroki dotyczące postępowania w przypadku awarii sprzętu opisano w naszym instrukcje zwrotuUwaga: Szczegółowe warunki gwarancji i usługi wsparcia mogą się różnić w zależności od produktu i regionu. Szczegółowe informacje można znaleźć w oficjalnych informacjach. W celu uzyskania dalszych informacji prosimy o kontakt: router-switch.com.

Więcej rozwiązań

Beyond Bandwidth: The 100G+ Data Center Architecture

Poza przepustowością: architektura centrum danych 100G+

Niezbędny fundament 100G — wzrost gotowy na sztuczną inteligencję, wydajność bez opóźnień

Centrum danych
GPU Cluster Networking Solutions for AI Scale-Out

Rozwiązania sieciowe klastrów GPU do skalowania AI

Projektuj wydajne struktury Ethernet dla klastrów GPU AI z uwzględnieniem skalowalnej topologii, przełączania o niskich opóźnieniach i architektury gotowej do wdrożenia.

Sieciowanie klastrów GPU AI
Enterprise Rack & Cabling Design

Projektowanie szaf i okablowania dla przedsiębiorstw

Najlepsze praktyki dotyczące układu szaf i okablowania — łatwość serwisowania, etykietowanie, przepływ powietrza i planowanie przyszłej rozbudowy.

Stojaki i okablowanie