मल्टी-डेटासेंटर सेटअप होना डिजास्टर रिकवरी प्लान (DRP) के लिए एक सामान्य टोपोलॉजी है, लेकिन इस तरह के वातावरण को लागू करने की कुछ सीमाएँ हैं।
आपको सबसे पहले डेटा केंद्रों के बीच संचार को SSH एक्सेस का उपयोग करके या किसी VPN को कॉन्फ़िगर करके हल करना चाहिए। फिर, आपके पास विलंबता है कि (कॉन्फ़िगरेशन के आधार पर) आपके डेटाबेस क्लस्टर को प्रभावित कर सकता है। अंत में, आपको इस बारे में सोचना चाहिए कि विफलता को कैसे निष्पादित किया जाए। क्या मास्टर विफलता के मामले में एप्लिकेशन रिमोट नोड तक पहुंच सकता है?
इस ब्लॉग में, हम दिखाएंगे कि PostgreSQL के लिए एक बहु-डेटासेंटर सेटअप को कैसे कार्यान्वित किया जाए, जिसमें पहले बताए गए इन सभी बिंदुओं को शामिल किया गया है, उनमें से कुछ ClusterControl का उपयोग कर रहे हैं। इसे ज्यादा उबाऊ न बनाने के लिए हम इसे दो भागों में बांटेंगे। पहले भाग में, हम डेटा केंद्रों के बीच कनेक्टिविटी को कवर करेंगे। दूसरा परिनियोजन और कॉन्फ़िगरेशन के बारे में ही होगा, तो चलिए शुरू करते हैं!
उद्देश्य
मान लें कि आप निम्नलिखित टोपोलॉजी रखना चाहते हैं:
जहां आपका एप्लिकेशन एक लोड बैलेंसर, एक प्राथमिक डेटाबेस नोड से जुड़ा है , और एक डेटासेंटर में एक स्टैंडबाय नोड, और डीआर उद्देश्यों के लिए द्वितीयक डेटासेंटर में दूसरा स्टैंडबाय नोड। बहु-डेटासेंटर वातावरण के लिए यह एक न्यूनतम सेटअप हो सकता है। आप लोड बैलेंसर का उपयोग करने से बच सकते हैं, लेकिन विफलता के मामले में, आपको अपने एप्लिकेशन को नए मास्टर से कनेक्ट करने के लिए पुन:कॉन्फ़िगर करना चाहिए, ताकि इससे बचने के लिए हम इसका उपयोग करने की सलाह दें, या उनमें से दो का उपयोग करें (प्रत्येक डीसी पर एक) एकल से बचने के लिए विफलता का बिंदु।
इसे और स्पष्ट करने के लिए, आइए उदाहरण के तौर पर डेटासेंटर 1 और 2 दोनों को कुछ सार्वजनिक आईपी पते निर्दिष्ट करें।
डेटासेंटर 1 में, सार्वजनिक नेटवर्क 35.166.37.0/24 है, तो आइए इस तरह से निम्नलिखित आईपी पते निर्दिष्ट करें:
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13डेटासेंटर 2 में, सार्वजनिक नेटवर्क 18.197.23.0/24 है, इसलिए:
Standby 2 Node: 18.197.23.14डेटा सेंटर कनेक्टिविटी
पहली समस्या यह हो सकती है। आप उनके बीच एक वीपीएन कॉन्फ़िगर कर सकते हैं, और यह सबसे सुरक्षित तरीका होना चाहिए, लेकिन जैसा कि हमने पिछले ब्लॉग में एक वीपीएन कॉन्फ़िगरेशन को कवर किया था, और इसे जितना संभव हो उतना छोटा बनाने के लिए, हम उन्हें निजी/सार्वजनिक कुंजी का उपयोग करके एसएसएच एक्सेस के माध्यम से कनेक्ट करेंगे। ।
आइए सभी नोड्स में 'रिमोट' नामक एक उपयोगकर्ता बनाएं (रूट का उपयोग करने से बचने के लिए):
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.और आप इसे sudoers फ़ाइल में जोड़कर विशेषाधिकार प्रदान कर सकते हैं:
$ visudo
remote ALL=(ALL) ALLअब, लोड बैलेंसर सर्वर (जो कि ClusterControl सर्वर भी होगा) में, नए उपयोगकर्ता के लिए की जोड़ी जेनरेट करें:
$ su remote
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/remote/.ssh/id_rsa):
Created directory '/home/remote/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/remote/.ssh/id_rsa.
Your public key has been saved in /home/remote/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:hgVe/unld9+r/Ynk1HM+t089A41bwxFlPYt5/q+ZyL8 [email protected]
The key's randomart image is:
+---[RSA 3072]----+
| . . .=|
| . + oo|
| . o o.o|
| o . . o+o.|
| . S o .oo= |
| . . o =.o|
| . .+.=*|
| [email protected]|
| o=EB/|
+----[SHA256]-----+
Now you will have a new directory in the homeदूरस्थ सार्वजनिक आईपी पते का उपयोग करके प्रत्येक नोड में सार्वजनिक कुंजी की प्रतिलिपि बनाएँ:
$ ssh-copy-id 35.166.37.12
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/remote/.ssh/id_rsa.pub"
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '35.166.37.12'"
and check to make sure that only the key(s) you wanted were added.यह कमांड आपकी सार्वजनिक कुंजी को अधिकृत_की फ़ाइल में रिमोट नोड में कॉपी कर देगा, ताकि आप इसे निजी का उपयोग करके एक्सेस कर सकें।
फिर, उन्हें एक्सेस करने का प्रयास करें:
$ ssh 35.166.37.12सुनिश्चित करें कि आपके फ़ायरवॉल में SSH ट्रैफ़िक की अनुमति है, और इसे और अधिक सुरक्षित बनाने के लिए, आपको इसकी अनुमति केवल किसी ज्ञात स्रोत से ही देनी चाहिए (उदा. 35.166.37.0/24 से)।
उदाहरण के लिए, यदि आप AWS का उपयोग कर रहे हैं, तो आपको 35.166.37.0/24 से SSH पोर्ट पर इस तरह से ट्रैफ़िक की अनुमति देनी चाहिए:
या यदि आप IPTABLES का उपयोग कर रहे हैं, तो आपको कुछ इस तरह चलाना चाहिए:
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTया यदि आप किसी भिन्न फ़ायरवॉल समाधान का उपयोग कर रहे हैं तो समान आदेश।
इसे थोड़ा और सुरक्षित बनाने के लिए, हम डिफ़ॉल्ट वाले से भिन्न SSH पोर्ट का उपयोग करने की सलाह देते हैं, और इसे एक्सेस करने के कई असफल प्रयासों को प्रतिबंधित करने के लिए कुछ टूल का उपयोग करना भी उपयोगी हो सकता है, जैसे कि fail2ban।
निष्कर्ष
इस बिंदु पर, यदि सब कुछ ठीक रहा, तो आपके पास अपने डेटा केंद्रों के बीच SSH संचार होगा, इसलिए अगला कदम अपने PostgreSQL क्लस्टर को तैनात करना और विफलता के मामले में विफलता का प्रबंधन करना है, जैसा कि हम इस ब्लॉग के दूसरे भाग में देखेंगे।
