JP2015069283A - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】 高可用性クラスタを運用した状況において、待機系サーバの性能を動的に変更する。
【解決手段】 特定のサービスを実行する第１の情報処理部と、前記第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、前記第１の情報処理部と連携し、前記第１の情報処理システムに特定の事象が発生した際に、前記特定のサービスを第１の情報処理部から引き継いで実行する第２の情報処理部を有する第２の情報処理システムと、に対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する性能管理部を有する、情報処理装置を備える。
【選択図】 図１

Description

本発明は、複数の情報システムを連携させてサービスの可用性を高める高可用性システムを管理する技術に関する。

近年、情報通信ネットワークを構成する計算機等の各種リソースを仮想化する、仮想化技術が普及している。これに伴い、係る仮想化技術を用いて、仮想化したリソースや、係るリソースの組合せ等を、インターネット等の通信ネットワークを通じてサービスとして提供する、クラウドコンピューティングが普及している。このようなクラウドコンピューティングの普及によって、例えば特定の企業内やデータセンター内において特定の企業等が所有するオンプレミス環境における情報通信装置と、係るクラウドコンピューティングを用いて構築される環境（以下クラウド環境と称することがある）における情報通信装置とを統合した情報通信システムの利用が進んでいる。

このような背景のもと、特定のサービスを実行する現用系システムに発生する障害を検知し、当該サービスを待機系システムに引き継ぐ、高可用性（ＨＡ：Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）システムの分野においても、係る現用系システムをオンプレミス環境に構築し、係る待機系システムをクラウド環境に構築し、これらを統合して高可用性クラスタシステムとする構成が考えられる。以下、このようなＨＡシステムを構成するクラスタを、ＨＡクラスタと称し、ＨＡクラスタを構成するシステム間におけるサービスの引継ぎ処理を、フェイルオーバ処理と称する場合がある。

一般的にＨＡクラスタを構成する待機系システムについては、前述したサービスのフェイルオーバ処理に際して、当該サービスの稼働性能（スループット等）が低下することを防ぐため、現用系システムと同等の性能を確保する場合がある。ここで、一般的にクラウド環境に仮想システムを設ける場合、用意する仮想システムの処理性能に応じてクラウド環境を利用する利用料が異なる場合がある。

このため、クラウド環境に用意する待機系システムとして、現用系サーバと同等の高性能の仮想システムを常時維持すると運用コストが高額化し、低性能の仮想システムにより代用するとサービスの稼働性能が低下する虞がある。よって、平常時には係る待機系システムの性能を抑制し、前記フェイルオーバ処理の際には係るシステムの性能が増大するよう、係るシステムの性能を制御できるとよい。なお、以下において、このようなシステムの性能変更をスケーリングと称する場合がある。このようなシステムのスケーリングに関しては、以下のような技術が開示されている。

特許文献１は、複数のサービスを連携させるサービス連携システムにおいて、処理の増大に伴い自動的にシステムのスケーリングを行う技術を開示する。特許文献１に開示された技術は、複数のクラウド環境を連携させて特定のサービスを提供する情報処理システムにおいて、特定のクラウド環境に用意されたシステムの処理負荷の増大を予測して、他のクラウド環境に用意されたシステムの処理能力を変更することにより、システム全体のスケーリング追従性を高める構成を採用する。

特許文献２は、クラウド環境に構築された仮想サーバのスケーリングにおいて、当該システムの稼働スケジュールに関する情報を参照し、スケーリング処理をスケジューリングする技術を開示する。特許文献２に開示された技術は、スケーリングに伴うオーバーヘッドを低減するため、負荷変動を織り込んだシステムの稼働スケジュールに基づいて仮想サーバの台数を増減するよう処理する。

特許文献３は、システムに含まれるリソースの状況をリアルタイムに監視し、監視結果に基づいてシステムに割り当てるリソースを制御する技術を開示する。特許文献３に開示された技術は、監視エージェントを用いてシステムを構成するリソースの状況を計測及び監視し、前記計測結果と、予め定められたルールに基づいて、当該システムを構成するリソースの増減等の制御を行う。

特許文献４は、実行系ノードの障害発生時に待機系ノードに切り替える情報システムにおいて、優先度に基づいて待機系ノードを選択する技術を開示する。特許文献４に開示された技術は、実行系ノードに発生した障害を取り除ける待機系ノードを、予め用意した複数の待機系ノードの中から優先度に基づいて選択する。また、特許文献４の技術は、切替え元の実行系ノードの性能を参照し、待機系ノードの性能を変更する。

特開２０１２−０９９０６２号公報 特開２０１３−０４１３９７号公報 特開２０１２−０８８７７０号公報 特開２００７−２０７２１９号公報

前述のとおり、ＨＡクラスタにおいて、クラウド環境に待機システムを構築する利益を十分に享受するには、ＨＡクラスタ全体を運用した状況で、クラウド環境に用意する待機系システムの性能を動的に変更する手段が必要となる。更に、クラウド環境に用意した待機系システムの性能変更に際しては、例えば管理者等のオペレータが、クラウド環境における仮想サーバとしての操作と、ＨＡクラスタを構成する待機系システムとしての操作とを、順序に沿って矛盾なく実行する必要がある。係る操作にミスや齟齬があった場合には、不要なフェイルオーバの発生や、フェイルオーバの失敗によるサービスの停止が発生するなどの問題が生じる。

上述した各特許文献に開示された技術は、いずれもシステムのスケーリング方法を開示するに留まり、当該スケーリングについても、例えば仮想サーバ等の稼働数の増減や、予め用意した待機リソースの中から適切な性能のリソースの選択にすぎず、上述した問題を解決するには不十分である。

そこで本発明は、ＨＡクラスタ全体を稼働した状態において、ＨＡクラスタ及びクラウド環境に構築した待機システム対する管理操作を適切な順序で実行し、係る待機システムの性能を動的に変更するよう管理する、情報処理装置等を提供することを主たる目的とする。

上記の目的を達成すべく、本発明に係る情報処理装置は、以下の構成を備えることを特徴とする。即ち、本発明に係る情報処理装置は、特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する性能管理部を備える。

また、本発明に係る情報処理方法は、以下の構成を備えることを特徴とする。即ち、本発明に係る情報処理方法は、 特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する。

また、本発明に係る情報処理プログラムは、以下の構成を備えることを特徴とする。即ち、本発明に係る情報処理プログラムは、特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する処理をコンピュータに実行させる。

なお、上記本発明の目的は、係るストレージ制御プログラムが格納された、コンピュータ読み取り可能な記憶媒体によっても実現可能である。

上記本発明によれば、ＨＡクラスタ全体を運用した状態で、クラウド環境に用意する待機系システムの性能を動的に変更するよう管理できる。また、前記待機系システムの性能を変更する際に、ＨＡクラスタに対する操作と、待機系システムに対する操作を矛盾無く実行できる。

図１は、本発明の第１の実施形態における情報処理装置の機能的な構成を例示するブロック図である。 図２は、本発明の第１の実施形態における情報処理装置の機能的な構成を例示するブロック図である。 図３は、本発明の第１の実施形態における待機系サーバの性能変更処理を例示する、フローチャートである。 図４は、本発明の第２の実施形態における情報処理装置の機能的な構成を例示するブロック図である。 図５は、本発明の第２の実施形態におけるスケール状態記憶部の構成を例示する模式図である。 図６は、本発明の第２の実施形態におけるスケールレベル対応表の構成を例示する模式図である。 図７は、本発明の第２の実施形態におけるクラスタ構成情報の構成を例示する模式図である。 図８は、本発明の第２の実施形態におけるスケールレベル管理情報の構成を例示する模式図である。 図９は、本発明の第２の実施形態における、待機系サーバの変更処理に関するＵＩ画面の一例を例示する模式図である。 図１０は、本発明の第２の実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。 図１１は、本発明の第２の実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。 図１２は、本発明の第２の実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。 図１３は、本発明の第２の実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。 図１４は、本発明の第２の実施形態における、サービスのフェイルオーバ処理を例示する、フローチャートである。 図１５は、本発明の第２の実施形態における、サービスのフェイルオーバ処理を例示する、フローチャートである。 図１６は、本発明の第３の実施形態における情報処理装置の機能的な構成を例示するブロック図である。 図１７は、本発明の第４の実施形態における情報処理装置の機能的な構成を例示するブロック図である。 本発明各実施形態に係る、性能管理装置を実現可能な情報処理装置のハードウェア構成を例示した模式図である。 図１９は、本発明の第５の実施形態における情報処理装置の機能的な構成を例示するブロック図である。

次に、本発明を実施する形態について、図面を参照して詳細に説明する。

＜第１の実施形態＞
本発明の第１の実施形態における情報処理装置について、図１を参照して説明する。図１は、本発明の第１の実施形態における情報処理装置の機能的な構成を例示するブロック図である。

図１に示すように、本実施形態におけるＨＡクラスタ１００は、オンプレミス環境１０１に構築された現用系サーバ１０３と、クラウド環境１０２に構築された待機系サーバ１０４と、待機系サーバ１０４の性能管理を実行する性能管理装置１０６と、を有する。オンプレミス環境１０１と、クラウド環境１０２とは、インターネット等のＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）回線１０９を介して、通信可能に接続されており、前記現用系サーバ１０３と、待機系サーバ１０４と、性能管理装置１０６との間は相互に通信可能である。以下、それぞれの構成要素について説明する。

まず、本実施形態におけるＨＡクラスタ１００は、前述の通りオンプレミス環境１０１に構築された現用系サーバ１０３と、クラウド環境１０２に構築された待機系サーバ１０４とを有し、現用系サーバ１０３に何らかの事象（故障や障害等）が発生した場合に、待機系サーバ１０４が、現用系サーバが実行していた処理（例えば後述するサービス１０５等）を引き継ぐフェイルオーバ処理を実行するよう構成される。

オンプレミス環境１０１は、本実施形態においては、例えば、ＨＡシステム１００を構築する特定の企業や組織などの内部に構成され、当該所有者によって運用される情報処理システムである。本実施形態におけるオンプレミス環境１０１は、物理的なサーバと、それらを通信可能に接続するＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の通信ネットワークを用いて構成してもよい。また、オンプレミス環境１０１を構成するサーバ等の計算機の一部は、仮想化された計算機であるバーチャルマシン（ＶＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）を用いて構成してもよい。本実施形態においては、オンプレミス環境１０１は、現用系サーバ１０３と、性能管理装置１０６と、を有するが、これら以外の任意のサーバ等を有するよう構成してもよい。

現用系サーバ１０３は、サービス１０５を実行するよう構成され、例えば、係るサービス１０５を用いてＨＡクラスタ１０３を利用するユーザあるいは外部のシステムに対して何らかの機能やリソース等を提供する、情報処理装置である。現用系サーバ１０３は、物理的なコンピュータ等の情報処理装置を用いて構成された物理サーバであってもよく、あるいは、バーチャルマシンを用いて構成された仮想サーバであってもよい。現用系サーバ１０３の構成は、ＨＡクラスタ１００あるいはオンプレミス環境１００の構成と、サービス１０５の実行に必要な要件に基づいて適切に選択すればよい。なお、本実施形態における現用系サーバ１０３は、前記サービス１０５に関連するデータ等を保持していてもよい。

クラウド環境１０２は、計算機及び通信ネットワークを構成する各種リソースを仮想化してサービスとして提供するクラウドコンピューティング環境である。本実施形態においては、クラウド環境１０２として、仮想サーバや仮想ストレージ等の仮想化インフラストラクチャを提供するＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）型のクラウドサービスや、データベースやアプリケーション実行環境等のアプリケーションプラットフォームを仮想化して提供する、ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）型のクラウドサービスなどを採用してもよい。本実施形態においては、具体的なクラウドサービスとして、例えば、Ａｍａｚｏｎ ＥＣ２（Ａｍａｚｏｎ Ｅｌａｓｔｃｉ Ｃｏｍｐｕｔｅ Ｃｌｏｕｄ）（登録商標）等を採用してもよい。本実施形態におけるクラウド環境１０２は、例えばインターネットを経由して広くクラウドサービスを提供するパブリッククラウドであってもよく、特定の企業向けに構築されたプライベートクラウドであってもよい。

本実施形態におけるクラウド環境１０２を提供する図示しないクラウド事業者は、クラウド環境１０２が提供する仮想サーバ等のサービスを制御するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を規定する。クラウド環境１０２を利用するユーザ及びシステムは、当該ＡＰＩを外部から実行（実行するよう通知）することにより、クラウド環境１０２が提供する各種サービス及びリソース等を制御できる。クラウド環境１０２がインターネットを通じて利用するよう公開されている場合、係るＡＰＩは、例えば通信路にＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）あるいはＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）プロトコルを利用したＳＯＡＰメッセージ等をより提供されるよう構成してもよい。この場合、係るＡＰＩのユーザは、例えば、特定のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）に対してＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて記述したメッセージを送信することにより、係るＡＰＩが提供する機能を実行できる。以下において、クラウド環境１０２において規定される係るＡＰＩを、クラウドＡＰＩを称する場合がある。

待機系サーバ１０４は、例えば、クラウド環境１０２内に構築される仮想計算機（仮想サーバ）である。本実施形態における待機系サーバ１０４は、前記現用系サーバと通信可能に接続され、前記現用系サーバ１０３に何らかの事象（故障や障害等）が発生した際に、係る現用系サーバ１０３において実行されるサービス１０５を引き継ぐフェイルオーバ処理に対応する。

待機系サーバ１０４は、係るサービス１０５の実行環境と、当該サービス１０５関連するデータ等を保持するよう構成してもよい。なお、以下において、本実施形態における待機系サーバ１０４の実態である仮想計算機について、クラウド・インスタンスと称する場合がある。

本実施形態において、前記クラウド環境１０２のユーザ（あるいはシステム）は、係るクラウドＡＰＩを利用して、クラウド・インスタンスに対する各種制御を実行できる。本実施形態においては、係るクラウドＡＰＩを利用して、例えば、クラウド・インスタンスの起動及び終了や、クラウド・インスタンスのタイプの変更（性能が異なるクラウド・インスタンスへの変更）や、クラウド・インスタンスの状態に関する情報の取得などの処理を実行できる。

サービス１０５は、前記の通り現用系サーバ１０３あるいは待機系サーバ１０４において実行され、本実施形態におけるＨＡクラスタ１００の図示しないユーザ（及びシステム）に対して何らかの機能やリソースを提供する。本実施形態におけるサービス１０５は、例えば現用系サーバ１０３及び待機系サーバ１０４において実行可能なソフトウェア・プログラムとして構成してもよい。なお、図１及び図２においては、サービス１０５は１つのみ例示されているが、現用系サーバ１０３は、ＨＡクラスタ１００において提供する機能やリソースに応じて、サービス１０５を複数実行してもよい。

性能管理装置１０６は、図示しない管理者からの要求に基づいて、待機系サーバ１０４の性能管理を実行する、情報処理装置である。性能管理装置１０６は、前記現用系サーバと同様、物理的な構成を有する実コンピュータ等を用いて構成してもよく、仮想化された計算機を用いて仮想端末として構成してもよい。本実施形態における性能管理部１０６を実コンピュータとして構成する場合、図１８に例示するような汎用のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やマイクロプロセッサ等の演算装置及１８０１及び、当該演算装置から参照されるメモリ等の記憶装置１８０２等からなるハードウェアと、当該演算装置２１０１によって実行される各種ソフトウェア・プログラム（コンピュータ・プログラム）とによって構成してもよい。更に、上記各ソフトウェア・プログラムを外部記憶媒体１８０５に記録しておき、性能管理装置１０６の出荷段階、あるいは運用段階等において、適宜外部記憶装置１８０４を通じて当該ソフトウェア・プログラムを不揮発性メモリ１８０３に格納するよう構成してもよい。

本実施形態における性能管理装置１０６は、オンプレミス環境１０１内においては、ＬＡＮなどを通じて現用系サーバ１０３と通信可能に接続されており、クラウド環境１０２における待機系サーバ１０４とは、回線１０９を通じて通信可能に接続されている。なお、本実施形態には、係る性能管理装置１０６を図１に示すクラウド管理装置１１０と接続するよう構成し、係る性能管理装置から、クラウド管理装置１１０に対して待機系サーバ１０４に対する性能管理指示を送信する構成も含まれる。また、性能管理装置１０６は、後述する管理端末１０８と通信可能に接続されていてもよい。

本実施形態における性能管理装置１０６は、待機系サーバ１０４の性能を管理するための各種処理を実行し、待機系サーバ１０４の性能に関する状態を管理する、スケール管理部１０７を有する。本実施形態においては、スケール管理部１０７を、性能管理装置１０６により実行されるソフトウェア・プログラム（コンピュータ・プログラム）として構成してもよい。

なお、図１における性能管理装置１０６は、現用系サーバ１０３とは独立した構成として設けられているが、本実施形態は係る構成に限定されない。本実施形態においては、例えば図２に示すように、係る性能管理装置を、現用系サーバの一部を構成する性能管理部１０６ａとして設けてもよい。この場合、スケール管理部１０７は、現用系サーバにより実行されるソフトウェア・プログラムとして構成してもよい。本実施形態における性能管理装置１０６の具体的な処理については後述する。

管理端末１０８は、図示しない管理者からの各種管理要求を、前記性能管理装置１０６や、現用系サーバ１０３等に送信する情報処理端末である。管理端末１０８も、前記性能管理装置１０６と同様、物理的な構成を有する実コンピュータ等を用いて構成してもよく、仮想化された計算機を用いて仮想端末として構成してもよい。なお、本実施形態における管理者端末１０８は必須ではなく、管理者による管理要求を前記性能管理装置１０６や、現用系サーバ１０３等に伝達可能であれば、任意の手段や装置を用いて代用してもよい。

回線１０９は、オンプレミス環境１０１とクラウド環境１０２を通信可能に接続できる、任意の通信ネットワークであり、例えば、インターネット等の広域通信ネットワークを採用してもよい。

次に、上記のように構成された、本実施形態における情報処理装置の動作について説明する。以下においては、性能管理部１０６における処理を中心に、本実施形態におけるＨＡクラスタ１００のフェイルオーバ処理に必要となる、現用系サーバ１０３及び待機系サーバ１０４の制御について説明する。

まず、本実施形態おける、サービス１０５のフェイルオーバ処理の一例について説明する。本実施形態においては、現用系サーバ１０３の稼働中に故障や障害等のなんらかの事象が発生し、現用系サーバ１０３において前記サービス１０５の実行を継続できなくなった場合、現用系サーバ１０３及び待機系サーバ１０４は連携して、前記サービス１０５の処理を待機系サーバ１０４サーバに引き継いで実行するフェイルオーバ処理を実行する。

この場合、例えば、現用系サーバ１０３は、サービス１０５の実行状態及びデータ等を保存してサービス１０５を停止可能な状態とし、係る保存した実行状態及びデータ等を、待機系サーバ１０４に送信する。待機系サーバ１０４は、例えば、前記現用系サーバ１０３より受信した前記実行状態及びデータ等に基づいてサービス１０５を構成するソフトウェア・プログラムを起動して、サービス１０５による処理を続行する。なお、本実施形態にケルフェイルオーバ処理の具体的な処理手順は、上述した一例に限定されず、現用系サーバ１０３、待機系サーバ１０４、及びクラウド環境１０２の構成によって、適宜適切な方法を選択してよい。

次に、上記フェイルオーバ処理に関連した、本実施形態における待機系サーバ１０４の性能変更処理について説明する。前述したように、ＨＡシステム１００においては、運用コスト面における優位性と、各種リソースの拡張容易性の観点から、現用系サーバ１０３においてサービス１０５を実行する平常時には待機系サーバ１０４の性能を低くするよう制御し、前述したフェイルオーバ処理が発生した際には、待機系サーバ１０４の性能を、現用系サーバ１０３と同等水準まで高くするよう制御してもよい。以下、待機系サーバ１０４の具体的な性能変更手順の一例について、図３を参照して説明する。図３は、本実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。

まず、図示しないシステム管理者は、例えば、オンプレミス環境１０１に配置された管理端末１０８を通じて、待機系サーバ１０４に対する性能変更指示を、性能管理装置１０６に送信する（ステップＳ３０１）。本実施形態においては、例えば、管理端末１０８を構成するユーザインタフェース（ＵＩ：Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）装置を用いて、前記システム管理者が指示内容を入力したり、選択したりすることによって、係る性能変更指示を送信してもよい。また、前記性能変更指示は、例えば、性能変更の対象となる待機系サーバの指定や、変更するサーバの性能レベル等の変更情報を含んでもよい。なお、図１及び図２に例示する構成においては、待機系サーバ１０４が１台だけ図示されているが、本実施形態におけるＨＡクラスタ１００は、複数の待機系サーバを有してもよい。

性能管理装置１０６における、スケール管理部１０７は、管理端末より受信した前記性能変更指示を解析し、性能変更の対象となる待機系サーバ（本実施形態においては待機系サーバ１０４）の情報を特定する（ステップＳ３０２）。

次に、スケール管理部１０７は、現用系サーバ１０３と、性能変更の対象である、待機系サーバ１０４との連携を解除する（ステップＳ３０３）。本実施形態においては、スケール管理部１０７は、例えば、前記したサービス１０５のフェイルオーバ処理のための、現用系サーバ１０３と、待機系サーバ１０４との間の連携を解除してもよい。この場合、スケール管理部１０７は、例えば、係る現用系サーバ１０３と待機系サーバ１０４との間における、サービス１０５の実行状態や、サービス１０５に関連するデータの送受信を停止してもよい。また、スケール管理部１０７は、係る現用系サーバ１０３と待機系サーバ１０４との間で、前記フェイルオーバ処理が実行されないように制御してもよい。

次に、スケール管理部１０７は、前記ステップＳ３０２において特定した、性能変更の対象となる待機系サーバ１０４の性能を変更する（ステップＳ３０４）。本実施形態においては、スケール管理部１０７は、クラウド環境１０２や、待機系サーバ１０４の構成に応じて、適宜適切な方法を用いて係る待機系サーバ１０４の性能変更処理を実行する。スケール管理部１０７は、例えば、前述したクラウド環境１０２において規定されたクラウドＡＰＩを利用して、待機系サーバ１０４の性能を変更してもよい。スケール管理部１０７は、ステップＳ３０４における性能変更処理の実行後、係る処理の完了を待機してもよい。

次に、スケール管理部１０７は、前記ステップＳ３０３において解除した、現用系サーバ１０３と、待機系サーバ１０４との間の連携を回復する（ステップＳ３０５）。本実施形態においては、スケール管理部１０７は、例えば、前記サービス１０５のフェイルオーバ処理のための、現用系サーバ１０３と待機系サーバ１０４との間の連携を回復してもよい。

次に、スケール管理部１０７は、ステップＳ３０１において指示された待機系サーバ１０４に対する性能変更処理の完了を、図示しない管理者へ通知する（ステップＳ３０６）。本実施形態においては、スケール管理部１０７が、管理端末１０８に対して係る待機系サーバ１０４の性能変更処理の完了を通知し、管理端末１０８において、前記ＵＩに処理完了を表示するよう構成してもよい。以上説明した処理により、性能管理部１０６は、待機系サーバ１０４の性能管理を実行する。

上記説明においては、システム管理者が管理端末１０８を通じて待機系サーバ１０４の性能変更要求を送信しているが、本実施形態はこのような構成に限定されない。例えば、現用系サーバ１０３にいて何等かの事象が発生した場合、現用系サーバ１０３自身か、あるいは性能管理部１０６が当該事象の発生を検知し、サービス１０５のフェイルオーバの要否を判定し、係る判定結果に基づいて、待機系サーバ１０４の性能を管理するよう構成してもよい。

前記説明した待機系サーバ１０４の性能変更手順においては、性能管理装置１０６が待機系サーバ１０４を直接制御しているが、本実施形態はこのような構成に限定されない。本実施形態における性能管理装置１０６は、クラウド環境１０２において提供されるクラウド・インスタンスの管理手段を適宜適切に使用して、待機系サーバ１０４を制御する。例えば、前述したように、性能管理装置１０６とクラウド管理装置１１０とを通信可能に接続し、スケール管理部１０７から、当該クラウド管理装置１１０に対して、待機系サーバ１０４を制御するための制御指示を送信するよう構成してもよい。

以上説明した、本実施形態における性能管理措置１０６によれば、性能管理装置１０６を構成するスケール管理部１０７は、特定のサービス１０５を実行する現用系サーバ１０３と、係る現用系サーバ１０３と連携して当該サービス１０５をフェイルオーバ可能に構成された待機系サーバ１０４とに対して、特定の順序に従って管理操作を実行することにより、係る待機系サーバ１０４の性能を管理することができる。

このような処理により、本実施系における性能管理装置１０６によれば、ＨＡクラスタ１００を運用した状態で、クラウド環境１０２に用意された待機系サーバ１０４の性能を動的に変更することが可能であり、係る待機系サーバ１０４の性能変更処理の際に、ＨＡクラスタを構成する現用系サーバ１０３と、待機系サーバ１０４とに対する管理操作を、矛盾なく実行可能である、という効果を奏する。

なお、本実施形態における情報処理装置である性能管理装置１０６は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。

＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。以下の説明においては、本実施形態に係る特徴的な構成を中心に説明する。その際、前記第１の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明は省略する。

本実施形態における情報処理装置は、前記第１の実施形態における情報処理装置と基本的な構成は同様である。以下、図４を参照して、本実施形態における、性能管理部１０６ａ及びクラスタ制御部１１４の構成と動作を中心に説明する。

本実施形態における現用系サーバ１０３は、前記第１の実施形態における現用系サーバ１０３と、基本的な構成は同様である。本実施形態においては、現用系サーバ１０３は、スケール管理部１０７と、スケール変更部１１１と、クラスタ制御部１１４と、フェイルオーバ抑制部１１３と、記憶装置１１５と、を有する。また、本実施形態における現用系サーバは、前記第１の実施形態において説明したフェイルオーバ処理の対象となる、サービス１０５を実行する。以下、それぞれの構成要素について説明する。

まず、現用系サーバにおいて稼働するサービス１０５は、前記第１の実施形態同様、ユーザや他のシステムに対して何らかの機能やサービスを提供するソフトウェア・プログラムである。現用系サーバ１０３に障害や故障等の特定の事象が発生した場合、フェイルオーバ処理により、待機系サーバ１０４は、現用系サーバ１０３からサービス１０５の処理を引き継いで実行する。

記憶装置１１５は、現用系サーバ１０３を構成する記憶媒体であり、現用系サーバ１０３における各種処理に必要な各種データやソフトウェア・プログラム等を格納する。なお、記憶装置１１５は、現用系サーバ１０３を物理的なコンピュータ等の情報処理装置を用いて構成する場合には、ハードディスクドライブ等の磁気記憶装置や半導体記憶装置により構成してもよく、現用系サーバ１０３を仮想計算機として構成する場合には、当該仮想計算に割り当てられた記憶用リソースとして構成してもよい。なお、待機系サーバ１０４を構成する記憶媒体である記憶装置１１８についても、記憶装置１１５と同様の構成としてよい。

本実施形態における係る記憶装置１１５は、前記サービス１０５に関連するデータ１１５ａを記憶してもよい。データ１１５ａは、例えば現用系サーバ１０３において稼働するサービス１０５に関連する任意のデータであり、サービス１０５を稼働する際に随時更新されるようなデータも含まれてよい。本実施形態においては、現用系サーバ１０３におけるクラスタ制御部１１４（後述）と、待機系サーバ１０４におけるクラスタ制御部１１７が連携することにより、係るデータ１１５ａを、現用系サーバ１０３と、待機系サーバ１０４との間で複製（ミラーリング）するよう構成してもよい。例えば、現用系サーバ１０３におけるクラスタ制御部が記憶装置１１５を参照して、複製対象となるデータ１１５ａを選択し、係るデータ１１５ａをＷＡＮ回線１０９を通じて待機系サーバ１０４におけるクラスタ制御部１１７に送信し、待機系サーバ１０４におけるクラスタ制御部１１７が当該データを受信し、待機系サーバ１０４を構成する記憶装置１１８にデータ１１８ａとして記録するよう構成してもよい。

なお、本実施形態においては、待機系サーバ１０４の性能変更処理のために係る待機系サーバ１０４を停止する場合、現用系サーバ１０３は、係る待機系サーバ１０４の停止中にサービス１０５により更新されたデータ１１５ａを、記憶装置１１５に蓄積してもよい。この場合、係る待機系サーバ１０４が起動した後に、例えば、後述する現用系サーバ１０３におけるクラスタ制御部１１４及び待機系サーバ１０４におけるクラスタ制御部１１７は、記憶装置１１５に蓄積されたデータを記憶装置１１８に複製してもよい。

次に、本実施形態におけるクラスタ制御部１１４について説明する。本実施形態におけるクラスタ制御部１１４は、後述するスケール管理部１０７及びフェイルオーバ抑制部１１３と通信可能に接続され、サービス１０５の可用性を確保できるよう、ＨＡシステム１００の構成要素を制御する。このような構成要素の制御として、例えば、本実施形態におけるクラスタ制御部１１４は、サービス１０５についての前記フェイルオーバ処理を制御してもよい。この場合、本実施形態におけるクラスタ制御部１１４は、前記待機系サーバ１０４におけるクラスタ制御部１１７と連携して、前記ミラーリング処理の停止・再開や、現用系サーバ１０３と待機系サーバ１０４との連携の解除・回復等を制御してもよい。また、クラスタ制御部１１４は、ＨＡクラスタ１００において提供するサービスに関する情報（例えば、提供可能な全サービスに関する情報や、現用系サーバにて稼働中のサービスに関する情報など）を提供してもよい。

本実施形態におけるクラスタ制御部１１４は、クラスタ構成情報１１４ａを有してもよい。係るクラスタ構成情報１１４ａは、例えば、図７に例示するように、ＨＡクラスタ１００において提供するサービス１０５を識別する情報７０１（例えば識別名称等）と、係るサービス１０５を実行可能な待機系サーバ１０３を識別する情報７０２（例えば、サーバ名等）とを関連付ける情報を含んでもよい。なお、図７に例示した構成においては、サービス識別情報７０１と、待機系サーバ識別情報７０２とを１対１で関連付けているが、サービス識別情報７０１に対して、複数の待機系サーバ識別情報を関連付けるような構成としてもよい。

なお、図４に例示する構成においては、クラスタ構成情報１１４ａは、クラスタ制御部１１４の一部として設けられているが、現用系サーバ１０３の一部を構成する独立した構成要素として設けてもよく、ＨＡクラスタ１００を構成する任意の情報処理装置を構成する構成要素として設けてもよい。係る構成を採用する場合、クラスタ制御部１１４は、係る情報処理装置に設けられたクラスタ構成情報１１４ａを、ＨＡクラスタ１００を構成する通信ネットワークを経由して参照してもよい。

次に、本実施形態における性能管理部の構成について説明する。図４に例示するように、本実施形態においては、スケール管理部１０７、スケール変更部１１１、及びフェイルオーバ抑制部１１３により、性能管理部１０６ａを構成してもよい。なお、図４に例示する構成においては、性能管理部１０６ａは、現用系サーバ１０３の一部を構成するよう設けられているが、前記第１の実施形態と同様、現用系サーバ１０３とは別に独立した構成要素（例えば、物理的あるいは仮想的な計算機により構成した性能管理装置）として設けてもよい。

まず、本実施形態におけるスケール管理部１０７について説明する。図４に例示するように、本実施形態におけるスケール管理部１０７は、入出力インタフェース１０７ａ、スケール状態記憶部１０７ｂ、及びスケールレベル対応表１０７ｃを含む。スケール管理部１０７は、スケール状態記憶部１０７ｂを用いて待機系サーバ１０４の（現在の）性能に関する状態であるスケールレベルを管理し、入出力インタフェース１０７ａを介して管理端末１０８からの性能変更要求を受け付ける。また、スケール管理部１０７は、スケールレベル対応表１０７ｃを参照して、待機系サーバ１０４に対する性能変更処理を実行する。以下、本実施形態において、スケールレベルは、待機系サーバ１０４の実態であるクラウド・インスタンスの性能タイプ（以下インスタンスタイプと称することがある）を数値化した値を表す。なお、クラウド・インスタンスの性能タイプは、後述するように、クラウド環境１０２を提供する、図示しないクラウド事業者によって定義される。

上述したスケール管理部１０７の構成要素について、以下図５及び図６を参照して説明する。図５は、本実施形態におけるスケール状態記憶部１０７ｂの１つの構成例を例示する、模式図である。図６は、本実施形態におけるスケールレベル対応表１０７ｂの１つの構成例を例示する、模式図である。

本実施形態におけるスケール状態記憶部１０７ｂは、待機系サーバ１０３の現状のスケールレベル等を保持する記憶領域である。図５に例示するように、スケール状態記憶部１０７ｂは、例えば、待機系サーバ名５０１と、インスタンスＩＤ５０２と、待機系サーバの現在のスケールレベル５０３と、待機系サーバのスケールレベル変更状態（性能変更処理の状態）５０４と、スケールレベル対応表１０７ｃへの参照情報であるアドレス５０５とを有する、１つ以上のエントリ５０６を有するよう構成してもよい。待機系サーバが複数存在する場合、スケール状態記憶部１０７ｂには、待機サーバ毎に、係るエントリ５０６が設けられる。

待機系サーバ名５０１は、本実施形態におけるＨＡクラスタ１００を構成する待機系サーバを一意に特定する識別情報を表す。本実施形態における待機系サーバ名５０１としては、前記クラスタ構成情報１１４ａにおける、待機系サーバ識別情報と同じ情報を用いてもよい。

インスタンスＩＤ５０２は、待機系サーバ１０３の実態であるクラウド・インスタンスについて一意に割り振られた識別子（ＩＤ：ｉｄｅｎｔｉｆｉｅｒ）である。

スケールレベル５０３は、待機系サーバ１０３に設定されている、現在のスケールレベルであり、待機系サーバ１０３に現在設定されている性能を表す。

状態５０４は、待機系サーバ名５０１により識別される待機系サーバ１０３について、後述する、性能変更の処理を実行中か否かの状態を表す。例えば、スケール管理部１０７は、係る待機系サーバ１０３の性能を変更する処理を実行している場合は、状態５０４を”変更中”に設定し、変更処理を実行していない場合は”確定”に設定してもよい。

アドレス５０５は、各待機系サーバに関連付けされた、後述するスケールレベル対応表１０７ｃへの参照情報を表す。本実施形態においては、アドレス５０５には、係る待機系サーバ毎に関連付けされたスケールレベル対応表の保持領域に対するアドレスを含めてもよい。

なお、本実施形態において、スケール状態記憶部１０７ｂの情報は、システム管理者により設定されてもよく、あるいはＨＡクラスタ１００において待機系サーバ１０３を構成したり追加したりする場合に、自動的に設定されるよう構成してもよい。

次に、スケールレベル対応表１０７ｃについて説明する。本実施形態におけるスケールレベル対応表１０７ｃは、各クラウド事業者が提供するクラウド環境１０２におけるクラウド・インスタンスの性能タイプ（インスタンスタイプ）と、前記スケールレベルを関連付けて保持してもよい。図６に例示する構成においては、スケールレベル対応表１０７ｃは、例えば、クラウド事業者名６０１と、スケールレベル６０２と、インスタンスタイプ６０３と、緒元情報６０４と、を有する、１つ以上のエントリ６０５を有してもよい。

スケールレベル対応表１０７ｃは、クラウド事業者毎に提供されるインスタンスタイプの数に応じて前記エントリ６０５を複数保持してもよい。なお、スケールレベル対応表１０７ｃは、例えば、クラウド事業者毎に提供される全てのインスタンスタイプについて前記エントリ６０５を保持してもよく、オンプレミス環境１０１における現用系サーバ１０３の性能と比較して不要なインスタンスタイプについては前記エントリ６０５を保持しなくともよい。なお、本実施形態においては、システム管理者が、クラウド事業者ごとに係るスケールレベル対応表１０７ｃの内容を設定してもよい。

次に、図６におけるエントリ６０５の各構成要素について説明する。

クラウド事業者名６０１は、クラウド環境１０２を提供するクラウド事業者を識別可能な情報であり、例えば、クラウド事業者の名称や、クラウド事業者毎に割り当てたＩＤ等により表される。

スケールレベル６０２は、前述したように、各クラウド事業者によって提供されるクラウド・インスタンスの性能タイプを数値化した値を表す。スケールレベル６０２は、システム管理者が、後述するインスタンスタイプ６０３に基づいて適宜設定してもよい。

インスタンスタイプ６０３は、前述したように、クラウド事業者毎に定義される、クラウド・インスタンスの性能を表す性能タイプである。これらは、例えば性能が高い順に「ラージ」、「ミディアム」、「スモール」等と定義され、クラウド事業者毎に定義が異なってもよい。

緒元情報６０４は、インスタンスタイプ６０３毎に、クラウド・インスタンスの性能や当該クラウド・インスタンスの利用料などの情報を含む。緒元情報６０４は、クラウド・インスタンスに関する性能を表す情報として、例えば演算処理装置（ＣＰＵ）の性能に関する情報、メモリ容量、通信ネットワークの通信速度、記憶装置の容量等を含んでもよい。緒元情報６０４は、システム管理者による性能変更の判断材料として使用してもよいため、前記性能に関する情報以外に、判断基準となり得る任意の情報を含んでもよい。

本実施形態において、上記説明したスケール状態記憶部１０７ｂ及び、スケールレベル対応表１０７ｃは、それぞれ現用系サーバ１０３を構成する記憶装置の一部に格納されてもよい。また、スケール管理部１０７がソフトウェア・プログラムにより構成される場合、スケール状態記憶部１０７ｂ及び、スケールレベル対応表１０７ｃは、係るソフトウェア・プログラムが実行される際に、係るソフトウェア・プログラムから参照可能なように、メモリに読み込まれるように構成してもよい。

次に、本実施形態における入出力インタフェース１０７ａについて説明する。入出力インタフェース１０７ａは、前述したように、管理端末１０８と通信可能に接続され、管理端末１０８から送信される性能変更要求を受け付ける。本実施形態においては、例えば管理端末１０８と、現用系サーバ１０３との間を例えばＬＡＮ等のオンプレミス環境内の通信ネットワーク１１２により接続してもよい。入出力インタフェース１０７ａと、管理端末１０８の間の通信には専用の通信プロトコルを採用してもよく、あるいはＨＴＴＰやＨＴＴＰＳ等の汎用プロトコルを採用してもよい。

本実施形態における入出力インタフェース１０７ａは、管理者端末１０８からの性能変更要求に応じて、スケール状態記憶部１０７ｂ及びスケールレベル対応表１０７ｃを参照して、スケールレベル管理情報１０７ｄを生成し、係るスケールレベル管理情報１０７ｄを管理者端末１０８に通知する。

次に、本実施形態におけるスケールレベル管理情報１０７ｄは、図８に示すように、例えば、現用系サーバ１０３において稼働しているサービス１０５を識別する情報（サービス名）と、係るサービス１０５をフェイルオーバ可能な待機系サーバ１０４を表す待機系サーバ名と、係る待機系サーバ１０４の現在のスケールレベルと、係る待機系サーバ１０４について変更可能なスケールレベルの情報と、を有してもよい。本実施形態においては、入出力インタフェース１０７は、係るスケールレベル管理情報１０７ｄを、例えば、ＸＭＬにより表現してもよい。

次に本実施形態におけるスケール変更部１１１の構成について説明する。本実施形態におけるスケール変更部１１１は、クラウド環境１０４に設けられた後述するクラウド管理装置１１０と通信可能に接続されており、スケール管理部１０７からの性能変更要求を解析し、前記クラウドＡＰＩを利用して、クラウド管理装置１１０に対して待機系サーバ１０４の性能変更要求を送信する。本実施形態におけるスケール変更部１１１の具体的な動作については、後述する。

次に、本実施形態におけるフェイルオーバ抑制部１１３について説明する。本実施形態におけるフェイルオーバ抑制部１１３は、前記スケール管理部１０７及びクラスタ制御部１１４と通信可能に接続される。フェイルオーバ抑制部１１３は、前記スケール管理部１０７と連携して前記サービス１０５のフェイルオーバ処理の実行可否を判定し、係る判定結果に基づいて前記フェイルオーバ処理を抑制する。本実施形態におけるフェイルオーバ抑制部１１３の具体的な動作については、後述する。

なお、本実施形態においては、上述したスケール管理部１０７、スケール変更部１１１、クラスタ制御部１１４、及びフェイルオーバ抑制部１１３はそれぞれ相互に通信可能に接続されていてもよい。また、上述したスケール管理部１０７、スケール変更部１１１、クラスタ制御部１１４、及びフェイルオーバ抑制部１１３がソフトウェア・プログラムとして実装される場合、係るソフトウェア・プログラムは、例えば任意のプロセス間通信や共有メモリ等により、通信可能に接続されてもよい。

また、図４に例示した本実施形態の構成例においては、スケール管理部１０７、スケール変更１１１、クラスタ制御部１１４、フェイルオーバ抑制部１１３を、それぞれ独立した構成要素として例示しているが、本実施形態はこのような構成に限定されない。本実施形態においては、これらの構成要素について、少なくとも一部または全部の構成要素を統合したソフトウェア・プログラムを提供してもよく、これらの構成要素をどのように分割するかは、任意に定めて良い。

次に、本実施形態における管理端末１０８について説明する。本実施形態における管理端末は、前記第１の実施形態と同様、図示しない管理者からの待機系サーバ１０４に対する性能変更要求を受け付け、係る性能変更要求を入出力インタフェース１０７ｄに送信する。本実施形態においても、前記第１の実施形態と同様、管理端末１０８を構成するＵＩ装置を用いて、前記システム管理者が指示内容を入力したり、選択したりすることにより、係る性能変更指示を送信してもよい。

次に、本実施形態におけるクラウド管理装置１１０について説明する。クラウド管理装置１１０は、例えば、クラウド事業者によって、クラウド環境１０２に設けられてもよい。クラウド管理装置１１０は、前記スケール変更部１１１とＷＡＮ回線１０９を介して通信可能に接続されており、また、前記待機系サーバ１０４と、クラウド内通信ネットワーク１１９を介して通信可能に接続されている。本実施形態におけるクラウド管理装置１１０は、例えば、クラウド事業者により規定された前記クラウドＡＰＩの実行要求を受け付け、係る実行要求に基づいて前記クラウド・インスタンスに対する各種制御を実行してもよい。

次に、本実施形態におけるクラウド内通信ネットワーク１１９について説明する。クラウド内通信ネットワーク１１９は、クラウド環境１０２を提供するクラウド事業者が構築する通信ネットワークである。クラウド事業者は、係るクラウド内通信ネットワークを、インターネット等の広域通信ネットワーク、ＬＡＮ等の局所通信ネットワーク、及び専用線を用いた拠点間通信ネットワーク等を組み合わせて構成してもよい。

次に、上記のように構成された、本実施形態における情報処理装置の動作について説明する。以下においては、待機系サーバ１０４に対する性能変更処理と、フェイルオーバ処理について説明する。

まず、本実施形態における、待機系サーバ１０４に対する性能変更処理について説明する。以下、待機系サーバ１０４の具体的な性能変更手順の一例について、図９乃至図１３を参照して説明する。図９は、本実施形態における、待機サーバの性能変更処理の際に、管理端末に表示するＵＩの一例を表す模式図である。図１０乃至図１３は、本実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。

まず、図示しないシステム管理者は、管理端末１０８から待機系サーバ１０４に対する性能変更処理を開始する（ステップＳ１００１）。管理端末１０８は、性能変更処理の開始に際して、前記スケールレベル管理情報１０７ｄを取得するための出力要求を、入出力インタフェース１０７ａに対して送信する（ステップＳ１００２）。

次に、入出力インタフェース１０７ａは、前記ステップＳ１００２において送信された要求を解析し、スケールレベル管理情報１０７ｄを生成する（ステップＳ１００３）。

ステップＳ１００３において、まず、入出力インタフェース１０７ａは、クラスタ制御部１１４から、現用系サーバ１０３において稼働中のサービス一覧と、係るサービスのフェイルオーバ処理を実行可能な待機系サーバ１０４を識別する待機系サーバ識別情報とを取得する。本実施形態においては、クラスタ制御部１１４は、クラスタ制御部１１４において管理している稼働中のサービス１０５に関する情報と、クラスタ構成情報１１４ａを参照することにより、これらの情報を提供できる。

次に、入出力インタフェース１０７ａは、前記取得したサービス一覧と、係るサービスに関連するフェイルオーバ処理に対応する待機系サーバの識別情報とを用いて、スケール状態記憶部１０７ｂ及びスケールレベル対応表１０７ｃを参照して、係るサービス一覧に記録されたサービス毎に、スケールレベル管理情報１０７ｄを生成する。

次に、入出力インタフェース１０７ａは、前記ステップＳ１００３において生成したスケールレベル管理情報１０７ｄを、管理端末１０８に通知する（ステップＳ１００４）。

次に、管理端末１０８は、前記ステップＳ１００４において通知されたスケールレベル管理情報１０７ｄに基づいて、システム管理者に対して、図示しないＵＩ装置により、各待機サーバに対する性能変更処理のためのＵＩを提供する（ステップＳ１００５）。図９は、本実施形態において管理端末１０８において表示するＵＩの一例を示す、模式図である。

図９に示すように、本実施形態におけるＵＩ９０１は、現用系サーバ１０３において稼働中のサービス一覧９０２と、係る一覧に表示された各サービスのフェイルオーバ処理を実行可能な待機系サーバ１０４の一覧９０３と、待機系サーバ毎のスケール一覧９０４と、変更指示操作部９０５とを含む。

本実施形態においては、変更指示操作部９０５は、例えば、押下可能なボタン表示等であってもよい。本実施形態においては、例えば、管理者端末１０８は、ＵＩ９０１を係る管理端末１０８に接続される図示しないディスプレイ装置に表示してもよい。

なお、本実施形態における管理端末１０８は、図９に例示した表示に限らず、入出力インタフェース１０７ａより受信したスケールレベル管理情報１０７ｄに基づいて、任意の形式でＵＩ表示を提供してよい。また、本実施形態における管理端末１０８は、係るＵＩ表示において、前記受信したスケールレベル管理情報１０７ｄの一部の情報を加工したり、省略したりしてもよい。

次に、図示しない管理者は、係るＵＩ９０１を確認しながら、管理端末１０８に接続される図示しない操作手段（例えば、キーボードやマウス等）により、変更指示操作部９０５を操作し、特定の待機系サーバ１０４に対する性能の変更を指示する（ステップＳ１００６）。本実施形態においては、例えば、変更指示操作部９０５がボタン表示であった場合は、管理者が当該ボタンを押下することで、待機系サーバに対する性能の変更を指示してもよい。

前記ステップ１００６における、管理者からの性能変更の指示により、管理端末１０８は、入出力インタフェース１０７ａに対して、特定の管理サーバ１０４に対する性能変更指示と共に、係る性能変更のために必要な情報（例えば、係る待機系サーバを識別する待機系サーバ名、インスタンスＩＤ，変更後のスケールレベル及び変更後のインスタンスタイプ等）を送信する。

次に、スケール管理部１０７において、管理端末１０８から、待機サーバ１０４に対する性能変更の要求を受け付けた後の処理について、図１１乃至図１３を参照して説明する。なお、以下においては、特定の待機系サーバ１０４に対する性能変更の指示を、スケール変更指示と称する場合がある。

まず、入出力インタフェース１０７ａは、管理端末１０８より、特定の待機系サーバ１０４に対するスケール変更指示を受信する（ステップＳ１１０１）。入出力インタフェース１０７ａは、係るスケール変更指示を解析し、係る変更指示に含まれる待機系サーバ名、インスタンスＩＤ，変更後のスケールレベル及び変更後のインスタンスタイプ等を抽出する。

次に、スケール管理部１０７は、受信したスケール変更指示に含まれる待機系サーバ名を用いて、スケール状態記憶部１０７ｂを参照し、係るサーバ名に関連するエントリ５０６における状態５０４を、”変更中”に更新する（ステップＳ１１０２）。

スケール管理部１０７は、入出力インタフェース１０７ａに対して係る状態５０４を通知し（ステップＳ１１０３）、入出力インタフェース１０７ａは、管理端末１０８に対して係る状態を更新するよう通知してもよい。

次に、スケール管理部１０７は、スケール変更部１１１に対して、スケール変更要求を通知する。当該スケール変更要求に応じて、スケール変更処理部１１１は、クラスタ制御部１１４及びクラウド管理部装置１１０と連携して、スケール変更指示において指定された特定の待機系サーバ１０４に対する性能変更の処理を実行する（ステップＳ１１０４）。以下、スケール変更部１１１における処理について図１２を参照して説明する。

まず、スケール変更部１１１は、現用系サーバ１０３と性能変更の対象となる特定の待機系サーバ１０４との間で、サービス１０５に関連するデータのミラーリング処理を実行している場合、係るミラーリング処理を停止するよう、クラスタ制御部１１４に通知する（ステップＳ１２０１）。

次に、スケール変更部１１１は、クラスタ制御部に１１４に対して、現用系サーバ１０３と性能変更の対象となる特定の待機系サーバ１０４との間の連携を解除し、切離するよう通知する（ステップＳ１２０２）。これにより、現用系サーバ１０３と係る待機系サーバ１０４との間における、不用意なフェイルオーバ処理の発生を抑止する。

次に、スケール変更部１１１は、クラウド環境１０２に用意されているクラウド管理装置１１０に対して、性能変更の対象となる特定の待機系サーバ１０４の実態である、クラウド・インスタンスのスケール変更を要求する（ステップＳ１２０３）。なお、以下、係るクラウド・インスタンスを、性能変更対象であるインスタンスと称する場合がある。

本実施形態においては、スケール変更部１１１は、クラウド管理装置１１０に対して、前述したクラウド環境１０２において規定されるクラウドＡＰＩを実行することにより、係る性能変更対象であるインスタンスに対するスケール変更要求を実行する。以下、スケール変更部１１１によるスケール変更要求の処理について、図１３を参照して説明する。

まず、スケール変更部１１１は、インスタンスを停止するクラウドＡＰＩを実行し、性能変更対象であるインスタンスを停止する（ステップＳ１３０１）。具体的には、スケール変更部１１１は、前記スケール変更要求に含まれるインスタンスＩＤを指定して、当該ＩＤにより識別可能なクラウド・インスタンスを停止するクラウドＡＰＩを実行してもよい。

次に、スケール変更部１１１は、インスタンス状態を取得するクラウドＡＰＩを実行し、性能変更対象であるインスタンスの停止状態を確認する（ステップＳ１３０２乃至ステップ１３０３）。具体的には、スケール変更部１１１は、前記スケール変更要求に含まれるインスタンスＩＤを指定して、当該ＩＤにより識別可能なクラウド・インスタンスの状態を取得するクラウドＡＰＩを実行してもよい。

次に、スケール変更部１１１は、インスタンスの停止状態を確認した後（ステップＳ１３０３においてＹＥＳの場合）、インスタンスタイプを修正するクラウドＡＰＩを実行し、性能変更対象であるインスタンスにおけるインスタンスタイプを変更する（ステップＳ１３０４）。具体的には、スケール変更部１１１は、前記スケール変更要求に含まれるインスタンスＩＤ及びインスタンスタイプを指定して、当該ＩＤにより識別可能なクラウド・インスタンスのインスタンスタイプを、前記スケール変更要求に含まれるインスタンスタイプに変更するクラウドＡＰＩを実行してもよい。

次に、スケール変更部１１１は、インスタンス起動を起動するクラウドＡＰＩを実行し、性能変更対象であるインスタンスを起動する（ステップＳ１３０５）。具体的には、スケール変更部１１１は、前記スケール変更要求に含まれるインスタンスＩＤを指定して、当該ＩＤにより識別可能なクラウド・インスタンスを起動するクラウドＡＰＩを実行してもよい。

次に、スケール変更部１１１は、インスタンス状態を取得するクラウドＡＰＩを実行し、性能変更対象であるインスタンスの起動状態を確認する（ステップＳ１３０６乃至ステップ１３０７）。スケール変更部１１１は性能変更対象であるインスタンスの起動を確認し（ステップＳ１３０７においてＹＥＳ）、クラウド管理装置１１０に対するスケール変更処理を終了し、図１２におけるステップＳ１２０４から処理を続行する。

次に、スケール変更部１１１は、クラスタ制御部１１４に対して、ステップＳ１２０３において性能変更処理が完了した特定の待機系サーバ１０４の復帰を要求する（ステップＳ１２０４）。本実施形態においては、スケール変更部１１１は、サービス１０５のフェイルオーバ処理が可能なように、係る特定の待機系サーバ１０４と現用系サーバ１０３との間の連携を再開するよう、クラスタ制御部１１４に通知してもよい。

次に、スケール変更部１１１は、前記ステップＳ１２０１において停止したミラーリング処理を再開するよう、クラスタ制御部１１４に通知する（ステップＳ１２０５）。

次に、スケール変更部１１１は、前記性能変更の対象である特定の待機系サーバ１０４の停止から起動までの間に、現用系サーバ１０３におけるサービス１０５の処理により蓄積されたデータ１１５ａが、現用系サーバ１０３と係る待機系サーバ１０４との間で同期されたか確認する（ステップＳ１２０６）。

係る同期処理が完了し、待機系サーバ１０４がＨＡクラスタ１００復帰した場合（ステップＳ１２０７においてＹＥＳ）、スケール変更部１１１は性能変更処理を終了し、スケール管理部１０７がステップＳ１１０５より処理を継続する。なお、スケール変更部１１１は、上述したスケール変更処理の結果を、スケール管理部１０７に通知してもよい。

スケール管理部１０７は、スケール状態記憶部１０７ｂを参照し、上記において性能変更処理の対象となった特定の待機系サーバに関連するエントリ５０６を抽出し、かかるエントリ５０６における状態５０４を”確定”に更新し、スケールレベル５０３を変更後のスケールレベル値に更新する（ステップＳ１１０５）。

スケール管理部１０７は、入出力インタフェース１０７ａに対して、係る状態５０４と変更後のスケールレベル５０３と共に、スケール変更完了を通知する（ステップＳ１１０６）。入出力インタフェース１０７ａは、管理端末１０８に対して係るスケール変更完了を通知するよう構成してもよい。

なお、上記説明においては、スケール状態記憶部１０７ｂ及びスケールレベル対応表１０７ｃの参照や更新は、スケール管理部１０７が実行するが、本実施形態はこのような構成に限定されない。本実施形態において、係るスケール状態記憶部１０７ｂ及びスケールレベル対応表１０７ｃの参照および更新は、例えばスケール変更部１１１が実行してもよい。

以上説明した処理により、本実施形態における情報処理装置によれば、現用系サーバ１０３において実行されるサービス１０５のフェイルオーバ処理に対応可能な待機系サーバ１０４の性能を変更することが可能である。

次に、上記のように構成された現用系サーバ１０３と、待機系サーバ１０４におけるフェイルオーバ処理について説明する。以下、本実施形態におけるフェイルオーバ処理の処理について図１４及び図１５を参照して説明する。図１４及び図１５は、本実施形態におけるフェイルオーバ処理の一例を例示する、フローチャートである。

まず、現用系サーバ１０３におけるクラスタ制御部１１４は、現用系サーバ１０３内に故障や障害等の特定の事象が発生したことを検知し、フェイルオーバ処理を開始する。

クラスタ制御部１１４は、フェイルオーバ抑制部１１３に対して、サービス１０５のフェイルオーバ処理を実行可能か否かの確認を要求する（ステップＳ１４０１）。具体的には、クラスタ制御部１１４は、クラスタ構成情報１１４ａを参照して、サービス１０５をフェイルオーバ可能な待機系サーバ名を取得し、係る待機系サーバ名を指定して、フェイルオーバ抑制部に対してフェイルオーバ処理の実行可否の確認を要求する。

以下、フェイルオーバ抑制部１１３における処理（ステップＳ１４０２）について図１５を参照して説明する。

フェイルオーバ抑制部１１３は、まず、スケール状態記憶部１０７ｂを参照して、前記ステップＳ１４０１において指定された待機系サーバ名に対応するエントリ５０６を抽出し、係るエントリ５０６における状態５０４を取得する（ステップＳ１５０１）。なお、本実施形態においては、フェイルオーバ抑制部１１３は、直接スケール状態記憶部１０７ｂを参照してもよく、スケール管理部１０７に対して前記ステップＳ１４０１において指定された待機系サーバ名を通知して、係るサーバ名に対応する状態５０４の取得を要求してもよい。

次に、フェイルオーバ抑制部１１３は、ステップＳ１５０１において取得した状態５０４を確認し（ステップＳ１５０２）、係る状態５０４が”確定”の場合（ステップＳ１５０２においてＹＥＳ）、クラスタ制御部１１４に対してフェイルオーバ処理の許可を通知する。

ステップＳ１５０２において、係る状態５０４が”確定”ではない場合（係るサーバ名により指定された待機サーバ１０４について、性能変更処理が実行されている場合、ステップＳ１５０２においてＮＯ）、フェイルオーバ抑制部１１３は、フェイルオーバ処理を抑制するため、クラスタ制御部１１４への応答を遅延させ、一定時間の経過の後（ステップＳ１５０４）、再度ステップＳ１５０１から処理を続行する。フェイルオーバ抑制部１１３は、ステップＳ１５０２における状態の確認結果が”確定”となるまで、ステップＳ１５０１乃至ステップＳ１５０４の処理を繰り返す。

クラスタ制御部１１４は、フェイルオーバ抑制部１１３におけるフェイルオーバ抑制処理の後、フェイルオーバ抑制部からフェイルオーバ許可の応答を受信し（ステップＳ１４０３）、待機系サーバ１０４におけるクラスタ制御部１１７に対して、フェイルオーバ処理の開始を通知し（ステップＳ１４０４）、当該クラスタ制御部１１７と連携して、サービス１０５のフェイルオーバ処理を実行する（ステップＳ１４０５）。

なお、本実施形態において、特定のサービス１０５をフェイルオーバ可能な待機系サーバ１０４が複数存在する場合、フェイルオーバ抑制部１１３は、それぞれの待機系サーバについてフェイルオーバ処理を実行可能か否か問い合わせて、フェイルオーバ処理を実行可能な待機系サーバの情報をクラスタ制御部に通知するよう構成してもよい。

以上説明した処理により、本実施形態における情報処理装置によれば、待機系サーバ１０４の性能を変更する処理が実行されている間は、係る待機系サーバ１０４に対するフェイルオーバ処理が抑制されるため、不要なフェイルオーバの発生や、フェイルオーバの失敗によるサービスの停止を防ぐことができる。

以上説明した通り、本実施形態におけるスケール管理部１０７は、特定の待機系サーバ１０４に対する性能変更要求に対応して、クラスタ制御部１１４と連携して現用系サーバ１０３と待機系サーバ１０４との連携を解除し、スケール変更部１１１と連携して具体的な性能変更要求をクラウド管理装置１１０に送信する。

このように、本実施形態によれば、オンプレミス環境１０１に構築される現用系サーバ１０３と、クラウド環境１０２に構築される待機系サーバ１０４とに対して、特定の順序に従って管理操作を実行することにより、管理者は、ＨＡクラスタ１００を運用した状態で、クラウド環境１０２に用意された待機系サーバ１０４の性能を動的に変更することが可能である。

また、本実施形態によれば、管理者は、係る待機系サーバ１０４の性能変更処理の際に、ＨＡクラスタを構成する現用系サーバ１０３と、待機系サーバ１０４とに対する管理操作を、矛盾なく実行可能である、という効果を奏する。

更に、本実施形態においては、クラスタ制御部１１４は、特定の待機系サーバ１０４について性能変更処理が実行されているか否かを確認した結果に基づいて、フェイルオーバ処理を実行するため、不要なフェイルオーバの発生や、フェイルオーバの失敗によるサービスの停止を防ぐことができるという効果を奏する。

なお、本実施形態における情報処理装置は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。

＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。以下の説明においては、本実施形態に係る特徴的な構成を中心に説明する。その際、前記第１及び第２の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明は省略する。

本実施形態における情報処理装置は、前記第２の実施形態における情報処理装置と基本的な構成は同様であるが、現用系サーバ１０３を１台、待機系サーバを２台とした３つのノードにより、ＨＡクラスタ１００を構成している。以下、図１６を参照して、本発明の第３の実施形態について説明する。

本実施形態における現用系サーバ１０３は、前記第２の実施形態における現用系サーバ１０３と基本的な構成は同一である。本実施形態における現用系サーバ１０３は、サービス１６０１及びサービス１６０２を実行し、係るサービスに関連するデータ１６０３ａ及びデータ１６０４ａを、それぞれ記憶装置１６０３及び記憶装置１６０４に記録する。なお、図１６に例示した構成においては、記憶装置１６０３及び記憶装置１６０４をそれぞれ独立した構成要素としているが、これらを統合して一つの記憶装置とし、データ１６０３ａ及びデータ１６０４ａを記録するよう構成してもよい。

本実施形態においては、サービス１６０１のフェイルオーバに対応する待機系サーバとしてクラウド環境１６０５に待機系サーバ１６０７を設け、サービス１６０２のフェイルオーバに対応する待機系サーバとしてクラウド環境１６０６に待機系サーバ１６０８を設ける。なお、クラウド環境１６０５とクラウド環境１６０６は同一のクラウド事業者により提供されてもよく、異なるクラウド事業者により提供されてもよい。

待機系サーバ１６０７及び、待機系サーバ１６０８は、それぞれサービス１６０１に関するデータ１６０３ａ及び、サービス１６０２に関するデータ１６０４ａをミラーリング可能な記憶装置１６０９及び記憶装置１６１０を備える。現用系サーバ１０３におけるクラスタ制御部１１４と、待機系サーバ１６０７におけるクラスタ制御部１６１３は、サービス１６０１に関係するデータ１６０３ａを、データ１６０９ａにミラーリングすると共に、現用系サーバ１０３に故障等の特定の事象が発生した際には、サービス１６０１を待機系サーバ１６０７において引き継いで実行するよう連携する。現用系サーバ１０３におけるクラスタ制御部１１４と、待機系サーバ１６０８におけるクラスタ制御部１６１４も同様に、サービス１６０２に関係するデータ１６０４ａを、データ１６１０ａにミラーリングすると共に、現用系サーバ１０３に故障等の特定の事象が発生した際には、サービス１６０２を待機系サーバ１６０８において引き継いで実行するよう連携する。

また、前記第２の実施形態と同様、管理端末１１０よりスケール管理部１０７に対してスケール変更指示を送信することにより、スケール変更部１１１がクラウド環境１６０５におけるクラウド管理装置１６１１と、クラウド環境１６０６におけるクラウド管理装置１６１２に対してスケール変更要求を送信し、各待機系サーバ１６０７及び１６０８の性能を変更できる。

上述した本実施形態によれば、複数のサービスに対して異なる運用方針を策定することにより、それぞれのサービスに関連付けされた待機系サーバのスケールレベル（性能）を個別に管理し、変更できる。このため、本実施形態に依れば、前記第２の実施形態と同様の効果を奏すると共に、運用コストの一層の低減や、サービスに対するフェイルオーバ処理の信頼性向上等の効果を奏する。

なお、図１６に例示した構成においては、２つのサービス１６０１、１６０２に対して、２つの待機系サーバ１６０７、１６０８を用意しているが、本実施形態はこのような構成に限定されない。例えば、現用系サーバにおいて実行するサービスの数と、フェイルオーバ処理のために用意する待機系サーバの数は２つでなくともよく、また、これらの数が異なってもよい。現用系サーバにおいて実行するサービスの数よりも、フェイルオーバ処理が可能な待機系サーバの数が多ければ、サービスの稼働状態に対する信頼性を向上できる。現用系サーバにおいて実行するサービスの数よりも、フェイルオーバ処理が可能な待機系サーバの数が少なければ、運用コストを更に低減できる。

なお、本実施形態における性能管理部１０６ａを実現する情報処理装置は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。

＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。以下の説明においては、本実施形態に係る特徴的な構成を中心に説明する。その際、前記第１乃至第３の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明は省略する。

本実施形態における情報処理装置は、前記第２の実施形態における情報処理装置と基本的な構成は同様であるが、前記第２の実施形態における管理端末１０８の代替として、性能管理部１７０１が組み合わされている。

本実施形態における性能管理部１７０１は、オンプレミス環境１０１に構築される現用系サーバ１０３における各種情報（性能情報や、発生したイベント情報等）を収集して分析することにより、現用系サーバ１０３に発生する障害の傾向を予測する。具体的には、性能管理部１７０１は、例えば現用系サーバを構成する演算処理装置（ＣＰＵ）やメモリの使用率、記憶装置に対するアクセス回数と書き込みや読み込みの総データサイズ、通信ネットワークアクセス回数と総通信データサイズ、現用系サーバ１０３自体の連続稼働時間等の情報を収集し、係る収集したデータに対して統計処理等を実施することにより、現用系サーバを構成する要素にどのようは障害が発生するか予測してもよい。

本実施形態においては、管理者は、例えば、スケールレベル対応表１０７ｃにおけるエントリ６０５として、”平常時のレベル”（現用系サーバ１０３よりも性能が低いレベル）と、”フェイルオーバ対応レベル”（現用系サーバ１０３と同等の性能レベル）を設定してよい。

本実施形態において、性能分析部１７０１は、前記現用系サーバ１０３に対する障害発生の傾向分析の結果、障害傾向にある（障害が発生する蓋然性がある程度高い）と判定した場合には、スケール管理部１０７に対して、待機系サーバ１０４の性能レベルを前記”フェイルオーバ対応レベル”に変更するように、変更指示を送信する。また、性能分析部１７０１は、係る障害傾向が収まったと判定した場合には、スケール管理部１０７に対して、待機系サーバ１０４の性能レベルを前記”平常時のレベル”に変更するように、変更指示を送信する。

以上説明した本実施形態によれば、オンプレミス環境に構築した現用系サーバ１０３の障害傾向に応じて、クラウド環境１０２に構築した待機系サーバ１０４の性能を動的に変更できるため、現用系サーバ１０３において障害が発生した際には迅速にフェイルオーバ処理が可能であり、かつ平常時には運用コストをできる、という効果を奏する。

なお、本実施形態における性能管理部１７０１による障害傾向の予測は、前記例示に限定されず、現用系サーバ１０３の構成等に応じて、適宜適切な方法を採用してよい。

本実施形態における情報処理装置は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。

＜第５の実施形態＞
次に、上述した各実施形態に共通する構成について、本発明の第５の実施形態として、図１９を参照して説明する。図１９は、本発明の第５の実施形態における情報処理装置の機能的な構成を例示するブロック図である。

図１９に示すように、本実施形態における第１の情報処理システム１９０１は、サービス１９０５を実行する第１の情報処理部１９０４を有する。

本実施形態における第１の情報処理部１９０４は、第２の情報処理システム１９０２と通信可能に接続される。なお、本実施形態においては、第１の情報処理システム１９０１と、第２の情報処理システム１９０２とが、通信可能に接続されてもよい。

本実施形態における第２の情報処理システム１９０２は、第２の情報処理部１９０６を有する。本実施形態においては、第２の情報処理システム１９０２は、第２の情報処理部１９０６の性能を管理できる。

本実施形態における第２の情報処理部１９０６は、前記第１の情報処理システム１９０１において特定の事象（例えば、障害や故障等）が発生した際に、前記サービス１９０５の実行を、前記第１の情報処理部１９０４から引き継ぐ。

本実施形態における情報処理装置１９０３は、前記第２の情報処理システムに対して管理操作を実行する性能管理部１９０３ａを有する。

本実施形態において、前記性能管理部１９０３ａは、第２の情報処理システム１９０２に対して、特定の順序に従って管理操作を実行することにより、第２の情報処理部１９０６の性能を管理する。係る管理操作には、例えば、第２の情報処理部１９０６の性能を変更する処理を含めてもよい。なお、本実施形態における性能管理部１９０３ａは、例えば、前記第１の情報処理システム１９０１と通信可能に接続されてもよく、前記第２の情報処理システム１９０２に対する管理操作と共に、前記第１の情報処理部１９０１に対する管理操作を実行してもよい。

上記説明した処理により、本実施系における情報処理装置１９０３によれば、第１の情報システム１９０１及び第２の情報システム１９０２を運用した状態で、第２の情報処理部１９０６の性能を管理することが可能である。また、係る第２の情報処理部１９０６の性能を管理する処理の際に、少なくとも、当該第２の情報処理部１９０６に対する前記管理操作を矛盾なく実行可能である、という効果を奏する。

なお、図１９に例示した構成においては、本実施形態における情報処理装置１９０３は、前記第１の情報処理システム１９０１とは別の独立した構成要素として図示されているが、本実施形態はこのような構成に限定されない。本実施形態においては、例えば情報処理装置１９０３は、第１の情報処理システム１９０１や、第１の情報処理部１９０４を構成する構成要素として設けてもよい。

以上、本発明を、上述した模範的な実施形態に適用した例として説明した。しかしながら、本発明の技術的範囲は、上述した各実施形態に記載した範囲には限定されない。当業者には、係る実施形態に対して多様な変更または改良を加えることが可能であることは明らかである。そのような場合、係る変更または改良を加えた新たな実施形態も、本発明の技術的範囲に含まれ得る。そしてこのことは、特許請求の範囲に記載した事項から明らかである。

尚、上述した実施形態及びその変形例の一部または全部は、以下の付記のようにも記載されうる。しかしながら、上述した実施形態及びその変形例により例示的に説明した本発明は、以下には限られない。

（付記１）
特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する性能管理部を有する、
情報処理装置。

（付記２）
前記性能管理部は、
前記第１の情報処理部と、前記第２の情報処理部と間の連携を解除し、
前記第２の情報処理部の性能を変更する性能変更処理を実行する、
付記１に記載の情報システムの管理装置。

(付記３）
前記性能管理部は、前記第２の情報処理部の性能に関する情報を含むスケールレベル設定情報に基づいて、前記性能変更処理を実行する、
付記２に記載の、情報処理装置。

（付記４）
前記性能管理部は、前記第２の情報処理部に対する前記性能変更処理を実行する際、当該性能変更処理の実行状態を含むスケール状態情報を更新する、
付記２または付記３に記載の、情報処理装置。

（付記５）
前記第２の情報処理システムが、１以上の仮想計算機を有し、当該仮想計算機を管理する管理要求を受け付ける仮想計算機環境を提供する場合に、
前記性能管理部は、前記第２の情報処理システムに対して、前記第２の情報処理システムを構成する仮想計算機である前記第２の情報処理部の処理性能を変更する管理要求を送信する、
付記２乃至付記４の何れかに記載の、情報処理装置。

（付記６）
前記性能管理部は、
前記第１の情報処理部における、前記特定のサービスに関するサービス関連情報を前記第２の情報処理部に複製する処理を停止し、
前記第１の情報処理部と、前記第２の情報処理部との間の前記フェイルオーバ処理のための連携を解除し、
前記第２の情報処理システムに対して、前記第２の情報処理部の処理性能を変更する管理要求を送信する、
付記５に記載の、情報処理装置。

（付記７）
前記第２の情報処理部の処理性能を変更する管理要求は、少なくとも、
前記第２の情報処理部を停止する要求と、
前記第２の情報処理部の性能を変更する要求と、
前記第２の情報処理部の状態を取得する要求と、
を含む、
付記５または付記６に記載の情報処理装置。

（付記８）
前記スケール状態情報を参照して前記性能管理部において前記第２の情報処理部の性能変更処理を実行中であるか否かを確認し、前記確認の結果、前記性能変更処理を実行中であると判定した場合、前記性能変更処理が完了するまで前記フェイルオーバ処理の実行を抑制するフェイルオーバ抑制部を、更に有する、
付記４乃至付記７の何れかに記載の情報処理装置。

（付記９）
前記第１の情報処理部が、複数の前記サービスを実行し、当該複数のサービスそれぞれに対して前記フェイルオーバ処理を実行する少なくとも１以上の前記第２の情報処理部を有する、少なくとも１以上の前記第２の情報処理システムが存在する場合に、
前記性能管理部は、当該第２の情報処理システムに対して、前記第２の情報処理部の処理性能を変更する管理要求を送信する、
付記５乃至付記８のいずれかに記載の情報処理装置。

（付記１０）
前記第１の情報処理システムが、前記第１の情報処理システムにおいて発生し得る障害の傾向を分析し、当該分析結果に基づいて、前記第２の情報処理部の性能を変更する要求を前記性能管理部に送信する性能分析部を有する場合に、
前記性能管理部は、前記性能分析部から送信される要求に応じて、前記第２の情報処理部に対する前記性能変更処理を実行する、
付記５乃至付記９のいずれかに記載の情報処理装置。

（付記１１）
前記第２の情報処理システムと、に通信可能に接続され、
前記第２の情報処理システムと通信可能に接続される前記第１の情報処理部の一部を構成するか、または当該第1の情報処理部と通信可能に接続される、
付記１乃至付記１０に記載の情報システムの管理装置。

（付記１２）
特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する
情報処理方法。

（付記１３）
情報処理プログラムであって、
特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する処理を、コンピュータに実行させる、
プログラム。

本発明は、現用系システムに障害等が発生した場合に、現用系システムの処理を待機系システムに引き継いで実行する高可用性システム等に適応できる。

１００ ＨＡクラスタ
１０１ オンプレミス環境
１０２ クラウド環境
１０３ 現用系サーバ
１０４ 待機系サーバ
１０５ サービス
１０６ 性能管理装置
１０７ スケール管理部
１０８ 管理端末
１０９ 回線
１１０ クラウド管理装置
１１１ スケール変更部
１１２ 通信ネットワーク
１１３ フェイルオーバ抑制部
１１４ クラスタ制御部
１１５ 記憶装置
１１７ クラスタ制御部
１１８ 記憶装置
１１９ クラウド内通信ネットワーク
１６０１ サービス
１６０２ サービス
１６０３ 記憶装置
１６０４ 記憶装置
１６０５ クラウド環境
１６０６ クラウド環境
１６０７ 待機系サーバ
１６０８ 待機系サーバ
１６０９ 記憶装置
１６１０ 記憶装置
１６１１ クラウド管理装置
１６１２ クラウド管理装置
１６１３ クラスタ制御部
１６１４ クラスタ制御部
１７０１ 性能分析部

Claims (10)

1. 特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する性能管理部を有する、
   情報処理装置。
2. 前記性能管理部は、前記第２の情報処理部の性能に関する情報を含むスケールレベル設定情報に基づいて、前記性能変更処理を実行する、
   請求項１に記載の、情報処理装置。
3. 前記性能管理部は、前記第２の情報処理部に対する前記性能変更処理を実行する際、当該性能変更処理の実行状態を含むスケール状態情報を更新する、
   請求項１または請求項２に記載の、情報処理装置。
4. 前記第２の情報処理システムが、１以上の仮想計算機を有し、当該仮想計算機を管理する管理要求を受け付ける仮想計算機環境を提供する場合に、
   前記性能管理部は、前記第２の情報処理システムに対して、前記第２の情報処理システムを構成する仮想計算機である前記第２の情報処理部の処理性能を変更する管理要求を送信する、
   請求項２または請求項３の何れかに記載の、情報処理装置。
5. 前記性能管理部は、
   前記第１の情報処理部における、前記特定のサービスに関するサービス関連情報を前記第２の情報処理部に複製する処理を停止し、
   前記第１の情報処理部と、前記第２の情報処理部との間の前記フェイルオーバ処理のための連携を解除し、
   前記第２の情報処理システムに対して、前記第２の情報処理部の処理性能を変更する管理要求を送信する、
   請求項４に記載の、情報処理装置。
6. 前記第２の情報処理部の処理性能を変更する管理要求は、少なくとも、
   前記第２の情報処理部を停止する要求と、
   前記第２の情報処理部の性能を変更する要求と、
   前記第２の情報処理部の状態を取得する要求と、
   を含む、
   請求項４または請求項５に記載の情報処理装置。
7. 前記スケール状態情報を参照して前記性能管理部において前記第２の情報処理部の性能変更処理を実行中であるか否かを確認し、前記確認の結果、前記性能変更処理を実行中であると判定した場合、前記性能変更処理が完了するまで前記フェイルオーバ処理の実行を抑制するフェイルオーバ抑制部を、更に有する、
   請求項３乃至請求項６の何れかに記載の情報処理装置。
8. 前記第１の情報処理システムが、前記第１の情報処理システムにおいて発生し得る障害の傾向を分析し、当該分析結果に基づいて、前記第２の情報処理部の性能を変更する要求を前記性能管理部に送信する性能分析部を有する場合に、
   前記性能管理部は、前記性能分析部から送信される要求に応じて、前記第２の情報処理部に対する前記性能変更処理を実行する、
   請求項４乃至請求項７のいずれかに記載の情報処理装置。
9. 特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する
   情報処理方法。
10. 情報処理プログラムであって、
    特定のサービスを実行する第１の情報処理部を有する第１の情報処理システムに通信可能に接続され、当該第１の情報処理システムに特定の事象が発生した際に、前記第１の情報処理部と連携して、前記特定のサービスの実行を前記第１の情報処理部から引き継ぐフェイルオーバ処理を実行する第２の情報処理部を有する第２の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第２の情報処理部の性能を管理する処理を、コンピュータに実行させる、
    プログラム。

Images