Kapitel 11 Problembehebung und Pool-Wiederherstellung in Oracle Solaris ZFS

Dieses Kapitel enthält Informationen zum Erkennen und Beseitigen von ZFS-Fehlern. Darüber hinaus werden hier auch Maßnahmen zum Vermeiden von Fehlfunktionen beschrieben.

Dieses Kapitel enthält die folgenden Abschnitte:

• Erkennen von ZFS-Fehlern

• Überprüfen der Integrität des ZFS-Dateisystems

• Beheben von Problemen mit ZFS

• Reparieren einer beschädigten ZFS-Konfiguration

• Abhilfe bei Nichtverfügbarkeit eines Geräts

• Ersetzen oder Reparieren eines beschädigten Geräts

• Reparieren beschädigter Daten

• Reparieren eines Systems, das nicht hochgefahren werden kann

Erkennen von ZFS-Fehlern

Da ZFS ein Dateisystem mit Datenträgerverwaltungsfunktionen ist, können in diesem System viele verschiedene Fehler auftreten. In diesem Kapitel werden die verschiedenen Fehler kurz umrissen. Dann wird erläutert, wie sie in einem laufenden System erkannt werden können. Dieses Kapitel schließt mit einer Diskussion zum Beheben von Problemen ab. In ZFS treten drei Haupttypen von Fehlern auf:

• Fehlende Datenspeichergeräte in einem ZFS-Speicher-Pool

• Beschädigte Datenspeichergeräte in einem ZFS-Speicher-Pool

• Beschädigte ZFS-Daten

Bitte beachten Sie, dass in einem einzigen Pool alle drei Fehlertypen auftreten können. Deswegen umfasst eine vollständige Problembehebungsroutine das Finden und Beheben eines Fehlers, Weitergehen zum nächsten Fehler usw.

Fehlende Datenspeichergeräte in einem ZFS-Speicher-Pool

Wenn ein Datenspeichergerät vollständig aus dem System entfernt wird, erkennt ZFS, dass es nicht geöffnet werden kann und versetzt es in den Zustand REMOVED. Je nach der Datenreplikationsebene des betreffenden Pools kann es sein, dass durch das Entfernen der gesamte Pool nicht mehr zur Verfügung steht. Bei der Entfernung eines Datenträgers in Konfigurationen mit Datenspiegelung oder RAID-Z bleibt der Pool weiterhin verfügbar. Ein Pool kann in den Zustand FAULTED versetzt werden, was bedeutet, dass Daten erst dann wieder verfügbar sind, wenn das Gerät wieder eingebunden wurde. Dies gilt unter folgenden Bedingungen:

• wenn alle Komponenten einer Spiegelung entfernt werden

• wenn mehrere Geräte in einem RAID-Z-Gerät (raidz1) entfernt werden

• wenn ein Gerät der obersten Hierarchieebene in einer Konfiguration mit einer Festplatte entfernt wird

Beschädigte Datenspeichergeräte in einem ZFS-Speicher-Pool

Der Begriff ?beschädigt“ deckt eine breite Vielfalt möglicher Fehler ab. Dazu werden beispielsweise die folgenden Fehler gezählt:

• vorübergehende E/A-Fehler aufgrund eines fehlerhaften Datenträgers bzw. Controllers

• Datenbeschädigung auf Datenträgern aufgrund kosmischer Strahlung

• Treiberfehler, wegen denen Daten falsch transportiert werden

• versehentliches Überschreiben von Bereichen auf einem physischen Datenträger durch einen Benutzer

In einigen Fällen treten solche Fehler nur vorübergehend auf, so z. B. bei sporadischen E/A-Fehlern aufgrund eines Controller-Problems. In anderen Fällen ist der Schaden bleibend, wie z. B. bei der Datenbeschädigung auf einem Datenträger. Auch wenn der Schaden bleibend ist, heißt das nicht, dass der Fehler wiederholt auftritt. Wenn ein Administrator beispielsweise versehentlich Bereiche eines Datenträgers überschreibt, ist kein Hardwareausfall aufgetreten, und das Datenspeichergerät muss nicht ausgetauscht werden. Genau festzustellen, mit welchem Problem das Datenspeichergerät behaftet ist, stellt keine leichte Aufgabe dar und wird später eingehender behandelt.

Beschädigte ZFS-Daten

Datenbeschädigung tritt auf, wenn sich Gerätefehler (die auf eines oder mehrere fehlende bzw. beschädigte Datenspeichergeräte hinweisen) auf virtuelle Geräte der obersten Hierarchieebene auswirken. So können beispielsweise in einer Hälfte einer Datenspiegelungskonfiguration Tausende Gerätefehler auftreten, ohne dass dies zur Datenbeschädigung führt. Wenn in der anderen Hälfte der Datenspiegelungskonfiguration an genau der gleichen Stelle ein Fehler auftritt, verursacht das eine Datenbeschädigung.

Eine Datenbeschädigung ist stets bleibend und muss bei der Reparatur besonders berücksichtigt werden. Auch wenn die betreffenden Datenspeichergeräte repariert oder ausgetauscht werden, sind die ursprünglichen Daten für immer verloren. Meist müssen Daten in solchen Situationen aus Sicherungskopien wiederhergestellt werden. Datenfehler werden beim Auftreten protokolliert und können durch regelmäßige Pool-Bereinigung (siehe folgender Abschnitt) in Grenzen gehalten werden. Beim Entfernen eines beschädigten Datenblocks erkennt der nächste Durchlauf der Datenträgerbereinigung, dass die Datenbeschädigung nicht mehr auf dem System vorhanden ist und entfernt die Protokollierung des Fehlers vom System.

Überprüfen der Integrität des ZFS-Dateisystems

Für ZFS gibt es kein Dienstprogramm wie fsck. Dieses Dienstprogramm diente üblicherweise zur Reparatur und Validierung von Dateisystemen.

Reparatur von Dateisystemen

Bei herkömmlichen Dateisystemen ist die Art und Weise des Schreibens von Daten von Natur aus anfällig für unerwartete Ausfälle, die zu Inkonsistenzen im Dateisystem führen. Da herkömmliche Dateisysteme nicht transaktionsorientiert sind, können unreferenzierte Datenblöcke, ungültige Verknüpfungszähler oder andere inkonsistente Dateisystemstrukturen auftreten. Mit der Einführung des so genannten Journaling wurden zwar einige dieser Probleme behoben, es können jedoch neue Probleme auftreten, wenn Transaktionen nicht rückgängig gemacht werden können. Inkonsistente Daten in einer ZFS-Konfiguration können nur bei Hardware-Ausfällen (was durch redundante Pools vermieden werden kann) oder bei Fehlern in der ZFS-Software auftreten.

Das Dienstprogramm fsck beseitigt bekannte Probleme, von denen UFS-Dateisysteme betroffen sind. Die meisten Probleme, von denen ZFS-Speicher-Pools betroffen sind, sind auf ausgefallene Hardware oder Stromausfälle zurückzuführen. Viele Probleme können durch redundante Pools vermieden werden. Wenn Ihr Pool durch ausgefallene Hardware oder einen Stromausfall beschädigt wurde, gehen Sie wie unter Reparieren von Schäden am gesamten ZFS-Speicher-Pool beschrieben vor.

Wenn ein Pool nicht redundant ist, besteht immer das Risiko, dass Sie nach einer Beschädigung des Dateisystems nicht mehr auf Ihre Daten zugreifen können.

Validierung von Dateisystemen

Neben der Dateisystemreparatur stellt das Dienstprogramm fsck sicher, dass Daten auf einem Datenträger fehlerfrei sind. Diese Validierung wird üblicherweise durch Aushängen des betreffenden Dateisystems und Ausführen des Dienstprogramms fsck durchgeführt. Während dieses Vorgangs muss das System möglicherweise in den Einzelbenutzermodus gebracht werden. Daraus resultieren Ausfallzeiten, die proportional zur Größe des zu überprüfenden Dateisystems sind. Statt eines Dienstprogramms zum expliziten Ausführen der entsprechenden Überprüfungen besitzt ZFS einen Mechanismus zur regelmäßigen Überprüfung auf Inkonsistenzen. Diese als Bereinigung bezeichnete Funktion wird häufig in Arbeitsspeichern und anderen Systemen als Methode des Erkennens und Vermeidens von Problemen eingesetzt, die Hardwareausfälle oder Softwarefehlfunktionen verursachen.

Kontrollieren der ZFS-Datenbereinigung

Wenn ZFS einen Fehler erkennt (der auf die Bereinigung oder den Zugriff auf Dateien zurückzuführen ist), wird dieser intern protokolliert, sodass Sie einen schnellen Überblick über alle bekannten Fehler im Pool erhalten.

Explizite ZFS-Datenbereinigung

Die einfachste Methode zum Überprüfen der Datenintegrität besteht im Durchführen einer expliziten Bereinigung aller im Pool enthaltenen Daten. Diesem Vorgang werden alle Daten im Pool einmalig unterzogen, wodurch sichergestellt wird, dass alle Datenblöcke gelesen werden können. Die Bereinigung erfolgt so schnell, wie es das entsprechende Datenspeichergerät zulässt, obwohl E/A-Vorgänge eine niedrigere Priorität als normale Prozessen haben. Dieser Vorgang kann sich negativ auf die Systemleistung auswirken, obgleich die Daten des Pools während der Bereinigung weiterhin verwendbar und weitgehend verfügbar bleiben sollten. Explizite Bereinigungen können mit dem Befehl zpool scrub ausgeführt werden. Beispiel:

# zpool scrub tank

Der Status der aktuellen Bereinigung kann mithilfe des Befehls zpool status angezeigt werden. Beispiel:

# zpool status -v tank
  pool: tank
 state: ONLINE
 scrub: scrub completed after 0h7m with 0 errors on Tue Tue Feb  2 12:54:00 2010
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c1t0d0  ONLINE       0     0     0
            c1t1d0  ONLINE       0     0     0

errors: No known data errors

Pro Pool kann immer nur eine aktive Bereinigung ausgeführt werden.

Mithilfe der Option -s können Sie eine laufende Bereinigung stoppen. Beispiel:

# zpool scrub -s tank

In den meisten Fällen sollte eine Bereinigung vollständig abgeschlossen werden, um die Datenintegrität sicherzustellen. Falls sich eine Bereinigung negativ auf die Systemleistung auswirkt, können Sie sie jederzeit abbrechen.

Durch regelmäßige Bereinigungen wird kontinuierlicher E/A-Datenverkehr zu allen Datenträgern des Systems gewährleistet. Ein Nebeneffekt der Bereinigung besteht darin, dass die Stromverwaltung im Leerlauf befindliche Datenträger nicht in den Energiesparmodus schalten kann. Wenn das System E/A-Vorgänge jederzeit und ohne größere Störungen ausführen kann oder Stromverbrauch kein Problem ist, kann dieser Effekt problemlos ignoriert werden.

Weitere Informationen zur Interpretation der Ausgabe des Befehls zpool status finden Sie unter Abfragen des Status von ZFS-Speicher-Pools.

ZFS-Datenbereinigung und Resilvering

Nach dem Ersetzen eines Datenspeichergeräts wird ein so genanntes ?Resilvering“ (Wiederaufspielen von Daten) durchgeführt, um Daten von unbeschädigten Kopien auf den neuen Datenträger zu kopieren. Dieser Vorgang ist eine Form der Datenträgerbereinigung. Aus diesem Grunde kann in einem Pool immer nur ein solcher Vorgang stattfinden. Ist eine Bereinigung im Gange, wird sie durch das Resilvering unterbrochen und nach Abschluss des Resilvering fortgesetzt.

Weitere Informationen zum Resilvering finden Sie unter Anzeigen des Resilvering-Status.

Beheben von Problemen mit ZFS

In den folgenden Abschnitten wird beschrieben, wie Sie Probleme mit ZFS-Dateisystem oder Speicher-Pools erkennen und beheben können:

• Ermitteln, ob in einem ZFS-Speicher-Pool Probleme vorhanden sind

• Überprüfen der Ausgabe des Befehls zpool status

• Systemprotokoll mit ZFS-Fehlermeldungen

Die folgenden Leistungsmerkmale dienen zur Problemerkennung in ZFS-Konfigurationen:

• Mithilfe des Befehls zpool status können ausführliche Informationen zum ZFS-Speicher-Pool angezeigt werden.

• Pool- und Gerätefehler werden mit ZFS/FMA-Diagnosemeldungen gemeldet.

• Frühere ZFS-Befehle, durch die Informationen zum Pool-Status geändert wurden, können mithilfe des Befehls zpool history angezeigt werden.

Die meisten ZFS-Probleme können mithilfe des Befehls zpool status erkannt werden. Mithilfe dieses Befehls werden verschiedene Fehlfunktionen im System analysiert, die wichtigsten Probleme erkannt und Empfehlungen zu Abhilfemaßnahmen sowie Verweise auf entsprechende Artikel in der Sun Knowledge Base angezeigt. Beachten Sie, dass der Befehl nur ein einziges Problem im Pool erkennen kann, obwohl mehrere Probleme vorhanden sein können. Bei Datenbeschädigungsfehlern wird beispielsweise stets vorausgesetzt, dass ein Datenspeichergerät ausgefallen ist. Durch den Austausch des ausgefallenen Geräts werden jedoch möglicherweise nicht alle Datenbeschädungsprobleme behoben.

Außerdem diagnostiziert und meldet ein ZFS-Diagnoseprogramm Pool- und Datenträgerausfälle. Darüber hinaus werden mit solchen Ausfällen im Zusammenhang stehende Prüfsummen-, E/A-, Geräte- und Poolfehler gemeldet. Von fmd gemeldete ZFS-Fehler werden auf der Konsole angezeigt und in der Systemprotokolldatei festgehalten. In den meisten Fällen verweist Sie die fmd-Meldung auf den Befehl zpool status, mit dessen Hilfe Sie das Problem weiter verfolgen können.

Der grundlegende Problembehebungsvorgang läuft wie folgt ab:

• Suchen Sie, falls möglich, mit dem Befehl zpool history die früheren ZFS-Befehle, die vor Auftreten des Problems ausgeführt wurden. Beispiel:

  # zpool history tank History for 'tank': 2010-07-15.12:06:50 zpool create tank mirror c0t1d0 c0t2d0 c0t3d0 2010-07-15.12:06:58 zfs create tank/erick 2010-07-15.12:07:01 zfs set checksum=off tank/erick

  Beachten Sie, dass in dieser Befehlsausgabe die Prüfsummen für das Dateisystem tank/erick deaktiviert sind. Diese Konfiguration wird nicht empfohlen.

• Suchen Sie die Fehler in den fmd-Meldungen, die an der Systemkonsole bzw. in der Datei unter /var/adm/messages angezeigt werden.

• Weitere Reparaturanweisungen finden Sie mithilfe des Befehls zpool status -x.

• Beheben Sie die Probleme, indem Sie wie folgt vorgehen:

  • Ersetzen Sie das ausgefallen oder fehlende Gerät durch ein neues Gerät, und setzen Sie das neue Gerät in Betrieb.

  • Stellen Sie mithilfe einer Sicherungskopie die fehlerhafte Konfiguration bzw. die beschädigten Daten wieder her.

  • Überprüfen Sie die Wiederherstellung mithilfe des Befehls zpool status - x.

  • Erstellen Sie eine Sicherungskopie der wiederhergestellten Konfiguration (falls möglich).

In diesem Abschnitt wird beschrieben, wie Sie die Ausgabe des Befehls zpool status interpretieren, damit Sie Fehler diagnostizieren können. Obwohl die meisten Aufgaben automatisch mithilfe des Befehls ausgeführt werden, müssen Sie genau wissen, um welche Probleme es sich handelt, damit Sie den Ausfall diagnostizieren können. In den nachfolgenden Abschnitten wird beschrieben, wie Sie verschiedenen vorgefundene Probleme beheben können.

Ermitteln, ob in einem ZFS-Speicher-Pool Probleme vorhanden sind

Mit dem Befehl zpool status -x können Sie am einfachsten herausfinden, ob in einem System Probleme vorliegen. Mithilfe dieses Befehls werden nur Pools angezeigt, die problembehaftet sind. Wenn in einem System alle Pools ordnungsgemäß funktionieren, wird nur Folgendes angezeigt:

# zpool status -x
all pools are healthy

Ohne das Flag -x werden mithilfe des Befehls die gesamten Statusinformationen aller Pools (oder eines in der Befehlszeile angegebenen Pools) angezeigt, auch wenn diese ordnungsgemäß funktionieren.

Weitere Informationen zu Befehlszeilenoptionen des Befehls zpool status finden Sie unter Abfragen des Status von ZFS-Speicher-Pools.

Überprüfen der Ausgabe des Befehls zpool status

Die gesamte Ausgabe des Befehls zpool status sieht ungefähr wie folgt aus:

# zpool status tank
# zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            c1t0d0  ONLINE       0     0     0
            c1t1d0  UNAVAIL      0     0     0  cannot open

errors: No known data errors

Es folgt eine Beschreibung dieser Ausgabe:

Gesamtinformationen zum Pool-Status

Dieser Abschnitt der Ausgabe des Befehls zpool status enthält die folgenden Felder (einige dieser Felder werden nur angezeigt, wenn im Pool Probleme auftreten):

pool

Gibt den Namen des Pools an.

state

Zeigt den aktuellen Funktionsstatus des Pools an. Diese Informationen beziehen sich lediglich auf die Fähigkeit des Pools, für die erforderliche Replikation zu sorgen.

status

Beschreibt, was mit dem Pool nicht in Ordnung ist. Dieses Feld wird nicht angezeigt, wenn keine Fehler gefunden wurden.

action

Eine empfohlene Aktion zur Fehlerbehebung. Dieses Feld wird nicht angezeigt, wenn keine Fehler gefunden wurden.

see

Verweist auf einen Artikel in der Sun Knowledge Base, der ausführliche Reparaturinformationen enthält. Online-Artikel werden öfter als dieses Handbuch aktualisiert und enthalten stets die aktuellsten Reparaturanweisungen. Dieses Feld wird nicht angezeigt, wenn keine Fehler gefunden wurden.

scrub

Zeigt den aktuellen Status einer Bereinigung an (Datum und Uhrzeit der letzten Bereinigung, Informationen zu einer laufenden Bereinigung, Informationen zur Anforderung von Bereinigungen).

errors

Zeigt bekannte bzw. unbekannte Datenfehler an.

Pool-Konfigurationsinformationen

Das Feld config in der Ausgabe des Befehls zpool status beschreibt die Konfigurationsstruktur der Datenspeichergeräte, die den Pool bilden, sowie deren Status und die von diesen Geräten herrührenden Fehler. Der Status kann die folgenden Werte annehmen: ONLINE, FAULTED, DEGRADED, UNAVAIL oder OFFLINE. Wenn der Status eines Pools nicht ONLINE ist, wurde die Fehlertoleranz des Pools eingeschränkt.

Im zweiten Abschnitt der Konfigurationsinformationen wird die Fehlerstatistik angezeigt. Diese Fehler werden in drei Kategorien eingeteilt:

• READ – E/A-Fehler während der Ausgabe einer Leseanforderung

• WRITE – E/A-Fehler während der Ausgabe einer Schreibanforderung

• CKSUM – Prüfsummenfehler, d. h., das Gerät hat nach einer Leseanforderung beschädigte Daten zurückgegeben.

Mithilfe dieser Kategorien kann ermittelt werden, ob es sich um bleibende Schäden handelt. Eine geringe Anzahl auftretender E/A-Fehler kann die Folge zeitweiliger Ausfälle sein, während eine größere Anzahl an E/A-Fehlern auf ein bleibendes Problem mit dem entsprechenden Gerät hinweisen kann. Bei diesen Fehlern muss es sich nicht unbedingt um Datenbeschädigung handeln, auch wenn sie von den Anwendungen so interpretiert werden. Wenn das Gerät zu einer redundanten Konfiguration gehört, kann es sein, dass die Datenträger nicht behebbare Fehler aufweisen, während auf der RAID-Z- bzw. Datenspiegelungsebene keine Fehler angezeigt werden. In solchen Fällen hat ZFS die unbeschädigten Daten erfolgreich abgerufen und versucht, die beschädigten Daten durch vorhandene Replikationen zu ersetzen.

Weitere Informationen zur Interpretation dieser Fehler finden Sie unter Ermitteln des Gerätefehlertyps.

Zusätzliche hilfreiche Informationen werden in der letzten Spalte der Ausgabe des Befehls zpool status angezeigt. Diese Information ergänzen die im Feld state enthaltenen Informationen und helfen bei der Diagnose von Fehlern. Bei Datenspeichergeräten mit dem Status FAULTED zeigt dieses Feld an, ob auf das betreffende Gerät zugegriffen werden kann oder die Daten auf dem Gerät beschädigt sind. Wenn auf das Datenspeichergerät mithilfe von Resilvering Daten neu aufgespielt werden, zeigt dieses Feld den Verlauf dieses Vorgangs an.

Weitere Informationen zur Überwachung des Resilvering-Vorgangs finden Sie in Anzeigen des Resilvering-Status.

Status eines Bereinigungsvorgangs

Im Bereinigungsabschnitt der Ausgabe des Befehls zpool status wird der aktuelle Status von Bereinigungsvorgängen angezeigt, die explizit ausgeführt werden. Diese Informationen weisen nicht auf Fehler hin, die im System aufgetreten sind, können aber zum Ermitteln der Genauigkeit des Meldens von Datenbeschädigungsfehlern herangezogen werden. Wenn die letzte Bereinigung erst vor kurzem ausgeführt wurde, sind Datenbeschädigungen höchstwahrscheinlich bereits bekannt.

Meldungen zum Abschluss von Bereinigungen bleiben nach Systemneustarts erhalten.

Weitere Informationen zur Datenbereinigung und zur Interpretation dieser Informationen finden Sie unter Überprüfen der Integrität des ZFS-Dateisystems.

Datenbeschädigungsfehler

Der Befehl zpool status zeigt auch an, ob im Zusammenhang mit einem Pool bekannte Fehler aufgetreten sind. Diese Fehler können während der Datenbereinigung oder im Normalbetrieb gefunden worden sein. ZFS führt ein kontinuierliches Protokoll aller mit einem Pool im Zusammenhang stehenden Datenfehler. Nach jedem Abschluss einer vollständigen Systembereinigung wird das Protokoll entsprechend aktualisiert.

Datenbeschädigungsfehler sind stets schwerwiegend. Ihr Vorhandensein weist darauf hin, dass bei mindestens einem Anwendungsprogramm aufgrund beschädigter Daten im Pool ein E/A-Fehler aufgetreten ist. Gerätefehler innerhalb eines redundanten Pools verursachen keine Datenbeschädigung und werden in diesem Protokoll nicht festgehalten. Standardmäßig wird nur die Anzahl der gefundenen Fehler angezeigt. Eine vollständige Liste mit Fehlern und deren Informationen kann mit dem Befehl zpool status -v angezeigt werden. Beispiel:

# zpool status -v
  pool: tank
 state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
   see: http://www.sun.com/msg/ZFS-8000-HC
 scrub: scrub completed after 0h0m with 0 errors on Tue Feb  2 13:08:42 2010
config:

        NAME        STATE     READ WRITE CKSUM
        tank        UNAVAIL      0     0     0  insufficient replicas
          c1t0d0    ONLINE       0     0     0
          c1t1d0    UNAVAIL      4     1     0  cannot open

errors: Permanent errors have been detected in the following files: 

/tank/data/aaa
/tank/data/bbb
/tank/data/ccc

Eine ähnliche Meldung wird auch von fmd auf der Systemkonsole angezeigt und in der Datei /var/adm/messages protokolliert. Diese Meldungen können auch mit dem Befehl fmdump verfolgt werden.

Weitere Informationen zur Interpretation von Datenbeschädigungsfehlern finden Sie unter Ermitteln der Art der Datenbeschädigung.

Systemprotokoll mit ZFS-Fehlermeldungen

Neben der kontinuierlichen Verfolgung von Fehlern innerhalb eines Pools zeigt ZFS beim Auftreten bestimmter Ereignisse auch Systemprotokollmeldungen an. In den folgenden Situationen werden Ereignisse zur Benachrichtigung des Administrators ausgelöst:

• Statusübergang eines Datenspeichergeräts – Wenn ein Datenspeichergerät in den Status FAULTED übergeht, protokolliert ZFS eine Meldung, die darauf hinweist, dass die Fehlertoleranz des Pools beeinträchtigt werden könnte. Eine ähnliche Meldung wird gesendet, wenn das Gerät später wieder in Betrieb genommen und die ordnungsgemäße Pool-Funktion wiederhergestellt wird.

• Datenbeschädigung – Beim Erkennen von Datenbeschädigungen protokolliert ZFS eine Meldung, die beschreibt, wann und wo die Datenbeschädigung erkannt wurde. Diese Meldung wird nur beim allerersten Auftreten des Ereignisses protokolliert. Ein nachfolgendes Auftreten dieser Ereignisses löst keine Meldung mehr aus.

• Pool- und Geräteausfälle – Wenn ein Pool oder Gerät ausfällt, meldet der Fehlerverwaltungsdämon diese Fehler mithilfe von Systemprotokollmeldungen und mit dem Befehl fmdump.

Wenn ZFS einen Gerätefehler erkennt und diesen automatisch behebt, wird keine Benachrichtigung gesendet. Solche Fehler stellen keine Einschränkung der Pool-Redundanz bzw. Datenintegrität dar und sind darüber hinaus normalerweise die Folge eines Treiberproblems mit eigenen entsprechenden Fehlermeldungen.

Reparieren einer beschädigten ZFS-Konfiguration

ZFS unterhält im Root-Dateisystem einen Cache aktiver Pools und ihrer Konfiguration. Wenn diese Cache-Datei beschädigt wird bzw. nicht mehr mit den auf dem Datenträger gespeicherten Konfigurationsinformationen übereinstimmt, kann auf einen Pool nicht mehr zugegriffen werden. ZFS versucht, eine solche Situation zu vermeiden, obwohl aufgrund der Eigenschaften des zugrunde liegenden Speichers immer die Möglichkeit besteht, dass Daten beschädigt werden können. Solche Situationen führen normalerweise zu einem Verschwinden eines ansonsten verfügbaren Pools aus dem System und können sich auch in unvollständigen Konfigurationen manifestieren, denen eine unbekannte Anzahl an virtuellen Geräten der obersten Hierarchie fehlt. In allen Fällen kann die Konfiguration durch Exportieren des Pools (falls er zugänglich ist) und anschließendes Importieren wiederhergestellt werden.

Weitere Informationen zum Importieren und Exportieren von Pools finden Sie unter Migrieren von ZFS-Speicher-Pools.

Abhilfe bei Nichtverfügbarkeit eines Geräts

Wenn auf ein Gerät nicht zugegriffen werden kann, wird es in der Ausgabe des Befehls zpool status mit dem Status UNAVAIL angezeigt. Dieser Status bedeutet, dass ZFS beim ersten Zugriff auf den Pool nicht auf das betreffende Datenspeichergerät zugreifen konnte oder es seitdem nicht mehr verfügbar ist. Wenn durch dieses Datenspeichergerät ein virtuelles Gerät der obersten Hierarchieebene nicht mehr verfügbar ist, können von diesem Pool keine Daten abgerufen werden. Andernfalls kann die Fehlertoleranz des Pools beeinträchtigt werden. In jedem Fall muss das Gerät zum Wiederherstellen des Normalbetriebs wieder in das System integriert werden.

Nach einem Geräteausfall wird von fmd in etwa die folgende Meldung angezeigt:

SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major
EVENT-TIME: Thu Jun 24 10:42:36 PDT 2010
PLATFORM: SUNW,Sun-Fire-T200, CSN: -, HOSTNAME: neo2
SOURCE: zfs-diagnosis, REV: 1.0
EVENT-ID: a1fb66d0-cc51-cd14-a835-961c15696fcb
DESC: The number of I/O errors associated with a ZFS device exceeded
acceptable levels.  Refer to http://sun.com/msg/ZFS-8000-FD for more information.
AUTO-RESPONSE: The device has been offlined and marked as faulted.  An attempt
will be made to activate a hot spare if available. 
IMPACT: Fault tolerance of the pool may be compromised.
REC-ACTION: Run 'zpool status -x' and replace the bad device.

Um ausführlichere Informationen zu Geräteproblemen und deren Behebung anzuzeigen, verwenden Sie den Befehl zpool status -x. Beispiel:

# zpool status -x
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
 scrub: scrub completed after 0h0m with 0 errors on Tue Feb  2 13:15:20 2010
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            c1t0d0  ONLINE       0     0     0
            c1t1d0  UNAVAIL      0     0     0  cannot open

errors: No known data errors

Diese Befehlsausgabe zeigt, dass das fehlende Gerät c1t1d0 nicht funktioniert. Wenn das Gerät fehlerhaft ist, ersetzen Sie es.

Nehmen Sie das ersetzte Gerät dann mit dem Befehl zpool online in Betrieb. Beispiel:

# zpool online tank c1t1d0

Als Letztes stellen Sie sicher, dass der Pool mit dem ersetzten Datenspeichergerät ordnungsgemäß funktioniert. Beispiel:

# zpool status -x tank
pool 'tank' is healthy

Wiedereinbinden eines Datenspeichergeräts

Die Art und Weise, wie ein fehlendes Datenspeichergerät wieder in ein System eingebunden wird, hängt vom jeweiligen Gerät ab. Wenn auf das Gerät über das Netzwerk zugegriffen wird, muss die Netzwerkverbindung wiederhergestellt werden. Wenn das Datenspeichergerät ein USB-Gerät oder ein anderer Wechseldatenträger ist, muss es wieder an das System angeschlossen werden. Wenn es sich bei dem betreffenden Gerät um eine lokale Festplatte handelt, kann es sein, dass das Gerät aufgrund eines Controller-Ausfalls nicht mehr vom System erkannt wird. In diesem Fall muss der Controller ausgetauscht werden, wonach die betreffenden Datenträger wieder verfügbar sind. Es können noch weitere Probleme vorliegen, die mit der der Art der Hardware und ihrer Konfiguration in Zusammenhang stehen. Wenn ein Laufwerk ausfällt und vom System nicht mehr erkannt wird, muss das Datenspeichergerät als beschädigt eingestuft werden. Folgen Sie der unter Ersetzen oder Reparieren eines beschädigten Geräts beschriebenen Vorgehensweise.

Benachrichtigung von ZFS nach Wiederherstellung der Verfügbarkeit

Nach dem Wiedereinbinden eines Datenspeichergeräts in das System erkennt ZFS unter Umständen seine Verfügbarkeit automatisch. Dies muss aber nicht so ein. Wenn der Pool ausgefallen war oder das System während der Wiedereinbindung neu gestartet wurde, sucht ZFS automatisch alle Datenspeichergeräte ab, während es versucht, auf den Pool zuzugreifen. Wenn der Pool in seiner Funktionstüchtigkeit beeinträchtigt war und das Gerät während des Systembetriebs ausgetauscht wurde, müssen Sie ZFS mithilfe des Befehls zpool online benachrichtigen, dass das Gerät jetzt wieder verfügbar ist und wieder auf das Gerät zugegriffen werden kann. Beispiel:

# zpool online tank c0t1d0

Weitere Informationen zum Inbetriebnehmen von Geräten finden Sie unter Inbetriebnehmen eines Gerätes.

Ersetzen oder Reparieren eines beschädigten Geräts

In diesem Abschnitt wird beschrieben, wie die verschiedenen Fehlertypen eines Datenspeichergerätes ermittelt, vorübergehende Fehler gelöscht und Geräte ausgetauscht werden können.

Ermitteln des Gerätefehlertyps

Der Begriff beschädigtes Gerät ist nicht klar umrissen und kann verschiedene mögliche Situationen beschreiben:

• Bitfäule – Mit der Zeit können äußere Einflüsse wie Magnetfelder und kosmische Strahlung dazu führen, dass auf Datenträgern gespeicherte Bits unvorhergesehene Werte annehmen. Solche Ereignisse sind relativ selten, treten aber häufig genug auf, um potenzielle Datenbeschädigung in größeren und lange laufenden Systemen zu verursachen.

• Fehlgeleitete Lese- oder Schreibvorgänge – Firmware- oder Hardwarefehler können dazu führen, dass Lese- oder Schreibvorgänge ganzer Datenblöcke auf den falschen Bereich auf dem Datenträger verweisen. Diese Fehler sind normalerweise vorübergehend, obwohl eine große Anzahl solcher Fehler auf ein fehlerhaftes Laufwerk hinweisen kann.

• Administratorfehler – Administratoren können versehentlich Datenträgerbereiche mit ungültigen Daten überschreiben (z. B. das Kopieren von /dev/zero auf bestimmte Datenträgerbereiche) und so Daten auf dem Datenträger dauerhaft beschädigen. Solche Fehler sind stets vorübergehend.

• Zeitweilige Ausfälle – Datenträger können zeitweilig ausfallen, wodurch E/A-Vorgänge fehlschlagen. Diese Situation tritt normalerweise bei Datenspeichergeräten auf, auf die über das Netzwerk zugegriffen wird, obwohl auch bei lokalen Datenträgern solche Ausfälle auftreten können. Solche Fehler sind können vorübergehend sein.

• Fehlerhafte bzw. unzuverlässig arbeitende Hardware – Unter diese Kategorie fallen alle durch fehlerhafte Hardware verursachten Probleme. Dies können dauerhafte E/A-Fehler, falscher Datentransport und daraus folgende regellose Datenbeschädigung sowie eine Reihe anderer Fehler sein. Solche Fehler sind normalerweise dauerhaft.

• Außer Betrieb genommene Datenspeichergeräte – Wenn ein Gerät außer Betrieb genommen wurde, wird angenommen, dass es der Administrator in diesen Zustand versetzt hat, weil es fehlerhaft ist. Der Administrator, der das Gerät in diesen Zustand versetzt hat, kann überprüfen, ob diese Annahme richtig ist.

Die genaue Ermittlung von Fehlerursachen kann sich schwierig gestalten. Der erste Schritt besteht darin, die Fehlerzähler in der Ausgabe des Befehls zpool status zu überprüfen. Beispiel:

# zpool status -v tpool
  pool: tpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scrub: scrub completed after 0h0m with 2 errors on Tue Jul 13 11:08:37 2010
config:

        NAME        STATE     READ WRITE CKSUM
        tpool       ONLINE       2     0     0
          c1t1d0    ONLINE       2     0     0
          c1t3d0    ONLINE       0     0     0
errors: Permanent errors have been detected in the following files:

        /tpool/words

Die Fehler werden in E/A- und Prüfsummenfehler unterteilt. Daraus lässt sich unter Umständen auf den Fehlertyp schließen. Im Normalbetrieb treten während einer langen Systemlaufzeit nur einige wenige Fehler auf. Wenn eine hohe Anzahl von Fehlern angezeigt wird, deutet dies wahrscheinlich auf einen bevorstehenden bzw. vollständigen Geräteausfall hin. Ein Administratorfehler kann jedoch ebenfalls zu hohen Fehleranzahlen führen. Eine weitere Informationsquelle ist das Systemprotokoll. Wenn das Protokoll eine große Anzahl an Meldungen von SCSI- bzw. Fibre Channel-Treibern enthält, weist dies möglicherweise auf schwerwiegende Hardwareprobleme hin. Wenn keine Systemmeldungen protokolliert werden, ist der Schaden wahrscheinlich vorübergehend.

Das Ziel besteht in der Beantwortung der folgenden Frage:

Ist es wahrscheinlich, dass an diesem Gerät wieder ein Fehler auftritt?

Nur einmal auftretende Fehler werden als vorübergehend eingestuft und ziehen keine potenziellen Ausfälle nach sich. Fehler, die dauerhaft oder ernstlich genug sind, um potenzielle Hardwareausfälle auszulösen, werden als schwerwiegend eingestuft. Die Ermittlung von Fehlertypen sprengt den Rahmen der gegenwärtig mit ZFS verfügbaren automatisierten Softwarelösungen und muss manuell vom Administrator durchgeführt werden. Nach der Ermittlung des Fehlertyps können entsprechende Abhilfemaßnahmen ergriffen werden. Diese bestehen entweder im Löschen vorübergehender Fehler oder im Austauschen des betreffenden Datenspeichergeräts aufgrund schwerwiegender Fehler. Die entsprechenden Reparaturvorgänge werden in den nächsten Abschnitten erläutert.

Auch wenn Gerätefehler als vorübergehend eingestuft wurden, können sie trotzdem nicht mehr rückgängig zu machende Datenfehler im Pool verursacht haben. Diese Fehler erfordern auch dann spezielle Reparaturmaßnahmen, wenn das zugrunde liegende Datenspeichergerät ordnungsgemäß funktioniert oder anderweitig repariert wurde. Weitere Informationen zum Beseitigen von Datenfehlern finden Sie unter Reparieren beschädigter Daten.

Löschen vorübergehender Fehler

Wenn Gerätefehler als vorübergehend eingestuft wurden und die zukünftige ordnungsgemäße Funktion des betreffenden Datenspeichergeräts nicht beeinträchtigen, können sie gelöscht werden. Damit wird angezeigt, dass kein schwerwiegender Fehler aufgetreten ist. Mit dem Befehl zpool clear können Sie Fehlerzähler für Datenspeichergeräte mit RAID-Z- bzw. Datenspiegelungskonfigurationen zurücksetzen. Beispiel:

# zpool clear tank c1t1d0

Mithilfe dieser Syntax werden alle Fehler gelöscht und alle Fehlerzähler zurückgesetzt, die mit dem betreffenden Datenspeichergerät in Zusammenhang stehen.

Zum Löschen aller mit den virtuellen Geräten im Pool in Verbindung stehenden Fehler und Zurücksetzen aller Fehlerzähler dient die folgende Syntax:

# zpool clear tank

Weitere Informationen zum Löschen von Pool-Fehlern finden Sie unter Löschen von Gerätefehlern im Speicher-Pool.

Austauschen eines Datenspeichergeräts in einem ZFS-Speicher-Pool

Wenn ein Datenspeichergerät dauerhaft beschädigt ist bzw. ein solcher Schaden bevorsteht, muss es ausgetauscht werden. Ob das betreffende Gerät ersetzt werden kann, hängt von der Konfiguration ab.

• Ermitteln, ob ein Gerät ausgetauscht werden kann

• Datenspeichergeräte, die nicht ausgetauscht werden können

• Austauschen eines Datenspeichergeräts in einem ZFS-Speicher-Pool

• Anzeigen des Resilvering-Status

Ermitteln, ob ein Gerät ausgetauscht werden kann

Damit ein Gerät ausgetauscht werden kann, muss sich der Pool im Status ONLINE befinden. Das betreffende Gerät muss zu einer redundanten Konfiguration gehören, oder es muss ordnungsgemäß funktionieren (d. h. sich im Status ONLINE befinden). Wenn das Gerät zu einer redundanten Konfiguration gehört, müssen ausreichende Replikationen vorhanden sein, aus denen unbeschädigte Daten wiederhergestellt werden können. Wenn zwei Datenträger in einer vierfachen Datenspiegelungskonfiguration fehlerhaft sind, können beide Datenträger ausgetauscht werden, da gültige Datenreplikationen vorhanden sind. Wenn jedoch zwei Datenträger in einer vierfachen RAID-Z-Konfiguration raidz1 fehlerhaft sind, kann keiner der beiden Datenträger ausgetauscht werden, da nicht genügend gültige Datenreplikationen verfügbar sind, aus denen Daten wiederhergestellt werden können. Wenn das Gerät beschädigt, aber noch in Betrieb ist, kann es ausgetauscht werden, solange sich der Pool nicht im Status FAULTED befindet. Wenn nicht genügend Replikationen mit gültigen Daten verfügbar sind, werden jedoch auch die beschädigten Daten auf das neue Datenspeichergerät kopiert.

In der folgenden Konfiguration kann der Datenträger c1t1d0 ausgetauscht werden, und die gesamten Daten im Pool werden von der ordnungsgemäßen Replikation c1t0d0 kopiert.

    mirror            DEGRADED
    c1t0d0             ONLINE
    c1t1d0             FAULTED

Der Datenträger c1t0d0 kann ebenfalls ausgetauscht werden, obwohl keine Datenselbstheilung erfolgen kann, da keine ordnungsgemäße Datenreplikation vorhanden ist.

In der folgenden Konfiguration kann keiner der fehlerhaften Datenträger ausgetauscht werden. Die Datenträger mit dem Status ONLINE können ebenfalls nicht ausgetauscht werden, da der Pool selbst fehlerhaft ist.

    raidz              FAULTED
    c1t0d0             ONLINE
    c2t0d0             FAULTED
    c3t0d0             FAULTED
    c4t0d0             ONLINE

In der folgenden Konfiguration können alle Datenträger der obersten Hierarchieebene ausgetauscht werden, obwohl auch auf den alten Datenträgern befindliche ungültige Daten auf den neuen Datenträger kopiert werden.

c1t0d0         ONLINE
c1t1d0         ONLINE

Wenn alle Datenträger fehlerhaft sind, kann nichts ausgetauscht werden, da dann der Pool selbst fehlerhaft ist.

Datenspeichergeräte, die nicht ausgetauscht werden können

Wenn ein Pool durch den Ausfall eines Datenspeichergeräts fehlerhaft wird oder das betreffende Gerät in einer nicht redundanten Konfiguration zu viele Datenfehler enthält, kann es nicht sicher ausgetauscht werden. Ohne ausreichende Redundanz sind keine entsprechenden gültigen Daten vorhanden, die die Fehler auf dem beschädigten Gerät beseitigen könnten. In einem solchen Fall besteht nur die Möglichkeit, den Pool zu löschen, die Konfiguration neu zu erstellen und die Daten aus einer Sicherungskopie wiederherzustellen.

Weitere Informationen zum Wiederherstellen eines gesamten Pools finden Sie unter Reparieren von Schäden am gesamten ZFS-Speicher-Pool.

Austauschen eines Datenspeichergeräts in einem ZFS-Speicher-Pool

Wenn Sie ermittelt haben, dass ein Datenspeichergerät ausgetauscht werden kann, können Sie es mithilfe des Befehls zpool replace ersetzen. Um ein beschädigtes Gerät durch ein anderes Gerät zu ersetzen, verwenden Sie eine Syntax wie die folgende:

# zpool replace tank c1t1d0 c2t0d0

Mithilfe dieses Befehls werden Daten vom beschädigten Gerät oder von anderen Geräten im Pool, sofern sich dieser in einer redundanten Konfiguration befindet, auf das neue Gerät migriert. Nach Abschluss des Befehls wird das beschädigte Datenspeichergerät von der Konfiguration abgetrennt und kann dann aus dem System entfernt werden. Wenn Sie das Datenspeichergerät bereits entfernt und an der gleichen Stelle durch ein neues Gerät ersetzt haben, sollten Sie das Einzelgeräteformat des Befehls verwenden. Beispiel:

# zpool replace tank c1t1d0

Mithilfe dieses Befehls wird das neue Datenspeichergerät formatiert, und anschließend werden die Daten aus der Konfiguration durch Resilvering aufgespielt.

Weitere Informationen zum Befehl zpool replace finden Sie unter Austauschen von Geräten in einem Speicher-Pool.

Beispiel 11–1 Austauschen eines Datenspeichergeräts in einem ZFS-Speicher-Pool

Das folgende Beispiel zeigt, wie ein Gerät (c1t3d0) in einem Speicher-Pool mit Datenspiegelung tank auf einem Sun Fire x4500-System von Oracle ersetzt wird. Um die Festplatte c1t3d0 durch eine neue Festplatte an derselben Position (c1t3d0) ersetzen, müssen Sie die Festplatte zunächst dekonfigurieren. Der Vorgang wird im Wesentlichen wie folgt durchgeführt:

• Nehmen Sie die Festplatte (c1t3d0), die ersetzt werden soll, außer Betrieb. Eine in Gebrauch befindliche Festplatte kann nicht dekonfiguriert werden.

• Verwenden Sie den Befehl cfgadm, um die betroffene Festplatte (c1t3d0) zu ermitteln, und entfernen Sie sie aus der Konfiguration. Der Pool wird durch die außer Betrieb genommene Festplatte in der Datenspiegelungskonfiguration in einen eingeschränkten Zustand versetzt, bleibt aber weiterhin verfügbar.

• Ersetzen Sie die Festplatte physisch (c1t3d0). Vergewissern Sie sich vor dem Ausbauen des fehlerhaften Laufwerks, dass die blaue Ausbaubereitschaft-LED leuchtet.

• Konfigurieren Sie die Festplatte (c1t3d0) erneut.

• Setzen Sie die neue Festplatte (c1t3d0) in Betrieb.

• Führen Sie den Befehl zpool replace aus, um die Festplatte (c1t3d0) zu ersetzen.

  ---

  Hinweis –

  Wenn Sie zuvor die Eigenschaft autoreplace des Pools auf on gesetzt haben, wird jedes neue Gerät, das sich an der gleichen Stelle befindet, an der sich zuvor ein anderes zum Pool gehörendes Geräts befand, automatisch formatiert und ohne den Befehl zpool replace ersetzt. Dieses Leistungsmerkmal wird möglicherweise nicht auf jeder Art von Hardware unterstützt.

  ---

• Wenn eine ausgefallene Festplatte automatisch durch eine Hot-Spare-Festplatte ersetzt wurde, müssen Sie die Hot-Spare-Festplatte möglicherweise nach dem Ersetzen der ausgefallenen Festplatte abtrennen. Wenn c2t4d0 beispielsweise noch immer eine aktive Hot-Spare-Festplatte ist, nachdem die ausgefallene Festplatte ersetzt wurde, trennen Sie sie ab.

  # zpool detach tank c2t4d0

Im folgenden Beispiel wird gezeigt, wie eine Festplatte in einem ZFS-Speicher-Pool ersetzt wird.

# zpool offline tank c1t3d0
# cfgadm | grep c1t3d0
sata1/3::dsk/c1t3d0            disk         connected    configured   ok
# cfgadm -c unconfigure sata1/3
Unconfigure the device at: /devices/pci@0,0/pci1022,7458@2/pci11ab,11ab@1:3
This operation will suspend activity on the SATA device
Continue (yes/no)? yes
# cfgadm | grep sata1/3
sata1/3                        disk         connected    unconfigured ok
<Physically replace the failed disk c1t3d0>
# cfgadm -c configure sata1/3
# cfgadm | grep sata1/3
sata1/3::dsk/c1t3d0            disk         connected    configured   ok
# zpool online tank c1t3d0
# zpool replace tank c1t3d0
# zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h0m with 0 errors on Tue Feb  2 13:17:32 2010
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0
            c1t1d0  ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            c0t2d0  ONLINE       0     0     0
            c1t2d0  ONLINE       0     0     0
          mirror-2  ONLINE       0     0     0
            c0t3d0  ONLINE       0     0     0
            c1t3d0  ONLINE       0     0     0

errors: No known data errors

Beachten Sie, dass in der obigen zpool-Ausgabe sowohl die neue als auch die alte Festplatte unter replacing (wird ersetzt) angezeigt werden kann. Beispiel:

replacing     DEGRADED     0     0    0
  c1t3d0s0/o  FAULTED      0     0    0
  c1t3d0      ONLINE       0     0    0

Dieser Text bedeutet, dass der Austauschvorgang läuft und an der neuen Festplatte das Resilvering durchgeführt wird.

Um eine Festplatte (c1t3d0) durch eine andere Festplatte (c4t3d0) zu ersetzen, müssen Sie nur den Befehl zpool replace ausführen. Beispiel:

# zpool replace tank c1t3d0 c4t3d0
# zpool status
  pool: tank
 state: DEGRADED
 scrub: resilver completed after 0h0m with 0 errors on Tue Feb  2 13:35:41 2010
config:

        NAME             STATE     READ WRITE CKSUM
        tank             DEGRADED     0     0     0
          mirror-0       ONLINE       0     0     0
            c0t1d0       ONLINE       0     0     0
            c1t1d0       ONLINE       0     0     0
          mirror-1       ONLINE       0     0     0
            c0t2d0       ONLINE       0     0     0
            c1t2d0       ONLINE       0     0     0
          mirror-2       DEGRADED     0     0     0
            c0t3d0       ONLINE       0     0     0
            replacing    DEGRADED     0     0     0
              c1t3d0     OFFLINE      0     0     0
              c4t3d0     ONLINE       0     0     0

errors: No known data errors

Mitunter muss der Befehl zpool status mehrmals ausgeführt werden, bevor der Austauschvorgang abgeschlossen ist.

# zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h0m with 0 errors on Tue Feb  2 13:35:41 2010
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            c0t1d0    ONLINE       0     0     0
            c1t1d0    ONLINE       0     0     0
          mirror-1    ONLINE       0     0     0
            c0t2d0    ONLINE       0     0     0
            c1t2d0    ONLINE       0     0     0
          mirror-2    ONLINE       0     0     0
            c0t3d0    ONLINE       0     0     0
            c4t3d0    ONLINE       0     0     0

Beispiel 11–2 Ersetzen eines fehlgeschlagenen Protokolliergeräts

Das folgende Beispiel zeigt die Wiederherstellung des Normalzustands nach dem Ausfall eines Protokolliergeräts (c0t5d0) im Speicher-Pool (pool). Der Vorgang wird im Wesentlichen wie folgt durchgeführt:

• Überprüfen Sie die Ausgabe des Befehls zpool status-x und die FMA-Diagnosemeldung, beschrieben unter:

  http://www.sun.com/msg/ZFS-8000-K4

• Ersetzen Sie das fehlgeschlagene Protokolliergerät physisch.

• Nehmen Sie das neue Protokolliergerät in Betrieb.

• Löschen Sie den Fehlerzustand des Pools.

# zpool status -x
  pool: pool
 state: FAULTED
status: One or more of the intent logs could not be read.
        Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
        or ignore the intent log records by running 'zpool clear'.
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        pool        FAULTED      0     0     0 bad intent log
          mirror    ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0
            c0t4d0  ONLINE       0     0     0
        logs        FAULTED      0     0     0 bad intent log
          c0t5d0    UNAVAIL      0     0     0 cannot open
<Physically replace the failed log device>
# zpool online pool c0t5d0
# zpool clear pool

# zpool status -x
  pool: pool
 state: FAULTED
status: One or more of the intent logs could not be read.
        Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
        or ignore the intent log records by running 'zpool clear'.
 scrub: none requested
config:

        NAME          STATE     READ WRITE CKSUM
        pool          FAULTED      0     0     0 bad intent log
          mirror-0    ONLINE       0     0     0
            c0t1d0    ONLINE       0     0     0
            c0t4d0    ONLINE       0     0     0
        logs          FAULTED      0     0     0 bad intent log
          c0t5d0      UNAVAIL      0     0     0 cannot open
<Physically replace the failed log device>
# zpool online pool c0t5d0
# zpool clear pool

Anzeigen des Resilvering-Status

Je nach Kapazität des Datenträgers und der Datenmenge im Pool kann das Austauschen eines Datenspeichergeräts geraume Zeit dauern. Der Vorgang des Übertragens von Daten von einem Datenspeichergerät auf ein anderes Gerät nennt man Resilvering. Er kann mithilfe des Befehls zpool status überwacht werden.

Herkömmliche Dateisysteme kopieren Daten auf Datenblockebene. Da in ZFS die künstliche Schicht des Volume Managers beseitigt wurde, kann das Resilvering hier viel leistungsfähiger und kontrollierter durchgeführt werden. Die beiden Hauptvorteile dieser Funktion bestehen in Folgendem:

• ZFS kopiert beim Resilvering nur die Mindestmenge erforderlicher Daten. Im Falle eines kurzen Ausfalls (im Gegensatz zu einem vollständigen Austausch von Datenspeichergeräten) können Daten innerhalb weniger Minuten bzw. Sekunden auf den gesamten Datenträger aufgespielt werden. Nach dem Austauschen eines Datenträgers ist der Zeitraum, den das Wiederaufspielen von Daten benötigt, proportional zur Datenmenge auf dem betreffenden Datenträger. Der Austausch eines 500-GB-Datenträgers kann in Sekundenschnelle durchgeführt werden, wenn im Pool nur einige wenige GB mit Daten belegt sind.

• Das Resilvering kann unterbrochen werden und ist sicher. Wenn am System ein Stromausfall auftritt oder es neu gestartet wird, fährt der Resilvering-Vorgang an genau der Stelle fort, wo er unterbrochen wurde, ohne dass dazu manuelle Eingriffe erforderlich sind.

Der Status des Resilvering-Vorgangs kann mit dem Befehl zpool status angezeigt werden. Beispiel:

# zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress for 0h0m, 22.60% done, 0h1m to go
config:
        NAME                  STATE     READ WRITE CKSUM 
        tank             DEGRADED     0     0     0
          mirror-0       DEGRADED     0     0     0
            replacing-0  DEGRADED     0     0     0
              c1t0d0     UNAVAIL      0     0     0  cannot open
              c2t0d0     ONLINE       0     0     0  85.0M resilvered
            c1t1d0       ONLINE       0     0     0

errors: No known data errors

In diesem Beispiel wird der Datenträger c1t0d0 durch das Gerät c2t0d0 ersetzt. Dieses Ereignis wird in der Statusausgabe durch das virtuelle Ersatzgerät in der Konfiguration dargestellt. Dieses Gerät ist kein echtes Gerät, und Sie können mit diesem Gerät auch keinen Pool erstellen. Der Zweck dieses Geräts besteht lediglich darin, den Resilvering-Vorgang anzuzeigen, damit festgestellt werden kann, welcher Datenträger ausgetauscht wird.

Beachten Sie, dass ein Pool, in dem ein Resilvering stattfindet, in den Status ONLINE oder DEGRADED versetzt wird, da er während des Resilvering-Vorgangs nicht das erforderliche Niveau an Datenredundanz gewährleisten kann. Das Resilvering findet so schnell wie möglich statt, obwohl die damit verbundenen E/A-Prozesse stets eine niedrigere Priorität als E/A-Benutzeranforderungen haben, um die Auswirkung auf die Systemleistung zu minimieren. Nach dem Abschluss des Resilvering wird die neue, vollständige Konfiguration vom System übernommen. Beispiel:

# zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h1m with 0 errors on Tue Feb  2 13:54:30 2010
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c2t0d0  ONLINE       0     0     0  377M resilvered
            c1t1d0  ONLINE       0     0     0

errors: No known data errors

Der Pool befindet sich jetzt wieder im Status ONLINE, und der ursprüngliche ausgefallene Datenträger (c1t0d0) wurde aus der Konfiguration entfernt.

Reparieren beschädigter Daten

In den folgenden Abschnitten wird beschrieben, wie Sie den Typ der Datenbeschädigung ermitteln und (falls möglich) Daten reparieren können.

• Ermitteln der Art der Datenbeschädigung

• Reparatur beschädigter Dateien bzw. Verzeichnisse

• Reparieren von Schäden am gesamten ZFS-Speicher-Pool

Zur Minimierung des Risikos von Datenbeschädigung nutzt ZFS Prüfsummenberechnung, Redundanz und Datenselbstheilung. Dennoch können Datenbeschädigungen auftreten, wenn ein Pool nicht redundant ist. Dies ist der Fall, wenn sich der Pool zum Zeitpunkt der Beschädigung in beeinträchtigtem Zustand befindet oder mehrere Datenkopien durch unvorhergesehene Ereignisse beschädigt werden. Unabhängig von der Ursache ist das Ergebnis dasselbe: Daten werden beschädigt und sind deswegen nicht mehr verfügbar. Die erforderlichen Abhilfemaßnahmen hängen von der Art der beschädigten Daten und ihrem relativen Wert ab. Es können zwei grundlegende Arten von Daten beschädigt werden:

• Pool-Metadaten – Damit Pools geöffnet werden können und auf Datasets zugegriffen werden kann, muss ZFS eine Reihe spezieller Daten verarbeiten. Wenn diese Daten beschädigt sind, stehen der gesamte Pool bzw. ein Teil der Datasets nicht mehr zur Verfügung.

• Objektdaten – In diesem Fall sind Daten innerhalb einer bestimmten Datei bzw. eines Verzeichnisses beschädigt. Dieses Problem kann dazu führen, dass auf einen Teil dieser Datei bzw. dieses Verzeichnisses nicht mehr zugegriffen werden kann oder das betreffende Objekt in seiner Gesamtheit nicht mehr verfügbar ist.

Daten werden während des Normalbetriebs und der Datenbereinigung auf Integrität überprüft. Weitere Informationen zum Überprüfen der Integrität von Pool-Daten finden Sie unter Überprüfen der Integrität des ZFS-Dateisystems.

Ermitteln der Art der Datenbeschädigung

Der Befehl zpool status zeigt standardmäßig nur an, dass eine Datenbeschädigung aufgetreten ist, es ist jedoch nicht ersichtlich, wo sie sich ereignet hat. Beispiel:

# zpool status monkey
  pool: monkey
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:

        NAME        STATE     READ WRITE CKSUM
        monkey      ONLINE       8     0     0
          c1t1d0    ONLINE       2     0     0
          c2t5d0    ONLINE       6     0     0

errors: 8 data errors, use '-v' for a list

Ein Fehler zeigt lediglich an, dass zu einem bestimmten Zeitpunkt ein Fehler aufgetreten ist. Diese Fehler müssen nicht mehr notwendigerweise im System vorhanden sein. Unter normalen Bedingungen ist dies der Fall. Bestimmte zeitweilige Ausfälle können zu Datenbeschädigungen führen, die nach dem Ende des Ausfalls automatisch behoben werden. Bei einer vollständigen Bereinigung des Pools wird jeder aktive Datenblock im Pool untersucht, und das Fehlerprotokoll wird nach Abschluss der Bereinigung geleert. Wenn Sie sehen, dass die betreffenden Fehler im Pool nicht mehr auftreten und Sie nicht auf den Abschluss des Bereinigungsvorgangs warten möchten, können Sie alle Fehler im Pool mithilfe des Befehls zpool online löschen.

Wenn die Datenbeschädigung in Metadaten für den gesamten Pool aufgetreten ist, sieht die Befehlsausgabe etwas anders aus. Beispiel:

# zpool status -v morpheus
  pool: morpheus
    id: 1422736890544688191
 state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.
   see: http://www.sun.com/msg/ZFS-8000-72
config:

        morpheus    FAULTED   corrupted data
          c1t10d0   ONLINE

Ist ein Pool beschädigt, wird er in den Status FAULTED versetzt, da er nicht die erforderliche Datenredundanz gewährleisten kann.

Reparatur beschädigter Dateien bzw. Verzeichnisse

Ist eine Datei oder ein Verzeichnis beschädigt, kann es je nach Art der Datenbeschädigung sein, dass das System noch immer funktioniert. Schäden sind praktisch nicht wieder rückgängig zu machen, wenn im System keine brauchbaren Datenkopien vorhanden sind. Wenn die betreffenden Daten wertvoll sind, müssen Sie diese aus Sicherungskopien wiederherstellen. Auch in diesem Fall kann es sein, dass Sie nach dieser Datenbeschädigung den Normalbetrieb wiederherstellen können, ohne den gesamten Pool wiederherstellen zu müssen.

Wenn sich der Schaden innerhalb eines Dateidatenblocks befindet, kann die betreffende Datei sicher gelöscht werden, wodurch der Fehler aus dem System entfernt wird. Mit dem Befehl zpool status -v können Sie eine Liste von Dateinamen mit dauerhaften Fehlern ausgeben. Beispiel:

# zpool status -v
  pool: monkey
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:

        NAME        STATE     READ WRITE CKSUM
        monkey      ONLINE       8     0     0
          c1t1d0    ONLINE       2     0     0
          c2t5d0    ONLINE       6     0     0

errors: Permanent errors have been detected in the following files: 

/monkey/a.txt
/monkey/bananas/b.txt
/monkey/sub/dir/d.txt
monkey/ghost/e.txt
/monkey/ghost/boo/f.txt

Es folgen Erläuterung zur Liste von Dateinamen mit dauerhaften Fehlern:

• Wenn der vollständige Pfad zur Datei gefunden wurde und das Dataset eingehängt ist, wird der vollständige Pfad zur Datei angezeigt. Beispiel:

  /monkey/a.txt

• Wenn der vollständige Pfad zur Datei gefunden wurde, das Dataset jedoch nicht eingehängt ist, wird der Dataset-Name ohne vorangestellten Schrägstrich (/), gefolgt vom Pfad zur Datei innerhalb des Datasets angezeigt. Beispiel:

  monkey/ghost/e.txt

• Wenn die Objektnummer zu einem Dateipfad nicht erfolgreich konvertiert werden kann, weil ein Fehler auftrat oder dem Objekt kein realer Pfad zugewiesen ist (z. B. bei dnode_t), dann wird der Dataset-Name, gefolgt von der Objektnummer angezeigt. Beispiel:

  monkey/dnode:<0x0>

• Wenn ein Objekt im Metaobjekt-Set (MOS) beschädigt ist, wird ein spezielles Tag <metadata>, gefolgt von der Objektnummer, angezeigt.

Wenn Metadaten einer Datei bzw. eines Verzeichnisses beschädigt sind, kann die betreffende Datei nur an einen anderen Ort verschoben werden. Sie können Dateien bzw. Verzeichnisse sicher an eine unkritische Stelle kopieren, sodass das ursprüngliche Objekt am Ausgangsort wiederhergestellt werden kann.

Reparieren von Schäden am gesamten ZFS-Speicher-Pool

Wenn Pool-Metadaten beschädigt sind und der Pool dadurch nicht geöffnet oder importiert werden kann, stehen folgende Optionen zur Verfügung:

• Versuchen Sie, den Pool mithilfe des Befehls zpool clear - F oder zpool import -F wiederherzustellen. Mithilfe dieser Befehle wird versucht, die letzten Pool-Transaktionen zurückzusetzen, um den Pool wiederherzustellen. Sie können den Befehl zpool status verwenden, um einen beschädigten Pool und die empfohlenen Wiederherstellungsschritte anzuzeigen. Beispiel:

  # zpool status pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool clear -F tpool'. A scrub of the pool is strongly recommended after recovery. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tpool FAULTED 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4

  Für die oben beschriebene Wiederherstellung ist der folgende Befehl zu verwenden:

  # zpool clear -F tpool

  Wenn Sie versuchen, einen beschädigten Pool zu importieren, wird eine Meldung wie die folgende angezeigt:

  # zpool import tpool cannot import 'tpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F tpool'. A scrub of the pool is strongly recommended after recovery.

  Für die oben beschriebene Wiederherstellung ist der folgende Befehl zu verwenden:

  # zpool import -F tpool Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010. Discarded approximately 5 seconds of transactions

  Wenn der beschädigte Pool in der Datei zpool.cache enthalten ist, wird das Problem behoben, sobald das System neu gestartet wird, und die Beschädigung des Pools wird über den Befehl zpool status angezeigt. Wenn der Pool nicht in der Datei zpool.cache enthalten ist, kann er nicht importiert oder geöffnet werden, und es werden Meldungen angezeigt, die den beschädigten Pool betreffen, wenn Sie versuchen, den Pool zu öffnen.

• Wenn der Pool durch die oben beschriebene Wiederherstellung nicht wiederhergestellt werden kann, müssen Sie den Pool und alle seine Daten aus einer Sicherungskopie wiederherstellen. Das eingesetzte Verfahren hängt weitgehend von der Pool-Konfiguration und der Datensicherungsstrategie ab. Zuerst sollten Sie die mit dem Befehl zpool status angezeigte Konfiguration speichern, um diese nach dem Löschen des Pools wiederherstellen zu können. Löschen Sie den Pool dann mit dem Befehl zpool destroy -f. Legen Sie sich an sicherer Stelle eine Datei an, in der die Struktur der Datasets sowie die einzelnen lokal gesetzten Eigenschaften beschrieben sind, da diese Informationen nicht mehr zugänglich sind, wenn auf den Pool nicht mehr zugegriffen werden kann. Mithilfe der Pool-Konfiguration und der Dataset-Struktur können Sie nach dem Löschen des Pools die vollständige Konfiguration wiederherstellen. Danach können Sie mithilfe eines beliebigen Wiederherstellungsverfahrens den Pool wieder mit Daten „auffüllen“.

Reparieren eines Systems, das nicht hochgefahren werden kann

ZFS soll trotz möglicher Fehler robust und stabil sein. Dennoch können Softwarefehler oder bestimmte unerwartete Probleme zum Systemabsturz führen, wenn auf einen Pool zugegriffen wird. Jeder Pool muss im Rahmen des Systemstarts geöffnet werden, was bedeutet, dass Fehler beim Zugreifen auf einen Pool in eine Systemabsturz-Neustart-Schleife münden können. Als Ausweg aus einer solchen Situation muss ZFS mitgeteilt werden, Pools beim Systemstart zu ignorieren.

ZFS unterhält in /etc/zfs/zpool.cache einen internen Cache aktiver Pools und ihrer Konfiguration. Der Speicherort und der Inhalt dieser Datei sind nicht öffentlich zugänglich und Änderungen unterworfen. Wenn ein System nicht mehr hochgefahren werden kann, sollten Sie es mit der Meilenstein-Option none (-m milestone=none) booten. Nach dem Hochfahren des Systems hängen Sie das Root-Dateisystem ohne Schreibschutz ein. Anschließend benennen Sie die Datei /etc/zfs/zpool.cache um oder verschieben diese. Dadurch ?vergisst“ ZFS, dass im System Pools vorhanden sind und greift nicht auf den schadhaften Pool zu, der das Problem verursacht hat. Danach können Sie durch Absetzen des Befehls svcadm milestone all den normalen Systemzustand wiederherstellen. Beim Booten von einem alternativen Root-Verzeichnis zu Reparaturzwecken können Sie ein ähnliches Verfahren anwenden.

Wenn das System wieder läuft, können Sie versuchen, den Pool mithilfe des Befehls zpool import zu importieren. Dadurch tritt jedoch wahrscheinlich der gleiche Fehler wie beim Systemstart auf, da dieser Befehl zum Zugriff auf Pools das gleiche Verfahren verwendet. Wenn das System mehrere Pools besitzt, gehen Sie wie folgt vor:

• Benennen Sie die Datei zpool.cache um oder verschieben Sie sie in ein anderes Verzeichnis (siehe oben).

• Finden Sie heraus, bei welchem Pool Probleme auftreten, indem Sie sich mithilfe des Befehls fmdump -eV die Pools, für die kritische Fehler gemeldet wurden, anzeigen lassen.

• Importieren Sie die Pools nacheinander. Lassen Sie dabei die Pools aus, bei denen Probleme aufgetreten sind, die in der Ausgabe des Befehls fmdump angezeigt werden.