「ディスクデバイスグループ構成のワークシート」と「ボリューム管理ソフトウェア構成のワークシート」に次の計画情報を追加してください。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–4 Sun Cluster ソフトウェアで使用がサポートされているボリューム管理ソフトウェア
ボリューム管理ソフトウェア |
要件 |
---|---|
Solstice DiskSuite または Solaris Volume Manager |
一部のノードで VxVM を使用してディスクを管理する場合でも、クラスタのすべてのノードに Solstice DiskSuite または Solaris Volume Manager ソフトウェアをインストールする必要があります。 |
クラスタのすべてのノード上に、クラスタ機能を持つ 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 とデバイスへの冗長パスを提供する場合は、ソフトウェアミラー化を使用する必要はありません。
ミラー化ルート – ルートディスクをミラー化することにより高可用性を保証できますが、このようなミラー化は必須ではありません。ルートディスクをミラー化するかどうかを判断する際のガイドラインについては、「ミラー化に関するガイドライン」を参照してください。
一意の命名 – /global/.devices/node@nodeid ファイルシステムがマウントされるデバイスとして使用されている、ローカル Solstice DiskSuite メタデバイス、ローカル Solaris ボリュームマネージャー ボリューム、または VxVM ボリュームがある可能性があります。この場合、/global/.devices/node@nodeid ファイルシステムがマウントされるローカルメタデバイスまたはローカルボリュームの名前はそれぞれ、クラスタ全体で一意である必要があります。
ノードリスト – ディスクデバイスグループの高可用性を実現するには、これらの潜在マスターのノードリストとフェイルバックポリシーを、関連付けられているリソースグループと同一にします。または、スケーラブルなリソースグループで、それと関連付けられているディスクデバイスグループ以上のノードが使用されている場合、スケーラブルなリソースグループのノードリストをディスクデバイスグループのノードリストのスーパーセットにします。ノードリストについては、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』のリソースグループ計画情報を参照してください。
多重ホストディスク – デバイスグループを構成するために使用されるすべてのデバイスを、そのデバイスグループのノードリストに構成されているすべてのノードに接続 (つまり、ポート) する必要があります。Solstice DiskSuite または Solaris Volume Manager ソフトウェアは、ディスクセットにデバイスを追加したときに、この接続を自動的に確認します。しかし、構成した VxVM ディスクグループは、ノードの特定のセットには関連を持ちません。
ホットスペアディスク – ホットスペアディスクを使用すると可用性を高めることができますが、ホットスペアディスクは必須ではありません。
ディスクの配置の推奨事項とその他の制限については、ボリューム管理ソフトウェアのマニュアルを参照してください。
Solstice DiskSuite または Solaris Volume Manager の構成を計画する際は、次の点を考慮してください。
ローカルメタデバイス名またはボリューム名 – 広域デバイスファイルシステム (/global/.devices/node@nodeid) がマウントされるローカル 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 9 Solaris ボリュームマネージャー ボリュームは、再構成時にあらかじめ作成されます。再構成は、/kernel/drv/md.conf ファイルに含まれる構成パラメータに基づいています。
Solaris 10 リリースで、Solaris ボリュームマネージャーはボリュームを動的に構成するように拡張されました。/kernel/drv/md.conf ファイルの nmd パラメータと md_nsets パラメータを編集する必要はありません。新しいボリュームは必要に応じて作成されます。
nmd フィールドと md_nsets フィールドは次のように変更して、Solaris 8 または Solaris 9 OS で Sun Cluster 構成をサポートする必要があります。
すべてのクラスタノードの /kernel/drv/md.conf ファイルの内容は、それぞれのノードがサービスを提供するディスクセット数に関係なく、同一である必要があります。このガイドラインに従わないと、重大な Solstice DiskSuite または Solaris Volume Manager エラーが発生し、データが失われることがあります。
md_nsets – md_nsets フィールドは、クラスタ全体のニーズを満たすために、システムに作成できるディスクセットの合計数を定義します。md_nsets の値は、クラスタ内で予想されるディスクセットの数に 1 を加えた値に設定します。Solstice DiskSuite または Solaris Volume Manager ソフトウェアは、追加のディスクセットを使用して、ローカルホスト上のプライベートディスクを管理します。
1 つのクラスタで使用できるディスクセットの最大数は 32 です。32 のうち、31 ディスクセットは一般的な使用のためで、1 ディスクセットは、プライベート ディスクの管理用に使われます。md_nsets のデフォルト値は 4 です。
nmd – nmd フィールドは、クラスタに存在すると予想されるメタデバイスまたはボリューム名の最大数を定義します。たとえば、あるクラスタの 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 Reference Guide』(Solaris 8) の「System and Startup Files」または『Solaris ボリュームマネージャの管理』(Solaris 9 または Solaris 10) を参照してください。
VERITAS Volume Manager (VxVM) の構成を計画する際は、次の点を考慮してください。
筐体ベースのネーミング – デバイスの筐体ベースのネーミングを使用する場合、必ず、同じストレージを共有するすべてのクラスタノードで整合性のあるデバイス名を使用してください。VxVM はこのような名前を調節しないため、VxVM が各ノードから同じデバイスに同じ名前を割り当てているかどうかは、管理者が確認する必要があります。整合性のある名前を割り当てなくても、クラスタの動作に悪影響はありません。ただし、整合性のない名前だと、クラスタの管理が極端に複雑になり、構成エラーが発生し、データが失われる可能性が高くなります。
ルートディスクグループ – VxVM 4.0 で、ルートディスクグループの作成は任意です。
ルートディスクグループは次のディスク上に作成できます。
ルートディスク (カプセル化されている必要がある)
ルート以外の 1 つまたは複数のローカルディスク (カプセル化または初期化できるもの)
ルートディスクとルート以外のローカルディスクの組み合わせ
ルートディスクグループは、ノードに対してローカルである必要があります。
簡易ルートディスクグループ – 簡易ルートディスクグループ (ルートディスクの 1 つのスライスに作成される rootdg) は、Sun Cluster ソフトウェア上の VxVM ではディスクタイプとしてサポートされません。これは、VxVM ソフトウェアの一般的な制限です。
ボリューム数 – ディスクデバイスグループを作成するときに任意のディスクデバイスグループが使用できるボリュームの最大数を確認します。
ボリューム数が 1000 未満の場合は、デフォルトのミラー数を使用できます。
ボリューム数が 1000 以上の場合は、ディスクデバイスグループボリュームへのマイナー番号の割り当て方を慎重に計画する必要があります。2 つのディスクデバイスグループに、オーバーラップするマイナー番号を割り当てることはできません。
ダーティーリージョンログ – ダーティーリージョンロギング (DRL) を使用すると、ノードに障害が発生した後に、ボリュームの回復時間を短縮できます。また、DRL を使用することで入出力のスループットを低減できることがあります。
Dynamic Multipathing (DMP) – DMP だけでノードごとに共有記憶装置への複数の入出力パスを管理することはサポートされません。DMP を使用できるのは、次の構成だけです。
ノードからクラスタの共有ストレージまでの I/O パスが 1 つ。
ノードから共有クラスタストレージまでの I/O パスを 2 つ以上管理できる、サポート対象のマルチパスソリューション (Sun Traffic Manager、EMC PowerPath、Hiatchi HDLM)。
詳細については、 VxVM のインストールマニュアルを参照してください。
UFS と VxFS のクラスタファイルシステムにはロギングが必要です。この要件は、QFS 共有ファイルシステムには適用されません。Sun Cluster ソフトウェアでは、次のロギングファイルシステムがサポートされています。
Solstice DiskSuite トランスメタデバイスロギング または Solaris ボリュームマネージャートランザクションボリュームロギング – 詳細は、『Solstice DiskSuite 4.2.1 ユーザーズガイド』の第 2 章「DiskSuite オブジェクトの作成」またはSolaris ボリュームマネージャの管理の「トランザクションボリューム (概要)」を参照してください。Solaris 10 のリリースの Solaris ボリュームマネージャーでは、トランザクションボリュームは有効ではなくなりました。
SPARC:VERITAS File System (VxFS) ロギング – 詳細は、VxFS ソフトウェア付属の mount_vxfs のマニュアルページを参照してください。
次の表に、各ボリューム管理ソフトウェアでサポートされているロギングファイルシステムを示します。
表 1–5 サポートされているファイルシステムのロギング
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 方向のミラー化だけです。
異なるデバイスサイズ – 異なるサイズのデバイスにミラーを作成した場合、ミラーの容量は、最小のサブミラーまたはプレックスのサイズに制限されます。
多重ホストディスクの詳細については、『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 ファイルが変更されることがあります。
起動プログラムは、システムがミラーまたは元の物理デバイスのどちらから起動されているのかを確認しません。起動プロセスの途中(メタデバイスまたはボリュームが読み込まれた後) でミラー化はアクティブになります。これより前の時点で、古いサブミラー問題が発生しやすくなります。