Open Source im professionellen Einsatz
Newsletter abonnieren
ABO & ARCHIV | NEWS | TECHNICAL REVIEW | VIDEOS | WHITEPAPER | EVENTS

Testphasen:

ABO & ARCHIV

Events

« August 2007 »
Mo Di Mi Do Fr Sa So
  1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 

Service


Anzeige

Server, DSL-Flatrate, Linux-Software, WLAN, Digitalkamera, Notebook, Software, Grafikkarten, Desktop-PCs, CPU, Netzwerk, Linux-News, Testberichte, Hardware und Software

  Home » ABO & ARCHIV » Ausgaben » 2005 » 10 » Na, wie geht's uns denn heute?  

Speichermedien automatisiert überwachen

Na, wie geht's uns denn heute?

von Gabriele Pohl
Erschienen im Linux-Magazin 2005/10

Die Self-Monitoring, Analysis and Reporting Technology (SMART) auf modernen Speichermedien liefert Kenngrößen zu deren gesundheitlichem Wohlbefinden. Die Smartmontools steuern diese Aktivitäten und informieren den Fileserver-Admin über einen bevorstehenden Plattentod.

Im Rechnerraum von Bruce Allen hat der Komponenten-Tod ein verlässliches Zuhause. Der Physiker betreibt für seine Forschungsarbeit einen Rechnercluster mit 300 Knoten und 600 Festplatten, auf denen 50 TByte Daten lagern. Bei einer solchen Gerätezahl fordern Verschleiß und die statistische Lebensdauer beinahe täglich ihren Tribut. Mit den Smartmontools [1], deren Initiator und Maintainer er ist, gelingt es Allen aber, Spontanausfälle der Speichermedien zur Seltenheit zu machen. »smartctl« aus dem Softwarepaket aktiviert und steuert die SMART-Funktionen der Geräte.

Die aktuelle Version der Smartmontools ist kompatibel mit den ATA/ATAPI-Standards 3 bis 7. Die Software läuft auf Linux, Free-, Net- und OpenBSD sowie Solaris, Darwin, OS/2, E-Comstation und Microsoft Windows. Wer die Linux-Version nicht in seiner Distribution vorfindet, holt sich entweder ein Binary-RPM-Paket oder die Sourcen von [1] oder melkt das dortige CVS.

Intelligentes Innenleben

Über die Self-Monitoring, Analysis and Reporting Technology verfügen alle Festplatten ab ATA 3 und SCSI 3. Die Testfunktionen lassen sich in drei Kategorien unterteilen: Der für den Benutzer unbemerkt laufende Onlinetest erhebt Daten zur Funktionsfähigkeit des Geräts und speichert sie in einer internen Attributtabelle, echte Fehlermeldungen kommen ins interne Errorlog.

Der Offlinetest sammelt Daten, die dem Onlinetest aus technischen Gründen versagt bleiben. Listing 2 kennzeichnet diese Attribute in Spalte »UPDATE« mit »Offline«. Steht dort »Always«, erfolgt die Aktualisierung sowohl im Online- als auch im Offlinetest. Auch das Offline-verfahren beeinträchtigt die Performance nicht, da reguläre Zugriffe auf das Medium Vorrang haben.

Die dritte Kategorie, die Selftests, prüfen die Hardware tatsächlich. Im Gegensatz zu den beiden anderen Verfahren, die bei Aktivierung automatisch in regelmäßigen Abständen ablaufen, startet der Selbsttest nur auf Anforderung. Im Angebot sind ein Test, der nur wenige Minuten dauert, und ein eingehender, der je nach Größe des Mediums eine Stunde oder länger braucht.

Da das Gerät hierbei seinen normalen Dienst versieht, hängt die benötigte Zeit von der Anzahl der reguläre Zugriffe ab. Im so genannten Captive Mode gestartet nimmt der Test das Gerät aber voll in Beschlag. Eine Laufzeitschätzung traut sich die Abfrage der SMART-Fähigkeiten wie in Abbildung 1 zu. Den Testfortschritt kann man dort unter »Self-test execution status« auch verfolgen.

Attribute mit Normwerten

Frühere ATA-Standards definierten noch mehrere Attribute, die Eigenschaften des Geräts beschrieben [2]. Wer den Gesamtstatus der Festplatte einschätzen wollte, musste alle Attribute analysieren. ATA/ATAPI 5 führt einen eigenen Health-Status ein: »smartctl -H Device«. Viele PCs erlauben per Bios-Setup, SMART bereits beim Booten zu prüfen.

Die Bedeutung und Belegung der Attribute bleibt in modernen Standards den Herstellern überlassen - sie wissen am besten, wann ein Wert als kritisch einzustufen ist. Die Smartmontools führen eine Datenbank mit diesen Informationen. Anträge zur Aufnahme eines bisher unbekannten Modells sind an eine spezielle Mailingliste [3] zu richten.

Die SMART-Firmware kennt für jedes Attribut Norm- und Schwellenwerte. Fällt der normierte Wert auf oder unter die Schwelle, gilt das Attribut als schadhaft. Im Beispiel (Listing 1) liegt die Schwelle für das Attribut »Reallocated_Sector_Ct« bei »063«. Mit »001« liegt der Wert sehr weit darunter und führt in der Spalte »WHEN_FAILED« zum Fehler »FAILING_NOW«. Hier hat die Firmware also derart oft defekte Sektoren ersetzt, dass die eiserne Reserve erschöpft ist.

Beim Beurteilen des gemeldeten Problems hilft der Typ, den die Spalte »TYPE« in Listing 2 angibt. »Old_age«-Attribute charakterisieren normale Alterungsprozesse. Kritisch sind Fehler bei den »Pre-fail«-Attributen in Kombination mit »FAILING_NOW« in der Spalte »WHEN_FAILED«, da hier tatsächlich ein Versagen innerhalb der nächsten Stunden droht. In diesem Fall empfiehlt sich der sofortige Austausch des Geräts.

Smartmontools auf
SATA-Platten

Laut Suses »README.SATA« und der Dokumentation auf [1] funktionieren SATA-Laufwerke beim Kernel 2.4 und 2.6 mit den Standard-IDE-Treibern. Wer im Bios einstellen kann, dass der SATA-Controller im Legacy Mode operiert, spielt auf der sicheren Seite. Der IDE- verdrängt in diesem Fall den Libata-Treiber. Für Intel-, VIA- und Nvidia-Controller gibt es extra Treiber. Alle anderen müssen Libata nutzen.

Den offiziellen Versionen fehlen dummerwiese für die Smartmontools notwendige »ioctl()«-Funktionen zum ATA-Passthrough. Das behebt für Kernel ab 2.6.9 ein Patch von [http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/]. Da die Smartmontools die Libata-Unterstützung nicht selbst erkennen, muss das die Datei »/etc/smartd.conf« mit der Zeile »/dev/sda -d ata« nachholen.

Automatisiert überwachen

Wer den Aufruf »smartctl -s on Device« in seine Startskripte integriert, aktiviert die SMART-Onlinetests auf dem Gerät. Die Option »-o on« bewirkt ein periodisches Ausführen der Auto-Offlinetests - üblicherweise alle vier Stunden -, sofern der Hersteller sie eingebaut hat (siehe Abbildung 1). Aktivierte Online- und Offlinetests stellen sicher, dass alle Attribute den aktuellen Stand wiedergeben.


Abbildung 1: Die Smartmontools liefern einen detaillierten Report über die SMART-Fähigkeiten des Geräts.

Den Health-Status regelmäßig überwachen ginge per Cronjob, der mit den Tools gelieferte Smartd ist aber der bessere Automatisierungstechniker. Viele Distributionen bringen für den Daemon passende Init-Skripte mit. Findet der startende Smartd keine Konfigurationsdatei »/etc/smartd.conf« oder eine mit dem Schlüsselwort »DEVICESCAN«, sucht er selbst nach Geräten, aktiviert SMART und startet die Überwachung; »smartctl -s on« ist also nicht nötig.

Einträge in der Conf-Datei regeln die Testmethoden und deren Zeitplan. An gleicher Stelle lassen sich für jedes einzelne Speichermedium eigene Regeln definieren. Smartd protokolliert seine Status- und Fehlermeldungen im Syslog. Außerdem verschickt das Programm auf Wunsch E-Mails, wenn es Schäden entdeckt hat, Fehler neu loggt oder ein Kommando scheitert. Dazu gibt der Admin der »smartd«-Konfiguration die Option »-m E-Mail-Adresse1,E-Mail-Adresse2,...« mit auf den Weg.


Abbildung 2: Das Tool Munins malt für den Admin Zeitdiagramme mit Attributwerten, die die Smartmontools geliefert haben.

Fürs zentrale Monitoring

Für einen einzelnen Server reichen die gezeigten Smartmontools-Möglichkeiten zweifellos aus. Wer aber wie Bruce Allen einen ganzen Rechnerpool sein Eigen nennt, braucht einen höheren Automatisierungsgrad. Eine Möglichkeit ist, einen gängigen Logfile-Agenten damit zu beauftragen, das Syslog auch in Richtung Smartmontools zentral auszuwerten.

Eine andere, elegante Möglichkeit eröffnet das Tool Munin [4]. In ihm kann der Admin Fehler- oder Warnstufen definieren. Schlägt eine davon an, versendet Munin einen so genannten Passive Alert an Nagios ([5], [6]). Voraussetzungen sind ein entsprechender NSCA-Server (Nagios Service Check Acceptor) sowie das Smartmontools-Plugin für Munin. Als Nebenprodukt eines solchen Setup kann sich der Admin an netten Grafiken mit dem zeitlichen Verlauf der Attributwerte wie in Abbildung 2 erfreuen.

Munin besteht aus dem zentralen Server und den so genannten Knoten (Munin-Nodes) auf den beobachteten Rechnern. Die Knoten erheben Daten über die Systemaktivitäten und -befindlichkeiten lokal und liefern sie auf Anfrage des Servers über einen Port (normalerweise 4949) an ihn aus. Auf dem Server speichert RRDtool [7] alle Daten und bastelt daraus HTML-Seiten.

Das Smartmontools-Plugin erwartet auf dem Knoten als Konfiguration pro Gerät einen Link »/etc/munin/plugins/smart_Device-Name«, der auf »/usr/share/munin/plugins/smart_« verweist. Bei Anfragen des Servers startet das Plugin dann einen »smartctl«-Aufruf mit den in »/etc/munin/plugin-conf.d/munin-node« konfigurierten Optionen und liefert die gewonnenen Daten aus.

Ausfälle werden selten

Auch Smartd kann plötzliche Systemausfälle ohne Vorgeschichte nicht verhindern. Die meisten Festplattenprobleme schleichen sich aber über längere Zeit an - umso ärgerlicher, wenn dies dem Admin tage- oder wochenlang verborgen bleibt. Er könnte in dieser Zeit neuere Backups anfertigen und Ersatzgeräte besorgen. Die Smartmontools verschaffen den entscheidenden zeitlichen Informationsvorsprung. Darum spricht alles dafür, das hilfreiche Toolset auf jedem Rechner einzusetzen. (jk)

Listing 1: Abfrage des
Gesundheitszustands

01 # smartctl -H /dev/hdb
02 smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
03 
04 === START OF READ SMART DATA SECTION ===
05 SMART overall-health self-assessment test result: FAILED!
06 Drive failure expected in less than 24 hours. SAVE ALL DATA.
07 Failed Attributes:
08 ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
09   5 Reallocated_Sector_Ct   0x0033   001   001   063    Pre-fail  Always   FAILING_NOW 637

Listing 2: Abfrage der
Attribute

01 # smartctl -A /dev/hda
...
05 SMART Attributes Data Structure revision number: 10
06 Vendor Specific SMART Attributes with Thresholds:
07 ID# ATTRIBUTE_NAME        FLAG  VALUE WORST THRESH TYPE   UPDATED WHEN_FAILED RAW_VALUE
08  1 Raw_Read_Error_Rate    0x000f  058  054  006  Pre-fail  Always  -  210712099
09  3 Spin_Up_Time           0x0003  098  097  000  Pre-fail  Always  -  0
10  4 Start_Stop_Count       0x0032  100  100  020  Old_age   Always  -  166
11  5 Reallocated_Sector_Ct  0x0033  100  100  036  Pre-fail  Always  -  0
12  7 Seek_Error_Rate           0x000f  073  060  030  Pre-fail Always  -  23892267
13  9 Power_On_Hours            0x0032  093  093  000  Old_age  Always  -  6176
14  10 Spin_Retry_Count         0x0013  100  100  097  Pre-fail Always  -  0
15  12 Power_Cycle_Count        0x0032  100  100  020  Old_age  Always  -  285
16 194 Temperature_Celsius      0x0022  040  052  000  Old_age  Always  -  40
17 195 Hardware_ECC_Recovered   0x001a  058  054  000  Old_age  Always  -  210712099
18 197 Current_Pending_Sector   0x0012  100  100  000  Old_age  Always  -  0
19 198 Offline_Uncorrectable    0x0010  100  100  000  Old_age  Offline -  0
20 199 UDMA_CRC_Error_Count     0x003e  200  197  000  Old_age  Always  -  4
21 200 Multi_Zone_Error_Rate    0x0000  100  253  000  Old_age  Offline -  0
22 202 TA_Increase_Count        0x0032  100  253  000  Old_age  Always  -  0

Infos

[1] Smartmontools: [http://smartmontools.sourceforge.net]

[2] Erläuterung zu den SMART-Attributen: [http://smartlinux.sourceforge.net/smart/attributes.php]

[3] Mailingliste Smartmontools-Database: [https://lists.sourceforge.net/lists/listinfo/smartmontools-database/]

[4] Munin: [http://munin.sourceforge.net]

[5] Nagios: [http://www.nagios.org]

[6] Dietmar Ruzicka, "Netzmanagement mit Nagios": Linux-Magazin 03/03, S. 66

[7] RRDtool: [http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/]

Die Autorin



Gabriele Pohl arbeitet als Linux-Admin, IT-Trainerin und -Beraterin: [http://www.dipohl.com]. Sie dankt Guido Guenther und Nicolas Stransky für die freundliche Unterstützung bei der Recherche zu diesem Artikel.

Ähnliche Artikel
Kernel-Hüter Interview mit dem Maintainer des Linux-Kernels 2.4
Blockhaus in der Ferne Fehlertolerantes Raid mit Enhanced Network Block Devices
Backup über Bande Ivman steuert per Hotplug beliebige Jobs
Kalte Platte Hotplug-Fähigkeit von SATA-Raids
Im roten Bereich Das ideale Dateisystem für den Fileserver
Heißes Eisen Management für virtualisierte Umgebungen mit Virtual Iron

Themen-Special
STORAGE
Alles was Sie zum Thema Storage wissen müssen:
»Administration
»Software
»Grundlagen
»LVM & Co.
Impressum | © 2007Linux New Media AG
Partner-Sites
Deutschland: [LinuxUser] [EasyLinux] [Linux-Community] [Linux-Nachrichten] [Linux Events] [OpenBytes]
Europa: [EasyLinux Polen] [Linux Magazine Polen] [Darmowe Programy] [EasyLinux Rumänien] [Linux Magazin Rumänien] [Linux Magazine Spanien]
International: [Linux Magazine International] [Linux Magazine Brasilien]