MySQL प्रतिकृति क्यों चुनें?
प्रतिकृति तकनीक के बारे में पहले कुछ मूल बातें। MySQL प्रतिकृति जटिल नहीं है! इसे लागू करना, मॉनिटर करना और ट्यून करना आसान है क्योंकि ऐसे कई संसाधन हैं जिनका आप लाभ उठा सकते हैं - Google एक है। MySQL प्रतिकृति में ट्यून करने के लिए बहुत सारे कॉन्फ़िगरेशन चर नहीं हैं। SQL_THREAD और IO_THREAD की तार्किक त्रुटियों को समझना और ठीक करना इतना कठिन नहीं है। MySQL प्रतिकृति आजकल बहुत लोकप्रिय है और डेटाबेस उच्च उपलब्धता को लागू करने का एक आसान तरीका प्रदान करता है। पुराने जमाने की बाइनरी लॉग पोजीशन के बजाय GTID (ग्लोबल ट्रांजैक्शन आइडेंटिफ़ायर) जैसी शक्तिशाली सुविधाएँ, या दोषरहित सेमी-सिंक्रोनस प्रतिकृति इसे और अधिक मज़बूत बनाती हैं।
जैसा कि हमने पहले की पोस्ट में देखा था, उच्च उपलब्धता समाधान का चयन करते समय नेटवर्क विलंबता एक बड़ी चुनौती है। MySQL प्रतिकृति का उपयोग विलंबता के प्रति संवेदनशील नहीं होने का लाभ प्रदान करता है। यह किसी भी प्रमाणन-आधारित प्रतिकृति को लागू नहीं करता है, इसके विपरीत गैलेरा क्लस्टर समकालिक प्रतिकृति प्राप्त करने के लिए समूह संचार और लेनदेन आदेश तकनीकों का उपयोग करता है। इस प्रकार, इसकी कोई आवश्यकता नहीं है कि सभी नोड्स को एक राइटसेट प्रमाणित करना होगा, और दूसरे दास या प्रतिकृति पर एक प्रतिबद्धता से पहले प्रतीक्षा करने की आवश्यकता नहीं है।
एसिंक्रोनस प्राइमरी-सेकेंडरी दृष्टिकोण के साथ पारंपरिक MySQL प्रतिकृति को चुनना आपको अपने मास्टर के भीतर से लेनदेन को संभालने की गति प्रदान करता है; इसे दासों को सिंक्रोनाइज़ करने या लेन-देन करने के लिए प्रतीक्षा करने की आवश्यकता नहीं है। सेटअप में आमतौर पर एक प्राथमिक (मास्टर) और एक या अधिक सेकेंडरी (दास) होते हैं। इसलिए, यह एक साझा-शून्य प्रणाली है, जहां सभी सर्वरों के पास डिफ़ॉल्ट रूप से डेटा की पूरी प्रतिलिपि होती है। बेशक कमियां हैं। यदि आपके दास SQL और I/O थ्रेड त्रुटियों, या क्रैश के कारण दोहराने में विफल रहे तो डेटा अखंडता एक समस्या हो सकती है। वैकल्पिक रूप से, डेटा अखंडता के मुद्दों को हल करने के लिए, आप MySQL प्रतिकृति को अर्ध-तुल्यकालिक (या MySQL 5.7 में दोषरहित अर्ध-सिंक प्रतिकृति कहा जाता है) को लागू करना चुन सकते हैं। यह कैसे काम करता है, मास्टर को तब तक इंतजार करना पड़ता है जब तक कि प्रतिकृति लेनदेन की सभी घटनाओं को स्वीकार नहीं कर लेती। इसका मतलब यह है कि इसे अपने लेखन को रिले लॉग में समाप्त करना होगा और एसीके प्रतिक्रिया के साथ मास्टर को वापस भेजने से पहले डिस्क पर फ्लश करना होगा। सेमी-सिंक्रोनस प्रतिकृति सक्षम होने के साथ, मास्टर में थ्रेड या सत्र को प्रतिकृति से पावती के लिए प्रतीक्षा करनी पड़ती है। एक बार जब इसे प्रतिकृति से एसीके प्रतिक्रिया मिलती है, तो यह लेनदेन कर सकता है। नीचे दिया गया उदाहरण दिखाता है कि MySQL सेमी-सिंक्रोनस प्रतिकृति को कैसे संभालता है।
MySQL दस्तावेज़ीकरण की छवि सौजन्यइस कार्यान्वयन के साथ, सभी प्रतिबद्ध लेन-देन पहले से ही मास्टर क्रैश के मामले में कम से कम एक दास को दोहराए जाते हैं। हालांकि सेमी-सिंक्रोनस अपने आप में एक उच्च-उपलब्धता समाधान का प्रतिनिधित्व नहीं करता है, लेकिन यह आपके समाधान के लिए एक घटक है। यह सबसे अच्छा है कि आपको अपनी आवश्यकताओं को जानना चाहिए और उसके अनुसार अपने सेमी-सिंक कार्यान्वयन को ट्यून करना चाहिए। इसलिए, यदि कुछ डेटा हानि स्वीकार्य है, तो आप इसके बजाय पारंपरिक अतुल्यकालिक प्रतिकृति का उपयोग कर सकते हैं।
जीटीआईडी-आधारित प्रतिकृति डीबीए के लिए सहायक है क्योंकि यह कार्य को विफल करने के लिए सरल करता है, खासकर जब दास को किसी अन्य मास्टर या नए मास्टर की ओर इशारा किया जाता है। इसका मतलब यह है कि एक साधारण MASTER_AUTO_POSITION=1 सही होस्ट और प्रतिकृति क्रेडेंशियल सेट करने के बाद, यह सही बाइनरी लॉग x &y स्थिति खोजने और निर्दिष्ट करने की आवश्यकता के बिना मास्टर से प्रतिकृति करना शुरू कर देगा। समानांतर प्रतिकृति का समर्थन जोड़ने से प्रतिकृति थ्रेड्स को भी बढ़ावा मिलता है क्योंकि यह रिले लॉग से घटनाओं को संसाधित करने की गति जोड़ता है।
इस प्रकार, यदि यह आपकी आवश्यकताओं के अनुरूप है, तो अन्य HA समाधानों की तुलना में MySQL प्रतिकृति एक बढ़िया विकल्प घटक है।
MySQL प्रतिकृति के लिए टोपोलॉजी
जीसीपी (Google क्लाउड प्लेटफ़ॉर्म) और एडब्ल्यूएस के साथ एक मल्टीक्लाउड वातावरण में MySQL प्रतिकृति को तैनात करना अभी भी वही तरीका है यदि आपको ऑन-प्रिमाइसेस दोहराना है।
विभिन्न टोपोलॉजी हैं जिन्हें आप सेटअप और कार्यान्वित कर सकते हैं।
दास प्रतिकृति के साथ मास्टर (एकल प्रतिकृति)
यह सबसे सरल MySQL प्रतिकृति टोपोलॉजी है। एक मास्टर लिखता है, एक या एक से अधिक दास एक ही मास्टर से अतुल्यकालिक या अर्ध-तुल्यकालिक प्रतिकृति के माध्यम से दोहराते हैं। यदि नामित मास्टर नीचे चला जाता है, तो सबसे अद्यतित दास को नए मास्टर के रूप में पदोन्नत किया जाना चाहिए। शेष दास नए मास्टर से प्रतिकृति फिर से शुरू करते हैं।
रिले स्लेव के साथ मास्टर (श्रृंखला प्रतिकृति)
प्रतिकृति श्रृंखला में अन्य दासों के लिए रिले के रूप में कार्य करने के लिए यह सेटअप एक मध्यवर्ती मास्टर का उपयोग करता है। जब एक मास्टर से कई दास जुड़े होते हैं, तो मास्टर का नेटवर्क इंटरफ़ेस अतिभारित हो सकता है। यह टोपोलॉजी रीड प्रतिकृतियों को मास्टर सर्वर को ऑफलोड करने के लिए रिले सर्वर से प्रतिकृति स्ट्रीम खींचने की अनुमति देती है। स्लेव रिले सर्वर पर, बाइनरी लॉगिंग और log_slave_updates को सक्षम किया जाना चाहिए, जिससे मास्टर सर्वर से स्लेव सर्वर द्वारा प्राप्त अपडेट को स्लेव के स्वयं के बाइनरी लॉग में लॉग किया जाता है।
स्लेव रिले का उपयोग करने की अपनी समस्याएं हैं:
- log_slave_updates में कुछ प्रदर्शन दंड हैं।
- स्लेव रिले सर्वर पर प्रतिकृति अंतराल इसके सभी दासों पर विलंब उत्पन्न करेगा।
- स्लेव रिले सर्वर पर नकली लेन-देन उसके सभी दासों को संक्रमित कर देगा।
- यदि कोई स्लेव रिले सर्वर विफल हो जाता है और आप GTID का उपयोग नहीं कर रहे हैं, तो उसके सभी स्लेव प्रतिकृति बनाना बंद कर देते हैं और उन्हें पुन:प्रारंभ करने की आवश्यकता होती है।
सक्रिय मास्टर के साथ मास्टर (सर्कुलर प्रतिकृति)
रिंग टोपोलॉजी के रूप में भी जाना जाता है, इस सेटअप के लिए दो या अधिक MySQL सर्वर की आवश्यकता होती है जो मास्टर के रूप में कार्य करते हैं। सभी मास्टर कुछ चेतावनियों के साथ लेखन प्राप्त करते हैं और बिनलॉग उत्पन्न करते हैं:
- प्राथमिक कुंजी टकराव से बचने के लिए आपको प्रत्येक सर्वर पर ऑटो-इन्क्रीमेंट ऑफ़सेट सेट करना होगा।
- कोई विरोध समाधान नहीं है।
- MySQL प्रतिकृति वर्तमान में दो अलग-अलग सर्वरों में वितरित अद्यतन की परमाणुता की गारंटी के लिए मास्टर और दास के बीच किसी भी लॉकिंग प्रोटोकॉल का समर्थन नहीं करता है।
- सामान्य अभ्यास केवल एक मास्टर को लिखना है और दूसरा मास्टर हॉट-स्टैंडबाय नोड के रूप में कार्य करता है। फिर भी, यदि आपके पास उस स्तर के नीचे दास हैं, तो निर्दिष्ट मास्टर विफल होने पर आपको मैन्युअल रूप से नए मास्टर पर स्विच करना होगा।
- ClusterControl इस टोपोलॉजी का समर्थन करता है (हम प्रतिकृति सेटअप में एकाधिक लेखकों की अनुशंसा नहीं करते हैं)। ClusterControl के साथ परिनियोजित करने के तरीके पर यह पिछला ब्लॉग देखें।
बैकअप मास्टर के साथ मास्टर (एकाधिक प्रतिकृति)
मास्टर एक बैकअप मास्टर और एक या अधिक दासों में परिवर्तन को धक्का देता है। मास्टर और बैकअप मास्टर के बीच सेमी-सिंक्रोनस प्रतिकृति का उपयोग किया जाता है। मास्टर बैकअप मास्टर को अपडेट भेजता है और ट्रांजेक्शन कमिट के साथ प्रतीक्षा करता है। बैकअप मास्टर अपडेट प्राप्त करता है, अपने रिले लॉग को लिखता है और डिस्क पर फ्लश करता है। बैकअप मास्टर तब मास्टर को लेन-देन की प्राप्ति को स्वीकार करता है, और लेन-देन प्रतिबद्ध के साथ आगे बढ़ता है। सेमी-सिंक प्रतिकृति का प्रदर्शन प्रभाव पड़ता है, लेकिन डेटा हानि का जोखिम कम से कम होता है।
मास्टर के नीचे जाने की स्थिति में मास्टर फेलओवर करते समय यह टोपोलॉजी अच्छी तरह से काम करती है। बैकअप मास्टर वार्म-स्टैंडबाय सर्वर के रूप में कार्य करता है क्योंकि इसमें अन्य दासों की तुलना में अप-टू-डेट डेटा होने की उच्चतम संभावना होती है।
एकल दास के लिए एकाधिक मास्टर्स (मल्टी-सोर्स प्रतिकृति)
बहु-स्रोत प्रतिकृति प्रतिकृति दास को एक साथ कई स्रोतों से लेनदेन प्राप्त करने में सक्षम बनाती है। मल्टी-सोर्स प्रतिकृति का उपयोग कई सर्वरों को एक सर्वर पर बैकअप करने के लिए किया जा सकता है, टेबल शार्ड्स को मर्ज करने के लिए, और एकाधिक सर्वर से डेटा को एक सर्वर में समेकित करने के लिए।
MySQL और MariaDB में बहु-स्रोत प्रतिकृति के अलग-अलग कार्यान्वयन हैं, जहां MariaDB के पास GTID होना चाहिए जिसमें gtid-domain-id को मूल लेनदेन को अलग करने के लिए कॉन्फ़िगर किया गया हो, जबकि MySQL प्रत्येक मास्टर के लिए एक अलग प्रतिकृति चैनल का उपयोग करता है जिससे दास प्रतिकृति करता है। MySQL में, एक बहु-स्रोत प्रतिकृति टोपोलॉजी में मास्टर्स को वैश्विक लेनदेन पहचानकर्ता (GTID) आधारित प्रतिकृति, या बाइनरी लॉग स्थिति-आधारित प्रतिकृति का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है।
इस ब्लॉग पोस्ट में मारियाडीबी बहु स्रोत प्रतिकृति पर अधिक पाया जा सकता है। MySQL के लिए, कृपया MySQL दस्तावेज़ देखें।
गैलेरा विद रेप्लिकेशन स्लेव (हाइब्रिड रेप्लिकेशन)
हाइब्रिड प्रतिकृति MySQL अतुल्यकालिक प्रतिकृति और गैलेरा द्वारा प्रदान की गई वस्तुतः तुल्यकालिक प्रतिकृति का एक संयोजन है। MySQL प्रतिकृति में GTID के कार्यान्वयन के साथ अब परिनियोजन को सरल बनाया गया है, जहाँ मास्टर फ़ेलओवर की स्थापना और प्रदर्शन करना दास पक्ष पर एक सीधी प्रक्रिया बन गई है।
गैलेरा क्लस्टर का प्रदर्शन सबसे धीमे नोड जितना तेज़ है। एसिंक्रोनस प्रतिकृति दास होने से क्लस्टर पर प्रभाव कम हो सकता है यदि आप दास को लंबे समय से चलने वाली रिपोर्टिंग/ओएलएपी प्रकार के प्रश्न भेजते हैं, या यदि आप भारी काम करते हैं जिसके लिए mysqldump जैसे ताले की आवश्यकता होती है। स्लेव ऑनसाइट और ऑफसाइट डिजास्टर रिकवरी के लिए लाइव बैकअप के रूप में भी काम कर सकता है।
हाइब्रिड प्रतिकृति ClusterControl द्वारा समर्थित है और आप इसे सीधे ClusterControl UI से परिनियोजित कर सकते हैं। इसे कैसे करें, इस बारे में अधिक जानकारी के लिए, कृपया ब्लॉग पोस्ट पढ़ें - MySQL 5.6 के साथ हाइब्रिड प्रतिकृति और मारियाडीबी 10.x के साथ हाइब्रिड प्रतिकृति।
GCP और AWS प्लेटफ़ॉर्म तैयार करना
"वास्तविक दुनिया" की समस्या
इस ब्लॉग में, हम "एकाधिक प्रतिकृति" टोपोलॉजी का प्रदर्शन और उपयोग करेंगे जिसमें दो अलग-अलग सार्वजनिक क्लाउड प्लेटफॉर्म पर अलग-अलग क्षेत्रों और विभिन्न उपलब्धता क्षेत्रों पर MySQL प्रतिकृति का उपयोग करके संचार करेंगे। यह परिदृश्य एक वास्तविक दुनिया की समस्या पर आधारित है जहां एक संगठन स्केलेबिलिटी, रिडंडेंसी, लचीलापन / दोष-सहिष्णुता के लिए कई क्लाउड प्लेटफॉर्म पर अपने बुनियादी ढांचे को तैयार करना चाहता है। इसी तरह की अवधारणाएं MongoDB या PostgreSQL के लिए लागू होंगी।
आइए एक अमेरिकी संगठन पर विचार करें, जिसकी दक्षिण पूर्व एशिया में एक विदेशी शाखा है। हमारा यातायात एशियाई-आधारित क्षेत्र में अधिक है। लिखने और पढ़ने के लिए लेटेंसी कम होनी चाहिए, लेकिन साथ ही यूएस-आधारित क्षेत्र एशियाई-आधारित ट्रैफ़िक से आने वाले रिकॉर्ड को भी खींच सकता है।
क्लाउड आर्किटेक्चर फ्लो
इस खंड में, मैं वास्तुशिल्प डिजाइन पर चर्चा करूंगा। सबसे पहले, हम एक अत्यधिक सुरक्षित परत की पेशकश करना चाहते हैं जिसके लिए हमारे Google कंप्यूट और एडब्ल्यूएस ईसी 2 नोड्स इंटरनेट से पैकेजों को संचार, अद्यतन या स्थापित कर सकते हैं, सुरक्षित, अत्यधिक उपलब्ध यदि कोई एजेड (उपलब्धता क्षेत्र) नीचे जाता है, दोहरा सकता है और एक सुरक्षित परत पर दूसरे क्लाउड प्लेटफॉर्म से संचार करें। उदाहरण के लिए नीचे दिया गया चित्र देखें:
उपरोक्त उदाहरण के आधार पर, एडब्ल्यूएस प्लेटफॉर्म के तहत, सभी नोड विभिन्न उपलब्धता क्षेत्रों पर चल रहे हैं। इसमें एक निजी और सार्वजनिक सबनेट है जिसके लिए सभी कंप्यूट नोड्स एक निजी सबनेट पर हैं। इसलिए, यह जरूरत पड़ने पर अपने सिस्टम पैकेज को खींचने और अपडेट करने के लिए इंटरनेट से बाहर जा सकता है। इसमें एक वीपीएन गेटवे है जिसके लिए उसे इंटरनेट को दरकिनार करते हुए एक सुरक्षित और निजी चैनल के माध्यम से उस चैनल में जीसीपी के साथ बातचीत करनी होती है। जीसीपी के समान, सभी कंप्यूट नोड्स अलग-अलग उपलब्धता क्षेत्रों पर हैं, जरूरत पड़ने पर सिस्टम पैकेज को अपडेट करने के लिए एनएटी गेटवे का उपयोग करते हैं और एडब्ल्यूएस नोड्स के साथ बातचीत करने के लिए वीपीएन कनेक्शन का उपयोग करते हैं जो एक अलग क्षेत्र, यानी एशिया पैसिफिक (सिंगापुर) पर होस्ट किए जाते हैं। दूसरी ओर, यूएस-आधारित क्षेत्र को us-east1 के अंतर्गत होस्ट किया जाता है। नोड्स तक पहुँचने के लिए, आर्किटेक्चर में एक नोड बुर्ज-नोड के रूप में कार्य करता है जिसके लिए हम इसे जम्प होस्ट के रूप में उपयोग करेंगे और ClusterControl स्थापित करेंगे। इस ब्लॉग में बाद में इसका समाधान किया जाएगा।
GCP और AWS परिवेश सेट करना
आपका पहला GCP खाता पंजीकृत करते समय, Google एक डिफ़ॉल्ट VPC (वर्चुअल प्राइवेट क्लाउड) खाता प्रदान करता है। इसलिए, डिफ़ॉल्ट से अलग VPC बनाना और अपनी आवश्यकताओं के अनुसार इसे अनुकूलित करना सबसे अच्छा है।
हमारा लक्ष्य यहां कंप्यूट नोड्स को निजी सबनेट में रखना है या नोड्स को सार्वजनिक IPv4 के साथ सेटअप नहीं किया जाएगा। इसलिए, दोनों सार्वजनिक बादलों को एक दूसरे से बात करने में सक्षम होना चाहिए। एडब्ल्यूएस और जीसीपी कंप्यूट नोड्स पहले बताए गए विभिन्न सीआईडीआर के साथ काम करते हैं। इसलिए, यहाँ निम्नलिखित CIDR हैं:
AWS कंप्यूट नोड्स: 172.21.0.0/16
जीसीपी कंप्यूट नोड्स: 10.142.0.0/20
इस एडब्ल्यूएस सेटअप में, हमने तीन सबनेट आवंटित किए जिनमें कोई इंटरनेट गेटवे नहीं बल्कि एनएटी गेटवे है; और एक सबनेट जिसमें एक इंटरनेट गेटवे है। इनमें से प्रत्येक सबनेट अलग-अलग उपलब्धता क्षेत्रों (AZ) में अलग-अलग होस्ट किए जाते हैं।
ap-southeast-1a =172.21.1.0/24
ap-southeast-1b =172.21.8.0/24
ap-southeast-1c =172.21.24.0/24
GCP में, us-east1 के अंतर्गत VPC में बनाया गया डिफ़ॉल्ट सबनेट जो 10.142.0.0/20 CIDR है, का उपयोग किया जाता है। इसलिए, आप अपने बहु-सार्वजनिक क्लाउड प्लेटफ़ॉर्म को सेटअप करने के लिए इन चरणों का पालन कर सकते हैं।
-
इस अभ्यास के लिए, मैंने 10.142.0.0/20 के निम्नलिखित सबनेट के साथ us-east1 क्षेत्र में एक VPC बनाया। नीचे देखें:
-
एक स्टेटिक आईपी रिजर्व करें। यह वह आईपी है जिसे हम एडब्ल्यूएस में ग्राहक गेटवे के रूप में स्थापित करेंगे
-
चूंकि हमारे पास सबनेट हैं (सबनेट-us-east1 के रूप में प्रावधानित) ), जीसीपी -> वीपीसी नेटवर्क -> वीपीसी नेटवर्क . पर जाएं और अपने द्वारा बनाए गए VPC का चयन करें और फ़ायरवॉल नियम . पर जाएं . इस खंड में, अपना प्रवेश और निकास निर्दिष्ट करके नियम जोड़ें। मूल रूप से, ये आने वाले और बाहर जाने वाले कनेक्शन के लिए AWS या आपके फ़ायरवॉल में इनबाउंड / आउटबाउंड नियम हैं। इस सेटअप में, मैंने इस ब्लॉग के उद्देश्य के लिए इसे आसान बनाने के लिए अपने AWS और GCP VPC में सेट CIDR रेंज से सभी TCP प्रोटोकॉल खोले। इसलिए, यह सुरक्षा के लिए सबसे अच्छा तरीका नहीं है। नीचे दी गई छवि देखें:
यहां फ़ायरवॉल-ssh का उपयोग ssh, HTTP और HTTPS आने वाले कनेक्शनों को अनुमति देने के लिए किया जाएगा।
-
अब AWS पर स्विच करें और VPC बनाएं। इस ब्लॉग के लिए, मैंने CIDR (क्लासलेस इंटर-डोमेन रूटिंग) 172.21.0.0/16
का इस्तेमाल किया -
सबनेट बनाएं जिसके लिए आपको उन्हें प्रत्येक AZ (उपलब्धता क्षेत्र) में असाइन करना होगा; और सार्वजनिक सबनेट के लिए कम से कम एक सबनेट आरक्षित करें जो NAT गेटवे को संभालेगा, और बाकी EC2 नोड्स के लिए हैं।
-
इसके बाद, अपनी रूट टेबल बनाएं और सुनिश्चित करें कि "गंतव्य" और "लक्ष्य" सही ढंग से सेट हैं। इस ब्लॉग के लिए, मैंने 2 रूट टेबल बनाए हैं। एक जो 3 AZ को संभालेगा जिसे मेरे कंप्यूट नोड्स को व्यक्तिगत रूप से सौंपा जाएगा और बिना इंटरनेट गेटवे के असाइन किया जाएगा क्योंकि इसमें कोई सार्वजनिक आईपी नहीं होगा। फिर दूसरा NAT गेटवे को हैंडल करेगा और उसके पास एक इंटरनेट गेटवे होगा जो पब्लिक सबनेट में होगा। नीचे दी गई छवि देखें:
और जैसा कि उल्लेख किया गया है, निजी मार्ग के लिए मेरा उदाहरण गंतव्य जो 3 सबनेट को संभालता है, एक NAT गेटवे लक्ष्य और एक वर्चुअल गेटवे लक्ष्य दिखाता है जिसका मैं बाद में आने वाले चरणों में उल्लेख करूंगा।
-
इसके बाद, एक "इंटरनेट गेटवे" बनाएं और इसे VPC को असाइन करें जो पहले AWS VPC सेक्शन में बनाया गया था। यह इंटरनेट गेटवे केवल सार्वजनिक सबनेट के लिए गंतव्य के रूप में सेट किया जाएगा क्योंकि यह वह सेवा होगी जिसे इंटरनेट से कनेक्ट करना होगा। जाहिर है, नाम एक इंटरनेट गेटवे सेवा के रूप में है।
-
इसके बाद, "NAT गेटवे" बनाएं। "NAT गेटवे" बनाते समय, सुनिश्चित करें कि आपने अपना NAT सार्वजनिक-सामना करने वाले सबनेट को असाइन किया है। NAT गेटवे आपके निजी सबनेट या EC2 नोड्स से इंटरनेट एक्सेस करने के लिए आपका चैनल है, जिसमें कोई सार्वजनिक IPv4 असाइन नहीं किया गया है। फिर एक ईआईपी (इलास्टिक आईपी) बनाएं या असाइन करें, क्योंकि एडब्ल्यूएस में, केवल उन नोड्स की गणना करें जिनके पास सार्वजनिक आईपीवी 4 असाइन किया गया है जो सीधे इंटरनेट से जुड़ सकते हैं।
-
अब, VPC -> सुरक्षा -> सुरक्षा समूह (SG) . के अंतर्गत , आपके बनाए गए VPC में एक डिफ़ॉल्ट SG होगा। इस सेटअप के लिए, मैंने प्रत्येक सीआईडीआर यानी जीसीपी में 10.142.0.0/20 और एडब्ल्यूएस में 172.21.0.0/16 के लिए निर्दिष्ट स्रोतों के साथ "इनबाउंड नियम" बनाए। नीचे देखें:
"आउटबाउंड नियम" के लिए, आप इसे छोड़ सकते हैं क्योंकि "इनबाउंड नियम" के लिए नियम निर्दिष्ट करना द्विपक्षीय है, जिसका अर्थ है कि यह "आउटबाउंड नियम" के लिए भी खुल जाएगा। ध्यान दें कि यह आपके सुरक्षा समूह को स्थापित करने का सबसे अच्छा तरीका नहीं है; लेकिन इस सेटअप के लिए इसे आसान बनाने के लिए, मैंने पोर्ट रेंज और स्रोत का भी व्यापक दायरा बनाया है। यह भी कि प्रोटोकॉल केवल TCP कनेक्शन के लिए विशिष्ट हैं क्योंकि हम इस ब्लॉग के लिए UDP के साथ काम नहीं करेंगे।
इसके अतिरिक्त, आप अपने VPC -> सुरक्षा -> नेटवर्क ACL जब तक यह आपके स्रोत में बताए गए CIDR से किसी भी tcp कनेक्शन को अस्वीकार नहीं करता है, तब तक इसे छुआ नहीं गया है। -
इसके बाद, हम वीपीएन कॉन्फ़िगरेशन को सेटअप करेंगे जिसे एडब्ल्यूएस प्लेटफॉर्म के तहत होस्ट किया जाएगा। VPC -> ग्राहक गेटवे . के अंतर्गत , पिछले चरण में पहले बनाए गए स्थिर IP पते का उपयोग करके गेटवे बनाएं। नीचे दी गई छवि पर एक नज़र डालें:
-
इसके बाद, एक वर्चुअल प्राइवेट गेटवे बनाएं और इसे वर्तमान VPC के साथ संलग्न करें जिसे हमने पिछले चरण में पहले बनाया था। नीचे दी गई छवि देखें:
-
अब, एक वीपीएन कनेक्शन बनाएं जिसका उपयोग एडब्ल्यूएस और जीसीपी के बीच साइट-टू-साइट कनेक्शन के लिए किया जाएगा। वीपीएन कनेक्शन बनाते समय, सुनिश्चित करें कि आपने सही वर्चुअल प्राइवेट गेटवे और कस्टमर गेटवे का चयन किया है जिसे हमने पिछले चरणों में बनाया था। नीचे दी गई छवि देखें:
AWS द्वारा आपका VPN कनेक्शन बनाते समय इसमें कुछ समय लग सकता है। जब आपके वीपीएन कनेक्शन का प्रावधान किया जाता है, तो आपको आश्चर्य हो सकता है कि टनल टैब के तहत (अपना वीपीएन कनेक्शन चुनने के बाद), यह दिखाएगा कि आईपी एड्रेस के बाहर खराब है। यह सामान्य है क्योंकि क्लाइंट से अभी तक कोई कनेक्शन स्थापित नहीं हुआ है। नीचे दी गई उदाहरण छवि पर एक नज़र डालें:
एक बार वीपीएन कनेक्शन तैयार हो जाने के बाद, अपने बनाए गए वीपीएन कनेक्शन का चयन करें और कॉन्फ़िगरेशन डाउनलोड करें। इसमें क्लाइंट के साथ साइट-टू-साइट VPN कनेक्शन बनाने के लिए निम्नलिखित चरणों के लिए आवश्यक आपके क्रेडेंशियल शामिल हैं।
नोट: यदि आपने अपना वीपीएन सेटअप किया है जहां IPSEC IS UP . है लेकिन स्थिति है नीचे बिल्कुल नीचे दी गई छवि की तरह
यह आपके बीजीपी सत्र या क्लाउड राउटर को सेट करते समय विशिष्ट मापदंडों पर गलत मूल्यों के कारण होने की संभावना है। अपने वीपीएन के समस्या निवारण के लिए इसे यहां देखें।
-
चूंकि हमारे पास एडब्ल्यूएस में एक वीपीएन कनेक्शन तैयार है, इसलिए जीसीपी में वीपीएन कनेक्शन बनाएं। अब, जीसीपी पर वापस चलते हैं और वहां क्लाइंट कनेक्शन सेटअप करते हैं। GCP में, GCP -> हाइब्रिड कनेक्टिविटी -> VPN . पर जाएं . सुनिश्चित करें कि आप सही क्षेत्र चुन रहे हैं, जो इस ब्लॉग पर है, हम us-east1 का उपयोग कर रहे हैं . फिर पिछले चरणों में बनाए गए स्थिर आईपी पते का चयन करें। नीचे दी गई छवि देखें:
फिर सुरंगों . में अनुभाग, यह वह जगह है जहां आपको पहले बनाए गए एडब्ल्यूएस वीपीएन कनेक्शन से डाउनलोड किए गए क्रेडेंशियल्स के आधार पर सेटअप करना होगा। मेरा सुझाव है कि Google की इस सहायक मार्गदर्शिका को देखें। उदाहरण के लिए, सेटअप की जा रही सुरंगों में से एक को नीचे दी गई छवि में दिखाया गया है:
मूल रूप से, यहां सबसे महत्वपूर्ण चीजें निम्नलिखित हैं:
- रिमोट पीयर गेटवे:आईपी एड्रेस - यह वीपीएन सर्वर का आईपी है जिसे सुरंग विवरण -> बाहरी आईपी एड्रेस के तहत बताया गया है। . यह हमारे द्वारा जीसीपी के तहत बनाए गए स्थिर आईपी से भ्रमित नहीं होना है। वह है क्लाउड वीपीएन गेटवे -> आईपी एड्रेस हालांकि।
- क्लाउड राउटर ASN - डिफ़ॉल्ट रूप से, AWS 65000 का उपयोग करता है। लेकिन संभव है, आपको यह जानकारी डाउनलोड की गई कॉन्फ़िगरेशन फ़ाइल से मिल जाएगी।
- पीयर राउटर ASN - यह वर्चुअल प्राइवेट गेटवे ASN है जो डाउनलोड की गई कॉन्फ़िगरेशन फ़ाइल में पाया जाता है।
- क्लाउड राउटर बीजीपी आईपी एड्रेस - यह ग्राहक गेटवे . है डाउनलोड की गई कॉन्फ़िगरेशन फ़ाइल में पाया गया।
- बीजीपी पीयर आईपी एड्रेस - यह वर्चुअल प्राइवेट गेटवे . है डाउनलोड की गई कॉन्फ़िगरेशन फ़ाइल में पाया गया।
-
मेरे पास नीचे दी गई उदाहरण कॉन्फ़िगरेशन फ़ाइल पर एक नज़र डालें:
जिसके लिए आपको GCP -> Hybrid Connectivity -> VPN के तहत अपना टनल जोड़ने के दौरान इसका मिलान करना होगा। कनेक्टिविटी सेटअप। नमूना सुरंग बनाने के दौरान नीचे दी गई छवि देखें जिसके लिए मैंने क्लाउड राउटर और बीजीपी सत्र बनाया:
फिर बीजीपी सत्र के रूप में,
नोट: डाउनलोड की गई कॉन्फ़िगरेशन फ़ाइल में IPSec कॉन्फ़िगरेशन टनल है, जिसके लिए AWS में आपके कनेक्शन के लिए दो (2) VPN सर्वर तैयार हैं। आपको उन दोनों को सेटअप करना होगा ताकि आपके पास एक उच्च उपलब्ध सेटअप हो। एक बार दोनों सुरंगों के लिए इसका सेटअप सही हो जाने पर, सुरंग टैब के अंतर्गत AWS VPN कनेक्शन दिखाएगा कि दोनों आईपी पते के बाहर ऊपर हैं। नीचे दी गई छवि देखें:
-
अंत में, चूंकि हमने एक इंटरनेट गेटवे और NAT गेटवे बनाया है, इसलिए सार्वजनिक और निजी सबनेट को सही गंतव्य के साथ सही ढंग से भरें और लक्ष्य जैसा कि पिछले चरणों के स्क्रीनशॉट में देखा गया है। इसे सेवाएं -> नेटवर्किंग और सामग्री वितरण -> VPC -> रूट तालिकाएं पर जाकर सेटअप किया जा सकता है और पिछले चरणों से उल्लिखित मार्ग तालिका का चयन करें। नीचे दी गई छवि देखें:
जैसा कि आपने देखा, igw-01faa6d83da5df964 इंटरनेट गेटवे है जिसे हमने बनाया और सार्वजनिक मार्ग द्वारा उपयोग किया जाता है। जबकि, निजी मार्ग तालिका में गंतव्य और लक्ष्य nat-07eb7a54e90dab61f पर सेट हैं और इन दोनों के पास गंतव्य है 0.0.0.0/0 पर सेट करें क्योंकि यह विभिन्न IPv4 कनेक्शनों से अनुमति देगा। साथ ही रूट प्रचार . सेट करना न भूलें वर्चुअल गेटवे के लिए सही ढंग से जैसा कि स्क्रीनशॉट में देखा गया है जिसका लक्ष्य vgw-0238040a5fd061515 है . बस रूट प्रोपेगेशन पर क्लिक करें और इसे नीचे स्क्रीनशॉट की तरह ही हाँ पर सेट करें:
यह बहुत महत्वपूर्ण है ताकि बाहरी GCP कनेक्शन से कनेक्शन AWS में रूट टेबल पर रूट हो जाए और आगे किसी मैनुअल काम की आवश्यकता न हो। अन्यथा, आपका GCP AWS से कनेक्शन स्थापित नहीं कर सकता।
अब जबकि हमारा वीपीएन तैयार हो गया है, हम बुर्जियन होस्ट सहित अपने निजी नोड्स सेट करना जारी रखेंगे।
कंप्यूट इंजन नोड्स सेट करना
कंप्यूट इंजन/ईसी2 नोड्स की स्थापना तेज और आसान होगी क्योंकि हमारे पास सभी सेटअप हैं। मैं उस विवरण में नहीं जाऊंगा, लेकिन नीचे स्क्रीनशॉट देखूंगा क्योंकि यह सेटअप की व्याख्या करता है।
AWS EC2 नोड्स :
GCP कंप्यूट नोड्स :
मूल रूप से, इस सेटअप पर। होस्ट क्लस्टरकंट्रोल गढ़ या कूद मेजबान होगा और जिसके लिए ClusterControl स्थापित किया जाएगा। जाहिर है, यहां सभी नोड्स इंटरनेट तक पहुंच योग्य नहीं हैं। उन्हें कोई बाहरी IPv4 असाइन नहीं किया गया है और नोड वीपीएन का उपयोग करके एक बहुत ही सुरक्षित चैनल के माध्यम से संचार कर रहे हैं।
अंत में, एडब्ल्यूएस से जीसीपी तक इन सभी नोड्स को एक समान सिस्टम उपयोगकर्ता के साथ सुडो एक्सेस के साथ सेटअप किया गया है, जिसकी हमारे अगले भाग में आवश्यकता है। देखें कि कैसे ClusterControl बहु-क्लाउड और बहु-क्षेत्र में आपके जीवन को आसान बना सकता है।
बचाव के लिए क्लस्टर नियंत्रण!!!
एकाधिक नोड्स और विभिन्न सार्वजनिक क्लाउड प्लेटफ़ॉर्म पर, साथ ही एक अलग "क्षेत्र" को संभालना एक "वास्तव में दर्दनाक और चुनौतीपूर्ण" कार्य हो सकता है। आप इसे प्रभावी ढंग से कैसे मॉनिटर करते हैं? ClusterControl न केवल आपके स्विस-चाकू के रूप में, बल्कि आपके वर्चुअल DBA के रूप में भी कार्य करता है। अब, देखते हैं कि कैसे ClusterControl आपके जीवन को आसान बना सकता है।
ClusterControl का उपयोग करके एक बहु-प्रतिकृति क्लस्टर बनाना
आइए अब "एकाधिक प्रतिकृति" टोपोलॉजी का अनुसरण करते हुए एक मारियाडीबी मास्टर-स्लेव प्रतिकृति क्लस्टर बनाने का प्रयास करें।
ClusterControl डिप्लॉय विजार्डहिट करना तैनाती बटन संकुल को संस्थापित करेगा और तदनुसार नोड्स को सेटअप करेगा। इसलिए, टोपोलॉजी कैसा दिखेगा इसका एक तार्किक दृष्टिकोण:
ClusterControl - टोपोलॉजी व्यूनोड्स 172.21.0.0/16 रेंज आईपी के जीसीपी पर चल रहे इसके मास्टर से नकल कर रहे हैं।
अब, हम मास्टर पर कुछ राइट्स लोड करने का प्रयास कैसे करेंगे? कनेक्टिविटी या विलंबता के साथ कोई भी समस्या स्लेव लैग उत्पन्न कर सकती है, आप इसे ClusterControl के साथ देख पाएंगे। नीचे स्क्रीनशॉट देखें:
और जैसा कि आप स्क्रीनशॉट के ऊपरी-दाएं कोने में देखते हैं, यह लाल हो जाता है क्योंकि यह इंगित करता है कि समस्याओं का पता चला था। इसलिए, इस समस्या का पता चलने पर अलार्म भेजा जा रहा था। नीचे देखें:
हमें इसमें खुदाई करने की जरूरत है। बारीक निगरानी के लिए, हमने डेटाबेस इंस्टेंस पर एजेंटों को सक्षम किया है। आइए एक नजर डालते हैं डैशबोर्ड पर।
यह आपके नोड्स की निगरानी के मामले में एक सुपर सहज अनुभव प्रदान करता है।
यह हमें बताता है कि उपयोग अधिक है या मेजबान प्रतिक्रिया नहीं दे रहा है। हालांकि यह सिर्फ एक पिंग . था प्रतिक्रिया विफलता, आप उस पर बमबारी करने से रोकने के लिए अलर्ट को अनदेखा कर सकते हैं। इसलिए, यदि आवश्यक हो तो आप क्लस्टर -> अलार्म इन द क्लस्टरकंट्रोल पर जाकर इसे 'अन-अनदेखा' कर सकते हैं। नीचे देखें:
विफलताओं को प्रबंधित करना और विफलता का प्रदर्शन करना
मान लें कि us-east1 मास्टर नोड विफल हो गया है, या सिस्टम या हार्डवेयर अपग्रेड के कारण एक बड़े ओवरहाल की आवश्यकता है। मान लें कि यह अभी टोपोलॉजी है (नीचे चित्र देखें):
आइए होस्ट 10.142.0.7 को बंद करने का प्रयास करें जो कि us-east1 क्षेत्र के अंतर्गत मास्टर है। नीचे स्क्रीनशॉट देखें कि ClusterControl इस पर कैसे प्रतिक्रिया करता है:
एक बार क्लस्टर में विसंगतियों का पता चलने पर ClusterControl अलार्म भेजता है। फिर यह सही उम्मीदवार चुनकर एक नए मास्टर को फेलओवर करने की कोशिश करता है (नीचे चित्र देखें):
फिर, इसने असफल मास्टर को अलग रख दिया जिसे पहले ही क्लस्टर से निकाल लिया गया है (नीचे चित्र देखें):
यह सिर्फ एक झलक है कि ClusterControl क्या कर सकता है, बैकअप, क्वेरी मॉनिटरिंग, लोड बैलेंसर्स को तैनात/प्रबंधित करने, और बहुत कुछ जैसी अन्य बेहतरीन सुविधाएं हैं!
निष्कर्ष
एक मल्टीक्लाउड में अपने MySQL प्रतिकृति सेटअप को प्रबंधित करना मुश्किल हो सकता है। हमारे सेटअप को सुरक्षित करने के लिए बहुत सावधानी बरतनी चाहिए, इसलिए उम्मीद है कि यह ब्लॉग सबनेट को परिभाषित करने और डेटाबेस नोड्स की रक्षा करने के बारे में एक विचार देता है। सुरक्षा के बाद, कई चीजों का प्रबंधन करना होता है और यहीं पर ClusterControl बहुत मददगार हो सकता है।
इसे अभी आज़माएं और हमें बताएं कि यह कैसा चल रहा है। आप हमसे यहां कभी भी संपर्क कर सकते हैं।