Қазіргі деректер орталықтарында мониторингтің әртүрлі түрлерімен қамтылған жүздеген белсенді құрылғылар орнатылған. Бірақ тіпті қолында мінсіз мониторингі бар тамаша инженер желідегі ақауларға бірнеше минут ішінде дұрыс жауап бере алады. Next Hop 2020 конференциясындағы баяндамада мен деректер орталығы желісін жобалау әдістемесін ұсындым, оның бірегей ерекшелігі бар – деректер орталығы миллисекундтарда өзін сауықтырады. Дәлірек айтқанда, инженер мәселені сабырмен шешеді, ал қызметтер оны байқамайды.
Көптеген желілік инженерлер үшін деректер орталығының желісі, әрине, ToR-дан, сөредегі коммутатордан басталады. ToR әдетте сілтемелердің екі түріне ие. Кішкентайлары серверлерге барады, басқалары - олардың N есе көп - бірінші деңгейдің тікенектеріне, яғни оның жоғары қосылыстарына барады. Орналастырулар әдетте тең деп саналады және жоғары сілтемелер арасындағы трафик proto, src_ip, dst_ip, src_port, dst_port кіретін 5-кортелік хэш негізінде теңгеріледі. Мұнда тосынсыйлар жоқ.
Әрі қарай, жоспар архитектурасы қалай көрінеді? Бірінші деңгейдегі тікенектер бір-бірімен байланыспайды, бірақ супер тікенектер арқылы жалғанады. X әрпі суперспиндерге жауап береді; бұл дерлік кросс-коннект сияқты.
Ал, екінші жағынан, тори бірінші деңгейдегі барлық омыртқаларға қосылғаны анық. Бұл суретте не маңызды? Егер бізде сөре ішінде өзара әрекеттесу болса, онда өзара әрекеттесу, әрине, ToR арқылы өтеді. Егер өзара әрекеттесу модуль ішінде орын алса, онда өзара әрекеттесу бірінші деңгейдегі тікенектер арқылы жүзеге асады. Егер өзара әрекеттесу модульаралық болса - мұндағы сияқты ToR 1 және ToR 2 - онда өзара әрекеттесу бірінші және екінші деңгейдегі тікенектер арқылы өтеді.
Теориялық тұрғыдан мұндай архитектура оңай масштабталады. Егер бізде порт сыйымдылығы, деректер орталығында бос орын және алдын ала төселген талшық болса, онда жолақтардың санын әрқашан көбейтуге болады, осылайша жүйенің жалпы сыйымдылығын арттырады. Мұны қағазда жасау өте оңай. Өмірде солай болар еді. Бірақ бүгінгі әңгіме ол туралы емес.
Дұрыс қорытындылар шығарылғанын қалаймын. Бізде деректер орталығының ішінде көптеген жолдар бар. Олар шартты түрде тәуелсіз. Деректер орталығының ішіндегі бір жол тек ToR ішінде мүмкін. Модульдің ішінде бізде жолдар санына тең жолдар саны бар. Модульдер арасындағы жолдар саны әр жазықтықтағы жазықтықтар саны мен супер тізбегі санының көбейтіндісіне тең. Түсінікті болу үшін, масштабты түсіну үшін мен Яндекс деректер орталықтарының біріне жарамды сандарды беремін.
Сегіз ұшақ бар, әр ұшақта 32 суперспин бар. Нәтижесінде модуль ішінде сегіз жол бар, ал модульаралық өзара әрекеттесу кезінде олардың 256-сы бар.
Яғни, егер біз аспаздық кітапты жасап жатсақ, өзін-өзі емдейтін ақауларға төзімді деректер орталықтарын құруды үйренуге тырыссақ, онда жазық архитектура дұрыс таңдау болып табылады. Бұл масштабтау мәселесін шешеді және теорияда бұл оңай. Көптеген тәуелсіз жолдар бар. Сұрақ қалады: мұндай архитектура сәтсіздіктерге қалай төтеп береді? Түрлі сәтсіздіктер бар. Және бұл туралы қазір талқылаймыз.
Біздің супермаркелеріміздің бірі «ауырып қалсын». Міне, мен екі жазық архитектураға қайта оралдым. Мысал ретінде біз бұларды ұстанамыз, өйткені аз қозғалатын бөліктермен не болып жатқанын көру оңайырақ болады. X11 ауырып қалсын. Бұл деректер орталықтарында тұратын қызметтерге қалай әсер етеді? Көп нәрсе сәтсіздіктің қалай көрінетініне байланысты.
Егер сәтсіздік жақсы болса, ол бірдей BFD автоматтандыру деңгейінде ұсталады, автоматтандыру проблемалық буындарды қуана қояды және мәселені оқшаулайды, содан кейін бәрі жақсы. Бізде көп жолдар бар, қозғалыс бірден балама бағыттарға қайта бағытталады, ал қызметтер ештеңені байқамайды. Бұл жақсы сценарий.
Жаман сценарий - егер бізде тұрақты жоғалтулар болса және автоматтандыру мәселені байқамайды. Мұның қолданбаға қалай әсер ететінін түсіну үшін TCP қалай жұмыс істейтінін талқылауға біраз уақыт бөлуге тура келеді.
Мен бұл ақпаратпен ешкімді таң қалдырмаймын деп үміттенемін: TCP - жіберуді растау хаттамасы. Яғни, ең қарапайым жағдайда жіберуші екі пакетті жібереді және олар бойынша жинақталған акті алады: «Мен екі пакетті алдым».
Осыдан кейін ол тағы екі пакет жібереді және жағдай қайталанады. Кейбір жеңілдету үшін алдын ала кешірім сұраймын. Терезе (ұшудағы пакеттер саны) екі болса, бұл сценарий дұрыс болады. Әрине, жалпы жағдайда бұл міндетті емес. Бірақ терезе өлшемі пакетті қайта жіберу контекстіне әсер етпейді.
3-пакетті жоғалтсақ не болады? Бұл жағдайда алушы 1, 2 және 4 пакеттерін алады. Және ол SACK опциясын пайдаланып жіберушіге: «Білесіз бе, үшеу келді, бірақ ортасы жоғалды» деп нақты айтады. Ол: «Ак 2, САК 4» дейді.
Осы сәтте жіберуші еш қиындықсыз жоғалған пакетті дәл қайталайды.
Бірақ терезедегі соңғы пакет жоғалса, жағдай мүлдем басқаша көрінеді.
Алушы алғашқы үш пакетті алады және ең алдымен күте бастайды. Linux ядросының TCP стекіндегі кейбір оңтайландырулардың арқасында, жалаушалар оның соңғы пакет немесе ұқсас нәрсе екенін анық көрсетпесе, ол жұптастырылған пакетті күтеді. Ол кешіктірілген ACK күту уақыты біткенше күтеді, содан кейін алғашқы үш пакетке растау жібереді. Бірақ қазір жіберуші күтеді. Төртінші пакеттің жоғалып кеткенін немесе келе жатқанын білмейді. Желіге шамадан тыс жүктеме түсірмеу үшін ол пакеттің жоғалғанын немесе RTO күту уақытының аяқталуын күтуге тырысады.
RTO күту уақыты дегеніміз не? Бұл TCP стекімен есептелетін RTT максимумы және кейбір тұрақты. Бұл қандай тұрақты, біз қазір талқылаймыз.
Бірақ ең бастысы, егер тағы да сәтсіз болып, төртінші пакет қайтадан жоғалса, RTO екі еселенеді. Яғни, әрбір сәтсіз әрекет күту уақытын екі еселеуді білдіреді.
Енді бұл база неге тең екенін көрейік. Әдепкі бойынша, ең аз RTO 200 мс құрайды. Бұл деректер пакеттері үшін ең аз RTO. SYN пакеттері үшін бұл басқаша, 1 секунд. Көріп отырғаныңыздай, пакеттерді қайта жіберудің алғашқы әрекеті де деректер орталығының ішіндегі RTT-ге қарағанда 100 есе көп уақыт алады.
Енді өз сценарийімізге оралайық. Қызметте не болып жатыр? Қызмет пакеттерді жоғалта бастайды. Қызмет алдымен шартты түрде сәттілікке ие болсын және терезенің ортасында бірдеңе жоғалтады, содан кейін ол SACK алады және жоғалған пакеттерді қайта жібереді.
Бірақ егер сәтсіздік қайталанса, бізде RTO бар. Мұнда не маңызды? Иә, біздің желіде көптеген жолдар бар. Бірақ белгілі бір TCP қосылымының TCP трафигі бірдей бұзылған стек арқылы өтуді жалғастырады. Біздің сиқырлы X11 өздігінен өшпесе, пакеттік шығындар проблемасыз аймақтарға трафиктің ағып кетуіне әкелмейді. Біз пакетті бірдей сынған стек арқылы жеткізуге тырысамыз. Бұл каскадты сәтсіздікке әкеледі: деректер орталығы - бұл өзара әрекеттесетін қолданбалар жиынтығы және барлық осы қолданбалардың TCP қосылымдарының кейбірі нашарлай бастайды - өйткені superspine деректер орталығының ішінде бар барлық қолданбаларға әсер етеді. «Атты етікпесең, ат ақсақ болды» дегендей. ат ақсап қалды – есеп берілмеді; есеп жеткізілмеді – біз соғыстан жеңіліп қалдық. Тек осы жерде есеп проблема туындаған сәттен бастап қызметтер сезіне бастаған деградация сатысына дейінгі секундтарда есептеледі. Бұл пайдаланушылар бір жерде бір нәрсені жіберіп алуы мүмкін дегенді білдіреді.
Бірін-бірі толықтыратын екі классикалық шешім бар. Біріншісі - сабандарды салып, мәселені келесідей шешуге тырысатын қызметтер: «TCP стегінде бір нәрсені өзгертейік. Қолданба деңгейінде күту уақытын немесе ішкі денсаулық тексерулерімен ұзақ мерзімді TCP сеанстарын жасайық.» Мәселе мынада, мұндай шешімдер: а) мүлдем масштабталмайды; б) өте нашар тексеріледі. Яғни, егер қызмет кездейсоқ TCP стегін оны жақсартатын етіп конфигурацияласа да, біріншіден, ол барлық қолданбалар мен барлық деректер орталықтары үшін жарамды болуы екіталай, екіншіден, ол мұның жасалғанын түсінбейді. дұрыс, ал не емес. Яғни, ол жұмыс істейді, бірақ ол нашар жұмыс істейді және масштабталмайды. Ал желіде ақау болса, кім кінәлі? Әрине, ҰОК. ҰОК не істейді?
Көптеген қызметтер ҰОК жұмысында осындай нәрсе болады деп санайды. Бірақ шынымды айтсам, бұл ғана емес.
ҰОК классикалық схемада көптеген мониторинг жүйелерін жасаумен айналысады. Бұл қара жәшік және ақ жәшік мониторингі. Қара жәшік омыртқаның мониторингінің мысалы туралы Александр Клименко соңғы келесі хопта. Айтпақшы, бұл мониторинг жұмыс істейді. Бірақ тіпті идеалды бақылауда да уақыт кідірісі болады. Әдетте бұл бірнеше минут. Ол сөнгеннен кейін кезекші инженерлерге оның жұмысын екі рет тексеруге, ақауды анықтауға, содан кейін проблемалық аймақты сөндіруге уақыт қажет. Яғни, ең жақсы жағдайда, проблеманы емдеу 5 минутты алады, ең нашар жағдайда - 20 минут, егер жоғалтулар қайда болатыны бірден байқалмаса. Осы уақыт ішінде - 5 немесе 20 минут - біздің қызметтеріміз зардап шегеді, бұл жақсы емес шығар.
Сіз шынымен не алғыңыз келеді? Бізде көптеген жолдар бар. Мәселелер дәл сол маршрутты пайдалануды жалғастыратын сәтсіз TCP ағындарынан туындайды. Бізге бір TCP қосылымында бірнеше маршруттарды пайдалануға мүмкіндік беретін нәрсе қажет. Шешім бар сияқты. TCP бар, ол көп жолды TCP деп аталады, яғни бірнеше жолдар үшін TCP. Рас, ол мүлдем басқа тапсырма үшін әзірленген - бірнеше желілік құрылғылары бар смартфондар үшін. Тасымалдауды ұлғайту немесе бастапқы/сақтық көшірме режимін жасау үшін қолданбаға ашық түрде бірнеше ағындарды (сеанстарды) жасайтын және сәтсіздік жағдайында олардың арасында ауысуға мүмкіндік беретін механизм әзірленді. Немесе, мен айтқанымдай, жолақты барынша арттырыңыз.
Бірақ бұл жерде бір нюанс бар. Мұның не екенін түсіну үшін біз ағындардың қалай орнатылғанын қарауымыз керек.
Жіптер дәйекті түрде орнатылады. Бірінші жіп алдымен орнатылады. Кейінгі ағындар осы ағында келісілген cookie файлы арқылы орнатылады. Мәселе мынада.
Мәселе мынада, егер бірінші жіп өзін-өзі бекітпесе, екінші және үшінші ағындар ешқашан пайда болмайды. Яғни, көп жолды TCP бірінші ағында SYN пакетінің жоғалуын шешпейді. Ал SYN жоғалса, көп жолды TCP кәдімгі TCP-ге айналады. Бұл деректер орталығының ортасында ол зауыттағы шығындар мәселесін шешуге және сәтсіздік жағдайында бірнеше жолды пайдалануды үйренуге көмектеспейді дегенді білдіреді.
Бізге не көмектесе алады? Сіздердің кейбіреулеріңіз тақырыптан біздің келесі тарихымыздың маңызды өрісі IPv6 ағынының жапсырмасының тақырып өрісі болатынын болжаған боларсыз. Шынында да, бұл v6-да пайда болатын өріс, ол v4-те жоқ, ол 20 битті алады және оны пайдалану туралы ұзақ уақыт бойы даулар болды. Бұл өте қызықты - даулар болды, RFC ішінде бірдеңе түзетілді, сонымен бірге Linux ядросында еш жерде құжатталмаған іске асыру пайда болды.
Мен сізді кішігірім тергеуге шақырамын. Соңғы бірнеше жылда Linux ядросында не болып жатқанын қарастырайық.
2014. Бір ірі және беделді компанияның инженері Linux ядросының функционалдығына ағын белгісі мәнінің ұяшық хэшіне тәуелділігін қосады. Олар мұнда нені түзетуге тырысты? Бұл келесі мәселені талқылаған RFC 6438 стандартына қатысты. Деректер орталығының ішінде IPv4 жиі IPv6 пакеттеріне инкапсуляцияланады, себебі зауыттың өзі IPv6, бірақ IPv4 қандай да бір түрде сырттан берілуі керек. Ұзақ уақыт бойы TCP немесе UDP-ге өту және src_ports, dst_ports табу үшін екі IP тақырыбының астына қарай алмайтын қосқыштармен проблемалар болды. Алғашқы екі IP тақырыбына қарасаңыз, хэш дерлік бекітілген болып шықты. Бұған жол бермеу үшін, осы инкапсулирленген трафиктің теңгерімінің дұрыс жұмыс істеуі үшін ағын белгісі өрісінің мәніне 5-корталық инкапсуляцияланған пакеттің хэшін қосу ұсынылды. Шамамен бірдей нәрсе басқа инкапсуляция схемалары үшін жасалды, UDP үшін, GRE үшін, соңғысы GRE Key өрісін пайдаланды. Әйтеуір, мұндағы мақсаттар айқын. Және, кем дегенде, сол уақытта олар пайдалы болды.
2015 жылы жаңа патч сол құрметті инженерден келеді. Ол өте қызық. Ол келесіні айтады - теріс бағыттау оқиғасы болған жағдайда хэшті рандомизациялаймыз. Теріс бағыттау оқиғасы дегеніміз не? Бұл біз бұрын талқылаған RTO, яғни терезенің құйрығын жоғалту - бұл шын мәнінде жағымсыз оқиға. Рас, дәл солай екенін болжау қиын.
2016, тағы бір беделді компания, сондай-ақ үлкен. Ол соңғы балдақтарды бөлшектейді және оны біз бұрын кездейсоқ жасаған хэш енді әрбір SYN қайта жіберу үшін және әрбір RTO күту уақытынан кейін өзгеретін етіп жасайды. Және бұл хатта бірінші және соңғы рет түпкі мақсат – жоғалулар немесе арналардың кептелуі жағдайында трафикті жұмсақ бағытта өзгерту және бірнеше жолдарды пайдалану мүмкіндігін қамтамасыз ету көрсетілген. Әрине, осыдан кейін көптеген басылымдар болды, оларды оңай табуға болады.
Жоқ, мүмкін емес, өйткені бұл тақырып бойынша бірде-бір жарияланым болған жоқ. Бірақ біз білеміз!
Егер сіз не істегеніңізді толық түсінбесеңіз, мен сізге қазір айтамын.
Не істелді, Linux ядросына қандай функция қосылды? txhash әрбір RTO оқиғасынан кейін кездейсоқ мәнге өзгереді. Бұл маршрутизацияның өте жағымсыз нәтижесі. Хэш осы txhash, ал ағын белгісі skb хэшіне байланысты. Мұнда функциялар бойынша кейбір есептеулер бар; барлық мәліметтерді бір слайдқа орналастыру мүмкін емес. Егер біреу қызық болса, сіз ядро кодынан өтіп, тексере аласыз.
Мұнда не маңызды? Ағын белгісі өрісінің мәні әрбір RTO кейін кездейсоқ санға өзгереді. Бұл біздің бақытсыз TCP ағынына қалай әсер етеді?
Егер SACK орын алса, ештеңе өзгермейді, себебі біз белгілі жоғалған пакетті қайта жіберуге тырысамыз. Барлығы ойдығыдай.
Бірақ RTO жағдайында, егер біз ToR хэш функциясына ағын белгісін қосқан болсақ, трафик басқа бағытты алуы мүмкін. Неғұрлым көп жолақтар болса, оның белгілі бір құрылғыдағы ақаулық әсер етпейтін жолды табу мүмкіндігі соғұрлым жоғары болады.
Бір мәселе қалады - RTO. Әрине, басқа бағыт бар, бірақ бұл үшін көп уақыт босқа кетеді. 200 мс өте көп. Секунд мүлдем жабайы. Бұрын мен қызметтер конфигурацияланған күту уақыттары туралы айтқан болатынмын. Сонымен, секунд - бұл әдетте қолданба деңгейінде қызмет конфигурациялайтын күту уақыты және бұл жағдайда қызмет тіпті салыстырмалы түрде дұрыс болады. Оның үстіне, қайталаймын, қазіргі заманғы деректер орталығының ішіндегі нақты RTT шамамен 1 миллисекундты құрайды.
RTO күту уақытымен не істей аласыз? Деректер пакеттері жоғалған жағдайда RTO үшін жауап беретін күту уақытын пайдаланушы кеңістігінен салыстырмалы түрде оңай конфигурациялауға болады: IP утилитасы бар және оның параметрлерінің бірінде бірдей rto_min бар. Әрине, RTO-ны жаһандық деңгейде емес, бірақ берілген префикстер үшін реттеу қажет екенін ескерсек, мұндай механизм өте тиімді көрінеді.
Рас, SYN_RTO-мен бәрі біршама нашар. Ол табиғи түрде шегеленген. Ядроның 1 секунд тұрақты мәні бар, және бұл. Пайдаланушы кеңістігінен ол жерге жете алмайсыз. Бір ғана жол бар.
eBPF көмекке келеді. Қарапайым тілмен айтқанда, бұл кішігірім Си бағдарламалары.Оларды ядро стегі мен TCP стегінің орындалуында әртүрлі жерлерде ілмектерге кірістіруге болады, олардың көмегімен параметрлердің өте үлкен санын өзгертуге болады. Жалпы, eBPF ұзақ мерзімді тренд болып табылады. Ондаған жаңа sysctl параметрлерін қысқартудың және IP утилитасын кеңейтудің орнына қозғалыс eBPF-ге қарай жылжып, оның функционалдығын кеңейтуде. eBPF көмегімен сіз кептелуді басқару элементтерін және әртүрлі басқа TCP параметрлерін динамикалық түрде өзгерте аласыз.
Бірақ біз үшін оны SYN_RTO мәндерін өзгерту үшін пайдалануға болатыны маңызды. Сонымен қатар, көпшілікке жарияланған мысал бар: . Мұнда не істелді? Мысал жұмыс істейді, бірақ өзі өте өрескел. Мұнда деректер орталығының ішінде біз алғашқы 44 битті салыстырамыз деп болжанады; егер олар сәйкес келсе, онда біз деректер орталығының ішінде боламыз. Және бұл жағдайда SYN_RTO күту уақытының мәнін 4 мс етіп өзгертеміз. Дәл сол тапсырманы әлдеқайда талғампаз орындауға болады. Бірақ бұл қарапайым мысал бұл а) мүмкін екенін көрсетеді; б) салыстырмалы қарапайым.
Біз не білеміз? Ұшақтың архитектурасы масштабтауға мүмкіндік беретін факт, біз ToR-де ағын белгісін қосқанда және проблемалық аймақтарды айналып өту мүмкіндігін алған кезде біз үшін өте пайдалы болып шықты. RTO және SYN-RTO мәндерін азайтудың ең жақсы жолы - eBPF бағдарламаларын пайдалану. Сұрақ қалады: теңгерімдеу үшін ағын белгісін пайдалану қауіпсіз бе? Және бұл жерде бір нюанс бар.
Сіздің желіңізде кез келген трансляцияда тұратын қызмет бар делік. Өкінішке орай, менің anycast деген не екенін егжей-тегжейлі айтып беруге уақытым жоқ, бірақ бұл бір IP мекенжайы арқылы қол жетімді әртүрлі физикалық серверлері бар таратылған қызмет. Міне, мүмкін болатын мәселе: RTO оқиғасы трафик мата арқылы өткенде ғана емес болуы мүмкін. Ол сондай-ақ ToR буферінің деңгейінде орын алуы мүмкін: инкаст оқиғасы орын алған кезде, ол хост бірдеңені төгіп тастағанда, хостта орын алуы мүмкін. RTO оқиғасы орын алғанда және ол ағын белгісін өзгертеді. Бұл жағдайда трафик басқа кез келген тарату данасына өтуі мүмкін. Бұл күйді кез келген трансляция деп есептейік, оның құрамында қосылым күйі бар - ол L3 Balancer немесе басқа қызмет болуы мүмкін. Содан кейін мәселе туындайды, себебі RTO-дан кейін TCP қосылымы серверге келеді, ол бұл TCP қосылымы туралы ештеңе білмейді. Егер бізде кез келген серверлер арасында күйді бөлісу болмаса, онда мұндай трафик тоқтатылады және TCP қосылымы үзіледі.
Мұнда не істей аласың? Ағын белгісін теңестіруді қосатын басқарылатын ортада кез келген трансляция серверлеріне қатынасу кезінде ағын белгісінің мәнін жазу қажет. Ең оңай жолы - мұны бірдей eBPF бағдарламасы арқылы жасау. Бірақ мұнда өте маңызды мәселе бар - егер сіз деректер орталығының желісін пайдаланбасаңыз, бірақ байланыс операторы болсаңыз не істеу керек? Бұл сіздің проблемаңыз: Juniper және Arista-ның белгілі бір нұсқаларынан бастап, олар әдепкі бойынша хэш функцияларына ағын белгісін қосады - шынын айтқанда, маған түсініксіз себеппен. Бұл желі арқылы өтетін пайдаланушылардың TCP қосылымдарын тоқтатуға әкелуі мүмкін. Сондықтан мен мұнда маршрутизаторлар параметрлерін тексеруді ұсынамын.
Қалай болғанда да, менің ойымша, біз эксперименттерге көшуге дайынбыз.
Біз ToR-де ағын белгісін қосқанда, қазір хосттарда тұратын eBPF агентін дайындадық, біз келесі үлкен сәтсіздікті күтпей, басқарылатын жарылыстарды жүргізуді шештік. Біз төрт қосылымы бар ToR-ды алып, олардың біріне тамшылар орнаттық. Олар ережені сызып, айтты - енді сіз барлық пакеттерді жоғалтасыз. Сол жақтан көріп отырғаныңыздай, бізде әр пакеттік мониторинг бар, ол 75% дейін төмендеді, яғни пакеттердің 25% жоғалды. Оң жақта осы ТР артында тұратын қызметтердің графиктері бар. Негізінде, бұл тірек ішіндегі серверлері бар интерфейстердің трафик графиктері. Көріп отырғаныңыздай, олар одан да төмен батып кетті. Неліктен олар төмендеді - 25% емес, кейбір жағдайларда 3-4 есе төмендеді? Егер TCP қосылымы сәтсіз болса, ол үзілген түйін арқылы жетуге тырысады. Бұл DC ішіндегі қызметтің әдеттегі әрекетімен ауырлатады - бір пайдаланушы сұрауы үшін ішкі қызметтерге N сұрау жасалады және жауап барлық деректер көздері жауап бергенде немесе қолданбада күту уақыты болғанда пайдаланушыға жіберіледі. әлі де конфигурациялауды қажет ететін деңгей. Яғни, бәрі өте, өте нашар.
Енді сол эксперимент, бірақ ағын белгісінің мәні қосулы. Көріп отырғаныңыздай, сол жақта біздің топтаманың мониторингі 25%-ға төмендеді. Бұл мүлдем дұрыс, өйткені ол қайта жіберулер туралы ештеңе білмейді, ол пакеттерді жібереді және жеткізілген және жоғалған пакеттер санының арақатынасын ғана санайды.
Ал оң жақта қызмет көрсету кестесі. Проблемалық буынның әсерін мұнда таба алмайсыз. Дәл сол миллисекундтарда трафик проблемалық аймақтан мәселеге әсер етпеген қалған үш қосылымға ағылды. Бізде өзін-өзі емдейтін желі бар.
Бұл менің соңғы слайдым, қорытындылау уақыты. Енді сіз өзін-өзі қалпына келтіретін деректер орталығының желісін қалай құру керектігін білесіз деп үміттенемін. Сізге Linux ядросының мұрағатынан өтіп, арнайы патчтарды іздеудің қажеті жоқ; бұл жағдайда Flow белгісі мәселені шешетінін білесіз, бірақ бұл механизмге мұқият қарау керек. Мен тағы бір рет айтамын, егер сіз байланыс операторы болсаңыз, ағын белгісін хэш функциясы ретінде пайдаланбауыңыз керек, әйтпесе пайдаланушыларыңыздың сеанстарын бұзасыз.
Желілік инженерлер концептуалды ауысудан өтуі керек: желі ToR-дан емес, желілік құрылғыдан емес, хосттан басталады. Өте жарқын мысал - RTO-ны өзгерту және кез келген трансляция қызметтеріне ағын белгісін бекіту үшін eBPF-ті қалай қолданамыз.
Ағын жапсырмасының механикасы, әрине, басқарылатын әкімшілік сегменттегі басқа қолданбалар үшін қолайлы. Бұл деректер орталықтары арасындағы трафик болуы мүмкін немесе мұндай механиканы шығыс трафикті басқару үшін арнайы жолмен пайдалануға болады. Бірақ мен бұл туралы сізге келесі жолы айтамын деп үміттенемін. Назарларыңызға көп рахмет.
Ақпарат көзі: www.habr.com