Nous avons un serveur Debian avec un contrôleur RAID à 3 disques 3Ware 9650SE, avec une matrice RAID6 à 5 disques, agissant comme hôte de machine virtuelle, tous Linux. Des problèmes persistent et je soupçonne un disque cassé non détecté.
Nous avons eu plusieurs plantages maintenant où l'hôte et tous les invités disent que le système d'E / S s'est bloqué pendant 120 secondes ou plus. Nous soupçonnions un contrôleur RAID défectueux, mais nous l'avons remplacé par un contrôleur identique avec un firmware identique, ce qui ne l'a pas corrigé. Je ne pensais pas que ce serait le cas, car une deuxième matrice RAID1 fonctionnait correctement.
Il y a presque une semaine (dimanche), lorsque cela fonctionnait, la vérification automatique était à 66%. Hier soir (vendredi matin), c'était à 67%. Avant et après le démarrage, et les deux en cas de problème. Lorsque j'ai désactivé la vérification avec tw_cli /c0/u0 stop verify, les choses sont redevenues réactives.
Je soupçonne qu'il s'est bloqué sur un défaut de disque à environ 66%. Une vérification automatique commence samedi:
# tw_cli /c0 show verify
/c0 basic verify weekly preferred start: Saturday, 12:00AM
et se ferait normalement depuis vendredi. Étant donné que le dimanche était de 66% et le vendredi de 67%, il est peu probable que ce soit une coïncidence.
«smartctl -a -d 3ware, 0 / dev / twa0» et «smartctl -t long» (autotest SMART long) sur tous les lecteurs n'ont révélé aucune erreur. Pas plus tw_cli /c0 show alarms.
Je soupçonnais qu'un disque était cassé d'une manière difficile à détecter, mais j'ai retiré chaque lecteur de la baie un par un, en ai créé une 'unique' et je l'ai remplie de zéros. Aucun disque n'a montré d'erreurs.
Ou tout autre conseil?
Éditer:
c'est la mise en page:
# tw_cli /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-6 OK - - 256K 5587.9 RiW OFF
u1 SPARE OK - - - 1863.01 - OFF
u2 RAID-1 OK - - - 1862.63 RiW ON
VPort Status Unit Size Type Phy Encl-Slot Model
------------------------------------------------------------------------------
p0 OK u0 1.82 TB SATA 0 - ST32000542AS
p1 OK u0 1.82 TB SATA 1 - ST32000542AS
p2 OK u0 1.82 TB SATA 2 - ST32000542AS
p3 OK u0 1.82 TB SATA 3 - ST32000542AS
p4 OK u0 1.82 TB SATA 4 - ST32000542AS
p5 OK u1 1.82 TB SATA 5 - WDC WD2002FYPS-02W3
p6 OK u2 1.82 TB SATA 6 - WDC WD2002FYPS-02W3
p7 OK u2 1.82 TB SATA 7 - WDC WD2002FYPS-02W3
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest
---------------------------------------------------------------------------
bbu On Yes OK OK OK 0 xx-xxx-xxxx
L'unité en question est u0.
edit2:
tw_cli / c0 show diag montre quelque chose d'intéressant (edit3: c'est inoffensif, j'ai découvert que cela était dû à l'appel smartctl -a -d 3ware,X /dev/twa0où X est un port invalide):
QueueAtaPassthrough() called with invalid TargetHandle: 0x17, portHandle: 0xFF
Legacy opcode=0xB1 error=0x10E
E=010E T=14:15:51 : Invalid operation for specified port
E=010E T=14:15:51 U=0 : Return error status to host
Error, Unit 23: Invalid operation for specified port
(EC:0x10e, SK=0x05, ASC=0x24, ASCQ=0x00, SEV=01, Type=0x70)
No additional sense data
Error, Unit 23: 0x10E OVERRIDDEN due to invalid sense buffer descriptor
sense buffer: len=0, address=0x414ca2c7c
Send AEN (code, time): 0031h, 06/21/2013 14:26:16
Synchronize host/controller time
(EC:0x31, SK=0x00, ASC=0x00, ASCQ=0x00, SEV=04, Type=0x71)
J'en reçois des tonnes. Je n'ai aucune idée de ce que cela signifie. Je ne peux même pas déterminer de quelle unité ou port il s'agit. (edit3: Je sais maintenant, c'est inoffensif).
Compte tenu de mon edit3, je suis de retour à la case départ. Rien n'indique qu'un disque est cassé, sauf que la vérification se bloque à 66% et provoque le blocage de la baie, ce qui se produit également parfois de manière aléatoire. Je souhaite que le vérificateur trouve la faute ...
Réponses:
2 choses qui n'ont pas été évoquées jusqu'à présent:
la source
Ce problème peut être dû à l'un des disques rencontrant une erreur de lecture et bloquant l'ensemble de la baie jusqu'à ce qu'il parvienne à réaffecter le secteur ou que le contrôleur RAID suppose que le disque est mort et qu'il démarre hors de la baie, le marquant comme "Dégradé" (cela dépend entièrement du contrôleur en question). Cela peut se produire souvent si un disque commence à mourir mais passe toujours SMART. La plupart des disques grand public continueront de tenter la lecture pour toujours.
Ce problème est résolu dans certains disques destinés au RAID à l'aide de quelque chose appelé contrôle de récupération d'erreur . WD appelle cela TLER. Depuis le site:
RAID-specific time-limited error recovery (TLER) - Pioneered by WD, this feature prevents drive fallout caused by the extended hard drive error-recovery processes common to desktop drives.Fondamentalement, il indique à un disque que s'il ne peut pas lire un secteur, il doit abandonner après x secondes. C'est très bien dans un RAID car les données peuvent être récupérées à partir d'un autre disque.
D'après ce que j'ai lu, le ST32000542AS n'implémente aucune forme d'ERC, donc l'un d'eux peut bloquer la totalité de la baie. Le WD2002FYPS implémente en fait le TLER de WD et ne causera donc pas ce problème.
la source
Juste pour être sûr, quelle est la version de votre firmware?
J'ai rencontré un problème - qui ressemble beaucoup à ce que vous décrivez - lorsque les exigences suivantes sont remplies:
À l'époque, aucun correctif de micrologiciel n'était disponible, j'ai donc migré de la taille de bande de 256 Ko à 64 Ko, ce qui a également résolu le problème. Vous pouvez essayer une solution de contournement, mais cela prendra certainement des jours.
Plus tard, j'ai essayé le nouveau firmware (* 4.10.00.021, je pense, avait le correctif) avec 256k et j'ai travaillé comme un charme. 4.10.00.027 est la dernière version.
la source
J'ai eu des problèmes avec un contrôleur 3ware et des disques Seagate. Il y a une subtile incompatibilité de firmware. Je suis passé aux disques Samsung, problème résolu.
la source