Как да мащабирате центрове за данни. Доклад на Yandex

Ние разработихме мрежов дизайн на център за данни, който позволява внедряването на изчислителни клъстери, по-големи от 100 хиляди сървъра с пикова честотна лента на бисекция над един петабайт в секунда.

От доклада на Дмитрий Афанасиев ще научите за основните принципи на новия дизайн, топологиите за мащабиране, проблемите, които възникват при това, възможностите за тяхното решаване, характеристиките на маршрутизирането и мащабирането на функциите на равнината на препращане на съвременните мрежови устройства в „плътно свързани“ топологии с голям брой ECMP маршрути. Освен това Дима говори накратко за организацията на външната свързаност, физическия слой, кабелната система и начините за по-нататъшно увеличаване на капацитета.

- Добър ден на всички! Казвам се Дмитрий Афанасиев, мрежов архитект съм в Yandex и предимно проектирам мрежи от центрове за данни.



Моят разказ ще бъде за актуализираната мрежа от центрове за данни Yandex. Това е до голяма степен еволюция на дизайна, който имахме, но в същото време има някои нови елементи. Това е обзорна презентация, защото имаше много информация, която трябваше да бъде опакована в малко време. Ще започнем с избора на логическа топология. След това ще има преглед на контролната равнина и проблемите с мащабируемостта на равнината на данни, избор какво ще се случи на физическо ниво и ще разгледаме някои характеристики на устройствата. Нека да се докоснем малко до това, което се случва в център за данни с MPLS, за което говорихме преди време.

И така, какво е Yandex по отношение на товари и услуги? Yandex е типичен хиперскалер. Ако разгледаме потребителите, ние обработваме предимно потребителски заявки. Също така различни стрийминг услуги и пренос на данни, защото имаме и услуги за съхранение. Ако е по-близо до бекенда, тогава там се появяват инфраструктурни натоварвания и услуги, като съхранение на разпределени обекти, репликация на данни и, разбира се, постоянни опашки. Един от основните видове натоварвания е MapReduce и подобни системи, обработка на потоци, машинно обучение и др.

Как е инфраструктурата, върху която се случва всичко това? Отново, ние сме доста типичен хипермащабер, въпреки че може би сме малко по-близо до по-малко хипермащабната страна на спектъра. Но имаме всички атрибути. Ние използваме стандартен хардуер и хоризонтално мащабиране, когато е възможно. Имаме пълно обединяване на ресурси: ние не работим с отделни машини, отделни стелажи, а ги комбинираме в голям пул от взаимозаменяеми ресурси с някои допълнителни услуги, които се занимават с планиране и разпределение, и работим с целия този пул.

Така че имаме следващото ниво - операционната система на ниво изчислителен клъстер. Много е важно да контролираме напълно технологичния стек, който използваме. Ние контролираме крайните точки (хостовете), мрежата и софтуерния стек.

Имаме няколко големи центрове за данни в Русия и чужбина. Те са обединени от гръбнак, който използва MPLS технология. Нашата вътрешна инфраструктура е почти изцяло изградена на IPv6, но тъй като трябва да обслужваме външен трафик, който все още идва главно през IPv4, трябва по някакъв начин да доставяме заявки, идващи през IPv4 до предните сървъри, и малко повече да отиваме към външен IPv4- Интернет - за например за индексиране.

Последните няколко итерации на мрежови проекти на центрове за данни са използвали многослойни Clos топологии и са само L3. Тръгнахме преди малко от L2 и въздъхнахме с облекчение. И накрая, нашата инфраструктура включва стотици хиляди изчислителни (сървърни) инстанции. Максималният размер на клъстера преди време беше около 10 хиляди сървъра. Това до голяма степен се дължи на начина, по който могат да работят същите тези операционни системи на клъстерно ниво, планировчици, разпределение на ресурси и т. н. Тъй като напредъкът се случи от страна на инфраструктурния софтуер, целевият размер сега е около 100 хиляди сървъра в един изчислителен клъстер и Имаме задача - да можем да изградим мрежови фабрики, които позволяват ефективно обединяване на ресурсите в такъв клъстер.

Какво искаме от мрежа от център за данни? На първо място, има много евтина и сравнително равномерно разпределена честотна лента. Тъй като мрежата е гръбнакът, чрез който можем да обединим ресурси. Новият целеви размер е около 100 хиляди сървъра в един клъстер.

Също така, разбира се, искаме мащабируема и стабилна контролна равнина, защото в такава голяма инфраструктура възникват много главоболия дори от просто случайни събития и не искаме контролната равнина също да ни носи главоболия. В същото време искаме да минимизираме състоянието в него. Колкото по-малко е състоянието, толкова по-добре и по-стабилно работи всичко и толкова по-лесно е да се диагностицира.

Разбира се, имаме нужда от автоматизация, защото е невъзможно да се управлява ръчно такава инфраструктура и от известно време е невъзможно. Нуждаем се от оперативна подкрепа, доколкото е възможно, и поддръжка за CI/CD, доколкото може да бъде предоставена.

С такива размери на центрове за данни и клъстери задачата за поддържане на постепенно внедряване и разширяване без прекъсване на услугата стана доста остра. Ако на клъстери с размер от хиляда машини, може би близо десет хиляди машини, те все още могат да бъдат разгърнати като една операция - тоест, ние планираме разширяване на инфраструктурата и няколко хиляди машини се добавят като една операция, тогава клъстер с размер от сто хиляди машини не възниква веднага по този начин, той се изгражда за определен период от време. И е желателно през цялото това време това, което вече е изпомпано, инфраструктурата, която е разгърната, да е налична.

И едно изискване, което имахме и останахме: поддръжка за мултинаемност, тоест виртуализация или мрежово сегментиране. Сега не е необходимо да правим това на ниво мрежова структура, тъй като шардингът е отишъл при хостовете и това направи мащабирането много лесно за нас. Благодарение на IPv6 и голямото адресно пространство не беше необходимо да използваме дублирани адреси във вътрешната инфраструктура; всички адреси вече бяха уникални. И благодарение на факта, че сме взели филтриране и мрежово сегментиране на хостовете, не е необходимо да създаваме никакви виртуални мрежови обекти в мрежите на центрове за данни.

Много важно нещо е това, което не ни трябва. Ако някои функции могат да бъдат премахнати от мрежата, това значително улеснява живота и като правило разширява избора на налично оборудване и софтуер, което прави диагностиката много проста.

И така, какво е това, от което не се нуждаем, от какво сме успели да се откажем, не винаги с радост в момента, в който се е случило, но с голямо облекчение, когато процесът приключи?

На първо място, изоставяне на L2. Не ни трябва L2, нито истински, нито емулиран. Неизползван до голяма степен поради факта, че ние контролираме стека на приложенията. Нашите приложения са хоризонтално мащабируеми, работят с L3 адресиране, не се притесняват много, че някой отделен екземпляр е изчезнал, те просто пускат нов, не е необходимо да се пуска на стария адрес, защото има отделно ниво на откриване на услуги и наблюдение на машини, разположени в клъстера. Ние не делегираме тази задача на мрежата. Работата на мрежата е да доставя пакети от точка А до точка Б.

Също така нямаме ситуации, при които адресите се движат в мрежата и това трябва да се наблюдава. В много дизайни това обикновено е необходимо за поддържане на VM мобилност. Ние не използваме мобилността на виртуалните машини във вътрешната инфраструктура на големия Yandex и освен това смятаме, че дори и да се направи това, не трябва да се случва с мрежова поддръжка. Ако наистина трябва да направите това, трябва да го направите на ниво хост и да изпратите адреси, които могат да мигрират в наслагвания, за да не докосвате или правите твърде много динамични промени в системата за маршрутизиране на самата подложка (транспортна мрежа) .

Друга технология, която не използваме, е мултикаст. Ако искаш, мога да ти кажа подробно защо. Това прави живота много по-лесен, защото ако някой се е занимавал с това и е гледал как точно изглежда мултикаст контролната равнина, във всички, освен най-простите инсталации, това е голямо главоболие. И нещо повече, трудно е да се намери добре работеща реализация с отворен код, например.

И накрая, ние проектираме нашите мрежи така, че да не се променят твърде много. Можем да разчитаме на факта, че потокът от външни събития в системата за маршрутизиране е малък.

Какви проблеми възникват и какви ограничения трябва да се вземат предвид, когато разработваме мрежа от център за данни? Цена, разбира се. Мащабируемост, нивото, до което искаме да растем. Необходимостта от разширяване без спиране на услугата. Честотна лента, наличност. Видимост на случващото се в мрежата за системи за мониторинг, за оперативни екипи. Поддръжка на автоматизация - отново, доколкото е възможно, тъй като различни задачи могат да бъдат решени на различни нива, включително въвеждането на допълнителни слоеве. Е, не [евентуално] зависим от доставчици. Въпреки че в различни исторически периоди, в зависимост от това кой раздел разглеждате, тази независимост е била по-лесна или по-трудна за постигане. Ако вземем напречно сечение на чиповете на мрежовите устройства, тогава доскоро беше много условно да говорим за независимост от производителите, ако искахме и чипове с висока пропускателна способност.

Каква логическа топология ще използваме, за да изградим нашата мрежа? Това ще бъде Clos на много нива. Всъщност реални алтернативи в момента няма. И топологията на Clos е доста добра, дори в сравнение с различни усъвършенствани топологии, които сега са повече в областта на академичния интерес, ако имаме големи превключватели на радикса.

Как е грубо структурирана многостепенната Clos мрежа и как се наричат ​​различните елементи в нея? Първо, розата на ветровете, за да се ориентирате къде е север, къде юг, къде изток, къде запад. Мрежи от този тип обикновено се изграждат от тези, които имат много голям трафик запад-изток. Що се отнася до останалите елементи, в горната част има виртуален превключвател, сглобен от по-малки превключватели. Това е основната идея на рекурсивното изграждане на мрежи на Clos. Взимаме елементи с някакъв вид основа и ги свързваме, така че това, което получаваме, да може да се разглежда като превключвател с по-голяма основа. Ако имате нужда от повече, процедурата може да се повтори.

В случаите, например, с две нива Clos, когато е възможно ясно да се идентифицират компоненти, които са вертикални в моята диаграма, те обикновено се наричат ​​равнини. Ако трябваше да изградим Clos с три нива на гръбначни превключватели (всички от които не са гранични или ToR превключватели и които се използват само за транзит), тогава самолетите биха изглеждали по-сложни; тези на две нива изглеждат точно така. Наричаме блок от ToR или листови превключватели и гръбначните превключватели от първо ниво, свързани с тях, Pod. Превключвателите на гръбначния стълб на ниво spine-1 в горната част на Pod са горната част на Pod, горната част на Pod. Превключвателите, които са разположени в горната част на цялата фабрика, са най-горният слой на фабриката, Top of fabric.

Разбира се, възниква въпросът: Clos мрежите се изграждат от известно време, самата идея идва като цяло от времето на класическата телефония, TDM мрежите. Може би се е появило нещо по-добро, може би нещо може да се направи по-добре? Да и не. Теоретично да, на практика в близко бъдеще определено не. Тъй като има редица интересни топологии, някои от тях дори се използват в производството, например Dragonfly се използва в HPC приложения; Има и интересни топологии като Xpander, FatClique, Jellyfish. Ако погледнете докладите на конференции като SIGCOMM или NSDI наскоро, можете да намерите доста голям брой работи върху алтернативни топологии, които имат по-добри свойства (едни или други) от Clos.

Но всички тези топологии имат едно интересно свойство. Това възпрепятства внедряването им в мрежи от центрове за данни, които се опитваме да изградим върху стандартен хардуер и които струват доста разумни пари. Във всички тези алтернативни топологии по-голямата част от честотната лента за съжаление не е достъпна по най-кратките пътища. Следователно ние веднага губим възможността да използваме традиционната равнина за управление.

Теоретично решението на проблема е известно. Това са, например, модификации на състоянието на връзката, използвайки k-най-късия път, но, отново, няма такива протоколи, които да бъдат внедрени в производството и широко достъпни на оборудването.

Освен това, тъй като по-голямата част от капацитета не е достъпна по най-кратките пътища, трябва да модифицираме повече от контролната равнина, за да изберем всички тези пътища (и между другото, това е значително повече състояние в контролната равнина). Все още трябва да модифицираме самолета за пренасочване и, като правило, са необходими поне две допълнителни функции. Това е способността да се вземат всички решения относно препращането на пакети еднократно, например на хоста. Всъщност това е маршрутизиране на източника, понякога в литературата за мрежи за взаимно свързване това се нарича решения за пренасочване на всички наведнъж. А адаптивното маршрутизиране е функция, от която се нуждаем върху мрежовите елементи, която се свежда например до факта, че избираме следващия хоп въз основа на информация за най-малкото натоварване на опашката. Като пример са възможни и други варианти.

Така посоката е интересна, но, уви, не можем да я приложим точно сега.

Добре, спряхме се на логическата топология на Clos. Как ще го мащабираме? Нека да видим как работи и какво може да се направи.

В мрежата Clos има два основни параметъра, които по някакъв начин можем да променяме и да получим определени резултати: радиксът на елементите и броят на нивата в мрежата. Имам схематична диаграма как и двете влияят на размера. В идеалния случай комбинираме и двете.

Може да се види, че крайната ширина на мрежата на Clos е продукт на всички нива на гръбначните превключватели на южния радикс, колко връзки имаме надолу, как се разклонява. Ето как мащабираме размера на мрежата.

По отношение на капацитета, особено на ToR комутаторите, има две опции за мащабиране. Или можем, запазвайки общата топология, да използваме по-бързи връзки, или можем да добавим повече равнини.

Ако погледнете разширената версия на мрежата Clos (в долния десен ъгъл) и се върнете към тази снимка с мрежата Clos по-долу...

... тогава това е точно същата топология, но на този слайд тя е свита по-компактно и равнините на фабриката са насложени една върху друга. Същото е.

Как изглежда мащабирането на Clos мрежа в числа? Тук предоставям данни за това каква максимална ширина може да бъде получена мрежа, какъв максимален брой стелажи, ToR превключватели или листови превключватели, ако не са в стелажи, можем да получим в зависимост от радикса на превключвателите, които използваме за гръбначни нива, и колко нива използваме.

Ето колко шкафове можем да имаме, колко сървъра и приблизително колко може да консумира всичко това на базата на 20 kW на шкаф. Малко по-рано споменах, че се стремим към размер на клъстера от около 100 хиляди сървъра.

Вижда се, че в целия този дизайн интерес представляват две опции и половина. Има опция с два слоя шипове и 64-портови суичове, която малко не достига. След това има идеално подходящи опции за 128-портови (с основа 128) гръбначни превключватели с две нива или превключватели с основа 32 с три нива. И във всички случаи, когато има повече радикси и повече слоеве, можете да направите много голяма мрежа, но ако погледнете очакваното потребление, обикновено има гигавати. Възможно е да положим кабел, но едва ли ще получим толкова ток на един обект. Ако погледнете статистиката и публичните данни за центровете за данни, можете да намерите много малко центрове за данни с приблизителен капацитет над 150 MW. По-големите обикновено са кампуси на центрове за данни, няколко големи центъра за данни, разположени доста близо един до друг.

Има още един важен параметър. Ако погледнете лявата колона, използваемата честотна лента е посочена там. Лесно е да се види, че в Clos мрежа значителна част от портовете се използват за свързване на комутатори един към друг. Използваемата честотна лента, полезна лента е нещо, което може да бъде дадено навън, към сървърите. Естествено, говоря за условни портове и конкретно за лентата. Като правило връзките в мрежата са по-бързи от връзките към сървъри, но на единица честотна лента, колкото и да можем да я изпратим към нашето сървърно оборудване, все още има известна честотна лента в самата мрежа. И колкото повече нива правим, толкова по-големи са специфичните разходи за предоставяне на тази лента навън.

Освен това дори тази допълнителна лента не е съвсем същата. Въпреки че обхватите са кратки, можем да използваме нещо като DAC (директно свързване на мед, т.е. twinax кабели) или многомодова оптика, която струва дори повече или по-малко разумни пари. Веднага щом преминем към по-дълги участъци - като правило това са едномодови оптики и цената на тази допълнителна честотна лента се увеличава значително.

И отново, връщайки се към предишния слайд, ако създадем мрежа Clos без презаписване, тогава е лесно да погледнете диаграмата, да видите как е изградена мрежата - добавяйки всяко ниво на гръбначни превключватели, повтаряме цялата лента, която беше на отдолу. Плюс ниво - плюс същата честотна лента, същия брой портове на комутаторите, каквито имаше на предишното ниво, и същия брой приемо-предаватели. Поради това е много желателно да се сведе до минимум броят на нивата на гръбначните превключватели.

Въз основа на тази картина е ясно, че наистина искаме да изградим нещо като превключватели с радикс 128.

Тук по принцип всичко е същото като това, което току-що казах; това е слайд за разглеждане по-късно.

Какви опции има, които можем да изберем като такива ключове? За нас е много приятна новина, че сега такива мрежи най-накрая могат да бъдат изградени на едночипови комутатори. И това е много готино, имат много хубави функции. Например, те почти нямат вътрешна структура. Това означава, че се чупят по-лесно. Чупят се по всякакви начини, но за щастие се чупят напълно. В модулните устройства има голям брой повреди (много неприятни), когато от гледна точка на съседите и контролната равнина изглежда, че работи, но например част от тъканта е изгубена и не работи при пълен капацитет. И трафикът към него е балансиран въз основа на факта, че е напълно функционален и можем да се претоварим.

Или, например, възникват проблеми със задната платка, защото вътре в модулното устройство има и високоскоростни SerDes - вътре е наистина сложно. Или знаците между препращащите елементи са синхронизирани или не са синхронизирани. По принцип всяко продуктивно модулно устройство, състоящо се от голям брой елементи, като правило съдържа една и съща мрежа Clos вътре в себе си, но е много трудно да се диагностицира. Често дори за самия продавач е трудно да диагностицира.

И има голям брой сценарии на повреда, при които устройството се влошава, но не изпада напълно от топологията. Тъй като нашата мрежа е голяма, активно се използва балансиране между еднакви елементи, мрежата е много регулярна, тоест един път, по който всичко е наред, не се различава от другия път, за нас е по-изгодно просто да загубим част от устройствата от топологията, отколкото да се окажете в ситуация, в която някои от тях изглежда работят, но някои от тях не.

Следващата хубава характеристика на едночиповите устройства е, че те се развиват по-добре и по-бързо. Те също така са склонни да имат по-добър капацитет. Ако вземем големите сглобени структури, които имаме в кръг, тогава капацитетът на стелаж за портове със същата скорост е почти два пъти по-добър от този на модулните устройства. Устройствата, изградени около един чип, са значително по-евтини от модулните и консумират по-малко енергия.

Но, разбира се, всичко това е с причина, има и недостатъци. Първо, радиксът е почти винаги по-малък от този на модулните устройства. Ако можем да получим устройство, изградено около един чип със 128 порта, тогава можем да получим модулно устройство с няколкостотин порта сега без никакви проблеми.

Това е значително по-малък размер на препращащите таблици и, като правило, всичко, свързано с мащабируемостта на равнината на данни. Плитки буфери. И, като правило, доста ограничена функционалност. Но се оказва, че ако знаете тези ограничения и се погрижите навреме да ги заобиколите или просто да ги вземете предвид, тогава това не е толкова страшно. Фактът, че радиксът е по-малък, вече не е проблем при устройства с радикс 128, които най-накрая се появиха наскоро; можем да изградим два слоя шипове. Но все още е невъзможно да се изгради нещо по-малко от две, което да е интересно за нас. С едно ниво се получават много малки клъстери. Дори предишните ни проекти и изисквания все още ги надхвърляха.

Всъщност, ако изведнъж решението е някъде на ръба, все още има начин за мащабиране. Тъй като последното (или първото), най-ниско ниво, където сървърите са свързани, са ToR комутатори или листови комутатори, от нас не се изисква да свързваме един шкаф към тях. Ето защо, ако решението е недостатъчно наполовина, можете да помислите за просто използване на комутатор с голям радикс на по-ниското ниво и свързване, например, на два или три шкафа в един комутатор. Това също е вариант, има своите разходи, но работи доста добре и може да бъде добро решение, когато трябва да достигнете около два пъти по-голям размер.

За да обобщим, ние изграждаме топология с две нива на шипове, с осем фабрични слоя.

Какво ще стане с физиката? Много прости изчисления. Ако имаме две нива на шипове, тогава имаме само три нива на комутатори и очакваме, че ще има три кабелни сегмента в мрежата: от сървъри до листови комутатори, до спин 1, до спин 2. Опциите, които можем използване са - това са twinax, multimode, single mode. И тук трябва да обмислим каква лента е налична, колко ще струва, какви са физическите размери, какви разстояния можем да покрием и как ще надстроим.

По отношение на разходите всичко може да се нареди. Twinax-ите са значително по-евтини от активната оптика, по-евтини от многомодовите трансивъри, ако го вземете на полет от края, малко по-евтини от 100-гигабитов порт за превключване. И, моля, имайте предвид, че струва по-малко от оптиката с единичен режим, тъй като при полети, където се изисква единичен режим, в центровете за данни поради редица причини има смисъл да се използва CWDM, докато паралелният единичен режим (PSM) не е много удобен за работа с много големи опаковки се получават влакна и ако се съсредоточим върху тези технологии, получаваме приблизително следната ценова йерархия.

Още една забележка: за съжаление, не е много възможно да се използват разглобени 100 до 4x25 многомодови портове. Поради конструктивните характеристики на трансивърите SFP28, той не е много по-евтин от 28 Gbit QSFP100. И това разглобяване за мултимода не работи много добре.

Друго ограничение е, че поради размера на изчислителните клъстери и броя на сървърите, нашите центрове за данни се оказват физически големи. Това означава, че поне един полет ще трябва да се извърши с единичен мод. Отново, поради физическия размер на Pods, няма да е възможно да прокарате два участъка twinax (медни кабели).

В резултат на това, ако оптимизираме цената и вземем предвид геометрията на този дизайн, получаваме един участък от twinax, един участък от многомодов и един участък от единичен режим, използвайки CWDM. Това взема предвид възможните пътища за надграждане.

Ето как изглежда напоследък, накъде отиваме и какво е възможно. Ясно е поне как да се премине към 50-гигабитов SerDes както за многомодов, така и за единичен режим. Освен това, ако погледнете какво има в еднорежимните трансивъри сега и в бъдеще за 400G, често дори когато 50G SerDes пристигнат от електрическата страна, 100 Gbps на лента вече могат да отидат към оптиката. Следователно е напълно възможно вместо да се премине към 50, да има преход към 100 Gigabit SerDes и 100 Gbps на лента, тъй като според обещанията на много производители, тяхната наличност се очаква съвсем скоро. Периодът, в който 50G SerDes бяха най-бързите, изглежда няма да е много дълъг, защото първите копия на 100G SerDes се пускат почти през следващата година. И след известно време след това те вероятно ще струват разумни пари.

Още един нюанс относно избора на физика. По принцип вече можем да използваме 400 или 200 Gigabit портове, използвайки 50G SerDes. Но се оказва, че това няма много смисъл, защото, както казах по-рано, ние искаме доста голям радикс на превключвателите, разбира се, в разумни граници. Искаме 128. И ако имаме ограничен капацитет на чипа и увеличим скоростта на връзката, тогава радиксът естествено намалява, няма чудеса.

И можем да увеличим общия капацитет с помощта на самолети и няма специални разходи; можем да добавим броя на самолетите. И ако загубим радикса, ще трябва да въведем допълнително ниво, така че в сегашната ситуация, при сегашния максимален наличен капацитет на чип, се оказва, че е по-ефективно да се използват 100-гигабитови портове, защото те ви позволяват за да получите по-голям радикс.

Следващият въпрос е как е организирана физиката, но от гледна точка на кабелната инфраструктура. Оказва се, че е организирано по доста смешен начин. Окабеляване между листови превключватели и шипове от първо ниво - там няма много връзки, всичко е изградено сравнително просто. Но ако вземем една равнина, това, което се случва вътре е, че трябва да свържем всички бодли от първото ниво с всички бодли от второто ниво.

Плюс това, като правило, има някои желания за това как трябва да изглежда вътре в центъра за данни. Например, ние наистина искахме да комбинираме кабели в сноп и да ги издърпаме, така че един пач панел с висока плътност да влезе изцяло в един пач панел, така че да няма зоопарк по отношение на дължините. Успяхме да разрешим този проблем. Ако първоначално погледнете логическата топология, можете да видите, че равнините са независими, всяка равнина може да бъде построена сама по себе си. Но когато добавим такова групиране и искаме да плъзнем целия пач панел в пач панел, трябва да смесим различни равнини в един пакет и да въведем междинна структура под формата на оптични кръстосани връзки, за да ги преопаковаме от начина, по който са били сглобени на един сегмент, в това как ще бъдат събрани на друг сегмент. Благодарение на това получаваме приятна функция: цялото сложно превключване не излиза извън стелажите. Когато трябва да преплетете нещо много силно, „разгънете равнините“, както понякога се нарича в мрежите на Clos, всичко е концентрирано в една стойка. Нямаме силно разглобени, до отделни връзки, превключване между стелажи.

Така изглежда от гледна точка на логическата организация на кабелната инфраструктура. На снимката вляво многоцветните блокове изобразяват блокове от превключватели на гръбначния стълб от първо ниво, по осем парчета всеки, и четири снопа кабели, идващи от тях, които вървят и се пресичат със сноповете, идващи от блоковете на превключватели на гръбначен стълб 2 .

Малки квадратчета показват пресечки. Горе вляво има разбивка на всяко такова пресичане, това всъщност е 512 на 512 портов модул за кръстосано свързване, който преопакова кабелите, така че да идват изцяло в една стойка, където има само една равнина spine-2. И вдясно, сканиране на тази картина е малко по-подробно във връзка с няколко Pods на ниво spine-1 и как е опаковано в кръстосана връзка, как стига до ниво spine-2.

Ето как изглежда. Все още не напълно сглобената стойка Spine-2 (вляво) и стойката за кръстосано свързване. За съжаление там няма какво да се види. Цялата тази структура се внедрява в момента в един от нашите големи центрове за данни, който се разширява. Това е в процес на работа, ще изглежда по-хубаво, ще бъде попълнено по-добре.

Важен въпрос: избрахме логическата топология и изградихме физиката. Какво ще се случи с контролния самолет? От експлоатационния опит е доста добре известно, има редица доклади, че протоколите за състояние на връзката са добри, удоволствие е да се работи с тях, но, за съжаление, те не се мащабират добре в гъсто свързана топология. И има един основен фактор, който предотвратява това - ето как работи наводняването в протоколите за състояние на връзката. Ако просто вземете алгоритъма за наводняване и погледнете как е структурирана нашата мрежа, можете да видите, че ще има много голям разклонител на всяка стъпка и той просто ще наводни контролната равнина с актуализации. По-конкретно, такива топологии се смесват много слабо с традиционния алгоритъм за наводняване в протоколите за състояние на връзката.

Изборът е да използвате BGP. Как да го подготвите правилно е описано в RFC 7938 относно използването на BGP в големи центрове за данни. Основните идеи са прости: минимален брой префикси на хост и като цяло минимален брой префикси в мрежата, използване на агрегиране, ако е възможно, и потискане на търсенето на път. Искаме много внимателно, много контролирано разпространение на актуализации, което се нарича безплатно от долината. Искаме актуализациите да се внедряват точно веднъж, докато преминават през мрежата. Ако произхождат от дъното, те отиват нагоре, като се разгъват не повече от веднъж. Не трябва да има зигзаг. Зигзагите са много лоши.

За да направим това, ние използваме дизайн, който е достатъчно прост, за да използва основните BGP механизми. Тоест, ние използваме eBGP, работещ на локална връзка, и автономните системи се присвояват, както следва: автономна система на ToR, автономна система на целия блок от превключватели spine-1 на един Pod и обща автономна система на целия Top от плат. Не е трудно да погледнете и да видите, че дори нормалното поведение на BGP ни дава разпространението на актуализациите, които искаме.

Естествено, адресирането и агрегирането на адреси трябва да бъдат проектирани така, че да са съвместими с начина, по който е изградено маршрутизирането, така че да гарантира стабилност на контролната равнина. L3 адресирането в транспорта е обвързано с топологията, защото без това е невъзможно да се постигне агрегиране; без това отделните адреси ще пропълзят в системата за маршрутизиране. И още нещо е, че агрегацията, за съжаление, не се смесва много добре с multi-path, защото когато имаме multi-path и имаме агрегация, всичко е наред, когато цялата мрежа е здрава, няма повреди в нея. За съжаление, веднага щом се появят повреди в мрежата и се загуби симетрията на топологията, можем да стигнем до точката, от която е обявена единицата, от която не можем да отидем по-нататък до мястото, където трябва да отидем. Следователно, най-добре е да се агрегират там, където няма повече многопътести, в нашия случай това са ToR комутатори.

Всъщност е възможно да се агрегира, но внимателно. Ако можем да направим контролирана дезагрегация, когато възникнат мрежови повреди. Но това е доста трудна задача, дори се чудехме дали ще бъде възможно да направим това, дали е възможно да добавим допълнителна автоматизация и автомати с крайни състояния, които правилно да ритат BGP, за да получат желаното поведение. За съжаление обработката на ъглови случаи е много неочевидна и сложна и тази задача не се решава добре чрез прикачване на външни прикачени файлове към BGP.

Много интересна работа в това отношение е извършена в рамките на протокола RIFT, който ще бъде обсъден в следващия доклад.

Друго важно нещо е как се мащабират равнините на данни в плътни топологии, където имаме голям брой алтернативни пътища. В този случай се използват няколко допълнителни структури от данни: ECMP групи, които от своя страна описват Next Hop групи.

В нормално работеща мрежа, без повреди, когато вървим нагоре по топологията Clos, достатъчно е да използваме само една група, защото всичко, което не е локално, е описано по подразбиране, можем да се качим. Когато вървим отгоре надолу на юг, тогава всички пътеки не са ECMP, те са единични пътеки. Всичко е наред. Проблемът е и особеността на класическата топология на Clos е, че ако погледнем горната част на тъканта, всеки елемент, има само един път до всеки елемент отдолу. Ако възникнат повреди по този път, тогава този конкретен елемент в горната част на фабриката става невалиден точно за тези префикси, които се намират зад счупения път. Но за останалото е валидно и трябва да анализираме групите ECMP и да въведем ново състояние.

Как изглежда мащабируемостта на равнината на данни на съвременните устройства? Ако направим LPM (най-дълго съвпадение на префикса), всичко е доста добре, над 100k префикса. Ако говорим за групи Next Hop, тогава всичко е по-лошо, 2-4 хиляди. Ако говорим за таблица, която съдържа описание на Next Hops (или adjacencies), тогава това е някъде от 16k до 64k. И това може да се превърне в проблем. И тук стигаме до едно интересно отклонение: какво се случи с MPLS в центровете за данни? По принцип искахме да го направим.

Две неща се случиха. Направихме микросегментиране на хостовете; вече нямаше нужда да го правим в мрежата. Не беше много добре с поддръжка от различни доставчици и още повече с отворени реализации на бели кутии с MPLS. А MPLS, поне традиционните му реализации, за съжаление, се комбинира много зле с ECMP. И ето защо.

Ето как изглежда структурата за препращане на ECMP за IP. Голям брой префикси могат да използват една и съща група и един и същ блок Next Hops (или съседства, това може да се нарича по различен начин в различна документация за различни устройства). Въпросът е, че това е описано като изходящия порт и на какво да пренапише MAC адреса, за да стигнете до правилния Next Hop. За IP всичко изглежда просто, можете да използвате много голям брой префикси за една и съща група, един и същ блок Next Hops.

Класическата MPLS архитектура предполага, че в зависимост от изходящия интерфейс, етикетът може да бъде пренаписан на различни стойности. Следователно трябва да запазим група и блок Next Hops за всеки входен етикет. И това, уви, не мащабира.

Лесно е да се види, че в нашия дизайн се нуждаехме от около 4000 ToR комутатора, максималната ширина беше 64 ECMP пътеки, ако се отдалечим от spine-1 към spine-2. Едва влизаме в една таблица с ECMP групи, ако само един префикс с ToR изчезне, и изобщо не влизаме в таблицата Next Hops.

Не всичко е безнадеждно, защото архитектури като Segment Routing включват глобални етикети. Формално би било възможно всички тези блокове Next Hops да се свият отново. За да направите това, имате нужда от операция от тип заместващ знак: вземете етикет и го пренапишете на същия без конкретна стойност. Но за съжаление, това не присъства много в наличните реализации.

И накрая, трябва да пренесем външен трафик към центъра за данни. Как да го направим? Преди това трафикът беше въведен в мрежата на Clos отгоре. Тоест имаше крайни рутери, които се свързваха с всички устройства в горната част на тъканта. Това решение работи доста добре при малки до средни размери. За съжаление, за да изпратим трафик симетрично към цялата мрежа по този начин, трябва да стигнем до всички елементи на Top of fabric едновременно, а когато има повече от сто от тях, се оказва, че имаме нужда и от голям радикс на крайните рутери. Като цяло това струва пари, защото edge рутерите са по-функционални, портовете на тях ще бъдат по-скъпи, а дизайнът не е много красив.

Друг вариант е да стартирате такъв трафик отдолу. Лесно е да се провери, че топологията на Clos е изградена по такъв начин, че трафикът, идващ отдолу, тоест от страната на ToR, е равномерно разпределен между нивата в целия Top of fabric в две итерации, зареждайки цялата мрежа. Затова въвеждаме специален тип Pod, Edge Pod, който осигурява външна свързаност.

Има още един вариант. Това прави Facebook например. Наричат ​​го Fabric Aggregator или HGRID. Въвежда се допълнително ниво на гръбнака за свързване на множество центрове за данни. Този дизайн е възможен, ако нямаме допълнителни функции или промени в капсулирането на интерфейсите. Ако са допълнителни допирни точки, е трудно. Обикновено има повече функции и нещо като мембрана, разделяща различните части на центъра за данни. Няма смисъл да се прави такава мембрана голяма, но ако наистина е необходима по някаква причина, тогава има смисъл да се обмисли възможността да се отнеме, да се направи възможно най-широка и да се прехвърли на домакините. Това се прави например от много облачни оператори. Имат наслагвания, започват от домакините.

Какви възможности за развитие виждаме? На първо място, подобряване на поддръжката за конвейера CI/CD. Искаме да летим по начина, по който изпитваме, и да изпробваме начина, по който летим. Това не се получава много добре, защото инфраструктурата е голяма и е невъзможно да се дублира за тестове. Трябва да разберете как да въведете тестови елементи в производствената инфраструктура, без да я изпускате.

По-доброто оборудване и по-доброто наблюдение почти никога не са излишни. Целият въпрос е балансът на усилията и възвръщаемостта. Ако можете да го добавите с разумни усилия, много добре.

Отворени операционни системи за мрежови устройства. По-добри протоколи и по-добри системи за маршрутизиране, като RIFT. Необходими са също изследвания за използването на по-добри схеми за контрол на претоварването и може би въвеждането, поне в някои моменти, на поддръжка на RDMA в рамките на клъстера.

Гледайки по-далеч в бъдещето, имаме нужда от усъвършенствани топологии и евентуално мрежи, които използват по-малко режийни разходи. От свежите неща наскоро се появиха публикации за технологията на тъканта за HPC Cray Slingshot, която е базирана на стандартния Ethernet, но с възможност за използване на много по-къси хедъри. В резултат на това режийните разходи се намаляват.

Всичко трябва да бъде възможно най-просто, но не и по-просто. Сложността е враг на мащабируемостта. Простотата и редовните структури са наши приятели. Ако можете да направите мащабиране някъде, направете го. И като цяло, сега е страхотно да се занимаваш с мрежови технологии. Случват се много интересни неща. Благодаря ти.

Източник: www.habr.com