Ko'p odamlar Elasticsearch bilan kurashmoqda. Ammo uni jurnallarni "ayniqsa katta hajmda" saqlash uchun ishlatmoqchi bo'lsangiz nima bo'ladi? Va bir nechta ma'lumotlar markazlaridan birining ishdan chiqishini boshdan kechirish ham og'riqsizmi? Qanday me'morchilikni yaratishingiz kerak va qanday tuzoqlarga duch kelasiz?
Biz Odnoklassniki-da jurnallarni boshqarish muammosini hal qilish uchun elasticsearch-dan foydalanishga qaror qildik va endi biz Habr bilan tajribamiz bilan o'rtoqlashamiz: arxitektura va tuzoqlar haqida.
Men Pyotr Zaitsev, men Odnoklassniki-da tizim administratori bo'lib ishlayman. Undan oldin men ham administrator edim, Manticore Search, Sphinx search, Elasticsearch bilan ishlaganman. Ehtimol, agar boshqa ... qidiruv paydo bo'lsa, men ham u bilan ishlayman. Shuningdek, men ixtiyoriy ravishda bir qator ochiq manba loyihalarida ishtirok etaman.
Odnoklassniki-ga kelganimda, intervyuda beparvolik bilan Elasticsearch bilan ishlashim mumkinligini aytdim. Men buni o'rganib, oddiy vazifalarni bajarganimdan so'ng, menga o'sha paytda mavjud bo'lgan jurnallarni boshqarish tizimini isloh qilish bo'yicha katta vazifa berildi.
talablar
Tizim talablari quyidagicha shakllantirildi:
- Graylog frontend sifatida ishlatilishi kerak edi. Kompaniya ushbu mahsulotni ishlatish tajribasiga ega bo'lganligi sababli, dasturchilar va testerlar buni bilishgan, ular uchun tanish va qulay edi.
- Ma'lumotlar hajmi: soniyada o'rtacha 50-80 ming xabar, lekin agar biror narsa buzilgan bo'lsa, u holda trafik hech narsa bilan cheklanmaydi, soniyada 2-3 million satr bo'lishi mumkin
- Mijozlar bilan qidiruv so'rovlarini qayta ishlash tezligiga qo'yiladigan talablarni muhokama qilib, biz bunday tizimdan foydalanishning odatiy namunasi ekanligini tushundik: odamlar so'nggi ikki kun ichida o'z arizalari jurnallarini qidirmoqdalar va bir soatdan ortiq kutishni xohlamaydilar. ikkinchisi tuzilgan so'rov natijasi uchun.
- Administratorlar, agar kerak bo'lsa, tizim qanday ishlashini chuqur o'rganishni talab qilmasdan, osonlik bilan kengaytirilishini talab qilishdi.
- Shunday qilib, ushbu tizimlar vaqti-vaqti bilan talab qiladigan yagona texnik xizmat ba'zi bir uskunani o'zgartirishdir.
- Bundan tashqari, Odnoklassniki ajoyib texnik an'anaga ega: biz ishga tushiradigan har qanday xizmat ma'lumotlar markazining ishdan chiqishidan (to'satdan, rejalashtirilmagan va istalgan vaqtda) omon qolishi kerak.
Ushbu loyihani amalga oshirishdagi oxirgi talab biz uchun eng qimmatga tushdi, men bu haqda batafsilroq gaplashaman.
o'rta
Biz to'rtta ma'lumot markazida ishlaymiz, Elasticsearch ma'lumotlar tugunlari esa faqat uchtasida joylashgan bo'lishi mumkin (bir qancha texnik bo'lmagan sabablarga ko'ra).
Ushbu to'rtta ma'lumot markazlarida taxminan 18 ming xil jurnal manbalari mavjud - apparat, konteynerlar, virtual mashinalar.
Muhim xususiyat: klaster konteynerlarda boshlanadi jismoniy mashinalarda emas, balki . Konteynerlarga 2 gigagertsli v2.0 ga o'xshash 4 yadro kafolatlanadi, agar ular bo'sh turgan bo'lsa, qolgan yadrolarni qayta ishlash imkoniyati mavjud.
Boshqa so'zlar bilan aytganda:
Topologiya
Men dastlab yechimning umumiy shaklini quyidagicha ko'rdim:
- Graylog domenining A-yozuvining orqasida 3-4 VIP turadi, bu jurnallar yuboriladigan manzil.
- har bir VIP LVS balanschisi hisoblanadi.
- Shundan so'ng, jurnallar Graylog batareyasiga o'tadi, ma'lumotlarning bir qismi GELF formatida, ba'zilari esa syslog formatida.
- Keyin bularning barchasi katta partiyalarda Elasticsearch koordinatorlari batareyasiga yoziladi.
- Va ular, o'z navbatida, tegishli ma'lumotlar tugunlariga yozish va o'qish so'rovlarini yuboradilar.
Terminologiya
Ehtimol, hamma ham terminologiyani batafsil tushunmaydi, shuning uchun men bu haqda bir oz to'xtalib o'tmoqchiman.
Elasticsearch bir necha turdagi tugunlarga ega - master, koordinator, ma'lumotlar tugunlari. Turli xil jurnallarni o'zgartirish va turli klasterlar o'rtasidagi aloqa uchun yana ikkita tur mavjud, ammo biz faqat sanab o'tilganlardan foydalandik.
usta
U klasterda mavjud bo'lgan barcha tugunlarni tekshiradi, zamonaviy klaster xaritasini yuritadi va uni tugunlar o'rtasida taqsimlaydi, voqea mantiqini qayta ishlaydi va klaster bo'ylab har xil turdagi uy ishlarini bajaradi.
Koordinator
Bitta vazifani bajaradi: mijozlardan o'qish yoki yozish so'rovlarini qabul qiladi va ushbu trafikni yo'naltiradi. Agar yozish so'rovi bo'lsa, u ustadan uni tegishli indeksning qaysi qismiga qo'yish kerakligini so'raydi va so'rovni boshqa yo'naltiradi.
Ma'lumotlar tugunlari
Ma'lumotlarni saqlaydi, tashqaridan kelgan qidiruv so'rovlarini bajaradi va unda joylashgan parchalar bilan operatsiyalarni bajaradi.
Greylog
Bu ELK stekidagi Logstash bilan Kibana sinteziga o'xshaydi. Graylog UI va jurnalni qayta ishlash quvurlarini birlashtiradi. Kaput ostida Graylog Kafka va Zookeeper-ni boshqaradi, ular Graylogga klaster sifatida ulanishni ta'minlaydi. Elasticsearch mavjud bo'lmaganda Graylog jurnallarni (Kafka) keshlashi va muvaffaqiyatsiz o'qish va yozish so'rovlarini takrorlashi, belgilangan qoidalarga muvofiq jurnallarni guruhlashi va belgilashi mumkin. Logstash singari, Graylog ham qatorlarni Elasticsearch-ga yozishdan oldin ularni o'zgartirish funksiyasiga ega.
Bundan tashqari, Graylog bir mavjud Elasticsearch tuguniga asoslanib, butun klaster xaritasini olish va uni ma'lum bir teg bo'yicha filtrlash imkonini beruvchi o'rnatilgan xizmat kashfiyotiga ega, bu esa so'rovlarni muayyan konteynerlarga yo'naltirish imkonini beradi.
Vizual ravishda bu shunday ko'rinadi:
Bu ma'lum bir misoldan olingan skrinshot. Bu erda biz qidiruv so'rovi asosida gistogramma quramiz va tegishli qatorlarni ko'rsatamiz.
Ko'rsatkichlar
Tizim arxitekturasiga qaytsak, men indeks modelini barchasi to'g'ri ishlashi uchun qanday qurganimiz haqida batafsilroq to'xtalib o'tmoqchiman.
Yuqoridagi diagrammada bu eng past daraja: Elasticsearch ma'lumotlar tugunlari.
Indeks - bu Elasticsearch parchalaridan tashkil topgan yirik virtual ob'ekt. O'z-o'zidan, har bir parcha Lucene indeksidan boshqa narsa emas. Va har bir Lucene indeksi, o'z navbatida, bir yoki bir nechta segmentlardan iborat.
Loyihalashda biz katta hajmdagi ma'lumotlarni o'qish tezligiga bo'lgan talabni qondirish uchun ushbu ma'lumotlarni ma'lumotlar tugunlari bo'ylab teng ravishda "tarqatishimiz" kerakligini tushundik.
Bu shuni ko'rsatdiki, har bir indeksdagi parchalar soni (replikatsiyalar bilan) ma'lumotlar tugunlari soniga qat'iy teng bo'lishi kerak. Birinchidan, ikkiga teng replikatsiya koeffitsientini ta'minlash uchun (ya'ni, biz klasterning yarmini yo'qotishimiz mumkin). Va, ikkinchidan, klasterning kamida yarmida o'qish va yozish so'rovlarini qayta ishlash uchun.
Biz birinchi navbatda saqlash muddatini 30 kun deb belgiladik.
Shardlarning taqsimlanishini grafik tarzda quyidagicha ko'rsatish mumkin:
Butun quyuq kulrang to'rtburchaklar indeksdir. Undagi chap qizil kvadrat asosiy parcha, indeksdagi birinchi. Va ko'k kvadrat - bu replika parchasi. Ular turli ma'lumotlar markazlarida joylashgan.
Yana bir parcha qo'shsak, u uchinchi ma'lumotlar markaziga o'tadi. Va nihoyat, biz ushbu tuzilmani olamiz, bu esa ma'lumotlarning mustahkamligini yo'qotmasdan DCni yo'qotish imkonini beradi:
Indekslarning aylanishi, ya'ni. yangi indeks yaratish va eng eskisini o'chirish, biz uni 48 soatga tenglashtirdik (indeksdan foydalanish naqshiga ko'ra: oxirgi 48 soat eng ko'p qidiriladi).
Ushbu indeks aylanish oralig'i quyidagi sabablarga ko'ra yuzaga keladi:
Qidiruv so'rovi ma'lum bir ma'lumot tuguniga kelganda, unumdorlik nuqtai nazaridan, agar uning o'lchami tugunning kestirib, o'lchami bilan taqqoslansa, bitta parcha so'ralganda foydaliroq bo'ladi. Bu sizga indeksning "issiq" qismini to'plamda saqlash va unga tezda kirish imkonini beradi. Ko'p "issiq qismlar" mavjud bo'lganda, indekslarni qidirish tezligi pasayadi.
Tugun bir parcha bo'yicha qidiruv so'rovini bajarishni boshlaganida, u jismoniy mashinaning giper-mavjud yadrolari soniga teng bo'lgan qatorlarni ajratadi. Agar qidiruv so'rovi ko'p sonli parchalarga ta'sir qilsa, u holda iplar soni mutanosib ravishda o'sadi. Bu qidiruv tezligiga salbiy ta'sir qiladi va yangi ma'lumotlarni indekslashga salbiy ta'sir qiladi.
Kerakli qidiruv kechikishini ta'minlash uchun biz SSD-dan foydalanishga qaror qildik. So'rovlarni tezda qayta ishlash uchun ushbu konteynerlarni joylashtirgan mashinalar kamida 56 yadroga ega bo'lishi kerak edi. 56 raqami shartli etarli qiymat sifatida tanlangan, bu Elasticsearch ish paytida yaratadigan iplar sonini aniqlaydi. Elasitcsearch-da ko'plab iplar pulining parametrlari to'g'ridan-to'g'ri mavjud yadrolar soniga bog'liq, bu esa o'z navbatida "kamroq yadro - ko'proq tugun" tamoyiliga muvofiq klasterdagi kerakli tugunlar soniga bevosita ta'sir qiladi.
Natijada, biz bir parchaning o'rtacha og'irligi taxminan 20 gigabayt ekanligini va har bir indeksda 1 ta parcha borligini aniqladik. Shunga ko'ra, agar biz ularni har 360 soatda bir marta aylantirsak, bizda ularning 48 tasi bor. Har bir indeks 15 kunlik ma'lumotlarni o'z ichiga oladi.
Ma'lumotlarni yozish va o'qish sxemalari
Keling, ushbu tizimda ma'lumotlar qanday qayd etilishini aniqlaylik.
Aytaylik, Graylogdan koordinatorga qandaydir so'rov keldi. Misol uchun, biz 2-3 ming qatorni indekslashni xohlaymiz.
Graylogdan so'rovni olgan koordinator ustadan so'raydi: "Indekslash so'rovida biz indeksni aniq belgilab qo'ydik, ammo uni qaysi qismga yozish ko'rsatilmagan".
Magistr javob beradi: "Ushbu ma'lumotni 71-sonli shardga yozing", shundan so'ng u to'g'ridan-to'g'ri 71-sonli asosiy parcha joylashgan tegishli ma'lumotlar tuguniga yuboriladi.
Shundan so'ng, tranzaktsiyalar jurnali boshqa ma'lumotlar markazida joylashgan replika-shardga takrorlanadi.
Graylogdan koordinatorga qidiruv so'rovi keladi. Koordinator uni indeks bo'yicha qayta yo'naltiradi, Elasticsearch esa so'rovlarni round-robin printsipidan foydalangan holda asosiy-shard va replika-shard o'rtasida taqsimlaydi.
180 ta tugun notekis javob beradi va ular javob berayotganda koordinator tezroq ma'lumotlar tugunlari tomonidan allaqachon "tupurilgan" ma'lumotlarni to'playdi. Shundan so'ng, barcha ma'lumotlar kelganda yoki so'rov kutish vaqtiga etganida, u hamma narsani to'g'ridan-to'g'ri mijozga beradi.
Bu butun tizim oxirgi 48 soat davomida qidiruv soʻrovlarini oʻrtacha 300-400 ms tezlikda qayta ishlaydi, bunda yetakchi joker belgisi boʻlgan soʻrovlar bundan mustasno.
Elasticsearch bilan gullar: Java sozlamalari
Bularning barchasi biz xohlagan tarzda ishlashi uchun biz klasterdagi turli xil narsalarni tuzatish uchun juda uzoq vaqt sarfladik.
Topilgan muammolarning birinchi qismi Java-ning Elasticsearch-da sukut bo'yicha oldindan sozlanishi bilan bog'liq edi.
Muammo birinchi
Biz juda ko'p sonli hisobotlarni ko'rdikki, Lucene darajasida fon ishlari bajarilayotganda Lucene segmentini birlashtirish xatolik bilan bajarilmaydi. Shu bilan birga, jurnallarda bu OutOfMemoryError xatosi ekanligi aniq edi. Biz telemetriyadan kestirib, bo'sh ekanligini ko'rdik va bu operatsiya nima uchun muvaffaqiyatsizlikka uchragani aniq emas edi.
Ma'lum bo'lishicha, Lucene indeksining birlashishi kestirib, tashqarida sodir bo'ladi. Va konteynerlar iste'mol qilinadigan resurslar nuqtai nazaridan juda cheklangan. Ushbu resurslarga faqat yig'ma to'p sig'ishi mumkin edi (heap.size qiymati taxminan RAMga teng edi) va ba'zi bir yig'indidan tashqari operatsiyalar, agar biron sababga ko'ra chegaradan oldin qolgan ~500MB ga mos kelmasa, xotira ajratish xatosi bilan qulab tushdi.
Tuzatish juda ahamiyatsiz edi: konteyner uchun mavjud RAM miqdori oshirildi, shundan so'ng biz hatto bunday muammolarga duch kelganimizni unutdik.
Ikkinchi muammo
Klaster ishga tushirilgandan 4-5 kun o'tgach, biz ma'lumotlar tugunlari vaqti-vaqti bilan klasterdan tushib keta boshlaganini va 10-20 soniyadan keyin unga kira boshlaganini payqadik.
Biz buni aniqlay boshlaganimizda, Elasticsearch-dagi bu yig'indisi xotira hech qanday tarzda boshqarilmagani ma'lum bo'ldi. Konteynerga ko'proq xotira berganimizda, biz to'g'ridan-to'g'ri bufer hovuzlarini turli xil ma'lumotlar bilan to'ldirishga muvaffaq bo'ldik va u Elasticsearch-dan aniq GC ishga tushirilgandan keyingina tozalandi.
Ba'zi hollarda, bu operatsiya ancha uzoq davom etdi va shu vaqt ichida klaster ushbu tugunni allaqachon chiqib ketgan deb belgilashga muvaffaq bo'ldi. Bu muammo yaxshi tasvirlangan .
Yechim quyidagicha edi: biz Java-ning ushbu operatsiyalar uchun xotiraning katta qismini yig'ishdan tashqarida ishlatish qobiliyatini chekladik. Biz uni 16 gigabayt bilan chekladik (-XX:MaxDirectMemorySize=16g), aniq GC tez-tez chaqirilishini va tezroq qayta ishlanishini ta'minladik va shu bilan klasterni endi beqarorlashtirmaydi.
Uchinchi muammo
Agar siz "klasterni eng kutilmagan daqiqada tark etadigan tugunlar" bilan bog'liq muammolar tugadi deb o'ylasangiz, adashasiz.
Indekslar bilan ishlashni sozlaganimizda, biz mmapfs ni tanladik ajoyib segmentatsiyaga ega yangi parchalarda. Bu juda qo'pol xato edi, chunki mmapf-dan foydalanganda fayl RAMga joylashtiriladi va keyin biz xaritalangan fayl bilan ishlaymiz. Shu sababli, ma'lum bo'lishicha, GC ilovadagi mavzularni to'xtatishga harakat qilganda, biz uzoq vaqt davomida xavfsiz nuqtaga boramiz va unga boradigan yo'lda, dastur uning tirik yoki yo'qligi haqidagi masterning so'rovlariga javob berishni to'xtatadi. . Shunga ko'ra, usta tugun endi klasterda mavjud emas deb hisoblaydi. Shundan so'ng, 5-10 soniyadan so'ng, axlat yig'uvchi ishlaydi, tugun jonlanadi, yana klasterga kiradi va parchalarni ishga tushirishni boshlaydi. Bularning barchasi "biz loyiq bo'lgan ishlab chiqarish" kabi tuyuldi va jiddiy narsa uchun mos emas edi.
Ushbu xatti-harakatdan xalos bo'lish uchun biz birinchi navbatda standart nioflarga o'tdik, so'ngra Elasticning beshinchi versiyasidan oltinchi versiyasiga ko'chib o'tganimizda, biz gibridlarni sinab ko'rdik, bu erda bu muammo takrorlanmadi. Saqlash turlari haqida ko'proq o'qishingiz mumkin .
To'rtinchi muammo
Keyin yana bir juda qiziqarli muammo bor edi, biz uni rekord vaqt ichida hal qildik. Biz uni 2-3 oy davomida ushladik, chunki uning namunasi mutlaqo tushunarsiz edi.
Ba'zida bizning koordinatorlarimiz to'liq GCga borishdi, odatda tushlikdan keyin, va u erdan qaytib kelmadilar. Shu bilan birga, GC kechikishini ro'yxatga olishda shunday ko'rinardi: hamma narsa yaxshi, yaxshi, yaxshi, keyin esa birdan hamma narsa juda yomon ketmoqda.
Avvaliga biz koordinatorni ish rejimidan chiqarib yuboradigan so'rovni boshlagan yovuz foydalanuvchimiz bor deb o'yladik. Biz so'rovlarni juda uzoq vaqt davomida qayd etib, nima bo'layotganini aniqlashga harakat qildik.
Natijada, foydalanuvchi katta so'rovni ishga tushirganda va u ma'lum bir Elasticsearch koordinatoriga tushganda, ba'zi tugunlar boshqalarga qaraganda uzoqroq javob berishi ma'lum bo'ldi.
Va koordinator barcha tugunlardan javob kutayotganda, u allaqachon javob bergan tugunlardan yuborilgan natijalarni to'playdi. GC uchun bu bizning yig'ma foydalanish naqshlarimiz juda tez o'zgarishini anglatadi. Va biz foydalangan GC bu vazifani bajara olmadi.
Bu vaziyatda klasterning xatti-harakatlarini o'zgartirish uchun biz topgan yagona tuzatish JDK13 ga o'tish va Shenandoah axlat yig'uvchisidan foydalanishdir. Bu muammoni hal qildi, koordinatorlarimiz tushishni to'xtatdi.
Bu erda Java bilan bog'liq muammolar tugadi va tarmoqli kengligi muammolari boshlandi.
Elasticsearch bilan "rezavorlar": o'tkazish qobiliyati
O'tkazish qobiliyati bilan bog'liq muammolar bizning klasterimiz barqaror ishlashini anglatadi, ammo indekslangan hujjatlar sonining eng yuqori cho'qqisida va manevrlar paytida ishlash etarli emas.
To'qnash kelgan birinchi alomat: ishlab chiqarishdagi ba'zi "portlashlar" paytida, to'satdan juda ko'p sonli jurnallar hosil bo'lganda, Graylog-da es_rejected_execution indekslash xatosi tez-tez yonib-o'chib turadi.
Buning sababi, bitta ma'lumot tugunidagi thread_pool.write.queue, Elasticsearch indekslash so'rovini qayta ishlash va ma'lumotlarni diskdagi parchaga yuklash imkoniyatiga ega bo'lgunga qadar, sukut bo'yicha faqat 200 ta so'rovni keshlashi mumkin. Va ichida Ushbu parametr haqida juda kam narsa aytilgan. Faqat iplarning maksimal soni va standart o'lcham ko'rsatilgan.
Albatta, biz ushbu qiymatni burish uchun bordik va quyidagilarni bilib oldik: xususan, bizning sozlashimizda 300 ga yaqin so'rovlar juda yaxshi keshlangan va yuqoriroq qiymat biz yana Full GC ga uchishimiz bilan to'la.
Bunga qo'shimcha ravishda, bular bitta so'rovda keladigan xabarlar to'plami bo'lganligi sababli, Graylog-ni tez-tez va kichik to'plamlarda emas, balki katta to'plamlarda yoki agar to'plam hali ham to'liq bo'lmasa, har 3 soniyada bir marta yozishi uchun sozlash kerak edi. Bunday holda, biz Elasticsearch-da yozadigan ma'lumotlar ikki soniyada emas, balki besh soniyada (bu bizga juda mos keladi), lekin katta hajmdagi ma'lumotlarni bosib o'tish uchun qilish kerak bo'lgan takrorlash soniga ega bo'ladi. ma'lumotlar to'plami kamayadi.
Bu, ayniqsa, biror joyda biror narsa qulab tushgan va bu haqda g'azab bilan xabar bergan paytlarda, to'liq spamlangan Elastikni va bir muncha vaqt o'tgach - tiqilib qolgan buferlar tufayli ishlamay qolgan Graylog tugunlarini olmaslik uchun juda muhimdir.
Bundan tashqari, ishlab chiqarishda xuddi shunday portlashlar sodir bo'lganida, biz dasturchilar va sinovchilardan shikoyatlar oldik: ular haqiqatan ham ushbu jurnallarga muhtoj bo'lgan paytda, ularga juda sekin berildi.
Ular buni aniqlay boshladilar. Bir tomondan, qidiruv so'rovlari ham, indekslash so'rovlari ham bir xil jismoniy mashinalarda qayta ishlanishi va u yoki bu tarzda ma'lum kamchiliklar bo'lishi aniq edi.
Ammo buni qisman chetlab o'tish mumkin edi, chunki Elasticsearch-ning oltinchi versiyalarida so'rovlarni tasodifiy aylanish printsipiga ko'ra emas, balki tegishli ma'lumotlar tugunlari o'rtasida taqsimlash imkonini beruvchi algoritm paydo bo'ldi (indekslash bilan shug'ullanadigan va birlamchi ma'lumotlarni saqlaydigan konteyner). shard juda band bo'lishi mumkin, tezda javob berishning iloji bo'lmaydi), lekin bu so'rovni tezroq javob beradigan replika-shardli kamroq yuklangan konteynerga yuborish uchun. Boshqacha qilib aytganda, biz use_adaptive_replica_selection ga yetib keldik: rost.
O'qish rasmi quyidagicha ko'rinishni boshlaydi:
Ushbu algoritmga o'tish biz yozish uchun katta jurnallar oqimiga ega bo'lgan paytlarda so'rov vaqtini sezilarli darajada yaxshilash imkonini berdi.
Nihoyat, asosiy muammo ma'lumotlar markazini og'riqsiz olib tashlash edi.
Bitta DC bilan aloqani yo'qotganimizdan so'ng darhol klasterdan nimani xohladik:
- Agar bizda muvaffaqiyatsiz ma'lumotlar markazida joriy master mavjud bo'lsa, u qayta tanlanadi va rol sifatida boshqa DCdagi boshqa tugunga o'tkaziladi.
- Magistr tezda barcha kirish mumkin bo'lmagan tugunlarni klasterdan olib tashlaydi.
- Qolganlariga asoslanib, u tushunadi: yo'qolgan ma'lumotlar markazida bizda falon va shunga o'xshash asosiy qismlar bor edi, u qolgan ma'lumotlar markazlarida tezda qo'shimcha replika parchalarini targ'ib qiladi va biz ma'lumotlarni indekslashni davom ettiramiz.
- Natijada, klasterning yozish va o'qish qobiliyati asta-sekin pasayadi, lekin umuman olganda, hamma narsa asta-sekin, lekin barqaror ishlaydi.
Ma'lum bo'lishicha, biz shunga o'xshash narsani xohladik:
Va biz quyidagilarni oldik:
Bu qanday sodir bo'ldi?
Ma'lumotlar markazi yiqilib tushganda, bizning xo'jayinimiz darboğazga aylandi.
Почему?
Gap shundaki, ustada klasterdagi muayyan vazifalar va hodisalarni tarqatish uchun mas'ul bo'lgan TaskBatcher mavjud. Har qanday tugundan chiqish, parchani replikadan asosiyga ko'tarish, biror joyda parcha yaratish bo'yicha har qanday vazifa - bularning barchasi birinchi navbatda TaskBatcher-ga o'tadi, u erda u ketma-ket va bitta ipda qayta ishlanadi.
Bitta ma'lumot markazi bekor qilinganda, ma'lum bo'lishicha, omon qolgan ma'lumotlar markazlaridagi barcha ma'lumotlar tugunlari ustaga "biz falon qismlarni va falon ma'lumotlar tugunlarini yo'qotdik" deb xabar berishni o'z burchi deb hisoblagan.
Shu bilan birga, omon qolgan ma'lumotlar tugunlari ushbu ma'lumotlarning barchasini joriy ustaga yubordi va u buni qabul qilganligini tasdiqlashni kutishga harakat qildi. Ular buni kutishmadi, chunki usta topshiriqlarni javob berishdan tezroq oldi. Tugunlar takroriy so'rovlarni o'z vaqtida tugatdi va bu vaqtda usta ularga javob berishga harakat ham qilmadi, lekin so'rovlarni ustuvorlik bo'yicha saralash vazifasi bilan to'liq shug'ullangan.
Terminal shaklida ma'lum bo'lishicha, ma'lumotlar tugunlari masterga spam yuborgan va u to'liq GC ga o'tgan. Shundan so'ng, bizning asosiy rolimiz keyingi tugunga o'tdi, u bilan mutlaqo bir xil narsa sodir bo'ldi va natijada klaster butunlay qulab tushdi.
Biz o'lchovlarni oldik va bu tuzatilgan 6.4.0 versiyasidan oldin, klasterni to'liq o'chirish uchun bir vaqtning o'zida 10 tadan atigi 360 ta ma'lumot tugunini chiqarish kifoya edi.
Bu shunday ko'rinardi:
Ushbu dahshatli xatolik tuzatilgan 6.4.0 versiyasidan so'ng, ma'lumotlar tugunlari ustani o'ldirishni to'xtatdi. Ammo bu uni "aqlli" qilmadi. Ya'ni: biz 2, 3 yoki 10 (birdan boshqa har qanday raqam) ma'lumotlar tugunlarini chiqarganimizda, usta A tugunni tark etganligi haqida birinchi xabarni oladi va bu haqda B tuguniga, C tuguniga, D tuguniga aytishga harakat qiladi.
Va hozirda buni faqat kimgadir biror narsa haqida aytishga urinishlar uchun 20-30 soniyaga teng vaqtni belgilash va shu tariqa ma'lumotlar markazining klasterdan chiqib ketish tezligini boshqarish orqali hal qilish mumkin.
Aslida, bu loyihaning bir qismi sifatida yakuniy mahsulotga dastlab taqdim etilgan talablarga mos keladi, ammo "sof fan" nuqtai nazaridan bu xato. Aytgancha, ishlab chiquvchilar tomonidan 7.2 versiyasida muvaffaqiyatli tuzatilgan.
Bundan tashqari, ma'lum bir ma'lumot tugunlari chiqib ketganda, uning chiqishi haqidagi ma'lumotni tarqatish butun klasterga unda falon va shunga o'xshash birlamchi parchalar mavjudligini aytishdan ko'ra muhimroq ekanligi ma'lum bo'ldi (boshqa ma'lumotlarda replika-shardni targ'ib qilish uchun). markazda boshlang'ich va ma'lumotlarda ular ustida yozilishi mumkin).
Shuning uchun, hamma narsa allaqachon o'lganida, chiqarilgan ma'lumotlar tugunlari darhol eskirgan deb belgilanmaydi. Shunga ko'ra, biz barcha pinglar bo'shatilgan ma'lumotlar tugunlariga tugaguncha kutishga majbur bo'lamiz va shundan keyingina bizning klasterimiz bizga u erda, u erda va u erda ma'lumot yozishni davom ettirishimiz kerakligini aytishni boshlaydi. Bu haqda ko'proq o'qishingiz mumkin .
Natijada, ma'lumotlar markazini olib tashlash operatsiyasi bugungi kunda bizni tirbandlik vaqtida taxminan 5 daqiqa vaqt oladi. Bunday katta va noqulay kolossus uchun bu juda yaxshi natija.
Natijada biz quyidagi qarorga keldik:
- Bizda 360 gigabayt diskli 700 ma'lumot tugunlari mavjud.
- Xuddi shu ma'lumotlar tugunlari orqali trafikni yo'naltirish uchun 60 ta koordinator.
- 40 dan oldingi versiyalardan beri biz o'ziga xos meros sifatida qoldirgan 6.4.0 ta usta - ma'lumotlar markazi olib qo'yilgandan keyin omon qolish uchun biz hatto magistrlar kvorumiga ega bo'lish kafolatiga ega bo'lish uchun bir nechta mashinalarni yo'qotishga aqlan tayyor edik. eng yomon stsenariy
- Rollarni bitta konteynerda birlashtirishga bo'lgan har qanday urinishlar ertami-kechmi tugun yuk ostida sinishi bilan uchrashdi.
- Butun klaster 31 gigabayt hajmdagi yig'ma o'lchamdan foydalanadi: o'lchamni kamaytirishga bo'lgan barcha urinishlar og'ir qidiruv so'rovlaridagi ba'zi tugunlarni etakchi joker belgisi bilan o'ldirishga yoki Elasticsearch-ning o'zida elektron to'xtatuvchini olishga olib keldi.
- Bundan tashqari, qidiruv samaradorligini ta'minlash uchun biz masterda mavjud bo'lgan darboğazda imkon qadar kamroq hodisalarni qayta ishlash uchun klasterdagi ob'ektlar sonini iloji boricha kamroq saqlashga harakat qildik.
Nihoyat, monitoring haqida
Bularning barchasi maqsadga muvofiq ishlashini ta'minlash uchun biz quyidagilarni kuzatamiz:
- Har bir ma'lumot tugunlari bizning bulutimizga uning mavjudligi haqida xabar beradi va unda falon qismlar mavjud. Biz biror joyda biror narsani o'chirganda, klaster 2-3 soniyadan so'ng A markazida biz 2, 3 va 4 tugunlarni o'chirgani haqida xabar beradi - bu boshqa ma'lumotlar markazlarida biz hech qanday holatda faqat bitta parcha bo'lgan tugunlarni o'chira olmaymiz degan ma'noni anglatadi. chap.
- Usta xulq-atvorining mohiyatini bilib, biz kutilayotgan vazifalar soniga juda ehtiyotkorlik bilan qaraymiz. Chunki hatto bitta tiqilib qolgan vazifa, agar u o'z vaqtida tugamasa, nazariy jihatdan ba'zi bir favqulodda vaziyatlarda, masalan, birlamchida replika parchasini ilgari surish ishlamasligiga sabab bo'lishi mumkin, shuning uchun indekslash ishlamay qoladi.
- Shuningdek, biz axlat yig'uvchilarning kechikishlariga diqqat bilan qaraymiz, chunki optimallashtirish jarayonida biz allaqachon bu bilan katta qiyinchiliklarga duch kelganmiz.
- Qaerda qiyinchilik borligini oldindan tushunish uchun ip bilan rad etadi.
- Xo'sh, uyum, RAM va I/U kabi standart ko'rsatkichlar.
Monitoringni yaratishda siz Elasticsearch-dagi Thread Pool-ning xususiyatlarini hisobga olishingiz kerak. Qidiruv va indekslash uchun konfiguratsiya parametrlari va standart qiymatlarini tavsiflaydi, lekin thread_pool.management haqida mutlaqo jim.Bu mavzular, xususan, _cat/shards va boshqa shunga o'xshash so'rovlarni qayta ishlaydi, ulardan monitoring yozishda foydalanish qulay. Klaster qanchalik katta bo'lsa, vaqt birligida shunchalik ko'p so'rovlar bajariladi va yuqorida aytib o'tilgan thread_pool.management nafaqat rasmiy hujjatlarda ko'rsatilmaydi, balki sukut bo'yicha 5 ta mavzu bilan cheklangan bo'lib, ular tezda yo'q qilinadi. qaysi monitoring to'g'ri ishlashni to'xtatadi.
Xulosa qilib aytmoqchi bo'lgan narsa: biz buni qildik! Biz dasturchilarimiz va ishlab chiquvchilarimizga deyarli har qanday vaziyatda ishlab chiqarishda sodir bo'layotgan voqealar haqida tez va ishonchli ma'lumot bera oladigan vositani bera oldik.
Ha, bu juda murakkab bo'lib chiqdi, lekin shunga qaramay, biz o'z istaklarimizni mavjud mahsulotlarga moslashtira oldik, ularni o'zimiz uchun tuzatish va qayta yozishimiz shart emas edi.
Manba: www.habr.com