Sun Cluster 3.0 12/01 ソフトウェアのインストール

ボリューム管理の計画

この節の計画情報を、『Sun Cluster 3.0 12/01 ご使用にあたって』の「ディスクデバイスグループ構成のワークシート」と「ボリューム管理ソフトウェア構成のワークシート」に追加してください。Solstice DiskSuite の場合は、この計画情報を「メタデバイスのワークシート (Solstice DiskSuite)」にも追加してください。

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

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

Solstice DiskSuite ソフトウェアを使用する場合は、ディスク管理のために一部のノードでだけ VxVM を使用するときでも、クラスタの全ノードにこのソフトウェアをインストールする必要があります。
VxVM を使用して VxVM クラスタ機能を有効にするときは、クラスタの全ノードに VxVM をインストールし、それらのライセンスを取得する必要があります。
VxVM を使用するが VxVM クラスタ機能を有効にしないという場合は、VxVM によって管理する記憶装置に接続されたノードにだけ VxVM をインストールしてライセンスを取得します。
1 つのノードに Solstice DiskSuite ソフトウェアと VxVM の両方をインストールする場合は、各ノードの固有ディスク（ルートディスクなど) の管理には Solstice DiskSuite ソフトウェアを使用し、共有ディスクの管理には VxVM を使用する必要があります。

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

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

ディスクを構成する際は、次の一般的なガイドラインを考慮してください。

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

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

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

Solstice DiskSuite の構成を計画する際は、次のことを考慮してください。

ローカルメタデバイス名 - 各ローカルメタデバイス名は、クラスタ内で固有の名前にする必要があり、どのデバイス ID (DID) 名とも同じであってはなりません。
メディエータ - 2 つの列だけで構成されていて、2 つのノードでマスターされている各ディスクセットでは、そのディスクセット用に構成されている Solstice DiskSuite メディエータを使用する必要があります。列は、ディスク格納装置、その物理ディスク、格納装置からノードへのケーブル、インタフェースアダプタカードで構成されます。各ディスクセットは、メディエータホストとして機能する 2 つのノードで構成します。また、メディエータが必要なすべてのディスクセットに対しては同じ 2 つのノードを使用し、これらの 2 つのノードがディスクセットをマスターする必要があります。メディエータは、列およびホストが 2 つずつという要件を満たしていないディスクセットに対しては構成できません。詳細は、mediator(7) のマニュアルページを参照してください。
/kernel/drv/md.conf の設定 - それぞれのディスクセットが使用するすべてのメタデバイスは前もって (/kernel/drv/md.conf ファイルに含まれる構成パラメータに基づいて再構成起動時に) 作成されます。md.conf ファイル内の各フィールドについては、Solstice DiskSuite のマニュアルに説明があります。nmd および md_nsets フィールドを次のように変更して、Sun Cluster 構成をサポートする必要があります。
- nmd - nmd フィールドは、各ディスクセットに対して作成するメタデバイスの個数を定義します。nmd の値には、クラスタ内の任意の 1 つのディスクセットが使用するメタデバイスの予想最高数を設定する必要があります。たとえば、最初の 15 のディスクセットは 10 個のメタデバイスを使用し、16 番目のディスクセットは 1000 個のメタデバイスを使用するという場合は、nmd の値は最低でも 1000 に設定する必要があります。また nmd の値は、各 DID 名および各ローカルメタデバイス名の一意性を、クラスタ全体で保つことができるのに十分な大きさが必要です。1 つのディスクセットで使用できるメタデバイスの最高数は 8192 です。ディスクセットあたりのメタデバイスのデフォルトの数は 128 です。
- md_nsets - md_nsets フィールドは、クラスタ全体のニーズを満たすためにシステムで作成できるディスクセットの総数を定義します。md_nsets の値には、クラスタ内の予想される論理ホスト数に 1 を加えた値を設定して、Solstice DiskSuite ソフトウェアが論理ホストの全プライベートディスク (ローカルディスクセットに含まれないメタデバイス) を管理できるようにします。1 つのクラスタで使用できるディスクセットの最高数は 32 です。ディスクセットのデフォルトの数は 4 です。
インストール時、これら 2 つのフィールドに、将来予想されるクラスタの拡張を考慮した値を設定してください。クラスタを実際に使用し始めた後でこれらの値を増やそうとすると、すべてのノードについて再構成再起動が必要になるため、作業は時間のかかるものになります。また、後でこれらの値を増やす場合、要求されたデバイスを作成するには、ルート (/) ファイルシステムに確保された領域では不十分という可能性が高まります。

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

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

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

筐体ベースのネーミング - デバイスの筐体ベースのネーミング (Enclosure-Based Naming、VxVM バージョン 3.2 で導入された機能) を使用する場合、必ず、同じストレージを共有するすべてのクラスタノードにおいて整合性のあるデバイス名を使用してください。VxVM はこのような名前を調節しないため、 VxVM が各ノードから同じデバイスに同じ名前を割り当てているかどうかは、管理者が確認する必要があります。整合性のある名前を割り当てなくてもクラスタの動作に悪影響はありませんが、クラスタの管理が極端に複雑になり、構成エラーが発生し、データが失われる可能性が高くなります。
ルートディスクグループ - 各ノードにデフォルトのディスクデバイスグループ (rootdg) を作成する必要があります。rootdg ディスクグループは次のディスク上に作成できます。
- ルートディスク (カプセル化されている必要がある)
- ルート以外の 1 つまたは複数のローカルディスク (カプセル化または初期化できるもの)
- ルートディスクとルート以外のローカルディスクの組み合わせ
rootdg ディスクグループは、ノードに対してローカルである必要があります。
カプセル化 - カプセル化するディスクには、2 つのディスクスライステーブルエントリを空けておく必要があります。
ボリューム数 - ディスクデバイスグループを作成するときに任意のディスクデバイスグループが使用するボリュームの最大数を確認します。
- ボリューム数が 1000 未満の場合は、デフォルトのミラー数を使用できます。
- ボリューム数が 1000 以上の場合は、ディスクデバイスグループボリュームへのマイナー番号の割り当て方を慎重に計画する必要があります。2 つのディスクデバイスグループに、オーバーラップするマイナー番号を割り当てることはできません。
ダーティーリージョンログ - ダーティーリージョンログ (DRL) の使用を推奨しますが、必須ではありません。DRL を使用すると、ノードに障害が発生した後に、ボリュームの回復時間を短縮できます。また、DRL を使用することで入出力のスループットを低減できることがあります。

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

ロギングはクラスタファイルシステムに必要です。Sun Cluster では、次のロギングファイルシステムがサポートされています。

Solaris UFS ロギング
Solstice DiskSuite トランスメタデバイス UNIX ファイルシステム (UFS) ロギング
VERITAS File System (VxFS) ロギング

Solstice DiskSuite トランスメタデバイス UFS ロギングの詳細については、Solstice DiskSuite のマニュアルを参照してください。Solaris UFS ロギングの詳細については、mount_ufs(1M) のマニュアルページを参照してください。VxFS ロギングの詳細については、VxVM ソフトウェアに付属している mount_vxfs(1M) のマニュアルページを参照してください。

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

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


ボリューム管理ソフトウェア	サポートされているファイルシステムのロギング
Solstice DiskSuite	Solaris UFS ロギング、Solstice DsikSuite トランスメタデバイス UFS ロギング、VxFS ロギング
VERITAS Volume Manager	Solaris UFS ロギング、VxFS ロギング

Soaris UFS ロギングまたは Solstice DiskSuite トランスメタデバイス UFS ロギングのどちらを使用するかを選択するときには、次の点を考慮してください。

Solaris UFS ログサイズ - Solaris UFS ロギングは、常に UFS ファイルシステム上の空き領域を使用し、ファイルシステムのサイズに応じてログを確保します。
- 1G バイト未満のファイルシステムの場合、ログのサイズは 1M バイトになります。
- 1G バイト以上のファイルシステムの場合は、ログのサイズはファイルシステム 1G バイトあたり 1M バイトになり、最大 64M バイトです。
ログメタデバイス - Solstice DiskSuite トランスメタデバイスは、UFS ロギングを管理します。トランスメタデバイスのロギングデバイスコンポーネントは、ミラー化とストライプ化が可能なメタデバイスです。最大 1G バイトのログを作成できますが、ほとんどのファイルシステムでは 64M バイトで十分です。最小のログサイズは 1M バイトです。トランスメタデバイスによるロギングの詳細は、Solstice DiskSuite のマニュアルを参照してください。

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

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

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

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

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

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

多重ホストディスクの詳細については、『Sun Cluster 3.0 12/01 の概念』を参照してください。

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

この節の計画情報を『Sun Cluster 3.0 12/01 ご使用にあたって』の「ローカルファイルシステム配置のワークシート」に追加してください。

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

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

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

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

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

この状況では、手作業による修復作業はありません。二次 (ミラー) ルートディスク上のファイルに変更が加えられている場合、起動中に、その変更が主ルートデバイスに反映されることはなく、サブミラーは無効になります。たとえば、/etc/system ファイルに対する変更が失われることがあります。主ルートディスクが休止している間に、一部の Solstice DiskSuite 管理コマンドによって、/etc/system ファイルが変更されることがあります。

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