ProHoster > Dienoraštis > Administravimas > Patarimai ir gudrybės dirbant su Ceph įtemptuose projektuose

Patarimai ir gudrybės dirbant su Ceph įtemptuose projektuose

Patarimai ir gudrybės dirbant su Ceph įtemptuose projektuose

Naudojant Ceph kaip tinklo saugyklą projektuose su skirtingomis apkrovomis, galime susidurti su įvairiomis užduotimis, kurios iš pirmo žvilgsnio neatrodo paprastos ar nereikšmingos. Pavyzdžiui:

  • duomenų perkėlimas iš senojo Ceph į naują, iš dalies naudojant ankstesnius serverius naujame klasteryje;
  • disko vietos paskirstymo problemos sprendimas Ceph.

Spręsdami tokias problemas, susiduriame su būtinybe teisingai pašalinti OSD neprarandant duomenų, o tai ypač svarbu dirbant su dideliais duomenų kiekiais. Tai bus aptarta straipsnyje.

Toliau aprašyti metodai tinka bet kuriai Ceph versijai. Be to, bus atsižvelgta į tai, kad Ceph gali saugoti didelį duomenų kiekį: siekiant išvengti duomenų praradimo ir kitų problemų, kai kurie veiksmai bus „padalyti“ į keletą kitų.

Pratarmė apie OSD

Kadangi du iš trijų aptartų receptų yra skirti OSD (Objektų saugojimo demonas), prieš pasineriant į praktinę dalį – trumpai apie tai, kas tai yra Kefe ir kodėl tai taip svarbu.

Visų pirma, reikia pasakyti, kad visas Ceph klasteris susideda iš daugybės OSD. Kuo jų daugiau, tuo didesnis nemokamų duomenų kiekis Ceph. Iš čia lengva suprasti pagrindinė OSD funkcija: ji saugo Ceph objekto duomenis visų klasterio mazgų failų sistemose ir suteikia prieigą prie jų tinklo (skaitymui, rašymui ir kitoms užklausoms).

Tuo pačiu lygiu replikacijos parametrai nustatomi kopijuojant objektus tarp skirtingų OSD. Ir čia galite susidurti su įvairiomis problemomis, kurių sprendimai bus aptarti toliau.

Byla Nr.1. Saugiai pašalinkite OSD iš Ceph klasterio neprarasdami duomenų

Poreikis pašalinti OSD gali kilti pašalinus serverį iš klasterio – pavyzdžiui, norint jį pakeisti kitu serveriu – taip ir nutiko mums, todėl buvo parašytas šis straipsnis. Taigi galutinis manipuliavimo tikslas yra išgauti visus OSD ir mons tam tikrame serveryje, kad jį būtų galima sustabdyti.

Kad būtų patogiau ir išvengtume situacijos, kai vykdydami komandas suklystume nurodydami reikiamą OSD, nustatysime atskirą kintamąjį, kurio reikšmė bus ištrinamo OSD numeris. Paskambinkime jai ${ID} — čia ir toliau toks kintamasis pakeičia OSD, su kuriuo dirbame, numerį.

Pažvelkime į būklę prieš pradedant darbą:

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

Norėdami pradėti OSD pašalinimą, turėsite atlikti sklandžiai reweight ant jo iki nulio. Tokiu būdu sumažiname duomenų kiekį OSD, subalansuodami juos su kitais OSD. Norėdami tai padaryti, paleiskite šias komandas:

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

... ir taip iki nulio.

Reikalingas sklandus balansavimaskad neprarastumėte duomenų. Tai ypač aktualu, jei OSD yra daug duomenų. Kad įsitikintumėte, jog įvykdžius komandas reweight viskas pavyko gerai, galite užbaigti ceph -s arba atskirame terminalo lange ceph -w kad būtų galima stebėti pokyčius realiu laiku.

Kai OSD yra „ištuštintas“, galite tęsti standartinę operaciją, kad jį pašalintumėte. Norėdami tai padaryti, perkelkite norimą OSD į būseną down:

ceph osd down osd.${ID}

„Ištraukime“ OSD iš klasterio:

ceph osd out osd.${ID}

Sustabdykime OSD paslaugą ir atjunkite jos skaidinį FS:

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

Pašalinkite OSD iš CRUSH žemėlapis:

ceph osd crush remove osd.${ID}

Ištrinkime OSD vartotoją:

ceph auth del osd.${ID}

Ir galiausiai pašalinkime patį OSD:

ceph osd rm osd.${ID}

Atkreipti dėmesį: Jei naudojate Ceph Luminous ar naujesnę versiją, aukščiau nurodytus OSD pašalinimo veiksmus galima sumažinti iki dviejų komandų:

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

Jei atlikę aukščiau aprašytus veiksmus paleidžiate komandą ceph osd tree, tada turėtų būti aišku, kad serveryje, kuriame buvo atliktas darbas, nebėra OSD, kuriems buvo atliktos aukščiau nurodytos operacijos:

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

Pakeliui atkreipkite dėmesį, kad Ceph klasterio būsena pereis į HEALTH_WARN, taip pat sumažės OSD skaičius ir laisvos vietos diske kiekis.

Toliau bus aprašyti veiksmai, kurių reikės, jei norite visiškai sustabdyti serverį ir atitinkamai pašalinti jį iš Ceph. Šiuo atveju svarbu tai atsiminti Prieš išjungdami serverį, turite pašalinti visus OSD šiame serveryje.

Jei šiame serveryje nebeliko OSD, tada juos pašalinę turite pašalinti serverį iš OSD žemėlapio hv-2paleisdami šią komandą:

ceph osd crush rm hv-2

Ištrinti mon iš serverio hv-2paleisdami toliau pateiktą komandą kitame serveryje (t. y. šiuo atveju įjungta hv-1):

ceph-deploy mon destroy hv-2

Po to galite sustabdyti serverį ir pradėti tolesnius veiksmus (iš naujo įdiegti ir pan.).

Byla Nr.2. Vietos diske paskirstymas jau sukurtame Ceph klasteryje

Antrą istoriją pradėsiu pratarme apie PG (Įdėjimo grupės). Pagrindinis PG vaidmuo Ceph visų pirma yra agreguoti Ceph objektus ir toliau juos atkartoti OSD. Formulė, pagal kurią galite apskaičiuoti reikiamą PG kiekį, yra atitinkamą skyrių Ceph dokumentacija. Ten taip pat aptariamas šis klausimas su konkrečiais pavyzdžiais.

Taigi: viena iš dažniausiai pasitaikančių problemų naudojant Ceph yra nesubalansuotas OSD ir PG skaičius tarp Ceph telkinių.

Pirma, dėl to gali susidaryti situacija, kai mažame telkinyje nurodoma per daug PG, o tai iš esmės yra neracionalus klasterio disko vietos panaudojimas. Antra, praktiškai yra rimtesnė problema: duomenų perpildymas viename iš OSD. Tai reiškia, kad klasteris pirmiausia pereina į būseną HEALTH_WARN, ir tada HEALTH_ERR. To priežastis yra ta, kad Ceph, skaičiuodamas turimą duomenų kiekį (ją galite sužinoti pagal MAX AVAIL komandos išvestyje ceph df kiekvienam telkiniui atskirai) yra pagrįstas turimų duomenų kiekiu OSD. Jei bent viename OSD neužtenka vietos, daugiau duomenų negalima įrašyti, kol duomenys nebus tinkamai paskirstyti visuose OSD.

Verta paaiškinti, kad šios problemos daugiausia nusprendžiama Ceph klasterio konfigūravimo etape. Vienas iš įrankių, kurį galite naudoti, yra Ceph PGCalc. Su jo pagalba aiškiai apskaičiuojamas reikalingas PG kiekis. Tačiau taip pat galite pasinaudoti tuo atveju, kai Ceph klasteris jau sukonfigūruotas neteisingai. Čia verta paaiškinti, kad atliekant taisymo darbus greičiausiai reikės sumažinti PG skaičių, o ši funkcija nepasiekiama senesnėse Ceph versijose (ji pasirodė tik versijoje "Nautilus").

Taigi, įsivaizduokime tokį vaizdą: klasteris turi būseną HEALTH_WARN dėl to, kad viename iš OSD pritrūksta vietos. Tai parodys klaida HEALTH_WARN: 1 near full osd. Žemiau pateikiamas algoritmas, kaip išeiti iš šios situacijos.

Pirmiausia turite paskirstyti turimus duomenis tarp likusių OSD. Panašią operaciją jau atlikome pirmuoju atveju, kai „išsausinome“ mazgą - vienintelis skirtumas, kad dabar reikės šiek tiek sumažinti reweight. Pavyzdžiui, iki 0.95:

ceph osd reweight osd.${ID} 0.95

Tai atlaisvina vietos diske OSD ir ištaiso ceph sveikatos klaidą. Tačiau, kaip jau minėta, ši problema dažniausiai kyla dėl neteisingos Ceph konfigūracijos pradiniuose etapuose: labai svarbu atlikti konfigūraciją iš naujo, kad ji nepasirodytų ateityje.

Mūsų konkrečiu atveju viskas baigėsi taip:

  • vertė per didelė replication_count viename iš baseinų,
  • per daug PG viename baseine ir per mažai kitame.

Pasinaudokime jau minėtu skaičiuotuvu. Tai aiškiai parodo, ką reikia įvesti, ir iš esmės nėra nieko sudėtingo. Nustačius reikiamus parametrus, gauname šias rekomendacijas:

Atkreipti dėmesį: Jei Ceph klasterį nustatote nuo nulio, kita naudinga skaičiuotuvo funkcija yra komandų generavimas, kurios sukurs telkinius nuo nulio su lentelėje nurodytais parametrais.

Paskutinis stulpelis padeda naršyti – Siūlomas PG skaičius. Mūsų atveju naudingas ir antrasis, kuriame nurodomas replikacijos parametras, kadangi nusprendėme pakeisti replikacijos daugiklį.

Taigi, pirmiausia turite pakeisti replikacijos parametrus - tai pirmiausia verta padaryti, nes sumažinę daugiklį, atlaisvinsime vietos diske. Vykdydami komandą pastebėsite, kad laisvos vietos diske padidės:

ceph osd pool $pool_name set $replication_size

O jį užbaigę keičiame parametrų reikšmes pg_num и pgp_num taip:

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

Svarbu,: turime nuosekliai keisti PG skaičių kiekviename telkinyje ir nekeisti reikšmių kituose telkiniuose, kol įspėjimai išnyks „Sumažėjęs duomenų perteklius“ и "n-sugadintų puslapių skaičius".

Taip pat galite patikrinti, ar viskas buvo gerai, naudodami komandų išvestis ceph health detail и ceph -s.

Byla Nr.3. Virtualios mašinos perkėlimas iš LVM į Ceph RBD

Esant situacijai, kai projekte naudojamos virtualios mašinos, įdiegtos išnuomotuose pliko metalo serveriuose, dažnai iškyla gedimams atsparios saugyklos problema. Taip pat labai norisi, kad šioje saugykloje būtų pakankamai vietos... Dar viena dažna situacija: serveryje yra virtuali mašina su vietine saugykla ir reikia plėsti diską, bet nėra kur dėtis, nes nėra laisvos vietos diske serveryje.

Problema gali būti išspręsta įvairiais būdais – pavyzdžiui, migruojant į kitą serverį (jei toks yra) arba į serverį įdedant naujų diskų. Tačiau tai ne visada įmanoma padaryti, todėl perėjimas iš LVM į Ceph gali būti puikus šios problemos sprendimas. Pasirinkę šią parinktį taip pat supaprastiname tolesnį migracijos tarp serverių procesą, nes nereikės perkelti vietinės saugyklos iš vieno hipervizoriaus į kitą. Vienintelis dalykas yra tas, kad atlikdami darbus turėsite sustabdyti VM.

Šis receptas paimtas iš straipsnis iš šio tinklaraščio, kurios instrukcijos buvo išbandytos veikiant. Beje, ten aprašytas ir be rūpesčių migracijos būdas, tačiau mūsų atveju to tiesiog neprireikė, todėl netikrinome. Jei tai labai svarbu jūsų projektui, mes mielai išgirsime apie rezultatus komentaruose.

Pereikime prie praktinės dalies. Pavyzdyje naudojame virsh ir atitinkamai libvirt. Pirmiausia įsitikinkite, kad Ceph telkinys, į kurį bus perkelti duomenys, yra prijungtas prie libvirt:

virsh pool-dumpxml $ceph_pool

Baseino apraše turi būti prisijungimo prie „Ceph“ duomenys su įgaliojimo duomenimis.

Kitas žingsnis – LVM vaizdas konvertuojamas į Ceph RBD. Vykdymo laikas visų pirma priklauso nuo vaizdo dydžio:

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

Po konvertavimo išliks LVM vaizdas, kuris bus naudingas, jei nepavyks perkelti VM į UBR ir turėsite atšaukti pakeitimus. Be to, kad galėtume greitai atšaukti pakeitimus, sukurkime virtualios mašinos konfigūracijos failo atsarginę kopiją:

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

... ir redaguoti originalą (vm_name.xml). Raskime bloką su disko aprašymu (prasideda nuo eilutės <disk type='file' device='disk'> ir baigiasi </disk>) ir sumažinkite iki tokios formos:

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

Pažvelkime į kai kurias detales:

  1. Prie protokolo source nurodomas saugyklos Ceph UBR adresas (tai adresas, nurodantis Ceph telkinio pavadinimą ir UBR vaizdą, kuris buvo nustatytas pirmajame etape).
  2. Bloke secret tipas nurodytas ceph, taip pat paslapties UUID, kad galėtumėte prie jo prisijungti. Jo uuid galima rasti naudojant komandą virsh secret-list.
  3. Bloke host nurodyti Ceph monitorių adresai.

Redaguodami konfigūracijos failą ir baigę LVM konvertavimą į RBD, galite pritaikyti pakeistą konfigūracijos failą ir paleisti virtualią mašiną:

virsh define $vm_name.xml
virsh start $vm_name

Pats metas patikrinti, ar virtualioji mašina startavo teisingai: tai galite sužinoti, pavyzdžiui, prisijungę prie jos per SSH arba per virsh.

Jei virtualioji mašina veikia tinkamai ir neradote jokių kitų problemų, galite ištrinti LVM vaizdą, kuris nebenaudojamas:

lvremove main/$vm_image_name

išvada

Su visais aprašytais atvejais susidūrėme praktikoje – tikimės, kad instrukcijos padės kitiems administratoriams išspręsti panašias problemas. Jei turite komentarų ar kitų panašių istorijų iš savo patirties naudojant Ceph, mes mielai juos pamatysime komentaruose!

PS

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com

Добавить комментарий