JP4066932B2

JP4066932B2 - 予測に基づいた計算機リソース配分方法

Info

Publication number: JP4066932B2
Application number: JP2003379291A
Authority: JP
Inventors: 貴志爲重; 良史高本
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-11-10
Filing date: 2003-11-10
Publication date: 2008-03-26
Anticipated expiration: 2023-11-10
Also published as: JP2005141605A; US8195800B2; US7500001B2; US20090113056A1; US20050102674A1; US20120215924A1; US8996701B2

Description

本発明は、予測技術を用いて計算機リソースを待機系から現用系へ自動的に遷移させる方法を提供する。

近年、サービスやソフトウェア、インフラストラクチャーの購入や供給および維持において、必要経費削減を目的としたアウトソーシング化が進んでいる。必要な計算機リソースを必要な時に使用し、使用量に応じて料金を支払う、「オンデマンド」型の計算機利用が提案され、従来からあるデータセンタやユーティリティセンタといった計算機センタに代表される高い計算リソースを有する計算機へのアウトソーシングが進みつつある。この動きは、グリッドコンピューティング技術のビジネス分野への適用によって、さらに加速すると考えられる。ここで問題となることは、遊休計算機リソースの維持とそれに伴うコストである。従来の計算機運用では、瞬間的に必要となる最大稼動時のスペックを見越して計算機リソースを導入していたため、普段は大量の遊休計算機リソースが存在している。この計算機リソースを維持することがコスト削減の障壁となっている。特開平９−８１４０９では、自計算機内に稼動系と待機系を持ち、障害が発生したとき自動的に対応付け可能な待機系処理機能を選択して対応付け、ホットスタンバイ関係を構築、待機系が他計算機の現用系になる方法を示している。これにより、待機系が他計算機の現用系となることができるため、待機系リソースの削減や遊休計算機リソースの削減を実現することが出来る。また、特開平１１−３２８１２９では、全てのジョブで共用となるリソースのみを接続、どの実行系ジョブにも対応できるようにする方法を示している。これにより、システム内の待機系ジョブ数を減少させ、計算機やメモリ等に関してリソースの有効活用およびシステム運用の軽減を図っている。

特開平９−８１４０９号公報

特開平１１−３２８１２９号公報

従来技術では、他サービスを同一サーバ上で運用しないため、例えばサーバ統合という形で総サーバ数を減らすことはできない。これは、サーバ以外の計算機リソースについても同様のことが言える。また、時間帯によって負荷が異なる場合、高負荷に耐えうるだけの十分な計算機リソースを用意しなければならず、計算機リソース削減が困難である。さらに、従来技術において、待機系は常に現用系と同じ設定を持つ計算機リソース群となるため、サービス毎に待機系を維持しなければならず、計算機リソースの削減が困難である。また、従来技術では現在の負荷値から現用系計算機リソースが過負荷になることの予測を行っていたため、リソース・スケジューリングの精度が低かった。その点でも、複数のサービスの間で余剰のリソースを融通し合うという構成とするのが困難であった。

そこで、本発明は複数のサービスの間で互いに余剰の計算機リソースを融通しあうことができ、もって全体の計算機リソース数を削減、余剰リソースの維持コストの低減が可能なリソース配分方法を提供することを目的とする。
また更に具体的には、リソース・スケジューリングの精度を高め、もって効率の良い配分が可能なリソース配分方法を提供することを目的とする。

上記課題を解決するため、待機系をデッドスタンバイからホットスタンバイの間で運用する。ホットスタンバイとは、現用系と同じ設定でアプリケーションが立ち上がった状態で、いつでも現用系のサービスを引き継げる状態であり、デッドスタンバイとは、少なくともアプリケーションがデプロイされておらず、アプリケーションやＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）をデプロイすることでどのようなサービスの待機系にも成り得る状態である。予測技術を用いて、待機系の状態を自動的に様々なスタンバイ状態へ遷移させることで、異なるサービスや異なる利用者間で計算機リソースを共用することが可能となり、維持しなければならない総計算機リソースを削減することができる。また、予測において、過去の履歴を参照することで、サーバを融通できるサービスを絞り込むこととした。これにより、サーバ融通決定後、融通先のサービスが上がる傾向にあるのか、または下がる傾向にあるのかの判定について精度を上げることが可能である。また、負荷が上がる時期と予想される負荷を指定することで、デプロイする時間を含めてスケジューリングすることが可能となる。また、周期性を検知することで、優先的にサーバを融通できるサーバを特定することや融通を回避すべきサーバを特定することが可能となる。予測技術を全サービスに適用することで、待機系（サーバプール）だけでなく他のサービスからもリソースを提供することが可能になるため、待機系（サーバプール）への新規リソースの追加といった初期コストの増大を抑制することが出来る。

本発明により、複数サービスや複数ユーザ間でサーバを共有することが可能となる。また、計算機リソースプールを作ったときに、計算機リソースの使用効率を向上することが出来る。予測技術を、リソースの不足するサービスだけでなく、全サービスに適用することで、単一サービスのサービスレベル維持に留まらず、全サービスのサービスレベルを図ることが出来る。予測技術により余力のあるサービスからリソースを提供するため、新規リソースの追加による初期コストの増大を抑制する効果がある。

以下、係る予測技術に基づいた計算機リソース配分方法について実施例１を図面に示し、更に詳細な説明を行う。

図１は、本発明による予測に基づいた計算機リソース配分方法により、複数のポリシサーバ（１０１、１０２、１０３）とそれぞれエージェント（１１１、１１２、１１３）を持つ複数のサーバ（１２１、１２２、１２３）がネットワーク１３１を介して接続されている様子を示している。

図２は、本発明による予測技術を用いた計算機リソース配分方法の概略構成図を示している。２０１は計算機環境を利用するユーザである。該ユーザ２０１やサーバ（２０２、２０３）のエージェント（２１１、２１２）から出されたイベント情報（該ユーザ２０１による該サーバのスケジュール、負荷予測、障害予測、メンテナンスや該エージェント（２１１、２１２）によるハードウェア情報やソフトウェア情報）をポリシサーバ２０４が受け取る。該ポリシサーバ２０４では、該サーバ（２０２、２０３）での負荷や障害を予測し、該サーバ（２０２、２０３）における現用系や待機系の状態を決定する。状態とは、現用系サーバか待機系サーバかということだけでなく、どのようなＯＳ上でどのようなアプリケーションを動作させるかということや待機系サーバのスタンバイ方法（電源、ＯＳ、アプリケーション、アプリケーション起動の有無）を指す。スタンバイには、ホットスタンバイやコールドスタンバイ、デッドスタンバイ（ホットスタンバイやコールドスタンバイ以外のスタンバイで少なくともアプリケーションがインストールされていないスタンバイ）が存在する。ホットスタンバイは、電源が入った状態で現用系と同じ設定で待機しており、アプリケーションが起動している。このため、瞬時に現用系のサービスを引き継ぐことが可能である。当然、ＯＳやアプリケーションは現用系と同じものがインストールされている。それに対し、コールドスタンバイは、電源については入っていても入っていなくてもどちらでも良い。また、アプリケーションは起動されていない。ただし、ＯＳとアプリケーションは現用系と同じものがインストールされており、各種設定もなされている。そのため、電源を入れ、ＯＳやアプリケーションを起動することで現用系のサービスを引き継ぐことが出来るが、ホットスタンバイに比べて引継ぎまでに時間を要する。その代わり、消費電力を抑えることが出来る。デッドスタンバイでは、少なくともアプリケーションはインストールされていない。そのため、現用系のサービスを引き継ぐためには、必要なＯＳやアプリケーションをインストールし実行可能な設定を施す必要がある。デッドスタンバイを用意する最大の利点は、必要なＯＳやアプリケーションをインストールし実行可能な設定を施すことで、どのようなサービスにも入れる点であり、これにより複数サービスや複数ユーザ間で計算機リソースを共有することが出来る。つまり、サーバならばサーバ統合を行うことができ、また遊休計算機を減らすことが可能になる。現用系と待機系の詳細は、図３に示す。

図３は、現用系と待機系に関する詳細を示している。現用系はアクティブと呼ばれる状態であり、カラム３０１に特徴が示されている。待機系は、カラム３０２に示されるホットスタンバイ、カラム３０３に示されるコールドスタンバイとその他の状態であるデッドスタンバイに分けることができる。カラム３０４は、デッドスタンバイの一例である。該デッドスタンバイは、少なくともアプリケーションがインストールされていない状態として特徴づけることが出来る。

図４は、現用系と待機系の遷移に関する詳細を示している。現用系４０１は、アクティブと呼ばれる稼動状態で構成されている。それに対し、待機系４０２はホットスタンバイ４０３、コールドスタンバイ４０４とその他の状態であるデッドスタンバイ４０５から構成されている。各状態は、該アクティブ、該ホットスタンバイ４０３、該コールドスタンバイ４０４、デッドスタンバイ４０５間で遷移する。該ホットスタンバイ４０３と該コールドスタンバイ４０４間も遷移する。ここで、該デッドスタンバイとなっている計算機リソースは、複数サービスまたは複数ユーザ間で共用となる。そのため、必要とするサービスまたはユーザが適宜、該アクティブ、該ホットスタンバイ４０３や該コールドスタンバイ４０４に遷移させ利用することができる。

図５は、ポリシサーバ５０１内に存在する機能の詳細を示している。予測機構５１１は、該ユーザ２０１や該エージェント（２１１、２１２）から出されたイベント情報をもとに、未来の計算機負荷や計算機障害を予測する。負荷予測の場合、解析的な数式と過去の値や現在の値から未来の値を導出する方法、負荷予測テーブルを用いて未来の値を導出する方法、いくつかのテンプレートを用意して未来の値を決定する方法が考えられる。障害予測の場合、負荷予測と同様にして障害が起こりそうな計算機リソースを抽出することができる。図７（ｂ）中のイベント内に記載された「メモリ内ビットエラー」が、障害を予測させる因子の例である。該予測機構５１１で予測された負荷や障害に関する情報がポリシエンジン５１２に送られる。送られた情報とポリシＤＢ（ＤａｔａＢａｓｅ）５１３を参照し、該ポリシエンジン５１２はリソース割付機構５１４へリソース割付要求を出す。参照される該ポリシＤＢの詳細は、図７（ａ）、（ｂ）に示されている。

図６は、該予測機構５１１の処理フローを示している。ステップ６０１でイベント情報を参照する。ここで、ユーザから明示的に予測情報を与えられた場合は、例外として該予測機構５１１での処理を終了し、該ポリシエンジン５１２へ処理を移行する。ステップ６０２で負荷に関する情報か否かを判断する。負荷に関する情報である場合、ステップ６０３で未来の負荷について予測を行う。このとき、ログとして現在や過去のハードウェア情報やソフトウェア情報を参照する場合がある。ステップ６０２で負荷に関する情報ではないと判断した場合は、ステップ６０４で障害に関する情報か否かを判断する。障害に関する情報である場合、ステップ６０５で未来の障害について予測を行う。このとき、負荷に関する予測と同様、ログとして現在や過去のハードウェア情報やソフトウェア情報を参照する場合がある。ステップ６０４で障害に関する情報でないと判断した場合、ステップ６０６でエラー出力を行う。

図７（ａ）と（ｂ）は、該ポリシＤＢ５１３に記述されているデータベースの内容を詳述している。カラム７０１、７１１には、該ユーザ２０１や該エージェント２１１から出されたイベント情報を示している。カラム７０２、７１２には、該ポリシエンジン５１２がイベントに対しアクションを起こす閾値と条件を示している。カラム７０３、７１３には、該ポリシエンジン５１２が起こすアクションの対象となるリソースとその動作を示している。カラム７０４、７１４には、カラム７０１（７１１）、７０２（７１２）、７０３（７１３）が同じ条件の場合における動作に関する優先順位を示している。このカラム７０４、７１４には、該ポリシＤＢ５１３全体に渡る優先順位を記述しても良い。カラム７０５、７１５には、図４に示される状態遷移に関する指示を示している。一つのイベントに対して、優先順位をつけた上で複数の選択肢を用意し、該ポリシエンジン５１２が選択できるようにしても良い。その場合、カラム７０４、７１４の優先順位付けされたことで関連付いているイベントについては図７（ａ）、（ｂ）に示すように対応付けをしなければならない。カラム７０６、７１６には、各イベントに対してアクションを起こすスケジュールを示している。ここには、アクションを起こす時間だけでなく「遷移確認後」、「フェイルオーバー後」といった条件文を記述することも可能である。また、カラム７０５、７１５で選択肢を用意した場合は、カラム７０６、７１６と関連するため、対応付けを行う必要がある。

図８は、該ポリシエンジン５１２の処理フローを示している。ステップ８０１で、該予測機構５１１から出力された予測情報を参照する。ステップ８０２で、該ポリシＤＢ５１３を参照し、図７（ａ）、（ｂ）に示される情報を確認する。ステップ８０３で、ステップ８０１で参照した該予測情報とステップ８０２で参照した該ポリシＤＢを比較する。ステップ８０４では、ステップ８０３で実行した比較からリソースの状態を変更する必要があるか否かを判断する。ステップ８０４で変更する必要があると判断した場合は、ステップ８０５でリソースの状態を変更するリソース割付要求を該リソース割付機構５１４へ出す。

図９は、該リソース割付機構５１４で行われるリソース割付要求について示している。カラム９０１は、リソース割付要求の優先順位を示している。カラム９０２は、リソース割付要求を出しているユーザを示している。カラム９０３は、リソース割付要求を出されているリソースの個数を示している。カラム９０４は、リソース割付要求を出されているリソースの種類を示している。カラム９０５は、リソース割付要求に伴う状態の遷移について示している。カラム９０６は、リソース割付要求が実行されてから実行に移すまでのスケジュールについて示している。カラム９０６には、アクションを起こす時間だけでなく「遷移確認後」、「フェイルオーバー後」といった条件文が記述されていることもある。

図１０は、該リソース割付機構５１４で行われる配分リソース決定について示している。図９に示された各カラム（９０１、９０２、９０３、９０４、９０５、９０６）に加えて、カラム１００４とカラム１００５が関連付けられる。カラム１００４は、インストールおよび実行に必要な設定が必要なＯＳやアプリケーションを示している。カラム１００５は、どのポートを利用するかを示している。該リソース割付機構５１４は、図９に示されるリソース割付要求を、図１１に詳述されている該リソース管理テーブル５１５を参照した上で、図１０に示す配分リソース決定へと変換する役割を担う。

図１１は、該リソース管理テーブル５１５に記述されている内容を示している。カラム１１０１は、リソースの種類を示している。カラム１１０２は、リソースを使用しているユーザを示している。ここで、１つのリソースを使用しているユーザは複数でも良い。カラム１１０３は、各リソースに付随する付加情報を示している。また、各リソースの性能情報を記述することもできる。サーバの場合は、インストールされているＯＳやアプリケーションとそれぞれに付随するバージョン情報を示している。また、ネットワークの場合は、ケーブルの種類や転送率を記述する。ストレージの場合は、用途を記述する。カラム１１０４は、各リソースが使用しているポート番号を示している。例えば、ハブやスイッチ、負荷分散装置のポートが対象になる。カラム１１０５は、各リソースの状態を示している。ここには、アクティブ、ホットスタンバイ、コールドスタンバイやデッドスタンバイといった現用系か待機系かということが記述される。カラム１１０６は、各リソースに関する予約情報を示している。時間を指定してメンテナンスしたい場合、このカラム１１０６に記述することになる。また、時間を指定して状態を遷移させたい場合にも、このカラム１１０６に記述する。

図１２は、該リソース割付機構５１４の処理フローを示している。ステップ１２０１で該ポリシエンジン５１２から出されたリソース割付要求を参照する。ステップ１２０２で該リソース管理テーブル５１５を参照し、ステップ１２０１で参照したリソース割付要求と比較する。ステップ１２０３でリソース割付が可能か否かを判断する。可能な場合、ステップ１２０４で該リソース管理テーブル５１５を参照する。ステップ１２０５で、割り付けるリソースを決定し、図１０に示したように配分リソース決定を行い、該リソース管理テーブル５１５のうち図１１のカラム１１０５に示される「状態」を「更新中」へ一時変更する。ステップ１２０３でリソース割付が不可能であると判断した場合、ステップ１２０６で余剰リソース化できるリソースがあるか判断する。余剰リソース化できない場合は、ステップ１２０７でエラー出力し終了する。余剰リソース化が可能な場合、ステップ１２０８で余剰化したリソースについて該リソース管理テーブル５１５のうち図１１のカラム１１０５に示される「状態」を「更新中」へ一時変更する。ステップ１２０９で割り付けるリソースにＯＳやアプリケーションのインストールや実行に必要な設定が必要か否かを判断する。必要な場合、ステップ１２１０で各リソースの該エージェント（２１１、２１２）にＯＳやアプリケーションのインストールや実行に必要な設定を要求する。全ての作業が完了した時点で、ステップ１２１１において、該リソース管理テーブル５１５を更新する。

図１３は、各サーバ（２０３，２０４）内に存在する機構の詳細を示している。エージェント１３１１は、計算機リソースに関するハードウェア情報やソフトウェア情報を収集し、該ポリシサーバ２０２へ送る役割を担っている。このとき、サーバ１３０１上からユーザ１３１２が該サーバ１３０１のスケジュール、負荷予測、障害予測、メンテナンス情報を入力し、該ポリシサーバ２０２へ転送する。

図１４は、該エージェント１３１１（２１１、２１２）の処理フローを示している。ステップ１４０１で、該リソース割付機構５１４から出された配分リソース決定（図１０）の内容を参照する。ステップ１４０２で電源を入れる必要があるか否かを判断する。必要な場合、ステップ１４０３で電源を入れる。ステップ１４０４で、ＯＳやアプリケーションのインストールや実行に必要な設定が必要か否かを判断する。必要と判断した場合、ステップ１４０５でＯＳやアプリケーションのインストールや実行に必要な設定を実行する。

本発明による運用方法は、ハードウェアのアーキテクチャに依存するものではない。また、ＯＳについても同様に依存するものではない。
[実施例２]
以下、係る予測技術に基づいた計算機リソース配分方法について実施例２を図面に示し、更に詳細な説明を行う。実施例２では、実施例１に記載した仕組みを使用し、特に、図６に示す予測機構の負荷に関する予測部分について詳述するものである。

図１５は、本発明による予測に基づいた計算機リソース配分方法により、複数のクライアント（１５０１、１５０２、１５０３）とそれぞれエージェント（１５１１、１５１２、１５１３）を持つ複数のサーバ（１５２１、１５２２、１５２３）が負荷分散装置１５４２とネットワークを介して接続されている様子を示している。該負荷分散装置１５４２にはポリシサーバ１５４１が接続されている。

図１６は、図１５に示した該負荷分散装置１５４２ではなく一つまたは、複数のクラスタリングソフト１６４３によって、サーバ（１６２１、１６２２、１６２３）がクラスタ化されている様子を示している。このように、負荷を分散する仕組みは、様々な形態が考えられる。ここで、重要なことは、該クライアント（１５０１、１５０２、１５０３、１６０１、１６０２、１６０３）からの処理要求に対して、サーバやストレージといった計算機リソースをサーバ単位またはＣＰＵ単位、メモリ単位で増やし、処理要求に対応できる仕組みが存在していることである。増設できる単位は、サーバやＣＰＵ、メモリの少数倍でも良い。従って、各計算機が物理計算機でも論理計算機でも良い。ＷｅｂサーバやＡＰサーバの場合、サーバ単位で追加していくことで要求される処理量の増加に対応できる。ＤＢサーバの場合、ＣＰＵやメモリを増設することで要求される処理量の増加に対応できる。

図１７は、図１５と図１６で示したシステムの物理構成に対し、論理的にサーバを構成した様子を示している。具体的には、各サーバ（１７３２〜１７３９）がサービス毎（１７２１、１７２２、１７２３、１７２４）に割り付けられている。ここで、サービス“Ａ”１７２１、サービス“Ｂ”１７２１、サービス“×”１７２３では、各サーバの状態は現用系であるアクティブ、または待機系であるホットスタンバイまたはコールドスタンバイである。また、待機系（サーバプール）１７２４では、各サーバの状態は待機系であるホットスタンバイ、コールドスタンバイ、またはデッドスタンバイである。ここで、予測対象となるサービスやサーバは、現用系なのか待機系なのかは問わずに実行される。しかし、待機系では業務に関する処理を行っていないため、予測を行うためのデータが採取できない場合が多い。よって、負荷予測については主に現用系が予測の対象となる。ただし、障害予測の場合は、待機系についてもデータ採取する必要がある。サーバの融通に関する優先順位は、基本的には待機系のサーバの方が現用系のサーバよりも高い。どのサーバが、どのサービスに属するかを管理している箇所は、負荷分散装置（または管理サーバ）１７１１であり、決定を行う箇所は、ポリシサーバ１７１２である。サービス間でサーバを融通する場合、必ず該待機系（サーバプール）１７２４に一度プールされる。該待機系（サーバプール）１７２４にプールされた状態のサーバに対し、必要なＯＳやアプリケーションをインストールし各種設定を行う。こうすることで、サービス間のセキュリティが維持されるだけでなく、該待機系（サーバプール）１７２４にあるサーバに関してはハードウェア使用量、ソフトウェア使用量にカウントしないというオンデマンドなリソース使用を可能にするビジネスモデルを提供することができる。ハードウェア使用量に関しては、ＣＰＵ利用率に基づくビジネスモデルが多いが、どのサービスでどれくらい使用したかを記録する本特許提案方法だからこそ複数のサービスまたは利用者に対して、柔軟なオンデマンド形態を提供することができる。また、本方式によってソフトウェア・ライセンスについてオンデマンドな提供方式が具体的に示されている。クライアント（１７０１、１７０２、１７０３）から出されたリクエストは、該負荷分散装置（または管理サーバ）１７１１で受け付けられ、各サービスへ振り分けられる。このとき、該クライアント（１７０１、１７０２、１７０３）からは、各サービスにそれぞれどれだけのサーバが存在するかは明らかでない。また、該負荷分散装置（または管理サーバ）１７１１が複数存在しても良い。

図１８は、該予測機構５１１の入力を行うＧＵＩを用いた登録画面の詳細を示している。該当録画面１８０１は、制御対象を入力する部分１８０２、イベント日時の開始を入力する部分１８０３、終了を入力する部分１８０４、予想される負荷を入力する部分１８０５、イベント内容を入力する部分１８０６から構成される。各項目は、管理者によって入力される。該制御対象を入力する部分１８０２では、負荷の変化が予想されるサービスを指定する。該イベント日時の開始を入力する部分１８０３では、負荷の変化が予想される日時を指定し、負荷の変化が開始する日時を指定する。また、該終了を入力する部分１８０４では、負荷の変化が終了する日時を指定する。ここで、日時の指定に関する部分は、分や秒などの詳細な設定をしても良い。より詳細な設定をすることで、利用者の要求に対して細やかな対応が可能である。また、リソースを融通可能なサービスを予測によって選択する際に、より目的にあった融通対象を選ぶことが可能になる。該予想される負荷を入力する部分１８０５では、過去の運用履歴に比べて、何倍の負荷が想定されるかを入力する部分である。該予想される負荷を入力する部分１８０５に入力する値によって、融通するリソースの量が決定される。例えば、８倍の負荷が予想される場合は、過去の履歴から平均値を用いて算出する通常負荷の８倍のリソースが必要であると判断し、８倍のリソースを融通するように要求する。ＷｅｂサーバやＡＰサーバの場合、８倍のサーバ台数を融通するように要求を出す。該イベント内容を入力する部分１８０６では、負荷変化の要因を入力する。この情報は、管理者の備忘録として機能するだけでなく、本情報によってソートすることで過去の動作実績を参考に管理者が入力を行うといった簡便性を提供するものである。入力する各項目について、既定値を設ける場合もある。これにより、管理者の手間を削減することが可能である。また、過去に入力した情報を履歴として残すことで、過去の動作実績を参照したり、リソースの補強が必要なサービスを特定することが容易になる。また、この情報を該ポリシエンジン５１２で解析することで、更に高度な自律制御を行うことができ、管理者の手間を削減することができる。

図１９は、図５に示す該ポリシサーバ５０１における処理過程を示している。詳細な処理機構については、図２１にて詳述する。ステップ１９０１で、該登録画面１８０１にて入力された設定日時におけるサービス毎のサービスレベル履歴を参照する。このとき、サービスレベルとは、レスポンス時間や要求処理数といった利用者の要求（需要）に関して満足しなければならないパラメータを指す場合と、ＣＰＵ利用率やサーバ数といった供給に関して満足しなければならないパラメータを指す場合がある。両者が混在する場合もあり、これはサービス提供者とサービス利用者が結ぶサービスレ・レベル・アグリーメント（ＳＬＡ）と呼ばれる契約によって規定されるものである。また、複数のサービスレベルが存在することが一般的である。該予測機構５１１で自律的に運用を行うためには、サービスレベルの優先順位を規定し、該ポリシＤＢ５１３に持っておくべきである。ここで、“サービス利用者とサービス提供者”は、“コンテンツ利用者とコンテンツ提供者”や“計算機リソース利用者と計算機リソース提供者”などが考えられ、一般的にコンテンツ提供者と計算機リソース利用者は同一である。ステップ１９０２で、サーバなどの計算機リソースを融通、つまりあるサービスで利用するリソースが減った場合に、サービスレベルを維持できるサービスを全てリストアップする。ステップ１９０３で、該ステップ１９０２でリストアップしたサービスから該制御対象を入力する部分１８０２で指定されたサービスが必要とするリソース分を融通してもらうサービスとサーバを決定する。ここで、該ポリシＤＢ５１３または該当録画面１８０１にて、予め優先順位を設定または管理者が指定しても良い。指定がない場合や優先順位が同じ場合は、参照した順序にてサービスとサーバを決定する。ステップ１９０４で、融通することを決定したサーバを待機系（サーバプール）へプールし、必要なＯＳやアプリケーションをインストールし各種設定を実行する。ステップ１９０５で、該ステップ１９０４で各種設定が終了したサーバを制御対象サービスへ追加し、業務を開始する。ステップ１９０５で、該当録画面１８０１で指定されたイベント終了後、制御対象から待機系（サーバプール）へ再びプールし、元々のサービスで使用していたＯＳやアプリケーションを必要に応じてインストールし各種設定を実行する。ここで、融通されたサーバが元々どのサービスで使用されていたか、元々のサービスで使用していたＯＳやアプリケーション、各種設定は該ポリシサーバ５０１が参照可能な場所に格納されているものとする。これにより、融通前後で融通したサービスのサービスレベルが損なわれることがなくなる。また、これらの情報は、次に設定されているイベントがあれば、元のサービスへサーバを戻すことなく優先的に使用するといった使い方により、インストールや設定にかかる時間を削減できる。この優先順位変更は、該ポリシＤＢ５１３を更新することによって、反映することができる。ステップ１９０７で、元々のサービスへサーバを戻す。ここで、サーバの融通に関するサーバ・スケジューリングには、該リソース管理テーブル５１５に記載された情報を利用する場合がある。これにより、複数の制御対象におけるイベントが時間的に重なって発生した場合も、一度、サービスに戻すことなくサーバを融通することが可能になるため、無駄なインストールや設定に時間を浪費することがなくなる。

図２０は、図１９で示した該ポリシサーバ５０１における処理過程を図解したものである。特に、プロビジョニングと呼ばれるサービス間のサーバ移動（論理的なサーバの移動）を詳解している。図２０（ａ）は、図１９の該ステップ１９０１、１９０２、１９０３で示された順序で各サービスから融通可能なサーバ候補に関する情報を得た段階を示している。図２０（ｂ）は、該ステップ１９０４で示されるように融通されることが決定したサーバを待機系（サーバプール）２０２５へプールされる様子を示している。このとき、一度に該待機系（サーバプール）へサーバをプールしても良いが、時間的にずらしてプールすることで稼動状態のサーバの全体数を段階的に増減することができる。これにより、突発的な負荷が融通元のサービスで発生しても融通するサーバ数の調整を行うことができる。また、稼動状態のサーバ数全体を徐々に減らすことで、データセンタといったサービス提供者がシステム全体の安定を図ることを可能とする。そのためにも、サービス毎やサーバ毎に現在の負荷をサンプリングする機構が大切である。サーバといったリソースの融通は、インストールや各種設定にかかる時間が支配的なため、数十分から数時間といったオーダになる。サンプリング間隔は、それよりも短いオーダになることが一般的であり、数秒から数分となる。図２０（ｃ）は、該ステップ１９０５で示されるように待機系（サーバプール）２０４５にて必要なＯＳやアプリケーションをインストールし各種設定を終えたサーバ（２０５９、２０６０、２０６１）が制御対象サービスであるサービス“Ａ”２０４１へ追加される様子を示している。図２０（ｄ）は、該ステップ１９０６で示される通り、イベントが終了した後、融通元サービスへサーバを戻す際に、制御対象サービスであるサービス“Ａ”２０７１から待機系（サーバプール）２０７５へサーバをプールし、元々のＯＳやアプリケーションをインストールし各種設定を行う様子を示している。この際も、該図２０（ｂ）の詳述にある通り、サーバを一度に減らしても良いが、時間的に徐々に減らすようにスケジューリングすることで、イベント終了後も高負荷が続いた場合にも対処することが可能となる。サービスやサーバ毎のサンプリング間隔は、同様にインストールや各種設定（数十分から数時間）に必要な時間よりも短いこと（数秒から数分）が望ましい。図２０（ｅ）は、該ステップ１９０７で示される、元々のサービスへサーバを戻す様子を示している。上述したインストールや各種設定に必要な時間は、新規にインストールと設定を行う場合を想定している。しかし、場合によっては、ＯＳとアプリケーションまたはアプリケーションのみをインストールし設定を行う場合もある。この制御は、該ポリシエンジン５１２が行う。このとき、サーバに業務を開始させるまでの時間は短くなる。そのため、サンプリング時間はより短く設定しておく必要がある。

図２１は、図１９で示した負荷予測とプロビジョニングに関する各ステップについて、処理フローを示したものである。ステップ２１０１で、該登録画面１７０１にて指定した時間における各サービスの過去履歴を参照する。このとき、指定時間内の時間平均を使うが、より精度の高い予測を行うために、指定時間間隔よりも短いサンプリング時間またはその倍数（整数倍、少数倍を含む）を用いて予測を行っても良い。ステップ２１０２で、該ステップ２１０１で算出した平均サービスレベルと要求サービスレベルとの差分を算出する。今後、評価する対象は差分となるが、優先順位が指定されている場合は、差分と優先順位の積やモデル式などを用いて評価する。ここで、要求サービスレベルが異なる場合を想定しているため、差分を評価することにしているが、要求サービスレベルが同一の場合、平均サービスレベルを直接評価することもある。どのパラメータを、どのように評価するかを該ポリシエンジン５１２に組み込むか、該ポリシＤＢ５１３または利用者から指定できるように実装しておく必要がある。また、負荷の周期性を検知し、優先順位に組み込む仕組みによって、予測の精度を高めることが可能である。予測の精度を高めることで、融通元となるサービスを絞りやすくすることが可能である。また、誤判定を防ぐ効果もある。周期性を検知する仕組みとしては、予め分かっている高負荷または低負荷の情報（昼間、週末、月末など）を登録する方法や、数学的なモデルに基づいて、ある程度のバラツキを許しつつ傾向から算出する方法が考えられる。このような実装により、利用者やサービス毎の柔軟な制御が可能となるだけでなく、誤判定を防ぎ、管理者に対し選択の幅を広げるメリットがある。スステップ２１０３で、該ステップ２１０３で算出した差分を基に、差分値が低い順番にソートする。ステップ２１０４で、該ステップ２１０３でソートしたサービスを順番にサーバが１台減ったときの予測サービスレベルを算出する。ステップ２１０５で、予測したサービスレベルと現在のサービスレベルを置換し保存する。ステップ２１０６で、予測サービスレベルが要求サービスレベルを満たすか否かを判定する。満たしていなければ、ステップ２１０４へ戻り、次のサービスについて予測サービスレベルを算出する。満たしている場合は、ステップ２１０７へ進む。ステップ２１０７で、制御指定サービスにサーバを１台増やしたときの予測サービスレベルを算出する。ステップ２１０８で、該ステップ２１０７で算出した予測サービスレベルが要求サービスレベルを満たしているか否かを判定する。この場合の要求サービスレベルとは、該登録画面１７０１で入力した該予想される負荷１７０５に指定されたサービスレベルを指す。該ポリシＤＢ５１３にモデル式を組み込み、該ポリシエンジン５１２で、モデル式によって変換されたサービスレベルを要求サービスレベルとする場合もある。これにより、管理者が経験的に行っていた作業を自律的に行うことが可能となる。要求を満たす場合は終了へ進む。要求を満たさない場合は、ステップ２１０９へ進む。ステップ２１０９で、次のソート順番に位置するサービスのサービスレベルが要求サービスレベルを満たすか否かを判断する。要求サービスレベルを満たせない場合は、その旨をフラグとして立てるなどの印を残し、終了へ進む。要求サービスレベルを満たす場合は、該ステップ２１０４へ戻る。該ステップ２１０９によって、要求サービスレベルを満たせるだけサーバが融通できない状況において、該ステップ２１０４から該ステップ２１０６のループが無限化することを防いでいる。全ステップが終了した後、システムはプロビジョニングへ進む。その際、管理者に最終決定をさせても良い。このように対話的にシステムを運用することで、予測の精度が低い場合にも管理者の能力や経験則で補うことができるため、非常に運用効率の良いシステムを提供することが可能である。また、予測の精度が高い場合であっても、管理者に最終判断を委ねることで、柔軟な対応が可能となる。この場合においても、本特許が提供する方式は、管理者の手間を大きく削減し、またビジネス機会の損失を防ぐものであり、その効果や位置づけが変わるものではない。

図２２は、本特許に示す運用方式を用いて、実際に運用を行った場合の結果を示している。図２２（ａ）は、サービスレベル２２０５の時間変化２２０６を示している。該登録画面１７０１にて入力した情報を反映させ、サービス名（２２０７、２２０８、２２０９、２２１０）、指定時間２２１２、要求サービスレベル２２１２、日付（２２０２、２２０３、２２０４）を表示している。また、過去の履歴（２２１３、２２１４、２２１５、２２１６）を表示している。ここに、該登録画面１７０１で指定した、該予想される負荷１７０５で示した値、または該ポリシＤＢ５１３やポリシエンジン５１２で加工した値を反映させ、予想サービスレベル２２１７として表示する。図２２（ｂ）で、各サービス（２２２１、２２２２、２２２３）におけるサービスレベルのサンプリング結果を表示する。画面構成としては、日付（２２２４、２２２５、２２２６）、サービスレベル２２２７、時間２２２８、指定時間２２２９、現状のサービスレベルと履歴２２３０、要求されるサービスレベル２２３１が存在する。該サービス（２２２１、２２２２、２２２３）毎にタブで切り替えることが可能であると、管理者の管理が容易になる。図２２（ｃ）で、サービスレベルのサンプリング結果を表示する。この場合、サービスレベルとしてサーバ台数を想定している。画面構成としては、日付（２２４２、２２４３、２２４４）、サービス名（２２４７、２２４８、２２４９）、サービスレベル２２４５（サーバ台数）、時間２２４６、指定時間２２５１、サービスレベルの時間変化に関する履歴（２２５２、２２５３、２２５４）である。該図２２（ａ）は過去履歴を、該図２２（ｂ）と該図２２（ｃ）は現在のサンプリング結果と融通した結果を併記している。該図２２（ｃ）によると、該サービス“Ｂ”２２４８と該サービス“Ｘ”２２５０がサーバの融通元となり、該サービス“Ａ”へサーバを融通している。その結果、該２２（ｂ）に示される通り、該サービスレベル２２３０は、該要求サービスレベル２２３１を上回ることなく、運用が行われる。このとき、他のサービスにおいてもサービスレベルは要求サービスレベルを満たしていたことを追記する。

図２３は、予測の手法について詳細を示している。第一の手法は、レスポンス時間２３０１とサーバ台数から必要なサーバ台数を算出する方法であり、図２３（ａ）に詳解される該レスポンス時間２３０１とサーバ利用率２３０２の関係２３０３を使用する。このとき参照するパラメータは、該レスポンス時間２３０１とサーバ台数である。現在割り当てられているサーバ台数から、算出した必要なサーバ台数を引くことで、融通可能なサーバ台数を算出する。このとき、与える該レスポンス時間２３０１がサービスレベル２３０６を越えないようにすることで、該サービスレベル２３０６を維持しつつ融通可能なサーバ台数を求めることが出来る。第一の手法に使用する定式を[数１]に示す。

ここで、f(g,n)は必要サーバ台数、g(t,t_min,α,β)はサーバ利用率２３０２、nは過去の履歴または現在のサーバ台数、tは該レスポンス時間２３０１、t_minは最低レスポンス時間２３０４、αは時間の次元を持つ定数、βは無次元の定数である。一般的に、α,βはサービス毎に異なる値を持つ。また、負荷の大きさによって異なる値を持つ場合もあるため、そのときα,βは負荷やハードウェアやＯＳ、アプリケーションに関するパラメータを持つ変数となる。第二の手法は、サーバ利用率２３１１から図２３（ｂ）に詳解される関係２３１３を用いて、レスポンス時間２３１２を算出するものである。ここで、サービスレベル２３１６を超えないようなサーバ利用率を設定することが重要となる。このとき参照するパラメータは、該サーバ利用率２３１１（各サービスまたはサーバのＣＰＵ利用率を使う場合もある）とサーバ台数である。サーバ台数が減るとき、減少した比率に反比例して該サーバ利用率２３１１は増加する。図２３（ｂ）の関係２３１３から、該サーバ利用率２３１１の増加によって、該レスポンス時間２３１２が該サービスレベル２３１６を超えないようにしなければならない。ここで、図２３（ｂ）の関係２３１３は、一般的に知られている待ち行列を使用する場合もある。第二の手法に使用する定式を[数２]に示す。

ここで、t (g,t_min,α,β)は該レスポンス時間２３１２、gは該サーバ利用率２３１１、nは過去の履歴または現在のサーバ台数、mは融通したいサーバ台数、t_minは最低レスポンス時間２３１４、αは時間の次元を持つ定数、βは無次元の定数である。一般的に、α,βはサービス毎に異なる値を持つ。また、負荷の大きさによって異なる値を持つ場合もあるため、そのときα,βは負荷やハードウェアやＯＳ、アプリケーションに関するパラメータを持つ変数となる。

実施例２では、主として負荷予測について詳述したが、障害予測に関しても同様の手法で精度を上げ、管理者の手間を削減することや計算機の自律運用による計算機リソースの使用効率向上を実現することが出来る。また、本発明による運用方法は、ハードウェアのアーキテクチャに依存するものではない。また、ＯＳについても同様に依存するものではない。

本特許を通して、予測技術を用いたリソース配分方法について述べてきたが、リソースを欲しているサービスについてのみに予測技術を適用するのではなく、リソースを提供するサービスを含む全サービスに適用することが非常に重要である。これにより、リソース要求を出しているサービスだけでなく、全サービスにおいてサービスレベルを維持することが可能である。また、予測技術によって余力のあるサービスからリソースを提供することで、新規にリソースを追加することなくサービスレベルを維持することができ、リソース追加による初期コストの増大を抑える効果がある。リソースを融通する際の優先順位については、待機系を優先して融通するべきである。ただし、予測技術は現用系、待機系を問わずに適用する。負荷予測の場合は、現用系のみに対して情報収集をすれば良いが、障害予測の場合には、現用系と待機系の両方から情報を収集すべきである。これは、予測が動作実績に基づくということに起因する。障害予測の場合、ハードウェアやソフトウェアから得られる情報によって、待機系についても障害を予測する必要がある。

本発明はデータセンタもしくはユーティリティセンタ等の計算機リソース提供施設のシステム運用に利用される可能性が高く、その分野で技術貢献することが見込まれる。

プログラムの遠隔実行方法の概略を示すブロック図である。本発明の実施例１の全体構成を示すブロック図である。実施例１の現用系と待機系に関する詳細を示す表である。実施例１の現用系と待機系の遷移の詳細を示す概念図である。実施例１のポリシサーバ内に存在する機能の詳細を示す機能ブロック図である。実施例１の予測機構の処理フローを示すフローチャートである。実施例１のポリシＤＢに記述されているデータベースの内容を示す表である。実施例１のポリシＤＢに記述されているデータベースの内容を示す表である。ポリシエンジンの処理フローを示すフローチャートである。リソース割付機構で行われるリソース割付要求を示す表である。リソース割付機構で行われる配分リソース決定を示す表である。リソース管理テーブルに記述されている内容を示す表である。リソース割付機構の処理フローを示すフローチャートである。各サーバ内に存在する機構の詳細を示す機能ブロック図である。エージェントの処理フローを示すフローチャートである。本発明の実施例２の全体構成図を示すブロック図である。本発明の実施例２の変形例の全体構成図示すブロック図である。本発明の実施例２の論理構成を示すブロック図である。ＧＵＩを用いた登録画面を示す図である。負荷予測とプロビジョニングに関する処理フローを示すフローチャートである。負荷予測後の融通するサーバを抽出した状態を示す概念図である。融通するサーバを待機系（サーバプール）へプールする状態を示す概念図である。融通するサーバに必要なＯＳやアプリケーションをインストールし各種設定を終えた後、待機系（サーバプール）から制御指定サービスへサーバを融通する状態を示す概念図である。融通したサーバを待機系（サーバプール）へプールする状態を示す概念図である。融通したサーバを元々のサービスへ戻す状態を示す概念図である。負荷予測に関する処理フローを示すフローチャートである。サービスレベルの過去履歴を表示するＧＵＩ画面を示す図である。本特許を適用した場合におけるサービスレベルの時間変化を表示するＧＵＩ画面を示す図である。本特許を適用した場合におけるサーバ台数の時間変化を表示するＧＵＩ画面を示す図である。第一の予測手法に用いるレスポンス時間とサーバ利用率の関係を示す特性図である。第二の予測手法に用いるサーバ利用率とレスポンス時間の関係を示す特性図である。

符号の説明

２０１はユーザ、２０２はポリシサーバ、２０３から２０４はサーバ、２１１から２１２はエージェントを示している。

Claims

単一または複数のポリシサーバに複数の計算機リソースが接続された計算機システムにおいて、複数のサービスに対してそれぞれ計算機リソースを割り当ててそれぞれの現用系計算機リソースとして動作させ、残りの計算機リソースのうちの第１群は前記複数のサービスのそれぞれの実行に備えてそれぞれのアプリケーションをインストールした第１の待機系状態で待機させ、前記残りの計算機リソースのうちの第２群は前記サービスの実行のためのアプリケーションがインストールされない第２の待機状態で待機させ、
あるサービスに割り当てられた計算機リソースについて運用に障害を及ぼすと前記ポオリシサーバにより判断されるハードウェア情報、またはソフトウェア情報を得たとき、該サービスの実行に備えた第一の待機状態の計算機リソースを現用系に遷移させるか、もしくは前記第二の待機状態の計算機リソースを該サービスの実行に備えた第一の待機状態へ遷移させる
ことを特徴とする計算機リソース配分方法。
単一または複数のポリシサーバに複数の計算機リソースが接続された計算機システムにおいて、複数のサービスに対してそれぞれ計算機リソースを割り当ててそれぞれの現用系計算機リソースとして動作させ、残りの計算機リソースのうちの第１群は前記複数のサービスのそれぞれの実行に備えてそれぞれのアプリケーションをインストールした第１の待機系状態で待機させ、前記残りの計算機リソースのうちの第２群は前記サービスの実行のためのアプリケーションがインストールされない第２の待機状態で待機させ、
あるサービスの実行に備えた第一の待機状態の計算機リソースを現用系へ遷移させたとき、前記第二の待機状態にある一または複数の計算機を該サービスの実行に備えた第一の待機状態へ遷移させ、逆に、あるサービスに割り当てられた現用系計算機リソースを前記第一の待機状態に遷移させたとき、該サービスの実行に備えた第一の待機状態にある単一または複数の計算機を該第二の待機状態へ遷移させる
ことを特徴とする計算機リソース配分方法。
単一または複数のポリシサーバに複数の計算機リソースが接続された計算機システムにおいて、複数のサービスに対してそれぞれ計算機リソースを割り当ててそれぞれの現用系計算機リソースとして動作させ、残りの計算機リソースのうちの第１群は前記複数のサービスのそれぞれの実行に備えてそれぞれのアプリケーションをインストールした第１の待機系状態で待機させ、前記残りの計算機リソースのうちの第２群は前記サービスの実行のためのアプリケーションがインストールされない第２の待機状態で待機させ、
前記ポリシサーバが、あるサービスについての過去の履歴と外部からの入力によって将来の負荷や障害を予測し、またあるサービスを行っている計算機についても同様の予測を行い、前記予測にしたがって現用系または前記第一の待機状態にある計算機リソースを前記第二の待機状態に遷移させ、もしくは更に前記第二の待機状態にある計算機リソースを現用系または該第一の待機状態へ遷移させる
ことを特徴とするリソース配分方法。
単一または複数のポリシサーバに複数の計算機リソースが接続された計算機システムにおいて、複数のサービスに対してそれぞれ計算機リソースを割り当ててそれぞれの現用系計算機リソースとして動作させ、残りの計算機リソースのうちの第１群は前記複数のサービスのそれぞれの実行に備えてそれぞれのアプリケーションをインストールした第１の待機系状態で待機させ、前記残りの計算機リソースのうちの第２群は前記サービスの実行のためのアプリケーションがインストールされない第２の待機状態で待機させ、
前記ポリシサーバは、イベント情報と過去の履歴を参照して予測情報を算出する予測機構と、前記イベント情報と、前記現用系リソース、第１の待機系状態及び第２の待機状態間の状態遷移と、前記イベントに対してアクションを起こすスケジュールとを対応付けて記憶するポリシＤＢを有し、前記現用系計算機リソースからイベント情報を取得した場合、前記予測機構で算出された予測情報と前記ポリシＤＢに基づき、状態遷移を実行する制御命令を前記計算機リソースに送信する
ことを特徴とするリソース配分方法。
請求項４に記載のリソース配分方法であって、
前記ポリシサーバは、状態遷移を段階的に行うよう制御する制御命令を前記計算機リソースに送信することを特徴とするリソース配分方法。