Sun Cluster ソフトウェアのインストール (Solaris OS 版)

ボリューム管理の計画

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

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

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

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


ボリューム管理ソフトウェア	要件
Solaris ボリュームマネージャー	一部のノードで VxVM を使用してディスクを管理する場合でも、クラスタのすべてのノードに Solaris ボリュームマネージャーソフトウェアをインストールする必要があります。
SPARC: VxVM とクラスタ機能	クラスタのすべてのノード上に、クラスタ機能を持つ VxVM をインストールして、それらにライセンスを付与する必要があります。
クラスタ機能を持たない VxVM	VxVM は、VxVM が管理する記憶装置に接続されているノードにのみインストールして、それらにライセンスを付与します。
Solaris ボリュームマネージャーと VxVM	これらのボリューム管理ソフトウェアを同じノードにインストールする場合は、Solaris ボリュームマネージャーソフトウェアを使用して、各ノードにローカルに接続されているディスクを管理します。ルートディスクもローカルディスクに含まれます。VxVM を使用して、すべての共有ディスクを管理します。

ボリュームマネージャーソフトウェアのインストールと構成の方法については、ボリュームマネージャーのマニュアルおよび「Solaris ボリュームマネージャーソフトウェアの構成」または「VxVM ソフトウェアのインストールと構成」を参照してください。クラスタ構成でのボリューム管理の使用の詳細は、『Sun Cluster の概念 (Solaris OS 版)』の「多重ホストデバイス」と『Sun Cluster の概念 (Solaris OS 版)』の「デバイスグループ」を参照してください。

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

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

ソフトウェア RAID – Sun Cluster ソフトウェアはソフトウェア RAID 5 をサポートしていません。
ミラー化多重ホストディスク – すべての多重ホストディスクは、複数のディスク拡張装置にまたがるようにミラー化する必要があります。ミラー化多重ホストディスクのガイドラインについては、「多重ホストディスクのミラー化」を参照してください。ストレージデバイスがハードウェア RAID とデバイスへの冗長パスを提供する場合は、ソフトウェアミラー化を使用する必要はありません。
ミラー化ルート – ルートディスクをミラー化することにより高可用性を保証できますが、このようなミラー化は必要ありません。ルートディスクをミラー化するかどうかを判断する際のガイドラインについては、「ミラー化に関するガイドライン」を参照してください。
一意の命名 – /global/.devices/node@nodeid ファイルシステムがマウントされるデバイスとして使用される、ローカル Solaris ボリュームマネージャーまたは VxVM ボリュームがある可能性があります。この場合、/global/.devices/node@nodeid ファイルシステムがマウントされるローカルボリュームのそれぞれは、クラスタ全体で一意である必要があります。
ノードリスト –デバイスグループの高可用性を実現するには、それらの潜在マスターのノードリストとフェイルバックポリシーを、関連付けられているリソースグループと同一にします。または、スケーラブルなリソースグループで、それと関連付けられているデバイスグループ以上のノードまたはゾーンが使用されている場合、スケーラブルなリソースグループのノードリストをデバイスグループのノードリストのスーパーセットにします。ノードリストの詳細は、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』のリソースグループの計画情報を参照してください。
多重ホストディスク – デバイスグループを構成するために使用されるすべてのデバイスを、そのデバイスグループのノードリストに構成されているすべてのノードに接続、つまりポートする必要があります。Solaris ボリュームマネージャーソフトウェアは、ディスクセットにデバイスを追加したときに、この接続を自動的に確認します。しかし、構成した VxVM ディスクグループは、ノードの特定のセットには関連を持ちません。
ホットスペアディスク – ホットスペアディスクは、可用性を高めるために使用できますが、必須ではありません。

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

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

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

ローカルボリューム名 – グローバルデバイスファイルシステム /global/.devices/node@nodeid がマウントされる各ローカル Solaris ボリュームマネージャーボリューム名は、クラスタ全体で一意になるようにする必要があります。また、その名前はどのデバイス ID (DID) 名とも同じであってはなりません。
二重列メディエータ – 2 つの列だけで構成されていて、2 つのノードでマスターされている各ディスクセットでは、そのディスクセット用に構成されている Solaris ボリュームマネージャーメディエータを使用する必要があります。列は、ディスク格納装置、その物理ディスク、格納装置から 1 つまたは複数のノードへのケーブル、インタフェースアダプタカードで構成されます。二重列メディエータの構成には、次の規則に従ってください。
- 各ディスクセットは、メディエータホストとして機能する 2 つのノードで構成します。
- メディエータを必要とするすべてのディスクセットに対して、2 つの同じノードを使用する必要があります。これら 2 つのノードがディスクセットをマスターする必要があります。
- メディエータは、列およびホストが 2 つずつという要件を満たしていないディスクセットに対しては構成できません。
詳細は、mediator(7D) のマニュアルページを参照してください。
/kernel/drv/md.conf 設定 – SPARC: Solaris 9 OS では、それぞれのディスクセットが使用する Solaris ボリュームマネージャーボリュームは、再構成起動時にあらかじめ作成されます。再構成は、/kernel/drv/md.conf ファイルに含まれる構成パラメータに基づいています。

注 –
Solaris 10 リリースで、Solaris ボリュームマネージャーはボリュームを動的に構成するように拡張されました。/kernel/drv/md.conf ファイルの nmd パラメータと md_nsets パラメータを編集しなくてすみます。新しいボリュームは必要に応じて作成されます。

Solaris 9 OS で Sun Cluster 構成をサポートするには、nmd および md_nsets フィールドを次のように変更する必要があります。

注意 –
すべてのクラスタノードの /kernel/drv/md.conf ファイルの内容は、それぞれのノードがサービスを提供するディスクセット数に関係なく、同一である必要があります。このガイドラインに従わないと、重大な Solaris ボリュームマネージャーエラーが発生し、データが失われることがあります。
- md_nsets – md_nsets フィールドは、システムでクラスタ全体のニーズを満たすために作成できるディスクセットの合計数を定義できます。md_nsets の値は、クラスタ内で予想されるディスクセットの数に 1 を加えた値に設定します。Solaris ボリュームマネージャーソフトウェアは、追加のディスクセットを使用して、ローカルホスト上のプライベートディスクを管理します。
  
  1 つのクラスタで使用できるディスクセットの最大数は 32 です。32 のうち、31 ディスクセットは一般的な使用のためで、1 ディスクセットは、プライベートディスクの管理用に使われます。md_nsets のデフォルト値は 4 です。
- nmd – nmd フィールドは、クラスタに存在するすべてのボリューム名のうち、予想される最大値を定義します。たとえば、あるクラスタの 15 番目までのディスクセットで使用されるボリューム名の最大数が 10 であるが、16 番目のディスクセットで使用されるボリュームの最大数が 1000 である場合、nmd の値を 1000 以上に設定します。また、nmd の値は各デバイス ID 名に十分な数を保証する大きさである必要があります。この値は、各ローカルボリューム名がクラスタ全体で一意になるように十分に大きな値を設定してください。
  
  1 つのディスクセットで使用できるボリューム名の最大数は 8192 です。nmd のデフォルト値は 128 です。
インストール時、これら 2 つのフィールドに、将来予想されるクラスタの拡張を考慮した値を設定してください。クラスタの使用を開始した後で、これらのフィールド値を増やそうとすると、時間がかかります。値を変更すると、すべてのノードで再構成再起動が必要になるからです。また、後でこれらの値を増やす場合、要求されたデバイスを作成するには、ルート (/) ファイルシステムに確保された領域では不十分という可能性が高まります。

同時に、nmd フィールドおよび md_nsets フィールドには、できる限り小さい値を使用してください。デバイスを作成していなくても nmd および md_nsets によって指定された値に基づいて、可能性のあるすべてのデバイス分をメモリー構造上に確保します。最適なパフォーマンスを得るには、nmd と md_nsets の値を、使用するボリュームの数よりもわずかに高く維持します。

md.conf ファイルの詳細は、『Solaris ボリュームマネージャの管理』 (Solaris 9 または Solaris 10) の「システムファイルと始動ファイル」を参照してください。

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

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

ノードへのアクセシビリティー - すべてのボリュームマネージャーディスクグループを、Sun Cluster デバイスグループまたはローカルのみのディスクグループとして構成する必要があります。これらの方法のいずれかでディスクグループを構成しない場合、クラスタ内のどのノードからもディスクグループ内のデバイスにアクセスできなくなります。
- デバイスグループは、主ノードに障害が発生した場合、2 つ目のノードで多重ホストディスクをホストできます。
- ローカルのみのディスクグループは、Sun Cluster ソフトウェアの制御外で機能し、1 度に 1 ノードからのみアクセスできます。
筐体ベースのネーミング –デバイスの筐体ベースのネーミング (Enclosure-Based Naming) を使用する場合、必ず、同じストレージを共有するすべてのクラスタノードにおいて整合性のあるデバイス名を使用してください。VxVM はこのような名前を調節しないため、VxVM が各ノードから同じデバイスに同じ名前を割り当てているかどうかは、管理者が確認する必要があります。整合性のある名前を割り当てなくても、クラスタの動作に悪影響はありません。ただし、整合性のない名前だと、クラスタの管理が極端に複雑になり、構成エラーが発生し、データが失われる可能性が高くなります。
ルートディスクグループ – ルートディスクグループの作成は任意です。

ルートディスクグループは次のディスク上に作成できます。
- ルートディスク (カプセル化されている必要がある)
- ルート以外の 1 つまたは複数のローカルディスク (カプセル化または初期化できるもの)
- ルートディスクとルート以外のローカルディスクの組み合わせ
ルートディスクグループは、ノードに対してローカルである必要があります。
簡易ルートディスクグループ – 簡易ルートディスクグループ (ルートディスクの 1 つのスライスに作成される rootdg) は、Sun Cluster ソフトウェア上で VxVM によるディスクタイプとしてサポートされません。これは、VxVM ソフトウェアの一般的な制限です。
カプセル化 – カプセル化するディスクでは、2 つのディスクスライステーブルエントリを空にしておく必要があります。
ボリューム数 – ディスクデバイスグループを作成するときに任意のディスクデバイスグループが使用できるボリュームの最大数を確認します。
- ボリューム数が 1000 未満の場合は、デフォルトのミラー数を使用できます。
- ボリューム数が 1000 以上の場合は、デバイスグループボリュームへのマイナー番号の割り当て方を慎重に計画する必要があります。2 つのデバイスグループに、オーバーラップするマイナー番号を割り当てることはできません。
ダーティリージョンログ – ダーティリージョンロギング (DRL) を使用すると、ノードに障害が発生した後に、ボリュームの回復時間を短縮できます。また、DRL を使用することで入出力のスループットを低減できることがあります。
Dynamic Multipathing (DMP) – DMP だけを使用して、ノードごとに共有記憶装置への複数の I/O パスを管理することはサポートされていません。DMP を使用できるのは、次の構成だけです。
- ノードからクラスタの共有ストレージまでの I/O パスが 1 つ。
- ノードから共有クラスタストレージまでの I/O パスを 2 つ以上管理できる、サポート対象のマルチパスソリューション (Sun Traffic Manager、EMC PowerPath、Hiatchi HDLM)。

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

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

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

Solaris UFS ロギング – mount_ufs(1M) のマニュアルページを参照してください。
(Solaris 9 のみ) SPARC: Solaris ボリュームマネージャートランザクションボリュームロギング – 詳細は、『Solaris ボリュームマネージャーの管理』の「トランザクションボリューム (概要)」を参照してください。

注 –
Solaris ボリュームマネージャートランザクションボリュームロギングは Solaris 10 OS から削除されています。Solaris UFS ロギングは、より低い管理条件とオーバーヘッドで、同様の機能を高いパフォーマンスで提供します。
SPARC: VERITAS File System (VxFS) ロギング – 詳細は、VxFS ソフトウェアに付属の mount_vxfs のマニュアルページを参照してください。

次の表に、各ボリューム管理ソフトウェアでサポートされているロギングファイルシステムを示します。

表 1–5 サポートされているファイルシステムのロギング


ボリュームマネージャー	サポートされているファイルシステムのロギング
Solaris ボリュームマネージャー	Solaris UFS ロギング SPARC: Solaris ボリュームマネージャートランザクションボリュームロギング (Solaris 9 のみ) VxFS のロギング
VERITAS Volume Manager	Solaris UFS ロギング VxFS のロギング

SPARC: Solaris 9 OS では、UFS クラスタファイルシステム用の Solaris UFS ロギングと Solaris ボリュームマネージャートランザクションボリュームロギングのいずれかを選択する際に、次の点を考慮してください。

Solaris UFS ロギングは、常に UFS ファイルシステム上の空き領域を使用し、ファイルシステムのサイズに応じてログを確保します。
- 1G バイト未満のファイルシステムの場合、ログのサイズは 1M バイトになります。
- 1G バイト以上のファイルシステムの場合は、ログのサイズはファイルシステム 1G バイトあたり 1M バイトになり、最大 64M バイトです。
トランザクションボリュームは UFS ロギングを管理します。トランザクションボリュームのロギングデバイスコンポーネントは、ミラー化とストライプ化が可能なボリュームです。最大 1G バイトのログを作成できますが、ほとんどのファイルシステムでは 64M バイトで十分です。最小のログサイズは 1M バイトです。

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

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

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

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

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

独立したディスク拡張装置 – ミラーまたはプレックスのサブミラーは、それぞれ異なる多重ホスト拡張装置に分散してください。
ディスク領域 – ミラー化すると、2 倍のディスク領域が必要になります。
3 方向のミラー化 – Solaris ボリュームマネージャーソフトウェアと VERITAS Volume Manager (VxVM) は、3 方向のミラー化をサポートしています。ただし、Sun Cluster ソフトウェアが必要とするのは、2 方向のミラー化だけです。
異なるデバイスサイズ – 異なるサイズのデバイスにミラーを作成した場合、ミラーの容量は、最小のサブミラーまたはプレックスのサイズに制限されます。

多重ホストディスクの詳細につていは、『Sun Cluster の概要 (Solaris OS 版)』の「多重ホストディスク記憶装置」と『Sun Cluster の概念 (Solaris OS 版)』を参照してください。

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

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

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

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

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

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

起動ディスク – 起動可能ルートディスクをミラーとして設定できます。主起動ディスクに障害が発生した場合に、ミラーから起動できます。
複雑さ – ルートディスクをミラー化すると、システム管理の複雑さが増します。また、シングルユーザーモードでの起動も複雑になります。
バックアップ – ルートディスクをミラー化するかどうかに関係なく、ルートは定期的にバックアップしてください。ミラー化だけで、管理上の誤りが防げるわけではありません。誤って変更あるいは削除したファイルは、バックアップによってのみ復元できます。
定足数 (Quorum) デバイス – 定足数デバイスとして構成されたディスクは、ルートディスクのミラー化に使用しないでください。
定足数 (Quorum) – Solaris ボリュームマネージャーソフトウェアの構成で、状態データベースの定足数が失われるという障害が発生した場合は、保守を行わない限り、システムを再起動できなくなります。状態データベースと状態データベースの複製の詳細は、Solaris ボリュームマネージャーのマニュアルを参照してください。
独立したコントローラ – 独立したコントローラにルートディスクをミラー化するという方法は、最高の可用性を得る手段の 1 つです。
二次ルートディスク – ミラー化したルートディスクを使用すると、主ルートディスクに障害が発生しても、二次 (ミラー) ルートディスクで動作を継続できます。その後、主ルートディスクは、電源を入れ直すか、一時的な入出力エラーの後に、正常に戻ることがあります。以降の起動は、eeprom(1M) boot-device パラメータに指定された主ルートディスクを使用して行われます。このような場合、手作業による修復作業は発生しませんが、起動に問題がないようにドライブは動作を開始します。Solaris ボリュームマネージャーソフトウェアでは、再同期が行われます。再同期をするには、ドライブが正常に戻ったときに手作業が必要になります。

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

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