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

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

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

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

उज्ज्वल पक्ष

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

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

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

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

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

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

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

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

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

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

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

और अब डेटाबेस कंटेनरीकरण के विरोधियों में जूते बदलने का समय है।

अंधेरा पक्ष

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

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

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

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

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

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

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

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

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

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

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

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

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

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