JP2015191563A

JP2015191563A - コマンド提供システムおよびコマンド提供装置

Info

Publication number: JP2015191563A
Application number: JP2014069845A
Authority: JP
Inventors: 浩康木村; Hiroyasu Kimura
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2014-03-28
Filing date: 2014-03-28
Publication date: 2015-11-02
Anticipated expiration: 2034-03-28
Also published as: JP6096700B2

Abstract

【課題】統合運用システムにおいて、多くの機器およびソフトウェアのことを考慮した結果、膨大な数のプロトコルおよびＡＰＩが日々生まれてくることとなり、ユーザおよびＡＰＩの提供者の学習コストと運用コストなどがコントロールできる範囲を超え増えている。
【解決手段】ＡＰＩを要求するＡＰＩクライアントとインフラ運用者が操作するためのＨＭＩと複数の通信ノードとネットワーク経由して接続し、通信ノードの状態変化によるイベント情報と設定可能である機能をＡＰＩとして事前に登録した上で、通信ノードにおいて発生したイベント通知の回数と事前に定義した通知回数に対する閾値の値または範囲を元にＡＰＩの利用可否を動的に変更し、利用可能であればＡＰＩクライアントに対して事前定義したＡＰＩを提供するＡＰＩ提供サーバにより、達成できる。
【選択図】図１

Description

本発明は、コマンド提供システムおよびコマンド提供装置に係り、特にシステムの状態に応じて通信ノードの状態を動的に変更させるコマンド提供システムおよびコマンド提供装置に関する。

ＣＯＲＢＡ（Common Object Request Broker Architecture）システム、Ｗｅｂサービス、クラウドコンピューティングといった分散システムを統合的に扱う技術がある。加えて、ＩＥＴＦ（Internet Engenineering Task Force）において検討されているｉ２ｒｓ（Interface to the Routing System）、ＯｐｅｎＦｌｏｗ、近年データセンター向けサービスから始まったＳＤＮ（Software-Defined Network）、キャリア向けサービスであるＮＦＶ（Network Functions Virtualization）といった統合運用システムを構築するための技術が注目を浴びている。

ハードウェアにおいては汎用コンピュータ、モバイル機器を代表とする組込機器、ネットワーク機器、ストレージ機器など、ソフトウェアに関しては様々なアプリケーション、データベースシステム、ＯＳ（Operating System）などをネットワークに接続した上で標準化されたプロトコルまたはＡＰＩ（Application Programming Interface）を用い相互接続することで過去には困難であったシステム間の連携が容易かつ低コストで可能になった。

本技術分野の背景技術として、例えば特許文献１には、ロール情報を用いて複数のサービスのそれぞれについて、アクセスを許可するか否かを統一的に判定することでコストを削減することができることが、開示されている。

特開２０１３−００８２２９号公報

しかし、システム間の連携は、容易に連携かつ低コストでの運用の可能性がある一方、以下のような課題が存在する。
（１）それぞれの技術および機器は、本来の適用されていたシステムのユースケースを最適化する目的において各プロトコルおよびＡＰＩが設計されることで、本来の使用方法とは異なる使い方を強いられるケースがある。
（２）インフラの構築時と、構築が終わり安定した運用時とでは必要とする機能が変わってくる。にもかかわらずユーザに対して必要以上に機能を公開することでユーザの学習コストの増大およびミスによる障害発生などの問題を起こす可能性が常に存在する。
（３）あまりにも多くの機器およびソフトウェアを考慮した結果、膨大な数のプロトコルおよびＡＰＩが日々生まれてくる。この結果、ユーザおよびＡＰＩの提供者の学習コストと運用コストがコントロールできる範囲を超え増えてくる。

特許文献１において、多くの機能をロール情報で管理することにより、コストおよび運用ミスを低減できる。しかし、ロール情報でアクセスできるＡＰＩを制限したとしても大量にＡＰＩがすでに存在しているような場合、または多くのユーザが存在する場合、すでに提供されているＡＰＩの整合性をとった上で提供することは非常に難しく、逆に運用コストが上昇する。

特にクラウド環境などにおいては、様々なシステムを疎結合で繋いで大きなシステムを構築することがあり、詳細なロール情報の内容を判断した上で全ての管理しきることは実環境においては現実的ではない。また、機能の粒度が異なるものを同じロール管理の土俵に乗せることも非常に難しく、実施の形態を見る限りはシステムが肥大化するにつれ複雑化する。

本発明の目的は、ネットワークシステムを構成する通信ノードにおいて利用可能であるすべてのＡＰＩをユーザに対していつでも提供するのではなく、提供者が提供したいと考える時期、機能範囲、通信ノードの構成を考慮した情報に基づき最適化し、必要なタイミングで提供するコマンド提供システムおよびコマンド提供装置を供することにある。

上述した課題は、通信ノードと、この通信ノードにコマンドを提供して、通信ノードを制御するコマンド提供装置と、を含むコマンド提供システムにおいて、通信ノードは、予め定めた第１の条件を満たしたとき、コマンド提供装置にイベント通知を送信し、コマンド提供装置は、イベント通知を受信し、予め定めた第２の条件を満たしたとき、通信ノードにコマンドを送信し、通信ノードは、コマンドを受信したとき、コマンドを設定するコマンド提供システムにより、達成できる。

また、通信ノードとネットワークを介して接続され、通信ノードにコマンドを提供して制御するコマンド提供装置であって、コマンドを登録し、コマンド適用可否を動的に変更させるコマンド登録テーブルと、イベントの種別、イベントの取得内容、イベントの通知元の通信ノード、通知方法を登録するイベント登録テーブルと、事前に登録したイベント情報を元に通知回数を動的に変更するイベント通知テーブルと、通信ノードからイベント通知を受信するイベント取得部と、通信ノードへ、コマンドを送信するコマンド送信部と、コマンド管理部と、を備え、コマンド管理部は、受信したイベント通知の数が予め定めた条件を満たすとき、コマンド送信部にコマンドの送信を指示するコマンド提供装置により、達成できる。

本発明によれば、ネットワークシステムを構成する通信ノードにおいて利用可能であるすべてのＡＰＩをユーザに対していつでも提供するのではなく、提供者が提供したいと考える時期、機能範囲、通信ノードの構成を考慮した情報に基づき最適化し、必要なタイミングで提供ができる。

ＡＰＩ提供システムのブロック図である。ＡＰＩ登録テーブルの構成を説明する図である。イベント登録テーブルの構成を説明する図である。イベント通知テーブルの構成を説明する図である。ＡＰＩＩＤテーブルの構成を説明する図である。ＡＰＩ提供システムの信号の流れを説明するブロック図である。ＡＰＩ管理部の処理を説明するフローチャートである。イベント取得部の処理を説明するフローチャートである。ＳＢＩ送信部とＳＢＩ受信部との間のシーケンス図である。ＡＰＩ提供システムの信号の流れを説明するブロック図である。ＡＰＩ登録テーブルの構成の構成を説明する図である。ＡＰＩＩＤテーブルの構成を説明する図である。イベント通知テーブルの構成を説明する図である。ＡＰＩ提供システムの信号の流れを説明するブロック図である。ＡＰＩ登録テーブルの構成の構成を説明する図である。ＡＰＩＩＤテーブルの構成を説明する図である。イベント通知テーブルの構成を説明する図である。ＡＰＩ提供システムの信号の流れを説明するブロック図である。ＡＰＩ登録テーブルの構成の構成を説明する図である。ＡＰＩＩＤテーブルの構成を説明する図である。イベント通知テーブルの構成を説明する図である。イベント通知テーブルの構成を説明する図である。

以下、本発明の実施の形態について、実施例を用い図面を参照しながら詳細に説明する。

実施例１では、ＳｔａｔｉｃＲｏｕｔｅを扱う通信ノード（通信装置）４００としてルータを適用した場合の、ＡＰＩ提供サーバ（コマンド提供装置）３００を説明する。ここで、ＳｔａｔｉｃＲｏｕｔｅは、宛先ネットワークへの最適なルートを管理者が手動で設定したルートのことである。

図１を参照して、ＡＰＩ提供システムの構成を説明する。図１において、ＡＰＩ提供システム（コマンド提供システム）７００は、ＡＰＩクライアント（端末装置）１００と、ＨＭＩ（ＨｕｍａｎＭａｃｈｉｎｅＩｎｔｅｒｆａｃｅ）（保守装置）２００と、ＡＰＩ提供サーバ３００と、通信ノード４００と、ネットワーク６００と、を含んでいる。

ＡＰＩ提供サーバ３００は、メモリ３１０と、ＣＰＵ３４０と、物理ポート３５０と、を含む。メモリ３１０は、ＡＰＩ管理ＤＢ３２０と、イベント管理ＤＢ３３０と、を保持する。ＡＰＩ管理ＤＢ３２０は、ＡＰＩ登録テーブル（コマンド登録テーブル）３２１と、ＡＰＩＩＤテーブル３２２と、を含む。イベント管理ＤＢ３３０は、イベント登録テーブル３３１と、イベント通知テーブル３３２と、を含む。ＣＰＵ３４０は、イベント取得部３４１と、ＳＢＩ（SouthBound Interface）送信部（コマンド送信部）３４２と、ＡＰＩ管理部（コマンド管理部）３４３と、して機能する。通信ノード４００は、ＳＢＩ受信部４１０と、イベント送信部４２０と、を含む。通信ノード４００は、区別するとき、通信ノード４００−Ａ、通信ノード４００−Ｂと表記する。

ＡＰＩクライアント１００、ＨＭＩ２００、通信ノード４００は、ネットワーク６００を介して、ＡＰＩ提供サーバ３００と物理ポート３５０を介して接続し、相互に通信する。物理ポート３５０は、区別するとき、物理ポート３５０−１、物理ポート３５０−２と記載する。

ＡＰＩクライアント１００は、ＡＰＩ提供システム７００を利用するＡＰＩユーザによって操作される。ＨＭＩ２００は、ＡＰＩ提供システム７００の運用者によって操作され、ＡＰＩ提供サーバ３００に要する情報を登録する。ＨＭＩ２００は、ＡＰＩ提供サーバ３００の物理ポート３５０を経由しＡＰＩ管理部３４３にアクセスする。ＨＭＩ２００は、ＡＰＩ管理ＤＢ（Date Base）３２０とイベント管理ＤＢ３３０上のすべてのテーブルの情報をＡＰＩ提供システム７００の運用前に設定する。

ネットワーク６００は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネットを含むネットワークである。通信ノード４００は、ネットワーク６００とのインタフェースを備え、ＡＰＩ提供サーバ３００と物理ポート３５０を通して接続する。実施例１では、通信ノード４００は、ルータであるとして説明するが、通信ノード４００は、ルータのようなネットワーク機器だけではなく、サーバ、コントロール機能をもつストレージ、モバイル機器を含む通信機能を備えた機器であればよい。

ＨＭＩ２００は、ＡＰＩ提供サーバ３００が提供するＡＰＩの種別とＡＰＩＩＤ登録、イベント登録、イベント通知登録を、事前に行う。ＨＭＩ２００からＡＰＩ提供サーバ３００に対して登録する情報は、事前にＡＰＩ提供システム７００を導入する運用者またはＡＰＩの提供者が登録する。ＡＰＩ提供サーバ３００が行うＡＰＩクライアント１００に対するＡＰＩの提供は、この事前にＡＰＩの提供者が登録した情報をもとに行われる。

ＡＰＩ提供サーバ３００は、通信ノード４００から通信ノード４００で発生した障害および状態の変化のイベントの通知、または、ＡＰＩ提供サーバ３００が取得した内容を受信する。ＡＰＩ提供サーバ３００は、情報を学習し、蓄積し、事前に登録しているＡＰＩのリストのうち提供可能であるＡＰＩの利用可否の情報を変更する。これによって、ＡＰＩ提供サーバ３００は、ＡＰＩクライアント１００に情報を提供する。

ＡＰＩ提供サーバ３００は、メモリ３１０、ＣＰＵ３４０、物理ポート３５０を内部バスによって接続している。ＡＰＩ管理ＤＢ３２０は、ＡＰＩクライアント１００から要求されるＡＰＩの具体的内容の登録と要求されるＡＰＩの名称を管理する。イベント管理ＤＢ３３０は、通信ノード４００からＡＰＩ提供サーバ３００が受信するイベントの事前登録とイベント通知の回数を管理する。

ＡＰＩクライアント１００は、ネットワーク６００を通してＡＰＩ提供サーバ３００に接続することが可能なＰＣ、サーバ、モバイル機器である。ＨＭＩ２００は、ネットワーク６００を通してＡＰＩ提供サーバ３００に接続することが可能なＰＣ、サーバ、モバイル機器であり、ユーザインターフェースを備える。

ＡＰＩ提供サーバ３００は、事前にＨＭＩ２００からＡＰＩ登録とイベント登録の指示を受けて各種登録を行い、ＡＰＩクライアント１００にＡＰＩを提供する。ＡＰＩ提供サーバ３００は、通信ノード４００から通信ノード４００で発生した障害おおび状態の変化のイベントの通知を受けて、ＡＰＩクライアント１００に提供するＡＰＩを変更する。ＡＰＩ提供サーバ３００は、ＡＰＩクライアント１００からのＡＰＩ要求を受けて、通信ノード４００にＳＢＩ要求を送信する。ここで、ＳＢＩは、下り信号である。

ＳＢＩ受信部４１０は、ＡＰＩ提供サーバ３００から送信されたＳＢＩ要求を受信する。ＳＢＩ受信部４１０は、要求されたＳＢＩの内容に合わせて通信ノード４００の機能設定を行う。イベント送信部４２０は、ＡＰＩ提供サーバ３００に対して通信ノード４００において発生した障害および設定変更、状態変化を含むイベント通知を通知する。イベント送信部４２０は、また、ＡＰＩ提供サーバ３００から問い合わせを受けてイベント通知を行う。

イベント通知は、ＳＮＭＰ（Simple Network Management Protocol）のＴｒａｐを用いること、Ｓｙｓｌｏｇなどを用いて通知すること、ＴＣＰ／ＩＰおよびＷｅｂＳｏｃｋｅｔを含むプロトコルを使うことが可能である。イベント通知は、ＡＰＩの提供者が通信ノード４００においてサポートされている通信プロトコルであれば利用することができる。また、イベント発生時に、通信ノード４００からＡＰＩ提供サーバ３００への通知だけではなく、ＡＰＩ提供サーバ３００が、ＲＥＳＴ（Representational State Transfer）、ＨＴＴＰＲｅｑｕｅｓｔ、ｓｃｐコマンド（Secure Copy）、ＦＴＰ（File Transfer Protocol）を含むデータを取得するプロトコルを用いて、定期的にあるいは任意のタイミングで通信ノード４００からイベントを取得する。

図２を参照して、ＡＰＩ登録テーブルを説明する。ＡＰＩ登録テーブルは、ＡＰＩを識別するＩＤ、ＡＰＩを反映させる操作対象、通信ノードに反映させる機能設定スクリプト（ＳＢＩ）を登録し、利用可否を動的に変更させるために利用する。図２において、ＡＩＰ登録テーブル３２１は、ＡＰＩＩＤ３２１０と、ＡＰＩ操作対象３２１１と、ＳＢＩ３２１２と、利用可否３２１３と、を含んで構成されている。

ＡＰＩＩＤ３２１０は、ＡＰＩクライアント１００がＡＰＩ提供サーバ３００に対して要求するＡＰＩを識別する。ＡＰＩ操作対象３２１１は、ＡＰＩによる操作対象となる通信ノード４００を指定する。ＳＢＩ３２１２は、通信ノード４００に対する実際の操作内容である。利用可否３２１３は、ＡＰＩが実際に利用できる状態であるかを示す。

ＳＢＩは、通信ノード４００に対する命令コマンドである。ＳＢＩは、通信機器におけるＣＬＩ（Command Line Interface）、ソフトウェアにおけるＡＰＩ、スクリプトおよび設定のためのプロトコルが該当する。

ＡＰＩ提供サーバ３００は、ＨＭＩ２００によってデータを入力された初期状態として図２（ａ）のＡＰＩ登録テーブル３２１（変更前）を保持する。ＡＰＩ提供サーバ３００は、イベント通知を受けて利用可否３２１３が変更された場合、ＡＰＩ登録テーブル３２１（変更後）のように利用可否３２１３を、「ＮＧ」から「ＯＫ」に変更する。

図２において、ＡＰＩＩＤが「１」のレコードは、後述する図６の経路１に該当する。一方、ＡＰＩＩＤが「２」のレコードは、図６の経路２に該当する。

図３を参照して、イベント登録テーブルの構成を説明する。イベント登録テーブルは、イベントの種別、イベントの取得内容、イベントの通知元の通信ノード、通知方法を登録するテーブルである。図３において、イベント登録テーブル３３１は、通知種別ＩＤ３３１０と、取得情報３３１１と、イベント通知元３３１２と、通知方法３３１３と、を含む。

通知種別ＩＤ３３１０は、通信ノード４００から受信したイベント通知を識別する。取得情報３３１１は、イベント通知によって取得される情報である。イベント通知元３３１２は、複数存在する通信ノード４００のうちどの通信ノード４００からイベントを受信したかを示す。通知方法３３１３は、通信ノード４００からのイベント通知をどのような方法で受信したかを示す。

図４を参照して、イベント通知テーブルの構成を説明する。イベント通知テーブルは、ＡＰＩを識別するＩＤ、通信ノードからのイベントを識別するＩＤ、事前にＡＰＩの利用可否を判断するために定義する通知回数の閾値と範囲、通知回数を保持し、事前に登録したイベント情報を元に通知回数を動的に変更するテーブルである。図４において、イベント通知テーブル３３２は、ＡＰＩＩＤ３３２０と、通知種別ＩＤ３３２１と、通知回数閾値３３２２と、通知回数３３２３と、を含む。

ＡＰＩＩＤ３３２０は、ＡＰＩクライアント１００がＡＰＩ提供サーバ３００に対して要求するＡＰＩを識別する。通知種別ＩＤ３３２１は、イベント通知を識別する。通知回数閾値３３２２は、通信ノード４００からのイベントの通知回数が指定した範囲内にあるかどうかを判断する。通知回数３３２３は、通信ノード４００からＡＰＩ提供サーバ３００へのイベントを通知した回数を示す。

図５を参照して、ＡＰＩＩＤテーブルの構成を説明する。ＡＰＩＩＤテーブルは、ＡＰＩクライアントに対して提供するＡＰＩ種別のリストを登録するテーブルである。図５において、ＡＰＩＩＤテーブル３２２は、ＡＰＩＩＤ３２２０と、ＡＰＩ名３２２１と、を含む。

ＡＰＩＩＤ３２２０は、ＡＰＩクライアント１００がＡＰＩ提供サーバ３００に対して要求するＡＰＩを識別する。ＡＰＩ名３２２１は、ＡＰＩＩＤ３２２０に対応するＡＰＩの名称、関数、メソッド名を示す。

ＡＰＩ登録テーブル３２１、ＡＰＩＩＤテーブル３２２、イベント通知テーブル３３２に存在するＡＰＩＩＤは、同一のものを指し示す。

図６を参照して、ＡＰＩ提供システムの信号の流れを説明する。図６において、ＡＰＩ提供システム７００Ａは、ＡＰＩクライアント１００と、ＨＭＩ２００と、ＡＰＩ提供サーバ３００と、ルータ５００と、を含んでいる。図１の通信ノード４００は、ルータ５００−Ａ、ルータ５００−Ｂ、ルータ５００−Ｃに相当する。ルータ５００は、それぞれ有線の物理インタフェースにより、図示しないネットワーク６００と接続している。なお、ルータ５００−Ｘ（Ｘ＝Ａ〜Ｃ）をルータＸと表記することがある。

ルータ５００は、物理インタフェースに１９２.０.２.０から始まる／３０のサブネットで分割したＩＰアドレスを設定している。ルータ５００−Ａは、ルータ５００−Ｃと接続する物理インタフェースに１９２.０.２.１／３０、ルータ５００−Ｂと接続する物理インタフェースに１９２.０.２.５／３０を設定している。ルータ５００−Ｂは、ルータＡと接続する物理インタフェースに１９２.０.２.６／３０、ルータ５００−Ｃと接続する物理インタフェースに１９２.０.２.１０／３０のＩＰアドレスを設定している。ルータ５００−Ｃは、ルータ５００−Ａと接続する物理インタフェースに１９２.０.２.２／３０、ルータＢと接続する物理インタフェースに１９２.０.２.９／３０、外部ネットワークへの物理インタフェースに１９２.０.２.１３／３０を設定している。

ルータ５００−Ａからルータ５００−Ｂを経由し、ルータ５００−Ｃの外部ネットワークへの経路１と、ルータ５００−Ａからルータ５００−Ｃに直接繋がる経路２の二つの経路を考える。それぞれの経路に必要な各ルータの設定を、ＳＢＩとしてＡＰＩ登録テーブル３２１のＳＢＩ３２１２にＡＰＩの提供者が登録する。この二つの経路は、いずれのルータにおいても未設定とし、ルータ５００−Ａからルータ５００−Ｃに対してはこの経路以外の経路が存在していて、Ｐｉｎｇコマンドをルータ５００−Ａからルータ５００−Ｃに対して送信した際に正常に送信できたとする。

ルータ５００−Ａからルータ５００−Ｃの外部ネットワークへのＩＰアドレスである１９２.０.２.１３／３０への接続性を経路のコントロールにより確保する。ルータ５００−ＡからルータＣの１９２.０.２.１３に対してＰｉｎｇコマンドによって接続性を検証し到達性がなかった（到達しなかった）際に発生するｉｃｍｐエラーをルータ５００−ＡからのＳＮＭＰｔｒａｐによってＡＰＩ提供サーバ３００に通知する。これによって、ルータ５００−Ａから５００−Ｃへの物理回線の疎通が不安定になったことをＡＰＩ提供サーバ３００が検知できる。

ＡＰＩ提供サーバ３００は、Ｐｉｎｇコマンドによって発生したイベント通知を受信して、イベント登録テーブル３３１のイベントとして登録する。ＡＰＩ提供サーバ３００は、イベント通知テーブル３３２の通知回数３３２３に登録することにより、ルータ５００−Ａのイベントとして扱う。

ＡＰＩをＡＰＩ提供サーバ３００において提供する場合、ＡＰＩ登録テーブル３２１、ＡＰＩＩＤテーブル３２２、イベント通知テーブル３３２、イベント登録テーブル３３１、を事前に登録しておく。通信ノード４００がどのようなＳＢＩとイベント通知の機能を持っているかに関して、マニュアルを含むドキュメントを参照する、または通信ノード４００の備えている機能を参照する。ＡＰＩまたはプロトコルが実装されていれば、参照した結果を直接各テーブルに反映することもできる。

ここでは、ネットワークの運用者が、ＨＭＩ２００を利用し、初期設定としてＡＰＩ登録テーブル３２１を、ＡＰＩ登録テーブル３２１（変更前）のように登録する。利用可否３２１３はすべてＮＧ状態となっている。

ＡＰＩは、ＡＰＩＩＤテーブル３２２にあるようにＡＰＩＩＤ３２２０の値が０００１と０００２となる二つのＡＰＩに分かれる。ＡＰＩ登録テーブル３２１のＡＰＩＩＤで参照すると、ＡＰＩＩＤ３２１０の値が０００１のものがルータ５００−Ｂを経由した経路１を設定するＡＰＩを示し、ＡＰＩＩＤ３２１０の値が０００２のものがルータ５００−Ａからルータ５００−Ｃまで直接の経路である経路２を設定するＡＰＩである。図２（ａ)のＡＰＩ登録テーブル（変更前）は、ルータ５００−Ａ、ルータ５００−Ｂ、ルータ５００−Ｃに登録するＳｔａｔｉｃＲｏｕｔｅのＳＢＩが登録されている。

図７を参照して、ＡＰＩ管理部の処理を説明する。なお、ＨＭＩ２００を利用し、ＡＰＩ提供サーバ３００に、ＡＰＩ登録テーブル３２１、ＡＰＩＩＤテーブル３２２、イベント通知テーブル３３２、イベント登録テーブル３３１が登録されているものとする。

図７において、ＡＰＩ管理部３４３は、ＡＰＩクライアント１００からＡＰＩリストの要求を受信する（Ｓ１００）。ＡＰＩ管理部３４３は、ＡＰＩＩＤテーブル３２２からＡＰＩリストを取得する（Ｓ１１０）。ＡＰＩ管理部３４３は、ＡＰＩリストが取得できたか判定する（Ｓ１２０）。Ｎｏのとき、ＡＰＩ管理部３４３は、ステップ１００に戻る。ステップ１２０でＹｅｓのとき、ＡＰＩ管理部３４３は、ＡＰＩクライアント１００にＡＰＩリストを返却する（Ｓ１３０）。ＡＰＩ管理部３４３は、ＡＰＩクライアントがＡＰＩリストから選択したＡＰＩの実行要求を受信する（Ｓ１４０）。ＡＰＩ管理部３４３は、ＡＰＩのＡＰＩ名をキーとしてＡＰＩＩＤテーブル３２２からＡＰＩＩＤを取得する（Ｓ１５０）。ＡＰＩ管理部３４３は、ＡＰＩ登録テーブル３２１からＡＰＩＩＤをキーとして利用可否３２１３の値を取得する（Ｓ１６０）。ＡＰＩ管理部３４３は、利用可否３２１３の値がＯＫか判定する（Ｓ１７０）。Ｎｏのとき、ＡＰＩ管理部３４３は、終了する。ステップ１７０でＹｅｓのとき、ＡＰＩ管理部３４３は、ＡＰＩＩＤ３２１０をキーにＡＰＩ登録テーブル３２１からＡＰＩ操作対象３２１１とＳＢＩ３２１２の対となる情報をすべて取得する（Ｓ１８０）。ＡＰＩ管理部３４３は、ＳＢＩ送信部にＡＰＩ操作対象とＳＢＩの値をセットとしたリストを送信して（Ｓ１９０）、終了する。

具体的に説明すると、ＡＰＩクライアント１００は、ｓｔａｔｉｃＡ＿Ｂ＿Ｃを選択し、実行要求を出したとする。ＡＰＩ管理部３４３は、ＡＰＩ名３３２１のｓｔａｔｉｃＡ＿Ｂ＿ＣをキーとしてＡＰＩＩＤテーブル３２２のＡＰＩＩＤ３２２０から０００１というＡＰＩＩＤを取得する。さらに、ＡＰＩ管理部３４３は、ＡＰＩ登録テーブル３２１からＡＰＩＩＤが０００１であるエントリから利用可否３２１３の値を取得する。ＡＰＩ登録テーブル３２１（変更前）を参照すると利用可否３２１３には、「ＮＧ」の値が入っている。このため、ＡＰＩ管理部３４３は、ＡＰＩクライアント１００から実行要求を終了する。

図８を参照して、イベントを取得し、イベントの処理を扱うイベント取得部の処理を説明する。ここでは、Ｐｉｎｇ送信によるエラーイベントの処理を説明する。なお、ルータ５００−Ａからルータ５００−Ｃに対してＰｉｎｇを送信しているが、通信路に問題があり何度かｉｃｍｐエラーが発生することが確認されていることを前提とする。

図８において、イベント取得部３４１は、ルータ５００−Ａのイベント送信部４２０からイベント通知６００を受信する（Ｓ３００）。イベント取得部３４１は、イベント通知の取得情報とイベント通知元をキーとしてイベント登録テーブル３３１から通知種別ＩＤ３３１０を取得する（Ｓ３１０）。イベント取得部３４１は、通知種別ＩＤ３３１０が取得できたか判定する（Ｓ３２０）。Ｙｅｓのとき、イベント取得部３４１は、イベント通知テーブル３３２の通知種別ＩＤ３３２１に該当する通知回数３３２３を＋１更新する（Ｓ３３０）。イベント取得部３４１は、イベント通知テーブル３３２の通知回数３３２３と通知回数閾値３３２２の範囲と比較する（Ｓ３４０）。イベント取得部３４１は、範囲内であるか判定する（Ｓ３５０）。Ｙｅｓのとき、イベント取得部３４１は、ＡＰＩ登録テーブル３２１の利用可否３２１３の値を「ＯＫ」に変更して（Ｓ３６０）、終了する。ステップ３５０でＮｏのとき、イベント取得部３４１は、ＡＰＩ登録テーブル３２１の利用可否３２１３の値を「ＮＧ」に変更して（Ｓ３７０）、終了する。ステップ３２０でＮｏのとき、イベント取得部３４１は、イベント送信部４２０に該当通知種別ＩＤが見つからなかったことを送信して（Ｓ３８０）、終了する。

なお、ステップ３６０において、もともとＯＫのとき、イベント取得部３４１は、ＯＫを維持する。また、ステップ３７０において、もともとＮＧのとき、イベント取得部３４１は、ＮＧを維持する。

図９を参照して、ＡＰＩ提供サーバのＳＢＩ送信部と、通信ノードのＳＢＩ受信部の動作を説明する。図９において、ＳＢＩ送信部３４２は、物理ポート３５０を介して、ＳＢＩの値をＡＰＩ操作対象のＳＢＩ受信部４１０にそれぞれ送信する（Ｓ２１０）。各ルータのＳＢＩ受信部４１０は、受信したＳＢＩの内容をルータに設定する（Ｓ２２０）。

具体的には、図２（ｂ）に示すように、ルータ５００−Ａは、ｉｐｒｏｕｔｅ１９２.０.２.１２２５５.２５５.２５５.２５２１９２.０.２.６が反映される。ルータ５００−Ｂは、ｉｐｒｏｕｔｅ１９２.０.２.１２２５５.２５５.２５５.２５２１９２.０.２.９が反映される。ルータ５００−Ｃは、ｉｐｒｏｕｔｅ１９２.０.２.４２５５.２５５.２５５.２５５.２５２１９２.０.２.１０が反映される。

以上のように、各ＡＰＩは、運用者がＨＭＩ２００を利用して設定したＡＰＩ提供条件に応じて、通信ノード４００の状態に依存して、動的に利用可否を変更することができる。したがって、インフラの状態および時期によって適切なタイミングで運用者が意図したＡＰＩを提供することが可能となる。本実施例ではイベント通知元が一カ所でありイベント通知元と、ＳＢＩ送信先とが、通信ノード４００として同一の場合である。また、ＳＢＩの反映先として複数の通信ノード４００が存在する場合を示した。

以下、実施例１の変形例を説明する。以下の変形例は、通信ノードの構成とイベント通知の方式またはイベントの通知元の組合せが異なる。
[変形例１]
変形例１では、イベント通知元とＳＢＩの反映先が同一の場合の構成を説明する。

図１０を参照して、他のＡＰＩ提供システムの構成を説明する。図１０において、ＡＰＩ提供システム７００Ｂは、ＡＰＩクライアント１００と、ＨＭＩ２００と、ＡＰＩ提供サーバ３００と、ＰＣ５１０と、Ｈｕｂ５１２と、スイッチ５１３と、サーバ５１４と、を含んで構成されている。なお、既に説明した実施例１と同一の符号を付された装置については、説明を省略する。

通信ノード４００に該当するのがＰＣ５１０−Ａ、ＰＣ５１０−Ｂ、Ｈｕｂ５１２、スイッチ５１３、サーバ５１４となる。ＰＣ５１０−ＡとＰＣ５１０−Ｂからサーバ５１４への経路３、経路４を介する通信がスイッチ５１３のＶＬＡＮ（Virtual Local Area Network）Ａ（今後＃ＩＦＶＬＡＮＡと表記）を経由し、通信フィルタを行う。実施例１と異なる点は、イベント通知元とＳＢＩ送信先が単一かつ同一装置であるという点である。

図１１のＡＰＩ登録テーブル３２１Ｂ、図１２のＡＰＩＩＤテーブル３２２Ａ、図１３のイベント通知テーブル３３２Ａについて、ＡＰＩ提供システム７００Ｂの運用者は、事前に登録する。なお、図３のイベント登録テーブル３３１は、実施例１と共通である。図１２において、ＳＢＩとしてフィルタを定義することでＡＰＩ名はフィルタの利用可否が選択できる。

図１１を参照して、ＡＰＩ登録テーブルを説明する。図１１において、ＡＰＩ登録テーブル３２１Ｂは、ＡＰＩＩＤ３２１０と、ＡＰＩ操作対象３２１１と、ＳＢＩ３２１２と、利用可否３２１３と、を含んで構成されている。ＳＢＩ３２１２は、スイッチに対する実際の操作内容である。

図１２を参照して、ＡＰＩＩＤテーブルを説明する。図１２において、ＡＰＩＩＤテーブル３２２Ａは、ＡＰＩＩＤ３２２０と、ＡＰＩ名３２２１と、を含む。ＡＰＩ名３２２１は、フィルタ種別を記載する。

図１３を参照して、イベント通知テーブルを説明する。図１３において、イベント通知テーブル３３２Ａは、ＡＰＩＩＤ３３２０と、通知種別ＩＤ３３２１と、通知回数閾値３３２２と、通知回数３３２３と、を含む。
[変形例２]
変形例２は、イベント通知元とＳＢＩの反映先が異なり、通信ノードの役割が異なっている場合を説明する。

図１４を参照して、他のＡＰＩ提供システムの構成を説明する。図１４において、ＡＰＩ提供システム７００Ｃは、ＡＰＩクライアント１００と、ＨＭＩ２００と、ＡＰＩ提供サーバ３００と、ＰＣ５１０と、Ｈｕｂ５１２と、認証スイッチ５２５と、認証サーバ５２６と、を含んで構成されている。なお、既に説明した実施例１と同一の符号を付された装置については、説明を省略する。

図１４において、通信ノード４００に該当するのが複数のＰＣ５１０、Ｈｕｂ５１２、認証スイッチ５２５、認証サーバ５２６である。認証スイッチ５２５は、ユーザを認証する機能を持ったＬＡＮスイッチである。認証スイッチ５２５は、認証サーバ５２６と連携して、決められたユーザしかネットワークへアクセスさせない。

認証スイッチ５２５は、認証先のＶＬＡＮとして、ＶＬＡＮ−ＡとＶＬＡＮ−Ｂとを用意する。ＰＣ５１０は、認証スイッチ５２５により、ＶＬＡＮ−Ａ、ＶＬＡＮ−Ｂのネットワークに振り分けられる。実施例１と異なる点は認証サーバ５２６がイベント通知の通知元となっており、ＳＢＩを送信する対象である通信ノード４００と異なっている点である。

図１５のＡＰＩ登録テーブル３２１Ｃ、図１６のＡＰＩＩＤテーブル３２２Ｂ、図１７のイベント通知テーブル３３２Ｂについて、ＡＰＩ提供システムの運用者は、事前に登録する。なお、図３のイベント登録テーブル３３１は、実施例１と共通である。図１５において、ＳＢＩとしてＶＬＡＮを定義することでＡＰＩ名はＭＡＣ（Media Access Control）アドレスが選択できる。

図１５を参照して、ＡＰＩ登録テーブルを説明する。図１５において、ＡＰＩ登録テーブル３２１Ｃは、ＡＰＩＩＤ３２１０と、ＡＰＩ操作対象３２１１と、ＳＢＩ３２１２と、利用可否３２１３と、を含んで構成されている。ＳＢＩ３２１２は、認証スイッチに対する実際の操作内容である。

図１６を参照して、ＡＰＩＩＤテーブルを説明する。図１６において、ＡＰＩＩＤテーブル３２２Ｂは、ＡＰＩＩＤ３２２０と、ＡＰＩ名３２２１と、を含む。ＡＰＩ名３２２１は、ＭＡＣアドレスを記載する。

図１７を参照して、イベント通知テーブルを説明する。図１７において、イベント通知テーブル３３２Ｂは、ＡＰＩＩＤ３３２０と、通知種別ＩＤ３３２１と、通知回数閾値３３２２と、通知回数３３２３と、を含む。
[変形例３]
変形例３は、イベントの通知方法がこれまでの通知ではなくＡＰＩ提供サーバ３００から取得する例を説明する。

図１８を参照して、他のＡＰＩ提供システムを説明する。図１８において、ＡＰＩ提供システム７００Ｄは、ＡＰＩクライアント１００と、ＨＭＩ２００と、ＡＰＩ提供サーバ３００と、コントローラ５３０と、ＶＭ（Virtual Machine）５３１と、を含んで構成されている。なお、既に説明した実施例１と同一の符号を付された装置については、説明を省略する。

図１８において、通信ノード４００は、ＶＭ５３１と、コントローラ５３０とである。上述した実施例１、変形例１、２において、イベントはＡＰＩ提供サーバ３００に対して通知を行っていた。しかし、変形例３において、定期的または不定期的に、ＡＰＩ提供サーバ３００から通信ノード４００に対して情報を取得する。

図１９のＡＰＩ登録テーブル３２１Ｄ、図２０のＡＰＩＩＤテーブル３２２Ｃ、図２１のイベント通知テーブル３３２Ｃについて、ＡＰＩ提供システム７００Ｄの運用者は、事前に登録する。なお、図３のイベント登録テーブル３３１は、実施例１と共通である。図１９において、ＳＢＩとして仮想ＣＰＵ割り当て増加、仮想メモリ割り当て増加を定義することでＡＰＩ名はＶＭｅｄｉｔが選択できる。

図１９を参照して、ＡＰＩ登録テーブルを説明する。図１９において、ＡＰＩ登録テーブル３２１Ｄは、ＡＰＩＩＤ３２１０と、ＡＰＩ操作対象３２１１と、ＳＢＩ３２１２と、利用可否３２１３と、を含んで構成されている。ＳＢＩ３２１２は、コントローラ５３０に対する実際の操作内容である。

図２０を参照して、ＡＰＩＩＤテーブルを説明する。図２０において、ＡＰＩＩＤテーブル３２２Ｃは、ＡＰＩＩＤ３２２０と、ＡＰＩ名３２２１と、を含む。ＡＰＩ名３２２１は、ＶＭｅｄｉｔを記載する。

図２１を参照して、イベント通知テーブルを説明する。図１３において、イベント通知テーブル３３２Ｃは、ＡＰＩＩＤ３３２０と、通知種別ＩＤ３３２１と、閾値３３２４と、取得値３３２５と、を含む。閾値３３２４と取得値３３２５の単位は、パーセント（％）である。

変形例３は、これまでの通知回数での判断と異なり、図２１のイベント通知テーブル３３２の取得値（％）３３２５として登録する。ここでは、取得値を１００分率の単位としたが、通信ノードにおいて取得できる情報に応じて適宜変更が可能である。

実施例１および変形例によれば、必要な時期に必要なＡＰＩのみを提供することによりユーザが知っていればよいＡＰＩは登録されているＡＰＩだけでよくなり、必要以上のパラメータを操作してしまうこと、および必要がないにも係わらずＡＰＩを呼び出すことがなくなり、設定ミスによる障害を減らすことが可能となる。

実施例２は、通知回数閾値と通知回数の対比による利用可否識別ではなくスケジュールによって利用可否を決定する。

図２２を参照して、実施例２におけるイベント通知テーブルを説明する。図２２において、イベント通知テーブル３３２Ｄは、ＡＰＩＩＤ３３２０と、通知種別ＩＤ３３２１と、スケジュール３３２６と、を含む。なお、既に説明した実施例１と同一の符号を付された装置については、説明を省略する。

図２２のイベント通知のスケジュール３３２６がこれまでの通知回数閾値３３２２と通知回数３３２３と異なっている。また通知種別ＩＤ３３２１はスケジュールであるため他のイベント通知と異なった体系の値をいれる。図２２の場合は００００が入っている。図３のイベント登録テーブル３３１においても上記までと異なりイベント通知元３３１２に「−」、通知方法３３１３に「−」が入っている。スケジュール３３２６は、年月日時分、曜日、午前午後など運用者が任意で入れることが可能である。イベント取得部３４１は、任意のタイミングでスケジュール３３２６の値を読み取り、現在の時刻と比較することでＡＰＩの利用可否の判断を行う。

実施例２によれば、イベント通知だけをＡＰＩの利用可否の判断にするのではなくスケジュールによる判断を追加することでインフラの稼働時期を意識したＡＰＩ提供も可能となる。

１００…ＡＰＩクライアント、２００…ＨＭＩ、３００…ＡＰＩ提供サーバ、３１０…メモリ、３２０…ＡＰＩ管理ＤＢ、３２１…ＡＰＩ登録テーブル、３２２…ＡＰＩ…ＩＤテーブル、３３０…イベント管理ＤＢ、３３１…イベント登録テーブル、３３２…イベント通知テーブル、３４０…ＣＰＵ、３４１…イベント取得部、３４２…ＳＢＩ送信部、３４３…ＡＰＩ管理部、３５０…物理ポート、４００…通信ノード、４１０…ＳＢＩ受信部、４２０…イベント送信部、５００…ルータ、５１０…ＰＣ、５１２…Ｈｕｂ、５１３…スイッチ、５１４…サーバ、５２５…認証スイッチ、５３０…コントローラ、５３１…ＶＭ、６００…ネットワーク、７００…ＡＰＩ提供システム。

Claims

通信ノードと、この通信ノードにコマンドを提供して、前記通信ノードを制御するコマンド提供装置と、を含むコマンド提供システムにおいて、
前記通信ノードは、予め定めた第１の条件を満たしたとき、前記コマンド提供装置にイベント通知を送信し、
前記コマンド提供装置は、前記イベント通知を受信し、予め定めた第２の条件を満たしたとき、前記通信ノードに前記コマンドを送信し、
前記通信ノードは、前記コマンドを受信したとき、前記コマンドを設定することを特徴とするコマンド提供システム。
請求項１に記載のコマンド提供システムであって、
前記第１の条件は、障害発生、設定変更または状態変化であることを特徴とするコマンド提供システム。
請求項１に記載のコマンド提供システムであって、
前記第２の条件は、通知回数の閾値超または範囲内、もしくはスケジュールであることを特徴とするコマンド提供システム。
通信ノードとネットワークを介して接続され、前記通信ノードにコマンドを提供して制御するコマンド提供装置であって、
コマンドを登録し、コマンド適用可否を動的に変更させるコマンド登録テーブルと、
イベントの種別、イベントの取得内容、イベントの通知元の通信ノード、通知方法を登録するイベント登録テーブルと、
事前に登録したイベント情報を基に通知回数を動的に変更するイベント通知テーブルと、
前記通信ノードからイベント通知を受信するイベント取得部と、
前記通信ノードへ、前記コマンドを送信するコマンド送信部と、
コマンド管理部と、
を備え、
前記コマンド管理部は、受信した前記イベント通知の数が予め定めた条件を満たすとき、前記コマンド送信部に前記コマンドの送信を指示することを特徴とするコマンド提供装置。
請求項４に記載のコマンド提供装置であって、
前記コマンド送信部は、前記コマンド登録部に保持された前記コマンドを前記通信ノードに送信することを特徴とするコマンド提供装置。
請求項４に記載のコマンド提供装置であって、
前記コマンド管理部は、前記イベント通知テーブルに基づいて、前記コマンド送信部に前記コマンドの送信を指示することを特徴とするコマンド提供装置。