JPWO2008149455A1 - マネジャ、エージェント及びシステム並びに送信制御方法 - Google Patents

マネジャ、エージェント及びシステム並びに送信制御方法 Download PDF

Info

Publication number
JPWO2008149455A1
JPWO2008149455A1 JP2009517671A JP2009517671A JPWO2008149455A1 JP WO2008149455 A1 JPWO2008149455 A1 JP WO2008149455A1 JP 2009517671 A JP2009517671 A JP 2009517671A JP 2009517671 A JP2009517671 A JP 2009517671A JP WO2008149455 A1 JPWO2008149455 A1 JP WO2008149455A1
Authority
JP
Japan
Prior art keywords
manager
agent
command
load information
load
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009517671A
Other languages
English (en)
Other versions
JP4978693B2 (ja
Inventor
和紀 柴田
和紀 柴田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2008149455A1 publication Critical patent/JPWO2008149455A1/ja
Application granted granted Critical
Publication of JP4978693B2 publication Critical patent/JP4978693B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

ネットワークに接続されたエージェントを、ＳＮＭＰにより管理するマネジャに、自マネジャが備えるＣＰＵの負荷状態を示すＣＰＵ占有率と、エージェントにより送信された、該エージェントが搭載される機器内部の状態変化を通知する状態変化通知コマンドの単位時間あたりの受信数を示す状態変化通知コマンド受信状況と、自マネジャが定期的に実行する処理を実行するまでの時間を示す負荷事象発生時間に基づいて、自マネジャの負荷状態を示すマネジャ負荷情報を生成する負荷情報生成手段と、エージェントに送信するコマンドを生成するコマンド生成手段とを備え、コマンド生成手段は、マネジャ負荷情報を含むコマンドを生成し、エージェントは、コマンドに含まれるマネジャ負荷情報に基づいて、状態変化通知コマンドの送信を制御することにより達成される。

Description

本発明は、ネットワーク装置と管理システムとの間が簡易ネットワーク管理プロトコル（SNMP: Simple Network Management Protocol)により接続されるシステムにおけるマネジャ、エージェント及びシステム並びに送信制御方法に関する。
ネットワーク上の通信では、情報の抜け、漏れを無くし、効率良くデータを送信することが求められる。ネットワーク上の通信の中で簡易ネットワーク管理プロトコル（以下、ＳＮＭＰと呼ぶ）は、通信負荷の軽いデータ送信方法として注目されている。
ＳＮＭＰは、エージェントのネットワーク管理情報を、マネジャに送る際の標準のプロトコルとして一般的に知られている。ＳＮＭＰの通信方式は大まかに、マネジャからの情報取得要求に対するエージェントの応答、エージェント側の状態変化に対するマネジャへの自発送信に分類することができる。
ＳＮＭＰでは、ＴＣＰ／ＩＰなどで知られているような双方向通信は実施されない。従って、ＳＮＭＰでは、送信データが正しく宛先に届いたかどうかの確認や、送信データが宛先に届いていない場合に行われる再送などの動作は補償されない。
そのため、マネジャからの情報取得要求に対するエージェントの応答処理を実行する際は、マネジャ側でタイマなどにより所定の応答待ち時間を設定し、該所定の応答待ち時間が経過してもエージェントからの応答がない場合に、リトライ処理を複数回繰り返す施策が講じられている。
一方、エージェント側に状態変化が生じた場合に、エージェント側がマネジャへトラップ（Ｔｒａｐ）の自発送信を行う場合は、エージェント側からの自発発信のため、タイマなどによる所定の応答待ち時間を設定するなどの施策を施すことができず、マネジャが本当にトラップを受信したか否かをエージェントは知ることができない。そのため、たまたまマネジャが高負荷の状態にあり処理が輻輳している場合には、トラップデータを取りこぼしてしまう問題がある。
上述したように、ＳＮＭＰには、マネジャ側の負荷状況によりトラップ受信を取りこぼす問題が懸念されており、それを解決するために、以下に示す改善策が提案されている。具体的には、送受信データに整理番号（以降、「シーケンス番号」と記述）を付与する方法、エージェント側にデータベース（以降、「ＤＢ」と記述）を作成し、その中にデータを保存する方法、エージェントに対して定期的にマネジャが情報取得を行うポーリング方法である。
従来の改善策、すなわち、シーケンス番号を付与する方法、ＤＢにデータを保存する方法、定期的にポーリングを行う方法について説明する。
シーケンス番号を付与する方法について、図１を参照して説明する。
図１には、ＳＮＭＰによりネットワークを管理する機器上のマネジャと、管理対象となる各ネットワーク機器に常駐するエージェント（エージェントＡ、エージェントＢ及びエージェントＣ）が示される。
マネジャとエージェントとの間では、定期的、例えばｎ秒毎（ｎは、ｎ>０の実数）にシーケンス番号の整合性のチェックが実施される。例えば、マネジャは、管理対象となるネットワーク機器に対して、定期的にシーケンス番号取得コマンドを送信する（ステップＳ２１、Ｓ２２、Ｓ２３）。エージェントは、シーケンス番号取得コマンドを受信すると、該シーケンス番号取得コマンドの応答として、自エージェントの保有するシーケンス番号をマネジャに通知する（ステップＳ４１、Ｓ４２、Ｓ４３）。マネジャは、エージェントから通知されたシーケンス番号を記憶する。図１では、一例として、エージェントＡからシーケンス番号１０１が通知され、エージェントＢからシーケンス番号２０１が通知され、エージェントＣからシーケンス番号３０１が通知される場合を示す。マネジャは、エージェントＡのシーケンス番号１０１を記憶し、エージェントＢのシーケンス番号２０１を記憶し、エージェントＣのシーケンス番号３０１を記憶する。
エージェント側で状態変化が発生した場合は、シーケンス番号を付与して状態を通知する（ステップＳ６）。例えば、トラップパケットを送信する。マネジャは、通知された状態及びシーケンス番号を保存する。各エージェントが連続して状態を通知することにより、マネジャの負荷が上昇する。その結果、マネジャでは、トラップの取りこぼしが発生し得る。例えば、各エージェントは、状態変化が発生した場合、シーケンス番号を付与して状態情報を通知する。マネジャ側ではトラップを連続して受信することにより負荷が上昇する。その結果、マネジャ側ではトラップを取りこぼす。例えば、エージェントＡは、状態変化が発生した場合、シーケンス番号１０２を付与して状態情報の通知を行うが、マネジャ側では負荷が上昇しているため、そのトラップを取りこぼす（ステップＳ８）。
その後、マネジャは、定期的に行っているシーケンス番号取得コマンドを送信する（ステップＳ１０）。エージェントは、シーケンス番号取得コマンドを受信すると、該シーケンス番号取得コマンドの応答として、自エージェントの保有するシーケンス番号をマネジャに通知する（ステップＳ１２）。
マネジャは、自マネジャが記憶するシーケンス番号が、エージェントにより送信されたシーケンス番号に一致するか否かを判断する。マネジャは、負荷が上昇しているときにトラップを取りこぼしているため、マネジャ−エージェント間でシーケンス番号の不一致が生じる（ステップＳ１４）。
マネジャは、エージェントとの間でシーケンス番号の不一致が生じた場合、エージェントに対し抜けている状態情報を獲得するコマンド（状態送信要求）を発信する。例えば、自マネジャが記憶しているシーケンス番号に対応する状態変化を示す状態情報を獲得するコマンドを発信する（ステップＳ１６）。
エージェントは、状態送信要求を受信すると、現在発生中の状態情報をマネジャに通知する（状態送信要求応答）（ステップＳ１８）。この際、エージェントのシーケンス番号を合わせて通知する。このようにすることで、マネジャ−エージェント間のシーケンス番号を一致させることができる。
図１において、例えばステップＳ８においてシーケンス番号１０２が付与された状態情報の通知を、マネジャで取りこぼさずに受信できた場合には、ステップＳ１４で、マネジャは、自マネジャが記憶するシーケンス番号と、エージェントにより送信されたシーケンス番号とが一致すると判断する。その後、定期的に整合性チェックが実施される。
次に、ＤＢにデータを保存する方法について、図２を参照して説明する。
図２には、ＳＮＭＰによりネットワークを管理する機器上のマネジャと、管理対象となる各ネットワーク機器に常駐するエージェント（エージェントＡ、エージェントＢ及びエージェントＣ）が示される。
各エージェントでは、状態変化が発生すると、該状態情報を各エージェントが備えるＤＢにシーケンス番号と対応させて保存する。そして、各エージェントでは、シーケンス番号を付与して状態情報を通知する（ステップＳ２２１、Ｓ２２２及びＳ２２３）。例えば、エージェントＡでは発生した状態変化を示す状態情報をシーケンス番号１２２に対応させて保存し、シーケンス番号１２２を付与して状態情報の通知を行い（ステップＳ２２１）、エージェントＢでは発生した状態変化を示す状態情報をシーケンス番号２４７に対応させて保存し、シーケンス番号２４７を付与して状態情報の通知を行い（ステップＳ２２２）、エージェントＣでは発生した状態変化を示す状態情報をシーケンス番号３７１に対応させて保存し、シーケンス番号３７１を付与して状態情報の通知を行う（ステップＳ２２３）。
マネジャとエージェントとの間では、定期的、例えばｎ秒毎（ｎは、ｎ>０の実数）にシーケンス番号の整合性のチェックが実施される。例えば、マネジャは、管理対象となるネットワーク機器に対して、定期的にシーケンス番号取得コマンドを送信する（ステップＳ２４１、Ｓ２４２、Ｓ２４３）。エージェントは、シーケンス番号取得コマンドを受信すると、該シーケンス番号取得コマンドの応答として、自エージェントの保有するシーケンス番号をマネジャに通知する（ステップＳ２６１、Ｓ２６２、Ｓ２６３）。マネジャは、エージェントから通知されたシーケンス番号を記憶する。
上述したように、各エージェントでは、状態変化が発生すると、該状態変化を示す状態情報を各エージェントが備えるＤＢにシーケンス番号と対応させて保存する。そして、各エージェントでは、シーケンス番号を付与して状態情報を通知する。例えば、エージェントＡでは発生した状態変化を示す状態情報をシーケンス番号１２３に対応させて保存し、シーケンス番号１２３を付与して状態情報の通知を行う。さらに、エージェントＡにおいて状態変化が発生した場合、エージェントＡでは発生した状態変化を示す状態情報をシーケンス番号１２４に対応させて保存し、シーケンス番号１２４を付与して状態情報の通知を行う。しかし、マネジャではそれらのトラップを取りこぼす（ステップＳ２８、Ｓ３０）。
その後、マネジャは、定期的に実施しているシーケンス番号の整合性チェックを行うためシーケンス番号取得コマンドを送信する（ステップＳ３２）。エージェントは、シーケンス番号取得コマンドを受信すると、該シーケンス番号取得コマンドの応答として、自エージェントの保有するシーケンス番号をマネジャに通知する（ステップＳ３４）。
マネジャは、自マネジャが記憶するシーケンス番号が、エージェントにより送信されたシーケンス番号に一致するか否かを判断する。マネジャはトラップを取りこぼしているため、マネジャ−エージェント間でシーケンス番号の不一致が生じる（ステップＳ３６）。
マネジャは、エージェントとの間にシーケンス番号の不一致が生じた場合、エージェントに対し抜けている状態情報を獲得するコマンド（状態送信要求）を発信する。例えば、自マネジャが記憶しているシーケンス番号に対応する状態変化を示す状態情報を獲得するコマンドを発信する（ステップＳ３８）。その際、マネジャは、保持しているシーケンス番号を付与する。ここでは、保持しているシーケンス番号１２２が付与された状態送信要求が、エージェントＡに送信される。
エージェントＡは、状態送信要求を受信すると、通知されたシーケンス番号から自エージェントＡで保持されているシーケンス番号までの状態情報をＤＢから取り出し、シーケンス番号と併せて状態送信要求応答としてマネジャに通知する。この場合、エージェントＡは、シーケンス番号１２２−１２４に対応する状態情報をＤＢから取り出し、マネジャに通知する。
次に、定期的にポーリングを行う方法について、図３を参照して説明する。
図３には、ＳＮＭＰによりネットワークを管理する機器上のマネジャと、管理対象となる各ネットワーク機器に常駐するエージェント（エージェントＡ、エージェントＢ及びエージェントＣ）が示される。
マネジャは、定期的にエージェントの状態確認を行う。例えば、マネジャは、定期的、例えばｎ秒毎（ｎは、ｎ>０の実数）に状態確認コマンドを送信する（ステップＳ３２１、Ｓ３２２、Ｓ３２３）。
各エージェントでは、状態変化が生じた場合、ＤＢへ状態情報を保存する。また、各エージェントでは、状態変化が生じた場合、マネジャからの状態確認コマンドに対する応答を行う（ステップＳ３４２）。状態変化を検出する尺度として、例えばＤＢの差分を量る尺度が使用される。具体的には、シーケンス番号やＤＢのデータ番号などが使用される。
マネジャが高負荷状態となった場合、エージェントにより送信された状態確認コマンドに対する応答を取りこぼす場合が生じる（ステップＳ３６）。この場合。次回の定期的なチェックにおいてエージェントの状態確認を行う際に、エージェントは、マネジャからの状態確認コマンドに対する応答として、ＤＢに保存された状態情報を通知する（ステップＳ３４２）。
特開２００４−８０３９７号公報
しかし、上述した背景技術には以下に示すような問題点がある。
シーケンス番号を付与する方法では、シーケンス番号の不一致をマネジャ側で認識した際、既にエージェント側で状態が変わっていた場合には、該当するシーケンス番号のデータを得ることができない問題がある。
具体的には、図４に示すように、エージェントＡで状態変化が発生し（ステップＳ４１）、シーケンス番号１０２を付与して状態情報の通知を行うが、マネジャ側では、そのトラップを取りこぼす（ステップＳ４２）。
マネジャが状態送信要求を行う前に、エージェントＡの状態が復旧する（ステップＳ４３）。すなわち、エージェントＡの状態が変化する。
マネジャは、定期的に実施しているシーケンス番号の整合性チェックを行うため、シーケンス番号取得コマンドを送信する（ステップＳ４４）。エージェントは、シーケンス番号取得コマンドを受信すると、該シーケンス番号取得コマンドの応答として、自エージェントの保有するシーケンス番号をマネジャに通知する（ステップＳ４５）。
マネジャは、自マネジャが記憶するシーケンス番号が、エージェントにより送信されたシーケンス番号に一致するか否かを判断する。マネジャはトラップを取りこぼしているため、マネジャ−エージェント間でシーケンス番号の不一致が生じる（ステップＳ４６）。
マネジャは、エージェントとの間にシーケンス番号の不一致が生じた場合、エージェントに対し抜けている状態情報を獲得するコマンド（状態送信要求）を発信する。例えば、自マネジャが記憶しているシーケンス番号に対応する状態変化を示す状態情報を獲得するコマンドを発信する（ステップＳ４７）。
エージェントＡは、状態送信要求を受信するが、既に状態が復旧しているため、どのような状態変化が発生していたのか分からない。従って、要求された状態情報を通知できない。
ＤＢにデータを保存する方法については、エージェント単位に全ての状態変化を示す状態情報を保存する大容量のＤＢが必要となる問題がある。容量は、ＤＢの使用方法、保存するデータの件数、保存期間など、データ管理方法によりばらつくためシステム設計時に容量算出を誤ると、状態情報の蓄積処理に負荷が掛かる。
具体的には、図５に示すように、各エージェントでは、状態変化が発生すると、該状態情報を各エージェントが備えるＤＢにシーケンス番号と対応させて保存する。そして、各エージェントでは、シーケンス番号を付与して状態情報を通知する（ステップＳ２２１、Ｓ２２２及びＳ２２３）。例えば、エージェントＡでは発生した状態変化を示す状態情報をシーケンス番号１２２に対応させて保存し、シーケンス番号１２２を付与して状態情報の通知を行い（ステップＳ２２１）、エージェントＢでは発生した状態変化を示す状態情報をシーケンス番号２４７に対応させて保存し、シーケンス番号２４７を付与して状態情報の通知を行い、（ステップＳ２２２）エージェントＣでは発生した状態変化を示す状態情報シーケンス番号３７１に対応させて保存し、シーケンス番号３７１を付与して状態情報の通知を行う（ステップＳ２２３）。このように、エージェント単位に全ての状態変化を示す状態情報を保存する大容量のＤＢが必要であるため、例えば、データの保存を効率よく実施しないと直ぐにＤＢが枯渇する問題がある。また、情報量が多くなった場合に、検索に非常に時間がかかる問題がある。
定期的にポーリングを行う方法については、取りこぼし防止には有効であるが、状態変化を示す状態情報の通知がポーリング周期によるため、リアルタイム性に欠けてしまう問題がある。また、シーケンス番号やＤＢデータ保存と組み合わせて使用されることが多く、これらに付随する問題も抱えてしまう。
具体的には、図６に示すように、マネジャが高負荷状態となる（ステップＳ６１）。エージェントにおいて状態変化が発生し、エージェントは状態情報を送信するが、マネジャはその状態情報を取りこぼす（ステップＳ６２）。マネジャは、次回の定期的なチェックにおいてエージェントの状態確認を行う（ステップＳ６３１、Ｓ６３２、Ｓ６３３）、エージェントは、マネジャからの状態確認コマンドに対する応答として、ＤＢに保存された状態情報を通知する（ステップＳ６４２）。従って、エージェントからの状態データ、例えばトラップを取りこぼすと、定期チェック以外に状態変化を示す状態情報を受信できないため、状態変化を示す状態情報をリアルタイムに把握できないこととなる。
背景技術には以上のような問題点が指摘されており、取りこぼしを解決するには至っていない。
また、マネジャ側でトラップを取りこぼす問題を解決するため、マネジャとエージェントの間のＬＡＮ通信が可能かどうかを監視し、ＬＡＮ通信が不可であることを検出した場合、それ以降、ＬＡＮ通信が可能になるまでに発行したトラップをエージェント内のローカルバッファに退避し、ＬＡＮ通信が可能であることを検出した時に、ローカルバッファに退避しておいたトラップをマネジャに向けて送信するエージェントが開示されている（例えば、特許文献１参照）。
エージェントは、トラップを発信する側であるため、状態変化に応じてリアルタイムにマネジャへデータを通知することは必要である。しかし、マネジャの負荷を考慮せずにトラップを送信してしまっては、トラップの取りこぼし確率を上昇させることになる。
このように、従来システムでは、マネジャの負荷を考慮せず、エージェント側の状態変化のタイミングでトラップ発信を実施していたことから、マネジャ側でのトラップ取りこぼしが発生していたと予想される。従って、現在のシステムを前提として、且つ可能な限り、比較的簡単で低コストで開発／短期間導入でき、その上で確かな効果を発揮できるトラップの送信を行うようにすることが望まれている。
そこで、本発明は、上述した問題点の少なくとも１つを解決するためになされたものであり、その目的は、マネジャの負荷状態に基づいて、マネジャとエージェントとの間で通信を行うことができるシステムにおけるマネジャ、エージェント及びシステム並びに送信制御方法を提供することにある。
本発明の他の目的は、マネジャの負荷状況に基づいて、トラップ取りこぼしを低減できるシステムにおけるマネジャ、エージェント及びシステム並びに送信制御方法を提供することにある。
上記課題を解決するため、本発明のマネジャは、
ネットワークに接続されたエージェントを、ＳＮＭＰにより管理するマネジャであって、
自マネジャが備えるＣＰＵの負荷状態を示すＣＰＵ占有率と、前記エージェントにより送信された、該エージェントが搭載される機器内部の状態変化を通知する状態変化通知コマンドの単位時間あたりの受信数を示す状態変化通知コマンド受信状況と、自マネジャが定期的に実行する処理を実行するまでの時間を示す負荷事象発生時間に基づいて、自マネジャの負荷状態を示すマネジャ負荷情報を生成する負荷情報生成手段と、
前記エージェントに送信するコマンドを生成するコマンド生成手段と
を備え、
前記コマンド生成手段は、前記マネジャ負荷情報を含むコマンドを生成し、
前記エージェントは、前記コマンドに含まれるマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信を制御することを特徴の１つとする。
また、別の構成例では、
前記ＣＰＵ占有率及び前記状態変化通知コマンド受信状況は負荷に応じて複数に分類され、前記負荷事象発生時間は時間に応じて複数に分類され、
前記負荷情報生成手段は、前記分類に基づいて、最も負荷のかかる状態及び最も時間が短い状態のうちの一方をマネジャの負荷情報とするように構成される。
また、別の構成例では、
前記コマンド生成手段は、前記エージェントに送信する全コマンドのヘッダ部に前記マネジャ負荷情報を含めるように構成される。
本発明のエージェントは、
ネットワークに接続され、該ネットワークを介してＳＮＭＰにより、マネジャにより管理されるエージェントであって、
前記マネジャは、自マネジャの負荷状態を示すマネジャ負荷情報を、コマンドに含めて送信し、
前記コマンドに含まれるマネジャ負荷情報を格納する負荷情報格納手段と、
前記負荷情報格納手段に格納されたマネジャ負荷情報に基づいて、自エージェントの状態が変化した場合、その状態変化を通知する状態変化通知コマンドの送信を制御する送信制御手段と
を備えることを特徴の１つとする。
また、別の構成例では、
前記状態変化通知コマンドを格納する状態変化通知コマンド格納手段
を備え、
前記送信制御手段は、前記負荷情報格納手段に格納されたマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信処理及び／又は保存処理を行うように構成される。
本発明のシステムは、
ネットワークに接続されたエージェントと、該エージェントを、ＳＮＭＰにより管理するマネジャとを備えるシステムであって、
前記マネジャは、
自マネジャが備えるＣＰＵの負荷状況を示すＣＰＵ占有率と、前記エージェントにより送信された、該エージェントが搭載される機器内部の状態変化を通知する状態変化通知コマンドの単位時間あたりの受信数を示す状態変化通知コマンド受信状況と、自マネジャが定期的に実行する処理を実行するまでの時間を示す負荷事象発生時間に基づいて、自マネジャの負荷状態を示すマネジャ負荷情報を生成する負荷情報生成手段と、
前記マネジャ負荷情報を含むコマンドを生成し、該コマンドを前記エージェントに送信するコマンド生成手段と
を備え、
前記エージェントは、
前記コマンドに含まれるマネジャ負荷情報を格納する負荷情報格納手段と、
前記負荷情報格納手段に格納されたマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信を制御する送信制御手段と
を備えることを特徴の１つとする。
本発明の送信制御方法は、
ネットワークに接続されたエージェントと、該エージェントを、ＳＮＭＰにより管理するマネジャとを備えるシステムにおける送信制御方法であって、
前記マネジャが、自マネジャが備えるＣＰＵの負荷状況を示すＣＰＵ占有率と、前記エージェントにより送信された、該エージェントが搭載される機器内部の状態変化を通知する状態変化通知コマンドの単位時間あたりの受信数を示す状態変化通知コマンド受信状況と、自マネジャが定期的に実行する処理を実行するまでの時間を示す負荷事象発生時間に基づいて、自マネジャの負荷状態を示すマネジャ負荷情報を生成する負荷情報生成ステップと、
前記マネジャが、前記マネジャ負荷情報を含むコマンドを生成するコマンドを生成するコマンド生成ステップと、
前記マネジャが、生成したコマンドを送信するコマンド送信ステップと、
前記エージェントが、前記コマンドを受信するコマンド受信ステップと、
前記エージェントが、前記コマンドに含まれるマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信を制御する状態変化通知コマンド送信制御ステップと
を有することを特徴の１つとする。
本発明によれば、マネジャの負荷状態に基づいて、マネジャとエージェントとの間で通信を行うことができるシステムにおけるマネジャ、エージェント及びシステム並びに送信制御方法を実現できる。
また、本発明によれば、マネジャの負荷状況に基づいて、トラップ取りこぼしを低減できるシステムにおけるマネジャ、エージェント及びシステム並びに送信制御方法を実現できる。
トラップ受信を取りこぼす問題に対する一改善策を示すフロー図である。 トラップ受信を取りこぼす問題に対する一改善策を示すフロー図である。 トラップ受信を取りこぼす問題に対する一改善策を示すフロー図である。 トラップ受信を取りこぼす問題に対する一改善策の問題点を示すフロー図である。 トラップ受信を取りこぼす問題に対する一改善策の問題点を示すフロー図である。 トラップ受信を取りこぼす問題に対する一改善策の問題点を示すフロー図である。 本発明の一実施例に係るシステムの一例を示すブロック図である。 本発明の一実施例に係るＳＮＭＰマネジャを示す部分ブロック図である。 本発明の一実施例に係るＳＮＭＰマネジャが送信するコマンドの構成を示す説明図である。 本発明の一実施例に係るＳＮＭＰエージェントを示す部分ブロック図である。 本発明の一実施例に係るシステムの動作を示すフロー図である。 本発明の一実施例に係るＳＮＭＰマネジャを示す部分ブロック図である。 本発明の一実施例に係るＳＮＭＰエージェントを示す部分ブロック図である。 本発明の一実施例に係るシステムの動作を示すフロー図である。
符号の説明
１００ ＳＮＭＰマネジャ
１０２ 負荷情報生成部
１０４ コマンド生成部
１０６ 情報取得部
２００（２００１、２００２、２００３、・・・、２００ｎ） ＳＮＭＰエージェント
２０２ コマンド受信部
２０４ 送信制御部
２０６ 負荷情報格納部
２０８ トラップ生成部
２１０ データベース（ＤＢ： ｄａｔａｂａｓｅ）
次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を用い、繰り返しの説明は省略する。
本発明の実施例に係るＳＮＭＰマネジャ及びＳＮＭＰエージェントが適用される機器管理システムの構成例について、図７を参照して説明する。
ＳＮＭＰマネジャは、ＳＮＭＰにより監視を行う機器側に搭載されるソフトウエアモジュールである。また、ＳＮＭＰエージェントはＳＮＭＰにより監視される機器側に搭載されるソフトウエアモジュールであり、ここにＳＮＭＰエージェントが搭載された機器の情報が集められＳＮＭＰプロトコルに翻訳されてＳＮＭＰマネジャに対して送付される。
本実施例に係る機器管理システムは、単一又は複数のネットワーク機器(以下、ＳＮＭＰエージェントと呼ぶ）２００（２００１、２００２、２００３、・・・、２００ｎ；ｎは、ｎ>０の整数）と、管理システム（以下、ＳＮＭＰマネジャと呼ぶ）１００とを備え、ＳＮＭＰマネジャ１００とＳＮＭＰエージェント２００との間がＳＮＭＰにて接続される。ＳＮＭＰとは、ＴＣＰ／ＩＰネットワークにおいて、ルータやコンピュータ、端末などネットワークに接続された通信機器をネットワーク経由で監視・制御するためのプロトコルである。
各ＳＮＭＰエージェント２００は、各ネットワークを介して通信路３００により、ＳＮＭＰマネジャ１００と接続される。ＳＮＭＰエージェント２００は、自ＳＮＭＰエージェントで発生したイベント／エラー情報を基に、その状態変化を通知するコマンド、例えばトラップを生成し、通信路３００を介して、ＳＮＭＰマネジャ１００に送信する。
ＳＮＭＰマネジャ１００は、定期的にＳＮＭＰエージェント２００から情報収集を行う。この情報収集以外に、ＳＮＭＰマネジャ１００は、スケジュール登録機能を有し、定期的な情報収集をＳＮＭＰエージェント２００に対し行う。
ＳＮＭＰエージェント２００は、ＳＮＭＰマネジャ１００からＧＥＴコマンド又はＳＥＴコマンドを受信した場合、応答を返信する。また、ＳＮＭＰエージェント２００は、自ＳＮＭＰエージェントが搭載されるネットワーク機器内部の状態変化を検出した場合、自発的にＳＮＭＰマネジャへ状態変化通知コマンドとしてのコマンド、例えばトラップを発行する。
本実施例に係るＳＮＭＰマネジャ１００について、図８を参照して説明する。
本実施例に係るＳＮＭＰマネジャ１００は、負荷情報生成部１０２と、コマンド生成部１０４と、コマンド受信１０８とエージェント情報格納部１１０を備える。
負荷情報生成部１０２には、「ＣＰＵ占有率」、「トラップ受信状況」及び「負荷事象発生時間」が入力され、入力された「ＣＰＵ占有率」、「トラップ受信状況」及び「負荷事象発生時間」に基づいて、ＳＮＭＰマネジャの負荷を測定し、測定したＳＮＭＰマネジャの負荷を示す負荷情報を生成する。
「ＣＰＵ占有率」とは、プログラムによってCPUがどの程度使用されているかを示す値である。ＣＰＵ占有率が高い場合には、多くのタスクが処理されていることを示し、各タスクの処理に時間がかかるため、プログラムがＳＮＭＰエージェントから受信したトラップを処理するのに時間がかかる。このため、処理最中に受信するトラップを取りこぼす現象が発生する場合がある。ＳＮＭＰマネジャ１００上で動作しているプログラムの動作状況によりＣＰＵ占有率の値は高低する。
「トラップ受信状況」とは、ＳＮＭＰエージェントが発信するトラップをＳＮＭＰマネジャが単位秒当たりに受信する量（数）である。ＳＮＭＰエージェント側にて状態変化などが頻発すると、ＳＮＭＰマネジャは複数回トラップを受信する。単一のＳＮＭＰエージェントからの通知であれば問題となることは少ないが、複数のＳＮＭＰエージェントから複数回トラップを受信すると単位秒当たりのトラップ受信量が多くなるため、トラップを取りこぼす現象が発生する場合がある。この値は、「ＣＰＵ占有率」に影響を与え、単位秒当たりの「トラップ受信状況」が高くなるほど、「ＣＰＵ占有率」も高くなる傾向にある。
「負荷事象発生時間」とは、定期的に実行する処理が、何秒後に実行されるかを示す値である。ネットワーク内では、定期的に装置の稼働状況のチェックやＤＢの整合処理などが実施される。これらの処理は、ネットワーク全体が高負荷状態となるため大抵スケジュール管理され、他のプログラムがあまり動作しない時間帯に実行される。この処理中、不慮の状態変化があった場合には、トラップ取りこぼしが発生する確率が高くなる。
負荷情報生成部１０２は、入力された「ＣＰＵ占有率」、「トラップ受信状況」及び「負荷事象発生時間」の各パラメータを負荷情報に置き換える。例えば、負荷情報生成部１０２は、表１を参照し、各パラメータを負荷情報に置き換える。表１には、「ＣＰＵ占有率」、「トラップ受信状況」及び「負荷事象発生時間」の各パラメータについて、その負荷の値、すなわち各パラメータの値に応じて分類される複数の負荷情報を示す。
Figure 2008149455
 具体的には、「ＣＰＵ占有率」については、負荷に応じて、ＣＰＵ占有率が「８１％〜１００％」は負荷情報「激高」に分類され、「６１％〜８０％」は負荷情報「高」に分類され、「４１％〜６０％」は負荷情報「中」に分類され、「２１％〜４０％」は負荷情報「低」に分類され、「２０％以下」は負荷情報「問題なし」に分類される。
同様に、「トラップ受信状況」については、負荷に応じて、トラップ受信状況が「２０トラップ／ｓｅｃ以上」は負荷情報「激高」に分類され、「１６トラップ／ｓｅｃ〜１９トラップ／ｓｅｃ」は負荷情報「高」に分類され、「１２トラップ／ｓｅｃ〜１５トラップ／ｓｅｃ」は負荷情報「中」に分類され、「８トラップ／ｓｅｃ〜１１トラップ／ｓｅｃ」は負荷情報「低」に分類され、「７トラップ／ｓｅｃ以下」は負荷情報「問題なし」に分類される。
同様に、「負荷事象発生時間」については、時間に応じて、負荷事象発生時間が「６０ｓｅｃ以内に有り」は負荷情報「激高」に分類され、「６１ｓｅｃ〜１２０ｓｅｃに有り」は負荷情報「高」に分類され、「１２１ｓｅｃ〜１８０ｓｅｃに有り」は負荷情報「中」に分類され、「１８１ｓｅｃ〜２４０ｓｅｃに有り」は負荷情報「低」に分類され、「２４１ｓｅｃ以上無し」は負荷情報「問題なし」に分類される。表１に示した分類、またその分類における数値は一例であり、適宜変更可能である。表１に示すようなテーブルを用いて各パラメータの値を分類し負荷の測定を行うことにより、処理を高速化できる。
負荷情報生成部１０２は、各パラメータの値を負荷情報に置き換え、さらに、置き換えた負荷情報から、マネジャの負荷情報を生成する。具体的には、負荷情報生成部１０２は、各パラメータを置き換えることにより取得した負荷情報から、最も負荷のかかっている状態を示す負荷情報を、マネジャの負荷情報としてコマンド生成部１０４に入力する。
例えば、各パラメータの値として、「ＣＰＵ占有率」が２３％、「トラップ受信状況」が５トラップ／ｓｅｃ、「負荷事象発生時間」が２８９ｓｅｃ以内、が入力された場合、負荷情報生成部１０２は、各パラメータにおける負荷情報として、「ＣＰＵ占有率」を負荷情報「低」に置き換え、「トラップ受信状況」を負荷情報「問題なし」に置き換え、「負荷事象発生時間」を負荷情報「問題なし」に置き換える。さらに、負荷情報生成部１０２は、各パラメータを置き換えることにより取得した負荷情報「低」、「問題なし」及び「問題無し」から、最も負荷のかかっている状態を示す負荷情報「低」を、マネジャの負荷情報としてコマンド生成部１０４に入力する。
また、例えば、各パラメータの値として、「ＣＰＵ占有率」が５８％、「トラップ受信状況」が１７トラップ／ｓｅｃ、「負荷事象発生時間」が１９０ｓｅｃ以内、が入力された場合、負荷情報生成部１０２は、各パラメータにおける負荷情報として、「ＣＰＵ占有率」を負荷情報「中」に置き換え、「トラップ受信状況」を負荷情報「高」に置き換え、「負荷事象発生時間」を負荷情報「低」に置き換える。さらに、負荷情報生成部１０２は、各パラメータを置き換えることにより取得した負荷情報「中」、「高」及び「低」から、最も負荷のかかっている状態を示す負荷情報「高」を、マネジャの負荷情報としてコマンド生成部１０４に入力する。
また、例えば、各パラメータの値として「ＣＰＵ占有率」が３３％、「トラップ受信状況」が１１トラップ／ｓｅｃ、「負荷事象発生時間」が４４ｓｅｃ以内、が入力された場合、負荷情報生成部１０２は、各パラメータにおける負荷情報として、「ＣＰＵ占有率」を負荷情報「低」に置き換え、「トラップ受信状況」を負荷情報「低」に置き換え、「負荷事象発生時間」を負荷情報「激高」に置き換える。さらに、負荷情報生成部１０２は、各パラメータを置き換えることにより取得した負荷情報「低」、「低」及び「激高」から、最も負荷のかかっている状態を示す負荷情報「激高」を、マネジャの負荷情報としてコマンド生成部１０４に入力する。
コマンド生成部１０４は、入力されたマネジャの負荷情報を含むコマンド（ＰＤＵ： Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）を生成する。例えば、コマンド生成部１０４は、入力されたマネジャの負荷情報を、自ＳＮＭＰマネジャが発行するコマンドのヘッダ部、例えばＵＤＰヘッダに含めて送信する。従って、本実施例に係るＳＮＭＰマネジャ１００が発行するコマンドのヘッダには、図９に示すように、アドレス情報、例えば送信元のポート番号及び宛先のポート番号と、コマンドコードと、データ情報量、例えばＵＤＰデータ長と、負荷情報とが含まれる。ここで、コマンドコードは、プロトコル データ ユニット（ＰＤＵ）データフォーマットに含まれるようにしてもよい。例えば、コマンド生成部１０４は、ＳＮＭＰエージェントが保有する監視情報の収集コマンドと、ＳＮＭＰエージェントに対する制御コマンドと、装置のヘルスチェックコマンドとをＳＮＭＰエージェントに向けて発行する。すなわち、コマンド生成部１０４は、マネジャの負荷情報を、自ＳＮＭＰマネジャ１００が発行する全コマンドに含め、ＳＮＭＰエージェントに通知する。
コマンド受信部１０８は、ＳＮＭＰマネジャが発行するコマンドに対するＳＮＭＰエージェントの応答やＳＮＭＰエージェントが発信するトラップを受信する。受信したＳＮＭＰエージェントの応答やトラップにシーケンス番号や状態データなどの情報が含まれている場合、エージェント情報としてエージェント情報格納部１１０に入力する。
エージェント情報格納部１１０は、ＳＮＭＰマネジャが管理するＳＮＭＰエージェントのシーケンス番号や状態データを格納する。
ＳＮＭＰエージェントが保有する監視情報の収集コマンドは、上述したシーケンス番号を取得するためのシーケンス番号取得コマンドや定期ポーリング処理のためのコマンドである。このＳＮＭＰエージェントが保有する監視情報の収集コマンドは、手動操作により発行されたり、ある所定の間隔で定期的に発行されたりするコマンドである。
ＳＮＭＰエージェントに対する制御コマンドは、ネットワークの運用に関わる制御や何らかの試験を実施するための制御コマンドである。ＳＮＭＰエージェントに対する制御コマンドは、常時使用されるわけではないが、保守時に使用頻度が高くなる。
装置のヘルスチェックコマンドは、ネットワーク内に存在する全てのＳＮＭＰエージェントを対象に、ＳＮＭＰエージェントが動作しているか否かを確認するためのコマンドである。装置のヘルスチェックコマンドは、ＳＮＭＰエージェントが保有する監視情報の収集コマンドと異なり、発行間隔の短いコマンドである。
上述したようにＳＮＭＰマネジャ１００が発行するコマンドには、保守や定期情報収集などＳＮＭＰエージェント側に負荷がかかる直前に発行されるコマンド、具体的にはＳＮＭＰエージェントが保有する監視情報の収集コマンドやＳＮＭＰエージェントに対する制御コマンドと、極短い間隔で発行されているコマンド、具体的には装置のヘルスチェックコマンドがある。
これらのコマンドにマネジャの負荷情報を含めて送信することにより、ＳＮＭＰエージェントに対して常に最新の負荷情報を通知することが可能である。ＳＮＭＰエージェント２００は、ＳＮＭＰマネジャ１００の負荷状況を常時認識できる。ＳＮＭＰエージェント２００は、ＳＮＭＰマネジャ１００により送信されたコマンドに含まれるマネジャの負荷情報に応じて、トラップの発行を制御する。例えば、コマンドを受信したＳＮＭＰエージェント２００は、該コマンドのヘッダに含まれるマネジャの負荷情報を取り出し、内部に格納する。ＳＮＭＰエージェント２００は、コマンドを受信した場合に、毎回この格納処理を実行し、格納されているマネジャの負荷情報を更新する。このようにすることにより、ＳＮＭＰエージェント２００は、常に最新のマネジャの負荷情報を認識することが可能となる。
本実施例に係るＳＮＭＰエージェント２００について、図１０を参照して説明する。
本実施例に係るＳＮＭＰエージェント２００は、コマンド受信部２０２と、送信制御部２０４と、負荷情報格納部２０６と、トラップ生成部２０８とを備える。
コマンド受信部２０２は、ＳＮＭＰマネジャ１００から送信されたコマンドの受信処理を行い、受信したコマンドを送信制御部２０４に入力する。
送信制御部２０４は、入力されたコマンドのヘッダ部に含まれるマネジャの負荷情報を取り出し、負荷情報格納部２０６に入力する。
負荷情報格納部２０６は、入力されたマネジャの負荷情報を格納する。
トラップ生成部２０８は、自ＳＮＭＰエージェントの状態が変化した場合に、その状態変化を通知する状態変化通知コマンドとしてのコマンド、例えばトラップを生成し、送信制御部２０４に入力する。
送信制御部２０４は、トラップ生成部２０８からトラップが入力された場合、負荷情報格納部２０６に格納された負荷情報に基づいて、該トラップを送信する。例えば、負荷情報格納部２０６に格納された負荷情報が「低」及び「問題無し」である場合にトラップを送信する。すなわち、負荷情報格納部２０６に格納された負荷情報が「中」、「高」及び「激高」である場合には、トラップの送信を行わない。
次に、本実施例に係る機器管理システムの動作について、図１１を参照して説明する。
本実施例では、ＳＮＭＰマネジャ１００により管理されるＳＮＭＰエージェントが３台（エージェントＡ、Ｂ及びＣ）の場合について説明するが、ＳＮＭＰエージェントが２台の場合及び４台以上の場合においても適用できる。また、本実施例では、ＳＮＭＰマネジャ１００が、定期的に監視情報の収集コマンド、制御コマンド及びヘルスチェックコマンドを、ＳＮＭＰエージェント２００に送信する場合について説明するが、不定期に送信する場合にも適用できる。
ＳＮＭＰマネジャ１００は、負荷情報生成部１０２において、「ＣＰＵ占有率」、「トラップ受信状況」及び「負荷事象発生時間」に基づいて、マネジャの負荷情報を生成する（ステップＳ１１０２）。例えば、マネジャの負荷情報「低」を生成する。
ＳＮＭＰマネジャ１００は、コマンド生成部１０４において、コマンドを生成し、そのヘッダにマネジャの負荷情報「低」を含めて送信する（ステップＳ１１０４１、Ｓ１１０４２、Ｓ１１０４３）例えば、コマンド生成部１０４は、そのヘッダにマネジャの負荷情報「低」を含む監視情報の収集コマンドを生成し、エージェントＡ、Ｂ及びＣに送信する。
各エージェントＡ、Ｂ及びＣでは、保有する監視情報をＳＮＭＰマネジャ１００に送信する（ステップＳ１１０６１、Ｓ１１０６２、Ｓ１１０６３）。また、送信制御部２０４は、監視情報収集コマンドのヘッダに含まれるマネジャの負荷情報を負荷情報格納部２０６に格納する（ステップＳ１１０８１、Ｓ１１０８２、Ｓ１１０８３）。
各エージェントのトラップ生成部２０８は、自エージェントの状態が変化した場合に、トラップを生成し、送信制御部２０４に入力する。送信制御部２０４は、トラップ生成部２０８からトラップが入力された場合、負荷情報格納部２０６に格納されたマネジャの負荷情報に基づいて、負荷情報格納部２０６に格納されたマネジャの負荷情報が「低」であるので、該トラップを送信する（ステップＳ１１１０）。
ＳＮＭＰマネジャ１００は、ＳＮＭＰエージェントＡ、Ｂ及びＣから送信されたトラップを受信する。その結果、ＣＰＵ占有率及びトラップ受信状況が上昇する。
ＳＮＭＰマネジャ１００は、負荷情報生成部１０２において、「ＣＰＵ占有率」、「トラップ受信状況」及び「負荷事象発生時間」に基づいて、マネジャの負荷情報を生成する（ステップＳ１１１２）。この状況では、ＣＰＵ占有率及びトラップ受信状況が上昇しているため、マネジャの負荷情報は「高」となる。
ＳＮＭＰマネジャ１００は、コマンド生成部１０４において、コマンドを生成し、そのヘッダに負荷情報「高」を含めて送信する（ステップＳ１１１４１、Ｓ１１１４２、Ｓ１１１４３）例えば、コマンド生成部１０４は、そのヘッダに負荷情報「高」を含む制御コマンドを生成し、エージェントＡ、Ｂ及びＣに送信する。
各ＳＮＭＰエージェントＡ、Ｂ及びＣでは、受信した制御コマンドに対する応答をＳＮＭＰマネジャ１００に送信する（ステップＳ１１１６１、Ｓ１１１６２、Ｓ１１１６３）。また、送信制御部２０４は、制御コマンドのヘッダに含まれる負荷情報を負荷情報格納部２０６に格納する（ステップＳ１１１８１、Ｓ１１１８２、Ｓ１１１８３）。その結果、マネジャの負荷情報が「高」に更新される。
各ＳＮＭＰエージェントのトラップ生成部２０８は、自エージェントの状態が変化した場合に、トラップを生成し、送信制御部２０４に入力する。送信制御部２０４は、トラップ生成部２０８からトラップが入力された場合、負荷情報格納部２０６に格納された負荷情報に基づいて、負荷情報格納部２０６に格納された負荷情報が「高」であるので、該トラップを送信しない。各ＳＮＭＰエージェントは、例えば、負荷情報が「低」又は「問題なし」など、ＳＮＭＰマネジャにおいて、トラップが受信される確率高いと判断される場合に、トラップを送信する。
しばらくの時間経過後、負荷が低い状態となる。
ＳＮＭＰマネジャ１００は、負荷情報生成部１０２において、「ＣＰＵ占有率」、「トラップ受信状況」及び「負荷事象発生時間」に基づいて、マネジャの負荷情報を生成する（ステップＳ１１２０）。例えば、負荷情報生成部１０２には、「負荷事象発生時間」として、高負荷となる情報収集コマンドの発行が１分後に迫っている情報が入力される。この場合、マネジャの負荷情報は「激高」となる。
ＳＮＭＰマネジャ１００は、コマンド生成部１０４において、コマンドを生成し、そのヘッダに負荷情報「激高」を含めて送信する（ステップＳ１１２２１、Ｓ１１２２２、Ｓ１１２２３）例えば、コマンド生成部１０４は、そのヘッダに負荷情報「激高」を含むヘルスチェックコマンドを生成し、エージェントＡ、Ｂ及びＣに送信する。
各エージェントＡ、Ｂ及びＣでは、受信したヘルスチェックコマンドに対する応答をＳＮＭＰマネジャ１００に送信する（ステップＳ１１２４１、Ｓ１１２４２、Ｓ１１２４３）。また、送信制御部２０４は、ヘルスチェックコマンドのヘッダに含まれるマネジャの負荷情報「激高」を負荷情報格納部２０６に格納する（ステップＳ１１２６１、Ｓ１１２６２、Ｓ１１２６３）。その結果、マネジャの負荷情報が「激高」に更新される。
各ＳＮＭＰエージェントのトラップ生成部２０８は、自エージェントの状態が変化した場合に、トラップを生成し、送信制御部２０４に入力する。送信制御部２０４は、トラップ生成部２０８からトラップが入力された場合、負荷情報格納部２０６に格納された負荷情報に基づいて、負荷情報格納部２０６に格納された負荷情報が「激高」であるので、該トラップを送信しない。各ＳＮＭＰエージェントは、例えば、負荷情報が「低」又は「問題なし」など、ＳＮＭＰマネジャにおいて、トラップが受信される確率高いと判断される場合に、トラップを送信する。
本実施例によれば、ＳＮＭＰマネジャの負荷情報をＳＮＭＰエージェントに通知することにより、ＳＮＭＰエージェントは、ＳＮＭＰマネジャの負荷情報に基づいてトラップ発信処理を制御することができる。このため、ＳＮＭＰマネジャにおけるトラップの取りこぼしを低減することができる。
次に、本発明の他の実施例に係る機器管理システムについて説明する。
本実施例に係る機器管理システムでは、ＳＮＭＰエージェントは、通知されたマネジャの負荷情報を用いて、トラップ発行を制御する。さらに、ＳＮＭＰエージェントは、ＳＮＭＰマネジャの負荷状況に応じて、後述する動作決定テーブルを参照し、トラップの送信遅延処理及び／又はDB保存処理を実行する。DB保存処理が選択された場合、ＳＮＭＰマネジャ１００における負荷低減後にＳＮＭＰマネジャがＳＮＭＰエージェントに対し、DB内参照コマンドを発行し、DB内の状態情報を取得する。このようにすることで、ＳＮＭＰマネジャ１００は、状態情報の補間を図ることができる。ＳＮＭＰマネジャにおける状態情報取得後に、ＳＮＭＰエージェントは、内部のＤＢに格納されている状態情報を全削除する。このようにすることにより、ＳＮＭＰエージェントの備えるＤＢの枯渇を低減できる。
本実施例に係る機器管理システムの構成は、図７を参照して説明した構成と同様である。
本実施例に係るＳＮＭＰマネジャの構成について、図１２を参照して説明する。本実施例に係るＳＮＭＰマネジャ１００は、図８を参照して説明したＳＮＭＰマネジャの構成において、負荷情報生成部１０２と接続された情報取得部１０６を備える。
情報取得部１０６は、負荷情報生成部１０２から入力されたマネジャの負荷情報に基づいて、そのマネジャの負荷情報が「低」又は「問題なし」である場合に、抜けているトラップの補完を行う。具体的には、マネジャの負荷情報が「激高」、「高」又は「中」から、「低」又は「問題なし」に変化した場合に、ＳＮＭＰエージェント２００から送信され、ＳＮＭＰマネジャ１００において取りこぼしされ、抜けているトラップの補完を行う。例えば、情報取得部１０６は、ＤＢ内の状態情報を要求するためのＤＢ内状態送信要求コマンドをＳＮＭＰエージェントに送信する。ＳＮＭＰマネジャ１００では、トラップの抜けや漏れを検出できない。このため、ＳＮＭＰエージェント２００に格納されている状態情報を取得するＤＢ内状態送信要求コマンドを発行する。このＤＢ内状態送信要求コマンドには、ＳＮＭＰマネジャ１００に記憶されているシーケンス番号が付与される。このようにすることにより、ＳＮＭＰマネジャ１００は、付与したシーケンス番号以降に状態変化があったか否かをＳＮＭＰエージェント２００に問い合わせることができる。
本実施例に係るＳＮＭＰエージェントの構成について、図１３を参照して説明する。本実施例に係るＳＮＭＰエージェントは、図１０を参照して説明したＳＮＭＰエージェントに、送信制御部２０４と接続された状態変化通知コマンド格納手段としてのデータベース（ＤＢ： database）２１０を備える。
送信制御部２０４は、トラップを発行する契機を迎えた場合に、負荷情報格納部２０６に格納された負荷情報に基づいて、トラップ発行処理及び／又はＤＢへのトラップ保存処理の実行を行う。例えば、送信制御部２０４は、表２に示すマネジャの負荷情報に対するＳＮＭＰエージェント側動作を示すテーブルを参照し、マネジャの負荷情報が「激高」である場合には、トラップ送信を停止しトラップをＤＢ２１０に保存し、負荷情報が「高」である場合には、トラップ送信を間欠的、例えば数ｍｓ間隔で送信し、トラップをＤＢ２１０に保存し、負荷情報が「中」である場合には、トラップを送信するとともにトラップをＤＢ２１０に保存し、負荷情報が「低」である場合には、トラップを送信するとともにトラップをＤＢ２１０に保存しない、負荷情報が「問題なし」である場合には、トラップを送信しトラップをＤＢ２１０に保存しない。
Figure 2008149455
 すなわち、マネジャの負荷情報が「問題なし」及び「低」である場合、問題は発生しないと想定されるため、施策を施すことなくトラップの送信を実施する。この場合、ＤＢ２１０へのデータ（トラップ）保存処理も実施しない。マネジャの負荷情報が「中」である場合、状況により、トラップ受信の取りこぼしが発生する可能性がある。そのため、トラップ送信は通常通り実施するが、ＤＢ２１０へのデータ保存処理を実施する。マネジャ負荷情報が「高」である場合、トラップ受信の取りこぼしが生じる確率は、負荷情報が「中」である場合より高いため、ＤＢ２１０へのデータ保存処理の実施とともに、トラップを間欠的に送信、すなわち、トラップの配信量を制御する。例えばトラップの発信間隔を通常時より数ms程空ける。このようにすることにより、ＳＮＭＰマネジャがトラップを受信できるようにする。マネジャの負荷情報が「激高」である場合、取りこぼしが発生する確率が高いため、トラップ発行自体を停止させ、ＤＢ２１０へのデータ保存処理を実施する。
また、送信制御部２０４は、ＳＮＭＰマネジャ１００からＤＢ内状態送信要求コマンドを受信した場合、通知されたシーケンス番号以降に発生している状態変化を示す状態情報をＳＮＭＰマネジャ１００に通知する。そして、通知した状態変化を示す状態情報をＤＢ２１０から削除する。このようにすることにより、ＳＮＭＰマネジャ１００では抜けている情報の補完が可能となり、ＳＮＭＰエージェント２００ではＤＢの容量を削減できるとともに、ＤＢの枯渇を低減できる。
次に、本実施例に係る機器管理システムの動作について、図１４を参照して説明する。
本実施例では、ＳＮＭＰマネジャ１００により管理されるＳＮＭＰエージェントが３台（エージェントＡ、Ｂ及びＣ）の場合について説明するが、ＳＮＭＰエージェントが２台の場合及び４台以上の場合においても適用できる。
ＳＮＭＰマネジャ１００における負荷状況が「低」から「高」に変化する。
負荷情報生成部１０２は、負荷情報を生成する（ステップＳ１４０２）。例えば、負荷情報生成部１０２は、負荷情報「高」を生成する。
ＳＮＭＰマネジャ１００からコマンドが送信される前に、ＳＮＭＰエージェントＡ、Ｂ及びＣのトラップ生成部２０８は、自エージェントの状態が変化したので、トラップを生成し、送信制御部２０４に入力する。送信制御部２０４は、トラップ生成部２０８からトラップが入力された場合、負荷情報格納部２０６に格納された負荷情報に基づいて、負荷情報格納部２０６に格納された負荷情報が「低」であるので、該トラップを送信する（ステップＳ１４０４）。その結果、ＳＮＭＰマネジャ１００は、連続的にトラップを受信するため、負荷がさらに上昇する。
さらに、ＳＮＭＰエージェントＡ、Ｂ及びＣによりトラップが送信される（ステップＳ１４０６）。その結果、ＳＮＭＰマネジャ１００では、トラップの取りこぼしが発生する（ステップＳ１４０８）。
しばらくの時間が経過後、ＳＮＭＰマネジャ１００における負荷状況が「高」から「低」に変化する。負荷情報生成部１０２は、マネジャの負荷情報を生成する（ステップＳ１４１０）。例えば、負荷情報生成部１０２は、負荷情報「低」を生成する。
情報取得部１０６は、負荷情報生成部１０２において生成された負荷情報が「低」に移行したので、ＳＮＭＰエージェントＡ、Ｂ及びＣに対して、ＤＢ内状態送信要求を送信する（ステップＳ１４１２１、Ｓ１４１２２、Ｓ１４１２３）。各ＤＢ内状態送信要求には、各エージェントに対するシーケンス番号が含まれる。
ＳＮＭＰエージェントＡ、Ｂ及びＣは、ＳＮＭＰマネジャ１００からＤＢ内状態送信要求を受信すると、該ＤＢ内状態送信要求に含まれるシーケンス番号に基づいて、該シーケンス番号以降の状態データを送信する（ステップＳ１４１４１、Ｓ１４１４２、Ｓ１４１４３）。その後、各ＳＮＭＰエージェントＡ、Ｂ及びＣの送信制御部２０４は、送信した状態データを、ＤＢ２１０から削除する（ステップＳ１４１６１、Ｓ１４１６２、Ｓ１４１６３）。
本実施例によれば、ＳＮＭＰマネジャ１００の負荷情報に基づいて、ＳＮＭＰエージェント２００は、トラップの送信処理及び／又はトラップの保存処理を行うことができる。
これまでは、ＳＮＭＰエージェント側におけるトラップの発行処理の制御は行われていない。すなわち、ＳＮＭＰエージェント側では、常にトラップを保存する処理、また、ＳＮＭＰマネジャからのシーケンス番号による問い合わせに応じて該当するトラップを送信する処理が行われている。
本実施例では、ＤＢに保存する処理が行われるが、全てを保存するとＤＢの枯渇、すなわち容量が足りない場合が生じるので、ある一定の期間だけ保存する。具体的には、マネジャの負荷情報が「低」又は「問題なし」の場合に、ＳＮＭＰマネジャ１００からＳＮＭＰエージェント２００に対してシーケンス番号を含むＤＢ情報送信要求コマンドを発行する。このコマンドにより、シーケンス番号以降に生じた状態の変化を問い合わせることができる。ＳＮＭＰエージェント２００では、ＤＢ情報送信要求コマンドに含まれるシーケンス番号以降の状態情報を送信した後に、該送信した状態情報をＤＢから削除する。このようにすることにより、ＳＮＭＰエージェント２００に備えるＤＢの容量を低減できる。また、ＳＮＭＰマネジャ側では、状態情報の補完を行うことができ、取りこぼしの無いＳＮＭＰ通信を確立できる。
上述した実施例における改善効果を示す。
一例として、ＳＮＭＰマネジャにおいて同様の負荷状態が６００ｓｅｃの間継続した場合におけるトラップ取りこぼし量の変化を示す。
ＳＮＭＰエージェントからのトラップによる輻輳を契機に負荷状態が発生した場合について、表３に示す。
Figure 2008149455
 同様の負荷状態が６００ｓｅｃ継続するので、各負荷状態において負荷がかかればかかるほど、言い換えれば、トラップ量が増加すればするほど、従来法ではトラップ取りこぼし量が増加する。一方、本手法を導入した場合、負荷状態発生直後のトラップのみ取りこぼす可能性があるが、それ以外はトラップの取りこぼしは発生しない。表３において、「＊１」は、負荷状態発生直後のトラップのみ取りこぼす可能性があることを示す。
次に、スケジュール登録された情報収集を契機として負荷状態が発生する場合について、表４に示す。
Figure 2008149455
 ＳＮＭＰマネジャは情報収集コマンドを送信し、その応答量を予測できる。しかし、従来法では、応答の処理については分かっていないため、上述したＳＮＭＰエージェントからのトラップによる輻輳を契機に負荷状態が発生した場合と同様にトラップの取りこぼしが発生する。一方、本手法を導入した場合、間欠的に送信したり、送信を停止したりするなどの処理を行うことができるため、トラップの取りこぼしは発生しない。
つぎに、ＳＮＭＰマネジャが１秒間に受信するトラップ量と、負荷低減後に補完が必要となる最大情報量との関係について、表５に示す。表５には、１トラップが５０バイトとした場合を示す。
Figure 2008149455
 本手法を導入した場合、「激高」である負荷状態が１日継続し、その後負荷が低減した場合でも、８６．４Ｍｂｙｔｅの情報補完によりトラップの取りこぼしを防止することができることが分かる。

Claims (7)

  1. ネットワークに接続されたエージェントを、ＳＮＭＰにより管理するマネジャであって、
    自マネジャが備えるＣＰＵの負荷状態を示すＣＰＵ占有率と、前記エージェントにより送信された、該エージェントが搭載される機器内部の状態変化を通知する状態変化通知コマンドの単位時間あたりの受信数を示す状態変化通知コマンド受信状況と、自マネジャが定期的に実行する処理を実行するまでの時間を示す負荷事象発生時間に基づいて、自マネジャの負荷状態を示すマネジャ負荷情報を生成する負荷情報生成手段と、
    前記エージェントに送信するコマンドを生成するコマンド生成手段と
    を備え、
    前記コマンド生成手段は、前記マネジャ負荷情報を含むコマンドを生成し、
    前記エージェントは、前記コマンドに含まれるマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信を制御することを特徴とするマネジャ。
  2. 請求項１に記載のマネジャにおいて、
    前記ＣＰＵ占有率及び前記状態変化通知コマンド受信状況は負荷に応じて複数に分類され、前記負荷事象発生時間は時間に応じて複数に分類され、
    前記負荷情報生成手段は、前記分類に基づいて、最も負荷のかかる状態及び最も時間が短い状態のうちの一方をマネジャの負荷情報とすることを特徴とするマネジャ。
  3. 請求項１又は２に記載のマネジャにおいて、
    前記コマンド生成手段は、前記エージェントに送信する全コマンドのヘッダ部に前記マネジャ負荷情報を含めることを特徴とするマネジャ。
  4. ネットワークに接続され、該ネットワークを介してＳＮＭＰにより、マネジャにより管理されるエージェントであって、
    前記マネジャは、自マネジャの負荷状態を示すマネジャ負荷情報を、コマンドに含めて送信し、
    前記コマンドに含まれるマネジャ負荷情報を格納する負荷情報格納手段と、
    前記負荷情報格納手段に格納されたマネジャ負荷情報に基づいて、自エージェントの状態が変化した場合、その状態変化を通知する状態変化通知コマンドの送信を制御する送信制御手段と
    を備えることを特徴とするエージェント。
  5. 請求項４に記載のエージェントにおいて、
    前記状態変化通知コマンドを格納する状態変化通知コマンド格納手段
    を備え、
    前記送信制御手段は、前記負荷情報格納手段に格納されたマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信処理及び／又は保存処理を行うことを特徴とするエージェント。
  6. ネットワークに接続されたエージェントと、該エージェントを、ＳＮＭＰにより管理するマネジャとを備えるシステムであって、
    前記マネジャは、
    自マネジャが備えるＣＰＵの負荷状況を示すＣＰＵ占有率と、前記エージェントにより送信された、該エージェントが搭載される機器内部の状態変化を通知する状態変化通知コマンドの単位時間あたりの受信数を示す状態変化通知コマンド受信状況と、自マネジャが定期的に実行する処理を実行するまでの時間を示す負荷事象発生時間に基づいて、自マネジャの負荷状態を示すマネジャ負荷情報を生成する負荷情報生成手段と、
    前記マネジャ負荷情報を含むコマンドを生成し、該コマンドを前記エージェントに送信するコマンド生成手段と
    を備え、
    前記エージェントは、
    前記コマンドに含まれるマネジャ負荷情報を格納する負荷情報格納手段と、
    前記負荷情報格納手段に格納されたマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信を制御する送信制御手段と
    を備えることを特徴とするシステム。
  7. ネットワークに接続されたエージェントと、該エージェントを、ＳＮＭＰにより管理するマネジャとを備えるシステムにおける送信制御方法であって、
    前記マネジャが、自マネジャが備えるＣＰＵの負荷状況を示すＣＰＵ占有率と、前記エージェントにより送信された、該エージェントが搭載される機器内部の状態変化を通知する状態変化通知コマンドの単位時間あたりの受信数を示す状態変化通知コマンド受信状況と、自マネジャが定期的に実行する処理を実行するまでの時間を示す負荷事象発生時間に基づいて、自マネジャの負荷状態を示すマネジャ負荷情報を生成する負荷情報生成ステップと、
    前記マネジャが、前記マネジャ負荷情報を含むコマンドを生成するコマンドを生成するコマンド生成ステップと、
    前記マネジャが、生成したコマンドを送信するコマンド送信ステップと、
    前記エージェントが、前記コマンドを受信するコマンド受信ステップと、
    前記エージェントが、前記コマンドに含まれるマネジャ負荷情報に基づいて、前記状態変化通知コマンドの送信を制御する状態変化通知コマンド送信制御ステップと
    を有することを特徴とする送信制御方法。
JP2009517671A 2007-06-08 2007-06-08 マネジャ、エージェント及びシステム並びに送信制御方法 Expired - Fee Related JP4978693B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2007/061617 WO2008149455A1 (ja) 2007-06-08 2007-06-08 マネジャ、エージェント及びシステム並びに送信制御方法

Publications (2)

Publication Number Publication Date
JPWO2008149455A1 true JPWO2008149455A1 (ja) 2010-08-19
JP4978693B2 JP4978693B2 (ja) 2012-07-18

Family

ID=40093290

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009517671A Expired - Fee Related JP4978693B2 (ja) 2007-06-08 2007-06-08 マネジャ、エージェント及びシステム並びに送信制御方法

Country Status (3)

Country Link
US (1) US7996528B2 (ja)
JP (1) JP4978693B2 (ja)
WO (1) WO2008149455A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5229007B2 (ja) * 2009-03-06 2013-07-03 日本電気株式会社 監視システム、ネットワーク機器、監視情報提供方法およびプログラム
WO2011007399A1 (ja) * 2009-07-17 2011-01-20 富士通テレコムネットワークス株式会社 Ｓｎｍｐエージェント装置およびｓｎｍｐエージェント制御方法
JP2012257039A (ja) * 2011-06-08 2012-12-27 Nec Corp 管理装置、通信システムおよび通信方法
JP5754283B2 (ja) * 2011-07-25 2015-07-29 富士通株式会社 ネットワーク監視制御装置及び管理情報取得方法
JP6418377B2 (ja) * 2014-06-06 2018-11-07 日本電気株式会社 管理対象装置、管理装置及びネットワーク管理システム
JP6760895B2 (ja) * 2017-07-12 2020-09-23 日本電信電話株式会社 ネットワーク計測システム、および、ネットワーク計測方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004328726A (ja) * 2003-04-11 2004-11-18 Alcatel ネットワークマネジャｓｎｍｐトラップ抑制
JP2005293048A (ja) * 2004-03-31 2005-10-20 Fujitsu Ltd 資源計画作成プログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6711613B1 (en) * 1996-07-23 2004-03-23 Server Technology, Inc. Remote power control system
US6604136B1 (en) * 1998-06-27 2003-08-05 Intel Corporation Application programming interfaces and methods enabling a host to interface with a network processor
JP2002344510A (ja) * 2001-05-15 2002-11-29 Nec Commun Syst Ltd ネットワーク管理システムと装置及び方法並びにプログラム
JP2004080397A (ja) 2002-08-19 2004-03-11 Nec Corp Ｌａｎ監視機能を備えたｓｎｍｐエージェント
US7451336B2 (en) * 2003-10-16 2008-11-11 International Business Machines Corporation Automated load shedding of powered devices in a computer complex in the event of utility interruption
JP3826940B2 (ja) * 2004-06-02 2006-09-27 日本電気株式会社 障害復旧装置および障害復旧方法、マネージャ装置並びにプログラム
JP4362440B2 (ja) * 2004-12-27 2009-11-11 中部日本電気ソフトウェア株式会社 通報装置及び方法
JP4852963B2 (ja) * 2005-10-14 2012-01-11 株式会社日立製作所 伝送装置
US8065559B2 (en) * 2008-05-29 2011-11-22 Citrix Systems, Inc. Systems and methods for load balancing via a plurality of virtual servers upon failover using metrics from a backup virtual server
US8260926B2 (en) * 2008-11-25 2012-09-04 Citrix Systems, Inc. Systems and methods for GSLB site persistence
JP5168166B2 (ja) * 2009-01-21 2013-03-21 富士通株式会社 通信装置および通信制御方法
US8238263B2 (en) * 2009-03-18 2012-08-07 Landis+Gyr Technologies, Llc Network status detection

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004328726A (ja) * 2003-04-11 2004-11-18 Alcatel ネットワークマネジャｓｎｍｐトラップ抑制
JP2005293048A (ja) * 2004-03-31 2005-10-20 Fujitsu Ltd 資源計画作成プログラム

Also Published As

Publication number Publication date
US20100088402A1 (en) 2010-04-08
US7996528B2 (en) 2011-08-09
JP4978693B2 (ja) 2012-07-18
WO2008149455A1 (ja) 2008-12-11

Similar Documents

Publication Publication Date Title
JP4978693B2 (ja) マネジャ、エージェント及びシステム並びに送信制御方法
KR101292979B1 (ko) 디바이스 관리 서버를 통한 단말 내부 소프트웨어 관리방법
CN100411345C (zh) 用于通信网中设备部件的本地保证管理设备
CN105159816B (zh) 一种降低设备功耗的方法、移动终端及系统
CN105141400B (zh) 一种高可用性集群管理方法及相关设备
CN104598300A (zh) 分布式业务流程定制方法及系统
CN102045192A (zh) 网络结构的假定所用的装置及系统
EP3264723A1 (en) Method, related apparatus and system for processing service request
KR20150068317A (ko) Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법
CN111092778A (zh) 基于有限时序数据队列实现api实时预警的系统及方法
CN107995128B (zh) 综采集控系统的数据访问方法、装置、主机和存储介质
JP2007249829A (ja) 内部ネットワーク間通信システム及び情報処理装置及び中継情報処理装置及び通信制御プログラム及び内部ネットワーク間における通信制御方法及び遠隔障害管理システム及び被管理装置及び管理装置
JP5560641B2 (ja) データ管理装置、データ管理プログラムおよびデータ管理方法
CN109257396A (zh) 一种分布式锁调度方法及装置
EP3295567B1 (en) Pattern-based data collection for a distributed stream data processing system
CN112672363B (zh) 随流信息遥测能力的确认方法和设备
CN103957127B (zh) 异构厂家传输网络接口适配方法
CN107528709A (zh) 一种配置状态回退方法和装置
JP2010245841A (ja) ネットワーク管理方法、ネットワーク管理装置およびネットワーク機器
JP6668186B2 (ja) 衛星通信システム、トラフィック管理・課金処理装置およびファイル転送方法
JP2014003476A (ja) 通信システム、監視サーバ、基地局および通信制御方法
RU2337489C1 (ru) Система управления устройствами и ее способ планирования команд управления устройствами
KR20060116389A (ko) 네트워크 관리 시스템에서의 명령 재시도 장치 및 방법
JP2014082723A (ja) 遠隔監視システム、遠隔監視装置、通信装置および遠隔監視方法
CN109889363A (zh) 一种支持任意层次级联部署快速管理终端设备的方法

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120321

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120403

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150427

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees