Savjeti i trikovi za rad sa Cephom u zauzetim projektima

Koristeći Ceph kao mrežnu pohranu u projektima s različitim opterećenjem, možemo naići na razne zadatke koji na prvi pogled ne izgledaju jednostavni ili trivijalni. Na primjer:

• migracija podataka sa starog Ceph-a na novi uz djelomičnu upotrebu prethodnih servera u novom klasteru;
• rješenje problema dodjele prostora na disku u Ceph-u.

Suočavajući se sa ovakvim problemima, suočavamo se sa potrebom da ispravno uklonimo OSD bez gubitka podataka, što je posebno važno kada se radi o velikim količinama podataka. O tome će biti riječi u članku.

Metode opisane u nastavku su relevantne za bilo koju verziju Ceph-a. Uz to će se uzeti u obzir i činjenica da Ceph može pohraniti veliku količinu podataka: kako bi se spriječio gubitak podataka i drugi problemi, neke radnje će biti "podijeljene" na nekoliko drugih.

Predgovor o OSD-u

Pošto su dva od tri razmatrana recepta posvećena OSD (Demon za pohranu objekata), prije nego što pređemo na praktični dio - ukratko o tome šta je to u Cephu i zašto je toliko važno.

Prije svega, treba reći da se cijeli Ceph klaster sastoji od mnogo OSD-ova. Što ih je više, veći je volumen besplatnih podataka u Ceph-u. Odavde je lako razumeti glavna OSD funkcija: Pohranjuje podatke Ceph objekata na sistemima datoteka svih čvorova klastera i pruža im mrežni pristup (za čitanje, pisanje i druge zahtjeve).

Na istom nivou, parametri replikacije se postavljaju kopiranjem objekata između različitih OSD-ova. I ovdje možete naići na razne probleme, o rješenjima kojih će biti riječi u nastavku.

Slučaj br. 1. Sigurno uklonite OSD iz Ceph klastera bez gubitka podataka

Potreba za uklanjanjem OSD-a može biti uzrokovana uklanjanjem servera iz klastera – na primjer, da bismo ga zamijenili drugim serverom – što nam se i dogodilo, što je dovelo do pisanja ovog članka. Dakle, krajnji cilj manipulacije je ekstrahiranje svih OSD-ova i mon-ova na datom serveru kako bi se mogao zaustaviti.

Radi praktičnosti i izbjegavanja situacije u kojoj prilikom izvršavanja naredbi pogriješimo u naznaku traženog OSD-a, postavićemo posebnu varijablu, čija će vrijednost biti broj OSD-a koji treba obrisati. Pozovimo je ${ID} — ovdje i ispod, takva varijabla zamjenjuje broj OSD-a s kojim radimo.

Pogledajmo stanje prije početka rada:

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

Da biste započeli uklanjanje OSD-a, morat ćete raditi glatko reweight na njemu na nulu. Na ovaj način smanjujemo količinu podataka u OSD-u balansirajući ih sa drugim OSD-ovima. Da biste to učinili, pokrenite sljedeće naredbe:

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

... i tako do nule.

Potrebno je glatko balansiranjeda ne izgubite podatke. Ovo je posebno tačno ako OSD sadrži veliku količinu podataka. Da biste bili sigurni da nakon izvršenja naredbi reweight sve je prošlo kako treba, možete završiti ceph -s ili u zasebnom terminalskom prozoru ceph -w kako bi pratili promjene u realnom vremenu.

Kada se OSD „isprazni“, možete nastaviti sa standardnom operacijom da ga uklonite. Da biste to učinili, prenesite željeni OSD u stanje down:

ceph osd down osd.${ID}

Hajde da "izvučemo" OSD iz klastera:

ceph osd out osd.${ID}

Zaustavimo OSD uslugu i demontirajmo njenu particiju u FS:

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

Uklonite OSD iz CRUSH map:

ceph osd crush remove osd.${ID}

Izbrišemo OSD korisnika:

ceph auth del osd.${ID}

I na kraju, uklonimo sam OSD:

ceph osd rm osd.${ID}

primjedba: Ako koristite Ceph Luminous verziju ili noviju, gore navedeni koraci uklanjanja OSD-a mogu se svesti na dvije naredbe:

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

Ako, nakon dovršetka gore opisanih koraka, pokrenete naredbu ceph osd tree, tada bi trebalo biti jasno da na serveru na kojem je obavljen posao više ne postoje OSD-ovi za koje su obavljene gore navedene 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, imajte na umu da će stanje Ceph klastera ići u HEALTH_WARN, a također ćemo vidjeti smanjenje broja OSD-ova i količine dostupnog prostora na disku.

U nastavku će biti opisani koraci koji će biti potrebni ako želite potpuno zaustaviti server i, shodno tome, ukloniti ga iz Ceph-a. U ovom slučaju, važno je to zapamtiti Prije isključivanja servera, morate ukloniti sve OSD-ove na ovom serveru.

Ako na ovom serveru nema više OSD-ova, onda nakon što ih uklonite, morate isključiti server iz OSD mape hv-2pokretanjem sljedeće naredbe:

ceph osd crush rm hv-2

Izbriši mon sa servera hv-2pokretanjem naredbe ispod na drugom serveru (tj. u ovom slučaju na hv-1):

ceph-deploy mon destroy hv-2

Nakon toga možete zaustaviti server i započeti s narednim radnjama (ponovno postavljanje, itd.).

Slučaj br. 2. Distribucija prostora na disku u već kreiranom Ceph klasteru

Drugu priču ću započeti predgovorom o PG (Grupe plasmana). Glavna uloga PG-a u Ceph-u je prvenstveno da agregira Ceph objekte i dalje ih replicira u OSD-u. Formula sa kojom možete izračunati potrebnu količinu PG je unutra relevantni odjeljak Ceph dokumentacija. Tamo se i o ovom pitanju raspravlja na konkretnim primjerima.

Dakle: jedan od uobičajenih problema pri korištenju Ceph-a je neuravnotežen broj OSD-a i PG-a između skupova u Ceph-u.

Prvo, zbog toga može nastati situacija kada je previše PG-ova specificirano u malom skupu, što je u suštini neracionalno korištenje prostora na disku u klasteru. Drugo, u praksi postoji ozbiljniji problem: prelivanje podataka u jednom od OSD-a. To podrazumijeva da klaster prvo prelazi u stanje HEALTH_WARN, i onda HEALTH_ERR. Razlog tome je što Ceph, prilikom izračunavanja raspoložive količine podataka (možete saznati putem MAX AVAIL u izlazu komande ceph df za svaki skup posebno) zasniva se na količini dostupnih podataka u OSD-u. Ako nema dovoljno prostora u barem jednom OSD-u, više podataka se ne može pisati dok se podaci pravilno ne rasporede među svim OSD-ovima.

Vrijedi pojasniti da su ovi problemi se uglavnom odlučuju u fazi konfiguracije Ceph klastera. Jedan od alata koji možete koristiti je Ceph PGCalc. Uz njegovu pomoć jasno se izračunava potrebna količina PG. Međutim, možete pribjeći tome iu situaciji kada je Ceph klaster već pogrešno konfigurisano. Ovdje je vrijedno pojasniti da ćete kao dio popravke najvjerovatnije morati smanjiti broj PG-ova, a ova funkcija nije dostupna u starijim verzijama Ceph-a (pojavila se samo u verziji Nautilus).

Dakle, zamislimo sljedeću sliku: klaster ima status HEALTH_WARN jer na jednom od OSD-a ponestaje prostora. Ovo će biti naznačeno greškom HEALTH_WARN: 1 near full osd. Ispod je algoritam za izlazak iz ove situacije.

Prije svega, trebate distribuirati dostupne podatke između preostalih OSD-ova. Već smo izvršili sličnu operaciju u prvom slučaju, kada smo "ispraznili" čvor - s jedinom razlikom što ćemo sada morati malo smanjiti reweight. Na primjer, do 0.95:

ceph osd reweight osd.${ID} 0.95

Ovo oslobađa prostor na disku u OSD-u i popravlja grešku u zdravlju ceph-a. Međutim, kao što je već spomenuto, ovaj problem se uglavnom javlja zbog pogrešne konfiguracije Ceph-a u početnim fazama: vrlo je važno izvršiti rekonfiguraciju kako se ne bi pojavio u budućnosti.

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

• vrijednost previsoka replication_count u jednom od bazena,
• previše PG u jednom bazenu i premalo u drugom.

Upotrijebimo već spomenuti kalkulator. Jasno pokazuje šta treba unijeti i, u principu, nema ništa komplikovano. Nakon postavljanja potrebnih parametara, dobijamo sljedeće preporuke:

primjedba: Ako postavljate Ceph klaster od nule, još jedna korisna funkcija kalkulatora je generiranje naredbi koje će kreirati skupove od nule sa parametrima navedenim u tabeli.

Poslednja kolona vam pomaže da se krećete - Preporučeni broj PG. U našem slučaju je koristan i drugi, gdje je naznačen parametar replikacije, jer smo odlučili promijeniti množitelj replikacije.

Dakle, prvo morate promijeniti parametre replikacije - to vrijedi prvo učiniti, jer ćemo smanjenjem množitelja osloboditi prostor na disku. Kako se naredba izvršava, primijetit ćete da će se raspoloživi prostor na disku povećati:

ceph osd pool $pool_name set $replication_size

I nakon njegovog završetka mijenjamo vrijednosti parametara pg_num и pgp_num kako slijedi:

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

važno: moramo mijenjati broj PG-ova uzastopno u svakom bazenu i ne mijenjati vrijednosti ​​​​u drugim skupinama dok upozorenja ne nestanu "Degradirana redundantnost podataka" и "n-broj degradiranih pgs".

Također možete provjeriti da li je sve prošlo dobro koristeći izlazne komande ceph health detail и ceph -s.

Slučaj br. 3. Migracija virtuelne mašine sa LVM na Ceph RBD

U situaciji kada projekat koristi virtuelne mašine instalirane na iznajmljenim golim serverima, često se javlja pitanje skladištenja otpornog na greške. Takođe je veoma poželjno da u ovom skladištu ima dovoljno prostora... Još jedna uobičajena situacija: na serveru postoji virtuelna mašina sa lokalnom memorijom i treba da proširite disk, ali nema kuda, jer nema slobodan prostor na disku preostao na serveru.

Problem se može riješiti na različite načine - na primjer, migracijom na drugi server (ako postoji) ili dodavanjem novih diskova na server. Ali to nije uvijek moguće učiniti, tako da migracija sa LVM-a na Ceph može biti odlično rješenje za ovaj problem. Odabirom ove opcije pojednostavljujemo i daljnji proces migracije između servera, jer neće biti potrebe za premještanjem lokalne memorije s jednog hipervizora na drugi. Jedina kvaka je da ćete morati da zaustavite VM dok se posao obavlja.

Sledeći recept je preuzet iz članak sa ovog bloga, čije su upute testirane na djelu. Između ostalog, tamo je također opisana metoda migracije bez problema, međutim, u našem slučaju jednostavno nije bio potreban, pa ga nismo provjeravali. Ako je ovo kritično za vaš projekat, bit će nam drago čuti rezultate u komentarima.

Pređimo na praktični dio. U primjeru koristimo virsh i, shodno tome, libvirt. Prvo, uvjerite se da je Ceph spremište u koje će podaci biti migrirani povezano na libvirt:

virsh pool-dumpxml $ceph_pool

Opis spremišta mora sadržavati podatke o povezivanju na Ceph s podacima o autorizaciji.

Sljedeći korak je da se LVM slika konvertuje u Ceph RBD. Vrijeme izvrš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, LVM slika će ostati, što će biti korisno ako migracija VM-a na RBD ne uspije i morate vratiti promjene. Takođe, da bismo mogli brzo da vratimo promene, napravimo rezervnu kopiju konfiguracionog fajla virtuelne mašine:

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

... i urediti original (vm_name.xml). Pronađimo blok s opisom diska (počinje linijom <disk type='file' device='disk'> i završava sa </disk>) i svesti na sljedeći oblik:

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

Pogledajmo neke detalje:

1. Za protokol source naznačena je adresa memorije u Ceph RBD (ovo je adresa koja označava naziv Ceph bazena i RBD sliku, koja je određena u prvoj fazi).
2. U bloku secret tip je naznačen ceph, kao i UUID tajne za povezivanje s njom. Njegov uuid se može pronaći pomoću naredbe virsh secret-list.
3. U bloku host adrese Ceph monitora su naznačene.

Nakon uređivanja konfiguracijske datoteke i dovršetka konverzije LVM u RBD, možete primijeniti izmijenjenu konfiguracijsku datoteku i pokrenuti virtuelnu mašinu:

virsh define $vm_name.xml
virsh start $vm_name

Vrijeme je da provjerite da li je virtuelna mašina ispravno pokrenuta: to možete saznati, na primjer, povezivanjem na nju putem SSH-a ili putem virsh.

Ako virtuelna mašina radi ispravno i niste pronašli nikakve druge probleme, tada možete izbrisati LVM sliku koja se više ne koristi:

lvremove main/$vm_image_name

zaključak

U praksi smo se susreli sa svim opisanim slučajevima - nadamo se da će upute pomoći drugim administratorima da riješe slične probleme. Ako imate komentare ili druge slične priče iz svog iskustva korištenja Ceph-a, bit će nam drago vidjeti ih u komentarima!

PS

Pročitajte i na našem blogu:

• «Naše ruke nisu za dosadu: vraćanje Rook grozda u K8s»;
• «Topu ili ne Topu - to je pitanje»;
• «Rook - “samouslužno” skladište podataka za Kubernetes»;
• «Kreiranje trajne pohrane sa obezbjeđivanjem u Kubernetesu zasnovanom na Ceph-u".

izvor: www.habr.com