以降のセクションでは、ZFS ストレージプールを作成およびモニターするための推奨のプラクティスを紹介します。ストレージプールの問題をトラブルシューティングする方法については、Oracle Solaris ZFS のトラブルシューティングとプールの回復を参照してください。
最新の Oracle Solaris 更新およびリリースでシステムを最新の状態に保ちます
データが必ず安全に書き込まれるように、コントローラがキャッシュフラッシュコマンドを受け付けることを確認してください。これは、プールのデバイスを変更する前、またはミラー化ストレージプールを分割する前に重要になります。これは通常 Oracle/Sun ハードウェアの問題ではありませんが、ハードウェアのキャッシュフラッシュ設定が有効であることを確認するのをお勧めします。
実際のシステム作業負荷に必要なメモリーのサイズを特定します
データベースアプリケーションなどの既知のアプリケーションのメモリーフットプリントでは、アプリケーションが 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
ZFS ARC キャッシュをチューニングするヒントについては、My Oracle Support (MOS) のドキュメント 1663862.1、『Memory Management Between ZFS and Applications in Oracle Solaris 11.x』を参照してください。このドキュメントには、user_reserver_hint_pct メモリー管理パラメーターを変更するために使用できるスクリプトが含まれています。
メモリーの破損を防止するため、ECC メモリーの使用を検討してください。メモリーが暗黙のうちに破損すると、データも破損する可能性があります。
定期的にバックアップを実行する – ZFS の冗長性を伴って作成されたプールは、ハードウェアの障害によるダウンタイムの短縮に役立ちますが、ハードウェア障害、電源障害、またはケーブルの切断の影響を受けないわけではありません。必ず定期的にデータをバックアップしてください。データが重要である場合、バックアップする必要があります。データのコピーを取得するには次のようなさまざまな方法があります。
定期的または日単位の ZFS スナップショット
ZFS プールデータの週単位のバックアップ。zpool split コマンドを使用して、ZFS ミラー化ストレージプールの正確な複製を作成できます。
エンタープライズレベルのバックアップ製品を使用した月単位のバックアップ
ハードウェア RAID
ZFS がストレージと冗長性を管理できるように、ストレージアレイにハードウェア RAID でなく JBOD モードを使用することを検討してください。
ハードウェア RAID または ZFS 冗長性、あるいは両方を使用します
ZFS 冗長性を使用することで多くの利点があります。本稼働環境では、ZFS がデータ不整合を修復できるように構成します。ベースとなるストレージデバイスに実装されている RAID レベルに関係なく、RAID-Z、RAID-Z-2、RAID-Z-3、ミラーなどの ZFS 冗長性を使用します。こうした冗長性を使用することで、配下のストレージデバイスまたはそこからホストへの接続での障害を ZFS で検出して修復できます。
ハードウェア RAID ソリューションの冗長性が確実な場合は、ZFS 冗長性なしの ZFS をハードウェア RAID アレイとともに使用することを検討します。ただし、データ整合性を確保するために、次の推奨事項に従ってください。
ハードウェア RAID アレイで障害が発生した場合は ZFS がデータの不整合を解決できないことを考慮して、安心感に基づいて LUN および ZFS ストレージプールのサイズを割り当てます。
RAID5 LUN とグローバルホットスペアを作成します。
zpool status を使用して ZFS ストレージプールを、ハードウェア RAID モニタリングツールを使用して配下の LUN をモニターします。
障害が発生したデバイスはすみやかに置換します。
データセンター品質のサービスを使用している場合は、毎月など、定期的に ZFS ストレージプールをスクラブします。
重要なデータの正常な最新のバックアップを常に用意します。
ローカルまたはネットワーク接続のストレージアレイでのプール作成のプラクティスも参照してください。
クラッシュダンプは多くのディスク容量を消費し、通常、物理メモリーの 1/2 - 3/4 の範囲のサイズになります。
以降のセクションでは、プールの全般的なプラクティスとより具体的なプールのプラクティスについて説明します。
ディスク全体を使用して、ディスク書き込みキャッシュを有効にし、保守をより簡単にします。スライス上にプールを作成すると、ディスクの管理および回復がより複雑になります。
ZFS がデータ不整合を修復できるように、ZFS 冗長性を使用します。
冗長でないプールが作成されると、次のメッセージが表示されます。
$ zpool create system1 c4t1d0 c4t3d0 'system1' successfully created, but with no redundancy; failure of one device will cause loss of the pool
ミラー化プールの場合は、ミラー化ディスクペアを使用します
RAID-Z プールの場合は、VDEV ごとに 3 - 9 個のディスクをグループ化します
同じプール内に RAID-Z とミラー化コンポーネントを混在させないでください。これらのプールは管理が難しく、パフォーマンスが低下する可能性があります。
ホットスペアを使用してハードウェアの障害によるダウンタイムを短縮します
デバイス間で I/O が均衡するように、サイズが同程度のディスクを使用します
小さな LUN は大きな LUN に拡張できます
metaslab を適切なサイズに保つために、LUN のサイズを極端に異なるもの (128M バイトから 2T バイトへなど) に拡張しないでください
より高速なシステム回復をサポートするために小さなルートプールと大きなデータプールを作成することを検討してください
推奨される最小のプールサイズは 8G バイトです。最小のプールサイズは 64M バイトですが、8G バイト未満では空きプール領域の割り当てや再利用が難しくなります。
推奨される最大のプールサイズは、実際の作業負荷やデータサイズが十分収まるサイズのはずです。定期的にバックアップできる量を超えるデータを格納しようとしないでください。そうしないと、データに予期しない問題が発生する可能性があります。
ローカルまたはネットワーク接続のストレージアレイでのプール作成のプラクティスも参照してください。
SPARC (SMI (VTOC)): s* 識別子を使用して、スライスでルートプールを作成します。p* 識別子を使用しないでください。通常、システムの ZFS ルートプールは、システムがインストールされるときに作成されます。2 つ目のルートプールを作成するか、またはルートプールを再作成する場合は、SPARC システムで次のような構文を使用します。
$ zpool create rpool c0t1d0s0
あるいは、ミラー化ルートプールを作成します。例:
$ zpool create rpool mirror c0t1d0s0 c0t2d0s0
Solaris 11.1 x86 (EFI (GPT)): d* 識別子を使用して、ディスク全体でルートプールを作成します。p* 識別子を使用しないでください。通常、システムの ZFS ルートプールは、システムがインストールされるときに作成されます。2 つめのルートプールを作成するか、またはルートプールを再作成する場合は、次のような構文を使用します。
$ zpool create rpool c0t1d0
あるいは、ミラー化ルートプールを作成します。例:
$ zpool create rpool mirror c0t1d0 c0t2d0
ルートプールは、ミラー化構成または単一ディスク構成として作成する必要があります。RAID-Z もストライプ化構成もサポートされていません。zpool add コマンドを使って、追加ディスクを追加して複数のミラー化された最上位レベル仮想ディスクを作成することはできませんが、ミラー化された仮想デバイスを zpool attach コマンドを使って拡張することは可能です。
ルートプールに別個のログデバイスを使用することはできません。
プールプロパティーは、AI インストール中に設定できますが、gzip 圧縮アルゴリズムはルートプールでサポートされていません。
ルートプールを初期インストールによって作成したあとは、ルートプールの名前を変更しないでください。ルートプールの名前を変更すると、システムがブートできなくなる可能性があります。
ルートプールディスクは連続的な操作に重要であるため (特にエンタープライズ環境で)、本番システムではルートプールを USB スティック上に作成しないでください。ルートプールにシステムの内蔵ディスクを使用することを検討するか、あるいは、少なくとも非ルートデータに使用するのと同品質のディスクを使用してください。また、USB スティックは、物理メモリーの少なくとも 1/2 のサイズに等しいダンプボリュームサイズをサポートするのに十分な大きさではない可能性があります。
ルートプールにホットスペアを追加するのではなく、2 方向または 3 方向のミラールートプールを作成することを検討してください。さらに、ルートプールとデータプール間でホットスペアを共有しないでください。
VMware のシンプロビジョニングされたデバイスをルートプールデバイスに使用しないでください。
d* 識別子を使用して、ディスク全体で非ルートプールを作成します。p* 識別子を使用しないでください。
ZFS は、追加のボリューム管理ソフトウェアを一切使わないで最適に機能します。
パフォーマンスを向上させるために、個々のディスクを使用するか、または少数のディスクで構成される LUN のみを使用します。ZFS での LUN セットアップに対する視認性を高めることにより、ZFS は入出力のスケジューリングをより適切に決定できます。
複数のコントローラにまたがる冗長なプール構成を作成して、コントローラの障害によるダウンタイムを短縮します。
ミラー化ストレージプール – 多くのディスクを消費しますが、一般に、小さなランダム読み取りでパフォーマンスが向上します。
$ zpool create system1 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
ローカルまたはリモートで接続されているストレージアレイに ZFS ストレージプールを作成するときには、次のストレージプールのプラクティスを考慮してください。
SAN デバイスにプールを作成し、ネットワーク接続の速度が低下した場合は、プールのデバイスが一定期間 UNAVAIL になる可能性があります。ネットワーク接続が連続的な方法でデータを提供するのに適しているかどうかを評価する必要があります。また、ルートプールに SAN デバイスを使用する場合は、システムがブートするとすぐにそれらが使用できなくなる可能性があり、ルートプールのデバイスも UNAVAIL になる可能性があることを考慮してください。
フラッシュ書き込みキャッシュリクエストが ZFS から発行されたあとにディスクアレイがそのキャッシュをフラッシュしていないことを、アレイベンダーに確認してください。
Oracle Solaris ZFS がローカルの小さなディスクキャッシュをアクティブ化できるように、ディスクスライスではなくディスク全体をストレージプールデバイスとして使用します。これにより、適切な時期にフラッシュされます。
最良のパフォーマンスを得るために、アレイ内の物理ディスクごとに 1 つの LUN を作成します。大きな LUN を 1 つだけ使用すると、ZFS がキューに入れる入出力読み取り操作の数が少なすぎて実際にはストレージを最適なパフォーマンスにすることができない可能性があります。反対に、小さな LUN を多数使用すると、ストレージが多数の保留中の入出力読み取り操作であふれてしまう可能性があります。
動的 (シン) プロビジョニングソフトウェアを使用して仮想領域割り当てを実装するストレージアレイは、Oracle Solaris ZFS にはお勧めしません。Oracle Solaris ZFS が変更されたデータを空き領域に書き込むと、それは LUN 全体に書き込まれます。Oracle Solaris ZFS の書き込みプロセスでは、すべての仮想領域をストレージアレイの視点から割り当てますが、これは動的プロビジョニングの利点を打ち消すものです。
ZFS の使用時は、動的プロビジョニングソフトウェアが不要になる可能性があることを考慮してください。
既存の ZFS ストレージプールで LUN を拡張できるため、新しい領域が使用されます。
小さな LUN が大きな LUN に置き換えられるときも同様の動作が行われます。
プールのストレージニーズを評価し、必要なストレージニーズに等しい小さな LUN でプールを作成した場合、より多くの領域が必要であれば、いつでもそれらの LUN を大きなサイズに拡張できます。
アレイが個々のデバイスを提供できる場合 (JBOD モード) は、このタイプのアレイに冗長な ZFS ストレージプール (ミラーまたは RAID-Z) を作成して、ZFS がデータの矛盾を報告および訂正できるようにすることを考慮してください。
Oracle データベースを作成するときには、次のストレージプールのプラクティスを考慮してください。
ミラー化プールまたはハードウェア RAID を使用します。
ランダム読み取り作業負荷には、一般的に RAID-Z プールは推奨されていません。
データベース redo ログ用の個別のログデバイスで小さな個別のプールを作成します。
アーカイブログ用の小さな個別のプールを作成します。
Oracle データベースのための ZFS の調整情報については、Oracle Solaris 11.4 Tunable Parameters Reference Manual の Tuning ZFS for Database Productsを参照してください。
VirtualBox は、デフォルトでベースとなるストレージからキャッシュフラッシュコマンドを無視するように構成されています。これは、システムクラッシュやハードウェア障害が発生した場合にデータが失われる可能性があることを意味します。
次のコマンドを発行して、VirtualBox でのキャッシュフラッシュを有効にします。
VBoxManage setextradata vm-name "VBoxInternal/Devices/type/0/LUN#n/Config/IgnoreFlush" 0
vm-name – 仮想マシンの名前
type – piix3ide (IDE 仮想コントローラを使用している場合) または ahci (SATA コントローラを使用している場合) のいずれかのコントローラタイプ。
n – ディスク番号
一般的に、パフォーマンスを最適にするためには、プール容量が 90% を下回るようにします。パフォーマンスが影響を受けるパーセントは、ワークロードによって大きく左右されます。
ほとんどがデータの追加の場合 (1 回書き込み、削除なし)、ZFS が新しいブロックを見つけることは非常に簡単です。この場合、パーセントは通常よりも高くてもかまわず、最大 95% 程度です。
データが大きいファイルまたは大きいブロック (128K ファイルまたは 1M バイトブロック) で作成されており、データが一括操作で削除される場合、パーセントは通常よりも高くてもかまわず、最大 95% 程度です。
プールの大きな部分 (50% 以上) が 8k のチャンク (DB ファイル、iSCSI LUN、または多くの小さいファイル) で構成され、常に書き換えがある場合、90% ルールに厳しく従うようにします。
すべてのデータが小さいブロックで、常に書き換えが行われている場合、容量が 80% を超えたらプールをしっかりモニターします。監視する兆候は、同じレベルのクライアント IOPS を達成するためにディスク IOPS が増加していることです
ランダムな読み取り/書き込み作業負荷の場合、RAID-Z プールにわたるミラー化プールをお勧めします
個別のログデバイス
同期書き込みパフォーマンスを高めるために推奨されています
同期書き込み負荷が高い場合でも、メインプール内の多数のログブロックに書き込むことでの断片化を防ぎます
読み取りパフォーマンスを高めるには、個別のキャッシュデバイスをお勧めします
スクラブ/再同期化 - 多数のデバイスで構成される非常に大きな RAID-Z プールは、スクラブや再同期化の時間が長くなります
プールパフォーマンスが低い – zpool status コマンドを使用して、プールのパフォーマンス問題の原因となっているハードウェアの問題を排除します。zpool status コマンドで問題が現れない場合は、fmdump コマンドを使用して、ハードウェアの障害を表示するか、fmdump –eV コマンドを使用して、報告された障害にはまだなっていないハードウェアエラーを確認します。
パフォーマンスを最適にするために、必ずプール容量が 90% を下回るようにします。
ビジー状態のメールサーバー上など、プールがいっぱいでファイルシステムが頻繁に更新されるときは、プールパフォーマンスが低下する可能性があります。プールがいっぱいになると、パフォーマンスペナルティーが発生することがありますが、それ以外の問題は発生しません。主要な作業負荷が不変のファイルの場合は、プール使用率の範囲を 95 - 96% に維持してください。95 - 96% の範囲のほとんど静的なコンテンツでも、書き込み、読み取り、および再同期のパフォーマンスが低下することがあります。
プールとファイルシステムの容量をモニターして、それらがいっぱいにならないようにします。
ZFS の割り当て制限と予約を使用して、ファイルシステムの容量がプール容量の 90% を超えないようにすることを検討します。
プールの健全性をモニターします
冗長プールを少なくとも週に一度、zpool status および fmdump でモニターします
冗長でないプールを少なくとも週に二度、zpool status および fmdump でモニターします
zpool scrub を定期的に実行して、データ整合性の問題を特定します。
消費者品質のドライブがある場合は、スクラブを週に 1 度行うスケジュールを考えます。
データセンター品質のドライブがある場合は、スクラブを月に 1 度行うスケジュールを考えます。
デバイスを交換する前やプールの冗長性を一時的に下げる前にもスクラブを実行して、すべてのデバイスが現在運用可能であることを確認するようにしてください。
プールまたはデバイス障害のモニタリング - 下記のように zpool status を使用します。また、fmdump または fmdump -eV を使用して、デバイスの障害またはエラーが発生しているかどうかを調べます。
冗長プールの場合は、zpool status および fmdump を使用して、週単位でプールの健全性をモニターします
冗長でないプールの場合は、zpool status および fmdump を使用して、週に二度プールの健全性をモニターします
プールデバイスが UNAVAIL または OFFLINE である – プールデバイスが使用できない場合、そのデバイスが format コマンド出力に一覧表示されているかどうかを確認します。デバイスが format 出力に一覧表示されていない場合、デバイスは ZFS に認識されていません。
プールデバイスが UNAVAIL または OFFLINE である場合、これは通常、デバイスに障害があったりケーブルが切断されていたりすること、または、不良ケーブルや不良コントローラなど、ほかのハードウェアの問題が原因でデバイスにアクセスできないことを示します。
ハードウェアコンポーネントが欠陥があると診断されたときに通知するように、smtp-notify サービスを構成することを検討してください。詳細は、smf(7)の通知パラメーターのセクションおよび smtp-notify(8) のマニュアルページを参照してください。
デフォルトで、いくつかの通知が root ユーザーに送信されるように自動的に設定されます。/etc/aliases ファイルでユーザーアカウントの別名を root として追加した場合は、次のような情報を含む電子メール通知を受け取ります。
SUNW-MSG-ID: ZFS-8000-8A, TYPE: Fault, VER: 1, SEVERITY: Critical EVENT-TIME: Fri Jun 29 16:58:58 MDT 2012 ... SOURCE: zfs-diagnosis, REV: 1.0 EVENT-ID: 76c2d1d1-4631-4220-dbbc-a3574b1ee807 DESC: A file or directory in pool 'pond' could not be read due to corrupt data. AUTO-RESPONSE: No automated response will occur. IMPACT: The file or directory is unavailable. REC-ACTION: Use 'fmadm faulty' to provide a more detailed view of this event. Run 'zpool status -xv' and examine the list of damaged files to determine what has been affected. Please refer to the associated reference document at http://support.oracle.com/msg/ZFS-8000-8A for the latest service procedures and policies regarding this diagnosis.
ストレージプール容量をモニターする – zpool list コマンドと zfs list コマンドを使用して、ファイルシステムデータによってどれだけのディスクが消費されたかを特定します。ZFS スナップショットがディスク容量を消費する可能性があります。zfs list コマンドで ZFS スナップショットが一覧表示されない場合、認識されずにディスクを消費していることがあります。zfs list – t スナップショットコマンドを使用して、スナップショットが消費するディスク容量を特定します。