Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Pekny clanok.
Zdravím,
na první pohled tento článek vypadá jako odborně provedený test/článek. Opak je bohužel pravdou. I přes mojí vytíženost jsem se rozhodl zaregistrovat a reagovat.
Stručně: ZFS má kvality, které na dlouhou dobu předběhly běžné potřeby (byl to záměr). Primární záměr tohoto FS je ochrana dat. Je zde také sytém urychlení čtení a zápisu pomocí systému vrstev vyrovnávacích cachí (HDD, pamět, atd.).
Když vypadne disk který slouží jako čtecí cache (HDD, pamět či jakékoliv jiné zařízení), nic se neděje, jelikož se data přečtou z původního (obvykle pomalejšího) místa.
Když však vypadne zápisová paměť ZIL (třeba zmíněná SSD), tak můžete nejlépe zvesela všem datům zamávat a jít se třeba opít, nebo tak něco. Neexistuje nástroj, jak data po takovémto výpadku zrekonstruovat. Z TOHOTO DÚVODU SE NEDPORUČUJE POUŽÍVAT SSD JAKO ZÁPISOVOU PAMĚŤ!!! Toto se píše snad ve všech poznámkách/radách pro začátečníky. SILNĚ doporučuji přečíst !
Jen pro lidi, co by to zajímalo: pokud systém optimalizujete a dodržíta pár základních rad, tak se dokážete dostat na rychlosti s HDDs co WIFT s ZILem na SSD cache.
Snad jsem to napsal stručně a srozumitelně. Roky jsem žil v zahraničí a češtinu už jsem pořádně (hlavně gramatika) nedoučil, tak mne prosím omluvte pokud někde chybí nějaký háček či čárka. Děkuji.
Kdysi byl CDR/Diit synonymem pro přesné/věrohodné informace. Když si vezmu pokles kvality článků na tomto serveru ... očekávám brzo články typu: snědl jsem piluli xy a prodloužil se mi penis o x cm - dokládám to fotografiemi ... ;o)
Ať se daří!!!
Jaromir
Já tedy nevím s jakými SSD pracujete, ale naše zkušenosti jsou zcela opačné. Spolehlivost SSD (ne všech samozřejmě, ale těch enterprise) se ukazuje jako mnohem lepší než spolehlivost běžných disků. Dáváme jim zabrat opravdu hodně a zatím nám neodešlo ani jedno. Konec konců i na diit.cz vyšel pěkný test toho, co vydrží obyčejný Intel 320 (vydržel toho hodně).
To se o klasických HDD říci rozhodně nedá.
Pokud vypadne ZIL na externím disku, nepřijdete o všechna data na poolu, ale jen o ta, která se nepodařilo zapsat během výpadku externího ZIL než ZFS automaticky začne používat ZIL na zbytku poolu. Je otázkou každého nasazení, zda to může znamenat problém, případně jaký.
Navíc, pokud se někdo bojí spolehlivosti SSD, není problém ho pro ZIL dát do mirroru, čímž si dovoluji tvrdit, že je riziko naprosto minimální a teoreticky se tím získá nějaký další výkon navíc.
Pokud tvrdíte, že "pokud systém optimalizujete a dodržíta pár základních rad, tak se dokážete dostat na rychlosti s HDDs" podělte se s námi prosím o ty rady. Já tvrdím, že SSD bude pro ZIL vždy výrazně rychlejší.
Stručne, jelikož za chvíli musím frčet ... porovnáváte enterpise SSD a běžný HDD = jablka a hrušky.
Ve valné většině bude chybovost ať už SSD ci HDD enteprise někde jinde než consumer. O tom žadná.
Jestli se nemýlim, záver článku byl, že tuším jedno nebo dvě ent. SSD pro Zil sou dobré, některé neent. jsou ale lepší (rychlejší + samozřejmě levnější).
Vy s tím souhlasíte, já ani omylem.
Není ZIL jako ZIL mimochodem.
Obecně jsou případy, jako je například NFS, kde se jakýkoliv ZIL nedoporučuje. Samozřejmě s Vámi souhlasím, pominuli tyto případy, tak ent. SSD v RAIDu jako ZIL je dobré a v jistých případech i lepší.
Pokud chcete výkon v enterpise, dělá se to uplně jinak - předpokládám, že jste slyšel někdy třeba o RAID60 či například raidz2.
Je mnoho pěkných návodů ... napřiklad zde s většinou zásadníh věcí souhlasím http://forums.freenas.org/threads/so-you-want-some-hardware-suggestions....
...
dal jsem si čas a tenhle vypadá ještě lépe http://nex7.blogspot.cz/2013/03/readme1st.html .
P.S. Teď jsem si všiml ve vašem příspevku slova vždy - nechci se sázet, ale co jste ochoten postrádat? Auto, jachta či nějaký diamantový prsten (že bych udělal někomu radost) by nebyl??? :O)
Clanek ktery obsahuje drby jako "3Gbit/s SATA2 works out to something like 375MBytes/sec" je k uvereni jako slib ceskeho politika :)
Psal jsem: "napřiklad zde s většinou zásadníh věcí souhlasím". Podívám se ale ... v tomto případě bych řekl, že je věta vytržena z kontextu. Je třeba brát cely odstavec a také pro koho je určen.
S čím v tomto článku nejvíc souhlasím je M1015. Pro mne bylo kdysi velice překvapení, jak papírově shodně výkonné řadiče můžou být v realných nasazeních se shodnými disky, CPU, atd. rozdílně výkonné !!!
Pro mne by bylo třeba už trošku o nečem jiném, kdyby bylo uvedeno k čemu byly disky připojeny, jaky ovladače, jaký OS, jak nastaven, atd.
Je to jako řící mam čtyřlitrový motor a jel jsem 200km/h. To o ničem nevypovídá, jen o hlouposti.
IBM M1015 je obyčejný LSI řadič s čipem LSI SAS2008 (na kterém byly mimochodem provedeny všechny testy, ze kterych Wift v článku vycházel). V čem by měl být tak zázračný?
Přesně tak. Je to LSI2008, jde do toho volně cpát LSI firmware (pro volbu mezi RAID a Interface modem).
Důvodem popularity téhle karty je především cena, na eBay to jde koupit po $100-120. Jeden čas toho bylo všude plno.
Článek byl o malých NAS a přiměřeně výkonných ... napište mi prosím co tavýto systém podle Vás potřebuje. Děkuji
Porovnávám low-end enterprise SSD (jako například Intel 320 nebo S3700) s "běžným" low-end enterprise HDD jako například WD RE4.
ZIL je jako ZIL. Je to pořád ZFS Inten Log, úplně přesně tak, jako to Wift napsal v článku. Žádný jiný ZIL není.
V jakém případě tedy není ZIL na SSD výkonnější? Vaše příspěvky jsou sice dlouhé, ale bez konkrétních příkladů.
S RAIDZ2 to beru jako legraci, to jste doufám nemyslel vážně jako výkonné řešení (konec konců máte to napsané i pod těmi odkazy co jste linkoval).
Prakticky všechny best-practise řešení doporučují ZIL na co nejrychlejší stabilní médium, konec konců kvůli tomu byla ta funkcionalina do ZFS přidána. Sami jsme si dělali mnoho testů a bez ZIL na SSD se v případě většího datasetu náročného právě na synchronní zápisy a nízkou latenci nedá dosáhnout rozumného výkonu bez SSD (opět, přesně jak to zmiňuje druhý link, který jste postoval a přesně jak píše i Wift v článku).
Pokud navíc použijete SSD mirror, stále jste nenapsal jedinou konkrétní nevýhodu tohoto řešení. A výhoda ve výkonu je evidentní.
Tak to je.
SSD je na ZFS SLOG zařízení vždy lepší - ale musí se použít "správné" SSD, kterému neklesá při stálém zápisu po čase rychlost (někdy až na jednotky MiB/s). Lepší SSD, s nastaveným OP (overprovisioning), při stálém QD=1 sekvenčním zápisu 4KiB bloků, klesne jen na cca 50 MiB/s - kde super kvalitní SSD má klidně 120 MiB/s, ZeusRAM pak několik stovek (blíží se to ke GiB/s, když je to dvouportově a nejsou latence v systému).
Když ještě taková SSD nebyla, šlo použít lepší RAID řadič, třeba lsi2308 s BBU (s baterkou), který má 1GiB RAM cache, a za něj jako SLOG dát pár normálních HDD, kterým ta rychlost zápisu neklesala. A zapnout to v režimu write cache, pohrát si s velikostí bloku. Když nebylo na SSD (které ještě navíc musí mít v sobě kondenzátory na uložení RAM cache, nefalšovat fsync() synchronní zápis), tak to byla jediná volba, jak docílit vyšší rychlosti při sync zápisu a neutratit nos mezi očima za STEC ZeusRAM nebo jiný takový bazmek.
Přitom se obešly ty nevhodné věci HDD - latence, seek. Ale sekvenční zápisová rychlost zůstala vysoká.
Normálně, dokud nedojde k průseru, se totiž ZIL nikdy nečte - jen se pořád zapisuje. A to nemusí taky SSD moc dlouho vydržet - to je další kritérium výběru.
Spolehlivost SSD a HDD je samozřejmě někde úplně jinde. Ale jde o to, v jakém režimu, nic není tak jednoduché a SSD je "divné zvíře", které má hluboký vnitřní "život".
Což jsou dnešní HDD bohužel už také - viz. jak si někdo nedávno pustil na elektronice HDD celý linux. Firmware disků, to je něco příšerného.
Však také existuje hezký, mrazivě pravdivý polovtip o SAN (Storage Area Network) - jsou to sítě, které píšou lidé, kteří píší firmware do disků ... Brrrr.
:-)
SSD i moderni spotrebni HDD jsou strasny zarizeni. Je potreba se uzkostlive drzet overenych modelu a aspon trochu duveryhodnych vyrobcu.Napriklad mi nesmi pres prah Seagate SVxx nebo SSD se SandForcem. Obecne bych si dobrovolne nekoupil SSD, kde neuvidim rencenzi ukazujici supercap na desce a zakladni test toho, ze funguje. Zatim to ve spotrebni svere dela slusne snad jen Crucial/Micron a na par modelech snad Samsung a Intel. Vsechno ostatni je komplet neduveryhodny smejd pokud neni prokazat opak.
Vzhledem k tomu jak skvele se nam vyvoji uloziste zacinam opet uvazovat o porizeni BD mechaniky. Dobre skladovane jednovrstve BlueRay je docela odolna vec a 25GB je kapacita na kterou jde vysmahnout to opravdu dulezite vcetne rozumne komprimovane verze fotek rodiny a podobnych veci.
Je to fakt síla, poslední dobou s těmi SSD/HDD.
Ty různé Audio/Video/Streaming disky, to je katastrofa - nehlásí některé chyby, protože priorita je ukládat/číst pořád dál (takže se neudělá odložený požadavek na nové zapsání a kontrolní čtení, jako normálně u disku) - video dekodéry jsou na vypadlé bity "zvyklé". Na nic jiného se to nehodí.
"Green" disky zase provádějí uspání/start, takže nakonec při nevhodném nasazení odejdou dost rychle na vyčerpání povolených start/stop cyklů (typ. 300.000).
SSD a jejich firmware - je další děsná kapitola, ano diskům se Sandforce se vyhnout, to je rozumné.
Ohledně kondenzátorů - to je nutnost. Ale se supercapacitory mám ty nejhorší zkušenosti - jsou málo teplotně odolné, většina odejde při delším vystavení nad 50°C, smrt při 60°C (alespoň ty co jsem měl tu smůlu vidět). Proto se dneska do enterprise SSD už supercapy nedávají. Místo toho je v tom kupa tantalů nebo elektrolytických kondíků s pevným dielektrikem, které vydrží bez problémů 105°C.
O BD mechanice také uvažuji, kromě LTO-6 pásky je to jediná rozumná možnost. Tak čekám, že se konečně chytnou ty vícevrstvé 100-120 GB. Ale na něco by stačily i ty jednovrstvé 25GB, to je fakt.
Očividně se neshodneme - pro příklad, psal jsem o NFS ... je třeba si také uvědomit, že je o nečem jiném, když jsou potřeby například domácí (ukládání filmů, fotky, malý web, atd.), úplně jiné pořadavky budou například při požadavku při střížně a zcela jiné např. asi to co by potřeboval WIFT.
Dal jsem si tu práci a přečetl zběžně ty dva odkazy:
14. To ZIL, Or Not To ZIL
This is a common question - do I need a ZIL (ZFS Intent Log)? So, first of all, this is the wrong question. In almost every storage system you'll ever build utilizing ZFS, you will need and will have a ZIL. The first thing to explain is that there is a difference between the ZIL and a ZIL (referred to as a log or slog) device. It is very common for people to call a log device a "ZIL" device, but this is wrong - there is a reason ZFS' own documentation always refers to the ZIL as the ZIL, and a log device as a log device. Not having a log device does not mean you do not have a ZIL!
So with that explained, the real question is, do you need to direct those writes to a separate device from the pool data disks or not? In general, you do if one or more of the intended use-cases of the storage server are very write latency sensitive, or if the total combined IOPS requirement of the clients is approaching say 30% of the raw pool IOPS potential of the zpool. In such scenarios, the addition of a log vdev can have an immediate and noticeable positive performance impact. If neither of those is true, it is likely you can just skip a log device and be perfectly happy. Most home systems, for example, have no need of a log device and won't miss not having it. Many small office environments using ZFS as a simple file store will also not require it. Larger enterprises or latency-sensitive storage will generally require fast log devices.
Pod to se podepíši!
Já se pod to podepíšu klidně taky. Především proto, že tam není nic o tom, že by se na ZIL neměla používat SSD a není tam vůbec žádný rozpor s tím, co bylo napsáno ve Wiftově článku.
môžete mi objasniť prečo sa pri NFS nedoporučuje ZIL? ešte som sa s takým odporúčaním nestretol. používam nexenta cluster, kde mám 2x Stec ZeusRAM mirror (v nezávislých jbodoch). Primárne exportujem volumes cez NFSv3 a bez ZIL mám pri malých súboroch rýchlosť zápisu 2-10 MBps. so zapnutým ZIL je to 10+ kráť viac. Pri veľkých súboroch je rýchlosť viacmenej zhodná - 600 až 800 MBps.
To mě také zarazilo, je to úplná blbost. Právě pro NFS je SLOG absolutní nutnost (pokud tedy někdo není takový idiot, že to patchne na nesyncovaný "zápis" nebo neexportuje s nosync).
V tom případě budeme rádi, když nám ty možnosti a základní rady v kostce nastíníte...
Nejsem vševědoucí ... chvíli mi trvalo, než jsem do detailu pochopil a nastudoval, že ZFS je úúúúplně o nečem jiném, než třeba ext3 či 4. Na netu je hodně návodů a proč vymýšlet-psát již prověřené a napsané?
Občas mám také tu tendenci vymýšlet něco nové a již ve skutečnosti vymyšlené .. časem vždy až na vyjímky zjistím, že to byla ztráta času.
Pokud byl Váš dotaz upřímný, dejte sem nějaký reálný case -požadavek (né ztráta času), přečtěte si třeba ty dva linky co jsem poslal před chvíli, postavme to, otestujme to ... před sí´tovkou za siťovkou, na takové stanici, na makové stanici, za takovým a makovým routerem ... s takovým požadavkem a makovým a uvidíme.
Pokud tam bude na konci 6% realné celk. zvýšení, tak mi to za zhoršené MTBF a větší výdaje nestojí.
O nečem jiném je, když koupím pár levných např. 2GB green disků, dam je do HW pole a potom připojím ZIL na výkonný, ale consumer SSD, tak budu čumět na nárůst výkonu a pose.. se z "výkonu".
Je to jako když někdo koupí levnou škoduli, nejede mu to a tak dela tuning.
Výsledek si každý rozumný člověk představí sám. Proti tomuto bojuji. Né proti všem. Né proti ZILu. Proti neznalosti. Nechci ztrácet čas teoretizovám a psaním, což mi stejně moc nejde ;O)) Na netu je plno užitečných rad i od zkušenějších, než jsem já.
V tuto chvíli nemá bohužel v bežném FS použití ZFS konkurenci. BASTA. Frčíííím
ZFS nikde nasazený nemám a ani se ta vyhlídka nerýsuje, zaujala mne hlavně poznámka o tom, že s klasickým HDD se dá dosáhnout zhruba téhož výkonu jako s SSD. Nestavěl jsem bohužel žádné opravdu velké pole, proto mi to připadá nepravděpodobné - tedy bude-li podobná cenová hladina, zdá se mi pořád levnější pro ZIL použít 2 x enterprise SSD, než něco speciálního (= drahého) s HDD...
No tak jsou asi instalace, kdy to může být pravda, pro určitý profil zátěže. A nemyslím tím jen SLOG, ale obecně SSD/HDD.
Třeba 2.5" 15k disky Seagate Savvio, ty mají kolem 200MiB/s, seek 2ms nebo kolik. Když jich v poli je hafo, tak to fakt jede. A netrpí to známými SSD neduhy - ucpáváním, nevyrovnaností latence (u horších SSD se stává, že se najednou na 20s "zamyslí", třeba jednou za den - a lehne kvůli tomu aplikace, dějí se obtížně vysledovatelné věci). Stačí se podívat na nějaké více "enterprise " testy, třeba na StorageReview a na latenci - to je průser.
S tím SLOGem máte dneska pravdu, ale před lety se to opravdu dělalo s HDD, přes cachovaný RAID řadič, protože SSD, které by uměly stálý sekvenční zápis 4KiB bloků a neucpaly se, jaksi za rozumné peníze nebyly.
Ono to platí částečně i dneska (obecně mimo SLOG použití), SSD je značně problematické zařízení, když tam místo toho dáte kupu kvalitních HDD disků, je to predikovatelné, kdežto SSD (hlavně ty "pseudo-enterprise") se chovají "různě". Třeba jsem viděl SAN, kde všechno jelo suprově, ale když se zvýšila zátěž o pár procent, celé se to ucpalo a lehlo. SSD. Ale při předprodukčních testech se na to nepřišlo, protože se to trénovalo jen pár dní. Při nasazení to týden jelo skvěle, ale pak ...
Návrhový problém vidím hlavně v tom, že když se buduje úložiště, mělo by se co nejvíce peněz utratit za opravdu kvalitní disky, nikoliv za různé vyfikundace, protože ty to nevytrhnou - když ve finále použijete místo enterprise disků nějaký spotřební šrot, protože na víc nezbudou prachy. Pak jsou vám všechny cache, řadiče, SAN síť na nic.
Na druhou stranu, když se v tom vyznáte, máte to vyzkoušené a dlouhodobě otestované, klidně můžete postavit skvělé úložiště na bázi laciných notesových SSD, ale musíte vědět, jak se chovají, jaký jim nastavit OP (overprovisioning) a kdy je preventivně zahodit a vyměnit za nové. Pak se dá dosáhnout hodně muziky za méně peněz. Ale chce to kus (sebevražedné) odvahy, protože se může stát, že výrobce v další várce vymění firmware a celé se to složí. Nicméně velké firmy (a odvážní systémáci) to tak poslední dobou dělají.
:-)
A co drahýho si jako představujete?
"zaujala mne hlavně poznámka o tom, že s klasickým HDD se dá dosáhnout zhruba téhož výkonu jako s SSD"
Nevím jakým způsobem pracuje log u ZFS, ale takovýto log se obvykle pouze sekvenčně zapisuje (přepisuje stále dokola), takže u HDD nedochází k seekům. V běžném provozu se tento log ani nečte, takže ani seeky mezi čtením jedné oblasti a zápisem do druhé oblasti nejsou. Tedy při troše snahy se dosahuje sekvenční rychlosti HDD, která je řádově srovnatelná s ssd.
Zajimava pripominka.
Rozumim tomu, ze kdyz se poskodi ZIL, tak jsou data v haji.
Ovsem nerozumim tomu, ze z toho duvodu jsou SSD nevhodna. Myslel jsem jsem, ze enterprise SSD jsou velmi spolehliva zarizeni, ale samozrejme muze se poskodit stejne jako jakykoli HDD.
V cem je tedy problem? Pokud misto SSD pouziji HDD a ten po pul roce odejde, tak jsme si prece vubec nepomohli!
Nebo jde o tom, aby se misto jednoho SDD pouzilo nejake RAID reseni s SSD disky, tedy aspon RAID 1, ktery bude odolny vuci vypadku 1, ci vice SSD disku (v pripade vyssich RAIDu)?
I v enterpise segmentu plati, ze chybovost SSD je porad nekde jinde nez u HDD. Mimochodem vadny HDD lze velice casto zachranit ... s daty. O SSD bych si to nedovolil rici.
Ano. Je jedno co odejde ;O) u critical ci enterprise, se to resi uplne jinak nez ZILem. Prirovnal bych to asi k tomu, ze si nekdo ve Windows da lepsi tapetu a ma dojem, ze ma novy a lepsi pocitac.
Vzpomel jsem si prave na kamarada, ktery dela cca dva roky v Londyne, jak mi loni v lete popisoval, jak se musel premahat ... u jednoho tamniho provedera vyhazovali po nekolika mesicich enterprise SSDcka a nahrazovali je ... museli je davat na sesrotovani ... co se mu honilo hlavou a jake mel pocity asi nemusim rikat ;O)
Problem je primarne o tom, ze kdyby dotycny vedel co dela tak obdobneho vysledku co dokazal s SSD ZILem mohl dokazat ciste s HDD disky.
Co se posledniho odstavce tyce, tak RAID jak jej lide znaji JE moralne zastaraly. RAID 5 zastaral nekdy okolo roku 08-09, raid 6 moralne zastaral loni, letos max. pristi rok. HW RAID bych prirovnal ke karburatoru. Az na fakt vyjimky uz jde o moralne zastaralou technologii u ktere neni duvod k pouziti.
RAID1 se pouziva jen home reseni, rekl bych a pouzivat tady HW reseni, to je jako davat do S120 sestilitrovy motor z BMW ;O)
S ZFS dosahnete vzdy lepsi pomer u vykon/cena/bezpecnost nez s HW RAID ... az na velmi specificke vyjimky samozrejme.
Radeji budu pouzivat zastaraly RAID 5/6 a ext4 nez nejake ZFS ktere pri poradne havarii neda dohromady nikdo.
Jste typ cloveka "dejte vsechna data do cloudu" (a nejlepe k Microsoftu), ze ano ? :)
Koukám, máte také rád humor ... to se mi líbí ;o)
Ano, je lepší mít Favo, než BMW, to opraví preci každý ;O))
Při "pořádné havárii" přijdete od data na kterémkoliv FS (pokud ne, tak to není pořádná havárie) I ty data na tom poli musíte mít zálohovaná / archivovaná.
No právě že nemusí, když se udělá dobrý návrh. Ale je pravda, že jsem jednou zažil případ, že pole mělo mirror vedle v baráku a jeden barák shořel a druhý se vytopil ... nebo naopak, uz si nevzpomínám. Když se to sere, tak se to ... souhlasím, že archivace zalohy musí být! Většinou ;O))
Tak to je.
Ona většina reálných havárií je stejně způsobena lidským faktorem, nikoliv nespolehlivostí hw nebo debilním návrhem.
Kdo ještě nikdy neudělal omylem "rm -rf *" někde ve zcela nevhodném místě FS (/) nebo něco ekvivalentně stupidního, tak není pravý systémák. A teprve ho to čeká.
Nebo nemusí dojít přímo k požáru, vytopení, zemětřesení - stačí idiot, co vypne omylem klimatizaci a pár dalších idiotů, co nesledují teplotní čidla a mají vypnutý poplach, protože to "zlobilo". Disky odejdou a nedají se reklamovat (každý enterprise disk má záznam teplot), v profi SSD odejdou superkapacitory (mají max. 50°C) atd. Celé to lehne.
Takže jediná věc, která funguje je zálohování. Pásky. LTO. Nejlépe každý den odnášené mimo objekt (a bacha na šifrování, protože po havárii se ukáže, že bezpečnostní specialista měl dešifrovací klíče v šuplíku, který vyhořel současně se servrovnou, takže místo záloh máte docela kvalitní pseudonáhodný šum).
Njn. Případně stačí serverovna spravovaná idioty, kde to klimatizace nezvládá a kteří v panice vypnou jeden napájecí okruh, aby odstavili 50% zdrojů tepla. Takové diskové pole vypnuté za běhu v troubě kde je 50°C, to je prostě lahůdka. (A potom se ti samí idioti smějí druhým, kde pro změnu pršelo. Jeden za 18 a druhý bez dvou za dvacet.)
:-)
Je pravdou, že se přístupy a požadavky na storage postupně mění, ale mění se to hodně pomalu. Osobně bych dneska to klasického raidu také nešel. Ty věci se dají řešit mnohem elegantněji na mnoha úrovních. ZFS je jen jedním z nich.
Souhlas.
Ačkoliv RAID5,6 jsou podle mého překonané technologie - mělo by se tam udávat MTDL místo MTBF - tedy střední doba do ztráty dat :-)
Jsem také členem RAID 5, ... Haters Clubu, ale jak píšete, nic není samospasitelné. Ani ZFS samozřejmě.
Má třeba neřešitelný problém s fragmentací. Když je pár let v provozu, je to fatální - musí se to jednou za pár let exportovat a importovat (udělat znovu), jinak se dějou věci ... zkuste si najít na netu jednu z historek, jak někdo udělal "zfs destroy" a pak celé datové centrum čekalo hodinu, den, dva, ... než se udělalo těch několik desítek miliard operací (při používání snapshotů, klonů a deduplikace několik let pořád dál se to poněkud zřetězí) :-)
Souhlasi, s fragmentací jsme si také "užili". Ale lidé z Delphixu, kteří pomáhají s vývojem, se snaží postupně alespoň částečně ten problém řešit a tak doufejme že ZFS bude umět s fragmentací zacházet trochu lépe (i když v principu se toho problému nezbavíme asi nikdy).
JJ.
COW, on-line deduplikace, write-able klony, to jsou protimluvy defragmentace už z principu.
Ale také čekám, že bude nějaký nástroj, co to dokáže alespoň nějak řešit. Snad se to brzy povede.
Zatím je work-around nezaplňovat kapacitu nad cca 70% a jednou za čas to odstavit a udělat celé znova.
Což při rozumném návrhu není až takový problém - stejně se to většinou používá ještě přes nějakou clusterovou úroveň (třeba zrcadleně přes LustreFS), takže jednotlivé ZFS head servery jsou odstavitelné i za provozu.
"COW, on-line deduplikace, write-able klony, to jsou protimluvy defragmentace už z principu."
+1
"Zatím je work-around nezaplňovat kapacitu nad cca 70% a jednou za čas to odstavit a udělat celé znova."
Tohle tak nějak platilo i v minulých časech (extX) jako pomoc alokátoru volného místa. Pokud to člověk nepřepískl, tak se mu FS odměnil velmi nízkou externí fragmentací.
"Což při rozumném návrhu není až takový problém - stejně se to většinou používá ještě přes nějakou clusterovou úroveň (třeba zrcadleně přes LustreFS), takže jednotlivé ZFS head servery jsou odstavitelné i za provozu."
Pěkné.
Toto by v nejnovejší revizi mělo být opraveno/vylepšeno (ješte jsem neměl možnost vyzkoušet)
Já to R5 haters clubu nepatřím, sám to provozuju na několika mašinách.
"Má třeba neřešitelný problém s fragmentací."
Neřešitelný? Já provozuju BTRFS a ten defragmentaci a další očistné procedury má. Pochopitelně principiálně nelze mít soubory defragmenované na všech snapshotech, to by potom znamenalo náklady na další místo. Ale soubory na subvolume defragmentovat lze.
Ono to opět dost záleží na způsobu použití. Pokud někdo dělá snapshoty subvolume a se všemi těmi snapshoty intenzivně pracuje (což BTRFS umožňuje), tak jsou potom jednotlivé extenty dost roztříštěny po celém prostoru. Což by ale ten, kdo navrhuje takové použití měl vědět no.
Ten BTRFS je kde a jak? Ja sledoval trošku loni devel list a když jsem viděl co se tam řešilo, tak už jsem ho nepoužil ani na testy. Nemluvě o tom, že pokud se nemylím, tak třeba raid 5 a 6 nejsou ani implementovány, atd.
BTRFS ještě není samozřejmně označeno jako stable a ještě hodně dlouho nebude.
Provozuji ho doma (domácí server na Debianu), na VMku na hostingu, potom ještě kámoš provozuje 30TB pole pro zálohy.
Původně jsem měl v úmyslu dát tam Debian na kFreeBSD jádře s ZFS. Nakonec jsem ale spokojen na BTRFS.
R5, 6 už jsou implementovány (v jádře asi tak měsíc).
Ale ono je to (opět) o přístupu. Pokud vím, že o data mohu kdykoliv přijít (což se u BTRFS moc nestává, už poměrně rané verze byly v tohle dostatečně stabilní), tak se proti tomu musím zabezpečit a potom už si jen užívat výhod (já už bych si dneska život bez snapshotů neuměl představit) a tak dál.
Tak ten RAID5 Haters Club je spíš taková sranda. Také to mám na mnoha místech. Ale chce to svoje, třeba nepoužívat příliš velké a mizerné disky - a nemyslet si "máme raid5, tak se nemůže nic stát" (což platí i o ZFS, ...).
"Write holes" a "silent errors", to není jen jakási ZFS propaganda, ale realita, bohužel.
BTRFS se poučilo z ZFS, takže se o defragmentaci stará. Na ZFS se tím lidi také zabývají, takže se brzy dá očekávat nějaká utilita, případně upravené ZFS.
V posledním odstavci jste ten problém vystihl - jakmile se používají COW, shapshoty, klony, deduplikace, ... výsledkem je zákonitě fragmentace. Defragmentační nástroje to pak upravují ... směrem k souvislým extentům, což není nic jiného, než že se to musí nakopírovat vícenásobně (aby to bylo souvislé) - žere to místo, a místo klonů se vlastně dělají bitové kopie původního (jako na starém typu FS bez COW a snapshotů/klonů).
Jo, je to velký problém, ale obávám se, že z podstaty věci neřešitelný. Leda nějakým kompromisem, třeba BTRFS mám dojem že umí jet s COW i bez něj. Takže si každý může vybrat, kterým směrem to bude "tlačit".
Když se poškodí dedikovaný SLOG, data v háji nejsou. V zpoolu zůstane všechno v pořádku, stačí ho znovu naimportovat a přijdete jenom o ta data, která v okamžiku havárie byla v ZIL na dedikovaném SLOG zařízení.
Tj. o posledních 10s (dvě transakční skupiny) zápisu, v okamžiku havárie.
Kdysi (asi do verze 20 nebo kolik) to byl průser, protože při ztrátě SLOGu byl v čudu i celý zpool. Ale to už dávno není pravda. Nicméně v diskusích o ZFS se to pořád táhne dál.
Samozřejmě máte s těmi SSD pravdu, mají MTBF 2 miliony hodin nebo více, proti HDD s 1.4-1.6 (obvyklé hodnoty, jsou samozřejmě vyjímky). A když při dopravě dodavateli upadne bedna z jeřábu, nic se nestane.
Místo jednoho SSD se obvykle na dedikovaný SLOG dávají dvě v mirroru, nebo se použije (jak píšu dále) RAID řadič s cachováním, protože tak se dá zvýšit rychlost zápisu do SLOGu - při vyšších výkonech to ani jinak normálně nejde.
Moc pěkný článek, Wifte.
Sice bude určitě plno lidí psát, že ... nemáte ZIL v mirroru, že testy nejedete přes Infiniband nebo alespoň přes 10GbE nebo tak něco. A spoustu dalších věcí ...
Ale k meritu věci to vede - tj. jaké SSD je vhodnější na ZIL, pokud holt nemáte těch asi 2x 50.000 Kč na STEC ZeusRAM, dva kusy v zrcadle. Docela by mě zajímalo zjistit, z jakého důvodu je ten Crucial tak špatný.
Jako ZIL (přesněji externí SLOG device) chudého muže se mi osvědčil také Intel DC S3700, dva kousky 100GB po 5.000 Kč do zrcadla.
Pokud je více peněz, jako nejrychlejší SSD používám SmartStorage Systems Optimus Ultra(+). To je skoro tak dobré jak ZeusRAM.
Ještě existuje jeden "tajný" trik, na rychlý SLOG - použití interní baterkou zálohované RAM paměti (nebo superrychlého paralelního SSD) ve vyspělém RAID5,6,50,60, ... řadiči. A k tomu třeba osm SSD na zápis - to celé jako dedikovaný SLOG device na ZIL zápisy. Při zapnutém write cachování. Do SLOGu se musí vejít 10s zápisu, tedy například při 1.5GiB/s je to 15GiB (pokud bude někdy celý provoz synchronní). Takže to nemusí být velké, ale rychlost zápisu musí dostačit. Problém je, že jsou to serializované zápisy převážně po 4KiB (pokud jsou data externě, jinak při menších datech jsou přímo v tom, tedy zápisový blok může být velký až 64KiB). Tedy QD=1, pro každý volume to jede v jedné serializované frontě. Pokud tedy používáte zvoly, třeba na iSCSI, vychází to lépe (je tam více front a SLOG to tak zvládá lépe).
Pokud se dělá nějaké větší obludné pole, které pak krmíte třeba přes Infiniband 1.5 GiB/s, tak to jinak ani nejde, protože i ZeusRAM je příliš pomalé a malé.
BTW, od určité verze ZFS při havárii externího SLOG zařízení přijdete jen o synchronní data, která jsou v okamžiku havárie v ZIL, tj. dvě transakční skupiny zápisu, tj. posledních 10s života ZILu.
Což se dá většinou nějak aplikačně/organizačně zvládnout. Lepší je samozřejmě mít ty ZFS systémy dva, v zrcadle přes LustreFS nebo Ceph nebo jiný clusterový systém. Ale to už je vyšší dívčí.
Díky za tip, ten superrychlý SLOG zní zajímavě :)
Pssst, je to Nexenta/Sun "tajemství" ! Teda Oracle.
Plus mega krutohustě tajné tajemství všech namyšlených blbečků kolem ZFS, těch "expertů", co vědí, co Vy nevíte.
Jen jsem ještě chtěl dodat, že jste Wifte mohl přidat jednu větu o nutnosti mít v SLOG SSD kondenzátory, aby se stihly zapsat při výpadku napájení cache v SSD (jestli to tam máte, tak mě to nějak uniklo). A otestovat, jestli SSD "nelže" při synchronním zápisu (tj. jestli nedělá fsync() falešně). Některé to dělají.
Jinak super.
musím tu pridať trochu zo svojej skúsenosti. SSD ako ZIL je naozaj hovadina. to radšej pridať RAM do systému, vytvoriť pre ZIL ramdisk (ramdiskadm -a zil-drive 16000m) a pripojiť malé UPS.
denný zápis mám asi 10-100GB dát. zo začiatku som chcel ušetriť, tak som ako ZIL používal 2x SAS Vertex 3. po 4 mesiacoch v rozpätí 7 dní odišli obidve SSDčka. Potom Intel SSD, výdrž 5 mesiacov (jeden dokonca zhorel). Nakoniec som aj tak skončil pri mirrored Stec ZeusRAM a nikdy by som neišiel naspäť.
Jako BFU jsem přínos ZFS nepochopil. Ten file system přece nezabezpečuje redundanci na fyzické vrstvě ne? Když odejde disk na poolu tak přijdu o data na disku uložená tak jako tak?
Proč by měl být raid 6 na HW 6Gbs SAS generaci řadičů morálně rok mrtvý?
Prosím diskutující GURU o radu. Momentálně mám v RAID 6, 9HDD. Na tom NTFS oddíl se skladem videa. Uvažuji správně dle článku, že je vhodné na tomto železe provozovat ZFS? Místo NTFS? Tedy HW RAID6 a nad tím ZFS? k tomu pořídit 2 SSD do miroru jako ZIL? Bude to bezpečnější? Případně zrychlí mi to zápis? Nahradí to nějak CACHECADE2 (SSD CACHE nad polem? Vím, že je to v principu něco jiného..). Uvažuji z principu špatně? Děkuji za tipy. Na bezpečnosti mi záleží nerad bych o materiál na poli přišel. (Prosím rady o zálohování mám:-))
Asi nejlepší by bylo podívat se na nějaký článek nebo prezentaci o ZFS, je toho na netu plno.
Třeba tady http://wiki.illumos.org/download/attachments/1146951/zfs_last.pdf.
V krátkosti - RAID5,6 nezaručuje datovou integritu. Disky mají určitou chybovost (překvapivě velkou - i v ideálních podmínkách komerční disky třeba 10e-14, tj. jedna chyba na 100TB). Typické RAID5,6, ... pole takové chyby neumí identifikovat, dělá CRC při každém zápisu, ale jakmile je tam chyba čtení z disku, přenáší se dál. V poli pak vznikají tzv. "silent errors", tedy tiché chyby. Když pak třeba po roce dojde k poruše disku, při resilveringu (obnovení) pole se obnoví data špatně. Pokud máte smůlu, může to být fatální. Stává se to často.
Naproti tomu ZFS zaručuje datovou integritu až na úroveň procesoru - protože se samoopravné ECC kódy vyhodnocují až v ovladači. Takže brání i chybám v železe, např. chybám RAID řadiče.
Jediné co ZFS zásadně požaduje, je ECC RAM a spolehlivý procesor - pak máte data spolehlivě.
Nepožaduje žádný hw RAID, ideální je na to jen SAS host base adaptér - levná varianta řadiče bez RAID funkce.
Co se týče redundance, tak můžete zvolit, co chcete, podle požadavků - strip, zrcadlo (zhruba ekvivalent RAID-0 a RAID-1), RAIDZ (jako RAID5, tj. jeden disk na ECC kontrolu), RAIDZ2 (dva disky), RAIDZ3 (3 disky) a kombinace.
Obvykle se používá kombinace zrcadla/strip, protože disky jsou relativně levné a pak to jede rychle. V porovnání se standardním RAIDem i zrcadlení zvyšuje rychlost čtení (na cca dvojnásobek).
ZFS umí výborně cachovat - říká se, že jediné co opravdu vyžaduje, je paměť. Minimální instalace bývaly nastavené na 8GB RAM, dneska spíše na 16GB (jak kde, třeba ve FreeNAS je myslím pořád 8GB).
Cachování zápisu jde do RAM, případně jde použít dedikované zařízení pro snížení latence zápisu - SLOG zařízení, kam se pak zapisují ZIL (ZFS Intent Log) - transakční logy, když jde o synchronní (tj. potvrzený) zápis. Další cachování je pro čtení - cachuje se v paměti ve struktuře ARC, případně do dedikovaného SSD kam jde L2ARC. Ale tyto cache nejsou kritické - pokud havarují, nic se neděje, jsou tam jen kopie často čtených bloků z diskového poolu.
ZFS není v žádném případě nějaký rychlostní šampión, hlavním cílem návrhu byla a je datová integrita. Každý zápisový/čtený blok se podepisuje ECC blokem, takže je zaručeno, že co se zapsalo, se také přečte.
Kromě toho to umí snapshoty, zapisovatelné snapshoty (klony), tyto si to umí posílat/přijímat - zfs send/recv, což se používá k inkrementálnímu zálohování nebo kopiím poolu. A umí to šifrování, komprimaci a on-line deduplikaci (blokovou). Každá taková věc samozřejmě snižuje propustnost.
Na mnoho věcí to není vhodné, dnes jsou kolikrát lepší různé "tiered storage", tj. systémy kde se ukládá na SSD, v další úrovni to jde na HDD nebo na pásky. Ale nebývá tam zaručena datová integrita, v tom je ZFS celkem ojedinělé. Pokud ano, tak si za to nechá firma zaplatit, a to dost (EMC například).
Oproti tomu ZFS je open source, je implementováno na Solarisu, illumosu (pokračovatel Open Solarisu), xBSD, Linuxu.
Ohledně použití, jak to popisujete, ZFS je pro to nevhodné.
Lepší řešení je to, co máte - pokud by nestačila rychlost, je lépe se poohlédnout po lepším RAID řadiči, který umí "tiered storage", tj. přidat do cesty nějaká rychlá SSD. S nedostatkem datové integrity se musíte smířit, pokud zálohujete, tak to snad vydrží. Ale provozovat větší RAID5, 6 pole - více disků - je dost nebezpečné, hlavně s ohledem na případné obnovení pole (při resilveringu za provozu nebezpečně často odejdou další disky, protože to dostává zabrat). Lepší je v takovém případě RAID50, 60, protože při obnovení se nemusí číst všechny disky.
Dnes existují i lepší RAID řadiče, které umí zabezpečit datovou integritu, ale za jiné peníze - a vyžadují speciální disky (třeba mají místo 512B sektorů o pár bajtů více pro ukládání ECC; tj. většinou jsou to normální enterprise disky, ale s jiným firmware ... několikrát dražší).
Není dosud implementace ZFS pod Windows (a hned tak nebude). Takže jediný způsob, jak by vam to k něčemu bylo, je dedikovaný NAS server, přes nějakou rychlou síť, třeba 10GbE, 10GBaseT nebo Infiniband. Například s FreeNASem nebo jiným softíkem, který umí ZFS implementaci. Nebo na illumosu (bývalý Open Solaris) plus nějaký balík na WWW správu.
Výhodou by bylo použití snapshotů, on-line deduplikace, datová integrita. Možnost zálohovat přes zfs send na jiný ZFS server. Nebo do pásek.
Nedávno jsem stavěl takový systém pro jednu videostřižnu - v ZFS serveru je illumos, 256GB ECC RAM, dva Xeony, cca 200TB disků ve dvou externích bednách, asi 40 SSD v další bedně a v serveru. Síť na pracovní stanice je Infiniband DDR po metalice (všechno je v dosahu asi 8m, jede to po twinaxu), nová Windows 8 už umí NFSv4 přes RDMA. Takže to jede zběsile rychle. Denně dělají na 12TB zpoolu který je celý na SSD, to se pak přesouvá na HDD zpool (pracovní kopie). Průchodnost HDD disků kolem 1GiB/s. Časem to chceme zvednout na 1.5GiB/s. A udělat gw do 10GBaseT sítě pro připojení jablečného železa.
Jenže to je dost profi systém, těžko bych si to představil někde doma.
Takže asi tak.
Velmi děkuji za hodnotné info. Zejména neexistence implementace pod win. V tuto chvíli je pole ve stejnéme case jako stanice (lokálně). Z čistě mechanického hlediska již není kam pole expandovat.. Je tedy jasné, že dalším vývojovým krokem bude pořízení průmyslového racku a celková změna konceptu. TJ. dedikovaný NAS,ZFS serveru k tomu 10GB sítovou infrastrukturu. Ještě, že paní domu IT dává větší prioritu než šminkám.-) Jinak mimochodem expandovat HW RAID6 pole plné dat je trpká zkušenost. degradovaný výkon po 20 dní... než proběhl rebuild. (dle fór na tom jiní uživatelé nebyli jinak). Předpokládám, že u ZFS toto problém nebude. Jak bych měl podle vás ideálně nakonfigurovat pole, konkretně 20 fyzických HDD, 2 SATA v zrcadle pro ZIL, řadičem SAS LSI 9271 s expanderem INTEL? předpokládejme tedy třeba FreeNAS implementaci a např 3 redundandní disky.. miror by hodně snižoval kapacitu pole. Jinak díky za odkaz na prezentaci. Konečně je mi jasné k čemu mohou sloužit některé základní desky s LSI integrovanými sas řadiči bez HW RAID funkcí :-)
Není zač, k tomu by komentáře měly být (samozřejmě kromě vzájemného osočování, nenávisti, urážek a tak dále)
:-)
Rebuild (myšlena změna konfigurace; opravě říkám resilvering) pole je problém vždycky, i na ZFS. Řeší se to tak, že se to nedělá. Třeba místo zvětšování RAIDZ2 pole (třeba 8 disků) se přidá další RAIDZ2 s taky osmi disky jako strip k tomu prvnímu (pak to bude 2x RAIDZ2). Jinak to nejde, ZFS to on-line neumí. Neumí žádné rebuildy (na jinou konfiguraci), mimochodem. Protože to je věc, kterou nikdo rozumný stejně nikdy nedělá - je to moc nebezpečné. Ruská ruleta je proti tomu celkem bezpečná kratochvíle.
:-)
Když už je to potřeba, dělá se to přes export/import - musíte to mít kam vypustit (pásky).
Pokud jsou takové "dynamické" požadavky, často se používá jen zrcadlení - tam disky přidáváte po dvou. Zrcadlit můžete i více skupin než dvě, pro kritická data se často používá trojnásobné zrcadlení (což jde v jiných úložištích obtížně). Nebo se přidává po RAIDZ, po 5-ti discích.
Ohledně toho, jakou konfiguraci zvolit, pro těch 20 HDD. To záleží na požadovaném výkonu, propustnosti.
Asi bych to udělal jako 4x strip RAIDZ po pěti discích. Nejraději ovšem jako 10x strip 2x zrcadlo HDD strip/zrcadlo, protože jednak se to nejlépe rozšiřuje, druhak to má maximální výkon. A cena disků je až na posledním místě. A hlavně, resilvering pak trvá nejkratší dobu a zatěžuje jen jednu dvojici, tím pádem to neohrožuje provoz.
Ale jak jsem už napsal, záleží, co od toho skutečně chcete. Možná by bylo výhodné mít to třeba 2x RAIDZ2 po 10-ti discích (RAIDZ se dává po lichých počtech, RAIDZ2 po sudých, RAIDZ3 po lichých - kvůli způsobu jak to funguje).
Samozřejmě, RAIDZ2, 3 jsou pomalejší.
K tomu cachování. Zase je to o tom, co na tom hodláte provozovat. Základem je hodně paměti. Můžete mít Xeon E3, ten je omezen na 32GB RAM. Pokud potřebujete více, tak Xeon E5, případně 2x Xeon E5. Vyšší výkon dostanete s méně jádry na maximální frekvenci, hlavně pokud budete používat SMB/CIFS, tam je to znát nejvíce.
Ale pokud nehodláte krmit celou síť nebo nevyžadujete extrémní rychlosti, tak bude E3 s max. 32GB RAM stačit.
Samozřejmě ECC, bez toho provozovat ZFS je pitomost.
Na zrychlení čtení se používají L2ARC cache SSD disky. Tam platí, že na každý blok 4KiB dat v L2ARC je v RAM asi 400B datová struktura - takže je blbost mít více než 10x větší L2ARC než máte RAM, protože pak se to stejně nestíhá obsloužit (ale to platí pro 4KiB bloky, jde to upravit). Takže řekněme třeba 32GB RAM, k tomu max. 400GB L2ARC SSD disk - nemusí být zrcadlený, protože to je jenom kopie dat. S ohledem na životnost, průchodnost atd. bych tam dal Intel DC S3700 400GB. Nebo špatný není ani notesový Corsair (už nevím typ, ale ten poslední nejdražší - Neutron GTX nebo tak nějak), při nastavení OP to funguje dobře. Můžete zvolit i menší kapacity a dát je do stripu, zvýší se celková průchodnost.
Ohledně SLOGu pro ZIL. Tam jde o to, jestli to vůbec potřebujete. Pokud totiž nebudete používat synchronní zápisy, tak SLOG nepotřebujete. Třeba když pojedete přes SMB protokol na wokenice, tak tam žádné sync zápisy nejsou (záleží na nastavení, ale typicky nejsou). Kdyby jste to používal přes NFS nebo iSCSI, je to něco jiného. Pak ano.
Kapacita SLOGu je 10x maximální průchodnost synchronního zápisu - tj. pokud máte 10GBaseT síť, je to cca 700MiB/s (záleží na latenci a nastavení velikosti MTU a na mnoha dalších blbinách) krát deset. Teda 8GB je dost, radši je lepší počítat s 16GB. Takže vyhoví např. 2x Intel DC S3700 100GB model do zrcadla (můžete to OP třeba na 20GB, zlepší se rychlost při stálém zápisu a životnost). Rychlost nebude tak vysoká - asi 40-50MiB/s max. Takže pro sync zápisy to moc rychlík stejně nebude - ale vyšší rychlost by vyžadovala použít trik s RAID cachovaným řadičem a třeba 4x SSD (nebo 8x) v hw RAIDu, kvůli rychlosti (a spolehlivosti). Nebo řádově lepší SSD (SSS Ultra+ nebo STEC ZeusRAM). To je myslím mimo budget.
Takže asi tak.
Samozřejmě, také můžete postavit server bez ZFS, třeba takhle http://www.storagereview.com/supermicro_superworkstation_5037ai_review
Tam použili klasický RAID, ale moderní typ, který umí ty "tiered SSD". A nad tím klidně FreeNAS na ext4.
Co bych k tomu ještě napsal, tak pokud půjdete do vyššího RAIDu 5, 6, ... (ať již jako ZFS RAIDZx nebo hw RAID5, 6), a bude se to opravdu používat jako disky, nikoliv jen na zálohu, tak nedoporučuji používání větších disků než 1TB, raději menší (a kvalitnější a rychlejší). Pokud chcete větší disky (2TB nebo více), jednoznačně zvolte jen zrcadlení/strip (RAID10).
Důvodem je, že disky mají stále téměř stejnou přenosovou kapacitu, a při větší velikosti pak trvá resilvering příliš dlouho - tím se zvyšuje šance na kumulaci havárie (zkrátka že při zátěži vyvolané kromě normálního běhu také obnovou odejde další disk), protože ta obnova bude trvat násobně déle.
Velikost HDD prostě stoupla za poslední léta 40x, ale přenosová rychlost téměř ne. MTBF také ne. Tím se dostává RAID5, 6 (i ZFS RAIDZx) do totálního maléru. Prostě pro větší disky jedině zrcadlení, nic jiného.
Jinými slovy, pro provozní data jsou ty malé (max. 1TB) disky, velké disky jsou jen na zálohy a občasná "bulk" data.
Vyborně. Souhlasím. Snad bych jen dodal, že čím více disků a čím více dat jimi proteče, tím více chyb.
ZFS chyby opravuje automaticky. Chyby vznikají například hojně i v kabelech a to určitě NTFS neřeší. ECC je nutnost a někdy se bohužel stane, že i HW RAID řadiče ji nemají implmentovány, nebo špatně. Ta penalizace se určitě vyplatí.
Musíte si uvědomit, proč máte RAID? Ve vašem případě to určitě nebude kvůli zvýšení rychlosti, řekl bych. Pole se obvykle používá kvůli bezpečnosti. A tady je to co se opomíjí, otázky typu: jak je pole bezpečné, za jak dlouho se pole obnoví, co když vypadne i druhý disk (disky se kupují bežně najednou od jednoho dodavatele, tudíž odejdou v podobné chvíli), jaká bude rychlost při degradaci, atd.
Takže například na rozdíl od HW RAIDu kde bude řadič zapisovat celý disk, tak ZFS bude zapisovat jen data a inicializace je zlomek vteřiny. Při poškození HW RAID řadiče budete potřebovat identický řadič pro přečtení dat, pokud vůbec půjdou přečíst, což u hostu odpadá. Atd.
V neposlední řadě si můžete zvolit třeba jaký druh komprese budete používat. Dedup, atd.
NTFS a ZFS bych přirovnal jako když chcete jet z Brna do Bruselu a pojedete na Segway (NTFS), nebo si najmete helikoptéru (ZFS).
Pokud se budeme bavit o skutečné bezpečnosti, tak se bavíme o raidz2 a výše a RAID60. Každá z těchto variant je určena pro jinou sféru. Pro 9HDD RAID60 není.
Pamatuji si jednou, že jsme hledali server (kvůli potřeby rozšíření), který roky fungoval v jedné státní instituci bezchybně a našli jsme jej nakonec podle kabelů zazděný "O)
Místo FreeNAS bych určitě doporučil NAS4Free. Dovolil bych si kolegu opravit, že minimum (ještě před rokem když jsem naposledy se díval na FreeNAS) bylo tuším nějakých 800mega, ve vašem případě bych to minimum viděl na 24-32GB. Důvod proč ne FreeNAS byl výkon a nespecifikované problémy.
O HW 6Gbs SAS generaci řadičů jsem rozhodně nic nepsal. Možná, když napíšete co přesně od toho očekáváte a co máte, mužeme něco vymyslet ... jelikož pod tím co jste napsal si může člověk představit mnoho věcí. Počítejte také s tím, že už na poli nějaké chyby 100%ně máte. Jaké máte zálohy?
Na Linuxu s ZFS zapomeňte.
Také, pokud to s bezpečností a rychlostí myslíte vážně, určitě doporučuji udělat dedikovaný stroj.
Teď jsem dostal k vašemu druhému příspěvku - 20dní? Mám úsměv na rtu a při té představě se mi dělá nevolno od žaludku. To se Vám vážně zdá jako dobré?
Koukal jsem na ten řadič - jste si jist, že má ECC pamět?
Prakticky: 20disků, to už by šla i šedesátka. Jak to teda je? Mám to chápat tak, že máte 9hdd a plánujete nový stroj s 20HDD? Určitě bych v tuto chvíli nemazal žádnou zálohu. Vykašlal bych se prozatím určitě na ZIL a redundatní disky a na vašem místě bych udělal to co radil kolega = najít kvalitní disky, udeálně z více zdrojů - prostě né jedna výrobní série, nebo je kupovat s časovým odstupem, atd.
Co z toho máte a co musíte použít? Teorie je jedna věc a praxe jiná ;o) S valnou většinou věcí co psal Karel souhlasím!
Prosím uvedl jsem trpká zkušenost 20 dní rebuild.. přeloženo hovorově byl to neskutečný opruz a nikdy více. Proto tu debatuji a lámu si hlavu s jiným řešením.
Přesná situace se má tak, že BIG case je naládováno 9x2TB disků + 1 hotspare na RAID6, celé to visí na LSI 9271-8i ( 6Gbs SAS generace) s odpovídajícím Intel expanderem. Chyby na poli? To si pište že jsou!! Je naprosto nezbytné mít naplánován "patrol read" u mě 1x týdně - v podstatě jde o kontrolní čtení bloků z pole a řadič vyřazuje ty nečitelné bloky. Poté naplánovaná kontrola integrity dat ve stejném intervalu. Stačí kouknout do logů a je jasné, že bez naplánovaných kontrol se nešťastníkům může pole klidně odporoučet. Pole slouží jako sklad videa. Pásky doma hned tak někdo doma nemá. Žádné firemní využití, jen takové to domácí žvýkání.-) Otázkou co s tím dál. Expandovat pole přidáním hdd už nikdy (tedy ne v téhle velikosti a zaplnění na 90%), opravdu mám obavy o chybovost. Je jasné, že budu muset sestavit nový stroj v průmyslovém racku.Dodávají se i pěkné do interierů. Jen váhám s koncepcí. Pokud zůstanu u stávající a bude mi jedno jak bude pole rychlé mohu zůstat u RAID6 v setech po 8hdd a nějakými globálními hotspare. Řešení RAID60 je pro mne finanční overkill. Robustní filesystem (ZFS??) a železo s poměrem redundance 2-3 paritní hdd na 6-8 je pro mne kompromis mezi cenou, bezpečností a obětováním kapacity. Opravdu nemám nějaký firemní budget. Nechme prosím stranou proč zrovna někdo řeší takové domácí zadání. Každý má své důvody. Je to pro lidi , kteří ze zdravotních důvodů nemohou dlouhodobě opustit domov a kvalitu televizní produkce psychicky neunášejí..-). Tak se daty krmí FULLHD projekce.
Ano plánuji tak 20 hdd. Zároveň je žádoucí možnost pole postupně zvětšovat. Byť s odstávkou. Stejně to jede v režimu 16/24. K RAIDU mne primárně vedla kapacita, rychlost a výkon a trpká zkušenost s mrtvými single disky. Bohužel ani raid není nesmrtelný, tak neustále hledám robustnější řešení. Tedy zaplatitelné. Také je možné ještě pár měsíců vydržet na RAID6 polích s NTFS a počkat co se stane na poli vývoje ZFS. Nevím jestli jsem nezaspal nebo se mi ten filesystem zdá poměrně nový a stále pod vývojem.. Tedy shrnu zadání, nový stroj 20hdd ZFS, kompromis mezi náklady, dostupným prostorem a bezpečností. Požadavky na rychlost nejsou tak prioritní, žádné extrémní IO vytížení. Zároveň ideálně využít stávající řadič, a hdd. Klienti (androidí udělátka, nebo tencí klienti) budou přistupovat počítám přes Sambu, jedna hlavní stanice přes iscsi (win). Jak vidíte malé, domácí, žádný datahouse.
V čem je pro vás RAID60 finanční overkill?
Takže máte zmíněný řadič a co ještě? Je pro Vás hodnotnější pár tisíc Kč, nebo desítky hodin práce a nervů navíc? Četl jste ty články co jsem Vám psal?
Je zde několik scénářů - hodláte za chodu data přemigrovat, nebo je někde zarchivovat a z toho co zbyde udělat NAS?
Také nerozumím tomu, že nemáte peníze a zároveň nemáte problém utratit zbytečně peníze za spary, HW RAID, SSD, atd.
Můžu se také zeptat jaké máte v tuto chvíli přenosové rychlosti?
Přečtěte si ty dva odkazy co jsem posílal a ušetříte hodně peněz a času. Škoda, že jste nedokázal odpovědet na mé dotazy - mohl jste ušetřit peníze a čas.
Vážený pane. Snažil jsem se na otázky odpovědět a situaci popsat. Děkuji autorovi článku a diskutujícím za podnět k samostudiu a postřehy z praxe. Ať ať se vám daří.
P.S. SAS/SATA HBA samozřejmě nemusíte kupovat, když už máte ten LSI9271 nebo kolik. Jen to musíte přepnout z RAID mode do Interface mode. Nepamatuji se, jestli zrovna tenhle typ má hw nebo sw switch, nebo zda se musí fleshnout firmware. Každopádně to bez problémů jde.
Hm, tak tahle poznámka patřila o kus níž. Ale vztahuje se to k tomu Vašemu problému.
Díky:-).
Tak teď, když jste popsal podrobněji účel stroje a je jasnější profil zátěže, tak ještě pár slov.
Vyrobil jsem na podobný účel celkem dost strojků, většinou na bázi FreeNASu se ZFS. Důvodem pro upřednostnění FreeNAS byla hlavně bezproblémová správa přes WEB, kterou zvládnou sami uživatelé. V nové verzi to už dokonce podporuje DLNA server, iTunes atd. - nemusí se nic dalšího bastlit.
Většinou jsem to neměl v takovém rozsahu jako plánujete (20 disků), typický box byl nejlevnější možný HP Microserver N36/40/54L, tedy dvoujádro Athlon II na 1.6-2.2GHz, do toho 16GB ECC RAM, 4-5x 4TB WD RE nebo RED disk, další PCIe 2xSATA na kterém visí dvě SSD (L2ARC, případně SLOG). Disky jsou buď 2x2 strip/mirror +1 spare, případně RAIDZ z 5-ti disků. Celkově to lidi používají přesně jak plánujete - na krmení androidích krabiček k televizi, přes WiFi na tablety atd. Filmy. Muzika. Sklad fotek. Občasný fileserver pro wokenice.
Pokud chcete 20 disků, na popsaný model použití bych asi preferoval 4x RAIDZ z pěti disků (můžete postupně přidávat po 5-ti discích) nebo 2x 10 RAIDZ2. Případně použít ještě hot-spare disk.
Na podobné malé zatížení stačí skutečně obyčejné velké disky - 4TB například. Jsou na výběr lepší (pseudo enterprise), tedy třeba WD RE4 (mají doporučený max. roční nájezd 550TB) nebo levnější WD RED (roční nájezd 120TB). Pokud by těch 120TB ročně stačilo, nebál bych se toho. Mám s nimi dobré zkušenosti.
Podle mě, na filmy stačí WD RED, lepší jsou pro tento účel vyhozené peníze. Overkill.
Jen se vyhněte všem Green a desktopovým.
A když jsme u toho, pokud použijete 4TB disky, asi jich nebudete potřebovat tolik. Nakonec možná zjistíte, že by vám úplně stačil ten laciný strojek HP Microserver N54L. Prázdný se dá koupit za cca 5kKč, jen do toho přidáte paměť a disky a máte hotovo.
Paměť raději větší, začít můžete na 8-16GB nebo rovnou vzít 32GB, ECC samozřejmě. Desku s podporou ECC (čipset Intel řady C2xx), procesor stačí jakýkoliv s podporou ECC (dneska Intel dělá s ECC i Pentia Gxxxx nebo podobná, nemusíte jít hned do Xeonů. Preferujte vyšší hodiny). Můžete preferovat i typ procesoru s nižším odběrem a použít pasivní chlazení.
Protože výkon není to, co potřebujete (pokud nebudete streamovat stovky filmů současně).
Možná by stálo za to investovat do lepší síťové karty, třeba vícenásobné serverové Intely nejsou už drahé (psal jste vlastně něco o 10GBaseT). Kolik na tom bude viset lidí ? Jeden FHD 3D film může mít i 50-100Mbit/s, takže počet nebo kapacita portu by tomu měla odpovídat. FreeNAS umí i teaming (LACP), takže možná by místo dosud drahé 10GBaseT vyhověla i levnější 2x1GbE (2.4kKč) nebo 4x1GbE (5kKč) karta (a tím pádem i levnější switche).
Celkově v tom nevidím nejmenší problém. FreeNAS má v sobě i ZFS scrubbing (na projíždění pole a hledání chyb), autosnapshoty, ... spoustu věcí. WWW rozhraní umí téměř všechno a je celkem použitelné.
Řekl bych, že v tom nemusíte hledat žádná kouzla nebo problémy. Vlastně ani to cachování přes ty SSD nepotřebujete. Na L2ARC i SLOG se klidně vykašlete, není to pro tohle použití potřeba - a stojí to zbytečně peníze. Raději kupte 32GB RAM, nejlepší cachování ZFS dělá stejně přes paměť.
SAS HBA koupíte relativně levně - bez RAID funkce. Dělají se 8,16, 24 portů, může být cenově výhodnější se obejít bez expandéru a mít disky připojené napřímo. Třeba na eBay seženete LSI2008 8 port HBA po $100 nebo míň, to by vás celé připojení disků vyšlo jen na cca 6kKč (kabely mSAS-4SATA stačí za pár korun od číňana, ZFS je proti poruše kabelů odolné).
Pokud sháníte bednu na 20+ disků, dobré a laciné rackové skříně dělá SuperMicro. Mají modely na různý počet interních disků, s expandérem (jedním nebo dvěma) i bez expandéru (direct attach disky). Ale je to všechno do serverovny, dělá to rámus jak startující stíhačka. Možná spíš preferujete něco do bytu, tak to by nebyla dobrá volba. Jsou určitě i velké skříně na 20+ do obýváku (a než dávat desetitisíce za bednu, je zde možnost si ji nechat udělat na zakázku, případně upravit nějakou hotovou; známý si vestavěl obývákový NAS do nábytkové skříně z Ikey - je to hezké a výborně to tlumí hluk).
Instalaci dáte na flesku (FreeNAS jede z flešky), takže disky budou volné na data. Nevidím v tom problém.
Já bych jenom skromě doplnil: Jde o úplně jiný koncept přístupu k problému.
Zatímco původní rozdělení tvoří vrstvy: disky - (hw) raid - partition manager - systém souborů, tak u BTRFS (ZFS tak dobře neznám), se všechny tyto vrstvy sloučí do jedné. Tedy nad disky už je přímo BTRFS.
Má to výhody jednak ve výše popsané bezpečnosti, ale také například v rychlosti zotavení po havárii jednoho disku.
BTRFS v režimu mirror (nebo obecně jakýkoliv redundantní režim) na nový disk tak synchronizuje pouze data, která jsou na něm aktuálně uložená, zatímco (hw) raid by musel číst a zapsat komplet celý disk. BTRFS na rozdíl od hw raidu ví, které bloky jsou obsazené daty a které ne.
Dále při klasickém rozdělení disků (ať již partition tabulka, LVM, nebo něco takového), je celkem problém s distribucí volného místa. Pokud máte disk (disk může být v tomto kontextu (hw) raid) rozdělený, tak v klasickém přístupu nemůžete z jednoho oddílu přesunout místo na druhý. Zatímco u BTRFS všechny subvolume sdílí celkové místo. A pokud přidáte další fyzický disk, tak toto nové místo mohou využít všechny oddíly.
AFAIK tohle je u ZFS jiné. U BTRFS se ukládají redundantně jednotlivé bloky, tedy pokud do existujícího fs (dejme tomu že jej mám jako raid1) přidám nový disk, tak btrfs začne nové bloky ukládat i na tento nový disk. Pokud vím, tak u ZFS tohle nefunguje, tam se zrcadlí celá zařízení, toto je pak součástí poolu a až nad tímto poolem jsou subvolume. Přístup BTRFS mi v tomto přijde modernější.
BTRFS nepochybně modernější je. Poučil se z návrhových chyb ZFS.
Jenže, není hotový, v provozní kvalitě, kdežto ZFS již ano ... no, s pár mouchami, že ...
(když se nedá včas pozor, z mušky může vyrůst masařka velká 3m)
:-)
Všechno chce svoje. Na některé věci je to téměř dokonalé (ZFS).
Těším se na BTRFS, až bude. Má mnoho velmi zajímavých vlastností.
Haleluja ;O)
Pekný deň všetkým :)
Chcem sa opytat skusenejsich manikov na nazor pripadne radu.
1. otazka:
mam doma postaveny NAS na primarne ukladanie filmov a muziky: c2d 2.5 ghz, 8GB ram,ubuntu LTS 12, 4x2TB Samsung, zfs raidz. pole je plne, takze rychlost sa uz nekona a fragmentaciu je sakra pocut. Uvazujem ze kupim SATA radic do pcie a k tomu postupne 4x4 TB Seagate desktop, znova do raidz.
Moze to tak ist ? co mozem cakat ?
2. otazka:
Na vianoce som podaroval synovi moj doterajsi komp, so zamerom, ze pre seba postavim vykonejsi, na urovni "hobistu" si prerabam zbierku DVD do mp4/h264/aac a ukladam na predtym zmienovanom NAS-e. chcem i7-4770K, 32 GB ram pre ramdisk. pri videu vela dat z niecoho citate a hned niekam zapisujete. jedno miesto bude SSD a druhe RAMDISK. Je taketo riesenie "udrzatelne" ?, alebo je uz ECC pamat nutnost ?
Dakujem za akykolvek nazor
Takže to jednou uložíte a potom jednom čtete? Ten CPU co píšete je úplně zbytečný, pokud nehodláte data šifrovat/dedup a podobný věci, což s videii stejně nemá cenu. Doporučuji přečíst ty dva odkazy co jsem psal výše.
Co se týče velých disků, tak se obecně na tyto účely nedoporučují. Je mnoho info na netu - např. http://www.servethehome.com/hard-drive-reliability-backblaze/ či http://www.hardcoreware.net/hard-drive-reliability-study/
Příklad: Já osobně doma mám v NASu AMD Athlon(tm) II 160u Processor - žere max 20W a pokud zrovna nešifruji, tak se fláká. Dedup nepoužívám. Freqvence je důležitější než počet jader. Zkoušel jsem zapnout druhé jadro, ale pokud jsem zrovna nešifroval, tak rozdíl byl nulový. Šifruji jen dva staré disky v RAID1, kde dávám jen fotky a videa.
Buďte více konkrétní. Špatným výběrem řadiče/disku/či třeba kabelu NAS po.... tak, že Vám nepomůže ani 24jader a 256giga pamětí.
Nevím co je vašem případě zaplněnost, ale hlavní problém ve vašem případě vidím v nedostatku paměti. U ZFS pro home použití platí jako minimum 4GB + 1GB na 1TB dat. Samozřejmě bez dedup a dalších věcí. dedup = alespoň 4x tolik paměti. Atd.
NAS je postaveny z toho co bolo doma k dispozicii, a okrem samby tam bezi: transmission, virtualbox a v nom pod XP-ckami jdownloader, oscam :) . ten transmission a jdownloader lahko sposobuju to, ze z celkovej kapacity 5,4 TB mam volne miesto 50 GB. a tu ide moje ZFS do kolien, takze bud premazat alebo rozsirit. Mazal som uz cez vianoce a bol to tazky proces :), ale vysledok bol jasne poznat. RAM sa mi viacej neda dat, boli tam len 2 sloty s maximalnou podporou 8 GB.
Chcem sa opytat, ci niekto nema skusenost s RAMDISKOM o kapacite povezdme 24 GB z normalnych pamati, nie ECC.
Celkem jistě by pomohla RAM paměť, pokud na tom jedete ještě virtualbox a jiné RAM žrouty, tak to asi narazí. RAM je pro ZFS základ.
Minimální rozumné obsazení je cca 8GB RAM - pro to je dimenzován například ZFS na FreeNAS (ačkoliv je fakt, jak tady zaznělo, že minimum je 800MB - jenže pro ext4; ZFS se sice dá "rozběhnout" na míň než 8GB, ale pak chodí velmi velmi velmi pomalu). Je tam plno konfiguračních parametrů, které jsou vzájemně závislé - například velikost oblasti v RAM, kam se ukládají transakční skupiny pro zápis (RAM write cache) bývá dimenzována na 1/8 RAM, tj. na 1GB, protože se tam musí vejít 10s záznamu (dvě transakční skupiny zapisované po 5s) - což je v souladu s 1Gb Ethernetem (cca 100MiB/s pásmo). No a tak dále. Je tam plno parametrů, protože s tím je pak zase provázána velikost read cache, dalších bufferů atd. Celkem komplexní věc, to správně vyladit.
Většina stížností na FreeNAS, jako na nevýkonnou platformu, pramení právě ze špatně dimenzovaného hw. Málo nebo dokonce i moc paměti (s optimalizací na 8GB RAM může být použití 128GB průser).
Pro velké výkony a enterprise nasazení je nejlepší illumos, to je prostě o něčem jiném, opravdu enterprise systém.
(maličkosti - potřebujete přidat iSCSI target ? Nemusíte démon restartovat, takže nepřerušíte službu - což jde třeba v podpoře mnoha hypervizorů dost blbě)
Pro deduplikaci je obvyklé počítat s 5GB RAM na 1TB deduplikovaného prostoru. V praxi je lepší to nepoužívat (pokud skutečně nevíte přesně, co bude výsledek, nemáte dost informací o povaze dat a jejich statistice) - je lepší místo deduplikace použít komprimaci - ta nezatěžuje významně procesor ani RAM a přesto na komprimovatelná data dost pomůže.
S RAMdiskem na obyčené RAM zkušenosti mám - tragické ovšem. :-)
Prostě do všeho by se měla dávat ECC RAM. Je pouze o kousek dražší, tak proč ne. A brát jenom desky a procesory, co to umí.
No, nechci být puntičkář, ale bylo to tuším necelých 600mega pro ext a přes 800, myslím 824, či 864, nebo tak něco pro ZFS ;o))
Souhlas, technicky to tak je - FreeNAS se ZFS se na tom dá rozběhnout. Ale pak ZFS jede naprosto hrozně. Je to leda pro studium a pokusy se snapshoty a konfigurací.
Prostě platí, že pokud máte málo paměti, použijte ext4, pokud o trochu více, XFS, pokud hodně, ideální je ZFS.
Pro FreeNAS plus ZFS považuji za rozumné minimum 8GB RAM, pokud je disková kapacita větší, tak raději minimálně 16GB. Mám dojem, že dokonce v nějakém README nebo v dokumentaci je zmínka, že parametry ZFS implementace jsou u FreeNAS optimalizovány pro 8GB RAM.
A to pořád musíte zapomenout na deduplikaci, pokud se chcete vyvarovat nečekaných věcí (na dedup je rozumné alespoň 5GB RAM na 1TB deduplikovaných dat).
Na druhé straně, někdy se stane, že bez změny nastavení parametrů ZFS je problém i s přemírou paměti, záleží jak kernel zvládá velké alokace. Tohle je v současnosti problém třeba současné Nexenty, která je založena ještě na starém Open Solarisu - mají problém s RAM nad 128GB, protože je něco blbě s alokací RAM v kernelu. Novější verze Solarisu nebo illumos tím netrpí.
Chápu, že přemíra RAM asi moc lidí trápit nebude, ne v amatérské oblasti použití :-)
Stručně:
NAS na virtualboxu = špatný nápad.
24GB paměť bez ECC s tolikati daty = nekonečná řada problémů.
Koukám, že S/M už je zase v módě ;o)
Ale teď vážně - to nemáte 500Kč na koupi staré desky s podporou ECC?
strucne :)
- virtualbox na NAS-e, okrem ineho
- ten 24 gb ramdisk by bol len ako docasny pracovny priestor pre konverziu medii - audio, video, nie dlhodobe ulozisko
- bude stara doska s podporou ECC za 500Kč podporovať procesor s instrukcnou sadou AVX2 ?
Zkusí to jinak: napište seznam přesné požadavky co budete chtít, co máte za železo ... přijde mi to, že se snazite stejně jako kolega výše utratit mnoho peněz a mít za to malý výkon.
Uvedu příklad - doma mám NAS na CPU s AMD 160u = žere max 20W. Pasivní chlazení - teď ukazuje 19,3C, max 29C. Max odběr na zásuvce když jsem jej před rokem dělal byl tuším 47W a to tam jede halda dalších služeb neustále. Pokud nešifruji partition, tak CPU jede neustále v úsporném módu. Malá spotřeba, velký výkon, tichý. Postaveno z "odpadu", jedině jsme kupoval CPU za 500Kč. Vrátí se však mi to však časem za spotřebu el. proudu, jelikož jede 365/24. Běžně na něj zálohuji i s kompresí disky a pole co mi přijdou na stůl a vzdy se čeká na source .o)) Zádný HW RAID a podobný zpomalovače/prodražovače.
Tahle zažloutlá úsporná levná tichá krabice postavená z odpadu s jednovláknem dá v přenosových rychlostech min z 99% na frak tomu plánovánémo osmivláknu s virtualboxem. Kromě toho, že mám vedle stolu další bednu, to nemá chybu ;o)
Vzpoměl jsme si na jednoho známeho - koupil si přel léty nového MB S Klasse, asi v 60 000Km, měl nehodu - pojištovna mu zkrátila plnění, jelikož z pneumatik čouhaly dráty, jak byly ojetý .. on říkal, že přeci nebude kupovat pořád tak drahý gumy ... pak jsem slyšel od člověka, co mu ho prodal v cca 196 000km, že po prodeji zjistil, že byl měněný jendou olej.
Měl jsem podobné železo, léta NAS založený na Atomu a fungovalo to, dnes jsem přešel na úspornou i3.
Chtěl bych se prosím zeptat, jaký máte názor na Intel "fake" RAID (intel rapid storage technology) pro Windows?
Mám na tomto poli raid 5 ze starších 1,5TB disků a rychlost zápisu je celkem slušných 85MB/s při write back cache modu (mám UPS). Rád bych ale přešel na bezpečnější řešení a udělal RAID 1 z 3TB disků + jeden 3 TB disk pro okamžité zálohy ( tři 3TB disky už mám)
Vzhledem k tomu že chci používat Windows a Hyper-V jsou mé RAID možnosti omezené. Pak tu je ještě Storage Spaces, ale to se Vám musí zdát asi ještě jako humornější varianta:) Investovat těžké tisíce do HW RAID karty se mi moc nechce, trpím obavou že karta odejde a už se mi nepodaří sehnat tu samou. Ještě mě napadlo zkusit použít ReFS souborový systém, vyrozuměl jsem že stejně jako ZFS by měl počítat kontrolní součty dat, i když vzhledem k jeho novosti se mi příliš nechce mu důvěřovat pro kritická data.
Náhodou jsem získal i Dell raid Perc kartu i s baterií, bohužel zvládá disky jen do 2TB a FW aktualizace nebude :/
Dobrý den,
jestli se ptáte mne, tak je odpověď jednoduchá a vyplývá z názvu: je to určené pro Windows. Z toho vyplývá bohužel vše.
Peptám se Vás jako stejný dotaz jako se ptám vždy: proč chcete RAID? Zkoušel jste někdy i rychlost obnovy dat, kolik chyb máte na poli, rychlost při degradaci, atd?
Mám dojem, že jste nečetl co jsme psali (nejenom já - viz výše). Přečtete si to ... a odpovíte si na mnoho věcí!
P.S. ... podobné železo ... přiznám se, že atomy neznám .. myslel jsem, že neumí ECC. Pokud by uměly, asi si nějaký vyzkoušel. Můžete mi prosím nějaky MB s atomem a ECC doporučit? Děkuji
Hehe. Tohle vzácné zvíře (Atomový board s ECC) je něco jako Yeti nebo BigFoot. Prý někde běhá po lese - kamarád kamaráda ho osobně viděl, všude se o tom píše a mluví, ale kde nic, tu nic.
Stejná věc se týká embedded AMD Kabini řady G - také to umí ECC, nicméně miniITX desky s tím žádná ECC nemají.
Tak snad časem se něco objeví.
Názor na Intel RST - je to prima věc pro desktop, jednak cachovaní čtení přes SSD, druhak zrcadlení (nebo strip pro vyšší průchodnost). Při zrcadlení se dají data zachránit i bez původního hardware. Je to lepší než drátem do oka, ale za úplně bezpečné řešení bych to nepovažoval. Tak nějak po těch letech mám bias proti těmhle Wintel udělátkům (možná dnes už neoprávněně).
Celkově jsou "fake" RAIDy skutečně fake.
:-)
Cokoliv softwarového (ala RAID) na wokenní server ve mě budí pochybnosti. Je skutečně nějaký projekt již fungující ? Nevím.
Na druhou stranu, na linuxových serverech jsou asi nejlepší zkušenosti s MD driverem, je to velmi flexibilní a fungující. Na zrcadlení. Nebo to jde zrcadlit přes LVM2, to také lidé celkem chválí (to nepoužívám, takže osobní zkušenost s tím mnoho nemám).
Zpátky k windows: jediné řešení je HW RAID. Z havárie karty bych obavy neměl, pokud se omezíte jen na zrcadlení/strip, tak to bývá přenositelné. V rámci jednoho dodavatele (doufejte).
Striktně bych se omezil na produkty LSI - to je dnes jediný skutečně fungující výrobce, Adaptec a další zásadně nebrat. A když něco s LSI čipy, tak jedině přímo od LSI, žádné rebrandované produkty (problém s firmware, bývají omezené na disky od dodavatele).
S vyjímkou IBM1015 (populární verze LSI2008), tam jde natlačit LSI firmware a "zlé kouzlo je zlomeno".
A ohledně toho typu RAID pole (10, 5, 6), při větších discích se striktně držte jen RAID10, kvůli době obnovení pole. Při dnešních (nestoupajících) rychlostech disků se doba resilveringu RAID5, 6 úměrně k velikosti disků prodlužuje mimo rozumné meze. Přitom MTBF disků je stejně mizerné jako před 10-ti lety, kdy 100GB disk byl standard.
Dnešní kapacita je třeba 40x větší, ale rychlost zápisu/čtení téměř stejná, MTBF také - tím pádem je to bezpečnostně cca 40x horší než to bylo - v případě obnovy pole. To je zásadní argument proti RAID5, 6 atd.
A to teď vynechám chybovost čtení (E-14 bitů, tj. jedna chyba na 10TB), tím pádem "write hole, silent errors".
Moderní lacinější disky jsou "vyhnané na steroidech", jejich firmware - to je kapitola sama pro sebe.
Tedy celkově - buď si kupte pod wokenice od LSI nějaký HW RAID, co umí RAID10 - to seženete levně, umí to už LSI2008. Takže žádné velké tisíce, když máte kliku, na eBay to je za $100.
Nebo druhá možnost - udělejte si dedikovaný NAS server. Třeba se ZFS. Získáte datovou integritu. A navíc možnost používat snapshoty, klony - což je pro virtualizaci velmi pohodlné. Absolutně návykové.
:-)
Pokud chcete dělat s Hyper-V, můžete třeba použít 10GbE propojení (bez switche, jen na přímo, pokud máte jen jeden server, tak to vyhoví) po metalice (CX4 kabely nebo přes SFP+ DAC metalický kabel). 10GbE karty na SFP+ nebo CX4 seženete za pár tisíc. Je to mnohem levnější řešení než 10GBaseT - a netopí to. A má to 10x menší latenci, což je pro virtualizaci poměrně zásadní.
Nebo ještě mnohem lepší a levnější možnost, kupte si z eBay dvě Infiniband DDR karty na metalický twinax. Vyjde na litr každá. Kabel od žluťáka $15. Na serveru musíte pustit Infiniband Subnet Manager démon. A jedete 20Gb/s, za pár korun (jen jste omezen na max. 10m). Pokud potřebujete propojit více mašin, karty jsou většinou dvouportové - tedy buď to můžete dát dvakrát a máte 40Gbit/s (IB se umí slučovat), nebo mezi sebou propojit (do trojúhelníku) 3 mašiny (pěkné laciné domácí virtualizační hnízdečko s možností livemotion mezi hypervizory, zásobované ZFS serverem, například; na 20Gbit/s). Nebo si za cca 10kKč koupit ještě IB DDR switch (bazar z eBay, 24 port za cca $500). Spěchejte, zásoby jsou omezené (výprodej minulé generace z datových center a skladů zásob náhradních karet a switchů).
20Gb/s domácí síť ? Kdo z vás na to má ? Každý, kdo není "úplně blbej", jak vidíte.
:-)
Obě výše zmíněné možnosti (na Infinibandu je to samozřejmě mnohem lepší) dávají možnost používat RDMA protokoly, s minimální latencí a overheadem. A nové wokenice umí RDMA, dokonce umí NFSv4 přes RDMA (mimo IP). Nebo iSCSI přes iSER protokol (mimo IP).
Tím se dostanete na průchodnost disků, jako byste je měl přímo v tom wokenním serveru (a něco se nového naučíte :)).
Takže tak bych to řešil, osobně raději tím druhým způsobem. Ale ten první způsob je zase o mnoho jednodušší a levnější - cesta nejmenšího odporu obvykle funguje.
1GB na 1TB dat
Tohle mimochodem platí i pro XFS. Jsou extrémisti co si na 1GB nasku udělají 8TB diskový pole a potom brečí, že není možný udělat xfs_repair. (Ono to už asi dneska jde, ale počkaj si.)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.