以下、本発明の実施形態の例を添付図面に基づき説明する。各図における同一符号は同一物または相当物を示す。説明の都合上、符号に添え字を追加して区別することがある。
図1は、本発明の実施形態における分散処理システムの構成例を示すブロック図である。
本実施形態の分散処理システムは、管理装置101、1台以上のデータ転送装置103、およびユーザ端末104を備え、広域網102を介して互いに接続される。データ転送装置103には、それぞれサーバ105およびDNS(Domain Name System)106がLAN(Local Area Network)107を介して接続される。管理装置101、サーバ105、DNS106およびユーザ端末104の台数は、本実施形態の台数に限定されない。
データ転送装置103は、広域網102を介して管理装置101、他のデータ転送装置およびユーザ端末104と通信する。また、データ転送装置103は、LAN107を介してサーバ105およびDNS106と通信する。
データ転送装置103は、記憶装置120、CPU121、ネットワークI/F122から構成される。ネットワークI/F122は、広域網102およびLAN107と接続できれば良く、その数は問わないが、ネットワークI/F122の数を増やすことで、ネットワーク帯域のボトルネックの問題を改善できる。
図1には、一つのデータ転送装置103が広域網102に接続されるネットワークI/F122及びLAN107に接続されるネットワークI/F122を備える例を示す。図1では、これらが、枝番(1)および(2)を用いて、それぞれネットワークI/F122(1)および122(2)と表示される。以下、各ネットワークI/F122を区別して説明する必要がある場合には枝番を記載し、いずれのネットワークI/F122にも共通する説明をする場合(または任意のネットワークI/F122に関する説明をする場合)には枝番を記載しない。他の構成要素(例えばデータ転送装置103等)についても同様である。
CPU121とネットワークI/F122は共有バス123、記憶装置120とCPU121は共有バス124で接続される。共有バス123および共有バス124は、別の通信手段によって置き換えられてもよい。例えば、CPU121の数が多数の場合、通信ボトルネックを起こしやすい共有バス124ではなく、ネットワークオンチップ等を利用しても良い。
記憶装置120には、セッションDB(Database)131、サービスノードDB132、利用予約DB133、マップ結果DB134およびアプリケーショングラフDB135が格納される。これらの情報は、アドレス変換部140および装置連携部150によって作成されるものであり、詳細は後述する。記憶装置120としては半導体メモリDRAM(Dynamic Random Access Memory)、SRAM(Static Random Access Memory)またはCAM(Content Addressable Memory)等を利用することが考えられる。SRAM、CAMの利用によって、DBへのアクセス速度を改善できる。
CPU121は、プログラムであるアドレス変換部140および装置連携部150を実行する。アドレス変換部140および装置連携部150の機能の一部またはすべてを専用LSI(Large-Scale Integrated Circuit)またはFPGA(Field Programmable Gate Array)等のハードウェアで実装しても良い。ハードウェアとして実装することで、処理の高速化および省電力化が可能となる。
アドレス変換部140は、パケット解析部141、セッション管理部142、サービスノード管理部143、アプリケーショングラフ管理部144、利用予約管理部145およびマッピング計算部146から構成される。
パケット解析部141は、ネットワークI/F122から受信したパケットの送信元IPアドレス、送信元ポート番号、送信先IPアドレス、送信先ポート番号、プロトコル番号およびVLANなどを解析する。パケットのヘッダデータだけでなく、ペイロードデータを解析する形態も考えられ、この場合、サービスの機能選択、及び、同一のポート番号を使用する複数のアプリケーションの識別が可能となる。
セッション管理部142は、パケット解析部141の解析結果に基づいて、接続元と接続先との通信を管理する。セッション管理部142は、アドレス変換に必要なセッションDB131を操作(登録、削除、変更または参照)する。
サービスノード管理部143は、サービスノード登録I/F151およびサービスノード情報収集・交換I/F152と連携して、サービスノードの情報を格納するサービスノードDB132を操作(登録、削除、変更または参照)する。なお、後述するように、サービスノードとは、サーバ105またはデータ転送装置103に相当する。サービスノード管理部143は、サービスノード登録I/F151を通して登録されるサービスノードの稼動情報を、サービスノード情報収集・交換I/F152を通して収集し、必要に応じて他のデータ転送装置103に送信する。
サービスノードの収集する稼動情報としては、サーバ105のCPU演算速度、空メモリ量、ネットワーク帯域、およびネットワーク往復遅延等が考えられる。サーバ105の情報は、LAN107を通してSNMP(Simple Network Management Protocol)等を用いて収集する。他のデータ転送装置103の稼動情報は、広域網102を通してSNMP等を用いて交換する。稼動情報の収集・交換手段は、SNMPに限定されず、機器の識別子、稼動情報種別及び値を単純にテキスト形式で並べて送受信する実装の容易なプロトコルを用いても良い。
アプリケーショングラフ管理部144は、アプリケーションを構成するサービスの依存関係を格納するアプリケーショングラフDB135を操作(登録、削除、変更または参照)する。登録のための手法として、システム管理者が管理装置101を使用して手動で登録する手法のほか、データ転送装置103が、アプリケーショングラフを部分グラフに分割し、データ転送装置に再帰的に登録していく手法が考えられる。アプリケーショングラフは、サービスノードの利用予約時に、どのサービスノードに利用予約をするか判断するのに使用したり、実際に使用するサービスノードの選択時に使用したりする。アプリケーショングラフについては詳細を後述する。
データ転送装置103の利用予約管理部145は、他のデータ転送装置103から要求されるサービス利用予約を管理し、利用予約状況を格納する利用予約DB133を操作(登録、削除、更新または参照)する。利用予約I/F153を通してサービスの利用予約を受けたデータ転送装置103は、サービスを実行するのに使用されるサーバ105およびネットワークリソースの稼動情報を、サービスの利用予約を登録したデータ転送装置103に通知する。利用予約は、データ転送装置103に限らず、ユーザ端末104またはサーバ105等が行っても良い。
マッピング計算部146は、アプリケーショングラフおよびサービスノード情報に基づき、アプリケーションを構成するサービスを実行するサーバ群を選択する。サーバ群の選択指標としては、応答時間の短縮、サーバ負荷制御によるサービス実行の優先度制御、サーバ使用の片寄せによる省電力化等が考えられる。本実施形態では、アプリケーションの応答時間が最短となる手順を後述する。
装置連携部150は、サービスノード登録I/F151、サービスノード情報収集・交換I/F152、利用予約I/F153およびアプリケーショングラフ登録I/F154から構成される。各I/Fの通信シーケンスおよび通信内容については後述する。
ネットワークI/F122(1)は、広域網102を介して、管理装置101、他のデータ転送装置、およびユーザ端末104と通信するための装置であり、イーサネットなどの通信手段を用いることが考えられる。ネットワークI/F122(2)は、サーバ105およびDNS106と通信するための装置であり、ネットワークI/F122(1)と同様にイーサネットなどを利用できる。ネットワークI/F122は、CPU121の制御によって動作し、広域網102またはLAN107とのパケット入出力を実行する。
サーバ105は、LAN107を介して、データ転送装置103およびDNS106と通信する。サーバ105は、分散アプリケーションを構成するサービスを実行する。サーバ105では、SNMPエージェントが稼動し、サーバ105内のCPUおよびメモリ(図示省略)等の使用状況をデータ転送装置103に通知する。サーバ105は、分散アプリケーションのサービスが動作するのに必要な仕様(機種、性能等)を満たしていればよく、その形態は限定されない。例えば、サーバ105は、Linux等のOSが搭載された汎用PC(Personal Computer)等であっても良い。また、サーバ105は、物理的な装置ではなく、仮想計算機等の論理的な装置であっても良い。
DNS106は、LAN107を介して、データ転送装置103およびサーバ105と通信する。データ転送装置103のパケット解析部141およびサーバ105上のアプリケーションは、ホスト名からIPアドレスを取得する際に、DNS106にホスト名を送信し、対応するIPアドレスを得る。同様に、DNS106にIPアドレスを送信することで、ホスト名を参照することもできる。DNS106は、LAN107ではなく広域網102に接続されてもよい。
本実施例のLAN107は、イーサネット(登録商標:Ethernet)としたが、データ転送装置103、サーバ105およびDNS106が相互に通信できるかぎり、他の種類のネットワーク、例えば、Myrinet(登録商標)またはInfiniband(登録商標)等であってもよい。他の通信手段の利用によって、通信速度および遅延時間の改善が可能となる。
ユーザ端末104は、広域網102を介して、データ転送装置103と通信する。ユーザ端末104は、ユーザ端末用アプリケーションが動作するのに必要な仕様(機種、処理性能等)を満たしていればよく、その形態は限定されない。例えば、ユーザ端末104は、PC、スマートフォンまたは携帯電話等であってもよい。
本実施形態の広域網102は、高遅延のWAN(Wide Area Network)である。本発明ではネットワークの遅延時間も考慮してリクエストの転送先が決定されるため、ネットワークの遅延が大きいほど本発明の効果も大きくなる。このため、本実施形態では広域網102の例として高遅延のWANを採用したが、IEEE 802.11a/b/g等の無線LAN、イーサネットによるLANなど、他の通信手段によって置き換えられてもよい。他の通信手段の利用によって通信速度および配置の自由度等の改善が可能となる。
管理装置101は、広域網102を介してデータ転送装置103と通信し、サービスノード登録I/F(Interface)151を通してサービスノードを登録し、データ転送装置103のアプリケーショングラフ登録I/F154を通してアプリケーショングラフを登録する。通信は、Telnet、ssh等の既存のプロトコルに基づくものでも、独自のプロトコルに基づくものでもよい。管理装置101の通信手段、通信プロトコルは、本発明の本質とは関係がなく、データ転送装置103が提供する通信手段および通信プロトコルに対応していればよい。管理装置101からデータ転送装置103へ接続後、CUI(Character-based User Interface)またはGUI(Graphical User Interface)等を備えたプログラムを通して、サービスノードDB132の操作を行う。サービスノードDB132の操作手段は、特に制限がなく、後述する内容を設定できればよい。人手による接続および設定が行われてもよいが、接続および設定のための一連の操作が自動化されてもよい。自動化された場合、設定ミスの軽減およびサーバ管理ソフトなどとの連携による管理・運用コスト削減が可能となる。
サービスノードは、分散アプリケーションを構成するプログラムが動作するサーバ105、または、サーバ105の代わりにサービス要求を受け付けるデータ転送装置103である。本実施形態では、データ転送装置103がサービス要求を透過的にサーバ105に転送するため、サービスノードに言及する際に、サーバ105とデータ転送装置103を区別していない。複数のサーバ105をそれらに接続された一つのデータ転送装置103によって集約して、それらを一つのサービスノードとして扱う形態も考えられる。個々の機器を区別する必要がある場合は、明示的にサーバ105またはデータ転送装置103と記載する。
続いて、本実施形態における分散処理システムの動作の概略について説明する。
まず、図2を用いて、本実施形態の分散処理システムにおいて実行される分散アプリケーションの構成を説明する。なお、図2ではデータ転送装置103およびネットワーク等の図示が省略されている。本分散アプリケーションは、ユーザ端末104で実行されるクライアントプログラム(Client)201、サーバ105(1)で実行されるサービスプログラム(MacNegatives)202、サーバ105(2)で実行されるサービスプログラム(Mac)203、およびサーバ105(3)で実行されるサービスプログラム(Add)204から構成される。なお、Client、MacNegatives、MacおよびAddは、提供されるサービスを識別する名称の一例である。
それぞれのプログラムはXML−RPC(Extensible Markup Language-Remote Procedure Call)プロトコルを用いて通信する。本実施形態ではXML−RPCを用いる例を説明するが、SOAP(Simple Object Access Protocol)または独自プロトコルが用いられてもよい。SOAPを用いることで再利用性、相互運用性の高いサービスプログラムの開発が可能となる。一方、独自プロトコルを用いる場合には、通信帯域および通信処理のオーバヘッドを改善できる。
図3〜図6は、図2の分散アプリケーションを構成するサービスプログラムの依存関係(すなわち、各サービスプログラムと、そのサービスプログラムによるサービスを提供するために使用される別のサービスプログラムとの関係)および構成するサービスプログラムのプロパティをXML形式で定義したアプリケーショングラフのファイルの例を示している。依存関係としては、外部のプログラムと通信を行う関数のみを示せばよく、内部処理を記述する必要は必ずしもない。アプリケーショングラフは、分散アプリケーションを構成するサービスプログラムの依存関係およびサービスプログラムのプロパティを示していればよく、XML形式以外の形式で記述されてもよい。
図3のXMLファイル300は、クライアントプログラム(Client)のアプリケーショングラフを示している。行301のserviceタグはアプリケーションプログラム名(Client)、行302のpublic_methodタグは、他のプログラムに公開されているサービスメソッド(main)を示している。行303のcallタグは、public_method内で使用されている外部プログラムのサービスの呼び出し順序を規定する。呼び出しは、シーケンシャル(seq)、並列(par)または選択(alt)等が考えられる。行304のuse_serverタグは、外部サービスプログラムのURL(http://mac-negatives-service-example.com/calc.php:80)、行305のuse_methodタグは、外部サービスプログラムのメソッド名(mac_negatives)を指定している。以降、既出のタグについては説明を省略する。
図4のXMLファイル400は、サービスプログラム(MacNegatives)のアプリケーショングラフを示している。行401のparamタグは、サービスメソッドに渡される引数の名前(a)および型(int)を示している。行402のresponseタグは、サービスメソッドの戻り値の型(int)を示している。paramタグおよびresponseタグは、分散アプリケーション全体のアプリケーショングラフを構築する際に、サービスメソッド呼び出しが定義と一致するか確認するために用いられる。
行403のrequirementタグでは、サービスメソッドが要求するリソース量、具体的には、サービスプログラムを実行するために必要とされるCPU処理時間(行404のcpuタグ)およびメモリ使用量(行405のmemoryタグ)を指定する。CPU処理時間およびメモリ使用量は、プログラマが設計時にプロファイラ等を使用して取得しておく。図4の例では、CPU処理時間およびメモリ使用量としてそれぞれ50msおよび300KBが指定されている。これは、サービスプログラム(MacNegatives)によるサービスをサーバ105が処理するために必要なCPU時間が50msであり、その処理のために必要なメモリ使用量が300KBであることを示している。
CPU処理時間については、分散処理システム全体で統一の基準を設ける。例えば、Intel(登録商標)社のXeon(登録商標)の2.0GHzを基準CPUとして定義し、このCPUの1コアを使用した場合の実行時間をCPU処理時間としてもよい。
行406のuse_serverタグは、外部サービスプログラムのURL(http://mac-service-example.com/calc.php:80)、行407のuse_methodタグは、外部サービスプログラムのメソッド名(mac)を指定している。
図5のXMLファイル500は、サービスプログラム(Mac)のアプリケーショングラフを示している。図4の場合と同様、行501および行502において、サービスプログラム(Mac)によるサービスをサーバ105が処理するために必要なCPU時間およびメモリ使用量が指定されている。また、行503のuse_serverタグは、外部サービスプログラムのURL(http://add-service-example.com/calc.php:80)、行504のuse_methodタグは、外部サービスプログラムのメソッド名(add)を指定している。
図6のXMLファイル600は、サービスプログラム(Add)のアプリケーショングラフを示している。図4の場合と同様、行601および行602において、サービスプログラム(add)によるサービスをサーバ105が処理するために必要なCPU時間およびメモリ使用量が指定されている。
なお、図4から図6に示すアプリケーショングラフは、データ転送装置103のアプリケーショングラフDB135に格納される(図13A〜図13E参照)。データ転送装置103は、行406、407、503および504によって指定された情報を参照することによって、サービスプログラムの依存関係を特定することができる。
続いて、図7を用いて、分散アプリケーションが動作する分散処理システムのネットワーク構成を説明する。ユーザ端末701、データ転送装置702およびDNS704は、ネットワーク700によって接続されている。データ転送装置702の後段にはサーバ703が接続されている。なお、図7のネットワーク700、ユーザ端末701、データ転送装置702、サーバ703およびDNS704は、それぞれ、図1に示す広域網102、ユーザ端末104、データ転送装置103、サーバ105およびDNS106に相当する。ただし、図7の例ではDNS704がネットワーク700(すなわち広域網102)に接続されている。
図7において、データ転送装置702およびサーバ703の内部に、各装置のIPアドレスの略称が記載されている。例えば、データ転送装置702(1)のIPアドレスの略称は「Ag」および「Ap」である。「Ag」は広域網102における(すなわちネットワークI/F122(1)の)IPアドレスに、「Ap」はLAN107における(すなわちネットワークI/F122(2)の)IPアドレスに相当する。図8にアドレス略称801とIPアドレス802の対応を示す。
本実施形態では、ユーザ端末701からのサービス実行要求に対し、分散処理システムは、応答時間が短くなるようにサーバおよびネットワーク経路を選択し、サービス実行およびデータの転送を行う。
ただし、本発明では、データ転送装置によるサーバおよびネットワーク経路の選択基準を変更することで、応答時間の改善だけでなく、サーバ利用およびネットワーク利用の偏在化などを実現できる。サーバ利用、ネットワーク利用の偏在化によって、未使用状態のサーバおよびルータを一時的に作り出し、そのサーバおよびルータの電源を遮断することで、省電力化または優先度の高い要求に対するリソース確保などが実現できる。
ユーザ端末701で動作するクライアントプログラム(Client)201は、サービスプログラム(MacNegatives)202の公開IPアドレスをDNS704から取得し、その公開IPアドレスにサービス要求パケットを送信する。図7の例ではIPアドレス「Cg」が取得され、サービス要求パケットは、データ転送装置702(3)に送られる。本実施形態では、サービスプログラムのIPアドレスとして、データ転送装置702のIPアドレスがDNS704で公開されていることを前提とする。データ転送装置702の詳細な動作についてはフローチャートを参照して後述する。
データ転送装置702(3)は、新規セッションを作成し、本発明のマッピング計算部146によって、応答時間が最短となるサービス提供が期待されるサービスノード群を選択する。アプリケーショングラフに対するマッピング結果は、マップ結果DB134に格納される。リソースマッピングの詳細については後述する。
その後、データ転送装置702(3)は、サービスプログラム(MacNegatives)が実際に動作しているサーバのIPアドレス宛にNAPT(Network Address Port Translation)を適用し、パケットを転送する。すなわち、送信元IPアドレスをデータ転送装置702(3)のアドレス804、送信元ポートを自動的に割り当てたNAPTポート907のポート番号(5001)、送信先IPアドレスをサーバ703(3)のアドレス803、ポート番号をサーバ703(3)で動作しているサービスプログラムの待ち受けポート番号(80)に書き換える。
本実施形態では、リソースマッピングの契機を、パケットの到着時としているが、サービスノードの稼動情報を更新するたびにリソースマッピングを実行してもよい。パケット受信とリソースマッピングとを独立させることで、データ転送装置のCPU負荷を分散させることが期待される。
パケットを受信したサーバ703(3)のサービスプログラム(MacNegatives)は、外部のサービスプログラム(Mac)を使用してサービスを提供しているため、サービスプログラム(Mac)の公開IPアドレスをDNS704から取得し、取得した公開IPアドレスにサービス要求パケットを送信する。サーバ703(3)のデフォルトゲートウェイはデータ転送装置702(3)となっており、このサービス要求パケットはデータ転送装置702(3)に送信される。
データ転送装置702(3)は、新規のセッションを作成し、リソースマッピングの結果をマップ結果DB134から読み出し、サービスプログラム(Mac)のサービスを提供しているサービスノードを選択する。データ転送装置702(3)は、送信先NAPTおよび送信元NAPTをパケットに実施し送信する。送信先はデータ転送装置702(1)、送信元は、データ転送装置702(3)となる。
以下、同様に、データ転送装置702(1)でサーバ703(1)が選択され、サーバ703(1)から送信されたサービスプログラム(Add)宛のパケットがデータ転送装置702(1)によってデータ転送装置702(2)に送られる。データ転送装置709(2)は、サーバ703(2)上のサービスプログラム(2)へパケットを送信する。処理の結果は、これまでの逆向きの経路を辿って最終的にユーザ端末701に返信される。
続いて、データ転送装置を実現する上で必要となる、セッションDB131、サービスノードDB132、利用予約DB133、マップ結果DB134およびアプリケーショングラフDB135について説明する。
図9Aの表920に、データ転送装置702(3)のセッションDB131の例を示す。セッションDB131は、セッション管理部142によって作成および参照される。セッションDB131が格納する情報は、登録フラグ901、接続元IPアドレス902、接続元ポート903、接続先IPアドレス904、接続先ポート905、プロトコル番号906、NAPTポート907、サービスIPアドレス908、サービスポート909、接続状態910およびタイムスタンプ911等である。
セッションDBの実装方法としては、ハッシュテーブル、RDB(Relational Database)等によるソフトウェア実装、またはCAMを使ったハードウェア実装が考えられる。本実施形態では、DRAM上に格納されるハッシュを使用した例について説明する。
登録フラグ901は、ハッシュにおいてそのエントリが登録済みか否かを示す。
本実施形態では、セッションは、TCPの場合はコネクションに相当するものとし、UDPの場合は通信が存在する一定期間の接続関係を示すものとする。セッションが無い状態から最初にセッションを作成するパケットの送信元を接続元、送信先を接続先とする。接続元IPアドレス902および接続元ポート903は、それぞれパケットの送信元IPアドレスおよび送信元ポート番号を記録する。同様に接続先IPアドレス904および接続先ポート905は、それぞれパケットの送信先IPアドレスおよび送信先ポート番号を記録する。
プロトコル番号906は、IPプロトコルで定義されている番号であり、TCP、UDP等の番号である。NAPTポート907は、データ転送装置で送信元NAPTを適用した場合に自動的に割り当てられる、装置内で一意となるポート番号である。
サービスIPアドレス908およびサービスポート909は、リソースマッピングの結果、割り当てられたサービスノードのIPアドレスおよびサービスノードのポート番号である。
接続状態910はセッションの接続状態を示す。接続状態については後述する。タイムスタンプ911は、セッションエントリが最後に更新された時刻を格納する。タイムスタンプ911は、TCPコネクションが切断されてから、セッションエントリを未使用状態にするまでのタイムアウト時間の基準時刻として使用したり、UDP通信において非通信状態がどのくらい続いているかを測定したりするのに使用する。
図9Bの表930に、データ転送装置702(1)のセッションDB131の例を、図9Cの表940にデータ転送装置702(2)のセッションDB131の例を示す。図9A〜図9Cに示す表920、表930および表940の内容は、分散アプリケーションを構成するサービスプログラムがすべて接続された状態を示す。
例えば、図9Aの表920の先頭のエントリの接続元IPアドレス902としてユーザ端末701のIPアドレスである「10.0.0.1」が、接続先IPアドレス904としてデータ転送装置702(3)のグローバルIPアドレスである「10.0.1.3」が、サービスIPアドレス908としてサーバ703(3)のIPアドレスである「192.168.1.3」が、それぞれ記録されている。この場合、データ転送装置702(3)は、ユーザ端末701からデータ転送装置702(3)に送信されたパケットの送信先をサーバ703(3)のIPアドレスに書き換えて送信する。
同様に、表920の2番目のエントリの接続元IPアドレス902として「192.168.1.3」が、接続先IPアドレス904としてデータ転送装置702(5)のグローバルIPアドレスである「10.0.1.5」が、サービスIPアドレス908としてデータ転送装置702(1)のグローバルIPアドレスである「10.0.1.1」が、それぞれ記録されている。この場合、データ転送装置702(3)は、サーバ703(3)からデータ転送装置702(5)に送信されたパケットの送信先をデータ転送装置702(1)のIPアドレスに書き換えて送信する。
なお、上記の2番目のエントリの例は、サーバ703(3)がDNS704から取得したサービスプログラム(Mac)の公開IPアドレスが「10.0.1.5」であった(より詳細には、取得した公開IPアドレスのリストの先頭が「10.0.1.5」であった)ことを示す。データ転送装置702(3)は、後述するリソースマッピングによって、パケットの最適な送信先(すなわち応答時間が最も短くなる送信先)としてデータ転送装置702(1)を選択し、パケットの送信先を「10.0.1.1」に書き換える。DNS704から取得したIPアドレスとリソースマッピングによって選択されたIPアドレスが同一である可能性もあり、その場合、サービスIPアドレス908は接続先IPアドレス904と同一になる(図9Bの2番目のエントリ参照)。
図10A、図10Bおよび図10Cは、データ転送装置702(3)のサービスノードDB132の例を示している。サービスノードDB132は、サービスノード管理部143によって作成および参照される。サービスノードDB132は主に、サービスID表1020、サービスノード稼動情報表1021およびサービスノード間往復遅延表1022から構成される。サービスノード稼動情報表1021は主にノードのプロパティ、サービスノード間往復遅延表1022はネットワークのプロパティを格納する。プロパティの項目、表の分割方法はこの例に限らない。例えば、サービスノードのプロパティとして消費電力を追加しても良いし、ネットワークのプロパティとして帯域使用率等を追加しても良い。また、表を管理のしやすいように分離または統合しても良い。
サービスノードDB132は、ハッシュテーブル、配列構造、またはRDB等による実装が考えられる。本実施形態では、DRAM上に格納される配列構造を使用した例について説明する。
サービスID表1020が格納する情報は、ID1001、サービスURL1002およびメソッド1003である。サービスID表1020は、サービスURL1002およびメソッド1003によって一意に定義される識別子をID1001として対応付けるものである。
サービスノード稼動情報表1021が格納する情報は、サービスID1004、IPアドレス1005、CPU負荷1006、空きメモリ容量(GB)1007等である。サービスID1004は、サービスID表1020のID1001に対応する。IPアドレス1005は、サービスID1004で識別されるサービスを提供している装置(データ転送装置702またはサーバ703)のIPアドレス(すなわち、そのサービスを要求するパケットの送信先として指定できるIPアドレス)であり、CPU負荷1006および空きメモリ容量(GB)1007は前記装置の稼動情報である。CPU負荷1006および空きメモリ容量(GB)1007は、サーバ703および他のデータ転送装置702から収集され、随時更新される。
なお、サービスID表1020には、例えば、管理者が管理装置101を操作して入力した情報が登録される。サービスノード稼動情報表1021のサービスID1004、IPアドレス1005、サービスノード間往復遅延表1022の送信元IP1008および送信先IP1009についても同様である。これらの情報に基づいて、各サービスプログラムを使用するサービス要求パケットの送信先として指定できるアドレスを特定することができる。
例えば、サービスプログラム(Mac)203を使用するサービス要求パケットについては、メソッド「mac」に対応するサービスID1001の値「2」と同じサービスID1004に対応する二つのIPアドレス「10.0.1.1」及び「10.0.1.5」が特定される。これは、サービスプログラム(Mac)203を使用するサービス要求パケットをデータ転送装置702(1)または702(5)に送信できること(すなわち、それらのデータ転送装置702に接続されたサーバ703がサービスプログラム(Mac)203を実行できること)を意味する。
サービスノード間往復遅延表1022が格納する情報は、送信元IP1008、送信先IP1009、および送信元IP1008と送信先IP1009間の往復遅延(ms)1010である。往復遅延(ms)1010は、送信元IP1008と送信先IP1009間の往復遅延であり、データ転送装置702がpingなどの仕組みを用いて直接収集するか、他のデータ転送装置702から収集するなどの方法によって、随時更新される。
図10Bの例では、IPアドレス「192.168.1.3」に対応するCPU負荷1006として「1」が格納されている。これは、データ転送装置702(3)に接続されたサーバ703(3)のCPU負荷が「1」であることを示す。一方、IPアドレス「10.0.1.1」に対応するCPU負荷1006として「2」が格納されている。これは、データ転送装置702(1)に接続されたサーバ703(1)のCPU負荷が「2」であることを示す。同様に、図10Bのサービスノード稼動情報表1021は、データ転送装置702(5)に接続されたサーバ703(5)、データ転送装置702(2)に接続されたサーバ703(2)、およびデータ転送装置702(4)に接続されたサーバ703(4)のCPU負荷が、それぞれ「2」、「1」および「3」であることを示す。
なお、CPU負荷1006の値をアプリケーショングラフによって指定された処理時間に乗じることによって、CPU負荷の影響を考慮した実際のCPU処理時間が計算される。例えば、サービスプログラム(Add)を使用するサービス要求パケットをデータ転送装置702(4)が受信した場合の処理時間は、100ms(図6の行601)×3(エントリ1014のCPU負荷1006)=300msと計算される。
また、サービスノード稼動情報表1021のIPアドレス1005に格納されているアドレスが、自身(すなわちデータ転送装置702(3))に接続されたサーバ703(3)のアドレスであるか、他のデータ転送装置702のアドレスであるかは、そのアドレスの値そのものに基づいて判定してもよいが、サービスノード稼動情報表1021が両者を区別するフラグ情報をさらに保持し、それに基づいて判定してもよい。
一方、図10Cの例では、サービスノード間往復遅延表1022の先頭のエントリの送信元IP「10.0.1.3」および送信先IP「192.168.1.3」に対応する往復遅延1010として「2」が格納されている。これは、データ転送装置702(3)とサーバ703(3)との間をパケットが往復するのに要する時間が2msであることを示す。同様に、2番目以降のエントリには、二つのデータ転送装置702間をパケットが往復するのに要する時間が格納されている。例えば、5番目のエントリは、データ転送装置702(1)とサーバ703(4)との間をパケットが往復するのに要する時間が250msであることを示す。
上記のように、サービスプログラム(Add)を使用するサービス要求パケットをデータ転送装置702(4)が受信した場合の処理時間が100msであるので、データ転送装置702(1)が当該パケットをデータ転送装置702(4)に送信してから、それに対する応答を受信するまでの時間(すなわち応答遅延時間)は、100ms+250ms=350msと計算される。
図10D、図10Eおよび図10Fは、それぞれ、データ転送装置702(1)のサービスノードDB132に含まれるサービスID表1030、サービスノード稼動情報表1031およびサービスノード間往復遅延表1032の内容の例を示している。図10G、図10Hおよび図10Iは、それぞれ、データ転送装置702(2)のサービスノードDB132に含まれるサービスID表1040、サービスノード稼動情報表1041およびサービスノード間往復遅延表1042の内容の例を示している。
図11Aの表1120に、データ転送装置702(3)の利用予約DB133の例を示す。利用予約DB133は、利用予約管理部145によって作成および参照される。利用予約DB133が格納する情報は、サービスURL1101、メソッド1102および利用予約元1103等である。
利用予約DB133は、ハッシュテーブル、配列構造、RDB、またはCAM等による実装が考えられる。本実施形態では、DRAM上に格納される配列構造を使用した例について説明する。
サービスURL1101は、サービスにアクセスする際に使用するURLであり、サービスを一意に示す文字列およびポート番号から構成される。URLは、サービスを一意に示せればよく、IPアドレスまたはUUID(Universally Unique Identifier)によって表現されてもよい。
メソッド1102には、サービスの機能が登録される。利用予約元1103には、データ転送装置702が収集したサービスノードの稼動情報を通知するIPアドレスが登録される。サービスノードの稼動情報は、サーバ単位、またはデータ転送装置で集約した稼動単位で収集することが考えられる。データ転送装置702で稼動情報を集約した場合は、負荷分散などによる処理性能向上および冗長構成による高信頼化などの効果が得られる。利用予約元への通知は、1エントリずつ実行してもよいし、複数CPUによる並列実行をしてもよい。並列実行した場合は、短時間で利用予約元に稼動情報を通知することが可能となる。
図11Bの表1130、図11Cの表1140、図11Dの表1150および図11Eの表1160は、それぞれ、データ転送装置702(1)、データ転送装置702(5)、データ転送装置702(2)およびデータ転送装置702(4)の利用予約DB133の例を示している。
例えば、データ転送装置702(3)が保持する表1120には、サービスURL「http://mac-negatives-service-example.com/calc.php:80」およびメソッド「mac_negatives」に対応する利用予約元として、データ転送装置702(3)自身のグローバルIPアドレスである「10.0.1.3」が登録されている。この場合、データ転送装置702(3)は、自らが管理する、サービスプログラム(MacNegatives)を実行するサーバ703(すなわちサーバ703(3))から稼動情報を取得し、その稼動情報をデータ転送装置702(3)自身が保持する。
一方、データ転送装置702(1)が保持する表1130には、サービスURL「http://mac-service-example.com/calc.php:80」およびメソッド「mac」に対応する利用予約元として、データ転送装置702(1)自身のグローバルIPアドレスである「10.0.1.1」及びデータ転送装置702(3)のグローバルIPアドレスである「10.0.1.3」が登録されている。この場合、データ転送装置702(1)は、自らが管理する、サービスプログラム(Mac)を実行するサーバ703(1)から稼動情報を取得し、その稼動情報をデータ転送装置702(1)自身が保持し、さらに、その稼動情報をデータ転送装置702(3)に送信する。
上記のように、本実施形態において「利用予約」とは稼動情報の送信要求に相当し、「利用予約元」とは、送信要求の要求元、すなわち、稼動情報の送信先を意味する。利用予約元は、利用予約先のデータ転送装置702を将来利用する(すなわちそこにサービス要求パケットを送信する)可能性はあるが、必ず利用するとは限らない。
本実施形態において、データ転送装置702(3)は、残りすべてのデータ転送装置702から、サービスノードの稼動情報を直接収集しているが、途中のデータ転送装置702を中継して収集する方法も考えられる。例えば、データ転送装置702(3)がデータ転送装置702(2)から受信する稼動情報は、データ転送装置702(1)にも送られているため、データ転送装置702(1)がデータ転送装置702(2)から送られた稼動情報をデータ転送装置702(3)に転送してもよい。このように、稼動情報を間接的に収集することで、稼動情報のトラフィック量を削減することが可能である。
図12Aの表1220に、データ転送装置702(3)のマップ結果DB134の例を示す。マップ結果DB134は、マッピング計算部146によって作成および参照される。マップ結果DB134が格納する情報は、サービスURL1201、メソッド1202および実行サービスノード1203等である。
マップ結果DB134は、ハッシュテーブル、配列構造、RDBまたはCAM等によって実装することが考えられる。本実施形態では、DRAM上に格納される配列構造を使用した例について説明する。サービスURL1201およびメソッド1202は、利用予約DB133におけるサービスURLおよびメソッドに相当するものである。実行サービスノード1203は、マッピングの結果選択されたサービスを実行するサービスノードのIPアドレスである。サービスノードは、サーバ703である場合と、データ転送装置702である場合がある。
図12Bの表1230および図12Cの表1240は、それぞれデータ転送装置702(1)およびデータ転送装置702(2)のマップ結果DB134の例を示している。
表1220の作成方法について説明する。まず、エントリ1204のサービスURLを実行可能なサービスノードが、表1021からサーバ703(3)のみであるため、実行サービスノード1203は192.168.1.3と決定される。エントリ1205のサービスURLを実行可能なサービスノードは、表1021のエントリ1011およびエントリ1012から、データ転送装置702(1)またはデータ転送装置702(5)と分かる。同様に、エントリ1205のサービスURLを実行可能なサービスノードは、表1021のエントリ1013およびエントリ1014から、データ転送装置702(2)またはデータ転送装置702(4)と分かる。
本実施形態では応答遅延時間を短縮するサービスノードの選択をする。CPU負荷は、基準を1として何倍処理時間が増加するかを示す数値である。サービスノードの詳細な選択手順は後述するため、計算結果の一例を示す。アプリケーション名MacNegativesの処理時間は行404に記載された50ms、アプリケーション名Macの処理時間は行501に記載された150ms、アプリケーション名Addの処理時間は行601に記載された100msであり、それぞれアプリケーショングラフDB135に格納されている。
例えば、データ転送装置702(3)−データ転送装置702(1)−データ転送装置702(2)を使用した場合(すなわち、ユーザ端末701がサービスプログラム(MacNegatives)202を使用するサービス要求パケットをデータ転送装置702(3)に送信し、データ転送装置702(3)がサービスプログラム(Mac)203を使用するサービス要求パケットをデータ転送装置702(1)に送信し、データ転送装置702(1)がサービスプログラム(Add)204を使用するサービス要求パケットをデータ転送装置702(2)に送信する場合)の応答遅延時間は、50ms(処理時間)×1(CPU負荷)+200ms(通信遅延)+150ms(処理時間)×2(CPU負荷)+50ms(通信遅延)+100ms(処理時間)×1(CPU負荷)によって計算され、合計700msとなる。なお、データ転送装置702(3)、702(1)および702(2)のCPU負荷はサービスノード稼動情報表1021(図10B)から、データ転送装置702(3)とデータ転送装置702(1)の間の通信遅延およびデータ転送装置702(1)とデータ転送装置702(2)の間の通信遅延はサービスノード間往復遅延表1022(図10C)から取得される。
データ転送装置702(3)は、同様にして、データ転送装置702(3)−データ転送装置702(1)−データ転送装置702(4)を使用した場合、データ転送装置702(3)−データ転送装置702(5)−データ転送装置702(2)を使用した場合、およびデータ転送装置702(3)−データ転送装置702(5)−データ転送装置702(4)を使用した場合のそれぞれの応答遅延時間を計算する。
本実施形態では、応答遅延時間が小さくなるようにパケットの送信先が決定される。上記の例では、上記の4通りの組み合わせについて計算した応答遅延時間のうち、データ転送装置702(3)−データ転送装置702(1)−データ転送装置702(2)を使用した場合の応答遅延時間が最も小さい。このため、データ転送装置702(3)は、サービスプログラム(Mac)203を使用するサービス要求パケットの送信先としてデータ転送装置702(1)を選択する。
上記のように応答遅延時間が小さくなるようにパケットの送信先の組み合わせを選択する処理(すなわちリソースマッピング処理)の詳細な手順については、図20〜図22を参照して後述する。
図13Aの表1320に、データ転送装置702(3)のアプリケーショングラフDB135の例を示す。アプリケーショングラフDB135は、アプリケーショングラフ管理部144によって作成および参照される。アプリケーショングラフDB135が格納する情報は、アプリケーション名1301、グラフ1302、IPアドレス1303およびポート番号1304等である。
アプリケーション名1301は、アプリケーションを識別する一意の識別子であれば、文字列でも数字でもよい。
グラフ1302は、アプリケーショングラフデータへのポインタを格納する。アプリケーショングラフデータは、隣接行列または隣接リストに変換した形式で保存することが考えられ、公知または周知の技術を使用することができる。アプリケーショングラフデータもアプリケーショングラフDB135内に格納される。
IPアドレス1303およびポート番号1304は、アプリケーションと通信する際に使用する代表IPアドレスおよび代表ポート番号であり、実際のアプリケーションは他のサーバで実行される。本実施形態では、アプリケーションをIPアドレスおよびポート番号で区別しているが、ポート番号の代わりに、ペイロード内に埋め込まれた、数字または文字列といった識別子によって区別してもよい。ペイロードでアプリケーションを識別する場合、少ないポート番号のみを開放すれば足りるため、セキュリティ確保などの面で運用が容易となる。
アプリケーショングラフDB135は、ハッシュテーブル、配列構造、RDBまたはCAM等によって実装することが考えられる。本実施形態では、DRAM上に格納される配列構造を使用した例について説明する。
アプリケーショングラフデータは、サービスノードURLをグラフノードとして、ノード間をエッジで結合した形式で表現される。例えば、図2に示すサービスプログラム202〜204がノードに、それらを結合する矢印がエッジに相当する。ノードにはプロパティとして、サービスのCPU使用時間、メモリ使用量等、サービスを実行する際の条件などが格納される。エッジには、プロパティとして、必要なネットワーク帯域、要求通信時間等の条件が格納される。
同様に、図13Bの表1330、図13Cの表1340、図13Dの表1350および図13Eの表1360は、それぞれ、データ転送装置702(1)、データ転送装置702(5)、データ転送装置702(2)およびデータ転送装置702(4)のアプリケーショングラフDB135の例を示している。
図14に、アプリケーショングラフの登録シーケンスを示す。アプリケーショングラフの登録は、ネットワークシステム管理者が管理装置101を用いて実行する。
ネットワークシステム管理者は、管理装置101を用いてデータ転送装置702(3)のアプリケーショングラフ管理部144へアクセスし、予め作成したアプリケーショングラフを定義するXMLファイル(図4〜図6参照)を転送するか、またはコンソール上で入力することで、アプリケーショングラフを登録できる(メッセージ1407)。アプリケーショングラフ管理部144は、アプリケーショングラフDB135にアプリケーショングラフを保存する(メッセージ1408)。
なお、ネットワークシステム管理者は、上記と同様の手順で他のデータ転送装置702にもアプリケーショングラフを登録する必要がある。具体的には、ネットワークシステム管理者は、上記と同様の手順で図4〜図6に示すXMLファイルを各データ転送装置702に転送し、それぞれのアプリケーショングラフDB135に保存させてもよい。
ただし、図7以降に示した例では、リソースマッピングを行うためにデータ転送装置702(1)および702(5)が保存する必要がある情報は図5および図6に示したもののみであり、データ転送装置702(2)および702(4)が保存する必要がある情報は図6に示したもののみである。各データ転送装置702は、転送された全ての情報を保存してもよいが、必要なものだけを保持し、その他のものを廃棄してもよい。あるいは、管理装置101が各データ転送装置702に必要な情報だけを転送してもよい。
次に、データ転送装置702(3)の利用予約管理部145は、利用予約DB133にサービス(MacNegatives)を登録する(メッセージ1409)。これによって、表1120の先頭のエントリが登録される(図11A参照)。
次に、アプリケーショングラフ管理部144は、アプリケーショングラフからサービス(MacNegatives)がサービス(Mac)を使用していることを検出し、サービス(Mac)を提供しているデータ転送装置702を、サービスノードDB132から検索する(メッセージ1410)。そして、検索されたサービス(Mac)を提供しているデータ転送装置702に対して、サービス(Mac)の利用予約を登録する(メッセージ1411)。サービス(Mac)を提供しているデータ転送装置702が複数存在する場合は、すべてのデータ転送装置702に対してメッセージ1411を送信する。本実施例では、データ転送装置702(1)およびデータ転送装置702(5)の二つが該当するため、これらにメッセージ1411が送信される。
データ転送装置702(1)およびデータ転送装置702(5)では、それぞれが持つ利用予約DBにサービス(Mac)を登録する(メッセージ1412)。これによって表1130および表1140の各エントリが登録される(図11Bおよび図11C参照)。
サービス(Mac)はサービス(Add)を使用しているため、データ転送装置702(3)の動作と同様に、サービス(Add)を提供しているデータ転送装置を検索し(メッセージ1413)、発見したデータ転送装置702(2)およびデータ転送装置702(4)にサービス(Add)の利用予約を登録する(メッセージ1414)。
最後にデータ転送装置702(2)およびデータ転送装置702(4)では、それぞれが持つ利用予約DBにサービス(Add)を登録する(メッセージ1415)。これによって表1150および表1160の各エントリが登録される(図11Dおよび図11E参照)。
図15に、サーバの稼動情報を収集するシーケンスを示す。本実施形態では、ブロック1501に示すように、データ転送装置702がサーバの稼動情報を繰り返し収集する。具体的には、すべてのデータ転送装置702は、自身に接続されたサーバに対してSNMPを用いてCPU負荷およびメモリ使用量等の稼動情報を収集する(メッセージ1503)。SNMPは多くのサーバ・ネットワーク機器でサポートされているため、これを用いることによって統一された収集方法を実現できる。ただし、この収集方法は一例であり、SNMPを用いない方法によって稼動情報を収集してもよい。
それぞれのデータ転送装置702は、稼動情報を収集後、利用予約DBに基づき、稼動情報を必要なデータ転送装置702(すなわち利用予約DB133に利用予約元として登録されたデータ転送装置702)のみに送る(ブロック1502)。本実施形態では、稼動情報は途中のデータ転送装置702に中継させている。
具体的には、データ転送装置702(1)がデータ転送装置702(3)に送信する稼動情報(メッセージ1504)は、データ転送装置702(1)がサーバ703(1)から取得した稼動情報だけでなく、データ転送装置702(1)がデータ転送装置702(2)から取得した稼動情報(メッセージ1507)およびデータ転送装置702(4)から取得した稼動情報(メッセージ1510)を含む。同様に、データ転送装置702(5)がデータ転送装置702(3)に送信する稼動情報(メッセージ1505)は、データ転送装置702(5)がサーバ703(5)から取得した稼動情報だけでなく、データ転送装置702(5)がデータ転送装置702(2)から取得した稼動情報(メッセージ1508)およびデータ転送装置702(4)から取得した稼動情報(メッセージ1511)を含む。なお、データ転送装置702(2)及び702(4)が送信する稼動情報は、それぞれ、サーバ703(2)および703(4)から取得された稼動情報を含む。
ただし、上記のような収集方法は一例であり、データ転送装置に中継させずに稼動情報を収集する方法も考えられる。その場合、各データ転送装置702は、サーバ703から取得した稼動情報を、利用予約元として登録されたデータ転送装置702に直接送信する。
上記のメッセージ1503〜1511の送受信(すなわちブロック1501)を所定のタイミングで(例えば定期的に)繰り返し実行することによって、サービスノードDBのCPU負荷1006及び空きメモリ容量1007等が最新の値に更新される。これによって、サーバ703の稼動状態が変化した場合にも、最新の稼動状態に基づいて最適なリソースマッピングを行うことができる。
図16にデータ転送装置間でリソースマッピングの結果を伝播させる処理のシーケンスを示す。
データ転送装置702(3)が、サービス(MacNegatives)への新規要求1601をユーザ端末701から受信すると、マップ要求1602がデータ転送装置702(3)のマッピング計算部146に通知される。リソースマッピングの詳細については後述する。
マッピングの結果、分散アプリケーションを実行するサーバ群が決定される。本実施形態では、サービス(MacNegatives)はサーバ703(3)、サービス(Mac)は、データ転送装置702(1)、サービス(Add)は、データ転送装置702(2)にマップされる。データ転送装置702(3)は、リソースマッピング後、サービス(Add)のマッピング結果1603をデータ転送装置702(1)へ送ることができる。
データ転送装置702(1)は、受信したサービス(Add)のマッピング結果を使用することによって、マッピング処理の実行を省略することができ、より多くの要求を短時間に処理することができるようになる。
ただし、データ転送装置702(1)は、自身でサービス(Add)のマッピングを実行することも可能である。これによって、新しいサーバおよびネットワーク稼動情報に基づくマッピングが実施され、より最適なマッピングが可能となる。この場合、データ転送装置702(3)は、マッピング結果1603をデータ転送装置702(1)へ送る必要がない。
なお、本実施形態では、データ転送装置702(2)は、さらに他のデータ転送装置702にサービス要求パケットを送信する必要がない。このため、データ転送装置702(2)自身がリソースマッピングを行う必要はないし、データ転送装置702(1)がデータ転送装置702(3)から受信したマッピング結果をさらにデータ転送装置702(2)に送信する必要もない。しかし、データ転送装置702(2)が他のデータ転送装置702にサービス要求パケットを送信する必要がある場合には、自身でマッピングを行うか、または、上記と同様にデータ転送装置702(1)からマッピング結果を受信し、いずれかのマッピング結果に基づいてパケットの送信先を決定する。
図17にデータ転送装置702のアドレス変換部140が実行するアドレス変換処理を説明するフローチャートを示す。
まず、処理は開始状態2001からステップ2002に進む。ステップ2002においてアドレス変換部140はパケットを受信し、ステップ2003に進む。ステップ2003においてアドレス変換部140は、パケットを解析する。具体的には、アドレス変換部140は、受信したパケットの送信元IPアドレス、送信元ポート番号、送信先IPアドレス、送信先ポート番号、プロトコル番号、およびTCPフラグ等を識別する。一つのポート番号を複数のアプリケーションが使用している可能性があるため、アドレス変換部140は、さらにパケットのペイロード部分のデータを解析することで、同じポート番号を使用しているアプリケーションを区別してもよい。
次に、アドレス変換部140は、ステップ2004において、セッションDB131のセッションエントリを参照し、ステップ2005に進む。セッションデータベース131の参照については後述する(図18参照)。ステップ2005においてアドレス変換部140は、参照したセッションエントリが新規セッションであるか否かを判定する。ステップ2003において識別された情報に対応するエントリがセッションDB131に登録されていなければ、参照したセッションエントリが新規セッションであると判定される。判定の結果がYES(すなわち新規セッションである)場合はステップ2006に、NO(すなわち新規セッションでない)場合はステップ2007に進む。
ステップ2006においてアドレス変換部140は、セッションエントリを作成し、ステップ2007に進む。セッションエントリの作成については後述する(図19参照)。ステップ2007においてアドレス変換部140は、NAPTを適用する。これによって、パケットの送信先IPアドレスおよび送信先ポート番号が、参照されたセッションエントリのサービスIPアドレス908およびサービスポート909の値に書き換えられる。
次に、ステップ2008においてアドレス変換部140は、セッションエントリの接続状態とタイムスタンプを現在の時刻に更新して、ステップ2009に進む。セッションエントリの接続状態の更新は、図23または図24の状態遷移図に従う。ステップ2009においてアドレス変換部140は、パケットをネットワークに送信して、終了状態2010に進む。
図18にデータ転送装置702のセッション管理部142が実行するセッションDB参照処理を説明するフローチャートを示す。
まず、処理は初期状態2101からステップ2102に進む。ステップ2102においてセッション管理部142は、受信パケットの送信元IPアドレス、送信元ポート番号、送信先IPアドレス、送信先ポート番号、およびプロトコル番号からハッシュ値を計算し、ステップ2103に進む。ハッシュ値の計算方法は、すべての値を排他的論理和演算するなどの方法が考えられる。ハッシュ値が均等にばらつく方法であれば別の方法を使用してもよい。
ステップ2103においてセッション管理部142は、計算したハッシュ値をアドレスとしてセッションテーブル(例えば図9Aの表920)のエントリを読み出し、エントリの登録フラグ(例えば登録フラグ901)を確認する。ハッシュ値がアドレス空間のサイズより大きい場合は、上位のビットを捨てる等の処理によって有効なアドレス空間に収まるようにする。ステップ2103がYESの場合、すなわちエントリが登録されている場合は、ステップ2104に進み、NOの場合、ステップ2105に進む。
ステップ2104においてセッション管理部142は、登録されているエントリの一致を確認する。本実施形態では、受信したパケットの送信元IPアドレス、送信元ポート番号、送信先IPアドレス、送信先ポート番号、およびプロトコル番号が、エントリの対応する項目すべてに一致するか否かを判定する。エントリの一致確認の結果がYES(すなわち一致する)の場合、参照されたエントリが、受信したパケットに対応するものであるため、終了状態2109へ進む。一方、エントリの一致確認の結果がNOの場合、ステップ2106に進む。
ステップ2105においてセッション管理部142は、エントリが登録されていない空きエントリメモリアドレスを作業用メモリに記録して終了状態2109に進む。
ステップ2106においてセッション管理部142は、既に実行されたハッシュ回数が、予め設定されたハッシュ試行回数を超えているか否かを判定する。YES(すなわち超えている)の場合は、ステップ2107に進み、NOの場合はステップ2108に進む。許可する再ハッシュの回数が多ければ、ハッシュが衝突しても登録できる可能性が高くなるが、登録・参照時間が長くなる。
ステップ2107においてセッション管理部142は、空きエントリが無いことを作業用メモリに記録して終了状態2109に進む。
ステップ2108においてセッション管理部142は、再ハッシュ計算を実行して、ステップ2103に進む。再ハッシュの計算は、例えば、元のハッシュ値に、再ハッシュの試行回数の二乗を加算するなどの方法がある。再ハッシュの計算は、公知または周知の技術を適用すればよい。
図19にデータ転送装置702のセッション管理部142が実行するセッション作成処理を説明するフローチャートを示す。
まず、処理は初期状態2201からステップ2202に進む。ステップ2202においてセッション管理部142は、作業用メモリに保存されている空きエントリの有無を確認する。確認の結果がYES(すなわち空きエントリが有る)である場合は、ステップ2203に進み、NO(すなわち空きエントリが無い)である場合は、ステップ2204に進む。
ステップ2203においてセッション管理部142はリソースマッピングを実行し、ステップ2205に進む。リソースマッピングについては後述する(図20〜図22参照)。ステップ2205においてセッション管理部142は、空きエントリアドレスに、セッション情報を登録し、終了状態2206に進む。
ステップ2204においてセッション管理部142は、エラー処理を実施してから終了状態2206に進む。エラー処理の方法としては、送信元へコネクション拒否のパケットを返信したり、エラーページへのリダイレクトを表示したりする方法が考えられる。
図20、図21および図22を用いてリソースマッピングについて説明する。アプリケーショングラフを、サービスを実際に提供するデータ転送装置702またはサーバ703に割り当てることをリソースマッピングと呼ぶ。本実施形態では、データ転送装置702がサーバ703への要求を代理で受け付けるため、リソースマッピングは、アプリケーションの実行を要求するパケットの送信先のデータ転送装置702を選択することを意味する。
本実施形態では、応答時間を短縮するように、アプリケーションを実行するサーバ群を選択する。しかし、応答時間は、処理を最適化するための指標の一例に過ぎない。応答時間以外の指標を用いた最適化の例として、例えば、消費電力が最小になるようにサーバ群を選択すること、CPU負荷が平準化されるように(あるいは特定のサーバ群に偏るように)サーバ群を選択すること、またはネットワーク使用帯域が平準化されるようにサーバ群を選択すること、等も考えられる。また、リソースマッピングのアルゴリズムも本実施形態に限定されるものではなく、最適化の精度を落としてマッピング時間を短くするアルゴリズム、または厳密な最適化を求めるアルゴリズムなども考えられる。
図20にデータ転送装置702のマッピング計算部146が実行するリソースマッピング処理を説明するフローチャートを示す。
まず、処理は初期状態2301からステップ2302に進む。ステップ2302においてマッピング計算部146は、受信したパケットの送信先IPアドレスおよび送信先ポート番号からアプリケーションを判別し、それに該当するアプリケーショングラフをアプリケーショングラフデータベースから読み出し、ステップ2303に進む。
ステップ2302を実行することによって、受信したパケットによって要求されたサービスを提供するために必要なアプリケーションの依存関係が特定される。言い換えると、これによって、受信したパケットによって要求されたサービスを提供するために実行する必要がある全てのサービスプログラムが特定される。例えば、サービス(MacNegatives)の提供を要求された場合、それを提供するために、サービスプログラム(MacNegatives)だけでなく、サービスプログラム(Mac)及びサービスプログラム(Add)も実行する必要があることが特定される(図2参照)。
本実施形態では、受信したパケットの送信先IPアドレス及び送信先ポート番号に基づいてアプリケーションを判別しているが、パケット解析部141が、受信したパケットのペイロード内容を判断してアプリケーションを判別することも考えられる。ペイロード内容の解析に基づく方法によって、ポート番号が同一の複数のアプリケーションを区別することができる。
ステップ2303においてマッピング計算部146は、アプリケーションを実行可能なサーバ群の情報をサービスノードDBから読み出し、ステップ2304に進む。ステップ2303を実行することによって、ステップ2302で特定されたそれぞれのアプリケーションを実行可能な一つ以上のサーバが特定される。すなわち、これによって、ステップ2302で特定された全てのアプリケーションを実行するためにサービス要求パケットの送信先として指定できるサービスノードの複数の組み合わせ(例えば、図12A〜図12Cを参照して説明した4通りの組み合わせ)を特定できる。
ステップ2304においてマッピング計算部146は、アプリケーショングラフをリスト構造に変換したアプリケーションノードリストを用意し、ステップ2305に進む。
ステップ2305においてマッピング計算部146は、サービスノードリストを格納する配列nodes[]を確保し、ステップ2306に進む。
ステップ2306においてマッピング計算部146は、変数min_delayに無限時間を示す十分大きな数値を設定し、ステップ2307に進む。十分大きな数値は、例えば365日等、アプリケーション全体の処理が終了すると期待される時間より1桁以上大きければよい。
ステップ2307においてマッピング計算部146は、マップ処理を行い終了状態2308へ進む。マップ処理については後述する。
図21にデータ転送装置702のマッピング計算部146が実行するマップ処理を説明するフローチャートを示す。
マップ処理は再帰的処理であり、引数としてアプリケーションノードリストのインデックスを示す自然数nを取る。まず、初期状態2401からステップ2402に進む。ステップ2402においてマッピング計算部146は、引数nがアプリケーションノードリストのサイズより大きいか否かを確認し、YES(すなわち大きい)の場合はステップ2404に、NOの場合はステップ2403に進む。
ステップ2403からステップ2407は、アプリケーションノードリストのn番目のサービスを提供できるすべてのサービスノード候補に対する繰り返し処理である。ステップ2405においてマッピング計算部146は、サービスノードリストの配列nodes[]に、現在対象とするi番目のサービスノードを登録し、ステップ2406に進む。ステップ2406においてマッピング計算部146は、マップ処理を呼び出す。このとき、引数としてn+1を渡す。ステップ2403からステップ2407をサービスノード数分繰り返した後、終了状態2412に進む。
ステップ2404においてマッピング計算部146は、アプリケーショングラフの全ノードを“未訪問”状態に初期化し、ステップ2408に進む。これはグラフのノードを2度以上訪問しないようにするためである。ステップ2408においてマッピング計算部146は、アプリケーショングラフの根ノードを引数として、遅延計算処理を呼び出して、得られた遅延時間を変数vに格納し、ステップ2409に進む。根ノードは、サービス要求元のノードに相当する。遅延計算処理については後述する。ステップ2409においてマッピング計算部146は、変数vの値が変数min_delayの値より小さいか確認し、YESの場合ステップ2410に、NOの場合、終了状態2412に進む。
ステップ2410においてマッピング計算部146は、変数min_delayに変数vの値を格納しステップ2411に進む。ステップ2411においてマッピング計算部146は、マップされた結果であるサービスノード配列nodes[]を別の領域に保存し、終了状態2412に進む。
図22にデータ転送装置702のマッピング計算部146が実行する遅延計算処理を説明するフローチャートを示す。
遅延計算処理は再帰的処理であり、引数としてノードkを取る。まず、初期状態2501からステップ2502に進む。ステップ2502においてマッピング計算部146は、ノードkを“訪問済み”に設定して、ステップ2503に進む。ステップ2503においてマッピング計算部146は、遅延時間の最大値を格納する変数max_path_delayを0に初期化して、ステップ2504に進む。
ステップ2504からステップ2509は、ノードkの隣接ノードのうち、“未訪問”状態のすべてのノードに対する繰り返し処理である。ステップ2505においてマッピング計算部146は、i番目の隣接ノードを引数として、遅延計算処理を呼び出し、結果を変数delayに格納して、ステップ2506に進む。ステップ2506においてマッピング計算部146は、ノードkからi番目の隣接ノードへの通信遅延を、サービスノードDBから取得して変数edge_delayに格納し、ステップ2507に進む。ステップ2507においてマッピング計算部146は、変数edge_delayと変数delayの合計が変数max_path_delayより大きいか確認し、YESの場合、ステップ2508に、NOの場合、ステップ2509に進む。
ステップ2508においてマッピング計算部146は、変数edge_delayと変数delayの合計を変数max_path_delayに代入してステップ2509に進む。ステップ2504からステップ2509の繰り返しが終了したら、マッピング計算部146の処理はステップ2510に進む。ステップ2510においてマッピング計算部146は、ノードk自身の処理遅延を変数max_path_delayに加算して、終了状態2511に進む。処理遅延は、サービスが必要としているCPU処理時間/サーバが提供できる毎秒CPU処理速度を計算することによって求められる。本遅延計算処理は、戻り値として変数max_path_delayの値を返す。
図20〜図22のリソースマッピングによって取得された最終的なマップ結果は、マップ結果DB134に格納され(図12A〜図12C参照)、さらに、マップ結果として取得されたIPアドレスがサービスIPアドレス908としてセッションDB131に格納される(図9A〜図9C参照)。
図20〜図22の処理の結果、図12Aを参照して説明したように、要求されたサービスを提供するために使用されるサービスノードの複数の組み合わせのうち、応答遅延時間が最小になる組み合わせが選択される。しかし、応答遅延時間は、リソースマッピングによって処理を最適化するために使用される指標の一例であり、他の指標が使用されてもよい。他の指標としては、例えば、消費電力またはサービスノードの負荷が挙げられる。
ここで、消費電力に基づくリソースマッピングについて説明する。この場合、例えば、サービスノードDB132のサービスノード稼動情報表1021が、各サービスノードにおける単位CPU処理時間当たりの消費電力を示す情報をさらに含む。そして、図21のステップ2408において、遅延計算の代わりに消費電力が計算される。各サービスノードの消費電力は、各サービスノードにおいて実行されるサービスプログラムを実行するためのCPU処理時間(図4〜図6参照)に、CPU負荷(図10B、図10E及び図10H参照)及び単位CPU処理時間当たりの消費電力を乗じることによって算出される。
例えば、IPアドレス「10.0.1.1」が示すサービスノードにおける消費電力は、図5の行501が示す「150ms」に図10Bのエントリ1011が示す「2」を乗じた値「300ms」にさらに単位CPU処理時間当たりの消費電力を乗じることによって算出される。
上記の処理によって、消費電力が最小になるサービスノードの組み合わせが特定される。
次に、負荷に基づくリソースマッピングについて説明する。負荷に基づく処理の最適化にはいくつかの考え方があり、その代表的な例は負荷の平坦化及び負荷の片寄せである。負荷の平坦化は、負荷の集中による処理性能の低下を回避するために行われる。一方、負荷の片寄せは、負荷を意図的に偏在させ、負荷がゼロになった(すなわち処理を行っていない)サービスノードの電源を遮断することによって、システム全体としての消費電力を削減すること等を目的として行われる。
最初に、負荷の平坦化のためのリソースマッピングについて説明する。この場合、例えば図20のステップ2307において、サービスノードDB132のCPU負荷が参照され、各サービスプログラムを実行するサービスノードのうち、CPU負荷が最も小さいものの組み合わせが特定される。
次に、負荷の片寄せのためのリソースマッピングについて説明する。負荷を片寄せする単純な方法は、例えば図20のステップ2307において、サービスノードDB132のCPU負荷を参照し、各サービスプログラムを実行するサービスノードのうち、CPU負荷が最も大きいものの組み合わせを特定する、というものである。
ただし、既に負荷がゼロになっているサービスノードが存在する場合には、そのサービスノードを含まない組み合わせを選択することが望ましい。また、負荷が大きいサービスノードを選択した場合、そのサービスノードにおいてさらに要求されたサービスプログラムを実行することによってそのサービスノードのCPU負荷が100%に達する可能性がある。これによるサービスノードの処理性能の低下を避けるために、要求されたサービスプログラムを実行した場合のCPU負荷の上限(例えば100%)を設定し、その上限を超えないサービスノードの組み合わせを特定してもよい。
すなわち、負荷を片寄せする場合は、サービスノードの複数の組み合わせから、負荷がゼロであるサービスノードを含まず、かつ、要求されたサービスプログラムを実行した場合に負荷の上限を超えるサービスノードを含まない組み合わせを特定し、さらにその中で、負荷が最も大きいサービスノードの組み合わせを特定することが望ましい。なお、上記のようにCPU負荷の上限としてCPU使用率の値(例えば100%)が設定される場合には、サービスノードDB132のCPU負荷としてCPU使用率(%)が保持されている必要がある。
図23に、データ転送装置のセッションDBの接続状態(TCP使用時)を決める状態遷移図を示す。
初期状態3001(CLOSED)は未接続を示す。初期状態3001で、SYNフラグが設定されたパケットを接続元から受信すると状態3002(SYN_RCV1)に遷移する。状態3002で、SYN−ACKフラグが設定されたパケットを接続先から受信すると状態3003(SYN_RCV2)に遷移する。状態3003で、ACKフラグが設定されたパケットを接続元から受信すると状態3004(OPEN)に遷移する。図9Aの接続状態910の値「OPEN」は、セッションの状態が状態3004または後述する状態3102であることを意味する。
状態3004は接続が確立した状態である。状態3004で、FINフラグが設定されたパケットを接続元または接続先のいずれかから受信すると状態3005(FIN_WAIT)に遷移する。状態3005において、FINフラグが設定された先ほどのパケットの送信先から、FIN−ACKフラグが設定されたパケットを受信すると状態3006(CLOSE_WAIT)に遷移する。なお、FIN−ACKフラグをFINフラグとACKフラグの2回に分けても同じ意味である。状態3006で、最後に受信したFINに対するACKを受信すると状態3007(TIMEOUT)に遷移する。
これらはTCP通信の接続および切断の通常の遷移に基づいている。状態3007では、一定時間経過した後、初期状態3001に遷移する。タイムアウトまでの時間は、NAT装置における公知または周知の技術に準拠することができる。
図24にデータ転送装置のセッションDBの接続状態(UDP使用時)を決める状態遷移図を示す。
UDPのようなコネクションレス通信の場合、セッションがいつまで続いているか厳密に判断できないため、通信が一定時間なければセッションが一度終了したものと見なす。初期状態3101(CLOSED)は未接続を示す。初期状態3101から、パケットを受信すると状態3102(OPEN)に遷移する。この際、最初に受信したパケットの送信元を接続元、送信先を接続先とする。
状態3102は接続が確立したことを示す。状態3102では、パケットを受信するたびにタイマーをセットし、一定時間パケットの受信が、接続元、接続先双方から無ければ、状態3101に遷移する。
以上に説明した実施形態のリソースマッピングによれば、広域網102を介して互いに接続される管理装置101、データ転送装置103、ユーザ端末104、およびLAN107によってデータ転送装置103と接続されるサーバ105およびDNS106から構成される分散処理システムにおいて、多段に接続されたサービスプログラムによって構成される分散アプリケーションを実行する際、データ転送装置103は、隣接するサービスノードの稼動情報のみでなく、アプリケーショングラフに基づいて、間接的に利用するサービスノードの稼動情報にも基づいて、隣接するサービスノードをサービスプログラム実行環境とする。これによって、総合的に分散アプリケーションの応答遅延時間を短縮することができる。さらに、応答遅延時間以外の指標を用いてリソースマッピングを行うことによって、省電力化または負荷の平坦化等を実現することもできる。