Duke përdorim Ceph si ruajtje rrjeti në projekte me ngarkesa të ndryshme, mund të përballim sfida të ndryshme që në shikim të parë nuk duken të thjeshta ose triviale. Për shembull:
- migrimi i të dhënave nga Ceph i vjetër në atë të ri me përdorimin e pjesshëm 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 u marrë me këto sfida, ne hasim nevojën për të nxjerrë saktë OSD pa humbje të të dhënave, që është veçanërisht e rëndësishme kur kemi sasi të mëdha të dhënash. Kjo është ajo që do të diskutohet në këtë artikull.
Metoda të përshkruara më poshtë janë të përshtatshme për çdo version të Ceph. Për më tepër, do të merret parasysh fakti se Ceph mund të ruajë një volum të madh të dhënash: për të parandaluar humbjen e të dhënave dhe probleme të tjera, disa veprime do të "ndarë" në disa të tjera.
Parathënie për OSD
Duke qenĂ« se dy nga tre recetat e shqyrtuara janĂ« tĂ« dedikuara pĂ«r OSD (), para se tĂ« kalojmĂ« nĂ« pjesĂ«n praktike â shkurtimisht pĂ«r atĂ« qĂ« Ă«shtĂ« ky proces nĂ« Ceph dhe pse Ă«shtĂ« kaq i rĂ«ndĂ«sishĂ«m.
Së pari, duhet të themi se i gjithë klasteri Ceph përbëhet nga shumë OSD. Sa më shumë OSD të kemi, aq më shumë hapësirë të lirë kemi në Ceph. Kështu, është e lehtë të kuptojmë funksionin kryesor të OSD: ai ruan të dhënat e objekteve Ceph në sistemet e skedarëve të të gjithë node-ve të klasterit dhe ofron qasje rrjeti në to (për lexim, shkrim dhe kërkesa të tjera).
Në këtë nivel vendosen parametrat e replikimit përmes kopjimit të objekteve midis OSD të ndryshme. Dhe këtu mund të hasni në probleme të ndryshme, zgjidhjen e të cilave do ta diskutojmë më tej.
Rasti â1. Nxjerrja e sigurt e OSD nga klasteri Ceph pa humbje tĂ« tĂ« dhĂ«nave
Nevoja pĂ«r tĂ« nxjerrĂ« OSD mund tĂ« shkaktohet nga heqja e serverit nga klasteri â pĂ«r shembull, pĂ«r ta zĂ«vendĂ«suar me njĂ« server tjetĂ«r â çka ndodhi nĂ« rastin tonĂ« dhe shĂ«rbeu si arsye pĂ«r tĂ« shkruar kĂ«tĂ« artikull. KĂ«shtu, qĂ«llimi pĂ«rfundimtar i manovrave Ă«shtĂ« tĂ« nxjerrim tĂ« gjithĂ« OSD dhe monâĂ«t nĂ« kĂ«tĂ« server, nĂ« mĂ«nyrĂ« qĂ« ta ndalojmĂ« atĂ«.
Për lehtësinë dhe për të eliminuar situatën ku gjatë kryerjes së komandave gabojmë në caktimin e OSD të duhur, do të vendosim një ndryshore të veçantë, vlera e së cilës do të jetë numri i OSD të hequr. Do ta quajmë ${ID} - këtu dhe më tej kjo ndryshore do të zëvendësojë numrin e OSD me të cilin 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 heqjen e OSD, do të duhet të kryejmë ngadalë reweight në të deri në zero. Kështu ne ulin sasinë e të dhënave në OSD duke balancuar ato në OSD të tjera. Për këtë do të ekzekutojmë 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 ngadalë është i nevojshëm, për të mos humbur të dhëna. Kjo është veçanërisht e rëndësishme nëse në OSD ndodhet një sasi e madhe të dhënash. Për t'u siguruar që pas ekzekutimit të komandave reweight gjithçka shkoi mirë, mund të ekzekutoni ceph -s ose në një dritare të veçantë të terminalit të nisni ceph -w për të parë ndryshimet në kohë reale.
Kur OSD "është zbrazur", mund të filloni operacionin standard për heqjen e saj. Për këtë, do ta kalojmë OSD-në e nevojshme në gjendjen down:
ceph osd down osd.${ID}"Do ta nxjerrim" OSD nga klasteri:
ceph osd out osd.${ID}Do të ndalojmë shërbimin OSD dhe do ta heqim pjesën e tij nga FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Do të heqim OSD nga :
ceph osd crush remove osd.${ID}Do të heqim përdoruesin OSD:
ceph auth del osd.${ID}Dhe, përfundimisht, do të 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ërmendura më sipër për heqjen e OSD mund të reduktohen në dy komanda:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Nëse pas përfundimit të veprimeve të mësipërme ekzekutoni komandën ceph osd tree, duhet të shihet se në serverin ku u realizuan punimet, nuk ekziston më OSD për të cilat u realizuan 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 Dhe njëkohësisht do të vërejmë se gjendja e klasterit Ceph do të kalojë në HEALTH_WARN, dhe gjithashtu do të shohim pakësimin e numrit të OSD dhe sasisë së hapësirës diskore të disponueshme.
Më pas 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 përpara se të çaktivizoni serverin, duhet të nxirrni të gjitha OSD në këtë server.
Nëse në këtë server nuk ka mbetur asnjë OSD, atëherë 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Ă«s mĂ« poshtĂ« nĂ« njĂ« server tjetĂ«r (dmth, nĂ« kĂ«tĂ« rast â nĂ« hv-1):
ceph-deploy mon destroy hv-2Pas kësaj, mund të ndaloni serverin dhe të kaloni në hapat e tjerë (përsëritjen e tij dhe tjerë).
Rasti â2. ShpĂ«rndarja e hapĂ«sirĂ«s diskore nĂ« njĂ« klaster Ceph tĂ« krijuar tashmĂ«
Historinë e dytë do ta filloj me një parathënie rreth PG (). Roli kryesor i PG në Ceph është në thelb agregimi i objekteve Ceph dhe më pas replikimi në OSD. Formula me anë të së cilës mund të llogaritet numri i nevojshëm i PG është e gjetur në dokumentacionin e Ceph. Atje po ashtu ky problem trajtohet me shembuj konkretë.
Pra, një nga problemet më të zakonshme gjatë përdorimit të Ceph është numri i paekuilibruar i OSD dhe PG mes grupeve në Ceph.
Së pari, për shkak të kësaj mund të ndodhë një situatë kur atmosfera e PG është shumë e madhe në një grup me volum të vogël, që në të vërtetë është një shfrytëzim irracional i hapësirës diskore në klaster. Së dyti, në praktikë ndodh një problem më serioz: mbushja e të dhënave në një nga OSD. Kjo shkakton kalimin e klasterit fillimisht në gjendjen HEALTH_WARN, dhe pastaj në HEALTH_ERR. E gjithë kjo është për shkak se Ceph gjatë llogaritjes së volumit të të dhënave të disponueshme (mund ta zbuloni në MAX AVAIL në rezultatin 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 të paktën në një OSD nuk ka mjaft hapësirë, atëherë nuk është e mundur të shkruhen të dhënat derisa ato të shpërndahen siç duhet mes të gjitha OSD.
Duhet të sqarojmë se këto probleme zgjidhen kryesisht në fazën e konfigurimit të klasterit Ceph. Një nga mjetet që mund të shfrytëzohet është . Me ndihmën e tij llogaritet në mënyrë vizuale numri i nevojshëm i PG. Megjithatë, mund të përdoret edhe në situata kur klasteri Ceph janë është konfigurua gabim. Këtu duhet sqaruar se gjatë punës për ndreqjen, ju ndoshta do t'ju nevojitet të zvogëloni numrin e PG, dhe kjo mundësi nuk është e disponueshme në versionet e vjetra të Ceph (ajo u shfaq vetëm me versionin ).
Kështu, le të paraqesim marrëdhënien e mëposhtme: klasteri ka statusin HEALTH_WARN për shkak se një nga OSD po i mbaron hapësira. Kjo do të shprehej me një gabim HEALTH_WARN: 1 near full osd. Më poshtë paraqitet algoritmi për daljen nga një situatë e tillë.
NĂ« radhĂ« tĂ« parĂ«, Ă«shtĂ« e nevojshme tĂ« shpĂ«rndahen tĂ« dhĂ«nat e disponueshme midis OSD tĂ« tjerĂ«. NjĂ« operacion tĂ« tillĂ« e kemi kryer tashmĂ« nĂ« rastin e parĂ«, kur u âthithĂ«mâ nyjĂ«n â me atĂ« ndryshim, qĂ« tani do tĂ« nevojitet ta zvogĂ«lojmĂ« paksa reweight. PĂ«r shembull, deri nĂ« 0.95:
ceph osd reweight osd.${ID} 0.95Kështu, hapësira diskore lirohet në OSD dhe gabimi në shëndetin e ceph rregullohet. Megjithatë, siç u tha, ky problem para së gjithash ndodhi për arsye të konfigurimit të papërshtatshëm të Ceph në fillim: është shumë e rëndësishme të bëhet rekonstrukcija, në mënyrë që të mos shfaqet në të ardhmen.
Në rastin tonë, gjithçka varej nga:
- një vlerë shumë e madhe
replication_countnë një nga grupet, - numri shumë i madh i PG në një grup dhe aq shumë i vogël në një tjetër.
Le të përdorim kalkulatorin e përmendur më parë. Atij i janë shpjeguar qartë se çfarë duhet të futet dhe, në thelb, nuk ka asgjë të komplikuar. Duke futur 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, të cilat do të krijojnë grupe nga fillimi me parametrat e caktuar në tabelë.
Drejtimi ndihmon kolona e fundit â Suggested PG Count. NĂ« rastin tonĂ«, e dobishme Ă«shtĂ« gjithashtu kolona e dytĂ«, ku Ă«shtĂ« treguar parametri i replikimit, pasi ne vendosĂ«m tĂ« ndryshojmĂ« edhe faktorĂ«t e replikimit.
Pra, sĂ« pari do tĂ« nevojitet tĂ« ndryshoni parametrat e replikimit â kjo duhet bĂ«rĂ« sĂ« pari, pasi duke zvogĂ«luar faktorĂ«t, ne do tĂ« lirojmĂ« hapĂ«sirĂ« diskore. GjatĂ« ekzekutimit tĂ« komandĂ«s mund tĂ« vĂ«reni se vlerat e hapĂ«sirĂ«s diskore tĂ« disponueshme do tĂ« rriten:
ceph osd pool $pool_name set $replication_size Dhe pas pĂ«rfundimit tĂ« saj â ndryshojmĂ« vlerat e parametrave pg_num dhe pgp_num si nga:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberE rëndësishme: duhet të ndryshojmë radhazi numrin e PG në çdo grup dhe të mos ndryshojmë vlerat në grupet e tjera deri sa të zhduken paralajmërimet «Degraded data redundancy» dhe «n-number of pgs degraded».
Për të verifikuar se gjithçka ka kaluar me sukses, mund të shihni gjithashtu rezultatet e komandave ceph health detail dhe ceph -s.
Rasti â3. Migrimi i njĂ« maune virtuale nga LVM nĂ« Ceph RBD
Në situatat kur projekti përdor makina virtuale të vendosura në serverë të marrë me qira bare-metal, 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ë tjetër situatë e zakonshme është: ka një makinë virtuale me ruajtje lokale në server dhe është e nevojshme të zgjerohet disku, por nuk ka vend, pasi në server nuk ka më hapësirë të lirë disku.
Problemin mund ta zgjidhim 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Ă« rinj nĂ« server. Por, nuk Ă«shtĂ« gjithmonĂ« e mundur ta bĂ«jmĂ« kĂ«tĂ«, prandaj migroja nga LVM nĂ« Ceph mund tĂ« jetĂ« njĂ« zgjidhje e shkĂ«lqyer pĂ«r kĂ«tĂ« problem. Duke zgjedhur kĂ«tĂ« mundĂ«si, ne gjithashtu thjeshtojmĂ« procesin e mĂ«tejshĂ«m tĂ« migrimit midis serverĂ«ve, pasi nuk do tĂ« ketĂ« nevojĂ« tĂ« lĂ«vizim ruajtjen lokale nga njĂ« hipervizor nĂ« tjetrin. E vetmja pengesĂ« Ă«shtĂ« se do tĂ« duhet tĂ« ndalojmĂ« VM pĂ«rkohĂ«sisht gjatĂ« punĂ«s.
Si referencĂ« e dhĂ«nĂ« mĂ« poshtĂ« Ă«shtĂ« , udhĂ«zimet e tĂ« cilit janĂ« testuar nĂ« praktikĂ«. PĂ«r t'u pĂ«rmendur, aty pĂ«rmendet gjithashtu njĂ« mĂ«nyrĂ« pa ndĂ«rlikime pĂ«r migrim, por nĂ« rastin tonĂ« kjo thjesht nuk u nevojit, prandaj nuk e kontrolluam. NĂ«se kjo Ă«shtĂ« kritike pĂ«r projektin tuaj â do tĂ« na bĂ«ntĂ« tĂ« lumtur tĂ« dĂ«gjojmĂ« rreth rezultateve nĂ« komentet.
Le të kalojmë në pjesën praktike. Në shembullin tonë ne përdorim virsh dhe, përkatësisht, libvirt. Fillimisht sigurohuni që puli i Ceph-it, në të cilin do të migrohen të dhënat, është i lidhur me libvirt:
virsh pool-dumpxml $ceph_poolNë përshkrimin e pulit duhet të ketë të dhëna lidhjeje me Ceph me të dhëna për autorizim.
Hapi tjetër është që imazhi LVM konvertohet në Ceph RBD. Koha e ekzekutimit 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 nĂ« RBD nuk funksionon dhe do tĂ« duhet tĂ« rikthejmĂ« ndryshimet. Po ashtu â pĂ«r mundĂ«sinĂ« e rikthimit tĂ« shpejtĂ« tĂ« ndryshimeve â do tĂ« bĂ«jmĂ« njĂ« backup tĂ« skedarit pĂ«r konfigurimin e 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 disku (fillon me rreshtin <disk type='file' device='disk'> dhe mbaron në </disk>) dhe do ta sjellim në formatin e mëposhtëm:
Le të shqyrtojmë disa detaje:
- NĂ« protokoll
sourcespecifikohet adresa deri në ruajtjen në Ceph RBD (kjo është adresa me emrin e Ceph-pulit dhe imazhin RBD, i cili u identifikua në hapin e parë). - Në bllokun
sekretspecifikohet llojiceph, si dhe UUID i sekreteve për lidhjen me të. UUID-në e tij mund ta gjeni duke përdorur komandënvirsh secret-list. - Në bllokun
hostspecifikohen adresat deri te monitorët e Ceph.
Pas redaktimit të skedarit të konfigurimit dhe përfundimit të konvertimit nga LVM në RBD, mund të aplikoni skedarin e ndryshuar të konfigurimit dhe të nisni makinën virtuale:
virsh define $vm_name.xml
virsh start $vm_name ĂshtĂ« koha pĂ«r tĂ« kontrolluar qĂ« makina virtuale tĂ« ketĂ« nisur siç duhet: mund ta kuptoni, pĂ«r shembull, duke u lidhur me tĂ« pĂ«rmes SSH ose pĂ«rmes virsh.
Nëse makina virtuale funksionon në mënyrë korrekte 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Ă«rfundimi
TĂ« gjitha rastet e pĂ«rshkruara mĂ« lart ne i kemi hasur nĂ« praktikĂ« â shpresojmĂ« qĂ« udhĂ«zimet do t'i ndihmojnĂ« edhe administratoret e tjerĂ« tĂ« zgjidhin probleme tĂ« ngjashme. NĂ«se keni ndonjĂ« komente ose histori tĂ« tjera tĂ« ngjashme nga pĂ«rvoja e punĂ«s me Ceph â do tĂ« na bĂ«ntĂ« tĂ« lumtur t'i shohim ato nĂ« komentet!
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
