RAID5 med Windows server

[Gjest Slettet-Pqy3rC]

Kjører med Promise EX8350

 

Liker ikke software raid fordi;

 

1)

Sucks CPU, treeeeigt!

 

2)

Dårlig funksjonalitet og usikker kompabilitet.

 

Liker ikke hardware raid fordi;

 

3)

Mye bedre funksjonalitet i io-kontrollere m egen cpu , f.eks

bakgrunns speiling/migration/rebuild/repair.

 

4)

Kontroller func er de samme i alle OS, Promise webPAM gir full kontroll over kortet/kortene via java apps.

[Torbjørn]

Er det den nye disken som krasjer vil det ikke ha noe å si, er det en annen er du "på dypt vann" siden du da har gått over regelen med at kun en disk kan dø om gangen.

7324750[/snapback]

 

Jeg tenkte ikke på at disken kræsjer totalt, jeg tenkte på om det er en ødelagt sektor/"unrecovrable read error" på en av de 3 diskene som er igjen.

 

AtW

7324821[/snapback]

 

linux software raid5 takler fint en force assemble med mangler på en av de eksisterende diskene, så lenge ikke kritiske områder er skadet. Det gjelder også lvm headers og filsystem headers hvis du også ønsker å få tilgang til dataene

 

på det verste gikk ikke en force assemble men å bygge opp raidet fra scratch fra de enkelte bestanddelene i riktig rekkefølge ga meg også dataene tilbake igjen. meget fleksibelt og robust mao. men du bør bruke hvert online sekund til å berge data.

[ATWindsor]

Er det den nye disken som krasjer vil det ikke ha noe å si, er det en annen er du "på dypt vann" siden du da har gått over regelen med at kun en disk kan dø om gangen.

7324750[/snapback]

 

Jeg tenkte ikke på at disken kræsjer totalt, jeg tenkte på om det er en ødelagt sektor/"unrecovrable read error" på en av de 3 diskene som er igjen.

 

AtW

7324821[/snapback]

 

linux software raid5 takler fint en force assemble med mangler på en av de eksisterende diskene, så lenge ikke kritiske områder er skadet. Det gjelder også lvm headers og filsystem headers hvis du også ønsker å få tilgang til dataene

 

på det verste gikk ikke en force assemble men å bygge opp raidet fra scratch fra de enkelte bestanddelene i riktig rekkefølge ga meg også dataene tilbake igjen. meget fleksibelt og robust mao. men du bør bruke hvert online sekund til å berge data.

7329672[/snapback]

 

Beklager om dette er et tåpelig spørsmål, jeg er litt ute på tynn is her, men er ikke force assemble noe man bruker om en av de 3 gjenværende diskene er midlertidlig utilgjengelig for raidet? Vil det hjelpe om det er ødelagt sektors på en av de 3 resterende diskene?

 

AtW

[HeltNils]

Har nettopp eksperimentert litt med kopiering til XP-RAID5-settet. Det bruker veldig lite CPU ved skriving, men det går også seint. Med Copyhandler får jeg ca 30 MB/s og 6% CPU-bruk på det meste med vanlige store filer.

 

Når jeg kopierer store filer som bare består av 0-bytes, får jeg derimot ca 60 MB/s, som er maks kilde-disken kan gi, og litt lavere CPU-bruk. Min teori er derfor at det er lagt en grense på hvor mye CPU som skal brukes av RAID-driveren, og at det er det som reduserer hastigheten. Når filene bare består av 0-bytes, trenger den ikke gjøre noen utregninger, eller de blir lettere for prosessoren.

 

Et alternativ kan være at den gjør mindre kompliserte skriveoperasjoner, men PAR2-genereringen jeg hadde gående på RAIDet fikk lavere hastighet med 0-byte-filene enn med vanlige, selv om det da så ut til å bli brukt mindre CPU, så jeg tror ikke det.

[JVRG]

For kopiering bør du bruke Copyhandler. Skriveytelsen kan øke drastisk ved kopiering, jeg får ca 30 MB/s på store filer. Når det gjelder leseytelse får jeg opptil ca 160 MB/s (med QuickSFV), men vanligvis ligger det rundt 80 MB/s (4 disker).

7327974[/snapback]

Bruker TotalCopy til kopiering. Både via nettverk og lokalt på maskinen.

 

Skal nevne at den ene disken har ryki nå, og det står en hyggelig gul trekant ved en av de andre diskene. Antar en eller fler av diskene ikke er helt gode, som egentlig var grunnen til at RAID ble satt opp til å starte med.

Alle diskene som står i maskinen er også av forskjellige merker, men alle er ca like store (160GB).

[roac]

Kjører med Promise EX8350

 

Liker ikke software raid fordi;

 

1)

Sucks CPU, treeeeigt!

 

2)

Dårlig funksjonalitet og usikker kompabilitet.

7328815[/snapback]

1) Hvis du ser det i sammenheng med denne artikkelen som gjelder RAID 5, greit nok. Men å si at software RAID sucks CPU gjenerelt er helt på jordet. Det krever CPU i de RAID-nivåer som baserer seg på paritet, noe som er langt fra alle.

 

2) Dette er bare helt på viddene. Det er mange software-løsninger som er like bra om ikke vel så bra som hardware RAID, og jeg tør påstå at Veritas Storage Foundation er blant disse. VSF har en del funksjonalitet som du ellers ikke finner i de fleste kontrollere (om noen), deriblant å bruke samme disk i flere volum.

[Torbjørn]

Beklager om dette er et tåpelig spørsmål, jeg er litt ute på tynn is her, men er ikke force assemble noe man bruker om en av de 3 gjenværende diskene er midlertidlig utilgjengelig for raidet? Vil det hjelpe om det er ødelagt sektors på en av de 3 resterende diskene?

 

AtW

7329808[/snapback]

 

Nei, den skjønner selv om den har alle diskene eller ikke, og vil du starte den med en disk for lite, så er det ingen som hindrer deg i det.

 

 

Hvis ditt raid allerede er degradert (mangler en disk i raid5), og en av de gjenværende diskene også feiler, er du ute på tynn is. Da kan en force assemble, ie be mdadm se bort fra rapporterte diskfeil, likevel starte raidet med bare en missing, hvorpå det vil vare helt til de dårlige sektorene blir lest/skrevet til. Men du lever selvsagt på nåde når det først har kommet så langt.

[ATWindsor]

Beklager om dette er et tåpelig spørsmål, jeg er litt ute på tynn is her, men er ikke force assemble noe man bruker om en av de 3 gjenværende diskene er midlertidlig utilgjengelig for raidet? Vil det hjelpe om det er ødelagt sektors på en av de 3 resterende diskene?

 

AtW

7329808[/snapback]

 

Nei, den skjønner selv om den har alle diskene eller ikke, og vil du starte den med en disk for lite, så er det ingen som hindrer deg i det.

 

 

Hvis ditt raid allerede er degradert (mangler en disk i raid5), og en av de gjenværende diskene også feiler, er du ute på tynn is. Da kan en force assemble, ie be mdadm se bort fra rapporterte diskfeil, likevel starte raidet med bare en missing, hvorpå det vil vare helt til de dårlige sektorene blir lest/skrevet til. Men du lever selvsagt på nåde når det først har kommet så langt.

7334360[/snapback]

 

Ok, men er det sånn at hele greia havarerer når den kommer til en dårlig sektor den skal lese fra, eller kan man "hoppe over" denne sektoren, og lese ut resten av disken? Det er jo for meg som bruker ganske vesentlig om jeg klarer å redde ut "alt minus noen sektorer", eller ingenting. Å skrive finner jeg vel ganske uaktuelt (ihvertfall for meg personlig) i en sånn situasjon, går en disk ned, så vil jeg vel forsøke å erstatte den og bygge opp arrayet så fort som overhode mulig, uten å gjøre noe som helst annet i mellomtiden.

 

AtW

[Torbjørn]

De filene som ligger på gode sektorer kan du hente ut, ikke de andre. Når du kommer til det punktet, må du antagelig starte raidet på nytt og begynne med andre filer.

 

Jeg har opplevd å i begrenset grad kunne fortsette å hente ut data også etter at andre disk er satt "faulty".

[HeltNils]

Bruker TotalCopy til kopiering. Både via nettverk og lokalt på maskinen.

Testet TC, og det gir ingen ytelsesøkning slik CH gjør, faktisk gikk det litt seinere enn vanlig Windows-kopiering (ca 8 MB/s, mot ca 8,8 med Windows). Synes derfor fortsatt du bør prøve CH. Du må nok stille litt på cachestørrelsen for å få maks ytelse, tror jeg har satt den til 2 MB.

[JVRG]

Testet TC, og det gir ingen ytelsesøkning slik CH gjør, faktisk gikk det litt seinere enn vanlig Windows-kopiering (ca 8 MB/s, mot ca 8,8 med Windows). Synes derfor fortsatt du bør prøve CH. Du må nok stille litt på cachestørrelsen for å få maks ytelse, tror jeg har satt den til 2 MB.

7335110[/snapback]

Imponerende!

 

Overførte en fil på 488MB fra OS-disken til RAIDet. CH brukte 30s (~16MB/s), mens TC brukte 129s (~4MB). For morroskyld testet jeg Windows sin innebygde kopiering etter dette, og den brukte merkelig nok mindre tid en CH gjorde (~25s). Antar dette er fordi fila har vært kopiert til RAIDet to ganger tidligere og deler av fila allerede ligger i forskjellige buffere (noe som burde vært til fordel for TC også).

 

Verdt å merke seg med denne testen var at jeg har et program kjørende i bakgrunnen i laveste prioritet som sluker alle CPU ressurser (ADATE for de som er kjent med det). Den ene disken er også død og ute av RAIDet uten at det ser ut til å påvirke TC resultatet.

 

Target

[Zerge]

Nå orket jeg ikke å lese hele tråden, men jeg ser at folk er interessert i benchmarks.

 

Da det rett og slett ble for dyrt å kjøpe seg en skikkelig hwraid kontroller, og jeg ikke hadde noe krav til oppetid for operativsystemet, gikk jeg til innkjøp av to kontrollere med SIL3114 brikker.

Disse benytter jeg så under linux 2.6.18.* og med 8*250gB harddisker i raid5 under mdadm får jeg en teoretisk skriveytelse fra dev/null på ca. 80-100megabyte/s

 

Jeg ble rett og slett meget positivt overrasket over hvor enkelt det var å bytte ut en defekt disk her i forrige uke, da den ene disken tok kvelden. Det var bare å fjerne den fra arrayet, bytte disk, legge til den nye og vips startet den rebuild som tok en 200minutter:)

[Torbjørn]

hva var cpuloaden under denne skrivingen?

[Zerge]

Sånn, da har jeg foretatt en liten test igjen.

 

dd if=/dev/zero of=./test bs=4M count=200

838860800 bytes (839 MB) copied, 7.63938 seconds, 110 MB/s

 

dd if=/dev/zero of=./test bs=4M count=2000

8388608000 bytes (8.4 GB) copied, 92.997 seconds, 90.2 MB/s

 

Og loaden du er interessert i er vel:

Cpu(s): 1.5%us, 31.7%sy, 0.0%ni, 41.2%id, 20.4%wa, 1.0%hi, 4.2%si, 0.0%st

Mem: 2057392k total, 2040496k used, 16896k free, 628k buffers

Swap: 2931820k total, 2132k used, 2929688k free, 1638728k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

14679 root 16 0 0 0 0 D 26 0.0 3:27.37 pdflush

28751 root 18 0 10128 4680 4572 D 25 0.2 0:23.37 dd

2290 root 10 -5 0 0 0 S 9 0.0 30:58.60 md0_raid5

 

Specs:

dual xeon 2.8ghz emt64

2GB ECC minne

8*WD2500JS 250GB

2*SIL3114 kontrollere

OS: Debian etch x86_64

 

Det var visst litt load ser jeg nå ja:) Som sagt, hadde jeg hatt de ekstra 3-4k til å spytte inn i en skikkelig hwraid kontroller fra 3ware eller lsi så hadde jeg gjort det:)

[Torbjørn]

kan du også sjekke cpu loaden og båndbredden hvis du kopierer til to filer samtidig? jeg gjetter at båndbredden deles i to, men cpu loaden kan være interessang.

[Zerge]

dd if=/dev/zero of=./test1 bs=4M count=2000

8388608000 bytes (8.4 GB) copied, 206.01 seconds, 40.7 MB/s

 

dd if=/dev/zero of=./test2 bs=4M count=2000

8388608000 bytes (8.4 GB) copied, 205.389 seconds, 40.8 MB/s

 

 

Cpu(s): 2.0%us, 31.4%sy, 0.0%ni, 48.3%id, 13.1%wa, 1.2%hi, 4.0%si, 0.0%st

Mem: 2057392k total, 2040916k used, 16476k free, 640k buffers

Swap: 2931820k total, 2132k used, 2929688k free, 1640204k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

28804 henrik 18 0 10128 4680 4572 D 16 0.2 0:09.98 dd

28805 root 18 0 10128 4680 4572 D 16 0.2 0:09.00 dd

14659 root 15 0 0 0 0 D 14 0.0 22:39.94 pdflush

14679 root 15 0 0 0 0 S 7 0.0 3:51.61 pdflush

2290 root 10 -5 0 0 0 S 6 0.0 31:11.70 md0_raid5

 

Merk at jeg ikke kopierer, jeg tester kun ren skriveytelse.

[Torbjørn]

javisst, beklager at jeg var litt upresis.

 

cpu-loaden er omtrent lik mao... det synes jeg var verd å merke seg. tenker da på lasten ved å ha flere brukere inne samtidig.

[Zerge]

CPU lasten gikk faktisk ned med ca. 10%. Jeg vil anta at dette skyldes minkningen i skrivehastighet pga. skriving til 2 filer samtidig. Jeg kunne sikkert testet hva som hadde skjedd hvis jeg hadde startet 20 samtidige writes, men det blir litt sent nå

[Zerge]

Haha, skal si at swraid virkelig ikke kan måle seg med hwraid ja:)

Testet nå å starte 20 samtidige writes a 800MB, det tok sine ressurser det..

 

Loaden hoppet litt, men for det meste lå den på 20% idle.

Man kan trygt si at det ikke er noe særlig å spare på å kjøre swraid i produksjon.

Det blir rett og slett for dumt at man må spytte inn mangfoldige tusen kroner i ekstra cpukraft når man like gjerne kunne hatt en egen kontroller som tok seg av arbeidet.

 

Klikk for å se/fjerne innholdet nedenfor

Cpu(s): 3.0%us, 33.8%sy, 0.0%ni, 16.6%id, 39.7%wa, 1.5%hi, 5.5%si, 0.0%st

Mem: 2057392k total, 2041500k used, 15892k free, 616k buffers

Swap: 2931820k total, 2132k used, 2929688k free, 1648116k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

14679 root 16 0 0 0 0 D 16 0.0 8:21.45 pdflush

2290 root 10 -5 0 0 0 S 9 0.0 31:58.43 md0_raid5

30483 root 18 0 10124 4676 4572 R 8 0.2 0:01.90 dd

30486 root 18 0 10128 4680 4572 R 5 0.2 0:01.64 dd

30475 root 18 0 10128 4680 4572 R 4 0.2 0:02.08 dd

223 root 10 -5 0 0 0 S 3 0.0 2:39.63 kswapd0

29774 xxxxxx 15 0 83096 65m 8636 S 3 3.3 3:25.98 xxxxxxx

30482 root 18 0 10124 4680 4572 R 3 0.2 0:01.73 dd

30480 root 18 0 10128 4680 4572 R 2 0.2 0:02.31 dd

30489 root 18 0 10124 4676 4572 R 2 0.2 0:01.53 dd

29771 xxxxxx 15 0 87384 69m 8592 S 2 3.4 7:09.57 xxxxxxx

30477 root 18 0 10128 4680 4572 R 2 0.2 0:02.17 dd

30487 root 18 0 10128 4680 4572 R 2 0.2 0:02.50 dd

30490 root 18 0 10128 4680 4572 R 2 0.2 0:02.18 dd

30493 root 18 0 10124 4676 4572 R 2 0.2 0:01.58 dd

236 root 10 -5 0 0 0 S 2 0.0 0:33.91 xfsdatad/1

30474 root 18 0 10124 4680 4572 R 2 0.2 0:02.09 dd

30492 root 18 0 10124 4676 4572 R 2 0.2 0:01.61 dd

30481 root 18 0 10128 4680 4572 R 1 0.2 0:01.81 dd

30485 root 18 0 10124 4676 4572 R 1 0.2 0:01.31 dd

29765 xxxxxx 15 0 85576 67m 8668 S 1 3.4 3:43.68 xxxxxxx

30488 root 18 0 10124 4676 4572 R 1 0.2 0:01.43 dd

29768 xxxxxx 15 0 86328 68m 8640 S 1 3.4 3:27.51 xxxxxxx

30476 root 18 0 10128 4680 4572 R 1 0.2 0:02.30 dd

30479 root 18 0 10124 4680 4572 R 1 0.2 0:01.63 dd

30484 root 18 0 10128 4680 4572 R 1 0.2 0:01.81 dd

235 root 10 -5 0 0 0 S 0 0.0 0:01.39 xfsdatad/0

30468 root 15 0 10728 1364 948 R 0 0.1 0:00.57 top

30491 root 18 0 10124 4676 4572 R 0 0.2 0:01.94 dd

1 root 15 0 6120 696 572 S 0 0.0 0:00.62 init

 

 

xxx# ./svada.sh

xxx# 200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 74.2251 seconds, 11.3 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 116.754 seconds, 7.2 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 160.893 seconds, 5.2 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 167.287 seconds, 5.0 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 171.255 seconds, 4.9 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 171.961 seconds, 4.9 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 172.054 seconds, 4.9 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 178.711 seconds, 4.7 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 181.907 seconds, 4.6 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 188.731 seconds, 4.4 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 193.332 seconds, 4.3 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 189.67 seconds, 4.4 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 191.983 seconds, 4.4 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 195.721 seconds, 4.3 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 192.185 seconds, 4.4 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 193.041 seconds, 4.3 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 197.197 seconds, 4.3 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 195.956 seconds, 4.3 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 195.755 seconds, 4.3 MB/s

200+0 records in

200+0 records out

838860800 bytes (839 MB) copied, 195.789 seconds, 4.3 MB/s

 

 

 

[roac]

Det blir rett og slett for dumt at man må spytte inn mangfoldige tusen kroner i ekstra cpukraft når man like gjerne kunne hatt en egen kontroller som tok seg av arbeidet.

7356157[/snapback]

Ikke hvis du får ekstra funksjonalitet, ref Veritas Storage Foundation.