Заманбап маалымат борборлорунда мониторингдин ар кандай түрлөрү менен камтылган жүздөгөн активдүү түзүлүштөр бар. Бирок колунда кемчиликсиз мониторинги бар идеалдуу инженер дагы бир нече мүнөттүн ичинде тармактын бузулушуна туура жооп бере алат. Next Hop 2020 конференциясындагы докладда мен DC тармагын долбоорлоо методологиясын сунуштадым, анын уникалдуу өзгөчөлүгү бар - маалымат борбору миллисекунддарда өзүн айыктырат. Тагыраак айтканда, инженер көйгөйдү жайбаракат чечет, ал эми кызматтар аны байкабай калат.
Көптөгөн тармак инженерлери үчүн маалымат борборунун тармагы, албетте, ToR менен, стойкадагы которгуч менен башталат. ToR адатта шилтемелердин эки түрү бар. Кичинекейлери серверлерге барышат, башкалары - алардан N эсе көп - биринчи деңгээлдеги омурткаларга, башкача айтканда, анын өйдө-ылдыйларына барышат. Жогорулатуулар, адатта, бирдей деп эсептелет жана өйдө шилтемелер ортосундагы трафик proto, src_ip, dst_ip, src_port, dst_port камтыган 5-телеликтен хэштин негизинде тең салмакталат. Бул жерде эч кандай сюрприз жок.
Андан кийин, пландын архитектурасы кандай болот? Биринчи даражадагы омурткалар бири-бирине туташкан эмес, бирок суперспиндер аркылуу туташат. X тамгасы superspines үчүн жооптуу болот; ал дээрлик кайчылаш туташуу сыяктуу.
Ал эми, экинчи жагынан, тори биринчи даражадагы бардык омурткалары менен байланышкан экени түшүнүктүү. Бул сүрөттө эмне маанилүү? Эгерде биз стеллаждын ичинде өз ара аракеттенишсек, анда өз ара аракеттенүү, албетте, ToR аркылуу өтөт. Эгерде өз ара аракеттенүү модулдун ичинде пайда болсо, анда өз ара аракеттенүү биринчи деңгээлдеги омурткалар аркылуу ишке ашат. Эгерде өз ара аракеттенүү модулдар аралык болсо - бул жердегидей, ToR 1 жана ToR 2 - анда өз ара аракеттенүү биринчи жана экинчи деңгээлдеги омурткалар аркылуу өтөт.
Теориялык жактан алганда, мындай архитектура оңой масштабдалат. Эгерде бизде порттун кубаттуулугу, маалымат борборунда бош орун жана алдын ала коюлган була бар болсо, анда тилкелердин саны ар дайым көбөйүшү мүмкүн, ошону менен системанын жалпы кубаттуулугу жогорулайт. Муну кагаз бетинде жасоо абдан оңой. Жашоодо ушундай болмок. Бирок бүгүнкү окуя бул жөнүндө эмес.
Туура тыянак чыгарылышын каалайм. Бизде маалымат борборунун ичинде көптөгөн жолдор бар. Алар шарттуу түрдө көз карандысыз. Маалымат борборунун ичиндеги бир жол ToR ичинде гана мүмкүн. Модулдун ичинде бизде жолдордун саны тилкелердин санына барабар. Модулдардын ортосундагы жолдордун саны ар бир тегиздиктеги тегиздиктердин саны менен суперспиндердин санынын көбөйтүндүсүнө барабар. Түшүнүктүү болушу үчүн, масштабды түшүнүү үчүн, мен Яндекс маалымат борборлорунун бирине жарактуу сандарды берем.
Сегиз учак бар, ар бир учакта 32 суперспина бар. Натыйжада, модулдун ичинде сегиз жол бар экени белгилүү болду, ал эми модулдар аралык өз ара аракеттенүү менен алардын 256сы бар.
Башкача айтканда, эгерде биз Cookbook'ти иштеп чыгып, өзүн айыктыра турган каталарга чыдамдуу маалымат борборлорун кантип курууну үйрөнүүгө аракет кылсак, анда планардык архитектура туура тандоо. Бул масштабдоо маселесин чечет жана теориялык жактан оңой. Көптөгөн көз карандысыз жолдор бар. Суроо бойдон калууда: мындай архитектура катачылыктарга кантип туруштук берет? Ар кандай мүчүлүштүктөр бар. Жана биз азыр муну талкуулайбыз.
Биздин суперспиндердин бири "ооруп калсын". Бул жерде мен эки учак архитектурасына кайтып келдим. Биз буларды мисал катары келтиребиз, анткени кыймылдуу бөлүктөрдүн азайышы менен эмне болуп жатканын көрүү оңой болот. X11 ооруп калсын. Бул маалымат борборлорунун ичинде жашаган кызматтарга кандай таасир этет? Көп нерсе ийгиликсиздиктин кандай экенинен көз каранды.
Эгерде бузулуу жакшы болсо, ал ошол эле BFD автоматташтыруу деңгээлинде кармалып, автоматташтыруу көйгөйлүү муундарды кубаныч менен коюп, көйгөйдү обочолонтсо, анда баары жакшы. Бизде көп жолдор бар, жол кыймылы заматта альтернативдик маршруттарга которулат, кызматтар эч нерсени байкабай калат. Бул жакшы сценарий.
Жаман сценарий - бул бизде дайыма жоготуулар болуп, автоматташтыруу көйгөйдү байкабаса. Бул колдонмого кандай таасир тийгизерин түшүнүү үчүн, TCP кантип иштээрин талкуулоого бир аз убакыт коротушубуз керек.
Мен бул маалымат менен эч кимди таң калтырбайм деп үмүттөнөм: TCP бул өткөрүү ырастоо протоколу. Башкача айтканда, эң жөнөкөй учурда, жөнөтүүчү эки пакетти жөнөтөт жана алар боюнча кумулятивдүү актты алат: "Мен эки пакет алдым".
Андан кийин ал дагы эки пакетти жөнөтөт жана кырдаал кайталанат. Бир аз жөнөкөйлөштүрүү үчүн алдын ала кечирим сурайм. Терезе (учууда пакеттердин саны) эки болсо, бул сценарий туура болот. Албетте, жалпы учурда бул сөзсүз түрдө эмес. Бирок терезенин өлчөмү пакетти багыттоо контекстине таасир этпейт.
3-пакетти жоготуп алсак эмне болот? Бул учурда, алуучу 1, 2 жана 4-пакеттерди алат. Жана ал SACK опциясын колдонуп жөнөтүүчүгө ачык айтат: "Билесизби, үчөө келди, бирок ортосу жоголду". Ал мындай дейт: "Ack 2, SACK 4".
Бул учурда жөнөтүүчү эч кандай көйгөйсүз жоголгон пакетти так кайталайт.
Ал эми терезедеги акыркы пакет жоголуп кетсе, абал такыр башкача көрүнөт.
Алуучу алгачкы үч пакетти алат жана биринчи кезекте күтө баштайт. Linux ядросунун TCP стекиндеги кээ бир оптималдаштыруулардын аркасында, ал жупташкан пакетти күтөт, эгерде желектер анын акыркы пакет же ушуга окшош бир нерсе экенин ачык көрсөтпөсө. Ал кечиктирилген ACK таймаутунун мөөнөтү бүткүчө күтүп, андан кийин алгачкы үч пакетке ырастоо жөнөтөт. Бирок азыр жөнөтүүчү күтөт. Ал төртүнчү пакет жоголдубу же келери калдыбы, билбейт. Ал эми тармакты ашыкча жүктөбөш үчүн, ал пакеттин жоголгондугунун ачык белгисин күтүүгө аракет кылат, же RTO күтүү мөөнөтү бүткүчө.
RTO тайм-ауту деген эмне? Бул TCP стек жана кээ бир туруктуу менен эсептелген RTT максималдуу болуп саналат. Бул кандай туруктуулук, биз азыр талкуулайбыз.
Бирок эң негизгиси, эгер дагы бир жолу бактысыз болуп, төртүнчү пакет кайра жоголсо, анда RTO эки эсе көбөйөт. Башкача айтканда, ар бир ийгиликсиз аракет тайм-ауттун эки эсеге көбөйүшүн билдирет.
Эми бул база эмнеге барабар экенин карап көрөлү. Демейки боюнча, минималдуу RTO 200 мс. Бул маалымат пакеттери үчүн минималдуу RTO. SYN пакеттери үчүн бул башкача, 1 секунд. Көрүнүп тургандай, пакеттерди кайра жөнөтүүнүн биринчи аракети да маалымат борборунун ичиндеги RTTге караганда 100 эсе көп убакытты талап кылат.
Эми биздин сценарийге кайрылалы. Кызмат менен эмне болуп жатат? Кызмат пакеттерди жогото баштайт. Кызмат алгач шарттуу түрдө бактылуу болсун жана терезенин ортосунда бир нерсесин жоготсун, андан кийин ал SACK алат жана жоголгон пакеттерди кайра жөнөтөт.
Бирок жаман ийгилик кайталанса, анда бизде РТО бар. Бул жерде эмне маанилүү? Ооба, биздин тармакта көп жолдор бар. Бирок белгилүү бир TCP байланышынын TCP трафиги ошол эле бузулган стек аркылуу жүрө берет. Пакеттик жоготуулар, эгерде биздин бул сыйкырдуу X11 өзүнөн өзү чыгып кетпесе, трафиктин көйгөйлүү эмес аймактарга агып кетишине алып келбейт. Биз пакетти ошол эле сынган стек аркылуу жеткирүүгө аракет кылып жатабыз. Бул каскаддык катага алып келет: маалымат борбору - бул өз ара аракеттенүүчү колдонмолордун жыйындысы жана бардык бул колдонмолордун TCP туташууларынын айрымдары начарлай баштайт - анткени superspine маалымат борборунун ичиндеги бардык тиркемелерди таасир этет. Айтылгандай: ат өтпөсөң, ат аксак кетти; ат аксак кетти - отчет берилбей калды; доклад берилген жок - согуштан утулуп калдык. Бул жерде гана эсеп көйгөй пайда болгон учурдан тартып кызматтар сезе баштаган деградация стадиясына чейин секунданын ичинде болот. Бул колдонуучулар бир жерден бир нерсеге жетишпей калышы мүмкүн дегенди билдирет.
Бири-бирин толуктап турган эки классикалык чечим бар. Биринчиси, самандарды салып, маселени чечүүгө аракет кылган кызматтар: "Келгиле, TCP стекинде бир нерсени оңдоп алалы. Колдонмо деңгээлинде тайм-ауттарды же ички ден соолукту текшерүү менен узакка созулган TCP сессияларын жасайлы." Маселе мындай чечимдер: а) такыр масштабдуу эмес; б) өтө начар текшерилет. Башкача айтканда, эгер кызмат кокустан TCP стекин аны жакшырта тургандай конфигурациялаган күндө да, биринчиден, ал бардык тиркемелер жана бардык маалымат борборлору үчүн колдонулушу күмөн, экинчиден, ал аткарылганын түшүнбөй калат. туура, жана эмне жок. Башкача айтканда, ал иштейт, бирок ал начар иштейт жана масштабдуу эмес. Ал эми тармакта көйгөй жаралса, ким күнөөлүү? Албетте, NOC. NOC эмне кылат?
Көптөгөн кызматтар УОКтун ишинде ушундай нерсе болот деп эсептешет. Бирок чынын айтсам, бул гана эмес.
Классикалык схемада NOC көптөгөн мониторинг системаларын иштеп чыгуу менен алектенет. Бул кара куту да, ак куту да мониторинг. Кара кутуча омуртка мониторингинин бир мисалы жөнүндө Александр Клименко акыркы Кийинки Хопта. Айтмакчы, бул мониторинг иштейт. Бирок идеалдуу мониторинг да убакыттын кечигүүсүнө ээ болот. Адатта, бул бир нече мүнөт. Ал өчкөндөн кийин дежур инженерлерге анын иштешин эки жолу текшерип, көйгөйдү локалдаштырууга жана көйгөйлүү аймакты өчүрүүгө убакыт керек. Башкача айтканда, эң жакшы учурда көйгөйдү дарылоо 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 жардамга келет. Жөнөкөй сөз менен айтканда, бул кичинекей C программалары.Аларды ядро стекинин жана TCP стекинин аткарылышынын ар кайсы жерлеринде илгичтерге киргизүүгө болот, алардын жардамы менен сиз өтө көп сандагы орнотууларды өзгөртө аласыз. Жалпысынан алганда, eBPF узак мөөнөттүү тренд болуп саналат. Ондогон жаңы sysctl параметрлерин кыскартуунун жана IP утилитасын кеңейтүүнүн ордуна, кыймыл eBPF тарапка жылып, анын функционалдуулугун кеңейтүүдө. eBPF колдонуп, сиз тыгынды башкарууну жана ар кандай башка TCP жөндөөлөрүн динамикалык түрдө өзгөртө аласыз.
Бирок SYN_RTO маанилерин өзгөртүү үчүн колдонулушу биз үчүн маанилүү. Мындан тышкары, жалпыга жарыяланган мисал бар: . Бул жерде эмне кылынды? Мисал иштеп жатат, бирок өзү абдан орой. Бул жерде маалымат борборунун ичинде биз биринчи 44 битти салыштырабыз деп болжолдонууда; эгерде алар дал келсе, анда биз маалымат борборунун ичинде болобуз. Жана бул учурда биз SYN_RTO таймаутунун маанисин 4ms кылып өзгөртөбүз. Ошол эле тапшырманы алда канча көрктүү кылса болот. Бирок бул жөнөкөй мисал муну көрсөтөт: а) мүмкүн; б) салыштырмалуу жөнөкөй.
Биз буга чейин эмнени билебиз? Учактын архитектурасы масштабга жол ачкандыгы, биз 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 энбелгиси көйгөйдү чечерин билесиз, бирок бул механизмге кылдаттык менен кайрылышыңыз керек. Жана дагы бир жолу баса белгилейм, эгерде сиз байланыш оператору болсоңуз, анда сиз агым белгисин хэш-функция катары колдонбошуңуз керек, антпесе колдонуучуларыңыздын сессияларын үзгүлтүккө учуратасыз.
Тармак инженерлери концептуалдык жылыштан өтүшү керек: тармак ТоРдон эмес, тармактык түзүлүштөн эмес, хосттон башталат. Эң сонун мисал, биз RTOну өзгөртүү үчүн жана каалаган кассеталык кызматтарга карата агым энбелгисин оңдоо үчүн eBPFди кантип колдонсок болот.
Агым этикеткасынын механикасы, албетте, башкарылуучу административдик сегменттеги башка колдонмолор үчүн ылайыктуу. Бул маалымат борборлорунун ортосундагы трафик болушу мүмкүн, же мындай механиканы чыгуучу трафикти башкаруу үчүн атайын жол менен колдонсоңуз болот. Бирок мен бул жөнүндө сага айтып берем, мен үмүттөнөм, кийинки жолу. Көңүл бурганыңыз үчүн чоң рахмат.
Source: www.habr.com