JP6496860B2 - 監視システム、監視方法および監視プログラム - Google Patents

Description

本発明は、監視システム、監視方法および監視プログラムに関する。

従来、専用線などの品質保証型のキャリア伝送ネットワークサービスでは、ＥｔｈｅｒＯＡＭによる品質測定および監視が実施されている。ＥｔｈｅｒＯＡＭは、Ｌ２レイヤのネットワークおよびサービスを運用・維持管理するために使用される技術標準である。ＩＴＵ−Ｔ勧告では、Ｙ．１７３１、ＩＥＥＥでは、８０２．１ａｇとして標準化がなされている。ＥｔｈｅｒＯＡＭでは、監視対象のエンドポイント機器をＭＥＰ（Maintenance Entity Group End Point）と呼び、標準にて定義されているＣＣＭ（Continuity Check Message）フレームを用いた定常監視、ＬＭＭ（Loss Measurement Message）フレームを用いたロス測定、ＤＭＭ（Delay Measurement Message）フレームを用いた遅延測定などを、Ｌ２レイヤで実施することができる。

近年、ネットワーク技術をソフトウェアで実装してコモディティ化した汎用ハード上で機能実現するＮＦＶ（Network Function Virtualization）の機運が上位レイヤを中心に高まっており、伝送ネットワークにおいても今後流れが加速すると想定される。ＮＦＶを用いて柔軟なネットワーク設計を低コストに実現できるように、専用ハードで提供されていた機能をソフトウェアで再実装したＶＮＦ（Virtual Network Function）製品やＷｈｉｔｅｂｏｘといった製品が多く市場に送り出されている。

ＮＦＶ／ＶＮＦ化の流れは、ネットワークをより柔軟に設計したいというユーザのニーズ主導で進められており、上位レイヤから徐々にＶＮＦ製品がリリースされＬ３以上では多くの機能のＮＦＶ／ＶＮＦ化が実現されている。しかしながら、Ｌ２機能のＮＦＶ／ＶＮＦ化については、ＩＰを用いた制御ができない点、高い性能要件が求められる点などから、未だ発展途上である。

また、現在伝送ネットワーク業界では、統合伝送装置に組み込まれた各光デバイス・モジュールを分離し、それぞれの機能のみを実現したピザボックスタイプの装置を組み合わせることで機能実現するｄｉｓ−ａｇｇｒｅｇａｔｉｏｎ ＮＷが盛んに検討されている。Ａｌｌ−ｉｎ−ｏｎｅタイプだった光伝送装置をＬ２スイッチ、トランスポンダ、光スイッチ、光アンプなどの機能部に分けることで、装置調達と設備設計の柔軟性を向上することが目的である。

ｄｉｓ−ａｇｇｒｅｇａｔｉｏｎ ＮＷでは、分離された機能モジュールを自由に調達・構築することで安価に機能実現できる代わりに、統合伝送装置では標準的に具備されていたＥｔｈｅｒＯＡＭ機能を別途手配し構築しなければならない。キャリア向けの統合伝送装置であれば、収容可能な対向端末をＥｔｈｅｒＯＡＭで監視する機能は具備されていることが多く、装置導入と同時に監視機能が利用できる。ｄｉｓ−ａｇｇｒｅｇａｔｉｏｎされた機能モジュールを用いて伝送機能を実現する場合、監視専用のアプライアンス機器を別途手配するか、ソフトウェアで実装しＶＮＦを用いてＥｔｈｅｒＯＡＭ機能を実現するなど、機能追加対応が別途必要となる。

キャリア伝送ネットワークに別途ＥｔｈｅｒＯＡＭの機能を具備する場合、監視対象が多く性能要件が厳しいため、スケールアウトを考慮した設計にする必要がある。キャリア伝送ネットワークでは収容している全アクセス装置を監視しなければならないことから、監視対象装置数が一般的なＬ２ネットワークよりも多い。監視対象が増加したスケールアウトが必要な場合、物理装置を増やして手動で構築・設定することも可能だが、運用コストを考慮するとＮＦＶ／ＶＮＦ技術を活用して自動でスケールアウトすることが望ましい。

ＮＦＶ／ＶＮＦ技術を活用してＥｔｈｅｒＯＡＭ機能を実現する場合、ＶＮＦの動作・管理基盤としてＯｐｅｎＳｔａｃｋなどのＶＩＭ（Virtual Infrastructure Management）技術を採用することが有効である。ＯｐｅｎＳｔａｃｋ環境でＶＮＦのライフサイクル管理を行う際のリファレンスモデルとして、ＥＴＳＩのＮＦＶ ＭＡＮＯ（Management and Orchestration）が広く知られており、ＶＮＦのスケールアウト・イン、およびライフサイクル管理については、市中製品を利活用する観点からも前記モデルに従うことが望ましい。

ＥｔｈｅｒＯＡＭを用いて監視対象装置の監視を行う場合、監視対象装置および監視用ＶＮＦがそれぞれ非同期にＣＣＭフレームを送出し、対向からのＣＣＭフレームの到達によって対向との相互接続正常性を確認する。ここで、例えば、ユニキャストモードを使用してＣＣＭ定常監視を行う場合には、監視対象装置および監視用ＶＮＦに対し各々のフレーム送信先のＭＡＣアドレスを設定する必要がある。このため、ＥｔｈｅｒＯＡＭ機能をＶＮＦ化する場合には、ＶＮＦに動的に割り当てられるＭＡＣアドレスを監視対象装置のフレーム送信先として設定する。

特開２０１２−０１５６０７号公報

"ＪＴ−Ｙ１７３１ イーサネット（登録商標）のＯＡＭ機能とメカニズム"、［online］、2010年2月24日、情報通信技術委員会、［2017年3月16日検索］、インターネット（http://www.ttc.or.jp/jp/document_list/pdf/j/STD/JT-Y1731v1.pdf） "802.1ag-Connectivity Fault Management"、［online］、［2017年3月16日検索］、インターネット（http://www.ieee802.org/1/pages/802.1ag.html）

上述したように、従来のＥｔｈｅｒＯＡＭの手法では、ＶＮＦに動的に割り当てられるＭＡＣアドレスを監視対象装置のフレーム送信先として設定するので、簡易に監視対象装置の監視を行うことができなかったという課題があった。

例えば、ＯｐｅｎＳｔａｃｋを用いて監視用ＶＮＦインスタンスを生成した際に、当該ＶＮＦのＭＡＣアドレスにはＯｐｅｎＳｔａｃｋでプールされているＭＡＣアドレス帯から任意の値が自動的にアサインされる。このため、ＶＮＦ生成前に事前にアクセス装置にＣＣＭ送信先ＭＡＣアドレスを指定しておくことは不可能であり、ＶＮＦ生成後に自動生成されたＭＡＣアドレスをフレーム送信先として設定する必要がある。また、複数ＶＮＦインスタンスを利用する場合各ＶＮＦが異なるＭＡＣアドレスを持つため、スケールアウトなどにより監視対象装置の監視を行うＶＮＦが切り替わるたびに監視対象装置のフレーム送信先を変える必要がある。これらのオペレーションコストがかかり、簡易に監視処理を行うことができなかった。

なお、動的に設定されるＭＡＣアドレスではなく静的なアドレスを使用するために、一般的には、あらかじめ決められた静的なＭＡＣアドレスを各ＶＮＦにおいて共通的に使用する手法が用いられる。この方法は、動的なＭＡＣアドレスを追跡するオペレーションコストを削減することはできるが、全ＶＮＦにフレームが到達し負荷分散できない課題、および監視対象装置および監視ＶＮＦの通信経路上にＭＡＣ学習を行うＬ２スイッチがある場合、送信元ＭＡＣアドレスが同一のフレームが複数経路から到達することで正しくＭＡＣ学習ができない課題、などが生じる。

上述した課題を解決し、目的を達成するために、本発明の複数のＶＮＦを動作させる情報処理装置を有する監視システムであって、前記情報処理装置は、各ＶＮＦが管理する監視対象装置ごとにそれぞれ設定された自ＶＮＦの仮想ＭＡＣアドレスを記憶する記憶部と、前記各ＶＮＦが前記監視対象装置から送信されたフレームを受信した場合に、該フレームの送信先ＭＡＣアドレスと前記仮想ＭＡＣアドレスとが一致するＶＮＦについては、前記フレームに含まれる情報を基に前記監視対象装置の通信を監視させるように制御する監視制御部と、前記ＶＮＦが前記監視対象装置にフレームを送信する際には、前記記憶部から送信先の監視対象装置に対応するＶＮＦの仮想ＭＡＣアドレスを取得し、該取得した仮想ＭＡＣアドレスを送信元ＭＡＣアドレスに設定するように制御する設定制御部とを備えたことを特徴とする。

また、本発明の監視方法は、複数のＶＮＦを動作させる情報処理装置によって実行される監視方法であって、前記情報処理装置は、各ＶＮＦが管理する監視対象装置ごとにそれぞれ設定された自ＶＮＦの仮想ＭＡＣアドレスを記憶する記憶部を有し、前記各ＶＮＦが前記監視対象装置から送信されたフレームを受信した場合に、該フレームの送信先ＭＡＣアドレスと前記仮想ＭＡＣアドレスとが一致するＶＮＦについては、前記フレームに含まれる情報を基に前記監視対象装置の通信を監視させるように制御する監視制御工程と、前記ＶＮＦが前記監視対象装置にフレームを送信する際には、前記記憶部から送信先の監視対象装置に対応するＶＮＦの仮想ＭＡＣアドレスを取得し、該取得した仮想ＭＡＣアドレスを送信元ＭＡＣアドレスに設定するように制御する設定制御工程とを含んだことを特徴とする。

本発明によれば、オペレーションコストを低減して簡易に監視処理を行うことができるという効果を奏する。

図１は、第１の実施形態に係る監視システムの全体構成を示す概略図である。 図２は、第１の実施形態に係る情報処理装置の構成例を示すブロック図である。 図３は、仮想ＭＡＣ管理テーブル記憶部が記憶するテーブルの一例を示す図である。 図４は、仮想ＭＡＣアドレスの事前設定処理の一例を説明する図である。 図５は、ＥｔｈｅｒＯＡＭフレームの受信処理の一例を説明する図である。 図６は、ＥｔｈｅｒＯＡＭフレームの送信処理の一例を説明する図である。 図７は、同一物理ホスト上でのスケールアウト実施時の処理の一例を説明する図である。 図８は、別物理ホストへのスケールアウト実施時の処理の一例を説明する図である。 図９は、監視対象装置ごとに設定された仮想ＭＡＣアドレスを用いてフレームの送受信を行う処理の概要を説明する図である。 図１０は、第１の実施形態に係る監視システムにおける事前設定処理の流れの一例を示すシーケンス図である。 図１１は、第１の実施形態に係るＶＮＦにおける受信処理の流れの一例を示すフローチャートである。 図１２は、第１の実施形態に係るＶＮＦにおける送信処理の流れの一例を示すフローチャートである。 図１３は、従来方式の課題を説明する図である。 図１４は、従来方式の課題を説明する図である。 図１５は、監視プログラムを実行するコンピュータを示す図である。

以下に、本願に係る監視システム、監視方法、情報処理装置および監視プログラムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態により本願に係る監視システム、監視方法、情報処理装置および監視プログラムが限定されるものではない。

［第１の実施形態］
以下の実施の形態では、第１の実施形態に係る監視システム１の構成、情報処理装置１００の構成、監視システム１における処理の流れを順に説明し、最後に第１の実施形態による効果を説明する。

［監視システムの構成］
図１は、第１の実施形態に係る監視システムの構成の一例を示す図である。第１の実施形態に係る監視システム１は、複数のＶＮＦ１０Ａ〜１０Ｃ、ＥｔｈｅｒＯＡＭコントローラ２０、ＳＤＮ（Software-Defined Networking）コントローラ３０、ＶＮＦＭ（Virtual Network Function Manager）４０、ＶＩＭ（Virtualized Infrastructure Manager）５０、複数のアクセス装置６０Ａ、６０Ｂを有する。

また、各ＶＮＦ１０Ａ〜１０Ｃは、Ｌ２伝送ネットワーク７０およびＬ２スイッチ８０を介して、監視対象のアクセス装置６０Ａ、６０Ｂと接続されている。なお、図１に示す構成は一例にすぎず、具体的な構成や各装置の数は特に限定されない。また、複数のＶＮＦ１０Ａ〜１０Ｃ、複数のアクセス装置６０Ａ、６０Ｂについて、特に区別なく説明する場合には、ＶＮＦ１０、アクセス装置６０と記載する。

ＶＮＦ１０Ａ〜１０Ｃは、Ｌ２伝送ネットワーク７０に接続され、Ｌ２伝送ネットワーク７０およびＬ２スイッチ８０を介してアクセス装置６０との間でＥｔｈｅｒＯＡＭを送受信することで、監視を実現する。監視システム１では、ＥｔｈｅｒＯＡＭの送信先ＭＡＣアドレスとして対向のＭＡＣアドレスを指定して伝送するため、アクセス装置６０と各アクセス装置を監視するＶＮＦ１０はそれぞれＬ２レイヤで透過的に接続されている必要がある。ここで、図１の例を上げて説明すると、例えば、アクセス装置６０Ａは、アクセス装置６０Ａを監視するＶＮＦ１０Ａと透過的に接続されており、アクセス装置６０Ｂは、アクセス装置６０Ｂを監視するＶＮＦ１０Ｂと透過的に接続されている。アクセス装置６０Ａとアクセス装置６０Ｂの間は透過的に接続される必要はない。例えば、Ｌ２スイッチ８０のＶＮＦ１０と接続するポートをトランクポートにし複数ＶＬＡＮ収容可能にすることで、アクセス装置６０間は別Ｌ２セグメントに分離しつつ、アクセス装置６０と各アクセス装置を監視するＶＮＦ１０は透過的に接続する。

ＶＮＦ１０Ａ〜１０Ｃは、ＯｐｅｎＳｔａｃｋに代表されるＶＩＭ５０上に仮想的に構築される。また、ＶＮＦ１０Ａ〜１０Ｃのインスタンス生成・削除・スケールアウト・インなどのライフサイクル管理は、ＶＮＦＭ４０によって制御される。ＶＮＦ１０Ａ〜１０ＣにおけるＥｔｈｅｒＯＡＭ関連設定情報の管理は、ＥｔｈｅｒＯＡＭコントローラ２０によって実施される。なお、ここでＥｔｈｅｒＯＡＭ関連設定情報とは、例えば、監視対象のアクセス装置６０Ａ、６０ＢのＭＥＧ ＩＤ、ＭＥＰ ＩＤ、ＭＡＣアドレス、ＶＬＡＮなどである。また、ＶＮＦ１０Ａ〜１０Ｃおよびアクセス装置６０Ａ、６０Ｂの両者に整合性の取れたプロビジョニングを実施する必要があり、上位のＳＤＮコントローラ３０によって実施される。

ここで、図１では、ＥｔｈｅｒＯＡＭコントローラ２０、ＳＤＮコントローラ３０、ＶＮＦＭ４０、ＶＩＭ５０の各機能は、同一の物理マシンで実現してもよいし、別々の物理マシンで実現してもよい。以下の説明では、ＥｔｈｅｒＯＡＭコントローラ２０、ＳＤＮコントローラ３０、ＶＮＦＭ４０、ＶＩＭ５０が同一の物理マシンである情報処理装置１００で実現しているものとして説明する。

［情報処理装置の構成］
次に、図２を用いて、情報処理装置１００の構成を説明する。図２は、第１の実施形態に係る情報処理装置の構成例を示すブロック図である。図２に示すように、この情報処理装置１００は、通信処理部１１、制御部１２および記憶部１３を有する。以下に情報処理装置１００が有する各部の処理を説明する。

通信処理部１１は、各種情報に関する通信を制御する。例えば、通信処理部１１は、伝送ネットワーク７０とＬ２スイッチ８０を介してアクセス装置６０との間でＥｔｈｅｒＯＡＭフレームの送受信を行う。

記憶部１３は、制御部１２による各種処理に必要なデータおよびプログラムを格納するが、特に本発明に密接に関連するものとしては、仮想ＭＡＣ管理テーブル記憶部１３ａを有する。例えば、記憶部１３は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置などである。

仮想ＭＡＣ管理テーブル記憶部１３ａは、各ＶＮＦ１０が管理する監視対象のアクセス装置６０ごとにそれぞれ設定されたＶＮＦ１０の仮想ＭＡＣアドレスと、アクセス装置６０のＭＡＣアドレス・ＶＬＡＮ ＩＤを記憶する。例えば、仮想ＭＡＣ管理テーブル記憶部１３ａは、図３に例示するように、「ＭＥＧ ＩＤ」と「ＭＥＰ ＩＤ」に対応付けて、監視対象のアクセス装置６０ごとにそれぞれ設定されたＶＮＦ１０の仮想ＭＡＣアドレスである「仮想ＭＡＣ」を記憶する。また、アクセス装置６０の構成情報として、「監視対象ＭＡＣ」および「ＶＬＡＮ ＩＤ」を記憶する。図３では「ＶＬＡＮ ＩＤ」が一つ使用する場合を示しているが、「ＶＬＡＮ ＩＤ」は多段に付与してもよい。ただし、前提条件として、「監視対象ＭＡＣ」と０以上の「ＶＬＡＮ ＩＤ」の組み合わせで一意性の制約を満たし、同様に「仮想ＭＡＣ」と０以上の「ＶＬＡＮ ＩＤ」の組み合わせで一意性の制約を満たす。

以降の記述では、記述を簡易化するために、「仮想ＭＡＣ」だけで一意性の制約を満たしている場合を例とするが、上述の通り「仮想ＭＡＣ」だけで一意性の制約を満たすことは要しない。「仮想ＭＡＣ」と０以上の「ＶＬＡＮ ＩＤ」の組み合わせで一意性の制約を満たしていればよい。

図３の例を挙げて説明すると、例えば、仮想ＭＡＣ管理テーブル記憶部１３ａは、ＶＮＦ１０Ａが管理する管理対象のアクセス装置６０Ａに対応する情報として、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」と、アクセス装置６０Ａの構成情報（監視対象ＭＡＣ「ＹＹ：ＹＹ：ＹＹ：ＹＹ：ＹＹ：Ｙ１」およびＶＬＡＮ ＩＤ「１０」）とを対応付けて記憶し、ＶＮＦ１０Ｂが管理する管理対象のアクセス装置６０Ｂに対応する情報として、ＭＥＧ ＩＤ「ＭＥＧ２０」と、ＭＥＰ ＩＤ「２００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ２」と、アクセス装置６０Ｂの構成情報（監視対象ＭＡＣ「ＹＹ：ＹＹ：ＹＹ：ＹＹ：ＹＹ：Ｙ２」およびＶＬＡＮ ＩＤ「２０」）とを対応付けて記憶する。

図３に例示する仮想ＭＡＣ管理テーブルについて、ＥｔｈｅｒＯＡＭコントローラ２０は、仮想ＭＡＣ管理テーブルに含まれる全てのレコードを保持する。各ＶＮＦ１０は、仮想ＭＡＣ管理テーブルのうち、各自が管理する管理対象のアクセス装置６０に対応するレコードをそれぞれ保持する。例えば、ＶＮＦ１０Ａは、ＶＮＦ１０Ａが管理する管理対象のアクセス装置６０Ａに対応する情報として、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」と、アクセス装置６０Ａの構成情報（監視対象ＭＡＣ「ＹＹ：ＹＹ：ＹＹ：ＹＹ：ＹＹ：Ｙ１」およびＶＬＡＮ ＩＤ「１０」）とが対応付けられたレコードを仮想ＭＡＣ管理テーブルとして保持する。

制御部１２は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行するが、特に本発明に密接に関連するものとしては、事前設定部１２ａ、判定制御部１２ｂ、監視制御部１２ｃ、設定制御部１２ｄ、決定部１２ｅ、通知部１２ｆおよび更新部１２ｇを有する。ここで、制御部１２は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路やＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路である。

また、各部のうち、事前設定部１２ａがＳＤＮコントローラ３０が有する機能であり、判定制御部１２ｂ、監視制御部１２ｃおよび設定制御部１２ｄがＶＮＦ１０が有する機能であり、決定部１２ｅ、通知部１２ｆおよび更新部１２ｇがＥｔｈｅｒＯＡＭコントローラ２０が有する機能であるものとする。

事前設定部１２ａは、仮想ＭＡＣアドレスの事前設定処理として、監視対象のアクセス装置６０に対応するＶＮＦ１０の仮想ＭＡＣアドレスを払い出し、該監視対象のアクセス装置６０に対して該仮想ＭＡＣアドレスをＥｔｈｅｒＯＡＭフレームの送信先ＭＡＣアドレスとして設定するとともに、払い出された仮想ＭＡＣアドレスを仮想ＭＡＣ管理テーブル記憶部１３ａに設定する。

ここで、図４を用いて、仮想ＭＡＣアドレスの事前設定処理の一例を説明する。図４は、仮想ＭＡＣアドレスの事前設定処理の一例を説明する図である。なお、以下の説明では、ＶＮＦ１０と監視対象のアクセス装置６０とが一対一の関係である場合を例に説明するが、当然これに限定されるものではなく、例えば、ＶＮＦ１０が一つに対して、複数のアクセス装置６０を監視対象としてもよい。

図４に示すように、ＳＤＮコントローラ３０は、監視対象のアクセス装置６０Ａ、６０Ｂに対してＥｔｈｅｒＯＡＭ送信先ＭＡＣアドレスとして任意の仮想ＭＡＣアドレスを払い出し、該仮想ＭＡＣアドレスをＭＥＧ ＩＤ、ＭＥＰ ＩＤ、ＶＬＡＮ ＩＤと合わせてアクセス装置６０Ａ、６０Ｂに設定する。なお、仮想ＭＡＣアドレスを払い出す際には、前述の一意性の制約を満たす必要がある。

図４の例を挙げて説明すると、例えば、ＳＤＮコントローラ３０は、監視対象のアクセス装置６０Ａに対してＥｔｈｅｒＯＡＭ送信先ＭＡＣアドレスとして、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」を設定するとともに、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、ＶＬＡＮ ＩＤ「１０」を設定する。また、ＳＤＮコントローラ３０は、監視対象のアクセス装置６０Ｂに対してＥｔｈｅｒＯＡＭ送信先ＭＡＣアドレスとして、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ２」を設定するとともに、ＭＥＧ ＩＤ「ＭＥＧ２０」と、ＭＥＰ ＩＤ「２００」と、ＶＬＡＮ ＩＤ「２０」を設定する。

また、ＳＤＮコントローラ３０は、アクセス装置６０の有するＭＡＣアドレスを取得し、ＥｔｈｅｒＯＡＭコントローラ２０に対してアクセス装置６０の構成情報（ＭＥＧ ＩＤ、ＭＥＰ ＩＤ、ＭＡＣアドレス、ＶＬＡＮ ＩＤ）とともに、払い出した仮想ＭＡＣアドレスを設定する。ＥｔｈｅｒＯＡＭコントローラ２０は、払い出された仮想ＭＡＣアドレス、アクセス装置のＭＡＣアドレス、ＶＬＡＮ ＩＤを、「ＭＥＧ ＩＤ」、「ＭＥＰ ＩＤ」を複合主キーとする仮想ＭＡＣ管理テーブルに格納する。図４の例を挙げて説明すると、例えば、ＥｔｈｅｒＯＡＭコントローラ２０は、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」と、構成情報（監視対象ＭＡＣ「ＹＹ：ＹＹ：ＹＹ：ＹＹ：ＹＹ：Ｙ１」およびＶＬＡＮ ＩＤ「１０」）とが対応付けられたレコードと、ＭＥＧ ＩＤ「ＭＥＧ２０」と、ＭＥＰ ＩＤ「２００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ２」と、構成情報（監視対象ＭＡＣ「ＹＹ：ＹＹ：ＹＹ：ＹＹ：ＹＹ：Ｙ２」およびＶＬＡＮ ＩＤ「２０」）とが対応付けられたレコードを記憶する。

そして、ＥｔｈｅｒＯＡＭコントローラ２０は、登録されたアクセス装置６０Ａ、６０Ｂの監視をどのＶＮＦ１０が担当するかを決定し、仮想ＭＡＣ管理テーブルの該当レコードをＶＮＦ１０に通知する。そして、ＶＮＦ１０は、ＥｔｈｅｒＯＡＭコントローラ２０から通知されたレコードを基に、指定されたアクセス装置６０の監視を行う。図４の例を挙げて説明すると、例えば、ＥｔｈｅｒＯＡＭコントローラ２０は、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」とが対応付けられたレコードをＶＮＦ１０Ａに通知し、ＶＭＥＧ ＩＤ「ＭＥＧ２０」と、ＭＥＰ ＩＤ「２００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ２」とが対応付けられたレコードをＶＮＦ１０Ｂに通知する。

判定制御部１２ｂは、各ＶＮＦ１０が監視対象のアクセス装置６０から送信されたＥｔｈｅｒＯＡＭフレームを受信した場合に、該ＥｔｈｅｒＯＡＭフレームの送信先ＭＡＣアドレスが自ＶＮＦ１０の仮想ＭＡＣアドレスのいずれかと一致するか各ＶＮＦ１０にそれぞれ判定させ、送信先ＭＡＣアドレスと仮想ＭＡＣアドレスとが一致しないＶＮＦ１０については、ＥｔｈｅｒＯＡＭフレームを破棄させるように制御する。

監視制御部１２ｃは、送信先ＭＡＣアドレスと仮想ＭＡＣアドレスとが一致するＶＮＦ１０については、ＥｔｈｅｒＯＡＭフレームに含まれる情報を基に監視対象のアクセス装置６０の通信を監視させるように制御する。具体的には、監視制御部１２ｃは、送信先ＭＡＣアドレスと仮想ＭＡＣアドレスとが一致するＶＮＦ１０については、ＥｔｈｅｒＯＡＭフレームから情報を取得させ、監視対象のアクセス装置６０のステータスを更新させるように制御する。

ここで、図５を用いて、ＥｔｈｅｒＯＡＭフレームの受信処理の一例を説明する。図５は、ＥｔｈｅｒＯＡＭフレームの受信処理の一例を説明する図である。図５に示すように、アクセス装置６０Ａは、仮想ＭＡＣアドレス「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」を送信先として、ＥｔｈｅｒＯＡＭフレームを送信する。ＶＮＦ１０Ａ〜１０Ｃでは、自身のＭＡＣアドレスと異なるＥｔｈｅｒＯＡＭフレームを取得するために、インタフェースをプロミスキャスモードに設定しておく。これにより、同一物理ホスト内の全てのＶＮＦ１０Ａ〜１０Ｃが、ＥｔｈｅｒＯＡＭフレームを受信する。

各ＶＮＦ１０Ａ〜１０Ｃが受信したＥｔｈｅｒＯＡＭフレームは、ソケットを通じてアプリケーション内に引き込まれる。各ＶＮＦ１０Ａ〜１０ＣのＥｔｈｅｒＯＡＭアプリケーションでは、送信先ＭＡＣアドレスをキーとして仮想ＭＡＣ管理テーブルを検索する。そして、ＥｔｈｅｒＯＡＭアプリケーションは、検索の結果、レコードが存在しない場合、つまり、自ＶＮＦ１０にとって監視対象からのＥｔｈｅｒＯＡＭフレームでない場合には、ＥｔｈｅｒＯＡＭフレームを破棄する。

また、ＥｔｈｅｒＯＡＭアプリケーションは、検索の結果、レコードが存在する場合、つまり、自ＶＮＦ１０にとって監視対象からのＥｔｈｅｒＯＡＭフレームである場合には、ＥｔｈｅｒＯＡＭフレームに含まれる情報を基に監視対象のアクセス装置６０に対する監視処理として、アクセス装置６０のステータス更新を実施する。

図５の例では、ＶＮＦ１０Ａの仮想ＭＡＣ管理テーブルには、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」とが対応付けられたレコードが記憶されている。ＶＮＦ１０Ｂの仮想ＭＡＣ管理テーブルには、ＭＥＧ ＩＤ「ＭＥＧ２０」と、ＭＥＰ ＩＤ「２００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ２」とが対応付けられたレコードが記憶されている。このため、ＶＮＦ１０Ａは、送信先ＭＡＣアドレス「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」と一致する仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」のレコードが存在するので、ＥｔｈｅｒＯＡＭフレームを受信して監視処理を行う。また、ＶＮＦ１０ＢおよびＶＮＦ１０Ｃは、送信先ＭＡＣアドレス「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」と一致するレコードが存在しないので、ＥｔｈｅｒＯＡＭフレームを破棄する。

設定制御部１２ｄは、ＶＮＦ１０が監視対象のアクセス装置６０にＥｔｈｅｒＯＡＭフレームを送信する際には、仮想ＭＡＣ管理テーブル記憶部１３ａから送信先のアクセス装置６０に対応するＶＮＦ１０の仮想ＭＡＣアドレスを取得し、該取得した仮想ＭＡＣアドレスを送信元ＭＡＣアドレスに設定するように制御する。

ここで、図６を用いて、ＥｔｈｅｒＯＡＭフレームの送信処理の一例を説明する。図６は、ＥｔｈｅｒＯＡＭフレームの送信処理の一例を説明する図である。図６に示すように、ＶＮＦ１０Ａは、仮想ＭＡＣ管理テーブルより監視対象のレコードを順次取得し、仮想ＭＡＣアドレス「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」を送信元、アクセス装置６０ＡのＭＡＣアドレス「ＹＹ：ＹＹ：ＹＹ：ＹＹ：ＹＹ：Ｙ１」を送信先として、ＥｔｈｅｒＯＡＭフレームを送信する。

この際、ＥｔｈｅｒＯＡＭフレームを送信したＶＮＦ１０Ａを除く他のＶＮＦ１０Ｂ、１０Ｃは、インタフェースがプロミスキャスモードに設定されているため、当該ＥｔｈｅｒＯＡＭフレームを受信する。ＥｔｈｅｒＯＡＭアプリケーションでは、仮想ＭＡＣ管理テーブルに合致しないＥｔｈｅｒＯＡＭフレームは破棄されるため、本フレームがステータス変更には影響しない。

決定部１２ｅは、情報処理装置１００に新たなＶＮＦ１０が生成された場合に、すでに動作しているＶＮＦ１０が管理する監視対象のアクセス装置６０のうち、新たなＶＮＦ１０に監視させるアクセス装置６０を決定する。つまり、決定部１２ｅは、ＶＮＦ１０がスケールアウトしＶＮＦインスタンスを増やした場合、稼働中のＶＮＦ１０から新規ＶＮＦ１０に委譲する監視対象を決定する。

また、決定部１２ｅは、情報処理装置１００とは異なる別の情報処理装置に新たなＶＮＦ１０が生成された場合に、すでに動作しているＶＮＦ１０が管理する監視対象のアクセス装置６０のうち、新たなＶＮＦ１０に監視させるアクセス装置６０を決定する。つまり、決定部１２ｅは、別物理ホストにスケールアウトする場合も、稼働中のＶＮＦ１０から別物理ホストの新規ＶＮＦ１０に委譲する監視対象を決定する。

通知部１２ｆは、決定部１２ｅによって決定された新たなＶＮＦ１０に監視させる監視対象のアクセス装置６０に対応する仮想ＭＡＣアドレスを、新たなＶＮＦ１０の仮想ＭＡＣアドレスとして登録するように別のＶＮＦ１０に通知する。なお、通知部１２ｆは、異なる物理ホスト上で生成された場合だけでなく、新たなＶＮＦが同一物理ホスト上で生成された場合であっても、新たなＶＮＦ１０に監視させる監視対象のアクセス装置６０に対応する仮想ＭＡＣアドレスを、新たなＶＮＦ１０の仮想ＭＡＣアドレスとして登録するように別のＶＮＦ１０に通知する。

更新部１２ｇは、新たなＶＮＦ１０に監視させる監視対象のアクセス装置６０に対応する仮想ＭＡＣアドレスを、通知部１２ｆによって通知された仮想ＭＡＣアドレスに変更するように仮想ＭＡＣ管理テーブル記憶部１３ａを更新する。

ここで、図７および図８を用いて、スケールアウト実施時の処理の一例を説明する。図７は、同一物理ホスト上でのスケールアウト実施時の処理の一例を説明する図である。図８は、別物理ホストへのスケールアウト実施時の処理の一例を説明する図である。図７に例示するように、同一物理ホスト上でＥｔｈｅｒＯＡＭ ＶＮＦをスケールアウトし、新たにＶＮＦ１０Ｄを増やした場合、ＥｔｈｅｒＯＡＭコントローラ２０は、稼働中のＶＮＦ１０Ａから新規ＶＮＦ１０Ｄに委譲する監視対象を決定する。ここでは、ＥｔｈｅｒＯＡＭコントローラ２０は、稼働中のＶＮＦ１０Ａから新規ＶＮＦ１０Ｄに委譲する監視対象として、アクセス装置６０Ａを決定したものとする。

この際、ＥｔｈｅｒＯＡＭコントローラ２０からの通知により、委譲元のＶＮＦ１０Ａの仮想ＭＡＣ管理テーブルからは対象のアクセス装置６０Ａのレコードは破棄され、新規ＶＮＦ１０Ｄの仮想ＭＡＣ管理テーブルにアクセス装置６０Ａのレコードが追加される。ここで、アクセス装置６０Ａのレコードとは、図７に例示されるように、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ１」とが対応付けられたレコードである。このように、委譲により監視を行うＶＮＦインスタンスが変更されるが、この場合でも送受信フレームのＭＡＣアドレスは変化せず、監視に影響を及ぼさない。

このため、スケールアウト時だけでなく、スケールインや障害発生時など、ＶＮＦ１０間で監視対象の委譲を行うケースにおいて、監視処理に影響を与えることなく容易に実施することが可能となる。ただし、ＶＮＦ１０に障害が発生した場合には、ＥｔｈｅｒＯＡＭコントローラ２０にて障害検知し、フェールオーバを行う必要がある。

なお、スケールアウト実施時の委譲する監視対象の決定や仮想ＭＡＣ管理テーブルの更新をＥｔｈｅｒＯＡＭコントローラ２０が制御する場合を例に説明するが、これに限定されるものではなく、例えば、ＶＮＦ１０が委譲する監視対象を決定してもよいし、ＶＮＦ１０間で通信を行うことで仮想ＭＡＣ管理テーブルの更新を実施するようにしてもよい。

続いて、図８を用いて、別物理ホストへのスケールアウト実施時の処理の一例を説明する。図８に示すように、別物理ホストにスケールアウトする場合も、図７の場合と同様に、仮想ＭＡＣ管理テーブルの更新を実施する。

例えば、ＥｔｈｅｒＯＡＭコントローラ２０は、稼働中のＶＮＦ１０Ｂから新規ＶＮＦ１０Ｅに委譲する監視対象のアクセス装置６０Ｂを決定すると、監視対象のアクセス装置６０Ｂに対応する仮想ＭＡＣアドレス「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：Ｘ２」を、新規ＶＮＦ１０Ｅの仮想ＭＡＣアドレスとして変更させるように別の物理ホストに通知する。そして、スケールアウト先のＶＮＦ１０ＥがＥｔｈｅｒＯＡＭフレームを送出することで、経路上にあるＬ２スイッチ８０ＡのＭＡＣ学習テーブルが学習される。これにより、移動先の物理ホストにのみフレームが到達するようになり、処理の負荷分散を実現することが可能である。

このように、第１の実施形態に係る監視システム１では、監視対象ごとに仮想ＭＡＣアドレスを用意し、ＶＭインスタンス生成時に動的に割り当てられたＭＡＣアドレスではなく、監視対象装置用の仮想ＭＡＣアドレスを用いて、ＶＮＦ１０とアクセス装置６０との間でフレームの送受信を行う。各ＶＮＦ１０は、仮想ＭＡＣ管理テーブルを持ち、対向装置ごとに別のＭＡＣアドレスを使用する。

ここで、図９を用いて、監視対象装置ごとに設定された仮想ＭＡＣアドレスを用いてフレームの送受信を行う処理の概要について説明する。図９は、監視対象装置ごとに設定された仮想ＭＡＣアドレスを用いてフレームの送受信を行う処理の概要を説明する図である。例えば、図９の例では、ＶＮＦ１０Ｂは、監視対象ごとの仮想ＭＡＣアドレスとして、「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：１０」、「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：１１」・・・「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ」が規定された仮想ＭＡＣ管理テーブルを有している。例えば、第１の実施形態に係る監視システム１では、１つのＶＮＦ１０で監視するアクセス装置６０が１０００台ある場合には、１０００個の対向装置ごとの仮想ＭＡＣアドレスを使用することとなる。

また、スケールアウトやフェールオーバにより監視元ＶＮＦが変更になった際は、ＶＮＦ１０は、仮想ＭＡＣ管理テーブルのレコードを更新し、移動先のＶＮＦ１０にて同仮想ＭＡＣアドレスを使用してフレームの送受信を行う。例えば、図９の例では、別物理ホストのＶＩＭ５０Ａに新しくＶＮＦ５０Ｅ〜５０Ｇが生成され、アクセス装置６０の監視をＶＮＦ１０ＢからＶＮＦ１０Ｅに変更する場合には、ＶＮＦ１０Ｂの仮想ＭＡＣ管理テーブルからはアクセス装置６０のレコードが破棄され、新規ＶＮＦ１０Ｅの仮想ＭＡＣ管理テーブルにアクセス装置６０のレコードが追加される。ここで、アクセス装置６０のレコードとは、図９に例示されるように、ＭＥＧ ＩＤ「ＭＥＧ１０」と、ＭＥＰ ＩＤ「１００」と、仮想ＭＡＣ「ＸＸ：ＸＸ：ＸＸ：ＸＸ：ＸＸ：１０」とが対応付けられたレコードである。

［監視システムの処理手順］
次に、図１０を用いて、第１の実施形態に係る監視システム１による事前設定処理の手順の例を説明する。図１０は、第１の実施形態に係る監視システムにおける事前設定処理の流れの一例を示すシーケンス図である。

図１０に示すように、ＳＤＮコントローラ３０は、監視対象のアクセス装置６０に対してＥｔｈｅｒＯＡＭ送信先ＭＡＣアドレスとして任意の仮想ＭＡＣアドレスを払い出し（ステップＳ１０１）、該仮想ＭＡＣアドレスをＭＥＧ ＩＤ、ＭＥＰ ＩＤ、ＶＬＡＮ ＩＤと合わせてアクセス装置６０に通知する（ステップＳ１０２）。なお、仮想ＭＡＣアドレスを払い出す際には、同一Ｌ２セグメント内で重複がないようにする必要がある。そして、アクセス装置６０は、仮想ＭＡＣアドレスを受信すると、該受信した仮想ＭＡＣアドレスをＥｔｈｅｒＯＡＭ送信先ＭＡＣアドレスとして設定する（ステップＳ１０３）。

その後、ＳＤＮコントローラ３０は、アクセス装置６０の有するＭＡＣアドレスを取得する（ステップＳ１０４）。そして、ＳＤＮコントローラ３０は、ＥｔｈｅｒＯＡＭコントローラ２０に対してアクセス装置６０の構成情報（ＭＥＧ ＩＤ、ＭＥＰ ＩＤ、ＭＡＣアドレス、ＶＬＡＮ ＩＤ）とともに、払い出した仮想ＭＡＣアドレスを通知する（ステップＳ１０５）。そして、ＥｔｈｅｒＯＡＭコントローラ２０は、払い出された仮想ＭＡＣアドレスを、アクセス装置６０の構成情報を複合キーとして仮想ＭＡＣ管理テーブルに格納する（ステップＳ１０６）。そして、ＥｔｈｅｒＯＡＭコントローラ２０は、登録されたアクセス装置６０の監視を担当する担当ＶＮＦをＶＮＦ１０Ａ〜１０Ｃのなかから決定する（ステップＳ１０７）。ここでは、例えば、アクセス装置６０の監視をＶＮＦ１０Ａが担当すると決定したものとする。

この場合には、ＥｔｈｅｒＯＡＭコントローラ２０は、監視対象のアクセス装置６０に対応する仮想ＭＡＣアドレスをＶＮＦ１０Ａに通知する（ステップＳ１０８）。そして、ＶＮＦ１０Ａは、ＥｔｈｅｒＯＡＭコントローラ２０から通知された仮想ＭＡＣアドレスを仮想ＭＡＣ管理テーブルに設定する（ステップＳ１０９）。

次に、図１１および図１２を用いて、第１の実施形態に係るＶＮＦによる送受信処理の手順の例を説明する。図１１は、第１の実施形態に係るＶＮＦにおける受信処理の流れの一例を示すフローチャートである。図１２は、第１の実施形態に係るＶＮＦにおける送信処理の流れの一例を示すフローチャートである。

まず、図１１を用いて、ＶＮＦ１０における受信処理の流れを説明する。図１１に例示するように、ＶＮＦ１０は、フレームを受信すると（ステップＳ２０１肯定）、送信先ＭＡＣアドレスをキーとして仮想ＭＡＣ管理テーブルを検索する（ステップＳ２０２）。

そして、ＶＮＦ１０は、検索の結果、レコードが存在する場合（ステップＳ２０３肯定）、つまり、自ＶＮＦにとって監視対象からのフレームである場合には、ＥｔｈｅｒＯＡＭフレームに含まれる情報を基に監視対象のアクセス装置６０に対する監視処理を実施する（ステップＳ２０４）。

また、ＶＮＦ１０は、検索の結果、仮想ＭＡＣ管理テーブルにレコードが存在しない場合（ステップＳ２０３否定）、つまり、自ＶＮＦにとって監視対象からのフレームでない場合には、ＥｔｈｅｒＯＡＭフレームを破棄する（ステップＳ２０５）。

次に、図１２を用いて、ＶＮＦ１０における送信処理の流れを説明する。図１２に例示するように、ＶＮＦ１０は、アクセス装置６０に対してＥｔｈｅｒＯＡＭフレームを送信する際には、仮想ＭＡＣ管理テーブルより監視対象のアクセス装置６０のレコードを取得する（ステップＳ３０１）。

そして、ＶＮＦ１０は、取得したレコードを参照し、仮想ＭＡＣアドレスを送信元、アクセス装置６０のＭＡＣアドレスを送信先としてＥｔｈｅｒＯＡＭフレームに設定し（ステップＳ３０２）、ＥｔｈｅｒＯＡＭフレームを送信する（ステップＳ３０３）。

［第１の実施形態の効果］
第１の実施形態に係る監視システム１における情報処理装置１００は、各ＶＮＦ１０が管理するアクセス装置６０ごとにそれぞれ設定されたＶＮＦ１０の仮想ＭＡＣアドレスを記憶する仮想ＭＡＣ管理テーブル記憶部１３ａを有する。そして、情報処理装置１００は、各ＶＮＦ１０がアクセス装置６０から送信されたフレームを受信した場合に、該フレームの送信先ＭＡＣアドレスが自ＶＮＦ１０の仮想ＭＡＣアドレスと一致するか各ＶＮＦ１０にそれぞれ判定させ、送信先ＭＡＣアドレスと仮想ＭＡＣアドレスとが一致しないＶＮＦ１０については、フレームを破棄させるように制御する。また、情報処理装置１００は、送信先ＭＡＣアドレスと仮想ＭＡＣアドレスとが一致するＶＮＦ１０については、フレームに含まれる情報を基にアクセス装置６０の通信を監視させるように制御する。また、情報処理装置１００は、ＶＮＦ１０がアクセス装置６０にフレームを送信する際には、仮想ＭＡＣ管理テーブル記憶部１３ａから送信先のアクセス装置６０に対応するＶＮＦ１０の仮想ＭＡＣアドレスを取得し、該取得した仮想ＭＡＣアドレスを送信元ＭＡＣアドレスに設定するように制御する。

このように、第１の実施形態に係る監視システム１では、監視対象のアクセス装置６０ごとに仮想ＭＡＣアドレスを事前に用意し、それを保持する仮想ＭＡＣ管理テーブルを使用するので、ＶＮＦ１０に動的に割り当てられるＭＡＣアドレスを用いることなく、オペレーションコストを低減して簡易に監視処理を行うことが可能である。

また、第１の実施形態に係る監視システム１では、監視元ＶＮＦ１０が移動した場合にも仮想ＭＡＣアドレスを引き継ぐため、移動先のＶＮＦのＭＡＣアドレスを追跡する必要がなくなる。一方、ＶＮＦに動的に割り当てられたＭＡＣアドレスする従来のやり方では、移動先のＶＮＦのＭＡＣアドレスを追跡する必要がある。

例えば、図１３に例示するように、従来方式では、監視元ＶＮＦがＶＮＦ１１０ＢからＶＮＦ１１０Ｄに変更した場合に、アクセス装置６００に対して、ＥｔｈｅｒＯＡＭの送信先ＭＡＣアドレスがＶＮＦ１１０ＢのＭＡＣアドレス（Ａ）からＶＮＦ１１０ＤのＭＡＣアドレス（Ｂ）に変更したことを通知する必要がある。なお、ここでＭＡＣアドレス（Ａ）とは、ＶＮＦ１１０Ｂ生成時に動的に割り当てられたＶＮＦ１１０ＢのＭＡＣアドレスであり、ＭＡＣアドレス（Ｂ）とは、ＶＮＦ１１０Ｄ生成時に動的に割り当てられたＶＮＦ１１０ＤのＭＡＣアドレスである。

また、第１の実施形態に係る監視システム１では、ＶＮＦ１０ごとに異なるユニキャストアドレスを使用するため、必要なＶＩＭ物理ホストにのみフレームが到達し、ＶＩＭ物理ホスト間での負荷分散が可能となる。さらに、第１の実施形態に係る監視システム１では、監視対象ごとに異なるユニキャストアドレスを使用することで、同一仮想ＭＡＣアドレスを維持したまま物理ホストをまたいでも経路上のＬ２スイッチで適切にＭＡＣ学習が実施されるようになり、物理ホストをまたいだ移動が可能となる。

つまり、例えば、仮にマルチキャストアドレスを使用した場合には、ＭＡＣ学習の対象ではなくＶＩＭの全物理ホストに到達する。このため、ＮＩＣ Ｉ／Ｏ負荷や仮想ブリッジでのＬ２フォワーディングなどのカーネルドメイン処理の負荷がＶＩＭを構成する全ての物理ホストで発生し、処理負荷を分散することができない。これに対して、第１の実施形態に係る監視システム１では、ＶＮＦ１０ごとに異なるユニキャストアドレスを使用するため、必要なＶＩＭ物理ホストにのみフレームが到達し、ＶＩＭ物理ホスト間での負荷分散が可能となる。

また、例えば、仮にユニキャストアドレスを複数ＶＩＭ物理ホストをまたぐ共通仮想ＭＡＣアドレスとして使用した場合、複数のＶＩＭ物理ホストから同一ＭＡＣアドレスを送信元とするＥｔｈｅｒＯＡＭが到達するため、経路上のＬ２スイッチで適切にＭＡＣ学習することができない。これに対して、第１の実施形態に係る監視システム１では、監視対象ごとに異なるユニキャストアドレスを使用するため、同一仮想ＭＡＣアドレスを維持したまま物理ホストをまたいでも経路上のＬ２スイッチで適切にＭＡＣ学習が実施されるようになり、物理ホストをまたいだ移動が可能となる。

また、第１の実施形態に係る監視システム１では、ＣＣＭヘッダ内のＭＥＧ ＩＤやＭＥＰ ＩＤを用いた監視対象の判定を行う代わりに、仮想ＭＡＣ管理テーブルを用いて送信先ＭＡＣアドレスをもとに監視対象か否かを判断する。これにより、Ｅｔｈｅｒフレームのデコードだけで監視対象判定を実施可能となり、ユーザドメイン処理負荷を低減できる。

ここで、ＣＣＭヘッダ内のＭＥＧ ＩＤやＭＥＰ ＩＤを用いた対象判定について、図１４を用いて説明する。図１４に示すように、ＶＮＦは、受信したＥｔｈｅｒＯＡＭフレームが監視対象であるか否かを判断するために、ヘッダ内のＭＥＧ ＩＤやＭＥＰ ＩＤを抽出し、ＭＥＧ ＩＤやＭＥＰ ＩＤを用いて、送信元解決を行っていた。これに対して、第１の実施形態に係る監視システム１では、ＶＮＦ１０は、ＣＣＭヘッダからＭＥＧ ＩＤやＭＥＰ ＩＤを抽出することなく、Ｅｔｈｅｒヘッダの送信先ＭＡＣアドレスをもとに仮想ＭＡＣ管理テーブルを用いて監視対象か否かを判断することができるので、負荷を低減することができる。

図１４に例示する処理Ａは、Ｅｔｈｅｒフレームが到達する全ＶＮＦに共通的に発生する処理であり、Ｂ処理は監視を担当するＶＮＦのみ発生する処理である。Ｂ処理については、ＶＮＦ単位で負荷分散されるため、高い負荷分散効果が期待できる。Ａ処理については、同一物理ホスト上の全てのＶＮＦで発生するためＶＩＭを構成する物理ホスト単位でしか負荷分散できず、その効果はＢ処理に比べて低い。また、一般に、ユーザドメインで実施される処理はカーネルやハイパーバイザにて処理最適化がされているカーネルドメインの処理に比べて処理性能が低い。このため、負荷分散効果が低いＡ処理のユーザドメイン処理を最小化することで、効果的に負荷を低減することができる。

なお、前述の図６で説明したように、ＥｔｈｅｒＯＡＭフレームを送信したＶＮＦ１０Ａを他のＶＮＦ１０Ｂ、１０ＣがＥｔｈｅｒＯＡＭフレームを受信するので、受信回数が増加し、ＮＩＣの負荷増加が懸念されるが、Ａ処理のユーザドメイン処理の負荷が軽減されているため、結果的に全体の負荷を低減することができる。

また、第１の実施形態に係る監視システム１では、ＯｐｅｎＳｔａｃｋなどの標準的なＶＩＭおよびＶＮＦＭ製品の機能のみを用いて、ＶＮＦのスケールイン・アウトを実現することが可能となり、機能追加が不要となる。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
また、上記実施形態において説明した情報処理装置が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施形態に係る情報処理装置１００が実行する処理をコンピュータが実行可能な言語で記述した監視プログラムを作成することもできる。この場合、コンピュータが監視プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる監視プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された監視プログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。

図１５は、監視プログラムを実行するコンピュータを示す図である。図１５に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図１５に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１５に例示するように、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、図１５に例示するように、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、図１５に例示するように、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、図１５に例示するように、例えばディスプレイ１１３０に接続される。

ここで、図１５に例示するように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の監視プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０９０に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。

なお、監視プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、監視プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

上記の実施形態やその変形は、本願が開示する技術に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ 監視システム
１０、１０Ａ〜１０Ｇ ＶＮＦ
１１ 通信処理部
１２ 制御部
１２ａ 事前設定部
１２ｂ 判定制御部
１２ｃ 監視制御部
１２ｄ 設定制御部
１２ｅ 決定部
１２ｆ 通知部
１２ｇ 更新部
１３ 記憶部
１３ａ 仮想ＭＡＣ管理テーブル記憶部
２０ ＥｔｈｅｒＯＡＭコントローラ
３０ ＳＤＮコントローラ
４０ ＶＮＦＭ
５０ ＶＩＭ
６０、６０Ａ、６０Ｂ アクセス装置
７０ Ｌ２伝送ネットワーク
８０、８０Ａ Ｌ２スイッチ
１００ 情報処理装置

Claims (3)

1. 複数のＶＮＦを動作させる情報処理装置を有する監視システムであって、
   前記情報処理装置は、
   各ＶＮＦが管理する監視対象装置ごとにそれぞれ設定された自ＶＮＦの仮想ＭＡＣアドレスを記憶する記憶部と、
   前記各ＶＮＦが前記監視対象装置から送信されたフレームを受信した場合に、該フレームの送信先ＭＡＣアドレスと前記仮想ＭＡＣアドレスとが一致するＶＮＦについては、前記フレームに含まれる情報を基に前記監視対象装置の通信を監視させるように制御する監視制御部と、
   前記ＶＮＦが前記監視対象装置にフレームを送信する際には、前記記憶部から送信先の監視対象装置に対応するＶＮＦの仮想ＭＡＣアドレスを取得し、該取得した仮想ＭＡＣアドレスを送信元ＭＡＣアドレスに設定するように制御する設定制御部と
   を備えたことを特徴とする監視システム。
2. 複数のＶＮＦを動作させる情報処理装置によって実行される監視方法であって、
   前記情報処理装置は、各ＶＮＦが管理する監視対象装置ごとにそれぞれ設定された自ＶＮＦの仮想ＭＡＣアドレスを記憶する記憶部を有し、
   前記各ＶＮＦが前記監視対象装置から送信されたフレームを受信した場合に、該フレームの送信先ＭＡＣアドレスと前記仮想ＭＡＣアドレスとが一致するＶＮＦについては、前記フレームに含まれる情報を基に前記監視対象装置の通信を監視させるように制御する監視制御工程と、
   前記ＶＮＦが前記監視対象装置にフレームを送信する際には、前記記憶部から送信先の監視対象装置に対応するＶＮＦの仮想ＭＡＣアドレスを取得し、該取得した仮想ＭＡＣアドレスを送信元ＭＡＣアドレスに設定するように制御する設定制御工程と
   を含んだことを特徴とする監視方法。
3. コンピュータを請求項１に記載の情報処理装置として機能させるための監視プログラム。

Images