Ceph-dən müxtəlif yükləri olan layihələrdə şəbəkə yaddaşı kimi istifadə edərək, ilk baxışdan sadə və ya əhəmiyyətsiz görünməyən müxtəlif tapşırıqlarla qarşılaşa bilərik. Misal üçün:
- yeni klasterdə əvvəlki serverlərin qismən istifadəsi ilə məlumatların köhnə Ceph-dən yenisinə miqrasiyası;
- Ceph-də disk sahəsinin ayrılması probleminin həlli.
Bu cür problemlərlə məşğul olaraq, məlumatları itirmədən OSD-ni düzgün çıxarmaq ehtiyacı ilə qarşılaşırıq, bu, böyük miqdarda məlumatlarla işləyərkən xüsusilə vacibdir. Bu məqalədə müzakirə olunacaq.
Aşağıda təsvir edilən üsullar Ceph-in istənilən versiyası üçün uyğundur. Bundan əlavə, Ceph-in böyük miqdarda məlumat saxlaya bilməsi nəzərə alınacaq: məlumat itkisinin və digər problemlərin qarşısını almaq üçün bəzi hərəkətlər bir neçə digərinə "bölünəcək".
OSD haqqında ön söz
Müzakirə olunan üç reseptdən ikisi OSD-yə həsr olunduğundan (), praktik hissəyə keçməzdən əvvəl - qısaca Ceph-də nə olduğu və niyə bu qədər vacib olduğu haqqında.
Əvvəla, bütün Ceph klasterinin bir çox OSD-dən ibarət olduğunu söyləmək lazımdır. Nə qədər çox olarsa, Ceph-də pulsuz məlumat həcmi bir o qədər çox olar. Buradan başa düşmək asandır əsas OSD funksiyası: O, Ceph obyekt məlumatlarını bütün klaster qovşaqlarının fayl sistemlərində saxlayır və ona şəbəkə girişini təmin edir (oxumaq, yazmaq və digər sorğular üçün).
Eyni səviyyədə, təkrarlama parametrləri müxtəlif OSD-lər arasında obyektlərin surətini çıxarmaqla təyin edilir. Və burada müxtəlif problemlərlə qarşılaşa bilərsiniz, onların həlli yolları daha sonra müzakirə ediləcəkdir.
İş № 1. Məlumatı itirmədən OSD-ni Ceph klasterindən təhlükəsiz şəkildə çıxarın
OSD-nin çıxarılması zərurəti serverin klasterdən çıxarılması ilə - məsələn, onu başqa bir serverlə əvəz etməkdən qaynaqlana bilər - bu, bizim başımıza gələn bu məqalənin yazılmasına səbəb oldu. Beləliklə, manipulyasiyanın son məqsədi verilmiş serverdə bütün OSD və monları çıxarmaqdır ki, dayandırıla bilsin.
Rahatlıq üçün və əmrləri yerinə yetirərkən tələb olunan OSD-ni göstərərkən səhv etdiyimiz bir vəziyyətin qarşısını almaq üçün ayrı bir dəyişən təyin edəcəyik, dəyəri silinəcək OSD-nin sayı olacaq. Gəlin ona zəng edək ${ID} — burada və aşağıda belə dəyişən işlədiyimiz OSD-nin sayını əvəz edir.
İşə başlamazdan əvvəl vəziyyətə baxaq:
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-nin silinməsinə başlamaq üçün siz rəvan yerinə yetirməlisiniz reweight üzərində sıfıra. Bu yolla biz digər OSD-lərə balanslaşdırmaqla OSD-dəki məlumatların miqdarını azaldırıq. Bunu etmək üçün aşağıdakı əmrləri yerinə yetirin:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... və s. sıfıra qədər.
Hamar balans tələb olunurməlumatları itirməmək üçün. Bu, xüsusən də OSD-də çoxlu məlumat varsa doğrudur. Əmrləri yerinə yetirdikdən sonra əmin olmaq üçün reweight hər şey yaxşı getdi, tamamlaya bilərsiniz ceph -s və ya ayrıca terminal pəncərəsində işə salın ceph -w real vaxtda dəyişiklikləri müşahidə etmək üçün.
OSD “boşaldıldıqda” onu çıxarmaq üçün standart əməliyyata davam edə bilərsiniz. Bunu etmək üçün istədiyiniz OSD-ni dövlətə köçürün down:
ceph osd down osd.${ID}OSD-ni klasterdən “çıxaraq”:
ceph osd out osd.${ID}OSD xidmətini dayandıraq və onun FS-də bölməsini ayıraq:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}OSD-ni buradan çıxarın :
ceph osd crush remove osd.${ID}OSD istifadəçisini silək:
ceph auth del osd.${ID}Və nəhayət, OSD-nin özünü çıxaraq:
ceph osd rm osd.${ID}Qeyd: Əgər siz Ceph Luminous və ya daha yüksək versiyadan istifadə edirsinizsə, o zaman yuxarıdakı OSD-nin çıxarılması addımları iki əmrə endirilə bilər:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Yuxarıda təsvir olunan addımları tamamladıqdan sonra əmri yerinə yetirirsiniz ceph osd tree, onda işin görüldüyü serverdə yuxarıda göstərilən əməliyyatların yerinə yetirildiyi OSD-lərin artıq olmadığı aydın olmalıdır:
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
Yolda Ceph klasterinin vəziyyətinə gedəcəyini qeyd edin HEALTH_WARN, və biz həmçinin OSD-lərin sayında və mövcud disk sahəsinin miqdarında azalma görəcəyik.
Aşağıda serveri tamamilə dayandırmaq və müvafiq olaraq onu Ceph-dən silmək istəyirsinizsə, tələb olunacaq addımlar təsvir olunacaq. Bu vəziyyətdə bunu xatırlamaq vacibdir Serveri bağlamazdan əvvəl bütün OSD-ləri silməlisiniz bu serverdə.
Bu serverdə daha çox OSD qalmayıbsa, onları sildikdən sonra serveri OSD xəritəsindən xaric etməlisiniz. hv-2aşağıdakı əmri işlətməklə:
ceph osd crush rm hv-2
Sil mon serverdən hv-2aşağıdakı əmri başqa bir serverdə işlətməklə (yəni bu halda, on hv-1):
ceph-deploy mon destroy hv-2Bundan sonra, serveri dayandıra və sonrakı hərəkətlərə başlaya bilərsiniz (yenidən yerləşdirmə və s.).
İş № 2. Artıq yaradılmış Ceph klasterində disk sahəsinin paylanması
İkinci hekayəyə PG haqqında ön sözlə başlayacağam (). Ceph-də PG-nin əsas rolu ilk növbədə Ceph obyektlərini birləşdirmək və onları OSD-də daha da təkrarlamaqdır. Tələb olunan PG miqdarını hesablaya biləcəyiniz düstur var Ceph sənədləri. Bu məsələ orada da konkret misallarla müzakirə edilir.
Beləliklə: Ceph istifadə edərkən ümumi problemlərdən biri Ceph-dəki hovuzlar arasında OSD və PG-nin balanssız sayıdır.
Birincisi, buna görə, kiçik bir hovuzda çox sayda PG göstərildiyi zaman bir vəziyyət yarana bilər ki, bu da klasterdəki disk sahəsinin irrasional istifadəsidir. İkincisi, praktikada daha ciddi bir problem var: OSD-lərdən birində məlumatların daşması. Bu, klasterin dövlətə ilk keçidini nəzərdə tutur HEALTH_WARN, daha sonra HEALTH_ERR. Bunun səbəbi, Ceph, mövcud məlumat miqdarını hesablayarkən (bunu tapa bilərsiniz MAX AVAIL komanda çıxışında ceph df hər bir hovuz üçün ayrıca) OSD-də mövcud məlumatların miqdarına əsaslanır. Ən azı bir OSD-də kifayət qədər yer yoxdursa, məlumat bütün OSD-lər arasında düzgün paylanana qədər daha çox məlumat yazıla bilməz.
Bu problemlərə aydınlıq gətirməyə dəyər əsasən Ceph klasterinin konfiqurasiya mərhələsində qərar verilir. İstifadə edə biləcəyiniz vasitələrdən biri də budur . Onun köməyi ilə tələb olunan PG miqdarı aydın şəkildə hesablanır. Bununla birlikdə, Ceph klasterinin olduğu bir vəziyyətdə də buna müraciət edə bilərsiniz artıq səhv konfiqurasiya edilmişdir. Burada aydınlaşdırmağa dəyər ki, düzəliş işinin bir hissəsi olaraq çox güman ki, PG-lərin sayını azaltmalı olacaqsınız və bu xüsusiyyət Ceph-in köhnə versiyalarında mövcud deyil (yalnız versiyada göründü) ).
Beləliklə, aşağıdakı şəkli təsəvvür edək: klasterin statusu var HEALTH_WARN OSD-lərdən birinin boş yerə getməsi səbəbindən. Bu, xəta ilə göstəriləcək HEALTH_WARN: 1 near full osd. Aşağıda bu vəziyyətdən çıxmaq üçün bir alqoritm var.
İlk növbədə, mövcud məlumatları qalan OSD-lər arasında paylamalısınız. Biz artıq birinci halda, nodu "boşaltdığımızda" oxşar əməliyyat həyata keçirdik - yeganə fərqlə indi bir az azaltmalı olacağıq. reweight. Məsələn, 0.95-ə qədər:
ceph osd reweight osd.${ID} 0.95Bu, OSD-də disk yerini boşaldır və seph sağlamlığındakı səhvi düzəldir. Lakin, artıq qeyd edildiyi kimi, bu problem əsasən ilkin mərhələlərdə Ceph-in səhv konfiqurasiyasına görə baş verir: gələcəkdə görünməməsi üçün yenidən konfiqurasiya etmək çox vacibdir.
Bizim xüsusi vəziyyətimizdə hər şey aşağıdakılara çatdı:
- dəyəri çox yüksəkdir
replication_counthovuzların birində, - bir hovuzda çox PG, digərində isə çox az.
Artıq qeyd olunan kalkulyatordan istifadə edək. Nə daxil edilməli olduğunu aydın şəkildə göstərir və prinsipcə, mürəkkəb bir şey yoxdur. Lazımi parametrləri təyin etdikdən sonra aşağıdakı tövsiyələri alırıq:
Qeyd: Əgər siz sıfırdan Ceph klaster qurursunuzsa, kalkulyatorun digər faydalı funksiyası cədvəldə göstərilən parametrlərlə sıfırdan hovuzlar yaradacaq əmrlərin yaradılmasıdır.
Son sütun naviqasiyanıza kömək edir - Təklif olunan PG sayı. Bizim vəziyyətimizdə, təkrarlama parametrinin göstərildiyi ikincisi də faydalıdır, çünki replikasiya çarpanını dəyişdirmək qərarına gəldik.
Beləliklə, əvvəlcə replikasiya parametrlərini dəyişdirməlisiniz - ilk növbədə bunu etməyə dəyər, çünki çarpanı azaltmaqla disk yerini boşaltacağıq. Komanda icra edildikdə, mövcud disk sahəsinin artacağını görəcəksiniz:
ceph osd pool $pool_name set $replication_size
Və tamamlandıqdan sonra parametr dəyərlərini dəyişdiririk pg_num и pgp_num belədir:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberVacibdir: hər hovuzda PG-lərin sayını ardıcıl olaraq dəyişdirməliyik və xəbərdarlıqlar yox olana qədər digər hovuzlardakı dəyərləri dəyişməməliyik. "Pislənmiş məlumat ehtiyatı" и "n-pg-lərin sayı pisləşdi".
Siz həmçinin komanda çıxışlarından istifadə edərək hər şeyin yaxşı getdiyini yoxlaya bilərsiniz ceph health detail и ceph -s.
İş № 3. Virtual maşının LVM-dən Ceph RBD-yə köçürülməsi
Layihənin icarəyə götürülmüş çılpaq metal serverlərdə quraşdırılmış virtual maşınlardan istifadə etdiyi bir vəziyyətdə, tez-tez səhvlərə dözümlü saxlama məsələsi yaranır. Bu saxlamada kifayət qədər yer olması da çox arzuolunandır... Başqa bir ümumi vəziyyət: serverdə lokal yaddaşa malik virtual maşın var və diski genişləndirmək lazımdır, lakin getmək üçün heç bir yer yoxdur, çünki heç bir yer yoxdur. serverdə boş disk sahəsi.
Problem müxtəlif yollarla həll edilə bilər - məsələn, başqa bir serverə köçməklə (əgər varsa) və ya serverə yeni disklər əlavə etməklə. Ancaq bunu etmək həmişə mümkün deyil, buna görə də LVM-dən Ceph-ə köçmək bu problemin əla həlli ola bilər. Bu seçimi seçməklə biz həmçinin serverlər arasında sonrakı miqrasiya prosesini sadələşdiririk, çünki yerli yaddaşı bir hipervizordan digərinə köçürməyə ehtiyac qalmayacaq. Yeganə məqam budur ki, iş aparılarkən VM-ni dayandırmalı olacaqsınız.
Aşağıdakı resept götürülmüşdür , təlimatları fəaliyyətdə sınaqdan keçirilmişdir. Yeri gəlmişkən, orada əngəlsiz miqrasiya üsulu da təsvir edilmişdir, lakin bizim vəziyyətimizdə sadəcə lazım deyildi, ona görə də yoxlamadıq. Bu, layihəniz üçün kritikdirsə, şərhlərdə nəticələr haqqında eşitməkdən şad olarıq.
Gəlin praktik hissəyə keçək. Nümunədə virsh və müvafiq olaraq libvirt istifadə edirik. Əvvəlcə məlumatların köçürüləcəyi Ceph hovuzunun libvirt-ə qoşulduğundan əmin olun:
virsh pool-dumpxml $ceph_poolHovuzun təsvirində icazə məlumatları ilə Ceph ilə əlaqə məlumatı olmalıdır.
Növbəti addım LVM şəklinin Ceph RBD-ə çevrilməsidir. İcra müddəti ilk növbədə şəklin ölçüsündən asılıdır:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameDönüşümdən sonra LVM şəkli qalacaq, bu, VM-nin RBD-yə köçürülməsi uğursuz olarsa və dəyişiklikləri geri qaytarmalı olacaqsınız. Həmçinin, dəyişiklikləri tez geri qaytarmaq üçün virtual maşın konfiqurasiya faylının ehtiyat nüsxəsini çıxaraq:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... və orijinalı redaktə edin (vm_name.xml). Diskin təsviri olan bir blok tapaq (sətirlə başlayır <disk type='file' device='disk'> və ilə bitir </disk>) və onu aşağıdakı formaya endirin:
<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>Bəzi detallara nəzər salaq:
- Protokola
sourceCeph RBD-də saxlama ünvanı göstərilir (bu, Ceph hovuzunun adını və birinci mərhələdə müəyyən edilmiş RBD şəklini göstərən ünvandır). - Blokda
secretnövü göstərilirceph, həmçinin ona qoşulmaq üçün sirrin UUID-i. Onun uuid-i əmrdən istifadə etməklə tapıla bilərvirsh secret-list. - Blokda
hostCeph monitorlarına ünvanlar göstərilir.
Konfiqurasiya faylını redaktə etdikdən və LVM-dən RBD-yə çevrilməni tamamladıqdan sonra dəyişdirilmiş konfiqurasiya faylını tətbiq edə və virtual maşını işə sala bilərsiniz:
virsh define $vm_name.xml
virsh start $vm_name
Virtual maşının düzgün işə salındığını yoxlamağın vaxtı gəldi: məsələn, SSH və ya vasitəsilə ona qoşulmaqla öyrənə bilərsiniz. virsh.
Virtual maşın düzgün işləyirsə və başqa problem tapmamısınızsa, o zaman artıq istifadə olunmayan LVM şəklini silə bilərsiniz:
lvremove main/$vm_image_nameNəticə
Təcrübədə təsvir olunan bütün hallarla qarşılaşdıq - ümid edirik ki, təlimatlar digər idarəçilərə oxşar problemləri həll etməyə kömək edəcəkdir. Ceph istifadə təcrübənizlə bağlı şərhləriniz və ya digər oxşar hekayələriniz varsa, onları şərhlərdə görməkdən şad olarıq!
PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com