🧢 😘 👏🏻 Proxmox में क्लस्टर स्टोरेज। भाग एक बाड़ लगाना 🧘🏼 🤦🏼 🙉

आपका स्वागत है!

मैं इस बारे में बात करना चाहता हूं कि हम कैसे प्रॉक्समोक्स वर्चुअल एनवायरनमेंट का उपयोग करते हैं।

मैं इंस्टॉलेशन और प्रारंभिक कॉन्फ़िगरेशन का वर्णन नहीं करूंगा - प्रोक्समॉक्स स्थापित करने और कॉन्फ़िगर करने के लिए बहुत सरल और सुखद है। हम इस बारे में बात करेंगे कि हम क्लस्टर वातावरण में सिस्टम का उपयोग कैसे करते हैं।

क्लस्टर को ठीक से काम करने के लिए, यह आवश्यक है कि क्लस्टर के वर्चुअल होस्ट वर्चुअल मशीन को जल्दी से नियंत्रित कर सकें। वर्चुअल मशीनों के डेटा को कहीं भी कॉपी नहीं किया जाना चाहिए। यही है, सभी क्लस्टर होस्ट के पास किसी विशेष मशीन के डेटा तक पहुंच होनी चाहिए, या, दूसरे शब्दों में, सभी क्लस्टर होस्ट को एक एकल डेटा स्टोर के साथ काम करना होगा, जिसके भीतर वर्चुअल मशीनों का एक विशिष्ट सेट काम करता है।

प्रॉक्समोक्स दो प्रकार के वर्चुअलाइजेशन के साथ काम करता है: ऑपरेटिंग सिस्टम स्तर, ओपनवीजेड और केवीएम पर आधारित हार्डवेयर। ये दो प्रकार डिस्क उपयोग के लिए एक अलग दृष्टिकोण का उपयोग करते हैं। यदि OpenVZ- के मामले में, वर्चुअल मशीन डिस्क के साथ काम मेजबान फ़ाइल सिस्टम स्तर पर किया जाता है, तो KVM- मशीनों के मामले में, वर्चुअल मशीन के स्वयं के फ़ाइल सिस्टम वाले डिस्क छवि का उपयोग किया जाता है। होस्ट ऑपरेटिंग सिस्टम केवीएम ड्राइव के अंदर डेटा रखने के बारे में परवाह नहीं करता है। हाइपरवाइजर यही करता है। क्लस्टर के संचालन को व्यवस्थित करते समय, फ़ाइल सिस्टम के साथ काम करने की तुलना में डिस्क छवियों के साथ विकल्प को आसान तरीके से लागू किया जाता है। होस्ट ऑपरेटिंग सिस्टम के दृष्टिकोण से KVM मशीन डेटा केवल रिपॉजिटरी में " कहीं " स्थित हो सकता है। यह अवधारणा LVM योजना पर अच्छी तरह से फिट बैठती है जब KVM डिस्क की छवि तार्किक आयतन के अंदर होती है।

OpenVZ के मामले में , हम एक फ़ाइल सिस्टम के साथ काम कर रहे हैं, न कि साझा संग्रहण पर केवल डेटा क्षेत्र। हमें एक पूर्ण क्लस्टर फ़ाइल सिस्टम की आवश्यकता है।

आलेख के इस भाग में क्लस्टर फ़ाइल सिस्टम पर चर्चा नहीं की जाएगी। केवीएम के साथ काम करने के बारे में भी। अब हम साझा भंडारण के साथ काम करने के लिए क्लस्टर तैयार करने के बारे में बात करेंगे।

मैं तुरंत कहना चाहता हूं कि हम क्लस्टर को एक वाणिज्यिक भार नहीं देते हैं, और हम योजना नहीं बनाते हैं। प्रणाली का उपयोग आंतरिक आवश्यकताओं के लिए किया जाता है, जो हमारे पास प्रचुर मात्रा में है। जैसा कि मैंने पिछले लेख में लिखा था, हम धीरे-धीरे कार्यभार को vCloud में स्थानांतरित कर रहे हैं, और उपलब्ध क्षमताओं पर प्रोक्समॉक्स को तैनात कर रहे हैं।

हमारे मामले में, एक साझा भंडार के आयोजन की समस्या दो पहलुओं के लिए नीचे आती है:

हमारे पास नेटवर्क पर वितरित एक ब्लॉक डिवाइस है, जिसमें कई होस्ट एक साथ एक्सेस करेंगे। इन मेजबानों को डिवाइस पर जगह के लिए नहीं लड़ने के लिए, हमें CLVM - क्लस्टर्ड लॉजिकल वॉल्यूम मैनेजर की आवश्यकता है । यह LVM के समान है, केवल Clustered है । CLVM के लिए धन्यवाद , प्रत्येक होस्ट के पास साझा संग्रहण पर LVM संस्करणों की स्थिति के बारे में नवीनतम जानकारी होती है ( और इसे ईमानदारी से समझौता किए बिना सुरक्षित रूप से बदल सकते हैं )। CLVM में लॉजिकल वॉल्यूम नियमित LVM की तरह ही रहते हैं। तार्किक वॉल्यूम में केवीएम चित्र या क्लस्टर एफएस होते हैं ।
OpenVZ के मामले में, हमारे पास तार्किक आयतन है, जिस पर फ़ाइल सिस्टम स्थित है। एक गैर-क्लस्टर फ़ाइल सिस्टम के साथ कई मशीनों का एक साथ संचालन सब कुछ के संचालन में अपरिहार्य त्रुटियों की ओर जाता है - यह एक हंस, कैंसर और पाईक है, केवल बदतर। फ़ाइल सिस्टम को पता होना चाहिए कि यह एक साझा संसाधन पर रहता है, और इस मोड में काम करने में सक्षम है।

एक क्लस्टर बनाना और इसे नोड्स कनेक्ट करना, मैं वर्णन नहीं करूंगा। यह डेवलपर्स वेबसाइट पर , उदाहरण के लिए पढ़ा जा सकता है। वैसे, उनका ज्ञान आधार काफी व्यापक और ज्ञानवर्धक है ।

हम Proxmox संस्करण 2.2 के साथ काम कर रहे हैं। हम मानते हैं कि हमारा क्लस्टर कॉन्फ़िगर किया गया है, और यह काम करता है।

हम फ़ेंस किए गए डेमन को कॉन्फ़िगर करेंगे

क्लस्टर वातावरण की विशिष्टता को व्यवहार के कुछ नियमों का पालन करने के लिए क्लस्टर के नोड्स की आवश्यकता होती है। आप इसे नहीं ले सकते और डिवाइस पर लिखना शुरू कर सकते हैं। पहले आपको अनुमति मांगने की आवश्यकता है। कई क्लस्टर सबसिस्टम इसकी निगरानी में शामिल हैं - सीएमएएन ( क्लस्टर मैनेजर ), डीएलएम ( डिस्ट्रीब्यूटेड लॉक मैनेजर ) और फेंस । एक फैंका हुआ डेमन बाउंसर का काम करता है। यदि, क्लस्टर के दृष्टिकोण से, एक नोड अनुचित तरीके से व्यवहार करना शुरू कर देता है - क्लस्टर में भंडारण के साथ संचार होता है, और बाड़ क्लस्टर से विफल नोड को डिस्कनेक्ट करने का प्रयास करता है।

फेंसिंग क्लस्टर भंडारण के साथ काम करने से एक नोड को खत्म करने की प्रक्रिया है। चूंकि एक अपर्याप्त मशीन एक अच्छे तरीके से छोड़ने के अनुरोधों का जवाब नहीं दे सकती है, नोड को क्लस्टर में बाहरी बलों का उपयोग करके मिटा दिया जाता है। इन बलों के साथ संवाद करने के लिए, ~~पुजारी~~ विशेष रूप से प्रशिक्षित बाड़ एजेंटों का उपयोग करते हैं। एक नियम के रूप में, नोड्स को डी-एनर्जेट करने के लिए बाड़ लगाया जाता है, जिसके बाद क्लस्टर एक सांस लेता है और काम फिर से शुरू करता है।

बाहरी बल कोई भी उपकरण हो सकता है जो सिग्नल के साथ ~~बैरल~~ को ~~बंद करने~~ या मशीन को नेटवर्क से अलग करने में सक्षम हो। ज्यादातर अक्सर, ऐसे उपकरण औद्योगिक बिजली की आपूर्ति या सर्वर प्रबंधन कंसोल होते हैं। हम अपने स्थान पर एचपी उपकरण का उपयोग करते हैं। आईएलओ कार्ड का उपयोग करके बाड़ लगाया जाता है।

जब तक फैंस डेमॉन को एजेंट से इस बात की पुष्टि नहीं हो जाती कि नोड सफलतापूर्वक " फ़ेंस " किया गया है, क्लस्टर में सभी I / O ऑपरेशन निलंबित हो जाएंगे। यह भंडारण में डेटा भ्रष्टाचार के जोखिम को कम करने के लिए किया जाता है। चूंकि एक विफल नोड व्यवहार के आम तौर पर स्वीकार किए गए नियमों का पालन करना बंद कर दिया है, कुछ भी इससे उम्मीद की जा सकती है। उदाहरण के लिए, डिस्क पर अनधिकृत ( और लॉग नहीं ) रिकॉर्डिंग करने का प्रयास। इसलिए, इस स्थिति में भंडार के साथ किसी भी संचार से डेटा भ्रष्टाचार का खतरा बढ़ जाता है।

यदि नोड के लिए बाड़ एजेंट को कॉन्फ़िगर नहीं किया गया है, तो फ़ाइंड समस्याओं के मामले में इसे किक करने में सक्षम नहीं होगा, और जब तक स्थिति हल नहीं होती तब तक क्लस्टर जमे हुए राज्य में रहेगा। इस स्थिति में, घटनाओं के आगे विकास के लिए कई परिदृश्य हैं:

नोडा अपने होश में आ सकता है, क्लस्टर में वापस आ सकता है और कह सकता है कि अब ऐसा नहीं होगा। उसे जाने दिया जाएगा, और क्लस्टर फिर से शुरू किया जाएगा।
नोड रिबूट हो सकता है ( या कोई इसे रीबूट करेगा ), और क्लस्टर में शामिल होने के लिए कहा जाएगा। क्लस्टर से जुड़ने के एक नए प्रयास के तथ्य को एक संकेत माना जाता है कि नोड स्वस्थ है, और आप काम करना जारी रख सकते हैं।
नोड मर सकता है। इस स्थिति में मैन्युअल हस्तक्षेप की आवश्यकता होती है। आपको यह सना हुआ डेमॉन को स्पष्ट करने की आवश्यकता है कि क्लस्टर भंडारण के साथ काम करना फिर से शुरू कर सकता है, क्योंकि नोड अब कोई खतरा नहीं है। और सामान्य तौर पर, शायद वह वापस नहीं आया। इस उद्देश्य के लिए " बाड़_बैक_मानसिक " नामक एक उपयोगिता है। इस मामले में, ऑपरेटर क्लस्टर को फिर से शुरू करने पर निर्णय लेने की जिम्मेदारी लेता है।

यदि होस्ट सामान्य मोड में अपना काम पूरा करता है, तो वह बस बाड़ डोमेन से खुद को हटाने के लिए कहता है, जिसके बाद वह रिपॉजिटरी के साथ संवाद करने की क्षमता खो देता है।

क्लस्टर डोमेन का उपयोग करके साझा भंडारण के साथ किसी भी संचालन के लिए बाड़ डोमेन में एक मेजबान की उपस्थिति एक शर्त है।

" बाड़-ओलो " एजेंट का उपयोग करके fenced कॉन्फ़िगरेशन पर विचार करें ( कॉन्फ़िगरेशन क्लस्टर के प्रत्येक नोड पर किया जाता है ):

फ़ाइल / etc / default / redhat-क्लस्टर-pve सेट में

FENCE_JOIN="yes"

अब, जब सिस्टम शुरू होता है, तो नोड बाड़ के डोमेन से जुड़ जाएगा। हम रिबूट नहीं करना चाहते हैं, इसलिए हम नोड को डोमेन से मैन्युअल रूप से जोड़ते हैं:

 root@srv03-vmx-02:~# fence_tool join

आप इस तरह से सना हुआ डेमन की स्थिति देख सकते हैं:

 root@srv03-vmx-02:~# fence_tool ls fence domain member count 4 victim count 0 victim now 0 master nodeid 1 wait state none members 1 2 3 4

परीक्षण बाड़-एजेंट

आईएलओ के विभिन्न संस्करणों के लिए अलग-अलग एजेंट हैं:

 root@tpve01:~# fence_ilo fence_ilo fence_ilo2 fence_ilo3 fence_ilo_mp

शुरू करने के लिए - हम iLO के माध्यम से हमारे लिए ब्याज की नोड की स्थिति के साथ पूछताछ करेंगे:

 root@tpve01:~# fence_ilo -a ILO_IP -l LOGIN -p PASSWORD -o status Status: ON

स्थिति: चालू । " -O स्थिति " के बजाय आप " -o रिबूट " कह सकते हैं। परीक्षण मशीन को पॉडी का एक रीसेट प्राप्त होगा।

उसी तरह, हम सभी नोड्स पर आईएलओ के प्रदर्शन की जांच करते हैं।

अब बाड़ एजेंटों के सही काम के लिए क्लस्टर को कॉन्फ़िगर करें। Proxmox में फैंसले लगाने के बारे में एक अच्छा लेख है , और मैं यहां नहीं लिखूंगा कि वहां क्या लिखा गया है, मैं केवल हमारे क्लस्टर का अंतिम विन्यास दूंगा:

 root@tpve01:~# cat /etc/pve/cluster.conf.new <?xml version="1.0"?> <cluster name="tpve" config_version="5"> <cman keyfile="/var/lib/pve-cluster/corosync.authkey"> </cman> <fencedevices> <fencedevice agent="fence_ilo" ipaddr="IP_ILO_TPVE01" name="tpve01" passwd_script="/usr/local/pvesync/ilo_pass/tpve01" login="LOGIN"/> <fencedevice agent="fence_ilo" ipaddr="IP_ILO_TPVE02" name="tpve02" passwd_script="/usr/local/pvesync/ilo_pass/tpve02" login="LOGIN"/> </fencedevices> <clusternodes> <clusternode name="tpve01" votes="1" nodeid="1"> <fence> <method name="power"> <device name="tpve01"/> </method> </fence> </clusternode> <clusternode name="tpve02" votes="1" nodeid="2"> <fence> <method name="power"> <device name="tpve02"/> </method> </fence> </clusternode> <clusternode name="tpve03" votes="1" nodeid="3"/> </clusternodes> </cluster>

हमारे उदाहरण में, tpve03 नोड में एक बाड़ एजेंट कॉन्फ़िगर नहीं है, और यदि इसके साथ कोई समस्या है, तो संघर्ष को मैन्युअल रूप से हल करना होगा।

पासवर्ड में iLO पासवर्ड को चमकाने के लिए नहीं, पासवर्ड के बजाय, एजेंट सेटिंग्स में पैरामीटर निर्दिष्ट किया गया है

 passwd_script="/usr/local/pvesync/ilo_pass/tpve01"

यह स्क्रिप्ट का मार्ग है जो पासवर्ड जारी करता है। स्क्रिप्ट आदिम है:

 root@tpve01:~# cat /usr/local/pvesync/ilo_pass/tpve01 #!/bin/bash echo "DERPAROL"

ये स्क्रिप्ट क्लस्टर के सभी नोड्स पर मौजूद होनी चाहिए।

क्लस्टर कॉन्फ़िगरेशन में सभी परिवर्तन किए गए हैं और मान्य होने के बाद , हम अपने कॉन्फ़िगरेशन का उपयोग करते हैं। Proxmox वेब इंटरफ़ेस में , हा सेटिंग्स पर जाएं और " सक्रिय करें " कहें। यदि सब कुछ त्रुटियों के बिना हुआ, और क्लस्टर कॉन्फ़िगरेशन सीरियल नंबर बढ़ाया गया था, तो परिवर्तन प्रभावी होंगे, और आप नोड्स को पुश करने का प्रयास कर सकते हैं। सामान्य तौर पर, यह अत्यधिक अनुशंसा की जाती है कि प्रत्येक क्लस्टर नोड को यह सुनिश्चित करने के लिए फेंस किया जाए कि सब कुछ वास्तव में काम करता है।

शुरू करने के लिए, अपने हाथों से नोड को मारें:

 root@tpve01:~# fence_node tpve02 fence tpve02 success

नोदा ने रीसेट पकड़ा।

अब समस्या का अनुकरण करने का प्रयास करें। नोड्स में से एक पर हम नेटवर्क इंटरफ़ेस जोड़ते हैं जिसके माध्यम से क्लस्टर नोड्स एक दूसरे के साथ संवाद करते हैं:

 root@tpve02:~# ifdown vmbr0

लाइव नोड पर कुछ समय के बाद, फंसे डेमॉन की स्थिति का एक स्कैन निम्नलिखित दिखाएगा:

 root@tpve01:~# fence_tool ls fence domain member count 2 victim count 1 victim now 2 master nodeid 1 wait state fencing members 1 2 3

" वेट स्टेट फेंसिंग " का अर्थ है कि अभी क्लस्टर से समस्या नोड का अपवाद हो रहा है, और फैंस डेमॉन बाड़ एजेंट से समाचार की प्रतीक्षा कर रहे हैं।

एजेंट से पुष्टि प्राप्त करने के बाद:

 root@tpve01:~# fence_tool ls fence domain member count 2 victim count 0 victim now 0 master nodeid 1 wait state none members 1 3

नोदा को मार दिया गया, हम काम कर रहे हैं।

जब नोड बढ़ जाता है, तो यह क्लस्टर से जुड़ जाएगा।

अब हमारा क्लस्टर साझा भंडारण के साथ काम करने के लिए तैयार है।

शायद हम वहीं रुक जाएंगे। अगले लेख में, जो जारी किया जाएगा, जाहिरा तौर पर, पहले से ही जनवरी में, मैं भंडारण को जोड़ने और इसके साथ काम करने के बारे में बात करूंगा।

Proxmox में क्लस्टर स्टोरेज। भाग एक बाड़ लगाना
Proxmox में क्लस्टर स्टोरेज। भाग दो लांच
Proxmox में क्लस्टर स्टोरेज। भाग तीन बारीकियों

Proxmox में क्लस्टर स्टोरेज। भाग एक बाड़ लगाना

हम फ़ेंस किए गए डेमन को कॉन्फ़िगर करेंगे

परीक्षण बाड़-एजेंट

More articles: