Завгүй төслүүдэд Цефтэй ажиллах зөвлөмж, арга

Завгүй төслүүдэд Цефтэй ажиллах зөвлөмж, арга

Ceph-ийг өөр өөр ачаалалтай төслүүдэд сүлжээний хадгалах хэрэгсэл болгон ашигласнаар бид эхлээд харахад энгийн эсвэл өчүүхэн мэт санагдах янз бүрийн ажлуудтай тулгарч магадгүй юм. Жишээлбэл:

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

Иймэрхүү асуудлуудыг шийдвэрлэхийн тулд бид OSD-ийг өгөгдлийг алдалгүйгээр зөв арилгах шаардлагатай тулгардаг бөгөөд энэ нь их хэмжээний өгөгдөлтэй ажиллахад онцгой ач холбогдолтой юм. Үүнийг нийтлэлд авч үзэх болно.

Доор тайлбарласан аргууд нь Ceph-ийн аль ч хувилбарт хамааралтай. Нэмж дурдахад, Ceph нь их хэмжээний өгөгдөл хадгалах боломжтой гэдгийг харгалзан үзэх болно: өгөгдөл алдах болон бусад асуудлаас урьдчилан сэргийлэхийн тулд зарим үйлдлүүдийг хэд хэдэн хэсэгт "хуваах" болно.

OSD-ийн тухай оршил

Хэлэлцсэн гурван жорын хоёр нь OSD-д зориулагдсан тул (Объект хадгалах дэмон), практик хэсэгт шумбахаас өмнө - энэ нь Ceph-д юу байдаг, яагаад ийм чухал болохыг товчхон хэлье.

Юуны өмнө Ceph кластер бүхэлдээ олон OSD-ээс бүрддэг гэдгийг хэлэх хэрэгтэй. Илүү их байх тусам Ceph дахь үнэгүй өгөгдлийн хэмжээ их байх болно. Эндээс ойлгоход амархан үндсэн OSD функц: Энэ нь бүх кластерийн зангилааны файлын системд Ceph объектын өгөгдлийг хадгалж, түүнд сүлжээний хандалтыг (унших, бичих болон бусад хүсэлтэд) олгодог.

Үүнтэй ижил түвшинд хуулбарлах параметрүүдийг өөр өөр OSD хооронд объектуудыг хуулах замаар тохируулдаг. Энд та янз бүрийн асуудалтай тулгарч болох бөгөөд тэдгээрийн шийдлийг доор авч үзэх болно.

Тохиолдол №1. Өгөгдөл алдалгүйгээр Ceph кластераас OSD-г аюулгүйгээр устгана уу

OSD-г устгах шаардлага нь серверийг кластераас хассанаас үүдэлтэй байж болох юм - жишээлбэл, өөр серверээр солих - энэ нь бидэнд тохиолдсон зүйл бөгөөд энэ нийтлэлийг бичихэд хүргэсэн. Тиймээс залилан хийх эцсийн зорилго нь тухайн сервер дээрх бүх OSD болон mons-ыг задлах бөгөөд ингэснээр үүнийг зогсоох боломжтой болно.

Тохиромжтой болгох, тушаалуудыг гүйцэтгэх явцад шаардлагатай 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өөр сервер дээр доорх тушаалыг ажиллуулж (жишээ нь, энэ тохиолдолд, 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-д хангалттай зай байхгүй бол өгөгдлийг бүх OSD-д зөв хуваарилах хүртэл дахиж өгөгдөл бичих боломжгүй.

Эдгээр асуудлуудыг тодруулах нь зүйтэй Ceph кластерын тохиргооны үе шатанд голчлон шийдэгддэг. Таны ашиглаж болох хэрэгслүүдийн нэг нь юм Ceph PGCalc. Түүний тусламжтайгаар PG-ийн шаардагдах хэмжээг тодорхой тооцоолно. Гэсэн хэдий ч, та Ceph кластер байгаа нөхцөл байдалд ч бас хандаж болно аль хэдийн буруу тохируулсан. Засварлах ажлын хүрээнд та PG-ийн тоог багасгах шаардлагатай бөгөөд Ceph-ийн хуучин хувилбаруудад энэ функц байхгүй (энэ нь зөвхөн хувилбарт гарч ирсэн) гэдгийг энд тодруулах нь зүйтэй. Наутилус).

Дараах зургийг төсөөлөөд үз дээ: кластер нь статустай байна 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-хуучирсан хуудасны тоо".

Та тушаалын гаралтыг ашиглан бүх зүйл сайн болсон эсэхийг шалгаж болно 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

Мөн манай блог дээрээс уншина уу:

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх