Ramai orang bergelut dengan Elasticsearch. Tetapi apa yang berlaku apabila anda ingin menggunakannya untuk menyimpan log "dalam jumlah yang sangat besar"? Dan adakah ia juga tidak menyakitkan untuk mengalami kegagalan mana-mana beberapa pusat data? Apakah jenis seni bina yang perlu anda buat, dan apakah perangkap yang akan anda temui?
Kami di Odnoklassniki memutuskan untuk menggunakan elasticsearch untuk menyelesaikan isu pengurusan log, dan kini kami berkongsi pengalaman kami dengan Habr: tentang seni bina dan tentang perangkap.
Saya Pyotr Zaitsev, saya bekerja sebagai pentadbir sistem di Odnoklassniki. Sebelum itu, saya juga seorang pentadbir, bekerja dengan Manticore Search, Sphinx search, Elasticsearch. Mungkin, jika ... carian lain muncul, saya mungkin akan bekerja dengannya juga. Saya juga mengambil bahagian dalam beberapa projek sumber terbuka secara sukarela.
Apabila saya datang ke Odnoklassniki, saya secara melulu berkata pada temu duga bahawa saya boleh bekerja dengan Elasticsearch. Selepas saya berjinak-jinak dan menyelesaikan beberapa tugasan mudah, saya diberi tugas besar untuk memperbaharui sistem pengurusan log yang wujud pada masa itu.
Keperluan
Keperluan sistem telah dirumuskan seperti berikut:
- Graylog akan digunakan sebagai bahagian hadapan. Oleh kerana syarikat itu sudah mempunyai pengalaman menggunakan produk ini, pengaturcara dan penguji mengetahuinya, ia sudah biasa dan mudah bagi mereka.
- Jumlah data: secara purata 50-80 ribu mesej sesaat, tetapi jika sesuatu pecah, maka trafik tidak dihadkan oleh apa-apa, ia boleh menjadi 2-3 juta baris sesaat
- Setelah berbincang dengan pelanggan tentang keperluan untuk kelajuan memproses pertanyaan carian, kami menyedari bahawa corak biasa menggunakan sistem sedemikian adalah ini: orang ramai mencari log permohonan mereka untuk dua hari lepas dan tidak mahu menunggu lebih daripada satu kedua untuk hasil pertanyaan yang dirumuskan.
- Pentadbir menegaskan bahawa sistem mudah berskala jika perlu, tanpa memerlukan mereka menyelidiki secara mendalam cara ia berfungsi.
- Supaya satu-satunya tugas penyelenggaraan yang diperlukan oleh sistem ini secara berkala ialah menukar beberapa perkakasan.
- Di samping itu, Odnoklassniki mempunyai tradisi teknikal yang sangat baik: mana-mana perkhidmatan yang kami lancarkan mesti bertahan dari kegagalan pusat data (tiba-tiba, tidak dirancang dan benar-benar pada bila-bila masa).
Keperluan terakhir dalam pelaksanaan projek ini menelan kos yang paling tinggi, yang akan saya bincangkan dengan lebih terperinci.
rabu
Kami bekerja di empat pusat data, manakala nod data Elasticsearch hanya boleh ditempatkan dalam tiga (atas beberapa sebab bukan teknikal).
Empat pusat data ini mengandungi kira-kira 18 ribu sumber log yang berbeza - perkakasan, bekas, mesin maya.
Ciri penting: kluster bermula dalam bekas bukan pada mesin fizikal, tetapi pada . Bekas dijamin 2 teras, serupa dengan 2.0Ghz v4, dengan kemungkinan mengitar semula teras yang tinggal jika ia terbiar.
Dalam kata lain:
Topologi
Saya pada mulanya melihat bentuk umum penyelesaian seperti berikut:
- 3-4 VIP berada di belakang rekod A domain Graylog, ini adalah alamat yang menghantar log.
- setiap VIP adalah pengimbang LVS.
- Selepas itu, log pergi ke bateri Graylog, beberapa data dalam format GELF, beberapa dalam format syslog.
- Kemudian semua ini ditulis dalam kelompok besar kepada bateri penyelaras Elasticsearch.
- Dan mereka, seterusnya, menghantar permintaan tulis dan baca ke nod data yang berkaitan.
Terminologi
Mungkin tidak semua orang memahami istilah secara terperinci, jadi saya ingin memikirkannya sedikit.
Elasticsearch mempunyai beberapa jenis nod - induk, penyelaras, nod data. Terdapat dua jenis lain untuk transformasi log yang berbeza dan komunikasi antara kelompok yang berbeza, tetapi kami hanya menggunakan yang disenaraikan.
Master
Ia ping semua nod yang terdapat dalam kluster, mengekalkan peta kluster terkini dan mengedarkannya antara nod, memproses logik peristiwa dan melaksanakan pelbagai jenis pengemasan seluruh kluster.
Penyelaras
Menjalankan satu tugas: menerima permintaan baca atau tulis daripada pelanggan dan laluan trafik ini. Sekiranya terdapat permintaan tulis, kemungkinan besar, ia akan meminta induk bahagian indeks yang berkaitan yang harus dimasukkannya, dan akan mengubah hala permintaan itu dengan lebih lanjut.
Nod data
Menyimpan data, melakukan pertanyaan carian yang tiba dari luar dan melakukan operasi pada serpihan yang terletak di atasnya.
greylog
Ini adalah sesuatu seperti gabungan Kibana dengan Logstash dalam tindanan ELK. Graylog menggabungkan kedua-dua UI dan saluran paip pemprosesan log. Di bawah hud, Graylog menjalankan Kafka dan Zookeeper, yang menyediakan sambungan kepada Graylog sebagai satu kelompok. Graylog boleh cache log (Kafka) sekiranya Elasticsearch tidak tersedia dan mengulangi permintaan baca dan tulis yang tidak berjaya, kumpulan dan tandakan log mengikut peraturan yang ditetapkan. Seperti Logstash, Graylog mempunyai fungsi untuk mengubah suai baris sebelum menulisnya ke Elasticsearch.
Selain itu, Graylog mempunyai penemuan perkhidmatan terbina dalam yang membolehkan, berdasarkan satu nod Elasticsearch yang tersedia, untuk mendapatkan keseluruhan peta kluster dan menapisnya dengan teg tertentu, yang memungkinkan untuk mengarahkan permintaan ke bekas tertentu.
Secara visual ia kelihatan seperti ini:
Ini adalah tangkapan skrin daripada contoh tertentu. Di sini kami membina histogram berdasarkan pertanyaan carian dan memaparkan baris yang berkaitan.
Indeks
Kembali kepada seni bina sistem, saya ingin membincangkan dengan lebih terperinci tentang cara kami membina model indeks supaya semuanya berfungsi dengan betul.
Dalam rajah di atas, ini ialah tahap paling rendah: nod data Elasticsearch.
Indeks ialah entiti maya besar yang terdiri daripada serpihan Elasticsearch. Dengan sendirinya, setiap serpihan tidak lebih daripada indeks Lucene. Dan setiap indeks Lucene pula terdiri daripada satu atau lebih segmen.
Semasa mereka bentuk, kami menganggap bahawa untuk memenuhi keperluan kelajuan membaca pada sejumlah besar data, kami perlu "menyebarkan" data ini secara sama rata merentas nod data.
Ini menyebabkan fakta bahawa bilangan serpihan setiap indeks (dengan replika) harus sama dengan bilangan nod data. Pertama, untuk memastikan faktor replikasi sama dengan dua (iaitu, kita boleh kehilangan separuh daripada kelompok). Dan, kedua, untuk memproses permintaan baca dan tulis pada sekurang-kurangnya separuh daripada kluster.
Kami mula-mula menentukan masa penyimpanan sebagai 30 hari.
Taburan serpihan boleh diwakili secara grafik seperti berikut:
Keseluruhan segi empat tepat kelabu gelap ialah indeks. Petak merah kiri di dalamnya ialah serpihan utama, yang pertama dalam indeks. Dan segi empat sama biru adalah serpihan replika. Mereka terletak di pusat data yang berbeza.
Apabila kita menambah serpihan lain, ia pergi ke pusat data ketiga. Dan, pada akhirnya, kami mendapat struktur ini, yang memungkinkan untuk kehilangan DC tanpa kehilangan konsistensi data:
Putaran indeks, i.e. mencipta indeks baharu dan memadamkan indeks tertua, kami menjadikannya bersamaan dengan 48 jam (mengikut corak penggunaan indeks: 48 jam terakhir paling kerap dicari).
Selang pusingan indeks ini disebabkan oleh sebab berikut:
Apabila permintaan carian tiba pada nod data tertentu, maka, dari sudut prestasi, ia lebih menguntungkan apabila satu serpihan disoal, jika saiznya setanding dengan saiz pinggul nod. Ini membolehkan anda menyimpan bahagian "panas" indeks dalam timbunan dan mengaksesnya dengan cepat. Apabila terdapat banyak "bahagian panas", kelajuan carian indeks merosot.
Apabila nod mula melaksanakan pertanyaan carian pada satu shard, ia memperuntukkan beberapa utas yang sama dengan bilangan teras hyperthreading mesin fizikal. Jika pertanyaan carian mempengaruhi sejumlah besar serpihan, maka bilangan utas bertambah secara berkadar. Ini memberi kesan negatif pada kelajuan carian dan memberi kesan negatif kepada pengindeksan data baharu.
Untuk menyediakan kependaman carian yang diperlukan, kami memutuskan untuk menggunakan SSD. Untuk memproses permintaan dengan cepat, mesin yang mengehoskan bekas ini perlu mempunyai sekurang-kurangnya 56 teras. Angka 56 telah dipilih sebagai nilai yang cukup bersyarat yang menentukan bilangan utas yang akan dihasilkan oleh Elasticsearch semasa operasi. Dalam Elasitcsearch, banyak parameter kolam benang bergantung secara langsung pada bilangan teras yang tersedia, yang seterusnya memberi kesan secara langsung kepada bilangan nod yang diperlukan dalam kelompok mengikut prinsip "teras lebih sedikit - lebih banyak nod".
Akibatnya, kami mendapati bahawa secara purata sekeping seberat kira-kira 20 gigabait, dan terdapat 1 serpihan setiap indeks. Sehubungan itu, jika kita menggilirkannya sekali setiap 360 jam, maka kita mempunyai 48 daripadanya. Setiap indeks mengandungi data selama 15 hari.
Litar menulis dan membaca data
Mari kita fikirkan bagaimana data direkodkan dalam sistem ini.
Katakan beberapa permintaan tiba daripada Graylog kepada penyelaras. Sebagai contoh, kami ingin mengindeks 2-3 ribu baris.
Penyelaras, setelah menerima permintaan daripada Graylog, menyoal tuan: "Dalam permintaan pengindeksan, kami secara khusus menentukan indeks, tetapi di mana serpihan untuk menulisnya tidak ditentukan."
Tuan menjawab: "Tulis maklumat ini ke nombor serpihan 71," selepas itu ia dihantar terus ke nod data yang berkaitan, di mana nombor serpihan primer 71 berada.
Selepas itu log transaksi direplikasi kepada replika-serihan, yang terletak di pusat data lain.
Permintaan carian tiba dari Graylog kepada penyelaras. Penyelaras mengubah hala mengikut indeks, manakala Elasticsearch mengedarkan permintaan antara beling primer dan beling replika menggunakan prinsip round-robin.
180 nod bertindak balas secara tidak sekata, dan semasa mereka bertindak balas, penyelaras sedang mengumpul maklumat yang telah "diludahkan" oleh nod data yang lebih pantas. Selepas ini, apabila sama ada semua maklumat telah tiba, atau permintaan telah mencapai tamat masa, ia memberikan segala-galanya secara langsung kepada pelanggan.
Keseluruhan sistem ini secara purata memproses pertanyaan carian selama 48 jam terakhir dalam 300-400ms, tidak termasuk pertanyaan tersebut dengan kad bebas terkemuka.
Bunga dengan Elasticsearch: persediaan Java
Untuk menjadikan semuanya berfungsi seperti yang kami inginkan pada asalnya, kami menghabiskan masa yang sangat lama untuk menyahpepijat pelbagai jenis perkara dalam kelompok.
Bahagian pertama masalah yang ditemui adalah berkaitan dengan cara Java diprakonfigurasikan secara lalai dalam Elasticsearch.
Masalah satu
Kami telah melihat sejumlah besar laporan bahawa pada peringkat Lucene, apabila kerja latar belakang dijalankan, penggabungan segmen Lucene gagal dengan ralat. Pada masa yang sama, jelas dalam log bahawa ini adalah ralat OutOfMemoryError. Kami melihat dari telemetri bahawa pinggul adalah bebas, dan tidak jelas mengapa operasi ini gagal.
Ternyata gabungan indeks Lucene berlaku di luar pinggul. Dan bekas agak terhad dari segi sumber yang digunakan. Hanya timbunan boleh dimuatkan ke dalam sumber ini (nilai heap.size lebih kurang sama dengan RAM), dan beberapa operasi luar timbunan ranap dengan ralat peruntukan memori jika atas sebab tertentu ia tidak muat ke dalam ~500MB yang kekal sebelum had.
Pembaikan itu agak remeh: jumlah RAM yang tersedia untuk bekas telah meningkat, selepas itu kami terlupa bahawa kami juga mempunyai masalah sedemikian.
Masalah kedua
4-5 hari selepas pelancaran kluster, kami mendapati bahawa nod data mula keluar dari kluster secara berkala dan memasukinya selepas 10-20 saat.
Apabila kami mula memikirkannya, ternyata memori luar timbunan dalam Elasticsearch ini tidak dikawal dalam apa jua cara. Apabila kami memberikan lebih banyak memori kepada bekas, kami dapat mengisi kolam penimbal langsung dengan pelbagai maklumat, dan ia telah dikosongkan hanya selepas GC eksplisit dilancarkan daripada Elasticsearch.
Dalam sesetengah kes, operasi ini mengambil masa yang agak lama, dan pada masa ini kluster berjaya menandakan nod ini sebagai sudah keluar. Masalah ini diterangkan dengan baik .
Penyelesaiannya adalah seperti berikut: kami mengehadkan keupayaan Java untuk menggunakan sebahagian besar memori di luar timbunan untuk operasi ini. Kami mengehadkannya kepada 16 gigabait (-XX:MaxDirectMemorySize=16g), memastikan GC eksplisit dipanggil dengan lebih kerap dan diproses dengan lebih pantas, dengan itu tidak lagi menjejaskan kestabilan gugusan.
Masalah tiga
Jika anda berpendapat bahawa masalah dengan "nod meninggalkan kluster pada saat yang paling tidak dijangka" telah selesai, anda silap.
Apabila kami mengkonfigurasi kerja dengan indeks, kami memilih mmapfs untuk pada serpihan segar dengan pembahagian yang hebat. Ini agak kesilapan, kerana apabila menggunakan mmapfs fail dipetakan ke dalam RAM, dan kemudian kami bekerja dengan fail yang dipetakan. Oleh sebab itu, ternyata apabila GC cuba menghentikan utas dalam aplikasi, kami pergi ke safepoint untuk masa yang sangat lama, dan dalam perjalanan ke sana, aplikasi berhenti menjawab permintaan tuan tentang sama ada ia masih hidup . Sehubungan itu, tuan percaya bahawa nod tidak lagi terdapat dalam kelompok. Selepas ini, selepas 5-10 saat, pengumpul sampah berfungsi, nod menjadi hidup, memasuki kelompok semula dan mula memulakan serpihan. Semuanya terasa seperti "pengeluaran yang sepatutnya kami perolehi" dan tidak sesuai untuk sesuatu yang serius.
Untuk menyingkirkan tingkah laku ini, kami mula-mula bertukar kepada niofs standard, dan kemudian, apabila kami berhijrah daripada versi kelima Elastik ke versi keenam, kami mencuba hybridfs, di mana masalah ini tidak dihasilkan semula. Anda boleh membaca lebih lanjut tentang jenis storan .
Masalah keempat
Kemudian terdapat satu lagi masalah yang sangat menarik yang kami rawat untuk masa yang singkat. Kami menangkapnya selama 2-3 bulan kerana coraknya benar-benar tidak dapat difahami.
Kadangkala penyelaras kami pergi ke GC Penuh, biasanya selepas makan tengah hari, dan tidak pernah kembali dari sana. Pada masa yang sama, apabila log masuk kelewatan GC, ia kelihatan seperti ini: semuanya berjalan lancar, baik, baik, dan kemudian tiba-tiba semuanya berjalan dengan sangat teruk.
Pada mulanya kami menyangka bahawa kami mempunyai pengguna jahat yang melancarkan beberapa jenis permintaan yang menyebabkan penyelaras keluar daripada mod kerja. Kami log permintaan untuk masa yang sangat lama, cuba memikirkan apa yang berlaku.
Akibatnya, ternyata pada masa ini apabila pengguna melancarkan permintaan besar, dan ia sampai ke penyelaras Elasticsearch tertentu, beberapa nod bertindak balas lebih lama daripada yang lain.
Dan sementara penyelaras sedang menunggu jawapan daripada semua nod, dia mengumpul hasil yang dihantar daripada nod yang telah bertindak balas. Untuk GC, ini bermakna corak penggunaan timbunan kami berubah dengan cepat. Dan GC yang kami gunakan tidak dapat menampung tugas ini.
Satu-satunya pembaikan yang kami temui untuk mengubah tingkah laku kluster dalam situasi ini ialah penghijrahan ke JDK13 dan penggunaan pengumpul sampah Shenandoah. Ini menyelesaikan masalah, penyelaras kami berhenti jatuh.
Di sinilah masalah dengan Java berakhir dan masalah lebar jalur bermula.
"Beri" dengan Elasticsearch: throughput
Masalah dengan daya pengeluaran bermakna kluster kami berfungsi dengan stabil, tetapi pada puncak bilangan dokumen yang diindeks dan semasa manuver, prestasi tidak mencukupi.
Gejala pertama yang dihadapi: semasa beberapa "letupan" dalam pengeluaran, apabila bilangan log yang sangat besar tiba-tiba dijana, ralat pengindeksan es_rejected_execution mula berkelip dengan kerap dalam Graylog.
Ini disebabkan oleh fakta bahawa thread_pool.write.queue pada satu nod data, sehingga saat Elasticsearch dapat memproses permintaan pengindeksan dan memuat naik maklumat ke serpihan pada cakera, dapat menyimpan hanya 200 permintaan secara lalai. Dan dalam Sangat sedikit yang dikatakan tentang parameter ini. Hanya bilangan maksimum benang dan saiz lalai ditunjukkan.
Sudah tentu, kami mengubah nilai ini dan mendapati perkara berikut: khususnya, dalam persediaan kami, sehingga 300 permintaan dicache dengan baik, dan nilai yang lebih tinggi dipenuhi dengan fakta bahawa kami sekali lagi terbang ke GC Penuh.
Selain itu, memandangkan ini adalah kumpulan mesej yang tiba dalam satu permintaan, anda perlu mengubah suai Graylog supaya ia tidak kerap menulis dan dalam kelompok kecil, tetapi dalam kelompok besar atau sekali setiap 3 saat jika kumpulan masih tidak lengkap. Dalam kes ini, ternyata maklumat yang kami tulis dalam Elasticsearch tersedia bukan dalam masa dua saat, tetapi dalam lima (yang sesuai dengan kami dengan baik), tetapi bilangan ulangan yang perlu dibuat untuk menolak yang besar. timbunan maklumat dikurangkan.
Ini amat penting pada saat-saat apabila sesuatu telah terhempas di suatu tempat dan melaporkannya dengan marah, supaya tidak mendapat Elastik yang dispam sepenuhnya, dan selepas beberapa lama - nod Graylog yang tidak boleh beroperasi kerana penimbal tersumbat.
Di samping itu, apabila kami mengalami letupan yang sama dalam pengeluaran, kami menerima aduan daripada pengaturcara dan penguji: pada masa mereka benar-benar memerlukan log ini, mereka diberikan dengan sangat perlahan.
Mereka mula memikirkannya. Di satu pihak, adalah jelas bahawa kedua-dua pertanyaan carian dan pertanyaan pengindeksan telah diproses, pada asasnya, pada mesin fizikal yang sama, dan satu cara atau yang lain akan terdapat penarikan balik tertentu.
Tetapi ini boleh dielakkan sebahagiannya kerana fakta bahawa dalam versi keenam Elasticsearch, algoritma muncul yang membolehkan anda mengedarkan pertanyaan antara nod data yang berkaitan bukan mengikut prinsip round-robin rawak (bekas yang melakukan pengindeksan dan memegang utama- shard boleh menjadi sangat sibuk, tidak akan ada cara untuk bertindak balas dengan cepat), tetapi untuk memajukan permintaan ini ke bekas yang kurang dimuatkan dengan replika-shard, yang akan bertindak balas dengan lebih pantas. Dalam erti kata lain, kami tiba di use_adaptive_replica_selection: true.
Gambar bacaan mula kelihatan seperti ini:
Peralihan kepada algoritma ini memungkinkan untuk meningkatkan masa pertanyaan dengan ketara pada saat-saat ketika kami mempunyai aliran log yang besar untuk ditulis.
Akhirnya, masalah utama ialah penyingkiran pusat data yang tidak menyakitkan.
Perkara yang kami mahu daripada kluster sejurus selepas kehilangan sambungan dengan satu DC:
- Jika kita mempunyai induk semasa dalam pusat data yang gagal, maka ia akan dipilih semula dan dipindahkan sebagai peranan ke nod lain dalam DC lain.
- Tuan akan segera mengalih keluar semua nod yang tidak boleh diakses daripada kluster.
- Berdasarkan yang selebihnya, dia akan faham: dalam pusat data yang hilang kami mempunyai serpihan utama ini dan sebegitu, dia akan dengan cepat mempromosikan serpihan replika pelengkap di pusat data yang tinggal, dan kami akan terus mengindeks data.
- Akibat daripada ini, hasil penulisan dan pembacaan kluster akan beransur-ansur merosot, tetapi secara umum semuanya akan berfungsi, walaupun perlahan, tetapi stabil.
Ternyata, kami mahukan sesuatu seperti ini:
Dan kami mendapat yang berikut:
Bagaimana ini berlaku?
Apabila pusat data jatuh, tuan kami menjadi hambatan.
Mengapa?
Hakikatnya ialah tuan mempunyai TaskBatcher, yang bertanggungjawab untuk mengagihkan tugas dan acara tertentu dalam kelompok. Sebarang keluaran nod, sebarang promosi serpihan daripada replika ke utama, sebarang tugas untuk mencipta serpihan di suatu tempat - semua ini pergi dahulu ke TaskBatcher, tempat ia diproses secara berurutan dan dalam satu utas.
Pada masa penarikan satu pusat data, ternyata semua nod data dalam pusat data yang masih hidup menganggap tugas mereka untuk memaklumkan tuan "kami telah kehilangan serpihan itu dan itu dan nod data itu dan itu."
Pada masa yang sama, nod data yang masih hidup menghantar semua maklumat ini kepada tuan semasa dan cuba menunggu pengesahan bahawa dia menerimanya. Mereka tidak menunggu untuk ini, kerana tuan menerima tugas lebih cepat daripada yang dia boleh jawab. Nod telah tamat masa permintaan berulang, dan tuan pada masa ini tidak cuba menjawabnya, tetapi telah diserap sepenuhnya dalam tugas menyusun permintaan mengikut keutamaan.
Dalam bentuk terminal, ternyata nod data menghantar spam kepada induk sehingga ia pergi ke GC penuh. Selepas itu, peranan induk kami berpindah ke beberapa nod seterusnya, perkara yang sama berlaku padanya, dan akibatnya gugusan itu runtuh sepenuhnya.
Kami mengambil ukuran, dan sebelum versi 6.4.0, di mana ini telah ditetapkan, sudah cukup untuk kami mengeluarkan hanya 10 nod data secara serentak daripada 360 untuk menutup gugusan sepenuhnya.
Ia kelihatan seperti ini:
Selepas versi 6.4.0, di mana pepijat yang dahsyat ini telah diperbaiki, nod data berhenti membunuh induk. Tetapi itu tidak menjadikannya "lebih bijak." Iaitu: apabila kita mengeluarkan 2, 3 atau 10 (mana-mana nombor selain daripada satu) nod data, induk menerima beberapa mesej pertama yang mengatakan bahawa nod A telah pergi, dan cuba memberitahu nod B, nod C tentang ini, nod D.
Dan pada masa ini, ini hanya boleh ditangani dengan menetapkan tamat masa untuk percubaan memberitahu seseorang tentang sesuatu, sama dengan kira-kira 20-30 saat, dan dengan itu mengawal kelajuan pusat data yang bergerak keluar dari kluster.
Pada dasarnya, ini sesuai dengan keperluan yang pada mulanya dibentangkan kepada produk akhir sebagai sebahagian daripada projek, tetapi dari sudut pandangan "sains tulen" ini adalah pepijat. Yang, dengan cara ini, telah berjaya diperbaiki oleh pembangun dalam versi 7.2.
Lebih-lebih lagi, apabila nod data tertentu terputus, ternyata penyebaran maklumat tentang keluarnya adalah lebih penting daripada memberitahu seluruh kluster bahawa terdapat serpihan primer sedemikian dan sedemikian padanya (untuk mempromosikan serpihan replika dalam data lain pusat di sekolah rendah, dan dalam maklumat boleh ditulis pada mereka).
Oleh itu, apabila semuanya telah mati, nod data yang dikeluarkan tidak serta-merta ditandakan sebagai basi. Sehubungan itu, kami terpaksa menunggu sehingga semua ping tamat masa ke nod data yang dikeluarkan, dan hanya selepas itu kluster kami mula memberitahu kami bahawa di sana, di sana, dan di sana kami perlu terus merekodkan maklumat. Anda boleh membaca lebih lanjut tentang ini .
Akibatnya, operasi menarik balik pusat data hari ini mengambil masa kira-kira 5 minit semasa waktu sibuk. Untuk kolosus yang besar dan kekok, ini adalah hasil yang cukup baik.
Akibatnya, kami membuat keputusan berikut:
- Kami mempunyai 360 ββnod data dengan cakera 700 gigabait.
- 60 penyelaras untuk menghala trafik melalui nod data yang sama ini.
- 40 induk yang telah kami tinggalkan sebagai sejenis warisan sejak versi sebelum 6.4.0 - untuk bertahan daripada penarikan pusat data, kami telah bersedia dari segi mental untuk kehilangan beberapa mesin untuk dijamin mempunyai kuorum sarjana walaupun dalam senario kes terburuk
- Sebarang percubaan untuk menggabungkan peranan pada satu bekas telah dipenuhi dengan fakta bahawa lambat laun nod akan pecah di bawah beban.
- Keseluruhan kelompok menggunakan timbunan.saiz 31 gigabait: semua percubaan untuk mengurangkan saiz mengakibatkan sama ada membunuh beberapa nod pada pertanyaan carian berat dengan kad bebas utama atau mendapatkan pemutus litar dalam Elasticsearch itu sendiri.
- Selain itu, untuk memastikan prestasi carian, kami cuba mengekalkan bilangan objek dalam gugusan sekecil mungkin, untuk memproses sesedikit mungkin peristiwa dalam kesesakan yang kami perolehi dalam induk.
Akhir sekali tentang pemantauan
Untuk memastikan semua ini berfungsi seperti yang diharapkan, kami memantau perkara berikut:
- Setiap nod data melaporkan kepada awan kami bahawa ia wujud, dan terdapat serpihan itu dan itu. Apabila kita memadamkan sesuatu di suatu tempat, kluster melaporkan selepas 2-3 saat bahawa di tengah A kita memadamkan nod 2, 3, dan 4 - ini bermakna bahawa di pusat data lain kita dalam apa jua keadaan tidak boleh memadamkan nod yang hanya terdapat satu serpihan dibiarkan.
- Mengetahui sifat tingkah laku tuan, kami melihat dengan teliti bilangan tugas yang belum selesai. Kerana walaupun satu tugas yang tersekat, jika ia tidak tamat masa, secara teorinya dalam beberapa situasi kecemasan boleh menjadi sebab mengapa, sebagai contoh, promosi serpihan replika dalam primer tidak berfungsi, itulah sebabnya pengindeksan akan berhenti berfungsi.
- Kami juga melihat dengan teliti kelewatan pemungut sampah, kerana kami telah menghadapi kesukaran besar dengan ini semasa pengoptimuman.
- Menolak mengikut urutan untuk memahami terlebih dahulu di mana kesesakan itu.
- Nah, metrik standard seperti timbunan, RAM dan I/O.
Semasa membina pemantauan, anda mesti mengambil kira ciri Kolam Benang dalam Elasticsearch. menerangkan pilihan konfigurasi dan nilai lalai untuk carian dan pengindeksan, tetapi senyap sepenuhnya tentang thread_pool.management. Benang ini memproses, khususnya, pertanyaan seperti _cat/shards dan pertanyaan lain yang serupa, yang mudah digunakan semasa menulis pemantauan. Lebih besar kluster, lebih banyak permintaan sedemikian dilaksanakan setiap unit masa, dan thread_pool.management yang disebutkan di atas bukan sahaja tidak dibentangkan dalam dokumentasi rasmi, tetapi juga dihadkan secara lalai kepada 5 utas, yang sangat cepat dilupuskan, selepas pemantauan yang mana berhenti berfungsi dengan betul.
Apa yang saya ingin katakan sebagai kesimpulan: kami berjaya! Kami dapat memberikan alat pengaturcara dan pembangun kami yang, dalam hampir semua keadaan, boleh memberikan maklumat dengan cepat dan boleh dipercayai tentang perkara yang berlaku dalam pengeluaran.
Ya, ternyata agak rumit, tetapi, bagaimanapun, kami berjaya menyesuaikan keinginan kami dengan produk sedia ada, yang tidak perlu kami tampal dan tulis semula untuk diri kami sendiri.
Sumber: www.habr.com