Duke përdorim Ceph si ruajtje në rrjet për projekte me ngarkesa të ndryshme, mund të përballemi me detyra që në pamje të parë nuk duken të thjeshta ose banale. Për shembull:
- migrimi i të dhënave nga Ceph i vjetër në të riun me përdorimin pjesor të serverëve të mëparshëm në klasterin e ri;
- zgjidhja e problemit të shpërndarjes së hapësirës diskore në Ceph.
Duke iu qasur këtyre detyrave, hasim nevojën për të nxjerrë OSD-në në mënyrë korrekte pa humbje të dhënash, e cila është veçanërisht e rëndësishme kur kemi volum të madh të të dhënave. Kjo do të trajtohet në artikull.
Metodat e përshkruara më poshtë janë të aplikueshme për të gjithë versionet e Ceph. Për më tepër, do të merret parasysh fakti që Ceph mund të mbajë një sasi të madhe të dhënash: për të parandaluar humbjet e të dhënave dhe probleme të tjera, disa veprime do të "ndarë" në disa të tjera.
Parathënie për OSD
PĂ«r shkak se dy nga tre recetat qĂ« po shqyrtojmĂ« i kushtohen OSD (), para se tĂ« futemi nĂ« pjesĂ«n praktike â shkurtimisht pĂ«r atĂ« se çfarĂ« Ă«shtĂ« nĂ« fakt nĂ« Ceph dhe pse Ă«shtĂ« kaq i rĂ«ndĂ«sishĂ«m.
Së pari, duhet të themi se e gjithë klasteri Ceph përbëhet nga shumë OSD. Sa më shumë të jenë, aq më shumë hapësirë të lirë të dhënash ka në Ceph. Këtu lehtë mund të kuptohet funksioni kryesor i OSD: ai ruan të dhënat e objekteve Ceph në sistemet e skedarëve të të gjitha nyjeve të klasterit dhe ofron akses në rrjet për to (për lexim, shkruan dhe kërkesa të tjera).
Në këtë nivel vendosen parametrat e replikimit përmes kopjimit të objekteve midis OSD-ve të ndryshme. Këtu mund të hasim disa probleme, zgjidhja e të cilave do të diskutohet më poshtë.
Rasti â1. Nxjerrja e sigurt e OSD-sĂ« nga klasteri Ceph pa humbje tĂ« dhĂ«nash
Nevoja pĂ«r tĂ« nxjerrĂ« OSD-nĂ« mund tĂ« shkaktohet nga nxjerrja e serverit nga klasteri â pĂ«r shembull, pĂ«r ta zĂ«vendĂ«suar me njĂ« server tjetĂ«r, â dhe kjo ndodhi me ne, qĂ« shĂ«rbeu si shkak pĂ«r tĂ« shkruar artikullin. KĂ«shtu, qĂ«llimi pĂ«rfundimtar i manipulimeve Ă«shtĂ« tĂ« nxjerrim tĂ« gjitha OSD-tĂ« dhe mon'Ă«t nĂ« kĂ«tĂ« server, nĂ« mĂ«nyrĂ« qĂ« tĂ« mund tĂ« ndalohet.
PĂ«r lehtĂ«si dhe pĂ«r tĂ« shmangur situatĂ«n, ku gjatĂ« ekzekutimit tĂ« komandave mund tĂ« gabojmĂ« me caktimin e OSD-sĂ« sĂ« duhur, do tĂ« caktuam njĂ« variablĂ« tĂ« veçantĂ«, vlera e tĂ« cilĂ«s do tĂ« jetĂ« numri i OSD-sĂ« qĂ« po heqim. Ta quajmĂ« ${ID} â kĂ«tu dhe mĂ« poshtĂ«, kjo variablĂ« zĂ«vendĂ«son numrin e OSD-sĂ« me tĂ« cilin po punojmĂ«.
Le të shohim gjendjen para fillimit të punëve:
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 Për të iniciuar fshirjen e OSD-së, do të nevojitet të kryhet ngadalë ri në të deri në zero. Kështu ne zvogëlojmë sasinë e të dhënave në OSD duke balancuar në OSD të tjera. Për këtë, kryhen komandat e mëposhtme:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78⊠dhe kështu me radhë deri në zero.
Balancimi gradual është i nevojshëm, për të mos humbur të dhëna. Kjo është veçanërisht e rëndësishme nëse ka një volum të madh të dhënash në OSD. Për të siguruar që pas ekzekutimit të komandave ri gjithçka ka shkuar mirë, mund të ekzekutoni ceph -s ose në një dritare të veçantë terminali të nisni ceph -w për të vëzhguar ndryshimet në kohë reale.
Kur OSD-ja "të jetë zbrazur", mund të vazhdoni me operacionin standard të fshirjes së saj. Për këtë, do ta çojmë OSD-në e nevojshme në gjendjen down:
ceph osd down osd.${ID}"Të heqim" OSD-në nga klasteri:
ceph osd out osd.${ID}Do ta ndalojmë shërbimin OSD dhe do ta çmontojmë pjesën e saj në FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Do ta heqim OSD-në nga :
ceph osd crush remove osd.${ID}Do të heqim përdoruesin OSD:
ceph auth del osd.${ID}Dhe, përfundimisht, do ta heqim OSD-në vetë:
ceph osd rm osd.${ID}Shënim: nëse po përdorni versionin Ceph Luminous ose më të lartë, atëherë veprimet e përshkruara më sipër për fshirjen e OSD-së mund të reduktohen në dy komanda:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Nëse pas përfundimit të veprimeve të përshkruara më sipër ekzekutoni komandën ceph osd tree, duhet të shihet se në serverin ku janë kryer punët, nuk ka më OSD për të cilat janë kryer operacionet e mësipërme:
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 Përveç kësaj, do të vërejmë se gjendja e klasterit Ceph do të kalojë në HEALTH_WARN, si edhe do të shohim një ulje të numrit të OSD-ve dhe volumit të hapur të hapësirës disk.
Më poshtë do të përshkruhen veprimet që do të nevojiten nëse dëshironi të ndaloni plotësisht serverin dhe, për rrjedhojë, ta hiqni atë nga Ceph. Në këtë rast, është e rëndësishme të mbani mend se para se të çaktivizoni serverin duhet të hiqni të gjitha OSD-të në këtë server.
Nëse nuk ka mbetur asnjë OSD në këtë server, pas heqjes së tyre, duhet të përjashtoni nga harta OSD serverin hv-2, duke ekzekutuar komandën e mëposhtme:
ceph osd crush rm hv-2 Fshijmë mon nga serveri hv-2, duke komandën më poshtë në një server tjetër (dmth. në këtë rast - në hv-1):
ceph-deploy mon shkatërro hv-2Pas kësaj, mund të ndalni serverin dhe të kaloni në veprime të tjera (si rikthim të tij etj.).
Rasti â2. ShpĂ«rndarja e hapĂ«sirĂ«s nĂ« disk nĂ« njĂ« Ceph-klaster tĂ« krijuar tashmĂ«
Historinë e dytë do ta filloj me një parathënie mbi PG (). Roli kryesor i PG në Ceph është kryesisht aggregimi i objekteve Ceph dhe replicimi i mëtejshëm në OSD. Formula që mund të përdoret për të llogaritur numrin e nevojshëm të PG ndodhet në dokumentacionin Ceph. Aty diskutohen gjithashtu këto çështje përmes shembujve të konkretizuar.
Pra, një nga problemet më të zakonshme gjatë përdorimit të Ceph është numri i papërputhshëm i OSD dhe PG ndërmjet grupeve në Ceph.
Së pari, për këtë mund të ndodhi një situatë ku tregohet një numër i tepërt PG në një grup të vogël në volum, që në thelb është përdorim i paarsyeshëm i hapësirës në disk në klaster. Së dyti, në praktikë ndodh një problem më serioz: mbingarkesa e të dhënave në një OSD. Kjo çon në kalimin e klasterit fillimisht në një gjendje HEALTH_WARN, pastaj në HEALTH_ERR. E gjithë kjo ndodh për shkak se Ceph, kur llogarit volumet e disponueshëm të të dhënave (mund ta zbuloni atë me MAX AVAIL në daljen e komandës ceph df për secilin grup veçmas) mbështetet në volumet e të dhënave të disponueshme në OSD. Nëse edhe në një OSD ka vend të pamjaftueshëm, atëherë nuk do të mund të shkruani më të dhëna derisa ato të shpërndahen siç duhet ndërmjet të gjithë OSD.
Duhet theksuar se këto probleme zgjidhen kryesisht në fazën e konfigurimit të Ceph-klasterit. Një nga mjetet që mund të përdorni është . Me të, llogaritet qartë numri i nevojshëm i PG. Megjithatë, mund të përdoret gjithashtu në situatën kur klasteri Ceph tashmë nuk është konfiguruar siç duhet. Këtu duhet të sqarohet se gjatë punës për rregullimin, ju, më shumë se me siguri, do të keni nevojë të ulni numrin e PG, dhe kjo mundësi nuk është e disponueshme në versionet e vjetra të Ceph (ajo u prezantua vetëm me versionin ).
Tani, imagjinoni skenarin e mëposhtëm: klasteri ka status HEALTH_WARN për shkak se në një nga OSD përfundon hapësira. Kjo do të shfaqet si një gabim HEALTH_WARN: 1 near full osd. Më poshtë është paraqitur algoritmi për të dalë nga një situatë e tillë.
SĂ« pari, Ă«shtĂ« e nevojshme tĂ« shpĂ«rndahen tĂ« dhĂ«nat ekzistuese midis OSD-ve tĂ« tjera. NjĂ« operacion tĂ« tillĂ« kemi kryer tashmĂ« nĂ« rastin e parĂ«, kur "thithnim" nyjĂ«n â me ndryshimin se tani do tĂ« duhet tĂ« zvogĂ«lojmĂ« paksa ri. PĂ«r shembull, deri nĂ« 0.95:
ceph osd reweight osd.${ID} 0.95Kështu, lirohet hapësira e disqeve në OSD dhe rregullohet problemi në ceph health. Megjithatë, siç u tha më parë, ky problem kryesisht ndodh për shkak të konfigurimit të gabuar të Ceph në fazat fillestare: është shumë e rëndësishme të bëhet rikonfigurimi, në mënyrë që ai të mos shfaqet në të ardhmen.
Në rastin tonë konkret, gjithçka zavendësohet në:
- një vlerë shumë të lartë
replication_countnĂ« njĂ« nga pool-et, - njĂ« numĂ«r shumĂ« tĂ« lartĂ« PG nĂ« njĂ« pool dhe shumĂ« tĂ« ulĂ«t â nĂ« tjetrin.
Do të përdorim kalkulatorin e përmendur më parë. Atij i është treguar qartë se çfarë duhet të futet dhe, në përgjithësi, nuk ka asgjë të komplikuar. Duke caktuar parametrat e nevojshëm, marrim rekomandimet e mëposhtme:
Shënim: nëse po konfiguroni një klaster Ceph nga fillimi, një funksion tjetër i dobishëm i kalkulatorit do të jetë gjenerimi i komandave që do të krijojnë pool me parametra të caktuar në tabelë.
Ndihmon tĂ« orientohesh kolona e fundit â Suggested PG Count. NĂ« rastin tonĂ«, e dobishme Ă«shtĂ« edhe e dyta, ku tregohet parimi i replikimit, sepse vendosĂ«m tĂ« ndryshojmĂ« dhe faktorĂ«t e replikimit.
Pra, fillimisht do tĂ« nevojitet tĂ« ndryshohen parametrat e replikimit â kjo duhet tĂ« bĂ«het mĂ« parĂ«, sepse, duke zvogĂ«luar faktorĂ«t, do tĂ« lirohet hapĂ«sira diskore. GjatĂ« ekzekutimit tĂ« komandĂ«s mund tĂ« vĂ«reni se vlera e hapĂ«sirĂ«s diskore tĂ« disponueshme do tĂ« rritet:
ceph osd pool $pool_name set $replication_size Dhe pas pĂ«rfundimit tĂ« saj â ndryshojmĂ« vlerat e parametrave pg_num dhe pgp_num nĂ« mĂ«nyrĂ« tĂ« tillĂ«:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberĂhtĂ« e rĂ«ndĂ«sishme: ne duhet tĂ« ndryshojmĂ« radhazi numrin e PG nĂ« çdo pool dhe tĂ« mos ndryshojmĂ« vlerat nĂ« pool-et e tjera, derisa tĂ« zhduken paralajmĂ«rimet "Degraded data redundancy" dhe "n-number of pgs degraded".
Të kontrolloni nëse gjithçka ka shkuar me sukses, mund të bëni gjithashtu përmes rezultateve të komandave ceph health detail dhe ceph -s.
Rasti Nr. 3. Migrimi i një maine virtuale me LVM në Ceph RBD
Në situatën kur projekti përdor makina virtuale të instaluara në servera bare-metal të marrë me qira, shpesh lind pyetja për ruajtjen e qëndrueshme. Po ashtu, është shumë e dëshirueshme që hapësira në këtë ruajtje të jetë e mjaftueshme... Një situatë tjetër e zakonshme: ka një makinë virtuale me ruajtje lokale në server dhe është e nevojshme të zgjerohet disku, por nuk ka ku, pasi nuk ka mbetur hapësirë e lirë në server.
Problemi mund tĂ« zgjidhet nĂ« mĂ«nyra tĂ« ndryshme â pĂ«r shembull, duke migruar nĂ« njĂ« server tjetĂ«r (nĂ«se ka njĂ« tĂ« tillĂ«) ose duke shtuar disqe tĂ« reja nĂ« server. Por nuk Ă«shtĂ« gjithmonĂ« e mundur ta bĂ«sh kĂ«tĂ«, ndaj migrimi nga LVM nĂ« Ceph mund tĂ« jetĂ« njĂ« zgjidhje e shkĂ«lqyer pĂ«r kĂ«tĂ« problem. Duke zgjedhur kĂ«tĂ« variant, ne gjithashtu e thjeshtojmĂ« procesin e mĂ«tejshĂ«m tĂ« migrimit midis serverave, pasi nuk do tĂ« jetĂ« e nevojshme tĂ« lĂ«vizim ruajtjen lokale nga njĂ« hipervizor nĂ« njĂ« tjetĂ«r. E vetmja pengesĂ« â do tĂ« duhet tĂ« ndalojmĂ« VM-nĂ« pĂ«r kohĂ«n e kryerjes sĂ« punimeve.
Siç po aludohet mĂ« poshtĂ« , udhĂ«zimi i tĂ« cilit Ă«shtĂ« provuar nĂ« veprim. PĂ«r ta thĂ«nĂ« ndryshe, atje pĂ«rmendet gjithashtu edhe njĂ« mĂ«nyrĂ« e migrimit tĂ« thjeshtĂ«, ndonĂ«se nĂ« rastin tonĂ« ai thjesht nuk ishte i nevojshĂ«m, prandaj nuk e kemi kontrolluar. NĂ«se kjo Ă«shtĂ« thelbĂ«sore pĂ«r projektin tuaj â do tĂ« ishim tĂ« lumtur tĂ« mĂ«sojmĂ« pĂ«r rezultatet nĂ« komentet.
Të kalojmë në pjesën praktike. Në shembullin tonë ne përdorim virsh dhe, për pasojë, libvirt. Në fillim sigurohuni që puli Ceph, në të cilin do të migrohen të dhënat, është lidhur me libvirt:
virsh pool-dumpxml $ceph_poolNë përshkrimin e pulit duhet të jenë të dhënat e lidhjes me Ceph me të dhëna për autorizim.
Hapi tjetër përfshin konvertimin e imazhit LVM në Ceph RBD. Koha e realizimit varet kryesisht nga madhësia e imazhit:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_namePas konvertimit do tĂ« mbetet imazhi LVM, i cili do tĂ« jetĂ« i dobishĂ«m nĂ« rast se migrimi i VM-sĂ« nĂ« RBD nuk do tĂ« jetĂ« i suksesshĂ«m dhe do tĂ« duhet tĂ« kthehemi prapa. Po ashtu â pĂ«r mundĂ«sinĂ« e shpejtĂ« tĂ« rikthimit tĂ« ndryshimeve â do tĂ« bĂ«jmĂ« njĂ« kopje rezervĂ« tĂ« skedarit tĂ« konfigurimit tĂ« makinĂ«s virtuale:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml ⊠dhe do të redaktojmë origjinalin (vm_name.xml). Do të gjejmë bllokun me përshkrimin e diskut (fillon me rreshtin <disk type='file' device='disk'> dhe përfundon në </disk>) dhe do ta çojmë atë në formën e mëposhtme:
Shikojmë disa detaje:
- NĂ« protokoll
sourcetregohet adresa e magazinimit në Ceph RBD (kjo është adresa që përmban emrin e Ceph pool dhe RBD imazhin, i cili u përcaktua në fazën e parë). - Në bllokun
sekretcaktohet tipiceph, si dhe UUID i sekretit për lidhje me të. UUID i tij mund të merret duke përdorur komandënvirsh secret-list. - Në bllokun
hostku tregohet adresat e monitorëve Ceph.
Pas redaktimit të skedarit të konfigurimit dhe përfundimit të konvertimit të LVM në RBD, mund të aplikoni skedarin e ri të konfigurimit dhe të nisni makinën virtuale:
virsh define $vm_name.xml
virsh start $vm_name Ka ardhur koha të kontrolloni nëse makina virtuale është nisur siç duhet: mund ta kontrolloni, për shembull, duke u lidhur me të përmes SSH ose përmes virsh.
Nëse makina virtuale funksionon siç duhet dhe nuk keni zbuluar probleme të tjera, atëherë mund ta hiqni imazhin LVM, i cili nuk përdoret më:
lvremove main/$vm_image_namePĂ«rfundim
TĂ« gjitha rastet e pĂ«rshkruara i kemi hasur nĂ« praktikĂ« â shpresojmĂ« qĂ« kĂ«to udhĂ«zime do t'i ndihmojnĂ« edhe administratoret e tjerĂ« tĂ« zgjidhin probleme tĂ« ngjashme. NĂ«se keni vĂ«rejtje ose histori tĂ« tjera tĂ« ngjashme nga pĂ«rvoja e pĂ«rdorimit tĂ« Ceph â do tĂ« na pĂ«lqente t'i shihnim ato nĂ« komentet!
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
