🥇Nipid ja trikid Ceph'iga töötamiseks koormatud projektides

Kasutades Ceph'i kui võrgu salvestusruumi erinevate koormustega projektides, võime kokku puutuda erinevate probleemidega, mis esmapilgul ei tundu lihtsad või triviaalsetena. Näiteks:

andmete migratsioon vana Ceph'ist uude, osaliselt kasutades eelmisi servereid uues klastris;
probleemi lahendamine Ceph'i kettaruumi jaotuse osas.

Selliste ülesannete lahendamisel seisame silmitsi vajadusega õigesti eemaldada OSD andmete kaotamata, mis on eriti oluline suurte andmemahtude korral. Just sellest juttu tuleb artiklis.

Allpool kirjeldatud meetodid kehtivad kõikide Ceph'i versioonide jaoks. Lisaks arvestatakse selle faktiga, et Ceph's võib talletuda suur andmemahutus: andmete kaotuse ja muude probleemide vältimiseks jagatakse mõned toimingud mitmeks.

Eessõna OSD-st

Kuna kaks kolmest käsitletavast retseptist on pühendatud OSD-le (Objekti salvestamise deemon), enne praktilisse ossa sukeldumist — lühidalt, mis see tegelikult on Ceph'is ja miks see on nii oluline.

Esiteks tuleb öelda, et kogu Ceph'i klaster koosneb paljusid OSD-dest. Mida rohkem neid on, seda suurem on vaba andmemaht Ceph'is. Sealt on lihtne mõista OSD peamist funktsiooni: see salvestab Ceph'i objektide andmed klastris olevate node'ide failisüsteemidesse ja pakub neile võrgu ligipääsu (lugemiseks, kirjutamiseks ja muudele päringutele).

Samuti seadistatakse replikatsiooni parameetrid, kopeerides objekte erinevate OSD-de vahel. Ja siin võime kokku puutuda erinevate probleemidega, mille lahendamist käsitletakse hiljem.

Juhtum nr 1. OSD turvaline eemaldamine Ceph'i klastrist andmete kaotamata

OSD eemaldamise vajadus võib tuleneda serveri eemaldamisest klastrist - näiteks asendamiseks teise serveriga - mis juhtus ka meie puhul, andes põhjuse artikli kirjutamiseks. Seega on operatsioonide lõppeesmärk eemaldada kõik OSD-d ja mon’id antud serveris, et see saaks välja lülitada.

Mugavuse ja olukorra vältimiseks, kus oleme käskude täitmise protsessis eksinud vajaliku OSD määramisel, seame eraldi muutuja, mille väärtuseks saab eemaldatava OSD number. Nimetame selle ${ID} — siin ja edaspidi asendab see muutuja OSD numbri, millega me töötame.

Vaadake seisundit enne tööde alustamist:

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 eemaldamiseks on vajalik sujuvalt reweight seda nulli. Nii vähendame OSD-s olevate andmete hulka, suunates need teistesse OSD-desse. Selle jaoks tuleb käivitada järgmised käsud:

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

… ja nii edasi kuni nullini.

Sujuv tasakaalustus on vajalik, et andmeid ei kaotataks. See on eriti oluline, kui OSD-s on palju andmeid. Et veenduda, et pärast käskude täitmist reweight on kõik läinud edukalt, saab käivitada ceph -s või avada eraldi terminaliaknas ceph -w kui soovite jälgida muudatusi reaalajas.

Kui OSD on "tühjendatud", saab alustada selle eemaldamise standardset protseduuri. Selleks viime soovitud OSD seisundisse down:

ceph osd down osd.${ID}

"Tõmbame" OSD klastrist välja:

ceph osd out osd.${ID}

Peatame OSD teenuse ja eemaldame selle jagamise failisüsteemist:

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

Eemaldame OSD CRUSH kaardist:

ceph osd crush remove osd.${ID}

Eemaldame OSD kasutaja:

ceph auth del osd.${ID}

Ja lõpuks eemaldame ise OSD:

ceph osd rm osd.${ID}

Märkus: kui kasutate Ceph Luminous või uuemat versiooni, siis võivad ülaltoodud OSD eemaldamise toimetamised kokku leppida kahes käsus:

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

Kui pärast ülaltoodud käskude täitmist käivitada käsk ceph osd tree, siis peaks olema näha, et serveris, kus tööd tehti, pole enam OSD-sid, mille jaoks operatsioone tehti:

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

Märgin ka, et Ceph klastri olek muudab HEALTH_WARN, samuti märkame OSD-de arvu vähendamist ja saadaval oleva kettaruumi vähenemist.

Edasi kirjeldatakse toiminguid, mis on vajalikud, kui soovite serveri täielikult peatada ja seega ka Ceph-st eemaldada. Sellisel juhul on oluline meeles pidada, et enne serveri väljalülitamist tuleb eemaldada kõik OSD-d selles serveris.

Kui selles serveris pole enam OSD-sid, tuleb nende eemaldamise järel OSD kaardilt välja jätta server hv-2, käivitades järgmise käsu:

ceph osd crush rm hv-2

Kustutame mon serverist hv-2, käivitades alloleva käsu teises serveris (st sel juhul — hv-1):

ceph-deploy mon destroy hv-2

Pärast seda võib serveri kinni panna ja liikuda järgmiste toimingute juurde (näiteks selle uuesti seadistamine jne.).

Juhtum nr 2. Diskiruumi jaotus juba loodud Ceph-klastris

Teise loo alustamiseks teen sissejuhatuse PG (Placement Groups). PG peamine roll Cephis on eelkõige Ceph-objektide agregatsioon ja edasine replikatsioon OSDs. PG vajaliku arvu arvutamise valem on toodud vastavas jaos Cephi dokumentatsioonis. Seal käsitletakse seda küsimust ka konkreetsete näidete kaudu.

Nii et üks levinumaid probleme Cephi kasutamise ajal on OSD ja PG vahelise tasakaalu puudumine klastris.

Esiteks võib see tekitada olukorra, kus väikese mahuga basseinis on liiga palju PG-sid, mis on sisuliselt diskiruumi ebaefektiivne kasutamine klastris. Teiseks, praktikas tekib tõsisem probleem: andmete üleküllus ühes OSD-s. See toob kaasa klastris kõigepealt oleku HEALTH_WARN, ja siis HEALTH_ERR. Kõik selle tõttu, et Ceph arvutab saadaval oleva andmemahu (mida saab kontrollida MAX AVAIL käsku andmete väljastamise ajal ceph df iga basseini kohta eraldi) OSD-s saadaval oleva andmemahu põhjal. Kui vähemalt ühes OSD-s on ruumi liiga vähe, siis rohkem andmeid salvestada ei õnnestu, kuni andmed on kõikides OSD-des korralikult jaotatud.

Oluline on märkida, et need probleemid lahendatakse suuresti Ceph-klastri seadistamise etapis.Üks tööriist, mida kasutada, on Ceph PGCalc. Selle abil arvutatakse visuaalselt vajalik PG-de arv. Sellegipoolest võib selle poole pöörduda ka olukordades, kui Ceph-klaster juba on vale seadistusega. Siinkohal tuleb märkida, et tõrgete parandamise käigus peate tõenäoliselt PG-de arvu vähendama, kuid see võimalus ei ole vanades Cephi versioonides saadaval (see ilmus alles versiooniga Nautilus).

Nii et kujutame ette järgmist stsenaariumi: klastril on olek HEALTH_WARN selle tõttu, et ühes OSD-s on ruum otsa saamas. Seda tõendab tõrge HEALTH_WARN: 1 near full osd. Allpool on toodud algoritm, et sellisest olukorrast välja pääseda.

Esmalt on vaja olemasolevad andmed jagada teiste OSDe vahel. Sarnast toimingut oleme juba teinud esimeses juhtumis, kui me "kuivasime" sõlme — ainsaks erinevuseks on see, et nüüd tuleb väärtust veidi vähendada. reweight. Näiteks 0.95:

ceph osd reweight osd.${ID} 0.95

Nii vabanevad OSDes kettaruumi ja kõrvaldatakse viga ceph health'is. Siiski, nagu juba mainitud, tekib see probleem enamasti vale Cephi seadistamise tõttu algstaadiumis: on äärmiselt oluline teha rekondigureerimine, et see ei korduks tulevikus.

Meie konkreetses juhul kõik seisnes:

liialt kõrge väärtus replication_count ühes basseinist,
liialt kõrge PG arv ühes basseinist ja liiga madal — teises.

Kasutame juba mainitud kalkulaatorit. Selles on selgelt näha, mida sisestada, ja põhimõtteliselt pole seal midagi keerulist. Sisestades vajalikud parameetrid, saame järgmised soovitused:

Märkus: kui seadistate Cephi klastrit nullist, osutub kalkulaatori abiks veel üks kasulik funktsioon, nimelt käskude genereerimine, mis loob basseinid nullist tabelis toodud parameetritega.

Kitsendatud aitab viimane veerg — Suggested PG Count. Meie puhul on kasulik ka teine, kus on märgitud replikatsiooni parameeter, kuna otsustasime muuta ka replikatsiooni kordajat.

Nii et esmalt tuleb muuta replikatsiooni parameetreid — seda tuleks teha esimesena, kuna kordaja vähendamine vabastab kettaruumi. Käskude täitmise protsessis võib täheldada, et vaba kettamaht kasvab:

ceph osd pool $pool_name set $replication_size

Ja pärast selle lõpetamist — muutke parameetreid pg_num ja pgp_num järgmiselt:

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

Oluline: peame järjestikku igas basseinis muutma PG arvu ja mitte muutma väärtusi teistes basseinides, kuni hoiatused kaovad "Degraded data redundancy" ja "n-number of pgs degraded".

Kontrollida, et kõik läks sujuvalt, saab ka käskude väljundite kaudu ceph health detail ja ceph -s.

Juhtum nr 3. Virtuaalse masina migratsioon LVM-ist Ceph RBD-sse

Kui projektis kasutatakse virtuaalseid masinaid, mis on paigaldatud renditud bare-metal serveritele, tekib sageli küsimus, kuidas tagada uuendatav salvestuslahendus. Samuti on oluline, et salvestuspinda oleks piisavalt... Teine levinud olukord: virtuaalne masin, millel on serveris kohalik salvestus, vajab ketta laiendamist, aga vaba kettaruumi pole jäänud.

Selle probleemi saab lahendada erinevate meetoditega — näiteks migratsiooniga teisele serverile (kui selline on olemas) või uute ketaste lisamisega serverisse. Kuid see ei õnnestu alati, seega võib migratsioon LVM-ist Ceph-i olla suurepärane lahendus. Sellise variandi valimisel lihtsustame ka edasist migratsiooniprotsessi serverite vahel, sest ei ole vaja kohalikku salvestust ühest hüperviisorist teise viia. Ainuke takistus on see, et virtuaalne masin tuleb tööde ajaks peatada.

Tuleks tuua järgmine retsept selle blogi artiklist, mille juhised on praktikas proovitud. Muide, seal on kirjeldatud ka süsteemi migratsiooni viisi,aga meie juhul ei olnud see vajalik, seega me ei kontrollinud seda. Kui see on teie projekti jaoks kriitiline — oleme tänulikud, kui jagate tulemusi kommentaarides.

Läheme praktilise osa juurde. Näites kasutame virsh’i ja vastavalt libvirt’i. Esiteks veenduge, et Ceph’i bassein, kuhu andmed migratsiooniks suunatakse, on libvirt’iga ühendatud:

virsh pool-dumpxml $ceph_pool

Basseini kirjelduses peaksid olema Ceph’i ühenduse andmed koos autoriseerimise andmetega.

Järgmine samm on see, et LVM-pilt konverteeritakse Ceph RBD-ks. Täitmise aeg sõltub peamiselt pildi suurusest:

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

Pärast konversiooni jääb LVM-pilt, mis on kasulik juhul, kui migratsioon virtuaalsest masinast RBD-sse ei õnnestu ja muudatused tuleb tagasi rullida. Samuti — muutuste kiireks tagasi rullimiseks — teeme varukoopia virtuaalse masina konfigureerimisfailist:

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

… ja redigeerime originaali (vm_name.xml). Leidke plokk ketta kirjeldusega (algab realt <disk type='file' device='disk'> ja lõpeb </disk>) ja toome selle järgmisesse vormi:

Vaatame mõningaid detaile:

Protokollis source tuletatakse vahehoidla aadress Ceph RBD (see on aadress, mis näitab Ceph basseini ja RBD pilti, mis määrati esimeses etapis).
Plokis secret näidatakse tüüpi ceph, samuti salajase ID, et kasutada sellele ühendust. Selle uuid'i saab teada käsuga virsh secret-list.
Plokis host näidatakse Ceph jälgijate aadresse.

Pärast konfiguratsioonifaili redigeerimist ja LVM-i ümberkujundamist RBD-sse saab rakendada muudetud konfiguratsioonifaili ja käivitada virtuaalse masina:

virsh define $vm_name.xml
virsh start $vm_name

On aeg kontrollida, kas virtuaalne masin käivitus õigesti: seda saab teha näiteks, ühendudes temaga SSH kaudu või läbi virsh.

Kui virtuaalne masin töötab õigesti ja te ei leidnud muid probleeme, saate eemaldada LVM-pildi, mis ei ole enam kasutuses:

lvremove main/$vm_image_name

Kokkuvõte

Kõikide kirjeldatud juhtumite korral oleme praktikas kokku puutunud — loodame, et juhised aitavad ka teisi haldureid sarnaste probleemide lahendamisel. Kui teil on märkusi või muid sarnaseid kogemusi Ceph'i kasutamisest — oleksime rõõmsad neid kommenteerida!