कठोर एंटरप्राइझ वातावरणात “मुक्त” PostgreSQL कसे बसवायचे

बरेच लोक PostgreSQL DBMS शी परिचित आहेत, आणि त्याने स्वतःला छोट्या प्रतिष्ठापनांमध्ये सिद्ध केले आहे. तथापि, मोठमोठ्या कंपन्या आणि एंटरप्राइझच्या गरजा असतानाही, मुक्त स्त्रोताकडे कल वाढत्या प्रमाणात स्पष्ट झाला आहे. या लेखात आम्‍ही तुम्‍हाला कॉर्पोरेट वातावरणात पोस्‍टग्रेस कसे समाकलित करायचे ते सांगू आणि उदाहरण म्‍हणून Commvault बॅकअप सिस्‍टम वापरून या डेटाबेससाठी बॅकअप सिस्‍टम (BSS) तयार करण्‍याचा आमचा अनुभव सामायिक करू.

PostgreSQL ने आधीच त्याची योग्यता सिद्ध केली आहे - DBMS उत्तम कार्य करते, ते अलीबाबा आणि TripAdvisor सारख्या फॅशनेबल डिजिटल व्यवसायांद्वारे वापरले जाते आणि परवाना शुल्काची कमतरता MS SQL किंवा Oracle DB सारख्या राक्षसांसाठी एक आकर्षक पर्याय बनवते. परंतु एंटरप्राइझ लँडस्केपमध्ये पोस्टग्रेएसक्यूएलबद्दल विचार सुरू करताच, आम्ही त्वरित कठोर आवश्यकता लागू करतो: “कॉन्फिगरेशन फॉल्ट टॉलरन्सचे काय? आपत्ती प्रतिकार? सर्वसमावेशक निरीक्षण कुठे आहे? स्वयंचलित बॅकअपचे काय? टेप लायब्ररी थेट आणि दुय्यम स्टोरेजवर वापरण्याबद्दल काय?


एकीकडे, PostgreSQL मध्ये अंगभूत बॅकअप साधने नाहीत, जसे की "प्रौढ" DBMSs जसे की Oracle DB मधील RMAN किंवा SAP डेटाबेस बॅकअप. दुसरीकडे, कॉर्पोरेट बॅकअप सिस्टीमचे पुरवठादार (Veeam, Veritas, Commvault) जरी ते PostgreSQL ला समर्थन देत असले तरी प्रत्यक्षात ते केवळ एका विशिष्ट (सामान्यतः स्टँडअलोन) कॉन्फिगरेशनसह आणि विविध निर्बंधांच्या संचासह कार्य करतात.

PostgreSQL साठी खास तयार केलेल्या बॅकअप सिस्टम, जसे की Barman, Wal-g, pg_probackup, PostgreSQL DBMS च्या छोट्या इंस्टॉलेशन्समध्ये किंवा IT लँडस्केपच्या इतर घटकांच्या जड बॅकअपची आवश्यकता नसलेल्या ठिकाणी अत्यंत लोकप्रिय आहेत. उदाहरणार्थ, PostgreSQL व्यतिरिक्त, पायाभूत सुविधांमध्ये भौतिक आणि आभासी सर्व्हर, OpenShift, Oracle, MariaDB, Cassandra, इत्यादींचा समावेश असू शकतो. एका सामान्य साधनासह या सर्वांचा बॅकअप घेणे उचित आहे. केवळ PostgreSQL साठी स्वतंत्र सोल्यूशन स्थापित करणे ही एक वाईट कल्पना आहे: डेटा कुठेतरी डिस्कवर कॉपी केला जाईल आणि नंतर तो टेपमध्ये काढला जाणे आवश्यक आहे. हे दुहेरी बॅकअप बॅकअप वेळ वाढवते, आणि अधिक गंभीरपणे, पुनर्प्राप्ती वेळ देखील.

एंटरप्राइझ सोल्यूशनमध्ये, इन्स्टॉलेशनचा बॅकअप समर्पित क्लस्टरमध्ये ठराविक नोड्ससह होतो. त्याच वेळी, उदाहरणार्थ, Commvault केवळ दोन-नोड क्लस्टरसह कार्य करू शकते, ज्यामध्ये प्राथमिक आणि माध्यमिक विशिष्ट नोड्सना काटेकोरपणे नियुक्त केले जातात. आणि फक्त प्राथमिक वरून बॅकअप घेणे अर्थपूर्ण आहे, कारण माध्यमिक पासून बॅकअपला मर्यादा आहेत. डीबीएमएसच्या वैशिष्ट्यांमुळे, दुय्यम वर डंप तयार केला जात नाही आणि म्हणूनच फक्त फाइल बॅकअपची शक्यता राहते.

डाउनटाइमचा धोका कमी करण्यासाठी, दोष-सहिष्णु प्रणाली तयार करताना, "लाइव्ह" क्लस्टर कॉन्फिगरेशन तयार केले जाते आणि प्राथमिक वेगवेगळ्या सर्व्हरमध्ये हळूहळू स्थलांतरित होऊ शकते. उदाहरणार्थ, Patroni सॉफ्टवेअर स्वतः यादृच्छिकपणे निवडलेल्या क्लस्टर नोडवर प्राथमिक लाँच करते. आयबीएसकडे हे बॉक्सच्या बाहेर ट्रॅक करण्याचा कोणताही मार्ग नाही आणि जर कॉन्फिगरेशन बदलले तर प्रक्रिया खंडित होतात. म्हणजेच, बाह्य नियंत्रणाचा परिचय आयएसआरला प्रभावीपणे कार्य करण्यापासून प्रतिबंधित करते, कारण नियंत्रण सर्व्हरला कोठून आणि कोणत्या डेटाची कॉपी करणे आवश्यक आहे हे समजत नाही.

दुसरी समस्या पोस्टग्रेसमध्ये बॅकअपची अंमलबजावणी आहे. हे डंपद्वारे शक्य आहे आणि ते लहान डेटाबेसवर कार्य करते. परंतु मोठ्या डेटाबेसमध्ये, डंपला बराच वेळ लागतो, भरपूर संसाधनांची आवश्यकता असते आणि डेटाबेस उदाहरणाच्या अपयशास कारणीभूत ठरू शकते.

फाइल बॅकअप परिस्थिती दुरुस्त करते, परंतु मोठ्या डेटाबेसवर ते धीमे आहे कारण ते सिंगल-थ्रेडेड मोडमध्ये कार्य करते. याव्यतिरिक्त, विक्रेत्यांवर अनेक अतिरिक्त निर्बंध आहेत. एकतर तुम्ही एकाच वेळी फाईल आणि डंप बॅकअप वापरू शकत नाही, किंवा डीडुप्लिकेशन समर्थित नाही. बर्याच समस्या आहेत आणि बहुतेकदा पोस्टग्रेसऐवजी महाग परंतु सिद्ध डीबीएमएस निवडणे सोपे आहे.

मागे हटायला कुठेच नाही! मॉस्को विकासक मागे आहेत!

तथापि, अलीकडेच आमच्या कार्यसंघाला कठीण आव्हानाचा सामना करावा लागला: AIS OSAGO 2.0 तयार करण्याच्या प्रकल्पात, जिथे आम्ही IT पायाभूत सुविधा तयार केल्या, विकसकांनी नवीन प्रणालीसाठी PostgreSQL निवडले.

मोठ्या सॉफ्टवेअर डेव्हलपरसाठी "ट्रेंडी" ओपन-सोर्स सोल्यूशन्स वापरणे खूप सोपे आहे. या डीबीएमएसच्या ऑपरेशनला समर्थन देण्यासाठी फेसबुककडे पुरेसे विशेषज्ञ आहेत. आणि आरएसएच्या बाबतीत, “दुसऱ्या दिवसाची” सर्व कामे आमच्या खांद्यावर पडली. आम्हाला दोष सहिष्णुता सुनिश्चित करणे, क्लस्टर एकत्र करणे आणि अर्थातच, बॅकअप सेट करणे आवश्यक होते. कृतीचे तर्क खालीलप्रमाणे होते:

• SRK ला क्लस्टरच्या प्राथमिक नोडमधून बॅकअप बनवायला शिकवा. हे करण्यासाठी, SRK ने ते शोधले पाहिजे - याचा अर्थ एक किंवा दुसर्या PostgreSQL क्लस्टर व्यवस्थापन समाधानासह एकत्रीकरण आवश्यक आहे. आरएसएच्या बाबतीत, यासाठी Patroni सॉफ्टवेअर वापरण्यात आले.
• डेटाची मात्रा आणि पुनर्प्राप्ती आवश्यकतांवर आधारित बॅकअपच्या प्रकारावर निर्णय घ्या. उदाहरणार्थ, जेव्हा आपल्याला पृष्ठे दाणेदारपणे पुनर्संचयित करण्याची आवश्यकता असेल तेव्हा डंप वापरा आणि डेटाबेस मोठे असल्यास आणि दाणेदार पुनर्संचयित करणे आवश्यक नसल्यास, फाइल स्तरावर कार्य करा.
• मल्टी-थ्रेडेड मोडमध्ये बॅकअप कॉपी तयार करण्यासाठी सोल्यूशनमध्ये ब्लॉक बॅकअपची शक्यता संलग्न करा.

त्याच वेळी, आम्ही सुरुवातीला अतिरिक्त घटकांच्या राक्षसी हार्नेसशिवाय एक प्रभावी आणि सोपी प्रणाली तयार करण्याचा प्रयत्न केला. कमी क्रॅच, कर्मचाऱ्यांवर कामाचा कमी ताण आणि IBS अपयशाचा धोका कमी. Veeam आणि RMAN वापरणारे पध्दत आम्ही ताबडतोब वगळले, कारण दोन सोल्यूशन्सचा संच आधीच सिस्टमच्या अविश्वसनीयतेकडे इशारा करतो.

एंटरप्राइझसाठी थोडी जादू

त्यामुळे, आम्हाला प्रत्येकी 10 नोड्सच्या 3 क्लस्टरसाठी विश्वसनीय बॅकअपची हमी देणे आवश्यक आहे, त्याच पायाभूत सुविधा बॅकअप डेटा सेंटरमध्ये मिरर केल्या आहेत. PostgreSQL च्या दृष्टीने डेटा केंद्रे सक्रिय-निष्क्रिय तत्त्वावर कार्य करतात. एकूण डेटाबेस आकार 50 TB होता. कोणतीही कॉर्पोरेट-स्तरीय नियंत्रण प्रणाली सहजपणे याचा सामना करू शकते. परंतु सावधानता अशी आहे की सुरुवातीला पोस्टग्रेसला बॅकअप सिस्टमसह पूर्ण आणि खोल सुसंगततेचा सुगावा नाही. म्हणून, आम्हाला पोस्टग्रेएसक्यूएलच्या संयोगाने सुरुवातीला जास्तीत जास्त कार्यक्षमता असलेले समाधान शोधावे लागले आणि सिस्टम परिष्कृत करावे लागेल.

आम्ही 3 अंतर्गत "हॅकॅथॉन" आयोजित केले - आम्ही पन्नासहून अधिक घडामोडी पाहिल्या, त्यांची चाचणी केली, आमच्या गृहितकांच्या संबंधात बदल केले आणि त्यांची पुन्हा चाचणी केली. उपलब्ध पर्यायांचे पुनरावलोकन केल्यानंतर, आम्ही Commvault निवडले. बॉक्सच्या बाहेर, हे उत्पादन सर्वात सोप्या PostgreSQL क्लस्टर इंस्टॉलेशनसह कार्य करू शकते आणि त्याच्या खुल्या आर्किटेक्चरने यशस्वी विकास आणि एकीकरणासाठी आशा निर्माण केल्या (ज्या न्याय्य होत्या). Commvault पोस्टग्रेएसक्यूएल लॉगचा बॅकअप देखील घेऊ शकते. उदाहरणार्थ, PostgreSQL च्या दृष्टीने Veritas NetBackup फक्त पूर्ण बॅकअप बनवू शकतो.

आर्किटेक्चर बद्दल अधिक. CommServ HA कॉन्फिगरेशनमध्ये प्रत्येक दोन डेटा सेंटरमध्ये Commvault व्यवस्थापन सर्व्हर स्थापित केले गेले. प्रणाली मिरर केलेली आहे, एका कन्सोलद्वारे व्यवस्थापित केली जाते आणि HA दृष्टिकोनातून, सर्व एंटरप्राइझ आवश्यकता पूर्ण करते.

आम्ही प्रत्येक डेटा सेंटरमध्ये दोन फिजिकल मीडिया सर्व्हर देखील लाँच केले, ज्यात आम्ही फायबर चॅनेलद्वारे SAN द्वारे बॅकअपसाठी विशेषत: समर्पित डिस्क अॅरे आणि टेप लायब्ररी कनेक्ट केल्या. विस्तारित डुप्लिकेशन डेटाबेसने मीडिया सर्व्हरची दोष सहिष्णुता सुनिश्चित केली आणि प्रत्येक सर्व्हरला प्रत्येक CSV शी कनेक्ट केल्याने कोणताही घटक अयशस्वी झाल्यास सतत ऑपरेशन सक्षम केले. सिस्टम आर्किटेक्चर डेटा केंद्रांपैकी एक पडले तरीही बॅकअप सुरू ठेवण्याची परवानगी देते.

Patroni प्रत्येक क्लस्टरसाठी प्राथमिक नोड परिभाषित करते. हे डेटा सेंटरमधील कोणतेही विनामूल्य नोड असू शकते - परंतु केवळ बहुतेक. बॅकअपमध्ये, सर्व नोड्स दुय्यम आहेत.

कोणता क्लस्टर नोड प्राथमिक आहे हे Commvault ला समजण्यासाठी, आम्ही Postgres सह सिस्टम (सोल्यूशनच्या ओपन आर्किटेक्चरबद्दल धन्यवाद) एकत्रित केले. या उद्देशासाठी, एक स्क्रिप्ट तयार केली गेली जी Commvault व्यवस्थापन सर्व्हरला प्राथमिक नोडच्या वर्तमान स्थानाचा अहवाल देते.

सर्वसाधारणपणे, प्रक्रिया असे दिसते:

Patroni प्राथमिक निवडते → Keepalived आयपी क्लस्टर उचलते आणि स्क्रिप्ट चालवते → निवडलेल्या क्लस्टर नोडवरील Commvault एजंटला एक सूचना प्राप्त होते की हे प्राथमिक → Commvault छद्म-क्लायंटमधील बॅकअप स्वयंचलितपणे पुन्हा कॉन्फिगर करते.

या दृष्टिकोनाचा फायदा असा आहे की समाधान सातत्य, लॉगची शुद्धता किंवा पोस्टग्रेस उदाहरणाच्या पुनर्प्राप्तीवर परिणाम करत नाही. हे सहजपणे स्केलेबल देखील आहे, कारण यापुढे Commvault प्राथमिक आणि माध्यमिक नोड्स निश्चित करणे आवश्यक नाही. हे पुरेसे आहे की सिस्टमला प्राथमिक कोठे आहे हे समजते आणि नोड्सची संख्या जवळजवळ कोणत्याही मूल्यापर्यंत वाढवता येते.

उपाय आदर्श असल्याचे भासवत नाही आणि त्याचे स्वतःचे बारकावे आहेत. Commvault केवळ संपूर्ण घटनांचा बॅकअप घेऊ शकतो, वैयक्तिक डेटाबेस नाही. म्हणून, प्रत्येक डेटाबेससाठी स्वतंत्र उदाहरण तयार केले गेले. वास्तविक क्लायंट व्हर्च्युअल स्यूडो-क्लायंटमध्ये एकत्र केले जातात. प्रत्येक Commvault स्यूडो-क्लायंट एक UNIX क्लस्टर आहे. ते क्लस्टर नोड्स ज्यावर पोस्टग्रेससाठी Commvault एजंट स्थापित केले आहे त्यात जोडले जातात. परिणामी, स्यूडो-क्लायंटच्या सर्व आभासी नोड्सचा एक उदाहरण म्हणून बॅकअप घेतला जातो.

प्रत्येक छद्म-क्लायंटमध्ये, क्लस्टरचा सक्रिय नोड दर्शविला जातो. Commvault साठी आमचे एकत्रीकरण समाधान हेच ​​परिभाषित करते. त्याच्या ऑपरेशनचे तत्त्व अगदी सोपे आहे: जर नोडवर क्लस्टर आयपी वाढविला गेला असेल, तर स्क्रिप्ट Commvault एजंट बायनरीमध्ये "सक्रिय नोड" पॅरामीटर सेट करते - खरं तर, स्क्रिप्ट मेमरीच्या आवश्यक भागात "1" सेट करते. . एजंट हा डेटा CommServe ला पाठवतो आणि Commvault इच्छित नोडमधून बॅकअप घेतो. याव्यतिरिक्त, स्क्रिप्ट स्तरावर कॉन्फिगरेशनची शुद्धता तपासली जाते, बॅकअप सुरू करताना त्रुटी टाळण्यास मदत करते.

त्याच वेळी, मोठ्या डेटाबेसचा बॅकअप अनेक थ्रेड्समध्ये ब्लॉकमध्ये घेतला जातो, RPO आणि बॅकअप विंडो आवश्यकता पूर्ण करतात. सिस्टमवरील भार नगण्य आहे: पूर्ण प्रती इतक्या वेळा येत नाहीत, इतर दिवशी फक्त लॉग गोळा केले जातात आणि कमी लोडच्या काळात.

तसे, आम्ही PostgreSQL संग्रहण लॉगचा बॅकअप घेण्यासाठी स्वतंत्र धोरणे लागू केली आहेत - ते वेगवेगळ्या नियमांनुसार संग्रहित केले जातात, वेगळ्या वेळापत्रकानुसार कॉपी केले जातात आणि त्यांच्यासाठी डुप्लिकेशन सक्षम केलेले नाही, कारण या लॉगमध्ये अद्वितीय डेटा असतो.

संपूर्ण IT इन्फ्रास्ट्रक्चरमध्ये सुसंगतता सुनिश्चित करण्यासाठी, प्रत्येक क्लस्टर नोड्सवर स्वतंत्र Commvault फाइल क्लायंट स्थापित केले जातात. ते पोस्टग्रेस फायली बॅकअपमधून वगळतात आणि फक्त OS आणि ऍप्लिकेशन बॅकअपसाठी आहेत. डेटाच्या या भागाचे स्वतःचे धोरण आणि स्टोरेज कालावधी देखील आहे.

सध्या, IBS उत्पादकता सेवांवर परिणाम करत नाही, परंतु परिस्थिती बदलल्यास, Commvault लोड मर्यादा सक्षम करू शकते.

ते चांगले आहे का? छान!

त्यामुळे, आम्हाला PostgreSQL क्लस्टर इन्स्टॉलेशनसाठी फक्त एक काम करण्यायोग्य नाही, तर पूर्णपणे स्वयंचलित बॅकअप देखील मिळाला आहे आणि तो एंटरप्राइझ कॉल्सच्या सर्व आवश्यकता पूर्ण करतो.

1 तास आणि 2 तासांचे RPO आणि RTO पॅरामीटर्स मार्जिनने कव्हर केले आहेत, याचा अर्थ संग्रहित डेटाच्या व्हॉल्यूममध्ये लक्षणीय वाढ होऊनही सिस्टम त्यांचे पालन करेल. अनेक शंकांच्या विरूद्ध, PostgreSQL आणि एंटरप्राइझ वातावरण अगदी सुसंगत असल्याचे दिसून आले. आणि आता आम्हाला आमच्या स्वतःच्या अनुभवावरून माहित आहे की अशा डीबीएमएसचा बॅकअप विविध प्रकारच्या कॉन्फिगरेशनमध्ये शक्य आहे.

अर्थात, या वाटेवर आम्हाला सात जोड्या लोखंडी बूट घालावे लागले, अनेक अडचणींवर मात करावी लागली, अनेक रेकवर पाऊल टाकावे लागले आणि अनेक चुका दुरुस्त कराव्या लागल्या. परंतु आता या दृष्टिकोनाची चाचणी आधीच केली गेली आहे आणि कठोर एंटरप्राइझ परिस्थितीत मालकी DBMS ऐवजी मुक्त स्त्रोत लागू करण्यासाठी वापरली जाऊ शकते.

तुम्ही कॉर्पोरेट वातावरणात PostgreSQL सह काम करण्याचा प्रयत्न केला आहे का?

लेखक:

ओलेग लव्हरेनोव, डेटा स्टोरेज सिस्टमचे डिझाइन अभियंता, जेट इन्फोसिस्टम्स

दिमित्री एरिकिन, जेट इन्फोसिस्टम्समधील संगणक प्रणालीचे डिझाइन अभियंता

स्त्रोत: www.habr.com