Acht RAID-controllers vergeleken @ THG

Tom's Hardware heeft acht verschillende RAID-controller uitbreidingskaarten met elkaar vergeleken. Vijf daarvan, te weten de Adaptec ATA Raid 1200A, de Dawicontrol DC-100 Raid, de Dawicontrol DC-133 Raid, de Highpoint Rocket Raid 133, en de Highpoint Rocket Raid 404 zijn voorzien van twee kanalen voor de aansluiting van vier harddisks. De 3Ware Escalade 7850, de Highpoint Rocket Raid 404, en de Megaraid i4 van LSI Logic zijn vierkanaals en kunnen acht harddisks bedienen. Na de diverse tests wijst THG twee kaartjes als aanbevelenswaardig aan:

3Ware Escalade 7850
Based on the strength of its good performance and features, the "Editor's Choice" goes to the 3Ware Escalade 7850. It is even easy to use. The technical performance of this high-end card makes it particularly suited for use in entry-level servers.

Dawicontrol DC-100 Raid
The DC-100 delivered convincing benchmark scores and service support. With a five-year manufacturer's warranty including exchange service, the DC-100 is our "Budget Recommendation."

Reacties (53)

[Tielenaar]

Ik snap niet waarom die 3Ware kaart nou zo ontzettend duur moet zijn (ruim 700 euro), hij ziet er redelijk simpel uit drivers lijken mij ook makkelijker te maken dan bijv die van een geluidskaart oid. Of heb ik het nu mis?

Ook lijkt het alsof die kaart nog 4 extra IDE connectors kwijt kan, dus er moet ook nog een 8 poorts kaart in omloop zijn?

Verder mis ik de link naar de review...

[JAVA-Doctor]

Die 3ware heeft net als de Megaraid i4 van LSI Logic veel meer features. Deze 2 kunnen Naast RAID 0,1 en 0+1 ook nog RAID 5. De Megaraid i4 heeft verder nog RAID 3 en de combinaties 0+1, 0+3 en 0+5. Bij 3 en 5 moet er parity berekend worden en dit kost nogal wat rekenkracht. Dit gaat dus gepaard met een dure chip. Bovendien hebben allebei deze kaarten cache erop zitten. Hoger prijskaartje is dan ook logisch.

Verder vond ik 't wel opvallend dat de Highpoint Rocket Raid 404 de snelste uit de test was. Vaak wordt er nogal denigrerend gedaan over de prestaties van Highpoint. In de praktijk blijkt 't dus allemaal erg mee te vallen

[boner]

De Megaraid i4 heeft verder nog RAID 3 en de combinaties 0+1, 0+3 en 0+5. Bij 3 en 5 moet er parity berekend worden en dit kost nogal wat rekenkracht. Dit gaat dus gepaard met een dure chip.

Parity = XOR(disk1,disk2) dat is door elke proc in 1 clockcycle te berekenen. Zelfs een 6502 doet dat op die snelheid. Dus een dure processor is er niet voor nodig. Alleen een simpel stukje real-estate op de ASIC.....

[boner]

wedden:

disk1 waarde: 12
disk2 waarde: 42

parity xor(12,42) = 38

xor(38,12) = .... 42
xor(38,42) = .... 12


xor is associatief.

dus het schrijven gaat goed. en een terugreken methode ook.

Raid werkt op disk-nivo. Dus je moet er eerst een ddisk uithalen, of disabelen voordat je data terug laat rekenen. Je kunt niet 1 sector van een hele disk automatisch laten her-berekenen.

[boner]

dat valt te bezien of het niet zo simpel is. Xor is als volgt gedefinieerd:
Operation
Description

AND
TRUE if the corresponding bits are all TRUE

OR
TRUE if at least one of the corresponding bits is TRUE

NAND
TRUE if at least one of the corresponding bits is FALSE

NOR
TRUE if no corresponding bits are TRUE

XOR
TRUE if an odd number of corresponding bits are TRUE

NOT
TRUE if the input is FALSE (available only for single input)


En dat is relatief eenvoudig is Silicium te implementeren.

Dat verhaal over de PCI bus moet je me nog eens uitleggen. Een RAID controller is er juist voor gemaakt om alleen data over de bus te transporteren en de individuele aansturing zelf te doen, inclusief de RAID afhandeling. Dus hoeveel disks er ook aanhangen de PCI controller merkt daar heogenaamd NIX van.

[justice strike]

simpel 8 schijven eerste 2 stripes gaan over schijf 1 en 2 wordt gexored en de parity daarvan word op schijf 3 geplaatst, strip 3 en 4 worden op schijf 2 en 3 geplaats worden gexored en de parity daarvan word op schijf 4 geplaats stripe 5 en 6 worden geplaats op schijf 3 en 4 worden gexored en de parity daarvan wordt op schijf 5 geplaats, etc... etc... etc.. er 2 stripes dus 1 parity bit dus 3 schijven elke keer.

daarom is dit zo intensief als het software matig gedaan word aangezien de block eerst gestriped en gexored moet worden voordat het naar de onafhankelijke ide poorten gestuurd worden. Zoals boner aangaf heeft een raid controller daar minder last van (natuurlijk word daar wel rekening mee gehouden, maar als alle 8 schijven 133 mb/sec trekken zullen we dan wedden dat de processor op de raid controller dan ook moeite krijgt )

omdat deze een dedicated bus en processor ervoor heeft

[mavink]

Was het maar zo simpel... Dat werkt bij twee schijven inderdaad wel, maar als je raid5 over 8 schijven aan het doen bent zoals met een 7850 kan, wordt de berekening een stuk ingewikkelder!
En ook als je processor het in 1 clockcycle zou kunnen doen zou het naar worden; met zoveel schijven kom je redelijk makkelijk richting de 100 MB/seconde, en al die data zou dan heen en weer moeten naar de CPU voordat hij weggeschreven kan worden. Da's niet fijn voor de bandbreedte op je PCI-bus...

[mavink]

Nou heel simpel: je stuurt data naar de schijf. Raid-controller stuurt de data naar de CPU om een parity-berekening te doen. Data wordt weggeschreven.
Misschien dat ik ergens iets mis, maar dan gaat die data toch een keer te veel heen-en-weer?

[boner]

idd. Je ziet iets over het hoofd. Op de controller zit die CPU, de controller ASIC. De CPU in je mobo staat daar compleet los van. Vergelijk het met een GPU, wat ook een microprocessor is maar dan gespecialiseerd voor graphics.

[justice strike]

parity is niet alleen een xor, want als jij 2 schijven xored en je krijgt dan een waarde dan kan je nooit data correctie uitvoeren, met andere woorden als een van die drie cijfers verandert weet jij niet de foutieve bit te vinden. meestal is het een combinatie van reed-solomon met nog wat data correctie code.

//nevermind ik had het over reen andere raid systeem ff door elkaar gehaald

[Maurits van Baerle]

Als je goed kijkt in het Pricewatch-tabelletje links zie je dat die prijs daar slaat op de 8-poorts versie. De 4-poorts is goedkoper.
Voor de link naar de review hoef je alleen op 'Bron' te klikken, bovenaan het artikel.

[Femme]

De kaart op de foto hierboven is de versie met vier kanalen. Deze is een stuk goedkoper, maar nog steeds duurder dan de goedkope firmware RAID kaarten. De 3ware's zijn duurder omdat er een I/O processor op zit die dus hardware RAID 5 parity voor zijn rekening kan nemen. Verder hebben ze ook meer mogelijkheden zoals ondersteuning van hotswap, hotspare, online rebuilding en 64-bit PCI, waardoor je de 3ware's in een serieuze server kunt toepassen.

[voodooless]

De 3Ware is een hardware RAID kaart. De andere (ik geloof allemaal, behalve de LSI) kunnen alleen RAID omdat de software alles regelt. De 3Ware kan al die dingen in hardware doen, en kan daarom ook RAID 5 omdat ie een eigen CPU heeft. De HPT is gewoon een IDE controller met een speciale BIOS en wat extra software. Dat zelfde gelt ook voor de andere goedkope controllers met andere chips.

[Verwijderd]

Het is een simpele XOR. Of je nu 2 of meer schijven hebt, maakt niet uit. Je moet het zien als een matrix. Als er een probleem is op een van de twee assen kun je ervan uit gaan de bit daar verkeerd is. Zie het volgende voorbeeld.

Correcte data:

Op de X en Y as staat de parity bit. Een kwestie van het aantal enen tellen. Als het aantal oneven is in een rij dan krijgt parity waarde 1, anders 0. Horizontale rij 'a' kent slechts 1 maal een 1 en is dus oneven. Waarde 1. Vertikale rij 'c' kent twee enen en heeft dus waarde 0.

Parity V ------ 1 1 0 0
------------------- a b c d
Parity H1 1 a |0|0|1|0
Parity H2 1 b |1|1|1|0
Parity H3 0 c |0|0|0|0


Corrupte data:

Hetzelfde plaatsje, maar de positie 'bb' is nu corrupt door een glitch. Tijdens het lezen komt de controller tot de conclusie dat verticale parity een 0 moet zijn en de horizontale parity ook. Aangezien 'bb' slechts twee standen kent en deze is verkeerd, moet 'bb' dus 1 zijn. Een nieuwe rekencontrole bevestigd dit. Zo simpel is het.

Parity V ------ 1 1 0 0
------------------- a b c d
Parity H1 1 a |0|0|1|0
Parity H2 1 b |1|0|1|0
Parity H3 0 c |0|0|0|0

Het grote probleem is natuurlijk, hoe breed mag ik een databrok maken? Hoe breder, hoe efficienter ik omga met de ruimte die parity bits in beslag nemen, maar des te gevoeliger ik voor (meerdere) fouten ben.

Meer parity is meer rekenwerk, meer opslagruimte en meer dataverkeer. Slimmere en snellere controles zijn noodzakelijk. ReedSolomon is noodzakelijk om de dataintegriteit te controleren van een sector en minder van een RAID combinatie.

RAID 0, 1 en 5 en 1 + 0 hebben hun voor- en nadelen. RAID 2, 3 en 4 hebben allemaal een parity bottleneck en dus eigenlijk niet bruikbaar. Een reden voor RAID 0 + 3 is voor mij niet te bedenken, wellicht dat iemand ideeen heeft. Een reden voor 0 + 5 vind ik al dubieus, 0 + 1 is volgens mij goedkoper en sneller.

[Lennie]

Het is tevens zo dat de 3ware zich gedraagt als een SCSI-controller/met schijven (ik weet niet of de rest dat ook doet), volgens mij is dit ook veel duurder.

Maar in gebruik vooral veel simpeler, tevens omdat het een zich als SCSI-bios presenteerd kun je ook booten van een stripped/mirrored/whatever partitie die verdeelt is over meerdere schijven.

(zoals ik al zei ik weet niet hoe de rest dit oplost, maar ik vond als SCSI-controller/disks presenteren aan de rest van het systeem wel elegant (http://www.google.com/sea...hl=en&lr=&ie=UTF-8&oe=UTF -8&q=dijkstra+elegant&btnG=Google+Search)

[straat]

Wel jammer dat de Promise FastTrack SX4000 (of anders de redelijk vergelijkbare SuperTrack SX6000) niet is meegenomen in de test, dat is namelijk een redelijk betaalbaar kaartje met veel leuke features...

De kaart heeft vier IDE poorten, hardware parity berekening, hotspare en hotswap support, 66MHz PCI ondersteuning, en kan uitgerust worden met maximaal 256MB cache geheugen. Hiervoor kan een standaard 168-pins ECC of non-parity DIMM gebruikt worden. Naast RAID 5 worden JBOD en de RAID levels 0, 1, 0+1 en 3 ondersteund.

zie verder http://www.tweakers.net/nieuws/22991

[voodooless]

de SX4000 en SX6000 net als de LSI en de 3 Ware in de test vallen eigenlijk onder een heel ander cathegorie en horen eigenlijk in een apparte test.

Van de SX4000 heb ik nog helemaal nergens een review gezien ( 256 MB Cache). Zal nog wel te nieuw zijn

[Madrox]

Wat mij opvalt is dat de duurste ondanks onboard cache toch niks beter presteert. Dus voor de snelheid hoef je die niet perse aan te schaffen. Wil je veel HDD's aansluiten, hot-swappen of RAID 3/5 kunnen draaien is het een optie anders kan je het beter bij de goedkope kaarten houden, of voor een onboard-oplossing kiezen.

Tja en die prijzen, volgens mij verdienen ze er goed aan. Neem bijv. een poosje terug die Promise Ultra 133 controller, kon je voor 2 piek ombouwen naar FULL Fastrak 133, ik bedoel maar....

[johnwoo]

Ik ga binnenkort ook een extra schijfje kopen en RAID draaien, maar ik heb besloten om geen RAID controller te kopen, en in plaats daarvan software RAID te gebruiken.
Twee redenen: 1) Een goede RAID kaart is me te prijzig (zoals reeds vermeld doen die goedkope kaartjes het stiekum toch via hun driver en niet compleet in hardware; dan kun je net zo goed software RAID nemen), en 2) serial ATA (II) zit eraan te komen, dus over een jaartje ofzo kun je toch weer overstappen.

Nu heeft software RAID natuurlijk ook nadelen: je OS moet het ondersteunen, en je levert wat CPU cycles in. Maar van beide nadelen heb ik geen last (WinXP Pro, en P4 2.26, die moet die extra cycletjes makkelijk trekken zonder er iets van te merken), dus software RAID here we come

[*marco*]

Ik stel even een vraag die voor sommigen dom over mag komen.

Wat kan ik met zo'n ding ? Ik weet dat je er hardeschijven op kan aansluiten maar het voordeel weet ik niet goed.Worden je 2 of 4 schijven herkend en partitioneerbaar als 1 schijf in je Os ?

Of heeft het meer met snelheid te maken of stabiliteit ? Let me know.. I'm curious.

[Frogmill]

Voor alles over RAID, lees deze uitmuntende en uitgebreide uitleg op Ars Technica:

http://arstechnica.com/paedia/r/raid-1.html

De verschillende RAID-configuraties worden hier o.a met plaatjes duidelijk gemaakt. Maar voor de liefhebbers zijn er ook een boel lettertjes bij, ook van zeer goede kwaliteit. Hier wordt meer op de voor- en nadelen ingegaan van de verschillende configuraties.

[mjtdevries]

Aardig artikel, maar ze missen toch wel een beetje de plank bij Raid5 en staan veel te kort stil bij Raid0+1

Ze doen net alsof Raid5 toch best wel snel is met schrijfacties, maar dat is echt niet zo mooi als zij het voorspiegelen. Raid5 is doodgewoon TRAAG met schrijven.

De reden dat het alsnog veel gebruikt wordt in bedrijven (bij ons ook bij alle servers) is doodeenvoudig omdat het nog steeds ruim voldoende is.
Voor je data volumes heb je redundantie nodig. De performance is echter zelden een bottleneck in een server. En dan is Raid5 gewoon de goedkoopste oplossing.

Alleen op zware database servers wordt schijfperformance wel een bottleneck. En dan ga je naar Raid 0+1. OOK als je een Proliant met een topmodel Raid controller hebt.

Als je het van mij niet wilt geloven, vraag het dan maar bij Compaq ( oh nee, "New HP" nu) Die zullen je exact hetzelfde vertellen.

[zion]

Mwoah.

Uitgaande van een hardware raid kaart, en 3 schijven (minimum voor raid5, meer schijven is betere performance, dus dit is worst case scenario)
schijven kunnen max. zeg 40mb/s

Raid-0 =
schijf1 = 40mb/s, schijf2 = 40mb/s, schijf3 = 40mb/s
Maximale throughput = 120mb/s

Raid1
Schijf1 = 40mb/s,Schijf2 = 40mb/s Mirroring
Maximale (eff) throughput = 40mb/s
Schijf3 kan bij 1 niet gebuikt worden.

Raid5
Schijf1 = 40mb/s, Schijf2 = 40mb/s, Schijf3 = 40mb/s parity (wordt eigenlijk verdeeld over de schijven, maar is eff 1 schijf)
Maximale (eff) throughput = 80mb/s

scenario bij 4 schijven zou maken: R0=160 R1=80 R5=120

Dus raid5 is wel degelijk een stuk sneller als raid1 of gewone schijven.

[mjtdevries]

Het zou leuk zijn als het inderdaad zo simpel was.

Maar dat is het dus niet. Wat dat betreft zou ik je aanraden dat artikel goed te lezen, want er staat nog heel wat nuttige informatie voor je in.
De overhead van Raid5 bij schrijven tgv parity berekeningen bv.

Eén belangrijk punt zal ik hier al vast vermelden. De performancewinst van een Raid array komt maar in beperkte mate van de grotere throughput.
Een zeker zo belangrijk punt is dat je files parallel aan elkaar van de schijf kan halen. Dus file 1 wordt van schijf 1 gelezen, file 2 van schijf 2 en file 3 van schijf3.

Daarmee verminder je je effectieve toegangstijden. En dat heeft vaak veel meer impact op de performance van je applicaties dan een hogere max transferrate.

[mjtdevries]

Juist andersom. Je gebruikt een relatief grote blokgrootte bij kleine bestanden. (zodat de bestanden elk op een andere schijf staan en die schijven elk een bestand ophalen. Waardoor je je effectieve toegangstijd stevig vermindert. Tranferrate is bij kleine files minder interessant dan toegangstijd)

Bij grote bestanden gebruik je een relatief lage blokgrootte zodat ze bestanden zoveel mogelijk verspreid staan over de schijven en je dus maximaal profijt kan trekken van de hoge sequentiele transferrate die je dan krijgt.

Het klinkt op het eerste gezicht tegenstrijdig om bij kleine bestanden grote blokgrootte te nemen, maar ik hoop dat de logica erachter zo duidelijk is.

Helaas is de uitstekende uitleg van Dell hierover tegenwoordig niet meer op hun site te vinden.

Overigens hebben IDE controllers nogal de neiging een bepaalde grootte te prefereren onafhankelijk van het type files dat je gebruikt.
Anandtech heeft dat ooit erg goed getest met een stel IDE Raid controllers. Is een test van midden vorig jaar of zo.

De blokgrootte instellen op basis van het soort files dat je hebt lijkt vooral iets voor high-end SCSI Raid controllers te zijn.

[Verwijderd]

Om het even simpel te houden ga ik niet in op details van de verschillende opzetten, maar RAID wordt over het algemeen gebruikt om data dubbel op te slaan.

Je sluit dan bijvoorbeeld 2 schijven van 40 GB aan en dan heb je niet 80 GB maar gewoon 40 GB aan schijfruimte, doordat alles op beide schijven wordt gezet. Mocht een van de schijven dan crashen, dan staat alles -gelukkig- nog op de andere schijf. (Drie keer raden hoe de schijven van t.net zijn aangesloten )

[Verwijderd]

Ik denk dat bij de meeste tweakers er RAID niet wordt gebruikt voor veiligheid (RAID1) maar meer als performance verhoging (RAID0).
2 harddisks worden dan door het operating system inderdaad gezien als 1 grote harddisk met de dubbele snelheid (bij sequentieel lezen).

[ACM]

Nee, we draaien alleen op de databases raid.
En die draaien toch echt voornamelijk voor de dataveiligheid dat raid. Dat het er over het algemeen sneller van wordt (vooral van raid 10/0+1) is dan mooi meegenomen natuurlijk

[SirBlade]

Zie niet helemaal het voordeel van IDE-RAID, behalve de prijs dan. Als je echt snel en betrouwbaar wil moet je toch gewoon voor SCSI-RAID gaan?

[Kristof]

Zo'n kaarten worden ook veel verkocht, doordat een gewoon moederbord maar 4 IDE aparaten kan aansluiten. Een cd-rom, writer, binnenkort DVDwriter en je hebt al onmiddellijk een beperking op uw HDs.

Als je HDspace te kort komt, koop je een HD bij, maar de 'oude' wens je nog wel bij te houden.
Velen hebben nog geen moederbord met extra raid controller onboard, dus hier kunnen deze kaartjes uitkomst bieden.

Vooral de Dawicontrol DC-100 Raid vind ik wel netjes. Die externe aansluiting zou wreed handig zijn. Hoeveel gebeurt het niet dat je even wat van een HD wil kopieren, maar je niet de moeite neemt om hem in je case te steken en dan de kabeltjes aansluit, en de HD op een stapel CD's laat balanceren? Met dit kaartje gaat dit wel veel gemakkelijker.

[mjtdevries]

SCSI Raid is eigenlijk niet betrouwbaarder dan IDE Raid.

Het hele idee van Raid is juist dat de betrouwbaarheid van de individuele schijven niet meer zo boeit. Dus dat verschil in IDE en SCSI schijven boeit dan ook niet meer.

Neem een Raid5 met een hotspare disk en de kans dat je je array kwijt raakt door kapotte schijven is zo goed als nul.

Het snelheidsverschil wordt ook al een stuk minder interessant. Bij IDE Raid kaarten heeft elke schijf een IDE kanaal voor zichzelf. Bij SCSI deel je een SCSI kanaal met meerdere schijven. Wat dat betreft heb je dus geen snelheidsvoordeel bij SCSI.

Verder heb je natuurlijk wel je 15k SCSI schijven tegenover de 7k IDE schijven. Maar het snelheidsverschil tussen de ene of andere Raid variant is hoger dan het verschil tussen IDE of SCSI.
Het prijsverschil maakt dan ook leuk uit. Meestal wordt bv Raid5 gebruikt voor de data schijf van een server. Dan is namelijk redundantie voor een beetje redelijke prijs belangrijk.
Bij IDE Raid kan je makkelijker Raid 0+1 voor de data schijf gebruiken, omdat de prijs van extra schijven niet zo schreeuwend hoog is als bij SCSI.

Maar voor een zware database server zou ik nog wel voor een highend SCSI oplossing gaan. Maar voor een normale fileserver en een minder zware database server is IDE Raid al lang toerijkend wat betreft snelheid en betrouwbaarheid.

[heuveltje]

"Bij SCSI deel je een SCSI kanaal met meerdere schijven. Wat dat betreft heb je dus geen snelheidsvoordeel bij SCSI."

das onzin. bij scsi mag je het dan misschien delen
maar het gaat nog altijd op volle snelheid. 3 schijven op een controller is niet langzamer of trager dan 3 schijven op 3 losse controllers

en het belangrijkste voordeel bij scsi zijn de acces tijden waar je verliefd op word

[mjtdevries]

3 SCSI schijven hebben nog geen last nee.
Maar nou zet ik 7 schijven op een kanaal.
7*40 MB/s transferrate komt flink boven de 160MB/s uit. Moet je dus al een SCSI Raid controller met 320MB/s hebben. En dan zit je dus aan hele dure controllers.
Bij IDE Raid controller hou je gewoon 100MB/s voor elk van die 7 schijven. Ruim voldoende om nooit een bottleneck te vormen.

[Pietervs]

Dus dat verschil in IDE en SCSI schijven boeit dan ook niet meer.
Pardon??? Nou en of dat het boeit: de toegangssnelheid verschilt enorm. Daarnaast is de levensduur van SCSI stukken langer, waardoor je minder schijven hoeft te vervangen tijdens de levensduur van de server, wat ook prettig is (een RAID-5 schijf is inderdaad zo vervangen, maar afhankelijk van de snelheid van je server kan het rebuilden van de array toch al snel enkele uren in beslag gaan nemen. Je wil niet weten wat er gebeurt als er in die tijd nog een schijf crasht!).

Meestal wordt bv Raid5 gebruikt voor de data schijf van een server. Dan is namelijk redundantie voor een beetje redelijke prijs belangrijk.
Bijna helemaal goed: niet alleen is redundantie en prijs belangrijk, maar ook toegangstijd en snelheid waarmee weggeschreven kan worden.

Het snelheidsverschil wordt ook al een stuk minder interessant Ook hier geldt weer: toegangstijd! Liever een array met 15k schijven als een array met 5400 tpm schijven.

Bij SCSI deel je een SCSI kanaal met meerdere schijven Onzin, zoals Heuveltje al terecht opmerkte.

Maar voor een normale fileserver en een minder zware database server is IDE Raid al lang toerijkend wat betreft snelheid en betrouwbaarheid. Ik hoop van harte dat jij geen systeem-/netwerkbeheerder bent...

[mjtdevries]

LEZEN!

Ik zeg het verschil boeit niet wat betreft betrouwbaarheid. Dan moet je niet over toeganstijd beginnen wat dat heeft met dat punt geen zier te maken!

Inderdaad zal je bij een IDE array wat vaker een schijf moeten vervangen dan bij een SCSI array.
Maar voor de betrouwbaarheid van de array als geheel maakt dat helemaal niets uit. Als je een kansberekening gaat doen op de betrouwbaarheid van je array is het verschil niet terug te vinden. (ergens 20 cijfers achter de komma of zo)

Rebuilden van een schijf is typisch sequentieel schrijven en dat is juist de sterke punt van IDE.

Je moet trouwens eens gaan uitrekeken wat de werkelijke kans is dat een array crashed doordat er nog een schijf uitvalt terwijl je array nog aan het rebuilden is. Die kans is onnoemelijk klein.

Alleen redundantie en prijs is belangrijk bij Raid5. Pak maar eens één van je servers en kijk wat de load op je schijven is. Stelt niets voor. Schijven zijn zeer zelden de bottleneck in servers. En als ze dat wel zijn is het ook automatisch de moeite waard Raid 0+1 te gebruiken.
Als je vanwege toegangstijd en snelheid Raid5 hebt gekozen dan heb je een verkeerde keuze gemaakt.

Liever een array met 2x zoveel 10k schijven dan de helft aan 15k schijven. Het aantal spindels in een array is zeer belangrijk voor de performance van de array. Net zoals de block size die je gebruikt.
Maar het snelheidsverschil waar ik het daar over had en waar je op reageerde was dus het snelheidsverschil tussen de IDE BUS en de SCSI BUS! Daar hebben de toerentallen van de schijven dus weer niets mee te maken.

Dat delen van dat SCSI kanaal is geen onzin zoals ik net in een andere reply heb laten zien.

En wat betreft mijn werk. Ik had oa 2 Exchange2000 servers met elk 4000 users, en een halve TB aan opslag onder mijn hoede. 14 stuks 15k SCSI schijven in een Raid5 array. Dus ik kan heel aardig in de praktijk wat metingen doen op een server die relatief gezien zware schijfbelasting heeft.
Verder wat SQL2000 clusters etc. En een stuk of 140 file&print servers.

Mijn argumenten zijn gebaseerd op de praktijk. Waar zijn die van jou op gebaseerd?

[leuk_he]

Neem een Raid5 met een hotspare disk en de kans dat je je array kwijt raakt door kapotte schijven is zo goed als nul.

Helaas, was het maar zo simpel. Een beheerder bij die raid-5 zetten die het net niet helemaal snapt, of moeite heeft met die raid-5 menu's kan ervoor zorgen dat je weer schone disks hebt, of dat zodra een "gerepareerde disk" wordt teruggezet je al je data kwijt raakt. (echt, het is niet zo simpel)

als je nou gezegd had "in theorie is de kans dat....."

Kortom, vergeet je backup's niet.

[mjtdevries]

Goed lezen wat ik schrijf:

De kans je array kwijt te raken door KAPOTTE SCHIJVEN is zo goed als nul.

Dat is dus wat anders dan de kans een array kwijt te raken door een incompetente systeembeheerder.

De kans dat de array controller zelf kapot gaat is ook een stuk groter dan dat de array stuk gaat door kapotte schijven. (De kans dat er een meteoriet op valt trouwens ook)

Kortom, vergeet inderdaad je backups niet!

[smallblock]

Ja hèhè, het kan altijd beter ( en duurder) Als je nou toevallig met een klein budget toch een betrouwbare en/of snelle oplossing wilt, waarom zou je dan niet voor IDE RAID gaan ?

[WiD]

Is er eigenlijk al verbetering in de linux drivers voor die dingen? Van 3ware waren ze al goed heb ik vernomen, maar bij de andere producenten was het om te En dit artikel zegt er ook niets over

[sampoo]

De Dawicontrol kaartje werkt perfect onder linux. Zelfs kernel support voor. Zit namelijk een Hightpoint hpt370 chipset op. Ik heb hem vooral voor de prijs gekozen en de vijf jaar garantie heeft mij over de streep getrokken.

[Verwijderd]

Duidelijke een beter bevestiging van de IDE poorten op de Escalade, bij het insteken van de IDE kabels komt er maar weinig kracht op de gesoldeerde verbindingen daar de kracht richting soldeerpunten is gericht. 5 jaar garantie mede daarom.

Dit in tegenstelling bij de dawicontrol waar door de nogal lange haakse verbindingen een grote kracht op de soldeer verbindingen komt dit kan bij veelvuldig gebruik snel tot metaalmoeheid en afbreken leiden.

[Ricochet]

[off-topic] Het zal eerder door lomp gebruik afbreken dan door metaalmoeheid. Dit laatste verschijnsel is veel complexer dan mensen denken. Daarnaast kan hier geen eens metaalmoeheid ontstaan omdat er geen continue belasting op staat. [/off-topic]

Overigens, die haakse verbinding is wel weer makkelijker met je kabels in de kast. Bij die andere kaart moeten de kabels er eerst omheen voordat ze erin gestoken kunnen worden.

[decipherer]

[off-topic] Metaalmoeheid treed niet op door een continue belasting van een onderdeel, maar juist door een wisselende belasting, waar hier in zekere mate sprake van is [/off-topic]

Echter, ik ben het er wel mee eens dat ze eerder af zullen breken door lompheid als door metaalmoeheid, tenzij je iedere dag die kabels eruit gaat trekken ofzo, maar dat zie ik de meeste niet doen.

[Verwijderd]

Ik weet niet hoe het met die andere kaarten zit. Maar op de 3Ware kun je maar 1 hardisk per kanaal aansluiten.

Hierdoor krijgt die harddisk de volle bandbreedte en hoeft hij het niet te delen met een slave schijf. Dit is een enorme performance winst.

[mjtdevries]

Op zich valt die performance winst wel mee.
100 MB/s is voor 2 schijven ook ruim voldoende. Er is toch geen enkele IDE schijf die 50MB/s trekt.

Tom had ooit een test waar bleek dat een promise raid kaartje met 4 schijven met twee schijven per kanaal net goed presteerde als 2 kaartjes met elk 1 schijf per kanaal.

Maar 1 harddisk per kanaal is een voorwaard om hot-swappable IDE schijven mogelijk te maken.
En dat wil je natuurlijk bij Raid5.

[metalant]

Ik gebruik al jaren een DAWI scsi controleer. Fijn kaartej, altijd goede driverondersteuning, ook voor nieuwe OSén, zoals bv Netware 6.

Er is ook een DAWI raid133 controller.
http://www.dawicontrol.com/english/html/raid133.htm