पोस्टग्रेज़ मंगलवार नंबर 5: “पोस्टग्रेएसक्यूएल और कुबेरनेट्स। सीआई/सीडी. परीक्षण स्वचालन"

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

हम इस चर्चा के मुख्य भाग की प्रतिलिपि प्रकाशित कर रहे हैं, और यहां सामुदायिक यूट्यूब चैनल पूरा वीडियो पोस्ट किया गया:

डेटाबेस और कुबेरनेट्स

НС: हम आज VACUUM और CHECKPOINTs के बारे में बात नहीं करेंगे। हम कुबेरनेट्स के बारे में बात करना चाहते हैं। मैं जानता हूं आपके पास कई वर्षों का अनुभव है. मैंने आपके वीडियो देखे और उनमें से कुछ को दोबारा भी देखा... आइए सीधे मुद्दे पर आते हैं: K8s में Postgres या MySQL आख़िर क्यों?

डी एस: इस प्रश्न का कोई निश्चित उत्तर नहीं है और न ही दिया जा सकता है। लेकिन सामान्य तौर पर, यह सरलता और सुविधा है... क्षमता। हर कोई प्रबंधित सेवाएँ चाहता है.

НС: कैसे करने के लिए RDS, केवल घर पर?

डी एस: हाँ: आरडीएस की तरह, बिल्कुल कहीं भी।

НС: "कहीं भी" एक अच्छा मुद्दा है। बड़ी कंपनियों में हर चीज़ अलग-अलग जगहों पर स्थित होती है। फिर, यदि यह एक बड़ी कंपनी है, तो तैयार समाधान क्यों नहीं लेती? उदाहरण के लिए, Nutanix का अपना विकास है, अन्य कंपनियों (VMware...) के पास समान "RDS, केवल घर पर" है।

डी एस: लेकिन हम एक अलग कार्यान्वयन के बारे में बात कर रहे हैं जो केवल कुछ शर्तों के तहत ही काम करेगा। और अगर हम कुबेरनेट्स के बारे में बात कर रहे हैं, तो बुनियादी ढांचे की एक विशाल विविधता है (जो K8s में हो सकती है)। मूलतः यह क्लाउड के लिए एपीआई के लिए एक मानक है...

НС: यह भी मुफ़्त है!

डी एस: यह इतना महत्वपूर्ण नहीं है. बाज़ार के बहुत बड़े हिस्से के लिए स्वतंत्रता महत्वपूर्ण नहीं है। कुछ और भी महत्वपूर्ण है... आपको शायद रिपोर्ट याद होगी "डेटाबेस और कुबेरनेट्स"?

НС: हाँ।

डी एस: मुझे एहसास हुआ कि इसे बहुत अस्पष्ट रूप से प्राप्त किया गया था। कुछ लोगों ने सोचा कि मैं कह रहा था: "दोस्तों, चलो कुबेरनेट्स में सभी डेटाबेस प्राप्त करें!", जबकि अन्य ने फैसला किया कि ये सभी भयानक साइकिलें थीं। लेकिन मैं बिल्कुल अलग बात कहना चाहता था: “देखो क्या हो रहा है, क्या समस्याएं हैं और उन्हें कैसे हल किया जा सकता है। क्या हमें अब कुबेरनेट्स डेटाबेस का उपयोग करना चाहिए? उत्पादन? ठीक है, केवल अगर आपको पसंद है...कुछ चीज़ें करना। लेकिन एक डेवलपर के लिए, मैं कह सकता हूं कि मैं इसकी अनुशंसा करता हूं। एक डेवलपर के लिए, वातावरण बनाने/हटाने की गतिशीलता बहुत महत्वपूर्ण है।"

एनएस: देव से क्या आपका तात्पर्य उन सभी परिवेशों से है जो उत्पाद नहीं हैं? मंचन, क्यूए…

डी एस: यदि हम पूर्ण स्टैंड के बारे में बात कर रहे हैं, तो शायद नहीं, क्योंकि वहां की आवश्यकताएं विशिष्ट हैं। यदि हम विशेष मामलों के बारे में बात कर रहे हैं जहां स्टेजिंग के लिए बहुत बड़े डेटाबेस की आवश्यकता होती है, तो शायद नहीं... यदि यह एक स्थिर, दीर्घकालिक वातावरण है, तो डेटाबेस को K8s में स्थित करने का क्या लाभ है?

НС: कोई नहीं। लेकिन हम स्थिर वातावरण कहाँ देखते हैं? एक स्थिर वातावरण कल अप्रचलित हो जाएगा।

डी एस: मंचन स्थिर हो सकता है. हमारे पास ग्राहक हैं...

НС: हाँ, मेरे पास भी एक है। यदि आपके पास 10 टीबी डेटाबेस और 200 जीबी स्टेजिंग है तो यह एक बड़ी समस्या है...

डी एस: मेरे पास एक बहुत अच्छा मामला है! स्टेजिंग पर एक उत्पाद डेटाबेस होता है जिसमें परिवर्तन किए जाते हैं। और वहाँ एक बटन है: "उत्पादन के लिए रोल आउट"। ये परिवर्तन - डेल्टा - उत्पादन में जोड़े जाते हैं (ऐसा लगता है कि वे केवल एपीआई के माध्यम से सिंक्रनाइज़ हैं)। यह एक बहुत ही आकर्षक विकल्प है.

НС: मैंने घाटी में ऐसे स्टार्टअप देखे हैं जो आरडीएस या यहां तक ​​कि हरोकू में बैठे हैं - ये 2-3 साल पहले की कहानियां हैं - और वे डंप को अपने लैपटॉप में डाउनलोड करते हैं। क्योंकि डेटाबेस अभी भी केवल 80 जीबी है, और लैपटॉप पर जगह है। फिर वे सभी के लिए अतिरिक्त डिस्क खरीदते हैं ताकि उनके पास अलग-अलग विकास करने के लिए 3 डेटाबेस हों। ऐसा भी होता है. मैंने यह भी देखा कि वे स्टेजिंग में उत्पाद की नकल करने से डरते नहीं हैं - यह बहुत हद तक कंपनी पर निर्भर करता है। लेकिन मैंने यह भी देखा कि वे बहुत डरते हैं, और अक्सर उनके पास पर्याप्त समय और हाथ नहीं होता है। लेकिन इससे पहले कि हम इस विषय पर आगे बढ़ें, मैं कुबेरनेट्स के बारे में सुनना चाहूंगा। क्या मैं सही ढंग से समझता हूं कि अभी तक कोई भी उत्पादन में नहीं है?

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

НС: 100 जीबी तक के इस आकार के डेटाबेस को अच्छी डिस्क और अच्छे नेटवर्क पर कुछ ही मिनटों में रोल आउट किया जा सकता है, है ना? 1 जीबी प्रति सेकंड की स्पीड अब आकर्षक नहीं रही।

डी एस: हाँ, रैखिक संचालन के लिए यह कोई समस्या नहीं है।

НС: ठीक है, हमें सिर्फ उत्पाद के बारे में सोचना है। और यदि हम कुबेरनेट्स को गैर-उत्पाद वातावरण के लिए विचार कर रहे हैं, तो हमें क्या करना चाहिए? मैं इसे ज़ालैंडो में देखता हूं ऑपरेटर करो, कुरकुरे में काटना, कुछ अन्य विकल्प भी हैं। और वहां है ऑनग्रेस - यह स्पेन से हमारा अच्छा दोस्त अल्वारो है: वे जो करते हैं वह मूलतः उचित नहीं है ऑपरेटर, और संपूर्ण वितरण (स्टैकग्रेस), जिसमें, पोस्टग्रेज़ के अलावा, उन्होंने एक बैकअप, एन्वॉय प्रॉक्सी को भरने का भी निर्णय लिया...

डी एस: दूत किसलिए? विशेष रूप से पोस्टग्रेज़ ट्रैफ़िक को संतुलित करना?

НС: हाँ। अर्थात्, वे इसे इस प्रकार देखते हैं: यदि आप लिनक्स वितरण और कर्नेल लेते हैं, तो नियमित पोस्टग्रेएसक्यूएल कर्नेल है, और वे एक ऐसा वितरण बनाना चाहते हैं जो क्लाउड-अनुकूल हो और कुबेरनेट्स पर चले। वे घटकों (बैकअप, आदि) को एक साथ रखते हैं और उन्हें डीबग करते हैं ताकि वे अच्छी तरह से काम करें।

डी एस: बहुत ही शांत! अनिवार्य रूप से यह आपके स्वयं के प्रबंधित पोस्टग्रेज़ बनाने के लिए सॉफ़्टवेयर है।

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

डी एस: मुझे ठीक से नहीं पता कि ज़ालैंडो किस स्थिति में आया, लेकिन कुबेरनेट्स में भंडारण अब इस तरह से बनाया गया है कि सामान्य विधि का उपयोग करके डिस्क बैकअप लेना असंभव है। हाल ही में मानक में - नवीनतम संस्करण में सीएसआई विशिष्टताएँ — हमने स्नैपशॉट को संभव बनाया, लेकिन इसे लागू कहां किया गया? ईमानदारी से कहूं तो, सब कुछ अभी भी बहुत कच्चा है... हम AWS, GCE, Azure, vSphere के शीर्ष पर CSI का प्रयास कर रहे हैं, लेकिन जैसे ही आप इसका उपयोग करना शुरू करते हैं, आप देख सकते हैं कि यह अभी तक तैयार नहीं है।

НС: इसीलिए हमें कभी-कभी बुनियादी ढांचे पर निर्भर रहना पड़ता है। मुझे लगता है कि यह अभी भी प्रारंभिक चरण है - दर्द बढ़ रहा है। प्रश्न: आप उन नए लोगों को क्या सलाह देंगे जो K8s में PgSQL आज़माना चाहते हैं? शायद कौन सा ऑपरेटर?

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

НС: और MySQL के लिए भी नहीं? मुझे पता है कि पेरकोना... चूंकि वे अब MySQL, MongoDB और Postgres पर काम कर रहे हैं, उन्हें किसी प्रकार का सार्वभौमिक समाधान बनाना होगा: सभी डेटाबेस के लिए, सभी क्लाउड प्रदाताओं के लिए।

डी एस: हमारे पास MySQL के ऑपरेटरों को देखने का समय नहीं था। अभी यह हमारा मुख्य फोकस नहीं है। MySQL स्टैंडअलोन में ठीक काम करता है। यदि आप केवल डेटाबेस लॉन्च कर सकते हैं तो ऑपरेटर का उपयोग क्यों करें... आप Postrges के साथ एक डॉकर कंटेनर लॉन्च कर सकते हैं, या आप इसे सरल तरीके से लॉन्च कर सकते हैं।

НС: इस बारे में भी एक सवाल था. बिल्कुल कोई ऑपरेटर नहीं?

डी एस: हाँ, हममें से 100% के पास PostgreSQL बिना किसी ऑपरेटर के चल रहा है। अब तक तो। हम प्रोमेथियस और रेडिस के लिए सक्रिय रूप से ऑपरेटर का उपयोग करते हैं। हमारे पास इलास्टिक्स खोज के लिए एक ऑपरेटर खोजने की योजना है - यह वह है जो सबसे अधिक "आग पर" है, क्योंकि हम इसे 100% मामलों में कुबेरनेट्स में स्थापित करना चाहते हैं। जैसे हम यह सुनिश्चित करना चाहते हैं कि कुबेरनेट्स में MongoDB भी हमेशा स्थापित रहे। यहां कुछ इच्छाएं प्रकट होती हैं - एक भावना है कि इन मामलों में कुछ किया जा सकता है। और हमने पोस्टग्रेज़ को देखा भी नहीं। बेशक, हम जानते हैं कि अलग-अलग विकल्प हैं, लेकिन वास्तव में हमारे पास एक स्टैंडअलोन विकल्प है।

कुबेरनेट्स में परीक्षण के लिए डीबी

НС: चलिए परीक्षण के विषय पर आगे बढ़ते हैं। डेटाबेस में परिवर्तन कैसे करें - DevOps परिप्रेक्ष्य से। माइक्रोसर्विसेज हैं, कई डेटाबेस हैं, हर समय कहीं न कहीं कुछ न कुछ बदलता रहता है। सामान्य सीआई/सीडी कैसे सुनिश्चित करें ताकि डीबीएमएस परिप्रेक्ष्य से सब कुछ क्रम में हो। आपका दृष्टिकोण क्या है?

डी एस: इसका कोई एक उत्तर नहीं हो सकता. कई विकल्प हैं. पहला आधार का आकार है जिसे हम रोल आउट करना चाहते हैं। आपने स्वयं उल्लेख किया है कि कंपनियों का विकास और मंच पर उत्पाद डेटाबेस की एक प्रति रखने के प्रति अलग-अलग दृष्टिकोण है।

НС: और जीडीपीआर की शर्तों के तहत, मुझे लगता है कि वे अधिक से अधिक सावधान हो रहे हैं... मैं कह सकता हूं कि यूरोप में उन्होंने पहले ही जुर्माना लगाना शुरू कर दिया है।

डी एस: लेकिन अक्सर आप ऐसा सॉफ़्टवेयर लिख सकते हैं जो उत्पादन से डंप लेता है और उसे अस्पष्ट कर देता है। उत्पाद डेटा प्राप्त किया जाता है (स्नैपशॉट, डंप, बाइनरी कॉपी...), लेकिन यह अज्ञात है। इसके बजाय, जेनरेशन स्क्रिप्ट हो सकती हैं: ये फिक्स्चर या सिर्फ एक स्क्रिप्ट हो सकती है जो एक बड़ा डेटाबेस तैयार करती है। समस्या यह है: आधार छवि बनाने में कितना समय लगता है? और इसे वांछित वातावरण में तैनात करने में कितना समय लगता है?

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

НС: साधारण नकल से?

डी एस: डेटा सीधे डॉकर छवि में संग्रहीत किया जाता है। वे। हमारे पास एक तैयार छवि है, यद्यपि 100 जीबी। डॉकर में परतों के लिए धन्यवाद, हम इस छवि को जितनी बार चाहें उतनी बार तैनात कर सकते हैं। तरीका मूर्खतापूर्ण है, लेकिन यह अच्छा काम करता है।

НС: फिर, जब आप परीक्षण करते हैं, तो यह डॉकर के अंदर ही बदल जाता है, है ना? डॉकर के अंदर कॉपी-ऑन-राइट - इसे फेंक दें और फिर से जाएं, सब कुछ ठीक है। कक्षा! और क्या आप पहले से ही इसका पूर्ण उपयोग कर रहे हैं?

डी एस: कब का।

НС: हम बहुत समान चीजें करते हैं। केवल हम डॉकर की कॉपी-ऑन-राइट का उपयोग नहीं करते हैं, बल्कि किसी अन्य का उपयोग करते हैं।

डी एस: यह सामान्य नहीं है. और डॉकर हर जगह काम करता है।

НС: सिद्धांत रूप में, हाँ. लेकिन हमारे पास वहां मॉड्यूल भी हैं, आप अलग-अलग मॉड्यूल बना सकते हैं और विभिन्न फ़ाइल सिस्टम के साथ काम कर सकते हैं। यहाँ कैसा क्षण है! पोस्टग्रेज़ की ओर से, हम इस सब को अलग तरह से देखते हैं। अब मैंने डॉकर की तरफ से देखा और पाया कि सब कुछ आपके लिए काम करता है। लेकिन यदि डेटाबेस बहुत बड़ा है, उदाहरण के लिए, 1 टीबी, तो इस सब में बहुत समय लगता है: रात में संचालन, और सब कुछ डॉकर में भरना... और यदि 5 टीबी डॉकर में भर दिया जाता है... या सब कुछ ठीक है?

डी एस: क्या अंतर है: ये बूँदें हैं, बस बिट्स और बाइट्स हैं।

НС: अंतर यह है: क्या आप इसे डंप और रिस्टोर के माध्यम से करते हैं?

डी एस: बिल्कुल जरूरी नहीं. इस छवि को बनाने की विधियाँ भिन्न हो सकती हैं।

НС: कुछ ग्राहकों के लिए, हमने इसे इस तरह बनाया है कि नियमित रूप से एक आधार छवि तैयार करने के बजाय, हम इसे लगातार अद्यतित रखें। यह मूलतः एक प्रतिकृति है, लेकिन यह सीधे मास्टर से नहीं, बल्कि एक संग्रह के माध्यम से डेटा प्राप्त करता है। एक बाइनरी संग्रह जहां हर दिन वाल डाउनलोड किए जाते हैं, जहां बैकअप लिया जाता है... फिर ये वाल थोड़ी देरी (वस्तुतः 1-2 सेकंड) के साथ आधार छवि तक पहुंचते हैं। हम इसे किसी भी तरह से क्लोन करते हैं - अब हमारे पास डिफ़ॉल्ट रूप से ZFS है।

डी एस: लेकिन ZFS के साथ आप एक नोड तक सीमित हैं।

НС: हाँ। लेकिन ZFS में भी एक जादू है भेजें: इसके साथ आप एक स्नैपशॉट भेज सकते हैं और यहां तक ​​कि (मैंने वास्तव में अभी तक इसका परीक्षण नहीं किया है, लेकिन...) आप दो के बीच एक डेल्टा भेज सकते हैं PGDATA. वास्तव में, हमारे पास एक और उपकरण है जिस पर हमने वास्तव में ऐसे कार्यों के लिए विचार नहीं किया है। PostgreSQL के पास है पृष्ठ_रिवाइंड, जो एक "स्मार्ट" rsync की तरह काम करता है, जो आपको देखने के लिए नहीं है उसे बहुत कुछ छोड़ देता है, क्योंकि वहां कुछ भी नहीं बदला है। हम दो सर्वरों के बीच त्वरित सिंक्रनाइज़ेशन कर सकते हैं और उसी तरह रिवाइंड कर सकते हैं।

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

डी एस: 50 बार का मतलब है कि आपको 50 स्पॉट इंस्टेंसेस ऑर्डर करने की आवश्यकता है।

НС: नहीं, हम सब कुछ एक मशीन पर करते हैं।

डी एस: लेकिन आप 50 गुना विस्तार कैसे करेंगे यदि यह एक डेटाबेस, मान लीजिए, टेराबाइट है। सबसे अधिक संभावना है कि उसे सशर्त 256 जीबी रैम की आवश्यकता है?

НС: हाँ, कभी-कभी आपको बहुत अधिक मेमोरी की आवश्यकता होती है - यह सामान्य है। लेकिन यह जीवन से एक उदाहरण है. उत्पादन मशीन में 96 कोर और 600 जीबी हैं। वहीं, डेटाबेस के लिए 32 कोर (अब कभी-कभी 16 कोर भी) और 100-120 जीबी मेमोरी का उपयोग किया जाता है।

डी एस: और 50 प्रतियां वहां फिट होंगी?

НС: तो केवल एक कॉपी है, फिर कॉपी-ऑन-राइट (जेडएफएस) काम करता है... मैं आपको और अधिक विस्तार से बताऊंगा।

उदाहरण के लिए, हमारे पास 10 टीबी डेटाबेस है। उन्होंने इसके लिए एक डिस्क बनाई, ZFS ने इसके आकार को 30-40 प्रतिशत तक संपीड़ित भी किया। चूँकि हम लोड परीक्षण नहीं करते हैं, इसलिए सटीक प्रतिक्रिया समय हमारे लिए महत्वपूर्ण नहीं है: इसे 2 गुना तक धीमा होने दें - यह ठीक है।

हम प्रोग्रामर, क्यूए, डीबीए आदि को अवसर देते हैं। 1-2 थ्रेड में परीक्षण करें. उदाहरण के लिए, वे किसी प्रकार का माइग्रेशन चला सकते हैं। इसे एक बार में 10 कोर की आवश्यकता नहीं है - इसे 1 पोस्टग्रेज बैकएंड, 1 कोर की आवश्यकता है। प्रवास शुरू हो जायेगा - हो सकता है ऑटोवैक्यूम फिर भी प्रारंभ होगा, फिर दूसरे कोर का उपयोग किया जाएगा। हमारे पास 16-32 कोर आवंटित हैं, इसलिए 10 लोग एक ही समय में काम कर सकते हैं, कोई समस्या नहीं।

क्योंकि शारीरिक रूप से PGDATA वही, यह पता चलता है कि हम वास्तव में पोस्टग्रेज को धोखा दे रहे हैं। चाल यह है: उदाहरण के लिए, 10 पोस्टग्रेज़ एक साथ लॉन्च किए जाते हैं। आमतौर पर समस्या क्या है? वे डाल share_buffers, मान लीजिए 25%। इस हिसाब से ये 200 जीबी है. आप इनमें से तीन से अधिक लॉन्च नहीं कर पाएंगे, क्योंकि मेमोरी ख़त्म हो जाएगी.

लेकिन कुछ बिंदु पर हमें एहसास हुआ कि यह आवश्यक नहीं था: हमने शेयर्ड_बफ़र्स को 2 जीबी पर सेट किया। PostgreSQL के पास है प्रभावी_कैश_आकार, और वास्तव में यह एकमात्र ऐसा है जो प्रभावित करता है योजनाओं. हमने इसे 0,5 टीबी पर सेट किया है। और इससे कोई फर्क नहीं पड़ता कि वे वास्तव में अस्तित्व में नहीं हैं: वह योजनाएँ ऐसे बनाता है जैसे कि वे मौजूद हों।

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

डी एस: क्या आपको नहीं लगता कि यहां कुछ समस्याएं हैं? पहला एक समाधान है जो केवल PostgreSQL पर काम करता है। यह दृष्टिकोण बहुत निजी है, सामान्य नहीं है. दूसरा यह है कि कुबेरनेट्स (और वह सब कुछ जो क्लाउड प्रौद्योगिकियाँ अब करने जा रही हैं) में कई नोड्स शामिल हैं, और ये नोड्स अल्पकालिक हैं। और आपके मामले में यह एक स्टेटफुल, लगातार नोड है। ये चीजें मुझे विवादित बनाती हैं।'

НС: सबसे पहले, मैं सहमत हूं, यह पूरी तरह से पोस्टग्रेज कहानी है। मुझे लगता है कि अगर हमारे पास लगभग सभी मेमोरी के लिए किसी प्रकार का प्रत्यक्ष आईओ और बफर पूल है, तो यह दृष्टिकोण काम नहीं करेगा - योजनाएं अलग होंगी। लेकिन अभी हम केवल पोस्टग्रेज़ के साथ काम करते हैं, हम दूसरों के बारे में नहीं सोचते हैं।

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

डी एस: मेरे दृष्टिकोण से, हम कुबेरनेट्स में पॉड बनाते हैं। K8s - इलास्टिक: गांठों को आवश्यकतानुसार ऑर्डर किया जाता है। कार्य केवल एक पॉड बनाना और यह कहना है कि उसे X मात्रा में संसाधनों की आवश्यकता है, और फिर K8s इसे स्वयं ही समझ लेगा। लेकिन कुबेरनेट्स में भंडारण समर्थन अभी भी अस्थिर है: 1.16में 1.17 (यह विज्ञप्ति जारी की गई थी недели पहले) ये सुविधाएँ केवल बीटा बन जाती हैं।

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

НС: सभी इंजनों (अमेज़ॅन, गूगल...) के लिए इस संस्करण का समर्थन शुरू करना भी आवश्यक है - इसमें भी कुछ समय लगता है।

डी एस: हम अभी तक उनका उपयोग नहीं करते हैं. हम अपना उपयोग करते हैं।

कुबेरनेट्स के लिए स्थानीय विकास

НС: क्या आपके मन में ऐसी इच्छा आई है जब आपको सभी पॉड्स को एक मशीन पर स्थापित करने और इतना छोटा परीक्षण करने की आवश्यकता हो। अवधारणा का शीघ्र प्रमाण प्राप्त करने के लिए, देखें कि एप्लिकेशन कुबेरनेट्स में चलता है, इसके लिए बहुत सारी मशीनें समर्पित किए बिना। वहाँ मिनिक्यूब है, है ना?

डी एस: मुझे ऐसा लगता है कि यह मामला - एक नोड पर तैनात - विशेष रूप से स्थानीय विकास के बारे में है। या ऐसे पैटर्न की कुछ अभिव्यक्तियाँ। खाओ मिनिक्यूब, वहाँ है K3s, मेहरबान. हम डॉकर में कुबेरनेट्स का उपयोग करने की दिशा में आगे बढ़ रहे हैं। अब हमने परीक्षणों के लिए इसके साथ काम करना शुरू कर दिया।

НС: मैं सोचता था कि यह सभी पॉड्स को एक डॉकर छवि में लपेटने का एक प्रयास था। लेकिन यह पता चला कि यह बिल्कुल अलग चीज़ के बारे में है। वैसे भी, अलग कंटेनर, अलग पॉड हैं - बस डॉकर में।

डी एस: हाँ। और एक अजीब सी नकल बनाई गई है, लेकिन इसका अर्थ यह है... हमारे पास तैनाती के लिए एक उपयोगिता है - Werf. हम इसे एक सशर्त मोड बनाना चाहते हैं werf up: "मेरे लिए स्थानीय कुबेरनेट्स लाओ।" और फिर वहां सशर्त चलाएँ werf follow. फिर डेवलपर आईडीई को संपादित करने में सक्षम होगा, और सिस्टम में एक प्रक्रिया शुरू की जाएगी जो परिवर्तनों को देखती है और छवियों को फिर से बनाती है, उन्हें स्थानीय K8 पर फिर से तैनात करती है। इस तरह हम स्थानीय विकास की समस्या को हल करने का प्रयास करना चाहते हैं।

K8s वास्तविकता में स्नैपशॉट और डेटाबेस क्लोनिंग

НС: यदि हम कॉपी-ऑन-राइट पर लौटते हैं। मैंने देखा कि बादलों के भी स्नैपशॉट होते हैं। वे अलग ढंग से काम करते हैं. उदाहरण के लिए, जीसीपी में: आपके पास संयुक्त राज्य अमेरिका के पूर्वी तट पर एक मल्टी-टेराबाइट उदाहरण है। आप समय-समय पर स्नैपशॉट लेते रहते हैं. आप स्नैपशॉट से पश्चिमी तट पर डिस्क की एक प्रति उठाते हैं - कुछ ही मिनटों में सब कुछ तैयार हो जाता है, यह बहुत तेज़ी से काम करता है, केवल मेमोरी में कैश भरने की आवश्यकता होती है। लेकिन ये क्लोन (स्नैपशॉट) एक नए वॉल्यूम को 'प्रावधान' करने के लिए हैं। जब आपको बहुत सारे उदाहरण बनाने की आवश्यकता होती है तो यह अच्छा होता है।

लेकिन परीक्षणों के लिए, मुझे ऐसा लगता है कि स्नैपशॉट, जिसके बारे में आप डॉकर में बात करते हैं या मैं ZFS, btrfs और यहां तक ​​कि LVM में बात करता हूं... - वे आपको एक मशीन पर वास्तव में नया डेटा नहीं बनाने की अनुमति देते हैं। क्लाउड में, आप अभी भी हर बार उनके लिए भुगतान करेंगे और सेकंड नहीं, बल्कि मिनट (और मामले में) प्रतीक्षा करेंगे हल्का भार, संभवतः एक घड़ी)।

इसके बजाय, आप इस डेटा को एक या दो सेकंड में प्राप्त कर सकते हैं, परीक्षण चला सकते हैं और इसे फेंक सकते हैं। ये स्नैपशॉट विभिन्न समस्याओं का समाधान करते हैं. पहले मामले में - पैमाने बढ़ाने और नई प्रतिकृतियां प्राप्त करने के लिए, और दूसरे में - परीक्षणों के लिए।

डी एस: मैं सहमत नहीं हूं. वॉल्यूम क्लोनिंग को ठीक से काम कराना क्लाउड का काम है। मैंने उनके कार्यान्वयन पर ध्यान नहीं दिया है, लेकिन मुझे पता है कि हम इसे हार्डवेयर पर कैसे करते हैं। हमारे पास सेफ़ है, यह किसी भी भौतिक आयतन की अनुमति देता है (आरबीडी) कहना क्लोन और दसियों मिलीसेकंड में समान विशेषताओं वाला दूसरा खंड प्राप्त करें, IOPS'अमी इत्यादि' आपको यह समझने की आवश्यकता है कि अंदर लिखने पर लिखने का एक पेचीदा मामला है। बादल को भी ऐसा क्यों नहीं करना चाहिए? मुझे यकीन है कि वे इसे किसी न किसी तरीके से करने की कोशिश कर रहे हैं।

НС: लेकिन एक उदाहरण जुटाने, डॉकर को वहां लाने आदि में अभी भी उन्हें सेकंड, दसियों सेकंड लगेंगे।

डी एस: एक संपूर्ण उदाहरण उठाना क्यों आवश्यक है? हमारे पास 32 कोर, 16... वाला एक उदाहरण है और यह इसमें फिट हो सकता है - उदाहरण के लिए, चार। जब हम पाँचवाँ आदेश देते हैं, तो उदाहरण पहले ही उठाया जाएगा, और फिर इसे हटा दिया जाएगा।

НС: हां, दिलचस्प बात यह है कि कुबेरनेट्स की कहानी अलग है। हमारा डेटाबेस K8s में नहीं है, और हमारे पास एक उदाहरण है। लेकिन मल्टी-टेराबाइट डेटाबेस की क्लोनिंग में दो सेकंड से अधिक समय नहीं लगता है।

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

НС: यह न केवल पोस्टग्रेज़ के लिए उपयुक्त है: ये योजनाएँ, जैसा कि मैंने बताया, केवल इसमें काम करेंगी। लेकिन अगर हम योजनाओं के बारे में चिंता नहीं करते हैं, और हमें केवल कार्यात्मक परीक्षण के लिए सभी डेटा की आवश्यकता है, तो यह किसी भी डीबीएमएस के लिए उपयुक्त है।

डी एस: कई साल पहले हमने एलवीएम स्नैपशॉट पर कुछ ऐसा ही किया था। यह एक क्लासिक है. इस दृष्टिकोण का बहुत सक्रिय रूप से उपयोग किया गया था। स्टेटफुल नोड्स सिर्फ एक दर्द हैं। क्योंकि आपको उन्हें छोड़ना नहीं चाहिए, आपको उन्हें हमेशा याद रखना चाहिए...

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

डी एस: तकनीकी रूप से इसका मतलब है कि कुबेरनेट्स के भीतर यह एक पॉड है जिसके भीतर हम कई पोस्टग्रेज चलाते हैं।

НС: हाँ। उसकी एक सीमा है: मान लीजिए कि एक ही समय में 10 से अधिक लोग उसके साथ काम नहीं करते हैं। यदि आपको 20 की आवश्यकता है, तो हम ऐसा दूसरा पॉड लॉन्च करेंगे। हम इसे पूरी तरह से क्लोन करेंगे, दूसरा पूर्ण वॉल्यूम प्राप्त करने के बाद, इसमें वही 10 "पतले" क्लोन होंगे। क्या आपको यह अवसर नजर नहीं आता?

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

НС: मैं कई टेराबाइट्स के लिए डेढ़ सेकंड में विश्वास नहीं करता। सेफ पर आप इसे स्वयं करते हैं, लेकिन आप बादलों के बारे में बात करते हैं। क्लाउड पर जाएं, EC2 पर मल्टी-टेराबाइट ईबीएस वॉल्यूम का क्लोन बनाएं और देखें कि प्रदर्शन क्या होगा। इसमें कुछ सेकंड नहीं लगेंगे. मुझे इसमें बहुत दिलचस्पी है कि वे इस स्तर पर कब पहुंचेंगे। मैं समझता हूं कि आप क्या कह रहे हैं, लेकिन मैं अलग होना चाहता हूं।

डी एस: ठीक है, लेकिन मैंने मीडियम टर्म में कहा, शॉर्ट टर्म में नहीं। कई वर्षों के लिए।

ज़ालैंडो से PostgreSQL के ऑपरेटर के बारे में

इस बैठक के बीच में, ज़ालैंडो के एक पूर्व डेवलपर एलेक्सी क्लाइयुकिन भी शामिल हुए और उन्होंने PostgreSQL ऑपरेटर के इतिहास के बारे में बात की:

यह बहुत अच्छा है कि इस विषय को सामान्य रूप से छुआ गया है: पोस्टग्रेज़ और कुबेरनेट्स दोनों। जब हमने 2017 में ज़ालैंडो में इसे करना शुरू किया, तो यह एक ऐसा विषय था जिसे हर कोई करना चाहता था, लेकिन किसी ने नहीं किया। सभी के पास पहले से ही कुबेरनेट्स थे, लेकिन जब उन्होंने पूछा कि डेटाबेस के साथ क्या करना है, तो लोगों को भी यह पसंद आया केल्सी हाईटॉवर, जिन्होंने K8s का प्रचार किया, ने कुछ इस तरह कहा:

“प्रबंधित सेवाओं पर जाएं और उनका उपयोग करें, कुबेरनेट्स में डेटाबेस न चलाएं। अन्यथा, आपका K8, ​​उदाहरण के लिए, अपग्रेड करने का निर्णय लेगा, सभी नोड्स को बंद कर देगा, और आपका डेटा बहुत दूर तक उड़ जाएगा।

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

सामान्य तौर पर, कंपनी की ऑटो फेलओवर की आवश्यकता आंतरिक हार्डवेयर डेटा सेंटर से क्लाउड पर स्थानांतरित होने के बाद दिखाई दी। क्लाउड एक मालिकाना PaaS (प्लेटफ़ॉर्म-ए-ए-सर्विस) समाधान पर आधारित था। यह ओपन सोर्स है, लेकिन इसे चालू करने में बहुत मेहनत करनी पड़ी। इसे कहा जाता था मूर्ख.

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

और हमारे पास पहले से ही एक डॉकर कंटेनर था। एक PaaS था जो डॉकर का उपयोग करता था। K8s क्यों न आज़माएँ? अपना खुद का ऑपरेटर क्यों नहीं लिखते? मूरत काबिलोव, जो एविटो से हमारे पास आए थे, ने इसे अपनी पहल पर एक परियोजना के रूप में शुरू किया - "खेलने के लिए" - और परियोजना "शुरू हुई।"

लेकिन सामान्य तौर पर, मैं AWS के बारे में बात करना चाहता था। ऐतिहासिक AWS संबंधित कोड क्यों था...

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

इसलिए, जब हमने स्टेटमेंट दिया, तो हमारे पास पोस्टग्रेज एक बाहरी वॉल्यूम पर चल रहा था (इस मामले में ईबीएस, क्योंकि हम एडब्ल्यूएस पर काम कर रहे थे)। डेटाबेस बढ़ गया, कुछ बिंदु पर इसका आकार बदलना आवश्यक हो गया: उदाहरण के लिए, ईबीएस का प्रारंभिक आकार 100 टीबी था, डेटाबेस बढ़ गया, अब हम ईबीएस 200 टीबी बनाना चाहते हैं। कैसे? मान लीजिए कि आप एक नए इंस्टेंस पर डंप/रिस्टोर कर सकते हैं, लेकिन इसमें लंबा समय लगेगा और इसमें डाउनटाइम भी शामिल होगा।

इसलिए, मैं एक ऐसा आकार बदलना चाहता था जो ईबीएस विभाजन को बड़ा कर दे और फिर फ़ाइल सिस्टम को नए स्थान का उपयोग करने के लिए कहे। और हमने यह किया, लेकिन उस समय कुबेरनेट्स के पास आकार बदलने के ऑपरेशन के लिए कोई एपीआई नहीं थी। चूँकि हमने AWS पर काम किया, इसलिए हमने इसके API के लिए कोड लिखा।

आपको अन्य प्लेटफ़ॉर्म के लिए भी ऐसा करने से कोई नहीं रोक रहा है। कथन में ऐसा कोई संकेत नहीं है कि इसे केवल AWS पर चलाया जा सकता है, और यह बाकी सभी चीज़ों पर काम नहीं करेगा। सामान्य तौर पर, यह एक ओपन सोर्स प्रोजेक्ट है: यदि कोई नए एपीआई के उपयोग के उद्भव में तेजी लाना चाहता है, तो आपका स्वागत है। खाओ GitHub, पुल अनुरोध - ज़ालैंडो टीम उन्हें बहुत तेज़ी से जवाब देने और ऑपरेटर को बढ़ावा देने की कोशिश करती है। जहां तक ​​मुझे पता है, प्रोजेक्ट भाग लिया Google Summer of Code और इसी तरह की कुछ अन्य पहलों पर। ज़ालैंडो इस पर काफी सक्रियता से काम कर रहे हैं.

पुनश्च बोनस!

यदि आप PostgreSQL और Kubernetes के विषय में रुचि रखते हैं, तो कृपया यह भी ध्यान दें कि अगला Postgres मंगलवार पिछले सप्ताह हुआ था, जहाँ मैंने निकोलाई से बात की थी ज़ालैंडो से अलेक्जेंडर कुकुश्किन. इसका वीडियो उपलब्ध है यहां.

पीपीएस

हमारे ब्लॉग पर भी पढ़ें:

• «डेटाबेस और कुबेरनेट्स (समीक्षा और वीडियो रिपोर्ट)";
• «कैसेंड्रा का कुबेरनेट्स में प्रवासन: विशेषताएं और समाधान";
• «MongoDB का कुबेरनेट्स में निर्बाध प्रवासन";
• «RabbitMQ का कुबेरनेट्स में निर्बाध प्रवासन'.

स्रोत: www.habr.com