Орчин үеийн мэдээллийн төвүүд нь янз бүрийн төрлийн хяналтанд хамрагдсан олон зуун идэвхтэй төхөөрөмжтэй байдаг. Гэхдээ гартаа төгс хяналттай төгс инженер хүртэл хэдхэн минутын дотор сүлжээний доголдолд зохих ёсоор хариу өгөх боломжтой. Next Hop 2020 бага хурлын тайланд би дата төв нь миллисекундэд өөрийгөө эдгээдэг өвөрмөц онцлогтой дата төвийн сүлжээний дизайны аргачлалыг танилцуулсан. Илүү нарийвчлалтай хэлэхэд, инженер нь асуудлыг тайвнаар засдаг бол үйлчилгээ нь үүнийг анзаардаггүй.
Сүлжээний олон инженерүүдийн хувьд дата төвийн сүлжээ нь мэдээжийн хэрэг ToR, тавиур дээрх унтраалгаар эхэлдэг. ToR нь ихэвчлэн хоёр төрлийн холбоостой байдаг. Бяцхан хүүхдүүд серверүүд рүү явдаг, бусад нь - үүнээс n дахин их байдаг - эхний түвшний нуруунууд руу, өөрөөр хэлбэл түүний дээд холбоосууд руу явдаг. Uplinks нь ихэвчлэн тэнцүү гэж тооцогддог бөгөөд uplinks хоорондын урсгалыг proto, src_ip, dst_ip, src_port, dst_port агуулсан 5-tuple хэш дээр үндэслэн тэнцвэржүүлдэг. Энд гэнэтийн зүйл байхгүй.
Дараа нь онгоцны архитектур ямар харагдаж байна вэ? Эхний түвшний сээр нуруу нь хоорондоо холбогддоггүй, харин superspins-ийн тусламжтайгаар холбогддог. X үсэг нь superspins-ийг хариуцах болно, энэ нь бараг хөндлөн холболттой адил юм.
Нөгөөтэйгүүр, тори нь эхний түвшний бүх нуруутай холбоотой байдаг нь тодорхой юм. Энэ зурган дээр юу чухал вэ? Хэрэв бид тавиур дотор харилцан үйлчлэлцдэг бол харилцан үйлчлэл нь мэдээж ToR-ээр дамждаг. Хэрэв харилцан үйлчлэл нь модуль дотор явагддаг бол харилцан үйлчлэл нь эхний түвшний нуруугаар дамждаг. Хэрэв харилцан үйлчлэл нь модуль хоорондын харилцан үйлчлэлтэй бол - энд ToR 1 ба ToR 2 - харилцан үйлчлэл нь эхний болон хоёрдугаар түвшний нуруугаар дамжих болно.
Онолын хувьд ийм архитектурыг хялбархан өргөжүүлэх боломжтой. Хэрэв бид портын багтаамжтай, өгөгдлийн төвийн зайны нөөцтэй, урьдчилан тавьсан шилэн утастай бол онгоцны тоог үргэлж нэмэгдүүлж, улмаар системийн нийт хүчин чадлыг нэмэгдүүлэх боломжтой. Цаасан дээр үүнийг хийхэд маш хялбар байдаг. Бодит амьдрал дээр ийм байх байсан. Гэхдээ өнөөдрийн түүх энэ тухай биш юм.
Зөв дүгнэлт хийгээсэй гэж хүсч байна. Дата төв дотор бидэнд олон зам бий. Тэд болзолт бие даасан байдаг. Дата төв доторх нэг арга замыг зөвхөн ToR дотор хийх боломжтой. Модуль дотор бид онгоцны тоотой ижил тооны замтай байна. Модулиудын хоорондох замын тоо нь онгоцны тоо ба хавтгай тус бүрийн супер эргэлтийн тооны үржвэртэй тэнцүү байна. Илүү тодорхой болгохын тулд масштабыг мэдрэхийн тулд би Yandex мэдээллийн төвүүдийн аль нэгэнд тохирох тоонуудыг өгөх болно.
Найман онгоцтой, онгоц бүр 32 супер эргэлттэй. Үүний үр дүнд модулийн дотор найман зам байгаа бөгөөд модуль хоорондын харилцан үйлчлэлийн хувьд тэдгээрийн 256 нь аль хэдийн байна.
Өөрөөр хэлбэл, хэрэв бид "Хоолны дэвтэр" боловсруулж, өөрийгөө эдгээдэг алдааг тэсвэрлэх чадвартай мэдээллийн төвүүдийг хэрхэн барьж сурахыг хичээж байгаа бол хавтгай архитектур нь зөв сонголт юм. Энэ нь масштабын асуудлыг шийдэх боломжийг олгодог бөгөөд онолын хувьд хялбар байдаг. Бие даасан олон зам бий. Асуулт хэвээр байна: ийм архитектур бүтэлгүйтлийг хэрхэн даван туулах вэ? Янз бүрийн гэмтэл гардаг. Мөн бид одоо энэ талаар ярилцах болно.
Манай суперспингийн нэг нь өвдөөд байг. Энд би хоёр онгоцны архитектур руу буцаж ирэв. Цөөн тооны хөдөлгөөнт хэсгүүдээр энд юу болж байгааг харахад хялбар байх тул бид тэднийг жишээ болгон авч үзэх болно. X11 өвдөөд байг. Энэ нь дата төв дотор амьдардаг үйлчилгээнд хэрхэн нөлөөлөх вэ? Бүтэлгүйтэл хэрхэн харагдахаас их зүйл шалтгаална.
Хэрэв эвдрэл нь сайн бол энэ нь ижил BFD-ийн автоматжуулалтын түвшинд баригдсан бол автоматжуулалт нь асуудалтай үеийг аз жаргалтайгаар тавьж, асуудлыг тусгаарлаж, дараа нь бүх зүйл хэвийн байна. Бид олон замтай, замын хөдөлгөөнийг өөр зам руу шууд шилжүүлж, үйлчилгээ нь юу ч анзаарахгүй. Энэ бол сайн хувилбар юм.
Муу хувилбар бол бид байнгын алдагдалтай байдаг бөгөөд автоматжуулалт нь асуудлыг анзаардаггүй. Энэ нь програмд хэрхэн нөлөөлж байгааг ойлгохын тулд бид TCP протокол хэрхэн ажилладаг талаар ярилцахад бага зэрэг цаг зарцуулах шаардлагатай болно.
Би энэ мэдээллээр хэнийг ч цочирдуулахгүй гэж найдаж байна: TCP бол гар барих протокол юм. Өөрөөр хэлбэл, хамгийн энгийн тохиолдолд илгээгч нь хоёр пакет илгээж, "Би хоёр пакет хүлээн авлаа" гэсэн хуримтлагдсан акк хүлээн авдаг.
Үүний дараа тэрээр дахин хоёр пакет илгээх бөгөөд нөхцөл байдал давтагдах болно. Хялбаршуулсан зүйлд би урьдчилан хүлцэл өчье. Хэрэв цонх (нислэгийн багцын тоо) хоёр байвал энэ хувилбар зөв болно. Мэдээжийн хэрэг, энэ нь ерөнхийдөө тийм биш юм. Гэхдээ пакет дамжуулах контекст цонхны хэмжээ нөлөөлдөггүй.
Хэрэв бид багц 3-ыг алдвал яах вэ? Энэ тохиолдолд хүлээн авагч нь 1, 2, 4-р пакетуудыг хүлээн авах болно. Мөн тэрээр SACK сонголтыг ашиглан илгээгчид шууд мэдэгдэх болно: "Гурав ирсэн, гэхдээ дунд нь алдагдсан." Тэр "Ack 2, SACK 4" гэж хэлдэг.
Яг энэ мөчид илгээгч алдагдсан пакетыг ямар ч асуудалгүйгээр давтаж байна.
Харин цонхны сүүлчийн пакет алдагдсан тохиолдолд нөхцөл байдал огт өөр харагдах болно.
Хүлээн авагч эхний гурван багцыг хүлээн авч, хамгийн түрүүнд хүлээж эхэлнэ. Линуксийн цөмийн TCP стек дэх зарим оновчлолын ачаар энэ нь хамгийн сүүлийн пакет эсвэл үүнтэй төстэй зүйл гэсэн туг дээр тодорхой заагаагүй л бол энэ нь хосолсон пакетийг хүлээх болно. Энэ нь хоцрогдсон ACK-ийн хугацаа дуусах хүртэл хүлээж, эхний гурван багцад хүлээн зөвшөөрлийг илгээнэ. Харин одоо илгээгч хүлээж байх болно. Дөрөв дэх боодол алдагдсан уу, ирэх гэж байна уу гэдгийг мэдэхгүй. Сүлжээг хэт ачаалахгүйн тулд пакет алдагдсан эсвэл RTO хугацаа дуусахыг хүлээхийг хичээх болно.
RTO завсарлага гэж юу вэ? Энэ нь TCP стек болон зарим тогтмолоор тооцоолсон RTT-ийн дээд хэмжээ юм. Энэ тогтмол гэж юу вэ, бид одоо хэлэлцэх болно.
Гэхдээ хэрэв бид дахин азгүйтэж, дөрөв дэх пакет дахин алдагдвал RTO хоёр дахин нэмэгдэх нь чухал юм. Өөрөөр хэлбэл, бүтэлгүй оролдлого бүр хугацаа нь хоёр дахин нэмэгддэг.
Одоо энэ суурь нь юутай тэнцүү болохыг харцгаая. Анхдагчаар хамгийн бага RTO нь 200 мс байна. Энэ нь өгөгдлийн пакетуудын хамгийн бага RTO юм. SYN пакетуудын хувьд энэ нь өөр, 1 секунд. Таны харж байгаагаар пакетуудыг дахин илгээх анхны оролдлого хүртэл өгөгдлийн төв доторх RTT-ээс 100 дахин их хугацаа шаардагдана.
Одоо бидний хувилбар руу буцах. Үйлчилгээ нь юу болж байна вэ? Үйлчилгээ нь багцаа алдаж эхэлдэг. Үйлчилгээ нь эхлээд азтай байж, цонхны дундуур ямар нэгэн зүйл алдвал SACK хүлээн авч, алдагдсан пакетуудыг дахин илгээнэ.
Харин азгүйтэл давтагдах юм бол бид RTO-той болно. Энд юу чухал вэ? Тийм ээ, бидэнд сүлжээнд маш олон зам бий. Гэхдээ нэг TCP холболтын TCP траффик нь ижил эвдэрсэн стекээр дамжин өнгөрөх болно. Манай ид шидийн X11 өөрөө унтардаггүй тохиолдолд пакет алдагдах нь асуудалгүй газар руу урсгалыг урсгахад хүргэдэггүй. Бид ижил эвдэрсэн стекээр пакет хүргэхийг оролдож байна. Энэ нь шаталсан бүтэлгүйтэлд хүргэдэг: өгөгдлийн төв нь харилцан үйлчилдэг програмуудын багц бөгөөд эдгээр бүх програмуудын TCP холболтуудын зарим нь муудаж эхэлдэг - учир нь суперспин нь DC дотор байгаа бүх програмуудад нөлөөлдөг. "Морь гутлаагүй бол морь доголдог" гэдэг шиг. морь доголон - тайланг ирүүлээгүй; мессежийг хүргэсэнгүй - тэд дайнд ялагдсан. Гагцхүү энд асуудал үүссэнээс эхлээд үйлчилгээ мэдрэгдэж эхэлсэн доройтлын үе хүртэл хэдэн секундын турш тоологдож байна. Энэ нь хэрэглэгчид хаа нэгтээ ямар нэг зүйл хүлээж авахгүй байж магадгүй гэсэн үг юм.
Бие биенээ нөхдөг хоёр сонгодог шийдэл байдаг. Эхнийх нь сүрэл тавьж, асуудлыг шийдэхийг оролдож буй үйлчилгээ юм: "TCP стек дээр ямар нэг зүйлийг тохируулцгаая. Мөн дотоод эрүүл мэндийн үзлэгээр хэрэглээний түвшний завсарлага эсвэл урт хугацааны TCP сессүүдийг хийцгээе. Асуудал нь ийм шийдлүүд: a) огт масштабтай байдаггүй; б) маш муу туршсан. Өөрөөр хэлбэл, үйлчилгээ нь санамсаргүйгээр TCP стекийг илүү сайн болгохоор тохируулсан ч, нэгдүгээрт, энэ нь бүх програмууд болон бүх мэдээллийн төвүүдэд хамаарахгүй, хоёрдугаарт, юу зөв хийгдсэн, юу хийснийг ойлгохгүй байх магадлалтай. үгүй. Өөрөөр хэлбэл, энэ нь ажилладаг, гэхдээ энэ нь муу ажилладаг, масштабтай байдаггүй. Мөн сүлжээний асуудал гарвал хэн буруутай вэ? Мэдээж ҮОХ. NOC юу хийдэг вэ?
Олон алба ҮОХ-нд ийм ажил явдаг гэж үздэг. Гэхдээ үнэнийг хэлэхэд зөвхөн биш.
Сонгодог схемийн дагуу ҮОХ нь олон мониторингийн боловсруулалт хийдэг. Эдгээр нь хар хайрцагны хяналт ба цагаан хайрцагны хяналт юм. Сээр нурууг хянах хар хайрцагны жишээний тухай Александр Клименко өнгөрсөн Next Hop-ийн тухай. Дашрамд хэлэхэд энэ мониторинг ажилладаг. Гэхдээ төгс хяналт ч гэсэн цаг хугацааны хоцрогдолтой байх болно. Ихэвчлэн хэдэн минут болдог. Ажилласны дараа жижүүрийн инженерүүд түүний ажиллагааг дахин шалгаж, асуудлыг нутагшуулж, дараа нь асуудлын талбарыг унтраах шаардлагатай байна. Энэ нь хамгийн сайн тохиолдолд, алдагдлыг хаана нэн даруй мэдэгдэхгүй бол асуудлыг эмчлэхэд 5 минут, хамгийн муу нь 20 минут шаардагдана. Энэ бүх хугацаанд буюу 5 эсвэл 20 минутын хугацаанд манай үйлчилгээнүүд хохирсоор байх нь тодорхой бөгөөд энэ нь сайн биш байж магадгүй юм.
Та юу авахыг хүсч байна вэ? Бидэнд маш олон зам бий. Азгүй TCP урсгалууд ижил замыг үргэлжлүүлэн ашигладаг тул асуудал үүсдэг. Бидэнд нэг TCP холболт дотор олон маршрут ашиглах боломжийг олгох ямар нэг зүйл хэрэгтэй байна. Бидэнд шийдэл байгаа юм шиг санагдаж байна. TCP байдаг бөгөөд үүнийг олон замт TCP гэж нэрлэдэг, өөрөөр хэлбэл олон замд зориулсан TCP. Энэ нь огт өөр ажилд зориулагдсан нь үнэн - хэд хэдэн сүлжээний төхөөрөмжтэй ухаалаг гар утсанд зориулагдсан. Шилжүүлгийг нэмэгдүүлэх эсвэл үндсэн / нөөцлөх горимыг хийхийн тулд програмын хэд хэдэн хэлхээг (сесс) ил тод үүсгэж, алдаа гарсан тохиолдолд тэдгээрийн хооронд шилжих боломжийг олгодог механизмыг боловсруулсан. Эсвэл миний хэлсэнчлэн зурвасын өргөнийг нэмэгдүүлэх.
Гэхдээ энд нэг нюанс бий. Энэ нь юу болохыг ойлгохын тулд бид урсгалыг хэрхэн тохируулж байгааг харах хэрэгтэй болно.
Утаснуудыг дарааллаар нь тохируулсан. Эхний урсгалыг эхлээд суулгана. Дараа нь тухайн хэлхээнд аль хэдийн тохиролцсон күүки ашиглан дараагийн урсгалуудыг тохируулна. Тэгээд асуудал энд байна.
Асуудал нь хэрэв эхний thread суулгаагүй бол хоёр, гурав дахь thread хэзээ ч гарч ирэхгүй. Өөрөөр хэлбэл, олон замт TCP нь эхний урсгал дахь SYN пакетийн алдагдлыг шийдэж чадахгүй. Хэрэв SYN алдагдсан бол олон замт TCP нь ердийн TCP болно. Тиймээс дата төвийн орчинд энэ нь бидэнд үйлдвэр дэх алдагдлын асуудлыг шийдэж, бүтэлгүйтсэн тохиолдолд олон замыг ашиглаж сурахад тус болохгүй.
Бидэнд юу тусалж чадах вэ? Та нарын зарим нь бидний цаашдын түүхийн чухал талбар нь IPv6 урсгалын шошгоны толгой талбар байх болно гэдгийг аль хэдийн нэрнээс нь тааварласан. Үнэхээр энэ талбар бол v6 дээр гарч ирдэг, v4 дээр байдаггүй, 20 бит авдаг, ашиглах талбар нь удаан хугацааны турш маргаантай байсан. Энэ нь маш сонирхолтой юм - маргаантай байсан, RFC-ийн хүрээнд ямар нэг зүйлийг зассан бөгөөд үүнтэй зэрэгцэн Линуксийн цөмд хэзээ ч хаана ч баримтжуулаагүй хэрэгжүүлэлт гарч ирэв.
Чамайг надтай нэгдэхийг санал болгож байна. Сүүлийн хэдэн жилийн хугацаанд Линуксийн цөмд юу болж байгааг харцгаая.
2014 он. Томоохон, нэр хүндтэй компанийн инженер нь залгуурын хэшээс урсгалын шошгоны үнэ цэнийн хамаарлыг Линуксийн цөмийн функцэд нэмж өгдөг. Тэд энд юу засах гээд байгаа юм бэ? Энэ нь дараах асуудлыг хэлэлцсэн RFC 6438-тай холбоотой юм. Өгөгдлийн төв дотор IPv4 нь ихэвчлэн IPv6 пакетуудад бүрхэгдсэн байдаг, учир нь үйлдвэр нь өөрөө IPv6 боловч IPv4-г ямар нэгэн байдлаар өгөх ёстой. Удаан хугацааны турш TCP эсвэл UDP руу орж, тэндээс src_port, dst_ports олохын тулд хоёр IP толгойн доор харагдахгүй байгаа унтраалгатай холбоотой асуудал байсан. Хэрэв та эхний хоёр IP толгойг харвал хэш бараг л тогтсон болох нь тогтоогдсон. Үүнээс зайлсхийхийн тулд энэхүү капсуллагдсан траффикийг тэнцвэржүүлэх нь зөв ажиллахын тулд урсгалын шошгоны талбарын утгад 5 багц бүхий багцаас хэш нэмэхийг санал болгосон. Ойролцоогоор ижил зүйлийг бусад капсулжуулалтын схемд, UDP-д, GRE-д хийсэн бөгөөд сүүлийнх нь GRE Түлхүүр талбарыг ашигласан. Ямар нэг байдлаар энд зорилгууд тодорхой байна. Мөн ядаж тэр үед тэд ашигтай байсан.
2015 онд ижил нэр хүндтэй инженерээс шинэ нөхөөс гарч ирэв. Тэр маш сонирхолтой. Энэ нь дараахь зүйлийг хэлдэг - бид сөрөг чиглүүлэлтийн үйл явдлын тохиолдолд хэшийг санамсаргүй байдлаар хуваах болно. Сөрөг чиглүүлэлтийн үйл явдал гэж юу вэ? Энэ бол бидний өмнө нь хэлэлцсэн RTO юм, өөрөөр хэлбэл цонхны сүүл алдагдах нь үнэхээр сөрөг үйл явдал юм. Энэ нь юу болохыг таахад харьцангуй хэцүү байдаг нь үнэн.
2016 он, бас нэг нэр хүндтэй компани, бас том. Энэ нь сүүлийн суга таягуудыг задлан шинжилж, бидний өмнө нь санамсаргүй байдлаар хийсэн хэшийг одоо SYN дахин дамжуулах бүрт болон RTO хугацаа дууссаны дараа өөрчлөх боломжтой болгодог. Мөн энэ захидалд анхны бөгөөд сүүлчийн удаа эцсийн зорилго нь сонсогдож байна - суваг алдагдсан эсвэл хэт ачаалалтай үед замын хөдөлгөөнд олон зам ашиглан зөөлөн чиглүүлэлт хийх боломжтой эсэхийг шалгах явдал юм. Мэдээжийн хэрэг, үүний дараа маш олон хэвлэл гарсан тул та тэдгээрийг амархан олж болно.
Үгүй ч гэсэн та чадахгүй, учир нь энэ сэдвээр ганц ч нийтлэл гараагүй байна. Гэхдээ бид мэднэ!
Хэрэв та юу хийснийг бүрэн ойлгохгүй байгаа бол би одоо танд хэлэх болно.
Юу хийсэн бэ, Линуксийн цөмд ямар функц нэмэгдсэн бэ? 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 битийг харьцуулж, хэрэв тэдгээр нь таарч байвал бид DC дотор байна гэж таамаглаж байна. Мөн энэ тохиолдолд бид SYN_RTO завсарлагын утгыг 4ms болгож өөрчилнө. Үүнтэй ижил ажлыг илүү гоёмсог хийж болно. Гэхдээ энэ энгийн жишээ нь юу болохыг харуулж байна a) боломжтой; б) харьцангуй хялбар.
Бид аль хэдийн юу мэддэг вэ? Хавтгай архитектур нь масштабыг нэмэгдүүлэх боломжийг олгодог тул бид ToR дээрх урсгалын шошгыг асааж, асуудалтай газруудыг тойрон эргэлдэх боломжийг олж авах үед энэ нь бидэнд маш ашигтай болж хувирдаг. RTO болон SYN-RTO утгыг бууруулах хамгийн сайн арга бол eBPF програмуудыг ашиглах явдал юм. Асуулт хэвээр байна: тэнцвэржүүлэхийн тулд урсгалын шошгыг ашиглах нь аюулгүй юу? Мөн энд нэг нюанс бий.
Та сүлжээнд дурын дамжуулалтад ажилладаг үйлчилгээтэй гэж бодъё. Харамсалтай нь надад anycast-ын талаар дэлгэрэнгүй ярих цаг алга, гэхдээ энэ нь нэг IP хаяг дээр өөр өөр физик серверүүдийг ашиглах боломжтой түгээсэн үйлчилгээ юм. Мөн энд байж болох асуудал байна: RTO үйл явдал зөвхөн үйлдвэрээр дамжин өнгөрөх үед ч тохиолдож болно. Энэ нь ToR буферийн түвшинд ч тохиолдож болно: incast үйл явдал тохиолдоход, хост ямар нэг зүйл асгарах үед хост дээр ч тохиолдож болно. RTO үйл явдал тохиолдоход урсгалын шошгыг өөрчилнө. Энэ тохиолдолд урсгал өөр дурын дамжуулалт руу шилжиж болно. Энэ нь статустай дурын дамжуулалт гэж бодъё, энэ нь холболтын төлөвийг агуулдаг - энэ нь L3 Balancer эсвэл өөр үйлчилгээ байж болно. Дараа нь асуудал үүсдэг, учир нь RTO-ийн дараа TCP холболт сервер дээр ирдэг бөгөөд энэ TCP холболтын талаар юу ч мэдэхгүй. Хэрэв бид anycast серверүүдийн хооронд төлөв хуваалцахгүй бол ийм траффик буурч, TCP холболт тасрах болно.
Энд юу хийж болох вэ? Урсгалын шошгыг тэнцвэржүүлэхийг идэвхжүүлсэн хяналттай орчинд та дурын дамжуулалтын серверт хандахдаа урсгалын шошгоны утгыг засах хэрэгтэй. Хамгийн хялбар арга бол ижил eBPF програмаар дамжуулан хийх явдал юм. Гэхдээ энд маш чухал зүйл байна - хэрэв та мэдээллийн төвийн сүлжээ ажиллуулдаггүй, харин харилцаа холбооны оператор бол яах вэ? Энэ бол таны асуудал юм: Juniper болон Arista-ийн тодорхой хувилбаруудаас эхлээд тэд хэш функцэд урсгалын шошгыг оруулсан байдаг - үнэнийг хэлэхэд би яагаад ч юм ойлгохгүй байна. Энэ нь таныг сүлжээгээр дамжиж буй хэрэглэгчдийн TCP холболтыг таслахад хүргэж болзошгүй. Тиймээс би энэ байршилд чиглүүлэгчийнхээ тохиргоог шалгахыг зөвлөж байна.
Ямар нэг байдлаар бид туршилт руу шилжихэд бэлэн байгаа юм шиг санагдаж байна.
Бид ToR дээрх урсгалын шошгыг асааж, одоо хостууд дээр амьдардаг агентийн eBPF-ийг бэлдэж, дараагийн том бүтэлгүйтлийг хүлээхгүй, харин хяналттай тэсрэлт хийхээр шийдсэн. Дөрвөн холболттой ToR-ийг авч, нэг дээр нь дусал хийсэн. Тэд дүрэм зурсан гэж тэд хэлэв - одоо та бүх багцаа алдаж байна. Таны зүүн талд харж байгаагаар бид пакет бүрт хяналт тавьдаг бөгөөд энэ нь 75% болж буурсан, өөрөөр хэлбэл пакетуудын 25% нь алдагдсан байна. Баруун талд энэ ТоР-ын ард амьдардаг үйлчилгээний графикууд байна. Үнэн хэрэгтээ эдгээр нь тавиур доторх серверүүдтэй холболтын хөдөлгөөний графикууд юм. Таны харж байгаагаар тэд бүр доошоо живсэн. Тэд яагаад 25% биш, харин зарим тохиолдолд 3-4 дахин бага живсэн бэ? Хэрэв TCP холболт азгүй бол энэ нь эвдэрсэн интерфейсээр дамжуулан холбогдохыг оролдсоор байна. Энэ нь DC доторх үйлчилгээний ердийн үйлдлээс болж улам бүр дорддог - нэг хэрэглэгчийн хүсэлтийн хувьд дотоод үйлчилгээнд N хүсэлт үүсэж, бүх өгөгдлийн эх сурвалж хариу өгөх эсвэл цаг дуусах үед хариу нь хэрэглэгч рүү очих болно. тохируулах шаардлагатай хэвээр байгаа програмын түвшин. Өөрөөр хэлбэл, бүх зүйл маш муу байна.
Одоо ижил туршилт, гэхдээ урсгалын шошгыг идэвхжүүлсэн. Таны харж байгаагаар зүүн талд бидний багцын хяналт мөн адил 25% -иар буурсан байна. Энэ нь туйлын зөв, учир нь тэр дахин дамжуулалтын талаар юу ч мэдэхгүй, пакет илгээж, хүргэсэн болон алдагдсан пакетуудын тооны харьцааг л тооцдог.
Мөн баруун талд үйлчилгээний хуваарь байна. Асуудлын үе мөчний үр нөлөөг та эндээс олохгүй. Асуудлын бүсээс асуудалд өртөөгүй үлдсэн гурван дээш холбоос руу ижил миллисекундэд урсгал урсдаг. Бид өөрийгөө эдгээдэг сүлжээтэй болсон.
Энэ бол миний сүүлчийн слайд, дүгнэлт хийх цаг юм. Одоо та өөрийгөө эдгээх дата төвийн сүлжээг хэрхэн бүтээх талаар мэдэж байгаа гэж найдаж байна. Та Линуксийн цөмийн архивыг үзэж, тэндээс тусгай засваруудыг хайх шаардлагагүй, Flow шошго нь энэ тохиолдолд асуудлыг шийддэг гэдгийг та мэднэ, гэхдээ та энэ механизмд анхааралтай хандах хэрэгтэй. Хэрэв та тээвэрлэгч бол урсгалын шошгыг хэш функц болгон ашиглах ёсгүй, эс тэгвээс та хэрэглэгчдийнхээ сессийг эвдэх болно гэдгийг би дахин онцолж байна.
Сүлжээний инженерүүдийн хувьд концепцийн өөрчлөлтийг хийх шаардлагатай: сүлжээ нь ToR-ээс эхэлдэггүй, сүлжээний төхөөрөмжөөс биш, харин хостоос эхэлдэг. Маш гайхалтай жишээ бол бид RTO-г өөрчлөх, дурын дамжуулалтын үйлчилгээ рүү чиглэсэн урсгалын шошгыг засахын тулд eBPF-ийг ашигладаг явдал юм.
Урсгалын шошгоны механик нь хяналттай захиргааны сегмент дэх бусад хэрэглээнд тохиромжтой. Энэ нь өгөгдлийн төвүүдийн хоорондох урсгал байж болно, эсвэл та ийм механикийг ашиглан гадагш урсгалыг хянах тусгай арга замаар ашиглаж болно. Гэхдээ би энэ талаар дараагийн удаа ярих болно гэж найдаж байна. Анхаарал тавьсанд маш их баярлалаа.
Эх сурвалж: www.habr.com