| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris ZFS 管理ガイド Oracle Solaris 10 1/13 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris ZFS 管理ガイド Oracle Solaris 10 1/13 Information Library (日本語) |
1. Oracle Solaris ZFS ファイルシステム (概要)
3. Oracle Solaris ZFS ストレージプールの管理
4. Oracle Solaris ZFS ルートファイルシステムのインストールとブート
5. Oracle Solaris ZFS ファイルシステムの管理
6. Oracle Solaris ZFS のスナップショットとクローンの操作
7. ACL および属性を使用した Oracle Solaris ZFS ファイルの保護
9. Oracle Solaris ZFS の高度なトピック
10. Oracle Solaris ZFS のトラブルシューティングとプールの回復
11. 推奨の Oracle Solaris ZFS プラクティス
ディスクまたはコントローラが不良であるために、一時的な入出力エラーが発生する
宇宙線が原因で、ディスク上のデータが破壊される
ドライバのバグが原因で、間違った場所からデータが転送されたり、間違った場所にデータが転送されたりする
ユーザーが誤って物理デバイスの一部を上書きしてしまう
これらのエラーは、ある場合には一時的に発生します。たとえば、コントローラに問題があるときは、入出力が無作為にエラーになります。また、ディスク上の破壊のように、損傷が永続することもあります。ただし、損傷が永続的だからといって、そのエラーが再度発生する可能性が高いことには必ずしもなりません。たとえば、誤ってディスクの一部を上書きしてしまった場合には、ハードウェア障害のようなことは発生していないので、そのデバイスを置き換える必要はありません。デバイスの問題を正確に識別するのは簡単なことではありません。詳細については、あとのセクションで説明します。
fsck に相当するユーティリティーは、ZFS には存在しません。このユーティリティーは従来から、ファイルシステムの修復と検証という 2 つの目的に利用されてきました。
従来のファイルシステムのデータ書き込み方法は、本質的に予期しない障害によってファイルシステムの不一致が発生しやすい性質を持っています。従来のファイルシステムはトランザクション方式ではないので、参照されないブロックや不正なリンクカウントなど、ファイルシステム構造の矛盾が発生する可能性があります。ジャーナリングを導入することでこれらの問題のいくつかは解決されますが、ログをロールバックできないときには別の問題が発生する可能性があります。データの不一致が ZFS 構成内のディスク上で発生するとすれば、それはハードウェア障害が発生した場合か、ZFS ソフトウェアにバグが存在する場合だけです。ただし、ハードウェア障害の場合は、プールに冗長性があるはずです。
fsck ユーティリティーは、UFS ファイルシステムに固有の既知の問題を修復します。ZFS ストレージプールの問題の大半は一般に、ハードウェアまたは電源の障害に関連しています。冗長プールを利用することで、多くの問題を回避できます。ハードウェアの障害または電源の停止が原因でプールが損傷している場合は、「ZFS ストレージプール全体の損傷を修復する」を参照してください。
プールに冗長性がない場合は、ファイルシステムの破壊によってデータの一部またはすべてにアクセスできなくなるリスクが常に存在します。
fsck ユーティリティーには、ファイルシステムの修復を実行する以外に、ディスク上のデータに問題がないことを検証する機能があります。このタスクでは従来から、ファイルシステムをアンマウントし、fsck ユーティリティーを実行する必要があります。処理中は、多くのシステムでシングルユーザーモードになります。このシナリオで発生するダウンタイムの長さは、チェックするファイルシステムのサイズに比例します。ZFS では、必要なチェックを実行するためのユーティリティーを明示的に使用する代わりに、すべての不一致を定期的にチェックするメカニズムが用意されています。この機能は「スクラブ」と呼ばれ、メモリーやほかのシステム内で、ハードウェアまたはソフトウェア障害が発生する前にエラーを検出および回避する手段として一般的に使用されます。
スクラブを行なっているときまたは必要なファイルにアクセスしているときにエラーが発生した場合には、そのエラーが内部でログに記録されるので、そのプールで認識されているすべてのエラーの概要をすぐに確認できます。
データの完全性をもっとも簡単にチェックする方法は、プールに含まれるすべてのデータのスクラブを明示的に開始することです。この処理では、プールに含まれるすべてのデータを 1 回たどってみて、すべてのブロックが読み取り可能であることを確認します。スクラブは、デバイスが実現できる最大速度で進行します。ただし、入出力が発生する場合には、その優先順位は通常の操作よりも低くなります。この操作によって、パフォーマンスが低下することがあります。ただし、スクラブの実行中でも、プールのデータはそのまま使用することができ、応答時間もほとんど変わらないはずです。明示的なスクラブを開始するには、zpool scrub コマンドを使用します。次に例を示します。
# zpool scrub tank
現在のスクラブ操作のステータスは、zpool status コマンドを使用して表示できます。例:
# 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
一度に実行できるスクラブ操作は、各プールで 1 つだけです。
-s オプションを使用すれば、進行中のスクラブ操作を中止できます。例:
# zpool scrub -s tank
ほとんどの場合、データの完全性を保証するスクラブ操作は、完了するまで続けるようにしてください。操作によってシステム性能に影響が出る場合は、ユーザー自身の判断でスクラブ操作を中止してください。
定期的にスクラブを実行すると、システム上のすべてのディスクへの継続的な入出力が保証されます。定期的なスクラブには、電源管理がアイドル状態のディスクを低電力モードにすることができなくなるという副作用があります。システムによる入出力がほとんど常に実行されている場合や、電力消費を気にする必要がない場合には、この問題は無視しても問題ありません。
zpool status の出力の解釈の詳細については、「ZFS ストレージプールのステータスのクエリー検索を行う」を参照してください。
デバイスを置き換えると、再同期化処理が開始されて、正常なコピーのデータが新しいデバイスに移動します。この処理は、ディスクのスクラブの一種です。このため、このような処理をプールで実行できるのは、その時点で 1 つだけです。スクラブ操作の実行中に再同期化を実行すると、現在のスクラブは中断され、再同期化の完了後に再開されます。
再同期化の詳細については、「再同期化のステータスを表示する」を参照してください。
データの破壊が発生するのは、1 つ以上のデバイスエラー (1 つ以上のデバイスが見つからないか、損傷している) が最上位レベルの仮想デバイスに影響するときです。たとえば、データは破壊されていないけれども、一方のミラーに大量のデバイスエラーが発生する場合があります。もう一方のミラーの正確に同じ場所にエラーが発生した場合は、データが破壊されたことになります。
データの破壊は常に永続的であり、修復時は特に注意する必要があります。配下のデバイスを修復または置き換えても、元のデータは永久に失われています。このような状況では、ほとんどの場合、バックアップからデータを復元する必要があります。データエラーは発生するたびに記録されます。次のセクションで説明するように、定期的にプールをスクラブすることでデータエラーを制御できます。破壊されたブロックを削除すると、次のスクラブ処理で破壊が存在しないことが認識され、すべてのエラー追跡がシステムから削除されます。
ZFS がファイルシステム領域とプール領域の計上をどのように報告するかわからない場合は、次のセクションを確認してください。「ZFS のディスク領域の計上」も確認してください。
利用可能なプールおよびファイルシステムの領域を判別する場合、zpool list および zfs list コマンドは、以前の df および du コマンドより優れています。旧バージョンのコマンドでは、プールおよびファイルシステムの領域を簡単に識別できず、下位のファイルシステムまたはスナップショットによって消費される領域の詳細を表示できません。
たとえば、次のルートプール (rpool) は、5.46GB が割り当て済みで、68.5GB は空き領域です。
# zpool list rpool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 74G 5.46G 68.5G 7% 1.00x ONLINE -
個々のファイルシステムの USED 列を確認することでプール領域の数値とファイルシステム領域の数値を比較すれば、ALLOC で報告されるプール領域はファイルシステムの USED の合計であることがわかります。例:
# zfs list -r rpool NAME USED AVAIL REFER MOUNTPOINT rpool 5.41G 67.4G 74.5K /rpool rpool/ROOT 3.37G 67.4G 31K legacy rpool/ROOT/solaris 3.37G 67.4G 3.07G / rpool/ROOT/solaris/var 302M 67.4G 214M /var rpool/dump 1.01G 67.5G 1000M - rpool/export 97.5K 67.4G 32K /rpool/export rpool/export/home 65.5K 67.4G 32K /rpool/export/home rpool/export/home/admin 33.5K 67.4G 33.5K /rpool/export/home/admin rpool/swap 1.03G 67.5G 1.00G -
zpool list コマンドによって報告される SIZE 値は、通常、プール内の物理ディスク領域の大きさですが、プールの冗長性レベルに応じて異なります。次の例を参照してください。zfs list コマンドは、使用可能な領域のうち、ファイルシステムで利用できる領域を示します。これは、ディスク領域から ZFS プール冗長性メタデータオーバーヘッド (ある場合) を差し引いたものです。
非冗長性ストレージプール – 136G バイトのディスク 1 つでプールを作成すると、zpool list コマンドによって SIZE および初期 FREE 値が 136G バイトとして報告されます。zfs list コマンドによって報告された初期 AVAIL 領域は、プールメタデータオーバーヘッドが少量あるため 134G バイトです。例:
# zpool create tank c0t6d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 72K 134G 21K /tank
ミラー化ストレージプール – 136G バイトのディスク 2 つでプールを作成すると、zpool list コマンドによって SIZE が 136G バイト、初期 FREE 値が 136G バイトとして報告されます。この報告は、デフレートされた領域値と呼ばれます。zfs list コマンドによって報告された初期 AVAIL 領域は、プールメタデータオーバーヘッドが少量あるため 134G バイトです。例:
# zpool create tank mirror c0t6d0 c0t7d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 72K 134G 21K /tank
RAID-Z ストレージプール – 136G バイトのディスク 3 つで raidz2 プールを作成すると、zpool list コマンドによって SIZE および初期 FREE 値が 408G バイトとして報告されます。この報告は、インフレートされたディスク領域値と呼ばれます。パリティー情報などの冗長性オーバーヘッドが含まれています。zfs list コマンドによって報告される初期 AVAIL 領域は、プール冗長性オーバーヘッドのため 133G バイトです。RAID-Z プールに関する zpool list および zfs list の出力間で領域に違いがあるのは、zpool list によってインフレートされたプール領域が報告されたためです。
# zpool create tank raidz2 c0t6d0 c0t7d0 c0t8d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 408G 286K 408G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 73.2K 133G 20.9K /tank
次のセクションでは、データ破壊の種類を確認する方法と、破壊したデータを修復する (可能な場合) 方法について説明します。
ZFS では、データ破壊のリスクを最小限に抑えるために、チェックサム、冗長性、および自己修復データが使用されます。それでも、プールが冗長でない場合、プールの機能が低下しているときに破壊が発生した場合、または予期しないことが一度に起こってデータの複数のコピーが破壊された場合は、データの破壊が発生することがあります。どのような原因であったとしても、結果は同じです。 データが破壊され、その結果アクセスできなくなっています。対処方法は、破壊されたデータの種類とその相対的な価値により異なります。破壊されるデータは、大きく 2 つの種類に分けられます。
プールメタデータ – ZFS では、プールを開いてデータセットにアクセスするために、一定量のデータを解析する必要があります。これらのデータが破壊された場合には、プール全体またはデータセット階層の一部が使用できなくなります。
オブジェクトデータ – この場合、破壊は特定のファイルまたはディレクトリに限定されます。この問題が発生すると、そのファイルまたはディレクトリの一部がアクセスできなくなる可能性があります。この問題が原因で、オブジェクトも一緒に破壊されることがあります。
データの検証は、通常の操作中およびスクラブ時に行われます。プールデータの完全性を検証する方法については、「ZFS ファイルシステムの整合性をチェックする」を参照してください。
デフォルトでは、zpool status コマンドでは、破壊が発生したことだけが報告され、破壊が発生した場所は報告されません。次に例を示します。
# 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
特定の時間にエラーが発生したことだけが、エラーごとに報告されます。各エラーが現在もシステムに存在するとは限りません。通常の状況下では、これが当てはまります。なんらかの一時的な機能停止によって、データが破壊されることがあります。それらは、機能停止が終了したあとで自動的に修復されます。プール内のすべてのアクティブなブロックを検査するために、プールのスクラブは完全に実行されることが保証されています。このため、スクラブが完了するたびに、エラーログがリセットされます。エラーが存在しないことを確認したので、スクラブが完了するのを待っている必要がない場合には、zpool online コマンドを使ってプール内のすべてのエラーをリセットします。
データ破壊がプール全体のメタデータで発生している場合は、出力が少し異なります。例:
# 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
プール全体が破壊された場合、プールは必要な冗長レベルを提供できないため、FAULTED 状態になります。
ファイルまたはディレクトリが破壊されても、破壊の種類によってはシステムがそのまま動作する場合があります。データの正常なコピーがシステムに存在しなければ、どの損傷も事実上修復できません。貴重なデータの場合は、影響を受けたデータをバックアップから復元する必要があります。このような場合でも、プール全体を復元しなくても破壊から回復できる場合があります。
ファイルデータブロックの中で損傷が発生した場合は、ファイルを安全に削除することができるため、システムのエラーを解消できます。永続的なエラーが発生しているファイル名のリストを表示するには、zpool status -v コマンドを使用します。例:
# 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
永続的なエラーが発生しているファイル名のリストは、次のようになります。
ファイルへの完全なパスが見つかり、データセットがマウントされている場合は、ファイルへの完全なパスが表示されます。例:
/monkey/a.txt
ファイルへの完全なパスは見つかったが、データセットがマウントされていない場合は、前にスラッシュ (/) が付かず、後ろにファイルへのデータセット内のパスが付いたデータセット名が表示されます。例:
monkey/ghost/e.txt
エラーにより、または dnode_t の場合のようにオブジェクトに実際のファイルパスが関連付けられていないことにより、ファイルパスに対するオブジェクト番号を正常に変換できない場合は、後ろにオブジェクト番号の付いたデータセット名が表示されます。例:
monkey/dnode:<0x0>
メタオブジェクトセット (MOS) のオブジェクトが破壊された場合は、後ろにオブジェクト番号の付いた <metadata> という特別なタグが表示されます。
ディレクトリまたはファイルのメタデータの中で破壊は発生している場合には、そのファイルを別の場所に移動するしかありません。任意のファイルまたはディレクトリを不便な場所に安全に移動することができ、そこで元のオブジェクトを復元することができます。
損傷を受けたファイルシステムにある破壊されたデータが、スナップショットなどの複数のブロック参照を持つ場合は、zpool status -v コマンドを使用しても、破壊されたすべてのデータパスが表示されるわけではありません。現在の zpool status による破壊されたデータの報告は、破壊されたメタデータの量や、zpool status コマンドの実行後にブロックが再利用されたかどうかによって制限されます。複製解除されたブロックがあると、破壊されたすべてのデータの報告がさらに複雑になります。
破壊されたデータがあり、スナップショットデータが影響を受けることが zpool status -v コマンドによって示された場合は、破壊されたほかのパスを特定するために次のコマンドを実行することを検討してください。
プールのメタデータが損傷していて、その損傷によりプールを開けないかインポートできない場合の選択肢には、次のものがあります。
zpool clear -F コマンドまたは zpool import - F コマンドを使用して、プールの回復を試みることができます。これらのコマンドは、プールに対する直近数回のトランザクションをロールバックして、プールを正常な状態に戻すことを試みます。zpool status コマンドを使用すると、損傷したプールと推奨される回復手順を確認できます。例:
# 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
前の出力で説明した回復プロセスでは次のコマンドを使用します。
# zpool clear -F tpool
損傷したストレージプールをインポートしようとすると、次のようなメッセージが表示されます。
# 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.
前の出力で説明した回復プロセスでは次のコマンドを使用します。
# 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
損傷したプールが zpool.cache ファイルに存在する場合、システムのブート時に問題が検出され、損傷したプールが zpool status コマンドで報告されます。プールが zpool.cache ファイルに存在しない場合、プールをインポートすることも開くこともできず、プールをインポートしようとするとプールの損傷を知らせるメッセージが表示されます。
損傷したプールを読み取り専用モードでインポートできます。この方法によってプールをインポートでき、データにアクセスできます。例:
# zpool import -o readonly=on tpool
プールを読み取り専用でインポートすることの詳細については、「読み取り専用モードでプールをインポートする」を参照してください。
zpool import -m コマンドを使用して、ログデバイスのないプールをインポートできます。詳細は、「ログデバイスがないプールをインポートする」を参照してください。
いずれのプール回復方法によってもプールを回復できない場合は、プールとそのすべてのデータをバックアップコピーから復元する必要があります。そのために使用する方法は、プールの構成とバックアップ方法によって大きく異なります。最初に、zpool status コマンドによって表示された構成を保存しておき、プールを破棄したあとで構成を再作成できるようにします。次に、zpool destroy -f コマンドを使用してプールを破棄します。
また、データセットのレイアウトやローカルに設定されたさまざまなプロパティーが記述されているファイルを別の安全な場所に保存します。これは、プールがアクセスできない状態になった場合に、これらの情報にアクセスできなくなるためです。プールを破棄したあとに、プールの構成とデータセットのレイアウトを使用して、完全な構成を再構築できます。次に、なんらかのバックアップまたは採用している復元方法を使って、データを生成することができます。
|