1) nepsal sem raid 50. Psal sem RAID5 + RAID1 - uzivatel ma 6 disku a ma to na lab - za me naprosto idealni setup Chovani v degraded stavu muzete ovlivnit nastavenim radice, kdy muzete prioritizovat rebuild nad i/o a obracene. Souhlasim s tim ze vice disku v raidu/logical volumu => vetsi moznost ze nejaky selze. Ncimene jak se s tim to ci ono pole popasuje zalezi na name. Meli jsme to treba HPE Evu ktera delala diskgroupy po 12 discich a nikomu to nevadilo. Meli jsme tu treba ibm storvize, kde byl aktivni cely rack a taky to nikomu nevadilo.
Moje chyba, psal jsi raid 5 + mirror, pochopil jsem to jako 50. Prioritizovat rebuild, ano, pokud máš spare disky, může to být background proces, to je asi nejvhodnější řešení při použití pětky.
2) Na server raid radicich zase ocenuji prediktive failure, kdy casto dostane hlasku o tom "ze se neco deje", ncimene disk funguje dal a pole neni v degraded stavu. Vendori takova disky uzvanvaji jako vadne a automaticky je meni (ne ze by pro lab to bylo smerodate), ale mate imo vetsi cas tim neco udelat.
HW Raid skryje před ZFS cenná data o chování disků a přidává falešné flushe, tj. zvyšuje se riziko ztráty dat.
Jak ? Prosim rozvest
Jj, tak to i běžně měníme jak na běžícím pásu a pro reklamaci se poskytuje jen report z řadiče.
ZFS má vlastní mechanismus jak detekuje vadný disk a případně ho nahrazuje za spare, pokud ale vidí virtuální blokové zařízení, jeho metriky neodpovídají stavu fyzického disku (to je v případě třeba vytvoření raid 0 s jedním diskem jako simulace JBODu/HBA, když to řadič neumí). Raid zpravidla zápisy strká do cache a reportuje jako zapsané do OS (narozdíl od HBA), opakované čtení čte data z cache, ikdyž se na pozadí ještě nemuselo podařit je zapsat fyzicky na disk, zfs se pak chybně může domnívat, že jsou data persistovaná.
Samozřejmě, když tyhle omezení znám, není to překážka, není velký problém data z disků do zfs reportovat jinou cestou nebo vlastním daemonem aktivovat spare disky. Stejně tak není problém mít agresivnější a častější self healing. U datových serverů s velkým provozem cache v řadič zpravidla není schopná držet moc dat, takže problémy se záhy ukážou. Jde s tím žít, ale musíš se podle toho zařídit.
Qemu a jeho qcow sice poskytuje podobné funkce pokud jde o snapshoty, ale jeho stabilita a rychlost jsou naprosto tristní.
Takovou zkusenost tedy opravdu nemam. Rychlost a stabilita je naprosto bezna s podobnout operaci treba ve vshpere
Pokud máš takovou zkušenost, tak je to vlastně super
. QCOW2 výkon padá s počtem snapshotů, propad proti rawu bez jediného snapshotu je ze zkušenosti při čtení asi 20 - 30 % (ano s qcow3 se to zlepšilo, ale nebyl jsem schopný pozorovat skoro nulový rozdíl proti raw, jak avizují v dokumentaci), to není málo. Ano pokud to porovnáváš v single thread, rozdíl je nicotný, pokud ale nad tím máš VM s více fyzickými cpu a konkurenčně čteš/zapisuješ, problém je na světě. Přímé porovnávní proti vsphere jsem nikdy nedělal. QCOW2 při růstu zůstává na jednom blokové zařízení a velmi špatně se rozděluje na více fyzických disků (musíš použít raid), režije při hodně snapshotech a velikosti je značná, to s vspere jsem nepozoroval. Šachování s linkem a vlastní shardering je prostě už příliš komplexní na nějakou údržbu.
QCOW2 má důležitá data v hlavičce souboru, kde se často přepisují, některé věci ti umí qemu-img check -r opravit, ale některé ne. Poškozenou hlavičku jsem viděl už několikrát při chybě disku při zápisu, kupodivu poslední dobou s ssd disky to je častější než kdy dříve. Pak je to na velkém laborování s hlavičkou a dát se ručně nějak rekonstruovat, zejména pokud víš, že k chybě došlo v posledních zápisech. Nějaká kontrola integrity zapsaných dat se s qcow2 moc neděje, zabudované šifrování tomu ale velmi pomáhá.
Slusnej standartni hw raid typu p420 kterej se rve do kazdyho proliantu je imo naprosto dostacujici pro 90% entry/midrange prostredi
To s tebou souhlasím, pokud se někdo musí ptát na zfs, nejspíš to není systém pro něj a obyčejný ext/btrfs nad hw raidem mu poslouží daleko lépe.
Zobrazit příspěvky
