Příspěvky

1

Software / Re:Šifrování pomocí LUKS, nebo přes ZFS?

« kdy: 29. 12. 2022, 07:00:44 »

Výhoda šifrování na úrovni filesystemu je v případě použití více disků. Pak se buď šifruje každý disk a data se pak šifrují zbytečně vícekrát a nebo se udělá sw raid a ten se pak zašifruje, ale pak se zase přijde o možnost upravit data z druhé kopie když zfs detekuje chybu.

Druhá výhoda je že zfs podporuje raw send. Tedy se pošlou přímo šifrovaná data. Takže můžu mít data uložená na serveru kterému úplně nevěřím, můžu tam dělat kontrolu konzistence scrubem a posílat si inkrementálně další snapshoty ale přitom šifrovací klíč nikdy neopustí můj počítač.

2

Server / Re:ZFS + mysql ničí SSD disky

« kdy: 17. 08. 2022, 21:38:06 »

To je možné. Ale jak říkám, ssd neumí upravit jen konkrétní bity ale musí přepsat celou buňku. Takže i když na to ext4 zapíše 512B tak se na pozadí provede nejspíš mnohem větší zápis, jen s tím rozdílem že do smartu se započítá těch 512B.

3

Server / Re:ZFS + mysql ničí SSD disky

« kdy: 17. 08. 2022, 16:50:40 »

V principu ano, pokud chcete potlačit write amplification tak je nejlepší mít recordsize stejný jako ashift. Ale někdy je lepší to mít vyšší a potlačit to kompresí. U recordsize 128kB pokud změníte jeden 4kB blok tak se na disk zapíše na jiné místo modifikovaných 128kB, to může být důvod toho množství zápisu ve smartu.

Jen pro zajímavost: kolik vám šetří ta deduplikace? Vzhledem k tomu že se to deduplikuje po blocích a Vy máte bloky 4kB velké tak deduplikační tabulka bude hodně velká a je otázka jestli se vyplatí.

Pokud dáte zpool status -D tak ve výpisu bude podobný řádek:
dedup: DDT entries 188696705, size 601B on disk, 194B in core

Když vynásobíte počet záznamů velikostí jednoho záznamu (on disk, in core) tak dostanete kolik zabírá deduplikační tabulka na disk, respektivě v ram.

Tohle může být příčina toho že je to pomalé. Je možné že deduplikační tabulka zabírá zbytečně moc ram která by se dala využít efektivněji pro db. A při každém zápisu bloku se musí upravovat počty referencí v tabulce což hodně sníží výkon zápisu.

Ještě bych prověřil jak je nastavená velikost bloku na nvme disku. Většinou nvme disky emulují 512B sektor (kvůli winXP) a to stojí také výkon. Je nesmysl aby aplikace pracovala se sektory o velikosti 4KB aby se pak překládali na 512B sektory které disk tvrdí že používá a přitom interně pracoval opět s 4KB.

Když to vezmu osobně tak pokud připravuji server pro db tak:
1, nastavím na nvme velikost sectoru na 4kB https://wiki.archlinux.org/title/Advanced_Format#Setting_native_sector_size

2, zpool vytvářím s ashift 12 a parametry (předpoklad je že /boot je na ext4 a ne na zfs):
dnodesize=auto (jinak pokud velikost adresáře překroší 512B tak to uloží jako nový blok)
redundant_metadata = most (omezím počet zápisů na metadata)
compression=zstd
xattr=sa (ukládá rozšířené atributy přímo k souboru, zvyšuje výkon při použití např selinuxu)
atime=off
primarycache nechávám zaplou na all

3, mysql dataset vytvářím s recordsize=16k. Mám to ozkoušené že to poskytuje nejlepší výkon a je to doporučováno pro db i v dokumentaci zfs.

4, u mysql nejvíc pomůže vypnout doublewrite, ale je možné zapnout ještě další optimalizace. Docela pěkně to má popsané letsencrypt když migroval na zfs: https://github.com/letsencrypt/openzfs-nvme-databases#mariadb-settings

4

Server / Re:ZFS + mysql ničí SSD disky

« kdy: 17. 08. 2022, 14:25:54 »

1, já bych to moc nehrotil. Vzhledem k tomu jak funguje zápis na NAND buňky a wear leveling v SSD tak ssd interně dělá cow stejně jako zfs. Akorát IO co udělá zfs počítá do smartu a ty co dělá samo ne. Takže nejspíš rozdíl v opotřebení disku nebude tak hrozný jako naznačuje smart.

2, je divné že i při recordsize 4KB by ext4 udělala 25TB zápisu za 6 let a zfs 800TB za rok. To by zfs zapisovalo téměř 200x víc dat než ext4

3, 4kB jako recordsize je málo. Předpokládám že máte ashift 12, tedy velikost bloku také 4kB. Pak ale nefunguje komprese. V zfs funguje komprese tak že se vezme blok (o velikosti maximálně recordsize) a ten se zkomprimuje a pak se uloží do tolika bloků o velikosti ashift kolik je potřeba. Pokud tedy máte recordsize 4kB tak se zkomprimuje na například 2kB ale to se stejně kvůli ashift uloží na 4kB.

Ideální velikost pro mysql je 16kB. Je to dost malá hodnota kdy je write amplification malé a zároveň dost vysoká aby se projevila komprese.


Ještě se zeptám jak se projevuje že je na zfs horší výkon? Jde jen o zápis a nebo i o čtení? Chápu správně že je to mirror z dvou nvme?
Já mám totiž zkušenost že se s zfs dá získat většinou vyšší výkon než s ext4. Samozřejmě záleží podle dat a použití, ale u zápisu většinou pomáhá komprese (průměrná db se kterou pracuji má kompresní poměr kolem 2 s zstd kompresí) a to že se v mysql může vypnout doublewrite.
U čtení pomáhá také komprese a to že data jsou v arc cachi uložena komprimovaně. Tedy pokud mám například 100GB RAM pro cache tak u ext4 tam mám 100GB dat a u zfs 200GB a většinou ještě vyšší hitrate kvůli lepšímu chívání arc cache vs LRU cache.

Samozřejmě jsem se setkal i s případy kdy při migraci na zfs poklesl výkon. Ale byly to většinou extrémní případy typu statisíce malých tabulek v mysql nebo ukládání už komprimovaných dat do mysql. Ale většinou migrace na zfs pomůže.

5

Server / Re:ZFS ARC meta size > 90% meta max size on host - Zabbix alert

« kdy: 30. 05. 2021, 18:59:30 »

ZFS povolí defaultně zabrat metadaty jen 75% ARC cache. Je to proto aby alespoň část cache zůstala pro data.
V tomto případě máte zabráno metadaty 91% prostoru který můžou metadata max zabrat.

Pokud chcete prostor pro metadata zvýšit tak to můžete za běhu upravit v souboru:
/sys/module/zfs/parameters/zfs_arc_meta_limit_percent

a nebo trvale v /etc/modprobe.d/zfs.conf direktivou
options zfs zfs_arc_meta_limit_percent=<hodnota>


Ale tohle varování můžete klidně ignorovat, nejhorší co se může stát je že při zátěži která pracuje častěji s metadaty a ne s daty tak se arc zaplní ze 75% metadaty a zbylých 25% zaberou méně často používaná data takže arc bude mít nižší hitrate než kdyby celý obsahoval metadata. Ale všechno bude fungovat dál.

6

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 17. 03. 2021, 08:21:51 »

V jaké topologii jsou disky? Obecně více mirrorů je na IOPS lepší než jeden raidz.

Je zaplá komprese? Komprese není na zatížení CPU poznat a u DB dociluje kompresního poměru většinou víc než 2 a to už je na výkonu poznat

Zkuste nastavit hodnotu recordsize 16kB. 4KB jsou málo, velikost stránky v mysql je 16kB. Navíc počítám že ashift je nastavený na 12, tedy nejmenší velikost bloku je 4kB a pokud je i recordsize 4kB tak komprese už nemůže ten blok zmenšit a proto se nepoužívá a tím se ztrácí výkon.

Pokud je dost RAM tak bych používal jako engine InnoDB a nastavil dost velký innodb buffer a pro ten dataset s mysql nastavil primarycache=metadata aby nedocházelo k dvojitému cachování v mysql a v zfs.

Protože u zfs nemůže nastat partial write tak se může v mysql vypnout doublewrite, to také přinese nějaký nárust výkonu.

Tohle co jsem uvedl tak by mělo výkonově dostat zfs blízko k výkonu ext4. Jen ještě upozorním že změny hodnot jako je komprese a nebo recordsize se aplikují jen na nová data takže pro změnu existujících dat je ideální poslat si pomocí zfs send ten dataset do nového a pak ten nový jen namountovat na místo původního.

7

Server / Re:Proxmox - výběr vhodné architektury ZFS (upgrade domácího IT)

« kdy: 14. 03. 2021, 22:18:40 »

Dobrý den,

pokud to vezmu postupně:
1, raidz vs mirror
Obecně by se dalo říct že raidz má mírně lepší bandwidth a mirror má lepší IOPS.
U klasického raid5 platí že pokud chceme přečíst malý blok který je jen na jednom disku tak poté nám stačí číst jen z tohoto jednoho disku. ZFS ovšem u všech dat ověřuje konzistenci a checksum je uložen pro celý stripe. Takže pokud chceme přečíst jeden blok z jednoho disku v raidz tak stejně musíme přečíst data i z ostatních abychom mohli ověřit součet.
Proto u mirroru máme teoretickou rychlost čtení <počet_disků>*<rychlost_disku> a u raidz máme 1*<rychlost_nejpomalejšího_disku>

Pěkné porovnání rychlostí různých raidů na zfs je zde:
https://calomel.org/zfs_raid_speed_capacity.html

Pokud to nechcete procházet celé tak jen porovnání 2*mirror vs raidz2
 4x 4TB, 2 striped mirrors,     7.5 TB,  w=226MB/s , rw=53MB/s  , r=644MB/s
 4x 4TB, raidz2 (raid6),        7.5 TB,  w=204MB/s , rw=54MB/s  , r=183MB/s

2, Rozdělení poolů
Zde je to podle preferencí. Já osobně bych udělal, jak píšete, pool pro proxmox, pool a pro zálohy ale jen jeden pool na data. Výkon toho datového poolu bude mnohem lepší když v něm budou všechny VDEV a ne jen polovina a druhá polovina v testovacím poolu.
A ten pool pro data bych dělal takhle:
disky bych dával v mirroru. Nejen že se to dá krásně rozšířit ale pokud by jste chtěl dev pool tak jen zavoláte "zpool split"
https://openzfs.github.io/openzfs-docs/man/8/zpool-split.8.html
a z poolu máte najednou 2 pooly kde druhý pool má naprosto stejná data i nastavení, můžete na něm cokoliv testovat a pak až nebude potřeba tak ho jen zrušíte a pomocí "zpool attach" postupně předěláte první zpool aby byl opět redundatní.

backup pool bych udělal jako raidz1 ze 3 disků. Je to odolné proti výpadku jednoho disku a to mi přijde že je na zálohy dostatečné (samozřejmě záleží jaké Vy máte nároky na zálohy).
Backup pool osobně využívám jen pro případ že by hlavní pool odešel takže pro mě pokud odejde backup pool a produkce zůstane funkční tak to není problém protože data mám na produkčním poolu ve snapshotech.
A šance že se rozbije produkce a zároveň odejdou 2 ze 3 disků na backupu je mizivá.

3, rozdělení na datasety, opět je to jen můj názor:
Rád si data uspořádávám logicky do datasetů. Nic mě to nestojí a můžu pro každá data nastavit přesně to co jim vyhovuje.
Například:
iso dataset - recorsize například 1M (stejně většina čtení bude sekvenční), primarycache=metadata (předpokládám že isa se nečtou tak často aby mělo smysl je cachovat v RAM)
dataset pro obrázky,hudbu: asi bych asi nastavil secondarycache=none. To že se malý obrázek zacachuje v RAM mi nevadí ale asi nechci aby mi opotřebovával SSD a cachoval se na ssd když u toho obrázku o výkon načtení tolik nejde.
Pokud jsou videa v jednotné cestě tak bych pro ně udělal zvlášť dataset, pokud jsou namíchané mezi obrázky tak bych pro ně dataset nedělal.
ostatní datasety pro osobní data bych udělal analogicky.

4, jak využít SSD
Na obou ssd bych udělal malý oddíl pro SLOG, stačí 4GB a ten dal v mirroru pro proxmox pool.
Jen pro vysvětlení: oproti na různých forech opakovanému omylu tak stačí SLOG jen hodně malý. SLOG drží synchronně zapisovaná data co jsou v RAM aby mohlo zfs potvrdit že data jsou na bezpečném uložišti. Takže velikost slogu nemá smysl větší než velikost zápisové části RAM v ZFS a to je 4GB. Data se ale při normálním provozu z SLOGU nečtou. Z něj by se čeli jen při pádu systemu když má data ještě v RAM. Takže i když je častý omyl že SLOG zrychlí zápis na pool tak SLOG sníží jen latenci zápisu protože půjde zápis potvrdit dřív ale bandwith je pořád omezený tím pomalým úložištěm.

SLOG pro data pool bych asi nedával. Nevím sice co tam půjde za provoz ale moc synchronních zápisů tam předpokládám nebude (v porovnání s SQL serverem na proxmoxu) a pro asynchronní zápisy se nepoužije.

Cache bych pro datový pool nedával při vatvoření poolu, podle toho co píšete tak NAS má dost RAM, takže možná bude hitrate dobrý i bez cache.

Pokud by se ukázalo že L2ARC není potřeba a hitrate je dobrý i bez ní tak bych zvážil z toho udělat special device v mirroru a dal jí pro datový pool.
https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954

Pak by právě malé soubory jako metadata byly na rychlém SSD takže se uleví plotnám a podle povahy dat by šlo pro dataset kde jsou osobní data a maily nastavit parametr "special_small_blocks".
To dělá to že soubory menší než nastavená hodnota se budou preferovaně ukládat na special device.
Tedy malé náhodné zápisy a čtení které dělá plotnám největší problém přesunete na ssd které s tím nemá problém.
Jen pozor že na to  zatímco slog a L2ARC se dá odebrat kdykoliv tak special device ne (teda jo, ale až v zfs2.0)

5, pár rychlých poznámek na konec
při vytváření poolu nastavit ashift=12, jinak bude problém když se přidá disk co má fyzicky 4k sektory
vypnout ashift, zfs je CoW filesystem a aktualizace času přístupu k souboru znamená změnit data v hlavičce -> tedy kvůli CoW udělat kopii hlavičky jinde. To vede k velké fragmentaci
vždy zapnout kompresi - zfs detekuje nekomprimovatelná data a ty nekomprimuje a dekomprese samotná je stejně hodně optimalizovaná a na vytížení CPU není poznat.
snapshot nezabírá při vytvoření skoro žádné místo a i pak jsou v něm jen změněné bloky a dobře chrání proti smazání dat omylem. Je mnohem lepší namountovat pár minut starý snapshot a jen obnovit smazanou složku nebo dokonce udělat roolback celého snapshotu při větším smazání, než si tahat data den stará data z backup serveru.
zfs send je mnohem lepší na zálohování než rsync. Oproti rsyncu nepřenáší změněné soubory ale jen změněné bloky.


Vytvoření zpoolu a nastavení zfs stejně nejvíc záleží na uložených datech a osobních preferencích ale snad Vám tyto rady pomůžou.

8

Server / Re:Vhodné úložiště pro LXC

« 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

9

Studium a uplatnění / Re:Certifikáty z IT kurzů

« kdy: 27. 07. 2019, 14:36:12 »

Popravdě moc nechápu ty rady na dokončení alespoň nějaké VŠ. Zaměstnavatele nejvíc zajímá co umíš a ne kolik máš papírů. Je jasný že nedokončit VŠ není pro start kariery dobré ale jít studovat 3 roky nějaký jednoduchý obor aby člověk měl papír je zbytečné. Pokud se budeš hlásit do práce v IT a zaměstnavateli s velkou slávou předložíš diplom že jsi dokončil studium Filozofie umění a budeš myslet že to bude nějaká výhoda při pohovoru tak jen zaměstnavatele rozesměješ.
To samé jako doporučovat dělat si školu při práci. Na jednu stranu to není špatný způsob jak získat titul ale na druhou stranu, po 3 letech co budeš dělat v IT tak budoucího zaměstnavatele bude zajímat víc co jsi dělal ty 3 roky než jakou jsi udělal školu. Vím ze své zkušenosti že čím delší doba od dokončení školy tím méně zaměstnavatele škola zajímá.

Jediný co je problem je že na začátku kariery budeš muset hodně přesvědčovat zaměstnance že něco umíš, ale teď je lidí nedostatek a firma nic neriskuje - když se neosvědčíš tak se s tebou rozloučí ještě ve zkušebce, je jen na tobě aby jsi ukázal že něco umíš.

Jen doplněk - opravdu si myslíte že Ajťák bez VŠ je v 60 zralý na předčasný důchod a někdo s VŠ bude pořád vážený odborník? Já se na VŠ učil assembler a věřím že za 30 let až mi bude 60 tak nikdo nebude ani vědět co to je. Prostě buď držíte krok s dobou a nebo máte smůlu bez ohledu na nějaký papír. V 60 letech za vás víc mluví to co jste dělat těch 35 let před tím než to jestli jste se před 40 lety místo učení na zkoušku věnoval holce.

10

Server / 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.