ボリューム管理の計画

この節の計画情報を、『Sun Cluster 3.1 ご使用にあたって』の「ディスクデバイスグループ構成のワークシート」と『Sun Cluster 3.1 ご使用にあたって』の「ボリュームマネージャ構成ワークシート」に追加してください。 Solstice DiskSuite/Solaris Volume Manager の場合は、この計画情報を『Sun Cluster 3.1 ご使用にあたって』の「メタデバイスのワークシート (Solstice DiskSuite/Solaris Volume Manager)」にも追加してください。

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

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

• Solstice DiskSuite/Solaris Volume Manager ソフトウェアを使用する場合は、ディスク管理のために一部のノードで VxVM を使用するときでも、クラスタの全ノードにこのソフトウェアをインストールする必要があります。

• VxVM を使用して、VxVM クラスタ機能を有効にするときは、クラスタの全ノードに VxVM をインストールし、それらのライセンスを取得する必要があります。

• VxVM を使用するが、VxVM クラスタ機能は有効にしない場合は、 VxVM によって管理する記憶装置に接続されたノードだけに VxVM をインストールしてライセンスを取得します。

• 1 つのノードに Solstice DiskSuite/Solaris Volume Manager ソフトウェアと VxVM の両方をインストールする場合は、各ノードの固有ディスク (ルートディスクなど) の管理には Solstice DiskSuite/Solaris Volume Manager ソフトウェアを使用し、共有ディスクの管理には VxVM を使用する必要があります。

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

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

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

• ミラー化多重ホストディスク – すべての多重ホストディスクは、複数のディスク拡張装置にまたがるようにミラー化する必要があります。多重ホストディスクのガイドラインについては、多重ホストディスクのミラー化 を参照してください。ストレージデバイスがハードウェア RAID とディスクへの冗長パスを提供する場合は、ソフトウェアミラー化を使用する必要はありません。

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

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

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

• 多重ポートディスク – クラスタ内でディスクグループの構築に使用されているディスクはすべて、そのデバイスグループのノードリストで構成されているすべてのノードに接続 (またはポート) する必要があります。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 ファイルに含まれる構成パラメータに基づいて再構成起動時にあらかじめ作成されます。

  nmd および md_nsets フィールドを次のように変更して、Sun Cluster 構成をサポートする必要があります。アップグレード用により多くの容量を必要とするファイルシステムの制約は変更できませんが (changeable とマークされなければならない)、このようなファイルシステムに layout_constraint を使用すれば、その minimum_size 値を変更できます。

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

    1 つのクラスタで使用できるディスクセットの最大数は 32 (一般的な使用のための 31 ディスクセットとプライベートディスク管理用の 1 ディスクセット) です。 md_nsets のデフォルト値は 4 です。

  • nmd – nmd フィールドは、各ディスクセットに対して作成するメタデバイスまたはボリュームの個数を定義します。nmd の値には、クラスタ内の任意の 1 つのディスクセットが使用するメタデバイスまたはボリューム名の予想最大数を設定する必要があります。たとえば、最初の 15 のディスクセットは 10 個のメタデバイスまたはボリュームを使用し、16 番目のディスクセットは 1000 個のメタデバイスまたはボリュームを使用するという場合は、nmd の値は最低でも 1000 に設定する必要があります。また nmd の値は、各 DID 名および各ローカルメタデバイス名またはボリューム名の一意性を、クラスタ全体で保つことができるのに十分な大きさが必要です。

    1 つのディスクセットで使用できるメタデバイス名またはボリューム名の最大数は 8192 です。 nmd のデフォルト値は、128 です。

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

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

  ---

  注意 –

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

  ---

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

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 ロギング — 詳細については、 mount_ufs(1M) マニュアルページを参照してください。

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

• VERITAS File System (VxFS) ロギング—詳細については、VxFS に付属している mount_vxfs マニュアルページを参照してください。

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

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

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

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

• 将来の Solaris リリースでは、トランザクションボリュームは Solaris オペレーティング環境から削除される予定です。Solaris 8 リリースからサポートされている UFS ロギングは、トランザクションボリュームと同じ機能を備えており、より高い性能を提供します。UFS ロギングでは、システム管理の要件やオーバーヘッドが軽減されます。

• 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 3.1 の概要』を参照してください。

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

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

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

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

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

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

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

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

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

• 定足数 (Quorum) デバイス – 定足数デバイスとして構成されたディスクは、ルートディスクのミラー化に使用しないでください。

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

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

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

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

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