ProHoster > Blog > башкаруу > Кеп долбоорлордо Ceph менен иштөө боюнча кеңештер жана ыкмалар

Кеп долбоорлордо Ceph менен иштөө боюнча кеңештер жана ыкмалар

Кеп долбоорлордо Ceph менен иштөө боюнча кеңештер жана ыкмалар

Cephти ар кандай жүктөмдүү долбоорлордо тармактык сактагыч катары колдонуу менен, биз бир караганда жөнөкөй же анча маанилүү эместей көрүнгөн ар кандай тапшырмаларга туш болушубуз мүмкүн. Мисалы:

  • жаңы кластердеги мурунку серверлерди жарым-жартылай колдонуу менен маалыматтарды эски Cephтен жаңысына көчүрүү;
  • Ceph ичинде диск мейкиндигин бөлүштүрүү маселесин чечүү.

Мындай көйгөйлөр менен күрөшүүдө биз OSDди маалыматтарды жоготпостон туура алып салуу зарылчылыгына туш болдук, бул чоң көлөмдөгү маалыматтар менен иштөөдө өзгөчө маанилүү. Бул макалада талкууланат.

Төмөндө сүрөттөлгөн ыкмалар Cephтин каалаган версиясына тиешелүү. Мындан тышкары, Ceph маалыматтардын чоң көлөмүн сактай ала тургандыгы эске алынат: маалыматтарды жоготуу жана башка көйгөйлөрдү алдын алуу үчүн, кээ бир иш-аракеттер бир нече башкага "бөлүнгөн" болот.

OSD жөнүндө кириш сөз

Талкууланган үч рецепттин экөө OSDге арналгандыктан (Object Storage Daemon), практикалык бөлүккө кирүүдөн мурун - анын Cephде эмне бар жана эмне үчүн мынчалык маанилүү экендиги жөнүндө кыскача.

Биринчиден, бүт Ceph кластери көптөгөн OSDлерден турат деп айтуу керек. Канчалык көп болсо, Cephдеги эркин маалымат көлөмү ошончолук чоң болот. Бул жерден түшүнүү оңой негизги OSD функциясы: Ал бардык кластердик түйүндөрдүн файлдык тутумдарында Ceph объектинин маалыматтарын сактайт жана ага жетүү мүмкүнчүлүгүн берет (окуу, жазуу жана башка суроо-талаптар үчүн).

Ошол эле деңгээлде, репликация параметрлери объекттерди ар кандай OSDлердин ортосунда көчүрүү жолу менен коюлат. Ал эми бул жерде сиз ар кандай көйгөйлөргө туш болот, аларды чечүү жолдору төмөндө талкууланат.

№1 иш. Дайындарды жоготпостон 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 ал боюнча нөлгө. Ушундай жол менен биз экрандагы маалыматтардын көлөмүн азайтып, аны башка экрандык дисплейлерге теңдештиребиз. Бул үчүн, төмөнкү буйруктарды аткарыңыз:

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башка серверде төмөнкү буйрукту иштетүү менен (мисалы, бул учурда, on hv-1):

ceph-deploy mon destroy hv-2

Андан кийин, сиз серверди токтотуп, кийинки аракеттерди баштасаңыз болот (аны кайра жайгаштыруу ж.б.).

№2 иш. Буга чейин түзүлгөн Ceph кластеринде диск мейкиндигин бөлүштүрүү

Мен экинчи окуяны PG жөнүндө кириш сөз менен баштайм (Жайгаштыруу топтору). Cephтеги PGдин негизги ролу, биринчи кезекте, Ceph объекттерин бириктирүү жана аларды OSDде андан ары кайталоо. PGнын керектүү көлөмүн эсептей турган формула бар тиешелүү бөлүм Ceph документтери. Бул маселе ошол жерде да конкреттүү мисалдар менен талкууланат.

Ошентип: Cephди колдонууда кеңири таралган көйгөйлөрдүн бири Cephдеги бассейндердин ортосундагы OSD жана PGтин тең салмактуу эмес саны.

Биринчиден, ушундан улам, кичинекей бассейнде өтө көп PG көрсөтүлгөн жагдай пайда болушу мүмкүн, бул кластердеги диск мейкиндигин сарамжалдуу эмес пайдалануу. Экинчиден, иш жүзүндө бир кыйла олуттуу көйгөй бар: OSDлердин биринде маалыматтардын ашып кетиши. Бул кластердин биринчи мамлекетке өтүшүн талап кылат 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. Мисалы, 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-саты бузулган".

Сиз ошондой эле буйрук чыгарууларды колдонуу менен баары жакшы болгонун текшере аласыз ceph health detail и ceph -s.

№3 иш. Виртуалдык машинаны 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

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Комментарий кошуу