Konsistenz des RAIDs überprüfen
Aus Wiki Thomas-Krenn.AG
RAID-Controller bieten unterschiedliche Möglichkeiten um die Konsistenz eines RAID-Sets zu überprüfen. Ziel solcher Überprüfungen ist es, frühzeitig Parity-Fehler und Blockfehler zu erkennen.
Dabei werden zumeist alle zugehörigen Blöcke der betroffenen Festplatten gelesen. Wenn dabei einzelne Lesefehler auftreten (bad blocks) können diese Blöcke - sofern noch ausreichend redundante Daten vorhanden sind - wieder mit den korrekten Daten beschrieben werden (z.B. mittels dynamic sector repair bei 3ware). Durch das erneute Schreiben von Daten auf den fehlerhaften Datenblock der Festplatte ersetzt die Firmware der Festplatte den fehlerhaften Sektor durch einen anderen freien Sektor (spare sector). Weitere Informationen dazu auf Wikipedia: http://en.wikipedia.org/wiki/Bad_sector
Inhaltsverzeichnis |
3ware RAID Controller
3ware bietet zur Überprüfung des RAIDs die Funktion verify. Wird diese Funktion ausgeführt, kommt es durch die Überprüfung zu einer Beeinflussung der Performance des RAIDs. Durch Variieren der Background Task Rate kann die Höhe der Performancebeeinflussung konfiguriert werden.
- 3ware empfiehlt zumindest einmal pro Woche ein verify durchzuführen.
- Wurde ein RAID Unit bisher noch nicht initialisiert, so wird beim Starten der verify Funktion automatisch die Initialisierung anstelle der Überprüfung durchgeführt. Nachdem die Initialisierung abgeschlossen ist, muss die verfiy Funktion erneut gestartet werden. Ob ein RAID Unit bereits initialisiert ist, kann z.B. über das CLI mittels
tw_cli /c0/u0 show allabgefragt werden. - Weitere detaillierte Informationen finden Sie im User Guide ihres 3ware RAID-Controllers in den Abschnitten About Initialization und About Verification:
Beispiel:
[root@testserver ~]# tw_cli /c0/u0 start verify Sending start verify message to /c0/u0 ... Done. [root@testserver ~]# tw_cli /c0/u0 show all /c0/u0 status = VERIFYING /c0/u0 is not rebuilding, its current state is VERIFYING /c0/u0 is verifying with percent completion = 1 /c0/u0 is initialized. /c0/u0 volume(s) = 1 /c0/u0 name = /c0/u0 serial number = 5ND29QM781616400022D /c0/u0 Storsave Policy = protect /c0/u0 Command Queuing Policy = off Unit UnitType Status %Cmpl Port Stripe Size(GB) Blocks ----------------------------------------------------------------------- u0 RAID-1 VERIFYING 1 - - 232.82 488259584 u0-0 DISK OK - p1 - 232.82 488259584 u0-1 DISK OK - p0 - 232.82 488259584 Parameter index does not exist [root@testserver ~]#
Areca RAID Controller
Bei Areca ermöglicht die Funktion Consistency Check die Konsistenz-Überprüfung des RAIDs. Es können dabei RAID-Sets der Level RAID3, RAID5 und RAID6 überprüft werden. Dabei werden alle zugehörigen Datenblöcke gelesen, dann die Parity berechnet, die gepeicherte Parity ausgelesen und dann die berechnete und gespeicherte Parity verglichen. Durch diesen Vorgang wird die Performance des RAID-Sets naturgemäß beeinflusst.
Auch Areca empfiehlt zumindest einmal pro Woche einen derartigen Check durchzuführen.
Detaillierte Informationen finden Sie im User Manual ihres Areca RAID-Controllers im Abschnitt Consistency Check sowie im CLI User Guide:
- User Manual ARC-11XX/ARC-12XX
- Übersicht bei Areca mit Links zu User Manuals von weiteren Controllern
- CLI User Guide
Beispiel:
[root@testserver ~]# cli64 vsf check vol=1
Laufende Consistency Checks können auch abgebrochen werden (z.B. bei Performance-Engpässen):
[root@testserver ~]# cli64 vsf stopcheck
Adaptec RAID Controller
Bei Adaptec ermöglicht die Funktion verify eine Überprüfung des disk media.
Laut Adaptec CLI Users Guide v 5.20 gibt es folgende Logical drive options:
- verify_fix (Verify with fix) - verifies the disk media and repairs the disk if bad data is found
- verify - verifies the disk media
Beispiel:
[root@testserver root]# ./arcconf TASK
Usage: TASK START <Controller#> LOGICALDRIVE <LogicalDrive#> <task> [noprompt]
Usage: TASK STOP <Controller#> LOGICALDRIVE <LogicalDrive#>
Usage: TASK START <Controller#> DEVICE <Channel# ID#> <task> [noprompt]
Usage: TASK STOP <Controller#> DEVICE <Channel# ID#>
======================================================
Performs a task on a logical device or a physical devices.
Task : Task to be started or performed.
LogicalDrive# : logical device ID on which task is to be performed
Logical Tasks : verify_fix (Verify with fix)
verify
clear
Channel# ID# : The Channel and ID of the physical device on which task is to be
performed. Optionally ALL indicates all ready drives for initialize
task only (ex. ARCCONF TASK START 1 DEVICE ALL INITIALIZE).
Physical Tasks : verify_fix
verify
clear
initialize
secureerase
[root@testserver root]# ./arcconf TASK START 1 LOGICALDRIVE 0 verify
Controllers found: 1
Verify of a Logical Device is a long process.
Are you sure you want to continue?
Press y, then ENTER to continue or press ENTER to abort: y
Command completed successfully.
[root@testserver root]# ./arcconf GETSTATUS 1
Controllers found: 1
Logical device Task:
Logical device : 0
Task ID : 101
Current operation : Verify
Status : In Progress
Priority : High
Percentage complete : 1
Command completed successfully.
[root@testserver root]#
Festplatten ohne RAID-Controller
Bei Festplatten, die direkt am Mainboard betrieben werden (also ohne RAID-Controller), kann mit Hilfe von SMART Tools eine Überprüfung auf Blockfehler durchgeführt werden. Unter Linux können dabei z.B. die smartmontools verwendet werden, weitere SMART Tools sind z.B. bei Wikipedia gelistet.
Das folgende Beispiel zeigt eine solche Überprüfung mit den smartmontools unter Linux:
[root@testserver ~]# smartctl -t long /dev/sda smartctl version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Extended self-test routine immediately in off-line mode". Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 115 minutes for test to complete. Test will complete after Fri Apr 11 12:34:29 2008 Use smartctl -X to abort test. [root@testserver ~]#
Nachdem der Test durchgelaufen ist, kann das Ergebnis abgefragt werden:
[root@testserver ~]# smartctl -l selftest /dev/sda smartctl version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 112 - [root@testserver ~]#
Wenn Fehler auftreten, erfordert eine Korrektur etwas Aufwand. Weitere Informationen dazu sind im Bad Block HowTo vom smartmontools Projekt zu finden.
Hinweis: bei SATA-Festplatten kann es u.U. erforderlich sein, -d ata oder -d sat beim Aufruf von smartctl anzugeben. Siehe dazu auch http://smartmontools.sourceforge.net/#testinghelp.
