कसरी "नि:शुल्क" PostgreSQL लाई कठोर उद्यम वातावरणमा फिट गर्ने

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

PostgreSQL ले पहिले नै यसको मूल्य प्रमाणित गरिसकेको छ - DBMS ले राम्रो काम गर्दछ, यो अलिबाबा र TripAdvisor जस्ता फैशनेबल डिजिटल व्यवसायहरू द्वारा प्रयोग गरिन्छ, र इजाजतपत्र शुल्कको अभावले यसलाई MS SQL वा Oracle DB जस्ता राक्षसहरूको लागि आकर्षक विकल्प बनाउँछ। तर जब हामी इन्टरप्राइज ल्यान्डस्केपमा PostgreSQL बारे सोच्न थाल्छौं, हामी तुरुन्तै कडा आवश्यकताहरूमा भाग्छौं: "कन्फिगरेसन त्रुटि सहिष्णुताको बारेमा के हो? प्रकोप प्रतिरोध? कहाँ छ व्यापक अनुगमन ? स्वचालित ब्याकअपको बारेमा के हो? सीधा र माध्यमिक भण्डारण दुवै टेप पुस्तकालयहरू प्रयोग गर्ने बारे के हो?"


एकातिर, 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 ले दुई-नोड क्लस्टरसँग मात्र काम गर्न सक्छ, जसमा प्राथमिक र माध्यमिकलाई कडाइका साथ निश्चित नोडहरूमा तोकिएको छ। र यसले प्राइमरीबाट ब्याकअप गर्न मात्रै अर्थ राख्छ, किनभने माध्यमिकबाट ब्याकअपको सीमितताहरू छन्। DBMS को विशेषताहरूको कारण, माध्यमिकमा डम्प सिर्जना गरिएको छैन, र त्यसैले फाइल जगेडाको सम्भावना मात्र रहन्छ।

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

अर्को समस्या पोस्टग्रेसमा ब्याकअपको कार्यान्वयन हो। यो डम्प मार्फत सम्भव छ, र यो साना डेटाबेस मा काम गर्दछ। तर ठूला डाटाबेसहरूमा, डम्पले लामो समय लिन्छ, धेरै स्रोतहरू चाहिन्छ र डाटाबेस उदाहरणको विफलता निम्त्याउन सक्छ।

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

पछाडि हट्ने ठाउँ छैन! मस्को विकासकर्ताहरू पछि छन्!

यद्यपि, भर्खरै हाम्रो टोलीले एउटा कठिन चुनौतीको सामना गर्यो: AIS OSAGO 2.0 सिर्जना गर्ने परियोजनामा, जहाँ हामीले IT पूर्वाधार सिर्जना गरेका थियौं, विकासकर्ताहरूले नयाँ प्रणालीको लागि PostgreSQL रोजे।

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

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

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

उद्यम को लागी एक सानो जादू

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

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

वास्तुकला बारे थप। Commvault व्यवस्थापन सर्भरहरू CommServ HA कन्फिगरेसनमा प्रत्येक दुई डाटा केन्द्रहरूमा स्थापना गरिएको थियो। प्रणाली मिरर गरिएको छ, एक कन्सोल मार्फत व्यवस्थित गरिएको छ र, HA दृष्टिकोणबाट, सबै उद्यम आवश्यकताहरू पूरा गर्दछ।

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

Patroni ले प्रत्येक क्लस्टरको लागि प्राथमिक नोड परिभाषित गर्दछ। यो डाटा केन्द्र मा कुनै पनि नि: शुल्क नोड हुन सक्छ - तर केवल अधिकतर। ब्याकअपमा, सबै नोडहरू माध्यमिक छन्।

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

सामान्यतया, प्रक्रिया यस्तो देखिन्छ:

Patroni ले प्राथमिक चयन गर्छ → Keepalived ले IP क्लस्टर उठाउँछ र स्क्रिप्ट चलाउँछ → चयन गरिएको क्लस्टर नोडमा Commvault एजेन्टले यो प्राथमिक → Commvault छद्म ग्राहक भित्र ब्याकअपलाई स्वचालित रूपमा पुन: कन्फिगर गर्छ भन्ने सूचना प्राप्त गर्दछ।

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

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

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

एकै समयमा, ठूला डाटाबेसहरू धेरै थ्रेडहरूमा ब्लकहरूमा जगेडा हुन्छन्, RPO र ब्याकअप विन्डो आवश्यकताहरू पूरा गर्दछ। प्रणालीमा लोड नगण्य छ: पूर्ण प्रतिलिपिहरू प्रायः हुँदैनन्, अन्य दिनहरूमा मात्र लगहरू सङ्कलन गरिन्छ, र कम लोडको अवधिमा।

वैसे, हामीले PostgreSQL अभिलेख लगहरू ब्याकअप गर्नका लागि छुट्टै नीतिहरू लागू गरेका छौं - तिनीहरू फरक नियमहरू अनुसार भण्डारण गरिएका छन्, फरक तालिका अनुसार प्रतिलिपि गरिएका छन्, र तिनीहरूका लागि डुप्लिकेशन सक्षम गरिएको छैन, किनभने यी लगहरूमा अद्वितीय डेटा हुन्छ।

सम्पूर्ण IT पूर्वाधारमा स्थिरता सुनिश्चित गर्न, प्रत्येक क्लस्टर नोडहरूमा छुट्टै Commvault फाइल क्लाइन्टहरू स्थापना गरिएका छन्। तिनीहरूले ब्याकअपबाट पोस्टग्रेस फाइलहरू बहिष्कार गर्छन् र ओएस र अनुप्रयोग ब्याकअपहरूको लागि मात्र हो। डाटाको यो भागको आफ्नै नीति र भण्डारण अवधि पनि छ।

हाल, IBS ले उत्पादकता सेवाहरूलाई असर गर्दैन, तर यदि स्थिति परिवर्तन भयो भने, Commvault ले लोड सीमित गर्न सक्षम गर्न सक्छ।

के यो राम्रो हो? राम्रो!

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

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

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

के तपाईंले कर्पोरेट वातावरणमा PostgreSQL सँग काम गर्ने प्रयास गर्नुभएको छ?

लेखकहरू:

Oleg Lavrenov, डाटा भण्डारण प्रणाली को डिजाइन ईन्जिनियर, जेट इन्फोसिस्टम्स

दिमित्री एरिकिन, जेट इन्फोसिस्टममा कम्प्युटर प्रणालीको डिजाइन इन्जिनियर

स्रोत: www.habr.com