🥇Savjeti i trikovi u radu s Ceph-om u opterećenim projektima

Korištenjem Ceph-a kao mrežnog spremišta u projektima različitih razina opterećenja, možemo se susresti s raznim zadacima koji se na prvi pogled ne čine jednostavnima ili trivijalnima. Na primjer:

migracija podataka iz starog Ceph-a u novi uz djelomično korištenje prethodnih servera u novom klasteru;
rješavanje problema raspodjele diskovnog prostora u Ceph-u.

Baveći se takvim zadacima, suočavamo se s potrebom ispravnog uklanjanja OSD-a bez gubitka podataka, što je posebno važno pri velikim količinama podataka. O tome će biti riječ u članku.

Opisane metode relevantne su za sve verzije Ceph-a. Osim toga, bit će uzeta u obzir činjenica da Ceph može skladištiti velike količine podataka: kako bismo spriječili gubitak podataka i druge probleme, neke radnje će biti "podijeljene" na nekoliko manjih.

Predgovor o OSD-u

Budući da su dva od tri razmatrana recepta posvećena OSD-u (Object Storage Daemon), prije nego što zaronimo u praktični dio - ukratko o tome što je to u Ceph-u i zašto je toliko važan.

Prvo treba reći da se cijeli Ceph klaster sastoji od mnogih OSD-ova. Što ih je više, to je veći slobodni prostor za podatke u Ceph-u. Odatle je lako razumjeti glavnu funkciju OSD-a: on pohranjuje podatke objekata Ceph-a na datotečnim sustavima svih čvorova klastera i omogućava mrežni pristup tim podacima (za čitanje, pisanje i druge zahtjeve).

Na ovoj razini također se postavljaju parametri replikacije kopiranjem objekata među različitim OSD-ovima. Ovdje se možemo susresti s različitim problemima, čije ćemo rješenje razmatrati u nastavku.

Slučaj br. 1. Sigurno uklanjanje OSD-a iz Ceph klastera bez gubitka podataka

Potrebna je uklanjanje OSD-a može biti uzrokovana isključenjem servera iz klastera — na primjer, radi zamjene s drugim serverom — što se i dogodilo kod nas, što je poslužilo kao povod za pisanje ovog članka. Tako da je konačni cilj manipulacija — ukloniti sve OSD-ove i mon'ove na ovom serveru kako bismo mogli zaustaviti njegov rad.

Radi praktičnosti i kako bismo izbjegli situaciju u kojoj bismo tijekom izvođenja naredbi pogriješili u označavanju potrebnog OSD-a, postavit ćemo zasebnu varijablu, čija će vrijednost biti broj uklanjanog OSD-a. Nazvat ćemo je ${ID} — ovdje i nadalje takva varijabla zamjenjuje broj OSD-a s kojim radimo.

Pogledajmo stanje prije početka radova:

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

Kako bi se iniciralo brisanje OSD-a, potrebno je postupno izvršiti reweight na njoj do nule. Tako smanjujemo količinu podataka u OSD-u balansiranjem na druge OSD-ove. Za to se izvršavaju sljedeće komande:

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

… i tako dalje do nule.

Postupno balansiranje je potrebno, kako bismo izbjegli gubitak podataka. To je posebno važno ako OSD sadrži veliku količinu podataka. Kako bismo se uvjerili da su svi koraci uspješno izvršeni, možemo izvesti reweight ceph -s ili pokrenuti u zasebnom prozoru terminala ceph -w kako bismo pratili promjene u stvarnom vremenu. Kada je OSD "ispražnjen", možemo pristupiti standardnoj operaciji za njegovo uklanjanje. Za to ćemo prevesti potrebni OSD u stanje

down ceph osd down osd.${ID}:

"Izvlačimo" OSD iz klastera:

ceph osd out osd.${ID}

Zaustavljamo OSD uslugu i odjavljujemo njegovu particiju u FS-u:

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

Uklanjamo OSD iz

CRUSH map ceph osd crush remove osd.${ID}:

Uklanjamo korisnika OSD-a:

ceph auth del osd.${ID}

I, konačno, uklanjamo sam OSD:

ceph osd rm osd.${ID}

: ako koristite verziju Ceph Luminous ili noviju, tada se prethodno opisane radnje za uklanjanje OSD-a mogu svesti na dvije komande:

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

Ako nakon izvršenja gore navedenih akcija izvedete komandu

ceph osd tree , trebali bismo vidjeti da na serveru na kojem su izvedeni radovi više nema OSD-a nad kojima su obavljene gornje 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

Usput, primijetit ćemo da će stanje Ceph klastera preći u

HEALTH_WARN , a također ćemo vidjeti smanjenje broja OSD-a i dostupnog prostora na disku.Dalje će biti opisani koraci koji će biti potrebni ako želite potpuno zaustaviti server i, sukladno tome, ukloniti ga iz Ceph-a. U tom slučaju važno je zapamtiti da

prije isključivanja servera morate izvaditi sve OSD-ove na ovom serveru. Ako na ovom serveru više nema OSD-a, nakon njihovog uklanjanja potrebno je isključiti iz mape OSD server

hv-2 hv-2, izvršavanjem sljedeće naredbe:

ceph osd crush rm hv-2

Brišemo mon s poslužitelja hv-2, pokretanjem dolje navedene naredbe na drugom poslužitelju (tj. u ovom slučaju — na hv-1):

ceph-deploy mon destroy hv-2

Nakon toga se može zaustaviti poslužitelj i pristupiti sljedećim radnjama (njegovom ponovnom postavljanju itd.).

Slučaj br. 2. Raspodjela diskovnog prostora u već stvorenom Ceph klasteru

Drugoj priči ću početi s uvodom o PG (Placement Groups). Osnovna uloga PG u Ceph-u prvenstveno je agregacija Ceph objekata i daljnja replikacija u OSD. Formula koja se može koristiti za izračunavanje potrebnog broja PG-a nalazi se u odgovarajućem odjeljku dokumentacije Ceph. Tamo se isto pitanje razrađuje i na konkretnim primjerima.

Dakle, jedna od uobičajenih problema tijekom korištenja Ceph-a jeste neizbalansiran broj OSD-a i PG-a između bazena u Ceph-u.

Prvo, zbog toga može doći do situacije u kojoj se navodi prevelik broj PG-a u malom bazenu, što u suštini predstavlja neracionalnu upotrebu diskovnog prostora u klasteru. Drugo, u praksi se pojavljuje ozbiljniji problem: preopterećenje podataka u jednom od OSD-a. To dovodi do toga da klaster prvo prelazi u stanje , a također ćemo vidjeti smanjenje broja OSD-a i dostupnog prostora na disku., a potom i HEALTH_ERR. Sve je to posljedica što Ceph prilikom izračunavanja dostupnog volumena podataka (može se saznati putem MAX AVAIL u izlazu naredbe ceph df za svaki bazen posebno) oslanja na volume dostupnih podataka u OSD-u. Ako u barem jednom OSD-u ne bude dovoljno prostora, podaci se više neće moći zapisivati dok se ne raspodijele ispravno između svih OSD-a.

Važno je napomenuti da se ovi problemi u većoj mjeri rješavaju u fazi konfiguracije Ceph klastera. Jedan od alata koji se može koristiti je Ceph PGCalc. Pomoću njega se vizualno izračunava potreban broj PG-a. Međutim, njemu se može pribjeći i u situaciji kada je Ceph klaster već neispravno konfiguriran. Ovde treba napomenuti da će vam prilikom rada na ispravci najvjerojatnije biti potrebno smanjiti broj PG-a, a ta mogućnost nije dostupna u starijim verzijama Ceph-a (pojavio se tek s verzijom Nautilus).

Dakle, zamislite sljedeću situaciju: status klastera je , a također ćemo vidjeti smanjenje broja OSD-a i dostupnog prostora na disku. jer u jednom od OSD-a ponestaje prostora. O tome će svjedočiti greška HEALTH_WARN: 1 gotovo puni osd. Ispod je prikazan algoritam za izlazak iz takve situacije.

Prvo je potrebno rasporediti postojeće podatke između preostalih OSD-a. Takvu operaciju smo već radili u prvom slučaju, kada smo "isušivali" čvor — s tom razlikom što će sada biti potrebno neznatno smanjiti reweight. Na primjer, do 0.95:

ceph osd reweight osd.${ID} 0.95

Tako se oslobađa diskovni prostor u OSD-u i popravlja greška u ceph health. Međutim, kao što je već spomenuto, ovaj problem se većinom javlja zbog nepravilne konfiguracije Ceph-a u ranim fazama: vrlo je važno izvršiti rekonstrukciju kako se ne bi ponovno pojavila.

U našem konkretnom slučaju sve se svodilo na:

prevelika vrijednost replication_count u jednom od pulova,
prekombinirana količina PG-a u jednom pulu i premala u drugom.

Iskoristit ćemo već spomenuti kalkulator. U njemu je jasno prikazano što treba unijeti i, u načelu, nema ništa komplicirano. Postavljajući potrebne parametre, dobivamo sljedeće preporuke:

Napomena: ako postavljate Ceph klaster od nule, dodatna korisna funkcija kalkulatora bit će generiranje komandi koje će stvoriti pule od nule s parametrima navedenim u tablici.

Orijentaciju pomaže posljednji stupac — Suggested PG Count. U našem slučaju koristan je i drugi stupac, gdje je naveden parametar replikacije, budući da smo odlučili promijeniti i umnožitelj replikacije.

Dakle, prvo je potrebno promijeniti parametre replikacije — to treba učiniti prvo, jer smanjivanjem umnožitelja oslobađamo diskovni prostor. Tijekom izvršavanja komande može se primijetiti da se vrijednost dostupnog diskovnog prostora povećava:

ceph osd pool $pool_name set $replication_size

A nakon što završi — mijenjamo vrijednosti parametara pg_num i pgp_num na sljedeći način:

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

Važno: trebamo redom u svakom pulu promijeniti broj PG-a i ne mijenjati vrijednosti u drugim pulovima dok upozorenja ne nestanu „Degraded data redundancy” i „n-broj pgs degraded”.

Provjeriti da li je sve prošlo uspješno također se može putem izlaza komandi ceph health detail i ili pokrenuti u zasebnom prozoru terminala.

Slučaj br. 3. Migracija virtualne mašine s LVM-a u Ceph RBD

U situaciji kada se u projektu koriste virtualne mašine postavljene na iznajmljene bare-metal servere, često se postavlja pitanje o pouzdanom skladištenju. Također, poželjno je da prostor u tom skladištu bude dovoljna... Druga uobičajena situacija: postoji virtualna mašina s lokalnim skladištem na serveru i potrebno je proširiti disk, ali nema gdje, jer na serveru više nema slobodnog prostora na disku.

Problem se može riješiti na različite načine - na primjer, migracijom na drugi server (ako takav postoji) ili dodavanjem novih diskova na server. No ne uspeva uvijek to učiniti, zbog čega migracija iz LVM-a u Ceph može biti odlična solucija ovog problema. Odabirom ove opcije također pojednostavljujemo budući proces migracije između servera, jer ne treba premještati lokalno skladište s jednog hipervizora na drugi. Jedini problem je što ćemo morati zaustaviti VM tijekom rada.

Kao referentna receptura uzeta je članak s ovog bloga, čije su upute testirane u praksi. Inače, tamo je opisan i način besprijekorne migracije, međutim, u našem slučaju to jednostavno nije bilo potrebno, pa ga nismo provjeravali. Ako je to ključno za vaš projekt - bit ćemo zahvalni ako nas obavijestite o rezultatima u komentarima.

Pristupimo praktičnom dijelu. U primjeru koristimo virsh i, shodno tome, libvirt. Prvo se pobrinite da je Ceph pool, u koji će se migrirati podaci, povezan s libvirt-om:

virsh pool-dumpxml $ceph_pool

U opisu poola trebali bi biti podaci o povezivanju s Ceph-om i podaci za autorizaciju.

Sljedeći korak je konverzija LVM slike u Ceph RBD. Vrijeme izvođenja ovisi prvenstveno o veličini slike:

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

Nakon konverzije ostaje LVM slika, koja će biti korisna u slučaju da migracija VM-a u RBD ne uspije i morat ćemo vraćati promjene. Također, kako bismo mogli brzo vratiti promjene, napravit ćemo backup konfiguracijske datoteke virtualne mašine:

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

... i urediti original (vm_name.xml). Naći ćemo blok s opisom diska (koji počinje s linijom <disk type='file' device='disk'> i završava s </disk>) i dovesti ga u sljedeći oblik:

Razmotrit ćemo neke detalje:

U protokolu source navodi se adresa do skladišta u Ceph RBD (to je adresa s naznakom naziva Ceph bazena i RBD slike, koja je definirana u prvom koraku).
U bloku secret navodi se tip ceph, kao i UUID tajne za povezivanje s njom. Njegov uuid se može saznati pomoću naredbe virsh secret-list.
U bloku host navode se adrese do Ceph monitora.

Nakon uređivanja konfiguracijske datoteke i završetka konverzije LVM u RBD može se primijeniti izmijenjena konfiguracijska datoteka i pokrenuti virtualna mašina:

virsh define $vm_name.xml
virsh start $vm_name

Vrijeme je da provjerimo je li virtualna mašina ispravno pokrenuta: to se može provjeriti, na primjer, povezivanjem putem SSH ili putem virsh.

Ako virtualna mašina ispravno radi i ne primijetite druge probleme, možete ukloniti LVM sliku koja više nije u upotrebi:

lvremove main/$vm_image_name

Zaključak

U svim navedenim slučajevima susreli smo se s praksom - nadamo se da će upute pomoći i drugim administratorima da riješe slične probleme. Ako imate prijedloge ili druga slična iskustva s provođenjem Ceph-a, rado bismo ih vidjeli u komentarima!