व्यस्त परियोजनाहरूमा Ceph सँग काम गर्नका लागि सुझाव र युक्तिहरू

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

• नयाँ क्लस्टरमा अघिल्लो सर्भरहरूको आंशिक प्रयोगको साथ पुरानो Ceph बाट नयाँ डेटा माइग्रेसन;
• Ceph मा डिस्क स्थान आवंटन को समस्या को समाधान।

त्यस्ता समस्याहरूको सामना गर्दै, हामीले डाटा नगुमाईकन OSD लाई सही रूपमा हटाउने आवश्यकताको सामना गरिरहेका छौं, जुन ठूलो मात्रामा डाटासँग व्यवहार गर्दा विशेष गरी महत्त्वपूर्ण हुन्छ। यो लेखमा छलफल गरिनेछ।

तल वर्णन गरिएका विधिहरू Ceph को कुनै पनि संस्करणको लागि सान्दर्भिक छन्। थप रूपमा, Ceph डाटाको ठूलो मात्रा भण्डारण गर्न सक्छ भन्ने तथ्यलाई ध्यानमा राखिनेछ: डाटा हानि र अन्य समस्याहरू रोक्नको लागि, केही कार्यहरू धेरै अन्यमा "विभाजित" हुनेछन्।

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

छलफल गरिएका तीनवटा रेसिपीहरूमध्ये दुई ओएसडीलाई समर्पित भएकाले (वस्तु भण्डारण डेमन), व्यावहारिक भाग मा डाइभ गर्नु अघि - यो Ceph मा के छ र किन यो धेरै महत्त्वपूर्ण छ भन्ने बारे छोटकरीमा।

सबै भन्दा पहिले, यो भनिन्छ कि सम्पूर्ण Ceph क्लस्टर धेरै OSDs समावेश गर्दछ। त्यहाँ जति धेरै छन्, Ceph मा नि: शुल्क डाटा भोल्युम धेरै। यहाँबाट बुझ्न सजिलो छ मुख्य OSD प्रकार्य: यसले सबै क्लस्टर नोडहरूको फाइल प्रणालीहरूमा Ceph वस्तु डाटा भण्डार गर्दछ र यसलाई नेटवर्क पहुँच प्रदान गर्दछ (पढ्न, लेखन, र अन्य अनुरोधहरूको लागि)।

एउटै स्तरमा, प्रतिकृति प्यारामिटरहरू विभिन्न OSD हरू बीच वस्तुहरू प्रतिलिपि गरेर सेट गरिन्छ। र यहाँ तपाईं विभिन्न समस्याहरू सामना गर्न सक्नुहुन्छ, जसको समाधान तल छलफल गरिनेछ।

मुद्दा नम्बर १। डाटा गुमाउन बिना Ceph क्लस्टरबाट OSD सुरक्षित रूपमा हटाउनुहोस्

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

सुविधाको लागि र आदेशहरू कार्यान्वयन गर्दा, हामीले आवश्यक OSD संकेत गर्नमा गल्ती गर्छौं भने, हामी एउटा छुट्टै चर सेट गर्नेछौं, जसको मान मेटाइने OSD को संख्या हुनेछ। उहाँलाई कल गरौं ${ID} — यहाँ र तल, यस्तो चरले हामीले काम गरिरहेका OSD को संख्यालाई प्रतिस्थापन गर्छ।

काम सुरु गर्नु अघि अवस्था हेरौं:

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

OSD हटाउन सुरु गर्न, तपाईंले सहज रूपमा प्रदर्शन गर्न आवश्यक हुनेछ reweight यसमा शून्यमा। यसरी हामी OSD मा डाटाको मात्रालाई अन्य OSD मा सन्तुलन गरेर घटाउँछौं। यो गर्नका लागि, निम्न आदेशहरू चलाउनुहोस्:

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

... र यस्तै शून्य सम्म।

सहज सन्तुलन आवश्यक छताकि डाटा हराउन नपरोस्। यो विशेष गरी सत्य हो यदि OSD मा डेटाको ठूलो मात्रा समावेश छ। आदेशहरू कार्यान्वयन पछि यो सुनिश्चित गर्न reweight सबै राम्रो भयो, तपाईं यसलाई पूरा गर्न सक्नुहुन्छ ceph -s वा छुट्टै टर्मिनल सञ्झ्यालमा चलाउनुहोस् ceph -w वास्तविक समयमा परिवर्तनहरू अवलोकन गर्न।

जब OSD "खाली" हुन्छ, तपाइँ यसलाई हटाउन मानक अपरेशनको साथ अगाडि बढ्न सक्नुहुन्छ। यो गर्नको लागि, राज्यमा वांछित OSD स्थानान्तरण गर्नुहोस् 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}

OSD बाट हटाउनुहोस् क्रश नक्शा:

ceph osd crush remove osd.${ID}

OSD प्रयोगकर्ता मेटौं:

ceph auth del osd.${ID}

र अन्तमा, OSD आफैलाई हटाउनुहोस्:

ceph osd rm osd.${ID}

भन्नु: यदि तपाइँ Ceph Luminous संस्करण वा उच्च प्रयोग गर्दै हुनुहुन्छ भने, माथिको OSD हटाउने चरणहरू दुई आदेशहरूमा घटाउन सकिन्छ:

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

यदि, माथि वर्णन गरिएका चरणहरू पूरा गरेपछि, तपाईंले आदेश चलाउनुहोस् ceph osd tree, तब यो स्पष्ट हुनुपर्दछ कि सर्भरमा जहाँ काम गरिएको थियो त्यहाँ अब OSD हरू छैनन् जसको लागि माथिका कार्यहरू प्रदर्शन गरिएको थियो:

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

बाटोमा, नोट गर्नुहोस् कि Ceph क्लस्टरको अवस्था जानेछ HEALTH_WARN, र हामी OSD को संख्या र उपलब्ध डिस्क स्पेसको मात्रामा पनि कमी देख्नेछौं।

यदि तपाइँ सर्भर पूर्ण रूपमा रोक्न चाहानुहुन्छ भने निम्न चरणहरू वर्णन गर्दछ र, तदनुसार, यसलाई Ceph बाट हटाउनुहोस्। यस अवस्थामा, यो सम्झना महत्त्वपूर्ण छ सर्भर बन्द गर्नु अघि, तपाईंले सबै OSDs हटाउनु पर्छ यस सर्भरमा।

यदि यस सर्भरमा कुनै पनि OSD हरू बाँकी छैनन् भने, तिनीहरूलाई हटाएपछि तपाईंले OSD नक्साबाट सर्भर बहिष्कार गर्न आवश्यक छ। hv-2निम्न आदेश चलाएर:

ceph osd crush rm hv-2

मेटाउन mon सर्भरबाट hv-2अर्को सर्भरमा तलको आदेश चलाएर (अर्थात् यस अवस्थामा, on hv-1):

ceph-deploy mon destroy hv-2

यस पछि, तपाइँ सर्भर रोक्न र पछिका कार्यहरू सुरु गर्न सक्नुहुन्छ (यसलाई पुन: तैनाती, आदि)।

मुद्दा नम्बर २। पहिले नै सिर्जना गरिएको Ceph क्लस्टरमा डिस्क स्थानको वितरण

म दोस्रो कथा PG को बारे मा एक प्रस्तावना संग सुरु गर्नेछु (नियुक्ति समूहहरू)। Ceph मा PG को मुख्य भूमिका मुख्य रूपमा Ceph वस्तुहरू जम्मा गर्नु र तिनीहरूलाई OSD मा दोहोर्याउनु हो। तपाईंले PG को आवश्यक रकम गणना गर्न सक्ने सूत्र छ सम्बन्धित खण्ड Ceph दस्तावेज। यो मुद्दा पनि विशिष्ट उदाहरणहरू सहित छलफल गरिएको छ।

त्यसोभए: Ceph प्रयोग गर्दा सामान्य समस्याहरू मध्ये एक Ceph मा पूलहरू बीच OSD र PG को असंतुलित संख्या हो।

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

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

त्यसोभए, निम्न चित्रको कल्पना गरौं: क्लस्टरको स्थिति छ HEALTH_WARN ओएसडी मध्ये एउटा ठाउँको कमी भएको कारणले। यो त्रुटि द्वारा संकेत गरिनेछ HEALTH_WARN: 1 near full osd। तल यस अवस्थाबाट बाहिर निस्कने एल्गोरिदम छ।

सबै भन्दा पहिले, तपाईंले बाँकी OSD हरू बीच उपलब्ध डाटा वितरण गर्न आवश्यक छ। हामीले पहिले नै पहिलो केसमा समान अपरेशन प्रदर्शन गरिसकेका छौं, जब हामीले नोडलाई "निकास" गर्यौं - केवल भिन्नताको साथ जुन अब हामीले थोरै घटाउनु पर्छ। reweight। उदाहरणका लागि, ०.९५ सम्म:

ceph osd reweight osd.${ID} 0.95

यसले OSD मा डिस्क स्पेस खाली गर्छ र ceph स्वास्थ्यमा त्रुटि फिक्स गर्छ। यद्यपि, पहिले नै उल्लेख गरिएझैं, यो समस्या मुख्यतया प्रारम्भिक चरणहरूमा Ceph को गलत कन्फिगरेसनको कारणले हुन्छ: यो पुन: कन्फिगरेसन गर्न धेरै महत्त्वपूर्ण छ ताकि यो भविष्यमा देखा पर्दैन।

हाम्रो विशेष अवस्थामा, यो सबै तल आयो:

• मूल्य धेरै उच्च replication_count एउटा पोखरीमा,
• एउटा पोखरीमा धेरै PG र अर्कोमा धेरै थोरै।

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

भन्नु: यदि तपाइँ स्क्र्याचबाट Ceph क्लस्टर सेटअप गर्दै हुनुहुन्छ भने, क्याल्कुलेटरको अर्को उपयोगी कार्य भनेको आदेशहरूको उत्पादन हो जसले तालिकामा निर्दिष्ट प्यारामिटरहरूसँग स्क्र्याचबाट पूलहरू सिर्जना गर्दछ।

अन्तिम स्तम्भले तपाईंलाई नेभिगेट गर्न मद्दत गर्दछ - सिफारिस गरिएको PG गणना। हाम्रो अवस्थामा, दोस्रो पनि उपयोगी छ, जहाँ प्रतिकृति प्यारामिटर संकेत गरिएको छ, किनकि हामीले प्रतिकृति गुणक परिवर्तन गर्ने निर्णय गर्यौं।

त्यसोभए, पहिले तपाईंले प्रतिकृति प्यारामिटरहरू परिवर्तन गर्न आवश्यक छ - यो पहिले गर्न लायक छ, किनकि गुणक घटाएर, हामी डिस्क ठाउँ खाली गर्नेछौं। आदेश कार्यान्वयन गर्दा, तपाईंले याद गर्नुहुनेछ कि उपलब्ध डिस्क स्पेस बढ्नेछ:

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

महत्त्वपूर्ण: हामीले प्रत्येक पोखरीमा क्रमिक रूपमा PG हरूको संख्या परिवर्तन गर्नुपर्छ र चेतावनीहरू गायब नभएसम्म अन्य पूलहरूमा मानहरू परिवर्तन गर्नु हुँदैन। "डिग्रेडेड डाटा रिडन्डेंसी" и "pgs को n-संख्या घटाइएको".

तपाइँ यो पनि जाँच गर्न सक्नुहुन्छ कि आदेश आउटपुटहरू प्रयोग गरेर सबै कुरा राम्रोसँग गयो ceph health detail и ceph -s.

मुद्दा नम्बर ३। LVM बाट Ceph RBD मा भर्चुअल मेसिन माइग्रेट गर्दै

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

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

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

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

virsh pool-dumpxml $ceph_pool

पूल विवरणमा प्राधिकरण डेटाको साथ Ceph मा जडान डेटा समावेश हुनुपर्छ।

अर्को चरण यो हो कि 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>

केही विवरणहरू हेरौं:

1. प्रोटोकलमा source Ceph RBD मा भण्डारणको ठेगाना संकेत गरिएको छ (यो Ceph पूल र RBD छविको नाम संकेत गर्ने ठेगाना हो, जुन पहिलो चरणमा निर्धारण गरिएको थियो)।
2. ब्लक मा secret प्रकार संकेत गरिएको छ ceph, साथै यसमा जडान गर्न गोप्य को UUID। यसको uuid आदेश प्रयोग गरेर फेला पार्न सकिन्छ virsh secret-list.
3. ब्लक मा host Ceph मनिटरहरूलाई ठेगानाहरू संकेत गरिएको छ।

कन्फिगरेसन फाइल सम्पादन गरेपछि र LVM लाई RBD रूपान्तरण पूरा गरेपछि, तपाइँ परिमार्जित कन्फिगरेसन फाइल लागू गर्न र भर्चुअल मेसिन सुरु गर्न सक्नुहुन्छ:

virsh define $vm_name.xml
virsh start $vm_name

यो भर्चुअल मेसिन सही रूपमा सुरु भयो भनेर जाँच गर्ने समय हो: तपाईंले पत्ता लगाउन सक्नुहुन्छ, उदाहरणका लागि, यसलाई SSH मार्फत वा मार्फत जडान गरेर। virsh.

यदि भर्चुअल मेसिनले ठीकसँग काम गरिरहेको छ र तपाईंले अन्य कुनै समस्या फेला पार्नुभएन भने, तपाईंले अब प्रयोग नगरिएको LVM छवि मेटाउन सक्नुहुन्छ:

lvremove main/$vm_image_name

निष्कर्षमा

हामीले व्यवहारमा वर्णन गरिएका सबै केसहरूको सामना गर्यौं - हामी आशा गर्छौं कि निर्देशनहरूले अन्य प्रशासकहरूलाई समान समस्याहरू समाधान गर्न मद्दत गर्नेछ। यदि तपाइँसँग Ceph प्रयोग गरेर तपाइँको अनुभवबाट टिप्पणीहरू वा अन्य समान कथाहरू छन् भने, हामी तिनीहरूलाई टिप्पणीहरूमा देख्न पाउँदा खुसी हुनेछौं!

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «हाम्रा हातहरू बोरियतका लागि होइनन्: K8s मा रुक क्लस्टर पुनर्स्थापित गर्दै»;
• «रुकलाई कि रुकलाई होइन - त्यो प्रश्न हो»;
• «रुक - Kubernetes को लागि "स्व-सेवा" डाटा गोदाम»;
• «Ceph मा आधारित Kubernetes मा प्रावधान संग लगातार भण्डारण सिर्जना गर्दै"।

स्रोत: www.habr.com