👨🏻‍🚀 👨🏻‍🍳 🌩️ कैसंड्रा आंखों के ऑपरेशन 🏇🏼 🍜 👩🏼‍🤝‍👩🏻

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

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

कार्य को हल करने की आवश्यकता थी कि निम्नलिखित परिस्थितियों में घटनाओं के अनुक्रम के बारे में जानकारी को कैसे संग्रहीत, खोज, संशोधित किया जाए:

ईवेंट विभिन्न सर्वरों और विभिन्न डेटा केंद्रों (यूएसए, यूरोप के पूर्वी और पश्चिमी तट) में हो सकते हैं
घटनाओं के बीच का अंतराल - एक सेकंड से लेकर कई दिनों तक
जब तक अंतिम घटना प्राप्त होती है (उदाहरण के लिए, रूपांतरण), पूरी श्रृंखला के बारे में जानकारी हाथ में होनी चाहिए
सूचना का जीवन समय लगभग दस दिन है, जिसके बाद इसे हटा दिया जाना चाहिए, अधिमानतः स्वचालित रूप से, टीटीएल के माध्यम से
पढ़ने / लिखने की घटनाओं की दर - प्रति सेकंड सैकड़ों या हजारों
प्रतिक्रिया समय: वांछनीय - 10ms तक, अनुमेय - 50ms के भीतर, अधिकतम - 100ms तक
जानकारी "हमेशा" उपलब्ध होनी चाहिए - हार्डवेयर विफलताओं, नेटवर्क, उन्नयन की परवाह किए बिना
सिस्टम को आसानी से स्केलेबल होना चाहिए: नए सर्वरों के अतिरिक्त, डेटा केंद्रों को अन्य सेवाओं के लिए पारदर्शी रूप से घटित होना चाहिए (निर्दिष्ट सीमाओं के भीतर प्रतिक्रिया समय की गिरावट स्वीकार्य है)।

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

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

लोहे का चयन

सबसे बड़ी चिंता प्रतिक्रिया समय सीमा की आवश्यकता थी - 10ms पर। दूसरे पैरामीटर को देखा जाना चाहिए जो कैसेंड्रा के आंतरिक कार्यों (संघनन, मरम्मत, ...) के सभी प्रकार के लिए मुफ्त डिस्क स्थान की उपलब्धता है। तीसरा, लोहा "सरल" होना चाहिए ताकि दुर्घटनाओं के मामले में इसे आसानी से बदला जा सके और विस्तार के दौरान जोड़ा जा सके।

प्रतिक्रिया समय

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

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

अनुमानों और परीक्षणों के परिणामस्वरूप, हमने तालिकाओं के भंडारण के लिए 8 गिग रैम, 15000rpm एसएएस डिस्क के विकल्प पर ध्यान केंद्रित करने का फैसला किया, और सामान्य रूप से कम लॉग के लिए 7200rpm एसएटीए (एक ही ऑपरेटिंग सिस्टम और कैसंड्रा स्वयं एक ही डिस्क पर स्थापित किए गए थे)

प्रोसेसर मॉडल का विकल्प इतना महत्वपूर्ण नहीं है, हम इंटेल प्रोसेसर Q9400 @ 2.66GHz, X3470 @ 2.93GHz का उपयोग करते हैं।

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

आज, कैसेंड्रा की प्रतिक्रिया समय लगभग हमेशा 5ms के भीतर होता है, 30ms के संघनन के दौरान बढ़ रहा है, और नेटवर्क समस्याओं के मामले में 100ms के स्तर तक शीघ्र ही उड़ान भर रहा है।

मुफ्त डिस्क स्थान

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

ऑपरेशन के सामान्य मोड में कैसेंड्रा (संघनन में कमी, एक नया नोड जोड़ने) के लिए कम से कम 50% डिस्क स्थान की आवश्यकता होती है, क्योंकि निकटतम संघनन अस्थायी रूप से दोगुना हो सकता है, और असफल मामलों में मरम्मत की प्रक्रिया उपभोग स्थान को तीन गुना कर सकती है। इसलिए, हमने डिस्क के वॉल्यूम को ट्रिपल मार्जिन के साथ लिया (हमें 300G मिला) और नागोस में डिस्क उपयोग के लिए स्तर निर्धारित किए: चेतावनी - 30%, महत्वपूर्ण - 50%। आज तक, अभ्यास गणना की शुद्धता की पुष्टि करता है, एक सामान्य स्थिति में हम कभी-कभी चेतावनी के लिए उड़ान भरते हैं और कभी भी महत्वपूर्ण नहीं होते हैं। मरम्मत के दौरान, कब्जे वाली जगह 50-60% तक बढ़ जाती है, कभी-कभी 70% तक।

चालू

संकुल

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

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

डेटा केंद्र

अब हमारे क्लस्टर में छह डेटा केंद्रों में बारह नोड्स हैं। एक नए डेटा सेंटर के लॉन्च में आवश्यक कॉन्फ़िगरेशन के सर्वर को ऑर्डर करना, डिस्क को चिह्नित करना, नए नोड्स के लिए आवश्यक प्रारंभिक टोकन का चयन करना और पैकेज स्थापित करना शामिल है। एक नए सर्वर पर संपूर्ण स्टार्टअप प्रक्रिया में एक घंटे तक का समय लगता है, डेटा प्रतिकृतियों के प्रारंभिक लोडिंग का समय (60% तक)।

निगरानी और प्रलेखन

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

विभिन्न मापदंडों के बीच सहसंबंध का स्पष्टीकरण हमें यह समझने की अनुमति देता है कि क्लस्टर के जीवन के मुश्किल मिनटों में आधार की प्रतिक्रिया समय बढ़ाने से कैसे बचें।

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

नोड नाम	लेट पढ़ें, एमएस	अक्षांश लिखें, एमएस	पढ़ें, ऑप्स / एस	लिखें, ऑप्स / एस	डिस्क,%	जावा,%	डेटा, जी	धाराएँ जी भेजती हैं	धाराएँ,% भेजें	धाराएँ, जीईवी पुन:	धाराएँ,% recv	कंप्यूटर अनुप्रयोग, जी	कंप्यूटर अनुप्रयोग, %
node1	0.7	0.6	66.7	10.8	15.0	60.1	39.4	0.0	0.0	0.0	0.0	0.0	0.0
node2	0.7	0.6	66.5	10.3	15.0	20.7	39.7	0.0	0.0	0.0	0.0	0.0	0.0

वही दो सर्वर, लेकिन दूसरा एक मरम्मत है:

नोड नाम	लेट पढ़ें, एमएस	लट लिखो, एमएस	पढ़ें, ऑप्स / एस	लिखें, ऑप्स / एस	डिस्क,%	जावा,%	डेटा, जी	धाराएँ जी भेजती हैं	धाराएँ,% भेजें	धाराएँ, जीईवी पुन:	धाराएँ,% recv	कंप्यूटर अनुप्रयोग, जी	कंप्यूटर अनुप्रयोग, %
node1	4.1	0.6	54.3	9.5	17.1	60.1	44.9	0.0	0.0	0.0	0.0	0.0	0.0
node2	2.6	0.5	54.5	9.5	18.5	55.2	48.9	1.9	22.3	0.0	0.0	2.5	1.2

इसके अलावा, हमने कॉर्पोरेट विकी में या कैसेंड्रा से संबंधित सभी मुद्दों पर विस्तृत टिप्पणियों के रूप में या तो खुद के लिए मुख्य प्रक्रियाओं का दस्तावेजीकरण किया।

बदनाम शंकु

NTS

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

ग्राहक फाइलर

हमारे आवेदन जावा में लिखा है और हम डेटाबेस के साथ काम करने के लिए हेक्टर लाइब्रेरी का उपयोग करते हैं। हेक्टर पर्याप्त स्मार्ट है और कनेक्शन के लिए क्लस्टर नोड चुनने के लिए क्लाइंट को विभिन्न नीतियां प्रदान करता है। पहला विकल्प जिस पर हम रुके थे - प्रत्येक ग्राहक ने नोड के साथ काम किया, जिसमें से उसे सबसे तेज़ प्रतिक्रिया मिली, सहज ज्ञान युक्त रूप से सही लग रहा था, लेकिन वास्तविकता क्रूर हो गई - यह पता चला कि यदि नोड्स में से किसी ने दूसरों की तुलना में तेजी से उत्तर दिया, तो सभी ग्राहक उस पर पहुंचे। और वास्तव में उसे DDoS दिया। जैसे ही नोड ने लोड बढ़ने के कारण धीरे-धीरे जवाब देना शुरू किया, हर कोई दूसरे पर पहुंच गया। मुझे तत्काल तर्क को फिर से लिखना पड़ा - अब ग्राहक अपने डेटा सेंटर के सभी "जीवित" नोड्स को एक सर्कल में घूमते हैं - ताकि डेटा सेंटर के भीतर नोड्स पर लोड समान रूप से वितरित हो। यदि नोड 100ms के भीतर प्रतिक्रिया नहीं करता है, तो ग्राहक इसे "मृत" के रूप में चिह्नित करता है और कभी-कभी इसकी स्थिति की जांच करने के लिए कहता है। इससे हमारी समस्या पूरी तरह से हल हो गई।

रचनाएँ, मरम्मत

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

तालिकाओं के भारी संपीड़न / मर्ज संचालन के प्रभाव में कमी में मर्ज आवृत्ति (तदनुसार, इसमें भाग लेने वाली तालिकाओं का आकार) का इष्टतम चयन होता है, समानांतरता की डिग्री (समानांतर मर्जों की संख्या में कमी से ऑपरेशन का समय बढ़ जाता है लेकिन डिस्क पर लोड कम हो जाता है) और संपीड़न ऑपरेशन के लिए अनुमत डिस्क ट्रैफ़िक।

मरम्मत ऑपरेशन प्रतिकृतियों के बीच डेटा और कब्रिस्तान को सिंक्रनाइज़ करता है। हालांकि कैसेंड्रा में इस घटना के लिए जाने पर सिंक्रनाइज़ेशन उपकरण हैं कि किसी एक प्रतिकृतियों में रिकॉर्डिंग पहली बार विफल हो गई, ये सभी उपकरण 100% गारंटी नहीं देते हैं। इसलिए, कुछ डेटा प्रोसेसिंग परिदृश्यों के लिए, समय-समय पर मरम्मत चलाने की सिफारिश की जाती है, और कुछ के लिए इसकी आवश्यकता होती है। चूंकि नोड्स (और डेटा केंद्रों के बीच) के बजाय बड़ी मात्रा में डेटा का हस्तांतरण इस प्रक्रिया में शामिल हो सकता है, इसलिए मरम्मत से तुरंत पहले डेटा विसंगतियों को कम करना महत्वपूर्ण है। इष्टतम मरम्मत प्रक्रिया का चयन और इसके लिए तैयारी में काफी समय लगा, क्योंकि ऑपरेशन मुश्किल है और आप अक्सर प्रयोग नहीं करेंगे।

नतीजतन, हमने निम्नलिखित मरम्मत स्टार्टअप रणनीति विकसित की: प्रक्रिया सप्ताह में एक बार रात में शुरू होती है; पहले, छोटे ColumnFamily के लिए, डिस्क पर तालिकाओं का एक पूर्ण मर्ज किया जाता है (यह प्रक्रिया बहुत कम संसाधन लेता है), और बड़े ColumnFamily के लिए "पुराना" (चार दिनों से अधिक) तालिकाओं का एक पूर्ण मर्ज। उत्तरार्द्ध ऑपरेशन एक तरफ कई कब्रों को साफ करता है और दूसरी तरफ अपेक्षाकृत कम संसाधनों का उपभोग करता है। समय की मरम्मत शुरू होने से, डिस्क पर एक न्यूनतम डेटा संग्रहीत किया जाता है और नोड्स के बीच अंतर और सिंक्रनाइज़ेशन की गणना करने की प्रक्रिया में, क्रमशः कम से कम समय लगता है - लगभग एक घंटे।

मरम्मत विशेष रूप से नेटवर्क की समस्याओं से ग्रस्त है - यदि सिंक्रनाइज़ेशन के दौरान कनेक्शन लंबे समय (मिनट) के लिए बाधित होता है या बड़े पैकेट नुकसान होते हैं, तो टीसीपी पर होने वाले नोड्स के बीच विनिमय अटक जाता है। कैसेंड्रा के नए संस्करणों में, आप इस तरह के हैंग के लिए टाइमआउट निर्दिष्ट कर सकते हैं।

मेमोरी और कचरा संग्रह

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

सिफारिशें

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

निष्कर्ष

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

कैसंड्रा आंखों के ऑपरेशन