ボリューム管理の計画

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

Sun Cluster は、ボリューム管理ソフトウェアを使用して、ディスクをディスクデバイスグループにまとめ、1 つの単位で管理できるようにします。Sun Cluster は、Solstice DiskSuite ソフトウェアおよび VERITAS Volume Manager (VxVM) をサポートしています。単一のクラスタ構成では、ボリューム管理ソフトウェアは 1 つだけ使用できます。ボリューム管理ソフトウェアの構成方法については、使用するボリューム管理ソフトウェアのマニュアルと、付録 A 「Solstice DiskSuite ソフトウェアの構成」 または付録 B 「VERITAS Volume Manager の構成」 を参照してください。クラスタ構成におけるボリューム管理の詳細については、『Sun Cluster 3.0 の概念』を参照してください。

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

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

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

• ミラー化多重ホストディスク - すべての多重ホストディスクは、複数のディスク拡張装置にまたがるようにミラー化する必要があります。多重ホストディスクのガイドラインについては、「多重ホストディスクのミラー化」を参照してください。

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

• 一意の命名 - 任意のクラスタノード上で、ローカルの Solstice DiskSuite メタデバイスまたは VxVM ボリュームが、/global/.devices/node@nodeid ファイルシステムをマウントするデバイスとして使用されている場合、そのメタデバイスまたはボリュームの名前はクラスタ全体で一意にする必要があります。

• ノードリスト - ディスクデバイスグループの高可用性を実現するには、それらの潜在マスターのノードリストとフェイルバックポリシーを、関連付けられているリソースグループと同一にします。または、スケーラブルなリソースグループで、それと関連付けられているディスクデバイスグループ以上のノードが使用されている場合、スケーラブルなリソースグループのノードリストをディスクデバイスグループのノードリストのスーパーセットにします。ノードリストについての詳細は、『Sun Cluster 3.0 データサービスのインストールと構成』のリソースグループの計画情報を参照してください。

• 多重ポートディスク- クラスタ内でディスクグループの構築に使用されているディスクはすべて、そのデバイスグループのノードリストで構成されているすべてのノードに接続 (またはポート) する必要があります。Solstice DiskSuite ソフトウェアは、ディスクセットにディスクを追加したときに、これを自動的に確認できます。ただし、構成した VxVM ディスクグループは、特定のセットのノードとは関連付けられていません。また、Solstice DiskSuite ディスクセット、VxVM ディスクグループ、または個々のセットの広域デバイスを広域デバイスグループとしてクラスタ化ソフトウェアに登録するときは、一部の接続確認しか実行できません。

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

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

Solstice DiskSuite のガイドライン

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

• メディエータ - 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 に設定する必要があります。1 つのディスクセットで使用できるメタデバイスの最高数は 8192 です。

  • md_nsets - md_nsets フィールドは、クラスタ全体のニーズを満たすためにシステムで作成できるディスクセットの総数を定義します。md_nsets の値には、クラスタ内の予想される論理ホスト数に 1 を加えた値を設定して、Solstice DiskSuite ソフトウェアが論理ホストの全プライベートディスク (ローカルディスクセットに含まれないメタデバイス) を管理できるようにします。1 つのクラスタで使用できるディスクセットの最高数は 32 です。

  インストール時、これら 2 つのフィールドに、将来予想されるクラスタの拡張を考慮した値を設定してください。クラスタを実際に使用し始めた後でこれらの値を増やそうとすると、すべてのノードについて再構成再起動が必要になるため、作業は時間のかかるものになります。また、後でこれらの値を増やす場合、要求されたデバイスを作成するには、ルート (/) ファイルシステムに確保された領域では不十分という可能性が高まります。

  ---

  注意 -

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

  ---

VERITAS Volume Manager のガイドライン

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

• ルートディスクグループ - 各ノードにデフォルトのディスクデバイスグループ (rootdg) を作成する必要があります。rootdg ディスクグループは次のディスク上に作成できます。

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

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

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

  • rootdg ディスクグループは、ノードに対してローカルである必要があります。

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

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

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

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

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

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

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

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

• Solaris UFS ロギング

Solstice DiskSuite トランスメタデバイス UFS ロギングの詳細については、Solstice DiskSuite のマニュアルを参照してください。Solaris UFS ロギングの詳細については、mount_ufs(1M) のマニュアルページおよび『Solaris 移行ガイド』を参照してください。

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

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

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

Solstice DiskSuite ボリューム管理ソフトウェア用に Solaris UFS ロギングまたは Solstice DiskSuite トランスメタデバイス UFS ロギングのどちらかを選択するときは、次の点を考慮してください。

• Solaris UFS ログサイズ - Solaris UFS ロギングは、常に UFS ファイルシステム上の空き領域を使用し、ファイルシステムのサイズに応じてログを確保します。

  • 1G バイト未満のファイルシステムの場合、ログのサイズは 1M バイトになります。

  • 1G バイト以上のファイルシステムの場合は、ログのサイズはファイルシステム 1G バイトあたり 1M バイトになり、最大 64M バイトです。

• ログメタデバイス - Solstice DiskSuite トランスメタデバイス UFS ロギングでは、ロギングに使用されたトランスデバイスによってメタデバイスが作成されます。ログは、ミラー化やストライプ化が可能な別のメタデバイスです。さらに、Solstice DiskSuite では、最大 1T バイトのロギングファイルシステムを作成できます。

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

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

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

Sun Cluster 構成で多重ホストディスクをミラー化することにより、構成は単一のディスク障害に耐えることができます。Sun Cluster ソフトウェアでは、すべての多重ホストディスクは、複数のディスク拡張装置にまたがるようにミラー化する必要があります。

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

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

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

• 3 方向のミラー化 - Solstice DiskSuite ソフトウェアと VERITAS Volume Manager (VxVM) は、3 方向のミラー化をサポートしています。ただし、Sun Cluster が必要とするのは、2 方向のミラー化だけです。

• メタデバイス数 - Solstice DiskSuite ソフトウェアでは、ミラーは連結やストライプなどの他のメタデバイスで構成されます。大規模な構成では、大量のメタデバイスが含まれることがあります。たとえば、UFS ロギングファイルシステムごとに 7 つのメタデバイスが作成されます。

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

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

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

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

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

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

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

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

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

• 定足数 (quorum) - Solstice DiskSuite の構成で、メタデバイス状態データベースの定足数が失われるという障害が発生した場合は、保守を行わない限り、システムを再起動できなくなります。メタデバイス状態データベースと状態データベースの複製の詳細については、Solstice DiskSuite のマニュアルを参照してください。

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

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

• 二次ルートディスク - ミラー化したルートディスクを使用すると、主起動ディスクに障害が発生しても、二次 (ミラー) ルートディスクで動作を継続できます。電源を入れ直したことにより、あるいは一時的に入出力エラーであったために、後で主ルートディスクが正常に戻った場合、以降の起動は、OpenBoot^TM PROM の boot-device フィールドに指定された主ルートディスクを使用して行われます。このような場合、手作業で修復作業を行わなくても、起動に問題がないようにドライブは動作を開始します。このとき、Solstice DiskSuite の再同期が行われます。再同期をするには、ドライブが正常に戻ったときに手作業が必要になります。この状況では、手作業による修復作業はありません。

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

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