Савремени дата центри имају стотине инсталираних активних уређаја, покривених различитим врстама надзора. Али чак и идеалан инжењер са савршеним надзором у руци ће моћи исправно да одговори на квар мреже за само неколико минута. У извештају на конференцији Нект Хоп 2020, представио сам методологију пројектовања мреже центара података, која има јединствену карактеристику – центар података се самоизлечи у милисекундама. Тачније, инжењер мирно решава проблем, док га сервиси једноставно не примећују.
За многе мрежне инжењере, мрежа центара података почиње, наравно, са ТоР-ом, са прекидачем у сталку. ТоР обично има две врсте веза. Мали иду на сервере, други - има их Н пута више - иду ка кичми првог нивоа, односно ка његовим узлазним везама. Уплинкови се обично сматрају једнаким, а саобраћај између узлазних веза је уравнотежен на основу хеша од 5-торке, што укључује прото, срц_ип, дст_ип, срц_порт, дст_порт. Овде нема изненађења.
Затим, како изгледа архитектура плана? Кичме првог нивоа нису међусобно повезане, већ су повезане преко суперспина. Слово Кс ће бити одговорно за суперспине; скоро је као унакрсна веза.
И јасно је да су, с друге стране, тори повезани са свим кичмама првог нивоа. Шта је важно на овој слици? Ако имамо интеракцију унутар сталка, онда интеракција, наравно, иде кроз ТоР. Ако се интеракција дешава унутар модула, онда се интеракција дешава кроз кичме првог нивоа. Ако је интеракција интермодуларна – као овде, ТоР 1 и ТоР 2 – онда ће интеракција ићи кроз кичме и првог и другог нивоа.
У теорији, таква архитектура је лако скалабилна. Ако имамо капацитет порта, слободан простор у дата центру и унапред постављено влакно, онда се број трака увек може повећати, чиме се повећава укупан капацитет система. Ово је врло лако урадити на папиру. У животу би било овако. Али данашња прича није о томе.
Желим да се донесу прави закључци. Имамо много путева унутар центра података. Они су условно независни. Једна путања унутар центра података је могућа само унутар ТоР-а. Унутар модула имамо број стаза једнак броју трака. Број путања између модула једнак је производу броја равни и броја суперспина у свакој равни. Да би било јасније, да бих стекао осећај размере, даћу бројеве који важе за један од центара података Иандек.
Има осам авиона, сваки авион има 32 суперспина. Као резултат тога, испоставља се да постоји осам путања унутар модула, а са интермодулном интеракцијом већ их има 256.
Односно, ако развијамо Цоокбоок, покушавајући да научимо како да изградимо центре података отпорне на грешке који сами себе лече, онда је планарна архитектура прави избор. Решава проблем скалирања, а у теорији је то лако. Постоји много независних путева. Остаје питање: како таква архитектура преживљава неуспехе? Има разних неуспеха. И о томе ћемо сада разговарати.
Нека нам се "разболи" једна од наших суперкичми. Овде сам се вратио на двопланску архитектуру. Задржаћемо се ових као примера јер ће једноставно бити лакше видети шта се дешава са мање покретних делова. Нека се Кс11 разболи. Како ће то утицати на услуге које живе унутар центара података? Много зависи од тога како неуспех заправо изгледа.
Ако је квар добар, ухваћен је на нивоу аутоматизације истог БФД-а, аутоматизација срећно поставља проблематичне спојеве и изолује проблем, онда је све у реду. Имамо много путева, саобраћај се тренутно преусмерава на алтернативне правце, а службе неће ништа приметити. Ово је добар сценарио.
Лош сценарио је ако имамо сталне губитке, а аутоматика не примети проблем. Да бисмо разумели како ово утиче на апликацију, мораћемо да проведемо мало времена разговарајући о томе како ТЦП функционише.
Надам се да нећу никога шокирати овом информацијом: ТЦП је протокол за потврду преноса. То јест, у најједноставнијем случају, пошиљалац шаље два пакета и добија кумулативни ацк на њих: „Примио сам два пакета.
Након тога ће послати још два пакета и ситуација ће се поновити. Унапред се извињавам за мало поједностављења. Овај сценарио је исправан ако је прозор (број пакета у лету) два. Наравно, у општем случају то није нужно случај. Али величина прозора не утиче на контекст прослеђивања пакета.
Шта се дешава ако изгубимо пакет 3? У овом случају, прималац ће примити пакете 1, 2 и 4. И он ће експлицитно рећи пошиљаоцу користећи опцију САЦК: „Знате, стигла су три, али је средина изгубљена.“ Он каже, "Ацк 2, САЦК 4."
У овом тренутку пошиљалац без икаквих проблема понавља тачно изгубљени пакет.
Али ако се изгуби последњи пакет у прозору, ситуација ће изгледати потпуно другачије.
Прималац прима прва три пакета и пре свега почиње да чека. Захваљујући неким оптимизацијама у ТЦП стеку Линук кернела, он ће чекати на упарени пакет осим ако заставице експлицитно не указују да је то последњи пакет или нешто слично. Сачекаће док временско ограничење одложеног АЦК-а не истекне, а затим ће послати потврду за прва три пакета. Али сада ће пошиљалац чекати. Не зна да ли је четврти пакет изгубљен или ће ускоро стићи. А да не би преоптеретио мрежу, покушаће да сачека експлицитну индикацију да је пакет изгубљен, или да истекне РТО тимеоут.
Шта је РТО тимеоут? Ово је максимум РТТ израчунат ТЦП стеком и нека константа. Каква је то константа, сада ћемо разговарати.
Али важно је да ако поново немамо среће и поново изгубимо четврти пакет, онда се РТО удвостручује. То јест, сваки неуспешан покушај значи удвостручавање временског ограничења.
Сада да видимо чему је ова база једнака. Подразумевано, минимални РТО је 200 мс. Ово је минимални РТО за пакете података. За СИН пакете је другачије, 1 секунда. Као што видите, чак и први покушај поновног слања пакета ће трајати 100 пута дуже од РТТ-а унутар центра података.
Сада да се вратимо на наш сценарио. Шта се дешава са услугом? Услуга почиње да губи пакете. Нека услуга у почетку буде условно срећна и изгуби нешто на средини прозора, затим добије САЦК и поново пошаље изгубљене пакете.
Али ако се лоша срећа понови, онда имамо РТО. Шта је овде важно? Да, имамо много путева у нашој мрежи. Али ТЦП саобраћај једне одређене ТЦП везе ће наставити да пролази кроз исти прекинути стек. Губици пакета, под условом да се овај наш магични Кс11 не угаси сам, не доводе до одлива саобраћаја у подручја која нису проблематична. Покушавамо да испоручимо пакет кроз исти сломљени стек. Ово доводи до каскадне грешке: центар података је скуп апликација које су у интеракцији, а неке од ТЦП веза свих ових апликација почињу да деградирају – јер суперспине утиче на све апликације које постоје унутар центра података. Како се каже: ако коња ниси потковао, коњ је хром; коњ је хром – извештај није достављен; извештај није достављен – изгубили смо рат. Само овде се рачуна у секундама од тренутка када се проблем појави до фазе деградације коју услуге почињу да осећају. То значи да корисници можда нешто пропуштају негде.
Постоје два класична решења која се допуњују. Први су сервиси који покушавају да ставе сламке и реше проблем овако: „Хајде да подесимо нешто у ТЦП стеку. Хајде да направимо тајм-ауте на нивоу апликације или дуготрајне ТЦП сесије са интерним здравственим проверама." Проблем је у томе што таква решења: а) уопште немају размере; б) веома су слабо проверени. То јест, чак и ако услуга случајно конфигурише ТЦП стек на начин који га чини бољим, прво, мало је вероватно да ће бити применљив на све апликације и све центре података, а друго, највероватније, неће разумети да је то учињено исправно, а шта не. То јест, ради, али ради лоше и не расте. А ако постоји проблем са мрежом, ко је крив? Наравно, НОЦ. Шта НОЦ ради?
Многе службе верују да се у раду НОК-а дешава овако нешто. Али да будем искрен, не само то.
НОЦ се у класичној шеми бави развојем многих система за праћење. То су и надзор црне кутије и беле кутије. О примеру праћења кичме црне кутије Александар Клименко на последњем Нект Хоп-у. Иначе, овај мониторинг функционише. Али чак и идеално праћење ће имати временско кашњење. Обично је ово неколико минута. Након што се угаси, дежурним инжењерима је потребно време да још једном провере његов рад, локализују проблем и затим угасе проблематичну област. Односно, у најбољем случају, лечење проблема траје 5 минута, у најгорем 20 минута, ако није одмах видљиво где настају губици. Јасно је да ће све ово време – 5 или 20 минута – наше услуге и даље трпети, што вероватно није добро.
Шта бисте заиста желели да добијете? Имамо толико начина. А проблеми настају управо зато што ТЦП токови који немају среће настављају да користе исту руту. Треба нам нешто што ће нам омогућити да користимо више рута унутар једне ТЦП везе. Чини се да имамо решење. Постоји ТЦП, који се назива мултипатх ТЦП, односно ТЦП за више путања. Истина, развијен је за потпуно другачији задатак - за паметне телефоне који имају неколико мрежних уређаја. Да би се максимизирао трансфер или направио примарни/резервни режим, развијен је механизам који креира више нити (сесија) транспарентно за апликацију и омогућава вам да прелазите између њих у случају квара. Или, као што сам рекао, максимизирајте низ.
Али овде постоји нијанса. Да бисмо разумели шта је то, мораћемо да погледамо како се успостављају нити.
Нити се инсталирају узастопно. Прва нит се инсталира прва. Наредне нити се затим постављају помоћу колачића који је већ договорен унутар те нити. И овде је проблем.
Проблем је у томе што ако се прва нит не успостави, друга и трећа нит никада неће настати. То јест, мултипатх ТЦП не решава губитак СИН пакета у првом току. А ако се СИН изгуби, мултипатх ТЦП се претвара у обичан ТЦП. То значи да нам у окружењу дата центра неће помоћи да решимо проблем губитака у фабрици и научимо да користимо више путања у случају квара.
Шта нам може помоћи? Неки од вас су већ из наслова погодили да ће важно поље у нашој даљој причи бити поље заглавља ознаке ИПв6 тока. Заиста, ово је поље које се појављује у в6, није га у в4, заузима 20 бита, а већ дуже време постоје контроверзе око његове употребе. Ово је веома интересантно – било је спорова, нешто је поправљено унутар РФЦ-а, а истовремено се појавила имплементација у језгру Линука, која нигде није документована.
Позивам вас да пођете са мном у малу истрагу. Хајде да погледамо шта се дешавало у Линук кернелу у последњих неколико година.
године 2014. Инжењер из једне велике и угледне компаније додаје функционалности Линук кернела зависност вредности ознаке тока од хеша утичнице. Шта су покушавали да поправе овде? Ово се односи на РФЦ 6438, који је разматрао следеће питање. Унутар центра података, ИПв4 је често инкапсулиран у ИПв6 пакете, јер је сама фабрика ИПв6, али ИПв4 се некако мора дати споља. Дуго су постојали проблеми са прекидачима који нису могли да погледају испод два ИП заглавља да би дошли до ТЦП или УДП и тамо пронашли срц_портс, дст_портс. Испоставило се да је хеш, ако погледате прва два ИП заглавља, испао скоро фиксиран. Да би се ово избегло, како би балансирање овог инкапсулираног саобраћаја функционисало исправно, предложено је да се дода хеш инкапсулираног пакета од 5 тупле у вредност поља ознаке тока. Приближно иста ствар је урађена за друге шеме енкапсулације, за УДП, за ГРЕ, овај други је користио поље ГРЕ Кеи. На овај или онај начин, циљеви су овде јасни. И барем су у том тренутку били корисни.
У 2015, нова закрпа долази од истог цењеног инжењера. Он је веома интересантан. Пише следеће - насумично ћемо рашчланити хеш у случају негативног рутирања. Шта је негативни догађај рутирања? Ово је РТО о којем смо раније говорили, односно губитак репа прозора је догађај који је заиста негативан. Истина, релативно је тешко претпоставити да је то то.
2016, друга реномирана компанија, такође велика. Раставља последње штаке и чини тако да се хеш, који смо претходно направили насумично, сада мења за сваки СИН ретрансмисију и после сваког РТО тимеоут-а. И у овом писму се по први и последњи пут наводи крајњи циљ – да се обезбеди да саобраћај у случају губитака или загушења канала има могућност да се меко преусмери и користи више путања. Наравно, након овога било је много публикација, лако их можете пронаћи.
Иако не, не можете, јер није било ниједне публикације на ову тему. Али знамо!
А ако не разумете у потпуности шта је урађено, сада ћу вам рећи.
Шта је урађено, која функционалност је додата Линук кернелу? ткхасх се мења у насумичну вредност након сваког РТО догађаја. Ово је веома негативан резултат рутирања. Хеш зависи од овог ткхасх-а, а ознака тока зависи од скб хеша. Овде постоје неке калкулације функција; сви детаљи се не могу ставити на један слајд. Ако је неко радознао, можете проћи кроз код кернела и проверити.
Шта је овде важно? Вредност поља ознаке тока се мења у насумични број након сваког РТО. Како ово утиче на наш несрећни ТЦП ток?
Ако дође до САЦК, ништа се не мења јер покушавамо поново да пошаљемо познати изгубљени пакет. Засада је добро.
Али у случају РТО-а, под условом да смо додали ознаку тока хеш функцији на ТоР-у, саобраћај може да иде другом рутом. И што је више трака, већа је шанса да ће пронаћи путању на коју не утиче квар на одређеном уређају.
Остаје један проблем - РТО. Наравно, постоји и друга рута, али се на ово губи много времена. 200 мс је много. Секунда је потпуно дивља. Раније сам говорио о временским ограничењима за које су услуге конфигурисане. Дакле, секунда је временско ограничење, које обично конфигурише услуга на нивоу апликације, а у овом случају услуга ће чак бити релативно тачна. Штавише, понављам, прави РТТ унутар модерног дата центра је око 1 милисекунде.
Шта можете да урадите са РТО тимеоут-има? Тајмаут, који је одговоран за РТО у случају губитка пакета података, може се релативно лако конфигурисати из корисничког простора: постоји ИП услужни програм, а један од његових параметара садржи исти рто_мин. С обзиром на то да РТО, наравно, треба да се прилагоди не глобално, већ за дате префиксе, такав механизам изгледа сасвим изводљив.
Истина, са СИН_РТО је све нешто горе. Природно је приковано. Кернел има фиксну вредност од 1 секунде, и то је то. Не можете доћи тамо из корисничког простора. Постоји само један начин.
еБПФ долази у помоћ. Поједностављено речено, ово су мали Ц програми. Могу се убацити у куке на различитим местима у извршавању стека кернела и ТЦП стека, помоћу којих можете променити веома велики број подешавања. Генерално, еБПФ је дугорочни тренд. Уместо смањења десетина нових сисцтл параметара и проширења ИП услужног програма, кретање се креће ка еБПФ-у и проширује његову функционалност. Користећи еБПФ, можете динамички мењати контроле загушења и разне друге ТЦП поставке.
Али за нас је важно да се може користити за промену вредности СИН_РТО. Штавише, постоји јавно објављен пример: . Шта је овде урађено? Пример је ефикасан, али је сам по себи веома груб. Овде се претпоставља да унутар центра података упоређујемо прва 44 бита; ако се поклапају, онда смо унутар центра података. И у овом случају мењамо вредност временског ограничења СИН_РТО на 4мс. Исти задатак се може урадити много елегантније. Али овај једноставан пример показује да је то а) могуће; б) релативно једноставно.
Шта већ знамо? Чињеница да раван архитектура дозвољава скалирање, испоставило се да је изузетно корисна за нас када омогућимо ознаку тока на ТоР-у и добијемо могућност протока око проблематичних области. Најбољи начин да смањите вредности РТО и СИН-РТО је коришћење еБПФ програма. Остаје питање: да ли је безбедно користити ознаку тока за балансирање? И овде постоји нијанса.
Претпоставимо да имате услугу на вашој мрежи која живи у аницаст-у. Нажалост, немам времена да улазим у детаље шта је аницаст, али то је дистрибуирана услуга са различитим физичким серверима доступним преко исте ИП адресе. И ево могућег проблема: РТО догађај се може догодити не само када саобраћај пролази кроз ткиво. Такође се може десити на нивоу бафера ТоР: када дође до инцаст догађаја, може се десити чак и на хосту када хост проспе нешто. Када дође до РТО догађаја и промени ознаку тока. У овом случају, саобраћај може да иде на другу инстанцу аницаст. Претпоставимо да је ово било какво пребацивање са стањем, садржи стање везе - то може бити Л3 Баланцер или нека друга услуга. Тада настаје проблем, јер након РТО ТЦП конекција стиже на сервер, који не зна ништа о овој ТЦП вези. А ако немамо дељење стања између аницаст сервера, онда ће такав саобраћај бити одбачен и ТЦП веза ће бити прекинута.
Шта можеш да урадиш овде? У оквиру вашег контролисаног окружења, где омогућавате балансирање ознака тока, потребно је да забележите вредност ознаке тока када приступате серверима било каквог преноса. Најлакши начин је да то урадите кроз исти еБПФ програм. Али ево једне веома важне тачке – шта да радите ако не управљате мрежом дата центара, али сте телеком оператер? Ово је и ваш проблем: почевши од одређених верзија Јунипера и Аристе, они подразумевано укључују ознаку тока у своје хеш функције - искрено, из разлога који ми није јасан. Ово може проузроковати да прекинете ТЦП везе од корисника који пролазе кроз вашу мрежу. Зато препоручујем да овде проверите подешавања рутера.
На овај или онај начин, чини ми се да смо спремни да пређемо на експерименте.
Када смо омогућили ознаку тока на ТоР-у, припремили еБПФ агент, који сада живи на хостовима, одлучили смо да не чекамо следећи велики квар, већ да спроведемо контролисане експлозије. Узели смо ТоР, који има четири уплинк-а, и поставили дроп-ове на једном од њих. Извукли су правило и рекли - сада губите све пакете. Као што видите на левој страни, имамо надзор по пакету, који је пао на 75%, односно 25% пакета је изгубљено. На десној страни су графикони служби које живе иза овог ТоР. У суштини, ово су графови саобраћаја интерфејса са серверима унутар рацк-а. Као што видите, потонули су још ниже. Зашто су пали ниже - не за 25%, већ у неким случајевима и 3-4 пута? Ако ТЦП веза није срећна, она наставља да покушава да допре до поквареног споја. Ово је погоршано типичним понашањем услуге унутар ДЦ-а – за један кориснички захтев се генерише Н захтева ка интерним услугама, а одговор ће ићи кориснику или када сви извори података одговоре, или када дође до истека времена у апликацији ниво, који тек треба да се конфигурише. То јест, све је веома, веома лоше.
Сада исти експеримент, али са омогућеном вредношћу ознаке тока. Као што видите, са леве стране наш надзор серије је опао за истих 25%. Ово је апсолутно тачно, јер не зна ништа о ретрансмитима, шаље пакете и једноставно броји однос броја испоручених и изгубљених пакета.
А са десне стране је распоред сервиса. Овде нећете наћи ефекат проблематичног зглоба. У тим истим милисекундама, саобраћај је текао од проблематичне области до три преостале узлазне везе на које проблем није утицао. Имамо мрежу која лечи сама себе.
Ово је мој последњи слајд, време је да сумирам. Сада се надам да знате како да изградите мрежу центара података који се самоизлечу. Нећете морати да пролазите кроз архиву Линук кернела и да тамо тражите посебне закрпе; знате да ознака Флов у овом случају решава проблем, али морате пажљиво приступити овом механизму. И још једном наглашавам да ако сте телеком оператер, не би требало да користите ознаку тока као хеш функцију, иначе ћете пореметити сесије својих корисника.
Мрежни инжењери морају да прођу кроз концептуалну промену: мрежа почиње не са ТоР-ом, не са мрежним уређајем, већ са хостом. Прилично упечатљив пример је како користимо еБПФ и да променимо РТО и да поправимо ознаку тока ка услугама било каквог преноса.
Механика ознака протока је свакако погодна за друге примене у контролисаном административном сегменту. То може бити саобраћај између центара података, или можете користити такву механику на посебан начин за управљање одлазним саобраћајем. Али о томе ћу вам, надам се, рећи следећи пут. Много вам хвала на пажњи.
Извор: ввв.хабр.цом