CLUSTERPRO構築備忘録①～NEC CLUSTERPRO X とは～

NEC が販売している HA型クラスタリングソフトウェアである「CLUSTERPRO X」の概要についてご紹介します。

Contents

CLUSTERPRO X とは
CLUSTERPRO X の構成
- 2ノード共有ディスクの場合の構成図
- CLUSTERPRO X のソフトウェア構成
CLUSTERPRO X のオプションについて

CLUSTERPRO X とは

CLUSTERPRO X とは NEC が販売しているHA型クラスタリングソフトウェアです。実は、x86 サーバをクラスタ化する “CLUSTERPRO X” 以外にも、高可用性の維持や高度な監視を実現する “CLUSTERPRO MC” などといった「CLUSTERPRO ほにゃらら”」という製品群がいくつか存在します。

CLUSTERPRO X はその中核となる製品ということですね。詳しく知りたい方は下記 NEC サイトから確認して下さい。

CLUSTERPRO – 製品一覧 |NEC

CLUSTERPRO X は必須ではない

先程「CLUSTERPRO X は中核となる製品」と記載しましたが、例えば CLUSTERPRO MC はCLUSTERPRO X がなくても単体で動作します。”CLUSTERPRO X と連携できる”という意味の中核です。

CLUSTERPRO X の概要

CLUSTERPRO X 4.0 for Windows スタートアップガイド | NEC
CLUSTERPRO X 4.0 for Windows インストール&設定ガイド | NEC
CLUSTERPRO X 4.0 for Windows リファレンスガイド | NEC

CLUSTERPRO X はいわゆるアクティブ/スタンバイ型のクラスタ(HA クラスタと言います)を実現するソフトウェアです。CLUSTERPRO X は HA クラスタとして共有ディスク型とミラー型の構成に対応しています。

ただし、あくまでディスクレベルの同期であり、メモリやプロセスを常に同期しているわけではありません。その為、例えばデータベースなどのアプリケーションをクラスタ化した場合は、フェイルオーバ後のデータベースの再開などの動作を CLUSTERPRO が実行しなければなりません。

勿論アプリケーション毎にフェイルオーバ後の処理は変わってくるはずなので、マニュアルが必要になってきます。

CLUSTERPRO X では「動作確認済みソフトウェア」として、CLUSTERPRO X でのフェイルオーバが正常に成功したアプリケーションのマニュアルを公表しています。

CLUSTERPRO X でのクラスタを構築する場合、まずはアプリケーションの動作確認が取れているかを確認しましょう。

CLUSTERPRO X 4.0 for Windows 動作確認済みソフトウェア

障害検出メカニズム

CLUSTERPRO は主に以下の2つを利用して障害を検知します。

ハートビート
リソース監視

リソースの復旧動作

リソースの活性(起動)・非活性(停止) の失敗もフェイルオーバ条件にすることができます。

ハートビート 1/2

CLUSTERPRO ではハートビートにイーサネットを利用します。そして、ハートビート用のイーサネットのことをインタコネクトと表現します。

カーネルモード LAN ハートビートは 1 つ以上設定する必要があります。2 つ以上の設定を推奨します。インタコネクト専用 LAN ハートビートとパブリック LANハートビートを同時に設定することを推奨します。

リファレンスガイドより

上記で言っている「パブリック LAN」とはいわゆる業務用の LAN のことです。つまり、2台構成の場合はインタコネクト専用の LAN としてサーバ同士をイーサネットケーブルで直接接続し、業務用 LAN もセカンダリインタコネクトとして利用することを推奨しています。

ネットワークパーティション（NP）

ここで「ネットワークパーティション問題」についてお話させて下さい。クラスタを構築するうえで非常に重要な問題です。

例えば全てのインタコネクトでハートビートが途絶えたとします。それは果たしてサーバの障害なのでしょうか。通信路の問題という可能性もあります。もしサーバ障害ではなく通信障害であったとすると、以下の流れを経てデータが破壊される可能性があります。

ケーブル破損などの、何らかの通信エラーによりハートビート断絶
スタンバイ側はサーバ障害と誤判断（ハートビートが無いので相手の状態が分からない）
フェイルオーバによりスタンバイ側もリソースを活性してしまう
アクティブ側もリソースの活性を継続している
排他制御も無い状態で両方でリソース(ディスク)を活性することによりデータが破壊される

このように、ネットワーク的に孤立(パーティション)してしまうことでクラスタ内の複数のノード群で同時にリソースを起動してしまうことを「ネットワークパーティション問題」もしくは「スプリットブレインシンドローム」と言います。

この問題を防ぐために、クラスタリングソフトウェアは、「サーバ障害を検出するためのハートビート」以外にも「ネットワークパーティションを検出するためのNP解決用リソース」が必要になります。

例えば CLUSTERPRO X では以下のような方式を採用しており、構築時に最低どれか1つの方式を設定しなければなりません。

COM方式

2 ノードクラスタで使用可能
シリアルクロスケーブルが必要
COM 通信路を使用して相手サーバの生存確認を行うことによってネットワークパーティション状態の判定を行う
COM 通信路が正常な状態で全てのネットワーク通信路に障害が発生した場合は、ネットワークパーティションを検出して、マスタサーバを除いた全てのサーバが緊急シャットダウン

PING方式

ping コマンドを受信し、応答を返却可能な常時稼動している装置(以下、「ping 用装置」と省略します) が必要
ping 用装置は複数指定することが可能
他サーバからのハートビートの途絶を検出した際に、ping 用装置から ping コマンドの応答がある場合にはハートビートの途絶したサーバがダウンしたと判断してフェイルオーバを実施し、ping コマンドの応答がない場合はネットワークパーティション状態により自身がネットワークから孤立したものと判断して緊急シャットダウンする。これにより、ネットワークパーティション状態が発生した際に、クライアントと通信可能な方のサーバで業務を継続することができる

DISK方式

共有ディスクを使用するクラスタで選択できる
共有ディスク上に専用のディスクパーティション (ディスクハートビート用パーティション) が必要
共有ディスク上に定期的にデータを書き込み、他サーバの最終生存時刻を計算することでネットワークパーティション状態の判定を行う
共有ディスクが正常な状態で全てのネットワーク通信路に障害が発生した場合は、ネットワークパーティションを検出して、マスタサーバ及びマスタサーバと通信できるサーバがフェイルオーバ処理を実施する。それ以外のサーバは全て緊急シャットダウン
他の方式に比べ、ディスク I/O の遅延を考慮する必要があるため、ネットワークパーティション解決に時間がかかる。この時間はクラスタのプロパティで設定するハートビートタイムアウト時間とディスク I/O 待ち時間の長いほうの約 2 倍となる。

NECの推奨としては以下となっています。

3 ノード以上で共有ディスクを使用するクラスタには、PING + DISK 方式を推奨します。
ハイブリッドを使用する場合は、共有ディスクが接続されたサーバでは PING + DISK 方式、共有ディスクが接続されていないサーバでは PING 方式のみを使用します。
3 ノード以上で共有ディスクを使用しないクラスタには、PING 方式を推奨します。
2 ノードで共有ディスクを使用するクラスタには COM + DISK 方式または、PING + DISK 方式を推奨します。
ノードで共有ディスクを使用しないクラスタを使用するクラスタには COM 方式または、 PING 方式を推奨します。

例えば2ノード構成のネットワークパーティション問題は以下のように解決することが推奨されています。

PING + DISK 方式

PING 方式と DISK 方式を組み合わせた方式
ping コマンドを受信し、応答を返却可能な常時稼動している装置（ping 用装置）が必要
ping 用装置は複数指定可能。また、共有ディスク上に専用のディスクパーティション（ディスクハートビート用パーティション）が必要
通常は PING 方式と同様に動作するが、ping 用装置の故障などにより、ハートビートが途絶する前に全サーバで ping コマンドの応答が返らない状態が続くと、DISK 方式に切り替わる。ただし、PING 方式と DISK 方式それぞれの NP 解決リソースを使用するサーバが一致していない場合（例えば全サーバで使用する PING 方式のリソースと共有ディスク装置が接続された一部のサーバでのみ使用する DISK 方式のリソースがある場合など）では、それぞれのリソースが個別に動作するため、ping 用装置の状態によらず DISK 方式も動作する
共有ディスクや共有ディスクへの経路に異常が発生している状態で他サーバからのハートビートの途絶を検出した場合、ping コマンドの応答がある状態でも緊急シャットダウンする

ハートビート 2/2

ここまででハートビートが途絶えたら NP 解決が行われ、解決方法によってクラスタの状態が遷移することがわかっていただけたかと思います。

NP を理解してもらったところでハートビートに話を戻します。ハートビート用のインタコネクトは複数用意するのが推奨でした。これはインタコネクト単体の障害によるフェイルオーバを防ぐため、つまりはハートビートの信頼性を向上するための推奨項目です。

ここで気になるのが、通常の運用ではアクティブ側のパブリック LAN に障害が発生した時点でフェイルオーバして欲しいですよね？ハートビートだけでそれが実現できるか考えてみます。

例えば「パブリック LAN のみ」をハートビートとする場合、なんだかパブリック LAN の障害を条件としてフェイルオーバしそうな感じもしますが、NP 解決方法によっては「スタンバイ側が緊急シャットダウンする」といった、状況の改善につながらないアクションに遷移する可能性もあります。なにより「ネットワークに負荷がかかったから」といった理由でフェイルオーバしかねません。

よって一般的にハートビート専用のラインを用意するわけですが、それだとパブリック LAN に障害が発生してもハートビートは継続しているのでフェイルオーバしません。

そんなハートビート以外のトリガーでフェイルオーバを発生させたいときに手動で作成するのが監視リソースです。

監視リソース

監視リソースを定義することで、ハートビートが途絶していない状況でもフェイルオーバを発生させることが可能です。例えば下図のような監視項目を追加することが可能です。

CLUSTERPRO X – 特徴/機能

意識しなければならないのは、構築時に監視リソースを追加しない限り、フェイルオーバの発生条件はハートビートの途絶のみです。上図のような条件でフェイルオーバを発生させたい場合は監視リソースを明示的に追加しなければなりません。

監視リソースの詳細についてはリファレンスガイドの「第６章モニタリソースの詳細」を参照してください。

MEMO

実は「既定ではハートビートが途絶した場合のみフェイルオーバする」ということについて、しつこいくらいにサポートに聞いたことがあります。その時のやり取りは以下のようなものでした。

CLUSTERPRO X で監視リソースを手動で追加しない場合、フェイルオーバの条件は「ハートビートが途切れた場合」のみということでしょうか。

はい、ご認識のとおりです。

（上図について）例えば”CLUSTERPRO X – 特徴/機能“の「2.検出可能な障害」の場合、ハートビートのみで全ての障害を検出するのではなく、必要だと思う監視リソースを追加していくことでフェイルオーバ条件を取捨選択していくことになるのでしょうか。

ご認識の通りとなります。

例えばインタコネクトに設定した「パブリック LAN」の障害を検知しフェイルオーバを発生させたい場合は、「NIC Link Up/Down監視リソース」を作成する必要があります。

NIC障害やLANケーブル断線の場合、NIC Link Up/Down監視リソースで異常を検出することが可能です。

NIC Link Up/Down監視リソースの追加をご検討いただければと存じます。

NEC サポートより

CLUSTERPRO X の構成

ここからは具体例を基に CLUSTERPRO の構成についてをお話していきます。分かりやすいように、2ノード共有ディスク型の構成で話を進めていきます。

2ノード共有ディスクの場合の構成図

2ノード共有ディスク構成の場合、構成としては以下の様になります。

インストール&設定ガイド P21 より引用

サーバ監視に焦点を当てた場合。スタートアップガイド P37 より引用

これらの構成図はマニュアルからそのまま引用しているのですが、あくまで構成例であるということを意識しなければなりません。

ここまで読んでいただいているのであれば理解できるかと思いますが、例えば1つ目の図で言うと、RS-232C の接続が必須かのように何の注釈も無く図に載っていますが、あくまでネットワークパーティション解決の手段の一つ（COM方式）です。PING 方式や DISK 方式で解決しても問題ありません。

また、2番目の図は見ようによっては「インタコネクトを3つ用意してください」に見えてしまいますが、「複数のインタコネクトを設定できます」となります。

CLUSTERPRO X のソフトウェア構成

CLUSTERPRO X は以下の3つのソフトウェアで構成されています。

CLUSTERPRO 本体

CLUSTERPRO のメインモジュールです。クラスタを構成する各サーバにインストールします。

Cluster WebUI / WebManager

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

Cluster WebUI と WebManager は纏められている為呼び方が2つあるのかと思いきや、この2つは管理ツールとして別のものです。

元々管理ツールは WebManager が提供されていたんですが、後述する builder と共に Java VM 上で動く Java アプレットとして実装されている為、Web ブラウザベースとはいえ操作するには Java(JRE)が必要でした。Cluster WebUI は CLUSTERPRO X 4.0 から新規に実装された管理ツールであり、既定の管理ツールとなっています。（Cluster WebUI はモダンな感じのUIです。）

ただし、Cluster WebUI / WebManager はあくまで構築済みのクラスタを操作するインタフェースです。クラスタが構成されていればフェイルオーバの実施などは可能ですが、初期構築や設定変更は行えません。構築･設定は builder で行います。

Cluster WebUI

WebManager

builder

CLUSTERPRO の構成情報を作成するためのツールです。CLUSTERPRO の設定は builder からしか行えません。 WebManager の設定モードとして動作するオンライン版と、管理端末に個別にインストールするオフライン版があり、オンライン版は WebManager に組み込まれています。 WebManager と同じく、ユーザインターフェースとして Web ブラウザを利用します。というより、builder は Webmanger とインタフェースが変わりません。

builder

builder のオンライン版について、WebManager を「操作モード」で動かしている状態を builder と言っているだけです。builder の実行には JRE が必要です。ちなみに、管理サーバを用意しなくても JRE がインストールされていればクラスタを構成するサーバ上でも WebManager および Builder を使用することができます。

スタートアップガイド P36 より引用

インストール&設定ガイド P19 より引用

上図は「スタートアップガイド」と「インストール&設定ガイド」から引用している CLUSTERPRO のソフトウェア構成です。スタートアップガイドの図は Cluster WebUI や builder が点線で表現されていますが、実体がないというイメージなのでしょう。

CLUSTERPRO X のオプションについて

最後にCLUSTERPRO X のオプションについていくつか触れておきます。

CLUSTERPRO X Database Agent

主要アプリケーションに定期的にアクセスし、異常応答やハングアップを検出する監視リソースを追加することが可能になるオプションです。このオプションがないとデータベースサーバのクラスタ化ができないわけではありません。Database Agent が無い場合、プロセスの消滅による異常は検出できますが、データベースのストールや結果異常を検出することができません。

CLUSTERPRO X Database Agent とは。導入するメリットについて

CLUSTERPRO X Alert Service

サーバーダウン、フェールオーバーなど重要なイベントを電子メールで通報するオプションです。CLUSTERPRO X 単体ではメール通報の機能が無いため、ほぼ必須のライセンスと言えます。

CLUSTERPRO X Alert Service とは。導入するメリットについて

CLUSTERPRO X System Resource Agent

システムリソース、プロセスリソース、ディスクリソースに対する監視リソースを追加することが可能になるオプションです。プロセス、システムおよびディスクのシステムリソースの使用量を継続的に収集し、解析します。リソースの使用量があらかじめ設定したしきい値以上になった場合、異常を検出します。

CLUSTERPRO X System Resource Agent とは。導入するメリットについて

ライセンスが必要な監視リソースまとめ

監視リソースという観点でオプションライセンスを考えると分かりやすいかもしれません。CLUSTEPRO X 4.0 では以下の監視リソースを作成するためにはそれに適合したライセンスが必要になります。

オプション製品名	モニタリソース名
CLUSTERPRO X Database Agent 4.0 for Windows	DB2 監視リソース
	ODBC 監視リソース
	Oracle 監視リソース
	PostgreSQL 監視リソース
	SQL Server 監視リソース
CLUSTERPRO X Internet Server Agent 4.0 for Windows	FTP 監視リソース
	HTTP 監視リソース
	IMAP4 監視リソース
	POP3 監視リソース
	SMTP 監視リソース
CLUSTERPRO X Application Server Agent 4.0 for Windows	Tuxedo 監視リソース
	Websphere 監視リソース
	Weblogic 監視リソース
	WebOTX 監視リソース
CLUSTERPRO X Java Resource Agent 4.0 for Windows	JVM監視リソース
CLUSTERPRO X System Resource Agent 4.0 for Windows	システム監視リソース