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

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

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

अधिकृत iSCSI कनेक्शन

यदि आपको iSCSI से कनेक्ट करते समय क्रेडिटयल को निर्दिष्ट करने की आवश्यकता होती है - तो Proxmox को दरकिनार करना बेहतर है। क्यों?

• सबसे पहले, क्योंकि Proxmox वेब इंटरफ़ेस के माध्यम से अधिकृत iSCSI कनेक्शन बनाना संभव नहीं है।
• दूसरे, भले ही आप मैन्युअल रूप से प्राधिकरण जानकारी निर्दिष्ट करने के लिए Proxmox में एक अनधिकृत कनेक्शन बनाने का निर्णय लेते हैं, आपको लक्ष्य कॉन्फ़िगरेशन फ़ाइलों को बदलने की क्षमता के लिए सिस्टम को बटना होगा, क्योंकि यदि आप iSCSI होस्ट से कनेक्ट करने में विफल रहते हैं, तो Proxmox लक्ष्य जानकारी को अधिलेखित कर देता है और कनेक्शन पुनः प्राप्त करता है।

मैन्युअल रूप से कनेक्ट करने के लिए आसान :

root@srv01-vmx:~# iscsiadm -m discovery -t st -p 10.11.12.13 root@srv01-vmx:~# iscsiadm -m node --targetname "iqn.2012-10.local.alawar.ala-nas-01:pve-cluster-01" --portal "10.11.12.13:3260" --op=update --name node.session.auth.authmethod --value=CHAP root@srv01-vmx:~# iscsiadm -m node --targetname "iqn.2012-10.local.alawar.ala-nas-01:pve-cluster-01" --portal "10.11.12.13:3260" --op=update --name node.session.auth.username --value=Admin root@srv01-vmx:~# iscsiadm -m node --targetname "iqn.2012-10.local.alawar.ala-nas-01:pve-cluster-01" --portal "10.11.12.13:3260" --op=update --name node.session.auth.password --value=Lu4Ii2Ai root@srv01-vmx:~# iscsiadm -m node --targetname "iqn.2012-10.local.alawar.ala-nas-01:pve-cluster-01" --portal "10.11.12.13:3260" --login 

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

नए GFS2-FS नोड पर बढ़ते

एक नए नोड पर GFS2- फाइल सिस्टम को माउंट करने के लिए, इसे ( फाइल सिस्टम ) एक और लॉग को जोड़ना होगा। यह निम्नानुसार किया जाता है: क्लस्टर के किसी भी नोड पर जिस पर हमें एफएस की आवश्यकता होती है, कमांड को निष्पादित किया जाता है:

 root@pve01:~# gfs2_jadd -j 1 /mnt/cluster/storage01 

" -J " पैरामीटर एफएस को जोड़ने के लिए लॉग की संख्या निर्दिष्ट करता है।

यह आदेश विफल हो सकता है:

 create: Disk quota exceeded 

त्रुटि के कारण:

GFS2 वॉल्यूम के अंदर वास्तव में एक फ़ाइल सिस्टम नहीं है, लेकिन दो हैं। एक अन्य फाइल सिस्टम व्यावसायिक उद्देश्यों के लिए है। यदि वांछित है, तो इसे " -o मेटा " विकल्प जोड़कर माउंट किया जा सकता है। इस FS के परिवर्तन से संभवतः डेटा फ़ाइल सिस्टम का विनाश हो सकता है। FS में लॉग जोड़ते समय, मेटा- फाइल सिस्टम को डायरेक्टरी " / tmp / TEMP_RANDOM_DIR " में माउंट किया जाता है, जिसके बाद इसमें एक लॉग फाइल बनाई जाती है। उन कारणों के लिए जो अभी भी हमारे लिए अस्पष्ट हैं, कर्नेल कभी-कभी यह मानता है कि ऑब्जेक्ट बनाने के लिए माउंटेड कोटा माउंटेड मेटा-एफएस से अधिक हो गया है, यही वजह है कि यह त्रुटि होती है। आप GFS2 को डेटा के साथ रिमूव करके इस स्थिति से बाहर निकल सकते हैं (निश्चित रूप से, इसके लिए आपको इस FS पर स्थित सभी वर्चुअल मशीनों को बंद करने की आवश्यकता है ) और ऐड लॉग कमांड को फिर से चलाएं। लॉग जोड़ने के अंतिम असफल प्रयास से मेटा-एफएस को अनमाउंट करना भी आवश्यक है:

 cat /proc/mounts | grep /tmp/ | grep -i gfs2 | awk '{print $2}' | xargs umount 

कंटेनर के अंदर डेटा स्रोत माउंट करना

कंटेनर वर्चुअलाइजेशन तकनीक अच्छा है क्योंकि मेजबान के पास वर्चुअल मशीन के साथ संचार करने की लगभग असीमित संभावनाएं हैं।

जब कंटेनर शुरू होता है, तो vzctl स्क्रिप्ट के निम्नलिखित सेट को निष्पादित करने की कोशिश करता है ( यदि कोई हो ):

• /etc/pve/openvz/vps.premount
• /etc/pve/openvz/CTID.premount
• /etc/pve/openvz/vps.mount
• /etc/pve/openvz/CTID.mount
• /etc/pve/openvz/CTID.start

जब रोका जाता है, तो निम्न स्क्रिप्ट निष्पादित होती हैं:

• /etc/pve/openvz/CTID.stop
• /etc/pve/openvz/CTID.umount
• /etc/pve/openvz/vps.umount
• /etc/pve/openvz/CTID.postumount
• /etc/pve/openvz/vps.postumount

जहां " CTID " कंटेनर नंबर है। " वीपीएस। * " लिपियों को किसी भी कंटेनर के साथ संचालन के दौरान निष्पादित किया जाता है। लिपियों " * .स्टार्ट " और " .स्टॉप " को कंटेनर के संदर्भ में निष्पादित किया जाता है, बाकी सभी मेजबान के संदर्भ में। इस प्रकार, हम कंटेनर की स्टार्ट / स्टॉप प्रक्रिया को डेटा माउंट करके जोड़ सकते हैं। यहाँ कुछ उदाहरण हैं:

कंटेनर के अंदर डेटा निर्देशिका माउंट करना

यदि कंटेनर बड़ी मात्रा में डेटा के साथ काम करता है, तो हम इस डेटा को कंटेनर के अंदर संग्रहीत नहीं करने का प्रयास करते हैं, लेकिन इसे होस्ट से माउंट करते हैं। इस दृष्टिकोण के दो सकारात्मक पहलू हैं:

1. कंटेनर छोटा है, जल्दी से प्रॉक्समॉक्स द्वारा समर्थित है। हमारे पास कंटेनर की कार्यक्षमता को जल्दी से बहाल करने / क्लोन करने का अवसर है।
2. कंटेनर डेटा को एक वयस्क बैकअप प्रणाली द्वारा प्रदान किया जा सकता है, इसके द्वारा प्रदान की जाने वाली सभी सुविधाओं के साथ (बहुस्तरीय बैकअप, रोटेशन, आंकड़े, और इसी तरह)।

फ़ाइल की सामग्री " CTID.mount ":

 #!/bin/bash . /etc/vz/vz.conf #        OpenVZ.  ,     ${VE_ROOT} -     . . ${VE_CONFFILE} #       DIR_SRC=/storage/src_dir #   ,      DIR_DST=/data #   ,     $DIR_SRC mkdir -p ${VE_ROOT}/${DIR_DST} #      mount -n -t simfs ${DIR_SRC} ${VE_ROOT}/{$DIR_DST} -o /data #     

कंटेनर के अंदर फ़ाइल सिस्टम को माउंट करना

मेजबान पर एक है जो कंटेनर को दिया जाना चाहिए। फ़ाइल की सामग्री " CTID.mount ":

 #!/bin/bash . /etc/vz/vz.conf . ${VE_CONFFILE} UUID_SRC=3d1d8ec1-afa6-455f-8a27-5465c454e212 # UUID ,      DIR_DST=/data mkdir -p ${VE_ROOT}/${DIR_DST} mount -n -U ${UUID_SRC} ${VE_ROOT}/{$DIR_DST} 

कंटेनर के अंदर फ़ाइल में फ़ाइल सिस्टम को माउंट करना

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

कंटेनर से फ़ाइल में लूप डिवाइस माउंट करें:

सबसे पहले, एक फ़ाइल बनाएँ:

 root@srv01:/storage# truncate -s 10G CTID_ext3.fs 

फ़ाइल में FS प्रारूपित करें:

 root@srv01:/storage# mkfs.ext3 CTID_ext3.fs mke2fs 1.42 (29-Nov-2011) CTID_ext3.fs is not a block special device. Proceed anyway? (y,n) y ... 

फ़ाइल की सामग्री " CTID.mount ":

 #!/bin/bash . /etc/vz/vz.conf . ${VE_CONFFILE} CFILE_SRC=/storage/CTID_ext3.fs #   ,      DIR_DST=/data mkdir -p ${VE_ROOT}/${DIR_DST} mount -n ${CFILE_SRC} -t ext3 ${VE_ROOT}/{$DIR_DST} -o loop 

रुकने पर कंटेनर में बाहरी डेटा को अनमाउंट करना

जब कंटेनर बंद हो जाता है, तो सिस्टम स्वचालित रूप से इससे जुड़े सभी फ़ाइल सिस्टम को अनमाउंट करने की कोशिश करता है। लेकिन विशेष रूप से विदेशी विन्यास में, वह ऐसा नहीं कर सकती। इसलिए, केवल मामले में, एक सरल स्क्रिप्ट " CTID.umount " का एक उदाहरण:

 #!/bin/bash . /etc/vz/vz.conf . ${VE_CONFFILE} DIR=/data if mountpoint -q "${VE_ROOT}${DIR}" ; then umount ${VE_ROOT}${DIR} fi 

एक गैर-क्लस्टर फ़ाइल सिस्टम के साथ क्लस्टर में कार्य करें

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

• प्रत्येक क्लस्टर नोड के लिए CLVM में अलग-अलग लॉजिकल वॉल्यूम
• नियमित कंटेनर संचालन के लिए प्राथमिक भंडारण
• अपनी विफलता / शटडाउन के मामले में एक विदेशी नोड वॉल्यूम के तत्काल बढ़ते के लिए खाली बैकअप भंडारण

प्रक्रिया:

CLVM में प्रत्येक क्लस्टर नोड की अपनी तार्किक मात्रा होती है, इसे प्रारूपित करें।

हम मुख्य भंडारण बनाते हैं। क्लस्टर के सभी नोड्स पर एक ही नाम के साथ एक निर्देशिका बनाएं ( उदाहरण के लिए, "/ संग्रहण" )। हम इसमें अपनी तार्किक मात्रा को बढ़ाते हैं। Proxmox व्यवस्थापक पैनल में, " निर्देशिका " प्रकार का एक भंडार बनाएं , इसे नाम दें, उदाहरण के लिए, " STORAGE ", और कहें कि यह साझा नहीं किया गया है।

बैकअप स्टोरेज बनाएं। क्लस्टर के सभी नोड्स पर एक ही नाम के साथ एक निर्देशिका बनाएं ( उदाहरण के लिए, "/ storage2" )। Proxmox व्यवस्थापक पैनल में, " निर्देशिका " प्रकार का एक भंडार बनाएं , इसे नाम दें, उदाहरण के लिए, " STORAGE2 ", और कहें कि यह साझा नहीं किया गया है। नोड्स में से एक के गिरने / बंद होने की स्थिति में, हम क्लस्टर के उस नोड पर " / संग्रहण 2 " निर्देशिका में इसकी मात्रा को माउंट करेंगे जो मृतक का बोझ उठाएगा ।

परिणामस्वरूप हमारे पास क्या है:

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

क्यों "के तहत ", और क्यों " सैद्धांतिक रूप से ":

वर्चुअल मशीनें " STORAGE " रिपॉजिटरी में रहती हैं, जो " / संग्रहण " निर्देशिका में स्थित है। मृत नोड से डिस्क को " / storage2 " निर्देशिका में माउंट किया जाएगा, जहां Proxmox कंटेनरों को देखेगा, लेकिन उन्हें वहां से शुरू करने में सक्षम नहीं होगा। इस स्टोरेज में स्थित वर्चुअल मशीनों को बढ़ाने के लिए, आपको तीन कार्य करने होंगे:

1. अग्नि पीड़ितों को सूचित करने के लिए कि उनका नया घर " भंडारण " निर्देशिका नहीं है, लेकिन / भंडारण 2 निर्देशिका है । ऐसा करने के लिए, प्रत्येक फ़ाइल " * .conf " निर्देशिका में " / etc / pve / nodes / dead_name / openvz ", " / संग्रहण / निजी / CTID " से VE_PRIVATE चर की सामग्री को " / संग्रहण 2 / निजी / CTID " में बदलें ।
2. क्लस्टर को बताएं कि उस निर्जीव नोड में से आभासी कंप्यूटर अब इस जीवित पर स्थित हैं। ऐसा करने के लिए, बस निर्देशिका से सभी फाइलें " / etc / pve / nodes / dead_name / openvz " को निर्देशिका " / etc / pve / nodes / live_node / openvz " में स्थानांतरित करें । शायद इसके लिए किसी प्रकार का सही API निर्देश है, लेकिन हमने इसके साथ परेशान नहीं किया है :)
3. प्रत्येक जले हुए कंटेनर के लिए कोटा रीसेट करें ( बस मामले में ):
   
   

    vzquota drop CTID 

   
   

वह सब है। आप कंटेनर चला सकते हैं।

यदि एक मृत नोड से कंटेनर थोड़ी जगह लेते हैं, या हमारे पास अविश्वसनीय रूप से तेज डिस्क हैं, या हम इंतजार कर सकते हैं, तो आप पहले और तीसरे चरण से बच सकते हैं, बस कंटेनर को " / भंडारण 2 / निजी " से " / भंडारण / निजी " की आवश्यकता होती है। "।

अगर क्लस्टर अलग हो गया

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

यदि क्लस्टर लीड को सफलता के लिए पुनर्जीवित करने का प्रयास नहीं किया जाता है, तो सबसे सरल बात यह है कि क्लस्टर के सभी नोड्स ( फ़ाइल "/ etc / default / redhat-क्लस्टर-pve" ) पर स्वचालित प्रविष्टि को बाड़ के डोमेन में अक्षम करें, और सभी नोड्स क्रमिक रूप से पुनरारंभ करें। हमें इस तथ्य के लिए तैयार रहना चाहिए कि नोड्स अपने दम पर रिबूट नहीं कर सकते हैं। जब सभी नोड्स को रिबूट किया जाता है, तो मैन्युअल रूप से बाड़ डोमेन से जुड़ते हैं, सीएलवीएम शुरू करते हैं, और इसी तरह। पिछले लेखों ने लिखा है कि यह कैसे करना है।

शायद यही सब है।

अगले भाग में मैं इस बारे में बात करूँगा कि हम क्लस्टर में कैसे काम को स्वचालित करते हैं।

आपका ध्यान के लिए धन्यवाद!

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