Při použití Cephu jako síťového úložiště v projektech s různou zátěží se můžeme setkat s různými úkoly, které se na první pohled nezdají jednoduché nebo triviální. Například:
- migrace dat ze starého Cephu na nový s částečným využitím předchozích serverů v novém clusteru;
- řešení problému alokace místa na disku v Ceph.
Při řešení takových problémů čelíme potřebě správně odstranit OSD bez ztráty dat, což je zvláště důležité při práci s velkým množstvím dat. O tom bude řeč v článku.
Níže popsané metody jsou relevantní pro jakoukoli verzi Ceph. Kromě toho bude zohledněna skutečnost, že Ceph může ukládat velké množství dat: aby se zabránilo ztrátě dat a dalším problémům, budou některé akce „rozděleny“ na několik dalších.
Předmluva o OSD
Protože dva ze tří diskutovaných receptů jsou věnovány OSD (), než se vrhneme na praktickou část - stručně o tom, co to v Cephu je a proč je tak důležité.
Nejprve je třeba říci, že celý cluster Ceph se skládá z mnoha OSD. Čím více jich je, tím větší objem volných dat v Cephu. Odtud je to snadné pochopit hlavní funkce OSD: Ukládá data objektů Ceph v souborových systémech všech uzlů clusteru a poskytuje k nim síťový přístup (pro čtení, zápis a další požadavky).
Na stejné úrovni se parametry replikace nastavují kopírováním objektů mezi různými OSD. A zde se můžete setkat s různými problémy, jejichž řešení bude diskutováno níže.
Případ č. 1. Bezpečně odeberte OSD z clusteru Ceph bez ztráty dat
Potřeba odebrat OSD může být způsobena odstraněním serveru z clusteru – například jeho nahrazením jiným serverem – což se stalo nám, což vedlo k napsání tohoto článku. Konečným cílem manipulace je tedy extrahovat všechna OSD a mons na daném serveru, aby mohla být zastavena.
Pro pohodlí a abychom se vyhnuli situaci, kdy při provádění příkazů uděláme chybu v označení požadovaného OSD, nastavíme samostatnou proměnnou, jejíž hodnotou bude číslo OSD, které se má smazat. Zavolejme jí ${ID} — zde a níže tato proměnná nahrazuje číslo OSD, se kterým pracujeme.
Podívejme se na stav před zahájení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
Chcete-li zahájit odstranění OSD, budete muset provést hladce reweight na to na nulu. Tímto způsobem snižujeme množství dat v OSD jejich vyvážením do jiných OSD. Chcete-li to provést, spusťte 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ž do nuly.
Je vyžadováno hladké vyváženíaby nedošlo ke ztrátě dat. To platí zejména v případě, že OSD obsahuje velké množství dat. Abyste se ujistili, že po provedení příkazů reweight vše proběhlo v pořádku, můžete to dokončit ceph -s nebo v samostatném spuštění okna terminálu ceph -w aby bylo možné sledovat změny v reálném čase.
Když je OSD „vyprázdněno“, můžete pokračovat standardní operací a odstranit ji. Chcete-li to provést, přeneste požadované OSD do stavu down:
ceph osd down osd.${ID}Pojďme „vytáhnout“ OSD z clusteru:
ceph osd out osd.${ID}Zastavme službu OSD a odpojme její oddíl ve FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Odebrat OSD z :
ceph osd crush remove osd.${ID}Smažeme uživatele OSD:
ceph auth del osd.${ID}A nakonec odeberme samotné OSD:
ceph osd rm osd.${ID}Poznámka: Pokud používáte verzi Ceph Luminous nebo vyšší, lze výše uvedené kroky odstranění OSD zredukovat na dva příkazy:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Pokud po provedení výše popsaných kroků spustíte příkaz ceph osd tree, pak by mělo být jasné, že na serveru, kde byla práce provedena, již nejsou OSD, pro které byly provedeny 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
Po cestě si všimněte, že stav clusteru Ceph půjde do HEALTH_WARNa také uvidíme pokles počtu OSD a množství dostupného místa na disku.
Níže budou popsány kroky, které budou vyžadovány, pokud chcete server úplně zastavit a podle toho jej odebrat z Ceph. V tomto případě je důležité si to zapamatovat Před vypnutím serveru musíte odstranit všechny OSD na tomto serveru.
Pokud na tomto serveru nezbývají žádné další OSD, pak po jejich odstranění musíte server vyloučit z mapy OSD hv-2spuštěním následujícího příkazu:
ceph osd crush rm hv-2
Odstranit mon ze serveru hv-2spuštěním níže uvedeného příkazu na jiném serveru (tj. v tomto případě na hv-1):
ceph-deploy mon destroy hv-2Poté můžete server zastavit a zahájit následné akce (opětovné nasazení atd.).
Případ č. 2. Distribuce místa na disku v již vytvořeném clusteru Ceph
Druhý příběh začnu předmluvou o PG (). Hlavní úlohou PG v Ceph je primárně agregovat objekty Ceph a dále je replikovat v OSD. Vzorec, pomocí kterého můžete vypočítat požadované množství PG, je in Ceph dokumentace. Tato problematika je tam diskutována i na konkrétních příkladech.
Takže: jedním z běžných problémů při používání Ceph je nevyvážený počet OSD a PG mezi fondy v Ceph.
Za prvé, kvůli tomu může nastat situace, kdy je v malém fondu specifikováno příliš mnoho PG, což je v podstatě iracionální využití místa na disku v clusteru. Za druhé, v praxi existuje vážnější problém: přetečení dat v jednom z OSD. To znamená, že klastr nejprve přejde do stavu HEALTH_WARN, a pak HEALTH_ERR. Důvodem je to, že Ceph při výpočtu dostupného množství dat (můžete to zjistit pomocí MAX AVAIL ve výstupu příkazu ceph df pro každý fond zvlášť) je založeno na množství dostupných dat v OSD. Pokud alespoň v jednom OSD není dostatek místa, nelze zapisovat žádná další data, dokud nebudou data správně distribuována mezi všechna OSD.
Stojí za to objasnit, že tyto problémy jsou z velké části rozhodnuty ve fázi konfigurace clusteru Ceph. Jedním z nástrojů, který můžete použít, je . S jeho pomocí se jasně vypočítá potřebné množství PG. Můžete se k němu však uchýlit i v situaci, kdy se shlukuje Ceph již nakonfigurován nesprávně. Zde je vhodné upřesnit, že v rámci oprav budete s největší pravděpodobností muset snížit počet PG a tato funkce není dostupná ve starších verzích Ceph (objevila se pouze ve verzi ).
Představme si tedy následující obrázek: cluster má status HEALTH_WARN kvůli nedostatku místa v jednom z OSD. To bude indikováno chybou HEALTH_WARN: 1 near full osd. Níže je uveden algoritmus, jak se z této situace dostat.
Nejprve je třeba distribuovat dostupná data mezi zbývající OSD. Podobnou operaci jsme již provedli v prvním případě, kdy jsme uzel „vypustili“ – jen s tím rozdílem, že nyní budeme muset mírně zmenšit reweight. Například až 0.95:
ceph osd reweight osd.${ID} 0.95Tím se uvolní místo na disku v OSD a opraví se chyba ve zdraví ceph. Jak již bylo zmíněno, tento problém se vyskytuje hlavně kvůli nesprávné konfiguraci Ceph v počátečních fázích: je velmi důležité provést rekonfiguraci, aby se v budoucnu neobjevila.
V našem konkrétním případě se vše sešlo takto:
- hodnota příliš vysoká
replication_countv jednom z bazénů, - příliš mnoho PG v jednom fondu a příliš málo v jiném.
Využijme již zmíněnou kalkulačku. Jasně ukazuje, co je potřeba zadat a v zásadě na tom není nic složitého. Po nastavení potřebných parametrů získáme následující doporučení:
Poznámka: Pokud nastavujete cluster Ceph od začátku, další užitečnou funkcí kalkulačky je generování příkazů, které vytvoří fondy od začátku s parametry uvedenými v tabulce.
Poslední sloupec vám pomůže s navigací - Doporučený počet PG. V našem případě je užitečný i druhý, kde je uveden parametr replikace, jelikož jsme se rozhodli změnit násobitel replikace.
Nejprve tedy musíte změnit parametry replikace - to se vyplatí udělat jako první, protože snížením násobiče uvolníme místo na disku. Při provádění příkazu si všimnete, že se dostupné místo na disku zvětší:
ceph osd pool $pool_name set $replication_size
A po jeho dokončení změníme hodnoty parametrů pg_num и pgp_num takto:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberJe to důležité,: musíme změnit počet PG postupně v každém fondu a neměnit hodnoty v jiných fondech, dokud varování nezmizí "Zhoršená redundance dat" и "n-počet str. degradováno".
Pomocí výstupů příkazů můžete také zkontrolovat, zda vše proběhlo v pořádku ceph health detail и ceph -s.
Případ č. 3. Migrace virtuálního počítače z LVM na Ceph RBD
V situaci, kdy projekt využívá virtuální stroje nainstalované na pronajatých serverech s holýma rukama, často vyvstává problém úložiště odolného proti chybám. Je také velmi žádoucí, aby v tomto úložišti bylo dostatek místa... Další častá situace: na serveru je virtuální stroj s lokálním úložištěm a potřebujete rozšířit disk, ale není kam jít, protože není volné místo na disku na serveru.
Problém lze vyřešit různými způsoby - například migrací na jiný server (pokud existuje) nebo přidáním nových disků na server. Ale není to vždy možné, takže migrace z LVM na Ceph může být vynikajícím řešením tohoto problému. Výběrem této možnosti také zjednodušíme další proces migrace mezi servery, protože nebude nutné přesouvat lokální úložiště z jednoho hypervizoru na druhý. Jediný háček je v tom, že budete muset zastavit VM, zatímco se práce provádí.
Následující recept je převzat z , jehož pokyny byly testovány v praxi. Mimochodem, je tam popsána i metoda bezproblémové migrace, ale v našem případě to prostě nebylo potřeba, takže jsme to nekontrolovali. Pokud je to pro váš projekt kritické, budeme rádi, když se o výsledcích dozvíme v komentářích.
Přejděme k praktické části. V příkladu používáme virsh a v souladu s tím libvirt. Nejprve se ujistěte, že fond Ceph, do kterého budou data migrována, je připojen k libvirt:
virsh pool-dumpxml $ceph_poolPopis fondu musí obsahovat data připojení k Ceph s autorizačními daty.
Dalším krokem je převedení obrazu LVM na Ceph RBD. Doba provedení závisí především na velikosti obrázku:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_namePo převodu zůstane obraz LVM, což bude užitečné, pokud se migrace virtuálního počítače na RBD nezdaří a budete muset vrátit změny. Abychom mohli rychle vrátit změny, udělejme zálohu konfiguračního souboru virtuálního počítače:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... a upravit originál (vm_name.xml). Najdeme blok s popisem disku (začíná řádkem <disk type='file' device='disk'> a končí s </disk>) a zredukujte jej do následující podoby:
<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>Podívejme se na některé detaily:
- K protokolu
sourceje uvedena adresa úložiště v Ceph RBD (jedná se o adresu označující název fondu Ceph a obrázek RBD, který byl stanoven v první fázi). - V bloku
secretje uveden typcepha také UUID tajného klíče, který se k němu má připojit. Jeho uuid lze najít pomocí příkazuvirsh secret-list. - V bloku
hostjsou uvedeny adresy na monitory Ceph.
Po úpravě konfiguračního souboru a dokončení převodu LVM na RBD můžete použít upravený konfigurační soubor a spustit virtuální počítač:
virsh define $vm_name.xml
virsh start $vm_name
Je čas zkontrolovat, zda se virtuální stroj spustil správně: zjistíte to například tak, že se k němu připojíte přes SSH nebo přes virsh.
Pokud virtuální počítač funguje správně a nenašli jste žádné další problémy, můžete odstranit obraz LVM, který se již nepoužívá:
lvremove main/$vm_image_nameZávěr
Se všemi popsanými případy jsme se setkali v praxi – doufáme, že návod pomůže vyřešit podobné problémy i dalším správcům. Pokud máte připomínky nebo jiné podobné příběhy ze svých zkušeností s používáním Cephu, budeme rádi, když je uvidíme v komentářích!
PS
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com