ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris 11.1 の管理: ZFS ファイルシステム Oracle Solaris 11.1 Information Library (日本語) |
1. Oracle Solaris ZFS ファイルシステム (概要)
3. Oracle Solaris ZFS ストレージプールの管理
5. Oracle Solaris ZFS ファイルシステムの管理
6. Oracle Solaris ZFS のスナップショットとクローンの操作
7. ACL および属性を使用した Oracle Solaris ZFS ファイルの保護
9. Oracle Solaris ZFS の高度なトピック
10. Oracle Solaris ZFS のトラブルシューティングとプールの回復
12. 推奨の Oracle Solaris ZFS プラクティス
このセクションでは、デバイスの障害の種類を確認し、一時的なエラーをクリアし、デバイスを置き換える方法について説明します。
「損傷したデバイス」という用語は定義があいまいですが、発生する可能性のあるいくつかの状況はこの用語で説明できます。
ビットの腐敗 – 時間の経過とともに、磁力の影響や宇宙線などのさまざまなことが原因で、ディスクに格納されているビットが反転してしまうことがあります。このようなことはあまり発生しませんが、発生した場合には、大規模なまたは長期間稼働するシステムでデータが破壊する可能性は十分にあります。
間違った方向への読み取りまたは書き込み – ファームウェアのバグまたはハードウェア障害のために、ブロック全体の読み取りまたは書き込みで、ディスク上の不正な場所を参照してしまうことがあります。これらのエラーは通常、一時的です。ただし、エラーの数が多い場合には、ドライブの障害が発生している可能性があります。
管理者エラー – 管理者が意図せずにディスクの一部を不正なデータで上書きする (ディスクの一部に /dev/zero をコピーするなど) ことで、ディスクが永続的に破壊されてしまう場合があります。これらのエラーは常に一時的です。
一時的な機能停止– ディスクが一定期間使用できなくなり、入出力に失敗することがあります。この状況は通常、ネットワークに接続されたデバイスに発生しますが、ローカルディスクでも一時的に機能が停止することがあります。これらのエラーは、一時的な場合と、そうでない場合があります。
不良または信頼性の低いハードウェア – この状況は、ハードウェアの障害によって引き起こされるさまざまな問題の総称です。問題の例としては、断続的な入出力エラー、不規則な破壊を引き起こす転送エラー、その他のさまざまな障害があります。これらのエラーは通常永続的です。
オフラインのデバイス – デバイスがオフラインである場合は、そのデバイスに障害が発生していると判断した管理者がデバイスをこの状態にしたと推定されます。管理者は、デバイスをこの状態にしたうえで、この推定が正しいかどうかを判断できます。
デバイスのどこに問題があるかを正確に判断することは、難しい作業です。最初に行うことは、zpool status 出力のエラー数を調べることです。例:
# zpool status -v tank pool: tank 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://support.oracle.com/msg/ZFS-8000-8A config: NAME STATE READ WRITE CKSUM tank ONLINE 2 0 0 c8t0d0 ONLINE 0 0 0 c8t0d0 ONLINE 2 0 0 errors: Permanent errors have been detected in the following files: /tank/file.1
エラーは、入出力エラーとチェックサムエラーに分かれます。どちらのエラーも、発生している可能性のある障害の種類を示している可能性があります。通常の処理で発生するエラーの数は、少ない (長い時間にほんの数個) と予測されます。大量のエラーが表示される場合、この状況はデバイス障害がすぐに発生する可能性または完全なデバイス障害が発生する可能性を示しています。ただし、管理者のミスが原因で大量のエラーが表示される可能性もあります。別の情報源は、syslog システムログです。このログに大量の SCSI ドライバまたはファイバチャネルドライバのメッセージが記録される場合、この状況は重大なハードウェアの問題が発生している可能性を示しています。syslog メッセージが生成されない場合、損傷は一時的であると思われます。
最後の手順は次の質問に答えることです。
このデバイスでもう一度エラーが発生する可能性がありますか。
一度だけ発生するエラーは「一時的」と考えられ、潜在的な障害を示していません。ハードウェア障害の可能性がある持続的または重大なエラーは、「致命的」と考えられます。エラーの種類を特定する作業は、ZFS で現在利用できる自動化ソフトウェアの範囲を超えているため、管理者自身が手動で行う必要があります。エラーの種類を特定したあとで、それに対応する処置を採ることができます。一時的なエラーを解消したり、致命的なエラーが起こっているデバイスを置き換えたります。これらの修復手順については、次のセクションで説明します。
一時的であると考えられるデバイスエラーでも、それらがプール内のデータの訂正不可能なエラーを発生させていることがあります。このようなエラーについては、配下のデバイスが健全であると判断されている場合、または別の機会に修復されている場合でも、特別な修復手順が必要になります。データエラーの修復の詳細については、「損傷したデータを修復する」を参照してください。
デバイスエラーが一時的と考えられる場合、つまりデバイスの今後の健全性に影響しないと考えられる場合は、デバイスエラーを安全に解消することで、致命的なエラーが発生していないと示すことができます。RAID-Z デバイスまたはミラーデバイスのエラー数をクリアするには、zpool clear コマンドを使用します。次に例を示します。
# zpool clear tank c1t1d0
この構文を実行すると、すべてのデバイスエラーと、デバイスに関連付けられたすべてのデータエラー数がクリアされます。
プール内の仮想デバイスに関連付けられているすべてのエラーをクリアし、プールに関連付けられているすべてのデータエラー数をクリアするには、次の構文を使用します。
# zpool clear tank
プールエラーのクリアの詳細については、「ストレージプールデバイスのエラーをクリアーする」を参照してください。
デバイスの損傷が永続的である場合、または永続的な損傷が今後発生する可能性がある場合には、そのデバイスを置き換える必要があります。デバイスを置き換えられるかどうかは、構成によって異なります。
置き換えるデバイスが冗長構成の一部である場合は、正常なデータを取得するための十分な複製が存在している必要があります。たとえば、4 方向ミラーの 2 台のディスクが UNAVAIL の場合は、健全な複製を入手できるので、どちらのディスクも交換できます。ただし、4 方向 RAID-Z (raidz1) 仮想デバイス内の 2 台のディスクが UNAVAIL の場合は、データを入手するために必要な複製が不足しているため、どちらのディスクも交換できません。デバイスが損傷していてもオンラインである場合は、プールの状態が UNAVAIL でないかぎり、それを交換できます。ただし、損傷を受けたデバイス上の壊れたデータは、正常なデータが格納されている複製が必要な数だけ存在しない場合には、新しいデバイスにコピーされます。
次の構成で、c1t1d0 ディスクは置き換えることができます。プール内のすべてのデータは正常な複製 c1t0d0 からコピーされます。
mirror DEGRADED c1t0d0 ONLINE c1t1d0 UNAVAIL
c1t0d0 ディスクも置き換えることができますが、正常な複製を入手できないため、データの自己修復は行われません。
次の構成では、UNAVAIL のディスクはどれも交換できません。プール自体が UNAVAIL のため、ONLINE のディスクも交換できません。
raidz1 UNAVAIL c1t0d0 ONLINE c2t0d0 UNAVAIL c3t0d0 UNAVAIL c4t0d0 ONLINE
次の構成の最上位レベルのディスクは、どちらも置き換えることができます。ただし、ディスクに不正なデータが存在する場合は、それらが新しいディスクにコピーされます。
c1t0d0 ONLINE c1t1d0 ONLINE
どちらかのディスクが UNAVAIL の場合は、プール自体が UNAVAIL のため、交換を行うことはできません。
デバイスが失われたためにプールが UNAVAIL になった場合、または非冗長な構成でデバイスに大量のデータエラーが含まれている場合は、そのデバイスを安全に交換することはできません。十分な冗長性がない場合、損傷したデバイスの修復に使用する正常なデータは存在しません。この場合は、プールを破棄して構成を再作成したのちに、データをバックアップコピーから復元するのが唯一の選択肢です。
プール全体を復元する方法の詳細については、「ZFS ストレージプール全体の損傷を修復する」を参照してください。
置き換えられるデバイスであることを確認したあとで、zpool replace コマンドを使ってデバイスを置き換えます。損傷したデバイスを別のデバイスに置き換える場合は、次のような構文を使用します。
# zpool replace tank c1t1d0 c2t0d0
このコマンドを実行すると、損傷したデバイスまたはプール内のほかのデバイス (冗長な構成の場合) から新しいデバイスにデータが移行されます。コマンドが完了すると、損傷したデバイスが構成から切り離され、そのデバイスをシステムから取り外せる状態になります。1 つの場所ですでにデバイスを取り外して新しいデバイスに置き換えている場合には、1 つのデバイス形式のコマンドを使用します。例:
# zpool replace tank c1t1d0
このコマンドにフォーマットされていないディスクを指定すると、そのディスクが適切な状態にフォーマットされたのち、残りの構成からデータが再同期化されます。
zpool replace コマンドの詳細については、「ストレージプール内のデバイスを置き換える」を参照してください。
例 10-1 ZFS ストレージプール内の SATA ディスクを置き換える
次の例では、システムのミラー化ストレージプール tank のデバイス (c1t3d0) を SATA デバイスに置き換える方法を示します。ディスク c1t3d0 を同じ位置 (c1t3d0) で新しいディスクに置き換えるには、ディスクを置き換える前に構成解除する必要があります。置き換えられるディスクが SATA ディスクでない場合は、「ストレージプール内のデバイスを置き換える」を参照してください。
基本的な手順は次のとおりです。
置き換えるディスク (c1t3d0) をオフラインにします。現在使用中の SATA ディスクを構成解除することはできません。
cfgadm コマンドを使用して、構成解除する SATA ディスク (c1t3d0) を識別し、それを構成解除します。このミラー化構成にオフラインのディスクが存在するプールの機能は低下しますが、プールは引き続き使用可能です。
ディスク (c1t3d0) を物理的に交換します。可能であれば、UNAVAIL のドライブを物理的に取り外す前に、青色の Ready to Remove (取り外し準備完了) LED が点灯していることを確認してください。
SATA ディスク (c1t3d0) を再構成します。
新しいディスク (c1t3d0) をオンラインにします。
zpool replace コマンドを実行してディスク (c1t3d0) を置き換えます。
注 - あらかじめプールの autoreplace プロパティーをオンに設定してあった場合、そのプールに以前属していたデバイスと物理的に同じ位置に新しいデバイスが検出されると、そのデバイスは自動的にフォーマットされ、zpool replace コマンドを使用せずに置き換えられます。ハードウェアによっては、この機能はサポートされない場合があります。
障害の発生したディスクがホットスペアに自動的に置き換えられる場合は、障害の発生したディスクが置き換えられたあとでホットスペアの切り離しが必要になることがあります。たとえば、障害の発生したディスクが置き換えられたあとも c2t4d0 がアクティブなホットスペアになっている場合は、切り離してください。
# zpool detach tank c2t4d0
FMA が障害の発生したデバイスを報告している場合、デバイスの障害を解決してください。
# fmadm faulty # fmadm repaired zfs://pool=name/vdev=guid
次の例では、ZFS ストレージプール内のディスクを置き換える手順を示します。
# 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
上記の zpool の出力で、新しいディスクと古いディスクの両方が replacing 見出しの下に表示される場合があります。例:
replacing DEGRADED 0 0 0 c1t3d0s0/o FAULTED 0 0 0 c1t3d0 ONLINE 0 0 0
このテキストは、置き換え処理および新しいディスクの再同期化が進行中であることを示しています。
ディスク (c1t3d0) を別のディスク (c4t3d0) で置き換える場合は、zpool replace コマンドの実行だけが必要です。例:
# 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
ディスクの置き換えが完了するまでに zpool status コマンドを数回実行する必要がある場合があります。
# 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
例 10-2 障害が発生したログデバイスを交換する
zpool status コマンド出力でインテントログ障害が ZFS によって特定されています。これらのエラーは障害管理アーキテクチャー (FMA) によっても報告されます。ZFS と FMA は両方とも、インテントログ障害から回復する方法を説明します。
次の例では、ストレージプール pool で障害が発生したログデバイス c0t5d0 を回復する方法を示します。基本的な手順は次のとおりです。
zpool status -x の出力と FMA 診断メッセージを確認します (次のサイトの説明を参照)。
障害が発生したログデバイスを物理的に交換します。
新しいログデバイスをオンラインにします。
プールのエラー状況がクリアされます。
FMA エラーを解決します。
たとえば、別個のログデバイスを持つプールに対する同期書き込み操作が確定される前にシステムが突然シャットダウンされた場合には、次のようなメッセージが表示されます。
# 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 # fmadm faulty # fmadm repair zfs://pool=name/vdev=guid
そのような場合には、次の方法でログデバイスの障害を解決できます。
ログデバイスを交換または回復します。この例の場合、ログデバイスは c0t5d0 です。
ログデバイスをオンラインに戻します。
# zpool online pool c0t5d0
障害が発生したログデバイスのエラー状況がリセットされます。
# zpool clear pool
障害が発生したログデバイスを交換せずにこのエラーから回復するために、zpool clear コマンドを使用してエラーを解決することができます。このシナリオでは、プールが縮退モードで実行され、ログレコードは、ログデバイスが交換されるまで、メインプールに書き込まれます。
ログデバイスの障害の発生を回避するため、ミラー化ログデバイスを利用することを検討してください。
デバイスを置き換えるときには、デバイスのサイズとプールに含まれるデータの量によっては、かなり長い時間がかかることがあります。あるデバイスのデータを別のデバイスに移動する処理は「再同期化」と呼ばれ、zpool status コマンドを使ってモニターできます。
次の zpool status 再同期化ステータスメッセージが表示されます。
再同期化進捗レポート。例:
scan: resilver in progress since Mon Jun 7 09:17:27 2010 13.3G scanned out of 16.2G at 18.5M/s, 0h2m to go 13.3G resilvered, 82.34% done
再同期化完了メッセージ。例:
resilvered 16.2G in 0h16m with 0 errors on Mon Jun 7 09:34:21 2010
再同期化完了メッセージはシステムのリブート後も残ります。
従来のファイルシステムでは、ブロックレベルでデータが再同期化されます。ZFS では、ボリュームマネージャーの論理階層がなくなり、より強力な制御された方法で再同期化できます。この機能の主な利点として、次の 2 点を挙げることができます。
ZFS では、最小限の必要なデータ量だけが再同期化されます。デバイスの完全な置き換えとは異なり、短時間の停止の場合は、わずか数分または数秒でディスク全体を再同期化できます。ディスク全体を置き換えるときは、再同期化処理にかかる時間は、ディスク上で使用されているデータ量に比例します。500G バイトのディスクを置き換えるときでも、プールで使用されているディスク容量が数 G バイトであれば、数秒で完了できます。
再同期化は、割り込み可能で安全です。システムの電源が切れるか、またはシステムがリブートした場合には、再同期化処理は中断した場所から正確に再開されます。手動で介入する必要はありません。
再同期化処理を表示するには、zpool status コマンドを使用します。例:
# zpool status tank pool: tank state: ONLINE 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. scan: resilver in progress since Mon Jun 7 10:49:20 2010 54.6M scanned out of 222M at 5.46M/s, 0h0m to go 54.5M resilvered, 24.64% done config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 replacing-0 ONLINE 0 0 0 c1t0d0 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 (resilvering) c1t1d0 ONLINE 0 0 0
この例では、ディスク c1t0d0 が c2t0d0 に置き換わります。ステータスが replacing の仮想デバイスが構成に存在しているので、このイベントはステータス出力で監視されます。このデバイスは実際のデバイスではなく、このデバイスを使ってプールを作成することもできません。このデバイスは、再同期化処理を表示し、置き換え中のデバイスを識別するためだけに使用されます。
再同期化が現在進行しているプールの状態は、すべて ONLINE または DEGRADED 状態になります。これは、再同期化処理が完了するまで、必要とする冗長レベルをそのプールで提供できないためです。システムへの影響を最小限に抑えるために、再同期化は最大限の速度で処理されます。ただし、その入出力の優先順位は、ユーザーが要求した入出力より常に低く設定されます。再同期化が完了すると、新しい完全な構成に戻ります。例:
# 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
プールは ONLINE に戻り、元の障害が発生したディスク (c1t0d0) は構成から削除されています。