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

ボリューム管理の計画

「ディスクデバイスグループ構成のワークシート」と「ボリューム管理ソフトウェア構成のワークシート」に次の計画情報を追加してください。Solstice DiskSuite または Solaris Volume Manager については、「メタデバイスのワークシート (Solstice DiskSuite または Solaris Volume Manager)」に次の計画情報を追加してください。

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

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

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


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

ボリューム管理ソフトウェアのインストールと構成方法については、ボリューム管理ソフトウェアのマニュアル、および「Solstice DiskSuite または Solaris Volume Manager ソフトウェアのインストールと構成」または「SPARC: VxVM ソフトウェアのインストールと構成」を参照してください。クラスタ構成におけるボリューム管理の詳細については、『Sun Cluster の概念(Solaris OS 版)』を参照してください。

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

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

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

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

Solstice DiskSuite または Solaris Volume Manager ソフトウェアのガイドライン

Solstice DiskSuite または Solaris Volume Manager の構成を計画する際は、次の点を考慮してください。

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

注意 –
すべてのクラスタノードの /kernel/drv/md.conf ファイルの内容は、それぞれのノードがサービスを提供するディスクセット数に関係なく、同一である必要があります。このガイドラインに従わないと、重大な Solstice DiskSuite または Solaris Volume Manager エラーが発生し、データが失われることがあります。

nmd および md_nsets フィールドを次のように変更して、Sun Cluster 構成をサポートする必要があります。
- md_nsets – md_nsets フィールドは、システムでクラスタ全体のニーズを満たすために作成できるディスクセットの合計数を定義できます。md_nsets の値は、クラスタ内で予想されるディスクセットの数に 1 を加えた値に設定します。Solstice DiskSuite または Solaris Volume Manager ソフトウェアは、追加のディスクセットを使用して、ローカルホスト上のプライベートディスクを管理します。プライベートディスクとは、ローカルディスクセットに含まれないメタデバイスまたはボリュームのことです。
  
  1 つのクラスタで使用できるディスクセットの最大数は 32 です。32 のうち、31 ディスクセットは一般的な使用のためで、1 ディスクセットは、プライベートディスクの管理用に使われます。md_nsets のデフォルト値は 4 です。
- nmd – nmd フィールドは、ディスクセットごとに作成されるメタデバイスまたはボリュームの数を定義します。nmd の値には、クラスタ内の任意の 1 つのディスクセットが使用するメタデバイスまたはボリューム名の予想最大数を設定する必要があります。たとえば、クラスタが最初の 15 のディスクセットで 10 のメタデバイスまたはボリュームを使用し、16 番目のディスクセットで 1000 のメタデバイスまたはボリュームを使用する場合、nmd の値を最低 1000 に設定します。また、nmd の値は各デバイス –ID 名に十分な数を保証する大きさでなければなりません。この値は、各ローカルメタデバイス名またはローカルボリューム名がクラスタ全体で一意になるように十分に大きな値を設定してください。
  
  1 つのディスクセットで使用できるメタデバイス名またはボリューム名の最大数は 8192 です。nmd のデフォルト値は 128 です。
インストール時、これら 2 つのフィールドに、将来予想されるクラスタの拡張を考慮した値を設定してください。クラスタの使用を開始した後で、これらのフィールド値を増やそうとすると、時間がかかります。値を変更すると、すべてのノードで再構成再起動が必要になるからです。また、後でこれらの値を増やす場合、要求されたデバイスを作成するには、ルート (/) ファイルシステムに確保された領域では不十分という可能性が高まります。

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

md.conf ファイルの詳細については、『Solstice DiskSuite 4.2.1 リファレンス』の「システムファイルと起動ファイル」を参照するか、『Solaris ボリュームマネージャの管理』の「システムファイルと始動ファイル」を参照してください。

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

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

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

ルートディスクグループは次のディスク上に作成できます。
- ルートディスク (カプセル化されている必要がある)
- ルート以外の 1 つまたは複数のローカルディスク (カプセル化または初期化できるもの)
- ルートディスクとルート以外のローカルディスクの組み合わせ
ルートディスクグループは、ノードに対してローカルである必要があります。
簡易ルートディスクグループ – 簡易ルートディスクグループ (ルートディスクの 1 つのスライスに作成される rootdg) は、Sun Cluster ソフトウェア上で VxVM によるディスクタイプとしてサポートされません。これは、VxVM ソフトウェアの一般的な制限です。
カプセル化 – カプセル化するディスクには、2 つのディスクスライステーブルエントリを空けておく必要があります。
ボリューム数 – ディスクデバイスグループを作成するときに任意のディスクデバイスグループが使用するボリュームの最大数を確認します。
- ボリューム数が 1000 未満の場合は、デフォルトのミラー数を使用できます。
- ボリューム数が 1000 以上の場合は、ディスクデバイスグループボリュームへのマイナー番号の割り当て方を慎重に計画する必要があります。2 つのディスクデバイスグループに、オーバーラップするマイナー番号を割り当てることはできません。
ダーティリージョンログ – ダーティリージョンロギング (DRL) を使用すると、ノードに障害が発生した後に、ボリュームの回復時間を短縮できます。また、DRL を使用することで入出力のスループットを低減できることがあります。
DMP (Dynamic Multipathing) – 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) のマニュアルページを参照してください。
Solstice DiskSuite トランスメタデバイスロギングまたは Solaris ボリュームマネージャトランザクションボリュームロギング – 詳細は、『Solstice DiskSuite 4.2.1 ユーザーズガイド』の「DiskSuite オブジェクトの作成」または『Solaris ボリュームマネージャの管理』の「トランザクションボリューム (概要)」を参照してください。
SPARC:VERITAS File System (VxFS) ロギング – 詳細は、VxFS ソフトウェアに付属の mount_vxfs のマニュアルページを参照してください。

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

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


ボリュームマネージャ	サポートされているファイルシステムのロギング
Solstice DiskSuite または Solaris Volume Manager	Solaris UFS ロギング Solstice DiskSuite トランスメタデバイスロギング Solaris ボリュームマネージャトランザクションボリュームロギング VxFS のロギング
SPARC: VERITAS Volume Manager	Solaris UFS ロギング VxFS のロギング

UFS クラスタファイルシステムに Solaris UFS ロギングおよび Solstice DiskSuite トランスメタデバイスロギング/Solaris ボリュームマネージャトランザクションボリュームロギングを選択する場合、以下の点を考慮してください。

Solaris ボリュームマネージャトランザクションボリュームロギング (旧 Solstice DiskSuite トランスメタデバイスロギング) は、今後の Solaris のリリースで Solaris OS から削除される予定です。Solaris UFS ロギングは、より低い管理条件とオーバーヘッドで、同様の機能を高いパフォーマンスで提供します。
Solaris UFS ログサイズ – Solaris UFS ロギングは、常に UFS ファイルシステム上の空き領域を使用し、ファイルシステムのサイズに応じてログを確保します。
- 1G バイト未満のファイルシステムの場合、ログのサイズは 1M バイトになります。
- 1G バイト以上のファイルシステムの場合は、ログのサイズはファイルシステム 1G バイトあたり 1M バイトになり、最大 64M バイトです。
ログメタデバイス/トランザクショナルボリューム – Solstice DiskSuite トランスメタデバイスまたは Solaris ボリュームマネージャトランザクショナルボリュームは、UFS ロギングを管理します。トランスメタデバイスまたはトランザクショナルボリュームのロギングデバイスコンポーネントは、ミラー化とストライプ化が可能なメタデバイスまたはボリュームです。最大 1G バイトのログを作成できますが、ほとんどのファイルシステムでは 64M バイトで十分です。最小のログサイズは 1M バイトです。

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

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

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

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

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

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

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

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

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

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

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

ルートディスクのミラー化については、使用するボリューム管理ソフトウェアのマニュアルと、「Solstice DiskSuite または Solaris Volume Manager ソフトウェアのインストールと構成」または「SPARC: VxVM ソフトウェアのインストールと構成」を参照してください。

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

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

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

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