(57)【要約】【課題】  従来システムの再構成においては、稼働状況を監視することはされていたものの、これをどのように用いて処理するかに関しては何ら記載されていない。つまり、従来、単に稼働状況を用いて、計算機資源を割り当てるとしかなく、どのサーバ（ハードウエア資源）がボトルネックになっているかについては考慮されていなかった。【解決手段】  システムを構成するサーバなどのハードウエア資源の稼働状況からいずれのハードウエア資源が処理上のボトルネックになっているか判定するものである。より具体的には、各ＣＰＵに処理上のボトルネックの度合いを示す閾値を設定しておき、これと各サーバの予想される度合いを比較して判定する。【選択図】  図２
2006344091.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバからなり、所定の情報処理を実行するシステムの再構成を実現するためのシステム再構成自動化装置において、
事前に、前記複数のサーバそれぞれについて上記情報処理のボトルネックを示す指標の閾値を記憶する管理手段と、
稼動中の上記複数のサーバのそれぞれに対して稼働状況を監視して、上記指標の現在値を得る監視手段と、
上記稼働状況に基づいて、一定期間後の上記複数のサーバそれぞれの上記指標の値を予測して、予測された上記指標の予測値と上記閾値とを比較してボトルネックとなるサーバの有無を判定する予測判定手段と、
ボトルネックとなるサーバが有る場合に、上記システムを再構成するための情報処理を実行する再構成手段とを有し、ボトルネックとなるサーバがない場合には、上記監視手段において上記指標の監視を行わせることを特徴とするシステム再構成自動化装置。
【請求項２】
請求項１において、
前記指標は、前記サーバが有するＣＰＵ平均使用率であることを特徴とするシステム再構成自動化装置。
【請求項３】
請求項１または２において、
前記予測判定手段は、予測された前記指標のうち、上記予測値が前記閾値を超えるか最も近い指標を有するサーバをボトルネックとなるサーバとして判定することを特徴とするシステム再構成自動化装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、いわゆるコンピュータシステムのシステム変更に関するものである。その中でも特に、リソース不足に伴うシステムの再設計および再構成に関わる。
【背景技術】
【０００２】
従来、システム変更を行うものとしては、特許文献１がある。特許文献１には、複数のＯＳが用いる計算機資源を、各ＯＳの状況に応じて効率的に割り当てる技術が記載されている。つまり、特許文献１においては、各ＯＳの負荷状態を監視することは記載されている。
【０００３】
【特許文献１】特開２００１−３３１３３３号公報  未来に対する予測値の算出を行うものとしては、特許文献２がある。特許文献２には、商品の需要特性を分析し、その需要特性に即した需要モデルを抽出する過程を定式化した技術が記載されている。つまり、特許文献２においては、過去に対して各候補モデルを適用した際の予測値を算出し、実際の需要実績と対比し、最適な予測モデルを選定することにより、未来に対する予測値を算出することは記載されている。
【０００４】
【特許文献２】特開２０００−２５０８８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上述した特許文献１には、以下の課題がある。特許文献１には、負荷状態を監視する、との記載はあるものの、これをどのように用いて処理するかに関しては何ら記載されていない。つまり、特許文献１には、単に負荷状態を用いて、計算機資源を割り当てるとしか記載されていない。
システムの再構成に当たっては、どのサーバ（ハードウエア資源）が処理上問題になっているかまで把握する必要がある。つまり、単に稼働状況を把握しているのみでは、どのようにシステムを再構成するか不明確になる為である。
上述した特許文献２には、予測値をどのように用いて処理するかに関しては何ら記載されていない。
また、閾値を設定しておき、それを超えたものを障害として検知し対処を行うといった事後的な対応を行うのではなく、システム要件を継続して満足する為には、問題が発生する前に予防的な対処を行う必要がある。
【課題を解決するための手段】
【０００６】
そこで、本発明では、システムを構成するサーバなどのハードウエア資源の稼働状況から、いずれのハードウエア資源が処理上のボトルネックになっているか判定をした上でシステムの再構成の自動化を実現するものである。
より具体的には、各ＣＰＵに処理上のボトルネックの度合いを示す閾値を設定しておき、これと各サーバの予想される度合いを事前に比較して判定する。ここで、ボトルネックの度合いには、ＣＰＵの使用率が含まれる。また、閾値との比較は、予め予測した値が閾値を越えたものや最も近いものをボトルネックになるものとして判定することが含まれる。
【発明の効果】
【０００７】
本発明によれば、ボトルネックの発生の事態を事前に回避して容易にシステムの再構成を実現することが可能になる。
【発明を実施するための最良の形態】
【０００８】
次に、本発明の実施形態について、図面を参照して説明する。
図1は本発明のシステム構成の概略を示した図である。
本発明のシステムの再構成を実現するシステム再構成自動化装置は、システム運用管理機構１と、システム要件入力機構２と、システム構成モデル選択機構３と、システム詳細設定機構４と、システムデプロイ実行機構５と、デプロイシステム６と、システムリソース監視機構７と、システムリソース使用量予測機構８と、システム構成パターン管理ＤＢ１０と、推奨システム構成管理ＤＢ２０と、システム運用管理ＤＢ３０と、デプロイリソース管理ＤＢ４０とシステムリソース管理ＤＢを有している。
【０００９】
システム運用管理機構１は、システム要件入力機構２からの入力情報をシステム構成モデル選択機構３のデータベース登録処理に従い、システム構成パターン管理ＤＢ１０の指定された格納先に情報を登録する。また、デプロイ実行に必要な情報をシステム構成モデル選択機構３とシステム詳細設定機構４から取得し、システムデプロイ実行機構５に受け渡す処理を行う。
システム要件入力機構２は、図４のシステム要件入力画面１１０を表示させ、システム構成パターン管理ＤＢ１０に登録する情報をシステム運用管理機構１に受け渡す処理を行う。
システム構成モデル選択機構３は、システム構成パターン管理ＤＢ１０に登録された情報と推奨システム構成管理ＤＢに記録されている情報とを比較し、図４のシステム構成モデル選択画面１１１にシステム名と使用アプリケーションおよびシステム推奨モデルの候補を表示させる処理を行う。
システム詳細設定機構４は、図４のシステム詳細設定画面１１２を表示させ、サーバ台数とデプロイを実行するために必要なＷｅｂサーバ、ＡＰサーバ、ＤＢサーバの各サーバにおけるホスト名とＩＰアドレス等の個別情報をシステム管理機構１に受け渡す処理を行い、図４のデプロイ実行確認画面を表示する。また、システム詳細設定登録ファイル保存先に指定された格納場所に、デプロイを実行するために必要な情報を保存する処理を行う。
システムデプロイ実行機構５は、システム運用管理機構１からデプロイの実行に必要な個別情報とデプロイリソース管理ＤＢ４０からシステム構成モデル選択機構３で選択されたシステム推奨モデルのデプロイリソース情報の問い合わせを行うもので、デプロイシステム６に問い合わせ結果を渡す処理を行う。
デプロイシステム６は、システムデプロイ実行機構５から取得した情報を元にデプロイを実行し、デプロイの処理が終了した後、システムデプロイ実行機構５に終了した情報を返す処理を行う。
【００１０】
システムリソース監視機構７は、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバにおける各サーバのハードウエア資源の稼働状況を監視する処理を行う。また、監視した結果をシステムリソース管理ＤＢ５０の指定された格納先に情報を登録する処理を行う。
システムリソース使用量予測機構８は、システムリソース管理ＤＢ５０から次週のＣＰＵ平均（ハードウエア資源）使用量を予測するために必要な情報を取得し、特許文献２を用いて、次週のＣＰＵ平均（ハードウエア資源）使用量を予測する処理と、システム運用管理ＤＢ３０のＣＰＵ情報とを比較する処理を行う。
システム構成パターンＤＢ１０は、使用するアプリケーション１１と、システム構成モデル１２と、システム構成モデルの金額１３と、1時間当たりのトランザクション処理量１４と、レスポンスタイム１５と、最大利用ユーザ数１６がシステム構成モデル毎に記憶されている。(図３）
推奨システム構成管理ＤＢ２０は、使用アプリケーション２１と、システム構成モデル２２と、サーバ種２３と、搭載されるオペレーティングシステム（以下、ＯＳ）２４と、サーバのスペックであるＣＰＵ要件２５と、ハードディスク（以下、ＨＤＤ）容量２７と、そのサーバがボトルネックに成り得ると推奨される場合のＣＰＵ閾値２８が事前検証済みであるシステム構成モデル毎に記憶されている。
システム運用管理ＤＢ３０は、図４のシステム要件入力画面１１０で入力された情報と、システム構成モデル選択画面１１１で選択された情報と、システム詳細設定画面１１２で入力された情報であるシステム名３１と、使用アプリケーション３２と、システム構成モデル３３と、サーバ種３４と、各サーバのホスト名（サーバ名）３５と、各サーバが業務を稼働する開始と終了の稼働時間３６と、各サーバのＩＰアドレス３７と、各サーバに設定されたＣＰＵ閾値３８の情報が記録されている。
デプロイリソース管理ＤＢ４０は、使用アプリケーション４１と、システム構成モデル４２と、サーバ種４３と、搭載されるＯＳ４４と、サーバ種４３として動作させるために必要なソフトウェア４５と、ソフトウェアのバージョン（以下、Ｖｅｒ）４６と、デプロイを実行するためのシステム構成モデル４２のシステムイメージが格納されている格納先の情報４７と、パラメータ情報が格納されている格納先の情報４８が記録されている。
システムリソース管理ＤＢ５０は、使用アプリケーション５１と、システム構成モデル５２と、サーバ種５３と、ホスト名（サーバ名）５４と、各サーバにおけるＣＰＵ平均使用率５５と、各サーバにおける次週ＣＰＵ平均使用率予測５６の情報が記録されている。
【００１１】
次に図２、図３、図４、図５を参照して、本発明の実施形態の動作について詳細に説明する。
デプロイが実行できる状態になった場合、図１のシステム詳細設定機構４で図４のデプロイ実行確認ボタンを表示させ（１１３）、「ＹＥＳ」ボタンが押されると、図２のステップ１０１で、デプロイリソース管理ＤＢ４０のアプリケーション４１とシステム構成モデル４２およびサーバ種４３を受付、これに対応するシステムイメージ格納先４７とパラメータ格納先４８からデプロイに必要な保存されている情報（アプリケーションのパラメータ値等、保存情報のフォーマットはＣＳＶ形式で記述しておくようにしてもよい）を取得し、システムデプロイ実行処理を開始する。
次に図２のステップ１０２で、デプロイシステム処理を実行し、システム構築を実施する処理を行う。また、図４の運用開始確認画面１１４の画面を表示させる。
図２の運用開始確認画面１１４の「ＹＥＳ」のボタンが押された後（システム構築が終了した後）は、図２のステップ１０３で常に各サーバのハードウエア資源を監視する処理を行う。つまり、各サーバ、例えば、システムリソース管理ＤＢ５０におけるホスト名５４＝ＳＥＲＶＥＲ１を受付、それに対応するＣＰＵの平均使用率６５％を取得して、システムリソース管理ＤＢ５０のＣＰＵ平均使用率５５へ、その情報を反映させ、データベースを更新する処理を行う。また、図には示されていないが定期的に監視する間隔は、ネットワークに負荷がかからない程度に行うように設定し、システム運用管理ＤＢ３０に登録しておくようにしてもよい。
【００１２】
また、図２のステップ１０４で、各サーバのホスト名５４（＝ＳＥＲＶＥＲ１）を受付、次週ＣＰＵ平均使用率を予測する処理を行い、その結果である次週ＣＰＵの平均使用率予測７５％をシステムリソース管理ＤＢ５０の次週ＣＰＵ平均使用率予測５６へ反映させ、データベースを更新する処理を行う。
本発明の実施形態では、図２のステップ１０５において、システムリソース管理ＤＢ５０に登録されている次週ＣＰＵ平均使用予測値５６とシステム運用管理ＤＢ３０に登録されているＣＰＵ閾値３８とを取得する。つまり、システムリソース管理ＤＢ５０からホスト名＝ＳＥＲＶＥＲ１を受付、これに対応する次週ＣＰＵ平均使用率予測７５％と、システム運用管理ＤＢ３０からシステム名＝システムＡおよびホスト名＝ＳＥＲＶＥＲ１を受付、これに対応するＣＰＵ閾値７０％を取得する。
【００１３】
図２のステップ１０６で、取得した両者の比較処理を行う。つまり、次週ＣＰＵ平均使用率予測７５％とＣＰＵ閾値７０％とを比較して、閾値を越えたものや最も近いものをボトルネックに成り得るサーバとして判定の処理を行う。判定結果でボトルネックとなるサーバが無い場合は、図２のステップ１０５へ戻り、各サーバの稼働状態の確認を行う処理を定期的に行う。定期的な稼働状態の確認処理は、各サーバのハードウエア資源を監視する処理の監視間隔に依存するものとする。判定結果でボトルネックとなるサーバが有った場合、つまり、この例で閾値（７０％）を越えているシステム名＝システムＡのホスト名＝ＳＥＲＶＥＲ１がボトルネックサーバとしてピックアップされ、図４の運用維持警告画面に、レスポンスタイム要件を守れない旨のメッセージを表示させ、ボトルネックサーバの欄に該当サーバのホスト名を表示させる。サーバの再検索について「ＹＥＳ」ボタンが押された後は、図２のステップ１０７でレスポンスタイムのシステム要件を満たすシステム構成モデル＝Ｗｅｂ-ＡＰ-ＤＢをシステム構成パターンＤＢ１０から検索する処理を行う。図２のステップ１０８で推奨システム構成管理ＤＢ２０において、システム構成モデル＝Ｗｅｂ-ＡＰ-ＤＢとサーバ種＝Ｗｅｂサーバを受付、それに対応するスペック要件（ＣＰＵ要件２５＝１．５ＧＨｚ、メモリ要件２６＝５１２ＭＢ、ＨＤＤ要件２７＝１０ＧＢ）と、ボトルネックサーバと判定されたサーバ＝Ｗｅｂサーバ、ホスト名＝Ｓｅｒｖｅｒ１のシステム運用管理ＤＢ３０における稼働時間３６＝開始時間０６：００〜終了時間２４：００で稼働する追加可能なサーバ（スケールアップ／スケールアウト可能なサーバ）の候補を図４の追加サーバ選択画面１１６におけるスケールアウト可能サーバまたはスケールアップ可能サーバの欄に該当スペックのサーバ名（ホスト名）とＣＰＵクロック数、メモリ容量およびＨＤＤ容量の一覧を表示させる。また、図には示されていないが追加可能なサーバは、システム構成モデル＝Ｗｅｂ-ＡＰ-ＤＢにおいての必要スペックを最低限満足するスペックのみを追加可能推奨サーバとして表示させるものであってもよい。
【００１４】
次に図２のステップ１０９でデプロイスケジュール設定の処理をする。つまり、図５の追加サーバ設定画面１１７を表示させ、デプロイを実行する日付とデプロイ開始時刻のスケジュールを図１のシステムデプロイ実行機構５へ情報を受け渡す。また、即時デプロイを実行させるような仕掛けの装備を実装してもよい。
次に図５の追加サーバ設定終了画面１１８を表示させ、図５の追加サーバ設定終了画面１１８の「ＹＥＳ」ボタンが押された後は、ステップ１０２へ戻り、デプロイシステム処理が実行され、システムの再構成を行う。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施例のシステム構成図
【図２】本発明の一実施例のフローチャート
【図３】本発明の一実施例における各データベースの内容を示す図
【図４】本発明の一実施例における画面遷移図（その１）
【図５】本発明の一実施例における画面遷移図（その２）
【符号の説明】
【００１６】
１  システム運用管理機構
２  システム要件入力機構
３  システム構成モデル選択機構
４  システム詳細設定機構
５  システムデプロイ実行機構
６  デプロイシステム
７  システムリソース監視機構
８  システムリソース使用量予測機構
１０  システム構成パターン管理ＤＢ
２０  推奨システム構成管理ＤＢ
３０  システム運用管理ＤＢ
４０  デプロイリソース管理ＤＢ
５０  システムリソース管理ＤＢ
【図１】
2006344091.tif 000003
【図２】
2006344091.tif 000004
【図３】
2006344091.tif 000005
【図４】
2006344091.tif 000006
【図５】
2006344091.tif 000007