Vhodné úložiště pro LXC

Vhodné úložiště pro LXC
« kdy: 26. 07. 2019, 06:09:55 »
Dobrý den,

prosil bych o radu. Provozuji několik (přibližně 10) kontejnerů v lxc a chtěl bych poradit jaké úložiště proto zvolit. Jde mi o to že ve všech kontejnerech je stejná verze debianu takže většinu souborů mají společnou. ( Vzhedem k tomu že většinu konfigurace mam v ansiblu tak nemám problem je všechny přeinstalovat kdyby bylo potřeba )
Rád bych je provozoval na btrfs kvůli snapshotům ale nebráním se čemukoliv jinému.

Napadlo mě

1, udělat base kontejner jako subvolume na btrfs a od něj dělat snapshoty ale podle toho jak chápu princip tak jakmile bych nějaký kontejner aktualizoval tak všechny nové soubory by už nebyly jen reflink na původní ale fyzicky by se uložily na disku. Takže časem by jsem na tom byl stejně jako teď na ext4 protože při aktualizaci kontejneru bych ho vyřadil z množiny těch co sdílí společná data. Takže např po roce užívání by stejné datové bloky sdíleli jen soubory co se za rok nezměnily ale přitom ty systemy by byly na 90% totožné.

2, použít kompresi zabudovanou v btrfs protože jsem myslel že při zaplé kompresi bude X stejných souborů mít velikost jednoho + režie ale po pár testech jsem zjistil že komprese v btrfs probíhá per-file takže to mi také nepomůže.

3, použít deduplikaci. To mi připadá jako nejlepší řešení protože pokud před updatem jsou všechny kontejnery snapshotem základního a updatem se u změněných souborů zruší reflinky na sdílené datové bloky ale deduplikací si zajistím že pokud se mi např aktualizoval ve všech kontejnerech htop tak po deduplikaci všechny soubory htopu budou ukazovat na stejné datové bloky.
Jestli jsem to teda pochopil správně tak tohle by mohlo problém vyřešit.


Nyní ještě jeden dotaz, jak mít snapshoty na úložišti? Pokud by každý kontejner byl vlastní subvolume tak poté by se lehko dělala obnova jednoho kontejneru do staršího snapshotu ale v tomhle případě nevím jak se bude chovat deduplikace když by musela probíhat napříč různými subvolume.
Pokud bych měl vše na jednom subvolume tak by deduplikace určitě fungovala ale zase obnovu kontejneru bych musel dělat pomocí např pomocí rsync a nemohl bych použít na to dělané nástroje jako např "snapper rollback".

Ještě poznamenám že vím že LXD umožňuje výběr backendu pro kontejnery ale bohužel LXD nemůžu kvůli kombinaci OS a architektury nainstalovat. (a navíc rád rozumím jak něco interně funguje a rád se v tom hrabu  :)  )

Budu rád za jakékoliv rady a přeji pěkný den.
« Poslední změna: 26. 07. 2019, 08:10:13 od Petr Krčmář »


Re:Vhodné úložiště pro LXC
« Odpověď #1 kdy: 27. 07. 2019, 20:02:10 »
Tak jsem provedl pár měření a nejlepší kombinace mi vyšla použití deduplikace a online komprese pomocí zstd.

Tohle je příklad kdy jsem na btrfs oddíl zkopíroval z LXC 2 kontejnery - v obou kontejnerech bylo apache s podobnou konfigurací.
Tohle je výsledek: deduplikace mi snížila zabrané místo z 804MB na 410MB což docela odpovídá očekávání a zapnutí komprese (zstd) snížilo obsazení na 188MB. Takže velikost 2 kontejnerů je 45% velikosti jednoho na ext4, to není špatný.
Processed 28129 files, 7854 regular extents (15299 refs), 17401 inline.
Type       Perc     Disk Usage   Uncompressed Referenced 
TOTAL       45%      188M         410M         804M       
none       100%       37M          37M          67M       
zstd        40%      151M         373M         736M


Zde jsem na btrfs nakopíroval všech 9 kontejnerů, jediné co mají společné je OS, ale v každém jsou jiné aplikace (nginx, apache, nextcloud, nsd, nfs, samba). Tohle je stav po nakopírování: Komprese snížila objem dat na polovinu což je samo o sobě dost dobré. Vypadá to že komprese 50% je přibližně průměr pro kompresi kontejnerů.
Processed 142932 files, 71636 regular extents (71636 refs), 88602 inline.
Type       Perc     Disk Usage   Uncompressed Referenced 
TOTAL       50%      2.0G         4.0G         4.0G       
none       100%      976M         976M         976M       
zstd        34%      1.0G         3.1G         3.1G   


Zde jsem zapnul deduplikaci (vzhledem k tomu že se používám blokovou kompresi tak pokud 2 bloky byly stejné před kompresí tak budou stejné i po ní):
Processed 142932 files, 25821 regular extents (76942 refs), 88602 inline.
Type       Perc     Disk Usage   Uncompressed Referenced 
TOTAL       51%      735M         1.3G         4.0G       
none       100%      372M         372M         968M       
zstd        34%      362M         1.0G         3.1G 

Takže vidíme že deduplikace dokázala snížit objem dat přibližně na třetinu. Takže kombinací komprese a deduplikace jsme se dostali na 18% původního objemu, to není vůbec špatné.

Jen poznámka: deduplikaci jsem dělal po 4K blocích protože defaultní velikost je 128k a ta nenajde tolik stejných bloků. Zde je výsledek při použití defaultní velikosti bloku.
Processed 142961 files, 58035 regular extents (75279 refs), 88605 inline.
Type       Perc     Disk Usage   Uncompressed Referenced 
TOTAL       49%      1.0G         2.1G         4.0G       
none       100%      319M         319M         431M       
zstd        41%      755M         1.7G         3.6G

David

  • ***
  • 108
    • Zobrazit profil
Re:Vhodné úložiště pro LXC
« Odpověď #2 kdy: 27. 07. 2019, 20:22:09 »
Já rád používám ZFS. Umí snapshoty, komprimaci, mohu mu dát NVMe write cache (SLOG).

Re:Vhodné úložiště pro LXC
« Odpověď #3 kdy: 28. 07. 2019, 12:11:45 »
Diky za hezkou otazku a shrnuti. Jsem zhruba v podobnem stadiu a to co jste sem nahodil mi rozhodne usetri/usetrilo par hodin.

Nejsem si uplne jisty zdali vam to k necemu bude nebo ne, ale ostree mi pripada ze by mohlo pomoct v tom co pozadujete. Prijde mi, ze se vam libi Xen templates a chtel byste neco podobneho pro kontejnery (vesmes mam nejaky podobny pozadavek).


Vsak posudte sam:

https://ostree.readthedocs.io/en/latest/
https://ostree.readthedocs.io/en/latest/manual/related-projects/ (doporucuju alespon prolistovat)

Re:Vhodné úložiště pro LXC
« Odpověď #4 kdy: 05. 08. 2019, 09:28:21 »
za mě také ZFS. To je filesystém v kterém je momentálně budoucnost