Redis Sentinel Redis के लिए एक सरल और स्वचालित उच्च उपलब्धता (HA) समाधान प्रदान करता है। यदि आप इस बात से परिचित हैं कि MongoDB चुनाव कैसे काम करते हैं, तो यह उससे बहुत दूर नहीं है। शुरू करने के लिए, आपके पास N संख्या में स्लेव्स को रेप्लिकेट करने वाला एक दिया गया मास्टर है। वहां से, आपके पास Sentinel डेमॉन चल रहे हैं, चाहे आपके एप्लिकेशन सर्वर्स पर या उन सर्वर्स पर जहां Redis चल रहा है। ये मास्टर के स्वास्थ्य पर नज़र रखते हैं।
यदि कोई Sentinel पता लगाता है कि एक मास्टर नॉन-रिस्पॉन्सिव है, तो यह अन्य सेंटिनल्स को SDOWN (सब्जेक्टिवली डाउन) संदेश प्रसारित करेगा। फिर, एक बार जब एक कोरम तक पहुंच जाता है कि एक मास्टर डाउन है, तो यह ODOWN (ऑब्जेक्टिवली डाउन) प्रसारित करेगा, और नया मास्टर चुना जाएगा। चूंकि आपको ODOWN स्थिति तक पहुंचने के लिए सेंटिनल्स के एक कोरम, या बहुमत से सहमत होने की आवश्यकता होती है, टाई से बचने के लिए विषम संख्या में Sentinels चलाना हमेशा सर्वोत्तम अभ्यास है।
नोट: Sentinel के साथ सर्वोत्तम प्रदर्शन के लिए Redis के 2.8 शाखा या उच्चतर के संस्करण का उपयोग करने की अत्यधिक अनुशंसा की जाती है।
यह कैसे काम करता है
Sentinels चल रहे Redis इंस्टेंस की कॉन्फ़िगरेशन फाइलों को रीराइट करके फेलओवर को संभालते हैं। आइए एक परिदृश्य के माध्यम से चलते हैं:
मान लें कि हमारे पास मास्टर "A" है जो स्लेव्स "B" और "C" को रेप्लिकेट कर रहा है। हमारे पास तीन Sentinels (s1, s2, s3) हैं जो हमारे एप्लिकेशन सर्वर्स पर चल रहे हैं, जो Redis को लिखते हैं। इस बिंदु पर "A", हमारा वर्तमान मास्टर, ऑफलाइन हो जाता है। हमारे सेंटिनल्स सभी "A" को ऑफलाइन देखते हैं, और एक दूसरे को SDOWN संदेश भेजते हैं। फिर वे सभी सहमत होते हैं कि "A" डाउन है, इसलिए "A" को ODOWN स्थिति में सेट किया जाता है। यहां से, यह देखने के लिए एक चुनाव होता है कि कौन सबसे आगे है, और इस मामले में "B" को नए मास्टर के रूप में चुना जाता है।
"B" के लिए कॉन्फ़िगरेशन फाइल सेट की जाती है ताकि यह अब किसी का स्लेव न हो। इस बीच, "C" के लिए कॉन्फ़िगरेशन फाइल रीराइट की जाती है ताकि यह अब "A" का स्लेव न हो बल्कि "B" का हो। यहां से, सब कुछ सामान्य रूप से जारी रहता है। क्या "A" को वापस ऑनलाइन आना चाहिए, सेंटिनल्स इसे पहचान लेंगे, और "A" के लिए कॉन्फ़िगरेशन फाइल को "B" का स्लेव होने के लिए रीराइट करेंगे, क्योंकि "B" वर्तमान मास्टर है।
कॉन्फ़िगरेशन
Sentinels को कॉन्फ़िगर करना उतना कठिन नहीं है जितना कोई सोचता होगा। वास्तव में, सबसे कठिन चीजों में से एक यह चुनना है कि अपने Sentinel प्रोसेस को कहां रखना है। मैं व्यक्तिगत रूप से यदि संभव हो तो उन्हें अपने ऐप सर्वर्स पर चलाने की सलाह देता हूं। संभवतः यदि आप इसे सेट अप कर रहे हैं, तो आप अपने मास्टर के लिए राइट उपलब्धता के बारे में चिंतित हैं। इस प्रकार, Sentinels इस बात की अंतर्दृष्टि प्रदान करते हैं कि आपका एप्लिकेशन सर्वर मास्टर से बात कर सकता है या नहीं। आप निश्चित रूप से अपने Redis इंस्टेंस सर्वर्स पर Sentinels चलाने के लिए स्वागत है।
कॉन्फ़िगरेशन चरण के साथ शुरू करने के लिए, कृपया यहां पाई गई उदाहरण फाइल का संदर्भ लें। यह Redis 2.8.4 पर Ubuntu 14.04 के साथ मिली एक उदाहरण sentinel.conf है, लेकिन किसी भी 2.8.x संस्करण के Redis के साथ काम करना चाहिए। मैंने शीर्ष पर दो लाइनें जोड़ने की स्वतंत्रता ली है जिन्हें मैं अभ्यास में उपयोग करना पसंद करता हूं:
daemonize yes
logfile /var/log/redis/redis-sentinel.logयह सेंटिनल प्रोसेस को डेमोनाइज मोड में रखता है, और इसके सभी संदेशों को stdout के बजाय एक लॉग फाइल में लॉग करता है।
यहां बहुत सारे कॉन्फ़िगरेबल विकल्प हैं, और अधिकांश बहुत अच्छी तरह से कमेंटेड हैं। हालांकि, इस पोस्ट के लिए हम केवल दो पर ध्यान केंद्रित करेंगे।
सबसे महत्वपूर्ण भाग सेंटिनल्स को बता रहा है कि आपका वर्तमान मास्टर कहां रहता है। इसे इस लाइन में संदर्भित किया गया है:
sentinel monitor mymaster 127.0.0.1 6379 2यह सेंटिनल को "mymaster" (यह एक मनमाना नाम है, बेझिझक इसे जैसा आप फिट देखें नाम दें) और एक दिए गए IP को एक दिए गए पोर्ट पर मॉनिटर करने के लिए कहता है, साथ ही फेलओवर के लिए कोरम को पूरा करने के लिए कितने सेंटिनल्स की आवश्यकता है (न्यूनतम 2 होना)। वे भाग जिन्हें आप शायद बदलना चाहेंगे वे हैं आपके मास्टर का IP पता और इसका पोर्ट, यदि यह मानक पोर्ट 6379 पर नहीं चल रहा है।
अगला, आप निम्न लाइन को बदलना चाह सकते हैं:
sentinel down-after-milliseconds mymaster 30000यह वह समय है जो आप एक सेंटिनल को SDOWN में मास्टर घोषित करने से पहले प्रतीक्षा करना चाहेंगे। डिफ़ॉल्ट 30 सेकंड है, मैं आमतौर पर इसे थोड़ा कम करके 10 सेकंड करना पसंद करता हूं। आप इसे बहुत कम नहीं करना चाहते; अन्यथा आपको बहुत बार फेलओवर होने की समस्या हो सकती है।
कुछ अन्य विकल्पों को देखने के लिए बेझिझक। एक जो बहुत सारे उपयोगकर्ताओं को रुचिकर लग सकता है वह नोटिफिकेशन स्क्रिप्ट है, यदि आप जब वे होते हैं तो फेलओवर का ट्रैक रखना पसंद करते हैं।
एक बार जब आप अपनी sentinel.conf को जैसा आप फिट देखते हैं कॉन्फ़िगर कर लेते हैं, तो निम्न कमांड के साथ डेमॉन शुरू करें:
redis-server /path/to/sentinel.conf --sentinelफेलओवर का परीक्षण
एक बार जब आपके सभी सेंटिनल्स ऑनलाइन हो जाते हैं, तो यह सुनिश्चित करने के लिए फेलओवर के लिए ड्राई रन करना संभव है कि यह सब सही ढंग से कॉन्फ़िगर किया गया है।
पहली चीज पहली। redis-cli के माध्यम से अपने Sentinel से कनेक्ट करें:
redis-cli -p 26379यदि आप सेंटिनल के बारे में कुछ जानकारी प्राप्त करना चाहते हैं, तो बस इस कमांड को चलाएं:
127.0.0.1:26379> INFOयह आपको जानकारी देगा, जैसे वर्तमान मास्टर कौन है, इसके कितने स्लेव्स हैं, और कितने सेंटिनल्स इसकी निगरानी कर रहे हैं।
फेलओवर का परीक्षण करने के लिए, बस निष्पादित करें:
127.0.0.1:26379> SENTINEL failover mymasterयह वर्तमान मास्टर पर ODOWN को बाध्य करेगा और फेलओवर होने का कारण बनेगा। थोड़ी देर बाद, यदि आप "INFO" कमांड फिर से चलाते हैं, तो आपको अब एक नया मास्टर सूचीबद्ध दिखाई देना चाहिए।
निष्कर्ष
उम्मीद है कि यह Redis और Sentinel को रहस्यमय बनाने में मददगार रहा है। यदि आपके कोई प्रश्न हैं, तो बेझिझक नीचे पोस्ट करें!
