Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

17.5.2014 13:45 | Přečteno: 5802× | | poslední úprava: 17.5.2014 16:44

Stará NASka praská ve švech. Disky v ní jsou téměř 5 let staré a jsou v RAID5. Hodně blbá kombinace. Navíc na začátku jsem učinil pár nepříliš šťastných rozhodnutí ohledně rozdělení, které mě nyní iritují. Část vyhrazená pro raw iSCSI je příliš malá takže se mezi ostatními daty válejí obří iSCSI soubory a podobně. Ostatně neznám nikoho, kdo měl v tomto směru dobrý odhad, pominu-li šťastlivce, kteří si můžou dovolit mít všechno na jednom svazku. Teoreticky by se daly udělat nějaké shrinky/expandy/přesuny... jenže mě se do experimentů na 7 TiB svazku, navíc z větší části nezálohovaném, příliš nechce.

Zrodil se tedy projekt úložiště pro takové to malé, domácí ukládání v normální domácnosti. No... normální. Pouze pokud se tak dá nazvat dvoučlenná domácnost, kde router i v noci indikuje 25 statických IP adres a 12 přidělených přes DHCP.

Požadavky

1. Kapacita 14 TiB+. Současné úložiště má 7 TiB a princip zdvojnásobování kapacity každých 5 let se mi v minulosti osvědčil.
2. Odolnost proti výpadku dvou disků.
3. Nezávislost na hardwaru, zejména na hardwarových RAIDech (o pseudohardwarových raději ani nemluvě). Když zaklepe základní deska křemíkovými bačkorami, chci mít možnost přehodit disky do jiného počítače a jedním příkazem data připojit. Nechci shánět po všech čertech stejný řadič nebo laborovat jak jsou uložená metadata abych to nějak zprovoznil přes md.
4. Chci online deduplikaci. Zálohuji ESXi virtuální stroje a deduplikace mi udělá transparentně a bezproblémově rozdílové zálohy. Je rozdíl skladovat 150 GiB záloh virtuálních mašin každý den nebo 150 MB rozdílových bloků.
5. Chci snapshoty. Chci je levné a chci je rychlé i když jich bude hodně. A nechci předem vyhrazovat místo, které může snapshot zabrat. Chci snapshot pracovního adresáře každých 10 minut a chci je skladovat týden, 1000 snapshotů tedy nesmí činit potíže.
6. Chci kontrolní součty dat. Kdybych nezažil silent data corruption (zapíšete A, přečtete B přičemž disk ani řadič nehlásí žádný problém), tak bych na tom třeba netrval. Ale zažil. Dvakrát. Jednou vinou řadiče, který prostě občas na disk poslal chybná data a jednou jsem viděl phantom read. Byl požadován sektor X a byl přečten a předán sektor Y. Nezjištěno, kdo za to mohl, asi SSD.
7. Nechci už nikdy přenikdy řešit situaci, že tady je místa málo a tady zase zbytečně hodně a řešení sice existuje, je ale netriviální a trvá dlouho.
8. Cena. Nechci zbytečně přeplácet, to je jasné.
9. Ocenil bych, kdyby volume manager rozuměl datům na disku. Aby se třeba při rebuildu RAIDU na svazku zaplněném z 10 % řešilo jen těch 10 % a ne zbytečně i prázdné místo. To je výhoda z hlediska času ale i bezpečnosti dat. Vypadne disk z RAIDu, dáte nový, spustí se rebuild, který trvá půl dne, zvýšená zátěž na disky zvyšuje pravděpodobnost, že odejde další. A Murphyho zákony všichni známe. Opět jsem viděl na vlastní oči.
10. Mohla by se hodit komprese. Zejména pokud by se dala aplikovat pouze na část disku.

Výběr SW řešení

1. md + nějaký souborový systém : splňuje 1, 2, 3, 8. 10 při použití souborového systému, který to umí. Populární NASky jako Synology nebo QNAP jsou na tom podobně jen je třeba vyhodit bod 8.
2. HW raid + nějaký souborový systém nad tím: splňuje 1, 2. 10 při použití souborového systému, který to umí.
3. LVM + nějaký souborový systém: splňuje 1, 2, 3, 5, 8. . 10 při použití souborového systému, který to umí. Bod 5 je teoreticky splněn ale kdo zkoušel v praxi více snapshotů, ten ví, že de facto není. Bod 7 také není uspokojivě vyřešen.
4. BTRFS: plní 1, 2 (ovšem RAID6 nemá scrubbing), 4, 5 (ovšem jen out of the band- po zápisu je nutné spustit utilitku, která provede deduplikaci), 6, 7, 8, 9, 10
5. ZFS: plní 1, 2, 3, 4, 5, 6, 7, 8 (s výhradami, vyžaduje SPOUSTU paměti), 9, 10

Je vidět, že jasný vítěz zde sice není, nicméně použitelní kandidáti zůstali pouze 2. Je to věci osobní volby. BTRFS má navíc výhodu čistější licenci a je vyvíjeno přímo v jádře. ZFS mi zase přijde jako mnohem vyspělejší. A to nakonec převážilo a rozhodl jsem se pro tento systém.

ZFS se dá použít v OpenIndiana nebo jiné variaci OpenSolarisu, FreeBSD nebo nějaké jeho nadstavbě (FreeNAS) ale také v Linuxu díky projektu http://zfsonlinux.org/. Rozhodl jsem se pro Linux, protože ho znám nejlépe.

Výběr hardware

Rozsah rešerše, které musí člověk podstoupit, když si chce koupit pitomý disk, je neuvěřitelný. Nebudu tím zatěžovat, vydalo by to na samostatný článek. Jako vítěz mi vyšel 3TB WD RED. Oproti třeba WD Green má trojnásobný MTBF. Je to sice číslo cucané z prstu ale při takovém rozdílu by to už něco mohlo znamenat. Navíc rozumí tomu, že poběží v RAIDu a že má tedy jen omezený čas na reakci. Některé disky se pokoušejí přečíst sektor třeba minutu. Řadič pak oprávněně označí celý takový disk jako vadný. Má nízkou spotřebu. Zkrátka z celého startovního pole těch levných šunkoidních disků mi vyšel nejlépe. 3TB varianta je (prý) méně poruchová než 4TB. Z požadované velikosti úložiště a kapacity disku a dvojité patity je zřejmé, že jsem musel pořídit 8 kusů.

Ke koupi disků jedna poznámka- je lepší nakoupit disky z různých sérii. Minimalizuje se tím pravděpodobnost, že se do pole dostanou disky zatížené stejnou výrobní vadou.

Základní desku je lepší koupit rovnou s potřebným počtem SATA portů. Rozšiřující karty jsou problematičtější a ve výsledku většinou i dražší. Je třeba si ověřit podporu řadiče. V případě Linuxu to většinou není problém, s FreeBSD to bývá horší a ESXi ve verzi 5.5 je vyloženě vybíravý a podporu pro většinu běžných řadičů nemá. Další důležitou vlastností je síťovka. Opět je lepší koupit rovnou vhodnou integrovanou kartu a nedokupovat pak zbytečně diskrétní síťovku protože ty bývají zbytečně drahé. Tady bych to charakterizoval takhle: Intel >>> Realtec > hromada hnoje > Broadcom. Pro ZFS potřebujeme hodně pamětí (odůvodnění bude v příští části, doporučuje se 1GiB paměti na 1TiB dat pokud nehodláte hojně použivat deduplikaci. V tom případě ještě mnohem více) a je tedy vhodné zakoupit desku s alespoň čtyřmi sloty. Paměť nejraději ECC. Když už máme checksumy v ZFS tak ať nám to nekazí chyby paměti. Procesor úsporný ale pro kompresi RAIDZ2 (což je ZFS název pro RAID6 s několika fíčurami navíc) to zase úplná plečka nemůže být. Výhodou je interní USB. Zbytek (jako integrovaná zvukovka, firewire a podobné blbosti) je nepodstatný. Já chtěl použit 2600K, který se mi válel v šuplíku spolu s 4x4GiB moduly. Tím jsem byl ve výběru desky značně omezen. Kvalitní desky dělá Supermicro. Já nakonec skončil s MSI Z77A-GD65. Je tam Intel síťovka, ASM1062 řadič pro dva dodatečné SATA porty, je tam tedy celkově 8 SATA portů, umí použít výstup "grafické karty" v procesoru což snižuje spotřebu a náklady na grafickou kartu. Současně to není deska tak úplně z "dolní poličky" takže má o něco málo kvalitnější součástky (s certifikací Military Class III :-p ).

Nastavení BIOSu, příprava disků, rozchození ZFS v Linuxu, konfigurace... v příští části.

       

Komentáře

[victor8]

Super, tesim sa na dalsiu cast, prave staviam nieco podobne (akurat mensie, len 9TB RAID6) nad Microserverom N40L, akurat som sa este nerozhodol ci ist do ZFS alebo ostat pri osvedcenej kombinacii devicemapperu + klasickeho linux fs.

Nebojis sa stability ZFS nad linuxom? (predsalen je mimo kernelu)...

[R]

Ja by som sa tiez bal pouzivat filesystem, ktory nie je sucastou jadra.

[R]

Ten procesor nepodporuje ECC. Vid http://ark.intel.com/products/52214

[typo]

1)cte se to pekne blbe

2)nikde nevidim zalozni zdroj

3)chybi celkova cena a navratnost v porovnanim s nejakym cloudem

[Šangala]

Ta trojka je teda dost úlet - srovnávat koše s baňama.

[Heron]

Dobrý článek, těším se na pokračování. U mě na 8TB úložiště loni vyhrál BTRFS, rád si přečtu o praktických zkušenostech s ZFS na Linuxu. (ZFS jsem zvažoval také, ale pouze na FreeBSD.)

[Jerry]

Spravu o domaci sit mas s tim co popisujes zrejme na plny uvazek :) Kdyz budes silazovat pouze tva vlastni legalni "dulezita" data, tak by ti stacily 2x1TB disky v mirroru, nebo se mylim ? :)

[Max]

Jeden čas jsem měl pod křídlem cca 50 soukromých pc a nebylo to nic zabijáckého.
Teď mám v jobu pod křídlem cca 300pc a je to relativně bez práce, na full time to rozhodně není a člověk má čas řešit servery, nové služby, apod.
Zdar Max

[Jerry]

Reagoval jsem na dvouclenou domacnost, temer 40 aktivnich IP adres, proste no comment :) Autor by se mel jeste zamyslet nad GEO NAS, nekdy staci malo, aby se nerozbitne reseni rozbilo :)

[Max]

Píšeš, že chceš ECC, ale vybereš CPU, co ECC neumí. Nevím, zda se něco změnilo, dlouho jsem na to nekoukal, ale dřív Intel na desktopu byl jasně bez šance na ECC, AMD na tom bylo mnohem líp.
Jeden čas se houfně nakupoval "Intel Xeon E3-1230V2" a dával se do MSI desek - výkon jak i7, cena jak i5, možnost ECC a bez, pro většinu zbytečné, grafické části.
Zdar Max

[Petr Tomášek]

Kde píše něco o ECC?

IMHO tam píše o tom, že chce filesystem, co ukládá checksumy souborů (kryptografický hash a ne nějaké blbé crc)...

[helb]

Paměť nejraději ECC. Když už máme checksumy v ZFS tak ať nám to nekazí chyby paměti.

[miho]

Pišu také, že jsem použil tento procesor z důvodu, že jsem ho už měl. Zkrátka ekonomické rozhodnutí. To nic nemění na faktu, že doporučuji ECC řešení.

[Tom]

no my meli smulu znamy koupil 3TB red a po sedmi mesicich NAS skolaboval na vadnem sektoru... ale je pravda ze RED je porad lepsi nez GREEN rada

[Dreit]

Dodal bych, že Blue řada je na tom stejně jako Green

[Sten]

Vadném sektoru jednoho disku? To se stává všem výrobcům. Taky proto existuje RAID.

[Bhua]

Mam 2600K v hlavni workstation, do NASu bych ho nedal, neni z nejuspornejsich. Asi neco na Atomu v mini-itx.

[Jezekus]

Moc pekne tesim se na pokracovani

Nejaky podobny servrik na domaci zvykani jsem resitl a nakonec jsem pouzi AsRock C2750D4I procesor je celkem schopny a usporny, ECC RAM, IPMI, sitovky Intel, jsem s tim zatim spokojen.

[Ondra]

autor se nikde nezminil, ze by mel penize na rozhazovani.

[Jezekus]

Ja zas nemel v supliku i5-2600K

[snajpa]

Pouzivame ZoL in production, tak o nem trochu vim a muzu rict, ze kdyz si das pozor na par veci, bude bezet v pohode. Bohuzel BTRFS podle mne urovne ZFS nikdy nedosahne, uz jenom proto, ze btrfs je zas "po linuxovsku" ladeny na maly instance a vyvijeny na noteboocich, kdezto nad ZFS da actually provozovat (a spravovat) server (ne orezavatko).
Rovnou muzes sahnout po nejakem stabilnim distru (= se ZFS nechces bezet na vzdy nejnovejsi vanille) a aktualnim git HEAD ZFS a SPL, release 0.6.2 je strasne starej a zabugovanej.
Kdyby tenhle portal za neco jeste stal, i bych se tu na blogu rozepsal, protoze se ZoL mam opravdu dost zkusenosti, o ktere stoji se podelit... Jenom musi byt s kym (mistni banda zarucene kazi chut sem cokoliv inteligentnejsiho psat...)

[snajpa]

Jinak off-top-of-my-head muzu rict, ze pokud nad tim chces bezet iSCSI, musis prijit na to, jak na iSCSI initiatoru vynutit sector size stejny, jako je block size ZVOL na targetu, jinak zacnes delat read-modify-write misto jenom write pro prepsani bloku (iSCSI standardne pouziva sector size 512B a to je problem, ZVOLy jsou efektivni az tak od 8k block size).
Dal se urcite vyplati limitovat ARC size (nejlepsi zacit od malych hodnot a propracovat se nahoru, kam az to zveda hitrate), zapnout kompresi, nepouzivat deduplikaci, nastavit zfs_txg_timeout na vic jak 5s (jinak zbytecne syncuje) a pokud mozno nikdy neobsazovat vic jak cca 75% mista (je to copy-on-write FS a tak je potreba se k tomu tak chovat).
Kdyby nahodou aktualni ZoL git head nesel pouzit, tu https://github.com/vpsfreecz jsou nase forky, ktere mame in production a jsou overene (aspon s RHEL6/OpenVZ kernelem).

[snajpa]

Ctu ten tvuj zapisek jeste jednou, jak pises "chci deduplikaci", tak to mozna jeste nevis, ale nechces, za zadnou cenu. Teda pokud tim nechces deduplikovat jenom pa GB, ale chces tim i efektivne neco prohnat. Dedup je pametove rozezrana neefektivni blbost, to je spis v kategorii "udelali jsme, protoze to jde", ne proto, ze by to melo uzitecnost (az na nekolik use-casu, ktery tvuj ale neni).
Naopak kompresi nemas duvod nepouzivat na vsechno, je rychla (obzvlast lzjb) - ze ji ani nepoznas, na disk se komprimovane ukladaji jenom data, u kterych se zjisti dobry kompresni pomer, nekomprimuji se nuly a tak ... neni to tupa komprese, ale je to navrzene proto, aby se to dalo pouzivat. V praxi u vpsFree to znamena, ze minimalne na zalohovacim poli nam komprese kompenzuje kapacitni ztratu za RAID-Z (tzn. kompresni pomer aspon 1.3 a lepsi).

[miho]

Díky za rady a doporučení. Myslím, že zálohy ESXi jsou právě pro deduplikaci docela vhodným kandidátem. Denní zálohy mají 150 GiB ale mají od předchozí zálohy jen málo změn (desítky MiB). Zatím jsem nezjistil, zda s tím nemíchá komprese. Dedup ratio se zda se nedá zjistit pro datastore ale jen pro celý pool takže konkrétní číslo nemám. Teoreticky by mohla být úspora až 1:1000.

Samozřejmě si jsem vědom, že je třeba hlídat velikost DDT. Je škoda, že ten poměr nejde nastavit lépe, já vlastně ARC jako cache dat nepotřebuji protože víc, než dá to pole i bez cache stejně ven přes gigabit nedostanu.

[snajpa]

No ne, ta dedup je fakt spatna vec, myslim, ze na to budes akorat nadavat... Ale teda kdyz uz, tak mej potom aspon 1 GB RAM na kazdej TB na poolu se zapnutym dedupem. Nicmene pro to, co rikas, se hodi mnohem vic vykoumat, jak pri zalohovani toho esxi to donutit nemenit bloky, co se shodujou s puvodnima. O tom nemam ani paru, vmware neznam.

[miho]

Zjistil jsem, že při kopírování dat do datasetů, které nemají zapnutý dedup velikost DDT neroste (a není tedy pravda co se občas píše, že se deduplikuje vůči celému poolu ale jen vůči datasetům s dedupem) takže by to nemělo být tak kritické. 1 GiB na 1 TiB mám tak jako tak. Pool ma něco přes 16 TiB a paměti mám 16 GiB. V případě krize rozšířitelné na 32 GiB. Je ovšem fakt, že by to stálo tolik jako rozdíl mezi 3TB a 4TB disky, měl bych ~6 TB místa navíc a nemusel bych asi řešit dedup

[snajpa]

A co se tyce REDu, co mam zkusenost, jsou asi levne proto, ze nejsou moc testovane. Jelikoz z cca 50ti nam 3 (z jinych varek) odesly do tydne/dvou, ale ostatni zatim drzi, bych rekl, ze se asi pocita s tim, ze si jich clovek koupi vic a kdyz to odchazi, tak se k tomu chova jako ke spotrebnimu zbozi, tzn. jde to do kose (reklamace tak levneho disku se nemusi vyplatit ani zakaznikovi, natoz dodavateli).

[Josef Kufner]

Nebylo by lepší to nechat nekomprimované, aby byla deduplikace efektivnější?

[snajpa]

Jestli se blok deduplikuje komprimovany nebo ne je uplne jedno, rozhoduje chcecksum dat. Jediny usecase, kde nema smysl kompresi zapinat, jsou medialni soubory a obecne spatne komprimovatelna data, u nich se stejne vetsinou ulozi puvodni nekomprimovana verze, protoze pomer vyjde spatne.

[Josef Kufner]

Otázkou však je, zda po změně jednoho bloku nedojde ke změně i následujícího bloku. Například kvůli tomu, že se nová data povedlo lépe zkomprimovat a zbytek souboru se posune.

[Chulda]

A dává smysl zálohovat celá VM? Není rozumnější párkrát měsíčně/ročně zazálohovat VM a důležitá data přes nějaký backup?

V tu chvíli denní zálohy budou mít pár GB a částečnou deduplikaci může dělat backup (rozdílová záloha)

[Šangala]

Ono je rozdíl jestli odzálohuješ minimální potřebnou Linux instalaci, kde má třeba full (tar.bz2) záloha < 400MiB a denní přírustek pár mega (bez dat), takže třeba v měsíčním cyklu si na hodnotě třeba 500/600MiB vs. odzálohovat jakékoliv Widle, kde ti na to nestačí ani 10× více.

[Chulda]

Toho jsem si vědom, proto jsem to napsal jako dotaz, nikoli kategorické tvrzení. A ani widle obvykle není třeba zálohovat celé.

[Šangala]

Přijde na to, jak dlouho má trvat a jak komplikovaná má být obnova, někdy se vyplatí zálohovat i /var/tmp.

[miho]

V mé situaci, kdy mám virtuály na 5 různých OSech, nad některých nemám a nechci mít roota je odpověď myslím jasná.

Zálohování uvnitř bych řešil dny. Při každé změně bych musel pořád něco řešit. A pak by se ukázalo, že jsem něco zapomněl zálohovat. Nebo že se něco nezálohovalo kvůli právům nebo nějaké jiné záležitosti, zkrátka bych to musel pořád kontrolovat. Přídání každého VM by mě stálo zase práci.

Rozchození zálohy celých VM bylo oproti tomu otázkou deseti minut (nakopírovat ghetto do ESXi, změnit pár věci v konfiguraci a hodit do cronu). Přidání dalšího VM mě stojí přesně 0 vteřin.

[Šangala]

Předem: nemám nic proti zálohování celých mašina a asi máš k tomu důvody, ale pár poznámek k některým větám :)…

V mé situaci, kdy mám virtuály na 5 různých OSech, nad některých nemám a nechci mít roota je odpověď myslím jasná.

Je pravda že ESXi jen z povzdáli můžu sledovat a nijak se nezajímám, ale pokud bych vzal paralelu s KVM s hosty na LVM (a nectěl bych to dělat jako push zevnitř), tak stačí udělal snapshot „z venku“ připojit read only a od zálohovat libovolnou metodou (tar cjf .... -g ...).
Platí za předpokladu, že se nešifruje VM až uvnitř - jinak je třeba znát ještě passhrazi.

Zálohování uvnitř bych řešil dny. Při každé změně bych musel pořád něco řešit. A pak by se ukázalo, že jsem něco zapomněl zálohovat. Nebo že se něco nezálohovalo kvůli právům nebo nějaké jiné záležitosti, zkrátka bych to musel pořád kontrolovat. Přídání každého VM by mě stálo zase práci.

Viz výše a znamenalo by to jen, přidání do nějakého seznamu.
NEBO
Universální zálohovací skript v každém stroji (jak jsou to Widle, tak to lze taky přes Cygwin, ale ty pak po obnově stejně nenastartují :( ), spouštěný cron-em, kdo má root-a má plné odpovědnost když to vypne, nicméně to lze z venku kontrolovat (třeba jen velikostí záloh), navíc může být záloha šifrovaná a to klíčem známým jen správci daného stroje, takže si ze zálohami může „hospodařit“ i cizí osoba a daný správce si může kdykoliv cokoliv vyhledat. (Kdo má nešifrované zálohy má všechno co potřeboval )

Rozchození zálohy celých VM bylo oproti tomu otázkou deseti minut (nakopírovat ghetto do ESXi, změnit pár věci v konfiguraci a hodit do cronu). Přidání dalšího VM mě stojí přesně 0 vteřin.

Je možné že je to nejrychlejší řešeni pro nasazení, ale dost nepříjemné s ohledem na velikost ukládaných dat (nejhorší by asi bylo prosté dd). Přidání dalšího stroje v případě Linuxu by mohlo být pod 1 min pokud není součásti template (vložit skript).

PS: Pokud těch 5 OS zahrnuje Widle a není to jedna/dvě mašiny, tak chápu, že je to tak na jistotu, ale toho místa je mi líto …

[Josef Kufner]

V okamžiku, kdy se to podělá, je mnohem rychlejší a jistější obnovit celý systém, jak byl. Dávat dokupy server z nějakých kousků je zdlouhavé a náchylné na chyby.

[Chulda]

Není to tak jednoznačné, např. backup VM s TB diskem trvá hodiny, zatímco backup diff dat trvá desítky minut (změny max do celkové velikosti v řádu desítek GB).

V případě velkých změn u velkého VM během dlouhé doby zálohování je ještě problém se zrušením snapshotu - opět bude trvat hodiny a také snížený výkon storage.

Těch omezení je spousta a tak opravdu není jen jedna univerzální a vždy vhodná záloha.

A ani ta jistota není jednoznačná. Snapshot neřeší neuložená aplikační data v RAM.

Vše je to ale o požadavcích. Často je ale opravdu lepší čistý VM + dohrát data.

[sigma]

No, u lepších řešení lze dělat i inkrementální zálohy VM disků, a zrušení snapshotu rozhodně nemusí trvat hodiny. Tady se zásadně projevují rozdíly mezi snapshoty typu linuxového LVM, a COW přístup např. u ZFS. Ty inkrementální binární zálohy si můžete představit třeba jako ZFS snapsnoty a zfs send. U větších řešení je tohle řešeno na SAN úrovni.

Co se týče konzistence dat v RAM, tak 1) je to stejné, jako kdyby ten stroj spadnul, a měl přitom zálohovanou writeback cache = co prošlo před fysnc(), to je bezpečně uloženo - tj. aplikace by s tím neměly mít úplně zásadní problém; a 2) pro samotné aplikace může být nějaký agent, který jim dá vědět, aby udělaly checkpoint. Nevím, jak v linuxu, ale na Windows Server je tohle integrální součást systému/NTFS, se kterou řada aplikací umí pracovat (MSSQL Server, Exchange).

Ano, vše je o požadavcích, ale v situaci, kdy virtualizační systém a guesty spravují jiní lidé je výrazně praktičtější umět VM obnovit bez další práce uvnitř ní. A jak už bylo řečeno, čím jednodušší postup v krizové situaci, tím větší šance, že to vyjde a bude to rychle hotové.

[Chulda]

Jenže lepší řešení nejsou zdarma a pochybuji, že by si je kvůli své malé virtualizaci pořídil.
Smazání snapshotu skrz vmware trvá dlouho.
Na SAN úrovni máte zas problém, že se zálohuje všechno nebo nic, což ne vždy může vyhovovat a SAN neví nic o VM nebo aplikačních datech v RAM.

ad 1) ale měl jsem za to, že se tomu se lidi snaží předejít. A v případě backup klienta tomu lze předejít.
ad 2) jo VSS. Vmware to umí s windows OS (quiesce guest FS). Vtipný je, že i když s tím linux nepracuje, tak kernel v RHEL6 měl bug, kvůli kterému ten linux někdy vytuh.

Ale na druhou stranu práce uvnitř ní už není starost provozovatele virtualizace. A pokud ti admini za něco stojí, tak stejně zálohují. Pak je IMHO lepší se s nimi domluvit, zda vůbec potřebujou častou zálohu celého VM.

[miho]

To vše záleží na situaci - rychlost zálohy jak je vytížený diskový subsystém, rušení snapshotu je zase ovlivněno kolik tam nateklo během života snapshotu dat.

Pokud můžu extrapolovat situaci u mě, tak záloha 1 TB VM bude trvat skutečně hodiny, konkrétně dvě hodiny a deset minut. A zrušení snapshotu (jelikož se to děje v noci) netvá dle logu esxi ani vteřinu takže nejsem schopen ani extrapolovat

[trekker.dk]

Kdyby tenhle portal za neco jeste stal, i bych se tu na blogu rozepsal, protoze se ZoL mam opravdu dost zkusenosti, o ktere stoji se podelit... Jenom musi byt s kym (mistni banda zarucene kazi chut sem cokoliv inteligentnejsiho psat...)

Možná ti to ušlo, ale autor tohohle blogu, se kterým sis vyměnil bezmála deset příspěvků, je taky součástí místní bandy...

[snajpa]

Autora, narozdil od tebe a podobnych, co do te "bandy" radim, nevidim psat prispevky, ktere maji nulovou hodnotu, krom toho ukazat, jak to nekomu umis nandat. A ted se muzes chytit za nos :) Nicmene bych preferoval, kdyz uz, diskuzi k veci.

[trekker.dk]

krom toho ukazat, jak to nekomu umis nandat.

Vidíš, co chceš vidět.

[radeczek]

Tohle vypadá na parádní zápisky... Už se těším na další díl.., Docela by měl pak zajímala celková cena, spotřeba, funkčnost. Snad se o tom s námi podělíš. Nějaké fotky budou?

[the.max]

Tak držím palce, aby ti ty 3TB disky vydrželi alespoň do konce záruky obzvlášť při 24/7 a nestane se ti to samé co mě, kdy jsem tři a půl roku zpět kupoval v jednom nejmenovaném velkoobchodě 2 constellationy es s 60ti měsíčni zárukou. Dodáky se bohužel při stěhování ztratili a když teď ty disky odešli a při vyhledání záruky ve velkoobchodě je najednou ze 60ti měsíců pouze 36 a dodáky pro jistotu zobrazit nejdou vůbec. Disky odešli 3 měsíce po 'novém' konci zaáruky. A nikde se ničeho nedovolám.

[R]

Chod na web Seagate, tam je niekde zahrabana moznost zistenia zaruky podla serioveho cisla disku. Ak tam zistis, ze zaruka je platna, daju sa disky poslat postou priamo do Seagate (to musis zaplatit ty) a oni ti poslu nove (resp. opravene).

[the.max]

Dík, našel, In Warranty Expiration 12-Oct-2015

[trekker.dk]

Kašli na to, jestli ti pošlou "opravené" disky, z poštovného budou akorát vyhozené peníze.

[Max]

Proč? Já takto úspěšně reklamoval a spokojenost.
Zdar Max

[xm]

Už jsem od vícero lidí slyšel, že Seagate posílá opravené (refurbished) disky, které velmi brzo odchází. Takže dát si něco na takový disk, co přijde zpátky ze Seagate, je o hubu (teda pokud člověk poctivě zálohuje tak o hubu ne, ale i tak ).

[trekker.dk]

Přesně tak, co si pamatuju, tak žádný z těch "opravených" disků nevydržel dýl než pár měsíců.

[R]

Jeden sa mi akurat dnes vysral :( Teda on funguje, lenze rychlostou asi 130KB/s...

[R]

Dat si nieco na lubovolny disk bez zalohy je o hubu. Novy disk moze odist uplne rovnako.

Minule som menil v notebooku disk (tiez Seagate), ktory mal len asi 1000 hodin nabehanych a bol uplne v prdeli. Padom to nebolo - notebook bol neposkodeny, ako novy a navyse mal ochranu disku pri pade. Nejake data som zachranil, ale mnohe subory uz nesli precitat. Po par hodinach sa z disku uz nedalo precitat nic, ani MBR.

[alkoholik]

ERC/TLER si muzes nastavit na co chces..
smartctl -l scterc,50,50 /dev/sda

[PanZvedavy]

Zajimave, autor se snazi na jednu stranu vybrat co nejspolehlivejsi reseni pro sva data v podobe ZFS, coz je opravdu dobra volba(ne-li dnes nejlepsi mozna), aby pozadovanou spolehlivost hned v zapeti poslal do kopru ignorovanim tak zakladni veci u ZFS jako je potreba ecc ram. U FS ktery je v podstate cely o ram je to pomerne nestastna volba. Staci procist par manualu k ZFS od sun-oracle nebo treba tady http://zfsonlinux.org/faq.html#DoIHaveToUseECCMemory.

Dalsi dulezitou komponentou je cpu...neni moc vhodne zvolit orezane polodpady jako atom ci jine low-watt srandicky. Naopak je potreba zvolit silne cpu, staci spustit na poolu scrub a i 4xcore na 3GHz se zacne poradne potit. Nekde jsem cetl, ze sun doporucoval minimalne dvoujadro. Intel core 2600 je vykonove hodne slusne, bohuzel neumi ecc.

Co se tyce volby OS, tak pro co nejstabilnejsi provoz ZFS se voli bud samotnej solaris(jehoz ultimativne-zasadni vyhodou dneska je nativni podpora sifrovani) nebo a je nejcastejsi volbou v komunitach "domacich kutilu" - openindiana ci BSD. BSD ma jednu zasadni vyhodu oproti openindiana a to, ze neni tak vybiravy po HW strance a je preci jen bliz svetu linuxu co se prace s nim tyce. Linuxu bych se v pripade ZFS vyhnul, ale padnej-zasadni argument nedodam-nemam, jen neznam nikoho, kdo by ZFS provozoval v realu na linuxu, coz neznamena, ze to nemuze nekde stabilne nejak jet :).
Zkratka dlouhodobe jsou v pripade ZFS nejpouzivanejsi a nejspolehlivejsi BSD s openindianou, ale kdyz to autor zkusi na linuxu jeho volba a sam jsem zvedavej.

[xm]

Přijde mi, že jste úplně mimo. Ne každý má stejné požadavky a myslím si, že ty autora blogpostu se hodně liší od toho co si představujete vy. Ostatně i ve vámi odkazovaném FAQu o ECC pamětech se píše:

For home users the additional safety brought by ECC memory might not justify the cost. It's up to you to determine what level of protection your data requires.

[R]

Videl som aj ext3 kvalitne rozosraty od vadnej RAM. Pri molochu typu ZFS si viem predstavit, ze to potom nikto neda dokopy.

[snajpa]

Co konkretne je na ZFS molochovity, kdyz se bavime o ondisk formatu? Ten je prave uplne jednoduchej a jasnej... ZFS se muze zdat komplexni, protoze integruje hodne puvodne nesouvisejicich konceptu dohromady, ale uvnitr ma celkem primocary navrh a ten kod se velmi dobre cte.

[snajpa]

Dokonce, kdyz tak nad tim premejslim, se ZFS bys to daval dohromady mnohem jednodusejc, protoze rovnou vis, jestli blok, kterej z disku vytahujes, je ok nebo ne, navic se bavime o copy on write FS, coz na ty obnovitelnosti docela pridava. A diky transakcnimu navrhu pripadne neni az takovej problem ziskat stav toho FS aspon z jedny recent transaction groupy. Aneb co neznam, toho se bojim

[PanZvedavy]

I lowend hw raid radice pouzivaji ecc ram. Dovolite si vymenit ecc ramku na raid radici(za predpokladu ze to firmware radice dovoli, coz nedovoli) za klasickou ramku, ktera se prodava za par svestek(128MB-1G)?
A ted kdyz to prevedem na ZFS, ktery bude pouzivat X ram modulu osazenych na zakladni desce, tak se moznost chyb kazdym dalsim modulem nasobi.

Je to jako jezdit v zime na letnich sjetych pneumatikach. I kdyby to bylo po 95-99 procent casu bez problemu a ridic mel stesti, tak prave to jedno procento dela a meni vse a v ten moment se ukaze sila zimnich gum - ecc ram. Je to samospasitelne? Samozrejme, ze ne, ale kdo jednou zazije ledovku na galuskacich, kde muze jit o hodne, tak si da sakra majzla na "pozadavky".
Pokud tvrdite, ze jsem "úplně mimo" predpokladam, ze mate nemale zkusenosti s provozem ZFS na klasickych ram bez ecc a na tom zakladate sva tvrzeni...nikoliv na linku s "might not justify the cost".

[David Watzke]

Jako vítěz mi vyšel 3TB WD RED. Oproti třeba WD Green má trojnásobný MTBF.

Hmm, ty jsem měl v sw raid1 a chcíply mi oba téměř ve stejnou dobu Jen tak tak jsem to stihnul odkopírovat.