Deur Ceph as netwerkberging in projekte met verskillende vragte te gebruik, kan ons verskeie take teëkom wat met die eerste oogopslag nie eenvoudig of triviaal lyk nie. Byvoorbeeld:
- migrasie van data van ou Ceph na nuwe een met gedeeltelike gebruik van vorige bedieners in die nuwe groepering;
- oplossing vir die probleem van skyfspasietoewysing in Ceph.
Om sulke probleme te hanteer, word ons gekonfronteer met die behoefte om die OSD korrek te verwyder sonder om data te verloor, wat veral belangrik is wanneer groot hoeveelhede data hanteer word. Dit sal in die artikel bespreek word.
Die metodes wat hieronder beskryf word, is relevant vir enige weergawe van Ceph. Daarbenewens sal die feit dat Ceph 'n groot hoeveelheid data kan stoor, in ag geneem word: om dataverlies en ander probleme te voorkom, sal sommige aksies in verskeie ander "verdeel" word.
Voorwoord oor OSD
Aangesien twee van die drie resepte wat bespreek word, aan OSD gewy is (), voordat jy in die praktiese deel duik - kortliks oor wat dit in Ceph is en hoekom dit so belangrik is.
Eerstens moet gesê word dat die hele Ceph-kluster uit baie OSD's bestaan. Hoe meer daar is, hoe groter is die gratis datavolume in Ceph. Dit is maklik om van hier af te verstaan hoof OSD-funksie: Dit stoor Ceph-objekdata op die lêerstelsels van alle cluster nodusse en verskaf netwerktoegang daartoe (vir lees, skryf en ander versoeke).
Op dieselfde vlak word replikasieparameters gestel deur voorwerpe tussen verskillende OSD's te kopieer. En hier kan u verskillende probleme ondervind, waarvan die oplossings hieronder bespreek sal word.
Saak nr. 1. Verwyder OSD veilig van Ceph-groepering sonder om data te verloor
Die behoefte om die OSD te verwyder kan veroorsaak word deur die bediener uit die groep te verwyder - byvoorbeeld om dit te vervang met 'n ander bediener - wat is wat met ons gebeur het, wat aanleiding gee tot die skryf van hierdie artikel. Dus, die uiteindelike doel van manipulasie is om alle OSD's en mons op 'n gegewe bediener te onttrek sodat dit gestop kan word.
Gerieflikheidshalwe en om 'n situasie te vermy waar ons, terwyl ons opdragte uitvoer, 'n fout maak om die vereiste OSD aan te dui, sal ons 'n aparte veranderlike stel, waarvan die waarde die nommer van die OSD sal wees wat uitgevee moet word. Kom ons bel haar ${ID} — hier en onder vervang so 'n veranderlike die nommer van die BSB waarmee ons werk.
Kom ons kyk na die toestand voordat ons begin werk:
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
Om OSD-verwydering te begin, sal jy glad moet werk reweight daarop tot nul. Op hierdie manier verminder ons die hoeveelheid data in die BSB deur dit na ander BSB's te balanseer. Om dit te doen, voer die volgende opdragte uit:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... en so aan tot nul.
Gladde balansering vereisom nie data te verloor nie. Dit is veral waar as die OSD 'n groot hoeveelheid data bevat. Om seker te maak dat na die uitvoering van die opdragte reweight alles het goed gegaan, jy kan dit voltooi ceph -s of in 'n aparte terminale venster loop ceph -w om veranderinge in reële tyd waar te neem.
Wanneer die OSD "leeggemaak" is, kan jy voortgaan met die standaardbewerking om dit te verwyder. Om dit te doen, dra die verlangde OSD oor na die staat down:
ceph osd down osd.${ID}Kom ons "trek" die OSD uit die groep:
ceph osd out osd.${ID}Kom ons stop die OSD-diens en ontkoppel sy partisie in die FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Verwyder OSD uit :
ceph osd crush remove osd.${ID}Kom ons vee die OSD-gebruiker uit:
ceph auth del osd.${ID}En uiteindelik, laat ons die OSD self verwyder:
ceph osd rm osd.${ID}Let daarop: As jy die Ceph Luminous-weergawe of hoër gebruik, kan die bogenoemde OSD-verwyderingsstappe tot twee opdragte verminder word:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
As jy die opdrag uitvoer nadat jy die stappe hierbo beskryf het voltooi ceph osd tree, dan moet dit duidelik wees dat op die bediener waar die werk uitgevoer is, daar nie meer OSD's is waarvoor die bogenoemde bewerkings uitgevoer is nie:
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
Langs die pad, let op dat die toestand van die Ceph cluster sal gaan na HEALTH_WARN, en ons sal ook 'n afname in die aantal OSD's en die hoeveelheid beskikbare skyfspasie sien.
Die volgende sal die stappe beskryf wat benodig word as u die bediener heeltemal wil stop en dit dienooreenkomstig van Ceph af wil verwyder. In hierdie geval is dit belangrik om dit te onthou Voordat u die bediener afskakel, moet u alle OSD's verwyder op hierdie bediener.
As daar nie meer OSD's op hierdie bediener oor is nie, moet jy die bediener van die OSD-kaart uitsluit nadat jy dit verwyder het hv-2deur die volgende opdrag uit te voer:
ceph osd crush rm hv-2
Verwyder mon vanaf die bediener hv-2deur die opdrag hieronder op 'n ander bediener uit te voer (d.w.s. in hierdie geval, aan hv-1):
ceph-deploy mon destroy hv-2Hierna kan jy die bediener stop en daaropvolgende aksies begin (herontplooi dit, ens.).
Saak nr 2. Verspreiding van skyfspasie in 'n reeds geskepte Ceph-kluster
Ek begin die tweede storie met 'n voorwoord oor PG (). Die hoofrol van PG in Ceph is hoofsaaklik om Ceph-voorwerpe saam te voeg en dit verder in OSD te repliseer. Die formule waarmee jy die vereiste hoeveelheid PG kan bereken, is in Ceph dokumentasie. Hierdie kwessie word ook daar met spesifieke voorbeelde bespreek.
Dus: een van die algemene probleme wanneer Ceph gebruik word, is die ongebalanseerde aantal OSD en PG tussen poele in Ceph.
Eerstens, as gevolg hiervan, kan 'n situasie ontstaan wanneer te veel PG's in 'n klein poel gespesifiseer word, wat in wese 'n irrasionele gebruik van skyfspasie in die groepering is. Tweedens is daar in die praktyk 'n ernstiger probleem: data-oorloop in een van die BSB'e. Dit behels dat die groep eers na die staat oorgaan HEALTH_WARN, en toe HEALTH_ERR. Die rede hiervoor is dat Ceph, wanneer jy die beskikbare hoeveelheid data bereken (jy kan dit uitvind deur MAX AVAIL in opdraguitvoer ceph df vir elke poel afsonderlik) is gebaseer op die hoeveelheid beskikbare data in die BSB. As daar nie genoeg spasie in ten minste een OSD is nie, kan nie meer data geskryf word totdat die data behoorlik onder alle OSD's versprei is nie.
Dit is die moeite werd om te verduidelik dat hierdie probleme word grootliks in die Ceph-kluster-konfigurasiestadium besluit. Een van die gereedskap wat jy kan gebruik is . Met sy hulp word die vereiste hoeveelheid PG duidelik bereken. Jy kan egter ook daarheen gryp in 'n situasie waar die Ceph groepeer reeds verkeerd gekonfigureer. Dit is die moeite werd om hier te verduidelik dat u as deel van die regstellingswerk heel waarskynlik die aantal PG's sal moet verminder, en hierdie kenmerk is nie beskikbaar in ouer weergawes van Ceph nie (dit het slegs in weergawe verskyn ).
So, kom ons stel ons die volgende prentjie voor: die groep het 'n status HEALTH_WARN as gevolg van een van die OSD's wat nie meer spasie het nie. Dit sal deur 'n fout aangedui word HEALTH_WARN: 1 near full osd. Hieronder is 'n algoritme om uit hierdie situasie te kom.
Eerstens moet u die beskikbare data tussen die oorblywende OSD's versprei. Ons het reeds in die eerste geval 'n soortgelyke operasie uitgevoer toe ons die nodus "gedreineer" het - met die enigste verskil dat ons nou effens sal moet verminder reweight. Byvoorbeeld, tot 0.95:
ceph osd reweight osd.${ID} 0.95Dit maak skyfspasie in die OSD vry en maak die fout in ceph-gesondheid reg. Soos reeds genoem, kom hierdie probleem egter hoofsaaklik voor as gevolg van die verkeerde konfigurasie van Ceph in die aanvanklike stadiums: dit is baie belangrik om 'n herkonfigurasie te maak sodat dit nie in die toekoms verskyn nie.
In ons spesifieke geval het dit alles neergekom op:
- waarde te hoog
replication_countin een van die swembaddens, - te veel PG in een swembad en te min in 'n ander.
Kom ons gebruik die reeds genoemde sakrekenaar. Dit wys duidelik wat ingevoer moet word en in beginsel is daar niks ingewikkeld nie. Nadat ons die nodige parameters gestel het, kry ons die volgende aanbevelings:
Let daarop: As jy 'n Ceph-kluster van nuuts af opstel, is 'n ander nuttige funksie van die sakrekenaar die generering van opdragte wat poele van nuuts af sal skep met die parameters wat in die tabel gespesifiseer word.
Die laaste kolom help jou om te navigeer - Voorgestelde PG-telling. In ons geval is die tweede een ook nuttig, waar die replikasieparameter aangedui word, aangesien ons besluit het om die replikasievermenigvuldiger te verander.
Dus, eers moet u die replikasieparameters verander - dit is die moeite werd om eers te doen, aangesien ons skyfspasie sal vrymaak deur die vermenigvuldiger te verminder. Soos die opdrag uitgevoer word, sal jy sien dat die beskikbare skyfspasie sal toeneem:
ceph osd pool $pool_name set $replication_size
En nadat dit voltooi is, verander ons die parameterwaardes pg_num и pgp_num soos volg:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberDit is belangrik om: ons moet die aantal PG's opeenvolgend in elke poel verander en nie die waardes in ander poele verander totdat die waarskuwings verdwyn nie "Verminderde data-oortolligheid" и "n-getal bladsye gedegradeer".
U kan ook kontroleer dat alles goed gegaan het deur die opdraguitsette te gebruik ceph health detail и ceph -s.
Saak nr 3. Migreer 'n virtuele masjien van LVM na Ceph RBD
In 'n situasie waar 'n projek virtuele masjiene gebruik wat op gehuurde kaalmetaalbedieners geïnstalleer is, ontstaan die kwessie van foutverdraagsame berging dikwels. Dit is ook baie wenslik dat daar genoeg spasie in hierdie berging is... Nog 'n algemene situasie: daar is 'n virtuele masjien met plaaslike berging op die bediener en jy moet die skyf uitbrei, maar daar is nêrens om heen te gaan nie, want daar is nie vrye skyfspasie oor op die bediener.
Die probleem kan op verskillende maniere opgelos word - byvoorbeeld deur na 'n ander bediener te migreer (as daar een is) of deur nuwe skywe by die bediener te voeg. Maar dit is nie altyd moontlik om dit te doen nie, so migreer van LVM na Ceph kan 'n uitstekende oplossing vir hierdie probleem wees. Deur hierdie opsie te kies, vereenvoudig ons ook die verdere proses van migrasie tussen bedieners, aangesien dit nie nodig sal wees om plaaslike berging van een hypervisor na 'n ander te skuif nie. Die enigste vangplek is dat jy die VM sal moet stop terwyl die werk uitgevoer word.
Die volgende resep is geneem uit , waarvan die instruksies in aksie getoets is. Terloops, die metode van moeitevrye migrasie word ook daar beskryf, in ons geval was dit egter eenvoudig nie nodig nie, so ons het dit nie nagegaan nie. As dit van kritieke belang is vir jou projek, sal ons bly wees om te hoor van die resultate in die kommentaar.
Kom ons gaan aan na die praktiese deel. In die voorbeeld gebruik ons virsh en, dienooreenkomstig, libvirt. Maak eers seker dat die Ceph-poel waarheen die data gemigreer sal word aan libvirt gekoppel is:
virsh pool-dumpxml $ceph_poolDie poelbeskrywing moet verbindingsdata na Ceph met magtigingsdata bevat.
Die volgende stap is dat die LVM-beeld na Ceph RBD omgeskakel word. Uitvoeringstyd hang hoofsaaklik af van die grootte van die prent:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameNa die omskakeling sal 'n LVM-beeld oorbly, wat nuttig sal wees as die migreer van die VM na RBD misluk en jy die veranderinge moet terugrol. Kom ons maak ook 'n rugsteun van die konfigurasielêer van die virtuele masjien om vinnig veranderinge te kan terugrol:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... en wysig die oorspronklike (vm_name.xml). Kom ons soek 'n blok met 'n beskrywing van die skyf (begin met die lyn <disk type='file' device='disk'> en eindig met </disk>) en verminder dit na die volgende vorm:
<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>Kom ons kyk na 'n paar besonderhede:
- Na die protokol
sourcedie adres na die berging in Ceph RBD word aangedui (dit is die adres wat die naam van die Ceph-poel en die RBD-beeld aandui, wat in die eerste stadium bepaal is). - In die blok
secrettipe aangedui wordceph, sowel as die UUID van die geheim om daaraan te koppel. Die uuid kan gevind word deur die opdrag te gebruikvirsh secret-list. - In die blok
hostadresse aan Ceph-monitors word aangedui.
Nadat u die konfigurasielêer geredigeer en die LVM na RBD-omskakeling voltooi het, kan u die gewysigde konfigurasielêer toepas en die virtuele masjien begin:
virsh define $vm_name.xml
virsh start $vm_name
Dit is tyd om seker te maak dat die virtuele masjien reg begin het: jy kan dit uitvind, byvoorbeeld deur dit via SSH of via virsh.
As die virtuele masjien korrek werk en u geen ander probleme gevind het nie, kan u die LVM-beeld wat nie meer gebruik word nie, uitvee:
lvremove main/$vm_image_nameGevolgtrekking
Ons het al die beskryf gevalle in die praktyk teëgekom - ons hoop dat die instruksies ander administrateurs sal help om soortgelyke probleme op te los. As jy opmerkings of ander soortgelyke stories het uit jou ervaring met Ceph, sal ons dit graag in die kommentaar sien!
PS
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Bron: will.com