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
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.
Management für virtualisierte Umgebungen mit Virtual Iron
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
Themen-Special STORAGE
Alles was Sie zum Thema Storage wissen müssen: »Administration »Software »Grundlagen »LVM & Co.