JP2017142647A

JP2017142647A - リソース管理装置及びリソース管理方法

Info

Publication number: JP2017142647A
Application number: JP2016023419A
Authority: JP
Inventors: イ朱; Yi Zhu; 芳巳福田; Yoshimi Fukuda; 裕司近藤; Yuji Kondo; 広充永田; Hiromitsu Nagata; 修治木村; Shuji Kimura; 友宏佐藤; Tomohiro Sato
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: NTT Inc
Priority date: 2016-02-10
Filing date: 2016-02-10
Publication date: 2017-08-17

Abstract

【課題】所定の通信ソフトウェアに対してコンピュータのリソースを保証する。【解決手段】処理リソース制御部１１は、複数の機能部３に対して各機能部３の機能に応じて優先度をそれぞれ付与し、付与した優先度に基づき汎用装置又は汎用システムの処理リソースを各機能部３にそれぞれ割り当てる。また、帯域リソース制御部１２は、複数の機能部３でそれぞれ用いられる複数の通信信号又は複数の機能部３のうち１つの機能部３で用いられる複数の通信信号に対して各通信信号の種類に応じて優先度を付与し、付与した優先度に基づき汎用装置又は汎用システムの持つ通信帯域を各通信信号にそれぞれ割り当てる【選択図】図１

Description

本発明は、大規模通信ソフトウェアに係る専用装置のＥｏＬ対策に関する技術であり、特に大規模通信ソフトウェアを備えた汎用装置又は汎用システムのリソースを管理する技術に関する。

近年、通信ソフトウェアのライフサイクルの長期化に伴い、通信サービスの提供を維持するための維持管理環境も長く維持しなければならず、通信ソフトウェアを稼働する専用装置も長く使用して保持する必要がある。その一方で通信ソフトウェアを稼働する専用装置は次第に古くなるため、これまでと同じ専用装置を調達することは難しく、該専用装置のＥｏＬ（End of Life）対策が必要となる。

そこで現在では、将来的に上記維持管理環境をＮＶＦ（Network Function Virtualization）化すること、つまり、維持管理環境を全て仮想化環境で構築する傾向にある。例えば、疑似的に呼処理を行う疑似呼処理装置の場合、図６に示すように、これまでは呼処理を専用装置（専用ハードウェア）で構築していたが、ハイパーバイザ等の仮想化技術を用いて呼処理の機能を仮想化し、仮想化した呼処理ソフトウェアを汎用装置（汎用コンピュータ）で動作させ、該汎用装置をクラウドネットワークに配置する。

このように、通信サービスに係る全ての専用ハードウェア機能をソフトウェアに置き換えることにより、通信ソフトウェアのハードウェア依存性が解消され、通信サービスを引き続き長く提供することができる。

"NetroSphere構想：キャリアネットワークのあり方を変革する新R&Dコンセプトを策定〜部品化したネットワーク機能を自由に組み合わせ、多様なサービス創出を支えるためのオープンな技術開発を推進〜"、日本電信電話株式会社、［online］、［平成28年2月1日検索］、＜URL: http://www.ntt.co.jp/news2015/1502/150219a.html＞

上述した通り通信ソフトウェアのハードウェア依存性がないため、複数の通信ソフトウェアを仮想的に汎用装置内で同時に動作させることができる。これによりハードウェアに係るコストを低減することができる。しかしその一方で、複数の通信ソフトウェアが限度あるコンピュータのリソースを互いに奪い合う事象が発生するという課題があった。

本発明は、上記事情を鑑みてなされたものであり、所定の通信ソフトウェアに対してコンピュータのリソースを保証することを目的とする。

以上の課題を解決するため、請求項１に係るリソース管理装置は、コンピュータのリソースを管理するリソース管理装置において、複数の装置としてそれぞれ機能する複数の機能部に対して各機能部の機能に応じて第１の優先度を付与し、前記第１の優先度に基づきコンピュータの処理リソースを前記機能部に割り当てる処理リソース制御部、を備えることを要旨とする。

請求項２に係るリソース管理装置は、請求項１に記載のリソース管理装置において、前記複数の機能部でそれぞれ用いられる複数の通信信号又は前記複数の機能部のうち１つの機能部で用いられる複数の通信信号に対して各通信信号の種類に応じて第２の優先度を付与し、前記第２の優先度に基づきコンピュータの通信帯域を前記通信信号に割り当てる帯域リソース制御部、を更に備えることを要旨とする。

請求項３に係るリソース管理装置は、請求項１に記載のリソース管理装置において、前記処理リソース制御部は、前記第１の優先度に応じたコンピュータの処理リソースの使用率を配分することを要旨とする。

請求項４に係るリソース管理装置は、請求項２に記載のリソース管理装置において、前記帯域リソース制御部は、前記第２の優先度に応じたコンピュータの通信帯域の帯域幅を配分することを要旨とする。

請求項５に係るリソース管理方法は、コンピュータのリソースを管理するリソース管理装置で行うリソース管理方法において、複数の装置としてそれぞれ機能する複数の機能部に対して各機能部の機能に応じて第１の優先度を付与し、前記第１の優先度に基づきコンピュータの処理リソースを前記機能部に割り当てる処理リソース制御ステップ、を備えることを要旨とする。

請求項６に係るリソース管理方法は、請求項５に記載のリソース管理方法において、前記複数の機能部でそれぞれ用いられる複数の通信信号又は前記複数の機能部のうち１つの機能部で用いられる複数の通信信号に対して各通信信号の種類に応じて第２の優先度を付与し、前記第２の優先度に基づきコンピュータの通信帯域を前記通信信号に割り当てる帯域リソース制御ステップ、を更に備えることを要旨とする。

本発明によれば、所定の通信ソフトウェアに対してコンピュータのリソースを保証することができる。

リソース管理装置の機能ブロック構成を示す図である。汎用装置におけるリソース管理装置の位置付けを示す図である。汎用装置又は汎用システムにおけるリソース管理装置の位置付けを示す図である。処理リソース制御部の動作処理を説明する際の参照図である。帯域リソース制御部の動作処理を説明する際の参照図である。背景技術を説明する際の参照図である。

以下、本発明を実施する一実施の形態について図面を用いて説明する。

図１は、本実施の形態に係るリソース管理装置１の機能ブロック構成を示す図である。該リソース管理装置１は、汎用装置又は汎用システムのリソースを管理する装置であり、処理リソース制御部１１と、帯域リソース制御部１２と、を備えて構成される。

処理リソース制御部１１は、従来の専用装置としてそれぞれ機能する複数の機能部３に対して各機能部３の機能に応じて優先度をそれぞれ付与し、付与した優先度に基づき汎用装置又は汎用システムの処理リソースを機能部３に割り当てる。なお、ここでいう機能部とは、従来の通信装置として仮想的に動作する通信ソフトウェアによる機能部である。

帯域リソース制御部１２は、複数の機能部３でそれぞれ用いられる複数の通信信号、又は複数の機能部３のうち１つの機能部３で用いられる複数の通信信号に対して各通信信号の種類に応じて優先度を付与し、付与した優先度に基づき汎用装置又は汎用システムの持つ通信帯域を通信信号に割り当てる。

なお、リソース管理装置１で用いられる全ての優先度は、該リソース管理装置１が動作する汎用装置又は汎用システムの持つ任意のメモリ又はハードディスクに記憶され、リソースの割当時に参照される。また、リソース管理装置１は、クラウドネットワーク（図６）に接続された１つの汎用装置内に単独で構成してもよく、すなわち、機能部３が動作する汎用装置とは別の汎用装置に構成してもよい。

図２及び図３は、クラウドネットワーク上の汎用装置又は汎用システムにおけるリソース管理装置１の位置付けを示す図である。クラウドネットワークとは１つ以上の物理的な汎用装置が接続された維持管理環境対象用のネットワークであり、既存の専用装置を仮想化した通信ソフトウェアが動作する。本実施の形態では、呼処理システムのネットワークを例示している。詳細には、呼処理サービスをユーザに提供するための仮想的な通信ソフトウェアとして、例えば、仮想加入者セッション制御サーバ（ＳＳＣサーバ）、仮想中継セッション制御サーバ（ＩＳＣサーバ）、仮想サポート系共通サーバ等が動作する。そのほか、システム管理者が呼処理システムを試験するための仮想的な通信ソフトウェアとして、例えば、仮想シミュレータ、仮想疑似装置、仮想負荷装置、仮想測定装置、仮想疑似呼処理装置等が動作する。

リソース管理装置１は、それら仮想された通信ソフトウェアと同様に、ハイパーバイザ等の仮想化技術を用いて作成された仮想化通信ソフトウェア又は仮想化通信アプリであり、仮想化ソフトウェア上で動作する。また、リソース管理装置１は、１つの物理的な汎用装置に備わる各種１つのリソース（１つの物理ＣＰＵ、１つの物理メモリ、１つの物理ハードディスク等）、１つの物理的な汎用装置に物理的又は論理的に備わる各種複数のリソース（複数の物理／仮想ＣＰＵ、複数の物理／仮想メモリ、複数の物理／仮想ハードディスク等）、複数の物理的な汎用装置に物理的又は論理的に備わる各種複数のリソース（複数の物理／仮想ＣＰＵ、複数の物理／仮想メモリ、複数の物理／仮想ハードディスク等）を管理対象とする。なお、本実施の形態において、汎用システムとは汎用装置の集合をいう。

次に、図４を参照しながら、処理リソース制御部１１の動作処理について説明する。

まず、処理リソース制御部１１は、複数の機能部３に対して各機能部３の機能に応じて優先度をそれぞれ付与する（ステップＳ１０１）。例えば、システム管理者が上記クラウドネットワーク内で呼処理を疑似的に試験する場合、仮想疑似呼処理装置に対して最も高い優先度を設定する。また、運用中の呼処理サービスに影響を与えないように、仮想ＳＳＣ／ＩＳＣサーバに対しても最も高い優先度を設定する。一方、監視系又は管理系サーバに対しては中又は最も低い優先度を設定する。

その後、処理リソース制御部１１は、ステップＳ１０１で付与した優先度に基づき汎用装置又は汎用システムの処理リソースを各機能部３にそれぞれ割り当てる（ステップＳ１０２）。詳細には、最も高い優先度が設定された仮想疑似呼処理装置及び仮想ＳＳＣ／ＩＳＣサーバに対しては、それぞれ、例えば６つのＣＰＵのうち２つのＣＰＵを割り当てる。ＣＰＵが物理的に１つの場合には、該１つのＣＰＵの使用率のうち４０％の使用率を配分する。一方、最も低い優先度が設定された監視系又は管理系サーバに対しては、１つのＣＰＵを割り当て、又は該１つのＣＰＵの使用率のうち１０％の使用率を配分する。

以上より、帯域リソース制御部１２は、複数の機能部３に対して各機能部３の機能に応じて優先度をそれぞれ付与し、付与した優先度に基づき汎用装置又は汎用システムの処理リソースを各機能部３にそれぞれ割り当てるので、処理リソースの使用において他の機能部による影響を互いに受けないことから、汎用装置又は汎用システムの処理リソースを互いに奪い合う事象の発生を防ぎ、所定の機能部３に対して汎用装置又は汎用システムの処理リソースを保証することができる。例えば、呼処理を疑似的に試験する場合、優先度の高い仮想疑似呼処理装置の機能部に多くの処理リソースが割り当てられるので、安定的な負荷試験を確保し維持することができる。

次に、帯域リソース制御部１２の動作処理について説明する。

最初に、複数の機能部３の通信信号に対する帯域リソースの割り当て方法について説明する。

まず、帯域リソース制御部１２は、複数の機能部３でそれぞれ用いられる複数の通信信号に対して各通信信号の種類に応じて優先度を付与する（ステップＳ２０１）。例えば、システム管理者が上記クラウドネットワーク内で呼処理を疑似的に試験する場合、仮想疑似呼処理装置が用いる通信信号（例えば、呼信号を制御するための呼制御信号、呼信号の制御に基づき送受信されるデータ信号）に対して高い優先度を設定する。一方、監視系又は管理系サーバが用いる通信信号に対しては低い優先度を設定する。なお、通信信号に対する優先度の具体的な設定方法は、例えば、ＴＣＰの“priority bit”やセッションレイヤの特別bit等を設定することにより実現できる。

次に、帯域リソース制御部１２は、ステップＳ２０１で付与した優先度に基づき汎用装置又は汎用システムの持つ通信帯域を各通信信号にそれぞれ割り当てる（ステップＳ２０２）。詳細には、高い優先度が付与された仮想疑似呼処理装置の通信信号に対しては、例えば、汎用装置が使用可能な通信帯域の最大帯域幅のうち４０％の帯域幅を配分する。一方、低い優先度が付与された監視系又は管理系サーバの通信信号に対しては、１０％の帯域幅を配分する。

続いて、図５を参照しながら、機能部３内の通信信号に対する帯域リソースの割り当て方法について説明する。ここでは、仮想疑似呼処理装置を用いてクラウドネットワーク内で呼処理を疑似的に試験する場合について説明する。

まず、帯域リソース制御部１２は、仮想疑似呼処理装置が汎用装置又は汎用システムで使用している専用ＩＦカード数、送受信している呼量、呼信号の速度等を参照し、該仮想疑似呼処理装置が信号を送信する際に必要な最大帯域幅を算出する（ステップＳ３０１）。

次に、帯域リソース制御部１２は、上記仮想疑似呼処理装置の受信フローを検出し、受信フローに含まれる複数の通信信号を、呼信号を制御するための呼制御信号（Ｃ−ｐｌａｎｅ）と、呼信号の制御に基づき通信されるデータ信号（Ｕ−ｐｌａｎｅ）とに分類する（ステップＳ３０２）。なお、分類処理については、通信信号内のヘッダ情報等を参照して実現可能である。

次に、帯域リソース制御部１２は、ここではシステム管理者が呼処理を試験することから、Ｃ−ｐｌａｎｅに対して高い優先度を設定し、Ｕ−ｐｌａｎｅに対して低い優先度を設定する（ステップＳ３０３）。なお、設定処理については、ユーザの指定に応じて設定してもよいし、通信信号内のヘッダ情報を元により自動で判断して設定してもよい。

最後に、帯域リソース制御部１２は、高い優先度が設定されたＣ−ｐｌａｎｅに対しては、ステップＳ３０１で算出された最大帯域幅のうち例えば４０％の帯域幅を配分し、低い優先度が設定されたＵ−ｐｌａｎｅに対しては、１０％の帯域幅を配分する（ステップＳ３０４）。詳細には、優先度の高い通信信号に対しては大きい帯域幅の物理／論理チャネルを割り当て、優先度の低い通信信号に対しては小さい帯域幅の物理／論理チャネルを割り当てる。

なお、ステップＳ３０２において、帯域リソース制御部１２は、Ｃ−ｐｌａｎｅに含まれる複数の呼制御信号（例えば、ＳＩＰ信号、疑似呼通信信号）、Ｕ−ｐｌａｎｅに含まれる複数のデータ信号（例えば、画像信号、音声信号）をそれぞれ分類してもよい。その場合、ステップＳ３０３では、Ｃ−ｐｌａｎｅ又はＵ−ｐｌａｎｅ内の個々の信号に対して優先度がそれぞれ設定され、ステップＳ３０４では、該個々の信号に対して帯域幅がそれぞれ配分される。つまり、包括的なＣ−ｐｌａｎｅではなく、ＳＩＰ信号等の個々の信号に対して優先度が設定されて帯域幅が割り当てられる。

以上より、帯域リソース制御部１２は、複数の機能部３でそれぞれ用いられる複数の通信信号、又は複数の機能部３のうち１つの機能部３で用いられる複数の通信信号に対して各通信信号の種類に応じて優先度を付与し、付与した優先度に基づき汎用装置又は汎用システムの持つ通信帯域を各通信信号にそれぞれ割り当てるので、所定の機能部３に対して汎用装置又は汎用システムの持つ通信帯域を保証することができる。例えば、呼処理を疑似的に試験する場合、呼制御信号に多くの帯域幅が割り当てられるので、安定的な負荷試験を確保し維持することができる。

最後に、本実施の形態で説明したリソース管理装置１は、ＣＰＵ等の演算機能やメモリ等の記憶機能を備えたコンピュータで実現できる。また、リソース管理装置１としてコンピュータを機能させるためのリソース管理プログラムや該リソース管理プログラムの記憶媒体を作成することも可能である。

１…リソース管理装置
１１…処理リソース制御部
１２…帯域リソース制御部
３…機能部
Ｓ１０１〜Ｓ１０２、Ｓ２０１〜Ｓ２０２、Ｓ３０１〜Ｓ３０４…ステップ

Claims

コンピュータのリソースを管理するリソース管理装置において、
複数の装置としてそれぞれ機能する複数の機能部に対して各機能部の機能に応じて第１の優先度を付与し、前記第１の優先度に基づきコンピュータの処理リソースを前記機能部に割り当てる処理リソース制御部、
を備えることを特徴とするリソース管理装置。
前記複数の機能部でそれぞれ用いられる複数の通信信号又は前記複数の機能部のうち１つの機能部で用いられる複数の通信信号に対して各通信信号の種類に応じて第２の優先度を付与し、前記第２の優先度に基づきコンピュータの通信帯域を前記通信信号に割り当てる帯域リソース制御部、
を更に備えることを特徴とする請求項１に記載のリソース管理装置。
前記処理リソース制御部は、
前記第１の優先度に応じたコンピュータの処理リソースの使用率を配分することを特徴とする請求項１に記載のリソース管理装置。
前記帯域リソース制御部は、
前記第２の優先度に応じたコンピュータの通信帯域の帯域幅を配分することを特徴とする請求項２に記載のリソース管理装置。
コンピュータのリソースを管理するリソース管理装置で行うリソース管理方法において、
複数の装置としてそれぞれ機能する複数の機能部に対して各機能部の機能に応じて第１の優先度を付与し、前記第１の優先度に基づきコンピュータの処理リソースを前記機能部に割り当てる処理リソース制御ステップ、
を備えることを特徴とするリソース管理方法。
前記複数の機能部でそれぞれ用いられる複数の通信信号又は前記複数の機能部のうち１つの機能部で用いられる複数の通信信号に対して各通信信号の種類に応じて第２の優先度を付与し、前記第２の優先度に基づきコンピュータの通信帯域を前記通信信号に割り当てる帯域リソース制御ステップ、
を更に備えることを特徴とする請求項５に記載のリソース管理方法。