Entwicklungsumgebung/Sensors: Unterschied zwischen den Versionen

Version vom 1. Juli 2009, 17:27 Uhr

Seite fertig: Sollten Sie Änderungsvorschläge oder Ergänzungen zu diesem Punkt haben, dann nutzen Sie bitte den Punkt Diskussion (oben).

Hardwareüberwachung des Servers

Installation der Sensoren

Die Hardware eines Servers muss überwacht werden. Das Paket "lm-sensors" erlaubt es, Informationen von Temperatur-, Spannungs- und Lüfter-Sensoren auszulesen. Das Zusatzpaket "i2c-tools" enthält eine heterogene Gruppe von Tools für Linux: ein Systembus-Überwachungs-Tool, EPROM-Decodierungs Skripte und vieles mehr. Das Paket "sensord" enthält einen Dämon, der die mit den anderen Tools ausgelesenen Daten im Systemlog aufzeichnet.

Installieren Sie die drei Pakete mit dem Befehl:

 aptitude install lm-sensors i2c-tools sensord

Einrichtung der Sensoren

Wichtig: Bei der Arbeit mit einer virtuellen Maschine werden die Werkzeuge der Hardwareüberwachung nicht funktionieren. Sie können die angegebenen Pakete zwar installieren, aber diese werden keine Daten von der Hardware liefern können.

Melden Sie sich als root an.

Geben Sie den Befehl:

 sensors-detect

Damit startet ein Programm, dass nahezu alle Kernel-Module für Sensoren testet und die wahrscheinlichsten auswählt. Sie erhalten eine Reihe von (englischen) Fragen, die meist nur mit ENTER zu bestätigen sind. Schlimmstenfalls reagiert der Rechner nicht mehr. Dann sollten Sie neu starten und beim nächsten Versuch mit diesem Befehl diese Frage mit [n] beantworten.

Am Ende schreibt dieses Programm die wahrscheinlichsten Module in eine Datei "/etc/sensors3.conf", die Sie noch per Hand weiter bearbeiten können.

Nach jeder Änderung starten Sie bitte den Dienst neu:

 /etc/init.d/sensord restart

Einrichtung der Festplattenüberwachung

Außerdem stellen die meisten Festplatten mit der integrierten Elektronik eine weitere Überwachungsmöglichkeit dar. Hier sind Lesefehler der Hardware ablesbar. Zudem kann auch ein physischer Test der Festplatte angeschoben werden. Bedingung dabei ist, dass die Festplatte S.M.A.R.T. unterstützt und diese Unterstützung im BIOS aktiviert ist. Oft kann man auch die Temperatur der Festplatte auslesen.

Damit diese Festplattenüberwachung arbeiten kann, muss die Festplatte das sogenannte SMART-Management unterstützen. Das ist bei Festplatten seit etwa 2001 meist der Fall. Ältere Festplatten können diese Option haben, aber nicht immer. Verschiedentlich muss dieses S.M.A.R.T. erst im BIOS aktiviert werden. Unter Linux ist es bei den meisten Boards aber möglich, auf SMART auch dann zurückzugreifen, wenn es im BIOS nicht eingeschaltet ist.

Installieren Sie das Paket mit dem Befehl:

 aptitude install smartmontools

Nach der Installation ist der Dienst nicht automatisch eingeschaltet, siehe "/etc/default/smartmontools". Entfernen die Kommentarzeichen in der Zeile:

 start_smartd=yes

Starten Sie als root zunächst testweise den Daemon mit dem Befehl:

 /etc/init.d/smartmontools start

Lesen Sie die Meldungen in der Datei /var/log/messages. Hier finden Sie meist viele Hinweise, dass zum Beispiel /dev/sda nicht existiert. Das ist unkritisch. Nur wenn echte Meldungen auftreten, die auf einen Absturz des Daemons hinweisen, sollten Sie auf weitere Experimente verzichten.

Nutzung

Hardware direkt am Server überwachen

Als root stehen Ihnen nun ein paar Befehle zur Verfügung, um die Einrichtung zu überprüfen.

Befehl sensors

zeigt nun Informationen über die Hardware an:

it87-isa-0290
Adapter: ISA adapter
VCore 1:   +1.74 V  (min =  +1.42 V, max =  +1.57 V)   ALARM
VCore 2:   +1.23 V  (min =  +2.40 V, max =  +2.61 V)   ALARM
+3.3V:     +6.60 V  (min =  +3.14 V, max =  +3.46 V)   ALARM
+5V:       +4.92 V  (min =  +4.74 V, max =  +5.24 V)
+12V:     +12.24 V  (min = +11.40 V, max = +12.60 V)
-12V:      -7.95 V  (min = -12.63 V, max = -11.41 V)   ALARM
-5V:       -3.72 V  (min =  -5.24 V, max =  -4.76 V)   ALARM
Stdby:     +5.06 V  (min =  +4.74 V, max =  +5.24 V)
VBat:      +0.00 V
fan1:     4115 RPM  (min =    0 RPM, div = 8)
fan2:        0 RPM  (min = 3013 RPM, div = 8)          ALARM
fan3:        0 RPM  (min = 3000 RPM, div = 2)          ALARM
M/B Temp:    +45°C  (low  =   +15°C, high =   +40°C)   sensor = thermistor
CPU Temp:    -55°C  (low  =   +15°C, high =   +45°C)   sensor = thermistor
Temp3:       +81°C  (low  =   +15°C, high =   +45°C)   sensor = diode

eeprom-i2c-0-51
Adapter: SMBus Via Pro adapter at 0400
Memory type:            DDR SDRAM DIMM
Memory size (MB):       256

Hier zum Beispiel ein Athlon-Rechner mit VIA-KT333-Chipsatz (Gigabyte-Board). Einige Werte haben keinen Sinn. So überwacht dieses Board z.B. -5V und -12V nicht. Analog sind die Lüfter fan2 und fan3 nicht eingebaut. Wer sich daran stößt, kann die Datei "/etc/sensors3.conf" entsprechend bearbeiten. Achten Sie dabei auf den Abschnitt mit dem richtigen Chipsatz. Hier müsste man z.B. im Abschnitt chip "it87-*" eintragen

 ignore fan2
 ignore fan3

Analog lassen sich Spannungswerte usw. anpassen, damit die Überwachung funktioniert. Leider ist man in diesem Bereich sehr auf die Informationen der Board-Hersteller angewiesen.

Wenn das Modul eeprom geladen ist, wie in diesem Beispiel, können auch die Informationen aus dem SPD-EEPROM auf dem RAM-Modul gelesen werden. Verwenden Sie dazu den Befehl

 decode-dimms.pl

Um die Festplattenüberwachung zu prüfen, nutzen Sie den Befehl

 smartctl -a /dev/sda

Die Ausgabe ist relativ lang, hier für eine 10GB-Seagate-Festplatte (gekürzt):

smartctl version 5.26 Copyright (C) 2002-3 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     ST310212A
Serial Number:    7EG3EHVQ
Firmware Version: 3.02
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   5
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Oct 16 17:07:49 2005 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity was
                                        completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
[.. einiges entfernt]
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0008   087   075   000    Old_age   Offline      -       2372785
  3 Spin_Up_Time            0x0006   098   098   000    Old_age   Always       -       0
  4 Start_Stop_Count        0x0013   100   100   020    Pre-fail  Always       -       318
  5 Reallocated_Sector_Ct   0x0013   100   100   036    Pre-fail  Always       -       22
  7 Seek_Error_Rate         0x0009   064   060   030    Pre-fail  Offline      -       30088533367
  9 Power_On_Hours          0x0012   094   094   000    Old_age   Always       -       5976
 10 Spin_Retry_Count        0x0013   100   100   090    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0013   100   100   000    Pre-fail  Always       -       484
197 Current_Pending_Sector  0x0030   100   100   000    Old_age   Offline      -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

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%      5278         -
# 2  Extended offline    Completed without error       00%      4761         -

Interessant vor allem die letzten Zeilen: Es ist grundsätzlich möglich, über diese SMART-Elektronik einen physischen Festplattentest durchführen zu lassen. Das sollte aber möglichst in Zeiten erfolgen, in denen kaum Festplattenzugriffe erfolgen, also z.B. nachts. Einen ausführlichen Test erzwingen Sie mit dem Befehl

 smartctl -t long /dev/sda

Der Test startet und gibt eine ungefähre Angabe, wie lange die Elektronik brauchen sollte. Für diese 10GB-Platte sind es etwa 15 Minuten, eine 60GB-Platte benötigt etwa eine Stunde. Das Ergebnis ist nach dieser Zeit in der Ausgabe von smartctl -a /dev/sda zu sehen.

Sollte dieser Test mit einer Fehlermeldung enden, sollte man dringend die Festplatte wechseln. Anfangs kann das SMART-Management noch einzelne Reserve-Sektoren benutzen, um die Ausfälle zu kompensieren. Ein Totalausfall ist aber zu befürchten - also sollte man bald reagieren!

Weblinks

zurück | Hauptseite

Uwe Schoffer 2009

@@ Zeile 193: / Zeile 193: @@
 ----
 <div align="right">[[Installation:Entwicklungsumgebung|zurück]] | [[Hauptseite]]</div>
+Uwe Schoffer 2009