🥇Nipid ja näpunäited Ceph'i kasutamisel koormatud projektides

Kasutades Cephi kui võrgu salvestust erineva koormusega projektides, võime silmitsi seista mitmesuguste ülesannetega, mis esmapilgul ei tundu lihtsad või triviaalsetena. Näiteks:

andmete migreerimine vanast Cephist uude osaliselt varasemaid servereid uues klastris kasutades;
ketta ruumi jaotuse probleemide lahendamine Cephis.

Selliste ülesannete lahendamisel seisame silmitsi vajadusega õigesti OSDd eemaldada andmete kaotamata, mis on eriti oluline suurte andmemahtude puhul. Just sellest räägitakse artiklis.

Allpool kirjeldatud meetodid kehtivad igasuguste Cephi versioonide jaoks. Samuti arvestatakse, et Cephis võib olla suures koguses andmeid: andmekao ja teiste probleemide vältimiseks jagatakse mõned toimingud mitmeks.

Sissejuhatus OSD-le

Kuna kaks kolmest käsitletavast retseptist on pühendatud OSD-le (Object Storage Daemon), enne praktilisse ossa sukeldumist — lühidalt, mis see Cephis üldse on ja miks see nii oluline on.

Esiteks tuleb öelda, et kogu Ceph-klaster koosneb paljusid OSD-dest. Mida rohkem OSD-sid, seda suurem on Ceph-i vaba andmemaht. Siit on lihtne mõista peamist OSD funktsiooni: see salvestab Ceph objektide andmed klasteri kõigi sõlmede failisüsteemides ja tagab neile võrguühenduse (lugemiseks, kirjutamiseks ja muude taotlusteks).

Samas tasemes seadistatakse replikatsiooni parameetrid, kopeerides objekte erinevate OSD-de vahel. Siin võivad tekkida erinevad probleemid, mille lahendamisest räägitakse järgmiselt.

Juhtum nr 1. OSD ohutu eemaldamine Ceph-klastrist andmete kaotuseta

OSD eemaldamise vajadus võib tuleneda serveri väljavõtmisest klastrist — näiteks teise serveri asendamiseks, — mis juhtus ka meil ja mis oli põhjuseks selle artikli kirjutamiseks. Nii et toimingute lõppeesmärk on eemaldada kõik OSD-d ja mon’id sellest serverist, et see saaks peatada.

Mugavuse ja olukorra vältimiseks, kus me käske täites eksime vajaliku OSD määramisel, määrame eraldi muutuja, mille väärtuseks on eemaldatava OSD number. Nimeks paneme selle ${ID} — siin ja edaspidi selline muutuja asendab 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 eemaldamise algatamiseks on vaja sujuvalt teostada reweight sellel nulliks. Nii vähendame OSD-s toimuvaid andmeid, tasakaalustades need teistesse OSD-desse. Selleks täidetakse järgmised käsklused:

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 tasakaalustamine on vajalik, et mitte kaotada andmeid. See on eriti oluline, kui OSD-s on suur andmemaht. Et veenduda, et pärast käskluste täitmist reweight kõik on läinud edukalt, võib täita ceph -s või avada eraldi terminaliaknas ceph -w et jälgida muudatusi reaalajas.

Kui OSD on "tühjendatud", võib alustada selle eemaldamise standardprotseduuri. Selleks viime vajalik OSD seisundisse down:

ceph osd down osd.${ID}

"Tõmbame" OSD klastrist välja:

ceph osd out osd.${ID}

Peatame OSD teenuse ja demonteerime selle faili süsteemis:

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

Kustutame OSD-st CRUSH kaardist:

ceph osd crush remove osd.${ID}

Kustutame OSD kasutaja:

ceph auth del osd.${ID}

Ja lõpuks kustutame OSD enda:

ceph osd rm osd.${ID}

Märkus: kui kasutate Ceph Luminous või uuemat versiooni, saab ülaltoodud OSD eemaldamisprotseduurid minimaliseerida kahele käsule:

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

Kui pärast ülaltoodud toimingute tegemist käivitate käsu ceph osd tree, peaks olema näha, et serveris, kus tööd tehti, ei ole enam OSD-d, millele ülaltoodud toimingud said teostatud:

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

Juhime tähelepanu, et Ceph klastrite olek muutub HEALTH_WARN, lisaks näeme OSD-de arvu ja vaba kettaruumi vähenemist.

Edasi kirjeldatakse toiminguid, mis on vajalikud, kui soovite serveri täielikult peatada ning vastavalt eemaldada selle Ceph-ist. Sellisel juhul on oluline meeles pidada, et enne serveri välja lülitamist tuleb igal OSD-l sellel serveril eemaldada.

Kui sellel serveril ei ole enam OSD-sid, siis nende eemaldamise järel tuleb need OSD kaardilt välja jätta. hv-2, täites järgmise käsu:

ceph osd crush rm hv-2

Kustutame mon serverilt hv-2, käivitades alltoodud käsu teises serveris (st antud juhul — hv-1):

ceph-deploy mon destroy hv-2

Pärast seda võib serveri välja lülitada ja jätkata järgmiste toimingutega (uuesti seadistamine jne).

Juhtum nr 2. Diskiruumi jaotamine juba loodud Ceph-klusteris

Teise loo alustamiseks teen sissejuhatuse PG (Placement Groups). PG peamine roll Cephis on peamiselt Ceph-objektide kogumine ja edasine replikatsioon OSD-sse. PG vajaliku arvu arvutamiseks vajalik valem on toodud vastavas jaotises Ceph'i dokumentatsioonis. Seal on sama teema käsitletud ka konkreetsete näidete abil.

Nii et: üks levinumaid probleeme Cephi kasutamise ajal on OSD-de ja PG-de tasakaalustamatus Cephis.

Esiteks, võib tekkida olukord, kus väikeses mahus basseinis on määratud liiga palju PG-d, mis on oma olemuselt ebaefektiivne kettaruumi kasutamine klastris. Teiseks, praktikas tekib tõsisem probleem: ühte OSD-d andmete ülevool. See toob kaasa klastrisse esialgu seisundi HEALTH_WARN, seejärel ka HEALTH_ERR. Kõik see juhtub seetõttu, et Ceph tugineb arvutuste tegemisel OSD-s oleva andmehulga suurusele (mida saab teada MAX AVAIL käskluse tulemuses ceph df iga basseini jaoks eraldi), kui arvutatakse andmete saadavust. Kui vähemalt ühes OSD-s on ruumi ebapiisavalt, ei ole võimalik rohkem andmeid salvestada, kuni andmed ei ole korralikult jaotatud kõigi OSD-de vahel.

Oluline on märkida, et neid probleeme lahendatakse suurel määral Ceph-klastri konfiguratsiooni etapis. Üks tööriist, millele toetuda, on Ceph PGCalc. Selle abil saab selgelt arvutada vajalike PG-de arvu. Siiski võib sellele tugineda ka olukordades, kus Ceph klaster juba on vale vale. Siin tasub märkida, et vigade parandamise käigus peate tõenäoliselt vähendama PG arvu, kuid see võimalus ei ole vanades Ceph versioonides saadaval (see ilmus alles versiooniga Nautilus).

Kujutame nüüd järgmisi stsenaariume: klastri staatus on HEALTH_WARN selle tõttu, et ühe OSD kohta lõpeb ruum. Sellest annab märku viga HEALTH_WARN: 1 near full osd. Allpool on esitatud algoritm, kuidas sellisest olukorrast välja pääseda.

Esiteks tuleb olemasolevaid andmeid teiste OSD-de vahel jaotada. Sarnast toimingut oleme juba teinud esimeses juhtumis, kui „kuivasime“ sõlme — ainus erinevus on see, et nüüd tuleb veidi vähendada reweight. Näiteks kuni 0.95:

ceph osd reweight osd.${ID} 0.95

Nii vabastatakse OSD-s diskiruumi ja viga ceph healthis parandatakse. Kuid nagu juba mainitud, tekib see probleem peamiselt Cephi vale seadistamise tõttu algstaadiumis: väga oluline on rekonstrueerimine, et see tulevikus ei ilmneks.

Meie konkreetsel juhul seisis see kõik:

liialt suur väärtus replication_count ühes basseinides,
ühe laval on liiga suur PG arv ja teisel liiga väike.

Kasutame juba mainitud kalkulaatorit. Selles on selgelt näidatud, mida sisestada, ja üldiselt pole seal midagi keerulist. Sisestades vajalikud parameetrid, saame järgmised soovitused:

Märkus: kui seadistate Ceph-klusterit nullist, on kalkulaatori veel üheks kasulikuks funktsiooniks käskude genereerimine, mis loovad lähtestatud basseinid tabelis toodud parameetritega.

Oleneb viimasest veerust — Suggested PG Count. Meie puhul on kasulik ka teine, kus on näidatud replikatsiooni parameeter, kuna otsustasime muuta replikatsiooni kordajat.

Nii et kõigepealt tuleb muuta replikatsiooni parameetreid — seda tuleks teha kõigepealt, kuna kordaja vähendamine vabastab salvestusruumi. Käsku täitmisel võib märgata, et saadaval oleva salvestusruumi väärtus suureneb:

ceph osd pool $pool_name set $replication_size

Ja pärast selle lõpetamist muudame parameetrite väärtused 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ärk-järgult igas rippes muutma PG arvut ja mitte muutma väärtusi teistes rippes, kuni hoiatused kaovad „Degradeeritud andmete ülekandmine“ ja „n-arvu pgs on degradeeritud“.

Kontrollige, et kõik on läinud edukalt, samuti saab kontrollida käskude väljundeid ceph health detail ja ceph -s.

Juhtum nr 3. Virtuaalmasina migratsioon LVM-st Ceph RBD-le

Kui projektis kasutatakse virtuaalmasinaid, mis on paigaldatud renditud bare-metal-serveritele, siis tekib sageli küsimus tagavarakoopia kvaliteetse salvestamise kohta. Ja oleks väga soovitav, et selle salvestuse jaoks oleks piisavalt ruumi… Teine levinud olukord: on virtuaalmasin, millel on lokaalne salvestusserveris ja on vaja ketast laiendada, kuid ruumi ei ole, kuna serveris ei ole vaba ketaruum.

Probleemi saab lahendada mitmesuguste vahenditega — näiteks migreerimisega teisele serverile (kui see on saadaval) või uute kettaste lisamisega serverisse. Kuid mitte alati ei ole seda võimalik teha, seetõttu võib migreerimine LVM-ilt Ceph-ile olla suurepärane lahendus sellele probleemile. Sellise variandi valides lihtsustame ka edasist migreerimisprotsessi serverite vahel, kuna ei pea kohalikku salvestust ühelt hüpervisorilt teisele tarnima. Ainuke konks on see, et peate VM-i töö ajaks peatama.

Nagu allpool toodud retseptis on see blogi artikli põhjal, mille juhiseid on praktikas katsetatud. Üldsega, seal on samuti kirjeldatud lihtsustatud migreerimise viisi, kuid meie juhtumil ei olnud see lihtsalt vajalik, seega me ei kontrollinud seda. Kui see on teie projekti jaoks kriitiline — oleksime rõõmsad, kui kuuleksime teie tulemustest kommentaarides.

Alustame praktilise osaga. Näites kasutame virsh'i ja vastavalt ka libvirt'i. Esiteks veenduge, et Ceph'i bassein, kuhu andmed migreeritakse, on libvirt'iga ühendatud:

virsh pool-dumpxml $ceph_pool

Puhangus kirjelduses peavad olema ühendusandmed Ceph'iga koos autentimisteabega.

Järgmine etapp on see, et LVM-i pildist 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 konverteerimist jääb LVM-i pilt, mis on kasulik, kui VM-i rändamine RBD-sse ei õnnestu ja tuleb muudatused tagasi võtta. Samuti, et võimalikult kiiresti muudatusi tagasi võtta, teeme varukoopia virtuaalmasina konfiguratsioonifailist:

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

… ja muudame originaali (vm_name.xml). Otsime välja plaadi kirjelduse ploki (mis algab reaalta: <disk type='file' device='disk'> ja lõpetab </disk>) ja viime selle järgmisesse vormi:

Vaatame mõningaid detaile:

Protokoll source määratakse Ceph RBD salvestuse aadress (see on aadress, kus on näidatud Ceph-aluse ja RBD-pildi nimi, mis määrati esimesel etapil).
Blokis salajane määratakse tüüp ceph, samuti salajase ühiku UUID selle ühendamiseks. Selle uuid saab teada järgmise käsklusega virsh secret-list.
Blokis host määratakse Ceph-i monitoride aadressid.

Pärast konfiguratsioonifaili redigeerimist ja LVM-i konverteerimist RBD-ks saab rakendada muudetud konfiguratsioonifaili ja käivitada virtuaalmasina:

virsh define $vm_name.xml
virsh start $vm_name

On õige aeg kontrollida, kas virtuaalmasin käivitus korrektselt: seda saab teada näiteks SSH kaudu ühendust luues või virsh.

Kui virtuaalmasin töötab korrektselt ja te ei leia muid probleeme, siis saab eemaldada LVM-pildi, mida enam ei kasutata:

lvremove main/$vm_image_name

Kokkuvõte

Kõigi eelnevalt kirjeldatud juhtumitega oleme praktikas kokku puutunud — loodame, et juhised aitavad ka teisi administraatoreid sarnaste probleemide lahendamisel. Kui teil on märkusi või muid sarnaseid lugusid Ceph-i kasutamisest — oleksime rõõmsad neid kommentaarides näha!