რჩევები და ხრიკები Ceph-თან დატვირთულ პროექტებში მუშაობისთვის

Ceph-ის ქსელის შესანახად გამოყენება სხვადასხვა დატვირთვის პროექტებში, შეიძლება შეგვხვდეს სხვადასხვა ამოცანები, რომლებიც ერთი შეხედვით არც ისე მარტივი და ტრივიალური გვეჩვენება. Მაგალითად:

• მონაცემთა მიგრაცია ძველი Ceph-დან ახალში წინა სერვერების ნაწილობრივი გამოყენებით ახალ კლასტერში;
• Ceph-ში დისკის სივრცის გამოყოფის პრობლემის გადაჭრა.

ასეთ პრობლემებთან გამკლავებისას ჩვენ ვაწყდებით OSD-ის სწორად ამოღების აუცილებლობას მონაცემთა დაკარგვის გარეშე, რაც განსაკუთრებით მნიშვნელოვანია დიდი რაოდენობით მონაცემებთან მუშაობისას. ეს იქნება განხილული სტატიაში.

ქვემოთ აღწერილი მეთოდები შესაბამისია Ceph-ის ნებისმიერი ვერსიისთვის. გარდა ამისა, მხედველობაში მიიღება ის ფაქტი, რომ Ceph-ს შეუძლია დიდი რაოდენობით მონაცემების შენახვა: მონაცემთა დაკარგვისა და სხვა პრობლემების თავიდან ასაცილებლად, ზოგიერთი მოქმედება "დაიყოფა" რამდენიმე სხვაზე.

წინასიტყვაობა OSD-ის შესახებ

ვინაიდან განხილული სამი რეცეპტიდან ორი ეძღვნება OSD-ს (ობიექტების შენახვის დემონი), სანამ პრაქტიკულ ნაწილს ჩავუღრმავდებით - მოკლედ რა არის ის კეფში და რატომ არის ასე მნიშვნელოვანი.

უპირველეს ყოვლისა, უნდა ითქვას, რომ მთელი Ceph კლასტერი შედგება მრავალი OSD-ისგან. რაც მეტია, მით მეტია უფასო მონაცემთა მოცულობა Ceph-ში. აქედან ადვილი გასაგებია ძირითადი OSD ფუნქცია: ის ინახავს Ceph ობიექტის მონაცემებს ყველა კლასტერული კვანძის ფაილურ სისტემაზე და უზრუნველყოფს ქსელის წვდომას მასზე (წაკითხვის, ჩაწერისა და სხვა მოთხოვნებისთვის).

ამავე დონეზე, რეპლიკაციის პარამეტრები დაყენებულია სხვადასხვა OSD-ებს შორის ობიექტების კოპირებით. და აქ შეგიძლიათ შეხვდეთ სხვადასხვა პრობლემას, რომელთა გადაწყვეტილებები ქვემოთ იქნება განხილული.

საქმე No1. უსაფრთხოდ ამოიღეთ 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-დან CRUSH რუკა:

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-დან. ამ შემთხვევაში, მნიშვნელოვანია გვახსოვდეს, რომ სერვერის გამორთვამდე, თქვენ უნდა ამოიღოთ ყველა OSD ამ სერვერზე.

თუ ამ სერვერზე აღარ არის OSD-ები, მაშინ მათი ამოღების შემდეგ თქვენ უნდა გამორიცხოთ სერვერი OSD რუქიდან hv-2შემდეგი ბრძანების გაშვებით:

ceph osd crush rm hv-2

წაშლა mon სერვერიდან hv-2ქვემოთ მოცემული ბრძანების სხვა სერვერზე გაშვებით (ანუ ამ შემთხვევაში, ჩართვაზე hv-1):

ceph-deploy mon destroy hv-2

ამის შემდეგ შეგიძლიათ შეაჩეროთ სერვერი და დაიწყოთ შემდგომი მოქმედებები (ხელახალი განლაგება და ა.შ.).

საქმე No2. დისკის სივრცის განაწილება უკვე შექმნილ Ceph კლასტერში

მეორე მოთხრობას დავიწყებ წინასიტყვაობით PG-ის შესახებ (განლაგების ჯგუფები). PG-ის მთავარი როლი Ceph-ში, უპირველეს ყოვლისა, არის Ceph ობიექტების აგრეგაცია და მათი შემდგომი რეპლიკაცია OSD-ში. ფორმულა, რომლითაც შეგიძლიათ გამოთვალოთ PG-ის საჭირო რაოდენობა, არის შესაბამისი განყოფილება Ceph დოკუმენტაცია. ეს საკითხი იქაც განიხილება კონკრეტული მაგალითებით.

ასე რომ: Ceph-ის გამოყენებისას ერთ-ერთი გავრცელებული პრობლემა არის OSD-ისა და PG-ის დაუბალანსებელი რაოდენობა Ceph-ში აუზებს შორის.

უპირველეს ყოვლისა, ამის გამო შეიძლება შეიქმნას სიტუაცია, როდესაც ძალიან ბევრი PG არის მითითებული პატარა აუზში, რაც არსებითად არის დისკის სივრცის ირაციონალური გამოყენება კლასტერში. მეორეც, პრაქტიკაში უფრო სერიოზული პრობლემაა: მონაცემთა გადადინება ერთ-ერთ OSD-ში. ეს გულისხმობს კლასტერის პირველ გადასვლას სახელმწიფოში HEALTH_WARN, და მერე HEALTH_ERR. ამის მიზეზი ის არის, რომ ცეფი, მონაცემთა არსებული რაოდენობის გამოთვლისას (შეგიძლიათ გაიგოთ MAX AVAIL ბრძანების გამომავალში ceph df თითოეული აუზისთვის ცალ-ცალკე) ეფუძნება OSD-ში არსებული მონაცემების რაოდენობას. თუ მინიმუმ ერთ OSD-ში არ არის საკმარისი ადგილი, მეტი მონაცემის ჩაწერა შეუძლებელია, სანამ მონაცემები სწორად არ განაწილდება ყველა OSD-ს შორის.

აღსანიშნავია, რომ ეს პრობლემები ძირითადად გადაწყვეტილია Ceph კლასტერის კონფიგურაციის ეტაპზე. ერთ-ერთი ინსტრუმენტი, რომლის გამოყენებაც შეგიძლიათ, არის Ceph PGCalc. მისი დახმარებით მკაფიოდ გამოითვლება PG-ის საჭირო რაოდენობა. თუმცა, თქვენ ასევე შეგიძლიათ მიმართოთ მას იმ სიტუაციაში, როდესაც Ceph კასეტურია უკვე არასწორად კონფიგურირებული. აქ უნდა განვმარტოთ, რომ როგორც გამოსწორების სამუშაოების ნაწილი, თქვენ სავარაუდოდ დაგჭირდებათ PG-ების რაოდენობის შემცირება და ეს ფუნქცია არ არის ხელმისაწვდომი Ceph-ის ძველ ვერსიებში (ის მხოლოდ ვერსიაში გამოჩნდა Nautilus).

ასე რომ, წარმოვიდგინოთ შემდეგი სურათი: კლასტერს აქვს სტატუსი HEALTH_WARN ერთ-ერთი OSD-ის სივრცის ამოწურვის გამო. ეს მითითებული იქნება შეცდომით HEALTH_WARN: 1 near full osd. ქვემოთ მოცემულია ამ სიტუაციიდან გამოსვლის ალგორითმი.

უპირველეს ყოვლისა, თქვენ უნდა გაანაწილოთ ხელმისაწვდომი მონაცემები დარჩენილ OSD-ებს შორის. ჩვენ უკვე ჩავატარეთ მსგავსი ოპერაცია პირველ შემთხვევაში, როდესაც კვანძი "გავაწურეთ" - ერთადერთი განსხვავებით, რომ ახლა ოდნავ შემცირება დაგვჭირდება reweight. მაგალითად, 0.95-მდე:

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-ების რაოდენობა თანმიმდევრულად თითოეულ აუზში და არ შევცვალოთ მნიშვნელობები სხვა აუზებში, სანამ გაფრთხილებები არ გაქრება "დაქვეითებული მონაცემთა ჭარბი რაოდენობა" и "n-pgs-ის დეგრადირებული რაოდენობა".

თქვენ ასევე შეგიძლიათ შეამოწმოთ, რომ ყველაფერი კარგად იყო ბრძანების შედეგების გამოყენებით ceph health detail и ceph -s.

საქმე No3. ვირტუალური მანქანის მიგრაცია 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 მითითებულია ცეფის მონიტორების მისამართი.

კონფიგურაციის ფაილის რედაქტირებისა და LVM-ში RBD-ში გადაყვანის დასრულების შემდეგ, შეგიძლიათ გამოიყენოთ შეცვლილი კონფიგურაციის ფაილი და დაიწყოთ ვირტუალური მანქანა:

virsh define $vm_name.xml
virsh start $vm_name

დროა შეამოწმოთ, რომ ვირტუალური მანქანა სწორად დაიწყო: შეგიძლიათ გაიგოთ, მაგალითად, მასთან დაკავშირებით SSH ან მეშვეობით virsh.

თუ ვირტუალური მანქანა მუშაობს სწორად და თქვენ ვერ იპოვნეთ რაიმე სხვა პრობლემა, მაშინ შეგიძლიათ წაშალოთ LVM სურათი, რომელიც აღარ გამოიყენება:

lvremove main/$vm_image_name

დასკვნა

ჩვენ პრაქტიკაში შევხვდით ყველა აღწერილ შემთხვევას - ვიმედოვნებთ, რომ ინსტრუქციები დაეხმარება სხვა ადმინისტრატორებს მსგავსი პრობლემების გადაჭრაში. თუ თქვენ გაქვთ კომენტარები ან სხვა მსგავსი ისტორიები Ceph-ის გამოყენების გამოცდილებიდან, მოხარული ვიქნებით მათ კომენტარებში ვიხილოთ!

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «ჩვენი ხელები მოწყენილობისთვის არ არის: K8-ებში Rook კასეტურის აღდგენა";
• «რუკს თუ არა რუკს - ეს არის კითხვა";
• «Rook - "თვითმომსახურების" მონაცემთა საწყობი Kubernetes-ისთვის";
• «მუდმივი მეხსიერების შექმნა Kubernetes-ში მიწოდებით Ceph-ის საფუძველზე".

წყარო: www.habr.com