JP1 / IM3 のフェイルオーバー障害を徹底解剖！
こんにちは
Hitachi JP1 / IM3（通称 IM3）を本番環境で運用していると、突然 「データベースが起動しない」 という痛ましい障害が頻発していました。
同僚と何度も議論し、テストを繰り返した結果、いくつかの「落とし穴」を発見。
今回の記事では、「なぜ起きたのか」、「どうやって確かめたのか」、そして 「どうすれば防げるのか」 を、ご紹介します。
この記事の対象者
・JP1/IM3／JP1/AJS を運用中のシステム管理者
・クラスタ構成でのフェイルオーバーに不安がある方
・「障害の根本原因を突き止めてから対策したい」方
１．現行システムの構成（ざっくり全体像）
項目 | 内容 |
サービス | JP1 /IM3（監視・ジョブ管理） |
DBエンジン | PostgreSQL（IM2まではHiRDB） |
クラスタ | CLUSTERPRO X 5.1がミラーディスク（Sync）でブロック単位ミラーリング |
構成ホスト | 正常系 JP1#1（IM3 + AJS3）と待機系 JP1#2（同上） |
ディスク | 1 本のミラーディスクに PostgreSQLとHiRDBのDB ファイル・WAL（トランザクションログ）を格納 |
フェイルオーバー手段 | 1. clpdiskagent.exe/clpnm.exeの強制停止 2. jbs_service.exeの強制停止 3. EC2 コンソールからインスタンス停止（OS シャットダウン相当） |
監視エージェント | JP1/IM‑Agent（物理/論理）でメトリック・イベントを取得、統合オペレーションビューアに可視化 |
課題 | - DB ファイル・WAL がミラーディスクで不整合になると起動不能 - 待機系の論理IP が名前解決できず Agent が起動できない |
※図やイラストは省略。イメージは「正系と待機系が同じミラーディスクを共有」だと捉えておけば OK。
２．想定原因（“なぜ”が分かった瞬間）
現象 | 想定原因 |
① DB ファイル破損 → IM3 が起動できない | ミラーディスクの ブロック単位ミラー が原因で、障害時に副系のDBファイルが不整合。 PostgreSQLがcheckpoint recordを探せず起動失敗（XX000PANIC: could not locate a valid checkpoint record） |
② WAL（トランザクションログ）破損 → 起動はできてもデータがズレる | 同上のミラリング不整合でWALが壊れ、復旧時に手作業が必要 |
③ PID/postmaster.pid 残留 → 次回起動で「プロセスが残っている」エラー | クラスタ障害時にプロセスが強制終了され、PIDファイルが削除されないまま残ってしまう |
④ 名前解決・ルーティング不整合 → 待機系 Agent が Manager に接続できない | 論理IPの優先順位がOSのIP ソート順とずれ、待機系にバインドできず |
⑤ メモリ枯渇 → java.lang.OutOfMemoryError: Java heap space が出る | jddmainの-Xmx 設定が実メモリに対して小さすぎる |
ポイント
JP1 のサポートからは「クラスタ構成でもフェイルオーバーは保証しない」旨の回答がありました。つまり、設計上のリスク が根底にあるということです。
3.検証・再現テスト（実際にやってみたこと）
テストシナリオの全容
手順 | 何をしたか | 期待結果 |
① フェイルオーバー手段の確認 | clpdiskagent.exe, clpnm.exe, jbs_service.exe をそれぞれ 強制終了 | 障害が起きてもリソースが自動で復帰し、IM3が継続稼働 |
② データ負荷シナリオ | - 低負荷 50 mtr/分 × 1日 - 高負荷 10,000 mtr/分 × 1日 - 高負荷＋長期蓄積 10,000 mtr/分 × 5日 | データ量が増えてもDBが正常に起動し続けるか |
③ イベント登録負荷 | 1 秒あたり100件以上のJP1イベントを流す | イベント処理が遅延しないか |
④ トランザクションログ破損シミュ | DBを 短時間連続で強制停止（※実施しないと判断） | Invalid primary checkpoint record が出て起動失敗が再現できるか |
⑤ 他JP1製品併用テスト | AJS3、PFM も同時に起動し、フェイルオーバー時に衝突しないか | 全製品が問題なくフェイルオーバー |
⑥ 環境差分チェック | 本番と同一の EC2（r6i.xlarge、Windows Server 2022）を使用 | 環境差異が結果に影響しないことを保証 |
主な結果
項目 | 再現可否 | コメント |
トランザクションログ破損 | ✕（再現できず） | 本番で見た「チェックポイント欠損」までは再現できなかったが、WALの不整合は確認できた |
PID・postmaster.pid 残留 | ○ | 手順通りに止めると残り、手動削除が必要になることが判明 |
メモリ枯渇 | ○ | -Xmxが足りないとOutOfMemoryErrorが出ることを再現 |
名前解決失敗 | ○ | 論理IPが待機系にバインドできず、Agentが起動しないケースを再現 |
フェイルオーバー成功率 | △（設定変更前は失敗多数 | タイムアウト設定を緩和すると成功率が上がった |
4. 対策案（“どうやって防ぐか”）
案① 設定チューニング＆仕様変更
内容 | 目的 | 予防効果 |
PostgreSQLの起動待ち時間60 → 120秒へ拡張 | 起動遅延に対応 | 起動失敗が減少 |
CLUSTERPROのタイムアウト60 → 6秒へ短縮 | 障害検知を早める | フェイルオーバーが速くなる |
PostgreSQLのWAL同期モードをAsyncへ変更（またはミラー対象外） | ミラーディスク不整合を回避 | トランザクションログ破損リスク低減 |
注意：WAL の同期を外すと耐障害性が下がるので、運用要件と相談が必須
案② DB エンジンを HiRDB に置換
メリット：HiRDBはミラーディスクでの不整合が起きにくいと実績あり
デメリット：移行工数が大きい、アプリ側の互換性確認が必要
案③ IM3をシングル構成＋AMIリストア
- IM3を単体サーバ に切り替える（待機系はAJSのみ）
- 障害時は AMIから即時リストア → 復旧作業が自動化
- 復元ポイントは「週末のスナップショット」→ データロス最小化
メリット | デメリット |
復旧手順が統一化、作業時間短縮 | 復元に時間がかかる（DB再セットアップが必要） |
待機系AJSに影響なし | 週次スナップショット以外のデータは失われる可能性あり |
案④ 自動化スクリプト
- DB起動失敗時にバックアップから自動リストア
- 手順書のバッチ化 → 人的ミス削減
ポイント：スクリプトの保守が必要。誤削除を防ぐため、テスト環境で要検証。
案⑤ ネットワーク設定の見直し
- 静的ルート・セキュリティグループ・DNS を最適化し、論理IP の優先順位を制御
- SkipAsSource フラグで論理IP がバインド対象になるよう調整
効果 | 実装コスト |
待機系 Agent が正しく Manager に接続できる | AWS のネットワークチームと調整が必要 |
5. 結論（総括）
項目 | 内容 |
根本原因 | CLUSTERPROのブロック単位ミラー が PostgreSQLのDBファイル・WAL を不整合にしやすく、フェイルオーバー時に起動失敗（checkpoint記録が見つからない） |
再現性 | 本番と同様の環境で トランザクションログ破損は再現できなかった が、ミラーディスク不整合は確認済み |
短期的対策 | - 起動待ち時間・タイムアウト緩和 - PID/postmaster.pidの自動削除スクリプト - ネットワーク（IPバインド）設定の調整 |
長期的対策 | - シングル化＋AMIリストアで復旧作業を簡素化 - HiRDBへDBエンジン変更かミラリング方式変更をJP1 サポートへ要望 |
次のステップ | １．設定チューニングを本番環境に適用し、効果を観測 ２．自動化スクリプトを作成し、手順書を標準化 ３．シングル構成・ネットワーク見直しを段階的に実装 ４．将来的にDBエンジン移行を検討（サポートと協議） |
PR
こちらの発言は全て個人的意見です。内容につきましては、十分注意し投稿しておりますが、誤りがあれば直接ご指導頂けますとありがたいです。
CNS Tech Blog Beyond｜CNS シイエヌエス - BEYOND THE RIGHT ANSWER.: 株式会社シイエヌエス
▶ お問い合わせフォームはこちら：
https://reg34.smp.ne.jp/regist/is?SMPFORM=ofte-lerand-a156f4b7d094ddf7db06c166e8de81dd
