Kontrola poprawności macierzy RAID

Z Thomas-Krenn-Wiki
Przejdź do nawigacji Przejdź do wyszukiwania

Kontrolery RAID oferują różne możliwości kontroli poprawności macierzy RAID, czego celem jest wczesne wykrycie błędów. Czytane są wszystkie bloki danego dysku twardego. Jeżeli podczas próby odczytu wystąpi błąd (bad blocks), informacje zapisane w dotkniętych blokach zostaną zrekonstruowane – oczywiście jest to zależne od dostępności odpowiednich bitów parzystości - i ponownie zapisane (np. za pośrednictwem dynamic sector repair - kontrolery 3ware). Poprzez próbę zapisu danych w miejscu uszkodzonych sektorów (bad blocks) zostaną przez firmware dysku udostępnione wolne sektory (spare sector). Dalsze informacje na ten temat znajdują się w wikipedi: http://en.wikipedia.org/wiki/Bad_sector

Kontrolery RAID 3ware

Kontrolery firmy 3ware oferują funkcje kontroli macierzy 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 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]#

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.

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.

Kategorie:RAID-Controller