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:
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:
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.
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
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.
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.
Für ZFS gibt es kein Dienstprogramm wie fsck. Dieses Dienstprogramm diente üblicherweise zur Reparatur und Validierung 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.
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.
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.
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.
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.
In den folgenden Abschnitten wird beschrieben, wie Sie Probleme mit ZFS-Dateisystem oder Speicher-Pools erkennen und beheben können:
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.
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.
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:
Dieser Abschnitt der Ausgabe des Befehls zpool status enthält die folgenden Felder (einige dieser Felder werden nur angezeigt, wenn im Pool Probleme auftreten):
Gibt den Namen des Pools an.
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.
Beschreibt, was mit dem Pool nicht in Ordnung ist. Dieses Feld wird nicht angezeigt, wenn keine Fehler gefunden wurden.
Eine empfohlene Aktion zur Fehlerbehebung. Dieses Feld wird nicht angezeigt, wenn keine Fehler gefunden wurden.
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.
Zeigt den aktuellen Status einer Bereinigung an (Datum und Uhrzeit der letzten Bereinigung, Informationen zu einer laufenden Bereinigung, Informationen zur Anforderung von Bereinigungen).
Zeigt bekannte bzw. unbekannte Datenfehler an.
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.
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.
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.
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.
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.
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 |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
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:
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 |
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.
In den folgenden Abschnitten wird beschrieben, wie Sie den Typ der Datenbeschädigung ermitteln und (falls möglich) Daten reparieren können.
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.
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.
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.
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“.
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.