JP6149444B2

JP6149444B2 - アプリケーション起動制御方法とシステムと装置とプログラム

Info

Publication number: JP6149444B2
Application number: JP2013053647A
Authority: JP
Inventors: 隆史鳥居
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2013-03-15
Filing date: 2013-03-15
Publication date: 2017-06-21
Anticipated expiration: 2033-03-15
Also published as: JP2014178976A

Description

本発明は、アプリケーション起動を制御するアプリケーション起動制御方法とシステムと装置とプログラムに関する。

クラウドシステムの技術が進展し、既存のシステムをクラウド化する動きが出てきている。良く知られているように、クラウドシステムは、例えばインターネットをベースとしたコンピュータの利用形態である。クラウドコンピューティングは、最小の管理エフォット又はサービスプロバイダ相互作用で迅速に提供・リリース可能とされ、構成可能なコンピュータリソース（例えばネットワーク、サーバ、ストレージ、アプリケーション、及びサービス）の共用プールに対するユビキタスな、便利なオン・デマンドアクセスを可能とする１つのモデルである（米国国立標準技術研究所（NIST: National Institute of Standards and Technology）による）。利用者は、インターネット接続環境を備えた携帯端末やＰＣ（Personal Computer）等、最低限の接続環境を用意するだけよく、インターネットの向こう側（データセンター等）からサービスを受けサービス利用料金を払う。

クラウド・コンピューティング・サービスを提供する側（例えばデータセンター等）では、利用者数やデータ数の増減等の変動に対応可能とするため、サーバ仮想化技術が用いられる。サーバ仮想化では、例えばハードウェアとＯＳ（Operating System）間に仮想化レイヤを設け、その上に複数の仮想マシンが実装されハードウェア・リソースの仮想化が行われる。ハードウェア・リソースの仮想化として、例えばＣＰＵ（Central Processing Unit）、メモリデバイス、ネットワークインタフェースデバイス(カード)、ディスク等のハードウェア・リソースを論理的に分割して、仮想マシンを構成する仮想マシンモニタ（Virtual Machine Monitor：ＶＭＭ）が用いられる場合がある。特に制限されないが、仮想マシンモニタ（ＶＭＭ）には、代表的には、
（ａ）ハードウェア上で直接動作するハイパーバイザ（Hypervisor）型仮想マシンモニタ（「ハイパーバイザ」という）と、
（ｂ）サーバのＯＳ上のアプリケーションとして実装されているホストＯＳ型仮想マシンモニタ等がある。

図４は、ハイパーバイザ（Hypervisor）型仮想マシンモニタ構成のサーバ仮想化技術の典型例のうちの一例を模式的に示す図である。図４を参照すると、サーバ１００において、図示されないＣＰＵやメモリや、ネットワークインタフェース（network Interface）等のハードウェア１５０の上にハイパーバイザ型仮想マシンモニタ（「ハイパーバイザ」という）１４０を備えている。ハイパーバイザ１４０の上に仮想マシン（ＶＭ）１１０、１２０（１３０）が実装される。特に制限されないが、複数の仮想マシン（ＶＭ）は、管理ＯＳ用仮想マシン１１０とゲストＯＳ用仮想マシン１２０（１３０）を含む構成としてもよい。なお管理ＯＳ用のドメインは「ドメイン０」とも呼ぶ場合がある。また、例えば業務等を稼動させるドメインは「ゲストドメイン」ともいう。ドメイン０では管理ＯＳ１１１が動作しゲストドメインを管理する。ゲストドメインでは、ゲストＯＳ１２１、１３１が動作する。なお、ゲストＯＳ用仮想マシン（ＶＭ）は２つに限定されるものでないことは勿論である。図４の例では、管理ＯＳ用仮想マシン１１０は、管理ＯＳ１１１を備え、管理ＯＳ１１１はデバイスドライバ１１２を備えている（デバイスドライバ１１２は例えば管理ＯＳ１１１内に実装されるが、図４では、別に示してある）。ゲスト用ＯＳ仮想マシン１２０（１３０）では、ゲストＯＳ１２１（１３１）、仮想デバイスドライバ１２２（１３２）を備え、ゲストＯＳ１２１（１３１）上でアプリケーション１２３（１３３）が実行される。なお、１つのゲスト用ＯＳ仮想マシン１２０（１３０）上で実行されるアプリケーションは１つに限られるものでなく、複数同時並行的に実行される場合もある。また、アプリケーション１２３（１３３）とゲストＯＳ１２１（１３１）の間には、例えばＡＰＩ（Application Interface）等が配置されるが、図４では省略されている。ハイパーバイザ１４０はＣＰＵ、メモリ等のハードウェアリソース（物理的資源）を仮想資源に分割し、仮想資源を単位として、仮想マシンへの仮想化資源の割り当ての制御・管理を行う。仮想マシン（ゲストＯＳ用仮想マシン）１２０（１３０）上で実行されるアプリケーション１２３（１３３）からのデバイスアクセス要求を受けると、ゲストＯＳ１２１（１３１）から仮想デバイスドライバ１２２（１３２）に対してアクセス要求が発行され、仮想デバイスドライバ１２２（１３２）からのアクセス要求はハイパーバイザ１４０を介して、管理ＯＳ用仮想マシン１１のデバイスドライバ１１２に受け渡され、デバイスドライバ１１２からデバイスインタフェース（ＩＦ）１５１に対してアクセス要求が発行される。なお、図４の例では、デバイスドライバ１１２を管理ＯＳ用仮想マシン１１０に備えた構成とされているが、デバイスドライバ１１２をハイパーバイザ１４０内に実装する方式もある。

クラウドシステムにおいて、既存のアプリケーションを仮想マシン（ＶＭ）上で動くようにして、自由に起動・停止することや、仮想マシンモニタ（ＶＭＭ）によりマイグレーション（ある仮想マシンで稼働しているＯＳやソフトウェアを停止させずに、別の物理コンピュータに移動させること）が可能になる。これにより、複数のアプリケーションを複数のＶＭで構成するシステムをクラウドシステムとして実現するケースが、今後さらに増えていくことが予想される。

複数のアプリケーションの組み合わせで構築されるシステムにおいては、複数のアプリケーションの起動順序を決定し、決められた順番で起動することが必要とされる場合が多い。例えばデータベースにアクセスするアプリケーションの場合、当該アプリケーション起動の前にデータベース管理システムが先に起動していることが必要とされる場合がある。データベース管理システムよりも先にアプリケーションが起動し、データベースにアクセスすると、データベースに接続できずにアクセスエラーが発生するためである。この対策として、例えばアプリケーション（ソフトウェア）の開発者が、アプリケーションの単純化のため、アプリケーションの起動の順番は、管理サーバ等で正しく管理することを前提として、データベースが起動していないことを想定して開発する場合がある。

また、大規模な通信サービスシステム、例えばＩＭＳ（Internet Multimedia System）やＥＰＣ（Evolved Packet Core）、ＬＴＥ（Long Term Evolution）等のような通信サービスの場合、多種、多数のアプリケーションの組み合わせでシステムが構築され、密接に関わりつつ動作をしている。

このため、アプリケーションの起動順序を正しく設定されていない場合、所望する動作が保証されないことになる。アプリケーションの起動順序の決定は、例えば人手で行う場合もあるが、エラー等の発生、省力化のため、管理サーバ等でアプリケーションの実行順序を管理する場合もある。

なお、アプリケーションの起動に関連して、特許文献１には、アプリケーションの起動や停止を管理するアプリケーションマネージャと、実際にアプリケーションの制御を行う仮想マシンを有するアプリケーション制御装置において、アプリケーションをローディングするための読込み手段と、前記読込み手段でローディングしたアプリケーションを管理するためのアプリケーション管理手段と、前記アプリケーションに関する情報を記憶するためのアプリケーション情報記憶手段と、前記アプリケーションマネージャが前記仮想マシンとデータや命令の送受信を行うための通信手段とを備えた構成が開示されている。仮想マシン上のアプリケーションの起動制御に関連して、特許文献２には、サーバ上の仮想マシンおよび実行サーバが高負荷である場合に、他のマシンへのアプリケーションのインストールを行い、当該アプリケーションの起動が選択された場合には、新たにインストールしたマシンで、アプリケーションを起動させ、１つのマシンに対して負荷が過度に集中することを防止するアプリケーション管理サーバが開示されている。

また、特許文献３には、各サーバのアプリケーションプロセス間で起動順序がある場合は、先に立ち上がっている必要のあるプロセスを随時監視し、必要なプロセスの起動完了確認後、自身のプロセスを起動する起動用のファイルを用意する必要があるほか、異なるサーバ上のアプリケーションプロセスに対する起動順序制御を行うためには、他サーバ上のアプリケーションプロセスの起動情報を収集するサーバ間通信を行うための起動用のファイルを記述する必要があり、起動用のファイル内に起動制御機能を付与するための開発作業を必要としているという問題に対して、各サーバに配置された起動順序の制御が必要なアプリケーションプロセスについて、あらかじめ起動順序レベルを設定するための起動順序レベル設定手段と、前記各サーバにおける各起動順序レベルごとに、他サーバでの当該起動順序レベルのアプリケーションプロセスの起動完了を、自サーバにおける次の起動順序レベルのアプリケーションプロセスの起動条件として設定するための起動連携条件設定手段と、前記各サーバにおいて、前記起動順序レベル及び前記起動連携条件の情報を参照して、各起動順序レベルごとにアプリケーションプロセスの起動制御を行う起動連携制御手段を備えたシステム、アプリケーションプロセス起動制御方法が開示されている。

なお、後述されるオープンフロー（ＯｐｅｎＦｌｏｗ）については例えば非特許文献１、２等が参照される。

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

Nick McKeownほか７名、"OpenFlow: Enabling Innovation in Campus Networks,"［ｏｎｌｉｎｅ］、［平成２５年１月３１日検索］、インターネット〈URL:http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉 "OpenFlow Switch Specification" Version 1.1.0 Implemented(Wire Protocol 0x02)［ｏｎｌｉｎｅ］、［平成２５年１月３１日検索］、インターネット〈URL:http://www.openflowswitch.org/documents/openflow-spec-v1.1.0.pdf〉

以下に関連技術の分析を与える。

仮想マシン環境において、管理サーバにより仮想マシン上のアプリケーションの起動を制御する場合の問題点について以下に説明する。

図３は、サーバ仮想化のプロトタイプ例を模式的に示す図である。管理サーバ１０が接続する管理系ネットワーク２は、ハイパーバイザ１４０側で接続される。例えば図４の例において、ドメイン０の管理ＯＳ用仮想マシン１１０はハイパーバイザ１４０を介して管理サーバ１０が接続する管理系ネットワーク２に接続される。業務等を稼動させるドメインのゲストＯＳ用仮想マシン１２０（１３０）は、仮想デバイスドライバ１２２（１３２）、ハイパーバイザ１４０、デバイスドライバ１１２を介してデバイスインタフェース１５１にアクセスし、業務系ネットネットワーク１に接続される。図３において２つの仮想マシン（ＶＭ）は、図４のゲストＯＳ用仮想マシン１２０（１３０）に対応し、簡単のため、仮想マシン（ＶＭ）が業務系ネットネットワーク１に接続するものとして図示されている。図４のゲストＯＳ用仮想マシン１２０（１３０）から、図３の管理系ネットワーク２側へのアクセスは、通常は行われない。例えば図４のゲストＯＳ用仮想マシン１２０（１３０）の仮想デバイスドライバ１２２（１３２）は、業務系ネットワーク１のネットワークデバイス（インタフェース）対応とされ、管理系ネットワーク２へのアクセスに対応していないためである。一方、管理ＯＳ用仮想マシン１１０は、管理系ネットワーク２へのアクセスに対応したデバイスドライバを介して、ハイパーバイザ１４０からハードウェア１５０内の対応ネットワークインタフェース等を介して管理系ネットワーク２にアクセス可能とされる。

業務系ネットワーク１は、通常の運用形態では、管理系ネットワーク２とは隔離されている。これは、クラウドシステムのような、マルチテナントのシステムでは。特にセキュリティの低減を回避するためである。管理系ネットワーク２と業務系のネットワーク２の間のセキュリティが脆弱である場合、業務系ネットワーク１から管理系ネットワーク２に侵入することが可能となる。不特定多数のテナントの情報にアクセスされる可能性がある。そのため、図３のようなシステム構成のように、仮想マシン（ＶＭ）からアクセスが行われる業務系ネットワーク１に、仮想マシン上におけるアプリケーションの起動を制御する管理サーバ１０が接続されることは、セキュリティの観点から望ましくない。上記特許文献１−３には、セキュリティに関する上記問題点は開示されていない。

本発明は、上記課題に鑑みて創案されたものであって、その目的は、アプリケーションの起動制御にあたり、セキュリティを確保可能とする装置、方法、システム、プログラムを提供することにある。

本発明に関連するいくつかの側面の１つによれば（視点１）、
コントローラから設定されたパケット転送規則にしたがって入力したパケットを処理するスイッチと、
アプリケーションを実行するアプリケーション実行装置と、
前記アプリケーションの起動を制御するアプリケーション起動制御部と、
を備え、
前記アプリケーション実行装置は、アプリケーションの起動要求信号を、少なくとも前記スイッチを介して、前記アプリケーション起動制御部に送信し、
前記アプリケーション実行装置は、前記アプリケーション起動制御部からのアプリケーション起動許可信号を、少なくとも前記スイッチを介して受けると、アプリケーションを起動する、アプリケーション起動制御システムが提供される。

別の側面の１つによれば（視点２）、
アプリケーション実行装置からのアプリケーション起動要求信号を、コントローラから設定されたパケット転送規則にしたがって入力したパケットを処理するスイッチを少なくとも介して受け取り、
アプリケーションの起動条件にしたがって、アプリケーション起動許可信号を少なくとも前記スイッチを介して、前記アプリケーション実行装置に送信するアプリケーション起動制御装置が提供される。

さらに別の側面の１つによれば（視点３）、
アプリケーション実行装置からのアプリケーション起動要求信号を、コントローラから設定されたパケット転送規則にしたがって入力したパケットを処理するスイッチを少なくとも介して受け取り、
アプリケーションの起動条件にしたがってアプリケーション起動許可信号を少なくとも前記スイッチを介して前記アプリケーション実行装置に送信する処理を、コンピュータに実行させるプログラムが提供される。

別の側面の１つによれば（視点４）、
アプリケーション実行装置からのアプリケーション起動要求信号を、コントローラから設定されたパケット転送規則にしたがって入力したパケットを処理するスイッチを少なくとも介して受け取り、
アプリケーションの起動条件にしたがってアプリケーション起動許可信号を、前記スイッチを介してアプリケーション実行装置に送信するアプリケーション起動制御方法が提供される。

別の側面の１つによれば（視点５）、
コントローラから設定されたパケット転送規則にしたがって入力したパケットを処理するスイッチであって、
アプリケーション実行装置からアプリケーション起動要求信号を受け取り、前記コントローラを介して、前記アプリケーション起動要求信号をアプリケーション起動制御部に送信し、
前記アプリケーション起動制御部からのアプリケーション起動許可信号を、前記コントローラを介して受け取り、前記アプリケーション起動許可信号を前記アプリケーション実行装置に送信するスイッチが提供される。

別の側面の１つによれば（視点６）、
パケット転送規則にしたがって入力したパケットを処理するスイッチを制御するコントローラであって、
アプリケーション実行装置からのアプリケーションの起動要求信号を、前記スイッチを介して受け取ると、前記アプリケーションの起動要求信号をアプリケーション起動制御部に送信し、
前記アプリケーション起動制御部からのアプリケーション起動許可信号を、前記スイッチを介して、前記アプリケーション実行装置に送信するコントローラが提供される。

本発明によれば、アプリケーションの起動制御にあたり、セキュリティを確保可能としている。

実施形態１を模式的に例示する図である。フローエントリの一例を例示する図である。プロトタイプのシステムの模式的に例示する図である。サーバ仮想化の典型例のうちの１つを模式的に例示する図である。発明概念を説明する図である。

本発明の実施形態について説明する。好ましい形態の１つによれば、図５を参照すると、コントローラ（４０）から設定されたパケット転送規則にしたがって、入力パケットを処理するスイッチ（３０）を備え、アプリケーション実行装置（５０）はアプリケーション起動要求信号を、例えば、前記スイッチ（３０）、コントローラ（４０）を介してアプリケーション起動制御部（２１）に送信する。前記アプリケーション起動制御部（２１）は、アプリケーション起動許可信号を、例えば、コントローラ（４０）、スイッチ（３０）を介して、前記アプリケーション実行装置（５０）に送信する。前記アプリケーション実行装置（５０）は、前記アプリケーション起動許可信号を受け、アプリケーションを起動する。

アプリケーション実行装置（５０）は、例えば仮想マシン（ＶＭ）からなる。前記仮想マシンを１つ又は複数を備えたサーバ装置（図１の１１）は、第１のネットワーク（業務系ネットワーク１）と第２のネットワーク（管理系ネットワーク２）に接続され、前記仮想マシン（ＶＭ）と前記スイッチ（３０）は、前記第１のネットワーク（１）に接続され、前記スイッチ（３０）に、前記コントローラ（４０）を介して接続される前記アプリケーション起動制御部（２１）を備えた管理サーバ（例えば図１の２０）が、前記第２のネットワーク（２）に接続される構成としてもよい。

前記スイッチ（３０）は、前記スイッチ（３０）で保持するパケット転送規則に、前記アプリケーション起動要求信号に対応するパケットの転送ルールが設定されていない場合、前記コントローラ（４０）に前記アプリケーション起動要求信号を送信し、前記コントローラ（４０）は、前記前記アプリケーション起動要求信号を前記アプリケーション起動制御部（２１）に送信する構成としてもよい。あるいは、前記コントローラ（４０）は前記アプリケーション起動要求信号を前記スイッチ（３０）に送信し、前記スイッチ（３０）を介して前記アプリケーション起動制御部（２１）に送信する構成としてもよい。なお、前記コントローラ（３０）と、前記アプリケーション起動制御部（２１）を、一つの管理サーバ（制御サーバ）等に実装するようにしてもよい。アプリケーション実行装置（５０）からのアプリケーション起動要求を、コントローラで制御されるスイッチを介して、アプリケーション起動制御部に送信する構成としたことにより、セキュリティの確保を可能としている。なお、スイッチ（３０）、コントローラ（４０）は、後述されるオープンフロースイッチ（ＯＦＳ）、オープンフローコントローラ（ＯＦＣ）で構成してもよい。以下、実施形態に即して説明する。

＜実施形態＞
本実施形態では、アプリケーションの起動順番を自動で確実に制御するために、オープンフロー（ＯｐｅｎＦｌｏｗ）の仕組みを利用する（非特許文献１、２参照）。オープンフロー（ＯｐｅｎＦｌｏｗ）は、通信をエンドツーエンドのフローとして認識し、フロー単位で経路制御等を実施することができる。フローとは、通信の送信元、宛先等に基づいて識別された所定の属性を有する一連の通信パケット群である。オープンフローによるフロー単位の経路制御は、オープンフロースイッチ（ＯｐｅｎＦｌｏｗＳｗｉｔｃｈ：「ＯＦＳ」と略記される）と、オープンフローコントローラ（ＯｐｅｎＦｌｏｗＣｏｎｔｒｏｌｌｅｒ：「ＯＦＣ」と略記される）を備えている。ＯＦＳは、ＯｐｅｎＦｌｏｗ技術を採用したネットワークスイッチであり、ＯＦＣによって設定されたフローテーブルに従って、ＯＦＳを通過する通信パケットに対して、フロー単位の経路制御を行う。フローテーブルの各エントリであるフローエントリは、図２に示すように、ＯＦＳが受信したパケットのヘッダに含まれる情報と照合するためのマッチングルール（Match Field）と、マッチングルールにマッチするパケットの処理方法を規定するインストラクション(Actions：指定ポートからのパケット送信、フラッディング、廃棄等)と、受信パケット数（バイト）等の統計情報(Counters)を一エントリとして含む。オープンフローのヘッダ情報として、入力ポート、宛先ＭＡＣ（Media Access Control）アドレス)、送信元ＭＡＣアドレス、Ether Type（Ethernet（登録商標） Type）、VLAN(Virtual Local Area Network) ID、VLAN PCP(Priority Code Point）、宛先ＩＰアドレス、送信元ＩＰアドレス、ＩＰプロトコル、TOS(Type of Service)、送信元ポート番号と宛先ポート番号（例えばTCP(Transmission Control Protocol)やUDP(User Datagram Protocol)のポート番号）が含まれる。これらのフィールドの組み合わせでフローが定義される。

ＯＦＳは、パケットを受信するとフローテーブルを参照し、受信したパケットのヘッダ情報にマッチするフローエントリを検索する。フローエントリ内にマッチするエントリが存在する場合は、マッチしたエントリに含まれるインストラクションに従って、受信パケットの処理を行う。

マッチするエントリが存在しなかった場合は、パケットイン（Ｐａｃｋｅｔ−Ｉｎ）メッセージで受信パケットをＯＦＣにセキュアチャネルを用いて送信し、ＯＦＣに受信パケットの処理方法を規定したフローエントリの設定を要求する。

ＯＦＣは、ネットワークトポロジ情報から当該受信パケットの転送経路を計算し、経路上のＯＦＳに対してフローエントリを設定するメッセージ（ＦｌｏｗＭｏｄｉｆｙ）を送信し、パケット転送を指示するパケットアウト（Ｐａｃｋｅｔ−Ｏｕｔ）メッセージを経路上の該当するＯＦＳに送信し、該当するＯＦＳは、受信パケットをフローエントリに従って転送する。

図１を参照すると、アプリケーションを起動する前に、予め定められた宛先に対して、予め定められたフォーマットのパケット（「アプリケーション起動リクエスト」という）を送信し、応答（「アプリケーション起動許可」という）を待つ。

このパケットは、ＯＦＳ３０に届き、新規フローであるため、Ｐａｃｋｅｔ−ＩｎメッセージでＯＦＣ４０に送信される。Ｐａｃｋｅｔ−Ｉｎメッセージを受信したＯＦＣ４０は、パケットを解析し、アプリケーション起動制御部２１宛てのアプリケーション起動リクエストであることを検出すると、アプリケーション起動制御部２１に転送する。

アプリケーション起動制御部２１は、ＯＦＣ４０からアプリケーション起動リクエストを受け取り、アプリケーション起動リクエストに対して、当該アプリケーションが起動してよい条件を満たすと（例えば起動してよいタイミングになったら）、アプリケーション起動許可パケットを送信し、要求元の仮想マシン（ＶＭ）に対してアプリケーションの起動を許可する。アプリケーション起動制御部２１において、他のノード（例えば同一サーバの他の仮想マシン又は他のサーバの仮想マシン（ＶＭ））のアプリケーションの起動を待ち合わせる場合には、アプリケーション起動許可の送信を待ち合わせることにより、ノードのアプリケーション起動を抑制する。Ｐａｃｋｅｔ−Ｉｎメッセージを用いることで、業務系のネットワーク２から管理系に情報を渡しており、セキュリティ対策を確保することができる。

本実施形態において、仮想マシン（ＶＭ）は、管理系ネットワーク２には、通常、接続されない。仮想マシン（ＶＭ）から管理系ネットワーク２へのアクセスは行われない。アプリケーションの起動制御を、管理サーバ２０から行うためには、管理サーバ２０と業務系ネットワーク１を接続する必要がある。業務系ネットワーク１から管理系ネットワーク２へ接続するパスを設けると、前記したように、セキュリティ上に問題が生じる。そこで、実施形態では、業務系ネットワーク１にＯＦＳ３０を設置し、ＯＦＳ３０とＯＦＣ４０のＯｐｅｎＦｌｏｗネットワークを経由して管理サーバ２０と通信する。

実施形態の動作を説明する。まず、サーバ１１の仮想マシン（ＶＭ）は起動スクリプトを順番に実行していく際に、起動スクリプトの実行前にアプリケーション起動リクエストを、予め指定されたアドレス（宛先ＩＰアドレス）に、指定されたフォーマットで送信しアプリケーション起動許可の受信を待ち合わせる。

アプリケーション起動リクエストパケットは、ＯＦＳ３０からＰａｃｋｅｔ−Ｉｎメッセージにてセキュアチャネルを用いてＯＦＣ４０に送信される。

ＯＦＣ４０は、Ｐａｃｋｅｔ−ＩｎメッセージにてＯＦＳ３０から送信されたアプリケーション起動リクエストパケットを解析し、管理サーバ２０のアプリケーション起動制御部２１宛てのアプリケーション起動リクエストであると判別すると、当該パケットを、アプリケーション起動制御部２１に送信する。ＯＦＣ４０は、業務ネットワーク１側からＯＦＳ３０のＰａｃｋｅｔ−ＩｎでＯＦＣ４０に転送されたパケットのうち、仮想マシン（ＶＭ）のアプリケーション起動要求等アプリケーション制御に関連する予め定められた正規のパケット以外は廃棄する等、フィルタリングを行うようにしてもよい。これにより、業務ネットワーク１側から管理サーバ２０等の情報を盗み取るアクセス攻撃に対するセキュリティを確保可能としている。

アプリケーション起動制御部２１は、当該アプリケーションを起動するための前提条件が全てそろっているかをチェックする。他の仮想マシン（ＶＭ）においてそのアプリケーションが起動する前に起動を完了していなければならないアプリケーションやモジュールがすでに起動しているかのチェック、あるいは、当該アプリケーションが起動するだけではなく、ある処理が完了していることをチェックする等、必要なチェックを行う。

アプリケーション起動制御部２１は、アプリケーションを起動してよいことを確認すると、仮想マシン（ＶＭ）に対して、アプリケーション起動許可パケットを送信する。例えば、ＯＦＣ４０は、アプリケーション起動許可パケットをＰａｃｋｅｔ−ＯｕｔメッセージでＯＦＳ３０に送信する。Ｐａｃｋｅｔ−Ｏｕｔメッセージを受けたＯＦＳ３０は、アプリケーション起動許可パケットを、業務系ネットワーク１を介して仮想マシン（ＶＭ）に送信する。仮想マシン（ＶＭ）は、アプリケーション起動許可パケットを受信すると、アプリケーション起動を実行する。そして、アプリケーション起動が終了した時点で、アプリケーション起動完了パケットを送信する。

これにより、他の仮想マシン（ＶＭ）のアプリケーション起動をブロックしないようにする。アプリケーションの起動スクリプトが、プロセスの起動を指示するだけで、完了は待ち合わせていない場合もあり得る。そのような場合、アプリケーションが確実に起動したことを別の方法で確認する必要がある。アプリケーションが起動したことをモニタリング等で観測するか、アプリケーション自体が、自分が起動したことを通知する機構を実装する。

仮想マシン（ＶＭ）上で実行されるアプリケーションの起動確認をアプリケーション毎に行うと、大規模システムでは、管理サーバやアプリケーション起動制御部２１に負荷がかかる可能性がある。このため、アプリケーション個別ではなく、いくつかのアプリケーションをまとめて扱うようにしてもよい。起動スクリプトが、例えばＩｎｉｔディレクトリ（例えばＬｉｎｕｘ（登録商標）では、ディレクトリetc/rc.d/init.d）のサブディレクトリＩｎｉｔ０、Ｉｎｉｔ１、Ｉｎｉｔ２に複数スクリプトをまとめて設定するようにしてもよい。グループ化して起動順の制御を行うようにしてもよい。拠点間でアプリケーションを移動させる場合、データの移動を抑えることができる。

本実施形態によれば、ＯｐｅｎＦｌｏｗの仕組みを、アプリケーション（業務系アプリケーション）の起動制御システムに活用することで、業務系ネットワーク１側から管理サーバ２０や管理系ネットワーク２等に対する不正アクセスや攻撃等への保護等セキュリティの確保を可能としている。

なお、図１では、ＯＦＣ４０から、管理サーバ２０のアプリケーション起動部２１宛てにアプリケーション起動リクエストパケットを送信しているが、かかる構成に制限されるものでないことは勿論である。例えばＯＦＣ４０は、ＯＦＳ３０からのＰａｃｋｅｔ−Ｏｕｔメッセージを受け、経路計算を実行してアプリケーション起動リクエストパケットのパケットフローを決定し、フロー修正（ＦｌｏｗＭｏｄｉｆｙ）メッセージ等をＯＦＳ３０に送信しＯＦＳ３０内のフローエントリを設定する。ＯＦＣ４０は、アプリケーション起動リクエストパケットをＰａｃｋｅｔ−ＯｕｔメッセージにてＯＦＳ３０に送信し（パケット転送を指示する）、ＯＦＳ３０から、該アプリケーション起動リクエストパケットを管理サーバ２０のアプリケーション起動部２１に送信するようにしてもよい。あるいは、ＯＦＳ３０とは別のＯＦＳ（不図示）が管理サーバ２０に最も近く接続している場合、Ｐａｃｋｅｔ−Ｏｕｔメッセージを別のＯＦＳに送信し、別のＯＦＳを介して、該アプリケーション起動リクエストパケットを管理サーバ２０のアプリケーション起動部２１に送信するようにしてもよい。

また、図１では、管理サーバ２０とＯＦＣ４０を別々のノードとして構成した例を示しているが、管理サーバ２０内にＯＦＣ４０を備えた構成としてもよい。

上記実施形態では、サーバ仮想化技術として、仮想マシンモニタとしてハイパーバイザを用いた例を説明したが、ホストＯＳ型の仮想マシンにも適当可能であることは勿論である。

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

１業務系ネットワーク
２管理系ネットワーク
１０、２０管理サーバ（制御サーバ）
１１、１００サーバ
２１アプリケーション起動制御部
３０スイッチ（ＯＦＳ）
４０コントローラ（ＯＦＣ）
５０アプリケーション実行装置（仮想マシン：ＶＭ）
１１０管理ＯＳ用仮想マシン（ＶＭ）
１１１管理ＯＳ
１１２デバイスドライバ
１２０、１３０ゲストＯＳ用仮想マシン（ＶＭ）
１２１、１３１ゲストＯＳ
１２２、１３２仮想デバイスドライバ
１２３、１３３アプリケーション
１４０ハイパーバイザ
１５０ハードウェア
１５１デバイスインタフェース（ＩＦ）

Claims

コントローラと、
前記コントローラが設定したパケット転送規則にしたがって受信したパケットを処理するスイッチと、
アプリケーションの実行を制御するアプリケーション制御部を有する管理サーバと、
前記アプリケーションを実行するアプリケーション実行装置を有するサーバ装置と、
を備え、
前記スイッチは、前記アプリケーション実行装置が前記管理サーバ宛てに送信したパケットを前記コントローラへ送信し、
前記コントローラは、受信した前記パケットがアプリケーション起動要求信号であると検出した場合に、前記受信したパケットを前記管理サーバへ送信する、アプリケーション起動制御システム。
前記コントローラは、アプリケーションの制御に関連するパケット以外の受信パケットを廃棄する、請求項１に記載のアプリケーション起動制御システム。
前記コントローラは、前記管理サーバから受信したアプリケーション起動許可信号であるパケットを、前記スイッチへ送信し、
前記スイッチは、前記アプリケーション起動許可信号であるパケットを、前記アプリケーション実行装置へ送信する、請求項１又は２に記載のアプリケーション起動制御システム。
前記管理サーバは、前記コントローラを介して前記スイッチと接続する請求項１乃至３のいずれか１項に記載のアプリケーション起動制御システム。
前記アプリケーション実行装置は仮想マシンであり、
前記サーバ装置は、１つ又は複数の前記仮想マシンと、ハイパーバイザと、を有し、
前記仮想マシンと、前記スイッチと、が第１のネットワークに接続し、
前記サーバ装置の前記ハイパーバイザと、前記管理サーバとが、第２のネットワークに接続する、請求項１乃至４のいずれか１項に記載のアプリケーション起動制御システム。
前記第１のネットワークが業務系のネットワークであり、
前記第２のネットワークが管理系のネットワークである、請求項５に記載のアプリケーション起動制御システム。
前記スイッチは、
前記アプリケーション実行装置から受信したパケットの転送ルールがパケット転送規則に設定されていない場合に、受信したパケットを、前記コントローラへ新規パケット入力を通知するメッセージで送信する、請求項１乃至６のいずれか１項に記載のアプリケーション起動制御システム。
前記コントローラは、
前記管理サーバから受信したパケットを、パケット転送を指示するメッセージで前記スイッチに送信する、請求項３に記載のアプリケーション起動制御システム。
アプリケーション実行装置が送信したパケットを、パケット転送規則にしたがって受信したパケットを処理するスイッチを介して受信し、
受信した前記パケットを解析し、
受信したパケットがアプリケーション起動要求信号であると検出した場合に、アプリケーションの実行を制御する管理サーバへ送信する処理を、コンピュータに実行させるプログラム。
受信したパケットをパケット転送規則にしたがって処理するスイッチを制御するコントローラが実行するアプリケーション起動制御方法であって、
アプリケーション実行装置が送信したパケットを、前記スイッチを介して受信し、
受信した前記パケットを解析し、
受信したパケットがアプリケーション起動要求信号であると検出した場合に、アプリケーションの実行を制御する管理サーバへ送信する、アプリケーション起動制御方法。
アプリケーションの制御に関連するパケット以外の受信パケットを廃棄する、請求項１０に記載のアプリケーション起動制御方法。
パケット転送規則にしたがって受信したパケットを処理するスイッチを制御するコントローラであって、
アプリケーション実行装置が送信したパケットを、前記スイッチを介して受信し、
受信した前記パケットを解析し、
受信したパケットがアプリケーション起動要求信号であると検出した場合に、アプリケーションの実行を制御する管理サーバへ送信する、コントローラ。