कठोर उद्यम वातावरण में "मुक्त" PostgreSQL को कैसे फिट करें

बहुत से लोग PostgreSQL DBMS से परिचित हैं, और इसने छोटे इंस्टॉलेशन में खुद को साबित किया है। हालाँकि, जब बड़ी कंपनियों और उद्यम आवश्यकताओं की बात आती है, तब भी ओपन सोर्स की ओर रुझान तेजी से स्पष्ट हो गया है। इस लेख में हम आपको बताएंगे कि पोस्टग्रेज़ को कॉर्पोरेट वातावरण में कैसे एकीकृत किया जाए और उदाहरण के तौर पर कॉमवॉल्ट बैकअप सिस्टम का उपयोग करके इस डेटाबेस के लिए एक बैकअप सिस्टम (बीएसएस) बनाने का अपना अनुभव साझा किया जाए।

PostgreSQL ने पहले ही अपनी उपयोगिता साबित कर दी है - DBMS बढ़िया काम करता है, इसका उपयोग अलीबाबा और ट्रिपएडवाइजर जैसे फैशनेबल डिजिटल व्यवसायों द्वारा किया जाता है, और लाइसेंस शुल्क की कमी इसे MS SQL या Oracle DB जैसे राक्षसों के लिए एक आकर्षक विकल्प बनाती है। लेकिन जैसे ही हम एंटरप्राइज़ परिदृश्य में PostgreSQL के बारे में सोचना शुरू करते हैं, हम तुरंत सख्त आवश्यकताओं में भाग लेते हैं: “कॉन्फ़िगरेशन दोष सहिष्णुता के बारे में क्या? आपदा प्रतिरोध? व्यापक निगरानी कहाँ है? स्वचालित बैकअप के बारे में क्या? सीधे और द्वितीयक भंडारण दोनों पर टेप लाइब्रेरी का उपयोग करने के बारे में क्या?


एक ओर, PostgreSQL में अंतर्निहित बैकअप उपकरण नहीं हैं, जैसे "वयस्क" DBMS जैसे Oracle DB या SAP डेटाबेस बैकअप में RMAN। दूसरी ओर, कॉर्पोरेट बैकअप सिस्टम (वीम, वेरिटास, कॉमवॉल्ट) के आपूर्तिकर्ता हालांकि पोस्टग्रेएसक्यूएल का समर्थन करते हैं, वास्तव में वे केवल एक निश्चित (आमतौर पर स्टैंडअलोन) कॉन्फ़िगरेशन और विभिन्न प्रतिबंधों के एक सेट के साथ काम करते हैं।

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

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

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

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

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

पीछे हटने की कोई जगह नहीं है! मॉस्को डेवलपर्स पीछे हैं!

हालाँकि, हाल ही में हमारी टीम को एक कठिन चुनौती का सामना करना पड़ा: AIS OSAGO 2.0 बनाने की परियोजना में, जहाँ हमने IT बुनियादी ढाँचा बनाया, डेवलपर्स ने नई प्रणाली के लिए PostgreSQL को चुना।

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

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

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

उद्यम के लिए थोड़ा जादू

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

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

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

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

पेट्रोनी प्रत्येक क्लस्टर के लिए एक प्राथमिक नोड परिभाषित करता है। यह डेटा सेंटर में कोई भी मुफ़्त नोड हो सकता है - लेकिन केवल अधिकतर। बैकअप में, सभी नोड सेकेंडरी हैं।

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

सामान्य तौर पर, प्रक्रिया इस तरह दिखती है:

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

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

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

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

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

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

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

वर्तमान में, IBS उत्पादकता सेवाओं को प्रभावित नहीं करता है, लेकिन यदि स्थिति बदलती है, तो कॉमवॉल्ट लोड सीमित करने को सक्षम कर सकता है।

अच्छी है? अच्छा!

इसलिए, हमें PostgreSQL क्लस्टर इंस्टॉलेशन के लिए न केवल एक व्यावहारिक, बल्कि एक पूरी तरह से स्वचालित बैकअप भी प्राप्त हुआ है, और यह एंटरप्राइज़ कॉल के लिए सभी आवश्यकताओं को पूरा करता है।

1 घंटे और 2 घंटे के आरपीओ और आरटीओ पैरामीटर एक मार्जिन के साथ कवर किए गए हैं, जिसका अर्थ है कि सिस्टम संग्रहीत डेटा की मात्रा में उल्लेखनीय वृद्धि के साथ भी उनका अनुपालन करेगा। कई संदेहों के विपरीत, PostgreSQL और एंटरप्राइज़ वातावरण काफी संगत साबित हुए। और अब हम अपने अनुभव से जानते हैं कि ऐसे DBMS के लिए बैकअप विभिन्न प्रकार की कॉन्फ़िगरेशन में संभव है।

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

क्या आपने कॉर्पोरेट परिवेश में PostgreSQL के साथ काम करने का प्रयास किया है?

लेखक:

ओलेग लाव्रेनोव, डेटा स्टोरेज सिस्टम के डिज़ाइन इंजीनियर, जेट इन्फोसिस्टम्स

दिमित्री एरीकिन, जेट इन्फोसिस्टम्स में कंप्यूटर सिस्टम के डिज़ाइन इंजीनियर

स्रोत: www.habr.com