Savjeti i trikovi za rad s Cephom u napornim projektima

Koristeći Ceph kao mrežnu pohranu u projektima s različitim opterećenjima, možemo se susresti s raznim zadacima koji na prvi pogled ne izgledaju jednostavno ili trivijalno. Na primjer:

• migracija podataka sa starog Cepha na novi uz djelomičnu upotrebu prethodnih poslužitelja u novom klasteru;
• rješenje problema raspodjele prostora na disku u Cephu.

Suočavajući se s ovakvim problemima, suočeni smo s potrebom ispravnog uklanjanja OSD-a bez gubitka podataka, što je posebno važno kada se radi o velikim količinama podataka. O tome će se raspravljati u članku.

Dolje opisane metode relevantne su za bilo koju verziju Cepha. Osim toga, bit će uzeta u obzir činjenica da Ceph može pohraniti veliku količinu podataka: kako bi se spriječio gubitak podataka i drugi problemi, neke radnje bit će "podijeljene" u nekoliko drugih.

Predgovor o OSD-u

Budući da su dva od tri spomenuta recepta posvećena OSD-u (Demon za pohranu objekata), prije nego što zaronimo u praktični dio - ukratko o tome što 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ća je količina besplatnih podataka u Cephu. Odavde je lako razumjeti glavna OSD funkcija: Pohranjuje podatke Ceph objekta u datotečne sustave svih čvorova klastera i omogućuje mrežni pristup njima (za čitanje, pisanje i druge zahtjeve).

Na istoj razini, parametri replikacije se postavljaju kopiranjem objekata između različitih OSD-ova. I ovdje se možete susresti s raznim problemima, o rješenjima će se dalje raspravljati.

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

Potreba za uklanjanjem OSD-a može biti uzrokovana uklanjanjem poslužitelja iz klastera - na primjer, da se zamijeni drugim poslužiteljem - što se nama dogodilo, što je dovelo do pisanja ovog članka. Stoga je krajnji cilj manipulacije ekstrahirati sve OSD-ove i monove na određenom poslužitelju tako da se može zaustaviti.

Radi praktičnosti i izbjegavanja situacije u kojoj tijekom izvršavanja naredbi pogriješimo u označavanju potrebnog OSD-a, postavit ćemo zasebnu varijablu čija će vrijednost biti broj OSD-a koji se briše. Nazovimo je ${ID} — ovdje i dolje, 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 glatko izvesti reweight na njemu na nulu. Na ovaj način smanjujemo količinu podataka u OSD-u usklađujući ih s drugim OSD-ima. 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 glatko balansiranjekako ne bi izgubili podatke. To je osobito istinito ako OSD sadrži veliku količinu podataka. Kako bismo bili sigurni da nakon izvršenja naredbi reweight sve je prošlo dobro, možete to dovršiti ceph -s ili u zasebnom prozoru terminala pokrenuti ceph -w kako bi se promjene promatrale u realnom vremenu.

Kada se OSD "isprazni", možete nastaviti sa standardnom operacijom za njegovo uklanjanje. Da biste to učinili, prenesite željeni OSD u stanje down:

ceph osd down osd.${ID}

Idemo "izvući" OSD iz klastera:

ceph osd out osd.${ID}

Zaustavimo OSD servis i demontiramo njegovu particiju u FS-u:

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

Ukloni OSD iz CRUSH karta:

ceph osd crush remove osd.${ID}

Idemo izbrisati OSD korisnika:

ceph auth del osd.${ID}

I na kraju, uklonimo sam OSD:

ceph osd rm osd.${ID}

Primijetiti: Ako koristite verziju Ceph Luminous ili noviju, tada se gornji koraci uklanjanja OSD-a mogu 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 poslužitelju na kojem je rad obavljen više nema OSD-ova 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 klastera Ceph prijeć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 poslužitelj i, sukladno tome, ukloniti ga iz Cepha. U ovom slučaju, važno je to zapamtiti Prije gašenja poslužitelja, morate ukloniti sve OSD-ove na ovom poslužitelju.

Ako više nema OSD-ova na ovom poslužitelju, nakon njihovog uklanjanja trebate isključiti poslužitelj iz OSD karte hv-2pokretanjem sljedeće naredbe:

ceph osd crush rm hv-2

ukloniti mon sa servera hv-2pokretanjem donje naredbe na drugom poslužitelju (tj. u ovom slučaju, na hv-1):

ceph-deploy mon destroy hv-2

Nakon toga možete zaustaviti poslužitelj i započeti sljedeće radnje (ponovno postavljanje itd.).

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

Drugu priču ću započeti predgovorom o PG (Grupe plasmana). Glavna uloga PG-a u Ceph-u prvenstveno je agregiranje Ceph objekata i njihovo daljnje repliciranje u OSD-u. Formula pomoću koje možete izračunati potrebnu količinu PG nalazi se u relevantni odjeljak Ceph dokumentacija. Ta se problematika također raspravlja na konkretnim primjerima.

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

Prvo, zbog toga može doći do situacije da je previše PG-ova navedeno u malom bazenu, što je u biti neracionalno korištenje prostora na disku u klasteru. Drugo, u praksi postoji ozbiljniji problem: prelijevanje podataka u jednom od OSD-ova. To podrazumijeva prvo prijelaz klastera u stanje HEALTH_WARN, i onda HEALTH_ERR. Razlog za to je što Ceph, kada izračunava raspoloživu količinu podataka (možete je saznati na MAX AVAIL u izlazu naredbe ceph df za svaki skup posebno) temelji se na količini dostupnih podataka na OSD-u. Ako nema dovoljno prostora u barem jednom OSD-u, više se podataka ne može pisati dok se podaci pravilno ne raspodijele na sve OSD-e.

Vrijedno je pojasniti da ovi problemi uglavnom se 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, također možete pribjeći tome u situaciji kada Ceph cluster već neispravno konfiguriran. Ovdje vrijedi pojasniti da ćete kao dio rada na popravku najvjerojatnije morati smanjiti broj PG-ova, a ova značajka nije dostupna u starijim verzijama Cepha (pojavila se samo u verziji Nautilus).

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

Prije svega, morate raspodijeliti 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 da ć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 ispravlja pogrešku u ispravnosti ceph-a. Međutim, kao što je već spomenuto, ovaj se problem uglavnom javlja zbog neispravne 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, a premalo u drugom.

Poslužimo se već spomenutim kalkulatorom. Jasno pokazuje što treba unijeti i, u načelu, nema ništa komplicirano. Postavljanjem potrebnih parametara dobivamo sljedeće preporuke:

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

Posljednji stupac pomaže vam u navigaciji - Predloženi broj PG. U našem slučaju, drugi je također koristan, gdje je naznačen parametar replikacije, jer smo odlučili promijeniti množitelj replikacije.

Dakle, prvo morate promijeniti parametre replikacije - ovo je prvo vrijedno 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

To je važno: moramo promijeniti broj PG-ova uzastopno u svakom skupu i ne mijenjati vrijednosti u drugim skupovima dok upozorenja ne nestanu "Degradirana redundantnost podataka" и "n-broj degradiranih stranica".

Također možete provjeriti je li sve dobro prošlo pomoću izlaza naredbi ceph health detail и ceph -s.

Slučaj br. 3. Migracija virtualnog stroja s LVM na Ceph RBD

U situaciji kada projekt koristi virtualne strojeve instalirane na unajmljenim bare-metal poslužiteljima, često se postavlja pitanje fault-tolerant storage-a. Također je vrlo poželjno da ima dovoljno prostora u ovoj pohrani... Još jedna uobičajena situacija: postoji virtualni stroj s lokalnom pohranom na poslužitelju i trebate proširiti disk, ali nemate kamo otići, jer nema slobodnog prostora na disku koji je ostao na poslužitelju.

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

Sljedeći recept je preuzet iz članak s ovog bloga, čije su upute testirane na djelu. Usput, tamo je također opisana metoda migracije bez muke, međutim, u našem slučaju to jednostavno nije bilo potrebno, pa ga nismo provjeravali. Ako je to kritično za vaš projekt, bit će nam drago čuti rezultate u komentarima.

Prijeđimo na praktični dio. U primjeru koristimo virsh i, sukladno tome, libvirt. Prvo provjerite je li Ceph skup u koji će se podaci migrirati povezan s libvirt:

virsh pool-dumpxml $ceph_pool

Opis bazena mora sadržavati podatke o povezivanju s Cephom s podacima za autorizaciju.

Sljedeći korak je da se LVM slika pretvori u Ceph RBD. Vrijeme izvedbe 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 ostat će LVM slika, što će biti korisno ako migracija VM-a na RBD ne uspije i morate vratiti promjene. Također, kako bismo mogli brzo vratiti promjene, napravimo sigurnosnu kopiju konfiguracijske datoteke virtualnog stroja:

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

... i uredi izvornik (vm_name.xml). Pronađimo blok s opisom diska (počinje linijom <disk type='file' device='disk'> a završava s </disk>) i svesti ga 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. Protokolu source naznačena je adresa skladišta u Ceph RBD (ovo je adresa koja označava naziv Ceph bazena i RBD slike, koja je određena u prvoj fazi).
2. U bloku secret tip je naznačen ceph, kao i UUID tajne za povezivanje s njim. Njegov uuid može se pronaći pomoću naredbe virsh secret-list.
3. U bloku host naznačene su adrese Ceph monitora.

Nakon uređivanja konfiguracijske datoteke i dovršetka pretvaranja LVM u RBD, možete primijeniti izmijenjenu konfiguracijsku datoteku i pokrenuti virtualni stroj:

virsh define $vm_name.xml
virsh start $vm_name

Vrijeme je da provjerite je li virtualni stroj ispravno pokrenut: to možete saznati, na primjer, povezivanjem s njim putem SSH ili putem virsh.

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

lvremove main/$vm_image_name

Zaključak

Sa svim opisanim slučajevima susreli smo se u praksi - nadamo se da će upute pomoći drugim administratorima u rješavanju sličnih problema. Ako imate komentara ili drugih sličnih priča iz vašeg iskustva korištenja Cepha, bit će nam drago vidjeti ih u komentarima!

PS

Pročitajte i na našem blogu:

• «Naše ruke nisu za dosadu: obnavljanje klastera Rook u K8s»;
• «Topu ili ne Topu - to je pitanje»;
• «Rook - “samoposlužno” skladište podataka za Kubernetes»;
• «Stvaranje trajne pohrane s opskrbom u Kubernetesu na temelju Ceph-a".

Izvor: www.habr.com