व्यस्त प्रकल्पांमध्ये Ceph सोबत काम करण्यासाठी टिपा आणि युक्त्या

वेगवेगळ्या भारांसह प्रकल्पांमध्ये नेटवर्क स्टोरेज म्हणून Ceph वापरणे, आम्हाला विविध कार्ये येऊ शकतात जी पहिल्या दृष्टीक्षेपात साधी किंवा क्षुल्लक वाटत नाहीत. उदाहरणार्थ:

• नवीन क्लस्टरमधील मागील सर्व्हरच्या आंशिक वापरासह जुन्या Ceph वरून नवीनमध्ये डेटाचे स्थलांतर;
• Ceph मधील डिस्क स्पेस वाटपाच्या समस्येचे निराकरण.

अशा समस्यांना सामोरे जाताना, डेटा न गमावता OSD योग्यरित्या काढण्याची गरज आम्हाला भेडसावत आहे, जे मोठ्या प्रमाणात डेटा हाताळताना विशेषतः महत्वाचे आहे. याबद्दल लेखात चर्चा केली जाईल.

खाली वर्णन केलेल्या पद्धती Ceph च्या कोणत्याही आवृत्तीसाठी संबंधित आहेत. याव्यतिरिक्त, सेफ मोठ्या प्रमाणात डेटा संचयित करू शकतो हे तथ्य विचारात घेतले जाईल: डेटा गमावणे आणि इतर समस्या टाळण्यासाठी, काही क्रिया इतरांमध्ये "विभाजित" केल्या जातील.

OSD बद्दल प्रस्तावना

चर्चा केलेल्या तीन पाककृतींपैकी दोन OSD ला समर्पित असल्यामुळे (ऑब्जेक्ट स्टोरेज डिमन), व्यावहारिक भागामध्ये जाण्यापूर्वी - सेफमध्ये ते काय आहे आणि ते इतके महत्त्वाचे का आहे याबद्दल थोडक्यात.

सर्व प्रथम, असे म्हटले पाहिजे की संपूर्ण सेफ क्लस्टरमध्ये अनेक ओएसडी असतात. जेवढे जास्त आहेत, तितकेच Ceph मधील फ्री डेटा व्हॉल्यूम. येथून समजणे सोपे आहे मुख्य OSD कार्य: हे सर्व क्लस्टर नोड्सच्या फाइल सिस्टमवर Ceph ऑब्जेक्ट डेटा संग्रहित करते आणि त्यावर नेटवर्क प्रवेश प्रदान करते (वाचन, लेखन आणि इतर विनंत्यांसाठी).

त्याच स्तरावर, वेगवेगळ्या OSD मधील वस्तू कॉपी करून प्रतिकृती मापदंड सेट केले जातात. आणि येथे आपल्याला विविध समस्या येऊ शकतात, ज्याचे निराकरण खाली चर्चा केली जाईल.

प्रकरण क्रमांक १. डेटा न गमावता Ceph क्लस्टरमधून OSD सुरक्षितपणे काढा

ओएसडी काढण्याची गरज क्लस्टरमधून सर्व्हर काढून टाकल्यामुळे उद्भवू शकते - उदाहरणार्थ, ते दुसर्‍या सर्व्हरसह बदलणे - जे आमच्या बाबतीत घडले, ज्यामुळे या लेखाच्या लेखनाला चालना मिळाली. अशाप्रकारे, मॅनिपुलेशनचे अंतिम लक्ष्य दिलेल्या सर्व्हरवरील सर्व ओएसडी आणि मॉन्स काढणे हे आहे जेणेकरून ते थांबवता येईल.

सोयीसाठी आणि कमांड कार्यान्वित करताना, आम्ही आवश्यक ओएसडी दर्शविण्यात चूक करतो अशा परिस्थिती टाळण्यासाठी, आम्ही एक वेगळे व्हेरिएबल सेट करू, ज्याचे मूल्य हटवल्या जाणार्‍या ओएसडीची संख्या असेल. चला तिला कॉल करूया ${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

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 "रिक्त" केले जाते, तेव्हा तुम्ही ते काढण्यासाठी मानक ऑपरेशनसह पुढे जाऊ शकता. हे करण्यासाठी, इच्छित ओएसडी राज्यात हस्तांतरित करा down:

ceph osd down osd.${ID}

चला ओएसडीला क्लस्टरमधून बाहेर काढूया:

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, नंतर हे स्पष्ट झाले पाहिजे की ज्या सर्व्हरवर कार्य केले गेले होते तेथे यापुढे ओएसडी नाहीत ज्यासाठी वरील ऑपरेशन केले गेले होते:

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 काढून टाकणे आवश्यक आहे या सर्व्हरवर.

या सर्व्हरवर आणखी कोणतेही OSD शिल्लक नसल्यास, ते काढून टाकल्यानंतर तुम्हाला OSD नकाशामधून सर्व्हर वगळण्याची आवश्यकता आहे. hv-2खालील आदेश चालवून:

ceph osd crush rm hv-2

हटवा mon सर्व्हर वरून hv-2दुसर्‍या सर्व्हरवर खालील कमांड चालवून (म्हणजे या प्रकरणात, चालू hv-1):

ceph-deploy mon destroy hv-2

यानंतर, तुम्ही सर्व्हर थांबवू शकता आणि त्यानंतरच्या क्रिया सुरू करू शकता (ते पुन्हा उपयोजित करणे इ.).

प्रकरण क्रमांक 2. आधीच तयार केलेल्या Ceph क्लस्टरमध्ये डिस्क स्पेसचे वितरण

मी दुसऱ्या कथेची सुरुवात PG बद्दल प्रस्तावनेने करेन (प्लेसमेंट गट). Ceph मधील PG ची मुख्य भूमिका मुख्यतः Ceph वस्तू एकत्रित करणे आणि त्यांची OSD मध्ये प्रतिकृती तयार करणे आहे. ज्या सूत्राने तुम्ही PG ची आवश्यक रक्कम मोजू शकता ते आहे संबंधित विभाग Ceph दस्तऐवजीकरण. या मुद्द्यावरही विशिष्ट उदाहरणांसह चर्चा केली आहे.

त्यामुळे: Ceph वापरताना सामान्य समस्यांपैकी एक म्हणजे Ceph मधील पूलमधील OSD आणि PG ची असंतुलित संख्या.

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

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

तर, खालील चित्राची कल्पना करू या: क्लस्टरची स्थिती आहे HEALTH_WARN एका OSD ची जागा संपल्यामुळे. हे त्रुटीद्वारे सूचित केले जाईल HEALTH_WARN: 1 near full osd. या परिस्थितीतून बाहेर पडण्यासाठी खाली एक अल्गोरिदम आहे.

सर्व प्रथम, तुम्हाला उर्वरित OSD मध्ये उपलब्ध डेटा वितरित करणे आवश्यक आहे. आम्ही पहिल्या प्रकरणात असेच ऑपरेशन केले आहे, जेव्हा आम्ही नोड "निचरा" केला - फक्त फरक आहे की आता आम्हाला किंचित कमी करावे लागेल reweight. उदाहरणार्थ, ०.९५ पर्यंत:

ceph osd reweight osd.${ID} 0.95

हे OSD मध्ये डिस्क जागा मोकळी करते आणि ceph आरोग्यातील त्रुटी दूर करते. तथापि, आधीच नमूद केल्याप्रमाणे, ही समस्या मुख्यतः प्रारंभिक टप्प्यावर सेफच्या चुकीच्या कॉन्फिगरेशनमुळे उद्भवते: पुनर्रचना करणे फार महत्वाचे आहे जेणेकरून ते भविष्यात दिसणार नाही.

आमच्या विशिष्ट बाबतीत, हे सर्व खाली आले:

• मूल्य खूप जास्त आहे replication_count एका तलावात,
• एका पूलमध्ये खूप पीजी आणि दुसऱ्यामध्ये खूप कमी.

आधीच नमूद केलेले कॅल्क्युलेटर वापरू. हे स्पष्टपणे दर्शवते की काय प्रविष्ट करणे आवश्यक आहे आणि तत्त्वानुसार, यात काहीही क्लिष्ट नाही. आवश्यक पॅरामीटर्स सेट केल्यावर, आम्हाला खालील शिफारसी मिळतात:

शेरा: जर तुम्ही सुरवातीपासून 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

महत्वाचे: आम्ही प्रत्येक पूलमध्ये क्रमाक्रमाने PGs ची संख्या बदलली पाहिजे आणि चेतावणी अदृश्य होईपर्यंत इतर पूलमधील मूल्ये बदलू नयेत "डिग्रेडेड डेटा रिडंडंसी" и "निकृष्ट pgs ची संख्या".

कमांड आउटपुट वापरून सर्व काही व्यवस्थित चालले आहे हे देखील तुम्ही तपासू शकता ceph health detail и ceph -s.

प्रकरण क्रमांक 3. आभासी मशीन LVM वरून Ceph RBD वर स्थलांतरित करणे

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

समस्येचे निराकरण वेगवेगळ्या प्रकारे केले जाऊ शकते - उदाहरणार्थ, दुसर्या सर्व्हरवर स्थलांतर करून (एखादे असल्यास) किंवा सर्व्हरवर नवीन डिस्क जोडून. परंतु हे करणे नेहमीच शक्य नसते, म्हणून LVM वरून Ceph मध्ये स्थलांतर करणे या समस्येचे उत्कृष्ट समाधान असू शकते. हा पर्याय निवडून, आम्ही सर्व्हरमधील स्थलांतराची पुढील प्रक्रिया देखील सुलभ करतो, कारण स्थानिक स्टोरेज एका हायपरवाइजरवरून दुसऱ्या हायपरवाइजरमध्ये हलवण्याची गरज नाही. फक्त एकच पकड आहे की काम चालू असताना तुम्हाला व्हीएम थांबवावे लागेल.

खालील कृती वरून घेतली आहे या ब्लॉगवरील लेख, ज्याच्या सूचना कृतीत तपासल्या गेल्या आहेत. तसे, त्रासमुक्त स्थलांतराची पद्धत देखील तेथे वर्णन केलेली आहेतथापि, आमच्या बाबतीत ते फक्त आवश्यक नव्हते, म्हणून आम्ही ते तपासले नाही. आपल्या प्रकल्पासाठी हे गंभीर असल्यास, टिप्पण्यांमधील परिणामांबद्दल ऐकून आम्हाला आनंद होईल.

चला व्यावहारिक भागाकडे जाऊया. उदाहरणात आपण 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 मध्ये रुक क्लस्टर पुनर्संचयित करणे";
• «रुककडे किंवा रुककडे नाही - हा प्रश्न आहे";
• «रुक - कुबर्नेट्ससाठी "स्व-सेवा" डेटा वेअरहाऊस";
• «Ceph वर आधारित Kubernetes मध्ये तरतूदीसह पर्सिस्टंट स्टोरेज तयार करणे».

स्त्रोत: www.habr.com