Birçok kişi Elasticsearch'te sorun yaşıyor. Peki günlükleri "özellikle büyük bir hacimde" depolamak için kullanmak istediğinizde ne olur? Ayrıca birden fazla veri merkezinden herhangi birinin arızalanması acısız bir deneyim midir? Ne tür bir mimari yapmalısınız ve hangi tuzaklarla karşılaşacaksınız?
Biz Odnoklassniki olarak log yönetimi sorununu çözmek için elasticsearch'ü kullanmaya karar verdik ve şimdi hem mimari hem de tuzaklar hakkındaki deneyimlerimizi Habr ile paylaşıyoruz.
Ben Pyotr Zaitsev, Odnoklassniki'de sistem yöneticisi olarak çalışıyorum. Ondan önce ben de yöneticiydim, Manticore Search, Sphinx search, Elasticsearch ile çalıştım. Belki başka bir ...arama ortaya çıkarsa, muhtemelen onunla da çalışacağım. Ayrıca gönüllü olarak birçok açık kaynak projesine katılıyorum.
Odnoklassniki'ye geldiğimde röportajda pervasızca Elasticsearch ile çalışabileceğimi söyledim. İşe alıştıktan ve bazı basit görevleri tamamladıktan sonra, o zamanlar var olan günlük yönetim sistemini yeniden düzenlemek gibi büyük bir görev bana verildi.
Gereksinimler
Sistem gereksinimleri şu şekilde formüle edildi:
- Graylog ön uç olarak kullanılacaktı. Şirketin bu ürünü kullanma deneyimi zaten olduğundan, programcılar ve testçiler bunu biliyorlardı, onlar için tanıdık ve kullanışlıydı.
- Veri hacmi: saniyede ortalama 50-80 bin mesaj, ancak bir şey bozulursa trafik hiçbir şeyle sınırlı değildir, saniyede 2-3 milyon satır olabilir
- Müşterilerle arama sorgularını işleme hızına ilişkin gereksinimleri tartıştıktan sonra, böyle bir sistemi kullanmanın tipik modelinin şu şekilde olduğunu fark ettik: insanlar son iki gün içindeki uygulamalarının günlüklerini arıyorlar ve bir saatten fazla beklemek istemiyorlar. formüle edilmiş bir sorgunun sonucu için ikincisi.
- Yöneticiler, sistemin nasıl çalıştığını derinlemesine araştırmalarına gerek kalmadan, gerektiğinde sistemin kolayca ölçeklenebilmesi konusunda ısrar etti.
- Öyle ki bu sistemlerin periyodik olarak ihtiyaç duyduğu tek bakım görevi bazı donanımların değiştirilmesidir.
- Buna ek olarak, Odnoklassniki'nin mükemmel bir teknik geleneği var: Başlattığımız herhangi bir hizmet, bir veri merkezi arızasından (ani, plansız ve kesinlikle herhangi bir zamanda) kurtulmalıdır.
Bu projenin hayata geçirilmesindeki son gereklilik bize en pahalıya mal oldu, bundan daha detaylı bahsedeceğim.
Çarşamba
Dört veri merkezinde çalışıyoruz, ancak Elasticsearch veri düğümleri yalnızca üç veri merkezinde bulunabiliyor (bir takım teknik olmayan nedenlerden dolayı).
Bu dört veri merkezi, donanım, konteynerler, sanal makineler olmak üzere yaklaşık 18 bin farklı log kaynağı içeriyor.
Önemli özellik: küme kapsayıcılarda başlar fiziksel makinelerde değil, . Konteynerler, 2Ghz v2.0'e benzer şekilde 4 çekirdek garantilidir ve boşta kalmaları durumunda kalan çekirdeklerin geri dönüştürülmesi olanağı vardır.
Başka bir deyişle:
Topoloji
Başlangıçta çözümün genel formunu şu şekilde gördüm:
- Graylog alanının A kaydının arkasında 3-4 VIP bulunur, logların gönderildiği adres burasıdır.
- her VIP bir LVS dengeleyicisidir.
- Bundan sonra loglar Graylog piline gider, verilerin bir kısmı GELF formatında, bir kısmı da syslog formatındadır.
- Daha sonra tüm bunlar büyük gruplar halinde bir dizi Elasticsearch koordinatörüne yazılır.
- Ve onlar da karşılık olarak ilgili veri düğümlerine yazma ve okuma istekleri gönderirler.
terminoloji
Belki herkes terminolojiyi ayrıntılı olarak anlamıyor, bu yüzden biraz üzerinde durmak istiyorum.
Elasticsearch'ün çeşitli düğüm türleri vardır: ana, koordinatör, veri düğümü. Farklı log dönüşümleri ve farklı kümeler arasındaki iletişim için iki tür daha vardır, ancak biz yalnızca listelenenleri kullandık.
usta
Kümede bulunan tüm düğümlere ping gönderir, güncel bir küme haritası tutar ve bunu düğümler arasında dağıtır, olay mantığını işler ve küme çapında çeşitli türlerde temizlik gerçekleştirir.
Koordinatör
Tek bir görevi gerçekleştirir: İstemcilerden gelen okuma veya yazma isteklerini kabul eder ve bu trafiği yönlendirir. Bir yazma isteği olması durumunda, büyük ihtimalle master'a ilgili indeksin hangi parçasını koyması gerektiğini soracak ve isteği daha ileriye yönlendirecektir.
Veri düğümü
Verileri depolar, dışarıdan gelen arama sorgularını gerçekleştirir ve üzerinde bulunan parçalar üzerinde işlemler gerçekleştirir.
grilog
Bu, Kibana'nın bir ELK yığınında Logstash ile füzyonu gibi bir şey. Graylog hem kullanıcı arayüzünü hem de günlük işleme hattını birleştirir. Graylog, arka planda Graylog'a küme olarak bağlantı sağlayan Kafka ve Zookeeper'ı çalıştırıyor. Graylog, Elasticsearch'ün kullanılamaması durumunda günlükleri (Kafka) önbelleğe alabilir ve başarısız okuma ve yazma isteklerini tekrarlayabilir, günlükleri belirlenen kurallara göre gruplayabilir ve işaretleyebilir. Logstash gibi Graylog da satırları Elasticsearch'e yazmadan önce değiştirme işlevine sahiptir.
Ek olarak Graylog, mevcut bir Elasticsearch düğümünü temel alarak tüm küme haritasının elde edilmesine ve belirli bir etikete göre filtrelenmesine olanak tanıyan yerleşik bir hizmet keşfine sahiptir; bu da isteklerin belirli kapsayıcılara yönlendirilmesini mümkün kılar.
Görsel olarak şöyle bir şeye benziyor:
Bu belirli bir örneğin ekran görüntüsüdür. Burada arama sorgusuna dayalı bir histogram oluşturuyoruz ve ilgili satırları görüntülüyoruz.
Endeksler
Sistem mimarisine dönersek, her şeyin doğru çalışması için indeks modelini nasıl oluşturduğumuz üzerinde daha detaylı durmak istiyorum.
Yukarıdaki şemada bu en düşük seviyedir: Elasticsearch veri düğümleri.
Dizin, Elasticsearch parçalarından oluşan büyük bir sanal varlıktır. Parçalardan her biri kendi içinde bir Lucene endeksinden başka bir şey değil. Ve her Lucene endeksi bir veya daha fazla bölümden oluşur.
Tasarım yaparken, büyük miktarda veri üzerinde okuma hızı gereksinimini karşılamak için bu verileri veri düğümleri arasında eşit bir şekilde "yaymamız" gerektiğini düşündük.
Bu, dizin başına parça sayısının (kopyalarla birlikte) veri düğümlerinin sayısına tam olarak eşit olması gerektiği gerçeğiyle sonuçlandı. Öncelikle replikasyon faktörünün ikiye eşit olmasını sağlamak için (yani kümenin yarısını kaybedebiliriz). İkincisi, kümenin en az yarısında okuma ve yazma isteklerini işlemek için.
Depolama süresini ilk olarak 30 gün olarak belirledik.
Parçaların dağılımı grafiksel olarak aşağıdaki gibi gösterilebilir:
Koyu gri dikdörtgenin tamamı bir indekstir. Soldaki kırmızı kare, dizindeki ilk parça olan birincil parçadır. Mavi kare ise bir kopya parçası. Farklı veri merkezlerinde bulunurlar.
Başka bir parça eklediğimizde üçüncü veri merkezine gidiyor. Ve sonunda veri tutarlılığını kaybetmeden DC'yi kaybetmeyi mümkün kılan bu yapıyı elde ediyoruz:
Endekslerin rotasyonu, yani. yeni bir indeks oluşturup en eskisini silerek 48 saate eşitledik (indeks kullanım şekline göre: en sık son 48 saat aranıyor).
Bu indeks dönüş aralığı aşağıdaki nedenlerden kaynaklanmaktadır:
Bir arama isteği belirli bir veri düğümüne ulaştığında, performans açısından bakıldığında, boyutu düğümün kalça boyutuyla karşılaştırılabilirse, bir parçanın sorgulanması daha karlı olur. Bu, endeksin "sıcak" kısmını bir yığın halinde tutmanıza ve ona hızlı bir şekilde erişmenize olanak tanır. Çok fazla “sıcak parça” olduğunda indeks arama hızı düşer.
Bir düğüm, bir parça üzerinde arama sorgusu yürütmeye başladığında, fiziksel makinenin hiper iş parçacıklı çekirdek sayısına eşit sayıda iş parçacığı tahsis eder. Bir arama sorgusu çok sayıda parçayı etkiliyorsa iş parçacığının sayısı da orantılı olarak artar. Bunun arama hızı üzerinde olumsuz etkisi vardır ve yeni verilerin indekslenmesini olumsuz etkiler.
Gerekli arama gecikmesini sağlamak için SSD kullanmaya karar verdik. İstekleri hızlı bir şekilde işlemek için bu konteynerleri barındıran makinelerin en az 56 çekirdeğe sahip olması gerekiyordu. 56 rakamı, Elasticsearch'ün çalışma sırasında üreteceği iş parçacığı sayısını belirleyen koşullu olarak yeterli bir değer olarak seçildi. Elasitcsearch'te birçok iş parçacığı havuzu parametresi doğrudan mevcut çekirdek sayısına bağlıdır ve bu da "daha az çekirdek - daha fazla düğüm" ilkesine göre kümedeki gerekli düğüm sayısını doğrudan etkiler.
Sonuç olarak, ortalama olarak bir parçanın yaklaşık 20 gigabayt ağırlığında olduğunu ve dizin başına 1 parça bulunduğunu tespit ettik. Buna göre 360 saatte bir döndürürsek 48 tane elde ederiz. Her indeks 15 güne ait verileri içerir.
Veri yazma ve okuma devreleri
Verilerin bu sisteme nasıl kaydedildiğini bulalım.
Diyelim ki Graylog'dan koordinatöre bir talep geldi. Mesela 2-3 bin satırı indekslemek istiyoruz.
Graylog'dan bir istek alan koordinatör, ustaya şu soruyu sorar: "İndeksleme talebinde özellikle bir dizin belirttik, ancak bunun hangi parçaya yazılacağı belirtilmedi."
Master yanıt verir: "Bu bilgiyi 71 numaralı parçaya yazın" ve ardından doğrudan 71 numaralı birincil parçanın bulunduğu ilgili veri düğümüne gönderilir.
Bundan sonra işlem günlüğü, başka bir veri merkezinde bulunan bir kopya parçasına kopyalanır.
Graylog'dan koordinatöre bir arama talebi gelir. Koordinatör onu dizine göre yönlendirirken, Elasticsearch istekleri birincil parça ile kopya parça arasında hepsini bir kez deneme ilkesini kullanarak dağıtır.
180 düğüm dengesiz yanıt veriyor ve onlar yanıt verirken koordinatör, daha hızlı veri düğümleri tarafından zaten "tükürülmüş" bilgileri biriktiriyor. Bundan sonra ya tüm bilgiler ulaştığında ya da istek zaman aşımına uğradığında her şeyi doğrudan istemciye verir.
Bu sistemin tamamı, başında joker karakter bulunan sorgular hariç, ortalama olarak son 48 saatteki arama sorgularını 300-400 ms'de işler.
Elasticsearch ile Çiçekler: Java kurulumu
Her şeyin başlangıçta istediğimiz gibi çalışmasını sağlamak için, kümedeki çok çeşitli şeylerin hatalarını ayıklamak için çok uzun zaman harcadık.
Keşfedilen sorunların ilk kısmı, Java'nın Elasticsearch'te varsayılan olarak önceden yapılandırılma şekliyle ilgiliydi.
İlk problem
Lucene düzeyinde, arka plan işleri çalışırken Lucene segment birleştirmelerinin bir hatayla başarısız olduğuna dair çok sayıda rapor gördük. Aynı zamanda loglarda bunun bir OutOfMemoryError hatası olduğu da açıktı. Telemetriden kalçanın serbest olduğunu gördük ve bu ameliyatın neden başarısız olduğu belli değildi.
Lucene indeksi birleşmelerinin kalça dışında meydana geldiği ortaya çıktı. Ve kaplar tüketilen kaynaklar açısından oldukça sınırlıdır. Bu kaynaklara yalnızca yığın sığabiliyordu (heap.size değeri yaklaşık olarak RAM'e eşitti) ve bazı yığın dışı işlemler, herhangi bir nedenle sınırdan önce kalan ~500 MB'a sığmadıklarında bellek ayırma hatasıyla çöktü.
Düzeltme oldukça önemsizdi: kapsayıcı için mevcut RAM miktarı artırıldı, ardından bu tür sorunlar yaşadığımızı bile unuttuk.
İkinci sorun
Kümenin lansmanından 4-5 gün sonra veri düğümlerinin periyodik olarak kümenin dışına çıkıp 10-20 saniye sonra kümeye girmeye başladığını fark ettik.
Bunu anlamaya başladığımızda, Elasticsearch'teki bu yığın dışı belleğin hiçbir şekilde kontrol edilmediği ortaya çıktı. Container'a daha fazla bellek verdiğimizde doğrudan arabellek havuzlarını çeşitli bilgilerle doldurabildik ve bu ancak Elasticsearch'ten açık GC başlatıldıktan sonra temizlendi.
Bazı durumlarda bu işlem oldukça uzun sürdü ve bu süre zarfında küme bu düğümü zaten çıkılmış olarak işaretlemeyi başardı. Bu sorun iyi tanımlanmış .
Çözüm şuydu: Java'nın bu işlemler için yığın dışındaki belleğin büyük kısmını kullanma yeteneğini sınırladık. Bunu 16 gigabayt (-XX:MaxDirectMemorySize=16g) ile sınırlandırdık, böylece açık GC'nin çok daha sık çağrılmasını ve çok daha hızlı işlenmesini, dolayısıyla kümenin istikrarını bozmamasını sağladık.
Üçüncü sorun
“Node’ların en beklenmedik anda kümeden ayrılması” ile ilgili sorunların bittiğini düşünüyorsanız yanılıyorsunuz.
Çalışmayı indekslerle yapılandırırken mmapfs'i seçtik. harika segmentasyona sahip yeni parçalarda. Bu oldukça büyük bir hataydı, çünkü mmapfs kullanıldığında dosya RAM'e eşlenir ve biz de eşlenen dosyayla çalışırız. Bu nedenle, GC uygulamadaki iş parçacıklarını durdurmaya çalıştığında, çok uzun bir süre boyunca kayıt noktasına gittiğimiz ve bu yolda uygulamanın, yöneticinin canlı olup olmadığına ilişkin isteklerine yanıt vermeyi bıraktığı ortaya çıktı. . Buna göre yönetici, düğümün artık kümede bulunmadığına inanmaktadır. Bundan sonra 5-10 saniye sonra çöp toplayıcı çalışır, düğüm canlanır, kümeye tekrar girer ve parçaları başlatmaya başlar. Her şey “hak ettiğimiz prodüksiyon”a çok benziyordu ve ciddi bir şeye uygun değildi.
Bu davranıştan kurtulmak için önce standart niof'lara geçtik, ardından Elastic'in beşinci versiyonundan altıncı versiyonuna geçtiğimizde hybridfs'i denedik, burada bu sorun tekrarlanmadı. Depolama türleri hakkında daha fazla bilgi edinebilirsiniz .
Dördüncü sorun
Sonra rekor bir süre boyunca tedavi ettiğimiz çok ilginç bir sorun daha vardı. 2-3 ay kadar yakaladık çünkü deseni kesinlikle anlaşılmazdı.
Koordinatörlerimiz bazen öğle yemeğinden sonra Full GC'ye gidiyor ve oradan bir daha geri dönmüyordu. Aynı zamanda, GC gecikmesini kaydederken şöyle görünüyordu: her şey iyi gidiyor, iyi, iyi ve sonra aniden her şey çok kötü gidiyor.
İlk başta, koordinatörü çalışma modundan çıkaracak bir tür istek başlatan kötü bir kullanıcımız olduğunu düşündük. Ne olduğunu anlamaya çalışarak çok uzun bir süre istekleri kaydettik.
Sonuç olarak, bir kullanıcının büyük bir istek başlattığı ve bu isteğin belirli bir Elasticsearch koordinatörüne ulaştığı anda, bazı düğümlerin diğerlerinden daha uzun yanıt verdiği ortaya çıktı.
Koordinatör tüm düğümlerden yanıt beklerken, daha önce yanıt vermiş olan düğümlerden gönderilen sonuçları toplar. GC için bu, yığın kullanım modellerimizin çok hızlı değiştiği anlamına gelir. Ve kullandığımız GC bu görevle baş edemedi.
Bu durumda kümenin davranışını değiştirmek için bulduğumuz tek çözüm JDK13'e geçiş ve Shenandoah çöp toplayıcının kullanılmasıdır. Bu sorunu çözdü, koordinatörlerimiz düşmeyi bıraktı.
Java ile ilgili sorunların bittiği ve bant genişliği sorunlarının başladığı yer burasıdır.
Elasticsearch ile "Meyveler": verim
Verimle ilgili sorunlar, kümemizin istikrarlı bir şekilde çalıştığı anlamına gelir, ancak dizine eklenen belge sayısının zirve yaptığı anlarda ve manevralar sırasında performansın yetersiz olduğu anlamına gelir.
Karşılaşılan ilk belirti: üretimdeki bazı "patlamalar" sırasında, aniden çok fazla sayıda log oluşturulduğunda, Graylog'da es_rejected_execution indeksleme hatası sık sık yanıp sönmeye başlar.
Bunun nedeni, Elasticsearch'ün indeksleme isteğini işleyebildiği ve bilgileri diskteki parçaya yükleyebildiği ana kadar, bir veri düğümündeki thread_pool.write.queue'nin varsayılan olarak yalnızca 200 isteği önbelleğe alabilmesidir. Ve Bu parametre hakkında çok az şey söyleniyor. Yalnızca maksimum iş parçacığı sayısı ve varsayılan boyut belirtilir.
Elbette bu değeri değiştirmeye gittik ve şunu öğrendik: özellikle kurulumumuzda 300'e kadar istek oldukça iyi bir şekilde önbelleğe alınıyor ve daha yüksek bir değer, tekrar Tam GC'ye uçmamız gerçeğiyle dolu.
Ek olarak, bunlar tek bir istek içinde gelen mesaj grupları olduğundan, Graylog'un sık sık ve küçük gruplar halinde değil, büyük gruplar halinde veya grup hala tamamlanmadıysa her 3 saniyede bir yazacak şekilde ayarlanması gerekiyordu. Bu durumda, Elasticsearch'te yazdığımız bilginin iki saniyede değil, beş saniyede (ki bu bize çok yakışıyor) ancak büyük bir alanı geçmek için yapılması gereken yeniden tarama sayısının elde edilebildiği ortaya çıkıyor. bilgi yığını azalır.
Bu, özellikle bir şeyin bir yere çarptığı ve tamamen spam gönderilen bir Elastik ve bir süre sonra tıkalı arabellekler nedeniyle çalışamayan Graylog düğümleri almamak için öfkeyle rapor ettiği anlarda önemlidir.
Ayrıca üretimde aynı patlamaları yaşadığımızda programcılardan ve testçilerden şikayetler aldık: Bu günlüklere gerçekten ihtiyaç duydukları anda, onlara çok yavaş verildi.
Bunu çözmeye başladılar. Bir yandan, hem arama sorgularının hem de dizin oluşturma sorgularının esas olarak aynı fiziksel makinelerde işlendiği ve şu ya da bu şekilde belirli dezavantajların olacağı açıktı.
Ancak, Elasticsearch'ün altıncı sürümlerinde, sorguları rastgele çevrim ilkesine (indekslemeyi yapan ve birincil verileri tutan kap) göre değil, ilgili veri düğümleri arasında dağıtmanıza olanak tanıyan bir algoritmanın ortaya çıkması nedeniyle bu kısmen aşılabilir. Shard çok meşgul olabilir, hızlı yanıt vermenin bir yolu olmayacaktır), ancak bu isteği replika parçalı daha az yüklü bir konteynere iletmek, bu da çok daha hızlı yanıt verecektir. Başka bir deyişle, use_adaptive_replica_selection: true değerine ulaştık.
Okuma resmi şöyle görünmeye başlar:
Bu algoritmaya geçiş, yazmamız gereken çok sayıda günlük akışının olduğu anlarda sorgu süresini önemli ölçüde iyileştirmeyi mümkün kıldı.
Son olarak asıl sorun veri merkezinin ağrısız bir şekilde kaldırılmasıydı.
Bir DC ile bağlantıyı kaybettikten hemen sonra kümeden istediklerimiz:
- Arızalı veri merkezinde mevcut bir ana yöneticimiz varsa, yeniden seçilecek ve başka bir DC'deki başka bir düğüme rol olarak taşınacaktır.
- Master, erişilemeyen tüm düğümleri kümeden hızlı bir şekilde kaldıracaktır.
- Geriye kalanlara dayanarak anlayacaktır: Kayıp veri merkezinde şu ve bu birincil parçalara sahiptik, geri kalan veri merkezlerinde tamamlayıcı kopya parçalarını hızlı bir şekilde tanıtacak ve biz verileri indekslemeye devam edeceğiz.
- Bunun sonucunda kümenin yazma ve okuma verimi giderek düşecek, ancak genel olarak her şey yavaş da olsa istikrarlı bir şekilde çalışacak.
Anlaşıldığı üzere şöyle bir şey istedik:
Ve şunları elde ettik:
Bu nasıl oldu?
Veri merkezi çökünce efendimiz darboğaz haline geldi.
Neden?
Gerçek şu ki, yöneticinin kümedeki belirli görevleri ve olayları dağıtmaktan sorumlu olan bir TaskBatcher'ı vardır. Herhangi bir düğüm çıkışı, bir parçanın replikadan birincil parçaya herhangi bir terfisi, herhangi bir yerde bir parça oluşturmaya yönelik herhangi bir görev - bunların tümü önce sırayla ve tek bir iş parçacığında işlendiği TaskBatcher'a gider.
Bir veri merkezinin geri çekilmesi sırasında, hayatta kalan veri merkezlerindeki tüm veri düğümlerinin, ustayı "şu şu parçaları ve şu ve bu veri düğümlerini kaybettik" konusunda bilgilendirmeyi kendi görevleri olarak gördükleri ortaya çıktı.
Aynı zamanda hayatta kalan veri düğümleri tüm bu bilgileri mevcut ustaya gönderdi ve onun bunu kabul edip etmediğinin onayını beklemeye çalıştı. Usta görevleri cevaplayabileceğinden daha hızlı aldığı için bunu beklemediler. Düğümler tekrarlanan isteklerin zaman aşımına uğradı ve o sırada usta onlara yanıt vermeye bile çalışmadı, ancak istekleri önceliğe göre sıralama görevine tamamen kapılmıştı.
Terminal biçiminde, veri düğümlerinin ana öğeyi tam GC'ye gidecek noktaya kadar spam gönderdiği ortaya çıktı. Bundan sonra ana rolümüz bir sonraki düğüme geçti, kesinlikle aynı şey ona da oldu ve sonuç olarak küme tamamen çöktü.
Ölçümler yaptık ve bunun düzeltildiği 6.4.0 sürümünden önce, kümeyi tamamen kapatmak için aynı anda 10 veri düğümünden yalnızca 360'unun çıktısını almamız yeterliydi.
Şunun gibi bir şeye benziyordu:
Bu korkunç hatanın giderildiği 6.4.0 sürümünden sonra veri düğümleri ana bilgisayarı öldürmeyi bıraktı. Ancak bu onu "daha akıllı" yapmıyordu. Şöyle ki: 2, 3 veya 10 (bir dışında herhangi bir sayı) veri düğümünün çıktısını aldığımızda, yönetici, A düğümünün ayrıldığını söyleyen ilk mesajı alır ve B düğümüne, C düğümüne bunu, D düğümünü anlatmaya çalışır.
Ve şu anda bu sorun ancak birisine bir şey anlatma girişimleri için yaklaşık 20-30 saniyeye eşit bir zaman aşımı süresi ayarlayarak ve böylece veri merkezinin kümeden çıkma hızını kontrol ederek çözülebilir.
Prensip olarak bu, projenin bir parçası olarak nihai ürüne başlangıçta sunulan gereksinimlere uyuyor, ancak "saf bilim" açısından bu bir hatadır. Bu arada, geliştiriciler tarafından 7.2 sürümünde başarıyla düzeltildi.
Dahası, belirli bir veri düğümü devre dışı kaldığında, bunun çıkışıyla ilgili bilgiyi yaymanın, tüm kümeye üzerinde şu veya bu birincil parçaların bulunduğunu söylemekten daha önemli olduğu ortaya çıktı (başka bir verideki kopya parçayı teşvik etmek için) birincilde merkezde ve üzerlerine bilgi yazılabilir).
Bu nedenle, her şey zaten sona erdiğinde, serbest bırakılan veri düğümleri hemen eski olarak işaretlenmez. Buna göre, serbest bırakılan veri düğümlerine tüm ping'ler zaman aşımına uğrayana kadar beklemek zorunda kalıyoruz ve ancak bundan sonra kümemiz bize orada, orada ve orada bilgileri kaydetmeye devam etmemiz gerektiğini söylemeye başlıyor. Bu konuda daha fazlasını okuyabilirsiniz .
Sonuç olarak bugün bir veri merkezini geri çekme işlemi yoğun saatlerde yaklaşık 5 dakikamızı alıyor. Bu kadar büyük ve hantal bir dev için bu oldukça iyi bir sonuç.
Sonuç olarak şu karara vardık:
- 360 gigabayt diskli 700 veri düğümümüz var.
- Trafiği aynı veri düğümleri üzerinden yönlendirmek için 60 koordinatör.
- 40'dan önceki sürümlerden bu yana bir tür miras olarak bıraktığımız 6.4.0 ana yönetici - veri merkezinin çekilmesinden sonra hayatta kalabilmek için, zihinsel olarak birkaç makineyi kaybetmeye hazırdık, böylece bir ana bilgisayar yeter sayısına sahip olacağımızı garanti altına alabilirdik. en kötü senaryo
- Rolleri tek bir kapta birleştirme girişimleri, er ya da geç düğümün yük altında kırılacağı gerçeğiyle karşılandı.
- Kümenin tamamı 31 gigabaytlık bir heap.size kullanıyor: boyutu küçültmeye yönelik tüm girişimler ya yoğun arama sorgularında bazı düğümlerin baştaki joker karakterle öldürülmesiyle ya da devre kesicinin Elasticsearch'ün kendisinde bulunmasıyla sonuçlandı.
- Ayrıca arama performansını sağlamak için master'da yakaladığımız darboğazda mümkün olduğunca az olay işleyebilmek için kümedeki nesne sayısını mümkün olduğunca küçük tutmaya çalıştık.
Son olarak izleme hakkında
Tüm bunların amaçlandığı gibi çalıştığından emin olmak için aşağıdakileri izliyoruz:
- Her veri düğümü, bulutumuza onun var olduğunu ve üzerinde şu ve bu parçaların bulunduğunu bildirir. Bir yerde bir şeyi söndürdüğümüzde, küme 2-3 saniye sonra A merkezinde 2, 3 ve 4 numaralı düğümleri söndürdüğümüzü bildirir - bu, diğer veri merkezlerinde yalnızca bir parçanın bulunduğu düğümleri hiçbir koşulda söndüremeyeceğimiz anlamına gelir sol.
- Ustanın davranışının doğasını bildiğimizden, bekleyen görevlerin sayısına çok dikkatli bakıyoruz. Çünkü sıkışmış bir görev bile, eğer zaman içinde zaman aşımına uğramazsa, teorik olarak bazı acil durumlarda, örneğin birincilde bir kopya parçanın tanıtılmasının işe yaramamasının nedeni olabilir, bu nedenle indeksleme çalışmayı durduracaktır.
- Çöp toplayıcı gecikmelerine de çok yakından bakıyoruz çünkü optimizasyon sırasında bununla zaten büyük zorluklar yaşadık.
- Darboğazın nerede olduğunu önceden anlamak için iş parçacığına göre reddeder.
- Yığın, RAM ve G/Ç gibi standart ölçümler.
İzlemeyi oluştururken, Elasticsearch'teki İş Parçacığı Havuzunun özelliklerini dikkate almanız gerekir. arama ve indeksleme için yapılandırma seçeneklerini ve varsayılan değerleri açıklar, ancak thread_pool.management hakkında tamamen sessizdir.Bu iş parçacıkları, özellikle izleme yazarken kullanılması uygun olan _cat/shards ve diğer benzer sorguları işler. Küme ne kadar büyük olursa, birim zaman başına bu tür istekler o kadar fazla yürütülür ve yukarıda bahsedilen thread_pool.management yalnızca resmi belgelerde sunulmakla kalmaz, aynı zamanda varsayılan olarak 5 iş parçacığıyla sınırlıdır ve bu işlem tamamlandıktan sonra çok hızlı bir şekilde imha edilir. hangi izlemenin düzgün çalışmayı durdurduğu.
Sonuç olarak söylemek istediğim şey: başardık! Programcılarımıza ve geliştiricilerimize, neredeyse her durumda, üretimde olup bitenler hakkında hızlı ve güvenilir bir şekilde bilgi sağlayabilecek bir araç verebildik.
Evet, oldukça karmaşık olduğu ortaya çıktı, ancak yine de isteklerimizi kendimiz yamamak ve yeniden yazmak zorunda kalmadığımız mevcut ürünlere sığdırmayı başardık.
Kaynak: habr.com