1. はじめに¶

1.1. 対象読者と目的¶

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

1.2. 本書の構成¶

「2. クラスタシステムとは?」：クラスタシステムの概要について説明します。
「3. CLUSTERPRO について」：クラスタシステムの概要について説明します。
「4. CLUSTERPRO の動作環境」：導入前に確認が必要な最新情報について説明します。
「5. 最新バージョン情報」：CLUSTERPRO の最新バージョンについての情報を示します。
「6. 注意制限事項」：既知の問題と制限事項について説明します。

1.3. CLUSTERPRO マニュアル体系¶

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

『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 のメンテナンス関連情報を記載します。

『CLUSTERPRO X ハードウェア連携ガイド』 (Hardware Feature Guide)

管理者、および CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアを対象読者とし、特定ハードウェアと連携する機能について記載します。『インストール&設定ガイド』を補完する役割を持ちます。

『CLUSTERPRO X 互換機能ガイド』 (Legacy Feature Guide)

管理者、および CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアを対象読者とし、CLUSTERPRO X 4.0 WebManager、Builder および CLUSTERPRO Ver 8.0 互換コマンドに関する情報について記載します。

1.4. 本書の表記規則¶

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

注釈

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

重要

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

参考

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

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

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

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 クラスタの導入が求められています。

図 2.1 HA クラスタ構成図¶

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

2.2.1. 共有ディスク型¶

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

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

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

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

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

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

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

また、下記の図のように、業務が 1 つであり、待機系では業務が動作しないスタンバイ形態を片方向スタンバイといいます。業務が 2 つ以上で、それぞれのノードが現用系かつ待機系である形態を双方向スタンバイといいます。

図 2.3 HA クラスタの運用形態¶

2.2.2. ミラーディスク型¶

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

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

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

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

図 2.4 データミラーの仕組み¶

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

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

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

2.3. システム構成¶

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

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

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

図 2.5 システム構成¶

フェイルオーバ型クラスタは、運用形態により、次のように分類できます。
片方向スタンバイクラスタ
一方のサーバを運用系として業務を稼動させ、他方のサーバを待機系として業務を稼動させない運用形態です。最もシンプルな運用形態でフェイルオーバ後の性能劣化のない可用性の高いシステムを構築できます。

図 2.6 片方向スタンバイクラスタ¶

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

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

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

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

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

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

N + N 構成

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

図 2.9 N + N 構成¶

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

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

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

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

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

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

リソースの障害検出

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. データの引き継ぎ¶

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

図 2.11 データの引き継ぎ¶

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

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

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

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

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

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

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

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

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

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

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

障害検出 (ハートビート/リソース監視)
ネットワークパーティション状態の解決 (NP解決)
クラスタ資源切り替え
- データの引き継ぎ
- IP アドレスの引き継ぎ
- アプリケーションの引き継ぎ

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

クラスタソフトウェアは、フェイルオーバ実現のため、これらの様々な処置を 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.13 共有ディスクの RAID コントローラとアクセスパスが SPOF となっている例 (左) と RAID コントローラとアクセスパスを分割した例¶

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

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

ネットワークを介してデータをミラーリングすることによるディスク I/O 性能 (特に write 性能) の低下
サーバ障害後の復旧における、ミラー再同期中のシステム性能 (ミラーコピーはバックグラウンドで実行される) の低下
ミラー再同期時間 (ミラー再同期が完了するまでフェイルオーバできない)

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

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

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

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

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

2.6.3. LAN¶

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

図 2.15 ルータが 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 ブラウザでも利用できます。

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

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

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

3.3.2. サーバ監視とは¶

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

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

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

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

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

フェイルオーバ型クラスタを構成するサーバ間を、BMC を介してハートビート通信を行い、他サーバの生存を確認します。
Witness

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

図 3.2 サーバ監視¶

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

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

COM 方式
PING 方式
HTTP 方式
共有ディスク方式
COM + 共有ディスク方式
PING + 共有ディスク方式
多数決方式
ネットワークパーティション解決しない

参考

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

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

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

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

注釈

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

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

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

ハートビートタイムアウト
- 業務を実行しているサーバの障害発生後、待機系がその障害を検出するまでの時間です。
- 業務の負荷等による遅延も考慮して、クラスタプロパティの設定値を調整します。
  
  (既定値では 30 秒です。)
ネットワークパーティション解決
- 相手サーバからのハートビートの途絶 (ハートビートタイムアウト) が、ネットワークパーティション状態によるものか、実際に相手サーバが障害を起こしたのかを確認するための時間です。
- ネットワークパーティション方式として共有ディスク方式が指定されている場合には、ディスク I/O の遅延を考慮した待ち時間が必要なため、既定値の設定で 30 秒～60 秒程の時間を要します。この所要時間はクラスタパーティションへのアクセス時間や、ハートビートタイムアウト値などに連動して変化します。その他の方式の場合、通常はほぼ瞬時に確認が完了します。
各種リソース活性化
- 業務で必要なリソースを活性化するための時間です。
- 一般的な設定では数秒で活性化しますが、フェイルオーバグループに登録されている資源の種類や数によって必要時間は変化します。
  
  (詳しくは、『インストール&設定ガイド』を参照してください。)
アプリケーション復旧処理・再起動
- 業務で使用するアプリケーションの起動に要する時間です。データベースのロールバック/ロールフォワードなどのデータ復旧処理の時間も含まれます。
- ロールバック/ロールフォワード時間などはチェックポイントインターバルの調整である程度予測可能です。詳しくは、各ソフトウェア製品のドキュメントを参照してください。

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

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

サーバ間の通信用に

NIC を 2 枚 (1 枚は外部との通信と流用、1 枚は CLUSTERPRO 専用)
RS-232C ケーブルで接続された COM ポート
共有ディスクの特定領域

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

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

図 3.4 共有ディスク使用時のクラスタ環境のサンプル¶

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

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

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

注釈

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

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

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

図 3.5 ミラーディスク使用時のクラスタ環境のサンプル¶

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

図 3.6 ミラーディスク使用時のクラスタ環境のサンプル¶

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

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

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

注釈

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

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

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

図 3.7 ハイブリッドディスク使用時のクラスタ環境のサンプル¶

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

図 3.8 ハイブリッドディスク使用時の遠隔クラスタ環境のサンプル¶

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

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

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

クラスタオブジェクト

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

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

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

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

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

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

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

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

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

3.6. リソースとは?¶

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

参考

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

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

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

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

LAN ハートビートリソース

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

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

BMC 経由で Ethernet を利用した通信を示します。BMC のハードウェアおよびファームウェアが対応している場合のみ利用可能です。

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

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

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

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

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

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

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

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

3.6.3. グループリソース¶

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

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

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

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

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

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

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

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

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

データベースや Web 等のサービスを起動/停止するための仕組みを提供します。
プリントスプーラリソース (spool)

プリントスプーラをフェイルオーバするための機能を提供します
仮想コンピュータ名リソース (vcom)

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

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

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

共有ディスク/ミラーディスク上のフォルダを共有公開するための機能を提供します。
NAS リソース (nas)

ファイルサーバ上の共有フォルダをネットワークドライブとしてマウントするための機能を提供します。
ハイブリッドディスクリソース (hd)

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

仮想マシンの起動、停止、マイグレーションを行います。
AWS Elastic IP リソース (awseip)

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

AWS 上で CLUSTERPRO を利用する場合、VIP を付与する仕組みを提供します。
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 Platform 上で CLUSTERPRO を利用する場合、業務が稼働するノードで特定のポートを開放する仕組みを提供します。
Oracle Cloud 仮想 IP リソース (ocvip)

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

注釈

ミラーディスクリソースを使用するためには、『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)

ミラーディスクの監視機構を提供します。
ミラーコネクト監視リソース (mdnw)

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

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

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

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

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

サービスリソースで起動したプロセスの死活監視機能を提供します。
プリントスプーラ監視リソース (spoolw)

プリントスプーラリソースで起動したプリントスプーラの監視機構を提供します。
仮想コンピュータ名監視リソース (vcomw)

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

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

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

CIFS リソースで公開した共有フォルダの監視機構を提供します。
NAS 監視リソース (nasw)

NAS リソースでマウントしたネットワークドライブの監視機構を提供します。
ハイブリッドディスク監視リソース (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 アプリケーションサーバへの監視機構を提供します。
仮想マシン監視リソース (vmw)

仮想マシンリソースで起動した仮想マシンの監視機構を提供します。
外部連携監視リソース (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 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 リソースが起動していないノードに対して、ヘルスチェック用ポートと同じポート番号が開放されていないかの監視機構を提供します。
Oracle Cloud 仮想 IP 監視リソース (ocvipw)

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

Oracle Cloud 仮想 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』のライセンスが必要です。
システム監視リソース、プロセスリソース監視リソースを使用するためには『CLUSTETRPRO X System Resoruce 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.1. ハードウェア動作環境¶

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

x86_64

4.1.1. 必要スペック¶

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

RS-232C ポート 1 つ ( 3 ノード以上のクラスタを構築する場合は不要)
Ethernet ポート 2 つ以上
共有ディスク、ミラー用ディスクまたはミラー用空きパーティション (ミラーディスクを使用する場合)
CD-ROM ドライブ

4.1.2. Express5800/A1080a,A1040a シリーズとの連携に対応したサーバ¶

BMC ハートビートリソースおよび外部連携モニタリソースの Express5800/A1080a,A1040a シリーズ連携機能が利用可能なサーバは下記の通りです。本機能は下記のサーバ以外では利用できません。

サーバ	備考
Express5800/A1080a-E	最新のファームウェアにアップデートしてください。
Express5800/A1080a-D	最新のファームウェアにアップデートしてください。
Express5800/A1080a-S	最新のファームウェアにアップデートしてください。
Express5800/A1040a	最新のファームウェアにアップデートしてください。

4.2. CLUSTERPRO Server の動作環境¶

4.2.1. 対応 OS¶

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

x86_64 版

OS	備考
Windows Server 2012 Standard
Windows Server 2012 Datacenter
Windows Server 2012 R2 Standard
Windows Server 2012 R2 Datacenter
Windows Server 2016 Standard
Windows Server 2016 Datacenter
Windows Server, version 1709 Standard
Windows Server, version 1709 Datacenter
Windows Server, version 1803 Standard
Windows Server, version 1803 Datacenter
Windows Server, version 1809 Standard
Windows Server, version 1809 Datacenter
Windows Server 2019 Standard
Windows Server 2019 Datacenter
Windows Server, version 1903 Standard
Windows Server, version 1903 Datacenter
Windows Server, version 1909 Standard
Windows Server, version 1909 Datacenter

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

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

2: オプション類を除く
3: ミラーディスクリソースおよびハイブリッドディスクリソース使用時に必要なメモリサイズです。

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

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

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

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

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

x86_64 版

モニタリソース	監視対象のアプリケーション	CLUSTERPRO Version
Oracle 監視	Oracle Database 12c Release 1 (12.1)	12.00~
	Oracle Database 12c Release 2 (12.2)	12.00~
	Oracle Database 18c (18.3)	12.10~
	Oracle Database 19c (19.3)	12.10~
DB2 監視	DB2 V10.5	12.00~
	DB2 V11.1	12.00~
	DB2 V11.5	12.20~
PostgreSQL 監視	PostgreSQL 9.3	12.00~
	PostgreSQL 9.4	12.00~
	PostgreSQL 9.5	12.00~
	PostgreSQL 9.6	12.00~
	PostgreSQL 10	12.00~
	PostgreSQL 11	12.10~
	PostgreSQL 12	12.22~
	PowerGres on Windows V9.1	12.00~
	PowerGres on Windows V9.4	12.00~
	PowerGres on Windows V9.6	12.00~
	PowerGres on Windows V11	12.10~
SQL Server 監視	SQL Server 2014	12.00~
	SQL Server 2016	12.00~
	SQL Server 2017	12.00~
	SQL Server 2019	12.20~
Tuxedo 監視	Tuxedo 12c Release 2 (12.1.3)	12.00~
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~
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 Enterprise Service Bus V8.4	12.00~
	WebOTX Enterprise Service Bus V8.5	12.00~
	Apache Tomcat 8.0	12.00~
	Apache Tomcat 8.5	12.00~
	Apache Tomcat 9.0	12.00~
	WebSAM SVF for PDF 9.1	12.00~
	WebSAM SVF for PDF 9.2	12.00~
	WebSAM Report Director Enterprise 9.1	12.00~
	WebSAM Report Director Enterprise 9.2	12.00~
	WebSAM Universal Connect/X 9.1	12.00~
	WebSAM Universal Connect/X 9.2	12.00~
システム監視	バージョン指定無し	12.00~
プロセスリソース監視	バージョン指定無し	12.10~

注釈

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

4.2.4. 仮想マシンリソースの動作環境¶

仮想マシンリソースの動作確認を行った仮想化基盤のバージョン情報を下記に提示します。

仮想化基盤	バージョン	備考
Hyper-V	Windows Server 2012 Hyper-V
	Windows Server 2012 R2 Hyper-V

注釈

仮想マシンリソースは Windows Server 2016 上では動作しません。

4.2.5. SNMP 連携機能の動作環境¶

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

x86_64 版

OS	CLUSTERPRO Version	備考
Windows Server 2012	12.00~
Windows Server 2012 R2	12.00~
Windows Server 2016	12.00~
Windows Server, version 1709	12.00~

4.2.6. JVM 監視の動作環境¶

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

Java(TM) Runtime Environment
Version7.0 Update 6 (1.7.0_6) 以降

Java(TM) Runtime Environment
Version8.0 Update 11 (1.8.0_11) 以降

Java(TM) Runtime Environment
Version9.0 (9.0.1) 以降

JVM監視 ロードバランサ連携機能(BIG-IP Local Traffic Managerと連携する場合)を使用するには、Microsoft .NET Framework の実行環境が必要です。

Microsoft .NET Framework 3.5 Service Pack 1
Microsoft .NET Framework 3.5 SP1 日本語 Language Pack

インストール手順

サーバがインターネットにつながらない状態の場合、OS のインストール媒体を用意してください。インターネットにつながる状態の場合は必要ありません。
[ サーバー マネージャー ] を起動し、[ ダッシュボード ] 画面で[ クイックスタート ] を選択してください。
表示されたメニューから[  2) 役割と機能の追加 ] を選択し、[ 役割と機能の追加ウィザード ] を表示します。

図 4.1 サーバーマネージャー¶

[ 開始する前に ] 画面が表示された場合、[ 次へ ] をクリックします。
[ インストールの種類 ] 画面で[ 役割ベースまたは機能ベースのインストール ] を選択し、[ 次へ ] をクリックします。
[ サーバーの選択 ] 画面で[ サーバー プールからサーバーを選択 ] を選択し、一覧から対象サーバを選択して[ 次へ ] をクリックします。

図 4.2 対象サーバの選択¶

[ サーバーの役割 ] 画面で[ 次へ ] をクリックしてください。

[ 機能 ] 画面で[ .Net Framework 3.5 Features ] にチェックを入れ、[ 次へ ] をクリックします。

図 4.3 機能の選択¶

サーバがインターネットにつながる状態の場合、[ 確認 ] 画面で[ インストール ] をクリックし、.Net Framework 3.5をインストールしてください。

サーバがインターネットにつながらない状態の場合、[ 確認 ] 画面で[ 代替ソースパスの指定 ] を選択してください。

図 4.4 インストールオプションの確認¶

表示された画面の説明を参考に[ パス ] 欄へOS インストール媒体のパスを指定し、[ OK ] をクリックしてください。その後[ インストール ] をクリックし、.Net Framework 3.5をインストールしてください。

図 4.5 代替ソースパスの指定¶

JVM監視ロードバランサ連携機能の動作確認を行ったロードバランサを下記に提示します。

x86_64 版

ロードバランサ	CLUSTERPRO Version	備考
Express5800/LB400h以降	12.00~
InterSec/LB400i 以降	12.00~
BIG-IP v11	12.00~
CoyotePoint Equalizer	12.00~

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

System Resource Agent を使用するには、Microsoft .NET Framework の実行環境が必要です。
Microsoft .NET Framework 4.5 以上
Microsoft .NET Framework 4.5 日本語 Language Pack 以上

注釈

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

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

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

ソフトウェア	Version	備考
AWS CLI	1.6.0~	AWS CLI バージョン 2 は未対応です
Python	2.7.5~ 3.6.7~	AWS CLI 付属の Python は不可

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

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

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

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

ソフトウェア	Version	備考
AWS CLI	1.11.0~	AWS CLI バージョン 2 は未対応です
Python	2.7.5~ 3.6.7~	AWS CLI 付属の Python は不可

AWS DNS リソース、AWS DNS 監視リソースの動作確認を行った AWS 上の OS のバージョン情報を下記に提示します。

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

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

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

ディストリビューション	CLUSTERPRO Version	備考
Windows Server 2012	12.00~
Windows Server 2012 R2	12.00~
Windows Server 2016	12.00~
Windows Server, version 1709	12.00~
Windows Server 2019	12.10~

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

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

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

4.2.11. 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 上の OS のバージョン情報を下記に提示します。

ディストリビューション	CLUSTERPRO Version	備考
Windows Server 2012	12.00~
Windows Server 2012 R2	12.00~
Windows Server 2016	12.00~
Windows Server, version 1709	12.00~
Windows Server 2019	12.10~

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

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

デプロイモデル

CLUSTERPRO

Version

備考

リソースマネージャー

12.00~

Azure DNS の追加が必要

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

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

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

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

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

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

4.2.14. SAP 連携コネクタの動作環境¶

SAP 連携コネクタの動作確認を行った OS および SAP NetWeaver（以降、SAP NW）のバージョン情報を下記に提示します。

NW Version	SAPカーネルバージョン	CLUSTERPRO Version	OS	クラスタ構成
7.4	745 749 753	12.01~	Microsoft Windows Server 2012 Microsoft Windows Server 2012 R2 Microsoft Windows Server 2016	SAN接続、共有ディスク型ミラーディスク型
7.5	745 749 753	12.00~	Microsoft Windows Server 2012 Microsoft Windows Server 2012 R2 Microsoft Windows Server 2016	SAN接続、共有ディスク型ミラーディスク型
7.52	753	12.10~	Microsoft Windows Server 2012 Microsoft Windows Server 2012 R2 Microsoft Windows Server 2016	SAN接続、共有ディスク型ミラーディスク型
7.52	753	12.20~	Microsoft Windows Server 2012 Microsoft Windows Server 2012 R2 Microsoft Windows Server 2016 Microsoft Windows Server 2019	SAN接続、共有ディスク型ミラーディスク型

SAP NWのハードウェア要件およびソフトウェア要件は、SAP NWのドキュメントを参照してください。

4.3. Cluster WebUI の動作環境¶

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

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

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

ブラウザ	言語
Internet Explorer 11	日本語/英語/中国語
Internet Explorer 10	日本語/英語/中国語
Firefox	日本語/英語/中国語
Google Chrome	日本語/英語/中国語

注釈

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

注釈

Internet Explorer 11 にて Cluster WebUI に接続すると、Internet Explorer が停止することがあります。本事象回避のために、Internet Explorer のアップデート (KB4052978 以降) を適用してください。なお、Windows 8.1/Windows Server 2012R2 に KB4052978 以降を適用するためには、事前に KB2919355 の適用が必要となります。詳細は Microsoft より展開されている情報をご確認ください。

注釈

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

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

必要メモリ容量　　 500MB 以上
必要ディスク容量　 200MB 以上

5. 最新バージョン情報¶

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

5.1. CLUSTERPRO とマニュアルの対応一覧
5.2. 機能強化
5.3. 修正情報

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

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

CLUSTERPROの内部バージョン	マニュアル	版数
12.22	スタートアップガイド	第 5 版
	インストール&設定ガイド	第 1 版
	リファレンスガイド	第 4 版
	メンテナンスガイド	第 2 版
	ハードウェア連携ガイド	第 1 版
	互換機能ガイド	第 2 版

5.2. 機能強化¶

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

項番	内部バージョン	機能強化項目
1	12.00	デザインを刷新した管理GUI (Cluster WebUI) を実装しました。
2	12.00	WebManager が HTTPS プロトコルに対応しました。
3	12.00	期限付きライセンスが利用可能になりました。
4	12.00	ミラーディスクリソース、ハイブリッドディスクリソースの最大数を拡大しました。
5	12.00	Windows Server, version 1709 に対応しました。
6	12.00	SQL Server 監視リソースが SQL Server 2017 に対応しました。
7	12.00	Oracle 監視リソースが Oracle Database 12c R2 に対応しました。
8	12.00	PostgreSQL 監視リソースが PowerGres on Windows 9.6 に対応しました。
9	12.00	WebOTX 監視リソースが WebOTX V10.1 に対応しました。
10	12.00	JVM 監視リソースが Apache Tomcat 9.0 に対応しました。
11	12.00	JVM 監視リソースが WebOTX V10.1 に対応しました。
12	12.00	JVM 監視リソースで以下の監視が可能になりました。 CodeHeap non-nmethods CodeHeap profiled nmethods CodeHeap non-profiled nmethods Compressed Class Space
13	12.00	AWS DNS リソース、AWS DNS 監視リソースを追加しました。
14	12	Azure DNS リソース、Azure DNS 監視リソースを追加しました。
15	12.00	クラスタ操作外の OS シャットダウンが実行された場合に、クラスタサービスの停止完了まで OS シャットダウンを延期させる機能を追加しました。
16	12.00	モニタリソースにおけるエラー判定およびタイムアウト判定の精度を改善しました。
17	12.00	グループリソースの活性/非活性の前後で、任意のスクリプトを実行する機能を追加しました。
18	12.00	両系活性検出時に生存させるサーバグループを選択可能にしました。
19	12.00	フェイルオーバ属性に [完全排他] が設定されているグループにて、排他の対象とする組み合わせを設定できるようになりました。
20	12.00	フェイルオーバ回数のカウント方式をサーバ単位/クラスタ単位から選択可能になりました。
21	12.00	内部プロセス間通信で消費されるTCPポート量を削減しました。
22	12.00	ログ収集で収集する項目を強化しました。
23	12.00	ミラーディスクリソース、ハイブリッドディスクリソースの差分ビットマップサイズを設定できるようになりました。
24	12.00	ミラーディスクリソース、ハイブリッドディスクリソースの非同期モードでの履歴記録領域サイズを設定できるようになりました。
25	12.01	WebManagerにおいて、設定不備によりHTTPSを使用できない場合に、イベントログおよびアラートログへメッセージを出力するようにしました。
26	12.10	Windows Server, version 1803 に対応しました。
27	12.10	Windows Server, version 1809 に対応しました。
28	12.10	Windows Server 2019 に対応しました。
29	12.10	Oracle 監視リソースが Oracle Database 18c に対応しました。
30	12.10	Oracle 監視リソースが Oracle Database 19c に対応しました。
31	12.10	PostgreSQL 監視リソースが PostgreSQL11 に対応しました。
32	12.10	PostgreSQL 監視リソースが PowerGres V11 に対応しました。
33	12.10	以下のリソース / モニタリソースが Python3 に対応しました。 AWS Elastic IP リソース AWS 仮想IP リソース AWS DNS リソース AWS Elastic IP 監視リソース AWS 仮想 IP 監視リソース AWS AZ 監視リソース AWS DNS 監視リソース
34	12.10	以下のリソース / モニタリソースが MSI インストーラや pip によりインストールされる AWS CLI(aws.cmd) に対応しました。 AWS Elastic IP リソース AWS 仮想 IP リソース AWS DNS リソース AWS Elastic IP 監視リソース AWS 仮想IP 監視リソース AWS AZ 監視リソース AWS DNS 監視リソース
35	12.10	SAP NetWeaver 用 SAP 連携コネクタが以下の SAP NetWeaver に対応しました。 SAP NetWeaver Application Server for ABAP 7.52
36	12.10	SAP NetWeaver 用 SAP 連携コネクタ / サンプルスクリプトが以下に対応しました。メンテナンスモード Standalone Enqueue Server 2
37	12.10	Cluster WebUI でクラスタの構築、構成変更が可能になりました。
38	12.10	PostgreSQL 用 DB 静止点コマンドを追加しました。
39	12.10	DB2 用 DB 静止点コマンドを追加しました。
40	12.10	Witness ハートビートリソースを追加しました。
41	12.10	HTTP ネットワークパーティション解決リソースを追加しました。
42	12.10	クラスタ構成の変更時、業務を停止せずに変更を反映可能な設定項目を拡充しました。
43	12.10	フェイルオーバグループの起動時に、フローティング IP アドレスの重複チェックを行う機能を追加しました。
44	12.10	遠隔クラスタ構成で、サーバグループ間のハートビートタイムアウトを検出しても、設定された時間だけ自動フェイルオーバを猶予する機能を追加しました。
45	12.10	スクリプトリソースの開始/終了スクリプトで使用できる環境変数を拡充しました。
46	12.10	強制停止スクリプトの実行結果を判定し、フェイルオーバを抑制する機能を追加しました。
47	12.10	強制停止機能における仮想マシン管理ツール (vCLI 6.5) で使用する perl.exeのパスを設定できるようにしました。
48	12.10	強制停止機能および筐体 ID 連携機能で実行する IPMI コマンドラインを編集できるようにしました。
49	12.10	プロセスリソース監視リソースを追加し、システム監視リソースのプロセスリソース監視機能を集約しました。
50	12.10	フェイルオーバグループ、グループリソース、モニタリソースの稼働状況をクラスタ統計情報として保存する機能を追加しました。
51	12.10	ログ収集のパターンに、ミラー統計情報とクラスタ統計情報を追加しました。
52	12.10	カスタム監視リソースにおいて、監視タイプが [非同期] で監視対象のスクリプトが終了して監視異常となった場合、スクリプトを再実行しない制限を解除しました。
53	12.10	クラスタ停止の実行時、グループリソースの停止前にカスタム監視リソースの停止完了を待ち合わせる設定を追加しました。
54	12.10	スクリプトリソースにて、開始スクリプトによるリカバリ処理を実行しない機能を追加しました。
55	12.10	clpmonctrl コマンドに処理を要求する先のサーバを指定するためのオプションを追加しました。
56	12.10	Alert Service の通報手段として、clplogcmd コマンドの出力先に mail が指定できるようになりました。
57	12.10	WebManager サーバに対する HTTPS 接続において、SSL および TLS 1.0 を無効化しました。
58	12.11	Cluster WebUI の表示および操作を改善しました。
59	12.12	Cluster WebUI が OpenSSL 1.1.1 に対応しました。
60	12.20	クラスタの操作および状態取得が可能なRESTful APIを追加しました。
61	12.20	Cluster WebUIやコマンドにおけるクラスタ情報の取得処理を改善しました。
62	12.20	クラスタ構成情報チェック機能を追加しました。
63	12.20	異常検出時の動作としてSTOPエラーを実行する際に、待機系サーバへメッセージを記録する機能を追加しました。
64	12.20	グループの自動起動やグループリソース活性・非活性異常時の復旧動作を無効化する機能を追加しました。
65	12.20	ライセンス管理コマンドにて、クラスタノード削除時における期限付きライセンスの再構成が可能となりました。
66	12.20	OSのユーザアカウントにより、Cluster WebUIにログインできるようになりました。
67	12.20	以下のアプリケーションやスクリプトの実行時に、[クラスタのプロパティ] の [アカウント] タブに登録したユーザとして実行できるようになりました。アプリケーションリソースで実行するアプリケーションスクリプトリソースで実行するスクリプトカスタム監視リソースで実行するスクリプトグループリソースの活性前後・非活性前後スクリプトグループリソースの最終動作前スクリプトモニタリソースの回復動作スクリプト強制停止スクリプト
68	12.20	スクリプトリソースにおいて、現用系サーバでの開始・終了スクリプトの実行と連動して、待機系サーバでもスクリプトを実行できるようになりました。
69	12.20	業務を停止せずにクラスタノードの追加・削除が可能となりました。(ミラーディスク/ハイブリッドディスク構成を除く)
70	12.20	ログ収集コマンドでイベントログを収集しない機能を追加しました。
71	12.20	ログファイルサイズが2GBを超えた場合でもログ収集が可能になりました。
72	12.20	ログ収集のパターンに、システム統計情報を追加しました。
73	12.20	グループの停止待ち合わせの設定条件を拡充しました。
74	12.20	Cluster WebUI でグループ起動停止予測時間を表示する機能を追加しました。
75	12.20	以下の機能でProxyサーバを利用できるようになりました。 Witnessハートビートリソース HTTPネットワークパーティション解決リソース
76	12.20	断線したインタコネクトが存在する状態におけるクラスタ起動時間を改善しました。
77	12.20	Cluster WebUIやclpstatコマンドで、クラスタ停止状態、クラスタサスペンド状態における表示内容を改善しました。
78	12.20	グループ起動停止予測時間およびモニタリソースの監視所用時間を表示するコマンドを追加しました。
79	12.20	システムリソース統計情報採取機能を追加しました。
80	12.20	サービスリソースの [活性リトライしきい値] の既定値を 0回から 1回に変更しました。
81	12.20	HTTP監視リソースが、BASIC認証に対応しました。
82	12.20	AWS AZ監視リソースのステータスを、アベイラビリティゾーンの状態が information または impaired の場合、異常から警告に変更しました。
83	12.20	Google Cloud 仮想IPリソース、Google Cloud 仮想IP監視リソースを追加しました。
84	12.20	Oracle Cloud 仮想IPリソース、Oracle Cloud 仮想IP監視リソースを追加しました。
85	12.20	以下の監視リソースについて、[AWS CLI コマンド応答取得失敗時動作] の既定値を「回復動作を実行しない(警告を表示する)」から「回復動作を実行しない(警告を表示しない)」に変更しました。 AWS Elastic IP監視リソース AWS 仮想 IP監視リソース AWS AZ監視リソース AWS DNS監視リソース
86	12.20	DB2モニタリソースがDB2 v11.5に対応しました。
87	12.20	SQL ServerモニタリソースがSQL Server 2019に対応しました。
88	12.20	ミラーディスクリソースのデータパーティションサイズを無停止で拡張する機能を追加しました。
89	12.20	ミラー復帰を伴わずに、ミラーディスクのデータを最新として扱う機能をclpmdctrlに追加しました。
90	12.22	RESTful APIで取得可能なリソースステータス情報を拡充しました。
91	12.22	片サーバが停止している状態で、ミラーディスクのデータを最新状態(赤から緑)にできるよう clpmdctrl コマンドを強化しました。
92	12.22	PostgreSQL監視リソースが PostgreSQL12 に対応しました。

5.3. 修正情報¶

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

項番	修正バージョン / 発生バージョン	修正項目	致命度	発生条件発生頻度	原因
1	12.01 / 12.00	同一製品の期限付きライセンスが2つ有効化されることがある。	小	ライセンス期限切れの際にストックされた未使用のライセンスを自動的に有効化する処理と、ライセンス登録コマンドによる新規ライセンスの登録操作が同時に行われた場合に、稀に発生する。	ライセンス情報を操作する際の排他処理に不備があったため。
2	12.01 / 12.00	clpgrpコマンドによるグループの起動が失敗する。	小	排他ルールが設定された構成で、起動対象のグループ名を指定せずにclpgrpコマンドを実行した場合に発生する。	グループ名が省略された場合の処理に不備があったため。
3	12.01 / 12.00	Cluster WebUI、WebManager、clpstatコマンドで、ミラーディスクに関する以下のパラメータが正しく表示されない。差分ビットマップサイズ非同期モードでの履歴記録領域サイズ	小	Cluster WebUI、WebManager、clpstatコマンドでクラスタプロパティを参照した場合に発生する。	表示データの取得処理に不備があったため。
4	12.01 / 12.00	モニタリソースの監視タイムアウトが検出されないことがある。	中	監視処理の所要時間がタイムアウト設定値を超えた場合に、タイミングにより発生する。	タイムアウト判定処理に不備があったため。
5	12.01 / 12.00	下記パラメータの変更が適切に反映されないことがある。グループリソース活性異常検出時のフェイルオーバしきい値モニタリソース異常検出時の最大フェイルオーバ回数	中	以下の条件をすべて満たす場合に発生する。フェイルオーバ回数のカウント単位にサーバが設定されているパラメータ変更時の反映方法としてクラスタのサスペンド/リジュームを実行していない	パラメータ変更時に要求される反映方法が適切でなかったため。
6	12.01 / 12.00	CPUライセンスとVMノードライセンスが混在する構成で、CPUライセンスの不足を示す警告メッセージが出力される。	小	CPUライセンスとVMノードライセンスが混在する場合に発生する。	ライセンスのカウント処理に不備があったため。
7	12.01 / 12.00	ODBC監視で監視異常を検出した場合、監視正常と判断してしまう。	中	ODBC監視で監視異常が発生した場合に発生する。	ODBC監視の監視ステータスを返却する処理に不備があったため。
8	12.01 / 12.00	Azure DNS 監視リソースにおいて、Azure 上のDNSサーバーが正常に稼働していても異常となる場合がある。	小	以下の条件をすべて満たす場合、必ず発生する。 [名前解決確認をする] がオンの場合 Azure CLI のバージョンが 2.0.30 ～ 2.0.32 の場合(2.0.29 以下、2.0.33 以上だと発生しない)	該当バージョンのAzure CLI により取得する DNSサーバー一覧にタブ文字が含まれることにより、Azure CLI の出力結果の解析処理に失敗するため。
9	12.01 / 12.00	Azure DNS 監視リソースにおいて、Azure 上のDNSサーバーの一部が正常に稼働している場合でも異常となる場合がある。	小	以下の条件をすべて満たす場合、必ず発生する。 [名前解決確認をする] がオンの場合 Azure CLI により取得したDNSサーバー一覧で最初に表示されるDNSサーバーが正常に稼働していない場合(2番目以降のDNSサーバーは正常に稼働)	DNSサーバーに対する健全性確認処理に不備があったため。
10	12.01 / 12.00	Azure DNS 監視リソースにおいて、Azure 上のDNSサーバー一覧の取得に失敗した場合でも異常とならない。	小	以下の条件をすべて満たす場合、必ず発生する。 [名前解決確認をする] がオンの場合 Azure CLI によるDNSサーバー一覧の取得に失敗した場合	正常、異常の判定処理に不備があったため。
11	12.01 / 12.00	以下の監視リソースにおいて、制御用プロセスが消滅しても異常とならず警告となる。仮想コンピュータ名監視リソース仮想 IP 監視リソース CIFS 監視リソースダイナミック DNS 監視リソース	中	制御用プロセスが消滅した場合、必ず発生する。	警告、異常の判定処理に不備があったため。
12	12.01 / 12.00	JVM 監視リソース利用時、監視対象Java VM でメモリリークが発生することがある。	中	以下の条件の場合に発生することがある。 [監視(固有)]タブ-[調整]プロパティ-[スレッド]タブ-[動作中のスレッド数を監視する]がオンの場合	使用しているJava APIの延長でScavenge GC で解放されないクラスが蓄積されることがあるため。
13	12.01 / 12.00	JVM監視リソースのJavaプロセスにおいて、メモリリークが発生することがある。	中	以下の条件をすべて満たす場合、発生することがある。 [監視(固有)]タブ-[調整]プロパティ]内の設定をすべてオフにした場合 JVM 監視リソースを複数作成した場合	監視対象Java VMへの接続切断処理に不備があったため。
14	12.01 / 12.00	JVM 監視リソースにおいて、以下のパラメータをオフにしてもJVM統計ログ(jramemory.stat)が出力される。 [監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[ヒープ使用量を監視する] [監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[非ヒープ使用量を監視する]	小	以下の条件をすべて満たす場合、必ず発生する。 [監視(固有)]タブ-[JVM 種別]が[Oracle Java(usage monitoring)]の場合 [監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[ヒープ使用量を監視する]がオフの場合 [監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[非ヒープ使用量を監視する]がオフの場合	JVM統計ログの出力判断処理に不備があったため。
15	12.01 / 12.00	JVM 監視リソースにおいて、ロードバランサ連携機能およびBIG-IP連携機能が動作しない。	中	必ず発生する。	バイナリの署名内容に差分があり、セキュリティエラーにより該当機能のコマンドが起動に失敗するため。
16	12.01 / 12.00	CLUSTERPRO Ver8.0 以前との互換機能を利用しているアプリケーションにおいて、一部のクラスタイベントを正しく取得できない。	中	互換APIを使用してクラスタイベントを監視している場合に発生する。	一部のクラスタイベントの通知処理に不備があったため。
17	12.10 / 12.00	SAP NetWeaver 用サンプルスクリプトを利用したカスタム監視リソースの障害検出時において、SAP サービスの停止処理中にSAP サービスの開始処理が行われる。	小	SAP サービスの停止処理に時間が掛かる場合に発生する。	SAP サービス停止用スクリプトにおいて、SAP サービスの停止完了を待ち合わせていないため。
18	12.10 / 12.00	タグの内容に ASCII 文字以外を含めた場合、AWS 仮想 IP リソースの活性に失敗する。	小	タグの内容に ASCII 文字以外を含めた場合、必ず発生する。	AWS 仮想 IP リソースが使用している AWS CLI の仕様のため。
19	12.10 / 12.00	WebOTX 監視リソースにおいて、WebOTX V10.1 を監視すると監視異常になる。	小	必ず発生する。	WebOTX V10.1 ではWebOTX が提供する otxadmin.bat コマンドが配置されている ${AS_INSTALL}¥bin が環境変数 PATH に含まれないため。
20	12.10 / 12.00	JVM 監視リソースの監視状態が警告のまま変わらない。	小	監視開始時、タイミングにより稀に発生する。	以下の原因による。 JVM 監視リソースにおける監視開始処理に不備があったため。メッセージ出力時において、該当する言語のメッセージ取得に失敗した場合の処理に不備があったため。
21	12.10 / 12.00	NAS リソースの [既定の依存関係に従う] に AWS DNS リソース、Azure DNS リソースが含まれていない。	小	必ず発生する。	NAS リソースの依存するリソースの既定値誤りのため。
22	12.10 / 12.00	SAP NetWeaver 構成において、ASCS 用フェイルオーバグループの初回フェイルオーバ時に、フェイルオーバ先のノードにおいて ASCS サービスの起動に失敗する。	小	AWS 環境において、ASCS 用フェイルオーバグループの初回フェイルオーバ時に発生する。	フェイルオーバ先のノードからCIFS リソースで共有したフォルダが数十秒程度参照できないため。
23	12.10 / 12.00	SQLServer 監視において、DB のキャッシュに SQL 文が残り、性能に問題が出る可能性がある。	小	監視レベル 2 の場合に発生する。	監視の度に毎回異なる updateの SQL を発行しているため。
24	12.10	ODBC 監視が 15 秒でタイムアウトする。	小	監視に 15 秒以上かかる場合に発生する。	ODBC 監視のタイムアウト値取得処理に不備があったため
25	12.10 / 12.00	ODBC 監視で監視ユーザー名を不正にした場合など警告になるべきケースが、監視異常になる。	小	監視パラメータに設定不備がある場合に発生する。	監視パラメータの設定不備に対する考慮漏れがあったため。
26	12.10 / 12.00	Oracle 監視のリスナー監視で、 tnsping がエラーになっても、監視異常にならない。	小	リスナー監視で tnsping がエラーの場合に発生する。	tnsping がエラーの場合の戻り値に誤りがあったため。
27	12.10 / 12.00	SQLServer 監視がタイムアウトした時、アラートログに「関数シーケンスエラー」が表示される。	小	監視がタイムアウトした場合に発生する。	誤ったエラー処理があり「関数シーケンスエラー」が出力されるため。
28	12.10 / 12.00	Database 監視において、アラートログにエラーメッセージが出力されないことがある。	小	一部のエラーにおいて、エラーメッセージが出力されない。	一部のエラーにおけるエラーメッセージに不備があったため。
29	12.10 / 12.00	カスタム監視リソースにおいて、タイムアウトを検出しても異常とならず警告となる。	中	カスタム監視リソースでタイムアウトを検出した場合、必ず発生する。	タイムアウト検出時の判定処理に不備があったため。
30	12.10 / 12.00	サービス監視リソースにおいて、監視対象サービスのハンドル取得に失敗した場合に異常とならず警告となる。	小	サービス監視リソースの監視対象サービスのハンドル取得に失敗した場合、必ず発生する。	監視対象サービスのハンドル取得失敗時の判定処理に不備があったため。
31	12.10 / 12.00	プリントスプーラ監視リソースにおいて、Spooler サービスのハンドル取得に失敗した場合に異常とならず警告となる。	小	Spooler サービスのハンドル取得に失敗した場合、必ず発生する。	Spooler サービスのハンドル取得失敗時の判定処理に不備があったため。
32	12.10 / 12.00	クラスタサスペンドがタイムアウトすることがある。	中	クラスタリジューム処理中にクラスタサスペンド操作を実行した場合に、稀に発生する。	クラスタサスペンド・リジューム操作が競合した場合の処理に不備があったため。
33	12.10 / 12.00	手動起動に設定されたフェイルオーバグループのフェイルオーバ時に、フェイルオーバ元で起動されていなかったグループリソースが、フェイルオーバ先で起動されることがある。	小	下記の状態遷移により発生する。クラスタ停止クラスタ起動手動起動に設定されたフェイルオーバグループの一部のグループリソースを単体起動グループリソースが起動されているサーバをシャットダウン	グループリソースの状態を保持する情報の初期化に不備があったため。
34	12.10 / 12.00	筐体 ID ランプが消灯されないことがある。	小	筐体 ID ランプ連携機能を使用する環境において、クラスタ内の一部サーバが停止し、筐体 ID ランプが点灯している状態で、残りの正常動作中サーバ上のクラスタサービスを停止した場合に発生する。	筐体 ID ランプの点灯要否の判定処理に不備があったため。
35	12.10 / 12.00	コマンド、Cluster WebUI からのクラスタサービスの操作、および構成情報の反映に失敗することがある。	小	クラスタサーバ内に停止しているサーバが存在する状態で当該の操作を行った際に、クラスタ構成や停止サーバ数などの条件により、応答待ち時間の累積がタイムアウト値 (120秒) を超過した場合に発生する。	タイムアウトの既定値が不十分であったため。
36	12.10 / 12.00	clpstat コマンドにて表示されるクラスタ復帰処理中サーバのステータスが適切でない。	小	クラスタ復帰処理の開始から完了までの間に clpstat -g を実行した場合に発生する。	サーバステータスの判定処理に不足があったため。
37	12.10 / 12.00	clpstat コマンドで、クラスタ停止処理中のステータスが適切に表示されない。	小	クラスタ停止実行直後からクラスタ停止完了までの間で clpstat コマンドを実行した場合に発生する。	クラスタ停止処理中のステータス判定処理に不備があったため。
38	12.10 / 12.00	停止処理の完了していないグループリソースのステータスが停止状態となる場合がある。	中	停止処理が失敗した状態のグループリソースに対し、下記の操作を行うと発生する場合がある。起動操作停止操作	異常状態のグループリソースに対する起動・停止操作によるステータス変更処理に不備があったため。
39	12.10 / 12.00	グループリソースの停止が失敗した際に、設定された最終動作に従わず、緊急シャットダウンが実行される場合がある。	中	グループリソースの非活性異常時の最終動作に「クラスタサービス停止と OS 再起動」が設定されている場合に発生する。	緊急シャットダウンの実行条件判定に不備があったため。
40	12.10 / 12.00	カスタム監視リソースで、clptoratio コマンドによるタイムアウト倍率の設定が効かない。	小	必ず発生する。	タイムアウト倍率値の設定処理が入っていないため。
41	12.11 / 12.10	Cluster WebUI の設定モードへの切替に失敗する。	小	特定のブラウザから HTTPS で Cluster WebUI に接続すると発生する。	特定ブラウザからのデータ送信パターンに対応できていない箇所があったため。
42	12.12 / 12.10	アプリケーションリソースの活性処理に失敗することがある。	小	アプリケーションリソースで、以下をすべて設定した場合に発生する。「常駐タイプ」に非常駐を設定実行ユーザを設定「正常な戻り値」に値を設定	変数の初期化漏れがあったため。
43	12.12 / 12.10	ネットワーク警告灯の設定時に、以下の項目の設定値が構成情報に保存されない。ネットワーク警告灯を使用する rshコマンド実行ファイルパスを指定するファイルパスサーバ起動時に音声ファイルの再生を行う音声ファイル番号サーバ停止時に音声ファイルの再生を行う音声ファイル番号	小	ネットワーク警告灯を設定する場合に必ず発生する。	ネットワーク警告灯の設定値の保存処理に漏れがあったため。
44	12.22 / 12.00～12.20	ミラー再構築中に残り時間が正しく表示されない場合がある。	小	ミラー再構築中の残り時間が1時間以上の場合に発生する。	ミラー再構築中の残り時間の表示処理に不備があったため。
45	12.20 / 12.00～12.12	ミラー復帰中に、ミラーディスク監視リソース/ハイブリッドディスク監視リソースのステータスが警告にならないことがある。	小	ミラーディスク監視リソース/ハイブリッドディスク監視リソースのステータスが異常の状態からミラー復帰を開始した場合に発生する。	監視リソースのステータス表示改善に伴う修正の際に、ミラー復帰に対する考慮が漏れていたため。
46	12.20 / 12.00～12.12	clpstatコマンドにて以下の不正なエラーメッセージが表示されることがある。 Could not connect to the server. Internal error.Check if memory or OS resources are sufficient.	小	クラスタ起動直後にclpstatコマンドを実行した場合に、稀に発生する。	エラー処理に不備があったため。
47	12.20 / 12.00～12.12	構成情報の反映時に不要な操作(WebManagerサーバ再起動)が要求されることがある。	小	反映方法に「クラスタシャットダウン・再起動」が必要な設定変更と、「WebManagerサーバ再起動」が必要な設定変更を同時に行った場合に発生する。	反映方法の判定処理に不備があったため。
48	12.20 / 12.00～12.12	グループおよびグループリソースのカレントサーバ情報に不整合が生じることがある。	中	手動フェイルオーバを設定している場合、インタコネクトの断線復帰後に稀に発生する。	インタコネクト復帰時のカレントサーバ情報更新処理に不備があったため。
49	12.20 / 12.00～12.12	グループの「起動可能サーバ一覧」からサーバを削除し、構成情報の反映後にクラスタ停止を実行するとサーバがシャットダウンされる。	小	グループが起動されているサーバを「起動可能サーバ一覧」から削除した場合に発生する。	グループが起動されているサーバを「起動可能サーバ一覧」から削除する際に、当該グループの停止が行われないため。
50	12.20 / 12.00～12.12	構成情報の反映時に不要な操作(サスペンド/リジューム)が要求されることがある。	小	自動登録されたモニタリソースのプロパティを参照した場合に発生することがある。	当該の内部処理に不備があったため。
51	12.20 / 12.00～12.12	CLUSTERPRO Web Alertサービスが異常終了することがある。	小	特定の条件によらず、ごく稀に発生することがある。	変数の初期化漏れがあったため。
52	12.20 / 12.00～12.12	Windows OSのプロセス wmiprvse.exe の保持するハンドルが増加する。	小	WMI (Windows Management Instrumentation) の実行により発生する。	ハンドルの解放漏れがあったため。
53	12.20 / 12.00～12.12	クラスタ再起動時、グループが起動しないことがある。	中	クラスタ再起動時、現用系のグループ停止処理中に、待機系サーバが先行して再起動した場合に稀に発生することがある。	サーバ間でグループ停止の待ち合わせ処理が失敗した場合における処理の考慮漏れがあったため。
54	12.20 / 12.00～12.12	サーバの停止処理に時間がかかることがある。	小	クラスタ停止時にごく稀に発生することがある。	クラスタ停止処理のタイミングがサーバ間でずれた場合のおける処理の考慮漏れがあったため。
55	12.20 / 12.00～12.12	グループ、リソースの非活性に失敗した場合でも非活性成功のアラートが出力されることがある。	小	緊急シャットダウン時に発生することがある。	緊急シャットダウン時にグループ、リソースの非活性結果に関係なく成功のアラートを出力していたため。
56	12.20 / 12.00～12.12	サーバダウン検出時にグループがフェイルオーバしないことがある。	中	サーバ起動時の内部情報の同期処理中にサーバダウンを検出した場合に発生することがある。	サーバステータスの更新処理に不備があったため。
57	12.20 / 12.00～12.12	外部連携監視リソースにて、回復動作スクリプトの実行が失敗することがある。	小	ユーザアプリケーションを下記の形式で指定した場合に発生する。 cscript スクリプトファイルのパス	指定されたユーザアプリケーションのパス確認処理に不備があったため。
58	12.20 / 12.10～12.12	インストールに失敗することがある。	小	インストールフォルダにProgram Files以外のフォルダを指定した場合に発生する。	動作に必要なDLLの検索が失敗するため。
59	12.20 / 12.10～12.12	ミラー統計情報採取機能とOS標準機能との連携が動作しない。	小	必ず発生する。	動作に必要なDLLの検索が失敗するため。
60	12.20 / 12.10～12.12	仮想マシンリソース、仮想マシン監視リソースが正常に動作しない。	中	必ず発生する。	仮想マシンリソース、仮想マシン監視リソースの初期化処理に不備があったため。
61	12.20 / 12.00～12.12	サービスリソースの非活性で、サービスが停止したにも関わらず非活性失敗となる場合がある。	小	Oracle など特定のサービスで発生する場合がある。	サービス停止処理が完了したにも関わらず、停止要求をエラーで返すサービスが存在するため。
62	12.20 / 12.00～12.12	Azureプローブポートリソースが活性している状態で、VIPへ接続できなくなる。	大	以下の場合に発生する。 1つのAzureプローブポートリソースに複数の接続(ロードバランサーからの正常性プローブ、pspingなどによる)がある場合、必ず発生する。高負荷の場合、稀に発生する。	左記の条件を満たす場合、Azureプローブポートリソースがロードバランサーからの正常性プローブの接続を拒否する処理となっていたため。
63	12.20 / 12.00～12.12	フェイルオーバ発生時に、ミラーディスクリソースの起動に失敗することがある。	中	サーバリセットを契機としたフェイルオーバ発生時に、稀に発生する。	サーバリセットを契機としたフェイルオーバ時の動作に不備があったため。
64	12.22 / 12.10～12.20	ミラー通信専用インタコネクトのIPアドレスを変更できない。	小	クラスタ構築時、優先順位が低いサーバを優先順位が高いサーバより先に追加した場合に発生する。	当該箇所の内部処理に不備があったため。
65	12.22 / 12.10～12.20	「筐体 ID ランプ連携使用する」の設定反映方法としてOS再起動が要求される。	小	クラスタプロパティで「筐体 ID ランプ連携使用する」の設定を変更し、設定の反映を実行すると発生する。	設定反映方法の定義が誤っていたため。
66	12.22 / 12.10～12.20	2バイト文字を含むレジストリキーをレジストリ同期リソースに設定できない。	小	レジストリキーに2バイト文字が含まれる場合に発生する。	レジストリキーに入力可能な文字種をASCII文字のみとしていたため。
67	12.22 / 12.20	クラスタ構成情報チェック機能で、AWSCLIコマンドのチェックが失敗する。	小	以下のグループリソースが設定された環境でクラスタ構成情報チェックを実行した場合に発生する。・AWS Elastic IPリソース・AWS 仮想IPリソース・AWS DNS リソース	AWSCLIコマンドの実行に必要な環境変数の設定が不足していたため。
68	12.22 / 12.20	クラスタ起動後にクラスタ構成情報チェックを実行すると、フローティングIPリソースおよび仮想IPリソースのチェックが失敗する。	小	フローティングIPリソースおよび仮想IPリソースを起動した状態で、クラスタ構成情報チェックを実行した場合に発生する。	フローティングIPリソースおよび仮想IPリソースの起動状態に対する考慮漏れのため。
69	12.22 / 12.20	クラスタ構成情報チェック機能で、OS起動時間チェックの確認結果が正しくないことがある。	小	OS設定値とハートビートタイムアウト値との値の組み合わせにより稀に発生する。	値の比較処理に不備があったため。
70	12.22 / 12.00	Cluster WebUI の細かな不具合を修正しました。	小	Cluster WebUI 使用時に発生する。	Cluster WebUI の内部処理に不備があったため。

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 フォルダにマウントして使用することはできません。
ミラーディスクリソース/ハイブリッドディスクリソースを使用するには、ミラー用のパーティション (データパーティションとクラスタパーティション) が必要です。
ミラー用のパーティションのディスク上の配置には特に制限はありませんが、データパーティションのサイズはバイト単位で完全に一致している必要があります。またクラスタパーティションには 1024MB 以上の容量が必要です。
データパーティションを拡張パーティション上の論理パーティションとして作成する場合は、両サーバとも論理パーティションにしてください。基本パーティションと論理パーティションでは同じサイズを指定しても実サイズが若干異なることがあります。
負荷分散のため、クラスタパーティションとデータパーティションは別のディスク上に作成することを推奨します（同じディスク上に作成しても動作に支障はありませんが、非同期ミラーの場合やミラーリングを中断している状態での書き込み性能が若干低下します）。
ミラーリソースでミラーリングするデータパーティションを確保するディスクは、両サーバでディスクのタイプを同じにしてください。

例)

組み合わせ

サーバ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 環境では使用できません。

BMCハートビートリソース
AWS Elastic IP リソース
AWS 仮想 IP リソース
AWS DNS リソース
Azure プローブポートリソース
Azure DNS リソース
Google Cloud 仮想 IP リソース
Oracle Cloud 仮想 IP リソース
AWS Elastic IP 監視リソース
AWS 仮想 IP 監視リソース
AWS AZ 監視リソース
AWS DNS 監視リソース
Azure プローブポート監視リソース
Azure ロードバランス監視リソース
Azure DNS 監視リソース
Google Cloud 仮想 IP 監視リソース
Google Cloud ロードバランス監視リソース
Oracle Cloud 仮想 IP 監視リソース
Oracle Cloud ロードバランス監視リソース

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

カーネルモードLANハートビートリソース
ミラーディスクコネクト
PINGネットワークパーティション解決リソース
FIPリソース
VIPリソース

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

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

≪不可な構成の例≫

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監視リソースが起動に失敗します。システム環境に依存するため、システムのメモリ搭載量を元に決定してください。
ロードバランサ連携の監視対象Java VMの負荷算出機能を利用する場合は、SingleServerSafeでの利用を推奨します。また、Red Hat Enterprise Linuxでのみ動作可能です。
監視対象Java VMの起動オプションに「-XX:+UseG1GC」が付加されている場合、Java 7以前ではJVM監視リソースの[プロパティ]-[監視(固有)] タブ-[調整]プロパティ-[メモリ]タブ内の設定項目は監視できません。

Java 8以降ではJVM監視リソースの[プロパティ]-[監視(固有)]タブ-[JVM種別]に[Oracle Java(usage monitoring)]を選択することで監視可能です。

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

「警子ちゃんミニ」、「警子ちゃん 4G」を使用する場合、警告灯にパスワードを設定しないで下さい。
音声ファイルの再生による警告を行う場合、あらかじめ音声ファイル再生に対応したネットワーク警告灯に音声ファイルを登録しておく必要があります。

音声ファイルの登録に関しては、各ネットワーク警告灯の取扱説明書を参照して下さい。
ネットワーク警告灯にクラスタ内のサーバからの rsh コマンド実行を許可するように設定してください。

6.2. CLUSTERPRO インストール前¶

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

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

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

6.2.2. 通信ポート番号¶

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

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

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

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

［サーバ・サーバ間］

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

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

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

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

［サーバ・Cluster WebUI 間］

From

To

備考

Cluster WebUI

自動割り当て

サーバ

29003/TCP

http通信

［その他］

From		To		備考
サーバ	自動割り当て	ネットワーク警告灯	各製品のマニュアルを参照	ネットワーク警告灯制御
サーバ	自動割り当て	サーバのBMCのマネージメントLAN	623/UDP	BMC制御 (強制停止/筐体ランプ連携)
サーバのBMCのマネージメントLAN	自動割り当て	サーバ	162/UDP	BMC 連携用に設定された外部連携モニタの監視先
サーバのBMCのマネージメントLAN	自動割り当て	サーバのBMCのマネージメントLAN	5570/UDP	BMC HB通信
サーバ	自動割り当て	Witness サーバ	Cluster WebUI で設定した通信ポート番号	Witness ハートビートリソースの接続先ホスト
サーバ	自動割り当て	監視先	icmp	IP監視リソース
サーバ	自動割り当て	NFSサーバ	icmp	NASリソースのNFSサーバ死活確認
サーバ	自動割り当て	監視先	icmp	Ping方式ネットワークパーティション解決リソースの監視先
サーバ	自動割り当て	監視先	Cluster WebUI で設定した通信ポート番号	HTTP 方式ネットワークパーティション解決リソースの監視先
サーバ	自動割り当て	サーバ	Cluster WebUI で設定した管理ポート番号	JVM監視リソース
サーバ	自動割り当て	監視先	Cluster WebUI で設定した接続ポート番号	JVM監視リソース
サーバ	自動割り当て	サーバ	Cluster WebUI で設定したロードバランサ連携管理ポート番号	JVM監視リソース
サーバ	自動割り当て	BIG-IP LTM	Cluster WebUI で設定した通信ポート番号	JVM監視リソース
サーバ	自動割り当て	サーバ	Cluster WebUI で設定したプローブポート	Azure プローブポートリソース
サーバ	自動割り当て	AWS リージョンエンドポイント	443/tcp	AWS Elastic IP リソース AWS 仮想 IP リソース AWS DNS リソース AWS Elastic IP 監視リソース AWS 仮想 IP 監視リソース AWS AZ 監視リソース AWS DNS 監視リソース
サーバ	自動割り当て	Azure エンドポイント	443/tcp	Azure DNS リソース
サーバ	自動割り当て	Azure の権威DNSサーバ	53/udp	Azure DNS 監視リソース
サーバ	自動割り当て	サーバ	Cluster WebUI で設定したポート番号	Google Cloud 仮想 IP リソース
サーバ	自動割り当て	サーバ	Cluster WebUI で設定したポート番号	Oracle Cloud 仮想 IP リソース

ミラーコネクト監視リソースを使用する場合、CLUSTERPRO はサーバ間で ping による疎通確認を行うため、icmp パケットを通すように設定する必要があります。ミラーコネクト監視リソースを使用する場合は、ファイアウォールの設定を変更して、サーバ間で ping による疎通確認ができるようにしてください。AWS環境の場合は、ファイアウォールの設定の他にセキュリティグループ設定も変更してください。

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

管理ポート番号はJVM監視リソースが内部で使用するためのポート番号です。Cluster WebUI の[クラスタプロパティ]-[JVM監視]タブ-[接続設定] ダイアログで設定します。詳細については『リファレンスガイド』の「パラメータの詳細」を参照してください。
接続ポート番号は監視先(WebLogic Server, WebOTX)のJava VM と接続するためのポート番号です。Cluster WebUI の該当するJVM監視リソース名の[プロパティ]-[監視(固有)]タブで設定します。詳細については『リファレンスガイド』の「モニタリソースの詳細」を参照してください。
ロードバランサ連携管理ポート番号はロードバランサ連携を行う場合に使用するためのポート番号です。ロードバランサ連携を使用しない場合は、設定不要です。Cluster WebUI の [クラスタのプロパティ]-[JVM監視] タブ-[ロードバランサ連携設定] ダイアログで設定します。詳細については『リファレンスガイド』の「パラメータの詳細」を参照してください。
通信ポート番号はBIG-IP LTMによるロードバランサ連携を行う場合に使用するためのポート番号です。ロードバランサ連携を使用しない場合は、設定不要です。Cluster WebUI の [クラスタのプロパティ]-[JVM監視] タブ-[ロードバランサ連携設定] ダイアログで設定します。詳細については『リファレンスガイド』の「パラメータの詳細」を参照してください。

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

AWS Elastic IP リソース、AWS 仮想 IP リソース、AWS DNS リソース、AWS Elastic IP 監視リソース、AWS 仮想 IP 監視リソース、AWS AZ 監視リソース、AWS DNS 監視リソースでは、AWS CLI を実行します。AWS CLI では上記のポート番号を使用します。

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

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. ミラーディスク用のパーティションについて¶

ミラーディスクリソースの管理用パーティション (クラスタパーティション) として、1024MB 以上の RAW パーティションを各サーバのローカルディスクに作成してください。
ミラーリング対象のパーティション (データパーティション) を各サーバのローカルディスクに作成し、NTFS でフォーマットしてください（既存のパーティションをミラーリングする場合、パーティションを作り直す必要はありません）。
データパーティションのサイズは、両サーバで等しくなるように設定してください。正確なパーティションサイズの確認と調整には [clpvolsz] コマンドを使用してください。
クラスタパーティションとデータパーティションには、両サーバで同じドライブ文字を設定してください。

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

ハイブリッドディスクリソースの管理用パーティション (クラスタパーティション) として、1024MB 以上の RAW パーティションを各サーバグループの共有ディスク（サーバグループのメンバサーバが 1 台の場合はローカルディスク）に作成してください。
ミラーリング対象のパーティション (データパーティション) を各サーバグループの共有ディスク（サーバグループのメンバサーバが 1 台の場合はローカルディスク）に作成し、NTFS でフォーマットしてください（既存のパーティションをミラーリングする場合、パーティションを作り直す必要はありません）。
データパーティションのサイズは、両サーバグループで等しくなるように設定してください。正確なパーティションサイズの確認と調整には [clpvolsz] コマンドを使用してください。
クラスタパーティションとデータパーティションには、各サーバで同じドライブ文字を設定してください。

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

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

6.2.10. OS 起動時間の調整¶

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

共有ディスクを使用する場合に、ディスクの電源が投入されてから使用可能になるまでの時間
ハートビートタイムアウト時間

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

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 方式、COM 方式など、他のネットワークパーティション解決方式のリソースと組み合わせて指定してください。
ディスク 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 をインストールする必要があります。
- 物理マシンの強制停止機能
- 筐体 ID ランプ連携
上記の機能を使用する場合、ベースボード管理コントローラー（BMC）のマネージメント用 LAN ポートの IP アドレスと OS が使用する IP アドレスの間で通信ができるように、各サーバの BMC を設定してください。サーバに BMC が搭載されていない場合や、BMC のマネージメント用のネットワークが閉塞している状態では、これらの機能は使用できません。BMC の設定方法については、各サーバのマニュアルを参照してください。
CLUSTERPRO に ipmiutil は添付しておりません。ipmiutil の入手方法とインストール方法については『インストール&設定ガイド』 - 「システム構成を決定する」- 「ハードウェア構成後の設定」 - 「9. BMC と ipmiutil をセットアップする (物理マシンの強制停止機能と筐体IDランプ連携を使用する場合は必須)」を参照してください。
ipmiutil に関する以下の事項について、弊社は対応いたしません。ユーザ様の判断、責任にてご使用ください。
- ipmiutil 自体に関するお問い合わせ
- ipmiutil の動作保証
- ipmiutil の不具合対応、不具合が原因の障害
- 各サーバの ipmiutil の対応状況のお問い合わせ
ご使用予定のサーバ (ハードウェア) の ipmiutil 対応可否についてはユーザ様にて事前に確認ください。ハードウェアとして IPMI 規格に準拠している場合でも、実際にはipmiutil が動作しない場合がありますので、ご注意ください。

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

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

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

6.2.15. メール通報について¶

メール通報機能は、STARTTLSやSSLに対応していません。

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

システムディスクが接続された HBA を[クラスタで管理するHBA一覧]に設定すると、OS がインストールされたシステムパーティションなどにアクセス制限が行われ OS が起動しなくなる場合があります。
SANブート環境などにおいて、システムディスクが接続された HBA を[クラスタで管理するHBA一覧] に設定する場合、システムパーティションを [クラスタ管理から除外するパーティション] に設定してアクセス制限の対象外とする必要があります。
詳細については『リファレンスガイド』の「パラメータの詳細」の「サーバプロパティ」を参照してください。

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

AWS Elastic IP リソース、AWS 仮想IP リソース、AWS DNS リソース、AWS Elastic IP 監視リソース、AWS 仮想IP 監視リソース、AWS AZ 監視リソース、AWS DNS 監視リソースでは、活性時/非活性時/監視時に AWS CLI を実行しています。
インスタンスの日時が正しく設定されていない場合、AWS CLI の実行に失敗し、「Failed in the AWS CLI command.」というメッセージが出力される場合があります。これは AWS の仕様によるものです。
この場合、インスタンスの日時を正しく設定し、NTP などにより時刻同期を取るようにしてください。詳細は「Windows インスタンスの時刻を設定する」(http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/windows-set-time.html)を参照してください。

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

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

AWS 仮想IP リソースなどのリソースおよび監視リソースは、その処理のために AWS CLI を内部で実行します。AWS CLI が正常に実行されるためには、事前に IAM の設定が必要となります。

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

アクション

説明

ec2:DescribeAvailabilityZones

アベイラビリティゾーンの情報を取得する時に必要です。

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

アクション

説明

route53:ChangeResourceRecordSets

リソースレコードセットの追加、削除、設定内容の更新する時に必要です。

route53:ListResourceRecordSets

リソースレコードセット情報の取得をする時に必要です。

以下のカスタムポリシーの例では全てのAWS 関連リソースおよびモニタリソースが使用するアクションを許可しています。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:Describe*",
                "ec2:ReplaceRoute",
                "ec2:AssociateAddress",
                "ec2:DisassociateAddress",
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
IAM Management Console の [Policies] - [Create Policy] でカスタムポリシーを作成できます。

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

IAM ロールを作成し、インスタンスに付与することでAWS CLIを実行可能にする方法です。
IAM ロールを作成します。作成したロールに IAM ポリシーをアタッチします。

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

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

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

Pythonをインストールします。

CLUSTERPRO が必要とする Python をインストールします。まず、Pythonがインストールされていることを確認します。未インストールの場合、以下から Python をダウンロードして、インストールします。インストール後、コントロールパネルにおいて環境変数 PATH に python.exe へのパスを追加します。PythonコマンドはSYSTEMユーザで実行されるため、システム環境変数PATHにPythonコマンドへのパスが設定されていることを確認してください。

https://www.python.org/downloads/

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

以下から AWS CLI バージョン 1 をダウンロードして、インストールします。

AWS CLI バージョン 2 には未対応のため、AWS CLI バージョン 2 はインストールしないでください。

システム環境変数 PATH にはインストーラが自動的に追加します。追加されない場合は、以下の「AWS CLI バージョン 1 実行ファイルをコマンドラインパスに追加する」を参照してください。

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-windows.html

「Windows (64 ビット) 用の AWS CLI MSI インストーラのダウンロード」

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

インストーラ別に必要なインストール後の対応は以下のとおりです。

MSIインストーラ

古いインストーラの場合はAWS CLIの実行ファイルが"aws.cmd"のみとなり、"aws.exe"がインストールされない場合があります。

AWS CLI バージョン 1 の最新のMSIインストーラを入手してください。

pipによるインストール

環境変数設定ファイル clpaws_setting.conf に"CLP_AWS_CMD=aws.cmd"の設定が必要です。

また、システム環境変数PATHにaws.cmdが存在するディレクトリ(例: "C:\Program Files\Python38")が設定されている必要があります。

環境変数設定ファイル clpaws_setting.conf の詳細は、『リファレンスガイド』の「グループリソースの詳細」の以下を参照してください。

「AWS Elastic IPリソースから実行するAWS CLIへ環境変数を反映させるには」

「AWS 仮想IPリソースから実行するAWS CLIへ環境変数を反映させるには」

「AWS DNS リソースから実行するAWS CLIへ環境変数を反映させるには」
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 ロールの付与は不要です。
IAM ユーザを作成します。作成したユーザに IAM ポリシーをアタッチします。

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

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

Pythonをインストールします。

CLUSTERPRO が必要とする Python をインストールします。まず、Pythonがインストールされていることを確認します。未インストールの場合、以下から Python をダウンロードして、インストールします。インストール後、コントロールパネルにおいて環境変数 PATH に python.exe へのパスを追加します。PythonコマンドはSYSTEMユーザで実行されるため、システム環境変数PATHにPythonコマンドへのパスが設定されていることを確認してください。

https://www.python.org/downloads/

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

以下から AWS CLI バージョン 1 をダウンロードして、インストールします。

AWS CLI バージョン 2 には未対応のため、AWS CLI バージョン 2 はインストールしないでください。

システム環境変数 PATH にはインストーラが自動的に追加します。追加されない場合は、以下の「AWS CLI バージョン 1 実行ファイルをコマンドラインパスに追加する」を参照してください。

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-windows.html

「Windows (64 ビット) 用の AWS CLI MSI インストーラのダウンロード」

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

インストーラ別に必要なインストール後の対応は以下のとおりです。

MSIインストーラ

古いインストーラの場合はAWS CLIの実行ファイルが"aws.cmd"のみとなり、"aws.exe"がインストールされない場合があります。

AWS CLI バージョン 1 の最新のMSIインストーラを入手してください。

pipによるインストール

環境変数設定ファイル clpaws_setting.conf に"CLP_AWS_CMD=aws.cmd"の設定が必要です。

また、システム環境変数PATHにaws.cmdが存在するディレクトリ(例: "C:\Program Files\Python38")が設定されている必要があります。

環境変数設定ファイル clpaws_setting.conf の詳細は、『リファレンスガイド』の「グループリソースの詳細」の以下を参照してください。

「AWS Elastic IPリソースから実行するAWS CLIへ環境変数を反映させるには」

「AWS 仮想IPリソースから実行するAWS CLIへ環境変数を反映させるには」

「AWS DNS リソースから実行するAWS CLIへ環境変数を反映させるには」
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.19. Azure DNS リソースについて¶

Azure CLI のインストール、サービスプリンシパルの作成の手順は、『CLUSTERPRO X Microsoft Azure 向け HAクラスタ構築ガイド』を参照してください。
Azure DNS リソースが利用するため、Azure CLI および Python のインストールが必要です。Python は、Azure CLI 2.0 をインストールすると同時にインストールされます。Azure CLI の詳細については、以下のWeb サイトを参照してください。

Microsoft Azure のドキュメント:

https://docs.microsoft.com/ja-jp/azure/
Azure DNS リソースが利用するため、Azure DNS のサービスが必要です。Azure DNS の詳細については、以下のWeb サイトを参照してください。

Azure DNS:

https://azure.microsoft.com/ja-jp/services/dns/
CLUSTERPRO が Microsoft Azure と連携するためには、Microsoft Azure の組織アカウントが必要となります。組織アカウント以外のアカウントは Azure CLI 実行時に対話形式でのログインが必要となるため使用できません。
Azure CLI を使用して、サービスプリンシパルを作成する必要があります。

Azure DNS リソースは Microsoft Azure にログインし、DNS ゾーンへの登録を実行します。Microsoft Azure へのログイン時、サービスプリンシパルによる Azure ログインを利用します。

サービスプリンシパルや詳細な手順については、以下のWeb サイトを参照してください。

Azure CLI から Azure へのログイン:

https://docs.microsoft.com/ja-jp/azure/xplat-cli-connect

Azure CLI 2.0 で Azure サービスプリンシパルを作成する:

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

作成されたサービスプリンシパルのロールを既定のContributor(共同作成者)から別のロールに変更する場合、Actions プロパティとして以下のすべての操作へのアクセス権を持つロールを選択してください。

この条件を満たさないロールに変更した場合、Azure DNS リソースの起動がエラーにより失敗します。

Azure CLI 2.0の場合

Microsoft.Network/dnsZones/A/write

Microsoft.Network/dnsZones/A/delete

Microsoft.Network/dnsZones/NS/read
Azure プライベート DNS には未対応です。

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

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

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 ハートビートリソースは最低 1 つ設定する必要があります。
インタコネクト専用の LAN をカーネルモード LAN ハートビートリソースとして登録し、さらにパブリック LAN もカーネルモード LAN ハートビートリソースとして登録することを推奨します (カーネルモード LAN ハートビートリソースを 2 つ以上設定することを推奨します)。
BMC ハートビートリソースを使用する場合、BMC のハードウェアやファームウェアが BMC ハートビートに対応している必要があります。利用可能な BMC については「4. CLUSTERPRO の動作環境」の「4.1.2. Express5800/A1080a,A1040a シリーズとの連携に対応したサーバ」を参照してください。
ハートビートタイムアウト時間は OS 再起動の所要時間より短くする必要があります。この条件を満たさない場合、クラスタ内の一部のサーバがリブートした際に、それを他のサーバが正しく検出できず、リブート後に動作異常が発生する場合があります。

6.3.6. スクリプトリソースの設定について¶

スクリプトリソースで [待機系サーバで実行する] の設定を有効にした場合、スクリプト内での互換コマンドの実行はサポートしていません。

6.3.7. スクリプトのコメントなどで取り扱える 2 バイト系文字コードについて¶

CLUSTERPRO では、Windows 環境で編集されたスクリプトは Shift-JIS、Linux 環境で編集されたスクリプトは EUC として扱われます。その他の文字コードを利用した場合、環境によっては文字化けが発生する可能性があります。

6.3.8. グループの起動可能サーバに設定可能なサーバグループ数について¶

1つのグループの起動可能サーバに設定可能なサーバグループ数は 2 となっています。3 つ以上のサーバグループを設定した場合、CLUSTERPRO Disk Agent サービス (clpdiskagent.exe) が正しく動作しない可能性があります。

6.3.9. 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.10. システム監視の設定について¶

リソース監視の検出パターン

System Resource Agent では、「しきい値」、「監視継続時間」という２つのパラメータを組み合わせて検出を行います。

各システムリソース(メモリ使用量、CPU 使用率、仮想メモリ使用量)を継続して収集し、一定時間（継続時間として指定した時間）しきい値を超えていた場合に異常を検出します。

6.3.11. PostgreSQL 監視の設定について¶

モニタリソース名に空白を含まないでください。

6.3.12. AWS Elastic IP リソースの設定について¶

データミラー構成のみ可能です。共有ディスク構成、ハイブリッド構成はサポートしていません。
IPv6はサポートしていません。
AWS 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。
AWS Elastic IPリソースはASCII文字以外の文字に対応していません。下記のコマンドの実行結果にASCII文字以外の文字が含まれないことを確認してください。

aws ec2 describe-addresses --allocation-ids <EIP ALLOCATION ID>

6.3.13. 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 アドレス、ENI定義がされていない場合でも AWS 仮想 IP リソースは正常に起動します。この動作は仕様どおりです。AWS 仮想 IP リソースは活性化時において、指定された IP アドレスのエントリが存在するルートテーブルに対してのみその内容を更新します。ルートテーブルが一つも見つからなかった場合でも更新対象なしとして正常と判断します。どのルートテーブルにエントリが存在する必要があるかはシステムの構成で決まるため、AWS 仮想 IP リソースとしては正常性の判断対象とはしていません。
AWS 仮想 IP リソースは、Windows OS の API を使用して NIC へ仮想 IP アドレスを追加しています。その際、skipassource フラグについては設定していないため、AWS 仮想 IP リソース活性後は skipassource フラグが無効となります。skipassource フラグを有効に設定する場合は、AWS 仮想 IP リソース活性後に PowerShell などで設定してください。

6.3.14. AWS DNS リソースの設定について¶

データミラー構成のみ可能です。共有ディスク構成、ハイブリッド構成はサポートしていません。
IPv6はサポートしていません。
AWS 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。
[リソースレコードセット名] にエスケープコードを含む場合、監視が異常になります。エスケープコードを含まない [リソースレコードセット名] を設定してください。
AWS DNS リソースの活性時、DNS 設定の変更がすべての Amazon Route 53 DNS サーバーに伝播済みとなるまでは待ち合わせません。これは Route 53 の仕様上、リソースレコードセットの変更が全体に適用されるまでに時間が掛かるためです。「AWS DNS 監視リソースの設定について」も参照してください。
AWS DNS リソースはアカウントに紐づいています。そのため、複数のアカウントや AWS アクセスキーID、AWS シークレットアクセスキーを使い分ける運用はできません。その場合は、スクリプトリソースなどで AWS CLI を実行するスクリプトを作成し、その中の環境変数に他アカウント認証用の情報を設定する運用を検討してください。

6.3.15. AWS DNS 監視リソースの設定について¶

AWS DNS 監視リソースは、監視時に AWS CLI を実行します。実行する AWS CLI のタイムアウトは、AWS DNS リソースで設定した [AWS CLI タイムアウト] を利用します。
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.16. Azure プローブポートリソースの設定について¶

IPv6はサポートしていません。
Microsoft Azure 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。

6.3.17. Azure ロードバランス監視リソースの設定について¶

Azure ロードバランス監視リソースが異常を検知した場合、Azureのロードバランサからの現用系と待機系の切り替えが正しく行われない可能性があります。そのため、Azure ロードバランス監視リソースの [最終動作] には [クラスタサービス停止と OS シャットダウン] を選択することを推奨とします。

6.3.18. Azure DNS リソースの設定について¶

IPv6はサポートしていません。
Microsoft Azure 環境では、フローティング IP リソース、フローティング IP 監視リソース、仮想 IP リソース、仮想 IP 監視リソース、仮想コンピュータ名リソース、仮想コンピュータ名監視リソースは利用できません。

6.3.19. Google Cloud 仮想 IP リソースの設定について¶

IPv6はサポートしていません。

6.3.20. Google Cloud ロードバランス監視リソースの設定について¶

Google Cloud ロードバランス監視リソースが異常を検知した場合、ロードバランサからの現用系と待機系の切り替えが正しく行われない可能性があります。そのため、Google Cloud ロードバランス監視リソースの [最終動作] には [クラスタサービス停止と OS シャットダウン] を選択することを推奨します。

6.3.21. Oracle Cloud 仮想 IP リソースの設定について¶

IPv6はサポートしていません。

6.3.22. Oracle Cloud ロードバランス監視リソースの設定について¶

Oracle Cloud ロードバランス監視リソースが異常を検知した場合、ロードバランサからの現用系と待機系の切り替えが正しく行われない可能性があります。そのため、Oracle Cloud ロードバランス監視リソースの [最終動作] には [クラスタサービス停止と OS シャットダウン] を選択することを推奨します。

6.3.23. Windows Server 2012 ベースのシステムにおけるサービス失敗時の回復操作について¶

Windows Server 2012 ベースのシステムにおいて、サービスが失敗(異常終了)した時に行われる回復操作として[コンピューターを再起動する]が設定されている場合、実際にサービスが失敗した際の動作が従来(Windows Server 2008以前)のOS再起動からSTOPエラーを伴うOS再起動へ変更されています。

本件の詳細については、下記の情報を参照してください。

参考：http://support.microsoft.com/kb/2848819

回復操作として既定で[コンピューターを再起動する]が設定されているCLUSTERPRO のサービスは下記です。

CLUSTERPRO Disk Agent サービス
CLUSTERPRO Server サービス
CLUSTERPRO Transaction サービス

6.3.24. OS のネットワーク負荷分散機能との共存について¶

OS のネットワーク負荷分散 (NLB) 機能にて使用している NIC に追加された IP アドレスは、NLB の仮想 IP アドレスとして認識されます。
この仮想 IP アドレスは NLB クラスタ内の全てのサーバにて付与されているものとして扱われます。
該当の NIC に対してフローティング IP アドレスが付与された場合、フローティング IP アドレスも仮想 IP アドレスとして認識されます。
このフローティング IP アドレスに対してアクセスした場合も、NLB の機能によって負荷分散が行われますが、フローティング IP アドレスは待機系の NIC には付与されていないため、フローティング IP アドレスに対するアクセスが異常となることがあります。

6.3.25. HBA の設定を反映する場合の注意点¶

クラスタの新規作成時に [サーバプロパティ] の [HBA] タブでアクセス制限の設定を変更して構成情報のアップロードを実行した場合、反映方法として OS 再起動が表示されないことがあります。クラスタの新規作成時に [HBA] タブでアクセス制限の設定を変更した場合は構成情報を反映するために OS の再起動を行ってください。

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. アプリケーションリソース / スクリプトリソースの画面表示について¶

CLUSTERPRO のアプリケーションリソース・スクリプトリソースから起動したプロセスはセッション 0 で実行されるため、GUI を持つプロセスを起動した場合、[対話型サービスダイアログの検出] ポップアップが表示され、このポップアップで [メッセージを表示する] を選択しないと GUI が表示されません。

6.4.15. ネットワークインターフェイスカード (NIC) が二重化されている環境について¶

NIC が二重化されている環境の場合、OS 起動時の NIC の初期化に時間がかかることがあります。初期化が完了する前にクラスタが起動すると、カーネルモード LAN ハートビートリソース (lankhb) の起動に失敗することがあります。この場合、NIC の初期化が完了しても、カーネルモード LAN ハートビートリソースの状態は正常に戻りません。この状態から復旧させるためには、クラスタをサスペンドした後、クラスタをリジュームする必要があります。

また、上記の現象を回避するためにネットワーク初期化完了待ち時間の設定、または ARMDELAY コマンドでクラスタの起動を遅らせることを推奨します。

ネットワーク初期化完了待ち時間

クラスタを構成する全サーバで共通の設定です。設定した時間に達していない場合でも、ネットワークの初期化が完了すると、クラスタの起動を開始します。
ARMDELAY コマンド

クラスタを構成する各サーバの個別の設定です。設定した時間に達していない場合、ネットワークの初期化が完了しても、クラスタの起動を開始しません。

ネットワーク初期化完了待ち時間、ARMDELAY コマンドの詳細については、『互換機能ガイド』を参照してください。

6.4.16. CLUSTERPRO のサービスのログオンアカウントについて¶

CLUSTERPROのサービスのログオンアカウントは [ローカルシステムアカウント] に設定されています。このログオンアカウントの設定を変更すると、クラスタとして正しく動作しない可能性があります。

6.4.17. CLUSTERPRO の常駐プロセスの監視について¶

プロセスを監視するようなソフトウェアにより、CLUSTERPROの常駐プロセスを監視すること自体には問題はありませんが、プロセスの異常終了時などにプロセスの再起動などの回復動作は行わないでください。

6.4.18. 外部連携モニタリソースについて¶

外部連携モニタリソースに異常を通知するには、[clprexec] コマンドを用いる方法、BMC 連携機能を用いる方法、サーバ管理基盤連携機能を用いる方法の三つの方法があります。
[clprexec] コマンドを用いる場合は CLUSTERPRO CD に同梱されているファイルを利用します。通知元サーバの OS やアーキテクチャに合わせて利用してください。また、通知元サーバと通知先サーバの通信が可能である必要があります。
BMC 連携機能を利用する場合、BMC のハードウェアやファームウェアが対応している必要があります。利用可能な BMC については本ガイドの「CLUSTERPRO の動作環境」の「Express5800/A1080a,A1040a シリーズとの連携に対応したサーバ」を参照してください。また、BMC の管理用 IP アドレスから OS の IP アドレスへの通信が可能である必要があります。

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

監視対象のJava VMを再起動する場合はJVM監視リソースをサスペンドするか、クラスタ停止を行った後に行ってください。
設定内容を変更時にクラスタサスペンドおよびクラスタリジュームを行う必要があります。
モニタリソースの遅延警告には対応していません。

6.4.20. システム監視リソース、プロセスリソース監視リソースについて¶

設定内容を変更時にクラスタサスペンドを行う必要があります。
モニタリソースの遅延警告には対応していません。
動作中に OS の日付/時刻を変更した場合、10 分間隔で行っている解析処理のタイミングが日付/時刻変更後の最初の 1 回だけずれてしまいます。以下のようなことが発生するため、必要に応じてクラスタのサスペンド・リジュームを行ってください。
- 異常として検出する経過時間を過ぎても、異常検出が行われない。
- 異常として検出する経過時間前に、異常検出が行われる。
システム監視リソースのディスクリソース監視機能で同時に監視できる最大のディスク数は 26 台です。

6.4.21. ミラー統計情報採取機能と 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.22. [対話型サービスダイアログの検出]ポップアップ表示について¶

アプリケーションリソース / スクリプトリソースの [デスクトップとの対話を許可する] を設定し、[対話型サービスダイアログの検出] ポップアップを表示させるには「Interactive Services Detection」サービスが起動している必要があります。

既定値で「Interactive Services Detection」サービスの起動が無効となっているため、以下の手順に従い有効化してください。

参考

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx

→[Using an Interactive Service]

6.4.23. AWS 環境における AMI のリストアについて¶

AWS 仮想 IP リソースや AWS Elastic IP リソースの [ENI ID] にプライマリネットワークインターフェイスの ENI ID を設定している場合、AMI などからのリストア時には、AWS 仮想 IP リソースや AWS Elastic IP リソースの設定を変更する必要があります。

なお、セカンダリネットワークインターフェイスの ENI ID を設定している場合、AMI などからのリストア時にはデタッチ/アタッチ処理によって同一 ENI ID の引き継ぎが可能なため、AWS 仮想 IP リソースや AWS Elastic IP リソースの再設定は不要です。

6.5. CLUSTERPRO の構成変更時¶

クラスタとして運用を開始した後に構成を変更する場合に発生する事象で留意して頂きたい事項です。

6.5.1. グループ共通プロパティの排他ルールについて¶

排他ルールの排他属性を変更した場合、クラスタサスペンド、リジュームにより変更が反映されます。

排他属性が「完全排他」に設定されている排他ルールに、新たに排他対象のグループを追加した場合、サスペンド前のグループの起動状態により完全排他のグループが同一サーバ上で複数起動した状態になることがあります。
次回グループ起動時から正しく排他制御が行われるようになります。

6.5.2. リソースプロパティの依存関係について¶

リソースの依存関係を変更した場合、クラスタサスペンド、リジュームにより変更が反映されます。
リソースの依存関係と反映方法としてリソース停止が必要な設定変更をした場合、リジューム後のリソースの起動状態が依存関係を考慮したものになっていない場合があります。
次回グループ起動時から正しく依存関係の制御が行われるようになります。

6.5.3. グループリソースの追加、削除について¶

同一グループリソース名を別のグループへ移す設定変更を行う場合、以下の手順にて行ってください。

以下の手順にて行わなかった場合、正常に動作できなくなる可能性があります。

例) フローティングIPリソース fip1 をグループ failover1 から別のグループ failover2 に移す場合

グループ failover1 から fip1 を削除します。
設定の反映を行います。
fip1 をグループ failover2 へ追加します。
設定の反映を行います。

6.5.4. 外部連携監視リソースのクラスタ統計情報の設定について¶

モニタリソースのクラスタ統計情報の設定を変更した場合、サスペンド・リジュームを実行しても外部連携監視リソースにはクラスタ統計情報の設定が反映されません。外部連携監視リソースにもクラスタ統計情報の設定を反映させる場合は、OS の再起動を行ってください。

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 以外の場合、異常でした。

6.6.2. 削除機能一覧¶

各バージョンで削除された機能について、以下に示します。

内部バージョン 12.00

WebManager Mobile

VB Corp CL 監視リソース

VB Corp SV 監視リソース

OracleAS 監視リソース

6.6.3. パラメータ削除一覧¶

Cluster WebUI で設定可能なパラメータのうち、各バージョンで削除されたものについて、以下の表に示します。

内部バージョン 12.00

クラスタ

パラメータ

既定値

クラスタのプロパティ

> WebManager タブ

WebManager Mobile の接続を許可する

オフ

> WebManager Mobile 用パスワード

操作用パスワード

-

参照用パスワード

-

JVM 監視リソース

パラメータ

既定値

JVM監視リソースのプロパティ

> 監視 (固有) タブ

> メモリタブ([JVM種別]に[Oracle Java]を選択した場合)

仮想メモリ使用量を監視する

2048[メガバイト]

> メモリタブ([JVM種別]に[Oracle Java(usage monitoring)]を選択した場合)

仮想メモリ使用量を監視する

2048[メガバイト]

ユーザ空間監視リソース

パラメータ

既定値

ユーザ空間監視リソースのプロパティ

> 監視 (固有) タブ

ハートビートのインターバル/タイムアウトを使用する

オン

内部バージョン 12.10

クラスタ

パラメータ

既定値

クラスタのプロパティ

> WebManager タブ

> WebManager 調整プロパティ

> 動作タブ

アラートビューア最大レコード数

300

クライアントデータ更新方法

Real Time

仮想コンピュータ名リソース

パラメータ

既定値

仮想コンピュータ名リソースのプロパティ

> 詳細タブ

> 仮想コンピュータ名リソース調整プロパティ

> パラメータタブ

対応付ける IP アドレス 6

FIP

6

[対応付ける IP アドレス] の選択肢からPublic を削除しました。[Publc] を設定している構成情報を使用する場合も変更の必要はありません。IP アドレスの変更をする場合、[任意のIPアドレス]を選択し IP アドレスを指定してください。

6.6.4. 既定値変更一覧¶

Cluster WebUI で設定可能なパラメータのうち、各バージョンで既定値が変更されたものについて、以下の表に示します。

バージョンアップ後も [変更前の既定値] の設定を継続したい場合は、バージョンアップ後に改めてその値に再設定してください。
[変更前の既定値] 以外の値を設定していた場合、バージョンアップ後もそれ以前の設定値が継承されます。再設定の必要はありません。

内部バージョン 12.00

クラスタ

パラメータ

変更前の既定値

変更後の既定値

備考

クラスタのプロパティ

> JVM監視タブ

最大Javaヒープサイズ

7[MB]

16[MB]

> 拡張タブ

フェイルオーバ回数のカウント単位

クラスタ

サーバ

グループリソース共通

パラメータ

変更前の既定値

変更後の既定値

備考

リソース共通のプロパティ

> 復旧動作タブ

フェイルオーバしきい値

サーバ数に合わせる

1 [回]

[クラスタプロパティ] - [拡張タブ] - [フェイルオーバ回数のカウント単位]の既定値変更に伴う変更。

アプリケーションリソース

パラメータ

変更前の既定値

変更後の既定値

備考

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

> 依存関係タブ

既定の依存関係に従う

オン

・フローティング IP リソース

・仮想 IP リソース

・仮想コンピュータ名リソース

・ディスクリソース

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

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

・プリントスプーラリソース

・レジストリ同期リソース

・CIFS リソース

・NAS リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

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

オン

・フローティング IP リソース

・仮想 IP リソース

・仮想コンピュータ名リソース

・ディスクリソース

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

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

・プリントスプーラリソース

・レジストリ同期リソース

・CIFS リソース

・NAS リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

・AWS DNS リソース

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

・Azure DNS リソース

レジストリ同期リソース

パラメータ

変更前の既定値

変更後の既定値

備考

レジストリ同期リソースのプロパティ

> 依存関係タブ

既定の依存関係に従う

オン

・CIFS リソース

・NAS リソース

・ディスクリソース

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

・フローティング IP リソース

・プリントスプーラリソース

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

・仮想 IP リソース

・仮想コンピュータ名リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

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

オン

・CIFS リソース

・NAS リソース

・ディスクリソース

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

・フローティング IP リソース

・プリントスプーラリソース

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

・仮想 IP リソース

・仮想コンピュータ名リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

・AWS DNS リソース

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

・Azure DNS リソース

スクリプトリソース

パラメータ

変更前の既定値

変更後の既定値

備考

スクリプトリソースのプロパティ

> 依存関係タブ

既定の依存関係に従う

オン

・CIFS リソース

・NAS リソース

・ディスクリソース

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

・フローティング IP リソース

・プリントスプーラリソース

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

・レジストリ同期リソース

・仮想 IP リソース

・仮想コンピュータ名リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

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

オン

・CIFS リソース

・NAS リソース

・ディスクリソース

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

・フローティング IP リソース

・プリントスプーラリソース

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

・レジストリ同期リソース

・仮想 IP リソース

・仮想コンピュータ名リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

・AWS DNS リソース

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

・Azure DNS リソース

サービスリソース

パラメータ

変更前の既定値

変更後の既定値

備考

サービスリソースのプロパティ

> 依存関係タブ

既定の依存関係に従う

オン

・CIFS リソース

・NAS リソース

・ディスクリソース

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

・フローティング IP リソース

・プリントスプーラリソース

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

・レジストリ同期リソース

・仮想 IP リソース

・仮想コンピュータ名リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

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

オン

・CIFS リソース

・NAS リソース

・ディスクリソース

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

・フローティング IP リソース

・プリントスプーラリソース

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

・レジストリ同期リソース

・仮想 IP リソース

・仮想コンピュータ名リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

・AWS DNS リソース

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

・Azure DNS リソース

CIFS リソース

パラメータ

変更前の既定値

変更後の既定値

備考

CIFS リソースのプロパティ

> 詳細タブ

共有設定復元時の失敗を活性異常とする

オン

オフ

NAS リソース

パラメータ

変更前の既定値

変更後の既定値

備考

NAS リソースのプロパティ

> 依存関係タブ

既定の依存関係に従う

オン

・フローティング IP リソース

・仮想 IP リソース

・AWS Elastic IPリソース

・AWS 仮想IPリソース

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

オン

・フローティング 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 [秒]

タイムアウト発生時にリトライしない

オフ

オン

タイムアウト発生時に回復動作を実行しない

オフ

オン

NAS 監視リソース

パラメータ

変更前の既定値

変更後の既定値

備考

NAS 監視リソースのプロパティ

> 監視 (共通) タブ

タイムアウト

60 [秒]

180 [秒]

タイムアウト発生時にリトライしない

オフ

オン

タイムアウト発生時に回復動作を実行しない

オフ

オン

カスタム監視リソース

パラメータ

変更前の既定値

変更後の既定値

備考

カスタム監視リソースのプロパティ

> 監視 (共通) タブ

監視開始待ち時間

0[秒]

3[秒]

プロセス名監視リソース

パラメータ

変更前の既定値

変更後の既定値

備考

プロセス名監視リソースのプロパティ

> 監視 (共通) タブ

監視開始待ち時間

0[秒]

3[秒]

タイムアウト発生時にリトライしない

オフ

オン

タイムアウト発生時に回復動作を実行しない

オフ

オン

SQL Server 監視リソース

パラメータ

変更前の既定値

変更後の既定値

備考

SQL Server 監視リソースのプロパティ

> 監視 (固有) タブ

ODBC ドライバ名

SQL Native Client

ODBC Driver 13 for SQL Server

Weblogic 監視リソース

パラメータ

変更前の既定値

変更後の既定値

備考

Weblogic 監視リソースのプロパティ

> 監視 (固有) タブ

インストールパス

C:beaweblogic92

C:OracleMiddleware

Oracle_Homewlserver

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 コマンド応答取得失敗時動作

回復動作を実行しない(警告を表示する)

回復動作を実行しない(警告を表示しない)

6.6.5. パラメータ移動一覧¶

Cluster WebUI で設定可能なパラメータのうち、各バージョンで設定箇所が変更されたものについて、以下の表に示します。

内部バージョン 12.00

変更前の設定箇所

変更後の設定箇所

[クラスタのプロパティ]-[リカバリタブ]-[最大再起動回数]

[クラスタのプロパティ]-[拡張タブ]-[最大再起動回数]

[クラスタのプロパティ]-[リカバリタブ]-[最大再起動回数をリセットする時間]

[クラスタのプロパティ]-[拡張タブ]-[最大再起動回数をリセットする時間]

[クラスタのプロパティ]-[リカバリタブ]-[強制停止機能を使用する]

[クラスタのプロパティ]-[拡張タブ]-[強制停止機能を使用する]

[クラスタのプロパティ]-[リカバリタブ]-[強制停止アクション]

[クラスタのプロパティ]-[拡張タブ]-[強制停止アクション]

[クラスタのプロパティ]-[リカバリタブ]-[強制停止タイムアウト]

[クラスタのプロパティ]-[拡張タブ]-[強制停止タイムアウト]

[クラスタのプロパティ]-[リカバリタブ]-[仮想マシン強制停止設定]

[クラスタのプロパティ]-[拡張タブ]-[仮想マシン強制停止設定]]

[クラスタのプロパティ]-[リカバリタブ]-[強制停止スクリプトを実行する]

[クラスタのプロパティ]-[拡張タブ]-[強制停止スクリプトを実行する]

[クラスタのプロパティ]-[省電力タブ]-[CPU クロック制御機能を使用する]

[クラスタのプロパティ]-[拡張タブ]-[CPU クロック制御機能を使用する]

[クラスタのプロパティ]-[自動復帰タブ]-[自動復帰]

[クラスタのプロパティ]-[拡張タブ]-[自動復帰]

[クラスタプロパティ]-[リカバリタブ]-[モニタリソース異常時の回復動作を抑制する]

[クラスタプロパティ]-[拡張タブ]-[クラスタ動作の無効化]-[モニタリソースの異常時の回復動作]

[グループのプロパティ]-[属性タブ]- [フェイルオーバ排他属性]

[グループ共通のプロパティ] -[排他タブ]

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 との互換性について¶

X 1.0/2.0/2.1/3.0/3.1/3.2/3.3/4.0/4.1 で作成したクラスタ構成情報は X 4.2 以降でも使用できます。ただし、X 2.0 以降ではグループリソース・モニタリソースの異常検出時のフェイルオーバ先サーバ選択方式が既定値の [安定動作サーバ] となるため、3 ノード以上の構成の場合にフェイルオーバ先の選択結果が X 1.0 と異なる場合があります。
フェイルオーバ先が複数ある場合に、[安定動作サーバ] に設定していると、フェイルオーバ先でさらに異常が発生した場合に、まだ異常が発生していないサーバに優先的にフェイルオーバすることができます。これに対し、X 1.0 の場合、移動可能なサーバの中で最もプライオリティの高いサーバにフェイルオーバしますので、最初に異常が発生していたサーバにフェイルバックしてしまい、3台目のサーバにフェイルオーバできない場合があります。
このため、通常は [安定動作サーバ] に設定することを推奨していますが、X 1.0 と同じ動作にする必要がある場合は、各リソースのプロパティの設定タブで、フェイルオーバ先サーバ設定を [最高プライオリティサーバ] に変更してください。

6.7.2. CLUSTERPRO Ver 8.0 以前との互換機能について¶

以下の機能を使用する場合、クラスタ名、サーバ名、グループ名は、Ver 8.0 の命名規則に従って設定する必要があります。

CLUSTERPRO クライアント
ESMPRO/AC 連携機能
ESMPRO/SM 連携機能
仮想コンピュータ名リソース
互換 API
互換コマンド

従来バージョンの命名規則は以下の通りです。

クラスタ名

- 15 文字以内

- 使用可能な文字は、半角英数字、ハイフン(-)、アンダーバー(_)です。

- PRN などの DOS 入出力デバイス名は指定しないでください。

- 大文字、小文字を区別しません。
サーバ名

- 15 文字以内

- 使用可能な文字は、半角英数字、ハイフン(-)、アンダーバー(_)です。

- 大文字、小文字を区別しません。
グループ名

- 15 文字以内

- 使用可能な文字は、半角英数字、ハイフン(-)、アンダーバー(_)です。

- PRN などの DOS 入出力デバイス名は指定しないでください。

- 大文字、小文字を区別しません。

6.7.3. 互換 API について¶

互換 API は、CLUSTERPRO Ver 8.0 以前で使用可能であった API を指します。互換 API は CLUSTERPRO X でも使用可能ですが、以下の制限事項があります。

下記に示すリソースのみ対応しています。その他のリソースは設定しても互換 API から参照することはできません。

- ディスクリソース

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

- 仮想コンピュータ名リソース

- フローティング IP リソース（IPv4 アドレスのみ）

- 仮想 IP リソース（IPv4 アドレスのみ）

- プリントスプーラリソース

クラスタ名、サーバ名、グループ名は、従来バージョンの規則に従い設定する必要があります。従来バージョン規則外の名称を指定された場合は、互換 API で参照することはできません。
Cluster WebUI で指定されたリソース名を使用して、互換 API を使用することはできません。
クラスタイベントの発生タイミングは、完全互換ではありません。イベントの種類は同じですが、通知されるイベントの数、順序は従来バージョンと異なる場合があります。
常駐プロセスから互換 API を使用している場合、[CLUSTERPRO Server] サービスの停止→再起動時に、ArmTerminateApi → ArminitializeApiを実行し、互換 API の再初期化を行う必要があります。原則として、スクリプトリソースの開始・終了スクリプトでプロセスを起動・停止するように設定してください。
Ver 3.0 互換 I/F は使用できません。

6.7.4. クライアント API について¶

クライアント API は、CLUSTERPRO Ver 8.0 以前で使用可能であった API を指します。クライアント API は CLUSTERPRO X でも使用可能ですが、以下の制限事項があります。
クラスタの構成変更を伴うクラスタサスペンド、リジューム行う場合、[CLUSTERPRO Old API Support] サービスの再起動を行う必要があります。
クラスタサーバを起動する場合、[CLUSTERPRO Old API Support] サービスの再起動もしくはポーリング間隔のチューニングを行う必要があります。

6.7.5. スクリプトファイルについて¶

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。プライマリインタコネクトと兼用で設定することが可能。
ミラーディスクシステム: 共有ディスクを使用しないクラスタシステム

サーバのローカルディスクをサーバ間でミラーリングする

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