Bir çox insan Elasticsearch ilə mübarizə aparır. Bəs onu qeydləri "xüsusilə böyük həcmdə" saxlamaq üçün istifadə etmək istədiyiniz zaman nə baş verir? Həm də bir neçə məlumat mərkəzindən hər hansı birinin uğursuzluğunu yaşamaq ağrısızdırmı? Hansı memarlıq yaratmalısınız və hansı tələlərlə qarşılaşacaqsınız?
Biz Odnoklassniki-də logların idarə edilməsi məsələsini həll etmək üçün elasticsearch-dan istifadə etmək qərarına gəldik və indi Habr ilə təcrübəmizi bölüşürük: həm memarlıq, həm də tələlər haqqında.
Mən Pyotr Zaitsev, Odnoklassniki-də sistem administratoru işləyirəm. Bundan əvvəl mən də admin idim, Manticore Search, Sphinx search, Elasticsearch ilə işləyirdim. Ola bilsin ki, başqa ... axtarış görünsə, mən də onunla işləyəcəm. Mən də könüllü olaraq bir sıra açıq mənbəli layihələrdə iştirak edirəm.
Odnoklassniki-yə gələndə müsahibədə ehtiyatsızlıqdan Elasticsearch ilə işləyə biləcəyimi dedim. Mən bunu başa düşdükdən və bəzi sadə tapşırıqları yerinə yetirdikdən sonra mənə o dövrdə mövcud olan log idarəetmə sistemində islahatların aparılması kimi böyük tapşırıq verildi.
Tələblər
Sistem tələbləri aşağıdakı kimi tərtib edilmişdir:
- Graylog-dan frontend kimi istifadə edilməli idi. Şirkətin artıq bu məhsuldan istifadə təcrübəsi olduğundan, proqramçılar və testerlər bunu bilirdilər, bu, onlara tanış və rahat idi.
- Məlumat həcmi: saniyədə orta hesabla 50-80 min mesaj, lakin bir şey pozulursa, trafik heç bir şeylə məhdudlaşmır, saniyədə 2-3 milyon sətir ola bilər.
- Müştərilərlə axtarış sorğularının emal sürətinə dair tələbləri müzakirə etdikdən sonra başa düşdük ki, belə bir sistemdən istifadənin tipik nümunəsi belədir: insanlar son iki gündə öz müraciətlərinin qeydlərini axtarır və birdən çox gözləmək istəmirlər. ikincisi tərtib edilmiş sorğunun nəticəsi üçün.
- Administratorlar sistemin necə işlədiyini dərindən araşdırmalarını tələb etmədən, zəruri hallarda sistemin asanlıqla genişləndirilə biləcəyini təkid etdilər.
- Beləliklə, bu sistemlərin vaxtaşırı tələb etdiyi yeganə texniki xidmət bəzi avadanlıqları dəyişdirməkdir.
- Bundan əlavə, Odnoklassniki-nin əla texniki ənənəsi var: işə saldığımız istənilən xidmət məlumat mərkəzinin nasazlığından (qəfil, planlaşdırılmamış və tamamilə istənilən vaxt) sağ qalmalıdır.
Bu layihənin həyata keçirilməsində sonuncu tələb bizə ən çox baha başa gəldi, bu barədə daha ətraflı danışacağam.
Çərşənbə
Biz dörd məlumat mərkəzində işləyirik, Elasticsearch məlumat qovşaqları isə yalnız üçdə yerləşdirilə bilər (bir sıra qeyri-texniki səbəblərə görə).
Bu dörd məlumat mərkəzi təxminən 18 min müxtəlif log mənbəyini - hardware, konteynerlər, virtual maşınları ehtiva edir.
Vacib xüsusiyyət: klaster konteynerlərdə başlayır fiziki maşınlarda deyil, üzərində . Konteynerlərə 2Ghz v2.0-ə bənzər 4 nüvəyə zəmanət verilir və boş halda qalan nüvələri təkrar emal etmək imkanı verilir.
Başqa sözlə:
Topologiya
Əvvəlcə həllin ümumi formasını aşağıdakı kimi gördüm:
- Graylog domeninin A-rekordunun arxasında 3-4 VIP dayanır, bu qeydlərin göndərildiyi ünvandır.
- hər bir VIP LVS balanslaşdırıcısıdır.
- Bundan sonra qeydlər Graylog batareyasına keçir, məlumatların bir hissəsi GELF formatında, bəziləri isə syslog formatındadır.
- Sonra bütün bunlar böyük partiyalarda Elasticsearch koordinatorlarının batareyasına yazılır.
- Onlar da öz növbəsində müvafiq məlumat qovşaqlarına yazı və oxu sorğuları göndərirlər.
Terminologiya
Ola bilsin ki, hər kəs terminologiyanı təfərrüatı ilə başa düşmür, ona görə də bir az onun üzərində dayanmaq istərdim.
Elasticsearch bir neçə növ qovşaqlara malikdir - master, koordinator, məlumat qovşağı. Fərqli log çevrilmələri və müxtəlif klasterlər arasında əlaqə üçün başqa iki növ var, lakin biz yalnız sadalananlardan istifadə etdik.
Master
O, klasterdə mövcud olan bütün qovşaqlara ping edir, müasir klaster xəritəsini saxlayır və onu qovşaqlar arasında paylayır, hadisə məntiqini emal edir və klaster boyu müxtəlif növ ev işlərini yerinə yetirir.
Koordinator
Tək bir tapşırığı yerinə yetirir: müştərilərdən oxumaq və ya yazma sorğularını qəbul edir və bu trafiki yönləndirir. Yazma sorğusu olarsa, çox güman ki, ustadan onu müvafiq indeksin hansı parçasına yerləşdirməli olduğunu soruşacaq və sorğunu daha da yönləndirəcək.
Məlumat qovşağı
Məlumatları saxlayır, xaricdən daxil olan axtarış sorğularını yerinə yetirir və üzərində yerləşən qırıqlar üzərində əməliyyatlar həyata keçirir.
boz zolaq
Bu, ELK yığınında Logstash ilə Kibana birləşməsi kimi bir şeydir. Graylog həm istifadəçi interfeysini, həm də log emal boru kəmərini birləşdirir. Başlıq altında Graylog, Graylog-a klaster kimi qoşulmanı təmin edən Kafka və Zookeeper-i idarə edir. Elasticsearch mümkün olmadıqda Graylog qeydləri (Kafka) keşləyə bilər və uğursuz oxumaq və yazma sorğularını təkrarlaya bilər, qeydləri müəyyən edilmiş qaydalara uyğun qruplaşdıra və işarələyə bilər. Logstash kimi, Graylog da sətirləri Elasticsearch-ə yazmazdan əvvəl dəyişdirmək funksiyasına malikdir.
Bundan əlavə, Graylog bir mövcud Elasticsearch qovşağına əsaslanaraq bütün klaster xəritəsini əldə etməyə və onu xüsusi teq ilə süzməyə imkan verən daxili xidmət kəşfinə malikdir ki, bu da sorğuları konkret konteynerlərə yönəltməyə imkan verir.
Vizual olaraq belə görünür:
Bu, müəyyən bir nümunənin ekran görüntüsüdür. Burada axtarış sorğusu əsasında histoqram qururuq və müvafiq sətirləri göstəririk.
Indeksləri
Sistem arxitekturasına qayıdaraq, indeks modelini necə qurduğumuz haqqında daha ətraflı danışmaq istərdim ki, hamısı düzgün işləsin.
Yuxarıdakı diaqramda bu, ən aşağı səviyyədir: Elasticsearch məlumat qovşaqları.
İndeks Elasticsearch qırıqlarından ibarət böyük virtual varlıqdır. Özlüyündə hər bir parça Lucene indeksindən başqa bir şey deyil. Və hər bir Lucene indeksi, öz növbəsində, bir və ya bir neçə seqmentdən ibarətdir.
Dizayn edərkən biz düşündük ki, böyük miqdarda məlumatda oxu sürəti tələbini ödəmək üçün bu məlumatları məlumat qovşaqları arasında bərabər şəkildə "yaymaq" lazımdır.
Bu, indeksə düşən qırıntıların sayının (replikalarla) məlumat qovşaqlarının sayına ciddi şəkildə bərabər olması ilə nəticələndi. Birincisi, ikiyə bərabər bir təkrarlama faktorunu təmin etmək üçün (yəni çoxluğun yarısını itirə bilərik). İkincisi, klasterin ən azı yarısında oxumaq və yazma sorğularını emal etmək üçün.
Əvvəlcə saxlama müddətini 30 gün olaraq təyin etdik.
Parçaların paylanması qrafik olaraq aşağıdakı kimi göstərilə bilər:
Bütün tünd boz düzbucaqlı bir indeksdir. İçindəki sol qırmızı kvadrat indeksdə birinci olan əsas parçadır. Mavi kvadrat isə replika parçasıdır. Onlar müxtəlif məlumat mərkəzlərində yerləşirlər.
Başqa bir parça əlavə etdikdə üçüncü məlumat mərkəzinə keçir. Və nəhayət, məlumatların ardıcıllığını itirmədən DC-ni itirməyə imkan verən bu quruluşu əldə edirik:
İndekslərin fırlanması, yəni. yeni indeks yaradaraq ən köhnəsini silərək onu 48 saata bərabər etdik (indeksdən istifadə sxeminə görə: ən çox axtarılan son 48 saat).
Bu indeks fırlanma intervalı aşağıdakı səbəblərə görədir:
Axtarış sorğusu müəyyən bir məlumat qovşağına çatdıqda, performans baxımından, ölçüsü düyünün ombasının ölçüsü ilə müqayisə oluna bilərsə, bir parça sorğulandıqda daha sərfəlidir. Bu, indeksin "isti" hissəsini yığın şəklində saxlamağa və ona tez daxil olmağa imkan verir. Çoxlu "isti hissələr" olduqda, indeks axtarışının sürəti azalır.
Bir qovşaq bir parça üzərində axtarış sorğusunu yerinə yetirməyə başlayanda, fiziki maşının hiper iş parçacığı nüvələrinin sayına bərabər olan bir sıra mövzular ayırır. Axtarış sorğusu çoxlu sayda qırıqlara təsir edərsə, o zaman mövzuların sayı mütənasib olaraq artır. Bu, axtarış sürətinə mənfi təsir göstərir və yeni məlumatların indeksləşdirilməsinə mənfi təsir göstərir.
Lazımi axtarış gecikməsini təmin etmək üçün SSD-dən istifadə etmək qərarına gəldik. Sorğuları tez bir zamanda emal etmək üçün bu konteynerləri saxlayan maşınların ən azı 56 nüvəsi olmalıdır. 56 rəqəmi, Elasticsearch-in əməliyyat zamanı yaradacağı iplərin sayını müəyyən edən şərti kifayət qədər dəyər kimi seçilmişdir. Elasitcsearch-də bir çox iplik hovuzunun parametrləri birbaşa mövcud nüvələrin sayından asılıdır, bu da öz növbəsində "daha az nüvə - daha çox qovşaq" prinsipinə uyğun olaraq klasterdəki lazımi sayda qovşaqlara birbaşa təsir göstərir.
Nəticədə, orta hesabla bir parçanın təxminən 20 giqabayt ağırlığında olduğunu və bir indeksdə 1 parça olduğunu gördük. Müvafiq olaraq, onları hər 360 saatda bir dəfə çevirsək, onda 48-i var. Hər bir indeks 15 gün üçün məlumatları ehtiva edir.
Məlumatların yazılması və oxunması sxemləri
Bu sistemdə məlumatların necə qeyd olunduğunu anlayaq.
Deyək ki, Graylog-dan koordinatora bir sorğu gəldi. Məsələn, biz 2-3 min sətiri indeksləşdirmək istəyirik.
Qreyloqdan sorğu alan koordinator ustaya sual verir: “İndeksləşdirmə sorğusunda biz xüsusi olaraq indeks göstərmişdik, lakin onun hansı parçaya yazılması göstərilməmişdi”.
Usta cavab verir: "Bu məlumatı 71 nömrəli parçaya yazın", bundan sonra o, birbaşa 71 nömrəli əsas hissənin yerləşdiyi müvafiq məlumat qovşağına göndərilir.
Bundan sonra əməliyyat jurnalı başqa bir məlumat mərkəzində yerləşən replika-shard-a təkrarlanır.
Qreyloqdan koordinatora axtarış sorğusu gəlir. Koordinator onu indeksə uyğun olaraq yönləndirir, Elasticsearch isə round-robin prinsipindən istifadə edərək ilkin-shard və replika-shard arasında sorğuları paylayır.
180 qovşaq qeyri-bərabər cavab verir və onlar cavab verərkən koordinator daha sürətli məlumat qovşaqları tərəfindən artıq “tüpürülmüş” məlumatları toplayır. Bundan sonra, ya bütün məlumatlar çatdıqda və ya sorğunun vaxtı çatdıqda, o, hər şeyi birbaşa müştəriyə verir.
Bütün bu sistem orta hesabla son 48 saat ərzində axtarış sorğularını 300-400 ms-də emal edir, aparıcı işarəsi olan sorğular istisna olmaqla.
Elasticsearch ilə çiçəklər: Java quraşdırma
Hər şeyin ilkin olaraq istədiyimiz kimi işləməsi üçün biz çoxluqda çoxlu sayda şeyləri sazlamaq üçün çox vaxt sərf etdik.
Aşkar edilmiş problemlərin birinci hissəsi Java-nın Elasticsearch-də defolt olaraq əvvəlcədən konfiqurasiya edilməsi ilə bağlı idi.
Problem bir
Biz çox sayda hesabat gördük ki, Lucene səviyyəsində, fon işləri işləyərkən, Lucene seqmentinin birləşmələri xəta ilə uğursuz olur. Eyni zamanda, qeydlərdə bunun OutOfMemoryError xətası olduğu aydın görünürdü. Telemetriyadan ombanın sərbəst olduğunu gördük və bu əməliyyatın niyə uğursuz olduğu aydın deyildi.
Məlum oldu ki, Lucene indeksinin birləşmələri omba xaricində baş verir. Və konteynerlər istehlak olunan resurslar baxımından olduqca ciddi şəkildə məhduddur. Bu resurslara yalnız yığın sığa bilərdi (heap.size dəyəri təxminən RAM-ə bərabər idi) və bəzi yığın əməliyyatları limitdən əvvəl qalan ~500MB-a uyğun gəlmirsə, yaddaşın ayrılması xətası ilə qəzaya uğradı.
Düzəliş olduqca mənasız idi: konteyner üçün mövcud olan RAM miqdarı artırıldı, bundan sonra belə problemlərimiz olduğunu unutduq.
Problem ikinci
Klaster işə salındıqdan 4-5 gün sonra məlumat qovşaqlarının vaxtaşırı klasterdən çıxmağa və 10-20 saniyədən sonra daxil olmağa başladığını müşahidə etdik.
Bunu anlamağa başlayanda məlum oldu ki, Elasticsearch-dəki bu yığın yaddaşı heç bir şəkildə idarə olunmur. Konteynerə daha çox yaddaş verdiyimiz zaman biz birbaşa bufer hovuzlarını müxtəlif məlumatlarla doldura bildik və o, yalnız Elasticsearch-dən açıq GC işə salındıqdan sonra təmizləndi.
Bəzi hallarda bu əməliyyat kifayət qədər uzun çəkdi və bu müddət ərzində klaster bu nodu artıq çıxmış kimi qeyd etməyi bacardı. Bu problem yaxşı təsvir edilmişdir .
Həll yolu belə idi: biz Java-nın bu əməliyyatlar üçün yığın xaricində yaddaşın böyük hissəsini istifadə etmək imkanını məhdudlaşdırdıq. Biz onu 16 giqabayt (-XX:MaxDirectMemorySize=16g) ilə məhdudlaşdırdıq, aydın GC-nin daha tez-tez çağırılmasını və daha sürətli işlənməsini təmin etdik və bununla da klasteri sabitliyi pozmadıq.
Problem üçüncü
“Ən gözlənilməz anda qovşaqların çoxluqdan çıxması” ilə bağlı problemlərin bitdiyini düşünürsənsə, yanılırsan.
İndekslərlə işi konfiqurasiya etdikdə mmapf-ləri seçdik böyük seqmentasiya ilə təzə qırıqlar üzərində. Bu, kifayət qədər kobud səhv idi, çünki mmapfs istifadə edərkən fayl RAM-a uyğunlaşdırılır və sonra biz xəritələnmiş faylla işləyirik. Buna görə də məlum olur ki, GC tətbiqdəki mövzuları dayandırmağa çalışdıqda, biz çox uzun müddət təhlükəsiz nöqtəyə gedirik və ona gedən yolda proqram onun canlı olub-olmaması ilə bağlı masterun sorğularına cavab verməyi dayandırır. . Müvafiq olaraq, master qovşağın artıq çoxluqda olmadığına inanır. Bundan sonra 5-10 saniyədən sonra zibil toplayıcı işləyir, qovşaq canlanır, yenidən klasterə daxil olur və qırıqları işə salmağa başlayır. Bütün bunlar "layiq olduğumuz istehsal" kimi hiss olunurdu və ciddi bir şey üçün uyğun deyildi.
Bu davranışdan xilas olmaq üçün əvvəlcə standart nioflara keçdik, sonra Elastic-in beşinci versiyalarından altıncı versiyaya köçdükdə bu problemin təkrarlanmadığı hibridləri sınadıq. Saxlama növləri haqqında daha çox oxuya bilərsiniz .
Problem dörd
Sonra rekord müddət ərzində müalicə etdiyimiz başqa bir çox maraqlı problem oldu. Naxışı tamamilə anlaşılmaz olduğu üçün 2-3 ay tutduq.
Bəzən koordinatorlarımız, adətən nahardan sonra, Full GC-yə gedirdilər və oradan heç qayıtmırdılar. Eyni zamanda, GC gecikməsini qeyd edərkən, belə görünürdü: hər şey yaxşı gedir, yaxşı, yaxşı və sonra bir dəfə - və hər şey birdən pisdir.
Əvvəlcə düşündük ki, koordinatoru iş rejimindən çıxaran bir növ sorğu göndərən pis istifadəçimiz var. Nə baş verdiyini anlamağa çalışaraq çox uzun müddət sorğuları daxil etdik.
Nəticədə məlum oldu ki, istifadəçi nəhəng sorğu başlatdıqda və o, konkret Elasticsearch koordinatoruna çatdıqda bəzi qovşaqlar digərlərindən daha uzun müddət cavab verir.
Və koordinator bütün qovşaqlardan cavab gözləyərkən, artıq cavab vermiş qovşaqlardan göndərilən nəticələri toplayır. GC üçün bu o deməkdir ki, yığın istifadə nümunələrimiz çox tez dəyişir. İstifadə etdiyimiz GC bu işin öhdəsindən gələ bilmədi.
Bu vəziyyətdə klasterin davranışını dəyişdirmək üçün tapdığımız yeganə həll JDK13-ə köçmək və Shenandoah zibil kollektorundan istifadə etməkdir. Bu problemi həll etdi, koordinatorlarımız düşməyi dayandırdı.
Java ilə bağlı problemlər burada sona çatdı və bant genişliyi problemləri başladı.
Elasticsearch ilə "giləmeyvə": məhsuldarlıq
Ötürmə qabiliyyəti ilə bağlı problemlər o deməkdir ki, klasterimiz sabit işləyir, lakin indeksləşdirilmiş sənədlərin sayında və manevrlər zamanı performans qeyri-kafi olur.
Qarşılaşılan ilk simptom: istehsalda bəzi "partlayışlar" zamanı, çoxlu sayda log birdən yarandıqda, Graylog-da es_rejected_execution indeksləşdirmə xətası tez-tez yanıb-sönməyə başlayır.
Bu, Elasticsearch indeksləşdirmə sorğusunu emal edə və diskdəki parçaya məlumatı yükləyə bilənə qədər thread_pool.write.queue-nin bir məlumat qovşağında olması ilə əlaqədar idi, defolt olaraq yalnız 200 sorğunu keşləyə bilər. Və içində Bu parametr haqqında çox az şey deyilir. Yalnız maksimum iplik sayı və standart ölçü göstərilir.
Əlbəttə ki, biz bu dəyəri bükməyə getdik və aşağıdakıları tapdıq: xüsusən, quraşdırmamızda 300-ə qədər sorğu kifayət qədər yaxşı yaddaşda saxlanılır və daha yüksək dəyər yenidən Tam GC-yə uçmağımızla doludur.
Bundan əlavə, bunlar bir sorğuya daxil olan mesajlar toplusu olduğundan, Graylog-u düzəltmək lazım idi ki, o, tez-tez və kiçik partiyalarla deyil, böyük partiyalarla və ya partiya hələ də tamamlanmayıbsa, hər 3 saniyədə bir dəfə yazsın. Bu halda məlum olur ki, Elasticsearch-də yazdığımız məlumat iki saniyəyə deyil, beşə (bu, bizə çox uyğun gəlir), lakin böyük bir axtarışdan keçmək üçün edilməli olan təkrar trayların sayına çatır. məlumat yığını azalır.
Bu, bir şeyin haradasa qəzaya uğradığı və tamamilə spam Elastik almamaq üçün bu barədə qəzəblə xəbər verdiyi anlarda xüsusilə vacibdir və bir müddət sonra - tıxanmış tamponlar səbəbindən işləməyən Graylog qovşaqları.
Bundan əlavə, istehsalda eyni partlayışlar baş verəndə, proqramçılardan və testerlərdən şikayətlər aldıq: bu jurnallara həqiqətən ehtiyac duyduqları anda onlara çox yavaş verildi.
Bunu anlamağa başladılar. Bir tərəfdən, həm axtarış sorğularının, həm də indeksləşdirmə sorğularının mahiyyətcə eyni fiziki maşınlarda işləndiyi və bu və ya digər şəkildə müəyyən çatışmazlıqların olacağı aydın idi.
Lakin bu, Elasticsearch-in altıncı versiyalarında təsadüfi dəyirmi sistem prinsipinə (indeksləşdirmə aparan və ilkin məzmunu saxlayan konteyner) uyğun olmayan müvafiq məlumat qovşaqları arasında sorğuları paylamağa imkan verən bir alqoritmin meydana çıxması səbəbindən qismən dəf edilə bilər. -shard çox məşğul ola bilər, tez cavab vermək mümkün olmayacaq), lakin bu sorğunu daha sürətli cavab verəcək replika-shard ilə daha az yüklənmiş konteynerə yönləndirmək. Başqa sözlə, biz use_adaptive_replica_selection-a gəldik: doğru.
Oxuma şəkli belə görünməyə başlayır:
Bu alqoritmə keçid, yazmaq üçün çoxlu jurnal axınımız olduğu anlarda sorğu vaxtını əhəmiyyətli dərəcədə yaxşılaşdırmağa imkan verdi.
Nəhayət, əsas problem məlumat mərkəzinin ağrısız çıxarılması idi.
Bir DC ilə əlaqəni itirdikdən dərhal sonra klasterdən nə istədik:
- Əgər uğursuz məlumat mərkəzində cari master varsa, o, yenidən seçiləcək və başqa bir DC-də başqa bir qovşaq rolu kimi köçürüləcək.
- Usta bütün əlçatmaz qovşaqları klasterdən tez siləcək.
- Qalanlara əsaslanaraq, o, başa düşəcək: itirilmiş məlumat mərkəzində belə və bu cür ilkin qırıqlarımız var idi, o, qalan məlumat mərkəzlərində tez bir zamanda tamamlayıcı replika parçaları təşviq edəcək və biz məlumatları indeksləşdirməyə davam edəcəyik.
- Bunun nəticəsində klasterin yazma və oxuma qabiliyyəti tədricən pisləşəcək, lakin ümumilikdə hər şey yavaş-yavaş, lakin sabit şəkildə işləyəcək.
Məlum oldu ki, biz belə bir şey istədik:
Və aşağıdakıları əldə etdik:
Bu necə oldu?
Məlumat mərkəzi yıxılanda ustamız darboğaz oldu.
Niyə?
Fakt budur ki, ustanın çoxluqda müəyyən tapşırıqları və hadisələri yaymaqdan məsul olan TaskBatcher var. İstənilən node çıxışı, hər hansı bir parçanın replikadan birinciliyə yüksəldilməsi, haradasa parça yaratmaq üçün istənilən tapşırıq - bütün bunlar əvvəlcə TaskBatcher-ə gedir, burada o, ardıcıl və bir ipdə işlənir.
Bir məlumat mərkəzi geri çəkilərkən məlum oldu ki, sağ qalan məlumat mərkəzlərindəki bütün məlumat qovşaqları ustaya “biz filan və filan məlumat qovşaqlarını itirmişik” məlumat verməyi öz vəzifəsi hesab edir.
Eyni zamanda, sağ qalan məlumat qovşaqları bütün bu məlumatları hazırkı ustaya göndərdi və onun qəbul etdiyini təsdiqləməsini gözləməyə çalışdı. Bunu gözləmirdilər, çünki usta cavab verə biləcəyindən daha tez tapşırıqlar alırdı. Düyünlər təkrarlanan istəkləri başa vurdu və bu zaman usta onlara cavab verməyə belə cəhd etmədi, lakin istəkləri prioritetlərə görə çeşidləmək vəzifəsi ilə tamamilə məşğul oldu.
Terminal şəklində, məlumat qovşaqlarının master-ı tam GC-yə daxil olana qədər spam etdiyi ortaya çıxdı. Bundan sonra bizim master rolumuz növbəti qovşaqlara keçdi, onunla tamamilə eyni şey oldu və nəticədə klaster tamamilə çökdü.
Ölçmələr apardıq və bunun düzəldildiyi 6.4.0 versiyasından əvvəl klasteri tamamilə bağlamaq üçün eyni vaxtda 10-dan yalnız 360 məlumat qovşağı çıxarmağımız kifayət idi.
Bu kimi bir şey görünürdü:
Bu dəhşətli səhvin düzəldildiyi 6.4.0 versiyasından sonra məlumat qovşaqları masterı öldürməyi dayandırdı. Ancaq bu, onu “daha ağıllı” etmədi. Məhz: 2, 3 və ya 10 (birdən başqa hər hansı bir rəqəm) məlumat qovşağını çıxardıqda, master A qovşağının getdiyini bildirən ilk mesajı alır və bu barədə B qovşağına, C qovşağına, D qovşağına məlumat verməyə çalışır.
Hal-hazırda, bu, yalnız kiməsə nəyisə söyləmək cəhdləri üçün təxminən 20-30 saniyəyə bərabər bir müddət təyin etməklə həll edilə bilər və bununla da məlumat mərkəzinin klasterdən kənara çıxma sürətinə nəzarət edə bilər.
Prinsipcə, bu, layihənin bir hissəsi kimi ilkin olaraq son məhsula təqdim olunan tələblərə uyğundur, lakin "saf elm" nöqteyi-nəzərindən bu bir səhvdir. Bu, yeri gəlmişkən, 7.2 versiyasında tərtibatçılar tərəfindən uğurla düzəldilmişdir.
Üstəlik, müəyyən bir məlumat qovşağı çıxanda məlum oldu ki, onun çıxışı haqqında məlumatın yayılması bütün klasterə onun üzərində filan və belə ilkin qırıntıların olduğunu bildirməkdən daha vacibdir (başqa bir məlumatda bir replika-shard təşviq etmək üçün). ibtidai mərkəzdə və onların üzərində məlumat yazıla bilər).
Buna görə də, hər şey artıq söndükdə, buraxılmış məlumat qovşaqları dərhal köhnəlmiş kimi qeyd edilmir. Müvafiq olaraq, buraxılmış məlumat qovşaqlarına bütün pinglərin vaxtı bitənə qədər gözləmək məcburiyyətindəyik və yalnız bundan sonra klasterimiz bizə orada, orada və orada məlumat yazmağa davam etməliyik deməyə başlayır. Bu barədə ətraflı oxuya bilərsiniz .
Nəticədə, bu gün data mərkəzinin çıxarılması əməliyyatı pik saatlarda təxminən 5 dəqiqə çəkir. Belə böyük və yöndəmsiz kolossus üçün bu olduqca yaxşı nəticədir.
Nəticədə aşağıdakı qərara gəldik:
- 360 gigabayt diskləri olan 700 məlumat qovşağımız var.
- Bu eyni məlumat qovşaqları vasitəsilə trafikin yönləndirilməsi üçün 60 koordinator.
- 40-dan əvvəlki versiyalardan bəri bir növ miras olaraq qoyduğumuz 6.4.0 usta - məlumat mərkəzinin geri çəkilməsindən sağ çıxmaq üçün, hətta ustaların kvorumuna zəmanət vermək üçün zehni olaraq bir neçə maşını itirməyə hazır idik. ən pis vəziyyət ssenarisi
- Rolları bir konteynerdə birləşdirmək üçün hər hansı cəhdlər, gec-tez düyünün yük altında qırılacağı ilə qarşılandı.
- Bütün klaster 31 giqabaytlıq heap.size istifadə edir: ölçüsü azaltmaq üçün edilən bütün cəhdlər ya bəzi qovşaqların məhv edilməsinə, ya da aparıcı joker işarə ilə ağır axtarış sorğularında Elasticsearch-də elektron açarın qırılmasına səbəb oldu.
- Bundan əlavə, axtarış performansını təmin etmək üçün masterda əldə etdiyimiz darboğazda mümkün qədər az hadisəni emal etmək üçün klasterdəki obyektlərin sayını mümkün qədər az saxlamağa çalışdıq.
Nəhayət, monitorinq haqqında
Bütün bunların nəzərdə tutulduğu kimi işləməsini təmin etmək üçün biz aşağıdakılara nəzarət edirik:
- Hər bir məlumat qovşağı bizim buludumuza onun mövcud olduğunu bildirir və onun üzərində filan və belə qırıqlar var. Biz haradasa nəyisə söndürəndə klaster 2-3 saniyədən sonra bildirir ki, A mərkəzində biz 2, 3 və 4-cü qovşaqları söndürmüşük - bu o deməkdir ki, digər məlumat mərkəzlərində biz heç bir halda yalnız bir parçanın olduğu qovşaqları söndürə bilmərik. sol.
- Ustanın davranışının xarakterini bilərək, biz gözlənilən tapşırıqların sayına çox diqqətlə baxırıq. Çünki hətta bir ilişib qalmış tapşırıq, vaxtında başa çatmazsa, nəzəri olaraq bəzi fövqəladə vəziyyətdə, məsələn, birincildə bir replika parçasının təşviqi işləməməsinin səbəbi ola bilər, buna görə də indeksləşdirmə fəaliyyətini dayandıracaq.
- Zibil yığanların gecikmələrinə də çox diqqətlə baxırıq, çünki optimallaşdırma zamanı bununla bağlı artıq böyük çətinliklərlə üzləşmişik.
- Darboğazın harada olduğunu əvvəlcədən başa düşmək üçün iplə rədd edir.
- Yaxşı, yığın, RAM və I/O kimi standart ölçülər.
Monitorinq qurarkən Elasticsearch-də Thread Pool-un xüsusiyyətlərini nəzərə almalısınız. axtarış və indeksləşdirmə üçün konfiqurasiya seçimlərini və standart dəyərləri təsvir edir, lakin thread_pool.management haqqında tamamilə səssizdir.Bu mövzular, xüsusən, monitorinq yazarkən istifadə etmək üçün əlverişli olan _cat/shards və digər oxşar sorğuları emal edir. Klaster nə qədər böyükdürsə, vaxt vahidi üçün bu cür sorğular bir o qədər çox yerinə yetirilir və yuxarıda qeyd olunan thread_pool.management nəinki rəsmi sənədlərdə təqdim edilmir, həm də standart olaraq 5 mövzu ilə məhdudlaşır ki, bu da çox tez silinir. hansı monitorinq düzgün işləməyi dayandırır.
Sonda nə demək istəyirəm: biz bunu etdik! Biz proqramçılarımıza və tərtibatçılarımıza demək olar ki, istənilən vəziyyətdə istehsalda baş verənlər haqqında məlumatı tez və etibarlı şəkildə təqdim edə bilən alət verə bildik.
Bəli, olduqca mürəkkəb olduğu ortaya çıxdı, amma buna baxmayaraq, istəklərimizi özümüz üçün yamaq və yenidən yazmaq məcburiyyətində qalmadığımız mövcud məhsullara uyğunlaşdıra bildik.
Mənbə: www.habr.com