Tipy a triky pre prácu s Cephom v rušných projektoch

Tipy a triky pre prácu s Cephom v rušných projektoch

Pri používaní Ceph ako sieťového úložiska v projektoch s rôznou záťažou sa môžeme stretnúť s rôznymi úlohami, ktoré sa na prvý pohľad nezdajú jednoduché alebo triviálne. Napríklad:

  • migrácia dát zo starého Cephu na nový s čiastočným využitím predchádzajúcich serverov v novom klastri;
  • riešenie problému alokácie diskového priestoru v Ceph.

Pri riešení takýchto úloh čelíme potrebe správneho odstránenia OSD bez straty údajov, čo je obzvlášť dôležité pri práci s veľkým množstvom údajov. O tom sa bude diskutovať v článku.

Metódy opísané nižšie sú relevantné pre akúkoľvek verziu Ceph. Okrem toho sa bude brať do úvahy skutočnosť, že Ceph môže uchovávať veľké množstvo údajov: aby sa predišlo strate údajov a iným problémom, niektoré akcie budú „rozdelené“ na niekoľko ďalších.

Predslov o OSD

Keďže dva z troch diskutovaných receptov sú venované OSD (Démon ukladania objektov), pred ponorením do praktickej časti - stručne o tom, čo to v Cephe je a prečo je to také dôležité.

V prvom rade treba povedať, že celý klaster Ceph pozostáva z mnohých OSD. Čím viac ich je, tým väčší je objem voľných dát v Ceph. Odtiaľto je ľahké pochopiť hlavná funkcia OSD: Ukladá dáta objektu Ceph na súborových systémoch všetkých uzlov klastra a poskytuje k nim sieťový prístup (na čítanie, zápis a iné požiadavky).

Na rovnakej úrovni sa parametre replikácie nastavujú kopírovaním objektov medzi rôznymi OSD. A tu sa môžete stretnúť s rôznymi problémami, ktorých riešenia budú uvedené nižšie.

Prípad č.1. Bezpečne odstráňte OSD z klastra Ceph bez straty údajov

Potreba odstrániť OSD môže byť spôsobená odstránením servera z klastra – napríklad jeho nahradením iným serverom – čo sa stalo nám, čo viedlo k napísaniu tohto článku. Konečným cieľom manipulácie je teda extrahovať všetky OSD a mons na danom serveri, aby sa to dalo zastaviť.

Pre pohodlie a aby sme sa vyhli situácii, kedy sa pri vykonávaní príkazov pomýlime pri uvádzaní požadovaného OSD, nastavíme samostatnú premennú, ktorej hodnotou bude číslo OSD, ktoré sa má vymazať. Zavolajme jej ${ID} — tu a nižšie takáto premenná nahrádza číslo OSD, s ktorým pracujeme.

Pozrime sa na stav pred začatím práce:

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

Na spustenie odstránenia OSD budete musieť hladko vykonať reweight na to na nulu. Týmto spôsobom znížime množstvo údajov v OSD ich vyvážením do iných OSD. Ak to chcete urobiť, spustite nasledujúce príkazy:

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

... a tak ďalej až do nuly.

Vyžaduje sa hladké vyváženieaby nedošlo k strate údajov. To platí najmä vtedy, ak OSD obsahuje veľké množstvo údajov. Aby ste sa uistili, že po vykonaní príkazov reweight všetko prebehlo v poriadku, môžete to dokončiť ceph -s alebo v samostatnom spustení okna terminálu ceph -w aby bolo možné sledovať zmeny v reálnom čase.

Keď sa OSD „vyprázdni“, môžete pokračovať v štandardnej operácii a odstrániť ju. Za týmto účelom preneste požadované OSD do stavu down:

ceph osd down osd.${ID}

Poďme „vytiahnuť“ OSD z klastra:

ceph osd out osd.${ID}

Zastavme službu OSD a odpojme jej oddiel vo FS:

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

Odstráňte OSD z CRUSH mapa:

ceph osd crush remove osd.${ID}

Vymažeme používateľa OSD:

ceph auth del osd.${ID}

A nakoniec odstránime samotné OSD:

ceph osd rm osd.${ID}

Poznámka: Ak používate verziu Ceph Luminous alebo vyššiu, vyššie uvedené kroky odstránenia OSD možno zredukovať na dva príkazy:

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

Ak po dokončení vyššie opísaných krokov spustíte príkaz ceph osd tree, potom by malo byť jasné, že na serveri, na ktorom bola vykonaná práca, už nie sú OSD, pre ktoré boli vykonané vyššie uvedené operácie:

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

Po ceste si všimnite, že stav klastra Ceph bude pokračovať HEALTH_WARNa tiež uvidíme pokles počtu OSD a množstva dostupného miesta na disku.

Nasleduje popis krokov, ktoré budú potrebné, ak chcete server úplne zastaviť a podľa toho ho odstrániť z Ceph. V tomto prípade je dôležité pamätať na to Pred vypnutím servera musíte odstrániť všetky OSD na tomto serveri.

Ak na tomto serveri nezostali žiadne ďalšie OSD, potom po ich odstránení musíte server vylúčiť z mapy OSD hv-2spustením nasledujúceho príkazu:

ceph osd crush rm hv-2

remove mon zo servera hv-2spustením nižšie uvedeného príkazu na inom serveri (t.j. v tomto prípade na hv-1):

ceph-deploy mon destroy hv-2

Potom môžete server zastaviť a začať s následnými akciami (opätovné nasadenie atď.).

Prípad č.2. Distribúcia diskového priestoru v už vytvorenom Ceph klastri

Druhý príbeh začnem predslovom o PG (Skupiny umiestnení). Hlavnou úlohou PG v Ceph je predovšetkým agregovať objekty Ceph a ďalej ich replikovať v OSD. Vzorec, pomocou ktorého môžete vypočítať požadované množstvo PG, je v príslušný oddiel Ceph dokumentácia. Táto problematika sa tam rozoberá aj na konkrétnych príkladoch.

Takže: jedným z bežných problémov pri používaní Ceph je nevyvážený počet OSD a PG medzi fondmi v Ceph.

Po prvé, kvôli tomu môže nastať situácia, keď je v malom poole špecifikovaných príliš veľa PG, čo je v podstate iracionálne využitie miesta na disku v klastri. Po druhé, v praxi existuje vážnejší problém: pretečenie údajov v jednom z OSD. To znamená, že klaster najprv prejde do stavu HEALTH_WARN, a potom HEALTH_ERR. Dôvodom je to, že Ceph pri výpočte dostupného množstva údajov (môžete to zistiť pomocou MAX AVAIL vo výstupe príkazu ceph df pre každý fond samostatne) je založený na množstve dostupných údajov v OSD. Ak aspoň v jednom OSD nie je dostatok miesta, nie je možné zapisovať žiadne ďalšie údaje, kým nebudú správne rozdelené medzi všetky OSD.

Stojí za to objasniť, že tieto problémy sa vo veľkej miere rozhoduje vo fáze konfigurácie klastra Ceph. Jedným z nástrojov, ktoré môžete použiť, je Ceph PGCalc. S jeho pomocou sa jasne vypočíta požadované množstvo PG. Môžete sa k nemu však uchýliť aj v situácii, keď sa zhlukuje Ceph nakonfigurovaný nesprávne. Tu je vhodné objasniť, že v rámci opravy budete s najväčšou pravdepodobnosťou musieť znížiť počet PG a táto funkcia nie je dostupná v starších verziách Ceph (objavila sa iba vo verzii Nautilus).

Predstavme si teda nasledujúci obrázok: klaster má status HEALTH_WARN kvôli nedostatku miesta v jednej z OSD. Bude to indikované chybou HEALTH_WARN: 1 near full osd. Nižšie je uvedený algoritmus, ako sa dostať z tejto situácie.

Najprv musíte distribuovať dostupné údaje medzi zostávajúce OSD. Podobnú operáciu sme už vykonali v prvom prípade, keď sme uzol „vypustili“ – len s tým rozdielom, že teraz budeme musieť mierne zmenšiť reweight. Napríklad až 0.95:

ceph osd reweight osd.${ID} 0.95

Tým sa uvoľní miesto na disku v OSD a opraví sa chyba v zdraví ceph. Ako už bolo spomenuté, tento problém sa vyskytuje hlavne v dôsledku nesprávnej konfigurácie Ceph v počiatočných fázach: je veľmi dôležité vykonať rekonfiguráciu, aby sa v budúcnosti neobjavila.

V našom konkrétnom prípade to všetko dopadlo takto:

  • príliš vysoká hodnota replication_count v jednom z bazénov,
  • príliš veľa PG v jednom bazéne a príliš málo v druhom.

Využime už spomínanú kalkulačku. Jasne ukazuje, čo treba zadať a v zásade nie je nič zložité. Po nastavení potrebných parametrov dostaneme nasledujúce odporúčania:

Poznámka: Ak nastavujete Ceph klaster od začiatku, ďalšou užitočnou funkciou kalkulačky je generovanie príkazov, ktoré vytvoria pooly od začiatku s parametrami uvedenými v tabuľke.

Posledný stĺpec vám pomáha pri navigácii - Odporúčaný počet PG. V našom prípade je užitočný aj druhý, kde je uvedený parameter replikácie, keďže sme sa rozhodli zmeniť násobiteľ replikácie.

Takže najprv musíte zmeniť parametre replikácie - to sa oplatí urobiť ako prvé, pretože znížením násobiteľa uvoľníme miesto na disku. Keď sa príkaz vykoná, všimnete si, že dostupné miesto na disku sa zvýši:

ceph osd pool $pool_name set $replication_size

A po jeho dokončení zmeníme hodnoty parametrov pg_num и pgp_num takto:

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

Je to dôležité,: musíme zmeniť počet PG postupne v každej oblasti a nemeniť hodnoty v iných oblastiach, kým varovania nezmiznú "Degradovaná redundancia údajov" и "n-počet str. degradovaných".

Pomocou výstupov príkazov môžete tiež skontrolovať, či všetko prebehlo v poriadku ceph health detail и ceph -s.

Prípad č.3. Migrácia virtuálneho počítača z LVM na Ceph RBD

V situácii, keď projekt využíva virtuálne stroje nainštalované na prenajatých serveroch typu bare-metal, často vzniká problém úložiska odolného voči chybám. Je tiež veľmi žiaduce, aby v tomto úložisku bolo dosť miesta... Ďalšia bežná situácia: na serveri je virtuálny stroj s lokálnym úložiskom a potrebujete rozšíriť disk, ale nie je kam ísť, pretože tam nie je voľné miesto na disku zostávajúce na serveri.

Problém možno vyriešiť rôznymi spôsobmi - napríklad migráciou na iný server (ak existuje) alebo pridaním nových diskov na server. Nie je to však vždy možné, takže migrácia z LVM na Ceph môže byť vynikajúcim riešením tohto problému. Výberom tejto možnosti zároveň zjednodušíme ďalší proces migrácie medzi servermi, pretože nebude potrebné presúvať lokálne úložisko z jedného hypervízora na druhý. Jediným háčikom je, že budete musieť zastaviť VM počas vykonávania práce.

Nasledujúci recept je prevzatý z článok z tohto blogu, ktorého pokyny boli testované v praxi. Mimochodom, je tam popísaný aj spôsob bezproblémovej migrácie, no v našom prípade to jednoducho nebolo potrebné, tak sme to nekontrolovali. Ak je to pre váš projekt kritické, budeme radi, ak sa o výsledkoch dozvieme v komentároch.

Prejdime k praktickej časti. V príklade používame virsh a teda libvirt. Najprv sa uistite, že fond Ceph, do ktorého sa budú údaje migrovať, je pripojený k libvirt:

virsh pool-dumpxml $ceph_pool

Popis fondu musí obsahovať údaje o pripojení k Ceph s údajmi o autorizácii.

Ďalším krokom je, že sa obraz LVM skonvertuje na Ceph RBD. Čas vykonania závisí predovšetkým od veľkosti obrázka:

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

Po konverzii zostane obraz LVM, čo bude užitočné, ak migrácia VM na RBD zlyhá a budete musieť vrátiť zmeny. Aby sme mohli rýchlo vrátiť zmeny späť, urobme si zálohu konfiguračného súboru virtuálneho počítača:

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

... a upraviť originál (vm_name.xml). Nájdite blok s popisom disku (začína riadkom <disk type='file' device='disk'> a končí s </disk>) a zredukujte ho na nasledujúci tvar:

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

Pozrime sa na niektoré detaily:

  1. K protokolu source je uvedená adresa úložiska v Ceph RBD (toto je adresa označujúca názov fondu Ceph a obrázok RBD, ktorý bol určený v prvej fáze).
  2. V bloku secret je uvedený typ ceph, ako aj UUID tajného kľúča, ktorý sa má k nemu pripojiť. Jeho uuid možno nájsť pomocou príkazu virsh secret-list.
  3. V bloku host sú uvedené adresy na monitory Ceph.

Po úprave konfiguračného súboru a dokončení konverzie LVM na RBD môžete použiť upravený konfiguračný súbor a spustiť virtuálny počítač:

virsh define $vm_name.xml
virsh start $vm_name

Je čas skontrolovať, či sa virtuálny stroj spustil správne: zistíte to napríklad tak, že sa k nemu pripojíte cez SSH alebo cez virsh.

Ak virtuálny počítač funguje správne a nenašli ste žiadne iné problémy, môžete odstrániť obraz LVM, ktorý sa už nepoužíva:

lvremove main/$vm_image_name

Záver

So všetkými popísanými prípadmi sme sa stretli v praxi – dúfame, že návod pomôže ostatným správcom vyriešiť podobné problémy. Ak máte pripomienky alebo iné podobné príbehy z vašich skúseností s používaním Ceph, budeme radi, ak ich uvidíte v komentároch!

PS

Prečítajte si aj na našom blogu:

Zdroj: hab.com

Pridať komentár