71 TiB DIY NAS ZFS on Linux-szal

Fájlrendszer, NAS, storage

A ZFS on Linux itt van már körülöttünk egy ideje. A HUP-on számtalanszor volt róla szó. Brian Behlendorf 2010-ben jelentette be, hogy Linuxra ZFS támogatáson dolgozik. 2013 tavaszán pedig azt, hogy kész a széleskörű használatra.

Az érdeklődőkben felmerülhet a kérdés, hogy a technikai érdekességen túl érdemes lehet-e a ZFS on Linux-szal foglalkozni. Talán erre adhat választ a "71 TiB DIY NAS Based on ZFS on Linux" blogbejegyzés.

A blogbejegyzés készítője Supermicro X9SCM-F alaplapra épített, 24 darab 4TB-os merevlemezt + 2 120 GB-os SSD-t tartalmazó, DIY NAS eszközéhez Debian "Wheezy"-t és ZFS on Linux-ot választott. A rendszert backup és videótárolás céllal hozta létre. A cucc körülbelül 6 ezer eurójába került. Az írás elolvasható itt.

( bra | 2014. 09. 02., k – 13:07 )

Én kb. fél éve kezdtem el a notebookomon használni, és szomorúan tapasztaltam, hogy ugyanazokkal a problémákkal küzdenek, amikkel a FreeBSD is a 10-esben (talán ma végre sikerült javítani): hosszabb használat után mindent kiszorít a memóriából.
--
zsebHUP-ot használok!

Csak erdeklodeskepp: mennyi memoria, es mennyi tarhely melett? (ha jol remlik akkor ZFS-nel minimum 8 GB-ot ajanlanak a legkissebb konfighoz is)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ez csak akkor probléma (FreeBSD-n legalábbis), ha az ember nem szán 10 percet a beállításra. Elég jól lehet szabályozni/korlátozni a ZFS memóriafelhasználását.

Meg persze akkor is, ha a felhasználó nem veszi figyelembe az ajánlásokat és 1-2-4 GB memóriával áll neki desktop felhasználás mellett még ZFS-t is használni...

A sima 7200 rpm-es SATA diszkekből ~100 IOPS jön ki "nyersen" (10k rpm-esből ~150, 15k rpm-esből ~200, "olcsó otthoni" SSD-ből 10k környéke, "drága otthoni/enterprise" SSD-ből 100k környéke, FusionIO és társaiból 1 millió), úgyhogy nagyságrendileg 2000 környéke jönne ki RAID5-ben, laborkörülmények között.

Nem akarok ilyen szintű redundanciát. Élesről klónozott tesztrendszerek lennének a storage-on, ha bukom az adatokat, akkor legfeljebb újraklónozok mindent egy másik ilyen storage-ra, amit előtalicskázok a raktárból.

Ha ténylegesen jó megoldást (redundáns kontrollerek, replikáció telephelyek között, több IOPS stb.) akarok, azt "kézzel" majdnem annyiba kerül összerakni, mint venni valami alja storage-ot.

( _ventura_ v | 2014. 09. 02., k – 14:57 )

Otthoni bohockodásra lehet jó, de olyat tud valaki aki produktív környezetben használja, pl vállalati storage virtualizáció alá, tehát ami éles környezetben működik és ha kiesik akkor az így vagy úgy pénz kiesés?

Fedora 20, Thinkpad x220

http://listserv.fnal.gov/scripts/wa.exe?A2=ind1303&L=SCIENTIFIC-LINUX-U…

ZFS on Linux (ZOL) is currently manually added to HELiOS (Healthcare Enterprise Linux Operating System). HELiOS is a spin of Scientific Linux created and maintained by the GE Healthcare Compute Systems team (CST).

es gondolom felette levo retegben megoldjak a redundanciat :-)

arra tokeletes ez, hogy sok storage podot osszerakjon az ember, es a felett, egy okosabb middleware-el szetszorja az adatait (ceph, swift, akarmi).

azonban ha iSCSI szintu redundancia kell (a LUN mindig ott legyen), mint ahogy VMware ala peldaul, akkor nem latom, hogy lehetne szepen megcsinalni, pedig jatszottam vele eleget.

Nem tudom, h oldjak meg.
De ha jol veszem ki a lenyeget, akkor azt akarod irni, h nem network FS es ez igy is igaz. Sosem allitotta magarol (dejolenne, ha azt is tudna...).
Nagyobb problema, hogy nem is mukodik veluk egyutt meg olyan igen faszan, helyesebben a levlistan latok ilyen-olyan gebaszokat ceph-fel, nfs, iscsi-vel kapcsolatban, de szemelyesen azokat nem hasznalom. Igazabol siman lehet, h az is rendben van, csak specko esetekben jon a szopas.

Amit sajat tapasztalatbol tudok, h a btrfs-snel jobb es stabilabb (a laptopomon az van es az alapjan, szerveren csak a /-t merem ott tartani).
Az ext4 es xfs eseten pedig hianyolom azokat a kib. jo kenyelmi feature-oket, amik a zfs-ben mind megvannak (scrub, send/recv, checksum, compress, snapshot es a tobbi, a talan legfontosabb a volume management).
Konkretan egyes feature-ok (scrub, checksum) miatt a ZOL-ban jobban bizok, mint az ext4-ben a legtobb esetben.

Pedig ebből indult a szál.

"pl vállalati storage virtualizáció alá"

Erre biztosan nincs ráragasztva a VMware certifikáció. Mivel olyan eszközzel is vannak sokszor gondok, amire rá van, az ember nem keres magának azzal bajt, hogy olyat használ, amivel nincs.

Egyszerű storage kontroller firmware hiba is tudott komoly galibát okozni egy olyan storage-dzsal, amit a VMware papíron 100%-ban támogat.

Biztosan nem állnék neki kritikus helyre sk. épített, SATA diszkes storage-dzsal + Linuxon mókolt ZFS-sel datastore-t csinálni.

Max. mentésnek. Ott is ha több szint van. Egyik szintnek jó lenne.

--
trey @ gépház

Sosem ertettem, h lehet vki annyira korlatolt, h ha "vallalati"-rol van szo, akkor a szemeben villog a vmware logoja, mint disney figuranak a dollarjel.

Szemely szerint teszek a vmware certifikaciora a vmware-rel egyutt. Van a vilagnak egy pottomnyi resze, ahol szinten nem hasznalnak vmware-t. Oszt akkor mi van?

Az van, hogy ott használnak barkács-storage-ot. Sőt, ideális esetben a hiper-szuper-enterprise környezetben is használnak barkács-storage-ot is, a megfelelő célokra. Ez a konkrét megoldás pl. tök jó és olcsó akkor, ha nem kell sok szálon sok IOPS-ot nyújtani, nem kap folyamatosan nagyobb terhelést, mint amit a karos diszkekkel ki tud szolgálni és nem fontos igazán a rajta lévő adat.

A sokadik hozzászólás után, ami a nagy IOPS-képtelen barkács-storage-ot hozza fel, muszáj írnom valamit:

Az eredeti hír/cikk arról szól, hogy a csóka otthon a videó gyűjteményére építette és konfigurálta a cuccot. Szóval IOPS igényről szó sem volt sehol. Az első beíró elővette (minden alap nélkül), hogy "de ha IOPS kell, akkor ez szar", és azóta ezt fújja minden nem-gyári-storage fujjoló. ZFS-sel (meg mással is) lehet nagy IOPS-re optimalizált tárolót építeni, csak megfelelő HW komponenseket és megfelelő SW konfigurációt kell választani. Enterprise SSD-kkel, sok-sok RAM-mal ZFS-sel is lehet horror IOPS-t elérni.

Az utolsó "és" utáni rész meg pláne gáz (a hozzászóló részéről), mert a ZFS pontosan (azaz egyik fő sarokpontja) az adatbiztonságra jött létre, ráadásul a konkrét konfig esetén 2x2 HDD hibát tűr a rendszer 24 lemezből, ami azért nem kevés - otthonra legalábbis.

A storage is olyan, mint minden más az informatikában: a szakemberre van bízva, hogy az adott feladatra melyiket használja, így ha nem megfelelő/nem bírja, akkor arról nem a storage tehet...

Szerintem nem írtam azt, hogy ez a megoldás nem jó semmire, hanem leírtam, hogy milyen feltételeknek kell teljesülnie ahhoz, hogy jól használható legyen valamire. Ez úgy gondolom, hogy jelentős különbség.

A végét, az utolsó "és" utáni részt viszont fenntartom: ebből a konfigurációból közel sem csak a diszkek mehetnek tönkre, hanem pl. az IO kártyák vagy az alaplap is - ezek hibája ellen pedig a ZFS sem csodatevő, nem fog megvédeni.

A hozzászólásom nem kifejezetten és kizárólag a Tiédre reakció, hanem úgy általában az egész témára, mert ahogy írtam, a Tiéd volt a sokadik ilyen tartalmú.

A konkrét esetben felesleges volt leírni, hogy milyen legyen a terhelés, hogy jó legyen ez a megvalósítás, mert nem csak úgy valamire, hanem egy konkrét feladatra építette a gépet és pont olyan terhelésnek is teszi ki. Emiatt én inkább provokatívnak éreztem ezt a részt.

A megbízhatósági pedig szintén zenész, mert nem azt írod, hogy vezérlő vagy alaplap hiba miatt átmenetileg elérhetetlenné válhat az adat (ami egy otthoni videótárnál nem akkora gond szerintem), hanem azt, hogy "és nem fontos igazán a rajta lévő adat" miközben az adatot elég jól megvédi, csak az elérhetőségét nem növeli sok-kilences régióba. Persze itt lehet azon polemizálni, hogy a "fontos" alatt az adatvesztés-elkerülést vagy a megszakítás nélküli elérhetőséget értjük, de szerintem a legtöbben az adatvesztést értik.

Még egyszer jelzem, hogy a szál "pl vállalati storage virtualizáció alá, tehát ami éles környezetben működik"-től indult.

Tegyük fel, hogy egy cégnek ez a fő centralizált adattárolója, amiről a virtuális gépei futnak. Rajta DNS, DHCP, címtár, levelezés, fájlmegosztások, adatbázis-szerverek.

Ha megáll, a cég megállt. Ketyeg az óra. Időre dolgoznak. Most akkor a döntés:

- tákolt storage, innen-onnan alkatrészekkel (szupport = bolti nyitvatartási idő, jó esetben, next businness day helyszíni garancia egy futárral, aki hoz majd neked egy tápot, alaplapot - de ahogy a hazai állapotokat ismerem, majd lesz amikor lesz)
- gyári storage, alkatrész akár 2 órás kiszállással 7/24/365

Nekem már volt szükség központi storage-hoz éjjel alkatrészre. Telefon ment a gyártóhoz, az embere (aki értett is hozzá, nem futár), beült az autóba este 9-kor, fél 11-kor a kezembe adta az alkatrészt Győrben.

Ha neked kell egy cég folyamatos üzemét biztosítani és a te f.szod verik ki, ha valami nem megy, akkor nem biztos, hogy akarsz magadnak álmatlan éjszakákat.

Még egyszer: senki sem mondja, hogy a tákolt storage nem jó. Akinek van esze, használ ilyet mert olcsó és mert megvan a maga helye. De nem első számúnak, hanem tartaléknak, backupnak, tesztkörnyezetbe stb.

A cikkben említett felhasználásra (pornógyűjtemény otthoni tárolására) teljesen jó. A cikkben említett megoldás nem is való ebben a formában másra, több sebből vérzik. Egy szem tápegység pl. ami ha beszarik és nincs másik 800W-os kéznél, akkor halott ember vagy. Nem is kell tovább menni.

Ráadásul a csávó írta, hogy az első táp be sem vált, kísérletezéssel választotta ki a jelenlegit. Most akkor ez mennyire megbízható egy olyan storage megoldással szemben, amiben a tápot mérnökök méretezték stb.

Hosszasan lehetne sorolni a problémákat.

--
trey @ gépház

Igazabol a szal a cikk onnan indul, aki ahonnan veszi.
Jobban meggondolva _ventura_ kerdezhetett altalaban a zfs-re es konkretan a cikkben felepitett storage-ra is, nem jelezte kulon
Az utobbit ha jol latom, senki nem allitotta es igazabol ostobasag meg lenne meg a kerdes felvetese is.

Viszont te felhoztal egy olyat peremfelteteleket, amikkel biztosan igazad lesz. Vagy ertelmezhetjuk ugy, h hasonlo helyzetben, direkt kibaszol magaddal?

ventura ezt irta:

Otthoni bohockodásra lehet jó, de olyat tud valaki aki produktív környezetben használja, pl vállalati storage virtualizáció alá, tehát ami éles környezetben működik és ha kiesik akkor az így vagy úgy pénz kiesés?

kiemeltem neked a lenyeget. ez a thread errol szol itt. ventura konkretan arra kerdezett ra, hogy virtualizacio ala hogy rakod be. kerlek mutasd meg, hol teremtette meg trey azt a kornyezetet, amiben neki igaza van... (sehol).

ha ebben a kornyezetben ilyet hasznalsz mindenfele replikacios middleware illetve egyeb nelkul, akkor akar rulettezhetnel is: ha barmi meghal, all a ceg, es minden rajtad csattan majd.

en megtanultam (a sajat karamon), hogy inkabb elkoltok 5x annyit, de minden redundans ES van kit hivni, ha beszarik. es meg igy is lehet ordatlan szivasokba belefutni (nalunk pl a HA switchek egyszerre haltak meg, csak a fizikailag kihuz-bedug oldotta meg)

+1

Továbbá 100%-ban supportált vassal van esélyed, hogy már más is belefutott egy bizonyos problémába, ergo lehet megoldás a közösségi support fórumokon. Fordulhatsz az eszköz gyártójához, a virtualizációs szoftver gyártójához. Két irányból csak hamarabb jön a megoldás. Ráadásul ha ezek nem tudják megoldani, akkor még mindig mondhatod, hogy nem a te sarad, te gondosan jártál el a tervezésnél. Hogy olyan hiba jött elő, ami a legkörültekintőbb tervezés esetén is beüthetett azt meg boxolja le a két gyártó.

Ha magad gányolsz, magadra maradsz. Lehet választani.

--
trey @ gépház

Na, itt a lényeg: A biztonságot nem az adatok szempontjából kell vizsgálni, hanem az IT középvezető szempontjából. Az adatok akár el is veszhetnek, az IT vezetö mondhatja, ő nem sajnálta a pénzt a biztonságos és szakszerű megoldástól, tehát mást tessék valagba rúgni. Amúgy is megvan a hajlam minden manager részéről, hogy minél több pénzt akar a projektje alá kaparni. Managernek a nagy költségvetésű projekt olyan, mint halnak a víz. Minél nagyobb a költségvetés, annál fontosabb tényező.
--
ulysses.co.hu

Cinikus a megjegyzés, bocs.

A "boxolja le a két gyártó" végkicsengésű gondolatmenet legalább annyira cinikus. Elköltöd drága dolgokra a megbízód pénzét, aztán ha mégsem kapja meg, amit akart, az nem a te sarad. Végül ki lesz az áttekintés ura, aki személyesen felel a projekt sikeréért? Egy banki katasztrófát pl. nyilván nem lehet egy enterprise storage szállító nyakába varrni.

A középszint mondhatja, hogy megtette a magáét (tegyük fel, hogy igaz) a többi rajta kívül áll. De azért legyen ráköltve minél több pénz, mert annál profibb a megoldás, annál inkább nem ő a felelős, ha mégsem, és annál inkább látszik személyében jelentős tényezőnek. Akkor viszont ki képviseli a megbízó érdekét? Nem tudom a választ, csak látom a kérdést.
--
ulysses.co.hu

Egy kis érdekesség, ami mostanában sokszor előkerül a közelemben (és igazából nincs köze ehhez a témához :-) ).

Egy rakás informatikai problémát (a példa legyen a 2+2 kiszámítása) többféleképpen is meg lehet oldani:

- felveszel három fejszámolót, mind kiszámolják az eredményt, majd többségi szavazással eldöntik, hogy mi a eredmény (nincs egyszeri költsége, sok fizetés kell nekik, megbízható, redundáns, lassú)
- felveszel egy fejszámolót, aki kiszámolja az eredményt (nincs egyszeri költség, kevesebb fizetés kell neki, nem megbízható, nem redundáns, lassú)
- veszel egy számítógépet, ami kiszámolja az eredményt (alacsony egyszeri költség, nem kell fizetés, megbízható, nem redundáns, gyors)
- veszel három számítógépet, kiszámolják az eredményt, majd megszavazzák, hogy mi a végleges eredmény (magas egyszeri költség, nem kell fizetés, megbízható, redundáns, gyors)

Meg még egy csomó más megoldás is van, nyilván, mind-mind a zárójelben megfogalmazott költségekkel, előnyökkel, hátrányokkal, kockázatokkal.

Szerintem egy IT-s nem lehet igazán jó akkor, ha a fentebbiek közül bármelyik megoldást favorizálja. A jó IT-s feladata éppen az, hogy ezeket a megoldásokat jól ismerje és az adott helyzet ismeretében megfelelő megoldást adjon az üzleti igényekre, vagy megfelelő módon, érthetően tájékoztassa a döntéshozókat a fentebbiekről. A HUP-on a legtöbb vitában nem ilyesmik köré szerveződő, kulturált társalgás folyik, hanem mindenki mondja a magáét, többnyire a többiek meghallgatása nélkül.

Lehet, hogy van valami abban, hogy kéne tanítani kommunikációt azokban a fránya iskolákban :-)

Pontosan erről beszéltem. Hogy mindennek megvan a maga helye. Nincs baj sem a gyári, sem a tákolt megoldással. Mindegyiknek vannak előnyei, hátrányai. Azt mondtam végig, hogy tudni kell, hogy melyik mire való és hol van a helye.

Ja, és még annyit, hogy a tákolt storage helye is meglehet az enterprise virtualizációban. Én is megtaláltam. Tesztelés, D2D backup és minden olyan hely, ami nem halálkritikus.

Hogy más hol találja meg? Ahol akarja. Ahova kell, oda gyári FC storage-ot, ahova kell gyári iSCSI storage-ot, ahova pedig az kellett, magam tákolta iSCSI storage-ot tettem. Mindegyik teszi a dolgát évek óta hiba nélkül, de tudom, hogy melyikről mit várhatok és mit bízhatok rájuk.

--
trey @ gépház

ezzel teljesen egyetertek, de sokszor a masik fel (a fonok, PM, donteshozo, akarki) csak a penzt latja, es hiaba mondod neki, hogy "osszerakjuk mi X-ert, de nem lesz olyan jo, megallhat, cserebe olcso", amikor konkretan beut a krach (mert befog), akkor valahogy elfelejti mindenki a vesszo utani reszt :)

> hol teremtette meg trey azt a kornyezetet, amiben neki igaza van

Itt gondolom azt akartad irni, h nincs igaza? Vagy nincs ertelme.

Konkretan trey az egyik oldalon felhozta az enterprise kategoriat, a masik oldalon pedig az ajja szart.

pl.:

- tákolt storage, innen-onnan alkatrészekkel (szupport = bolti nyitvatartási idő, jó esetben, next businness day helyszíni garancia egy futárral, aki hoz majd neked egy tápot, alaplapot - de ahogy a hazai állapotokat ismerem, majd lesz amikor lesz)
- gyári storage, alkatrész akár 2 órás kiszállással 7/24/365

Az elobbinel lehet akar az is, h az alkatresellatasra 0 percet kell varni (potalkatresz).
Az utobbinal meg akkor 2 ora, ha olyat kotsz, ha meg nem, akkor szar. Sot, az elobbinel is olyan az NBD garancia, amilyet valasztasz.

> Ha neked kell egy cég folyamatos üzemét biztosítani és a te f.szod verik ki, ha valami nem megy, akkor nem biztos, hogy akarsz magadnak álmatlan éjszakákat.

Azt kapjak, amire befizettek. Nekem allt mar napokig glusterfs clusterem, mert a kedves megrendelo azt valasztotta, amit (nem volt csere alkatresz es replikacio sem). Az illetekes azt kapta, amikor kerte, amikor problema volt, akkor pedig felszisszent, aztan nezte mit lehet tenni. Osszesegeben visszanezve jo megoldas volt, ugy tippelem, hogy TCO-ban magasan ez a megoldas nyert ott es akkor. Amugy nem egy takolmany helyrol van szo.

> A cikkben említett felhasználásra (pornógyűjtemény otthoni tárolására) teljesen jó. A cikkben említett megoldás nem is való ebben a formában másra, több sebből vérzik. Egy szem tápegység pl. ami ha beszarik és nincs másik 800W-os kéznél, akkor halott ember vagy. Nem is kell tovább menni.

Ki az a huje, aki a cikkben szereplo storage-on akarja ezt csinalni?
De ha meg be is szarna a tap, miert feltetelezi, hogy nincs tartalek?

> Ráadásul a csávó írta, hogy az első táp be sem vált, kísérletezéssel választotta ki a jelenlegit. Most akkor ez mennyire megbízható egy olyan storage megoldással szemben, amiben a tápot mérnökök méretezték stb.

Mutasson ra vki, mennyivel lesz megbizhatobb a mernokok altal beletervezett storage tapja a nem mernok altal beletervezett bika tapnal.
Lehet fikazni a "takolt" storage-ot, de ertelmesen. Amit trey irt, azt tiszta hujeseg.

> Hosszasan lehetne sorolni a problémákat.

A jelen esetben csusztatasokkal tamasztotta ala az erveit, semmit nem er.

Megjegyzem, megcsak SLA-t sem definialt senki, vagy mitol lesz a vallalati vallati kategoria.

> meg igy is lehet ordatlan szivasokba belefutni

Pontosan. Viszont a megoldas nem az, h 5x annyit koltok, aztan imadkozom, hanem a feladatnak es a lehetosegeknek megfeleloen felkeszulok a szivasokra es azokat kezelem akar elore akar utolag.

Elmultak szerintem mar azok az idok, amikor egyszeruen ra lehet huzni a temara nehany jol ismert receptet es abbol kenyelmesen meg lehet elni.

"Az elobbinel lehet akar az is, h az alkatresellatasra 0 percet kell varni (potalkatresz)."

Amit leállás nélkül cserélsz. A komolyabb (, de alja) storage-ok minden része redundáns már. Beleértve a kontrollert, a tápot. Mutasd már meg a tákolt storage-odon az alaplapcserét légy szíves. Vagy a menet közbeni redundáns controller-en a firmware upgrade-et, zéró leállással és folyamatos kiszolgálással úgy, hogy nem kell azon imádkozni, hogy mikor kulázik maga alá. Az ugye megvan, hogy ha ezekkel valami gond van, akkor az első kérdés az lesz a gyártótól, hogy a legfrissebb firmware-rel tudod-e reprodukálni? Ilyen megy a storage offline-ba? Vagy mi lesz? Hamar lesz ám kifliszáj... Lefelé.

Vagy hogyan lesz ezekkel normális enterprise menedzsment?

"hogy TCO-ban magasan ez a megoldas nyert ott es akkor. Amugy nem egy takolmany helyrol van szo."

Ott ahol a napokig álló storage nem termelt semmi veszteséget, ott lehet.

"akkor pedig felszisszent,"

Mégiscsak érzékenyen érintette.

"Az illetekes azt kapta, amikor kerte,"

Csak ha nem másnak dolgozol, hanem magadnak, akkor tudod, hogy te mit akarsz kérni.

"Mutasson ra vki, mennyivel lesz megbizhatobb a mernokok altal beletervezett storage tapja a nem mernok altal beletervezett bika tapnal."

Ott van benne a cikkben. Beletett egy jó nagyot, aztán kiderült, hogy nem mindegy, hogy "Corsair 860i" vagy "Seasonic Platinum 860". Kísérletezgetés vs. hozzáértő tervezés és széleskörű tesztelés. Pedig 860 (jó nagy!) volt mindegyik.

"De ha meg be is szarna a tap, miert feltetelezi, hogy nincs tartalek?"

Amit leállással cserélsz?

És itt még csak a hardver egy részének kivesézésénél tartottam, a ZFS on Linux megbízhatóságára, támogatottságára (tainted kernel), a megfelelő egyéb eszközök (hálókártyák, host bus adapterek esetleges FC kártyák kiválasztása körüli dolgokra ki sem tértem).

Ezek olyan döntések, amit ha te hozol meg (nem kell az ügyfélre ráverni, ha a tákolt lesz az olcsóbb (legalábbis kezdetben) valószínűleg azt választja, de ha közlöd vele, hogy ha beszarik, akkor a drágább olcsóbb lehetett volna, nem biztos, hogy az mellet dönt), akkor neked kell vinni a balhét. És ha majd Linus Torvalds azt írja vissza egy állandóan eldumpolt kernelre, hogy "STFU, tainted", majd találsz egy jó magyarázatot az ügyfél/vezetés felé, hogy miért esik-kel a rendszer.

--
trey @ gépház

> Mutasd már meg a tákolt storage-odon az alaplapcserét légy szíves

Ezt is meg lehet oldani (replikacio a kulcsszo), de miert akarnam menet kozben kicserelni? Szo sem volt ilyenrol. A legtobb "vallalat" siman kibir egy alaplapcserehez szukseges leallast. Ha nem, akkor ugy kell tervezni. De nem latok ilyen peremfeltetelt fent.

> megy a storage offline-ba? Vagy mi lesz?

OMG, eddig nem is tudom hogy maradt fenn a vilag:)

> Vagy hogyan lesz ezekkel normális enterprise menedzsment?

A nem storage gepeid eseten talan nem csinalod? Pont ugyanugy.

> Ott ahol a napokig álló storage nem termelt semmi veszteséget, ott lehet.

Mondj 1 okot, amiert napokig allnia kellene a storage-nak csak es kizarolag azert, mert takolt.

> "akkor pedig felszisszent,"
> Mégiscsak érzékenyen érintette.

Hogyne. Viszont ez benne volt a pakliban.
Ellenben ha a gyari storage-ra kellett volna atutalni a kb. 4-5x akkora osszeget, rendesen orditott volna.

> Csak ha nem másnak dolgozol, hanem magadnak, akkor tudod, hogy te mit akarsz kérni.

Ezt nem ertem. En nyujtom neki a lehetosegeket mellette szamokkal, o meg kivalasztja. Ez a dolga, ezert kapja a fizujat (nem mellesleg a konkret esetben az osztalek 50%-at is).

> Pedig 860 (jó nagy!) volt mindegyik.

Egesz pontosan mi a kulonbseg akozott, hogy ha veszek 1 szar tapot, amivel nem mukodik, mintha veszek egy szar dobozos storage-ot, amivel ugyanugy nem mukodik vmi?
Elszurta. Pont ugyanugy el fogja tudni szurni mashol is. Nagy cucc, kicserelte par fityingert. Meg o is be tudta vallalni, vallalati kornyezetben is talan belefer.

> Amit leállással cserélsz?

Es akkor mivan? Tervezett leallas, csokolom mukodik ujra.
Leirom megegyszer szepen lassan: Oda tesz az ember SPOF eszkozt, ahol belefer. Vallalatnal is. Ahol nem fer bele, oda nem tesz. Ha megis, szamol vele.

De mondok vmit, a storage is spof, csak 1 van belole, kell egyet replikalni, ugyhogy vegyel abbol is kettot. De jobb, ha 4-et, mert azt a part is kene replikalni, ha a telephelyeden tuz ut ki.
Viszont az igazsag az, h .ru barmikor megtamadhat minket, a legjobb az lenne, ha duplaznad egy masik foldreszre. De oszinten szolva nem lennek nyugodt, ha a vallalat megallna, csak mert eltalalt minket eltevedt kisbolygo, az igazsag az, hogy ez egy VALLALATI storage, az pedig 2014-ben nem az, h nincs a HOLD-ra is replikalva.

> dolgokra ki sem tértem

Nem is kell. Barmikor osszeallitok neked egy olyan rendszert, ami rosszul fog mukodni. Ahhoz nem kell esz.

> Ezek olyan döntések, amit ha te hozol meg (nem kell az ügyfélre ráverni, ha a tákolt lesz az olcsóbb (legalábbis kezdetben) valószínűleg azt választja, de ha közlöd vele, hogy ha beszarik, akkor a drágább olcsóbb lehetett volna, nem biztos, hogy az mellet dönt), akkor neked kell vinni a balhét. És ha majd Linus Torvalds azt írja vissza egy állandóan eldumpolt kernelre, hogy "STFU, tainted", majd találsz egy jó magyarázatot az ügyfél/vezetés felé, hogy miért esik-kel a rendszer.

Kar is vitatkozni. A sok huje mennyire bator.
Mondjuk en meg sosem leveleztem Linus-szal, biztos en rontok el vmit:/

t

Jaja, van mindenre magyarázatod:

- tegyünk bele jó hardvert
- tegyünk bele redundanciát, hotplug eszközöket
- öljünk bele csillió mérnökórát (tervezés, kísérletezgetés, menedzsment kitalálása, replikáció összereszelése, megfelelő iSCSI target összeimádkozása stb.)

A végén ezeket összeadva kiderül, hogy a polcról levett olcsóbb lett. Ráadásul ha mindezt határidőre kell, akkor éjszakázzunk is vele, hogy kész legyen időre! Sőt, ha lejár az eszközök garanciája, akkor imádkozzunk, hogy legyen a sarki bótban ugyanolyan 2 év múlva, vagy vegyük 10-et a polcra.

Ez is egy út. Legyen ez a tiéd.

Egyébként 6-szor írtam le, leírom 7-edszer is. Nincs ezekkel baj, meglehet a helyük. Azt kell megtalálni. Hogy ki hova teszi, az ízlés (és bátorság) kérdése.

--
trey @ gépház

Nem követem a szálat, de mi használunk tákolt storage-t olyan környezetben is, ahol pár milliós veszteséget termelne egy leállás per óra, az adatvesztés pedig előre nem is látható kártérítési perekkel járna. Nálunk ezek 24-32 diszkes szerverek software raid6-tal, replikálva, több szinten snapshot-olva és archiválva.

Az biztos, hogy bőven van buktató a dologban. Ha nem saját magam csinálnám, csak azért lennék felelős, hogy menjen a dolog, erősen gondolkoznék a gyári storage-ban. Így is vannak korlátok -pl a BBWC hiánya vagy a middleware adottságai- amiket nem lehet figyelmen kívül hagyni az alkalmazásnál, de azért szépen lehet építeni ezekre is.

Mondjuk az eddigi legnagyobb adatvesztést épp gyári SAN okozta, amiben a forgalmazó mérnökei akartak firmware-t frissíteni. Kijöttek, a redundáns kontrollerek fejreálltak, táp kihúz-bedug, az összes image lesérült, felük kb javíthatatlanul.
Nem tudom, az ügyfélnek milyen szerződése volt a forgalmazóval, de azok, amint a reboot után látszott a LUN és az új firmware verzió, otthagytak a picsába, hogy innen ők végeztek.
Az ügyből nem volt kártérítés; tanulság: jól át kell olvasni szerződést. :)

A feladatnak szerintem több megoldása van.
A legegyszerűbb nyilván az, hogy egy ilyen aktív dobozod van, minden forgalom átmegy rajta, az igazi targetek felé pedig egy egyszerű CDB FIFO-t vezetsz a módosítási műveletekről, az olvasási műveleteket meg load balance-olod (figyelembe véve persze az írási queue állapotát).
Ha az egyik target megdöglik, a queue telik, ha visszajön, elkezded ráírni a módosításokat, és ha szinkronban van, már olvasni is tudsz róla (illetve addig is, ha a queue-t is figyelembe veszed).

Eddig ugye ez a proxy lesz a SPoF a storage helyett, de azért itt IP szinten sok lehetőséged van játszani, failovert viszonylag egyszerűen fogsz tudni csinálni, mindössze azt kell eldöntened, hogy milyen rendelkezésre állási és megbízhatósági garanciát akarsz adni. Lényegében a gépek állapotát és a queue-t kell jól szinkronizálni, ez elég gyakori feladat, nem storage jellegű.
Ha fontos (márpedig nyilván az) a rendelkezésre állás és az adatbiztonság is, pld. egy három gépes clustert tudnék ide elképzelni, ami az írásokat akkor igazolja vissza az initiatornak, amikor legalább két gépen stable storage-on van a cucc. RAID5 proxy, egy gép kieshet. :)
Ha tudod garantálni, hogy a forgalom mindig csak az aktív node-ra érkezzen, kész is van a SPoF-mentes dzsunkastorage szinkronizáló cucc, amivel vmware alá tudsz szarból várat építeni. (nyilván vannak még aspektusai a dolognak, amiket kezelni kell)
Szerintem ezt kb. egy hét alatt összelegóznám neked tesztpadon valami scriptnyelvben. Te profibb vagy, neked már gyors is lenne ennyi idő alatt. :)

Ilyen blokkokat elég jól fogsz tudni load balance-olni is, pld. target LUN-onként (mondjuk IP címekre mappelve), nem ez lesz a szűk keresztmetszet.

Ami bonyolultabb, az aktív-aktív, de a fenti miatt szerintem ennek az igénynek a létjogosultsága kevés.
--
zsebHUP-ot használok!

Olyan feltételeket hoztam, ami a mai magyar valóságban megállja helyét. Te meg jöttél olyasmivel, hogy az amerikai Livermore kutatóközpontban megállja a helyét. Hogy melyik relevánsabb? Attól függ, hogy földrajzilag hol vagy, illetve mit kell megoldanod.

--
trey @ gépház

Fuggetlen a foldrajzi helyzettol.
Ha vki egy tapos gepet vesz, az szamoljon azzal, hogy attol megallhat a gep. Ha nem vesz melle tartalekot, akkor pedig allva is marad.
Ha a storage beszallitotol nem 2 oras, hanem 24 oras supporto veszel, akkor azt kapsz (occsobbert).

Ez igy lesz az USA-ban, nalunk es Iranban is.
Barmelyikhez elerheto az azonos feltetelek, a takolt es a brand storage-nal nem ebben lesz a kulonbseg.

> glustert szerintem lehet ra rakni

Van is, mukodik. Kb. 0 terhelessel. De ez azert keves. De mivel nincs ra szuksegem, nem uptodate-ek az informacioim. Siman lehet, hogy az ujabb fejleszteseknek koszonhetoen mar gyors es stabil (xattr=sa az erintett property, ha jol sejtem).
Valojaban magaban a glusterben sem bizom annyira...

> a kerdes NFS/iSCSI felol volt :)

Lustre alatt van.
Amugy most latom, h a kerdezo konkretan a virtulazaciora kerdezett csak, bocsanat.
Az LLNL-ben ha jol tudom, arra nem hasznaljak.

( zrubi v | 2014. 09. 02., k – 15:00 )

Érdekes lenne majd újra visszatérni erre néhány hónap aktív használat után is.

Szvzs a szűk keresztmetszet az lesz, ahogy (NFS, SMB, iSCSI) kiszolgálja mindezt a kliensek számára....

--
zrubi.hu

Az iXSystems már sok éve gyárt FreeBSD/ZFS alapú tárolókat mindenféle nagy nevektől származó 100% támogatottsággal (igen, VMWare is közte van), nagy kapacitásra, nagy teljesítményre vagy mindkettőre. Szóval ez nem egy kísérleti dolog. Sajnos itthon egyenlőre nem forgalmazza senki.

Persze a Linux port még ehhez képest friss, viszont nem a semmiből kellett megcsinálni, mert az egész ZFS világ alá megcsinálták az OpenZFS projektet, hogy az összes platformon elősegítsék az egységes és jól működő ZFS-t.

( Zahy v | 2014. 09. 02., k – 22:56 )

De jó lenne, ha ennyit elkölthetnék egy itthoni filmszerverre! Mondjuk biztosan nem Linuxszal, hanem FreeBSD-vel csinálnám meg, de hát mindenki úgy hülye a saját szemétdombján, ahogy akar, ugye.

( _ventura_ v | 2014. 09. 03., sze – 14:13 )

Látom megy itt a harc :D Lehet kicsit félreérthető voltam. A HW nem érdekel hanem a linux + ZFS kombó, mennyire stabil, megbízható. Most solaris 10 + ZFS kombó van, 4 éve teszi a dolgát soha 1 gond nem volt vele. Ezért lennék kiváncsi a linux+zfs kombóra. Főleg olyantól aki üzemeltet ilyet és nem otthoni pornó tárolásra, hanem SAN/NAS célokra használja 7/24/365-ben. Ugye pl.: erről megy a cég, vagy hasonló.

Fedora 20, Thinkpad x220