JP7251182B2 - 制御装置、処理装置の制御方法及びプログラム - Google Patents

Description

本発明は、制御装置、処理装置の制御方法及びプログラムに関する。

特許文献１、２に、複数の処理装置に分散処理や並列処理を行わせるシステムが開示されている。この種のシステムでは、複数の処理装置を集中的に制御する制御装置が用いられる。この制御装置は、多数の処理装置を同時に制御する際に、通常は個々の処理装置に対する制御を並列処理する。

特許文献１の制御装置（情報処理装置１０）は、複数の装置のうち、処理に要する時間が所定値より長い装置への処理要求が、他の装置よりも先に送信されるように、処理要求の送信順を決定する。そして、この制御装置（情報処理装置１０）は、前記決定した送信順で、複数の装置それぞれに対して処理要求を送信し、複数の装置に並列に処理を実行させる。

特許文献２の制御装置（管理ノード）は、各処理ノードに依頼したテスト処理の処理結果に基づいて分散処理の対象とする処理ノードを選択する。

さらに、特許文献３には、システムの信頼性を向上させることができるという情報処理装置（待機系サーバ）が開示されている。この情報処理装置は、運用系サーバに障害が発生し処理が待機系サーバに移行された場合に、優先度にしたがいコネクション毎に送信間隔を空けてダミーパケットを送信するダミーパケット送信制御部を備える。さらに、この情報処理装置は、パケットの応答を基に各コネクションが使用可能か否かを判定するダミーパケット受信制御部を備える。さらに、この情報処理装置は、通信が使用可能と判定されたコネクションを用いて、運用系サーバが行っていたクライアントとの通信を継続する通信処理部を備える。

特開２０１４－１９９５３４号公報 特開２００６－３４４０６８号公報 特開２０１８－２８７８７号公報

以下の分析は、本発明によって与えられたものである。上記した制御装置が、複数の処理装置を制御する構成においては、並列数に上限を設けて運用がなされている。その理由は、制御装置の処理能力をすべて使用すると他の処理ができなくなるからである。

このような制御装置では、同時に制御する処理装置の数が前記所定の並列数を超えると、先行の処理装置の制御が完了するまで、後続の処理装置の制御は待たされることになる。このとき、制御装置から、先行の処理装置に接続できない状態では、後続の処理装置の制御開始がさらに遅延するという問題点がある。この問題は、コネクション型のプロトコルを使用する制御で顕著であり、コネクション確立待ちや応答のタイムアウト待ちが処理遅延時間の大部分を占める。

また、制御装置が先行の処理装置に接続できない状態は、制御装置と処理装置間のネットワーク障害や、処理装置の故障など、予期せぬ要因で発生する。この場合、障害が復旧するまでの時間を予測することは困難であり、接続復旧の見込みのない処理装置に対する処理（待機を含む）は、時間と処理リソースの無駄な消費である。このような非効率な動作は、利用者が制御装置への設定を行った際に、処理が全く進んでいないように見えるなど、利用者から制御装置の動作正常性を疑われるという問題にも繋がる。

本発明は、複数の処理装置を同時に制御する制御装置の制御性能の向上に貢献できる制御装置、処理装置の制御方法及びプログラムを提供することを目的とする。

第１の視点によれば、異なる優先度が設定されたキューを用いて複数の処理装置から制御要求を処理する制御処理部と、前記複数の処理装置に対し、検証パケットを送信する検証処理部と、前記検証パケットに対する応答に要した時間が所定の閾値以下である処理装置の制御要求を優先度の高い第１のキューに格納し、その他の処理装置の制御要求を前記第１のキューよりも優先度の低い第２のキューに格納するキュー管理部と、を備える制御装置が提供される。

第２の視点によれば、異なる優先度が設定されたキューを用いて複数の処理装置から制御要求を処理する制御処理部を備えた制御装置が、前記複数の処理装置に対し、検証パケットを送信し、前記検証パケットに対する応答に要した時間が所定の閾値以下である処理装置の制御要求を優先度の高い第１のキューに格納し、前記検証パケットに対する応答に要した時間が所定の閾値を超えている処理装置の制御要求を、前記第１のキューよりも優先度の低い第２のキューに格納する処理装置の制御方法が提供される。本方法は、複数の処理装置を制御する制御装置という、特定の機械に結びつけられている。

第３の視点によれば、異なる優先度が設定されたキューを用いて複数の処理装置から制御要求を処理する制御処理部を備えた制御装置に搭載されたコンピュータに、前記複数の処理装置に対し、検証パケットを送信する処理と、前記検証パケットに対する応答に要した時間が所定の閾値以下である処理装置の制御要求を優先度の高い第１のキューに格納する処理と、前記検証パケットに対する応答に要した時間が所定の閾値を超えている処理装置の制御要求を、前記第１のキューよりも優先度の低い第２のキューに格納する処理とを、実行させるプログラムが提供される。このプログラムは、コンピュータ装置に入力装置又は外部から通信インタフェースを介して入力され、記憶装置に記憶されて、プロセッサを所定のステップないし処理に従って駆動させる。また、このプログラムは、必要に応じ中間状態を含めその処理結果を段階毎に表示装置を介して表示することができ、あるいは通信インタフェースを介して、外部と交信することができる。そのためのコンピュータ装置は、一例として、典型的には互いにバスによって接続可能なプロセッサ、記憶装置、入力装置、通信インタフェース、及び必要に応じ表示装置を備える。

本発明によれば、複数の処理装置を同時に制御する制御装置の制御性能を飛躍的に向上させることが可能となる。

本発明の一実施形態の構成を示す図である。 本発明の一実施形態の動作を説明するための図である。 本発明の一実施形態の動作を説明するための図である。 本発明の一実施形態の動作を説明するための図である。 本発明の第１の実施形態の制御装置の構成を示す図である。 本発明の第１の実施形態の制御装置の検証データ記憶部に保持される接続検証結果の一例を示す図である。 本発明の第１の実施形態の制御装置の動作（接続検証）を表した流れ図である。 本発明の第１の実施形態の制御装置の動作（処理装置制御）を表した流れ図である。 本発明の第３の実施形態の制御装置の検証データ記憶部に保持される接続検証結果の一例を示す図である。 本発明の制御装置を構成するコンピュータの構成を示す図である。

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。また、以降の説明で参照する図面等のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。プログラムはコンピュータ装置を介して実行され、コンピュータ装置は、例えば、プロセッサ、記憶装置、入力装置、通信インタフェース、及び必要に応じ表示装置を備える。このコンピュータ装置は、通信インタフェースを介して装置内又は外部の機器（コンピュータを含む）と、有線、無線を問わず、交信可能に構成される。また、図中の各ブロックの入出力の接続点には、ポート乃至インタフェースがあるが図示省略する。また、以下の説明において、「Ａ及び／又はＢ」は、Ａ及びＢの少なくともいずれかという意味で用いる。

本発明は、その一実施形態において、図１に示すように、制御処理部１３と、検証処理部１２と、キュー管理部１１と、を備える制御装置１にて実現できる。より具体的には、制御処理部１３は、異なる優先度が設定されたキュー１４Ｂ、１４Ｃを用いて複数の処理装置２Ａ、２Ｂの制御要求を処理する。ここで、キュー１４Ｂはキュー１４Ｃよりも高い優先度が設定されているものとする。

検証処理部１２は、図２に示すように、前記複数の処理装置２Ａ、２Ｂに対し、検証パケットを送信する。検証パケットの送信タイミングは、図２のように同時でなくてもよく、検証パケットに対する応答に要した時間を計測できれば良い。

ここでは、図３に示すように、制御装置１は、処理装置２Ａから、前記検証パケットに対する応答パケットを受信したものとする。一方、制御装置１は、処理装置２Ｂから、前記検証パケットに対する応答パケットを受信できなかったものとする。この応答パケットの受信障害の原因としては、処理装置２Ｂが応答パケットを送信しなかった場合、処理装置２Ｂが応答パケットを送信したが制御装置１に届かなかった場合、処理装置２Ｂの応答が遅かった場合などが考えられる。

この場合、キュー管理部１１は、図４に示すように、優先度の高い第１のキュー１４Ｂに、前記検証パケットに対する応答に要した時間が所定の閾値以下である処理装置２Ａの制御要求を格納する。一方、キュー管理部１１は、前記第１のキューよりも優先度の低い第２のキュー１４Ｃに、その他の処理装置２Ｂの制御要求を格納する。

制御処理部１３は、キュー１４Ｃよりも、優先度の高いキュー１４Ｂから制御要求を取り出して処理する。これにより、検証パケットに対する応答に要した時間が所定の閾値以下である処理装置２Ａの制御要求を優先し、処理装置２Ｂの制御要求を後回しにして処理する。

結果として、本実施形態によれば、接続不可等の処理装置２Ａ、２Ｂのコネクション確立待ちや応答のタイムアウト待ちで無駄な時間を消費することなく、接続可の処理装置２Ａ、２Ｂから順次制御処理を処理することが可能となる。また、上記に伴い、制御装置１は、動作正常性を疑われるような挙動を見せなくなり、利用者もその動作正常性を容易に確認することができるようになる。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図５は、本発明の第１の実施形態の制御装置の構成を示す図である。図５を参照すると、処理要求部１１０と、検証処理部１２０と、制御処理部１３０と、処理キュー１４０Ａ～１４０Ｃと、受信キュー１５０と、検証データ記憶部１６０とを備えた制御装置１００が示されている。また、図５の下段の処理装置２００Ａ～処理装置２００Ｅは、制御装置１００の制御対象の処理装置を示している。以下、処理装置２００Ａ～処理装置２００Ｅを特に区別しない場合、「処理装置２００」と記す。

処理要求部１１０は、定期的に、処理キュー１４０Ａに対して、管理対象の処理装置２００に対する接続検証要求を追加する。また、処理要求部１１０は、処理装置２００への制御処理の実行時に、検証データ記憶部１６０から該当する処理装置２００の接続検証結果を取得する。そして、処理要求部１１０は、該当する処理装置２００の接続検証結果に応じて、処理キュー１４０Ｂまたは処理キュー１４０Ｃに制御要求を追加する。従って、処理要求部１１０が、上記したキュー管理部として機能することになる。

検証処理部１２０は、処理スレッド１２１を用いて、以下の処理を実施する。
（１）検証パケットの送信
まず、検証処理部１２０は、処理キュー１４０Ａから接続検証要求を取り出し、接続検証要求に基づき、当該処理装置２００へコネクションレス型のプロトコルで検証パケットを送信する。

接続検証にコネクション型のプロトコルを使用しない理由は、特定の処理装置２００に接続できない場合に、コネクション確立待ちや応答のタイムアウト待ちの時間を無駄に消費することを回避するためである。これにより、単一の処理スレッド１２１でも多数の処理装置２００への接続検証を処理できるようになる。なお、一般的な処理装置２００ではＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）によるＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）情報取得をサポートしている。この場合、データ量が少なく不変な任意のＭＩＢオブジェクト取得を検証パケットに用いることもできる。

（２）検証パケットに対する応答の監視
検証処理部１２０は、検証パケットの送信後、検証用のタイマを起動し、受信キューへの応答パケットの格納を監視する。

（３）接続検証結果の記録
所定のタイムアウト期間内に、受信キュー１５０に応答パケットが格納された場合、検証処理部１２０は、受信キュー１５０からの応答パケット取り出し時、検証データ記憶部１６０に、該当する処理装置２００の接続検証結果として「接続可」を格納する。また、検証処理部１２０は、応答パケットの取り出し後、検証用のタイマを停止する。一方、所定のタイムアウト期間内に、受信キュー１５０に応答パケットが格納されず、前記検証用のタイマが満了した場合、検証処理部１２０は、該当する処理装置２００の接続検証結果として「接続不可」を格納する。

（４）接続検証結果に基づいた制御要求の移動
また、検証処理部１２０は、接続検証結果の格納後、前回と今回の接続検証結果が異なるか否かを確認する。ここで、接続検証結果に変化が生じている場合、検証処理部１２０は、処理キュー１４０Ｂに格納されている制御要求又は処理キュー１４０Ｃに格納されている制御要求の移動を行う。例えば、接続検証結果が「接続可」であった処理装置２００が、「接続不可」となった場合、検証処理部１２０は、処理キュー１４０Ｂに格納されている該当する処理装置２００の制御要求を、処理キュー１４０Ｃに移動する。また例えば、接続検証結果が「接続不可」であった処理装置２００が、「接続可」となった場合、検証処理部１２０は、処理キュー１４０Ｃに格納されている該当する処理装置２００の制御要求を、処理キュー１４０Ｂに移動するようにしてもよい。ここで「制御要求を移動する」とは、移動元のキューから該当する制御要求を削除し、移動先のキューに該当する制御要求を格納することを意味する。

制御処理部１３０は、複数の処理スレッド１３１Ａ、１３１Ｂを用いて、以下の処理を並列で処理する。なお、以下の説明において、処理スレッド１３１Ａ、１３１Ｂを特に区別しない場合、「処理スレッド１３１」と記す。

（１）制御要求の処理
制御処理部１３０は、高優先の処理キュー１４０Ｂまたは低優先の処理キュー１４０Ｃから制御要求を取り出し、制御要求に基づき、当該処理装置２００を制御する。なお、処理キュー１４０Ｃからの制御要求の取り出しは、処理キュー１４０Ｂに制御要求が存在しない場合に行われる。また、処理キュー１４０Ｃから取り出した制御要求の同時処理数が所定の上限値に達している場合、制御処理部１３０は、処理キュー１４０Ｃからの制御要求の取り出しを抑止する。

（２）接続検証結果に基づいた制御要求の移動
また、制御処理部１３０は、１つの制御要求を処理したタイミングで接続検証結果の格納後、前回と今回の接続検証結果が異なるか否かを確認する。ここで、接続検証結果に変化が生じている場合、制御処理部１３０は、検証処理部１２０と同様に、処理キュー１４０Ｂに格納されている制御要求又は処理キュー１４０Ｃに格納されている制御要求の移動を行う。例えば、接続検証結果が「接続可」であった処理装置２００が、「接続不可」となった場合、制御処理部１３０は、処理キュー１４０Ｂに格納されている該当する処理装置２００の制御要求を、処理キュー１４０Ｃに移動する。また例えば、接続検証結果が「接続不可」であった処理装置２００が、「接続可」となった場合、制御処理部１３０は、処理キュー１４０Ｃに格納されている該当する処理装置２００の制御要求を、処理キュー１４０Ｂに移動するようにしてもよい。

処理キュー１４０Ａは、接続検証要求の追加と取り出しが可能なキューである。

処理キュー１４０Ｂと処理キュー１４０Ｃは、制御要求の追加と取り出しが可能なキューである。処理キュー１４０Ｂが高優先用、処理キュー１４０Ｃが低優先用であり、優先度に従って、制御処理部１３０は制御要求を取り出す。

受信キュー１５０は、応答パケットの追加と取り出しが可能なキューである。

検証データ記憶部１６０は、接続検証結果を蓄積する。図６は、制御装置１００の検証データ記憶部１６０に保持される接続検証結果の一例を示す図である。図６の例では、処理装置毎に、接続検証結果を過去所定回数分、蓄積可能となっている。

処理装置２００は、制御装置１００からの検証パケットに対する応答パケットの送信や、制御装置１００からの制御要求に基づく処理を実施する。

続いて、本実施形態の動作について図面を参照して詳細に説明する。図７は、本発明の第１の実施形態の制御装置の動作（接続検証）を表した流れ図である。制御装置１００で管理している処理装置２００それぞれに対して、処理要求部１１０が定期的に接続検証を要求することで、接続検証処理が開始する。ここでは、処理装置２００Ｂに対する接続検証を例に説明する。

処理要求部１１０は、処理キュー１４０Ａに処理装置２００Ｂの接続検証要求を追加する（ステップＳ１０１）。

検証処理部１２０は、処理キュー１４０Ａの更新を検知すると、処理キュー１４０Ａから接続検証要求を取り出す（ステップＳ１０２）。

接続検証要求に基づき、検証処理部１２０が処理装置２００Ｂへコネクションレス型のプロトコル（例えば、ＵＤＰでのＳＮＭＰ）で検証パケットを送信する（ステップＳ１０３）。

次に、検証処理部１２０は、検証用のタイマを起動し（ステップＳ１０４）、検証用のタイマ満了までに、応答パケットを受信したか否かを確認する（ステップＳ１０５）。

前記確認の結果、検証用のタイマ満了までに、処理装置２００Ｂからの応答パケットを受信した場合（ステップＳ１０５のＹＥＳ）、検証処理部１２０は、受信キュー１５０から応答パケットを取り出す（ステップＳ１０６）。次に、検証処理部１２０は、検証用のタイマを停止する（ステップＳ１０７）。さらに、検証処理部１２０は、検証データ記憶部１６０に、処理装置２００Ｂの接続検証結果「接続可」を登録する（ステップＳ１０８）。

一方、前記確認の結果、検証用のタイマ満了までに、処理装置２００Ｂからの応答パケットを受信できなかった場合（ステップＳ１０５のＮＯ）、タイムアウトとなる。この場合、検証処理部１２０は検証データ記憶部１６０に、処理装置２００Ｂの接続検証結果「接続不可」を登録する（ステップＳ１０９）。

次に、検証処理部１２０は、検証データ記憶部１６０を参照して、前回と今回の接続検証結果が異なるか否かを確認する（ステップＳ１１０）。前記確認の結果、前回と今回の接続検証結果が異なる場合（ステップＳ１１０のＹＥＳ）、検証処理部１２０が処理キュー１４０Ｂと処理キュー１４０Ｃの制御要求の配置を調整する（ステップＳ１１１）。

ここで、検証処理部１２０による制御要求の配置の調整について説明する。前回と今回の接続検証結果が異なる場合としては、「接続可」から「接続不可」に変化した場合と、「接続不可」から「接続可」に変化した場合との２通りがある。例えば、上述の接続検証処理の結果、「接続可」の処理装置２００が、「接続不可」となった場合、検証処理部１２０は、処理キュー１４０Ｂの当該処理装置２００の制御要求を、処理キュー１４０Ｃに移動する。逆に、「接続不可」だった処理装置２００が「接続可」となった場合、検証処理部１２０は、処理キュー１４０Ｃの当該処理装置２００の制御要求を、処理キュー１４０Ｂに移動する。

なお、ステップＳ１１０において、前回と今回の接続検証結果が同じであった場合、検証処理部１２０は、一連の処理を終了する（ステップＳ１１０のＮＯ）。

以上の接続検証処理の結果、検証データ記憶部１６０に保持された検証データを参照することで、処理装置２００Ｂが接続可能な装置であるか否かを判断することが可能となる。

続いて、検証データ記憶部１６０に保持された検証データを用いた処理装置２００の制御について説明する。図８は、本発明の第１の実施形態の制御装置の動作（処理装置制御）を表した流れ図である。図８の処理は、利用者から制御装置１００に処理装置２００の制御が要求されることで、開始される。なお、以下の説明では、各処理装置２００において、図７に示した接続検証処理が少なくとも一回実施されていることを前提とする。接続検証が一度も実施されていない場合、制御装置１００は、図７の接続検証の処理を先に行い、接続検証処理が完了するまで待機してから、図８の処理装置の制御を開始することになる。

以下の説明では、処理装置２００Ｄまたは処理装置２００Ｅに対する制御を行うものとして説明する。処理装置２００Ｄ、処理装置２００Ｅの接続検証の結果が、それぞれ図６に示すとおり、「接続可」、「接続不可」であるものとして説明する。

図８を参照すると、まず、処理要求部１１０が検証データ記憶部１６０から制御対象の処理装置２００の接続検証結果を参照する（ステップＳ２０１）。

処理要求部１１０は、接続検証結果が接続可であるか否かを確認する（ステップＳ２０２）。処理装置２００Ｄの場合、接続検証結果は「接続可」であるので（ステップＳ２０２のＹＥＳ）、ステップＳ２０３へ処理を進めることになる。一方、処理装置２００Ｅの場合、接続検証結果は「接続不可」であるので（ステップＳ２０２のＮＯ）、ステップＳ２０４へ処理を進めることになる。

接続検証結果が「接続可」である場合、処理要求部１１０は、高優先の処理キュー１４０Ｂに処理装置２００Ｄの制御要求を追加する（ステップＳ２０３）。

一方、接続検証結果が「接続不可」である場合、処理要求部１１０は、低優先の処理キュー１４０Ｃに処理装置２００Ｅの制御要求を追加する（ステップＳ２０４）。

処理キュー１４０Ｂまたは処理キュー１４０Ｃの更新を検知した制御処理部１３０は、高優先である処理キュー１４０Ｂの制御要求を先に確認する（ステップＳ２０５）。

前記確認の結果、処理キュー１４０Ｂに制御要求が存在する場合（ステップＳ２０６のＹＥＳ）、制御処理部１３０は、処理スレッド１３１Ａで処理キュー１４０Ｂから処理装置２００Ｄの制御要求を取り出す（ステップＳ２０７）。

一方、前記確認の結果、処理キュー１４０Ｂに制御要求が存在しない場合（ステップＳ２０６のＮＯ）、制御処理部１３０は、低優先の制御要求の同時処理数の確認を行う。具体的には、制御処理部１３０は、処理スレッド１３１Ｂで低優先の制御要求を処理している処理スレッド１３１の数が、低優先の制御要求の同時処理数の上限に達しているか否かを確認する（ステップＳ２０８）。ここで、低優先の制御要求の同時処理数が上限に達している場合、制御処理部１３０は処理を終了する（ステップＳ２０８のＹＥＳ）。

ここで、低優先の制御要求の同時処理数に上限を設けている理由について説明する。すべての処理スレッド１３１が処理キュー１４０Ｃから取り出した低優先の制御要求を処理している状態では、処理キュー１４０Ｂに高優先の新規制御要求が追加された際に、この高優先の制御要求の処理を開始できなくなるためである。例えば、Ｎ個の処理スレッド１３１を使用できる場合に、処理スレッド１３１は処理キュー１４０Ｂから取り出す高優先の制御要求を同時にＮ個まで処理できる。このとき、処理キュー１４０Ｃから取り出す低優先の制御要求の同時処理数の上限をＮ／２個とすることで、優先度に反して高優先の制御要求が待たされることを防ぐことができる。もちろん、上記低優先の制御要求の同時処理数（Ｎ／２）個は、あくまで一例であり、Ｎを超えない範囲で、制御装置１００の性能や利用者から求められる要求性能に応じて変更することが可能である。

一方、低優先の制御要求の同時処理数が上限に達していない場合（ステップＳ２０８のＮＯ）、制御処理部１３０は、処理スレッド１３１Ｂで処理キュー１４０Ｃから処理装置２００Ｅの制御要求を取り出す（ステップＳ２０９）。

なお、上記ステップＳ２０７およびＳ２０９では、先行の制御要求で特定の処理装置２００の制御処理中に、それと同一の処理装置２００に対する制御要求をスキップすることが好ましい。その理由は、複数の処理スレッド１３１で同一の処理装置２００を制御すると、制御内容の競合が発生する場合があるためである。よって、このスキップ処理により、同一の処理装置２００に対して同時に一つの制御要求のみを処理することができるようになる。

上記ステップＳ２０７およびＳ２０９で制御要求を取り出した制御処理部１３０は、処理スレッド１３１で、制御要求に基づき、処理装置２００に対する制御を実施する（ステップＳ２１０）。

なお、制御要求を複数の処理スレッド１３１で処理している理由は、複数の処理装置２００を同時に制御できるようにするためである。処理スレッド１３１の数量は制御装置１００の処理能力などにより調整するものとする。

一般に、処理装置の制御は、接続検証処理のように、処理装置２００への制御を非同期とし、単一の処理スレッド１３１で処理できない。これは、処理装置２００に対する複数の制御を順番通りに漏れなく実施する必要があるためである。順序制御や再送制御を個々に実装することは非現実的であり、順序制御や再送制御はコネクション型のプロトコル（例えば、ＴＣＰでのＳＳＨやＨＴＴＰ）に委ねることが最適であるためである。また、一般的な処理装置２００のサポートしている制御用のプロトコルが、コネクション型に限定されることも理由の一つである（一般的に、ＳＮＭＰなどのコネクションレス型のプロトコルは制御用ではなく参照用のみでサポートしている）。なお、ＴＣＰは、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＳＳＨは、Ｓｅｃｕｒｅ Ｓｈｅｌｌ、ＨＴＴＰは、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略である。

例として、処理キュー１４０Ｂに処理装置２００Ｄの制御要求、処理キュー１４０Ｃに処理装置２００Ｅの制御要求が追加されている状態では、高優先である処理キュー１４０Ｂに追加された処理装置２００Ｄの制御要求が優先して処理される。さらに、処理キュー１４０Ｂに多数の処理装置２００の制御要求が追加されている状態では、低優先の処理キュー１４０Ｃに追加されている処理装置２００Ｅの制御要求は、後回しにされることとなる。

本実施形態では、処理装置２００に対する制御を実施する都度、制御処理部１３０が、接続検証結果の検証を行い、その結果に基づいた制御要求の再配置の判定を行う。

具体的には、制御処理部１３０は、接続検証結果（高優先の制御要求を処理している場合は接続可、低優先の制御要求を処理している場合は接続不可）と、実際の処理装置２００への制御での接続結果が異なるか否かを確認する（ステップＳ２１１）。

接続検証結果と実際の接続結果が異なるケースとしては次のようなものが考えられる。
（１）高優先の制御処理時に、処理装置２００へ接続できなくなるケース
この場合、接続不可が継続する状況では、次回の制御要求を高優先で処理するのは、無駄な時間の消費となるため、制御要求の再配置を行う必要がある。
（２）低優先の制御処理時に、処理装置２００へ接続できるようになっているケース
この場合も、次回の制御要求を低優先で処理すると、接続可となったにもかかわらず制御要求の処理開始が遅れるため、この場合も制御要求の再配置を行う必要がある。

具体的には、制御処理部１３０は、前記接続検証結果と、実際の処理装置２００への制御での接続結果が異なる場合、検証データ記憶部１６０に、接続検証結果として実際の接続結果を格納する（ステップＳ２１２）。この処理により、次回以降に処理要求部１１０が実際の接続結果に基づいて、処理キュー１４０Ｂまたは処理キュー１４０Ｃに制御要求を追加することになる。

そして、制御処理部１３０は、処理キュー１４０Ｂと処理キュー１４０Ｃの制御要求の配置を調整する（ステップＳ２１３）。例えば、処理要求部１１０が「接続可」の処理装置２００の制御要求を処理キュー１４０Ｂに追加し、制御処理部１３０が同一の処理装置２００の先行する制御要求を処理した段階で、該当処理装置２００へ接続できなくなっていると、待ち状態が生じることになる。これを避けるため、制御処理部１３０は、処理キュー１４０Ｂの当該処理装置２００の制御要求を、処理キュー１４０Ｃに移動する。逆に、接続不可だった処理装置２００が接続できるようになった場合は、制御処理部１３０は、処理キュー１４０Ｃの当該処理装置２００の制御要求を、処理キュー１４０Ｂに移動する。

なお、ステップＳ２１１の判定の結果、記接続検証結果と、実際の処理装置２００への制御での接続結果が同一であった場合、制御処理部１３０は、一連の処理を終了する（ステップＳ２１１のＮＯ）。

なお、上記ステップＳ２１３の処理は、図７で説明したステップＳ１１１の制御要求の配置の調整と同一の処理である。これにより、検証結果が変更されたことに連動して、処理キュー１４０Ｂまたは処理キュー１４０Ｃに追加された制御要求を正しい優先度で処理させることが可能となる。

これらの処理により、接続不可の処理装置２００のコネクション確立待ちや応答のタイムアウト待ちで無駄な時間を消費することなく、接続可の処理装置２００から順次制御処理が進捗する。これにより、利用者も制御装置１００の動作正常性を確認できるようになる。

以上説明したように、本実施形態の制御装置１００によれば、その制御性能の向上のほか、利用者のシステム運用負荷を軽減する効果がある。その理由は、利用者が制御装置１００へ設定を実施した際に、接続可である処理装置２００では優先的に制御が完了し、即時にサービスを開始可能となる構成を採用したことにある。また、本実施形態によれば、処理装置２００の制御完了の進捗状況により、制御装置１００の動作正常性を確認できる構成を採用しているため、この点でも利用者のシステム運用負荷を軽減するものとなっている。

［第２の実施形態］
続いて、本発明の第２の実施形態について図面を参照して説明する。第２の実施形態は、第１の実施形態と同様の構成にて実現できるので、以下、両者を対比しながら、その相違点を中心に説明する。

第１の実施形態では、接続不可の処理装置２００でも接続状況が改善することを期待し、低優先の処理キュー１４０Ｃに制御要求を追加している。一方、第２の実施形態では、接続不可の処理装置２００に対しては、処理キュー１４０Ｃに制御要求を追加せずに廃棄する。これにより、第２の実施形態では、接続不可の処理装置２００での制御を待つ必要がなくなる。

この第２の実施形態では、利用者が制御装置１００への設定を先に投入しており、処理装置２００を後から順番に接続するなど、接続不可となる要因が判明している状況において、無駄な制御処理を実施しない方法として有用である。

［第３の実施形態］
続いて、本発明の第３の実施形態について図面を参照して説明する。第３の実施形態は、第２の実施形態と同様の構成にて実現できるので、以下、両者を対比しながら、その相違点を中心に説明する。

上記した第２の実施形態では、接続検証処理において、処理装置２００から送信された応答パケットが、検証用のタイマ満了後に到達した場合については一律に、破棄するものとしていた。第３の実施形態では、検証用のタイマ満了後に到達した場合であっても、その遅延量が少ない場合には、処理キューＣに登録する点で変更を加えている。

より具体的には、図９に示すように、検証パケットの送信時刻と応答パケットの受信時刻（受信キュー１５０から応答パケットを取り出した時刻）の時刻差分を検証データ記憶部１６０に格納しておく。そして、この時刻差分を、制御要求をキューに格納するか否かの判定に利用する。

例えば、図９の処理装置２００Ｅの時刻差分ＸＸ秒が、所定の許容範囲内であった場合、第３の実施形態の処理要求部１１０は、低優先の処理キュー１４０Ｃに、処理装置２００Ｅの制御要求を追加する。これにより、一部の処理装置２００、例えば、処理装置２００Ｅが物理的に遠距離に配置されていて、遅延が発生するような場合であっても、制御の対象に加えることが可能となる。一方、図９の処理装置２００Ｆの時刻差分ＹＹ秒が、所定の許容範囲を超えている場合、第２の実施形態と同様に、処理装置２００Ｆの制御要求を破棄する。これにより、処理装置２００Ｆのコネクション確立待ちや応答のタイムアウト待ちで無駄な時間を消費することを回避することが可能となる。

以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示した装置構成、各要素の構成、データの表現形態は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。

また、上記した第１～第３の実施形態に示した手順は、制御装置１、１００として機能するコンピュータ（図１０の９０００）に、制御装置１、１００としての機能を実現させるプログラムにより実現可能である。このようなコンピュータは、図１０のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０１０、通信インタフェース９０２０、メモリ９０３０、補助記憶装置９０４０を備える構成に例示される。すなわち、図１０のＣＰＵ９０１０にて、検証処理プログラムや処理要求（キュー管理）プログラムを実行し、その補助記憶装置９０４０等に保持された各計算パラメーターの更新処理を実施させればよい。

即ち、上記した第１～第３の実施形態に示した制御装置１、１００の各部（処理手段、機能）は、これらの装置に搭載されたプロセッサに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することができる。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点による制御装置参照）
［第２の形態］
上記した制御装置のキュー管理部は、第３のキューに、前記検証処理部に前記検証パケットの送信を要求する検証要求を格納し、
前記検証処理部は、前記第３のキューから前記検証要求を取り出して、前記検証パケットの送信を開始する構成を採ることができる。
［第３の形態］
上記した制御装置の前記検証処理部は、前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの変化を記録し、
前記キュー管理部は、前記検証データを参照して、前記処理装置の前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの状態に変更が生じたときに、前記第１のキューから前記第２のキューへの前記制御要求の移動、又は、前記第２のキューから前記第１のキューへの前記制御要求の移動を行う構成を採ることもできる。
［第４の形態］
上記した制御装置において、前記制御処理部における、前記第２のキューから取り出した制御要求の処理の同時処理数に上限が設けられていることが好ましい。
［第５の形態］
上記した制御装置の前記キュー管理部は、前記制御要求の処理の結果に応じて、前記第１のキューから前記第２のキューへの前記制御要求の移動、又は、前記第２のキューから前記第１のキューへの前記制御要求の移動を行う構成を採ることもできる。
［第６の形態］
上記した制御装置の前記キュー管理部は、前記検証パケットに対する応答がない処理装置の制御要求の、前記第２のキューへの登録を抑止する構成を採ることもできる。
［第７の形態］
上記した制御装置の前記キュー管理部は、前記処理装置の前記検証パケットに対する応答に要した時間が前記所定の閾値を超えていても、所定の範囲内である場合、前記第２のキューに前記処理装置の制御要求を格納する構成を採ることもできる。
［第８の形態］
上記した制御装置の前記検証処理部は、コネクションレス型のプロトコルを用いて、前記処理装置に対し、前記検証パケットを送信する構成を採ることができる。
［第９の形態］
（上記第２の視点による処理装置の制御方法参照）
［第１０の形態］
（上記第３の視点によるプログラム参照）
なお、上記第９～第１０の形態は、第１の形態と同様に、第２～第８の形態に展開することが可能である。

なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１、１００ 制御装置
１１ キュー管理部
１２、１２０ 検証処理部
１３、１３０ 制御処理部
１４Ｂ、１４Ｃ キュー
２Ａ、２Ｂ、２００、２００Ａ～２００Ｅ 処理装置
１１０ 処理要求部
１４０Ａ～１４０Ｃ 処理キュー
１５０ 受信キュー
１６０ 検証データ記憶部
１２１、１３１、１３１Ａ、１３１Ｂ 処理スレッド
９０００ コンピュータ
９０１０ ＣＰＵ
９０２０ 通信インタフェース
９０３０ メモリ
９０４０ 補助記憶装置

Claims (9)

1. 複数の処理装置の制御要求に対して異なる優先度が設定されたキューを用いて前記複数の処理装置の制御要求を処理する制御処理部と、
   前記複数の処理装置に対し、検証パケットを送信する検証処理部と、
   前記検証パケットに対する応答に要した時間が所定の閾値以下である処理装置の制御要求を優先度の高い第１のキューに格納し、その他の処理装置の制御要求を前記第１のキューよりも優先度の低い第２のキューに格納するキュー管理部と、
   を備え、
   前記検証処理部は、前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの変化を検証データとして記録し、
   前記キュー管理部は、前記検証データを参照して、前記処理装置の前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの状態に変更が生じたときに、前記第１のキューから前記第２のキューへの前記制御要求の移動、又は、前記第２のキューから前記第１のキューへの前記制御要求の移動を行う、
   制御装置。
2. 前記キュー管理部は、第３のキューに、前記検証処理部に前記検証パケットの送信を要求する検証要求を格納し、
   前記検証処理部は、前記第３のキューから前記検証要求を取り出して、前記検証パケットの送信を開始する請求項１の制御装置。
3. 前記制御処理部における、前記第２のキューから取り出した制御要求の処理の同時処理数に上限が設けられている請求項１又は２の制御装置。
4. 前記キュー管理部は、前記制御要求の処理の結果に応じて、前記第１のキューから前記第２のキューへの前記制御要求の移動、又は、前記第２のキューから前記第１のキューへの前記制御要求の移動を行う、
   請求項１から３いずれか一の制御装置。
5. 前記キュー管理部は、前記検証パケットに対する応答がない処理装置の制御要求の、前記第２のキューへの登録を抑止する請求項１から４いずれか一の制御装置。
6. 前記キュー管理部は、前記処理装置の前記検証パケットに対する応答に要した時間が前記所定の閾値を超えていても、所定の範囲内である場合、前記第２のキューに前記処理装置の制御要求を格納する請求項１から５いずれか一の制御装置。
7. 前記検証処理部は、コネクションレス型のプロトコルを用いて、前記処理装置に対し、前記検証パケットを送信する請求項１から６いずれか一の制御装置。
8. 複数の処理装置の制御要求に対して異なる優先度が設定されたキューを用いて前記複数の処理装置の制御要求を処理する制御処理部を備えた制御装置が、
   前記複数の処理装置に対し、検証パケットを送信し、
   前記検証パケットに対する応答に要した時間が所定の閾値以下である処理装置の制御要求を優先度の高い第１のキューに格納し、
   前記検証パケットに対する応答に要した時間が所定の閾値を超えている処理装置の制御要求を、前記第１のキューよりも優先度の低い第２のキューに格納し、
   前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの変化を検証データとして記録し、
   前記検証データを参照して、前記処理装置の前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの状態に変更が生じたときに、前記第１のキューから前記第２のキューへの前記制御要求の移動、又は、前記第２のキューから前記第１のキューへの前記制御要求の移動を行う、
   処理装置の制御方法。
9. 複数の処理装置の制御要求に対して異なる優先度が設定されたキューを用いて前記複数の処理装置の制御要求を処理する制御処理部を備えた制御装置に搭載されたコンピュータに、
   前記複数の処理装置に対し、検証パケットを送信する処理と、
   前記検証パケットに対する応答に要した時間が所定の閾値以下である処理装置の制御要求を優先度の高い第１のキューに格納する処理と、
   前記検証パケットに対する応答に要した時間が所定の閾値を超えている処理装置の制御要求を、前記第１のキューよりも優先度の低い第２のキューに格納する処理と、
   前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの変化を検証データとして記録する処理と、
   前記検証データを参照して、前記処理装置の前記検証パケットに対する応答に要した時間が前記所定の閾値以下であるか否かの状態に変更が生じたときに、前記第１のキューから前記第２のキューへの前記制御要求の移動、又は、前記第２のキューから前記第１のキューへの前記制御要求の移動を行う処理と、
   を実行させるプログラム。

Images