Elasticsearch क्लस्टर 200 TB+

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

हामीले Odnoklassniki मा लग व्यवस्थापनको समस्या समाधान गर्न elasticsearch को प्रयोग गर्ने निर्णय गर्यौं, र अब हामी Habr सँग हाम्रो अनुभव साझा गर्छौं: वास्तुकला र पिटफल्स बारे।

म Pyotr Zaitsev हुँ, म Odnoklassniki मा एक प्रणाली प्रशासकको रूपमा काम गर्छु। त्यो भन्दा पहिले, म एक प्रशासक पनि थिएँ, Manticore खोज, Sphinx खोज, Elasticsearch मा काम गरें। हुनसक्छ, यदि अर्को ... खोज देखा पर्‍यो भने, म पनि यसको साथ काम गर्नेछु। म स्वैच्छिक आधारमा धेरै खुला स्रोत परियोजनाहरूमा पनि भाग लिन्छु।

जब म ओड्नोक्लास्निकीमा आएँ, मैले अन्तर्वार्तामा लापरवाही भनेँ कि म Elasticsearch सँग काम गर्न सक्छु। मैले यसलाई ह्याङ्ग गरेपछि र केही साधारण कार्यहरू पूरा गरेपछि, मलाई त्यस समयमा अवस्थित लग व्यवस्थापन प्रणाली सुधार गर्ने ठूलो काम दिइएको थियो।

आवश्यकताहरू

प्रणाली आवश्यकताहरू निम्नानुसार तयार गरिएको थियो:

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

यस परियोजनाको कार्यान्वयनमा अन्तिम आवश्यकताले हामीलाई सबैभन्दा बढी खर्च गर्यो, जसको बारेमा म थप विस्तारमा कुरा गर्नेछु।

पर्यावरण

हामी चार डेटा केन्द्रहरूमा काम गर्छौं, जबकि Elasticsearch डाटा नोडहरू केवल तीनमा अवस्थित हुन सक्छन् (धेरै गैर-प्राविधिक कारणहरूका लागि)।

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

महत्त्वपूर्ण विशेषता: क्लस्टर कन्टेनरहरूमा सुरु हुन्छ पोडम्यान भौतिक मेसिनहरूमा होइन, तर आफ्नै क्लाउड उत्पादन एक-क्लाउड। कन्टेनरहरूलाई 2 कोरहरू ग्यारेन्टी गरिन्छ, 2.0Ghz v4 जस्तै, यदि तिनीहरू निष्क्रिय छन् भने बाँकी कोरहरू पुन: प्रयोग गर्ने सम्भावनाको साथ।

अर्को शब्दमा:

टोपोलजी

मैले सुरुमा निम्नानुसार समाधानको सामान्य रूप देखे:

• 3-4 VIPहरू ग्रेलोग डोमेनको A-रेकर्ड पछाडि छन्, यो लगहरू पठाइने ठेगाना हो।
• प्रत्येक VIP एक LVS ब्यालेन्सर हो।
• त्यस पछि, लगहरू ग्रेलोग ब्याट्रीमा जान्छन्, केही डाटा GELF ढाँचामा छन्, केही syslog ढाँचामा छन्।
• त्यसपछि यो सबै Elasticsearch समन्वयकहरूको ब्याट्रीमा ठूलो ब्याचमा लेखिएको छ।
• र तिनीहरू, बारीमा, सान्दर्भिक डेटा नोडहरूमा लेख्न र पढ्न अनुरोधहरू पठाउँछन्।

टर्मिनलजी

सायद सबैले शब्दावलीलाई विस्तृत रूपमा बुझ्दैनन्, त्यसैले म यसमा थोरै बस्न चाहन्छु।

Elasticsearch मा धेरै प्रकारका नोडहरू छन् - मास्टर, संयोजक, डाटा नोड। त्यहाँ विभिन्न लग रूपान्तरण र विभिन्न क्लस्टरहरू बीच सञ्चारको लागि दुई अन्य प्रकारहरू छन्, तर हामीले सूचीबद्ध मात्र प्रयोग गर्यौं।

मास्टर
यसले क्लस्टरमा उपस्थित सबै नोडहरू पिङ गर्छ, अप-टु-डेट क्लस्टर नक्सा कायम राख्छ र यसलाई नोडहरू बीच वितरण गर्छ, घटना तर्क प्रशोधन गर्छ, र विभिन्न प्रकारका क्लस्टर वाइड हाउसकीपिङ गर्छ।

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

डाटा नोड
डाटा भण्डारण गर्दछ, बाहिरबाट आएका खोज क्वेरीहरू प्रदर्शन गर्दछ र यसमा अवस्थित शार्डहरूमा कार्यहरू गर्दछ।

ग्रेलोग
यो ELK स्ट्याकमा Logstash सँग Kibana को फ्युजन जस्तै हो। ग्रेलोगले UI र लग प्रशोधन पाइपलाइन दुवै संयोजन गर्दछ। हुड अन्तर्गत, Graylog काफ्का र Zookeeper चलाउँछ, जसले ग्रेलोगलाई क्लस्टरको रूपमा जडान प्रदान गर्दछ। इलास्टिकसर्च अनुपलब्ध भएको अवस्थामा ग्रेलोगले लगहरू (काफ्का) क्यास गर्न सक्छ र निर्दिष्ट नियमहरू अनुसार असफल पढ्न र लेख्न अनुरोधहरू, समूह र चिन्ह लगाइ दोहोर्याउन सक्छ। Logstash जस्तै, Graylog ले तिनीहरूलाई Elasticsearch मा लेख्नु अघि पङ्क्तिहरू परिमार्जन गर्न कार्यक्षमता छ।

थप रूपमा, Graylog सँग एक निर्मित सेवा खोज छ जसले अनुमति दिन्छ, एउटा उपलब्ध Elasticsearch नोडको आधारमा, सम्पूर्ण क्लस्टर नक्सा प्राप्त गर्न र विशेष ट्यागद्वारा फिल्टर गर्न, जसले विशेष कन्टेनरहरूमा अनुरोधहरू निर्देशित गर्न सम्भव बनाउँछ।

दृश्यात्मक रूपमा यो केहि यस्तो देखिन्छ:

यो एक विशेष उदाहरणबाट स्क्रिनसट हो। यहाँ हामी खोज क्वेरीमा आधारित हिस्टोग्राम बनाउँछौं र सान्दर्भिक पङ्क्तिहरू प्रदर्शन गर्छौं।

अनुक्रमणिका

प्रणाली वास्तुकलामा फर्केर, म कसरी हामीले अनुक्रमणिका मोडेल निर्माण गर्यौं भन्ने बारे थप विवरणमा बस्न चाहन्छु ताकि यो सबैले सही रूपमा काम गर्‍यो।

माथिको रेखाचित्रमा, यो निम्न स्तर हो: Elasticsearch डेटा नोडहरू।

एक सूचकांक Elasticsearch shards मिलेर बनेको ठूलो भर्चुअल इकाई हो। आफैमा, प्रत्येक शार्डहरू लुसेन सूचकांक भन्दा बढी होइन। र प्रत्येक लुसेन सूचकांक, बारीमा, एक वा बढी खण्डहरू समावेश गर्दछ।

डिजाइन गर्दा, हामीले डेटाको ठूलो मात्रामा पढ्ने गतिको आवश्यकता पूरा गर्नको लागि, हामीले डेटा नोडहरूमा समान रूपमा यो डेटा "स्प्रेड" गर्न आवश्यक थियौं।

यो तथ्यमा परिणाम भयो कि प्रति अनुक्रमणिका (प्रतिकृतिहरू सहित) शार्डहरूको संख्या डाटा नोडहरूको संख्यासँग कडा रूपमा बराबर हुनुपर्छ। सबैभन्दा पहिले, दुई बराबरको प्रतिकृति कारक सुनिश्चित गर्न (अर्थात, हामी क्लस्टरको आधा गुमाउन सक्छौं)। र, दोस्रो, क्लस्टरको कम्तिमा आधामा पढ्न र लेख्न अनुरोधहरू प्रशोधन गर्न।

हामीले पहिले 30 दिनको रूपमा भण्डारण समय निर्धारण गर्यौं।

शार्डको वितरणलाई ग्राफिक रूपमा निम्नानुसार प्रतिनिधित्व गर्न सकिन्छ:

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

जब हामीले अर्को शार्ड थप्छौं, यो तेस्रो डेटा केन्द्रमा जान्छ। र, अन्तमा, हामीले यो संरचना पाउँछौं, जसले डेटा स्थिरता नगुमाई DC गुमाउन सम्भव बनाउँछ:

अनुक्रमणिकाको परिक्रमा, अर्थात् नयाँ अनुक्रमणिका सिर्जना गर्दै र सबैभन्दा पुरानो मेटाउँदै, हामीले यसलाई 48 घण्टा बराबर बनायौं (अनुक्रमणिका प्रयोगको ढाँचा अनुसार: पछिल्लो 48 घण्टा प्रायः खोजिन्छ)।

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

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

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

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

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

डाटा लेखन र पढ्ने सर्किट

यस प्रणालीमा डाटा कसरी रेकर्ड गरिएको छ भनेर पत्ता लगाउनुहोस्।

मानौं ग्रेलोगबाट संयोजकलाई केही अनुरोध आएको छ। उदाहरणका लागि, हामी 2-3 हजार पङ्क्तिहरू अनुक्रमणिका गर्न चाहन्छौं।

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

मास्टरले जवाफ दिन्छ: "यस जानकारीलाई शार्ड नम्बर 71 मा लेख्नुहोस्," त्यसपछि यो सीधै सम्बन्धित डाटा नोडमा पठाइन्छ, जहाँ प्राथमिक-शार्ड नम्बर 71 अवस्थित छ।

जस पछि लेनदेन लग एक प्रतिकृति-शार्ड मा प्रतिकृति गरिएको छ, जुन अर्को डाटा केन्द्र मा स्थित छ।

ग्रेलोगबाट संयोजकलाई खोज अनुरोध आउँछ। संयोजकले यसलाई अनुक्रमणिका अनुसार रिडिरेक्ट गर्छ, जबकि Elasticsearch ले राउन्ड-रोबिन सिद्धान्त प्रयोग गरेर प्राथमिक-shard र replica-shard बीच अनुरोधहरू वितरण गर्दछ।

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

यो सम्पूर्ण प्रणालीले गत 48 घण्टाको लागि 300-400ms मा खोज क्वेरीहरू प्रशोधन गर्दछ, ती प्रश्नहरूलाई प्रमुख वाइल्डकार्डमा बाहेक।

इलास्टिकसर्चको साथ फूलहरू: जाभा सेटअप

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

पत्ता लागेका समस्याहरूको पहिलो भाग इलास्टिकसर्चमा पूर्वनिर्धारित रूपमा जाभा पूर्व-कन्फिगर गरिएको तरिकासँग सम्बन्धित थियो।

समस्या एक
हामीले धेरै ठूलो संख्यामा रिपोर्टहरू देखेका छौं कि लुसेन स्तरमा, पृष्ठभूमि कार्यहरू चलिरहेको बेला, लुसेन खण्ड एक त्रुटिको साथ असफल हुन्छ। एकै समयमा, यो लगहरूमा स्पष्ट थियो कि यो एउटा OutOfMemoryError त्रुटि थियो। हामीले टेलिमेट्रीबाट देख्यौं कि हिप खाली थियो, र यो स्पष्ट थिएन कि यो अपरेशन किन असफल भयो।

यो बाहिर भयो कि लुसेन सूचकांक मर्ज हिप बाहिर हुन्छ। र कन्टेनरहरू उपभोग गरिएका स्रोतहरूको सन्दर्भमा कडा रूपमा सीमित छन्। केवल हिप यी स्रोतहरूमा फिट हुन सक्छ (heap.size मान लगभग RAM को बराबर थियो), र केही अफ-हिप अपरेसनहरू मेमोरी आवंटन त्रुटिको साथ क्र्यास भयो यदि कुनै कारणले तिनीहरू ~500MB मा फिट भएनन् जुन सीमा अघि रह्यो।

फिक्स एकदम मामूली थियो: कन्टेनरको लागि उपलब्ध RAM को मात्रा बढाइएको थियो, जस पछि हामीले बिर्सियौं कि हामीसँग पनि यस्ता समस्याहरू थिए।

समस्या दुई
क्लस्टर सुरु भएको 4-5 दिन पछि, हामीले देख्यौं कि डाटा नोडहरू आवधिक रूपमा क्लस्टरबाट बाहिर जान थाले र 10-20 सेकेन्ड पछि यसलाई प्रविष्ट गर्नुहोस्।

जब हामीले यसलाई पत्ता लगाउन थाल्यौं, यो बाहिर आयो कि Elasticsearch मा यो अफ-हिप मेमोरी कुनै पनि हिसाबले नियन्त्रित छैन। जब हामीले कन्टेनरलाई थप मेमोरी दियौं, हामीले विभिन्न जानकारीहरूका साथ प्रत्यक्ष बफर पूलहरू भर्न सक्षम भयौं, र इलास्टिकसर्चबाट स्पष्ट GC सुरु गरेपछि मात्र खाली गरियो।

केहि अवस्थामा, यो अपरेशनले धेरै लामो समय लियो, र यस समयमा क्लस्टरले यो नोडलाई पहिले नै बाहिर निस्किएको रूपमा चिन्ह लगाउन व्यवस्थित गर्यो। यो समस्या राम्रोसँग वर्णन गरिएको छ यहाँ.

समाधान निम्नानुसार थियो: हामीले यी कार्यहरूको लागि ढेर बाहिर मेमोरीको ठूलो मात्रा प्रयोग गर्न जाभाको क्षमतालाई सीमित गर्यौं। हामीले यसलाई 16 गीगाबाइट (-XX:MaxDirectMemorySize=16g) मा सीमित गर्यौं, स्पष्ट GC लाई धेरै पटक बोलाइयो र धेरै छिटो प्रशोधन गरियो, जसले गर्दा क्लस्टरलाई अब अस्थिर बनाउँदैन।

समस्या तीन
यदि तपाइँ सोच्नुहुन्छ कि "सबैभन्दा अप्रत्याशित क्षणमा क्लस्टर छोड्ने नोडहरू" को समस्याहरू समाप्त भएका छन्, तपाइँ गलत हुनुहुन्छ।

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

यस व्यवहारबाट छुटकारा पाउन, हामीले पहिले मानक niofs मा स्विच गर्यौं, र त्यसपछि, जब हामी इलास्टिकको पाँचौं संस्करणबाट छैठौंमा माइग्रेट गर्यौं, हामीले हाइब्रिडफहरू प्रयास गर्यौं, जहाँ यो समस्या पुन: उत्पादन गरिएको थिएन। तपाईं भण्डारण प्रकारहरू बारे थप पढ्न सक्नुहुन्छ यहाँ.

समस्या चार
त्यसपछि त्यहाँ अर्को धेरै रोचक समस्या थियो जुन हामीले रेकर्ड समयको लागि उपचार गर्यौं। हामीले यसलाई 2-3 महिनाको लागि समात्यौं किनभने यसको ढाँचा बिल्कुल नबुझेको थियो।

कहिलेकाहीँ हाम्रा संयोजकहरू पूर्ण GC मा गए, सामान्यतया खाजा पछि, र त्यहाँबाट कहिल्यै फर्केनन्। एकै समयमा, GC ढिलाइ लगाउँदा, यो यस्तो देखिन्थ्यो: सबै कुरा राम्ररी चलिरहेको छ, राम्रो, राम्रो, र त्यसपछि अचानक सबै कुरा धेरै नराम्रो हुँदै गइरहेको छ।

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

नतिजाको रूपमा, यो पत्ता लाग्यो कि प्रयोगकर्ताले ठूलो अनुरोध सुरु गर्दा, र यो एक विशिष्ट Elasticsearch समन्वयकमा पुग्छ, केही नोडहरू अरू भन्दा लामो प्रतिक्रिया दिन्छन्।

र जब संयोजक सबै नोडहरूबाट प्रतिक्रियाको लागि पर्खिरहेको छ, उसले नोडहरूबाट पठाएको नतिजाहरू जम्मा गर्छ जुन पहिले नै प्रतिक्रिया दिइसकेको छ। GC को लागि, यसको मतलब हाम्रो हिप प्रयोग ढाँचा धेरै चाँडै परिवर्तन हुन्छ। र हामीले प्रयोग गरेको GC ले यो कार्यको सामना गर्न सकेन।

यस अवस्थामा क्लस्टरको व्यवहार परिवर्तन गर्न हामीले फेला पारेको एक मात्र समाधान JDK13 मा माइग्रेसन र शेनान्डोह फोहोर संकलनकर्ताको प्रयोग हो। यसले समस्या समाधान गर्‍यो, हाम्रा संयोजकहरू झर्न रोकिए।

यो जहाँ जाभाको समस्या समाप्त भयो र ब्यान्डविथ समस्याहरू सुरु भयो।

Elasticsearch को साथ "बेरी": थ्रुपुट

थ्रुपुटको साथ समस्याहरूको मतलब हाम्रो क्लस्टरले स्थिर रूपमा काम गर्छ, तर अनुक्रमित कागजातहरूको संख्यामा शिखरमा र युद्धाभ्यासको समयमा, प्रदर्शन अपर्याप्त छ।

पहिलो लक्षण देखा पर्‍यो: उत्पादनमा केही "विस्फोटहरू" को समयमा, जब धेरै ठूलो संख्यामा लगहरू अचानक उत्पन्न हुन्छन्, अनुक्रमणिका त्रुटि es_rejected_execution ग्रेलोगमा बारम्बार फ्ल्याश हुन थाल्छ।

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

अवश्य पनि, हामी यस मानलाई ट्विस्ट गर्न गयौं र निम्न पत्ता लगायौं: विशेष गरी, हाम्रो सेटअपमा, 300 वटा अनुरोधहरू राम्ररी क्यास गरिएका छन्, र उच्च मूल्य यस तथ्यले भरिएको छ कि हामी फेरि पूर्ण GC मा उडान गर्छौं।

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

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

थप रूपमा, जब हामीसँग उत्पादनमा यी समान विस्फोटहरू थिए, हामीले प्रोग्रामरहरू र परीक्षकहरूबाट गुनासोहरू प्राप्त गर्यौं: यस क्षणमा जब उनीहरूलाई यी लगहरू चाहिन्छ, उनीहरूलाई धेरै बिस्तारै दिइयो।

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

तर इलास्टिकसर्चको छैठौं संस्करणहरूमा, एक एल्गोरिथ्म देखा पर्‍यो जसले तपाईंलाई अनियमित राउन्ड-रोबिन सिद्धान्त (इन्डेक्सिङ गर्ने कन्टेनर र प्राइमरी होल्ड गर्ने कन्टेनर) अनुसार नभई प्रासंगिक डाटा नोडहरू बीच क्वेरीहरू वितरण गर्न अनुमति दिन्छ भन्ने तथ्यको कारणले यसलाई आंशिक रूपमा रोक्न सकिन्छ। -shard धेरै व्यस्त हुन सक्छ, त्यहाँ छिटो प्रतिक्रिया दिने कुनै तरिका हुनेछैन), तर यो अनुरोधलाई प्रतिकृति-shard भएको कम लोड भएको कन्टेनरमा फर्वार्ड गर्न, जसले धेरै छिटो प्रतिक्रिया दिनेछ। अर्को शब्दमा, हामी use_adaptive_replica_selection मा पुग्यौं: true।

पढ्ने चित्र यस्तो देखिन थाल्छ:

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

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

हामीले एउटा DC सँग जडान गुमाएपछि तुरुन्तै क्लस्टरबाट के चाहन्छौं:

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

यो बाहिर निस्किएको रूपमा, हामी यो जस्तै केहि चाहन्थे:

र हामीले निम्न पायौं:

याे कसरी भयाे?

जब डाटा सेन्टर खस्यो, हाम्रो मास्टर बाधा भयो।

किन?

तथ्य यो हो कि मास्टरसँग टास्कब्याचर छ, जुन क्लस्टरमा केहि कार्यहरू र घटनाहरू वितरण गर्न जिम्मेवार छ। कुनै नोड निकास, प्रतिकृतिबाट प्राथमिकमा शार्डको कुनै पनि पदोन्नति, कतै शार्ड सिर्जना गर्ने कुनै पनि कार्य - यो सबै पहिले TaskBatcher मा जान्छ, जहाँ यसलाई क्रमिक रूपमा र एक थ्रेडमा प्रशोधन गरिन्छ।

एउटा डाटा सेन्टर फिर्ता लिने समयमा, यो बाहिरियो कि जीवित डाटा केन्द्रहरूमा सबै डाटा नोडहरू मास्टरलाई सूचित गर्न आफ्नो कर्तव्य ठान्छन् "हामीले त्यस्ता र त्यस्ता शार्डहरू र त्यस्ता र त्यस्ता डाटा नोडहरू गुमायौं।"

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

टर्मिनल फारममा, यो पत्ता लाग्यो कि डाटा नोडहरूले मास्टरलाई स्प्याम गरे कि यो पूर्ण 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।

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

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

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

स्रोत: www.habr.com