डेटाबेस Kubernetes मा बस्छन्?

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

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

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

राम्रो पक्ष

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

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

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

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

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

के तपाइँ एक पकड महसुस गर्नुहुन्छ? हामी लोड वितरण गर्न र मुख्य वेब सर्भर क्र्यास हुनबाट बच्न k8s वा Swarm प्रयोग गर्छौं, तर हामी डाटाबेसको लागि यो गर्दैनौं। तर यदि डाटाबेस क्र्यास भयो भने, हाम्रो सम्पूर्ण क्लस्टर गरिएको पूर्वाधारले कुनै अर्थ राख्दैन - डाटाबेस पहुँच त्रुटि फर्काउने खाली वेब पृष्ठहरू के राम्रो छन्?

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

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

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

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

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

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

अँध्यारो पक्ष

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

सहमत हुनुहोस्, कन्टेनरमा आधार चाहिने परियोजनाहरू उत्कृष्ट मिलिङ मेसिन अपरेटरले एक हातको औंलाहरूमा गणना गर्न सकिन्छ। धेरै जसो, k8s वा Docker Swarm को प्रयोग पनि अनावश्यक छ - प्राय: यी उपकरणहरू टेक्नोलोजीहरूको सामान्य प्रचार र लिंगहरूको व्यक्तिमा "सर्वशक्तिमान" को मनोवृत्तिको कारणले गर्दा सबै कुरालाई भित्र धकेल्न प्रयोग गरिन्छ। बादल र कन्टेनरहरू। ठिक छ, किनकि अब यो फैशनेबल छ र सबैले यो गर्छन्।

कम्तिमा आधा केसहरूमा, परियोजनामा ​​Kubernetis वा केवल Docker प्रयोग गर्नु अनावश्यक छ। समस्या यो हो कि ग्राहकको पूर्वाधार कायम गर्न भाडामा लिइएका सबै टोली वा आउटसोर्सिङ कम्पनीहरू यस बारे सचेत छैनन्। यो नराम्रो हुन्छ जब कन्टेनरहरू लगाइन्छ, किनकि यसले ग्राहकलाई निश्चित मात्रामा सिक्का खर्च गर्दछ।

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

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

ठिक छ। सायद परियोजनालाई साँच्चै क्लस्टरिङ चाहिन्छ, तर यदि राज्यविहीन अनुप्रयोगहरूसँग सबै कुरा स्पष्ट छ भने, हामी कसरी क्लस्टर डाटाबेसको लागि सभ्य नेटवर्क जडान व्यवस्थित गर्न सक्छौं?

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

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

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

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

हामी के तर्फ लैजादैछौ? यसबाहेक, डाटाबेस कन्टेनराइजेशन उपयुक्त छ जहाँ यसको लागि वास्तविक आवश्यकता छ। तपाईंले पूर्ण-एप डाटाबेस भर्न सक्नुहुन्न र यसलाई स्पिन गर्न सक्नुहुन्न मानौं तपाईंसँग दुई दर्जन माइक्रोसर्भिसेसहरू छन् - यसले त्यसरी काम गर्दैन। र यो स्पष्ट रूपमा बुझ्नुपर्छ।

आउटपुटको सट्टा

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

त्यहाँ परियोजनाहरू छन् जसका लागि सिद्धान्तहरू र उपकरणहरू जुन Kubernetis सँग आउँछन् पूर्ण रूपमा फिट हुन्छन्, र त्यस्ता परियोजनाहरूमा कम्तिमा ब्याकएन्ड क्षेत्रमा शान्ति हुन्छ। र त्यहाँ परियोजनाहरू छन् जसलाई कन्टेनराइजेशन आवश्यक छैन, तर सामान्य सर्भर पूर्वाधार, किनभने तिनीहरू मौलिक रूपमा माइक्रोसर्भिस क्लस्टर मोडेलमा पुन: स्केल गर्न सक्दैनन्, किनभने तिनीहरू खस्नेछन्।

स्रोत: www.habr.com