Ábendingar og brellur til að vinna með Ceph í annasömum verkefnum

Með því að nota Ceph sem netgeymslu í verkefnum með mismunandi álag gætum við lent í ýmsum verkefnum sem við fyrstu sýn virðast ekki einföld eða léttvæg. Til dæmis:

• flutningur gagna frá gamla Ceph yfir í nýjan með hluta notkun fyrri netþjóna í nýja klasanum;
• lausn á vandamálinu við úthlutun diskpláss í Ceph.

Við að takast á við slík vandamál stöndum við frammi fyrir þörfinni á að fjarlægja OSD rétt án þess að tapa gögnum, sem er sérstaklega mikilvægt þegar um er að ræða mikið magn af gögnum. Um þetta verður fjallað í greininni.

Aðferðirnar sem lýst er hér að neðan eiga við fyrir hvaða útgáfu sem er af Ceph. Að auki verður tekið tillit til þess að Ceph getur geymt mikið magn af gögnum: til að koma í veg fyrir gagnatap og önnur vandamál verða sumar aðgerðir „skipt“ í nokkrar aðrar.

Formáli um OSD

Þar sem tvær af þremur uppskriftum sem fjallað er um eru tileinkaðar OSD (Hlutageymslupúki), áður en farið er í verklega hlutann - stuttlega um hvað það er í Ceph og hvers vegna það er svo mikilvægt.

Fyrst af öllu ætti að segja að allur Ceph þyrpingin samanstendur af mörgum OSD. Því fleiri sem eru, því meira er ókeypis gagnamagn í Ceph. Það er auðvelt að skilja það héðan aðal OSD aðgerð: Það geymir Ceph-hlutagögn á skráarkerfum allra klasahnúta og veitir netaðgang að þeim (til að lesa, skrifa og aðrar beiðnir).

Á sama stigi eru afritunarfæribreytur stilltar með því að afrita hluti á milli mismunandi OSD. Og hér getur þú lent í ýmsum vandamálum, lausnirnar sem verða ræddar hér að neðan.

1. mál. Fjarlægðu OSD á öruggan hátt úr Ceph þyrpingunni án þess að tapa gögnum

Þörfin á að fjarlægja OSD gæti stafað af því að þjónninn er fjarlægður úr þyrpingunni - til dæmis til að skipta honum út fyrir annan netþjón - sem er það sem gerðist hjá okkur og varð tilefni til að skrifa þessa grein. Þannig er lokamarkmið meðhöndlunar að draga út allar OSD og mons á tilteknum netþjóni svo hægt sé að stöðva hana.

Til hægðarauka og til að forðast aðstæður þar sem við gerum mistök við að tilgreina nauðsynlega OSD á meðan skipanir eru keyrðar, munum við setja sérstaka breytu, gildi hennar verður númerið á OSD sem á að eyða. Við skulum hringja í hana ${ID} — hér og hér að neðan kemur slík breyta í stað númers OSD sem við erum að vinna með.

Við skulum skoða ástandið áður en unnið er:

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

Til að hefja fjarlægingu á OSD þarftu að framkvæma vel reweight á það í núll. Þannig minnkum við magn gagna í OSD með því að jafna það við aðrar OSD. Til að gera þetta skaltu keyra eftirfarandi skipanir:

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

... og svo framvegis þar til núllið er.

Slétt jafnvægi krafisttil að missa ekki gögn. Þetta á sérstaklega við ef OSD inniheldur mikið magn af gögnum. Til að ganga úr skugga um að eftir að hafa keyrt skipanirnar reweight allt gekk vel, þú getur klárað það ceph -s eða í sérstakri flugstöðvarglugga ceph -w til að fylgjast með breytingum í rauntíma.

Þegar OSD er „tæmt“ geturðu haldið áfram með venjulegu aðgerðina til að fjarlægja hana. Til að gera þetta skaltu flytja viðeigandi OSD til ríkisins down:

ceph osd down osd.${ID}

Við skulum „draga“ OSD út úr þyrpingunni:

ceph osd out osd.${ID}

Við skulum stöðva OSD þjónustuna og aftengja skiptinguna í FS:

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

Fjarlægðu OSD úr CRUSH kort:

ceph osd crush remove osd.${ID}

Eyðum OSD notandanum:

ceph auth del osd.${ID}

Og að lokum skulum við fjarlægja OSD sjálft:

ceph osd rm osd.${ID}

Athugið: Ef þú ert að nota Ceph Luminous útgáfu eða nýrri, þá er hægt að minnka skrefin til að fjarlægja OSD hér að ofan í tvær skipanir:

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

Ef þú keyrir skipunina eftir að hafa lokið skrefunum sem lýst er hér að ofan ceph osd tree, þá ætti það að vera ljóst að á þjóninum þar sem vinnan var framkvæmd eru ekki lengur OSDs sem ofangreindar aðgerðir voru gerðar fyrir:

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

Á leiðinni, athugaðu að ástand Ceph þyrpingarinnar mun fara til HEALTH_WARN, og við munum einnig sjá fækkun á fjölda skjámynda og magni af tiltæku plássi.

Eftirfarandi mun lýsa þeim skrefum sem þarf ef þú vilt stöðva þjóninn algjörlega og, í samræmi við það, fjarlægja hann úr Ceph. Í þessu tilfelli er mikilvægt að muna það Áður en þú slekkur á netþjóninum verður þú að fjarlægja allar OSD á þessum server.

Ef það eru ekki fleiri OSD eftir á þessum þjóni, þá þarftu að útiloka þjóninn frá OSD kortinu eftir að hafa fjarlægt þær hv-2með því að keyra eftirfarandi skipun:

ceph osd crush rm hv-2

Eyða mon frá þjóninum hv-2með því að keyra skipunina fyrir neðan á öðrum netþjóni (þ.e. í þessu tilfelli, á hv-1):

ceph-deploy mon destroy hv-2

Eftir þetta geturðu stöðvað netþjóninn og byrjað á síðari aðgerðir (endursetja hann osfrv.).

2. mál. Dreifing diskpláss í þegar búið til Ceph þyrping

Ég mun byrja seinni söguna með formála um PG (Staðsetningarhópar). Meginhlutverk PG í Ceph er fyrst og fremst að safna saman Ceph hlutum og endurtaka þá frekar í OSD. Formúlan sem þú getur reiknað út nauðsynlegt magn af PG er í viðkomandi kafla Ceph skjöl. Þar er einnig fjallað um þetta mál með sérstökum dæmum.

Svo: eitt af algengustu vandamálunum við notkun Ceph er ójafnvægi á OSD og PG á milli lauga í Ceph.

Í fyrsta lagi, vegna þessa, getur komið upp sú staða þegar of mörg PG eru tilgreind í litlum laug, sem er í rauninni óskynsamleg notkun á diskplássi í þyrpingunni. Í öðru lagi, í reynd er alvarlegra vandamál: gagnaflæði í einni af OSD. Þetta felur í sér að klasinn færist fyrst til ríkisins HEALTH_WARN, og svo HEALTH_ERR. Ástæðan fyrir þessu er sú að Ceph, þegar þú reiknar út tiltækt magn gagna (þú getur fundið það út með því að MAX AVAIL í skipunarúttakinu ceph df fyrir hverja laug fyrir sig) er byggt á magni tiltækra gagna í OSD. Ef það er ekki nóg pláss í að minnsta kosti einni OSD er ekki hægt að skrifa fleiri gögn fyrr en gögnunum er rétt dreift meðal allra OSD.

Það er rétt að skýra að þessi vandamál eru að mestu leyti ákveðnar á Ceph klasastillingarstigi. Eitt af verkfærunum sem þú getur notað er Ceph PGCalc. Með hjálp þess er nauðsynlegt magn af PG greinilega reiknað út. Hins vegar getur þú líka gripið til þess í aðstæðum þar sem Ceph þyrpingin þegar rangt stillt. Það er þess virði að skýra það hér að sem hluti af lagfæringunni þarftu líklegast að fækka PGs og þessi eiginleiki er ekki tiltækur í eldri útgáfum af Ceph (hann birtist aðeins í útgáfu Nautilus).

Svo, við skulum ímynda okkur eftirfarandi mynd: þyrpingin hefur stöðu HEALTH_WARN vegna þess að einn af OSD er að verða uppiskroppa með pláss. Þetta verður gefið til kynna með villu HEALTH_WARN: 1 near full osd. Hér að neðan er reiknirit til að komast út úr þessum aðstæðum.

Fyrst af öllu þarftu að dreifa tiltækum gögnum á milli þeirra OSD sem eftir eru. Við gerðum þegar svipaða aðgerð í fyrra tilvikinu, þegar við „tæmdum“ hnútinn - með þeim eina mun að nú þurfum við að minnka aðeins reweight. Til dæmis, allt að 0.95:

ceph osd reweight osd.${ID} 0.95

Þetta losar um pláss í OSD og lagar villuna í ceph heilsu. Hins vegar, eins og áður hefur verið nefnt, kemur þetta vandamál aðallega fram vegna rangrar uppsetningar á Ceph á fyrstu stigum: það er mjög mikilvægt að gera endurstillingu þannig að það birtist ekki í framtíðinni.

Í okkar sérstöku tilviki kom þetta allt niður á:

• gildi of hátt replication_count í einni af laugunum,
• of mikið PG í einni laug og of lítið í annarri.

Við skulum nota reiknivélina sem áður hefur verið nefnd. Það sýnir vel hvað þarf að slá inn og í grundvallaratriðum er ekkert flókið. Eftir að hafa stillt nauðsynlegar færibreytur fáum við eftirfarandi ráðleggingar:

Athugið: Ef þú ert að setja upp Ceph þyrping frá grunni, þá er önnur gagnleg aðgerð reiknivélarinnar að búa til skipanir sem búa til laugar frá grunni með breytunum sem tilgreindar eru í töflunni.

Síðasti dálkurinn hjálpar þér að fletta - Ráðlagður PG talning. Í okkar tilviki er sá seinni líka gagnlegur, þar sem afritunarbreytan er tilgreind, þar sem við ákváðum að breyta margfaldaranum.

Svo fyrst þarftu að breyta afritunarbreytunum - þetta er þess virði að gera fyrst, þar sem með því að minnka margfaldarann ​​munum við losa um pláss. Þegar skipunin keyrir muntu taka eftir því að tiltækt pláss mun aukast:

ceph osd pool $pool_name set $replication_size

Og eftir að því er lokið breytum við breytugildunum pg_num и pgp_num sem hér segir:

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

Það er mikilvægt: við verðum að breyta fjölda PGs í röð í hverri laug og ekki breyta gildunum í öðrum laugum fyrr en viðvaranirnar hverfa „Minni gagnaofframboð“ и "n-fjöldi blaðsíðna rýrnað".

Þú getur líka athugað hvort allt hafi gengið vel með því að nota skipanaúttakin ceph health detail и ceph -s.

3. mál. Flytja sýndarvél frá LVM til Ceph RBD

Í aðstæðum þar sem verkefni notar sýndarvélar sem eru settar upp á leigðum berum málmþjónum, kemur oft upp vandamálið um bilunarþolna geymslu. Það er líka mjög æskilegt að það sé nóg pláss í þessari geymslu... Önnur algeng staða: það er sýndarvél með staðbundinni geymslu á þjóninum og þú þarft að stækka diskinn, en það er hvergi að fara, því það er engin laust pláss eftir á þjóninum.

Vandamálið er hægt að leysa á mismunandi vegu - til dæmis með því að flytja yfir á annan netþjón (ef hann er til) eða bæta nýjum diskum við netþjóninn. En það er ekki alltaf hægt að gera þetta, svo að flytja frá LVM til Ceph getur verið frábær lausn á þessu vandamáli. Með því að velja þennan valkost einföldum við einnig frekara ferli flutnings milli netþjóna, þar sem engin þörf er á að færa staðbundna geymslu frá einum hypervisor til annars. Eini gallinn er sá að þú verður að stöðva VM meðan verkið er unnið.

Eftirfarandi uppskrift er tekin úr grein af þessu bloggi, en leiðbeiningarnar hafa verið prófaðar í verki. Við the vegur, Þar er einnig lýst aðferðinni við vandræðalausa fólksflutninga, hins vegar var það einfaldlega ekki þörf í okkar tilfelli, svo við athuguðum það ekki. Ef þetta er mikilvægt fyrir verkefnið þitt munum við vera ánægð að heyra um niðurstöðurnar í athugasemdunum.

Við skulum halda áfram að verklega hlutanum. Í dæminu notum við virsh og, í samræmi við það, libvirt. Fyrst skaltu ganga úr skugga um að Ceph laugin sem gögnin verða flutt í sé tengd við libvirt:

virsh pool-dumpxml $ceph_pool

Laugarlýsingin skal innihalda tengigögn til Ceph með heimildargögnum.

Næsta skref er að LVM myndinni er breytt í Ceph RBD. Framkvæmdartími fer fyrst og fremst eftir stærð myndarinnar:

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

Eftir umbreytinguna verður LVM mynd eftir, sem mun vera gagnlegt ef flutningur VM til RBD mistekst og þú verður að draga breytingarnar til baka. Einnig, til að geta afturkallað breytingar fljótt, skulum við taka öryggisafrit af stillingarskrá sýndarvélarinnar:

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

... og breyttu frumritinu (vm_name.xml). Við skulum finna blokk með lýsingu á disknum (byrjar á línunni <disk type='file' device='disk'> og endar með </disk>) og minnkaðu það í eftirfarandi form:

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

Við skulum skoða nokkur smáatriði:

1. Til bókunar source heimilisfangið á geymsluna í Ceph RBD er gefið upp (þetta er heimilisfangið sem gefur til kynna nafn Ceph laugarinnar og RBD myndina, sem var ákvarðað á fyrsta stigi).
2. Í blokkinni secret gerð er tilgreind ceph, sem og UUID leyndarmálsins til að tengjast því. Uuid þess er að finna með því að nota skipunina virsh secret-list.
3. Í blokkinni host heimilisföng til Ceph skjáa eru tilgreind.

Eftir að þú hefur breytt stillingarskránni og lokið við LVM í RBD umbreytingu geturðu notað breyttu stillingarskrána og ræst sýndarvélina:

virsh define $vm_name.xml
virsh start $vm_name

Það er kominn tími til að athuga hvort sýndarvélin hafi byrjað rétt: þú getur komist að því, til dæmis með því að tengjast henni í gegnum SSH eða í gegnum virsh.

Ef sýndarvélin virkar rétt og þú hefur ekki fundið nein önnur vandamál, þá geturðu eytt LVM myndinni sem er ekki lengur notuð:

lvremove main/$vm_image_name

Ályktun

Við fundum öll tilvik sem lýst er í reynd - við vonum að leiðbeiningarnar hjálpi öðrum stjórnendum að leysa svipuð vandamál. Ef þú hefur athugasemdir eða aðrar svipaðar sögur frá reynslu þinni af því að nota Ceph, munum við vera ánægð að sjá þær í athugasemdunum!

PS

Lestu líka á blogginu okkar:

• «Hendur okkar eru ekki fyrir leiðindi: að endurheimta Rook þyrpinguna í K8s»;
• «To Rook or not to Rook - það er spurningin»;
• «Rook - „sjálfsafgreiðslu“ gagnavöruhús fyrir Kubernetes»;
• «Að búa til viðvarandi geymslu með úthlutun í Kubernetes byggt á Ceph'.

Heimild: www.habr.com