JP5666620B2

JP5666620B2 - ネットワークシステム、及びそのサービス品質制御方法

Info

Publication number: JP5666620B2
Application number: JP2012547728A
Authority: JP
Inventors: 啓生宮本; 秀貴青木; 功下川; 俊明垂井
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2010-12-07
Filing date: 2011-08-31
Publication date: 2015-02-12
Anticipated expiration: 2031-08-31
Also published as: JPWO2012077390A1; WO2012077390A1

Description

本発明はネットワークサービス運用システムに係り、特に、ネットワークサービスの品質の保証を行うネットワークサービス運用管理技術に関する。

近年、情報システムの運用管理コスト増加を背景にしたデータセンタ(以下DC)の利用拡大と共に、IT機器による消費電力が問題化している。経済産業省が2008年に発表したグリーンIT(GreenIT)イニシアティブ会議での予測によれば、2025年のデータセンタ内のICT(Information and Communication Technology)機器の消費電力量は06年の2.5倍の527億kWhとなると言われている。これは06年のICT機器全体の消費電力の総和を超える。このような状況に対応すべく、Green of ICT/Green by ICTの名のもとに、ネットワーク装置の省電力化機構によってICT機器トータルで約４割の電力消費を削減することを目標に掲げている。特に、ICT機器そのものの省電力化技術(Green of ICT)だけでなく、ICT機器全体を制御する運用管理技術によって、省電力化を実現するGreen by ICTが注目されている。

ネットワーク運用管理技術において、機器の使用リソースを業務処理合わせて適正に割り当てることで、業務処理を持たない物理サーバの電力制御を行い、省電力化を実現する方法が提案されている(特許文献1、特許文献２)。これらは仮想マシンをいくつかの物理サーバに集約することで、稼働しない物理サーバを見つけ出し、それらの物理サーバの電源を切ることによってIT機器の消費電力を削減する方法である。さらに、特許文献３では、仮想マシン移動時において、複数の移動ポリシーを制御することにより、物理サーバやアプリケーションの実態に連動した仮想マシンの配置決定が可能である。

また、データセンタ内の仮想マシンの配置決定だけでなく、データセンタ間連携のための標準化団体が発足していることから、ユーザにより近いデータセンタやより高効率なデータセンタを選択して、仮想マシンを移動することも将来的には考えられる。たとえば、特許文献４のようにデータセンタ間で仮想マシンやアプリケーションの動作環境を仮想マシンの移行前に確認することで、データセンタ間における仮想マシンの性能レベルが維持されることを保証する。

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

しかし，特許文献１、特許文献２、特許文献３では、仮想マシンが必要とするネットワーク容量等を鑑みていない。従って，仮想マシンの集約後のQoS性能保証が課題となる。

さらに、特許文献４では、データセンタ間で仮想マシンの移行に関して、省電力化を踏まえた方式は含まれておらず、移行後の性能レベルは維持できるものの、物理サーバへ効率的に仮想マシンを稼働させる方法については検討されていない。

本発明の目的は、上記の課題を解決し、ネットワークシステムであるデータセンタ内のサーバ位置及び通信経路の適正化を行い、さらに連携するデータセンタの処理状況を把握して資源配置適正化を行うことで、QoSの確保及び省電力化を実現することが可能な、ネットワークシステム、及びそのサービス品質制御方法を提供することにある。

上記の目的を達成するため、本発明においては、外部からのリクエストに対してサービスを提供するネットワークシステム、及びそのサービス品質制御方法であって、サービスを実行するための情報処理装置及び通信装置と、サービスを管理するソフトウェアを記憶する記憶装置と、ソフトウェアと連動して情報処理装置及び通信装置の管理を行う管理装置とを備え、管理装置は、サービスを実行する情報処理装置の位置を変更することにより、ネットワークシステム内に発生する通信量を削減し、電力を下げることにより、ネットワークシステム全体の省電力化を図る構成のネットワークシステム、及びそのサービス品質制御方法を提供する。

また、上記の目的を達成するため、本発明においては、外部からのリクエストに対して
サービスを提供するネットワークシステム、及びそのサービス品質制御方法であって、サ
ービスを実行するための情報処理装置及び通信装置と、サービスを管理するソフトウェア
を記憶する記憶装置と、ソフトウェアと連動して情報処理装置及び通信装置の管理を行う
管理装置とを備え、通信装置は、リクエストを受信し、受信したリクエストを解析し、い
ずれのサービスに対するリクエストかを判定した結果に基づき、リクエストを振分け、リ
クエストに対するサービス毎のQoS違反を監視し、QoS違反を検出した場合、リクエストの
処理を、ネットワークシステム内のリソース再割当てで対応するか、他ネットワークシス
テムに振分るかの判断結果に基づき、リクエストの処理の振分先を決定し、管理装置は、
サービスを実行する情報処理装置上の仮想計算機の位置を変更することにより、ネットワ
ークシステム内に発生する通信量を削減し、電力を下げることにより、ネットワークシス
テム全体の省電力化を図る構成のネットワークシステム、及びそのサービス品質制御方法
を提供する。

すなわち、上記の目的を達成するため、本発明の好適な実施態様においては、データセ
ンタなどのネットワークシステムは外部のネットワークシステムからの要求に対してサー
ビスを提供するシステムであって、当該ネットワークシステムはサービスを管理するソフ
トウェアと、ソフトウェアと連動してネットワークシステムを構成する情報処理装置や通
信機器などの管理を行う管理装置と、ネットワークシステムを構成し、サービスを実行す
るための情報処理装置及び通信装置によって構成されたネットワークシステムにおいて、
サービスを実行する情報処理装置上の仮想計算機の位置を変更することでネットワークシ
ステム内に発生する通信量を削減し、利用していない装置等の電力を下げ、さらには省電
力向けのシステムが備わる装置については管理装置から省電力を実現する状態に変更する
ことで、ネットワークシステム全体の省電力化を実現するリソース割当方法を実現する。
これによって課題となる資源の配置を適正化し、QoSを保証しつつ省電力化できるネット
ワークシステムが構築できる。

ネットワークを考慮した資源の適正配置を実施することによってQoSを保証しつつ省電力化可能なネットワークシステムを実現できる。

第１の実施例に係るデータセンタ間連携サービスシステムの一構成例を示す図ある。第１の実施例のシステムによるサービス連携の一具体例を示す図である。第１の実施例に係わる、プロキシ（Proxy）の一構成例を示す図である。第１の実施例に係わる、プロキシ（Proxy）の負荷予測から振り分け処理実施までのシーケンスの一例を示す図である。第１の実施例に係わる、トラフィック監視テーブルの一例を示す図である。第１の実施例に係わる、サービス管理テーブルの一例を示す図である。第１の実施例の変形例に係わる、優先度制御管理テーブルの一例を示す図である。第１の実施例に係わる、データセンタ（DC）の内部構成の一例を示す図である。第１の実施例に係わる、データセンタ（DC）の内部構成の他の例を示す図である。第１の実施例に係わる、データセンタ（DC）の内部構成の他の例を示す図である。第１の実施例に係わる、データセンタ内の情報処理位置を決定するためのフローチャート（１）を示す図である。第１の実施例に係わる、データセンタ内の情報処理位置を決定するためのフローチャート（２）を示す図である。第１の実施例に係わる、QoS定義テーブルの一構成例を示す図である。第１の実施例に係わる、DC管理ノードにおけるサービスグルーピング処理の一例を説明するためのシーケンス図である。第１の実施例に係わる、構成確認要求テーブルの一例を示す図である。第２の実施例に係わる、本実施例における親管理ノードが、システム全体で自律的にQoSを保証する機能を説明するシーケンス図である。第２の実施例に係わる、データセンタ(DC)間仮想マシン配置最適化処理を示すシーケンス図である。

以下、本発明の各種の実施例を図面に従い説明する。本明細書において、ネットワークシステムとは、主に、クライアント(Client)のリクエストに対して、複数のデータセンタ(Data Center：DC)が連携して、１つのサービス(service)を提供するシステムを意味するが、サーバ、ネットワーク、ストレージリソースと、リソース管理マネージャとして機能するデータセンタ(DC)管理ノードとから構成されるデータセンタ(DC)自身をネットワークシステムと呼ぶ場合がある。また、本明細書において、データセンタ(DC)内の記憶装置で記憶され、情報処理装置で実行される各種のプログラム、ソフトウェアの機能を「機能」以外に「手段」や「部」と呼ぶ場合がある点留意されたい。例えば、サービス振分機能やQoS情報策定機能等は、サービス振分手段やQoS情報策定手段、或いはサービス振分部やQoS情報策定部等となる。監視部、フォーマット変換部、振分け先決定部、負荷予測部他も同様である。

図1は第一の実施例に係る、データセンタ間連携サービスシステムの一構成例を示す図である。データセンタ間連携サービスシステムは、クライアント(Client)のリクエストに対して、複数のデータセンタが連携して１つのサービス(service)を提供するネットワークシステムである。データセンタ(Data Center：DC)は、それぞれ複数のサービスを提供し、それぞれのサービスは、連携して動作することを想定している。サービス間を連携させるために、各データセンタ(DC)にサービスを仲介するプロキシ（Proxy）を設置し、サービス連携に必要な入出力フォーマットの変換や次サービスへのデータ転送を実施する。また、Proxy間で負荷情報を交換することによって、各データセンタで動作するサービスに必要なリソースにおいて、過剰分を削減し、省電力化されたシステムを提供することができる。

各データセンタ(DC)は、情報を安全かつ高速に処理できるように、高性能のサーバや大容量のネットワークやストレージをセンタに集約したネットワークシステムである。データセンタ(DC)内の物理的なリソースであるサーバ、ネットワーク、ストレージは仮想化され、物理装置以上にリソースが存在するように提供することが可能である。仮想化されたリソースを使用して、様々なサービスをクライアントに提供することが可能である。

上述のように、各データセンタ(DC)は、これらのリソース以外に、ネットワーク経由で受信したデータを情報処理し、送信者に対して相応のレスポンスを実施するサービス(service)と、サービス間を仲介するプロキシ（Proxy）によって構成される。データセンタ内にはProxyもサービスも複数あってもよく、あるサービスグループを束ねるProxyが存在する構成を取り得る。仮想化されたリソース上に構築されたProxyは、DC間のサービス連携時の仲介役として存在する。Proxyはサービス間のインタフェースの整合性をとり、同じDC内のサービスを管理するために存在する。Proxyは、同じ機能を有した装置であってもよい。

図１のデータセンタ間連携サービスシステムにおいて、符号101はクライアント（Client）、符号102はWAN、符号103は親管理ノードであるクラウドマネージャー（Cloud Manager）、符号104はDC4、符号105はプロキシ（Proxy）、符号106はservice A、符号107はDC3、符号108はProxy、符号109はservice B、符号110はDC2、符号111はProxy、符号112はservice C、符号113はDC1、符号114はProxy、符号115はservice D、符号116はサービス連携情報、符号120はDNS、符号121はQoS情報(Service A)、符号124はQoS情報(service A to D)、符号127はService Eである。

DC4 104はProxy105、service A106から構成されている。Proxy105はClient101、service A106、Proxy108、Cloud Manager103と接続されている。Service A106はProxy105と接続されている。同様に、DC3107はProxy108、service B109から構成されている。Proxy108はservice B109、Proxy105、Proxy111、Cloud Manager103と接続されている。Service B109はProxy108と接続されている。DC2 110の構成要素は、Proxy111、service C112、Service E127から構成されている。Proxy111はservice C112、Proxy108、Proxy114、Cloud Manager103と接続されている。Service C112はProxy111と接続されている。更に、DC1 113は、Proxy114、serviceD115から構成されている。Proxy114はservice D115、Proxy111、Cloud Manager103、Client 101と接続されている。

ここで、Client101とは、サービスを利用する顧客であり、各データセンタが提供するサービス、連携サービスを使用することが可能であり、Proxy105、Proxy114、DNS(Domain Name Server)120と接続されている。WAN102は広域ネットワークである。また、親管理ノードとなるCloud Manager103は、サービス提供者が構築したサービスフローを解釈し、連携方法を各データセンタのProxyに示す機能も持つ。サービス提供者は、サービスの接続関係とサービス間を接続する際に必要なインタフェースの接続方法を定義する。

Cloud Manager103は、親管理ノードとして機能し、Proxy114、Proxy111、Proxy108、Proxy105と接続しており、各Proxyから取得できるサービス情報を基に接続関係と接続方法を決定し、各Proxyに対してサービス連携情報を送信する。各ProxyはこのCloud Manager103からのサービス連携情報を基に、サービスの接続関係を認識する。サービス中は、要求(Request)の中の連携サービスの連携サービス識別子（ID）と連携先のサービス識別子（ID）と処理識別子（ID）によって、振り分け先のサービスと処理内容を識別して、該当するサービスへ処理を振り分け、処理結果を連携サービス識別子と処理識別子によって後段のサービスを特定して送信する。

Proxy114は、上述の通りソフトウェアとしてその機能を提供してもよいし、ハードウェアとしてその機能を提供してもよい。すなわち、Proxyは、ネットワーク経由で送信されてきたRequestのヘッダ情報を読み取り、各Proxyが管理しているデータセンタ内の複数のサービスに対して、ヘッダ情報に適合したサービスへ処理を振り分ける。また、処理を振り分ける際に、サービスに適したフォーマットに変換する。

本実施例の構成において、複数のサービスが連携する際には、前段のサービスを管理するProxyが前段のサービスの負荷状況を次段のサービスを管理するProxyに送信することによって、負荷状況を事前に通知し、適切なリソースを確保することでサービス毎に設定されたQoS情報を満足することを可能にする。また、Proxyはデータセンタ内のリソース管理マネージャである、後で詳述されるデータセンタ(DC)管理ノードと連動し、サーバリソース、ネットワークリソース、ストレージリソースをサービス稼働状態のときにQoSを満たすだけのリソースを利用することによって、データセンタ内の電力利用を適切にし、ひいてはシステム全体が省電力化を実現することを可能にする。

serviceD115は、ソフトウェアの機能をネットワークを経由して、利用できるようにしたものである。サービスが複数連携することによって提供することも可能であり、Proxy114と接続されている。サービス連携情報116は連携サービスを提供するにあたり必要なサービスの接続関係とインタフェースが異なる場合の変換ルールが記載されている。サービス連携情報は１連携サービスごとに存在し、この情報を各Proxyに送信することによってProxy間の接続関係を明確にでき、各Proxyが管理するサービスを連携させることが可能になる。

DNS120(Domain Name System)は、URL(Uniform Resource Locator)の名前解決するためのシステムである。クライアントからサービスにアクセスする際に使用する。QoS情報(ServiceA)121はProxyが管理する各サービスのQoSを定義する情報であって、各サービスはQoS情報の範囲でサービスを提供することが望ましい。QoS情報はサービス提供者である顧客と交わす契約から構築した情報であり、たとえばSLA(Service Level Agreement)といった情報を基に、サービスの応答時間、サービスの接続可能数といったクライアントから見たサービスの品質にかかわる情報を定義している。連携サービスのおいてもQoS情報は定義することができ、連携サービスも同様にサービス提供者とデータセンタ事業者が交わす契約であるSLAを基本として作成するものである。

図２は、データセンタによる連携サービスの一具体例を示す図である。同図においては、データセンタDC1 202、DC2 209、DC4 206により、複数のサービスが連携して１つのService AA207を提供している。すなわち、Service A205とService C203とService D204が、シーケンシャルに処理が実施されることで、Service AAに定義するServiceを実現する。同図において、点線は処理の流れを示している。サービス名は、サービスの名前にアルファベット２つ並んでいる場合には、連携サービスを指し、１つの場合には、自分以外の構成要素を含まないサービスを指すものとする。

図３Ａは図１に示した本実施例のシステム中のデータセンタ(DC)内のProxyの機能構成の一例を示す構成図である。このProxyは、上述の通り、ソフトウェアとしてその機能を提供してもよいし、ハードウェアとしてその機能を提供してもよい。ハードウェアとして提供する場合、例えば、Proxyの機能を搭載した負荷分散装置が利用できる。

図３Ａにおいて、符号301はサービス、符号302はフォーマット変換部、符号303は送受信部、符号304はサービス振分部、符号305はサービス管理情報を記録するサービス管理テーブル、符号306は負荷予測部、符号307はサービス振分判断部、符号308は負荷情報送受信部、符号309は前段サービス、符号310はQoS監視部、符号311はQoS情報策定部、符号312は振分け先決定部、符号313は制御用送受信部、符号314はQOS定義テーブル、符号315は後段サービス、符号316は構成確認要求、符号317は子管理ノードであり、各データセンタ内のリソース管理マネージャとして機能するデータセンタ(DC)管理ノード、符号318は親管理ノードであるCloud Manager、符号332は他データセンタ（DC）、符号333はトラフィック監視テーブル、符号334は監視部である。

なお、他データセンタ(DC)332は、データセンタ(DC)300と同様、サーバリソース、ストレージリソース、ネットワークリソースとリソース管理マネージャであるDC管理ノード等で構成される。すなわち、他DC332は、同図にそのハードウェア構成を示すように、リソースとして機能する通信装置335、通信経路336、情報処理装置337、各種ソフトウェアを保持する記憶装置338、及びDC管理ノード339などから構成される。

次に図３Ａに示すProxy内の各機能ブロックを使ってその動作、処理の流れを説明する。まず、他のデータセンタからWAN経由で送信されてきたサービスリクエストに対してProxy内の送受信部303が受信する。送受信部303は、フォーマット変換部302、QoS監視部310、サービス301等と接続され、他データセンタ(DC)やクライアントとサービスに関する情報をやり取りするインタフェースである。他データセンタやクライアントからProxyが管理するサービスへのRequestを受信し、処理結果を他のデータセンタやクライアントへ送信する。サービスのRequestには、SOAP(Simple Object Access Protocol)やREST(Representational State Transfer)のような分散処理システムで利用するメッセージ交換プロトコルを想定している。送受信部303は、受信データをフォーマット変換部302へ転送、さらにはサービス処理結果に対してサービス管理テーブル305のサービス管理情報から送信先を参照し、ヘッダ情報を付けて送信する役目を持つ。

一方、送受信部303に入力されるデータは、監視部334によってモニタリングされており、サービス単位でトラヒック量の時間変動を計測し、トラヒック監視テーブル333に蓄積する。蓄積する際、監視部334によって計測データに圧縮処理を実施してもよい。そして、送受信部303は受信データから送信元のサービス識別子と処理識別子を取得し、フォーマット変換部302へ取得した情報を転送する。

図４に本実施例において使用するトラヒック監視テーブル333の一例を示した。同図において、401はサービス識別子、402は連携サービス識別子、403は圧縮フラグ、404は監視期間、405はデータ参照先である。Proxyが管理するサービスにおいて、当該Proxyが存在するデータセンタに対してWAN側から流れ込むトラヒック量と、WAN側へ送出するトラヒック量をProxyの監視部334で監視する。本テーブル333は、サービスごとに抽出したトラヒックデータを蓄積するために必要なテーブルである。以下、トラヒック監視情報テーブル333の説明をする。

サービス識別子401は観測したトラヒックのサービスを特定する情報である。連携サービス識別子402は、サービスリクエストを発行したクライアントやサービス及び応答先を識別する情報である。この連携サービス識別子402をキーとして、後で説明する、図５に示すサービス管理テーブル305から送信元情報と送信先情報を取得するために用いられる。圧縮フラグ403はデータ参照先のファイルに記載されているデータが圧縮されているか否かをデータ利用者やプログラムに提示するための情報である。監視期間404はデータ参照先にあるデータの監視開始時間と監視終了時間が記載されている項目である。データ参照先405は実際のトラヒック監視情報が記載されているファイル名である。

なお、すべてのサービスの単位時間ごとのトラヒック量を蓄積する場合、蓄積する期間やサンプリングの間隔によってProxyが管理するストレージを圧迫しかねないため、蓄積するデータをある程度可逆性のあるデータへ圧縮する方法をとることも可能である。たとえば、サービスのトラヒック量の時間的変動を、wavelet変換等を用いることにより、サービスのトラヒック特性を踏まえて圧縮することが可能になる。このときの圧縮に利用した関数や関数の入力パラメータ等の情報を蓄積データとして登録することもできる。ファイルがwavelet変換等で圧縮されている場合には、ファイルのフォーマットを読み取り、フォーマットを確認し、展開して利用する。

図３Ａのフォーマット変換部302は、送受信部303から受信したデータを解析し、Proxyが管理するいずれのサービスの入力値であるかを判定し、そのサービスの入力フォーマットへ変換処理を行う機能を持つ。フォーマット変換ルールはサービス管理テーブル305で管理されており、受信データの中に記載されたサービス識別子や処理識別子等をキーとして変換ルールを取得する。すなわち、フォーマット変換部302は、取得した情報を基にサービス管理テーブル305を参照して、処理内容を決定し、必要であれば、受信データを処理内容に合わせてフォーマット変換を行う。異なるデータセンタ間でサービスを連携させる場合、サービス間のインタフェースの違いを吸収するモジュールが必要になる場合がある。これに対し、サービスを開発する際にサービスの入出力を定義する、図示を省略したインタフェース定義ファイルを作成し、サービス連携時に、入力側のインタフェース定義ファイルと出力側のインタフェース定義ファイルを比較し、変換ルールを作成することで対応できる。

この変換ルールは、図５を用いて説明するサービス管理テーブル305の変換ルールと同義である。たとえば、インタフェースがXML（eXtensible Markup Language）であれば、XSLT(XML Stylesheet Language Transformations)で作成された変換ルールファイルを作成することになる。そこで、このときの変換ルールに関してはサービス管理テーブル305を参照する。

図５に本実施例のサービス管理情報を記録するサービス管理テーブル305の一例を示した。サービス管理テーブル305はサービス間の連携方法を記載したサービス管理情報を示すデータを保存するテーブルであって、データセンタ内のサービスを管理するProｘｙ毎に持つ管理テーブルである。Proxyはデータセンタ内のサービスグループを管理するため、サービスグループが複数存在すれば、Proxyも複数存在してもよく、その場合、サービス管理テーブルはProxy分存在する。

このサービス管理テーブル305は、RAM(Random Access Memory)やHDD(Hard Disk Drive)などの記録用媒体、記憶装置に蓄積されており、例えばデータベースのようなソフトウェアで管理されている。前段のProxyが送信してきたサービスリクエストに対して、いずれのサービスへ処理を振り分ければよいかを判断し、リクエストの値とProxyが管理するサービスの入力値が異なる場合であれば、それを変換するためのルールを持つ。さらに、サービスの処理結果の送信先をも管理する。

図５において、符号601はサービス名、符号602はサービス識別子、符号603は処理識別子、符号604は送信元情報、符号605は振分ルール、符号606は送信先情報、符号607は変換ルール、符号608は連携サービス識別子である。この連携サービス識別子608は複数サービスが連携して、１つのサービスを提供するときのサービス識別子を示す。本実施例では使用しないが連携サービス毎に優先順位を付ける場合に、他データセンタ等からのリクエストと優先順位を対応づける場合に利用する。

ここで、サービス名601はProxyが管理しているサービス名である。サービス識別子602はProxyが管理しているサービスの識別子を示す。サービス振分部604においてデータセンタ内のサービスを呼び出すときに利用する。処理識別子603は同じ連携サービスで、複数回同じサービスを利用する場合の識別情報をとして利用する。送信元情報604はサービスの要求元情報を示す。サービス要求元に対して他データセンタへの負荷分散指示を出すことから、サービス要求元のProxyに接続でき、さらに要求元のサービスを特定できる情報を登録する。例えば、Proxyへの接続URL(Uniform Resource Locator)、及びサービス識別子である。振分ルール605は複数のデータセンタに対して処理振り分けを実施する場合の振分ルール及び重みを示す。送信先情報606は振分ルール605に従って処理を依頼するためのURI（Uniform Resource Identifier）を示す。具体的には、振り分け先のサービスが特定できるURLである。変換ルール607はProxyでサービス要求を受信した際に、サービスの入力フォーマットに変換するためのルールを示す。ここでは入力情報としてXML (Extensible Markup Language)を受信したことを想定し、変換するためのXLST(XML Stylesheet Language Transformations)ファイル名を例に示した。

図３Ａのフォーマット変換部302でフォーマット変換された受信データは、サービス振分部304に転送され、該当するサービスへ処理を依頼する。フォーマット変換部302がサービス振分部304にデータを転送する。

サービス振分部304は、処理内容に従い、該当するサービスへ処理を依頼する。サービス振分部304はフォーマット変換部302、サービス301と接続され、フォーマット変換部302もしくは送受信部303から転送されたデータを、サービス管理テーブル305記載のルールに従って、該当するサービスへ当該データを転送する。このとき依頼するサービスは、当該Proxyが管理するサービス301である。

サービス301は、後で説明するデータセンタ(DC)内の仮想マシン等の上で動作するプログラムであり、送受信部303、サービス振分部304と接続されている。サービス301は処理を完了すると送受信部303へサービス情報と処理識別子とともに処理結果を転送する。送受信部303は、各サービスからの処理結果を受け、サービス管理テーブル305を参照して、次の転送先サービスを検索してWAN経由で送信する。

一方、図３ＡのQoS監視部310は、以上の説明したサービスへのリクエストが随時発生している際に、送受信部303からのサービスごとのスループットを参照してQoS違反が発生していないかを監視する。QoS監視部310は、送受信部303、サービス振分判断部307と接続され、送受信部303を常時監視し、サービス毎のQoSをチェックする。QoS定義テーブル記載の確認項目に対して違反を検出するとQoS監視部310は、サービス振分判断部307に対してサービス識別子と違反内容を通知する。違反情報の検出方法の例として、QoS定義テーブル314には応答時間に対して単位時間内における許容可能な違反回数が記載されており、その回数を超えた場合にサービス振分判断部307に対して応答時間を超えたことを通知するなどである。すなわち、QoS監視部310によって違反が検出された場合、サービス振分判断部307にその違反情報が転送される。

なお、図３ＡのQoS定義テーブル314は、Proxyが管理するサービスのQoS情報が登録されたテーブルである。サービス毎に定義された同時接続可能数や応答時間等の性能情報が登録されている。本情報は、サービス提供者がSLA(Service Level Agreement)として顧客(クライアント)と締結した内容に関連して定義される情報である。図１０に本実施例で用いるQoS定義テーブル314の一構成例を示した。

図１０に明らかなように、QoS定義テーブル314は、サービス名1001毎に、サービス識別子1002、同時接続可能数1003、応答時間1004、利用帯域上限値1005が蓄積されている。サービス名1001はProxyが管理しているサービス名を示す。サービス識別子1002はProxyが管理しているサービスの識別子を示す。次に説明するサービス振分部307においてデータセンタ内のサービスを呼び出すときに利用する。同時接続可能数(単位時間当たり)1003はサービスが単位時間当たり接続できる接続数を規定する。応答時間1004はここではProxyにリクエストが到着して、サービスが実施されてProxyを経由して応答をかえすまでの時間をさす。利用帯域上限値1005は契約上サービス毎に規定されている利用帯域の上限値を示す。

図３Ａのサービス振分判断部307は、事前に負荷予測部306から各サービスのリクエスト状況予測値を取得し、受け取った違反情報と合わせて他データセンタへ振り分けるか、当該Proxyが存在するデータセンタ内のリソース再割当によって処理性能を向上させるかを判断する。すなわち、サービス振分判断部307は、負荷予測部306、QoS監視部310、振分け先決定部312と接続され、QoS監視部310が検出した違反情報と、後で説明する負荷予測部306が計算した今後の負荷予測結果を基に、他データセンタへ処理を振り分けるか、内部のリソース再割り当てで対応可能かを判断する。

振分け先決定部312は、サービス振分判断部307の判断の結果、他データセンタへ処理振り分けを実施する場合、候補となるデータセンタを検索して決定する。この検索方法は、既に候補として登録されているデータセンタ（DC）の中からサービスの要求性能、及びQoS定義テーブル314記載のサービス品質を提供するのに十分なリソースが存在するか否かを登録情報の中から検索してもよいし、現状に沿った振り分けを実施するのであれば、登録情報の検索結果に加えて現在の負荷情報をとり合わせるインタフェースを用いて、候補となるデータセンタ（DC）に問い合わせてもよい。振り分け先のデータセンタが決まると、必要であればサービスイメージ及び処理結果の転送先を記載したサービス管理テーブル305を該当するデータセンタへ転送して、サービスの起動を行う。

他データセンタへ処理振り分けを行う際、制御用送受信部313を経由して、前段サービスを管理するProxyへ振り分け処理を依頼する。振り分けルールはQoS情報策定部311で作成したQoS情報を基に作成する。内部リソースの再割当を行う際には、同じ連携サービスで利用するサービスをグルーピングし、可能な限り同じ物理サーバ上で処理を実施させることによって、サービス要求時に発生する通信を軽減させることが可能になる。

QoS情報策定部311は、振分け先決定部312、制御用送受信部313と接続され、振分け先決定部312の振分け先決定を受け、リクエスト振り分け率及びQoS情報をあらたに作成する。例えば、応答時間は元のQoS情報と同じにし、同時接続可能数を現在のデータセンタ分と振分け先のデータセンタ分で分割する。分割にあたり、負荷予測部306による負荷変動データセンタの能力を超える場合、超えた分を他データセンタへ処理を振り分ける。振り分ける際には、上述のとおり、前段のサービスを管理するProxyに対して振り分け処理を依頼する。

QoS情報策定部311は、受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーにサービス管理テーブル305で変換先のサービス名と変換ルールを検索し、フォーマット変換部302に変換ルールとサービス名、受信データの本体部を送信する。

ここでは、複数のデータセンタがユーザシームレスに連携してサービスを提供する場合、その複数のデータセンタのリソースは１つのデータセンタのリソースとして見えることが望ましい。その時、複数のデータセンタが提供する同時接続可能数を合わせた数をQoS情報として定義できることを想定している。また、当該Proxyが存在するデータセンタにおいて、十分なリソースが存在し、かつサービスの契約帯域上限値まで当該サービスが利用していない場合には、制御用送受信部313から、管理装置であるDC管理ノード317に対してリソース再割当要求である構成確認要求316を送信し、負荷予測に合わせたサーバリソース、ネットワークリソースを再割当てる。他データセンタ(DC)332を利用した処理振り分けによるQoS違反の回避、及びデータセンタ内の余剰リソースの再割当によるQoS違反の回避は、実施するまでのコストを考慮し、まずは後者を優先的に実施し、他データセンタへの処理振り分けはその後に実施することが望ましい。後者においても、サービス管理情報等の必要な情報が、他データセンタ(DC)332のプロキシに送信される。

制御用送受信部313は、QoS情報策定部311、Cloud Manager 318、他DC332、管理装置であるDC管理ノード317と接続され、サービス管理情報、QoS情報や、構成確認要求316などの情報等を送受信するインタフェースである。なお、DC管理ノード317は構成確認要求316を受信すると、その内部に構成確認要求テーブルを作成することもできる。構成確認要求テーブルの構成は、図５を用いて説明したサービス管理テーブルと同様な形式となり、その一例を図１２として示したが、図５のサービス確認要求テーブル同様、振分ルール605も記録しても良い。その内容は、図５と同様であるのでここでは図示、説明を省略する。すなわち、番号1201〜1207は図５の番号601〜607に対応している。

負荷予測部306は、制御用送受信部313、サービス振分判断部307と接続され、前段サービスと連携したサービスを提供するサービスが存在し、該サービスは前段サービスの負荷変動に関連した負荷変動とすることを想定した場合、前段のサービスの直近の負荷変動を取得することで、過去の変動履歴と合わせて、該サービスの負荷変動を予測する。

図３Ａにおいて、WANに接続される前段サービスのサービス309は、受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーに、サービス変換テーブルから変換先のサービス名と変換ルールを検索し、フォーマット変換部に変換ルールとサービス名、受信データの本体部を送信する。同様に、後段サービスのサービス315は受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーにサービス変換テーブルから変換先のサービス名と変換ルールを検索し、フォーマット変換部に変換ルールとサービス名、受信データの本体部を送信する。

Cloud Manager318や他DC332は受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーにサービス変換テーブルから変換先のサービス名と変換ルールを検索し、フォーマット変換部に変換ルールとサービス名、受信データの本体部を送信する。

図３Ｂは、以上説明した、実施例１のプロキシ(Proxy)における負荷予測から振り分け処理実施までのシーケンスの一例を示す図である。まず、制御用送受信部313は、前段サービス負荷情報を負荷予測部306に送信する（S406）。負荷予測部306は、受信した情報の復号化処理を行い（S407）、予測期間等のパラメータ設定を行い（S408）、トラフィック量予測処理を行い、予測情報をサービス振分判断部307に送信する（S409、S410）。サービス振分判断部307は回線帯域確認を行い（S411）、回線帯域超過分の振分け先決定依頼を送信する（S412）。依頼を受けた振分け先決定部312は、超過分の振分け先決定を行い(S413)、QoS情報策定依頼と共に、決定した振分け先一覧と振分けスループットをQoS情報策定部311に送信する（S414）。QoS情報策定部311は、振分けたトラフィックそれぞれに対しQoSを設定する（S415）。設定したQoS情報を振分ルールとしてサービス管理テーブル305に格納する（S416）。

なお、以上説明した実施例１のデータセンタ(DC)のプロキシ(Proxy)における振分け処理方法の変形例を説明する。本実施例のデータセンタ間連携サービスシステムに利用される、いずれの通信回線も有限であることから、効率的に通信回線を使用できるように、夫々のサービスに優先度を設定する。

すなわち、複数のサービスで使用する通信回線が競合し、他の要素で通信帯域の割り当てを解決できなかった場合に、振分け先決定部312は、図６に示す優先度制御管理テーブル609を利用して、割り当てる通信帯域の内訳を決定することができる。同図の優先度制御管理テーブル609は、サービス識別子602に対応する優先度制御情報610を記録する。この優先度制御管理テーブル609はサービスを管理するProxy単位で存在し、Proxyが存在するデータセンタ内サービスの優先順位を定義するものである。この優先度制御管理テーブル609は、図５に示したサービス管理テーブル305を拡張する形で蓄積することも可能であるが、別個に用意する形でも良い。

以上のように、プロキシ(Proxy)が各サービスにおいて、複数のサービス間の使用帯域の割り当てを調整する際に、振分先決定部312は、この優先度制御管理テーブル609を参照して優先度の高いサービスから帯域割り当て実施する。

図６に示すように、優先度制御情報記載の優先度は３種類存在し、優先順位の高いほうから帯域保証型、帯域確保型、ベストエフォート型とする。帯域保証型は、サービスを提供する上で決められた最大帯域を保証するものであり、他の優先度を持つ連携サービスと使用回線が競合した場合、優先的に通信帯域を割り当てる。帯域確保型は、使用回線の通信帯域に余裕がある場合は、必要な通信帯域を割り当てるが、帯域保証型のサービスと帯域確保型のサービスで使用回線が競合する場合には、帯域保証型のサービスを優先して帯域を割り当て、帯域確保型サービスの使用帯域は要求帯域以下で運用することを許容する。また、ベストエフォート型の連携サービスと使用回線が競合する場合には、帯域確保型のサービスに優先的に帯域を割り当てる。ベストエフォート型は、最大帯域は決められているが、その帯域を保証されない。サービスを提供するタイミングで使用回線の帯域が余っていなければ、大きな遅延が発生する可能性もある。

図７は第１の実施例におけるデータセンタ（DC）構成の一具体例を示す図である。このデータセンタ（DC）は、図１のDC1、DC2、DC3、DC４に対応する。同図に示すように、データセンタ(DC)は、DC管理ノード、プロキシ(Proxy)、通信制御装置、複数の物理マシン、及び記憶装置から構成されている。

符号501はサービスグループ構築部、符号502はサービス構成情報、符号503は機器構成情報、符号504はネットワーク構成情報、符号505はネットワーク構成情報収集部、符号506はサービス稼働情報、符号507は制御パラメータ生成部、符号508はDC管理ノード、符号509は物理マシン、符号510はWAN、符号511は通信制御装置、符号512は物理マシン、符号513は仮想マシン、符号514は仮想マシン、符号515は仮想マシン、符号516は仮想マシン、符号517は仮想マシン、符号518はServiceA、符号519はServiceB、符号520はServiceC、符号521はServiceD、符号522はServiceD、符号523は構成確認要求、符号524は制御用送受信部、符号525は送受信部である。

図７のデータセンタ（DC）構成において、物理マシン509はデータセンタ内において業務向けの情報処理を行うサーバ、すなわち情報処理装置337である。物理マシン509のハードウェア構成については、図示を省略した、一般のサーバの処理部であるＣＰＵ(Central Processing Unit)や記憶部であるメモリ等から構成されるコンピュータの構成と同じである。WAN510はデータセンタ(DC)が接続される広域ネットワークの一例である。通信制御装置511はいわゆるスイッチやルータ等に代表される通信装置であり、通信装置335に対応するる。利用しないポート等を発見した場合には、外部からポートやNIF(Network Interface)単位で省電力化モードにする機能を持っていることが望ましい。仮想マシン513は、例えばXen等の通常の仮想マシンをさす。サービスを実行するための動作環境をこの仮想マシン上に構築する。サービス構成情報502、機器構成情報503、ネットワーク構成情報504、サービス稼働情報506は、データセンタ(DC)の磁気記憶装置等の記憶装置に記憶されている。この記憶装置は、記憶装置338に対応している。

また、ServiceA518はソフトウェアで実装されたアプリケーションであり、図７の例においては、ServiceD522と接続されている。ServiceB519はServiceD522と接続されている。ServiceD522はServiceB519、ServiceA518と接続されている。これらのサービスは、図３Ａのサービス301に対応していることは言うまでもない。

Proxy内の送受信部525は、他データセンタやクライアントとサービスに関する情報をやり取りするインタフェースである。他データセンタやクライアントからProxyが管理するサービスへのRequestを受信し、処理結果を他のデータセンタやクライアントへ送信する。サービスのRequestには、SOAP(Simple Object Access Protocol)やREST(Representational State Transfer)のような分散処理システムで利用するメッセージ交換プロトコルを想定している。送受信部525では、受信データをフォーマット変換部へ転送、さらにはサービス処理結果に対して、先に説明したサービス管理テーブル305から送信先を参照し、ヘッダ情報を付けて送信する役目を持つ。なお、この送受信部525と制御用送受信部524は、それぞれ図３Ａの送受信部303と制御用送受信部313に対応する。

図７において、Proxyの制御用送受信部524からDC管理ノード508に対して、サービス管理テーブル305から自データセンタが送信元情報、送信先情報両者とも記録されていないサービスに関する情報は削除し、図３Ａの構成確認情報316相当する構成確認要求523として送信する。同じくDC管理ノード317に対応するDC管理ノード508は構成確認要求523を受信してサービスグループ構成部501によって、隣接するサービスごとにグルーピングする。また、連携サービスが異なる場合でも、同じサービスを利用している場合もグルーピングの対象とする。そして、その内部に構成確認要求テーブルを蓄積することができる。

その後、DC管理ノード508は、サービス構成情報502及びサービス稼働情報506、機器構成情報503を記憶装置から取得し、各サービスが動作している仮想マシンと物理マシンの対応を確認し、グルーピングの結果と対応結果とが異なる場合に、移行コストが一番小さい仮想マシンを見つけ出す。ネットワーク構成情報収集部505によってネットワークトポロジーを確認でき、トラヒックが削減されたことを確認する。以上のように移行する仮想マシンを発見すると、移行に関して必要なマイグレーション（Migration）に関するサーバやスイッチ、ソフトウェアに対する制御方法を制御パラメータ生成部507で生成し、実際の物理マシンへの制御を実施する。

より具体的に説明すると、サービスグループ構築部501は、送信されてきた構成確認要求523に対して、前後に隣接するサービスや、同じサービスを利用している連携サービスなど、いくつかの状況に合致したサービスを後で説明する手法でグルーピングし、現在のサービス構成情報及び機器の構成情報を考慮して、移動コストが一番少ない仮想マシンを検索する。

サービス構成情報502はデータセンタ内の物理マシン、仮想マシン、サービスの組み合わせにおいていずれのサービスがどこの物理マシン、仮想マシンで動作しているかを把握するための情報である。機器構成情報503はデータセンタ内の機器情報を把握するための情報であり、物理マシン509、512や通信制御装置511が何台存在し、何台稼働しているかを把握する。ネットワーク構成情報504は物理マシンや通信制御装置などの物理的なネットワークの接続関係について把握するための情報である。ネットワーク構成情報収集部505はネットワーク構成情報を収集し、現在のネットワークトポロジーを作成する。物理マシン、仮想マシン、ネットワークトポロジーの情報を基に、マイグレーションの結果利用しないマシンやネットワークがあるか否かを検索し、検索の結果利用しないノード等が有った場合、対象となるノードを省電力化モードにして電力を削減する。

サービス稼働情報506はサービスが現時点どのくらい稼働率で動作しているのかを把握するための情報である。サービス毎の負荷変動情報を格納するである。制御パラメータ生成部507はサービスグループ構成部501とネットワーク構成情報収集部506の結果を反映するために、実際の制御パラメータに変換して制御を行う。機器によるインタフェースの違い等はここで吸収する。DC管理ノード508はデータセンタ内の情報処理リソースを統合管理する。リソースを監視し、稼働状況に合わせて仮想マシンの集約/分散を実施することによってデータセンタ内の省電力化を実現する。基本的には、サービスの稼働情報や機器構成情報等の収集機能を持っていればよい。

以上、図７を用いて本実施例におけるデータセンタ(DC)の構成の一具体例を説明したが、その構成の変形例を図８Ａと図８Ｂを用いて説明する。

まず、図８Ａにデータセンタ（DC）内のプロキシ(Proxy)のソフトウェアバージョンを示す。同図に見るように図３Ａを用いて詳述したプロキシ(Proxy)を図７の物理マシン上の仮想マシンの１つで構成する変形例である。同図において、図７と同一符号は、同一物を示している。プロキシ(Proxy)531は複数の物理マシンが収納されたサーバラック529中の物理マシン512の上に形成された仮想マシン530によって実現される。図７の構成同様、各種のプロキシ機能を実現すると共に、制御用送受信部532と送受信部533により、通信制御装置526、528、511、更には534を介して各種の通信を行う。

一方、図８Ｂに、データセンタ（DC）内のプロキシ(Proxy)のハードウェアバージョンを示す。同図に見るように図３Ａで詳述したプロキシ(Proxy)を、通信制御装置中に設置された拡張ボード上で構成する変形例である。同図において、図７と同一符号は、同一物を示しているが、一部符号表示を省略した。本変形例においては、通信制御装置５３４上の拡張ボード535にプロキシ(Proxy)536が構成され、プロキシ機能を実現すると共に、制御用送受信部537と送受信部538により各種の通信を行う。

図９Ａ、図９Ｂは実施例１における、データセンタ内のリソース割当時の動作を示すフローチャートを示す図である。すなわち、データセンタ（DC）内の情報処理位置を決定するためのフローチャートである。なお、フローチャート（１）、（２）は連続するフローチャートであり、丸印のＡ、丸印のＢにおいて連続する。本フローチャートでは、連携するサービスでグルーピングをし、サービス間のデータ受け渡しをサーバ内のメモリ上での受け渡しで完了するようにすることでネットワーク上の通信量を削減することを可能にする。

まず、ステップ901はProxyの制御用送受信部からDC管理ノードに対して構成確認要求とQoS管理（定義）テーブルを送信し、DC管理ノード317が受信を行う処理である。

ステップ902はDC管理ノード317で構成確認要求523を受信し、サービスグループ構築部501においてサービスグルーピング開始し、内部に保持する構成確認要求テーブル等を用いて、同じ連携サービス内で接続関係にあるサービスの存在を確認する処理である。すなわち、送信元情報及び送信先情報を参照し、あるサービスの送信元情報が、あるサービスの送信先情報になっていることを確認できるかを調べる処理である。もしあるサービスの送信元情報があるサービスの送信先情報になっていることを確認できれば、ステップ903へ進む。送信元情報及び送信先情報を参照し、あるサービスの送信元情報があるサービスの送信先情報になっていることを確認できなければ、ステップ914、すなわちENDへ進む。

ステップ903はグループ番号を発番し、該当するサービスにグループ番号を付与する処理である。

ステップ904はグループが存在する複数の連携サービスにおいて、グループ間で同じサービスが存在するか否かを確認かどうか調べる処理である。もしグループが存在する複数の連携サービスにおいて、グループ間で同じサービスが存在するか否かを確認できれば、ステップ905へ進む。もしグループが存在する複数の連携サービスにおいて、グループ間で同じサービスが存在するか否かを確認できなければ、ステップ906へ進む。

ステップ905はグループ番号を発番し、該当するグループにグループ番号を付与する処理である。

ステップ906で、DC管理ノード908は、機器構成情報903とサービス構成情報902から現在のサービス配置状況を取得する。

続いて、図９Ｂのフローに移り、ステップ907で、グループごとにサービスが物理マシン上に集約するようにサービス配置案を作成する。

ステップ908において、作成した配置案のうち、グループ内のサービスの帯域変動の時間変化予測値を重畳させ、物理マシンの持つ通信帯域を超えないサービスの組み合わせを持つ配置案を抽出する。

ステップ909において、抽出した配置案のうち、グループ内のサービスの負荷変動の時間変化予測値を重畳させ、物理マシンのCPU使用率が100％以下になるサービスの組み合わせを持つ配置案を抽出する。

更に、ステップ910において、抽出した配置案のうち、サービスの移動コスト、すなわち、転送時間、転送時の消費電力が最小になる配置案を抽出する。

ステップ911において、抽出した配置案をもとに、VLAN(Virtual LAN)の設定を実施し、ステップ912において、該当するサービスに対して移動指示を発行する。

ステップ913において、負荷分散装置の振分け先を設定し、終了する（ステップ914）。

なお、以上説明したデータセンタ(DC)内のサービスグループ構築部501でのサービスグルーピングの処理フロー（901-914）の理解を助けるため、図１１のタイミングチャートとしてその概略を示した。同図におい明らかなように、子管理ノードであるDC管理ノード(DC1)1102中のプロキシ(Proxy1)1104が、構成確認要求とQoS定義テーブルをDC管理ノード(DC1)1102に送信する（801）ことで処理が開始される。

まず、子管理ノード(DC1)1102では、サービスグルーピング処理を開始する(801、802、803)。すなわち、DC内で同じ連携サービスに属するサービスを検索する(804)。もし、同じ連携サービスに属するサービスを発見した場合、グループ番号（ID）を発番し、サービス管理テーブルに登録する(805)。複数のグループの中から重複するサービスを持つグループを検索し(806)、重複するサービスを持つグループを発見した場合、新たにグループIDを発番し、サービス管理テーブルに登録する(807)。全ての検索終了後、グループIDと各サービスの移動コストを基にして、サービスの配置を決定し(808)、サービスの移動を指示する(809)。

以上、実施例１における、Proxyを利用したサービス振り分け方法を説明してきた。本実施例の方法では、応答時間と同時接続可能数で性能を評価しながら目的とするサービスのQoSを管理している。過剰なリソースが動作していることを検知すると、負荷に応じて過剰なリソースを省電力モードに移行させ、データセンタ内の消費電力を低減するシステムにおいて、データセンタをまたいで複数サービスが連携する場合、前段のサービスの稼働状況に応じて、後段のサービスを処理するためのリソースを増加させる。

そのとき、前段のサービスは、常時サービスの負荷を計測しているデータセンタ内のDC管理ノードで、各サービスでQoSを違反した場合、スタンバイ状態のリソースを割り当て、即時対処するが、急激な負荷が発生した場合には、対応できず、複数のサービスを連携させて提供するサービスでは、QoS違反が他のサービスへも伝搬し、元々の違反以上の遅延や接続数の低下につながる可能性がある。

そこで、複数のDC内のサービスを管理するProxyと、これら複数のProxyを管理する親管理ノード(Cloud Manager)を連携させ、この親管理ノードで、違反の伝搬を事前に検知して、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証することを可能にする。

第２の実施例として、複数のProxyを管理する親管理ノード(Cloud Manager)で違反の伝搬を事前に検知して、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証することを可能とするネットワークシステムについて説明する。

図３Ａ、図７等に示したように、各データセンタ(DC)には、管理装置としてのDC管理ノードが設置されているが、第２の実施例のネットワークシステムには、WAN等の広域ネットワークを介して、複数のデータセンタ（DC）の複数の管理装置、すなわち複数のDC管理ノードと情報を送受信可能な、親管理装置としての親管理ノード(Cloud Manager)318が設置されており、この親管理ノード(Cloud Manager)318は、実施例１のおける、各Proxyから取得できるサービス情報を基に接続関係と接続方法を決定し、各Proxyに対してサービス連携情報を送信するよう機能することに加え、違反の伝搬を事前に検知し、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証する。

図１３に、本実施例における親管理ノードが、システム全体で自律的にQoSを保証する機能を説明するシーケンス図である。なお、図３Ａ等で説明した各データセンタ(DC)内の管理ノードを本実施例の説明においては、子管理ノードと呼び、親管理ノード(Cloud Manager)と区別する。

まず、図１３において、データセンタ(DC1)の子管理ノード1102がデータセンタ(DC1)のプロキシ(Proxy)1104に対して、サービスIDリストと各サービスのQoS定義テーブルを送信する(1106、1107)。この送信を受け、プロキシ(Proxy)1104は、サービス(Service)IDリスト記載のサービスを監視対象に登録し(1108)、サービスが利用する通信帯域の監視を開始する(1109)。そして、サービスの通信帯域のQoS警戒点超えを検出した場合(1110)、検出したサービスのService IDを子管理ノード1102に送信する(1111、1112)。

子管理ノード1102は移行先要求条件を決定し(1113)、決定した移行先要求条件を親管理ノード(Cloud Manager)1101に送信する(1114、1115)。親管理ノード1101では、移行先要求条件に合致するデータセンタ(DC)リストを作成し(116)、作成したDCリストを要求元の子管理ノード1102送信する(1117、1118)。

子管理ノード1102ではDCリストを受け、DCリストのRTT(Round Trip Time)を調査して、優先順位決定を行い(1119)、優先順位上位のものからサーバのリソース確認要求を、決定したデータセンタ(DC2)の子管理ノード(DC2)1103に送信する(1120)と共に、直近未来のService 1のトラフィック変動を算出し(1121)、算出したService 1のトラフィック変動データ送信を行う(1122)。トラフィック変動データを受信した子管理ノード(DC2)1103では、Service2が動作するサーバを優先的に、Service1のトラフィックと重畳できるサービスの検出を行い(1123)、検出後、子管理ノード (DC2)1103にＯＫを返信する（1124）。

返信に応答し、子管理ノード(DC1)1102は当該サービスの対象となるイメージデータ等と負荷分散制御ルールを子管理ノード(DC2)1103に送信する(1125)。子管理ノード(DC2)1103はそのイメージデータ等を該当するサーバに送信し(1126)、例えば、ＶＭＷａｒeを利用するシステムにあっては、vCenterに登録し(1127)、負荷分散装置へ負荷分散制御ルールを設定し(1128)、完了通知を行う(1129)。

更に、本実施例おける親管理ノード1101が更に、データセンタ(DC)間の仮想マシン(VM)の配置最適化処理を施すよう機能する場合について説明する。

図１４に本実施例に係わる、データセンタ(DC)間仮想マシン(VM)配置最適化処理を示すシーケンス図である。同図において、Cloud Serverである親管理ノード1101はサービスのフロー情報を各データセンタ(DC)の子管理ノードに対して定期的に収集を行う（1408）。この定期的な情報収集は、図１２の場合、子管理ノード1102、1103、1130に対し順次フロー情報取得要求を送信し（1409、1411、1413）、サービス単位のフロー情報を収集する(1410、1412、1414)。

取得したサービスフロー情報からデータセンタ(DC)間でデータの送受信が存在するDCを複数(DC1,DC2)選択し(1415)、選択したDCのリストを作成し（1416）、最適化処理指示とDCリストを送信する（1417、1418）。DC2 1103に移動可能仮想マシン(VM)リスト要求を行う(1418)。これに対応し、DC2 1103において、各サービスの移動制約条件を基に、DC1 1102へ移動可能なVMリストを作成し(1420)、DC1 1102に送信する（1421）。

これを受け、子管理ノードDC1 1102では、図１２のステップ1422〜1429を実行する。すなわち、選択したVMが動作中の物理サーバのCPU負荷情報及びと送受信しているトラヒックの時系列データの予測値を取得(1423)、選択したVMのフロー情報とVMリストを基に選択したVMと通信が発生しているVMを検索(1424)、検索結果とDC１内で選択したVM以外のVMのCPU利用率及びトラヒック量の時系列データの予測値を選択したVMが動作中の物理サーバのそれに時間を合わせて重ね合わせ(1424)、CPU利用率が１００％、トラヒック量が物理サーバに接続された回線条件を超えないVMを検索(1426)、物理サーバにVMが一番たくさん搭載される場合を最適解とし、集約するVMのリストを作成(1427)、集約VMリストを基に、VMを物理サーバに移動(1428)、VMの集約が終了し、これまで選択されていないDC1内のVMを選択し、移動可能VMリスト要求から繰り返し実施する(1429)。

本実施例によれば、複数のProxyを管理する親管理ノード(Cloud Manager)で違反の伝搬を事前に検知して、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証することを可能となる。さらに、親管理ノード(Cloud Manager)により、データセンタ(DC)間の仮想マシン(VM)の配置最適化処理を施し、システム全体で自律的にQoSを保証し、省電力化を図ることができる。

なお、本発明の種々の実施例について説明してきたが、本発明はこれらの実施例に限定されるものなく、様々な変形例が含まれうることは言うまでもない。上述した実施例は本発明のより良い理解のために説明したものであり、本発明はそれに限定されるもので無い。また、ある実施例構成の一部を他の実施例の構成に置き換えることも可能であり、ある実施例の構成に他の実施例の構成を加えることも可能である。また、上述した各実施例の構成、機能、処理手段等は、それらの一部又は全部をソフトウェア構成のみならず、専用のハードウェア構成、あるいはそれらを共用した構成としても良いことは言うまでもない。

また、以上詳述した本発明の開示内容から明らかなように、特許請求の範囲に記載された請求項に係る発明以外の発明も、本願明細書に多数存在する。その一部を例示すれば下記のとおりである。

例示１：ネットワークシステムは外部のネットワークシステムからの要求に対してサービスを提供するシステムであって、当該ネットワークシステムは当該サービスを管理するソフトウェアと、前記ソフトウェアと連動してネットワークシステムを構成する情報処理装置や通信機器などの管理を行う管理装置と、当該ネットワークシステムを構成し、当該サービスを実行するための情報処理装置及び通信装置によって構成された前記ネットワークシステムにおいて、サービスを実行する情報処理装置の位置を変更することでネットワークシステム内に発生する通信量を削減し、利用していない装置等の電力を下げ、さらには省電力向けのシステムが備わる装置については前記管理装置から省電力を実現する状態に変更することで、前記ネットワークシステム全体の省電力化を実現するリソース割当方法。

例示２：例示１のネットワークシステムを複数連動させることによって高負荷なサービス要求に対してもお応答性能を確保しつつ省電力化を実現できるネットワークシステム。

例示３：例示２の連動したネットワークシステムにおいて、ネットワークシステム上で提供するサービスを連携させることによって、前段で発生した高負荷なサービス要求に対しても、必要十分な資源を各ネットワークシステムから確保し、決められたサービス品櫃保証を実現することができる例示１のソフトウェア。

例示４：ネットワークシステムの構成要素を管理する管理装置がネットワークシステムとネットワークシステム外部のネットワークシステムをつなぐネットワークを管理する例示１のソフトウェアにおいて、前記ソフトウェアが管理するサービス間の連携方式が記載されているサービス管理情報を例示１の管理装置が前記ソフトウェアから取得し、前記管理装置が管理する情報処理装置及び通信機器を制御し、サービスの実行場所を決定することで通信量を削減することを可能にする管理装置。

例示５：例示１のネットワークシステムにおいて、当該ネットワークシステム以外の複数のネットワークシステムが提供するサービスとの接続関係が記載された前記ソフトウェアが管理するサービス管理情報。

例示６：例示３の前記ソフトウェアに関して複数のネットワークシステムにそれぞれ例示３の前記ソフトウェアと前記ソフトウェアが管理する例示５のサービス管理情報を所有させてサービスの接続関係を規定し、さらにそれぞれネットワークシステムが提供するサービスの入出力の違いを前記ソフトウェアで変換して吸収することで入出力の異なるサービス間を連携させることを可能にするサービス連携方法。

例示７：ネットワークシステムが提供するサービスを例示３のソフトウェアで管理し、さらにそれぞれのサービスのサービス品質をサービス品質定義情報によって管理することで、サービス品質の劣化を検知することが可能な例示３のソフトウェア。

例示８：ネットワークシステムが提供するサービスを例示３のソフトウェアで管理し、さらにそれぞれのサービスのサービス品質をサービス品質定義情報によって管理することで、サービス品質の劣化を検知することが可能なサービス品質定義情報。

例示９：ネットワークシステム内の通信量削減するためのサービスの実行位置を決定する例示４の管理装置において、前記実行位置を決定するために、前記ネットワークシステムが提供するサービスのソフトウェアの入出力先情報に対して当該ネットワークシステム外のサービスからの入力や当該ネットワークシステム外のサービスへの出力になる当該ネットワークシステムが提供するサービスを除いた情報として例示３のソフトウェアが生成して例示４の管理装置へ転送する構成要素確認要求情報。

例示１０：例示１のソフトウェアが実装されたサービス管理装置。

本発明はネットワークサービス運用システムに係り、特に、ネットワークサービスの品質の保証を行うネットワークサービス運用管理技術として極めて有用である。

101・・・Client
102・・・WAN
103・・・Cloud Manager（親管理ノード）
104・・・DC4
105・・・Proxy
106・・・serviceA
107・・・DC3
108・・・Proxy
109・・・serviceB
110・・・DC2
111・・・Proxy
112・・・serviceC
113・・・DC1
114・・・Proxy
115・・・serviceD
116・・・サービス連携情報
120・・・DNS
121・・・QoS情報(ServiceA)
124・・・QoS情報(serviceAtoD)
127・・・ServiceE
201・・・ServiceB
203・・・ServiceC
204・・・ServiceD
205・・・ServiceA
207・・・ServiceAA
300・・・データセンタ(DC)
301・・・サービス
302・・・フォーマット変換部
303・・・送受信部
304・・・サービス振分部
305・・・サービス管理テーブル
306・・・負荷予測部
307・・・サービス振分判断部
309・・・サービス
310・・・QoS監視部
311・・・QoS情報策定部
312・・・振分け先決定部
313・・・制御用送受信部
314・・・QOS定義テーブル
315・・・サービス
316・・・構成確認要求
317・・・DC管理ノード
318・・・Cloud Manager
332・・・他DC
333・・・トラフィック監視テーブル
334・・・監視部
335・・・通信装置
336・・・通信経路
337・・・情報処理装置
338・・・記憶装置（ソフトウェア）
339・・・DC管理ノード
401・・・サービス識別子
402・・・連携サービス識別子
403・・・圧縮フラグ
404・・・監視期間
405・・・データ参照先
501・・・サービスグループ構築部
502・・・サービス構成情報
503・・・機器構成情報
504・・・ネットワーク構成情報
505・・・ネットワーク構成情報収集部
506・・・サービス稼働情報
507・・・制御パラメータ生成部
508・・・DC管理ノード
509・・・物理マシン
510・・・WAN
511・・・通信制御装置
512・・・物理マシン
513・・・仮想マシン
514・・・仮想マシン
515・・・仮想マシン
516・・・仮想マシン
517・・・仮想マシン
518・・・ServiceA
519・・・ServiceB
520・・・ServiceC
521・・・ServiceD
522・・・ServiceD
523・・・構成確認要求
524・・・制御用送受信部
525・・・送受信部
526、527、528、534・・・通信制御装置
535・・・拡張ボード
601、1201・・・サービス名
602、1202・・・サービス識別子
603、1203・・・処理識別子
604、1204・・・送信元情報
605・・・振分ルール
606、1206・・・送信先情報
607、1207・・・変換ルール
608・・・連携サービス識別子
609・・・優先度制御管理テーブル
1001・・・サービス名
1002・・・サービス識別子
1003・・・同時接続可能数
1004・・・応答時間
1005・・・利用帯域上限値。

Claims

外部からのリクエストに対してサービスを提供するネットワークシステムであって、前
記サービスを実行するための情報処理装置及び通信装置と、前記サービスを管理するソフ
トウェアを記憶する記憶装置と、前記ソフトウェアと連動して前記情報処理装置及び前記
通信装置の管理を行う管理装置とを備え、
前記通信装置は、
前記リクエストを受信し、前記リクエストに対する前記サービスの処理結果を送信す
る送受信部と、
前記リクエストを解析し、前記サービスのいずれに対するリクエストかを判定した結
果に基づき、前記リクエストを振分けるサービス振分部と、
前記リクエストに対する、前記サービス毎のQoS違反を監視するQoS監視部と、
前記QoS監視部が、QoS違反を検出した場合、前記リクエストの処理を、前記ネットワ
ークシステム内のリソース再割当てで対応するか、他ネットワークシステムに振分るかの
判断結果に基づき、前記リクエストの処理の振分先を決定するサービス振分判断部と、
前記リクエストの処理を他ネットワークシステムに振分る場合に、前記サービスの優
先順位を定義する優先度制御管理情報に基づき、前記サービス毎に割り当てる通信帯域の
内訳を決定する振分け先決定部と、
前記リクエストの処理を前記ネットワークシステム内のリソース再割当で対応する場
合に、前記決定された振分け先に基づいて作成される構成確認要求を前記管理装置に送信
する制御用送受信部とを備え、
前記管理装置は、
前記構成確認要求に基づいて、前記サービスを実行する前記情報処理装置上の仮想計
算機の位置を変更する、
ことを特徴とするネットワークシステム。
請求項１に記載のネットワークシステムであって、
前記管理装置は、前記ネットワークシステム内に発生する通信量を削減し、電力を下げ
ることにより、前記ネットワークシステム全体の省電力化のために、前記仮想計算機の位
置を変更することを特徴とするネットワークシステム。
請求項２に記載のネットワークシステムであって、
前記通信装置は、前記振分け先決定部の決定を受け、リクエスト振分率及びQoS情報を
含むサービス管理情報を策定するQoS情報策定部を備え、
前記制御用送受信部は、前記QoS情報策定部が策定した前記サービス管理情報を、構成
確認要求とともに前記管理装置に送信する、
ことを特徴とするネットワークシステム。
請求項３に記載のネットワークシステムであって、
前記通信装置は、前記サービス管理情報をサービス管理テーブルに蓄積する、ことを特
徴とするネットワークシステム。
請求項４に記載のネットワークシステムであって、
前記通信装置は、前記サービス管理テーブルに管理する前記サービス管理情報として、
前記他ネットワークシステムが提供するサービスとの接続関係を記録する、
ことを特徴とするネットワークシステム。
請求項３に記載のネットワークシステムであって、
前記管理装置は、前記制御用送受信部から受信した前記サービス管理情報を用いて、前
記管理装置が管理する前記情報処理装置及び前記通信装置を制御し、前記サービスの実行
場所を決定する、
ことを特徴とするネットワークシステム。
請求項６に記載のネットワークシステムであって、
前記管理装置は、前記構成確認要求を受信した場合、前記サービス管理情報に基づき、
前記サービスに連携するサービスが存在するか否かを確認し、存在する場合にサービスグ
ルーピング処理を実行する、
ことを特徴とするネットワークシステム。
外部からのリクエストに対してサービスを提供するネットワークシステムのサービス品
質制御方法であって、
前記ネットワークシステムは、前記サービスを実行するための情報処理装置及び通信装
置と、前記サービスを管理するソフトウェアを記憶する記憶装置と、前記ソフトウェアと
連動して前記情報処理装置及び前記通信装置の管理を行う管理装置とを備え、
前記通信装置は、
前記リクエストを受信し、
前記リクエストに対する前記サービスの処理結果を送信し、
前記リクエストを解析し、
前記サービスのいずれに対するリクエストかを判定した結果に基づき、前記リクエスト
を振分け、
前記リクエストに対する、前記サービス毎のQoS違反を監視し、
前記QoS違反を検出した場合、前記リクエストの処理を、前記ネットワークシステム内
のリソース再割当てで対応するか、他ネットワークシステムに振分るかの判断結果に基づ
き、前記リクエストの処理の振分先を決定し、
前記リクエストの処理を他ネットワークシステムに振分る場合に、前記サービスの優先
順位を定義する優先度制御管理情報に基づき、前記サービス毎に割り当てる通信帯域の内
訳を決定し、
前記リクエストの処理を前記ネットワークシステム内のリソース再割当で対応する場合
に、前記決定された振分け先に基づいて作成される構成確認要求を前記管理装置に送信し
、前記ネットワークシステムの前記管理装置は、前記サービスを実行する前記情報処理
装置上の仮想計算機の位置を変更することにより、前記ネットワークシステム内に発生す
る通信量を削減し、電力を下げることにより、前記ネットワークシステム全体の省電力化
を図る、
ことを特徴とするサービス品質制御方法。
請求項８に記載のサービス品質制御方法であって、
前記通信装置は、前記リソース内の再割当てで対応すると決定した場合、サービス管理
情報を作成し、作成した前記サービス管理情報と構成確認要求を前記管理装置に送信する
、
ことを特徴とするサービス品質制御方法。
請求項９に記載のサービス品質制御方法であって、
前記通信装置は、前記サービス管理情報をサービス管理テーブルに蓄積すると共に、前
記サービス管理情報として、前記他ネットワークシステムが提供するサービスとの接続関
係を記録する、
ことを特徴とするサービス品質制御方法。
請求項９に記載のサービス品質制御方法であって、
前記管理装置は、前記通信装置から受信した前記サービス管理情報を用いて、前記管理
装置が管理する前記情報処理装置及び前記通信装置を制御し、前記サービスの実行場所を
決定する、
ことを特徴とするサービス品質制御方法。
請求項９に記載のサービス品質制御方法であって、
前記管理装置は、前記構成確認要求を受信した場合、前記サービス管理情報に基づき、
前記サービスに連携するサービスが存在するか否かを確認し、存在する場合にサービスグ
ルーピング処理を実行する、
ことを特徴とするサービス品質制御方法。
請求項９に記載のサービス品質制御方法であって、
前記サービス管理テーブルに、前記サービスの接続関係を規定し、更に前記ネットワー
クシステム各々が提供する前記サービスの入出力の違いを前記ソフトウェアで変換して吸
収することで入出力の異なる前記サービス間を連携させる、ことを特徴とするサービス品
質制御方法。
請求項８に記載のサービス品質制御方法であって、
前記通信装置は、前記リクエストの処理を、前記他ネットワークシステムに振分ると決
定した場合、前記リクエストに係るサービス管理情報を前記他ネットワークシステムに送
信する、
ことを特徴とするサービス品質制御方法。