डेटाबेस कुबर्नेट्समध्ये राहतात का?

असो, ऐतिहासिकदृष्ट्या, आयटी उद्योग कोणत्याही कारणास्तव दोन सशर्त शिबिरांमध्ये विभागलेला आहे: जे “साठी” आहेत आणि जे “विरुद्ध” आहेत. शिवाय, विवादांचा विषय पूर्णपणे अनियंत्रित असू शकतो. कोणते ओएस चांगले आहे: विन किंवा लिनक्स? Android किंवा iOS स्मार्टफोनवर? तुम्ही सर्व काही ढगांमध्ये साठवून ठेवावे की कोल्ड RAID स्टोरेजमध्ये ठेवावे आणि स्क्रू एका तिजोरीत ठेवावे? PHP लोकांना प्रोग्रामर म्हणण्याचा अधिकार आहे का? हे विवाद, काही वेळा, केवळ अस्तित्त्वात असतात आणि त्यांना खेळाच्या आवडीशिवाय कोणताही आधार नसतो.

हे असेच घडले की कंटेनर आणि डॉकर आणि कंडिशनल k8 सह या सर्व प्रिय पाककृतींच्या आगमनाने, बॅकएंडच्या विविध भागात नवीन क्षमतांचा वापर “साठी” आणि “विरुद्ध” वादविवाद सुरू झाले. (आपण आगाऊ आरक्षण करू या की या चर्चेत कुबेर्नेट्स बहुतेकदा ऑर्केस्ट्रेटर म्हणून सूचित केले जात असले तरी, या विशिष्ट साधनाची निवड मूलभूत महत्त्वाची नाही. त्याऐवजी, आपण आपल्यासाठी सर्वात सोयीस्कर आणि परिचित वाटणारे दुसरे कोणतेही साधन बदलू शकता. .)

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

उजळ बाजू

लाइट साइडच्या युक्तिवादाचे थोडक्यात वर्णन एका वाक्यांशात केले जाऊ शकते: "हॅलो, 2k19 खिडकीच्या बाहेर आहे!" हे नक्कीच लोकवादासारखे वाटते, परंतु जर आपण परिस्थितीचा तपशीलवार विचार केला तर त्याचे फायदे आहेत. आता त्यांची सोडवणूक करूया.

समजा तुमच्याकडे एक मोठा वेब प्रोजेक्ट आहे. हे सुरुवातीला मायक्रोसर्व्हिस पध्दतीच्या आधारावर तयार केले जाऊ शकते किंवा एखाद्या वेळी ते उत्क्रांतीच्या मार्गाने आले - खरे तर हे फार महत्वाचे नाही. तुम्ही आमचा प्रकल्प वेगळ्या मायक्रोसर्व्हिसेसमध्ये विखुरला, ऑर्केस्ट्रेशन सेट केले, लोड बॅलन्सिंग आणि स्केलिंग केले. आणि आता, स्पष्ट विवेकाने, आपण गळून पडलेले सर्व्हर वाढवण्याऐवजी हॅब्रा इफेक्ट्सच्या वेळी हॅमॉकमध्ये मोजिटो पिऊ शकता. परंतु सर्व कृतींमध्ये तुम्ही सातत्य राखले पाहिजे. बर्‍याचदा, फक्त ऍप्लिकेशन-कोड-कंटेनराइज्ड असतो. आमच्याकडे कोडशिवाय दुसरे काय आहे?

ते बरोबर आहे, डेटा. कोणत्याही प्रकल्पाचा केंद्रबिंदू हा त्याचा डेटा असतो: हे एकतर सामान्य DBMS - MySQL, Postgre, MongoDB, किंवा शोध (ElasticSearch), कॅशिंगसाठी की-व्हॅल्यू स्टोरेज - उदाहरणार्थ, रेडिस इत्यादीसाठी वापरलेले स्टोरेज असू शकते. सध्या आम्ही नाही जेव्हा डेटाबेस खराब लिखित क्वेरींमुळे क्रॅश होतो तेव्हा आम्ही कुटिल बॅकएंड अंमलबजावणी पर्यायांबद्दल बोलू आणि त्याऐवजी आम्ही क्लायंट लोड अंतर्गत या डेटाबेसची दोष सहनशीलता सुनिश्चित करण्याबद्दल बोलू. शेवटी, जेव्हा आम्ही आमचा अर्ज कंटेनरीकृत करतो आणि कितीही येणार्‍या विनंत्यांवर प्रक्रिया करण्यासाठी त्याला मुक्तपणे स्केल करण्याची परवानगी देतो, तेव्हा हे स्वाभाविकपणे डेटाबेसवरील भार वाढवते.

किंबहुना, डेटाबेसमध्ये प्रवेश करण्यासाठीचे चॅनेल आणि तो ज्या सर्व्हरवर चालतो तो आमच्या सुंदर कंटेनराइज्ड बॅकएंडमध्ये सुईचा डोळा बनतो. त्याच वेळी, कंटेनर व्हर्च्युअलायझेशनचा मुख्य हेतू संरचनेची गतिशीलता आणि लवचिकता आहे, ज्यामुळे आम्हाला शक्य तितक्या कार्यक्षमतेने उपलब्ध असलेल्या संपूर्ण पायाभूत सुविधांमध्ये पीक लोडचे वितरण आयोजित करण्याची परवानगी मिळते. म्हणजेच, जर आम्ही संपूर्ण क्लस्टरमध्ये सिस्टीमचे सर्व विद्यमान घटक कंटेनरीकृत केले नाही आणि रोल आउट केले नाही, तर आम्ही खूप गंभीर चूक करत आहोत.

केवळ अनुप्रयोगच नव्हे तर डेटा संचयित करण्यासाठी जबाबदार असलेल्या सेवा देखील क्लस्टर करणे अधिक तर्कसंगत आहे. स्वतंत्रपणे काम करणार्‍या आणि k8s मध्ये लोड वितरीत करणार्‍या वेब सर्व्हरचे क्लस्टरिंग आणि उपयोजित करून, आम्ही डेटा सिंक्रोनाइझेशनची समस्या आधीच सोडवत आहोत - जर आम्ही काही मीडिया किंवा ब्लॉग प्लॅटफॉर्म उदाहरण म्हणून घेतले तर पोस्ट्सवरील समान टिप्पण्या. कोणत्याही परिस्थितीत, आमच्याकडे एक इंट्रा-क्लस्टर आहे, अगदी आभासी, बाह्यसेवा म्हणून डेटाबेसचे प्रतिनिधित्व. प्रश्न असा आहे की डेटाबेस स्वतःच अद्याप क्लस्टर केलेला नाही - क्यूबमध्ये तैनात केलेले वेब सर्व्हर आमच्या स्थिर लढाऊ डेटाबेसमधील बदलांची माहिती घेतात, जे स्वतंत्रपणे फिरतात.

तुम्हाला झेल जाणवतो का? आम्ही लोड वितरीत करण्यासाठी आणि मुख्य वेब सर्व्हर क्रॅश होण्यापासून टाळण्यासाठी k8s किंवा Swarm वापरतो, परंतु आम्ही डेटाबेससाठी हे करत नाही. परंतु जर डेटाबेस क्रॅश झाला, तर आमच्या संपूर्ण क्लस्टर केलेल्या पायाभूत सुविधांना काही अर्थ नाही - डेटाबेस ऍक्सेस त्रुटी परत करणारी रिक्त वेब पृष्ठे काय चांगली आहेत?

म्हणूनच सामान्यतः केल्याप्रमाणे केवळ वेब सर्व्हरच नव्हे तर डेटाबेस इन्फ्रास्ट्रक्चर देखील क्लस्टर करणे आवश्यक आहे. केवळ अशा प्रकारे आपण एका संघात पूर्णपणे कार्य करणारी रचना सुनिश्चित करू शकतो, परंतु त्याच वेळी एकमेकांपासून स्वतंत्र आहे. शिवाय, जरी आमच्या बॅकएंडचा अर्धा भाग लोडखाली "संकुचित" झाला तरी, उर्वरित टिकून राहतील आणि क्लस्टरमध्ये डेटाबेस एकमेकांशी सिंक्रोनाइझ करण्याची प्रणाली आणि नवीन क्लस्टर्स सतत स्केल आणि तैनात करण्याची क्षमता आवश्यक क्षमतेपर्यंत त्वरीत पोहोचण्यास मदत करेल - जर फक्त डेटा सेंटरमध्ये रॅक असतील तर.

याव्यतिरिक्त, क्लस्टर्समध्ये वितरित डेटाबेस मॉडेल आपल्याला या डेटाबेसला आवश्यक असलेल्या ठिकाणी नेण्याची परवानगी देते; जर आपण जागतिक सेवेबद्दल बोलत असाल, तर सॅन फ्रान्सिस्को परिसरात कुठेतरी वेब क्लस्टर फिरवणे आणि त्याच वेळी मॉस्को प्रदेशात आणि मागे डेटाबेसमध्ये प्रवेश करताना पॅकेट पाठवणे अगदी अतार्किक आहे.

तसेच, डेटाबेसचे कंटेनरायझेशन आपल्याला अमूर्ततेच्या समान स्तरावर सिस्टमचे सर्व घटक तयार करण्यास अनुमती देते. जे, यामधून, प्रशासकांच्या सक्रिय सहभागाशिवाय, विकसकांद्वारे, थेट कोडमधून ही प्रणाली व्यवस्थापित करणे शक्य करते. विकसकांना वाटले की नवीन उपप्रकल्पासाठी स्वतंत्र डीबीएमएस आवश्यक आहे - सोपे! एक yaml फाइल लिहिली, ती क्लस्टरवर अपलोड केली आणि तुम्ही पूर्ण केले.

आणि अर्थातच, अंतर्गत ऑपरेशन मोठ्या प्रमाणात सरलीकृत आहे. मला सांगा, जेव्हा नवीन कार्यसंघ सदस्याने कामासाठी लढाऊ डेटाबेसमध्ये हात घातला तेव्हा तुम्ही किती वेळा डोळे बंद केले? कोणता, खरं तर, तुमच्याकडे एकमेव आहे आणि सध्या फिरत आहे? अर्थात, आम्ही येथे सर्व प्रौढ आहोत, आणि कुठेतरी आमच्याकडे एक नवीन बॅकअप आहे, आणि त्याहूनही दूर - शेल्फच्या मागे आजीच्या काकड्या आणि जुन्या स्कीसह - आणखी एक बॅकअप, कदाचित कोल्ड स्टोरेजमध्ये देखील, कारण तुमच्या ऑफिसला आधीच आग लागली होती. पण त्याचप्रमाणे, लढाऊ पायाभूत सुविधा आणि अर्थातच, लढाऊ डेटाबेसमध्ये प्रवेश असलेल्या नवीन कार्यसंघ सदस्याचा प्रत्येक परिचय आजूबाजूच्या प्रत्येकासाठी वैधॉलची बादली आहे. बरं, त्याला कोण ओळखतो, एक नवशिक्या, कदाचित तो क्रॉस-हँडेड असेल? हे भितीदायक आहे, आपण सहमत व्हाल.

कंटेनरायझेशन आणि खरं तर, तुमच्या प्रकल्पाच्या डेटाबेसचे वितरित भौतिक टोपोलॉजी अशा वैधतेचे क्षण टाळण्यास मदत करते. नवशिक्यावर विश्वास नाही? ठीक आहे! चला त्याला इतर क्लस्टर्ससह डेटाबेससह कार्य करण्यासाठी आणि डिस्कनेक्ट करण्यासाठी त्याचे स्वतःचे क्लस्टर देऊया - फक्त मॅन्युअल पुश आणि दोन की च्या सिंक्रोनस रोटेशनद्वारे सिंक्रोनाइझेशन (एक टीम लीडसाठी, दुसरी अॅडमिनसाठी). आणि प्रत्येकजण आनंदी आहे.

आणि आता डेटाबेस क्लस्टरिंगच्या विरोधकांमध्ये बदलण्याची वेळ आली आहे.

काळी बाजू

डेटाबेसचे कंटेनर बनवणे आणि एका मध्यवर्ती सर्व्हरवर ते चालू ठेवणे योग्य का नाही यावर युक्तिवाद करताना, आम्ही सनातनी आणि "आजोबांनी हार्डवेअरवर डेटाबेस चालवले आणि आम्हीही!" त्याऐवजी, कंटेनरायझेशन प्रत्यक्षात मूर्त लाभांश देऊ शकेल अशा परिस्थितीत येण्याचा प्रयत्न करूया.

सहमत आहे, ज्या प्रकल्पांना खरोखर कंटेनरमध्ये बेसची आवश्यकता आहे ते सर्वोत्तम मिलिंग मशीन ऑपरेटर नसून हाताच्या बोटांवर मोजले जाऊ शकतात. बर्‍याच भागांमध्ये, k8s किंवा डॉकर स्वॉर्मचा वापर करणे देखील निरर्थक आहे - बहुतेकदा ही साधने तंत्रज्ञानाच्या सामान्य प्रचारामुळे आणि लिंगांच्या व्यक्तीमधील "सर्वशक्तिमान" च्या वृत्तीमुळे सर्व गोष्टींमध्ये ढकलण्यासाठी वापरल्या जातात. ढग आणि कंटेनर. ठीक आहे, कारण आता ते फॅशनेबल आहे आणि प्रत्येकजण ते करतो.

किमान अर्ध्या प्रकरणांमध्ये, प्रकल्पावर कुबरनेटिस किंवा फक्त डॉकर वापरणे अनावश्यक आहे. समस्या अशी आहे की क्लायंटच्या पायाभूत सुविधा राखण्यासाठी नियुक्त केलेल्या सर्व संघ किंवा आउटसोर्सिंग कंपन्यांना याची माहिती नाही. जेव्हा कंटेनर लादले जातात तेव्हा ते अधिक वाईट असते, कारण क्लायंटला विशिष्ट प्रमाणात नाणी मोजावी लागतात.

सर्वसाधारणपणे, असे मत आहे की डॉकर/क्यूब माफिया या पायाभूत समस्यांचे आउटसोर्स करणार्‍या क्लायंटला मूर्खपणे चिरडत आहेत. शेवटी, क्लस्टर्ससह कार्य करण्यासाठी, आम्हाला अभियंते आवश्यक आहेत जे यासाठी सक्षम आहेत आणि सामान्यतः अंमलबजावणी केलेल्या सोल्यूशनची आर्किटेक्चर समजतात. आम्ही एकदा प्रजासत्ताक प्रकाशनासह आमच्या प्रकरणाचे वर्णन केले आहे - तेथे आम्ही क्लायंटच्या टीमला कुबरनेटिसच्या वास्तविकतेमध्ये कार्य करण्यासाठी प्रशिक्षित केले आणि प्रत्येकजण समाधानी झाला. आणि ते सभ्य होते. बर्‍याचदा, k8s "अंमलबजावणी करणारे" क्लायंटच्या पायाभूत सुविधांना ओलिस घेतात - कारण आता फक्त त्यांनाच समजते की तेथे सर्वकाही कसे कार्य करते; क्लायंटच्या बाजूने कोणतेही विशेषज्ञ नाहीत.

आता कल्पना करा की अशा प्रकारे आम्ही केवळ वेब सर्व्हरचा भागच नाही तर डेटाबेस देखभाल देखील करतो. आम्ही म्हणालो की बीडी हे हृदय आहे आणि हृदयाचे नुकसान कोणत्याही सजीवांसाठी घातक आहे. थोडक्यात, संभावना सर्वोत्तम नाहीत. म्हणून, कुबेरनेटीस हाईप करण्याऐवजी, बर्‍याच प्रकल्पांनी AWS साठी सामान्य दराने त्रास देऊ नये, जे त्यांच्या साइट/प्रोजेक्टवरील लोडसह सर्व समस्या सोडवेल. पण AWS आता फॅशनेबल राहिलेले नाही, आणि शो-ऑफ पैशापेक्षा जास्त किमतीचे आहेत - दुर्दैवाने, IT वातावरणातही.

ठीक आहे. कदाचित प्रकल्पाला खरोखर क्लस्टरिंगची आवश्यकता आहे, परंतु जर स्टेटलेस ऍप्लिकेशन्ससह सर्वकाही स्पष्ट असेल, तर क्लस्टर केलेल्या डेटाबेससाठी आम्ही सभ्य नेटवर्क कनेक्टिव्हिटी कशी आयोजित करू शकतो?

जर आपण निर्बाध अभियांत्रिकी सोल्यूशनबद्दल बोलत आहोत, जे k8s मध्ये संक्रमण आहे, तर आपली मुख्य डोकेदुखी क्लस्टर केलेल्या डेटाबेसमध्ये डेटा प्रतिकृती आहे. काही डीबीएमएस सुरुवातीला त्यांच्या वैयक्तिक घटनांमधील डेटाच्या वितरणासाठी एकनिष्ठ असतात. इतर अनेक जण तसे स्वागतार्ह नाहीत. आणि बर्‍याचदा आमच्या प्रकल्पासाठी डीबीएमएस निवडण्याचा मुख्य युक्तिवाद म्हणजे कमीतकमी संसाधने आणि अभियांत्रिकी खर्चासह प्रतिकृती तयार करण्याची क्षमता नाही. विशेषत: जर प्रकल्प सुरुवातीला मायक्रोसर्व्हिस म्हणून नियोजित केला गेला नसेल, परंतु या दिशेने विकसित झाला असेल.

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

व्हर्च्युअल फाइल सिस्टमचा विषय सुरू ठेवणे: डॉकर व्हॉल्यूम्स, दुर्दैवाने, समस्या-मुक्त नाहीत. सर्वसाधारणपणे, दीर्घकालीन विश्वसनीय डेटा स्टोरेजसारख्या बाबतीत, मी सर्वात तांत्रिकदृष्ट्या सोप्या योजनांसह करू इच्छितो. आणि कंटेनरच्या FS वरून मूळ होस्टच्या FS मध्ये नवीन अॅब्स्ट्रॅक्शन लेयर जोडणे स्वतःच एक धोका आहे. परंतु जेव्हा कंटेनरायझेशन सपोर्ट सिस्टमच्या ऑपरेशनमध्ये या स्तरांमधील डेटा प्रसारित करण्यात अडचणी येतात, तेव्हा ही खरोखरच आपत्ती आहे. याक्षणी, पुरोगामी मानवतेला ज्ञात असलेल्या बहुतेक समस्यांचे निर्मूलन झालेले दिसते. परंतु तुम्ही समजता, यंत्रणा जितकी गुंतागुंतीची तितकी ती तुटते.

या सर्व "साहस" च्या प्रकाशात, डेटाबेस एकाच ठिकाणी ठेवणे अधिक फायदेशीर आणि सोपे आहे, आणि जरी तुम्हाला ऍप्लिकेशन कंटेनराइज करणे आवश्यक असले तरी, ते स्वतःच चालवू द्या आणि वितरण गेटवेद्वारे एकाच वेळी संप्रेषण प्राप्त करा. डेटाबेस, जो फक्त एकदाच आणि एकाच ठिकाणी वाचला आणि लिहिला जाईल. हा दृष्टीकोन त्रुटी आणि डिसिंक्रोनाइझेशनची शक्यता कमीतकमी कमी करतो.

आपण कशाकडे नेत आहोत? शिवाय, जिथे खरी गरज आहे तिथे डेटाबेस कंटेनरायझेशन योग्य आहे. तुम्ही पूर्ण-अ‍ॅप डेटाबेस भरू शकत नाही आणि तुमच्याकडे दोन डझन मायक्रोसर्व्हिसेस असल्याप्रमाणे ते फिरवू शकत नाही - ते तसे काम करत नाही. आणि हे स्पष्टपणे समजून घेतले पाहिजे.

आउटपुटऐवजी

जर तुम्ही "डेटाबेस व्हर्च्युअलाइज करण्यासाठी किंवा नाही" स्पष्ट निष्कर्षाची वाट पाहत असाल तर आम्ही तुम्हाला निराश करू: ते येथे होणार नाही. कारण कोणताही पायाभूत उपाय तयार करताना, एखाद्याला फॅशन आणि प्रगतीने नव्हे तर, सर्व प्रथम, सामान्य ज्ञानाने मार्गदर्शन केले पाहिजे.

असे प्रकल्प आहेत ज्यासाठी कुबेरनेटिससह येणारी तत्त्वे आणि साधने पूर्णपणे जुळतात आणि अशा प्रकल्पांमध्ये किमान बॅकएंड भागात शांतता असते. आणि असे प्रकल्प आहेत ज्यांना कंटेनरायझेशनची गरज नाही, परंतु सामान्य सर्व्हर इन्फ्रास्ट्रक्चरची आवश्यकता आहे, कारण ते मूलभूतपणे मायक्रोसर्व्हिस क्लस्टर मॉडेलमध्ये पुनर्स्थित करू शकत नाहीत, कारण ते पडतील.

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