Zamonaviy ma'lumotlar markazlarida turli xil monitoring turlari bilan qamrab olingan yuzlab faol qurilmalar mavjud. Ammo qo'lida mukammal monitoringga ega bo'lgan mukammal muhandis ham bir necha daqiqada tarmoqdagi nosozlikka to'g'ri javob bera oladi. Next Hop 2020 konferensiyasidagi ma’ruzada men o‘ziga xos xususiyatga ega bo‘lgan ma’lumotlar markazi tarmog‘ini loyihalash metodologiyasini taqdim etdim – ma’lumotlar markazi millisekundlarda o‘zini davolaydi. Aniqrog'i, muhandis muammoni xotirjamlik bilan hal qiladi, xizmatlar esa buni sezmaydilar.
Ko'pgina tarmoq muhandislari uchun ma'lumotlar markazi tarmog'i, albatta, ToR bilan, rafdagi kalit bilan boshlanadi. ToR odatda ikki turdagi havolalarga ega. Kichkintoylar serverlarga boradilar, boshqalari - ulardan N marta ko'proq - birinchi darajadagi tikanlar tomon, ya'ni uning yuqori ulanishlariga boradilar. Yuqori ulanishlar odatda teng hisoblanadi va yuqoriga ulanishlar orasidagi trafik proto, src_ip, dst_ip, src_port, dst_portni o'z ichiga olgan 5-tuple xesh asosida muvozanatlanadi. Bu erda hech qanday kutilmagan hodisalar yo'q.
Keyinchalik, samolyotlarning arxitekturasi qanday ko'rinishga ega? Birinchi darajadagi tikanlar bir-biriga bog'lanmagan, lekin superspinlar yordamida bog'langan. X harfi superspinlar uchun javobgar bo'ladi, bu deyarli o'zaro bog'lanishga o'xshaydi.
Va aniqki, boshqa tomondan, tori birinchi darajadagi barcha tikanlar bilan bog'langan. Ushbu rasmda nima muhim? Agar biz raf ichida o'zaro ta'sirga ega bo'lsak, unda o'zaro ta'sir, albatta, ToR orqali o'tadi. Agar o'zaro ta'sir modul ichida bo'lsa, u holda o'zaro ta'sir birinchi darajadagi tikanlar orqali o'tadi. Agar o'zaro ta'sir modullararo bo'lsa - bu erda bo'lgani kabi, ToR 1 va ToR 2 - u holda o'zaro ta'sir ham birinchi, ham ikkinchi darajadagi tikanlar orqali o'tadi.
Nazariy jihatdan, bunday arxitektura osongina kengaytirilishi mumkin. Agar bizda port sig'imi, ma'lumotlar markazida bo'sh joy zaxirasi va oldindan yotqizilgan tola mavjud bo'lsa, u holda samolyotlar soni har doim ko'paytirilishi mumkin va shu bilan tizimning umumiy quvvatini oshiradi. Qog'ozda buni qilish juda oson. Haqiqiy hayotda ham shunday bo'lardi. Ammo bugungi hikoya bu haqda emas.
Men to'g'ri xulosalar chiqarilishini xohlayman. Ma'lumotlar markazida ko'plab yo'llar mavjud. Ular shartli ravishda mustaqildir. Ma'lumotlar markazi ichida bir yo'l faqat ToR ichida mumkin. Modulning ichida bizda samolyotlar soni bilan bir xil miqdordagi yo'llar mavjud. Modullar orasidagi yo'llar soni tekisliklar soni va har bir tekislikdagi superspinlar sonining mahsulotiga teng. Aniqroq qilish, o'lchovni his qilish uchun men Yandex ma'lumotlar markazlaridan biri uchun amal qiladigan raqamlarni beraman.
Sakkizta samolyot bor, har bir samolyotda 32 ta superspin bor. Natijada, modul ichida sakkizta yo'l borligi ma'lum bo'ldi va modullararo o'zaro ta'sirda ularning 256 tasi mavjud.
Ya'ni, agar biz pishirish kitobini ishlab chiqayotgan bo'lsak, o'z-o'zini davolaydigan xatolarga chidamli ma'lumotlar markazlarini qanday qurishni o'rganishga harakat qilsak, unda planar arxitektura to'g'ri tanlovdir. Bu sizga masshtablash muammosini hal qilishga imkon beradi va nazariy jihatdan bu oson. Ko'p mustaqil yo'llar mavjud. Savol tug'iladi: bunday arxitektura muvaffaqiyatsizliklardan qanday omon qoladi? Turli xil buzilishlar mavjud. Va biz buni hozir muhokama qilamiz.
Superspinlarimizdan biri kasal bo'lib qolsin. Bu erda men ikkita samolyot arxitekturasiga qaytdim. Biz ularga misol sifatida yopishib olamiz, chunki harakatlanuvchi qismlar kamroq bo'lsa, bu erda nima sodir bo'layotganini ko'rish osonroq bo'ladi. X11 kasal bo'lsin. Bu ma'lumotlar markazlarida yashovchi xizmatlarga qanday ta'sir qiladi? Ko'p narsa muvaffaqiyatsizlik qanday ko'rinishiga bog'liq.
Agar muvaffaqiyatsizlik yaxshi bo'lsa, u bir xil BFD ni avtomatlashtirish darajasida tutiladi, avtomatlashtirish muammoli bo'g'inlarni mamnuniyat bilan qo'yadi va muammoni izolyatsiya qiladi, keyin hamma narsa yaxshi. Bizda ko'plab yo'llar bor, transport bir zumda muqobil yo'nalishlarga o'tkaziladi va xizmatlar hech narsani sezmaydi. Bu yaxshi stsenariy.
Yomon stsenariy, agar bizda doimiy yo'qotishlar bo'lsa va avtomatlashtirish muammoni sezmasa. Bu dasturga qanday ta'sir qilishini tushunish uchun biz TCP protokoli qanday ishlashini muhokama qilish uchun biroz vaqt sarflashimiz kerak bo'ladi.
Umid qilamanki, bu ma'lumot bilan hech kimni hayratda qoldirmayman: TCP - bu qo'l siqish protokoli. Ya'ni, eng oddiy holatda, jo'natuvchi ikkita paketni yuboradi va ular bo'yicha kümülatif ack oladi: "Men ikkita paket oldim."
Shundan so'ng u yana ikkita paket yuboradi va vaziyat yana takrorlanadi. Biroz soddalashtirish uchun oldindan uzr so'rayman. Agar oyna (parvozdagi paketlar soni) ikkita bo'lsa, bu stsenariy to'g'ri bo'ladi. Albatta, bu umuman olganda shunday bo'lishi shart emas. Ammo paketni yo'naltirish kontekstiga oyna o'lchami ta'sir qilmaydi.
Agar biz 3-paketni yo'qotsak nima bo'ladi? Bunday holda, qabul qiluvchi 1, 2 va 4-paketlarni oladi. Va u SACK opsiyasidan foydalangan holda jo'natuvchiga aniq xabar beradi: "Bilasizmi, uchtasi keldi, lekin o'rtasi yo'qoldi." U "Ack 2, SACK 4" deydi.
Ayni paytda jo'natuvchi hech qanday muammosiz yo'qolgan paketni aynan takrorlaydi.
Ammo oynadagi oxirgi paket yo'qolgan bo'lsa, vaziyat juda boshqacha ko'rinadi.
Qabul qiluvchi dastlabki uchta paketni oladi va birinchi navbatda kutishni boshlaydi. Linux yadrosining TCP stekidagi ba'zi optimallashtirishlar tufayli, agar bayroqlarda bu oxirgi paket yoki shunga o'xshash narsa aniq ko'rsatilmagan bo'lsa, u juftlashtirilgan paketni kutadi. Kechiktirilgan ACK kutish muddati tugaguncha kutib turadi va keyin dastlabki uchta paket uchun tasdiqnoma yuboradi. Ammo endi jo'natuvchi kutmoqda. To‘rtinchi paket yo‘qolganmi yoki yetib kelayaptimi, bilmaydi. Tarmoqni ortiqcha yuklamaslik uchun u paket yo'qolganligi yoki RTO vaqtining tugashi haqida aniq ko'rsatmani kutishga harakat qiladi.
RTO kutish vaqti nima? Bu TCP to'plami va ba'zi doimiylar tomonidan hisoblangan RTTdan maksimaldir. Bu doimiy nima, biz hozir muhokama qilamiz.
Ammo shunisi muhimki, agar biz yana omadimiz kelmasa va to'rtinchi paket yana yo'qolsa, RTO ikki baravar ko'payadi. Ya'ni, har bir muvaffaqiyatsiz urinish - bu vaqtni ikki baravar oshirish.
Keling, bu baza nimaga teng ekanligini ko'rib chiqaylik. Odatiy bo'lib, minimal RTO 200ms ni tashkil qiladi. Bu ma'lumotlar paketlari uchun minimal RTO. SYN paketlari uchun u boshqacha, 1 soniya. Ko'rib turganingizdek, paketlarni qayta jo'natishning birinchi urinishi ham ma'lumotlar markazi ichidagi RTT-dan 100 baravar ko'proq vaqt oladi.
Endi bizning stsenariyimizga qayting. Xizmat bilan nima bo'lyapti? Xizmat paketlarni yo'qotishni boshlaydi. Xizmat dastlab omadli bo'lsin va oynaning o'rtasida nimadir yo'qotsin, keyin u SACK oladi, yo'qolgan paketlarni qayta yuboradi.
Ammo omadsizlik takrorlansa, bizda RTO bor. Bu erda nima muhim? Ha, bizda tarmoqda juda ko'p yo'llar mavjud. Ammo ma'lum bir TCP ulanishining TCP trafigi bir xil buzilgan stek orqali o'tishda davom etadi. Paket yo'qolishi, agar bizning sehrli X11 o'z-o'zidan o'chmasa, muammoli bo'lmagan joylarga transport oqimiga olib kelmaydi. Biz bir xil buzilgan stek orqali paketni yetkazib berishga harakat qilmoqdamiz. Bu kaskadli nosozlikka olib keladi: ma'lumotlar markazi o'zaro ta'sir qiluvchi ilovalar to'plamidir va bu ilovalarning ba'zi TCP ulanishlari yomonlasha boshlaydi - chunki superspin ma'lumotlar markazi ichidagi barcha ilovalarga ta'sir qiladi. Maqoldagidek: otni etik qilmasang, ot oqsoqlanadi; ot oqsoqlandi - hisobot yetkazilmadi; xabar yetkazilmadi - ular urushda yutqazdilar. Faqat bu erda hisoblash muammo yuzaga kelgan paytdan boshlab xizmatlar seza boshlagan degradatsiya bosqichiga qadar bir necha soniya davom etadi. Bu shuni anglatadiki, foydalanuvchilar biror joyda biror narsa olmasliklari mumkin.
Bir-birini to'ldiradigan ikkita klassik echim mavjud. Birinchisi, somon qo'yish va muammoni hal qilishga urinayotgan xizmatlar: “Keling, TCP stekida biror narsani o'zgartiraylik. Va keling, ichki sog'liq tekshiruvlari bilan ilova darajasidagi taym-autlarni yoki uzoq muddatli TCP seanslarini qilaylik. Muammo shundaki, bunday echimlar: a) umuman masshtabga ega emas; b) juda yomon sinovdan o'tgan. Ya'ni, agar xizmat tasodifan TCP stekini yaxshiroq sozlagan bo'lsa ham, birinchidan, bu barcha ilovalar va barcha ma'lumotlar markazlari uchun qo'llanilishi dargumon, ikkinchidan, nima to'g'ri bajarilganligini va nima ekanligini tushunmaydi. emas. Ya'ni, u ishlaydi, lekin u yomon ishlaydi va miqyosda emas. Va agar tarmoq muammosi bo'lsa, kim aybdor? Albatta MOQ. NOC nima qiladi?
Ko'pgina xizmatlar MOQda ish shu tarzda ketayotganiga ishonishadi. Lekin rostini aytsam, nafaqat.
MOQ klassik sxema bo'yicha ko'plab monitoringlarni ishlab chiqish bilan shug'ullanadi. Bular qora quti monitoringi va oq quti monitoringi. Tikanlarning qora qutisi-monitoring misoli haqida Aleksandr Klimenko o'tmishdagi Next Hop haqida. Aytgancha, bu monitoring ishlaydi. Ammo hatto mukammal monitoring ham vaqt oralig'iga ega bo'ladi. Odatda bu bir necha daqiqa. U ishlagandan so'ng, navbatchi muhandislarga uning ishlashini ikki marta tekshirish, muammoni lokalizatsiya qilish va muammoli joyni o'chirish uchun vaqt kerak bo'ladi. Ya'ni, eng yaxshi holatda, muammoni davolash 5 daqiqa, eng yomoni 20 daqiqa davom etadi, agar yo'qotishlar qaerda sodir bo'lganligi darhol aniq bo'lmasa. Shuncha vaqt - 5 yoki 20 daqiqa - bizning xizmatlarimiz zarar etkazishda davom etishi aniq, bu yaxshi emas.
Siz nimani olishni xohlaysiz? Bizda juda ko'p yo'llar bor. Va muammolar aynan shu sababli yuzaga keladi, chunki omadsiz TCP oqimlari bir xil yo'nalishdan foydalanishda davom etadi. Bizga bitta TCP ulanishida bir nechta marshrutlardan foydalanishga imkon beradigan narsa kerak. Bizning yechimimiz borga o'xshaydi. TCP mavjud bo'lib, u ko'p yo'l TCP deb ataladi, ya'ni ko'p yo'llar uchun TCP. To'g'ri, u butunlay boshqa vazifa uchun - bir nechta tarmoq qurilmalariga ega smartfonlar uchun ishlab chiqilgan. O'tkazishni maksimal darajada oshirish yoki asosiy/zaxira rejimini o'tkazish uchun dastur uchun shaffof ravishda bir nechta mavzularni (sessiyalarni) yaratadigan va ishlamay qolganda ular o'rtasida almashish imkonini beruvchi mexanizm ishlab chiqilgan. Yoki, aytganimdek, tarmoqli kengligini maksimal darajada oshiring.
Ammo bu erda bir nuance bor. Bu nima ekanligini tushunish uchun biz oqimlar qanday o'rnatilishini ko'rib chiqishimiz kerak.
Iplar ketma-ket o'rnatiladi. Birinchi oqim birinchi navbatda o'rnatiladi. Keyinchalik keyingi oqimlar ushbu mavzu doirasida allaqachon kelishilgan cookie-fayllar yordamida o'rnatiladi. Va bu erda muammo.
Muammo shundaki, agar birinchi ip o'rnatilmasa, ikkinchi va uchinchi iplar hech qachon chiqmaydi. Ya'ni, multipath TCP birinchi oqimda SYN paketining yo'qolishini hal qilmaydi. Va agar SYN yo'qolsa, ko'p yo'nalishli TCP oddiy TCPga aylanadi. Shunday qilib, ma'lumotlar markazi muhitida bu bizga zavoddagi yo'qotishlar muammosini hal qilishda yordam bermaydi va ishlamay qolganda bir nechta yo'llardan qanday foydalanishni o'rganadi.
Bizga nima yordam berishi mumkin? Sizning ba'zilaringiz IPv6 oqim yorlig'i sarlavhasi maydoni bizning keyingi hikoyamizda muhim maydon bo'lishini allaqachon nomidan taxmin qilgansiz. Haqiqatan ham, bu v6-da paydo bo'ladigan maydon, u v4-da emas, u 20 bitni oladi va uni ishlatish haqida uzoq vaqtdan beri bahs-munozaralar mavjud. Bu juda qiziq - nizolar bor edi, RFC doirasida nimadir tuzatildi va shu bilan birga Linux yadrosida hech qachon hujjatlashtirilmagan dastur paydo bo'ldi.
Kichkina tergovga qo'shilishni taklif qilaman. Keling, so'nggi bir necha yil ichida Linux yadrosida nima sodir bo'lganini ko'rib chiqaylik.
2014 yil. Katta va nufuzli kompaniyaning muhandisi Linux yadrosining funksionalligiga oqim yorlig'i qiymatining rozetkaning xeshiga bog'liqligini qo'shadi. Ular bu erda nimani tuzatishga harakat qilmoqdalar? Bu quyidagi masalani muhokama qilgan RFC 6438 bilan bog'liq. Ma'lumotlar markazi ichida IPv4 ko'pincha IPv6 paketlarida inkapsullanadi, chunki zavodning o'zi IPv6, ammo IPv4 qandaydir tarzda berilishi kerak. Uzoq vaqt davomida TCP yoki UDP ga kirish va u erda src_ports, dst_ports topa olish uchun ikkita IP sarlavhasi ostiga qaray olmaydigan kalitlar bilan bog'liq muammolar mavjud edi. Ma'lum bo'lishicha, agar siz birinchi ikkita IP sarlavhasini ko'rsangiz, xesh deyarli tuzatilgan bo'lib chiqdi. Bunga yo'l qo'ymaslik uchun, bu kapsulalangan trafikni muvozanatlash to'g'ri ishlashi uchun, oqim yorlig'i maydonining qiymatiga 5 ta o'ralgan paketdan xeshni qo'shish taklif qilindi. Taxminan xuddi shunday boshqa inkapsulyatsiya sxemalari uchun ham amalga oshirildi, UDP uchun, GRE uchun, ikkinchisida GRE Key maydoni ishlatilgan. Bu erda qandaydir yoki boshqa maqsadlar aniq. Va hech bo'lmaganda o'sha paytda ular foydali edi.
2015 yilda yangi yamoq xuddi shu hurmatli muhandisdan keladi. U juda qiziq. Unda quyidagilar aytilgan - salbiy marshrutlash hodisasi bo'lsa, biz xeshni tasodifiy qilamiz. Salbiy marshrutlash hodisasi nima? Bu biz ilgari muhokama qilgan RTO, ya'ni deraza dumini yo'qotish haqiqatan ham salbiy hodisadir. To'g'ri, bu nima ekanligini taxmin qilish nisbatan qiyin.
2016, yana bir hurmatli kompaniya, shuningdek, katta. U oxirgi qo'ltiq tayoqchalarini tahlil qiladi va uni shunday qiladiki, biz avval tasodifiy qilgan xesh endi har bir SYN retransmitterida va har bir RTO taymoutidan keyin o'zgartiriladi. Va bu maktubda, birinchi va oxirgi marta, yakuniy maqsad yangraydi - yo'qolgan yoki kanallar haddan tashqari yuklangan taqdirda transport bir nechta yo'llardan foydalangan holda yumshoq yo'nalishni o'zgartirish imkoniyatiga ega ekanligiga ishonch hosil qilish. Albatta, bundan keyin juda ko'p nashrlar bor edi, ularni osongina topishingiz mumkin.
Yo'q bo'lsa ham, qila olmaysiz, chunki bu mavzu bo'yicha bitta nashr yo'q. Lekin bilamiz!
Va agar siz nima qilinganligini to'liq tushunmasangiz, men sizga hozir aytaman.
Nima qilindi, Linux yadrosiga qanday funksiyalar qo'shildi? txhash har bir RTO hodisasidan keyin tasodifiy qiymatga o'zgaradi. Bu bir xil salbiy marshrutlash natijasidir. Xesh bu txhashga bog'liq va oqim yorlig'i skb xeshga bog'liq. Bu erda funktsiyalar bo'yicha ba'zi hisob-kitoblar mavjud, barcha tafsilotlarni bitta slaydga joylashtirish mumkin emas. Agar kimdir qiziqsa, siz yadro kodidan o'tib, tekshirishingiz mumkin.
Bu erda nima muhim? Oqim yorlig'i maydonining qiymati har bir RTOdan keyin tasodifiy raqamga o'zgaradi. Bu bizning omadsiz TCP oqimimizga qanday ta'sir qiladi?
SACK holatida hech narsa o'zgarmadi, chunki biz ma'lum bo'lgan yo'qolgan paketni qayta yuborishga harakat qilmoqdamiz. Hozirgacha juda yaxshi.
Ammo RTO holatida, agar biz ToR-dagi xesh funktsiyasiga oqim yorlig'ini qo'shgan bo'lsak, trafik boshqa yo'nalishni egallashi mumkin. Va samolyotlar qanchalik ko'p bo'lsa, ma'lum bir qurilmadagi halokatga ta'sir qilmaydigan yo'lni topish ehtimoli ko'proq.
Bitta muammo qolmoqda - RTO. Boshqa marshrut, albatta, topiladi, lekin bunga ko'p vaqt sarflanadi. 200 ms juda ko'p. Ikkinchisi, odatda, vahshiylik. Avvalroq, men xizmatlarni sozlaydigan vaqt tugashlari haqida gapirgan edim. Shunday qilib, soniya odatda dastur darajasida xizmatni o'rnatadigan vaqt tugashidir va bunda xizmat hatto nisbatan to'g'ri bo'ladi. Bundan tashqari, takror aytaman, zamonaviy ma'lumotlar markazidagi haqiqiy RTT 1 millisekund atrofida.
RTO kutish vaqti haqida nima qilish mumkin? Ma'lumotlar paketlari yo'qolgan taqdirda RTO uchun javobgar bo'lgan kutish vaqti foydalanuvchi maydonidan nisbatan oson sozlanishi mumkin: IP yordam dasturi mavjud va uning parametrlaridan birida bir xil rto_min mavjud. Shuni hisobga olsak, albatta, siz RTO-ni global miqyosda aylantirishingiz kerak emas, lekin berilgan prefikslar uchun bunday mexanizm juda ishlayotgan ko'rinadi.
To'g'ri, SYN_RTO bilan hamma narsa biroz yomonroq. U tabiiy ravishda mixlangan. Qiymat yadroda o'rnatiladi - 1 soniya, va bu. Siz unga foydalanuvchi maydonidan kira olmaysiz. Faqat bitta yo'l bor.
eBPF yordamga keladi. Oddiy qilib aytadigan bo'lsak, bular kichik C dasturlari.Ular yadro stekini va TCP stekini bajarishda turli joylarda ilgaklarga kiritilishi mumkin, ular yordamida juda ko'p sonli sozlamalarni o'zgartirishingiz mumkin. Umuman olganda, eBPF uzoq muddatli tendentsiyadir. O'nlab yangi sysctl parametrlarini arralash va IP yordam dasturini kengaytirish o'rniga, harakat eBPF yo'nalishida va uning funksionalligini kengaytiradi. eBPF yordamida siz tirbandlikni boshqarish va boshqa turli TCP sozlamalarini dinamik ravishda o'zgartirishingiz mumkin.
Ammo biz uchun muhimi shundaki, uning yordamida siz SYN_RTO qiymatlarini burishingiz mumkin. Va ommaviy e'lon qilingan misol bor: . Bu yerda nima qilinadi? Misol ishlayapti, lekin o'zi juda qo'pol. Bu erda ma'lumotlar markazida biz birinchi 44 bitni solishtiramiz, agar ular mos kelsa, biz o'zimizni DC ichida topamiz deb taxmin qilinadi. Va bu holda, biz SYN_RTO kutish vaqtining qiymatini 4 ms ga o'zgartiramiz. Xuddi shu vazifani ancha nozik tarzda bajarish mumkin. Ammo bu oddiy misol nima ekanligini ko'rsatadi a) mumkin; b) nisbatan oson.
Biz allaqachon nimani bilamiz? Planar arxitektura masshtablash imkonini berishi, biz ToR-da oqim yorlig'ini yoqqanimizda va muammoli joylarni aylanib chiqish imkoniyatini qo'lga kiritganimizda, bu biz uchun juda foydali bo'lib chiqadi. RTO va SYN-RTO qiymatlarini pasaytirishning eng yaxshi usuli eBPF dasturlaridan foydalanishdir. Savol qoladi: muvozanat uchun oqim yorlig'idan foydalanish xavfsizmi? Va bu erda bir nuance bor.
Faraz qilaylik, sizda tarmoqda istalgan translatsiyada yashovchi xizmat mavjud. Afsuski, menda anycast haqida batafsil ma'lumot berishga vaqtim yo'q, lekin bu bir xil IP-manzilda turli jismoniy serverlar mavjud bo'lgan taqsimlangan xizmat. Va bu erda mumkin bo'lgan muammo: RTO hodisasi nafaqat transport zavod orqali o'tganda sodir bo'lishi mumkin. Bu ToR bufer darajasida ham sodir bo'lishi mumkin: incast hodisasi sodir bo'lganda, u xost biror narsani to'kib yuborganida ham paydo bo'lishi mumkin. RTO hodisasi sodir bo'lganda va u oqim yorlig'ini o'zgartirganda. Bunday holda, trafik boshqa istalgan translatsiya nusxasiga o'tishi mumkin. Aytaylik, bu har qanday statistik translatsiya, u ulanish holatini o'z ichiga oladi - bu L3 Balancer yoki boshqa xizmat bo'lishi mumkin. Keyin muammo paydo bo'ladi, chunki RTO dan keyin TCP ulanishi serverga keladi, bu TCP ulanishi haqida hech narsa bilmaydi. Va agar bizda har qanday serverlar o'rtasida davlat almashinuvi bo'lmasa, bunday trafik to'xtatiladi va TCP ulanishi uziladi.
Bu yerda nima qilish mumkin? Oqim yorlig'ini muvozanatlashni yoqadigan boshqariladigan muhitda istalgan translatsiya serverlariga kirishda oqim yorlig'i qiymatini tuzatishingiz kerak. Eng oson yo'li - buni bir xil eBPF dasturi orqali qilish. Ammo bu erda juda muhim nuqta - agar siz ma'lumotlar markazi tarmog'ini ishlatmasangiz, lekin aloqa operatori bo'lsangiz nima qilish kerak? Bu sizning muammoingiz ham: Juniper va Arista-ning ma'lum versiyalaridan boshlab, ular sukut bo'yicha xesh funktsiyasidagi oqim yorlig'ini o'z ichiga oladi - rostini aytsam, hech qanday sababsiz tushunaman. Bu sizning tarmog'ingiz orqali o'tadigan foydalanuvchilarning TCP ulanishlarini to'xtatishga olib kelishi mumkin. Shuning uchun men ushbu manzilda router sozlamalarini tekshirishni tavsiya etaman.
Qanday bo'lmasin, menimcha, biz tajribalarga o'tishga tayyormiz.
Biz ToR-da oqim yorlig'ini yoqqanimizda, agentning eBPF-ni tayyorladik, u hozir xostlarda yashaydi, biz keyingi katta muvaffaqiyatsizlikni kutmaslikka, balki boshqariladigan portlashlarni amalga oshirishga qaror qildik. Biz to'rtta yuqoriga ulanishi bo'lgan ToRni oldik va ulardan birida tomchilar qildik. Ular qoidani chizishdi, dedilar - endi siz barcha paketlarni yo'qotyapsiz. Chapda ko'rib turganingizdek, bizda har bir paketli monitoring mavjud bo'lib, u 75% ga kamaydi, ya'ni paketlarning 25% yo'qoladi. O'ng tomonda ushbu ToR ortida yashovchi xizmatlarning grafiklari mavjud. Aslida, bu raf ichidagi serverlar bilan bo'g'inlarning trafik grafiklari. Ko'rib turganingizdek, ular yanada pastga cho'kishdi. Nima uchun ular 25% ga emas, balki ba'zi hollarda 3-4 martaga pastroq cho'kishdi? Agar TCP ulanishi omadsiz bo'lsa, u buzilgan interfeys orqali kirishga urinishda davom etadi. Bu DC ichidagi xizmatning odatiy xatti-harakati bilan yanada kuchayadi - bitta foydalanuvchi so'rovi uchun ichki xizmatlarga N ta so'rov hosil bo'ladi va javob barcha ma'lumotlar manbalari javob berganda yoki vaqt tugashi boshlanganda foydalanuvchiga keladi. hali ham sozlanishi kerak bo'lgan dastur darajasi. Ya'ni, hamma narsa juda, juda yomon.
Endi xuddi shu tajriba, lekin oqim yorlig'i yoqilgan. Ko'rib turganingizdek, chap tomonda bizning ommaviy monitoringimiz xuddi shu 25% ga kamaydi. Bu mutlaqo to'g'ri, chunki u retranslyatsiyalar haqida hech narsa bilmaydi, u paketlarni jo'natadi va shunchaki etkazib berilgan va yo'qolgan paketlar sonining nisbatini hisoblaydi.
Va o'ng tomonda xizmatlar jadvali. Bu erda muammoli birikmaning ta'sirini topa olmaysiz. Xuddi shu millisekundlardagi trafik muammoli hududdan muammoga ta'sir qilmagan uchta yuqori ulanishga o'tdi. Bizda o'zini davolaydigan tarmoq mavjud.
Bu mening so'nggi slaydm, xulosa qilish vaqti. Endi, umid qilamanki, siz o'z-o'zidan tiklanadigan ma'lumotlar markazi tarmog'ini qanday qurishni bilasiz. Linux yadro arxividan o'tish va u erda maxsus yamoqlarni qidirishingiz shart emas, siz Flow yorlig'i bu holatda muammoni hal qilishini bilasiz, lekin siz ushbu mexanizmga ehtiyotkorlik bilan yondashishingiz kerak. Va yana bir bor ta'kidlaymanki, agar siz tashuvchi bo'lsangiz, oqim yorlig'ini xesh funktsiyasi sifatida ishlatmasligingiz kerak, aks holda siz foydalanuvchilar seanslarini buzasiz.
Tarmoq muhandislari uchun kontseptual siljish sodir bo'lishi kerak: tarmoq ToR bilan emas, tarmoq qurilmasi bilan emas, balki xost bilan boshlanadi. Juda yorqin misol, biz RTO-ni o'zgartirish va istalgan translatsiya xizmatlariga oqim yorlig'ini tuzatish uchun eBPF-dan qanday foydalanamiz.
Oqim yorlig'i mexanikasi, albatta, boshqariladigan ma'muriy segmentdagi boshqa maqsadlar uchun mos keladi. Bu ma'lumotlar markazlari orasidagi trafik bo'lishi mumkin yoki siz chiquvchi trafikni boshqarish uchun bunday mexanikadan maxsus tarzda foydalanishingiz mumkin. Ammo keyingi safar bu haqda gaplashaman, umid qilamanki. E'tiboringiz uchun katta rahmat.
Manba: www.habr.com