Как да мащабираме дата-центровете. Доклад на Яндекс

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

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

— Здравейте на всички! Казвам се Дмитрий Афанасьев, аз съм мрежов архитект в Яндекс и се занимавам главно с дизайна на мрежи на дата центрове.



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

И така, какво всъщност представлява Яндекс от гледна точка на натоварвания и услуги? Яндекс е типичен хиперскейлър. Ако погледнем от страната на потребителите, на първо място обработваме потребителски запитвания. Освен това предлагаме различни стрийминг услуги и доставка на данни, тъй като имаме и storage услуги. Ако се приближим до бекенда, там има инфраструктурни натоварвания и услуги, като разпределени обектни хранилища, репликация на данни и, разбира се, persistent queues. Един от основните типове натоварвания е MapReduce и подобни системи, потокова обработка, машинно обучение и т.н.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В случаите на двустепенни Clos, когато ясно можем да разделим компонентите, които в схемата ми са вертикални, те обикновено се нарекат плоскости. Ако изграждахме Clos с три нива на spine switch-ове (всички, които не са крайни и не са ToR switch-ове и които се използват само за транзит), плоскостите биха изглеждали по-сложно, а двустепенните изглеждат именно така. Блокът на ToR или leaf switch-ове и асоциираните с тях spine switch-ове от първо ниво наричаме Pod. Spine switch-овете от ниво spine-1 в горната част на Pod са top of Pod, върхът на Pod. Switch-овете, които са разположени в горната част на цялата фабрика, са горният слой на фабриката, Top of fabric.

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

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

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

Освен това, тъй като голяма част от капацитета не е достъпна по най-кратките маршрути, трябва да модифицираме не само контролния план, за да избира всичките тези маршрути (и, между другото, това значително увеличава състоянието в контролния план). Трябва да модифицираме и предавания план, като обикновено са необходими поне две допълнителни функции. Първата е възможността да се вземат всички решения за предаване на пакети наведнъж, например на хоста. Всъщност, това е source routing; понякога в литературата относно мрежовата свързаност се нарича вземане на решения за предаване наведнъж. И още adaptive routing — това е функция, която е необходима на мрежовите елементи, и която например избира следващия хоп на базата на информация за най-ниското натоварване на опашката. Например, възможни са и други варианти.

Следователно, посоката е интересна, но за съжаление, в момента не можем да я приложим.

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

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

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

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

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

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

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

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

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

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

Освен това, дори и тази допълнителна честотна лента не е напълно еднаква. Докато разстоянията са кратки, можем да използваме нещо като DAC (direct attach copper, т.е. twinax кабели) или multimode оптика, която все още е на разумни цени. В момента, в който преминем на по-дълги разстояния — обикновено това е single mode оптика, и цената на тази допълнителна честотна лента значително нараства.

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

На базата на това изображение, виждаме, че много искаме да изграждаме на нещо, като превключватели с радикс 128.

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

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

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

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

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

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

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

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

В заключение, изграждаме топология с два слоя спайнове и осем слоя фабрика.

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

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

Още едно забележка: за съжаление, не е много удачно да се използват разглобени 100 към 4x25 многомодови портове. Поради особеностите на конструкцията на SFP28 трансиверите, те не се оказват много по-евтини от QSFP28 на 100 Гбит. И това разглобяване за многомодовите оптики не работи много добре.

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

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

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

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

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

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

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

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

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

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

Не по-малко важен въпрос: избрахме логична топология, изградихме физиката. Какво ще се случи с control plane? Достатъчно добре е известно от опит, че има известно количество представяния, че протоколите на базата на link state са добри, приятно е да се работи с тях, но за съжаление, на плътно свързана топология те се мащабират лошо. И има един основен фактор, който пречи на това — как работи флуидингът в протоколите на базата на link state. Ако просто вземем алгоритъма за флуидинг и погледнем как е устроена нашата мрежа, ще видим, че на всяка стъпка ще има много голям fanout, и просто ще залива control plane с ъпдейти. Конкретно такива топологии конкретно с традиционния алгоритъм за флуидинг в протоколите на базата на link state се смесват много лошо.

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

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

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

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

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

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

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

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

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

Така изглежда структурата на ECMP-форвардинга за IP. Голямо количество префикси може да използва една и съща група и един и същ блок Next Hops (или adjacencies, в различната документация на различни устройства това може да се нарича по различен начин). Същността е, че това се описва като изходен порт и на какво да се пренапише МАС-адреса, за да достигне до правилния Next Hop. За IP всичко изглежда просто; може да се използва за много голямо количество префикси на една и съща група, един и същ блок Next Hops.

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

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

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

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

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

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

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

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

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

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

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

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