Kasutades Cephi võrgusalvestusena erineva koormusega projektides, võime kokku puutuda erinevate ülesannetega, mis esmapilgul ei tundu lihtsad ega triviaalsed. Näiteks:
- andmete migreerimine vanast Cephist uude, kasutades uues klastris osaliselt varasemaid servereid;
- lahendus kettaruumi eraldamise probleemile Cephis.
Selliste probleemidega tegelemisel seisame silmitsi vajadusega OSD õigesti eemaldada ilma andmeid kaotamata, mis on eriti oluline suurte andmemahtude käsitlemisel. Seda arutatakse artiklis.
Allpool kirjeldatud meetodid on asjakohased iga Cephi versiooni jaoks. Lisaks võetakse arvesse asjaolu, et Ceph suudab salvestada suure hulga andmeid: andmete kadumise ja muude probleemide vältimiseks jagatakse mõned toimingud mitmeks muuks.
Eessõna OSD kohta
Kuna kolmest käsitletud retseptist kaks on pühendatud OSD-le (), enne praktilisse ossa sukeldumist – lühidalt sellest, mis see Ceph on ja miks see nii oluline on.
Kõigepealt olgu öeldud, et kogu Cephi klaster koosneb paljudest OSD-dest. Mida rohkem neid on, seda suurem on tasuta andmemaht Cephis. Siit on seda lihtne mõista OSD põhifunktsioon: see salvestab Ceph-objektiandmed kõigi klastri sõlmede failisüsteemides ja pakub neile juurdepääsu võrgule (lugemiseks, kirjutamiseks ja muudeks päringuteks).
Samal tasemel määratakse replikatsiooniparameetrid, kopeerides objekte erinevate OSD-de vahel. Ja siin võite kokku puutuda mitmesuguste probleemidega, mille lahendusi arutatakse allpool.
Juhtum nr 1. Eemaldage OSD turvaliselt Cephi klastrist ilma andmeid kaotamata
Ekraanimenüü eemaldamise vajaduse võib põhjustada serveri eemaldamine klastrist – näiteks selle asendamiseks mõne teise serveriga –, mis juhtus ka meiega, mistõttu see artikkel kirjutati. Seega on manipuleerimise lõppeesmärk eraldada kõik antud serveris olevad OSD-d ja monid, et seda saaks peatada.
Mugavuse huvides ja vältimaks olukorda, kus käskude täitmisel eksime vajaliku OSD märkimisel, seame eraldi muutuja, mille väärtuseks saab kustutatava OSD numbri. Helistame talle ${ID} — siin ja allpool asendab selline muutuja ekraanimenüü numbrit, millega me töötame.
Vaatame seisukorda enne tööle asumist:
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
Ekraanimenüü eemaldamise alustamiseks peate toimima sujuvalt reweight selle peal nulli. Nii vähendame OSD-s olevate andmete hulka, tasakaalustades seda teiste OSD-dega. Selleks käivitage 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.
Vajalik sujuv tasakaalustamineet mitte andmeid kaotada. See kehtib eriti siis, kui ekraanimenüü sisaldab palju andmeid. Veendumaks, et pärast käskude täitmist reweight kõik läks hästi, saate lõpule viia ceph -s või eraldi terminaliakna käivitamisel ceph -w muutuste jälgimiseks reaalajas.
Kui OSD on "tühjendatud", saate selle eemaldamiseks jätkata tavapärast toimingut. Selleks viige soovitud OSD olekusse down:
ceph osd down osd.${ID}"Tõmbame" OSD klastrist välja:
ceph osd out osd.${ID}Peatame OSD-teenuse ja ühendame lahti selle partitsiooni FS-is:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Eemaldage ekraanimenüüst :
ceph osd crush remove osd.${ID}Kustutame OSD kasutaja:
ceph auth del osd.${ID}Ja lõpuks eemaldame OSD enda:
ceph osd rm osd.${ID}Märkus: Kui kasutate Ceph Luminous versiooni või uuemat versiooni, saab ülaltoodud OSD eemaldamise samme taandada kahe käsuga:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Kui pärast ülalkirjeldatud toimingute sooritamist käivitate käsu ceph osd tree, siis peaks olema selge, et serveris, kus töö tehti, pole enam OSD-sid, mille jaoks ülaltoodud toiminguid 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
Pidage meeles, et Cephi klastri olek läheb HEALTH_WARN, ning näeme ka OSD-de arvu ja vaba kettaruumi vähenemist.
Järgnevalt kirjeldatakse samme, mis on vajalikud, kui soovite serveri täielikult peatada ja vastavalt selle Cephist eemaldada. Sel juhul on oluline seda meeles pidada Enne serveri väljalülitamist peate eemaldama kõik OSD-d selles serveris.
Kui selles serveris pole enam OSD-sid, peate pärast nende eemaldamist serveri OSD-kaardilt välja jätma hv-2käivitades järgmise käsu:
ceph osd crush rm hv-2
Kustuta mon serverist hv-2käivitades alloleva käsu teises serveris (st antud juhul sisse hv-1):
ceph-deploy mon destroy hv-2Pärast seda saate serveri peatada ja alustada järgnevaid toiminguid (taasjuurutamine jne).
Juhtum nr 2. Kettaruumi jaotus juba loodud Ceph-klastris
Alustan teist lugu eessõnaga PG kohta (). PG peamine roll Cephis on peamiselt Cephi objektide koondamine ja nende edasine kopeerimine OSD-s. Valem, mille abil saate arvutada vajaliku PG koguse, on sees Ceph dokumentatsioon. Seda teemat käsitletakse seal ka konkreetsete näidetega.
Niisiis: Cephi kasutamisel on üks levinumaid probleeme OSD ja PG tasakaalustamata arv Cephi kogumite vahel.
Esiteks võib seetõttu tekkida olukord, kui väikeses kogumis on määratud liiga palju PG-sid, mis on sisuliselt ebaratsionaalne klastri kettaruumi kasutamine. Teiseks on praktikas tõsisem probleem: andmete ülevool ühes OSD-s. See tähendab, et klaster läheb esmalt olekusse HEALTH_WARN, ja siis HEALTH_ERR. Selle põhjuseks on asjaolu, et Ceph olemasoleva andmemahu arvutamisel (selle saate teada, kui MAX AVAIL käsu väljundis ceph df iga basseini kohta eraldi) põhineb OSD-s saadaolevate andmete hulgal. Kui vähemalt ühes OSD-s pole piisavalt ruumi, ei saa rohkem andmeid kirjutada enne, kui andmed on kõigi OSD-de vahel õigesti jaotatud.
Tasub selgitada, et need probleemid otsustatakse suures osas Cephi klastri seadistamise etapis. Üks tööriistu, mida saate kasutada, on . Tema abiga arvutatakse selgelt vajalik kogus PG-d. Kuid võite seda kasutada ka olukorras, kus Ceph-klaster juba valesti konfigureeritud. Siinkohal tasub selgitada, et parandustöö osana peate suure tõenäosusega vähendama PG-de arvu ja see funktsioon pole Cephi vanemates versioonides saadaval (see ilmus ainult versioonis ).
Kujutagem ette järgmist pilti: klastril on olek HEALTH_WARN kuna üks OSD-st sai tühjaks. Seda näitab tõrge HEALTH_WARN: 1 near full osd. Allpool on algoritm sellest olukorrast väljumiseks.
Kõigepealt peate jaotama saadaolevad andmed ülejäänud OSD-de vahel. Sarnase toimingu tegime juba esimesel juhul, kui sõlme "tühjendasime" - ainsa erinevusega, et nüüd peame veidi vähendama reweight. Näiteks kuni 0.95:
ceph osd reweight osd.${ID} 0.95See vabastab OSD-s kettaruumi ja parandab tseph-seisundi vea. Kuid nagu juba mainitud, ilmneb see probleem peamiselt Cephi vale konfigureerimise tõttu algstaadiumis: on väga oluline teha ümberseadistus, et seda tulevikus ei tekiks.
Meie konkreetsel juhul taandus see kõik järgmisele:
- väärtus liiga kõrge
replication_countühes basseinis, - liiga palju PG-d ühes basseinis ja liiga vähe teises.
Kasutame juba mainitud kalkulaatorit. See näitab selgelt, mida tuleb sisestada ja põhimõtteliselt pole midagi keerulist. Pärast vajalike parameetrite määramist saame järgmised soovitused:
Märkus: Kui seadistate Ceph-klastri nullist, on kalkulaatori veel üks kasulik funktsioon käskude genereerimine, mis loovad tabelis määratud parameetritega kogumid nullist.
Viimane veerg aitab teil navigeerida - Soovitatav PG arv. Meie puhul on kasulik ka teine, kus on märgitud replikatsiooniparameeter, kuna otsustasime replikatsioonikordajat muuta.
Niisiis, kõigepealt peate muutma replikatsiooni parameetreid - seda tasub kõigepealt teha, kuna kordaja vähendamisega vabastame kettaruumi. Käsu täitmisel märkate, et saadaolev kettaruum suureneb:
ceph osd pool $pool_name set $replication_size
Ja pärast selle valmimist muudame parameetrite väärtusi pg_num и pgp_num järgmiselt:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberOluline: peame muutma PG-de arvu järjestikku igas kogumis ja mitte muutma väärtusi teistes kogumites enne, kui hoiatused kaovad "Alanenud andmete liiasus" и "n-arv halvenenud lehekülgi".
Samuti saate käsuväljundite abil kontrollida, kas kõik läks hästi ceph health detail и ceph -s.
Juhtum nr 3. Virtuaalse masina migreerimine LVM-ist Ceph RBD-sse
Olukorras, kus projektis kasutatakse renditud paljasmetalliserveritele paigaldatud virtuaalmasinaid, kerkib sageli esile tõrketaluvusega salvestusruumi küsimus. Samuti on väga soovitav, et selles salvestusruumis oleks piisavalt ruumi... Teine levinud olukord: serveris on lokaalse salvestusega virtuaalmasin ja on vaja ketast laiendada, aga pole kuhugi minna, sest pole serverisse on jäänud vaba kettaruumi.
Probleemi saab lahendada erineval viisil – näiteks migreerudes teise serverisse (kui see on olemas) või lisades serverisse uusi kettaid. Kuid seda pole alati võimalik teha, nii et LVM-ilt Cephile üleminek võib olla selle probleemi suurepärane lahendus. Selle valiku valimisega lihtsustame ka edasist serveritevahelise migratsiooni protsessi, kuna pole vaja kohalikku salvestusruumi ühest hüperviisorist teise teisaldada. Ainus konks on see, et peate töö tegemise ajaks VM-i peatama.
Järgmine retsept on võetud , mille juhiseid on töös testitud. Muideks, seal on kirjeldatud ka probleemivaba rände meetoditaga meie puhul polnud seda lihtsalt vaja, seega me seda ei kontrollinud. Kui see on teie projekti jaoks kriitilise tähtsusega, on meil hea meel kuulda tulemustest kommentaarides.
Liigume edasi praktilise osa juurde. Näites kasutame virsh ja vastavalt libvirt. Esiteks veenduge, et Ceph-i kogum, kuhu andmed migreeritakse, on ühendatud libvirtiga:
virsh pool-dumpxml $ceph_poolPuuli kirjeldus peab sisaldama Cephi ühenduse andmeid koos autoriseerimisandmetega.
Järgmine samm on see, et LVM-pilt teisendatakse Ceph RBD-ks. Teostusaeg sõltub eelkõige pildi suurusest:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_namePärast teisendamist jääb alles LVM-pilt, mis on kasulik, kui VM-i RBD-le migreerimine ebaõnnestub ja peate muudatused tagasi võtma. Muudatuste kiireks tagasipööramiseks tehkem ka virtuaalmasina konfiguratsioonifaili varukoopia:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... ja redigeeri originaali (vm_name.xml). Leiame ploki ketta kirjeldusega (algab reaga <disk type='file' device='disk'> ja lõpeb </disk>) ja vähendage see järgmisele kujule:
<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>Vaatame mõningaid üksikasju:
- Protokolli juurde
sourcenäidatakse Cephi RBD-s asuva salvestusruumi aadress (see on aadress, mis näitab Cephi kogumi nime ja RBD kujutist, mis määrati esimeses etapis). - Plokis
secrettüüp on näidatudceph, samuti saladuse UUID, millega sellega ühenduse luua. Selle uuid leiate käsu abilvirsh secret-list. - Plokis
hostCeph monitoride aadressid on näidatud.
Pärast konfiguratsioonifaili redigeerimist ja LVM-i RBD-ks teisendamise lõpetamist saate rakendada muudetud konfiguratsioonifaili ja käivitada virtuaalmasina:
virsh define $vm_name.xml
virsh start $vm_name
On aeg kontrollida, kas virtuaalmasin käivitus õigesti: seda saate teada näiteks SSH kaudu või virsh.
Kui virtuaalmasin töötab korralikult ja te ei leidnud muid probleeme, saate kustutada LVM-pildi, mida enam ei kasutata:
lvremove main/$vm_image_nameJäreldus
Praktikas kohtasime kõiki kirjeldatud juhtumeid – loodame, et juhised aitavad teistel administraatoritel sarnaseid probleeme lahendada. Kui teil on Cephi kasutamise kogemustest kommentaare või muid sarnaseid lugusid, näeme neid hea meelega kommentaarides!
PS
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com