Quoting Tiberiu ATUDOREI <[email protected]>: > Scuze ca ma bag si eu in discutie mai pe la spartul targului, dar "nu ma > pot abtine". > As avea sugestia sa luati in considerare faptul ca orice asertiune facuta > de Ave legata de topicele software raid / extx / zfs are urmatoarele > argumente aditionale: > -este unul dintre putinii RHCE de pe forum > - lucreaza la o firma care ( pot sa zic fara urma de rusine) are maximum > de experienta pe chestiile enuntate mai sus ( ca sa fiu mai explicit pentru > cine nu ne cunoaste, avem si cate o adresa de mail cu @oracle.com in coada) > -prin natura jobului avem si maximum de expunere pe tehnologiile enterprise > storage ( in fiecare saptamina instalam sisteme cu SUTE de HDD-uri > enterprise, cu Linux si cu Solaris) > -din tot ce instalam noi, ZFS e folosit exclusiv pe Solaris (sa nu intram > in polemici legate de model de licentiere , zfs in kernel,samd,samd ... ) > - marea majoritate a sistemelor (95%+) sunt cu Linux .. Si cu chestiile > considerate "unreliable" mai sus in topic (mii de clienti aubagat miliarde > de dolari in sisteme mission-critical bazate pe tehnologii 'unreliable'... > si noi mai suntem inca pe piata...f.ciudat) > -de notat ca pentru chestiile de back-up sau care necesita alta categorie > de features (ZFS storage appliance) si pe sistemele cu Solaris se foloseste > totusi ZFS > -si dintre zecile de instalari (ale lui Andrei, sute in cazul meu) cu > mii/zeci de mii de discuri (nu exagerez deloc, un full rack de servere are > fix 200 de discuri) cred ca stim amandoi doar vreo 2-3 cazuri de servere > date cu rotile in sus din motive de storage (si in toate cazurile discurile > erau bine mersi, buba era in alta parte) > - ca sa iti faci o idee de diferenta de clasa de hardware intre discurile > de tip consumer si cele enterprise..cele enterprise au capacitatea cu un > ordin de marime mai mic, pretul cuun ordin de marime mai mare, ca si > indicatorii de fiabilitate zunt cu un ordin de marime mai mare (plus ca au > o gramada de tehnologii in plus gen amortizare vibratii, control de > temperatura, controlul vitezei de rotatie samd samd). Au si discurile > consumer tehnologii specifice dar in mare sunt cam opusul celor > entrerprise: control putere consumata, control acustica, parcare automataa > capetelor samd,samd. Ia baga tu niste discuri cu tehnologie green in > maretul storage zfs facut cu freenas si vezi peste cateva luni ce se > intampla (nu zic ca nu se poate folosi, trebuie sa iei anumite precautii si > sa faci un pic de tuning la discurile alea ... sistemul meu storage de > acasa e de 18 TB facuti exact cu ZFS si nas4free ... asta e un fork de > freenas dar care e bazat pe freebsd 9 si nu pe versiunea 8 ca freenas). Mai > arunca o privire din cand in cand pe valorile raportate de smartd ...dar > TOATE valorile. Si vezi si dinamica lor in timp. > Dar vad ca m-am intins prea mult. Cam asta era sugestia de baza: cand apar > observatii legate de storage facute de wolfy, mituc, ave sau altii mai > vechi de pe forum...eu zic sa luati notite daca nu va simtiti guru in > domeniu. Nu de alta dar noi lucram cu discuri cam de cand capacitatile se > calculau in zeci de megabytes si cu storage pe linux cam de vreo 15 ani > (cazul meu). > Si concluzia mea personala e : la storage nu poti sa faci din rahat bici ca > "pocneste" (dar numai o data).
Depinde de peisaj, adica daca iti tii "toate ouale intr-un singur cos" sau nu. Daca ai mai multe noduri/cosuri(N>2), prinse intr-un cluster, nu e nici o catastrofa daca face "poc" unul sau mai multe noduri, atata timp cat ai macar un nod supravetuitor! Si daca pe fiecare nod ai alt FS(ZFS/ext4/XFS/etc), si alt tip de raid(mdraid/hardware/ZFS mirror), SO din distributii diferite cred ca poti sa stai linistit si cu dotari non-enterprise! Garantat nu vor pocni toate odata! Si intotdeauna contextul/peisajul este esential. Se pot aplica tehnologii "proaste/nefiabile/non-enterprise" care intr-un anumit context/peisaj sa de rezultatele scontate, dar pot fi si situatii in care se aplica tehnologii "bune/fiabile/enterprise" care sa nu conduca la rezultatele dorite. Aici se face diferenta intre un admin bun/capabil si unul mai putin bun. Adica un admin bun, cu o dotare tehnica existenta, cu un anumit buget la dispozitie, obtine rezultatele dorite/asteptate (si constante in timp) de management! Sigur exista si situatii in care nu ai cum sa obtii rezultate intr-un anumit context. > On Nov 15, 2013 1:41 PM, "Andrei Pascal" <[email protected]> wrote: > >> 2013/11/15 Iulian Murgulet <[email protected]> >> >> > Quoting Andrei Pascal <[email protected]>: >> > >> > > Of of, m?i m?i... Po?i l?sa scrub-ul ?la s? ruleze , e drept - dar tot >> > î?i >> > > va fute discurile. ?i, întreb eu, CÂND ruleziscrub-ul? >> > >> > ... on-demand >> > >> >> C?t de des? Cum te asiguri c? l-ai rulat FIX înainte s? apar? orice >> posibil? corup?ie? Dac? datele s-au corupt înainte s? rulezi scrub-ul? >> >> >> > > Dac? îl rulezi la >> > > scriere ?i cu asta basta, nu e nici o diferen?? între ZFS ?i RAID 5 de >> > > exemplu. >> > >> > Ba da este. ZFS nu are "RAID-5 write hole"! >> > >> > Ok, fie cum zici tu. >> >> >> > > Plus c? e la mintea coco?ului c? într-un mirror nu pui discuri din >> > > acela?i lot de produc?ie. >> > > >> > > Argumentul cu rebuildul mirror-ului ZFS e valabil, dar, cum spuneam mai >> > >> > ... iar restul e poveste ? >> > >> >> Vezi mai sus... >> >> >> > > înainte, ZFS e ?i volume manager ?i filesystem iar suport comercial >> n-are >> > > decât pe Solaris. Pentru tine acas? îns? merge ?i pe *bsd, nu-i bai. >> Sau >> > > dac? nu te intereseaz? suportul. >> > > >> > >> > ... nu ma intereseaza. Merge in productie si la mine si la alte case mai >> > mari. >> >> >> M? bucur doar c? nu stau în Bra?ov, pe partea rela?iei mele cu statul >> mult-iubit. ?i sper c? datele despre mine nu sunt ?inute pe acele ma?ini, >> c? n-o s? am nici o pl?cere în a alerga pentru a le reface când acel ZFS o >> va lua prin copaci. >> _______________________________________________ >> RLUG mailing list >> [email protected] >> http://lists.lug.ro/mailman/listinfo/rlug >> > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ================ ATENTIONARI ============== - pentru atasamente tip Office va rugam sa folositi format OFFICE 97; - nu trimiteti date personale (CNP, copii dupa acte de identitate etc). O lista completa cu reguli de utilizare exista la: http://gw.casbv.ro/forum_smf/index.php?topic 00.msg3106#msg3106 C.A.S.J. Brasov - B-dul Mihail Kogalniceanu, nr. 11,Brasov [web-site]: http://www.casbv.ro [forum]: http://gw.casbv.ro/forum_smf/index.php ===================================== _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
