🥇व्यस्त परियोजनाओं में सेफ के साथ काम करने के लिए टिप्स और ट्रिक्स

विभिन्न भार वाली परियोजनाओं में नेटवर्क स्टोरेज के रूप में सेफ का उपयोग करते हुए, हमें विभिन्न कार्यों का सामना करना पड़ सकता है जो पहली नज़र में सरल या तुच्छ नहीं लगते हैं। उदाहरण के लिए:

नए क्लस्टर में पिछले सर्वर के आंशिक उपयोग के साथ पुराने सेफ से नए में डेटा का स्थानांतरण;
सेफ में डिस्क स्थान आवंटन की समस्या का समाधान।

ऐसी समस्याओं से निपटने के लिए, हमें डेटा खोए बिना ओएसडी को सही ढंग से हटाने की आवश्यकता का सामना करना पड़ता है, जो बड़ी मात्रा में डेटा से निपटने के दौरान विशेष रूप से महत्वपूर्ण है। इस पर लेख में चर्चा की जाएगी।

नीचे वर्णित विधियाँ सेफ के किसी भी संस्करण के लिए प्रासंगिक हैं। इसके अलावा, इस तथ्य को ध्यान में रखा जाएगा कि सेफ बड़ी मात्रा में डेटा संग्रहीत कर सकता है: डेटा हानि और अन्य समस्याओं को रोकने के लिए, कुछ कार्यों को कई अन्य में "विभाजित" किया जाएगा।

ओएसडी के बारे में प्रस्तावना

चूंकि चर्चा की गई तीन में से दो रेसिपी ओएसडी को समर्पित हैं (ऑब्जेक्ट स्टोरेज डेमॉन), व्यावहारिक भाग में गोता लगाने से पहले - संक्षेप में यह सेफ में क्या है और यह इतना महत्वपूर्ण क्यों है।

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

समान स्तर पर, विभिन्न ओएसडी के बीच ऑब्जेक्ट की प्रतिलिपि बनाकर प्रतिकृति पैरामीटर सेट किए जाते हैं। और यहां आप विभिन्न समस्याओं का सामना कर सकते हैं, जिनके समाधान पर नीचे चर्चा की जाएगी।

केस नंबर 1. डेटा खोए बिना सेफ क्लस्टर से ओएसडी को सुरक्षित रूप से हटाएं

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

सुविधा के लिए और ऐसी स्थिति से बचने के लिए, जहां कमांड निष्पादित करते समय, हम आवश्यक ओएसडी को इंगित करने में गलती करते हैं, हम एक अलग वेरिएबल सेट करेंगे, जिसका मान हटाए जाने वाले ओएसडी की संख्या होगी। चलो उसे बुलाते हैं ${ID} - यहां और नीचे, ऐसा वैरिएबल उस ओएसडी की संख्या को प्रतिस्थापित करता है जिसके साथ हम काम कर रहे हैं।

आइए काम शुरू करने से पहले स्थिति पर नजर डालें:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

ओएसडी हटाने की शुरुआत करने के लिए, आपको सुचारू रूप से कार्य करने की आवश्यकता होगी reweight उस पर शून्य. इस तरह हम ओएसडी में डेटा की मात्रा को अन्य ओएसडी के साथ संतुलित करके कम कर देते हैं। ऐसा करने के लिए, निम्नलिखित आदेश चलाएँ:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

...और इसी तरह शून्य तक।

सहज संतुलन आवश्यक हैताकि डेटा न खोए। यह विशेष रूप से सच है यदि ओएसडी में बड़ी मात्रा में डेटा हो। यह सुनिश्चित करने के लिए कि आदेशों को निष्पादित करने के बाद reweight सब कुछ ठीक रहा, आप इसे पूरा कर सकते हैं ceph -s या एक अलग टर्मिनल विंडो में चलाएं ceph -w वास्तविक समय में परिवर्तनों का निरीक्षण करने के लिए।

जब ओएसडी "खाली" हो जाता है, तो आप इसे हटाने के लिए मानक ऑपरेशन के साथ आगे बढ़ सकते हैं। ऐसा करने के लिए, वांछित ओएसडी को राज्य में स्थानांतरित करें down:

ceph osd down osd.${ID}

आइए OSD को क्लस्टर से बाहर "खींचें":

ceph osd out osd.${ID}

आइए OSD सेवा को रोकें और FS में इसके विभाजन को अनमाउंट करें:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

ओएसडी को यहां से हटाएं क्रश मानचित्र:

ceph osd crush remove osd.${ID}

आइए OSD उपयोगकर्ता को हटाएं:

ceph auth del osd.${ID}

और अंत में, आइए OSD को ही हटा दें:

ceph osd rm osd.${ID}

नोट: यदि आप सेफ ल्यूमिनस संस्करण या उच्चतर का उपयोग कर रहे हैं, तो उपरोक्त ओएसडी हटाने के चरणों को दो कमांड तक कम किया जा सकता है:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

यदि, ऊपर वर्णित चरणों को पूरा करने के बाद, आप कमांड चलाते हैं ceph osd tree, तो यह स्पष्ट होना चाहिए कि जिस सर्वर पर काम किया गया था, वहां अब कोई ओएसडी नहीं है जिसके लिए उपरोक्त ऑपरेशन किए गए थे:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

रास्ते में, ध्यान दें कि सेफ़ क्लस्टर की स्थिति पर जाएँ HEALTH_WARN, और हम ओएसडी की संख्या और उपलब्ध डिस्क स्थान की मात्रा में भी कमी देखेंगे।

निम्नलिखित उन चरणों का वर्णन करेगा जिनकी आवश्यकता होगी यदि आप सर्वर को पूरी तरह से बंद करना चाहते हैं और तदनुसार, इसे सेफ से हटा दें। ऐसे में यह याद रखना जरूरी है सर्वर बंद करने से पहले, आपको सभी ओएसडी को हटाना होगा इस सर्वर पर.

यदि इस सर्वर पर कोई और OSD नहीं बचे हैं, तो उन्हें हटाने के बाद आपको सर्वर को OSD मैप से बाहर करना होगा hv-2निम्नलिखित आदेश चलाकर:

ceph osd crush rm hv-2

मिटाना mon सर्वर से hv-2नीचे दिए गए आदेश को किसी अन्य सर्वर पर चलाकर (अर्थात इस मामले में, चालू)। hv-1):

ceph-deploy mon destroy hv-2

इसके बाद, आप सर्वर को बंद कर सकते हैं और बाद की कार्रवाइयां (इसे फिर से तैनात करना, आदि) शुरू कर सकते हैं।

केस नंबर 2. पहले से निर्मित सेफ़ क्लस्टर में डिस्क स्थान का वितरण

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

तो: सेफ का उपयोग करते समय आम समस्याओं में से एक सेफ में पूल के बीच ओएसडी और पीजी की असंतुलित संख्या है।

सबसे पहले, इस वजह से, ऐसी स्थिति उत्पन्न हो सकती है जब एक छोटे पूल में बहुत सारे पीजी निर्दिष्ट किए जाते हैं, जो अनिवार्य रूप से क्लस्टर में डिस्क स्थान का एक तर्कहीन उपयोग है। दूसरे, व्यवहार में एक अधिक गंभीर समस्या है: किसी एक ओएसडी में डेटा अतिप्रवाह। इसमें क्लस्टर को पहले राज्य में स्थानांतरित करना शामिल है HEALTH_WARNऔर फिर HEALTH_ERR. इसका कारण यह है कि सेफ, उपलब्ध डेटा की मात्रा की गणना करते समय (आप इसका पता लगा सकते हैं MAX AVAIL कमांड आउटपुट में ceph df प्रत्येक पूल के लिए अलग से) ओएसडी में उपलब्ध डेटा की मात्रा पर आधारित है। यदि कम से कम एक ओएसडी में पर्याप्त जगह नहीं है, तो कोई और डेटा तब तक नहीं लिखा जा सकता जब तक कि डेटा सभी ओएसडी के बीच ठीक से वितरित न हो जाए।

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

तो, आइए निम्नलिखित चित्र की कल्पना करें: क्लस्टर की एक स्थिति है HEALTH_WARN एक OSD का स्थान समाप्त हो जाने के कारण। यह एक त्रुटि द्वारा दर्शाया जाएगा HEALTH_WARN: 1 near full osd. इस स्थिति से बाहर निकलने के लिए नीचे एक एल्गोरिदम दिया गया है।

सबसे पहले, आपको उपलब्ध डेटा को शेष ओएसडी के बीच वितरित करना होगा। हमने पहले मामले में पहले से ही एक समान ऑपरेशन किया था, जब हमने नोड को "सूखा" किया था - केवल इस अंतर के साथ कि अब हमें इसे थोड़ा कम करने की आवश्यकता होगी reweight. उदाहरण के लिए, 0.95 तक:

ceph osd reweight osd.${ID} 0.95

यह ओएसडी में डिस्क स्थान खाली कर देता है और सेफ स्वास्थ्य में त्रुटि को ठीक कर देता है। हालाँकि, जैसा कि पहले ही उल्लेख किया गया है, यह समस्या मुख्य रूप से प्रारंभिक चरणों में सेफ के गलत कॉन्फ़िगरेशन के कारण होती है: पुन: कॉन्फ़िगरेशन करना बहुत महत्वपूर्ण है ताकि यह भविष्य में प्रकट न हो।

हमारे विशेष मामले में, यह सब नीचे आया:

मूल्य बहुत अधिक है replication_count एक तालाब में,
एक पूल में बहुत अधिक पीजी और दूसरे में बहुत कम।

आइए पहले से बताए गए कैलकुलेटर का उपयोग करें। यह स्पष्ट रूप से दिखाता है कि क्या दर्ज करने की आवश्यकता है और, सिद्धांत रूप में, कुछ भी जटिल नहीं है। आवश्यक पैरामीटर सेट करने के बाद, हमें निम्नलिखित सिफारिशें मिलती हैं:

नोट: यदि आप स्क्रैच से सेफ क्लस्टर स्थापित कर रहे हैं, तो कैलकुलेटर का एक अन्य उपयोगी कार्य कमांड की पीढ़ी है जो तालिका में निर्दिष्ट मापदंडों के साथ स्क्रैच से पूल बनाएगा।

अंतिम कॉलम आपको नेविगेट करने में मदद करता है - सुझाई गई पीजी गणना. हमारे मामले में, दूसरा भी उपयोगी है, जहां प्रतिकृति पैरामीटर इंगित किया गया है, क्योंकि हमने प्रतिकृति गुणक को बदलने का निर्णय लिया है।

तो, सबसे पहले आपको प्रतिकृति मापदंडों को बदलने की आवश्यकता है - यह पहले करने लायक है, क्योंकि गुणक को कम करके, हम डिस्क स्थान खाली कर देंगे। जैसे ही कमांड निष्पादित होगी, आप देखेंगे कि उपलब्ध डिस्क स्थान बढ़ जाएगा:

ceph osd pool $pool_name set $replication_size

और इसके पूरा होने के बाद, हम पैरामीटर मान बदलते हैं pg_num и pgp_num निम्नानुसार है:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

यह महत्वपूर्ण है: हमें प्रत्येक पूल में क्रमिक रूप से पीजी की संख्या बदलनी चाहिए और चेतावनियां गायब होने तक अन्य पूलों में मूल्यों को नहीं बदलना चाहिए "अपघटित डेटा अतिरेक" и "पीजीएस की एन-संख्या ख़राब".

आप कमांड आउटपुट का उपयोग करके यह भी जांच सकते हैं कि सब कुछ ठीक रहा ceph health detail и ceph -s.

केस नंबर 3. वर्चुअल मशीन को LVM से Ceph RBD में माइग्रेट करना

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

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

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

चलिए व्यावहारिक भाग पर चलते हैं। उदाहरण में हम virsh और, तदनुसार, libvirt का उपयोग करते हैं। सबसे पहले, सुनिश्चित करें कि जिस सेफ पूल में डेटा माइग्रेट किया जाएगा वह libvirt से जुड़ा है:

virsh pool-dumpxml $ceph_pool

पूल विवरण में प्राधिकरण डेटा के साथ सेफ से कनेक्शन डेटा होना चाहिए।

अगला चरण यह है कि LVM छवि को Ceph RBD में परिवर्तित किया जाता है। निष्पादन का समय मुख्य रूप से छवि के आकार पर निर्भर करता है:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

रूपांतरण के बाद, एक LVM छवि बनी रहेगी, जो तब उपयोगी होगी जब VM को RBD में माइग्रेट करना विफल हो जाता है और आपको परिवर्तनों को वापस लाना होगा। इसके अलावा, परिवर्तनों को तुरंत वापस लाने में सक्षम होने के लिए, आइए वर्चुअल मशीन कॉन्फ़िगरेशन फ़ाइल का बैकअप बनाएं:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... और मूल संपादित करें (vm_name.xml). आइए डिस्क के विवरण के साथ एक ब्लॉक ढूंढें (लाइन से शुरू होता है <disk type='file' device='disk'> और के साथ समाप्त होता है </disk>) और इसे निम्न रूप में घटाएं:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

आइए कुछ विवरण देखें:

प्रोटोकॉल को source सेफ आरबीडी में भंडारण का पता दर्शाया गया है (यह सेफ पूल और आरबीडी छवि का नाम दर्शाने वाला पता है, जो पहले चरण में निर्धारित किया गया था)।
ब्लॉक में secret प्रकार दर्शाया गया है ceph, साथ ही इससे जुड़ने के रहस्य का यूयूआईडी भी। इसका uuid कमांड का उपयोग करके पाया जा सकता है virsh secret-list.
ब्लॉक में host सेफ़ मॉनिटरों के पते दर्शाए गए हैं।

कॉन्फ़िगरेशन फ़ाइल को संपादित करने और LVM से RBD रूपांतरण पूरा करने के बाद, आप संशोधित कॉन्फ़िगरेशन फ़ाइल लागू कर सकते हैं और वर्चुअल मशीन शुरू कर सकते हैं:

virsh define $vm_name.xml
virsh start $vm_name

यह जांचने का समय आ गया है कि वर्चुअल मशीन सही ढंग से शुरू हुई है: उदाहरण के लिए, आप इसे एसएसएच के माध्यम से या इसके माध्यम से कनेक्ट करके पता लगा सकते हैं virsh.

यदि वर्चुअल मशीन सही ढंग से काम कर रही है और आपको कोई अन्य समस्या नहीं मिली है, तो आप उस LVM छवि को हटा सकते हैं जिसका अब उपयोग नहीं किया जाता है:

lvremove main/$vm_image_name

निष्कर्ष

हमने अभ्यास में सभी वर्णित मामलों का सामना किया - हमें उम्मीद है कि निर्देश अन्य प्रशासकों को समान समस्याओं को हल करने में मदद करेंगे। यदि आपके पास सेफ का उपयोग करने के अपने अनुभव पर टिप्पणियाँ या अन्य समान कहानियाँ हैं, तो हमें उन्हें टिप्पणियों में देखकर खुशी होगी!

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

स्रोत: www.habr.com

व्यस्त परियोजनाओं में सेफ के साथ काम करने के लिए टिप्स और ट्रिक्स