इलास्टिक्स खोज क्लस्टर 200 टीबी+

बहुत से लोग Elasticsearch के साथ संघर्ष करते हैं। लेकिन क्या होता है जब आप इसका उपयोग "विशेष रूप से बड़ी मात्रा में" लॉग संग्रहीत करने के लिए करना चाहते हैं? और क्या कई डेटा केंद्रों में से किसी की विफलता का अनुभव करना भी दर्द रहित है? आपको किस प्रकार की वास्तुकला बनानी चाहिए, और आप किन कठिनाइयों का सामना करेंगे?

Odnoklassniki में हमने लॉग प्रबंधन के मुद्दे को हल करने के लिए इलास्टिक्स खोज का उपयोग करने का निर्णय लिया, और अब हम Habr के साथ अपना अनुभव साझा करते हैं: वास्तुकला और नुकसान दोनों के बारे में।

मैं प्योत्र ज़ैतसेव हूं, मैं ओडनोक्लास्निकी में एक सिस्टम प्रशासक के रूप में काम करता हूं। इससे पहले, मैं भी एक व्यवस्थापक था, मैन्टिकोर सर्च, स्फिंक्स सर्च, इलास्टिक्सर्च के साथ काम किया था। शायद, यदि कोई अन्य...खोज सामने आती है, तो मैं संभवतः उसके साथ भी काम करूंगा। मैं स्वैच्छिक आधार पर कई ओपन सोर्स परियोजनाओं में भी भाग लेता हूं।

जब मैं Odnoklassniki आया, तो मैंने साक्षात्कार में लापरवाही से कहा कि मैं Elasticsearch के साथ काम कर सकता हूं। जब मैंने इसमें महारत हासिल कर ली और कुछ सरल कार्य पूरे कर लिए, तो मुझे उस समय मौजूद लॉग प्रबंधन प्रणाली में सुधार करने का बड़ा काम दिया गया।

आवश्यकताएँ

सिस्टम आवश्यकताएँ निम्नानुसार तैयार की गईं:

• ग्रेलॉग को फ्रंटएंड के रूप में इस्तेमाल किया जाना था। क्योंकि कंपनी के पास पहले से ही इस उत्पाद का उपयोग करने का अनुभव था, प्रोग्रामर और परीक्षक इसे जानते थे, यह उनके लिए परिचित और सुविधाजनक था।
• डेटा वॉल्यूम: औसतन 50-80 हजार संदेश प्रति सेकंड, लेकिन अगर कुछ टूट जाता है, तो ट्रैफ़िक किसी भी चीज़ तक सीमित नहीं है, यह 2-3 मिलियन लाइनें प्रति सेकंड हो सकता है
• खोज क्वेरी को संसाधित करने की गति के लिए ग्राहकों के साथ आवश्यकताओं पर चर्चा करने के बाद, हमने महसूस किया कि ऐसी प्रणाली का उपयोग करने का विशिष्ट पैटर्न यह है: लोग पिछले दो दिनों से अपने एप्लिकेशन के लॉग की तलाश कर रहे हैं और इससे अधिक इंतजार नहीं करना चाहते हैं तैयार की गई क्वेरी के परिणाम के लिए दूसरा।
• प्रशासकों ने इस बात पर जोर दिया कि यदि आवश्यक हो तो सिस्टम को आसानी से स्केलेबल किया जा सकता है, इसके लिए उन्हें गहराई से जाने की आवश्यकता नहीं है कि यह कैसे काम करता है।
• इसलिए इन प्रणालियों को समय-समय पर जिस एकमात्र रखरखाव कार्य की आवश्यकता होती है वह है कुछ हार्डवेयर बदलना।
• इसके अलावा, Odnoklassniki की एक उत्कृष्ट तकनीकी परंपरा है: हम जो भी सेवा लॉन्च करते हैं उसे डेटा सेंटर विफलता (अचानक, अनियोजित और बिल्कुल किसी भी समय) से बचना चाहिए।

इस परियोजना के कार्यान्वयन में अंतिम आवश्यकता हमें सबसे अधिक महंगी पड़ी, जिसके बारे में मैं अधिक विस्तार से बात करूंगा।

बुधवार

हम चार डेटा केंद्रों में काम करते हैं, जबकि इलास्टिक्स खोज डेटा नोड्स केवल तीन में स्थित हो सकते हैं (कई गैर-तकनीकी कारणों से)।

इन चार डेटा केंद्रों में लगभग 18 हजार विभिन्न लॉग स्रोत हैं - हार्डवेयर, कंटेनर, वर्चुअल मशीन।

महत्वपूर्ण विशेषता: क्लस्टर कंटेनरों में शुरू होता है पोडमैन भौतिक मशीनों पर नहीं, बल्कि पर स्वयं का क्लाउड उत्पाद एक-क्लाउड. कंटेनरों को 2Ghz v2.0 के समान 4 कोर की गारंटी दी जाती है, यदि शेष कोर निष्क्रिय हैं तो उन्हें पुनर्चक्रित करने की संभावना है।

दूसरे शब्दों में:

टोपोलॉजी

मैंने प्रारंभ में समाधान का सामान्य रूप इस प्रकार देखा:

• ग्रेलॉग डोमेन के ए-रिकॉर्ड के पीछे 3-4 वीआईपी हैं, यह वह पता है जिस पर लॉग भेजे जाते हैं।
• प्रत्येक वीआईपी एक एलवीएस बैलेंसर है।
• इसके बाद, लॉग ग्रेलॉग बैटरी में जाते हैं, कुछ डेटा GELF प्रारूप में होता है, कुछ syslog प्रारूप में।
• फिर यह सब इलास्टिक्स खोज समन्वयकों की एक श्रृंखला में बड़े बैचों में लिखा जाता है।
• और वे, बदले में, संबंधित डेटा नोड्स को लिखने और पढ़ने के अनुरोध भेजते हैं।

शब्दावली

शायद हर कोई शब्दावली को विस्तार से नहीं समझता है, इसलिए मैं इस पर थोड़ा ध्यान देना चाहूंगा।

इलास्टिक्स खोज में कई प्रकार के नोड होते हैं - मास्टर, समन्वयक, डेटा नोड। विभिन्न लॉग परिवर्तनों और विभिन्न समूहों के बीच संचार के लिए दो अन्य प्रकार हैं, लेकिन हमने केवल सूचीबद्ध लोगों का उपयोग किया है।

स्वामी
यह क्लस्टर में मौजूद सभी नोड्स को पिंग करता है, एक अप-टू-डेट क्लस्टर मैप बनाए रखता है और इसे नोड्स के बीच वितरित करता है, इवेंट लॉजिक को प्रोसेस करता है, और विभिन्न प्रकार के क्लस्टर वाइड हाउसकीपिंग करता है।

संयोजक
एक ही कार्य करता है: ग्राहकों से पढ़ने या लिखने के अनुरोधों को स्वीकार करता है और इस ट्रैफ़िक को रूट करता है। यदि कोई लिखित अनुरोध है, तो सबसे अधिक संभावना है, यह मास्टर से पूछेगा कि उसे प्रासंगिक सूचकांक का कौन सा हिस्सा डालना चाहिए, और अनुरोध को आगे पुनर्निर्देशित करेगा।

डेटा नोड
डेटा संग्रहीत करता है, बाहर से आने वाली खोज क्वेरी निष्पादित करता है और उस पर स्थित शार्ड पर संचालन करता है।

धूसर
यह ELK स्टैक में लॉगस्टैश के साथ किबाना के संलयन जैसा कुछ है। ग्रेलॉग यूआई और लॉग प्रोसेसिंग पाइपलाइन दोनों को जोड़ती है। हुड के तहत, ग्रेलॉग काफ्का और ज़ूकीपर चलाता है, जो एक क्लस्टर के रूप में ग्रेलॉग को कनेक्टिविटी प्रदान करता है। इलास्टिक्स खोज अनुपलब्ध होने की स्थिति में ग्रेलॉग लॉग (काफ्का) को कैश कर सकता है और असफल पढ़ने और लिखने के अनुरोधों को दोहरा सकता है, निर्दिष्ट नियमों के अनुसार लॉग को समूहित और चिह्नित कर सकता है। लॉगस्टैश की तरह, ग्रेलॉग में पंक्तियों को Elasticsearch पर लिखने से पहले संशोधित करने की कार्यक्षमता है।

इसके अलावा, ग्रेलॉग में एक अंतर्निहित सेवा खोज है जो एक उपलब्ध इलास्टिक्स खोज नोड के आधार पर, संपूर्ण क्लस्टर मानचित्र प्राप्त करने और इसे एक विशिष्ट टैग द्वारा फ़िल्टर करने की अनुमति देती है, जिससे विशिष्ट कंटेनरों के लिए अनुरोधों को निर्देशित करना संभव हो जाता है।

देखने में यह कुछ इस तरह दिखता है:

यह एक विशिष्ट उदाहरण का स्क्रीनशॉट है. यहां हम खोज क्वेरी के आधार पर एक हिस्टोग्राम बनाते हैं और प्रासंगिक पंक्तियाँ प्रदर्शित करते हैं।

सूचकांक

सिस्टम आर्किटेक्चर पर लौटते हुए, मैं इस बात पर अधिक विस्तार से ध्यान देना चाहूंगा कि हमने इंडेक्स मॉडल कैसे बनाया ताकि यह सब सही ढंग से काम करे।

उपरोक्त चित्र में, यह निम्नतम स्तर है: इलास्टिक्स खोज डेटा नोड्स।

इंडेक्स इलास्टिक्स खोज शार्क से बनी एक बड़ी आभासी इकाई है। अपने आप में, प्रत्येक शार्ड ल्यूसीन इंडेक्स से ज्यादा कुछ नहीं है। और प्रत्येक ल्यूसीन सूचकांक में, बदले में, एक या अधिक खंड होते हैं।

डिज़ाइन करते समय, हमने सोचा कि बड़ी मात्रा में डेटा पर पढ़ने की गति की आवश्यकता को पूरा करने के लिए, हमें इस डेटा को डेटा नोड्स में समान रूप से "फैलाने" की आवश्यकता है।

इसके परिणामस्वरूप यह तथ्य सामने आया कि प्रति सूचकांक (प्रतिकृतियों के साथ) शार्ड की संख्या सख्ती से डेटा नोड्स की संख्या के बराबर होनी चाहिए। सबसे पहले, दो के बराबर प्रतिकृति कारक सुनिश्चित करने के लिए (अर्थात, हम क्लस्टर का आधा हिस्सा खो सकते हैं)। और, दूसरी बात, क्लस्टर के कम से कम आधे हिस्से पर पढ़ने और लिखने के अनुरोधों को संसाधित करने के लिए।

हमने सबसे पहले भंडारण का समय 30 दिन निर्धारित किया।

शार्डों के वितरण को ग्राफिक रूप से इस प्रकार दर्शाया जा सकता है:

संपूर्ण गहरे भूरे रंग का आयत एक सूचकांक है। इसमें बायां लाल वर्ग प्राथमिक शार्ड है, सूचकांक में पहला। और नीला वर्ग एक प्रतिकृति टुकड़ा है। वे विभिन्न डेटा केंद्रों में स्थित हैं।

जब हम एक और शार्ड जोड़ते हैं, तो यह तीसरे डेटा सेंटर में चला जाता है। और, अंत में, हमें यह संरचना मिलती है, जो डेटा स्थिरता खोए बिना डीसी को खोना संभव बनाती है:

सूचकांकों का घूर्णन, अर्थात् एक नया सूचकांक बनाकर और सबसे पुराने को हटाकर, हमने इसे 48 घंटों के बराबर कर दिया (सूचकांक के उपयोग के पैटर्न के अनुसार: पिछले 48 घंटों को सबसे अधिक बार खोजा जाता है)।

यह सूचकांक रोटेशन अंतराल निम्नलिखित कारणों से है:

जब एक खोज अनुरोध एक विशिष्ट डेटा नोड पर आता है, तो, प्रदर्शन के दृष्टिकोण से, जब एक शार्ड से पूछताछ की जाती है, तो यह अधिक लाभदायक होता है, यदि इसका आकार नोड के कूल्हे के आकार के बराबर है। यह आपको इंडेक्स के "हॉट" हिस्से को ढेर में रखने और उस तक तुरंत पहुंचने की अनुमति देता है। जब बहुत सारे "हॉट पार्ट्स" होते हैं, तो सूचकांक खोज की गति कम हो जाती है।

जब कोई नोड एक शार्ड पर खोज क्वेरी निष्पादित करना शुरू करता है, तो यह भौतिक मशीन के हाइपरथ्रेडिंग कोर की संख्या के बराबर कई थ्रेड आवंटित करता है। यदि कोई खोज क्वेरी बड़ी संख्या में शार्क को प्रभावित करती है, तो थ्रेड की संख्या आनुपातिक रूप से बढ़ जाती है। इसका खोज गति पर नकारात्मक प्रभाव पड़ता है और नए डेटा के अनुक्रमण पर नकारात्मक प्रभाव पड़ता है।

आवश्यक खोज विलंबता प्रदान करने के लिए, हमने SSD का उपयोग करने का निर्णय लिया। अनुरोधों को शीघ्रता से संसाधित करने के लिए, इन कंटेनरों को होस्ट करने वाली मशीनों में कम से कम 56 कोर होने चाहिए। 56 का आंकड़ा सशर्त रूप से पर्याप्त मान के रूप में चुना गया था जो ऑपरेशन के दौरान इलास्टिक्स खोज द्वारा उत्पन्न थ्रेड्स की संख्या निर्धारित करता है। Elasitcsearch में, कई थ्रेड पूल पैरामीटर सीधे उपलब्ध कोर की संख्या पर निर्भर करते हैं, जो बदले में "कम कोर - अधिक नोड्स" सिद्धांत के अनुसार क्लस्टर में नोड्स की आवश्यक संख्या को सीधे प्रभावित करता है।

परिणामस्वरूप, हमने पाया कि औसतन एक शार्ड का वजन लगभग 20 गीगाबाइट होता है, और प्रति इंडेक्स 1 शार्ड होते हैं। तदनुसार, यदि हम उन्हें हर 360 घंटे में एक बार घुमाएँ, तो हमारे पास उनमें से 48 हैं। प्रत्येक सूचकांक में 15 दिनों का डेटा होता है।

डेटा लेखन और रीडिंग सर्किट

आइए जानें कि इस सिस्टम में डेटा कैसे रिकॉर्ड किया जाता है।

मान लीजिए कि ग्रेलॉग से समन्वयक के पास कुछ अनुरोध आता है। उदाहरण के लिए, हम 2-3 हजार पंक्तियों को अनुक्रमित करना चाहते हैं।

समन्वयक, ग्रेलॉग से एक अनुरोध प्राप्त करने के बाद, मास्टर से सवाल करता है: "अनुक्रमण अनुरोध में, हमने विशेष रूप से एक सूचकांक निर्दिष्ट किया था, लेकिन इसे किस शार्ड में लिखना है यह निर्दिष्ट नहीं किया गया था।"

मास्टर जवाब देता है: "इस जानकारी को शार्ड नंबर 71 पर लिखें," जिसके बाद इसे सीधे संबंधित डेटा नोड पर भेजा जाता है, जहां प्राथमिक-शार्ड नंबर 71 स्थित है।

जिसके बाद लेन-देन लॉग को एक प्रतिकृति-शार्क में दोहराया जाता है, जो दूसरे डेटा सेंटर में स्थित होता है।

ग्रेलॉग से समन्वयक के पास एक खोज अनुरोध आता है। समन्वयक इसे सूचकांक के अनुसार पुनर्निर्देशित करता है, जबकि इलास्टिक्स खोज राउंड-रॉबिन सिद्धांत का उपयोग करके प्राथमिक-शार्क और प्रतिकृति-शार्क के बीच अनुरोध वितरित करता है।

180 नोड्स असमान रूप से प्रतिक्रिया करते हैं, और जब वे प्रतिक्रिया दे रहे होते हैं, तो समन्वयक ऐसी जानकारी जमा कर रहा होता है जो पहले से ही तेज़ डेटा नोड्स द्वारा "थूक" दी गई है। इसके बाद, जब या तो सारी जानकारी आ जाती है, या अनुरोध टाइमआउट पर पहुंच जाता है, तो यह सब कुछ सीधे ग्राहक को दे देता है।

यह संपूर्ण सिस्टम पिछले 48 घंटों की खोज क्वेरी को औसतन 300-400ms में प्रोसेस करता है, अग्रणी वाइल्डकार्ड वाली क्वेरी को छोड़कर।

इलास्टिक्स खोज के साथ फूल: जावा सेटअप

यह सब उस तरह से काम करने के लिए जैसा हम मूल रूप से चाहते थे, हमने क्लस्टर में विभिन्न प्रकार की चीज़ों को डीबग करने में बहुत लंबा समय बिताया।

खोजी गई समस्याओं का पहला भाग इलास्टिक्स खोज में जावा को डिफ़ॉल्ट रूप से पूर्व-कॉन्फ़िगर करने के तरीके से संबंधित था।

पहली समस्या
हमने बहुत बड़ी संख्या में रिपोर्टें देखी हैं कि ल्यूसीन स्तर पर, जब पृष्ठभूमि नौकरियां चल रही होती हैं, तो ल्यूसीन खंड विलय एक त्रुटि के साथ विफल हो जाता है। साथ ही, लॉग्स में यह स्पष्ट था कि यह एक आउटऑफमेमरी एरर त्रुटि थी। हमने टेलीमेट्री से देखा कि कूल्हा मुक्त था, और यह स्पष्ट नहीं था कि यह ऑपरेशन विफल क्यों हो रहा था।

यह पता चला कि ल्यूसीन इंडेक्स मर्ज कूल्हे के बाहर होता है। और उपभोग किए गए संसाधनों के मामले में कंटेनर काफी सख्ती से सीमित हैं। केवल हीप इन संसाधनों में फिट हो सकता है (हीप.साइज मान लगभग रैम के बराबर था), और कुछ ऑफ-हीप ऑपरेशन मेमोरी आवंटन त्रुटि के साथ क्रैश हो गए यदि किसी कारण से वे सीमा से पहले शेष ~ 500 एमबी में फिट नहीं हुए।

सुधार काफी मामूली था: कंटेनर के लिए उपलब्ध रैम की मात्रा बढ़ा दी गई थी, जिसके बाद हम भूल गए कि हमें भी ऐसी समस्याएं थीं।

समस्या दो
क्लस्टर के लॉन्च के 4-5 दिन बाद, हमने देखा कि डेटा नोड्स समय-समय पर क्लस्टर से बाहर गिरने लगे और 10-20 सेकंड के बाद इसमें प्रवेश करने लगे।

जब हमने इसका पता लगाना शुरू किया, तो पता चला कि इलास्टिक्स खोज में यह ऑफ-हीप मेमोरी किसी भी तरह से नियंत्रित नहीं है। जब हमने कंटेनर को अधिक मेमोरी दी, तो हम विभिन्न सूचनाओं के साथ प्रत्यक्ष बफर पूल को भरने में सक्षम थे, और इलास्टिक्स खोज से स्पष्ट जीसी लॉन्च होने के बाद ही इसे साफ़ किया गया था।

कुछ मामलों में, इस ऑपरेशन में काफी लंबा समय लगा, और इस दौरान क्लस्टर इस नोड को पहले से ही बाहर निकलने के रूप में चिह्नित करने में कामयाब रहा। इस समस्या का अच्छे से वर्णन किया गया है यहां.

समाधान इस प्रकार था: हमने इन परिचालनों के लिए ढेर के बाहर बड़ी मात्रा में मेमोरी का उपयोग करने की जावा की क्षमता को सीमित कर दिया। हमने इसे 16 गीगाबाइट (-XX:MaxDirectMemorySize=16g) तक सीमित कर दिया, यह सुनिश्चित करते हुए कि स्पष्ट GC को अधिक बार कॉल किया गया और बहुत तेजी से संसाधित किया गया, जिससे क्लस्टर अब अस्थिर नहीं होगा।

समस्या तीन
यदि आपको लगता है कि "सबसे अप्रत्याशित क्षण में नोड्स के क्लस्टर छोड़ने" की समस्याएँ खत्म हो गई हैं, तो आप गलत हैं।

जब हमने कार्य को अनुक्रमणिका के साथ कॉन्फ़िगर किया, तो हमने mmapfs को चुना खोज समय कम करें महान विभाजन के साथ ताजा टुकड़ों पर। यह काफी बड़ी गलती थी, क्योंकि mmapfs का उपयोग करते समय फ़ाइल को RAM में मैप किया जाता है, और फिर हम मैप की गई फ़ाइल के साथ काम करते हैं। इस वजह से, यह पता चलता है कि जब जीसी एप्लिकेशन में थ्रेड्स को रोकने की कोशिश करता है, तो हम बहुत लंबे समय के लिए सेफपॉइंट पर जाते हैं, और इसके रास्ते में, एप्लिकेशन मास्टर के अनुरोधों का जवाब देना बंद कर देता है कि क्या यह जीवित है . तदनुसार, मास्टर का मानना ​​है कि नोड अब क्लस्टर में मौजूद नहीं है। इसके बाद, 5-10 सेकंड के बाद, कचरा संग्राहक काम करता है, नोड जीवन में आता है, क्लस्टर में फिर से प्रवेश करता है और शार्क को आरंभ करना शुरू कर देता है। यह सब बहुत हद तक "वह उत्पादन जिसके हम हकदार थे" जैसा महसूस हुआ और किसी भी गंभीर चीज़ के लिए उपयुक्त नहीं था।

इस व्यवहार से छुटकारा पाने के लिए, हमने पहले मानक निओफ़्स पर स्विच किया, और फिर, जब हम इलास्टिक के पांचवें संस्करण से छठे संस्करण में चले गए, तो हमने हाइब्रिडफ़्स की कोशिश की, जहां यह समस्या पुन: उत्पन्न नहीं हुई। आप भंडारण प्रकारों के बारे में अधिक पढ़ सकते हैं यहां.

समस्या चार
फिर एक और बहुत दिलचस्प समस्या थी जिसका हमने रिकॉर्ड समय तक इलाज किया। हमने इसे 2-3 महीने तक पकड़ा क्योंकि इसका पैटर्न बिल्कुल समझ से परे था।

कभी-कभी हमारे समन्वयक फुल जीसी में चले जाते थे, आमतौर पर दोपहर के भोजन के कुछ समय बाद, और वहां से कभी नहीं लौटते थे। उसी समय, जीसी विलंब को लॉग करते समय ऐसा लग रहा था: सब कुछ ठीक चल रहा है, अच्छा, अच्छा, और फिर अचानक सब कुछ बहुत खराब हो रहा है।

पहले तो हमने सोचा कि हमारे पास एक दुष्ट उपयोगकर्ता है जो किसी प्रकार का अनुरोध लॉन्च कर रहा है जिसने समन्वयक को कार्यशील मोड से बाहर कर दिया है। हमने बहुत लंबे समय तक अनुरोधों को लॉग किया, यह पता लगाने की कोशिश की कि क्या हो रहा था।

परिणामस्वरूप, यह पता चला कि उस समय जब कोई उपयोगकर्ता एक बड़ा अनुरोध लॉन्च करता है, और वह एक विशिष्ट इलास्टिक्स खोज समन्वयक के पास जाता है, तो कुछ नोड्स दूसरों की तुलना में अधिक समय तक प्रतिक्रिया करते हैं।

और जबकि समन्वयक सभी नोड्स से प्रतिक्रिया की प्रतीक्षा कर रहा है, वह उन नोड्स से भेजे गए परिणामों को जमा करता है जो पहले ही प्रतिक्रिया दे चुके हैं। जीसी के लिए, इसका मतलब है कि हमारे ढेर उपयोग पैटर्न बहुत तेज़ी से बदलते हैं। और जिस GC का हमने उपयोग किया वह इस कार्य का सामना नहीं कर सका।

इस स्थिति में क्लस्टर के व्यवहार को बदलने के लिए हमें जो एकमात्र समाधान मिला, वह है JDK13 में माइग्रेशन और शेनान्डाह कचरा संग्रहकर्ता का उपयोग। इससे समस्या हल हो गई, हमारे समन्वयकों का गिरना बंद हो गया।

यहीं पर जावा की समस्याएँ समाप्त हुईं और बैंडविड्थ की समस्याएँ शुरू हुईं।

इलास्टिक्स खोज के साथ "जामुन": थ्रूपुट

थ्रूपुट के साथ समस्याओं का मतलब है कि हमारा क्लस्टर स्थिर रूप से काम करता है, लेकिन अनुक्रमित दस्तावेज़ों की संख्या और युद्धाभ्यास के दौरान चरम पर, प्रदर्शन अपर्याप्त है।

पहला लक्षण सामने आया: उत्पादन में कुछ "विस्फोट" के दौरान, जब बहुत बड़ी संख्या में लॉग अचानक उत्पन्न होते हैं, तो इंडेक्सिंग त्रुटि es_rejected_execution ग्रेलॉग में बार-बार फ्लैश होने लगती है।

यह इस तथ्य के कारण था कि एक डेटा नोड पर thread_pool.write.queue, जब तक Elasticsearch इंडेक्सिंग अनुरोध को संसाधित करने और डिस्क पर शार्ड पर जानकारी अपलोड करने में सक्षम नहीं हो जाता, तब तक डिफ़ॉल्ट रूप से केवल 200 अनुरोधों को कैश करने में सक्षम होता है। और में इलास्टिक्स खोज दस्तावेज़ीकरण इस पैरामीटर के बारे में बहुत कम कहा गया है. केवल थ्रेड्स की अधिकतम संख्या और डिफ़ॉल्ट आकार दर्शाया गया है।

बेशक, हमने इस मान को घुमाया और निम्नलिखित पाया: विशेष रूप से, हमारे सेटअप में, 300 तक अनुरोध काफी अच्छी तरह से कैश किए गए हैं, और एक उच्च मूल्य इस तथ्य से भरा है कि हम फिर से पूर्ण जीसी में उड़ जाते हैं।

इसके अलावा, चूंकि ये संदेशों के बैच हैं जो एक अनुरोध के भीतर आते हैं, इसलिए ग्रेलॉग को ट्विक करना आवश्यक था ताकि यह अक्सर और छोटे बैचों में नहीं, बल्कि बड़े बैचों में या हर 3 सेकंड में एक बार लिखे, यदि बैच अभी भी पूरा नहीं हुआ है। इस मामले में, यह पता चलता है कि जो जानकारी हम इलास्टिक्स खोज में लिखते हैं वह दो सेकंड में नहीं, बल्कि पांच सेकंड में उपलब्ध हो जाती है (जो हमारे लिए काफी उपयुक्त है), लेकिन एक बड़े पैमाने पर आगे बढ़ने के लिए जितनी संख्या में रिट्रेस करना पड़ता है। सूचना का ढेर कम हो गया है।

यह उन क्षणों में विशेष रूप से महत्वपूर्ण है जब कुछ कहीं दुर्घटनाग्रस्त हो गया है और इसके बारे में उग्र रूप से रिपोर्ट करता है, ताकि पूरी तरह से स्पैम इलास्टिक न हो, और कुछ समय बाद - ग्रेलॉग नोड्स जो अवरुद्ध बफ़र्स के कारण निष्क्रिय हैं।

इसके अलावा, जब हमारे उत्पादन में ये समान विस्फोट हुए, तो हमें प्रोग्रामर और परीक्षकों से शिकायतें मिलीं: उस समय जब उन्हें वास्तव में इन लॉग की आवश्यकता थी, उन्हें बहुत धीरे-धीरे दिया गया था।

उन्होंने इसका पता लगाना शुरू कर दिया। एक ओर, यह स्पष्ट था कि खोज क्वेरी और अनुक्रमण क्वेरी दोनों को अनिवार्य रूप से एक ही भौतिक मशीनों पर संसाधित किया गया था, और किसी न किसी तरह से कुछ कमियां होंगी।

लेकिन इस तथ्य के कारण इसे आंशिक रूप से टाला जा सकता है कि इलास्टिक्स खोज के छठे संस्करण में, एक एल्गोरिदम दिखाई दिया जो आपको यादृच्छिक राउंड-रॉबिन सिद्धांत (कंटेनर जो अनुक्रमण करता है और प्राथमिक रखता है) के अनुसार प्रासंगिक डेटा नोड्स के बीच प्रश्नों को वितरित करने की अनुमति देता है -शार्ड बहुत व्यस्त हो सकता है, जल्दी से प्रतिक्रिया देने का कोई तरीका नहीं होगा), लेकिन इस अनुरोध को प्रतिकृति-शार्ड के साथ कम लोड वाले कंटेनर में अग्रेषित करें, जो बहुत तेजी से प्रतिक्रिया देगा। दूसरे शब्दों में, हम उपयोग_अनुकूली_प्रतिकृति_चयन: सत्य पर पहुंचे।

पढ़ने की तस्वीर इस तरह दिखने लगती है:

इस एल्गोरिदम में परिवर्तन से उन क्षणों में क्वेरी समय में उल्लेखनीय सुधार करना संभव हो गया जब हमारे पास लिखने के लिए लॉग का एक बड़ा प्रवाह था।

अंत में, मुख्य समस्या डेटा सेंटर को दर्द रहित तरीके से हटाना था।

एक डीसी से कनेक्शन टूटने के तुरंत बाद हम क्लस्टर से क्या चाहते थे:

• यदि हमारे पास विफल डेटा सेंटर में एक वर्तमान मास्टर है, तो इसे फिर से चुना जाएगा और एक भूमिका के रूप में दूसरे डीसी में दूसरे नोड में ले जाया जाएगा।
• मास्टर क्लस्टर से सभी दुर्गम नोड्स को तुरंत हटा देगा।
• शेष के आधार पर, वह समझ जाएगा: खोए हुए डेटा सेंटर में हमारे पास ऐसे और ऐसे प्राथमिक टुकड़े थे, वह शेष डेटा केंद्रों में पूरक प्रतिकृति शार्क को जल्दी से बढ़ावा देगा, और हम डेटा को अनुक्रमित करना जारी रखेंगे।
• इसके परिणामस्वरूप, क्लस्टर का लेखन और पढ़ने का थ्रूपुट धीरे-धीरे कम हो जाएगा, लेकिन सामान्य तौर पर सब कुछ धीरे-धीरे, लेकिन स्थिर रूप से काम करेगा।

जैसा कि बाद में पता चला, हम ऐसा कुछ चाहते थे:

और हमें निम्नलिखित मिला:

ऐसा कैसे हुआ?

जब डेटा सेंटर गिरा, तो हमारा मास्टर बाधा बन गया।

क्यों?

तथ्य यह है कि मास्टर के पास एक टास्कबैचर है, जो क्लस्टर में कुछ कार्यों और घटनाओं को वितरित करने के लिए जिम्मेदार है। कोई भी नोड निकास, प्रतिकृति से प्राथमिक तक किसी शार्ड का प्रचार, कहीं एक शार्ड बनाने का कोई भी कार्य - यह सब सबसे पहले टास्कबैचर पर जाता है, जहां इसे क्रमिक रूप से और एक थ्रेड में संसाधित किया जाता है।

एक डेटा सेंटर की वापसी के समय, यह पता चला कि जीवित डेटा केंद्रों के सभी डेटा नोड्स ने मास्टर को सूचित करना अपना कर्तव्य समझा कि "हमने ऐसे और ऐसे टुकड़े और ऐसे और ऐसे डेटा नोड्स खो दिए हैं।"

उसी समय, जीवित डेटा नोड्स ने यह सारी जानकारी वर्तमान मास्टर को भेज दी और पुष्टि के लिए प्रतीक्षा करने का प्रयास किया कि उसने इसे स्वीकार कर लिया है। उन्होंने इसके लिए इंतजार नहीं किया, क्योंकि मास्टर को उत्तर देने की तुलना में तेजी से कार्य प्राप्त हुए। नोड्स ने बार-बार अनुरोध करने का समय समाप्त कर दिया, और इस समय मास्टर ने उन्हें उत्तर देने की कोशिश भी नहीं की, लेकिन प्राथमिकता के आधार पर अनुरोधों को क्रमबद्ध करने के कार्य में पूरी तरह से लीन था।

टर्मिनल रूप में, यह पता चला कि डेटा नोड्स ने मास्टर को इस हद तक स्पैम कर दिया कि यह पूर्ण जीसी में चला गया। उसके बाद, हमारी मास्टर भूमिका किसी अगले नोड में चली गई, उसके साथ भी बिल्कुल वैसा ही हुआ, और परिणामस्वरूप क्लस्टर पूरी तरह से ध्वस्त हो गया।

हमने माप लिया, और संस्करण 6.4.0 से पहले, जहां यह तय किया गया था, क्लस्टर को पूरी तरह से बंद करने के लिए 10 में से केवल 360 डेटा नोड्स को एक साथ आउटपुट करना हमारे लिए पर्याप्त था।

यह कुछ इस तरह दिखता था:

संस्करण 6.4.0 के बाद, जहां इस भयानक बग को ठीक कर दिया गया था, डेटा नोड्स ने मास्टर को मारना बंद कर दिया। लेकिन इससे वह "अधिक चतुर" नहीं बन गया। अर्थात्: जब हम 2, 3 या 10 (एक के अलावा कोई भी संख्या) डेटा नोड्स आउटपुट करते हैं, तो मास्टर को कुछ पहला संदेश प्राप्त होता है जो कहता है कि नोड ए छोड़ दिया गया है, और नोड बी, नोड सी को इसके बारे में, नोड डी को बताने की कोशिश करता है।

और फिलहाल, इससे केवल किसी को कुछ बताने के प्रयासों के लिए लगभग 20-30 सेकंड के बराबर का समय निर्धारित करके ही निपटा जा सकता है, और इस प्रकार क्लस्टर से बाहर जाने वाले डेटा सेंटर की गति को नियंत्रित किया जा सकता है।

सिद्धांत रूप में, यह उन आवश्यकताओं में फिट बैठता है जो शुरू में परियोजना के हिस्से के रूप में अंतिम उत्पाद के लिए प्रस्तुत की गई थीं, लेकिन "शुद्ध विज्ञान" के दृष्टिकोण से यह एक बग है। वैसे, डेवलपर्स द्वारा संस्करण 7.2 में सफलतापूर्वक तय किया गया था।

इसके अलावा, जब एक निश्चित डेटा नोड बाहर चला गया, तो यह पता चला कि उसके बाहर निकलने के बारे में जानकारी प्रसारित करना पूरे क्लस्टर को यह बताने से अधिक महत्वपूर्ण था कि उस पर ऐसे और ऐसे प्राथमिक-शार्क थे (किसी अन्य डेटा में प्रतिकृति-शार्क को बढ़ावा देने के लिए) प्राथमिक में केंद्र, और उन पर जानकारी लिखी जा सकती है)।

इसलिए, जब सब कुछ पहले ही समाप्त हो चुका होता है, तो जारी किए गए डेटा नोड्स को तुरंत बासी के रूप में चिह्नित नहीं किया जाता है। तदनुसार, हमें तब तक इंतजार करने के लिए मजबूर किया जाता है जब तक कि जारी किए गए डेटा नोड्स के लिए सभी पिंग का समय समाप्त नहीं हो जाता है, और उसके बाद ही हमारा क्लस्टर हमें बताना शुरू करता है कि वहां, वहां, और वहां हमें रिकॉर्डिंग जानकारी जारी रखने की आवश्यकता है। आप इसके बारे में और अधिक पढ़ सकते हैं यहां.

परिणामस्वरूप, आज व्यस्त समय के दौरान डेटा सेंटर को वापस लेने में हमें लगभग 5 मिनट का समय लगता है। इतने बड़े और अनाड़ी कोलोसस के लिए, यह एक बहुत अच्छा परिणाम है।

परिणामस्वरूप, हम निम्नलिखित निर्णय पर पहुंचे:

• हमारे पास 360 गीगाबाइट डिस्क के साथ 700 डेटा नोड हैं।
• इन्हीं डेटा नोड्स के माध्यम से ट्रैफ़िक को रूट करने के लिए 60 समन्वयक।
• 40 मास्टर्स जिन्हें हमने 6.4.0 से पहले के संस्करणों के बाद से एक प्रकार की विरासत के रूप में छोड़ा है - डेटा सेंटर की वापसी से बचने के लिए, हम मानसिक रूप से कई मशीनों को खोने के लिए तैयार थे ताकि मास्टर्स के कोरम की गारंटी दी जा सके। सबसे खराब स्थिति
• एक कंटेनर पर भूमिकाओं को संयोजित करने के किसी भी प्रयास को इस तथ्य के साथ पूरा किया गया कि देर-सबेर नोड लोड के तहत टूट जाएगा।
• पूरा क्लस्टर 31 गीगाबाइट के ढेर आकार का उपयोग करता है: आकार को कम करने के सभी प्रयासों के परिणामस्वरूप या तो अग्रणी वाइल्डकार्ड के साथ भारी खोज क्वेरी पर कुछ नोड्स को मार दिया गया या इलास्टिक्स खोज में सर्किट ब्रेकर प्राप्त हुआ।
• इसके अलावा, खोज प्रदर्शन सुनिश्चित करने के लिए, हमने क्लस्टर में वस्तुओं की संख्या को यथासंभव कम रखने की कोशिश की, ताकि मास्टर में हमें मिलने वाली बाधा में जितनी संभव हो उतनी कम घटनाओं को संसाधित किया जा सके।

अंत में निगरानी के बारे में

यह सुनिश्चित करने के लिए कि यह सब उद्देश्य के अनुसार काम करता है, हम निम्नलिखित की निगरानी करते हैं:

• प्रत्येक डेटा नोड हमारे क्लाउड को रिपोर्ट करता है कि यह मौजूद है, और इस पर ऐसे और ऐसे टुकड़े हैं। जब हम कहीं कुछ बुझाते हैं, तो क्लस्टर 2-3 सेकंड के बाद रिपोर्ट करता है कि केंद्र ए में हमने नोड्स 2, 3, और 4 को बुझा दिया है - इसका मतलब है कि अन्य डेटा केंद्रों में हम किसी भी परिस्थिति में उन नोड्स को बुझा नहीं सकते हैं जिन पर केवल एक शार्ड है बाएं।
• गुरु के व्यवहार की प्रकृति को जानकर हम लंबित कार्यों की संख्या पर बहुत ध्यान से विचार करते हैं। क्योंकि एक अटका हुआ कार्य भी, यदि समय पर पूरा नहीं होता है, तो सैद्धांतिक रूप से कुछ आपातकालीन स्थिति में इसका कारण बन सकता है, उदाहरण के लिए, प्राथमिक में एक प्रतिकृति शार्ड का प्रचार काम नहीं करता है, जिसके कारण अनुक्रमण काम करना बंद कर देगा।
• हम कूड़ा उठाने में होने वाली देरी को भी बहुत करीब से देखते हैं, क्योंकि अनुकूलन के दौरान हमें पहले ही इसमें बड़ी कठिनाइयों का सामना करना पड़ा है।
• पहले से समझने के लिए थ्रेड द्वारा अस्वीकार करें कि अड़चन कहां है।
• खैर, मानक मेट्रिक्स जैसे हीप, रैम और I/O।

निगरानी बनाते समय, आपको इलास्टिक्स खोज में थ्रेड पूल की विशेषताओं को ध्यान में रखना चाहिए। इलास्टिक्स खोज दस्तावेज़ीकरण खोज और अनुक्रमण के लिए कॉन्फ़िगरेशन विकल्पों और डिफ़ॉल्ट मानों का वर्णन करता है, लेकिन thread_pool.management के बारे में पूरी तरह से चुप है। ये थ्रेड, विशेष रूप से, _cat/shards और अन्य समान प्रश्नों को संसाधित करते हैं, जो मॉनिटरिंग लिखते समय उपयोग करने के लिए सुविधाजनक होते हैं। जितना बड़ा क्लस्टर, उतने ही अधिक ऐसे अनुरोध प्रति यूनिट समय में निष्पादित होते हैं, और उपरोक्त थ्रेड_पूल.मैनेजमेंट न केवल आधिकारिक दस्तावेज में प्रस्तुत किया जाता है, बल्कि डिफ़ॉल्ट रूप से 5 थ्रेड तक सीमित होता है, जिसे बाद में बहुत जल्दी निपटाया जाता है। कौन सी मॉनिटरिंग सही ढंग से काम करना बंद कर देती है.

मैं निष्कर्ष में क्या कहना चाहता हूँ: हमने यह किया! हम अपने प्रोग्रामर और डेवलपर्स को एक टूल देने में सक्षम थे, जो लगभग किसी भी स्थिति में, उत्पादन में क्या हो रहा है, इसके बारे में जल्दी और विश्वसनीय रूप से जानकारी प्रदान कर सकता है।

हां, यह काफी जटिल निकला, लेकिन, फिर भी, हम अपनी इच्छाओं को मौजूदा उत्पादों में फिट करने में कामयाब रहे, जिन्हें हमें अपने लिए पैच करने और फिर से लिखने की ज़रूरत नहीं थी।

स्रोत: www.habr.com