(57)【要約】【課題】仮想マシンを動作させる仮想化通信装置において、物理ポートについての個別のハードウェアに依存する情報に起因した管理コストを削減すること。【解決手段】物理マシン１は、通信インタフェースであるＮＩＣポート５０と、物理マシン１内で動作する仮想マシン１０から仮想的な通信インタフェースとして認識される仮想ＩＦ２１と、各仮想マシン１０と各キュー５１との間のパケット転送処理を行うキュー抽象化プロセス２２とを有する。キュー抽象化プロセス２２は、キュー５１との間のパケット転送処理を行うためのＮＩＣポート５０のハードウェアに依存するキュー側ドライバ３６ｂと、仮想ＩＦ２１を介して仮想マシン１０との間のパケット転送処理を行うためのＮＩＣポート５０のハードウェアに依存しないＩＦ側ドライバ３６ａとを有する。【選択図】図２
2019062491.tif 000002
【特許請求の範囲】
【請求項１】
仮想化通信装置内で動作する仮想マシンごとにその仮想マシンに対して送受信するパケットを格納するためのパケットバッファを備え、前記仮想化通信装置内にハードウェアとして搭載される通信インタフェースである物理ポートと、
前記仮想化通信装置内で動作する前記仮想マシンから仮想的な通信インタフェースとして認識される仮想ＩＦと、
前記各仮想マシンと前記各パケットバッファとの間のパケット転送処理を行うポート抽象化プロセスとを有しており、
前記ポート抽象化プロセスは、前記パケットバッファとの間のパケット転送処理を行うための前記物理ポートのハードウェアに依存するポート側ドライバと、前記仮想ＩＦを介して前記仮想マシンとの間のパケット転送処理を行うための前記物理ポートのハードウェアに依存しないＩＦ側ドライバとを有することを特徴とする
仮想化通信装置。
【請求項２】
前記各仮想マシンは、自身のパケット転送処理を担当する前記ポート抽象化プロセスおよび前記仮想ＩＦを、他の前記仮想マシンとは別々に構成することを特徴とする
請求項１に記載の仮想化通信装置。
【請求項３】
前記物理ポートは、自身の前記物理ポート内に到着したパケットのアドレス情報と、アドレステーブルに登録されている前記仮想マシンごとの固有のアドレス情報とを照合することで、到着したパケットを前記各パケットバッファに振り分けるためのアドレス照合部を有することを特徴とする
請求項１に記載の仮想化通信装置。
【請求項４】
前記仮想化通信装置は、さらに、前記ポート抽象化プロセスごとに設定される前記仮想マシンごとの固有のアドレス情報を、前記物理ポートの外部から前記アドレステーブルに登録するためのテーブル設定部を有することを特徴とする
請求項３に記載の仮想化通信装置。
【請求項５】
仮想化通信装置は、
前記仮想化通信装置内で動作する仮想マシンごとにその仮想マシンに対して送受信するパケットを格納するためのパケットバッファを備え、前記仮想化通信装置内にハードウェアとして搭載される通信インタフェースである物理ポートと、
前記仮想化通信装置内で動作する前記仮想マシンから仮想的な通信インタフェースとして認識される仮想ＩＦと、
前記各仮想マシンと前記各パケットバッファとの間のパケット転送処理を行うポート抽象化プロセスとを有しており、
前記ポート抽象化プロセスは、前記パケットバッファとの間のパケット転送処理を行うための前記物理ポートのハードウェアに依存するポート側ドライバと、前記仮想ＩＦを介して前記仮想マシンとの間のパケット転送処理を行うための前記物理ポートのハードウェアに依存しないＩＦ側ドライバとを用いて、パケット転送処理を行うことを特徴とする
仮想化通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化通信装置、および、仮想化通信方法の技術に関する。
【背景技術】
【０００２】
仮想化技術を使ってネットワーク機能を物理マシン上に構築するＮＦＶ（Network Functions Virtualization）という取り組みがなされている。専用ハードウェアで実現されてきた機能を仮想化技術によりソフトウェアとして動作させることで、汎用性を高め、柔軟なシステム構築ができる。
なお、物理マシン上に構築された仮想マシンであるＶＭ（Virtual Machine）が行う通信として、同じ物理マシン上の他のＶＭとの間の通信（ＶＭ−ＶＭ間通信）や、物理マシンに搭載されるＮＩＣ（Network Interface Card）を経由する他の物理マシンとの間の通信（ＮＩＣ−ＶＭ間通信）などが挙げられる。これらの通信でのパケット転送には、仮想マシン間連携技術であるＩＶＣ（Inter-VM Communication）が利用される。
【０００３】
図４は、ＩＶＣを適用した物理マシンの構成図である。
物理マシン１０１は、２台の仮想マシン１１０（１１０−１，１１０−２）と、ＩＶＣ１２０と、２つのＮＩＣポート１５０とを有する。ＩＶＣ１２０は、仮想マシン１１０間の通信や、仮想マシン１１０とＮＩＣポート１５０を介した他装置との間の通信を仲介するスイッチング機能を有する。例えば、図４では、ＮＩＣポート１５０から入力されたパケットが、ＩＶＣ１２０を経由して、仮想マシン１１０−１に到着する流れを太線矢印で示している。
【０００４】
また、物理マシン１０１内のハードウェアで構成された機能部と、ソフトウェアで構成された機能部とを区別するため、ハードウェアで構成された機能部（ＮＩＣポート１５０）を太線で囲んでいる。
以下、図４に示したＩＶＣ１２０の実現方式の詳細として、非特許文献１，２に記載の仮想スイッチ方式を図５で説明し、非特許文献３〜５に記載のＳＲ−ＩＯＶ（Single Root I/O Virtualization）方式を図６で説明する。
【０００５】
図５は、仮想スイッチ方式の構成図である。
物理マシン１０２内の２つの仮想ＩＦ１２１（１２１−１，１２１−２）と、スイッチング部１４６とを備える仮想スイッチが図４のＩＶＣ１２０に相当する。各仮想ＩＦ１２１は、それぞれ送受信を担当する仮想マシン１１０と１：１で対応付けられている。例えば、仮想マシン１１０−１と仮想ＩＦ１２１−１とが対応し、仮想マシン１１０−２と仮想ＩＦ１２１−２とが対応する。
【０００６】
図５の太線矢印で示すように、物理マシン１０２は、ＮＩＣポート１５０で受信したパケットをスイッチング部１４６で一度終端する。そして、スイッチング部１４６は、終端したパケット内のトラフィックを、仮想マシン１１０の識別子（ＭＡＣアドレスなど）によって仮想マシン１１０に振り分ける処理をソフトウェア的に行う。
なお、図示は省略したが、仮想マシン１１０からＮＩＣポート１５０経由で他装置に送信するパケットや、同じ物理マシン１０２の内部で折り返される仮想マシン１１０−１と１１０−２との間のパケットも同様に、スイッチング部１４６によりソフトウェア的に振り分けられる。
【０００７】
スイッチング部１４６は、アドレス学習部１４２と、アドレステーブル１４３と、アドレス照合部１４４とを有する。アドレステーブル１４３には、仮想マシン１１０ごとのＭＡＣアドレスが登録される。アドレス照合部１４４は、到着したパケットのヘッダに記載されるアドレス情報とアドレステーブル１４３とを照合して（アドレスマッチングして）、パケットの転送先を決定する。アドレス学習部１４２は、スイッチング部１４６を通過するパケットのヘッダに記載されるアドレス情報に応じて、アドレステーブル１４３に登録するＭＡＣアドレスの情報を更新する。
【０００８】
図６は、ＳＲ−ＩＯＶ方式の構成図である。
物理マシン１０３内のＮＩＣポート１５０に、図４のＩＶＣ１２０に相当する機能がハードウェアとして搭載されている。物理的に１つのＮＩＣポート１５０は、ハードウェアの機能を用いて複数の論理的なポート単位であるＶＦ（Virtual Function）１５５に分割される。
ＮＩＣポート１５０は、２つのＶＦ１５５（１５５−１，１５５−２）と、スイッチング部１５６とを備える。各ＶＦ１５５は、それぞれ送受信を担当する仮想マシン１１０内のＶＦドライバ１１１と１：１で対応付けられている。例えば、仮想マシン１１０−１内のＶＦドライバ１１１−１とＶＦ１５５−１とが対応し、仮想マシン１１０−２内のＶＦドライバ１１１−２とＶＦ１５５−２とが対応する。つまり、図５の仮想スイッチのような仮想化層を介さずに、各ＶＦ１５５は対応付けられている仮想マシン１１０と直接接続する。
【０００９】
スイッチング部１５６は、図５のスイッチング部１４６の機能をハードウェア的に実現したものである。つまり、アドレス学習部１４２の機能を有するアドレス学習部１５２と、アドレステーブル１４３の機能を有するアドレステーブル１５３と、アドレス照合部１４４の機能を有するアドレス照合部１５４とが、それぞれスイッチング部１５６に備えられている。スイッチング部１５６により、ＭＡＣアドレスによるトラフィックの振り分けがハードウェア的に可能となる。
【００１０】
なお、ＮＩＣポート１５０内のアドレステーブル１５３は、アドレス学習部１５２による学習で更新する方法だけでなく、ＮＩＣポート１５０の外部から直接アドレステーブル１５３の内容を更新できるようなしくみも提案されている。
例えば、非特許文献６，７に記載の「Generic Flow API」は、Intel社が提供するＤＰＤＫ（Data Plane Development Kit）という通信高速化技術において、アドレステーブル１５３（Flow Table）の制御を外部から可能とするための仕様である。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】Ben Pfaff他、「The Design and Implementation of Open vSwitch.」、In: NSDI. 2015. p.117-130.
【非特許文献２】Reza Rahimi他、「A High-Performance OpenFlow Software Switch」、In: High Performance Switching and Routing (HPSR)、 2016 IEEE 17th International Conference on. IEEE 2016. p.93-99.
【非特許文献３】PCI-SIG、「Single Root I/O Virtualization and Sharing Specification Revision 1.0」、［online］、2007年9月11日、［2017年9月15日検索］、インターネット＜URL：http://pcisig.com/single-root-io-virtualization-and-sharing-specification-revision-10＞
【非特許文献４】Intel、「PCI-SIG Single Root I/O Virtualization (SR-IOV) Support in Intel Virtualization Technology for Connectivity」、［online］、［2017年9月15日検索］、インターネット＜URL：https://www.intel.com/content/dam/doc/white-paper/pci-sig-single-root-io-virtualization-support-in-virtualization-technology-for-connectivity-paper.pdf＞
【非特許文献５】Yaozu Dong他、「High Performance Network Virtualization with SR-IOV」、 Journal of Parallel and Distributed Computing 2012 72.11: 1471-1480.
【非特許文献６】Intel、「Intel Ethernet Flow Director」、［online］、［2017年9月15日検索］、インターネット＜URL：https://www.intel.co.jp/content/www/jp/ja/ethernet-products/ethernet-flow-director-video.html＞
【非特許文献７】DPDK（Data Plane Development Kit）、「9. Generic flow API (rte_flow)」、［online］、［2017年9月15日検索］、インターネット＜URL：http://dpdk.org/doc/guides/prog_guide/rte_flow.html＞
【発明の概要】
【発明が解決しようとする課題】
【００１２】
図５の仮想スイッチ方式よりも図６のＳＲ−ＩＯＶ方式のほうが、ＮＩＣポート１５０内のハードウェアにパケット転送処理を負担させるために、一般的に性能は向上する。
【００１３】
一方で、図６のＳＲ−ＩＯＶ方式では、ハードウェアのＮＩＣポート１５０は複数のベンダにより提供されるので、それぞれのベンダの実装により個別のハードウェアに依存したＶＦドライバ１１１が必要になる。そのため、仮想マシン１１０上でアプリケーションソフトを動作させる運用者にとっては、個別のハードウェアに依存したＶＦドライバ１１１を意識する必要が生じてしまう。
そのため、仮想マシン１１０というハードウェアの依存情報が隠蔽される抽象的な動作環境の特性を活かして、特定の個別のハードウェアに依存する情報を運用者に意識させないことで、運用者の管理コストを削減することが求められる。
【００１４】
そこで、本発明は、仮想マシンを動作させる仮想化通信装置において、物理ポートについての個別のハードウェアに依存する情報に起因した管理コストを削減することを、主な課題とする。
【課題を解決するための手段】
【００１５】
前記課題を解決するために、本発明の仮想化通信装置は、以下の特徴を有する。
本発明は、仮想化通信装置内で動作する仮想マシンごとにその仮想マシンに対して送受信するパケットを格納するためのパケットバッファを備え、前記仮想化通信装置内にハードウェアとして搭載される通信インタフェースである物理ポートと、
前記仮想化通信装置内で動作する前記仮想マシンから仮想的な通信インタフェースとして認識される仮想ＩＦと、
前記各仮想マシンと前記各パケットバッファとの間のパケット転送処理を行うポート抽象化プロセスとを有しており、
前記ポート抽象化プロセスが、前記パケットバッファとの間のパケット転送処理を行うための前記物理ポートのハードウェアに依存するポート側ドライバと、前記仮想ＩＦを介して前記仮想マシンとの間のパケット転送処理を行うための前記物理ポートのハードウェアに依存しないＩＦ側ドライバとを有することを特徴とする。
【００１６】
これにより、ポート側ドライバの側で個別のハードウェアに依存する情報が吸収されることで、仮想ＩＦおよびＩＦ側ドライバは、個別のハードウェアに依存しない一般的な通信デバイスとして、仮想マシンから利用することができる。よって、仮想マシンの運用者は、仮想マシンを動作させる仮想化通信装置の物理ポートについての個別のハードウェアに依存する情報を意識しなくても済むため、個別のハードウェアに依存する情報に起因した管理コストを削減することができる。
【００１７】
本発明は、前記各仮想マシンが、自身のパケット転送処理を担当する前記ポート抽象化プロセスおよび前記仮想ＩＦを、他の前記仮想マシンとは別々に構成することを特徴とする。
【００１８】
これにより、１台の物理マシン内で複数の仮想マシンが動作する場合でも、ポート抽象化プロセスと仮想ＩＦとの組が仮想マシンごとに複数組用意される。よって、複数のポート抽象化プロセスがそれぞれ独立にパケット転送処理を行うため、処理負荷が適切に分散される。
【００１９】
本発明は、前記物理ポートが、自身の前記物理ポート内に到着したパケットのアドレス情報と、アドレステーブルに登録されている前記仮想マシンごとの固有のアドレス情報とを照合することで、到着したパケットを前記各パケットバッファに振り分けるためのアドレス照合部を有することを特徴とする。
【００２０】
これにより、パケット転送処理のうちの主要かつ負荷が高いアドレス照合処理を、物理ポートというハードウェア内に設けられたアドレス照合部にオフロードさせることで、転送性能を向上させることができる。
【００２１】
本発明は、前記仮想化通信装置が、さらに、前記ポート抽象化プロセスごとに設定される前記仮想マシンごとの固有のアドレス情報を、前記物理ポートの外部から前記アドレステーブルに登録するためのテーブル設定部を有することを特徴とする。
【００２２】
これにより、物理ポートの内部構成として、アドレステーブルを更新するためのラーニング機能を設ける必要がなくなったため、物理ポートに求められる機能の簡素化により、ハードウェアの汎用性が向上する。
【発明の効果】
【００２３】
本発明によれば、仮想マシンを動作させる仮想化通信装置において、物理ポートについての個別のハードウェアに依存する情報に起因した管理コストを削減することができる。
【図面の簡単な説明】
【００２４】
【図１】本実施形態に係わる仮想化通信装置として動作する物理マシンの構成図である。
【図２】本実施形態に係わる図１の物理マシンの詳細な構成図である。
【図３】本実施形態に係わるキュー抽象化プロセスの動作を示すフローチャートである。
【図４】ＩＶＣを適用した物理マシンの構成図である。
【図５】仮想スイッチ方式の構成図である。
【図６】ＳＲ−ＩＯＶ方式の構成図である。
【発明を実施するための形態】
【００２５】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２６】
図１は、仮想化通信装置として動作する物理マシン１の構成図である。
物理マシン１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
また、この図１で示した物理マシン１を複数台接続した通信システムを構築することも可能である。
【００２７】
物理マシン１は、以下の３階層でそれぞれの機能を分担している。
（１）仮想ゲスト層として、３台の仮想マシン１０（１０−１，１０−２，１０−３）が存在する。
（２）仮想ホスト層として、１台の仮想マシン１０に対して、１つの仮想ＩＦ２１と、その仮想ＩＦ２１と接続するキュー抽象化プロセス（ポート抽象化プロセス）２２とが存在する。
（３）ハードウェア層として、１台の仮想マシン１０に対して、１つのキュー（パケットバッファ）５１が存在し、そのキュー５１はいずれかのＮＩＣポート（物理ポート）５０内に形成される。なお、キュー５１とは、仮想マシン１０に対して送受信するパケットを一時的に格納するパケットバッファであり、例えば、リングバッファなどにより実装される。
【００２８】
仮想マシン１０と、仮想ＩＦ２１と、キュー抽象化プロセス２２と、キュー５１とは１：１対応である。例えば、仮想マシン１０−１に対して、仮想ＩＦ２１−１と、キュー抽象化プロセス２２−１と、キュー５１−１とが対応付けられる（太線矢印）。
同様に、仮想マシン１０−２に対して、仮想ＩＦ２１−２と、キュー抽象化プロセス２２−２と、キュー５１−２とが対応付けられる（破線矢印）。さらに、仮想マシン１０−３に対して、仮想ＩＦ２１−３と、キュー抽象化プロセス２２−３と、キュー５１−３とが対応付けられる（破線矢印）。
ここで、キュー５１−１とキュー５１−２とは、第１のＮＩＣポート５０−１内に用意され、キュー５１−３は、第２のＮＩＣポート５０−２内に用意される。このように、各キュー５１が属するＮＩＣポート５０は、物理マシン１内のどのＮＩＣポート５０であってもよい。
【００２９】
図１では、ＮＩＣポート５０−１が受信したパケットを、仮想マシン１０−１に転送するまでの経路を太線矢印で例示した。以下、この経路に沿って説明する。
まず、ＮＩＣポート５０内のアドレス照合部５４は、アドレステーブル５３を参照して、受信したパケットをどのキュー５１に格納するかを決定する。つまり、別々の仮想マシン１０に対して送受信するパケットは、別々のキュー５１に格納される。
ここで、図６のＮＩＣポート１５０で使用されていたスイッチング部１５６（アドレス照合部１５４、アドレステーブル１５３）の構成を、図１の物理マシン１のＮＩＣポート５０に流用してもよい。つまり、物理マシン１は、図６のアドレステーブル１５３を図１のアドレステーブル５３として用い、図６のアドレス照合部１５４を図１のアドレス照合部５４として用いる。
これにより、転送パケットのアドレスマッチング処理をハードウェア（アドレス照合部５４）にオフロードさせる（逃がす）ことで、パケット転送処理のスループット性能を向上させることができる。
【００３０】
次に、キュー５１−１に格納されたパケットは、キュー５１−１に対応するキュー抽象化プロセス２２−１内のキュー側ドライバ３６ｂ−１に転送される。キュー側ドライバ（ポート側ドライバ）３６ｂは、対応するキュー５１との間でパケットの送受信を行うためのドライバであり、キュー５１を収容するＮＩＣポート５０のハードウェアに依存してあらかじめ用意される。
パケット転送部３６は、ＩＦ側ドライバ３６ａとキュー側ドライバ３６ｂとの間でパケットを転送する処理部である。図１では、パケット転送部３６−１は、キュー側ドライバ３６ｂ−１から受信したパケットを、ＩＦ側ドライバ３６ａ−１に転送する。
【００３１】
ＩＦ側ドライバ３６ａは、対応する仮想マシン１０との間でパケットの送受信を行うためのドライバであり、ＮＩＣポート５０のハードウェアには非依存の（一般的な）ドライバである。図１では、ＩＦ側ドライバ３６ａ−１は、仮想ＩＦ２１−１を介して対応する仮想マシン１０−１にパケットを転送する。
このように、仮想マシン１０と物理デバイスであるＮＩＣポート５０との間にキュー抽象化プロセス２２を用意し、各キュー抽象化プロセス２２に仮想ＩＦ２１を用意することでハードウェアの抽象化レベルを上げ、仮想マシン１０のハードウェア依存性を軽減させることができる。
【００３２】
図２は、図１の物理マシン１の詳細な構成図である。
物理マシン１のキュー抽象化プロセス２２は、図１で示したＩＦ側ドライバ３６ａとパケット転送部３６とキュー側ドライバ３６ｂとに加え、設定入力部３１と、設定リスト３２と、アドレス作成部３３と、ドライバ作成部３４と、仮想ＩＦ作成部３５と、キュー探索部３７と、ＮＩＣ設定部３８とを有する。
さらに、物理マシン１の前記した（２）仮想ホスト層として、キュー管理テーブル２３とテーブル設定ＡＰＩ（テーブル設定部）２４とが存在する。
【００３３】
設定入力部３１は、管理者から入力された自身が属するキュー抽象化プロセス２２についての設定内容を設定リスト３２として保存する。以下が、設定リスト３２の一例である。
（設定１）自身のID番号。例えば、自身のキュー抽象化プロセス２２が「3」番であることを示す内容として、「“id”: 3」が設定リスト３２に登録される。
（設定２）自身のキュー抽象化プロセス２２に対応するＮＩＣポート５０およびキュー５１の情報。例えば「0」番のＮＩＣポート５０内の「1」番のキュー５１を使用するときには、「“nic”:{“port”: 0, “queue”: 1}」が設定リスト３２に登録される。
（設定３）自身のキュー抽象化プロセス２２に対応する仮想ＩＦ２１および仮想マシン１０の情報。例えばＭＡＣアドレス「A0-B1-C3-A4-B5-C6」の仮想ＩＦ２１（vNICポート）をディレクトリパス「/tmp/vhost0」から仮想マシン１０に使用させる場合は、「“vhost”:{“mac”:”A0-B1-C3-A4-B5-C6”, “path”:”/tmp/vhost0”}」が設定リスト３２に登録される。
【００３４】
アドレス作成部３３は、（設定３）のＭＡＣアドレスを設定入力部３１から管理者に手入力させる手間を削減するために、既に仮想マシン１０に使用されているＭＡＣアドレスと重複しないアドレス（ユニークなアドレス）を、例えばランダムなデータとして作成する。つまり、（設定３）のＭＡＣアドレスは、各仮想マシン１０を一意に特定するための固有情報として使用される。
【００３５】
なお、図６ではＮＩＣポート１５０内のアドレステーブル１５３のデータ内容を更新するアドレス学習部１５２を示した。図２では、このアドレス学習部１５２の代わりに、アドレステーブル５３のデータ内容を更新する手段として、キュー抽象化プロセス２２ごとのＮＩＣ設定部３８と、キュー抽象化プロセス２２とは独立したテーブル設定ＡＰＩ２４とを有する。
ＮＩＣ設定部３８は、物理マシン１内のパケットフローの通知経路を示すマッチングルールを、テーブル設定ＡＰＩ２４を介して（設定２）のＮＩＣポート５０内のアドレステーブル５３に設定する。マッチングルールは、（設定３）のＭＡＣアドレスが指定されたパケットを、（設定２）のキュー５１に転送する旨のルールである。
なお、マッチングルールの設定契機は、例えば、物理マシン１の初期化時（電源投入時）に加え、その後のアドレステーブル５３の内容変更時である。
【００３６】
テーブル設定ＡＰＩ２４は、例えば、非特許文献６、７に記載の「Generic Flow API」であり、アドレステーブル５３にＮＩＣポート５０の外部から直接マッチングルールを書き込むためのＡＰＩである。
例えば、物理port「1」のＮＩＣポート５０に対して、パケットのdst MAC（宛先ＭＡＣアドレス）が「A0-B1-C3-A4-B5-C6」の際には「2」番目のキュー５１にパケットを積む、というマッチングルールは、テーブル設定ＡＰＩ２４を介して以下のコマンドにより設定される。
「flow create 1 ingress pattern eth / eth dst is a0-b1-c3-a4-b5-c6 / end actions queue index 2 / end」
このマッチングルールは、例えばルール「0」としてアドレステーブル５３に設定される。以下がその設定結果を示す応答メッセージである。
「Flow rule #0 created」
【００３７】
ドライバ作成部３４は、設定リスト３２の（設定２）に従ってキュー側ドライバ３６ｂを作成し、設定リスト３２の（設定３）に従ってＩＦ側ドライバ３６ａを作成する。
仮想ＩＦ作成部３５は、設定リスト３２の（設定３）に従って、ＩＦ側ドライバ３６ａに対応する仮想ＩＦ２１を作成する。
キュー探索部３７は、キュー管理テーブル２３に登録されている使用可能なキュー５１のメンバリストから、自身のキュー抽象化プロセス２２と対応付けるための（設定２）のキュー５１を探索する。
【００３８】
キュー管理テーブル２３は、キュー抽象化プロセス２２の数とは独立して物理マシン１ごとに存在するテーブルである。キュー管理テーブル２３は、物理マシン１内の使用可能なＮＩＣポート５０（port）のメンバリスト、そのＮＩＣポート５０内の使用可能な（available）キュー５１と、使用中の（unavailable）キュー５１とのメンバリストを保持する。以下にキュー管理テーブル２３の設定例を構造化テキストファイルで例示する。この例では、「0」番のＮＩＣポート５０には「1,2,4,5,6,8」番という６つの使用可能なキュー５１が存在し、「1」番のＮＩＣポート５０には「0,1,4,6,7」番という５つの使用可能なキュー５１が存在することを示している。
【００３９】
【表１】
2019062491.tif 000003
【００４０】
図３は、キュー抽象化プロセス２２の動作を示すフローチャートである。
Ｓ１１として、物理マシン１は、キュー抽象化プロセス２２を起動するための命令を受け、その命令に付随する以下の引数に従ってキュー抽象化プロセス２２を起動する。
・（設定１）として設定リスト３２に登録するキュー抽象化プロセス２２のID番号。
・（設定２）として設定リスト３２に登録するＮＩＣポート５０の番号。
・（設定３）として設定リスト３２に登録する仮想ＩＦ２１のＩＤ（ディレクトリパス）。
・（設定３）として設定リスト３２に登録する仮想ＩＦ２１のＭＡＣアドレス（仮想マシン１０の固有情報）。
【００４１】
Ｓ１２として、キュー探索部３７は、Ｓ１１で起動したキュー抽象化プロセス２２に割り当てるための使用可能な（現時点で未使用の）キュー５１を、キュー管理テーブル２３から探索する。この使用可能なキュー５１は、Ｓ１１の（設定２）として指定されたＮＩＣポート５０に属するキュー５１から探索される。キュー探索部３７は、Ｓ１２で使用可能なキュー５１が探索できたときには（Ｙｅｓ）Ｓ１３に進み、探索できなかったときには（Ｎｏ）Ｓ２５に進む。
【００４２】
なお、Ｓ１２のＹｅｓ／Ｎｏの判定処理は、例えば、キュー探索部３７の機能を実装したサブルーチンからの戻り値が、成功を示す値か、失敗を示す値かにより行われる。
また、Ｓ１２でＹｅｓとなりＳ１３に進むときには、キュー探索部３７は、探索できたキュー５１を（設定２）のキュー５１として設定リスト３２に登録する。さらに、ドライバ作成部３４は、設定リスト３２に登録したキュー５１に対応するキュー側ドライバ３６ｂを作成する。
【００４３】
Ｓ１３として、仮想ＩＦ作成部３５は、設定リスト３２の（設定３）として登録したディレクトリパスに基づき、仮想ＩＦ２１を作成する。仮想ＩＦ作成部３５は、この仮想ＩＦ２１の作成に成功したときには（Ｙｅｓ）Ｓ１４に進み、失敗したときには（Ｎｏ）Ｓ２４に進む。なお、Ｓ１３でＹｅｓとなりＳ１４に進むときには、ドライバ作成部３４は、作成した仮想ＩＦ２１に対してＩＦ側ドライバ３６ａを作成する。
【００４４】
Ｓ１４として、ＮＩＣ設定部３８は、設定リスト３２の（設定２）として登録したＮＩＣポート５０内のアドレステーブル５３に対して、図２の説明で前記したマッチングルールを設定する。ＮＩＣ設定部３８は、この設定に成功したときには（Ｙｅｓ）Ｓ１５に進み、失敗したときには（Ｎｏ）Ｓ２３に進む。
【００４５】
Ｓ１５として、パケット転送部３６は、仮想マシン１０とＮＩＣポート５０との間でのパケット転送を開始する。図１で説明したように、パケット転送部３６と仮想マシン１０（仮想ＩＦ２１）との間のパケット送受信には、ＩＦ側ドライバ３６ａが使用される。パケット転送部３６とＮＩＣポート５０（キュー５１）との間のパケット送受信には、キュー側ドライバ３６ｂが使用される。
Ｓ１６として、物理マシン１は、キュー抽象化プロセス２２を停止するための命令を受けたか否かを判定する。物理マシン１は、Ｓ１６でＹｅｓならＳ２１に進み、ＮｏならＳ１５の転送を継続する。
【００４６】
Ｓ２１として、パケット転送部３６は、Ｓ１５で開始したパケット転送を停止する。
Ｓ２２として、ＮＩＣ設定部３８は、Ｓ１４で設定したＮＩＣポート５０の設定を削除する。
Ｓ２３として、仮想ＩＦ作成部３５は、Ｓ１３で作成した仮想ＩＦ２１を削除する。ドライバ作成部３４は、削除された仮想ＩＦ２１に対応するＩＦ側ドライバ３６ａも削除する。
Ｓ２４として、キュー探索部３７は、Ｓ１２で取得したキュー５１を解放する。つまり、キュー探索部３７は、キュー５１の状態を“使用中”から“未使用（使用可能）”に移行する旨を、キュー管理テーブル２３に登録する。ドライバ作成部３４は、削除されたキュー５１に対応するキュー側ドライバ３６ｂも削除する。
Ｓ２５として、物理マシン１は、Ｓ１１で起動したキュー抽象化プロセス２２を停止する。
【００４７】
以上説明した本実施形態では、図５の仮想スイッチ方式や、図６のＳＲ−ＩＯＶ方式における以下の問題点を解決する仕組みを備えることで、通信性能の向上と、管理コストの削減とをバランスよく実現する。
【００４８】
まず、図５の仮想スイッチ方式のソフトウェア的な振分け処理における転送性能の低下という問題に対し、図１，図２で述べた本実施形態の方式は、ＮＩＣポート５０というハードウェア内に機能部を設けることにより、転送性能を向上させている。
例えば、図５のアドレス照合部１４４は、ＭＡＣアドレスなどによるパケットマッチング処理をソフトウェア的に実現していた。一方、図１では、物理ハードウェアであるＮＩＣポート５０内のアドレス照合部５４にパケットマッチング処理をオフロードできるため、システム全体のスループット性能を向上させることができる。
【００４９】
また、図５の仮想スイッチ方式では、１つのスイッチング部１４６のプロセスが、複数の（２つの）仮想ＩＦ１２１を介してパケット転送処理を行っていた。よって、仮想ＩＦ１２１の数が増加したときには、１つのスイッチング部１４６のプロセスに処理負荷が集中することで、転送性能が低下してしまっていた。
一方、図１では、１つの仮想マシン１０に対して、１つの仮想ＩＦ２１と、１つのキュー抽象化プロセス２２とが生成される。つまり、３つの仮想マシン１０に対するパケット転送処理は、３つのキュー抽象化プロセス２２がそれぞれ独立に（並列して）行うため、処理負荷が適切に分散される。これにより、システム全体のスケーラビリティを向上させることができる。さらに、前記したように、ＮＩＣポート５０内のアドレス照合部５４にパケットマッチング処理をオフロードしているため、キュー抽象化プロセス２２単体の負荷を削減できる。
【００５０】
次に、図６のＳＲ−ＩＯＶ方式の物理ハードウェアへの依存性が高いことにより運用コストが増加してしまう問題に対し、図１，図２で述べた本実施形態の方式は、仮想マシン１０とＮＩＣポート５０との間に物理ハードウェアの依存性を吸収する適切な前記した（２）仮想ホスト層を設ける。これにより、物理ハードウェアへの依存を抑え、汎用性を向上させている。
例えば、図６のＳＲ−ＩＯＶ方式では、各ＮＩＣポート５０に対応したＶＦドライバ１１１が各仮想マシン１１０の中に必要となるため、物理マシン１０３に搭載されているＮＩＣポート５０の種類を意識して仮想マシン１１０を構築する必要がある。その結果、どの仮想マシン１１０がどの物理マシン１０３で動作するかを運用者が管理する必要があり、物理を隠蔽する仮想化の役割が一部損なわれてしまう。
【００５１】
一方、本実施形態では、ドライバ作成部３４が作成する送受信ドライバとして、ハードウェア依存情報を含むキュー側ドライバ３６ｂと、ハードウェア依存情報を含まないＩＦ側ドライバ３６ａとを別々に用意する構成を採用した。そして、キュー側ドライバ３６ｂのための個別のハードウェアに依存する情報は、Ｓ１１でキュー抽象化プロセス２２を起動するための命令に付随して、あらかじめ管理者などが入力しておく。
これにより、キュー側ドライバ３６ｂの側で個別のハードウェアに依存する情報が吸収されることで、仮想ＩＦ２１およびＩＦ側ドライバ３６ａは、個別のハードウェアに依存しない一般的な通信デバイスとして、仮想マシン１０からエミュレーションされる。
例えば、図１で第１のＮＩＣポート５０−１を製造ベンダＡが提供し、第２のＮＩＣポート５０−２を製造ベンダＢが提供していたとする。キュー側ドライバ３６ｂ−１、３６ｂ−２は、製造ベンダＡのハードウェア仕様が反映され、キュー側ドライバ３６ｂ−３は、製造ベンダＢのハードウェア仕様が反映される。一方、３つのＩＦ側ドライバ３６ａ（３６ａ−１、３６ａ−２、３６ａ−３）として、いずれもベンダＡ、Ｂに依存しないドライバを使用することができる。
【００５２】
また、図６のＳＲ−ＩＯＶ方式では、ＮＩＣポート５０の内部にスイッチング部１５６の機能をフルセットで用意する必要があるため、ＮＩＣポート５０のコストが高くなり、使用可能なＮＩＣポート５０が限られてしまうという問題があった。
一方、本実施形態では、ＮＩＣポート５０内の機能として、アドレス照合部５４は備えているものの、そのアドレス照合部５４が参照するアドレステーブル５３を更新するためのラーニング機能（アドレス学習部１５２に相当する機能）は、存在してもよいが必須では無い。図２では、ＮＩＣポート５０の外部であるＮＩＣ設定部３８からテーブル設定ＡＰＩ２４を介したアドレステーブル５３を更新する手段を用いている。これにより、ＮＩＣポート５０に求められる機能がＳＲ−ＩＯＶ方式よりも少なくて済むため、ハードウェアの汎用性が向上する。
【００５３】
以上説明したように、本実施形態では、仮想マシン１０間、または、仮想マシン１０とＮＩＣポート５０との間のパケットフォワーディングで利用されるＩＶＣ１２０として、図１，図２に示した構成を有する。この構成では、仮想マシン１０ごとにキュー抽象化プロセス２２を起動し（分散型とし）、そのキュー抽象化プロセス２２から仮想ＩＦ２１を介してパケットを送受信することを特徴とする。これにより、仮想マシン１０からは特定のハードウェアであるＮＩＣポート５０は意識しなくて済むため、ハードウェア依存性を軽減させることができる。
さらに、ＮＩＣポート５０内のアドレス照合部５４にパケット転送処理をオフロードすることで（ハードウェアアクセラレーションを用いることで）、スループット性能を向上させることができる。
【００５４】
なお、本実施形態においては、本発明に係る仮想化通信装置の内部構成として、図１に示す３台の仮想マシン１０と、３つのキュー抽象化プロセス２２と、３つのキュー５１と、２つのＮＩＣポート５０とで説明したが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、リソース管理システムの各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。
【符号の説明】
【００５５】
１      物理マシン（仮想化通信装置）
１０    仮想マシン
２１    仮想ＩＦ
２２    キュー抽象化プロセス（ポート抽象化プロセス）
２３    キュー管理テーブル
２４    テーブル設定ＡＰＩ（テーブル設定部）
３１    設定入力部
３２    設定リスト
３３    アドレス作成部
３４    ドライバ作成部
３５    仮想ＩＦ作成部
３６    パケット転送部
３６ａ  ＩＦ側ドライバ
３６ｂ  キュー側ドライバ（ポート側ドライバ）
３７    キュー探索部
３８    ＮＩＣ設定部
５０    ＮＩＣポート（物理ポート）
５１    キュー（パケットバッファ）
５３    アドレステーブル
５４    アドレス照合部
５６    スイッチング部
【図１】
2019062491.tif 000004
【図２】
2019062491.tif 000005
【図３】
2019062491.tif 000006
【図４】
2019062491.tif 000007
【図５】
2019062491.tif 000008
【図６】
2019062491.tif 000009