Олон хүмүүс Elasticsearch-тэй тэмцдэг. Гэхдээ үүнийг "их хэмжээний" лог хадгалахад ашиглахыг хүсвэл юу болох вэ? Мөн хэд хэдэн мэдээллийн төвийн аль нэг нь бүтэлгүйтэх нь өвдөлтгүй гэж үү? Та ямар төрлийн архитектур хийх ёстой вэ, ямар бэрхшээл тулгардаг вэ?
Одноклассники дахь бид бүртгэлийн менежментийн асуудлыг шийдэхийн тулд elasticsearch ашиглахаар шийдсэн бөгөөд одоо бид архитектурын талаар болон алдаа дутагдлын талаар Хабртай туршлагаа хуваалцаж байна.
Би бол Петр Зайцев, би Одноклассники сайтад системийн администратороор ажилладаг. Үүнээс өмнө би бас админ байсан, Manticore Search, Sphinx search, Elasticsearch-тай ажиллаж байсан. Магадгүй, хэрэв өөр ... хайлт гарч ирвэл би ч бас түүнтэй ажиллах болно. Би бас сайн дурын үндсэн дээр хэд хэдэн нээлттэй эхийн төслүүдэд оролцдог.
Би Одноклассники-д ирээд ярилцлагадаа Elasticsearch-тэй хамтран ажиллах боломжтой гэж увайгүй хэлсэн. Би үүнийг ойлгож, зарим энгийн ажлуудыг гүйцэтгэсний дараа надад тухайн үед байсан бүртгэлийн менежментийн системийг шинэчлэх том даалгавар өгсөн.
шаардлага
Системийн шаардлагыг дараах байдлаар томъёолсон.
- Грэйлогийг урд тал болгон ашиглах ёстой байв. Тус компани энэ бүтээгдэхүүнийг ашиглах туршлагатай байсан тул программистууд болон тестерүүд үүнийг мэддэг байсан тул энэ нь тэдэнд танил, тохиромжтой байсан.
- Мэдээллийн хэмжээ: секундэд дунджаар 50-80 мянган мессеж, гэхдээ ямар нэг зүйл эвдэрвэл траффик юугаар ч хязгаарлагдахгүй, секундэд 2-3 сая мөр байж болно.
- Үйлчлүүлэгчидтэй хайлтын асуулга боловсруулах хурдад тавигдах шаардлагуудын талаар ярилцсаны дараа бид ийм системийг ашиглах ердийн хэв маяг нь дараах байдалтай байгааг ойлгосон: хүмүүс сүүлийн хоёр өдрийн турш өөрсдийн өргөдлийн бүртгэлийг хайж байгаа бөгөөд нэгээс илүү удаа хүлээхийг хүсэхгүй байна. хоёр дахь нь боловсруулсан асуулгын үр дүнгийн хувьд.
- Администраторууд систем нь хэрхэн ажилладаг талаар гүнзгий судлах шаардлагагүй, шаардлагатай бол хялбархан өргөжүүлэх боломжтой байхыг шаарддаг.
- Тиймээс эдгээр системд үе үе шаардлагатай засвар үйлчилгээ хийх цорын ганц ажил бол зарим техник хангамжийг өөрчлөх явдал юм.
- Нэмж дурдахад, Одноклассники нь техникийн маш сайн уламжлалтай: бидний эхлүүлсэн аливаа үйлчилгээ нь дата төвийн эвдрэлийг (гэнэтийн, төлөвлөөгүй, ямар ч үед) даван туулах ёстой.
Энэ төслийг хэрэгжүүлэхэд тавигдах сүүлчийн шаардлага нь бидэнд хамгийн их зардал гаргасан бөгөөд энэ талаар би илүү дэлгэрэнгүй ярих болно.
Байгаль орчны
Бид дөрвөн дата төвд ажилладаг бол Elasticsearch өгөгдлийн зангилаа нь зөвхөн гуравт (техникийн бус олон шалтгааны улмаас) байрлах боломжтой.
Эдгээр дөрвөн мэдээллийн төв нь ойролцоогоор 18 мянган өөр бүртгэлийн эх сурвалжийг агуулдаг - техник хангамж, контейнер, виртуал машин.
Чухал онцлог: кластер нь саванд эхэлдэг физик машин дээр биш, харин дээр . Контейнерууд нь 2Ghz v2.0-тэй төстэй 4 цөмтэй бөгөөд сул зогссон тохиолдолд үлдсэн цөмийг дахин боловсруулах боломжтой.
Өөрөөр хэлбэл:
Топологи
Би эхлээд шийдлийн ерөнхий хэлбэрийг дараах байдлаар харсан.
- Graylog домэйны A бичлэгийн ард 3-4 VIP байгаа бөгөөд энэ нь бүртгэлийг илгээдэг хаяг юм.
- VIP бүр нь LVS тэнцвэржүүлэгч юм.
- Үүний дараа логууд Graylog батерей руу ордог бөгөөд зарим өгөгдөл нь GELF форматтай, зарим нь syslog форматтай байдаг.
- Дараа нь энэ бүгдийг Elasticsearch зохицуулагчдын батерейнд их хэмжээгээр бичдэг.
- Тэд эргээд холбогдох өгөгдлийн зангилаа руу бичих, унших хүсэлт илгээдэг.
Нэр томъёо
Магадгүй хүн бүр нэр томъёог нарийвчлан ойлгодоггүй тул би энэ талаар бага зэрэг ярихыг хүсч байна.
Elasticsearch нь хэд хэдэн төрлийн зангилаатай байдаг - мастер, зохицуулагч, өгөгдлийн зангилаа. Өөр өөр лог хувиргах болон өөр өөр кластеруудын хооронд харилцах өөр хоёр төрөл байдаг ч бид зөвхөн жагсаасан зүйлсийг ашигласан.
мастер
Энэ нь кластерт байгаа бүх зангилаа руу ping хийж, хамгийн сүүлийн үеийн кластерын зураглалыг хөтөлж, зангилаа хооронд хуваарилж, үйл явдлын логикийг боловсруулж, кластерийн өргөн хүрээний янз бүрийн төрлийн цэвэрлэгээг гүйцэтгэдэг.
Зохицуулагч
Нэг даалгавар гүйцэтгэдэг: үйлчлүүлэгчдээс унших, бичих хүсэлтийг хүлээн авч, энэ урсгалыг чиглүүлдэг. Хэрэв бичих хүсэлт байгаа бол энэ нь холбогдох индексийн аль хэсгийг оруулахыг мастераас асууж, хүсэлтийг цааш нь чиглүүлэх болно.
Өгөгдлийн зангилаа
Өгөгдлийг хадгалж, гаднаас ирж буй хайлтуудыг гүйцэтгэж, түүн дээр байрлах хэлтэрхийнүүд дээр үйлдлүүдийг гүйцэтгэдэг.
Грейлог
Энэ нь ELK стек дэх Кибана-г Logstash-тай нийлүүлэхтэй адил зүйл юм. Graylog нь UI болон лог боловсруулах дамжуулах хоолойг хоёуланг нь нэгтгэдэг. Бүрээсний доор Graylog нь Кафка болон Zookeeper-ийг ажиллуулдаг бөгөөд энэ нь Graylog-ийг кластер хэлбэрээр холбох боломжийг олгодог. Graylog нь Elasticsearch ажиллах боломжгүй тохиолдолд бүртгэлийг (Кафка) кэш хийж, амжилтгүй унших, бичих хүсэлтийг давтаж, заасан дүрмийн дагуу логуудыг бүлэглэх, тэмдэглэх боломжтой. Logstash-ийн нэгэн адил Graylog нь мөрүүдийг Elasticsearch-д бичихээс өмнө өөрчлөх боломжтой.
Нэмж дурдахад Graylog нь нэг боломжтой Elasticsearch зангилаа дээр үндэслэн кластерын зургийг бүхэлд нь авч, тодорхой хаягаар шүүх боломжийг олгодог суурилуулсан үйлчилгээний нээлттэй бөгөөд энэ нь хүсэлтийг тодорхой контейнер руу чиглүүлэх боломжийг олгодог.
Харааны хувьд энэ нь иймэрхүү харагдаж байна:
Энэ бол тодорхой тохиолдлоос авсан дэлгэцийн агшин юм. Энд бид хайлтын асуулгад үндэслэн гистограмм үүсгэж, холбогдох мөрүүдийг харуулдаг.
Индексүүд
Системийн архитектур руу буцахдаа бид бүгд зөв ажиллахын тулд индексийн загварыг хэрхэн бүтээсэн талаар илүү дэлгэрэнгүй ярихыг хүсч байна.
Дээрх диаграммд энэ нь хамгийн доод түвшин юм: Elasticsearch мэдээллийн зангилаа.
Индекс нь Elasticsearch хэлтэрхийүүдээс бүрдсэн том виртуал нэгж юм. Өөрөө, хэлтэрхий бүр нь Лусений индексээс өөр зүйл биш юм. Лусений индекс бүр нь эргээд нэг буюу хэд хэдэн сегментээс бүрддэг.
Дизайн хийхдээ бид их хэмжээний өгөгдөл дээр унших хурдны шаардлагыг хангахын тулд энэ өгөгдлийг өгөгдлийн зангилаанууд дээр жигд "тархах" шаардлагатай гэж үзсэн.
Үүний үр дүнд нэг индекс дэх хэсгүүдийн тоо (хуулбартай) нь өгөгдлийн зангилааны тоотой яг тэнцүү байх ёстой. Нэгдүгээрт, хуулбарлах хүчин зүйлийг хоёртой тэнцүү байлгахын тулд (өөрөөр хэлбэл бид кластерын талыг алдаж болно). Хоёрдугаарт, кластерын дор хаяж тал дээр унших, бичих хүсэлтийг боловсруулахын тулд.
Бид эхлээд хадгалах хугацааг 30 хоног гэж тодорхойлсон.
Хэргийн тархалтыг дараах байдлаар графикаар дүрсэлж болно.
Хар саарал тэгш өнцөгт бүхэлдээ индекс юм. Үүний зүүн улаан дөрвөлжин нь индексийн эхнийх нь үндсэн хэлтэрхий юм. Мөн цэнхэр дөрвөлжин нь хуулбарласан хэлтэрхий юм. Тэд өөр өөр мэдээллийн төвүүдэд байрладаг.
Бид өөр хэлтэрхий нэмэхэд гурав дахь дата төв рүү очно. Эцэст нь бид ийм бүтцийг олж авдаг бөгөөд энэ нь өгөгдлийн тогтвортой байдлыг алдалгүйгээр DC-г алдах боломжийг олгодог.
Индексүүдийн эргэлт, i.e. Шинэ индекс үүсгэж, хамгийн эртнийх нь устгаснаар бид үүнийг 48 цагтай тэнцүү болгосон (индекс ашиглалтын хэв маягийн дагуу: сүүлийн 48 цагийг ихэвчлэн хайдаг).
Энэ индексийн эргэлтийн интервал нь дараахь шалтгаанаас үүдэлтэй.
Хайлтын хүсэлт тодорхой өгөгдлийн цэг дээр ирэхэд гүйцэтгэлийн үүднээс авч үзвэл, хэмжээ нь зангилааны ташааны хэмжээтэй харьцуулах боломжтой бол нэг хэлтэрхийг асуухад илүү ашигтай байдаг. Энэ нь индексийн "халуун" хэсгийг бөөгнөрөлд хадгалж, түүнд хурдан хандах боломжийг олгоно. Олон тооны "халуун хэсгүүд" байгаа үед индекс хайлтын хурд буурдаг.
Зангилаа нь нэг хэлтэрхий дээр хайлтын асуулгыг гүйцэтгэж эхлэхэд физик машины hyperthreading цөмийн тоотой тэнцүү тооны хэлхээг хуваарилдаг. Хэрэв хайлтын асуулга нь олон тооны хэлтэрхийд нөлөөлж байвал хэлхээний тоо пропорциональ хэмжээгээр өснө. Энэ нь хайлтын хурдад сөргөөр нөлөөлж, шинэ өгөгдлийг индексжүүлэхэд сөргөөр нөлөөлдөг.
Шаардлагатай хайлтын хоцролтыг хангахын тулд бид SSD ашиглахаар шийдсэн. Хүсэлтийг хурдан боловсруулахын тулд эдгээр контейнеруудыг байрлуулсан машинууд дор хаяж 56 цөмтэй байх ёстой. 56 гэсэн тоог нөхцөлт хангалттай утга болгон сонгосон бөгөөд энэ нь үйл ажиллагааны явцад Elasticsearch үүсгэх хэлхээний тоог тодорхойлдог. Elasitcsearch-д урсгалын сангийн олон параметрүүд нь боломжтой цөмийн тооноос шууд хамаардаг бөгөөд энэ нь "цөөн цөм - илүү зангилаа" зарчмын дагуу кластер дахь шаардлагатай тооны зангилаанд шууд нөлөөлдөг.
Үүний үр дүнд бид нэг хэлтэрхий дунджаар 20 гигабайт жинтэй, нэг индекст 1 ширхэг байдаг болохыг олж мэдсэн. Үүний дагуу, хэрэв бид тэдгээрийг 360 цаг тутамд нэг удаа эргүүлэх юм бол бид 48 байна. Индекс бүр 15 өдрийн өгөгдлийг агуулна.
Өгөгдөл бичих, унших хэлхээ
Энэ системд өгөгдөл хэрхэн бичигдсэнийг олж мэдье.
Грэйлогоос зохицуулагч руу ямар нэгэн хүсэлт ирсэн гэж бодъё. Жишээлбэл, бид 2-3 мянган мөрийг индексжүүлэхийг хүсч байна.
Грэйлогоос хүсэлтийг хүлээн авсан зохицуулагч мастераас асуув: "Индексийн хүсэлтэд бид индексийг тусгайлан зааж өгсөн боловч аль хэсэгт бичихийг заагаагүй байна."
Мастер хариуд нь: "Энэ мэдээллийг 71-р хэлтэрхийн дугаарт бичнэ үү" гэж хариулаад дараа нь 71-р үндсэн хэсэг байрлах холбогдох өгөгдлийн зангилаа руу шууд илгээгдэнэ.
Үүний дараа гүйлгээний бүртгэлийг өөр мэдээллийн төвд байрлах хуулбар-хэсэгт хуулбарлана.
Грэйлогоос зохицуулагч руу хайлтын хүсэлт ирдэг. Зохицуулагч нь үүнийг индексийн дагуу дахин чиглүүлдэг бол Elasticsearch нь round-robin зарчмыг ашиглан анхдагч-хэсэг болон хуулбар-хэсэг хооронд хүсэлтийг хуваарилдаг.
180 зангилаа жигд бус хариу үйлдэл үзүүлдэг бөгөөд хариу үйлдэл үзүүлж байх хооронд зохицуулагч нь илүү хурдан өгөгдлийн зангилаануудаар аль хэдийн "нулимсан" мэдээллийг хуримтлуулж байна. Үүний дараа бүх мэдээлэл ирсэн эсвэл хүсэлт хугацаа хэтэрсэн тохиолдолд бүх зүйлийг шууд үйлчлүүлэгчид өгдөг.
Энэ систем бүхэлдээ хайлтын асуулгыг сүүлийн 48 цагийн турш дунджаар 300-400 мс-д боловсруулдаг бөгөөд тэргүүлэгч тэмдэгтэй асуултуудыг оруулаагүй болно.
Elasticsearch бүхий цэцэг: Java тохиргоо
Бүгдийг бидний хүссэнээр ажиллуулахын тулд бид кластер дахь олон төрлийн зүйлийг дибаг хийхэд маш удаан хугацаа зарцуулсан.
Илэрсэн асуудлуудын эхний хэсэг нь Java-г Elasticsearch дээр анхдагчаар урьдчилан тохируулсантай холбоотой байв.
Асуудал нэг
Лусений түвшинд суурь ажлууд ажиллаж байх үед Lucene сегментийн нэгдлүүд алдаатай бүтэлгүйтсэн тухай маш олон тооны тайланг бид харсан. Үүний зэрэгцээ энэ нь OutOfMemoryError алдаа байсан нь бүртгэлд тодорхой байсан. Бид телеметрийн тусламжтайгаар хонго нь чөлөөтэй байгааг харсан бөгөөд яагаад энэ ажиллагаа амжилтгүй болсон нь тодорхойгүй байв.
Лусений индексийн нэгдэл нь ташааны гадна талд тохиолддог нь тогтоогдсон. Мөн савнууд нь зарцуулсан нөөцийн хувьд нэлээд хязгаарлагдмал байдаг. Эдгээр нөөцөд зөвхөн нуруулдан багтах боломжтой (heap.size утга нь ойролцоогоор RAM-тай тэнцүү байсан) бөгөөд хэрэв ямар нэг шалтгааны улмаас хязгаараас өмнө үлдсэн ~500MB-т багтахгүй бол санах ойн хуваарилалтын алдаатай зарим овоолгын үйлдлүүд гацсан.
Засвар нь маш өчүүхэн байсан: саванд ашиглах боломжтой RAM-ийн хэмжээ нэмэгдсэн бөгөөд үүний дараа бид ийм асуудалтай тулгарснаа мартсан.
Асуудал хоёр
Кластерыг ажиллуулснаас хойш 4-5 хоногийн дараа өгөгдлийн зангилаа үе үе кластераас гарч, 10-20 секундын дараа нэвтэрч эхэлснийг бид анзаарсан.
Бид үүнийг олж мэдэхэд Elasticsearch дахь энэхүү овоолон санах ой ямар ч байдлаар хянагддаггүй нь тогтоогдсон. Бид контейнерт илүү их санах ой өгөх үед бид шууд буферийн сангуудыг янз бүрийн мэдээллээр дүүргэж чадсан бөгөөд Elasticsearch-аас тодорхой GC ажиллуулсны дараа л устгасан.
Зарим тохиолдолд энэ ажиллагаа нэлээд удаан үргэлжилсэн бөгөөд энэ хугацаанд кластер энэ зангилааг аль хэдийн гарсан гэж тэмдэглэж чадсан. Энэ асуудлыг маш сайн тодорхойлсон .
Үүний шийдэл нь дараах байдалтай байсан: бид эдгээр үйлдлүүдэд зориулж овоолгын гадна санах ойн ихэнх хэсгийг ашиглах Java-г хязгаарласан. Бид үүнийг 16 гигабайтаар (-XX:MaxDirectMemorySize=16г) хязгаарласан бөгөөд энэ нь тодорхой GC-г илүү олон удаа дуудаж, илүү хурдан боловсруулж, кластерийг тогтворгүй болгохоо больсон.
Гуравдугаар асуудал
Хэрэв та "хамгийн санаанд оромгүй мөчид кластераас гарах зангилаа" асуудал дууссан гэж бодож байгаа бол та эндүүрч байна.
Бид индекстэй ажиллах тохиргоог хийхдээ mmapfs-ийг сонгосон гайхалтай сегментчилсэн шинэхэн хэлтэрхийнүүд дээр. Энэ бол нэлээд бүдүүлэг алдаа байсан, учир нь mmapfs ашиглах үед файлыг RAM-д буулгадаг бөгөөд дараа нь бид зураглагдсан файлтай ажилладаг. Үүнээс болж GC програмын утсыг зогсоох гэж оролдоход бид аюулгүй газар руу маш удаан очдог бөгөөд түүн рүү явах замд програм нь амьд эсэх талаар мастерын хүсэлтэд хариу өгөхөө больсон. . Үүний дагуу мастер зангилаа нь кластерт байхгүй болсон гэж үздэг. Үүний дараа 5-10 секундын дараа хог цуглуулагч ажиллаж, зангилаа амь орж, кластерт дахин орж, хэлтэрхийг эхлүүлж эхэлнэ. Энэ бүхэн "бидний хүртэх ёстой үйлдвэрлэл" шиг санагдаж байсан бөгөөд ямар ч ноцтой зүйлд тохиромжгүй байв.
Энэ зан авираас ангижрахын тулд бид эхлээд стандарт niofs руу шилжсэн бөгөөд дараа нь бид Elastic-ийн тав дахь хувилбараас зургаа дахь хувилбар руу шилжихдээ эрлийз хувилбаруудыг туршиж үзсэн бөгөөд энэ асуудал дахин давтагдахгүй байв. Та хадгалах төрлүүдийн талаар илүү ихийг уншиж болно .
Асуулт дөрөв
Дараа нь бид рекорд тогтоосон хугацаанд эмчилсэн өөр нэг маш сонирхолтой асуудал гарч ирэв. Загвар нь үнэхээр ойлгомжгүй байсан тул бид 2-3 сарын турш барьж авсан.
Заримдаа манай зохицуулагчид үдийн хоолны дараа ихэвчлэн Full GC-д очдог байсан бөгөөд тэндээсээ буцаж ирдэггүй байв. Үүний зэрэгцээ, GC-ийн саатлыг бүртгэх үед энэ нь иймэрхүү харагдаж байв: бүх зүйл сайн, сайн, сайн, дараа нь гэнэт бүх зүйл маш муу болж байна.
Эхлээд бид зохицуулагчийг ажлын горимоос нь салгасан ямар нэгэн хүсэлтийг эхлүүлсэн муу хэрэглэгчтэй гэж бодсон. Бид юу болоод байгааг олж мэдэхийг хичээж, хүсэлтийг маш удаан хугацаанд бүртгэсэн.
Үүний үр дүнд хэрэглэгч асар их хүсэлт гаргаж, тодорхой Elasticsearch зохицуулагч руу очих үед зарим зангилаа бусдаасаа илүү удаан хариу үйлдэл үзүүлдэг болох нь тогтоогдсон.
Зохицуулагч нь бүх зангилаанаас хариу хүлээж байх хооронд аль хэдийн хариу өгсөн зангилаанаас илгээсэн үр дүнг хуримтлуулдаг. GC-ийн хувьд энэ нь бидний овоолгын хэрэглээний загвар маш хурдан өөрчлөгддөг гэсэн үг юм. Бидний ашиглаж байсан GC энэ ажлыг даван туулж чадаагүй.
Энэ нөхцөлд кластерын зан төлөвийг өөрчлөх цорын ганц шийдэл бол JDK13 руу шилжих, Шенандоа хог цуглуулагч ашиглах явдал юм. Энэ нь асуудлыг шийдэж, манай зохицуулагчид унахаа больсон.
Эндээс Java-ийн асуудал дуусч, зурвасын өргөнтэй холбоотой асуудал эхэлсэн.
Elasticsearch-тэй "Жимс": дамжуулах чадвар
Дамжуулах чадварын асуудал нь манай кластер тогтвортой ажиллаж байгаа боловч индексжүүлсэн баримт бичгийн тоо оргил үедээ, маневр хийх үед гүйцэтгэл хангалтгүй байна гэсэн үг юм.
Эхний шинж тэмдэг: үйлдвэрлэлийн зарим "тэсрэлт" үед маш олон тооны логууд гэнэт үүсэх үед es_rejected_execution индексжүүлэлтийн алдаа Graylog дээр байнга анивчдаг.
Энэ нь нэг өгөгдлийн зангилаа дээрх thread_pool.write.queue нь Elasticsearch нь индексжүүлэх хүсэлтийг боловсруулж, мэдээллийг дискний хэлтэрхий рүү байршуулах хүртэл анхдагчаар ердөө 200 хүсэлтийг кэшлэх чадвартай байсантай холбоотой юм. Тэгээд дотор Энэ параметрийн талаар маш бага зүйл ярьдаг. Зөвхөн хамгийн их урсгалын тоо болон анхдагч хэмжээг зааж өгсөн болно.
Мэдээжийн хэрэг, бид энэ утгыг мушгин гуйвуулж, дараахь зүйлийг олж мэдэв: ялангуяа бидний тохиргоонд 300 хүртэлх хүсэлтийг маш сайн хадгалдаг бөгөөд илүү өндөр үнэ цэнэ нь бид дахин Full GC руу нисч байгаатай холбоотой юм.
Нэмж дурдахад эдгээр нь нэг хүсэлтийн дотор ирдэг багц мессежүүд тул Graylog-ийг олон удаа, жижиг багцаар биш, асар их багцаар эсвэл багц дуусаагүй бол 3 секунд тутамд нэг удаа бичихийн тулд өөрчлөх шаардлагатай болсон. Энэ тохиолдолд бидний Elasticsearch дээр бичсэн мэдээлэл нь хоёр секундын дотор биш, харин тав (энэ нь бидэнд маш сайн тохирдог), харин том зайг даван туулахын тулд хийх ёстой дахин тавиуруудын тоог авах боломжтой болох нь харагдаж байна. мэдээллийн багц багассан.
Энэ нь хаа нэгтээ ямар нэг зүйл эвдэрч, энэ талаар ууртай мэдээлэх үед онцгой чухал бөгөөд ингэснээр бүрэн спамлагдсан Elastic болон хэсэг хугацааны дараа - буфер бөглөрсний улмаас ажиллах боломжгүй болсон Graylog зангилаанууд.
Нэмж дурдахад, үйлдвэрлэлд ижил төстэй дэлбэрэлтүүд тохиолдоход бид программистууд болон шалгагчдаас гомдол хүлээн авсан: яг тэр мөчид эдгээр бүртгэлүүд үнэхээр хэрэгтэй байсан тул тэдгээрийг маш удаанаар өгсөн.
Тэд үүнийг тодорхойлж эхлэв. Нэг талаас, хайлтын асуулга болон индексжүүлэлтийн асуулга хоёулаа үндсэндээ ижил физик машинууд дээр боловсруулагдсан бөгөөд ямар нэгэн байдлаар тодорхой сул тал байх нь тодорхой байв.
Гэхдээ Elasticsearch-ийн зургаа дахь хувилбаруудад санамсаргүй тойргийн зарчмын дагуу (индексжүүлэлт хийдэг, анхдагч мэдээллийг агуулсан контейнер) холбогдох өгөгдлийн зангилааны хооронд асуултуудыг хуваарилах боломжийг олгодог алгоритм гарч ирсэн тул үүнийг хэсэгчлэн тойрч болох юм. -shard маш завгүй байж болох тул хурдан хариу өгөх арга байхгүй), гэхдээ энэ хүсэлтийг илүү хурдан хариу өгөх хуулбар-хэсэг бүхий бага ачаалалтай контейнер руу илгээнэ үү. Өөрөөр хэлбэл, бид use_adaptive_replica_selection: true дээр ирсэн.
Уншиж буй зураг дараах байдлаар харагдаж эхэлнэ.
Энэхүү алгоритм руу шилжсэнээр бид бичихэд их хэмжээний бүртгэлтэй байсан тэр мөчид асуулгын хугацааг мэдэгдэхүйц сайжруулах боломжтой болсон.
Эцэст нь гол асуудал бол дата төвийг өвдөлтгүй арилгах явдал байв.
Нэг DC-тэй холбоо тасарсан даруйдаа кластераас хүссэн зүйл:
- Хэрэв бид бүтэлгүйтсэн өгөгдлийн төвд одоогийн мастер байгаа бол түүнийг дахин сонгож, өөр DC-ийн өөр зангилаа руу үүрэг болгон шилжүүлэх болно.
- Мастер бүх нэвтрэх боломжгүй зангилааг кластераас хурдан арилгах болно.
- Үлдсэн дээр үндэслэн тэрээр ойлгох болно: алдагдсан мэдээллийн төвд ийм ийм үндсэн хэсгүүд байсан, тэр үлдсэн дата төвүүдэд нэмэлт хуулбаруудыг хурдан сурталчлах болно, бид өгөгдлийг үргэлжлүүлэн индексжүүлэх болно.
- Үүний үр дүнд кластерын бичих, унших чадвар аажмаар буурах боловч ерөнхийдөө бүх зүйл удаан боловч тогтвортой ажиллах болно.
Бид ийм зүйлийг хүсч байсан нь тодорхой болсон:
Мөн бид дараахь зүйлийг авсан.
Энэ нь яаж болсон бэ?
Дата төв унахад манай мастер гацаа болсон.
Яагаад?
Мастер нь кластерт тодорхой даалгавар, үйл явдлыг түгээх үүрэгтэй TaskBatcher-тэй байдаг. Аливаа зангилааны гаралт, хэлтэрхийг хуулбараас анхдагч хүртэл сурталчлах, хаа нэгтээ хэлтэрхий үүсгэх аливаа ажил - энэ бүхэн эхлээд TaskBatcher руу ордог бөгөөд үүнийг дараалан, нэг хэлхээнд боловсруулдаг.
Нэг дата төвийг татан буулгах үед амьд үлдсэн дата төвүүдийн бүх өгөгдлийн зангилаа мастерт "бид ийм ийм хэлтэрхий, ийм ийм өгөгдлийн зангилаа алдсан" гэж мэдэгдэх үүрэгтэй гэж үзсэн.
Үүний зэрэгцээ, амьд үлдсэн өгөгдлийн зангилаанууд энэ бүх мэдээллийг одоогийн мастер руу илгээж, түүнийг хүлээн авсан гэдгээ батлахыг хүлээхийг оролдсон. Мастер хариулахаасаа илүү хурдан даалгавруудыг хүлээж авсан тул тэд үүнийг хүлээгээгүй. Зангилаанууд давтагдах хүсэлтийг хойшлуулсан бөгөөд энэ үед мастер тэдэнд хариулах гэж оролдсонгүй, харин хүсэлтийг эрэмбэлэн ангилах ажилд бүрэн шингэсэн байв.
Терминал хэлбэрээр өгөгдлийн зангилаанууд мастер руу спам илгээж, бүрэн GC руу шилжсэн нь тогтоогдсон. Үүний дараа бидний мастер үүрэг дараагийн зангилаа руу шилжсэн бөгөөд үүнтэй ижил зүйл тохиолдсон бөгөөд үүний үр дүнд кластер бүрэн унав.
Бид хэмжилт хийсэн бөгөөд үүнийг зассан 6.4.0 хувилбараас өмнө кластерыг бүрэн унтраахын тулд 10-аас зөвхөн 360 өгөгдлийн зангилааг нэгэн зэрэг гаргахад хангалттай байсан.
Энэ нь иймэрхүү харагдаж байсан:
Энэхүү аймшигт алдааг зассан 6.4.0 хувилбарын дараа өгөгдлийн зангилаа мастерийг устгахаа больсон. Гэхдээ энэ нь түүнийг "ухаалаг" болгосонгүй. Тухайлбал: 2, 3 эсвэл 10 (нэгээс өөр ямар ч тоо) өгөгдлийн зангилаа гаргахад мастер А зангилаа гарсан гэсэн эхний мессежийг хүлээн авч, В зангилаа, С зангилаа, D зангилааны талаар хэлэхийг оролддог.
Одоогийн байдлаар үүнийг хэн нэгэнд ямар нэг зүйлийн талаар хэлэх оролдлогын хугацаа 20-30 секундтэй тэнцэх хугацааг тогтоож, кластераас гарах дата төвийн хурдыг хянах замаар л шийдвэрлэх боломжтой.
Зарчмын хувьд энэ нь төслийн нэг хэсэг болгон эцсийн бүтээгдэхүүнд танилцуулсан шаардлагад нийцэж байгаа боловч "цэвэр шинжлэх ухааны" үүднээс авч үзвэл энэ нь алдаа юм. Дашрамд хэлэхэд үүнийг хөгжүүлэгчид 7.2 хувилбар дээр амжилттай зассан.
Түүгээр ч барахгүй тодорхой өгөгдлийн зангилаа гарахад түүний гаралтын талаарх мэдээллийг түгээх нь бүхэл бүтэн кластерт ийм ийм үндсэн хэсгүүд байгааг хэлэхээс илүү чухал болох нь тогтоогдсон (өөр өгөгдөлд хуулбарлах хэсгийг сурталчлахын тулд). төвийг анхан шатны болон мэдээлэлд бичиж болно).
Тиймээс, бүх зүйл аль хэдийн унтарсан үед суллагдсан өгөгдлийн зангилаанууд хуучирсан гэж шууд тэмдэглэгддэггүй. Үүний дагуу бид суллагдсан өгөгдлийн зангилаа руу бүх пинг хугацаа дуустал хүлээхээс өөр аргагүй болж байгаа бөгөөд үүний дараа л манай кластер тэнд, тэнд, тэнд мэдээллийг үргэлжлүүлэн бичих хэрэгтэй гэж хэлж эхэлдэг. Та энэ талаар илүү ихийг уншиж болно .
Үүний үр дүнд өнөөдөр дата төвийг татан буулгах ажиллагаа ачаалал ихтэй үед 5 минут орчим болдог. Ийм том, болхи колоссын хувьд энэ нь маш сайн үр дүн юм.
Үүний үр дүнд бид дараах шийдвэрт хүрсэн.
- Бидэнд 360 гигабайт диск бүхий 700 өгөгдлийн зангилаа бий.
- Эдгээр өгөгдлийн зангилаануудаар дамжуулан урсгалыг чиглүүлэх 60 зохицуулагч.
- 40-ээс өмнөх хувилбаруудаас хойш бидний өвлөн үлдээсэн 6.4.0 мастерууд - Дата төвийг татан буулгах үед амьд үлдэхийн тулд бид мастеруудын чуулгатай байх баталгаатай байхын тулд хэд хэдэн машиныг алдахад сэтгэл зүйн бэлтгэлтэй байсан. хамгийн муу тохиолдол
- Нэг саванд үүргүүдийг нэгтгэх оролдлого нь эрт орой хэзээ нэгэн цагт ачааллын дор зангилаа эвдэрнэ гэсэн баримттай тулгарсан.
- Бүхэл бүтэн кластер нь 31 гигабайтын овоолгын хэмжээг ашигладаг: хэмжээг багасгах бүх оролдлого нь хүнд хайлтын асуулгын зарим зангилааг тэргүүлэх орлуулагч тэмдэгтээр устгах, эсвэл өөрөө Elasticsearch-д таслуур авахад хүргэсэн.
- Нэмж дурдахад, хайлтын гүйцэтгэлийг хангахын тулд бид мастерт тохиолдсон саад бэрхшээлийг аль болох цөөхөн үйл явдлыг боловсруулахын тулд кластер дахь объектын тоог аль болох бага байлгахыг хичээсэн.
Эцэст нь хяналтын тухай
Энэ бүхэн зориулалтын дагуу ажиллахын тулд бид дараахь зүйлийг хянадаг.
- Өгөгдлийн зангилаа бүр нь байгаа гэдгээ манай үүлэнд мэдээлдэг бөгөөд үүн дээр ийм, ийм хэлтэрхий байдаг. Бид хаа нэгтээ ямар нэг зүйлийг унтраахад кластер нь 2-3 секундын дараа А төвд 2, 3, 4-р зангилаануудыг унтраасан гэж мэдээлдэг - энэ нь бусад мэдээллийн төвүүдэд зөвхөн нэг хэлтэрхий байгаа зангилаануудыг ямар ч тохиолдолд унтрааж чадахгүй гэсэн үг юм. зүүн.
- Мастерын зан үйлийн мөн чанарыг мэдэхийн тулд бид хүлээгдэж буй ажлуудын тоог маш анхааралтай ажигладаг. Учир нь нэг гацсан ажил ч гэсэн хугацаандаа дуусахгүй бол онолын хувьд зарим онцгой байдлын үед жишээ нь анхдагч хэсэгт хуулбарын хэлтэрхий сурталчлах нь ажиллахгүй байгаа шалтгаан болж, индексжүүлэлт ажиллахаа болино.
- Оновчлолын явцад бид аль хэдийн маш их бэрхшээлтэй тулгарсан тул бид хог цуглуулагчийн саатлыг сайтар судалж үздэг.
- Хаана түгжрэл байгааг урьдчилан ойлгохын тулд утсаар татгалздаг.
- За, нуруулдан, RAM болон I/O гэх мэт стандарт хэмжүүрүүд.
Хяналт тавихдаа Elasticsearch дахь Thread Pool-ийн онцлогуудыг анхаарч үзэх хэрэгтэй. хайлт болон индексжүүлэх тохиргооны сонголтууд болон анхдагч утгуудыг тайлбарладаг боловч thread_pool.management-ийн талаар огт чимээгүй байдаг.Эдгээр хэлхээнүүд нь ялангуяа _cat/shards гэх мэт асуулга болон бусад ижил төстэй асуултуудыг боловсруулдаг бөгөөд энэ нь мониторинг бичихэд ашиглахад тохиромжтой. Кластер том байх тусам нэгж цаг тутамд илүү олон хүсэлтийг гүйцэтгэдэг бөгөөд дээр дурдсан thread_pool.management нь албан ёсны баримт бичигт тусгагдаагүй төдийгүй анхдагч байдлаар 5 хэлхээгээр хязгаарлагддаг бөгөөд үүнийг дараа нь маш хурдан устгадаг. аль хяналт нь зөв ажиллахаа больсон.
Эцэст нь хэлэхэд би юу хэлэхийг хүсч байна: бид үүнийг хийсэн! Бид програмистууд болон хөгжүүлэгчиддээ бараг ямар ч нөхцөлд үйлдвэрлэлд юу болж байгаа талаар хурдан бөгөөд найдвартай мэдээллээр хангах хэрэгслийг өгч чадсан.
Тийм ээ, энэ нь нэлээд төвөгтэй байсан ч бид өөрсдийн хүслийг одоо байгаа бүтээгдэхүүнүүдэд тохируулж чадсан бөгөөд бид өөрсдөө засвар хийж, дахин бичих шаардлагагүй байв.
Эх сурвалж: www.habr.com