1. はじめに

1.1. 対象読者と目的

『CLUSTERPRO X スタートアップガイド』は、CLUSTERPRO をはじめてご使用になるユーザの皆様を対象に、CLUSTERPRO の製品概要、クラスタシステム導入のロードマップ、他マニュアルの使用方法についてのガイドラインを記載します。また、最新の動作環境情報や制限事項などについても紹介します。

1.2. 本書の構成

• 「2. クラスタシステムとは?」：クラスタシステムの概要について説明します。

• 「3. CLUSTERPRO について」：クラスタシステムの概要について説明します。

• 「4. CLUSTERPRO の動作環境」：導入前に確認が必要な最新情報について説明します。

• 「5. 最新バージョン情報」：CLUSTERPRO の最新バージョンについての情報を示します。

• 「6. 注意制限事項」：既知の問題と制限事項について説明します。

1.3. CLUSTERPRO マニュアル体系

CLUSTERPRO のマニュアルは、以下の 4 つに分類されます。各ガイドのタイトルと役割を以下に示します。

『CLUSTERPRO X スタートアップガイド』 (Getting Started Guide)

すべてのユーザを対象読者とし、製品概要、動作環境、アップデート情報、既知の問題などについて記載します。

『CLUSTERPRO X インストール&設定ガイド』 (Install and Configuration Guide)

CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアと、クラスタシステム導入後の保守・運用を行うシステム管理者を対象読者とし、CLUSTERPRO を使用したクラスタシステム導入から運用開始前までに必須の事項について説明します。実際にクラスタシステムを導入する際の順番に則して、CLUSTERPRO を使用したクラスタシステムの設計方法、CLUSTERPRO のインストールと設定手順、設定後の確認、運用開始前の評価方法について説明します。

『CLUSTERPRO X リファレンスガイド』 (Reference Guide)

管理者、および CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアを対象とし、CLUSTERPRO の運用手順、各モジュールの機能説明およびトラブルシューティング情報等を記載します。『インストール&設定ガイド』を補完する役割を持ちます。

『CLUSTERPRO X メンテナンスガイド』 (Maintenance Guide)

管理者、および CLUSTERPRO を使用したクラスタシステム導入後の保守・運用を行うシステム管理者を対象読者とし、CLUSTERPRO のメンテナンス関連情報を記載します。

1.4. 本書の表記規則

本書では、注意すべき事項、重要な事項および関連情報を以下のように表記します。

注釈

この表記は、重要ではあるがデータ損失やシステムおよび機器の損傷には関連しない情報を表します。

重要

この表記は、データ損失やシステムおよび機器の損傷を回避するために必要な情報を表します。

参考

この表記は、参照先の情報の場所を表します。

また、本書では以下の表記法を使用します。

表記	使用方法	例
[ ] 角かっこ	コマンド名の前後 画面に表示される語 (ダイアログボックス、メニューなど) の前後	[スタート] をクリックします。 [プロパティ] ダイアログ ボックス
コマンドライン中の [ ] 角かっこ	かっこ内の値の指定が省略可能であることを示します。	clpstat -s [-h host_name]
モノスペースフォント	パス名、コマンド ライン、システムからの出力 (メッセージ、プロンプトなど)、ディレクトリ、ファイル名、関数、パラメータ	C:\Program Files\CLUSTERPRO
太字	ユーザが実際にコマンドプロンプトから入力する値を示します。	以下を入力します。 clpcl -s -a
斜体	ユーザが有効な値に置き換えて入力する項目	clpstat -s [-h host_name]

本書の図では、CLUSTERPROを表すために このアイコンを使用します。

1.5. 最新情報の入手先

最新の製品情報については、以下のWebサイトを参照してください。

https://jpn.nec.com/clusterpro/

2. クラスタシステムとは?

本章では、クラスタシステムの概要について説明します。

本章で説明する項目は以下のとおりです。

• 2.1. クラスタシステムの概要

• 2.2. HA (High Availability) クラスタ

• 2.3. システム構成

• 2.4. 障害検出のメカニズム

• 2.5. クラスタリソースの引き継ぎ

• 2.6. Single Point of Failure の排除

• 2.7. 可用性を支える運用

2.1. クラスタシステムの概要

現在のコンピュータ社会では、サービスを停止させることなく提供し続けることが成功への重要なカギとなります。例えば、1 台のマシンが故障や過負荷によりダウンしただけで、顧客へのサービスが全面的にストップしてしまうことがあります。そうなると、莫大な損害を引き起こすだけではなく、顧客からの信用を失いかねません。

クラスタシステムを導入することにより、万一のときのシステム停止時間 (ダウンタイム) を最小限に食い止めたり、負荷を分散させたりすることで可用性を高めます。

クラスタとは、「群れ」「房」を意味し、その名の通り、「複数のコンピュータを一群 (または複数群) にまとめて、信頼性や処理性能の向上を狙うシステム」です。クラスタシステムには様々な種類があり、以下の 3 つに分類できます。この中で、CLUSTERPRO は HA (High Availability) クラスタに分類されます。

• HA (High Availability) クラスタ

  通常時は一方が現用系として業務を稼動させ、現用系障害発生時に待機系に業務を引き継ぐような形態のクラスタです。高可用性を目的としたクラスタです。共有ディスク型、ミラーディスク型があります。
• 負荷分散クラスタ

  クライアントからの要求を適切な負荷分散ルールに従って、各ノードに割り当てるクラスタです。高スケーラビリティを目的としたクラスタで、一般的にデータの引き継ぎはできません。ロードバランスクラスタ、並列データベースクラスタがあります。
• HPC (High Performance Computing) クラスタ

  非常に計算量が多いクラスタのこと。スーパコンピュータを用いて単一の業務を実行するためのクラスタです。全てのノードの CPU を利用し、単一の業務を実行するグリッドコンピューティングという技術も近年話題に上ることが多くなっています。

2.2. HA (High Availability) クラスタ

一般的にシステムの可用性を向上させるには、そのシステムを構成する部品を冗長化し、Single Point of Failureをなくすことが重要であると考えられます。Single Point of Failureとは、コンピュータの構成要素 (ハードウェアの部品) が 1 つしかないために、その個所で障害が起きると業務が止まってしまう弱点のことを指します。HA クラスタとは、ノードを複数台使用して冗長化することにより、システムの停止時間を最小限に抑え、業務の可用性 (availability)を向上させるクラスタシステムをいいます。

システムの停止が許されない基幹業務システムなどのダウンタイムがビジネスに大きな影響を与えてしまうシステムに、HA クラスタの導入が求められています。

HA クラスタは、共有ディスク型とミラーディスク型に分けることができます。以下にそれぞれのタイプについて説明します。

2.2.1. 共有ディスク型

クラスタシステムでは、サーバ間でデータを引き継がなければなりません。このデータを、SAN接続の FibreChannel ディスクアレイ装置のように複数のサーバからアクセス可能な外付けディスク （共有ディスク） 上に置き、このディスクを介してサーバ間でデータを引き継ぐ形態を共有ディスク型といいます。

図 2.1 HAクラスタ構成図（共有ディスク型）

• 共有ディスクが必要になるため高価

• 大規模データを扱うシステム向き

業務アプリケーションを動かしているサーバ (現用系サーバ) で障害が発生した場合、クラスタシステムが障害を検出し、障害発生時に業務を引き継ぐサーバ (待機系サーバ) で業務アプリケーションを自動起動させ、業務を引き継がせます。これをフェイルオーバといいます。クラスタシステムによって引き継がれる業務は、ディスク、IP アドレス、アプリケーションなどのリソースと呼ばれるもので構成されています。

クラスタ化されていないシステムでは、アプリケーションをほかのサーバで再起動させると、クライアントは異なる IP アドレスに再接続しなければなりません。しかし、多くのクラスタシステムでは、業務単位にサーバに付与している IP ではなく別ネットワークの IP アドレス (仮想IP アドレス)を割り当てています。このため、クライアントは業務を行っているサーバが現用系か待機系かを意識する必要はなく、まるで同じサーバに接続しているように業務を継続できます。

現用系のダウンによりフェイルオーバが発生すると、共有ディスク上のデータは適切な終了処理が行われないまま待機系に引き継がれることになります。このため、待機系では引き継いだデータの論理チェックをする必要があります。これは一般に、クラスタ化されていないシステムでダウン後の再起動時に行われるのと同様の処理になります。例えば、データベースならばロールバックやロールフォワードの処理が必要になります。これらによって、クライアントは未コミットの SQL 文を再実行するだけで、業務を継続することができます。

障害発生後は、障害が検出されたサーバを物理的に切り離して修理後、クラスタシステムに接続すれば待機系として復帰できます。業務の継続性を重視する実際の運用の場合は、グループのフェイルバックを行わなくても良いです。どうしても、元のサーバで業務を行いたい場合は、グループの移動を実行してください。

図 2.2 障害発生から復旧までの流れ

1. 通常運用

2. 障害発生

3. サーバ復旧

4. 業務移動

フェイルオーバ先のサーバのスペックが不十分、双方向スタンバイのため過負荷になる、などの理由で元のサーバで業務を行うのが望ましい場合には、元のノードの復旧作業が完了してから一旦業務を停止し、元のノードで業務を再開します。フェイルオーバしたグループを元のサーバに戻すことをフェイルバックといいます。

図 2.3 HAクラスタの運用形態（片方向スタンバイ） のように、業務が1つであり、待機系では業務が動作しないスタンバイ形態を片方向スタンバイといいます。

図 2.3 HAクラスタの運用形態（片方向スタンバイ）

図 2.4 HAクラスタの運用形態（双方向スタンバイ） のように、業務が2つ以上で、それぞれのサーバが現用系かつ待機系である形態を双方向スタンバイといいます。

Server 1はApplication Aの現用系であると同時にApplication Bの待機系です。

Server 2はApplication Bの現用系であると同時にApplication Aの待機系です。

図 2.4 HAクラスタの運用形態（双方向スタンバイ）

2.2.2. ミラーディスク型

前述の共有ディスク型は大規模なシステムに適していますが、共有ディスクはおおむね高価なためシステム構築のコストが膨らんでしまいます。そこで共有ディスクを使用せず、各サーバのディスクをサーバ間でミラーリングすることにより、同等の機能をより低価格で実現したクラスタシステムをミラーディスク型といいます。

しかし、サーバ間でデータをミラーリングする必要があるため、大量のデータを必要とする大規模システムには向きません。

アプリケーションからの Write 要求が発生すると、データミラーエンジンはローカルディスクにデータを書き込みます。書き込んだデータを、インタコネクトを通して待機系サーバにも Write要求を振り分けます。インタコネクトとは、サーバ間をつなぐケーブルのことで、クラスタシステムではサーバの死活監視のために必要になります。データミラータイプでは死活監視に加えてデータの転送に使用することがあります。待機系のデータミラーエンジンは、受け取ったデータを待機系のローカルディスクに書き込むことで、現用系と待機系間のデータを同期します。

アプリケーションからのRead要求に対しては、単に現用系のディスクから読み出すだけです。

図 2.5 データミラーの仕組み

データミラーの応用例として、スナップショットバックアップの利用があります。データミラータイプのクラスタシステムは 2 カ所に共有のデータを持っているため、待機系のサーバをクラスタから切り離すだけで、スナップショットバックアップとしてデータを保存する運用が可能です。

HA クラスタの仕組みと問題点

次に、クラスタの実装と問題点について説明します。

2.3. システム構成

共有ディスク型クラスタは、ディスクアレイ装置をクラスタサーバ間で共有します。サーバ障害時には待機系サーバが共有ディスク上のデータを使用し業務を引き継ぎます。

ミラーディスク型クラスタは、クラスタサーバ上のデータディスクをネットワーク経由でミラーリングする構成です。サーバ障害時には待機系サーバ上のミラーデータを使用し業務を引き継ぎます。データのミラーリングは I/O 単位で行うため上位アプリケーションから見ると共有ディスクと同様に見えます。

以下の図は、共有ディスク型クラスタの構成例です。

図 2.6 システム構成

フェイルオーバ型クラスタは、運用形態により、次のように分類できます。

片方向スタンバイクラスタ

一方のサーバを運用系として業務を稼動させ、他方のサーバを待機系として業務を稼動させない運用形態です。最もシンプルな運用形態でフェイルオーバ後の性能劣化のない可用性の高いシステムを構築できます。

図 2.7 片方向スタンバイクラスタ(1)

図 2.8 片方向スタンバイクラスタ(2)

同一アプリケーション双方向スタンバイクラスタ

複数のサーバで同じ業務アプリケーションを稼動させ相互に待機する運用形態です。各業務アプリケーションは独立して動作します。フェイルオーバ時には 1 台のサーバ上で同一業務アプリケーションが複数動作することになりますので、このような運用が可能なアプリケーションでなければなりません。ある業務データを複数に分割できる場合に、アクセスしようとしているデータによってクライアントからの接続先サーバを変更することで、データ分割単位での負荷分散システムを構築できます。

図 2.9 同一アプリケーション双方向スタンバイクラスタ(1)

図 2.10 同一アプリケーション双方向スタンバイクラスタ(2)

異種アプリケーション双方向スタンバイクラスタ

複数の種類の業務アプリケーションをそれぞれ異なるサーバで稼動させ相互に待機する運用形態です。 フェイルオーバ時には 1 台のサーバ上に複数の業務アプリケーションが動作することになりますので、これらのアプリケーションは共存可能でなければなりません。 業務単位での負荷分散システムを構築できます。

Application AとApplication Bは異なるアプリケーションです。

図 2.11 異種アプリケーション双方向スタンバイクラスタ(1)

図 2.12 異種アプリケーション双方向スタンバイクラスタ(2)

N + N 構成

ここまでの構成を応用し、より多くのノードを使用した構成に拡張することも可能です。下図は、3 種の業務を 3 台のサーバで実行し、いざ問題が発生した時には 1 台の待機系にその業務を引き継ぐという構成です。片方向スタンバイでは、正常時には待機系サーバが何も業務を行わないため、無駄なリソースの比率が 1/2 になっていたのですが、この構成の場合無駄なリソースの比率が 1/4 となり、コストの削減ができます。また、1 台までの異常発生であればパフォーマンスの低下もありません。

図 2.13 N + N 構成 (1)

図 2.14 N + N 構成 (2)

2.4. 障害検出のメカニズム

クラスタソフトウェアは、業務継続に問題をきたす障害を検出すると業務の引き継ぎ (フェイルオーバ) を実行します。フェイルオーバ処理の具体的な内容に入る前に、簡単にクラスタソフトウェアがどのように障害を検出するか見ておきましょう。

CLUSTERPRO はサーバ監視のために、定期的にサーバ同士で生存確認を行います。この生存確認をハートビートと呼びます。

ハートビートとサーバの障害検出

クラスタシステムにおいて、検出すべき最も基本的な障害はクラスタを構成するサーバのダウンです。サーバの障害には、電源異常やメモリエラーなどのハードウェア障害や OS のパニックなどが含まれます。このような障害を検出するために、サーバの死活監視としてハートビートが使用されます。

ハートビートは、ping の応答を確認するような死活監視だけでもよいのですが、クラスタソフトウェアによっては、自サーバの状態情報などを相乗りさせて送るものもあります。クラスタソフトウェアはハートビートの送受信を行い、ハートビートの応答がない場合はそのサーバの障害とみなしてフェイルオーバ処理を開始します。ただし、サーバの高負荷などによりハートビートの送受信が遅延することも考慮し、サーバ障害と判断するまである程度の猶予時間が必要です。このため、実際に障害が発生した時間とクラスタソフトウェアが障害を検知する時間とにはタイムラグが生じます。

リソースの障害検出

業務の停止要因はクラスタを構成するサーバのダウンだけではありません。例えば、業務アプリケーションが使用するディスク装置や NIC の障害、もしくは業務アプリケーションそのものの障害などによっても業務は停止してしまいます。可用性を向上するためには、このようなリソースの障害も検出してフェイルオーバを実行しなければなりません。

リソース異常を検出する手法として、監視対象リソースが物理的なデバイスの場合は、実際にアクセスしてみるという方法が取られます。アプリケーションの監視では、アプリケーションプロセスそのものの死活監視のほか、業務に影響のない範囲でサービスポートを試してみるような手段も考えられます。

2.4.1. 共有ディスクの排他制御

共有ディスク型のフェイルオーバクラスタでは、複数のサーバでディスク装置を物理的に共有します。一般的に、ファイルシステムはサーバ内にデータのキャッシュを保持することで、ディスク装置の物理的な I/O 性能の限界を超えるファイル I/O 性能を引き出しています。

あるファイルシステムを複数のサーバから同時にマウントしてアクセスするとどうなるでしょうか?

通常のファイルシステムは、自分以外のサーバがディスク上のデータを更新するとは考えていないので、キャッシュとディスク上のデータとに矛盾を抱えることとなり、最終的にはデータを破壊します。フェイルオーバクラスタシステムでは、次に説明するネットワークパーティション状態などによる複数サーバからのファイルシステムの同時マウントを防ぐために、ディスク装置の排他制御を行っています。

2.4.2. ネットワークパーティション症状 (Split-brain-syndrome)

サーバ間をつなぐすべてのインタコネクトが切断されると、ハートビートによる死活監視だけではサーバのダウンと区別できません。この状態でサーバダウンとみなし、フェイルオーバ処理を実行し、複数のサーバでファイルシステムを同時にマウントすると、共有ディスク上のデータが破壊されてしまいます。

図 2.15 ネットワークパーティション症状

このような問題を「ネットワークパーティション症状」またはスプリットブレインシンドローム(Split-brain-syndrome) と呼びます。この問題を解決するため、フェイルオーバクラスタでは、すべてのインタコネクトが切断されたときに、確実に共有ディスク装置の排他制御を実現するためのさまざまな対応策が考えられています。

2.5. クラスタリソースの引き継ぎ

クラスタが管理するリソースにはディスク、IP アドレス、アプリケーションなどがあります。これらのクラスタリソースを引き継ぐための、フェイルオーバクラスタシステムの機能について説明します。

2.5.1. データの引き継ぎ

共有ディスク型クラスタでは、サーバ間で引き継ぐデータは共有ディスク装置上のパーティションに格納します。すなわち、データを引き継ぐとは、アプリケーションが使用するファイルが格納されているファイルシステムを健全なサーバ上でマウントしなおすことにほかなりません。共有ディスク装置は引き継ぐ先のサーバと物理的に接続されているので、クラスタソフトウェアが行うべきことはファイルシステムのマウントだけです。

図 2.16 データの引き継ぎ

単純な話のようですが、クラスタシステムを設計・構築するうえで注意しなければならない点があります。

1 つは、ファイルシステムやデータベースの復旧時間の問題です。引き継ごうとしているファイルは、障害が発生する直前までほかのサーバで使用され、もしかしたらまさに更新中であったかもしれません。このため、ファイルシステムによっては引き継ぐ際に整合性チェックが必要となりますし、データベースであればロールバック等の処理が必要となります。これは電源障害などでダウンした単体サーバを再起動した場合と同様です。このような復旧処理に長時間を要する場合、それがそのままフェイルオーバ時間 (業務の引き継ぎ時間) に追加されてしまい、システムの可用性を低下させる要因になります。

もう 1 つは、書き込み保証の問題です。アプリケーションが共有ディスクにデータを書き出す際に、通常はファイルシステムを介しての書き出しになりますが、アプリケーションが書き込みを完了していても、ファイルシステムがディスクキャッシュ上に保持しているだけで、共有ディスクへの書き込みを行っていなかった場合、この状態で現用系のサーバがダウンすると、ディスクキャッシュ上のデータは待機系に引き継がれないことになります。このため、障害発生時に確実に待機系に引き継ぐ必要のある大切なデータは、同期書き込みなどにより確実にディスクに書き込む必要があります。これは単体サーバがダウンした際にデータが揮発しないようにするのと同じです。つまり、待機系に引き継がれるのは共有ディスクに記録されたデータのみであり、ディスクキャッシュのようなメモリ上のデータは引き継がれないということを考慮してクラスタシステムを設計する必要があります。

2.5.2. IP アドレスの引き継ぎ

次にクラスタソフトウェアが行うことは、IP アドレスの引き継ぎです。フェイルオーバした際に、IP アドレスを引き継ぐことで、業務がどのサーバで動作しているのか、気にすることなく作業を行うことができます。クラスタソフトウェアは、そのための IP アドレスの引き継ぎを行います。

2.5.3. アプリケーションの引き継ぎ

クラスタソフトウェアが業務引き継ぎの最後に行う仕事は、アプリケーションの引き継ぎです。フォールトトレラントコンピュータ (FTC) とは異なり、一般的なフェイルオーバクラスタでは、アプリケーション実行中のメモリ内容を含むプロセス状態などを引き継ぎません。すなわち、障害が発生したサーバで実行していたアプリケーションを健全なサーバで再実行することでアプリケーションの引き継ぎを行います。

例えば、DB のインスタンスをフェイルオーバする場合、障害発生直前の状態で再開されるのではなく、一旦ダウンした状態から再起動した場合と同様にトランザクションのロールバック等が行われ、クライアントからも再接続が必要になります。このデータベース復旧に必要な時間は、DBMS のチェックポイントインターバルの設定などによってある程度の制御ができますが、一般的には数分程度必要となるようです。

多くのアプリケーションは再実行するだけで業務を再開できますが、障害発生後の業務復旧手順が必要なアプリケーションもあります。このようなアプリケーションのためにクラスタソフトウェアは業務復旧手順を記述できるよう、アプリケーションの起動の代わりにスクリプトを起動できるようになっています。スクリプト内には、スクリプトの実行要因や実行サーバなどの情報をもとに、必要に応じて更新途中であったファイルのクリーンアップなどの復旧手順を記述します。

2.5.4. フェイルオーバについての総括

ここまでの内容から、次のようなクラスタソフトの動作が分かると思います。

1. 障害検出 (ハートビート/リソース監視)

2. フェンシング (ネットワークパーティション状態の解決(NP解決) および 障害発生サーバの切断)

3. データの引き継ぎ

4. IP アドレスの引き継ぎ

5. アプリケーションの引き継ぎ

図 2.17 フェイルオーバタイムチャート

クラスタソフトウェアは、フェイルオーバ実現のため、これらの様々な処置を 1 つ 1 つ確実に、短時間で実行することで、高可用性 （High Availability） を実現しているのです。

2.6. Single Point of Failure の排除

高可用性システムを構築するうえで、求められるもしくは目標とする可用性のレベルを把握することは重要です。これはすなわち、システムの稼働を阻害し得るさまざまな障害に対して、冗長構成をとることで稼働を継続したり、短い時間で稼働状態に復旧したりするなどの施策を費用対効果の面で検討し、システムを設計するということです。

Single Point of Failure (SPOF) とは、システム停止につながる部位を指す言葉であると前述しました。クラスタシステムではサーバの多重化を実現し、システムの SPOF を排除することができますが、共有ディスクなど、サーバ間で共有する部分については SPOF となり得ます。この共有部分を多重化もしくは排除するようシステム設計することが、高可用性システム構築の重要なポイントとなります。

クラスタシステムは可用性を向上させますが、フェイルオーバには数分程度のシステム切り替え時間が必要となります。従って、フェイルオーバ時間は可用性の低下要因の 1 つともいえます。このため、高可用性システムでは、まず単体サーバの可用性を高める ECC メモリや冗長電源などの技術が本来重要なのですが、ここでは単体サーバの可用性向上技術には触れず、クラスタシステムにおいて SPOF となりがちな下記の 3 つについて掘り下げて、どのような対策があるか見ていきたいと思います。

• 共有ディスク

• 共有ディスクへのアクセスパス

• LAN

2.6.1. 共有ディスク

通常、共有ディスクはディスクアレイにより RAID を組むので、ディスクのベアドライブはSPOF となりません。しかし、RAID コントローラを内蔵するため、コントローラが問題となります。多くのクラスタシステムで採用されている共有ディスクではコントローラの二重化が可能になっています。

二重化された RAID コントローラの利点を生かすためには、通常は共有ディスクへのアクセスパスの二重化を行う必要があります。ただし、二重化された複数のコントローラから同時に同一の論理ディスクユニット (LUN) へアクセスできるような共有ディスクの場合、それぞれのコントローラにサーバを 1 台ずつ接続すればコントローラ異常発生時にノード間フェイルオーバを発生させることで高可用性を実現できます。

図 2.18 RAIDコントローラとアクセスパスがSPOFとなっている例

図 2.19 RAIDコントローラとアクセスパスが二重化されている例

※HBA: Host Bus Adapter の略で、共有ディスク側ではなく、サーバ本体側のアダプタのことです。

一方、共有ディスクを使用しないデータミラー型のフェイルオーバクラスタでは、すべてのデータをほかのサーバのディスクにミラーリングするため、SPOF が存在しない理想的なシステム構成を実現できます。ただし、次のような点について考慮する必要があります。

• ネットワークを介してデータをミラーリングすることによるディスク I/O 性能 (特に write 性能) の低下

• サーバ障害後の復旧における、ミラー再同期中のシステム性能 (ミラーコピーはバックグラウンドで実行される) の低下

• ミラー再同期時間 (ミラー再同期が完了するまでフェイルオーバできない)

すなわち、データの参照が多く、データ容量が多くないシステムにおいては、データミラー型のフェイルオーバクラスタを採用するというのも可用性を向上させるのに有効といえます。

2.6.2. 共有ディスクへのアクセスパス

共有ディスク型クラスタの一般的な構成では、共有ディスクへのアクセスパスはクラスタを構成する各サーバで共有されます。SCSI を例に取れば、1 本の SCSI バス上に 2 台のサーバと共有ディスクを接続するということです。このため、共有ディスクへのアクセスパスの異常はシステム全体の停止要因となり得ます。

対策としては、共有ディスクへのアクセスパスを複数用意することで冗長構成とし、アプリケーションには共有ディスクへのアクセスパスが 1 本であるかのように見せることが考えられます。これを実現するデバイスドライバをパスフェイルオーバドライバなどと呼びます。

図 2.20 パスフェイルオーバドライバ

2.6.3. LAN

クラスタシステムに限らず、ネットワーク上で何らかのサービスを実行するシステムでは、LANの障害はシステムの稼働を阻害する大きな要因です。クラスタシステムでは適切な設定を行えば NIC 障害時にノード間でフェイルオーバを発生させて可用性を高めることは可能ですが、クラスタシステムの外側のネットワーク機器が故障した場合はやはりシステムの稼働を阻害します。

図 2.21 LANにおける障害の例（NIC）

この図の場合、Server上のNICが故障してもフェイルオーバすることで、Server上のサービスに対するPCからのアクセスを継続できます。

図 2.22 LANにおける障害の例（ルータ）

この図の場合、Routerが故障するとServer上のサービスに対するPCからのアクセスを継続できません（RouterがSPOFになっている）。

このようなケースでは、LAN を冗長化することでシステムの可用性を高めます。クラスタシステムにおいても、LAN の可用性向上には単体サーバでの技術がそのまま利用可能です。例えば、予備のネットワーク機器の電源を入れずに準備しておき、故障した場合に手動で入れ替えるといった原始的な手法や、高機能のネットワーク機器を冗長配置してネットワーク経路を多重化することで自動的に経路を切り替える方法が考えられます。また、インテル社の ANSドライバのように NIC の冗長構成をサポートするドライバを利用するということも考えられます。

ロードバランス装置 (Load Balance Appliance) やファイアウォールサーバ (Firewall Appliance) も SPOF となりやすいネットワーク機器です。これらもまた、標準もしくはオプションソフトウェアを利用することで、フェイルオーバ構成を組めるようになっているのが普通です。同時にこれらの機器は、システム全体の非常に重要な位置に存在するケースが多いため、冗長構成をとることはほぼ必須と考えるべきです。

2.7. 可用性を支える運用

2.7.1. 運用前評価

システムトラブルの発生要因の多くは、設定ミスや運用保守に起因するものであるともいわれています。このことから考えても、高可用性システムを実現するうえで運用前の評価と障害復旧マニュアルの整備はシステムの安定稼働にとって重要です。評価の観点としては、実運用に合わせて、次のようなことを実践することが可用性向上のポイントとなります。

• 障害発生個所を洗い出し、対策を検討し、擬似障害評価を行い実証する

• クラスタの「一連の状態遷移」を想定した評価を行い、縮退運転時のパフォーマンスなどの検証を行う

• これらの評価をもとに、システム運用、障害復旧マニュアルを整備する

クラスタシステムの設計をシンプルにすることは、上記のような検証やマニュアルが単純化でき、システムの可用性向上のポイントとなることが分かると思います。

2.7.2. 障害の監視

上記のような努力にもかかわらず障害は発生するものです。ハードウェアには経年劣化があり、ソフトウェアにはメモリリークなどの理由や設計当初のキャパシティプラニングを超えた運用をしてしまうことにより、長期間運用を続けると障害が発生することがあります。このため、ハードウェア、ソフトウェアの可用性向上と同時に、さらに重要となるのは障害を監視して障害発生時に適切に対処することです。万が一サーバに障害が発生した場合を例に取ると、クラスタシステムを組むことで数分の切り替え時間でシステムの稼働を継続できますが、そのまま放置しておけばシステムは冗長性を失い次の障害発生時にはクラスタシステムは何の意味もなさなくなってしまいます。

このため、障害が発生した場合、すぐさまシステム管理者は次の障害発生に備え、新たに発生した SPOF を取り除くなどの対処をしなければなりません。このようなシステム管理業務をサポートするうえで、リモートメンテナンスや障害の通報といった機能が重要になります。

以上、クラスタシステムを利用して高可用性を実現するうえで必要とされる周辺技術やそのほかのポイントについて説明しました。注意すべき点を簡単にまとめます。

• Single Point of Failure を排除または把握する

• 障害に強いシンプルな設計を行い、運用前評価に基づき運用・障害復旧手順のマニュアルを整備する

• 発生した障害を早期に検出し適切に対処する

3. CLUSTERPRO について

本章では、CLUSTERPRO を構成するコンポーネントの説明と、クラスタシステムの設計から運用手順までの流れについて説明します。

本章で説明する項目は以下のとおりです。

• 3.1. CLUSTERPRO とは?

• 3.2. CLUSTERPRO の製品構成

• 3.3. CLUSTERPRO のソフトウェア構成

• 3.4. フェンシング機能

• 3.5. フェイルオーバのしくみ

• 3.6. リソースとは?

• 3.7. CLUSTERPRO を始めよう!

3.1. CLUSTERPRO とは?

クラスタについて理解したところで、CLUSTERPRO の紹介を始めましょう。CLUSTERPRO とは、HA クラスタシステムを実現するためのソフトウェアです。

3.2. CLUSTERPRO の製品構成

CLUSTERPRO は大きく分けると 2 つのモジュールから構成されています。

• CLUSTERPRO Server

  CLUSTERPRO の本体です。クラスタシステムを構成する各サーバマシンにインストールします。CLUSTERPRO Server には、CLUSTERPRO の高可用性機能の全てが包含されています。また、Cluster WebUI のサーバ側機能も含まれます。
• Cluster WebUI

  CLUSTERPRO の構成情報の作成や運用管理を行うための管理ツールです。ユーザインターフェイスとして Web ブラウザを利用します。実体は CLUSTERPRO Server に組み込まれていますが、操作は管理端末上の Web ブラウザで行うため、CLUSTERPRO Server とは区別されています。

3.3. CLUSTERPRO のソフトウェア構成

CLUSTERPRO のソフトウェア構成は次の図のようになります。クラスタを構成するサーバ上には「CLUSTERPRO Server (CLUSTERPRO 本体)」をインストールします。Cluster WebUI の本体機能は CLUSTERPRO Server に含まれるため、別途インストールする必要がありません。Cluster WebUI は管理 PC 上の Web ブラウザから利用するほか、クラスタを構成する各サーバ上の Web ブラウザでも利用できます。

1. CLUSTERPRO Server (Main module)

2. Cluster WebUI

図 3.1 CLUSTERPRO のソフトウェア構成

3.3.1. CLUSTERPRO の障害監視のしくみ

CLUSTERPRO では、サーバ監視、業務監視、内部監視の 3 つの監視を行うことで、迅速かつ確実な障害検出を実現しています。以下にその監視の詳細を示します。

3.3.2. サーバ監視とは

サーバ監視とはフェイルオーバ型クラスタシステムの最も基本的な監視機能で、クラスタを構成するサーバが停止していないかを監視する機能です。

サーバ監視（ハートビート）は以下の通信パスを使用して行います。

• プライマリインタコネクト

  クラスタサーバ間通信専用のLAN です。ハートビートを行うと同時にサーバ間の情報交換に使用します。
  

  図 3.2 LANハートビート／カーネルモードLANハートビート（プライマリインタコネクト）

• セカンダリインタコネクト

  クライアントとの通信に用いるパスとして使用します。サーバ間の情報交換や、インタコネクトのバックアップ用としても使用します。
  

  図 3.3 LANハートビート／カーネルモードLANハートビート（セカンダリインタコネクト）

• Witness

  フェイルオーバ型クラスタを構成する各サーバとWitness サーバサービスが動作している外部サーバ (Witness サーバ) 間で通信を行い、Witness サーバが保持する他サーバとの通信情報から生存を確認します。
  

  図 3.4 Witnessハートビート

3.3.3. 業務監視とは

業務監視とは、業務アプリケーションそのものや業務が実行できない状態に陥る障害要因を監視する機能です。

• 監視オプションによるアプリケーション/プロトコルのストール/結果異常監視

  別途ライセンスの購入が必要となりますが、データベースアプリケーション (Oracle, DB2等)、プロトコル (FTP, HTTP等)、アプリケーションサーバ (WebSphere, WebLogic等)のストール/結果異常監視を行うことができます。詳細は、『リファレンスガイド』の「モニタリソースの詳細」を参照してください。
• アプリケーションの死活監視

  アプリケーションを起動用のリソース (アプリケーションリソース、サービスリソースと呼びます) により起動し、監視用のリソース (アプリケーション監視リソース、サービス監視リソースと呼びます) により定期的にプロセスの生存を確認することで実現します。業務停止要因が業務アプリケーションの異常終了である場合に有効です。

注釈

• CLUSTERPRO が直接起動したアプリケーションが監視対象の常駐プロセスを起動し終了してしまうようなアプリケーションでは、常駐プロセスの異常を検出することはできません。

注釈

• アプリケーションの内部状態の異常 (アプリケーションのストールや結果異常) を検出することはできません。

• リソースの監視

  CLUSTERPRO のモニタリソースによりクラスタリソース (ディスクパーティション、IP アドレスなど) やパブリック LAN の状態を監視することで実現します。業務停止要因が業務に必要なリソースの異常である場合に有効です。

3.3.4. 内部監視とは

内部監視とは、CLUSTERPRO 内部のモジュール間相互監視です。CLUSTERPRO の各監視機能が正常に動作していることを監視します。

次のような監視を CLUSTERPRO 内部で行っています。

• CLUSTERPRO プロセスの死活監視

3.3.5. 監視できる障害と監視できない障害

CLUSTERPRO には、監視できる障害とできない障害があります。クラスタシステム構築時、運用時に、どのような障害が検出可能なのか、または検出できないのかを把握しておくことが重要です。

3.3.6. サーバ監視で検出できる障害とできない障害

監視条件: 障害サーバからのハートビートが途絶

• 監視できる障害の例

  • ハードウェア障害 (OS が継続動作できないもの)

  • STOP エラー

• 監視できない障害の例

  • OS の部分的な機能障害 (マウス/キーボードのみが動作しない等)

3.3.7. 業務監視で検出できる障害とできない障害

監視条件: 障害アプリケーションの消滅、 継続的なリソース異常、 あるネットワーク装置への通信路切断

• 監視できる障害の例

  • アプリケーションの異常終了

  • 共有ディスクへのアクセス障害 (HBA の故障など)

  • パブリック LAN NIC の故障

• 監視できない障害の例

  • アプリケーションのストール/結果異常

    アプリケーションのストール/結果異常を CLUSTERPRO で直接監視することはできません 1 が、アプリケーションを監視し異常検出時に自分自身を終了するプログラムを作成し、そのプログラムをアプリケーションリソースで起動、アプリケーション監視リソースで監視することで、フェイルオーバを発生させることは可能です。

1

監視オプションで取り扱う、データベースアプリケーション (Oracle,DB2等)、プロトコル (FTP,HTTP等) 、アプリケーションサーバ (WebSphere, WebLogic等) については、ストール/結果異常監視を行うことができます。

3.4. フェンシング機能

CLUSTERPROはフェンシングの仕組みとして「ネットワークパーティション解決」と「強制停止」を備えています。

3.4.1. ネットワークパーティション解決

CLUSTERPRO は、あるサーバからのハートビート途絶を検出すると、その原因が本当にサーバ障害なのか、あるいはネットワークパーティション状態によるものなのかの判別を行います。サーバ障害と判断した場合は、フェイルオーバ (健全なサーバ上で各種リソースを活性化し業務アプリケーションを起動) を実行しますが、ネットワークパーティション状態と判断した場合には、業務継続よりもデータ保護を優先させるため、緊急シャットダウンなどの処理を実施します。

ネットワークパーティション解決方式には下記の方法があります。

• PING 方式

• HTTP 方式

• 共有ディスク方式

• PING + 共有ディスク方式

• 多数決方式

• ネットワークパーティション解決しない

参考

ネットワークパーティション解決方法の設定についての詳細は、『リファレンスガイド』の「ネットワークパーティション解決リソースの詳細」を参照してください。

3.4.2. 強制停止

サーバ障害を検知したとき、健全なサーバから障害を起こしたサーバに対して停止要求を発行することができます。障害のあるサーバを停止状態へ移行させることにより、業務アプリケーションが複数のサーバで同時に起動する可能性を排除します。強制停止の処理はフェイルオーバが開始される前に実行されます。

参考

強制停止の設定についての詳細は、『リファレンスガイド』の「強制停止リソースの詳細」を参照してください。

3.5. フェイルオーバのしくみ

CLUSTERPRO は他サーバからのハートビートの途絶を検出すると、フェイルオーバ開始前にサーバの障害かネットワークパーティション状態かを判別します。この後、健全なサーバ上で各種リソースを活性化し業務アプリケーションを起動することでフェイルオーバを実行します。

このとき、同時に移動するリソースの集まりをフェイルオーバグループと呼びます。フェイルオーバグループは利用者から見た場合、仮想的なコンピュータとみなすことができます。

注釈

クラスタシステムでは、アプリケーションを健全なノードで起動しなおすことでフェイルオーバを実行します。このため、アプリケーションのメモリ上に格納されている実行状態をフェイルオーバすることはできません。

障害発生からフェイルオーバ完了までの時間は数分間必要です。以下にタイムチャートを示します。

図 3.5 フェイルオーバのタイムチャート

1. ハートビートタイムアウト

• 業務を実行しているサーバの障害発生後、待機系がその障害を検出するまでの時間です。

• 業務の負荷等による遅延も考慮して、クラスタプロパティの設定値を調整します。

  (既定値では 30 秒です。)

2. フェンシング

• ネットワークパーティション解決と強制停止を実施するための時間です。

• ネットワークパーティション解決では、相手サーバからのハートビートの途絶 (ハートビートタイムアウト) がネットワークパーティション状態によるものか、実際に相手サーバが障害を起こしたのかを確認します。

  通常はほぼ瞬時に確認が完了します。
• 強制停止では、障害を起こしたと判断された相手サーバに対して停止要求を発行します。

  必要時間はクラスタの動作環境 (物理環境・仮想環境・クラウド等) によって変化します。

3. 各種リソース活性化

• 業務で必要なリソースを活性化するための時間です。

• ファイルシステム復旧、ディスク内のデータ引継ぎ、IPアドレスの引継ぎ等を行います。

• 一般的な設定では数秒で活性化しますが、フェイルオーバグループに登録されているリソースの種類や数によって必要時間は変化します。

  (詳しくは、『インストール&設定ガイド』を参照してください。)

4. アプリケーション復旧処理・再起動

• 業務で使用するアプリケーションの起動に要する時間です。データベースのロールバック/ロールフォワードなどのデータ復旧処理の時間も含まれます。

• ロールバック/ロールフォワード時間などはチェックポイントインターバルの調整である程度予測可能です。詳しくは、各ソフトウェア製品のドキュメントを参照してください。

3.5.1. CLUSTERPRO で構築する共有ディスク型クラスタのハードウェア構成

共有ディスク型クラスタの CLUSTERPRO の HW 構成は下図のようになります。

サーバ間の通信用に

• NIC を 2 枚 (1 枚は外部との通信と流用、1 枚は CLUSTERPRO 専用)

• 共有ディスクの特定領域

を利用する構成が一般的です。

共有ディスクとの接続インターフェイスは SCSI や Fibre Channel、iSCSI ですが、最近はFibre Channel か iSCSI による接続が一般的です。

図 3.6 クラスタ構成例（共有ディスク型）

FIP1	10.0.0.11 (Cluster WebUIクライアントからのアクセス先)
FIP2	10.0.0.12 (業務クライアントからのアクセス先)
NIC1-1	192.168.0.1
NIC1-2	10.0.0.1
NIC2-1	192.168.0.2
NIC2-2	10.0.0.2

• 共有ディスク:

  ディスクハートビート用パーティション ドライブ文字	E
  ディスクリソース ドライブ文字	F
  ファイルシステム	NTFS

上記は、共有ディスク使用時のクラスタ環境のサンプルです。

3.5.2. CLUSTERPROで構築するミラーディスク型クラスタのハードウェア構成

各サーバのディスク上のパーティションをミラーリングすることによって、共有ディスク装置の代替とする構成です。共有ディスク型に比べて小規模で低予算のシステムに向いています。

注釈

ミラーディスクを使用するには、Replicator オプションまたは Replicator DR オプションをご購入いただく必要があります。

ミラーディスクデータコピー用のネットワークが必要となりますが、通常、インタコネクト(CLUSTERPRO の内部通信用 NIC) で兼用します。

CLUSTERPRO で構築するデータミラー型クラスタのハードウェア構成は、下図のような構成になります。

• ミラーディスク使用時のクラスタ環境のサンプル (OS がインストールされているディスクにクラスタパーティション、データパーティションを確保する場合)

  以下の構成では、OSがインストールされているディスクの空きパーティションを、クラスタパーティション、データパーティションとして使用しています。

  

  図 3.7 クラスタ構成例(1)（ミラーディスク型）

  FIP1	10.0.0.11 (Cluster WebUIクライアントからのアクセス先)
  FIP2	10.0.0.12 (業務クライアントからのアクセス先)
  NIC1-1	192.168.0.1
  NIC1-2	10.0.0.1
  NIC2-1	192.168.0.2
  NIC2-2	10.0.0.2

  クラスタパーティション ドライブ文字	E
  ファイルシステム	RAW
  データパーティション ドライブ文字	F
  ファイルシステム	NTFS

• ミラーディスク使用時のクラスタ環境のサンプル (クラスタパーティション、データパーティション用のディスクを用意する場合)

  以下の構成では、クラスタパーティション、データパーティション用にディスクを用意し、接続しています。

  

  図 3.8 クラスタ構成例(2)（ミラーディスク型）

  FIP1	10.0.0.11 (Cluster WebUIクライアントからのアクセス先)
  FIP2	10.0.0.12 (業務クライアントからのアクセス先)
  NIC1-1	192.168.0.1
  NIC1-2	10.0.0.1
  NIC2-1	192.168.0.2
  NIC2-2	10.0.0.2

  クラスタパーティション ドライブ文字	E
  ファイルシステム	RAW
  データパーティション ドライブ文字	F
  ファイルシステム	NTFS

3.5.3. CLUSTERPRO で構築するハイブリッドディスク型クラスタのハードウェア構成

共有ディスク型とミラーディスク型を組み合わせ、共有ディスク上のパーティションをミラーリングすることによって、共有ディスク装置の障害に対しても業務継続を可能とする構成です。リモートサイト間でミラーリングすることにより、災害対策としても利用できます。

注釈

ハイブリッドディスクを使用するには、Replicator DR オプションをご購入いただく必要があります。

ミラーディスクの場合と同様、データコピー用のネットワークが必要となりますが、通常、インタコネクト (CLUSTERPRO の内部通信用 NIC) で兼用します。

CLUSTERPRO で構築するハイブリッドディスク型クラスタのハードウェア構成は、下図のようになります。

• ハイブリッドディスク使用時のクラスタ環境のサンプル (2 台のサーバで共有ディスクを使用し、3 台目のサーバの通常のディスクへミラーリングする場合)

  

  図 3.9 クラスタ構成例（ハイブリッドディスク型）

  FIP1	10.0.0.11 (Cluster WebUIクライアントからのアクセス先)
  FIP2	10.0.0.12 (業務クライアントからのアクセス先)
  NIC1-1	192.168.0.1
  NIC1-2	10.0.0.1
  NIC2-1	192.168.0.2
  NIC2-2	10.0.0.2
  NIC3-1	192.168.0.3
  NIC3-2	10.0.0.3

• 共有ディスク

  ハートビート用パーティション ドライブ文字	E
  ファイルシステム	RAW
  クラスタパーティション ドライブ文字	F
  ファイルシステム	RAW
  データパーティション ドライブ文字	G
  ファイルシステム	NTFS

上記は、同じネットワーク内で共有ディスクをミラーリングする場合のクラスタ環境のサンプルです。ハイブリッドディスクでは同じ共有ディスク装置に接続されたサーバグループの間でミラーリングを行いますが、上記の例では共有ディスクを server3 のローカルディスクにミラーリングするため、待機系サーバグループ svg2 はメンバサーバが server3 のみとなります。

図 3.10 クラスタ構成例（ハイブリッドディスク型, 遠隔クラスタ）

VIP1	10.0.0.11 (Cluster WebUIクライアントからのアクセス先)
VIP2	10.0.0.12 (業務クライアントからのアクセス先)
NIC1-1	192.168.0.1
NIC1-2	10.0.0.1
NIC2-1	192.168.0.2
NIC2-2	10.0.0.2
NIC3-1	192.168.0.3
NIC3-2	10.0.0.3

• 共有ディスク

  ハートビート用パーティション ドライブ文字	E
  ファイルシステム	RAW
  クラスタパーティション ドライブ文字	F
  ファイルシステム	RAW
  データパーティション ドライブ文字	G
  ファイルシステム	NTFS

上記は、リモートサイト間でミラーリングを行う場合のクラスタ環境のサンプルです。この例ではPublic LAN のネットワークセグメントがサーバグループ間で異なるため、フローティング IP アドレスではなく仮想 IP アドレスを使用しています。仮想 IP アドレスを使用する場合、途中のルータは全てホストルートを伝播するように設定されている必要があります。また、ミラーのモードを非同期にし、データ圧縮機能を有効にすることをお勧めします。

3.5.4. クラスタオブジェクトとは?

CLUSTERPRO では各種リソースを下のような構成で管理しています。

• クラスタオブジェクト

  一群のサーバをまとめたクラスタシステムです。
• サーバオブジェクト

  実体サーバを示すオブジェクトで、クラスタオブジェクトに属します。
• サーバグループオブジェクト

  サーバを束ねるオブジェクトで、クラスタオブジェクトに属します。ハイブリッドディスクリソースを使用する場合に必要です。
• ハートビートリソースオブジェクト

  実体サーバの NW 部分を示すオブジェクトで、サーバオブジェクトに属します。
• ネットワークパーティション解決リソースオブジェクト

  ネットワークパーティション解決機構を示すオブジェクトで、サーバオブジェクトに属します。
• グループオブジェクト

  仮想のサーバを示すオブジェクトで、クラスタオブジェクトに属します。
• グループリソースオブジェクト

  仮想サーバの持つ資源 (NW、ディスク) を示すオブジェクトでグループオブジェ

  クトに属します。
• モニタリソースオブジェクト

  監視機構を示すオブジェクトで、クラスタオブジェクトに属します。

3.6. リソースとは?

CLUSTERPRO では、監視する側とされる側の対象をすべてリソースと呼び、監視する側とされる側のリソースを分類して管理します。このことにより、より明確に監視/被監視の対象を区別できるほか、クラスタ構築や障害検出時の対応が容易になります。リソースはハートビートリソース、ネットワークパーティション解決リソース、グループリソース、モニタリソースの 4 つに分類されます。以下にその概略を示します。

参考

各リソースの詳細については、『リファレンスガイド』を参照してください。

3.6.1. ハートビートリソース

サーバ間で、お互いの生存を確認するためのリソースです。

以下に現在サポートされているハートビートリソースを示します。

• LAN ハートビートリソース

  Ethernet を利用した通信を示します。
• Witness ハートビートリソース

  Witness サーバサービスが動作している外部サーバから取得した各サーバとの通信状態を示します。

3.6.2. ネットワークパーティション解決リソース

ネットワークパーティション状態を解決するためのリソースを示します。

• DISK ネットワークパーティション解決リソース

  DISK 方式によるネットワークパーティション解決リソースです。共有ディスク構成の場合のみ利用可能です。
• PING ネットワークパーティション解決リソース

  PING 方式によるネットワークパーティション解決リソースです。
• HTTP ネットワークパーティション解決リソース

  HTTP 方式によるネットワークパーティション解決リソースです。
• 多数決ネットワークパーティション解決リソース

  多数決方式によるネットワークパーティション解決リソースです。

3.6.3. グループリソース

フェイルオーバを行う際の単位となる、フェイルオーバグループを構成するリソースです。

以下に現在サポートされているグループリソースを示します。

• アプリケーションリソース (appli)

  アプリケーション (ユーザ作成アプリケーションを含む) を起動/停止するための仕組みを提供します。
• フローティング IP リソース (fip)

  仮想的な IP アドレスを提供します。クライアントからは一般の IP アドレスと同様にアクセス可能です。
• ミラーディスクリソース (md)

  ローカルディスク上の特定のパーティションのミラーリングとアクセス制御を行う機能を提供します。ミラーディスク構成の場合のみ利用可能です。
• レジストリ同期リソース (regsync)

  クラスタを構成するサーバ間でアプリケーションやサービスを同一設定で動作させるために、複数サーバの特定レジストリを同期する仕組みを提供します。
• スクリプトリソース (script)

  ユーザ作成スクリプト等のスクリプト (BAT) を起動/停止するための仕組みを提供します。
• ディスクリソース (sd)

  共有ディスク上の特定のパーティションのアクセス制御を行う機能を提供します。共有ディスク装置が接続されている場合にのみ利用可能です。
• サービスリソース (service)

  データベースや Web 等のサービスを起動/停止するための仕組みを提供します。
• 仮想コンピュータ名リソース (vcom)

  仮想的なコンピュータ名を提供します。クライアントからは一般のコンピュータ名と同様にアクセス可能です。
• ダイナミック DNS リソース (ddns)

  Dynamic DNS サーバに仮想ホスト名と活性サーバの IP アドレスを登録します。
• 仮想 IP リソース (vip)

  仮想的な IP アドレスを提供します。クライアントからは一般の IP アドレスと同様にアクセス可能です。ネットワークアドレスの異なるセグメント間で遠隔クラスタを構成する場合に使用します。
• CIFS リソース (cifs)

  共有ディスク/ミラーディスク上のフォルダを共有公開するための機能を提供します。
• ハイブリッドディスクリソース (hd)

  ディスクリソースとミラーディスクリソースを組み合わせたリソースで、共有ディスクまたはローカルディスク上の特定のパーティションのミラーリングとアクセス制御を行う機能を提供します。
• AWS Elastic IP リソース (awseip)

  AWS 上で CLUSTERPRO を利用する場合、EIP を付与する仕組みを提供します。
• AWS 仮想 IP リソース (awsvip)

  AWS 上で CLUSTERPRO を利用する場合、VIP を付与する仕組みを提供します。
• AWS セカンダリ IP リソース (awssip)

  AWS 上で CLUSTERPRO を利用する場合、セカンダリ IP を付与する仕組みを提供します。
• AWS DNS リソース (awsdns)

  AWS 上で CLUSTERPRO を利用する場合、Amazon Route 53 に仮想ホスト名と活性サーバの IP アドレスを登録します。
• Azure プローブポートリソース (azurepp)

  Microsoft Azure 上で CLUSTERPRO を利用する場合、業務が稼働するノードで特定のポートを開放する仕組みを提供します。
• Azure DNS リソース (azuredns)

  Microsoft Azure 上で CLUSTERPRO を利用する場合、Azure DNS に仮想ホスト名と活性サーバの IP アドレスを登録します。
• Google Cloud 仮想 IP リソース (gcvip)

  Google Cloud 上で CLUSTERPRO を利用する場合、業務が稼働するノードで特定のポートを開放する仕組みを提供します。
• Google Cloud DNS リソース (gcdns)

  Google Cloud 上で CLUSTERPRO を利用する場合、Cloud DNS に仮想ホスト名と活性サーバの IP アドレスを登録します。
• Oracle Cloud 仮想 IP リソース (ocvip)

  Oracle Cloud Infrastructure 上で CLUSTERPRO を利用する場合、業務が稼働するノードで特定のポートを開放する仕組みを提供します。
• Oracle Cloud DNS リソース (ocdns)

  Oracle Cloud Infrastructure 上で CLUSTERPRO を利用する場合、Oracle Cloud DNS に仮想ホスト名と活性サーバの IP アドレスを登録します。

注釈

ミラーディスクリソースを使用するためには、『CLUSTERPRO X Replicator』 または『CLUSTERPRO X Replicator DR』 のライセンスが必要です。

ハイブリッドディスクリソースを使用するためには、『CLUSTERPRO X Replicator DR』 のライセンスが必要です。

ライセンスが登録されていないリソースは、Cluster WebUIの一覧に表示されません。

3.6.4. モニタリソース

クラスタシステム内で、監視を行う主体であるリソースです。

以下に現在サポートされているモニタリソースを示します。

• アプリケーション監視リソース (appliw)

  アプリケーションリソースで起動したプロセスの死活監視機能を提供します。
• ディスク RW 監視リソース (diskw)

  ファイルシステムへの監視機構を提供します。また、ファイルシステム I/O ストール時に意図的な STOP エラーまたは、HW リセットによりフェイルオーバを実施する機能を提供します。共有ディスクのファイルシステムへの監視にも利用できます。
• フローティング IP 監視リソース (fipw)

  フローティング IP リソースで起動した IP アドレスの監視機構を提供します。
• IP 監視リソース (ipw)

  ネットワークの疎通を監視する機構を提供します
• ミラーディスク監視リソース (mdw)

  ミラーディスクの監視機構を提供します。
• NIC Link Up/Down 監視リソース (miiw)

  LAN ケーブルのリンクステータスの監視機構を提供します。
• マルチターゲット監視リソース (mtw)

  複数のモニタリソースを束ねたステータスを提供します。
• レジストリ同期監視リソース (regsyncw)

  レジストリ同期リソースによる同期処理の監視機構を提供します。
• ディスク TUR 監視リソース (sdw)

  SCSI の [TestUnitReady] コマンドにより共有ディスクへのアクセスパスの動作を監視する機構を提供します。FibreChannel の共有ディスクに対しても使用できます。
• サービス監視リソース (servicew)

  サービスの死活監視機能を提供します。
• 仮想コンピュータ名監視リソース (vcomw)

  仮想コンピュータ名リソースで起動した仮想コンピュータの監視機構を提供します。
• ダイナミックDNS監視リソース (ddnsw)

  定期的に Dynamic DNS サーバに仮想ホスト名と活性サーバの IP アドレスを登録します。
• 仮想 IP 監視リソース (vipw)

  仮想 IP リソースで起動した IP アドレスの監視機構を提供します。
• CIFS 監視リソース (cifsw)

  CIFS リソースで公開した共有フォルダの監視機構を提供します。
• ハイブリッドディスク監視リソース (hdw)

  ハイブリッドディスクの監視機構を提供します。
• ハイブリッドディスク TUR 監視リソース (hdtw)

  SCSI の [TestUnitReady] コマンドにより、ハイブリッドディスクとして使用する共有ディスク装置へのアクセスパスの動作を監視する機構を提供します。FibreChannel の共有ディスクに対しても使用できます。
• カスタム監視リソース (genw)

  監視処理を行うコマンドやスクリプトがある場合に、その動作結果によりシステムを監視する機構を提供します。
• プロセス名監視リソース (psw)

  プロセス名を指定することで、任意のプロセスの死活監視機能を提供します。
• DB2 監視リソース (db2w)

  IBM DB2 データベースへの監視機構を提供します。
• ODBC 監視リソース (odbcw)

  ODBC でアクセス可能なデータベースへの監視機構を提供します。
• Oracle 監視リソース (oraclew)

  Oracle データベースへの監視機構を提供します。
• PostgreSQL 監視リソース (psqlw)

  PostgreSQL データベースへの監視機構を提供します。
• SQL Server 監視リソース (sqlserverw)

  SQL Server データベースへの監視機構を提供します。
• FTP 監視リソース (ftpw)

  FTP サーバへの監視機構を提供します。
• HTTP 監視リソース (httpw)

  HTTP サーバへの監視機構を提供します。
• IMAP4 監視リソース (imap4w)

  IMAP サーバへの監視機構を提供します。
• POP3 監視リソース (pop3w)

  POP サーバへの監視機構を提供します。
• SMTP 監視リソース (smtpw)

  SMTP サーバへの監視機構を提供します。
• Tuxedo 監視リソース (tuxw)

  Tuxedo アプリケーションサーバへの監視機構を提供します。
• WebSphere 監視リソース (wasw)

  WebSphere アプリケーションサーバへの監視機構を提供します。
• WebLogic 監視リソース(wlsw)

  WebLogic アプリケーションサーバへの監視機構を提供します。
• WebOTX 監視リソース (otxw)

  WebOTX アプリケーションサーバへの監視機構を提供します。
• 外部連携監視リソース (mrw)

  "異常発生通知受信時に実行する異常時動作の設定"と"異常発生通知の Cluster WebUI 表示" を実現するためのモニタリソースです。
• JVM監視リソース (jraw)

  Java VMへの監視機構を提供します。
• システム監視リソース (sraw)

  システム全体のリソースへの監視機構を提供します。
• プロセスリソース監視リソース (psrw)

  プロセス個別のリソースの監視機構を提供します。
• ユーザ空間監視リソース (userw)

  ユーザ空間のストール監視機構を提供します。また、ユーザ空間ストール時に意図的な STOP エラーまたは、HW リセットによりフェイルオーバを実施する機能を提供します。
• AWS Elastic IP監視リソース (awseipw)

  AWS Elastic IPリソースで付与した Elastic IP(以下、EIP)の監視機構を提供します。
• AWS 仮想IP監視リソース (awsvipw)

  AWS 仮想IPリソースで付与した仮想IP(以下、VIP)の監視機構を提供します。
• AWS セカンダリ IP 監視リソース (awssipw)

  AWS セカンダリ IP リソースで付与した セカンダリ IP の監視機構を提供します。
• AWS AZ監視リソース (awsazw)

  Availability Zone(以下、AZ) の監視機構を提供します。
• AWS DNS 監視リソース (awsdnsw)

  AWS DNS リソースで付与した仮想ホスト名と IP アドレスの監視機構を提供します。
• Azure プローブポート監視リソース (azureppw)

  Azure プローブポートリソースが起動しているノードに対して、死活監視のためのポートの監視機構を提供します。
• Azure ロードバランス監視リソース (azurelbw)

  Azure プローブポートリソースが起動していないノードに対して、プローブ ポートと同じポート番号が開放されていないかの監視機構を提供します。
• Azure DNS 監視リソース (azurednsw)

  Azure DNS リソースで付与した仮想ホスト名と IP アドレスの監視機構を提供します。
• Google Cloud 仮想 IP 監視リソース (gcvipw)

  Google Cloud 仮想 IP リソースが起動しているノードに対して、死活監視のためのポートの監視機構を提供します。
• Google Cloud ロードバランス監視リソース (gclbw)

  Google Cloud 仮想 IP リソースが起動していないノードに対して、ヘルスチェック用ポートと同じポート番号が開放されていないかの監視機構を提供します。
• Google Cloud DNS 監視リソース (gcdnsw)

  Google Cloud DNS リソースで付与した仮想ホスト名と IP アドレスの監視機構を提供します。
• Oracle Cloud 仮想 IP 監視リソース (ocvipw)

  Oracle Cloud 仮想 IP リソースが起動しているノードに対して、死活監視のためのポートの監視機構を提供します。
• Oracle Cloud ロードバランス監視リソース (oclbw)

  Oracle Cloud 仮想 IP リソースが起動していないノードに対して、ヘルスチェック用ポートと同じポート番号が開放されていないかの監視機構を提供します。
• Oracle Cloud DNS 監視リソース (ocdnsw)

  Oracle Cloud DNS リソースで付与した仮想ホスト名と IP アドレスの監視機構を提供します。

注釈

DB2 監視リソース、ODBC 監視リソース、Oracle 監視リソース、PostgreSQL 監視リソース、SQL Server 監視リソースを使用するためには、『CLUSTERPRO X Database Agent』 のライセンスが必要です。

FTP 監視リソース、HTTP 監視リソース、IMAP4 監視リソース、POP3 監視リソース、SMTP 監視リソースを使用するためには、『CLUSTERPRO X Internet Server Agent』 のライセンスが必要です。

Tuxedo 監視リソース、WebLogic 監視リソース、WebSphere 監視リソース、WebOTX 監視リソースを使用するためには、『CLUSTERPRO X Application Server Agent』 のライセンスが必要です。

JVM監視リソースを使用するためには『CLUSTERPRO X Java Resource Agent』のライセンスが必要です。

システム監視リソース、プロセスリソース監視リソースを使用するためには『CLUSTERPRO X System Resource Agent』のライセンスが必要です。

ライセンスが登録されていない監視リソースは、Cluster WebUIの一覧に表示されません。

3.7. CLUSTERPRO を始めよう!

以上で CLUSTERPRO の簡単な説明が終了しました。

以降は、以下の流れに従い、対応するガイドを読み進めながら CLUSTERPRO を使用したクラスタシステムの構築を行ってください。

3.7.1. 最新情報の確認

本ガイドの「4. CLUSTERPRO の動作環境」、「5. 最新バージョン情報」、「6. 注意制限事項」を参照してください。

3.7.2. クラスタシステムの設計

『インストール&設定ガイド』の「システム構成を決定する」、「クラスタシステムを設計する」および

『リファレンスガイド』の「グループリソースの詳細」、「モニタリソースの詳細」、「ハートビートリソースの詳細」、「ネットワークパーティション解決リソースの詳細」、「その他の設定情報」 を参照してください。

3.7.3. クラスタシステムの構築

『インストール&設定ガイド』の全編を参照してください。

3.7.4. クラスタシステムの運用開始後の障害対応

『メンテナンスガイド』の「保守情報」および『リファレンスガイド』の「トラブルシューティング」、「エラーメッセージ一覧」を参照してください。

4. CLUSTERPRO の動作環境

本章では、CLUSTERPRO の動作環境について説明します。

本章で説明する項目は以下の通りです。

• 4.1. ハードウェア動作環境

• 4.2. CLUSTERPRO Server の動作環境

• 4.3. Cluster WebUI の動作環境

• 4.4. Witness サーバの動作環境

4.1. ハードウェア動作環境

CLUSTERPRO は以下のアーキテクチャのサーバで動作します。

• x86_64

4.1.1. 必要スペック

CLUSTERPRO Server に必要なスペックは下記の通りです。

• Ethernet ポート 2 つ以上

• 共有ディスク、ミラー用ディスクまたはミラー用空きパーティション (ミラーディスクを使用する場合)

• DVD-ROM ドライブ

4.2. CLUSTERPRO Server の動作環境

4.2.1. 対応 OS

CLUSTERPRO は、下記の OS に対応しています。

x86_64 版

OS	備考
Windows Server 2016 Standard
Windows Server 2016 Datacenter
Windows Server 2019 Standard
Windows Server 2019 Datacenter
Windows Server 2022 Standard
Windows Server 2022 Datacenter

4.2.2. 必要メモリ容量とディスクサイズ

必要メモリサイズ （ユーザモード）	384MB( 2 )
必要メモリサイズ （kernelモード）	32MB + 4MB( 3 )×（ミラーディスクリソース数+ハイブリッドディスクリソース数）
必要ディスクサイズ （インストール直後）	100MB
必要ディスクサイズ （運用時）	5.0GB + 9.0GB ( 4 )

2

オプション類を除く

3

ミラーディスクリソースおよびハイブリッドディスクリソース使用時に必要なメモリサイズです。

4

ミラーディスクリソースおよびハイブリッドディスクリソース使用時に必要なディスクサイズです。

非同期方式に変更時やキューサイズ変更時および差分ビットマップサイズ変更時は、構成時に指定したサイズのメモリが追加で必要になります。また、ミラーディスクへの I/O に対応してメモリを使用するため、ディスク負荷の増加にともない使用するメモリサイズも増加します。

DISK ネットワークパーティション解決リソースが使用するパーティションに必要なサイズは「共有ディスクについて」を参照してください。

クラスタパーティションに必要なサイズは「ミラーディスク用のパーティションについて」、「ハイブリッドディスク用のパーティションについて」を参照してください。

4.2.3. 監視オプションの動作確認済アプリケーション情報

監視オプションは、下記のアプリケーションを監視対象として動作確認しています。

x86_64 版

モニタリソース	監視対象の アプリケーション	CLUSTERPRO Version	備考
Oracle 監視	Oracle Database 19c (19.3)	13.00~
DB2 監視	DB2 V11.5	13.00~
PostgreSQL 監視	PostgreSQL 14.1	13.00~
	PostgreSQL 15.1	13.10~
	PostgreSQL 16.3	13.21~
	PowerGres on Windows V13	13.00~
SQL Server 監視	SQL Server 2019	13.00~
	SQL Server 2022	13.10~
Tuxedo 監視	Tuxedo 12c Release 2 (12.1.3)	12.00~
	Tuxedo 22c (22.1.0)	13.20~
WebLogic 監視	WebLogic Server 11g R1	12.00~
	WebLogic Server 11g R2	12.00~
	WebLogic Server 12c R2 (12.2.1)	12.00~
	WebLogic Server 14c (14.1.1)	12.20~
WebSphere 監視	WebSphere Application Server 8.5	12.00~
	WebSphere Application Server 8.5.5	12.00~
	WebSphere Application Server 9.0	12.00~
WebOTX 監視	WebOTX Application Server V9.1	12.00~
	WebOTX Application Server V9.2	12.00~
	WebOTX Application Server V9.3	12.00~
	WebOTX Application Server V9.4	12.00~
	WebOTX Application Server V9.5	12.00~
	WebOTX Application Server V10.1	12.00~
	WebOTX Application Server V10.3	12.30~
	WebOTX Application Server V11.1	13.20~
JVM監視	WebLogic Server 11g R1	12.00~
	WebLogic Server 11g R2	12.00~
	WebLogic Server 12c R2 (12.2.1)	12.00~
	WebLogic Server 14c (14.1.1)	12.20~
	WebOTX Application Server V9.1	12.00~
	WebOTX Application Server V9.2	12.00~
	WebOTX Application Server V9.3	12.00~
	WebOTX Application Server V9.4	12.00~
	WebOTX Application Server V9.5	12.00~
	WebOTX Application Server V10.1	12.00~
	WebOTX Application Server V11.1	13.20~
	WebOTX Application Server V10.3	12.30~
	WebOTX Enterprise Service Bus V8.4	12.00~
	WebOTX Enterprise Service Bus V8.5	12.00~
	WebOTX Enterprise Service Bus V10.3	12.30~
	WebOTX Enterprise Service Bus V11.1	13.20~
	Apache Tomcat 8.0	12.00~
	Apache Tomcat 8.5	12.00~
	Apache Tomcat 9.0	12.00~
	Apache Tomcat 10.0	13.02~
	WebSAM SVF for PDF 9.1	12.00~
	WebSAM SVF for PDF 9.2	12.00~
	WebSAM SVF PDF Enterprise 10.1	13.10~
	WebSAM Report Director Enterprise 9.1	12.00~
	WebSAM Report Director Enterprise 9.2	12.00~
	WebSAM RDE SUITE 10.1	13.10~
	WebSAM Universal Connect/X 9.1	12.00~
	WebSAM Universal Connect/X 9.2	12.00~
	WebSAM SVF Connect SUITE Standard 10.1	13.10~
システム監視	バージョン指定無し	12.00~
プロセスリソース監視	バージョン指定無し	12.10~

注釈

x86_64環境で監視オプションをご利用される場合、監視対象のアプリケーションもx86_64版のアプリケーションをご利用ください。

4.2.4. SNMP 連携機能の動作環境

SNMP 連携機能の動作確認を行った OS を下記に提示します。

x86_64 版

OS	備考
Windows Server 2016

4.2.5. JVM 監視の動作環境

JVM監視を使用する場合には、Java 実行環境が必要です。

Java(TM) Runtime Environment

Version8.0 Update 11 (1.8.0_11) 以降

Java(TM) Runtime Environment

Version9.0 (9.0.1) 以降

Java(TM) SE Development Kit

Version11.0 (11.0.5) 以降

Java(TM) SE Development Kit

Version17.0 (17.0.2) 以降

4.2.6. システム監視，プロセスリソース監視及びシステムリソース情報を収集する機能の動作環境

System Resource Agent を使用するには、Microsoft .NET Framework の実行環境が必要です。

Microsoft .NET Framework 4.6.2 以上

Microsoft .NET Framework 4.6.2 日本語 Language Pack 以上

注釈

Windows Server 2016 以降のOSでは、.NET Framework 4.6.2 以降のバージョンがプレインストールされています（プレインストールされている .NET Framework のバージョンは、OSにより異なります）。

4.2.7. AWS Elastic IP リソース、AWS Elastic IP監視リソース、AWS AZ 監視リソースの動作環境

AWS Elastic IPリソース、AWS Elastic IP監視リソース、AWS AZ監視リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
AWS CLI	1.12.0~ 2.0.0~

4.2.8. AWS 仮想 IP リソース、AWS 仮想 IP 監視リソースの動作環境

AWS 仮想IPリソース、AWS 仮想IP監視リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
AWS CLI	1.12.0~ 2.0.0~

4.2.9. AWS セカンダリ IP リソース、AWS セカンダリ IP 監視リソースの動作環境

AWS セカンダリ IP リソース、AWS セカンダリ IP 監視リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
AWS CLI	1.12.0~ 2.0.0~

4.2.10. AWS DNS リソース、AWS DNS 監視リソースの動作環境

AWS DNS リソース、AWS DNS 監視リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
AWS CLI	1.12.0~ 2.0.0~

4.2.11. AWS 強制停止リソースの動作環境

AWS 強制停止リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
AWS CLI	1.15.0~ 2.0.0~

4.2.12. Azure プローブポートリソース、Azure プローブポート監視リソース、Azure ロードバランス監視リソースの動作環境

Azure プローブポートリソース、Azure プローブポート監視リソース、Azure ロードバランス監視リソースの動作確認を行った Microsoft Azure 上のデプロイモデルを下記に提示します。

ロードバランサーの設定方法は、『CLUSTERPRO X Microsoft Azure 向け HAクラスタ 構築ガイド』を参照してください。

デプロイモデル	CLUSTERPRO Version	備考
リソースマネージャー	12.00~	ロードバランサーの追加が必要

4.2.13. Azure DNS リソース、Azure DNS 監視リソースの動作環境

Azure DNS リソース、Azure DNS 監視リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
Azure CLI	2.0~

Azure CLI のインストール方法は以下を参照してください。

Azure CLI のインストール:

https://docs.microsoft.com/ja-jp/cli/azure/install-azure-cli?view=azure-cli-latest

Azure DNS リソース、Azure DNS 監視リソースの動作確認を行った Microsoft Azure 上のデプロイモデルを下記に提示します。

Azure DNS の設定方法は、『CLUSTERPRO X Microsoft Azure 向け HAクラスタ 構築ガイド』を参照してください。

デプロイモデル	CLUSTERPRO Version	備考
リソースマネージャー	12.00~	Azure DNS の追加が必要

4.2.14. Azure 強制停止リソースの動作環境

Azure 強制停止リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
Azure CLI	2.0~

4.2.15. Google Cloud 仮想 IP リソース、Google Cloud 仮想 IP 監視リソース、Google Cloud ロードバランス監視リソースの動作環境

Google Cloud 仮想 IP リソース、Google Cloud 仮想 IP 監視リソース、Google Cloud ロードバランス監視リソースの動作確認を行った Google Cloud 上の OS のバージョン情報を下記に提示します。

ディストリビューション	CLUSTERPRO Version	備考
Windows Server 2016	12.20~
Windows Server 2019	12.20~

4.2.16. Google Cloud DNS リソース、Google Cloud DNS 監視リソースの動作環境

Google Cloud DNS リソース、Google Cloud DNS 監視リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
Google Cloud SDK	295.0.0~

Google Cloud SDK の前提条件、インストール方法は以下を参照してください。

Google Cloud SDK のインストール:

https://cloud.google.com/sdk/install

4.2.17. Oracle Cloud 仮想 IP リソース、Oracle Cloud 仮想 IP 監視リソース、Oracle Cloud ロードバランス監視リソースの動作環境

Oracle Cloud 仮想 IP リソース、Oracle Cloud 仮想 IP 監視リソース、Oracle Cloud ロードバランス監視リソースの動作確認を行った Oracle Cloud Infrastructure 上の OS のバージョン情報を下記に提示します。

ディストリビューション	CLUSTERPRO Version	備考
Windows Server 2016	12.20~

4.2.18. Oracle Cloud DNS リソース、Oracle Cloud DNS 監視リソースの動作環境

Oracle Cloud DNS リソース、Oracle Cloud DNS 監視リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
OCI CLI	3.27.1~

4.2.19. OCI 強制停止リソースの動作環境

OCI 強制停止リソースを使用する場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
OCI CLI	3.5.3~

4.2.20. 暗号化を有効にする場合の動作環境

CLUSTERPRO のコンポーネントで通信の暗号化を有効にする場合には、以下のソフトウェアが必要です。

ソフトウェア	Version	備考
OpenSSL	1.1.1 (1.1.1a~) 3.0 (3.0.0~) 3.1 (3.1.0~)

上記のソフトウェアを使用した、通信の暗号化をサポートするコンポーネントは、以下の通りです。

• Cluster WebUI

• RESTful API

• FTP 監視リソース

• メール通報機能

• ミラーディスクリソース

• ハイブリッドディスクリソース

4.3. Cluster WebUI の動作環境

Cluster WebUI を動作させるために必要な環境について記載します。

4.3.1. 動作確認済 OS、ブラウザ

現在の対応状況は下記の通りです。

ブラウザ	言語
Firefox	日本語/英語/中国語
Google Chrome	日本語/英語/中国語
Microsoft Edge (Chromium)	日本語/英語/中国語

注釈

IPアドレスで接続する場合、事前に該当の IPアドレスを [ローカル イントラネット] の [サイト] に登録する必要があります。

注釈

タブレットやスマートフォンなどのモバイルデバイスには対応していません。

4.3.2. 必要メモリ容量/ディスク容量

• 必要メモリ容量　　 500MB 以上

• 必要ディスク容量　 200MB 以上

4.4. Witness サーバの動作環境

4.4.1. Witness サーバサービスの動作確認済み環境

以下の環境で動作確認済みです。

Witness サーバのバージョン	実行環境
5.2.0	Node.js 18.13.0 Node.js 20.10.0

4.4.2. 必要メモリ容量とディスクサイズ

必要メモリサイズ	50MB + (ノード数 * 0.5 MB)
必要ディスクサイズ	1GB

5. 最新バージョン情報

本章では、CLUSTERPRO の最新情報について説明します。新しいリリースで強化された点、改善された点などをご紹介します。

• 5.1. CLUSTERPRO とマニュアルの対応一覧

• 5.2. 機能強化

• 5.3. 修正情報

5.1. CLUSTERPRO とマニュアルの対応一覧

本書では下記のバージョンの CLUSTERPRO を前提に説明してあります。CLUSTERPRO のバージョンとマニュアルの版数に注意してください。

CLUSTERPROの 内部バージョン	マニュアル	版数	備考
13.21	スタートアップガイド	第 3 版
	インストール&設定ガイド	第 2 版
	リファレンスガイド	第 3 版
	メンテナンスガイド	第 2 版

5.2. 機能強化

各バージョンにおいて以下の機能強化を実施しています。

項番	内部バージョン	機能強化項目
1	13.00	Windows Server 2022 に対応しました。
2	13.00	メジャーバージョンアップに伴い、いくつかの機能を削除しました。詳細は機能削除一覧を参照してください。
3	13.00	サーバダウン時の自動フェイルオーバをクラスタ全体で一括して抑止する機能を追加しました。
4	13.00	グループリソースの活性・非活性異常検出時およびモニタリソースの異常検出時の最終動作によるサーバ再起動の回数がリセットされたときに、アラートログで通知するようにしました。
5	13.00	ダイナミックフェイルオーバ以外の自動フェイルオーバにおいて、指定したモニタリソースで異常を検出しているサーバをフェイルオーバ先から除外できるようになりました。
6	13.00	ファイアウォールの規則を追加するコマンド clpfwctrl を追加しました。
7	13.00	AWS セカンダリ IP リソース、AWS セカンダリ IP 監視リソースを追加しました。
8	13.00	BMCを利用した強制停止機能をBMC強制停止リソースとして刷新しました。
9	13.00	仮想マシン強制停止機能をvCenter強制停止リソースとして刷新しました。
10	13.00	AWS環境の強制停止機能を強制停止リソースに追加しました。
11	13.00	OCI環境の強制停止機能を強制停止リソースに追加しました。
12	13.00	強制停止スクリプトをカスタム強制停止リソースとして刷新しました。
13	13.00	モニタ異常検出時の回復動作等でOSシャットダウンを伴う動作を一括してOSリブートに変更する機能を追加しました。
14	13.00	グループ間の起動および停止待ち合わせ処理に関するアラートメッセージを改善しました。
15	13.00	clpstatの設定情報の表示オプションで、リソース起動属性の設定値を表示できるようにしました。
16	13.00	clpcl/clpstdnコマンドで、自サーバがクラスタ停止状態でも-hオプションを指定できるようにしました。
17	13.00	実IPアドレス以外で Cluster WebUI に接続して設定モードに切替えた時に警告メッセージを出力するようになりました。
18	13.00	Cluster WebUI の設定モードで除外対象のパーティション情報が取得できない場合でも構成情報の反映およびエクスポートができるようになりました。
19	13.00	Cluster WebUI の設定モードでグループリソースを登録している状態でグループの削除が行えるようになりました。
20	13.00	Cluster WebUI で通信タイムアウトが発生した際のエラーメッセージの内容を変更しました。
21	13.00	Cluster WebUI のミラーディスク画面でフルコピー等の実行に失敗した際のエラーメッセージの内容を変更しました。
22	13.00	Cluster WebUI の設定モードで登録したグループ、グループリソース、モニタリソースを複製できる機能を追加しました。
23	13.00	Cluster WebUI の設定モードで登録したグループリソースを別のグループへ移動できる機能を追加しました。
24	13.00	Cluster WebUI の設定モードの [グループのプロパティ] のグループリソース一覧から設定を変更できるようになりました。
25	13.00	Cluster WebUI の設定モードの [モニタ共通のプロパティ] のモニタリソース一覧から設定を変更できるようになりました。
26	13.00	Cluster WebUI の設定モードでグループリソース非活性時の依存関係が表示されるようになりました。
27	13.00	Cluster WebUI の設定モードでグループリソース活性時および非活性時の依存関係図を表示する機能を追加しました。
28	13.00	Cluster WebUI のステータス画面でグループリソース/モニタリソースのタイプやリソース名で表示を絞り込む機能を追加しました。
29	13.00	CIFSリソースの [共有設定復元時の失敗を活性異常とする] の既定値をオンからオフに変更しました。
30	13.00	WebManager サービスで通信方式に HTTPS を使用した場合、証明書ファイルとして中間証明書を使用できるようになりました。
31	13.00	クラスタ構成情報ファイルを旧バージョンから現バージョンへ変換するコマンド clpcfconv を追加しました。
32	13.00	OS起動時にクラスタサービスの起動を遅延させる機能を追加しました。
33	13.00	Cluster WebUI のクラスタ構成情報チェックのエラー結果において、対処法などの詳細を表示できるようになりました。
34	13.00	clpcfsetコマンドのcreateオプション指定時にOS種別を指定できるようにしました。
35	13.00	clpcfsetコマンドにdelオプションを追加し、クラスタ構成情報からリソースやパラメータを削除する機能を追加しました。
36	13.00	clpcfsetコマンドのインターフェースを強化したclpcfadm.pyコマンドを追加しました。
37	13.00	AWS DNSリソースの起動完了タイミングをレコードセットがAWS Route53へ伝搬されたことを確認してから起動するように変更しました。
38	13.00	AWS DNS監視リソースの監視開始待ち時間の既定値を300秒に変更しました。
39	13.00	clpstatコマンドが二重起動可能となりました。
40	13.00	Node Managerサービスを追加しました
41	13.00	ハートビート統計情報機能を追加しました。
42	13.00	HTTP NP解決リソースで、Witnessハートビートリソースを使用しない場合でも Proxyサーバを利用できるようになりました。
43	13.00	HTTP監視リソースがDigest認証に対応しました。
44	13.00	FTP監視リソースでFTPSを利用するFTPサーバを監視できるようになりました。
45	13.00	システム監視リソースを複数登録できるようになりました。
46	13.00	プロセスリソース監視リソースを複数登録できるようになりました。
47	13.00	プロセスリソース監視リソースで特定のプロセスのみを監視対象とする機能を追加しました。
48	13.00	サービス監視リソース単体で任意のサービスの監視が行えるようになりました。
49	13.00	clpmdctrlコマンド、clpmdstatコマンドのオプション体系をclphdctrlコマンド、clphdstatコマンドに合わせました。
50	13.02	JVM監視リソースが Apache Tomcat 10.0 に対応しました。
51	13.10	CVE-2022-34824～34825 の脆弱性に対応し、インストール時にインストール先フォルダのアクセス権を適切に設定する機能を追加しました。
52	13.10	メール通報機能が SMTPS および STARTTLS に対応しました。
53	13.10	Azure 環境の強制停止機能を強制停止リソースに追加しました。
54	13.10	vCenter 強制停止リソースで vSphere Automation API を利用した強制停止機能を追加しました。
55	13.10	ログファイルを保存する期間を設定できるようになりました。
56	13.10	クラスタ構成情報チェック機能のチェック項目を拡充しました。
57	13.10	フローティングIPリソースの送信元 IP アドレスを変更できるようになりました。
58	13.10	ReFS を使用したミラーディスクリソースの初期構築およびフルコピー処理を高速化しました。
59	13.10	ミラーブレイク状態でのフェイルオーバを許容する機能を追加しました。
60	13.10	マルチターゲット監視リソースで以下のモニタリソースを登録できるようになりました。 - AWS Elastic IP 監視リソース - AWS 仮想 IP 監視リソース - AWS セカンダリ IP 監視リソース - AWS AZ 監視リソース - AWS DNS 監視リソース - Azure プローブポート監視リソース - Azure ロードバランス監視リソース - Azure DNS 監視リソース - Google Cloud 仮想 IP 監視リソース - Google Cloud ロードバランス監視リソース - Google Cloud DNS 監視リソース - Oracle Cloud 仮想 IP 監視リソース - Oracle Cloud ロードバランス監視リソース
61	13.10	カスタム監視リソースに、設定されたスクリプトの戻り値を警告とする機能を追加しました。
62	13.10	SQL Server 監視リソースが SQL Server 2022 に対応しました。
63	13.10	PostgreSQL 監視リソースが PostgreSQL 15.1 に対応しました。
64	13.10	AWS 環境で、AWS 仮想IPリソース および AWS 仮想IP監視リソースのみを使用する構成では Python が不要になりました。
65	13.10	AWS 関連機能で実行しているAWS CLI やインスタンスメタデータへのアクセスに環境変数を指定する機能を Cluster WebUI から設定できるようになりました。
66	13.10	AWS 関連機能で実行しているAWS CLI にコマンドラインオプションを指定する機能を追加しました。
67	13.10	JVM監視リソースが WebSAM SVF PDF Enterprise 10.1 に対応しました。
68	13.10	JVM監視リソースが WebSAM RDE SUITE 10.1 に対応しました。
69	13.10	JVM監視リソースが WebSAM SVF Connect SUITE Standard 10.1 に対応しました。
70	13.10	プロセスリソース統計情報を出力する機能を追加しました。
71	13.10	HTTP監視リソースがクライアント認証に対応しました。
72	13.10	FTP監視リソースが OpenSSL3.0 に対応しました。
73	13.10	JVM監視リソースで、運用ログにリトライ回数に関する情報を出力するようになりました。
74	13.10	JVM監視リソースが Java17 に対応しました。
75	13.10	JVM監視リソースが Java7 非対応になりました。
76	13.10	すべての Ping NP 解決リソースのステータスが異常で NP 状態になった場合にシャットダウンするよう挙動を変更しました。
77	13.10	clpbackup コマンドにサーバシャットダウンや再起動をおこなわないオプションを追加しました。
78	13.10	clpcfadm.py コマンドに変更前のクラスタ構成情報のバックアップファイルを作成するオプションを追加しました。
79	13.10	Cluster WebUI および clplogcc コマンドでプロアクティブ診断用のログを採取できるようになりました。
80	13.10	Cluster WebUI の操作ログを Cluster WebUI で表示できるようになりました。
81	13.10	ミラー構築中のクラスタ構成情報の変更をガードするようにしました。
82	13.10	Cluster WebUI が OpenSSL 3.0 に対応しました。
83	13.10	Cluster WebUI の HTTPS 接続において TLS 1.1 を無効化しました。
84	13.10	通信可能なサーバのみに対して Cluster WebUI でクラスタ構成情報の反映をおこなう機能を追加しました。
85	13.10	Cluster WebUI のステータス画面にクラスタの動作が無効化されている設定の一覧を表示する機能を追加しました。
86	13.10	Cluster WebUI の設定モードで、以下の項目を表示/非表示にする機能およびソートする機能を追加しました。 - [グループのプロパティ] のグループリソース一覧 - [モニタ共通のプロパティ] のモニタリソース一覧
87	13.10	クラスタプロパティの [接続可能なクライアント台数] の名称を [同時接続セッション数] に変更し、下限値を変更しました。
88	13.10	Cluster WebUI のアラートログの [受信日時] はデフォルトで非表示になりました。
89	13.10	Cluster WebUI のステータス画面の [マネージャ再起動] ボタンの説明を 「WebManagerサービス再起動」 に変更しました。
90	13.10	Cluster WebUI の設定モードから [グループの複製] をおこなう際、グループリソース個別の依存関係も複製できるようになりました。
91	13.10	Cluster WebUI にて、AWS DNS リソースの設定不備をガードするようにしました。
92	13.10	Cluster WebUI にて、カスタム監視リソースの [監視タイプ] に非同期を設定した際の設定不備をガードするようにしました。
93	13.10	Cluster WebUI にて、Ping NP 解決リソースの設定不備をガードするようにしました。
94	13.10	クラスタ統計情報で、手動操作によるフェイルオーバか異常検知による自動フェイルオーバの切り分けが可能になりました。
95	13.11	RESTful API が OpenSSL 3.0 に対応しました。
96	13.11	Witness ハートビートリソースが OpenSSL 3.0 に対応しました。
97	13.11	HTTP ネットワークパーティション解決リソースが OpenSSL 3.0 に対応しました。
98	13.12	以下の機能が OpenSSL 3.1 に対応しました。 - Cluster WebUI - RESTful API - ミラーディスクリソース - ハイブリッドディスクリソース - FTP 監視リソース - メール通報
99	13.20	グループリソース、モニタリソース、強制停止リソースの異常検出時に調査用のログファイルを採取し、Cluster WebUI のアラートログからダウンロードできるようになりました。
100	13.20	停止待ち合わせの対象グループが停止に失敗した際に、停止待ち時間まで待ち合わせないようにしました。
101	13.20	Oracle Cloud DNS リソース、Oracle Cloud DNS 監視リソースを追加しました。
102	13.20	CIFS リソースの [アクセス許可] の [ユーザ名] に 2 バイト文字を設定可能にしました。
103	13.20	以下のグループリソースの依存関係の既定値を変更しました。 - Azure プローブポートリソース - Google Cloud 仮想 IP リソース - Oracle Cloud 仮想 IP リソース - スクリプトリソース - アプリケーションリソース - サービスリソース - ダイナミック DNS リソース - レジストリ同期リソース - 仮想コンピュータ名リソース
104	13.20	以下の AWS 関連リソースおよび監視リソースで Python が不要になりました。 - AWS Elastic IP リソース - AWS DNS リソース - AWS Elastic IP 監視リソース - AWS DNS 監視リソース - AWS AZ 監視リソース
105	13.20	HTTP 監視リソースについて、HTTP/1.1 を強制されるような環境に対応しました。
106	13.20	POP3 監視リソースの認証方式に POP3S を追加しました。
107	13.20	システム監視、プロセスリソース監視及びシステムリソース情報の動作環境を Microsoft .NET Framework 4.6.2 以上に変更しました。
108	13.20	WebOTX 監視リソースが WebOTX V11.1 に対応しました。
109	13.20	JVM 監視リソースが WebOTX V11.1 に対応しました。
110	13.20	Tuxedo 監視リソースが Oracle Tuxedo 22c (22.1.0) に対応しました。
111	13.20	HTTP ネットワークパーティション解決リソースのターゲットに URI を指定可能にしました。
112	13.20	AWS 強制停止リソースを設定している環境で、EC2 インスタンスの停止保護が有効な場合にアラートログで通知するようにしました。
113	13.20	Azure 強制停止リソースの強制停止アクションに、リソース割り当てを解除せず即時停止するアクションを追加しました。
114	13.20	clpstat コマンドの「する/しない」の表示を「オン/オフ」に変更しました。
115	13.20	clpmdstat/clphdstat コマンドの戻り値でミラーディスクリソース/ハイブリットディスクリソースの状態が確認できるようになりました。
116	13.20	clprexec コマンドの --script で指定するスクリプト格納フォルダをコマンド名に合わせて work\trnreq から work\rexec に変更しました。
117	13.20	クラウド関連機能のエラーメッセージを拡充しました。
118	13.20	サーバがダウンした際に出力されるメッセージの種別を改善しました。
119	13.20	RESTful API の操作ログをサーバ側に出力できるようになりました。
120	13.20	RESTful API で以下のメトリクス情報を取得する API を追加しました。 - グループの連続稼働時間 - クラスタ構成情報の最終反映日時
121	13.20	クラスタ構成情報チェック機能のチェック項目を拡充しました。
122	13.20	クラスタ構成情報チェック機能の処理時間を短縮化しました。
123	13.20	Cluster WebUI の [設定のエクスポート] で保存するクラスタ構成情報ファイル名 (zip 形式) に時刻情報を追加しました。
124	13.20	Cluster WebUI の設定モードで、[NP発生時動作] を以下に変更した際に警告ポップアップを表示するようにしました。 - クラスタサービス停止 - クラスタサービス停止と OS シャットダウン - クラスタサービス停止と OS 再起動
125	13.20	Cluster WebUI のステータスタブでサーバの状態を色付けして表示するようにしました。
126	13.20	Cluster WebUI のポップアップアラート通知の表示位置を右上から右下に変更しました。
127	13.20	Cluster WebUI の操作モードでライセンスの期限切れや残日数を表示するようにしました。
128	13.21	CLUSTERPRO インストール時に設定した HBA フィルタリング情報を、クラスタ構成情報アップロード時に自動で取り込むようにしました。
129	13.21	以下の機能が OpenSSL 3.2 および OpenSSL 3.3 に対応しました。 - Cluster WebUI - RESTful API - Witness ハートビートリソース - HTTP ネットワークパーティション解決リソース - FTP 監視リソース - POP3 監視リソース
130	13.21	PostgreSQL 監視リソースが PostgreSQL 16.3 に対応しました。

5.3. 修正情報

各バージョンにおいて以下の修正を実施しています。

項番	修正バージョン / 発生バージョン	修正項目	重要度	発生条件 発生頻度
1	13.00 / 9.00 ～ 12.32	グループリソースの単体活性が成功したとき、同じグループ内の他のグループリソースの復旧動作が実行される場合がある。	小	活性異常状態のグループリソースが存在する状態で、同じグループ内の他のグループリソースを単体活性した場合に発生する。
2	13.00 / 12.10 ～ 12.32	Cluster WebUI の設定モードでグループリソースの「コメント」を修正したときに、修正内容が更新されない場合がある。	小	グループリソースの「コメント」を修正して[適用]ボタン押下後、修正前の状態に戻して[OK]ボタンを押下した場合に発生する。
3	13.00 / 12.10 ～ 12.32	Cluster WebUI の設定モードでモニタリソースの「コメント」を修正したときに、修正内容が更新されない場合がある。	小	モニタリソースの「コメント」を修正して[適用]ボタン押下後、修正前の状態に戻して[OK]ボタンを押下した場合に発生する。
4	13.00 / 12.10 ～ 12.32	停止済のサーバに Cluster WebUI を接続したときに、ダウン後再起動状態のサーバの[サーバ復帰]ボタンが有効にならない	小	停止済のサーバに Cluster WebUI を接続してダウン後再起動状態のサーバが存在する場合に発生する。
5	13.00 / 12.10 ～ 12.32	Cluster WebUI の設定モードで、WebLogic監視の監視（固有）画面にある項目「インストールパス」が入力必須項目となっていない。	小	常に発生する。
6	13.00 / 12.00 ～ 12.32	Cluster WebUI のステータス画面でクラスタの操作を実行した際に、通信タイムアウトが発生すると同一のリクエストを再度発行してしまう。	中	Cluster WebUI とクラスタサーバ間で通信タイムアウトが発生すると必ず発生する。
7	13.00 / 12.10 ～ 12.32	Cluster WebUI の設定モードで依存関係を設定した際に、Cluster WebUI がフリーズする場合がある。	小	2つのグループリソースを互いに依存させた場合に発生する。
8	13.00 / 12.20 ～ 12.32	clpstatコマンドの応答が遅延することがある。	小	他のサーバとの通信が切断した場合に発生することがある。
9	13.00 / 11.10 ～ 12.32	モニタリソースの遅延警告のアラートログで、response time に 0 が出力されることがある。	小	モニタリソースの遅延警告のアラートログが出力された際に発生することがある。
10	13.00 / 12.20 ～ 12.32	clpwebmcのAPエラーが発生することがある。	小	Cluster WebUIの設定モードでサーバを削除したクラスタ構成情報を反映する際に稀に発生することがある。
11	13.00 / 12.00 ～ 12.32	モニタリソースが監視タイムアウトを誤検出することがある。	中	モニタリソースの監視処理実行時にごく稀に発生することがある。
12	13.00 / 12.20 ～ 12.32	HTTP方式のNP解決リソースで、ターゲットのレスポンスがステータスコード301だった場合に異常となる。	小	レスポンスがステータスコード301だった場合に発生する。
13	13.00 / 12.00 ～ 12.32	プロセスリソース監視リソースの[メモリ使用量の監視]の[継続時間 (分)]の表記を[最大更新回数 (回)]に修正しました。	小	Cluster WebUIやclpstatコマンドでプロパティを表示した際に発生する。
14	13.00 / 12.00 ～ 12.32	HTTP監視リソースで、HEAD リクエストの発行に対する応答のステータスコードが400または500 番台であった場合、かつ、監視URI に既定値以外のURI を指定した場合に、異常ではなく警告となる。	小	HEAD リクエストの発行に対する応答のステータスコードが400または500 番台であった場合、かつ、監視URI に既定値以外のURI を指定した場合に発生する。
15	13.00 / 12.10 ～ 12.32	カスタム監視リソースで監視対象のスクリプトのプロセスが消滅した場合のアラートメッセージで対象のモニタリソース名が出力されない。	小	カスタム監視リソースで監視対象のスクリプトのプロセスが消滅した場合に発生する。
16	13.00 / 11.01 ～ 12.32	ミラー関係コマンドの応答に時間がかかることがある。	小	ミラーディスクコネクトが切断されている場合、あるいはクラスタを構成するサーバの一部がダウンしている場合に発生する。
17	13.00 / 12.20 ～ 12.32	CLUSTERPRO Information Base サービスが異常終了することがある。	小	以下のいずれかの操作を行った際にごく稀に発生することがある。 - クラスタ起動 - クラスタ停止 - クラスタサスペンド - クラスタリジューム
18	13.01 / 9.00～12.32、13.00	CVE-2021-20700～20707 の脆弱性により以下の可能性がある。 ・任意のコードを実行される ・任意のファイルをアップロードされる ・任意のファイルを読み取られる	大	悪意のある第三者によって細工された CLUSTERPRO の内部プロトコルに反するパケットを、CLUSTERPRO の特定のプロセスが受信した場合に発生する。
19	13.01 / 13.00	clprexecコマンドの--scriptオプションが動作しない	小	--scriptオプションを指定してclprexecコマンドを実行した場合に発生する。
20	13.01 / 13.00	clpcfset コマンドで強制停止リソースを追加した場合、クラスタ起動に失敗する。	小	clpcfset コマンドで強制停止リソースを追加したクラスタ構成情報を適用したクラスタを起動した場合に発生する。
21	13.02 / 13.00 ～ 13.01	CLUSTERPRO Node Manager サービスがサービス起動遅延時間を待たずに開始する。	小	[サービス起動遅延時間] に 0 秒より大きい値を設定すると発生する。
22	13.02 / 13.01	アップデートインストール時に CLUSTERPRO Old API Support サービスが登録される。	小	内部バージョン 13.00 から 13.01 にアップデートした場合に発生する。
23	13.02 / 13.00 ～ 13.01	フェイルオーバグループの [起動可能なサーバ] の一覧からサーバを削除した構成情報の設定反映時にグループ停止が要求されない。	小	フェイルオーバグループの [起動可能なサーバ] の一覧からサーバを削除した構成情報の設定反映時に発生する。
24	13.02 / 13.00 ～ 13.01	ミラーディスクリソースまたはハイブリッドディスクリソースを含むクラスタ構成情報の設定反映時に STOP エラーが発生することがある。	中	ミラーディスクリソースまたはハイブリッドディスクリソースのリソース名を 8 文字以上に設定すると発生する。
25	13.02 / 13.00 ～ 13.01	モニタリソースが監視タイムアウトを誤検出することがある。	小	モニタリソースの監視処理実行時にごく稀に発生することがある。
26	13.02 / 13.00 ～ 13.01	モニタリソース等の [回復動作] に「意図的なストップエラーの発生」を設定している場合、回復動作が実行されないことがある。	小	回復動作実行時に稀に発生する。
27	13.02 / 13.00 ～ 13.01	クラスタサービス起動時にカーネルモード LAN ハートビートリソースで初期化エラーが発生することがある。	中	ネットワークデバイスが利用可能になる前に、カーネルモードLANハートビートリソースが起動した場合に発生する。
28	13.02 / 12.00 ～ 13.01	NP発生時動作によるクラスタサービスの停止が完了しない。	中	[NP 発生時動作] に「クラスタサービス停止」を指定した場合に発生する。
29	13.02 / 13.00 ～ 13.01	複数のサーバに対する強制停止の実行が失敗することがある。	小	3 台以上のクラスタ構成において、1 台のサーバから複数のサーバに対して強制停止を実行すると稀に発生する。
30	13.02 / 9.00 ～ 13.01	clpstat コマンドでアプリケーションエラーが発生することがある。	小	グループリソースが1つも登録されていないフェイルオーバグループが設定されている環境で発生する。
31	13.02 / 13.00 ～ 13.01	クラスタサスペンド状態で Cluster WebUI や clpstat コマンドのサーバステータスが停止と表示される場合がある。	小	クラスタサスペンド状態で以下のサービスを再起動すると発生する。 - CLUSTERPRO Node Manager - CLUSTERPRO Information Base
32	13.02 / 13.00 ～ 13.01	グループリソースやモニタリソースのステータス表示が不正になる場合がある。	小	OS起動時のクラスタサービスの内部処理で問題が発生した場合に発生する。
33	13.02 / 13.00 ～ 13.01	Cluster WebUI や clpstat コマンドで強制停止リソースを使用していないサーバのステータスが正しく表示されない。	小	3 台以上のクラスタ構成において、強制停止を使用しない設定をしたサーバが存在する場合に発生する。
34	13.02 / 9.00 ～ 13.01	OS 起動時 または OS シャットダウン時に STOP エラー が発生することがある。	中	OS 起動時 または OSシャットダウン時にごく稀に発生する場合がある。
35	13.02 / 9.00 ～ 13.01	CVE-2022-34822～34823 の脆弱性により以下の可能性がある。 - 任意のファイルを読み取られる - 任意のコードを実行される	大	悪意のある第三者によって細工された CLUSTERPRO の内部プロトコルに反するパケットを、CLUSTERPRO の特定のプロセスが受信した場合に発生する。
36	13.10 / 12.20 ～ 13.02	CLUSTERPRO Information Base サービスが異常終了することがある。	小	クラスタシャットダウンを実行した際に稀に発生することがある。
37	13.10 / 13.00 ～ 13.02	clpnm.exe プロセスが異常終了し、OSが再起動する場合がある。	中	ごく稀に発生することがある。
38	13.10 / 13.00 ～ 13.02	クラスタサービス起動後、ハートビート異常のアラートが出力される場合がある。	小	クラスタサービス起動後、稀に発生することがある。
39	13.10 / 12.00 ～ 13.02	ライセンスファイルが破損しクラスタが起動できないことがある。	小	クラスタ起動中にサーバが電源断した場合に稀に発生することがある。
40	13.10 / 12.00 ～ 13.02	期限付きライセンスの期限終了後、製品版ライセンスではなく期限付きライセンスが優先されて Active になることがある。	小	期限付きライセンスの期限が終了する際に、未使用の期限付きライセンスと製品版ライセンスが登録されている場合に発生する。
41	13.10 / 13.00 ～ 13.02	BMC強制停止リソースのステータスが異常になる。	小	iLO 共有ネットワークポートを有効にしている場合に発生する。
42	13.10 / 9.00 ～ 13.02	クラスタリジュームに失敗しクラスタが異常終了することがある。	中	名前が 1 文字の監視リソースがあり、それと同じタイプの監視リソースを複数登録した環境で、クラスタサスペンド・リジュームを繰り返し実行すると発生する。
43	13.10 / 13.00 ～ 13.02	サーバシャットダウン時にサーバダウン通知が送信されない場合がある。	小	サーバシャットダウン時に稀に発生することがある。
44	13.10 / 12.10 ～ 13.02	モニタリソースの回復スクリプトが実行されない場合がある。	小	Cluster WebUI で、[回復動作前にスクリプトを実行する] を ON にした後、スクリプトの編集を行わない場合またはスクリプトの変更と他の変更を同時におこなう場合に発生する。
45	13.10 / 9.00 ～ 13.02	常時監視に設定した監視リソースが動作しないことがある。	小	「監視タイミング」を活性時に設定した監視リソースを、常時に設定変更した場合に発生する。
46	13.10 / 9.00 ～ 13.02	サービスリソースまたはサービス監視リソースの[サービス名]に対象サービスのサービス表示名を設定すると監視処理に失敗することがある。	中	サービス表示名からサービス名を取得する処理に失敗した場合に発生する。
47	13.10 / 11.10 ～ 13.02	CIFS監視リソースが誤って監視結果を正常と判定する。	小	CIFS 監視リソースの初回監視時に発生する。
48	13.10 / 12.10 ～ 13.02	JVM監視リソースの調整プロパティで[Metaspace]の使用量のしきい値の設定ができない。	小	常に発生する。
49	13.10 / 9.00 ～ 13.02	HTTP監視リソースの接続可能なホスト名の名前解決に失敗することがある。	小	接続先にIPアドレスではなくホスト名を指定した場合に発生することがある。
50	13.10 / 13.00 ～ 13.02	Disk NP 解決リソースを複数設定している場合に、クラスタリジューム時にエラーメッセージが出力されることがある。	小	タイミングにより発生することがある。
51	13.10 / 12.20 ～ 13.02	clpstat コマンドの表示が実行サーバごとに異なることがある。	小	クラスタサービスが停止しているサーバ上でコマンドを実行した場合に発生することがある。
52	13.10 / 12.30 ～ 13.02	clpcfset コマンドで作成したクラスタ構成情報のXML属性値が正しくないことがある。	小	clpcfset コマンドで id 属性ノードを追加した場合に発生する。
53	13.10 / 13.00 ～ 13.02	clpcfset コマンドで作成したクラスタ構成情報のオブジェクト数が正しくないことがある。	小	強制停止リソースを含むクラスタ構成情報に対してclpcfset コマンドで追加・削除した場合に発生する。
54	13.10 / 13.00 ～ 13.02	clpcfadm.py コマンドが正しく実行出来ないことがある。	小	Cluster WebUI でフェイルオーバグループをすべて削除したクラスタ構成情報に対してclpcfadm.pyコマンドを実行した場合に発生する。
55	13.10 / 13.00 ～ 13.02	clpcfadm.py コマンドで不正な監視リソースが設定できることがある。	小	clpcfadm.py コマンドで監視リソースを追加する時、監視リソースタイプに jra と指定すると発生する。
56	13.10 / 13.00 ～ 13.02	clpcfadm.py コマンドで作成したクラスタ構成情報のリソースの活性・非活性タイムアウト値が正しくないことがある。	小	clpcfadm.py コマンドでリソースの活性・非活性タイムアウト値の計算を要するパラメータを変更した場合に発生する。
57	13.10 / 12.20 ～ 13.02	RESTful API を使用したクラスタの状態取得が失敗することがある。	小	CLUSTERPRO Information Base サービスを再起動した場合に発生することがある。
58	13.10 / 12.20 ～ 13.02	RESTful API で取得したクラスタのステータスと実際のステータスに不整合が発生することがある。	小	他サーバとの通信が切断した状態でステータスを取得すると発生することがある。
59	13.10 / 12.20 ～ 13.02	RESTful API で情報取得ができない場合がある。	小	操作系の API を実行した直後に情報取得系の API を実行すると稀に発生する。
60	13.10 / 12.22 ～ 13.02	RESTful API のグループ情報取得にて異常発生時のレスポンスが不正な場合がある。	小	クラスタサーバで内部エラーが発生した場合に発生することがある。
61	13.10 / 12.00 ～ 13.02	複数のミラーディスクリソースまたはハイブリッドディスク リソースを登録した構成で Cluster WebUI の表示が遅延することがある。	小	複数のリソースでミラー復帰が行われる場合に発生することがある。
62	13.10 / 12.00 ～ 13.02	Cluster WebUI でミラー復帰の中断が失敗することがある。	小	ミラー復帰を実行した Cluster WebUI とは別のブラウザから接続して中断した場合、または、ミラー復帰実行中にブラウザをリロードした場合に発生する。
63	13.10 / 12.10 ～ 13.02	Cluster WebUI のクラスタ作成ウィザードでクラスタを生成する際、[管理用IPアドレス] に対応するフローティング IP 監視リソースが自動登録されない。	小	クラスタ作成ウィザードで [管理用 IP アドレス] を登録した場合に発生する。
64	13.10 / 12.30 ～ 13.02	Cluster WebUI によるクラウド環境情報の取得が失敗することがある。	小	Proxy サーバを経由して Cluster WebUI に接続した場合に発生する。
65	13.10 / 12.00 ～ 13.02	Cluster WebUI の設定モードで Azure DNS リソースの [TTL] を変更してもレコードに反映されない。	小	常に発生する。
66	13.10 / 12.10 ～ 13.02	Cluster WebUI でリソース名などの文字列の設定において、2 バイト以上連続したスペースが 1 バイトに短縮される。	小	2 バイト以上連続したスペースを設定した状態で、クラスタ構成情報の設定変更をおこなうと発生する。
67	13.10 / 12.10 ～ 13.02	Cluster WebUI で Ping NP解決リソースのグループを追加する際に、グループ一覧の表示内容が不正になる場合がある。	小	Ping NP解決リソースのグループ一覧に複数のグループを登録している場合に発生することがある。
68	13.11 / 12.20 ～ 13.10	構成情報の反映に失敗することがある。	小	Cluster WebUI を使用して構成情報の反映を繰り返すと発生することがある。
69	13.11 / 12.30 ～ 13.10	クラスタ動作が無効化されることがある。	小	CPU ライセンスと仮想マシンライセンスが混在する環境で発生する。
70	13.11 / 13.00 ～ 13.10	CLUSTERPRO サービスの起動時にフェイルオーバグループが起動しないことがある。	中	サーバを 1 台ずつ CLUSTERPRO サービスの停止をおこなった後、CLUSTERPRO サービスの起動をおこなった際に発生することがある。
71	13.11 / 11.30 ～ 13.10	フェイルオーバグループの [起動可能なサーバ] の設定を変更した場合に適切な反映方法が要求されない。	小	必ず発生する。
72	13.11 / 11.10 ～ 13.10	SQL Server 監視リソースが異常を検出しないことがある。	小	[監視レベル] を 0 に設定すると発生する。
73	13.11 / 13.10	メール通報機能が動作しないことがある。	小	13.02 以前のバージョンでメール通報機能を設定している状態で 13.10 にバージョンアップした場合に発生する。
74	13.11 / 12.20 ～ 13.10	ハートビートのステータスが不正になることがある。	小	複数のクラスタサーバに Cluster WebUI を接続している、または、複数のクラスタサーバ上で clpstat コマンドを実行した場合に、発生することがある。
75	13.11 / 13.00 ～ 13.10	グループリソースのステータスが不正になることがある。	小	片サーバのみ CLUSTERPRO サービスを再起動した場合に発生することがある。
76	13.11 / 13.00 ～ 13.10	ESMPRO/ARC との連携時に共有ディスクの電源オンを待ち合わせる処理が動作しない。	小	クラスタ起動時に発生する。
77	13.11 / 9.00 ～ 13.10	クラスタ構成情報の反映に失敗し、CLUSTERPRO 関連サービスが起動しない場合がある。	小	構成情報反映時にごく稀に発生することがある。
78	13.11 / 13.00	Cluster WebUI の設定モードで、サービス監視リソースを登録できない場合がある。	小	グループリソースを登録していない状態でサービス監視リソースを登録した場合に発生する。
79	13.12 / 13.11	クラスタサーバのステータスが不正になり、クラスタを起動できないことがある。	中	クラスタサービス停止後に発生することがある。
80	13.12 / 9.00 ～ 13.11	フェイルオーバグループの移動を繰り返すとミラーディスクコネクト通信が切断することがある。	小	フェイルオーバグループの移動を短い間隔で実行すると発生することがある。
81	13.12 / 13.10 ～ 13.11	ハイブリッドディスクリソースを登録したフェイルオーバグループのフェイルオーバが失敗することがある。	小	[ミラーブレイク状態でのフェイルオーバを指定した時間許容する] を有効にし、フェイルオーバ先サーバグループのカレントサーバ以外にフェイルオーバすると発生する。
82	13.12 / 13.00 ～ 13.11	モニタリソースの回復動作実行時に再起動回数リセットのアラートが出力されることがある。	小	モニタリソースが以下のいずれかの回復動作を実行すると発生する。 - クラスタサービス停止と OS シャットダウン - クラスタサービス停止と OS 再起動 - 意図的なストップエラーの発生
83	13.12 / 9.00 ～ 13.11	ネットワークパーティションが発生すると、CLUSTERPRO Node Manager サービス (clpnm.exe) が異常終了し、STOP エラーが発生することがある。	中	以下のすべての条件を満たした場合に稀に発生する。 - Disk 方式の NP 解決リソースが設定されている - マスタサーバ以外のサーバである - ネットワークパーティションが発生する
84	13.12 / 13.10 ～ 13.11	HTTPS で Cluster WebUI に接続すると、画面が表示されないことがある。	小	OpenSSL 3.0 以降の場合に稀に発生することがある。
85	13.12 / 12.30 ～ 13.11	Cluster WebUI の操作モードで、特定のリソースの設定値が表示ができない。また、clpstat コマンドで、特定のリソースの設定情報の表示が失敗する。	小	以下のいずれかの設定項目を最大長にした場合に発生する。 - AWS セカンダリ IP リソース リソース名 (31 文字) - AWS 仮想 IP リソース リソース名 (31 文字) - Google Cloud DNS リソース リソース名 (31 文字) - Google Cloud DNS リソース ゾーン名 (63 文字) - Google Cloud DNS リソース DNS 名 (253 文字)
86	13.12 / 9.00 ～ 13.11	CVE-2023-39544～39548 の脆弱性により以下の可能性がある。 - 任意のコードを実行される - 任意のファイルをアップロードされる - CLUSTERPRO のクラスタ構成情報ファイルを読み取られる	大	悪意のある第三者によって細工された CLUSTERPRO の内部プロトコルに反するパケットを、CLUSTERPRO の特定のプロセスが受信した場合に発生する。
87	13.20 / 12.20 ～ 13.12	CLUSTERPRO Information Base サービスが異常終了することがある。	小	サーバを削除したクラスタ構成情報をアップロードする際に発生することがある。
88	13.20 / 11.00 ～ 13.12	CLUSTERPRO Transaction サービスが異常終了し、OS が再起動することがある。	小	CLUSTERPRO Transaction サービス起動時に初期化処理で失敗した場合に発生する。
89	13.20 / 12.20 ～ 13.12	OS 起動時に CLUSTERPRO API サービスのエラーログが出力されることがある。	小	クラスタを未構築の状態で OS 再起動すると発生する。
90	13.20 / 9.00 ～ 13.12	CLUSTERPRO が正常に動作しない。	大	CLUSTERPRO をインストールした状態でシステムロケールを日本語から日本語以外に変更し、CLUSTERPRO を再インストールすると発生する。
91	13.20 / 13.00 ～ 13.12	クラスタサービスの起動に失敗することがある。	小	クラスタサービスが停止した直後にクラスタサービスを起動すると発生することがある。
92	13.20 / 9.00 ～ 13.12	クラスタサービス停止時に緊急シャットダウンが発生することがある。	中	クラスタサービス停止に 1 時間以上かかると発生する。
93	13.20 / 9.00 ～ 13.12	クラスタサービスのプロセス (clprc.exe) が異常終了することがある。	中	活性時監視のモニタリソースの停止処理が遅延した際に、稀に発生する。
94	13.20 / 9.00 ～ 13.12	監視異常によりリソース再起動、またはフェイルオーバが実行された時、停止していたリソースも起動される。	小	リソースの活性異常時の最終動作が「何もしない (次のリソースを活性しない)」に設定されているリソースが起動失敗した状態で、監視異常による回復動作がおこなわれた場合に発生する。
95	13.20 / 12.30 ～ 13.12	停止しているリソースが、サーバダウンによるフェイルオーバ時に起動することがある。	小	手動起動に設定されたリソースが、クラスタ起動後に一度も起動したことのない状態で、サーバダウンによるフェイルオーバが発生すると発生する。
96	13.20 / 9.00 ～ 13.11	ミラーディスクコネクト通信が切断することがある。	中	フェイルオーバグループの移動を短時間で繰り返すと稀に発生することがある。
97	13.20 / 9.00 ～ 13.12	仮想コンピュータ名リソースの停止時にアプリケーションエラーが発生し、停止に失敗することがある。	中	タイミングによって稀に発生する。
98	13.20 / 12.00 ～ 13.12	ダイナミック DNS リソースの起動時に不要なエラーメッセージが出力されることがある。	小	以下の設定がされている場合に出力される。 - 「登録した IP アドレスを削除する」がオン - サーバ別設定している
99	13.20 / 12.00 ～ 13.12	Azure DNS リソースのアラートログが正しく出力されないことがある。	小	エラーの種類によって発生する。
100	13.20 / 12.10 ～ 13.12	監視タイミングを活性時に設定しているモニタリソースが、対象リソースが非活性状態であるにもかかわらず監視をおこなうことがある。	小	リソースの再起動を繰り返すと発生することがある。
101	13.20 / 12.20 ～ 13.12	モニタリソース停止時に不正なアラートログ (監視 <モニタリソース名> の停止に失敗しました) が出力されることがある。	小	モニタリソース停止時に稀に発生することがある。
102	13.20 / 12.30 ～ 13.12	以下の監視リソースで、監視対象に異常がない場合でも異常と判断することがある。 - AWS 仮想 IP 監視リソース - AWS セカンダリ IP 監視リソース - Google Cloud DNS 監視リソース	中	内部処理で異常になった場合に発生する。
103	13.20 / 12.00 ～ 13.12	Azure DNS 監視リソースの監視処理が正常に動作しない。	小	Azure CLI のバージョンが 2.50.0 以降の環境で発生する。
104	13.20 / 11.10 ～ 13.12	不要なイベントログが出力されることがある。	小	以下のいずれかの設定を行っている場合に発生する。 - フローティング IP 監視リソースの [NIC Link Up/Down を監視する] が"オン" - NIC Link Up/Down 監視リソースを設定している
105	13.20 / 11.35 ～ 13.12	ハートビートリソースがタイムアウトを誤検知することがある。	中	ハートビートの [タイムアウト値] が 400 秒以上の場合に発生することがある。
106	13.20 / 12.10 ～ 13.12	DISK ネットワークパーティション解決リソースが複数設定できるようになっている。	小	常に発生する。
107	13.20 / 13.10 ～ 13.12	Azure 強制停止リソースが正常に動作しないことがある。	小	3 ノード以上の環境で Azure 強制停止の [利用サーバ] の設定を変更した場合に発生することがある。
108	13.20 / 13.10 ～ 13.12	Azure 強制停止リソースによるインスタンスの再起動に時間がかかることがある。	小	[強制停止アクション] を reboot に設定した場合に発生する。
109	13.20 / 13.10 ～ 13.12	クラウド環境の強制停止リソースでタイムアウトが発生し定期チェックに失敗することがある。	小	システムの高負荷時に発生することがある。
110	13.20 / 13.10 ～ 13.12	Amazon CloudWatch 連携機能の実行に失敗することがある。	小	2 つ以上のモニタリソースで [監視処理時間メトリクスを送信する] を"オン"にした場合に発生する。
111	13.20 / 13.00 ～ 13.12	clpcfadm.py コマンドを使用してクラスタ構成情報を作成した場合に以下が発生することがある。 - 指定した値と異なる値が設定される - 指定した値が設定できない	小	特定のパラメータを設定した場合に発生する。
112	13.20 / 13.10 ～ 13.12	ログ収集で Cluster WebUI の操作ログが収集できないことがある。	小	以下の場合に発生する。 - [ログ出力先] のパスにシンボリックリンクが含まれる - [ログ出力先] のパスの末尾に \ が付与されている
113	13.20 / 9.00 ～ 13.12	Cluster WebUI から設定の反映をおこなった際、認証エラーとなり必要なサービスの再起動が実行されないことがある。	小	クラスタパスワード方式のパスワードを新規設定 (または、変更) とサービス再起動を伴う変更を同時におこなうと発生する。
114	13.20 / 12.00 ～ 13.12	Cluster WebUI から強制ミラー復帰が実行できないことがある。	小	ハイブリッドディスク構成で、サーバステータスが不明なサーバが存在すると発生する。
115	13.20 / 9.00 ～ 13.12	WebManager サーバの HTTP レスポンスヘッダで適切な文字エンコーディングが指定されていない。	小	Cluster WebUI を使用する際に必ず発生する。
116	13.20 / 13.00 ～ 13.12	RESTful API の実行が失敗することがある。	小	OS 起動直後に RESTful API を実行すると発生することがある。
117	13.20 / 13.00 ～ 13.12	ESMPRO/AC 連携時、アラートログに不要なエラーメッセージが表示されることがある。	小	電源障害時に ESMPRO/AC 側から複数のサーバでクラスタシャットダウンが同時に実行されると発生することがある。
118	13.20 / 12.00 ～ 13.12	Cluster WebUI のアラートログで表示内容が不正になることがある。	小	破損したアラートログを Cluster WebUI で表示した場合に発生する。
119	13.20 / 13.00 ～ 13.12	Cluster WebUI の設定モードで依存関係図が表示できない場合がある。	小	リソース数が極端に多い場合に発生する。
120	13.20 / 12.20 ～ 13.12	Cluster WebUI の設定モードでサーバを削除した構成情報をアップロードする際に Cluster WebUI が操作できなくなることがある。	小	削除対象のサーバでフェイルオーバグループが 2 個以上起動している場合に発生する。
121	13.20 / 12.10 ～ 13.12	Cluster WebUI の設定モードで、ネットワークパーティション解決リソースの調整プロパティを設定し適用ボタンを押した後、クラスタのプロパティを [キャンセル] ボタンで閉じると、値が保存されない。	小	ネットワークパーティション解決調整プロパティの値を変更後、クラスタのプロパティを [キャンセル] ボタンで閉じると発生する。
122	13.20 / 12.10 ～ 13.12	Cluster WebUI の設定モードで、FTP 監視リソースの監視 (固有) タブにある項目 [ユーザ名] が入力必須項目となっていない。	小	常に発生する。
123	13.20 / 13.00 ～ 13.12	Cluster WebUI の設定モードで、[グループのプロパティ] - [リソース一覧] タブから [リソースのプロパティ] を開いた際、[復旧動作] タブの表示が誤っている。	小	[フェイルオーバ回数のカウント単位] を、[クラスタ] に設定している場合に発生する。
124	13.20 / 12.00 ～ 13.12	Cluster WebUI の表示が遅延する。	小	ハイブリッドディスクリソースを複数登録している場合に発生することがある。
125	13.21 / 13.20	CLUSTERPRO サービス停止時に、CLUSTERPRO の特定のプロセス (clprc.exe または clpibsv.exe) でアプリケーションエラーが発生することがある。	小	CLUSTERPRO サービス停止時にごく稀に発生することがある。
126	13.21 / 12.20 ～ 13.20	CLUSTERPRO Information Baseサービスの停止に時間がかかることがある。	小	クラスタを長期間運用した状態で、CLUSTERPRO Information Baseサービスを再起動すると発生することがある。
127	13.21 / 9.00 ～ 13.12	CLUSTERPRO Web Alert サービスにおいて、不要なローカル通信がおこなわれることがある。	小	インタコネクトタブのハートビート I/F で、一部のサーバに空欄が設定されている場合に発生することがある。
128	13.21 / 12.20 ～ 13.20	Cluster WebUI にてクラスタ構成情報反映時にサービス再起動の画面が閉じないことがある。	小	反映方法として WebManager サービス再起動, Information Base サービス再起動, API サービス再起動が同時に要求される場合に発生する。
129	13.21 / 11.30 ～ 13.20	Azure ロードバランス監視リソースが監視異常になることがある。	小	フェイルオーバグループの停止処理中に、タイミングによって発生することがある。
130	13.21 / 9.00 ～ 13.20	DISK ネットワークパーティション解決リソースの停止に時間がかかることがある。	小	NP 発生時動作に「クラスタサービス停止」を設定した環境で、ネットワークパーティション解決動作によってクラスタサービスが停止されると発生することがある。
131	13.21 / 13.00 ～ 13.20	DISK ネットワークパーティション解決リソースの起動に失敗する。	小	NP 発生時動作に「クラスタサービス停止」を設定した環境で、ネットワークパーティション解決動作によってクラスタサービスが停止された後、クラスタサービスを起動すると発生する。
132	13.21 / 13.00 ～ 13.20	DISK ネットワークパーティション解決リソースでアプリケーションエラーが発生することがある。	中	DISK ネットワークパーティション解決リソース停止時にごく稀に発生することがある。
133	13.21 / 12.00 ～ 13.20	clpcfadm.py コマンドで作成した Azure DNS リソースの活性・非活性タイムアウト値が正しくないことがある。	小	clpcfadm.py コマンドで Azure DNS リソースの活性・非活性タイムアウト値の計算を要するパラメータを変更した場合に発生する。
134	13.21 / 13.20	WebManager サーバの内部ログが一部失われることがある。	小	WebManager サーバを再起動すると発生することがある。
135	13.21 / 13.20	ハイブリッドディスク構成の環境でサーバグループ毎に DISK ネットワークパーティション解決リソースを設定できない。	小	常に発生する。
136	13.21 / －	Cluster WebUI にて、オプション製品ライセンスが必要なグループリソースやモニタリソースの設定ができないことがある。	小	試用版ライセンスで動作している環境において、試用期間内のライセンスと試用期間外のライセンスが混在して登録されていると発生することがある。
137	13.21 / 13.20	Cluster WebUI にて操作権のないユーザでログインすると認証エラーのメッセージが表示される。	小	以下のいずれかの設定を行っている場合に発生する。 - パスワードによって接続を制御する - クライアント IP アドレスによって接続を制御する
138	13.21 / 13.20	以下のアラートログが出力され、調査ログがダウンロードできない。 モジュール : trnsv イベントID : 2301	小	「クライアント IP アドレスによって接続を制御する」の設定を有効にした環境で発生する。

6. 注意制限事項

本章では、注意事項や既知の問題とその回避策について説明します。

本章で説明する項目は以下の通りです。

• 6.1. システム構成検討時

• 6.2. CLUSTERPRO インストール前

• 6.3. CLUSTERPRO の構成情報作成時

• 6.4. CLUSTERPRO 運用後

• 6.5. CLUSTERPRO の構成変更時

• 6.6. CLUSTERPRO バージョンアップ時

• 6.7. 旧バージョンとの互換性

6.1. システム構成検討時

HW の手配、システム構成、共有ディスクの構成時に留意すべき事項について説明します。

6.1.1. ミラーディスク/ハイブリッドディスクの要件について

• ダイナミックディスクは使用できません。ベーシックディスクを使用してください。

• ミラーディスク/ハイブリッドディスク用のパーティション (データパーティションとクラスタパーティション) を NTFS フォルダにマウントして使用することはできません。

• ミラーディスクリソース/ハイブリッドディスクリソースを使用するには、ミラー用のパーティション (データパーティションとクラスタパーティション) が必要です。

• ミラー用のパーティションのディスク上の配置には特に制限はありませんが、データパーティションのサイズはバイト単位で完全に一致している必要があります。またクラスタパーティションには 1024MiB 以上の容量が必要です。

• データパーティションを拡張パーティション上の論理パーティションとして作成する場合は、両サーバとも論理パーティションにしてください。基本パーティションと論理パーティションでは同じサイズを指定しても実サイズが若干異なることがあります。

• 負荷分散のため、クラスタパーティションとデータパーティションは別のディスク上に作成することを推奨します （同じディスク上に作成しても動作に支障はありませんが、非同期ミラーの場合やミラーリングを中断している状態での書き込み性能が若干低下します）。

• ミラーリソースでミラーリングするデータパーティションを確保するディスクは、両サーバでディスクのタイプを同じにしてください。

  例)

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

• [ディスクの管理] などで確保したパーティションサイズは、ディスクのシリンダあたりのブロック (ユニット) 数でアラインされます。このため、ミラー用のディスクとして使用するディスクのジオメトリがサーバ間で異なると、データパーティションのサイズを完全に一致させることができない場合があります。このような問題を避けるため、データパーティションを確保するディスクは、RAID構成なども含め両サーバでHW構成を一致させることを推奨します。

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

• RAID 構成のディスクをミラーリングする場合、ディスクアレイコントローラのキャッシュをWRITE THRU にすると書き込み性能の低下が大きくなるため、WRITE BACK での使用をお勧めします。ただし、WRITE BACK で使用する場合は、バッテリーを搭載したディスクアレイコントローラを用いるか、UPS を併用する必要があります。

• OS のページファイルがあるパーティションは、ミラーリングできません。

6.1.2. IPv6 環境について

下記の機能は IPv6 環境では使用できません。

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS DNS リソース

• Azure プローブポートリソース

• Azure DNS リソース

• Google Cloud 仮想 IP リソース

• Google Cloud DNS リソース

• Oracle Cloud 仮想 IP リソース

• Oracle Cloud DNS リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS DNS 監視リソース

• Azure プローブポート監視リソース

• Azure ロードバランス監視リソース

• Azure DNS 監視リソース

• Google Cloud 仮想 IP 監視リソース

• Google Cloud ロードバランス監視リソース

• Google Cloud DNS 監視リソース

• Oracle Cloud 仮想 IP 監視リソース

• Oracle Cloud ロードバランス監視リソース

• Oracle Cloud DNS 監視リソース

下記の機能はリンクローカルアドレスを使用できません。

• カーネルモードLANハートビートリソース

• ミラーディスクコネクト

• PINGネットワークパーティション解決リソース

• FIPリソース

• VIPリソース

6.1.3. ネットワーク構成について

NAT環境等のように、自サーバのIPアドレスおよび相手サーバのIPアドレスが、各サーバで異なるような構成においては、クラスタ構成を構築/運用できません。

以下の図は、NAT装置を間に挟んで異なるネットワークに接続された2台のサーバを示しています。

ここで、NAT装置の設定が "External network から 10.0.0.2宛のパケットは、Internal networkにフォワード" になっていたとします。

しかし、この環境でServer 1と Server 2でクラスタを構築することを考えると、各サーバで異なるネットワークのIPアドレスを指定することになります。

このように各サーバが異なるサブネットに配置された環境では、クラスタを正しく構築・運用することはできません。

図 6.1 クラスタを構成できない環境の例

• Server 1でのクラスタ設定

  • 自サーバ: 10.0.0.1

  • 相手サーバ: 10.0.0.2

• Server 2でのクラスタ設定

  • 自サーバ: 192.168.0.1

  • 相手サーバ: 10.0.0.1

6.1.4. 共有ディスクの要件について

• ダイナミックディスクは使用できません。ベーシックディスクを使用してください。

• 共有ディスク用のパーティション (ディスクハートビート用パーティション、ディスクリソース用切替パーティション) を NTFS フォルダにマウントして使用することはできません。

• ソフトウェア RAID (ストライプセット、ミラーセット、パリティ付ストライプセット) やボリュームセットは使用できません。

6.1.5. ミラーディスク/ハイブリッドディスクの write 性能について

ミラーディスクリソース/ハイブリッドディスクリソースのディスクミラーリングには同期ミラーと非同期ミラーの 2 種類の方式があります。

同期ミラーの場合、ミラーリング対象のデータパーティションへの書き込み要求毎に、両サーバのディスクへの書き込みを実施し、その完了を待ち合わせます。各サーバへの書き込みは並行して実施されますが、他サーバのディスクへの書き込みはネットワークを介して実施されるため、ミラーリングしない通常のローカルディスクに比べ書き込み性能が低下します。特にネットワークの通信速度が低く遅延が大きい遠隔クラスタ構成などの場合は大幅に性能が低下することになります。

非同期ミラーの場合、自サーバへの書き出しは即時実行しますが、他サーバへの書き出しは一旦ローカルキューに保存し、バックグラウンドで書き出します。他サーバへの書き出しの完了を待ち合わせないため、ネットワーク性能が低い場合も書き込み性能が大きく低下することはありません。ただし、非同期ミラーの場合も書き込み要求毎に更新データをキューに保存するため、ミラーリングしない通常のローカルディスクや共有ディスクに比べると、書き込み性能が低下します。このため、ディスクへの書き込み処理に高いスループットが要求されるシステム(更新系が多いデータベースシステムなど) には共有ディスクの使用を推奨します。

また、非同期ミラーの場合、書き込み順序は保証されますが、現用系サーバがダウンした場合に最新の更新分が失われる可能性があります。このため、障害発生直前の情報を確実に引き継ぐ必要がある場合は、同期ミラーか共有ディスクを用いる必要があります。

6.1.6. 非同期ミラーの履歴ファイルについて

非同期モードのミラーディスク/ハイブリッドディスクでは、メモリ上のキューに記録しきれない書き込みデータは、履歴ファイル格納フォルダとして指定されたフォルダに履歴ファイルとして一時的に記録されます。この履歴ファイルは、履歴ファイルのサイズ制限を設定していない場合、指定されたフォルダに制限なく書き出されます。このような設定の場合、回線速度が業務アプリケーションのディスク更新量に比べて低すぎると、リモートサーバへの書き込み処理がディスク更新に追いつかず、履歴ファイルでディスクが溢れてしまいます。このため、遠隔クラスタ構成でも業務 AP のディスク更新量に合わせて十分な速度の通信回線を確保する必要があります。

また、長時間の通信遅延や、ディスク更新の連続発生などにより、履歴ファイル格納フォルダが溢れた場合に備え、履歴ファイルの書き出し先に指定するドライブには十分な空き容量を確保し、履歴ファイルサイズ制限を設定するか、システムドライブとは別のドライブを指定する必要があります。

6.1.7. 複数の非同期ミラー間のデータ整合性について

非同期モードのミラーディスク/ハイブリッドディスクでは、現用系のデータパーティションへの書き込みを、同じ順序で待機系のデータパーティションにも実施します。

ミラーディスクの初期構築中やミラーリング中断後の復帰 （コピー） 中以外は、この書き込み順序が保証されるため、待機系のデータパーティション上にあるファイル間のデータ整合性は保たれます。

しかし、複数のミラーディスク/ハイブリッドディスクリソース間では書き込み順序が保証されませんので、例えばデータベースのデータベースファイルとジャーナル （ログ） ファイルのように、一方のファイルが他方より古くなるとデータの整合性が保てないファイルを複数の非同期ミラーディスクに分散配置すると、サーバダウン等でフェイルオーバした際に業務アプリケーションが正常に動作しなくなる可能性があります。

このため、このようなファイルは必ず同一の非同期ミラーディスク/ハイブリッドディスク上に配置してください。

6.1.8. マルチブートについて

他のブートディスクで起動すると、ミラーや共有ディスクのアクセス制限が外れてしまい、ミラーディスクの整合性保証や共有ディスクのデータ保護ができなくなるため、これらのリソースを使用している場合はマルチブートを使用しないでください。

6.1.9. JVM 監視リソースについて

• 同時に監視可能なJava VMは最大25個です。同時に監視可能なJava VMとはCluster WebUI([監視(固有)]タブ-[識別名])で一意に識別するJava VM数のことです。

• Java VMとJVM監視リソース間のコネクションはSSLには対応していません。

• スレッドのデッドロックは検出できない場合があります。これは、Java VMの既知で発生している不具合です。詳細は、OracleのBug Databaseの「Bug ID: 6380127 」を参照してください。

• JVM監視リソースが監視できるJava VMは、JVM監視リソースが動作中のサーバと同じサーバ内のみです。

• Cluster WebUI (クラスタプロパティ-[JVM監視]タブ-[Javaインストールパス])で設定したJavaインストールパスは、クラスタ内のサーバにおいて、共通の設定となります。JVM監視が使用するJava VMのバージョンおよびアップデートは、クラスタ内のサーバにおいて、同じものにしてください。

• Cluster WebUI (クラスタプロパティ-[JVM監視]タブ-[接続設定]ダイアログ-[管理ポート番号])で設定した管理ポート番号は、クラスタ内のサーバにおいて、共通の設定となります。

• x86_64版OS上においてIA32版の監視対象のアプリケーションを動作させている場合、監視を行うことはできません。

• Cluster WebUI (クラスタプロパティ-[JVM監視]タブ-[最大Javaヒープサイズ])で設定した最大Javaヒープサイズを3000など大きな値に設定すると、JVM監視リソースが起動に失敗します。システム環境に依存するため、システムのメモリ搭載量を元に決定してください。

6.1.10. ネットワーク警告灯の要件について

• 「警子ちゃんミニ」、「警子ちゃん 4G」を使用する場合、警告灯にパスワードを設定しないで下さい。

• 音声ファイルの再生による警告を行う場合、あらかじめ音声ファイル再生に対応したネットワーク警告灯に音声ファイルを登録しておく必要があります。

  音声ファイルの登録に関しては、各ネットワーク警告灯の取扱説明書を参照して下さい。

• ネットワーク警告灯にクラスタ内のサーバからの rsh コマンド実行を許可するように設定してください。

6.1.11. Cluster WebUI について

Cluster WebUI を使用する際は、よりセキュアに使用するため、通信方式として HTTPS の使用を推奨しています。

設定方法については『リファレンスガイド』 - 「パラメータの詳細」 - 「クラスタプロパティ」 - 「WebManager タブ」 および 「暗号化 タブ」を参照ください。

6.2. CLUSTERPRO インストール前

OS のインストールが完了した後、OS やディスクの設定を行うときに留意して頂きたいことです。

6.2.1. ファイルシステムについて

OS をインストールするパーティション、共有ディスクのディスクリソースとして使用するパーティション、ミラーディスク/ハイブリッドディスクリソースのデータパーティションのファイルシステムは NTFS を使用してください。

6.2.2. 通信ポート番号

CLUSTERPRO では、デフォルトで以下のポート番号を使用します。このポート番号については Cluster WebUI での変更が可能です。これらのポート番号には、CLUSTERPRO 以外のプログラムからアクセスしないようにしてください。

下記ポート番号には、CLUSTERPRO 以外のプログラムからアクセスしないようにしてください。

サーバにファイアウォールの設定を行う場合には、下記のポート番号にアクセスできるようにしてください。

CLUSTERPRO インストール後に clpfwctrl コマンドでファイアウォールの設定を行うことができます。詳細は『リファレンスガイド』 - 「CLUSTERPRO コマンドリファレンス」 - 「ファイアウォールの規則を追加する (clpfwctrl コマンド)」を参照してください。 また、clpfwctrl コマンドで設定を行うポートについては、以下の表の clpfwctrl 欄に ✓ が記載されているポートと「ICMPv4」、「ICMPv6」のプロトコルとなります。

クラウド環境の場合は、インスタンス側のファイアウォール設定の他に、クラウド基盤側のセキュリティ設定においても、下記のポート番号にアクセスできるようにしてください。

• ［サーバ・サーバ間］

  From		To		備考	clpfwctrl
  サーバ	自動割り当て 5	サーバ	29001/TCP	内部通信	✓
  サーバ	自動割り当て	サーバ	29002/TCP	データ転送	✓
  サーバ	自動割り当て	サーバ	29003/UDP	アラート同期	✓
  サーバ	自動割り当て	サーバ	29004/TCP	ディスクエージェント間通信	✓
  サーバ	自動割り当て	サーバ	29005/TCP	ミラードライバ間通信	✓
  サーバ	自動割り当て	サーバ	29008/TCP	クラスタ情報管理	✓
  サーバ	自動割り当て	サーバ	29010/TCP	Restful API 内部通信	✓
  サーバ	29106/UDP	サーバ	29106/UDP	ハートビート	✓
  サーバ	icmp	サーバ	icmp	FIP/VIPリソースの重複確認

  5

  自動割り当てでは、その時点で使用されていないポート番号が割り当てられます。

• ［サーバ・クライアント間］

  From		To		備考	clpfwctrl
  Restful API クライアント	自動割り当て	サーバ	29009/TCP	http通信	✓

• ［サーバ・Cluster WebUI 間］

  From		To		備考	clpfwctrl
  Cluster WebUI	自動割り当て	サーバ	29003/TCP	http通信	✓

• ［その他］

  From		To		備考	clpfwctrl
  サーバ	自動割り当て	ネットワーク警告灯	各製品のマニュアルを参照	ネットワーク警告灯制御
  サーバ	自動割り当て	サーバのBMCのマネージメントLAN	623/UDP	BMC制御 (強制停止)
  サーバ	自動割り当て	Witness サーバ	Cluster WebUI で設定した通信ポート番号	Witness ハートビートリソースの接続先ホスト
  サーバ	自動割り当て	監視先	icmp	IP監視リソース
  サーバ	自動割り当て	監視先	icmp	Ping方式ネットワークパーティション解決リソースの監視先
  サーバ	自動割り当て	監視先	Cluster WebUI で設定した通信ポート番号	HTTP 方式ネットワークパーティション解決リソースの監視先
  サーバ	自動割り当て	サーバ	Cluster WebUI で設定した管理ポート番号	JVM監視リソース	✓
  サーバ	自動割り当て	監視先	Cluster WebUI で設定した接続ポート番号	JVM監視リソース
  サーバ	自動割り当て	サーバ	Cluster WebUI で設定したプローブポート	Azure プローブポートリソース	✓
  サーバ	自動割り当て	AWS リージョンエンドポイント	443/tcp	AWS Elastic IP リソース AWS 仮想 IP リソース AWS セカンダリ IP リソース AWS DNS リソース AWS Elastic IP 監視リソース AWS 仮想 IP 監視リソース AWS セカンダリ IP 監視リソース AWS AZ 監視リソース AWS DNS 監視リソース AWS 強制停止リソース
  サーバ	自動割り当て	Azure エンドポイント	443/tcp	Azure DNS リソース
  サーバ	自動割り当て	Azure の権威DNSサーバ	53/udp	Azure DNS 監視リソース
  サーバ	自動割り当て	サーバ	Cluster WebUI で設定したポート番号	Google Cloud 仮想 IP リソース	✓
  サーバ	自動割り当て	サーバ	Cluster WebUI で設定したポート番号	Oracle Cloud 仮想 IP リソース	✓
  サーバ	自動割り当て	Oracle Cloud エンドポイント	443/tcp	Oracle Cloud DNSリソース Oracle Cloud DNS 監視リソース OCI 強制停止リソース

AWS環境 の場合は、ファイアウォールの設定の他にセキュリティグループ設定も変更してください。

JVM監視では以下の2つのポート番号を使用します。

• 管理ポート番号はJVM監視リソースが内部で使用するためのポート番号です。Cluster WebUI の[クラスタプロパティ]-[JVM監視]タブ-[接続設定] ダイアログで設定します。詳細については『リファレンスガイド』の「パラメータの詳細」を参照してください。

• 接続ポート番号は監視先(WebLogic Server, WebOTX)のJava VM と接続するためのポート番号です。Cluster WebUI の該当するJVM監視リソース名の[プロパティ]-[監視(固有)]タブで設定します。詳細については『リファレンスガイド』の「モニタリソースの詳細」を参照してください。

Azure プローブポートリソースの [プローブポート]、Google Cloud 仮想 IP リソースの [ポート番号]、Oracle Cloud 仮想 IP リソースの [ポート番号] は、ロードバランサが各サーバの死活監視に使用するポート番号です。

以下のAWS関連リソースはAWS CLI を実行します。AWS CLI では上記のポート番号を使用します。

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS DNS リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS DNS 監視リソース

• AWS 強制停止リソース

Azure DNS リソースでは、Azure CLI を実行します。Azure CLI では上記のポート番号を使用します。

以下のOracle Cloud関連リソースはOCI CLI を実行します。OCI CLI では上記のポート番号を使用します。

• Oracle Cloud DNS リソース

• Oracle Cloud DNS 監視リソース

• OCI 強制停止リソース

6.2.3. 通信ポート番号の自動割り当て範囲の変更

OS が管理している通信ポート番号の自動割り当ての範囲が CLUSTERPRO が使用する通信ポート番号と重複する場合があります。

OS が管理している通信ポート番号の自動割り当ての範囲を以下の方法等により確認して、通信ポート番号が重複する場合には、CLUSTERPRO が使用する通信ポート番号と重複しないよう、CLUSTERPRO が使用するポート番号を変更するか、または OS が管理している通信ポート番号の自動割り当ての範囲を以下の方法等により変更してください。

• Windows が提供する netsh コマンドにて、自動割り当ての範囲を表示/設定します。

• OS が管理している通信ポート番号の自動割り当て範囲の確認方法

  netsh interface <ipv4|ipv6> show dynamicportrange <tcp|udp>
  

  以下に実行例を示します。

  >netsh interface ipv4 show dynamicportrange tcp
  
  プロトコル tcp の動的ポートの範囲
  ---------------------------------
  開始ポート : 49152
  ポート数 : 16384
  

  上記は、ipv4、TCP プロトコルの通信ポート番号の自動割り当ての範囲が 49152～ 68835 (ポート番号 49152 から16384 個のポートを割り当て) であることを示します。CLUSTERPRO が使用するポート番号がこの範囲内にある場合は、CLUSTERPRO が使用するポート番号を変更するか、後述の「OS が管理している通信ポート番号の自動割り当て範囲の設定方法」を実施してください。

• OS が管理している通信ポート番号の自動割り当て範囲の設定方法

  netsh interface <ipv4|ipv6> set dynamicportrange <tcp|udp> [startport=]<開始ポート番号> [numberofports=]<自動割り当て範囲>

  以下に実行例を示します。

  >netsh interface ipv4 set dynamicportrange tcp startport=10000 numberofports=1000
  

  上記は、ipv4、TCP プロトコルの通信ポート番号の自動割り当ての範囲を 10000～ 10999 (ポート番号 10000 から1000 個のポートを割り当て) に設定します。

6.2.4. ポート数不足を回避する設定について

CLUSTERPRO の構成において、多数のサーバ、多数のリソースを使用している場合、CLUSTERPRO の内部通信に使用する一時ポートが不足して、クラスタサーバとして正常に動作できなくなる可能性があります。

一時ポートとして使用できる範囲や、一時ポートが解放されるまでの時間を必要に応じて調整してください。

6.2.5. 時刻同期の設定

クラスタシステムでは、複数のサーバの時刻を定期的に同期する運用を推奨します。タイムサーバなどを使用してサーバの時刻を同期させてください。

6.2.6. 共有ディスクについて

• CLUSTERPRO によるアクセス制限を行っていない状態で、共有ディスクに接続されたサーバを複数起動すると、共有ディスク上のデータが破壊される危険があります。アクセス制限をかける前は、必ずいずれか 1 台のみ起動するようにしてください。

• ネットワークパーティション解決方式としてディスク方式を用いる場合、DISK ネットワークパーティション解決リソースが使用する 17MB 以上の RAW パーティション （ディスクハートビート用パーティション） を共有ディスク上に作成してください。

• ディスクリソースとしてサーバ間のデータ引き継ぎに使用するパーティション （切替パーティション） は NTFS でフォーマットしてください。

• 共有ディスク上の各パーティションには、全てのサーバで同一のドライブ文字を設定してください。

• 共有ディスク上のパーティション作成やフォーマットは、いずれか 1 台のサーバからのみ行います。各サーバで再作成・再フォーマットを行う必要はありません。ただし、ドライブ文字は各サーバで設定する必要があります。

• サーバの再インストール等で共有ディスク上のデータを引き続き使用する場合は、パーティションの確保やフォーマットは行わないでください。パーティションの確保やフォーマットを行うと共有ディスク上のデータは削除されます。

6.2.7. ミラーディスク用のパーティションについて

• ミラーディスクリソースの管理用パーティション (クラスタパーティション) として、1024MiB 以上の RAW パーティションを各サーバのローカルディスクに作成してください。

• ミラーリング対象のパーティション (データパーティション) を各サーバのローカルディスクに作成し、NTFS でフォーマットしてください （既存のパーティションをミラーリングする場合、パーティションを作り直す必要はありません）。

• データパーティションのサイズは、両サーバで等しくなるように設定してください。正確なパーティションサイズの確認と調整には [clpvolsz] コマンドを使用してください。

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

6.2.8. ハイブリッドディスク用のパーティションについて

• ハイブリッドディスクリソースの管理用パーティション (クラスタパーティション) として、1024MiB 以上の RAW パーティションを各サーバグループの共有ディスク （サーバグループのメンバサーバが 1 台の場合はローカルディスク） に作成してください。

• ミラーリング対象のパーティション (データパーティション) を各サーバグループの共有ディスク （サーバグループのメンバサーバが 1 台の場合はローカルディスク） に作成し、NTFS でフォーマットしてください （既存のパーティションをミラーリングする場合、パーティションを作り直す必要はありません）。

• データパーティションのサイズは、両サーバグループで等しくなるように設定してください。正確なパーティションサイズの確認と調整には [clpvolsz] コマンドを使用してください。

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

6.2.9. データパーティション上のフォルダやファイルのアクセス許可について

ワークグループ環境で、データパーティション上のフォルダやファイルにアクセス許可の設定を行う場合、そのデータパーティションにアクセスする全てのノードで、該当のユーザに対してアクセス許可を設定する必要があります。例えば server1, server2 の test というユーザに対してアクセス許可を与える場合、server1 および server2 にて test ユーザに対してアクセス許可を設定してください。

6.2.10. OS 起動時間の調整

電源が投入されてから、OS が起動するまでの時間が、下記の 2 つの時間より長くなるように調整してください6。

• 共有ディスクを使用する場合に、ディスクの電源が投入されてから使用可能になるまでの時間

• ハートビートタイムアウト時間

6

具体的な手順は、『インストール&設定ガイド』の「システム構成を決定する」 - 「ハードウェア構成後の設定」 -「システム構成を決定する」 - 「CLUSTERPRO のサービス起動時間を調整する (必須)」を参照してください。

6.2.11. ネットワークの確認

• インタコネクトやミラーディスクコネクトで使用するネットワークの確認をします。クラスタ内のすべてのサーバで確認します。

• [ipconfig] コマンドや [ping] コマンドを使用してネットワークの状態を確認してください。

  • Public LAN (他のマシンと通信を行う系)

  • インタコネクト専用 LAN (CLUSTERPRO のサーバ間接続に使用する系)

  • ミラーディスクコネクトLAN (インタコネクトと共用)

  • ホスト名

• クラスタで使用するフローティング IP リソースの IP アドレスは、OS 側への設定は不要です。

• CLUSTERPRO の設定 (ハートビートやミラーディスクコネクトなど) に IPv6 を指定している場合、NIC がリンクダウンすると、その NIC に付与されている IP アドレスが見えなくなり、CLUSTERPRO の動作に影響を与えます。下記のコマンドを実行し、メディアセンス制御をオフにしてください。

  netsh interface ipv6 set global dhcpmediasense=disabled
  

6.2.12. ESMPRO/AutomaticRunningController との連携について

ESMPRO/AutomaticRunningController (以降 ESMPRO/AC と略します) と連携動作させる場合は、CLUSTERPRO の構築/設定に次の留意事項があります。これらが満たされていないと、ESMPRO/AC との連携機能が正しく動作しないことがあります。

• ネットワークパーティション解決リソースとして、DISK 方式のリソースのみを単独で指定することはできません。DISK 方式を指定する場合は、必ず PING 方式など、他のネットワークパーティション解決方式のリソースと組み合わせて指定してください。

• ディスク TUR 監視リソースを作成する際は、[最終動作] の設定値はデフォルト (何もしない) から変更しないでください。

• ディスク RW 監視リソースを作成する際、[ファイル名] の設定値に共有ディスク上のパスを指定する場合は、[監視タイミング] の設定値はデフォルト (活性時) から変更しないでください。

• 復電後再起動した際、次のアラートが CLUSTERPROのマネージャ上にエントリされることがあります。上記の設定により、実際の動作に支障はありませんので無視してください。

  • ID:18

    モジュール名:nm

    メッセージ:リソース<DiskNPのリソース名>の起動に失敗しました。(サーバ名:xx)
  • ID:1509

    モジュール名:rm

    メッセージ:監視 <ディスクTUR監視リソース名> は異常を検出しました。 (4 : デバイスオープンに失敗しました。監視先ボリュームのディスク状態を確認してください。)

• ESMPRO/AC の設定方法、留意事項等については、『CLUSTERPRO X for Windows PPガイド』の「ESMPRO/AC」の章の記述を参照してください。

6.2.13. ipmiutil について

• 以下の機能では、BSD ライセンスのオープンソースとして公開されている IPMI Management Utilities (ipmiutil) を使用して、各サーバの BMC ファームウェアを制御します。このため、これらの機能を利用する場合は各クラスタサーバに ipmiutil をインストールする必要があります。

  • 物理マシンの強制停止機能

• 上記の機能を使用する場合、ベースボード管理コントローラー （BMC） のマネージメント用 LAN ポートの IP アドレスと OS が使用する IP アドレスの間で通信ができるように、各サーバの BMC を設定してください。サーバに BMC が搭載されていない場合や、BMC のマネージメント用のネットワークが閉塞している状態では、これらの機能は使用できません。BMC の設定方法については、各サーバのマニュアルを参照してください。

• CLUSTERPRO に ipmiutil は添付しておりません。ipmiutil の入手方法とインストール方法については『インストール&設定ガイド』 - 「システム構成を決定する」- 「ハードウェア構成後の設定」 - 「BMC と ipmiutil をセットアップする (物理マシンの強制停止機能を使用する場合は必須)」を参照してください。

• ipmiutil に関する以下の事項について、弊社は対応いたしません。ユーザ様の判断、責任にてご使用ください。

  • ipmiutil 自体に関するお問い合わせ

  • ipmiutil の動作保証

  • ipmiutil の不具合対応、不具合が原因の障害

  • 各サーバの ipmiutil の対応状況のお問い合わせ

• ご使用予定のサーバ (ハードウェア) の ipmiutil 対応可否についてはユーザ様にて事前に確認ください。ハードウェアとして IPMI 規格に準拠している場合でも、実際にはipmiutil が動作しない場合がありますので、ご注意ください。

6.2.14. Server Core へのインストールについて

Server Core 環境に CLUSTERPRO をインストールする場合、コマンドプロンプトから、CD 媒体のルート直下にある menu.exe を実行してください。これによりメニュー画面が表示されます。

以降の手順は通常のインストールと同様ですが、ライセンス登録で [ライセンスファイルから登録] を選択することはできません。必ず [ライセンス項目を入力して登録] を選択してください。

6.2.15. システムディスクが接続された HBA のアクセス制限について

システムディスクが接続された HBA を[クラスタで管理するHBA一覧]に設定すると、OS がインストールされたシステムパーティションなどにアクセス制限が行われ OS が起動しなくなる場合があります。

SANブート環境などにおいて、システムディスクが接続された HBA を[クラスタで管理するHBA一覧] に設定する場合、システムパーティションを [クラスタ管理から除外するパーティション] に設定してアクセス制限の対象外とする必要があります。

詳細については『リファレンスガイド』の「パラメータの詳細」の「サーバプロパティ」を参照してください。

6.2.16. AWS 環境における時刻同期

以下のAWS 関連リソースでは活性時/非活性時/監視時に AWS CLI を実行しています。

AWS Elastic IP リソース

AWS 仮想 IP リソース

AWS セカンダリ IP リソース

AWS DNS リソース

AWS Elastic IP 監視リソース

AWS 仮想 IP 監視リソース

AWS セカンダリ IP 監視リソース

AWS AZ 監視リソース

AWS DNS 監視リソース

AWS 強制停止リソース

インスタンスの日時が正しく設定されていない場合、AWS CLI の実行に失敗する場合があります。これは AWS の仕様によるものです。

この場合、インスタンスの日時を正しく設定し、NTP などにより時刻同期を取るようにしてください。詳細は「Windows インスタンスの時刻を設定する」 ( https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/set-time.html ) を参照してください。

6.2.17. AWS 環境における IAM の設定について

AWS 環境における IAM （Identity & Access Management）の設定について説明します。

CLUSTERPROの一部の機能は、その処理のために AWS CLI を内部で実行します。AWS CLI が正常に実行されるためには、事前に IAM の設定が必要となります。

AWS CLI にアクセス許可を与える方法として、IAM ロールを使用する方針と、IAM ユーザを使用する方針の 2 通りがあります。基本的には各インスタンスに AWS アクセスキーID、AWS シークレットアクセスキーを保存する必要がなくセキュリティが高くなることから、前者のIAM ロールを使用する方針を推奨します。

IAMの設定手順は次の通りです。

1. まずIAMポリシーを作成します。後述の「IAMポリシーの作成」を参照してください。

2. 次にインスタンスの設定を行います。

   IAMロールを使用する場合、後述の「インスタンスの設定 - IAMロールを使用する」を参照してください。

   IAMユーザを使用する場合、後述の「インスタンスの設定 - IAMユーザを使用する」を参照してください。

IAMポリシーの作成

AWS の EC2 や S3 などのサービスへのアクションに対するアクセス許可を記述したポリシーを作成します。CLUSTERPRO の AWS 関連リソースおよび監視リソースが AWS CLI を実行するために許可が必要なアクションは以下のとおりです。

必要なポリシーは将来変更される可能性があります。

• AWS 仮想IPリソース/AWS 仮想IP監視リソース

アクション	説明
ec2:DescribeNetworkInterfaces ec2:DescribeVpcs ec2:DescribeRouteTables	VPC、ルートテーブル、ネットワークインタフェースの情報を取得する時に必要です。
ec2:ReplaceRoute	ルートテーブルを更新する時に必要です。

• AWS Elastic IPリソース/AWS Elastic IP監視リソース

アクション	説明
ec2:DescribeNetworkInterfaces ec2:DescribeAddresses	EIP、ネットワークインタフェースの情報を取得する時に必要です。
ec2:AssociateAddress	EIPをENIに割り当てる際に必要です。
ec2:DisassociateAddress	EIPをENIから切り離す際に必要です。

• AWS セカンダリ IP リソース/AWS セカンダリ IP 監視リソース

アクション	説明
ec2:DescribeNetworkInterfaces ec2:DescribeSubnets	ネットワークインタフェース、サブネットの情報を取得する時に必要です。
ec2:AssignPrivateIpAddresses	セカンダリIPアドレスの割り当てをする時に必要です。
ec2:UnassignPrivateIpAddresses	セカンダリIPアドレスの割り当て解除をする時に必要です。

• AWS AZ監視リソース

アクション	説明
ec2:DescribeAvailabilityZones	アベイラビリティゾーンの情報を取得する時に必要です。

• AWS DNS リソース/AWS DNS 監視リソース

アクション	説明
route53:ChangeResourceRecordSets	リソースレコードセットの追加、削除、設定内容の更新する時に必要です。
route53:GetChange	リソースレコードセットの追加、設定内容の更新する時に必要です。
route53:ListResourceRecordSets	リソースレコードセット 情報の取得をする時に必要です。

• AWS 強制停止リソース

アクション	説明
ec2:DescribeInstances	インスタンスの情報を取得する時に必要です。
ec2:StopInstances	インスタンスの停止をする時に必要です。
ec2:RebootInstances	インスタンスの再起動をする時に必要です。
ec2:DescribeInstanceAttribute	インスタンスの属性を取得するときに必要です。

• モニタリソースの監視処理時間を Amazon CloudWatch に送信する機能

アクション	説明
cloudwatch:PutMetricData	カスタムメトリクスを送信する時に必要です。

• アラートサービスのメッセージを Amazon SNS に送信する機能

アクション	説明
sns:Publish	メッセージを送信する時に必要です。

以下のカスタムポリシーの例では全てのAWS 関連リソースおよびモニタリソースが使用するアクションを許可しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:Describe*",
                "ec2:ReplaceRoute",
                "ec2:AssociateAddress",
                "ec2:DisassociateAddress",
                "ec2:AssignPrivateIpAddresses",
                "ec2:UnassignPrivateIpAddresses",
                "ec2:StopInstances",
                "ec2:RebootInstances",
                "route53:ChangeResourceRecordSets",
                "route53:GetChange",
                "route53:ListResourceRecordSets"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

IAM Management Console の [Policies] - [Create Policy] で カスタムポリシーを作成できます。

インスタンスの設定 - IAMロールを使用する

IAM ロールを作成し、インスタンスに付与することでAWS CLIを実行可能にする方法です。

図 6.2 IAMロールを使用したインスタンスの設定

1. IAM ロールを作成します。作成したロールに IAM ポリシーをアタッチします。

   IAM Management Console の [Roles] - [Create New Role] で IAM ロールを作成できます。

2. インスタンス作成時に、「IAM Role」に作成した IAM ロールを指定します。

3. インスタンスにログオンします。

4. AWS CLI をインストールします

   AWS CLI をダウンロードして、インストールします。

   システム環境変数 PATH にはインストーラが自動的に追加します。自動的に追加されない場合は、AWSのドキュメント「AWS コマンドラインインターフェイス」を参照して追加してください。

   AWS CLIのインストールを行った時点ですでにCLUSTERPROがインストール済の場合は、OSを再起動してからCLUSTERPROの操作を行ってください。

5. Administrator ユーザでコマンドプロンプトを起動し、以下のコマンドを実行します。

   > aws configure
   

   質問に対して AWS CLI の実行に必要な情報を入力します。AWS アクセスキー ID、AWS シークレットアクセスキーは入力しないことに注意してください。

   AWS Access Key ID [None]: （Enterのみ）
   AWS Secret Access Key [None]: （Enterのみ）
   Default region name [None]: <既定のリージョン名>
   Default output format [None]: text

   "Default output format"は、"text"以外を指定することも可能です。

   誤った内容を設定してしまった場合は、 %SystemDrive%\Users\Administrator\.aws をディレクトリごと消去してから上記操作をやり直してください。

インスタンスの設定 - IAMユーザを使用する

IAM ユーザを作成し、そのアクセスキーID、シークレットアクセスキーをインスタンス内に保存することでAWS CLIを実行可能にする方法です。インスタンス作成時の IAM ロールの付与は不要です。

図 6.3 IAMユーザを使用したインスタンスの設定

1. IAM ユーザを作成します。作成したユーザに IAM ポリシーをアタッチします。

   IAM Management Console の [Users] - [Create New Users] で IAM ユーザを作成できます。

2. インスタンスにログオンします。

3. AWS CLI をインストールします

   AWS CLI をダウンロードして、インストールします。

   システム環境変数 PATH にはインストーラが自動的に追加します。自動的に追加されない場合は、AWSのドキュメント「AWS コマンドラインインターフェイス」を参照して追加してください。

   AWS CLIのインストールを行った時点ですでにCLUSTERPROがインストール済の場合は、OSを再起動してからCLUSTERPROの操作を行ってください。

4. Administrator ユーザでコマンドプロンプトを起動し、以下のコマンドを実行します。

   > aws configure
   

   質問に対して AWS CLI の実行に必要な情報を入力します。AWS アクセスキー ID、AWS シークレットアクセスキーは作成した IAM ユーザの詳細情報画面から取得したものを入力します。

   AWS Access Key ID [None]: <AWS アクセスキー>
   AWS Secret Access Key [None]: <AWS シークレットアクセスキー>
   Default region name [None]: <既定のリージョン名>
   Default output format [None]: text

   "Default output format"は、"text"以外を指定することも可能です。

   誤った内容を設定してしまった場合は、 %SystemDrive%\Users\Administrator\.aws をディレクトリごと消去してから上記操作をやり直してください。

6.2.18. Azure 環境における設定について

• CLUSTERPRO が Microsoft Azure と連携するためには、Microsoft Azure の組織アカウントが必要となります。

  組織アカウント以外のアカウントは Azure CLI 実行時に対話形式でのログインが必要となるため使用できません。
• CLUSTERPROの一部の機能は、その処理のために Azure CLI を内部で実行します。

  Azure CLI が正常に実行されるためには、事前に設定が必要となります。

  Azure CLI の設定については、以下の Web サイトを参照してください。

  Azure のドキュメント:

  https://docs.microsoft.com/ja-jp/azure/
• Microsoft Azure へのログイン時、サービス プリンシパルによる Azure ログインを利用してるため、サービス プリンシパルを事前に作成する必要があります。

  詳細な手順については、以下のWeb サイトを参照してください。
  Azure CLI を使用してサインインする:

  https://docs.microsoft.com/ja-jp/azure/xplat-cli-connect
  Azure CLI で Azure サービス プリンシパルを作成する:

  https://docs.microsoft.com/ja-jp/cli/azure/create-an-azure-service-principal-azure-cli

• Azure CLI のインストール、サービス プリンシパルの作成の手順は、『CLUSTERPRO X Microsoft Azure 向け HAクラスタ 構築ガイド』を参照してください。

6.2.19. Azure環境におけるIAMの設定について

Azure 環境における IAM （Identity & Access Management）の設定について説明します。

CLUSTERPROの一部の機能は、その処理のために Azure CLI を内部で実行します。Azure CLI が正常に実行されるためには、事前に IAM の設定が必要となります。

アクセス権限の設定

CLUSTERPRO の Azure 関連機能が Azure CLI を実行するために必要なアクセス権限は以下の通りです。

必要なアクセス権限は将来変更される可能性があります。

• Azure 強制停止リソース

  アクセス権限	説明
  Microsoft.Compute/virtualMachines/deallocate/action	インスタンスの停止をする時に必要です。
  Microsoft.Compute/virtualMachines/stop/action	インスタンスの停止をする時に必要です。
  Microsoft.Compute/virtualMachines/restart/action	インスタンスの再起動をする時に必要です。
  Microsoft.Compute/virtualMachines/write Microsoft.Compute/virtualMachines/read	インスタンスの属性を取得・更新する時に必要です。

• Azure DNSリソース

  アクセス権限	説明
  Microsoft.Network/dnsZones/A/write	Aレコードの追加、更新をする時に必要です。
  Microsoft.Network/dnsZones/A/delete	Aレコードの削除をする時に必要です。
  Microsoft.Network/dnsZones/NS/read	NSレコードの情報を取得する時に必要です。

  注釈

  Azure CLI 1.0の場合は、以下も必要です。

  Microsoft.Network/dnsZones/read

  Microsoft.Network/dnsZones/A/read

6.2.20. Azure DNS リソースについて

• Azure プライベート DNS には未対応です。

6.2.21. Google Cloud 仮想IPリソースについて

• Google Cloud 仮想IPリソースを Windows Server 2019 で利用する場合、以下のサービスの[スタートアップの種類]を[自動 (遅延開始)]に設定する必要があります。

  • Google Compute Engine Agent

  • Google OSConfig Agent

6.2.22. Google Cloud DNS リソースについて

• Google Cloud の Cloud DNS を使用します。Cloud DNS の詳細については、以下の Web サイトを参照してください。

  Cloud DNS

  https://cloud.google.com/dns/

• Cloud DNS の操作に使用するため、Cloud SDK のインストールが必要です。Cloud SDK の詳細については、以下のサイトを参照してください。

  Cloud SDK

  https://cloud.google.com/sdk/

• 以下の権限を持ったアカウントで Cloud SDK を承認する必要があります。

  dns.changes.create

  dns.changes.get

  dns.managedZones.get

  dns.resourceRecordSets.create

  dns.resourceRecordSets.delete

  dns.resourceRecordSets.list

  dns.resourceRecordSets.update

  Cloud SDK の承認については、以下の Web サイトを参照してください。

  Cloud SDK ツールの承認

  https://cloud.google.com/sdk/docs/authorizing

6.2.23. OCI 環境における CLI の設定について

OCI 環境における CLI の設定について説明します。

CLUSTERPROの一部の機能は、その処理のために OCI CLI を内部で実行します。

OCI CLI が正常に実行されるためには、事前に設定が必要となります。

OCI CLI の設定については、以下の Web サイトを参照してください。

Oracle Cloud Infrastructureドキュメント - コマンドライン・インタフェース(CLI)

https://docs.oracle.com/ja-jp/iaas/Content/API/Concepts/cliconcepts.htm

6.2.24. OCI 環境におけるポリシーの設定について

OCI 環境におけるポリシーの設定について説明します。

CLUSTERPROの一部の機能は、その処理のために OCI CLI を内部で実行します。OCI CLI が正常に実行されるためには、事前にポリシーの設定が必要となります。

ポリシーの設定

CLUSTERPRO の OCI 関連機能が OCI CLI を実行するために必要なポリシーは以下の通りです。

必要なポリシーは将来変更される可能性があります。

• Oracle Cloud DNSリソース, Oracle Cloud DNS監視リソース

  ポリシー構文	説明
  Allow <subject> to use dns in <location>	Oracle Cloud DNS のAレコードを作成、更新、削除または情報を取得する時に必要です。

• OCI 強制停止リソース

  ポリシー構文	説明
  Allow <subject> to use instance-family in <location>	インスタンスの停止、再起動、情報を取得する時に必要です。

  <subject>、 <location> は環境に応じた値を入れてください。

6.3. CLUSTERPRO の構成情報作成時

CLUSTERPRO の構成情報の設計、作成前にシステムの構成に依存して確認、留意が必要な事項です。

6.3.1. CLUSTERPRO インストールパス配下のフォルダやファイルについて

<CLUSTERPROインストールパス>配下にあるフォルダやファイルは、CLUSTERPRO以外から操作（編集/作成/追加/削除など）しないでください。

CLUSTERPRO以外からフォルダやファイルを操作した場合の影響についてはサポート対象外とします。

6.3.2. グループリソースの非活性異常時の最終アクション

非活性異常検出時の最終動作に [何もしない] を選択すると、グループが非活性失敗のまま停止しません。

実際に業務で使用する際には、[何もしない] は設定しないように注意してください。

6.3.3. 遅延警告割合

遅延警告割合を 0 または、100 に設定すれば以下のようなことを行うことが可能です。

• 遅延警告割合に 0 を設定した場合

  監視毎に遅延警告がアラート通報されます。

  この機能を利用し、サーバが高負荷状態でのモニタリソースへのポーリング時間を算出し、モニタリソースの監視タイムアウト時間を決定することができます。
• 遅延警告割合に 100 を設定した場合

  遅延警告の通報を行いません。

テスト運用以外で、0% 等の低い値を設定しないように注意してください。

6.3.4. ディスク監視リソースとハイブリッドディスク TUR 監視リソースの監視方法 TUR について

• SCSI の Test Unit Ready コマンドをサポートしていないディスク、ディスクインターフェイス (HBA) では使用できません。

  ハードウェアがサポートしている場合でもドライバがサポートしていない場合があるのでドライバの仕様も合わせて確認してください。

• Read 方式に比べて OS やディスクへの負荷は小さくなります。

• Test Unit Readyでは、実際のメディアへの I/O エラーは検出できない場合があります。

6.3.5. ハートビートリソースの設定について

• 優先度が一番高いインタコネクトには、全サーバ間で通信可能なカーネルモード LAN ハートビートを設定してください。

• カーネルモード LAN ハートビートリソースを 2 つ以上設定することを推奨します(クラウド環境や遠隔クラスタ環境のようにネットワークの追加が難しい場合はその限りではありません)。

• インタコネクト専用の LAN をカーネルモード LAN ハートビートリソースとして登録し、さらにパブリック LAN もカーネルモード LAN ハートビートリソースとして登録することを推奨します。

• ハートビートタイムアウト時間は OS 再起動の所要時間より短くする必要があります。この条件を満たさない場合、クラスタ内の一部のサーバがリブートした際に、それを他のサーバが正しく検出できず、リブート後に動作異常が発生する場合があります。

6.3.6. スクリプトのコメントなどで取り扱える 2 バイト系文字コードについて

• CLUSTERPRO では、Windows 環境で編集されたスクリプトは Shift-JIS、Linux 環境で編集されたスクリプトは EUC として扱われます。その他の文字コードを利用した場合、環境によっては文字化けが発生する可能性があります。

6.3.7. グループの起動可能サーバに設定可能なサーバグループ数について

• 1つのグループの起動可能サーバに設定可能なサーバグループ数は 2 となっています。3 つ以上のサーバグループを設定した場合、CLUSTERPRO Disk Agent サービス (clpdiskagent.exe) が正しく動作しない可能性があります。

6.3.8. JVM 監視の設定について

• 監視対象がWebLogicの場合、JVM監視リソースの以下の設定値については、システム環境(メモリ搭載量など)により、設定範囲の上限に制限がかかることがあります。

  • [ワークマネージャのリクエストを監視する]-[リクエスト数]

  • [ワークマネージャのリクエストを監視する]-[平均値]

  • [スレッドプールのリクエストを監視する]-[待機リクエスト リクエスト数]

  • [スレッドプールのリクエストを監視する]-[待機リクエスト 平均値]

  • [スレッドプールのリクエストを監視する]-[実行リクエスト リクエスト数]

  • [スレッドプールのリクエストを監視する]-[実行リクエスト 平均値]

• Java Resource Agentを使用するには、「 CLUSTERPRO の動作環境 」の「 JVM 監視の動作環境 」に記載しているJRE(Java Runtime Environment)もしくはJDK(Java Development Kit)をインストールしてください。監視対象（WebLogic ServerやWebOTX）が使用するJREやJDKと同じ物件を使用することも、別の物件を使用することも可能です。1つのサーバにJREとJDKの両方をインストールしている場合、どちらを使用することも可能です。

• モニタリソース名に空白を含まないでください。

6.3.9. システム監視の設定について

• リソース監視の検出パターン

  System Resource Agent では、「しきい値」、「監視継続時間」という２つのパラメータを組み合わせて検出を行います。

  
  

  各システムリソース(メモリ使用量、CPU 使用率、仮想メモリ使用量)を継続して収集し、一定時間（継続時間として指定した時間）しきい値を超えていた場合に異常を検出します。

6.3.10. PostgreSQL 監視の設定について

• モニタリソース名に空白を含まないでください。

6.3.11. AWS CLI コマンドラインオプション

AWS 関連機能では AWS CLI を実行しています。

クラスタプロパティのクラウドタブで [AWS CLI コマンドラインオプション] を設定することで、これらの処理に反映するコマンドラインオプションを指定することができます。

AWSCLI実行時にリクエストを送信するエンドポイントの URL を指定する場合などに有効です。

複数のコマンドラインオプションを指定する場合はスペースで区切りで指定してください。

AWSのサービスごとにコマンドラインオプションを指定することができます。

[AWS CLI コマンドラインオプション] の設定が有効になる機能は以下の通りです。

aws cloudwatch

• Amazon CloudWatch 連携

aws ec2

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS 強制停止リソース

• Cluster WebUI によるクラウド環境情報の取得

aws route53

• AWS DNS リソース

• AWS DNS 監視リソース

aws sns

• Amazon SNS 連携

AWS CLI のコマンドラインオプションの詳細についてはAWSのドキュメントをご参照ください。

注釈

特殊文字である「;」「&&」「||」「`」を指定すると AWS CLI コマンドラインオプションは無効になります。

--outputオプションを指定すると AWS CLI コマンドラインオプションは無効になります。

6.3.12. AWS 関連機能実行時の環境変数

AWS 関連機能では AWS CLI やインスタンスメタデータへのアクセスを実行します。

クラスタプロパティのクラウドタブで [AWS関連機能実行時の環境変数] を設定することで、これらの処理に反映する環境変数を指定することができます。 AWS環境にてプロキシサーバを利用する場合や、AWS CLI の設定ファイルや認証情報ファイルを指定する場合などに有効です。

[AWS関連機能実行時の環境変数] の設定が有効になる機能は以下の通りです。

• AWS Elastic IP リソース

• AWS 仮想 IP リソース

• AWS セカンダリ IP リソース

• AWS DNS リソース

• AWS Elastic IP 監視リソース

• AWS 仮想 IP 監視リソース

• AWS セカンダリ IP 監視リソース

• AWS AZ 監視リソース

• AWS DNS 監視リソース

• AWS 強制停止リソース

• Amazon SNS 連携

• Amazon CloudWatch 連携

• Cluster WebUI によるクラウド環境情報の取得

また、環境変数設定ファイルを使用することで環境変数を指定することもできます。 この場合、[AWS関連機能実行時の環境変数] は設定しないでください。[AWS関連機能実行時の環境変数] を設定した場合は環境変数設定ファイルは使用できません。

注釈

環境変数設定ファイルは旧バージョンとの互換性維持のための機能です。 環境変数の設定には [AWS関連機能実行時の環境変数] の使用を推奨します。

環境変数設定ファイルは、以下に配置しています。

<CLUSTERPROインストールパス>/cloud/aws/clpaws_setting.conf

環境変数設定ファイルのフォーマットは、以下のとおりです。

環境変数名 = 値

記載例)

[ENVIRONMENT]
HTTP_PROXY = http://10.0.0.1:3128
HTTPS_PROXY = http://10.0.0.1:3128
NO_PROXY = 169.254.169.254,ec2.ap-northeast-1.amazonaws.com

環境変数設定ファイルの仕様は、以下のとおりです。

• 一行目は [ENVIRONMENT] を記載してください。記載がない場合は環境変数が設定されないことがあります。

• 環境変数設定ファイルが存在しない場合や読み取り権限がない場合は無視します。活性異常や監視異常にはなりません。

• 同名の環境変数が既に設定されている場合、値を上書きします。

• 環境変数名の前にスペースやタブがある場合または = の両側にタブがある場合、設定が反映されないことがあります。

• 環境変数名は大文字・小文字を区別します。

• 値にスペースが入る場合、""(ダブルクォート)で括る必要はありません。

• 環境変数はグループリソースやモニタリソースの共通スクリプト (例.最終動作前スクリプト、活性/非活性前後スクリプト) には反映されません。

6.3.13. AWS 関連機能実行時に使用する設定ファイルと認証情報ファイルについて

AWS 関連機能から実行されるAWS CLIは以下のフォルダに保存されている設定ファイルと認証情報ファイルを使用しています。

<システムドライブ>\Users\Administrator\.aws

上記のフォルダ以外に保存されている設定ファイルと認証情報ファイルを使用したい場合、環境変数を指定する必要があります。

AWS 関連機能から実行されるAWS CLIに環境変数を指定するには「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS 関連機能実行時の環境変数」を参照してください。

設定ファイルと認証情報ファイルを指定する環境変数は以下になります。

設定ファイルと認証情報ファイルのパスを環境変数に指定してください。

AWS_CONFIG_FILE
AWS_SHARED_CREDENTIALS_FILE

AWS CLIの環境変数の詳細についてはAWSのドキュメントをご参照ください。

6.3.14. AWS Elastic IP リソースの設定について

• IPv6はサポートしていません。

• AWS 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。

• AWS Elastic IPリソースはASCII文字以外の文字に対応していません。下記のコマンドの実行結果にASCII文字以外の文字が含まれないことを確認してください。

  aws ec2 describe-addresses --allocation-ids <EIP ALLOCATION ID>

• AWS Elastic IP リソースはENIのプライマリプライベートIPアドレスにEIPを関連付けます。セカンダリプライベートIPアドレスに関連付けはできません。

6.3.15. AWS 仮想 IP リソースの設定について

• IPv6はサポートしていません。

• AWS 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。

• AWS 仮想 IPリソースはASCII文字以外の文字に対応していません。下記のコマンドの実行結果にASCII文字以外の文字が含まれないことを確認してください。

  aws ec2 describe-vpcs --vpc-ids <VPC ID>
  aws ec2 describe-route-tables --filters Name=vpc-id,Values=<VPC ID>
  aws ec2 describe-network-interfaces --network-interface-ids <ENI ID>

• AWS 仮想IPリソースは、VPC ピアリング接続を経由してのアクセスが必要な場合では利用することができません。これは、VIP として使用する IP アドレスが VPC の範囲外であることを前提としており、このような IP アドレスは VPC ピアリング接続では無効とみなされるためです。VPC ピアリング接続を経由してのアクセスが必要な場合は、Amazon Route 53 を利用する AWS DNS リソースを使用してください。

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

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

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

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

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

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

• インスタンスが使用するルートテーブルに、仮想IPが使用するIPアドレスのルートが存在しない場合でもAWS仮想IPリソースは正常に起動します。この動作は仕様どおりです。AWS 仮想 IP リソースは活性化時において、指定された IP アドレスのエントリが存在するルートテーブルに対してのみその内容を更新します。ルートテーブルが一つも見つからなかった場合でも更新対象なしとして正常と判断します。どのルートテーブルにエントリが存在する必要があるかはシステムの構成で決まるため、AWS 仮想 IP リソースとしては正常性の判断対象とはしていません。

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

6.3.16. AWS セカンダリ IP リソースの設定について

• IPv6はサポートしていません。

• AWS 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソースは利用できません。

• AWS セカンダリ IP リソースはASCII文字以外の文字に対応していません。下記のコマンドの実行結果にASCII文字以外の文字が含まれないことを確認してください。

  aws ec2 describe-network-interfaces --network-interface-ids <ENI ID>
  aws ec2 describe-subnets --subnet-ids <SUBNET_ID>

• AWS セカンダリ IP リソースはサブネットが異なる構成では利用できません。

• AWS セカンダリ IP リソースで割り当てられるセカンダリ IP アドレスはインスタンスタイプごとに上限があります。

  詳細は下記を参照してください。

  https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI
• AWS セカンダリ IP リソースでセカンダリ IP アドレスを割り当てるネットワークアダプタの物理IPアドレスを静的に登録してください。

  詳細は下記の手順1を参照してください。

  https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/config-windows-multiple-ip.html

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

6.3.17. AWS DNS リソースの設定について

• IPv6はサポートしていません。

• AWS 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。

• [リソースレコードセット名] にエスケープコードを含む場合、監視が異常になります。エスケープコードを含まない [リソースレコードセット名] を設定してください。

• AWS DNS リソースはアカウントに紐づいています。そのため、複数のアカウントや AWS アクセスキーID、AWS シークレットアクセスキーを使い分ける運用はできません。その場合は、スクリプトリソースなどで AWS CLI を実行するスクリプトを作成し、その中の環境変数に他アカウント認証用の情報を設定する運用を検討してください。

6.3.18. AWS DNS 監視リソースの設定について

• AWS DNS リソースの活性直後、以下の事象により AWS DNS 監視リソースによる監視が失敗する可能性があります。この場合、AWS DNS 監視リソースの [監視開始待ち時間] を Amazon Route 53 における DNS 設定の変更が反映される時間より長く設定してください(https://aws.amazon.com/jp/route53/faqs/)。

  • AWS DNS リソースの活性時、レコードセットの追加や更新をする。

  • Amazon Route 53 における DNS 設定の変更が反映される前に、AWS DNS 監視リソースが監視を実行すると名前解決ができないため監視に失敗する。DNS リゾルバキャッシュが有効な間は、その後も AWS DNS 監視リソースは監視に失敗する。

  • Amazon Route 53 における DNS 設定の変更が反映される。

  • AWS DNS リソースの [TTL] の有効期間が経過すると名前解決に成功するため、AWS DNS 監視リソースの監視が成功する。

6.3.19. Azure プローブポートリソースの設定について

• IPv6はサポートしていません。

• Microsoft Azure 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。

6.3.20. Azure ロードバランス監視リソースの設定について

Azure ロードバランス監視リソースが異常を検知した場合、Azureのロードバランサからの現用系と待機系の切り替えが正しく行われない可能性があります。そのため、Azure ロードバランス監視リソースの [最終動作] には [クラスタサービス停止と OS シャットダウン] を選択することを推奨とします。

6.3.21. Azure DNS リソースの設定について

• IPv6はサポートしていません。

• Microsoft Azure 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。

6.3.22. Google Cloud 仮想 IP リソースの設定について

• IPv6はサポートしていません。

6.3.23. Google Cloud ロードバランス監視リソースの設定について

• Google Cloud ロードバランス監視リソースが異常を検知した場合、ロードバランサからの現用系と待機系の切り替えが正しく行われない可能性があります。そのため、Google Cloud ロードバランス監視リソースの [最終動作] には [クラスタサービス停止と OS シャットダウン] を選択することを推奨します。

6.3.24. Google Cloud DNS リソースの設定について

• IPv6はサポートしていません。

• Google Cloud 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソースは利用できません。

• 複数のGoogle Cloud DNSリソースの活性・非活性処理が同時に実行されるとエラーが発生することがあります。そのため、クラスタ内で複数のGoogle Cloud DNSリソースを使用する場合は、リソースの依存関係やグループの起動・停止待ち合わせ等で活性・非活性処理が同時に実行されないように設定する必要があります。

6.3.25. Oracle Cloud 仮想 IP リソースの設定について

• IPv6はサポートしていません。

6.3.26. Oracle Cloud ロードバランス監視リソースの設定について

• Oracle Cloud ロードバランス監視リソースが異常を検知した場合、ロードバランサからの現用系と待機系の切り替えが正しく行われない可能性があります。そのため、Oracle Cloud ロードバランス監視リソースの [最終動作] には [クラスタサービス停止と OS シャットダウン] を選択することを推奨します。

6.3.27. Oracle Cloud DNS リソースの設定について

• IPv6 はサポートしていません。

• Oracle Cloud 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソースは利用できません。

6.3.28. OCI 関連機能実行時に使用する構成情報ファイルについて

OCI 関連機能から実行されるOCI CLIは以下のフォルダに保存されている構成情報ファイルを使用しています。

<システムドライブ>\Users\opc\.oci

6.3.29. Windows Server 2012 以降のシステムにおけるサービス失敗時の回復操作について

Windows Server 2012 以降のシステムにおいて、サービスが失敗(異常終了)した時に行われる回復操作として[コンピューターを再起動する]が設定されている場合、実際にサービスが失敗した際の動作が従来(Windows Server 2008以前)のOS再起動からSTOPエラーを伴うOS再起動へ変更されています。

回復操作として既定で[コンピューターを再起動する]が設定されているCLUSTERPRO のサービスは下記です。

• CLUSTERPRO Disk Agent サービス

• CLUSTERPRO Node Manager サービス

• CLUSTERPRO Server サービス

• CLUSTERPRO Transaction サービス

6.3.30. OS のネットワーク負荷分散機能との共存について

OS のネットワーク負荷分散 (NLB) 機能にて使用している NIC に追加された IP アドレスは、NLB の仮想 IP アドレスとして認識されます。

この仮想 IP アドレスは NLB クラスタ内の全てのサーバにて付与されているものとして扱われます。

該当の NIC に対してフローティング IP アドレスが付与された場合、フローティング IP アドレスも仮想 IP アドレスとして認識されます。

このフローティング IP アドレスに対してアクセスした場合も、NLB の機能によって負荷分散が行われますが、フローティング IP アドレスは待機系の NIC には付与されていないため、フローティング IP アドレスに対するアクセスが異常となることがあります。

6.3.31. HBA の設定を反映する場合の注意点

クラスタの新規作成時に [サーバプロパティ] の [HBA] タブでアクセス制限の設定を変更して構成情報のアップロードを実行した場合、反映方法として OS 再起動が表示されないことがあります。クラスタの新規作成時に [HBA] タブでアクセス制限の設定を変更した場合は構成情報を反映するために OS の再起動を行ってください。

6.3.32. リソース追加ウィザード画面に表示されるリソースタイプ一覧について

グループリソースやモニタリソースの追加ウィザード画面のリソースタイプ一覧は、初期状態ではCLUSTERPROインストール環境に合わせて絞り込んで表示されます。

表示されていないリソースを追加する場合は [全てのタイプを表示] ボタンをクリックしてください。

6.3.33. ミラーディスクリソースとハイブリッドディスクリソースの共存について

同一のフェイルオーバーグループにミラーディスクリソースとハイブリッドディスクリソースを混在させることはできません。

6.3.34. ミラーブレイク状態でのフェイルオーバを指定した時間許容する設定を使用する場合の注意点

本設定を使用する場合は、以下の項目に注意してください。

• 本設定を有効にした場合は、ミラーブレイク時の自動ミラー復帰が一時的に抑制されます。

• 本設定を有効にした場合は、一部のフェイルオーバ属性の設定に制限がかかります。

• ハイブリッドディスクリソースに対して本機能を使用する場合は、サーバグループを構成するサーバ間で時刻が同期されていることを確認してください。

• タイムアウトには、ハートビートタイムアウト以上の値を設定することを推奨します。

詳細は『リファレンスガイド』 - 「パラメータの詳細」 - 「クラスタプロパティ」 - 「ミラーディスクタブ」を参照してください。

6.4. CLUSTERPRO 運用後

クラスタとして運用を開始した後に発生する事象で留意して頂きたい事項です。

6.4.1. 回復動作中の操作制限

モニタリソースの異常検出時の設定で回復対象にグループリソース (ディスクリソース、アプリケーションリソースなど) を指定し、モニタリソースが異常を検出した場合の回復動作遷移中 (再活性化 → フェイルオーバ → 最終動作) には、Cluster WebUI やコマンドによる以下の操作は行わないでください。

• クラスタの停止/サスペンド

• グループの起動/停止/移動

モニタリソース異常による回復動作遷移中に上記の制御を行うと、そのグループの他のグループリソースが停止しないことがあります。

また、モニタリソース異常状態であっても最終動作実行後であれば上記制御を行うことが可能です。

6.4.2. コマンドリファレンスに記載されていない実行形式ファイルやスクリプトファイルについて

インストールディレクトリ配下にコマンドリファレンスに記載されていない実行形式ファイルやスクリプトファイルがありますが、CLUSTERPRO 以外からは実行しないでください。

実行した場合の影響については、サポート対象外とします。

6.4.3. クラスタシャットダウン・クラスタシャットダウンリブート

ミラーディスク使用時は、グループ活性処理中に [clpstdn] コマンドまたは Cluster WebUI からクラスタシャットダウン,クラスタシャットダウンリブートを実行しないでください。

グループ活性処理中はグループ非活性ができません。このため、ミラーディスクリソースが正常に非活性されていない状態で OS がシャットダウンされ、ミラーブレイクが発生することがあります。

6.4.4. 特定サーバのシャットダウン、リブート

ミラーディスク使用時は、コマンドまたは Cluster WebUI からサーバのクラスタサービス停止,シャットダウン,シャットダウンリブートコマンドを実行するとミラーブレイクが発生します。

6.4.5. ネットワークパーティション状態からの復旧

ネットワークパーティションが発生している状態では、クラスタを構成するサーバ間で互いの状態が確認できないため、この状態でグループの操作 (起動/停止/移動) を行ったり、サーバを再起動したりすると、サーバ間でクラスタの状態についての認識にずれが生じます。このように異なる状態認識のサーバが複数起動している状態でネットワークが復旧すると、その後のグループ操作が正しく動作しなくなりますので、ネットワークパーティション状態にある間は、ネットワークから切り離された （クライアントと通信できない） 方のサーバはシャットダウンするか、CLUSTERPRO Server サービスを停止しておき、ネットワークが復旧してから再起動してクラスタに復帰してください。万一、複数のサーバが起動した状態でネットワークが復旧した場合は、クラスタの状態認識が異なるサーバを再起動することにより、正常状態に復帰できます。

なお、ネットワークパーティション解決リソースを使用している場合は、ネットワークパーティションが発生しても、通常はいずれかの （あるいは全ての） サーバが緊急シャットダウンして、互いに通信できないサーバが複数起動するのを回避します。緊急シャットダウンされたサーバを手動で再起動したり、緊急シャットダウン時の動作を再起動に設定していたりした場合も、再起動したサーバは再度緊急シャットダウンされます （Ping 方式や多数決方式の場合はCLUSTERPRO Server サービスが停止されます）。ただし、DISK 方式で複数のディスクハートビート用パーティションを使用している場合、ディスクパス障害によりディスクを介した通信ができない状態でネットワークパーティションが発生すると、両サーバが保留状態で動作を継続する場合があります。

6.4.6. Cluster WebUI について

• 接続先と通信できない状態で操作を行うと、制御が戻ってくるまでしばらく時間が必要な場合があります。

• Proxy サーバを経由する場合は、Cluster WebUI のポート番号を中継できるように、Proxy サーバの設定をしてください。

• Reverse Proxy サーバを経由する場合、Cluster WebUI は正常に動作しません。

• CLUSTERPRO のアップデートを行った場合、起動している全てのブラウザを一旦終了してください。ブラウザ側のキャッシュをクリアして、ブラウザを起動してください。

• 本製品より新しいバージョンで作成されたクラスタ構成情報は、本製品で利用することはできません。

• Web ブラウザを終了すると (ウィンドウフレームの [X] 等)、確認ダイアログが表示される場合があります。

  

  設定を続行する場合は [ページに留まる] を選択してください。

• Web ブラウザをリロードすると (メニューの [最新の情報に更新] やツールバーの [現在のページを再読み込み] 等) 、確認ダイアログが表示される場合があります。

  

  設定を続行する場合は [ページに留まる] を選択してください。

• 上記以外の Cluster WebUI の注意制限事項についてはオンラインマニュアルを参照してください。

6.4.7. CLUSTERPRO Disk Agent サービスについて

CLUSTERPRO Disk Agent サービスは停止しないでください。停止した場合、手動での起動はできません。OS を再起動し CLUSTERPRO Disk Agent サービスを起動しなおす必要があります。

6.4.8. ミラー構築中のクラスタ構成情報の変更について

ミラー構築中 (初期構築を含む) はクラスタ構成情報を変更しないでください。クラスタ構成情報を変更した場合、ドライバが不正な動作を行う場合があります。

6.4.9. ミラーディスクの待機系のクラスタ復帰について

ミラーディスク活性時に待機系がクラスタサービス （CLUSTERPRO Server サービス） を停止した状態で稼動していた場合、サービスを開始してクラスタに復帰する前に一度待機系サーバを再起動してください。そのまま復帰させるとミラーの差分情報が不正となり、ミラーディスクに不整合が生じます。

6.4.10. ミラーディスク-ハイブリッドディスク間の構成変更について

ミラーディスクリソースでミラーリングしていたディスクをハイブリッドディスクリソースでミラーリングするように構成変更する場合、まず既存のミラーディスクリソースを削除した構成情報をアップロードして、既存のリソースが削除された状態に変更してから、ハイブリッドディスクリソースを追加した構成情報をアップロードしてください。ハイブリッドディスクをミラーディスクに変更する場合も同様です。

上記の手順で既存のリソースを削除せずに、新規のリソースに入れ替えた構成情報をアップロードした場合、ディスクミラーリングの設定変更が正しく行えず不正な動作を行う場合があります。

6.4.11. [chkdsk] コマンドとデフラグについて

ディスクリソースで制御している共有ディスク上の切替パーティションや、ミラーディスクリソースでミラーリングしているデータパーティションに対して、[chkdsk] コマンドやデフラグを実行する場合、リソースが起動済みのサーバで実行する必要があります。起動していない状態では、アクセス制限により実行できません。

また、[chkdsk] コマンドを修復モード （/fオプション） で実行する場合、対象パーティション上のファイルやフォルダが開かれていると実行が失敗するため、フェイルオーバグループを停止し、対象のディスクリソース/ミラーディスクリソースを単体起動した状態で実行します。もし対象パーティションに対して監視を行うディスク RW 監視リソースがある場合は、このモニタリソースを一時停止しておく必要があります。

6.4.12. インデックスサービスについて

インデックスサービスのカタログに共有ディスク/ミラーディスク上のディレクトリを作成して、共有ディスク/ミラーディスク上のフォルダに対してインデックスを作成する場合、インデックスサービスを手動起動に設定して、共有ディスク/ミラーディスクの活性後に起動するようにCLUSTERPRO から制御する必要があります。インデックスサービスを自動起動にしていると、インデックスサービスが対象ボリュームを OPEN することにより、その後の活性化処理においてマウント処理が失敗し、アプリケーションやエクスプローラからのディスクアクセスが [パラメータが間違っています] （エラーコード87） というエラーで失敗します。

6.4.13. Windows Server 2012 以降の環境におけるユーザーアカウント制御の影響について

Windows Server 2012 以降では、既定値でユーザーアカウント制御 (User Account Control, 以下 UAC と略します) が有効となっています。UAC が有効となっている場合、下記の機能に影響があります。

• モニタリソース

  下記のモニタリソースに影響があります。
  • Oracle 監視リソース

    Oracle 監視リソースにおいて「認証方式」を [OS 認証] とした場合、監視ユーザにAdministratorsグループ以外のユーザが設定されていると、Oracle監視の処理は失敗します。

    「認証方式」に [OS 認証] を設定する場合は、「監視ユーザ」に設定するユーザはAdministratorsグループに属するようにしてください。

6.4.14. ネットワークインターフェイスカード (NIC) が二重化されている環境について

NIC が二重化されている環境の場合、OS 起動時の NIC の初期化に時間がかかることがあります。初期化が完了する前にクラスタが起動すると、カーネルモード LAN ハートビートリソース (lankhb) の起動に失敗することがあります。この場合、NIC の初期化が完了しても、カーネルモード LAN ハートビートリソースの状態は正常に戻りません。この状態から復旧させるためには、クラスタをサスペンドした後、クラスタをリジュームする必要があります。

また、上記の現象を回避するためにネットワーク初期化完了待ち時間の設定でクラスタの起動を遅らせることを推奨します。

• ネットワーク初期化完了待ち時間

  クラスタを構成する全サーバで共通の設定です。設定した時間に達していない場合でも、ネットワークの初期化が完了すると、クラスタの起動を開始します。

6.4.15. CLUSTERPRO のサービスのログオンアカウントについて

CLUSTERPROのサービスのログオンアカウントは [ローカル システム アカウント] に設定されています。このログオンアカウントの設定を変更すると、クラスタとして正しく動作しない可能性があります。

6.4.16. CLUSTERPRO の常駐プロセスの監視について

プロセスを監視するようなソフトウェアにより、CLUSTERPROの常駐プロセスを監視すること自体には問題はありませんが、プロセスの異常終了時などにプロセスの再起動などの回復動作は行わないでください。

6.4.17. 外部連携監視リソースについて

• 外部連携監視リソースに異常を通知するには、[clprexec] コマンドを用いる方法、サーバ管理基盤連携機能を用いる方法の二つの方法があります。

• [clprexec] コマンドを用いる場合は CLUSTERPRO CD に同梱されているファイルを利用します。通知元サーバの OS やアーキテクチャに合わせて利用してください。また、通知元サーバと通知先サーバの通信が可能である必要があります。

6.4.18. JVM 監視リソースについて

• 監視対象のJava VMを再起動する場合はJVM監視リソースをサスペンドするか、クラスタ停止を行った後に行ってください。

• 設定内容を変更時にクラスタサスペンドおよびクラスタリジュームを行う必要があります。

• モニタリソースの遅延警告には対応していません。

6.4.19. システム監視リソース、プロセスリソース監視リソースについて

• 設定内容を変更時にクラスタサスペンドを行う必要があります。

• モニタリソースの遅延警告には対応していません。

• 動作中に OS の日付/時刻を変更した場合、10 分間隔で行っている解析処理のタイミングが日付/時刻変更後の最初の 1 回だけずれてしまいます。以下のようなことが発生するため、必要に応じてクラスタのサスペンド・リジュームを行ってください。

  • 異常として検出する経過時間を過ぎても、異常検出が行われない。

  • 異常として検出する経過時間前に、異常検出が行われる。

• システム監視リソースのディスクリソース監視機能で同時に監視できる最大のディスク数は 26 台です。

6.4.20. ミラー統計情報採取機能と OS 標準機能との連携に伴うイベントログ出力について

• 内部バージョン 11.16 以前からアップデートした環境の場合、アプリケーションイベントログに下記のエラーが出力されることがあります。

• イベントID:1008

  ソース:Perflib

  メッセージ:サービス "clpdiskperf" (DLL "<CLUSTERPRO インストールパス>\bin\clpdiskperf.dll") の Open プロシージャに失敗しました。このサービスのパフォーマンス データは利用できません。データ セクションの最初の 4 バイト (DWORD) に、エラーコードが含まれています。

  ミラー統計情報採取機能と OS 標準機能との連携機能を使用する場合、コマンドプロンプトから以下のコマンドを実行することで、本メッセージが出力されなくなります。

  > lodctr.exe <CLUSTERPRO インストールパス>\perf\clpdiskperf.ini

  連携機能を使用しない場合、本メッセージが出力されてもCLUSTERPROおよびパフォーマンスモニタの動作に支障はありませんが、本メッセージの出力が多発する場合はコマンドプロンプトから以下の2つのコマンドを実行することで、本メッセージが出力されなくなります。

  > unlodctr.exe clpdiskperf
  > reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\clpdiskperf

• ミラー統計情報採取機能と OS 標準機能との連携機能が有効化されている場合、アプリケーションイベントログに下記のエラーが出力されることがあります。

• イベントID:4806

  ソース:CLUSTERPRO X

  メッセージ:パフォーマンスモニタのプロセス数が多すぎるため、ミラー統計情報は採取できません。

  連携機能を使用しない場合、本メッセージが出力されてもCLUSTERPROおよびパフォーマンスモニタの動作に支障はありませんが、本メッセージの出力が多発する場合はコマンドプロンプトから以下の2つのコマンドを実行することで、本メッセージが出力されなくなります。

  > unlodctr.exe clpdiskperf
  > reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\clpdiskperf

なお、ミラー統計情報採取機能と OS 標準機能との連携機能については、以下を参照してください。

『メンテナンスガイド』

「保守情報」

「ミラー統計情報採取機能」

「ミラー統計情報採取機能と OS 標準機能との連携」

6.4.21. AWS 環境における AMI のリストアについて

AWS 仮想 IP リソースや AWS Elastic IP リソース、AWS セカンダリ IP リソースの [ENI ID] にプライマリネットワークインターフェイスの ENI ID を設定している場合、AMI などからのリストア時には、AWS 仮想 IP リソースや AWS Elastic IP リソースやAWS セカンダリ IP リソースの設定を変更する必要があります。

なお、セカンダリネットワークインターフェイスの ENI ID を設定している場合、AMI などからのリストア時にはデタッチ/アタッチ処理によって同一 ENI ID の引き継ぎが可能なため、AWS 仮想 IP リソースや AWS Elastic IP リソースやAWS セカンダリ IP リソースの再設定は不要です。

6.5. CLUSTERPRO の構成変更時

クラスタとして運用を開始した後に構成を変更する場合に発生する事象で留意して頂きたい事項です。

6.5.1. グループ共通プロパティの排他ルールについて

排他ルールの排他属性を変更した場合、クラスタサスペンド、リジュームにより変更が反映されます。

排他属性が「完全排他」に設定されている排他ルールに、新たに排他対象のグループを追加した場合、サスペンド前のグループの起動状態により完全排他のグループが同一サーバ上で複数起動した状態になることがあります。

次回グループ起動時から正しく排他制御が行われるようになります。

6.5.2. リソースプロパティの依存関係について

リソースの依存関係を変更した場合、クラスタサスペンド、リジュームにより変更が反映されます。

リソースの依存関係と反映方法としてリソース停止が必要な設定変更をした場合、リジューム後のリソースの起動状態が依存関係を考慮したものになっていない場合があります。

次回グループ起動時から正しく依存関係の制御が行われるようになります。

6.5.3. 外部連携監視リソースのクラスタ統計情報の設定について

モニタリソースのクラスタ統計情報の設定を変更した場合、サスペンド・リジュームを実行しても外部連携監視リソースにはクラスタ統計情報の設定が反映されません。外部連携監視リソースにもクラスタ統計情報の設定を反映させる場合は、OS の再起動を行ってください。

6.5.4. ポート番号の変更について

サーバのファイアウォールを有効にしており、ポート番号を変更した場合、ファイアウォールの設定の変更が必要です。clpfwctrl コマンドでファイアウォールの設定を行うことができます。詳細は『リファレンスガイド』 - 「CLUSTERPRO コマンドリファレンス」 - 「ファイアウォールの規則を追加する (clpfwctrl コマンド)」を参照してください。

6.6. CLUSTERPRO バージョンアップ時

クラスタとして運用を開始した後にCLUSTERPRO をバージョンアップ(アップグレードまたはアップデート)する際に留意して頂きたい事項です。

6.6.1. 機能変更一覧

各バージョンで変更された機能について、以下に示します。

内部バージョン 12.00

• 管理ツールについて

  既定の管理ツールを Cluster WebUI に変更しました。従来の WebManager をご利用の場合は、http://管理用グループの管理IPアドレスまたは CLUSTERPRO Server をインストールしたサーバの実IPアドレス:ポート番号 (既定値29003)/main.htm を Web ブラウザに指定してください。
• ミラーディスクリソース/ハイブリッドディスクリソースについて

  クラスタパーティションの最低サイズが1GiBとなっています。アップグレード時には、十分なサイズのクラスタパーティションを事前にご準備ください。
• 最大フェイルオーバ回数について

  フェイルオーバ回数のカウント単位が「クラスタ」から「サーバ」に変更されます。それに伴い、グループリソース・モニタリソースの[最大フェイルオーバ回数] が既定値の値になります。

  バージョンアップ前に設定していた [最大フェイルオーバ回数] の値をバージョンアップ後も使用する場合は、[クラスタのプロパティ] - [拡張] タブ - [フェイルオーバ回数のカウント単位] を「クラスタ」に変更してください。

内部バージョン 12.10

• 設定ツールについて

  既定の設定ツールを Cluster WebUI に変更しました。Cluster WebUI によるクラスタの管理および設定を可能にしました。
• クラスタ統計情報採取機能について

  クラスタ統計情報採取機能により、既定値の動作では統計情報ファイルがインストールパス配下に保存されます。ディスク容量の都合等で統計情報ファイルを保存したくない場合は、クラスタ統計情報採取機能をオフにしてください。本機能の設定値については『リファレンスガイド』の「パラメータの詳細」を参照してください。
• システム監視リソースについて

  システム監視リソース内で設定していた「System Resource Agent プロセス設定」 部分を新規モニタリソースとして分離しました。「System Resource Agent プロセス設定」で監視設定を行っている場合、本監視の設定は無効となります。アップデート後も本監視を継続する場合は、アップデート後に新規にプロセスリソース監視リソースを登録し、監視設定を行ってください。プロセスリソース監視リソースの監視設定の詳細は『リファレンスガイド』の「モニタリソースの詳細」、「プロセスリソース監視リソースを理解する」を参照してください。
• BMC連携について

  ipmiutilのパラメータを以下の通りに変更しました。

変更前(12.01以前)

強制停止アクション

強制停止アクション	パラメータ
BMC パワーオフ	ireset.cmd -d -J 0 -N IPアドレス -U ユーザ名 -P パスワード
BMC リセット	ireset.cmd -r -J 0 -N IPアドレス -U ユーザ名 -P パスワード
BMC パワーサイクル	ireset.cmd -c -J 0 -N IPアドレス -U ユーザ名 -P パスワード
BMC NMI	ireset.cmd -n -J 0 -N IPアドレス -U ユーザ名 -P パスワード

筐体IDランプ

筐体IDランプ	パラメータ
点滅	ialarms.cmd -i250 -J 0 -N IPアドレス -U ユーザ名 -P パスワード
消灯	ialarms.cmd -i0 -J 0 -N IPアドレス -U ユーザ名 -P パスワード

変更後

強制停止アクション

強制停止アクション	パラメータ
BMC パワーオフ	ireset.cmd -d -N IPアドレス -U ユーザ名 -P パスワード
BMC リセット	ireset.cmd -r -N IPアドレス -U ユーザ名 -P パスワード
BMC パワーサイクル	ireset.cmd -c -N IPアドレス -U ユーザ名 -P パスワード
BMC NMI	ireset.cmd -n -N IPアドレス -U ユーザ名 -P パスワード

筐体IDランプ

筐体IDランプ	パラメータ
点滅	ialarms.cmd -i250 -N IPアドレス -U ユーザ名 -P パスワード
消灯	ialarms.cmd -i0 -N IPアドレス -U ユーザ名 -P パスワード

内部バージョン 12.20

• AWS AZ 監視リソースについて

  AWS CLI を使って取得できるAZの状態が available の場合は正常、information や impaired の場合は警告、unavailable の場合は異常に変更しました。以前は AWS CLI を使って取得できるAZの状態が available 以外の場合、異常でした。

内部バージョン 12.30

• WebLogic 監視リソースについて

  新しい監視方式として REST API を追加しました。本バージョンからは REST API が監視方式の既定値となります。バージョンアップ時には監視方式の再設定を行ってください。

内部バージョン 13.00

• 強制停止機能および強制停止スクリプトについて

  環境の種類に応じた個別の強制停止リソースとして刷新されました。

  バージョンアップ前に設定された強制停止機能および強制停止スクリプトは無効となりますので、強制停止リソースとして設定し直してください。

内部バージョン 13.10

• AWS 仮想 IP リソースについて

  Pythonを使用しなくなったことによりパラメータが一部変更しています。

内部バージョン 13.20

• Cluster WebUI の対応ブラウザについて

  本バージョン以降、Cluster WebUI は Internet Explorer をサポートしていません。動作確認済ブラウザについては「4.3.1. 動作確認済 OS、ブラウザ」を参照してください。

6.6.2. 機能削除一覧

各バージョンで削除された機能について、以下に示します。

重要

旧バージョンからアップグレードする場合、対処列に記載がある項目は手動で構成情報を更新する必要があります。

アップグレード手順は『インストール&設定ガイド』-「CLUSTERPRO をインストールする」- 「CLUSTERPRO Server のインストール」- 「旧バージョンの CLUSTERPRO Server からアップグレードするには」を参照し、 対処列の実施は手順にあるタイミングで実施してください。

内部バージョン 12.00

機能	対処
WebManager Mobile
VB Corp CL 監視リソース
VB Corp SV 監視リソース
OracleAS 監視リソース

内部バージョン 13.00

機能	対処
WebManager/Builder
COM ネットワークパーティション解決リソース	[クラスタプロパティ] - [NP解決タブ] を開き、タイプが [不明] と表示されているNP解決リソースを削除してください。
NASリソース NAS監視リソース	グループリソースの依存関係に NASリソースを個別に設定している場合、先に依存関係の設定を削除します。 NAS リソースを依存関係に設定しているグループリソースについて、 [リソースのプロパティ] - [依存関係] タブを開き、NASリソースを選択した状態で [削除] ボタンをクリックし依存するリソースから削除してください。 NASリソースを削除してください。 NASリソースの削除時に、NAS監視リソースも削除されます。
プリントスプーラリソース プリントスプーラ監視リソース	グループリソースの依存関係にプリントスプーラリソースを個別に設定している場合、先に依存関係の設定を削除します。 プリントスプーラリソースを依存関係に設定しているグループリソースについて、 [リソースのプロパティ] - [依存関係] タブを開き、プリントスプーラリソースを選択した状態で [削除] ボタンをクリックし依存するリソースから削除してください。 プリントスプーラリソースを削除してください。 プリントスプーラリソースの削除時に、プリントスプーラ監視リソースも削除されます。
仮想マシングループ 仮想マシンリソース 仮想マシン監視リソース	仮想マシングループを含んだ「ホストクラスタ用の構成情報」は移行できません。
BMC連携機能	関連する外部連携監視リソースを削除してください。
互換コマンド	スクリプトリソース カスタム監視リソース 最終動作前スクリプト 活性/非活性前後スクリプト 回復スクリプト 回復動作前スクリプト 強制停止スクリプト その他 CLUSTERPRO から設定したスクリプト これらのスクリプトで互換コマンドを使用している場合、スクリプトの内容を互換コマンドを使わない形式で修正してください。 例 armload でサービスを制御している場合、サービスの起動停止処理を sc コマンドで代替してください。 サービスの監視処理については、サービス監視リソースで代替してください。 armdelay で CLUSTERPRO サービス起動時の遅延時間を設定している場合、クラスタプロパティのタイムアウトタブ[サービス起動遅延時間]の設定で代替してください。
CPUクロック制御コマンド (clpcpufreq コマンド)	-
リソース使用量予測コマンド (clpprer コマンド)	-
筐体 ID ランプを制御するコマンド (clpledctrl コマンド)	-
クラスタ間連携を行うコマンド (clptrnreq コマンド)	-
BMC 情報を変更するコマンド (clpbmccnf コマンド)	-
カーネルモードLANハートビートリソースのブロードキャスト機能	ハートビートI/Fの送信方法のブロードキャストは廃止されました。 以前のバージョンで作成されたクラスタ構成情報を使用した場合、ユニキャストでハートビートを送信します。
CLUSTERPRO タスクマネージャ	-
CLUSTERPRO クライアント	-
ロードバランサ連携機能 (JVM監視リソース)	-
SCVMMを利用した仮想マシン強制停止機能	-
ミラーコネクト監視リソース （ミラーディスク監視リソースに統合されました）	ミラーコネクト監視リソースを削除してください。

6.6.3. パラメータ削除一覧

Cluster WebUI で設定可能なパラメータのうち、各バージョンで削除されたものについて、以下の表に示します。

内部バージョン 12.00

クラスタ

パラメータ	既定値
クラスタのプロパティ
WebManager タブ
WebManager Mobile の接続を許可する	オフ
WebManager Mobile 用パスワード
操作用パスワード	-
参照用パスワード	-

JVM 監視リソース

パラメータ	既定値
JVM監視リソースのプロパティ
監視 (固有) タブ
メモリタブ([JVM種別]に[Oracle Java]を選択した場合)
仮想メモリ使用量を監視する	2048 [MB]
メモリタブ([JVM種別]に[Oracle Java(usage monitoring)]を選択した場合)
仮想メモリ使用量を監視する	2048 [MB]

ユーザ空間監視リソース

パラメータ	既定値
ユーザ空間監視リソースのプロパティ
監視 (固有) タブ
ハートビートのインターバル/タイムアウトを使用する	オン

内部バージョン 12.10

クラスタ

パラメータ	既定値
クラスタのプロパティ
WebManager タブ
WebManager 調整プロパティ
動作タブ
アラートビューア最大レコード数	300
クライアントデータ更新方法	Real Time

仮想コンピュータ名リソース

パラメータ	既定値
仮想コンピュータ名リソースのプロパティ
詳細タブ
仮想コンピュータ名リソース調整プロパティ
パラメータタブ
対応付ける IP アドレス 7	FIP

7

[対応付ける IP アドレス] の選択肢からPublic を削除しました。[Public] を設定している構成情報を使用する場合も変更の必要はありません。IP アドレスの変更をする場合、[任意のIPアドレス]を選択し IP アドレスを指定してください。

内部バージョン 13.00

クラスタ

パラメータ	既定値
クラスタのプロパティ
インタコネクトタブ
ブロードキャスト/ユニキャスト	ユニキャスト
アラートサービスタブ
筐体 ID ランプ連携を使用する	オフ
筐体 ID ランプ点滅コマンド	-
インターバル	-
拡張タブ
仮想マシン強制停止設定 仮想マシン管理ツール	vCenter
仮想マシン強制停止設定 コマンド	C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\apps\vm\vmcontrol.pl
強制停止スクリプトを使用する	オフ
サーバのプロパティ
情報タブ
仮想マシン	オフ
種類	vSphere
BMCタブ
強制停止コマンドライン	-
筐体IDランプ 点滅 / 消灯	-

内部バージョン 13.10

仮想 IP リソース

パラメータ	既定値
仮想 IP リソースのプロパティ
詳細タブ
仮想 IP リソース調整プロパティ
RIP タブ
ネクストホップ IP アドレス	-

内部バージョン 13.20

クラスタ

パラメータ	既定値
クラスタのプロパティ
RIP（互換）タブ
ネットワークアドレス	-

グループ

パラメータ	既定値
グループのプロパティ
論理サービスタブ
論理サービス名	-

アプリケーションリソース

パラメータ	既定値
アプリケーションリソースのプロパティ
詳細タブ
アプリケーションリソース調整プロパティ
パラメータタブ
デスクトップとの対話を許可する	オフ

スクリプトリソース

パラメータ	既定値
スクリプトリソースのプロパティ
詳細タブ
スクリプトリソース調整プロパティ
デスクトップとの対話を許可する	オフ

6.6.4. 既定値変更一覧

Cluster WebUI で設定可能なパラメータのうち、各バージョンで既定値が変更されたものについて、以下の表に示します。

• バージョンアップ後も [変更前の既定値] の設定を継続したい場合は、バージョンアップ後に改めてその値に再設定してください。

• [変更前の既定値] 以外の値を設定していた場合、バージョンアップ後もそれ以前の設定値が継承されます。再設定の必要はありません。

内部バージョン 12.00

クラスタ

パラメータ	変更前の既定値	変更後の既定値	備考
クラスタのプロパティ
JVM監視タブ
最大Javaヒープサイズ	7[MB]	16[MB]
拡張タブ
フェイルオーバ回数のカウント単位	クラスタ	サーバ

グループリソース 共通

パラメータ	変更前の既定値	変更後の既定値	備考
リソース共通のプロパティ
復旧動作タブ
フェイルオーバしきい値	サーバ数に合わせる	1 [回]	[クラスタプロパティ] - [拡張タブ] - [フェイルオーバ回数のカウント単位]の既定値変更に伴う変更。

アプリケーションリソース

パラメータ	変更前の既定値	変更後の既定値	備考
アプリケーションリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ハイブリッドディスクリソース - ミラーディスクリソース - プリントスプーラリソース - レジストリ同期リソース - CIFS リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - Azure プローブポートリソース	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ハイブリッドディスクリソース - ミラーディスクリソース - プリントスプーラリソース - レジストリ同期リソース - CIFS リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

レジストリ同期リソース

パラメータ	変更前の既定値	変更後の既定値	備考
レジストリ同期リソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - Azure プローブポートリソース	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

スクリプトリソース

パラメータ	変更前の既定値	変更後の既定値	備考
スクリプトリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - Azure プローブポートリソース	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

サービスリソース

パラメータ	変更前の既定値	変更後の既定値	備考
サービスリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - Azure プローブポートリソース	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

モニタリソース 共通

パラメータ	変更前の既定値	変更後の既定値	備考
モニタリソース共通のプロパティ
回復動作タブ
最大フェイルオーバ回数	サーバ数に合わせる	1 [回]	[クラスタプロパティ] - [拡張タブ] - [フェイルオーバ回数のカウント単位]の既定値変更に伴う変更。

アプリケーション監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
アプリケーション監視リソースのプロパティ
監視 (共通) タブ
監視開始待ち時間	0[秒]	3[秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

フローティング IP 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
フローティング IP 監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	60 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

NIC Link Up/Down 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
NIC Link Up/Down 監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	60 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

レジストリ同期監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
レジストリ同期監視リソースのプロパティ
監視 (共通) タブ
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

サービス監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
サービス監視リソースのプロパティ
監視 (共通) タブ
監視開始待ち時間	0[秒]	3[秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

プリントスプーラ監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
プリントスプーラ監視リソースのプロパティ
監視 (共通) タブ
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

仮想コンピュータ名監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
仮想コンピュータ名監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	60 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

仮想 IP 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
仮想 IP 監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	60 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

カスタム監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
カスタム監視リソースのプロパティ
監視 (共通) タブ
監視開始待ち時間	0[秒]	3[秒]

プロセス名監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
プロセス名監視リソースのプロパティ
監視 (共通) タブ
監視開始待ち時間	0[秒]	3[秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

SQL Server 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
SQL Server 監視リソースのプロパティ
監視 (固有) タブ
ODBC ドライバ名	SQL Native Client	ODBC Driver 13 for SQL Server

WebLogic 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
WebLogic 監視リソースのプロパティ
監視 (固有) タブ
インストールパス	C:\bea\weblogic92	C:\Oracle\Middleware\Oracle_Home\wlserver

JVM 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
JVM監視リソースのプロパティ
監視(共通)タブ
タイムアウト	120[秒]	180 [秒]

ダイナミック DNS 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
ダイナミックDNS監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	120 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

AWS Elastic IP 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
AWS Elastic IP監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	100 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

AWS 仮想 IP 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
AWS 仮想IP監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	100 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

AWS AZ 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
AWS AZ監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	100 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

Azure プローブポート監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
Azure プローブポート監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	100 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

Azure ロードバランス監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
Azure ロードバランス監視リソースのプロパティ
監視 (共通) タブ
タイムアウト	100 [秒]	180 [秒]
タイムアウト発生時にリトライしない	オフ	オン
タイムアウト発生時に回復動作を実行しない	オフ	オン

内部バージョン 12.10

スクリプトリソース

パラメータ	変更前の既定値	変更後の既定値	備考
スクリプトリソースのプロパティ
詳細タブ
スクリプトリソース調整プロパティ
パラメータタブ
リカバリ処理を実行する	オン	オフ	内部バージョン12.00 以前では設定変更不可。12.10 より設定変更可能。

内部バージョン 12.20

サービスリソース

パラメータ	変更前の既定値	変更後の既定値	備考
サービスリソースのプロパティ
復旧動作タブ
活性リトライしきい値	0 [回]	1 [回]

AWS Elastic IP 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
AWS Elastic IP 監視リソースのプロパティ
監視 (固有) タブ
AWS CLI コマンド応答取得失敗時動作	回復動作を実行しない(警告を表示する)	回復動作を実行しない(警告を表示しない)

AWS 仮想 IP 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
AWS 仮想 IP 監視リソースのプロパティ
監視 (固有) タブ
AWS CLI コマンド応答取得失敗時動作	回復動作を実行しない(警告を表示する)	回復動作を実行しない(警告を表示しない)

AWS AZ 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
AWS AZ 監視リソースのプロパティ
監視 (固有) タブ
AWS CLI コマンド応答取得失敗時動作	回復動作を実行しない(警告を表示する)	回復動作を実行しない(警告を表示しない)

AWS DNS 監視リソース

パラメータ	変更前の既定値	変更後の既定値	備考
AWS DNS 監視リソースのプロパティ
監視 (固有) タブ
AWS CLI コマンド応答取得失敗時動作	回復動作を実行しない(警告を表示する)	回復動作を実行しない(警告を表示しない)

内部バージョン 12.30

クラスタ

パラメータ	変更前の既定値	変更後の既定値	備考
クラスタのプロパティ
拡張タブ
最大再起動回数	0 [回]	3 [回]
最大再起動回数をリセットする時間	0 [分]	60 [分]
API タブ
通信方式	HTTP	HTTPS

内部バージョン 12.32

AWS DNS リソース

パラメータ	変更前の規定値	変更後の規定値	備考
AWS DNS リソースのプロパティ
詳細 タブ
非活性時にリソースレコードセットを削除する	オン	オフ

内部バージョン 13.00

アプリケーションリソース

パラメータ	変更前の既定値	変更後の既定値	備考
アプリケーションリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ハイブリッドディスクリソース - ミラーディスクリソース - プリントスプーラリソース - レジストリ同期リソース - CIFS リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ハイブリッドディスクリソース - ミラーディスクリソース - プリントスプーラリソース - レジストリ同期リソース - CIFS リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

レジストリ同期リソース

パラメータ	変更前の既定値	変更後の既定値	備考
レジストリ同期リソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

スクリプトリソース

パラメータ	変更前の既定値	変更後の既定値	備考
スクリプトリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

サービスリソース

パラメータ	変更前の既定値	変更後の既定値	備考
サービスリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - CIFS リソース - ディスクリソース - ハイブリッドディスクリソース - フローティング IP リソース - プリントスプーラリソース - ミラーディスクリソース - レジストリ同期リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース

仮想コンピュータ名リソース

パラメータ	変更前の既定値	変更後の既定値	備考
仮想コンピュータ名のプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - Azure プローブポートリソース	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS セカンダリ IP リソース - Azure プローブポートリソース

CIFS リソース

パラメータ	変更前の既定値	変更後の既定値	備考
CIFS リソースのプロパティ
詳細タブ
共有設定復元時の失敗を活性異常とする	オン	オフ

ダイナミックDNSリソース

パラメータ	変更前の既定値	変更後の既定値	備考
ダイナミックDNSのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - Azure プローブポートリソース	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想IPリソース - AWS セカンダリ IP リソース - Azure プローブポートリソース

内部バージョン 13.10

クラスタ

パラメータ	変更前の既定値	変更後の既定値	備考
クラスタのプロパティ
WebManager タブ
Cluster WebUI の操作ログを出力する	オフ	オン

内部バージョン 13.20

クラスタ

パラメータ	変更前の既定値	変更後の既定値	備考
クラスタのプロパティ
統計情報タブ
システムリソース統計情報
統計情報を採取する	オフ	オン

Azure プローブポートリソース

パラメータ	変更前の既定値	変更後の既定値	備考
Azure プローブポートリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - 依存するリソースはありません	オン - アプリケーションリソース - スクリプトリソース - サービスリソース

Google Cloud 仮想 IP リソース

パラメータ	変更前の既定値	変更後の既定値	備考
Google Cloud 仮想 IP リソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - 依存するリソースはありません	オン - アプリケーションリソース - スクリプトリソース - サービスリソース

Oracle Cloud 仮想 IP リソース

パラメータ	変更前の既定値	変更後の既定値	備考
Oracle Cloud 仮想 IP リソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - 依存するリソースはありません	オン - アプリケーションリソース - スクリプトリソース - サービスリソース

アプリケーションリソース

パラメータ	変更前の既定値	変更後の既定値	備考
アプリケーションリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure DNS リソース

スクリプトリソース

パラメータ	変更前の既定値	変更後の既定値	備考
スクリプトリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure DNS リソース

サービスリソース

パラメータ	変更前の既定値	変更後の既定値	備考
サービスリソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure DNS リソース

レジストリ同期リソース

パラメータ	変更前の既定値	変更後の既定値	備考
レジストリ同期リソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure プローブポートリソース - Azure DNS リソース	オン - フローティング IP リソース - 仮想 IP リソース - 仮想コンピュータ名リソース - ディスクリソース - ミラーディスクリソース - ハイブリッドディスクリソース - CIFS リソース - レジストリ同期リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - AWS DNS リソース - Azure DNS リソース

ダイナミック DNS リソース

パラメータ	変更前の既定値	変更後の既定値	備考
ダイナミック DNS リソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - Azure プローブポートリソース	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース

仮想コンピュータ名リソース

パラメータ	変更前の既定値	変更後の既定値	備考
仮想コンピュータ名リソースのプロパティ
依存関係タブ
既定の依存関係に従う	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース - Azure プローブポートリソース	オン - フローティング IP リソース - 仮想 IP リソース - AWS Elastic IPリソース - AWS 仮想 IP リソース - AWS セカンダリ IP リソース

6.6.5. パラメータ移動一覧

Cluster WebUI で設定可能なパラメータのうち、各バージョンで設定箇所が変更されたものについて、以下の表に示します。

内部バージョン 12.00

変更前の設定箇所	変更後の設定箇所
[クラスタのプロパティ]-[リカバリタブ]-[最大再起動回数]	[クラスタのプロパティ]-[拡張タブ]-[最大再起動回数]
[クラスタのプロパティ]-[リカバリタブ]-[最大再起動回数をリセットする時間]	[クラスタのプロパティ]-[拡張タブ]-[最大再起動回数をリセットする時間]
[クラスタのプロパティ]-[リカバリタブ]-[強制停止機能を使用する]	[クラスタのプロパティ]-[拡張タブ]-[強制停止機能を使用する]
[クラスタのプロパティ]-[リカバリタブ]-[強制停止アクション]	[クラスタのプロパティ]-[拡張タブ]-[強制停止アクション]
[クラスタのプロパティ]-[リカバリタブ]-[強制停止タイムアウト]	[クラスタのプロパティ]-[拡張タブ]-[強制停止タイムアウト]
[クラスタのプロパティ]-[リカバリタブ]-[仮想マシン強制停止設定]	[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]]
[クラスタのプロパティ]-[リカバリタブ]-[強制停止スクリプトを実行する]	[クラスタのプロパティ]-[拡張タブ]-[強制停止スクリプトを実行する]
[クラスタのプロパティ]-[自動復帰タブ]-[自動復帰]	[クラスタのプロパティ]-[拡張タブ]-[自動復帰]
[クラスタのプロパティ]-[リカバリタブ]-[モニタリソース異常時の回復動作を抑制する]	[クラスタのプロパティ]-[拡張タブ]-[クラスタ動作の無効化]-[モニタリソースの異常時の回復動作]
[グループのプロパティ]-[属性タブ]- [フェイルオーバ排他属性]	[グループ共通のプロパティ] -[排他タブ]

内部バージョン 13.00

変更前の設定箇所	変更後の設定箇所
[クラスタのプロパティ]-[拡張タブ]-[強制停止機能を使用する]	[クラスタのプロパティ]-[フェンシングタブ]-[強制停止]-[タイプ]
[クラスタのプロパティ]-[拡張タブ]-[強制停止アクション]	[BMC強制停止のプロパティ]-[強制停止タブ]-[強制停止アクション]
[クラスタのプロパティ]-[拡張タブ]-[強制停止タイムアウト]	[BMC強制停止のプロパティ]-[強制停止タブ]-[強制停止タイムアウト]
[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]-[アクション]	[vCenter強制停止のプロパティ]-[強制停止タブ]-[強制停止アクション]
[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]-[タイムアウト]	[vCenter強制停止のプロパティ]-[強制停止タブ]-[強制停止タイムアウト]
[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]-[ホスト名]	[vCenter強制停止のプロパティ]-[vCenterタブ]-[ホスト名]
[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]-[ユーザ名]	[vCenter強制停止のプロパティ]-[vCenterタブ]-[ユーザ名]
[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]-[パスワード]	[vCenter強制停止のプロパティ]-[vCenterタブ]-[パスワード]
[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]-[Perlパス]	[vCenter強制停止のプロパティ]-[vCenterタブ]-[Perlパス]
[サーバのプロパティ]-[BMCタブ]-[IPアドレス]	[BMC強制停止のプロパティ]-[サーバ一覧タブ]-[BMCの入力]-[IPアドレス]
[サーバのプロパティ]-[BMCタブ]-[ユーザ名]	[BMC強制停止のプロパティ]-[サーバ一覧タブ]-[BMCの入力]-[ユーザ名]
[サーバのプロパティ]-[BMCタブ]-[パスワード]	[BMC強制停止のプロパティ]-[サーバ一覧タブ]-[BMCの入力]-[パスワード]

内部バージョン 13.10

変更前の設定箇所	変更後の設定箇所
[クラスタのプロパティ]-[監視タブ]	[クラスタのプロパティ]-[統計情報タブ]
[クラスタのプロパティ]-[ミラーディスクタブ]-[統計情報を採取する]	[クラスタのプロパティ]-[統計情報タブ]-[ミラー統計情報]
[クラスタのプロパティ]-[拡張タブ]-[クラスタ統計情報]	[クラスタのプロパティ]-[統計情報タブ]-[クラスタ統計情報]

6.7. 旧バージョンとの互換性

6.7.1. CLUSTERPRO X 1.0/2.0/2.1/3.0/3.1/3.2/3.3/4.0/4.1/4.2/4.3/5.0/5.1 との互換性について

X 1.0/2.0/2.1/3.0/3.1/3.2/3.3/4.0/4.1/4.2/4.3/5.0/5.1 で作成したクラスタ構成情報は X 5.2 以降でも使用できます。ただし、X 2.0 以降ではグループリソース・モニタリソースの異常検出時のフェイルオーバ先サーバ選択方式が既定値の [安定動作サーバ] となるため、3 ノード以上の構成の場合にフェイルオーバ先の選択結果が X 1.0 と異なる場合があります。

フェイルオーバ先が複数ある場合に、[安定動作サーバ] に設定していると、フェイルオーバ先でさらに異常が発生した場合に、まだ異常が発生していないサーバに優先的にフェイルオーバすることができます。これに対し、X 1.0 の場合、移動可能なサーバの中で最もプライオリティの高いサーバにフェイルオーバしますので、最初に異常が発生していたサーバにフェイルバックしてしまい、3台目のサーバにフェイルオーバできない場合があります。

このため、通常は [安定動作サーバ] に設定することを推奨していますが、X 1.0 と同じ動作にする必要がある場合は、各リソースのプロパティの設定タブで、フェイルオーバ先サーバ設定を [最高プライオリティサーバ] に変更してください。

6.7.2. スクリプトファイルについて

CLUSTERPRO Ver 8.0 以前で使用していたスクリプトファイルを移植する場合、環境変数名の最初の "ARMS_" を "CLP_" に置換してください。

例） IF "%ARMS_EVENT%" == "START" GOTO NORMAL

    ↓

    IF "%CLP_EVENT%" == "START" GOTO NORMAL

7. 用語集

インタコネクト

クラスタ サーバ間の通信パス

(関連) プライベート LAN、パブリック LAN

仮想 IP アドレス

遠隔地クラスタを構築する場合に使用するリソース(IP アドレス)

管理クライアント

Cluster WebUI が起動されているマシン

起動属性

クラスタ起動時、自動的にフェイルオーバグループを起動するか、手動で起動するかを決定するフェイル オーバ グループの属性

管理クライアントより設定が可能

共有ディスク

複数サーバよりアクセス可能なディスク

共有ディスク型クラスタ

共有ディスクを使用するクラスタシステム

切替パーティション

複数のコンピュータに接続され、切り替えながら使用可能なディスクパーティション

(関連) ディスクハートビート用パーティション

クラスタシステム

複数のコンピュータを LAN などでつないで、1つのシステムのように振る舞わせるシステム形態

クラスタシャットダウン

クラスタシステム全体 (クラスタを構成する全サーバ)をシャットダウンさせること

クラスタパーティション

ミラーディスクまたはハイブリッドディスクに設定するパーティション。ミラーディスクやハイブリッドディスクの管理に使用する。

(関連) ディスクハートビート用パーティション

現用系

ある 1 つの業務セットについて、業務が動作しているサーバ

(関連) 待機系

サーバグループ

同じネットワークや共有ディスク装置に接続しているサーバの集合

セカンダリ (サーバ)

通常運用時、フェイルオーバグループがフェイルオーバする先のサーバ

(関連) プライマリ (サーバ)

待機系

現用系ではない方のサーバ

(関連) 現用系

ディスクハートビート用パーティション

共有ディスク型クラスタで、ハートビート通信に使用するためのパーティション

データパーティション

共有ディスクの切替パーティションのように使用することが可能なローカルディスク

ミラーディスクに設定するデータ用のパーティション

(関連) クラスタパーティション

ネットワークパーティション

全てのハートビートが途切れてしまうこと

(関連) インタコネクト、ハートビート

ノード

クラスタシステムでは、クラスタを構成するサーバを指す。ネットワーク用語では、データを他の機器に経由することのできる、コンピュータやルータなどの機器を指す。

ハートビート

サーバの監視のために、サーバ間で定期的にお互いに通信を行うこと

(関連) インタコネクト、ネットワークパーティション

パブリック LAN

サーバ/クライアント間通信パスのこと

(関連) インタコネクト、プライベート LAN

フェイルオーバ

障害検出により待機系が、現用系上の業務アプリケーションを引き継ぐこと

フェイルバック

あるサーバで起動していた業務アプリケーションがフェイルオーバにより他のサーバに引き継がれた後、業務アプリケーションを起動していたサーバに再び業務を戻すこと

フェイルオーバグループ

業務を実行するのに必要なクラスタリソース、属性の集合

フェイルオーバグループの移動

ユーザが意図的に業務アプリケーションを現用系から待機系に移動させること

フェイルオーバ ポリシー

フェイルオーバ可能なサーバリストとその中でのフェイルオーバ優先順位を持つ属性

プライベート LAN

クラスタを構成するサーバのみが接続された LAN

(関連) インタコネクト、パブリック LAN

プライマリ (サーバ)

フェイルオーバグループでの基準で主となるサーバ

(関連) セカンダリ (サーバ)

フローティング IP アドレス

フェイルオーバが発生したとき、クライアントのアプリケーションが接続先サーバの切り替えを意識することなく使用できる IP アドレス

クラスタサーバが所属する LAN と同一のネットワーク アドレス内で、他に使用されていないホストアドレスを割り当てる

マスタサーバ

Cluster WebUI の設定モード の [サーバ共通のプロパティ]-[マスタサーバ] で先頭に表示されているサーバ

ミラーディスクコネクト

データミラー型クラスタでデータのミラーリングを行うために使用する LAN。プライマリインタコネクトと兼用で設定することが可能。

ミラーディスクシステム

共有ディスクを使用しないクラスタシステム

サーバのローカルディスクをサーバ間でミラーリングする