Како скалирати центре података. Јандекс извештај

Развили смо дизајн мреже центара података који омогућава примену рачунарских кластера већих од 100 хиљада сервера са максималном ширином опсега бисекције од преко једног петабајта у секунди.

Из извештаја Дмитрија Афанасјева сазнаћете о основним принципима новог дизајна, топологијама скалирања, проблемима који се јављају при томе, опцијама за њихово решавање, карактеристикама рутирања и скалирања функција равни прослеђивања савремених мрежних уређаја у „густо повезаним“ топологије са великим бројем ЕЦМП рута . Поред тога, Дима је укратко говорио о организацији екстерног повезивања, физичком слоју, кабловском систему и начинима даљег повећања капацитета.

- Добар дан свима! Моје име је Дмитриј Афанасјев, ја сам мрежни архитекта у Иандек-у и првенствено дизајнирам мреже центара података.



Моја прича ће бити о ажурираној мрежи Иандек дата центара. То је у великој мери еволуција дизајна који смо имали, али у исто време постоје и неки нови елементи. Ово је прегледна презентација јер је било много информација које је требало упаковати у мало времена. Почећемо са избором логичке топологије. Затим ће бити преглед контролне равни и проблема са скалабилношћу равни података, избор шта ће се десити на физичком нивоу, а ми ћемо погледати неке карактеристике уређаја. Хајде да се мало дотакнемо онога што се дешава у дата центру са МПЛС-ом, о чему смо причали пре неког времена.

Дакле, шта је Иандек у смислу оптерећења и услуга? Иандек је типичан хиперскалер. Ако посматрамо кориснике, првенствено обрађујемо захтеве корисника. Такође разни стриминг сервиси и пренос података, јер имамо и услуге складиштења. Ако је ближе бацкенд-у, онда се тамо појављују инфраструктурна оптерећења и услуге, као што су складиштење дистрибуираних објеката, репликација података и, наравно, упорни редови. Један од главних типова оптерећења су МапРедуце и слични системи, обрада тока, машинско учење итд.

Каква је инфраструктура на којој се све ово дешава? Опет, ми смо прилично типичан хиперскалер, иако смо можда мало ближе нижој хиперскалерској страни спектра. Али ми имамо све атрибуте. Користимо робни хардвер и хоризонтално скалирање где год је то могуће. Имамо потпуно обједињавање ресурса: не радимо са појединачним машинама, појединачним регалима, већ их комбинујемо у велики скуп заменљивих ресурса са неким додатним услугама које се баве планирањем и алокацијом, и радимо са целим овим базеном.

Дакле, имамо следећи ниво - оперативни систем на нивоу рачунарског кластера. Веома је важно да у потпуности контролишемо технолошки скуп који користимо. Ми контролишемо крајње тачке (хостове), мрежу и софтверски стог.

Имамо неколико великих дата центара у Русији и иностранству. Обједињује их кичма која користи МПЛС технологију. Наша интерна инфраструктура је скоро у потпуности изграђена на ИПв6, али пошто морамо да опслужујемо спољни саобраћај који и даље долази углавном преко ИПв4, морамо некако да испоручимо захтеве који долазе преко ИПв4 на фронтенд сервере, а још мало ићи на екстерни ИПв4- Интернет - за на пример, за индексирање.

Последњих неколико итерација дизајна мрежа центара података користиле су вишеслојне Цлос топологије и само су Л3. Малопре смо напустили Л2 и одахнули. Коначно, наша инфраструктура укључује стотине хиљада рачунарских (серверских) инстанци. Максимална величина кластера пре неког времена била је око 10 хиљада сервера. Ово је углавном због тога како ти исти оперативни системи на нивоу кластера, распоређивачи, алокација ресурса итд. могу да функционишу. Пошто се напредак догодио на страни инфраструктурног софтвера, циљна величина је сада око 100 хиљада сервера у једном рачунарском кластеру, и Имамо задатак – да можемо да изградимо мрежне фабрике које омогућавају ефикасно удруживање ресурса у таквом кластеру.

Шта желимо од мреже дата центара? Пре свега, постоји много јефтиног и прилично равномерно распоређеног пропусног опсега. Зато што је мрежа кичма преко које можемо да удружимо ресурсе. Нова циљна величина је око 100 хиљада сервера у једном кластеру.

Такође, наравно, желимо скалабилну и стабилну контролну раван, јер на тако великој инфраструктури многе главобоље настају чак и из просто случајних догађаја, а не желимо да нам контролна раван доноси и главобоље. Истовремено желимо да минимизирамо стање у њему. Што је стање мање, то боље и стабилније све функционише и лакше се дијагностикује.

Наравно, потребна нам је аутоматизација, јер је таквом инфраструктуром немогуће управљати ручно, а већ неко време је немогуће. Потребна нам је оперативна подршка што је више могуће и ЦИ/ЦД подршка у мери у којој је то могуће.

Са таквим величинама центара података и кластера, задатак подршке инкременталној имплементацији и проширењу без прекида услуге постао је прилично акутан. Ако би на кластерима величине хиљаду машина, можда близу десет хиљада машина, могли да се и даље развију као једна операција – односно планирамо проширење инфраструктуре, а неколико хиљада машина се додаје као једна операција, онда кластер величине сто хиљада машина не настаје одмах овако, већ се гради у одређеном временском периоду. И пожељно је да све ово време оно што је већ испумпано, инфраструктура која је распоређена, буде на располагању.

И један захтев који смо имали и оставили: подршка за мултитенанци, односно виртуелизацију или сегментацију мреже. Сада не морамо ово да радимо на нивоу мрежне тканине, јер је дељење отишло на хостове, а то нам је веома олакшало скалирање. Захваљујући ИПв6 и великом адресном простору, нисмо морали да користимо дупле адресе у интерној инфраструктури; сво адресирање је већ било јединствено. А захваљујући чињеници да смо филтрирање и сегментацију мреже преузели на хостове, не морамо да креирамо било какве виртуелне мрежне ентитете у мрежама центара података.

Веома важна ствар је оно што нам не треба. Ако се неке функције могу уклонити са мреже, то знатно олакшава живот, а по правилу проширује избор доступне опреме и софтвера, чинећи дијагностику веома једноставном.

Дакле, шта је то што нам не треба, чега смо успели да се одрекнемо, не увек са радошћу у тренутку када се то догодило, али са великим олакшањем када се процес заврши?

Пре свега, напуштање Л2. Не треба нам Л2, ни прави ни емулирани. Неискоришћен углавном због чињенице да контролишемо стек апликација. Наше апликације су хоризонтално скалабилне, раде са Л3 адресирањем, нису много забринуте што се нека појединачна инстанца угасила, једноставно пуштају нову, не треба је увести на стару адресу, јер постоји посебан ниво откривања услуга и праћења машина које се налазе у кластеру . Овај задатак не делегирамо мрежи. Задатак мреже је да испоручује пакете од тачке А до тачке Б.

Такође немамо ситуације да се адресе крећу унутар мреже и то треба пратити. У многим дизајнима ово је обично потребно за подршку мобилности ВМ-а. Ми не користимо мобилност виртуелних машина у интерној инфраструктури великог Иандек-а, и, штавише, верујемо да чак и ако се то уради, то не би требало да се деси уз мрежну подршку. Ако то заиста треба да се уради, то треба да се уради на нивоу хоста, и гурне адресе које могу да мигрирају у преклапања, како не би додиривали или уносили превише динамичких промена у систем рутирања саме подлоге (транспортне мреже) .

Друга технологија коју не користимо је мултицаст. Ако желите, могу вам детаљно рећи зашто. Ово знатно олакшава живот, јер ако се неко бавио тиме и погледао како тачно изгледа контролна раван за вишеструко емитовање, у свим инсталацијама осим у најједноставнијим, ово је велика главобоља. И штавише, тешко је наћи добро функционишућу имплементацију отвореног кода, на пример.

Коначно, дизајнирамо наше мреже тако да се не мењају превише. Можемо рачунати на чињеницу да је проток спољашњих догађаја у систему рутирања мали.

Који проблеми настају и која ограничења морамо узети у обзир када развијамо мрежу дата центара? Цена, наравно. Скалабилност, ниво до којег желимо да растемо. Потреба за проширењем без заустављања услуге. Пропусни опсег, доступност. Видљивост шта се дешава на мрежи за системе за праћење, за оперативне тимове. Подршка за аутоматизацију - опет, колико год је то могуће, пошто се различити задаци могу решавати на различитим нивоима, укључујући и увођење додатних слојева. Па, не [могуће] да зависи од добављача. Иако је у различитим историјским периодима, у зависности од тога који део погледате, ова независност била лакше или теже остварива. Ако узмемо пресек чипова мрежних уређаја, онда је донедавно било веома условно говорити о независности од произвођача, ако смо желели и чипове са великом пропусношћу.

Коју ћемо логичку топологију користити за изградњу наше мреже? Ово ће бити Цлос на више нивоа. У ствари, у овом тренутку не постоје праве алтернативе. А Цлос топологија је прилично добра, чак и у поређењу са разним напредним топологијама које су сада више у области академског интереса, ако имамо велике радикс прекидаче.

Како је Цлос мрежа на више нивоа грубо структурирана и како се у њој зову различити елементи? Пре свега, дигао се ветар, да се оријентишете где је север, где је југ, где је исток, где је запад. Мреже овог типа обично граде они који имају веома велики саобраћај запад-исток. Што се тиче преосталих елемената, на врху је виртуелни прекидач састављен од мањих прекидача. Ово је главна идеја рекурзивне конструкције Цлос мрежа. Узимамо елементе са неком врстом радикса и повезујемо их тако да се оно што добијемо може сматрати прекидачем са већим радиксом. Ако вам је потребно још више, поступак се може поновити.

У случајевима, на пример, са два нивоа Цлос, када је могуће јасно идентификовати компоненте које су вертикалне у мом дијаграму, оне се обично називају равнима. Ако бисмо направили Цлос са три нивоа кичмених прекидача (који нису гранични или ТоР прекидачи и који се користе само за транзит), онда би авиони изгледали сложеније; они на два нивоа изгледају управо овако. Блок ТоР или листа прекидача и прекидаче за кичму првог нивоа који су повезани са њима називамо Под. Прекидачи за кичму на нивоу кичме-1 на врху Под-а су врх Под-а, врх Под-а. Прекидачи који се налазе на врху целе фабрике су горњи слој фабрике, Врх тканине.

Наравно, поставља се питање: Цлос мреже су грађене већ неко време, а сама идеја углавном потиче из времена класичне телефоније, ТДМ мрежа. Можда се појавило нешто боље, можда се нешто може боље урадити? Да и не. Теоретски да, у пракси у блиској будућности дефинитивно не. Пошто постоји велики број занимљивих топологија, неке од њих се чак користе у производњи, на пример, Драгонфли се користи у ХПЦ апликацијама; Постоје и занимљиве топологије као што су Кспандер, ФатЦликуе, Јеллифисх. Ако недавно погледате извештаје са конференција попут СИГЦОММ или НСДИ, можете пронаћи прилично велики број радова о алтернативним топологијама које имају боља својства (једна или она) од Цлос-а.

Али све ове топологије имају једно занимљиво својство. То онемогућава њихову имплементацију у мрежама центара података, које покушавамо да изградимо на робном хардверу и које коштају прилично разумне паре. У свим овим алтернативним топологијама, већина пропусног опсега нажалост није доступна најкраћим путевима. Стога одмах губимо прилику да користимо традиционалну контролну равнину.

Теоретски, решење проблема је познато. То су, на пример, модификације стања везе коришћењем к-најкраћег пута, али, опет, не постоје такви протоколи који би били имплементирани у производњи и широко доступни на опреми.

Штавише, пошто већина капацитета није доступна преко најкраћих путева, морамо да модификујемо више од саме контролне равни да бисмо изабрали све те путање (и успут, ово је знатно више стања у контролној равни). Још увек треба да изменимо раван за прослеђивање, а по правилу су потребне најмање две додатне функције. Ово је могућност да се све одлуке о прослеђивању пакета доносе једнократно, на пример, на хосту. У ствари, ово је изворно рутирање, понекад се у литератури о интерконекцијским мрежама то назива одлукама о прослеђивању одједном. А адаптивно рутирање је функција која нам је потребна на мрежним елементима, а која се своди, на пример, на чињеницу да бирамо следећи скок на основу информација о најмањем оптерећењу у реду чекања. Као пример, могуће су и друге опције.

Дакле, правац је интересантан, али га, авај, тренутно не можемо применити.

У реду, одлучили смо се за логичку топологију Цлос. Како ћемо га скалирати? Хајде да видимо како то функционише и шта се може учинити.

У Цлос мрежи постоје два главна параметра која некако можемо да варирамо и добијемо одређене резултате: радикс елемената и број нивоа у мрежи. Имам шематски дијаграм како оба утичу на величину. У идеалном случају, комбинујемо обоје.

Може се видети да је коначна ширина Цлос мреже производ свих нивоа кичмених прекидача јужног радикса, колико линкова имамо доле, како се она грана. Овако скалирамо величину мреже.

Што се тиче капацитета, посебно на ТоР прекидачима, постоје две опције скалирања. Или можемо, уз одржавање опште топологије, користити брже везе, или можемо додати више равни.

Ако погледате проширену верзију мреже Цлос (у доњем десном углу) и вратите се на ову слику са Цлос мрежом испод...

... онда је ово потпуно иста топологија, али на овом слајду је компактније скупљена и равни фабрике су постављене једна на другу. То је исто.

Како изгледа скалирање Цлос мреже у бројевима? Овде дајем податке о томе коју максималну ширину мрежа може да се добије, који максималан број рекова, ТоР прекидача или лисних прекидача, ако нису у рековима, можемо добити у зависности од тога који радикс прекидача користимо за нивое кичме и колико нивоа користимо.

Ево колико рекова можемо да имамо, колико сервера и колико отприлике све ово може да потроши на основу 20 кВ по реку. Мало раније сам поменуо да циљамо на величину кластера од око 100 хиљада сервера.

Види се да у целом овом дизајну интересују две и по опције. Постоји опција са два слоја бодљи и прекидачима са 64 порта, што је мало мање. Затим постоје савршено прикладне опције за 128-портне (са радиксом 128) прекидаче за кичму са два нивоа, или прекидаче са радиксом 32 са три нивоа. И у свим случајевима, где има више радикса и више слојева, можете направити веома велику мрежу, али ако погледате очекивану потрошњу, обично има гигавата. Могуће је поставити кабл, али тешко да ћемо добити толико струје на једном месту. Ако погледате статистику и јавне податке о дата центрима, можете пронаћи врло мало центара података са процењеним капацитетом већим од 150 МВ. Већи су обично кампуси центара података, неколико великих центара података који се налазе прилично близу један другом.

Постоји још један важан параметар. Ако погледате леву колону, тамо је наведена корисна пропусност. Лако је видети да се у Цлос мрежи значајан део портова користи за међусобно повезивање прекидача. Употребљиви пропусни опсег, корисна трака, је нешто што се може дати споља, према серверима. Наравно, говорим о условним портовима и посебно о бенду. Линкови унутар мреже су по правилу бржи од линкова ка серверима, али по јединици пропусног опсега, колико год можемо да га пошаљемо на нашу серверску опрему, ипак постоји нешто пропусног опсега унутар саме мреже. И што више нивоа направимо, то је већи специфични трошак пружања ове траке споља.

Штавише, чак ни овај додатни бенд није потпуно исти. Док су распони кратки, можемо користити нешто попут ДАЦ-а (директно причвршћивање бакарних, односно твинак каблова), или вишемодну оптику, која кошта чак и мање-више разумне паре. Чим пређемо на веће распоне - по правилу, то су оптика једног мода, а цена овог додатног пропусног опсега се приметно повећава.

И опет, враћајући се на претходни слајд, ако креирамо Цлос мрежу без прекомерне претплате, онда је лако погледати дијаграм, видети како је мрежа изграђена - додајући сваки ниво кичмених прекидача, понављамо целу траку која је била на дно. Плус ниво - плус исти опсег, исти број портова на прекидачима као што је било на претходном нивоу и исти број примопредајника. Због тога је веома пожељно минимизирати број нивоа прекидача кичме.

На основу ове слике, јасно је да заиста желимо да изградимо нешто попут прекидача са радиксом од 128.

Овде је, у принципу, све исто као што сам управо рекао, ово је слајд за разматрање касније.

Које опције постоје које можемо изабрати као такве прекидаче? За нас је веома пријатна вест да се сада такве мреже коначно могу градити на прекидачима са једним чипом. И ово је веома кул, имају много лепих карактеристика. На пример, немају скоро никакву унутрашњу структуру. То значи да се лакше ломе. Разбијају се на разне начине, али се на срећу потпуно ломе. Код модуларних уређаја постоји велики број кварова (веома непријатних), када са становишта суседа и контролне равни изгледа да ради, али, на пример, део тканине је изгубљен и не ради пуним капацитетом. А саобраћај до њега је балансиран на основу чињенице да је потпуно функционалан и да можемо бити преоптерећени.

Или, на пример, настају проблеми са задњом плочом, јер се унутар модуларног уређаја налазе и брзи СерДес - унутра је заиста сложен. Знакови између елемената за прослеђивање су или синхронизовани или нису синхронизовани. Генерално, сваки продуктивни модуларни уређај који се састоји од великог броја елемената, по правилу, садржи исту Цлос мрежу унутар себе, али је веома тешко дијагностиковати. Често је чак и самом продавцу тешко да постави дијагнозу.

И има велики број сценарија кварова у којима се уређај деградира, али не испада у потпуности из топологије. Пошто је наша мрежа велика, активно се користи балансирање између идентичних елемената, мрежа је врло правилна, односно један пут на коме је све у реду се не разликује од другог пута, исплативије нам је да једноставно изгубимо нешто од уређаја из топологије него да дођу у ситуацију да неки од њих раде, а неки не.

Следећа лепа карактеристика уређаја са једним чипом је да се развијају боље и брже. Они такође имају већи капацитет. Ако узмемо велике склопљене структуре које имамо у кругу, онда је капацитет по јединици река за портове исте брзине скоро двоструко бољи од модуларних уређаја. Уређаји направљени око једног чипа приметно су јефтинији од модуларних и троше мање енергије.

Али, наравно, ово је све са разлогом, постоје и недостаци. Прво, радикс је скоро увек мањи од оног код модуларних уређаја. Ако можемо да добијемо уређај направљен око једног чипа са 128 портова, онда можемо да добијемо модуларни са неколико стотина портова сада без икаквих проблема.

Ово је приметно мања величина табела прослеђивања и, по правилу, свега што се односи на скалабилност у равни података. Плитки пуфери. И, по правилу, прилично ограничена функционалност. Али испоставило се да ако знате ова ограничења и на време водите рачуна да их заобиђете или једноставно узмете у обзир, онда то није тако страшно. Чињеница да је радикс мањи више није проблем на уређајима са радиксом од 128 који су се недавно појавили; можемо уградити два слоја кичме. Али још увек је немогуће изградити нешто мање од два што је за нас интересантно. Са једним нивоом добијају се веома мали кластери. Чак су их и наши претходни дизајни и захтеви и даље превазилазили.

У ствари, ако се одједном решење нађе негде на ивици, још увек постоји начин за скалирање. Пошто су последњи (или први), најнижи ниво на коме су сервери повезани, ТоР прекидачи или лисни прекидачи, од нас се не тражи да повежемо један рацк на њих. Стога, ако решење падне за око половину, можете размишљати о једноставном коришћењу прекидача са великим радиксом на нижем нивоу и повезивању, на пример, два или три река у један прекидач. Ово је такође опција, има своје трошкове, али ради прилично добро и може бити добро решење када треба да достигнете дупло већу величину.

Да резимирамо, градимо топологију са два нивоа кичме, са осам фабричких слојева.

Шта ће бити са физиком? Веома једноставне прорачуне. Ако имамо два нивоа кичме, онда имамо само три нивоа прекидача, а очекујемо да ће у мрежи бити три сегмента кабла: од сервера до лисних прекидача, до кичме 1, до кичме 2. Опције које можемо употреба су - то су твинак, мултимоде, сингле моде. И овде треба да размотримо која трака је доступна, колико ће коштати, које су физичке димензије, које распоне можемо покрити и како ћемо надоградити.

Што се тиче трошкова, све се може поређати. Твинак-ови су знатно јефтинији од активне оптике, јефтинији од мултимодних примопредајника, ако се узимају по лету од краја, нешто јефтинији од 100-гигабитног свич порта. И, имајте на уму, кошта мање од сингле моде оптике, јер на летовима где је један режим потребан, у центрима података из више разлога има смисла користити ЦВДМ, док паралелни сингле мод (ПСМ) није баш згодан за рад са веома великим паковањима добијају се влакна, а ако се фокусирамо на ове технологије, добијамо отприлике следећу хијерархију цена.

Још једна напомена: нажалост, није баш могуће користити растављене вишемодне портове од 100 до 4к25. Због карактеристика дизајна СФП28 примопредајника, није много јефтинији од 28 Гбит КСФП100. А ово растављање за мултимоде не ради баш добро.

Још једно ограничење је то што се због величине рачунарских кластера и броја сервера наши центри података испостављају као физички велики. То значи да ће најмање један лет морати да се обави са синглемодом. Опет, због физичке величине Подова, неће бити могуће покренути два распона твинак-а (бакарних каблова).

Као резултат тога, ако оптимизујемо за цену и узмемо у обзир геометрију овог дизајна, добијамо један распон твинак-а, један распон мултимодног и један распон синглемоде користећи ЦВДМ. Ово узима у обзир могуће путеве надоградње.

Овако то изгледа у последње време, куда идемо и шта је могуће. Јасно је, барем, како се прећи на 50-Гигабитни СерДес и за мултимод и за синглемоде. Штавише, ако погледате шта је у једномодним примопредајницима сада иу будућности за 400Г, често чак и када 50Г СерДес стигну са електричне стране, 100 Гбпс по траци већ може ићи у оптику. Због тога је сасвим могуће да ће уместо преласка на 50 доћи до преласка на 100 Гигабит СерДес и 100 Гбпс по траци, јер се према обећањима многих продаваца њихова доступност очекује прилично брзо. Период када су 50Г СерДес били најбржи, чини се, неће бити дуго, јер прве копије 100Г СерДес излазе скоро следеће године. И после неког времена после тога вероватно ће вредети разумног новца.

Још једна нијанса о избору физике. У принципу, већ можемо да користимо 400 или 200 Гигабит портова користећи 50Г СерДес. Али испоставило се да ово нема много смисла, јер, као што сам раније рекао, желимо прилично велики радикс на прекидачима, у разумном року, наравно. Хоћемо 128. А ако имамо ограничен капацитет чипа и повећамо брзину везе, онда се радикс природно смањује, нема чуда.

А авионима можемо повећати укупан капацитет и нема посебних трошкова, можемо додати број авиона. А ако изгубимо радикс, мораћемо да уведемо додатни ниво, па се у тренутној ситуацији, са тренутним максималним расположивим капацитетом по чипу, испоставља да је ефикасније користити 100-гигабитне портове, јер вам они омогућавају да добијете већи радикс.

Следеће питање је како је физика организована, али са становишта кабловске инфраструктуре. Испоставило се да је то организовано на прилично забаван начин. Каблирање између лиснатих прекидача и шиљака првог нивоа - ту нема много веза, све је изграђено релативно једноставно. Али ако узмемо једну раван, оно што се дешава унутра је да треба да повежемо све кичме првог нивоа са свим кичмама другог нивоа.

Плус, по правилу, постоје неке жеље како би то требало да изгледа унутар дата центра. На пример, заиста смо желели да спојимо каблове у сноп и повучемо их тако да један патцх панел високе густине иде у потпуности у један патцх панел, тако да није било зоолошког врта у смислу дужине. Успели смо да решимо овај проблем. Ако у почетку погледате логичку топологију, можете видети да су равни независне, свака раван се може градити за себе. Али када додамо такав пакет и желимо да превучемо цео патцх панел у патцх панел, морамо да помешамо различите равни унутар једног пакета и уведемо међуструктуру у облику оптичких унакрсних веза да бисмо их поново спаковали од начина на који су састављени на једном сегменту, како ће се прикупљати на другом сегменту. Захваљујући томе, добијамо лепу особину: све сложене комутације не прелазе оквире. Када треба нешто јако снажно да преплетете, „развијете авионе“, како се то понекад назива у Цлос мрежама, све је то концентрисано унутар једног сталка. Немамо високо растављене, све до појединачних карика, пребацивање између рекова.

Овако то изгледа са становишта логичне организације кабловске инфраструктуре. На слици лево, разнобојни блокови приказују блокове кичмених прекидача првог нивоа, по осам комада, и четири снопа каблова који долазе из њих, који иду и укрштају се са сноповима који долазе из блокова кичмених-2 прекидача. .

Мали квадрати означавају раскрснице. У горњем левом углу је преглед сваке такве раскрснице, ово је заправо модул за унакрсну везу 512 к 512 портова који поново пакује каблове тако да у потпуности долазе у један рацк, где постоји само једна спине-2 раван. А на десној страни, скенирање ове слике је мало детаљније у односу на неколико Подова на нивоу кичме-1, и како је упаковано у унакрсно повезивање, како долази до нивоа кичме-2.

Овако то изгледа. Сталак за кичму-2 (лево) и постоље за унакрсно повезивање. Нажалост, тамо нема много тога да се види. Цела ова структура се тренутно поставља у једном од наших великих центара података који се проширује. Ово је у току, изгледаће лепше, боље ће се попуњавати.

Важно питање: изабрали смо логичку топологију и изградили физику. Шта ће се десити са контролним авионом? Прилично је познато из оперативног искуства, постоји велики број извештаја да су протоколи стања везе добри, задовољство је радити са њима, али, нажалост, они нису добро скалирани на густо повезаној топологији. И постоји један главни фактор који то спречава - овако функционише флоодинг у протоколима стања везе. Ако само узмете алгоритам поплаве и погледате како је наша мрежа структурисана, можете видети да ће на сваком кораку бити веома велики фаноут и једноставно ће преплавити контролни ниво ажурирањима. Конкретно, такве топологије се веома лоше мешају са традиционалним алгоритмом поплаве у протоколима стања везе.

Избор је да користите БГП. Како га правилно припремити описано је у РФЦ 7938 о употреби БГП-а у великим центрима података. Основне идеје су једноставне: минималан број префикса по хосту и генерално минималан број префикса на мрежи, користити агрегацију ако је могуће и потиснути тражење путања. Желимо веома пажљиву, веома контролисану дистрибуцију ажурирања, оно што се назива без долине. Желимо да се ажурирања примењују тачно једном када прођу кроз мрежу. Ако потичу од дна, иду горе, не одвијајући се више од једном. Не би требало бити зигзагова. Зигзагови су веома лоши.

Да бисмо то урадили, користимо дизајн који је довољно једноставан да користи основне БГП механизме. То јест, користимо еБГП који ради на локалној вези, а аутономни системи се додељују на следећи начин: аутономни систем на ТоР, аутономни систем на целом блоку спине-1 прекидача једног Пода и општи аутономни систем на целом врху оф Фабриц. Није тешко погледати и видети да нам чак и нормално понашање БГП-а даје дистрибуцију ажурирања коју желимо.

Наравно, адресирање и агрегација адреса морају бити дизајнирани тако да буду компатибилни са начином на који је рутирање изграђено, тако да осигурава стабилност контролне равни. Л3 адресирање у транспорту је везано за топологију, јер без тога је немогуће постићи агрегацију; без тога ће се појединачне адресе увући у систем рутирања. И још једна ствар је да се агрегација, нажалост, не меша баш најбоље са вишеструким, јер када имамо више пута и имамо агрегацију, све је у реду, када је цела мрежа здрава, у њој нема кварова. Нажалост, чим се појаве кварови у мрежи и изгуби се симетрија топологије, можемо доћи до тачке са које је јединица најављена, са које не можемо ићи даље тамо где треба. Због тога је најбоље агрегирати тамо где нема даљег вишеструког пута, у нашем случају то су ТоР прекидачи.

У ствари, могуће је агрегирати, али пажљиво. Ако можемо да урадимо контролисану дезагрегацију када дође до кварова на мрежи. Али ово је прилично тежак задатак, чак смо се питали да ли би то било могуће урадити, да ли је могуће додати додатну аутоматизацију и коначне аутомате који би исправно избацили БГП да би добили жељено понашање. Нажалост, обрада кутних кућишта је веома неочигледна и сложена, а овај задатак није добро решен причвршћивањем екстерних прилога на БГП.

У оквиру РИФТ протокола урађен је веома интересантан посао у овом погледу, о чему ће бити речи у наредном извештају.

Још једна важна ствар је како се равни података скалирају у густим топологијама, где имамо велики број алтернативних путања. У овом случају се користи неколико додатних структура података: ЕЦМП групе, које заузврат описују Нект Хоп групе.

У мрежи која нормално ради, без кварова, када идемо горе по Цлос топологији, довољно је да користимо само једну групу, јер све што није локално је описано подразумевано, можемо ићи горе. Када идемо од врха до дна на југ, онда све путање нису ЕЦМП, оне су једноструке путање. Све је у реду. Проблем је, а посебност класичне Цлос топологије је у томе што ако погледамо врх тканине, било који елемент, постоји само један пут до било ког елемента испод. Ако дође до кварова на овој путањи, онда овај одређени елемент на врху фабрике постаје неважећи управо за оне префиксе који се налазе иза прекинуте путање. Али за остало важи, и морамо да анализирамо ЕЦМП групе и уведемо ново стање.

Како изгледа скалабилност у равни података на савременим уређајима? Ако урадимо ЛПМ (најдуже подударање префикса), све је сасвим добро, преко 100к префикса. Ако говоримо о Нект Хоп групама, онда је све горе, 2-4 хиљаде. Ако говоримо о табели која садржи опис Нект Хопс-а (или суседности), онда је то негде од 16к до 64к. И ово може постати проблем. И ту долазимо до занимљиве дигресије: шта се десило са МПЛС-ом у центрима података? У принципу, желели смо то да урадимо.

Десиле су се две ствари. Урадили смо микро-сегментацију на хостовима; више нисмо морали да то радимо на мрежи. Није било добро са подршком различитих произвођача, а још више са отвореним имплементацијама на белим кутијама са МПЛС-ом. А МПЛС, барем његове традиционалне имплементације, нажалост, веома се лоше комбинује са ЕЦМП-ом. И зато.

Овако изгледа ЕЦМП структура прослеђивања за ИП. Велики број префикса може да користи исту групу и исти блок Нект Хопс (или суседности, ово се може другачије звати у различитој документацији за различите уређаје). Поента је да се ово описује као одлазни порт и на шта треба преписати МАЦ адресу да би се дошло до исправног Нект Хоп-а. За ИП све изгледа једноставно, можете користити веома велики број префикса за исту групу, исти блок Нект Хопс.

Класична МПЛС архитектура подразумева да, у зависности од излазног интерфејса, ознака може бити преписана на различите вредности. Због тога морамо да задржимо групу и блок Нект Хопс за сваку улазну ознаку. А ово, нажалост, нема размере.

Лако је видети да нам је у нашем дизајну било потребно око 4000 ТоР прекидача, максимална ширина је била 64 ЕЦМП путање, ако се удаљимо од кичме-1 ка кичми-2. Једва улазимо у једну табелу ЕЦМП група, ако нестане само један префикс са ТоР, а уопште не уђемо у табелу Нект Хопс.

Није све безнадежно, јер архитектуре као што је рутирање сегмената укључују глобалне ознаке. Формално, било би могуће поново срушити све ове блокове Нект Хопс. Да бисте то урадили, потребна вам је операција типа џокера: узмите ознаку и препишите је на исту без одређене вредности. Али, нажалост, ово није много присутно у доступним имплементацијама.

И на крају, потребно је да доведемо спољни саобраћај у центар података. Како се то ради? Раније је саобраћај у Цлос мрежу уведен одозго. То јест, постојали су ивични рутери који су се повезивали са свим уређајима на врху тканине. Ово решење ради прилично добро на малим и средњим величинама. Нажалост, да бисмо на овај начин симетрично слали саобраћај на целу мрежу, потребно је да истовремено дођемо до свих елемената Топ тканине, а када их има више од сто, испоставља се да нам је потребан и велики радик на ивичним рутерима. Генерално, ово кошта, јер су ивични рутери функционалнији, портови на њима ће бити скупљи, а дизајн није баш леп.

Друга опција је покретање таквог саобраћаја одоздо. Лако је проверити да је Цлос топологија изграђена на такав начин да је саобраћај који долази одоздо, односно са стране ТоР, равномерно распоређен међу нивоима кроз цео Врх тканине у две итерације, учитавајући целу мрежу. Стога уводимо посебан тип Под-а, Едге Под, који обезбеђује екстерно повезивање.

Постоји још једна опција. То, на пример, ради Фејсбук. Зову га Фабриц Аггрегатор или ХГРИД. Уводи се додатни ниво кичме за повезивање више центара података. Овај дизајн је могућ ако немамо додатне функције или промене енкапсулације на интерфејсима. Ако су то додатне додирне тачке, тешко је. Обично постоји више функција и нека врста мембране која раздваја различите делове центра података. Нема смисла правити такву мембрану великом, али ако је из неког разлога заиста потребна, онда има смисла размотрити могућност њеног одузимања, што је могуће шире и преношења на домаћине. То раде, на пример, многи оператери у облаку. Имају преклапања, крећу од домаћина.

Какве развојне могућности видимо? Пре свега, побољшање подршке за ЦИ/ЦД цевовод. Желимо да летимо на начин на који тестирамо и тестирамо начин на који летимо. Ово не функционише баш најбоље, јер је инфраструктура велика и немогуће је дуплирати за тестове. Морате да разумете како да уведете елементе тестирања у производну инфраструктуру, а да их не испустите.

Боља инструментација и бољи надзор скоро никада нису сувишни. Цело питање је баланс напора и повратка. Ако можете да га додате уз разуман труд, врло добро.

Отворени оперативни системи за мрежне уређаје. Бољи протоколи и бољи системи рутирања, као што је РИФТ. Такође је потребно истраживање коришћења бољих шема за контролу загушења и можда увођење, барем у неким тачкама, РДМА подршке унутар кластера.

Гледајући даље у будућност, потребне су нам напредне топологије и могуће мреже које користе мање трошкове. Од свежих ствари, недавно су биле публикације о технологији тканине за ХПЦ Цраи Слингсхот, која је заснована на робном Етхернету, али са могућношћу коришћења много краћих заглавља. Као резултат тога, режијски трошкови су смањени.

Све треба да буде што једноставније, али не једноставније. Сложеност је непријатељ скалабилности. Једноставност и правилне структуре су наши пријатељи. Ако можете негде да скалирате, урадите то. И уопште, сјајно је сада бити укључен у мрежне технологије. Много се занимљивих ствари дешава. Хвала вам.

Извор: ввв.хабр.цом