ボリューム管理の計画

「デバイスグループ構成のワークシート」と 「ボリューム管理ソフトウェア構成のワークシート」に次の計画情報を追加してください。Solaris ボリュームマネージャー の場合は 「ボリュームのワークシート (Solaris ボリュームマネージャー)」にもこの情報を追加してください。

この節では、クラスタ構成のボリューム管理を計画する上でのガイドラインについて説明します。

• 「ボリューム管理ソフトウェアのガイドライン」

• 「Solaris ボリュームマネージャー ソフトウェアのガイドライン」

• 「Veritas Volume Manager ソフトウェアのガイドライン」

• 「ファイルシステムのロギング」

• 「ミラー化に関するガイドライン」

Oracle Solaris Cluster は、ボリューム管理ソフトウェアを使用して、ディスクをデバイスグループにまとめ、1 つの単位で管理できるようにします。Oracle Solaris Cluster ソフトウェアは、次の方法でインストールまたは使用する Solaris ボリュームマネージャー ソフトウェアと Veritas Volume Manager (VxVM) ソフトウェアをサポートします。

表 1-4 サポートされているボリューム管理ソフトウェアと Oracle Solaris Cluster ソフトウェアの使用

ボリュームマネージャーソフトウェアのインストールと構成の方法については、ボリュームマネージャーのドキュメントおよび 「Solaris ボリュームマネージャー ソフトウェアの構成」または 「VxVM ソフトウェアのインストールと構成」を参照してください。クラスタ構成でのボリューム管理の使用については、『Oracle Solaris Cluster Concepts Guide』の「Multihost Devices」および『Oracle Solaris Cluster Concepts Guide』の「Device Groups」を参照してください。

ボリューム管理ソフトウェアのガイドライン

ボリューム管理ソフトウェアでディスクを構成する際は、次の一般的なガイドラインを考慮してください。

• ソフトウェア RAID – Oracle Solaris Cluster ソフトウェアは、ソフトウェア RAID 5 をサポートしていません。

• ミラー化多重ホストディスク – すべての多重ホストディスクは、複数のディスク拡張装置にまたがるようにミラー化する必要があります。ミラー化多重ホストディスクのガイドラインについては、「多重ホストディスクのミラー化」を参照してください。ストレージデバイスがハードウェア RAID とデバイスへの冗長パスを提供する場合は、ソフトウェアミラー化を使用する必要はありません。

• ミラー化ルート – ルートディスクをミラー化することにより高可用性を保証できますが、このようなミラー化は必要ありません。ルートディスクをミラー化するかどうかを判断する際のガイドラインについては、「ミラー化に関するガイドライン」を参照してください。

• 一意の命名 – /global/.devices/node@nodeid ファイルシステムがマウントされるデバイスとして使用されるローカル Solaris ボリュームマネージャー または VxVM ボリュームが存在している可能性があります。この場合、/global/.devices/node@nodeid ファイルシステムがマウントされる各ローカルボリュームの名前は、クラスタ全体で一意になるようにしてください。

• ノードリスト – デバイスグループの高可用性を実現するには、これらの潜在マスターのノードリストとフェイルバックポリシーを、関連付けられているリソースグループと同一にします。または、スケーラブルなリソースグループで、それと関連付けられているデバイスグループ以上のノードが使用されている場合、スケーラブルなリソースグループのノードリストをデバイスグループのノードリストのスーパーセットにします。ノードリストについては、『Oracle Solaris Cluster Data Services Planning and Administration Guide 』のリソースグループの計画情報を参照してください。

• 多重ホストディスク – デバイスグループを構成するために使用されるすべてのデバイスを、そのデバイスグループのノードリストに構成されているすべてのノードに接続、つまりポートする必要があります。Solaris ボリュームマネージャー ソフトウェアは、ディスクセットにデバイスを追加したときに、この接続を自動的に確認します。しかし、構成した VxVM ディスクグループは、ノードの特定のセットには関連を持ちません。

• ホットスペアディスク – ホットスペアディスクは、可用性を高めるために使用できますが、必須ではありません。

ディスクの配置の推奨事項とその他の制限については、ボリューム管理ソフトウェアのドキュメントを参照してください。

Solaris ボリュームマネージャー ソフトウェアのガイドライン

Solaris ボリュームマネージャー の構成を計画する際は、次の点を考慮してください。

• ローカルボリューム名 – グローバルデバイスファイルシステム /global/.devices/node@ nodeid がマウントされる各ローカル Solaris ボリュームマネージャー ボリュームの名前は、クラスタ全体で一意になるようにします。また、その名前はどのデバイス ID (DID) 名とも同じであってはなりません。

• 二重列メディエータ – ディスク列は、ディスク格納装置、その物理ディスク、格納装置から 1 つまたは複数のホストへのケーブル、およびインタフェースアダプタカードで構成されます。 正確に 2 つのディスク列で構成され、正確に 2 つの Solaris ホストによってマスターされる各ディスクセットは、二重列ディスクセットと呼ばれます。 そのようなディスクセットでは、Solaris ボリュームマネージャー の二重列メディエータが構成されている必要があります。 二重列メディエータの構成時には、次の規則に従ってください。

  • 各ディスクセットは、メディエータホストとして機能する 2 つまたは 3 つのホストで構成します。

  • そのディスクセットのメディエータとして、ディスクセットをマスターできるホストを使用する必要があります。 キャンパスクラスタがある場合は、可用性を向上させるために、3 つ目のノードまたはクラスタネットワーク上の非クラスタホストを 3 つ目のメディエータホストとして構成することもできます。

  • メディエータは、列およびホストが 2 つずつという要件を満たしていないディスクセットに対しては構成できません。

  詳細は、mediator(7D)のマニュアルページを参照してください。

Veritas Volume Manager ソフトウェアのガイドライン

Veritas Volume Manager (VxVM) の構成を計画する際は、次の点を考慮してください。

• ノードへのアクセシビリティー - すべてのボリュームマネージャーディスクグループを、Oracle Solaris Cluster デバイスグループまたはローカルのみのディスクグループとして構成します。これらの方法のいずれかでディスクグループを構成しない場合、クラスタ内のどのノードからもディスクグループ内のデバイスにアクセスできなくなります。

  • デバイスグループは、主ノードに障害が発生した場合、2 つ目のノードで多重ホストディスクをホストできます。

  • ローカルのみのディスクグループは、Oracle Solaris Cluster ソフトウェアの制御外で機能し、1 度に 1 ノードからのみアクセスできます。

• 筐体ベースのネーミング –デバイスの筐体ベースのネーミング (Enclosure-Based Naming) を使用する場合、必ず、同じストレージを共有するすべてのクラスタノードにおいて整合性のあるデバイス名を使用してください。VxVM はこのような名前を調節しないため、VxVM が各ノードから同じデバイスに同じ名前を割り当てているかどうかは、管理者が確認する必要があります。整合性のある名前を割り当てなくても、クラスタの動作に悪影響はありません。ただし、整合性のない名前だと、クラスタの管理が極端に複雑になり、構成エラーが発生し、データが失われる可能性が高くなります。

• ルートディスクグループ – ルートディスクグループの作成は任意です。

  ルートディスクグループは次のディスク上に作成できます。

  • ルートディスク (カプセル化されている必要がある)

  • ルート以外の 1 つまたは複数のローカルディスク (カプセル化または初期化できるもの)

  • ルートディスクとルート以外のローカルディスクの組み合わせ

  ルートディスクグループは、Solaris ホストに対してローカルである必要があります。

• 簡易ルートディスクグループ – ルートディスクの 1 つのスライスに作成される簡易ルートディスクグループは、Oracle Solaris Cluster ソフトウェア上で VxVM によるディスクタイプとしてサポートされません。これは、VxVM ソフトウェアの一般的な制限です。

• カプセル化 – カプセル化するディスクでは、2 つのディスクスライステーブルエントリを空にしておく必要があります。

• ボリューム数 – ディスクデバイスグループを作成するときに任意のディスクデバイスグループが使用できるボリュームの最大数を確認します。

  • ボリューム数が 1000 未満の場合は、デフォルトのミラー数を使用できます。

  • ボリューム数が 1000 以上の場合は、デバイスグループボリュームへのマイナー番号の割り当て方を慎重に計画する必要があります。2 つのデバイスグループに、オーバーラップするマイナー番号を割り当てることはできません。

• ダーティリージョンログ – ダーティリージョンロギング (DRL) を使用すると、ノードに障害が発生した後に、ボリュームの回復時間を短縮できます。また、DRL を使用することで入出力のスループットを低減できることがあります。

• Dynamic Multipathing (DMP) – DMP だけを使用して、Solaris ホストごとに共有記憶装置への複数の I/O パスを管理することはサポートされていません。DMP を使用できるのは、次の構成だけです。

  • クラスタの共有ストレージに対してホストごとに I/O パスが 1 つだけ構成されている。

  • 共有クラスタストレージに対してホストごとに複数の I/O パスを管理する、サポート対象のマルチパスソリューション (Solaris I/O マルチパス ソフトウェア (MPxIO) や EMC PowerPath など) が使用されている。

• ZFS – Root ディスクのカプセル化は、ZFS root ファイルシステムと互換性がありません。

詳細については、 VxVM のインストールドキュメントを参照してください。

ファイルシステムのロギング

UFS および VxFS クラスタファイルシステムには、ロギングが必要です。Oracle Solaris Cluster ソフトウェアでは、ファイルシステムのロギングの方法として、次がサポートされています。

• Solaris UFS ロギング: 詳細は、mount_ufs(1M) のマニュアルページを参照してください。

• SPARC: Veritas File System (VxFS) ロギング – 詳細は、VxFS ソフトウェアに付属の mount_vxfs のマニュアルページを参照してください。

Solaris ボリュームマネージャー と Veritas Volume Manager は、どちらも両方の種類のファイルシステムのロギングをサポートしています。

ミラー化に関するガイドライン

この節では、クラスタ構成のミラー化を計画する際のガイドラインについて説明します。

• 「多重ホストディスクのミラー化」

• 「ルートディスクのミラー化」

多重ホストディスクのミラー化

Oracle Solaris Cluster 構成内のすべての多重ホストディスクをミラー化することにより、この構成で単一デバイスの障害を許容できるようになります。 Oracle Solaris Cluster ソフトウェアでは、すべての多重ホストディスクは、複数の拡張装置にまたがるようにミラー化する必要があります。ストレージデバイスがハードウェア RAID とデバイスへの冗長パスを提供する場合は、ソフトウェアミラー化を使用する必要はありません。

多重ホストディスクをミラー化する際は、次の点を考慮してください。

• 独立したディスク拡張装置 – ミラーまたはプレックスのサブミラーは、それぞれ異なる多重ホスト拡張装置に分散してください。

• ディスク領域 – ミラー化すると、2 倍のディスク領域が必要になります。

• 3 方向のミラー化 – Solaris ボリュームマネージャー ソフトウェアと Veritas Volume Manager (VxVM) は、3 方向のミラー化をサポートしています。ただし、Oracle Solaris Cluster ソフトウェアが必要とするのは、2 方向のミラー化だけです。

• 異なるデバイスサイズ – 異なるサイズのデバイスにミラーを作成した場合、ミラーの容量は、最小のサブミラーまたはプレックスのサイズに制限されます。

マルチホストディスクの詳細は、『Oracle Solaris Cluster Concepts Guide』の「Multihost Devices」を参照してください。

ルートディスクのミラー化

「ローカルファイルシステム配置のワークシート」に、次の計画情報を追加してください。

最高の可用性を得るには、ローカルディスク上のルート (/)、/usr、/var、/opt、swap をミラー化してください。VxVM では、ルートディスクをカプセル化し、生成されたサブディスクをミラー化します。ただし、Oracle Solaris Cluster ソフトウェアでは、ルートディスクのミラー化を要求しません。

ルートディスクをミラー化するかどうかを決定する前に、危険性、複雑さ、コスト、保守時間の面から、ルートディスクに関するさまざまな方法を検討してください。どの構成でも有効に機能するというような汎用的なミラー化はありません。ルートをミラー化するかどうかを決定する際は、ご購入先に相談してください。

ルートディスクのミラー化の手順については、ボリュームマネージャーのドキュメントおよび 「Solaris ボリュームマネージャー ソフトウェアの構成」または 「VxVM ソフトウェアのインストールと構成」を参照してください。

ルートディスクをミラー化するかどうかを決定する際は、次のことを考慮してください。

• 起動ディスク – 起動可能ルートディスクをミラーとして設定できます。主起動ディスクに障害が発生した場合に、ミラーから起動できます。

• 複雑さ – ルートディスクをミラー化すると、システム管理の複雑さが増します。また、シングルユーザーモードでの起動も複雑になります。

• バックアップ – ルートディスクをミラー化するかどうかに関係なく、ルートは定期的にバックアップしてください。ミラー化だけで、管理上の誤りが防げるわけではありません。誤って変更あるいは削除したファイルは、バックアップによってのみ復元できます。

• 定足数 (Quorum) デバイス – 定足数デバイスとして構成されたディスクは、ルートディスクのミラー化に使用しないでください。

• 定足数 (Quorum) – Solaris ボリュームマネージャー ソフトウェアの構成で、状態データベースの定足数が失われるという障害が発生した場合は、保守を行わない限り、システムを再起動できなくなります。状態データベースと状態データベースの複製の詳細については、Solaris ボリュームマネージャー のドキュメントを参照してください。

• 独立したコントローラ – 独立したコントローラにルートディスクをミラー化するという方法は、最高の可用性を得る手段の 1 つです。

• 二次ルートディスク – ミラー化したルートディスクを使用すると、主ルートディスクに障害が発生しても、二次 (ミラー) ルートディスクで動作を継続できます。その後、主ルートディスクは、電源を入れ直すか、一時的な入出力エラーの後に、正常に戻ることがあります。以降の起動は、eeprom(1M) boot-device パラメータに指定された主ルートディスクを使用して行われます。このような場合、手作業による修復作業は発生しませんが、起動に問題がないようにドライブは動作を開始します。Solaris ボリュームマネージャー ソフトウェアでは、再同期が行われます。再同期をするには、ドライブが正常に戻ったときに手作業が必要になります。

  二次 (ミラー) ルートディスク上のファイルが変更された場合、起動中に、その変更が主ルートディスクに反映されることはありません。これにより古いサブミラーが生じます。たとえば、/etc/system ファイルに対する変更が失われることがあります。Solaris ボリュームマネージャー ソフトウェアでは、主ルートディスクが休止している間に、一部の管理コマンドによって /etc/system ファイルが変更されることがあります。

  起動プログラムは、システムがミラーまたは元の物理デバイスのどちらから起動されているのかを確認しません。起動プロセスの途中 (ボリュームが読み込まれたあと) でミラー化はアクティブになります。これより前の時点で、古いサブミラー問題が発生しやすくなります。