Мрежа која се лекува: магијата на Flow Label и детективот околу кернелот Linux. Извештај на Yandex

Современите центри за податоци имаат инсталирани стотици активни уреди, покриени со различни видови на мониторинг. Но, дури и идеален инженер со совршен мониторинг во рака ќе може правилно да одговори на дефект на мрежата за само неколку минути. Во извештајот на конференцијата Next Hop 2020, ја претставив методологијата за дизајн на мрежата на DC, која има единствена карактеристика - центарот за податоци се лекува во милисекунди. Поточно, инженерот мирно го решава проблемот, додека службите едноставно не го забележуваат.

— За почеток, ќе дадам прилично детален вовед за оние кои можеби не се свесни за структурата на модерен DC.


За многу мрежни инженери, мрежата на центарот за податоци започнува, се разбира, со ToR, со прекинувач во решетката. ToR обично има два типа на врски. Малите одат до серверите, други - ги има N пати повеќе - одат кон боцките на првото ниво, односно до неговите нагорни врски. Врските обично се сметаат за еднакви, а сообраќајот помеѓу нагоре линкови е избалансиран врз основа на хаш од 5-tuple, кој вклучува proto, src_ip, dst_ip, src_port, dst_port. Нема изненадувања овде.


Следно, како изгледа архитектурата на планот? Боцките од првото ниво не се поврзани едни со други, туку се поврзани преку супер-боцки. Буквата X ќе биде одговорна за супершипки; таа е речиси како вкрстено поврзување.


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


Во теорија, таквата архитектура е лесно скалабилна. Ако имаме капацитет на пристаниште, резервен простор во центарот за податоци и претходно поставени влакна, тогаш бројот на ленти секогаш може да се зголеми, а со тоа да се зголеми севкупниот капацитет на системот. Ова е многу лесно да се направи на хартија. Така би било во животот. Но, денешната приказна не е за тоа.


Сакам да се донесат вистинските заклучоци. Имаме многу патеки во центарот за податоци. Тие се условно независни. Една патека во центарот за податоци е можна само во ToR. Внатре во модулот, имаме број на патеки еднаков на бројот на ленти. Бројот на патеки помеѓу модулите е еднаков на производот од бројот на рамнини и бројот на супербоди во секоја рамнина. За да биде појасно, за да се добие чувство за скалата, ќе дадам бројки што важат за еден од центрите за податоци на Yandex.


Има осум авиони, секој авион има 32 супер боцки. Како резултат на тоа, излегува дека има осум патеки во модулот, а со интермодулна интеракција веќе има 256 од нив.

Односно, ако развиваме Cookbook, обидувајќи се да научиме како да изградиме центри за податоци толерантни за грешки кои сами се лекуваат, тогаш планарната архитектура е вистинскиот избор. Го решава проблемот со скалирање, а во теорија е лесно. Има многу независни патеки. Останува прашањето: како таквата архитектура ги преживува неуспесите? Има различни неуспеси. И ние ќе разговараме за ова сега.


Нека се „разболи“ еден од нашите суперболести. Тука се вратив на архитектурата со два авиони. Ќе се задржиме на овие како пример бидејќи едноставно ќе биде полесно да се види што се случува со помалку подвижни делови. Нека се разболи Х11. Како ова ќе влијае на услугите што живеат во центрите за податоци? Многу зависи од тоа како всушност изгледа неуспехот.


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


Лошо сценарио е ако имаме постојани загуби, а автоматиката не го забележи проблемот. За да разбереме како ова влијае на апликацијата, ќе треба да потрошиме малку време за да разговараме за тоа како функционира TCP.


Се надевам дека нема да шокирам никого со оваа информација: TCP е протокол за потврда на преносот. Односно, во наједноставниот случај, испраќачот испраќа два пакети и добива кумулативен приказ на нив: „Добив два пакети“.


После тоа, тој ќе испрати уште два пакети, а ситуацијата ќе се повтори. Однапред се извинувам за некое поедноставување. Ова сценарио е точно ако прозорецот (бројот на пакети во лет) е два. Се разбира, во општиот случај тоа не мора да биде случај. Но, големината на прозорецот не влијае на контекстот за препраќање пакети.


Што ќе се случи ако го изгубиме пакетот 3? Во овој случај, примачот ќе ги добие пакетите 1, 2 и 4. И тој експлицитно ќе му каже на испраќачот користејќи ја опцијата SACK: „Знаете, пристигнаа три, но средината беше изгубена“. Тој вели: „Ack 2, SACK 4“.


Во овој момент, испраќачот без никакви проблеми го повторува точно пакетот што бил изгубен.


Но, ако последниот пакет во прозорецот се изгуби, ситуацијата ќе изгледа сосема поинаква.

Примачот ги добива првите три пакети и прво почнува да чека. Благодарение на некои оптимизации во оџакот TCP на кернелот Линукс, тој ќе чека спарен пакет освен ако знаменцата експлицитно не означат дека тоа е последниот пакет или нешто слично. Ќе почека додека не истече времето за одложено ACK и потоа ќе испрати потврда за првите три пакети. Но, сега испраќачот ќе почека. Тој не знае дали четвртиот пакет е изгубен или ќе пристигне. И за да не се преоптоварува мрежата, таа ќе се обиде да чека експлицитна индикација дека пакетот е изгубен или да истече времето на RTO.


Што е истек на RTO? Ова е максимумот на RTT пресметан од оџакот TCP и одредена константа. За каква константа станува збор, сега ќе разговараме.


Но, важно е дека ако повторно немаме среќа и четвртиот пакет повторно се изгуби, тогаш RTO се удвојува. Односно, секој неуспешен обид значи удвојување на тајмаутот.


Сега да видиме на што е еднаква оваа основа. Стандардно, минималниот RTO е 200 ms. Ова е минималниот RTO за пакети со податоци. За SYN пакетите е различно, 1 секунда. Како што можете да видите, дури и првиот обид за повторно испраќање пакети ќе трае 100 пати подолго од RTT во центарот за податоци.


Сега да се вратиме на нашето сценарио. Што се случува со услугата? Услугата почнува да губи пакети. Нека услугата прво има условно среќа и изгуби нешто на средина на прозорецот, потоа добива ВЕСНИЦА и повторно ги испраќа пакетите што се изгубени.


Но, ако лошата среќа се повтори, тогаш имаме RTO. Што е важно тука? Да, имаме многу патеки во нашата мрежа. Но, TCP сообраќајот на една конкретна TCP врска ќе продолжи да поминува низ истиот скршен стек. Загубите на пакети, под услов овој наш магичен X11 да не згасне сам, не доведува до проток на сообраќај во области кои не се проблематични. Се обидуваме да го испорачаме пакетот преку истиот скршен оџак. Ова води до каскаден неуспех: центарот за податоци е збир на апликации кои се во интеракција, а некои од TCP-врските на сите овие апликации почнуваат да се деградираат - бидејќи superspine влијае на сите апликации што постојат во центарот за податоци. Како што вели поговорката: ако не си потковал коњ, коњот куцувал; коњот куцна - извештајот не беше доставен; извештајот не беше доставен - ја изгубивме војната. Само овде броењето е во секунди од моментот кога ќе се појави проблемот до степенот на деградација што службите почнуваат да го чувствуваат. Ова значи дека корисниците можеби пропуштаат нешто некаде.


Постојат две класични решенија кои се надополнуваат. Првиот е сервисите кои се обидуваат да стават сламки и да го решат проблемот вака: „Ајде да дотеруваме нешто во оџакот TCP. Ајде да направиме тајмаути на ниво на апликација или долготрајни TCP сесии со внатрешни здравствени проверки“. Проблемот е што таквите решенија: а) воопшто не се размеруваат; б) се многу слабо проверени. Тоа е, дури и ако услугата случајно го конфигурира оџакот TCP на начин што го прави подобар, прво, мала е веројатноста да биде применлива за сите апликации и сите центри за податоци, и второ, најверојатно, нема да разбере дека е направено правилно, а што уште не. Тоа е, работи, но работи слабо и не скалира. И ако има проблем со мрежата, кој е виновен? Се разбира, НОК. Што прави НОК?

Многу служби веруваат дека во работата на НОК се случува вакво нешто. Но, да бидам искрен, не само тоа.


NOC во класичната шема е ангажирана во развојот на многу системи за следење. Тоа се мониторинг на црната и белата кутија. За пример за следење на 'рбетот на црната кутија изјави Александар Клименко на последниот Next Hop. Патем, овој мониторинг функционира. Но, дури и идеалното следење ќе има временско задоцнување. Обично ова е неколку минути. Откако ќе се исклучи, на дежурните инженери им треба време да ја проверат повторно неговата работа, да го локализираат проблемот и потоа да ја изгаснат проблематичната област. Односно, во најдобар случај, лекувањето на проблемот трае 5 минути, во најлош случај, 20 минути, ако веднаш не е очигледно каде се случуваат загубите. Јасно е дека сето ова време - 5 или 20 минути - нашите услуги ќе продолжат да страдаат, што веројатно не е добро.


Што навистина би сакале да добиете? Имаме толку многу начини. И проблемите се јавуваат токму затоа што тековите на TCP кои немаат среќа продолжуваат да ја користат истата рута. Ни треба нешто што ќе ни овозможи да користиме повеќе правци во рамките на една TCP конекција. Се чини дека имаме решение. Постои TCP, кој се нарекува TCP со повеќе патеки, односно TCP за повеќе патеки. Точно, тој беше развиен за сосема друга задача - за паметни телефони кои имаат неколку мрежни уреди. За да се максимизира преносот или да се направи примарен/резервен режим, беше развиен механизам кој создава повеќе нишки (сесии) транспарентно за апликацијата и ви овозможува да се префрлате помеѓу нив во случај на дефект. Или, како што реков, максимизирајте ја низата.

Но, тука има една нијанса. За да разбереме што е тоа, ќе треба да погледнеме како се воспоставуваат нишки.


Нишките се инсталираат последователно. Првата нишка е инсталирана прво. Последователните нишки потоа се поставуваат со користење на колачето што е веќе договорено во таа нишка. И тука е проблемот.


Проблемот е што ако првата нишка не се воспостави, втората и третата нишка никогаш нема да се појават. Односно, TCP со повеќе патеки не ја решава загубата на SYN пакет во првиот тек. И ако SYN се изгуби, TCP со повеќе патеки се претвора во обичен TCP. Ова значи дека во средина на центарот за податоци нема да ни помогне да го решиме проблемот со загубите во фабриката и да научиме да користиме повеќе патеки во случај на дефект.


Што може да ни помогне? Некои од вас веќе погодија од насловот дека важно поле во нашата понатамошна приказна ќе биде полето за заглавие на етикетата за проток на IPv6. Навистина, ова е поле што се појавува во v6, не е во v4, зафаќа 20 бита, а веќе долго време има контроверзии околу неговата употреба. Ова е многу интересно - имаше спорови, нешто беше поправено во рамките на RFC, а во исто време се појави имплементација во кернелот на Linux, која никаде не беше документирана.


Ве поканувам да одите со мене на мала истрага. Ајде да погледнеме што се случува во кернелот Линукс во изминатите неколку години.

2014 година. Инженер од една голема и почитувана компанија ја додава на функционалноста на кернелот Линукс зависноста на вредноста на ознаката за проток од хашот на сокетот. Што се обидуваа да поправат овде? Ова е поврзано со RFC 6438, кој го дискутираше следново прашање. Внатре во центарот за податоци, IPv4 често е инкапсулиран во IPv6 пакети, бидејќи самата фабрика е IPv6, но IPv4 некако мора да се даде надвор. Долго време имаше проблеми со прекинувачите кои не можеа да изгледаат под два заглавија на IP за да стигнат до TCP или UDP и да најдат src_ports, dst_ports таму. Се испостави дека хашот, ако ги погледнете првите два заглавија на IP-адресата, се покажа дека е речиси фиксиран. За да се избегне ова, за да функционира правилно балансирањето на овој инкапсулиран сообраќај, беше предложено да се додаде хашот на пакетот со 5-топла инкапсулирани на вредноста на полето за ознака за проток. Приближно истото беше направено за други шеми за инкапсулација, за UDP, за GRE, вториот го користеше полето GRE Key. Вака или онака, целите овде се јасни. И барем во тој момент тие беа корисни.

Во 2015 година, нов лепенка доаѓа од истиот почитуван инженер. Тој е многу интересен. Го кажува следново - ќе го рандомизираме хашот во случај на негативен настан за рутирање. Што е негативен настан за рутирање? Ова е RTO за кој разговаравме порано, односно губењето на опашката на прозорецот е настан кој е навистина негативен. Точно, релативно е тешко да се погоди дека тоа е тоа.

2016 година, уште една реномирана компанија, исто така голема. Ги расклопува последните патерици и го прави така што хашот, кој претходно го правевме случајно, сега се менува за секое реемитување на SYN и по секој истек на RTO. И во ова писмо, за прв и последен пат, е наведена крајната цел - да се осигура дека сообраќајот во случај на загуби или застој на каналот има способност да биде меко пренасочен и да користи повеќе патеки. Се разбира, после ова имаше многу публикации, лесно можете да ги најдете.

Иако не, не можете, затоа што немаше ниту една публикација на оваа тема. Но, ние знаеме!

И ако не разбирате целосно што е направено, ќе ви кажам сега.


Што беше направено, каква функционалност беше додадена во кернелот на Линукс? txhash се менува во случајна вредност по секој настан RTO. Ова е многу негативен резултат од рутирањето. Хешот зависи од овој txhash, а ознаката за проток зависи од хашот skb. Овде има некои пресметки за функциите; сите детали не можат да се стават на еден слајд. Ако некој е љубопитен, можете да поминете низ кодот на јадрото и да проверите.

Што е важно тука? Вредноста на полето за ознака за проток се менува во случаен број по секој RTO. Како ова влијае на нашиот несреќен проток на TCP?


Ако се случи SACK, ништо не се менува бидејќи се обидуваме повторно да испратиме познат изгубен пакет. Досега добро.


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


Останува еден проблем - RTO. Се разбира, постои и друга рута, но многу време се губи на ова. 200 ms се многу. Втората е апсолутно дива. Претходно, зборував за тајмаути на кои услугите се конфигурирани. Значи, секунда е тајмаут, кој обично го конфигурира услугата на ниво на апликација, а во ова услугата дури и ќе биде релативно исправна. Покрај тоа, повторувам, вистинскиот 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 бита; ако се совпаѓаат, тогаш сме во центарот за податоци. И во овој случај ја менуваме вредноста на истекот на SYN_RTO на 4ms. Истата задача може да се изврши многу поелегантно. Но, овој едноставен пример покажува дека ова е а) можно; б) релативно едноставно.

Што веќе знаеме? Фактот што архитектурата на рамнината овозможува скалирање, се покажува како исклучително корисно за нас кога ќе ја овозможиме ознаката за проток на ToR и ќе ја добиеме способноста да тече околу проблематичните области. Најдобар начин да се намалат вредностите на RTO и SYN-RTO е да се користат програмите eBPF. Останува прашањето: дали е безбедно да се користи ознака за проток за балансирање? И тука има една нијанса.


Да претпоставиме дека имате услуга на вашата мрежа што живее во anycast. За жал, немам време да навлегувам во детали за тоа што е anycast, но тоа е дистрибуирана услуга со различни физички сервери достапни преку истата IP адреса. И тука е можен проблем: настанот RTO може да се случи не само кога сообраќајот поминува низ ткаенината. Може да се појави и на ниво на тампон ToR: кога ќе се случи настанат инcast, може да се појави дури и на домаќинот кога домаќинот ќе истури нешто. Кога ќе се појави настан RTO и тој ја менува ознаката за проток. Во овој случај, сообраќајот може да оди во друг билокаст пример. Да претпоставиме дека ова е статусен билокаст, содржи состојба на поврзување - може да биде 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 во овој случај го решава проблемот, но треба внимателно да му пристапите на овој механизам. И уште еднаш нагласувам дека ако сте телекомуникациски оператор, не треба да користите flow label како хаш функција, во спротивно ќе ги нарушите сесиите на вашите корисници.

Мрежните инженери мора да претрпат концептуална промена: мрежата започнува не со ToR, не со мрежниот уред, туку со домаќинот. Прилично впечатлив пример е како го користиме eBPF и за промена на RTO и за фиксирање на ознаката за проток кон услугите на anycast.

Механиката на етикетата на проток е секако погодна за други апликации во рамките на контролираниот административен сегмент. Ова може да биде сообраќај помеѓу центрите за податоци или можете да користите таква механика на посебен начин за управување со појдовниот сообраќај. Но, ќе ви кажам за ова, се надевам, следниот пат. Ви благодарам многу за вниманието.

Извор: www.habr.com