[ADAPTEC 2610SA] RAID configuratie kwijt :S

[wizl]

In onze HP ML350G4 server zitten 4 Maxtor 80GB SATA schijven in een RAID5 configuratie op een Adaptec 2610SA controller. Het OS is Suse Linux 10.0. Daarop draait VMware server met daarop weer 4 FreeBSD 6.1 servers. Het hele verhaal heeft 2 maanden naar volle tevredenheid gedraaid.

Eergisteren gaf disk #0 aan dat hij een defect had (oranje ledje knipperde). HP heeft een nieuwe schijf geleverd en daarmee heb ik de defecte #0 vervangen (terwijl de server draaide!) De lampjes op de nieuwe schijf brandden groen, en afgaande op de schijfactiviteit van de andere 3 schijven begon het rebuilden van de array. Ongeveer een kwartier later is de server compleet onderuit gegaan. Op de console van Suse stonden meldingen in de trent van 'critical I/O /dev/sda'.

Ik heb de server toen uitgezet, en weer aan, waarna de array controller vond dat de RAID5-array FAILED was als gevolg van missing, of rebuilding members. In de configuratie van de arraycontroller waren schijf #0 en #2 grijs, en #1 en #3 wit. De lampjes op alle schijven brandden groen.

Mijn conclusie was dat de array-configuratie gegevens op de schijven verminkt zijn geraakt, en de inmiddels gearriveerde 'engineer' van HP was het daar mee eens. Uiteindelijk dus maar 2 nieuwe schijven geplaatst en opnieuw begonnen. Ik ben er echter niet echt gerust op

Voorheen gebruikten we altijd SCSI in servers, en dit is ons eerste experiment met SATA. Twee vragen dus eigenlijk:

Hoe kan die RAID-controller zijn configuratie vern**ken en gebeurt dat vaker (ik heb het nog nooit gezien)
Zijn SATA schijven eigenlijk wel al productieserver 'waardig'?

[DeBolle]

Op het eerste gezicht denk ik dat tijdens de rebuild een tweede schijf defect is geraakt. Dat komt relatief vaak voor - tijdens een rebuild worden alle disks immers volledig gelezen om alle RAID5 data en parity op de nieuwe schijf te schrijven. Dit gebeurt onafhankelijk van de soort disk en komt dus ook voor bij SCSI of FC.
Te voorkomen valt dit niet, je kunt het risico alleen verkleinen door bijvoorbeeld te zorgen dat alle disks uit verschillende series/fabricagedatums komen, samen met een hot spare (als de controller dat kan) en een extra parity disk (RAID6).
Dit alles om de tijd dat een array degraded is zo kort mogelijk te houden.
De uitval van SATA disks valt mij alleszins mee, op ongeveer 200 disks zijn er het afgelopen half jaar vier defect geraakt.
Met dat in gedachten hebben wij ongeveer 40TB aan SATA disks draaien, met de opmerking dat ze voornamelijk gebruikt worden als staging voor backupservers. Belangrijke data voor productiesystemen staan nog steeds op externe arrays met SCSI en FC.
Ik gebruik zelf (nog) geen losse SATA RAID controllers in een server en heb dus nog geen ervaringen met het wegraken van de config. Ik zou verwachten dat een dergelijke controller de config wegschrijft op alle disks, maar kennelijk is dat niet het geval?