ZFS ストレージプールの推奨される実践法

ZFS では、複数のストレージデバイスが 1 つのストレージプールに集約されるプール型ストレージモデルを使用します。ストレージプール内のファイルシステムは、プール内のすべてのストレージを使用します。

次の各セクションでは、ZFS ストレージプールの作成、監視、およびトラブルシューティングの推奨される実践法について説明します。

ZFS ストレージプール作成のプラクティス

ルートプール – s* 識別子を使用してスライスが含まれるプールを作成します。p* 識別子を使用しないでください。通常、システムの ZFS ルートプールは、システムがインストールされるときに作成されます。2 つめのルートプールを作成するか、またはルートプールを再作成する場合は、次のような構文を使用します。
```
# zpool create rpool c0t1d0s0
```
あるいは、ミラー化ルートプールを作成します。例:
```
# zpool create rpool mirror c0t1d0s0 c0t2d0s0
```
- ルートプールのコンポーネントをルート以外のプールのデータと分けておくことを考えてください。
- ルートプールは、ミラー化構成または単一ディスク構成として作成する必要があります。RAID-Z やストライプ化構成はサポートされていません。zpool add コマンドを使って、追加ディスクを追加して複数のミラー化された最上位レベル仮想ディスクを作成することはできませんが、ミラー化された仮想デバイスを zpool attach コマンドを使って拡張することは可能です。
- ルートプールに別個のログデバイスを使用することはできません。
- pool_options キーワード構文を使用して、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) でシングルパリティーの RAIDZ (raidz) 構成を作成します。
  - RAIDZ-2 構成はより優れたデータ可用性を提供し、RAID-Z と同様に動作します。RAIDZ-2 は、RAID-Z または 2 ウェイミラーよりも平均データ損失時間 (MTTDL) が大幅に優れています。6 台のディスク (4+2) でダブルパリティーの RAID-Z (raidz2) 構成を作成します。
  - RAIDZ-3 構成では、ディスク容量が最大となり、3 台のディスク障害に耐えられるため、優れた可用性が提供されます。8 台のディスク ((5+3) でトリプルパリティーの RAID-Z (raidz3) 構成を作成します。
冗長性のないプール – 冗長性のないプールを作成する場合は、次のようなメッセージが表示されます。
```
# zpool create pond c8t2d0 c8t3d0
'pond' successfully created, but with no redundancy; failure of one
device will cause loss of the pool
```
デバイス障害はデータが回復不可能であることを意味することがあるため、冗長性のないプールの作成は推薦されていません。冗長性のある ZFS ストレージプールの作成を考えてください。例:
```
# zpool create pond mirror c8t2d0 c8t3d0
```

ZFS ストレージプールの監視の実践法

パフォーマンスを最適にするために、必ずプール容量が 80% を下回るようにします。プールとファイルシステムの容量を監視して、それらがいっぱいにならないようにします。ZFS の割り当て制限と予約を使用して、ファイルシステムの容量がプール容量の 80% を超えないようにすることを検討します。
zpool scrub を定期的に実行して、データの完全性に関する問題を特定します。
- 消費者品質のドライブがある場合は、スクラブを週に 1 度行うスケジュールを考えます。
- データセンター品質のドライブがある場合は、スクラブを月に 1 度行うスケジュールを考えます。
- また、デバイスを交換する場合は、その前にスクラブを実行して、すべてのデバイスが現在動作していることを確認する必要があります。
zpool status を毎週使用して、プールとプールデバイスのステータスを監視します。また、fmdump または fmdump -eV を使用して、デバイスの障害またはエラーが発生しているかどうかを調べます。

ZFS ストレージプールのトラブルシューティングの実践法

Oracle Solaris 11 でプールの問題をトラブルシューティングすることは、Oracle Solaris 10 リリースで問題を診断することに似ていますが、診断に関する次の新しい説明と特徴を確認してください。

障害の発生したデバイス – zpool status -l の出力を確認して障害の発生したデバイスの物理的な位置を特定し、それを交換します。障害の発生したディスクの交換については、『Oracle Solaris の管理: ZFS ファイルシステム』の「破損したデバイスを交換または修復する」を参照してください。

障害の発生したデバイスの通知 – ハードウェアコンポーネントが障害と診断された場合など、さまざまな障害管理イベントに応えて電子メール通知を送信するように smtp-notify サービスを構成できます。詳細は、smf(5) の通知パラメータのセクションを参照してください。

デフォルトでは、いくつかの通知は 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.

デバイスの移動 – ZFS ストレージプールの一部であるデバイスには、デバイス ID が含まれています (デバイスドライバでデバイス ID が作成されたか、または組み立てられた場合)。すべてのファイルシステムと同様に、ZFS はそのベースとなるデバイスと非常に密接な関係があるため、システムのファームウェアのアップグレード、別のコントローラへのプールデバイスの移動、またはデバイスの配線の変更を試みる場合は、最初にそのプールのエクスポートを考慮してもかまいません。デバイス ID がデバイスの変更に付随せず、これが Oracle 以外のハードウェアで起こることがある場合、そのプールとプールデータは使用できなくなる可能性があります。通常、Oracle のドライバはデバイス ID を完全にサポートしているため、デバイスがライブプールのもとで変更された場合、Oracle の Sun ハードウェアは回復できます。しかし、ハードウェアの変更を行う前に、プールのエクスポートを考慮してもかまいません。

プールの問題のトラブルシューティングの詳細は、『Oracle Solaris の管理: ZFS ファイルシステム』の第 11 章「Oracle Solaris ZFS のトラブルシューティングとプールの回復」を参照してください。

ナビゲーションリンクをスキップ
印刷ビューの終了
	Oracle Solaris 10 から Oracle Solaris 11 への移行 Oracle Solaris 11 Information Library (日本語)