इलास्टिकसर्च क्लस्टर 200 TB+

बरेच लोक Elasticsearch सह संघर्ष करतात. पण जेव्हा तुम्हाला ते “विशेषतः मोठ्या व्हॉल्यूममध्ये” लॉग संग्रहित करण्यासाठी वापरायचे असते तेव्हा काय होते? आणि अनेक डेटा सेंटर्सपैकी कोणतेही अपयश अनुभवणे देखील वेदनारहित आहे का? आपण कोणत्या प्रकारचे आर्किटेक्चर बनवावे आणि आपण कोणत्या अडचणींना अडखळणार आहात?

आम्ही ओड्नोक्लास्निकी येथे लॉग मॅनेजमेंटच्या समस्येचे निराकरण करण्यासाठी इलास्टिकसर्च वापरण्याचे ठरवले आणि आता आम्ही आमचा अनुभव Habr सह सामायिक करतो: आर्किटेक्चर आणि त्रुटींबद्दल.

मी Pyotr Zaitsev आहे, मी Odnoklassniki येथे सिस्टम प्रशासक म्हणून काम करतो. त्यापूर्वी, मी प्रशासक देखील होतो, मॅन्टीकोर शोध, स्फिंक्स शोध, इलास्टिकसर्चमध्ये काम केले. कदाचित, जर दुसरा ...शोध दिसला, तर मी कदाचित त्यावरही काम करेन. मी स्वेच्छेने अनेक ओपन सोर्स प्रकल्पांमध्ये देखील सहभागी होतो.

जेव्हा मी ओड्नोक्लास्निकी येथे आलो तेव्हा मी मुलाखतीत बेपर्वाईने सांगितले की मी इलास्टिकसर्चसह काम करू शकतो. मला ते हँग झाल्यानंतर आणि काही सोपी कामे पूर्ण केल्यावर, त्या वेळी अस्तित्वात असलेल्या लॉग व्यवस्थापन प्रणालीमध्ये सुधारणा करण्याचे मोठे काम मला देण्यात आले.

आवश्यकता

सिस्टम आवश्यकता खालीलप्रमाणे तयार केल्या होत्या:

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

या प्रकल्पाच्या अंमलबजावणीसाठी शेवटची आवश्यकता आम्हाला सर्वात जास्त खर्च करते, ज्याबद्दल मी अधिक तपशीलवार बोलेन.

पर्यावरण

आम्ही चार डेटा सेंटरमध्ये काम करतो, तर इलास्टिकसर्च डेटा नोड्स फक्त तीनमध्ये असू शकतात (अनेक गैर-तांत्रिक कारणांमुळे).

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

महत्त्वाचे वैशिष्ट्य: क्लस्टर कंटेनरमध्ये सुरू होते पोडमॅन भौतिक मशीनवर नाही तर चालू आहे स्वतःचे क्लाउड उत्पादन वन-क्लाउड. कंटेनरना 2 कोरची हमी दिली जाते, 2.0Ghz v4 प्रमाणेच, जर ते निष्क्रिय असतील तर उर्वरित कोर पुनर्वापराच्या शक्यतेसह.

दुसऱ्या शब्दात:

टोपोलॉजी

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

• 3-4 व्हीआयपी ग्रेलॉग डोमेनच्या ए-रेकॉर्डच्या मागे आहेत, हा तो पत्ता आहे ज्यावर लॉग पाठवले जातात.
• प्रत्येक VIP हा LVS बॅलन्सर असतो.
• त्यानंतर, लॉग ग्रेलॉग बॅटरीवर जातात, काही डेटा GELF फॉरमॅटमध्ये असतो, काही syslog फॉरमॅटमध्ये असतो.
• मग हे सर्व इलास्टिकसर्च कोऑर्डिनेटरच्या बॅटरीवर मोठ्या बॅचमध्ये लिहिले जाते.
• आणि ते, त्या बदल्यात, संबंधित डेटा नोड्सवर लिहा आणि वाचण्याच्या विनंत्या पाठवतात.

टर्मिनोलॉजी

कदाचित प्रत्येकाला शब्दावली तपशीलवार समजत नाही, म्हणून मला त्यावर थोडे लक्ष द्यायचे आहे.

इलास्टिकसर्चमध्ये अनेक प्रकारचे नोड्स आहेत - मास्टर, कोऑर्डिनेटर, डेटा नोड. भिन्न लॉग ट्रान्सफॉर्मेशन आणि भिन्न क्लस्टर्समधील संप्रेषणासाठी इतर दोन प्रकार आहेत, परंतु आम्ही फक्त सूचीबद्ध केलेले वापरले.

मास्टर
हे क्लस्टरमध्ये उपस्थित असलेल्या सर्व नोड्सला पिंग करते, अद्ययावत क्लस्टर नकाशा राखते आणि नोड्समध्ये वितरित करते, इव्हेंट लॉजिकवर प्रक्रिया करते आणि विविध प्रकारचे क्लस्टर वाइड हाउसकीपिंग करते.

समन्वयक
एकच कार्य करते: क्लायंटच्या वाचन किंवा लेखन विनंत्या स्वीकारते आणि या रहदारीला मार्ग देते. लिहिण्याची विनंती असल्यास, बहुधा, तो संबंधित निर्देशांकाच्या कोणत्या शार्डमध्ये ठेवायचा हे मास्टरला विचारेल आणि विनंती पुढे पुनर्निर्देशित करेल.

डेटा नोड
डेटा संग्रहित करते, बाहेरून आलेल्या शोध क्वेरी करते आणि त्यावर असलेल्या शार्ड्सवर ऑपरेशन करते.

ग्रेलॉग
हे ELK स्टॅकमध्ये लॉगस्टॅशसह किबानाच्या फ्यूजनसारखे आहे. ग्रेलॉग UI आणि लॉग प्रोसेसिंग पाइपलाइन दोन्ही एकत्र करते. हुड अंतर्गत, ग्रेलॉग काफ्का आणि झूकीपर चालवतात, जे ग्रेलॉगला क्लस्टर म्हणून कनेक्टिव्हिटी प्रदान करतात. इलास्टिकसर्च अनुपलब्ध असल्यास ग्रेलॉग लॉग (काफ्का) कॅशे करू शकतो आणि अयशस्वी वाचन आणि लेखन विनंत्या, विशिष्ट नियमांनुसार गट आणि चिन्हांकित लॉगची पुनरावृत्ती करू शकतो. Logstash प्रमाणे, Graylog मध्ये पंक्ती इलास्टिकसर्चवर लिहिण्यापूर्वी सुधारित करण्याची कार्यक्षमता आहे.

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

दृश्यमानपणे हे असे काहीतरी दिसते:

हा एका विशिष्ट प्रसंगाचा स्क्रीनशॉट आहे. येथे आपण शोध क्वेरीवर आधारित हिस्टोग्राम तयार करतो आणि संबंधित पंक्ती प्रदर्शित करतो.

निर्देशांक

सिस्टम आर्किटेक्चरकडे परत येताना, मी इंडेक्स मॉडेल कसे तयार केले याबद्दल अधिक तपशीलवार विचार करू इच्छितो जेणेकरून ते सर्व योग्यरित्या कार्य करेल.

वरील आकृतीमध्ये, ही सर्वात खालची पातळी आहे: Elasticsearch डेटा नोड्स.

इंडेक्स ही इलास्टिकसर्च शार्ड्सची बनलेली एक मोठी आभासी संस्था आहे. स्वतःमध्ये, प्रत्येक शार्ड ल्युसीन इंडेक्सपेक्षा अधिक काही नाही. आणि प्रत्येक ल्युसीन इंडेक्समध्ये एक किंवा अधिक विभाग असतात.

डिझाईन करताना, आम्हाला असे आढळले की मोठ्या प्रमाणावर डेटा वाचण्याच्या गतीची आवश्यकता पूर्ण करण्यासाठी, आम्हाला हा डेटा डेटा नोड्समध्ये समान रीतीने "स्प्रेड" करणे आवश्यक आहे.

याचा परिणाम असा झाला की प्रति इंडेक्स (प्रतिकृतीसह) शार्ड्सची संख्या डेटा नोड्सच्या संख्येइतकीच असली पाहिजे. प्रथम, दोन समान प्रतिकृती घटक सुनिश्चित करण्यासाठी (म्हणजे, आपण क्लस्टरचा अर्धा भाग गमावू शकतो). आणि, दुसरे म्हणजे, क्लस्टरच्या किमान अर्ध्या भागावर विनंत्या वाचणे आणि लिहिणे यावर प्रक्रिया करणे.

आम्ही प्रथम स्टोरेज वेळ 30 दिवस म्हणून निर्धारित केला.

शार्ड्सचे वितरण खालीलप्रमाणे ग्राफिक पद्धतीने दर्शविले जाऊ शकते:

संपूर्ण गडद राखाडी आयत एक निर्देशांक आहे. त्यातील डावा लाल चौकोन हा प्राथमिक शार्ड आहे, जो निर्देशांकातील पहिला आहे. आणि निळा चौरस एक प्रतिकृती शार्ड आहे. ते वेगवेगळ्या डेटा सेंटरमध्ये स्थित आहेत.

जेव्हा आपण दुसरा शार्ड जोडतो, तेव्हा ते तिसऱ्या डेटा सेंटरमध्ये जाते. आणि, शेवटी, आम्हाला ही रचना मिळते, ज्यामुळे डेटाची सुसंगतता न गमावता डीसी गमावणे शक्य होते:

निर्देशांकांचे रोटेशन, म्हणजे. नवीन अनुक्रमणिका तयार करणे आणि सर्वात जुने हटवणे, आम्ही ते 48 तासांच्या बरोबरीचे केले (इंडेक्स वापरण्याच्या पद्धतीनुसार: शेवटचे 48 तास बहुतेक वेळा शोधले जातात).

हा निर्देशांक रोटेशन मध्यांतर खालील कारणांमुळे आहे:

जेव्हा शोध विनंती विशिष्ट डेटा नोडवर येते, तेव्हा, कार्यप्रदर्शनाच्या दृष्टिकोनातून, जेव्हा एका शार्डची चौकशी केली जाते, तेव्हा त्याचा आकार नोडच्या हिपच्या आकाराशी तुलना करता येतो तेव्हा ते अधिक फायदेशीर असते. हे तुम्हाला निर्देशांकाचा “गरम” भाग एका ढिगाऱ्यात ठेवण्यास आणि त्वरीत प्रवेश करण्यास अनुमती देते. जेव्हा बरेच "गरम भाग" असतात, तेव्हा निर्देशांक शोधाचा वेग कमी होतो.

जेव्हा नोड एका शार्डवर शोध क्वेरी कार्यान्वित करण्यास प्रारंभ करतो, तेव्हा ते भौतिक मशीनच्या हायपरथ्रेडिंग कोरच्या संख्येइतके थ्रेड्सचे वाटप करते. जर शोध क्वेरी मोठ्या संख्येने शार्ड्सवर परिणाम करत असेल, तर थ्रेड्सची संख्या प्रमाणानुसार वाढते. याचा शोध गतीवर नकारात्मक परिणाम होतो आणि नवीन डेटाच्या अनुक्रमणिकेवर नकारात्मक परिणाम होतो.

आवश्यक शोध विलंब प्रदान करण्यासाठी, आम्ही SSD वापरण्याचा निर्णय घेतला. विनंत्यांची त्वरीत प्रक्रिया करण्यासाठी, हे कंटेनर होस्ट करणाऱ्या मशीनमध्ये किमान 56 कोर असणे आवश्यक होते. 56 ची आकृती सशर्त पुरेशी मूल्य म्हणून निवडली गेली होती जी ऑपरेशन दरम्यान इलास्टिकसर्च किती थ्रेड्स तयार करेल हे निर्धारित करते. Elasitcsearch मध्ये, अनेक थ्रेड पूल पॅरामीटर्स थेट उपलब्ध कोरच्या संख्येवर अवलंबून असतात, जे "कमी कोर - अधिक नोड्स" या तत्त्वानुसार क्लस्टरमधील आवश्यक नोड्सच्या संख्येवर थेट परिणाम करतात.

परिणामी, आम्हाला आढळले की सरासरी एका शार्डचे वजन सुमारे 20 गीगाबाइट्स असते आणि प्रति निर्देशांक 1 शार्ड्स असतात. त्यानुसार, जर आपण त्यांना दर 360 तासांनी एकदा फिरवले, तर आपल्याकडे त्यापैकी 48 आहेत. प्रत्येक निर्देशांकात 15 दिवसांचा डेटा असतो.

डेटा लेखन आणि वाचन सर्किट

या प्रणालीमध्ये डेटा कसा रेकॉर्ड केला जातो ते पाहू या.

समजा ग्रेलॉगकडून समन्वयकाकडे काही विनंती आली आहे. उदाहरणार्थ, आम्हाला 2-3 हजार पंक्ती अनुक्रमित करायच्या आहेत.

ग्रेलॉगकडून विनंती प्राप्त झाल्यानंतर समन्वयकाने मास्टरला प्रश्न केला: "इंडेक्सिंग विनंतीमध्ये, आम्ही विशेषत: एक निर्देशांक निर्दिष्ट केला आहे, परंतु कोणत्या शार्डमध्ये ते लिहायचे ते निर्दिष्ट केलेले नाही."

मास्टर प्रतिसाद देतो: "ही माहिती शार्ड क्रमांक 71 वर लिहा," त्यानंतर ती थेट संबंधित डेटा नोडवर पाठविली जाते, जिथे प्राथमिक-शार्ड क्रमांक 71 स्थित आहे.

त्यानंतर ट्रान्झॅक्शन लॉगची प्रतिकृती दुसऱ्या डेटा सेंटरमध्ये असलेल्या प्रतिकृती-शार्डवर केली जाते.

ग्रेलॉगकडून समन्वयकाकडे शोध विनंती येते. समन्वयक ते निर्देशांकानुसार पुनर्निर्देशित करतो, तर Elasticsearch राऊंड-रॉबिन तत्त्वाचा वापर करून प्राथमिक-शार्ड आणि प्रतिकृती-शार्ड दरम्यान विनंत्या वितरित करतो.

180 नोड्स असमानपणे प्रतिसाद देतात आणि ते प्रतिसाद देत असताना, समन्वयक माहिती जमा करत आहे जी आधीच वेगवान डेटा नोड्सद्वारे "थुंकली" गेली आहे. यानंतर, जेव्हा एकतर सर्व माहिती पोहोचते किंवा विनंती कालबाह्य झाली तेव्हा ते थेट क्लायंटला सर्वकाही देते.

ही संपूर्ण प्रणाली सरासरी 48-300ms मध्ये मागील 400 तासांच्या शोध क्वेरींवर प्रक्रिया करते, त्या क्वेरींना अग्रगण्य वाइल्डकार्डसह वगळून.

Elasticsearch सह फुले: Java सेटअप

हे सर्व आम्हाला मुळात हवे तसे कार्य करण्यासाठी, आम्ही क्लस्टरमधील विविध प्रकारच्या गोष्टी डीबग करण्यात बराच वेळ घालवला.

शोधलेल्या समस्यांचा पहिला भाग इलॅस्टिकसर्चमध्ये डीफॉल्टनुसार Java पूर्व-कॉन्फिगर केलेल्या पद्धतीशी संबंधित होता.

समस्या एक
आम्ही मोठ्या संख्येने अहवाल पाहिले आहेत की ल्युसीन स्तरावर, जेव्हा बॅकग्राउंड जॉब्स चालू असतात, तेव्हा ल्युसीन सेगमेंट त्रुटीसह अयशस्वी होते. त्याच वेळी, लॉगमध्ये हे स्पष्ट होते की ही एक OutOfMemoryError त्रुटी होती. आम्ही टेलीमेट्रीवरून पाहिले की हिप मोकळी आहे आणि हे ऑपरेशन का अयशस्वी होत आहे हे स्पष्ट झाले नाही.

असे दिसून आले की लुसीन इंडेक्स विलीन होणे हिपच्या बाहेर होते. आणि वापरल्या जाणाऱ्या संसाधनांच्या बाबतीत कंटेनर अत्यंत कठोरपणे मर्यादित आहेत. या संसाधनांमध्ये फक्त ढीगच बसू शकतात (heap.size मूल्य अंदाजे RAM च्या बरोबरीचे होते), आणि काही ऑफ-हीप ऑपरेशन्स काही कारणास्तव मर्यादेपूर्वी राहिलेल्या ~500MB मध्ये बसत नसल्यास मेमरी वाटप त्रुटीसह क्रॅश होतात.

निराकरण अगदी क्षुल्लक होते: कंटेनरसाठी उपलब्ध RAM चे प्रमाण वाढले होते, त्यानंतर आम्ही विसरलो की आम्हाला अशा समस्या देखील होत्या.

समस्या दोन
क्लस्टरच्या लाँचनंतर 4-5 दिवसांनी, आमच्या लक्षात आले की डेटा नोड्स कालांतराने क्लस्टरच्या बाहेर पडू लागले आणि 10-20 सेकंदांनंतर ते प्रविष्ट केले.

जेव्हा आम्ही ते शोधण्यास सुरुवात केली तेव्हा असे दिसून आले की इलास्टिकसर्चमधील ही ऑफ-हेप मेमरी कोणत्याही प्रकारे नियंत्रित केली जात नाही. जेव्हा आम्ही कंटेनरला अधिक मेमरी दिली, तेव्हा आम्ही विविध माहितीसह थेट बफर पूल भरण्यास सक्षम होतो आणि इलास्टिकसर्चमधून स्पष्ट GC लाँच केल्यानंतरच ते साफ केले गेले.

काही प्रकरणांमध्ये, या ऑपरेशनला बराच वेळ लागला आणि या काळात क्लस्टरने हा नोड आधीच बाहेर पडलेला म्हणून चिन्हांकित करण्यात व्यवस्थापित केले. या समस्येचे चांगले वर्णन केले आहे येथे.

उपाय खालीलप्रमाणे होता: या ऑपरेशन्ससाठी आम्ही जावाची मेमरी मोठ्या प्रमाणात वापरण्याची क्षमता मर्यादित केली. आम्ही ते 16 गीगाबाइट्स (-XX:MaxDirectMemorySize=16g) पर्यंत मर्यादित केले आहे, हे सुनिश्चित करून की स्पष्ट GC अधिक वेळा कॉल केला गेला आणि खूप जलद प्रक्रिया केली गेली, ज्यामुळे यापुढे क्लस्टर अस्थिर होणार नाही.

समस्या तीन
"सर्वात अनपेक्षित क्षणी क्लस्टर सोडून नोड्स" मधील समस्या संपल्या आहेत असे तुम्हाला वाटत असल्यास, तुम्ही चुकत आहात.

जेव्हा आम्ही निर्देशांकासह कार्य कॉन्फिगर केले, तेव्हा आम्ही mmapfs निवडले शोध वेळ कमी करा उत्कृष्ट विभाजनासह ताज्या शार्ड्सवर. ही एक चूक होती, कारण mmapfs वापरताना फाइल RAM मध्ये मॅप केली जाते आणि नंतर आम्ही मॅप केलेल्या फाइलसह कार्य करतो. यामुळे, असे दिसून आले की जेव्हा GC ऍप्लिकेशनमधील थ्रेड्स थांबवण्याचा प्रयत्न करतो, तेव्हा आम्ही बर्याच काळासाठी सेफ पॉईंटवर जातो आणि त्या मार्गावर, ऍप्लिकेशन जिवंत आहे की नाही याबद्दल मास्टरच्या विनंतीला प्रतिसाद देणे थांबवते. . त्यानुसार, मास्टरचा असा विश्वास आहे की नोड यापुढे क्लस्टरमध्ये उपस्थित नाही. यानंतर, 5-10 सेकंदांनंतर, कचरा गोळा करणारे कार्य करते, नोड जिवंत होतो, पुन्हा क्लस्टरमध्ये प्रवेश करतो आणि शार्ड्स सुरू करतो. हे सर्व "आम्ही पात्र असलेल्या उत्पादनासारखे" वाटले आणि कोणत्याही गंभीर गोष्टीसाठी ते योग्य नव्हते.

या वर्तनापासून मुक्त होण्यासाठी, आम्ही प्रथम मानक niofs वर स्विच केले, आणि नंतर, जेव्हा आम्ही इलास्टिकच्या पाचव्या आवृत्त्यांपासून सहाव्या आवृत्त्यांमध्ये स्थलांतरित झालो तेव्हा आम्ही हायब्रिडफ्सचा प्रयत्न केला, जिथे ही समस्या पुनरुत्पादित केली गेली नाही. तुम्ही स्टोरेज प्रकारांबद्दल अधिक वाचू शकता येथे.

समस्या चार
मग आणखी एक अतिशय मनोरंजक समस्या आली ज्यावर आम्ही विक्रमी वेळेसाठी उपचार केले. आम्ही ते 2-3 महिने पकडले कारण त्याचा नमुना पूर्णपणे समजण्यासारखा नव्हता.

कधीकधी आमचे समन्वयक फुल GC मध्ये गेले, सहसा दुपारच्या जेवणानंतर, आणि तेथून परत आले नाहीत. त्याच वेळी, जीसी विलंब लॉग करताना, असे दिसले: सर्व काही चांगले चालले आहे, चांगले, चांगले, आणि नंतर अचानक सर्वकाही खूप वाईट रीतीने जात आहे.

सुरुवातीला आम्हाला वाटले की आमच्याकडे एक वाईट वापरकर्ता आहे जो काही प्रकारची विनंती लाँच करत आहे ज्यामुळे समन्वयक कार्य मोडमधून बाहेर पडला. आम्ही खूप वेळ विनंत्या लॉग केल्या, काय होत आहे हे शोधण्याचा प्रयत्न केला.

परिणामी, असे दिसून आले की ज्या क्षणी वापरकर्ता एक प्रचंड विनंती लाँच करतो आणि तो विशिष्ट इलास्टिकसर्च समन्वयकाकडे जातो, तेव्हा काही नोड्स इतरांपेक्षा जास्त वेळ प्रतिसाद देतात.

आणि समन्वयक सर्व नोड्सच्या प्रतिसादाची वाट पाहत असताना, तो आधीच प्रतिसाद दिलेल्या नोड्समधून पाठवलेले परिणाम जमा करतो. GC साठी, याचा अर्थ असा आहे की आमची हीप वापरण्याची पद्धत खूप लवकर बदलते. आणि आम्ही वापरलेला GC या कार्याचा सामना करू शकला नाही.

या परिस्थितीत क्लस्टरचे वर्तन बदलण्यासाठी आम्हाला आढळलेला एकमेव उपाय म्हणजे JDK13 मध्ये स्थलांतर आणि शेननडोह कचरा गोळा करणाऱ्याचा वापर. यामुळे समस्या सुटली, आमच्या समन्वयकांची घसरण थांबली.

येथूनच Java मधील समस्या संपल्या आणि बँडविड्थ समस्या सुरू झाल्या.

Elasticsearch सह "Berries": थ्रूपुट

थ्रूपुटमधील समस्यांचा अर्थ असा होतो की आमचे क्लस्टर स्थिरपणे कार्य करते, परंतु अनुक्रमित दस्तऐवजांच्या संख्येच्या शिखरावर आणि युक्त्या दरम्यान, कामगिरी अपुरी आहे.

पहिले लक्षण समोर आले: उत्पादनातील काही "स्फोट" दरम्यान, जेव्हा खूप मोठ्या संख्येने लॉग अचानक तयार होतात, तेव्हा अनुक्रमणिक त्रुटी es_rejected_execution ग्रेलॉगमध्ये वारंवार फ्लॅश होऊ लागते.

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

अर्थात, आम्ही हे मूल्य फिरवायला गेलो आणि खालील गोष्टी शोधल्या: विशेषतः, आमच्या सेटअपमध्ये, 300 पर्यंत विनंत्या चांगल्या प्रकारे कॅश केल्या आहेत आणि आम्ही पुन्हा पूर्ण GC मध्ये उड्डाण करतो या वस्तुस्थितीने उच्च मूल्य भरलेले आहे.

याव्यतिरिक्त, हे संदेशांचे बॅचेस आहेत जे एका विनंतीमध्ये येतात, ग्रेलॉगला चिमटा काढणे आवश्यक होते जेणेकरून ते सहसा आणि लहान बॅचमध्ये नाही तर मोठ्या बॅचमध्ये किंवा बॅच अद्याप पूर्ण नसल्यास दर 3 सेकंदात एकदा लिहितात. या प्रकरणात, असे दिसून आले की आम्ही इलास्टिकसर्चमध्ये जी माहिती लिहितो ती दोन सेकंदात नाही, तर पाचमध्ये उपलब्ध होते (जी आम्हाला खूप अनुकूल आहे), परंतु मोठ्या प्रमाणात पुढे ढकलण्यासाठी तयार केलेल्या रिट्रेची संख्या. माहितीचा साठा कमी झाला आहे.

हे विशेषतः अशा क्षणांमध्ये महत्वाचे आहे जेव्हा काहीतरी कुठेतरी क्रॅश झाले आहे आणि त्याबद्दल तीव्रपणे अहवाल देतात, जेणेकरून पूर्णपणे स्पॅम केलेले लवचिक मिळू नये आणि काही काळानंतर - ग्रेलॉग नोड्स जे अडकलेल्या बफरमुळे अक्षम आहेत.

याव्यतिरिक्त, जेव्हा आमच्याकडे उत्पादनात असेच स्फोट होते, तेव्हा आम्हाला प्रोग्रामर आणि परीक्षकांकडून तक्रारी प्राप्त झाल्या: ज्या क्षणी त्यांना खरोखर या लॉगची आवश्यकता होती, तेव्हा त्यांना ते खूप हळू दिले गेले.

ते शोधू लागले. एकीकडे, हे स्पष्ट होते की शोध क्वेरी आणि अनुक्रमणिका क्वेरी दोन्हीवर प्रक्रिया केली गेली होती, मूलत: समान भौतिक मशीनवर, आणि एक किंवा दुसर्या मार्गाने काही विशिष्ट कमतरता असतील.

परंतु इलास्टिकसर्चच्या सहाव्या आवृत्त्यांमध्ये, एक अल्गोरिदम दिसल्यामुळे हे अंशतः टाळले जाऊ शकते जे तुम्हाला यादृच्छिक राउंड-रॉबिन तत्त्वानुसार नसलेल्या संबंधित डेटा नोड्स दरम्यान क्वेरी वितरित करण्यास अनुमती देते (इंडेक्सिंग करते आणि प्राथमिक धारण करणारे कंटेनर -shard खूप व्यस्त असू शकते, त्वरीत प्रतिसाद देण्याचा कोणताही मार्ग नसेल), परंतु ही विनंती प्रतिकृती-शार्डसह कमी लोड केलेल्या कंटेनरवर पाठवण्यासाठी, जे खूप जलद प्रतिसाद देईल. दुसऱ्या शब्दांत, आम्ही use_adaptive_replica_selections वर पोहोचलो: true.

वाचन चित्र असे दिसू लागते:

या अल्गोरिदममधील संक्रमणामुळे आमच्याकडे लिहिण्यासाठी लॉगचा मोठा प्रवाह होता तेव्हा त्या क्षणी क्वेरी वेळेत लक्षणीय सुधारणा करणे शक्य झाले.

शेवटी, डेटा सेंटरचे वेदनारहित काढणे ही मुख्य समस्या होती.

एका डीसीशी कनेक्शन गमावल्यानंतर लगेचच आम्हाला क्लस्टरमधून काय हवे होते:

• आमच्याकडे अयशस्वी डेटा सेंटरमध्ये वर्तमान मास्टर असल्यास, ते पुन्हा निवडले जाईल आणि दुसर्या DC मधील दुसर्या नोडमध्ये भूमिका म्हणून हलविले जाईल.
• मास्टर क्लस्टरमधून सर्व दुर्गम नोड्स त्वरीत काढून टाकेल.
• उर्वरित डेटाच्या आधारे, त्याला समजेल: हरवलेल्या डेटा सेंटरमध्ये आमच्याकडे अशा आणि अशा प्राथमिक शार्ड्स होत्या, तो उर्वरित डेटा सेंटरमध्ये त्वरीत पूरक प्रतिकृती शार्ड्सचा प्रचार करेल आणि आम्ही डेटा अनुक्रमित करणे सुरू ठेवू.
• याचा परिणाम म्हणून, क्लस्टरचे लेखन आणि वाचन थ्रूपुट हळूहळू खराब होईल, परंतु सर्वसाधारणपणे सर्वकाही कार्य करेल, जरी हळूहळू, परंतु स्थिरपणे.

जसे हे दिसून आले की, आम्हाला असे काहीतरी हवे आहे:

आणि आम्हाला खालील गोष्टी मिळाल्या:

हे कसे घडले?

जेव्हा डेटा सेंटर पडले तेव्हा आमचे मास्टर अडथळे बनले.

का?

वस्तुस्थिती अशी आहे की मास्टरकडे टास्कबॅचर आहे, जो क्लस्टरमधील विशिष्ट कार्ये आणि कार्यक्रमांचे वितरण करण्यासाठी जबाबदार आहे. कोणताही नोड एक्झिट, प्रतिकृतीपासून प्राथमिकपर्यंत शार्डची कोणतीही जाहिरात, कुठेतरी शार्ड तयार करण्याचे कोणतेही कार्य - हे सर्व प्रथम टास्कबॅचरकडे जाते, जिथे ते अनुक्रमे आणि एका थ्रेडमध्ये प्रक्रिया केली जाते.

एक डेटा सेंटर मागे घेताना, असे दिसून आले की हयात असलेल्या डेटा सेंटरमधील सर्व डेटा नोड्सने मास्टरला सूचित करणे हे त्यांचे कर्तव्य मानले होते की "आम्ही असे आणि असे शार्ड्स आणि असे डेटा नोड गमावले आहेत."

त्याच वेळी, हयात असलेल्या डेटा नोड्सने ही सर्व माहिती वर्तमान मास्टरला पाठविली आणि त्याने ते स्वीकारले याची पुष्टी होण्याची प्रतीक्षा करण्याचा प्रयत्न केला. त्यांनी याची वाट पाहिली नाही, कारण मास्टरला उत्तर देण्यापेक्षा जलद कार्ये मिळाली. नोड्सने पुनरावृत्ती केलेल्या विनंत्यांची वेळ संपली आणि यावेळी मास्टरने त्यांना उत्तर देण्याचा प्रयत्न देखील केला नाही, परंतु प्राधान्याने विनंत्या क्रमवारी लावण्याच्या कार्यात पूर्णपणे गढून गेले.

टर्मिनल फॉर्ममध्ये, असे दिसून आले की डेटा नोड्सने मास्टरला स्पॅम केले की ते पूर्ण GC मध्ये गेले. त्यानंतर, आमची मुख्य भूमिका काही पुढच्या नोडवर गेली, अगदी तीच गोष्ट घडली आणि परिणामी क्लस्टर पूर्णपणे कोलमडला.

आम्ही मोजमाप घेतले आणि आवृत्ती 6.4.0 पूर्वी, जिथे हे निश्चित केले होते, क्लस्टर पूर्णपणे बंद करण्यासाठी एकाच वेळी 10 पैकी फक्त 360 डेटा नोड्स आउटपुट करणे पुरेसे होते.

हे असे काहीतरी दिसत होते:

आवृत्ती 6.4.0 नंतर, जिथे हा भयानक बग निश्चित केला गेला होता, डेटा नोड्सने मास्टरला मारणे थांबवले. पण त्यामुळे तो “हुशार” झाला नाही. उदाहरणार्थ: जेव्हा आपण 2, 3 किंवा 10 (एका व्यतिरिक्त कोणतीही संख्या) डेटा नोड्स आउटपुट करतो, तेव्हा मास्टरला काही पहिला संदेश प्राप्त होतो ज्यामध्ये नोड A सोडला आहे आणि नोड B, नोड C याबद्दल, नोड D सांगण्याचा प्रयत्न करतो.

आणि या क्षणी, एखाद्याला एखाद्या गोष्टीबद्दल सांगण्याच्या प्रयत्नांसाठी कालबाह्य सेट करून, सुमारे 20-30 सेकंदांइतकेच, आणि अशा प्रकारे क्लस्टरच्या बाहेर जाणाऱ्या डेटा सेंटरचा वेग नियंत्रित करूनच हे हाताळले जाऊ शकते.

तत्त्वतः, हे प्रकल्पाचा भाग म्हणून अंतिम उत्पादनास सुरुवातीला सादर केलेल्या आवश्यकतांमध्ये बसते, परंतु "शुद्ध विज्ञान" च्या दृष्टिकोनातून ही एक बग आहे. जे, तसे, विकसकांनी आवृत्ती 7.2 मध्ये यशस्वीरित्या निश्चित केले होते.

शिवाय, जेव्हा एखादा विशिष्ट डेटा नोड बाहेर गेला तेव्हा असे दिसून आले की त्याच्या बाहेर पडण्याबद्दल माहिती प्रसारित करणे हे संपूर्ण क्लस्टरला सांगण्यापेक्षा अधिक महत्त्वाचे आहे की त्यावर असे आणि असे प्राथमिक-शार्ड आहेत (दुसऱ्या डेटामध्ये प्रतिकृती-शार्डचा प्रचार करण्यासाठी) प्राथमिक मध्ये केंद्र, आणि माहितीमध्ये त्यांच्यावर लिहिले जाऊ शकते).

म्हणून, जेव्हा सर्वकाही आधीच संपले आहे, तेव्हा रिलीझ केलेले डेटा नोड्स ताबडतोब शिळे म्हणून चिन्हांकित केले जात नाहीत. त्यानुसार, रिलीझ केलेल्या डेटा नोड्सवर सर्व पिंग्सची वेळ संपेपर्यंत आम्हाला प्रतीक्षा करणे भाग पडते आणि त्यानंतरच आमचे क्लस्टर आम्हाला सांगू लागते की आम्हाला तेथे, तेथे आणि तेथे माहिती रेकॉर्ड करणे सुरू ठेवण्याची आवश्यकता आहे. आपण याबद्दल अधिक वाचू शकता येथे.

परिणामी, आज डेटा सेंटर काढण्यासाठी गर्दीच्या वेळी आम्हाला सुमारे 5 मिनिटे लागतात. अशा मोठ्या आणि अनाड़ी कोलोसससाठी, हा एक चांगला परिणाम आहे.

परिणामी, आम्ही खालील निर्णयावर आलो:

• आमच्याकडे 360 गीगाबाइट डिस्कसह 700 डेटा नोड्स आहेत.
• याच डेटा नोड्सद्वारे रहदारी मार्गी लावण्यासाठी 60 समन्वयक.
• 40 मास्टर्स जे आम्ही 6.4.0 च्या आधीच्या आवृत्त्यांपासून एक प्रकारचा वारसा म्हणून सोडले आहेत - डेटा सेंटर मागे घेण्यापासून टिकून राहण्यासाठी, आम्ही अनेक मशीन गमावण्यास मानसिकरित्या तयार होतो जेणेकरून मास्टर्सचा कोरम असेल याची हमी दिली जाईल. सर्वात वाईट परिस्थिती
• एका कंटेनरवर भूमिका एकत्र करण्याचा कोणताही प्रयत्न या वस्तुस्थितीसह पूर्ण झाला की लवकरच किंवा नंतर नोड लोडमध्ये खंडित होईल.
• संपूर्ण क्लस्टर 31 गीगाबाइट्सचा heap.size वापरतो: आकार कमी करण्याच्या सर्व प्रयत्नांमुळे एकतर अग्रगण्य वाइल्डकार्डसह मोठ्या शोध क्वेरींवरील काही नोड्स नष्ट होतात किंवा Elasticsearch मध्येच सर्किट ब्रेकर मिळतात.
• याव्यतिरिक्त, शोध कार्यप्रदर्शन सुनिश्चित करण्यासाठी, आम्ही मास्टरमध्ये मिळालेल्या अडथळ्यामध्ये शक्य तितक्या कमी घटनांवर प्रक्रिया करण्यासाठी क्लस्टरमधील ऑब्जेक्ट्सची संख्या शक्य तितक्या लहान ठेवण्याचा प्रयत्न केला.

शेवटी देखरेख बद्दल

हे सर्व हेतूनुसार कार्य करते याची खात्री करण्यासाठी, आम्ही खालील निरीक्षण करतो:

• प्रत्येक डेटा नोड आमच्या क्लाउडला कळवतो की तो अस्तित्वात आहे आणि त्यावर असे आणि अशा प्रकारचे शार्ड्स आहेत. जेव्हा आपण कुठेतरी काहीतरी विझवतो, तेव्हा क्लस्टर 2-3 सेकंदांनंतर अहवाल देतो की केंद्र A मध्ये आम्ही नोड्स 2, 3 आणि 4 विझवले - याचा अर्थ असा की इतर डेटा सेंटरमध्ये आम्ही कोणत्याही परिस्थितीत ते नोड्स विझवू शकत नाही ज्यावर फक्त एक शार्ड आहे. बाकी
• गुरुच्या वर्तनाचे स्वरूप जाणून, आम्ही प्रलंबित कामांची संख्या काळजीपूर्वक पाहतो. कारण एखादे रखडलेले कार्यही, जर ते वेळेत पूर्ण झाले नाही, तर सैद्धांतिकदृष्ट्या काही आपत्कालीन परिस्थितीत कारण बनू शकते, उदाहरणार्थ, प्राथमिकमध्ये प्रतिकृती शार्डची जाहिरात कार्य करत नाही, ज्यामुळे अनुक्रमणिका कार्य करणे थांबवेल.
• आम्ही कचरा गोळा करणाऱ्या विलंबांकडे देखील बारकाईने पाहतो, कारण आम्हाला ऑप्टिमायझेशन दरम्यान या आधीच मोठ्या अडचणी आल्या आहेत.
• अडचण कुठे आहे हे आगाऊ समजून घेण्यासाठी थ्रेडद्वारे नाकारतो.
• बरं, मानक मेट्रिक्स जसे की हीप, RAM आणि I/O.

मॉनिटरिंग तयार करताना, तुम्ही इलास्टिकसर्चमधील थ्रेड पूलची वैशिष्ट्ये विचारात घेणे आवश्यक आहे. लवचिक शोध दस्तऐवजीकरण शोध आणि अनुक्रमणिका साठी कॉन्फिगरेशन पर्याय आणि डीफॉल्ट मूल्यांचे वर्णन करते, परंतु thread_pool.management बद्दल पूर्णपणे शांत आहे. हे थ्रेड्स प्रक्रिया करतात, विशेषतः, _cat/shards आणि इतर तत्सम क्वेरी, जे मॉनिटरिंग लिहिताना वापरण्यास सोयीस्कर असतात. क्लस्टर जितका मोठा असेल, तितक्या जास्त अशा विनंत्या प्रति युनिट वेळेत अंमलात आणल्या जातात आणि वर नमूद केलेले thread_pool.management केवळ अधिकृत दस्तऐवजातच सादर केले जात नाही, तर ते डीफॉल्टनुसार 5 थ्रेड्सपर्यंत मर्यादित आहे, ज्याची नंतर खूप लवकर निपटारा केली जाते. जे निरीक्षण योग्यरित्या कार्य करणे थांबवते.

मला शेवटी काय म्हणायचे आहे: आम्ही ते केले! आम्ही आमच्या प्रोग्रामर आणि डेव्हलपरना एक साधन देऊ शकलो जे जवळजवळ कोणत्याही परिस्थितीत, उत्पादनात काय घडत आहे याबद्दल द्रुत आणि विश्वासार्हपणे माहिती देऊ शकते.

होय, हे बरेच क्लिष्ट असल्याचे दिसून आले, परंतु, तरीही, आम्ही आमच्या इच्छा विद्यमान उत्पादनांमध्ये बसविण्यास व्यवस्थापित केले, ज्या आम्हाला स्वतःसाठी पॅच आणि पुन्हा लिहिण्याची गरज नव्हती.

स्त्रोत: www.habr.com