🥇Awgrymiadau a thriciau ar gyfer gweithio gyda Ceph mewn prosiectau prysur

Wrth ddefnyddio Ceph fel ateb storio rhwydwaith mewn prosiectau â llwythi gwaith amrywiol, efallai y byddwn yn dod ar draws amryw o dasgau nad ydynt efallai'n ymddangos yn syml nac yn ddibwys ar yr olwg gyntaf. Er enghraifft:

mudo data o'r hen Ceph i'r un newydd gyda defnydd rhannol o weinyddion blaenorol yn y clwstwr newydd;
Datrysiad i broblem dyrannu lle disg yn Ceph.

Wrth ymdrin â thasgau o'r fath, rydym yn wynebu'r angen i echdynnu'r OSD yn gywir heb golli data, sy'n arbennig o bwysig ar gyfer cyfrolau data mawr. Dyma fydd yr erthygl hon yn ei drafod.

Mae'r dulliau a ddisgrifir isod yn berthnasol i bob fersiwn o Ceph. Ar ben hynny, byddwn yn ystyried y ffaith y gall Ceph storio symiau mawr o ddata: er mwyn atal colli data a phroblemau eraill, bydd rhai gweithrediadau'n cael eu rhannu'n sawl cam ar wahân.

Cyflwyniad i OSD

Gan fod dau o'r tri rysáit dan sylw wedi'u neilltuo i OSD (Daemon Storio Gwrthrychau), cyn plymio i'r rhan ymarferol - trosolwg byr o beth yw Ceph a pham ei fod mor bwysig.

Yn gyntaf oll, dylid nodi bod clwstwr cyfan Ceph yn cynnwys nifer o OSDs. Po fwyaf o OSDs sydd, y mwyaf yw cyfaint y data rhydd yn Ceph. Mae hyn yn ei gwneud hi'n hawdd ei ddeall. prif swyddogaeth yr OSDMae'n storio data gwrthrych Ceph ar systemau ffeiliau pob nod clwstwr ac yn darparu mynediad rhwydwaith iddynt (ar gyfer darllen, ysgrifennu, a cheisiadau eraill).

Ar y lefel hon, mae paramedrau dyblygu hefyd yn cael eu gosod trwy gopïo gwrthrychau rhwng gwahanol OSDau. Gall amrywiol broblemau godi yma, a thrafodir atebion isod.

Astudiaeth Achos #1: Dileu OSD yn Ddiogel o Glwstwr Ceph Heb Golli Data

Gall yr angen i gael gwared ar OSD godi pan gaiff gweinydd ei dynnu o glwstwr—er enghraifft, i'w ddisodli gan weinydd arall—sef yr hyn a ddigwyddodd i ni, gan ysgogi'r erthygl hon. Felly, nod eithaf y triniaethau hyn yw cael gwared ar bob OSD a mons ar weinydd penodol fel y gellir ei gau i lawr.

Er hwylustod ac i osgoi sefyllfaoedd lle byddwn yn gwneud camgymeriad wrth nodi'r OSD a ddymunir wrth weithredu gorchmynion, byddwn yn diffinio newidyn ar wahân y bydd ei werth yn rhif yr OSD sy'n cael ei ddileu. Byddwn yn ei alw'n ${ID} — o hyn ymlaen, mae newidyn o'r fath yn disodli'r rhif OSD rydym yn gweithio ag ef.

Gadewch i ni edrych ar y cyflwr cyn dechrau gweithio:

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

I gychwyn tynnu'r OSD, bydd angen i chi berfformio'n llyfn reweight Arno, rydym yn lleihau faint o ddata yn yr OSD trwy ei gydbwyso ar draws OSDau eraill. I wneud hyn, gweithredwch y gorchmynion canlynol:

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

… ac yn y blaen tan sero.

Angen cydbwyso llyfni osgoi colli data. Mae hyn yn arbennig o bwysig os yw'r OSD yn cynnwys llawer iawn o ddata. Er mwyn sicrhau, ar ôl gweithredu'r gorchmynion reweight Aeth popeth yn dda, gallwch chi ei wneud ceph -s neu ei redeg mewn ffenestr derfynell ar wahân ceph -w er mwyn arsylwi newidiadau mewn amser real.

Unwaith y bydd yr OSD yn "wag," gallwch fwrw ymlaen â'r llawdriniaeth tynnu safonol. I wneud hyn, byddwn yn gosod yr OSD a ddymunir i'r cyflwr "gwag". down:

ceph osd down osd.${ID}

Gadewch i ni "dynnu" yr OSD allan o'r clwstwr:

ceph osd out osd.${ID}

Gadewch i ni atal y gwasanaeth OSD a dad-osod ei raniad yn y system ffeiliau:

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

Tynnu OSD o Map CRUSH:

ceph osd crush remove osd.${ID}

Gadewch i ni ddileu'r defnyddiwr OSD:

ceph auth del osd.${ID}

Ac yn olaf, gadewch i ni gael gwared ar yr OSD ei hun:

ceph osd rm osd.${ID}

NodynOs ydych chi'n defnyddio Ceph Luminous neu uwch, gellir lleihau'r camau uchod ar gyfer cael gwared ar yr OSD i ddau orchymyn:

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

Os ar ôl cwblhau'r camau a ddisgrifir uchod rydych chi'n rhedeg y gorchymyn ceph osd tree, yna dylai fod yn glir, ar y gweinydd lle perfformiwyd y gwaith, nad oes mwy o OSDau y perfformiwyd y gweithrediadau uchod ar eu cyfer:

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

Wrth fynd heibio, nodwn y bydd cyflwr clwstwr Ceph yn mynd i mewn i HEALTH_WARN, a byddwn hefyd yn gweld gostyngiad yn nifer yr OSDs a faint o le disg sydd ar gael.

Isod byddwn yn disgrifio'r camau sydd eu hangen os ydych chi am atal y gweinydd yn llwyr ac, o ganlyniad, ei dynnu o Ceph. Yn yr achos hwn, mae'n bwysig cofio hynny Cyn cau'r gweinydd i lawr, rhaid i chi ddileu'r holl OSDs. ar y gweinydd hwn.

Os nad oes mwy o OSDau ar ôl ar y gweinydd hwn, yna ar ôl eu dileu, mae angen i chi eithrio'r gweinydd OSD o'r map. hv-2trwy redeg y gorchymyn canlynol:

ceph osd crush rm hv-2

Dileu mon o'r gweinydd hv-2, rhedeg y gorchymyn isod ar weinydd arall (h.y. yn yr achos hwn - ar hv-1):

ceph-deploy mon destroy hv-2

Ar ôl hyn, gallwch atal y gweinydd a bwrw ymlaen â chamau dilynol (ei ail-leoli, ac ati).

Astudiaeth Achos #2: Dyrannu Lle Disg mewn Clwstwr Ceph Presennol

Dechreuaf yr ail stori gyda rhagair am PG (Grwpiau Lleoli). Prif rôl PG yn Ceph yw crynhoi gwrthrychau Ceph ac yna eu hailadrodd i'r OSD. Mae'r fformiwla ar gyfer cyfrifo'r nifer gofynnol o PGs yn adran berthnasol Dogfennaeth Ceph. Trafodir y mater hwn yno hefyd, gydag enghreifftiau penodol.

Felly, un o'r problemau cyffredin wrth redeg Ceph yw nifer anghytbwys o OSDs a PGs rhwng pyllau yn Ceph.

Yn gyntaf, gall hyn arwain at sefyllfa lle mae gormod o PGs wedi'u pennu mewn pwll bach, sydd i bob pwrpas yn gwastraffu lle disg yn y clwstwr. Yn ail, yn ymarferol, mae problem fwy difrifol yn codi: gorlif data yn un o'r OSDs. Mae hyn yn achosi i'r clwstwr fynd i gyflwr yn gyntaf HEALTH_WARN, ac yna HEALTH_ERRY rheswm am hyn yw bod Ceph, wrth gyfrifo'r gyfaint data sydd ar gael (gallwch ei ddarganfod trwy MAX AVAIL yn yr allbwn gorchymyn ceph df Mae dyraniad lle (ar gyfer pob pwll ar wahân) yn seiliedig ar faint o ddata sydd ar gael yn yr OSD. Os bydd hyd yn oed un OSD yn rhedeg allan o le, ni ellir ysgrifennu mwy o ddata nes bod y data wedi'i ddosbarthu'n iawn ar draws yr holl OSDs.

Mae'n werth egluro bod y problemau hyn yn cael eu datrys i raddau helaeth yng nghyfnod ffurfweddu clwstwr CephUn o'r offer y gellir eu defnyddio yw Ceph PGCalcMae'n caniatáu ichi gyfrifo'n glir y nifer gofynnol o PGs. Fodd bynnag, gellir ei ddefnyddio hefyd mewn sefyllfaoedd lle mae'r clwstwr Ceph eisoes wedi'i ffurfweddu'n anghywir. Mae'n werth egluro yma, fel rhan o'r ateb, y bydd angen i chi leihau nifer y PGs yn fwyaf tebygol, ac nid yw'r nodwedd hon ar gael mewn fersiynau hŷn o Ceph (dim ond yn fersiwn Nautilus).

Felly, gadewch i ni ddychmygu'r darlun canlynol: mae gan y clwstwr y statws HEALTH_WARN Oherwydd bod un o'r OSDs yn rhedeg allan o le. Bydd hyn yn cael ei nodi gan wall. HEALTH_WARN: 1 near full osdIsod mae algorithm ar gyfer dianc o'r sefyllfa hon.

Yn gyntaf, mae angen i ni ddosbarthu'r data presennol ymhlith y OSDs sy'n weddill. Rydym eisoes wedi perfformio llawdriniaeth debyg yn yr achos cyntaf pan wnaethom "ddraenio" y nod—yr unig wahaniaeth yw y bydd angen i ni nawr leihau ychydig reweightEr enghraifft, hyd at 0.95:

ceph osd reweight osd.${ID} 0.95

Mae hyn yn rhyddhau lle ar y ddisg yn yr OSD ac yn cywiro'r gwall iechyd Ceph. Fodd bynnag, fel y soniwyd yn gynharach, mae'r broblem hon yn cael ei hachosi'n bennaf gan ffurfweddiad anghywir Ceph yn ystod y camau cychwynnol: mae'n hanfodol ei hail-ffurfweddu i'w atal rhag digwydd eto.

Yn ein hachos penodol ni, roedd popeth yn dibynnu ar:

gormod o werth replication_count yn un o'r pyllau nofio,
gormod o PG mewn un pwll a rhy ychydig yn y llall.

Gadewch i ni ddefnyddio'r gyfrifiannell a soniais amdani yn gynharach. Mae'n dangos yn glir beth sydd angen ei nodi, a does dim byd cymhleth amdano. Ar ôl nodi'r paramedrau gofynnol, cawn yr argymhellion canlynol:

NodynOs ydych chi'n sefydlu clwstwr Ceph o'r dechrau, nodwedd ddefnyddiol arall o'r gyfrifiannell yw y gall gynhyrchu gorchmynion a fydd yn creu pyllau o'r dechrau gyda'r paramedrau a bennir yn y tabl.

Mae'r golofn olaf yn eich helpu i gael eich cyfeiriadau: Cyfrif PG AwgrymedigYn ein hachos ni, mae'r ail un, sy'n nodi'r paramedr dyblygu, hefyd yn ddefnyddiol, gan ein bod wedi penderfynu newid y lluosydd dyblygu hefyd.

Felly, yn gyntaf, bydd angen i chi newid y paramedrau dyblygu—mae hwn yn gam cyntaf da, gan y bydd lleihau'r lluosydd yn rhyddhau lle ar y ddisg. Wrth i'r gorchymyn redeg, fe sylwch fod gwerth y lle ar y ddisg sydd ar gael yn cynyddu:

ceph osd pool $pool_name set $replication_size

Ac ar ôl ei gwblhau, rydym yn newid gwerthoedd y paramedr pg_num и pgp_num fel a ganlyn:

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

Mae'n bwysigrhaid inni newid nifer y PGs ym mhob pwll yn olynol a pheidio â newid y gwerthoedd mewn pyllau eraill nes bod y rhybuddion yn diflannu Diswyddiad data wedi'i ddirywio и "n-nifer o dudiadau wedi'u diraddio".

Gallwch hefyd wirio bod popeth wedi mynd yn llwyddiannus gan ddefnyddio allbynnau'r gorchymyn. ceph health detail и ceph -s.

Astudiaeth Achos #3: Mudo Peiriant Rhithwir o LVM i Ceph RBD

Pan fydd prosiect yn defnyddio peiriannau rhithwir sydd wedi'u gosod ar weinyddion metel noeth ar brydles, mae problem storio sy'n goddef nam yn aml yn codi. Mae hefyd yn ddymunol iawn cael digon o le storio... Sefyllfa gyffredin arall: mae peiriant rhithwir gyda storfa leol ar y gweinydd ac mae angen i chi ehangu'r ddisg, ond nid oes lle i wneud hynny oherwydd bod y gweinydd yn llawn.

Mae sawl ffordd o ddatrys y broblem hon, fel mudo i weinydd arall (os yw ar gael) neu ychwanegu disgiau newydd at y gweinydd. Fodd bynnag, nid yw hyn bob amser yn bosibl, felly gall mudo o LVM i Ceph fod yn ateb ardderchog. Drwy ddewis yr opsiwn hwn, rydym hefyd yn symleiddio'r broses fudo ddilynol rhwng gweinyddion, gan nad oes angen symud storfa leol o un hypervisor i un arall. Yr unig broblem yw y bydd yn rhaid i chi atal y VM tra bod y gwaith yn cael ei wneud.

Mae'r rysáit a roddir isod yn seiliedig ar erthygl o'r blog hwn, y profwyd y cyfarwyddiadau ar waith. Gyda llaw, disgrifir dull ar gyfer mudo di-dor yno hefyd, ond yn ein hachos ni, nid oedd ei angen o gwbl, felly ni wnaethom ei brofi. Os yw hyn yn hanfodol i'ch prosiect, byddem wrth ein bodd yn clywed eich canlyniadau yn y sylwadau.

Gadewch i ni symud ymlaen at y rhan ymarferol. Yn yr enghraifft hon, byddwn yn defnyddio virsh ac, yn unol â hynny, libvirt. Yn gyntaf, gwnewch yn siŵr bod y pwll Ceph y bydd y data'n cael ei fudo iddo wedi'i gysylltu â libvirt:

virsh pool-dumpxml $ceph_pool

Rhaid i ddisgrifiad y pwll gynnwys data cysylltiad Ceph gyda data awdurdodi.

Y cam nesaf yw trosi'r ddelwedd LVM i Ceph RBD. Mae'r amser y mae'n ei gymryd i gwblhau'r broses hon yn dibynnu'n bennaf ar faint y ddelwedd:

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

Ar ôl y trawsnewid, byddwch ar ôl gyda delwedd LVM, a fydd yn ddefnyddiol os bydd mudo'r VM i RBD yn methu ac mae angen i chi ddiddymu'r newidiadau. Hefyd, i ddiddymu newidiadau'n gyflym, gadewch i ni wneud copi wrth gefn o ffeil ffurfweddu'r peiriant rhithwir:

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

…a golygu'r gwreiddiol (vm_name.xml). Gadewch i ni ddod o hyd i'r bloc gyda disgrifiad y ddisg (yn dechrau gyda'r llinell <disk type='file' device='disk'> ac yn gorffen gyda </disk>) a'i ddwyn i'r ffurf ganlynol:

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

Beth am edrych ar rai manylion:

Yn y protocol source Mae cyfeiriad y storfa yn Ceph RBD wedi'i nodi (dyma'r cyfeiriad sy'n nodi enw'r pwll Ceph a'r ddelwedd RBD a bennwyd yn y cam cyntaf).
Yn y bloc secret mae'r math wedi'i nodi ceph, yn ogystal ag UUID y gyfrinach i gysylltu ag ef. Gellir dod o hyd i'w UUID gan ddefnyddio'r gorchymyn virsh secret-list.
Yn y bloc host Mae cyfeiriadau i fonitorau Ceph wedi'u nodi.

Ar ôl i chi olygu'r ffeil ffurfweddu a chwblhau'r trosi o LVM i RBD, gallwch gymhwyso'r ffeil ffurfweddu wedi'i haddasu a chychwyn y peiriant rhithwir:

virsh define $vm_name.xml
virsh start $vm_name

Nawr yw'r amser i wirio bod y peiriant rhithwir wedi cychwyn yn gywir: gallwch ddarganfod hyn, er enghraifft trwy gysylltu ag ef trwy SSH neu virsh.

Os yw'r peiriant rhithwir yn gweithio'n gywir ac nad ydych wedi canfod unrhyw broblemau eraill, gallwch ddileu'r ddelwedd LVM nad yw'n cael ei defnyddio mwyach:

lvremove main/$vm_image_name

Casgliad

Rydym wedi dod ar draws yr holl achosion a ddisgrifiwyd yn ymarferol, a gobeithiwn y bydd y cyfarwyddiadau hyn yn helpu gweinyddwyr eraill i ddatrys problemau tebyg. Os oes gennych unrhyw sylwadau neu straeon tebyg eraill o'ch profiad gyda Ceph, byddem wrth ein bodd yn eu clywed yn y sylwadau!