Contained WithinFind More DocumentationFeatured Support Resources |  Download this book in PDF (2012 KB)
第 11 章 ZFS のトラブルシューティングとデータの回復この章では、ZFS の障害モードをどのように識別し、そこから回復するかについて説明します。また、障害の発生を防ぐ方法についても説明します。 この章は、次の節で構成されます。 ZFS 障害モードZFS では、ファイルシステムとボリュームマネージャーが統合されているために、多くの異なる障害モードが存在します。この章では、さまざまな障害モードの概要を説明してから、実行しているシステムでそれらをどのように識別するかについて説明します。この章の最後では、問題を修復する方法について説明します。ZFS で発生する可能性のあるエラーには、次の 3 つのタイプがあります。 1 つのプールで 3 つのすべてのエラーが発生することもあります。このため、完全な修復作業を行うには、1 つのエラーを検出して訂正したら、次のエラーの対処に進む必要があります。 ZFS ストレージプール内でデバイスが見つからないデバイスがシステムから完全に削除されると、ZFS はそのデバイスを開けないことを検出し、UNAVAIL 状態にします。これが原因でプール全体が使用できない状態になるかどうかは、そのプールのデータ複製レベルによって決まります。ミラー化されたデバイスまたは RAID-Z デバイスにあるディスクが取り外されても、そのプールには引き続きアクセスできます。ミラーのすべてのコンポーネントが取り外された場合、RAID-Z デバイスから複数のデバイスが取り外された場合、または 1 つのディスクや最上位のデバイスが取り外された場合には、そのプールは FAULTED になります。そのデバイスを再度接続するまで、データにはアクセスできません。 ZFS ストレージプール内のデバイスが損傷している「損傷している」という用語には、発生する可能性のあるさまざまなエラーが含まれます。たとえば、次のようなエラーがあります。
これらのエラーは、ある場合には一時的に発生します。たとえば、コントローラに問題があるときは、入出力が無作為にエラーになります。また、ディスク上の破壊のように、損傷が永続することもあります。ただし、損傷が永続的だからといって、そのエラーが再度発生する可能性が高いことには必ずしもなりません。たとえば、管理者が誤ってディスクの一部を上書きしてしまった場合には、ハードウェア障害のようなことは発生していないので、そのデバイスを置き換える必要はありません。デバイスでどのような障害が発生しているのかを正確に判断するのは簡単なことではありません。詳細については、あとで説明します。 ZFS データが破壊しているデータの破壊が発生するのは、1 つ以上のデバイスエラー (デバイスが見つからないか、デバイスが損傷している) が最上位レベルの仮想デバイスに影響するときです。たとえば、データは破壊されていないけれども、一方のミラーに大量のデバイスエラーが発生する場合があります。もう一方のミラーの正確に同じ場所にエラーが発生した場合は、データが破壊されたことになります。 データの破壊は常に永続的であり、修復時は特に注意する必要があります。配下のデバイスを修復または置き換えても、元のデータは永久に失われています。このような状況では、ほとんどの場合、バックアップからデータを復元する必要があります。データエラーは発生するたびに記録されます。次の節で説明するように、定期的にディスクをスクラブすることでデータエラーを制御できます。破壊されたブロックを削除すると、次のスクラブ処理で破壊が存在しないことが認識され、すべてのエラー追跡がシステムから削除されます。 ZFS データの完全性をチェックするfsck に相当するユーティリティーは、ZFS には存在しません。このユーティリティーは従来、データの修復と検証という 2 つの目的のために使用されてきました。 データの修復従来のファイルシステムのデータ書き込み方法は、本質的に予期しない障害によってデータの不一致が発生しやすい性質を持っています。従来のファイルシステムはトランザクション方式ではないので、参照されないブロックや不正なリンクカウントなど、データ構造の矛盾が発生する可能性があります。ジャーナリングを導入することでこれらの問題のいくつかは解決されますが、ログをロールバックできないときには別の問題が発生する可能性があります。ZFS では、これらの問題は存在しません。データの不一致がディスク上で発生するとすれば、それはハードウェア障害が発生した場合か、ZFS ソフトウェアにバグが存在する場合だけです。ただし、ハードウェア障害の場合は、プールに冗長性があるはずです。 fsck ユーティリティーは各ファイルシステム固有の既知の問題を修復するために設計されているため、未知の問題が発生するファイルシステムのためにこのようなユーティリティーを作成することは不可能です。今後の実績により、あるデータ破壊の問題が一般的で単純なことが判明し、修復ユーティリティーを開発できるようになる可能性はありますが、これらの問題は冗長プールを使用すれば常に回避することができます。 プールに冗長性がない場合は、データの破壊によってデータの一部またはすべてにアクセスできなくなる可能性が常に存在します。 データの検証fsck ユーティリティーには、データを修復する以外に、ディスク上のデータに問題がないことを検証する機能があります。この作業は従来、ファイルシステムのマウントを解除し、fsck ユーティリティーを実行することで行います。処理中は、多くのシステムでシングルユーザーモードになります。このシナリオで発生するダウンタイムの長さは、チェックするファイルシステムのサイズに比例します。ZFS では、必要なチェックを実行するためのユーティリティーを明示的に使用する代わりに、すべてのデータを定期的にチェックする機構が用意されています。この機能は「スクラブ」と呼ばれ、メモリーやほかのシステム内で、ハードウェアまたはソフトウェア障害が発生する前にエラーを検出および回避する手段として一般的に使用されます。 ZFS データのスクラブを制御するスクラブを行なっているときまたは必要なファイルにアクセスしているときにエラーが発生した場合には、そのエラーが内部でログに記録されるので、そのプールで認識されているすべてのエラーの概要をすぐに確認できます。 ZFS データの明示的なスクラブデータの完全性をもっとも簡単にチェックする方法は、プールに含まれるすべてのデータのスクラブを明示的に開始することです。この処理では、プールに含まれるすべてのデータを 1 回たどってみて、すべてのブロックが読み取り可能であることを確認します。スクラブは、デバイスが実現できる最大速度で進行します。ただし、入出力が発生する場合には、その優先順位は通常の操作よりも低くなります。この操作によって、パフォーマンスが低下することがあります。ただし、スクラブの実行中でも、ファイルシステムはそのまま使用することができ、応答時間もほとんど変わらないはずです。明示的なスクラブを開始するには、zpool scrub コマンドを使用します。次に例を示します。
現在のスクラブの状態は、zpool status の出力に表示できます。次に例を示します。
ある時点で実行できるスクラブ操作は、各プールで 1 つだけです。 -s オプションを使用すれば、進行中のスクラブを中止できます。次に例を示します。
ほとんどの場合、データの完全性を保証するスクラブ操作は、完了するまで続けるようにしてください。スクラブ操作によってシステム性能に影響が出る場合は、ユーザー自身の判断でスクラブみを中止してください。 定期的にスクラブを実行すると、システム上のすべてのディスクへの継続的な入出力も保証されます。定期的なスクラブには、電源管理がアイドル状態のディスクを低電力モードにすることができなくなるという副作用があります。システムによる入出力がほとんど常に実行されている場合や、電力消費を気にする必要がない場合には、この問題は無視しても問題ありません。 zpool status の出力の解釈の詳細については、「ZFS ストレージプールの状態のクエリー検索を行う」を参照してください。 ZFS データのスクラブと再同期化デバイスを置き換えると、再同期化処理が開始されて、正常なコピーのデータが新しいデバイスに移動します。この処理は、ディスクのスクラブの一種です。このため、このような処理をプールで実行できるのは、その時点で 1 つだけです。スクラブ処理の実行中に再同期化を実行すると、進行中のスクラブは中断されて、再同期化の完了後に再開されます。 再同期化の詳細については、「再同期化の状態を表示する」を参照してください。 ZFS の問題を識別するここでは、ZFS ファイルシステムまたはストレージプールで発生する問題を識別する方法について説明します。 次の機能を使用して、ZFS 構成で発生した問題を識別することができます。
ZFS に関するほとんどのトラブルシューティングでは、zpool status コマンドが重要な役割を果たします。このコマンドを実行すると、システム上のさまざまな障害が分析され、もっとも重大な問題が識別されます。さらに、推奨する処置と、詳細情報が掲載されたナレッジ記事へのリンクが提示されます。プールで複数の問題が発生している可能性がある場合でも、このコマンドで識別できる問題は 1 つだけです。たとえば、データ破壊エラーについては、常に 1 つのデバイスに障害が発生していることしか報告されません。障害の発生したデバイスを置き換えても、データ破壊の問題は修正されません。 また、ZFS 診断エンジンでは、プールとデバイスの障害が診断されて報告されます。プールまたはデバイスの障害に関連するチェックサム、入出力、デバイス、およびプールのエラーも報告されます。fmd で報告される ZFS 障害は、コンソールとシステムメッセージファイルに表示されます。ほとんどの fmd メッセージで、zpool status コマンドを実行して詳細な回復の手順を確認することを求めています。 基本的な回復方法は次のとおりです。
この章では、障害の種類を診断するために、zpool status の出力をどのように解釈するかについて説明します。また、特定の問題を修復する方法について、あとに続く節のどこを参照すればよいかを示します。ほとんどの作業はコマンドによって自動的に実行されますが、障害の種類を診断するうえで、どのような問題が識別されるかを正確に理解しておくことは重要です。 ZFS ストレージプールに問題があるかどうかを確認するシステムになんらかの既知の問題が存在するかどうかを確認するもっとも簡単な方法は、zpool status -x コマンドを使用することです。このコマンドでは、問題が発生しているプールの説明だけが出力されます。システムに不良なプールが存在しない場合、このコマンドは次のような簡潔なメッセージを表示します。
-x フラグを指定しないでこのコマンドを実行した場合は、すべてのプールが健全である場合でも、すべてのプール (コマンド行で特定のプールを指定した場合は、要求したプール) のすべての状態が表示されます。 zpool status コマンドのコマンド行オプションの詳細については、「ZFS ストレージプールの状態のクエリー検索を行う」を参照してください。 zpool status の出力を確認するzpool status の完全な出力は次のようになります。
この出力は、いくつかのセクションに分かれています。 プールの全般的な状態情報zpool status 出力のこのヘッダーセクションは、次のフィールドで構成されます。一部の項目は、プールに問題がある場合にのみ表示されます。
プール構成情報zpool status 出力の config フィールドには、プールを構成するデバイスの構成レイアウト、デバイスの状態、およびデバイスから生成されたエラーが出力されます。次のいずれかの状態になる可能性があります。 ONLINE、FAULTED、DEGRADED、UNAVAILABLE、OFFLINE です。ONLINE 以外のいずれかの状態の場合は、プールの耐障害性が危殆化しています。 構成出力の 2 番目のセクションには、エラー統計が表示されます。これらのエラーは、3 つのカテゴリに分けられます。
これらのエラーを使って、損傷が永続的かどうかを判断できます。入出力エラーが少数の場合は、機能が一時的に停止している可能性があります。入出力エラーが大量の場合は、デバイスに永続的な問題が発生している可能性があります。これらのエラーは、アプリケーションによって解釈されるデータ破壊に対応していないことがあります。デバイスが冗長構成になっている場合は、ディスクデバイスの訂正できないエラーが表示されることがあります。ただし、ミラーまたは RAID-Z デバイスレベルではエラーは表示されません。このような場合には、ZFS では正常なデータを正常に取得してから、既存の複製を使って損傷したデータの修復を試みます。 これらのエラーを解釈してデバイス障害を確認する方法の詳細については、「デバイス障害の種類を確認する」を参照してください。 さらに、zpool status 出力の最終列には、補足情報が表示されます。この情報は、state フィールドの情報を補足するもので、障害モードの診断に役立ちます。デバイスが FAULTED の場合は、このフィールドにはデバイスがアクセスできない状態かどうか、またはデバイス上のデータが破壊されているかどうかが表示されます。デバイスで再同期化が実行されている場合、このフィールドには現在の進行状況が表示されます。 再同期化の進行状況を監視する方法の詳細については、「再同期化の状態を表示する」を参照してください。 スクラブの状態zpool status 出力の 3 番目のセクションには、明示的なすべてのスクラブの現在の状態が説明されます。この情報は、システム上でなんらかのエラーが検出されているかどうかを示すものではありません。ただし、この情報を使って、データ破壊エラーの報告が正確かどうかを判断できます。前回のスクラブが最近実行されている場合には、既知のデータ破壊が発生していれば、高い確率でそのとき検出されている可能性があります。 データスクラブおよびこの情報の解釈方法の詳細については、「ZFS データの完全性をチェックする」を参照してください。 データ破壊エラーzpool status コマンドでは、既知のエラーが発生している場合に、それらがプールに関連するものであるかどうかも出力されます。これらのエラーは、ディスクのスクラブ中または通常の操作中に検出されている可能性があります。ZFS では、プールに関連するすべてのデータエラーの持続的なログを管理しています。システムの完全なスクラブが終了するたびに、このログのローテーションが行われます。 データ破壊エラーは、常に致命的です。このエラーが発生している場合は、プールのデータが破壊されたために、1 つ以上のアプリケーションで入出力エラーが発生したことになります。冗長なプール内でデバイスエラーが発生してもデータは破壊されないので、このログの一部として記録されません。デフォルトでは、検出されたエラーの数だけが表示されます。エラーおよびその詳細の完全なリストは、zpool status -v オプションを使用すれば表示できます。次に例を示します。
同様のメッセージは、システムコンソールで fmd を実行した場合にも、また /var/adm/messages ファイルにも表示されます。fmdump コマンドを使って、これらのメッセージを追跡することもできます。 データ破壊エラーの解釈の詳細については、「データ破壊の種類を確認する」を参照してください。 ZFS エラーメッセージのシステムレポートZFS では、プール内のエラーを継続的に追跡するだけでなく、そのようなイベントが発生したときに syslog メッセージを表示することもできます。次のような場合に、イベントを生成して管理者に通知します。
ZFS がデバイスエラーを検出してそれを自動的に回復した場合には、通知は行われません。このようなエラーでは、プールの冗長性またはデータの完全性の障害は発生しません。また、このようなエラーは通常、ドライバの問題が原因で発生しており、ドライバ自身のエラーメッセージも出力されます。 損傷した ZFS 構成を修復するZFS では、アクティブなプールとその構成のキャッシュをルートファイルシステム上で管理しています。このファイルが破壊された場合、またはこのファイルがなんらかの形でディスクに保管されている内容と同期しなくなった場合には、そのプールを開くことができなくなります。ZFS ではこのような状況を回避しようとしますが、配下のファイルシステムとストレージの特性から、なんらかの破壊は常に発生する可能性があります。こうした状況になると、ほかの方法で使用できるとしても、通常はプールがシステムに表示されなくなります。また、この状況から構成が不完全であること、つまり、最上位レベルの仮想デバイスが見つからない (その数は不明) ことがわかる場合もあります。どちらの場合でも、なんらかの方法でプールを見ることができる場合には、プールをエクスポートして再度インポートする方法で、構成を回復することができます。 プールのインポートとエクスポートの詳細については、「ZFS ストレージプールを移行する」を参照してください。 見つからないデバイスに関する問題を解決するデバイスを開けない場合には、zpool status の出力に UNAVAILABLE と表示されます。この状態は、プールにはじめてアクセスしたときにデバイスを開けなかったか、またはそのデバイスがそれ以降使用できない状態であることを示しています。このデバイスが原因で、最上位レベルの仮想デバイスが使用できない場合、そのプールの内容にはアクセスできません。または、プールの耐障害性が危殆化している可能性があります。どちらの場合でも、通常の動作に戻すために必要な操作は、そのデバイスをシステムに再接続することだけです。 たとえば、デバイス障害が発生したあとに、 fmd から次のようなメッセージが表示される場合があります。
このような場合の次の手順は、zpool status -x コマンドを使って、デバイスの問題とその解決策に関する詳細な情報を表示することです。 この出力から、見つからないデバイス c1t1d0 が機能していないことを確認できます。このデバイスに障害が発生していることを確認できたら、デバイスを置き換えます。 次に、zpool online コマンドを使用して、置き換えたデバイスをオンラインにします。次に例を示します。
デバイスを置き換えたプールが正常に動作していることを確認します。
デバイスを物理的に再接続する見つからないデバイスを再接続するための正確な手順は、そのデバイスごとに異なります。デバイスがネットワークに接続されているドライブの場合は、接続を復元するべきです。デバイスが USB などのリムーバブルメディアである場合は、システムに再接続するべきです。デバイスがローカルディスクである場合は、コントローラに障害が発生していたために、デバイスがシステムから見えない状態になっていた可能性があります。この場合は、コントローラを置き換えれば、ディスクが再び使用できる状態になるはずです。ハードウェアの種類と構成によっては、ほかの問題が存在する可能性もあります。あまり起こらないことですが、ドライブに障害が発生してシステムから認識されなくなった場合には、デバイスが損傷していると見なすべきです。「破損したデバイスを交換または修復する」で説明している手順に従ってください。 デバイスが使用できることを ZFS に通知するデバイスをシステムに再接続しても、デバイスが使用できるようになったことが自動的に検出されないこともあります。プールでそれまで障害が発生した場合、または接続手続きの一部としてシステムが再起動された場合には、プールを開こうとするときにすべてのデバイスが自動的に再スキャンされます。システムの稼働中にプールの機能が低下したのでデバイスを置き換えた場合には、デバイスが使用できるようになって再度開ける状態になったことを、zpool online コマンドを使って ZFS に通知する必要があります。次に例を示します。
デバイスをオンラインする方法の詳細については、「デバイスをオンラインにする」を参照してください。 破損したデバイスを交換または修復するこの節では、デバイスの障害の種類の確認し、一時的なエラーを消去し、およびデバイスを置き換える方法について説明します。 デバイス障害の種類を確認する「損傷したデバイス」という用語は定義があいまいですが、発生する可能性のあるいくつかの状況はこの用語で説明できます。
どこに問題があるかを正確に判断することは、難しい作業です。最初に行うことは、次のように zpool status 出力のエラー数を調べることです。
エラーは、入出力エラーとチェックサムエラーに分かれます。どちらのエラーも、発生している可能性のある障害の種類を示している可能性があります。通常の処理で発生するエラーの数は、少ない (長い時間にほんの数個) と予測されます。大量のエラーが表示される場合、この状況はデバイス障害がすぐに発生する可能性または完全なデバイス障害が発生する可能性を示しています。ただし、重大な管理者エラーが原因で、大量のエラーが発生している可能性もあります。別の情報源は、システムログです。このログに大量の SCSI ドライバまたはファイバチャネルドライバのメッセージが記録される場合、この状況は重大なハードウェアの問題が発生している可能性を示しています。syslog メッセージが生成されない場合、損傷は一時的であると思われます。 最後の手順は次の質問に答えることです。 このデバイスでもう一度エラーが発生する可能性がありますか。 一度だけ発生するエラーは「一時的」と考えられ、潜在的な障害を示していません。ハードウェア障害の可能性がある持続的または重大なエラーは、「致命的」と考えられます。エラーの種類を特定する作業は、ZFS で現在利用できる自動化ソフトウェアの範囲を超えているため、管理者自身が手動で行う必要があります。エラーの種類を特定したら、それに対応する処置を採ることができます。一時的なエラーを解消したり、致命的なエラーが起こっているデバイスを置き換えたります。これらの修復手順については、次の節で説明します。 一時的であると考えられるデバイスエラーでも、それがプール内のデータの訂正不可能なエラーを発生させていることがあります。このようなエラーについては、配下のデバイスが健全であると判断されている場合、または別の機会に修復されている場合でも、特別な修復手順が必要になります。データエラーの修復の詳細については、「損傷したデータを修復する」を参照してください。 一時的なエラーを解消するデバイスエラーが一時的と考えられる場合、つまりデバイスの今後の健全性に影響しないと考えられる場合は、デバイスエラーを安全に解消することで、致命的なエラーが発生していないことを指定することができます。RAID-Z デバイスまたはミラーデバイスのエラー数を消去するには、zpool clear コマンドを使用します。次に例を示します。
この構文を実行すると、デバイスに関連付けられているすべてのエラーおよびすべてのデータエラー数が消去されます。 プール内の仮想デバイスに関連付けられているすべてのエラーが消去し、プールに関連付けられているすべてのデータエラー数を消去するには、次の構文を使用します。
プールエラーの消去の詳細については、「ストレージプールのデバイスをクリアーする」を参照してください。 ZFS ストレージプール内のデバイスを置き換えるデバイスの損傷が永続的である場合、または永続的な損傷が今後発生する可能性がある場合には、そのデバイスを置き換える必要があります。デバイスを置き換えられるかどうかは、構成によって異なります。 デバイスを置き換えられるかどうかを確認するデバイスを置き換えるには、プールが ONLINE 状態である必要があります。デバイスは冗長構成の一部であるか、健全 (ONLINE 状態) である必要があります。ディスクが冗長構成の一部である場合は、正常なデータを取得するための十分な複製が存在している必要があります。4 方向ミラーの 2 台のディスク に障害が発生している場合は、健全な複製を入手できるので、どちらのディスクも置き換えることができます。ただし、4 方向 RAID-Z デバイス内の 2 つのディスクで障害が発生した場合は、データを入手するために必要な複製がないため、どちらのディスクも置き換えることができません。デバイスが損傷していてもオンラインである場合には、プールの状態が FAULTED でない限り、デバイスを置き換えることができます。ただし、正常なデータが格納されている複製が必要な数だけ存在しない場合、そのデバイス上に不正なデータがある場合には、それらが新しいデバイスにコピーされます。 次の構成のディスク c1t1d0 は置き換えることができます。プール内のすべてのデータは正常な複製 c1t0d0 からコピーされます。
ディスク c1t0d0 も置き換えることがですが、正常な複製を入手できないため、データの自己修復は行われません。 次の構成で障害の発生したディスクは、どちらも置き換えることができません。プール自体に障害が発生しているため、ONLINE 状態のディスクも置き換えることができません。
次の構成の最上位レベルのディスクは、どちらも置き換えることができます。ただし、ディスクに不正なデータが存在する場合は、それらが新しいディスクにコピーされます。
どちらかのディスクで障害が発生した場合は、プール自体に障害が発生したことになるため、置き換えを行うことはできません。 置き換えることができないデバイスデバイスが失われたためにプールが障害状態になった場合、または非冗長な構成でデバイスに大量のデータエラーが含まれている場合は、そのデバイスを安全に置き換えることはできません。十分な冗長性がない場合、損傷したデバイスの修復に使用する正常なデータは存在しません。このような場合に選択できる方法は、プールを破棄して構成を再作成し、そのときにデータを復元することです。 プール全体を復元する方法の詳細については、「ZFS ストレージプール全体の損傷を修復する」を参照してください。 ZFS ストレージプール内のデバイスを置き換える置き換えられるデバイスであることを確認したら、zpool replace コマンドを使ってデバイスを置き換えます。損傷したデバイスを別のデバイスに置き換える場合は、次のコマンドを使用します。
このコマンドを実行すると、損傷したデバイスまたはプール内のほかのデバイス (冗長な構成の場合) から新しいデバイスへのデータの移行が開始されます。コマンドが完了すると、損傷したデバイスが構成から切り離され、そのデバイスをシステムから取り外せる状態になります。1 つの場所ですでにデバイスを取り外して新しいデバイスに置き換えている場合には、1 つのデバイス形式のコマンドを使用します。次に例を示します。
このコマンドにフォーマットされていないディスクを指定すると、そのディスクが適切な状態にフォーマットされてから、残りの構成からデータの再同期化が開始されます。 zpool replace コマンドの詳細については、「ストレージプール内のデバイスを置き換える」を参照してください。 例 11–1 ZFS ストレージプール内のデバイスを置き換える次の例では、Sun Fire x4500 システムのミラー化ストレージプール tank のデバイス (c1t3d0) を置き換える方法を示します。ディスク c1t3d0 を同じ位置で新しいディスク (c1t3d0) に置き換える場合は、ディスクを置き換える前に構成解除する必要があります。基本的な手順は次のとおりです。
上記の zpool の出力で、新しいディスクと古いディスクの両方が replacing 見出しの下に表示される場合があります。次に例を示します。
このテキストは、置き換え処理および新しいディスクの再同期化が進行中であることを示しています。 ディスク (c1t3d0) を別のディスク (c4t3d0) で置き換える場合は、ディスクを物理的に交換したあとで zpool replace コマンドを実行する必要があります。次に例を示します。
ディスクの置き換えが完了するまでに zpool status コマンドを数回実行する必要がある場合があります。
例 11–2 障害が発生したログデバイスを交換する次の例では、ストレージプール pool で障害が発生したログデバイス c0t5d0 を回復する方法を示します。基本的な手順は次のとおりです。
再同期化の状態を表示するドライブを置き換えるときには、ドライブのサイズとプールに含まれるデータの量によっては、かなり長い時間がかかることがあります。あるデバイスのデータを別のデバイスに移動する処理は、「再同期化」と呼ばれ、zpool status コマンドを使って監視できます。 従来のファイルシステムでは、ブロックレベルでデータが再同期化されます。ZFS では、ボリュームマネージャーの論理階層がなくなり、より強力な制御された方法で再同期化できます。この機能の主な利点として、次の 2 点を挙げることができます。
再同期化処理を表示するには、zpool status コマンドを使用します。次に例を示します。
この例では、ディスク c1t0d0 が c2t0d0 に置き換わります。状態が replacing の仮想デバイスが構成に存在しているので、このイベントは状態出力で監視されます。このデバイスは実際のデバイスではありません。この種類の仮想デバイスを使ってプールを作成することもできません。このデバイスは、再同期化処理を表示し、置き換え中のデバイスを正確に識別するためだけに使用されます。 再同期化が現在進行しているプールの状態は、すべて ONLINE または DEGRADED 状態になります。これは、再同期化処理が完了するまで、必要とする冗長レベルをそのプールで提供できないためです。システムへの影響を最小限に抑えるために、再同期化は最大限の速度で処理されます。ただし、その入出力の優先順位は、ユーザーが要求した入出力より常に低く設定されます。再同期化が完了すると、新しい完全な構成に戻ります。次に例を示します。
プールは、ONLINE に戻り、元の不正なディスク (c1t0d0) は構成から削除されています。 損傷したデータを修復するここでは、データ破壊の種類を確認する方法と、破壊したデータを修復する (可能な場合) 方法について説明します。 ZFS では、データ破壊の可能性を最小限に抑えるために、チェックサム、冗長性、および自己修復データが使用されます。それでも、プールが冗長でない場合、プールの機能が低下しているときに破壊が発生した場合、または予期しないことが一度に起こってデータの複数のコピーが破壊された場合は、データの破壊が発生することがあります。どのような原因であったとしても、結果は同じです。 データが破壊され、その結果アクセスできなくなっています。対処方法は、破壊されたデータの種類とそれに関連する値により異なります。破壊されるデータは、大きく 2 つの種類に分けられます。
データの検証は、通常の操作中およびスクラブ時に行われます。プールデータの完全性を検証する方法の詳細については、「ZFS データの完全性をチェックする」を参照してください。 データ破壊の種類を確認するデフォルトでは、zpool status コマンドでは、破壊が発生したことだけが報告され、破壊が発生した場所は報告されません。次に例を示します。
特定の時刻にエラーが発生したことだけが、エラーごとに報告されます。各エラーが現在もシステムに存在するとは限りません。通常の環境では、このようになっています。なんらかの一時的な機能低下によって、データが破壊されることがあります。それらは、機能低下が終了した時点で自動的に修復されます。プール内のすべてのアクティブなブロックを検査するために、プールのスクラブは完全に実行されることが保証されています。このため、スクラブが完了するたびに、エラーログがリセットされます。エラーが存在しないことを確認したので、スクラブが完了するのを待っている必要がない場合には、zpool online コマンドを使ってプール内のすべてのエラーをリセットします。 データ破壊がプール全体のメタデータで発生している場合は、出力が少し異なります。次に例を示します。
プール全体が破壊された場合は、プールが必要な冗長レベルを提供できないため、プールは FAULTED 状態になります。 破壊されたファイルまたはディレクトリを修復するファイルまたはディレクトリが破壊されても、破壊の種類によってはシステムをそのまま使用できる場合があります。損傷が発生している場合、データの正常なコピーがシステムのどこにも存在しなければ、事実上それらは修復できません。重要なデータの場合には、バックアップからデータを復元する以外の選択肢はありません。このような場合でも、プール全体を復元しなくても破壊から回復できる場合があります。 ファイルデータブロックの中で損傷が発生した場合は、ファイルを安全に削除することができるため、システムのエラーを解消できます。永続的なエラーが発生しているファイル名のリストを表示するには、zpool status -v コマンドを使用します。次に例を示します。
上記の出力についての説明を次に示します。
ディレクトリまたはファイルのメタデータの中で破壊は発生している場合には、そのファイルを別の場所に移動するしかありません。任意のファイルまたはディレクトリを不便な場所に安全に移動することができ、そこで元のオブジェクトを復元することができます。 ZFS ストレージプール全体の損傷を修復するプールメタデータで損傷が発生していて、プールを開くことができない場合は、プールとそのすべてのデータをバックアップから復元する必要があります。そのために使用する方法は、プールの構成とバックアップ方法によって大きく異なります。最初に、zpool status を使用して表示された構成を保存し、プールを破棄したときに構成を再作成できるようにします。次に、zpool destroy -f を使用してプールを破棄します。また、データセットのレイアウトやローカルに設定されたさまざまなプロパティーが記述されているファイルを別の安全な場所に保存します。これは、プールがアクセスできない状態になった場合に、これらの情報にアクセスできなくなるためです。プールを破棄したあとに、プールの構成とデータセットのレイアウトを使用して、完全な構成を再構築できます。次に、なんらかのバックアップまたは採用している復元方法を使って、データを生成することができます。 起動できないシステムを修復するZFS は、エラーが発生した場合でも、堅牢で安定した状態であるように設計されています。それでも、ソフトウェアのバグや予期しない異常な操作のために、プールにアクセスするときにシステムでパニックが発生することがあります。各プールは起動処理のときに開く必要があるので、このような障害が発生すると、システムがパニックと再起動のループに入ってしまうことになります。この状況から回復するには、起動時にどのプールも探さないように ZFS を設定する必要があります。 ZFS では、利用できるプールとその構成の内部キャッシュを /etc/zfs/zpool.cache で管理しています。このファイルの場所と内容は非公開で、変更される可能性があります。システムを起動できなくなった場合は、-m milestone=none 起動オプションを使用して、none マイルストーンで起動します。システムが起動したら、ルートファイルシステムを書き込み可能として再マウントしてから、/etc/zfs/zpool.cache ファイルの名前を変更するかこのファイルを別の場所に移動します。これらの操作によって、システムに存在するすべてのプールがキャッシュから消去されるので、問題の原因となっている不正なプールにアクセスしようとしなくなります。この状態になったら、svcadm milestone all コマンドを実行して、通常のシステムの状態に戻ることができます。代替ルートから起動して修復を行う場合にも、同じような工程を使用できます。 システムが起動したら、zpool import コマンドを使ってプールをインポートしてみることができます。ただし、このコマンドを実行すると、起動で発生したエラーと同じエラーが発生する可能性があります。これは、プールにアクセスするときに起動時と同じ方法が使用されているためです。複数のプールがシステムに存在する場合は、次の手順を実行します。
|
|||||||||||||||||||||||||||||||||
|