Schlagwort: value

Übersicht: Wichtige S.M.A.R.T Werte und Ihre Bedeutung

prego Schreib einen Kommentar

Im IT-Administrator 07/2014 gibt es einen guten Artikel zum Thema S.M.A.R.T Werte bei Festplatten. Da das Thema bei uns in der Firma immer mal wieder aktuell ist und vor allem die Frage im Raum steht wie man Festplatten durch Monitoring besser überwachen kann ist eine Tabelle sehr gut, die aufzeigt welche SMART Werte in der Praxis überhaupt von Relevanz sind und was sie beziehungsweise eine Änderung bedeuten. Für meine eigene Dokumentation möchte ich diese hier einmal festhalten:

 

WertBedeutung
Spin_Up_Time (ID:3)Die Zeit in Millisekunden, die der Plattenstapel beim Hochfahren benoetigt, um auf Nenndrehzahl zu kommen. Steigt dieser Wert ploetzlich an, deutet das auf ein defektes Plattenlagter oder Motorproblem hin.
Spin_Retry_Count (ID:10)Anzahl der Fehlstarts beim hochdrehen des Plattenstapels. Dreht der Plattenstapel nach kurzer Zeit nicht mit Nenndrehzahl, wird ein erneuter Startversuch unternommen. Beginnt dieser Wert ueber 0 zu steigen, deutet das auf ein defektes Plattenlager oder Motorproblem hin.
Calibration_Retry_Count (ID:11)Anzahl der Rekalibrierungsversuche. Schaffen es die Koepfe nicht, sich in der vorgegebenen (kurzen) Zeit genau ueber einer Spir zu platzieren, muss eine Rekalibrierung initiiert werden. Steigt dieser Wert, deutet das vor allem bei aelteren Laufwerken auf beginnende Probleme der Festplattenmechanik hin.
Power_On_Hours (ID:9)Anzahl der Betriebsstunden. Der Wert waechst im Laufe der Zeit und zeigt lediglich das Alter der Festplatte in Stunden (manchmal Minuten oder Sekunden) an.
Temperature_Celsium (ID:194)Aktuelle Temperatur im Laufwerk. Der Wert sollte ganz grob moeglichst im Bereich von 30°C-40°C liegen - zu warme Festplatten (>45°C) aber auch kalte Platten (<20°C) haben ein deutlich erhoehtes Ausfallrisiko.
UDMA_CRC_Error_Count (ID:199)Anzahl der fehlerhaftern Uebertragungen zwischen Festplatte und Controller. Werte ueber 0 deuten auf schlecht eingesteckte Verbindungskabel, mangelde Abschirmung oder Wackelkontakte hin. Sehr hohe Werte (mehrere tausend) koennen Ihre Ursache in einem defekten Controller-Chip haben.
Reallocated_Sector_Ct (ID:5)Anzahl der reallozierten Sektoren. Sobald ein Sektor mehrfach nicht mehr korrekt gelesen/geschrieben/geprueft werden kann, wird er in einen reservierten Bereich der Platte ausgelagert (sparse area). Dies ist ein deutliches Warnzeichen, weil es auf beginnende Oberflaechenprobleme hinweist. Beginnt dieser Wert ueber 0 zu wachsen, steht oft ein Festplattenausfall (head-crash) bevor.
Seek_Error_Rate (ID:7)Eine nicht naeher spezifizierte Rate fuer Positionierungsfehler der Schreib-/Lesekoepfe. Steigt dieser Wert, deutet das auf Probleme mit der Positionierung der Koepfe hin - Ursache koennen Servofehler, thermische Ausdehnung oder mechanische Ausfallerscheinungen sein.
(Raw_)Read_Error_Rate (ID:1)Eine nicht naeher spezifizierte Rate fuer Lesefehler. Ein steigender Wert bedeutet, dass die Oberflaeche der Platten beschaedigt ist oder die Schreib-/Lesekoepfe fehlerhaft arbeiten.
Uncorrectable_Sector_ct (ID:198)Anzahl der Versuche, fehlerhafte Sektoren ohne Erfolg zu lesen oder zu schreiben. Ein steigender Wert zeigt defekte Plattenoberflaechen oder Fehler in den Schreib-/Lesekoepfen an.
Free_Fall_Protection (ID:254) und nG-Sense_Rerror_Rate (ID:221)Wird bei Notebook-Festplatten die 'Free Fall Protection' ausgeloest (Platte befindet sich bei 0 G im freien Fall) und/oder gibt es Fehler durch zu hohe G-Raten (Vibration/Stoesse), steigen diese Werte. Das wiederum deutet auf einen sehr rauhen Umgang mit den Notebook hin.
Load_Cycle_Coung (ID:193)Anzahl der Unload/Load-Zyklen der Schreib-/Lesekoepfe. Viele (Notebook-)Festplatten parken ihre Koepfe (unload) nach wenigen Sekunden Leerlauf, um Energie zu sparen. Schreibt ein Betriebssystem wie Linux alle paar Sekunden beispielsweise eine Log-Datei, muessen die Koepfe dazu wieder 'ent-parkt' werden (load). Die maximale Anzahl von Unload-/Load-Zyklen sollte je nach Hersteller 100.000 bis 600.000 nicht ueberschreiten, waechst im obigen Szenario jedoch um ueber 100 pro Stunde. Das Unload/-Load Maximum ist so innerhalb eines Jahres erreicht. Abhilfe schafft ein Abschalten der Energiespar-Option.
Current_Pending_Sector_Ct (197)Dieser besondere Wert zeigt die aktuell nicht korrekt les- oder schreibbaren Sektoren an, die noch nicht remappt wurden. Ist ein Sektor auch nicht mit Hilfe der Fehlerkorrektur (ECC)lesbar, erhaelt er zunaechst den Status 'current pending sector'. Der Sektor wird nun aber noch nicht remapped, weil sein Inhalt (bei Lesefehlern) ja nicht bekannt ist und ein spaeterer Versuche vielleicht erfolgreich ist. Erst nach mehreren erfolglosen Lese-Versuchen wird der Sektor als fehlerhaft markiert und Reallocated_Sector_Ct (ID: 5) um den Wert 1 erhoeht. Wird andererseits schreibend auf den Sektor zugegriffen, muessen die Daten zuvor logischerweise nicht gelesen werden. Die Festplatte markiert den Sektor dann endgueltig als fehlerhaft und mapped ihn in den reservierten Bereich um.

Puppet: Hiera und Puppet – Installation, Einrichten, Moduleinbindung

prego Ein Kommentar

Hiera ist eine key-/value Datenbank von Konfigurationsdaten fuer Puppet. Als ersten Schritt moechte ich aufzeigen wie man es installiert, minimal einrichtet und testweise in ein Modul einbindet.

Zuerst muss auf dem Puppetmaster Server (ich arbeite unter Debian Wheezy) das folgende Paket inklusive seiner Abhaengigkeiten installiert werden:

aptitude install ruby-hiera-puppet

Nach der Installation muss eine Konfigurationsdatei fuer Hiera unter Puppet erzeugt werden. Die Datei ist per Definition die /etc/puppet/hiera..yaml. Sie hat folgenden Inhalt:

---
:backends:
    - yaml

:hierarchy:
    - common

:yaml:
    :datadir: '/etc/puppet/hieradata'

Erklaerung der hier gemachten Einstellungen:

  • —: Definiert den Beginn der Datei
  • :backends: Gibt das Format an in dem die die Daten vorliegen. In diesem Fall ist YAML definiert.
  • :hierarchy: Definiert die Hierarchie der Datenquellen. In diesem Fall gibt es nur eine moegliche Datenquelle ‚common‘
  • :yaml::datadir:Definiert fuer das YAML Backend das Verzeichnis in dem die Daten gespeichert sind. In diesem Fall das Verzeichnis /etc/puppet/hieradata

Sicherstellen das das gerade angesprochene Verzeichnis existiert:

mkdir -p /etc/puppet/hieradata

Anschliessend die folgende Datei common.yaml in dem Verzeichnis anlegen:

---
testmessage: hallo welt

Testen ob alles funktioniert kann man das ganze danach mit dem folgenden Aufruf:

hiera -c /etc/puppet/hiera.yaml testmessage

Zum Schluss noch ein Beispiel wie man den Wert nun in Puppet in einer Klasse ausliesst und in einer Datei speichert:

class hieratest {
    $testmessage = hiera("testmessage")
    file { '/tmp/hieratest.txt':
        content => inline_template("<%= testmessage %>n"),
    }
}

Wenn man daraus zum Beispiel ein Modul ‚hieratest‘ macht, auf einem Node einbindet und Puppet laufen laesst, dann findet man dort die Datei /tmp/hieratest.txt mit dem definierten Inhalt ‚hallo welt‘.