🥇Tipy & triky pro práci s Ceph v zatížených projektech

Používáním Ceph jako síťového úložiště v různě zatížených projektech se můžeme setkat s různými úkoly, které se na první pohled nemusí zdát jednoduché nebo triviální. Například:

migrace dat ze starého Ceph do nového s částečným využitím předchozích serverů v novém clusteru;
řešení problému distribuce diskového prostoru v Ceph.

Při řešení takových úkolů se setkáváme s nutností správně odebrat OSD bez ztráty dat, což je obzvlášť důležité při velkých objemech dat. O tom bude pojednávat tento článek.

Způsoby uvedené níže jsou aktuální pro jakékoli verze Ceph. Dále bude zohledněno, že v Ceph může být uložen velký objem dat: pro zajištění ochrany před ztrátou dat a dalšími problémy budou některé úkony „rozděleny“ na více jiných.

Úvod o OSD

Jelikož dva z tří zvažovaných receptů se týkají OSD (Object Storage Daemon), před ponořením do praktické části — stručně o tom, co to vůbec je v Ceph a proč je to tak důležité.

V první řadě je třeba říci, že celý Ceph cluster se skládá z mnoha OSD. Čím více jich je, tím větší je volný prostor pro data v Ceph. Odtud je snadné pochopit hlavní funkci OSD: ukládá objekty Ceph na souborové systémy všech uzlů clusteru a poskytuje k nim síťový přístup (pro čtení, zápis a další požadavky).

Na této úrovni jsou také nastaveny parametry replikace kopírováním objektů mezi různými OSD. A zde se mohou vyskytnout různé problémy, o jejichž řešení bude dále řeč.

Případ č. 1. Bezpečné odebrání OSD z clusteru Ceph bez ztráty dat

Potřeba odebrání OSD může být způsobena vyřazením serveru z clusteru — například za účelem jeho výměny za jiný server, což se stalo i u nás a sloužilo jako podnět pro napsání tohoto článku. Cílem těchto manipulací je tedy odebrat všechna OSD a mony na tomto serveru, aby bylo možné jej zastavit.

Pro pohodlí a vyloučení situace, kdy bychom se při provádění příkazů spletli v určení požadovaného OSD, nastavíme samostatnou proměnnou, jejíž hodnota bude odpovídat číslu odstraňovaného OSD. Nazveme ji ${ID} — tato proměnná zde a dále nahrazuje číslo OSD, se kterým pracujeme.

Podíváme se na stav před začátkem prací:

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

Pro iniciaci odstranění OSD je třeba provést postupné převážení na nulu. Tímto způsobem snižujeme množství dat v OSD přerozdělením na jiné OSD. Pro tento úkol se vykonávají následující příkazy:

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

… a tak dále až k nule.

Postupné vyvážení je nezbytné, aby nedošlo ke ztrátě dat. To platí zejména v případě, že OSD obsahuje velké množství dat. Abychom se ujistili, že po provedení příkazů převážení vše proběhlo úspěšně, lze provést ceph -s nebo v samostatném okně terminálu spustit ceph -w abychom mohli sledovat změny v reálném čase.

Když je OSD "vyprázdněná", můžeme přistoupit k standardnímu procesu jejího odstranění. Pro tento účel převedeme požadované OSD do stavu down:

ceph osd down osd.${ID}

"Vytáhneme" OSD z clusteru:

ceph osd out osd.${ID}

Zastavíme službu OSD a odpojíme jej připravený systém:

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

Odstraníme OSD z CRUSH mapy:

ceph osd crush remove osd.${ID}

Smažeme uživatele OSD:

ceph auth del osd.${ID}

A nakonec odstraníme samotné OSD:

ceph osd rm osd.${ID}

Poznámka: pokud používáte verzi Ceph Luminous nebo novější, výše uvedené úkony pro odstranění OSD lze shrnout do dvou příkazů:

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

Pokud po provedení výše uvedených akcí vykonáte příkaz ceph osd tree, mělo by být vidět, že na serveru, kde byly operace provedeny, již nejsou žádné OSD, na kterých se prováděly výše uvedené operace:

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

Současně poznamenáme, že stav clusteru Ceph přejde do HEALTH_WARN, a také uvidíme pokles počtu OSD a objemu dostupného diskového prostoru.

Dále budou popsány úkony, které budou potřeba, pokud chcete zcela zastavit server a tím pádem jej odstranit z Ceph. V takovém případě je důležité pamatovat, že před vypnutím serveru je nutné vyjmout všechny OSD na tomto serveru.

Pokud na tomto serveru již nejsou žádné OSD, pak po jejich odstranění je třeba vyloučit ze seznamu OSD server hv-2, provedením následujícího příkazu:

ceph osd crush rm hv-2

Odstraňujeme mon ze serveru hv-2, spuštěním níže uvedeného příkazu na jiném serveru (tedy v tomto případě na hv-1):

ceph-deploy mon destroy hv-2

Po tom je možné zastavit server a přistoupit k dalším akcím (jeho opětovnému nasazení a podobně).

Případ č. 2. Rozdělení diskového prostoru v již vytvořeném clustere Ceph

Druhou historii začnu s úvodem o PG (Placement Groups). Hlavní úlohou PG v Ceph je především agregace objektů Ceph a jejich další replikace v OSD. Vzorec, pomocí něhož lze vypočítat potřebný počet PG, se nachází v příslušné sekci dokumentaci Ceph. Tam je tato otázka také podrobně rozebrána na konkrétních příkladech.

Takže: jedním z běžných problémů během provozu Ceph je nevyvážený počet OSD a PG mezi pooly v Ceph.

Za prvé, může vzniknout situace, kdy je uvedeno příliš velké množství PG v malé velikosti poolu, což je v podstatě neefektivním využitím diskového prostoru v clustere. Za druhé, v praxi vzniká vážnější problém: přetečení dat v jednom z OSD. To vede k tomu, že cluster nejprve přejde do stavu HEALTH_WARN, a poté i HEALTH_ERR. Příčinou je, že Ceph při výpočtu dostupného objemu dat (ten je možné zjistit podle MAX AVAIL ve výstupu příkazu ceph df pro každý pool zvlášť) se opírá o objem dostupných dat v OSD. Pokud v jednom OSD nebude dostatek místa, pak již nebude možné zapisovat data, dokud nebudou data správně rozdělena mezi všechna OSD.

Je dobré upřesnit, že tyto problémy se v větší míře řeší již v etapě konfigurace clustere Ceph. Jedním z nástrojů, kterého lze využít, je Ceph PGCalc. Pomocí něj lze názorně vypočítat potřebný počet PG. Nicméně, můžete ho využít i v situaci, kdy je cluster Ceph již špatně nastaven. Je dobré k tomu dodat, že v rámci oprav vám pravděpodobně bude potřeba snížit počet PG, a tato možnost není k dispozici ve starých verzích Ceph (objevila se až ve verzi Nautilus).

Představme si tedy následující obraz: cluster má stav HEALTH_WARN kvůli tomu, že v jednom z OSD dochází místo. O tom bude svědčit chyba HEALTH_WARN: 1 near full osd. Níže je uveden algoritmus, jak se dostat z této situace.

Nejprve je třeba rozdělit existující data mezi zbytek OSD. Podobnou operaci jsme již provedli v prvním případě, kdy jsme "vysušovali" uzel — s tím rozdílem, že nyní bude třeba nepatrně snížit převážení. Například na 0.95:

ceph osd reweight osd.${ID} 0.95

Tímto se uvolní diskový prostor v OSD a oprava chyb v ceph health. Jak již bylo řečeno, tento problém většinou vzniká z důvodu nesprávného nastavení Ceph na počátku: je velmi důležité provést rekonstrukci, aby se v budoucnu neobjevoval.

V našem konkrétním případě to vše spočívalo v:

příliš vysoké hodnotě replication_count v jednom z poolů,
příliš vysokém počtu PG v jednom poolu a příliš nízkém — v druhém.

Vyjdeme z již zmíněného kalkulátoru. Je v něm názorně ukázáno, co je potřeba zadat, a v zásadě není nic složitého. Zadaním požadovaných parametrů dostaneme následující doporučení:

Poznámka: pokud nastavujete Ceph cluster od nuly, další užitečnou funkcí kalkulátoru bude generace příkazů, které vytvoří pooly od nuly s parametry uvedenými v tabulce.

Pomáhá se orientovat poslední sloupec — Suggested PG Count. V našem případě je užitečný také druhý, ve kterém je uveden parameter replikace, protože jsme se rozhodli změnit i násobitel replikace.

Takže nejprve bude třeba změnit parametry replikace — to by se mělo dělat na prvním místě, protože snížením násobitele uvolníme diskový prostor. V průběhu provádění příkazu bude vidět, že hodnota dostupného diskového prostoru se bude zvyšovat:

ceph osd pool $pool_name set $replication_size

A po jeho dokončení — změníme hodnoty parametrů pg_num a pgp_num následujícím způsobem:

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

Je důležité: musíme postupně každém poolu změnit počet PG a neměnit hodnoty v jiných poolech, dokud nezmizí varování "Degraded data redundancy" a "n-number of pgs degraded".

Zkontrolovat, že vše proběhlo úspěšně, lze také podle výstupů příkazů ceph health detail a ceph -s.

Případ č. 3. Migrace virtuálního stroje z LVM do Ceph RBD

V situaci, kdy se v projektu používají virtuální stroje nainstalované na pronajatých serverech bare-metal, se často objevuje otázka o spolehlivém úložišti. Také by bylo velmi žádoucí, aby bylo v tomto úložišti dostatek místa... Jiná běžná situace: existuje virtuální stroj s lokálním úložištěm na serveru a je nutné rozšířit disk, ale není kam, protože na serveru nezbývá volné místo.

Problém lze vyřešit různými způsoby — například migrací na jiný server (pokud nějaký existuje) nebo přidáním nových disků na server. Ale ne vždy je to možné, proto může být migrace z LVM do Ceph skvělým řešením tohoto problému. Výběrem této varianty také zjednodušujeme další proces migrace mezi servery, protože není třeba přesouvat lokální úložiště z jednoho hypervizoru na druhý. Jedinou komplikací je, že bude nutné zastavit VM na dobu potřebnou k provedení práce.

Jako následující recept je použita článek z tohoto blogu, jehož pokyny byly vyzkoušeny v praxi. Mimochodem, tam také popisují způsob bezproblémové migrace, ale v našem případě to jednoduše nebylo potřeba, proto jsme to neprověřovali. Pokud je to však kritické pro váš projekt — rádi se dozvíme o výsledcích v komentářích.

Přejdeme k praktické části. V příkladu používáme virsh a podle toho libvirt. Nejprve se ujistěte, že je připojený Ceph pool, do kterého budou data migrací, k libvirt:

virsh pool-dumpxml $ceph_pool

V popisu poolu by měly být údaje o připojení k Ceph s údaji pro autorizaci.

Dalším krokem je, že se LVM obrázek převede na Ceph RBD. Doba provedení závisí především na velikosti obrazu:

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

Po konverzi zůstane LVM obrázek, který bude užitečný v případě, že se migrace VM do RBD nezdaří a bude nutné se vrátit k předchozím změnám. Také — pro možnost rychlého návratu změn — uděláme zálohu konfiguračního souboru virtuálního stroje:

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

… a upravíme originál (vm_name.xml). Najdeme blok s popisem disku (začíná řádkem <disk type='file' device='disk'> a končí na </disk>) a převedeme ho do následující podoby:

Podíváme se na některé detaily:

V protokolu source se uvádí adresa úložiště v Ceph RBD (jedná se o adresu s názvem Ceph-pool a RBD obrazu, která byla určena v prvním kroku).
V bloku secret se uvádí typ ceph, stejně jako UUID tajného klíče pro připojení k němu. Jeho uuid lze zjistit pomocí příkazu virsh secret-list.
V bloku host se uvádějí adresy monitorů Ceph.

Po úpravě konfiguračního souboru a dokončení konverze LVM na RBD lze použít upravený konfigurační soubor a spustit virtuální stroj:

virsh define $vm_name.xml
virsh start $vm_name

Je nejvyšší čas zkontrolovat, zda virtuální stroj správně naběhl: to lze zjistit například připojením přes SSH nebo prostřednictvím virsh.

Pokud virtuální stroj funguje správně a neobjevili jste další problémy, můžete odstranit LVM obraz, který již není používán:

lvremove main/$vm_image_name

Závěr

Se všemi uvedenými případy jsme se setkali v praxi – doufáme, že instrukce pomohou i dalším administrátorům vyřešit podobné problémy. Pokud máte jakékoliv poznámky nebo další podobné příběhy z používání Ceph – budeme rádi, když je uvidíme v komentářích!