Konsistenz des RAIDs überprüfen

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

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

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 all abgefragt 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:

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

Erfahrungen

Der RAID Check wurde auf einem Intel SR2500 Server (BIOS: 94, BMC: 64, FRUSDR: 47) mit Areca ARC-1210 4x SATA Controller (BIOS: V1.21, Firmware: 1.46) inkl. Battery Backup Modul mit 3 Festplatten (ST3200826AS) getestet. Dafür wurde ein RAID5 Volume mit 20GB überprüft. Dieser Vorgang hat 5 Minuten und 25 Sekunden gedauert, was einem "Check-Durchsatz" von etwa 63MB pro Sekunde entspricht.

Adaptec RAID Controller

Bei Adaptec RAID Controllern ermöglicht die Funktion verify eine Überprüfung des disk media.

Laut Adaptec CLI Users Guide v 6.10 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]#

Weitere detaillierte Informationen finden Sie in folgendem Dokument:

Wartung und Pflege von Adaptec RAID Lösungen

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. Siehe dazu auch Analyse einer fehlerhaften Festplatte mit smartctl.

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.


Foto Werner Fischer.jpg

Autor: Werner Fischer

Werner Fischer arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.


Das könnte Sie auch interessieren

Onboard RAID auf Supermicro X12 Mainboards
RAID Datenrettung
Verify / Consistency Check manuell starten