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

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

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

• 3.1. グループリソースの一覧と対応する CLUSTERPRO のバージョン

• 3.2. グループとは？

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

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

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

• 3.6. EXEC リソースを理解する

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

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

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

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

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

• 3.12. ボリュームマネージャリソースを理解する

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

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

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

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

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

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

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

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

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

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

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

3.1. グループリソースの一覧と対応する CLUSTERPRO のバージョン

各グループに登録することができるグループリソース数は以下のとおりです。

バージョン	グループリソース数(1 グループあたり)
4.0.0-1～	256

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

グループリソース名	略称	機能概要	対応バージョン
EXEC リソース	exec	「 EXEC リソースを理解する 」を参照	4.0.0-1～
ディスクリソース	disk	「 ディスクリソースを理解する 」を参照	4.0.0-1～
フローティング IP リソース	fip	「 フローティング IP リソースを理解する 」を参照	4.0.0-1～
仮想 IP リソース	vip	「 仮想 IP リソースを理解する 」を参照	4.0.0-1～
ミラーディスクリソース	md	「 ミラーディスクリソースを理解する 」を参照	4.0.0-1～
ハイブリッドディスクリソース	hd	「 ハイブリッドディスクリソースを理解する 」を参照	4.0.0-1～
ボリュームマネージャリソース	volmgr	「 ボリュームマネージャリソースを理解する」を参照	4.0.0-1～
ダイナミック DNS リソース	ddns	「 ダイナミック DNS リソースを理解する 」を参照	4.0.0-1～
AWS Elastic IP リソース	awseip	「 AWS Elastic IPリソースを理解する 」を参照	4.0.0-1～
AWS 仮想 IP リソース	awsvip	「 AWS 仮想IPリソースを理解する 」を参照	4.0.0-1～
AWS セカンダリ IP リソース	awssip	「 AWS セカンダリ IP リソースを理解する 」を参照	5.0.0-1～
AWS DNS リソース	awsdns	「 AWS DNS リソースを理解する 」を参照	4.0.0-1～
Azure プローブポートリソース	azurepp	「 Azure プローブポートリソースを理解する 」を参照	4.0.0-1～
Azure DNS リソース	azuredns	「 Azure DNS リソースを理解する 」を参照	4.0.0-1～
Google Cloud 仮想 IP リソース	gcvip	「 Google Cloud 仮想 IP リソースを理解する 」を参照	4.2.0-1～
Google Cloud DNS リソース	gcdns	「 Google Cloud DNS リソースを理解する 」を参照	4.3.0-1～
Oracle Cloud 仮想 IP リソース	ocvip	「 Oracle Cloud 仮想 IP リソースを理解する 」を参照	4.2.0-1～
Oracle Cloud DNS リソース	ocdns	「 Oracle Cloud DNS リソースを理解する 」を参照	5.2.0-1～

現在動的リソース追加をサポートしているグループリソースは以下のとおりです。

グループリソース名	略称	機能概要	対応バージョン
EXEC リソース	exec	「 EXEC リソースを理解する 」を参照	4.0.0-1～
ディスクリソース	disk	「 ディスクリソースを理解する 」を参照	4.0.0-1～
フローティング IP リソース	fip	「 フローティング IP リソースを理解する 」を参照	4.0.0-1～
仮想 IP リソース	vip	「 仮想 IP リソースを理解する 」を参照	4.0.0-1～
ボリュームマネージャリソース	volmgr	「 ボリュームマネージャリソースを理解する」を参照	4.0.0-1～

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 と Group B が排他ルールに所属していない場合

図 3.1 各サーバの状態とGroup A、Group Bの起動状況

1. クラスタの立ち上げ

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

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

4. Server 1 の電源 ON

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

6. Group A の移動

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

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

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

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

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

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

図 3.2 各サーバの状態とGroup A、Group Bの起動状況（A、Bは通常排他）

1. クラスタの立ち上げ

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

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

4. Server 1 の電源 ON

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

6. Group A の移動

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

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

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

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

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

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

図 3.3 各サーバの状態とGroup A、Group Bの起動状況（A、Bは完全排他）

1. クラスタの立ち上げ

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

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

4. Server 1 の電源 ON

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

6. Group A の移動

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

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

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

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

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

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

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

図 3.4 各サーバの状態とGroup A、Group Bの起動状況（Replicator使用時）

1. クラスタの立ち上げ

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

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

4. Server 1 の電源 ON

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

6. Group A の移動

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

8. Server 2 ダウン

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

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

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

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

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

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

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

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

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

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

注釈

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

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

回復動作の活性リトライ回数およびフェイルオーバ回数は回復動作に失敗した場合でも 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の活性処理が異常（fsckの異常、mountのエラーなど）になりました。

   

   図 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.5. 最終動作前スクリプトについて

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

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

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

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

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

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

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

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

#!/bin/sh

# ***************************************
# *           preactaction.sh
# ***************************************

ulimit -s unlimited
echo "START"

# スクリプト実行要因の環境変数を参照して、処理の振り分けを行う。
if [ "$CLP_TIMING" = "START" ]
then
    # ここに、活性異常時最終動作前に実行すべき回復処理を記述する。
    #
else
    echo "NO_CLP"
fi

echo "EXIT"
exit 0

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

以下の点に注意して、スクリプトを作成してください。

• スクリプト中にて、実行に時間を必要とするコマンドを実行する場合には、コマンドの実行が完了したことを示すトレースを残すようにしてください。この情報は、問題発生時、障害の切り分けを行う場合に使用することができます。clplogcmdを使用してトレースを残す方法があります。

• スクリプト中に clplogcmd を使用して記述する方法

  clplogcmd で Cluster WebUI のアラートログや OS の syslog に、メッセージを出力できます。clplogcmd については、本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「メッセージを出力する (clplogcmd コマンド)」を参照してください。

  (例：スクリプト中のイメージ)

  clplogcmd -m "recoverystart.."
  recoverystart
  clplogcmd -m "OK"
  

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

• スクリプトから起動されるコマンド、アプリケーションのスタックサイズについて

  スタックサイズが 2MB に設定された状態で回復スクリプト、回復動作前スクリプトが実行されます。このため、スクリプトから起動されるコマンドやアプリケーションで 2MB 以上のスタックサイズが必要な場合には、スタックオーバーフローが発生します。

  スタックオーバーフローが発生する場合には、コマンドやアプリケーションを起動する前にスタック サイズを設定してください。

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

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

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

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

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

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

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

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

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

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

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

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

#!/bin/sh
#***********************************************
#                rscextent.sh                  *
#***********************************************
ulimit -s unlimited
echo "START"

if [ "$CLP_TIMING" = "PRESTART" ]
then
    echo "$CLP_GROUPNAME"
    echo "$CLP_RESOURCENAME"
    # ここに、リソース活性前に実行したい任意の処理を記述する。
    #

elif [ "$CLP_TIMING" = "POSTSTART" ]
then
    echo "$CLP_GROUPNAME"
    echo "$CLP_RESOURCENAME"
    # ここに、リソース活性後に実行したい任意の処理を記述する。
    #

elif [ "$CLP_TIMING" = "PRESTOP" ]
then
    echo "$CLP_GROUPNAME"
    echo "$CLP_RESOURCENAME"
    # ここに、リソース非活性前に実行したい任意の処理を記述する。
    #

elif [ "$CLP_TIMING" = "POSTSTOP" ]
then
    echo "$CLP_GROUPNAME"
    echo "$CLP_RESOURCENAME"
    # ここに、リソース非活性後に実行したい任意の処理を記述する。
    #

fi
echo "EXIT"
exit 0

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

以下の点に注意して、スクリプトを作成してください。

• スクリプト中にて、実行に時間を必要とするコマンドを実行する場合には、コマンドの実行が完了したことを示すトレースを残すようにしてください。この情報は、問題発生時、障害の切り分けを行う場合に使用することができます。clplogcmdを使用してトレースを残す方法があります。

• スクリプト中に clplogcmd を使用して記述する方法

  clplogcmd で Cluster WebUI のアラートログや OS の syslog に、メッセージを出力できます。clplogcmd については、本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「メッセージを出力する (clplogcmd コマンド)」を参照してください。

  (例：スクリプト中のイメージ)

  clplogcmd -m "start.."
  ：
  clplogcmd -m "OK"
  

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

• スクリプトから起動されるコマンド、アプリケーションのスタックサイズについて

  スタックサイズが 2MB に設定された状態で活性/非活性前後スクリプトが実行されます。このため、スクリプトから起動されるコマンドやアプリケーションで 2MB 以上のスタックサイズが必要な場合には、スタックオーバーフローが発生します。

  スタックオーバーフローが発生する場合には、コマンドやアプリケーションを起動する前にスタック サイズを設定してください。

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

活性異常、非活性異常検出時の最終動作として OS の再起動を伴うような設定をしている場合に、活性異常、非活性異常の検出によるシャットダウン回数、または再起動回数を制限することができます。

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

注釈

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

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

最大再起動回数をリセットする時間に 0 を設定した場合には、再起動回数はリセットされません。リセットする場合は [clpregctrl] コマンドを使用する必要があります。[clpregctrl] コマンドに関しては「9. CLUSTERPRO コマンドリファレンス」の「再起動回数を制御する (clpregctrl コマンド)」を参照してください。

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

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

また、最大再起動回数をリセットする時間が 10 分に設定されているため、クラスタシャットダウン後再起動時にグループの活性に成功した場合には、10 分経過すると再起動回数はリセットされます。

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

設定例

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

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

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

最大再起動回数 1 回

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

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

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

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

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

2. Disk resource 1の活性処理が異常（fsckの異常、mountのエラーなど）になりました。

   

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

   

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

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

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

   

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

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

8. Disk resource 1の活性処理が異常（fsckの異常、mountのエラーなど）になりました。

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

3.2.8. 再起動回数初期化

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

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

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

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

  グループの起動処理を開始します。
• 両系活性が発生すると判断した場合（タイムアウトした場合）

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

注釈

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図 3.24 グループの起動順序

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

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 Bと同じサーバで起動する場合には待ち合わせる

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

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

   

   図 3.25 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.26 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.27 Server 1 でGroup C、Server 2でGroup Bが起動

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

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

   

   図 3.28 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.29 Group AはServer 2にフェイルオーバ、Server 1でGroup Cが起動

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

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

   

   図 3.30 Server 1 でGroup Aが起動

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

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

   

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

注釈

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

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

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

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

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

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

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

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

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

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

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

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

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

排他なし

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

通常排他

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

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

完全排他

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

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

注釈

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

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

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

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

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

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

共有ディスク上のハイブリッドディスクリソースを使用する（ミラーリング元、ミラーリング先）サーバは、サーバグループ内の1台のサーバです。

図 3.32 サーバグループ

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

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

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

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

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

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

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

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

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

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

サーバ別設定が可能なグループリソースは下記です。

グループリソース名	対応バージョン
ディスクリソース	4.0.0-1～
フローティング IP リソース	4.0.0-1～
仮想 IP リソース	4.0.0-1～
ミラーディスクリソース	4.0.0-1～
ハイブリッドディスクリソース	4.0.0-1～
ダイナミック DNS リソース	4.0.0-1～
AWS Elastic IP リソース	4.0.0-1～
AWS 仮想 IP リソース	4.0.0-1～
AWS セカンダリ IP リソース	5.0.0-1～
AWS DNS リソース	4.0.0-1～
Azure DNS リソース	4.0.0-1～
Google Cloud DNS リソース	4.3.0-1～
Oracle Cloud DNS リソース	5.2.0-1～

注釈

仮想 IP リソース、AWS Elastic IP リソース、AWS 仮想 IP リソース、AWS セカンダリ IP リソース、Azure DNS リソース、Google Cloud DNS リソース、Oracle Cloud DNS リソースには必ずサーバ個別設定が必要なパラメータがあります。

サーバ個別設定可能なパラメータは各グループリソースのパラメータの説明を参照してください。サーバ個別設定可能なパラメータには「サーバ個別設定可能 」と付記しています。

ここではフローティング 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 プロパティ」 - 「マスタサーバタブ」 を参照してください。

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

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

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

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

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

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

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

追加

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

削除

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

順位

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

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

ハイブリッドディスクリソースを含むグループを起動するサーバの設定には、フェイルオーバグループを起動するサーバグループを設定する必要があります。

追加

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

削除

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

順位

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

3.4.4. 属性タブ

グループ起動属性

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

• 自動起動

  クラスタの起動時、グループは自動的に起動されます。
• 手動起動

  クラスタの起動時、グループは起動されません。

  ユーザが明示的に Cluster WebUI または [clpgrp] コマンドから、操作することで起動されます。

両系活性チェックを行う

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

タイムアウト (1～9999)

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

フェイルオーバ属性

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

• 自動フェイルオーバ

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

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

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

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

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

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

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

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

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

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

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

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

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

フェイルバック属性

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

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

• 自動フェイルバック

  自動的にフェイルバックします。
• 手動フェイルバック

  自動的にフェイルバックしません。

モニタの編集

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

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

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

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

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

  

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

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

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

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

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

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

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

追加

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

削除

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

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

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

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

注釈

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

• ユーザ空間モニタ

• ARPモニタ

• 仮想IPモニタ

• ミラーディスクコネクトモニタ

• ハイブリッドディスクモニタ

• ハイブリッドディスクコネクトモニタ

注釈

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

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

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

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

注釈

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

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

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

3.4.5. 起動待ち合わせタブ

追加

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

削除

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

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

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

プロパティ

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

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

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

• チェックボックスがオンの場合

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

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

3.4.6. 停止待ち合わせタブ

追加

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

削除

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

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

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

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

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

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

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

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

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

対象グループの停止失敗時に停止待ち時間まで待機する

対象グループが停止に失敗したとき停止待ち時間まで待機するかどうかを設定します。

• チェックボックスがオンの場合

  • 停止待ち時間まで待機します。

• チェックボックスがオフの場合

  • 停止待ち時間まで待機せずに自身の停止処理を開始します。

3.4.7. 全体の依存関係タブ

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

活性時タブ

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

非活性時タブ

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

図を表示

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

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 を設定するとフェイルオーバを行いません。

最終動作

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

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

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

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

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

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

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

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

  活性異常を検出したサーバのクラスタサービスを停止し、OS を再起動します。
• sysrq パニック

  sysrq のパニックを行います。

  注釈

  sysrq パニックに失敗した場合、OS のシャットダウンを行います。

• keepalive リセット

  clpkhb ドライバ、clpka ドライバを使用し、OS をリセットします。

  注釈

  keepalive リセットに失敗した場合、OS のシャットダウンを行います。

  clpkhb ドライバ、clpka ドライバが対応していない OS、kernel では設定しないでください。
• keepalive パニック

  clpkhb ドライバ、clpka ドライバを使用し、OS をパニックします。

  注釈

  keepalive パニックに失敗した場合、OS のシャットダウンを行います。

  clpkhb ドライバ、clpka ドライバが対応していない OS、kernel では設定しないでください。
• BMC リセット

  ipmi のコマンドを使用し、サーバをハードウェアリセットします。

  注釈

  BMC リセットに失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。
• BMC パワーオフ

  ipmi のコマンドを使用し、OS の電源をオフにします。OS の ACPI の設定によりOS のシャットダウンが実行される場合があります。

  注釈

  BMC パワーオフに失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。
• BMC パワーサイクル

  ipmi のコマンドを使用し、サーバのパワーサイクル （電源オフ/オン） を実行します。OS の ACPI の設定により OS のシャットダウンが実行される場合があります。

  注釈

  BMC パワーサイクルに失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。
• BMC NMI

  ipmi のコマンドを使用し、サーバへ NMI を発生させます。NMI 発生後の挙動はOS の設定に依存します。

  注釈

  BMC NMIに失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。

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

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

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

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

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

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

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

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

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

最終動作

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

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

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

  グループの停止処理を継続します。

  注釈

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

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

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

  注釈

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

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

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

  非活性異常を検出したサーバのクラスタデーモンを停止し、OS を再起動します。
• sysrq パニック

  sysrq のパニックを行います。

  注釈

  sysrq パニックに失敗した場合、OS のシャットダウンを行います。

• keepalive リセット

  clpkhb ドライバ、clpka ドライバを使用し、OS をリセットします。

  注釈

  keepalive リセットに失敗した場合、OS のシャットダウンを行います。

  clpkhb ドライバ、clpka ドライバが対応していない OS、kernel では設定しないでください。
• keepalive パニック

  clpkhb ドライバ、clpka ドライバを使用し、OS をパニックします。

  注釈

  keepalive パニックに失敗した場合、OS のシャットダウンを行います。

  clpkhb ドライバ、clpka ドライバが対応していない OS、kernel では設定しないでください。
• BMC リセット

  ipmi のコマンドを使用し、サーバをハードウェアリセットします。

  注釈

  BMC リセットに失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。
• BMC パワーオフ

  ipmi のコマンドを使用し、OS の電源をオフにします。OS の ACPI の設定によりOS のシャットダウンが実行される場合があります。

  注釈

  BMC パワーオフに失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。
• BMC パワーサイクル

  ipmi のコマンドを使用し、サーバのパワーサイクル （電源オフ/オン） を実行します。OS の ACPI の設定により OS のシャットダウンが実行される場合があります。

  注釈

  BMC パワーサイクルに失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。
• BMC NMI

  ipmi のコマンドを使用し、サーバへ NMI を発生させます。NMI 発生後の挙動はOS の設定に依存します。

  注釈

  BMC NMI に失敗した場合、OS のシャットダウンを行います。

  OpenIPMI をインストールしていない、または [ipmitool] コマンドが動作しないサーバでは設定しないでください。

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

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

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

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

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

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

3.5.4. 詳細タブ

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

3.5.5. 拡張タブ

リソース起動属性

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

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

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

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

実行タイミング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ユーザアプリケーション

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

例:

"/tmp/user application/script.sh"

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

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

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

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

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

表示

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルを表示します。エディタで編集して保存した内容は反映されません。

編集

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

置換

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

タイムアウト (1～9999)

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

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

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

3.6. EXEC リソースを理解する

CLUSTERPRO では、CLUSTERPRO によって管理され、グループの起動時、終了時、フェイルオーバ発生時および移動時に実行されるアプリケーションやシェルスクリプトを登録できます。EXEC リソースには、ユーザ独自のプログラムやシェルスクリプトなども登録できます。シェルスクリプトは、sh のシェルスクリプトと同じ書式なので、それぞれのアプリケーションの事情にあわせた処理を記述できます。

注釈

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

3.6.1. EXEC リソースの依存関係

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

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
ディスクリソース
ミラーディスクリソース
ハイブリッドディスクリソース
ボリュームマネージャーリソース
ダイナミック DNS リソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
AWS DNS リソース
Azure DNS リソース

3.6.2. EXEC リソースの活性/非活性処理結果の判定方法について

EXEC リソースに登録されたアプリケーションやシェルスクリプトの実行結果により、活性/非活性処理結果の判定を行います。

アプリケーションやシェルスクリプトの終了コードが0の場合には、正常に活性/非活性処理が成功したと判定します。

0以外の終了コードの場合には、活性/非活性処理が失敗したと判定します。

開始/停止スクリプトのタイムアウトが発生した場合には、活性/非活性処理が失敗したと判定します。

3.6.3. EXEC リソースで使用するスクリプト

スクリプトの種類

EXEC リソースには、それぞれ開始スクリプトと終了スクリプトが用意されています。CLUSTERPRO は、クラスタの状態遷移が必要な場面において、EXEC リソースごとのスクリプトを実行します。クラスタ環境下で動作させたいアプリケーションの起動、終了、もしくは復旧の手順を、これらのスクリプトに記述する必要があります。

図 3.35 開始スクリプトと終了スクリプト

3.6.4. EXEC リソースのスクリプトで使用する環境変数

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

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

終了スクリプトの環境変数は、直前に実行された開始スクリプトの内容を、値として返します。開始スクリプトでは CLP_FACTOR および CLP_PID の環境変数はセットされません。

CLP_LASTACTION の環境変数は、CLP_FACTOR の環境変数がCLUSTERSHUTDOWN または SERVERSHUTDOWN の場合にのみセットされます。

環境変数	環境変数の値	意味
CLP_EVENT …スクリプト実行要因	START	クラスタの起動により、実行された場合。 グループの起動により、実行された場合。 グループの移動により、移動先のサーバで実行された場合。 モニタリソースの異常検出によるグループの再起動により、同じサーバで実行された場合。 モニタリソースの異常検出によるグループリソースの再起動により、同じサーバで実行 された場合。
〃	FAILOVER	サーバダウンにより、フェイルオーバ先の サーバで実行された場合。 モニタリソースの異常検出により、フェイルオーバ先のサーバで実行された場合。 グループリソースの活性失敗により、フェイルオーバ先のサーバで実行された場合。
CLP_FACTOR …グループ停止要因	CLUSTERSHUTDOWN	クラスタ停止により、グループの停止が実行された場合。
〃	SERVERSHUTDOWN	サーバ停止により、グループの停止が実行された場合。
〃	GROUPSTOP	グループ停止により、グループの停止が実行された場合。
〃	GROUPMOVE	グループ移動により、グループの移動が実行された場合。
〃	GROUPFAILOVER	モニタリソースの異常検出により、グループのフェイルオーバが実行された場合。 グループリソースの活性失敗により、グループのフェイルオーバが実行された場合。
〃	GROUPRESTART	モニタリソースの異常検出により、グループの再起動が実行された場合。
〃	RESOURCERESTART	モニタリソースの異常検出により、グループ リソースの再起動が実行された場合。
CLP_LASTACTION …クラスタ停止後処理	REBOOT	OS を reboot (再起動) する場合。
〃	HALT	OS をhalt (シャットダウン) する場合。
〃	NONE	何もしない。
CLP_SERVER ……スクリプトの実行サーバ	HOME	グループの、プライマリサーバで実行された。
〃	OTHER	グループの、プライマリサーバ以外で実行された。
CLP_DISK 1 …共有ディスクまたはミラーディスク上 のパーティション接続情報	SUCCESS	接続に失敗しているパーティションはない。
〃	FAILURE	接続に失敗しているパーティションがある。
CLP_PRIORITY …スクリプトが実行されたサーバの フェイルオーバポリシーの順位	1～クラスタ内のサーバ数	実行されているサーバの、プライオリティを示す。1 から始まる数字で、小さいほどプライオリティが高いサーバ。 CLP_PRIORITY が 1 の場合、プライマリサーバで実行されたことを示す。
CLP_GROUPNAME …グループ名	グループ名	スクリプトが属している、グループ名を示す。
CLP_RESOURCENAME …リソース名	リソース名	スクリプトが属している、リソース名を示す。
CLP_PID …プロセス ID	プロセス ID	プロパティとして開始スクリプトが非同期に設定されている場合、開始スクリプトのプロセスIDを示す。開始スクリプトが同期に設定されている場合、本環境変数は値を持たない。
CLP_VERSION_FULL …CLUSTERPROフルバージョン	CLUSTERPROフルバージョン	CLUSTERPROのフルバージョンを示す。（例） 5.2.1-1
CLP_VERSION_MAJOR …CLUSTERPROメジャーバージョン	CLUSTERPROメジャーバージョン	CLUSTERPROのメジャーバージョンを示す。（例）5
CLP_PATH …CLUSTERPROインストールパス	CLUSTERPROインストールパス	CLUSTERPROがインストールされているパスを示す。（例）/opt/nec/clusterpro
CLP_OSNAME …サーバOS名	サーバOS名	スクリプトが実行されたサーバのOS名を示す。 （例）1.OS名が取得できた場合：Red Hat Enterprise Linux Server release 6.8 (Santiago) 2.OS名が取得できなかった場合：Linux
CLP_OSVER …サーバOS名	サーバOSバージョン	スクリプトが実行されたサーバのOSバージョンを示す。 （例）1.OSバージョンが取得できた場合：6.8 2.OSバージョンが取得できなかった場合：※値なし

1

ディスクソース、ミラーディスクソース、ハイブリッドソース、ボリュームマネージャリソースが対象となります。

[EXECリソース調整プロパティ] の [待機系サーバで実行する] が有効に設定され、スクリプトを待機系サーバ上で実行する場合、環境変数にセットされる情報は下図のとおりとなります。

環境変数	環境変数の値	意味
CLP_EVENT …スクリプト実行要因	STANDBY	待機系サーバ上で実行された場合。
CLP_SERVER ……スクリプトの実行サーバ	HOME	グループの、プライマリサーバで実行された。
〃	OTHER	グループの、プライマリサーバ以外で実行された。
CLP_PRIORITY …スクリプトが実行されたサーバの フェイルオーバポリシーの順位	1～クラスタ内のサーバ数	実行されているサーバの、プライオリティを示す。1 から始まる数字で、小さいほどプライオリティが高いサーバ。 CLP_PRIORITY が 1 の場合、プライマリサーバで実行されたことを示す。
CLP_GROUPNAME …グループ名	グループ名	スクリプトが属している、グループ名を示す。
CLP_RESOURCENAME …リソース名	リソース名	スクリプトが属している、リソース名を示す。
CLP_VERSION_FULL …CLUSTERPROフルバージョン	CLUSTERPROフルバージョン	CLUSTERPROのフルバージョンを示す。（例） 5.2.1-1
CLP_VERSION_MAJOR …CLUSTERPROメジャーバージョン	CLUSTERPROメジャーバージョン	CLUSTERPROのメジャーバージョンを示す。（例）5
CLP_PATH …CLUSTERPROインストールパス	CLUSTERPROインストールパス	CLUSTERPROがインストールされているパスを示す。（例）/opt/nec/clusterpro
CLP_OSNAME …サーバOS名	サーバOS名	スクリプトが実行されたサーバのOS名を示す。 （例）1.OS名が取得できた場合：Red Hat Enterprise Linux Server release 6.8 (Santiago) 2.OS名が取得できなかった場合：Linux
CLP_OSVER …サーバOSバージョン	サーバOSバージョン	スクリプトが実行されたサーバのOSバージョンを示す。 （例）1.OSバージョンが取得できた場合：6.8 2.OSバージョンが取得できなかった場合：※値なし

3.6.5. EXEC リソーススクリプトの実行タイミング

開始、終了スクリプトの実行タイミングと環境変数の関連を、クラスタ状態遷移図にあわせて説明します。

• 説明を簡略にするため、2 台構成のクラスタで説明します。

  3 台以上の構成の場合に、発生する可能性のある実行タイミングと環境変数の関連は、補足という形で説明します。

• 図中のサーバは以下の状態を表しています。

  サーバ	サーバ状態
  	正常状態 (クラスタとして正常に動作している)
  	停止状態 (クラスタが停止状態)

  • (例) 正常状態にある Server 1 において Group A が動作している。

    

• 各グループは、起動したサーバの中で、最もプライオリティの高いサーバ上で起動されます。

• クラスタに定義されているグループは A、B、C の3つで、それぞれ以下のようなフェイルオーバポリシーを持っています。

  グループ	優先度1サーバ	優先度2サーバ
  A	Server 1	Server 2
  B	Server 2	Server 1
  C	Server 1	Server 2

【クラスタ状態遷移図】

代表的なクラスタ状態遷移について説明します。

図 3.36 クラスタ状態遷移の例（概要）

図中の1. ～11. は、以下の説明に対応しています。

1. 通常立ち上げ

   ここでいう通常立ち上げとは、開始スクリプトがプライマリサーバで正常に実行された時を指します。

   各グループは、起動したサーバの中で、最もプライオリティの高いサーバ上で起動されます。

   

   図 3.37 状態とスクリプト実行（通常立ち上げ）

   Start に対する環境変数

   	Group A	Group B	Group C
   CLP_EVENT	START	START	START
   CLP_SERVER	HOME	HOME	HOME

2. 通常シャットダウン

   ここでいう通常シャットダウンとは、終了スクリプトに対応する開始スクリプトが、通常立ち上げにより実行された、もしくはグループの移動 (オンラインフェイルバック) により実行された直後の、クラスタシャットダウンを指します。

   

   図 3.38 状態とスクリプト実行（通常シャットダウン）

   Stop に対する環境変数

   	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.39 状態とスクリプト実行（サーバダウンによるフェイルオーバ）

   Start に対する環境変数

   	Group A	Group C
   CLP_EVENT	FAILOVER	FAILOVER
   CLP_SERVER	OTHER	OTHER

4. Server 1 フェイルオーバ後クラスタシャットダウン

   Group A と Group C の終了スクリプトが、フェイルオーバ先のServer 2 で実行されます (Group B の終了スクリプトは、通常シャットダウンでの実行です)。

   

   図 3.40 状態とスクリプト実行（フェイルオーバ後、クラスタシャットダウン）

   Stop に対する環境変数

   	Group A	Group B	Group C
   CLP_EVENT	FAILOVER	START	FAILOVER
   CLP_SERVER	OTHER	HOME	OTHER

5. Group A と Group C の移動

   Group A と Group C の終了スクリプトが、フェイルオーバ先のServer 2 で実行された後、Server 1 で開始スクリプトが実行されます。

   

   図 3.41 状態とスクリプト実行（Group A、Group Cの移動）(1)

   

   図 3.42 状態とスクリプト実行（Group A、Group Cの移動）(2)

   Stop に対する環境変数

   	Group A	Group C
   CLP_EVENT	FAILOVER 2	FAILOVER
   CLP_SERVER	OTHER	OTHER

   Startに対する環境変数

   	Group A	Group C
   CLP_EVENT	START	START
   CLP_SERVER	HOME	HOME

2

終了スクリプトの環境変数の値は、直前に実行された開始スクリプトの環境変数の値となる。

「5. Group A と Group C の移動」の遷移の場合、直前にクラスタシャットダウンがないのでFAILOVERになるが、「5. Group A と Group C の移動」の前にクラスタシャットダウンが行われていると、STARTとなる。

6. Group C の障害、フェイルオーバ

   Group C に障害が発生すると、Server 1 でGroup C の終了スクリプトが実行され、Server 2 でGroup C の開始スクリプトが実行されます。

   

   図 3.43 状態とスクリプト実行（Group Cの障害、フェイルオーバ）(1)

   

   図 3.44 状態とスクリプト実行（Group Cの障害、フェイルオーバ）(2)

   Server 1 のStopに対する環境変数

   	Group C
   CLP_EVENT	START
   CLP_SERVER	HOME

   Server 2のStartに対する環境変数

   	Group C
   CLP_EVENT	FAILOVER
   CLP_SERVER	OTHER

7. Group C の移動

   6. でServer 2 にフェイルオーバしてきたGroup C を、Server 2 よりServer 1 へ移動します。Server 2 で終了スクリプトを実行した後、Server 1 で開始スクリプトを実行します。

   

   図 3.45 状態とスクリプト実行（Group Cの移動）(1)

   Stopに対する環境変数 ( 6. よりフェイルオーバしてきたため)

   	Group C
   CLP_EVENT	FAILOVER
   CLP_SERVER	OTHER

   

   図 3.46 状態とスクリプト実行（Group Cの移動）(2)

   Startに対する環境変数

   	Group C
   CLP_EVENT	START
   CLP_SERVER	HOME

8. Group B の停止

   Group B の終了スクリプトがServer 2 で実行されます。

   

   図 3.47 状態とスクリプト実行（Group Bの停止）

   Stopに対する環境変数

   	Group B
   CLP_EVENT	START
   CLP_SERVER	HOME

9. Group B の起動

   Group B の開始スクリプトがServer 2 で実行されます。

   

   図 3.48 状態とスクリプト実行（Group Bの起動）

   Startに対する環境変数

   	Group B
   CLP_EVENT	START
   CLP_SERVER	HOME

10. Group C の停止

    Group C の終了スクリプトがServer 2 で実行されます。

    

    図 3.49 状態とスクリプト実行（Group Cの停止）

    Stopに対する環境変数

    	Group C
    CLP_EVENT	FAILOVER
    CLP_SERVER	OTHER

11. Group C の起動

    Group C の開始スクリプトがServer 2 で実行されます。

    

    図 3.50 状態とスクリプト実行（Group Cの起動）

    Startに対する環境変数

    	Group C
    CLP_EVENT	START
    CLP_SERVER	OTHER

【補足1】

フェイルオーバポリシーに設定されているサーバを 3 つ以上持つグループにおいて、プライマリサーバ以外のサーバで異なった動作を行う場合、 CLP_SERVER (HOME/OTHER) の代わりに、CLP_PRIORITY を使用します。

図 3.51 クラスタ状態遷移の例（サーバダウンによるフェイルオーバ）

(例1) クラスタ状態遷移図 「3. Server 1 ダウンによるフェイルオーバ」の場合

Server 1 をプライマリサーバとするグループの開始スクリプトが、障害発生により次に高いフェイルオーバポリシーを持つServer 2 で実行されます。開始スクリプトには、CLP_EVENT (=FAILOVER) を分岐条件にして、業務の起動、復旧処理 (たとえばデータベースのロールバック処理など) を記述しておく必要があります。

2 番目に高いフェイルオーバポリシーを持つサーバのみで実行したい処理がある場合は、CLP_PRIORITY (=2) を分岐条件にして記述しておく必要があります。

図 3.52 状態とスクリプト実行（Group A、Group Cの起動）

Start に対する環境変数

	Group A	Group C
CLP_EVENT	FAILOVER	FAILOVER
CLP_SERVER	OTHER	OTHER
CLP_PRIORITY	2	2

(例2) クラスタ状態遷移図「7. Group C の移動」の場合

図 3.53 クラスタ状態遷移の例（Group Cの移動）

Group C の終了スクリプトが、フェイルオーバ元のServer 2 で実行された後、Server 3で開始スクリプトが実行されます。

図 3.54 状態とスクリプト実行（Group Cの移動）(1)

Stop に対する環境変数

	Group C
CLP_EVENT	FAILOVER
CLP_SERVER	OTHER
CLP_PRIORITY	2

図 3.55 状態とスクリプト実行（Group Cの移動）(2)

Startに対する環境変数

	Group C
CLP_EVENT	START
CLP_SERVER	OTHER
CLP_PRIORITY	3

【補足2】

リソースモニタがスクリプトを (再) 起動する場合

リソースモニタがアプリケーションの異常を検出し開始スクリプトを (再) 起動する場合の環境変数は以下のようになります。

(例1) リソースモニタがServer 1 で起動していたアプリケーションの異常終了を検出してServer 1 でGroup A の再起動を行う場合

図 3.56 状態とスクリプト実行（Group Aの再起動）(1)

Stop に対する環境変数

	Group A
CLP_EVENT	Start 実行時と同一の値

図 3.57 状態とスクリプト実行（Group Aの再起動）(2)

Start に対する環境変数

	Group A
CLP_EVENT	START

(例2) リソースモニタがServer 1 で起動していたアプリケーションの異常終了を検出してServer 2 へフェイルオーバをして、Server 2 でGroup A の起動を行う場合

図 3.58 状態とスクリプト実行（Group Aのフェイルオーバ）(1)

Stop に対する環境変数

	Group A
CLP_EVENT	Start 実行時と同一の値

図 3.59 状態とスクリプト実行（Group Aのフェイルオーバ）(2)

Start に対する環境変数

	Group A
CLP_EVENT	FAILOVER

【補足3】

[EXECリソース調整プロパティ] の [待機系サーバで実行する] を有効に設定すると、グループを起動したサーバ (=現用系サーバ) で開始スクリプトや終了スクリプトが実行されるタイミングに合わせて、グループを起動していない他のサーバ (=待機系サーバ) でもスクリプトを実行することができます。

現用系サーバでのスクリプト実行と比較すると、待機系サーバでのスクリプト実行には以下の特徴があります。

• スクリプトの実行結果 (エラーコード) がグループリソースのステータスに影響しません。

• 活性前後スクリプトや非活性前後スクリプトを実行しません。

• 活性時監視に設定されているモニタリソースの起動・停止を行いません。

• セットされる環境変数の種類・値が異なります (前項「 EXEC リソースのスクリプトで使用する環境変数 」を参照してください)。

• 現用系サーバのクラスタサービス停止によるフェイルオーバの場合は実行しません。

待機系サーバでスクリプトが実行されるタイミングと環境変数の関連について、クラスタ状態遷移図にあわせて説明します。

【クラスタ状態遷移図】

図 3.60 クラスタ状態遷移の例（サーバダウンによるフェイルオーバ）

図中の 1. ～ 4. は、以下の説明に対応しています。

1. 通常立ち上げ

グループを起動するとき、現用系サーバでの開始スクリプト実行に合わせて、待機系サーバでも開始スクリプトが実行されます。

待機系サーバの開始スクリプトは、現用系サーバの開始スクリプトが実行された「後」で実行されます。

開始スクリプトには、CLP_EVENT (=STANDBY) を分岐条件にして、待機系サーバ上で実行したい処理を記述しておく必要があります。

図 3.61 状態とスクリプト実行（Group Aの通常起動）(1)

図 3.62 状態とスクリプト実行（Group Aの通常起動）(2)

Start に対する環境変数

	Server 1	Server 2
CLP_EVENT	START	STANDBY
CLP_SERVER	HOME	OTHER

2. 通常シャットダウン

グループを停止するとき、現用系サーバでの終了スクリプト実行に合わせて、待機系サーバでも終了スクリプトが実行されます。

待機系サーバの終了スクリプトは、現用系サーバの終了スクリプトが実行される「前」に実行されます。

終了スクリプトには、CLP_EVENT (=STANDBY) を分岐条件にして、待機系サーバ上で実行したい処理を記述しておく必要があります。

図 3.63 状態とスクリプト実行（Group Aの通常シャットダウン）(1)

図 3.64 状態とスクリプト実行（Group Aの通常シャットダウン）(2)

Stop に対する環境変数

	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.65 クラスタ状態遷移の例（サーバダウンによるフェイルオーバ）

Start に対する環境変数

	Server 2
CLP_EVENT	FAILOVER
CLP_SERVER	OTHER

4. Group Aの移動

Group Aの終了スクリプトがServer 1 (= 待機系サーバ) とServer 2 (= 現用系サーバ) で実行された後、 開始スクリプトがServer 1 (= 現用系サーバ) とServer 2 (= 待機系サーバ) で実行されます。

図 3.66 状態とスクリプト実行（Group Aの移動）(1)

図 3.67 状態とスクリプト実行（Group Aの移動）(2)

図 3.68 状態とスクリプト実行（Group Aの移動）(3)

図 3.69 状態とスクリプト実行（Group Aの移動）(4)

Stop に対する環境変数

	Server 1	Server 2
CLP_EVENT	STANDBY	FAILOVER 3
CLP_SERVER	HOME	OTHER

3

終了スクリプトの環境変数の値は、直前に実行された開始スクリプトの環境変数の値となる。

「4. Group A の移動」の遷移の場合、直前にクラスタシャットダウンがないのでFAILOVERになるが、「4. Group A の移動」の前にクラスタシャットダウンが行われていると、STARTとなる。

Start に対する環境変数

	Server 1	Server 2
CLP_EVENT	START	STANDBY
CLP_SERVER	HOME	OTHER

3.6.6. EXEC リソーススクリプトの記述の流れ

前のトピックの、スクリプトの実行タイミングと実際のスクリプト記述を関連付けて説明します。文中の (数字) は 「 EXEC リソーススクリプトの実行タイミング 」の各動作をさします。

group A 開始スクリプト： start.sh の一例

#!/bin/sh
# ***************************************
# *              start.sh               *
# ***************************************

# スクリプト実行要因の環境変数を参照して処理の振り分けを行う。
if [ "$CLP_EVENT" = "START" ]
then
    # DISK接続情報環境変数を参照してエラー処理の要否を判定する。
    if [ "$CLP_DISK" = "SUCCESS" ]
    then
        # ここに、業務の通常起動処理を記述する。
        # この処理は以下のタイミングで実行される。
        #
        # (1) 通常立ち上げ
        # (5) Group A と Group C の移動
        #

        # 実行サーバ環境変数を参照して処理の振り分けを行う。
        if [ "$CLP_SERVER" = "HOME" ]
        then
            # ここに、プライマリサーバで、業務が通常起動される場合にのみ行いたい処理を記述する。
            # この処理は以下のタイミングで実行される。
            #
            # (1) 通常立ち上げ
            # (5) Group A と Group C の移動
            #

        else
            # ここに、プライマリサーバ以外で、業務が通常起動される場合にのみ行いたい処理を記述する。
            #
        fi
    else
        # ここに、ディスク関連のエラー処理を記述する。
        #

    fi
elif [ "$CLP_EVENT" = "FAILOVER" ]
then

    # DISK接続情報環境変数を参照してエラー処理の要否を判定する。
    if [ "$CLP_DISK" = "SUCCESS" ]
    then
        # ここに、業務の通常起動処理を記述する。
        # この処理は以下のタイミングで実行される。
        #
        # (3) Server 1ダウンによるフェイルオーバ
        #

        # 実行サーバ環境変数を参照して処理の振り分けを行う。
        if [ "$CLP_SERVER" = "HOME" ]
        then
            # ここに、フェイルオーバ後、プライマリサーバで業務が起動される場合にのみ行いたい処理を記述する。
            #

        else
            # ここに、フェイルオーバ後、非プライマリサーバで業務が起動される場合にのみ行いたい処理を記述する。
            # この処理は以下のタイミングで実行される。
            #
            # (3) Server 1ダウンによるフェイルオーバ
            #

        fi
    else
        # ここに、ディスク関連のエラー処理を記述する。
        #

    fi
else
    # CLUSTERPROは動作していない。

fi

# 終了コードが0の場合、EXECリソースの活性処理は成功と判定される。
# スクリプト内でエラーが発生した場合には 0以外の終了コードを返却するように記述する。
exit 0

Group A 終了スクリプト： stop.sh の一例

#!/bin/sh
# ***************************************
# *              stop.sh               *
# ***************************************

# スクリプト実行要因の環境変数を参照して処理の振り分けを行う。
if [ "$CLP_EVENT" = "START" ]
then
    if [ "$CLP_DISK" = "SUCCESS" ]
    then
        # ここに、業務の通常終了処理を記述する。以下のタイミングで実行される。
        #
        # (2) 通常シャットダウン
        #

        # 実行サーバ環境変数を参照して処理の振り分けを行う。
        if [ "$CLP_SERVER" = "HOME" ]
        then
            # ここに、プライマリサーバで業務が通常終了される場合にのみ行いたい処理を記述する。
            # この処理は以下のタイミングで実行される。
            #
            # (2) 通常シャットダウン
            #

        else
            # ここに、プライマリサーバ以外で業務が通常終了される場合にのみ行いたい処理を記述する。
            #

        fi
    else
        # ここに、ディスク関連のエラー処理を記述する。
        #

    fi
elif [ "$CLP_EVENT" = "FAILOVER" ]
then

    # DISK接続情報環境変数を参照してエラー処理の要否を判定する。
    if [ "$CLP_DISK" = "SUCCESS" ]
    then
        # ここに、フェイルオーバ後の通常終了処理を記述する。
        # この処理は以下のタイミングで実行される。
        #
        # (4) Server 1フェイルオーバ後、クラスタシャットダウン
        # (5) Group A と Group C の移動
        #

        # 実行サーバ環境変数を参照して処理の振り分けを行う。
        if [ "$CLP_SERVER" = "HOME" ]
        then
            # ここに、フェイルオーバ後、プライマリサーバで業務が終了される場合にのみ行いたい処理を記述する。
            #

        else
            # ここに、フェイルオーバ後、非プライマリサーバで業務が終了される場合にのみ行いたい処理を記述する。
            # この処理は以下のタイミングで実行される。
            #
            # (4) Server 1フェイルオーバ後、クラスタシャットダウン
            # (5) Group A と Group C の移動
            #

        fi
    else
        # ここに、ディスク関連のエラー処理を記述する。
        #

    fi
else
    # CLUSTERPROは動作していない。
fi

# 終了コードが0の場合、EXECリソースの非活性処理は成功と判定される。
# スクリプト内でエラーが発生した場合には 0以外の終了コードを返却するように記述する。
exit 0

3.6.7. EXEC リソーススクリプト作成のヒント

以下の点に注意して、スクリプトを作成してください。

• スクリプト中にて、実行に時間を必要とするコマンドを実行する場合には、コマンドの実行が完了したことを示すトレースを残すようにしてください。この情報は、問題発生時、障害の切り分けを行う場合に使用することができます。トレースを残す方法は下記の 2 つがあります。

• スクリプト中に [echo] コマンドを記述して EXEC リソースのログ出力先を設定する方法

  トレースを [echo] コマンドにて標準出力することができます。その上で、スクリプトが属しているリソースのプロパティでログ出力先を設定します。
  デフォルトではログ出力されません。ログ出力先の設定については「詳細タブ」の「EXEC リソース調整プロパティ」にある「メンテナンスタブ」を参照してください。[ローテートする]チェックボックスがオフの場合は、ログ出力先に設定されたファイルには、サイズが無制限に出力されますのでファイルシステムの空き容量に注意してください。

  (例：スクリプト中のイメージ)

  echo "appstart.."
  appstart
  echo "OK"
  

• スクリプト中に clplogcmd を記述する方法

  clplogcmd で Cluster WebUI のアラートログや OS の syslog に、メッセージを出力できます。clplogcmd については、本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「メッセージを出力する (clplogcmd コマンド)」を参照してください。

  (例：スクリプト中のイメージ)

  clplogcmd -m "appstart.."
  appstart
  clplogcmd -m "OK"
  

3.6.8. EXEC リソース 注意事項

• スクリプトのログローテート機能について

  スクリプトのログローテート機能を有効にした場合、ログ出力を仲介するプロセス(仲介プロセス)が生成されます。仲介プロセスは、「開始・停止スクリプト」および「開始・停止スクリプトから標準出力・標準エラー出力のいずれかまたは両方を継承した子孫プロセス」からのログ出力が全て停止 (ファイルディスクリプタがクローズ) するまで動作を継続します。子孫プロセスの出力をログから除外する場合は、スクリプトからのプロセス生成時に標準出力および標準エラー出力をリダイレクトしてください。

• 開始スクリプト/終了スクリプトはroot ユーザで実行されます。

• 環境変数に依存するアプリケーションを起動する際には必要に応じてスクリプト側で環境変数の設定を行っていただく必要があります。

3.6.9. 詳細タブ

ユーザアプリケーション

スクリプトとしてサーバ上の実行可能ファイル (実行可能なシェルスクリプトやバイナリファイル) を使用します。各実行可能ファイル名は、サーバ上のローカルディスクのパスで設定します。

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

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

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

表示

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

編集

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

[ユーザアプリケーション] を選択している場合は [アプリケーション・パスの入力] ダイアログボックスが表示されます。

アプリケーション・パスの入力

EXEC リソースの実行可能ファイル名を設定します。

開始 (1023 バイト以内)

EXEC リソースの開始時の実行可能ファイル名を設定します。「/」 で始まる必要があります。引数を指定することも可能です。

終了 (1023 バイト以内)

EXEC リソースの終了時の実行可能ファイル名を設定します。「/」 で始まる必要があります。終了スクリプトは省略可能です。

実行可能ファイル名はクラスタサーバ上のファイルを 「/」 から始まる完全なパス名で設定する必要があります。引数を指定することも可能です。

置換

[この製品で作成したスクリプト] を選択した場合に、[ファイル選択] ダイアログボックスが表示されます。

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

調整

EXEC リソース調整プロパティダイアログを表示します。EXEC リソースの詳細設定を行います。EXEC リソースを PID モニタリソースで監視するには、開始スクリプトの設定を非同期にする必要があります。

EXEC リソース調整プロパティ

パラメータタブ

[開始スクリプト]、[終了スクリプト] 全スクリプト共通

同期

スクリプトの実行時にスクリプトの終了を待ちます。常駐しない (実行後に処理がすぐ戻る) 実行可能ファイルの場合に選択します。

非同期

スクリプトの実行時にスクリプトの終了を待ちません。常駐する実行可能ファイルの場合に選択します。

EXEC リソースの開始スクリプトを非同期で実行する場合は、PID モニタリソースで監視できます。

タイムアウト (1～9999)

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

待機系サーバで実行する

スクリプトを待機系サーバで実行するか否かを設定します。本パラメータを有効にした場合、待機系サーバで実行する際のタイムアウト (1～9999) が設定可能となります。

メンテナンスタブ

ログ出力先 (1023バイト以内)

EXEC リソースのスクリプトや実行可能ファイルの標準出力と標準エラー出力のリダイレクト先を指定します。何も指定しない場合、/dev/null に出力されます。「/」 で始まる必要があります。

[ローテートする]チェックボックスがオフの場合は無制限に出力されますのでファイルシステムの空き容量に注意してください。

[ローテートする]チェックボックスがオンの場合は、出力されるログファイルは、ローテートします。また、以下の注意事項があります。

• [ログの出力先] には 1009 バイト以内でログのパスを記述してください。1010 バイトを超えた場合、ログの出力が行えません。

• ログファイルの名前の長さは 31 バイト以内で記述してください。32 バイト以上の場合、ログの出力が行えません。

• EXEC リソースごとに異なるログファイル名を設定してください。

  複数の EXEC リソースでログローテートを行う場合、パス名が異なってもログファイルの名前が同じ場合(ex. /home/foo01/log/exec.log, /home/foo02/log/exec.log)、複数の EXEC リソースのログが、いずれか 1 つのログファイルに出力されます。また、ローテートサイズが正しく反映されないことがあります。

ローテートする

EXEC リソースのスクリプトや実行可能ファイルの実行ログを、オフの場合は無制限のファイルサイズで、オンの場合はローテートして出力します。

ローテートサイズ (1～999999999)

[ローテートする]チェックボックスがオンの場合に、ローテートするサイズを指定します。

ローテート出力されるログファイルの構成は、以下のとおりです。

ファイル名	内容
[ログ出力先]指定のファイル名	最新のログです。
[ログ出力先]指定のファイル名.pre	ローテートされた以前のログです。

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

3.7.1. ディスクリソースの依存関係

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

グループリソースタイプ
ダイナミック DNS リソース
フローティング IP リソース
仮想 IP リソース
ボリュームマネージャリソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
AWS DNS リソース
Azure DNS リソース

3.7.2. 切替パーティションとは?

切替パーティションとは、クラスタを構成する複数台のサーバに接続された共有ディスク上のパーティションのことを指します。

切替はフェイルオーバグループごとに、フェイルオーバポリシーにしたがって行われます。業務に必要なデータは、切替パーティション上に格納しておくことで、フェイルオーバ時、フェイルオーバグループの移動時などに自動的に引き継がれます。

注釈

ディスクタイプが「raw」の場合には、CLUSTERPRO が切替パーティションを OS の raw デバイスにマップ (bind) することで実現しています。また、ディスクリソース調整プロパティの[アンバインドを実行する]チェックボックスがオンの場合には、ディスクリソース非活性時にアンバインド処理を行います。

切替パーティションが全サーバで、同じデバイス名でアクセスできない場合は、サーバ個別設定を行ってください。

図 3.70 切替パーティション (1)

図 3.71 切替パーティション (2)

3.7.3. ディスクリソース制御下のデバイス領域拡張方法

対象デバイスの領域拡張は以下の手順で行ってください。 なお、以下の手順は必ず、該当ディスクリソースが活性しているサーバ上にて実行してください。

1. 該当ディスクリソースが所属するグループを、clpgrp コマンド等で非活性にしてください。

2. ディスクが mount されていないことを、mount コマンドや df コマンドを使用して確認します。

3. 該当ディスクリソースの種類に応じて、以下のコマンドを実行してディスクを Read Only から Read Write の状態にします。

   # clproset -w -d (デバイス名)

4. デバイスの領域拡張を実施します。

5. 該当ディスクリソースの種類に応じて、以下のコマンドを実行して、ディスクを Read Write から Read Only の状態にします。

   # clproset -o -d (デバイス名)

6. 該当ディスクリソースが所属するグループを、clpgrp コマンド等で活性にしてください。

3.7.4. ディスクリソースに関する注意事項

<ディスクリソース全般>

• ファイルシステムのアクセス制御 (mount/umount) は、CLUSTERPRO が行いますので、OS 側で mount/umount する設定を行わないでください。また、共有ディスクのファイルシステムを OS の /etc/fstab にエントリしないでください。(/etc/fstabへのエントリが必要な場合には、ignoreオプションは使用せずnoautoオプションを使用してください。)

• ディスクリソースに設定されたパーティションデバイス名はクラスタ内の全サーバでリードオンリーの状態になります。グループを活性するサーバで、活性時にリードオンリーは解除されます。

• クラスタプロパティの [拡張] タブで、[マウント、アンマウントコマンドを排他する] にチェックを入れている場合、ディスクリソース、ミラーリソースの mount/umount は同一サーバ内で排他的に動作するため、ディスクリソースの活性/非活性に時間がかかることがあります。

• マウントポイントにシンボリックリンクを含むパスを指定すると、異常検出時の動作に [強制終了] を選択しても強制終了できません。

  また、同様に「//」を含むパスを指定した場合にも、強制終了できません。

• OS 起動時にデバイス順序の入れ替わりを防止するには、udevデバイス(例：/dev/disk/by-id/[デバイス名])をデバイス名に設定してください。

• OS 上でランレベルの変更操作を行った際、デバイスのパスの故障/復旧が発生した際などに、ディスクリソースに設定されたパーティションデバイスのデバイスファイルが再作成され、その結果として、ディスクリソースに設定されたパーティションデバイスのリードオンリーが解除される場合があります。

<ディスクタイプ [LVM] での利用時>

• 本設定を利用する場合は、ボリュームマネージャリソースも併用してボリュームグループの制御を行うことを推奨します。詳細は本ガイド 「ボリュームマネージャリソースを理解する」を参照してください。

• ボリュームの定義は CLUSTERPRO 側で行いません。

• ファイルシステムに [zfs] を指定しないでください。

3.7.5. 詳細タブ

ディスクのタイプ サーバ個別設定可能

ディスクのタイプを指定します。以下の中から選択します。

• disk

• raw

• lvm

ファイルシステム (15バイト以内) サーバ個別設定可能

ディスクデバイス上に作成しているファイルシステムのタイプを指定します。以下の中から選択します。直接入力することもできます。[ディスクのタイプ] に [raw] 以外を設定した場合に設定が必要になります。

• ext3

• ext4

• xfs

• zfs

デバイス名 (1023バイト以内) サーバ個別設定可能

ディスクリソースとして使用するディスクデバイス名を選択します。直接入力することもできます。[ファイルシステム] が [zfs] 以外の場合は 「/」 で始まる必要があります。[ファイルシステム] が [zfs] の場合はZFSデータセット名を指定します。

RAWデバイス名 (1023バイト以内) サーバ個別設定可能

ディスクリソースとして使用する RAW ディスクデバイス名を設定します。[ディスクのタイプ] が[raw] の場合に設定が必要になります。

マウントポイント (1023バイト以内) サーバ個別設定可能

ディスクデバイスをマウントするディレクトリを設定します。「/」 で始まる必要があります。 [ディスクのタイプ] が [raw] 以外の場合に設定が必要になります。

調整

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

ディスクリソース調整プロパティ([ディスクのタイプ] が [raw] 以外の場合)

マウントタブ

マウントに関する詳細設定が表示されます。

マウントオプション (1023バイト以内)

ディスクデバイス上のファイルシステムをマウントする場合に [mount] コマンドへ渡すオプションを設定します。複数のオプションは [,(カンマ)] で区切ります。

マウントオプションの例

設定項目	設定値
デバイス名	/dev/sdb5
マウントポイント	/mnt/sdb5
ファイルシステム	ext3
マウントオプション	rw,data=journal

上記設定時に実行される [mount] コマンド

mount -t ext3 -o rw,data=journal /dev/sdb5 /mnt/sdb5

タイムアウト (1～999)

ディスクデバイス上のファイルシステムをマウントする場合の [mount] コマンドの終了を待つタイムアウトを設定します。ファイルシステムの容量が大きいと時間がかかる場合があります。設定する値が小さすぎないように注意してください。

リトライ回数 (0～999)

ディスクデバイス上のファイルシステムのマウントに失敗した場合のマウントリトライ回数を設定します。0 を設定するとリトライを実行しません。

既定値

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

アンマウントタブ

アンマウントに関する詳細設定が表示されます。

タイムアウト (1～999)

ディスクデバイス上のファイルシステムをアンマウントする場合の、[umount] コマンドの終了を待つタイムアウトを設定します。

リトライ回数 (0～999)

ディスクデバイス上のファイルシステムのアンマウントに失敗した場合の、アンマウントリトライ回数を指定します。0 を設定するとリトライを実行しません。

リトライインターバル (0～999)

ディスクデバイス上のファイルシステムのアンマウントに失敗した場合に、次のリトライを実行するまでの間隔を指定します。

異常検出時の強制動作

アンマウントに失敗後、アンマウントリトライする場合に実行する動作を下記より選択します。

• [強制終了]

  マウントポイントにアクセスしているプロセスの強制終了を試みます。必ずしもプロセスが強制終了できるとは限りません。
• [何もしない]

  マウントポイントにアクセスしているプロセスの強制終了を試みません。

既定値

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

fsckタブ

[fsck] に関する詳細設定が表示されます。ファイルシステムに[xfs] 以外を指定した場合に表示されます。ファイルシステムに [zfs] を指定した場合には無効となります。

fsckオプション (1023バイト以内)

ディスクデバイス上のファイルシステムをチェックする場合に [fsck] コマンドに渡すオプションを指定します。複数のオプションはスペースで区切って設定してください。ここで、[fsck] コマンドが対話形式にならないようにオプションを指定してください。[fsck] コマンドが対話形式になると、[fsck タイムアウト] が経過後リソースの活性がエラーになります。

fsckタイムアウト (1～9999)

ディスクデバイス上のファイルシステムをチェックする場合に [fsck] コマンドの終了を待つタイムアウトを指定します。ファイルシステムの容量が大きいと時間がかかる場合があります。設定する値が小さすぎないように注意してください。

Mount実行前のfsckアクション

ディスクデバイス上のファイルシステムをマウントする前の [fsck] の動作を下記より選択します。

• [必ず実行する]

  マウント前に [fsck] を実行します。
• [指定回数に達したら実行する]

  リソースが [回数] で指定する回数正常に活性した時に [fsck] を実行します。

  = 回数 (0～999)
• [実行しない]

  マウント前に [fsck] を実行しません。

注釈

[fsck] の指定回数はファイルシステムが管理しているチェックインターバルとは無関係です。

Mount失敗時のfsckアクション

ディスクデバイス上のファイルシステムのマウントに失敗した場合の [fsck] の動作を設定します。この設定は [マウントリトライ回数] の設定値が 0 以外の場合に有効になります。

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

  [fsck] を実行後、マウントのリトライを実行します。
• チェックボックスがオフ

  [fsck] を実行しないで、マウントのリトライを実行します。

注釈

Mount 実行前の [fsck アクション] が [実行しない] の場合との組み合わせは推奨しません。この設定では、ディスクリソースは [fsck] を実行しないため、切替パーティションに [fsck]で修復可能な異常があった場合、ディスクリソースをフェイルオーバできません

reiserfsの再構築

[reiserfsck] が修復可能なエラーで失敗した場合の挙動を指定します。

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

  [reiserfsck --fix -fixable] を実行します。
• チェックボックスがオフ

  [reiserfsck] が修復可能なエラーで失敗しても修復動作をしません。

既定値

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

xfs_repairタブ

[xfs_repair] に関する詳細設定が表示されます。ファイルシステムに[xfs] を設定した場合のみ表示されます。

xfs_repairオプション (1023バイト以内)

ディスクデバイス上のファイルシステムをチェックする場合に [xfs_repair] コマンドに渡すオプションを指定します。複数のオプションはスペースで区切って設定してください。

xfs_repairタイムアウト (1～9999)

ディスクデバイス上のファイルシステムをチェックする場合に [xfs_repair] コマンドの終了を待つタイムアウトを指定します。ファイルシステムの容量が大きいと時間がかかる場合があります。設定する値が小さすぎないように注意してください。

Mount失敗時のxfs_repairアクション

ディスクデバイス上のファイルシステムのマウントに失敗した場合の [xfs_repair] の動作を設定します。この設定は [マウントリトライ回数] の設定値が 0 以外の場合に有効になります。

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

  [xfs_repair] を実行後、マウントのリトライを実行します。
• チェックボックスがオフ

  [xfs_repair] を実行しないで、マウントのリトライを実行します。

既定値

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

ディスクリソース調整プロパティ([ディスクのタイプ] が [raw] の場合)

アンバインドタブ

アンバインドに関する詳細設定が表示されます。

アンバインドを実行する

RAWディスクデバイスのアンバインド実行有無を指定します。

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

  RAWディスクデバイスのアンバインドを実行します。
• チェックボックスがオフ

  RAWディスクデバイスのアンバインドを実行しません。

タイムアウト (1～999)

[アンバインドを実行する]チェックボックスがオンの場合に、RAWディスクデバイスのアンバインド処理の終了を待つタイムアウトを設定します。

リトライ回数 (1～999)

[アンバインドを実行する]チェックボックスがオンの場合に、RAWディスクデバイスのアンバインド処理に失敗した場合の、アンバインドリトライ回数を指定します。

既定値

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

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

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

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

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

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

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

[ifconfig] コマンドもしくは API を実行し、OS に IP アドレスを付与します。[ifconfig] コマンドもしくは API のどちらを実行するかは、フローティング IP リソースが自動的に判定します。[ifconfig] コマンドが以下のフォーマット以外の場合はAPI を実行します。

eth0    Link encap:Ethernet HWaddr 00:50:56:B7:1B:C0
        inet addr:192.168.1.113 Bcast:192.168.1.255 Mask:255.255.255.0
        inet6 addr: fe80::250:56ff:feb7:1bc0/64 Scope:Link
                           :

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

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

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

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

アドレスの割り当て

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

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

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

切替方式の仕組み

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

IPv6 の場合、ARP ブロードキャストは送信しません。

以下はCLUSTERPRO が送信する ARP ブロードキャストパケットの内容です。

図 3.74 CLUSTERPRO が送信する ARP ブロードキャストパケット

経路制御

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

使用条件

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

• クラスタサーバ自身

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

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

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

• 通信プロトコルが TCP/IP、もしくはSCTP/IP であること

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

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

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

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

• フローティング IP リソースが活性しているサーバでネットワーク再起動を実行しないでください。ネットワークを再起動するとフローティング IP リソースが追加した IP アドレスが削除されます。

• [ifconfig] コマンドのタイムラグによる IP アドレス重複について

  フローティング IP リソースで以下の設定の場合、リソースのフェイルオーバに失敗することがあります。

  • [活性リトライしきい値] に既定値より小さい値を設定している場合

  • [Ping リトライ回数]、[Ping インターバル] を設定していない場合

  この現象は以下の原因で発生します。

  • フェイルオーバ元となるサーバでフローティング IP アドレスを非活性後、[ifconfig] コマンドの仕様により IP アドレスの解放に時間がかかることがある

  • フェイルオーバ先のサーバからフローティング IP アドレスに対する [ping] コマンドが到達すると、リソース活性異常となる（二重活性を防止するため）

  この現象は以下の設定により回避できます。

  • リソースの [活性リトライしきい値] を大きくする (既定値 5 回)

  • [Ping リトライ回数]、[Ping インターバル] を大きくする

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

    

    図 3.75 フローティングIP構成 (1)（通常時）

    Server 1がダウンし、フェイルオーバが発生します。

    しかし、Server 1側でフローティングIPアドレス（FIP）の開放に時間がかかり、その間、Server 2から FIPへのpingが到達するため、FIPの重複と判断して、Server 2での活性は失敗します（ClientからFIPへのアクセス不可）。
    

    図 3.76 フローティングIP構成 (2)（フェイルオーバ失敗）

• OS ストール時の IP アドレス重複について

  フローティング IP アドレスを活性した状態で OS のストールが発生した場合、以下の設定の場合にリソースのフェイルオーバに失敗することがあります。

  • [Ping タイムアウト] に 0 以外を指定した場合

  • [FIP 強制活性] が OFF の場合

  この現象は以下の原因で発生します。

  • フローティング IP アドレスを活性した状態で以下のような OS の部分的なストールが発生

    • ネットワークモジュールは動作し、他ノードからの ping に反応する状態

    • ユーザ空間モニタリソースでストール検出不可の状態

  • フェイルオーバ先のサーバでフローティング IP アドレスの活性時に、二重活性防止のために活性予定のフローティング IP アドレスに対して [ping] コマンドを実行すると、上記のために ping が到達し、リソース活性異常となる

  この現象が多発するマシン環境では、以下の設定により回避できます。ただし、フェイルオーバ後、ストールの状況によってはグループの両系活性が発生することがあり、タイミングによってサーバシャットダウンが起こるので注意してください。両系活性の詳細は『メンテナンスガイド』の「保守情報」の「サーバダウンの発生条件」の「ネットワークパーティションからの復帰」を参照してください。

  • [Ping タイムアウト] に 0 を設定する

    フローティング IP アドレスに対して重複確認を行いません。
  • [FIP 強制活性] を On に設定する

    フローティング IP アドレスが他のサーバで使用されている場合でも、強制的にフローティング IP アドレスを活性します。

• pingタイムアウトの設定が0以外かつFIP強制活性がOFFの場合

  Server 1のOSがストールしたため、FIPが活性状態のままフェイルオーバが発生します。 しかしその直後は、Server 2でFIP活性前に実行したpingコマンドに対して応答が返ります。 そのため、二重活性が発生することのないよう、Server 2におけるFIP活性は失敗します。

  

  図 3.77 pingタイムアウトの設定が0以外かつFIP強制活性がOFFの場合

• pingタイムアウトが0の場合

  Server 1のOSがストールしたため、FIPが活性状態のままフェイルオーバが発生します。 Server 2ではFIPに対するpingコマンドを実行せず、Server 2におけるFIP活性は成功します。

  

  図 3.78 pingタイムアウトが0の場合

• pingタイムアウトの設定が0以外かつFIP強制活性がONの場合

  Server 1のOSがストールしたため、FIPが活性状態のままフェイルオーバが発生します。 Server 2ではFIPに対するpingコマンドを実行しますが、その結果に関係なく、Server 2におけるFIP活性は強制的に成功します。

  

  図 3.79 pingタイムアウトの設定が0以外かつFIP強制活性がONの場合

• フローティング IP が割り当てられる仮想 NIC の MAC アドレスについて

  フローティング IP が割り当てられる仮想 NIC の MAC アドレスは、実 NIC の MACアドレスとなります。そのため、フローティング IP リソースがフェイルオーバすると、対応する MAC アドレスが変更されます。
• リソース活性時の現用系サーバからの IP 通信のソースアドレスについて

  サーバからの IP 通信の送信元アドレスは、フローティング IP リソースが活性している場合でも基本的にサーバの実 IP となります。送信元アドレスをフローティング IP に変更したい場合はアプリケーション側で設定が必要です。

• FIP強制活性をオンに設定した場合、フローティング IP アドレスを起動した後に同じネットワークセグメント上のマシンからフローティング IP アドレスに接続すると、先に存在していた IP アドレスのマシンに接続することがあります。

• フローティング IP リソースは OpenVPN が起動している環境での動作に対応しておりません。

• フローティング IP リソースでは、IPアドレスを付与する NIC 名(ネットワークインタフェース名、例：eth0)の長さは15文字が上限です。15文字を超える場合は、活性異常になります。その際は NIC 名(ネットワークインタフェース名)を見直してください。

• フローティング IP リソースは活性する前に、重複した IP アドレスがないかチェックするために [ping] を発行しています。このため、重複 IP アドレスを保持するネットワーク機器がファイアウォールなどで ICMP の受信拒否を設定している場合は [ping] コマンドを使用した重複 IP アドレスの確認が行えないため、フローティングIPアドレスが重複することがあります。

• 送信元設定を有効にするフローティング IP リソースは、各ネットワークアドレスにつき1つのみとしてください。同じネットワークアドレスに送信元設定を有効にした FIP アドレスが既に存在する場合は活性に失敗します。

• 送信元設定を有効にするフローティング IP リソースの IP アドレスには、ミラーディスクコネクトと異なるサブネットの IP アドレスを指定してください。

• 送信元変更機能は、既存の経路情報を変更します。

• 送信元変更機能は、IPv6 の IP アドレスに対しては使用できません。

3.8.4. フローティング IP リソース非活性待ち合わせ処理

フローティング IP アドレスの非活性化を実行した後に以下の処理を行います。

1. 待ち合わせ処理

   • [ifconfig] コマンドもしくは API を実行し、OS に付加されている IP アドレスの一覧を取得します。[ifconfig] コマンドもしくは API のどちらを実行するかは、フローティング IP リソースが自動的に判定します。IP アドレスの一覧にフローティング IP アドレスが存在しなければ非活性と判断します。

   • IP アドレスの一覧にフローティング IP アドレスが存在する場合は、 1 秒間待ち合わせます。待ち合わせ時間は Cluster WebUI では変更できません。

   • 上記の処理を最大 4 回繰り返します。この回数は Cluster WebUI で変更できません。

   • この結果が異常となった場合にフローティング IP リソースを非活性異常とするかしないかは、フローティング IP リソースの非活性確認タブの [I/F の削除確認を行う] の [異常検出時のステータス] で変更します。

2. [ping] コマンドによる非活性確認処理

   • [ping] コマンドを実行し、フローティング IP アドレスからの応答有無を確認します。フローティング IP アドレスから応答がなければ非活性と判断します。

   • フローティング IP アドレスから応答がある場合は、1 秒間待ち合わせます。待ち合わせ時間は Cluster WebUI では変更できません。

   • 上記の処理を最大 4 回繰り返します。この回数は Cluster WebUI で変更できません。

   • [ping] コマンドはタイムアウト 1 秒で実行します。このタイムアウトは Cluster WebUI で変更できません。

   • この結果が異常となった場合にフローティング IP リソースを非活性異常とするかしないかは、フローティング IP リソースの非活性確認タブの [I/F の応答確認を行う] の [異常検出時のステータス] で変更します。

注釈

[ifconfig] コマンドによる IP アドレス一覧の取得、および [ifconfig] コマンドによるフローティング IP リソースの活性/非活性の各処理は 60 秒 （デフォルト） でタイムアウトします。

このタイムアウトは Cluster WebUI で変更できます。詳しくは、「詳細タブ」の「フローティング IP リソース調整プロパティ」の「パラメータタブ」を参照してください。

3.8.5. 詳細タブ

IPアドレス サーバ個別設定可能

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

bonding または タグVLANの使用有無に関わらず、以下の例のように設定してください。

※ bonding 環境の補足説明は本ガイドの「8. その他の設定情報」の「bonding」を参照してください。

例） 10.0.0.12

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

マスクビット数を明示的に指定する場合は、アドレスの後、[/マスクビット数] を指定します。(IPv6アドレスの場合は必ず[/マスクビット数]を指定してください)

例） 10.0.0.12/8、 fe80::1/8

ネットワークインタフェースを明示的に指定する場合、アドレスの後、[%インタフェース名] を指定します。

例） 10.0.0.12%eth1、fe80::1/8%eth1

上記の例ではネットワークインタフェースeth1 にマスクビット数8のフローティング IP アドレスを追加します。

IPv6アドレスかつ[ifconfig] コマンドが利用可能な環境の場合、大文字と小文字を区別して判定するため、ifconfig コマンドの出力書式とフローティング IP の IP アドレスの書式を一致させてください。

調整

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

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

パラメータタブ

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

ifconfig

IP アドレス一覧の取得、および [ifconfig] コマンドによるフローティング IP リソースの活性/非活性の各処理で実行される [ifconfig] コマンドに関する詳細設定です。

• タイムアウト (1～999)

  [ifconfig] コマンドのタイムアウトを設定します。[ifconfig] コマンドが利用できない環境の場合は、本パラメータは影響がないため、既定値である60(秒)を設定してください。

ping

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

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

  [ping] コマンドを発行する間隔を設定します。
• タイムアウト (0～999)

  [ping] コマンドのタイムアウトを設定します。

  0 を設定すると [ping] コマンドは実行されません。
• リトライ回数 (0～999)

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

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

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

  強制活性を行いません。

ARP 送信回数 (0～999)

フローティング IP リソースを活性化する場合に送信する ARP パケットの送信回数を設定します。0 を設定すると ARP パケットを送信しません。

NIC Link Down を異常と判定する

フローティング IP リソースを活性する前に、NIC Link Downの確認を行うかどうかを設定します。NIC のボード、ドライバによっては、必要な ioctl( ) がサポートされていない場合があります。NIC の Link Up/Down 監視の動作可否は、各ディストリビュータが提供する [ethtool]コマンドで確認することができます。[ethtool]コマンドでの確認方法は、本ガイドの「NIC Link Up/Down モニタリソースを理解する」 - 「NIC Link Up/Down モニタリソースの注意事項」を参照してください。

bonding デバイスの場合、活性時に bonding を構成するすべての NIC が Link Down 状態であれば異常と判定します。

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

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

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

送信元変更機能を使用する

フローティング IP アドレスを送信元にするかどうかを設定します。

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

  フローティング IP アドレスが所属するネットワークについて、フローティング IP アドレスを送信元とする経路情報を追加します。
• チェックボックスがオフ

  送信元変更機能を使用しません。

既定値

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

非活性確認タブ

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

I/F の削除確認

• I/F の削除確認を行う

  フローティング IP を非活性した後に、該当のフローティング IPアドレスが正常に消滅したことを確認するかどうかの設定を設定します。
• チェックボックスがオン

  確認処理を行います。
• チェックボックスがオフ

  確認処理を行いません。
• 異常検出時のステータス

  結果が異常となった場合にフローティングIP リソースの非活性異常をどう扱うかを設定します。
• 異常にする

  フローティング IP リソースの非活性異常として扱います。
• 異常にしない

  フローティング IP リソースの非活性異常として扱いません。

I/F の応答確認

• I/F の応答確認を行う

  フローティング IP を非活性した後に、[ping] コマンドで該当のフローティング IPアドレスが正常に消滅したことを確認するかどうかの設定を設定します。
• チェックボックスがオン

  確認処理を行います。
• チェックボックスがオフ

  確認処理を行いません。
• 異常検出時のステータス

  [ping] コマンドでフローティング IP に到達できた場合にフローティング IP リソースの非活性異常をどう扱うかを設定します。
• 異常にする

  フローティング IP リソースの非活性異常として扱います。
• 異常にしない

  フローティング IP リソースの非活性異常として扱いません。

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

3.9.1. 仮想 IP リソースの依存関係

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

3.9.2. 仮想 IP とは?

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

IP アドレス一覧の取得、および仮想 IP リソースの活性/非活性の各処理では[ifconfig] コマンドもしくは API を実行します。[ifconfig] コマンドもしくは API のどちらを実行するかは、仮想 IP リソースが自動的に判定します。以下に例を示します。

• RHEL 7 以降(RHEL 7 互換OS含む)のように[ifconfig] コマンドが利用できない環境の場合：API を実行。

• RHEL 7 以降(RHEL 7 互換OS含む)にてnet-toolsパッケージにより[ifconfig] コマンドが利用可能な環境の場合：API を実行。これは[ifconfig] コマンドの出力形式が RHEL 6 以前と互換性がないためです。

• RHEL 6 のように[ifconfig] コマンドが利用可能な環境の場合：[ifconfig] コマンドを実行。

  

  図 3.80 仮想IPを使用した構成 (1)

  

  図 3.81 仮想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.9.3. 仮想 IP アドレスの検討

仮想 IP アドレスに割り当てる IP アドレスは、以下の条件を満たす必要があります。

• クラスタサーバが所属する LAN の、ネットワークアドレスの範囲外である

• 既存のネットワークアドレスと衝突しない

この 2 つの条件を満たすために、以下の 2 つの割り当て方法で、いずれかを選択してください。

• 仮想 IP アドレス用に新たに正当なネットワーク IP アドレスを取得し、そこから仮想 IP アドレスを割り当てる。

• プライベート IP アドレス空間から、適当なネットワーク IP アドレスを決定し、そこからそれぞれの仮想 IP アドレスを割り当てます。具体例を示すと、以下のような手順になります。

  • ネットワークアドレス 192.168.0～192.168.255 から、仮想 IP アドレス用に 1 つ選択します。

  • 上記で選択したネットワークアドレスの中から、仮想 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 アドレスは、組織内で閉じたネットワークのためのアドレスであるため、インターネットプロバイダ等を隔てた組織外から、仮想 IP アドレスを用いてアクセスはできません。

• プライベート IP アドレスに関する経路情報を、組織外に流してはいけません。

• プライベート IP アドレスの衝突が起こらないよう、組織内での調整が必要です。

3.9.4. 仮想 IP リソースを使用する場合の事前準備

クラスタ構成が以下の条件に該当する場合、各サーバに仮想 IP アドレスと同じネットワークアドレスのダミーの仮想 IP アドレスを設定する必要があります。

• 複数の仮想 IP リソースが存在する

• ネットワークアドレスと NIC エイリアス名が同じリソースが存在する

注釈

ダミーの仮想 IP アドレスが設定できない場合、任意の仮想 IP リソースの非活性時に同じ NIC エイリアスに付与されている他の仮想 IP アドレスも OS より削除される場合があります。

ダミーの仮想 IP アドレスは、以下の条件を満たす必要があります。

• 仮想 IP リソースの IP アドレスと同じネットワークアドレスで、固有の IP アドレスである

• クラスタを構成する各サーバ用にダミーの仮想 IP アドレスを用意できる

• NIC エイリアス毎に用意する

以下の設定例の場合、各サーバにダミーの仮想 IP アドレスの設定が必要です。

• 仮想 IP リソース 1

  IP アドレス 10.0.1.11/24

  NIC エイリアス名 eth1
• 仮想 IP リソース 2

  IP アドレス 10.0.1.12/24

  NIC エイリアス名 eth1

例としてダミーの仮想 IP アドレスを以下のように設定します。

• Server 1 のダミー仮想 IP アドレス

  IP アドレス 10.0.1.100/24

  NIC エイリアス名 eth1:0
• Server 2 のダミー仮想 IP アドレス

  IP アドレス 10.0.1.101/24

  NIC エイリアス名 eth1:0

ダミーの仮想 IP アドレスが OS 起動時に有効になるように以下の手順で OS へ設定してください。

以下の手順はServer 1 の eth1 に 10.0.1.100/24 を設定する例です。

1. ディストリビューションごとに下記の設定を行います。

• SUSE LINUX Enterprise Server の場合

  下記のパスのファイルを編集し、設定内容の斜体部分を追加します。

  パス

  /etc/sysconfig/network/ifcfg-eth1-"eth1のMACアドレス"

  設定内容

  BOOTPROTO='static'
  BROADCAST='10.0.0.255'
  IPADDR='10.0.0.1'
  MTU=''
  NETMASK='255.255.255.0'
  NETWORK='10.0.0.0'
  IPADDR_1='10.0.1.100'
  NETMASK_1='255.255.255.0'
  NETWORK_1='10.0.1.0'
  LABEL_1=1
  REMOTE_IPADDR=''
  STARTMODE='onboot'
  UNIQUE='xxxx'
  _nm_name='xxxx'

• SUSE LINUX Enterprise Server 以外の場合

  下記のパスのファイルを作成し、設定内容を追加します。

  パス

  /etc/sysconfig/network-scripts/ifcfg-eth1:0
  

  設定内容

  DEVICE=eth1:0
  BOOTPROTO=static
  BROADCAST=10.0.1.255
  HWADDR=eth1のMACアドレス
  IPADDR=10.0.1.100
  NETMASK_1='255.255.255.0'
  NETWORK=10.0.1.0
  ONBOOT=yes
  TYPE=Ethernet
  

2. OS を再起動します。

OS 再起動後にダミーの仮想 IP アドレスが有効になります。Server 2 も同様に設定してください。

クラスタの構成変更で上記の設定が必要になった場合は、以下の手順で行ってください。

1. クラスタを停止します。手順は『インストール&設定ガイド』の「運用開始前の準備を行う」 - 「CLUSTERPRO を一時停止する」 - 「CLUSTERPROデーモンの停止」を参照してください。

2. クラスタデーモンを無効にします。手順は『インストール&設定ガイド』の「運用開始前の準備を行う」 - 「CLUSTERPRO を一時停止する」 - 「CLUSTERPRO デーモンの無効化」を参照してください。

3. 上記の設定を変更します。

4. OS を再起動して、設定が反映されていることを確認します。

5. クラスタデーモンを有効にします。手順は『インストール&設定ガイド』の「運用開始前の準備を行う」 - 「CLUSTERPRO を一時停止する」 - 「無効化したCLUSTERPROデーモンを有効にする」を参照してください。

6. クラスタの構成を変更します。手順は『インストール&設定ガイド』の「クラスタ構成情報を変更する」を参照してください。

3.9.5. 経路制御

リモート LAN から仮想 IP アドレスにアクセスするために、リモート LAN とクラスタサーバの LAN まで経路上の全てのルータに、仮想 IP アドレスの経路情報が有効になっていなければなりません。

具体的には、以下のような設定が必要です。

• クラスタサーバの LAN 上のルータがホスト RIP を解釈する。

• クラスタサーバからリモートサーバまでの経路上のルータが、全て動的経路制御であるか、または仮想 IP アドレスの経路に関する情報が、静的経路情報として設定されている。

3.9.6. 仮想 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.9.7. 仮想 IP リソースに関する注意事項

• 仮想 IP リソースが活性しているサーバでネットワーク再起動を実行しないでください。ネットワークを再起動すると仮想 IP リソースが追加した IP アドレスが削除されます。

仮想 IP アドレスには、以下の規則があります。

• 仮想 IP リソースが正常に非活性されない場合 (サーバダウン時など)、仮想 IP リソースの経路情報が削除されません。経路情報が削除されない状態で仮想 IP リソースが活性した場合、ルータまたはルーティングデーモンが経路情報をリセットするまで仮想 IPアドレスにアクセスできません。

  このため、ルータまたはルーティングデーモンのフラッシュタイマーの設定時間を調整する必要があります。フラッシュタイマーの設定時間は、ハートビートタイムアウト以内になるように調整してください。ハートビートタイムアウトに関しては、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「タイムアウトタブ」を参照してください。

• 仮想 IP が割り当てられる仮想 NIC の MAC アドレスについて

  仮想 IP が割り当てられる仮想 NIC の MAC アドレスは、実 NIC の MAC アドレスとなります。そのため、仮想 IP リソースがフェイルオーバすると、対応する MAC アドレスが変更されます。

• リソース活性時の現用系サーバからの IP 通信のソースアドレスについて

  サーバからの IP 通信の送信元アドレスは、仮想 IP リソースが活性している場合でも基本的にサーバの実 IP となります。送信元アドレスを仮想 IP に変更したい場合はアプリケーション側で設定が必要です。

• 使用するルーティングプロトコルについて

  使用するルーティングプロトコルを「RIPver2」に設定した場合、送出するRIPパケット内のサブネットマスクは「255.255.255.255」となります。

3.9.8. 詳細タブ

IPアドレス サーバ個別設定可能

使用する仮想 IP アドレスを入力します。マスクビット数を明示的に指定する場合は、アドレスの後、[/マスクビット数] を指定します。(IPv6アドレスの場合は必ず[/マスクビット数]を指定してください)

NICエイリアス名 サーバ個別設定可能

使用する仮想 IP アドレスを活性する NIC インタフェース名を入力します。

宛先IPアドレス サーバ個別設定可能

RIP パケットの送出先 IP アドレスを入力します。IPv4 はブロードキャストアドレス、IPv6 はルータの IPv6 アドレスを指定します。

送信元IPアドレス サーバ個別設定可能

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 リソース調整プロパティ

パラメータタブ

仮想 IP リソースのパラメータに関する詳細設定が表示されます。

ifconfig

IP アドレス一覧の取得、および仮想 IP リソースの活性/非活性の各処理で実行される [ifconfig] コマンドに関する詳細設定です。

• タイムアウト (1～999)

  [ifconfig] コマンドのタイムアウトを設定します。[ifconfig] コマンドが利用できない環境の場合は、本パラメータは影響がないため、既定値である60(秒)を設定してください。

ping

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

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

  [ping] コマンドを発行する間隔を設定します。
• タイムアウト (0～999)

  [ping] コマンドのタイムアウトを設定します。

  0 を設定すると [ping] コマンドは実行されません。
• リトライ回数 (0～999)

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

  [ping] コマンドによるチェックで重複した IP アドレスが検出された場合に、仮想 IP アドレスを強制的に活性するかどうかを設定します。
• チェックボックスがオン

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

  強制活性を行いません。

ARP送信回数 (0～999)

仮想 IP リソースを活性化する場合に送信する ARP パケットの送信回数を設定します。 0 を設定すると ARP パケットを送信しません。

NIC Link Down を異常と判定する

仮想 IP リソースを活性する前に、NIC Link Downの確認を行うかどうかを設定します。NIC のボード、ドライバによっては、必要な ioctl( ) がサポートされていない場合があります。NIC の Link Up/Down 監視の動作可否は、各ディストリビュータが提供する [ethtool]コマンドで確認することができます。[ethtool]コマンドでの確認方法は、本書の「NIC Link Up/Down モニタリソースを理解する」 - 「NIC Link Up/Down モニタリソースの注意事項」を参照してください。

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

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

  NIC Link Downの場合でも、仮想 IP リソースを活性化します。既存の動作と同じです。

既定値

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

非活性確認タブ

仮想 IP リソースの非活性確認に関する詳細設定が表示されます。

I/F の削除確認

• I/F の削除確認を行う

  仮想 IP を非活性した後に、該当の仮想 IPアドレスが正常に消滅したことを確認するかどうかを設定します。
• チェックボックスがオン

  確認処理を行います。
• チェックボックスがオフ

  確認処理を行いません。
• 異常検出時のステータス

  結果が異常となった場合に仮想 IP リソースの非活性異常をどう扱うかを設定します。
• 異常にする

  仮想 IP リソースの非活性異常として扱います。
• 異常にしない

  仮想 IP リソースの非活性異常として扱いません。

I/F の応答確認

• I/F の応答確認を行う

  仮想 IP を非活性した後に、[ping] コマンドで該当の仮想 IPアドレスが正常に消滅したことを確認するかどうかを設定します。
• チェックボックスがオン

  確認処理を行います。
• チェックボックスがオフ

  確認処理を行いません。
• 異常検出時のステータス

  [ping] コマンドで仮想 IP に到達できた場合に仮想 IP リソースの非活性異常をどう扱うかを設定します。
• 異常にする

  仮想 IP リソースの非活性異常として扱います。
• 異常にしない

  仮想 IP リソースの非活性異常として扱いません。

RIPタブ

仮想 IP リソースの RIP に関する詳細設定が表示されます。

メトリック (1～15)

RIP のメトリック値を入力します。メトリックは宛先に到達するための RIP のホップカウントです。

ポート

[ポート番号] には RIP の送信に使用する通信ポートの一覧が表示されます。

追加

RIP の送信に使用するポート番号を追加します。[ポート番号の入力] ダイアログボックスが表示されます。

ポート番号

RIP の送信に使用するポート番号を入力して [OK] を選択してください。

編集

[ポート番号の入力] ダイアログボックスが表示されます。[ポート番号] で選択しているポートが表示されるので、編集して [OK] を選択します。

削除

[ポート番号] で選択しているポートをリストから削除します。

RIPngタブ

仮想 IP リソースの RIPng に関する詳細設定が表示されます。

メトリック (1～15)

RIPng のメトリック値を入力します。メトリックは宛先に到達するための RIPng のホップカウントです。

ポート

[ポート番号] には RIPng を送信するポート番号の一覧が表示されます。

追加

RIPng の送信に使用するポート番号を追加します。[ポート番号の入力] ダイアログボックスが表示されます。

ポート番号

RIPng の送信に使用するポート番号を入力して [OK] を選択してください。

編集

[ポート番号の入力] ダイアログボックスが表示されます。[ポート番号] で選択しているポートが表示されるので、編集して [OK] を選択します。

削除

[ポート番号] で選択しているポートをリストから削除します。

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

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

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

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース

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

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

以下の図で、Server 1に接続されている Mirror disk 1 および Server 2に接続されている Mirror disk 2は、ペアとしてディスクデータのミラーリングを行います。

図 3.82 ミラーディスク構成 (1)

図 3.83 ミラーディスク構成 (2)

データパーティション

ミラーリングするデータ (業務データなど) を格納するパーティションのことを、データパーティションといいます。

データパーティションは以下のように割り当ててください。

• データパーティションのサイズ

  1GB 以上、1TB 未満のパーティションを確保してください。

  ※ データの構築時間、復旧時間の観点より、1TB 未満のサイズを推奨します。
• パーティション ID

  83 (Linux)
• ファイルシステムは、ミラーリソースの mkfs の設定が [する] の場合にはクラスタ生成時に自動的に構築されます。
• ファイルシステムのアクセス制御 (mount/umount) は、CLUSTERPRO が行いますので、OS 側でデータパーティションを mount/umount する設定を行わないでください。

クラスタパーティション

CLUSTERPRO がミラーパーティション制御のために使用する専用パーティションを、クラスタパーティションといいます。

クラスタパーティションは以下のように割り当ててください。

• クラスタパーティションのサイズ

  最低 1024MiB 確保してください。ジオメトリによって 1024MB 以上になる場合がありますが、1024MB 以上でも問題ありません。
• パーティション ID

  83 (Linux)
• クラスタパーティションは、データミラーリング用のデータパーティションとペアで割り当てる必要があります。
• クラスタパーティションにファイルシステムを構築しないでください。
• ファイルシステムのアクセス制御 (mount/umount) は、CLUSTERPRO がミラーパーティションデバイスをマウントするデバイスとして行いますので、OS 側でクラスタパーティションを mount/umount する設定を行わないでください。

ミラーパーティションデバイス (/dev/NMPx)

1 つのミラーディスクリソースで 1 つのミラーパーティションデバイスをファイルシステムに提供します。ミラーディスクリソースとして登録すると、 1 台のサーバ (通常はリソースグループのプライマリサーバ) からのみアクセス可能になります。

通常、ユーザ (AP) はファイルシステムを経由して I/O を行うため、ミラーパーティションデバイス (dev/NMPx) を意識する必要はありません。Cluster WebUI で情報を作成するときに重複しないようにデバイス名を割り当てます。

• ファイルシステムのアクセス制御 (mount/umount) は、CLUSTERPRO が行いますのでOS 側でミラーパーティションデバイスを mount/umount する設定を行わないでください。

  業務アプリケーションなどからの、ミラーパーティション (ミラーディスクリソース) へのアクセス可否の考え方は、共有ディスクを使用した切替パーティション (ディスクリソース) と同じです。

• ミラーパーティションの切り替えは、フェイルオーバグループごとにフェイルオーバポリシーにしたがって行われます。

ミラーディスクコネクト

ミラーディスクリソースごとに最大 2 つのミラーディスクコネクトを登録できます。

• 2 つのミラーディスクコネクトを登録した場合、切替時の動作などは以下のようになります。

  • ミラーデータの同期に使用する経路を二重化することができます。1 つのミラーディスクコネクトが断線等で使用できなくなった場合でもミラーデータを同期することができます。

  • ミラーリングの速度は変わりません。

  • データ書き込み中にミラーディスクコネクトが切り替わる場合には、一時的にミラーブレイク状態になり、ミラーディスクコネクトの切替が完了した後で差分ミラー復帰が実行されることがあります。

  • ミラー復帰中にミラーディスクコネクトが切り替わる場合には、ミラー復帰が中断されることがあります。自動ミラー復帰を行う設定にしている場合には、ミラーディスクコネクトの切替が完了した後でミラー復帰が自動的に再開されます。自動ミラー復帰を行わない設定の場合には、ミラーディスクコネクトの切替が完了した後でミラー復帰を再実行する必要があります。

ミラーディスクコネクトの設定に関しては、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「インタコネクトタブ」を参照して下さい。

• ディスクのパーティション

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

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

    OS (root パーティションや swap パーティション) と別にミラー用のディスクを用意することを推奨します。
  • H/W RAID の仕様の制限で LUN の追加ができない場合

    H/W RAID のプリインストールモデルで LUN 構成変更が困難な場合

    
    

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

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

  

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

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

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

  

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

• ディスクの配置

  ミラーディスクとして複数のディスクを使用することができます。

  また 1 つのディスクに複数のミラーパーティションデバイスを割り当てて使用することができます。

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

  以下の図は、同サイズのパーティションを確保したディスクのペア2つを、ミラーパーティションとして使用する場合を示しています。

  

  図 3.86 各ディスクをミラーパーティションにする場合

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

  図は各ディスクに、クラスタパーティションのほか同サイズのパーティションを2つ確保し、データパーティションとして使用する場合を示しています。

  

  図 3.87 ディスク内の複数領域をミラーパーティションにする場合

3.10.3. ミラーパラメータ設定の考え方

ミラーデータポート番号

ミラードライバ間でミラーデータの送受信に使用する TCP ポート番号を設定します。ミラーディスクリソースごとに設定する必要があります。

Cluster WebUI でミラーディスクリソースを追加する場合に下記の条件で初期値が表示されます。

• 29051 以降のポート番号で、未使用かつ最小のポート番号

ハートビートポート番号

ミラードライバ間で制御用データの通信を行う TCP ポート番号を設定します。ミラーディスク リソースごとに設定する必要があります。

Cluster WebUI でミラーディスクリソースを追加する場合に下記の条件で初期値が表示されます。

• 29031 以降のポート番号で、未使用かつ最小のポート番号

ACK2 ポート番号

ミラードライバ間で制御用データの通信を行う TCP ポート番号を設定します。ミラーディスク リソースごとに設定する必要があります。

Cluster WebUI でミラーディスクリソースを追加する場合に下記の条件で初期値が表示されます。

• 29071 以降のポート番号で、未使用かつ最小のポート番号

リクエストキューの最大数

ミラーディスクドライバが上位からの I/O 要求（書き込み要求）をキューイングするためのキューの個数を設定します。大きくすると書き込みのパフォーマンスが向上しますが、物理メモリを多く消費します。

以下を目安に設定してください。

• 以下のような条件では大きくすると性能向上が期待できます。

  • サーバに物理メモリが多く搭載されていて空きメモリサイズが十分ある。

接続タイムアウト

ミラー復帰やデータ同期時に、サーバ間通信の接続成功を待つタイムアウトです。

送信タイムアウト

このタイムアウトは以下で使用します。

• ミラー復帰やデータ同期時に、現用系サーバが待機系サーバに write データを送信開始してから送信完了を待つまでのタイムアウト。

  

  図 3.88 送信タイムアウト（writeデータ）

  ※詳細には、ネットワーク(TCP)の送信バッファへ送信データを格納開始してから、格納が完了するまでのタイムアウト。TCPのバッファがいっぱいになっていて、空きができない場合にタイムアウトが発生する。

• 現用系サーバが待機系サーバへ write 完了通知の ACK を送信する処理にて、送信するACKがあるかどうか、送信の要否を確認する時間間隔。

  

  図 3.89 送信タイムアウト（ACK送信チェック）

受信タイムアウト

このタイムアウトは以下で使用します。

• 待機系サーバが現用系サーバからの write データを受信開始してから受信完了を待つまでのタイムアウト。

  

  図 3.90 受信タイムアウト

Ackタイムアウト

このタイムアウトは下記に使用します。

• 現用系サーバが待機系サーバへ write データを送信開始してから待機系サーバからのwrite 完了通知の ACK の受信を待つまでのタイムアウト。

  タイムアウト以内に、ACK を受信できなかった場合、現用系サーバ側の差分ビットマップに差分情報を蓄積します。
  

  図 3.91 ACKタイムアウト（待機系サーバからのACK受信）

  ※モードが同期モードに設定されている場合には、アプリケーションへの応答が、ACK受信またはACK受信がタイムアウトするまで、待たされることがあります。モードが非同期モードに設定されている場合には、アプリケーションへの応答は現用系のディスクへ書き込み後、ACKを待たずに、返ります。

• 待機系サーバが現用系サーバへの write 完了通知の ACK を送信完了してから、現用系サーバの ACK の受信を待つまでのタイムアウト。

  タイムアウト以内に、現用系サーバの ACK を受信できなかった場合、待機系サーバ側の差分ビットマップに差分情報を蓄積します。
  

  図 3.92 ACKタイムアウト（現用系サーバからのACK受信）

• ミラー復帰時に、コピー元サーバが復帰データ送信を開始してから、コピー先サーバからの完了通知の ACK を待つまでのタイムアウト。

  

  図 3.93 ACKタイムアウト（復帰データACK受信）

  ※後述の「復帰データサイズ」の量の復帰データ送信に対して、ACKが1つ返ります。従って、復帰データサイズを大きくすると、効率は良くなりますが、ACKタイムアウト等が発生した場合に再送信が必要になる量も多くなります。

ハートビートインターバル(1～600)

2台のサーバのミラードライバ間で、ミラーディスクコネクトの健全性を確認するために行われるハートビートの間隔(秒)です。通常はデフォルトのままで使用してください。

ICMP Echo Reply 受信タイムアウト(1～100)

2台のサーバのミラードライバ間で、ミラーディスクコネクトの健全性を確認するために行われるハートビートで利用される値です。ICMP Echo Requestを送信してから、相手サーバからのICMP Echo Replyを受信するまでの最大待ち時間です。本タイムアウト値を経過してもICMP Echo Replyを受信できなかった場合、最大で後述のICMP Echo Request リトライ回数分まで繰り返されます。通常はデフォルトのままで使用してください。

図 3.94 ICMP Echo Reply 受信タイムアウト

ICMP Echo Request リトライ回数(1～50)

ICMP Echo Request に対する相手サーバからの ICMP Echo Reply が前述のICMP Echo Reply 受信タイムアウトまでに受信出来なかった際に ICMP Echo Request の送信をリトライする、最大送信回数です。通常はデフォルトのままで使用してください。

ICMP Echo Reply 受信タイムアウトとICMP Echo Request リトライ回数を調整することでミラーディスクコネクト断線と判断する感度を調整できます。

• 値を大きくする

  • 遠隔地のようにネットワーク遅延が発生するような場合

  • ネットワークの一時的な障害が発生するような場合

• 値を小さくする

  • ネットワーク障害を検出するまでの時間を短くしたい場合

差分ビットマップ更新インターバル

差分ビットマップへ書き込む情報は一時的にメモリ上に蓄えられ、一定間隔でクラスタパーティションへ書き出されます。待機系サーバでその書き出す情報の有無をチェックして書き出しをおこなう、時間間隔です。

差分ビットマップサイズ

差分ビットマップのサイズを指定します。

データパーティションのサイズが大きい場合、差分ビットマップのサイズを大きくすることで差分コピーの効率が向上することがあります。

ただし、メモリ効率が悪化するため、通常は既定値のままお使いください。

なお、この設定はミラーディスクリソースおよびハイブリッドディスクリソースをクラスタに作成する前に設定する必要があります。これらのリソースがクラスタ内に存在する場合は変更することができません。

初期ミラー構築

クラスタ構築後の初回起動時に初期ミラー構築を行う挙動を設定します。

• 初期ミラー構築を行う

  クラスタ構築後の初回起動時に初期ミラー構築を行います。

  ext3/ext4/xfs とその他のファイルシステムでは、初期ミラー構築にかかる時間が異なります。
• 初期ミラー構築を行わない

  クラスタ構築後の初回起動時に初期ミラー構築を行いません。

  クラスタ構築前に CLUSTERPRO 以外の手段でミラーディスクのデータパーティションの内容を必ず完全に同一にしておく必要があります。

初期mkfs

クラスタ構築後の初回起動時にミラーディスクのデータパーティションへの mkfs の挙動を設定します。

• 初期 mkfs を行う

  クラスタ構築直後の初回起動時にミラーディスクのデータパーティションへの mkfs を行います。
• 初期 mkfs を行わない

  クラスタ構築直後の初回起動時にミラーディスクのデータパーティションへの mkfs を行いません。

  ミラーディスクのデータパーティションに既にファイルシステムが構築されていて、二重化しようとするデータが既にあり、mkfs によるファイルシステムの構築や初期化が不要な場合に、初期mkfsをおこなわない設定をすることができます。

  ミラー用ディスクのパーティション構成は、ミラーディスクリソースの条件を満たしている必要があります。 4 シングルサーバをクラスタ化する場合にはご注意ください。

4

ミラーディスクにはクラスタパーティションが必ず必要です。シングルサーバのディスクをミラーの対象とする時にクラスタパーティションを確保できない場合には、一旦バックアップを採ってパーティションを再確保してください。

[初期ミラー構築を行わない] を選択した場合には、[初期 mkfs を行う] は選択できません。（現用系と待機系のデータパーティションをそれぞれmkfsすると、mkfs した直後でも、現用系と待機系とでmkfsしたデータパーティション内に差分が生じます。そのため、初期mkfsを行う場合には、初期ミラー構築（現用系と待機系とのデータパーティションのコピー）も必要になります。そのため、[初期ミラー構築を行う] を選択すると [初期 mkfs を行う] が選択可能になります。）

モード

ミラーリングの同期方式を切り換えます。

モード	概要	説明
同期	現用系と待機系のデータが完全に一致することを保証します。	ミラーリングされたディスクへの書き込み完了は、ローカルディスクへの書き込みとリモートディスクへの書き込みの両方の 完了を待ち合わせます。
非同期	データ更新の書込み順序は保証されますが、サーバダウン等によりミラーディスクリソースを非活性化できない形でフェイルオーバした場合、最新の更新データが失われる可能性があります。	ミラーリングされたディスクへの書き込み完了は、ローカルディスクへの書き込みのみを待ち合わせます。 リモートディスクへの書き込みは、書き込み要求がキューイングされ、バックグラウンドで実行されます。 キューイングされた書き込みデータはカーネル空間メモリに保持後、ユーザ空間メモリに転送されます。ユーザ空間メモリで保持できる限界に達した場合、一時ファイルに出力し保持します。

キューの数

モードが [非同期] の場合に、リモートディスクへの書き込み要求を保持するキューの上限個数を指定します。

非同期モードの設定については「詳細タブ」を参照してください。

速度の遅いネットワークを使う場合等にて、ミラーへの書き込み量が増えて送信（同期）が必要となるデータが増えた時やネットワークが遅くなった時に、このキューで送信待ち（同期完了待ち）データを蓄えます。その後ミラーへの書き込みが減って送信（同期）するデータが減った時やネットワークが速くなった時に、蓄えられていた送信待ちデータが送信されます。このようにして、書き込みデータの増減やネットワークの速度変化をキューで緩和して、ネットワークへ送信します。

通常、このキューの数を大きく設定して同期データの増減を緩和する場合には、同期完了までの時間の上限（Ackタイムアウト）も大きく設定します。

このキューはメモリ空間内に構築されますが、同期完了待ちのデータ数がこのキューの上限個数を超えた場合には、超過分をファイルとして記録し、ため込みます。

このキューの上限個数を大きく設定したり無制限に設定することで、I/Oパフォーマンスが改善される可能性がありますが、使用されるメモリ量も多くなります。必要となるメモリ量については、「スタートアップガイド」の「CLUSTERPROの動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「必要メモリ容量とディスクサイズ」を参照してください。

また、このキューの上限個数を大きく設定しすぎたり無制限に設定した場合、大量のデータ書き込みが発生した状態で、同期のタイムアウト（Ackタイムアウト）やミラー通信の断線が発生すると、キューに対する処理が一度に大量に生じて極端に高負荷となることがあります。

注釈

ミラーディスクリソースやハイブリッドディスクリソースが非同期モードの場合で、遠隔構成などネットワーク通信が遅くてディスクI/O量が多いような環境の場合には、I/O量が多い状態が続くとキュー上限数超えやAckタイムアウトによるミラーブレイクが発生し続けて、いつまで経っても正常に同期された状態にならなかったり、システムがメモリ不足や高負荷で不安定になる場合があります。

このような環境の場合には、I/O量が多くなる前に事前にミラー同期を中断したり、定期的にミラー同期をおこなう構成にするなどの方法を、ご検討ください。

通信帯域制限

モードが [非同期] の場合、一旦キューイングした書き込みデータを、可能な限り高速に待機系に転送しようとします。このため、ミラーディスクコネクトに使用する通信路を他のアプリケーション通信にも使用する場合には、通信帯域が圧迫されて他の通信が阻害される可能性があります。

このような場合、ミラーの通信に使用する通信帯域を制限することにより、他の通信への影響を軽減することができます。

ただし、ミラーディスクへの平均書き込み量よりも、ミラーディスクコネクトに実際に使用可能な通信帯域が下回る場合、キューに蓄積されるデータを待機系へ転送しきれなくなり、キュー数の上限に達してミラーリングが中断（ミラーブレイク）することになりますので、業務アプリケーションの書き込みデータ量に対して十分な通信帯域を確保する必要があります。

注釈

本機能は 1 秒間のデータ送信量の総和が設定値を超えた場合に最大 1 秒の待ち時間を設けることで通信帯域を制限しているため、 1 回のディスク書き込みデータサイズが設定値を超える場合には期待する効果が見込めないことがあります。

例えば、ミラーディスクのコピー実行時の 1 回の送信データサイズが 64KB の場合、本設定値を64KB/秒以下に設定しても、コピー実行時の通信量が設定値を上回る可能性があります。

履歴ファイル格納ディレクトリ

モードが [非同期] の場合、メモリ内に構築されたキューの数の上限を超えた場合に超過分をファイルとして記録するディレクトリを指定します。

ミラーディスクへのI/O量によっては、履歴ファイル格納ディレクトリへのI/O負荷も高くなることがあるため、履歴ファイル格納用のディスクを用意し、そこに履歴ファイル格納ディレクトリを設定することを推奨します。

履歴ファイルサイズ制限

モードが [非同期] の場合、履歴ファイルの蓄積量の上限を指定します。履歴ファイルが上限に達した場合、ミラーブレイク状態となります。なお、ここで設定する値は対象ミラーディスクリソースの一時ファイルサイズの上限であり、履歴ファイル格納フォルダ内の一時ファイルの総量を制限するものではありません。

なお、ミラーディスクリソースの一時ファイルの総量が上限値に達しない場合でも、未送信データ件数が「非同期モードでの履歴記録領域サイズ」の上限に達するとミラーリングを中断します。詳細は、「クラスタプロパティ」の「ミラードライバタブ －Replicator / Replicator DR を使用している場合－」の「非同期モードでの履歴記録領域サイズ」を参照してください。

データの圧縮

ミラー同期データ（モードが [非同期] の場合）や、ミラー復帰データを、圧縮して送信するかを指定します。速度の遅いネットワークを使う場合に、送信データを圧縮することで、送信量を減らすことができます。

注釈

• 圧縮処理により、データ送信時にCPU負荷が高くなる場合があります。

• 速度の遅いネットワークでは、圧縮により送信量が減少して、非圧縮よりも時間の短縮が見込める場合があります。逆に、速度の速いネットワークでは、転送時間の短縮よりも圧縮処理時間と負荷の増加のほうが目立ってくるため、時間の短縮が見込めない場合があります。

• 圧縮効率の良いデータが多い場合、圧縮により送信量が減少して、非圧縮よりも時間の短縮が見込める場合があります。逆に、圧縮効率の悪いデータが多い場合、送信量が減少せず、圧縮処理時間と負荷の増加により、時間の短縮が見込めない場合があります。

ミラーエージェント送信タイムアウト

ミラーエージェントが相手サーバへ処理を要求してから処理結果を待つまでのタイムアウトです。

図 3.95 ミラーエージェント送信タイムアウト

ミラーエージェント受信タイムアウト

ミラーエージェントが相手サーバとの通信 socket を作成してから受信開始を待つまでのタイムアウトです。

図 3.96 ミラーエージェント受信タイムアウト

復帰データサイズ (64～32768)

ミラー復帰で 1 回の処理で 2 台のサーバ間でやりとりするデータの大きさを指定します。 通常はデフォルトのままで使用してください。

• 値を大きくする

  • サーバ間でデータをやり取りする回数が少なくなるので、ミラー復帰の全体の処理に必要な時間が短くなります。

  • ミラー復帰中に、ディスク性能が低下する可能性があります。

    （ミラー復帰データのディスク読み込み範囲と、ファイルシステムからのディスク書き込み範囲とが重なった場合、排他アクセスをして、先にアクセスしたほうが完了するまで、もう一方はアクセスが待たされます。

    ネットワークが遅い環境では、この復帰データサイズの値が大きいと、ミラー復帰の1回のデータ転送にかかる時間も長くなります。もし、ミラーへの通常のディスクアクセスが、このミラー復帰の転送中の範囲と重なった場合、ディスクアクセスはその転送が完了するまで待たされます。その結果、ディスク性能が低下することがあります。

    そのため、特にネットワークが遅い環境では、この値は小さくしてください。）

• 値を小さくする

  • ミラー復帰中の 2 台のサーバ間の送受信データが細分化されるため、ネットワーク速度が遅い場合やサーバ高負荷の場合でのタイムアウトの発生確率が低くなります。

  • サーバ間でやりとりする回数が増えるため、特に遅延の発生するネットワークでは、ミラー復帰の処理に必要な時間が長くなります。

ミラー通信を暗号化する

ミラーディスクコネクトを流れる通信データの暗号化有無を指定します。

暗号化アルゴリズムとしてAdvanced Encryption Standard (GCM) を使用し、最大256bitの暗号化鍵長をサポートします。

ミラーディスクコネクトの経路が外部の回線を経由する場合は、暗号化を使用することを推奨します。

3.10.4. ミラーディスクの構築例

過去にミラーディスクとして使用していたディスクを流用する場合は、クラスタパーティションに以前のデータが残っているので初期化が必要です。クラスタパーティションの初期化については『インストール&設定ガイド』を参照してください。

• 初期ミラー構築を行う

  初期 mkfs を行う

  まず、CLUSTERPROをインストールし、セットアップを行います。 次に、Server 1、Server 2のそれぞれに接続されたディスクに対して、初期mkfsを実行します。

  

  図 3.97 ミラーディスク構築例（初期ミラー構築、初期mkfsともに行う）(1)

  続いて初期ミラー構築を開始します。 Server 1の Mirror disk 1から Server 2の Mirror disk 2へ、全面コピーを行います。

  

  図 3.98 ミラーディスク構築例（初期ミラー構築、初期mkfsともに行う）(2)

• 初期ミラー構築を行う

  初期 mkfs を行わない

  まず、二重化する Application のデータをクラスタ構築前に用意できる場合には、先に現用系のミラーディスク（Mirror disk 1）のデータパーティションに作成しておきます（ex. データベースの初期DBなど）。 パーティション構成は "3.10.2. ミラーディスクとは?" を参照してください。 次に、Server 1、Server 2のそれぞれに CLUSTERPROをインストールし、セットアップを行います。

  

  図 3.99 ミラーディスク構築例（初期ミラー構築のみ行う）(1)

  続いて初期ミラー構築を開始します。 Server 1の Mirror disk 1から Server 2の Mirror disk 2へ、全面コピーを行います。

  

  図 3.100 ミラーディスク構築例（初期ミラー構築のみ行う）(2)

• 初期ミラー構築を行わない

  初期 mkfs を行わない

  たとえば以下のような方法で両サーバのミラーディスクの内容を同一にすることができます。(クラスタ構築後にはできません。必ずクラスタ構築前に実施してください。)

  • 例1: ディスクのパーティションイメージをコピーする方法

    まず、二重化する Application のデータをクラスタ構築前に用意できる場合には、先に現用系のミラーディスク（Mirror disk 1）のデータパーティションに作成しておきます（ex. データベースの初期DBなど）。 パーティション構成は "3.10.2. ミラーディスクとは?" を参照してください。

    

    図 3.101 ミラーディスク構築例（パーティションイメージコピー）(1)

    待機系サーバ（Server 2）のミラー用ディスク（Mirror disk 2）を取り外して、現用系サーバ（Server 1）へ接続します。

    

    図 3.102 ミラーディスク構築例（パーティションイメージコピー）(2)

    Mirror disk 1（現用系用ミラーディスク）がアンマウントされている状態で、ddコマンドなどを使って Mirror disk 1のデータパーティションを丸ごと Mirror disk 2のデータパーティションへコピーします。

    ファイルシステム経由のコピーではパーティションイメージが同一になりませんので注意してください。
    

    図 3.103 ミラーディスク構築例（パーティションイメージコピー）(3)

    現用系サーバ（Server 1）に接続していた待機系用ミラーディスク（Mirror disk 2）を待機系サーバ（Server 2）へ戻します。

    さらに CLUSTERPROをインストールし、セットアップを行います。

    以降は、「初期mkfsを行わない・初期ミラー構築を行わない」場合の設定でクラスタを構築します。

    ミラーパーティションの初期構築（初期同期）は実行しません。
    

    図 3.104 ミラーディスク構築例（パーティションイメージコピー）(4)

  • 例2: バックアップ装置でコピーをする方法

    まず、二重化する Application のデータをクラスタ構築前に用意できる場合には、先に現用系のミラーディスク（Mirror disk 1）のデータパーティションに作成しておきます（ex. データベースの初期DBなど）。

    パーティション構成は "3.10.2. ミラーディスクとは?" を参照してください。
    

    図 3.105 ミラーディスク構築例（バックアップ装置使用）(1)

    現用系サーバ（Server 1）にバックアップ装置（Backup device）を接続します。

    ddコマンドなど、パーティションイメージでバックアップするコマンドを使って、ミラーディスク（Mirror disk 1）のデータパーティションのデータをバックアップします。
    

    図 3.106 ミラーディスク構築例（バックアップ装置使用）(2)

    待機系サーバ（Server 2）にバックアップ装置（Backup device）を接続し、現用系サーバ（Server 1）でデータをバックアップした際のメディアをServer 2のバックアップ装置へ移動します。

    

    図 3.107 ミラーディスク構築例（バックアップ装置使用）(3)

    CLUSTERPROをインストールし、セットアップを行います。

    以降は、「初期mkfsを行わない・初期ミラー構築を行わない」場合の設定でクラスタを構築します。ミラーパーティションの初期構築（初期同期）は実行しません。
    

    図 3.108 ミラーディスク構築例（バックアップ装置使用）(4)

3.10.5. ミラーディスクリソースに関する注意事項

• 両サーバで、同一デバイス名でアクセスできない場合はサーバ個別設定を行ってください。

• クラスタプロパティの [拡張] タブで、[マウント、アンマウントコマンドを排他する] にチェックを入れている場合、ディスクリソース、ミラーリソースの mount/umount は同一サーバ内で排他的に動作するため、ミラーリソースの活性/非活性に時間がかかることがあります。

• マウントポイントにシンボリックリンクを含むパスを指定すると、異常検出時の動作に [強制終了] を選択しても強制終了できません。

  また、同様に「//」を含むパスを指定した場合にも、強制終了できません。

• Linux の md によるストライプセット、ボリュームセット、ミラーリング、パリティ付きストライプセットを使用したディスクを、クラスタパーティションやデータパーティションに指定することはできません。

• Linux の LVM によるボリュームを、クラスタパーティションやデータパーティションに指定することは可能です。

  なお、SuSE Linux については、LVM や MultiPath によるボリュームを、クラスタパーティションやデータパーティションに使用することはできません。

• ミラーディスクリソース (ミラーパーティションデバイス) を Linux の md や LVM によるストライプセット、ボリュームセット、ミラーリング、パリティ付きストライプセットの対象とすることはできません。

• ミラーディスク用のディスクとして使用するディスクのジオメトリがサーバ間で異なる場合の注意

  [fdisk] コマンドなどで確保したパーティションサイズはシリンダあたりのブロック (ユニット) 数でアラインされます。

  データパーティションのサイズと初期ミラー構築の方向の関係が以下になるようにデータパーティションを確保してください。

  コピー元のサーバ ≦ コピー先のサーバ

  コピー元のサーバとは、ミラーディスクリソースが所属するフェイルオーバグループのフェイルオーバポリシーが高いサーバを指します。

  コピー先のサーバとは、ミラーディスクリソースが所属するフェイルオーバグループのフェイルオーバポリシーが低いサーバを指します。

  
  

  なお、データパーティションは同程度のサイズで確保するようにしてください。

  データパーティションのサイズが、コピー元側とコピー先側とで32GiB, 64GiB, 96GiB, … (32GiBの倍数) を跨がないように注意してください。32GiBの倍数を跨ぐサイズの場合、初期ミラー構築に失敗することがあります。

例)

組み合わせ	データパーティションのサイズ		説明
	Server 1側	Server 2側
OK	30GiB	31GiB	両方とも0～32GiB未満の範囲内にあるのでOK
OK	50GiB	60GiB	両方とも32GiB以上～64GiB未満の範囲内にあるのでOK
NG	30GiB	39GiB	32GiBを跨いでいるのでNG
NG	60GiB	70GiB	64GiBを跨いでいるのでNG

• ミラーディスクリソースで使用するファイルに対してopen() システムコールのO_DIRECTフラグを使用しないでください。

  例えば Oracle の設定パラメータの filesystemio_options = setall などがこれに該当します。

• DISK 監視の READ (O_DIRECT) 方式の監視先として ミラーパーティションデバイス(/dev/NMP1など) を指定しないでください。

• ミラーディスクリソースのデータパーティションおよびクラスタパーティションには、全サーバで同一の論理セクタサイズのディスク装置を使用してください。異なる論理セクタサイズの装置を使用すると、正常に動作しません。データパーティションとクラスタパーティションでは論理セクタサイズが異なっていても動作可能です。

例)

組み合わせ	パーティションの論理セクタサイズ				説明
	Server 1側	Server 1側	Server 2側	Server 2側
	データパー ティション	クラスタパー ティション	データパー ティション	クラスタパー ティション
OK	512B	512B	512B	512B	論理セクタサイズが統一されている
OK	4KB	512B	4KB	512B	データパーティションで4KB、クラスタパーティションで512Bに統一されている
NG	4KB	512B	512B	512B	データパーティションの論理セクタサイズが統一されていない
NG	4KB	4KB	4KB	512B	クラスタパーティションの論理セクタサイズが統一されていない

• ミラーディスクリソースのデータパーティションおよびクラスタパーティションとして使用するディスクについて、HDDとSSDを混在させないでください。混在させると最適な性能が得られません。データパーティションとクラスタパーティションではディスクタイプが異なっていても動作可能です。

  例)

  組み合わせ	パーティションのディスクタイプ				説明
  	Server 1側	Server 1側	Server 2側	Server 2側
  	データパー ティション	クラスタパー ティション	データパー ティション	クラスタパー ティション
  OK	HDD	HDD	HDD	HDD	ディスクタイプが統一されている
  OK	SSD	HDD	SSD	HDD	データパーティションでSSD、クラスタパーティションでHDDに統一されている
  NG	SSD	HDD	HDD	HDD	データパーティションでHDD/SSDが混在している
  NG	SSD	SSD	SSD	HDD	クラスタパーティションでHDD/SSDが混在している

3.10.6. mount前後の処理の流れ

ミラーディスクリソース活性時のmountの処理は以下のように行われます。

ファイルシステムにnoneが指定されている場合、mount処理は行いません。

1. 事前にマウントされているか？

   既にマウントされていた場合 → ×へ

2. マウント前に fsck を実行する設定か？

   fsck を実行するタイミングである → デバイスに fsck を実行する

3. デバイスをマウントする

   マウント成功 → ○へ

4. マウントのリトライを行う設定か？

   リトライしない設定の場合 → ×へ

5. マウント失敗時に fsck （xfs_repair）を実行する設定の場合

   2.でfsckを実行して成功していた場合 → 6.へ

   3.でタイムアウトにより失敗していた場合 → 6.へ

   上記以外の場合 → デバイスにfsck（xfs_repair）を実行する

6. 再度デバイスのマウントを試みる

   マウント成功 → ○へ

7. マウントのリトライ回数以内か？

   リトライ回数以内の場合 → 6.へ

   リトライ回数を超えた場合 → ×へ

○ リソース起動（マウント成功）

× リソース起動失敗（マウントされていない）

3.10.7. umount前後の処理の流れ

ミラーディスクリソース非活性時のumountの処理は以下のように行われます。

ファイルシステムにnoneが指定されている場合、umount処理は行いません。

1. 事前にアンマウントされているか？

   既にアンマウントされていた場合 → ×へ

2. デバイスをアンマウントする

   アンマウント成功 → ○へ

3. アンマウントのリトライを行う設定か？

   リトライしない設定の場合 → ×へ

4. まだマウントされているか？（マウント一覧からマウントポイントが削除されていて、ミラーデバイスも未使用状態になっているか？）

   もうマウントされていない → ○へ

5. マウントポイントを使用しているプロセスのKILLを試みる

6. 再度デバイスのアンマウントを試みる

   アンマウント成功 → ○へ

7. アンマウントタイムアウトではなく、かつ、マウント一覧からマウントポイントが削除されているか？

   マウントポイントは既に削除された → ミラーデバイスが使用されなくなるまで待つ（最大でアンマウントタイムアウトの時間まで待つ）

8. アンマウントのリトライ回数以内か？

   リトライ回数以内の場合 → 4.へ

   リトライ回数を超えた場合 → ×へ

○ リソース停止（アンマウント成功）

× リソース停止失敗（マウントされたまま、もしくは既にアンマウントされていた）

3.10.8. ミラーのステータスが異常となる条件

ミラーディスクリソースのステータスが正常（GREEN）状態から異常（RED）状態になるケースとして、おもに以下のようなものがあります。

• 通信（ミラーディスクコネクト）の断線や待機系側サーバの停止などにより、現用系側と待機系側とでミラー同期できなくなり、差分が生じた場合。

  待機系側は最新データを保持していないので、異常（RED）状態になります。
• ミラーデータを同期しないよう設定して、現用系側と待機系側とで差分が生じた場合。

  待機系側は最新データを保持していないので、異常（RED）状態になります。
• ミラーディスクの切り離し（ミラーリングの中断）操作をおこなった場合。

  待機系側は異常（RED）状態になります。
• ミラー復帰中（ミラーの再同期中）にミラー復帰を中断した場合。

  待機系側はまだコピーが完了していないので、異常（RED）状態になります。
• 現用系側サーバが、サーバダウンなどで、正常にクラスタシャットダウンしなかった場合。

  （活性していたミラーディスクリソースが非活性へ移行せずに停止した場合。）

  そのサーバのミラーディスクはサーバ起動後に、異常（RED）状態になります。
• 片方のサーバだけを起動してミラーディスクを活性した後、ミラー同期をしないままそのサーバを停止して、もう片方のサーバを起動してミラーディスクを活性した場合。

  両方のサーバのミラーディスクにそれぞれ個別に更新がおこなわれているため、

  両サーバのミラーディスクとも異常（RED）状態になります。

  このように両サーバのミラーディスクにそれぞれ個別に更新がおこなわれた場合、どちらのサーバのミラーディスクをコピー元とすべきか自動では判断できないため、自動ミラー復帰はおこなわれません。強制ミラー復帰を実行する必要があります。
• 通信（ミラーディスクコネクト）の断線や待機系側サーバのリブートなどにより、現用系側と待機系側とでミラー同期できなくなって差分が生じ、その後さらに、現用系側サーバがサーバダウンなどにより正常にクラスタシャットダウンしなかった場合。

  この場合、その後に待機系側へ正常にフェイルオーバしても、両サーバ起動後には、両サーバとも異常（RED）状態になります。

  この場合にも、自動ミラー復帰はおこなわれません。強制ミラー復帰を実行する必要があります。

ミラーのステータスの参照方法については、下記を参照してください。

• オンラインマニュアル

• 9. CLUSTERPRO コマンドリファレンス

  • ミラー状態を表示する (clpmdstat コマンド)

    • 表示例

      • ミラーディスクリソース状態表示

また、ミラー復帰、強制ミラー復帰の手順については、下記を参照してください。

• 10. トラブルシューティング

  • 障害発生時の手順

    • ミラーブレイク状態からの復旧を行う

    • 自動でミラーを復帰するには

    • コマンドでミラーブレイク状態を確認するには

    • コマンドでミラー復帰を行うには

    • コマンドによる強制ミラー復帰を行うには

    • コマンドによるサーバ 1 台のみの強制ミラー復帰を行うには

    • Cluster WebUI でミラーブレイク状態を確認するには

    • Cluster WebUI でミラー復帰を行うには

    • Cluster WebUI で強制ミラー復帰を行うには

    • Cluster WebUI でサーバ 1 台のみの強制ミラー復帰を行うには

3.10.9. 詳細タブ

ミラーパーティションデバイス名

ミラーパーティションに関連付けるミラーパーティションデバイス名を選択します。

ミラーディスクリソース、ハイブリッドディスクリソースで既に設定済のデバイス名は、リスト表示されません。

マウントポイント (1023 バイト以内) サーバ個別設定可能

ミラーパーティションデバイスをマウントするディレクトリを設定します。[/] で始まる必要があります。

データパーティションデバイス名 (1023 バイト以内) サーバ個別設定可能

ディスクリソースとして使用するデータパーティションデバイス名を設定します。[/] で始まる必要があります。

クラスタパーティションデバイス名 (1023バイト以内) サーバ個別設定可能

データパーティションとペアになるクラスタパーティションデバイス名を設定します。[/] で始まる必要があります。

ファイルシステム

ミラーパーティション上で使用するファイルシステムのタイプを指定します。

以下の中から選択します。直接入力することもできます。

• ext3

• ext4

• xfs

• none (ファイルシステムなし)

ミラーディスクコネクト

ミラーディスクコネクトの追加、削除、変更を行います。[ミラーディスクコネクト一覧] には、ミラーディスクリソースで使うミラーディスクコネクトの I/F 番号が表示されます。

[利用可能なミラーディスクコネクト] には、未使用のミラーディスクコネクト I/F 番号が表示されます。

• ミラーディスクコネクトはクラスタプロパティで設定します。

• 使用できるミラーディスクコネクトは、1 つのミラーディスクリソースにつき最大 2 つです。2 つ用意したときの挙動は「ミラーディスクとは?」を参照してください。

• ミラーディスクコネクトの設定に関しては、『インストール&設定ガイド』を参照してください。

追加

ミラーディスクコネクトを追加する場合に使用します。[利用可能なミラーディスクコネクト] から追加したい I/F 番号を選択して、[追加] をクリックしてください。[ミラーディスクコネクト一覧] に追加されます。

削除

使用するミラーディスクコネクトを削除する場合に使用します。[ミラーディスクコネクト一覧]から削除したい I/F 番号を選択して、[削除] をクリックしてください。[利用可能なミラーディスクコネクト] に追加されます。

順位

使用するミラーディスクコネクトの優先順位を変更する場合に使用します。[ミラーディスクコネクト一覧] から変更したい I/F 番号を選択して、矢印をクリックしてください。選択行が移動します。

調整

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

ミラーディスクリソース調整プロパティ

マウントタブ

マウントに関する詳細設定が表示されます。

[ミラーディスクリソース詳細]タブでファイルシステムにnoneを指定している場合は表示されません。

マウントオプション (1023 バイト以内)

ミラーパーティションデバイス上のファイルシステムをマウントする場合に mount コマンドへ渡すオプションを設定します。複数のオプションは「, (カンマ)」で区切ります。

マウントオプションの例

設定項目	設定値
ミラーパーティションデバイス名	/dev/NMP5
ミラーマウントポイント	/mnt/sdb5
ファイルシステム	ext3
マウントオプション	rw,data=journal

上記設定時に実行される mount コマンド

mount -t ext3 -o rw,data=journal /dev/NMP5 /mnt/sdb5

タイムアウト (1～999)

ミラーパーティションデバイス上のファイルシステムをマウントする場合の mount コマンドの終了を待つタイムアウトを設定します。ファイルシステムの容量が大きいと時間がかかる場合があります。設定する値に注意してください。

リトライ回数 (0～999)

ミラーパーティションデバイス上のファイルシステムのマウントに失敗した場合のマウントリトライ回数を設定します。0 を設定するとリトライを実行しません。

既定値

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

アンマウントタブ

アンマウントに関する詳細設定が表示されます。

[ミラーディスクリソース詳細]タブでファイルシステムにnoneを指定している場合は表示されません。

タイムアウト (1～999)

ミラーパーティションデバイス上のファイルシステムをアンマウントする場合の umount コマンドの終了を待つタイムアウトを設定します。

リトライ回数 (0～999)

ミラーパーティションデバイス上のファイルシステムの、アンマウントに失敗した場合のアンマウントリトライ回数を指定します。0 を設定するとリトライを実行しません。

リトライインターバル (0～999)

ミラーパーティションデバイス上のファイルシステムのアンマウントに失敗した場合に、次のリトライを実行するまでの間隔を指定します。

異常検出時の強制動作

アンマウントに失敗後、アンマウントリトライする場合に実行する動作を、下記より選択します。

• [強制終了]

  マウントポイントにアクセスしているプロセスの強制終了を試みます。必ずしもプロセスが強制終了できるとは限りません。
• [何もしない]

  マウントポイントにアクセスしているプロセスの強制終了を試みません。

既定値

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

fsckタブ

[fsck] に関する詳細設定が表示されます。

[ミラーディスクリソース詳細]タブでファイルシステムにxfsまたはnoneを指定している場合は表示されません。

fsckオプション (1023 バイト以内)

ミラーパーティションデバイス上のファイルシステムをチェックする場合に、fsck コマンドに渡すオプションを指定します。複数のオプションはスペースで区切って設定してください。ここで、fsck コマンドが対話形式にならないようにオプションを指定してください。fsck コマンドが対話形式になると、[fsckタイムアウト] が経過後リソースの活性がエラーになります。

fsckタイムアウト (1～9999)

ミラーパーティションデバイス上のファイルシステムをチェックする場合に、fsck コマンドの終了を待つタイムアウトを指定します。ファイルシステムの容量が大きいと時間がかかる場合があります。設定する値に注意してください。

Mount実行前のfsckアクション

ミラーパーティションデバイス上のファイルシステムをマウントする前の [fsck] の動作を下記より選択します。

• [必ず実行する]

  マウント前に fsck を実行します。
• [指定回数に達したら実行する]

  リソースが [回数] で指定する回数正常に活性した時に fsck を実行します。

  = 回数 (0～999)
• [実行しない]

  マウント前に fsck を実行しません。

注釈

fsck の指定回数はファイルシステムが管理しているチェックインターバルとは無関係です。

Mount失敗時のfsckアクション

ミラーパーティションデバイス上のファイルシステムのマウントに失敗した場合の [fsck] の動作を設定します。この設定は [マウントリトライ回数] の設定値が 0 以外の場合に有効になります。

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

  fsck を実行後、マウントのリトライを実行します。
• チェックボックスがオフ

  fsck を実行しないで、マウントのリトライを実行します。

注釈

[Mount実行前のfsckアクション] が [実行しない] の場合との組み合わせは推奨しません。この設定では、ミラーリソースは fsck を実行しないため、ミラーパーティションに fsck で修復可能な異常があった場合、ミラーリソースをフェイルオーバできません

reiserfsの再構築

reiserfsck が修復可能なエラーで失敗した場合の挙動を指定します。

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

  reiserfsck --fix-fixable を実行します。
• チェックボックスがオフ

  reiserfsck が修復可能なエラーで失敗しても修復動作をしません。

既定値

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

xfs_repairタブ

[xfs_repair] に関する詳細設定が表示されます。ファイルシステムに[xfs] を設定した場合のみ表示されます。

xfs_repairオプション (1023バイト以内)

ディスクデバイス上のファイルシステムをチェックする場合に [xfs_repair] コマンドに渡すオプションを指定します。複数のオプションはスペースで区切って設定してください。

xfs_repairタイムアウト (1～9999)

ディスクデバイス上のファイルシステムをチェックする場合に [xfs_repair] コマンドの終了を待つタイムアウトを指定します。ファイルシステムの容量が大きいと時間がかかる場合があります。設定する値が小さすぎないように注意してください。

Mount失敗時のxfs_repairアクション

ディスクデバイス上のファイルシステムのマウントに失敗した場合の [xfs_repair] の動作を設定します。この設定は [マウントリトライ回数] の設定値が 0 以外の場合に有効になります。

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

  [xfs_repair] を実行後、マウントのリトライを実行します。
• チェックボックスがオフ

  [xfs_repair] を実行しないで、マウントのリトライを実行します。

既定値

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

ミラータブ

ミラーディスクに関する詳細設定が表示されます。

初期ミラー構築を行う

クラスタ構築時の初期ミラー構築を行うかどうかを指定します。

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

  初期ミラー構築を行います。

ext3/ext4 とその他のファイルシステムでは、初期ミラー構築にかかる時間が異なります。

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

  初期ミラー構築を行いません。

初期mkfsを行う

クラスタ構築時の初期 mkfs を行うかどうかを指定します。初期ミラー構築を行う場合のみ指定可能です。

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

  初期 mkfs を行います。
• チェックボックスがオフ

  初期 mkfs を行いません。

データを同期する

ミラーディスクリソースが活性化した時にミラーデータの同期を行うかどうかを指定します。

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

  ミラーデータを同期します。write データは現用系から待機系へ渡されます。clpmdctrl コマンド、clphdctrl コマンドでミラーデータを同期しない状態に切り換えることができます。
• チェックボックスがオフ

  ミラーデータを同期しません。write データは現用系から待機系へ渡されず差分として蓄積されます。clpmdctrl コマンド、clphdctrl コマンドでミラーデータを同期する状態に 切り換えることができます。

モード

ミラーデータの同期モードを指定します。

• [同期]

  ミラーコネクトの帯域が主に LAN の場合に選択します。
• [非同期]

  ミラーコネクトの帯域が主に WAN の場合に選択します。非同期のモードの場合、キューの個数を設定します。ミラーディスクリソース単位で設定します。
  • 無制限

    メモリが確保できなくなるまでキューを確保します。メモリが確保できなくなるとミラーブレイクが発生します。（メモリが確保できなくなると、システムが不安定となる可能性があるため、おすすめできません。）
  • 数を指定 (1～999999)

    キューを確保する最大数を指定します。同期データがキューの最大数を超える場合には、超過分が履歴ファイルとして記録されます。

  [非同期] を選択したとき、[通信帯域制限] のチェックボックスにチェックを入れることが可能です。

  • チェックボックスがオン (1～999999)

    通信帯域制限の上限を設定します。
  • チェックボックスがオフ

    通信帯域制限の上限を設定しません。

  [非同期] を選択したとき、[履歴ファイル格納ディレクトリ] のテキストボックスの編集が可能です。キューを超過した際の、ファイルを格納するディレクトリを設定します。指定が無い場合は、(CLUSTERPROインストールディレクトリ)/workの下にファイルが生成されます。

  [非同期] を選択したとき、[履歴ファイルサイズ制限] のテキストボックスの編集が可能です。履歴ファイルの総計がこのサイズに達すると、ミラーブレイク状態となります。0または無指定の場合は、サイズ無制限となります。

  また、[非同期] を選択したとき、[データを圧縮する] のチェックボックスにチェックを入れることが可能です。

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

    ミラー同期の通信データを圧縮します。
  • チェックボックスがオフ

    ミラー同期の通信データを圧縮しません。

復帰時データを圧縮する

ミラー復帰の通信データを圧縮するか設定します。

ミラー通信を暗号化する

ミラーディスクコネクトを流れる通信データを暗号化するかどうかを設定します。ミラー同期の通信データおよびミラー復帰の通信データ、両方に作用します。

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

  ミラーディスクコネクトを流れるデータが暗号化されます。
• チェックボックスがオフ

  ミラーディスクコネクトを流れるデータは暗号化されません。

鍵ファイルフルパス (1023 バイト以内)

ミラーディスクコネクトを流れる通信データを暗号化する鍵ファイルをフルパスで指定します。暗号化を使用する場合は、指定が必須です。

注釈

鍵ファイルはOSのopensslコマンドを使用して生成したものを使用します。

以下は、RHEL7系での実行例です。ディストリビューションごとにopensslコマンドのオプション体系も異なるので、確認の上、実行してください。

# openssl rand 16 -out (鍵ファイル名)     鍵長128ビット(16バイト)の暗号化鍵を生成
# openssl rand 24 -out (鍵ファイル名)     鍵長192ビット(24バイト)の暗号化鍵を生成
# openssl rand 32 -out (鍵ファイル名)     鍵長256ビット(32バイト)の暗号化鍵を生成

鍵長は128ビット, 192ビット, 256ビットのいずれかが使用可能です。

重要

必ず、ミラーディスクリソースが活性可能な全サーバで同じ鍵ファイルを使用してください。鍵ファイルが異なると、正常にミラーリングできません。

既定値

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

ミラードライバタブ

ミラードライバに関する詳細設定が表示されます。

ミラーデータポート番号 (1～655355 )

ミラードライバがサーバ間でディスクデータの送受信に使用する TCP ポート番号を設定します。最初に作成したミラーディスクリソースまたはハイブリッドディスクリソースにデフォルトの[29051] が設定されます。2 つめ以降のミラーディスクリソースまたはハイブリッドディスクリソースにはデフォルトに 1 ずつ加算された値 [29052,29053,…] が設定されます。

5

Well-Known ポート、特に 1～1023 番の予約ポートの使用は推奨しません。

ハートビートポート番号 (1～655356 )

ミラードライバがサーバ間で制御用データの通信を行う TCP ポート番号を設定します。最初に作成したミラーディスクリソースまたはハイブリッドディスクリソースにデフォルトの [29031]が設定されます。2 つめ以降のミラーディスクリソースまたはハイブリッドディスクリソースにはデフォルトに 1 ずつ加算された値 [29032,29033,…] が設定されます。

6

Well-Known ポート、特に 1～1023 番の予約ポートの使用は推奨しません。

ACK2 ポート番号 (1～655357 )

ミラードライバがサーバ間で制御用データの通信を行う TCP ポート番号を設定します。最初に作成したミラーディスクリソースまたはハイブリッドディスクリソースにデフォルトの [29071]が設定されます。2 つめ以降のミラーディスクリソースまたはハイブリッドディスクリソースにはデフォルトに 1 ずつ加算された値 [29072,29073,…] が設定されます。

7

Well-Known ポート、特に 1～1023 番の予約ポートの使用は推奨しません。

送信タイムアウト (10～99)

書き込みデータの送信タイムアウトを設定します。

接続タイムアウト (5～99)

接続のタイムアウトを設定します。

Ackタイムアウト (1～600)

ミラー復帰、データ同期時にAck応答を待つタイムアウトを設定します。

受信タイムアウト (1～600)

書き込み確認の受信待ちタイムアウトを設定します。

ハートビートインターバル (1～600)

ミラードライバによるミラーディスクコネクト間ハートビートのインターバルを設定します。

ICMP Echo Reply 受信タイムアウト (1～100)

ミラードライバによるミラーディスクコネクト間ハートビートのタイムアウトを設定します。ここで設定された時間の間無応答がICMP Echo Request リトライ回数分続くとミラーディスクコネクトの断線とみなします。

ICMP Echo Request リトライ回数 (1～50)

ミラードライバによるミラーディスクコネクト間ハートビートのリトライ回数を設定します。ICMP Echo Reply 受信タイムアウトとともにミラーコネクト断線の判定感度に関わってきます。

既定値

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

• 送信タイムアウト

• 接続タイムアウト

• Ack タイムアウト

• 受信タイムアウト

• ハートビートインターバル

• ICMP Echo Reply 受信タイムアウト

• ICMP Echo Request リトライ回数

注釈

[ミラーデータポート番号] [ハートビートポート番号] [ACK2ポート番号] はリソースごとに異なるポート番号を設定する必要があります。また、クラスタで使用するその他のポート番号と重複しないように設定する必要があります。そのため、[既定値] を押しても既定値はセットされません。

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

3.11.1. ハイブリッドディスクリソースの依存関係

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

グループリソースタイプ
フローティング IP リソース
仮想 IP リソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース

3.11.2. ハイブリッドディスクとは?

ハイブリッドディスクとは、2 つのサーバグループ間でデータのミラーリングを行うリソースのことです。サーバグループは 1 台または 2 台のサーバから構成されます。サーバグループが2 台のサーバで構成される場合には共有ディスクを使用します。サーバグループが 1 台のサーバで構成される場合には共有型でないディスク (サーバ内蔵、サーバ間で共有していない外付型ディスク筐体など) を使用します。

図 3.109 ハイブリッド構成 (1)（通常時）

Server 1がダウンすると、Application は Server 2にフェイルオーバします。

図 3.110 ハイブリッド構成 (2)（Server 1ダウン）

Server 2がダウンすると、Application は Server 3にフェイルオーバします。

図 3.111 ハイブリッド構成 (3)（Server 2ダウン）

データパーティション

ミラーリングするデータ (業務データなど) を格納するパーティションのことを、データパーティションといいます。

データパーティションは以下のように割り当ててください。

• データパーティションのサイズ

  1GB 以上、1TB 未満のパーティションを確保してください。

  ※データの構築時間、復旧時間の観点より、1TB 未満のサイズを推奨します。
• パーティション ID

  83 (Linux)
• ファイルシステムは、本バージョンのハイブリッドディスクリソースでは自動では構築されませんので、必要に応じてあらかじめ手動で構築してください。
• ファイルシステムのアクセス制御 (mount/umount) は、CLUSTERPRO が行いますので、OS 側でデータパーティションを mount/umount する設定を行わないでください。

クラスタパーティション

CLUSTERPRO がハイブリッドディスクの制御のために使用する専用パーティションを、クラスタパーティションといいます。

クラスタパーティションは以下のように割り当ててください。

• クラスタパーティションのサイズ

  最低 1024MiB 確保してください。ジオメトリによって 1024MB 以上になる場合がありますが、1024MB 以上でも問題ありません。
• パーティション ID

  83 (Linux)
• クラスタパーティションは、データミラーリング用のデータパーティションとペアで割り当てる必要があります。
• クラスタパーティションにファイルシステムを構築しないでください。

ミラーパーティションデバイス (/dev/NMPx)

1 つのハイブリッドディスクリソースで 1 つのミラーパーティションデバイスをファイルシステムに提供します。ハイブリッドディスクリソースとして登録すると、1 台のサーバ (通常はリソースグループのプライマリサーバ) からのみアクセス可能になります。

通常、ユーザ (AP) はファイルシステムを経由して I/O を行うため、ミラーパーティションデバイス (dev/NMPx) を意識する必要はありません。Cluster WebUI で情報を作成するときに重複しないようにデバイス名を割り当てます。

• ファイルシステムのアクセス制御 (mount/umount) は、CLUSTERPRO が行いますので、OS 側でミラーパーティションデバイスを mount/umount する設定を行わないでください。

  業務アプリケーションなどからの、ミラーパーティション (ハイブリッドディスクリソース) へのアクセス可否の考え方は、共有ディスクを使用した切替パーティション (ディスクリソース) と同じです。

• ミラーパーティションの切り替えは、フェイルオーバグループごとにフェイルオーバポリシーにしたがって行われます。

• ミラーパーティションのスペシャルデバイス名は /dev/NMPx (xは数字の1～8) を使用します。他のデバイスドライバでは、/dev/NMPx を使用しないでください。

• ミラーパーティションはメジャー番号の 218 を使用します。他のデバイスドライバでは、メジャー番号の 218 を使用しないでください。

• 例1) 2 台のサーバで共有ディスクを使用し 3 台目のサーバでサーバに内蔵したディスクを使用する場合

  図はハイブリッド構成の例です。Server 1とServer 2が Shared diskを共有し、Shared diskの Cluster partition、および Data partition の内容がServer 3に接続された Diskにミラーリングされています。

  この Cluster partition および Data partition がハイブリッドリソースにおけるフェイルオーバの単位であり、ミラーパーティションデバイスとなります。
  

  図 3.112 ハイブリッド構成におけるパーティション

• 共有型でないディスクを使用する場合 (サーバグループ内にサーバが 1 台の場合)には、OS (root パーティションや swap パーティション) と同じディスク上に、ハイブリッドディスクリソース用のパーティション (クラスタパーティション、データパーティション) を確保することも可能です。

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

    OS (root パーティションや swap パーティション) と別にミラー用のディスクを用意することを推奨します。
  • H/W RAID の仕様の制限で LUN の追加ができない場合

    H/W RAID のプリインストールモデルで LUN 構成変更が困難な場合

    OS (root パーティションや swap パーティション) と同じディスクに、ハイブリッドディスクリソース用のパーティション (クラスタパーティション、データパーティション) を確保することも可能です。

ミラーディスクコネクト

ミラーディスクリソースの「ミラーディスクとは?」の「ミラーディスクコネクト」を参照してください。

3.11.3. ミラーパラメータ設定の考え方

以下のパラメータについてはミラーディスクリソースと同一です。ミラーディスクリソースを参照してください。

• ミラーデータポート番号

• ハートビートポート番号

• ACK2 ポート番号

• リクエストキューの最大数

• 接続タイムアウト

• 送信タイムアウト

• 受信タイムアウト

• Ack タイムアウト

• 差分ビットマップ更新インターバル (クラスタプロパティ)

• 差分ビットマップサイズ (クラスタプロパティ)

• ミラーエージェント送信タイムアウト (クラスタプロパティ)

• ミラーエージェント受信タイムアウト (クラスタプロパティ)

• 復帰データサイズ (クラスタプロパティ)

• 初期ミラー構築

• キューの数

• 通信帯域制限

• 履歴ファイル格納ディレクトリ

• 履歴ファイルサイズ制限

• ハートビートインターバル

• ICMP Echo Reply 受信タイムアウト

• ICMP Echo Request リトライ回数

• 鍵ファイルフルパス

以下のパラメータについてはミラーディスクリソースと異なります。

• 初期 mkfs

  本バージョンのハイブリッドディスクリソースでは、自動では mkfs を行いませんので、必要な場合はあらかじめ手動で行ってください。

3.11.4. ハイブリッドディスクリソースに関する注意事項

• サーバ間でクラスタパーティション、またはデータパーティションに設定するデバイス名が異なる場合はサーバ個別設定を行ってください。ただし、同一サーバグループに所属するサーバ間でデバイス名が異なる場合、デバイス名には by-id を設定してください。

• クラスタプロパティの [拡張] タブで、[マウント、アンマウントコマンドを排他する] にチェックを入れている場合、ディスクリソース、ミラーリソース、ハイブリッドディスクリソースの mount/umount は同一サーバ内で排他的に動作するため、ハイブリッドディスクリソースの活性/非活性に時間がかかることがあります。

• マウントポイントにシンボリックリンクを含むパスを指定すると、異常検出時の動作に [強制終了] を選択しても強制終了できません。

  また、同様に「//」を含むパスを指定した場合にも、強制終了できません。

• Linux の md によるストライプセット、ボリュームセット、ミラーリング、パリティ付きストライプセットを使用したディスクを、クラスタパーティションやデータパーティションに指定することはできません。

• Linux の LVM によるボリュームを、クラスタパーティションやデータパーティションに指定することは可能です。

  なお、SuSE Linux については、LVM や MultiPath によるボリュームを、クラスタパーティションやデータパーティションに使用することはできません。

• ハイブリッドディスクリソース (ミラーパーティションデバイス) を Linux の md や LVMによるストライプセット、ボリュームセット、ミラーリング、パリティ付きストライプセットの対象とすることはできません。

• ハイブリッドディスク用のディスクとして使用するディスクのジオメトリがサーバ間で異なる場合の注意

  fdisk コマンドなどで確保したパーティションサイズはシリンダあたりのブロック (ユニット) 数でアラインされます。

  データパーティションのサイズと初期ミラー構築の方向の関係が以下になるようにデータパーティションを確保してください。

  コピー元のサーバ ≦ コピー先のサーバ
  コピー元のサーバとは、ハイブリッドディスクリソースが所属するフェイルオーバグループのサーバグループのうちプライオリティが高いサーバグループのサーバを指します。

  コピー先のサーバとは、ハイブリッドディスクリソースが所属するフェイルオーバグループのサーバグループのうちプライオリティが低いサーバグループのサーバを指します。
  なお、データパーティションは同程度のサイズで確保するようにしてください。

  データパーティションのサイズが、コピー元側とコピー先側とで 32GiB, 64GiB, 96GiB, … (32GiBの倍数) を跨がないように注意してください。

  32GiBの倍数を跨ぐサイズの場合、初期ミラー構築に失敗することがあります。

例)

組み合わせ	データパーティションのサイズ		説明
	Server 1側	Server 2側
OK	30GiB	31GiB	両方とも0～32GiB未満の範囲内にあるのでOK
OK	50GiB	60GiB	両方とも32GiB以上～64GiB未満の範囲内にあるのでOK
NG	30GiB	39GiB	32GiBを跨いでいるのでNG
NG	60GiB	70GiB	64GiBを跨いでいるのでNG

• ハイブリッドディスクリソースで使用するファイルに対して open() システムコールのO_DIRECT フラグを使用しないでください。

  例えば Oracle の設定パラメータの filesystemio_options = setall などがこれに該当します。

• DISK 監視の READ (O_DIRECT) 方式の監視先として ミラーパーティションデバイス(/dev/NMP1など) を指定しないでください。

• ハイブリッドディスクを使用するクラスタ構成では、モニタリソースの最終動作等を、[クラスタサービス停止] に設定しないようにしてください。

• ハイブリッドディスクリソースのデータパーティションおよびクラスタパーティションには、全サーバで同一の論理セクタサイズのディスクを使用してください。異なる論理セクタサイズのディスクを使用すると、正常に動作しません。データパーティションとクラスタパーティションでは論理セクタサイズが異なっていても動作可能です。

例)

組み合わせ	パーティションの論理セクタサイズ				説明
	Server 1側	Server 1側	Server 2側	Server 2側
	データパー ティション	クラスタパー ティション	データパー ティション	クラスタパー ティション
OK	512B	512B	512B	512B	論理セクタサイズが統一されている
OK	4KB	512B	4KB	512B	データパーティションで4KB、クラスタパーティションで512Bに統一されている
NG	4KB	512B	512B	512B	データパーティションの論理セクタサイズが統一されていない
NG	4KB	4KB	4KB	512B	クラスタパーティションの論理セクタサイズが統一されていない

• ハイブリッドディスクリソースのデータパーティションおよびクラスタパーティションとして使用するディスクについて、HDDとSSDを混在させないでください。混在させると最適な性能が得られません。データパーティションとクラスタパーティションではディスクタイプが異なっていても動作可能です。

  例)

  組み合わせ	パーティションのディスクタイプ				説明
  	Server 1側	Server 1側	Server 2側	Server 2側
  	データパー ティション	クラスタパー ティション	データパー ティション	クラスタパー ティション
  OK	HDD	HDD	HDD	HDD	ディスクタイプが統一されている
  OK	SSD	HDD	SSD	HDD	データパーティションでSSD、クラスタパーティションでHDDに統一されている
  NG	SSD	HDD	HDD	HDD	データパーティションでHDD/SSDが混在している
  NG	SSD	SSD	SSD	HDD	クラスタパーティションでHDD/SSDが混在している

• 現用系サーバ異常ダウンした後のミラー復帰の挙動について

  現用系サーバが異常ダウンした場合、ダウンするタイミングによって全面ミラー復帰となる場合と差分ミラー復帰になる場合があります。

• 共有ディスクで接続されたサーバ (同一サーバグループ内のサーバ) でリソースを活性する場合

  図はハイブリッド構成の例です。Server 1とServer 2が Shared diskを共有し、Shared diskの Cluster partition、および Data partition の内容がServer 3に接続された Diskにミラーリングされています。

  

  図 3.113 ハイブリッド構成 (1)（同一サーバグループ内でリソース活性, 通常時）

  Server 1がダウンすると、Hybrid Disk Resource は Server 2にフェイルオーバします。

  

  図 3.114 ハイブリッド構成 (2)（同一サーバグループ内でリソース活性, Server 1ダウン）

  Shared disk と Server 3 に接続されたDiskの間でミラー復帰処理を行う必要がある場合、Server 1がダウンしたタイミングによってその処理内容が異なります。

  1. Server 1（現用系サーバ）がダウンする直前に、Server 1でServer 3（待機系サーバ）へのデータ送信の失敗/ACK1の受信エラーを認識し、クラスタパーティションへ記録できた場合

     ダウンした Server 1と同一サーバグループに属するサーバ（Server 2）が最新データをもっていると判断され、Server 2から Server 3への全面ミラー復帰が実行されます。
     

     図 3.115 ハイブリッド構成 (3)（同一サーバグループ内でリソース活性, Server 1ダウン後のミラー復帰）

  2. その他の場合

     Server 2とServer 3のどちらが最新データをもっているか判断できないため、ミラーは保留状態になります。

     フェイルオーバグループのフェイルオーバ属性が "自動フェイルオーバ" である場合、次のプライオリティのサーバでリソースが活性するので、保留状態を経由してリソースが活性化されます。

     フェイルオーバグループのフェイルオーバ属性が手動フェイルオーバの場合には、ミラーは保留状態になります。

• 相手サーバグループのサーバでリソースを活性する場合

  図はハイブリッド構成の例です。 Server 1とServer 2が Shared diskを共有し、Shared diskの Cluster partition、および Data partition の内容がServer 3に接続された Diskにミラーリングされています。

  

  図 3.116 ハイブリッド構成 (1)（相手サーバグループ内でリソース活性, 通常時）

  Server 1がダウンすると、Hybrid Disk Resource は Server 3にフェイルオーバします。

  

  図 3.117 ハイブリッド構成 (2)（相手サーバグループ内でリソース活性, Server 1ダウン）

  1. Server 1がダウンする直前、Server 3へのデータ送信の失敗/ACK1の受信エラーをServer 1が認識して、クラスタパーティションにそれを記録できた場合

     Server group 1が最新データをもっていると判断され、Server 3におけるハイブリッドディスクリソースを含むグループの活性が失敗します。

  

  図 3.118 ハイブリッド構成 (3)（相手サーバグループ内でリソース活性, Server 1ダウン後のミラー復帰）

  2. それ以外の場合

     Server 2とServer 3のどちらが最新データをもっているか判断できないため、ミラーは保留状態になります。

     フェイルオーバグループのフェイルオーバ属性が "自動フェイルオーバ" である場合、次のプライオリティのサーバでリソースが活性するので、保留状態を経由してリソースが活性化されます。

     フェイルオーバグループのフェイルオーバ属性が手動フェイルオーバの場合には、ミラーは保留状態になります。

  

  図 3.119 ハイブリッド構成 (4)（相手サーバグループ内でリソース活性, Server 1ダウン後のミラー復帰）

3.11.5. mount前後の処理の流れ

ハイブリッドディスクリソース活性時のmountの処理は以下のように行われます。

ファイルシステムにnoneが指定されている場合、mount処理は行いません。

1. 事前にマウントされているか？

   既にマウントされていた場合 → ×へ

2. マウント前に fsck を実行する設定か？

   fsck を実行するタイミングである → デバイスに fsck を実行する

3. デバイスをマウントする

   マウント成功 → ○へ

4. マウントのリトライを行う設定か？

   リトライしない設定の場合 → ×へ

5. マウント失敗時に fsck（xfs_repair）を実行する設定の場合

   2.でfsckを実行して成功していた場合 → 6.へ

   3.でタイムアウトにより失敗していた場合 → 6.へ

   上記以外の場合 → デバイスにfsck（xfs_repair）を実行する

6. 再度デバイスのマウントを試みる

   マウント成功 → ○へ

7. マウントのリトライ回数以内か？

   リトライ回数以内の場合 → 6.へ

   リトライ回数を超えた場合 → ×へ

○ リソース起動（マウント成功）

× リソース起動失敗（マウントされていない）

3.11.6. umount前後の処理の流れ

ハイブリッドディスクリソース非活性時のumountの処理は以下のように行われます。

ファイルシステムにnoneが指定されている場合、umount処理は行いません。

1. 事前にアンマウントされているか？

   既にアンマウントされていた場合 → ×へ

2. デバイスをアンマウントする

   アンマウント成功 → ○へ

3. アンマウントのリトライを行う設定か？

   リトライしない設定の場合 → ×へ

4. まだマウントされているか？（マウント一覧からマウントポイントが削除されていて、ミラーデバイスも未使用状態になっているか？）

   もうマウントされていない → ○へ

5. マウントポイントを使用しているプロセスのKILLを試みる

6. 再度デバイスのアンマウントを試みる

   アンマウント成功 → ○へ

7. アンマウントタイムアウトではなく、かつ、マウント一覧からマウントポイントが削除されているか？

   マウントポイントは既に削除された → ミラーデバイスが使用されなくなるまで待つ

   （最大でアンマウントタイムアウトの時間まで待つ）

8. アンマウントのリトライ回数以内か？

   リトライ回数以内の場合 → 4.へ

   リトライ回数を超えた場合 → ×へ

○ リソース停止（アンマウント成功）

× リソース停止失敗（マウントされたまま、もしくは既にアンマウントされていた）

3.11.7. 詳細タブ

以下についてはミラーディスクリソースと同一です。ミラーディスクリソースを参照してください。

• ハイブリッドディスク詳細タブ (ミラーディスク詳細タブを参照ください)

• ミラーディスクコネクトの選択

• ハイブリッドディスク調整プロパティ (ミラーディスク調整プロパティを参照ください)

  • マウントタブ

  • アンマウントタブ

  • fsck タブ

  • xfs_repair タブ

  • ミラータブ (初期 mkfs を行う以外のパラメータ)

  • ミラードライバタブ

以下のタブについてはミラーディスクリソースと異なります。

• ハイブリッドディスク調整プロパティのミラータブ [初期 mkfs を行う]

初期mkfsを行う

本バージョンのハイブリッドディスクリソースでは、クラスタを構築するときの自動の初期 mkfsは実行されません。

3.12. ボリュームマネージャリソースを理解する

3.12.1. ボリュームマネージャリソースの依存関係

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

グループリソースタイプ
ダイナミック DNS リソース
フローティング IP リソース
仮想 IP リソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース
AWS DNS リソース
Azure DNS リソース

3.12.2. ボリュームマネージャリソースとは?

• ボリュームマネージャとは、複数のストレージやディスクを 1 つの論理的なディスクとして扱うためのディスク管理用ソフトウェアです。

• ボリュームマネージャリソースは、ボリュームマネージャによって管理される論理ディスクを制御します。

• 業務に必要なデータは、論理ディスク内に格納しておくことで、フェイルオーバ時、フェイルオーバグループの移動時などに、自動的に引き継がれます。

図 3.120 ボリュームマネージャリソース (1)

図 3.121 ボリュームマネージャリソース (2)

3.12.3. ボリュームマネージャリソースに関する注意事項

<ボリュームマネージャリソース全般>

• ミラーディスクはボリュームマネージャリソースの管理対象とはしないでください。

• 個々のボリュームの制御はディスクリソースで行います。

• 論理ディスクのアクセス制御 (import/export) は、CLUSTERPRO が行いますので、 OS 側で import/export する設定を行わないでください。

<ボリュームマネージャ [lvm] での利用時>

• ボリュームグループの定義は CLUSTERPRO 側で行いません。

• 個々のボリュームの制御が必須のため、最低 1 つはディスクリソースが必要です。

• CLUSTERPRO の設定情報に含まれるボリュームグループは OS 起動時に自動的にエクスポート処理を行います。

• CLUSTERPRO の設定情報に含まれていないボリュームグループはエクスポートしません。

• 共有ディスクで構築した VG を対象ボリュームに指定した場合、LVMの仕様により、VG の import/export 状態は共有ディスク上に記録されるため、現用系サーバで活性(import), 非活性(export) すると、待機系サーバでも同様の状態に見える場合があります。

• Red Hat Enterprise Linux 7 以降の環境で、ボリュームマネージャリソースにて LVM の制御を行う場合、LVM メタデータデーモンを無効にする必要があります。

• リソース活性時に以下のコマンドを実行します。

  コマンド	オプション	使用するタイミング
  vgs	-P	ボリュームグループのステータス確認時
  	--noheadings	ボリュームグループのステータス確認時
  	-o vg_attr,vg_name	ボリュームグループのステータス確認時
  vgimport	(無し)	ボリュームグループインポート時
  vgscan	(無し)	ボリュームグループスキャン時
  vgchange	-ay	ボリュームグループ活性時

• リソース活性時のシーケンスは下記の通りとなります。

  

  図 3.122 リソース活性時のシーケンス（lvm）

  1. ボリュームグループステータス確認コマンドを実行します。実行が失敗すると、活性は失敗です。

     vgs -P --noheadings -o vg_attr, vg_name VG名

  2. ボリュームグループインポートコマンドを実行します。実行が失敗すると活性は失敗です。

     vgimport VG名

  3. ボリュームグループスキャンコマンドを実行します。

     vgscan
     

  4. ボリュームグループ活性コマンドを実行します。実行が成功すると活性は成功、失敗すると活性は失敗です。

     vgchange -ay VG名

• リソース非活性時に以下のコマンドを実行します。

  コマンド	オプション	使用するタイミング
  vgs	-P	ボリュームグループのステータス確認時
  	--noheadings	ボリュームグループのステータス確認時
  	-o vg_attr,vg_name	ボリュームグループのステータス確認時
  vgchange	-an	ボリュームグループ非活性時
  vgexport	(無し)	ボリュームグループエクスポート時

• リソース非活性時のシーケンスは下記の通りとなります

  

  図 3.123 リソース非活性時のシーケンス（lvm）

  1. ボリュームグループステータス確認コマンドを実行します。実行が失敗すると、非活性は失敗です。

     実行が成功した場合、対象VGがエクスポート可能状態であれば非活性は成功です。

     vgs -P --noheadings -o vg_attr, vg_name VG名

  2. ボリュームグループ非活性コマンドを実行します。実行が失敗すると、非活性は失敗です。

     vgchange -an VG名

  3. ボリュームグループエクスポートコマンドを実行します。成功すれば非活性は成功、失敗すれば非活性は失敗です。

     vgexport VG名

<ボリュームマネージャ [zfspool] での利用時>

• ZFSストレージプールをiSCSI環境で利用している場合、iSCSI接続の断線が発生するとZFSに対するexport等の処理が大きく遅延することがあります(OSの制限)。ZFSのiSCSI断線時の挙動は、ZFSのプロパティ値 "failmode" で規定されますが、CLUSTERPROでは、"failmode=panic" を推奨しています。"failmode=panic"の場合、iSCSI断線後、一定時間でOSが自主的にpanicするように動作します。

• ZFSのプロパティ値 "mountpoint" が legacy に設定されているデータセットは、ストレージプールをインポートしただけではファイルシステムがマウントされません。この場合は、ボリュームマネージャリソースの他に、ディスクリソースを用いてZFSファイルシステムのマウント/アンマウントを行う必要があります。

• Ubuntu Server 16.04 以降の場合、OS起動のタイミングによっては両系活性が発生することがあります。OS起動時にストレージプールが自動インポートされてもファイルシステムが自動マウントされないようにしてください。

  自動マウントを抑止する方法は以下のいずれかがあります。

  • ZFS のプロパティ値 "mountpoint" を "legacy" に設定する。

  • ZFS のプロパティ値 "canmount" を "noauto" に設定する。

  この設定により、OS起動時に自動インポートされても自動マウントは抑止され、両系活性を防ぐことができます。この場合は、ディスクリソースを用いて ZFSファイルシステムのマウント/アンマウントを行う必要があります。

3.12.4. 詳細タブ

ボリュームマネージャ

利用するボリュームマネージャを指定します。以下のボリュームマネージャが選択できます。

• lvm (LVM ボリュームグループ制御)

• zfspool (ZFS ストレージプール制御)

ターゲット名 (1023 バイト以内)

ボリュームの名前を<VG名>の形式(ターゲット名のみ)で設定します。

コンボボックスの選択肢は、すべてのサーバからボリュームグループ情報を取得し、一台以上のサーバに存在するボリュームグループがすべて表示されます。

ボリュームマネージャが [lvm] の場合、複数ボリュームをまとめて制御することができます。複数ボリュームを制御する場合は、ボリュームの名前を半角スペースで区切って設定します。

調整

[ボリュームマネージャリソース調整プロパティ] ダイアログボックスを表示します。ボリューム マネージャリソースの詳細設定を行います。

ボリュームマネージャリソース調整プロパティ([ボリュームマネージャ] が [zfspool] 以外の場合)

インポートタブ

インポートに関する詳細設定が表示されます。

インポートタイムアウト (1～9999)

ボリュームをインポートする場合のコマンドの終了を待つタイムアウトを設定します。

ボリューム起動タイムアウト (1～9999)

起動コマンドのタイムアウトを設定します。

ボリュームステータス確認タイムアウト (1～999)

ステータス確認コマンドのタイムアウトを設定します。

ボリュームマネージャが [lvm] の場合に利用可能です。

既定値

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

エクスポートタブ

エクスポートに関する詳細設定が表示されます。

ボリューム停止タイムアウト (1～9999)

ボリューム非活性コマンドのタイムアウトを設定します。

エクスポートタイムアウト (1～9999)

エクスポート/デポートコマンドのタイムアウトを設定します。

ボリュームステータス確認タイムアウト (1～999)

ステータス確認コマンドのタイムアウトを設定します。

ボリュームマネージャが [lvm] の場合に利用可能です。

既定値

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

ボリュームマネージャリソース調整プロパティ([ボリュームマネージャ] が [zfspool] の場合)

インポートタブ

インポートに関する詳細設定が表示されます。

インポートタイムアウト (1～9999)

ボリュームをインポートする場合のコマンドの終了を待つタイムアウトを設定します。

強制インポート

インポート失敗時に強制インポートを試行するかを設定します。チェックボックスが ON の場合に強制インポートを行います。

pingチェック行う

強制インポートが ON の場合のみ有効な設定です。

インポート失敗の原因が、「他ホストでインポート済み」であった場合に、強制インポートの前にping でインポート済みホストの死活監視を行うかを設定します。死活監視を行い、インポート済みホストが動作していた場合には強制活性が行われません。これにより、複数ホストによる同一プールの同時インポートを防止します。チェックボックスが ON の場合に死活監視を行います。

注釈

本設定を有効にすると、CLUSTERPRO が停止してからOSがシャットダウンするまでに時間がかかった場合に、フェイルオーバに失敗する可能性があります。たとえば、モニタリソースが異常を検出し運用系サーバをシャットダウンする場合に、運用系の停止前に待機系でボリュームマネージャの活性が開始されてしまうと、ping チェックによって活性に失敗します。

既定値

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

エクスポートタブ

エクスポートに関する詳細設定が表示されます。

エクスポートタイムアウト (1～9999)

ボリュームをエクスポートする場合のコマンドの終了を待つタイムアウトを設定します。

強制エクスポート

エクスポート失敗時に強制エクスポートを試行するかを設定します。チェックボックスが ON の場合に強制エクスポートを行います。

既定値

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

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

3.13.1. ダイナミック DNS リソースの依存関係

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

グループリソースタイプ
仮想 IP リソース
フローティング IP リソース
AWS Elastic IPリソース
AWS 仮想IPリソース
AWS セカンダリ IP リソース

3.13.2. ダイナミック DNS リソースとは?

• ダイナミック DNS リソースは、Dynamic DNS サーバに仮想ホスト名と活性サーバの IP アドレスを登録します。クライアントアプリケーションは、仮想ホスト名を使用してクラスタサーバに接続することができます。仮想ホスト名を使用することにより、"フェイルオーバ"または、"グループの移動" が発生しても、クライアントは、接続先サーバの切り替えを意識する必要がありません。

以下の図には、ダイナミックDNSサーバ（DDNSサーバ）とServer 1およびServer 2、そして Clientが描かれています。 Server 1は、仮想ホスト名とIPアドレスをDDNSサーバに登録します。

図 3.124 ダイナミックDNSサーバを使用する構成 (1)

Clientは、アクセス先である仮想ホスト名に対応するIPアドレスを、DDNSサーバに問い合わせます。 問い合わせに対して、DDNSサーバは仮想ホスト名に対応する Server 1のIPアドレスを回答します。 Clientは仮想ホスト名のIPアドレスに接続します。

図 3.125 ダイナミックDNSサーバを使用する構成 (2)

Server 1がダウンし、Server 2へのフェイルオーバが発生します。

図 3.126 ダイナミックDNSサーバを使用する構成 (3)

Server 2は、仮想ホスト名とIPアドレスをDDNSサーバに登録します。

図 3.127 ダイナミックDNSサーバを使用する構成 (4)

Clientは、アクセス先である仮想ホスト名に対応するIPアドレスを、DDNSサーバに問い合わせます。 問い合わせに対して、DDNSサーバは仮想ホスト名に対応する Server 2のIPアドレスを回答します。 Clientは仮想ホスト名のIPアドレスに接続します。

図 3.128 ダイナミックDNSサーバを使用する構成 (5)

3.13.3. ダイナミック DNS リソースを使用する場合の事前準備

ダイナミック DNS リソースを使用する前に DDNS サーバを構築する必要があります。

以下、BIND9 の例で説明します。

ダイナミック DNS リソースの使用方式によって、DDNS サーバを構築する時に、

/etc/named.conf の設定が下記の 2 種類があります。使いたい方式で DDNS サーバ 上の /etc/named.conf を設定してください。

• 認証あり方式でダイナミック DNS リソースを使用したい場合

  BIND9 サーバ上で [dnssec-keygen] コマンドを使って共有鍵を作成します。/etc/named.conf に共有鍵を追記し、ゾーンファイルの更新を許可するように設定します。

  ダイナミック DNS リソースを追加する場合、認証キー名に共有鍵名を記入し、認証キー値に共有鍵値を記入してください。

  注釈

  DDNS サーバの構築方法、[dnssec-keygen] コマンドの使用方法、allow-update以外の設定方法等については、BIND のマニュアルを参照してください。

  設定例：

  1. 共有鍵を生成します。

     example は共有鍵名です。

     #dnssec-keygen -a HMAC-MD5 -b 256 -n HOST example

     [dnssec-keygen] コマンドを実行した後、下記の 2 つファイルが生成されます。共有鍵のため、2 つのファイルの Key は同じです。

     Kexample.+157+09088.key
     Kexample.+157+09088.private

     以下の named.conf の設定では Kexample.+157+09088.key から共有鍵を抽出していますが、Kexample.+157+09088.private を使っても同じになります。

     Kexample.+157+09088.key の共有鍵の値は下記の太字部分です。

     # cat Kexample.+157+09088.key
     example. IN KEY 512 3 157 iuBgSUEIBjQUKNJ36NocAgaB

  2. /etc/named.conf に共有鍵の情報を追記します。

     key "example" {
         algorithm hmac-md5;
         secret "iuBgSUEIBjQUKNJ36NocAgaB";
     };
     

  3. /etc/named.conf の中で共有鍵の情報を zone ステートメントに追記します。

     zone "example.jp" {
         :
         allow-update{
             key example;
         };
         :
     };
     

  4. Cluster WebUI でダイナミック DNS リソースを追加する時、認証キー名に共有鍵名 (example)を記入して、認証キー値に共有鍵値 (iuBgSUEIBjQUKNJ36NocAgaB) を記入してください。

• 認証なし方式でダイナミック DNS リソースを使用したい場合

  /etc/named.conf に、ゾーンファイルを更新可能な IP 範囲 [allow-update{xxx.xxx.xxx.xxx} ] として、必ずクラスタ内の全サーバの IP を設定する必要があります。

  設定例：

  クラスタ内サーバ 1 のIP：192.168.10.110

  クラスタ内サーバ 2 のIP：192.168.10.111

  1. /etc/named.confのzone ステートメントに更新を許可する IP 範囲を追記します。

     zone "example.jp" {
         :
         //更新可能なIP範囲
         allow-update {
             192.168.10.0/24;
         };
         :
     };
     

     または

     zone "example.jp" {
         :
         //更新可能なIP範囲
         allow-update {
             192.168.10.110;
             192.168.10.111;
         };
         :
     };
     

  2. ダイナミック DNS リソースを追加する場合、認証キー名と認証キー値に何も記入しないでください。

3.13.4. ダイナミック DNS リソースに関する注意事項

• ダイナミック DNS リソースを利用する場合、各サーバ上に bind-utils のパッケージが必要です。

• 各サーバで仮想ホスト名の名前解決ができる必要があります。

• 各サーバの IP は異なるセグメントに存在する場合、FIP をダイナミック DNS リソースの IP として設定することはできません。

• 各サーバの IP アドレスを DDNS サーバに登録したい場合、サーバ別設定で各サーバの IP を設定してください。

• クライアントから仮想ホスト名を使用して接続を行っている場合、ダイナミック DNS リソースを持つグループのフェイルオーバが発生すると、再接続が必要なことがあります。(ブラウザの再起動など)

• 本リソースの認証あり方式では BIND9 を使って構築した DDNS サーバのみ対応します。認証なし方式を使う場合、ダイナミック DNS リソースには認証キー名と認証キー値に何も記入しないでください。

• 仮想ホスト名を経由した Cluster WebUI 接続時の挙動について

  • ダイナミックDNSリソースに各サーバのIPアドレスをサーバ別設定している場合

    クライアントから仮想ホスト名を使用して Cluster WebUI を接続している場合、ダイナミック DNS リソースを持つグループのフェイルオーバが発生すると、Cluster WebUI の接続は自動的に切り替わりません。ブラウザを再起動し、再度Cluster WebUI を接続する必要があります。
  • ダイナミック DNS リソースに FIP アドレスを設定している場合

    クライアントから仮想ホスト名を使用して Cluster WebUI を接続している場合、ダイナミック DNS リソースを持つグループのフェイルオーバが発生すると、Cluster WebUI の接続は自動的に切り替わります。
• 認証あり方式でダイナミック DNS リソースを使用する場合、クラスタ内の各サーバの時刻と DDNS サーバの時刻の差が 5 分未満である必要があります。

  時間差が 5 分以上の場合、DDNS サーバに仮想ホスト名の登録ができません。

3.13.5. 詳細タブ

仮想ホスト名

DDNS サービスに登録する仮想ホスト名を入力します。

IPアドレス サーバ個別設定可能

仮想ホスト名に対応する IP アドレスを記入します。

FIP リソースと一緒に使用する場合、[共通] タブに FIP リソースの IP アドレスを入力します。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力してください。

DDNSサーバ

DDNS サーバの IP アドレスを入力します。

ポート番号

DDNS サーバのポート番号を記入します。既定値は 53 です。

認証キー名

[dnssec-keygen] コマンドを使って共有鍵を生成したときの共有鍵名を入力します。

認証キー値

[dnssec-keygen] コマンドを使って生成した共有鍵の値を入力します。

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

3.14.1. AWS Elastic IPリソースの依存関係

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

3.14.2. AWS Elastic IPリソースとは?

クライアントアプリケーションは、Amazon Web Services(以下、AWS) 環境の Amazon Virtual Private Cloud(以下、VPC)に対して、Elastic IP(以下、EIP) アドレスを使用してクラスタサーバに接続することができます。EIP アドレスを使用することにより、"フェイルオーバ" または、"グループの移動" の移動が発生しても、クライアントは、接続先 VPC の切り替えを意識する必要がありません。

EIP 制御による HA クラスタ

インスタンスを Public な Subnet 上に配置する(業務を VPC の外部に公開する)場合に使用します。

クラスタ化するインスタンスは各 Availability Zone(以下、AZ) の Public な Subnet 上に配置されており、各インスタンスは、インターネットゲートウェイを経由してインターネットへアクセスできるような構成を想定しています。

図 3.129 AWS Elastic IP リソースを使用する構成

3.14.3. AWS Elastic IPリソースに関する注意事項

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS Elastic IPリソースの設定について」を参照してください。

• IAM の設定については『スタートアップガイド』の「注意制限事項」-「OS インストール後、CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

3.14.4. AWS Elastic IPリソースから実行するAWS CLIへコマンドラインオプションを反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS CLI コマンドラインオプション」を参照してください。

3.14.5. AWS Elastic IPリソースから実行するAWS CLIへ環境変数を反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS 関連機能実行時の環境変数」を参照してください。

3.14.6. 詳細タブ

EIP ALLOCATION ID (45 バイト以内)

EIP 制御の場合、付け替え対象の EIP の ID を指定します。

ENI ID (45 バイト以内) サーバ個別設定可能

EIP 制御の場合、EIP を割り当てる ENI ID を指定します。サーバ別設定が必須です。[共通]タブでは、任意のサーバの ENI ID を記載し、他のサーバは個別設定を行うようにしてください。

AWS Elastic IP リソース調整プロパティ

パラメータタブ

タイムアウト (1～999)

AWS Elastic IPリソースの活性/非活性の各処理で実行される [AWS CLI] コマンドのタイムアウトを設定します。

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

3.15.1. AWS 仮想IPリソースの依存関係

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

3.15.2. AWS 仮想IPリソースとは?

クライアントアプリケーションは、AWS 環境の VPC に対して、仮想IP(以下、VIP)アドレスを使用してクラスタサーバに接続することができます。VIP アドレスを使用することにより、"フェイルオーバ" または、"グループの移動" が発生しても、クライアントは、接続先 VPC の切り替えを意識する必要がありません。AWS仮想IPリソースでは活性時に AWS CLI を実行して route table の更新処理を行います。

VIP 制御による HA クラスタ

インスタンスを Private な Subnet 上に配置する(業務を VPC 内部に公開する)場合に使用します。

クラスタ化するインスタンス及び、そのインスタンスへアクセスを行うインスタンス群は各 Availability Zone(以下、AZ) の Private な Subnet 上に配置されており、各インスタンスは、Public な Subnet に配置された NATゲートウェイ を経由してインターネットへアクセスできるような構成を想定しています。

図 3.130 AWS 仮想 IP リソースを使用する構成

3.15.3. AWS 仮想IPリソースに関する注意事項

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS 仮想IPリソースの設定について」を参照してください。

• IAM の設定については『スタートアップガイド』の「注意制限事項」-「OS インストール後、CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

3.15.4. AWS 仮想IPリソースから実行するAWS CLIへコマンドラインオプションを反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS CLI コマンドラインオプション」を参照してください。

3.15.5. AWS 仮想IPリソースから実行するAWS CLIへ環境変数を反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS 関連機能実行時の環境変数」を参照してください。

3.15.6. 詳細タブ

IPアドレス (45 バイト以内)

VIP 制御の場合、使用する VIP アドレスを指定します。VIP アドレスとしては、VPC の CIDR に属さない IP アドレスを指定する必要があります。

VPC ID (45 バイト以内) サーバ個別設定可能

VIP 制御の場合、サーバが所属する VPC ID を指定します。サーバ個別設定を行う場合、[共通]タブでは、任意のサーバの VPC ID を記載し、他のサーバは個別設定を行うようにしてください。ルーティングの設定方法については、以下を参照してください。

『CLUSTERPRO X Amazon Web Services 向け HA クラスタ 構築ガイド （Linux 版）』 - 「VPC 環境の設定」

ENI ID (45 バイト以内) サーバ個別設定可能

VIP 制御の場合、VIPのルーティング先の ENI ID を指定します。指定する ENI ID は Source/Dest. Check を disabled としておく必要があります。サーバ別設定が必須です。サーバ個別設定を行う場合、[共通]タブでは、任意のサーバの ENI ID を記載し、他のサーバは個別設定を行うようにしてください。

AWS 仮想IP リソース調整プロパティ

パラメータタブ

起動タイムアウト (1～9999)

AWS 仮想IPリソースの活性時に使われるスクリプトのタイムアウトを設定します。

停止タイムアウト (1～9999)

AWS 仮想IPリソースの非活性時に使われるスクリプトのタイムアウトを設定します。

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

3.16.1. AWS セカンダリ IP リソースの依存関係

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

3.16.2. AWS セカンダリ IP リソースとは?

クライアントアプリケーションは、AWS 環境の VPC に対して、セカンダリ IP アドレスを使用してクラスタサーバに接続することができます。

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

AWS セカンダリ IP リソースでは活性時にセカンダリ IP アドレスの割り当て処理、非活性時にセカンダリ IP アドレスの割り当て解除処理を行います。

セカンダリ IP 制御による HA クラスタ

インスタンスを Private な Subnet 上に配置する(業務を VPC 内部に公開する)場合に使用します。

クラスタ化するインスタンス及び、そのインスタンスへアクセスを行うインスタンス群は各 Availability Zone(以下、AZ) の Private な Subnet 上に配置されており、各インスタンスは、Public な Subnet に配置された NATゲートウェイ を経由してインターネットへアクセスできるような構成を想定しています。

図 3.131 AWS セカンダリ IP リソースを使用する構成

注釈

図中の SIP はセカンダリ IP アドレスを指します。

3.16.3. AWS セカンダリ IP リソースに関する注意事項

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS セカンダリ IP リソースの設定について」を参照してください。

• IAM の設定については『スタートアップガイド』の「注意制限事項」-「OS インストール後、CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

3.16.4. AWS セカンダリ IP リソースから実行するAWS CLIへコマンドラインオプションを反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS CLI コマンドラインオプション」を参照してください。

3.16.5. AWS セカンダリ IP リソースから実行するAWS CLIへ環境変数を反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS 関連機能実行時の環境変数」を参照してください。

3.16.6. 詳細タブ

IPアドレス (45 バイト以内)

使用するセカンダリ IP アドレスを指定します。セカンダリ IP アドレスとしては、インスタンスが属するサブネットのネットワーク内の IP アドレスを指定する必要があります。

ENI ID (45 バイト以内) サーバ個別設定可能

セカンダリ IP アドレスを割り当てるネットワークインターフェイスの ENI ID を指定します。サーバ別設定が必須です。サーバ個別設定を行う場合、[共通]タブでは、任意のサーバの ENI ID を記載し、他のサーバは個別設定を行うようにしてください。

AWS セカンダリ IP リソース調整プロパティ

パラメータタブ

起動タイムアウト (1～9999)

AWS セカンダリ IP リソースの活性時に使われるスクリプトのタイムアウトを設定します。

停止タイムアウト (1～9999)

AWS セカンダリ IP リソースの非活性時に使われるスクリプトのタイムアウトを設定します。

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

3.17.1. AWS DNS リソースの依存関係

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

3.17.2. AWS DNS リソースとは?

図 3.132 AWS DNSリソースを使用する構成

Amazon Web Services(以下、AWS) で利用する仮想ホスト名(DNS 名)に対応する IP アドレスを活性時に AWS CLI を実行して登録、非活性時 AWS CLI を実行して削除します。

クライアントはフェイルオーバグループが起動しているノードに仮想ホスト名でアクセスすることができます。

AWS DNS リソースを利用することで、クライアントは AWS 上でもフェイルオーバやグループの移動による接続先ノードの切り替えを意識する必要がありません。

AWS DNS リソースを利用する場合、クラスタの構築を行う前に以下の準備が必要です。

• Amazon Route 53 の Hosted Zone の作成

• AWS CLI のインストール

3.17.3. AWS DNS リソースの活性タイミング

本リソースはDNS レコードへのアップデートがAmazon Route 53へ反映されるまで待機した後に活性状態へと移行します。

注釈

本機能は CLUSTERPRO X 5.0 以降のバージョンで使用できる機能です。

CLUSTERPRO X 4.3 以前からアップグレードを行った場合に本機能を使用するには、本グループリソースを一度削除し、再追加することで設定してください。

3.17.4. AWS DNS リソースに関する注意事項

• クライアントから仮想ホスト名(DNS 名)を使用して接続を行っている場合、AWS DNS リソースが追加されているフェイルオーバグループでフェイルオーバが発生すると再接続が必要な場合があります。

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS DNS リソースの設定について」を参照してください。

• IAM の設定については『スタートアップガイド』の「注意制限事項」-「OS インストール後、CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

3.17.5. AWS DNS リソースから実行するAWS CLIへコマンドラインオプションを反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS CLI コマンドラインオプション」を参照してください。

3.17.6. AWS DNS リソースから実行するAWS CLIへ環境変数を反映させるには

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「AWS 関連機能実行時の環境変数」を参照してください。

3.17.7. 詳細タブ

ホストゾーンID (255バイト以内)

Amazon Route 53 の Hosted Zone ID を入力します。

リソースレコードセット名 (255バイト以内)

DNS A レコード名を入力します。レコード名の末尾にはドット (.) を付けてください。[リソースレコードセット名] にエスケープコードを含む場合、監視が異常になります。エスケープコードを含まない [リソースレコードセット名] を設定してください。[リソースレコードセット名] は小文字で指定してください。

IPアドレス (39バイト以内) サーバ個別設定可能

仮想ホスト名(DNS 名)に対応する IP アドレスを入力します(IPv4)。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力します。サーバ個別設定を行う場合、[共通]タブでは任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

TTL (0～2147483647)

DNSサービスのキャッシュの生存期間(TTL=Time To Liveの略)を入力します。

非活性時にリソースレコードセットを削除する

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

  非活性時にレコードセットを削除します。
• チェックボックスがオフ(既定)

  非活性時にレコードセットを削除しません。削除しない場合、残存した仮想ホスト名(DNS 名)にクライアントからアクセスされる可能性があります。

調整

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

AWS DNS リソース調整プロパティ

パラメータタブ

タイムアウト (1～999)

AWS DNS リソースの活性/非活性の各処理で実行される [AWS CLI] コマンドのタイムアウトを設定します。

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

3.18.1. Azure プローブポートリソースの依存関係

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

グループリソースタイプ
EXEC リソース

3.18.2. Azure プローブポートリソースとは?

クライアントアプリケーションは、Microsoft Azure 環境の可用性セット上の仮想マシンに対して、パブリック仮想 IPアドレス(以下、VIP と記載)を使用してクラスタサーバに接続することができます。VIP アドレスを使用することにより、"フェイルオーバ" または、"グループの移動" が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。

図 3.133 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.134 Azure プローブポートリソースを使用する構成（内部負荷分散）

3.18.3. Azure プローブポートリソースに関する注意事項

• プライベート ポートとプローブ ポートが同じ場合、Azure プローブポートリソース、Azure プローブポートモニタリソースの追加は不要です。

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「Azure プローブポートリソースの設定について」を参照してください。

3.18.4. 詳細タブ

プローブポート (1～65535)

Microsoft Azure のロードバランサが、各サーバの死活監視に使用するポート番号を指定します。エンドポイント作成時に ProbePort に指定した値を指定してください。プローブ プロトコルには TCP を指定してください。

調整

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

Azure プローブポートリソース調整プロパティ

パラメータタブ

プローブ待ち受けのタイムアウト (5～999999999)

Microsoft Azure のロードバランサからの死活監視を待つタイムアウト時間を指定します。Azure のロードバランサから定期的に死活監視されているかを確認します。

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

3.19.1. Azure DNS リソースの依存関係

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

3.19.2. Azure DNS リソースとは?

図 3.135 Azure DNSリソースを使用する構成

Azure DNS リソースは、仮想ホスト名(DNS名)から設定した IP アドレスを得られるように Azure DNS のレコードセットや DNS A レコードの制御を行います。

クライアントはフェイルオーバグループが起動しているノードに仮想ホスト名(DNS 名)でアクセスすることができます。

Azure DNS リソースを利用することで、クライアントは Microsoft Azure 上でもフェイルオーバやグループの移動による接続先ノードの切り替えを意識する必要がありません。

Azure DNS リソースを利用する場合、クラスタの構築を行う前に以下の準備が必要です。詳細は『CLUSTERPRO X Microsoft Azure 向け HA クラスタ 構築ガイド（Linux 版）』を参照してください。

• Microsoft Azure のリソースグループ、DNS ゾーンの作成

• Azure CLI のインストール

  Azure CLI はRed Hat Enterprise Linux 7 および互換OSの場合は、Azure CLI 2.0を使用してください。

• Python のインストール(Azure CLI 2.0 を使用する場合のみ)

3.19.3. Azure DNS リソースに関する注意事項

• クライアントから仮想ホスト名(DNS 名)を使用して接続を行っている場合、Azure DNS リソースが追加されているフェイルオーバグループでフェイルオーバが発生すると再接続が必要な場合があります。

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」-「Azure DNS リソースの設定について」を参照してください。

• 『スタートアップガイド』の「注意制限事項」 - 「OSインストール後、CLUSTERPROインストール前」 - 「Azure DNS リソースについて」を参照してください。

3.19.4. 詳細タブ

レコードセット名 (253バイト以内)

Azure DNS の A レコードを登録するレコードセット名を入力します。

ゾーン名 (253バイト以内)

Azure DNS のレコードセットが所属する DNS ゾーン名を入力します。

IPアドレス (39バイト以内) サーバ個別設定可能

仮想ホスト名(DNS 名)に対応する IP アドレスを入力します(IPv4)。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力します。サーバ個別設定を行う場合、[共通]タブでは任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

TTL (0～2147483647)

DNSサービスのキャッシュの生存期間(TTL=Time To Liveの略)を入力します。

リソースグループ名 (180バイト以内)

DNS ゾーンが所属する Microsoft Azure のリソース グループ名を入力します。

ユーザURI (2083バイト以内)

Microsoft Azure ログイン用のユーザ URI を入力します。

テナントID (36バイト以内)

Microsoft Azure ログイン用の tenantId を入力します。

サービスプリンシパルのファイルパス (1023バイト以内)

Microsoft Azure ログイン用のサービス プリンシパルファイル名(証明書のファイル名)を入力します。絶対パスで指定してください。

サービスプリンシパルのthumbprint (256バイト以内)

Microsoft Azure ログイン用のサービス プリンシパル(証明書)の拇印。Azure CLI 1.0 使用時のみ入力してください。

Azure CLI ファイルパス (1023バイト以内)

Azure CLI のインストールパスおよびファイル名を入力します。絶対パスで指定してください。

非活性時にレコードセットを削除する

• チェックボックスがオン(既定)

  非活性時にレコードセットを削除します。
• チェックボックスがオフ

  非活性時にレコードセットを削除しません。削除しない場合、残存した仮想ホスト名(DNS 名)にクライアントからアクセスされる可能性があります。

調整

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

Azure DNS リソース調整プロパティ

パラメータタブ

タイムアウト (1～999)

Azure DNS リソースの活性/非活性の各処理で実行される [Azure CLI] コマンドのタイムアウトを設定します。

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

3.20.1. Google Cloud 仮想 IP リソースの依存関係

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

グループリソースタイプ
EXEC リソース

3.20.2. Google Cloud 仮想 IP リソースとは?

クライアントアプリケーションは、Google Cloud 環境の仮想マシンに対して、仮想 IP アドレス(以下、VIP と記載)を使用してクラスターを構成するノードに接続することができます。VIP アドレスを使用することにより、フェイルオーバーまたは、グループの移動が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。

図 3.136 Google Cloud 仮想 IP リソースを使用する構成

上記図の Google Cloud 環境上に構築したクラスターには、VIP と外部から通信するためのポート、または DNS 名と外部から通信するためのポートを指定してアクセスします。 クラスターの現用系と待機系は、CLUSTERPRO から Google Cloud のロードバランサ(上記図の Cloud Load Balancing)を制御して切り替えます。制御には上記図の、Health Check を利用します。

活性時に Google Cloud のロードバランサからのヘルスチェックを待ち受けるための制御プロセスを起動し、[ポート番号] で指定したポートをオープンします。

非活性時にはヘルスチェックを待ち受けるための制御プロセスを停止し、[ポート番号] で指定したポートをクローズします。

Google Cloud 仮想 IP リソースでは Google Cloud の内部負荷分散に対応しています。

3.20.3. Google Cloud 仮想 IP リソースに関する注意事項

• Google Cloud の仕様により、外部 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.20.4. 詳細タブ

ポート番号 (1～65535)

Google Cloud のロードバランサが、各ノードのヘルスチェックに使用するポート番号を指定します。ロードバランサのヘルスチェック設定時にポートに指定した値を指定してください。ロードバランサは [TCP 負荷分散] を指定してください。

調整

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

Google Cloud 仮想 IP リソース調整プロパティ

ヘルスチェックのタイムアウト (5～999999999)

Google Cloud のロードバランサからのヘルスチェックを待つタイムアウト時間を指定します。Google Cloud のロードバランサから定期的にヘルスチェックされているかを確認します。

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

3.21.1. Google Cloud DNS リソースの依存関係

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

3.21.2. Google Cloud DNS リソースとは?

Google Cloud DNS リソースは、仮想ホスト名(DNS名)から設定した IP アドレスを得られるように Google Cloud DNS のレコードセットや DNS A レコードの制御を行います。

クライアントはフェイルオーバグループが起動しているノードに仮想ホスト名(DNS 名)でアクセスすることができます。

Google Cloud DNS リソースを利用することで、クライアントは Google Cloud 上でもフェイルオーバやグループの移動による接続先ノードの切り替えを意識する必要がありません。

3.21.3. Google Cloud DNS リソースに関する注意事項

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」-「Google Cloud DNS リソースの設定について」を参照してください。

• 『スタートアップガイド』の「注意制限事項」 - 「OSインストール後、CLUSTERPROインストール前」 - 「Google Cloud DNS リソースについて」を参照してください。

3.21.4. 詳細タブ

ゾーン名 (63バイト以内)

Google Cloud DNS のレコードセットが所属する DNS ゾーン名を入力します。

DNS名 (253バイト以内)

Google Cloud DNS に登録する A レコードの DNS 名を入力します。

IPアドレス (39バイト以内) サーバ個別設定可能

仮想ホスト名(DNS 名)に対応する IP アドレスを入力します(IPv4)。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力します。サーバ個別設定を行う場合、[共通]タブでは任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

TTL (0～2147483647)

DNSサービスのキャッシュの生存期間(TTL=Time To Liveの略)を入力します。

非活性時にレコードセットを削除する

• チェックボックスがオン(既定)

  非活性時にレコードセットを削除します。
• チェックボックスがオフ

  非活性時にレコードセットを削除しません。削除しない場合、残存した仮想ホスト名(DNS 名)にクライアントからアクセスされる可能性があります。

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

3.22.1. Oracle Cloud 仮想 IP リソースの依存関係

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

グループリソースタイプ
EXEC リソース

3.22.2. Oracle Cloud 仮想 IP リソースとは?

クライアントアプリケーションは、Oracle Cloud Infrastructure 環境の仮想マシンに対して、パブリック仮想 IP アドレス(以下、VIP と記載)を使用してクラスターを構成するノードに接続することができます。VIP アドレスを使用することにより、フェイルオーバーまたは、グループの移動が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。

図 3.138 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.139 Oracle Cloud 仮想IPリソースを使用する構成（プライベートロードバランサ）

3.22.3. Oracle Cloud 仮想 IP リソースに関する注意事項

• プライベート ポートとヘルスチェックのポートが同じ場合、Oracle Cloud 仮想 IP リソース、Oracle Cloud 仮想 IP モニタリソースの追加は不要です。

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「Oracle Cloud 仮想 IP リソースの設定について」を参照してください。

3.22.4. 詳細タブ

ポート番号 (1～65535)

Oracle Cloud Infrastructure のロードバランサが、各ノードのヘルスチェックに使用するポート番号を指定します。バックエンド・セットのヘルスチェック設定時にポートに指定した値を指定してください。ヘルスチェックのプロトコルは TCP を指定してください。

調整

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

Oracle Cloud 仮想 IP リソース調整プロパティ

ヘルスチェックのタイムアウト (5～999999999)

Oracle Cloud Infrastructure のロードバランサからのヘルスチェックを待つタイムアウト時間を指定します。Oracle Cloud Infrastructure のロードバランサから定期的にヘルスチェックされているかを確認します。

3.23. Oracle Cloud DNS リソースを理解する

3.23.1. Oracle Cloud DNS リソースの依存関係

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

3.23.2. Oracle Cloud DNS リソースとは?

図 3.140 Oracle Cloud DNSリソースをシングルリージョン環境で使用する構成

図 3.141 Oracle Cloud DNSリソースをマルチリージョン環境で使用する構成

Oracle Cloud DNS リソースは、仮想ホスト名 (DNS 名) から設定した IP アドレスを得られるように Oracle Cloud DNS のレコードセットや DNS A レコードの制御を行います。

クライアントはフェイルオーバグループが起動しているノードに仮想ホスト名 (DNS 名) でアクセスすることができます。

Oracle Cloud DNS リソースを利用することで、クライアントは Oracle Cloud 上でもフェイルオーバやグループの移動による接続先ノードの切り替えを意識する必要がありません。

3.23.3. Oracle Cloud DNS リソースに関する注意事項

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「Oracle Cloud DNS リソースの設定について」を参照してください。

• 『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 - 「OCI 環境における CLI の設定について」を参照してください。

• 『スタートアップガイド』の「注意制限事項」 - 「OSインストール後、CLUSTERPROインストール前」 - 「OCI 環境におけるポリシーの設定について」を参照してください。

3.23.4. 詳細タブ

リージョン (48バイト以内) サーバ個別設定可能

サーバが所属しているリージョンのリージョン識別子を入力します。マルチリージョン環境の場合、各サーバのタブでリージョン識別子を入力します。サーバ個別設定を行う場合、[共通]タブでは任意のサーバが所属するリージョン識別子を記載し、他のサーバは個別設定を行うようにしてください。

ドメイン (FQDN) (254バイト以内)

Oracle Cloud DNS のゾーンに登録するドメイン(FQDN)を入力します。

注釈

マルチリージョン環境の場合、すべてのリージョンで同じドメイン(FQDN)を入力してください。

ゾーンOCID (255バイト以内) サーバ個別設定可能

Oracle Cloud DNS のゾーン名に関連付けられた OCID を入力します。マルチリージョン環境の場合、各サーバのタブでゾーンOCID を入力します。サーバ個別設定を行う場合、[共通]タブでは任意のサーバのゾーンOCID を記載し、他のサーバは個別設定を行うようにしてください。

IPアドレス (39バイト以内) サーバ個別設定可能

仮想ホスト名(DNS 名)に対応する IP アドレスを入力します(IPv4)。各サーバの IP アドレスを使用する場合、各サーバのタブで IP アドレスを入力します。サーバ個別設定を行う場合、[共通]タブでは任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。

TTL (1～604800)

DNSサービスのキャッシュの生存期間(TTL=Time To Liveの略)を入力します。

非活性時にレコードセットを削除する

• チェックボックスがオン(既定)

  非活性時にレコードセットを削除します。
• チェックボックスがオフ

  非活性時にレコードセットを削除しません。削除しない場合、残存した仮想ホスト名(DNS 名)にクライアントからアクセスされる可能性があります。

Proxyを使用する

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

  『本ガイド』の「パラメータの詳細」 - 「サーバプロパティ」 - 「Proxy タブ」に設定したプロキシ情報を使用し Oracle Cloud DNS リソースの活性/非活性の各処理で実行される OCI CLIコマンドを実行します。
• チェックボックスがオフ(既定)

  『本ガイド』の「パラメータの詳細」 - 「サーバプロパティ」 - 「Proxy タブ」に設定したプロキシ情報を使用せずに Oracle Cloud DNS リソースの活性/非活性の各処理で実行される OCI CLIコマンドを実行します。

マルチリージョンでのリソースレコードの操作範囲

• 現用系サーバが所属するリージョンのみ

  フェイルオーバグループが起動しているサーバが所属しているリージョンの Oracle Cloud DNS に対して A レコードの作成、更新、または削除の操作を行います。
• クラスタサーバが所属する全てのリージョン(既定)

  クラスタに登録したすべてのサーバが所属しているリージョンの Oracle Cloud DNS に対して A レコードの作成、更新、または削除の操作を行います。

注釈

[クラスタサーバが所属する全てのリージョン] を設定した場合

• フェイルオーバーグループが起動していないサーバが所属するリージョンのOracle Cloud DNSに対する処理異常が発生しても活性異常としません。

• フェイルオーバーグループが起動していないサーバが所属するリージョンのOracle Cloud DNSに対してOracle Cloud DNSモニタリソースの[インターバル]ごとにAレコードの作成・または更新処理を行います。

調整

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

Oracle Cloud DNS リソース調整プロパティ

パラメータタブ

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

タイムアウト (1～999)

Oracle Cloud DNS リソースの活性/非活性の各処理で実行される OCI CLIコマンドのタイムアウトを設定します。