ボリューム管理の計画

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

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

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

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

• 「ミラー化のガイドライン」

Oracle Solaris Cluster ソフトウェアは、ボリュームマネージャーソフトウェアを使用して、1 つの単位として管理できるデバイスグループにディスクをまとめます。Oracle Solaris Cluster ソフトウェアは Solaris Volume Manager ソフトウェアをサポートしています。クラスタのすべての投票ノードに Solaris Volume Manager ソフトウェアをインストールする必要があります。

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

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

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

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

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

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

• 一意の名前付け – /global/.devices/node@ nodeid ファイルシステムがマウントされるデバイスとして使用されるローカル Solaris Volume Manager ボリュームを持っている可能性があります。その場合は、/global/.devices/node@ nodeid ファイルシステムがマウントされる各ローカルボリュームの名前は、クラスタ全体で一意である必要があります。

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

• 多重ホストディスク – デバイスグループを構成するために使用されるすべてのデバイスを、そのデバイスグループのノードリストに構成されているすべてのノードに接続、つまりポートする必要があります。Solaris Volume Manager ソフトウェアは、ディスクセットにデバイスが追加されたときに、この接続を自動的に確認できます。

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

ディスクレイアウトの推奨事項とその他の制限については、ボリュームマネージャーのドキュメントを参照してください。

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

Solaris Volume Manager の構成を計画する場合は、次の点を考慮してください。

• ローカルボリューム名 – グローバルデバイスファイルシステム /global/.devices/node@nodeid がマウントされている各ローカル Solaris Volume Manager ボリュームの名前は、クラスタ全体で一意である必要があります。また、名前はどのデバイス ID 名とも同じにはできません。

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

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

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

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

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

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

UFS クラスタファイルシステムではロギングが必要です。Oracle Solaris Cluster ソフトウェアは Oracle Solaris の UFS ロギングをサポートしています。詳細については、mount_ufs(1M) のマニュアルページを参照してください。

Solaris Volume Manager は両方の種類のファイルシステムロギングをサポートします。

ミラー化のガイドライン

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

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

• 「ルートディスクのミラー化に関するガイドライン」

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

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

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

• 独立したディスク拡張装置 – ミラーのサブミラーは、それぞれ異なる多重ホスト拡張装置に配置するようにしてください。

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

• 3 方向のミラー化 – Solaris Volume Manager ソフトウェアは 3 方向のミラー化をサポートしています。ただし、Oracle Solaris Cluster ソフトウェアが必要とするのは、2 方向のミラー化だけです。

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

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

ルートディスクのミラー化に関するガイドライン

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

ルートディスクをミラー化するかどうかを決定する前に、ルートディスクに関するさまざまな代替方法のリスク、複雑さ、コスト、およびサービス時間について検討してください。単一のミラー化方法ですべての構成に対応できるものはありません。ルートをミラー化するかどうかを決定するときには、地域の Oracle サービス担当者が推奨する解決案を検討することもできます。

ルートディスクをミラー化する方法については、ボリュームマネージャーのドキュメントと「 Solaris Volume Manager ソフトウェアの構成」を参照してください。

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

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

• 複雑さ – ルートディスクをミラー化すると、システム管理がさらに複雑になります。ルートディスクのミラー化によって、単一ユーザーモードでのブートも複雑になります。

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

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

• 定足数 – Solaris Volume Manager ソフトウェアでは、状態データベース定足数が失われるような障害が発生した場合、保守が行われるまでシステムをリブートできません。状態データベースと状態データベースの複製については、Solaris Volume Manager のドキュメントを参照してください。

• 独立したコントローラ – 最高の可用性には、独立したコントローラにルートディスクをミラー化する方法もあります。

• セカンダリルートディスク – ミラー化したルートディスクを使用すれば、プライマリルートディスクに障害が発生しても、セカンダリ (ミラー) ルートディスクで作業を継続できます。たとえば電源を入れ直した場合や、一過性の入出力エラーの場合に、プライマリルートディスクがあとから正常に戻る場合があります。以降のブートは、eeprom(1M) boot-device パラメータに指定されたプライマリルートディスクを使用して行われます。この場合、手動による修復タスクは行われませんが、ドライブは動作を開始し、ブートすることができます。Solaris Volume Manager ソフトウェアでは、再同期が行われます。再同期では、ドライブが正常に戻ったときに、手動の手順を行う必要があります。

  セカンダリ (ミラー) ルートディスクのいずれかのファイルに変更が行われた場合、ブート時に、その変更がプライマリルートディスクに反映されることはありません。この状況により、サブミラーが古くなります。たとえば、/etc/system ファイルに加えた変更が失われる場合があります。Solaris Volume Manager ソフトウェアでは、プライマリルートディスクが停止している間に、管理コマンドによって /etc/system ファイルが変更された場合があります。

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