Lanpetuta dauden proiektuetan Ceph-ekin lan egiteko aholkuak eta trikimailuak

Ceph sareko biltegiratze gisa erabiliz karga ezberdineko proiektuetan, lehen begiratuan sinpleak edo hutsalak diruditen hainbat zeregin topa ditzakegu. Adibidez:

• Datuen migrazioa Ceph zaharretik berrira aurreko zerbitzarien erabilera partzialarekin kluster berrian;
• Ceph-en disko-espazioaren esleipenaren arazoari irtenbidea.

Horrelako arazoei aurre egiteko, OSDa behar bezala kendu behar dugu datuak galdu gabe, eta hori bereziki garrantzitsua da datu kopuru handiak tratatzerakoan. Artikuluan eztabaidatuko da.

Jarraian deskribatzen diren metodoak garrantzitsuak dira Ceph-en edozein bertsiotarako. Horrez gain, Ceph-ek datu kopuru handia gorde dezakeela kontuan hartuko da: datuak galtzea eta beste arazo batzuk saihesteko, ekintza batzuk beste hainbatetan “banatuko dira”.

OSDari buruzko hitzaurrea

Aztertutako hiru errezetatik bi OSDra dedikatzen direnez (Objektuen biltegiratze deabrua), zati praktikoan murgildu aurretik - laburki zer den Ceph-en eta zergatik den hain garrantzitsua.

Lehenik eta behin, esan beharra dago Ceph kluster osoa OSD askoz osatuta dagoela. Zenbat eta gehiago egon, orduan eta handiagoa izango da Ceph-en doako datu-bolumena. Erraza da hemendik ulertzea OSD funtzio nagusia: Ceph objektuaren datuak kluster-nodo guztien fitxategi-sistemetan gordetzen ditu eta sarerako sarbidea ematen du (irakurtzeko, idazteko eta bestelako eskaerak egiteko).

Maila berean, erreplikazio-parametroak OSD desberdinen artean objektuak kopiatuz ezartzen dira. Eta hemen hainbat arazo topa ditzakezu, eta horien irtenbideak jarraian aztertuko dira.

1. kasua. Kendu segurtasunez OSD Ceph klusterretik datuak galdu gabe

OSDa kentzeko beharra zerbitzaria klustertik kentzeak sor dezake -adibidez, beste zerbitzari batekin ordezkatzea-, horixe gertatu zaigu, artikulu hau idazteari hasiera emanez. Horrela, manipulazioaren azken helburua zerbitzari jakin bateko OSD eta mons guztiak ateratzea da, gelditu ahal izateko.

Erosotasunerako eta komandoak exekutatzen diren bitartean behar den OSDa adieraztean akats bat egiten dugun egoera saihesteko, aldagai bereizi bat ezarriko dugu, zeinaren balioa ezabatu nahi den OSDaren zenbakia izango da. Dei diezaiogun ${ID} — hemen eta behean, aldagai horrek lan egiten ari garen OSDaren zenbakia ordezkatzen du.

Ikus dezagun egoera lanean hasi aurretik:

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

OSD kentzen hasteko, ondo egin beharko duzu reweight gainean zerora. Horrela, OSDko datu kopurua murrizten dugu beste OSD batzuekin orekatuz. Horretarako, exekutatu komando hauek:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... eta horrela zero arte.

Oreka leuna behar dadatuak ez galtzeko. Hau bereziki egia da OSDak datu kopuru handia badu. Komandoak exekutatu ondoren hori ziurtatzeko reweight dena ondo atera zen, osatu dezakezu ceph -s edo terminaleko leiho bereizi batean ceph -w aldaketak denbora errealean behatzeko.

OSDa "hustuta" dagoenean, eragiketa estandarrarekin jarraitu dezakezu hura kentzeko. Horretarako, transferitu nahi duzun OSD egoerara down:

ceph osd down osd.${ID}

"Atera" dezagun OSDa klusterretik:

ceph osd out osd.${ID}

Gelditu dezagun OSD zerbitzua eta desmuntatu dezagun bere partizioa FS-n:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Kendu OSD-tik CRUSH mapa:

ceph osd crush remove osd.${ID}

Ezabatu dezagun OSD erabiltzailea:

ceph auth del osd.${ID}

Eta azkenik, kendu dezagun OSD bera:

ceph osd rm osd.${ID}

Kontuan izan: Ceph Luminous bertsioa edo handiagoa erabiltzen ari bazara, goiko OSD kentzeko urratsak bi komandotara murriztu daitezke:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Goian deskribatutako urratsak bete ondoren, komandoa exekutatzen baduzu ceph osd tree, orduan argi geratu behar da lana egin den zerbitzarian jada ez dagoela aurreko eragiketak egin diren OSDrik:

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

Bidean, kontuan izan Ceph klusterraren egoera joango dela HEALTH_WARN, eta OSD kopurua eta disko erabilgarri dagoen espazioaren murrizketa ere ikusiko dugu.

Jarraian, zerbitzaria guztiz gelditu nahi baduzu eta, horren arabera, Ceph-etik kendu nahi badituzu, beharrezkoak diren urratsak deskribatuko dira. Kasu honetan, garrantzitsua da hori gogoratzea Zerbitzaria itzali aurretik, OSD guztiak kendu behar dituzu zerbitzari honetan.

Zerbitzari honetan OSD gehiago geratzen ez bada, kendu ondoren zerbitzaria OSD mapatik kanpo utzi behar duzu hv-2komando hau exekutatuz:

ceph osd crush rm hv-2

Ezabatu mon zerbitzaritik hv-2beheko komandoa beste zerbitzari batean exekutatuz (hau da, kasu honetan, on hv-1):

ceph-deploy mon destroy hv-2

Horren ondoren, zerbitzaria gelditu eta ondorengo ekintzen has zaitezke (berriro inplementatzea, etab.).

2. kasua. Diskoko espazioaren banaketa dagoeneko sortutako Ceph kluster batean

Bigarren istorioa PGri buruzko hitzaurre batekin hasiko dut (Kokapen Taldeak). Ceph-en PGren eginkizun nagusia Ceph-eko objektuak gehitzea eta OSD-n gehiago errepikatzea da. Beharrezko PG kopurua kalkulatu dezakezun formula dago dagokion atala Ceph dokumentazioa. Gai hau ere hor eztabaidatzen da adibide zehatzekin.

Beraz: Ceph erabiltzean ohiko arazoetako bat Ceph-eko igerilekuen arteko OSD eta PG kopuru desorekatua da.

Lehenik eta behin, horregatik, egoera bat sor daiteke multzo txiki batean PG gehiegi zehazten direnean, hau da, funtsean, klusterreko diskoko espazioaren erabilera irrazionala. Bigarrenik, praktikan arazo larriagoa dago: datuak gainezkatzea OSDetako batean. Horrek klusterrak estatura igarotzea dakar lehenik HEALTH_WARN, eta gero HEALTH_ERR. Horren arrazoia Ceph-ek, eskuragarri dagoen datu-kopurua kalkulatzean (hori esker aurki dezakezu MAX AVAIL komandoaren irteeran ceph df igerileku bakoitzerako bereizita) OSDn eskuragarri dauden datu kopuruan oinarritzen da. Gutxienez OSD batean leku nahikorik ez badago, ezin da datu gehiago idatzi datuak OSD guztien artean behar bezala banatu arte.

Arazo horiek argitzea merezi du neurri handi batean, Ceph kluster konfigurazio fasean erabakitzen dira. Erabili dezakezun tresnetako bat da Ceph PGCalc. Bere laguntzarekin, behar den PG-kopurua argi kalkulatzen da. Hala ere, horretara jo dezakezu Ceph klusterra dagoen egoera batean dagoeneko gaizki konfiguratuta. Hemen argitzea merezi du konponketa lanaren zati gisa ziurrenik PG-kopurua murriztu beharko duzula, eta funtzio hau ez dago Ceph-en bertsio zaharretan (bertsioan bakarrik agertu zen). Nautilus).

Beraz, imajina dezagun irudi hau: klusterrak egoera bat du HEALTH_WARN OSDetako bat espaziorik gabe geratzen delako. Errore baten bidez adieraziko da HEALTH_WARN: 1 near full osd. Jarraian egoera honetatik ateratzeko algoritmo bat dago.

Lehenik eta behin, eskuragarri dauden datuak gainerako OSDen artean banatu behar dituzu. Lehen kasuan ere antzeko eragiketa bat egin genuen, nodoa "xukatu" genuenean - orain apur bat murriztu beharko dugu desberdintasun bakarrarekin. reweight. Adibidez, 0.95 arte:

ceph osd reweight osd.${ID} 0.95

Honek OSD-ko diskoko lekua askatzen du eta ceph osasunaren errorea konpontzen du. Dena den, lehen esan bezala, arazo hau hasierako faseetan Ceph-en konfigurazio okerraren ondorioz gertatzen da nagusiki: oso garrantzitsua da birkonfigurazioa egitea, etorkizunean ager ez dadin.

Gure kasuan, hauxe izan zen guztia:

• balio handiegia replication_count igerilekuetako batean,
• PG gehiegi igerileku batean eta gutxiegi beste batean.

Erabili dezagun lehen aipatutako kalkulagailua. Argi eta garbi erakusten du zer sartu behar den eta, printzipioz, ez dago ezer konplikaturik. Beharrezko parametroak ezarrita, gomendio hauek jasoko ditugu:

Kontuan izan: Ceph cluster bat hutsetik konfiguratzen ari bazara, kalkulagailuaren beste funtzio erabilgarria taulan zehaztutako parametroekin hutsetik sortuko dituzten komandoak sortzea da.

Azken zutabeak nabigatzen laguntzen dizu - Iradokitako PG zenbaketa. Gure kasuan, bigarrena ere baliagarria da, non erreplikazio-parametroa adierazten den, erreplikazioaren biderkatzailea aldatzea erabaki baitugu.

Beraz, lehenik eta behin erreplikazio-parametroak aldatu behar dituzu - hori lehenik eta behin egitea merezi du, biderkatzailea murriztuz diskoko tokia askatuko baitugu. Komandoa exekutatzen den heinean, disko erabilgarri dagoen espazioa handituko dela ohartuko zara:

ceph osd pool $pool_name set $replication_size

Eta amaitu ondoren, parametroen balioak aldatzen ditugu pg_num и pgp_num honela:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Garrantzitsua da: igerileku bakoitzean PG kopurua sekuentzialki aldatu behar dugu eta ez beste igerilekuetako balioak aldatu abisuak desagertu arte "Datuen erredundantzia degradatua" и "n-pg-kopurua degradatuta".

Dena ondo joan dela egiaztatu dezakezu komandoen irteerak erabiliz ceph health detail и ceph -s.

3. kasua. Makina birtual bat LVMtik Ceph RBDra migratzen

Proiektu batek alokatutako metalezko zerbitzarietan instalatutako makina birtualak erabiltzen dituen egoeran, akatsak jasan ditzakeen biltegiratzearen arazoa sortzen da maiz. Era berean, oso desiragarria da biltegiratze horretan leku nahikoa egotea... Beste egoera arrunt bat: zerbitzarian biltegiratze lokala duen makina birtual bat dago eta diskoa zabaldu behar duzu, baina ez dago inora, ez baitago. zerbitzarian disko librea geratzen da.

Arazoa modu ezberdinetan konpondu daiteke, adibidez, beste zerbitzari batera migratuz (baldin badago) edo zerbitzarian disko berriak gehituz. Baina ez da beti posible hori egitea, beraz, LVMtik Ceph-era migratzea arazo honen konponbide bikaina izan daiteke. Aukera hau aukeratuz gero, zerbitzarien arteko migrazio-prozesu gehiago errazten dugu, ez baita tokiko biltegiratzerik hipervisor batetik bestera eraman beharrik izango. Harrapaketa bakarra da VM gelditu beharko duzula lana egiten ari den bitartean.

Hurrengo errezetatik hartua da blog honetako artikulua, zeinen argibideak jardunean probatu diren. Bide batez, trabarik gabeko migrazio metodoa ere deskribatzen da bertan, ordea, gure kasuan besterik gabe ez zen beharrezkoa, beraz, ez genuen egiaztatu. Zure proiekturako garrantzitsua bada, poz-pozik egongo gara emaitzen berri iruzkinetan.

Goazen zati praktikora. Adibidean virsh eta, horren arabera, libvirt erabiltzen ditugu. Lehenik eta behin, ziurtatu datuak migratuko diren Ceph igerilekua libvirt-era konektatuta dagoela:

virsh pool-dumpxml $ceph_pool

Igerilekuaren deskribapenak Ceph-erako konexio-datuak izan behar ditu baimen-datuekin.

Hurrengo urratsa LVM irudia Ceph RBD bihurtzea da. Exekuzio denbora irudiaren tamainaren araberakoa da batez ere:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Bihurtu ondoren, LVM irudi bat geratuko da, eta hori erabilgarria izango da VM-ra RBDra migratzeak huts egiten badu eta aldaketak atzera egin behar badituzu. Gainera, aldaketak azkar atzera egin ahal izateko, egin dezagun makina birtualeko konfigurazio fitxategiaren babeskopia:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... eta editatu jatorrizkoa (vm_name.xml). Bila dezagun bloke bat diskoaren deskribapena duen (lerroarekin hasten da <disk type='file' device='disk'> eta honekin bukatzen da </disk>) eta laburtu forma honetara:

<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>

Ikus ditzagun xehetasun batzuk:

1. Protokoloari source Ceph RBD-n biltegiratzeko helbidea adierazten da (lehen fasean zehaztu zen Ceph igerilekuaren izena eta RBD irudia adierazten duen helbidea da).
2. Blokean secret mota adierazten da ceph, baita bertara konektatzeko sekretuaren UUID-a ere. Bere uuid komandoa erabiliz aurki daiteke virsh secret-list.
3. Blokean host Ceph monitoreen helbideak adierazten dira.

Konfigurazio fitxategia editatu eta LVM-ra RBD bihurketa amaitu ondoren, aldatutako konfigurazio-fitxategia aplikatu eta makina birtuala abiarazi dezakezu:

virsh define $vm_name.xml
virsh start $vm_name

Makina birtuala ondo hasi zela egiaztatzeko garaia da: jakin dezakezu, adibidez, SSH bidez edo konektatuz. virsh.

Makina birtuala ondo funtzionatzen ari bada eta ez baduzu beste arazorik aurkitu, orduan jada erabiltzen ez den LVM irudia ezabatu dezakezu:

lvremove main/$vm_image_name

Ondorioa

Praktikan deskribatutako kasu guztiak topatu ditugu - argibideek beste administratzaile batzuek antzeko arazoak konpontzen laguntzea espero dugu. Ceph erabiliz egindako esperientziatik iruzkinak edo antzeko beste istorio batzuk badituzu, pozik ikusiko ditugu iruzkinetan!

PS

Irakurri ere gure blogean:

• «Gure eskuak ez dira aspertzeko: K8s-en Rook multzoa berreskuratzea»;
• «Rook edo ez Rook - hori da galdera»;
• «Rook - Kubernetesentzako "autozerbitzua" datu biltegia»;
• «Biltegiratze iraunkorra sortzea Ceph-en oinarrituta Kubernetesen hornidurarekin'.

Iturria: www.habr.com