2008サーバSP2でVB6を使用して、ソケット通信を利用した複数設備との
クライアントサーバの常駐APLを作成しました。その常駐APLに不具合が
発生した場合(ダウン、フリーズなど)、自動で起動するようにしたいの
ですが、この様な場合、どのように方法が一般的なのでしょうか？
【補足】
以下は私が考えた方法です。
案１
稼働中のプロセスを定期的に取得するAPLを作成して、『クライアントサ
ーバ常駐APL』が存在している事を確認、存在していない場合は『クライ
アントサーバの常駐APL』を起動する
案２
『クライアントサーバ常駐APL』に定期的にコネクションするクライアン
トAPLを作成して、コネクションに一定回数以上連続して失敗した場合、
『クライアントサーバ常駐APL』を起動又は、再起動する
※先日APLがダウンして、設備が稼動する事ができず、生産計画に影響を
与えてしまいました。その対策を検討しています。
以上、宜しくお願い致します。
フリーズの場合、原因を突き止めぬまま次のプロセスを起動することによって
リソース不足に陥り、二次被害を広げる可能性があります。
(処理時間が追いつかないのに次の処理が並行稼働し、さらにリソースを圧迫するなど)
あるいはダウンの場合、原因箇所を突き止めぬまま自動再起動を試みても、
また同じところでダウンして、結局、先に進まない可能性があります。
(ネットワーク自体がダウンした場合など)
そうした場合に対応するため、障害発生時に携帯メールなり画面通知アラートなりを
「人間」に対して発行するための仕組みも必要になってくるかと思います。
(もちろん、それを受け取って正常稼働を監視する「運用」の仕組みも必要です)
> どのように方法が一般的なのでしょうか？
再起動時のリカバリー(不良個所のスキップ、ログ解析、障害箇所の再実行など)も
考慮せねばなりませんし、一般解は無く、ケースバイケースだと思いますよ。
監視業務がある場合は、定期的に生存通知信号を投げ続け、それが一定時間
応答なしになった場合に、システムダウンと判断する手もありますし、
冗長システムがある場合は、待機系に切り替えるといった手もあります。
システムの規模によっては、冗長手段を採ることもありますね。
完全に別システムな待機系に切り替えるとか、それでもダウンしたら、
回復させるまでの間を手動業務で臨時対応できるようにしておき、
正常時のｎ割程度までの処理性能は維持させるとか。
そのダウンタイムを越えた場合にどうするかは、契約内容次第。
> 案１
> 稼働中のプロセスを定期的に取得するAPLを作成して、『クライアントサ
> ーバ常駐APL』が存在している事を確認、存在していない場合は『クライ
> アントサーバの常駐APL』を起動する
その場合、監視アプリ自身のダウンも検知する仕組みが必要ですね。
たとえば、監視側(親)が子プロセスを監視するとともに、
子も親の正常性を監視するとか。
もちろん、アプリが存在しているというだけでは不足なので、
それぞれが期待動作しているという点までを保証する必要がありますが。
> 案２
> 『クライアントサーバ常駐APL』に定期的にコネクションするクライアン
> トAPLを作成して、コネクションに一定回数以上連続して失敗した場合、
> 『クライアントサーバ常駐APL』を起動又は、再起動する
うちはこれが多いかな…?
ここでいう「コネクション」が、ソケットなのかファイル監視になるのか
Window Message の交換になるのか DB 値のポーリング監視になるのかは
ケースバイケースといったところですが。
魔界の仮面弁士様
早々のご回答、有難うございます。
おっしゃる通り、不具合原因が突き止められれば一番良いのですが..
今回は案2の監視APLをソケットで作成(既に設備とはソケット通信です
ので)して、サーバAPL不具合(コネクションに複数回連続して失敗)と
判定される場合には、監視APLからPCを再起動させようと思います。
PCは自動ログオン、自動APL起動に設定しています。監視APLは常駐で
はなく、タスクスケジューラで一定期間毎に起動しようと思います。
不具合は様々な原因で発生するかと思いますが、PC再起動が最大公
約数的に最も最適で有ると考えました。いかかでしょうか？ 宜し
ければアドバイスをお願いします。
以上、宜しくお願い致します。
この手の異常系対策って、結構大変なんですよね…。
不具合・データ異常ぐらいは検出できても、ハード障害・人的ミスなどは
事前の想定が意外と難しかったり。
異常が起きたことを記録して再起動する仕組みを作ったら、
想定以上のデータが飛来して、ログが溢れてしまったり。
> 監視APLは常駐ではなく、タスクスケジューラで一定期間毎に起動しようと思います。
いいんじゃないでしょうか。(現場を知らないので責任は持てませんが)
その場合、タスクがきちんと起動したかどうかの確認も必要かと思います。
タスクの起動状況を(ログ等で)定期的に確認する運用を組み込むとか。
> 不具合は様々な原因で発生するかと思いますが、PC再起動が最大公
> 約数的に最も最適で有ると考えました。いかかでしょうか？
スマートフォンでさえ、ハングアップで手動再起動が必要なケースは
多々あるわけですし、一般論で良いのなら、サービスの再起動や
OS あるいは PC の再起動の実施自体は、有効な手法の1つだと思います。
自動回復ではなく、人的判断が求められるケースもあるでしょうから、
それが“最適”かどうかの判断はできませんけれどね。
(迂闊に再起動できないケースもあるはず)
ただ、再起動は対処療法／緊急措置であって、問題原因の解決策にはなりません。
先の話は、自動再起動の仕組みを用意するとともに、
・再起動が必要になったという事実を認識できるような運用手法
・障害発生時(あるいは発生の直前)に、どのような状態にあったのかの記録
・実運用に影響を与えずに障害の再現性チェックを行うための環境
なども合わせて考えておかねばならないかな、という話です。
運用マニュアルの作成も必要でしょうし。
> 不具合原因が突き止められれば一番良いのですが..
不具合の原因を突き止めるのも重要ですが、そもそもその前に、
不具合があったことを確実に認識できるようにしておくことも必要ですね。
> 宜しければアドバイスをお願いします。
要件次第で要求性能も変わるので、あまりアドバイスはしにくいですが、
実際にあった分かりにくい例として：
毎日昼過ぎのバッチ処理の後で、特定の常駐アプリがハングアップ
することがあり、アプリの不具合調査の間、再起動で凌いでいた。
→アプリの不具合かと思いきや、実は電源自体の初期不良で、運が悪いと
日中に熱暴走していたことがメーカー側の調査で判明。
> コネクションに複数回連続して失敗
PC ではなく、通信機器側の再起動やハード交換が必要なケースもありますね。
>Keiko 2012/02/27(月) 17:37:36
自分で質問を見直してみて下さい。
何言ってるのかさっぱり分かりません。
上司に言われた事をメモ取って並べた感じですが
少し落ち着いた方が良いのでは?
>魔界の仮面弁士
さんの解読力は凄いとおもった。
何か面倒臭い事になってますけど
プロセスを2つ立ち上げで主従関係を作って
共有メモリを使用すればいいのでは?
CreateFileMapping APIとか。
魔界の仮面弁士様
その他の皆様
貴重なご意見、アドバイス、有難うございました。