Opracowaliśmy projekt sieci centrum danych pozwalający na wdrażanie klastrów obliczeniowych większych niż 100 tysięcy serwerów o szczytowej przepustowości w bisekcji powyżej jednego petabajta na sekundę.
Z raportu Dmitrija Afanasjewa dowiesz się o podstawowych zasadach nowego projektu, topologiach skalowania, problemach z tym związanych, możliwościach ich rozwiązania, funkcjach routingu i skalowaniu funkcji płaszczyzny przesyłania nowoczesnych urządzeń sieciowych w „gęsto połączonych” topologie z dużą liczbą tras ECMP. Ponadto Dima krótko opowiedział o organizacji łączności zewnętrznej, warstwie fizycznej, systemie okablowania i sposobach dalszego zwiększania przepustowości.
- Dzień dobry wszystkim! Nazywam się Dmitry Afanasyev, jestem architektem sieci w Yandex i projektuję głównie sieci centrów danych.
Moja historia będzie dotyczyć zaktualizowanej sieci centrów danych Yandex. To w dużej mierze ewolucja projektu, który mieliśmy, ale jednocześnie pojawiło się kilka nowych elementów. Jest to prezentacja poglądowa, ponieważ w krótkim czasie trzeba było zawrzeć dużo informacji. Zaczniemy od wyboru topologii logicznej. Następnie nastąpi przegląd płaszczyzny sterowania i problemów ze skalowalnością płaszczyzny danych, wybór tego, co będzie się działo na poziomie fizycznym, a także przyjrzymy się niektórym funkcjom urządzeń. Poruszmy trochę kwestię tego, co dzieje się w centrum danych z MPLS, o czym rozmawialiśmy już jakiś czas temu.
Czym więc jest Yandex pod względem ładunków i usług? Yandex jest typowym hiperskalerem. Jeśli patrzymy na użytkowników, przetwarzamy przede wszystkim żądania użytkowników. Również różne usługi przesyłania strumieniowego i przesyłania danych, ponieważ mamy również usługi przechowywania. Jeśli bliżej backendu, to pojawiają się tam obciążenia infrastruktury i usługi, takie jak rozproszona pamięć obiektowa, replikacja danych i oczywiście trwałe kolejki. Jednym z głównych typów obciążeń jest MapReduce i podobne systemy, przetwarzanie strumieniowe, uczenie maszynowe itp.
Jaka jest infrastruktura, na której to wszystko się dzieje? Ponownie jesteśmy dość typowym hiperskalerem, chociaż być może jesteśmy trochę bliżej mniejszej strony widma hiperskalarnej. Ale mamy wszystkie atrybuty. Tam, gdzie to możliwe, używamy sprzętu towarowego i skalowania poziomego. Mamy pełny Pooling zasobów: nie pracujemy z pojedynczymi maszynami, pojedynczymi stojakami, ale łączymy je w dużą pulę wymiennych zasobów z kilkoma dodatkowymi usługami związanymi z planowaniem i alokacją i pracujemy z całą tą pulą.
Mamy więc kolejny poziom – system operacyjny na poziomie klastra obliczeniowego. Bardzo ważne jest, abyśmy w pełni kontrolowali stos technologii, z którego korzystamy. Kontrolujemy punkty końcowe (hosty), sieć i stos oprogramowania.
Posiadamy kilka dużych centrów danych w Rosji i za granicą. Łączy je szkielet wykorzystujący technologię MPLS. Nasza wewnętrzna infrastruktura jest prawie w całości zbudowana na protokole IPv6, ale ponieważ musimy obsługiwać ruch zewnętrzny, który nadal przychodzi głównie przez IPv4, musimy w jakiś sposób dostarczać żądania przychodzące przez IPv4 do serwerów frontendowych, a trochę więcej trafiać do zewnętrznego Internetu IPv4 - na przykład na przykład do indeksowania.
W kilku ostatnich iteracjach projektów sieci centrów danych wykorzystywano wielowarstwowe topologie Clos i dotyczyły one wyłącznie warstwy L3. Jakiś czas temu opuściliśmy L2 i odetchnęliśmy z ulgą. Wreszcie nasza infrastruktura obejmuje setki tysięcy instancji obliczeniowych (serwerowych). Jeszcze jakiś czas temu maksymalny rozmiar klastra wynosił około 10 tysięcy serwerów. Wynika to w dużej mierze z tego, jak mogą działać te same systemy operacyjne na poziomie klastra, programy planujące, alokacja zasobów itp. Ponieważ postęp nastąpił po stronie oprogramowania infrastrukturalnego, docelowy rozmiar wynosi obecnie około 100 tysięcy serwerów w jednym klastrze obliczeniowym, a Mamy zadanie - umieć budować fabryki sieciowe, które pozwolą na efektywne łączenie zasobów w takim klastrze.
Czego oczekujemy od sieci centrów danych? Przede wszystkim jest dużo taniego i dość równomiernie rozłożonego pasma. Ponieważ sieć jest szkieletem, dzięki któremu możemy łączyć zasoby. Nowa docelowa wielkość to około 100 tysięcy serwerów w jednym klastrze.
Nam też oczywiście zależy na skalowalnej i stabilnej płaszczyźnie sterowania, bo na tak dużej infrastrukturze mnóstwo problemów pojawia się nawet od zwyczajnie losowych zdarzeń, a nie chcemy, żeby płaszczyzna sterowania przyprawiała nas też o bóle głowy. Jednocześnie chcemy zminimalizować panujący w nim stan. Im mniejszy stan, tym lepiej i stabilniej wszystko działa i tym łatwiej jest zdiagnozować.
Oczywiście automatyzacja jest nam potrzebna, bo nie da się ręcznie zarządzać taką infrastrukturą i to już od jakiegoś czasu jest niemożliwe. Potrzebujemy wsparcia operacyjnego w jak największym stopniu oraz wsparcia CI/CD w takim zakresie, w jakim jest to możliwe.
Przy takich rozmiarach centrów danych i klastrów zadanie wspierania przyrostowego wdrażania i rozbudowy bez przerywania świadczenia usług stało się dość pilne. Jeżeli na klastrach liczących tysiąc, a może blisko dziesięć tysięcy maszyn udałoby się je jeszcze wdrożyć w ramach jednej operacji – czyli planujemy rozbudowę infrastruktury i w ramach jednej operacji dodanych zostanie kilka tysięcy maszyn, wtedy klaster liczący sto tysięcy maszyn nie powstaje od razu, lecz rozłożony w czasie. Pożądane jest, aby przez cały ten czas dostępna była już wypompowana infrastruktura, która została wdrożona.
I jedno wymaganie, które mieliśmy i zostawiliśmy: obsługa multitenancy, czyli wirtualizacji lub segmentacji sieci. Teraz nie musimy tego robić na poziomie struktury sieci, ponieważ fragmentacja przeszła do hostów, co bardzo ułatwiło nam skalowanie. Dzięki IPv6 i dużej przestrzeni adresowej nie musieliśmy stosować zduplikowanych adresów w infrastrukturze wewnętrznej, cała adresacja była już unikalna. A dzięki temu, że przenieśliśmy filtrowanie i segmentację sieci na hosty, nie musimy tworzyć żadnych wirtualnych podmiotów sieciowych w sieciach data center.
Bardzo ważną rzeczą jest to, czego nie potrzebujemy. Jeśli uda się usunąć niektóre funkcje z sieci, znacznie ułatwia to życie i z reguły poszerza wybór dostępnego sprzętu i oprogramowania, czyniąc diagnostykę bardzo prostą.
Czego więc nie potrzebujemy, z czego byliśmy w stanie zrezygnować, nie zawsze z radością w momencie, gdy to się wydarzyło, ale z wielką ulgą, gdy proces się zakończy?
Przede wszystkim porzucenie L2. Nie potrzebujemy L2, ani prawdziwego, ani emulowanego. Nieużywane w dużej mierze ze względu na to, że kontrolujemy stos aplikacji. Nasze aplikacje są skalowalne poziomo, działają z adresacją L3, nie martwią się zbytnio, że wygasła jakaś pojedyncza instancja, po prostu wdrażają nową, nie trzeba jej wdrażać pod starym adresem, bo jest odrębny poziom wykrywania usług i monitorowania maszyn znajdujących się w klastrze. Nie delegujemy tego zadania na sieć. Zadaniem sieci jest dostarczanie pakietów z punktu A do punktu B.
Nie mamy też sytuacji, w których adresy przemieszczają się w sieci i trzeba to monitorować. W wielu projektach jest to zazwyczaj potrzebne do obsługi mobilności maszyn wirtualnych. Nie wykorzystujemy mobilności maszyn wirtualnych w wewnętrznej infrastrukturze wielkiego Yandexa, a ponadto uważamy, że nawet jeśli tak się stanie, nie powinno się to zdarzyć przy wsparciu sieciowym. Jeśli rzeczywiście trzeba to zrobić, to trzeba to zrobić na poziomie hosta i wypchnąć adresy, które mogą migrować do nakładek, aby nie dotykać i nie wprowadzać zbyt wielu dynamicznych zmian w systemie routingu samego podkładu (sieci transportowej) .
Kolejną technologią, z której nie korzystamy, jest multicast. Jeśli chcesz, mogę Ci szczegółowo powiedzieć dlaczego. To znacznie ułatwia życie, bo jeśli ktoś się z tym uporał i patrzył dokładnie jak wygląda płaszczyzna sterowania multicastem, we wszystkich instalacjach poza najprostszymi, to jest to duży ból głowy. A co więcej, ciężko znaleźć np. dobrze działającą implementację open source.
Wreszcie projektujemy nasze sieci tak, aby nie zmieniały się zbytnio. Możemy liczyć na to, że przepływ zdarzeń zewnętrznych w systemie routingu jest niewielki.
Jakie problemy się pojawiają i jakie ograniczenia należy wziąć pod uwagę budując sieć centrum danych? Koszt, oczywiście. Skalowalność, poziom do jakiego chcemy się rozwijać. Konieczność rozbudowy bez zatrzymywania usługi. Przepustowość, dostępność. Widoczność tego, co dzieje się w sieci, dla systemów monitorujących, dla zespołów operacyjnych. Wsparcie automatyzacji - znowu w miarę możliwości, ponieważ różne zadania można rozwiązywać na różnych poziomach, łącznie z wprowadzaniem dodatkowych warstw. Cóż, nie [prawdopodobnie] zależy od dostawców. Choć w różnych okresach historycznych, w zależności od tego, na który dział się spojrzy, tę niezależność było łatwiej lub trudniej osiągnąć. Jeśli weźmiemy przekrój chipów do urządzeń sieciowych, to do niedawna mówienie o niezależności od dostawców było bardzo warunkowe, jeśli chcieliśmy także chipów o dużej przepustowości.
Jakiej topologii logicznej użyjemy do budowy naszej sieci? To będzie wielopoziomowe Clos. Tak naprawdę w tej chwili nie ma realnych alternatyw. A topologia Clos jest całkiem dobra, nawet w porównaniu z różnymi zaawansowanymi topologiami, które są obecnie bardziej w obszarze zainteresowań akademickich, jeśli mamy duże przełączniki radix.
Jak z grubsza zbudowana jest wielopoziomowa sieć Clos i jak nazywają się w niej poszczególne elementy? Przede wszystkim wzrósł wiatr, aby zorientować się, gdzie jest północ, gdzie jest południe, gdzie jest wschód, gdzie jest zachód. Sieci tego typu budowane są zazwyczaj przez te, które mają bardzo duży ruch zachód-wschód. Jeśli chodzi o pozostałe elementy, na górze znajduje się wirtualny przełącznik złożony z mniejszych przełączników. To jest główna idea rekurencyjnej budowy sieci Clos. Bierzemy elementy z jakąś podstawą i łączymy je tak, aby to, co otrzymamy, można było uznać za przełącznik z większą podstawą. Jeśli potrzebujesz jeszcze więcej, procedurę można powtórzyć.
W przypadku np. Clos dwupoziomowego, kiedy na moim schemacie da się jednoznacznie zidentyfikować składowe, które są pionowe, zwykle nazywa się je płaszczyznami. Gdybyśmy zbudowali Closa z trzema poziomami przełączników kręgosłupa (z których wszystkie nie są przełącznikami granicznymi ani ToR i które służą tylko do tranzytu), wówczas samoloty wyglądałyby na bardziej złożone; dwupoziomowe wyglądają dokładnie tak. Blok ToR lub przełączniki liściowe i powiązane z nimi przełączniki kręgosłupa pierwszego poziomu nazywamy Pod. Przełączniki kręgosłupa na poziomie kręgosłupa-1 na górze kapsuły to górna część kapsuły, górna część kapsuły. Przełączniki znajdujące się na górze całej fabryki to górna warstwa fabryki, górna część tkaniny.
Oczywiście pojawia się pytanie: sieci Clos budowane są od jakiegoś czasu, sam pomysł na ogół wywodzi się z czasów klasycznej telefonii, sieci TDM. Może pojawiło się coś lepszego, może można coś zrobić lepiej? Tak i nie. Teoretycznie tak, w praktyce w najbliższej przyszłości na pewno nie. Ponieważ istnieje wiele interesujących topologii, niektóre z nich są nawet wykorzystywane w produkcji, np. Dragonfly jest używany w aplikacjach HPC; Istnieją również ciekawe topologie, takie jak Xpander, FatClique, Jellyfish. Jeśli spojrzeć na raporty z ostatnich konferencji takich jak SIGCOMM czy NSDI, można znaleźć dość dużą liczbę prac dotyczących alternatywnych topologii, które mają lepsze właściwości (takie czy inne) niż Clos.
Ale wszystkie te topologie mają jedną interesującą właściwość. Uniemożliwia to ich wdrożenie w sieciach centrów danych, które staramy się budować na sprzęcie towarowym i które kosztują całkiem rozsądne pieniądze. We wszystkich tych alternatywnych topologiach większość przepustowości nie jest niestety dostępna najkrótszymi ścieżkami. Tym samym od razu tracimy możliwość korzystania z tradycyjnej płaszczyzny sterowania.
Teoretycznie rozwiązanie problemu jest znane. Są to np. modyfikacje stanu łącza przy użyciu k-najkrótszej ścieżki, ale znowu nie ma takich protokołów, które byłyby zaimplementowane seryjnie i powszechnie dostępne na sprzęcie.
Co więcej, ponieważ większość możliwości nie jest dostępna najkrótszymi ścieżkami, musimy zmodyfikować coś więcej niż tylko płaszczyznę sterowania, aby wybrać wszystkie te ścieżki (a przy okazji, jest to znacznie więcej stanów w płaszczyźnie sterowania). Musimy jeszcze zmodyfikować płaszczyznę spedycyjną i z reguły wymagane są co najmniej dwie dodatkowe funkcje. Jest to możliwość jednorazowego podjęcia wszystkich decyzji dotyczących przekazania pakietów np. na hoście. W rzeczywistości jest to routing źródła; czasami w literaturze dotyczącej sieci połączeń wzajemnych nazywa się to decyzjami o przekazywaniu „wszystko na raz”. A routing adaptacyjny to funkcja, której potrzebujemy na elementach sieci, co sprowadza się np. do tego, że wybieramy kolejny przeskok na podstawie informacji o najmniejszym obciążeniu kolejki. Możliwe są na przykład inne opcje.
Zatem kierunek jest interesujący, ale niestety nie możemy go teraz zastosować.
OK, zdecydowaliśmy się na topologię logiczną Clos. Jak to skalujemy? Zobaczmy, jak to działa i co można zrobić.
W sieci Clos istnieją dwa główne parametry, które możemy w jakiś sposób zmieniać i uzyskać określone wyniki: podstawa elementów i liczba poziomów w sieci. Mam schematyczny diagram pokazujący, jak oba wpływają na rozmiar. Najlepiej połączyć jedno i drugie.
Można zauważyć, że ostateczna szerokość sieci Clos jest iloczynem wszystkich poziomów przełączników kręgosłupa południowej podstawy, liczby nieaktywnych połączeń i sposobu rozgałęzień. W ten sposób skalujemy wielkość sieci.
Jeśli chodzi o pojemność, szczególnie w przypadku przełączników ToR, istnieją dwie opcje skalowania. Albo możemy, zachowując ogólną topologię, zastosować szybsze łącza, albo możemy dodać więcej płaszczyzn.
Jeżeli spojrzysz na rozszerzoną wersję sieci Clos (w prawym dolnym rogu) i wrócisz do tego zdjęcia z siecią Clos poniżej...
... to jest dokładnie ta sama topologia, tyle że na tym slajdzie jest ona zwinięta bardziej zwięźle, a płaszczyzny fabryki nakładają się na siebie. To jest to samo.
Jak w liczbach wygląda skalowanie sieci Clos? Tutaj podaję dane, jaką maksymalną szerokość można uzyskać w sieci, jaką maksymalną liczbę szaf, przełączników ToR lub przełączników liściowych, jeśli nie są w szafach, możemy uzyskać w zależności od tego, jaką podstawę przełączników zastosujemy dla poziomów grzbietu, oraz z ilu poziomów korzystamy.
Oto, ile szaf możemy mieć, ile serwerów i w przybliżeniu, ile to wszystko może zużyć, biorąc pod uwagę 20 kW na szafę. Nieco wcześniej wspomniałem, że naszym celem jest klaster o wielkości około 100 tysięcy serwerów.
Widać, że w całym tym projekcie interesujące są dwie i pół opcji. Dostępna jest opcja z dwiema warstwami grzbietów i 64-portowymi przełącznikami, która jest trochę za krótka. Istnieją doskonale dopasowane opcje dla 128-portowych (z radix 128) przełączników typu „spine” z dwoma poziomami lub przełączników z radix 32 z trzema poziomami. We wszystkich przypadkach, gdy jest więcej podstaw i więcej warstw, można utworzyć bardzo dużą sieć, ale jeśli spojrzeć na oczekiwane zużycie, zazwyczaj są to gigawaty. Można położyć kabel, ale w jednym miejscu nie uda nam się uzyskać takiej ilości prądu. Jeśli spojrzeć na statystyki i publiczne dane dotyczące centrów danych, można znaleźć bardzo niewiele centrów danych o szacowanej mocy większej niż 150 MW. Większe to zazwyczaj kampusy centrów danych, czyli kilka dużych centrów danych zlokalizowanych dość blisko siebie.
Jest jeszcze jeden ważny parametr. Jeśli spojrzysz na lewą kolumnę, wyświetli się tam użyteczna przepustowość. Łatwo zauważyć, że w sieci Clos znaczna część portów wykorzystywana jest do łączenia ze sobą przełączników. Pasmo użyteczne, pas użyteczny, to coś, co można oddać na zewnątrz, w stronę serwerów. Mówię oczywiście o portach warunkowych, a konkretnie o zespole. Z reguły łącza w sieci są szybsze niż łącza do serwerów, ale na jednostkę przepustowości, o ile możemy wysłać ją do naszego sprzętu serwerowego, w samej sieci nadal pozostaje pewna przepustowość. Im więcej poziomów wykonamy, tym większy będzie konkretny koszt dostarczenia tego paska na zewnątrz.
Co więcej, nawet to dodatkowe pasmo nie jest dokładnie takie samo. Choć rozpiętości są krótkie, możemy zastosować coś w rodzaju DAC (bezpośrednio podłączane kable miedziane, czyli kable twinax) lub optykę wielomodową, która kosztuje nawet mniej więcej rozsądne pieniądze. Gdy tylko przejdziemy na dłuższe rozpiętości - z reguły są to optyki jednomodowe i koszt tej dodatkowej przepustowości zauważalnie wzrasta.
I znowu wracając do poprzedniego slajdu, jeśli stworzymy sieć Clos bez nadsubskrypcji, to łatwo spojrzeć na schemat, zobaczyć, jak zbudowana jest sieć - dodając każdy poziom przełączników kręgosłupa, powtarzamy cały pasek, który był na spód. Poziom Plus - plus to samo pasmo, ta sama liczba portów na przełącznikach, co na poprzednim poziomie i ta sama liczba transceiverów. Dlatego wysoce pożądane jest minimalizowanie liczby poziomów przełączeń grzbietu.
Na podstawie tego obrazu jasno widać, że naprawdę chcemy opierać się na czymś w rodzaju przełączników o podstawie 128.
Tutaj w zasadzie wszystko jest tak samo, jak przed chwilą powiedziałem, to slajd do rozważenia później.
Jakie opcje możemy wybrać jako takie przełączniki? To dla nas bardzo przyjemna wiadomość, że teraz takie sieci można wreszcie budować na przełącznikach jednoukładowych. I to jest bardzo fajne, mają wiele fajnych funkcji. Na przykład prawie nie mają struktury wewnętrznej. Oznacza to, że łatwiej się łamią. Łamią się na różne sposoby, ale na szczęście łamią się całkowicie. W urządzeniach modułowych występuje duża ilość usterek (bardzo nieprzyjemnych), gdy z punktu widzenia sąsiadów i płaszczyzny sterującej wydaje się, że działa, ale np. część tkaniny została utracona i nie działa przy pełnej wydajności. A ruch do niego jest zbilansowany w oparciu o to, że jest w pełni funkcjonalny i możemy zostać przeciążeni.
Lub na przykład pojawiają się problemy z płytą montażową, ponieważ wewnątrz urządzenia modułowego znajdują się również szybkie SerDes - w środku jest to naprawdę skomplikowane. Albo znaki pomiędzy elementami spedycyjnymi są zsynchronizowane, albo niezsynchronizowane. Ogólnie rzecz biorąc, każde produktywne urządzenie modułowe składające się z dużej liczby elementów z reguły zawiera w sobie tę samą sieć Clos, ale bardzo trudno jest je zdiagnozować. Często nawet samemu sprzedawcy trudno jest zdiagnozować.
Ma także dużą liczbę scenariuszy awarii, w których urządzenie ulega degradacji, ale nie wypada całkowicie z topologii. Ponieważ nasza sieć jest duża, aktywnie wykorzystywane jest balansowanie pomiędzy identycznymi elementami, sieć jest bardzo regularna, czyli jedna ścieżka, na której wszystko jest w porządku, nie różni się od drugiej, bardziej opłaca się nam po prostu stracić część urządzeń z topologii, niż doprowadzić do sytuacji, w której niektóre z nich wydają się działać, a inne nie.
Kolejną miłą cechą urządzeń jednoukładowych jest to, że ewoluują lepiej i szybciej. Mają też zazwyczaj większą pojemność. Jeśli weźmiemy duże zmontowane konstrukcje, które mamy na okręgu, wówczas pojemność na jednostkę stojaka dla portów o tej samej prędkości jest prawie dwukrotnie większa niż w przypadku urządzeń modułowych. Urządzenia zbudowane wokół jednego chipa są zauważalnie tańsze od modułowych i zużywają mniej energii.
Ale oczywiście nie bez powodu to wszystko ma swoje wady. Po pierwsze, podstawa jest prawie zawsze mniejsza niż w przypadku urządzeń modułowych. Jeśli uda nam się dostać urządzenie zbudowane wokół jednego chipa ze 128 portami, to teraz bez problemu otrzymamy modułowe z kilkoma setkami portów.
Jest to zauważalnie mniejszy rozmiar tabel forwardingu i w zasadzie wszystko, co dotyczy skalowalności płaszczyzny danych. Płytkie bufory. I z reguły raczej ograniczona funkcjonalność. Okazuje się jednak, że jeśli znasz te ograniczenia i zadbasz o ich obejście lub po prostu weźmiesz je pod uwagę, to nie jest to takie straszne. To, że podstawa jest mniejsza, nie stanowi już problemu na urządzeniach z podstawą 128, które wreszcie pojawiły się niedawno; możemy wbudować dwie warstwy kolców. Ale nadal nie da się zbudować czegoś mniejszego niż dwa, co byłoby dla nas interesujące. Przy jednym poziomie uzyskuje się bardzo małe klastry. Nawet nasze poprzednie projekty i wymagania nadal je przewyższały.
Tak naprawdę, jeśli nagle rozwiązanie znajdzie się gdzieś na krawędzi, nadal istnieje sposób na zwiększenie skali. Ponieważ ostatnim (lub pierwszym) najniższym poziomem, do którego podłączane są serwery, są przełączniki ToR lub przełączniki liściowe, nie mamy obowiązku podłączania do nich jednej szafy. Dlatego też, jeśli rozwiązanie okaże się mniej więcej o połowę mniejsze, można pomyśleć o zastosowaniu po prostu przełącznika z dużym promieniem na niższym poziomie i połączeniu np. dwóch lub trzech szaf w jeden przełącznik. Jest to również opcja, ma swoją cenę, ale sprawdza się całkiem nieźle i może być dobrym rozwiązaniem, gdy trzeba osiągnąć około dwukrotnie większy rozmiar.
Podsumowując, budujemy w oparciu o topologię z dwoma poziomami kolców i ośmioma warstwami fabrycznymi.
Co stanie się z fizyką? Bardzo proste obliczenia. Jeśli mamy dwa poziomy kolców, to mamy tylko trzy poziomy przełączników i spodziewamy się, że w sieci będą trzy odcinki kablowe: od serwerów do przełączników liściowych, do kręgosłupa 1, do kręgosłupa 2. Opcje, które możemy użyj są - są to twinax, wielomodowy, jednomodowy. I tutaj musimy rozważyć, jaka listwa jest dostępna, ile będzie kosztować, jakie są wymiary fizyczne, jakie rozpiętości możemy pokryć i w jaki sposób będziemy modernizować.
Jeśli chodzi o cenę, wszystko da się pogodzić. Twinaxy są znacznie tańsze niż aktywna optyka, tańsze niż transceivery wielomodowe, jeśli wziąć pod uwagę lot od końca, nieco tańsze niż 100-gigabitowy port przełącznika. I proszę pamiętać, że kosztuje mniej niż optyka jednomodowa, ponieważ podczas lotów, gdzie wymagany jest tryb jednomodowy, w centrach danych z wielu powodów ma sens stosowanie CWDM, podczas gdy równoległy tryb jednomodowy (PSM) nie jest zbyt wygodny w pracy przy pomocy bardzo dużych opakowań uzyskuje się włókna, a jeśli skupimy się na tych technologiach, otrzymamy w przybliżeniu następującą hierarchię cen.
Jeszcze jedna uwaga: niestety nie jest zbyt możliwe użycie zdemontowanych portów wielomodowych od 100 do 4x25. Ze względu na cechy konstrukcyjne transceiverów SFP28, jest on niewiele tańszy niż 28 Gbit QSFP100. I ten demontaż dla multimode nie działa zbyt dobrze.
Kolejnym ograniczeniem jest to, że ze względu na wielkość klastrów obliczeniowych i liczbę serwerów, nasze centra danych okazują się fizycznie duże. Oznacza to, że przynajmniej jeden lot trzeba będzie wykonać singlemodem. Ponownie, ze względu na fizyczny rozmiar kapsuł, nie będzie możliwe poprowadzenie dwóch przęseł twinax (kable miedziane).
W rezultacie, jeśli zoptymalizujemy pod kątem ceny i uwzględnimy geometrię tego projektu, otrzymamy jeden zakres twinax, jeden zakres wielomodowy i jeden zakres jednomodowy przy użyciu CWDM. Uwzględnia to możliwe ścieżki aktualizacji.
Tak to wygląda ostatnio, dokąd zmierzamy i co jest możliwe. Przynajmniej jest jasne, jak przejść w kierunku 50-gigabitowych SerDes zarówno w trybie wielomodowym, jak i jednomodowym. Co więcej, jeśli spojrzysz na to, co jest w jednomodowych transiwerach teraz i w przyszłości dla 400G, często nawet gdy 50G SerDes docierają od strony elektrycznej, 100 Gbps na linię może już trafiać do optyki. Jest więc całkiem możliwe, że zamiast przejścia na 50, nastąpi przejście na 100 Gigabit SerDes i 100 Gbps na linię, bo według obietnic wielu dostawców ich dostępność spodziewana jest już wkrótce. Wydaje się, że okres, w którym 50G SerDes były najszybsze, nie będzie długi, gdyż pierwsze egzemplarze 100G SerDes zostaną wprowadzone na rynek już niemal w przyszłym roku. A po pewnym czasie prawdopodobnie będą warte rozsądnych pieniędzy.
Jeszcze jeden niuans dotyczący wyboru fizyki. W zasadzie możemy już korzystać z portów 400 lub 200 Gigabit korzystając z SerDes 50G. Okazuje się jednak, że nie ma to większego sensu, bo jak mówiłem wcześniej, chcemy dość dużej podstawy na przełącznikach, oczywiście w granicach rozsądku. Chcemy 128. A jeśli mamy ograniczoną pojemność chipa i zwiększamy prędkość łącza, to podstawa naturalnie maleje, nie ma cudów.
Możemy zwiększyć całkowitą pojemność za pomocą samolotów i nie ma żadnych specjalnych kosztów, możemy dodać liczbę samolotów. A jeśli stracimy podstawę, będziemy musieli wprowadzić dodatkowy poziom, więc w obecnej sytuacji, przy obecnej maksymalnej dostępnej pojemności na chip, okazuje się, że bardziej efektywne jest wykorzystanie portów 100-gigabitowych, ponieważ pozwalają one aby uzyskać większą podstawę.
Następne pytanie dotyczy tego, jak zorganizowana jest fizyka, ale z punktu widzenia infrastruktury kablowej. Okazuje się, że jest to zorganizowane w dość zabawny sposób. Okablowanie pomiędzy przełącznikami listwowymi a kolcami pierwszego poziomu - ogniw tam nie jest zbyt wiele, wszystko jest zbudowane stosunkowo prosto. Ale jeśli weźmiemy jedną płaszczyznę, w środku będziemy musieli połączyć wszystkie grzbiety pierwszego poziomu ze wszystkimi grzbietami drugiego poziomu.
Poza tym z reguły pojawiają się życzenia dotyczące tego, jak powinno wyglądać wnętrze centrum danych. Na przykład naprawdę chcieliśmy połączyć kable w wiązkę i przeciągnąć je tak, aby jeden panel krosowy o dużej gęstości mieścił się w całości w jednym panelu krosowym, tak aby nie było zoo pod względem długości. Udało nam się rozwiązać ten problem. Jeśli początkowo spojrzysz na topologię logiczną, zobaczysz, że płaszczyzny są niezależne, każdą płaszczyznę można zbudować samodzielnie. Ale kiedy dodamy takie wiązanie i chcemy przeciągnąć cały panel krosowy do panelu krosowego, musimy zmieszać różne płaszczyzny w jednym pakiecie i wprowadzić strukturę pośrednią w postaci optycznych połączeń krzyżowych, aby przepakować je od sposobu, w jaki zostały zmontowane w jednym segmencie, w jaki sposób będą zbierane w innym segmencie. Dzięki temu otrzymujemy fajną cechę: całe skomplikowane przełączanie nie wychodzi poza szafy. Kiedy trzeba coś bardzo mocno splatać, „rozłożyć płaszczyzny”, jak to się czasem nazywa w sieciach Clos, to wszystko jest skupione w jednym racku. Nie mamy wysoce zdemontowanego, aż do pojedynczych ogniw, przełączania pomiędzy regałami.
Tak to wygląda z punktu widzenia logicznej organizacji infrastruktury kablowej. Na zdjęciu po lewej wielobarwne bloki przedstawiają bloki przełączników grzbietowych pierwszego poziomu, po osiem sztuk każdy i wychodzące z nich cztery wiązki kabli, które biegną i przecinają się z wiązkami wychodzącymi z bloków przełączników grzbietowych-2 .
Małe kwadraty oznaczają skrzyżowania. W lewym górnym rogu znajduje się opis każdego takiego skrzyżowania. W rzeczywistości jest to moduł połączeń krzyżowych o wymiarach 512 na 512 portów, który upakuje kable w taki sposób, że wchodzą one w całości do jednej szafy, w której znajduje się tylko jedna płaszczyzna kręgosłupa 2. Po prawej stronie skan tego obrazu jest nieco bardziej szczegółowy w odniesieniu do kilku Podów na poziomie kręgosłupa-1 oraz tego, jak jest on spakowany w połączeniu krzyżowym, jak dochodzi do poziomu kręgosłupa-2.
Tak to wygląda. Jeszcze nie w pełni zmontowany stojak spine-2 (po lewej) i stojak typu cross-connect. Niestety nie ma tam zbyt wiele do zobaczenia. Cała ta struktura jest obecnie wdrażana w jednym z naszych dużych centrów danych, które jest rozbudowywane. To jest praca w toku, będzie wyglądać ładniej, będzie lepiej wypełnione.
Ważne pytanie: wybraliśmy topologię logiczną i zbudowaliśmy fizykę. Co stanie się z płaszczyzną sterującą? Jest to dość dobrze znane z doświadczenia operacyjnego, istnieje wiele raportów, że protokoły stanu łącza są dobre, praca z nimi to przyjemność, ale niestety nie skalują się dobrze na gęsto połączonej topologii. I jest jeden główny czynnik, który temu zapobiega - tak działa zalewanie w protokołach stanu łącza. Jeśli po prostu weźmiesz algorytm zalewania i przyjrzysz się strukturze naszej sieci, zobaczysz, że na każdym kroku będzie bardzo duży fanout, co po prostu zaleje płaszczyznę kontrolną aktualizacjami. W szczególności takie topologie bardzo słabo łączą się z tradycyjnym algorytmem zalewania w protokołach stanu łącza.
Wybór polega na użyciu protokołu BGP. Sposób jego prawidłowego przygotowania opisano w dokumencie RFC 7938 dotyczącym stosowania protokołu BGP w dużych centrach danych. Podstawowe założenia są proste: minimalna liczba prefiksów na host i ogólnie minimalna liczba prefiksów w sieci, jeśli to możliwe, użyj agregacji i pomiń wyszukiwanie ścieżek. Chcemy bardzo ostrożnej, bardzo kontrolowanej dystrybucji aktualizacji, tak zwanej wolnej od dolin. Chcemy, aby aktualizacje były wdrażane dokładnie raz, gdy przechodzą przez sieć. Jeśli mają swój początek na dole, idą w górę, rozwijając się nie więcej niż raz. Nie powinno być zygzaków. Zygzaki są bardzo złe.
Aby to zrobić, używamy projektu, który jest wystarczająco prosty, aby korzystać z podstawowych mechanizmów BGP. Oznacza to, że korzystamy z eBGP działającego na łączu lokalnym, a systemy autonomiczne przypisane są następująco: system autonomiczny na ToR, system autonomiczny na całym bloku kręgosłupa – 1 przełączniki jednego Poda, oraz ogólny system autonomiczny na całym Topie z Tkaniny. Nietrudno zauważyć, że nawet normalne zachowanie protokołu BGP zapewnia nam dystrybucję potrzebnych aktualizacji.
Naturalnie adresowanie i agregacja adresów muszą być zaprojektowane tak, aby były zgodne ze sposobem budowy routingu, aby zapewniały stabilność płaszczyzny sterowania. Adresowanie L3 w transporcie jest powiązane z topologią, ponieważ bez tego nie da się osiągnąć agregacji, bez tego poszczególne adresy wkradną się do systemu routingu. I jeszcze jedno, agregacja niestety nie bardzo dobrze łączy się z wielościeżkowością, bo jak mamy wielościeżkowe i mamy agregację to wszystko jest w porządku, gdy cała sieć jest zdrowa, nie ma w niej żadnych awarii. Niestety, gdy tylko w sieci pojawią się awarie i utracona zostanie symetria topologii, możemy dojść do punktu, z którego ogłoszono jednostkę, z którego nie możemy już dalej iść tam, gdzie trzeba. Dlatego najlepiej agregować tam, gdzie nie ma już dalszej wielodrożności, w naszym przypadku są to przełączniki ToR.
Faktycznie można agregować, ale ostrożnie. Jeśli uda nam się przeprowadzić kontrolowaną dezagregację w przypadku awarii sieci. Ale to dość trudne zadanie, zastanawialiśmy się nawet, czy da się to zrobić, czy można dodać dodatkową automatyzację i maszyny o skończonych stanach, które poprawnie kopną BGP, aby uzyskać pożądane zachowanie. Niestety przetwarzanie spraw narożnych jest bardzo nieoczywiste i skomplikowane, a tego zadania nie da się dobrze rozwiązać poprzez dołączenie zewnętrznych załączników do BGP.
Bardzo ciekawe prace w tym zakresie wykonano w ramach protokołu RIFT, o czym będzie mowa w kolejnym raporcie.
Kolejną ważną rzeczą jest skalowanie płaszczyzn danych w gęstych topologiach, w których mamy dużą liczbę alternatywnych ścieżek. W tym przypadku wykorzystywanych jest kilka dodatkowych struktur danych: Grupy ECMP, które z kolei opisują grupy Next Hop.
W normalnie działającej sieci, bez awarii, kiedy idziemy w górę topologii Clos, wystarczy skorzystać tylko z jednej grupy, ponieważ domyślnie jest opisane wszystko, co nie jest lokalne, możemy wejść w górę. Kiedy idziemy z góry na dół na południe, wówczas wszystkie ścieżki nie są ECMP, są to ścieżki jednościeżkowe. Wszystko w porządku. Problem w tym, że osobliwością klasycznej topologii Clos jest to, że jeśli spojrzymy na górę tkaniny, na dowolny element, istnieje tylko jedna ścieżka do dowolnego elementu poniżej. Jeśli na tej ścieżce wystąpią awarie, wówczas ten konkretny element na górze fabryki stanie się nieważny właśnie dla tych przedrostków, które leżą za uszkodzoną ścieżką. Ale w pozostałej części jest to ważne i musimy przeanalizować grupy ECMP i wprowadzić nowy stan.
Jak wygląda skalowalność płaszczyzny danych na nowoczesnych urządzeniach? Jeśli zrobimy LPM (najdłuższe dopasowanie prefiksu), wszystko jest w porządku, ponad 100 tys. prefiksów. Jeśli mówimy o grupach Next Hop, to wszystko jest gorsze, 2-4 tys. Jeśli mówimy o tabeli zawierającej opis kolejnych przeskoków (lub przylegań), to jest to gdzieś od 16 tys. do 64 tys. I to może stać się problemem. I tu dochodzimy do ciekawej dygresji: co się stało z MPLS w centrach danych? W zasadzie chcieliśmy to zrobić.
Wydarzyły się dwie rzeczy. Przeprowadziliśmy mikrosegmentację na hostach; nie musieliśmy już tego robić w sieci. Nie było zbyt dobrze przy wsparciu różnych dostawców, a tym bardziej przy otwartych implementacjach na białych skrzynkach z MPLS. A MPLS, przynajmniej jego tradycyjne implementacje, niestety bardzo słabo łączy się z ECMP. I własnie dlatego.
Tak wygląda struktura przekazywania ECMP dla IP. Duża liczba prefiksów może wykorzystywać tę samą grupę i ten sam blok Next Hops (lub przylegania, co może być różnie nazywane w różnych dokumentacjach dla różnych urządzeń). Chodzi o to, że jest to opisane jako port wychodzący i na co należy przepisać adres MAC, aby dostać się do prawidłowego Next Hop. W przypadku IP wszystko wygląda prosto, można zastosować bardzo dużą liczbę prefiksów dla tej samej grupy, tego samego bloku Next Hops.
Klasyczna architektura MPLS zakłada, że w zależności od interfejsu wychodzącego etykietę można przepisać na różne wartości. Dlatego musimy zachować grupę i blok Next Hops dla każdej etykiety wejściowej. A to niestety nie ma skali.
Łatwo zauważyć, że w naszym projekcie potrzebowaliśmy około 4000 przełączników ToR, maksymalna szerokość wynosiła 64 ścieżki ECMP, jeśli przejdziemy od kręgosłupa-1 do kręgosłupa-2. Ledwo wchodzimy w jedną tabelę grup ECMP, jeśli zniknie tylko jeden prefiks z ToR, a w ogóle nie trafiamy do tabeli Next Hops.
Nie wszystko jest beznadziejne, ponieważ architektury takie jak Segment Routing obejmują globalne marki. Formalnie byłoby możliwe ponowne zwinięcie wszystkich bloków Next Hops. Aby to zrobić, potrzebujesz operacji typu wieloznacznego: weź etykietę i przepisz ją na tę samą, bez określonej wartości. Ale niestety nie jest to zbyt obecne w dostępnych implementacjach.
Na koniec musimy wprowadzić ruch zewnętrzny do centrum danych. Jak to zrobić? Wcześniej ruch do sieci Clos był wprowadzany od góry. Oznacza to, że istniały routery brzegowe, które łączyły się ze wszystkimi urządzeniami na wierzchu sieci szkieletowej. To rozwiązanie sprawdza się całkiem dobrze w przypadku małych i średnich rozmiarów. Niestety, aby w ten sposób skierować ruch symetrycznie do całej sieci, musimy dotrzeć jednocześnie do wszystkich elementów Topu tkaniny, a gdy jest ich więcej niż setka, okazuje się, że potrzebujemy również dużego radix na routerach brzegowych. Ogólnie rzecz biorąc, kosztuje to pieniądze, ponieważ routery brzegowe są bardziej funkcjonalne, porty na nich będą droższe, a projekt nie jest zbyt piękny.
Inną opcją jest uruchomienie takiego ruchu od dołu. Łatwo sprawdzić, że topologia Clos jest zbudowana w taki sposób, że ruch przychodzący od dołu, czyli od strony ToR, jest równomiernie rozkładany pomiędzy poziomami na całym Top of Fabric w dwóch iteracjach, obciążając całą sieć. Dlatego wprowadzamy specjalny typ Poda, Edge Pod, który zapewnia łączność zewnętrzną.
Jest jeszcze jedna opcja. Tak robi na przykład Facebook. Nazywają to Fabric Aggregator lub HGRID. Wprowadzany jest dodatkowy poziom kręgosłupa w celu połączenia wielu centrów danych. Taka konstrukcja jest możliwa pod warunkiem, że nie mamy dodatkowych funkcji ani zmian w enkapsulacji na interfejsach. Jeśli są to dodatkowe punkty kontaktowe, jest to trudne. Zwykle jest więcej funkcji i swego rodzaju membrana oddzielająca różne części centrum danych. Nie ma sensu zwiększać takiej membrany, ale jeśli z jakiegoś powodu jest ona naprawdę potrzebna, warto rozważyć możliwość jej usunięcia, maksymalnego poszerzenia i przekazania gospodarzom. Robi to na przykład wielu operatorów chmur. Mają nakładki, zaczynają od gospodarzy.
Jakie widzimy możliwości rozwoju? Przede wszystkim usprawnienie obsługi rurociągu CI/CD. Chcemy latać tak, jak testujemy i testujemy, jak latamy. Nie bardzo to wychodzi, bo infrastruktura jest duża i nie da się jej powielić do testów. Musisz zrozumieć, jak wprowadzić elementy testowe do infrastruktury produkcyjnej, nie porzucając ich.
Lepsze oprzyrządowanie i lepszy monitoring prawie nigdy nie są zbędne. Całe pytanie polega na równowadze wysiłku i zysku. Jeśli możesz to dodać przy rozsądnym wysiłku, bardzo dobrze.
Otwarte systemy operacyjne dla urządzeń sieciowych. Lepsze protokoły i lepsze systemy routingu, takie jak RIFT. Konieczne są także badania nad wykorzystaniem lepszych systemów kontroli zatorów komunikacyjnych i być może wprowadzeniem, przynajmniej w niektórych punktach, wsparcia RDMA w ramach klastra.
Patrząc dalej w przyszłość, potrzebujemy zaawansowanych topologii i ewentualnie sieci zużywających mniej narzutów. Z nowości pojawiły się ostatnio publikacje dotyczące technologii szkieletowej dla HPC Cray Slingshot, która opiera się na standardowym standardzie Ethernet, ale z możliwością zastosowania znacznie krótszych złączy. W rezultacie koszty ogólne są zmniejszone.
Wszystko powinno być tak proste, jak to możliwe, ale nie prostsze. Złożoność jest wrogiem skalowalności. Prostota i regularność konstrukcji to nasi przyjaciele. Jeśli możesz gdzieś skalować, zrób to. Ogólnie rzecz biorąc, wspaniale jest teraz zajmować się technologiami sieciowymi. Dzieje się wiele ciekawych rzeczy. Dziękuję.
Źródło: www.habr.com