Nasveti in zvijače za delo s Cephom pri napornih projektih

Če uporabljamo Ceph kot omrežni pomnilnik v projektih z različnimi obremenitvami, se lahko srečamo z različnimi nalogami, ki se na prvi pogled ne zdijo preproste ali trivialne. Na primer:

• selitev podatkov iz starega Cepha v novega z delno uporabo prejšnjih strežnikov v novi gruči;
• rešitev problema dodeljevanja prostora na disku v Ceph.

Pri tovrstnih težavah se soočimo s potrebo po pravilni odstranitvi OSD brez izgube podatkov, kar je še posebej pomembno pri delu z velikimi količinami podatkov. O tem bomo razpravljali v članku.

Spodaj opisane metode so pomembne za katero koli različico Ceph. Poleg tega bo upoštevano dejstvo, da lahko Ceph shrani veliko količino podatkov: da bi preprečili izgubo podatkov in druge težave, bodo nekatera dejanja "razdeljena" na več drugih.

Predgovor o OSD

Ker sta dva od treh obravnavanih receptov namenjena OSD (Demon za shranjevanje predmetov), preden se potopite v praktični del - na kratko o tem, kaj je v Cephu in zakaj je tako pomembno.

Najprej je treba povedati, da je celotna gruča Ceph sestavljena iz številnih OSD-jev. Več kot jih je, večja je brezplačna količina podatkov v Cephu. Od tukaj je enostavno razumeti glavna funkcija OSD: Shranjuje podatke o predmetu Ceph v datotečnih sistemih vseh vozlišč gruče in omogoča omrežni dostop do njih (za branje, pisanje in druge zahteve).

Na isti ravni se parametri replikacije nastavijo s kopiranjem objektov med različnimi OSD-ji. In tukaj lahko naletite na različne težave, o katerih rešitvah bomo razpravljali spodaj.

Primer št. 1. Varno odstranite OSD iz gruče Ceph brez izgube podatkov

Potrebo po odstranitvi OSD-ja lahko povzroči odstranitev strežnika iz gruče – na primer, da bi ga zamenjali z drugim strežnikom – kar se nam je zgodilo, zaradi česar smo napisali ta članek. Tako je končni cilj manipulacije ekstrahirati vse OSD-je in mons na danem strežniku, tako da ga je mogoče ustaviti.

Za udobje in v izogib situaciji, ko se med izvajanjem ukazov zmotimo pri navedbi zahtevanega OSD-ja, bomo nastavili ločeno spremenljivko, katere vrednost bo številka OSD-ja, ki ga želimo izbrisati. Pokličimo jo ${ID} — tukaj in spodaj taka spremenljivka nadomesti številko OSD, s katerim delamo.

Poglejmo stanje pred začetkom dela:

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

Če želite sprožiti odstranitev OSD, boste morali gladko izvesti reweight na to v nulo. Na ta način zmanjšamo količino podatkov v OSD-ju, tako da ga uravnotežimo z drugimi OSD-ji. Če želite to narediti, zaženite naslednje ukaze:

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

... in tako naprej do nule.

Potrebno je gladko uravnoteženjeda ne izgubite podatkov. To še posebej velja, če OSD vsebuje veliko količino podatkov. Da se prepričate, da po izvedbi ukazov reweight vse je šlo dobro, lahko ga dokončate ceph -s ali v ločenem terminalskem oknu ceph -w za opazovanje sprememb v realnem času.

Ko je OSD "izpraznjen", lahko nadaljujete s standardno operacijo, da ga odstranite. Če želite to narediti, prenesite želeni OSD v stanje down:

ceph osd down osd.${ID}

OSD "izvlečemo" iz gruče:

ceph osd out osd.${ID}

Ustavimo storitev OSD in odklopimo njeno particijo v FS:

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

Odstranite OSD iz Zemljevid CRUSH:

ceph osd crush remove osd.${ID}

Izbrišimo uporabnika OSD:

ceph auth del osd.${ID}

In končno, odstranimo sam OSD:

ceph osd rm osd.${ID}

Obvestilo: Če uporabljate različico Ceph Luminous ali novejšo, lahko zgornje korake za odstranitev OSD skrajšate na dva ukaza:

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

Če po zaključku zgoraj opisanih korakov zaženete ukaz ceph osd tree, potem mora biti jasno, da na strežniku, kjer je bilo opravljeno delo, ni več OSD-jev, za katere so bile izvedene zgornje operacije:

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

Med potjo upoštevajte, da bo stanje grozda Ceph šlo v HEALTH_WARN, opazili pa bomo tudi zmanjšanje števila zaslonskih menijev in količine razpoložljivega prostora na disku.

V nadaljevanju bodo opisani koraki, ki bodo potrebni, če želite popolnoma ustaviti strežnik in ga ustrezno odstraniti iz Ceph. V tem primeru je pomembno, da se tega spomnite Preden zaustavite strežnik, morate odstraniti vse zaslonske menije na tem strežniku.

Če na tem strežniku ni več OSD-jev, potem ko jih odstranite, morate strežnik izključiti iz OSD zemljevida hv-2z izvajanjem naslednjega ukaza:

ceph osd crush rm hv-2

Izbriši mon s strežnika hv-2tako, da zaženete spodnji ukaz na drugem strežniku (tj. v tem primeru na hv-1):

ceph-deploy mon destroy hv-2

Po tem lahko zaustavite strežnik in začnete z naslednjimi dejanji (ponovno uvajanje itd.).

Primer št. 2. Porazdelitev prostora na disku v že ustvarjeni gruči Ceph

Drugo zgodbo bom začel s predgovorom o PG (Skupine umestitev). Glavna vloga PG v Cephu je predvsem združevanje objektov Ceph in njihovo nadaljnje posnemanje v OSD. Formula, s katero lahko izračunate potrebno količino PG, je v ustrezni razdelek Ceph dokumentacija. To vprašanje je tam obravnavano tudi s konkretnimi primeri.

Torej: ena od pogostih težav pri uporabi Cepha je neuravnoteženo število OSD in PG med bazeni v Cephu.

Prvič, zaradi tega lahko pride do situacije, ko je v majhnem bazenu podanih preveč PG, kar je v bistvu neracionalna uporaba prostora na disku v gruči. Drugič, v praksi obstaja resnejša težava: prelivanje podatkov v enem od OSD-jev. To pomeni, da grozd najprej preide v stanje HEALTH_WARN, in potem HEALTH_ERR. Razlog za to je, da Ceph pri izračunu razpoložljive količine podatkov (izvedete jo tako, da MAX AVAIL v izhodu ukaza ceph df za vsako skupino posebej) temelji na količini razpoložljivih podatkov v OSD. Če v vsaj enem OSD-ju ni dovolj prostora, ni mogoče zapisati več podatkov, dokler podatki niso pravilno porazdeljeni med vse OSD-je.

Vredno je pojasniti, da te težave se večinoma odločajo na stopnji konfiguracije gruče Ceph. Eno od orodij, ki jih lahko uporabite, je Ceph PGCalc. Z njegovo pomočjo je potrebna količina PG jasno izračunana. Vendar pa se lahko zatečete k njej tudi v situaciji, ko je grozd Ceph že nepravilno konfiguriran. Tukaj je vredno pojasniti, da boste kot del popravkov najverjetneje morali zmanjšati število PG, ta funkcija pa ni na voljo v starejših različicah Ceph (pojavila se je samo v različici Nautilus).

Torej, predstavljajmo si naslednjo sliko: grozd ima status HEALTH_WARN ker enemu od zaslonskih menijev zmanjkuje prostora. To bo označeno z napako HEALTH_WARN: 1 near full osd. Spodaj je algoritem za izhod iz te situacije.

Najprej morate razpoložljive podatke porazdeliti med preostale OSD-je. Podobno operacijo smo že izvedli v prvem primeru, ko smo "izsušili" vozlišče - z edino razliko, da bomo morali zdaj nekoliko zmanjšati reweight. Na primer do 0.95:

ceph osd reweight osd.${ID} 0.95

To sprosti prostor na disku v OSD-ju in odpravi napako v zdravju ceph. Vendar, kot že omenjeno, se ta težava pojavi predvsem zaradi nepravilne konfiguracije Ceph v začetnih fazah: zelo pomembno je, da naredite ponovno konfiguracijo, da se v prihodnosti ne bo pojavila.

V našem konkretnem primeru se je vse zmanjšalo na:

• vrednost previsoka replication_count v enem izmed bazenov,
• preveč PG v enem bazenu in premalo v drugem.

Uporabimo že omenjeni kalkulator. Jasno pokaže, kaj je treba vnesti, in načeloma ni nič zapletenega. Po nastavitvi potrebnih parametrov dobimo naslednja priporočila:

Obvestilo: Če nastavljate gručo Ceph iz nič, je še ena uporabna funkcija kalkulatorja generiranje ukazov, ki bodo iz nič ustvarili bazene s parametri, navedenimi v tabeli.

Zadnji stolpec vam pomaga pri navigaciji – Predlagano število PG. V našem primeru je uporaben tudi drugi, kjer je naveden parameter replikacije, saj smo se odločili spremeniti množitelj replikacije.

Torej, najprej morate spremeniti parametre replikacije - to je vredno storiti najprej, saj bomo z zmanjšanjem množitelja sprostili prostor na disku. Ko se ukaz izvede, boste opazili, da se bo razpoložljivi prostor na disku povečal:

ceph osd pool $pool_name set $replication_size

In po njegovem zaključku spremenimo vrednosti parametrov pg_num и pgp_num kot sledi:

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

Pomembno je,: zaporedno moramo spremeniti število PG v vsakem bazenu in ne spreminjati vrednosti ​​​​​v drugih bazenih, dokler opozorila ne izginejo "Pomanjšana redundanca podatkov" и "n-število degradiranih strani".

Z izhodi ukazov lahko tudi preverite, ali je vse potekalo dobro ceph health detail и ceph -s.

Zadeva št. 3. Selitev virtualnega stroja iz LVM v Ceph RBD

V primeru, ko projekt uporablja virtualne stroje, nameščene na najetih golih strežnikih, se pogosto pojavi vprašanje shranjevanja, ki je odporno na napake. Zelo zaželeno je tudi, da je v tem pomnilniku dovolj prostora ... Druga pogosta situacija: na strežniku je navidezni stroj z lokalnim pomnilnikom in disk morate razširiti, vendar ni kam iti, ker ni prosti prostor na disku, ki ostane na strežniku.

Težavo je mogoče rešiti na različne načine - na primer s selitvijo na drug strežnik (če obstaja) ali dodajanjem novih diskov na strežnik. Vendar tega ni vedno mogoče storiti, zato je selitev z LVM na Ceph lahko odlična rešitev te težave. Z izbiro te možnosti poenostavimo tudi nadaljnji proces selitve med strežniki, saj lokalnega pomnilnika ne bo treba seliti iz enega hipervizorja v drugega. Edina težava je, da boste morali med izvajanjem dela ustaviti VM.

Naslednji recept je vzet iz članek iz tega bloga, katerega navodila so bila preizkušena v akciji. Mimogrede, tam je opisan tudi način selitve brez težav, vendar v našem primeru preprosto ni bil potreben, zato ga nismo preverjali. Če je to ključnega pomena za vaš projekt, bomo veseli rezultatov v komentarjih.

Preidimo na praktični del. V primeru uporabljamo virsh in temu primerno libvirt. Najprej se prepričajte, da je področje Ceph, v katerega bodo preseljeni podatki, povezano z libvirt:

virsh pool-dumpxml $ceph_pool

Opis bazena mora vsebovati podatke o povezavi s Cephom s podatki o avtorizaciji.

Naslednji korak je, da se slika LVM pretvori v Ceph RBD. Čas izvedbe je odvisen predvsem od velikosti slike:

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

Po pretvorbi bo ostala slika LVM, ki bo uporabna, če selitev VM v RBD ne uspe in boste morali razveljaviti spremembe. Da bi lahko hitro povrnili spremembe nazaj, naredimo tudi varnostno kopijo konfiguracijske datoteke navideznega stroja:

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

... in uredi izvirnik (vm_name.xml). Poiščimo blok z opisom diska (začne se z vrstico <disk type='file' device='disk'> in se konča z </disk>) in ga zmanjšajte na naslednjo obliko:

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

Oglejmo si nekaj podrobnosti:

1. K protokolu source naveden je naslov do pomnilnika v Ceph RBD (to je naslov, ki označuje ime bazena Ceph in sliko RBD, ki je bila določena na prvi stopnji).
2. V bloku secret je navedena vrsta ceph, kot tudi UUID skrivnosti za povezavo z njim. Njegov uuid lahko najdete z ukazom virsh secret-list.
3. V bloku host navedeni so naslovi monitorjev Ceph.

Ko uredite konfiguracijsko datoteko in zaključite pretvorbo LVM v RBD, lahko uporabite spremenjeno konfiguracijsko datoteko in zaženete virtualni stroj:

virsh define $vm_name.xml
virsh start $vm_name

Čas je, da preverite, ali se je virtualni stroj pravilno zagnal: to lahko ugotovite na primer tako, da se z njim povežete prek SSH ali prek virsh.

Če virtualni stroj deluje pravilno in niste našli nobenih drugih težav, lahko izbrišete sliko LVM, ki je ne uporabljate več:

lvremove main/$vm_image_name

Zaključek

Z vsemi opisanimi primeri smo se srečali v praksi - upamo, da bodo navodila pomagala drugim administratorjem pri reševanju podobnih težav. Če imate komentarje ali druge podobne zgodbe iz vaših izkušenj z uporabo Cepha, jih bomo veseli v komentarjih!

PS

Preberite tudi na našem blogu:

• «Naše roke niso za dolgčas: obnavljanje gruče Rook v K8s»;
• «Topu ali ne Rooku - to je vprašanje»;
• «Rook - “samopostrežno” podatkovno skladišče za Kubernetes»;
• «Ustvarjanje trajnega pomnilnika z zagotavljanjem v Kubernetes na podlagi Ceph".

Vir: www.habr.com