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

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

मीटअपच्या आदल्या दिवशी, आम्ही ओलेगशी कॅसॅंड्राबरोबर वितरित सिस्टमच्या दोष सहिष्णुतेबद्दल बोललो, मीटिंगमध्ये तो काय बोलेल आणि या कार्यक्रमास उपस्थित राहणे योग्य का आहे हे विचारले.

ओलेगने 1995 मध्ये त्याच्या प्रोग्रामिंग करिअरची सुरुवात केली. त्यांनी बँकिंग, दूरसंचार आणि वाहतूक क्षेत्रात सॉफ्टवेअर विकसित केले. तो प्लॅटफॉर्म टीमवर 2007 पासून ओड्नोक्लास्निकी येथे अग्रगण्य विकासक म्हणून काम करत आहे. त्याच्या जबाबदाऱ्यांमध्ये आर्किटेक्चर विकसित करणे आणि हाय-लोड सिस्टम, मोठ्या डेटा वेअरहाऊससाठी उपाय आणि पोर्टलची कार्यक्षमता आणि विश्वासार्हतेच्या समस्या सोडवणे समाविष्ट आहे. तो कंपनीतील विकासकांना प्रशिक्षणही देतो.

- ओलेग, हॅलो! मे मध्ये झाला पहिली भेट, Apache Cassandra ला समर्पित, सहभागींचे म्हणणे आहे की चर्चा रात्री उशिरापर्यंत चालली होती, कृपया मला सांगा, पहिल्या भेटीबद्दल तुमची छाप काय होती?

वेगवेगळ्या कंपन्यांचे विविध पार्श्वभूमी असलेले विकसक त्यांच्या स्वतःच्या वेदना, समस्यांचे अनपेक्षित निराकरण आणि आश्चर्यकारक कथा घेऊन आले. आम्ही बहुतेक बैठक चर्चेच्या स्वरूपात आयोजित करण्यात व्यवस्थापित केले, परंतु अशा अनेक चर्चा होत्या की आम्ही नियोजित विषयांपैकी फक्त एक तृतीयांश विषयांना स्पर्श करू शकलो. आमच्या वास्तविक उत्पादन सेवांचे उदाहरण वापरून आम्ही कसे आणि कशाचे परीक्षण करतो यावर आम्ही खूप लक्ष दिले.

मला स्वारस्य होते आणि ते खरोखर आवडले.

- घोषणेचा आधार घेत, दुसरी भेट दोष सहिष्णुतेसाठी पूर्णपणे समर्पित असेल, तुम्ही हा विषय का निवडला?

कॅसॅंड्रा ही एक सामान्य व्यस्त वितरण प्रणाली आहे ज्यामध्ये वापरकर्त्याच्या विनंतीची थेट सेवा करण्यापलीकडे मोठ्या प्रमाणात कार्यक्षमता आहे: गप्पाटप्पा, अपयश शोधणे, स्कीमा बदलांचा प्रसार, क्लस्टर विस्तार/कपात, अँटी-एंट्रॉपी, बॅकअप आणि पुनर्प्राप्ती इ. कोणत्याही वितरित प्रणालीप्रमाणे, जसे हार्डवेअरचे प्रमाण वाढते, अयशस्वी होण्याची शक्यता वाढते, त्यामुळे कॅसॅंड्रा उत्पादन क्लस्टरच्या ऑपरेशनला अपयश आणि ऑपरेटरच्या कृतींच्या बाबतीत वर्तनाचा अंदाज घेण्यासाठी त्याच्या संरचनेची सखोल माहिती आवश्यक आहे. अनेक वर्षे Cassandra वापरल्यानंतर, आम्ही लक्षणीय कौशल्य जमा केले आहे, जे आम्ही सामायिक करण्यास तयार आहोत आणि आम्हाला दुकानातील सहकारी ठराविक समस्या कशा सोडवतात यावर देखील चर्चा करायची आहे.

- जेव्हा कॅसॅन्ड्राचा प्रश्न येतो, तेव्हा तुम्हाला दोष सहिष्णुतेचा अर्थ काय आहे?

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

— तुम्ही सर्वात जास्त लोड केलेल्या आणि सर्वात मोठ्या डेटा क्लस्टरचे उदाहरण देऊ शकता का?

आमच्या सर्वात मोठ्या क्लस्टरपैकी एक म्हणजे गिफ्ट क्लस्टर: 200 पेक्षा जास्त नोड्स आणि शेकडो टीबी डेटा. परंतु ते सर्वात जास्त लोड केलेले नाही, कारण ते वितरित कॅशेने व्यापलेले आहे. आमचे सर्वात व्यस्त क्लस्टर्स लेखनासाठी हजारो RPS आणि वाचनासाठी हजारो RPS हाताळतात.

- व्वा! एखादी गोष्ट किती वेळा तुटते?

होय सर्व वेळ! एकूण, आमच्याकडे 6 हजाराहून अधिक सर्व्हर आहेत आणि प्रत्येक आठवड्यात दोन सर्व्हर आणि अनेक डझन डिस्क बदलल्या जातात (मशीन फ्लीटच्या अपग्रेड आणि विस्ताराच्या समांतर प्रक्रिया विचारात न घेता). प्रत्येक प्रकारच्या अयशस्वीतेसाठी, काय करावे आणि कोणत्या क्रमाने, जेव्हा शक्य असेल तेव्हा सर्व काही स्वयंचलित केले जाते याविषयी स्पष्ट सूचना आहेत, त्यामुळे अपयश नित्याचे असतात आणि 99% प्रकरणांमध्ये वापरकर्त्यांचे लक्ष वेधले जात नाही.

- अशा नकारांना तुम्ही कसे सामोरे जाल?

कॅसॅन्ड्राच्या ऑपरेशनच्या अगदी सुरुवातीपासून आणि पहिल्या घटनांपासून, आम्ही बॅकअप आणि त्यांच्याकडून पुनर्प्राप्तीसाठी यंत्रणांवर काम केले, कॅसॅन्ड्रा क्लस्टरची स्थिती विचारात घेणारी तैनाती प्रक्रिया तयार केली आणि उदाहरणार्थ, नोड्स रीस्टार्ट होऊ देत नाहीत. डेटा गमावणे शक्य असल्यास. आम्ही या सर्व गोष्टींबद्दल मीटिंगमध्ये बोलण्याचा विचार करत आहोत.

— तुम्ही म्हटल्याप्रमाणे, पूर्णपणे विश्वसनीय प्रणाली नाहीत. आपण कोणत्या प्रकारच्या अपयशांसाठी तयार आहात आणि हाताळण्यास सक्षम आहात?

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

- दोष सहिष्णुतेच्या बाबतीत कॅसॅंड्रामध्ये काय कमतरता आहे असे तुम्हाला वाटते?

कॅसॅन्ड्राला, इतर अनेक सुरुवातीच्या NoSQL स्टोअर्सप्रमाणे, त्याची अंतर्गत रचना आणि होत असलेल्या गतिमान प्रक्रियांची सखोल माहिती आवश्यक आहे. मी म्हणेन की त्यात साधेपणा, अंदाज आणि निरीक्षणक्षमता नाही. परंतु मीटिंगमधील इतर सहभागींची मते ऐकणे मनोरंजक असेल!

ओलेग, प्रश्नांची उत्तरे देण्यासाठी वेळ दिल्याबद्दल खूप खूप धन्यवाद!

आमच्या सेंट पीटर्सबर्ग कार्यालयात 12 सप्टेंबर रोजी होणाऱ्या बैठकीमध्ये अपाचे कॅसॅंड्रा ऑपरेट करण्याच्या क्षेत्रातील तज्ञांशी संवाद साधू इच्छिणाऱ्या प्रत्येकाची आम्ही वाट पाहत आहोत.

या, हे मनोरंजक असेल!

कार्यक्रमासाठी नोंदणी करा.

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