Opracowaliśmy projekt sieci centrów danych, który umożliwia uruchamianie klastrów obliczeniowych liczących ponad 100 tysięcy serwerów, z maksymalną przepustowością bisekcyjną (bisection bandwidth) przekraczającą jeden petabajt na sekundę.
Z raportu Dmitrija Afanasjewa dowiesz się o głównych zasadach nowego projektu, skalowaniu topologii, problemach, które mogą się pojawić, opcjach ich rozwiązania oraz szczególnych aspektach routingu i skalowania funkcji forwarding plane nowoczesnych urządzeń sieciowych w „gęstych” (densely connected) topologiach z dużą liczbą tras ECMP. Ponadto Dima krótko opowiedział o organizacji zewnętrznej łączności, warstwie fizycznej, systemie kablowym oraz sposobach dalszego zwiększenia pojemności.
— Dzień dobry wszystkim! Nazywam się Dmitrij Afanasjew, jestem architektem sieci w Yandexie i głównie zajmuję się projektowaniem sieci centrów danych.
Moja prezentacja będzie dotyczyła zaktualizowanej sieci centrów danych Yandex. W dużej mierze to ewolucja wcześniejszego projektu, ale jednocześnie zawiera pewne nowe elementy. To prezentacja przeglądowa, ponieważ musieliśmy zmieścić dużo informacji w krótkim czasie. Rozpoczniemy od wyboru logicznej topologii. Następnie będzie omówienie control plane i problemów ze skalowalnością data plane, decyzja co do tego, co będzie działo się na poziomie fizycznym, a także przyjrzymy się niektórym szczególnym cechom urządzeń. Dotkniemy również kwestii MPLS w centrum danych, o którym rozmawialiśmy jakiś czas temu.
Zatem, czym jest Yandex z perspektywy obciążeń i usług? Yandex to typowy hyperscaler. Jeśli spojrzeć na użytkowników, zajmujemy się przede wszystkim przetwarzaniem zapytań użytkowników. Oferujemy również różne usługi streamingowe i dostarczanie danych, ponieważ mamy też usługi storage. W obszarze backendu pojawiają się obciążenia i usługi infrastrukturalne, takie jak rozproszone magazyny obiektowe, replikacja danych oraz oczywiście persistent queues. Jednym z kluczowych typów obciążeń są systemy MapReduce oraz podobne, przetwarzanie strumieniowe, uczenie maszynowe itp.
Jak wygląda infrastruktura, na której to wszystko się odbywa? Jesteśmy dość typowym hiperskalarem, mimo że być może jesteśmy nieco bliżej strony spektrum, na której znajdują się mniejsi hiperskalery. Mamy jednak wszystkie atrybuty. Wykorzystujemy sprzęt komercyjny i horyzontalne skalowanie wszędzie, gdzie to możliwe. Mamy pełne wykorzystanie pooling zasobów: nie pracujemy z pojedynczymi maszynami czy staldami, ale łączymy je w dużą pulę wymiennych zasobów z dodatkowymi usługami zajmującymi się planowaniem i alokacją, i pracujemy z tą pulą.
A zatem pojawia się kolejny poziom — systemów operacyjnych na poziomie klastra obliczeniowego. Jest to niezwykle ważne, ponieważ w pełni kontrolujemy stos technologii, który używamy. Kontrolujemy punkty końcowe (hosty), sieć i stos programowy.
Mamy kilka dużych centrów danych w Rosji i za granicą. Łączy je backbone korzystający z technologii MPLS. Nasza wewnętrzna infrastruktura jest praktycznie w pełni oparta na IPv6, ale ponieważ musimy obsługiwać ruch zewnętrzny, który nadal napływa głównie przez IPv4, musimy jakoś dostarczać żądania przychodzące przez IPv4 do frontendów,serwerówi również trochę surfować w zewnętrznym internecie IPv4 — na przykład do indeksowania.
Ostatnie kilka iteracji projektowania sieci centrów danych wykorzystuje wielopoziomowe topologie Clos i stosuje tylko L3. Odeszliśmy od L2 jakiś czas temu i odetchnęliśmy z ulgą. W końcu nasza infrastruktura obejmuje setki tysięcy instancji obliczeniowych (serwerów). Maksymalny rozmiar klastra wynosił jakiś czas temu około 10 tys. serwerów. Jest to w dużej mierze uzależnione od tego, jak mogą działać te właśnie systemy operacyjne na poziomie klastra, planistyczne, alokacja zasobów itp. Ponieważ nastąpił postęp po stronie oprogramowania infrastrukturalnego, obecnie docelowym wielkością jest rzędu 100 tys. serwerów w jednym klastrze obliczeniowym i mamy zadanie — umieć budować sieciowe fabryki, które pozwalają efektywnie realizować pooling zasobów w takim klastrze.
Czego oczekujemy od sieci centrów danych? Przede wszystkim – dużo taniej i stosunkowo równomiernie rozłożonej przepustowości. Ponieważ sieć to ta podstawa, dzięki której możemy realizować pooling zasobów. Nowy docelowy rozmiar to około 100 tysięcy serwerów w jednym klastrze.
Oczywiście chcemy także skalowalnego i stabilnego control plane, ponieważ przy tak dużej infrastrukturze pojawia się sporo bólu głowy nawet z powodu zwykłych zdarzeń, a nie chcemy, aby dodatkowe problemy generował nam jeszcze control plane. Chcemy przy tym zminimalizować stan w nim. Im mniej stanu, tym lepiej i stabilniej wszystko działa, łatwiej to diagnozować.
Oczywiście potrzebujemy automatyzacji, ponieważ zarządzanie taką infrastrukturą ręcznie jest niemożliwe i było to niemożliwe już od pewnego czasu. Potrzebujemy wsparcia operacyjnego oraz wsparcia CI/CD, na ile to możliwe.
Przy tak dużych centrach danych i klastrach nagle stała się pilna potrzeba wsparcia inkrementalnego wdrażania i rozbudowy bez przerwy w świadczeniu usług. Jeśli w klastrach o wielkości tysiąca maszyn, bliskich dziesięciu tysiącom maszyn, można to było wdrażać jako jedną operację – to znaczy, planujemy rozszerzenie infrastruktury, a kilka tysięcy maszyn dodaje się jako jedna operacja, to klaster o rozmiarze do stu tysięcy maszyn nie powstaje od razu, lecz buduje się przez pewien czas. I jest pożądane, aby przez cały ten czas, to co już zostało wdrożone, czyli rozbudowana infrastruktura, była dostępna.
I jedno wymaganie, które mieliśmy i które odpadło: to wsparcie multitenancy, czyli wirtualizacji lub segmentacji sieci. Teraz nie musimy tego robić na poziomie sieci, ponieważ segmentacja przeniosła się na hosty, co bardzo ułatwiło nam skalowanie. Dzięki IPv6 i dużej przestrzeni adresowej nie musieliśmy w wewnętrznej infrastrukturze używać duplikujących się adresów, cała adresacja była i tak unikalna. A dzięki temu, że filtrację i segmentację sieci przenieśliśmy na hosty, nie musimy tworzyć jakichkolwiek wirtualnych bytów sieciowych w sieciach centrów danych.
Bardzo ważnym aspektem jest to, czego nie potrzebujemy. Jeśli niektóre funkcje można usunąć z sieci, znacznie ułatwia to życie i, co do zasady, poszerza wybór dostępnego sprzętu i oprogramowania, a także znacznie upraszcza diagnostykę.
Cóż zatem nie jest nam potrzebne, od czego mogliśmy się uwolnić, nie zawsze z radością w momencie, gdy to się działo, ale z wielką ulgą, gdy proces się kończył?
Przede wszystkim rezygnacja z L2. Nie potrzebujemy ani prawdziwego, ani emulowanego L2. Nie jest ono w dużej mierze wykorzystywane dzięki temu, że kontrolujemy stos aplikacji. Nasze aplikacje skalują się poziomo, działają z adresowaniem L3, nie martwią się, że jakiś pojedynczy instancja przestała działać, po prostu wprowadzają nową, nie musi być uruchamiana pod starym adresem, ponieważ istnieje oddzielny poziom odkrywania usług oraz monitorowania maszyn znajdujących się w klastrze. Nie przenosimy tego zadania na sieć. Zadaniem sieci jest dostarczanie pakietów z punktu A do punktu B.
Nie mamy również sytuacji, w których adresy przemieszczają się w sieci i muszą być śledzone. W wielu projektach jest to zazwyczaj potrzebne do zapewnienia mobilności VM. Nie korzystamy z mobilności maszyn wirtualnych wewnętrznej infrastruktury dużego Yandexa i uważamy, że nawet jeśli to się już odbywa, nie powinno to mieć wsparcia ze strony sieci. Jeśli naprawdę jest to konieczne, powinno się todziać na poziomie hostów, a adresy, które mogą migrować, powinny być umieszczane w nakładkach, aby nie ingerować w dużą ilość dynamicznych zmian w systemie routingu samej sieci transportowej.
Jeszcze jedną technologią, której nie używamy, jest multicast. Osobom zainteresowanym mogę szczegółowo wyjaśnić, dlaczego. To znacznie ułatwia życie, ponieważ jeśli ktoś miał z tym do czynienia i widział, jak wygląda dokładnie kontrola planu multicastu — we wszystkich instalacjach, poza najprostszymi, to duży ból głowy. Co więcej, trudno znaleźć dobrze działającą otwartą implementację, na przykład.
I wreszcie projektujemy nasze sieci tak, żeby nie zachodziło w nich zbyt wiele zmian. Możemy liczyć na to, że przepływ zewnętrznych zdarzeń w systemie routingu jest niewielki.
Jakie problemy mogą się pojawić i jakie ograniczenia należy uwzględnić przy projektowaniu sieci centrum danych? Oczywiście koszty. Skalowalność, do jakiego poziomu chcemy się rozwijać. Konieczność rozszerzenia bez wstrzymywania usługi. Przepustowość, dostępność. Widoczność tego, co dzieje się w sieci, dla systemów monitorowania, dla zespołów operacyjnych. Wsparcie automatyzacji — znowu, w takim zakresie, w jakim to możliwe, ponieważ różne zadania mogą być realizowane na różnych poziomach, w tym wprowadzenie dodatkowych warstw. No i nie-[zależność]-od dostawców. Chociaż w różnych okresach historycznych, w zależności od tego, na jaki aspekt patrzeć, ta niezależność była łatwiejsza lub trudniejsza do osiągnięcia. Jeśli weźmiemy pod uwagę aspekty chipów urządzeń sieciowych, to do tej pory mówienie o niezależności od dostawców w przypadku chęci uzyskania chipów o dużej przepustowości można było traktować bardzo warunkowo.
Na jakiej topologii logicznej zbudujemy naszą sieć? Będzie to wielopoziomowy Clos. W rzeczywistości nie ma żadnych realnych alternatyw w tej chwili. A topologia Clos jest wystarczająco dobra, nawet w porównaniu z różnymi zaawansowanymi topologiami, które obecnie znajdują się głównie w sferze zainteresowania akademickiego, jeśli mamy przełączniki o dużym radixie.
Jak mniej więcej wygląda wielopoziomowa sieć Clos i jak nazywane są w niej różne elementy? Przede wszystkim różowa róża wiatru, aby zorientować się, gdzie jest północ, gdzie południe, gdzie wschód, gdzie zachód. Takiego typu sieci zazwyczaj budują ci, którzy mają bardzo duży ruch z zachodu na wschód. Co do pozostałych elementów, u góry przedstawiony jest wirtualny przełącznik zbudowany z mniejszych przełączników. To podstawowa idea rekurencyjnego budowania sieci Clos. Bierzemy elementy z jakimś radixem i łączymy je w taki sposób, aby to, co powstało, można było traktować jako przełącznik o większym radixie. Jeśli potrzebujemy jeszcze większego, procedurę można powtórzyć.
W przypadku na przykład dwupoziomowych Clos, gdy można wyraźnie wydzielić komponenty, które na moim schemacie są pionowe, nazywamy je płaszczyznami. Gdybyśmy budowali Clos z trzema poziomami przełączników spine (wszystkie, które nie są brzegowe ani ToR i które są używane tylko do tranzytu), to płaszczyzny wyglądałyby bardziej skomplikowanie, dwupoziomowe wyglądają właśnie w ten sposób. Blok przełączników ToR lub leaf oraz powiązane z nimi pierwszego poziomu przełączniki spine nazywamy Pod. Przełączniki spine na poziomie spine-1 na górze Pod to top of Pod, szczyt Pod. Przełączniki, które znajdują się na górze całej fabric, to górna warstwa fabric, Top of fabric.
Oczywiście pojawia się pytanie: sieci Clos budowane są już od jakiegoś czasu, sama idea pochodzi w ogóle z czasów klasycznej telefonii, sieci TDM. Może pojawiło się coś lepszego, może można to jakoś ulepszyć? Tak i nie. Teoretycznie tak, w praktyce w najbliższym czasie z pewnością nie. Ponieważ istnieje pewna liczba interesujących topologii, część z nich jest nawet używana w produkcji, na przykład Dragonfly w aplikacjach HPC; są także interesujące topologie, takie jak Xpander, FatClique, Jellyfish. Jeśli spojrzeć na prezentacje na konferencjach takich jak SIGCOMM czy NSDI w ostatnim czasie, można znaleźć dość dużą liczbę prac na temat alternatywnych topologii, które mają lepsze właściwości (te lub inne) niż Clos.
Jednak wszystkie te topologie mają jedną interesującą cechę. Utrudnia to ich wdrażanie w sieciach centrów danych, które próbujemy budować na sprzęcie masowym i które kosztują dość rozsądne pieniądze. Wszystkie te alternatywne topologie niestety w dużej mierze posiadają pasmo dostępne nie po najkrótszych ścieżkach. Dlatego od razu pozbawiamy się możliwości korzystania z tradycyjnego control plane.
Teoretycznie rozwiązanie problemu jest znane. To na przykład modyfikacje link state z wykorzystaniem k-shortest path, ale znowu, nie ma takich protokołów, które byłyby wdrożone w produkcie i powszechnie dostępne na sprzęcie.
Co więcej, ponieważ większość pojemności jest dostępna nie najkrótszymi trasami, musimy zmodyfikować nie tylko kontrolny plane, aby wybierał wszystkie te trasy (a swoją drogą, to znacznie bardziej złożony stan w kontrolnym plane). Musimy również zmodyfikować forwarding plane, a zazwyczaj potrzebne są przynajmniej dwie dodatkowe funkcje. To możliwość podejmowania wszystkich decyzji dotyczących przekazywania pakietów jednocześnie, na przykład na hoście. W rzeczywistości to routing źródłowy, czasami w literaturze dotyczącej sieci interkoneksyjnych nazywane jest to wszystkimi decyzjami forwardingowymi na raz. I dodatkowo adaptacyjne routowanie – to już funkcja, która jest nam potrzebna w elementach sieci, polegająca na tym, że wybieramy następny hop w oparciu o informacje o najmniejszym obciążeniu kolejki. Przykładowo, mogą być inne opcje.
Tak więc kierunek jest interesujący, ale niestety, w tej chwili nie możemy go zastosować.
Ok, zatrzymaliśmy się na logicznej topologii Clos. Jak zamierzamy ją skalować? Przyjrzyjmy się, jak jest zbudowana i co można zrobić.
W sieci Clos są dwa główne parametry, które możemy jakoś modyfikować, aby uzyskać różne rezultaty: radix elementów i liczba poziomów w sieci. Schematycznie pokazałem, jak jedno i drugie wpływa na rozmiar. W idealnym przypadku łączymy jedno i drugie.
Widać, że ostateczna szerokość sieci Clos to iloczyn wszystkich poziomów spine switchy południowego radiksu, to, ile mamy linków w dół, jak się rozgałęzia. W ten sposób skalujemy rozmiar sieci.
Jeśli chodzi o pojemność, szczególnie na przełącznikach ToR, są dwa sposoby skalowania. Możemy albo, zachowując ogólną topologię, używać szybszych linków, albo dodawać więcej płaszczyzn.
Jeśli spojrzymy na rozwiniętą wersję sieci Clos (w prawym dolnym rogu) i wrócimy do tego obrazka z siecią Clos na dole…
… to jest dokładnie ta sama topologia, ale na tym slajdzie jest ona złożona bardziej kompaktowo, a płaszczyzny fabryki nałożone na siebie. To jedno i to samo.
Jak wygląda skalowanie sieci Clos w liczbach? Tutaj mam dane dotyczące maksymalnej szerokości, jaką może uzyskać sieć, jaką maksymalną liczbę szafek, przełączników ToR lub przełączników leaf, jeśli nie znajdują się w szafkach, możemy uzyskać w zależności od tego, jaki mamy radiks przełączników używanych dla poziomów spine i ile poziomów stosujemy.
Tutaj przedstawiono, ile możemy mieć stref, ile serwerów oraz mniej więcej ile to wszystko może pobierać w oparciu o 20 kW na strefę. Trochę wcześniej wspomniałem, że dążymy do rozmiaru klastra rzędu 100 tysięcy serwerów.
Widać, że w całej tej konstrukcji interesują nas dwa i pół wariantu. Jest opcja z dwoma warstwami spine'ów i przełącznikami 64-portowymi, która nieco nie wystarcza. Następnie doskonale wpasowują się opcje dla przełączników spine'ów 128-portowych (z radixem 128) z dwiema warstwami lub przełączniki z radixem 32 z trzema warstwami. I we wszystkich przypadkach, gdzie mamy większy radix i więcej warstw, można stworzyć bardzo dużą sieć, jednak jeśli spojrzysz na oczekiwane zużycie, zazwyczaj chodzi o gigawaty. Kabel można poprowadzić, ale tyle energii w jednym miejscu raczej nie uzyskamy. Jeśli spojrzeć na statystyki, publiczne dane o centrach danych — bardzo mało można znaleźć centrów danych o mocy obliczeniowej większej niż 150 MW. To, co przekracza tę wartość, to zazwyczaj kampusy centrów danych, kilka dużych centrów danych znajdujących się stosunkowo blisko siebie.
Jest jeszcze jeden ważny parametr. Jeśli spojrzysz na lewą kolumnę, tam znajdują się informacje o użytecznej przepustowości. Łatwo zauważyć, że w sieci Clos zauważalna część portów zostaje przeznaczona na łączenie przełączników ze sobą. Użyteczna przepustowość, to, co możemy oddać na zewnątrz, w stronę serwerów. Oczywiście mówię o portach warunkowych i właśnie o pasmie. Zazwyczaj łącza wewnątrz sieci są szybsze niż łącza w stronę serwerów, ale na jednostkę pasma, którą możemy oddać na zewnątrz do naszego sprzętu serwerowego, przypada jeszcze trochę pasma wewnątrz samej sieci. I im więcej warstw wprowadzamy, tym większe są jednostkowe koszty związane z dostarczeniem tego pasma na zewnątrz.
Co więcej, nawet to dodatkowe pasmo nie jest do końca jednorodne. Dopóki odległości są krótkie, możemy używać czegoś w rodzaju DAC (direct attach copper, czyli kable twinax) lub multimode optyki, które kosztują jeszcze w miarę rozsądnie. Gdy przechodzimy do dłuższych odległości — zazwyczaj jest to optyka single mode, a koszt dodatkowego pasma zauważalnie wzrasta.
I ponownie, wracając do poprzedniego slajdu, jeśli budujemy sieć Clos bez ponownej subskrypcji, można łatwo spojrzeć na schemat, zobaczyć, jak budowana jest sieć — dodając każdy poziom przełączników spine, powtarzamy całą tę pasmo, które było poniżej. Plus poziom — plus całe to samo pasmo, jeszcze tyle samo, ile było na poprzednim poziomie, portów na switchach, jeszcze tyle samo transceiverów. Dlatego ilość poziomów przełączników spine jest bardzo pożądana do zminimalizowania.
Z tej grafiki widać, że naprawdę chcielibyśmy bazować na czymś takim jak przełączniki o radixie 128.
Tutaj zasadniczo wszystko to samo, co teraz powiedziałem, ten slajd jest raczej do rozważenia później.
Jakie mamy możliwości wyboru takich przełączników? Dobrą wiadomością dla nas jest to, że teraz takie sieci w końcu można budować na jednouchwytowych przełącznikach. I to jest świetne, mają masę atrakcyjnych cech. Na przykład prawie nie mają wewnętrznej struktury. To znaczy, że łatwiej się psują. Psują się, jak to bywa, ale, na szczęście, psują się w całości. W urządzeniach modułowych jest wiele typów uszkodzeń (bardzo nieprzyjemnych), kiedy z perspektywy sąsiadów i control plane wydaje się, że działa, ale na przykład część fabryki została usunięta i nie działa z pełną pojemnością. A ruch jest na nie rozkładany na podstawie tego, że jest w pełni funkcjonalne, i możemy otrzymać przeciążenie.
Lub, na przykład, pojawiają się problemy z backplane, ponieważ wewnątrz urządzenia modułowego również są szybkie SerDesy — naprawdę jest złożone wewnętrznie. Albo tablice między elementami forwarding synchronizują się lub nie synchronizują. Generalnie, każde wydajne urządzenie modułowe, składające się z dużej liczby elementów, zasadniczo zawiera tę samą sieć Clos, tylko że znacznie trudniej ją zdiagnozować. Często nawet samemu dostawcy trudno jest to zdiagnozować.
Ma to ma wiele scenariuszy awarii, w których urządzenie degradacji, ale nie wypada całkowicie z topologii. Ponieważ nasza sieć jest duża, aktywnie wykorzystuje równoważenie obciążenia między identycznymi elementami, sieć jest bardzo regularna, co oznacza, że jeden ścieżka, na której wszystko działa, nie różni się niczym od innej ścieżki. Opłaca nam się po prostu stracić część urządzeń z topologii, niż znaleźć się w sytuacji, gdzie niektóre z nich wydają się działać, a inne nie.
Następną miłą cechą jednoprocesorowych urządzeń jest to, że rozwijają się lepiej i szybciej. Zazwyczaj mają również lepszą pojemność. Jeśli bierzemy pod uwagę duże konstrukcje, które mamy, w przeliczeniu na jednostki rack, pojemność na portach tej samej prędkości jest prawie dwukrotnie lepsza niż w przypadku urządzeń modułowych. Urządzenia zbudowane wokół jednego chipu są zauważalnie tańsze niż modułowe i konsumują mniej energii.
Oczywiście, nie jest to proste, są również wady. Po pierwsze, praktycznie zawsze mniejszy radix niż w przypadku urządzeń modułowych. Jeśli możemy stworzyć urządzenie zbudowane wokół jednego chipu na 128 portów, to modułowe możemy uzyskać na kilka setek portów, bez większych problemów.
Jest to zauważalnie mniejszy rozmiar tabel forwardingowych i, generalnie, wszystko, co dotyczy skalowalności data plane. Płytsze bufory. Zazwyczaj również dość ograniczona funkcjonalność. Okazuje się jednak, że jeśli znamy te ograniczenia i na czas zadbamy o to, aby je obejść lub po prostu uwzględnić, to nie jest to takie straszne. Mniejszy radix nie stanowi już problemu na nowo pojawiających się urządzeniach z radixem 128, możemy zbudować dwa poziomy spine. A mniej niż dwa nic interesującego w naszym rozmiarze i tak nie można zbudować. Z jednym poziomem tworzą się naprawdę małe klastry. Nawet nasze wcześniejsze projekty i wymagania wciąż je przewyższały.
W rzeczywistości, jeśli rozwiązanie wydaje się gdzieś na granicy, istnieje jeszcze sposób na skalowanie. Ponieważ ostatni (lub pierwszy), najniższy poziom, do którego podłączane są serwery — przełączniki ToR lub przełączniki leaf, nie jesteśmy zobowiązani do podłączania jednej szafy. Dlatego, jeśli rozwiązanie okazałoby się niepełne, można pomyśleć o używaniu przełącznika z większą ilością portów na najniższym poziomie i podłączeniu na przykład dwóch lub trzech szaf do jednego przełącznika. To też jest opcja, ma swoje koszty, ale działa i może okazać się niezłym rozwiązaniem, gdy trzeba zwiększyć rozmiar dwa razy.
Podsumowując, budujemy topologię z dwoma poziomami spine, z ośmioma poziomami fabric.
Co z fizyką? Bardzo proste obliczenia. Jeśli mamy dwa poziomy spine, to mamy w sumie trzy poziomy przełączników, a oczekujemy, że w sieci będą trzy segmenty kablowe: od serwerów do przełączników leaf, do spine 1, do spine 2. Możliwe opcje to twinax, multimode, single mode. Należy tu wziąć pod uwagę, jaka przepustowość jest dostępna, ile to będzie kosztować, jakie są wymiary fizyczne, jakie odległości możemy pokonać oraz jak będziemy się aktualizować.
Pod względem kosztu można to wszystko uporządkować w linię. Twinaxy są znacząco tańsze niż aktywna optyka, tańsze niż transceivery multimode, jeśli weźmiemy pod uwagę odcinki od końca, nieco tańsze niż port przełącznika 100-gigabitowego. I uwaga, kosztują mniej niż optyka single mode, ponieważ na odcinkach, gdzie wymagana jest single mode, w centrach danych z wielu powodów sensowne jest użycie CWDM, a praca z równoległym single mode (PSM) jest mało wygodna, co prowadzi do bardzo dużych wiązek włókna, a jeśli zatrzymamy się na tych technologiach, otrzymujemy mniej więcej taką hierarchię cenową.
Kolejna uwaga: niestety, nie udaje się za bardzo wykorzystać rozłożonych portów 100 na 4x25 multimode. Z powodu specyfiki konstrukcji transceiverów SFP28 nie kosztuje znacznie mniej niż QSFP28 na 100 Gb. A to rozłożenie dla multimode niezbyt działa.
Kolejnym ograniczeniem jest to, że ze względu na rozmiar klastrów obliczeniowych i liczbę serwerów nasze centra danych są fizycznie duże. Oznacza to, że co najmniej jeden przelot będzie musiał być z użyciem światłowodu jednomodowego. Ponownie, z powodu fizycznego rozmiaru pods nie będzie możliwe przejście dwóch przelotów przy zastosowaniu kabli twinax (miedzianych).
W rezultacie, jeśli zoptymalizujemy pod względem kosztów i uwzględnimy geometrię tej konstrukcji, uzyskamy jeden przelot twinaxem, jeden przelot multimodowym i jeden przelot jednomodowym z wykorzystaniem CWDM. To uwzględnia możliwe drogi do upgrade'u.
Tak mniej więcej wygląda to, co działo się niedawno, dokąd zmierzamy i co jest możliwe. Jest zrozumiałe, przynajmniej jak zmierzać w kierunku 50-gigabitowych SerDes zarówno dla multimodu, jak i dla jednomodu. Co więcej, jeśli spojrzeć na obecny stan transceiverów jednomodowych i ich przyszłość dla 400G, to często, nawet gdy przychodzą 50G SerDes z strony elektrycznej, w optyce mogą już być 100 Gbps na tor. Dlatego całkiem możliwe, że zamiast przejścia na 50 może nastąpić przejście na 100-gigabitowe SerDes i 100 Gbps na tor, ponieważ wielu dostawców obiecuje, że ich dostępność jest spodziewana całkiem szybko. Okres, w którym 50G SerDes były najszybsze, wydaje się nie być zbyt długi, ponieważ pierwsze egzemplarze 100G SerDes mają być wprowadzane już w przyszłym roku. I w pewnym momencie po tym, mogą one być dostępne w rozsądnej cenie.
Kolejny niuans dotyczący wyboru fizyki. W zasadzie już teraz możemy stosować porty 400- lub 200-gigabitowe z użyciem 50G SerDes. Jednak okazuje się, że nie ma w tym większego sensu, ponieważ, jak już wcześniej mówiłem, chcemy mieć wystarczająco duży radix na switchach, w rozsądnych granicach, oczywiście. Chcemy 128. A jeśli mamy ograniczoną pojemność chipu i zwiększamy prędkość łącza, to radix naturalnie maleje, nie ma cudów.
Ogólną pojemność możemy zwiększyć dzięki płaszczyznom, a przy tym nie ponosząc szczególnych kosztów, można zwiększyć liczbę płaszczyzn. A jeśli stracimy radix, będziemy zmuszeni wprowadzić dodatkowy poziom, dlatego w obecnych układach, przy maksymalnej dostępnej pojemności na jeden chip, okazuje się, że bardziej efektywne jest stosowanie portów 100-gigabitowych, ponieważ pozwalają one uzyskać większy radix.
Następnym zagadnieniem jest organizacja fizyki, ale już z perspektywy infrastruktury kablowej. Okazuje się, że jest ona zorganizowana dość zabawnie. Kablowanie między przełącznikami leaf a spine pierwszego poziomu — tam nie ma zbyt wielu połączeń, wszystko jest zbudowane stosunkowo prosto. Natomiast jeśli weźmiemy jedną płaszczyznę, to co się dzieje wewnątrz — trzeba połączyć wszystkie spine pierwszego poziomu ze wszystkimi spine drugiego poziomu.
Dodatkowo, zazwyczaj istnieją pewne wymagania dotyczące tego, jak to ma wyglądać wewnątrz centrum danych. Na przykład, bardzo chcieliśmy zgrupować kable w wiązki i prowadzić je w taki sposób, aby jeden gęsty panel krosowy przechodził całkowicie do drugiego panelu, aby nie było zoo w długościach. Udało nam się rozwiązać ten problem. Jeśli pierwotnie spojrzeć na topologię logiczną, widać, że płaszczyzny są niezależne, każda płaszczyzna może być budowana samodzielnie. Ale gdy dodajemy takie bundling i chcemy prowadzić całkowicie panel krosowy do panelu krosowego, musimy wewnątrz jednej wiązki mieszać różne płaszczyzny i wprowadzać pośrednią konstrukcję w formie optycznych cross-connectów, aby przepakować je od tego, jak były zbudowane na jednym segmencie, do tego, jak będą zbudowane na innym segmencie. Dzięki temu mamy przyjemną cechę: całe skomplikowane okablowanie nie wychodzi poza ramy stojaka. Kiedy trzeba coś mocno przepleść, „rozwinąć płaszczyzny”, jak to czasem nazywają w sieciach Clos, wszystko koncentruje się wewnątrz jednego stojaka. Nie mamy mocno rozdzielonych, aż do indywidualnych połączeń, okablowania między stojakami.
Tak to wygląda z perspektywy logicznej organizacji infrastruktury kablowej. Na zdjęciu po lewej stronie kolorowe bloki przedstawiają bloki spine-switchy pierwszego poziomu, po osiem sztuk, a od nich odchodzą cztery wiązki kabli, które idą i krzyżują się z wiązkami biegnącymi od bloków spine-2-switchy.
Małe kwadraty oznaczają punkty przecięcia. W lewym górnym rogu znajduje się rozwinięcie każdego z tych punktów, które w rzeczywistości jest modułem cross-connect z 512 na 512 portów, przepakowującym kable tak, aby mieściły się w jednej szafie, gdzie jest tylko jedna płaszczyzna spine-2. A po prawej stronie jest nieco bardziej szczegółowe rozwinięcie tego obrazu dotyczące kilku Pods na poziomie spine-1 oraz jak to jest pakowane w cross-connect, jak dochodzi do poziomu spine-2.
Oto jak to wygląda. Nie w pełni złożona szafa spine-2 (po lewej) i szafa cross-connect. Niestety, niewiele stamtąd widać. Cała ta konstrukcja rozwija się teraz w jednym z naszych dużych centrów danych, które się rozrasta. To praca w toku, będzie wyglądać lepiej, będzie lepiej wypełniona.
Istotne pytanie: wybraliśmy topologię logiczną, zbudowaliśmy fizykę. Co z control plane? Z doświadczenia eksploatacyjnego wiadomo, że pewna liczba wypowiedzi sugeruje, że protokoły link state są dobre, przyjemne w użyciu, ale niestety nie skalują się dobrze w gęsto upakowanej topologii. Istnieje jeden główny czynnik, który to utrudnia — sposób działania floodingu w protokołach link state. Jeśli po prostu weźmiemy algorytm floodingu, spojrzymy na to, jak jest zorganizowana nasza sieć, widać, że w każdym kroku będzie bardzo duży fanout i po prostu zaleje control plane aktualizacjami. Konkretnie takie topologie z tradycyjnym algorytmem floodingu w protokołach link state źle się mieszają.
Wybór — używać BGP. Jak go właściwie przygotować, opisano w RFC 7938 dotyczącym użycia BGP w dużych centrach danych. Podstawowe pomysły są proste: minimalna liczba prefiksów na hosta i w ogóle minimalna liczba prefiksów w sieci, używanie agregacji, jeśli to możliwe, oraz tłumienie path hunting. Chcemy bardzo ostrożnego, bardzo kontrolowanego rozpowszechniania aktualizacji, to, co nazywa się valley free. Chcemy, aby aktualizacje, przechodząc przez sieć, rozwijały się dokładnie jeden raz. Jeśli pochodzą z dołu, idą w górę, rozwijają się nie więcej niż jeden raz. Nie powinno być zygzaków. Zygzaki są bardzo złe.
Aby to zrobić, stosujemy dość prostą schematykę bazującą na podstawowych mechanizmach BGP. Oznacza to, że używamy eBGP działającego w trybie link local, a systemy autonomiczne są przypisywane w następujący sposób: system autonomiczny na ToR, system autonomiczny dla całej puli switchy spine-1 w jednym Pod oraz wspólny system autonomiczny dla całego Top of Fabric. Nie trudno zauważyć, że nawet normalne zachowanie BGP zapewnia nam pożądane rozpowszechnianie aktualizacji.
Naturalnie, trzeba projektować adresację i agregację adresów tak, aby było to zgodne z budową routingu, co zapewnia stabilność control plane. Adresacja L3 w transporcie jest związana z topologią, ponieważ bez tego nie można osiągnąć agregacji, a indywidualne adresy będą przechodzić przez system routingu. Jeszcze jedną rzeczą jest to, że agregacja, niestety, nie bardzo dobrze współdziała z multi-path, ponieważ gdy mamy multi-path i agregację, wszystko jest w porządku, gdy cała sieć działa, nie ma w niej awarii. Niestety, gdy w sieci występują awarie i symetria topologii zostaje utracona, możemy natknąć się na punkt, z którego ogłoszono agregat, z którego nie można przejść tam, gdzie chcemy. Dlatego najlepiej agregować tam, gdzie nie ma dalej multi-path, w naszym przypadku są to switche ToR.
W rzeczywistości można agregować, ale z ostrożnością. Jeżeli możemy przeprowadzić kontrolowaną dezaggregację w przypadku awarii w sieci. Ale to dość skomplikowane zadanie, nawet próbowaliśmy ocenić, czy to możliwe, czy można dodać dodatkową automatykę, oraz skończone automaty, które będą prawidłowo „kopać” BGP, aby uzyskać pożądane zachowanie. Niestety, obsługa corner cases jest bardzo nieoczywista i skomplikowana, a dołączenie zewnętrznego sprzętu do BGP nie rozwiązuje tego problemu dobrze.
Bardzo interesująca praca w tym zakresie została wykonana w ramach protokołu RIFT, o którym będzie mowa w następnej prezentacji.
Inną ważną kwestią jest to, jak skalują się data plane w gęstych topologiach, gdzie mamy dużą liczbę alternatywnych ścieżek. W tym przypadku wykorzystuje się kilka dodatkowych struktur danych: grupy ECMP, które opisują z kolei grupy Next Hop.
W normalnie działającej sieci, bez zakłóceń, gdy poruszamy się w górę po topologii Clos, wystarczy używać tylko jednej grupy, ponieważ wszystko, co nie jest lokalne, opisane jest przez domyślne ustawienia, można iść w górę. Kiedy schodzimy z góry na południe, to wszystkie ścieżki nie są ECMP, to ścieżki jednokierunkowe. Wszystko dobrze. Problematyczne jest to, że klasyczna topologia Clos charakteryzuje się tym, że jeśli spojrzymy na Top of fabric, każdy element ma jedną ścieżkę do każdego elementu na dole. Jeśli wzdłuż tej ścieżki wystąpią awarie, to dany element na górze fabric staje się nieważny właśnie dla tych prefiksów, które znajdują się za uszkodzoną ścieżką. A dla pozostałych jest ważny, więc musimy rozwiązywać grupy ECMP i wprowadzać nowy stan.
Jak wygląda skalowalność data plane na nowoczesnych urządzeniach? Jeśli robimy LPM (najdłuższe dopasowanie prefiksu), wszystko jest dość dobrze, powyżej 100k prefiksów. Jeśli mówimy o grupach Next Hop, to trochę gorzej, 2-4 tysiące. Jeśli mówimy o tabeli, która zawiera opis Next Hops (lub sąsiedztw), to jest to gdzieś od 16k do 64k. I to może stać się problemem. I tutaj przechodzimy do interesującej dygresji: co się stało z MPLS w centrach danych? W zasadzie chcieliśmy go wdrożyć.
Zdarzyły się dwie rzeczy. Zrealizowaliśmy mikrosegmentację na hostach, więc nie musieliśmy już tego robić w sieci. Nie było to zbyt dobre z wsparciem od różnych dostawców, zwłaszcza z otwartymi realizacjami na white boxes z MPLS. Ponadto MPLS, przynajmniej jego tradycyjne realizacje, niestety bardzo słabo współpracują z ECMP. I dlatego.
Tak wygląda struktura ECMP-forwardingu dla IP. Duża liczba prefiksów może korzystać z tej samej grupy i tego samego bloku Next Hops (lub sąsiedztw, w różnych dokumentacjach może być to nazywane różnie). Chodzi o to, że opisuje to port wyjściowy oraz jak przepisujemy adres MAC, aby dotrzeć do właściwego Next Hop. Dla IP wszystko wydaje się proste, można używać bardzo dużej liczby prefiksów w tej samej grupie, tego samego bloku Next Hops.
Klasyczna architektura MPLS zakłada — w zależności od wyjściowego interfejsu, etykieta może być przepisywana na różne wartości. Dlatego musimy utrzymywać grupę i blok Next Hops dla każdej wejściowej etykiety. I to, niestety, nie skalowalnie.
Nie jest trudno zauważyć, że w naszej konstrukcji potrzebowaliśmy około 4000 przełączników ToR, maksymalna szerokość – 64 ścieżki ECMP, w przypadku przejścia z spine-1 w stronę spine-2. Ciężko nam się zmieścić, na granicy, w jednej tabeli grup ECMP, jeśli tylko jeden prefiks z ToR odchodzi, a w ogóle nie mieścimy się w tabeli Next Hops.
Nie jest wszystko beznadziejne, ponieważ architektury typu Segment Routing zakładają globalne etykiety. Formalnie można by ponownie zwinąć wszystkie te bloki Next Hops. W tym celu potrzebna jest operacja typu wildcard: wziąć etykietę i zapisać ją ponownie na tę samą bez konkretnej wartości. Niestety, w dostępnych realizacjach nie jest to zbyt powszechne.
I w końcu musimy przynieść zewnętrzny ruch do centrum danych. Jak to zrobić? Kiedyś ruch był wprowadzany do sieci Clos od góry. A więc były brzegowe routery, które łączyły się ze wszystkimi urządzeniami na Top of fabric. To rozwiązanie działa całkiem nieźle w małych i średnich rozmiarach. Niestety, aby wprowadzać ruch w ten sposób symetrycznie do całej sieci, trzeba przychodzić jednocześnie do wszystkich elementów Top of fabric, a gdy ich liczba przekracza sto, okazuje się, że potrzebujemy dużego radix także na brzegowych routerach. Ogólnie, wiąże się to z kosztami, ponieważ brzegowe routery są bardziej funkcjonalne, porty na nich będą droższe, a cała konstrukcja nie wygląda atrakcyjnie.
Inna opcja to wprowadzanie takiego ruchu od dołu. Nie jest trudno zobaczyć, że topologia Clos jest skonstruowana tak, że ruch wchodzący od dołu, czyli ze strony ToR, jest równomiernie rozkładany po poziomach na całe Top of fabric w ciągu dwóch iteracji, obciążając całą sieć. Dlatego wprowadzamy specjalny typ Pod, Edge Pod, które zapewniają zewnętrzną łączność.
Jest jeszcze jedna opcja. Na przykład Facebook to robi. Nazywa się to Fabric Aggregator lub HGRID. Wprowadzany jest dodatkowy poziom spine, aby połączyć kilka centrów danych. Taka konstrukcja jest możliwa, jeśli nie ma dodatkowych funkcji na styku lub zmiany enkapsulacji. Jeśli są, to są to dodatkowe punkty styku, co jest skomplikowane. Zazwyczaj pojawia się więcej funkcji i rodzaj błony oddzielającej różne części centrum danych. Nie warto robić dużej błony, ale jeśli jest ona potrzebna, warto rozważyć możliwość przeniesienia jej, uczynienia jak najszerszą i przeniesienia na hosty. Tak robi wiele operatorów chmurowych. Mają overlay, które zaczynają się od hostów.
Jakie widzimy możliwości rozwoju? Przede wszystkim - ulepszenie wsparcia dla CI/CD pipeline. Chcemy działać tak, jak testujemy, i testować tak, jak działamy. Nie do końca nam to wychodzi, ponieważ infrastruktura jest duża, a nie można jej zduplikować do testów. Musimy zrozumieć, jak wprowadzać elementy testowe do działającej infrastruktury, nie destabilizując jej.
Lepsze instrumentowanie, lepszy monitoring nigdy nie są zbędne. Cała kwestia polega na równowadze wysiłków i zysków. Jeśli można rozsądnie dodać – to bardzo dobrze.
Otwarte systemy operacyjne dla urządzeń sieciowych. Najlepsze protokoły i najlepsze systemy routingu, na przykład RIFT. Potrzebne są także badania nad zastosowaniem najlepszych schematów kontroli zatłoczenia i być może wprowadzenie, przynajmniej w niektórych punktach, wsparcia dla RDMA w obrębie klastra.
Patrząc w dłuższą przyszłość, potrzebne są zaawansowane topologie i być może sieci o mniejszym narzucie. Z nowych rzeczy - niedawno były publikacje na temat technologii fabryk dla HPC Cray Slingshot, bazującej na zwykłym Ethernet, ale z opcją użycia znacznie krótszych nagłówków. W rezultacie narzut się zmniejsza.
Wszystko powinno być robione tak prosto, jak to możliwe, ale nie prostsze. Złożoność jest wrogiem skalowalności. Prostota i regularne struktury są naszymi przyjaciółmi. Jeśli można gdzieś skalować – róbcie to. A w ogóle, wygląda to świetnie, teraz warto zajmować się technologiami sieciowymi. Dzieje się wiele interesujących rzeczy. Dziękuję.
Źródło: habr.com
