ओलेग अनास्तासयेव के साथ लघु-साक्षात्कार: अपाचे कैसेंड्रा में दोष सहिष्णुता

Odnoklassniki RuNet पर Apache Cassandra का सबसे बड़ा उपयोगकर्ता है और दुनिया में सबसे बड़े उपयोगकर्ताओं में से एक है। हमने फोटो रेटिंग्स को स्टोर करने के लिए 2010 में कैसेंड्रा का उपयोग करना शुरू किया, और अब कैसेंड्रा हजारों नोड्स पर डेटा के पेटाबाइट का प्रबंधन करता है, वास्तव में, हमने अपना स्वयं का विकास भी किया है NewSQL ट्रांजेक्शनल डेटाबेस.
12 सितंबर को हम अपने सेंट पीटर्सबर्ग कार्यालय में आयोजन करेंगे अपाचे कैसेंड्रा को समर्पित दूसरी मुलाकात. कार्यक्रम के मुख्य वक्ता ओडनोक्लास्निकी के मुख्य अभियंता ओलेग अनास्तासयेव होंगे। ओलेग वितरित और दोष-सहिष्णु प्रणालियों के क्षेत्र में एक विशेषज्ञ हैं; वह 10 से अधिक वर्षों से कैसेंड्रा के साथ काम कर रहे हैं और बार-बार सम्मेलनों में इस उत्पाद के उपयोग की विशेषताओं के बारे में बात की.

मीटअप की पूर्व संध्या पर, हमने ओलेग से कैसेंड्रा के साथ वितरित सिस्टम की दोष सहनशीलता के बारे में बात की, पूछा कि वह मीटअप में किस बारे में बात करेंगे और इस कार्यक्रम में भाग लेने लायक क्यों है।

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

- ओलेग, नमस्ते! मई में हुआ था पहली मुलाकातअपाचे कैसेंड्रा को समर्पित, प्रतिभागियों का कहना है कि देर रात तक चर्चा चलती रही, कृपया मुझे बताएं, पहली मुलाकात के बारे में आपकी क्या राय है?

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

मुझे इसमें दिलचस्पी थी और मुझे यह वाकई पसंद आया।

- घोषणा को देखते हुए, दूसरी मुलाकात पूर्णतया दोष सहनशीलता के प्रति समर्पित होगा, आपने यह विषय क्यों चुना?

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

- जब कैसंड्रा की बात आती है, तो दोष सहिष्णुता से आपका क्या मतलब है?

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

— क्या आप सबसे अधिक लोडेड और सबसे बड़े डेटा क्लस्टर का उदाहरण दे सकते हैं?

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

- बहुत खूब! कोई चीज़ कितनी बार टूटती है?

लगातार हाँ! कुल मिलाकर, हमारे पास 6 हजार से अधिक सर्वर हैं, और हर हफ्ते कुछ सर्वर और कई दर्जन डिस्क बदले जाते हैं (मशीन बेड़े के उन्नयन और विस्तार की समानांतर प्रक्रियाओं को ध्यान में रखे बिना)। प्रत्येक प्रकार की विफलता के लिए, क्या करना है और किस क्रम में करना है, इस पर स्पष्ट निर्देश हैं, जब भी संभव हो सब कुछ स्वचालित होता है, इसलिए विफलताएं नियमित होती हैं और 99% मामलों में उपयोगकर्ताओं द्वारा ध्यान नहीं दिया जाता है।

- आप ऐसे इनकारों से कैसे निपटते हैं?

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

— जैसा कि आपने कहा, कोई बिल्कुल विश्वसनीय सिस्टम नहीं हैं। आप किस प्रकार की विफलताओं के लिए तैयारी करते हैं और उनसे निपटने में सक्षम हैं?

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

- आपको क्या लगता है दोष सहनशीलता के मामले में कैसेंड्रा में क्या कमी है?

कई अन्य शुरुआती NoSQL स्टोर्स की तरह, कैसेंड्रा को इसकी आंतरिक संरचना और होने वाली गतिशील प्रक्रियाओं की गहरी समझ की आवश्यकता होती है। मैं कहूंगा कि इसमें सरलता, पूर्वानुमेयता और अवलोकनशीलता का अभाव है। लेकिन बैठक में अन्य प्रतिभागियों की राय सुनना दिलचस्प होगा!

ओलेग, सवालों के जवाब देने के लिए समय निकालने के लिए आपका बहुत-बहुत धन्यवाद!

हम उन सभी का इंतजार कर रहे हैं जो 12 सितंबर को हमारे सेंट पीटर्सबर्ग कार्यालय में होने वाली बैठक में अपाचे कैसेंड्रा के संचालन के क्षेत्र में विशेषज्ञों के साथ संवाद करना चाहते हैं।

आओ, यह दिलचस्प होगा!

आयोजन के लिए पंजीकरण करें.

स्रोत: www.habr.com