Мрежа, която се лекува сама: магията на Flow Label и детективът около ядрото на Linux. Доклад на Yandex

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

- Като начало ще дам доста подробно въведение за тези, които може би не са наясно със структурата на съвременния DC.


За много мрежови инженери мрежата на центъра за данни започва, разбира се, с ToR, с превключвател в шкафа. ToR обикновено има два вида връзки. Малките отиват към сървърите, други - те са N пъти повече - отиват към шиповете на първо ниво, тоест към неговите ъплинкове. Връзките нагоре обикновено се считат за равни и трафикът между връзките нагоре се балансира на базата на хеша от 5 кортежа, който включва proto, src_ip, dst_ip, src_port, dst_port. Тук няма изненади.


След това, как изглежда архитектурата на самолетите? Шиповете от първо ниво не са свързани помежду си, а са свързани посредством суперспини. Буквата X ще отговаря за суперзавъртанията, това е почти като кръстосана връзка.


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


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


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


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

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


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


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


Лош сценарий е, ако имаме постоянни загуби, а автоматиката не забелязва проблема. За да разберем как това се отразява на приложението, ще трябва да отделим малко време за обсъждане на това как работи TCP протоколът.


Надявам се да не шокирам никого с тази информация: TCP е протокол за ръкостискане. Тоест в най-простия случай подателят изпраща два пакета и получава кумулативно потвърждение за тях: „Получих два пакета“.


След това той ще изпрати още два пакета и ситуацията ще се повтори. Предварително се извинявам за известно опростяване. Този сценарий е правилен, ако прозорецът (брой пакети в полет) е два. Разбира се, това не е задължително да е така като цяло. Но контекстът на препращане на пакети не се влияе от размера на прозореца.


Какво ще стане, ако загубим пакет 3? В този случай получателят ще получи пакети 1, 2 и 4. И той изрично ще информира изпращача чрез опцията SACK: „Знаеш ли, дойдоха три, но средният беше изгубен.“ Той казва "Ack 2, SACK 4".


Подателят в този момент повтаря точно пакета, който е бил изгубен без никакви проблеми.


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

Получателят получава първите три пакета и първо започва да чака. Благодарение на някои оптимизации в TCP стека на Linux ядрото, той ще изчака сдвоен пакет, освен ако няма изрична индикация във флаговете, че това е последният пакет или нещо подобно. Той ще изчака, докато изтече времето за изчакване на отложеното ACK и след това ще изпрати потвърждение за първите три пакета. Но сега изпращачът ще чака. Не знае дали четвъртият пакет е изгубен или предстои да пристигне. И за да не претоварва мрежата, тя ще се опита да изчака изричната индикация, че пакетът е загубен или изтичането на времето за изчакване на RTO.


Какво е RTO таймаут? Това е максимумът от RTT, изчислен от TCP стека и някаква константа. Каква е тази константа, сега ще обсъдим.


Но е важно, че ако отново нямаме късмет и четвъртият пакет отново се загуби, тогава RTO се удвоява. Тоест всеки неуспешен опит е удвояване на таймаута.


Сега нека видим на какво е равна тази основа. По подразбиране минималният RTO е 200 ms. Това е минималният RTO за пакети с данни. За SYN пакетите е различно, 1 секунда. Както можете да видите, дори първият опит за повторно изпращане на пакети ще отнеме 100 пъти повече от RTT в центъра за данни.


Сега обратно към нашия сценарий. Какво става с услугата? Услугата започва да губи пакети. Нека услугата първоначално има късмет и загуби нещо в средата на прозореца, след това получава SACK, изпраща повторно изгубените пакети.


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


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

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


NOC в класическата схема се занимава с разработването на много мониторинг. Това са както мониторинг на черна кутия, така и мониторинг на бяла кутия. За примера на черна кутия - мониторинг на шипове казал Александър Клименко за миналото Next Hop. Между другото, този мониторинг работи. Но дори перфектното наблюдение ще има забавяне във времето. Обикновено са няколко минути. След като работи, дежурните инженери се нуждаят от време, за да проверят отново работата му, да локализират проблема и след това да потушат проблемната зона. Тоест в най-добрия случай третирането на проблема отнема 5 минути, в най-лошия 20 минути, ако не се вижда веднага къде са загубите. Ясно е, че през цялото това време - 5 или 20 минути - нашите услуги ще продължат да болят, което вероятно не е добре.


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

Но тук има един нюанс. За да разберем какво представлява, ще трябва да разгледаме как са настроени потоците.


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


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


Какво може да ни помогне? Някои от вас вече се досетиха от името, че важното поле в нашата по-нататъшна история ще бъде полето за заглавка на етикета на IPv6 потока. Наистина, това е поле, което се появява във v6, не е във v4, отнема 20 бита и има спорове относно използването му от дълго време. Това е много интересно - имаше спорове, нещо беше коригирано в рамките на RFC и в същото време се появи внедряване в ядрото на Linux, което никога не беше документирано никъде.


Предлагам ви да се присъедините към мен в малко разследване. Нека да разгледаме какво се случва в ядрото на Linux през последните няколко години.

2014 година. Инженер от голяма и реномирана компания добавя към функционалността на Linux ядрото зависимостта на стойността на етикета на потока от хеша на сокета. Какво се опитват да поправят тук? Това е свързано с RFC 6438, който обсъжда следния проблем. Вътре в центъра за данни IPv4 често е капсулиран в IPv6 пакети, тъй като самата фабрика е IPv6, но IPv4 трябва по някакъв начин да бъде раздаден. Дълго време имаше проблеми с превключватели, които не можеха да погледнат под две IP заглавки, за да стигнат до TCP или UDP и да намерят src_ports, dst_ports там. Оказа се, че хешът, ако погледнете първите два IP хедъра, се оказа почти фиксиран. За да се избегне това, така че балансирането на този капсулиран трафик да работи правилно, беше предложено да се добави хеш от 5-кортежния капсулиран пакет към стойността на полето за етикет на потока. Приблизително същото беше направено за други схеми на капсулиране, за UDP, за GRE, като в последното беше използвано полето GRE Key. По един или друг начин целите тук са ясни. И поне в този момент те бяха полезни.

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

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

Въпреки че не, не можете, защото няма нито една публикация по тази тема. Но ние знаем!

И ако не разбирате напълно какво е направено, сега ще ви кажа.


Какво е направено, каква функционалност е добавена към ядрото на Linux? txhash се променя на произволна стойност след всяко RTO събитие. Това е същият отрицателен резултат от маршрутизирането. Хешът зависи от този txhash, а етикетът на потока зависи от skb хеша. Тук има някои изчисления на функциите, всички подробности не могат да бъдат поставени на един слайд. Ако някой е любопитен, може да прегледа кода на ядрото и да провери.

Кое е важното тук? Стойността на полето за етикет на потока се променя на произволно число след всеки RTO. Как това се отразява на нашия нещастен TCP поток?


В случай на SACK нищо не се е променило, защото се опитваме да изпратим отново известен загубен пакет. Дотук добре.


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


Остава един проблем - RTO. Друг маршрут, разбира се, се намира, но за него се отделя много време. 200ms са много. Втората като цяло е дивотия. По-рано говорих за изчакване, което конфигурира услуги. Така че секундата е таймаут, който обикновено настройва услуга на ниво приложение и в това услугата дори ще бъде относително правилна. Освен това, повтарям, реалният RTT в модерен център за данни е около 1 милисекунда.


Какво може да се направи относно изчакванията на RTO? Времето за изчакване, което отговаря за RTO в случай на загуба на пакети с данни, може да бъде сравнително лесно конфигурирано от потребителското пространство: има помощна програма за IP и един от нейните параметри съдържа същия rto_min. Като се има предвид, че, разбира се, трябва да включите RTO не глобално, но за дадени префикси, такъв механизъм изглежда доста работещ.


Вярно е, че с SYN_RTO всичко е малко по-лошо. Естествено е закован. Стойността е фиксирана в ядрото - 1 секунда и това е. Не можете да го достигнете от потребителското пространство. Има само един начин.


eBPF идва на помощ. Казано по-просто, това са малки програми на C. Те могат да бъдат вмъкнати в кукички на различни места в изпълнението на стека на ядрото и стека на TCP, с които можете да промените много голям брой настройки. Като цяло eBPF е дългосрочна тенденция. Вместо да се съкращават десетки нови sysctl параметри и да се разширява IP помощната програма, движението е в посока на eBPF и разширяване на неговата функционалност. С eBPF можете динамично да променяте контролите на задръстванията и различни други TCP настройки.


Но за нас е важно, че с него можете да завъртите стойностите на SYN_RTO. Има и публично публикуван пример: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. Какво се прави тук? Примерът работи, но сам по себе си е много груб. Тук се предполага, че вътре в центъра за данни сравняваме първите 44 бита, ако те съвпадат, тогава се озоваваме вътре в DC. И в този случай ние променяме стойността на времето за изчакване на SYN_RTO на 4ms. Същата задача може да се направи много по-грациозно. Но този прост пример показва какво е а) възможно; б) сравнително лесно.

Какво вече знаем? Това, че равнинната архитектура позволява мащабиране, се оказва изключително полезно за нас, когато включим етикета на потока на ToR и получим възможност да обхождаме проблемните области. Най-добрият начин да намалите стойностите на RTO и SYN-RTO е да използвате eBPF програми. Остава въпросът: безопасно ли е да се използва етикетът на потока за балансиране? И тук има един нюанс.


Да предположим, че имате услуга в мрежата, която живее в anycast. За съжаление нямам време да навлизам в подробности за anycast, но това е разпределена услуга, при която различни физически сървъри са налични на един и същ IP адрес. И тук е възможен проблем: събитието RTO може да възникне не само когато трафикът преминава през фабриката. Може да възникне и на ниво ToR буфер: когато възникне incast събитие, то може да се случи дори на хоста, когато хостът разлее нещо. Когато възникне RTO събитие и то промени етикета на потока. В този случай трафикът може да отиде към друг екземпляр на anycast. Да предположим, че е състояние anycast, то съдържа състояние на връзка - може да бъде L3 Balancer или някаква друга услуга. Тогава възниква проблем, защото след RTO, TCP връзката пристига на сървъра, който не знае нищо за тази TCP връзка. И ако нямаме споделяне на състояние между сървъри за anycast, тогава такъв трафик ще бъде премахнат и TCP връзката ще се прекъсне.


Какво може да се направи тук? В рамките на вашата контролирана среда, където активирате балансирането на етикета на потока, трябва да коригирате стойността на етикета на потока при достъп до сървъри на anycast. Най-лесният начин е да го направите чрез същата програма eBPF. Но тук има един много важен момент - какво да правите, ако не управлявате мрежа от център за данни, а сте телеком оператор? Това е и вашият проблем: започвайки с определени версии на Juniper и Arista, те включват етикета на потока в хеш функцията по подразбиране - честно казано, без причина, която разбирам. Това може да доведе до прекъсване на TCP връзки от потребители, преминаващи през вашата мрежа. Затова силно препоръчвам да проверите настройките на вашия рутер на това място.

По един или друг начин ми се струва, че сме готови да преминем към експерименти.


Когато включихме етикета на потока на ToR, подготвихме eBPF на агента, който сега живее на хостовете, решихме да не чакаме следващия голям провал, а да проведем контролирани експлозии. Взехме ToR, който има четири ъплинка, и направихме пускане на един от тях. Начертаха правило, казаха - сега губите всички пакети. Както можете да видите отляво, имаме мониторинг на пакети, който е спаднал до 75%, тоест 25% от пакетите са загубени. Вдясно са графики на услуги, които стоят зад това ToR. Всъщност това са графики на трафика на стави със сървъри вътре в шкафа. Както виждате, те потънаха още по-ниско. Защо са потънали по-надолу - не с 25%, а в някои случаи 3-4 пъти? Ако TCP връзката е лоша, тя продължава да се опитва да достигне през повредения интерфейс. Това се влошава от типичното поведение на услугата вътре в DC - за една потребителска заявка се генерират N заявки към вътрешни услуги и отговорът ще отиде до потребителя или когато всички източници на данни отговорят, или когато се задейства изчакване нивото на приложението, което все още трябва да бъде конфигурирано. Тоест всичко е много, много лошо.


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

А вдясно е графикът на услугите. Тук няма да намерите ефекта на проблемна става. За същите тези милисекунди трафикът премина от проблемната зона към останалите три връзки нагоре, които не бяха засегнати от проблема. Имаме мрежа, която се лекува сама.

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

За мрежовите инженери трябва да се извърши концептуална промяна: мрежата не започва с ToR, не с мрежово устройство, а с хост. Доста поразителен пример е как използваме eBPF както за промяна на RTO, така и за коригиране на етикета на потока към услугите за всяко предаване.

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

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