3. グループリソースの詳細

本章では、フェイルオーバグループを構成するグループリソースについての詳細を説明します。

グループの概要については、『インストール&設定ガイド』の「クラスタシステムを設計する」を参照 してください。

• 3.1. グループリソースの一覧

• 3.2. グループとは?

• 3.3. グループ共通のプロパティ

• 3.4. グループのプロパティ

• 3.5. リソースのプロパティ

• 3.6. アプリケーションリソースを理解する

• 3.7. フローティング IP リソースを理解する

• 3.8. ミラーディスクリソースを理解する

• 3.9. レジストリ同期リソースを理解する

• 3.10. スクリプトリソースを理解する

• 3.11. ディスクリソースを理解する

• 3.12. サービスリソースを理解する

• 3.13. 仮想コンピュータ名リソースを理解する

• 3.14. ダイナミック DNSリソースを理解する

• 3.15. 仮想 IP リソースを理解する

• 3.16. CIFS リソースを理解する

• 3.17. ハイブリッドディスクリソースを理解する

• 3.18. AWS Elastic IPリソースを理解する

• 3.19. AWS 仮想IPリソースを理解する

• 3.20. AWS セカンダリ IP リソースを理解する

• 3.21. AWS DNS リソースを理解する

• 3.22. Azure プローブポートリソースを理解する

• 3.23. Azure DNS リソースを理解する

• 3.24. Google Cloud 仮想 IP リソースを理解する

• 3.25. Google Cloud DNS リソースを理解する

• 3.26. Oracle Cloud 仮想 IP リソースを理解する

3.1. グループリソースの一覧

現在サポートされているグループリソースは以下のとおりです。

グループリソース名	略称	機能概要
アプリケーションリソース	appli	「 アプリケーションリソースを理解する 」 を参照
フローティング IP リソース	fip	「 フローティング IP リソースを理解する 」 を参照
ミラーディスクリソース	md	「 ミラーディスクリソースを理解する 」 を参照
レジストリ同期リソース	regsync	「 レジストリ同期リソースを理解する 」 を参照
スクリプトリソース	script	「 スクリプトリソースを理解する 」 を参照
ディスクリソース	sd	「 ディスクリソースを理解する 」 を参照
サービスリソース	service	「 サービスリソースを理解する 」 を参照
仮想コンピュータ名リソース	vcom	「 仮想コンピュータ名リソースを理解する 」 を参照
ダイナミックDNSリソース	ddns	「 ダイナミック DNSリソースを理解する 」 を参照
仮想 IP リソース	vip	「 仮想 IP リソースを理解する 」 を参照
CIFS リソース	cifs	「 CIFS リソースを理解する 」 を参照
ハイブリッドディスクリソース	hd	「 ハイブリッドディスクリソースを理解する 」 を参照
AWS Elastic IPリソース	awseip	「 AWS Elastic IPリソースを理解する 」 を参照
AWS 仮想IPリソース	awsvip	「 AWS 仮想IPリソースを理解する 」 を参照
AWS セカンダリ IP リソース	awssip	「 AWS セカンダリ IP リソースを理解する 」 を参照
AWS DNS リソース	awsdns	「 AWS DNS リソースを理解する 」 を参照
Azure プローブポートリソース	azurepp	「 Azure プローブポートリソースを理解する 」 を参照
Azure DNS リソース	azuredns	「 Azure DNS リソースを理解する 」 を参照
Google Cloud 仮想 IP リソース	gcvip	「 Google Cloud 仮想 IP リソースを理解する 」 を参照
Google Cloud DNS リソース	gcdns	「 Google Cloud DNS リソースを理解する 」 を参照
Oracle Cloud 仮想 IP リソース	ocvip	「 Oracle Cloud 仮想 IP リソースを理解する 」 を参照

3.2. グループとは?

グループとはフェイルオーバを行う単位です。各グループにおいてフェイルオーバ時の動作に関する規則 (フェイルオーバポリシー) が設定できます。

3.2.1. グループタイプを理解する

グループには以下のタイプがあります。

• フェイルオーバグループ

  業務を継続するために必要なリソースをまとめ、業務単位でフェイルオーバを行います。各グループには最大 256のグループリソースが登録できます。

3.2.2. グループプロパティを理解する

各グループで設定可能なプロパティは以下のとおりです。

• 起動可能サーバ

  クラスタを構成するサーバからグループが起動可能なサーバを選択し設定します。

  また、起動可能なサーバに順位を設定し、グループが起動する優先順位を設定します。
• グループ起動属性

  グループの起動属性を自動起動、または手動起動に設定します。

  自動起動の場合、クラスタを開始する際に、グループが起動可能な最も優先順位の高いサーバで、グループが自動的に起動します。

  手動起動の場合、サーバが起動してもグループは起動しません。サーバ起動後、Cluster WebUI または [clpgrp] コマンドを使用してグループを手動で起動してください。Cluster WebUIの詳細はオンラインマニュアル、[clpgrp] コマンドの詳細は本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「グループを操作する (clpgrp コマンド)」を参照してください。
• フェイルオーバ属性

  フェイルオーバの方法を設定します。設定可能なフェイルオーバ属性は以下になります。
  自動フェイルオーバ

  ハートビートがタイムアウトした場合、グループリソースやモニタリソースが異常を検出した場合、それらを契機に自動でフェイルオーバを行います。

  自動フェイルオーバの場合、下記の方法を設定することができます。
  • 起動可能なサーバ設定に従う

    グループリソースやモニタリソースの異常検出を契機としてフェイルオーバが 行われる場合、そのリソースのフェイルオーバ先サーバの設定 (安定動作サーバ/最高プライオリティサーバ) に従います。また、ハートビートのタイムアウトの検出を契機としてフェイルオーバが行われる場合、起動可能なサーバに設定されているサーバのプライオリティに従い、フェイルオーバ先を決定します。

    安定動作サーバ/最高プライオリティサーバに設定した場合の動作については、「 復旧動作タブ 」および「 回復動作タブ 」を参照してください。
  • ダイナミックフェイルオーバを行う

    各サーバの監視リソースやフェイルオーバグループのステータスを考慮し、 フェイルオーバ先を決定してフェイルオーバを行います。

    フェイルオーバ先の決定の流れは以下のようになります。

  判定要素	条件	結果
  指定されたモニタリソースの状態	異常(全サーバ)	フェイルオーバ先が無い場合にモニタリソースの異常を無視してフェイルオーバを行うか判定する処理に進む。
  〃	正常( 1 台のみ)	正常なサーバをフェイルオーバ先とする。
  〃	正常(複数)	エラーレベルを比較する処理に進む。
  モニタリソースの異常を無視してフェイルオーバを行う	設定有り	指定されたモニタリソースの状態を無視し、起動している全てのサーバに対してエラーレベルを比較する処理に進む。
  〃	設定無し	フェイルオーバしない。
  エラーレベルが 最小であるサーバ数	1	異常の度合いが最小であるサーバをフェイルオーバ先とする。
  〃	2 以上	異常の度合いが最小であるサーバ内で、業務の度合いを比較する。
  サーバグループ内のフェイルオーバポリシーを優先する	設定有り かつ フェイルオーバ元と同じサーバグループ内にフェイルオーバ可能なサーバがある。	サーバグループ内のサーバをフェイルオーバ先とする。
  〃	設定有り かつ フェイルオーバ元と同じサーバグループ内にフェイルオーバ可能なサーバが無い。	スマートフェイルオーバによる判定処理に進む。
  〃	設定無し	スマートフェイルオーバによる判定処理に進む。
  スマートフェイルオーバを行う	設定有り かつ フェイルオーバ先として推奨されるサーバ数が1。	スマートフェイルオーバにより推奨されたサーバをフェイルオーバ先とする。
  〃	設定有り かつ フェイルオーバ先として推奨されるサーバ数が2以上。	ランニングレベルの判定処理に進む。
  〃	設定無し	ランニングレベルの判定処理に進む。
  ランニングレベルが 最小であるサーバ数	1	ランニングレベルが最小であるサーバをフェイルオーバ先とする。
  〃	2以上	起動しているサーバで最もプライオリティが高いサーバをフェイルオーバ先とする。

  注釈

  指定されたモニタリソース

  モニタリソースで異常を検出しているサーバをフェイルオーバ先から除外します。

  使用するモニタリソースを Cluster WebUI で設定することができます。

  エラーレベル

  異常を検出している監視リソース数。

  スマートフェイルオーバ

  System Resource Agentが収集したシステムリソース情報から負荷が最小であるサーバをフェイルオーバ先として決定する機能です。この機能を有効にするためには、フェイルオーバ先として設定されている全てのサーバにSystem Resource Agentのライセンスを登録する必要があります。また、システム監視リソースをモニタリソースに設定する必要があります。システム監視リソースについては、本ガイドの「4. モニタリソースの詳細」の「システム監視リソースを理解する」を参照してください。

  ランニングレベル

  管理グループを除く、起動済みまたは起動中のフェイルオーバグループ数。
  • サーバグループ内のフェイルオーバポリシーを優先する

    同一サーバグループ内のサーバにフェイルオーバ可能な場合、そのサーバグループ内のサーバへ優先的にフェイルオーバを行います。同一サーバグループ内でフェイルオーバ可能なサーバが無い場合、他のサーバグループ内のサーバをフェイルオーバ先とします。

    グループリソースやモニタリソースの異常検出を契機としてフェイルオーバが 行われる場合、そのリソースのフェイルオーバ先サーバの設定 (安定動作サーバ/最高プライオリティサーバ) に従います。また、ハートビートのタイムアウトの検出を契機としてフェイルオーバが行われる場合、起動可能なサーバに設定 されているサーバのプライオリティに従い、フェイルオーバ先を決定します。
  • サーバグループ間では手動フェイルオーバのみ有効とする

    上記 [サーバグループ内のフェイルオーバポリシーを優先する] が設定されている場合のみ、選択できます。

    同一サーバグループ内のサーバに対して、自動的にフェイルオーバを行います。

    同一サーバグループ内にフェイルオーバ可能なサーバが無い場合、他の サーバグループのサーバへのフェイルオーバを自動的に行うことはありません。

    他のサーバグループ内のサーバへグループを移動させるためには、Cluster WebUI または [clpgrp] コマンドでグループを移動させる必要があります。
  手動フェイルオーバ

  ハートビートがタイムアウトした際に自動でフェイルオーバを行いません。Cluster WebUI または [clpgrp] コマンドから手動でフェイルオーバを行ってください。ただし、手動フェイルオーバが設定されていても、グループリソースやモニタリソースの異常検出時には、自動的にフェイルオーバを行います。

  注釈

  外部連携監視リソースの設定で、[サーバグループ外にフェイルオーバする] が設定されている場合、ダイナミックフェイルオーバの設定やサーバグループ間のフェイルオーバ設定は無効となります。フェイルオーバ元のサーバが属するサーバグループとは別のサーバグループに属するサーバグループ内のサーバで、プライオリティが最も高いサーバにフェイルオーバします。

• フェイルオーバ属性(拡張)

  フェイルオーバ属性で設定された自動フェイルオーバの方法について、より詳細な内容を設定します。

  設定可能な内容は以下のとおりです。
  • 指定したモニタリソースで異常を検出しているサーバをフェイルオーバ先から除外する

    指定したモニタリソースで異常を検出しているサーバをフェイルオーバ先から除外します。

    フェイルオーバ属性として [起動可能なサーバ設定に従う] または [サーバグループ内のフェイルオーバポリシーを優先する] を選択した場合、本設定を有効または無効に設定できます。

    フェイルオーバ属性として [ダイナミックフェイルオーバを行う] を選択した場合、本設定は自動的に有効になります。
  • 全てのサーバで異常を検出している場合、異常を無視してフェイルオーバを行う

    上記 [指定したモニタリソースで異常を検出しているサーバをフェイルオーバ先から除外する] が設定されている場合のみ、選択できます。

    全てのサーバで異常を検出していてフェイルオーバ先が無い場合に、モニタリソースの異常を無視してフェイルオーバ先を決定します。
• フェイルバック属性

  自動フェイルバック、手動フェイルバックのどちらかを設定します。ただし、以下の条件の場合には設定できません。

  • フェイルオーバグループにミラーディスクリソースまたはハイブリッドディスクリソースが設定されている場合

  • フェイルオーバ属性が [ダイナミックフェイルオーバを行う] の場合

  自動フェイルバックの場合、フェイルオーバした後、優先順位の最も高いサーバが起動する際に自動的にフェイルバックします。

  手動フェイルバックの場合、サーバを起動してもフェイルバックは発生しません。

3.2.3. フェイルオーバポリシーを理解する

フェイルオーバポリシーとは、複数のサーバの中から、フェイルオーバ先となるサーバを決定するための規則のことで、グループの各プロパティの値で規定されます。フェイルオーバポリシーはフェイルオーバ発生時に特定のサーバに過度な負荷を与えないように設定する必要があります。

以下に、フェイルオーバ可能なサーバリストとその中でのフェイルオーバ優先順位の例を用いて、フェイルオーバ発生時のフェイルオーバポリシーによる動作の違いを説明します。

＜図中記号の説明＞

サーバ状態	説明
	正常状態 (クラスタとして正常に動作している)
	保留状態 (クラスタに復帰していない)
	停止状態 (クラスタが停止状態)

3ノードの場合

グループ	サーバの優先順位
	優先度 1 サーバ	優先度 2 サーバ	優先度 3 サーバ
A	Server 1	Server 3	Server 2
B	Server 2	Server 3	Server 1

2ノードの場合

グループ	サーバの優先順位
	優先度 1 サーバ	優先度 2 サーバ
A	Server 1	Server 2
B	Server 2	Server 1

A と B はグループ起動属性が自動起動、フェイルバック属性が手動フェイルバックに設定されているものとします。サーバは保留状態から自動復帰しないように設定されているものとします。保留状態からの自動復帰を行うかどうかは、[クラスタのプロパティ] の [拡張] タブで設定します。

• 排他属性が「通常排他」あるいは「完全排他」に設定されている排他ルールに所属し、同じサーバで起動することのできない複数のグループが、同時に同じサーバで起動あるいはフェイルオーバしようとした場合、そのサーバに対する優先順位が高いグループが優先されます。サーバの優先順位が同じ場合には、グループ名の数字、特殊記号、アルファベット順で若い方が優先されます。グループの排他属性については、「グループの排他制御を理解する」を参照してください。

• 管理用グループのフェイルオーバ優先順位はサーバの優先順位に基づきます。 サーバの優先順位は [クラスタのプロパティ] の [マスタサーバ] タブで設定します。

Group A と B が排他ルールに所属していない場合

図 3.1 サーバの状態とグループA、Bの起動先サーバ

1. クラスタの立ち上げ

2. クラスタのシャットダウン

3. Server 1 ダウン：次に優先順位の高いサーバへフェイルオーバする

4. Server 1 の電源 ON

5. Server 1 のクラスタ復帰

6. クラスタのシャットダウン

7. Group A の移動

8. Server 2 ダウン：次に優先順位の高いサーバへフェイルオーバする

9. Server 2 ダウン：次に優先順位の高いサーバへフェイルオーバする

10. Server 3 ダウン：次に優先順位の高いサーバへフェイルオーバする

11. Server 2 ダウン：次に優先順位の高いサーバへフェイルオーバする

12. Server 2 ダウン：次に優先順位の高いサーバへフェイルオーバする

Group A と B が排他属性に「通常排他」が設定してある排他ルールに所属する場合

図 3.2 サーバの状態とグループA、Bの起動先サーバ（A、Bは通常排他）

1. クラスタの立ち上げ

2. クラスタのシャットダウン

3. Server 1ダウン：通常排他のグループが起動されていないサーバへフェイルオーバする

4. Server 1の電源ON

5. Server 1のクラスタ復帰

6. クラスタのシャットダウン

7. Group Aの移動

8. Server 2ダウン：通常排他のグループが起動されていないサーバへフェイルオーバする

9. Server 2ダウン：通常排他のグループが起動されていないサーバは存在しないが、起動可能なサーバが存在するのでフェイルオーバする

10. Server 3ダウン：通常排他のグループが起動されていないサーバは存在しないが、起動可能なサーバが存在するのでフェイルオーバする

11. Server 2ダウン：通常排他のグループが起動されていないサーバへフェイルオーバする

12. Server 3ダウン：通常排他のグループが起動されていないサーバへフェイルオーバする

Group A と B が排他属性に「完全排他」が設定してある排他ルールに所属する場合

図 3.3 サーバの状態とグループA、Bの起動先サーバ（A、Bは完全排他）

1. クラスタの立ち上げ

2. クラスタのシャットダウン

3. Server 1ダウン：完全排他のグループが起動されていないサーバへフェイルオーバする

4. Server 1の電源ON

5. Server 1のクラスタ復帰

6. クラスタのシャットダウン

7. Group Aの移動

8. Server 2ダウン：完全排他のグループが起動されていないサーバへフェイルオーバする

9. Server 2ダウン：フェイルオーバしない(Group Bは停止する)

10. Server 3ダウン ：フェイルオーバしない(Group Aは停止する)

11. Server 2ダウン：完全排他のグループが起動されていないサーバへフェイルオーバする

12. Server 3ダウン：完全排他のグループが起動されていないサーバへフェイルオーバする

Replicator を使用している場合 (サーバ 2 台の場合)

Group A と B が排他ルールに所属していない場合

図 3.4 サーバの状態とグループA、Bの起動先サーバ（Replicator使用時）

1. クラスタの立ち上げ

2. クラスタのシャットダウン

3. Server 1 ダウン：Group Aの待機系サーバへフェイルオーバする

4. Server 1 の電源ON

5. Server 1 のクラスタ復帰

6. クラスタのシャットダウン

7. Group A の移動

8. Server 2 ダウン：Group Bの待機系サーバへフェイルオーバする

9. Server 2 ダウン

10. Server 2 ダウン：待機系サーバへフェイルオーバする

3.2.4. 活性異常、非活性異常検出時の動作

活性異常、非活性異常検出時には以下の制御が行われます。

• グループリソース活性異常検出時の流れ

  • グループリソースの活性時に異常を検出した場合、活性リトライを行います。

  • [活性リトライしきい値] に設定されている回数の活性リトライに失敗した場合、 [フェイルオーバ先サーバ] で指定されたサーバへのフェイルオーバを行います。

  • [フェイルオーバしきい値] に設定されている回数のフェイルオーバを行っても活性できない場合、[最終動作] で設定された措置を実施します。

• グループリソース非活性異常検出時の流れ

  • 非活性時に異常を検出した場合、非活性リトライを行います。

  • [非活性リトライしきい値]に設定されている回数の非活性リトライに失敗した場合、[最終動作] で設定された措置を実施します。

注釈

[フェイルオーバ回数のカウント単位] が"サーバ"の場合

フェイルオーバ回数はサーバごとに記録されるため、[フェイルオーバしきい値] はサーバごとのフェイルオーバ回数の上限値になります。

グループ活性に成功したサーバでは、フェイルオーバ回数はリセットされます。

回復動作のフェイルオーバ回数は回復動作に失敗した場合でも 1 回としてカウントされることに注意してください。

[フェイルオーバ回数のカウント単位] が"クラスタ"の場合

フェイルオーバ回数はクラスタ単位に記録されるため、[フェイルオーバしきい値] はクラスタ単位のフェイルオーバ回数の上限値になります。

グループが活性し、正常な状態が 10 分間続いた場合、フェイルオーバ回数はリセットされます。

回復動作のフェイルオーバ回数は回復動作に失敗した場合でも 1 回としてカウントされることに注意してください。

以下の設定例でグループリソース活性異常検出時の流れを説明します。

設定例 (フェイルオーバ回数のカウント単位 ： サーバ)

活性リトライしきい値 3 回

フェイルオーバしきい値 1 回

最終動作 グループ停止

を指定している場合の挙動の例

1. 以下の図では、Server 1 と Server 2が共有ディスク（Shared disk）に接続されています。

   フェイルオーバグループA（Failover group A）はServer 1上にあり、ディスクリソース（Disk resource 1）の活性処理（ファイルシステムのマウント処理など）が開始されます。
   

   図 3.5 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (1)

2. Disk resource 1の活性処理が異常（ディスクパス障害等によるマウント処理の失敗）になりました。

   

   図 3.6 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (2)

3. Disk resource 1の活性処理を3回（活性リトライ回数）までリトライします。

   

   図 3.7 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (3)

4. Failover group Aのフェイルオーバ処理を開始します。

   "フェイルオーバしきい値" は各サーバでフェイルオーバした回数です。

   これは Server 1での 1回目のフェイルオーバ処理です。
   

   図 3.8 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (4)

5. Disk resource 1の活性処理（ファイルシステムのマウント処理等）を開始します。

   Disk resource 1の活性処理中に異常が発生した場合、活性処理を 3回までリトライします。
   

   図 3.9 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (5)

6. Server 2でもDisk resource 1の活性処理がリトライオーバした場合、Failover group Aのフェイルオーバ処理を開始します。

   これは Server 2での 1回目のフェイルオーバ処理です。
   

   図 3.10 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (6)

7. Server 1でDisk resource 1の活性処理を開始します。Disk resource 1の活性処理中に異常が発生した場合、活性処理を 3回までリトライします。

   

   図 3.11 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (7)

8. Server 1でもDisk resource 1の活性処理がリトライオーバした場合、フェイルオーバしきい値が1なのでフェイルオーバ処理は実行せず、"最終動作" に設定された動作を開始します。

   "最終動作" はフェイルオーバ処理がリトライオーバした後の動作です。

   ここでは Failover group Aのグループ停止処理を開始します。
   

   図 3.12 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：サーバ） (8)

設定例 (フェイルオーバ回数のカウント単位 ： クラスタ)

活性リトライしきい値 3 回

フェイルオーバしきい値 サーバ数に合わせる (以下のケースでは 2 回)

最終動作 グループ停止

を指定している場合の挙動の例

1. 図では、Server 1 と Server 2が共有ディスク（Shared disk）に接続されています。

   フェイルオーバグループA（Failover group A）はServer 1上にあり、ディスクリソース（Disk resource 1）の活性処理（ファイルシステムのマウント処理など）が開始されます。
   

   図 3.13 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (1)

2. Disk resource 1の活性処理が異常（ディスクパス障害等によるマウント処理の失敗）になりました。

   

   図 3.14 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (2)

3. Disk resource 1の活性処理を3回（活性リトライ回数）までリトライします。

   

   図 3.15 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (3)

4. Failover group Aのフェイルオーバ処理を開始します。 "フェイルオーバしきい値" は各サーバでフェイルオーバした回数です。 これはこのクラスタでの 1回目のフェイルオーバ処理です。

   

   図 3.16 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (4)

5. Disk resource 1の活性処理（ファイルシステムのマウント処理等）を開始します。 Disk resource 1の活性処理中に異常が発生した場合、活性処理を 3回までリトライします。

   

   図 3.17 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (5)

6. Server 2でもDisk resource 1の活性処理がリトライオーバした場合、Failover group Aのフェイルオーバ処理を開始します。 これは このクラスタでの 2回目のフェイルオーバ処理です。

   

   図 3.18 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (6)

7. Server 1でDisk resource 1の活性処理を開始します。Disk resource 1の活性処理中に異常が発生した場合、活性処理を 3回までリトライします。

   

   図 3.19 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (7)

8. Server 1でもDisk resource 1の活性処理がリトライオーバした場合、フェイルオーバしきい値が2なのでフェイルオーバ処理は実行せず、"最終動作" に設定された動作を開始します。 "最終動作" はフェイルオーバ処理がリトライオーバした後の動作です。 ここでは Failover group Aのグループ停止処理を開始します。

   

   図 3.20 グループリソース活性異常検出時の流れ（フェイルオーバカウント単位：クラスタ） (8)

3.2.5. 最終動作について

[フェイルオーバしきい値] に設定されている回数のフェイルオーバを行っても活性できない場合、[最終動作] で設定された措置を実施します。最終動作は以下の動作が選択できます。

• 何もしない (次のリソースを活性する)

  グループの起動処理を継続します。
• 何もしない (次のリソースを活性しない)

  グループの起動処理を中断します。
• グループ停止

  活性異常を検出したグループリソースが所属するグループ内のすべてのリソースを非活性化します。
• クラスタサービス停止

  活性異常を検出したサーバの CLUSTERPRO Server サービスを停止します。
• クラスタサービス停止と OS シャットダウン

  活性異常を検出したサーバの CLUSTERPRO Server サービスを停止し、OS を シャットダウンします。
• クラスタサービス停止と OS 再起動

  活性異常を検出したサーバの CLUSTERPRO Server サービスを停止し、OS を再起動します。
• 意図的なストップエラーの発生

  活性異常を検出したサーバでストップエラーを発生させます。

3.2.6. 最終動作前スクリプトについて

グループリソースの活性異常検出時、非活性異常検出時の最終動作前に、最終動作前スクリプトを実行させることが可能です。

最終動作前スクリプトで使用する環境変数

CLUSTERPRO はスクリプトを実行する場合に、どの状態で実行したか (活性異常時、非活性異常時) などの情報を環境変数にセットします。

スクリプト内で下図の環境変数を分岐条件として、システム運用にあった処理内容を記述できます。

環境変数	環境変数の値	意味
CLP_TIMING …実行タイミング	START	グループリソースの活性異常による最終動作前スクリプト実行を示します。
〃	STOP	グループリソースの非活性異常による最終動作前スクリプト実行を示します。
CLP_GROUPNAME …グループ名	グループ名	最終動作前スクリプトを実行する原因となる異常を検出したグループリソースが所属するグループ名を示します。
CLP_RESOURCENAME …グループリソース名	グループリソース名	最終動作前スクリプトを実行する原因となる異常を検出したグループリソース名を示します。

最終動作前スクリプトの記述の流れ

前のトピックの、環境変数と実際のスクリプト記述を関連付けて説明します。

非活性異常時の最終動作前スクリプトの一例

rem ********************************************
rem *            predeactaction.bat            *
rem ********************************************

echo START

rem スクリプト実行要因の環境変数を参照して、
rem 処理の振り分けを行う
IF "%CLP_TIMING%"=="STOP" GOTO NORMAL

rem ********************************************
rem CLP_TIMING is not STOP (Error)
rem ********************************************
echo NO_CLP
GOTO EXIT

rem ********************************************
rem CLP_TIMING is STOP
rem ********************************************
:NORMAL
echo %CLP_GROUPNAME%
echo %CLP_RESOURCENAME%

rem ここに、実行すべき回復処理を記述する。

:EXIT
echo EXIT

最終動作前スクリプト作成のヒント

Cluster WebUI のアラートログに、メッセージを出力できる [clplogcmd] コマンドがありますのでご活用ください。

最終動作前スクリプト 注意事項

• 最終動作前スクリプトが実行される条件について

  最終動作前スクリプトはグループリソースの活性異常検出時、非活性異常検出時の最終動作の前に実行されます。最終動作に [何もしない(次のリソースを活性/非活性する)] や、[何もしない(次のリソースを活性/非活性しない)] が設定されている場合にも、最終動作前スクリプトは実行されます。

  最大再起動回数や、他のサーバが全て停止している場合の最終動作抑制機能によって最終動作が実行されない場合は、最終動作前スクリプトは実行されません。

3.2.7. 活性/非活性前後スクリプトについて

グループリソースの活性/非活性前後に、任意のスクリプトを実行させることが可能です。

活性/非活性前後スクリプトで使用する環境変数

CLUSTERPRO はスクリプトを実行する場合に、どの状態で実行したか (活性前、活性後、非活性前、非活性後) などの情報を環境変数にセットします。

スクリプト内で下図の環境変数を分岐条件として、システム運用にあった処理内容を記述できます。

環境変数	環境変数の値	意味
CLP_TIMING …実行タイミング	PRESTART	グループリソース活性前のスクリプト実行を示します。
〃	POSTSTART	グループリソース活性後のスクリプト実行を示します。
〃	PRESTOP	グループリソース非活性前のスクリプト実行を示します。
〃	POSTSTOP	グループリソース非活性後のスクリプト実行を示します。
CLP_GROUPNAME …グループ名	グループ名	スクリプトが属しているグループリソースのグループ名を示します。
CLP_RESOURCENAME …グループリソース名	グループリソース名	スクリプトが属しているグループリソース名を示します。

活性/非活性前後スクリプトの記述の流れ

前のトピックの、環境変数と実際のスクリプト記述を関連付けて説明します。

活性/非活性前後スクリプトの一例

rem ******************************************************
rem *                    rscextent.bat                   *
rem ******************************************************

echo START
IF "%CLP_TIMING%"=="PRESTART" GOTO PRESTART
IF "%CLP_TIMING%"=="POSTSTART" GOTO POSTSTART
IF "%CLP_TIMING%"=="PRESTOP" GOTO PRESTOP
IF "%CLP_TIMING%"=="POSTSTOP" GOTO POSTSTOP

:PRESTART
echo %CLP_GROUPNAME%
echo %CLP_RESOURCENAME%
rem ここに、リソース活性前に実行したい任意の処理を記述する。
rem

GOTO EXIT

:POSTSTART
echo %CLP_GROUPNAME%
echo %CLP_RESOURCENAME%
rem ここに、リソース活性後に実行したい任意の処理を記述する。
rem

GOTO EXIT

:PRESTOP
echo %CLP_GROUPNAME%
echo %CLP_RESOURCENAME%
rem ここに、リソース非活性前に実行したい任意の処理を記述する。
rem

GOTO EXIT

:POSTSTOP
echo %CLP_GROUPNAME%
echo %CLP_RESOURCENAME%
rem ここに、リソース非活性後に実行したい任意の処理を記述する。
rem

GOTO EXIT

:EXIT

活性/非活性前後スクリプト作成のヒント

Cluster WebUI のアラートログに、メッセージを出力できる [clplogcmd] コマンドがありますのでご活用ください。

活性/非活性前後スクリプト 注意事項

特にありません。

3.2.8. 再起動回数制限について

活性異常、非活性異常検出時の最終動作として [クラスタサービス停止と OS シャットダウン]、または [クラスタサービス停止とOS再起動] を設定している場合に、活性異常、非活性異常の検出によるシャットダウン回数、または再起動回数を制限することができます。

この最大再起動回数はサーバごとの再起動回数の上限になります。

注釈

再起動回数はサーバごとに記録されるため、最大再起動回数はサーバごとの再起動回数の上限になります。

また、グループ活性、非活性異常検出時の最終動作による再起動回数とモニタリソース異常の最終動作による再起動回数も別々に記録されます。

最大再起動回数をリセットする時間に0を設定した場合には、再起動回数のカウントはリセットされません。再起動回数をリセットするには、clpregctrl コマンドを使用してください。

以下の設定例で再起動回数制限の流れを説明します。

最大再起動回数が 1 回に設定されているため、一度だけ最終動作である [クラスタサービス停止とOS再起動] が実行されます。

また、最大再起動回数をリセットする時間が 10 分に設定されているため、OS の再起動後に CLUSTERPRO Server サービスが正常に起動した状態で 10 分経過するとそのサーバの再起動回数はリセットされます。

設定例

活性リトライしきい値 0 回

フェイルオーバしきい値 0 回

最終動作 クラスタサービス停止と OS 再起動

最大再起動回数 1 回

最大再起動回数をリセットする時間 10 分

を指定している場合の挙動の例

1. 以下の図では、Server 1 と Server 2が共有ディスク（Shared disk）に接続されています。

   フェイルオーバグループA（Failover group A）はServer 1上にあり、ディスクリソース（Disk resource 1）の活性処理（ファイルシステムのマウント処理など）が開始されます。
   

   図 3.21 再起動回数制限時の処理 (1)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	0回	0回

2. Disk resource 1の活性処理が異常になりました。

   

   図 3.22 再起動回数制限時の処理 (2)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	0回	0回

3. クラスタサービスを停止後、OSを再起動します。"活性リトライしきい値"、"フェイルオーバしきい値" は0のため、最終動作を実行します。

   Server 1では再起動回数 1が記録されます。
   

   図 3.23 再起動回数制限時の処理 (3)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	1回	0回

4. Failover group Aのフェイルオーバ処理を開始します。

   

   図 3.24 再起動回数制限時の処理 (4)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	1回	0回

5. Disk resource 1の活性処理（ファイルシステムのマウント処理等）を開始します。

   Server 2ではリソース活性が成功、Server 1では再起動が完了します。
   

   図 3.25 再起動回数制限時の処理 (5)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	1回	0回

6. clpgrpコマンド、Cluster WebUIを使用して、Failover group Aのフェイルオーバ処理を開始します。

   

   図 3.26 再起動回数制限時の処理 (6)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	1回	0回

7. Disk resource 1の活性処理（ファイルシステムのマウント処理等）を開始します。

   

   図 3.27 再起動回数制限時の処理 (7)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	1回	0回

8. Disk resource 1の活性処理が異常になりました。

   最大再起動回数に達しているため最終動作は実行しません。

   10分経過しても再起動回数はリセットされません。

   Failover group Aは活性異常状態になります。
   

   図 3.28 再起動回数制限時の処理 (8)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	1回	0回

9. Disk resource 1の活性異常の原因となったディスクの異常を取り除きます。

   その後、clpstdnコマンド、またはCluster WebUIを使用して、クラスタシャットダウン後、再起動を実行します。
   

   図 3.29 再起動回数制限時の処理 (9)

   

   図 3.30 再起動回数制限時の処理 (10)

   	Server 1	Server 2
   最大再起動回数	1回	1回
   再起動回数	1回	0回

10. Failover group Aの起動に成功します。

    10分経過後、再起動回数はリセットされます。

    次回、Failover group A起動時に Disk resource 1 活性異常が発生した場合、最終動作が実行されます。

図 3.31 再起動回数制限時の処理 (11)

	Server 1	Server 2
最大再起動回数	1回	1回
再起動回数	0回	0回

3.2.9. 再起動回数初期化

再起動回数を初期化する場合、[clpregctrl] コマンドを使用してください。[clpregctrl] コマンドに関しては本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「再起動回数を制御する (clpregctrlコマンド)」を参照してください。

3.2.10. 両系活性チェックについて

グループ起動時に、両系活性が発生するか否かを確認することができます。

• 両系活性が発生しないと判断した場合

  グループの起動処理を開始します。

• 両系活性が発生すると判断した場合（タイムアウトした場合）

  グループの起動処理を開始しません。グループを起動しようとしたサーバでは、グループは停止状態となります。

注釈

• グループが停止状態で、リソースの単体起動が実施された場合、両系活性チェックは実施されます。しかし、グループの中で１つでもリソースが活性している状態でリソースの単体起動を実施した場合は、両系活性チェックは実施されません。

• [両系活性チェックを行う] がオンのグループに、フローティングIPリソースが存在しない場合、両系活性チェックは実行せず、グループの起動を開始します。

• 両系活性が発生すると判断した場合、グループやリソースの状態がサーバ間で不整合となる場合があります。

3.2.11. グループの起動、停止待ち合わせ設定を理解する

グループの起動、停止待ち合わせを設定することにより、グループを起動、停止する順序を設定することができます。

• グループの起動待ち合わせを設定した場合:

  • グループ起動時は、起動待ち合わせ対象のグループの起動処理が正常に完了してから、このグループの起動処理が開始されます。

  • グループ起動時に、起動待ち合わせするように設定されているグループの待ち合わせタイムアウト時にはグループは起動しません。

• グループの停止待ち合わせを設定した場合:

  • グループ停止時は、停止待ち合わせ対象のグループの停止処理が正常に完了してから、このグループの停止処理が開始されます。

  • 停止待ち合わせ処理でタイムアウトが発生した場合、グループの停止処理は継続します。

  • 停止待ち合わせは、Cluster WebUI で設定した条件で実行されます。

グループの起動、停止待ち合わせ設定を表示するには、Cluster WebUI の設定モードからグループのプロパティをクリックし、[起動待ち合わせ] タブ、[停止待ち合わせ] タブをクリックします。

例としてグループの起動待ち合わせする深度を一覧で表示します。

図 3.32 グループの起動順序

グループ起動の実行を、簡単な状態遷移の例で説明します。

2 台構成のサーバで、グループを 3 つ持っている場合

グループのフェイルオーバポリシー

Group A Server 1

Group B Server 2

Group C Server 1 → Server 2

グループの起動待ち合わせ設定

Group A 起動待ち合わせ設定なし

Group B 起動待ち合わせ設定なし

Group C Group Aの起動を待ち合わせる

Group C Group Bと同じサーバで起動する場合には待ち合わせる

1. Server 1 でGroup AとGroup Cを起動する場合

   Server 1 で、Group A の正常起動を待ってからGroup Cが起動します。

   

   図 3.33 Server 1 でGroup AとGroup Cが起動

2. Server 1 でGroup A、Server 2でGroup Cを起動する場合

   Server 1 でGroup A の正常起動を待ってから、Server 2でGroup Cが起動します。

   「同じサーバで起動する場合のみ待ち合わせを行う」が設定されていないため他サーバで起動するGroup Aの正常起動を待ち合わせます。
   

   図 3.34 Server 1 でGroup A、Server 2でGroup Cが起動

3. Server 1 でGroup C、Server 2でGroup Bを起動する場合

   Server 1 でGroup B の正常起動を待たずにGroup Cが起動します。

   Group Cは同じサーバで起動する場合のみGroup Bの起動を待つように設定されていますが、Group BはServer 1では起動しない設定のため、待ち合わせしません。
   

   図 3.35 Server 1 でGroup C、Server 2でGroup Bが起動

4. Server 1でGroup AとGroup Cを起動する場合

   Server 1でGroup Aの起動がエラーになった場合、Group Cは起動しません。

   

   図 3.36 Server 1でGroup Aの起動がエラー、Group Cが起動しない

5. Server 1でGroup AとGroup Cを起動する場合

   Server 1でGroup Aの起動が失敗しGroup Aのリソースの復旧動作によりServer 2にフェイルオーバが発生した場合、Server 2でGroup Aが起動した後でServer 1でGroup Cが起動します。

   

   図 3.37 Group AはServer 2にフェイルオーバ、Server 1でGroup Cが起動

6. Server 1でGroup AとGroup Cを起動する場合

   Server 1でGroup Aの起動待ち合わせタイムアウトが発生した場合、Group Cは起動しません。

   

   図 3.38 Server 1 でGroup Aが起動

7. Server 1でGroup Cのみを起動する場合

   Server 1でGroup Aが起動していないため、起動待ち合わせタイムアウトが発生しGroup Cは起動しません。

   

   図 3.39 Server 1 でGroup A、Group Cは起動しない

注釈

• グループ起動時に、起動待ち合わせするように設定されているグループを自動的に起動する機能はありません。

• グループ起動時に、起動待ち合わせするように設定されているグループの待ち合わせタイムアウト時にはグループは起動しません。

• グループ起動時に、起動待ち合わせするように設定されているグループが起動に失敗した場合にはグループは起動しません。

• 起動待ち合わせ対象のグループ内に正常に起動しているリソースと停止しているリソースが存在する場合、そのグループは正常に起動済みと判断します。

• グループ停止時に、停止待ち合わせするように設定されているグループを自動的に停止する機能はありません。

• グループ停止時に、停止待ち合わせするように設定されているグループの待ち合わせタイムアウト時にはグループの停止処理は継続します。

• グループ停止時に、停止待ち合わせするように設定されているグループが停止に失敗した場合にはグループの停止処理は継続します。

• Cluster WebUI やclpgrpコマンドによるグループ停止処理やリソース停止処理では、停止待ち合わせは行いません。停止待ち合わせは、Cluster WebUI で設定した条件（クラスタ停止時、またはサーバ停止時）で実行されます。

• フェイルオーバ時に起動待ち合わせ処理でタイムアウトが発生した場合にはフェイルオーバは失敗します。

3.2.12. グループの排他制御を理解する

フェイルオーバ排他属性はフェイルオーバの際のグループの排他属性を設定します。 ただし、以下の条件の場合には設定できません。

• フェイルオーバ属性が [ダイナミックフェイルオーバを行う], [サーバグループ内のフェイルオーバポリシーを優先する], [サーバグループ間では手動フェイルオーバのみ有効とする] の場合

設定可能なフェイルオーバ排他属性は以下になります。

排他なし

フェイルオーバの際、排他を行いません。フェイルオーバ可能なサーバのうち、最も優先順位の高いサーバでフェイルオーバします。

通常排他

フェイルオーバの際、排他を行います。フェイルオーバ可能なサーバのうち、他の通常排他のグループが起動していない最も優先順位の高いサーバでフェイルオーバします。

ただし、全てのフェイルオーバ可能なサーバで既に他の通常排他のグループが起動している場合、排他を行いません。フェイルオーバ可能なサーバのうち最も優先順位の高いサーバでフェイルオーバします。

完全排他

フェイルオーバの際、排他を行います。フェイルオーバ可能なサーバのうち、他の完全排他のグループが起動していない最も優先順位の高いサーバでフェイルオーバします。

ただし、全てのフェイルオーバ可能なサーバで既に他の完全排他のグループが起動している場合、フェイルオーバを行いません。

注釈

異なる排他ルール同士は排他を行いません。同一の排他ルールに所属するグループのみ、設定された排他属性に従い、排他制御が行われます。いずれの場合も 排他なし のグループとは排他を行いません。フェイルオーバ排他属性の詳細は 「 フェイルオーバポリシーを理解する 」を参照してください。また、排他ルールの設定方法の詳細は「 グループ共通のプロパティ 」を参照してください。

3.2.13. サーバグループを理解する

このトピックでは、サーバグループについて説明します。

サーバグループとは、主にハイブリッドディスクリソースを使用する場合に必要なサーバ群のグループです。

共有ディスク装置でハイブリッドディスクリソースを使用する場合に同一の共有ディスク装置で接続されているサーバ群を 1 つサーバグループとして設定します。

共有型でないディスクでハイブリッドディスクリソースを使用する場合にも 1 台のサーバを 1 つサーバグループとして設定します。

図 3.40 サーバグループ

3.2.14. グループリソースの依存関係設定を理解する

グループリソース間に依存関係を設定することにより、グループリソースを活性する順序を 設定することができます。

• グループリソースに依存関係を設定した場合:

• 活性時は [依存するリソース] の活性化が完了してから、このグループリソースの活性化が開始されます。

• 非活性時はこのグループリソースの非活性化が完了してから、[依存するリソース] の非活性化が開始されます。

例として該当グループに所属するリソースの依存する深度を一覧で表示します。

図 3.41 グループリソースの活性順序の例

図 3.42 グループリソースの非活性順序の例

3.2.15. グループリソースをサーバ個別設定する

グループリソースの一部の設定値はサーバごとに異なる設定が可能です。サーバ別設定が可能なリソースは [詳細] タブに各サーバのタブが表示されます。

ここではフローティング IPリソースでサーバ個別設定を説明します。

サーバ個別設定

フローティング IPリソースでサーバ個別設定可能なパラメータが表示されます。

個別に設定する

サーバ個別設定を行いたいサーバ名のタブを選択してチェックボックスをオンにするとフローティング IPリソースでサーバ個別設定可能なパラメータが入力可能になります。必要なパラメータを入力します。

注釈

サーバ個別設定では [調整] は選択できません。

3.3. グループ共通のプロパティ

3.3.1. 排他タブ

追加

排他ルールを追加します。[追加] を選択すると [排他ルールの定義] ダイアログボックスが表示されます。

削除

排他ルールを削除します。

名称変更

選択している排他ルール名の変更ダイアログボックスが表示されます。

下記の入力規則があります。

• 最大 31 文字 (31 バイト) までです。

• 文字列先頭と文字列末尾にハイフン (-) とスペースは使えません。

• 文字列全て数字の場合は使用できません。

排他ルールで一意 (英大文字・小文字の区別なし) な名前を入力してください。

プロパティ

選択している排他ルールのプロパティを表示します。

排他ルールの定義

排他ルール名と排他属性を設定します。排他属性には通常排他と完全排他の設定が可能です。通常排他を設定可能な排他ルールは１つのみです。完全排他は複数設定可能です。通常排他に設定された排他ルールがすでに存在する場合は、通常排他を選択することはできません。

名前

排他ルール名を表示しています。

排他属性

排他ルールに設定した排他属性を表示します。

グループ

排他ルールに属しているフェイルオーバグループ名の一覧を表示しています。

[登録可能なグループ]から排他ルールに登録したいグループを選択し、[追加]ボタンを押下してください。[排他対象のグループ]には排他ルールに登録したグループが表示されます。他の排他ルールに追加したフェイルオーバグループは[登録可能なグループ]に表示されません。

3.3.2. 起動待ち合わせタブ

起動待ち合わせ一覧を表示します。

3.3.3. 停止待ち合わせタブ

停止待ち合わせ一覧を表示します。

3.4. グループのプロパティ

3.4.1. リソース一覧タブ

選択したグループに含まれるグループリソースの一覧を表示します。

各種設定値を変更することができます。

名前のリンクを押下すると、該当のリソースのプロパティ画面に遷移します。

CSVダウンロードを押下すると、グループリソースの一覧に表示している情報をCSV形式でダウンロードします。

各表示項目の詳細は「 リソースのプロパティ 」を参照してください。

3.4.2. 情報タブ

タイプ

グループのタイプを表示します。

サーバグループ設定を使用する

• チェックボックスがオン

  サーバグループ設定を使用します。
• チェックボックスがオフ

  サーバグループ設定を使用しません。

名前

グループ名を表示します。

グループ名の変更

1. [その他]メニューをクリックして、[グループの名称変更]を選択してください。

2. [グループ名の変更]ダイアログボックスが表示されます。

入力規則

• 1 バイトの英大文字・小文字，数字，ハイフン (-)，アンダーバー (_)，スペースのみ使用可能です。

• 最大 31 文字 (31 バイト) までです。

• 文字列先頭と文字列末尾にハイフン (-)とスペースは使えません。

コメント (127 バイト以内)

グループのコメントを設定します。半角英数字のみ入力可能です。

3.4.3. 起動サーバタブ

グループを起動するサーバの設定には、全サーバで起動する設定と、起動可能なサーバ またはサーバグループを選択する設定があります。

全サーバで起動する設定の場合は、クラスタに登録されている全サーバでグループを起動できます。グループを起動するサーバの起動順位は、サーバの優先順位と等しくなります。サーバの優先順位に関しては、本ガイドの「2. パラメータの詳細」 - 「Servers プロパティ」 - 「マスタサーバタブ」 を参照してください。

起動可能なサーバとサーバグループを選択する場合は、クラスタに登録されているサーバとサーバグループから任意に起動するサーバまたはサーバグループを選択できます。また、グループを起動するサーバまたはサーバグループの起動順位を変更することができます。

フェイルオーバグループを起動するサーバを設定する場合

全てのサーバでフェイルオーバ可能

グループを起動するサーバを指定します。

• チェックボックスがオン

  クラスタに登録されている全サーバでグループを起動できます。グループの起動順位はサーバの優先順位と等しくなります。
• チェックボックスがオフ

  起動可能なサーバの選択と起動順位の変更ができます。

追加

起動可能なサーバを追加する場合に使用します。[利用可能なサーバ] から追加したいサーバを選択して、[追加] をクリックします。[起動可能なサーバ] に追加されます。

削除

起動可能なサーバを削除する場合に使用します。[起動可能なサーバ] から削除したいサーバを選択して、[削除] をクリックします。[利用可能なサーバ] に追加されます。

順位

起動可能なサーバの優先順位を変更する場合に使用します。[起動可能なサーバ] から変更したいサーバを選択して、矢印をクリックします。選択行が移動します。

サーバグループ設定を使用する場合

ハイブリッドディスクリソースを含むグループの場合、サーバグループ設定を使用して起動可能なサーバを設定する 必要があります。サーバグループの設定については、本ガイドの「2. パラメータの詳細」 - 「Servers プロパティ」 - 「サーバグループタブ」を参照してください。

追加

起動可能なサーバグループを追加する場合に使用します。[利用可能なサーバグループ] から追加したいサーバグループを選択して、[追加] をクリックします。[起動可能なサーバグループ] に追加されます。

削除

起動可能なサーバグループを削除する場合に使用します。[起動可能なサーバグループ] から削除したいサーバグループを選択して、[削除] をクリックします。[利用可能なサーバグループ] に追加されます。

順位

起動可能なサーバグループの優先順位を変更する場合に使用します。[起動可能なサーバグループ] から変更したいサーバグループを選択して、矢印をクリックします。選択行が移動します。

3.4.4. 属性タブ

グループ起動属性

クラスタ起動時に CLUSTERPRO によりグループを自動的に起動するか (自動起動)、もしくは Cluster WebUI または [clpgrp] コマンドからユーザが操作して起動するか (手動起動) の属性を設定します。

両系活性チェックを行う

グループ起動前に両系活性が発生するか否かを確認します。

タイムアウト (1～9999)

両系活性チェックを実施する最大時間を指定します。既定値は300秒です。グループに所属するフローティングIPリソースの [フローティングIPリソース 調整プロパティ] - [pingタイムアウト] に設定した値より大きな値を設定してください。

フェイルオーバ属性

サーバダウン発生時、自動的にフェイルオーバするかどうかを設定します。

• 自動フェイルオーバ

  自動的にフェイルオーバします。さらに、以下の項目が選択可能となります。
  • 起動可能なサーバ設定に従う

    デフォルト設定です。
  • ダイナミックフェイルオーバを行う

    フェイルオーバ時に、各サーバのモニタやフェイルオーバグループのステータスを考慮し、フェイルオーバ先を決定する機能です。

    ラジオボタンが選択された場合、フェイルバック属性のパラメータを全てデフォルト値に戻し、グレイアウトさせます。

    ダイナミックフェイルオーバを選択した場合、各オプションが設定できます。詳細は「グループプロパティを理解する」を参照してください。
  • サーバグループ内のフェイルオーバポリシーを優先する

    サイト間 (サーバグループ間) のフェイルオーバを制御する機能です。

    ただし、フェイルオーバグループにサーバグループが設定されていない場合、サイト間フェイルオーバの表示はグレイアウトされます。

    ラジオボタンが選択された場合にのみ、[サーバグループ間では手動フェイルオーバのみを有効とする] のチェックボックスを選択できるようになります。

    [サーバグループ内のフェイルオーバポリシーを優先する] のラジオボタンのみを選択した場合、同一サーバグループ内のフェイルオーバポリシーを優先し、フェイルオーバ先を決定します。

    [サーバグループ内のフェイルオーバポリシーを優先する] のラジオボタンを選択し、かつ [サーバグループ内では手動フェイルオーバのみ有効とする] のチェックボックスにチェックを入れている場合、サーバグループ間をまたぐようなフェイルオーバは自動的に行われません。サーバグループ間をまたいでグループを移動させるには、手動でグループを移動させる必要があります。
• 手動フェイルオーバ

  自動的にフェイルオーバしません。

フェイルオーバ属性(拡張)

フェイルオーバ属性で設定された自動フェイルオーバの方法について、より詳細な内容を設定します。 詳細は「グループプロパティを理解する」を参照してください。

フェイルバック属性

グループが起動しているサーバよりも高プライオリティのサーバが正常に起動してきたときに自動的にフェイルバックするかどうかを設定します。

ミラーディスクリソースまたはハイブリッドディスクリソースを含めるグループは手動 フェイルバック属性に設定してください。

モニタの編集

指定したモニタリソースで異常を検出しているサーバをフェイルオーバ先から除外します。 フェイルオーバ属性(拡張) の [指定したモニタリソースで異常を検出しているサーバをフェイルオーバ先から除外する] を選択した場合に、使用するモニタリソースを設定することができます。

使用するモニタリソースは、モニタリソースタイプ、モニタリソース名による設定ができます。

• モニタリソースタイプの追加

  モニタリソースタイプを追加します。

  追加したモニタリソースタイプのモニタリソースが一つでも異常状態になっているサーバはフェイルオーバ先から除外されます。

  

  選択したモニタリソースタイプを追加します。
• モニタリソースタイプの削除

  選択されているモニタリソースタイプを削除します。
• モニタリソースグループの追加

  モニタリソースグループを追加します。

  モニタリソースグループの最大登録数は32個です。

  一つのモニタリソースグループ内に複数のモニタリソースが登録されている場合、登録されている全てのモニタリソースが異常状態になっているサーバはフェイルオーバ先から除外されます。

  また複数のモニタリソースグループが登録されている場合、いずれか一つでも条件を満たしたサーバはフェイルオーバ先から除外されます。

追加

[利用可能なモニタリソース一覧]で選択されているモニタリソースを[モニタリソース一覧]に追加します。

削除

[モニタリソース一覧]で選択されているモニタリソースを、一覧から削除します。

• モニタリソースグループの削除

  選択されているモニタリソースグループを削除します。
• モニタリソースグループの編集

  選択されているモニタリソースグループを編集します。

  注釈

  下記のモニタリソースはモニタリソースタイプに登録できません。また、当該モニタリソースはモニタリソースグループにリソース名を登録できません。

  • ハイブリッドディスク監視

  注釈

  警告状態のモニタリソースは異常として扱いません。ただし、ミラーディスク監視リソースは除きます。

  活性時監視に設定されているモニタリソースは、グループ起動サーバ以外のサーバでは監視を行わないため異常状態になりません。

  Cluster WebUI、clpmonctrlコマンドを使用して停止したモニタリソースは正常状態となります。

  モニタリソースの監視を行うサーバとして設定されていないサーバでは監視を行わないため異常状態になりません。

  注釈

  ミラーディスク監視リソースの場合は、ミラーディスクリソースの活性可否により判断します。ミラーディスク監視リソースの状態には依存しません。

  ミラーディスク監視リソースが異常状態であっても、ミラーディスクリソースが正常に活性できるサーバはフェイルオーバ先から除外されません。

  ミラーディスク監視リソースが正常状態や警告状態であっても、ミラーディスクリソースが正常に活性できないサーバはフェイルオーバ先から除外されます。

  初期ミラー構築前の場合、フェイルオーバグループの起動に失敗することがあります。ミラーディスク監視リソースは、初期ミラー構築後に「フェイルオーバ先サーバの除外に使用するモニタリソース」に登録することを推奨します。

3.4.5. 論理サービスタブ

追加

[論理サービス名一覧] に論理サービス名を追加します。

論理サービス名はフェイルオーバグループ内で最大 48 個まで登録可能で、異なるフェイルオーバグループであれば、複数の同一論理サービス名が存在していても構いません。

削除

[論理サービス名一覧] から選択した論理サービス名を削除します。

編集

選択した [論理サービス名の入力] ダイアログボックスを表示します。

論理サービス名 (31 バイト以内)

追加する論理サービス名を 31 文字以内で入力してください。

論理サービスの詳細については 「 グループとは? 」を参照してください。

3.4.6. 起動待ち合わせタブ

追加

[利用可能なグループ] で選択したグループを [対象グループ] に追加します。

削除

[対象グループ] で選択したグループを [対象グループ] から削除します。

対象グループの起動待ち時間 (0～9999)

対象グループの正常起動完了を待ち合わせる最大時間を指定します。既定値は 1800 秒です。

プロパティ

[対象グループ] で選択したグループのプロパティを変更します。

同じサーバで起動する場合のみ待ち合わせを行う

起動待ち合わせを行うグループと対象グループが同じサーバで起動する場合のみ待ち合わせるかどうかを設定します。

起動待ち合わせを行うグループを起動するサーバが、対象グループの「起動サーバ」に含まれていない場合には待ち合わせを行いません。

起動待ち合わせを行うグループを起動するサーバ以外で対象グループが起動失敗になっている場合には待ち合わせを行いません。

3.4.7. 停止待ち合わせタブ

追加

[利用可能なグループ] で選択したグループを [対象グループ] に追加します。

削除

[対象グループ] で選択したグループを [対象グループ] から削除します。

対象グループの停止待ち時間 (0～9999)

対象グループの正常停止完了を待ち合わせる最大時間を指定します。既定値は 1800 秒です。

クラスタ停止時に対象グループの停止を待ち合わせる

クラスタ停止時に対象グループの停止を待ち合わせるかどうかを設定します。

サーバ停止時に対象グループの停止を待ち合わせる

サーバ単体停止時に対象グループの停止完了を待ち合わせるかどうかを設定します。対象グループのうち同じサーバで起動しているグループのみ停止を待ち合わせます。

グループ停止時に対象グループの停止を待ち合わせる

グループ停止操作時に対象グループの停止完了を待ち合わせるかどうかを設定します。対象グループのうち同じサーバで起動しているグループのみ停止を待ち合わせます。

3.4.8. 全体の依存関係タブ

グループリソースの依存関係設定を表示します。

活性時タブ

フェイルオーバグループ活性時のグループリソースの依存関係を表示します。

非活性時タブ

フェイルオーバグループ非活性時のグループリソースの依存関係を表示します。

図を表示

リンクを押下すると、グループリソースの依存関係の図を表示します。

3.5. リソースのプロパティ

3.5.1. 情報タブ

名前

リソース名を表示します。

リソース名の変更

1. [その他]メニューをクリックして、[グループリソースの名称変更]を選択してください。

2. [リソース名の変更]ダイアログボックスが表示されます。

入力規則

• 1 バイトの英大文字・小文字，数字，ハイフン (-)，アンダーバー (_)，スペースのみ使用可能です。

• 最大 31 文字 (31 バイト) までです。

• 文字列先頭と文字列末尾にハイフン (-)とスペースは使えません。

コメント (127 バイト以内)

リソースのコメントを設定します。半角英数字のみ入力可能です。

3.5.2. 依存関係タブ

既定の依存関係に従う

選択したグループリソースが CLUSTERPRO の既定の依存関係に従うかどうかを指定します。

• チェックボックスがオン

  リソースのタイプに依存します。各リソースの既定の依存関係は本ガイドの「2. パラメータの詳細」の「パラメータ一覧」を参照してください。依存するタイプのリソースが複数ある場合はそのタイプのリソースすべてに依存します。
• チェックボックスがオフ

  指定するリソースに依存します。

追加

[利用可能なリソース] で選択したグループリソースを [依存するリソース] に追加します。

削除

[依存するリソース] で選択したグループリソースを [依存するリソース] から削除します。

3.5.3. 復旧動作タブ

グループリソース活性異常検出時の流れ

• グループリソースの活性時に異常を検出した場合、活性リトライを行います。

• [活性リトライしきい値] の活性リトライに失敗した場合、[フェイルオーバ先サーバ] で指定されたサーバへのフェイルオーバを行います。

• [フェイルオーバしきい値] のフェイルオーバを行っても活性できない場合、[最終動作] を行います。

グループリソース非活性異常検出時の流れ

• 非活性時に異常を検出した場合、非活性リトライを行います。

• [非活性リトライしきい値] の非活性リトライに失敗した場合、[最終動作] を行います。

活性異常検出時の復旧動作

活性リトライしきい値 (0～99)

活性異常検出時に活性リトライを行う回数を入力します。0 を設定すると活性リトライを行いません。

フェイルオーバ先サーバ

活性異常検出時に活性リトライが [活性リトライしきい値] で指定した回数失敗した後にフェイルオーバを行う際の、フェイルオーバ先サーバを次の中から選択します。

• 安定動作サーバ

  グループ起動後、リソース異常を検出した回数が最も少ないサーバにフェイルオーバします。

  上記を満たすサーバが複数存在する場合は、それらの中から、グループのフェイルオーバポリシーの設定に従ってフェイルオーバします。
• 最高プライオリティサーバ

  グループのフェイルオーバポリシーの設定に従ってフェイルオーバします。

フェイルオーバしきい値 (0～99)

活性異常検出時に活性リトライが [活性リトライしきい値] で指定した回数失敗した後にフェイルオーバを行う回数を入力します。0 を設定するとフェイルオーバを行いません。

[クラスタのプロパティ] - [拡張]タブ - [フェイルオーバ回数のカウント単位] を[サーバ]にした場合、フェイルオーバしきい値に、0～99の任意の回数を設定します。

[クラスタのプロパティ] - [拡張]タブ - [フェイルオーバ回数のカウント単位] を[クラスタ]にした場合、フェイルオーバしきい値に、以下の設定が可能です。

• サーバ数に合わせる

  フェイルオーバしきい値にサーバ数を設定します。
• 回数を指定

  フェイルオーバしきい値に任意の回数を設定します。

  フェイルオーバ回数のカウント単位の設定については、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「拡張タブ」を参照してください。

最終動作

活性異常検出時に活性リトライが [活性リトライしきい値] で指定した回数失敗し、フェイルオーバが [フェイルオーバしきい値] で指定した回数失敗した後の動作を選択します。

最終動作は以下の動作が選択できます。

• 何もしない (次のリソースを活性する)

• 何もしない (次のリソースを活性しない)

• グループ停止

• クラスタサービス停止

• クラスタサービス停止と OS シャットダウン

• クラスタサービス停止と OS 再起動

• 意図的なストップエラーの発生

最終動作の詳細は「 最終動作について 」を参照してください。

最終動作前にスクリプトを実行する

活性異常検出時の最終動作を実行する前にスクリプトを実行するかどうかを指定します。

• チェックボックスがオン

  最終動作を実施する前にスクリプト/コマンドを実行します。スクリプト/コマンドの設定を行うためには [設定]をクリックしてください。

  スクリプトの設定については「活性前後、非活性前後にスクリプトを実行する」のスクリプトの設定の説明を参照してください。
• チェックボックスがオフ

  スクリプト/コマンドを実行しません。

非活性異常検出時の復旧動作

非活性リトライしきい値 (0～99)

非活性異常検出時に非活性リトライ回数を入力します。0 を設定すると非活性リトライを行いません。

最終動作

非活性異常検出時に非活性リトライが [非活性リトライしきい値] で指定した回数失敗した後の動作を選択します。

最終動作は以下の動作が選択できます。

• 何もしない (次のリソースを非活性する)

• 何もしない (次のリソースを非活性しない)

• クラスタサービス停止と OS シャットダウン

• クラスタサービス停止と OS 再起動

• 意図的なストップエラーの発生

最終動作の詳細は「 最終動作について 」を参照してください。

注釈

非活性異常検出時の最終動作に [何もしない] を選択すると、グループが非活性失敗のまま停止しません。本番環境では [何もしない] は設定しないように注意してください。

最終動作前にスクリプトを実行する

非活性異常検出時の最終動作を実行する前にスクリプトを実行するかどうかを指定します。

• チェックボックスがオン

  最終動作を実施する前にスクリプト/コマンドを実行します。スクリプト/コマンドの設定を行うためには [設定]をクリックしてください。

  スクリプトの設定については「活性前後、非活性前後にスクリプトを実行する」のスクリプトの設定の説明を参照してください。
• チェックボックスがオフ

  スクリプト/コマンドを実行しません。

3.5.4. 詳細タブ

リソース固有のパラメータは各リソースの説明に記述しています。

3.5.5. 拡張タブ

リソース起動属性

グループ起動時にリソースを自動的に起動するか (自動起動)、もしくは Cluster WebUI または [clprsc] コマンドからユーザが操作して起動するか (手動起動) の属性を設定します。

活性前後、非活性前後にスクリプトを実行する

リソース活性前、活性後、非活性前、非活性後にスクリプトを実行するかどうかを指定します。設定を行うためには [設定]をクリックしてください。

チェックボックスにチェックを入れることで、指定のタイミングでスクリプトが実行されます。

実行タイミング

リソース活性前にスクリプトを実行する

• チェックボックスがオン

  リソース活性前にスクリプトを実行します。
• チェックボックスがオフ

  リソース活性前にスクリプトを実行しません。

リソース活性後にスクリプトを実行する

• チェックボックスがオン

  リソース活性後にスクリプトを実行します。
• チェックボックスがオフ

  リソース活性後にスクリプトを実行しません。

リソース非活性前にスクリプトを実行する

• チェックボックスがオン

  リソース非活性前にスクリプトを実行します。
• チェックボックスがオフ

  リソース非活性前にスクリプトを実行しません。

リソース非活性後にスクリプトを実行する

• チェックボックスがオン

  リソース非活性後にスクリプトを実行します。
• チェックボックスがオフ

  リソース非活性後にスクリプトを実行しません。

スクリプトの設定を行うためには [設定]をクリックしてください。

ユーザアプリケーション

スクリプトとしてサーバ上の実行可能ファイル (実行可能なバッチファイルや実行ファイル) を使用します。ファイル名にはサーバ上のローカルディスクの絶対パスまたは実行可能ファイル名を設定します。ただし、実行可能ファイル名のみを設定する場合、あらかじめ環境変数にパスを設定しておく必要があります。また、絶対パスやファイル名に空欄が含まれる場合は、下記のように、ダブルクォーテーション (") でそれらを囲ってください。

例：

"C:\Program Files\script.bat"

また VB スクリプトを実行させる場合は下記のように入力してください。

例：

cscript script.vbs

各実行可能ファイルは、Cluster WebUI のクラスタ構成情報には含まれません。Cluster WebUI で 編集やアップロードはできませんので、各サーバ上に準備する必要があります。

この製品で作成したスクリプト

スクリプトとして Cluster WebUI で準備したスクリプトファイルを使用します。必要に応じて Cluster WebUI でスクリプトファイルを編集できます。スクリプトファイルは、クラスタ構成情報に含まれます。

ファイル (1023 バイト以内)

[ユーザアプリケーション] を選択した場合に、実行するスクリプト (実行可能なバッチファイルや実行ファイル) を設定します。

表示

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルを表示します。

編集

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルを編集します。変更を反映するには [保存] をクリックしてください。スクリプトファイル名の変更はできません。

置換

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルの内容を、ファイル選択ダイアログボックスで選択したスクリプトファイルの内容に置換します。スクリプトが既に表示中または編集中の場合は置換できません。ここではスクリプトファイルを選択してください。バイナリファイル (アプリケーションなど) は選択しないでください。

タイムアウト (1～9999)

スクリプトの実行完了を待ち合わせる最大時間を指定します。

活性前後、非活性前後に実行されるスクリプトの既定値は 30 秒です。

[活性異常検出時の復旧動作] [非活性異常検出時の復旧動作]の[最終動作前にスクリプトを実行する]の[設定]ボタンから設定できるタイムアウトの既定値は 5 秒です。

実行ユーザ

スクリプトを実行するユーザを指定します。実行ユーザは [クラスタのプロパティ] の [アカウント] タブに登録されたユーザの中から選択可能です。

実行ユーザを指定しなかった場合、スクリプトはローカルシステムアカウントとして実行されます。

3.6. アプリケーションリソースを理解する

CLUSTERPRO では、CLUSTERPRO によって管理され、グループの起動時、終了時、フェイルオーバ発生時および移動時に実行されるアプリケーションを登録できます。アプリケーションリソースには、ユーザ独自のアプリケーションも登録できます。

3.6.1. アプリケーションリソースの依存関係

既定値では、以下のグループリソースタイプに依存します。

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
仮想コンピューター名リソース
ディスクリソース
ミラーディスクリソース
ハイブリッドディスクリソース
レジストリ同期リソース
CIFSリソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
AWS DNS リソース
Azure プローブポートリソース
Azure DNS リソース

3.6.2. アプリケーションリソースとは?

アプリケーションとは、ファイルの拡張子が exe/cmd/bat 等のファイルが、コマンドライン等から実行可能なプログラムを指します。

3.6.3. アプリケーションリソースに関する注意事項

アプリケーションリソースで実行されるアプリケーションの同一レビジョンのものが、フェイルオーバポリシーに設定されている全サーバに存在していることが必須です。

3.6.4. 詳細タブ

常駐タイプ

アプリケーションのタイプを設定します。以下の中から選択します。

• 常駐

  アプリケーションが常駐する場合に選択します。
• 非常駐

  アプリケーションが常駐しない (実行後に処理がすぐ戻る) 場合に選択します。

開始パス (1023 バイト以内)

アプリケーションリソースの開始時の実行可能ファイル名を設定します。

終了パス (1023 バイト以内)

アプリケーションリソースの終了時の実行可能ファイル名を設定します。常駐タイプが 常駐の場合以下の動作となります。

• 終了パスを指定しなかった場合

  非活性時にCLUSTERPRO より起動しているアプリケーションの終了処理を行います。
• 終了パスを指定した場合

  非活性時に終了パスで指定したアプリケーションを実行することにより起動しているアプリケーションの終了処理を行います。

注釈

[開始パス]、および [終了パス] には実行可能ファイル名の絶対パス、あるいは環境変数で設定されたパスの通った実行可能ファイル名を設定します。相対パスは指定しないでください。相対パスを指定した場合、アプリケーションリソースの起動に失敗する可能性があります。

調整

[アプリケーションリソース調整プロパティ] ダイアログボックスを表示します。アプリケーションリソースの詳細設定を行います。

アプリケーションリソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

同期 (開始)

常駐型アプリケーションの場合、本設定は無視されます。

非常駐型アプリケーションの場合、アプリケーションの実行時にアプリケーションの終了を待ちます。

非同期 (開始)

常駐型アプリケーションの場合、本設定は無視されます。

非常駐型アプリケーションの場合、アプリケーションの実行時にアプリケーションの終了を待ちません。

正常な戻り値 (開始) (1023 バイト以内)

[非同期] を選んだ場合、入力欄は入力できません。

常駐タイプが非常駐の場合に開始パスで設定した実行可能ファイルのエラーコードがどのような値の場合に正常と判断するかを設定します。

• 値がない場合

  戻り値は無視します。
• 値がある場合

  以下の入力規則に従ってください。

  ・0,2,3 のようにカンマで区切る

  ・0-3 のようにハイフンで指定

注釈

実行可能ファイルとしてバッチファイルを指定している場合、バッチファイルを実行する cmd.exe で異常が発生した場合に「1」が返却されますので、正常な戻り値として「1」を指定すると異常を検出できなくなります。

同期 (終了)

常駐型アプリケーションの場合、終了パスを指定しなかったときは起動しているアプリケーションの終了を待ちます。終了パスを指定したときは終了パスで指定したアプリケーションの終了を待ちます。

非常駐型アプリケーションの場合、アプリケーションの実行時にアプリケーションの終了を待ちます。

非同期 (終了)

常駐型アプリケーションの場合、起動しているアプリケーションまたは終了パスで指定したアプリケーションの終了を待ちません。

非常駐型アプリケーションの場合、アプリケーションの実行時にアプリケーションの終了を待ちません。

正常な戻り値 (終了) (1023 バイト以内)

[非同期] を選んだ場合、入力欄は入力できません。

常駐タイプが非常駐の場合に終了パスで設定した実行可能ファイルのエラーコードがどのような値の場合に正常と判断するかを設定します。

• 値がない場合

  戻り値は無視します。
• 値がある場合

  以下の入力規則に従ってください。

  ・0,2,3 のようにカンマで区切る

  ・0-3 のようにハイフンで指定

注釈

実行可能ファイルとしてバッチファイルを指定している場合、バッチファイルを実行する cmd.exe で異常が発生した場合に「1」が返却されますので、正常な戻り値として「1」を指定すると異常を検出できなくなります。

タイムアウト (開始) (1～9999)

常駐型アプリケーションの場合、本設定は無視されます。

非常駐型アプリケーションの場合、アプリケーションの実行時に終了を待つ場合 ([同期]) のタイムアウトを設定します。[同期] を選択している場合のみ入力可能です。設定時間内にアプリケーションが終了しないと、異常と判断します。

タイムアウト (終了) (1～9999)

常駐型アプリケーションの場合、起動しているアプリケーションまたは終了パスで指定したアプリケーションの終了を待つ場合 ([同期]) のタイムアウトを設定します。

非常駐型アプリケーションの場合、アプリケーションの実行時に終了を待つ場合 ([同期]) のタイムアウトを設定します。

[同期] を選択している場合のみ入力可能です。設定時間内にアプリケーションが終了しないと、異常と判断します。

対象 VCOM リソース名

アプリケーションリソースが使用するコンピュータ名に仮想コンピュータ名を渡す場合に設定します。選択肢にはアプリケーションリソースが所属するフェイルオーバグループ内に存在する仮想コンピュータ名リソース名が表示されます。

本パラメータを設定した場合、下記の環境変数を追加してアプリケーションを起動します。

COMPUTERNAME=<仮想コンピュータ名>

_CLUSTER_NETWORK_FQDN_=<仮想コンピュータ名>

_CLUSTER_NETWORK_HOSTNAME_=<仮想コンピュータ名>

_CLUSTER_NETWORK_NAME_=<仮想コンピュータ名>

デスクトップとの対話を許可する

実行するアプリケーションにデスクトップとの対話を許可するかどうかを設定します。設定した場合、アプリケーションが実行されると、デスクトップ上にアプリケーションの 画面が表示されます。

終了時アプリケーションを強制終了する

非活性時の終了処理としてアプリケーションを強制終了するかどうかを設定します。設定した場合、通常の終了処理を行わず強制終了によりアプリケーションを終了させます。常駐タイプに「常駐」を設定しており、かつ終了パスを指定していない場合のみ有効となります。

実行ユーザ

アプリケーションを実行するユーザを指定します。実行ユーザは [クラスタのプロパティ] の [アカウント] タブに登録されたユーザの中から選択可能です。

「個別指定する」を指定している場合、開始タブ/終了タブにおける実行ユーザの設定が使用されます。

「個別指定する」以外を指定している場合、開始タブ/終了タブの設定は使用されなくなり、本パラメータで指定した実行ユーザの設定が使用されます。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

開始タブ/終了タブ 共通

開始/終了に関する詳細設定が表示されます。

カレントディレクトリ (1023 バイト以内)

アプリケーションを実行する時のディレクトリを設定します。

オプションパラメータ (1023 バイト以内)

アプリケーションに対する入力パラメータを設定します。入力パラメータが複数ある場合は、スペース区切りで設定します。スペースを含む入力パラメータがある場合は、入力パラメータをダブルクオート(")で括ります。

例: "param 1" param2

ウィンドウサイズ

アプリケーションを実行する時のウィンドウサイズを以下の中から選択します。

• [非表示]

  アプリケーションは表示されません。
• [通常]

  アプリケーションは通常のウィンドウで表示されます。
• [最大化]

  アプリケーションは最大化のウィンドウで表示されます。
• [最小化]

  アプリケーションは最小化のウィンドウで表示されます。

実行ユーザ ドメイン (255 バイト以内)

アプリケーションを実行するユーザアカウントの所属するドメインを指定します。

[終了] タブの場合、グループの停止・再開は不要です。

実行ユーザ アカウント (255 バイト以内)

アプリケーションを実行するユーザアカウントを指定します。 1

[終了] タブの場合、グループの停止・再開は不要です。

実行ユーザ パスワード (255 バイト以内)

アプリケーションを実行するユーザアカウントのパスワードを指定します。

[終了] タブの場合、グループの停止・再開は不要です。

コマンドプロンプトから実行する

アプリケーションをコマンドプロンプト (cmd.exe) から実行するかどうかを設定します。ファイルの拡張子が、exe/cmd/bat 以外のアプリケーション (JavaScript や VBScript等) を実行する場合に指定します。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

1

実行ユーザアカウントを指定しなかった場合、アプリケーションはローカルシステムアカウントとして実行されます。

3.7. フローティング IP リソースを理解する

3.7.1. フローティング IP リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.7.2. フローティング IP とは?

クライアントアプリケーションは、フローティング IP アドレスを使用してクラスタサーバに接続することができます。フローティング IP アドレスを使用することにより、"フェイルオーバ"または、"グループの移動" が発生しても、クライアントは、接続先サーバの切り替えを意識 する必要がありません。

フローティング IP アドレスは、同一 LAN 上でもリモート LAN からでも使用可能です。

ClientはフローティングIP（FIP）によって Server 1へアクセスします。

図 3.43 フローティングIPによるアクセス (1)

Server 1からServer 2へのフェイルオーバが発生しても、Clientからの接続先はFIPであり、接続先サーバが変わったことを意識する必要はありません。

図 3.44 フローティングIPによるアクセス (2)

アドレスの割り当て

フローティング IP アドレスに割り当てる IP アドレスは、以下の条件を満たす必要があります。

• クラスタサーバが所属する LAN と同じネットワークアドレス内でかつ使用していないホストアドレス

この条件内で必要な数 (一般的にはフェイルオーバグループ数分) の IP アドレスを確保 してください。この IP アドレスは一般のホストアドレスと変わらないため、インターネットなどのグローバル IP アドレスから割り当てることも可能です。

また、フローティング IP アドレスに IPv6 アドレスを割り当てることも可能です。

切替方式の仕組み

フローティング IP リソースが活性するサーバから ARP ブロードキャストを送信することにより、ARP テーブル上の MAC アドレスが切り替わります。

フローティング IP リソースには ARP ブロードキャストを定期的に更新する機能はありません。必要に応じて、カスタム監視リソースなどによりネットワーク機器のARPテーブルを更新してください。

経路制御

ルーティングテーブルの設定は不要です。

使用条件

以下のマシンからフローティング IP アドレスにアクセスできます。

• クラスタサーバ自身

• 同一クラスタ内の他のサーバ、他のクラスタシステム内のサーバ

• クラスタサーバと同一 LAN 内およびリモート LAN のクライアント

さらに以下の条件であれば上記以外のマシンからでもフローティング IP アドレスが使用できます。ただし、すべてのマシン、アーキテクチャの接続を保障できません。事前に充分に評価をしてください。

• 通信プロトコルが TCP/IP であること

• ARP プロトコルをサポートしていること

スイッチング HUB により構成された LAN であっても、フローティング IP アドレスのメカニズムは問題なく動作します。

サーバダウン時には、接続していた TCP/IP コネクションは切断されます。

3.7.3. フローティング IP リソースに関する注意事項

IPが重複している状態でFIPの強制活性を行うと、Windows OSの仕様によりNICが無効化されてしまうため、[FIP 強制活性]は使用しないでください。

フローティング IP アドレスに IPv4 アドレスを割り当てる場合、以下の注意事項があります。

• フローティング IP リソースを停止すると、ルーティング情報が削除される場合があります。この現象を回避するためには、ルーティング情報登録時には下記のようにIFオプションによりインターフェイスを指定してください。

  
  

  route -p add [destination] [Mask netmask] [gateway] [IF interface]

フローティング IP アドレスに IPv6 アドレスを割り当てる場合、以下の注意事項があります。

• ManagementGroup のフローティング IP リソース (ManagementIP リソース) にIPv6 アドレスは指定しないでください。
• 仮想コンピュータ名リソースの設定で、IPv6 アドレスを割り当てたフローティング IPリソースを仮想コンピュータ名と関連付けるよう設定しても、この関連付けは無効と なります。
• 仮想コンピュータ名リソースで DNS への動的登録が設定されており、仮想コンピュータ名に対応付けるアドレスとしてフローティング IP アドレスが選択されている場合、このフローティング IP アドレスに IPv6 アドレスを割り当てることはできません。
• フローティング IP リソースを停止すると、ルーティング情報が削除される場合があります。この現象を回避するためには、ルーティング情報登録時には下記のようにIFオプションによりインターフェイスを指定してください。

  
  

  route -p add [destination] [Mask netmask] [gateway] [IF interface]

フローティング IP リソースを物理ホストに設定した際に、Windows の動作として物理ホスト名と FIP のレコードが DNS に登録されます（該当のネットワークアダプタのプロパティの設定でアドレスをDNSに登録する設定をONにしている場合）。物理ホストの名前解決で紐づくIPアドレスを物理IPアドレスにするためには以下のように設定してください。

• 該当のフローティング IP アドレスが付与されている、ネットワークアダプタの[プロパティ]-[インターネット プロトコル バージョン 4]-[詳細設定]-[DNS]タブ-[この接続のアドレスをDNSに登録する]に、チェックが入っている場合はチェックを外します。

• この設定を反映させるためには、以下のいずれかも合わせて実施してください。

  1. DNS Client サービスを再起動する。

  2. ipconfig /registerdns コマンドを明示的に実行する。

• DNSサーバに該当のフローティング IP アドレスが付与されているネットワークアダプタの物理IPアドレスを静的に登録してください。

フローティング IP リソースは、Windows OS の API を使用して NIC へフローティング IP アドレスを追加しています。その際、skipassource フラグについては設定していないため、フローティング IP リソース活性後は skipassource フラグが無効となります。skipassource フラグを有効に設定する場合は、フローティング IP リソース活性後に PowerShell などで設定してください。

クラスタ内のサーバにて OS のネットワーク負荷分散 (NLB) 機能を利用する場合、『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 -「OS のネットワーク負荷分散機能との共存について」を参照してください。

3.7.4. 詳細タブ

IP アドレス

使用するフローティング IP アドレスを入力します。

IPv4 アドレスを指定した場合、既定値ではマスクビット数を 24 として、ローカルコンピュータ上のサブネットマスクが一致するアドレスを検索し、該当するインデックスにフローティング IP アドレスを追加します。

IPv6 アドレスを入力する場合は、以下のように設定します。

例） fe80::1

フローティング IP リソースは、既定値ではプレフィックス長を 64Bit として、ローカルコンピュータ上のプレフィックスが一致するアドレスを検索し、該当するインデックスにフローティング IP アドレスを追加します。一致するアドレスが複数ある場合は、インデックス数値が 一番大きいインデックスにアドレスを追加します。

プレフィックス長を明示的に指定する場合は、アドレスの後、[/プレフィックス長] を指定します。

例） fe80::1/8

インデックスを明示的に指定する場合、アドレスの後、[%インデックス] を指定します。

例） fe80::1%5

上記の例ではインデックス 5 にフローティング IP アドレスを追加します。

調整

[フローティング IP リソース調整プロパティ] ダイアログボックスを表示します。フローティング IP リソースの詳細設定を行います。

フローティング IP リソース調整プロパティ

フローティング IP リソースに関する詳細設定が表示されます。

ping 実行

フローティング IP リソースを活性する前に [ping] コマンドを使用して重複した IP アドレスがないか確認を行うかどうかを設定します。

• チェックボックスがオン

  [ping] コマンドによる確認を行います。
• チェックボックスがオフ

  [ping] コマンドによる確認を行いません。

ping

フローティング IP リソースを活性する前に、重複した IP アドレスがないかチェックするために発行される [ping] コマンドに関する詳細設定です。

• インターバル (0～999)

  [ping] コマンドを発行する間隔を秒単位で設定します。
• タイムアウト (1～999999)

  [ping] コマンドのタイムアウトをミリ秒単位で設定します。
• リトライ回数 (0～999)

  [ping] コマンドのリトライ回数を設定します。
• FIP 強制活性

  [ping] コマンドによるチェックで重複した IP アドレスが検出された場合に、フローティング IP アドレスを強制的に活性するかどうかを設定します。必ずオフにしてください。
  • チェックボックスがオン

    強制活性を行います。
  • チェックボックスがオフ

    強制活性を行いません。

NIC Link Down を異常と判定する

フローティング IP リソースを活性する前に、NIC Link Downの確認を行うかどうかを設定します。

• チェックボックスがオン

  NIC Link Downの場合、フローティング IP リソースを活性化しません。
• チェックボックスがオフ

  NIC Link Downの場合でも、フローティング IP リソースを活性化します。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

3.8. ミラーディスクリソースを理解する

3.8.1. ミラーディスクリソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.8.2. ミラーディスクとは?

ミラーディスクとは、クラスタを構成する 2 台のサーバ間でディスクデータのミラーリングを行うディスクのペアのことです。

ミラーリングはパーティション単位で行われ、ミラーリング対象となるデータパーティションの他に、管理情報を記録するための RAW パーティション (クラスタパーティション) が必要です。また、ミラーリングを行う両サーバに CLUSTERPRO X Replicator 5.0 for Windows のライセンスが必要です。

• ディスクのタイプとジオメトリ

  両サーバのデータパーティションのサイズはバイト単位で完全に一致している必要が ありますが、ディスクのタイプやジオメトリが異なると完全に同じサイズのパーティションが作成できないことがあります。このため、データパーティションを確保するディスクは、両サーバでディスクのタイプとジオメトリを同じにしてください。

  両サーバで同じモデルのディスクを使用することを推奨します。

  例)

  組み合わせ	サーバ1	サーバ2
  OK	SCSI	SCSI
  OK	IDE	IDE
  NG	IDE	SCSI

  組み合わせ	ヘッド	セクタ	シリンダ
  OK かつ サーバ1	240	63	15881
  OK かつ サーバ2	240	63	15881
  NG かつ サーバ1	240	63	15881
  NG かつ サーバ2	120	63	31762

  両サーバでディスクのタイプやジオメトリを揃えられない場合は、ミラーディスクリソースを設定する前に [clpvolsz] コマンドにより両サーバのデータパーティションの正確なサイズを確認し、もしサイズが一致しない場合は再度 [clpvolsz] コマンドを使用して 大きいほうのパーティションを縮小してください。

  [clpvolsz] コマンドについての詳細は本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「パーティションサイズを調整する (clpvolszコマンド)」を参照してください。

• パーティションのドライブ文字

  両サーバのデータパーティションとクラスタパーティションには、同一のドライブ文字を 設定してください。

  両サーバに 1 つの SCSI ディスクを増設して 1 つのミラーディスクのペアにする場合

  

  図 3.45 増設したディスクをミラーディスクのペアにする場合

両サーバの OS が格納されている IDE ディスクの空き領域を使用してミラーディスクのペアにする場合

図では、ディスクのOS等が使用していない領域をミラーパーティションデバイス（クラスタパーティション、データパーティション）として使用しています。

図 3.46 ディスクの空き領域をミラーパーティションにする場合

• OS と同じディスク上に、ミラーパーティション (クラスタパーティション、データ パーティション) を確保することも可能です。

  • 障害時の保守性を重視する場合

    OS と別にミラー用のディスクを用意することを推奨します。
  • H/W Raid の仕様の制限で論理ディスクの追加ができない場合

    H/W Raid のプリインストールモデルで論理ディスク構成変更が困難な場合

    OS と同じディスクに、ミラーパーティション (クラスタパーティション、データパーティション) を確保することも可能です。

• ディスクの配置

  1 つのミラーディスクリソースでミラーリングできるのは 1 パーティションのみですが、複数のミラーディスクリソースを作成して複数のパーティションをミラーリング することが可能です。

  また 1 つのディスクに複数のデータパーティション・クラスタパーティションを配置して、複数のミラーディスクリソースを作成することができます。

  両サーバに 1 つの SCSI ディスクを増設して 2 つのミラーパーティションにする場合

  図は各ディスクに、クラスタパーティションのほか同サイズのパーティションを2つ確保し、データパーティションとして使用する場合を示しています。

  

  図 3.47 ディスク内の複数領域をミラーパーティションにする場合

  • クラスタパーティション 1 つとデータパーティション 2 つを確保してください。

  • それぞれのデータパーティションで使用するクラスタパーティションの管理領域のオフ セットインデックスを 0 と 1 に割り当てます。

  両サーバに 2 つのSCSIディスクを増設して 2 つのミラーパーティションにする場合

  図は、同サイズのパーティションを確保したディスクのペア2つを、ミラーパーティションとして使用する場合を示しています。

  

  図 3.48 各ディスクをミラーパーティションにする場合

  • 1 つ目のディスクにクラスタパーティションとデータパーティションを確保し、2 つ目の ディスクにデータパーティションを確保してください。

  • それぞれのデータパーティションで使用するクラスタパーティションの管理領域のオフ セットインデックスを 0 と １ に割り当てます。

  • クラスタパーティションをそれぞれのディスクに確保することもできます。その際、オフ セットインデックスは 0 と 0 に割り当てます。

  • 非同期モードでミラーリングする場合は、データパーティションへの書き込みに合わせてクラスタパーティションへのアクセスが発生します。クラスタパーティションとデータパーティションを別ディスクに確保することでディスクへのアクセスを分散できます。

  3台のサーバに 1 つの SCSI ディスクを増設して 2 つのミラーパーティションにする場合

  図は各ディスクに、クラスタパーティションのほか同サイズのパーティションを2つ確保し、Server 1とServer 2、Server 2とServer 3の間でデータパーティションとして使用する場合を示しています。

  

  図 3.49 ディスク内の複数領域をミラーパーティションにする場合（サーバ3台）

  • それぞれのサーバにクラスタパーティション 1 つとデータパーティション 2 つを確保してください。

  • Server 2 には、Server 1 とミラーリングするためのデータパーティションと、Server 3 とミラーリングするためのデータパーティションの、 2 つが必要です。

  • それぞれのデータパーティションで使用するクラスタパーティションの管理領域のオフ セットインデックスを 0 と 1 に割り当てます。

データパーティション

CLUSTERPRO のミラーディスクリソースがミラーリングしたデータ (業務データなど) を格納するパーティションのことを、データパーティションといいます。

データパーティションは以下のように割り当ててください。

• データパーティションのサイズ

  パーティションのサイズに制約はありません。任意のサイズで確保してください。
• データパーティションのコピー所要時間

  初期構築時やディスク交換時にフルコピーを行う際、ボリュームの利用領域のサイズに比例して所要時間が増加します。ボリュームの利用領域が特定できない場合は、ボリュームの全領域をコピーするため、データパーティションのサイズに比例して所要時間が増加します。
• ファイルシステム

  パーティションは NTFS でフォーマットしてください。FAT/FAT32 はサポートしていません。

• ベーシックディスク上に割り当ててください。ダイナミックディスクはサポートしていません。

• データパーティションを拡張パーティション上の論理パーティションとして作成する場合は、両サーバとも論理パーティションにしてください。基本パーティションと論理パーティションでは同じサイズを指定しても実サイズが若干異なることがあります。

• データパーティションへのアクセスは CLUSTERPRO により制御されます。

クラスタパーティション

CLUSTERPRO がミラーパーティション制御のために使用する専用パーティションを、クラスタパーティションといいます。

クラスタパーティションは以下のように割り当ててください。

• クラスタパーティションのサイズ

  最低 1024MiB 確保してください。ジオメトリによって 1024MB 以上になる場合がありますが、1024MB 以上でも問題ありません。

• クラスタパーティションは、データミラーリング用のデータパーティションとペアで割り当てる必要があります。複数のミラーディスクで1つのクラスタパーティションを使用する場合は、クラスタパーティション内で使用する領域が重ならないようミラーディスク毎に異なるインデックス番号を割り当てます。

• クラスタパーティションにファイルシステムを構築しないでください。フォーマットしないでください。

• クラスタパーティションへのアクセスは制限されます。

データパーティションのアクセス制御

ミラーディスクリソースによりミラーリングされるデータパーティションは、ミラーディスクリソースが活性化されている現用系サーバからのみアクセス可能になります。

• ファイルシステムのアクセス制御は、CLUSTERPRO が行います。

  業務アプリケーションなどからの、データパーティションへのアクセス可否の考え方は、共有ディスクの切替パーティション (ディスクリソース) と同じです。

• ミラーパーティションの切り替えは、フェイルオーバグループごとにフェイルオーバポリシーにしたがって行われます。

• 業務に必要なデータは、データパーティション上に格納しておくことで、フェイルオーバ時、フェイルオーバグループの移動時などに自動的に引き継がれます。

Server 1に接続されている Mirror disk 1 および Server 2に接続されている Mirror disk 2は、ペアとしてその間でディスクデータのミラーリングを行います。

図 3.50 ミラーディスク構成 (1)

図 3.51 ミラーディスク構成 (2)

3.8.3. ミラーパラメータ設定の考え方

リクエストキュー最大サイズ

ミラーディスクドライバがサーバ間通信で I/O 要求を受信するためのキューサイズを設定 します。大きくするとパフォーマンスが向上しますが、メモリを多く消費します。小さくするとメモリの使用量が少なくなりますが、パフォーマンスが低下する可能性があります。

以下を目安に設定してください。

• 以下のような条件では大きくすると性能向上が期待できます。

• サーバに物理メモリが多く搭載されていて空きメモリサイズが十分ある。

• ディスクの I/O 性能が良い。

• 以下のような条件では小さくすることを推奨します。

• サーバに搭載されている物理メモリが少ない。

• ディスクの I/O 性能が悪い。

ミラーコネクトタイムアウト

ミラー復帰やデータ同期時に、サーバ間通信で無応答となった場合やデータ同期が完了しない場合にミラーコネクトを切断するまでの時間です。ミラーコネクトの回線速度が遅い場合やミラーディスクへの負荷が高い場合は、タイムアウト時間を長く設定する必要があります。

本パラメータはハートビートタイムアウト未満となるように下記計算式を目安に調整してください。

ハートビートタイムアウト = ミラーコネクトタイムアウト + 10秒

※ハートビートタイムアウトの設定については、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「タイムアウトタブ」を参照してください。

初期ミラー構築

クラスタ構築後の初回起動時に初期ミラー構築を行う挙動を設定します。

• 初期ミラー構築を行う

  クラスタ構築後の初回起動時に初期ミラー構築 (データパーティションのディスクイメージのフルコピー) を行います。
• 初期ミラー構築を行わない

  既にデータパーティション内のデータがサーバ間で一致しているものと見なし、クラスタ構築後の初回起動時に初期ミラー構築を行いません。クラスタ構築時に CLUSTERPRO 以外の手段でデータパーティションのディスクイメージ (物理データ)を同一にする必要があります。

モード

ミラーリングの同期方式を切り換えます。

モード	概要	説明
同期	現用系と待機系のデータが完全に一致することを保証します。	ミラーリングされたディスクへの書き込み完了は、ローカルディスクへの書き込みとリモートディスクへの書き込みの両方の 完了を待ち合わせます。
非同期	データ更新の書込み順序は保証されますが、サーバダウン等によりミラーディスクリソースを非活性化できない形でフェイルオーバした場合、最新の更新データが失われる可能性があります。	ミラーリングされたディスクへの書き込み完了は、ローカルディスクへの書き込みのみを待ち合わせます。 リモートディスクへの書き込みは、書き込み要求がキューイングされ、バックグラウンドで実行されます。 キューイングされた書き込みデータはカーネル空間メモリに保持後、ユーザ空間メモリに転送されます。ユーザ空間メモリで保持できる限界に達した場合、一時ファイルに出力し保持します。

カーネルキューサイズ

モードが [非同期] の場合のリモートディスクへの書き込み要求をカーネル空間のメモリで保持するサイズを指定します。通常は既定値のまま使用します。

カーネルキューに書き込みデータが格納できたら、I/O が完了となります。

CPU 負荷が高くてアプリケーションキューへのデータ引取りが遅延する場合はサイズを増やしますが、大きくしすぎるとシステムリソースを圧迫します。

アプリケーションキューサイズ

モードが [非同期] の場合のリモートディスクへの書き込み要求をユーザ空間のメモリで 保持するサイズを指定します。通常は既定値のまま使用しますが、高速なネットワークを使う場合は、このキューのサイズを大きくすることで一時ファイルの作成頻度を低減して、ディスク I/O によるオーバーヘッドを削減できます。

通信帯域制限

モードが [非同期] の場合、一旦キューイングした書き込みデータを可能な限り高速に待機系に転送しようとするため、ミラーコネクトに使用する通信路を他のアプリケーション通信にも使用する場合、通信帯域が圧迫されて他の通信が阻害される可能性があります。このような場合、ミラーコネクト通信に使用する通信帯域を制限することにより、他の通信への影響を軽減することができます。ただし、ミラーコネクトに使用可能な通信帯域がミラーディスクへの書き込みデータ量の平均値を下回る場合、キューイングしたデータを待機系に転送しきれなくなり、オーバーフローによりミラーリングが中断することになりますので、業務アプリケーションの書き込みデータ量に対して十分な通信帯域を確保する必要があります。

なお、本機能は 1 秒間のデータ送信量の総和が設定値を超えた場合に最大 1 秒の待ち時間を設けることで通信帯域を制限しているため、 1 回のディスク書き込みデータサイズが設定値を超える場合には期待する効果が見込めないことがあります。例えば、ミラーディスクのコピー実行時の 1 回の送信データサイズは 64KByte となりますので、本設定値を64KByte /秒以下に設定してもコピー実行時の通信量が設定値を上回る可能性があります。

参考

ミラーディスクリソース毎に設定する通信帯域制限の他に、Windows標準の機能を利用してミラーディスクコネクト毎に通信帯域制限を行うことも可能です。詳細は『メンテナンスガイド』の「保守情報」の「ミラーコネクト通信の帯域制限」を参照してください。

履歴ファイル格納フォルダ

モードが [非同期] の場合のリモートディスクへの書き込み要求がアプリケーションキューに記録しきれなくなった場合に作成する一時ファイルを保持するフォルダを指定します。通信 帯域が不足している場合、履歴ファイルのサイズ制限を設定していないとディスク容量の上限までデータを記録しますので、システムディスク上のフォルダを指定すると空きスペース 不足となりシステムの動作が不安定になる可能性があります。このため、一定のサイズを 超えたらミラーリングを中断したいという場合は、履歴ファイルサイズ制限を設定するか、専用のパーティションを作成してください。

履歴ファイル格納フォルダにクラスタパーティション、データパーティション上のフォルダを指定しないでください。また、パスに2バイト文字を含むフォルダを指定しないでください。

スレッドタイムアウト

モードが [非同期] の場合に、カーネルキューからアプリケーションキューへ転送できない 状態が続いた場合にタイムアウトする時間です。タイムアウトするとミラーコネクトが切断されます。

高負荷によりアプリケーションキューへの転送が遅延すると、タイムアウトが発生することがあります。このような場合は値を増やしてください。

ミラー通信を暗号化する

ミラーディスクコネクトを流れる通信データの暗号化有無を指定します。

暗号化アルゴリズムとしてAdvanced Encryption Standard (GCM) を使用し、最大256bitの暗号化鍵長をサポートします。

ミラーディスクコネクトの経路が外部の回線を経由する場合は、暗号化を使用することを推奨します。

3.8.4. ミラーディスクの構築例

• 初期ミラー構築を行う

  まず、二重化する Application のデータをクラスタ構築前に用意できる場合には、先に現用系のミラーディスク（Mirror disk 1）のデータパーティションに作成しておきます（ex. データベースの初期DBなど）。 パーティション構成は "3.8.2. ミラーディスクとは?" を参照してください。 次に、Server 1、Server 2のそれぞれに CLUSTERPROをインストールし、セットアップを行います。

  

  図 3.52 ミラーディスク構築例（初期ミラー構築を行う）(1)

  続いて初期ミラー構築を開始します。 Server 1の Mirror disk 1から Server 2の Mirror disk 2へ、全面コピーを行います。

  

  図 3.53 ミラーディスク構築例（初期ミラー構築を行う）(2)

• 初期ミラー構築を行わない

たとえば以下のような方法で両サーバのデータパーティションの内容を同一にすることができます。

1. 二重化する AP のデータをクラスタ構築前に用意できる場合には先に現用系のミラーディスクのデータパーティションに予め作成しておきます。(ex. データベースの初期データなど)

2. CLUSTERPRO をインストールし、初期ミラー構築を行わない設定でクラスタを構築します。

3. クラスタシャットダウンを行います。

4. 両サーバのデータパーティションがあるディスクを取り外し、Linux サーバに接続 して、ディスクをマウントしない状態で [dd] コマンドなどにより現用系側のデータパーティションのデータを

   待機系側のデータパーティションにコピーします。

5. ディスクを現用系と待機系へ戻し、両サーバを起動します。

3.8.5. ミラーディスクリソースに関する注意事項

• 両サーバで同一パーティションに対して、同一ドライブ文字でアクセスできるように設定してください。

• 現在パーティションに設定されているドライブ文字と異なるドライブ文字を設定した場合、ミラーディスクリソースの起動時にドライブ文字が変更されます。ドライブ文字が他のパーティションで使用されている場合、ミラーディスクリソースの起動に失敗します。

• ハイブリッドディスクリソースでミラーリングしていたディスクをミラーディスクリソースでミラーリングするように構成変更する場合、まず既存のハイブリッドディスクリソースを削除した構成情報をアップロードして、既存のリソースが削除された状態に変更してから、ミラーディスクリソースを追加した構成情報をアップロードしてください。

• ミラーディスクリソースのデータパーティションおよびクラスタパーティションには、全サーバで同一論理セクタサイズのディスク装置を使用してください。異なる論理セクタサイズのディスク装置を使用すると、正常に動作しません。データパーティションとクラスタパーティションでは論理セクタサイズが異なっていても動作可能です。

例)

組み合わせ	パーティションの論理セクタサイズ				説明
	サーバ1側	サーバ1側	サーバ2側	サーバ2側
	データパー ティション	クラスタパー ティション	データパー ティション	クラスタパー ティション
OK	512B	512B	512B	512B	論理セクタサイズが統一されている
OK	4KB	512B	4KB	512B	データパーティションで4KB、クラスタパーティションで512Bに統一されている
NG	4KB	512B	512B	512B	データパーティションの論理セクタサイズが統一されていない
NG	4KB	4KB	4KB	512B	クラスタパーティションの論理セクタサイズが統一されていない

3.8.6. 詳細タブ

ミラーディスク番号

ミラーパーティションに割り当てるミラーディスク番号を選択します。

データパーティションのドライブ文字 (1023 バイト以内)

データパーティションのドライブ文字 (A～Z) を設定します。

クラスタパーティションのドライブ文字 (1023 バイト以内)

クラスタパーティションのドライブ文字 (A～Z) を設定します。

クラスタパーティションのオフセットインデックス

クラスタパーティション内で使用する領域のインデックス番号を選択します。複数のミラー ディスクを使用する場合は、クラスタパーティション内で使用する領域が重ならないようミラーディスク毎に異なるインデックス番号を割り当てます。

選択

データミラーリング通信に使用する通信経路 (ミラーディスクコネクト) を選択します。 [ミラーディスクコネクトの選択] ダイアログボックスを表示します。

• 追加

  使用するミラーディスクコネクトを追加する場合に使用します。[利用可能なミラーディスクコネクト] から追加したいミラーディスクコネクトを選択して、[追加] をクリックします。[ミラーディスクコネクト一覧] に追加します。

  ミラーディスクコネクトは、1つのミラーディスクリソースに対して2本まで設定可能です。
• 削除

  使用するミラーディスクコネクトを削除する場合に使用します。[ミラーディスクコネクト一覧] から削除したいサーバを選択して、[削除] をクリックします。[利用可能なミラーディスクコネクト] に追加されます。
• 順位

  ミラーディスクコネクトの優先順位を変更する場合に使用します。[利用可能なミラーディスクコネクト] から変更したいミラーディスクコネクトを選択して、矢印をクリックします。選択行が移動します。

ミラーディスクコネクトの設定については、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「インタコネクトタブ」を参照してください。

追加

[起動可能サーバ] に選択したサーバを追加します。選択したサーバの [パーティションの選択] ダイアログボックスを表示します。

• 接続

  サーバに接続して、パーティションの一覧を取得します。
• データパーティション

  一覧からデータパーティションとして使用するパーティションを選択します。選択したデータパーティションの GUID が表示されます。
• クラスタパーティション

  一覧からクラスタパーティションとして使用するパーティションを選択します。選択したクラスタパーティションの GUID が表示されます。

重要

データパーティション、クラスタパーティションに指定するパーティションはそれぞれ別々のパーティションを指定してください。同一のパーティションを指定した場合、データが 破壊される可能性があります。

またデータパーティション、クラスタパーティションには共有ディスク上のパーティションを指定しないでください。

削除

[起動可能サーバ] から選択したサーバを削除します。

編集

選択したサーバの [パーティションの選択] ダイアログボックスを表示します。

調整

[ミラーディスクリソース調整プロパティ] ダイアログボックスを表示します。ミラーディスクリソースの詳細設定を行います。

ミラーディスクリソース調整プロパティ

ミラータブ

ミラーに関する詳細設定が表示されます。

初期ミラー構築を行う

クラスタ構築時の初期ミラー構築 (データパーティションのフルコピー) を行うかどうかを指定します。

• チェックボックスがオン

  初期ミラー構築を行います。通常はこちらを指定します。
• チェックボックスがオフ

  初期ミラー構築を行わず、構築済みとして扱います。既にデータパーティションの 内容が一致していて、フルコピーを実施する必要がない場合には、こちらを指定します。

ミラーコネクトタイムアウト (2～9999)

ミラーコネクトのタイムアウトを設定します。

リクエストキュー最大サイズ (512～65535)

ミラーディスクドライバがサーバ間通信で I/O 要求を受信するためのキューサイズを設定 します。

モード

ミラーデータの同期のモードを切り換えます。

• 同期

  ローカルディスクとリモートディスクに並行して書き込み、両方の完了を待ち合わせ ます。
• 非同期

  ローカルディスクへ書き込み後、リモートディスクへ書き込みます。ローカルディスクへの書き込み完了のみを待ち合わせます。

カーネルキューサイズ (512～65535)

非同期ミラーの I/O データを一時的に蓄えるためのカーネル空間のキューのサイズを設定します。

アプリケーションキューサイズ (512～65535)

非同期ミラーの I/O データを一時的に蓄えるためのユーザ空間のキューのサイズを設定 します。

通信帯域制限 (0～999999999)

ミラーコネクトで使用する通信帯域の上限を設定します。

スレッドタイムアウト (2～9999)

カーネルキューからアプリケーションキューへ転送できなくなった場合のタイムアウトを設定します。

履歴ファイル格納フォルダ (1023 バイト以内)

I/O データがアプリケーションキューを溢れた場合にファイル出力する出力先フォルダを設定します。リモートディスクと未同期の I/O データをファイルとして保持するため、十分な空き容量があるフォルダを設定する必要があります。

履歴ファイル格納フォルダにクラスタパーティション、データパーティション上のフォルダを指定しないでください。また、パスに 2 バイト文字を含むフォルダを指定しないでください。

また、Windowsのシステムドライブ(通常はC: )以外に履歴ファイル格納フォルダを設定することを推奨します。システムドライブ上に設定すると、I/Oの集中により、ミラー処理が遅延する、システムが不安定になるなどの現象が起こることがあります。

履歴ファイルサイズ制限 (0～999999999)

履歴ファイル格納フォルダに格納する一時ファイルのサイズの上限を設定します。サイズ制限を設定すると、このミラーディスクリソースの一時ファイルの総量が上限に達した時点でミラーリングを中断します。なお、ここで設定する値は対象ミラーディスクリソースの一時ファイルサイズの上限であり、履歴ファイル格納フォルダ内の一時ファイルの総量を制限するものではありません。

なお、ミラーディスクリソースの一時ファイルの総量が上限値に達しない場合でも、未送信データ件数が「非同期モードでの履歴記録領域サイズ」の上限に達するとミラーリングを中断します。詳細は、「クラスタプロパティ」の「ミラーディスクタブ」の「非同期モードでの履歴記録領域サイズ」を参照してください。

データを圧縮する

ミラーディスクコネクトを流れるミラーデータを圧縮するかどうかを設定します。

復帰時データを圧縮する

ミラー復帰のためにミラーディスクコネクトを流れるデータを圧縮するかどうかを設定します。

ミラー通信を暗号化する

ミラーディスクコネクトを流れるデータを暗号化するかどうかを設定します。ミラー同期の通信データおよびミラー復帰の通信データ、両方に作用します。

• チェックボックスがオン

  ミラーディスクコネクトを流れるデータが暗号化されます。
• チェックボックスがオフ

  ミラーディスクコネクトを流れるデータは暗号化されません。

鍵ファイルフルパス

ミラーディスクコネクトを流れるデータを暗号化する鍵ファイルを指定します。

注釈

鍵ファイルはclpkeygenコマンドを使用して生成したものを使用します。clpkeygenコマンドの詳細は「9. CLUSTERPRO コマンドリファレンス」 - 「通信暗号化用の鍵ファイルを作成する (clpkeygenコマンド)」を参照してください。

重要

必ず、ミラーディスクリソースが活性可能な全サーバで同じ鍵ファイルを使用してください。鍵ファイルが異なると、正常にミラーリングできません。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

3.8.7. ミラーディスクリソース運用に関する注意事項

両サーバでミラーデータが同期している状態からクラスタシャットダウンした場合、その後は以下に述べるいずれかの順序でサーバ起動を行ってください。

• 両サーバを同時に起動する

• サーバ1台目を起動し、サーバ1台目が起動した状態のままサーバ2台目を起動する

サーバ起動とシャットダウンを1サーバずつ交互に行う 2 ことは避けてください。

各サーバが保持するミラーデータの最新/非最新は、サーバ同士の通信によって判断されます。前述 2 の操作を行った場合、ミラーデータの最新/非最新が正確に判断されなくなるため、次回の両サーバ起動時にミラーディスクリソースの起動に失敗します。

2(1,2)

サーバ1台目を起動しシャットダウンしたのち、サーバ2台目を起動しシャットダウン

3.9. レジストリ同期リソースを理解する

3.9.1. レジストリ同期リソースの依存関係

既定値では、以下のグループリソースタイプに依存します。

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
仮想コンピューター名リソース
ディスクリソース
ミラーディスクリソース
ハイブリッドディスクリソース
CIFSリソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
AWS DNS リソース
Azure プローブポートリソース
Azure DNS リソース

3.9.2. レジストリ同期リソースとは?

図 3.54 レジストリ同期リソース (1)

図 3.55 レジストリ同期リソース (2)

フェイルオーバ時に同期するレジストリキーを設定することができます。レジストリ同期リソースが活性している状態で、同期対象として設定されたレジストリキー配下の内容が更新された場合、フェイルオーバ時にこの更新内容がフェイルオーバ先サーバのレジストリに反映されます。

レジストリ同期リソースは、以下のようにしてサーバ間でレジストリの同期を行います。

1. フェイルオーバグループにレジストリ同期リソースがある場合、レジストリ同期リソースが活性化されると、設定されているレジストリキーの更新を監視します。

2. レジストリキーの更新を検出すると、そのレジストリキー配下をファイルとして、ローカルディスクに保存します。また、このファイルを、フェイルオーバ先となる各サーバに配信 します。

3. 配信を受けたサーバはローカルディスクにこれを保持します。フェイルオーバが発生し、そのサーバでレジストリ同期リソースが活性された場合、配信されたファイルの内容を該当する

   レジストリキーに復元します。

3.9.3. レジストリ同期リソースに関する注意事項

• 待機系サーバでは、同期対象レジストリキーをオープンしないでください。

• フェイルオーバ発生時、フェイルオーバ先サーバで同期対象レジストリキーがオープンされていると、レジストリの復元処理が失敗します。同期対象レジストリキーを使用するアプリケーションは、スクリプトリソース等を利用して CLUSTERPRO の制御下で起動・停止してください。

• 同期対象レジストリキーには必要最小限のものだけを設定してください。また、頻繁に更新が発生するレジストリキーを同期対象レジストリキーに設定することはおすすめできません。

• レジストリ同期リソースが活性している状態では、同期対象レジストリキーの更新が発生する度に、ファイルへの保存処理および他サーバへの配信処理が実行されます。同期対象レジストリキーの数や更新頻度により大量の更新が発生すると、 これらの処理がシステムのパフォーマンスに影響を与える場合があります。

  また、同期対象レジストリキーの名前変更/削除をしないでください。

• 同期対象レジストリキーには、以下のレジストリキーを設定することができます。これら以外のレジストリキーを同期させることはできません。

  • HKEY_USERS 配下の任意キー

  • HKEY_LOCAL_MACHINE 配下の任意のキー

  ただし、以下のキーは設定しないでください。

  • HKEY_LOCAL_MACHINE¥SOFTWARE¥NEC¥CLUSTERPRO 配下のキー

  • HKEY_LOCAL_MACHINE¥SOFTWARE¥NEC

  • HKEY_LOCAL_MACHINE¥SOFTWARE

  • HKEY_LOCAL_MACHINE

  また、同一リソース内で親子関係となるレジストリキーは設定しないでください。

• 同期対象レジストリキーは、1 リソースにつき最大 16 個まで設定できます。

• 同期対象レジストリキー名ついては、以下の規則があります。

  • 使用可能文字はレジストリキーに関する OS の仕様に従います。

  • 最大 259 バイトまでです。260 バイト以上のキー名は設定しないでください。

3.9.4. 詳細タブ

追加

監視するレジストリキーを追加します。[レジストリキーの入力] ダイアログボックスが表示 されます。

レジストリキー

同期を行うレジストリキーを入力して [OK] を選択してください。

削除

[レジストリ一覧] で選択しているレジストリキーを同期対象から削除します。

編集

[レジストリキーの入力] ダイアログボックスが表示されます。[レジストリ一覧] で選択しているレジストリキーが表示されるので、編集して [OK] を選択します。

レジストリ同期リソース調整プロパティ

パラメータタブ

レジストリ同期に関する詳細設定が表示されます。

配信インターバル (1～99)

レジストリキーの更新内容を他サーバへ配信する時のインターバルを設定します。

インターバルを小さくした場合

• 更新内容は、すぐに他サーバへ配信されます。

• レジストリキーの更新頻度により、システムの負荷が増大する場合があります。

インターバルを大きくした場合

• 更新内容が他サーバへ配信されるまでに遅延が発生する場合があります。更新内容の配信が完了していない状態でフェイルオーバが発生した場合、その更新内容はフェイルオーバ先のサーバに反映されません。

• レジストリキーの更新頻度が多い場合に、同期処理によるシステムの負荷の増大を抑えることができます。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

3.10. スクリプトリソースを理解する

CLUSTERPRO では、CLUSTERPRO によって管理され、グループの起動時、終了時、フェイルオーバ発生時および移動時に実行されるスクリプトを登録できます。スクリプトリソースには、ユーザ独自のスクリプトなども登録できます。

注釈

スクリプトリソースで実行されるアプリケーションの同一レビジョンのものが、フェイルオーバポリシーに設定されている全サーバに存在していることが必須です。

3.10.1. スクリプトリソースの依存関係

既定値では、以下のグループリソースタイプに依存します。

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
仮想コンピューター名リソース
ディスクリソース
ミラーディスクリソース
ハイブリッドディスクリソース
レジストリ同期リソース
CIFSリソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
AWS DNS リソース
Azure プローブポートリソース
Azure DNS リソース

3.10.2. スクリプトリソースで使用するスクリプト

スクリプトの種類

スクリプトリソースには、それぞれ開始スクリプトと終了スクリプトが用意されています。CLUSTERPRO は、クラスタの状態遷移が必要な場面において、スクリプトリソースごとのスクリプトを実行します。クラスタ環境下で動作させたいアプリケーションの起動、終了、もしくは復旧の手順を、これらのスクリプトに記述する必要があります。

図 3.56 開始スクリプトと終了スクリプト

start.bat

開始スクリプト

stop.bat

終了スクリプト

3.10.3. スクリプトリソースのスクリプトで使用する環境変数

CLUSTERPRO は、スクリプトを実行する場合に、どの状態で実行するか (スクリプト実行要因) などの情報を環境変数にセットします。

スクリプト内で下図の環境変数を分岐条件として、システム運用にあった処理内容を記述 できます。

終了スクリプトの環境変数は、直前に実行された開始スクリプトの内容を、値として返します。開始スクリプトでは CLP_FACTOR の環境変数はセットされません。

CLP_LASTACTION の環境変数は、CLP_FACTOR の環境変数がCLUSTERSHUTDOWN または SERVERSHUTDOWN の場合にのみセットされます。

環境変数	環境変数の値	意味
CLP_EVENT …スクリプト実行要因	START	クラスタの起動により、実行された場合。 グループの起動により、実行された場合。 グループの移動により、移動先のサーバで実行された場合。 モニタリソースの異常検出によるグループの再起動により、同じサーバで実行された場合。 モニタリソースの異常検出によるグループリソースの再起動により、同じサーバで実行 された場合。
〃	FAILOVER	サーバダウンにより、フェイルオーバ先の サーバで実行された場合。 モニタリソースの異常検出により、フェイルオーバ先のサーバで実行された場合。 グループリソースの活性失敗により、フェイルオーバ先のサーバで実行された場合。
〃	RECOVER	サーバの復帰を行った場合。 モニタリソースで異常を検出した場合。 グループリソースの活性処理が異常終了した場合。
CLP_FACTOR …グループ停止要因	CLUSTERSHUTDOWN	クラスタ停止により、グループの停止が実行された場合。
〃	SERVERSHUTDOWN	サーバ停止により、グループの停止が実行された場合。
〃	GROUPSTOP	グループ停止により、グループの停止が実行された場合。
〃	GROUPMOVE	グループ移動により、グループの移動が実行された場合。
〃	GROUPFAILOVER	モニタリソースの異常検出により、グループのフェイルオーバが実行された場合。 グループリソースの活性失敗により、グループのフェイルオーバが実行された場合。
〃	GROUPRESTART	モニタリソースの異常検出により、グループの再起動が実行された場合。
〃	RESOURCERESTART	モニタリソースの異常検出により、グループ リソースの再起動が実行された場合。
CLP_LASTACTION …クラスタ停止後処理	REBOOT	OS を reboot (再起動) する場合。
〃	HALT	OS を halt (シャットダウン) する場合。
〃	NONE	何もしない。
CLP_SERVER ……スクリプトの実行サーバ	HOME	グループの、プライマリサーバで実行された。
〃	OTHER	グループの、プライマリサーバ以外で実行された。
CLP_DISK 3 …共有ディスクまたはミラーディスク上 のパーティション接続情報	SUCCESS	接続に失敗しているパーティションはない。
〃	FAILURE	接続に失敗しているパーティションがある。
CLP_PRIORITY …スクリプトが実行されたサーバの フェイルオーバポリシーの順位	1～クラスタ内のサーバ数	実行されているサーバの、プライオリティを示す。1 から始まる数字で、小さいほどプライオリティが高いサーバ。 CLP_PRIORITY が 1 の場合、プライマリサーバで実行されたことを示す。
CLP_GROUPNAME …グループ名	グループ名	スクリプトが属している、グループ名を示す。
CLP_RESOURCENAME …リソース名	リソース名	スクリプトが属している、リソース名を示す。
CLP_PID …プロセス ID	プロセス ID	プロパティとして開始スクリプトが非同期に設定されている場合、開始スクリプトのプロセスIDを示す。開始スクリプトが同期に設定されている場合、本環境変数は値を持たない。
CLP_VERSION_FULL …CLUSTERPROフルバージョン	CLUSTERPROフルバージョン	CLUSTERPROのフルバージョンを示す。（例） 13.01
CLP_VERSION_MAJOR …CLUSTERPROメジャーバージョン	CLUSTERPROメジャーバージョン	CLUSTERPROのメジャーバージョンを示す。（例）13
CLP_PATH …CLUSTERPROインストールパス	CLUSTERPROインストールパス	CLUSTERPROがインストールされているパスを示す。（例）C:\Program Files\CLUSTERPRO
CLP_OSNAME …サーバOS名	サーバOS名	スクリプトが実行されたサーバのOS名を示す。 （例）Windows Server 2016 Standard
CLP_OSVER …サーバOS名	サーバOSバージョン	スクリプトが実行されたサーバのOSバージョンを示す。 （例）6.2.0.0.274.3
CLP_SERVER_PREV …フェイルオーバ元サーバ名	サーバ名	CLP_EVENT が FAILOVER の場合のみ、スクリプトが所属するグループのフェイルオーバ元を示す。CLP_EVENT が FAILOVER以外の場合は不定値となる。

3

ディスクリソース、ミラーディスクリソース、ハイブリッドディスクリソースが対象になります。

[スクリプトリソース調整プロパティ] の [待機系サーバで実行する] が有効に設定され、スクリプトを待機系サーバ上で実行する場合、環境変数にセットされる情報は下図のとおりとなります。

環境変数	環境変数の値	意味
CLP_EVENT …スクリプト実行要因	STANDBY	待機系サーバ上で実行された場合。
CLP_SERVER ……スクリプトの実行サーバ	HOME	グループの、プライマリサーバで実行された。
〃	OTHER	グループの、プライマリサーバ以外で実行された。
CLP_PRIORITY …スクリプトが実行されたサーバの フェイルオーバポリシーの順位	1～クラスタ内のサーバ数	実行されているサーバの、プライオリティを示す。1 から始まる数字で、小さいほどプライオリティが高いサーバ。 CLP_PRIORITY が 1 の場合、プライマリサーバで実行されたことを示す。
CLP_GROUPNAME …グループ名	グループ名	スクリプトが属している、グループ名を示す。
CLP_RESOURCENAME …リソース名	リソース名	スクリプトが属している、リソース名を示す。
CLP_VERSION_FULL …CLUSTERPROフルバージョン	CLUSTERPROフルバージョン	CLUSTERPROのフルバージョンを示す。（例） 13.01
CLP_VERSION_MAJOR …CLUSTERPROメジャーバージョン	CLUSTERPROメジャーバージョン	CLUSTERPROのメジャーバージョンを示す。（例）13
CLP_PATH …CLUSTERPROインストールパス	CLUSTERPROインストールパス	CLUSTERPROがインストールされているパスを示す。（例）C:\Program Files\CLUSTERPRO
CLP_OSNAME …サーバOS名	サーバOS名	スクリプトが実行されたサーバのOS名を示す。 （例）Windows Server 2016 Standard
CLP_OSVER …サーバOSバージョン	サーバOSバージョン	スクリプトが実行されたサーバのOSバージョンを示す。 （例）6.2.0.0.274.3

3.10.4. スクリプトリソース スクリプトの実行タイミング

開始、終了スクリプトの実行タイミングと環境変数の関連を、クラスタ状態遷移図にあわせて説明します。

• 説明を簡略にするため、2 台構成のクラスタで説明します。

  3 台以上の構成の場合に、発生する可能性のある実行タイミングと環境変数の関連は、補足という形で説明します。

  サーバ	サーバ状態
  	正常状態 (クラスタとして正常に動作している)
  	停止状態 (クラスタが停止状態)

  (例) 正常状態にあるサーバにおいてGroup Aが動作している。

  

• 各グループは、起動したサーバの中で、最もプライオリティの高いサーバ上で起動 されます。

• クラスタに定義されているグループはA、B、Cの3つで、それぞれ以下のようなフェイルオーバポリシーを持っています。

  グループ	優先度1サーバ	優先度2サーバ
  A	Server 1	Server 2
  B	Server 2	Server 1
  C	Server 1	Server 2

【クラスタ状態遷移図】

代表的なクラスタ状態遷移について説明します。

図 3.57 クラスタ状態遷移の例（概要）

図中の 1. ～ 13. は、以下の説明に対応しています。

1. 通常立ち上げ

   ここでいう通常立ち上げとは、開始スクリプトがプライマリサーバで正常に実行された時を 指します。

   各グループは、起動したサーバの中で、最もプライオリティの高いサーバ上で起動されます。

   

   図 3.58 状態とスクリプト実行（通常立ち上げ）

   start.bat に対する環境変数

   	Group A	Group B	Group C
   CLP_EVENT	START	START	START
   CLP_SERVER	HOME	HOME	HOME

2. 通常シャットダウン

   ここでいう通常シャットダウンとは、終了スクリプトに対応する開始スクリプトが、通常立ち上げにより実行された、もしくはグループの移動 (オンラインフェイルバック) により実行された直後の、クラスタシャットダウンを指します。

   

   図 3.59 状態とスクリプト実行（通常シャットダウン）

   stop.bat に対する環境変数

   	Group A	Group B	Group C
   CLP_EVENT	START	START	START
   CLP_SERVER	HOME	HOME	HOME

3. Server 1 ダウンによるフェイルオーバ

   Server 1 をプライマリサーバとするグループの開始スクリプトが、障害発生により下位の プライオリティサーバ (Server 2) で実行されます。開始スクリプトには、CLP_EVENT (=FAILOVER) を分岐条件にして、業務の起動、復旧処理 (たとえばデータベースのロールバック処理など) を記述しておく必要があります。

   プライマリサーバ以外でのみ実行したい処理がある場合は、CLP_SERVER (=OTHER) を分岐条件にして記述しておく必要があります。

   

   図 3.60 状態とスクリプト実行（サーバダウンによるフェイルオーバ）

   start.bat に対する環境変数

   	Group A	Group C
   CLP_EVENT	FAILOVER	FAILOVER
   CLP_SERVER	OTHER	OTHER

4. Server 1 のクラスタ復帰

   ダウン後再起動状態 (非クラスタとして動作中) のServer 1 をクラスタに復帰させる場合、Server 1 でフェイルオーバ発生時に動作していたフェイルオーバグループの、開始スクリプトが実行されます (フェイルオーバが発生したサーバでリカバリ処理が実行されます)。

   リカバリ処理 (たとえば、ローカルディスクにあるデータベース情報などの修復) を行うために、CLP_EVENT (=RECOVER) を分岐条件にして、処理を記述しておく必要があります(特にリカバリ処理が必要無い場合でも、業務の起動処理を実行しないように、スクリプトを記述してください)。

   データミラーリングの運用の場合、クラスタ復帰にて、データの復旧 (ミラーセットの再構築)を行います。

   

   図 3.61 状態とスクリプト実行（サーバのクラスタ復帰）

   start.bat に対する環境変数

   	Group A	Group C
   CLP_EVENT	RECOVER	RECOVER
   CLP_SERVER	HOME	HOME

5. Server 1 フェイルオーバ後クラスタシャットダウン

   Group A と C の終了スクリプトが、フェイルオーバ先のServer 2 で実行されます

   (Group B の終了スクリプトは、通常シャットダウンでの実行です)。
   

   図 3.62 状態とスクリプト実行（フェイルオーバ後、クラスタシャットダウン）

   stop.bat に対する環境変数

   	Group A	Group B	Group C
   CLP_EVENT	FAILOVER	START	FAILOVER
   CLP_SERVER	OTHER	HOME	OTHER

6. Group A と C の移動

   Group A と C の終了スクリプトが、フェイルオーバ先のServer 2 で実行された後、Server 1 で開始スクリプトが実行されます。

   

   図 3.63 状態とスクリプト実行（Group A、Group Cの移動）(1)

   

   図 3.64 状態とスクリプト実行（Group A、Group Cの移動）(2)

   stop.bat に対する環境変数

   	Group A	Group C
   CLP_EVENT	FAILOVER 4	FAILOVER
   CLP_SERVER	OTHER	OTHER

   4

   終了スクリプトの環境変数の値は、直前に実行された開始のスクリプトの環境変数の値となる。「 6. Group AとCの移動」の遷移の場合、直前にクラスタシャットダウンがないのでFAILOVERとなりますが、「 6. AとCの移動」の前にクラスタシャットダウンが行われているとSTARTとなります。

   start.bat に対する環境変数

   	Group A	Group C
   CLP_EVENT	START	START
   CLP_SERVER	HOME	HOME

7. Server 1 の起動 (自動復帰モード)

   Server 1 の自動復帰を実行します。Server 1 でフェイルオーバ発生時に動作していた フェイルオーバグループの、開始スクリプトが実行されます (フェイルオーバが発生したサーバでリカバリ処理が実行されます)。「 4. Server 1 のクラスタ復帰 」と同様の注意が必要です。

   データミラーリング運用の場合、クラスタ復帰にて、データの復旧 (ミラーセットの再構築) を行います。

   

   図 3.65 状態とスクリプト実行（サーバの起動, 自動復帰モード）

   start.bat に対する環境変数

   	Group A	Group C
   CLP_EVENT	RECOVER	RECOVER
   CLP_SERVER	HOME	HOME

8. Group C の障害、フェイルオーバ

   Group C に障害が発生すると、Server 1 でGroup C の終了スクリプトが実行され、Server 2 でGroup C の開始スクリプトが実行されます。

   

   図 3.66 状態とスクリプト実行（Group Cの障害、フェイルオーバ）(1)

   

   図 3.67 状態とスクリプト実行（Group Cの障害、フェイルオーバ）(2)

   Server 1 の stop.bat に対する環境変数

   	Group C
   CLP_EVENT	START
   CLP_SERVER	HOME

   Server 1 の start.bat に対する環境変数

   	Group C
   CLP_EVENT	RECOVER

   Server 2 の start.bat に対する環境変数

   	Group C
   CLP_EVENT	FAILOVER
   CLP_SERVER	OTHER

9. Group C の移動

   8. でServer 2 にフェイルオーバしてきたGroup C を、Server 2 よりServer 1 へ移動します。Server 2 で終了スクリプトを実行した後、Server 1 で開始スクリプトを実行します。

   

   図 3.68 状態とスクリプト実行（Group Cの移動）(1)

   

   図 3.69 状態とスクリプト実行（Group Cの移動）(2)

   stop.bat に対する環境変数 ( 8. よりフェイルオーバしてきたため)

   	Group C
   CLP_EVENT	FAILOVER
   CLP_SERVER	OTHER

   start.bat に対する環境変数

   	Group C
   CLP_EVENT	START
   CLP_SERVER	HOME

10. Group B の停止

    Group B の終了スクリプトがServer 2 で実行されます。

    

    図 3.70 状態とスクリプト実行（Group Bの停止）

    stop.bat に対する環境変数

    	Group B
    CLP_EVENT	START
    CLP_SERVER	HOME

11. Group B の起動

    Group B の開始スクリプトがServer 2 で実行されます。

    

    図 3.71 状態とスクリプト実行（Group Bの起動）

    start.bat に対する環境変数

    	Group B
    CLP_EVENT	START
    CLP_SERVER	HOME

12. Group C の停止

    Group C の終了スクリプトがServer 2 で実行されます。

    

    図 3.72 状態とスクリプト実行（Group Cの停止）

    stop.bat に対する環境変数

    	Group C
    CLP_EVENT	FAILOVER
    CLP_SERVER	OTHER

13. Group C の起動

    Group C の開始スクリプトがServer 2 で実行されます。

    

    図 3.73 状態とスクリプト実行（Group Cの起動）

    start.bat に対する環境変数

    	Group C
    CLP_EVENT	START
    CLP_SERVER	OTHER

【補足1】

フェイルオーバポリシーに設定されているサーバを 3 つ以上持つグループにおいて、プライマリサーバ以外のサーバで、異なった動作を行う場合 CLP_SERVER (HOME/OTHER)の代わりに、CLP_PRIORITY を使用する

図 3.74 クラスタ状態遷移の例（サーバダウンによるフェイルオーバ）

(例1) クラスタ状態遷移図 「 3. Server 1 ダウンによるフェイルオーバ」の場合

Server 1 をプライマリサーバとするグループの開始スクリプトが、障害発生により次に高いフェイルオーバポリシーを持つServer 2 で実行されます。開始スクリプトには、CLP_EVENT (=FAILOVER) を分岐条件にして、業務の起動、復旧処理 (たとえばデータベースのロールバック処理など) を記述しておく必要があります。

2 番目に高いフェイルオーバポリシーを持つサーバのみで実行したい処理がある場合は、CLP_PRIORITY (=2) を分岐条件にして記述しておく必要があります。

図 3.75 状態とスクリプト実行（Group A、Group Cの起動）

start.bat に対する環境変数

	Group A	Group C
CLP_EVENT	FAILOVER	FAILOVER
CLP_SERVER	OTHER	OTHER
CLP_PRIORITY	2	2

(例2) クラスタ状態遷移図「 6. Group A と C の移動」の場合

図 3.76 クラスタ状態遷移の例（Group Cの移動）

Group C の終了スクリプトが、フェイルオーバ元のServer 2 で実行された後、Server 3で開始スクリプトが実行されます。

図 3.77 状態とスクリプト実行（Group Cの移動）(1)

図 3.78 状態とスクリプト実行（Group Cの移動）(2)

stop.bat に対する環境変数

	Group C
CLP_EVENT	FAILOVER
CLP_SERVER	OTHER
CLP_PRIORITY	2

start.bat に対する環境変数

	Group C
CLP_EVENT	START
CLP_SERVER	OTHER
CLP_PRIORITY	3

【補足2】

モニタリソースがスクリプトを (再) 起動する場合

モニタリソースの異常検出によって開始スクリプトを (再) 起動する場合の環境変数は以下のようになります。

(例1) モニタリソースの異常検出のためServer 1 でGroup A の再起動を行う場合

図 3.79 状態とスクリプト実行（Group Aの再起動）(1)

図 3.80 状態とスクリプト実行（Group Aの再起動）(2)

stop.bat に対する環境変数

	Group A
CLP_EVENT	Start 実行時と同一の値

start.bat に対する環境変数

		Group A
	CLP_EVENT	RECOVER
	CLP_EVENT	Start

※start.bat は 2 回実行されます。

(例2) モニタリソースがServer 1 で異常を検出してServer 2 へフェイルオーバをして、Server 2 でGroup A の起動を行う場合

図 3.81 状態とスクリプト実行（Group Aのフェイルオーバ）(1)

図 3.82 状態とスクリプト実行（Group Aのフェイルオーバ）(2)

図 3.83 状態とスクリプト実行（Group Aのフェイルオーバ）(3)

stop.bat に対する環境変数

	Group A
CLP_EVENT	Start 実行時と同一の値

start.bat に対する環境変数

		Group A
	CLP_EVENT	RECOVER
	CLP_EVENT	FAILOVER

【補足3】

[スクリプトリソース調整プロパティ] の [待機系サーバで実行する] を有効に設定すると、 グループを起動したサーバ (=現用系サーバ) で開始スクリプトや終了スクリプトが実行されるタイミングに合わせて、 グループを起動していない他のサーバ (=待機系サーバ) でもスクリプトを実行することができます。

現用系サーバでのスクリプト実行と比較すると、待機系サーバでのスクリプト実行には以下の特徴があります。

• スクリプトの実行結果 (エラーコード) がグループリソースのステータスに影響しません。

• 活性前後スクリプトや非活性前後スクリプトを実行しません。

• 活性時監視に設定されているモニタリソースの起動・停止を行いません。

• セットされる環境変数の種類・値が異なります (前項「 スクリプトリソースのスクリプトで使用する環境変数 」を参照してください)。

待機系サーバでスクリプトが実行されるタイミングと環境変数の関連について、クラスタ状態遷移図にあわせて説明します。

【クラスタ状態遷移図】

図 3.84 クラスタ状態遷移の例（サーバダウンによるフェイルオーバ）

図中の 1. ～ 5. は、以下の説明に対応しています。

1. 通常立ち上げ

   グループを起動するとき、現用系サーバでの開始スクリプト実行に合わせて、待機系サーバでも開始スクリプトが実行されます。

   待機系サーバの開始スクリプトは、現用系サーバの開始スクリプトが実行された「後」で実行されます。

   開始スクリプトには、CLP_EVENT (=STANDBY) を分岐条件にして、待機系サーバ上で実行したい処理を記述しておく必要があります。

   

   図 3.85 状態とスクリプト実行（Group Aの通常起動）(1)

   

   図 3.86 状態とスクリプト実行（Group Aの通常起動）(2)

   start.bat に対する環境変数

   	Server 1	Server 2
   CLP_EVENT	START	STANDBY
   CLP_SERVER	HOME	OTHER

2. 通常シャットダウン

   グループを停止するとき、現用系サーバでの終了スクリプト実行に合わせて、待機系サーバでも終了スクリプトが実行されます。

   待機系サーバの終了スクリプトは、現用系サーバの終了スクリプトが実行される「前」に実行されます。

   終了スクリプトには、CLP_EVENT (=STANDBY) を分岐条件にして、待機系サーバ上で実行したい処理を記述しておく必要があります。

   

   図 3.87 状態とスクリプト実行（Group Aの通常シャットダウン）(1)

   

   図 3.88 状態とスクリプト実行（Group Aの通常シャットダウン）(2)

   stop.bat に対する環境変数

   	Server 1	Server 2
   CLP_EVENT	START	STANDBY
   CLP_SERVER	HOME	OTHER

3. Server 1 ダウンによるフェイルオーバ

   Server 1 の障害発生により、グループがServer 2 にフェイルオーバされ、Server 2 で (現用系サーバとして) 開始スクリプトが実行されます。

   開始スクリプトには、CLP_EVENT (=FAILOVER) を分岐条件にして、業務の起動、復旧処理 (たとえばデータベースのロールバック処理など) を記述しておく必要があります。

   Server 1 がダウン状態であるため、待機系サーバとしての開始スクリプトは実行されません。

   

   図 3.89 クラスタ状態遷移の例（サーバダウンによるフェイルオーバ）

   start.bat に対する環境変数

   	Server 2
   CLP_EVENT	FAILOVER
   CLP_SERVER	OTHER

4. サーバ1のクラスタ復帰

   ダウン後再起動状態 (非クラスタとして動作中) のServer 1 をクラスタに復帰させる場合、Server 1 でフェイルオーバ発生時に動作していたフェイルオーバグループの、開始スクリプトが実行されます (フェイルオーバが発生したサーバでリカバリ処理が実行されます)。

   リカバリ処理 (たとえば、ローカルディスクにあるデータベース情報などの修復) を行うために、CLP_EVENT (=RECOVER) を分岐条件にして、処理を記述しておく必要があります(特にリカバリ処理が必要無い場合でも、業務の起動処理を実行しないように、スクリプトを記述してください)。

   このとき、Server 1 で開始スクリプトが実行されますが、Server 2 では開始スクリプトは実行されません。

   

   図 3.90 状態とスクリプト実行（サーバのクラスタ復帰）

   start.bat に対する環境変数

   	Server 1
   CLP_EVENT	RECOVER
   CLP_SERVER	HOME

5. Group Aの移動

   Group Aの終了スクリプトがServer 1 (= 待機系サーバ) とServer 2 (= 現用系サーバ) で実行された後、 開始スクリプトがServer 1 (= 現用系サーバ) とServer 2 (= 待機系サーバ) で実行されます。

   

   図 3.91 状態とスクリプト実行（Group Aの移動）(1)

   

   図 3.92 状態とスクリプト実行（Group Aの移動）(2)

   

   図 3.93 状態とスクリプト実行（Group Aの移動）(3)

   

   図 3.94 状態とスクリプト実行（Group Aの移動）(4)

   stop.bat に対する環境変数

   	Server 1	Server 2
   CLP_EVENT	STANDBY	FAILOVER 5
   CLP_SERVER	HOME	OTHER

   5

   終了スクリプトの環境変数の値は、直前に実行された開始スクリプトの環境変数の値となります。「5. Group Aの移動」の遷移の場合、直前にクラスタシャットダウンがないのでFAILOVERとなりますが、「5. Group Aの移動」の前にクラスタシャットダウンが行われているとSTARTとなります。

   start.bat に対する環境変数

   	Server 1	Server 2
   CLP_EVENT	START	STANDBY
   CLP_SERVER	HOME	OTHER

3.10.5. スクリプトの記述の流れ

前のトピックの、スクリプトの実行タイミングと実際のスクリプト記述を関連付けて説明します。文中の (数字) は「 スクリプトリソース スクリプトの実行タイミング 」の各動作をさします。

Group A 開始スクリプト： start.bat の一例

rem **************************************************************
rem *                          START.BAT                         *
rem **************************************************************

rem スクリプト実行要因の環境変数を参照して処理の振り分けを行う。
IF "%CLP_EVENT%"=="START" GOTO NORMAL
IF "%CLP_EVENT%"=="FAILOVER" GOTO FAILOVER
IF "%CLP_EVENT%"=="RECOVER" GOTO RECOVER


rem CLUSTERPROは動作していない
GOTO no_clp


:NORMAL
IF "%CLP_DISK%"=="FAILURE" GOTO ERROR_DISK

    rem ここに、業務の通常起動処理を記述する。
    rem この処理は以下のタイミングで実行される。
    rem
    rem (1) 通常立ち上げ
    rem (6) フェイルオーバグループの移動（オンラインフェイルバック）
    rem


rem 実行サーバ環境変数を参照して、処理の振り分けを行う。
IF "%CLP_SERVER%"=="OTHER" GOTO ON_OTHER1

    rem プライマリサーバで、業務が通常起動される場合のみ
    rem 行いたい処理を記述する。
    rem この処理は以下のタイミングで実行される。
    rem
    rem (1) 通常立ち上げ
    rem (6) フェイルオーバグループの移動（オンラインフェイルバック）
    rem

GOTO EXIT


:ON_OTHER1

rem プライマリサーバ以外で、業務が通常起動される場合のみ
rem 行いたい処理を記述する。

GOTO EXIT


:FAILOVER

rem DISK接続情報環境変数を参照して、エラー処理を行う。
IF "%CLP_DISK%"=="FAILURE" GOTO ERROR_DISK

    rem フェイルオーバ先のサーバでの業務の起動処理を記述する。
    rem この処理は以下のタイミングで実行される。
    rem
    rem (3) Server 1ダウンによるフェイルオーバ
    rem


rem 実行サーバ環境変数を参照して、処理の振り分けを行う。
IF "%CLP_SERVER%"=="OTHER" GOTO ON_OTHER2

    rem フェイルオーバ後、プライマリサーバで業務が起動される場合のみ
    rem 行いたい処理を記述する。

GOTO EXIT


:ON_OTHER2

rem フェイルオーバ後、非プライマリサーバで業務が起動される場合のみ
rem 行いたい処理を記述する。
rem この処理は以下のタイミングで実行される。
rem
rem (3) Server 1ダウンによるフェイルオーバ
rem

GOTO EXIT


:RECOVER

rem クラスタ復帰後のリカバリ処理を記述する。
rem この処理は以下のタイミングで実行される。
rem
rem (4) クラスタ復帰
rem

GOTO EXIT


:ERROR_DISK

rem ディスク関連のエラー処理を記述する。

:no_clp

:EXIT
exit

Group A 終了スクリプト： stop.bat の一例

rem **************************************************************
rem *                          STOP.BAT                          *
rem **************************************************************

rem スクリプト実行要因の環境変数を参照して処理の振り分けを行う。
IF "%CLP_EVENT%"=="START" GOTO NORMAL
IF "%CLP_EVENT%"=="FAILOVER" GOTO FAILOVER


rem CLUSTERPROは動作していない
GOTO NO_CLP



:NORMAL
rem DISK接続情報環境変数を参照して、エラー処理を行う。
IF "%CLP_DISK%"=="FAILURE" GOTO ERROR_DISK

    rem ここに、業務の通常終了処理を記述する。
    rem この処理は以下のタイミングで実行される。
    rem
    rem (2) 通常シャットダウン
    rem


rem 実行サーバ環境変数を参照して、処理の振り分けを行う。
IF "%CLP_SERVER%"=="OTHER" GOTO ON_OTHER1

    rem プライマリサーバで、業務が通常処理される場合のみ
    rem 行いたい処理を記述する。
    rem この処理は以下のタイミングで実行される。
    rem
    rem (2) 通常シャットダウン
    rem

GOTO EXIT


:ON_OTHER1

rem プライマリサーバ以外で、業務が通常終了される場合のみ
rem 行いたい処理を記述する。

GOTO EXIT


:FAILOVER

rem DISK接続情報環境変数を参照して、エラー処理を行う。
IF "%CLP_DISK%"=="FAILURE" GOTO ERROR_DISK

    rem フェイルオーバ後の通常終了処理を記述する。
    rem この処理は以下のタイミングで実行される。
    rem
    rem (5) Server 1フェイルオーバ後、クラスタシャットダウン
    rem (6) フェイルオーバグループ ACの移動
    rem


rem 実行サーバ環境変数を参照して、処理の振り分けを行う。
IF "%CLP_SERVER%"=="OTHER" GOTO ON_OTHER2

    rem フェイルオーバ後、プライマリサーバで業務が終了
    rem される場合のみ行いたい処理を記述する。

GOTO EXIT


:ON_OTHER2

rem フェイルオーバ後、非プライマリサーバで業務が終了
rem される場合のみ行いたい処理を記述する。
rem この処理は以下のタイミングで実行される。
rem
rem (5) Server 1フェイルオーバ後、クラスタシャットダウン
rem (6) フェイルオーバグループ ACの移動
rem

GOTO EXIT


:ERROR_DISK

rem ディスク関連のエラー処理を記述する。

:NO_CLP

:EXIT
exit

3.10.6. スクリプト作成のヒント

アラートログに、メッセージを出力できる [clplogcmd] コマンドがありますのでご活用ください。

3.10.7. スクリプトリソースに関する注意事項

開始/終了スクリプト内で start コマンドを利用している場合には、start コマンド経由で起動するスクリプト側で exit コマンドを使用して処理を終了するようにしてください。

3.10.8. 詳細タブ

追加

スクリプトの追加ダイアログが表示されます。[start.bat]、[stop.bat] 以外のスクリプトを追加します。

注釈

追加するスクリプトのファイル名に 2 バイト文字は使用しないでください。

追加するスクリプトのファイル名に「&(アンパサンド)」、「=(等号)」は使用しないでください。

削除

スクリプトを削除します。[start.bat]、[stop.bat] は削除できません。

表示

選択したスクリプトファイルを表示します。

編集

選択したスクリプトファイルを編集できます。変更を反映するには [保存] をクリックしてください。スクリプトファイル名の変更はできません。

置換

ファイル選択ダイアログボックスが表示されます。

注釈

Cluster WebUI から [削除] を実行しスクリプトファイルを削除しても、実ファイルは削除されません。またスクリプトファイルの削除後、Cluster WebUI を再起動するなどして構成情報を読込みなおした場合、削除したスクリプトファイルが [スクリプト一覧] に表示されます。

[リソースのプロパティ] で選択したスクリプトファイルの内容が、ファイル選択ダイアログ ボックスで選択したスクリプトファイルの内容に置換されます。スクリプトが表示中または編集中の場合は置換できません。ここではスクリプトファイルを選択してください。バイナリファイル (アプリケーションなど) は選択しないでください。

調整

[スクリプトリソース調整プロパティ] ダイアログを表示します。スクリプトリソースの詳細設定を行います。

スクリプトリソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

[開始スクリプト]、[終了スクリプト] 全スクリプト共通

同期

スクリプトの実行時にスクリプトの終了を待ちます。

非同期

選択できません。

正常な戻り値 (1023 バイト以内)

スクリプトのエラーコードがどのような値の場合に正常と判断するかを設定します。

• 値がない場合

  戻り値は無視します。
• 値がある場合

  以下の入力規則に従ってください。

  • 0,2,3 のようにカンマで区切る

  • 0-3 のようにハイフンで指定

注釈

スクリプトを実行する cmd.exe で異常が発生した場合、「1」が返却されますので、正常な戻り値として「1」を設定すると異常が検出できなくなります。

待機系サーバで実行する

スクリプトを待機系サーバで実行するか否かを設定します。本パラメータを有効にした場合、待機系サーバで実行する際のタイムアウト (1～9999) が設定可能となります。

リカバリ処理を実行する

以下のタイミングで開始スクリプトを実行するか否かを設定します。

• サーバの復帰時

• モニタリソースの異常検出時

• グループリソース活性処理の異常終了時

詳細は本ガイドの「 スクリプトリソース スクリプトの実行タイミング 」にて確認してください。リカバリ処理として実行される場合は環境変数CLP_EVENTにRECOVERが設定されます。

タイムアウト (1～9999)

スクリプトの実行時に終了を待つ場合 ([同期]) のタイムアウトを設定します。[同期] を選択している場合のみ入力可能です。設定時間内にスクリプトが終了しないと、異常と判断します。

対象 VCOM リソース名

スクリプトリソースが使用するコンピュータ名に仮想コンピュータ名を渡す場合に設定します。選択肢にはスクリプトリソースが所属するフェイルオーバグループ内に存在する仮想コンピュータ名リソース名が表示されます。

本パラメータを設定した場合、下記の環境変数を追加してスクリプトを起動します。

COMPUTERNAME=<仮想コンピュータ名>

_CLUSTER_NETWORK_FQDN_=<仮想コンピュータ名>

_CLUSTER_NETWORK_HOSTNAME_=<仮想コンピュータ名>

_CLUSTER_NETWORK_NAME_=<仮想コンピュータ名>

注釈

対象VCOMリソース名を指定した場合、スクリプト内でCLUSTERPROコマンドを使用できません。

デスクトップとの対話を許可する

実行するスクリプトにデスクトップとの対話を許可するかどうかを設定します。設定すると、スクリプトの進行状況を画面にて確認することができますスクリプトをデバッグする際に使用すると効果があります。

実行ユーザ

スクリプトを実行するユーザを指定します。実行ユーザは [クラスタのプロパティ] の [アカウント] タブに登録されたユーザの中から選択可能です。

実行ユーザを指定しなかった場合、スクリプトはローカルシステムアカウントとして実行されます。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

3.11. ディスクリソースを理解する

3.11.1. ディスクリソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.11.2. ディスクリソースとは?

ディスクリソースとは、クラスタを構成する複数のサーバからアクセスする共有ディスクの切替パーティションのことです。

• 切替パーティション

  切替パーティションとは、クラスタを構成する複数台のサーバに接続された共有ディスク上のパーティションのことを指します。

  切替はフェイルオーバグループごとに、フェイルオーバポリシーにしたがって行われます。業務に必要なデータは、切替パーティション上に格納しておくことで、フェイルオーバ時、フェイルオーバグループの移動時などに自動的に引き継がれます。

  切替パーティションは全サーバで、同一領域に同じドライブ文字でアクセスできるようにしてください。
  

  図 3.95 ディスクリソース (1)

  

  図 3.96 ディスクリソース (2)

• 切替パーティションのサイズ

  パーティションのサイズに制約はありません。任意のサイズで確保してください。
• ファイルシステム

  パーティションは NTFS でフォーマットしてください。FAT/FAT32 はサポートしていません。
• アクセス制御

  ファイルシステムのアクセス制御は、CLUSTERPRO が行います。
• HBA (Host Bus Adapter) の設定

  複数のサーバを共有ディスクに接続する場合、ファイルシステムへの同時アクセスを行うとデータが破壊される可能性があります。そのため、共有ディスク上のパーティションにアクセスする際は、アクセス制限を考慮する必要があります。

  CLUSTERPRO ではHBA (Host Bus Adapter) の設定により、共有ディスクの アクセス制限を行います。共有ディスクを接続する HBA に対し、アクセス制限の設定を行ってください。

  詳細については本ガイドの「2. パラメータの詳細」 - 「サーバプロパティ」 - 「HBA タブ」を参照してください。
• DISK ネットワークパーティション解決リソースの設定

  ディスクリソースを使用する場合、DISK ネットワークパーティション解決リソースの使用を推奨します。

  DISK ネットワークパーティション解決リソースについては「 DISK 方式によるネットワークパーティション解決を理解する 」を参照してください。

3.11.3. ディスクリソースに関する注意事項

• 全サーバで同一パーティションに対して、同一のドライブ文字を割り当ててください。OSが自動で割り当てたドライブ文字が割り当てようとしていたドライブ文字と同一であっても、一度削除して設定しなおすなど、手動で明示的に割り当ててください。

• 現在パーティションに設定されているドライブ文字と異なるドライブ文字を設定した 場合、ディスクリソースの起動時にドライブ文字が変更されます。ドライブ文字が他のパーティションで使用されている場合、ディスクリソースの起動に失敗します。

• ダイナミックディスクはサポートしていません。ダイナミックディスク上のパーティションをディスクリソースに使用した場合、ディスクリソースの起動に失敗します。

• ディスクリソースに使用するパーティションに対し HBA の設定を行ってください。HBA の設定を行っていないパーティションをディスクリソースに使用すると、リソースの起動に失敗します。

  また HBA の設定を変更した場合、変更内容を反映するために OS の再起動が必要になります。HBA の設定を変更後、OS を再起動していない場合、ディスク リソースの起動に失敗します。

  HBA の設定の詳細については本ガイドの「2. パラメータの詳細」 - 「サーバプロパティ」 - 「HBA タブ」を参照してください。

  HBAの設定後にドライブ文字の変更/削除を行うと操作が失敗することがあります。回避策の手順に従って、設定を行ってください。

• <回避策>

1. コマンドプロンプトから以下のコマンドを実行してドライブ文字を削除してください。

   # mountvol (変更対象の)ドライブ文字: /P

2. ディスクの管理([コントロールパネル] > [管理ツール] > [コンピュータの管理] > [ディスクの管理])を使用して変更対象ドライブからドライブ文字が削除されていることを確認。

3. [ディスクの管理]からドライブ文字を追加する。

3.11.4. 詳細タブ

ドライブ文字 (1023 バイト以内)

使用するディスクのドライブ文字 (A～Z) を設定します。

追加

[起動可能サーバ] に選択したサーバを追加します。追加したサーバのパーティション 一覧が [パーティションの選択] ダイアログボックスに表示されます。

削除

[起動可能サーバ] から選択したサーバを削除します。

編集

選択したサーバの [パーティションの選択] ダイアログボックスが表示されます。

• パーティションの選択

  一覧から切替パーティションとして使用するパーティションを選択します。選択した切替パーティションの GUID が表示されます。GUID はパーティションを一意に 識別する識別子です。
• 接続

  サーバに接続して、パーティションの一覧を取得します。

重要

ディスクリソースで指定するパーティションには、フィルタリング設定された HBAに接続された共有ディスク上のパーティションを指定してください。

また、ディスクリソースで指定したパーティションは、ディスクハートビート用パーティションやミラーディスクリソースのクラスタパーティション、データパーティションには指定しないでください。共有ディスク上のデータが破壊される可能性があります。

3.12. サービスリソースを理解する

CLUSTERPRO では、CLUSTERPRO によって管理され、グループの起動時、終了時、フェイルオーバ発生時および移動時に実行されるサービスを登録できます。サービスリソースには、ユーザ独自のサービスも登録できます。

3.12.1. サービスリソースの依存関係

既定値では、以下のグループリソースタイプに依存します。

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
仮想コンピューター名リソース
ディスクリソース
ミラーディスクリソース
ハイブリッドディスクリソース
レジストリ同期リソース
CIFSリソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
AWS DNS リソース
Azure プローブポートリソース
Azure DNS リソース

3.12.2. サービスリソースとは?

サービスとは、OS のサービス制御マネージャによって管理されるサービスを指します。

3.12.3. サービスリソースに関する注意事項

• サービスリソースで実行されるサービスは、フェイルオーバポリシーに設定されている全サーバに存在していることが必須です。

• 通常、サービスリソースで実行されるサービスは手動起動に設定します。自動起動で起動するサービスや、サービスリソース以外によって起動される可能性があるサービスの場合は、後述する [サービスリソース調整プロパティ] ダイアログの [サービス] タブの [サービスが起動済みの場合、エラーとしない] チェックボックスをオンにする必要があります。このチェックボックスがオフの場合、既に起動されているサービスに対してサービスリソースでサービス開始処理が実行されると、活性失敗となります。

• [サービスリソース調整プロパティ] ダイアログの [サービス] タブの [サービスが起動済みの場合、エラーとしない] チェックボックスがオンの状態で、サービスリソース活性時に対象サービスが起動済であった場合、サービスリソースの非活性時に対象サービスの停止を行いません。

• サービスリソースで実行されるサービスは CLUSTERPRO 以外から制御させないため、サービス制御マネージャによる回復動作は設定しないことを推奨します。

  サービス制御マネージャによる回復動作でサービスの再起動を設定している場合、CLUSTERPRO による回復動作と重複して予期せぬ挙動となる可能性があります。

3.12.4. 詳細タブ

サービス名 (1023 バイト以内)

サービスリソースで使用するサービス名または、サービス表示名を設定します。

コンボボックスの選択肢はすべてのサーバから取得したサービスのサービス表示名一覧が表示されます。

接続

すべてのサーバからサービス一覧を取得し、[サービス名] コンボボックスに表示するサービス表示名一覧を更新します。

調整

[サービスリソース調整プロパティ] ダイアログを表示します。サービスリソースの詳細設定を行います。

サービスリソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

同期

サービス開始時は、サービスの状態が「起動済」状態になるまで待ち合せを行います。通常、サービスを開始すると、「起動中」→「起動済」のように状態が遷移します。

サービス停止時は、サービスの状態が「停止」状態になるまで待ち合せを行います。通常、サービスを停止すると、「停止中」→「停止」のように状態が遷移します。

非同期

待ち合せを行いません。

タイムアウト (1～9999)

サービス開始時は、サービスの状態が「起動」状態になるまでのタイムアウトを設定します。[同期] を選択している場合のみ入力可能です。設定時間内にサービスが「起動」状態にならない場合は、異常と判断します。

サービス停止時は、サービスの状態が「停止」状態になるまでのタイムアウトを設定します。[同期] を選択している場合のみ入力可能です。設定時間内にサービスが「停止」状態にならない場合は、異常と判断します。

対象 VCOM リソース名

サービスリソースが使用するコンピュータ名に仮想コンピュータ名を渡す場合に設定します。選択肢にはサービスリソースが所属するフェイルオーバグループ内に存在する仮想コンピュータ名リソース名が表示されます。

本パラメータを設定した場合、下記のレジストリを追加してサービスを起動します。

キー名

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<サービスリソースで設定したサービス>

値

名前 : Environment

種類 : REG_MULTI_SZ

データ : COMPUTERNAME=<仮想コンピュータ名>

_CLUSTER_NETWORK_FQDN_=<仮想コンピュータ名>

_CLUSTER_NETWORK_HOSTNAME_=<仮想コンピュータ名>

_CLUSTER_NETWORK_NAME_=<仮想コンピュータ名>

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

サービスタブ

サービスに関する詳細設定が表示されます。

開始パラメータ (1023 バイト以内)

サービスに対する入力パラメータを設定します。入力パラメータが複数ある場合は、スペース区切りで設定します。スペースを含む入力パラメータがある場合は、入力パラメータをダブルクオート(")で括ります。エスケープシークエンス \ を使用することはできません。

例: "param 1" param2

サービスが起動済みの場合、エラーとしない

• チェックボックスがオン

  サービス開始時に、すでにサービスが開始済みの場合、そのまま活性状態にします。
• チェックボックスがオフ

  サービス開始時に、すでにサービスが開始済みの場合、活性異常とします。

サービス開始後の待ち合わせ (0～9999)

サービスが起動状態になった後、待ち合わせる時間を指定します。指定された時間分、待ち合わせた後、サービスリソースの活性が完了した状態となります。

サービス停止後の待ち合わせ(0～9999)

サービスが停止状態になった後、待ち合わせる時間を指定します。指定された時間分、待ち合わせた後、サービスリソースの非活性が完了した状態となります。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

注釈

[サービスが起動済みの場合、エラーとしない] に設定した場合、複数グループに同じサービス名を持つサービスリソースを登録できます。この際、[対象 VCOM リソース名] は設定しないで下さい。

[対象 VCOM リソース名] を設定した場合、1 つのサーバで複数のグループが起動する際に、サービスリソースが活性異常となります。

ただし、複数グループに同じサービス名を持つサービスリソースを登録した場合、次のような操作を行うと、サービス監視リソースが異常を検出し、フェイルオーバなどが発生する場合があります。

• 同じサービスを制御するサービスリソースを登録したフェイルオーバグループが同一サーバ上で複数活性している状態で、最初にサービスを起動したフェイルオーバグループを停止もしくは別のサーバに移動する。

3.13. 仮想コンピュータ名リソースを理解する

3.13.1. 仮想コンピュータ名リソースの依存関係

既定値では、以下のグループリソースタイプに依存します。

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
Azure プローブポートリソース

3.13.2. 仮想コンピュータ名リソースとは?

クライアントアプリケーションは、仮想コンピュータ名を使用してクラスタサーバに接続する ことができます。また、サーバ間でも仮想コンピュータ名を使用しての接続が可能です。仮想コンピュータ名を使用することにより、フェイルオーバ/フェイルオーバグループの移動が発生しても、クライアントは、接続先サーバの切り替えを意識する必要がありません。

また、Windows マシンクライアントのみが、仮想コンピュータ名によるクラスタサーバへの 接続が可能です。

図 3.97 仮想コンピュータ名リソース (1)

図 3.98 仮想コンピュータ名リソース (2)

3.13.3. 仮想コンピュータ名の検討

仮想コンピュータ名に割り当てるコンピュータ名は以下の条件を満たす必要があります。

• クラスタサーバ名とは異なる名前である

• 同一ネットワークセグメント上に接続されたマシンのコンピュータ名とは異なる名前 である

• 15 文字以内である

• 英小文字、数字およびハイフンのみ可能

3.13.4. 仮想コンピュータ名とフローティング IP との関連付け

仮想コンピュータ名と FIP アドレスが関連付けられると、クライアントの LMHOSTS ファイルに、仮想コンピュータ名と FIP アドレスの組を記述することができます。これにより、リモート LAN から仮想コンピュータ名を使用することができます。関連付けは Cluster WebUI の設定モードから、仮想コンピュータリソースのプロパティ→[詳細] タブ→[対象 FIP リソース名] で設定します。

仮想コンピュータ名と FIP アドレスが関連付けられていないと、LMHOSTS ファイルを使用する方法では、リモート LAN から仮想コンピュータを使用することができません。この場合、リモート LAN から仮想コンピュータ名を使用するためには、仮想コンピュータ名を DNS に動的登録する、もしくは WINS を設定する必要があります。WINS の設定については、 次項の「 WINS サーバの設定方法 」を参照してください。

3.13.5. WINS サーバの設定方法

仮想コンピュータ名と FIP アドレスで関連付けを行わず、リモート LAN から仮想コンピュータ名を使用する場合は、以下の WINS サーバの設定を行ってください。

• クラスタサーバ上に WINS サーバを設置する場合

  1. 全クラスタサーバへ WINS サーバをインストールしてください (セットアップ後にサーバ再起動を促すダイアログは [いいえ] を選択してください)。

  2. [コントロールパネル]－[ネットワーク接続] から、パブリック LAN を示すローカルエリア接続の [プロパティ] を開きます。

  3. [インターネットプロトコル (TCP/IP)] を選択し、[プロパティ] をクリックします。

  4. [詳細設定] をクリックして、[WINS] タブを選択します。

  5. WINS アドレスに、全クラスタサーバの、パブリック LAN の IP アドレスを設定してください (使用順は区別する必要はありません)。

  6. その他のクラスタサーバへ、2～5 の設定を行ってください。

  7. クラスタシャットダウンリブートを行ってください。

  8. リモート LAN 上のクライアントへ、サーバと同様に WINS サーバの設定を 行ってください。

• クラスタサーバとは別のサーバ上に WINS サーバを設置する場合

  1. クラスタサーバとは独立したサーバへ、WINSサーバをインストールしてください。

  2. 全クラスタサーバで、3.～6. の設定を行ってください。

  3. [コントロールパネル]－[ネットワーク接続] から、パブリック LAN を示すローカルエリア接続の [プロパティ] を開きます。

  4. [インターネットプロトコル (TCP/IP)] を選択し、[プロパティ] をクリックします。

  5. [詳細設定] をクリックして、[WINS] タブを選択します。

  6. WINS アドレスに、WINS サーバの IP アドレスを設定してください。

  7. クラスタシャットダウンリブートを行ってください。

  8. リモート LAN 上のクライアントへ、サーバと同様に WINS サーバの設定を 行ってください。

3.13.6. 仮想コンピュータ名リソースとダイナミック DNS リソースの使い分け

仮想コンピュータ名リソースは旧プロトコルを使用しているため、DNSサーバを用意可能な場合はダイナミックDNSリソースを推奨致します。

仮想コンピュータ名リソースとダイナミックDNSリソースの併用はできません。

3.13.7. 仮想コンピュータ名で使用可能なサービス

仮想コンピュータ名は以下のサービスが使用できます。

サービス	FIP関連付け 有	FIP関連付け 無
TCP/IP の名前解決 (コンピュータ名→IP アドレス)	✓	n/a
ネットワークドライブ接続	✓	✓
ネットワークプリンタ接続	✓	✓
名前付きパイプ	✓	✓
RPC (名前つきパイプ)	✓	✓
RPC (TCP/IP)	✓	n/a

3.13.8. 仮想コンピュータ名リソースに関する注意事項

• 活性する仮想コンピュータ名リソース 1 つにつき、1 つの仮想コンピュータ名制御プロセス (clpvcomp.exe) を生成します。誤って、このプロセスを終了しないようにしてください。プロセス消滅の異常は仮想コンピュータ名監視リソースで検出することが可能です。

• 仮想コンピュータ名は以下のサービスを使用できません。

  1. メールスロット

  2. RPC (NetBIOS)

• 仮想コンピュータ名とフローティング IP が関連付けられていない場合、以下の注意事項があります。

  1. 以下のサービスが使用できません。

     • TCP/IP の名前解決 (コンピュータ名→IP アドレス)

     • RPC (TCP/IP)

  2. サーバダウンによるフェイルオーバ後は、再接続が可能になるまでに、数分程度必要な場合があります。

  3. クラスタが起動してからネットワークコンピュータで仮想コンピュータ名が表示されるまで数分程度必要なことがあります。

  4. LMHOSTS に仮想コンピュータ名は記述できません。

  5. DNS サーバを使用する設定を行っているかつ、DNS サーバが WINS 連携をしている場合は、DNS サーバ上に仮想コンピュータ名のキャッシュ情報が残っている間、フェイルオーバによる切替えが動作しません。DNS サーバ上で WINSレコードに対するキャッシュ保持期間を 1 秒程度に短くしてください。

• 仮想コンピュータ名とフローティング IP が関連付けらている場合、以下の注意事項があります。

  1. NetBEUI プロトコルは使用できません。NetBEUI プロトコルを使用する場合には、関連付けを 解除してください。

  2. 仮想コンピュータ名は、関連付けられているフローティング IP のネットワークアドレス内で有効になります。関連付けられているフローティング IP と異なるネットワークアドレスから仮想コンピュータ名を利用する場合は、以下の何れかを実施して下さい。

     • DNSに動的登録する

     • LMHOSTS に仮想コンピュータ名と FIP アドレスの組を記述する

     • WINS サーバを設定する

  3. 複数の仮想コンピュータ名を同一のフローティング IP と関連付けることはできません。

  4. 複数のパブリック LAN に、それぞれ異なるフローティング IP がある場合、各LAN に同じ仮想コンピュータ名を使う際には、各フローティング IP に対応する仮想コンピュータ名リソースを作成し、それらのリソース間に依存関係を設定して、 活性・非活性処理がシリアルに実行されるようにする必要があります。

• リモートネットワーク上の WINS サーバに仮想コンピュータ名を登録する場合、 下記の確認・設定をクラスタサーバに対して行ってください。

  1. [コントロールパネル]－[ネットワークと共有センター]－[アダプターの設定の変更] を開きます。

  2. [ファイルメニュー]－[詳細設定]－[詳細設定] を選択し、[アダプタとバインド] タブを選択します。

  3. バインドパス順序をパブリック LAN (WINS サーバのアドレスが登録されているネットワークアダプタ) が先頭になるように変更する。

     [アダプタとバインド] のイメージは、以下のようになります。

  

• グループが活性しているサーバ (現用系サーバ) から、そのグループの持つ仮想コンピュータ名を使用してファイル共有プロトコル(SMB/CIFS) の通信を行うと、認証エラーが発生し通信に失敗することがあります。回避策の手順に従って、設定を行ってください。

  例1) グループ活性中のサーバで、エクスプローラを起動し、アドレスバーに次を 入力して共有フォルダを開こうとしても、認証エラーで失敗する。

  \\＜仮想コンピュータ名＞\共有名

  例2) グループ活性中のサーバで、レジストリエディタを起動し、「ネットワークレジストリへの接続」で仮想コンピュータ名を指定すると、認証エラーで失敗する。

  <回避策>

  1. すべてのサーバが正常動作中であることを、Cluster WebUI から確認してください。

  2. 全クラスタサーバで、以下 3～7 を実施します。

  3. スタートメニューの "ファイル名を指定して実行" から regedit.exe を起動し、 以下のレジストリ値を追加します。

     キー:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
     名前(型):
     DisableStrictNameChecking(DWORD型)
     値:0x1
     

  4. 以下のキーに次の値が既に存在する場合、削除します。

     キー:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
     名前(型):
     BackConnectionHostNames(DWORD型)
     

  5. 4.と同じ名前 ("BackConnectionHostNames") の "複数行文字列値" を新規作成し、仮想コンピュータ名をセットします。

     例) "vcom1"、"vcom2" の 2 つの仮想コンピュータ名が存在する場合

     

  6. レジストリエディタを閉じます。

  7. (仮想コンピュータ名とフローティング IP が関連付けられている場合のみ実施)

     システムドライブの、\Windows\system32\drivers\etc\hosts に、仮想コンピュータ名 (FQDN名ではなくコンピュータ名のみ) と、それに関連付けられているフローティング IP アドレスの組み合わせでエントリを追加します。

     フローティング IP アドレスと関連付けられている仮想コンピュータ名が複数存在する場合には、それらすべてについてエントリを追加します。
     例) 仮想コンピュータ名が "vcom1"、それと関連付けられているフローティングIP アドレスが 10.1.1.11 の場合:

     hosts ファイルに次の行を追加

     10.1.1.11 vcom1

  8. 以上の手順をすべてのサーバで実施した後、クラスタシャットダウンを実施して、すべてのサーバを再起動してください。

• 仮想コンピュータ名を DNS に動的登録する場合、以下の注意事項があります。

  1. クラスタサーバはドメインに参加している必要があります。

  2. パブリック LAN に、DNS の設定が必要です。CLUSTERPRO は、パブリックLAN に指定されたアドレスに対して、仮想コンピュータ名を DNS へ登録します。

  3. DNS 登録は仮想コンピュータ名リソースの活性時に行いますが、DNS 登録に失敗しても、エラーとしません。

  4. 仮想コンピュータ名の DNS からの削除は仮想コンピュータ名リソースの非活性時に行いますが、削除に失敗してもエラーとしません。

• ネットワークケーブルが抜けている場合、NICに対し仮想コンピュータ名リソースを割り当てることができないため、リソースの 活性に失敗することがあります。

• Server サービスが停止している場合、仮想コンピュータ名リソースの起動に失敗します。仮想コンピュータ名リソースを使う場合は、必ず Server サービスを起動させておいてください。

• DNS サーバの動的更新を「セキュリティ保護のみ」とする場合、仮想コンピュータ名リソースが更新するゾーンに対して、各コンピュータオブジェクトに「書き込み」「サブツリーの削除」のアクセス許可を与える必要があります。アクセス許可の適用先は「このオブジェクトとすべての子オブジェクト」を選択して下さい。設定方法は DNS サーバの設定方法をご確認ください。DNS サーバの動的更新を「非セキュリティ保護およびセキュリティ保護」に設定している場合、上記設定は不要です。

3.13.9. 詳細タブ

仮想コンピュータ名 (15 バイト以内)

仮想コンピュータ名を設定します。

対象 FIP リソース名

仮想コンピュータ名に関連付けるフローティング IP リソース名を選択します。

調整

[VCOM リソース調整プロパティ] ダイアログを表示します。仮想コンピュータ名リソースの詳細設定を行います。

VCOM リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

DNS への動的登録をする

リソース活性時に DNS への動的登録を行うかどうかを設定します。

対応付ける IP アドレス

DNS への動的登録を行う際に仮想コンピュータ名と対応付ける IP アドレスとして、以下のいずれかを選択します。

• FIP

  対象 FIP リソース名で選択したフローティング IP リソースのアドレスを対応付けます。
• 任意のアドレス

  サーバ毎に任意の IP アドレスを対応付けます。

編集

対応付ける IP アドレスとして任意のアドレスを選択した場合、サーバ一覧で対象サーバを選び、[編集]をクリックしてサーバ毎に IP アドレスを設定します。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

3.14. ダイナミック DNSリソースを理解する

3.14.1. ダイナミックDNSリソースの依存関係

既定値では、以下のグループリソースタイプに依存します。

グループリソースタイプ
仮想 IP リソース
フローティング IP リソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
Azure プローブポートリソース

3.14.2. ダイナミック DNS リソースとは?

• ダイナミック DNS リソースは、Dynamic DNS サーバ(以下DDNSサーバ)に仮想ホスト名と活性サーバの IP アドレスを登録します。クライアントアプリケーションは、仮想ホスト名を使用してクラスタサーバに接続することができます。仮想ホスト名を使用することにより、"フェイルオーバ"または、"グループの移動" が発生しても、クライアントは、接続先サーバの切り替えを意識する必要がありません。

以下の図には、ダイナミックDNSサーバ（DDNSサーバ）とServer 1およびServer 2、そして Clientが描かれています。 Server 1は、仮想ホスト名とIPアドレスをDDNSサーバに登録します。

図 3.99 ダイナミックDNSサーバを使用する構成 (1)

Clientは、アクセス先である仮想ホスト名に対応するIPアドレスを、DDNSサーバに問い合わせます。 問い合わせに対して、DDNSサーバは仮想ホスト名に対応する Server 1のIPアドレスを回答します。 Clientは仮想ホスト名のIPアドレスに接続します。

図 3.100 ダイナミックDNSサーバを使用する構成 (2)

Server 1がダウンし、Server 2へのフェイルオーバが発生します。

図 3.101 ダイナミックDNSサーバを使用する構成 (3)

Server 2は、仮想ホスト名とIPアドレスをDDNSサーバに登録します。

図 3.102 ダイナミックDNSサーバを使用する構成 (4)

Clientは、アクセス先である仮想ホスト名に対応するIPアドレスを、DDNSサーバに問い合わせます。 問い合わせに対して、DDNSサーバは仮想ホスト名に対応する Server 2のIPアドレスを回答します。 Clientは仮想ホスト名のIPアドレスに接続します。

図 3.103 ダイナミックDNSサーバを使用する構成 (5)

3.14.3. 仮想コンピュータ名リソースとダイナミック DNS リソースの使い分け

仮想コンピュータ名リソースは旧プロトコルを使用しているため、DNSサーバを用意可能な場合はダイナミックDNSリソースを推奨致します。

仮想コンピュータ名リソースとダイナミックDNSリソースの併用はできません。

3.14.4. ダイナミック DNS リソースを使用する場合の事前準備

• ダイナミック DNS リソースを使用する前に DDNS サーバを構築する必要があります。DDNSサーバはActive Directoryのみサポートしています。

• Kerberos 認証機能を使用する場合、ダイナミック DNS リソースが更新するActive Directory のドメインに対して、以下の設定を行う必要があります。

• 各クラスタサーバに以下のアクセス許可を与えて下さい。

  • すべての子オブジェクトの作成

  • すべての子オブジェクトの削除

  アクセス許可の適用先は「このオブジェクトとすべての子オブジェクト」を選択して下さい。

• DNS サーバの動的更新を「セキュリティ保護のみ」とする場合、ダイナミック DNS リソースが更新するActive Directory のドメインに対して、各コンピュータオブジェクトに「書き込み」「サブツリーの削除」のアクセス許可を与える必要があります。アクセス許可の適用先は「このオブジェクトとすべての子オブジェクト」を選択して下さい。設定方法は DNS サーバの設定方法をご確認ください。DNS サーバの動的更新を「非セキュリティ保護およびセキュリティ保護」に設定している場合、上記設定は不要です。

3.14.5. ダイナミック DNS リソースに関する注意事項

• ダイナミック DNS リソースは[定期的に動的更新を行う]をオンにしている場合、定期的に DDNS サーバに仮想ホスト名の更新を行います。

• 活性するダイナミックDNSリソース 1 つにつき、1 つのDDNS制御プロセス(clpddnsp.exe)を生成します。誤ってこのプロセスを終了しないようにしてください。プロセス消滅の異常はダイナミックDNS監視リソースで検出することが可能です。

• 各サーバの IP は異なるセグメントに存在する場合、FIPをダイナミックDNSリソースのIPとして設定することはできません。

• 各サーバの IP アドレスを DDNS サーバに登録したい場合、サーバ別設定で各サーバの IP アドレスを設定してください。[IPアドレス]は[共通]タブでは任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

• サーバ別設定の場合、活性時に既に同じ仮想ホスト名が存在すると、プライマリ DNS サーバから重複する仮想ホスト名を一旦削除し、該当するノードの仮想ホスト名と活性サーバの IP アドレスを登録します。この場合、非活性時の設定である[登録したIPアドレスを削除する]の値は影響しません。

• クライアントから仮想ホスト名を使用して接続を行っている場合、ダイナミック DNS リソースを持つグループのフェイルオーバが発生すると、再接続が必要なことがあります。(ブラウザの再起動など)

• 仮想ホスト名を経由した Cluster WebUI 接続時の挙動について

  • ダイナミック DNS リソースに各サーバの IP アドレスをサーバ別設定している場合

    クライアントから仮想ホスト名を使用して Cluster WebUI を接続している場合、ダイナミック DNS リソースを持つグループのフェイルオーバが発生すると、Cluster WebUI の接続は自動的に切り替わりません。ブラウザを再起動し、再度Cluster WebUI を接続する必要があります。
  • ダイナミック DNS リソースに FIP アドレスを設定している場合

    クライアントから仮想ホスト名を使用して Cluster WebUI を接続している場合、ダイナミック DNS リソースを持つグループのフェイルオーバが発生すると、Cluster WebUI の接続は自動的に切り替わります。

3.14.6. 詳細タブ

仮想ホスト名 (253 バイト以内)

DDNS サービスに登録する仮想ホスト名を入力します。

IPアドレス (79 バイト以内)

仮想ホスト名に対応する IP アドレスを記入します。

FIP リソースと一緒に使用する場合、[共通] タブに FIP リソースの IP アドレスを入力します。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力してください。

DDNSサーバ (255 バイト以内)

DDNS サーバの IP アドレスを入力します。セカンダリDNSサーバを指定するには、カンマ(,)区切りで複数指定してください。プライマリDNSサーバは最初に指定、セカンダリDNSサーバは2番目以降に指定してください。

プライマリDNSサーバのみ指定する例：192.168.10.180

セカンダリDNSサーバを2つ指定する例：192.168.10.180,192.168.10.181,192.168.10.182

ポート番号(1～65535)

DDNS サーバのポート番号を入力します。既定値は 53 です。

キャッシュのTTL (0～2147483647)

キャッシュの生存期間(TTL=Time To Liveの略)を入力します。既定値は0秒です。

定期的に動的更新を行う

• チェックボックスがオン(既定)

  DDNSサーバへ仮想ホスト名と活性サーバの IP アドレスを定期的に更新します。
• チェックボックスがオフ

  DDNSサーバへ仮想ホスト名と活性サーバの IP アドレスを定期的に更新しません。

更新間隔 (1～9999)

DDNSサーバへ仮想ホスト名と活性サーバの IP アドレスを定期的に更新する間隔を入力します。既定値は60分です。

DDNSサーバの更新間隔より短い時間を指定してください。

登録したIPアドレスを削除する

• チェックボックスがオン

  非活性時、DDNSサーバへ登録した仮想ホスト名と活性サーバの IP アドレスを削除します。
• チェックボックスがオフ(既定)

  非活性時、DDNSサーバへ登録した仮想ホスト名と活性サーバの IP アドレスを削除しません。削除しない場合、残存した仮想ホスト名にクライアントからアクセスされる可能性があります。

Kerberos認証

Active Directory で Kerberos認証が有効かどうかを設定します。ダイナミックDNS リソースが仮想ホスト名を Active Directory ドメインへ登録時にパスワードを自動生成するため、パスワードは指定不要です。既定値はオフです。

• チェックボックスがオン

  Active Directory で Kerberos 認証が有効な場合、設定します。
• チェックボックスがオフ(既定)

  Active Directory で Kerberos 認証が無効な場合、設定します。

3.15. 仮想 IP リソースを理解する

3.15.1. 仮想 IP リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.15.2. 仮想 IP リソースとは?

クライアントアプリケーションは、仮想 IP アドレスを使用してクラスタサーバに接続することができます。また、サーバ間でも仮想 IP アドレスを使用しての接続が可能です。仮想 IP アドレスを使用することにより、フェイルオーバ/フェイルオーバグループの移動が発生しても、クライアントは、接続先サーバの切り替えを意識する必要がありません。

図 3.104 仮想IPを使用した構成 (1)

図 3.105 仮想IPを使用した構成 (2)

• サーバの設定事項1

  同一LAN内のクラスタサーバは、RIPパケットを受け取ることにより経路変更が可能か、またはルータにアクセスすることにより仮想IPアドレスの経路情報を解決できる必要があります。
• サーバの設定事項2

  別セグメントのクラスタサーバは、ルータにアクセスすることにより仮想IPアドレスの経路情報を解決できる必要があります。
• 仮想IPリソースの設定事項1

  クラスタサーバが所属するLANの、ネットワークアドレスの範囲外であり、既存のIPアドレスと衝突しないIPアドレスを設定してください。
• ルータの設定事項1

  各ルータは、RIPパケットを解釈して動的経路の制御が行えるか、または仮想IPアドレスの経路に関する情報が静的経路情報として解決できる必要があります。
• 仮想IPリソースの設定事項2

  RIPパケットを正しく送信するため、送信元IPアドレスは必ずサーバごとに設定してください。
• ルータの設定事項2

  各ルータのフラッシュタイマーは、ハートビートタイムアウト以内に設定してください。
• クライアントの設定事項1

  同一LAN内のクライアントは、RIPパケットを受け取ることにより経路変更が可能か、または ルータにアクセスすることにより仮想IPアドレスの経路情報を解決できる必要があります。
• クライアントの設定事項2

  別セグメントのクライアントマシンは、ルータにアクセスすることにより仮想IPアドレスの経路情報を解決できる必要があります。

3.15.3. 仮想 IP アドレスの検討

仮想 IP アドレスに割り当てる IP アドレスは、以下の条件を満たす必要があります。

• クラスタサーバが所属する LAN の、ネットワークアドレスの範囲外である

• 既存のネットワークアドレスと衝突しない

この 2 つの条件を満たすために、以下の 2 つの割り当て方法で、いずれかを選択してください。

• 仮想 IP アドレス用に新たに正当なネットワーク IP アドレスを取得し、そこから 仮想 IP アドレスを割り当てる。

• プライベート IP アドレス空間から、適当なネットワーク IP アドレスを決定し、そこからそれぞれの仮想 IP アドレスを割り当てます。具体例を示すと、以下のような手順になります。

  • ネットワークアドレス 192.168.0 ～ 192.168.255 から、仮想 IP アドレス用に １つ選択します。

  • 上記で選択したネットワークアドレスの中から、仮想 IP アドレス用のホスト IP アドレスを 64 個以内で割り当てます。(例えば、ネットワークアドレス 192.168.10を選択し、その中からホスト IP アドレスを 192.168.10.1 と 192.168.10.254 の2 個を割り当てる。)

  • 仮想 IP アドレスのネットマスクは、255.255.255.0 に設定します。

さらに以下の点に注意が必要です。

• プライベート IP アドレスは、組織内で閉じたネットワークのためのアドレスであるため、インターネットプロバイダ等を隔てた組織外から、仮想 IP アドレスを用いてアクセスはできません。

• プライベート IP アドレスに関する経路情報を、組織外に流してはいけません。

• プライベート IP アドレスの衝突が起こらないよう、組織内での調整が必要です。

3.15.4. 経路制御

リモート LAN から仮想 IP アドレスにアクセスするために、リモート LAN とクラスタサーバの LAN まで経路上の全てのルータに、仮想 IP アドレスの経路情報が有効になっていなければなりません。

具体的には、以下のような設定が必要です。

• クラスタサーバの LAN 上のルータがホスト RIP を解釈する。

• クラスタサーバからリモートサーバまでの経路上のルータが、全て動的経路制御であるか、または仮想 IP アドレスの経路に関する情報が、静的経路情報として設定されている。

3.15.5. 仮想 IP アドレスの使用条件

仮想 IP アドレスが使用できる環境

以下のマシンからは仮想 IP アドレスに正しくアクセスできます。スイッチングハブが使われた LAN であっても、仮想 IP アドレスメカニズムは問題なく動作します。

ただし、サーバダウン時には、接続していた TCP/IP コネクションは切断されます。

ホスト形式の RIP を受信してホスト形式のルーティングテーブルを作成するように設定できないスイッチング HUB で仮想 IP アドレスを使用する場合は、ネットワークアドレスを新たに 1 つ確保して、それぞれのサーバの仮想 IP アドレスが別々のネットワークアドレスに 所属するように仮想 IP アドレスを設定する必要があります。

• 仮想 IP が活性するサーバと同一 LAN にあるクラスタサーバ

  以下の条件を満たすものであれば、仮想 IP アドレスが使用できます。

  • RIP パケットを受け取ることにより経路変更が可能なマシン

  • ルータにアクセスすることにより仮想 IP アドレスの経路情報を解決できるマシン

• 仮想 IP が活性するサーバと異なる LAN にあるクラスタサーバ

  以下の条件を満たすものであれば、仮想 IP アドレスが使用できます。

  • ルータにアクセスすることにより仮想 IP アドレスの経路情報を解決できる マシン

• クラスタサーバと同一 LAN に属するクライアント

  以下の条件を満たすものであれば、仮想 IP アドレスが使用できます。

  • RIP パケットを受け取ることにより経路変更が可能なマシン

  • ルータにアクセスすることにより仮想 IP アドレスの経路情報を解決できるマシン

• リモート LAN 上のクライアント

  以下の条件を満たすものであれば、仮想 IP アドレスが使用できます。

  • ルータにアクセスすることにより仮想 IP アドレスの経路情報を解決できるマシン

3.15.6. 仮想 IP リソースに関する注意事項

仮想 IP アドレスは NetBIOS プロトコルをサポートしていません。

• 仮想 IP アドレスを LMHOSTS などで適当なホスト名にマップしても Windowsのブラウズ/ネットワーク、プリンタ資源へのアクセス/ユーザ認証などには使用できません。

• NetBIOS プロトコルでの接続先の自動切替を行う場合には、仮想コンピュータ名を使用してください。

仮想 IP アドレスには、以下の規則があります。

• 仮想 IP リソースの登録数は 1 クラスタシステムに対して最大 64 までです。

• 仮想 IP リソースを使用するには、クラスタ名、サーバ名、グループ名は Ver8.0 以前の命名規則に従って設定する必要があります。

ルータのフラッシュタイマーの設定時間は、ハートビートタイムアウト以内になるように調整してください。ハートビートタイムアウトに関しては、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「タイムアウトタブ」を参照してください。

各クラスタサーバに OS の [ルーティングとリモートアクセス サービス] を追加し、LAN ルーティングを有効にする必要があります。ただし、優先順位の一番高いインタコネクト LAN がパブリック LAN と共通である場合は不要です。

仮想 IP アドレスとして IPv6 アドレスを使用する場合は、優先順位の一番高いインタコネクトとしてパブリック LAN を指定する必要があります。

使用するルーティングプロトコルを「RIPver2」に設定した場合、創出するRIPパケット内のサブネットマスクは「255.255.255.255」となります。

3.15.7. 詳細タブ

IP アドレス (45 バイト以内)

使用する仮想 IP アドレスを入力します。

ネットマスク (45 バイト以内)

使用する仮想 IP アドレスのネットマスクを設定します。仮想 IP アドレスとして IPv6 アドレスを指定する場合は設定不要です。

宛先 IP アドレス (45 バイト以内)

RIP パケットの送出先 IP アドレスを入力します。IPv4 の場合はクラスタサーバが所属する LAN のブロードキャストアドレス、IPv6 の場合はクラスタサーバが所属する LAN のルータの IPv6 アドレスを指定します。

送信元 IP アドレス (45 バイト以内)

RIP パケット送出時にバインドする IP アドレスを入力します。仮想 IP アドレスを活性するNIC で活性している実 IP アドレスを指定します。

IPv6 アドレスを使用する場合は、送信元 IP アドレスとしてリンクローカルアドレスを指定します。

注釈

送信元 IP アドレスは必ずサーバ個別設定を行い、各サーバの実 IP アドレスを設定してください。送信元アドレスが不正な場合、仮想 IP リソースは正常に動作しません。

サーバ共通設定画面では、任意のサーバの送信元 IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

送出間隔 (1～30)

RIP パケットの送出間隔を入力します。

使用するルーティングプロトコル

使用する RIP バージョンを入力します。IPv4 環境では RIPver1、RIPver2 から選択します。IPv6 環境では RIPngver1、RIPngver2、RIPngver3 から選択します。複数のルーティングプロトコルを選択することも可能です。

調整

[仮想 IP リソース調整プロパティ] ダイアログを表示します。仮想 IP リソースの詳細設定を行います。

仮想 IP リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

ping 実行

仮想 IP リソースを活性する前に [ping] コマンドを使用して重複した IP アドレスがないか確認を行うかどうかを設定します。

• チェックボックスがオン

  [ping] コマンドによる確認を行います。
• チェックボックスがオフ

  [ping] コマンドによる確認を行いません。

ping

仮想 IP リソースを活性する前に、重複した IP アドレスがないかチェックするために発行される [ping] コマンドに関する詳細設定です。

• インターバル (0～999)

  [ping] コマンドを発行する間隔を秒単位で設定します。
• タイムアウト (1～999999)

  [ping] コマンドのタイムアウトをミリ秒単位で設定します。
• リトライ回数 (0～999)

  [ping] コマンドのリトライ回数を設定します。
• VIP 強制活性

  [ping] コマンドによるチェックで重複した IP アドレスが検出された場合に、仮想 IPアドレスを強制的に活性するかどうかを設定します。
  • チェックボックスがオン

    強制活性を行います。
  • チェックボックスがオフ

    強制活性を行いません。

NIC Link Down を異常と判定する

仮想 IP リソースを活性する前に、NIC Link Downの確認を行うかどうかを設定します。

• チェックボックスがオン

  NIC Link Downの場合、仮想 IP リソースを活性化しません。
• チェックボックスがオフ

  NIC Link Downの場合でも、仮想 IP リソースを活性化します。既存の動作と同じです。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

RIP タブ

仮想 IP リソースの RIP に関する詳細設定が表示されます。

ネクストホップ IP アドレス

RIP の次ホップアドレス (次ルータのアドレス) を入力します。ネクストホップ IP アドレスは省略可能で RIPver2 の場合のみ指定することが可能です。ネットマスクまたは prefix の指定はできません。

メトリック (1～15)

RIP のメトリック値を入力します。メトリックは宛先に到達するための RIP のホップカウントです。

ポート

[ポート番号] には RIP の送信に使用する通信ポートの一覧が表示されます。

追加

RIP の送信に使用するポート番号を追加します。[ポート番号の入力] ダイアログボックスが表示されます。

ポート番号

RIP の送信に使用するポート番号を入力して [OK] を選択してください。

削除

[ポート番号] で選択しているポートをリストから削除します。

編集

[ポート番号の入力] ダイアログボックスが表示されます。[ポート番号] で選択しているポートが表示されるので、編集して [OK] を選択します。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

RIPng タブ

仮想 IP リソースの RIPng に関する詳細設定が表示されます。

メトリック (1～15)

RIPng のメトリック値を入力します。メトリックは宛先に到達するための RIPng のホップカウントです。

ポート

[ポート番号] には RIPng を送信するポート番号の一覧が表示されます。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

追加

RIPng の送信に使用するポート番号を追加します。[ポート番号の入力] ダイアログボックスが表示されます。

ポート番号

RIPng の送信に使用するポート番号を入力して [OK] を選択してください。

削除

[ポート番号] で選択しているポートをリストから削除します。

編集

[ポート番号の入力] ダイアログボックスが表示されます。[ポート番号] で選択しているポートが表示されるので、編集して [OK] を選択します。

3.16. CIFS リソースを理解する

3.16.1. CIFS リソースの依存関係

既定値では、以下のグループリソースタイプに依存します。

グループリソースタイプ
ディスクリソース
ミラーディスクリソース
ハイブリッドディスクリソース

3.16.2. CIFS リソースとは?

CIFS リソースは共有フォルダの公開・削除を制御します。CIFS リソースを用いることにより、共有ディスク/ミラーディスク上のフォルダを共有フォルダとして公開することができます。

以下の 2 通りの公開方法があります。

共有設定を個別に指定する

共有フォルダの設定をあらかじめ CIFS リソースの設定項目で指定しておき、リソース活性時に指定された設定で共有フォルダを公開します。公開する共有フォルダ毎に CIFS リソースを作成する必要があります。

ドライブ共有設定の自動保存を行う

指定された共有ディスク/ミラーディスク上のフォルダが共有公開された場合に、共有設定を取得して、共有ディスク/ミラーディスク上の設定ファイルに保存します。共有設定は共有ディスク/ミラーディスクの非活性時に一旦解除されますが、次回 CIFS リソース活性時に、保存していた設定で共有フォルダを再公開します。

[ドライブ共有設定の自動保存を行う]をチェックした場合の動作を説明します。CIFS リソースは自動的にドライブ上の共有フォルダの情報を取得し、[共有設定ファイル]に保存します。

CIFS リソースの初期起動時には共有設定ファイルは存在しないため、ドライブ上の全ての共有フォルダ情報をスキャンし、[共有設定ファイル]に保存します。

その後は共有フォルダの設定が変更されるたびに CIFS リソースから[共有設定ファイル]を更新します。

CIFS リソースが非活性となる際には全ての共有を削除します。

ただし、[共有設定ファイル]には共有情報が残りますので、活性時には共有情報を自動的に復旧します。

各公開方法のメリット/デメリットは以下の通りです。

	メリット	デメリット
共有設定を個別に指定する	共有設定の不整合が発生しません。	共有設定を変更した場合、CIFSリソースの変更が必要です。
ドライブ共有設定の自動保存を行う	共有設定を変更した場合、自動で保存します	共有設定ファイルが破損した場合、共有情報の不整合が発生します。

3.16.3. CIFS リソースに関する注意事項

• 共有ディスク/ミラーディスク上のフォルダを共有公開する場合、フォルダの右クリックメニュー等で共有設定を行っても、ディスクリソース/ミラーディスクリソースの非活性化の際に共有設定が消去され、フェイルオーバ時に他サーバに引き継がれません。このため、このような場合はCIFS リソースを用いる必要があります。

• ドライブ共有設定の自動保存を行う場合、保存先として設定された共有設定ファイルは隠しファイルとして作成されます。また、共有設定ファイルが破損した場合のバックアップとして、設定されたファイル名の末尾に".bak"を付けたファイルが同じフォルダに作成されます。既存のファイルとファイル名が重複しないように設定してください。

• 共有設定ファイルを作成するフォルダには、ローカルシステムアカウント (SYSTEM) に対してファイルの作成・更新に必要なアクセス権が与えられている必要があります。適切なアクセス権がないと、共有設定ファイルの作成・更新に失敗します。また、 誤って共有設定ファイルとバックアップファイルが削除されると、設定情報が失われる可能性がありますので、他のアカウントでは削除できないように設定することを お勧めします。

• CLUSTERPROが管理するディスク上(例.共有ディスク、ミラーディスク)のフォルダの共有の公開・削除をCIFSリソースで制御する場合、下記いずれかの条件が生じるとCIFSリソースの活性に失敗します。回避策1もしくは回避策2のいずれかを実施してください。回避策1を推奨します。

  <条件>

  • クラスタシャットダウン・再起動以外によるサーバ再起動後、CIFSリソースをフェイルバックさせる。

  • 非活性異常後の次回活性時。

  <回避策1>

  [フォルダがすでに共有済みの場合に活性異常としない]をチェックしてください。
  <回避策2>

  スクリプトリソースを利用してCIFSリソースの活性前に共有名の削除を 実施する必要があります。下記の手順でスクリプトリソースの追加と設定 変更を行ってください。

  1. スクリプトリソースを追加し、[プロパティ]を開きます。[依存関係]タブで[既定の依存関係に従う]のチェックを外し、[依存するリソース]に該当のディスクリソースを追加してください。

  2. 1. で追加したスクリプトリソースの[詳細]タブを開き、start.bat に以下の(★)部分の記載を追加します。

     :NORMAL

     net share <CIFSリソースで制御する共有名> /delete (★追加)

     (略)

     :FAILOVER

     net share <CIFSリソースで制御する共有名> /delete (★追加)
     CIFSリソースで[ドライブ共有設定の自動保存を行う]場合は、CIFSリソースで制御する共有名を全て追加する必要があります。

  3. CIFSリソースの [プロパティ] を開きます。依存関係タブで [既定の依存関係に従う] のチェックを外し、[依存するリソース] に該当のディスクリソースと 1. で追加したスクリプトリソースを追加してください。

• 共有アクセス権はクラスタノード全てから参照可能なユーザ・グループを設定してください。CIFS リソースでは NTFS アクセス権は設定しません。

• ActiveDirectory サーバの移行に際して、共有フォルダに対して、SID履歴の機能を利用した状態で移行前後の両サーバドメインのアカウントについて共有設定をした場合、移行元のアカウントについては共有設定を保持できません。

• 共有フォルダのアクセス権限が以下の場合、CIFS リソースは活性に失敗します。アクセス権限を設定してください。

  • SYSTEM のアクセス権限のうち、「読み取り」が拒否されている場合

  • SYSTEM のアクセス権限のうち、「フォルダの内容の一覧表示」が拒否されている場合

• [共有設定復元時の失敗を活性異常とする]の設定がオンの場合、共有設定ファイルで保存されているユーザが削除されると、CIFS リソースの活性に失敗します。共有フォルダのアクセス権に設定されているユーザを削除する場合の手順は以下のいずれかです。

  • [共有設定復元時の失敗を活性異常とする]の設定をオフにする。

  • 共有設定されているユーザの削除を実施する場合、併せてCIFSリソースに設定しているドライブ上の共有フォルダのプロパティから[共有]タブ-[詳細な共有]-[アクセス許可]より該当のグループを削除する。

• 共有設定ファイルが破損してしまった場合の復旧方法は以下のいずれかです。

  • CIFS リソースを停止し、バックアップしていた共有設定ファイルに置換後、CIFS リソースを起動する。フォルダ数が多い場合や、共有設定を変更する回数が多い場合はこの方式が有効です。

  • CIFS リソースを停止し、破損した共有設定ファイルを削除する。CIFS リソースを起動後、エクスプローラから再度共有設定を行う。

• フェイルオーバが発生した際、一時的に共有フォルダが存在しなくなるため、フェイルオーバ前に開いていたファイルやエクスプローラでの閲覧が継続不可能になる場合があります。このため、下記のような共有フォルダのオフライン利用を推奨します。

  • [ドライブ共有設定の自動保存を行う]がオンの場合、共有フォルダの[キャッシュ]設定にて[共有からユーザーが開いたファイルとプログラムは、すべて自動的にオフラインで利用可能にする]を指定する

  • [ドライブ共有設定の自動保存を行う]がオフの場合、CIFS リソースの調整プロパティの[キャッシュ]タブにて[自動キャッシュ]を指定する

3.16.4. 詳細タブ

ドライブ共有設定の自動保存を行う

ドライブ共有設定の自動保存を行うかどうかを設定します。自動保存を行う場合はオンにしてください。

対象ドライブ

ドライブ共有設定の自動保存を行う場合に、対象となるディスクのドライブ文字を指定します。

共有設定ファイル (255 バイト以内)

ドライブ共有設定を保存するファイルをフルパスで指定します。同じグループ内の共有ディスク/ミラーディスク/ハイブリッドディスク上のパスを指定する必要があります。CIFS リソースが作成するファイルです。CIFS リソース活性前に用意して頂く必要はありません。

共有設定復元時の失敗を活性異常とする

チェックされている場合： CIFS リソースの活性時に、共有設定ファイルに保存されているユーザが存在しない場合、またはドメイン環境などでユーザの情報が取得できない 場合に、CIFS リソースの活性に失敗します。また、共有フォルダの設定変更時、共有フォルダのアクセス権に設定されているユーザが存在しない場合やドメイン環境などでユーザの情報が取得できない場合などに警告メッセージが出力されます。

チェックされていない場合 (既定)：上記の場合に、CIFS リソースの活性に成功します。情報を取得できなかったユーザのファイル共有のアクセス権は設定されません。警告メッセージも出力されません。

一方、以下の設定は、共有設定を個別に指定する場合に設定します。

共有名 (79 バイト以内)

CIFS リソースで公開する共有フォルダの共有名を設定します。下記を除いたシフトJISの文字であれば使用可能です。

• 機種依存文字(NEC機種依存文字、NEC選定IBM拡張文字、IBM拡張文字)
• ～∥―－￠￡￢:

使用可能な文字かどうかを確認するには、CIFSリソース登録後、[ファイル]メニューの[情報ファイルの保存]で情報ファイルを保存し、[ファイル]メニューの[情報ファイルを開く]で情報ファイルを開いてCIFSリソースの共有名が文字化けしていないことを確認して下さい。

フォルダ (255 バイト以内)

CIFS リソースで公開するフォルダのフルパスを設定します。

コメント (255 バイト以内)

CIFS リソースで公開する共有フォルダのコメントを設定します。

フォルダがすでに共有済みの場合に活性異常としない

チェックされていない場合： CIFS リソースの活性時にフォルダがすでに共有済みの場合、CIFS リソースの活性に失敗します。Windows Server 2012以降ではOS側の仕様変更により常にこの状態となりますため、チェックすることを推奨します。

チェックされている場合 (既定)：上記の場合に、CIFS リソースの活性に成功します。警告メッセージも出力されません。

調整

CIFS リソース調整プロパティダイアログを表示します。CIFS リソースの詳細設定を行います。

CIFS リソース調整プロパティ

キャッシュタブ

キャッシュに関する詳細設定が表示されます。

キャッシュを可能にする

共有フォルダのキャッシュを可能にするかどうかを設定します。本機能を有効にした場合、CIFS リソースの共有設定を個別に指定する場合にサーバの共有フォルダに置かれているファイルをオフライン状態でも参照することができるため、フェイルオーバ後もファイルが参照可能となります。[ドライブ共有設定の自動保存を行う]を設定した場合は本機能を使用いたしません。

設定

キャッシュを可能にする場合に、キャッシュの設定を選択します。

以下のいずれかの設定を選択します。「手動キャッシュ (BranchCacheを有効化)」には未対応です。

• 自動キャッシュ

  Windows OS における以下に該当します。Windows OS のバージョンにより表記が異なる場合があります。

  共有からユーザーが開いたファイルとプログラムは、すべて自動的にオフラインで利用可能にする
• 手動キャッシュ

  Windows OS における以下に該当します。Windows OS のバージョンにより表記が異なる場合があります。

  ユーザーが指定したファイルとプログラムのみ、オフラインで利用可能にする
• 自動キャッシュ (パフォーマンスを最適化)

  Windows OS における以下に該当します。Windows OS のバージョンにより表記が異なる場合があります。

  パフォーマンスが最適になるようにする

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

ユーザタブ

ユーザ数制限とアクセス許可についての詳細設定が表示されます。

ユーザ数制限 (1～9999)

共有フォルダに同時にアクセスするユーザ数の上限を設定します。

追加

ユーザアカウントまたはユーザグループに対するアクセス許可設定を [アクセス許可] 一覧に追加します。下記の [ユーザの入力] ダイアログボックスが表示されますので、ユーザ名と権限を新規に設定します。

削除

[アクセス許可] 一覧で選択したアクセス許可設定を削除します。

編集

[アクセス許可] 一覧で選択したアクセス許可設定を変更します。[ユーザの入力] ダイアログボックスが表示されます。選択したアクセス許可設定が下記の [ユーザの入力] ダイアログボックスに表示され、権限を変更することができます。

既定値

[既定値]をクリックすると全ての項目に既定値が設定されます。

ユーザ名 (255 バイト以内)

Windows のユーザ名またはグループ名を入力します。ドメインアカウントの場合は "ドメイン名\ユーザ名" の形式で入力します。ユーザ名に、2バイト文字は登録できません。半角スペースを含む名前は登録可能です(例：Domain Admins)。Windows のユーザ名またはグループ名に2バイト文字を使用する場合は、[ドライブ共有設定の自動保存を行う]をチェックしてください。

権限

入力したユーザ/グループのアクセス権限として、以下のいずれかの設定を選択します。

• フルコントロール

• 変更

• 読み取り

• なし

「なし」を設定した場合はアクセスが拒否されます。

3.17. ハイブリッドディスクリソースを理解する

3.17.1. ハイブリッドディスクリソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.17.2. ハイブリッドディスクとは?

ハイブリッドディスクリソースとは、ディスクリソースとミラーディスクリソースを組み合わせた リソースです。 ディスクリソースを使用する場合、フェイルオーバグループは同一の共有ディスク装置と接続されたクラスタサーバにのみフェイルオーバできますが、ハイブリッド ディスクでは共有ディスクのデータをミラーリング（同期／非同期）することにより、共有ディスク装置に接続されていないサーバにもフェイルオーバすることが可能です。 これにより、下図のような遠隔クラスタを構成し、通常の障害は現用系サイト内でフェイルオーバし、災害発生時は待機系サイトにフェイルオーバすることができます。 待機系サイトも共有ディスク構成で冗長化することができます。

図 3.106 ハイブリッド構成 (1)（通常時）

Server 1がダウンすると、Application は Server 2にフェイルオーバします。

図 3.107 ハイブリッド構成 (2)（Server 1ダウン）

Server 2がダウンすると、Application は Server 3にフェイルオーバします。

図 3.108 ハイブリッド構成 (3)（Server 2ダウン）

ハイブリッドディスクでは、共通の共有ディスク装置に接続されたサーバ群をサーバグループと呼び、 2 つのサーバグループ間でディスクミラーリングを行います。共有ディスク装置を使用しないサーバは、単一サーバのみのサーバグループとなります。

ミラーディスクリソースと同様、ミラーリングはパーティション単位で行われ、ミラーリング対象となるデータパーティションの他に、管理情報を記録するための RAW パーティション (クラスタパーティション) が必要です。また、ハイブリッドディスクリソースを使用する各 サーバに CLUSTERPRO X Replicator DR 5.0 for Windows のライセンスが必要です。

3.17.3. ハイブリッドディスクに関する注意事項

• データパーティションのサイズ

  ミラーリングを行うデータパーティションのサイズはバイト単位で完全に一致している必要があります。

  ディスクのタイプやジオメトリが異なると、パーティションサイズを揃えられない場合がありますが、この場合はハイブリッドディスクリソースを設定する前に [clpvolsz] コマンドにより両サーバのデータパーティションの正確なサイズを確認し、もしサイズが一致しない場合は再度 [clpvolsz] コマンドを使用して大きいほうのパーティションを縮小してください。

  [clpvolsz] コマンドについての詳細は本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「パーティションサイズを調整する (clpvolszコマンド)」を参照してください。

  データパーティションのサイズに制限はありません。
• データパーティションのコピー所要時間

  初期構築時やディスク交換時にフルコピーを行う際、ボリュームの利用領域のサイズに比例して所要時間が増加します。ボリュームの利用領域が特定できない場合は、ボリュームの全領域をコピーするため、データパーティションのサイズに比例して所要時間が増加します。
• クラスタパーティションのサイズ

  最低 1024MiB 確保してください。ディスクのジオメトリによって 1024MB 以上になる場合がありますが、1024MB 以上でも問題ありません。
• パーティションのドライブ文字

  データパーティションとクラスタパーティションには、各サーバでそれぞれ同一のドライブ文字を設定してください。

  また、ハイブリッドディスクリソース設定後はリソースを削除するまでドライブ文字を変更しないでください。ドライブ文字が変更された場合、ハイブリッドディスクリソースの起動時にドライブ文字を元に戻します。元のドライブ文字が他のパーティションで使用されている場合は、ミラーディスクリソースの起動に失敗します。
• パーティションの配置

  共有ディスク上のデータパーティションをミラーリングする場合、データパーティションとクラスタパーティションは同じ共有ディスク装置上に配置する必要があります (同じ論理ディスク上である必要はありません)。

  データパーティションとクラスタパーティションはベーシックディスク上に 割り当ててください。ダイナミックディスクはサポートしていません。

  データパーティションを拡張パーティション上の論理パーティションとして作成する場合は、 両サーバとも論理パーティションにしてください。基本パーティションと論理パーティションでは同じサイズを指定しても実サイズが若干異なることがあります。
• パーティションのフォーマット

  データパーティションは NTFS でフォーマットしてください。FAT/FAT32/exFAT はサポートしていません。

  クラスタパーティションにファイルシステムを構築しないでください。フォーマットしないでください。
• パーティションのアクセス制御

  ハイブリッドディスクリソースによりミラーリングされるデータパーティションは、ハイブリッドディスクリソースが活性化されている現用系サーバからのみアクセス可能になります。その他のサーバでは CLUSTERPRO によりアクセスが制限されます。

  また、クラスタパーティションへのアクセスも CLUSTERPRO により制限されます。
• パーティションの削除

  ハイブリッドディスクリソースのデータパーティション/クラスタパーティションを削除する場合は、事前に Cluster WebUI でハイブリッドディスクリソースを削除してください。
• サーバグループの設定

  ハイブリッドディスクリソースを持つフェイルオーバグループでは、ハイブリッドディスクリソースがミラーリングを行う 2 つのサーバグループを、グループのプロパティのサーバグループタブで登録する必要があります。これらのサーバグループの構成は Cluster WebUI の設定モードの Server Groups で設定します。
• ミラーディスク-ハイブリッドディスク間の構成変更

  ミラーディスクリソースでミラーリングしていたディスクをハイブリッドディスクリソースでミラーリングするように構成変更する場合、まず既存のミラーディスクリソースを削除した構成情報をして、既存のリソースが削除された状態に変更してから、ハイブリッドディスクリソースを追加した構成情報をアップロードしてください。
• ハイブリッドディスクを構成するディスク装置

  ハイブリッドディスクリソースのデータパーティションおよびクラスタパーティションには、全サーバで同一論理セクタサイズのディスク装置を使用してください。異なる論理セクタサイズのディスク装置を使用すると、正常に動作しません。データパーティションとクラスタパーティションでは論理セクタサイズが異なっていても動作可能です。

• 例)

組み合わせ	パーティションの論理セクタサイズ				説明
	サーバ1側	サーバ1側	サーバ2側	サーバ2側
	データパー ティション	クラスタパー ティション	データパー ティション	クラスタパー ティション
OK	512B	512B	512B	512B	論理セクタサイズが統一されている
OK	4KB	512B	4KB	512B	データパーティションで4KB、クラスタパーティションで512Bに統一されている
NG	4KB	512B	512B	512B	データパーティションの論理セクタサイズが統一されていない
NG	4KB	4KB	4KB	512B	クラスタパーティションの論理セクタサイズが統一されていない

• 自動ミラー初期構築がオフの場合

  [クラスタのプロパティ] - [ミラーディスク]タブ - [自動ミラー初期構築] をオフにしてハイブリッドディスクリソースを使用する場合、ハイブリッドディスクリソースの初回起動前に、ミラーディスクリストを使用してコピー元となるサーバグループのアイコンを緑に変更してください。

3.17.4. 詳細タブ

ハイブリッドディスク番号

ハイブリッドディスクリソースに割り当てるディスク番号を選択します。この番号は他のハイブリッドディスクリソースやミラーディスクリソースと異なる必要があります。

データパーティションのドライブ文字 (1023バイト以内)

データパーティションのドライブ文字 (A～Z) を設定します。

クラスタパーティションのドライブ文字(1023バイト以内)

クラスタパーティションのドライブ文字 (A～Z) を設定します。複数のハイブリッドディスクで同じクラスタパーティションを使うことができますが、ミラーディスクリソースのクラスタパーティションとは兼用できません。

クラスタパーティションのオフセットインデックス

クラスタパーティション内で使用する領域のインデックス番号を選択します。複数のハイブリッドディスクを使用する場合は、クラスタパーティション内で使用する領域が重ならないようハイブリッドディスク毎に異なるインデックス番号を割り当てます。

選択

データミラーリング通信に使用する通信経路 (ミラーディスクコネクト) を選択します。[ミラーディスクコネクトの選択] ダイアログボックスを表示します。

• 追加

  使用するミラーディスクコネクトを追加する場合に使用します。[利用可能なミラーディスクコネクト] から追加したいミラーディスクコネクトを選択して、[追加] をクリックします。 [ミラーディスクコネクト一覧] に追加します。
• 削除

  使用するミラーディスクコネクトを削除する場合に使用します。[ミラーディスクコネクト一覧] から削除したいサーバを選択して、[削除] をクリックします。[利用可能なミラーディスクコネクト] に追加されます。
• 順位

  ミラーディスクコネクトの優先順位を変更する場合に使用します。[利用可能なミラーディスクコネクト] から変更したいミラーディスクコネクトを選択して、矢印をクリックします。選択行が移動します。

ミラーディスクコネクトの設定については、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「インタコネクトタブ」を参照してください。

サーバグループ

フェイルオーバグループのプロパティのサーバグループタブで選択した 2 つのサーバグループの各メンバサーバの情報を表示します。

Cluster WebUI から、[情報取得] をクリックすると、各サーバのデータパーティションとクラスタパーティションの GUID 情報を取得することができます。

調整

[ハイブリッドディスクリソース調整プロパティ] ダイアログボックスを表示します。ハイブリッドディスクリソースの詳細設定を行います。

ハイブリッドディスクリソース調整プロパティ

ミラータブ

ミラーに関する詳細設定が表示されます。

この設定画面の各パラメータはミラーディスクリソースと共通です。

各パラメータの意味と設定方法については「 ミラーディスクリソースを理解する 」を参照してください。

3.17.5. ハイブリッドディスクリソース運用に関する注意事項

両サーバグループでミラーデータが同期している状態からクラスタシャットダウンした場合、その後は以下に述べるいずれかの順序でサーバ起動を行ってください。

• 両サーバグループに属するサーバを少なくとも1台ずつ、同時に起動する

• サーバグループ1に属するサーバ（サーバ1台目）を起動し、サーバ1台目が起動した状態のまま、サーバグループ2に属するサーバ（サーバ2台目）を起動する

サーバ起動とシャットダウンを1台ずつ交互に行う 6 ことは避けてください。

各サーバグループが保持するミラーデータの最新/非最新は、サーバ同士の通信によって判断されます。前述 6 の操作を行った場合、ミラーデータの最新/非最新を正確に判断されなくなるため、次回の両サーバグループのサーバ起動時にハイブリッドディスクリソースの起動に失敗します。

6(1,2)

サーバグループ1に属するサーバ（サーバ1台目）を起動しシャットダウンしたのち、サーバグループ2に属するサーバ（サーバ2台目）を起動しシャットダウンする。

3.18. AWS Elastic IPリソースを理解する

3.18.1. AWS Elastic IPリソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.18.2. AWS Elastic IPリソースとは?

本リソースを利用することで、Amazon Web Services(以下、AWS) 環境の Amazon Virtual Private Cloud(以下、VPC)を使用した CLUSTERPRO による HA クラスタ構築が可能です。

同環境下で、より重要な業務を行うことが可能となり AWS 環境におけるシステム構成の選択肢が広がります。AWS は地域(リージョン)ごとに複数の Availability Zone(以下、AZ)で堅牢に構成されており、利用者は必要に応じて AZ を選択して使用できます。CLUSTERPRO は複数の AZ 間(以下、Multi-AZ) で HA クラスタを可能とするため、業務の高可用性を実現します。

データミラー方式による「VIP 制御による HA クラスタ」 と 「EIP 制御による HA クラスタ」の2種類のHAクラスタを想定しています。本節では Elastic IP(以下、EIP)制御による HA クラスタの場合に使用する AWS Elastic IPリソースについて記載します。

AWS Elastic IPリソース、AWS 仮想IPリソース、AWS セカンダリ IP リソース、AWS DNS リソースは組み合わせて使用可能です。

EIP 制御による HA クラスタ

インスタンスを Public な Subnet 上に配置する(業務を VPC の外部に公開する)場合に使用します。

クラスタ化するインスタンスは各 AZ の Public な Subnet 上に配置されており、各インスタンスは、インターネットゲートウェイを経由してインターネットへアクセスできるような構成を想定しています。

図 3.109 AWS Elastic IP リソースを使用する構成

3.18.3. AWS Elastic IPリソースに関する注意事項

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS Elastic IPリソースの設定について」を参照してください。

3.18.4. AWS Elastic IPリソースから実行するAWS CLIへ環境変数を反映させるには

環境変数設定ファイルに環境変数を指定することにより、以下の AWS 関連リソースから実行する AWS CLI に反映させることが可能です。

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS DNS リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS DNS 監視リソース

• AWS 強制停止リソース

AWS環境にて、プロキシサーバを利用する場合などに有効です。

環境変数設定ファイルは、以下に配置しています。

環境変数設定ファイルが存在しない場合は該当ファイルを作成してください。

<CLUSTERPROインストールパス>\cloud\aws\clpaws_setting.conf

環境変数設定ファイルのフォーマットは、以下のとおりです。

環境変数名 = 値

記載例)

[ENVIRONMENT]
HTTP_PROXY = http://10.0.0.1:3128
HTTPS_PROXY = http://10.0.0.1:3128

パラメータに複数の値を設定する場合は、カンマ区切り(,)で列挙してください。環境変数 NO_PROXY に除外接続先を複数指定する場合の記載例は以下となります。

記載例)

NO_PROXY = 169.254.169.254,ec2.ap-northeast-1.amazonaws.com

環境変数設定ファイルの仕様は、以下のとおりです。

• 一行目は必ず [ENVIRONMENT] を記載してください。記載がない場合は、環境変数は設定しません。

• 環境変数設定ファイルが存在しない場合や読み取り権限がない場合は無視します。活性異常や監視異常にはなりません。

• 同名の環境変数が既に設定されている場合、値を上書きします。

• 複数の環境変数の設定が可能です。複数の環境変数を設定する場合は、1行には1つの環境変数のみ設定してください。

• = の両側のスペース有無に関わらず、設定は有効です。

• 環境変数名の前にスペースやタブがある場合および = の両側にタブがある場合、設定は無効です。

• 環境変数名は大文字・小文字を区別します。

• 値にスペースが入る場合、""(ダブルクォート)で括る必要はありません。

• 環境変数設定ファイルで設定した環境変数は前述の AWS 関連リソースから実行する AWS CLI にのみ反映されます。そのため、それ以外のスクリプト(例.最終動作前スクリプト、活性/非活性前後スクリプト、スクリプトリソースから実行するスクリプト)には反映されません。それ以外のスクリプト内で AWS CLI を実行する場合、必要な環境変数は該当するスクリプト内で設定してください。

3.18.5. 詳細タブ

EIP ALLOCATION ID (45バイト以内)

EIP 制御の場合、付け替え対象の EIP の ID を指定します。

ENI ID (45バイト以内)

EIP 制御の場合、EIP を割り当てる ENI ID を指定します。サーバ別の設定が必須です。サーバ共通設定画面では、任意のサーバのENI IDを記載し、他のサーバは個別設定を行うようにしてください。

調整

[AWS Elastic IPリソース調整プロパティ] ダイアログボックスを表示します。AWS Elastic IPリソースの詳細設定を行います。

AWS Elastic IP リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

タイムアウト (1～999)

AWS Elastic IPリソースの活性/非活性の各処理で実行される [AWS CLI] コマンドのタイムアウトを設定します。

3.19. AWS 仮想IPリソースを理解する

3.19.1. AWS 仮想IPリソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.19.2. AWS 仮想IPリソースとは?

本リソースを利用することで、Amazon Web Services(以下、AWS) 環境の Amazon Virtual Private Cloud(以下、VPC)を使用した CLUSTERPRO による HA クラスタ構築が可能です。

同環境下で、より重要な業務を行うことが可能となり AWS 環境におけるシステム構成の選択肢が広がります。AWS は地域(リージョン)ごとに複数の Availability Zone(以下、AZ)で堅牢に構成されており、利用者は必要に応じて AZ を選択して使用できます。CLUSTERPRO は複数の AZ 間(以下、Multi-AZ) で HA クラスタを可能とするため、業務の高可用性を実現します。

AWS仮想IPリソースでは活性時に AWS CLI を実行して route table の更新処理を行います。

データミラー方式による「VIP 制御による HA クラスタ」 と 「EIP 制御による HA クラスタ」の2種類のHAクラスタを想定しています。本節では 仮想IP(以下、vip)制御による HA クラスタの場合に使用する AWS 仮想IPリソースについて記載します。

AWS Elastic IPリソース、AWS 仮想IPリソース、AWS セカンダリ IP リソース、AWS DNS リソースは組み合わせて使用可能です。

VIP 制御による HA クラスタ

インスタンスを Private な Subnet 上に配置する(業務を VPC 内部に公開する)場合に使用します。

クラスタ化するインスタンス及び、そのインスタンスへアクセスを行うインスタンス群は各 AZ の Private な Subnet 上に配置されており、各インスタンスは、Public な Subnet に配置された NAT インスタンス を経由してインターネットへアクセスできるような構成を想定しています。

図 3.110 AWS 仮想 IP リソースを使用する構成

3.19.3. AWS 仮想IPリソースに関する注意事項

• 『スタートアップガイド』 の 「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS 仮想IPリソースの設定について」を参照してください。

3.19.4. AWS 仮想IPリソースから実行するAWS CLIへ環境変数を反映させるには

環境変数設定ファイルに環境変数を指定することにより、以下の AWS 関連リソースから実行する AWS CLI に反映させることが可能です。

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS DNS リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS DNS 監視リソース

• AWS 強制停止リソース

AWS環境にて、プロキシサーバを利用する場合などに有効です。

環境変数設定ファイルは、以下に配置しています。

環境変数設定ファイルが存在しない場合は該当ファイルを作成してください。

<CLUSTERPROインストールパス>\cloud\aws\clpaws_setting.conf

環境変数設定ファイルのフォーマットは、以下のとおりです。

環境変数名 = 値

記載例)

[ENVIRONMENT]
HTTP_PROXY = http://10.0.0.1:3128
HTTPS_PROXY = http://10.0.0.1:3128

パラメータに複数の値を設定する場合は、カンマ区切り(,)で列挙してください。環境変数 NO_PROXY に除外接続先を複数指定する場合の記載例は以下となります。

記載例)

NO_PROXY = 169.254.169.254,ec2.ap-northeast-1.amazonaws.com

環境変数設定ファイルの仕様は、以下のとおりです。

• 一行目は必ず [ENVIRONMENT] を記載してください。記載がない場合は、環境変数は設定しません。

• 環境変数設定ファイルが存在しない場合や読み取り権限がない場合は無視します。活性異常や監視異常にはなりません。

• 同名の環境変数が既に設定されている場合、値を上書きします。

• 複数の環境変数の設定が可能です。複数の環境変数を設定する場合は、1行には1つの環境変数のみ設定してください。

• = の両側のスペース有無に関わらず、設定は有効です。

• 環境変数名の前にスペースやタブがある場合および = の両側にタブがある場合、設定は無効です。

• 環境変数名は大文字・小文字を区別します。

• 値にスペースが入る場合、""(ダブルクォート)で括る必要はありません。

• 環境変数設定ファイルで設定した環境変数は前述の AWS 関連リソースから実行する AWS CLI にのみ反映されます。そのため、それ以外のスクリプト(例.最終動作前スクリプト、活性/非活性前後スクリプト、スクリプトリソースから実行するスクリプト)には反映されません。それ以外のスクリプト内で AWS CLI を実行する場合、必要な環境変数は該当するスクリプト内で設定してください。

3.19.5. 詳細タブ

IPアドレス (45バイト以内)

VIP 制御の場合、使用する VIP アドレスを指定します。VIP アドレスとしては、VPC の CIDR に属さない IP アドレスを指定する必要があります。

VPC ID (45バイト以内)

VIP 制御の場合、サーバが所属する VPC ID を指定します。サーバ個別設定を行う場合、[共通]タブでは、任意のサーバの VPC ID を記載し、他のサーバは個別設定を行うようにしてください。

ENI ID (45バイト以内)

VIP 制御の場合、VIPのルーティング先の ENI ID を指定します。指定する ENI ID は Source/Dest. Check を disabled としておく必要があります。サーバ別の設定が必須です。[共通]タブでは、任意のサーバの ENI ID を記載し、他のサーバは個別設定を行うようにしてください。

調整

[AWS 仮想IPリソース調整プロパティ] ダイアログボックスを表示します。AWS 仮想IPリソースの詳細設定を行います。

AWS 仮想 IP リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

タイムアウト (1～999)

AWS 仮想IPリソースの活性/非活性の各処理で実行される [AWS CLI] コマンドのタイムアウトを設定します。

3.20. AWS セカンダリ IP リソースを理解する

3.20.1. AWS セカンダリ IP リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.20.2. AWS セカンダリ IP リソースとは?

クライアントアプリケーションは、AWS 環境の VPC に対して、セカンダリ IP アドレスを使用してクラスタサーバに接続することができます。

セカンダリ IP アドレスを使用することにより、"フェイルオーバ" または、"グループの移動" が発生しても、クライアントは、接続先 VPC の切り替えを意識する必要がありません。

AWS セカンダリ IP リソースでは活性時にセカンダリ IP アドレスの割り当て処理、非活性時にセカンダリ IP アドレスの割り当て解除処理を行います。

AWS Elastic IPリソース、AWS 仮想IPリソース、AWS セカンダリ IP リソース、AWS DNS リソースは組み合わせて使用可能です。

セカンダリ IP 制御による HA クラスタ

インスタンスを Private な Subnet 上に配置する(業務を VPC 内部に公開する)場合に使用します。

クラスタ化するインスタンス及び、そのインスタンスへアクセスを行うインスタンス群は各 AZ の Private な Subnet 上に配置されており、各インスタンスは、Public な Subnet に配置された NAT インスタンス を経由してインターネットへアクセスできるような構成を想定しています。

図 3.111 AWS セカンダリ IP リソースを使用する構成

注釈

図中の SIP はセカンダリ IP アドレスを指します。

3.20.3. AWS セカンダリ IP リソースに関する注意事項

• 『スタートアップガイド』 の 「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS セカンダリ IP リソースの設定について」を参照してください。

3.20.4. AWS セカンダリ IP リソースから実行するAWS CLIへ環境変数を反映させるには

環境変数設定ファイルに環境変数を指定することにより、以下の AWS 関連リソースから実行する AWS CLI に反映させることが可能です。

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS DNS リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS DNS 監視リソース

• AWS 強制停止リソース

AWS環境にて、プロキシサーバを利用する場合などに有効です。

環境変数設定ファイルは、以下に配置しています。

環境変数設定ファイルが存在しない場合は該当ファイルを作成してください。

<CLUSTERPROインストールパス>\cloud\aws\clpaws_setting.conf

環境変数設定ファイルのフォーマットは、以下のとおりです。

環境変数名 = 値

記載例)

[ENVIRONMENT]
HTTP_PROXY = http://10.0.0.1:3128
HTTPS_PROXY = http://10.0.0.1:3128

パラメータに複数の値を設定する場合は、カンマ区切り(,)で列挙してください。環境変数 NO_PROXY に除外接続先を複数指定する場合の記載例は以下となります。

記載例)

NO_PROXY = 169.254.169.254,ec2.ap-northeast-1.amazonaws.com

環境変数設定ファイルの仕様は、以下のとおりです。

• 一行目は必ず [ENVIRONMENT] を記載してください。記載がない場合は、環境変数は設定しません。

• 環境変数設定ファイルが存在しない場合や読み取り権限がない場合は無視します。活性異常や監視異常にはなりません。

• 同名の環境変数が既に設定されている場合、値を上書きします。

• 複数の環境変数の設定が可能です。複数の環境変数を設定する場合は、1行には1つの環境変数のみ設定してください。

• = の両側のスペース有無に関わらず、設定は有効です。

• 環境変数名の前にスペースやタブがある場合および = の両側にタブがある場合、設定は無効です。

• 環境変数名は大文字・小文字を区別します。

• 値にスペースが入る場合、""(ダブルクォート)で括る必要はありません。

• # の位置に関わらず # を記載している行の環境変数は設定しません。

• 環境変数設定ファイルで設定した環境変数は前述の AWS 関連リソースから実行する AWS CLI にのみ反映されます。そのため、それ以外のスクリプト(例.最終動作前スクリプト、活性/非活性前後スクリプト、スクリプトリソースから実行するスクリプト)には反映されません。それ以外のスクリプト内で AWS CLI を実行する場合、必要な環境変数は該当するスクリプト内で設定してください。

3.20.5. 詳細タブ

IPアドレス (45バイト以内)

使用するセカンダリ IP アドレスを指定します。セカンダリ IP アドレスとしては、インスタンスが属するサブネットのネットワーク内の IP アドレスを指定する必要があります。

ENI ID (45バイト以内)

セカンダリ IP アドレスを割り当てるネットワークインターフェイスの ENI ID を指定します。サーバ別設定が必須です。サーバ個別設定を行う場合、[共通]タブでは、任意のサーバの ENI ID を記載し、他のサーバは個別設定を行うようにしてください。

調整

[AWS セカンダリ IP リソース調整プロパティ] ダイアログボックスを表示します。AWS セカンダリ IP リソースの詳細設定を行います。

AWS セカンダリ IP リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

起動タイムアウト (1～9999)

AWS セカンダリ IP リソースの活性時に使われるスクリプトのタイムアウトを設定します。

停止タイムアウト (1～9999)

AWS セカンダリ IP リソースの非活性時に使われるスクリプトのタイムアウトを設定します。

3.21. AWS DNS リソースを理解する

3.21.1. AWS DNS リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.21.2. AWS DNS リソースとは?

図 3.112 AWS DNSリソースを使用する構成

Amazon Web Services(以下、AWS) で利用する仮想ホスト名(DNS 名)に対応する IP アドレスを活性時に AWS CLI を実行して登録、非活性時 AWS CLI を実行して削除します。

クライアントはフェイルオーバグループが起動しているノードに仮想ホスト名でアクセスすることができます。

AWS DNS リソースを利用することで、クライアントは AWS 上でもフェイルオーバやグループの移動による接続先ノードの切り替えを意識する必要がありません。

AWS Elastic IPリソース、AWS 仮想IPリソース、AWS セカンダリ IP リソース、AWS DNS リソースは組み合わせて使用可能です。

AWS DNS リソースを利用する場合、クラスタの構築を行う前に以下の準備が必要です。

• Amazon Route 53 の Hosted Zone の作成

• AWS CLI のインストール

3.21.3. AWS DNS リソースの活性タイミング

本リソースはDNS レコードへのアップデートがAmazon Route 53へ反映されるまで待機した後に活性状態へと移行します。

注釈

本機能はCLUSTERPRO X 5.0 を新規インストールした場合のみ有効な機能です。

CLUSTERPRO X 4.3 以前からアップデートを行った場合に本機能を有効にするには本リソースを削除し再設定してください。

3.21.4. AWS DNS リソースに関する注意事項

• クライアントから仮想ホスト名(DNS 名)を使用して接続を行っている場合、AWS DNS リソースが追加されているフェイルオーバグループでフェイルオーバが発生すると再接続が必要な場合があります。

• 『スタートアップガイド』 の 「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS DNS リソースの設定について」を参照してください。

3.21.5. AWS DNS リソースから実行するAWS CLIへ環境変数を反映させるには

環境変数設定ファイルに環境変数を指定することにより、以下の AWS 関連リソースから実行する AWS CLI に反映させることが可能です。

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS DNS リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS DNS 監視リソース

• AWS 強制停止リソース

AWS環境にて、プロキシサーバを利用する場合などに有効です。

環境変数設定ファイルは、以下に配置しています。

環境変数設定ファイルが存在しない場合は該当ファイルを作成してください。

<CLUSTERPROインストールパス>\cloud\aws\clpaws_setting.conf

環境変数設定ファイルのフォーマットは、以下のとおりです。

環境変数名 = 値

記載例)

[ENVIRONMENT]
HTTP_PROXY = http://10.0.0.1:3128
HTTPS_PROXY = http://10.0.0.1:3128

パラメータに複数の値を設定する場合は、カンマ区切り(,)で列挙してください。環境変数 NO_PROXY に除外接続先を複数指定する場合の記載例は以下となります。

記載例)

NO_PROXY = 169.254.169.254,ec2.ap-northeast-1.amazonaws.com

環境変数設定ファイルの仕様は、以下のとおりです。

• 一行目は必ず [ENVIRONMENT] を記載してください。記載がない場合は、環境変数は設定しません。

• 環境変数設定ファイルが存在しない場合や読み取り権限がない場合は無視します。活性異常や監視異常にはなりません。

• 同名の環境変数が既に設定されている場合、値を上書きします。

• 複数の環境変数の設定が可能です。複数の環境変数を設定する場合は、1行には1つの環境変数のみ設定してください。

• = の両側のスペース有無に関わらず、設定は有効です。

• 環境変数名の前にスペースやタブがある場合および = の両側にタブがある場合、設定は無効です。

• 環境変数名は大文字・小文字を区別します。

• 値にスペースが入る場合、""(ダブルクォート)で括る必要はありません。

• 環境変数設定ファイルで設定した環境変数は前述の AWS 関連リソースから実行する AWS CLI にのみ反映されます。そのため、それ以外のスクリプト(例.最終動作前スクリプト、活性/非活性前後スクリプト、スクリプトリソースから実行するスクリプト)には反映されません。それ以外のスクリプト内で AWS CLI を実行する場合、必要な環境変数は該当するスクリプト内で設定してください。

3.21.6. 詳細タブ

ホストゾーンID (255バイト以内)

Amazon Route 53 の Hosted Zone ID を入力します。

リソースレコードセット名 (255バイト以内)

DNS A レコード名を入力します。レコード名の末尾にはドット (.) を付けてください。[リソースレコードセット名] にエスケープコードを含む場合、監視が異常になります。エスケープコードを含まない [リソースレコードセット名] を設定してください。[リソースレコードセット名] は小文字で指定してください。

IPアドレス (39バイト以内)

仮想ホスト名(DNS 名)に対応する IP アドレスを入力します(IPv4)。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力します。サーバ別の設定を行う場合は[共通]タブでは、任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

TTL (0～2147483647)

キャッシュの生存期間(TTL=Time To Liveの略)を入力します。

非活性時にリソースレコードセットを削除する

• チェックボックスがオン

  非活性時にレコードセットを削除します。
• チェックボックスがオフ(既定)

  非活性時にレコードセットを削除しません。削除しない場合、残存した仮想ホスト名(DNS 名)にクライアントからアクセスされる可能性があります。

調整

[AWS DNS リソース調整プロパティ] ダイアログボックスを表示します。AWS DNS リソースの詳細設定を行います。

AWS DNS リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

タイムアウト (1～999)

AWS DNS リソースの活性/非活性の各処理で実行される [AWS CLI] コマンドのタイムアウトを設定します。

3.22. Azure プローブポートリソースを理解する

3.22.1. Azure プローブポートリソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.22.2. Azure プローブポートリソースとは?

クライアントアプリケーションは、Microsoft Azure 環境の可用性セット上の仮想マシンに対して、パブリック仮想 IPアドレス(以下、VIP と記載)を使用してクラスタサーバに接続することができます。VIP アドレスを使用することにより、"フェイルオーバ" または、"グループの移動" が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。

図 3.113 Azure プローブポートリソースを使用する構成

上記図の Microsoft Azure 環境上に構築したクラスタには、VIPというグローバルな IP アドレスと外部から通信するためのエンドポイント、または DNS 名と外部から通信するためのエンドポイントを指定してアクセスします。 クラスタの現用系と待機系は、CLUSTERPRO から Microsoft Azure のロードバランサ(上記図の Load Balancer)を制御して切り替えます。制御には、Health Check を利用します。

活性時に Microsoft Azure のロードバランサからの死活監視(プローブ ポートへのアクセス)を待ち受けるためのプローブポート制御プロセスを起動します。

非活性時には死活監視(プローブ ポートへのアクセス)を待ち受けるためのプローブポート制御プロセスを停止します。

Azure プローブポートリソースでは Microsoft Azure の内部負荷分散(Internal Load Balancing)にも対応しています。内部負荷分散の場合、VIPは Azure のプライベートIPアドレスとなります。

図 3.114 Azure プローブポートリソースを使用する構成（内部負荷分散）

3.22.3. Azure プローブポートリソースに関する注意事項

• プライベート ポートとプローブ ポートが同じ場合、Azure プローブポートリソース、Azure プローブポート監視リソースの追加は不要です。

• 『スタートアップガイド』 の 「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Azure プローブポートリソースの設定について」を参照してください。

3.22.4. 詳細タブ

プローブポート (1～65535)

Azure のロードバランサが、各サーバの死活監視に使用するポート番号を指定します。エンドポイント作成時に ProbePort に指定した値を指定してください。プローブ プロトコルには TCP を指定してください。

調整

[Azure プローブポートリソース調整プロパティ] ダイアログボックスを表示します。Azure プローブポートリソースの詳細設定を行います。

Azure プローブポートリソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

プローブ 待ち受けのタイムアウト (5～999999999)

Azure のロードバランサからの死活監視を待つタイムアウト時間を指定します。Azure のロードバランサから定期的に死活監視されているかを確認します。

3.23. Azure DNS リソースを理解する

3.23.1. Azure DNS リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.23.2. Azure DNS リソースとは?

図 3.115 Azure DNSリソースを使用する構成

Azure DNS リソースは、仮想ホスト名(DNS名)から設定した IP アドレスを得られるように Azure DNS のレコードセットや DNS A レコードの制御を行います。

クライアントはフェイルオーバグループが起動しているノードに仮想ホスト名(DNS 名)でアクセスすることができます。

Azure DNS リソースを利用することで、クライアントは Microsoft Azure 上でもフェイルオーバやグループの移動による接続先ノードの切り替えを意識する必要がありません。

Azure DNS リソースを利用する場合、クラスタの構築を行う前に以下の準備が必要です。詳細は『CLUSTERPRO X Microsoft Azure 向け HA クラスタ 構築ガイド（Windows 版）』を参照してください。

• Microsoft Azure のリソースグループ、DNS ゾーンの作成

• Azure CLI のインストール

3.23.3. Azure DNS リソースに関する注意事項

• クライアントから仮想ホスト名(DNS 名)を使用して接続を行っている場合、Azure DNS リソースが追加されているフェイルオーバグループでフェイルオーバが発生すると再接続が必要な場合があります。

• 『スタートアップガイド』 の 「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Azure DNS リソースの設定について」を参照してください。

• 『スタートアップガイド』 の 「注意制限事項」 - 「CLUSTERPROインストール前」 - 「Azure DNS リソースについて」を参照してください。

3.23.4. 詳細タブ

レコードセット名 (253バイト以内)

Azure DNS の A レコードを登録するレコードセット名を入力します。

ゾーン名 (253バイト以内)

Azure DNS のレコードセットが所属する DNS ゾーン名を入力します。

IPアドレス (39バイト以内)

仮想ホスト名(DNS 名)に対応する IP アドレスを入力します(IPv4)。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力します。サーバ別の設定を行う場合は[共通]タブでは、任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

TTL (0～2147483647)

キャッシュの生存期間(TTL=Time To Liveの略)を入力します。

リソースグループ名 (180バイト以内)

DNS ゾーンが所属する Microsoft Azure のリソース グループ名を入力します。

ユーザURI (2083バイト以内)

Microsoft Azure ログイン用のユーザ URI を入力します。

テナントID (36バイト以内)

Microsoft Azure ログイン用の tenantId を入力します。

サービスプリンシパルのファイルパス (1023バイト以内)

Microsoft Azure ログイン用のサービス プリンシパルファイル名(証明書のファイル名)を入力します。ドライブ名含め絶対パスで指定してください。

Azure CLI ファイルパス (1023バイト以内)

Azure CLI のインストールパスおよびファイル名を入力します。ドライブ名含め絶対パスで指定してください(拡張子含む)。

非活性時にレコードセットを削除する

• チェックボックスがオン(既定)

  非活性時にレコードセットを削除します。
• チェックボックスがオフ

  非活性時にレコードセットを削除しません。削除しない場合、残存した仮想ホスト名(DNS 名)にクライアントからアクセスされる可能性があります。

調整

[Azure DNS リソース調整プロパティ] ダイアログボックスを表示します。Azure DNS リソースの詳細設定を行います。

Azure DNS リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

タイムアウト (1～999)

Azure DNS リソースの活性/非活性の各処理で実行される [Azure CLI] コマンドのタイムアウトを設定します。

3.24. Google Cloud 仮想 IP リソースを理解する

3.24.1. Google Cloud 仮想 IP リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.24.2. Google Cloud 仮想 IP リソースとは?

クライアントアプリケーションは、Google Cloud Platform 環境の仮想マシンに対して、仮想 IP アドレス(以下、VIP と記載)を使用してクラスターを構成するノードに接続することができます。VIP アドレスを使用することにより、フェイルオーバーまたは、グループの移動が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。

図 3.116 Google Cloud 仮想 IP リソースを使用する構成

上記図の Google Cloud Platform 環境上に構築したクラスターには、VIP と外部から通信するためのポート、または DNS 名と外部から通信するためのポートを指定してアクセスします。 クラスターの現用系と待機系は、CLUSTERPRO から Google Cloud Platform のロードバランサ(上記図の Cloud Load Balancing)を制御して切り替えます。制御には上記図の、Health Check を利用します。

活性時に Google Cloud Platform のロードバランサからのヘルスチェックを待ち受けるための制御プロセスを起動し、[ポート番号] で指定したポートをオープンします。

非活性時にはヘルスチェックを待ち受けるための制御プロセスを停止し、[ポート番号] で指定したポートをクローズします。

Google Cloud 仮想 IP リソースでは Google Cloud Platform の内部負荷分散に対応しています。

3.24.3. Google Cloud 仮想 IP リソースに関する注意事項

• GCP の仕様により、外部 TCP ネットワーク負荷分散では HTTP プロトコルを使用するレガシー ヘルスチェックが要求されます。

  Google Cloud 仮想 IP リソースは、TCP プロトコルを使用するヘルスチェックにのみ対応しているため、外部 TCP ネットワークロードバランサからのヘルスチェックに応答できません。

  そのため、外部 TCP ネットワークロードバランサによる Google Cloud 仮想 IP リソースを使用したHAクラスターはご利用になれません。内部 TCP ロードバランサをご利用ください。

  以下を参照してください。

  ヘルスチェックのコンセプト:

  https://cloud.google.com/load-balancing/docs/health-check-concepts/

• プライベート ポートとヘルスチェックのポートが同じ場合、Google Cloud 仮想 IP リソース、Google Cloud 仮想 IP モニタリソースの追加は不要です。

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Google Cloud 仮想 IP リソースの設定について」を参照してください。

3.24.4. 詳細タブ

ポート番号 (1～65535)

Google Cloud Platform のロードバランサが、各ノードのヘルスチェックに使用するポート番号を指定します。ロードバランサのヘルスチェック設定時にポートに指定した値を指定してください。ロードバランサは [TCP 負荷分散] を指定してください。

調整

[Google Cloud 仮想 IP リソース調整プロパティ] ダイアログボックスを表示します。Google Cloud 仮想 IP リソースの詳細設定を行います。

Google Cloud 仮想 IP リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

ヘルスチェックのタイムアウト (5～999999999)

Google Cloud Platform のロードバランサからのヘルスチェックを待つタイムアウト時間を指定します。Google Cloud Platform のロードバランサから定期的にヘルスチェックされているかを確認します。

3.25. Google Cloud DNS リソースを理解する

3.25.1. Google Cloud DNS リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.25.2. Google Cloud DNS リソースとは?

Google Cloud DNS リソースは、仮想ホスト名(DNS名)から設定した IP アドレスを得られるように Google Cloud DNS のレコードセットや DNS A レコードの制御を行います。

クライアントはフェイルオーバグループが起動しているノードに仮想ホスト名(DNS 名)でアクセスすることができます。

Google Cloud DNS リソースを利用することで、クライアントは Google Cloud Platform 上でもフェイルオーバやグループの移動による接続先ノードの切り替えを意識する必要がありません。

3.25.3. Google Cloud DNS リソースに関する注意事項

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Google Cloud DNS リソースの設定について」を参照してください。

• 『スタートアップガイド』の「注意制限事項」 - 「OSインストール後、CLUSTERPROインストール前」 - 「Google Cloud DNS リソースについて」を参照してください。

3.25.4. 詳細タブ

ゾーン名 (63バイト以内)

Google Cloud DNS のレコードセットが所属する DNS ゾーン名を入力します。

DNS名 (253バイト以内)

Google Cloud DNS に登録する A レコードの DNS 名を入力します。

IPアドレス (39バイト以内) サーバ個別設定可能

仮想ホスト名(DNS 名)に対応する IP アドレスを入力します(IPv4)。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力します。サーバ別の設定を行う場合は[共通]タブでは、任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

TTL (0～2147483647)

キャッシュの生存期間(TTL=Time To Liveの略)を入力します。

非活性時にレコードセットを削除する

• チェックボックスがオン(既定)

  非活性時にレコードセットを削除します。
• チェックボックスがオフ

  非活性時にレコードセットを削除しません。削除しない場合、残存した仮想ホスト名(DNS 名)にクライアントからアクセスされる可能性があります。

3.26. Oracle Cloud 仮想 IP リソースを理解する

3.26.1. Oracle Cloud 仮想 IP リソースの依存関係

既定値では、依存するグループリソースタイプはありません。

3.26.2. Oracle Cloud 仮想 IP リソースとは?

クライアントアプリケーションは、Oracle Cloud Infrastructure 環境の仮想マシンに対して、パブリック仮想 IP アドレス(以下、VIP と記載)を使用してクラスターを構成するノードに接続することができます。VIP アドレスを使用することにより、フェイルオーバーまたは、グループの移動が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。

図 3.118 Oracle Cloud 仮想IPリソースを使用する構成

上記図の Oracle Cloud Infrastructure 環境上に構築したクラスターには、VIP というグローバルな IP アドレスと外部から通信するためのポート、または DNS 名と外部から通信するためのポートを指定してアクセスします。 クラスターの現用系と待機系は、CLUSTERPRO から Oracle Cloud Infrastructure のロードバランサ(上記図の Load Balancer)を制御して切り替えます。制御には上記図の、Health Check を利用します。

活性時に Oracle Cloud Infrastructure のロードバランサからのヘルスチェックを待ち受けるための制御プロセスを起動し、[ポート番号] で指定したポートをオープンします。

非活性時にはヘルスチェックを待ち受けるための制御プロセスを停止し、[ポート番号] で指定したポートをクローズします。

Oracle Cloud 仮想 IP リソースでは Oracle Cloud Infrastructure のプライベート・ロード・バランサにも対応しています。プライベート・ロード・バランサの場合、VIP は Oracle Cloud Infrastructure のプライベート IP アドレスとなります。

図 3.119 Oracle Cloud 仮想IPリソースを使用する構成（プライベートロードバランサ）

3.26.3. Oracle Cloud 仮想 IP リソースに関する注意事項

• プライベート ポートとヘルスチェックのポートが同じ場合、Oracle Cloud 仮想 IP リソース、Oracle Cloud 仮想 IP モニタリソースの追加は不要です。

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Oracle Cloud 仮想 IP リソースの設定について」を参照してください。

3.26.4. 詳細タブ

ポート番号 (1～65535)

Oracle Cloud Infrastructure のロードバランサが、各ノードのヘルスチェックに使用するポート番号を指定します。バックエンド・セットのヘルスチェック設定時にポートに指定した値を指定してください。ヘルスチェックのプロトコルは TCP を指定してください。

調整

[Oracle Cloud 仮想 IP リソース調整プロパティ] ダイアログボックスを表示します。Oracle Cloud 仮想 IP リソースの詳細設定を行います。

Oracle Cloud 仮想 IP リソース調整プロパティ

パラメータタブ

パラメータに関する詳細設定が表示されます。

ヘルスチェックのタイムアウト (5～999999999)

Oracle Cloud Infrastructure のロードバランサからのヘルスチェックを待つタイムアウト時間を指定します。Oracle Cloud Infrastructure のロードバランサから定期的にヘルスチェックされているかを確認します。