この章では、Sun Cluster をインストールする際の計画情報とガイドラインについて説明します。
この章の内容は、次のとおりです。
次の表に、Sun Cluster ソフトウエアのインストール作業の手順の参照箇所を示します。
表 1-1 Sun Cluster のインストール作業の参照箇所
作業 |
参照箇所 |
||
---|---|---|---|
クラスタハードウェアの設定 |
『Sun Cluster 3.0 U1 Hardware Guide』 サーバーや記憶装置に付属しているマニュアル |
||
クラスタソフトウェアのインストールの計画 |
第1章 『Sun Cluster 3.0 U1 ご使用にあたって』のワークシート |
||
新しいクラスタのインストール、または既存クラスタに対するノードの追加 |
|
||
|
Solaris オペレーティング環境、Cluster Control Panel (任意)、SunPlex Manager (任意)、クラスタフレームワーク、データサービスソフトウェアパッケージのインストール | ||
|
ボリューム管理ソフトウェアのインストールと構成 |
|
|
|
|
Solstice DiskSuite |
Solstice DiskSuite のマニュアル |
|
|
VERITAS Volume Manager (VxVM) |
VxVM のマニュアル |
|
クラスタフレームワークソフトウェアの構成、および Sun Management Center のインストールと構成 (Sun Management Center は任意) | ||
|
リソースグループとデータサービスの計画、インストール、構成 |
『Sun Cluster 3.0 U1 データサービスのインストールと構成』 『Sun Cluster 3.0 U1 ご使用にあたって』 の 「データサービス構成のためのワークシート(記入例)」 |
|
Solaris オペレーティング環境、クラスタフレームワーク、データサービス、ボリューム管理ソフトウェアを、Sun Cluster 2.2 から Sun Cluster 3.0 にアップグレード |
「Sun Cluster 2.2 から Sun Cluster 3.0 U1 へのアップグレード」 「Solstice DiskSuite の構成」 または 「VxVM ソフトウェアのインストールと構成」 ボリューム管理ソフトウェアのマニュアル |
||
カスタムデータサービスの開発 |
『Sun Cluster 3.0 U1 データサービス開発ガイド』 |
この節では、クラスタ環境への Solaris ソフトウェアのインストールを計画するうえでのガイドラインを説明します。Solaris ソフトウェアの詳細については、Solaris のインストールマニュアルを参照してください。
Solaris ソフトウェアは、ローカルの CD-ROM から、あるいは JumpStartTM によるインストール方法でネットワークインストールサーバーからインストールできます。また Sun Cluster では、JumpStart を使用して、Solaris オペレーティング環境と Sun Cluster ソフトウェアを同時にインストールするカスタマイズ方法もあります。複数のクラスタノードをインストールする場合は、ネットワークインストールを検討してください。
scintall JumpStart によるインストール方法の詳細については、「Solaris と Sun Cluster ソフトウェアをインストールする (JumpStart)」を参照してください。Solaris の標準的なインストール方法の詳細については、Solaris のインストールマニュアルを参照してください。
『Sun Cluster 3.0 U1 ご使用にあたって』の「ローカルファイルシステム配置のワークシート」に次の情報を追加してください。
Solaris オペレーティング環境をインストールするときは、必要な Sun Cluster パーティションを作成し、すべてのパーティションが各領域の最小必要条件を満たすようにします。
スワップ - 少なくとも 750M バイト、または物理メモリーの 2 倍のどちらか大きい方を割り当てます。
/globaldevices - scinstall(1M) ユーティリティが広域デバイスのために使用する 100M バイトのファイルシステムを作成します。
ボリューム管理ソフトウェア - ボリューム管理ソフトウェアが使用できるように、ディスク終端のスライス (スライス 7) に 10M バイトのパーティションを作成します。クラスタで VERITAS Volume Manager (VxVM) を使用しており、ルートディスクをカプセル化する予定の場合は、VxVM で使用できるように、2 つの未使用スライスを用意します。
Solaris オペレーティング環境を対話的にインストールする場合は、上記の必要条件を満たすためにパーティションをカスタマイズする必要があります。
追加のパーティションを計画する際の情報については、次のガイドラインを参照してください。
Solaris オペレーティング環境を実行する他のシステムと同様に、ルート (/)、/var、/usr、/opt の各ディレクトリを別個のファイルシステムとして構成したり、ルート (/) ファイルシステムのすべてのディレクトリを含めることができます。次に、Sun Cluster 構成でのルート (/), /var, /usr、/opt の各ディレクトリのソフトウェアの内容を示します。スキーマのパーティション分割を計画するときは、次の情報を検討してください。
ルート (/) - Sun Cluster ソフトウェア自体は、ルート (/) ファイルシステムの 40M バイト未満の領域しか占有しません。また、Solstice DiskSuiteTM ソフトウェアには 5M バイト未満、VxVM ソフトウェアには 15M バイト未満の領域しか必要ありません。特にクラスタ内に多数の共有ディスクがある場合は、最適な結果が得られるよう、ブロック型特殊デバイスと、Solstice DiskSuite または VxVM ソフトウェアで使用される文字型特殊デバイスの両方を作成するための、十分な領域と i ノード容量を構成しておく必要があります。したがって、一般的にルート (/) ファイルシステムに割り当てる容量に、最低でも 100M バイトを追加します。
/var - Sun Cluster ソフトウェアは、インストール時には /var ファイルシステムのわずかな領域しか占有しません。ただし、ログファイル用に十分な領域を別途用意しておく必要があります。また、クラスタ化されたノードでは、標準的なスタンドアロンサーバーよりも、ログに記録されるメッセージが増えることがあります。したがって、/var ファイルシステムには最低でも 100M バイトの余裕を設けてください。
/usr - Sun Cluster ソフトウェアは、/usr ファイルシステムの 25M バイト未満の領域を占有します。Solstice DiskSuite および VxVM ソフトウェアは、それぞれ 15M バイト未満が必要です。
/opt - Sun Cluster フレームワークソフトウェアは、/opt ファイルシステムの 2M バイト未満を使用します。ただし、各 Sun Cluster データサービスで 1M 〜 5M バイトが使用されることがあります。Solstice DiskSuite ソフトウェアは /opt ファイルシステムの領域をまったく使用しません。VxVM ソフトウェアは、そのパッケージとツールをすべてインストールした場合、40M バイト以上を使用することがあります。また、ほとんどのデータベースおよびアプリケーションソフトウェアは、/opt ファイルシステムにインストールされます。SunTM Management Center ソフトウェア (以前の名称は Sun Enterprise SyMONTM) を使用してクラスタを監視する場合は、Sun Management Center エージェントおよび Sun Cluster モジュールパッケージをサポートするために、各ノードごとにさらに 25M バイトの領域が必要です。
スワップパーティションの最小サイズは、750M バイトまたはマシンの物理メモリーの 2 倍の、どちらか大きい方にします。インストールする Sun 以外のアプリケーションでも、スワップが必要な場合があります。スワップの要件については、各アプリケーションのマニュアルを参照してください。
Sun Cluster ソフトウェアでは、広域デバイスの管理に使用するローカルディスクのいずれかに、特殊なファイルシステムを別途用意しておく必要があります。このファイルシステムは、後にクラスタファイルシステムとしてマウントされるため、独立したものにしてください。このファイルシステムには、scinstall(1M) コマンドで認識されるデフォルトの名前 /globaldevices を付けます。ファイルシステムの名前は、scinstall(1M) コマンドによって後で /global/.devices/node@nodeid (nodeid は、クラスタメンバーになったときにノードに割り当てられる数) に変更され、元の /globaldevice マウントポイントは削除されます。特にクラスタ内に多数のディスクがある場合は、/globaldevices ファイルシステムに、ブロック型の特殊デバイスと文字型の特殊デバイスの両方を作成するための十分な領域と i ノードの容量が必要です。ほとんどのクラスタ構成には、100M バイトのファイルシステムサイズで十分です。
Solstice DiskSuite ソフトウェアを使用する場合、複製データベースの作成に使用できるように、ルートディスク上にスライスを別途用意しておく必要があります。つまり、各ローカルディスク上に、このためのスライスを別に用意します。ただし 1 つのノードにローカルディスクが 1 つしかない場合は、Solstice DiskSuite ソフトウェアが正しく動作するように、同じスライス内に 3 つの複製データベースを作成する必要が生じることがあります。詳細については、Solstice DiskSuite のマニュアルを参照してください。
VxVM を使用しており、ルートディスクをカプセル化する予定の場合は、VxVM が使用する 2 つの未使用スライスのほかに、ディスクの始点または終点に若干の未割り当て空き領域も必要になります。ルートディスクのカプセル化については、VxVM のマニュアルを参照してください。
表 1-2 に、750M バイト未満の物理メモリーを持つクラスタノードのパーティション分割スキーマを示します。このスキーマは、Solaris オペレーティング環境の「エンドユーザーシステムサポート」ソフトウェアグループ、Sun Cluster ソフトウェア、および Sun Cluster HA for NFS データサービスと共にインストールされます。ディスク上の最後のスライスであるスライス 7 には、ボリューム管理ソフトウェア用に小容量が割り当てられます。
このような配置は、Solstice DiskSuite ソフトウェアまたは VxVM の使用を意図したものです。Solstice DiskSuite ソフトウェアを使用する場合は、複製データベース用にスライス 7 を使用します。VxVM を使用する場合は、後でゼロの長さを割り当てることにより、スライス 7 を開放できます。この配置によって 必要な 2 つのスライス 4 と 7 が確保され、ディスクの終端に未使用領域が確保されます。
表 1-2 ファイルシステム割り当て例
スライス |
内容 |
割り当て (M バイト) |
説明 |
---|---|---|---|
0 |
/ |
1168 |
441M バイト - Solaris オペレーティング環境ソフトウェア用 100M バイト - ルート (/) 用の追加分 100M バイト - /var 用の追加分 25M バイト - Sun Cluster ソフトウェア用 55M バイト - ボリューム管理ソフトウェア用 1M バイト - Sun Cluster HA for NFS ソフトウェア用 25M バイト - Sun Management Center エージェントおよび Sun Cluster モジュールエージェントパッケージ用 421M バイト (ディスクの残りの空き容量) - データベースやアプリケーションソフトウェアで将来的に使用 |
1 |
スワップ |
750 |
物理メモリーが 750M バイト未満の場合の最小サイズ |
2 |
オーバーラップ |
2028 |
ディスク全体 |
3 |
/globaldevices |
100 |
このスライスは、Sun Cluster ソフトウェアによって後で別のマウントポイントに割り当てられ、クラスタファイルシステムとしてマウントされます。 |
4 |
未使用 |
- |
VxVM でルートディスクをカプセル化するための空きスライスとして確保されます。 |
5 |
未使用 |
- |
|
6 |
未使用 |
- |
|
7 |
ボリューム管理ソフトウェア |
10 |
Solstice DiskSuite ソフトウェアにより複製データベース用に使用されるか、VxVM によりスライス開放後のインストールに使用されます。 |
この節では、Sun Cluster ソフトウェアのインストールの計画と準備のガイドラインについて説明します。Sun Cluster コンポーネントの詳細については、『Sun Cluster 3.0 U1 の概念』を参照してください。
ソフトウェアのインストールを始める前に、必要なライセンス証明書を用意しておきます。Sun Cluster ソフトウェアにはライセンス証明書は必要ありませんが、Sun Cluster ソフトウェアと共にインストールされる各ノードが、Sun Cluster ソフトウェア使用許諾契約書に準拠している必要があります。
ボリューム管理ソフトウェアやアプリケーションソフトウェアのライセンス必要条件については、該当する製品のインストールマニュアルを参照してください。
各ソフトウェア製品をインストールした後に、必要なパッチもインストールする必要があります。必須パッチの最新リストについては、『Sun Cluster 3.0 U1 ご使用にあたって』を参照するか、ご購入先にお問い合わせください。パッチを適用するうえでの一般的なガイドラインと手順については、『Sun Cluster 3.0 U1 のシステム管理』を参照してください。
クラスタ構成によっては、Sun Cluster のさまざまなコンポーネントに多数の IP アドレスを設定する必要があります。クラスタ構成内の各ノードにはパブリックサブネットの同じセットとのパブリックネットワーク接続が少なくとも 1 つ必要です。
次の表に、IP アドレスの割り当てが必要なコンポーネントの一覧を示します。使用する任意のネームサービスにこれらの IP アドレスを追加してください。また、Solaris ソフトウェアをインストールした後で、各クラスタノードのローカル /etc/inet/hosts ファイルにもこれらの IP アドレスを追加します。
表 1-3 IP アドレスを使用する Sun Cluster コンポーネント
コンポーネント |
必要な IP アドレス |
---|---|
管理コンソール |
サブネットあたり 1 つ |
クラスタノード |
ノードおよびサブネットごとに 1 つずつ |
端末集配信装置またはシステムサービスプロセッサ |
1 |
論理アドレス |
論理ホストリソースおよびサブネットあたり 1 つずつ |
端末集配信装置 (コンセントレータ) は、管理コンソールとクラスタノードコンソール間で通信します。Sun EnterpriseTM E10000 サーバーは、端末集配信装置ではなく、システムサービスプロセッサ (SSP) を使用します。コンソールアクセスの詳細については、『Sun Cluster 3.0 U1 の概念』を参照してください。
論理アドレスを使用する各データサービスリソースグループには、論理アドレスへのアクセス元となる各パブリックネットワークに指定されているホスト名を設定する必要があります。リソースグループの計画に関する情報とワークシートについては、『Sun Cluster 3.0 U1 データサービスのインストールと構成』を参照してください。データサービスとリソースの詳細については、『Sun Cluster 3.0 U1 の概念』も参照してください。
この節では、インストール中に構成する Sun Cluster コンポーネントのガイドラインについて説明します。
『Sun Cluster 3.0 U1 ご使用にあたって』の「クラスタ名とノード名のワークシート」に次の計画情報を追加してください。
クラスタ名は、Sun Cluster のインストールの際に指定します。クラスタ名は、インストール環境全体で一意にする必要があります。
『Sun Cluster 3.0 U1 ご使用にあたって』の「クラスタ名とノード名のワークシート」に次の計画情報を追加してください。その他のほとんどのワークシートに関する情報は、ノード名ごとにまとめられています。
ノード名とは、Solaris オペレーティング環境のインストール中にマシンに割り当てる名前のことです。Sun Cluster のインストール中に、クラスタとしてインストールするすべてのノード名を指定します。
『Sun Cluster 3.0 U1 ご使用にあたって』の「クラスタ名とノード名のワークシート」に次の計画情報を追加してください。
Sun Cluster ソフトウェアは、ノード間の内部通信にプライベートネットワークを使用します。Sun Cluster では、プライベートネットワーク上のクラスタインターコネクトへの接続が少なくとも 2 つ必要です。クラスタの最初のノードに Sun Cluster ソフトウェアをインストールするときに、プライベートネットワークアドレスとネットマスクを指定します。デフォルトのプライベートネットワークアドレス (172.16.0.0) とネットマスク (255.255.0.0) をそのまま使用するように選択するか、デフォルトのネットワークアドレスがすでに使用中の場合は別のアドレスを入力できます。
デフォルト以外のプライベートネットワークアドレスを指定する場合は、次の条件を満たす必要があります。
ノードをクラスタメンバーとして正常にインストールした後で、プライベートネットワークアドレスとネットマスクを変更することはできません。
アドレスの最後の 2 つのオクテットにはゼロを使用する。
RFC 1597 のネットワークアドレス割り当てガイドラインに従う。
RFC のコピーの入手方法については、『TCP/IP and Data Communications Administration Guide』を参照してください。
デフォルト以外のネットマスクを指定する場合は、以下の条件を満たす必要があります。
少なくとも、プライベートネットワークアドレスに指定したすべてのビットをマスクする。
"ホール" がないようにする。
『Sun Cluster 3.0 U1 ご使用にあたって』の「クラスタ名とノード名のワークシート」に次の計画情報を追加してください。
プライベートホスト名とは、プライベートネットワークインタフェースを介したノード間の通信に使用される名前のことです。プライベートホスト名は、clusternodenodeid-priv という命名規則に従って、Sun Cluster のインストール中に自動的に作成されます (nodeid は内部ノード ID の数値)。このノード ID 番号は、Sun Cluster のインストール中に各ノードがクラスタメンバーとなる際に、自動的に各ノードに割り当てられます。インストール後に、scsetup(1M) ユーティリティを使用してプライベートホスト名を変更できます。
『Sun Cluster 3.0 U1 ご使用にあたって』の「クラスタインターコネクトのワークシート」に次の計画情報を追加してください。
クラスタインターコネクトは、クラスタノード間のプライベートネットワーク通信にハードウェアパスを提供します。各インターコネクトは、2 つのトランスポートアダプタの間、トランスポートアダプタとトランスポート接続点の間、または 2 つのトランスポート接続点の間を接続するケーブルで構成されます。Sun Cluster のインストール中に、2 つのクラスタインターコネクトに対して以下の構成情報を指定します。
トランスポートアダプタ - ネットワークインタフェースのポートなどのトランスポートアダプタ用に、トランスポートアダプタ名とトランスポートの種類を指定します。構成が 2 ノードクラスタの場合は、インターコネクトを直接接続 (アダプタからアダプタ) するか、トランスポート接続点を使用するかも指定します。2 ノードクラスタが直接接続されている場合でも、インターコネクトのトランスポート接続点を指定できます。トランスポート接続点を指定すると、その後クラスタに別のノードを追加しやすくなります。
トランスポート接続点 - ネットワークスイッチなどのトランスポート接続点を使用する場合は、各インターコネクトのトランスポート接続点名を指定します。デフォルト名の switchN (N は、インストール中に自動的に割り当てられた数)を使用するか、他の名前を作成します。
また、接続点のポート名を指定するか、デフォルト名をそのまま使用します。デフォルトのポート名は、ケーブルのアダプタ側が接続されているノードの内部ノード ID 番号と同じです。ただし、SCI などの特定の種類のアダプタではデフォルトのポート名は使用できません。
3 つ以上のノードを持つクラスタでは、必ずトランスポート接続点を使用してください。クラスタノード間の直接接続は、2 ノードクラスタの場合だけサポートされています。
インストール後に、scsetup(1M) ユーティリティを使用して、追加のプライベートネットワーク接続を構成できます。
クラスタインターコネクトの詳細については『Sun Cluster 3.0 U1 の概念』を参照してください。
『Sun Cluster 3.0 U1 ご使用にあたって』の「パブリックネットワークのワークシート」に次の計画情報を追加してください。
パブリックネットワークはクラスタの外部と通信します。パブリックネットワーク構成を計画する際は、次のことを考慮してください。
パブリックネットワークとプライベートネットワーク (クラスタインターコネクト) には、別のアダプタを使用する必要があります。
すべてのクラスタノードに接続されているパブリックネットワークが少なくとも 1 つ存在する必要があります。
パブリックネットワーク接続は、ハードウェア構成の許容範囲であればいくつでも追加できます。
local-mac-address 変数は、デフォルト値である false を使用する必要があります。Sun Cluster ソフトウェアは、local-mac-address の値として true をサポートしません。
パブリックネットワークアダプタのバックアップグループの計画のガイドラインについては、「NAFO グループ」も参照してください。 ネットワークインタフェースの詳細については、『Sun Cluster 3.0 U1 の概念』を参照してください。
『Sun Cluster 3.0 U1 ご使用にあたって』の「ディスクデバイスグループ構成のワークシート」に次の計画情報を追加してください。
すべてのボリューム管理ソフトウェアディスクグループを Sun Cluster ディスクデバイスグループとして構成する必要があります。このように構成することで、主ノードに障害が発生した場合でも、2 つ目のノードで多重ホストディスクをホストできるようになります。ディスクデバイスグループを計画する際は、次の点を考慮してください。
フェイルオーバー - 多重ポートディスクと、適切に構成したボリューム管理ソフトウェアデバイスをフェイルオーバーデバイスとして構成できます。ボリューム管理ソフトウェアデバイスの適切な構成には、多重ポートディスクやエクスポートしたデバイスを複数のノードでホストできるように、ボリューム管理ソフトウェア自体を正しく設定する作業が含まれます。テープドライブ、CD-ROM、単一ポートディスクは、フェイルオーバーデバイスとして構成できません。
ミラー化 - ディスクをミラー化して、ディスクの障害からデータを保護する必要があります。ミラー化の方法については、「Solstice DiskSuite の構成」と 「VxVM ソフトウェアのインストールと構成」、およびボリューム管理ソフトウェアのマニュアルを参照してください。
ディスクデバイスグループの詳細については、『Sun Cluster 3.0 U1 の概念』を参照してください。
『Sun Cluster 3.0 U1 ご使用にあたって』の「パブリックネットワークのワークシート」に次の計画情報を追加してください。
ネットワークアダプタフェイルオーバー (NAFO) グループは、パブリックネットワークアダプタの監視とフェイルオーバーを提供しており、ネットワークアドレスリソースの基礎となるものです。2 つ以上のアダプタで構成されている NAFO グループのアクティブなアダプタに障害が発生すると、そのアドレスはすべて NAFO グループ内の別のアダプタにフェイルオーバーされます。アクティブな NAFO グループアダプタは、このような方法で、NAFO グループ内のアダプタが接続されているサブネットへのパブリックネットワークの接続を維持します。
NAFO グループを計画する際は、次の点を考慮してください。
各パブリックネットワークアダプタは、NAFO グループに属している必要があります。
各ノードでは、サブネットごとに 1 つの NAFO グループのみ使用できます。
特定の NAFO グループ内の 1 つのアダプタだけが、/etc/hostname.adapter ファイルという形式で、ホスト名の関連付けを使用できます。
NAFO グループの命名規則は nafoN (N は NAFO グループの作成時に指定した数) です。
ネットワークアダプタフェイルオーバーの詳細については、『Sun Cluster 3.0 U1 の概念』を参照してください。
Sun Cluster 構成では、定足数 (quorum) デバイスを使用して、データとリソースの整合性を保持します。クラスタがノードとの接続を一時的に失っても、定足数デバイスによって、クラスタノードがクラスタに再結合しようとしたときの amnesia や split-brain といった問題を防止できます。定足数デバイスは、scsetup(1M) ユーティリティを使用して割り当てることができます。
定足数デバイスを計画する際は、次のことを考慮してください。
最小限 - 2 ノードクラスタには、少なくとも 1 つの共有ディスクが定足数デバイスとして割り当てられている必要があります。その他のトポロジの場合は、定足数デバイスはオプションです。
奇数の規則 - 2 ノードクラスタまたは定足数デバイスに直接接続されているノードペアで複数の定足数デバイスが構成されている場合、定足数デバイスが完全に独立した障害パスを持つように、奇数個の定足数デバイスを構成します。
接続- 定足数デバイスが接続できるノードは 2 つまでです。
定足数 (quorum) についての詳細は、『Sun Cluster 3.0 U1 の概念』を参照してください。
この節では、広域デバイスとクラスタファイルシステムを計画する上でのガイドラインを説明します。広域デバイスとクラスタファイルシステムの詳細については、『Sun Cluster 3.0 U1 の概念』を参照してください。
Sun Cluster は、特定のディスク配置あるいはファイルシステムサイズを必要としません。広域デバイスとクラスタファイルシステムを計画する際は、次のことを考慮してください。
ミラー化 - 広域デバイスの高可用性を実現するには、すべての広域デバイスをミラー化する必要があります。
ディスク - ミラー化するときは、複数のディスクアレイにまたがってミラー化されるように配置してください。
可用性 - 広域デバイスの高可用性を実現するには、広域デバイスがクラスタ内の複数のノードに物理的に接続されている必要があります。複数の物理的な接続を持つ広域デバイスは、単一のノードでの障害に対応できます。物理的な接続を 1 つしか持たない広域デバイスもサポートされていますが、そのノードがダウンした場合、ほかのノードからはその広域デバイスにアクセスできなくなります。
クラスタファイルシステムのマウントポイントを計画する際は、次の点を考慮してください。
マウントポイントの場所 - マウントポイントは、別のソフトウェア製品によって禁止されていない限り、/global ディレクトリに作成します。/global ディレクトリを使用することで、広域的に使用できるクラスタファイルシステムと、ローカルファイルシステムを簡単に区別できるようになります。
マウントポイントを入れ子にする - 通常は、クラスタファイルシステムのマウントポイントは入れ子にしないでください。たとえば、あるファイルシステムを /global/a にマウントし、別のファイルをシステムは /global/a/b にマウントするような設定は避けてください。この規則を無視すると、システムがファイルシステムの子をマウントしようと試み、親マウントポイントが存在しない場合に、可用性とノードの起動順序に問題が発生することがあります。この規則の唯一の例外は、2 つのファイルシステムのデバイスが同じ物理ノード接続を使用している場合です (同じディスク上の異なるスライスなど)。
この節の計画情報を、『Sun Cluster 3.0 U1 ご使用にあたって』の「ディスクデバイスグループ構成のワークシート」と「ボリューム管理ソフトウェア構成のワークシート」に追加してください。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 U1 の概念』を参照してください。
ディスクを構成する際は、次の一般的なガイドラインを考慮してください。
ミラー化多重ホストディスク - すべての多重ホストディスクは、複数のディスク拡張装置にまたがるようにミラー化する必要があります。多重ホストディスクのガイドラインについては、「多重ホストディスクのミラー化」を参照してください。
ミラー化ルート - ルートディスクをミラー化することにより高可用性を保証できますが、このようなミラー化は必要ありません。ルートディスクをミラー化するかどうかを判断する際のガイドラインについては、「ミラー化に関するガイドライン」を参照してください。
一意の命名 - 任意のクラスタノード上で、ローカルの Solstice DiskSuite メタデバイスまたは VxVM ボリュームが、/global/.devices/node@nodeid ファイルシステムをマウントするデバイスとして使用されている場合、そのメタデバイスまたはボリュームの名前はクラスタ全体で一意にする必要があります。
ノードリスト - ディスクデバイスグループの高可用性を実現するには、それらの潜在マスターのノードリストとフェイルバックポリシーを、関連付けられているリソースグループと同一にします。または、スケーラブルなリソースグループで、それと関連付けられているディスクデバイスグループ以上のノードが使用されている場合、スケーラブルなリソースグループのノードリストをディスクデバイスグループのノードリストのスーパーセットにします。ノードリストについての詳細は、『Sun Cluster 3.0 U1 データサービスのインストールと構成』のリソースグループの計画情報を参照してください。
多重ポートディスク- クラスタ内でディスクグループの構築に使用されているディスクはすべて、そのデバイスグループのノードリストで構成されているすべてのノードに接続 (またはポート) する必要があります。Solstice DiskSuite ソフトウェアは、ディスクセットにディスクを追加したときに、これを自動的に確認できます。ただし、構成した VxVM ディスクグループは、特定のセットのノードとは関連付けられていません。また、Solstice DiskSuite ディスクセット、VxVM ディスクグループ、または個々のセットの広域デバイスを広域デバイスグループとしてクラスタ化ソフトウェアに登録するときは、一部の接続確認しか実行できません。
ホットスペアディスク - ホットスペアディスクは可用性を高めるために使用できますが、必須ではありません。
ディスクの配置の推奨事項とその他の制限については、ボリューム管理ソフトウェアのマニュアルを参照してください。
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 (VxVM) の構成を計画する際は、次のことを考慮してください。
ルートディスクグループ - 各ノードにデフォルトのディスクデバイスグループ (rootdg) を作成する必要があります。rootdg ディスクグループは次のディスク上に作成できます。
ルートディスク (カプセル化されている必要がある)
ルート以外の 1 つまたは複数のローカルディスク (カプセル化または初期化できるもの)
ルートディスクとルート以外のローカルディスクの組み合わせ
rootdg ディスクグループは、ノードに対してローカルである必要があります。
カプセル化 - カプセル化するディスクには、2 つのディスクスライステーブルエントリを空けておく必要があります。
ボリューム数 - ディスクデバイスグループを作成するときに任意のディスクデバイスグループが使用するボリュームの最大数を確認します。
ボリューム数が 1000 未満の場合は、デフォルトのミラー数を使用できます。
ボリューム数が 1000 以上の場合は、ディスクデバイスグループボリュームへのマイナー番号の割り当て方を慎重に計画する必要があります。2 つのディスクデバイスグループに、オーバーラップするマイナー番号を割り当てることはできません。
ダーティーリージョンログ - ダーティーリージョンログ (DRL) の使用を推奨しますが、必須ではありません。DRL を使用すると、ノードに障害が発生した後に、ボリュームの回復時間を短縮できます。また、DRL を使用することで入出力のスループットを低減できることがあります。
ロギングはクラスタファイルシステムに必要です。Sun Cluster では、次のロギングファイルシステムがサポートされています。
Solaris UFS ロギング
Solstice DiskSuite トランスメタデバイス UNIX ファイルシステム (UFS) ロギング
Solstice DiskSuite トランスメタデバイス UFS ロギングの詳細については、Solstice DiskSuite のマニュアルを参照してください。Solaris UFS ロギングの詳細については、mount_ufs(1M) のマニュアルページを参照してください。
次の表に、各ボリューム管理ソフトウェアでサポートされているロギングファイルシステムを示します。
表 1-4 サポートされているファイルシステムのロギング一覧表
ボリューム管理ソフトウェア |
サポートされているファイルシステムのロギング |
---|---|
Solstice DiskSuite |
Solaris UFS ロギング、Solstice DiskSuite トランスメタデバイス 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 ロギングを管理します。トランスメタデバイスのロギングデバイスコンポーネントは、ミラー化とストライプ化が可能なメタデバイスです。最大 1G バイトのログを作成できますが、ほとんどのファイルシステムでは 64M バイトで十分です。最小のログサイズは 1M バイトです。トランスメタデバイスによるロギングの詳細は、Solstice DiskSuite のマニュアルを参照してください。
この節では、クラスタ構成のミラー化を計画する際のガイドラインについて説明します。
Sun Cluster 構成で多重ホストディスクをミラー化することにより、構成は単一のディスク障害に耐えることができます。Sun Cluster ソフトウェアでは、すべての多重ホストディスクは、複数のディスク拡張装置にまたがるようにミラー化する必要があります。
多重ホストディスクをミラー化する際は、次のことを考慮してください。
独立したディスク拡張装置 - ミラーまたはプレックスのサブミラーは、それぞれ異なる多重ホストディスク拡張装置に分散してください。
ディスク領域 - ミラー化すると、2 倍のディスク領域が必要になります。
3 方向のミラー化 - Solstice DiskSuite ソフトウェアと VERITAS Volume Manager (VxVM) は、3 方向のミラー化をサポートしています。ただし、Sun Cluster が必要とするのは、2 方向のミラー化だけです。
メタデバイス数 - Solstice DiskSuite ソフトウェアでは、ミラーは連結やストライプなどの他のメタデバイスで構成されます。大規模な構成では、大量のメタデバイスが含まれることがあります。たとえば、UFS ロギングファイルシステムごとに 7 つのメタデバイスが作成されます。
異なるディスクサイズ - 異なるサイズのディスクにミラーを作成した場合、ミラーの容量は、最小のサブミラーまたはプレックスのサイズに制限されます。
多重ホストディスクの詳細については、『Sun Cluster 3.0 U1 の概念』を参照してください。
この節の計画情報を『Sun Cluster 3.0 U1 ご使用にあたって』の「ローカルファイルシステム配置のワークシート」に追加してください。
最高の可用性を得るには、ローカルディスク上のルート (/)、/usr、/var、/opt、swap をミラー化してください。VxVM では、ルートディスクをミラー化し、生成されたサブディスクをミラー化します。ただし、Sun Cluster では、ルートディスクのミラー化は必須ではありません。
ルートディスクをミラー化するかどうかを決める前に、危険性、複雑さ、コスト、保守時間の面からルートディスクに関するさまざまな方法を検討してください。どの構成でも有効に機能するというような汎用的なミラー化はありません。ルートをミラー化するかどうかを決定するにあたっては、ご購入先に相談してください。
ルートディスクのミラー化については、使用するボリューム管理ソフトウェアのマニュアルと、「Solstice DiskSuite の構成」 または、「VxVM ソフトウェアのインストールと構成」 を参照してください。
ルートディスクをミラー化するかどうかを決定する際は、次のことを考慮してください。
複雑さ - ルートディスクをミラー化すると、システム管理の複雑さが増し、シングルユーザーモードでの起動が複雑になります。
バックアップ - ルートディスクをミラー化するかどうかに関係なく、ルートは定期的にバックアップしてください。ミラー化だけで、管理上の誤りが防げるわけではありません。誤って変更あるいは削除したファイルは、バックアップによってのみ復元できます。
定足数 (quorum) デバイス - 定足数デバイスとして構成されたディスクは、ルートディスクのミラー化に使用しないでください。
定足数 (quorum) - Solstice DiskSuite の構成で、メタデバイス状態データベースの定足数が失われるという障害が発生した場合は、保守を行わない限り、システムを再起動できなくなります。メタデバイス状態データベースと状態データベースの複製の詳細については、Solstice DiskSuite のマニュアルを参照してください。
独立したコントローラ - 独立したコントローラにルートディスクをミラー化するという方法は、最高の可用性を得る手段の 1 つです。
起動ディスク - 起動可能ルートディスクをミラーとして設定すると、主起動ディスクに障害が発生した場合にミラーから起動できます。
二次ルートディスク - ミラー化したルートディスクを使用すると、主起動ディスクに障害が発生しても、二次 (ミラー) ルートディスクで動作を継続できます。電源を入れ直したことにより、あるいは一時的に入出力エラーであったために、後で主ルートディスクが正常に戻った場合、以降の起動は、OpenBootTM PROM の boot-device フィールドに指定された主ルートディスクを使用して行われます。このような場合、手作業で修復作業を行わなくても、起動に問題がないようにドライブは動作を開始します。このとき、Solstice DiskSuite の再同期が行われます。再同期をするには、ドライブが正常に戻ったときに手作業が必要になります。この状況では、手作業による修復作業はありません。
二次 (ミラー) ルートディスク上のファイルに変更が加えられている場合、起動中に、その変更が主ルートデバイスに反映されることはなく、サブミラーは無効になります。たとえば、/etc/system ファイルに対する変更が失われることがあります (主ルートディスクが休止している間に、一部の Solstice DiskSuite 管理コマンドによって、/etc/system ファイルが変更されることがあります)。
起動プログラムは、ミラーまたは元の物理デバイスのどちらから起動が行われているのかを確認しません。起動プロセスの途中 (メタデバイスが読み込まれた後) でミラー化はアクティブになります。これより前の時点では、サブミラーが無効になる問題が発生しやすくなります。