Gan ddefnyddio Ceph fel storfa rhwydwaith mewn prosiectau â llwythi gwahanol, efallai y byddwn yn dod ar draws tasgau amrywiol nad ydynt ar yr olwg gyntaf yn ymddangos yn syml neu'n ddibwys. Er enghraifft:
- mudo data o hen Ceph i un newydd gyda defnydd rhannol o weinyddion blaenorol yn y clwstwr newydd;
- ateb i broblem dyrannu lle ar ddisg yn Ceph.
Wrth ddelio â phroblemau o'r fath, rydym yn wynebu'r angen i gael gwared ar yr OSD yn gywir heb golli data, sy'n arbennig o bwysig wrth ddelio â symiau mawr o ddata. Bydd hyn yn cael ei drafod yn yr erthygl.
Mae'r dulliau a ddisgrifir isod yn berthnasol i unrhyw fersiwn o Ceph. Yn ogystal, bydd y ffaith y gall Ceph storio llawer iawn o ddata yn cael ei ystyried: er mwyn atal colli data a phroblemau eraill, bydd rhai gweithredoedd yn cael eu “rhannu” i sawl un arall.
Rhagair am OSD
Gan fod dwy o'r tri rysáit a drafodwyd yn ymroddedig i OSD (), cyn plymio i'r rhan ymarferol - yn fyr am yr hyn ydyw yn Ceph a pham ei fod mor bwysig.
Yn gyntaf oll, dylid dweud bod clwstwr Ceph cyfan yn cynnwys llawer o OSDs. Po fwyaf sydd, y mwyaf yw cyfaint y data rhydd yn Ceph. Mae'n hawdd deall oddi yma prif swyddogaeth OSD: Mae'n storio data gwrthrych Ceph ar systemau ffeiliau pob nod clwstwr ac yn darparu mynediad rhwydwaith iddo (ar gyfer darllen, ysgrifennu, a cheisiadau eraill).
Ar yr un lefel, gosodir paramedrau atgynhyrchu trwy gopïo gwrthrychau rhwng gwahanol OSDs. Ac yma gallwch ddod ar draws problemau amrywiol, a bydd yr atebion iddynt yn cael eu trafod isod.
Achos Rhif 1. Tynnwch OSD yn ddiogel o glwstwr Ceph heb golli data
Gall yr angen i gael gwared ar yr OSD gael ei achosi trwy dynnu'r gweinydd o'r clwstwr - er enghraifft, i roi gweinydd arall yn ei le - sef yr hyn a ddigwyddodd i ni, gan arwain at ysgrifennu'r erthygl hon. Felly, y nod yn y pen draw o drin yw echdynnu'r holl OSDs a mons ar weinydd penodol fel y gellir ei atal.
Er hwylustod ac i osgoi sefyllfa lle, wrth weithredu gorchmynion, rydym yn gwneud camgymeriad wrth nodi'r OSD gofynnol, byddwn yn gosod newidyn ar wahân, a'i werth fydd nifer yr OSD i'w ddileu. Gadewch i ni ei galw ${ID} — yma ac isod, mae newidyn o'r fath yn disodli nifer yr OSD yr ydym yn gweithio ag ef.
Edrychwn 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 OSD, bydd angen i chi berfformio'n llyfn reweight arno i sero. Fel hyn rydym yn lleihau faint o ddata yn yr OSD trwy ei gydbwyso ag OSDs eraill. I wneud hyn, rhedwch 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 llyfner mwyn peidio â cholli data. Mae hyn yn arbennig o wir os yw'r OSD yn cynnwys llawer iawn o ddata. I wneud yn siŵr bod ar ôl gweithredu'r gorchmynion reweight aeth popeth yn dda, gallwch chi ei gwblhau ceph -s neu mewn rhediad ffenestr derfynell ar wahân ceph -w er mwyn gweld newidiadau mewn amser real.
Pan fydd yr OSD wedi'i “gwagio”, gallwch fwrw ymlaen â'r llawdriniaeth safonol i'w dynnu. I wneud hyn, trosglwyddwch yr OSD a ddymunir i'r wladwriaeth 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 dadosod ei raniad yn yr FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Dileu OSD o :
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}Nodyn: Os ydych chi'n defnyddio fersiwn Ceph Luminous neu'n uwch, yna gellir lleihau'r camau tynnu OSD uchod 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 nad oes bellach OSDs y cyflawnwyd y gweithrediadau uchod ar eu cyfer ar y gweinydd lle cyflawnwyd y gwaith:
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
Ar hyd y ffordd, sylwch y bydd cyflwr clwstwr Ceph yn mynd i HEALTH_WARN, a byddwn hefyd yn gweld gostyngiad yn nifer yr OSDs a faint o le ar y ddisg sydd ar gael.
Bydd y canlynol yn disgrifio'r camau y bydd eu hangen os ydych chi am atal y gweinydd yn llwyr ac, yn unol â hynny, ei dynnu oddi wrth Ceph. Yn yr achos hwn, mae'n bwysig cofio hynny Cyn cau'r gweinydd, rhaid i chi gael gwared ar yr holl OSDs ar y gweinydd hwn.
Os nad oes mwy o OSDs ar ôl ar y gweinydd hwn, yna ar ôl eu tynnu mae angen i chi eithrio'r gweinydd o'r map OSD hv-2trwy redeg y gorchymyn canlynol:
ceph osd crush rm hv-2
Dileu mon o'r gweinydd hv-2trwy redeg y gorchymyn isod ar weinydd arall (h.y. yn yr achos hwn, ymlaen hv-1):
ceph-deploy mon destroy hv-2Ar ôl hyn, gallwch chi atal y gweinydd a dechrau gweithredoedd dilynol (ei ail-leoli, ac ati).
Achos Rhif 2. Dosbarthiad gofod disg mewn clwstwr Ceph a grëwyd eisoes
Dechreuaf yr ail stori gyda rhagair am PG (). Prif rôl PG yn Ceph yn bennaf yw agregu gwrthrychau Ceph a'u hefelychu ymhellach mewn OSD. Mae'r fformiwla y gallwch chi gyfrifo'r swm gofynnol o PG ynddi Ceph dogfennaeth. Mae'r mater hwn hefyd yn cael ei drafod yno gydag enghreifftiau penodol.
Felly: un o'r problemau cyffredin wrth ddefnyddio Ceph yw'r nifer anghytbwys o OSD a PG rhwng pyllau yn Ceph.
Yn gyntaf, oherwydd hyn, gall sefyllfa godi pan nodir gormod o PGs mewn pwll bach, sydd yn ei hanfod yn ddefnydd afresymol o ofod disg yn y clwstwr. Yn ail, yn ymarferol mae problem fwy difrifol: gorlif data yn un o'r OSDs. Mae hyn yn golygu bod y clwstwr yn trosglwyddo'n gyntaf i'r wladwriaeth HEALTH_WARN, ac yna HEALTH_ERR. Y rheswm am hyn yw bod Ceph, wrth gyfrifo faint o ddata sydd ar gael (gallwch ddod o hyd iddo trwy MAX AVAIL yn yr allbwn gorchymyn ceph df ar gyfer pob cronfa ar wahân) yn seiliedig ar faint o ddata sydd ar gael yn yr OSD. Os nad oes digon o le mewn o leiaf un OSD, ni ellir ysgrifennu mwy o ddata nes bod y data wedi'i ddosbarthu'n iawn ymhlith yr holl OSDs.
Mae'n werth egluro bod y problemau hyn yn cael eu penderfynu i raddau helaeth ar gam cyfluniad clwstwr Ceph. Un o'r offer y gallwch ei ddefnyddio yw . Gyda'i help, mae'r swm gofynnol o PG wedi'i gyfrifo'n glir. Fodd bynnag, gallwch hefyd droi ato mewn sefyllfa lle mae clwstwr Ceph eisoes wedi'i ffurfweddu'n anghywir. Mae'n werth egluro yma, fel rhan o'r gwaith trwsio mae'n debygol y bydd angen i chi leihau nifer y PGs, ac nid yw'r nodwedd hon ar gael mewn fersiynau hŷn o Ceph (dim ond mewn fersiwn yr ymddangosodd ).
Felly, gadewch i ni ddychmygu'r llun canlynol: mae gan y clwstwr statws HEALTH_WARN oherwydd bod un o'r OSD yn rhedeg allan o le. Bydd hyn yn cael ei nodi gan gamgymeriad HEALTH_WARN: 1 near full osd. Isod mae algorithm ar gyfer dod allan o'r sefyllfa hon.
Yn gyntaf oll, mae angen i chi ddosbarthu'r data sydd ar gael rhwng yr OSDs sy'n weddill. Fe wnaethom eisoes gyflawni llawdriniaeth debyg yn yr achos cyntaf, pan wnaethom “ddraenio” y nod - gyda'r unig wahaniaeth y bydd angen i ni nawr leihau ychydig reweight. Er enghraifft, hyd at 0.95:
ceph osd reweight osd.${ID} 0.95Mae hyn yn rhyddhau lle disg yn yr OSD ac yn trwsio'r gwall yn iechyd ceph. Fodd bynnag, fel y crybwyllwyd eisoes, mae'r broblem hon yn digwydd yn bennaf oherwydd cyfluniad anghywir Ceph yn y camau cychwynnol: mae'n bwysig iawn gwneud ad-drefnu fel nad yw'n ymddangos yn y dyfodol.
Yn ein hachos penodol ni, daeth y cyfan i lawr i:
- gwerth yn rhy uchel
replication_countyn un o'r pyllau, - gormod o PG mewn un pwll a rhy ychydig mewn pwll arall.
Gadewch i ni ddefnyddio'r gyfrifiannell a grybwyllwyd eisoes. Mae'n dangos yn glir beth sydd angen ei gofnodi ac, mewn egwyddor, nid oes dim byd cymhleth. Ar ôl gosod y paramedrau angenrheidiol, rydym yn cael yr argymhellion canlynol:
Nodyn: Os ydych chi'n sefydlu clwstwr Ceph o'r dechrau, swyddogaeth ddefnyddiol arall y gyfrifiannell yw cynhyrchu gorchmynion a fydd yn creu pyllau o'r dechrau gyda'r paramedrau a nodir yn y tabl.
Mae'r golofn olaf yn eich helpu i lywio - Awgrym o Gyfrif PG. Yn ein hachos ni, mae'r ail un hefyd yn ddefnyddiol, lle nodir y paramedr atgynhyrchu, gan inni benderfynu newid y lluosydd atgynhyrchu.
Felly, yn gyntaf mae angen i chi newid y paramedrau atgynhyrchu - mae'n werth gwneud hyn yn gyntaf, oherwydd trwy leihau'r lluosydd, byddwn yn rhyddhau lle ar y ddisg. Wrth i'r gorchymyn weithredu, fe sylwch y bydd y gofod disg sydd ar gael yn cynyddu:
ceph osd pool $pool_name set $replication_size
Ac ar ôl ei gwblhau, rydym yn newid y gwerthoedd 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_numberMae'n bwysig: rhaid inni newid nifer y PGs yn olynol ym mhob pwll a pheidio â newid y gwerthoedd mewn pyllau eraill nes bod y rhybuddion yn diflannu "Diraddio data wedi'i ddiraddio" и "n-nifer y tudalennau wedi'u diraddio".
Gallwch hefyd wirio bod popeth wedi mynd yn dda gan ddefnyddio'r allbynnau gorchymyn ceph health detail и ceph -s.
Achos Rhif 3. Mudo peiriant rhithwir o LVM i Ceph RBD
Mewn sefyllfa lle mae prosiect yn defnyddio peiriannau rhithwir sydd wedi'u gosod ar weinyddion metel noeth sy'n cael eu rhentu, mae mater storio sy'n goddef namau yn codi'n aml. Mae hefyd yn ddymunol iawn bod digon o le yn y storfa hon ... Sefyllfa gyffredin arall: mae peiriant rhithwir gyda storfa leol ar y gweinydd ac mae angen i chi ehangu'r ddisg, ond nid oes unrhyw le i fynd, oherwydd nid oes gofod disg rhydd ar ôl ar y gweinydd.
Gellir datrys y broblem mewn gwahanol ffyrdd - er enghraifft, trwy fudo i weinydd arall (os oes un) neu ychwanegu disgiau newydd i'r gweinydd. Ond nid yw bob amser yn bosibl gwneud hyn, felly gall mudo o LVM i Ceph fod yn ateb ardderchog i'r broblem hon. Trwy ddewis yr opsiwn hwn, rydym hefyd yn symleiddio'r broses fudo bellach rhwng gweinyddwyr, gan na fydd angen symud storfa leol o un hypervisor i'r llall. Yr unig ddal yw y bydd yn rhaid i chi atal y VM tra bod y gwaith yn cael ei wneud.
Daw'r rysáit canlynol o , y mae cyfarwyddiadau wedi eu profi ar waith. Gyda llaw, disgrifir y dull o fudo di-drafferth yno hefyd, fodd bynnag, yn ein hachos ni nid oedd ei angen, felly ni wnaethom ei wirio. Os yw hyn yn hanfodol ar gyfer eich prosiect, byddwn yn falch o glywed am y canlyniadau yn y sylwadau.
Gadewch i ni symud ymlaen at y rhan ymarferol. Yn yr enghraifft rydym 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 symud iddo wedi'i gysylltu â libvirt:
virsh pool-dumpxml $ceph_poolRhaid i ddisgrifiad y gronfa gynnwys data cysylltu â Ceph gyda data awdurdodi.
Y cam nesaf yw bod y ddelwedd LVM yn cael ei throsi i Ceph RBD. Mae amser gweithredu yn dibynnu'n bennaf ar faint y ddelwedd:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameAr ôl y trawsnewid, bydd delwedd LVM yn aros, a fydd yn ddefnyddiol os bydd mudo'r VM i RBD yn methu a bod yn rhaid ichi rolio'r newidiadau yn ôl. Hefyd, er mwyn gallu dychwelyd newidiadau yn 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). Dewch i ni ddod o hyd i floc gyda disgrifiad o'r ddisg (yn dechrau gyda'r llinell <disk type='file' device='disk'> ac yn gorffen gyda </disk>) a'i leihau 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>Edrychwn ar rai manylion:
- I'r protocol
sourcenodir y cyfeiriad i'r storfa yn ABA Ceph (dyma'r cyfeiriad sy'n nodi enw pwll Ceph a'r ddelwedd RBD, a bennwyd yn y cam cyntaf). - Yn y bloc
secretnodir y mathceph, yn ogystal â UUID y gyfrinach i gysylltu ag ef. Gellir dod o hyd i'w uuid trwy ddefnyddio'r gorchymynvirsh secret-list. - Yn y bloc
hostnodir cyfeiriadau i fonitoriaid Ceph.
Ar ôl golygu'r ffeil ffurfweddu a chwblhau'r trosi 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
Mae'n bryd gwirio bod y peiriant rhithwir wedi cychwyn yn gywir: gallwch ddarganfod, er enghraifft, trwy gysylltu ag ef trwy SSH neu drwy virsh.
Os yw'r peiriant rhithwir yn gweithio'n gywir ac nad ydych wedi dod o hyd i unrhyw broblemau eraill, yna gallwch ddileu'r ddelwedd LVM nad yw'n cael ei defnyddio mwyach:
lvremove main/$vm_image_nameCasgliad
Daethom ar draws yr holl achosion a ddisgrifiwyd yn ymarferol - gobeithiwn y bydd y cyfarwyddiadau yn helpu gweinyddwyr eraill i ddatrys problemau tebyg. Os oes gennych sylwadau neu straeon tebyg eraill o'ch profiad o ddefnyddio Ceph, byddwn yn falch o'u gweld yn y sylwadau!
PS
Darllenwch hefyd ar ein blog:
- «";
- «";
- «";
- «'.
Ffynhonnell: hab.com