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

किसी तरह, ऐतिहासिक रूप से, आईटी उद्योग किसी भी कारण से दो सशर्त शिविरों में विभाजित है: वे जो "के पक्ष में" हैं और जो "विरुद्ध" हैं। इसके अलावा, विवादों का विषय पूरी तरह से मनमाना हो सकता है। कौन सा ओएस बेहतर है: विन या लिनक्स? एंड्रॉइड या आईओएस स्मार्टफोन पर? क्या आपको सब कुछ बादलों में संग्रहीत करना चाहिए या इसे कोल्ड RAID स्टोरेज पर रखना चाहिए और स्क्रू को तिजोरी में रखना चाहिए? क्या PHP लोगों को प्रोग्रामर कहलाने का अधिकार है? ये विवाद, कभी-कभी, विशेष रूप से अस्तित्वगत प्रकृति के होते हैं और इनका खेल हित के अलावा कोई आधार नहीं होता है।

ऐसा हुआ कि कंटेनरों और डॉकर और सशर्त k8s के साथ इस सभी पसंदीदा व्यंजनों के आगमन के साथ, बैकएंड के विभिन्न क्षेत्रों में नई क्षमताओं के उपयोग के "पक्ष" और "विरुद्ध" बहस शुरू हो गई। (आइए पहले से ही एक आरक्षण कर लें कि यद्यपि कुबेरनेट्स को अक्सर इस चर्चा में एक ऑर्केस्ट्रेटर के रूप में इंगित किया जाएगा, इस विशेष उपकरण का चुनाव मौलिक महत्व का नहीं है। इसके बजाय, आप किसी अन्य को प्रतिस्थापित कर सकते हैं जो आपको सबसे सुविधाजनक और परिचित लगता है .)

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

उज्जवल पक्ष

लाइट साइड के तर्क को संक्षेप में एक वाक्यांश में वर्णित किया जा सकता है: "हैलो, 2k19 खिड़की के बाहर है!" बेशक, यह लोकलुभावनवाद जैसा लगता है, लेकिन अगर आप स्थिति पर विस्तार से गौर करें, तो इसके अपने फायदे हैं। आइए अब उन्हें सुलझाएं।

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

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

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

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

क्या आपको कोई पकड़ समझ में आ रही है? हम लोड को वितरित करने और मुख्य वेब सर्वर को क्रैश होने से बचाने के लिए k8s या स्वार्म का उपयोग करते हैं, लेकिन हम डेटाबेस के लिए ऐसा नहीं करते हैं। लेकिन अगर डेटाबेस क्रैश हो जाता है, तो हमारे पूरे क्लस्टर्ड इंफ्रास्ट्रक्चर का कोई मतलब नहीं रह जाता है - ऐसे खाली वेब पेजों का क्या फायदा जो डेटाबेस एक्सेस एरर लौटाते हैं?

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

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

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

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

कंटेनरीकरण और, वास्तव में, आपके प्रोजेक्ट के डेटाबेस की वितरित भौतिक टोपोलॉजी ऐसे सत्यापन क्षणों से बचने में मदद करती है। किसी नौसिखिया पर भरोसा मत करो? ठीक है! आइए उसे काम करने के लिए अपना स्वयं का क्लस्टर दें और डेटाबेस को अन्य क्लस्टर से डिस्कनेक्ट करें - केवल मैन्युअल पुश और दो कुंजियों के सिंक्रोनस रोटेशन द्वारा सिंक्रनाइज़ेशन (एक टीम लीड के लिए, दूसरा एडमिन के लिए)। और हर कोई खुश है.

और अब डेटाबेस क्लस्टरिंग का विरोधी बनने का समय आ गया है।

अंधेरा पहलू

यह तर्क देते हुए कि डेटाबेस को कंटेनरीकृत करना और इसे एक केंद्रीय सर्वर पर चलाना जारी रखना क्यों उचित नहीं है, हम रूढ़िवादिता और "दादाजी हार्डवेयर पर डेटाबेस चलाते थे, और हम भी ऐसा ही करेंगे!" जैसे बयानों की ओर नहीं झुकेंगे! इसके बजाय, आइए ऐसी स्थिति लाने का प्रयास करें जिसमें कंटेनरीकरण वास्तव में ठोस लाभांश का भुगतान करेगा।

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

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

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

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

ठीक है। शायद परियोजना को वास्तव में क्लस्टरिंग की आवश्यकता है, लेकिन अगर स्टेटलेस अनुप्रयोगों के साथ सब कुछ स्पष्ट है, तो हम क्लस्टर डेटाबेस के लिए सभ्य नेटवर्क कनेक्टिविटी कैसे व्यवस्थित कर सकते हैं?

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

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

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

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

हम किस ओर ले जा रहे हैं? इसके अलावा, डेटाबेस कंटेनरीकरण उपयुक्त है जहां इसकी वास्तविक आवश्यकता है। आप एक पूर्ण-ऐप डेटाबेस को भर नहीं सकते हैं और इसे स्पिन नहीं कर सकते हैं जैसे कि आपके पास दो दर्जन माइक्रोसर्विसेज हैं - यह उस तरह से काम नहीं करता है। और यह बात स्पष्ट रूप से समझ लेनी चाहिए.

आउटपुट के बजाय

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

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

स्रोत: www.habr.com