ボリューム管理の計画

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

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

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

• Solstice DiskSuite/Solaris Volume Manager ソフトウェアのガイドライン

• SPARC: VERITAS 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 とディスクへの冗長パスを提供する場合は、ソフトウェアミラー化を使用する必要はありません。

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

• 一意の命名 – ローカル Solstice DiskSuite メタデバイス、ローカル Solaris Volume Manager、ボリューム、または 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 Volume Manager ボリュームの名前は、クラスタ全体で一意にする必要があります。 また、その名前はどのデバイス ID (DID) 名とも同じであってはなりません。

• 二重列メディエータ – 2 つの列だけで構成されていて、2 つのノードでマスターされている各ディスクセットでは、そのディスクセット用に構成されている Solstice DiskSuite/Solaris Volume Manager メディエータを使用する必要があります。 列は、ディスク格納装置、その物理ディスク、格納装置からノードへのケーブル、インタフェースアダプタカードで構成されます。 二重列メディエータの構成には、次の規則に従ってください。

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

  • メディエータを必要とするすべてのディスクセットに対して、2 つの同じノードを使用する必要があります。 これら 2 つのノードがディスクセットをマスターする必要があります。

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

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

• /kernel/drv/md.conf 設定 – それぞれのディスクセットが使用するすべての Solstice DiskSuite メタデバイスまたは Solaris Volume Manager ボリュームは、再構成起動時にあらかじめ作成されます。 再構成は、/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) の構成を計画する際は、次の点を考慮してください。

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

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

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

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

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

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

• カプセル化 – カプセル化するディスクには、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)。

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

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

• Solaris UFS logging – 詳細については、mount_ufs(1M) のマニュアルページを参照してください。

• Solstice DiskSuite trans-metadevice logging または Solaris Volume Manager transactional-volume logging – 詳細については、『Solstice DiskSuite 4.2.1 ユーザーズガイド』の「DiskSuite オブジェクトの作成」を参照するか、『Solaris ボリュームマネージャの管理』の「トランザクションボリューム (概要)」を参照してください。

• SPARC: VERITAS File System (VxFS) のロギング – 詳細については、mount_vxfs ソフトウェアに付属の VxFS マニュアルページを参照してください。

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

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

ボリュームマネージャ	サポートされているファイルシステムのロギング
Solstice DiskSuite/Solaris Volume Manager	Solaris UFS logging、Solstice DiskSuite trans-metadevice logging または Solaris Volume Manager transactional-volume logging、VxFS ロギング
SPARC: VERITAS Volume Manager	Solaris UFS ロギング, VxFS ロギング

Solaris UFS logging と Solstice DiskSuite trans-metadevice logging/Solaris Volume Manager transactional-volume logging のどちらを使用するかを選択するときには、次の点を考慮してください。

• Solaris Volume Managertransactional-volume logging (旧 Solstice DiskSuite trans-metadevice logging) は、将来の Solaris リリースで、Solaris オペレーティング環境から削除される予定です。 Solaris UFS logging は、より低い管理条件とオーバーヘッドで、同様の機能を高いパフォーマンスで提供します。

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

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

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

• ログメタデバイス/トランザクショナルボリューム – Solstice DiskSuite トランスメタデバイスまたは Solaris Volume Manager トランザクショナルボリュームは、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 Volume Manager ボリュームで構成されます。 大規模な構成では、大量のメタデバイスまたはボリュームが含まれることがあります。

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

多重ホストディスクの詳細については、『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 ファイルが変更されることがあります。

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