Dynomite से Redis Enterprise Active-Active में निर्बाध माइग्रेशन - चरण-दर-चरण गाइड

इस लेख के भाग I में, "Dynomite डेटाबेस को Redis Enterprise Active-Active डेटाबेस में क्यों माइग्रेट करें?", हमने Dynomite और Redis Enterprise की आर्किटेक्चर और फीचर्स की तुलना की। हमने दिखाया कि कैसे Redis Enterprise आपको फीचर-रिच, आसानी से प्रबंधनीय तरीके से Redis Enterprise को जियो-डिस्ट्रीब्यूट करने में मदद कर सकता है, और समवर्ती लिखने के बीच संघर्षों के बारे में चिंता किए बिना।

भाग II में, Dynomite से Redis Enterprise में माइग्रेट करने के लिए उपलब्ध माइग्रेशन विकल्पों का वर्णन किया जाएगा।

ध्यान दें कि इसके बाद Redis Enterprise के सेल्फ-मैनेज्ड ऑफरिंग को "Redis Enterprise Software" कहा जाएगा और मैनेज्ड ऑफरिंग को "Redis Enterprise Cloud" या "क्लाउड सब्सक्रिप्शन" कहा जाएगा।

अपने Dynomite डेटाबेस को माइग्रेट करना

आइए व्यावहारिक बनें और देखें कि हम दो प्रकार के माइग्रेशन कैसे चला सकते हैं:

1. Redis Enterprise के इम्पोर्ट/एक्सपोर्ट फीचर का उपयोग करके माइग्रेशन
2. Redis Enterprise के ReplicaOf फीचर का उपयोग करके माइग्रेशन, जिसे Active-Passive भी कहा जाता है

चित्रण के उद्देश्य के लिए, मान लें कि हमारे पास दो डेटासेंटर्स में फैला एक Dynomite क्लस्टर है: dc-a और dc-b। प्रत्येक डेटासेंटर में एक रैक है, और प्रत्येक रैक दो नोड्स से बना है, जिनके बीच डेटासेट वितरित है।

यदि हम Dynomite की आर्किटेक्चर के हमारे विवरण को याद करते हैं, तो हम जानते हैं कि प्रत्येक Dynomite रैक में पूरा डेटासेट होता है।

इसलिए, हम अपने माइग्रेशन के दायरे को, चाहे वह इम्पोर्ट/एक्सपोर्ट हो या Active-Passive, अपने Dynomite सेटअप के भीतर एक ही रैक तक सीमित कर सकते हैं।

आइए rack-1-dc-a को चुनें और मान लें कि इसके दो नोड्स के IP इस प्रकार हैं:

• a1: 10.0.0.1
• a2: 10.0.0.2

स्पष्टता के लिए, यहां हमारे Dynomite सेटअप के लिए yaml कॉन्फिगरेशन है:

 #a1 dyn_o_mite: datacenter: dc-a dyn_listen: 10.0.0.1:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.3:7379:rack1:dc-a:4294967294 - 10.0.0.4:7379:rack1:dc-b:4294967294 - 10.0.0.2:7379:rack1:dc-b:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 2147483647 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM #a2 dyn_o_mite: datacenter: dc-a dyn_listen: 10.0.0.3:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.1:7379:rack1:dc-a:2147483647 - 10.0.0.4:7379:rack1:dc-b:4294967294 - 10.0.0.2:7379:rack1:dc-b:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 4294967294 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM #b1 dyn_o_mite: datacenter: dc-b dyn_listen: 10.0.0.2:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.4:7379:rack1:dc-b:4294967294 - 10.0.0.1:7379:rack1:dc-a:4294967294 - 10.0.0.3:7379:rack1:dc-a:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 2147483647 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM #b2 dyn_o_mite: datacenter: dc-b dyn_listen: 10.0.0.4:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.2:7379:rack1:dc-b:2147483647 - 10.0.0.1:7379:rack1:dc-a:4294967294 - 10.0.0.3:7379:rack1:dc-a:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 4294967294 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM 

इस कॉन्फिगरेशन और ट्यूटोरियल के लिए उपयोग किए गए सेटअप पर कुछ अवलोकन:

• Ubuntu 18.04 चलाने वाले चार GCP VMs।
• VMs एक ही VPC में रहते हैं जो कई क्षेत्रों में फैला है।
• पोर्ट 7379 और 7380 खोले गए, क्योंकि Dynomite डेटा रेप्लिकेट करने के लिए उन पोर्ट्स का उपयोग करता है - yaml कॉन्फिगरेशन में "dyn_port"।
• Redis OSS प्रत्येक नोड पर पोर्ट 6379 पर चल रहा है - yaml कॉन्फिगरेशन में "servers" देखें।
• Dynomite क्लाइंट्स के अनुरोधों के लिए पोर्ट 8379 पर सुनता है (जैसे redis-cli -h 10.0.0.1 -p 8379) - yaml कॉन्फिगरेशन में "listen" देखें।

अब जब हम अपने सेटअप को समझते हैं और तय कर चुके हैं कि हम अपने माइग्रेशन के लिए किस रैक का उपयोग करेंगे, तो आइए Redis Enterprise डेटाबेस बनाएं।

अपना Redis Enterprise Active-Active डेटाबेस बनाएं

चूंकि इस लेख का उद्देश्य यह समझाना नहीं है कि अपना क्लस्टर कैसे सेट करें या अपना डेटाबेस कैसे बनाएं, कृपया अपने Active-Active डेटाबेस को चालू करने के लिए नीचे दिए गए दस्तावेज़ देखें:

• Redis Enterprise Software क्लस्टर
• क्लाउड सब्सक्रिप्शन
• सॉफ्टवेयर डेटाबेस निर्माण
• सॉफ्टवेयर Active-Active डेटाबेस निर्माण
• क्लाउड डेटाबेस निर्माण

हमारे दो माइग्रेशन परिदृश्यों का परीक्षण करने के लिए, मैंने दो Redis Enterprise Software क्लस्टर्स में फैले एक Active-Active डेटाबेस बनाया है - एक यूरोप में और एक यू.एस. में। प्रत्येक क्लस्टर तीन VMs से बना है जो Ubuntu 18.04 चला रहे हैं। जान लें कि यदि आप Active-Active के बिना डेटाबेस बनाते हैं, तो माइग्रेशन चरण समान होंगे, जब तक कि इस लेख में अन्यथा निर्दिष्ट न हो।

आइए अपने पहले प्रकार के माइग्रेशन के साथ आगे बढ़ते हैं।

इम्पोर्ट/एक्सपोर्ट फीचर का उपयोग करके माइग्रेशन

Redis OSS एक पर्सिस्टेंस विकल्प प्रदान करता है जिसे Redis डेटाबेस बैकअप फाइल्स या RDB कहा जाता है, जो आपके डेटासेट के पॉइंट-इन-टाइम स्नैपशॉट करता है, या तो निर्दिष्ट अंतराल पर या SAVE या BGSAVE कमांड द्वारा ट्रिगर किए जाने पर।

उन स्नैपशॉट्स को .rdb फाइलों में सहेजा जाता है, जिन्हें यहां RDB फाइलें कहा जाता है। हम उन्हें अपने Dynomite सर्वर्स से एक्सपोर्ट करेंगे और अपने Redis Enterprise डेटाबेस में इम्पोर्ट करेंगे। इस समाधान के साथ, ध्यान दें कि डेल्टा माइग्रेशन संभव नहीं है और इम्पोर्ट में कुछ समय लग सकता है, डेटा के आकार के आधार पर।

महत्वपूर्ण: Redis Enterprise के नॉन-जियो-डिस्ट्रीब्यूटेड डेटाबेस और Active-Active डेटाबेस के बीच एक बड़ा अंतर है:

• नॉन जियो-डिस्ट्रीब्यूटेड डेटाबेस: RDB फाइलें इम्पोर्ट करते समय, मौजूदा डेटाबेस की सभी सामग्री मिटा दी जाएगी।
• Active-Active डेटाबेस: आप RDB फाइलें इम्पोर्ट कर सकते हैं और उन्हें अपने मौजूदा डेटासेट में मर्ज कर सकते हैं। इसका मतलब है कि आप इम्पोर्ट से पहले और दौरान अपने Active-Active डेटाबेस पर राइट ट्रैफिक भेजना शुरू कर सकते हैं। ध्यान दें - यदि आप अपने Active-Active डेटाबेस पर उन कुंजियों को लिख रहे हैं जो पहले से Dynomite में मौजूद हैं, तो बाद का इम्पोर्ट नए मानों को पुराने मानों से ओवरराइट कर सकता है! इसके लिए सावधानीपूर्वक योजना की आवश्यकता होती है।

Dynomite से Redis Enterprise में RDB फाइलों के साथ डेटा माइग्रेट करने का तरीका इस प्रकार है:

• Dynomite डेटाबेस पर ट्रैफिक रोकें और, यदि आपने अपने माइग्रेशन की सावधानीपूर्वक योजना बनाई है, और Active-Active डेटाबेस का उपयोग कर रहे हैं, तो Redis Enterprise डेटाबेस पर कटओवर करें।
• प्रत्येक नोड के डेटा (हमारे मामले में a1 और a2) को RDB फाइलों के रूप में एक्सपोर्ट करें।
• RDB फाइलों को उस स्थान पर अपलोड करें जो Redis Enterprise क्लस्टर से एक्सेसिबल हो (जैसे, Google Cloud Storage बकेट, AWS S3 बकेट, FTP सर्वर, आदि)
• RDB फाइलों को Redis Enterprise डेटाबेस में इम्पोर्ट करें।
• Redis Enterprise डेटाबेस पर कटओवर करें।

आइए उपरोक्त चरणों को अधिक विस्तार से देखें।

वैकल्पिक: प्रत्येक नोड पर Redis OSS कॉन्फिगरेशन फाइलें संपादित करें

आपके Dynomite नोड्स पर चल रहे Redis OSS इंस्टेंसेस की कॉन्फिगरेशन फाइलें डिफ़ॉल्ट रूप से /etc/redis में स्थित होती हैं यदि आपने इसे "apt-get" के साथ इंस्टॉल किया है, या आपके Redis फोल्डर में यदि आपने Redis OSS खुद बनाया है। इस फाइल को "redis.conf" कहा जाता है।

इस फाइल को अपने पसंदीदा टेक्स्ट एडिटर से खोलें और "dbfilename" डायरेक्टिव को खोजें। प्रत्येक नोड पर फाइल का नाम बदलें, जैसे

• नोड 1 पर "dump1.rdb",
• नोड 2 पर "dump2.rdb"।

यह सुनिश्चित करता है कि जब हम अपने RDB फाइलों को एक्सटर्नल स्टोरेज में एक्सपोर्ट करते हैं, तो उनके नाम समान नहीं होते। यदि आप चाहें तो स्नैपशॉट लेने के बाद उनके नाम बदल सकते हैं।

वैकल्पिक रूप से, आप यह भी कर सकते हैं:

• "dir" डायरेक्टिव के साथ वह डायरेक्टरी बदलें जिसमें RDB फाइलें स्टोर की जाएंगी।
• स्नैपशॉटिंग अंतराल बदलें या ऑटोमैटिक स्नैपशॉटिंग अक्षम करें। इस ट्यूटोरियल में, हम SAVE Redis कमांड का उपयोग करके स्नैपशॉटिंग को ट्रिगर करेंगे, ताकि हम ट्रैफिक रोकने के बाद पूरा डेटासेट डंप करना सुनिश्चित कर सकें।

ध्यान दें कि Redis OSS कॉन्फिगरेशन फाइलों को संपादित करने के बाद, आपको Redis OSS सर्वर को रीस्टार्ट करना होगा ताकि आपके परिवर्तन प्रभावी हों।

डेटा डंप करें

अब पोर्ट 8379 के माध्यम से अपने Dynomite डेटाबेस पर आने वाले ट्रैफिक को रोकें। फिर से, यदि आप Active-Active डेटाबेस में इम्पोर्ट कर रहे हैं और अपने माइग्रेशन की सावधानीपूर्वक योजना बनाई है ताकि इम्पोर्ट के दौरान किसी भी आकस्मिक ओवरराइट का जोखिम न हो, तो आप ट्रैफिक को अपने Active-Active डेटाबेस पर कटओवर कर सकते हैं।

redis-cli लॉन्च करें। पोर्ट 8379, Dynomite का सुनने वाला पोर्ट, उपयोग न करें। इसके बजाय पोर्ट 6379 का उपयोग करें। ऐसा इसलिए है क्योंकि हमें अपने नोड पर चल रहे Redis OSS इंस्टेंस से कनेक्ट करने की आवश्यकता है, न कि हमारे Dynomite क्लस्टर से, जो SAVE कमांड का समर्थन नहीं करता। आप बिना किसी कमांड-लाइन आर्गुमेंट के बस redis-cli चला सकते हैं।

प्रत्येक नोड पर, DBSIZE कमांड चलाएं। आपको Redis OSS के प्रत्येक इंस्टेंस पर संग्रहीत कुंजियों की संख्या मिलेगी। कुल हमारे Dynomite डेटाबेस में कुंजियों की संख्या होनी चाहिए।

 #a1 127.0.0.1:6379> dbsize (integer) 1323 #a2 127.0.0.1:6379> dbsize (integer) 1371 

SAVE कमांड चलाएं और जांचें कि आपकी RDB फाइलें /var/lib/redis में बनाई गई हैं - या आपके द्वारा निर्दिष्ट किसी भी डायरेक्टरी में।

दोनों डंप फाइलों को एक्सटर्नल स्टोरेज में एक्सपोर्ट करें

हम अब अपने दो RDB फाइलों को एक्सटर्नल स्टोरेज में एक्सपोर्ट करने के लिए तैयार हैं।

इस ट्यूटोरियल के लिए, मैं फाइलों को Google Cloud के क्लाउड स्टोरेज में एक्सपोर्ट करूंगा, लेकिन आप अन्य एक्सटर्नल स्टोरेज विकल्पों का भी उपयोग कर सकते हैं जैसे FTP सर्वर, किसी अन्य क्लाउड सर्विस प्रोवाइडर का स्टोरेज समाधान, या आपके Redis Enterprise क्लस्टर से एक्सेसिबल एक्सटर्नल डिस्क। आप उन विकल्पों के बारे में नीचे अधिक जानकारी पा सकते हैं:

• Redis Enterprise Software
• Redis Enterprise Cloud

Google Cloud में, मैंने निम्नलिखित बनाया है:

• एक सर्विस अकाउंट जिसके लिए मैंने एक JSON कुंजी बनाई है।
• एक क्लाउड स्टोरेज बकेट जिसके लिए मैंने अपने सर्विस अकाउंट को Storage Legacy Object Reader अनुमति दी है।

अब प्रत्येक नोड के लिए, हम निम्नलिखित कमांड चलाएंगे:

 gsutil cp path_to_dump_file gs://your_bucket 

अब हम अपने Google Cloud बकेट में अपनी दो RDB फाइलें देख सकते हैं:

हम अब उन्हें अपने Active-Active डेटाबेस में इम्पोर्ट करने के लिए तैयार हैं।

डंप फाइलों को Redis Enterprise डेटाबेस में इम्पोर्ट करें

Redis Enterprise UI में लॉग इन करें और अपना Active-Active डेटाबेस चुनें। यदि इस ट्यूटोरियल की तरह, आपने कई क्लस्टर्स में फैले एक Redis Enterprise Active-Active डेटाबेस बनाया है, तो आप जिस भी क्लस्टर को पसंद करते हैं उसके माध्यम से UI से कनेक्ट कर सकते हैं। इस ट्यूटोरियल में, हम अपने यूरोप (EU) क्लस्टर का उपयोग करेंगे।

यदि आप क्लाउड Active-Active डेटाबेस का उपयोग कर रहे हैं, तो बस क्लाउड UI से कनेक्ट करें और अपना डेटाबेस चुनें।

आइए अपने डेटाबेस के कॉन्फिगरेशन पेज पर जाएं और इम्पोर्ट बटन पर क्लिक करें। उपयुक्त स्टोरेज टाइप चुनें। हमारे मामले में, यह Google Cloud Storage होगा।

अब हम अपनी दो RDB फाइलों का क्लाउड स्टोरेज पथ जोड़ सकते हैं जैसे:

• /helene-test/dump1.rdb
• /helene-test/dump2.rdb

हमें निम्नलिखित जानकारी भी जोड़ने की आवश्यकता है:

• क्लाइंट ID
• क्लाइंट ईमेल
• प्राइवेट कुंजी ID
• प्राइवेट कुंजी

यह जानकारी उस JSON कुंजी फाइल में मिल सकती है जिसे आपने Google Cloud सर्विस अकाउंट के लिए कुंजी बनाते समय डाउनलोड किया था।

ध्यान दें कि प्राइवेट कुंजी JSON फाइल में अजीब तरह से फॉर्मेट की गई है; इसमें उद्धरण चिह्न और नई लाइनें हैं। इसे जल्दी से एक ऐसे तरीके में फॉर्मेट करने के लिए जिसे Redis Enterprise UI स्वीकार करे, बस एक पायथन इंटरप्रेटर लॉन्च करें और इसे प्रिंट करें:

 print(WHOLE_COPIED_KEY) 

अब हमारे पास निम्नलिखित इम्पोर्ट कॉन्फिगरेशन है:

इम्पोर्ट पर क्लिक करें और इम्पोर्ट समाप्त होने तक प्रतीक्षा करें जो डेटाबेस के आकार पर निर्भर करेगा।

डेटाबेस जांचें और कटओवर करें

redis-cli के साथ, अपने Redis Enterprise डेटाबेस के एंडपॉइंट से कनेक्ट करें। कुछ कुंजियों को पढ़ने का प्रयास करें और DBSIZE कमांड चलाएं ताकि यह जांचा जा सके कि आपके पास कुंजियों की सही कुल संख्या है।

 redis-12000.internal.helene-eu-cluster.demo.redislabs.com:12000> dbsize (integer) 2694 

Active-Active जियो-डुप्लिकेशन की जांच करना न भूलें! बस दूसरे क्लस्टर के डेटाबेस एंडपॉइंट से कनेक्ट करें, हमारे मामले में यहां, यू.एस. वाला, और जांचें कि आपको कितनी कुंजियां मिलती हैं।

आपका माइग्रेशन अब पूरा हो गया है। यदि आपने पहले से नहीं किया है तो आप अपने डेटाबेस पर ट्रैफिक कटओवर कर सकते हैं।

ReplicaOf फीचर का उपयोग करके माइग्रेशन

अब आइए एक निरंतर माइग्रेशन चलाएं।

Redis Enterprise फीचर 'ReplicaOf' (जिसे Redis Cloud UI में Active-Passive भी कहा जाता है) हमें दो Redis डेटाबेस के बीच लगातार डेटा रेप्लिकेट करने की अनुमति देता है। मुख्य लाभ यह है कि यह प्रारंभिक सिंक्रोनाइज़ेशन पूरा होने के बाद डेल्टा को रेप्लिकेट करता है, जिसका अर्थ है लगभग कोई एप्लिकेशन-साइड डाउनटाइम नहीं।

चरण हैं:

• Dynomite डेटाबेस और Active-Active डेटाबेस के बीच एक ReplicaOf लिंक स्थापित करें
• प्रारंभिक सिंक्रोनाइज़ेशन पूरा होने तक प्रतीक्षा करें
• Dynomite डेटाबेस पर ट्रैफिक रोकें
• डेल्टा के रेप्लिकेट होने तक प्रतीक्षा करें
• डेटाबेस के बीच ReplicaOf लिंक हटाएं
• Active-Active डेटाबेस पर कटओवर करें

ReplicaOf का उपयोग Active-Passive तरीके से करने का इरादा है। इसका मतलब है कि टारगेट को पैसिव माना जाता है, और इसे सहन करने की आवश्यकता होती है ताकि टारगेट पूरी तरह से री-सिंक्रोनाइज़ हो जाए (टारगेट डेटाबेस का फ्लश + सोर्स डेटाबेस से सिंक)।

माइग्रेशन शुरू करने से पहले, आइए कुछ सुरक्षा पहलुओं पर चर्चा करें।

आपके Dynomite सेटअप में Redis OSS के लिए सुरक्षा कॉन्फिगरेशन

सबसे पहले, आपको उस नेटवर्क के लिए कस्टम TCP के साथ 6379 पोर्ट के लिए एक इनबाउंड नियम जोड़ने की आवश्यकता है जिसमें आपका Dynomite रैक रहता है।

दूसरे, दोनों Dynomite नोड्स पर Redis OSS कॉन्फिगरेशन फाइलों को अपडेट करने की आवश्यकता है। डिफ़ॉल्ट रूप से, Redis केवल IPv4 और IPv6 (यदि उपलब्ध हो) लूपबैक इंटरफेस पतों पर सुनता है। इसका मतलब है कि Redis OSS केवल उसी होस्ट से क्लाइंट कनेक्शन स्वीकार कर पाएगा जिस पर वह चल रहा है। हमें Redis OSS के "bind" डायरेक्टिव को अपडेट करने की आवश्यकता है ताकि Redis OSS हमारे Redis Enterprise क्लस्टर होस्ट से कनेक्शन सुन सके।

इसे करने के दो तरीके हैं:

• Redis OSS को केवल पीयर्ड VPC में एक मशीन से आने वाले कनेक्शन सुनने दें - अनुशंसित और अधिक सुरक्षित
• Redis OSS को सभी होस्ट्स द्वारा एक्सेस करने दें - सुरक्षित नहीं, खासकर जब से Dynomite डेटाबेस पासवर्ड का समर्थन नहीं करता

आइए उन दो विकल्पों पर विस्तार से चर्चा करें।

विकल्प 1 - VPC पीयरिंग के साथ

पहला विकल्प उस VPC को पीयर करना है जिसमें आपका Dynomite रैक रहता है, उस VPC के साथ जिसमें आपका Redis Enterprise क्लस्टर रहता है। कृपया ध्यान दें कि, यदि हमारे जैसे, आपने एक Active-Active डेटाबेस बनाया है, तो यह किसी भी क्लस्टर में रह सकता है। जैसा पहले, हम प्रदर्शन के लिए अपने यूरोप (EU) क्लस्टर का उपयोग करेंगे।

एक बार जब आप अपने नेटवर्क को पीयर कर लेते हैं, तो आपको बस redis.conf फाइल में "bind" डायरेक्टिव को संपादित करना होगा: डिफ़ॉल्ट लूपबैक इंटरफेस पतों के बाद अपने Dynomite मशीन का प्राइवेट IP जोड़ें।

रैक में सभी नोड्स के लिए ऐसा करें और बस! अपने Redis OSS इंस्टेंसेस को रीस्टार्ट करना न भूलें।

विकल्प 2 - VPC पीयरिंग के बिना

यदि आप अपने नेटवर्क को पीयर नहीं कर सकते या नहीं करना चाहते हैं, तो आपको प्रत्येक नोड पर Redis OSS कॉन्फिगरेशन फाइल को निम्नलिखित तरीके से अपडेट करने की आवश्यकता है:

• "bind" डायरेक्टिव को कमेंट करें, जो आपके Redis OSS इंस्टेंस को इंटरनेट पर सभी के लिए उजागर करेगा
• "protected-mode" को "no" पर सेट करें, ताकि क्लाइंट अन्य होस्ट्स से Redis से कनेक्ट कर सकें भले ही कोई प्रमाणीकरण कॉन्फिगर न हो, न ही "bind" डायरेक्टिव का उपयोग करके इंटरफेस का एक विशिष्ट सेट स्पष्ट रूप से सूचीबद्ध हो।

महत्वपूर्ण: यह अंतिम चरण आवश्यक है क्योंकि Dynomite Redis के OSS AUTH कमांड का समर्थन नहीं करता, जो हमें डेटाबेस पासवर्ड सेट करने से रोकता है। इसलिए, यदि आप उपयोग में पोर्ट्स से कौन कनेक्ट करता है इसे नियंत्रित करने के लिए फ़ायरवॉल का उपयोग नहीं करते हैं, तो कोई भी Redis OSS इंस्टेंस से कनेक्ट कर सकता है और इसके डेटा को एक्सेस/बदल/हटा सकता है। पोर्ट 6379 को केवल आपके Redis Enterprise क्लस्टर के होस्ट के लिए खोलें।

यदि आप वास्तव में पासवर्ड का उपयोग करना चाहते थे, तो आप कर सकते थे। लेकिन यह निरंतर माइग्रेशन चलाना असंभव बना देगा, क्योंकि आपको निम्नलिखित करना होगा:

• Dynomite डेटाबेस पर ट्रैफिक रोकें
• "requirepass" डायरेक्टिव को संपादित करके डेटाबेस के लिए पासवर्ड सेट करें। इस बिंदु से, आप पोर्ट 8379 का उपयोग करके अपने Dynomite डेटाबेस पर कोई भी राइट ट्रैफिक नहीं भेज पाएंगे, क्योंकि डेटाबेस तक पहुंचने के लिए AUTH कमांड की आवश्यकता होगी
• नीचे वर्णित अनुसार ReplicaOf का उपयोग करके माइग्रेशन करें
• Redis Enterprise डेटाबेस पर ट्रैफिक कटओवर करें

एक और सुरक्षा विचार और हम अपना माइग्रेशन शुरू करने के लिए तैयार हैं!

वैकल्पिक - TLS सक्षम करें

आपके डेटा तक अनधिकृत पहुंच को रोकने के लिए, Redis Enterprise TLS प्रोटोकॉल का समर्थन करता है।

यदि आप Redis Enterprise Software का उपयोग कर रहे हैं, तो आप इसे विशेष रूप से ReplicaOf संचार के लिए कॉन्फिगर कर सकते हैं। यदि आप Redis Enterprise Cloud का उपयोग कर रहे हैं, तो आप सामान्य रूप से TLS सक्षम कर सकते हैं।

डेटाबेस के बीच ReplicaOf लिंक सेट करें

Redis Enterprise UI में, आइए हमारे Active-Active डेटाबेस कॉन्फिगरेशन पेज पर जाएं और Edit पर क्लिक करें।

हमारे पास Active-Passive/ReplicaOf को सक्षम करने का विकल्प है। एक बार जब हम ऐसा करते हैं, तो हम निम्नलिखित प्रारूप में सोर्स जोड़ सकते हैं:

 redis://:@IP:port 

कृपया ध्यान दें:

• ReplicaOf अधिकतम 32 सोर्स की अनुमति देता है। इसका मतलब है कि यदि आपने Dynomite रैक में 32 से अधिक नोड्स में अपना डेटासेट वितरित किया है, तो आप इस विकल्प का उपयोग नहीं कर पाएंगे
• यदि आपने VPC पीयरिंग का उपयोग किया है, तो आपको अपने मशीनों के प्राइवेट IPs का उपयोग करना चाहिए
• यदि आपने VPC पीयरिंग का उपयोग नहीं किया है:
  • आपको अपने मशीनों के पब्लिक IPs का उपयोग करना चाहिए
  • यदि आपने अपने डेटाबेस के लिए पासवर्ड सेट करने का फैसला किया (और एक बार का माइग्रेशन चलाने के लिए), तो पासवर्ड इस प्रकार प्रदान किया जाना चाहिए: redis://:password@IP:port।

हमारे मामले में, VPC पीयरिंग के साथ, हमारे सोर्स इस तरह दिखते हैं:

माइग्रेशन शुरू करें

अब आइए निम्नलिखित चरण लें:

• Redis Enterprise UI में Update पर क्लिक करें,
• प्रारंभिक सिंक्रोनाइज़ेशन समाप्त होने तक प्रतीक्षा करें,
• Dynomite डेटाबेस पर ट्रैफिक रोकें,
• डेल्टा के सिंक्रोनाइज़ होने तक प्रतीक्षा करें,
• Active-Active डेटाबेस को फिर से अपडेट करके ReplicaOf अक्षम करें,
• Active-Active डेटाबेस पर ट्रैफिक शुरू करें।

अपने डेटा की जांच करें

पहले की तरह, redis-cli के साथ अपने डेटाबेस से कनेक्ट करें और जांचें कि आपका डेटा माइग्रेट हो गया है। अन्य क्लस्टर्स/अन्य लोकल एंडपॉइंट्स से कनेक्ट करके Active-Active जियो-डुप्लिकेशन की भी जांच करें।

निष्कर्ष

Redis को कई वर्षों तक डेवलपर्स द्वारा सबसे पसंदीदा डेटाबेस नामित किया गया है। यदि आप Dynomite का उपयोग कर रहे हैं, तो शायद इसलिए क्योंकि आप Redis से भी प्यार करते हैं। Redis, Redis OSS और Redis Enterprise दोनों का घर होने के नाते, आपके संगठन को Redis को अधिक प्रबंधनीय तरीके से जियो-डिस्ट्रीब्यूट करने में मदद कर सकता है, जबकि संघर्ष समाधान के लिए उच्चतम शैक्षणिक मानकों को बनाए रखता है।