Mga tip at trick para sa pakikipagtulungan kay Ceph sa mga abalang proyekto

Mga tip at trick para sa pakikipagtulungan kay Ceph sa mga abalang proyekto

Gamit ang Ceph bilang network storage sa mga proyektong may iba't ibang load, maaari tayong makatagpo ng iba't ibang gawain na sa unang tingin ay hindi mukhang simple o walang kuwenta. Halimbawa:

  • paglipat ng data mula sa lumang Ceph patungo sa bago na may bahagyang paggamit ng mga nakaraang server sa bagong cluster;
  • solusyon sa problema ng disk space allocation sa Ceph.

Sa pagharap sa mga ganitong problema, nahaharap tayo sa pangangailangang alisin nang tama ang OSD nang hindi nawawala ang data, na lalong mahalaga kapag nakikitungo sa malalaking halaga ng data. Tatalakayin ito sa artikulo.

Ang mga pamamaraan na inilarawan sa ibaba ay may kaugnayan para sa anumang bersyon ng Ceph. Bilang karagdagan, ang katotohanan na ang Ceph ay maaaring mag-imbak ng isang malaking halaga ng data ay isasaalang-alang: upang maiwasan ang pagkawala ng data at iba pang mga problema, ang ilang mga aksyon ay "hahatiin" sa maraming iba pa.

Paunang salita tungkol sa OSD

Dahil ang dalawa sa tatlong recipe na tinalakay ay nakatuon sa OSD (Daemon sa Imbakan ng Bagay), bago sumabak sa praktikal na bahagi - maikling tungkol sa kung ano ito sa Ceph at kung bakit ito napakahalaga.

Una sa lahat, dapat sabihin na ang buong cluster ng Ceph ay binubuo ng maraming OSD. Kung mas marami, mas malaki ang dami ng libreng data sa Ceph. Ito ay madaling maunawaan mula dito pangunahing function ng OSD: Nag-iimbak ito ng data ng object ng Ceph sa mga file system ng lahat ng cluster node at nagbibigay ng network access dito (para sa pagbabasa, pagsusulat, at iba pang mga kahilingan).

Sa parehong antas, ang mga parameter ng pagtitiklop ay itinakda sa pamamagitan ng pagkopya ng mga bagay sa pagitan ng iba't ibang OSD. At dito maaari kang makatagpo ng iba't ibang mga problema, ang mga solusyon na tatalakayin sa ibaba.

Kaso No. 1. Ligtas na alisin ang OSD mula sa Ceph cluster nang hindi nawawala ang data

Ang pangangailangan na tanggalin ang OSD ay maaaring sanhi ng pag-alis ng server mula sa cluster - halimbawa, upang palitan ito ng isa pang server - na kung ano ang nangyari sa amin, na nagbunga sa pagsulat ng artikulong ito. Kaya, ang pinakalayunin ng pagmamanipula ay kunin ang lahat ng OSD at mons sa isang naibigay na server upang ito ay mahinto.

Para sa kaginhawahan at upang maiwasan ang isang sitwasyon kung saan, habang nagsasagawa ng mga utos, nagkakamali kami sa pagpahiwatig ng kinakailangang OSD, magtatakda kami ng isang hiwalay na variable, ang halaga nito ay ang bilang ng OSD na tatanggalin. Tawagan natin siya ${ID} β€” dito at sa ibaba, pinapalitan ng naturang variable ang bilang ng OSD kung saan kami nagtatrabaho.

Tingnan natin ang kondisyon bago simulan ang trabaho:

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

Upang simulan ang pagtanggal ng OSD, kakailanganin mong maayos na gumanap reweight sa ito sa zero. Sa ganitong paraan binabawasan namin ang dami ng data sa OSD sa pamamagitan ng pagbabalanse nito sa ibang mga OSD. Upang gawin ito, patakbuhin ang sumusunod na mga utos:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... at iba pa hanggang sa zero.

Kinakailangan ang makinis na pagbabalansepara hindi mawalan ng data. Ito ay totoo lalo na kung ang OSD ay naglalaman ng malaking halaga ng data. Upang matiyak na pagkatapos isagawa ang mga utos reweight naging maayos ang lahat, maaari mo itong kumpletuhin ceph -s o sa isang hiwalay na terminal window run ceph -w para maobserbahan ang mga pagbabago sa real time.

Kapag ang OSD ay "nawalan ng laman", maaari kang magpatuloy sa karaniwang operasyon upang alisin ito. Upang gawin ito, ilipat ang nais na OSD sa estado down:

ceph osd down osd.${ID}

"Hilahin" natin ang OSD palabas ng cluster:

ceph osd out osd.${ID}

Itigil natin ang serbisyo ng OSD at i-unmount ang partition nito sa FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Alisin ang OSD mula sa CRUSH mapa:

ceph osd crush remove osd.${ID}

Tanggalin natin ang gumagamit ng OSD:

ceph auth del osd.${ID}

At sa wakas, alisin natin ang OSD mismo:

ceph osd rm osd.${ID}

Nota: Kung gumagamit ka ng Ceph Luminous na bersyon o mas mataas, ang mga hakbang sa pag-alis ng OSD sa itaas ay maaaring bawasan sa dalawang command:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Kung, pagkatapos makumpleto ang mga hakbang na inilarawan sa itaas, patakbuhin mo ang command ceph osd tree, kung gayon dapat na malinaw na sa server kung saan isinagawa ang gawain ay wala nang mga OSD kung saan isinagawa ang mga operasyon sa itaas:

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

Sa daan, tandaan na ang estado ng Ceph cluster ay mapupunta sa HEALTH_WARN, at makikita rin natin ang pagbaba sa bilang ng mga OSD at ang dami ng magagamit na espasyo sa disk.

Ang sumusunod ay maglalarawan ng mga hakbang na kakailanganin kung nais mong ganap na ihinto ang server at, nang naaayon, alisin ito mula sa Ceph. Sa kasong ito, mahalagang tandaan iyon Bago isara ang server, dapat mong alisin ang lahat ng OSD sa server na ito.

Kung wala nang mga OSD na natitira sa server na ito, pagkatapos na alisin ang mga ito kailangan mong ibukod ang server mula sa mapa ng OSD hv-2sa pamamagitan ng pagpapatakbo ng sumusunod na command:

ceph osd crush rm hv-2

Tanggalin mon mula sa server hv-2sa pamamagitan ng pagpapatakbo ng command sa ibaba sa isa pang server (ibig sabihin, sa kasong ito, sa hv-1):

ceph-deploy mon destroy hv-2

Pagkatapos nito, maaari mong ihinto ang server at simulan ang mga kasunod na pagkilos (muling pag-deploy nito, atbp.).

Kaso No. 2. Pamamahagi ng puwang sa disk sa isang nalikha nang Ceph cluster

Sisimulan ko ang pangalawang kuwento sa isang paunang salita tungkol sa PG (Mga Pangkat sa Paglalagay). Ang pangunahing tungkulin ng PG sa Ceph ay pangunahing pagsama-samahin ang mga bagay ng Ceph at higit pang kopyahin ang mga ito sa OSD. Ang formula kung saan maaari mong kalkulahin ang kinakailangang halaga ng PG ay nasa kaugnay na seksyon Dokumentasyon ni Ceph. Ang isyung ito ay tinalakay din doon na may mga tiyak na halimbawa.

Kaya: isa sa mga karaniwang problema kapag gumagamit ng Ceph ay ang hindi balanseng bilang ng OSD at PG sa pagitan ng mga pool sa Ceph.

Una, dahil dito, maaaring lumitaw ang isang sitwasyon kapag masyadong maraming PG ang tinukoy sa isang maliit na pool, na kung saan ay isang hindi makatwiran na paggamit ng puwang sa disk sa cluster. Pangalawa, sa pagsasanay mayroong isang mas malubhang problema: overflow ng data sa isa sa mga OSD. Nangangahulugan ito ng unang paglipat ng cluster sa estado HEALTH_WARN, at pagkatapos HEALTH_ERR. Ang dahilan nito ay si Ceph, kapag kinakalkula ang magagamit na dami ng data (maaari mong malaman ito sa pamamagitan ng MAX AVAIL sa output ng command ceph df para sa bawat pool nang hiwalay) ay batay sa dami ng magagamit na data sa OSD. Kung walang sapat na espasyo sa kahit isang OSD, wala nang data na maisusulat hanggang sa maayos na maipamahagi ang data sa lahat ng OSD.

Ito ay nagkakahalaga ng paglilinaw na ang mga problemang ito ay higit na napagpasyahan sa yugto ng pagsasaayos ng kumpol ng Ceph. Isa sa mga tool na magagamit mo ay Ceph PGCalc. Sa tulong nito, malinaw na kinakalkula ang kinakailangang halaga ng PG. Gayunpaman, maaari mo ring gamitin ito sa isang sitwasyon kung saan ang Ceph cluster na na-configure nang hindi tama. Ito ay nagkakahalaga ng paglilinaw dito na bilang bahagi ng pag-aayos ay malamang na kailangan mong bawasan ang bilang ng mga PG, at ang tampok na ito ay hindi magagamit sa mga mas lumang bersyon ng Ceph (lumalabas lamang ito sa bersyon Karakol).

Kaya, isipin natin ang sumusunod na larawan: ang kumpol ay may katayuan HEALTH_WARN dahil sa naubusan ng espasyo ang isa sa OSD. Ipapahiwatig ito ng isang error HEALTH_WARN: 1 near full osd. Nasa ibaba ang isang algorithm para makaalis sa sitwasyong ito.

Una sa lahat, kailangan mong ipamahagi ang magagamit na data sa pagitan ng mga natitirang OSD. Nagsagawa na kami ng katulad na operasyon sa unang kaso, nang "pinatuyo" namin ang node - na may pagkakaiba lamang na ngayon ay kakailanganin naming bahagyang bawasan reweight. Halimbawa, hanggang 0.95:

ceph osd reweight osd.${ID} 0.95

Ito ay nagpapalaya sa puwang sa disk sa OSD at inaayos ang error sa kalusugan ng ceph. Gayunpaman, tulad ng nabanggit na, ang problemang ito ay pangunahing nangyayari dahil sa hindi tamang pagsasaayos ng Ceph sa mga unang yugto: napakahalaga na gumawa ng muling pagsasaayos upang hindi ito lumitaw sa hinaharap.

Sa aming partikular na kaso, ang lahat ay dumating sa:

  • masyadong mataas ang halaga replication_count sa isa sa mga pool,
  • masyadong maraming PG sa isang pool at masyadong maliit sa isa pa.

Gamitin natin ang nabanggit na calculator. Malinaw na ipinapakita nito kung ano ang kailangang ipasok at, sa prinsipyo, walang kumplikado. Ang pagkakaroon ng pagtatakda ng mga kinakailangang parameter, nakukuha namin ang mga sumusunod na rekomendasyon:

Nota: Kung nagse-set up ka ng Ceph cluster mula sa simula, ang isa pang kapaki-pakinabang na function ng calculator ay ang pagbuo ng mga command na lilikha ng mga pool mula sa simula na may mga parameter na tinukoy sa talahanayan.

Tinutulungan ka ng huling column na mag-navigate - Iminungkahing Bilang ng PG. Sa aming kaso, ang pangalawa ay kapaki-pakinabang din, kung saan ipinahiwatig ang parameter ng pagtitiklop, dahil nagpasya kaming baguhin ang multiplier ng pagtitiklop.

Kaya, kailangan mo munang baguhin ang mga parameter ng pagtitiklop - ito ay karapat-dapat na gawin muna, dahil sa pamamagitan ng pagbabawas ng multiplier, palayain namin ang espasyo sa disk. Habang isinasagawa ang utos, mapapansin mong tataas ang magagamit na espasyo sa disk:

ceph osd pool $pool_name set $replication_size

At pagkatapos nitong makumpleto, binabago namin ang mga halaga ng parameter pg_num ΠΈ pgp_num tulad ng sumusunod:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Mahalagang: dapat nating baguhin ang bilang ng mga PG nang sunud-sunod sa bawat pool at huwag baguhin ang mga halaga sa iba pang mga pool hanggang sa mawala ang mga babala "Nasira ang data redundancy" ΠΈ "n-bilang ng mga pg nasira".

Maaari mo ring suriin kung naging maayos ang lahat gamit ang mga output ng command ceph health detail ΠΈ ceph -s.

Kaso No. 3. Paglipat ng virtual machine mula sa LVM patungo sa Ceph RBD

Sa isang sitwasyon kung saan ang isang proyekto ay gumagamit ng mga virtual machine na naka-install sa mga nirentahang bare-metal server, ang isyu ng fault-tolerant na storage ay madalas na lumitaw. Napakainam din na mayroong sapat na espasyo sa imbakan na ito... Isa pang karaniwang sitwasyon: mayroong isang virtual machine na may lokal na imbakan sa server at kailangan mong palawakin ang disk, ngunit walang mapupuntahan, dahil walang libreng puwang sa disk na natitira sa server.

Maaaring malutas ang problema sa iba't ibang paraan - halimbawa, sa pamamagitan ng paglipat sa ibang server (kung mayroon) o pagdaragdag ng mga bagong disk sa server. Ngunit hindi palaging posible na gawin ito, kaya ang paglipat mula sa LVM patungong Ceph ay maaaring maging isang mahusay na solusyon sa problemang ito. Sa pamamagitan ng pagpili sa opsyong ito, pinapasimple rin namin ang karagdagang proseso ng paglipat sa pagitan ng mga server, dahil hindi na kailangang ilipat ang lokal na storage mula sa isang hypervisor patungo sa isa pa. Ang tanging catch ay kailangan mong ihinto ang VM habang isinasagawa ang gawain.

Ang sumusunod na recipe ay kinuha mula sa artikulo mula sa blog na ito, ang mga tagubilin na nasubok sa pagkilos. Siya nga pala, inilarawan din doon ang paraan ng walang hirap na paglipat, gayunpaman, sa aming kaso ay hindi ito kailangan, kaya hindi namin ito sinuri. Kung ito ay kritikal para sa iyong proyekto, ikalulugod naming marinig ang tungkol sa mga resulta sa mga komento.

Lumipat tayo sa praktikal na bahagi. Sa halimbawa ginagamit namin ang virsh at, nang naaayon, libvirt. Una, tiyaking nakakonekta sa libvirt ang Ceph pool kung saan ililipat ang data:

virsh pool-dumpxml $ceph_pool

Ang paglalarawan ng pool ay dapat maglaman ng data ng koneksyon sa Ceph na may data ng pahintulot.

Ang susunod na hakbang ay ang imahe ng LVM ay na-convert sa Ceph RBD. Ang oras ng pagpapatupad ay pangunahing nakasalalay sa laki ng imahe:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Pagkatapos ng conversion, mananatili ang isang LVM na imahe, na magiging kapaki-pakinabang kung mabigo ang paglipat ng VM sa RBD at kailangan mong ibalik ang mga pagbabago. Gayundin, upang mabilis na maibalik ang mga pagbabago, gumawa tayo ng backup ng file ng configuration ng virtual machine:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... at i-edit ang orihinal (vm_name.xml). Maghanap tayo ng isang bloke na may paglalarawan ng disk (nagsisimula sa linya <disk type='file' device='disk'> at nagtatapos sa </disk>) at bawasan ito sa sumusunod na anyo:

<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>

Tingnan natin ang ilang detalye:

  1. Sa protocol source ang address sa imbakan sa Ceph RBD ay ipinahiwatig (ito ang address na nagpapahiwatig ng pangalan ng Ceph pool at ang imahe ng RBD, na natukoy sa unang yugto).
  2. Sa bloke secret uri ay ipinahiwatig ceph, pati na rin ang UUID ng sikretong kumonekta dito. Ang uuid nito ay matatagpuan gamit ang command virsh secret-list.
  3. Sa bloke host ang mga address sa mga monitor ng Ceph ay ipinahiwatig.

Pagkatapos i-edit ang configuration file at kumpletuhin ang LVM sa RBD conversion, maaari mong ilapat ang binagong configuration file at simulan ang virtual machine:

virsh define $vm_name.xml
virsh start $vm_name

Panahon na upang suriin kung nagsimula nang tama ang virtual machine: maaari mong malaman, halimbawa, sa pamamagitan ng pagkonekta dito sa pamamagitan ng SSH o sa pamamagitan ng virsh.

Kung gumagana nang tama ang virtual machine at wala kang nakitang iba pang problema, maaari mong tanggalin ang LVM na imahe na hindi na ginagamit:

lvremove main/$vm_image_name

Konklusyon

Nakatagpo namin ang lahat ng inilarawan na mga kaso sa pagsasanay - inaasahan namin na ang mga tagubilin ay makakatulong sa iba pang mga administrator na malutas ang mga katulad na problema. Kung mayroon kang mga komento o iba pang katulad na mga kuwento mula sa iyong karanasan sa paggamit ng Ceph, ikalulugod naming makita ang mga ito sa mga komento!

PS

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Magdagdag ng komento