Uzante Ceph kiel retan stokadon en projektoj kun malsamaj ŝarĝoj, ni povas renkonti diversajn taskojn, kiuj unuavide ne ŝajnas simplaj aŭ bagatelaj. Ekzemple:
- migrado de datumoj de malnova Ceph al nova kun parta uzo de antaŭaj serviloj en la nova areto;
- solvo al la problemo de diskspaco asigno en Ceph.
Traktante tiajn problemojn, ni alfrontas la bezonon ĝuste forigi la OSD sen perdi datumojn, kio estas precipe grava kiam traktas grandajn kvantojn da datumoj. Ĉi tio estos diskutita en la artikolo.
La metodoj priskribitaj malsupre estas gravaj por iu ajn versio de Ceph. Krome, la fakto, ke Ceph povas stoki grandan kvanton da datumoj, estos konsiderata: por malhelpi datumperdon kaj aliajn problemojn, iuj agoj estos "dividitaj" en plurajn aliajn.
Antaŭparolo pri OSD
Ĉar du el la tri diskutitaj receptoj estas dediĉitaj al OSD (), antaŭ plonĝi en la praktikan parton - mallonge pri kio ĝi estas en Ceph kaj kial ĝi estas tiel grava.
Antaŭ ĉio, oni devas diri, ke la tuta Ceph-areo konsistas el multaj OSDoj. Ju pli estas, des pli granda estas la libera datumvolumo en Ceph. Estas facile kompreni de ĉi tie ĉefa OSD-funkcio: Ĝi stokas Ceph-objektodatenojn sur la dosiersistemoj de ĉiuj aretnodoj kaj disponigas retaliron al ĝi (por legado, skribo, kaj aliaj petoj).
Sur la sama nivelo, reproduktaj parametroj estas fiksitaj kopiante objektojn inter malsamaj OSDoj. Kaj ĉi tie vi povas renkonti diversajn problemojn, kies solvoj estos diskutitaj sube.
Kazo n-ro 1. Sekure forigu OSD de Ceph-areto sen perdi datumojn
La bezono forigi la OSD povas esti kaŭzita de forigo de la servilo de la grapolo - ekzemple, anstataŭigi ĝin per alia servilo - kio estas kio okazis al ni, kaŭzante la verkadon de ĉi tiu artikolo. Tiel, la finfina celo de manipulado estas ĉerpi ĉiujn OSDojn kaj monojn sur antaŭfiksita servilo por ke ĝi estu maldaŭrigita.
Por komforto kaj por eviti situacion, kie, dum plenumado de komandoj, ni eraras indikante la bezonatan OSD, ni starigos apartan variablon, kies valoro estos la nombro de la OSD por esti forigita. Ni voku ŝin ${ID} — ĉi tie kaj sube, tia variablo anstataŭas la nombron de la OSD, kun kiu ni laboras.
Ni rigardu la kondiĉon antaŭ ol komenci laboron:
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
Por komenci OSD-forigon, vi devos glate agi reweight sur ĝi ĝis nulo. Tiel ni reduktas la kvanton de datumoj en la OSD ekvilibrigante ĝin al aliaj OSD-oj. Por fari tion, rulu la jenajn komandojn:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... kaj tiel plu ĝis nulo.
Glata ekvilibro necesaspor ne perdi datumojn. Ĉi tio estas precipe vera se la OSD enhavas grandan kvanton da datumoj. Por certigi, ke post plenumi la komandojn reweight ĉio iris bone, vi povas kompletigi ĝin ceph -s aŭ en aparta fina fenestro kuras ceph -w por observi ŝanĝojn en reala tempo.
Kiam la OSD estas "malplenigita", vi povas daŭrigi kun la norma operacio por forigi ĝin. Por fari tion, translokigu la deziratan OSD al la ŝtato down:
ceph osd down osd.${ID}Ni "tiru" la OSD el la areto:
ceph osd out osd.${ID}Ni haltigu la OSD-servon kaj malmuntu ĝian sekcion en la FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Forigi OSD de :
ceph osd crush remove osd.${ID}Ni forigu la uzanton de OSD:
ceph auth del osd.${ID}Kaj finfine, ni forigu la OSD mem:
ceph osd rm osd.${ID}Примечание: Se vi uzas Ceph Luminous-version aŭ pli altan, tiam la supraj paŝoj pri forigo de OSD povas esti reduktitaj al du komandoj:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Se, post plenumi la paŝojn priskribitajn supre, vi rulas la komandon ceph osd tree, tiam devus esti klare, ke sur la servilo, kie la laboro estis farita, ne plu ekzistas OSD-oj por kiuj la supraj operacioj estis faritaj:
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
Survoje, notu, ke la stato de la Ceph-areto iros al HEALTH_WARN, kaj ni ankaŭ vidos malpliiĝon de la nombro da OSD-oj kaj la kvanto de disponebla diskospaco.
La jenaj priskribos la paŝojn, kiuj estos postulataj se vi volas tute haltigi la servilon kaj, sekve, forigi ĝin de Ceph. En ĉi tiu kazo, estas grave memori tion Antaŭ ol malŝalti la servilon, vi devas forigi ĉiujn OSDojn sur ĉi tiu servilo.
Se ne plu restas OSD-oj sur ĉi tiu servilo, tiam post forigo de ili, vi devas ekskludi la servilon de la OSD-mapo. hv-2rulante la sekvan komandon:
ceph osd crush rm hv-2
Forigi mon de la servilo hv-2rulante la komandon sube sur alia servilo (t.e. en ĉi tiu kazo, sur hv-1):
ceph-deploy mon destroy hv-2Post ĉi tio, vi povas haltigi la servilon kaj komenci postajn agojn (redeploji ĝin, ktp.).
Kazo n-ro 2. Distribuado de diskospaco en jam kreita Ceph-areto
Mi komencos la duan rakonton per antaŭparolo pri PG (). La ĉefa rolo de PG en Ceph estas ĉefe aldoni Ceph-objektojn kaj plue reprodukti ilin en OSD. La formulo per kiu vi povas kalkuli la bezonatan kvanton da PG estas en Ceph-dokumentado. Ĉi tiu afero ankaŭ estas diskutita tie kun specifaj ekzemploj.
Do: unu el la oftaj problemoj dum uzado de Ceph estas la malekvilibra nombro da OSD kaj PG inter naĝejoj en Ceph.
Unue, pro tio, situacio povas ekesti kiam tro multaj PG-oj estas specifitaj en malgranda naĝejo, kio estas esence neracia uzo de diskspaco en la areto. Due, praktike estas pli serioza problemo: datumoj superfluas en unu el la OSDoj. Ĉi tio implicas, ke la areto unue transiras al la ŝtato HEALTH_WARN, kaj tiam HEALTH_ERR. La kialo de ĉi tio estas, ke Ceph kalkulas la disponeblan kvanton da datumoj (vi povas eltrovi ĝin per MAX AVAIL en la komanda eligo ceph df por ĉiu naĝejo aparte) estas bazita sur la kvanto de disponeblaj datenoj en la OSD. Se ne estas sufiĉe da spaco en almenaŭ unu OSD, ne pli da datumoj povas esti skribitaj ĝis la datenoj estas konvene distribuitaj inter ĉiuj OSDoj.
Indas klarigi, ke ĉi tiuj problemoj estas plejparte deciditaj ĉe la Ceph-areta konfiguraciostadio. Unu el la iloj, kiujn vi povas uzi, estas . Kun ĝia helpo, la bezonata kvanto de PG estas klare kalkulita. Tamen, vi ankaŭ povas recurri al ĝi en situacio kie la Ceph-grupo jam agordita malĝuste. Indas klarigi ĉi tie, ke kadre de la ripara laboro vi plej verŝajne bezonos redukti la nombron da PG-oj, kaj ĉi tiu funkcio ne disponeblas en pli malnovaj versioj de Ceph (ĝi nur aperis en versio). ).
Do, ni imagu la sekvan bildon: la areto havas statuson HEALTH_WARN pro unu el la OSD mankas spaco. Ĉi tio estos indikita per eraro HEALTH_WARN: 1 near full osd. Malsupre estas algoritmo por eliri el ĉi tiu situacio.
Antaŭ ĉio, vi devas distribui la disponeblajn datumojn inter la ceteraj OSDoj. Ni jam faris similan operacion en la unua kazo, kiam ni "drenis" la nodon - kun la sola diferenco, ke nun ni devos iomete redukti reweight. Ekzemple, ĝis 0.95:
ceph osd reweight osd.${ID} 0.95Ĉi tio liberigas diskospacon en la OSD kaj riparas la eraron en ceph-sano. Tamen, kiel jam menciis, ĉi tiu problemo ĉefe okazas pro malĝusta agordo de Ceph en la komencaj etapoj: estas tre grave fari reagordon por ke ĝi ne aperu estonte.
En nia aparta kazo, ĉio reduktiĝis al:
- valoro tro alta
replication_counten unu el la naĝejoj, - tro da PG en unu naĝejo kaj tro malmulte en alia.
Ni uzu la jam menciitan kalkulilon. Ĝi klare montras tion, kion oni devas enigi kaj, principe, estas nenio komplika. Fiksinte la necesajn parametrojn, ni ricevas la jenajn rekomendojn:
Примечание: Se vi agordas Ceph-grupon de nulo, alia utila funkcio de la kalkulilo estas la generacio de komandoj, kiuj kreos poolojn de nulo kun la parametroj specifitaj en la tabelo.
La lasta kolumno helpas vin navigi - Sugestita PG-kalkulo. En nia kazo, la dua ankaŭ estas utila, kie la replika parametro estas indikita, ĉar ni decidis ŝanĝi la reproduktan multiplikaton.
Do, unue vi devas ŝanĝi la reproduktajn parametrojn - ĉi tio unue indas fari, ĉar reduktante la multiplikaton, ni liberigos diskspacon. Dum la komando efektiviĝas, vi rimarkos, ke la disponebla diskospaco pliiĝos:
ceph osd pool $pool_name set $replication_size
Kaj post ĝia kompletigo, ni ŝanĝas la parametrajn valorojn pg_num и pgp_num kiel sekvas:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numbergravaj: ni devas ŝanĝi la nombron da PG-oj sinsekve en ĉiu naĝejo kaj ne ŝanĝi la valorojn en aliaj naĝejoj ĝis la avertoj malaperos "Degradita datumredundo" и "n-nombro da paĝoj degradita".
Vi ankaŭ povas kontroli, ke ĉio iris bone uzante la komandajn eligojn ceph health detail и ceph -s.
Kazo n-ro 3. Migrado virtuala maŝino de LVM al Ceph RBD
En situacio kie projekto uzas virtualajn maŝinojn instalitajn sur luigitaj nudmetalaj serviloj, ofte aperas la temo de mistolerema stokado. Ankaŭ estas tre dezirinde, ke estas sufiĉe da spaco en ĉi tiu stokado... Alia ofta situacio: estas virtuala maŝino kun loka stokado sur la servilo kaj vi bezonas vastigi la diskon, sed ne estas kie iri, ĉar ne ekzistas. libera diskospaco lasita sur la servilo.
La problemo povas esti solvita en malsamaj manieroj - ekzemple, migrante al alia servilo (se ekzistas) aŭ aldonante novajn diskojn al la servilo. Sed ne ĉiam eblas fari ĉi tion, do migri de LVM al Ceph povas esti bonega solvo por ĉi tiu problemo. Elektante ĉi tiun opcion, ni ankaŭ simpligas la plian procezon de migrado inter serviloj, ĉar ne estos bezono movi lokan stokadon de unu hiperviziero al alia. La sola kapto estas, ke vi devos haltigi la VM dum la laboro efektiviĝas.
La sekva recepto estas prenita de , kies instrukcioj estis provitaj en ago. Parenteze, la metodo de senĝena migrado ankaŭ estas priskribita tie, tamen en nia kazo ĝi simple ne estis bezonata, do ni ne kontrolis ĝin. Se ĉi tio estas kritika por via projekto, ni ĝojos aŭdi pri la rezultoj en la komentoj.
Ni transiru al la praktika parto. En la ekzemplo ni uzas virsh kaj, sekve, libvirt. Unue, certigu, ke la Ceph-pool al kiu la datumoj estos migritaj estas konektita al libvirt:
virsh pool-dumpxml $ceph_poolLa priskribo de la naĝejo devas enhavi konektodatenojn al Ceph kun rajtigaj datumoj.
La sekva paŝo estas, ke la LVM-bildo estas konvertita al Ceph RBD. La tempo de ekzekuto dependas ĉefe de la grandeco de la bildo:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_namePost la konvertiĝo, LVM-bildo restos, kio estos utila se migrado de la VM al RBD malsukcesas kaj vi devas refari la ŝanĝojn. Ankaŭ, por povi rapide refari ŝanĝojn, ni faru sekurkopion de la virtuala maŝina agorda dosiero:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... kaj redaktu la originalon (vm_name.xml). Ni trovu blokon kun priskribo de la disko (komencas per la linio <disk type='file' device='disk'> kaj finiĝas per </disk>) kaj redukti ĝin al la sekva formo:
<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>Ni rigardu kelkajn detalojn:
- Al la protokolo
sourcela adreso al la stokado en Ceph RBD estas indikita (ĉi tiu estas la adreso indikanta la nomon de la Ceph-naĝejo kaj la RBD-bildo, kiu estis determinita ĉe la unua etapo). - En la bloko
secrettipo estas indikitaceph, same kiel la UUID de la sekreto por konekti al ĝi. Ĝia uuid troveblas uzante la komandonvirsh secret-list. - En la bloko
hostadresoj al Ceph-monitoroj estas indikitaj.
Post redaktado de la agorda dosiero kaj kompletigi la konvertiĝon de LVM al RBD, vi povas apliki la modifitan agordan dosieron kaj komenci la virtualan maŝinon:
virsh define $vm_name.xml
virsh start $vm_name
Estas tempo kontroli, ke la virtuala maŝino ĝuste ekfunkciis: vi povas ekscii, ekzemple, konektante al ĝi per SSH aŭ per virsh.
Se la virtuala maŝino funkcias ĝuste kaj vi ne trovis aliajn problemojn, tiam vi povas forigi la LVM-bildon, kiu ne plu estas uzata:
lvremove main/$vm_image_namekonkludo
Ni renkontis ĉiujn priskribitajn kazojn en la praktiko - ni esperas, ke la instrukcioj helpos aliajn administrantojn solvi similajn problemojn. Se vi havas komentojn aŭ aliajn similajn rakontojn de via sperto uzante Ceph, ni ĝojos vidi ilin en la komentoj!
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com