JP6501694B2 - 計算機システム及び計算機システムのタスク実行方法 - Google Patents

Description

本発明は、計算機を用いた優先度の付いたタスクの実行方法に関する。

クラウドサービス（以下、クラウド）におけるInfrastructure as a Service (IaaS)では、物理的なサーバやネットワーク機器等のInformation Technology (IT)リソース(以下、リソース)を、利用者ごとに論理的に分割したテナントとよばれる単位で提供する。テナントには、論理的に分割されたサーバ上で動作する仮想的な計算機のVirtual Machine (VM)や、Virtual Local Area Network (VLAN)等により提供される仮想的なネットワーク等が含まれる。VM作成等のテナントに対する管理は、ポータルサイト（以下、ポータル）から行うのが一般的である。よって、クラウドの提供には、物理的なリソースやポータルの提供するサーバ、およびリソースの管理を自動的に行うサーバ等を備えた、計算機システム（以下、クラウド基盤）が必要となる。またクラウドでは、各利用者がポータルから任意のタイミングで、VM作成等の要求が可能なため、これをクラウド基盤へ反映させるための処理であるタスクをクラウド基盤が随時受け付けられる必要がある。

しかしクラウド基盤では、複数のテナント(以下、マルチテナント)が物理リソースを共有しているため、費用対効果や物理的な制約等の関係から、1度に処理できるタスクの数に上限が設けられことが一般的である。このため、クラウドサービスを提供する事業者側の都合として、課金額や顧客の重要度に応じて、優先的にタスクを処理するテナントと、そうでないテナントを分けるため、クラウド基盤内部の処理の制御等を行う必要性がある。

他方、クラウドを利用する利用者の観点からも、例えばITシステムの立ち上げ時期は開発工期短縮のため急ぐ必要がある等、タスクの処理を急ぐ場合もあれば、そうでない場合もあり、状況に応じて課金額を変化させ、タスクの処理速度を利用者自ら調整するというニーズがある。

特許文献１には第１の計算機と、第１の計算機から送信されるリクエストを受け付ける第２の計算機とを備える計算機システムであって、第２の計算機は、第１の計算機からリクエストを受信した場合、受け付けたリクエストの総数が第１の閾値以下か否かを判定し、受け付けたリクエストの総数が第１の閾値より大きいと判定された場合、第１の計算機から受信したリクエストの送信元のユーザが所属するグループを特定し、特定されたグループから受け付けたリクエスト数が第２の閾値以下か否かを判定し、特定されたグループから受け付けたリクエスト数が第２の閾値以下と判定された場合、特定されたグループからのリクエストを受け付けることが開示されている。

特開:2011-70435

クラウド基盤は、VM作成等のタスクを処理する、もしくは作成されたVMやネットワーク等を管理する仮想化管理サーバを備える。しかし、仮想化管理サーバはマルチテナントで共有される。そのため、特定のテナントの利用者がポータル等からVM作成等のタスクを大量に要求した場合、他のテナントのタスクの実行が妨げられる。

これを防ぐ方法の一例として、特許文献１がある。特許文献1では、同時に受付可能なリクエスト（本願のタスクに相当）数の上限閾値を組織（本願のテナントに相当）毎に設けることで、特定の組織からのリクエストがクラウド基盤へ集中した場合でも、他組織からのリクエストの受け付けを可能にすることが開示されている。

しかし、特許文献1では、受け付けられたリクエストを実行するスレッド間では、優劣無く同等にリクエストが処理される。

そのため、特許文献1のリクエスト制御方法を、本願が対象とするクラウド基盤へ適用した場合、タスクの受け付けに関しては、テナント間で優劣を付けることは可能であるが、タスクが処理される仮想化管理サーバ上では、タスク間で処理能力の割り当て比率を変える等、優先度を制御できない。

また、特許文献1おいてリクエストが実行されるスレッドとは異なり、複数存在する仮想化管理サーバは、その種別やベンダ、バージョン等により、指定可能な優先度指標の形式が異なる。そのため、特許文献1のリクエスト制御方法について、タスクの実行時に仮想化管理サーバに対して、単純にテナントに割り当てられた優先度指標を指定する処理を加えるのみでは、優先度を受け付けられない仮想化管理サーバが発生する課題がある。

このためクラウ基盤全体として、テナントの優先度に応じたタスクの優先度制御を実施できず、一部のテナントのタスクの処理に必要な時間が増大し、Service Level Agreement (SLA)違反が発生する。

優先度が指定されたタスクの実行を要求する第一の計算機と、第一の計算機からタスクの実行要求を受付け、受付けた実行要求を指定された第一の優先度に基づいて格納する複数のタスクキューと、前記タスクキューの優先度に基づいて第三の計算機へタスクの実行を指示するタスク実行制御部を備える第二の計算機と、第二の計算機からタスクの実行要求を受付け、受付けたタスクを実行する複数の第三の計算機を備える計算機システムによって解決される。より詳細な構成は実施例により明らかにされるであろう。

クラウドシステムで優先度が指定されたタスクを優先度に従って実行させることを容易化できる。

本発明の概要を模式的に示す図である。 実施例におけるクラウド基盤の物理構成例を示す図である。 実施例における物理サーバの構成を示す図である。 実施例におけるタスク管理サーバの構成例を示す図である。 実施例におけるテナントテーブルの構成例を図である。 実施例における仮想化管理サーバテーブルの構成例を図である。 実施例における優先度値変換テーブルの構成例を図である。 実施例におけるタスク管理テーブルの構成例を図である。 実施例におけるタスク種別テーブルの構成例を図である。 実施例におけるタスク平均実行時間テーブルの構成例を図である。 実施例におけるタスク毎実行時間予測テーブルの構成例を図である。 実施例におけるタスク実行制御プログラムの処理に関するフローチャートである。 実施例におけるタスクの実行先選定に関するフローチャートである。 実施例におけるテナントランク変更に関する画面の例を示した図である。 実施例におけるタスク実行結果に関する画面の例を示した図である 実施例における中間仮想化管理サーバを含む構成の例を示した図である。 実施例における中間仮想化管理サーバを含む構成における優先度値設定処理のフローチャートである。

以下、本発明を実施するための形態である実施例を図面に従い説明する。

なお以降で示す実施例ならびに図面は、本発明を実施するための形態の一つであって、同様の処理が可能な他の構成・形態への適用を制限するものではない。

図1は、クラウド基盤100により、VM130等が動作する複数のテナント150が提供されており、各テナントを管理するテナント管理者160が、端末161からクラウド基盤100内のポータルサーバ200へブラウザ等を用いてアクセスすることで、テナント150を管理する状況を表している。

クラウド基盤100内には、前述のポータルサーバ200、タスク管理サーバ300、仮想化管理サーバ400がある。

ポータルサーバ200は、ブラウザ経由でアクセス可能なWebページや、Web Application Programming Interface (API)等により、テナント管理者160やクライアントプログラムに対して、テナントを管理する機能を提供し、VM作成等のタスクをタスク管理サーバ300へ送信する機能を持つ。

タスク管理サーバ300は、タスク管理プログラム310やタスク実行制御プログラム等を備え、ポータルサーバ200から受信したタスクを一時的に保持し、仮想化管理サーバ400へ、タスクの実行を依頼する機能を有する。

仮想化管理サーバ400は、クラウド基盤100内のVMやネットワーク等、物理/論理リソースの構成変更や状態を管理する機能を有し、タスク管理サーバ300から受信したタスクを実行キュー410へ一時的に格納後、すでに実行中のタスクの状態や仮想化管理サーバ400の性能等を考慮し、実行キューから取り出したタスクを実行する機能を有する。

仮想化管理サーバ400は、クラウド基盤内で１または複数存在し、各仮想化管理サーバ400が管理対象とするリソースの種別や、論理/物理的な範囲は異なる場合があり、加えて各仮想化管理サーバ400のベンダやバージョンの違い等により、受付可能なWeb API等のインターフェース(以下、I/F)が異なる。

各テナント150には、課金額や契約状態、またはクラウド事業者の設定等、重要度を表現する指標であるランク（図中ではGold、Silver、Bronzeと表現）が設定されているものとする。ランクとは、後述するクラウド基盤100内の処理について、あるテナントの管理者等が指示したVM作成等のタスクの処理を、他のテナントのタスクの実行より優先するか、を指定する指標であり、GoldはSilverより優先され、BronzeはSilverより優先されないものとして定義する。

ここで、テナント管理者160が管理者端末161上で、テナント150aに対するVM作成の操作を行った際、ポータルサーバから発行されたタスクが仮想化管理サーバ1 400aで実行されるまでの処理を説明する。なお、テナント150aに対しては、最上位のランクであるGoldが割り当てられているものとする。

ポータルサーバ200から発行されたタスク180aは、ネットワークを介してタスク管理サーバ300のタスク管理プログラム310が受信する。受信されたタスク180aは、タスク管理プログラム310により、テナント150a用の実行待ちタスクキュー350aへ追加される。

タスク管理プログラム310は、定期的に各テナントの実行待ちタスクキュー350を検査し、実行待ちタスクキュー350内に存在するタスクの実行を、タスク実行制御プログラムへ指示する。

具体的には、タスク管理プログラム310によってタスク実行待ちキュー350aから取り出されたタスク180aは、タスク実行制御プログラム320へ送信される。タスク180aを受信したタスク実行制御プログラム320は、テナント150aのランク等、テナントの性質と、タスクの種別と、仮想化管理サーバ400の状態等と、を後述の方法によって考慮し、タスク実行先となる仮想化タスク実行先となる仮想化管理サーバ400を１つ選定する。

次にタスク実行制御プログラム320は、選定した仮想化管理サーバ400に対してタスクの実行を依頼する。このとき、実行制御プログラム320は、より上位ランクのテナントのタスクが早く完了するように、タスクと共に優先度値を仮想化管理サーバ400へ送信する。

他方、前述のように仮想化管理サーバ400毎に受信可能な優先度指標も異なっている場合がある。よって本願では、テナントのランクと、各仮想化管理サーバ400が受信可能な優先度値を対応付けた、優先度値変換テーブルT300を仮想化管理サーバが持ち、タスク実行制御プログラム320は前記選定された仮想化管理サーバ400に応じてランクと優先度値の変換を行う。

具体的には、例えばタスク180aの実行先として仮想化管理サーバ400aがタスク管理サーバによって選定された場合、タスク実行制御プログラム320は、優先度値変換テーブルT300を参照し、タスクを実行したテナントのランクであるGoldから、仮想化管理サーバ400aが受信可能、かつGoldランクに対応する優先度値90を取得し、これをタスク180aと共に仮想化管理サーバ400aへ送信する。

タスクとタスクに対する優先度値を受信した仮想化管理サーバ410aは、前記受信したタスクを実行キュー410aへ追加し、前記受信した優先度値に応じてタスクを実行する。

なお、仮にタスク180aがVM作成ではなく、ファイアウォール設定等のネットワークに関するタスクであった場合は、該タスクを受け入れ可能な、仮想化管理サーバ2 400bがタスク実行先として選択される。さらに仮想化管理サーバ2 400bが受信可能な優先度値(例えばHigh等)へ、テナントのランクが変換される。

このような一連の処理を行うことで、テナントに設定されたランクとタスクを実行する仮想化管理サーバの優先度指標が異なる構成においても、テナントのランクに応じてタスクの優先制御が可能となる。

図2を用いてクラウド基盤の物理構成について説明する。

クラウド基盤100は、1または複数のネットワーク機器102と、１または複数の物理サーバ110と、から構成される。なお、クラウド基盤100内には、これら以外の物理機器や、機器同士を接続する配線等があってもよい。

ネットワーク機器102とは、例えば1または複数のネットワークスイッチ等であり、複数の物理サーバ102間の通信を可能にする。加えて、例えばインターネット101等のネットワークを介して、クラウド基盤102内外の通信を可能にする。なお、ネットワーク機器102は、ファイアウォール機器やロードバランサ機器等を含んでいてもよい。

物理サーバ110群は、１か複数のテナント用物理サーバ120、クラウド基盤を管理する１か複数のポータルサーバ200、タスク管理サーバ300、１か複数の仮想化管理サーバ400、クラウド基盤を管理する１か複数のその他管理系サーバ500等で構成される。

なお、テナント用物理サーバ120、ポータルサーバ200、タスク管理サーバ300、仮想化管理サーバ400、物理サーバ110は、同じ物理サーバ110であってもよいし、障害発生やセキュリティ事故の影響範囲の限定等を目的として、別々であってもよい。

また、ポータルサーバ200、タスク管理サーバ300、仮想化管理サーバ400、その他管理系サーバ500は、物理サーバ110上でVMとして動作させてもよい。

加えて、物理サーバ110には、記憶領域を提供するための外部ストレージ装置が接続されていてもよい。

テナント用物理サーバ120は、テナント150のVM130を動作させるために仮想化技術を提供するハイパーバイザや、テナント用物理サーバ120に接続されたネットワークをVM130が使用できるように仮想スイッチ等を備えるものとする。

ポータルサーバ200は、クラウド基盤100の内外から、クラウド基盤100に対する構成変更等の要求を受け付け、タスク管理サーバへ送信する機能を備える。ポータルサーバ200が要求を受け付けるI/Fは、例えばテナント管理者160が、端末161上のブラウザを用いてアクセスできるような形式であっても、Representational State Transfer API(REST API)のようなWeb APIであっても、その他の形式であってもよい。

タスク管理サーバ300は、ポータルサーバ200から受信したタスクを一時的に保持し、タスクの実行先となる仮想化管理サーバ400へ、タスクと優先度値を送信する機能を備える。なお、タスク管理サーバ300の詳細は後述する。

仮想化管理サーバ400は、タスク管理サーバ300等からタスクとタスクに対する優先度値を受信するI/Fと、受信済みタスクに対する新たな優先度値を受信するI/Fと、未実行のタスクを格納する実行キュー410と、タスクの内容に応じて、クラウド基盤100内のVMやネットワーク等、物理/論理リソースの構成を変更する機能を備える。

なお、仮想化管理サーバ400は、複数のタスクを同時に実行可能な機能を備えてもよく、同機能を備える場合に、同時に実行可能なタスクの数をタスク実行スロット数、タスク実行スロット数から実行中のタスク数を減じた値を、空きタスク実行スロット数とする。

前述の機能に加えて仮想化管理サーバ400は、未実行や実行中等のタスクの実行状態や、空きタスク実行スロット数、管理対象のリソース(VM130やネットワーク)の情報を、同サーバ外部のプログラムが取得できるI/Fを備える。

仮想化管理サーバ400は、タスク管理サーバ300から受信したタスクを実行キュー410へ一時的に格納後、すでに実行中のタスクの状態や仮想化管理サーバ400の性能等を考慮し、実行キューから取り出したタスクを実行する機能を備える。

仮想化管理サーバ400は、クラウド基盤内で１または複数存在し、各仮想化管理サーバ400が管理対象とするリソースの種別や、論理/物理的な範囲は異なるものとし、加えて各仮想化管理サーバ400のベンダやバージョンの違い等により、受付可能なWeb API等のI/Fが異なるものとする。

その他管理系サーバ500は、例えばユーザ管理や認証の機能を担うサーバや、課金管理を担うサーバ等である。
図3は図2で示した、物理サーバ120の物理的な構成の概要を示したものである。
物理サーバ120は、演算処理を行うためのCPU 191や一時記憶領域であるメモリ192、ネットワーク等と通信を行うためのネットワーク I/F 195、およびデータを格納する記憶領域のためのハードディスク194または外部記憶装置を利用するための外部ディスクIF 195を備える。こうした構成要素が内部BUS 197で互いに接続され、情報をやり取りする。

ネットワーク I/F 196の一例としてはNetwork Interface Card (NIC)であり、外部ディスクI/F 195の一例としてはHost Bus Adapter（HBA）、等である。なお、ハードディスク194、および外部ディスクIF 195は必須な要素ではない。

また、ディスプレイ等の出力装置やキーボード・マウスといった入出力I/F 193を備えてもよいし、Secure Shell（SSH）といった手段によりネットワーク経由で当該計算機が遠隔管理される場合には、入力I/F 193は必須の要素ではない。

図4は図2で示した、タスク管理サーバ300内部の構成について詳述する。

タスク管理サーバ300は、ポータルサーバ200から受信したタスクを管理、もしくは0実行するため、メモリ192内にタスク管理プログラム310と、タスク実行制御プログラム320と、ランク変更プログラム330と、を備える。

これらのプログラムはメモリ192に格納されCPU360により実行される。本実施例に記載されたプログラムはハードウェアとして実装されても良い。このため、タスク管理プログラム310、タスク実行制御プログラム320、ランク変更プログラム330は各々タスク管理部、タスク実行制御部、ランク変更部と呼ばれることもある。他のプログラムと説明されている構成要素についても同様である。

加えて、前述の各プログラムが利用する各種データを記録するため、メモリ192内にテナントテーブルT100と、仮想化管理サーバテーブルT200と、優先度値変換テーブルT300と、タスク管理テーブルT400と、タスク種別テーブルT500と、タスク平均実行時間T600と、タスク実行時間予測テーブルT700と、を備える。

さらに、CPU360、メモリ192、外部記憶装置370、I/Oデバイス380はネットワークを介して接続されており、各種テーブルは外部記憶装置に格納されてもよい。

また、I/Oデバイスはディスプレイ、マウス、キーボード等の入出力機器であり、タスク実行制御プログラム320等の処理結果が出力される。

本実施例ではタスク管理サーバにI/Oデバイスが接続されている例を説明しているが、ポータルサーバ200等の他のサーバに接続されていてもよく、処理結果はインターネット101経由で接続されている外部の端末に出力されるようにしても良い。

なお、プログラム310〜330は、それぞれメモリ上に展開され、動作してもよいし、1つのプログラムに統合されていたり、各プログラムを有するサーバが分かれていたり、これ以外の形態であってもよい。また、前記各テーブルは、メモリ上に展開されていても、Database (DB)等に格納されている等の形態でもよい。なお、各テーブルの詳細は後述する。

タスク管理プログラム310は、テナント毎に実効待ちタスクキュー350を備え、ポータルサーバ200から発行されたタスクを受信し、上位ランクのテナントのタスクが優先的に実行されるよう後述の実行待ちタスクキュー350からタスクを取り出し、タスクをタスク実行制御プログラムへ送信する機能を有する。

タスクを受信したタスク管理プログラム310は、タスクを発行したテナント150を特定し、特定されたテナントの実行待ちタスクキュー350へ追加する。

前記タスクを発行したテナント150を特定する方法としては、例えばタスク受信時に合わせてタスクを発行したテナント150の情報を受け取る形式であってもよいし、タスク内にテナント150を特定する情報が含まれている形式であってもよい。または、タスクを送信したテナント管理者160の情報や、テナント管理者160の端末161等、発信元から特定する形式であってもよい。

各テナントの実行待ちタスクキュー350は、タスク管理プログラム310により定期的に検査され、上位ランクのテナントのタスクが、より優先的に実行待ちタスクキュー350から取り出され、実行されるように制御される。

具体的には、例えばGoldのランクが割り当てられたテナントのタスクであれば、1回の検査で3個、Silverランクのテナントのタスクであれば、1回の検査で2つのタスクを実行待ちタスクキュー350から取り出し、タスク実行制御プログラム320へ渡す、等の方法が考えられる。

また、特定のテナントのタスクでクラウド基盤のリソースが過剰に消費されることを防ぐため、後述のテナントテーブルT100でテナント毎に定められた、同時タスク実行上限数T105により、1つのテナントに対して同時に実行できるタスクの数を制限してもよい。

なお、実行待ちタスクキュー350に関する実装の方法として、後述のタスク管理テーブルT400を基に、動作の高速化を目的にタスク管理サーバ300のメモリ上へテナント毎に生成しても良いし、タスク管理テーブルT400を都度参照するようにしても良い。

タスク実行制御プログラム320は、タスク管理プログラム310から受信したタスクについて、１か複数の仮想化管理サーバ400からタスクの実行先となるものを選定し、テナントのランクを、選定された仮想化管理サーバが受信可能な優先度値へ変換し、タスクと前記優先度値を選定された仮想化管理サーバ400へ送信する機能を有する。なお、タスク実行制御プログラム320に関する処理の詳細は図12にて後述する。

ランク変更プログラム330は、テナントに対するランクが変更された際に、タスク実行制御プログラム320から仮想化管理サーバ400へ送信済みのタスクについて、変更されたテナントのランクに従ってタスクの優先度値の変更を実施する機能を有する。なお、ランク変更プログラム330は図14で詳述する。

図5はテナントの構成を管理するための、テナントテーブルT100の構成例である。
テナントテーブルT100は、クラウド基盤100内でテナントを一意に識別する識別子であるテナントID T101と、テナントの名称を示すT102と、テナントのランクT103と、デフォルト仮想化管理サーバID T104と、クラウド基盤100内で同時に実行可能なテナントの構成変更等のタスクの上限を規定する、同時タスク実行上限数T105と、投機タスク許可フラグT106と、を有する。

ランクT103は、前述のGold, Silver, Bronzeのような2種類以上の離散値であってもよいし、このほか数値等の連続値であってもよい。また、ランクT103の値は、テナントの契約に依存して値が設定されていることを想定しているが、このほかテナントに対する課金額や契約年数等から自動的に算出してもよいし、テナント毎にクラウド基盤100の運用者事業者が人手で設定してもよい。

デフォルト仮想化管理サーバID T104は、クラウド基盤100の運用事業者観点での運用効率向上を考慮した値であり、特定のテナントに対して、タスクの事項先として利用する仮想化管理サーバ400の限定を可能にする（以下、限定された仮想化管理サーバ400をデフォルト管理サーバと呼ぶ）。
一例としては、障害発生時等に、特定のテナントのVMが限定された仮想化管理サーバ400の管轄下に存在していることにより、障害原因の切り分け効率向上が期待できる、等である。

なお、デフォルト仮想化管理サーバID T103は、例えば、クラウド基盤の運用事業者が人手で指定してもよいし、テナントの契約時期等に応じて自動的に決定してもよい。また、デフォルト仮想化管理サーバID T103に指定される仮想サーバIDは、１つの仮想化管理サーバ400の識別子であってもよいし、複数でもよい。

同時タスク実行上限数T105は、テナントに対して、すべての仮想化管理サーバ400上で同時に実行可能な、タスク数の上限を定めたものであり、前述のタスク管理プログラム310が、実行待ちタスクキューからタスクを取り出す際に参照される。なお、同時タスク実行上限数T105は、ランクT103に応じて自動的に決定されてもよいし、クラウド基盤100の運用事業者により、手動で設定されてもよい。

投機タスク許可フラグT106は、タスク実行制御プログラムに対して、図8で後述の投機タスクの生成を、図13で詳述の処理で許可するかどうかを示すものである。なお、該フラグは「Yes/No」の2値をとり、例えばGold等の上位ランクは「Yes」、それ以外のSilver/Bronzeは「No」等、自動的に決定されてもよいし、テナント150枚にクラウド基盤100の運用事業者が人手で決定してもよい。

図6は仮想化管理サーバ400の情報を管理するために用いる、仮想化管理サーバ管理テーブルT200の構成例である。
仮想化管理サーバテーブルT200は、仮想化管理サーバ400をクラウド基盤100内で一意に特定する仮想化管理サーバID T201と、仮想化管理サーバ400のIPアドレスT202と、タスク実行スロット数T203と、仮想化管理サーバ400のCPUコア周波数T204と、CPUコア数T205と、メモリ容量T206と、実行可能なタスクの種別を示す実行可能タスク種別T207を備える。

IPアドレスT202は、仮想化管理サーバ400にアクセスするためのネットワークアドレスであり、このほかUniform Resource Identifier (URI)等であってもよい。
タスク実行スロット数T203、各仮想化管理サーバ400で同時に実行可能なタスクの数示したものであり、例えば仮想化管理サーバ400の導入時にクラウド基盤100の運用事業者により人手に定められてもよいし、Web APIを利用して自動的に仮想化管理サーバ400から値を取得し、記載してもよい。

タスク実行スロット数T203、および実行可能タスク種別T207は、タスク実行制御プログラムがタスクの実効先となる仮想化管理サーバ400を選定する際に用いられる。
CPUコア周波数T204と、CPUコア数T205と、メモリ容量T206は、仮想化管理サーバ400の性能を示す指標であり、図7の説明で後述のタスク受け入れ可否を自動で決定するために参照される。

図7はテナント150毎に設定されたランクから仮想化管理サーバ400が受信可能な優先度値への変換に用いる、優先度値変換テーブルT300の構成例である。

優先度値変換テーブルT300は、仮想化管理サーバ400を一意に識別する仮想化管理サーバID T301毎に、テナントのランクT302と、仮想化管理サーバ400が受信可能な優先度値T303と、該仮想化管理サーバ400がランクT301のテナントのタスクを受け入れ可能かを示す、タスク受け入れ可能フラグT304を持つ。

優先度値T303は、仮想化管理サーバ400が受信可能な値であればよく、仮想化管理サーバの種別やバージョン、ベンダによって、例えば0から100の数値であったり、High/Mid/Low等の値であったり、CPU/メモリ等のリソースの配分を示すシェア値であったり、Unix(登録商標） OSにおけるプロセス間の優先度を示すnice値等である。

一例をとして、図7ではGoldランクのテナントのタスクに対して優先度値90、 Silverに対して60、 Bronzeに対して20が、優先度値変換テーブルT300に記載されている場合、タスク実行制御プログラム320は、タスク管理プログラム310から受信したGoldランクのテナントのタスクを仮想化管理サーバ400へ送信する際、タスクと優先度値90を仮想化管理サーバ400へ送信する。

なお、テナント150のランクから優先度値への変換は、優先度値変換テーブルT300を用いず、プログラム上で計算により求めてもよく、この場合、優先度値変換テーブルT300は必須要素ではない。

また、ランクT301に対する優先度値T303の値は、クラウド基盤100の運用事業者が人手で決定する方法のほか、例えば図6で示したCPUコア周波数T204と、CPUコア数T205と、メモリ容量T206から自動的に決定してもよい。

タスク受け入れ可能フラグT304は、仮想化管理サーバID T301を持つ仮想化管理サーバ400が、ランクT301に記載されたランクのタスクを受け入れるか、を示すフラグであり、例えば「Yes」の場合は受け入れ、「No」の場合は拒否することを示す。

タスク受け入れ可能フラグT304は、クラウド基盤100の運用事業者が人手で決定する方法のほか、例えば、タスク完了までの時間短縮を狙い、高性能な仮想化管理サーバ400は、Goldランクのテナントのタスクのみを受け入れるようにするなど、図6で示したCPUコア周波数T204と、CPUコア数T205と、メモリ容量T206等の、仮想化管理サーバ400性能を示す指標から、自動的に決定する方法等である。

図8はタスクを管理するための、タスク管理テーブルT400の構成例である。
タスク管理テーブルT400は、タスクの情報をタスク毎に管理するためのテーブルであり、テナントID T401と、タスクID T402と、状態T403と、タスクタイプT404と、依存タスクID T405と、親タスクID T406と、実行先仮想化管理サーバID T407と、実行ID T408と、タスク受付時刻T409と、タスク実行開始時刻T410と、タスク実行完了時刻T411と、から構成され、タスク管理プログラムが実行待ちタスクキュー350へタスクを追加した際にレコードが追加される。

テナントID T401は、タスクがどのテナント150のものかを示すものであり、図6で述べた仮想化管理サーバID T201に該当する。

タスクID T402は、タスク管理プログラム310によって生成される値であり、クラウド基盤内100内でタスクを一意に特定する識別子である。

タスクの状態T403は、タスクの実行状態を示すものであり、実行待ちタスクキュー350の追加済みであるが、未実行なことを示す「実行待ち」、実行待ちタスクキュー350から取り出され、仮想化管理サーバ400上へ送信されたことを示す「実行中」、仮想化管理サーバ400上での実行が完了したことを示す「完了」、タスクの処理に関してエラーが発生したことを示す「エラー終了」の値をとり、タスク管理プログラム310によって、定期的に仮想化管理サーバ400上で実行中のタスクを監視し、更新する。

なお、状態T403は、例えばタスクがキャンセルされたことを示す値など、前述の値以外が含まれてもよい。

タスク種別ID T404は、図9で後述のタスク種別ID T501に対応するものであり、実行されるタスクの種別を示した値をとる。なお、取りえる値の詳細は図9で述べる。

タスクタイプT405は、通常タスクと、投機タスクと、環境設定タスクの3種類の値を取りえる。

通常タスクとは、ポータルサーバ200が発行したタスクであることを示す。投機タスクとは、図13で後述のタスク実行制御プログラム320が、通常タスクの実行先となる仮想化管理サーバ400を選定する過程で、通常タスクと同じ内容のタスクを、通常タスクの実行先とは異なる仮想化管理サーバ400にて、並列実行することを判断した場合に、タスク実行制御プログラムが新たに生成するタスクである。

環境設定タスクとは、図13で後述のタスク実行制御プログラム320が、通常タスク、または投機タスクの実行を仮想化サーバへ依頼するにあたり、該タスクを実行する前に行うべき環境設定を実施するタスクであり、タスク実行制御プログラム320によって生成される。なお、環境設定タスクを生成し、実行すべきかどうかの判断については、図10で後述する。

依存タスクID T406は、タスク実行制御プログラム320によって前述の環境設定タスクが生成された際に、前記環境設定タスクの完了後でないと、実行不可能なタスクのタスクIDT402が記載されるものである。なお、本処理については図13に詳述する。

親タスクID T407は、タスク実行制御プログラム320によって前述の投機タスクが生成された場合に、投機タスクを生成する起点となったタスクのタスクID T402が記載されるものである。

実行先仮想化管理サーバID T408は、タスクの実行先としてタスクが送信された仮想化管理サーバ400の識別子を示し、図6で述べた仮想化管理サーバID T201に対応する。
実行ID T409は、仮想化管理サーバ400上でタスクを一意に特定する識別子であり、タスク実行制御プログラム320が、タスクを仮想化管理サーバ400へ送信した際にタスク実行制御プログラム320によって記録される。

タスク受付時刻T410は、タスク管理プログラム310が該タスクを受信した時刻を示し、タスク管理プログラム310によって更新される。

タスク実行開始時刻T411は、該タスクを仮想化管理サーバ400へ送信した時刻を示し、タスク実行制御プログラムによって更新される。

タスク実行完了時刻T412は、該タスクが仮想化管理サーバ400上で実行完了となった時刻を示し、タスク管理プログラム310によって、定期的に仮想化管理サーバ400上で実行中のタスクを監視し、更新する。

図9はタスク種別毎の情報を管理する、タスク種別テーブルT500の構成例である。

タスク種別テーブルT500は、タスクの種別毎に、タスク種別ID T501と、タスク種別名T502と、特定仮想化管理サーバへの依存フラグT503と、ランク毎の上限実行時間T504と、依存環境設定タスク種別ID T505を備える。

タスク種別ID T501は、タスクの種別を一意に特定する識別子であり、例えばVM作成は「Create_VM」、FW設定は「FW_Setting」、既存VMへのディスク追加は「Add_Disk」、テナント150のVM130等が使用するネットワークの作成(VLANの設定等)は「Create_NW」等、の値をとる。

タスク種別名T502は、前述のタスク種別ID T501に対応する名称であり、図14で詳述する画面等に表示されるものである。
特定仮想化管理サーバへの依存フラグT503は、例えば既存のVMへのディスク追加等は、必ずディスク追加対象のVMを管轄下に持つ仮想化管理サーバ400にてタスクを実行する必要がある。対象のVMを別の仮想化管理サーバ400の管轄下へマイグレーションすれば、VMに対するディスク追加のタスクを実行することも可能であるが、マイグレーションは処理コストが高い。そのため、ディスク追加の特定仮想化管理サーバへの依存フラグT503は「No」となる。

他方、VM作成等は、例えば作成されたVMが適切に通信できるようなテナントのネットワーク事前に複数の仮想化管理サーバ400の管轄下に敷設されていれば、どの仮想化管理サーバ400でも実行可能となるため、特定仮想化管理サーバへの依存フラグT503は「Yes」となる。

上限実行時間T504、タスク種別ID T501毎に、各ランクで遵守すべきタスクの上限実行時間を記載したものであり、後述の図12で説明するタスクの実行先となる仮想化管理サーバ400を選定する際の指標として用いられる。なお、上限実行時間T504は、例えば、顧客との契約内容を基に、クラウド基盤100の運用事業者が人手で決めてもよいし、図10で後述の平均実行時間T603に対して1.5倍等の余裕率を掛けるなどして、自動的に決定してもよい。

依存環境設定タスク種別ID T505は、タスク種別ID T501毎に、依存する環境設定タスクのタスク種別IDを記載したものであり、後述のタスク毎実行時間予測テーブルT700の実行要件充足フラグT703のフラグ設定と、タスク実行制御プログラム320の処理にて、環境設定タスクを生成すべきかどうかの判断に利用される。

図10は仮想化管理サーバ400とタスク種別毎のタスク平均実行時間を管理する、タスク平均実行時間テーブルT600の構成例である。

タスク平均実行時間テーブルT600は、各仮想化管理サーバ400で、各タスク種別のタスクを実行した際の平均実行時間を管理するテーブルであり、仮想化管理サーバID T601と、タスク種別ID T602と、平均実行時間T603から構成される。なお、このテーブルは図13で後述するタスク実行先の仮想化管理サーバ400を選定する処理において、後述の図11で述べるタスク実行完了予測時間T704を生成するために用いられる。

仮想化管理サーバID T601は、図6で述べた仮想化管理サーバID T201に対応する値であり、タスク種別ID T602は、図9で述べたタスク種別ID T501に対応する値である。

平均実行時間T603は、仮想化管理サーバID T601の識別子を持つ仮想化管理サーバにて、タスク種別IDのタスクを実行した場合に、タスクの実行に要した平均実行時間をランク毎に記載したものである。平均実行時間T603の各値は、例えばタスク管理テーブルT400に記録されたタスク実行開始時刻T411とタスク実行完了時刻T412から定期的に算出することで更新してもよく、クラウド基盤100の運用事業者によって、仮想化管理サーバ導入前に各タスク種別を該仮想化管理サーバ上で実行し、得られた時間を人手で記載してもよい。

図11はタスクの実行先となる仮想化管理サーバ400の選定指標となるタスク毎実行時間予測テーブルの構成例である。

タスク毎実行時間予測テーブルT700は、図13で後述のタスクの実行先となる仮想化管理サーバ400の選定する際の指標となる値を記載したテーブルである。該テーブルは、前記選定処理の過程で、タスク実行先選定プログラム320により、タスク毎にメモリ上に生成され、実行先の仮想化管理サーバ400が決定した段階でメモリから削除されるものであり、他のテーブルのように永続化されない。なお、該テーブルを用いずに前記指標メモリ上で管理する形態でもよく、この場合、該テーブルは必須要素ではない。

タスク毎実行時間予測テーブルT700は、仮想化管理サーバID T700と、優先選択フラグT702と、実行要件充足フラグT703と、タスク実行完了予測時間T704と、を備える。

仮想化管理サーバID T701は、図6で述べた仮想化管理サーバID T201に対応する値である。

優先選択フラグT702は、タスクの実行先として、優先的に選択すべきかを示したフラグである。具体的には、各仮想化管理サーバ400について、テナントテーブルT100のデフォルト仮想化管理サーバID T104に仮想化管理サーバID T701の識別子が記載されている、または優先度値変換テーブルT300について、仮想化管理サーバID T301とランクT302から特定されるタスク受け入れフラグT304が「Yes」である場合に、優先選択フラグT702は「Yes」、それ以外の場合は「No」となる。

実行先要件充足フラグT703は、該タスクの実行に対して、各仮想化管理サーバ400が管轄する対象の環境が、要件を満たしているかどうかを示すフラグであり、満たしている場合は「Yes」、満たしていない場合は「No」となる。

なお、前記環境の要件を満たしていない場合は、環境設定タスクを新たに生成し、実行することとなる。

該タスクの前に、環境設定タスクを実行すべきかどうかの判断は、通常タスクのタスク内容に対して、現状の仮想化管理サーバ400配下の環境が、タスク種別テーブルT500に記載された依存環境設定タス種別ID T505に記載された種別のタスクを実行する必要があるかどうかで行う。

具体的には、例えば実行されるタスクがVM作成の場合、作成されたVMが動作可能なように、仮想化管理サーバ400が管轄するテナントのネットワークの環境が準備されている必要がある。よって、前述のようにタスクの実行に対して前記環境が要件を満たしていない場合は、要件を満たすための環境設定タスクを新たに生成し、該タスクの前に実行する必要があるため、実行先要件充足フラグT703を「Yes」とする。他方、該タスクを実行する環境が整っている場合は、実行先要件充足フラグT703を「No」とする。

タスク実行完了予測時間T704は、仮想化管理サーバID T701記載の識別子を持つ仮想化管理サーバにおいて該タスクを実行した場合に、タスク完了までに必要な予測時間を示す。なお、前記予測時間を算出する方法の例は、図13にて詳述する。
図12はタスク実行制御プログラムがタスク管理サーバ310からタスク実行要求を受信し、タスク実行先の選定と、選定された仮想化管理サーバ400が受信可能な優先度値へランクを変換し、タスクと共に選定された仮想化管理サーバ400へ送信する処理について説明するフローチャートである。

タスク実行制御プログラム320は、ステップS100にて、タスク管理プログラムからタスクの実行要求を受け付ける。

タスクの実行要求を受け取ったタスク実行制御プログラム320は、ステップS101にて、
タスク管理テーブルT400の該タスクのレコードについて、依存タスクID T405を参照し、依存するタスクのタスクIDを取得する。次に、前記取得したタスクIDを持つタスクのレコードについて、状態T402の値を取得する。ここで、前記取得した状態T402の値が「完了」であればステップS102へ進み、それ以外であればステップS107へ進む。

ステップS102では、該タスクの実行先となる仮想化管理サーバ400が選定済みかどうかを判定するため、タスク管理テーブルT400の該タスクのレコードの実行先仮想化管理サーバID T407の値を取得し、値が記載されていなければステップS103へ進み、記載があればステップS105へ進む。

なお、ステップS102でタスクの実行先仮想化管理サーバ400が選定済みであるケースは、該タスクが投機タスクであるか、環境設定タスクである場合に加えて、以前に一度実行を試みたが、ステップS101にて依存するタスクが未完了と判定され、処理を続行できなかったタスクの場合である。

ステップS103では、１または複数の仮想化管理サーバ400の中から、タスクの実行先となるものを選定し、ステップ104へ進む。なお、ステップS103の処理については、図13で詳述する。

ステップS104では、直前のステップS103のタスク実行先となる仮想化管理サーバ400を選定する過程で、該タスクが完了を待つべき新規タスクが生成されたか判定する。前記判定は、タスク管理テーブルT400の該タスクのレコードについて、依存タスクID T405の値を取得することで行い、値が取得された場合は、該タスクが依存するタスクが新たに生成されたことを示し、依存タスクの完了を待つため該タスクは実行せず、ステップS107へ進む。また、値が取得されない場合は、ステップS105へ進む。

ステップS105では、該タスクを実行したテナントランクから、選定された仮想化管理サーバ400が受信可能な優先度値への変換を行い、ステップS106へ進む。

具体的には、優先度値変換テーブルT300から、選定された仮想化管理サーバのIDと、該タスクを実行したテナントに対応する優先度値T303を取得することで、ランクと優先度値の変換を行う。

ステップS106では、タスク実行制御プログラムが、選定された仮想化管理サーバ400に対して、タスクと前記変換された優先度値を送信し、ステップS108で処理を終える。

ステップ108では、該タスクの実行に際して、依存タスクの完了を待つ必要があることから、タスクの実行を一度保留させるため、タスク管理プログラム310に対して、該タスクを実行待ちタスクキューへ戻すよう指示を出し、ステップS108にて処理終了となる。

以上、一連のタスク実行制御プログラム320の処理により、タスクの実行先となる仮想化管理サーバ400の選定と、選定された仮想化管理サーバ400が受信可能な優先度値へのランクの変換が実施され、タスクと共に選定された仮想化管理サーバ400へ送信される。これにより、本願が対象とする、仮想化管理サーバ400毎に受信可能な優先度値の指標が異なる構成において、テナントに対して割り当てられた優先度に応じて、タスクの処理の優先制御ができる。

図13にて、タスク実行制御プログラムが、１または複数の仮想化管理サーバ400の中から、タスクの実行先となる仮想化管理サーバ400を１つ選定する処理について説明するフローチャートである。

仮想化管理サーバの選定は、次の観点に従って実施する。
まず、該タスクのタスク種別を受け入れ可能であり、該タスクを実行した場合の実行時間が最短となるものを選択する。

ただし、テナントに対して、またはテナントのランクに対して優先的に選択すべき１または複数の仮想化管理サーバ400が指定されている場合に、前記指定された１または複数の仮想化管理サーバ400の中から、該タスクを実行した場合の実行時間が最短となるものを選択する。

加えて、1または複数の仮想化管理サーバ400で該タスクを実行した場合で、タスク完了までの時間が、タスク種別テーブルT500に記載された、ランクに応じた上限実行時間T504を超えると予測された場合、該タスクと同内容の投機タスクを新たに生成する。前記生成された投機タスクに対して、前記指定された以外の選択１または複数の仮想化管理サーバ400以外から、該タスクを実行した場合の実行時間が最短となるものを選択する。

なお、同内容の通常タスクと投機タスクが同時に実行された場合、タスク管理プログラム310が両タスクの状態を監視し、どちらかが完了したタイミングをもって、タスク完了とし、未完了のタスクのキャンセル/削除や、例えば作成途中であったVM等、不要なリソースの削除を併せて行う。

以降では前記観点に従って、タスクの実行先となる仮想化管理サーバを選定する処理について説明する。

実行制御プログラムS320は、ステップ200にてタスクの実行先選定を開始し、ステップS201へ進む。

ステップS201では、該タスクのタスク種別を受け入れ可能な仮想化管理サーバ400に関する、タスク毎実行時間予測テーブルT700を生成する。
具体的には、仮想化管理サーバテーブルT200を参照し、実行可能タスク種別T207に該タスクの種別を持つ、１または仮想化管理サーバ複数の仮想化管理サーバIDを取得し、タスク毎実行時間予測テーブルT700をメモリ上に生成する。

このとき、図11で述べた方法に従って、優先選択フラグT702と、実行先要件充足フラグT703を設定する。

加えて、各仮想化管理サーバ400のレコード毎に、タスク実行予測時間T704を算出し、前記タスク毎実行時間予測テーブルT700に設定する。

前記タスク実行予測時間T704を算出する方法の一例として、例えば、該タスクと仮想化管理サーバ400へ送信済みのタスクについて、仮想化管理サーバID T701記載の識別子と、タスクの種別と、タスクを実行したテナント150のランクから、タスク平均実行時間テーブルT600から平均実行時間を特定し、各仮想化サーバ間に合計した値とする。

さらに、実行先要件充足フラグT703が「Yes」となっている場合は、図11で述べたとおり、該タスクを実行する前に、例えばテナントネットワーク作成等の新たな環境設定タスクを実効する必要があるため、前記合計した前記平均実行時間へ、前記環境設定タスクの平均実行時間を加算し、これをタスク実行予測時間T704として、前記タスク毎実行時間予測テーブルT700に設定する。

なお、仮想化管理サーバテーブルのT200のタスク実行スロット数T203と、Web API等で取得できる実行キュー410に存在するタスクの個数等から、例えば、実行キュー410に実行待ちのタスクがあるが、タスク実行スロット数が多く、かつ完了が近いタスクがあるため、すぐに実行キュー410が空になる見込み等の予測を行い、該タスクの実行時間の予測へ加味してもよい。加えて、より高度なタスクスケジューリング手法を用いて、タスク実行時間の予測を行ってもよい。

ステップS202では、テナントまたはテナントのランクに対して、優先的に選択すべき仮想化管理サーバが指定されているかを判定する。

具体的には、前記タスク毎実行時間予測テーブルT700の優先選択フラグT602が「Yes」となっているレコードが存在するかを検索し、存在しない場合はステップS203へ進み、存在する場合はステップS206へ進む。

ステップS203では、前記タスク毎実行時間予測テーブルT700に記載された仮想化管理サーバ400のうち、タスク実行予測時間T704が最短となる仮想化管理サーバ400を、該タスクの実行先として選択する。

ステップS204では、該タスクを実行するにあたり、選択された仮想化管理サーバ400の管轄下のリソースに対して、環境設定用のタスクを実行する必要があるかを判定する。

具体的には、前記タスク毎実行時間予測テーブルT700の実行要件充足フラグT703を検査し、「Yes」であればステップS205へ進み、「No」であればステップS209へ進む。

ステップS209では、選択された仮想化管理サーバ400の管轄下のリソースに対して実施する、環境設定タスクを新たに生成し、ステップS205へ進む。

具体的には、タスク管理テーブルT400へ環境設定タスクのレコードを追記する。さらに、タスク管理テーブルT400の該タスクのレコードについて、依存タスクID T406を前記環境設定タスクのタスクIDで更新する。
なお、前記環境設定タスクは、該タスクを実行する前提として行うべきものである。そのため、タスク管理プログラムは、前記環境設定タスクを他のタスクより優先的に実行すべきものと判断し、例えば実行待ちタスクキュー350の中から優先的に取り出す等、を行ってもよい。

次に、ステップS202にて、デフォルト仮想化管理サーバ、またはランクによるタスク受け入れ先仮想化管理サーバの指定があると判定され、S206へ進んだ場合について述べる。

ステップS206では、投機タスクを生成する必要があるかどかを判定し、必要があればステップS208へ進み、不要であればステップS207へ進む。

投機タスクを生成するかどうかの判定は、まず指定された各仮想化管理サーバ400上で該タスクを実行した場合に、タスク種別テーブルT500に記載された、タスク種別毎の上限実効時間を遵守できるかを判定する。

前記判定の結果、前記上限実行時間を遵守できる仮想化管理サーバが存在すれば、投機タスクは生成しない。
他方、何れの仮想化管理サーバ400でも遵守できない見込みであり、かつ該タスクを実行したテナント150について、テナントテーブルT100の投機タスク許可フラグ106が「Yes」の場合は、前記上限実行時間の遵守を狙い、図11で述べた投機タスクを生成する。

ステップS207では、前記タスク毎実行時間予測テーブルT700から、優先選択フラグT702が「Yes」となっている仮想化管理サーバ400から、タスク完了までの時間が最短となるものを選択し、ステップS204へ進む。

ステップS208では、図8で述べた投機タスクの生成と、実行先の選定を行い、前述のステップS207、およびステップS204以降を実施する。

前記投機タスクの生成は、タスク管理テーブルT400へ、該タスクと同内容であるが、タスクID T402の異なるレコードを追加することで行う。このとき、タスクタイプT405を「投機タスク」、親タスクID T406を該タスクのタスクID T402とする。

加えて、前記タスク毎実行時間予測テーブルT700のうち、優先選択フラグT602が「No」となっているもの、すなわち、前記指定された想化管理サーバ400ではない、１か複数の仮想化管理サーバ400から、タスク完了までの時間が最短となるものを選択し、前記選択された仮想化管理サーバの識別子を、実行先仮想化管理サーバID T408へ記載する。

なお、タスクの実行先となる仮想化管理サーバ400を選定する方法は、上記以外であってもよく、一例として、実行中である上位ランクのタスクの数が少ない仮想化管理サーバ400を選択する方法がある。すなわちGoldのタスク数が少ない（SilverやBronzeのタスク数が多い）仮想化管理サーバ400を選ぶというものである。このほか、ランダムに選ぶ方法や、仮想化管理サーバ400へのタスク送信履歴を仮想化管理サーバ300が保持し、前回のタスクの実行要求を受信してから一番時間が経過している仮想化管理サーバ400を、タスクの実行先として選択する等の方法であってもよい。

最後に、ステップS205では、メモリ上に生成されたタスク毎実行時間予測テーブルT700を破棄し、処理終了となる。

S208で投機タスクを生成した場合は同じタスクを複数の仮想管理サーバへ実行するよう指示するが、仮想化管理サーバからタスクの実行が終わったことを示す情報を最初にタスク管理サーバが受け取ったときに、他のタスクの実行を中止するよう指示すれば無駄なタスクの実行を削減できるだけでなく最も早くタスクの実行を行うことができる。

また、仮想化管理サーバからタスクの実行が始まったことを示す情報を最初にタスク管理サーバが受け取ったときに、他のタスクの実行を中止するよう指示すれば、より無駄の無いタスク実行が可能となる。

以上の一連のタスク実行制御プログラム320の処理により、テナントに割り当てられたランクや各仮想化管理サーバの負荷状況等に応じた、タスクの実行先となる仮想化管理サーバ400の選択が可能となる。

図14はテナント管理者161の端末からテナント150の端末に出力するランクの変更申し込み画面の例である。

画面800は、テナント150をどのランクへ変更するかを選択可能なドロップダウンリスト811と、VM作成等の機能メニュー毎の平均実行時間を表示するテーブル820と、申し込みを実施するボタン831と、申し込みをキャンセルするボタン832を備え、例えばポータルサーバ200によってテナント管理者へ提供される。

なお、画面800の構成要素は、例えばランク毎の金額の表示や、ランクを変更する期間を指定可能なボタン等、上記以外の要素を含んでもよく、また例えば、ドロップダウンリスト811がチェックボックスであるなど、違う形態であってもよい。

テーブル820は、機能メニュー821と、ランク毎にタスクに平均実行時間822と、テナント150の現在のランクと、各機能メニューに対するタスクの平均実行時間の実績値を備え、テナント管理者161がテナント150のランクを変更する際に参考とするものである。

平均実行時間822は、例えば、タスク平均実行時間テーブル600に記載された平均実行時間T603について、全レコードの平均値を算出して表示してもよいし、タスク管理テーブルT400へ、各タスクを実行した際のランクを記録するフィールドを設け、タスク種別ID T404毎と前記記録されたランク毎に、タスク実行開示時刻T411とタスク完了時刻T421の差の平均値を算出する等してもよい。

また、表示される平均実行時間822の値は、例えば分単位で四捨五入する等、精度を下げたものを表示してもよい。

申し込みボタン831がテナント管理者161によって押下された場合、ポータルサーバからランク変更プログラム330に対して、テナント150のテナントIDとランクを含む、ランク変更通知が送信される。ポータルサーバから前記ランク変更通知を受け取ったランク変更プログラム330は、タスク管理プログラム310、およびタスク実行制御プログラム310が使用するテナントテーブルT100に記載された、テナントのランクを更新する。

具体的には、受信したテナントIDをキーに、テナントテーブルT100からランク変更対象のテナントのレコードを特定し、特定されたレコードのランクT103を、受信したランクに変更する。

次にランク変更プログラム330は、すでに仮想化管理サーバ400へ送信されたタスクの特定と、特定された仮想化管理サーバ400にたいして、新しいランクに対応する優先度値の通知を行う。

具体的には、まずタスク管理テーブルT400から受信したテナントIDをキーとし、状態T402が「実行中」のレコードを特定する。さらに、特定された各レコードから実行先仮想化管理サーバIDと、実行ID T408を取得する。

次に、ランク変更プログラム330は、受信した新しいランクに対応する優先度値を、前記取得した実行先仮想化管理サーバIDをキーに、優先度値変換テーブルから取得する。

さらにランク変更プログラム330は、前記取得した実行先仮想化管理サーバIDをキーに、仮想化管理サーバテーブルT200からIPアドレスT202を取得し、取得したIPアドレスを用い、各仮想化管理サーバ400に対して、優先度値を変更する対象タスクの前記取得した実行ID、新しいランクに対応する優先度値を送信し、各仮想化管理サーバ400は、受信した実行IDに対応するタスクに対して、受信した新しいランクに対応する優先度値を設定することで、テナント150に対するランク変更の処理は完了となる。

図15に、クラウド基盤100の運用事業者が、タスクの実行結果の情報を確認可能な画面の例を示す。

画面850は、タスクの実行結果を表示するテナント150を選択可能なドロップダウンリスト861と、表示する期間を指定するドロップダウンリスト862と、タスクの実行結果の情報を表示するテーブル870と、前記タスクの実行結果の情報を表計算ソフトウェア用のファイル等に出力するボタン880を備える。

なお、画面850の構成要素は、例えばテーブル870をソートするためのボタン等、上記以外の要素を含んでもよく、また例えば、ドロップダウンリスト861がチェックボックスであるなど、違う形態であってもよい。また、画面850は、例えばポータルサーバによって提供され、クラウド基盤100の運用事業者が使用する端末等に表示されてもよいし、タスク管理サーバ300の備えるI/Oデバイス380に表示しても良い。

タスクの実行結果の情報を表示するテーブル870はタスク毎に、タスクIDや、タスク種別、タスクを実行した際のランク、タスクの受付、実行開始、完了時刻等の情報を含む。

テーブル870は、ドロップダウンリスト861で指定されたテナントについて、例えばテナントID T401をキーにタスク管理テーブルT400から情報を取得する方法や、タスク管理テーブルT400とは別にタスクの実行結果を記録するログファイルをタスク管理プログラム310等がタスクサーバ内に出力し、これを基に生成してもよい。

また、テーブル870は、各タスクがタスク種別テーブルT500に記載された上限実行時間T504を超過したかどうかの情報を含んでも良い。

クラウド基盤100の運用事業者は、画面850を操作し、タスクの実行結果の情報を確認することで、例えばSLA違反となったタスクの有無を確認や、クラウド基盤100の仮想化管理サーバ400等のサーバの増強の増強を計画するうえで参考にすることが可能になる。

加えて、ボタン880により出力されたファイルをテナントの管理者161等の顧客へレポートとして提示することが可能なる。なお、出力されるファイルは、表計算ソフトウェア用のファイル以外に、前期タスクの実行時間等を表したグラフを含む画像ファイル等であってもよい。

また、画面880からテナントを選択するドロップダウンリスト861を除去し、同画面をテナント管理者161が、クラウド基盤100の運用事業者を介さずに直接確認できるようにしてもよい。

以上の本実施例で述べた構成要素および処理により、クラウド基盤100が複数種類の仮想化管理サーバ400を備える場合でも、テナント150に割り当てられたランクを各仮想化管理サーバ400が受信可能な優先度値へ変換し、前記変換された優先度値に基づいてよりタスクが処理される。これにより、テナントが複数存在するクラウド基盤100において、テナントの優先度に応じた時間でのタスク実行制御、すなわちタスクの処理に要する時間に差を設けることが可能となる。

実施例1では、タスク管理サーバ300から仮想化管理サーバ400に対して、直接タスクを送信していた。他方、クラウド基盤100内に存在するテナント150の数が増化した場合、より多くの仮想化管理サーバ400を導入することが想定される。その際、タスク管理サーバ300の負荷軽減や、リソース管理範囲限定によるメンテナンス性の向上、障害発生時の影響範囲の限定等を目的として、タスクを実行する依頼の中継や、配下のリソースを分担して管理する機能を有した中間仮想化管理サーバ500を、タスク管理サーバ300と仮想化管理サーバ400の間に導入することが考えられる。

そこで実施例2では、最上層のタスク管理サーバ300と最下層の仮想化管理サーバ400の間に、１または複数の中間仮想化管理サーバ500が存在する構成について述べる。

図16は実施例2の構成例である。クラウド基盤100は、タスク管理サーバ300と、１または複数の中間管理サーバ500と、１または複数の仮想化管理サーバ420を備え、ポータルサーバ等で発行されたタスクは、タスク管理サーバ300、および中間仮想化管理サーバ500を介して、何れかの仮想化管理サーバ420へ送信され、実行される。

中間仮想化管理サーバ500は、タスク管理サーバ300から受信したタスクを、管理下の仮想化管理サーバ420へ送信する機能を有する。
なお、中間仮想化管理サーバ500は、タスク管理サーバ300からタスクと共に受信する優先度値を、仮想の仮想化管理サーバへタスクと併せて送信する機能を有していてもよいし、有していなくてもよい。

中間仮想化管理サーバ500が、中間仮想化管理サーバ500aのように、管理下の仮想化管理サーバへ優先度値を伝播させる機能を有している場合は、例えば仮想化管理サーバ420a, または仮想化管理サーバ420bが、それぞれ受信可能な優先度値を、タスクと共に送信する。

他方、中間仮想化管理サーバ500bのように優先度値を伝播できない場合は、最下層のタスク管理サーバ420で実行されるタスクに対する優先度値の設定を目的として、図17で詳述する処理により、タスク管理サーバ300が仮想化管理サーバ420cや仮想化管理サーバ420dに対して、優先度値を直接送信する方法を用いる。

図17は図16中の中間仮想化管理サーバ500bのように、中間仮想化管理サーバ500が優先度値を下層の仮想化管理サーバへ伝播させる機能を持たない、配下の仮想化管理サーバ420cまたは430dに対して、仮想化管理サーバ300のタスク管理プログラム310が、優先度値を直接送信する方法について述べるフローチャートである。

実施例1の構成では、タスク実行制御プログラム320が、ランクから優先度値への変換処理を実施していたが、本実施例は、タスク管理プログラム310が該処理を行うことを特徴とする。

なお、本実施例では、各中間仮想化管理サーバ500おけるタスクを一意に特定するため、タスク管理テーブルT400に対して、タスクを送信した中間仮想化管理サーバのIDと、中間仮想化管理サーバでの実行IDを記録するフィールドが追加されるものとする。

タスク管理プログラム310は、中間仮想化サーバ500bから、仮想化管理サーバ420cまたは仮想化管理サーバ420dへ、タスクが送信されたことを検知して、ステップS300から処理を開始する。

これは例えば、タスク管理プログラム310が、タスク管理テーブルT400の状態T403を監視し、タスクの状態が「実行中」になったことを検知すればよい。

なお、状態T403等の更新は、例えばタスク管理プログラム310が、中間仮想化サーバ500bに対して定期的に問い合わせを実施し、更新するものとしてもよいし、中間仮想化管理サーバ500bから、能動的にタスク管理プログラム310へ通知させてもよい。

ステップS301では、実行中と新たに検知されたタスクについて、タスク管理テーブルT400から、タスクを実行したテナントのテナントID T401と、実行先仮想化官吏サーバIDを取得し、ステップS302へ進む。

ステップS302では、ステップS301で取得されたテナントIDをキーに、テナントテーブルT100から、ランクT103を取得する。さらに、取得されたランクとタスクを実行している仮想化管理サーバ420のIDから、前記仮想化管理サーバ420が受信可能な優先度値へランクを変換し、ステップS303へ進む。

ステップS303では、仮想化管理サーバ420のIDをキーに、仮想化管理サーバテーブルT200からIPアドレスT201を取得し、仮想化管理サーバ420へ前記変換された優先度値を送信し、タスクに対する優先度値を更新させる。

なお、優先度値をタスク管理プログラム310から直接最下層の仮想化管理サーバ420へ送信する本処理の処理コストは小さいが、タスク管理プログラム310を備えるタスク管理サーバの負荷増加が問題になる場合は、本処理のみをタスク管理プログラムから分離し、複数のサーバ上で実行する等してもよい。

以上一連の処理により、中間仮想化管理サーバ500が優先度値を受け取れない、または伝播できない場合でも、最下層の仮想化管理サーバ420で実行されるタスクに対して、テナントのランクに応じた優先度値を設定可能とする。

以上、実施例1、2を通して説明した本発明により、マルチテナントなクラウド基盤において、課金額/事業者による設定等、テナントの優先度に応じた時間でのタスク実行制御、すなわちタスクの処理に要する時間に差を設けることが可能となる。

100・・・クラウド基盤、130・・・VM、150・・・テナント、150a・・・テナント1、160・・・テナント管理者、161・・・端末、180・・・タスク、180a・・・テナント１のタスク、200・・・ポータルサーバ、300・・・タスク管理サーバ、310・・・タスク管理プログラム、320・・・タスク実行制御プログラム、350・・・実行待ちタスクキュー、350a・・・テナント1の実行待ちタスクキュー、370・・・外部記憶装置、380・・・I/Oデバイス、400・・・仮想化管理サーバ、400a・・・仮想化管理サーバ1、400b・・・仮想化管理サーバ2、410・・・実行キュー、410a・・・仮想化管理サーバ1の実行キュー、T300・・・優先度値変換テーブル

Claims (11)

1. 優先度が指定されたタスクの実行を要求する第一の計算機と、
   第一の計算機からタスクの実行要求を受付け、受付けた実行要求を指定された第一の優先度に基づいて格納する複数のタスクキューと、
   前記タスクキューの優先度に基づいて第三の計算機へタスクの実行を要求するタスク実行制御部を備える第二の計算機と、
   第二の計算機からタスクの実行要求を受付け、受付けたタスクを実行する複数の第三の計算機を備え、
   前記複数の第三の計算機は、タスクの優先度として受信可能な優先度値の指標が異なる計算機を含み、
   前記タスク実行制御部は第三の計算機で実行中のタスクと前記受け付けたタスクとについて、第一の優先度、タスクの種別情報とを基に第三の計算機で実行した時のそれぞれの平均実行時間を求め、それらを合計した実行時間が最も短い第三の計算機を前記受け付けたタスクを実行する第三の計算機として選択し、前記第一の優先度を、前記選択された第三の計算機が受信可能な第二の優先度に変換し、変換された第二の優先度で第三の計算機へタスクの実行を要求することを特徴とする計算機システム。
2. 第三の計算機は実行要求を受けたタスクを格納する実行タスクキューを備え、
   前記タスク実行制御部は前記実行時間に前記実行タスクキューに格納されたタスクの実行時間を加えた実行時間が最も短い第三の計算機を次のタスクを実行する第三の計算機として選択することを特徴とする請求項１に記載の計算機システム。
3. 前記タスク実行制御部は第三の計算機を選択するとき、タスクの実行に必要なリソースを備える第三の計算機の中から最も実行時間が短い計算機をタスクを実行する第三の計算機として選択することを特徴とする請求項１に記載の計算機システム。
4. 前記タスク実行制御部は第三の計算機を選択するとき、タスクの実行に必要なリソースを備える第三の計算機の中から予め定められた時間よりも実行時間が短い計算機の中からタスクを実行する第三の計算機として選択することを特徴とする請求項１に記載の計算機システム。
5. 前記タスク実行制御部は第三の計算機を選択するとき、タスクを実行する複数の第三の計算機を選択し、選択した複数の第三の計算機へ同一タスクの実行を要求することを特徴とする請求項１に記載の計算機システム。
6. 前記タスク実行制御部は最初に第三の計算機からタスクの実行完了を知らせる情報を得たとき、前記タスクの実行を要求した他の第三の計算機へ前記タスクの実行を中止することを要求することを特徴とする請求項５に記載の計算機システム。
7. 前記タスク実行制御部は最初に第三の計算機からタスクの実行開始を知らせる情報を得たとき、前記タスクの実行を要求した他の第三の計算機へ前記タスクの実行を中止することを要求することを特徴とする請求項５に記載の計算機システム。
8. 第一の計算機が優先度を指定されたタスクの実行を第二の計算機へ要求し、
   第二の計算機が第一の計算機からタスクの実行要求を受付け、受付けた実行要求を指定された第一の優先度に基づいて受付けたタスクをタスクキューへ格納し、第二の計算機のタスク実行制御部が前記タスクキューの優先度に基づいて複数の第三の計算機のいずれかの第三の計算機を選択してタスクの実行を要求し、
   第三の計算機が第二の計算機からタスクの実行要求を受付けたタスクを実行し、
   前記複数の第三の計算機は、タスクの優先度として受信可能な優先度値の指標が異なる計算機を含み、
   前記タスク実行制御部は第三の計算機で実行中のタスクと前記受け付けたタスクとについて、第一の優先度、タスクの種別情報とを基に第三の計算機で実行した時のそれぞれの平均実行時間を求め、それらを合計した実行時間が最も短い第三の計算機を前記受け付けたタスクを実行する第三の計算機として選択し、前記第一の優先度を、前記選択された第三の計算機が受信可能な第二の優先度に変換し、変換された第二の優先度で第三の計算機へタスクの実行を要求することを特徴とするタスク実行方法。
9. 第三の計算機は実行要求を受けたタスクを格納する実行タスクキューを備え、
   前記タスク実行制御部は前記実行時間に前記実行タスクキューに格納されたタスクの実行時間を加えた実行時間が最も短い第三の計算機を次のタスクを実行する第三の計算機として選択することを特徴とする請求項８に記載のタスク実行方法。
10. 前記タスク実行制御部は第三の計算機を選択するとき、タスクを実行する複数の第三の計算機を選択し、選択した複数の第三の計算機へ同一タスクの実行を要求することを特徴とする請求項８に記載のタスク実行方法。
11. 前記タスク実行制御部は最初に第三の計算機からタスクの実行完了を知らせる情報を得たとき、前記タスクの実行を要求した他の第三の計算機へ前記タスクの実行を中止することを要求することを特徴とする請求項１０に記載のタスク実行方法

Images