I když jsem LVM pro úložiště KVM nezkoušel, použil jsem ho pro funkci stínového objemu samby a mohu vám říci jednu věc:výkon byl propastný.
Každý snímek vyžaduje další zápis. Pokud máte jeden základní svazek a 4 snímky, množství zápisů, které jde na jednotky, se při zápisu na základní svazek vynásobí 5.
Pokud jde o vaše konkrétní otázky:
- LVM zmrazí souborový systém během vytváření snímku (zastaví zápis, vyprázdní mezipaměť, provede snímek, obnoví zápis)
- jak jsem řekl, je to velmi pomalé
- Ano, poškozený základní svazek způsobí, že všechny snímky jsou nepoužitelné, a co víc, pokud vám dojde místo vyhrazené pro rozdílové snímky, snímek bude také uložen
- Ano, snímek můžete pořídit
Bohužel znám pouze 3 systémy, které dobře fungují se snímky:NetApp WAFL, ZFS a btrfs. Pokud systém není kritický, může btrfs stát za pokus.
Je naprosto v pořádku to udělat. Co neděláte chceme, aby se zároveň používal rodič snímku (originál nebo zdroj, nebo jak to nazvat), protože to způsobí násobení IO (v tom měl Hubert pravdu, je to jen snadno zabránit tím, že nebudete neustále používat zdrojovou hlasitost).
Pokud máte jednu hlavní instalaci operačního systému na LVM a uděláte snímek čtyřikrát, nebudete mít velkou penalizaci IO, protože zapisujete pouze do jednotlivých svazků snímků. Samozřejmě to není zdarma, ale ani jiné formy snapshotování na jiných souborových systémech nebo virtuálních discích. Vždy někde něco stojí.
Další věc, ve které má Hubert pravdu, je, že musíte přemýšlet o velikosti svých snímků. Budete se chtít ujistit, že svazky snímků mohou pokračovat v zápisu. Úplný svazek snímků věci špatně rozbije. Bezpečným způsobem, jak tomu zabránit, je vytvořit svazek snímků na stejnou velikost (nebo větší) než je zdrojový svazek. Tímto způsobem však ztrácíte výhodu využití menšího místa na disku.
Víte, že obrázky qemu jsou také schopné pořizovat snímky?
Tenké zajišťovací LVM by mělo být považováno za hlavní možnost pro tento scénář, zde v roce 2019.
Výkon tenkých LV je dobrý a fungují jako samostatné svazky, takže po vytvoření snímku se nemusíte starat o péči a integritu originálu (může být poškozen, smazán atd., aniž by to ovlivnilo snímek).
Zájem OP o „snímek zabírá málo místa“ není ve skutečnosti spokojen s tradičním LVM, protože prostor musí být předem alokován monolitickým způsobem pro každý snímek. Ale tenké LV jsou alokovány jako řídké soubory a ve skutečnosti zabírají málo místa.
Kompromisem pro tenké zajišťování je to, že dostupný prostor v tenkém fondu musí být monitorován stejně jako souborový systém, aby nedošlo k jeho zaplnění. Linuxové distribuce mají obvykle démony, kteří to monitorují a posílají varování nebo provádějí akci, když se thinpool dosáhne téměř plného stavu.