ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris の管理: ZFS ファイルシステム Oracle Solaris 11 Information Library (日本語) |
1. Oracle Solaris ZFS ファイルシステム (概要)
3. Oracle Solaris ZFS ファイルシステムと従来のファイルシステムの相違点
4. Oracle Solaris ZFS ストレージプールの管理
6. Oracle Solaris ZFS ファイルシステムの管理
7. Oracle Solaris ZFS のスナップショットとクローンの操作
8. ACL および属性を使用した Oracle Solaris ZFS ファイルの保護
10. Oracle Solaris ZFS の高度なトピック
11. Oracle Solaris ZFS のトラブルシューティングとプールの回復
13. 推奨の Oracle Solaris ZFS プラクティス
Oracle データベース用のファイルシステム作成のプラクティス
以降のセクションでは、ZFS ストレージプールを作成および監視するための推奨のプラクティスを紹介します。ストレージプールの問題をトラブルシューティングする方法については、第 11 章Oracle Solaris ZFS のトラブルシューティングとプールの回復を参照してください。
最新の Solaris リリースおよびパッチでシステムを最新の状態に保ちます
実際のシステム作業負荷に必要なメモリーのサイズを特定します
データベースアプリケーションなどの既知のアプリケーションのメモリーフットプリントでは、アプリケーションが ZFS キャッシュから必要なメモリーを繰り返し要求する必要がないように、ARC サイズに上限を設定してもかまいません。
重複除去のメモリー要件を考慮します
次のコマンドで ZFS のメモリー使用量を特定します。
# mdb -k > ::memstat Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 388117 1516 19% ZFS File Data 81321 317 4% Anon 29928 116 1% Exec and libs 1359 5 0% Page cache 4890 19 0% Free (cachelist) 6030 23 0% Free (freelist) 1581183 6176 76% Total 2092828 8175 Physical 2092827 8175 > $q
メモリーの破損を防止するため、ECC メモリーの使用を検討してください。メモリーが暗黙のうちに破損すると、データも破損する可能性があります。
定期的にバックアップを実行する – ZFS の冗長性を伴って作成されたプールは、ハードウェアの障害によるダウンタイムの短縮に役立ちますが、ハードウェア障害、電源障害、またはケーブルの切断の影響を受けないわけではありません。必ず定期的にデータをバックアップしてください。データが重要である場合、バックアップする必要があります。データのコピーを取得するには次のようなさまざまな方法があります。
定期的または日単位の ZFS スナップショット
ZFS プールデータの週単位のバックアップ。zpool split コマンドを使用して、ZFS ミラー化ストレージプールの正確な複製を作成できます。
エンタープライズレベルのバックアップ製品を使用した月単位のバックアップ
ハードウェア RAID
ZFS がストレージと冗長性を管理できるように、ストレージアレイにハードウェア RAID でなく JBOD モードを使用することを検討してください。
ハードウェア RAID または ZFS 冗長性、あるいは両方を使用します
ZFS 冗長性を使用することで多くの利点があります。本稼働環境では、ZFS がデータ不整合を修復できるように構成します。配下のストレージデバイスに実装されている RAID レベルに関係なく、RAIDZ、RAIDZ-2、RAIDZ-3、ミラーなどの ZFS 冗長性を使用します。こうした冗長性を使用することで、配下のストレージデバイスまたはそこからホストへの接続での障害を ZFS で検出して修復できます。
クラッシュダンプは多くのディスク容量を消費し、通常、物理メモリーの 1/2 - 3/4 の範囲のサイズになります。
以降のセクションでは、プールの全般的なプラクティスとより具体的なプールのプラクティスについて説明します。
ディスク全体を使用して、ディスク書き込みキャッシュを有効にし、保守をより簡単にします。スライス上にプールを作成すると、ディスクの管理および回復がより複雑になります。
ZFS がデータ不整合を修復できるように、ZFS 冗長性を使用します。
冗長でないプールが作成されると、次のメッセージが表示されます。
# zpool create tank c4t1d0 c4t3d0 'tank' successfully created, but with no redundancy; failure of one device will cause loss of the pool
ミラー化プールの場合は、ミラー化ディスクペアを使用します
RAIDZ プールの場合は、VDEV ごとに 3 - 9 個のディスクをグループ化します
ホットスペアを使用してハードウェアの障害によるダウンタイムを短縮します
デバイス間で I/O が均衡するように、サイズが同程度のディスクを使用します
小さな LUN は大きな LUN に拡張できます
metaslab を適切なサイズに保つために、LUN のサイズを極端に異なるもの (128M バイトから 2T バイトへなど) に拡張しないでください
より高速なシステム回復をサポートするために小さなルートプールと大きなデータプールを作成することを検討してください
s* 識別子を使用して、スライスでルートプールを作成します。p* 識別子を使用しないでください。通常、システムの ZFS ルートプールは、システムがインストールされるときに作成されます。2 つめのルートプールを作成するか、またはルートプールを再作成する場合は、次のような構文を使用します。
# zpool create rpool c0t1d0s0
あるいは、ミラー化ルートプールを作成します。例:
# zpool create rpool mirror c0t1d0s0 c0t2d0s0
ルートプールは、ミラー化構成または単一ディスク構成として作成する必要があります。RAID-Z やストライプ化構成はサポートされていません。zpool add コマンドを使って、追加ディスクを追加して複数のミラー化された最上位レベル仮想ディスクを作成することはできませんが、ミラー化された仮想デバイスを zpool attach コマンドを使って拡張することは可能です。
ルートプールに別個のログデバイスを使用することはできません。
プールプロパティーは、AI インストール中に設定できますが、gzip 圧縮アルゴリズムはルートプールでサポートされていません。
ルートプールを初期インストールによって作成したあとは、ルートプールの名前を変更しないでください。ルートプールの名前を変更すると、システムがブートできなくなる可能性があります。
d* 識別子を使用して、ディスク全体で非ルートプールを作成します。p* 識別子は使用しないでください。
ZFS は、追加のボリューム管理ソフトウェアを一切使わないで最適に機能します。
パフォーマンスを向上させるために、個々のディスクを使用するか、または少数のディスクで構成される LUN のみを使用します。ZFS での LUN セットアップに対する視認性を高めることにより、ZFS は入出力のスケジューリングをより適切に決定できます。
複数のコントローラにまたがる冗長なプール構成を作成して、コントローラの障害によるダウンタイムを短縮します。
ミラー化ストレージプール – 多くのディスクを消費しますが、一般に、小さなランダム読み取りでパフォーマンスが向上します。
# zpool create tank mirror c1d0 c2d0 mirror c3d0 c4d0
RAID-Z ストレージプール – 3 つのパリティー方式を使って作成できます。この場合、パリティーは 1 (raidz)、2 (raidz2)、または 3 (raidz3) に等しくなります。RAID-Z 構成は、ディスク容量を最大化し、通常、データが大きなチャンク (128K 以上) で読み取りおよび書き込みされるときに、パフォーマンスが高くなります。
それぞれ 3 つのディスク (2+1) の 2 つの VDEV を持つシングルパリティー RAID-Z (raidz) 構成を検討してください。
# zpool create rzpool raidz1 c1t0d0 c2t0d0 c3t0d0 raidz1 c1t1d0 c2t1d0 c3t1d0
RAIDZ-2 構成では、データの可用性が向上し、RAID-Z と同様の性能が提供されます。RAIDZ-2 は、RAID-Z または双方向ミラーよりもデータ損失までの平均時間 (MTTDL) がかなり短縮されます。6 台のディスク (4+2) でダブルパリティーの RAID-Z (raidz2) 構成を作成します。
# zpool create rzpool raidz2 c0t1d0 c1t1d0 c4t1d0 c5t1d0 c6t1d0 c7t1d0 raidz2 c0t2d0 c1t2d0 c4t2d0 c5t2d0 c6t2d0 c7t2d
RAIDZ-3 構成では、ディスク容量が最大となり、3 台のディスク障害に耐えられるため、優れた可用性が提供されます。9 つのディスク (6+3) では、トリプルパリティー RAID-Z (raidz3) 構成を作成します。
# zpool create rzpool raidz3 c0t0d0 c1t0d0 c2t0d0 c3t0d0 c4t0d0 c5t0d0 c6t0d0 c7t0d0 c8t0d0
Oracle データベースを作成するときには、次のストレージプールのプラクティスを考慮してください。
ミラー化プールまたはハードウェア RAID を使用します。
ランダム読み取り作業負荷には、一般的に RAID-Z プールは推奨されていません。
データベース redo ログ用の個別のログデバイスで小さな個別のプールを作成します。
アーカイブログ用の小さな個別のプールを作成します。
詳細は、次のホワイトペーパーを参照してください。
http://blogs.oracle.com/storage/entry/new_white_paper_configuring_oracle
最適なパフォーマンスには、プール容量を 80% 以下に保ちます
ランダムな読み取り/書き込み作業負荷の場合、RAID-Z プールにわたるミラー化プールをお勧めします
個別のログデバイス
同期書き込みパフォーマンスを高めるために推奨されています
同期書き込み負荷が高い場合でも、メインプール内の多数のログブロックに書き込むことでの断片化を防ぎます
読み取りパフォーマンスを高めるには、個別のキャッシュデバイスをお勧めします
スクラブ/再同期化 - 多数のデバイスで構成される非常に大きな RAID-Z プールは、スクラブや再同期化の時間が長くなります
プールパフォーマンスが低い – zpool status コマンドを使用して、プールのパフォーマンス問題の原因となっているハードウェアの問題を排除します。zpool status コマンドで問題が現れない場合は、fmdump コマンドを使用して、ハードウェアの障害を表示するか、fmdump -eV コマンドを使用して、報告された障害にはまだなっていないハードウェアエラーを確認します。
パフォーマンスを最適にするために、必ずプール容量が 80% を下回るようにします。
ビジー状態のメールサーバー上など、プールがいっぱいでファイルシステムが頻繁に更新されるときは、プールパフォーマンスが低下する可能性があります。プールがいっぱいになると、パフォーマンスペナルティーが発生することがありますが、それ以外の問題は発生しません。主要な作業負荷が不変のファイルの場合は、プール使用率の範囲を 95 - 96% に維持してください。95 - 96% の範囲のほとんど静的なコンテンツでも、書き込み、読み取り、および再同期のパフォーマンスが低下することがあります。
プールとファイルシステムの容量を監視して、それらがいっぱいにならないようにします。
ZFS の割り当て制限と予約を使用して、ファイルシステムの容量がプール容量の 80% を超えないようにすることを検討します。
プールの健全性を監視します
冗長プールの場合は、zpool status および fmdump を使用して、週単位でプールを監視します
冗長でないプールの場合は、zpool status および fmdump を使用して、2 週間に 1 度プールを監視します
zpool scrub を定期的に実行して、データ整合性の問題を特定します。
消費者品質のドライブがある場合は、スクラブを週に 1 度行うスケジュールを考えます。
データセンター品質のドライブがある場合は、スクラブを月に 1 度行うスケジュールを考えます。
デバイスを交換する前やプールの冗長性を一時的に下げる前にもスクラブを実行して、すべてのデバイスが現在運用可能であることを確認するようにしてください。
プールまたはデバイス障害の監視 - 下記のように zpool status を使用します。また、fmdump または fmdump -eV を使用して、デバイスの障害またはエラーが発生しているかどうかを調べます。
冗長プールの場合は、zpool status および fmdump を使用して、週単位でプールの健全性を監視します
冗長でないプールの場合は、zpool status および fmdump を使用して、2 週間に 1 度プールの健全性を監視します
プールデバイスが UNAVAIL または OFFLINE である – プールデバイスが使用できない場合、そのデバイスが format コマンド出力に一覧表示されているかどうかを確認します。デバイスが format 出力に一覧表示されていない場合、デバイスは ZFS に認識されていません。
プールデバイスが UNAVAIL または OFFLINE である場合、これは通常、デバイスに障害があったりケーブルが切断されていたりすること、または、不良ケーブルや不良コントローラなど、ほかのハードウェアの問題が原因でデバイスにアクセスできないことを示します。
ハードウェアコンポーネントが欠陥があると診断されたときに通知するように、smtp-notify サービスを構成することを検討してください。詳細は、smf(5) および smtp-notify(1M) の通知パラメータセクションを参照してください。
デフォルトでは、いくつかの通知は root ユーザーに送信されるように自動的に設定されます。/etc/aliases ファイルでユーザーアカウントの別名を root として追加した場合は、次のような電子メール通知を受け取ります。
-------- Original Message -------- Subject: Fault Management Event: tardis:SMF-8000-YX Date: Wed, 21 Sep 2011 11:11:27 GMT From: No Access User <noaccess@tardis.drwho.COM> Reply-To: root@tardis.drwho.COM To: root@tardis.drwho.COM SUNW-MSG-ID: ZFS-8000-D3, TYPE: Fault, VER: 1, SEVERITY: Major EVENT-TIME: Wed Sep 21 11:11:27 GMT 2011 PLATFORM: Sun-Fire-X4140, CSN: 0904QAD02C, HOSTNAME: tardis SOURCE: zfs-diagnosis, REV: 1.0 EVENT-ID: d9e3469f-8d84-4a03-b8a3-d0beb178c017 DESC: A ZFS device failed. Refer to http://sun.com/msg/ZFS-8000-D3 for more information. AUTO-RESPONSE: No automated response will occur. IMPACT: Fault tolerance of the pool may be compromised. REC-ACTION: Run 'zpool status -x' and replace the bad device.
ストレージプール容量を監視する – zpool list コマンドと zfs list コマンドを使用して、ファイルシステムデータによってどれだけのディスクが消費されたかを特定します。ZFS スナップショットがディスク容量を消費する可能性があります。zfs list コマンドで ZFS スナップショットが一覧表示されない場合、認識されずにディスクを消費していることがあります。zfs list - t スナップショットコマンドを使用して、スナップショットが消費するディスク容量を特定します。