Mei it brûken fan Ceph as netwurk opslach yn projekten mei ferskate loads, kinne wy tsjinkomme ferskate taken dy't op it earste each net lykje simpel of triviaal. Bygelyks:
- migraasje fan gegevens fan âlde Ceph nei nije mei in part gebrûk fan eardere tsjinners yn it nije kluster;
- oplossing foar it probleem fan tawizing fan skiifromte yn Ceph.
Omgean mei sokke problemen, wy wurde konfrontearre mei de needsaak om de OSD korrekt te ferwiderjen sûnder gegevens te ferliezen, wat foaral wichtich is by it omgean mei grutte hoemannichten gegevens. Dit sil wurde besprutsen yn it artikel.
De hjirûnder beskreaune metoaden binne relevant foar elke ferzje fan Ceph. Dêrnjonken wurdt rekken holden mei it feit dat Ceph in grutte hoemannichte gegevens opslaan kin: om gegevensferlies en oare problemen te foarkommen, wurde guon aksjes "splitst" yn ferskate oaren.
Foarwurd oer OSD
Sûnt twa fan 'e trije besprutsen resepten binne wijd oan OSD (), foardat jo yn it praktyske diel dûke - koart oer wat it is yn Ceph en wêrom it sa wichtich is.
Alderearst moat it sein wurde dat it hiele Ceph-kluster bestiet út in protte OSD's. Hoe mear der binne, hoe grutter it frije gegevensvolume yn Ceph. It is hjir maklik te begripen wichtichste OSD funksje: It bewarret Ceph-objektgegevens op 'e bestânsystemen fan alle klusterknooppunten en jout tagong ta it netwurk (foar lêzen, skriuwen en oare oanfragen).
Op itselde nivo wurde replikaasjeparameters ynsteld troch objekten te kopiearjen tusken ferskate OSD's. En hjir kinne jo ferskate problemen tsjinkomme, de oplossingen dy't hjirûnder sille wurde besprutsen.
Saak nr. 1. Ferwiderje OSD feilich út Ceph-kluster sûnder gegevens te ferliezen
De needsaak om de OSD te ferwiderjen kin feroarsake wurde troch it fuortsmiten fan de tsjinner út it kluster - bygelyks om it te ferfangen troch in oare tsjinner - wat is wat ús bard is, wêrtroch it skriuwen fan dit artikel is. Sa is it ultime doel fan manipulaasje om alle OSD's en mons op in opjûne tsjinner út te heljen, sadat it stoppe wurde kin.
Foar gemak en om in situaasje te foarkommen wêrby't wy, by it útfieren fan kommando's, in flater meitsje by it oanjaan fan de fereaske OSD, sille wy in aparte fariabele ynstelle, wêrfan de wearde it nûmer is fan 'e OSD dy't wiske wurde sil. Litte wy har skilje ${ID} - hjir en hjirûnder ferfangt sa'n fariabele it nûmer fan 'e OSD wêrmei't wy wurkje.
Litte wy nei de betingst sjen foardat jo wurkje:
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-ferwidering te begjinnen, moatte jo soepel útfiere reweight op it op nul. Op dizze manier ferminderje wy de hoemannichte gegevens yn 'e OSD troch it te balansearjen mei oare OSD's. Om dit te dwaan, útfiere de folgjende kommando's:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... en sa fierder oant nul.
Smooth balâns nedichom gjin gegevens te ferliezen. Dit is benammen wier as de OSD in grutte hoemannichte gegevens befettet. Om derfoar te soargjen dat nei it útfieren fan de kommando's reweight alles gie goed, jo kinne it foltôgje ceph -s of yn in apart terminalfinster run ceph -w om feroaringen yn echte tiid te observearjen.
As de OSD "leech" is, kinne jo trochgean mei de standert operaasje om it te ferwiderjen. Om dit te dwaan, oerdrage de winske OSD nei de steat down:
ceph osd down osd.${ID}Litte wy de OSD út it kluster "lûke":
ceph osd out osd.${ID}Litte wy de OSD-tsjinst stopje en syn partition yn 'e FS ûntkoppele:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Ferwiderje OSD út :
ceph osd crush remove osd.${ID}Litte wy de OSD-brûker wiskje:
ceph auth del osd.${ID}En as lêste, litte wy de OSD sels fuortsmite:
ceph osd rm osd.${ID}remark: As jo Ceph Luminous ferzje of heger brûke, dan kinne de boppesteande OSD-ferwideringsstappen wurde fermindere nei twa kommando's:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
As jo, nei it foltôgjen fan de hjirboppe beskreaune stappen, it kommando útfiere ceph osd tree, dan moat it dúdlik wêze dat op 'e tsjinner wêr't it wurk útfierd is gjin OSD's mear binne wêrfoar de boppesteande operaasjes binne útfierd:
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
Oan 'e wei, tink derom dat de steat fan' e Ceph-kluster nei sil gean HEALTH_WARN, en wy sille ek in fermindering fan it oantal OSD's en it bedrach fan beskikbere skiifromte sjen.
It folgjende sil de stappen beskriuwe dy't nedich binne as jo de tsjinner folslein wolle stopje en it sadwaande fuortsmite fan Ceph. Yn dit gefal is it wichtich om te ûnthâlden dat Foardat jo de tsjinner ôfslute, moatte jo alle OSD's fuortsmite op dizze tsjinner.
As d'r gjin OSD's mear binne op dizze tsjinner, dan moatte jo nei it fuortheljen de tsjinner útslute fan 'e OSD-kaart hv-2troch it folgjende kommando út te fieren:
ceph osd crush rm hv-2
Wiskje mon fan de tsjinner hv-2troch it kommando hjirûnder út te fieren op in oare server (dus yn dit gefal, op hv-1):
ceph-deploy mon destroy hv-2Hjirnei kinne jo de tsjinner stopje en folgjende aksjes begjinne (it opnij ynsette, ensfh.).
Saak nr. 2. Ferdieling fan skiifromte yn in al oanmakke Ceph-kluster
Ik sil it twadde ferhaal begjinne mei in foarwurd oer PG (). De haadrol fan PG yn Ceph is foaral om Ceph-objekten te aggregearjen en se fierder te replikearjen yn OSD. De formule wêrmei jo it fereaske bedrach fan PG kinne berekkenje is yn Ceph dokumintaasje. Dizze kwestje wurdt dêr ek besprutsen mei spesifike foarbylden.
Dus: ien fan 'e mienskiplike problemen by it brûken fan Ceph is it unbalansearre oantal OSD en PG tusken swimbaden yn Ceph.
As earste, hjirtroch kin in situaasje ûntstean as tefolle PG's wurde oantsjutte yn in lyts swimbad, wat yn wêzen in irrasjoneel gebrûk fan skiifromte yn it kluster is. Twadder is d'r yn 'e praktyk in serieuzer probleem: gegevensoerstreaming yn ien fan' e OSD's. Dit hâldt yn dat it kluster earst oergiet nei de steat HEALTH_WARN, en doe HEALTH_ERR. De reden hjirfoar is dat Ceph, by it berekkenjen fan de beskikbere hoemannichte gegevens (jo kinne it fine troch MAX AVAIL yn it kommando útfier ceph df foar elke pool apart) is basearre op it bedrach fan beskikbere gegevens yn 'e OSD. As d'r net genôch romte is yn op syn minst ien OSD, kinne gjin gegevens mear skreaun wurde oant de gegevens goed ferdield binne ûnder alle OSD's.
It is de muoite wurdich om te ferdúdlikjen dat dizze problemen wurde foar it grutste part besletten yn 'e Ceph-klusterkonfiguraasjestadium. Ien fan 'e ark dy't jo kinne brûke is . Mei har help wurdt it fereaske bedrach fan PG dúdlik berekkene. Jo kinne lykwols ek taflecht ta it yn in situaasje dêr't de Ceph kluster al ferkeard ynsteld. It is hjir de muoite wurdich om te ferdúdlikjen dat jo as ûnderdiel fan it reparaasjewurk nei alle gedachten it oantal PG's moatte ferminderje, en dizze funksje is net beskikber yn âldere ferzjes fan Ceph (it ferskynde allinich yn ferzje ).
Dat, lit ús it folgjende byld foarstelle: it kluster hat in status HEALTH_WARN fanwege ien fan de OSD rint út romte. Dit sil oanjûn wurde troch in flater HEALTH_WARN: 1 near full osd. Hjirûnder is in algoritme om út dizze situaasje te kommen.
Earst moatte jo de beskikbere gegevens fersprieden tusken de oerbleaune OSD's. Wy hawwe al in ferlykbere operaasje útfierd yn it earste gefal, doe't wy de knoop "drained" - mei it ienige ferskil dat wy no wat moatte ferminderje reweight. Bygelyks, oant 0.95:
ceph osd reweight osd.${ID} 0.95Dit makket skiifromte frij yn 'e OSD en reparearret de flater yn ceph sûnens. Lykwols, sa't al neamd, dit probleem komt benammen troch ferkearde konfiguraasje fan Ceph yn de earste fazen: it is hiel wichtich om te meitsje in rekonfiguraasje, sadat it net ferskynt yn 'e takomst.
Yn ús bysûndere gefal kaam it allegear del op:
- wearde te heech
replication_countyn ien fan de swimbaden, - tefolle PG yn ien pool en te min yn in oar.
Litte wy de al neamde rekkenmasine brûke. It lit dúdlik sjen wat der ynfierd wurde moat en yn prinsipe is der neat yngewikkeld. Nei it ynstellen fan de nedige parameters, krije wy de folgjende oanbefellings:
remark: As jo in Ceph-kluster fanôf it begjin opstelle, is in oare nuttige funksje fan 'e rekkenmasine it generearjen fan kommando's dy't puollen fanôf it begjin meitsje mei de parameters oantsjutte yn' e tabel.
De lêste kolom helpt jo navigearje - Suggested PG Count. Yn ús gefal is de twadde ek nuttich, wêr't de replikaasjeparameter oanjûn is, om't wy besletten hawwe om de replikaasjemultiplikator te feroarjen.
Dat, earst moatte jo de replikaasjeparameters feroarje - dit is earst de muoite wurdich te dwaan, om't wy troch de multiplier te ferminderjen, skiifromte frijmeitsje. As it kommando útfiert, sille jo merke dat de beskikbere skiifromte sil tanimme:
ceph osd pool $pool_name set $replication_size
En nei syn foltôging feroarje wy de parameterwearden pg_num и pgp_num as folget:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberwichtich: wy moatte it oantal PG's sequentieel feroarje yn elke pool en de wearden yn oare pools net feroarje oant de warskôgingen ferdwine "Degradearre gegevensredundânsje" и "n-oantal pgs degradearre".
Jo kinne ek kontrolearje dat alles goed gie mei de kommando-útgongen ceph health detail и ceph -s.
Saak nr. 3. Migrearjen fan in firtuele masine fan LVM nei Ceph RBD
Yn in situaasje wêryn in projekt firtuele masines brûkt ynstalleare op ferhierde bleatemetaalservers, ûntstiet it probleem fan flater-tolerante opslach faak. It is ek tige winsklik dat der genôch romte is yn dizze opslach ... In oare mienskiplike situaasje: d'r is in firtuele masine mei lokale opslach op 'e tsjinner en jo moatte de skiif útwreidzje, mar d'r is gjin plak om te gean, om't der gjin frije skiifromte oerbleaun op de tsjinner.
It probleem kin op ferskate manieren oplost wurde - bygelyks troch te migrearjen nei in oare tsjinner (as d'r ien is) of nije skiven ta te foegjen oan de tsjinner. Mar it is net altyd mooglik om dit te dwaan, dus migrearje fan LVM nei Ceph kin in poerbêste oplossing wêze foar dit probleem. Troch dizze opsje te kiezen, ferienfâldigje wy ek it fierdere proses fan migraasje tusken servers, om't d'r gjin need is om lokale opslach fan de iene hypervisor nei de oare te ferpleatsen. De ienige fangen is dat jo de VM moatte stopje wylst it wurk wurdt útfierd.
It folgjende resept is nommen út , wêrfan de ynstruksjes binne testen yn aksje. Trouwens, dêr wurdt ek de metoade fan probleemfrije migraasje beskreaun, lykwols, yn ús gefal wie it gewoan net nedich, dus wy hawwe it net kontrolearre. As dit kritysk is foar jo projekt, sille wy bliid wêze om te hearren oer de resultaten yn 'e kommentaren.
Litte wy nei it praktyske diel gean. Yn it foarbyld brûke wy virsh en, dus, libvirt. Soargje derfoar dat de Ceph-pool wêryn de gegevens sille wurde migrearre is ferbûn mei libvirt:
virsh pool-dumpxml $ceph_poolDe beskriuwing fan it swimbad moat ferbiningsgegevens nei Ceph befetsje mei autorisaasjegegevens.
De folgjende stap is dat de LVM-ôfbylding wurdt omboud ta Ceph RBD. De útfieringstiid hinget foaral ôf fan 'e grutte fan 'e ôfbylding:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameNei de konverzje sil in LVM-ôfbylding bliuwe, wat nuttich sil wêze as it migrearjen fan de VM nei RBD mislearret en jo moatte de wizigingen weromdraaie. Om wizigingen fluch werom te kinnen, litte wy ek in reservekopy meitsje fan it konfiguraasjetriem fan 'e firtuele masine:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... en bewurkje it orizjineel (vm_name.xml). Litte wy in blok fine mei in beskriuwing fan 'e skiif (begjint mei de line <disk type='file' device='disk'> en einiget mei </disk>) en ferminderje it nei de folgjende foarm:
<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>Litte wy nei guon details sjen:
- Nei it protokol
sourceit adres oan 'e opslach yn Ceph RBD wurdt oanjûn (dit is it adres dat de namme fan' e Ceph-pool en it RBD-ôfbylding oanjout, dat waard bepaald yn 'e earste etappe). - Yn it blok
secrettype wurdt oanjûnceph, lykas de UUID fan it geheim om dêrmei te ferbinen. De uuid kin fûn wurde mei it kommandovirsh secret-list. - Yn it blok
hostadressen oan Ceph monitors wurde oanjûn.
Nei it bewurkjen fan it konfiguraasjetriem en it foltôgjen fan de LVM nei RBD-konverzje, kinne jo it wizige konfiguraasjetriem tapasse en de firtuele masine begjinne:
virsh define $vm_name.xml
virsh start $vm_name
It is tiid om te kontrolearjen dat de firtuele masine goed begon: jo kinne útfine, bygelyks troch te ferbinen mei har fia SSH of fia virsh.
As de firtuele masine goed wurket en jo hawwe gjin oare problemen fûn, dan kinne jo de LVM-ôfbylding wiskje dy't net mear wurdt brûkt:
lvremove main/$vm_image_namekonklúzje
Wy hawwe alle beskreaune gefallen yn 'e praktyk tsjinkaam - wy hoopje dat de ynstruksjes oare behearders sille helpe om ferlykbere problemen op te lossen. As jo opmerkingen of oare ferlykbere ferhalen hawwe fan jo ûnderfining mei it brûken fan Ceph, sille wy se bliid wêze om se yn 'e opmerkingen te sjen!
PS
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com