कैसंड्रा क्लस्टर बचाव अनुभव

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

परियोजना के बारे में

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

क्या गलत हुआ?

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

nodetool ring
161594151652226679147006417055137150248
X1 Up 106.92 GB 38459616957251446947579138011358024346 |<--|
X2 Up 261.58 GB 87228834825681839886276714150491220347 | ^
X3 Up 268.08 GB 136691754424709629435450736264931173936 v |
X4 Up 148.58 GB 151190524462851319585265604946253553766 | ^
X5 Up 72.71 GB 161594151652226679147006417055137150248 |-->|


सभी पाँच सर्वरों पर हार्ड ड्राइव का आकार 260GB था। डिस्क स्थान से बाहर चलने के कारण दो नोड गिर गए और पूरा क्लस्टर भार में डूब गया।

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

रीएनिमेशन

सबसे पहले, कैसंड्रा बंद होने के साथ, आप इसकी डेटा फ़ाइलों के साथ कुछ भी कर सकते हैं। हमने भारी और पुरानी फ़ाइलों में से एक (30GB) को NFS में स्थानांतरित कर दिया और उस पर सिमलिंक लगा दिया। हमने क्लस्टर शुरू किया, सेवा की जांच की - यह काम करता है। समस्या का पता चलने के समय से कुल मरम्मत समय 15 मिनट है। लगभग सभी इस समय फाइल को एनएफएस में स्थानांतरित करने में लग गए।

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

nodetool setcachecapacity App Feeds 200000 1000000

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

उपचार का प्रयास किया

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

इसलिए पहली बार मैं 1221 बग में भाग गया। फिक्स पढ़ने के बाद, मैंने नवीनतम संस्करण में अपग्रेड करने का प्रयास किया, लेकिन फिर बग 1760 ने मुझे पीछे छोड़ दिया। परिणामस्वरूप, मैंने अभी भी क्लस्टर को 0.6.5 में अपडेट किया, लेकिन इससे बहुत मदद नहीं मिली। क्लस्टर असंतुलित स्थिति में फंस गया है।

मुझे कहना होगा कि क्लस्टर के प्रबंधन के लिए उपकरण न केवल दयनीय हैं, बल्कि अल्पविकसित भी हैं। आप केवल कुछ आदेश दे सकते हैं और अप्रत्यक्ष संकेतों द्वारा उनकी प्रक्रिया की निगरानी कर सकते हैं। वह सब है।

मेरे बहुत खुशी के लिए, इस बिंदु पर प्रबंधन ने रिप्टानो से एक प्रशिक्षण संगोष्ठी को छोड़ दिया । यह कंपनी कैसेंड्रा है, वे इसे विकसित करते हैं और सशुल्क सहायता प्रदान करते हैं। इस कार्यशाला में, कैसंड्रा ताओ ने मुझे खोला।

ताओ कैसांद्रा

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

इस तरह, अंत में, मैं क्लस्टर को ठीक करने में कामयाब रहा। नोड्स को क्लस्टर से एक के बाद एक हटा दिया गया, साफ किया गया, और सही ढंग से गिने टोकन के साथ शुरू किया गया। बेशक मुझे पेपर को फिर से शुरू करने की सोच कर बैठना था जो मुझे बिना डाउनटाइम के करने की अनुमति देगा। यह एक दिलचस्प निकला, यद्यपि बहुत मुश्किल नहीं, दहनशील समस्या।

बेशक, कुछ कीड़े थे। मैं 1676 तक हर समय भूतिया था। एक लोडिंग नोड ने अपने नए डेटा का 50GB प्राप्त किया और चुपचाप बैठ गया। सेवा को पुनः आरंभ करने के परिणामस्वरूप अगले 50GB हो गए। और इसलिए जब तक सब कुछ नहीं आता।

निष्कर्ष

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

इस समय के दौरान, मैंने इस डेटाबेस के इनसाइड के बारे में बहुत कुछ सीखा, इसके रचनाकारों (आश्चर्यजनक रूप से उत्तरदायी और स्मार्ट लोगों) के साथ बात की, और यहां तक ​​कि प्रक्रिया के अंत तक, मैंने इसका आनंद लिया।