वर्चुअल आईपी एड्रेस एक ऐसा आईपी एड्रेस होता है जो वास्तविक भौतिक नेटवर्क इंटरफेस के अनुरूप नहीं होता है। यह कई नेटवर्क इंटरफेस के बीच तैरता है और गलती सहनशीलता और गतिशीलता के लिए केवल एक सक्रिय इंटरफ़ेस आईपी पता धारण करेगा। ClusterControl डेटाबेस लोड बैलेंसर्स के साथ वर्चुअल आईपी एड्रेस इंटीग्रेशन प्रदान करने के लिए Keepalived का उपयोग करता है ताकि लोड बैलेंसर स्तर पर किसी एकल बिंदु विफलता (SPOF) को समाप्त किया जा सके।
इस ब्लॉग पोस्ट में, हम आपको दिखाएंगे कि कैसे क्लस्टरकंट्रोल वर्चुअल आईपी एड्रेस को कॉन्फ़िगर करता है और फ़ेलओवर या फ़ेलबैक होने पर आप क्या उम्मीद कर सकते हैं। किसी भी सेवा रुकावट को कम करने के लिए और कभी-कभी किए जाने वाले रखरखाव कार्यों को सुचारू करने के लिए इस व्यवहार को समझना महत्वपूर्ण है।
आवश्यकताएं
आपके नेटवर्क में Keepalived चलाने के लिए कुछ आवश्यकताएं हैं:
- आईपी प्रोटोकॉल 112 (वर्चुअल राउटर रिडंडेंसी प्रोटोकॉल - वीआरआरपी) नेटवर्क में समर्थित होना चाहिए। कुछ नेटवर्क VRRP के लिए समर्थन अक्षम कर देते हैं, विशेष रूप से इंटर-वीएलएएन संचार। कृपया इसे नेटवर्क व्यवस्थापक से सत्यापित करें।
- यदि आप मल्टीकास्ट का उपयोग करते हैं, तो नेटवर्क को मल्टीकास्ट अनुरोध का समर्थन करना चाहिए (आईपी ए | grep -i मल्टीकास्ट का उपयोग करें)। अन्यथा, आप unicast_src_ip . के माध्यम से यूनिकास्ट का उपयोग कर सकते हैं और unicast_peer विकल्प। मल्टीकास्ट का उपयोग तब उपयोगी होता है जब आपके पास क्लाउड वातावरण जैसा गतिशील वातावरण होता है, या जब डीएचसीपी के माध्यम से आईपी असाइनमेंट किया जाता है।
- VRRP इंस्टेंस के एक सेट को एक अद्वितीय virtual_router_id का उपयोग करना चाहिए मूल्य, जिसे अन्य उदाहरणों के बीच साझा नहीं किया जा सकता है। अन्यथा, आप फर्जी पैकेट देखेंगे और मास्टर-बैकअप स्विच को तोड़ देंगे।
- यदि आप एडब्ल्यूएस जैसे क्लाउड वातावरण पर चल रहे हैं, तो आपको वर्चुअल आईपी एड्रेस (इलास्टिक आईपी) को अलग करने और संबद्ध करने के लिए शायद एक बाहरी स्क्रिप्ट (संकेत:"सूचित करें" विकल्प का उपयोग करें) का उपयोग करने की आवश्यकता है ताकि इसे मान्यता प्राप्त हो और इसके द्वारा रूट किया जा सके। राउटर।
रख-रखाव तैनात करना
ClusterControl के माध्यम से Keepalived को स्थापित करने के लिए, आपको ClusterControl द्वारा स्थापित या आयात किए गए दो या अधिक लोड बैलेंसर की आवश्यकता होती है। उत्पादन के उपयोग के लिए, हम अत्यधिक अनुशंसा करते हैं कि लोड बैलेंसर सॉफ़्टवेयर एक स्टैंडअलोन होस्ट पर चल रहा हो और आपके डेटाबेस नोड्स के साथ सह-स्थित न हो।
आपके पास ClusterControl द्वारा प्रबंधित कम से कम दो लोड बैलेंसर होने के बाद, Keepalived को स्थापित करने और वर्चुअल IP पता सक्षम करने के लिए, बस ClusterControl पर जाएँ -> क्लस्टर चुनें -> मैनेज करें -> लोड बैलेंसर -> Keepalived:
अधिकांश क्षेत्र स्व-व्याख्यात्मक हैं। आप Keepalived का एक नया सेट परिनियोजित कर सकते हैं या मौजूदा Keepalived इंस्टेंस आयात कर सकते हैं। महत्वपूर्ण क्षेत्रों में वास्तविक वर्चुअल आईपी पता और नेटवर्क इंटरफ़ेस शामिल है जहां वर्चुअल आईपी पता मौजूद होगा। यदि होस्ट दो अलग-अलग इंटरफ़ेस नामों का उपयोग कर रहे हैं, तो Keepalived 1 होस्ट का इंटरफ़ेस नाम निर्दिष्ट करें, फिर बाद में सही इंटरफ़ेस नाम के साथ Keepalived 2 पर कॉन्फ़िगरेशन फ़ाइल को मैन्युअल रूप से संशोधित करें।
VRRP इंस्टेंस
लेखन के वर्तमान समय में, ClusterControl v1.5.1 Keepalived v1.3.5 (होस्ट ऑपरेशन सिस्टम के आधार पर) स्थापित करता है और VRRP इंस्टेंस के लिए निम्नलिखित को कॉन्फ़िगर किया गया है:
vrrp_instance VI_PROXYSQL {
interface eth0 # interface to monitor
state MASTER
virtual_router_id 51 # Assign one ID for this route
priority 100
unicast_src_ip 10.0.0.246
unicast_peer {
10.0.0.204
}
virtual_ipaddress {
10.0.0.100 # the virtual IP
}
track_script {
chk_proxysql
}
# notify /usr/local/bin/notify_keepalived.sh
}ClusterControl यूनीकास्ट के माध्यम से संचार करने के लिए VRRP इंस्टेंस को कॉन्फ़िगर करता है। यूनिकास्ट के साथ, हमें अन्य Keepalived नोड्स के सभी यूनिकास्ट साथियों को परिभाषित करना चाहिए। यह कम गतिशील है लेकिन ज्यादातर समय काम करता है। मल्टीकास्ट के साथ, आप उन पंक्तियों (यूनिकास्ट_*) को हटा सकते हैं और होस्ट डिस्कवरी और पीयरिंग के लिए मल्टीकास्ट आईपी एड्रेस पर भरोसा कर सकते हैं। यह आसान है लेकिन इसे आमतौर पर नेटवर्क व्यवस्थापकों द्वारा अवरुद्ध कर दिया जाता है।
अगला भाग वर्चुअल आईपी एड्रेस है। आप नई लाइन द्वारा अलग किए गए प्रति VRRP उदाहरण के लिए कई वर्चुअल IP पते निर्दिष्ट कर सकते हैं। एक ही समय में HAProxy/ProxySQL और Keepalived में लोड संतुलन के लिए भी गैर-स्थानीय आईपी पते से जुड़ने की क्षमता की आवश्यकता होती है, जिसका अर्थ है कि यह स्थानीय सिस्टम पर किसी डिवाइस को असाइन नहीं किया गया है। यह एक रनिंग लोड बैलेंसर इंस्टेंस को एक ऐसे आईपी से बाइंड करने की अनुमति देता है जो फेलओवर के लिए स्थानीय नहीं है। इस प्रकार ClusterControl net.ipv4.ip_nonlocal_bind=1 को भी कॉन्फ़िगर करता है अंदर /etc/sysctl.conf.
अगला निर्देश track_script . है , जहां आप स्वास्थ्य जांच प्रक्रिया के लिए स्क्रिप्ट निर्दिष्ट कर सकते हैं जिसे अगले भाग में समझाया गया है।
स्वास्थ्य जांच
ClusterControl Track_script द्वारा लौटाए गए त्रुटि कोड की जांच करके स्वास्थ्य जांच करने के लिए Keepalived को कॉन्फ़िगर करता है। Keepalived कॉन्फ़िगरेशन फ़ाइल में, जो डिफ़ॉल्ट रूप से /etc/keepalived/keepalived.conf पर स्थित है, आपको कुछ इस तरह दिखना चाहिए:
track_script {
chk_proxysql
}जहां यह chk_proxysql को कॉल करता है जिसमें शामिल हैं:
vrrp_script chk_proxysql {
script "killall -0 proxysql" # verify the pid existence
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}यदि होस्ट पर "प्रॉक्सीस्क्ल" नामक कोई प्रक्रिया चल रही है, तो "किलॉल -0" कमांड एग्जिट कोड 0 लौटाता है। अन्यथा, उदाहरण को खुद को अवनत करना होगा और अगले भाग में बताए गए अनुसार विफलता शुरू करना होगा। ध्यान दें कि Keepalived स्वास्थ्य जांच करने के लिए Linux वर्चुअल सर्वर (LVS) घटकों का भी समर्थन करता है, जहां यह HAProxy के समान, TCP/IP कनेक्शन को संतुलित करने में भी सक्षम है, लेकिन यह इस ब्लॉग पोस्ट के दायरे से बाहर है।
सिम्युलेटिंग फ़ेलओवर
VRRP घटकों के लिए, Keepalived VRRP उदाहरणों के बीच संचार करने के लिए VRRP प्रोटोकॉल (IP प्रोटोकॉल 112) का उपयोग करता है। मास्टर के उच्च प्राथमिकता वाले मान का मतलब है कि मास्टर को हमेशा वर्चुअल आईपी एड्रेस रखने का उच्च विशेषाधिकार होगा, जब तक कि आप "nopreempt" के साथ इंस्टेंस को कॉन्फ़िगर नहीं करते। आइए फ़ेलओवर और फ़ेलबैक फ़्लो को बेहतर ढंग से समझाने के लिए एक उदाहरण का उपयोग करें। निम्नलिखित आरेख पर विचार करें:
तीन MySQL Galera नोड्स के सामने तीन ProxySQL इंस्टेंस हैं। प्रत्येक ProxySQL होस्ट को निम्न प्राथमिकता संख्या के साथ मास्टर के रूप में Keepalived के साथ कॉन्फ़िगर किया गया है:
- ProxySQL1 - प्राथमिकता 101
- ProxySQL2 - प्राथमिकता 100
- ProxySQL3 - प्राथमिकता 99
जब Keepalived को मास्टर के रूप में शुरू किया जाता है, तो यह पहले सदस्यों को प्राथमिकता संख्या का विज्ञापन करेगा और फिर खुद को वर्चुअल आईपी पते से जोड़ देगा। बैकअप इंस्टेंस के विपरीत, यह केवल विज्ञापन का निरीक्षण करेगा और वर्चुअल आईपी एड्रेस को केवल तभी असाइन करेगा जब इसकी पुष्टि हो जाए कि यह खुद को मास्टर तक बढ़ा सकता है।
ध्यान दें कि यदि आप "प्रॉक्सीस्क्ल" या "हैप्रोक्सी" प्रक्रिया को किल कमांड के माध्यम से मैन्युअल रूप से मारते हैं, तो सिस्टमड प्रोसेस मैनेजर डिफ़ॉल्ट रूप से उस प्रक्रिया को पुनर्प्राप्त करने का प्रयास करेगा जिसे अनजाने में रोका जा रहा है। इसके अलावा, यदि आपके पास ClusterControl ऑटो रिकवरी चालू है, तो ClusterControl हमेशा प्रक्रिया शुरू करने का प्रयास करेगा, भले ही आप systemd (systemctl stop proxysql) के माध्यम से एक क्लीन शटडाउन करते हैं। विफलता का सर्वोत्तम अनुकरण करने के लिए, हम सुझाव देते हैं कि उपयोगकर्ता क्लस्टरकंट्रोल की स्वचालित पुनर्प्राप्ति सुविधा को बंद कर दें या संचार को तोड़ने के लिए बस प्रॉक्सीएसक्यूएल सर्वर को बंद कर दें।
यदि हम ProxySQL1 को बंद कर देते हैं, तो वर्चुअल IP पता अगले होस्ट पर विफल हो जाएगा जो उस विशेष समय पर उच्च प्राथमिकता रखता है (जो कि ProxySQL2 है):
आप विफल नोड के syslog में निम्नलिखित देखेंगे:
Feb 27 05:21:59 proxysql1 systemd: Unit proxysql.service entered failed state.
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: /usr/bin/killall -0 proxysql exited with status 1
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) failed
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 103 to 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 102, ours 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.सेकेंडरी नोड पर रहते हुए, निम्नलिखित हुआ:
Feb 27 05:22:00 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:22:01 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 avahi-daemon[346]: Registering new address record for 10.0.0.100 on eth0.IPv4.इस मामले में, फ़ेलओवर में लगभग 3 सेकंड का समय लगा, जिसमें अधिकतम फ़ेलओवर समय अंतराल . होगा + advert_int . परदे के पीछे, डेटाबेस समापन बिंदु बदल गया है और डेटाबेस ट्रैफ़िक को प्रॉक्सीएसक्यूएल2 के माध्यम से बिना किसी एप्लिकेशन को देखे रूट किया जा रहा है।
जब ProxySQL1 ऑनलाइन वापस आता है, तो यह एक नए मास्टर चुनाव के लिए बाध्य होगा और उच्च प्राथमिकता के कारण आईपी पते पर कब्जा कर लेगा:
Feb 27 05:38:34 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) succeeded
Feb 27 05:38:35 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 101 to 103
Feb 27 05:38:36 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:38:37 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 avahi-daemon[343]: Registering new address record for 10.0.0.100 on eth0.IPv4.उसी समय, ProxySQL2 स्वयं को बैकअप स्थिति में अवनत कर देता है और नेटवर्क इंटरफ़ेस से वर्चुअल IP पता हटा देता है:
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 103, ours 102
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.
Feb 27 05:38:36 proxysql2 avahi-daemon[346]: Withdrawing address record for 10.0.0.100 on eth0.इस बिंदु पर, ProxySQL1 ऑनलाइन वापस आ गया है और सक्रिय लोड बैलेंसर बन जाता है जो अनुप्रयोगों और क्लाइंट से कनेक्शन प्रदान करता है। जब उच्च प्राथमिकता वाला सर्वर ऑनलाइन आता है तो VRRP सामान्य रूप से कम प्राथमिकता वाले सर्वर को पहले से खाली कर देगा। यदि आप ProxySQL1 के ऑनलाइन वापस आने के बाद IP पता ProxySQL2 पर बने रहना चाहते हैं, तो "nopreempt" विकल्प का उपयोग करें। यह निम्न प्राथमिकता वाली मशीन को मास्टर भूमिका बनाए रखने की अनुमति देता है, तब भी जब उच्च प्राथमिकता वाली मशीन ऑनलाइन वापस आती है। हालांकि, इसके लिए काम करने के लिए, इस प्रविष्टि की प्रारंभिक स्थिति बैकअप होनी चाहिए। अन्यथा, आपको निम्न पंक्ति दिखाई देगी:
Feb 27 05:50:33 proxysql2 Keepalived_vrrp[6298]: (VI_PROXYSQL): Warning - nopreempt will not work with initial state MASTERचूंकि डिफ़ॉल्ट रूप से ClusterControl सभी नोड्स को मास्टर के रूप में कॉन्फ़िगर करता है, इसलिए आपको संबंधित VRRP इंस्टेंस के लिए निम्न कॉन्फ़िगरेशन विकल्प को तदनुसार कॉन्फ़िगर करना होगा:
vrrp_instance VI_PROXYSQL {
...
state BACKUP
nopreempt
...
}इन परिवर्तनों को लोड करने के लिए Keepalived प्रक्रिया को पुनरारंभ करें। वर्चुअल IP पता केवल ProxySQL1 या ProxySQL3 (प्राथमिकता के आधार पर और उस समय कौन सा नोड उपलब्ध है) पर विफल हो जाएगा यदि ProxySQL2 पर स्वास्थ्य जांच विफल हो जाती है। कई मामलों में, दो मेजबानों पर Keepalived चलाना पर्याप्त होगा।
