Zakladne pravidla swRAIDu typ 1 (diskuse)

[Honza "tux" Friesse]

Osobně se mi osvědčil výběr disků WD a Maxtor. Většina WD odejde do záruky (a potom až hodně let po záruce) a Maxtorů po záruce. Samozřejmě nejlepší jsou SCSI disky, nicméně když je nutné cenu serveru srazit dolů, je IDE disk v RAID také hodně dobrá volba.

Malý offtopic: Co byste dnes doporučili za HW do serverů? Mnou ověřená (naprosto stabilní) kombinace VIA KT800Pro + AMD 64 (939) se již neprodává, Intel je děsivě drahý (a na většinu menších serverů naprosto zbytečně rychlý), a NVidii nějak pořád nevěřím.

[Michal Fecko]

Osobně se mi osvědčil výběr disků WD a Maxtor. Většina WD odejde do záruky (a potom až hodně let po záruce) a Maxtorů po záruce. Samozřejmě nejlepší jsou SCSI disky, nicméně když je nutné cenu serveru srazit dolů, je IDE disk v RAID také hodně dobrá volba.

Preferujem odlisne Seagate + WD (aj ked teraz na serveri mam tusim 3xSG ) Ano SCSI su lepsie, ale povacsine ak niekto robi RAID nad SCSI diskami tak pouzije napr. Adaptec - tento blog je fakt iba o PATA/SATA, teda prevazne LOW PRICE serveroch.

Malý offtopic: Co byste dnes doporučili za HW do serverů? Mnou ověřená (naprosto stabilní) kombinace VIA KT800Pro + AMD 64 (939) se již neprodává, Intel je děsivě drahý (a na většinu menších serverů naprosto zbytečně rychlý), a NVidii nějak pořád nevěřím.

Urcite P3/P4 + Intel chipset/doska popr. doska s VIA, Nvidia chipsety skor do desktopov.

[cezz]

Preferujem odlisne Seagate + WD

To uz zas tak odlisne od Maxtor + WD byt nemusi Viz http://www.seagate.com/maxtor/.

[Michal Kubeček]

VIA poslední dobou na AMD64 platformu dost kašle, takže jsem přešel na ATi a zatím nemám důvod si stěžovat.

[Honza "tux" Friesse]

VIA poslední dobou na AMD64 platformu dost kašle

přesně. Navíc ji teď označují nějak velmi podobně jak KT800Pro, ale je to úplně něco jiného, síťovka funkční snad jen s prop. R1000, který spíš nefungoval než fungoval.

takže jsem přešel na ATi a zatím nemám důvod si stěžovat.

Osobně mám v ATI v NB, a výkonostně nic moc (pamět DDR2 a rychlost jak SDRAM),ale fakt je, že je to Intel procesor (rok zpět). Potom jsem viděl jednu desku s ATI na desktopu a zlobil tam časovač (nějaký problém, že došlo 2x IRQ, šlo opravit parametrem jádra) a ještě ne úplně ideálně fungoval SATA disk (opět rok zpět). Ale asi nějakou ATI/AMD zkusím, stejně nemám moc na výběr.

[Michal Fecko]

Osobne by som si na NB zvolil Intel chipset.

[Honza "tux" Friesse]

To byl mé osobní přehlédnutí. Můj poslední Intel byl Celeron 366, pak už jen AMD, takže jsem ztratil přehled o Intelu. No a byla výborná nabídka IBM/Lenovo (tehdy ještě takový přechod) TP R51e, za 15000 (+- nějaká tisícovka, už si to nepamatuju) bez DPH. U něj bylo napsáno Pentium M, tudíž jsem předpokládal, že je to Centrino... Nebylo. Nicméně ten NB chodí docela stabilně, až na strašně pomalou paměť, takže to není tak hrozné.

[blaf]

- proc museji byt oba disky jako master a na samostatnem radici? Nejak k tomu nevidim duvod.

- pozadavek aby byly disky od ruznych vyrobcu, resp. ruzny model atd.. je podle me kravovina... proc?

- vytvaret si samostatny /backup asi nebude to prave; ochrani to tak maximalne od smazani lidskou chybou (ale kvuli tomu to nemusi byt samostatny oddil) a nebo od poskozeni FS chybou v softwaru (a to se na 99.9999% muze stat leda tak kdyz pouzivate unstable moduly nebo pretaktujete komponenty v pc).

[trekker.dk]

proc museji byt oba disky jako master a na samostatnem radici? Nejak k tomu nevidim duvod.

Nemusí, ale je to vhodné. Stejně tak, že je důležité mít CDROM připojenou odděleně od RAIDu. Není to důležité, ale je to vhodné

pozadavek aby byly disky od ruznych vyrobcu, resp. ruzny model atd.. je podle me kravovina... proc?

Snížená pravděpodobnost, že dva výrobci budou mít ve stejný čas vadnou sérii.

[Michal Fecko]

- proc museji byt oba disky jako master a na samostatnem radici? Nejak k tomu nevidim duvod.

ak odide jeden disk na samostatnom radici druhy to nepociti, ak disk odide na spolocnom radici s druhym diskom tak s najvacsou pravdepodobnostou tento degradovany RAID budto spadne alebo nebude pracovat korektne do vymeny havarovaneho disku.

- pozadavek aby byly disky od ruznych vyrobcu, resp. ruzny model atd.. je podle me kravovina... proc?

svojho casu bola jedna "vydarena" rada Hitachi (tusim z madarskeho zavodu) a ta mala tusim 70 - 80% (!) kazivost. V tomto pripade tusim firma hitachi celila niekolkym sudnym zalobam koli strate dat pretoze disky tejto rady odchazali v rovnakom casovom obdovi - ak boli v tom case 2x rovnake Hitachi disky v raide a odisli napr. do 2 dni (vikend) tak ste prisli o data, preto je lepsie znacky/typy/rady kombinovat

- vytvaret si samostatny /backup asi nebude to prave; ochrani to tak maximalne od smazani lidskou chybou (ale kvuli tomu to nemusi byt samostatny oddil) a nebo od poskozeni FS chybou v softwaru (a to se na 99.9999% muze stat leda tak kdyz pouzivate unstable moduly nebo pretaktujete komponenty v pc).

samostatny odiel snad koli odlisnemu FS. a je fakt ze RAID chrani proti nepredvidatelnym udalostiam ale oddeleny /backup s odlisnym FS chrani proti ludskemu erroru a nejakemu tomu "skrytemu" bugu na ostatnych FS v RAIDe. Dobre je takztiez po synchronizacii /backup particie so zvysnymi tuto umountnut z dovodu napr rm -rf.

[blaf]

ad a) to mi prijde jako prijatelne vysvetleni. Prece kdyz spadne jeden disk z raidu (at uz to je jako master nebo slave), tak ho co nejdrive odstranim z pocitace a du to reklamovat - ne? Beru vysvetleni od Michala Kubecka (viz. nize), ze to je predevsim kvuli vykonu.

ad b) jj, to sem cekal ze o tom zase uslysim. Mimochodem, jeden takovej disk z prave te "vydarene" serie z madarske tovarny od IBM mi uz nekolik let spolehlive chrochta v pocitaci Yeah, I'm lucky! Celkem vzato, asi to nemuze skodit, ale taky to neni zadna tragedie kdyz si koupim dva identicke disky do raidu. Navic kdyz to zacnete kombinovat, tam prece mate vyssi pravdepodobnost ze aspon jeden disk z takove vydarene serie se vam povede koupit

ad c) O tom "rm -rf" slysim od nasich tucnaku ve firme takrka ob den. Na vlastni oci jsem takoveho IDIOTA jeste nepotkal. Navic, by to asi muselo byt pod rootem a tak podobne... Vlastni myslenka /backup adresare je fajn, ale nechapu proc to musi byt samostatna particie - jak pise autor.

[blaf]

Ach boze! melo to byt: ad a) to mi NEPRIJDE jako prijatelne vysvetleni. ...

[Michal Fecko]

Ach boze! melo to byt: ad a) to mi NEPRIJDE jako prijatelne vysvetleni. ...

Viac tu: http://www.abclinuxu.cz/blog/show/192327#14

[Michal Fecko]

ad c) O tom "rm -rf" slysim od nasich tucnaku ve firme takrka ob den. Na vlastni oci jsem takoveho IDIOTA jeste nepotkal. Navic, by to asi muselo byt pod rootem a tak podobne... Vlastni myslenka /backup adresare je fajn, ale nechapu proc to musi byt samostatna particie - jak pise autor.

Tak si skusme predstavit ze mame server ktory nam niekto hackne (alebo staci zle zvolene nastavenie sudo) a hacker ktori nam masinu hackol alebo nevedomi uzivatel daju rm -rf. Co potom ak nemame zalohovanie na iny stroj/dat nosic?

[blaf]

uf, a jak to souvisi s tim doporucenim z blogu ze /backup ma byt samostatna particie?

[Michal Fecko]

uf, a jak to souvisi s tim doporucenim z blogu ze /backup ma byt samostatna particie?

napr. tym umountom pri backupe, to sa da iba ak je to samostatna particia, ak mame stastie a hacker-zaskodnik si tu osobitnu odpojenu particiu nevsimne tak dolezite data mame uchovane - viem je to pritiahnute za vlasy, ale pride mi to ako vcelku logicke riesenie zalohovania proti chybe/utoku ludskeho faktora.

[blaf]

jo prave, je to pritahnute za vlasy... Ale jinak se proti tom neda nic namitnout

[frEon]

ad c) O tom "rm -rf" slysim od nasich tucnaku ve firme takrka ob den. Na vlastni oci jsem takoveho IDIOTA jeste nepotkal. Navic, by to asi muselo byt pod rootem a tak podobne...

podivej se na muj profil, mam tam fotku

[frEon]

ps: nejak se mi tam vpletla mezera a misto rm -rf neco/* sem napsal rm -rf neco /* , nastesti to byl backup systemu do kteryho sem byl zrovna chrootlej, takze nic zavaznyho...

[trekker.dk]

ad a) to mi neprijde jako prijatelne vysvetleni. Prece kdyz spadne jeden disk z raidu (at uz to je jako master nebo slave), tak ho co nejdrive odstranim z pocitace a du to reklamovat - ne?

A pokud půjde o server, tak ho máš offline, než ten disk vyndáš. Nemůžeš spoléhat na to, že když jeden disk vypadne, že nezablokuje celou sběrnici.

[Michal Fecko]

ad a) to mi neprijde jako prijatelne vysvetleni. Prece kdyz spadne jeden disk z raidu (at uz to je jako master nebo slave), tak ho co nejdrive odstranim z pocitace a du to reklamovat - ne?

A pokud půjde o server, tak ho máš offline, než ten disk vyndáš. Nemůžeš spoléhat na to, že když jeden disk vypadne, že nezablokuje celou sběrnici.

A navyse server moze byt aj od teba par stoviek km, kym sa disk vymeni, moze to trvat aj tyzden a radsej tyzden v degradovanom rezime ako offline...

[Michal Kubeček]

proc museji byt oba disky jako master a na samostatnem radici? Nejak k tomu nevidim duvod

Pokud budete paralelně přenášet data na oba (což je u RAID 1 docela obvyklé), pak to na výkonu poznáte.

[blaf]

aha, vyborne, to dava smysl. Mate bod za 1. rozumnou odpoved v teto diskuzi Ten zbytek od ostatnich mi tady zatim prijde jenom jako "vareni z vody". diky.

[Michal Fecko]

Ten zbytek od ostatnich mi tady zatim prijde jenom jako "vareni z vody".

"Z vody nevarim", ak tvrdim ze master/slave raid1 sposobuje aj ine problemi ako ubytok vykonu. Tak namatkovo: [1][2]

[dustin]

Při použití raidu s jedním redundantním diskem by všechny měly být na sobě maximálně nezávislé, aby se snížilo riziko, že vypadnou dva najednou. U konfigurace master/slave jsou na sobě docela závislé, spadlý master s sebou může vzít i slave a je po raidu. Samozřejmě také nemusí, ale riziko je nesporně vyšší.

[Michal Fecko]

Při použití raidu s jedním redundantním diskem by všechny měly být na sobě maximálně nezávislé, aby se snížilo riziko, že vypadnou dva najednou. U konfigurace master/slave jsou na sobě docela závislé, spadlý master s sebou může vzít i slave a je po raidu. Samozřejmě také nemusí, ale riziko je nesporně vyšší.

Presne.

[blaf]

urban legend?

[dustin]

Již se mi stalo, že spadlý disk zasekl celý onboard IDE řadič, takže v té chvíli neběžel ani druhý IDE kanál.

Je to vše o pravděpodobnosti a nebudu si zbytečně koledovat o problém. Ale (naštěstí) je to každého věc :)

[wake]

Elektronika na Master ridi i Slave - takze kdyz Master elektronika chcipne, chcipne i pristup na Slave.

[Shadow]

disky by nemali byt od jedneho vyrobcu, ak ale su minimalne by nemali byt rovnakeho typu ak ani to sa nemoze splnit tak nech aspon su rozneho datumu vyroby

A kruci. Pozdě. Snad pomůže kontinuální smartd a mdadm monitorování napojené na mobil. I kdyby to byla vadná série, snad neselžou oba dva zároveň.

[Radek Hladik]

S RAIDy mám docela dost zkušeností. Můžu potvrdit, že umření celého PATA řadiče není vůbec urban legend, ale naprosto běžná věc u onboard řadičů. Co se týče SATA řadičů, tak situace je o mnoho lepší, většina řadičů umí a podporuje hotplug, leč i tak jsem viděl situaci, kdy kernel zkusil zresetovat port s vadným diskem a to na půl minuty umrtvilo celý řadič. Půl minuty není moc, ale například za tu dobu vyprší hodně timeoutů.

To že se vyplatí brát dva různé disky je také docela dobré, protože každá věc, která sníží pravdědopodbnost souběžného selhání obou disků je dobrá věc . Pro důležité stroje také doporučuju mít další disk jako náhradní a ne čekat, až se vadný disk vyreklamuje. Je dobré si uvědomit, že v případě havárie jednoho disku dojde k zvýšení zátěže toho druhého. A to jak samotným provozem (u mirroru stoupne počet čtení na dvojnásobek) tak i následnou replikací dat na nový disk. Jednou jsem vyměňoval vadný disk v RAIDu 2x během jednoho dne, když nový disk umřel právě při rekonstrukci RAIDu. A to to byl disk, který jsme před tím několik hodin bez problému testovali.

K zápisku v blogu bych přidal následujících pár poznámek. Je důležité si uvědomit, proč se RAID dělá. Pokud se jedná o zvýšení výkonu při čtení, zabránění ztráty dat při havárii disku nebo zvýšení dostupnosti serveru. Například pokud jde jen o zvýšení bezpečnosti dat, pak je někdy lepší nedávat disky do RAIDu, ale udělat dva FS a data nějak synchronizovat nebo mirrorovat na úrovni aplikace. Člověk se tak vyhne problému, kdy disk je OK, ale podělá se FS. Pokud je naopak třeba vysoká dostupnost, pak je třeba vhodné koupit i druhý řadič, jen tak pro "klid duše".

[oron]

poprosim vas odbornikov o radu, kedze s raid az take skusenosti nemam ako sedujete stav raidu ja pouzivam:

cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sdb2[1] sda2[0]
      143355904 blocks [2/2] [UU]

md2 : active raid1 sdb3[1] sda3[0]
      76798656 blocks [2/2] [UU]

md0 : active raid1 sdb5[1] sda5[0]
      5116544 blocks [2/2] [UU]

md4 : active raid1 sdb6[1] sda6[0]
      2048192 blocks [2/2] [UU]

md3 : active raid1 sdb1[1] sda1[0]
      16876160 blocks [2/2] [UU]

a

 mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Wed Apr 25 11:42:27 2007
     Raid Level : raid1
     Array Size : 5116544 (4.88 GiB 5.24 GB)
    Device Size : 5116544 (4.88 GiB 5.24 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Wed Sep  5 11:24:08 2007
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : d1dafd96:8fd418f7:7221e1b8:8da95bb3
         Events : 0.388

    Number   Major   Minor   RaidDevice State
       0       8        5        0      active sync   /dev/sda5
       1       8       21        1      active sync   /dev/sdb5

ale stale som si nie uplne isty co to staci ? posialate si nejake taketo vypisy mailom, alebo nejake cez web ? proste kde-co sledovat ci sa "nieco" nedeje

a este mam

 ps aux | grep mdadm
mdadm --monitor --scan -t -f --pid-file=/var/run/mdadm/mdadm.pid

vdaka

[Michal Fecko]

posialate si nejake taketo vypisy mailom, alebo nejake cez web ? proste kde-co sledovat ci sa "nieco" nedeje

ak to pravidelne kontrolujes tak to staci, samozrejme je dobre si nastavit smartmontools a mdadm aby v pripade problemov posieli varovanie na mail.

[Shadow]

Jen doplňuji, že je stejně tak možné si kromě obyčejného e-mailu nechat zasílat ještě SMS nebo IM. Já používám řešení na bázi SMS.

[Radek Hladik]

Stačí kontrolovat u každého RIADu ten řádek s 2/2 a [UU] - 2 disky ze 2 a oba jsou UP. Když to selže, bude tam třeba 1/2 a [U_]. Další možnost je dívat se do souborů v adresáři /sys/block/md0/md a podadresářích. Tady je možné si pro každý RAID member zjistit, v jakém je stavu, nastavit minimální a maximální rychlost obnovy pro daný RAID, ručně pustit regeneraci nebo kontrolu RAIDu, atd...

Co se týče automatického hlídání, tak to záleží na tom, co je to za stroj, kolik jich máš a tak. Na jeden stroj (domácí workstation) stačí třeba to mdadm nebo nějaký vlastní skript, pro víc serverů je vhodné nějaké složitější řešení.

[Ondřej Čečák]

"Je dobré si uvědomit, že v případě havárie jednoho disku dojde k zvýšení zátěže toho druhého. A to jak samotným provozem (u mirroru stoupne počet čtení na dvojnásobek) ..."

Tomu nerozumim, linuxovy md raid 1 cte prece z obou, ne?

"Jednou jsem vyměňoval vadný disk v RAIDu 2x během jednoho dne, když nový disk umřel právě při rekonstrukci RAIDu."

Linux tu rekonstrukci, kdyz nejsou dalsi diskove operace, dela opravdu "poradne" -- stava se, ze levne lowendove radice to moc neustoji, systemove odezvy jsou dlouhe, ale po syncu je bezny a vyssi provoz uplne bez problemu.

[cezz]

"Je dobré si uvědomit, že v případě havárie jednoho disku dojde k zvýšení zátěže toho druhého. A to jak samotným provozem (u mirroru stoupne počet čtení na dvojnásobek) ..."

Tomu nerozumim, linuxovy md raid 1 cte prece z obou, ne?

Presne tak, pri RAID 1 cita linux z oboch diskov naraz a teda pri vypadku jedneho disku sa "citacia" zataz z chybneho disku prenesie na ten funkcny..