JP2005196601A - 自律管理システム向けポリシシミュレータ - Google Patents

Abstract

【課題】ポリシ制御による自律管理システムにおいて、ポリシ作成時に低コスト、迅速にポリシの妥当性を検証する。
【解決手段】自律管理システムの挙動を分析するシミュレータにおいて、システム構成、負荷分散設定、システムの負荷条件、ソフトウェアの性能情報、ソフトウェアの過渡的な挙動、及び検証対象の自律管理ポリシを入力とし、ある時刻のシステムの過渡現象を考慮した挙動（リソース使用量、応答時間、処理量）を計算し、該挙動に自律管理ポリシを適用し、次時刻のシステム構成、負荷分散設定を判断し、変更されたシステム構成、負荷分散設定を使用して次時刻のシミュレーションを行なう。
【選択図】図１

Description

本発明は計算機群を自律的に管理するシステム、特に、自律管理ポリシのシミュレーション手段に関する。

データセンタ、企業情報システムにおいては、システムの巨大化、複雑化にともなう、運用管理負荷の増大が大きな課題となっている。システム管理者の負荷を減らすことが、これからのＩＴシステムでは必須の機能となってきている。上記の課題を解決するために、自律管理システムが提案されている。自律管理システムはデータセンタ、企業情報システムのサーバ群を、負荷状態等に応じて、自動的に管理することにより、上記の課題を解決するシステムである。
特開２００２−０２４１９２号公報には、３層データセンタのサーバを負荷に応じて割当てる自律管理技術が開示されている。同技術によれば、複数の顧客企業をサポートする、３階層（Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバ）Ｗｅｂシステムにおいて、各顧客企業の処理に使われるサーバの他に、顧客企業間で共有予備サーバを置き、予備サーバを負荷に応じて各顧客企業に割当てる。それにより、急激なアクセス集中が起こったときにも、サービスレベルを維持することを可能にする。上記を実現するために、システム内に管理サーバを置き、システム内の各サーバの稼動状況を監視するとともに、あらかじめ決められた自律管理ポリシに従い、負荷に応じたサーバ割当・削減を実現する。

自律管理ポリシとは、予備サーバから現用サーバへ変更（サーバ割当）する条件、現用サーバから予備サーへ変更（サーバ削減）するの条件の記述である。上記従来例では、各サーバの稼働率を監視し、あらかじめ定めたスレッショルドと比較することにより、サーバ割当・削減を行なう。具体的には、サーバの稼働率がスレッショルドを上回ると、過負荷になっていると判定し、新規サーバを割当てる。サーバの稼働率がスレッショルドを下回ると、サーバ数が過剰であると判断し、割当てられているサーバの一部を削減する。サーバを割当てた場合には、前段の負荷分散装置やサーバの負荷分散プログラムの設定を変更し、割当てられたサーバを含む全てのサーバに均等に負荷が課せられるようにする。同じく、サーバが削減された場合にも、前段の負荷分散装置やサーバの負荷分散プログラムの設定を変更し、残った全てのサーバに均等に負荷が課せられるようにする。３階層Ｗｅｂシステムでは、上記の処理を、Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバの全てのレイヤーで行なう必要がある。

さらに、電子情報通信学会論文誌ＶＯＬ．Ｊ８０−Ｄ−Ｉ ＮＯ．９ ｐｐ８６６−８７６「Ｗｅｂアクセス負荷に対応したサーバ自動割当制御」には、自律管理ポリシの詳細が述べられている。自律管理ポリシは、単なるスレッショルドに基づくサーバ割当・削減だけでは不十分であり、
・スレッショルドの条件を満たした場合、その持続時間
・割当てるべきサーバが、前回予備になってからの経過時間
・他層のサーバの割当タイミング
等、複雑な条件を総合的に考慮したポリシの作成が必要になる。

特開２００２−０２４１９２号公報

電子情報通信学会論文誌ＶＯＬ．Ｊ８０−Ｄ−Ｉ ＮＯ．９ ｐｐ８６６−８７６「Ｗｅｂアクセス負荷に対応したサーバ自動割当制御」

上記従来技術を用いて、システムの自律管理を行なおうとした場合、自律管理のポリシの検証が困難であるという問題がある。
データセンタ、企業情報システムにおいて、システムの構成、動作させるプログラム、システムの負荷となる入力の量（時間変化）、さらには必要とされるサービスレベル（応答時間等）は、システムに応じて異なる。従って、自律管理のポリシはシステム毎に作成されなければならない。

例えば、上記第一の公知例におけるスレッショルド値はシステム毎に設定が必要である。ここで問題になるのは、作成したポリシに基づきシステムが正しく動作することをどのようにして確認するかである。具体的には、サーバ割当のスレッショルドとなるＣＰＵ使用率を８０％に設定したとして、これによりアクセス集中時の応答の遅延を防ぐことができるか？ということを検証する必要がある。スレッショルドの設定が高すぎると、サーバの割当が遅れるため、サーバが過負荷になり、システムのサービスレベルを維持することができなくなる。逆に、スレッショルドを低く設定すれば、システムのサービスレベルを維持することができるが、過剰なサーバ割当によりコストの増大を招き、望ましくない。コストとサービスレベルのトレードオフを両立させる妥当な値を設定することが求められる。

さらに、サーバの挙動は、キャッシュ等の過渡挙動（時間で変化する要素）の影響を強く受けるため、ポリシの作成には、サーバの過渡挙動も考慮が必須である。図５〜図７を用いて過渡現象の影響について説明する。図５は自律管理を行う３層Ｗｅｂシステムにおいて、初期状態（図５（ａ））と自律管理により、ＤＢサーバが追加された後の構成を（図５（ｂ））示す。初期状態（図５（ａ））ではＷｅｂサーバ３１００、ＡＰ（アプリケーション）サーバ３２００、ＤＢ（データベース）サーバ３３００が割り当てられており、クライアント群３５００からのリクエストを処理する。ＤＢサーバはストレージ３４００上のデータを用いて処理を行う。また、Ｗｅｂ、ＡＰ、ＤＢの各層には、予備サーバ３１１０、３２１０、３３１０が置かれている。図５（ｂ）は、ＤＢサーバが過負荷になったことにより、自律管理処理により、予備のＤＢサーバ３３１０が現用サーバとして追加され、クライアントからの処理を受け付けるようになった状態を示す。

図６（ａ）はシステムの入力負荷、図６（ｂ）は自律管理を行わない場合の、システムの応答時間の変化を示す。時刻Aで入力負荷が急増したことにより、自律管理を行わない場合（図５（ａ）の構成で処理を続けた場合）は図６（ｂ）に示すように、時刻Aから後の応答時間が増大してしまう。それにより、そのまま処理を続けていたのでは、システムの応答時間の上限４０１１を越えてしまうため、自律管理機構が働き、図６（ｃ）に示すように、ＤＢサーバが１台から２台に増強され、図５（ｂ）の構成になる。ことで、本システムでは、ＤＢサーバのみがネックになっており、Ｗｅｂ、ＡＰサーバはネックにならないと仮定する。その結果、時刻Bより後は２台に増えたＤＢサーバにラウンドロビンで負荷を分配することにより、ＤＢサーバの処理能力が２倍に向上し、応答時間が減少するはずである。しかし実際には、キャッシュに起因する過渡現象のため、応答時間は簡単には減少しない。以下でその理由を述べる。

図７（ａ）に追加されたＤＢサーバの性能変化、図７（ｂ）にシステムの応答時間の変化を示す。システムのＤＢサーバが１台から２台に増強された場合に、理想的には図７（ｂ）の点線４０４１のように応答時間が削減されるはずである。しかし、実際には実践４０４０のように、応答時間は一旦急激に増加してしまう。その原因は、追加されたＤＢサーバ３３１０のデータキャッシュの影響である。自律管理処理により、ＤＢサーバが３３１０時追加された直後には、追加されたばかりのＤＢサーバ３３１０のキャッシュ内にはデータは無く（コールドキャッシュ）、追加されたＤＢサーバ３３１０の性能は低い。その後キャッシュ内にデータが蓄積されるにつれ、ＤＢサーバ３３１０の性能は徐々に向上し、最終的には既存ＤＢサーバ３３００と同程度まで回復する。従って、既存ＤＢサーバ３３００の性能を１００％とした場合、追加されたＤＢサーバ３３１０の性能は図７（ａ）のように時刻Bから徐々に向上するカーブを描く。追加ＤＢサーバの性能が既存ＤＢサーバと同一になる時刻をCとする。既存ＤＢサーバ、追加ＤＢサーバに上記のような性能差があるにもかかわらず、両方のＤＢサーバに単純にラウンドロビンで負荷を分配すると、性能の低い追加ＤＢサーバの処理待ちキューにリクエストがたまってしまい、システム全体の性能が大幅に低下してしまい、図（７）（ｂ）の性能低下の原因となる。

上記の現象の原因は、既存サーバと追加サーバに性能差があるにもかかわらず、性能差を考慮せず負荷分散を行ったことにある。この現象を避けるためには、各々のサーバの性能に見合った負荷を課する必要がある。図７（ｃ）にこの現象をさけるための負荷分散ポリシを示す。サーバが１台から２台に追加された時点（時刻B）でいきなり既存ＤＢサーバの負荷の半分を追加ＤＢサーバに割り当てるのではなく、追加ＤＢサーバへの負荷分散量を徐々に増やし（図７（ｃ）４０６０）、両者のサーバの性能が同一となる時刻Cに負荷が均等に分配されるように制御する。自律管理によりＤＢサーバが追加された際には、この負荷分散ポリシを適用することにより、追加ＤＢサーバ３３１０の性能が低いうちに過大な負荷が課せられることを回避し、システムの性能が低下することを回避することができる。この例のように、自律管理ポリシでは、単にサーバ追加・削減スレッショルドを記述するだけでなく、サーバ性能の過渡現象を考慮した負荷分散ポリシ、さらには前記第２の公知例でのべたような、負荷の持続時間、サーバの割当履歴などを考慮する必要がある。

上記のように、システムの応答時間には、サーバの性能の過渡的な変化等の複雑な要素がからむ。自律管理ポリシの作成時にはサーバ性能の過渡現象などを考慮した複雑なポリシを作成する必要がある。そのため、あるサイトに向けて作成された自律管理ポリシの妥当性を検証しようとすると、人手の机上チェックでは到底不可能であり、現在は、実際のシステムで確認する以外の方法は無い。そのため、ポリシの検証を行おうとすると、多大なコストがかかる。また、実際のシステムが完成してからしかポリシの検証を行なうことができないために、システム構築期間が延びると言う問題も生じる。
本発明の目的は、ポリシ制御による自律管理システムにおいて、ポリシ作成時に、作成したポリシの妥当性の検証を、低コストかつ迅速に行うことである。

上記目的を達成するために、下記の機能を持つ自律管理向けポリシシミュレータを提供する。シミュレータは、自律管理向けポリシ、該当する処理に割当てられたサーバを表すシステム構成、入力負荷の時間変化、システムで動作させるプログラムの性能情報、動作させるプログラムの性能の過渡特性を入力とし、システムの挙動（処理量、応答時間、リソース使用率）を出力する。
さらに、自律管理により刻々と構成を変化するシステムにおいて、過渡状態を含めたシステムの挙動のシミュレーションを実現するために、シミュレータは、ある時刻のシステムの構成、負荷分散の設定、入力となる負荷の情報を先ず求め、それを元に、その時刻の過渡現象を考慮したリソース使用率、アプリケーションの応答時間、システムの処理量を計算する。さらに、その結果を自律管理のポリシに当てはめ、どのポリシーを適用するか決定する。そして、該当する自律管理ポリシを適用し、次時刻のシステム構成、負荷分散の設定を決定する。シミュレータは時刻を進めた後に、次時刻の挙動のシミュレーションを繰り返す。以上の動作により、自律管理ポリシに基づきシステムの構成を刻々と変えてシミュレーションを行うことが可能である。さらに、ソフトウェアの過渡状態を考慮したシステムの挙動をシミュレーションすることを可能にする。さらに、自律管理の判断を行う際に、ソフトウェアの過渡特性等を反映したシステム挙動をベースに判断を行うことを可能にする。

本発明によれば、ポリシ制御による自律管理システムにおいて、作成したポリシが対象とするシステム上で期待通りに動くことを、実システムを使用することなく、低コストかつ迅速に検証することが可能となる。さらに、自律管理システムのシミュレーションを行なう際に、ソフトウェアの過渡的な応答を考慮したシステムの挙動をシミュレーションするため、システムの挙動を正確にシミュレーションすることが可能となる。

以下、本発明に係るシミュレータを、図面に示した実施例を参照して詳細に説明する。
＜実施例１＞
図１は本発明の実施例のシミュレータの入出力を表す。シミュレータ１００の入力は、自律管理ポリシ２００、システム全体の構成を示す構成情報３００、システムの入力となる負荷量（アクセス量等）の時間変化を示す負荷条件４００、システム上で動作するソフトウェアの性能情報（ソフトウェアのＣＰＵなどのリソース使用量、応答時間）を示すライブラリ５００、ソフトウェアの過渡的な性能特性を示すライブラリ６００である。負荷条件４００では、入力負荷の変動の他に、サーバの故障などの外乱も広義の外乱としてここに定義される。シミュレータの出力は、システムの応答時間、リソース使用率、システムの処理リクエスト数（処理量）等のシステム挙動７００、および、自律管理ポリシがどのように適用されたかを示すポリシ適用ログ８００である。負荷条件４００でシステム負荷の時間変化を入力し、また、ソフトウェアの過渡的な性能情報６００を入力することにより、システムの過渡的な性能を考慮したシミュレーションを行うことができる。

図２はシミュレータ１００の内部構成の機能ブロック図である。１３０は時刻管理機能であり、シミュレータ全体が現在どの時刻のシミュレーションを行っているかを示す擬似的な時計である。１２０はシミュレーション対象となるシステムの入力負荷を計算する機能であり、時刻管理が示す時刻での入力負荷量を得る。入力負荷のほかにサーバの故障などの外乱情報も得られる。１１０はシステム挙動計算機能であり、１２０で計算したシステムの入力負荷、現在のシステム構成及び負荷分散の設定１７０、ライブラリのソフトウェアの性能情報５００、過渡性能特性６００より、システムの挙動（応答時間、リソース使用率、処理量）１４０を計算する。１５０はポリシ適用機能であり、今回計算したシステムの挙動をベースに、シミュレーション対象となるポリシ２００のうちで、現在のシステム挙動に適合したポリシを選択する。１６０は、次時刻システム構成、負荷分散設定決定機構であり、１５０で選択したポリシを現在のシステムに適用し、次時刻のシミュレーションに使用するシステム構成、負荷分散設定１７０を決定する。

図３はシミュレータの動作フローであり、シミュレータ１００は図３で示す処理を繰り返す。図４は本シミュレータを使用して、フィードバックによるポリシ最適化を行なうための、ポリシ入出力画面である。オペレータは図４の画面２０１０を介して、作成したポリシに基づくシミュレーション結果の観測、ポリシの改良を行なう。
図８は本発明のシミュレーション対象となる３階層Ｗｅｂシステムであり、自律管理により、各層のサーバを負荷に応じて自動的に増減させる。図９は本ＬＡＮに接続するためのＩｎＢｏｕｎｄのストレージサーバである。各サーバはディスクキャッシュを持っているため、過渡現象を考慮したポリシが必須である。図１０はポリシ記述方法の一例である。

本発明の特徴は、ポリシシミュレータ１００が、入力負荷変動や外乱４００及び、ソフトの過渡特性６００を考慮してシステムの挙動を求め、さらに、求めたシステム挙動に自律管理のポリシを適用しながら、シミュレーションを進めることにある。
以下では図１〜図４、図８〜図１０を用いて、実施例のシミュレータの動作を詳細に述べる。
図８にシミュレーション対象システムの構成の一例を示す。図のシステムでは、Ｗｅｂ、ＡＰ、ＤＢからなる３階層システムで、各層２台づつの現用サーバ５０４０、５０４１、５０５０、５０５１、５０６０、５０６１及び各層１台の予備サーバ５０４２、５０５２、５０６２から構成される。管理サーバ５０８０においてポリシベースによる自律管理を行い、システムの負荷に応じて予備サーバを現用サーバに変化させ、システムのサーバが過負荷になることを抑え、システムの応答時間を一定に保つ。自律管理システムの制御方法の詳細は公知であるのでここでは割愛する。このようなシステムでは、従来技術等でのべたような、過渡現象を考慮した複雑な自律管理ポリシが必須であり、管理サーバ５０８０で動作する自律管理ポリシの検証が非常に難しい。本発明のシミュレータは自律管理ポリシの動作検証を目的としている。

本実施例のシミュレータは、Ｗｅｂシステムだけでなく、図９に示すようなストレージシステムにも適用することができる。図では、現用のストレージサーバ６０４０〜６０４１の他に、予備のストレージサーバ６０４２が置かれ、負荷に応じて予備のストレージサーバを現用に加えることによって、システムの応答時間の低下を回避する。この例でも各ストレージサーバはディスクキャッシュ５０５０〜５０５２を持つため、予備から現用に追加されたばかりのストレージサーバの性能が、現用サーバより遅いと言う問題があるため、図７（ｃ）のような、両者の過渡的な性能差を考慮した負荷分散ポリシが必要になる。したがって、この場合も、自律管理ポリシの検証が課題となる。

図１０に自律管理ポリシの記述例を示す。ポリシは、条件、（条件の）論理式、（左記が成立した場合の）自律管理アクションに大別される。条件としては、（トランザクション数等の）システム処理量、（ＣＰＵ、ネットワーク、ディスク等の）システムリソース使用率、アプリケーション応答時間、の閾値との比較、閾値を超えた／下回った場合、その持続時間、さらには、前回の自律管理制御アクションからの経過時間が挙げられる。自律管理アクションとしては、ある処理に割当てられているサーバやサーバへの負荷分散量を増やす、減らす、さらに徐々に増やす、徐々に減らすことである。これらの条件、アクションを組み合わせることにより、自律管理のアクションが記述される。例えば、
・サーバのＣＰＵ使用率が８０％を超えたら新しいサーバを一台追加する
・新しいサーバを追加した場合の、新しいサーバに課する負荷値は図７（ｃ）の式に従い
変化させる
等がポリシの具体例である。これらのポリシはシステムの構成、動作するプログラム、システムの入力負荷、ユーザの求めるサービスレベルにより、新たに作成する必要がある。
ポリシシミュレータ１００は、上で述べたようなポリシの動作をシミュレーションし、ポリシの妥当性を確認するシステムである。図１に示すように、ポリシシミュレータの入力は下記である。
（１） 自律管理ポリシ２００
（２） 図１０で述べた自律管理のためのポリシ
（３） システム全体構成３００
（４） 図８、図９のような、ポリシが制御対象とするシステムの（予備サーバを含めた）全体の構成。本特許では該当する処理に割当てられ、実際にシステムが処理に使用する（予備サーバを除く）サーバの構成は「システム構成」と呼び、予備サーバを含めた全体の構成を示す「システム全体構成」と区別する。システム全体構成のうちの現用サーバは、シミュレーションの初期状態でのシステム構成となる。システム全体構成では、物理的なトポロジに加え、各サーバやネットワーク、ストレージの処理性能も記述される。
（５） 負荷条件４００
（６） シミュレーション対象となるシステムの入力負荷（ユーザクライアントから到来するリクエスト量等）の経時変化（の予測値）である。これにより、例えば、ある時刻に急激なアクセス集中が生じた場合の自律管理システムの挙動をシミュレーションすることができる。自律管理システムの主要な目的に、サーバ故障時の代替サーバ自動割当等の外乱に対する対処がある。負荷条件の中で、外乱を記述することにより、サーバ故障等の外乱をシミュレーションすることを可能にする。例えば
（７） ・時刻５００秒： ＤＢサーバ１故障
（８） 等が外乱の記述例である。
（９） ソフトウェア性能情報５００
（１０） シミュレーション対象のシステム上で動作するソフトウェアの定常状態での応答時間、リソース使用量を記述する。例えば、
（１１） ・ＤＢ層トランザクション： 平均応答時間１ｍｓ／回、
（１２） 平均リソース使用率、１ＧＨｚ Ｐｅｎｔｉｕｍ（登録商標） ＣＰＵ： ０．５ｍ秒／回
（１３） （ネットワーク、ディスクの記述も必要であるがここでは省略する）
（１４） のように記述を行なう。システムの性能計算の基本となる値である。
（１５） ソフト過渡特性６００
（１６） ソフトウェアの過渡的な特性を表すライブラリである。過渡現象記述の一方法は、図７（ａ）に示すように、過渡的な現象がのトリガとなる現象が発生してからの、システムの性能の経時変化で示される。図７（ａ）では、ＣＰＵの処理能力が過渡的に低下する場合であり、システム処理能力が通常時の何％であるかが示されている。上記の他に、過渡的にオーバヘッドが発生する場合には、ＣＰＵ等のリソース使用率が、通常時の何％になるか（１００％以上の値になる）で示す場合もある。（４）と共に用いることにより、システムの過渡現象を含めた性能を求めることができる。
シミュレータは下記を出力とする。
（１） システム挙動７００
（２） システムの挙動を表すデータの経時変化、具体的には、システムの応答時間、ＣＰＵ、ネットワーク、ディスク等の各リソース使用率、システムの処理量（処理リクエスト数）等の変化である。本データを用いることにより、システムがサービスレベルに合致して期待通りに動いているかどうかを確認することができる。
（３） ポリシ適用ログ８００
（４） 各ポリシがどのように適用されたかを示すログであり、時刻、適用されたポリシの識別子、ポリシの判断に使用したパラメータの値が保持される。また、自律管理によるサーバの割当状況も記録される。（１）と共に用いることにより、作成したポリシが期待通りに動かなかった場合のデバッグ、さらにはフィードバックによるポリシ最適化に活用することができる。

次にシミュレータの詳細な動作について、図２、図３を用いて説明する。本自律管理システムシミュレータは、各シミュレーションサイクルについて、
（１） 該当する時刻のシステム動作の把握
（２） （１）の結果に基づき自律管理ポリシを適用
（３） （２）に基づき次時刻のシステム構成、負荷分散設定を求める
を繰り返す。（３）で求めた、システム構成、負荷分散設定に基づき、次時刻のシミュレーションを行なう。シミュレーションサイクルをどの値にするかは、各シミュレータに必要な、精度、シミュレーションのスピードへの要求等に応じ、下記の要素を考慮して決定する。
・シミュレーションサイクルを短くすれば、精度は上がるが、シミュレーションに必要な
時間は長くなる
・シミュレーションサイクルをながくすれば、シミュレーションは早く終わるが、精度が
低下する
・シミュレーション対象のシステムで問題となる過渡現象より十分短いサイクルで、
シミュレーションを実行する必要がある（さもないと、過渡現象の評価制度が）
大幅に低下する。
以下では、各シミュレーションサイクルにおける動作を詳細に述べる。

シミュレータは先ず、現在のシミュレーションサイクルにおける、システム構成、負荷分散設定１７０を取得すると共に、システムの入力負荷、外乱情報を得る（ステップ１００１）。ここで、システム構成、負荷分散設定１７０は、通常は前の時刻のポリシ適用１６０により求められる。シミュレーションの最初のサイクルでは、システム全体構成３００に示された、初期状態の現用系サーバの構成、ｄｅｆａｕｌｔの負荷分散設定を使用する。システムの入力負荷、外乱情報は、入力負荷計算機能１２０が、負荷条件４００から、現在のシミュレーションサイクルに該当する時刻の情報を読み出すことにより、得られる。
シミュレータは次に、システム挙動計算機能１１０により、ステップ１００１で得られたシステム構成、入力負荷等の情報と、ソフトウェアの性能情報ライブラリ５００、ソフトウェアの過渡特性ライブラリ６００を使用して、システムのリソース使用率、応答時間、システム処理量等のシステムの挙動１４０を計算する（ステップ１００２）。計算方法の一例は下記である。
（１） 性能情報ライブラリ５００に示されたソフトウェアの性能情報（応答時間、リソース使用量）を得る
（２） 過渡特性ライブラリ６００より、現在の時刻における過渡特性をあらわす値を得る。例えば、図７（ａ）では、追加ＤＢサーバが割当てられてから、現在までの経過時間を計算し、過渡特性のグラフに当てはめることにより、現在のＣＰＵ性能が通常の何％であるかを求めることができる。
（３） システム構成１７０において、故障などの外乱情報に該当する機器の使用を禁止する。該等する機器は、（４）の挙動計算時に使用することができない。
（４） （３）で得られた使用可能な機器情報、１７０の負荷分散設定、システム全体構成３００から得られるＣＰＵ等のハードウェア性能、（１）で得た性能情報より、システムの挙動を計算する。その際に（２）で得た過渡特性の情報により、上記情報を修正する。例えば、
（５） ・ＣＰＵ性能が通常時の何％に低下しているか？
（６） ・ソフトウェアのオーバヘッドが通常時の何％に増大しているか？
（７） に応じて値を変更する。
（８） 上記の値を用いて、積み上げベースでシステムの挙動（ＣＰＵ等のリソース使用率、応答時間、システムの処理量）を求める。リソース使用率が１００％を超えた場合は、その分の待ち時間を応答時間に足す。
計算したシステム挙動は、シミュレータの出力７００として出力される。

シミュレータは次のステップとして、ポリシ適用機能１５０により、ステップ１００２で計算したシステム挙動１４０を元に、自律管理ポリシ２００のうちのどれが適用できるかを判断する（ステップ１００３）。具体的には、図１０で述べた自律管理ポリシの条件６００１、６００２、６００３部分にシステム挙動１４０を適用し判断するとともに、現在の時刻とポリシ適用履歴より条件６００４を判断し、さらに、サーバ割当状況６００５を判断し、最終的な判断６０１０を行い、該当するポリシが適用可能かどうか判断する。前回アクションからの経過時間６００４とは、例えば「サーバが削減され、予備サーバになった後５秒間は他の処理への割当を禁止する」等のポリシである。また、サーバ割当状況とは、「該当するユーザには最大４台までサーバの割当を許可する」といったポリシである。判断の結果適用可能であると判断されたポリシの情報は、ポリシ適用ログ８００に保存される。

適用するポリシが決定した後、シミュレータは次時刻システム構成、負荷分散設定決定機構１６０により、ステップ１００３において決定されたポリシを現在のシステム構成、負荷分散設定に適用し、次のシミュレーションサイクルのシステム構成、負荷分散設定１７０を決定する（ステップ１００４）。ここで、システム構成とは、現用系として使用しているサーバ等の構成情報である。負荷分散設定とは、複数のサーバに負荷を分散する方法で、ラウンドロビン、図７（ｃ）のような複数のサーバで重みを変えた負荷分散等がある。これにより、シミュレータでの現在のシステム稼動状況に応じた自律管理ポリシの適用を実現する。
以上の処理の後、シミュレータはシミュレーションクロックを進め（１００５）、シミュレーションの最初（ステップ１００１）からの動作を繰り返す。
以上の処理により、自律管理システムの過渡情報を考慮した、ポリシの動作検証を実現することができる。

次に本シミュレータを適用したフィードバックによるポリシ最適化について述べる。自律管理システムのポリシ作成時には、通常は一回で満足の行くポリシを作成することは困難であり、試行錯誤によるポリシの最適化が必要である。本シミュレーションツールは、シミュレーション結果を観測し、フィードバックによりポリシを最適化する際に使用することができる。
図４に本シミュレータの入出力画面２０１０を示す。出力画面には、稼動状況の出力部分２０１２、ポリシ適用ログの出力部分２０１１及び、ポリシ入力のためのエディタ部分２０１３が存在する。ポリシの最適化は下記の手順で行なわれる。
（１） ポリシエディタで（初期）ポリシを入力する
（２） 本シミュレータで自律管理システムの挙動をシミュレートする
（３） シミュレーション結果を画面２０１０に表示する
（４） 稼動状況２０１２を観測し、挙動に問題のある（例えば、ＳＬＡで定めた最大
（５） 応答時間を超している）部分が無いか調べる。
（６） （問題部分が無ければ、最適化終了）
（７） 問題部分がある場合、ポリシ適用ログ２０１１を調査して、ポリシのどの部分に問題があるかを判断する。
（８） ポリシの問題がある部分をポリシ入力エディタ２０１３で修正する。
（９） シミュレーション結果をフィードバックした、新しいポリシを使用して、再度挙動をシミュレーションする。
（以下（３）に戻り、最適化が終了するまで繰り返す）
以上の処理により、自律管理システムのポリシを、シミュレーション結果をフィードバックさせて最適化することができる。
＜変形例＞
本発明は以上に述べた実施例に限定されるのではなく、いろいろの変形例にも適用可能である。例えば、
（１） 実施例１においては、リソース使用量等の積み上げにより求めるているが、待ち行列モデルに基づくシミュレーションにより、より正確なシミュレーションを行なうことができる。
（２） 実施例１においては、現用系１系統だけである。言い換えれば、システム内では１ユーザ（１業務）の処理だけが行なわれている場合である。本発明で述べたシミュレーションシステムでは、現用系が２系統以上（複数ユーザ、業務が予備サーバを共有した構成）の場合のシステム挙動もシミュレーションすることができる。その場合は、他系統のサーバ割当状況を考慮しつつ、全ての挙動のシミュレーションを並行して行えば良い。
（３） 実施例１においては、自律管理の制御対象はサーバであったが、ストレージ、ネットワーク装置などを対象にした場合も、全く同様の手法でシミュレーションを行うことができる。

本発明は作成した運用管理ポリシが期待通りのシステム挙動をするか否かを実システムを使用することなく検証できるので、データセンタ等の多数の計算機資源を自立管理するシステムに適用して管理負担の軽減する効果が大きく、この分野への適用が期待できる。

本発明の実施例のポリシシミュレータの入出力構成である。 実施例のポリシシミュレータの内部構成を示す機能ブロック図である。 実施例のポリシシミュレータの動作フローである。 実施例のポリシシミュレータの入出力画面である。 シュミレーション対象となる３階層Ｗｅｂシステムのサーバ追加前後の状態である。 ３階層Ｗｅｂシステムにおける自律管理における挙動である。 ３階層Ｗｅｂシステムにおける自律管理における過渡現象である。 ３階層Ｗｅｂシステムの構成例を示すブロック図ある。 制御対象となるストレージシステムの構成例を示すブロック図である。 実施例の自律管理ポリシの記述例である。

Claims (7)

1. ポリシ制御による自律管理を行う計算機システムの挙動を解析するシミュレータにおいて、
   解析対象のシステムに割当てられたサーバ、ストレージ、ネットワーク機器の情報を表すシステム構成、上記システムの入力負荷、上記システム上で動作するソフトウェアの性能情報、及び、上記システムの自律管理ポリシを入力とし、上記システムの挙動を出力することを特徴とする自律管理システム向けポリシシミュレータ。
2. 出力として自律管理ポリシの適用ログを出力することを特徴とする請求項１記載の自律管理システム向けポリシシミュレータ。
3. ソフトウェアの過渡的な性能変化の情報を入力とし、ソフトウェアの過渡的な性能変化を考慮したシステム挙動を出力することを特徴とする請求項１記載の自律管理システム向けポリシシミュレータ。
4. 上記システム内の機器の故障等の外乱情報を入力とし、外乱情報を考慮したシステム挙動を出力することを特徴とする請求項１記載の自律管理システム向けポリシシミュレータ。
5. 上記システムの処理量、リソース使用率、応答時間等のシステム動作状況を表す値と、閾値との比較結果及び持続時間、前回の自律管理アクションからの経過時間、上記システム内のサーバ、ストレージ、ネットワーク機器の割当情報、及び、上記項目の論理演算により記述される自律管理処理の条件、
   及び、上記条件が成立した場合に実行される、割当サーバ、ストレージ、ネットワーク機器の数、サーバ、ストレージ、ネットワーク機器への負荷分散の量の、増加、削減、もしくは、徐々に増減させることにより記述される自律管理アクション、
   の組合せにより、ポリシを記述することを特徴とする請求項１記載の自律管理システム向けポリシシミュレータ。
6. シミュレータの内部でシミュレーションクロックを管理し、
   各シミュレーションクロックにおいて、
   該シミュレーションクロックにおける、システムに割当てられたサーバの情報を表すシステム構成、各サーバ、ストレージ、ネットワーク機器への負荷分散の設定、システムの入力負荷を得るステップ、
   上記情報、及び、システム上で動作するソフトウェアの性能情報、ソフトウェアの過渡的な性能変化の情報に基づき、該シミュレーションクロックにおける、システムの挙動を表す、システム内のリソース使用率、アプリケーションの応答時間、システムの処理リクエスト数等を計算するステップ、
   上記で計算した、システムの挙動を表す、システム内のリソース使用率、アプリケーションの応答時間、システムの処理リクエスト数等を、自律管理を自律管理ポリシに適用し、適用する自律管理ポリシを適用するステップ、
   該自律管理ポリシに従い、次時刻のシステム構成、負荷分散設定をどのようい変更するかを決定するステップ、
   上記で変更されたシステム構成、負荷分散設定を、次のシミュレーションクロックでのシミュレーションに使用することを特徴とする請求項３記載の自律管理システム向けポリシシミュレータ。
7. ポリシベース自律管理システムのポリシ最適化方法であって、
   解析対象のシステムに割当てられたサーバ、ストレージ、ネットワーク機器の情報を表すシステム構成、上記システムの入力負荷、上記システム上で動作するソフトウェアの性能情報、及び、上記システムの自律管理ポリシを入力とし、自律管理ポリシの適用ログを出力するシミュレータにポリシを適用してシステム挙動、及びポリシ適用ログを求め、
   上記システム挙動、ポリシ適用ログより発見された問題点を、従来のポリシにフィードバックし、新しい改善されたポリシを作成し、
   該新ポリシを元にシミュレーションを繰り返して、ポリシを最適化することを特徴にする、自律管理システム向けポリシ最適化方法。

Images