次に、本発明を実施する形態について、図面を参照して詳細に説明する。
<第1の実施形態>
本発明の第1の実施形態における情報処理装置について、図1を参照して説明する。図1は、本発明の第1の実施形態における情報処理装置の機能的な構成を例示するブロック図である。
図1に示すように、本実施形態におけるHAクラスタ100は、オンプレミス環境101に構築された現用系サーバ103と、クラウド環境102に構築された待機系サーバ104と、待機系サーバ104の性能管理を実行する性能管理装置106と、を有する。オンプレミス環境101と、クラウド環境102とは、インターネット等のWAN(Wide Area Network)回線109を介して、通信可能に接続されており、前記現用系サーバ103と、待機系サーバ104と、性能管理装置106との間は相互に通信可能である。以下、それぞれの構成要素について説明する。
まず、本実施形態におけるHAクラスタ100は、前述の通りオンプレミス環境101に構築された現用系サーバ103と、クラウド環境102に構築された待機系サーバ104とを有し、現用系サーバ103に何らかの事象(故障や障害等)が発生した場合に、待機系サーバ104が、現用系サーバが実行していた処理(例えば後述するサービス105等)を引き継ぐフェイルオーバ処理を実行するよう構成される。
オンプレミス環境101は、本実施形態においては、例えば、HAシステム100を構築する特定の企業や組織などの内部に構成され、当該所有者によって運用される情報処理システムである。本実施形態におけるオンプレミス環境101は、物理的なサーバと、それらを通信可能に接続するLAN(Local Area Network)等の通信ネットワークを用いて構成してもよい。また、オンプレミス環境101を構成するサーバ等の計算機の一部は、仮想化された計算機であるバーチャルマシン(VM:Virtual Machine)を用いて構成してもよい。本実施形態においては、オンプレミス環境101は、現用系サーバ103と、性能管理装置106と、を有するが、これら以外の任意のサーバ等を有するよう構成してもよい。
現用系サーバ103は、サービス105を実行するよう構成され、例えば、係るサービス105を用いてHAクラスタ103を利用するユーザあるいは外部のシステムに対して何らかの機能やリソース等を提供する、情報処理装置である。現用系サーバ103は、物理的なコンピュータ等の情報処理装置を用いて構成された物理サーバであってもよく、あるいは、バーチャルマシンを用いて構成された仮想サーバであってもよい。現用系サーバ103の構成は、HAクラスタ100あるいはオンプレミス環境100の構成と、サービス105の実行に必要な要件に基づいて適切に選択すればよい。なお、本実施形態における現用系サーバ103は、前記サービス105に関連するデータ等を保持していてもよい。
クラウド環境102は、計算機及び通信ネットワークを構成する各種リソースを仮想化してサービスとして提供するクラウドコンピューティング環境である。本実施形態においては、クラウド環境102として、仮想サーバや仮想ストレージ等の仮想化インフラストラクチャを提供するIaaS(Infrastructure as a Service)型のクラウドサービスや、データベースやアプリケーション実行環境等のアプリケーションプラットフォームを仮想化して提供する、PaaS(Platform as a Service)型のクラウドサービスなどを採用してもよい。本実施形態においては、具体的なクラウドサービスとして、例えば、Amazon EC2(Amazon Elastci Compute Cloud)(登録商標)等を採用してもよい。本実施形態におけるクラウド環境102は、例えばインターネットを経由して広くクラウドサービスを提供するパブリッククラウドであってもよく、特定の企業向けに構築されたプライベートクラウドであってもよい。
本実施形態におけるクラウド環境102を提供する図示しないクラウド事業者は、クラウド環境102が提供する仮想サーバ等のサービスを制御するためのAPI(Application Programming Interface)を規定する。クラウド環境102を利用するユーザ及びシステムは、当該APIを外部から実行(実行するよう通知)することにより、クラウド環境102が提供する各種サービス及びリソース等を制御できる。クラウド環境102がインターネットを通じて利用するよう公開されている場合、係るAPIは、例えば通信路にHTTP(Hypertext Transfer Protocol)あるいはHTTPS(Hypertext Transfer Protocol Secure)プロトコルを利用したSOAPメッセージ等をより提供されるよう構成してもよい。この場合、係るAPIのユーザは、例えば、特定のURI(Uniform Resource Identifier)に対してXML(Extensible Markup Language)を用いて記述したメッセージを送信することにより、係るAPIが提供する機能を実行できる。以下において、クラウド環境102において規定される係るAPIを、クラウドAPIを称する場合がある。
待機系サーバ104は、例えば、クラウド環境102内に構築される仮想計算機(仮想サーバ)である。本実施形態における待機系サーバ104は、前記現用系サーバと通信可能に接続され、前記現用系サーバ103に何らかの事象(故障や障害等)が発生した際に、係る現用系サーバ103において実行されるサービス105を引き継ぐフェイルオーバ処理に対応する。
待機系サーバ104は、係るサービス105の実行環境と、当該サービス105関連するデータ等を保持するよう構成してもよい。なお、以下において、本実施形態における待機系サーバ104の実態である仮想計算機について、クラウド・インスタンスと称する場合がある。
本実施形態において、前記クラウド環境102のユーザ(あるいはシステム)は、係るクラウドAPIを利用して、クラウド・インスタンスに対する各種制御を実行できる。本実施形態においては、係るクラウドAPIを利用して、例えば、クラウド・インスタンスの起動及び終了や、クラウド・インスタンスのタイプの変更(性能が異なるクラウド・インスタンスへの変更)や、クラウド・インスタンスの状態に関する情報の取得などの処理を実行できる。
サービス105は、前記の通り現用系サーバ103あるいは待機系サーバ104において実行され、本実施形態におけるHAクラスタ100の図示しないユーザ(及びシステム)に対して何らかの機能やリソースを提供する。本実施形態におけるサービス105は、例えば現用系サーバ103及び待機系サーバ104において実行可能なソフトウェア・プログラムとして構成してもよい。なお、図1及び図2においては、サービス105は1つのみ例示されているが、現用系サーバ103は、HAクラスタ100において提供する機能やリソースに応じて、サービス105を複数実行してもよい。
性能管理装置106は、図示しない管理者からの要求に基づいて、待機系サーバ104の性能管理を実行する、情報処理装置である。性能管理装置106は、前記現用系サーバと同様、物理的な構成を有する実コンピュータ等を用いて構成してもよく、仮想化された計算機を用いて仮想端末として構成してもよい。本実施形態における性能管理部106を実コンピュータとして構成する場合、図18に例示するような汎用のCPU(Central Processing Unit)やマイクロプロセッサ等の演算装置及1801及び、当該演算装置から参照されるメモリ等の記憶装置1802等からなるハードウェアと、当該演算装置2101によって実行される各種ソフトウェア・プログラム(コンピュータ・プログラム)とによって構成してもよい。更に、上記各ソフトウェア・プログラムを外部記憶媒体1805に記録しておき、性能管理装置106の出荷段階、あるいは運用段階等において、適宜外部記憶装置1804を通じて当該ソフトウェア・プログラムを不揮発性メモリ1803に格納するよう構成してもよい。
本実施形態における性能管理装置106は、オンプレミス環境101内においては、LANなどを通じて現用系サーバ103と通信可能に接続されており、クラウド環境102における待機系サーバ104とは、回線109を通じて通信可能に接続されている。なお、本実施形態には、係る性能管理装置106を図1に示すクラウド管理装置110と接続するよう構成し、係る性能管理装置から、クラウド管理装置110に対して待機系サーバ104に対する性能管理指示を送信する構成も含まれる。また、性能管理装置106は、後述する管理端末108と通信可能に接続されていてもよい。
本実施形態における性能管理装置106は、待機系サーバ104の性能を管理するための各種処理を実行し、待機系サーバ104の性能に関する状態を管理する、スケール管理部107を有する。本実施形態においては、スケール管理部107を、性能管理装置106により実行されるソフトウェア・プログラム(コンピュータ・プログラム)として構成してもよい。
なお、図1における性能管理装置106は、現用系サーバ103とは独立した構成として設けられているが、本実施形態は係る構成に限定されない。本実施形態においては、例えば図2に示すように、係る性能管理装置を、現用系サーバの一部を構成する性能管理部106aとして設けてもよい。この場合、スケール管理部107は、現用系サーバにより実行されるソフトウェア・プログラムとして構成してもよい。本実施形態における性能管理装置106の具体的な処理については後述する。
管理端末108は、図示しない管理者からの各種管理要求を、前記性能管理装置106や、現用系サーバ103等に送信する情報処理端末である。管理端末108も、前記性能管理装置106と同様、物理的な構成を有する実コンピュータ等を用いて構成してもよく、仮想化された計算機を用いて仮想端末として構成してもよい。なお、本実施形態における管理者端末108は必須ではなく、管理者による管理要求を前記性能管理装置106や、現用系サーバ103等に伝達可能であれば、任意の手段や装置を用いて代用してもよい。
回線109は、オンプレミス環境101とクラウド環境102を通信可能に接続できる、任意の通信ネットワークであり、例えば、インターネット等の広域通信ネットワークを採用してもよい。
次に、上記のように構成された、本実施形態における情報処理装置の動作について説明する。以下においては、性能管理部106における処理を中心に、本実施形態におけるHAクラスタ100のフェイルオーバ処理に必要となる、現用系サーバ103及び待機系サーバ104の制御について説明する。
まず、本実施形態おける、サービス105のフェイルオーバ処理の一例について説明する。本実施形態においては、現用系サーバ103の稼働中に故障や障害等のなんらかの事象が発生し、現用系サーバ103において前記サービス105の実行を継続できなくなった場合、現用系サーバ103及び待機系サーバ104は連携して、前記サービス105の処理を待機系サーバ104サーバに引き継いで実行するフェイルオーバ処理を実行する。
この場合、例えば、現用系サーバ103は、サービス105の実行状態及びデータ等を保存してサービス105を停止可能な状態とし、係る保存した実行状態及びデータ等を、待機系サーバ104に送信する。待機系サーバ104は、例えば、前記現用系サーバ103より受信した前記実行状態及びデータ等に基づいてサービス105を構成するソフトウェア・プログラムを起動して、サービス105による処理を続行する。なお、本実施形態にケルフェイルオーバ処理の具体的な処理手順は、上述した一例に限定されず、現用系サーバ103、待機系サーバ104、及びクラウド環境102の構成によって、適宜適切な方法を選択してよい。
次に、上記フェイルオーバ処理に関連した、本実施形態における待機系サーバ104の性能変更処理について説明する。前述したように、HAシステム100においては、運用コスト面における優位性と、各種リソースの拡張容易性の観点から、現用系サーバ103においてサービス105を実行する平常時には待機系サーバ104の性能を低くするよう制御し、前述したフェイルオーバ処理が発生した際には、待機系サーバ104の性能を、現用系サーバ103と同等水準まで高くするよう制御してもよい。以下、待機系サーバ104の具体的な性能変更手順の一例について、図3を参照して説明する。図3は、本実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。
まず、図示しないシステム管理者は、例えば、オンプレミス環境101に配置された管理端末108を通じて、待機系サーバ104に対する性能変更指示を、性能管理装置106に送信する(ステップS301)。本実施形態においては、例えば、管理端末108を構成するユーザインタフェース(UI:User Interface)装置を用いて、前記システム管理者が指示内容を入力したり、選択したりすることによって、係る性能変更指示を送信してもよい。また、前記性能変更指示は、例えば、性能変更の対象となる待機系サーバの指定や、変更するサーバの性能レベル等の変更情報を含んでもよい。なお、図1及び図2に例示する構成においては、待機系サーバ104が1台だけ図示されているが、本実施形態におけるHAクラスタ100は、複数の待機系サーバを有してもよい。
性能管理装置106における、スケール管理部107は、管理端末より受信した前記性能変更指示を解析し、性能変更の対象となる待機系サーバ(本実施形態においては待機系サーバ104)の情報を特定する(ステップS302)。
次に、スケール管理部107は、現用系サーバ103と、性能変更の対象である、待機系サーバ104との連携を解除する(ステップS303)。本実施形態においては、スケール管理部107は、例えば、前記したサービス105のフェイルオーバ処理のための、現用系サーバ103と、待機系サーバ104との間の連携を解除してもよい。この場合、スケール管理部107は、例えば、係る現用系サーバ103と待機系サーバ104との間における、サービス105の実行状態や、サービス105に関連するデータの送受信を停止してもよい。また、スケール管理部107は、係る現用系サーバ103と待機系サーバ104との間で、前記フェイルオーバ処理が実行されないように制御してもよい。
次に、スケール管理部107は、前記ステップS302において特定した、性能変更の対象となる待機系サーバ104の性能を変更する(ステップS304)。本実施形態においては、スケール管理部107は、クラウド環境102や、待機系サーバ104の構成に応じて、適宜適切な方法を用いて係る待機系サーバ104の性能変更処理を実行する。スケール管理部107は、例えば、前述したクラウド環境102において規定されたクラウドAPIを利用して、待機系サーバ104の性能を変更してもよい。スケール管理部107は、ステップS304における性能変更処理の実行後、係る処理の完了を待機してもよい。
次に、スケール管理部107は、前記ステップS303において解除した、現用系サーバ103と、待機系サーバ104との間の連携を回復する(ステップS305)。本実施形態においては、スケール管理部107は、例えば、前記サービス105のフェイルオーバ処理のための、現用系サーバ103と待機系サーバ104との間の連携を回復してもよい。
次に、スケール管理部107は、ステップS301において指示された待機系サーバ104に対する性能変更処理の完了を、図示しない管理者へ通知する(ステップS306)。本実施形態においては、スケール管理部107が、管理端末108に対して係る待機系サーバ104の性能変更処理の完了を通知し、管理端末108において、前記UIに処理完了を表示するよう構成してもよい。以上説明した処理により、性能管理部106は、待機系サーバ104の性能管理を実行する。
上記説明においては、システム管理者が管理端末108を通じて待機系サーバ104の性能変更要求を送信しているが、本実施形態はこのような構成に限定されない。例えば、現用系サーバ103にいて何等かの事象が発生した場合、現用系サーバ103自身か、あるいは性能管理部106が当該事象の発生を検知し、サービス105のフェイルオーバの要否を判定し、係る判定結果に基づいて、待機系サーバ104の性能を管理するよう構成してもよい。
前記説明した待機系サーバ104の性能変更手順においては、性能管理装置106が待機系サーバ104を直接制御しているが、本実施形態はこのような構成に限定されない。本実施形態における性能管理装置106は、クラウド環境102において提供されるクラウド・インスタンスの管理手段を適宜適切に使用して、待機系サーバ104を制御する。例えば、前述したように、性能管理装置106とクラウド管理装置110とを通信可能に接続し、スケール管理部107から、当該クラウド管理装置110に対して、待機系サーバ104を制御するための制御指示を送信するよう構成してもよい。
以上説明した、本実施形態における性能管理措置106によれば、性能管理装置106を構成するスケール管理部107は、特定のサービス105を実行する現用系サーバ103と、係る現用系サーバ103と連携して当該サービス105をフェイルオーバ可能に構成された待機系サーバ104とに対して、特定の順序に従って管理操作を実行することにより、係る待機系サーバ104の性能を管理することができる。
このような処理により、本実施系における性能管理装置106によれば、HAクラスタ100を運用した状態で、クラウド環境102に用意された待機系サーバ104の性能を動的に変更することが可能であり、係る待機系サーバ104の性能変更処理の際に、HAクラスタを構成する現用系サーバ103と、待機系サーバ104とに対する管理操作を、矛盾なく実行可能である、という効果を奏する。
なお、本実施形態における情報処理装置である性能管理装置106は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。
<第2の実施形態>
次に、本発明の第2の実施形態について説明する。以下の説明においては、本実施形態に係る特徴的な構成を中心に説明する。その際、前記第1の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明は省略する。
本実施形態における情報処理装置は、前記第1の実施形態における情報処理装置と基本的な構成は同様である。以下、図4を参照して、本実施形態における、性能管理部106a及びクラスタ制御部114の構成と動作を中心に説明する。
本実施形態における現用系サーバ103は、前記第1の実施形態における現用系サーバ103と、基本的な構成は同様である。本実施形態においては、現用系サーバ103は、スケール管理部107と、スケール変更部111と、クラスタ制御部114と、フェイルオーバ抑制部113と、記憶装置115と、を有する。また、本実施形態における現用系サーバは、前記第1の実施形態において説明したフェイルオーバ処理の対象となる、サービス105を実行する。以下、それぞれの構成要素について説明する。
まず、現用系サーバにおいて稼働するサービス105は、前記第1の実施形態同様、ユーザや他のシステムに対して何らかの機能やサービスを提供するソフトウェア・プログラムである。現用系サーバ103に障害や故障等の特定の事象が発生した場合、フェイルオーバ処理により、待機系サーバ104は、現用系サーバ103からサービス105の処理を引き継いで実行する。
記憶装置115は、現用系サーバ103を構成する記憶媒体であり、現用系サーバ103における各種処理に必要な各種データやソフトウェア・プログラム等を格納する。なお、記憶装置115は、現用系サーバ103を物理的なコンピュータ等の情報処理装置を用いて構成する場合には、ハードディスクドライブ等の磁気記憶装置や半導体記憶装置により構成してもよく、現用系サーバ103を仮想計算機として構成する場合には、当該仮想計算に割り当てられた記憶用リソースとして構成してもよい。なお、待機系サーバ104を構成する記憶媒体である記憶装置118についても、記憶装置115と同様の構成としてよい。
本実施形態における係る記憶装置115は、前記サービス105に関連するデータ115aを記憶してもよい。データ115aは、例えば現用系サーバ103において稼働するサービス105に関連する任意のデータであり、サービス105を稼働する際に随時更新されるようなデータも含まれてよい。本実施形態においては、現用系サーバ103におけるクラスタ制御部114(後述)と、待機系サーバ104におけるクラスタ制御部117が連携することにより、係るデータ115aを、現用系サーバ103と、待機系サーバ104との間で複製(ミラーリング)するよう構成してもよい。例えば、現用系サーバ103におけるクラスタ制御部が記憶装置115を参照して、複製対象となるデータ115aを選択し、係るデータ115aをWAN回線109を通じて待機系サーバ104におけるクラスタ制御部117に送信し、待機系サーバ104におけるクラスタ制御部117が当該データを受信し、待機系サーバ104を構成する記憶装置118にデータ118aとして記録するよう構成してもよい。
なお、本実施形態においては、待機系サーバ104の性能変更処理のために係る待機系サーバ104を停止する場合、現用系サーバ103は、係る待機系サーバ104の停止中にサービス105により更新されたデータ115aを、記憶装置115に蓄積してもよい。この場合、係る待機系サーバ104が起動した後に、例えば、後述する現用系サーバ103におけるクラスタ制御部114及び待機系サーバ104におけるクラスタ制御部117は、記憶装置115に蓄積されたデータを記憶装置118に複製してもよい。
次に、本実施形態におけるクラスタ制御部114について説明する。本実施形態におけるクラスタ制御部114は、後述するスケール管理部107及びフェイルオーバ抑制部113と通信可能に接続され、サービス105の可用性を確保できるよう、HAシステム100の構成要素を制御する。このような構成要素の制御として、例えば、本実施形態におけるクラスタ制御部114は、サービス105についての前記フェイルオーバ処理を制御してもよい。この場合、本実施形態におけるクラスタ制御部114は、前記待機系サーバ104におけるクラスタ制御部117と連携して、前記ミラーリング処理の停止・再開や、現用系サーバ103と待機系サーバ104との連携の解除・回復等を制御してもよい。また、クラスタ制御部114は、HAクラスタ100において提供するサービスに関する情報(例えば、提供可能な全サービスに関する情報や、現用系サーバにて稼働中のサービスに関する情報など)を提供してもよい。
本実施形態におけるクラスタ制御部114は、クラスタ構成情報114aを有してもよい。係るクラスタ構成情報114aは、例えば、図7に例示するように、HAクラスタ100において提供するサービス105を識別する情報701(例えば識別名称等)と、係るサービス105を実行可能な待機系サーバ103を識別する情報702(例えば、サーバ名等)とを関連付ける情報を含んでもよい。なお、図7に例示した構成においては、サービス識別情報701と、待機系サーバ識別情報702とを1対1で関連付けているが、サービス識別情報701に対して、複数の待機系サーバ識別情報を関連付けるような構成としてもよい。
なお、図4に例示する構成においては、クラスタ構成情報114aは、クラスタ制御部114の一部として設けられているが、現用系サーバ103の一部を構成する独立した構成要素として設けてもよく、HAクラスタ100を構成する任意の情報処理装置を構成する構成要素として設けてもよい。係る構成を採用する場合、クラスタ制御部114は、係る情報処理装置に設けられたクラスタ構成情報114aを、HAクラスタ100を構成する通信ネットワークを経由して参照してもよい。
次に、本実施形態における性能管理部の構成について説明する。図4に例示するように、本実施形態においては、スケール管理部107、スケール変更部111、及びフェイルオーバ抑制部113により、性能管理部106aを構成してもよい。なお、図4に例示する構成においては、性能管理部106aは、現用系サーバ103の一部を構成するよう設けられているが、前記第1の実施形態と同様、現用系サーバ103とは別に独立した構成要素(例えば、物理的あるいは仮想的な計算機により構成した性能管理装置)として設けてもよい。
まず、本実施形態におけるスケール管理部107について説明する。図4に例示するように、本実施形態におけるスケール管理部107は、入出力インタフェース107a、スケール状態記憶部107b、及びスケールレベル対応表107cを含む。スケール管理部107は、スケール状態記憶部107bを用いて待機系サーバ104の(現在の)性能に関する状態であるスケールレベルを管理し、入出力インタフェース107aを介して管理端末108からの性能変更要求を受け付ける。また、スケール管理部107は、スケールレベル対応表107cを参照して、待機系サーバ104に対する性能変更処理を実行する。以下、本実施形態において、スケールレベルは、待機系サーバ104の実態であるクラウド・インスタンスの性能タイプ(以下インスタンスタイプと称することがある)を数値化した値を表す。なお、クラウド・インスタンスの性能タイプは、後述するように、クラウド環境102を提供する、図示しないクラウド事業者によって定義される。
上述したスケール管理部107の構成要素について、以下図5及び図6を参照して説明する。図5は、本実施形態におけるスケール状態記憶部107bの1つの構成例を例示する、模式図である。図6は、本実施形態におけるスケールレベル対応表107bの1つの構成例を例示する、模式図である。
本実施形態におけるスケール状態記憶部107bは、待機系サーバ103の現状のスケールレベル等を保持する記憶領域である。図5に例示するように、スケール状態記憶部107bは、例えば、待機系サーバ名501と、インスタンスID502と、待機系サーバの現在のスケールレベル503と、待機系サーバのスケールレベル変更状態(性能変更処理の状態)504と、スケールレベル対応表107cへの参照情報であるアドレス505とを有する、1つ以上のエントリ506を有するよう構成してもよい。待機系サーバが複数存在する場合、スケール状態記憶部107bには、待機サーバ毎に、係るエントリ506が設けられる。
待機系サーバ名501は、本実施形態におけるHAクラスタ100を構成する待機系サーバを一意に特定する識別情報を表す。本実施形態における待機系サーバ名501としては、前記クラスタ構成情報114aにおける、待機系サーバ識別情報と同じ情報を用いてもよい。
インスタンスID502は、待機系サーバ103の実態であるクラウド・インスタンスについて一意に割り振られた識別子(ID:identifier)である。
スケールレベル503は、待機系サーバ103に設定されている、現在のスケールレベルであり、待機系サーバ103に現在設定されている性能を表す。
状態504は、待機系サーバ名501により識別される待機系サーバ103について、後述する、性能変更の処理を実行中か否かの状態を表す。例えば、スケール管理部107は、係る待機系サーバ103の性能を変更する処理を実行している場合は、状態504を”変更中”に設定し、変更処理を実行していない場合は”確定”に設定してもよい。
アドレス505は、各待機系サーバに関連付けされた、後述するスケールレベル対応表107cへの参照情報を表す。本実施形態においては、アドレス505には、係る待機系サーバ毎に関連付けされたスケールレベル対応表の保持領域に対するアドレスを含めてもよい。
なお、本実施形態において、スケール状態記憶部107bの情報は、システム管理者により設定されてもよく、あるいはHAクラスタ100において待機系サーバ103を構成したり追加したりする場合に、自動的に設定されるよう構成してもよい。
次に、スケールレベル対応表107cについて説明する。本実施形態におけるスケールレベル対応表107cは、各クラウド事業者が提供するクラウド環境102におけるクラウド・インスタンスの性能タイプ(インスタンスタイプ)と、前記スケールレベルを関連付けて保持してもよい。図6に例示する構成においては、スケールレベル対応表107cは、例えば、クラウド事業者名601と、スケールレベル602と、インスタンスタイプ603と、緒元情報604と、を有する、1つ以上のエントリ605を有してもよい。
スケールレベル対応表107cは、クラウド事業者毎に提供されるインスタンスタイプの数に応じて前記エントリ605を複数保持してもよい。なお、スケールレベル対応表107cは、例えば、クラウド事業者毎に提供される全てのインスタンスタイプについて前記エントリ605を保持してもよく、オンプレミス環境101における現用系サーバ103の性能と比較して不要なインスタンスタイプについては前記エントリ605を保持しなくともよい。なお、本実施形態においては、システム管理者が、クラウド事業者ごとに係るスケールレベル対応表107cの内容を設定してもよい。
次に、図6におけるエントリ605の各構成要素について説明する。
クラウド事業者名601は、クラウド環境102を提供するクラウド事業者を識別可能な情報であり、例えば、クラウド事業者の名称や、クラウド事業者毎に割り当てたID等により表される。
スケールレベル602は、前述したように、各クラウド事業者によって提供されるクラウド・インスタンスの性能タイプを数値化した値を表す。スケールレベル602は、システム管理者が、後述するインスタンスタイプ603に基づいて適宜設定してもよい。
インスタンスタイプ603は、前述したように、クラウド事業者毎に定義される、クラウド・インスタンスの性能を表す性能タイプである。これらは、例えば性能が高い順に「ラージ」、「ミディアム」、「スモール」等と定義され、クラウド事業者毎に定義が異なってもよい。
緒元情報604は、インスタンスタイプ603毎に、クラウド・インスタンスの性能や当該クラウド・インスタンスの利用料などの情報を含む。緒元情報604は、クラウド・インスタンスに関する性能を表す情報として、例えば演算処理装置(CPU)の性能に関する情報、メモリ容量、通信ネットワークの通信速度、記憶装置の容量等を含んでもよい。緒元情報604は、システム管理者による性能変更の判断材料として使用してもよいため、前記性能に関する情報以外に、判断基準となり得る任意の情報を含んでもよい。
本実施形態において、上記説明したスケール状態記憶部107b及び、スケールレベル対応表107cは、それぞれ現用系サーバ103を構成する記憶装置の一部に格納されてもよい。また、スケール管理部107がソフトウェア・プログラムにより構成される場合、スケール状態記憶部107b及び、スケールレベル対応表107cは、係るソフトウェア・プログラムが実行される際に、係るソフトウェア・プログラムから参照可能なように、メモリに読み込まれるように構成してもよい。
次に、本実施形態における入出力インタフェース107aについて説明する。入出力インタフェース107aは、前述したように、管理端末108と通信可能に接続され、管理端末108から送信される性能変更要求を受け付ける。本実施形態においては、例えば管理端末108と、現用系サーバ103との間を例えばLAN等のオンプレミス環境内の通信ネットワーク112により接続してもよい。入出力インタフェース107aと、管理端末108の間の通信には専用の通信プロトコルを採用してもよく、あるいはHTTPやHTTPS等の汎用プロトコルを採用してもよい。
本実施形態における入出力インタフェース107aは、管理者端末108からの性能変更要求に応じて、スケール状態記憶部107b及びスケールレベル対応表107cを参照して、スケールレベル管理情報107dを生成し、係るスケールレベル管理情報107dを管理者端末108に通知する。
次に、本実施形態におけるスケールレベル管理情報107dは、図8に示すように、例えば、現用系サーバ103において稼働しているサービス105を識別する情報(サービス名)と、係るサービス105をフェイルオーバ可能な待機系サーバ104を表す待機系サーバ名と、係る待機系サーバ104の現在のスケールレベルと、係る待機系サーバ104について変更可能なスケールレベルの情報と、を有してもよい。本実施形態においては、入出力インタフェース107は、係るスケールレベル管理情報107dを、例えば、XMLにより表現してもよい。
次に本実施形態におけるスケール変更部111の構成について説明する。本実施形態におけるスケール変更部111は、クラウド環境104に設けられた後述するクラウド管理装置110と通信可能に接続されており、スケール管理部107からの性能変更要求を解析し、前記クラウドAPIを利用して、クラウド管理装置110に対して待機系サーバ104の性能変更要求を送信する。本実施形態におけるスケール変更部111の具体的な動作については、後述する。
次に、本実施形態におけるフェイルオーバ抑制部113について説明する。本実施形態におけるフェイルオーバ抑制部113は、前記スケール管理部107及びクラスタ制御部114と通信可能に接続される。フェイルオーバ抑制部113は、前記スケール管理部107と連携して前記サービス105のフェイルオーバ処理の実行可否を判定し、係る判定結果に基づいて前記フェイルオーバ処理を抑制する。本実施形態におけるフェイルオーバ抑制部113の具体的な動作については、後述する。
なお、本実施形態においては、上述したスケール管理部107、スケール変更部111、クラスタ制御部114、及びフェイルオーバ抑制部113はそれぞれ相互に通信可能に接続されていてもよい。また、上述したスケール管理部107、スケール変更部111、クラスタ制御部114、及びフェイルオーバ抑制部113がソフトウェア・プログラムとして実装される場合、係るソフトウェア・プログラムは、例えば任意のプロセス間通信や共有メモリ等により、通信可能に接続されてもよい。
また、図4に例示した本実施形態の構成例においては、スケール管理部107、スケール変更111、クラスタ制御部114、フェイルオーバ抑制部113を、それぞれ独立した構成要素として例示しているが、本実施形態はこのような構成に限定されない。本実施形態においては、これらの構成要素について、少なくとも一部または全部の構成要素を統合したソフトウェア・プログラムを提供してもよく、これらの構成要素をどのように分割するかは、任意に定めて良い。
次に、本実施形態における管理端末108について説明する。本実施形態における管理端末は、前記第1の実施形態と同様、図示しない管理者からの待機系サーバ104に対する性能変更要求を受け付け、係る性能変更要求を入出力インタフェース107dに送信する。本実施形態においても、前記第1の実施形態と同様、管理端末108を構成するUI装置を用いて、前記システム管理者が指示内容を入力したり、選択したりすることにより、係る性能変更指示を送信してもよい。
次に、本実施形態におけるクラウド管理装置110について説明する。クラウド管理装置110は、例えば、クラウド事業者によって、クラウド環境102に設けられてもよい。クラウド管理装置110は、前記スケール変更部111とWAN回線109を介して通信可能に接続されており、また、前記待機系サーバ104と、クラウド内通信ネットワーク119を介して通信可能に接続されている。本実施形態におけるクラウド管理装置110は、例えば、クラウド事業者により規定された前記クラウドAPIの実行要求を受け付け、係る実行要求に基づいて前記クラウド・インスタンスに対する各種制御を実行してもよい。
次に、本実施形態におけるクラウド内通信ネットワーク119について説明する。クラウド内通信ネットワーク119は、クラウド環境102を提供するクラウド事業者が構築する通信ネットワークである。クラウド事業者は、係るクラウド内通信ネットワークを、インターネット等の広域通信ネットワーク、LAN等の局所通信ネットワーク、及び専用線を用いた拠点間通信ネットワーク等を組み合わせて構成してもよい。
次に、上記のように構成された、本実施形態における情報処理装置の動作について説明する。以下においては、待機系サーバ104に対する性能変更処理と、フェイルオーバ処理について説明する。
まず、本実施形態における、待機系サーバ104に対する性能変更処理について説明する。以下、待機系サーバ104の具体的な性能変更手順の一例について、図9乃至図13を参照して説明する。図9は、本実施形態における、待機サーバの性能変更処理の際に、管理端末に表示するUIの一例を表す模式図である。図10乃至図13は、本実施形態における、待機系サーバの性能変更処理を例示する、フローチャートである。
まず、図示しないシステム管理者は、管理端末108から待機系サーバ104に対する性能変更処理を開始する(ステップS1001)。管理端末108は、性能変更処理の開始に際して、前記スケールレベル管理情報107dを取得するための出力要求を、入出力インタフェース107aに対して送信する(ステップS1002)。
次に、入出力インタフェース107aは、前記ステップS1002において送信された要求を解析し、スケールレベル管理情報107dを生成する(ステップS1003)。
ステップS1003において、まず、入出力インタフェース107aは、クラスタ制御部114から、現用系サーバ103において稼働中のサービス一覧と、係るサービスのフェイルオーバ処理を実行可能な待機系サーバ104を識別する待機系サーバ識別情報とを取得する。本実施形態においては、クラスタ制御部114は、クラスタ制御部114において管理している稼働中のサービス105に関する情報と、クラスタ構成情報114aを参照することにより、これらの情報を提供できる。
次に、入出力インタフェース107aは、前記取得したサービス一覧と、係るサービスに関連するフェイルオーバ処理に対応する待機系サーバの識別情報とを用いて、スケール状態記憶部107b及びスケールレベル対応表107cを参照して、係るサービス一覧に記録されたサービス毎に、スケールレベル管理情報107dを生成する。
次に、入出力インタフェース107aは、前記ステップS1003において生成したスケールレベル管理情報107dを、管理端末108に通知する(ステップS1004)。
次に、管理端末108は、前記ステップS1004において通知されたスケールレベル管理情報107dに基づいて、システム管理者に対して、図示しないUI装置により、各待機サーバに対する性能変更処理のためのUIを提供する(ステップS1005)。図9は、本実施形態において管理端末108において表示するUIの一例を示す、模式図である。
図9に示すように、本実施形態におけるUI901は、現用系サーバ103において稼働中のサービス一覧902と、係る一覧に表示された各サービスのフェイルオーバ処理を実行可能な待機系サーバ104の一覧903と、待機系サーバ毎のスケール一覧904と、変更指示操作部905とを含む。
本実施形態においては、変更指示操作部905は、例えば、押下可能なボタン表示等であってもよい。本実施形態においては、例えば、管理者端末108は、UI901を係る管理端末108に接続される図示しないディスプレイ装置に表示してもよい。
なお、本実施形態における管理端末108は、図9に例示した表示に限らず、入出力インタフェース107aより受信したスケールレベル管理情報107dに基づいて、任意の形式でUI表示を提供してよい。また、本実施形態における管理端末108は、係るUI表示において、前記受信したスケールレベル管理情報107dの一部の情報を加工したり、省略したりしてもよい。
次に、図示しない管理者は、係るUI901を確認しながら、管理端末108に接続される図示しない操作手段(例えば、キーボードやマウス等)により、変更指示操作部905を操作し、特定の待機系サーバ104に対する性能の変更を指示する(ステップS1006)。本実施形態においては、例えば、変更指示操作部905がボタン表示であった場合は、管理者が当該ボタンを押下することで、待機系サーバに対する性能の変更を指示してもよい。
前記ステップ1006における、管理者からの性能変更の指示により、管理端末108は、入出力インタフェース107aに対して、特定の管理サーバ104に対する性能変更指示と共に、係る性能変更のために必要な情報(例えば、係る待機系サーバを識別する待機系サーバ名、インスタンスID,変更後のスケールレベル及び変更後のインスタンスタイプ等)を送信する。
次に、スケール管理部107において、管理端末108から、待機サーバ104に対する性能変更の要求を受け付けた後の処理について、図11乃至図13を参照して説明する。なお、以下においては、特定の待機系サーバ104に対する性能変更の指示を、スケール変更指示と称する場合がある。
まず、入出力インタフェース107aは、管理端末108より、特定の待機系サーバ104に対するスケール変更指示を受信する(ステップS1101)。入出力インタフェース107aは、係るスケール変更指示を解析し、係る変更指示に含まれる待機系サーバ名、インスタンスID,変更後のスケールレベル及び変更後のインスタンスタイプ等を抽出する。
次に、スケール管理部107は、受信したスケール変更指示に含まれる待機系サーバ名を用いて、スケール状態記憶部107bを参照し、係るサーバ名に関連するエントリ506における状態504を、”変更中”に更新する(ステップS1102)。
スケール管理部107は、入出力インタフェース107aに対して係る状態504を通知し(ステップS1103)、入出力インタフェース107aは、管理端末108に対して係る状態を更新するよう通知してもよい。
次に、スケール管理部107は、スケール変更部111に対して、スケール変更要求を通知する。当該スケール変更要求に応じて、スケール変更処理部111は、クラスタ制御部114及びクラウド管理部装置110と連携して、スケール変更指示において指定された特定の待機系サーバ104に対する性能変更の処理を実行する(ステップS1104)。以下、スケール変更部111における処理について図12を参照して説明する。
まず、スケール変更部111は、現用系サーバ103と性能変更の対象となる特定の待機系サーバ104との間で、サービス105に関連するデータのミラーリング処理を実行している場合、係るミラーリング処理を停止するよう、クラスタ制御部114に通知する(ステップS1201)。
次に、スケール変更部111は、クラスタ制御部に114に対して、現用系サーバ103と性能変更の対象となる特定の待機系サーバ104との間の連携を解除し、切離するよう通知する(ステップS1202)。これにより、現用系サーバ103と係る待機系サーバ104との間における、不用意なフェイルオーバ処理の発生を抑止する。
次に、スケール変更部111は、クラウド環境102に用意されているクラウド管理装置110に対して、性能変更の対象となる特定の待機系サーバ104の実態である、クラウド・インスタンスのスケール変更を要求する(ステップS1203)。なお、以下、係るクラウド・インスタンスを、性能変更対象であるインスタンスと称する場合がある。
本実施形態においては、スケール変更部111は、クラウド管理装置110に対して、前述したクラウド環境102において規定されるクラウドAPIを実行することにより、係る性能変更対象であるインスタンスに対するスケール変更要求を実行する。以下、スケール変更部111によるスケール変更要求の処理について、図13を参照して説明する。
まず、スケール変更部111は、インスタンスを停止するクラウドAPIを実行し、性能変更対象であるインスタンスを停止する(ステップS1301)。具体的には、スケール変更部111は、前記スケール変更要求に含まれるインスタンスIDを指定して、当該IDにより識別可能なクラウド・インスタンスを停止するクラウドAPIを実行してもよい。
次に、スケール変更部111は、インスタンス状態を取得するクラウドAPIを実行し、性能変更対象であるインスタンスの停止状態を確認する(ステップS1302乃至ステップ1303)。具体的には、スケール変更部111は、前記スケール変更要求に含まれるインスタンスIDを指定して、当該IDにより識別可能なクラウド・インスタンスの状態を取得するクラウドAPIを実行してもよい。
次に、スケール変更部111は、インスタンスの停止状態を確認した後(ステップS1303においてYESの場合)、インスタンスタイプを修正するクラウドAPIを実行し、性能変更対象であるインスタンスにおけるインスタンスタイプを変更する(ステップS1304)。具体的には、スケール変更部111は、前記スケール変更要求に含まれるインスタンスID及びインスタンスタイプを指定して、当該IDにより識別可能なクラウド・インスタンスのインスタンスタイプを、前記スケール変更要求に含まれるインスタンスタイプに変更するクラウドAPIを実行してもよい。
次に、スケール変更部111は、インスタンス起動を起動するクラウドAPIを実行し、性能変更対象であるインスタンスを起動する(ステップS1305)。具体的には、スケール変更部111は、前記スケール変更要求に含まれるインスタンスIDを指定して、当該IDにより識別可能なクラウド・インスタンスを起動するクラウドAPIを実行してもよい。
次に、スケール変更部111は、インスタンス状態を取得するクラウドAPIを実行し、性能変更対象であるインスタンスの起動状態を確認する(ステップS1306乃至ステップ1307)。スケール変更部111は性能変更対象であるインスタンスの起動を確認し(ステップS1307においてYES)、クラウド管理装置110に対するスケール変更処理を終了し、図12におけるステップS1204から処理を続行する。
次に、スケール変更部111は、クラスタ制御部114に対して、ステップS1203において性能変更処理が完了した特定の待機系サーバ104の復帰を要求する(ステップS1204)。本実施形態においては、スケール変更部111は、サービス105のフェイルオーバ処理が可能なように、係る特定の待機系サーバ104と現用系サーバ103との間の連携を再開するよう、クラスタ制御部114に通知してもよい。
次に、スケール変更部111は、前記ステップS1201において停止したミラーリング処理を再開するよう、クラスタ制御部114に通知する(ステップS1205)。
次に、スケール変更部111は、前記性能変更の対象である特定の待機系サーバ104の停止から起動までの間に、現用系サーバ103におけるサービス105の処理により蓄積されたデータ115aが、現用系サーバ103と係る待機系サーバ104との間で同期されたか確認する(ステップS1206)。
係る同期処理が完了し、待機系サーバ104がHAクラスタ100復帰した場合(ステップS1207においてYES)、スケール変更部111は性能変更処理を終了し、スケール管理部107がステップS1105より処理を継続する。なお、スケール変更部111は、上述したスケール変更処理の結果を、スケール管理部107に通知してもよい。
スケール管理部107は、スケール状態記憶部107bを参照し、上記において性能変更処理の対象となった特定の待機系サーバに関連するエントリ506を抽出し、かかるエントリ506における状態504を”確定”に更新し、スケールレベル503を変更後のスケールレベル値に更新する(ステップS1105)。
スケール管理部107は、入出力インタフェース107aに対して、係る状態504と変更後のスケールレベル503と共に、スケール変更完了を通知する(ステップS1106)。入出力インタフェース107aは、管理端末108に対して係るスケール変更完了を通知するよう構成してもよい。
なお、上記説明においては、スケール状態記憶部107b及びスケールレベル対応表107cの参照や更新は、スケール管理部107が実行するが、本実施形態はこのような構成に限定されない。本実施形態において、係るスケール状態記憶部107b及びスケールレベル対応表107cの参照および更新は、例えばスケール変更部111が実行してもよい。
以上説明した処理により、本実施形態における情報処理装置によれば、現用系サーバ103において実行されるサービス105のフェイルオーバ処理に対応可能な待機系サーバ104の性能を変更することが可能である。
次に、上記のように構成された現用系サーバ103と、待機系サーバ104におけるフェイルオーバ処理について説明する。以下、本実施形態におけるフェイルオーバ処理の処理について図14及び図15を参照して説明する。図14及び図15は、本実施形態におけるフェイルオーバ処理の一例を例示する、フローチャートである。
まず、現用系サーバ103におけるクラスタ制御部114は、現用系サーバ103内に故障や障害等の特定の事象が発生したことを検知し、フェイルオーバ処理を開始する。
クラスタ制御部114は、フェイルオーバ抑制部113に対して、サービス105のフェイルオーバ処理を実行可能か否かの確認を要求する(ステップS1401)。具体的には、クラスタ制御部114は、クラスタ構成情報114aを参照して、サービス105をフェイルオーバ可能な待機系サーバ名を取得し、係る待機系サーバ名を指定して、フェイルオーバ抑制部に対してフェイルオーバ処理の実行可否の確認を要求する。
以下、フェイルオーバ抑制部113における処理(ステップS1402)について図15を参照して説明する。
フェイルオーバ抑制部113は、まず、スケール状態記憶部107bを参照して、前記ステップS1401において指定された待機系サーバ名に対応するエントリ506を抽出し、係るエントリ506における状態504を取得する(ステップS1501)。なお、本実施形態においては、フェイルオーバ抑制部113は、直接スケール状態記憶部107bを参照してもよく、スケール管理部107に対して前記ステップS1401において指定された待機系サーバ名を通知して、係るサーバ名に対応する状態504の取得を要求してもよい。
次に、フェイルオーバ抑制部113は、ステップS1501において取得した状態504を確認し(ステップS1502)、係る状態504が”確定”の場合(ステップS1502においてYES)、クラスタ制御部114に対してフェイルオーバ処理の許可を通知する。
ステップS1502において、係る状態504が”確定”ではない場合(係るサーバ名により指定された待機サーバ104について、性能変更処理が実行されている場合、ステップS1502においてNO)、フェイルオーバ抑制部113は、フェイルオーバ処理を抑制するため、クラスタ制御部114への応答を遅延させ、一定時間の経過の後(ステップS1504)、再度ステップS1501から処理を続行する。フェイルオーバ抑制部113は、ステップS1502における状態の確認結果が”確定”となるまで、ステップS1501乃至ステップS1504の処理を繰り返す。
クラスタ制御部114は、フェイルオーバ抑制部113におけるフェイルオーバ抑制処理の後、フェイルオーバ抑制部からフェイルオーバ許可の応答を受信し(ステップS1403)、待機系サーバ104におけるクラスタ制御部117に対して、フェイルオーバ処理の開始を通知し(ステップS1404)、当該クラスタ制御部117と連携して、サービス105のフェイルオーバ処理を実行する(ステップS1405)。
なお、本実施形態において、特定のサービス105をフェイルオーバ可能な待機系サーバ104が複数存在する場合、フェイルオーバ抑制部113は、それぞれの待機系サーバについてフェイルオーバ処理を実行可能か否か問い合わせて、フェイルオーバ処理を実行可能な待機系サーバの情報をクラスタ制御部に通知するよう構成してもよい。
以上説明した処理により、本実施形態における情報処理装置によれば、待機系サーバ104の性能を変更する処理が実行されている間は、係る待機系サーバ104に対するフェイルオーバ処理が抑制されるため、不要なフェイルオーバの発生や、フェイルオーバの失敗によるサービスの停止を防ぐことができる。
以上説明した通り、本実施形態におけるスケール管理部107は、特定の待機系サーバ104に対する性能変更要求に対応して、クラスタ制御部114と連携して現用系サーバ103と待機系サーバ104との連携を解除し、スケール変更部111と連携して具体的な性能変更要求をクラウド管理装置110に送信する。
このように、本実施形態によれば、オンプレミス環境101に構築される現用系サーバ103と、クラウド環境102に構築される待機系サーバ104とに対して、特定の順序に従って管理操作を実行することにより、管理者は、HAクラスタ100を運用した状態で、クラウド環境102に用意された待機系サーバ104の性能を動的に変更することが可能である。
また、本実施形態によれば、管理者は、係る待機系サーバ104の性能変更処理の際に、HAクラスタを構成する現用系サーバ103と、待機系サーバ104とに対する管理操作を、矛盾なく実行可能である、という効果を奏する。
更に、本実施形態においては、クラスタ制御部114は、特定の待機系サーバ104について性能変更処理が実行されているか否かを確認した結果に基づいて、フェイルオーバ処理を実行するため、不要なフェイルオーバの発生や、フェイルオーバの失敗によるサービスの停止を防ぐことができるという効果を奏する。
なお、本実施形態における情報処理装置は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。
<第3の実施形態>
次に、本発明の第3の実施形態について説明する。以下の説明においては、本実施形態に係る特徴的な構成を中心に説明する。その際、前記第1及び第2の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明は省略する。
本実施形態における情報処理装置は、前記第2の実施形態における情報処理装置と基本的な構成は同様であるが、現用系サーバ103を1台、待機系サーバを2台とした3つのノードにより、HAクラスタ100を構成している。以下、図16を参照して、本発明の第3の実施形態について説明する。
本実施形態における現用系サーバ103は、前記第2の実施形態における現用系サーバ103と基本的な構成は同一である。本実施形態における現用系サーバ103は、サービス1601及びサービス1602を実行し、係るサービスに関連するデータ1603a及びデータ1604aを、それぞれ記憶装置1603及び記憶装置1604に記録する。なお、図16に例示した構成においては、記憶装置1603及び記憶装置1604をそれぞれ独立した構成要素としているが、これらを統合して一つの記憶装置とし、データ1603a及びデータ1604aを記録するよう構成してもよい。
本実施形態においては、サービス1601のフェイルオーバに対応する待機系サーバとしてクラウド環境1605に待機系サーバ1607を設け、サービス1602のフェイルオーバに対応する待機系サーバとしてクラウド環境1606に待機系サーバ1608を設ける。なお、クラウド環境1605とクラウド環境1606は同一のクラウド事業者により提供されてもよく、異なるクラウド事業者により提供されてもよい。
待機系サーバ1607及び、待機系サーバ1608は、それぞれサービス1601に関するデータ1603a及び、サービス1602に関するデータ1604aをミラーリング可能な記憶装置1609及び記憶装置1610を備える。現用系サーバ103におけるクラスタ制御部114と、待機系サーバ1607におけるクラスタ制御部1613は、サービス1601に関係するデータ1603aを、データ1609aにミラーリングすると共に、現用系サーバ103に故障等の特定の事象が発生した際には、サービス1601を待機系サーバ1607において引き継いで実行するよう連携する。現用系サーバ103におけるクラスタ制御部114と、待機系サーバ1608におけるクラスタ制御部1614も同様に、サービス1602に関係するデータ1604aを、データ1610aにミラーリングすると共に、現用系サーバ103に故障等の特定の事象が発生した際には、サービス1602を待機系サーバ1608において引き継いで実行するよう連携する。
また、前記第2の実施形態と同様、管理端末110よりスケール管理部107に対してスケール変更指示を送信することにより、スケール変更部111がクラウド環境1605におけるクラウド管理装置1611と、クラウド環境1606におけるクラウド管理装置1612に対してスケール変更要求を送信し、各待機系サーバ1607及び1608の性能を変更できる。
上述した本実施形態によれば、複数のサービスに対して異なる運用方針を策定することにより、それぞれのサービスに関連付けされた待機系サーバのスケールレベル(性能)を個別に管理し、変更できる。このため、本実施形態に依れば、前記第2の実施形態と同様の効果を奏すると共に、運用コストの一層の低減や、サービスに対するフェイルオーバ処理の信頼性向上等の効果を奏する。
なお、図16に例示した構成においては、2つのサービス1601、1602に対して、2つの待機系サーバ1607、1608を用意しているが、本実施形態はこのような構成に限定されない。例えば、現用系サーバにおいて実行するサービスの数と、フェイルオーバ処理のために用意する待機系サーバの数は2つでなくともよく、また、これらの数が異なってもよい。現用系サーバにおいて実行するサービスの数よりも、フェイルオーバ処理が可能な待機系サーバの数が多ければ、サービスの稼働状態に対する信頼性を向上できる。現用系サーバにおいて実行するサービスの数よりも、フェイルオーバ処理が可能な待機系サーバの数が少なければ、運用コストを更に低減できる。
なお、本実施形態における性能管理部106aを実現する情報処理装置は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。
<第4の実施形態>
次に、本発明の第4の実施形態について説明する。以下の説明においては、本実施形態に係る特徴的な構成を中心に説明する。その際、前記第1乃至第3の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明は省略する。
本実施形態における情報処理装置は、前記第2の実施形態における情報処理装置と基本的な構成は同様であるが、前記第2の実施形態における管理端末108の代替として、性能管理部1701が組み合わされている。
本実施形態における性能管理部1701は、オンプレミス環境101に構築される現用系サーバ103における各種情報(性能情報や、発生したイベント情報等)を収集して分析することにより、現用系サーバ103に発生する障害の傾向を予測する。具体的には、性能管理部1701は、例えば現用系サーバを構成する演算処理装置(CPU)やメモリの使用率、記憶装置に対するアクセス回数と書き込みや読み込みの総データサイズ、通信ネットワークアクセス回数と総通信データサイズ、現用系サーバ103自体の連続稼働時間等の情報を収集し、係る収集したデータに対して統計処理等を実施することにより、現用系サーバを構成する要素にどのようは障害が発生するか予測してもよい。
本実施形態においては、管理者は、例えば、スケールレベル対応表107cにおけるエントリ605として、”平常時のレベル”(現用系サーバ103よりも性能が低いレベル)と、”フェイルオーバ対応レベル”(現用系サーバ103と同等の性能レベル)を設定してよい。
本実施形態において、性能分析部1701は、前記現用系サーバ103に対する障害発生の傾向分析の結果、障害傾向にある(障害が発生する蓋然性がある程度高い)と判定した場合には、スケール管理部107に対して、待機系サーバ104の性能レベルを前記”フェイルオーバ対応レベル”に変更するように、変更指示を送信する。また、性能分析部1701は、係る障害傾向が収まったと判定した場合には、スケール管理部107に対して、待機系サーバ104の性能レベルを前記”平常時のレベル”に変更するように、変更指示を送信する。
以上説明した本実施形態によれば、オンプレミス環境に構築した現用系サーバ103の障害傾向に応じて、クラウド環境102に構築した待機系サーバ104の性能を動的に変更できるため、現用系サーバ103において障害が発生した際には迅速にフェイルオーバ処理が可能であり、かつ平常時には運用コストをできる、という効果を奏する。
なお、本実施形態における性能管理部1701による障害傾向の予測は、前記例示に限定されず、現用系サーバ103の構成等に応じて、適宜適切な方法を採用してよい。
本実施形態における情報処理装置は、上述したように、情報処理システムの性能を管理する管理装置としても機能する。
<第5の実施形態>
次に、上述した各実施形態に共通する構成について、本発明の第5の実施形態として、図19を参照して説明する。図19は、本発明の第5の実施形態における情報処理装置の機能的な構成を例示するブロック図である。
図19に示すように、本実施形態における第1の情報処理システム1901は、サービス1905を実行する第1の情報処理部1904を有する。
本実施形態における第1の情報処理部1904は、第2の情報処理システム1902と通信可能に接続される。なお、本実施形態においては、第1の情報処理システム1901と、第2の情報処理システム1902とが、通信可能に接続されてもよい。
本実施形態における第2の情報処理システム1902は、第2の情報処理部1906を有する。本実施形態においては、第2の情報処理システム1902は、第2の情報処理部1906の性能を管理できる。
本実施形態における第2の情報処理部1906は、前記第1の情報処理システム1901において特定の事象(例えば、障害や故障等)が発生した際に、前記サービス1905の実行を、前記第1の情報処理部1904から引き継ぐ。
本実施形態における情報処理装置1903は、前記第2の情報処理システムに対して管理操作を実行する性能管理部1903aを有する。
本実施形態において、前記性能管理部1903aは、第2の情報処理システム1902に対して、特定の順序に従って管理操作を実行することにより、第2の情報処理部1906の性能を管理する。係る管理操作には、例えば、第2の情報処理部1906の性能を変更する処理を含めてもよい。なお、本実施形態における性能管理部1903aは、例えば、前記第1の情報処理システム1901と通信可能に接続されてもよく、前記第2の情報処理システム1902に対する管理操作と共に、前記第1の情報処理部1901に対する管理操作を実行してもよい。
上記説明した処理により、本実施系における情報処理装置1903によれば、第1の情報システム1901及び第2の情報システム1902を運用した状態で、第2の情報処理部1906の性能を管理することが可能である。また、係る第2の情報処理部1906の性能を管理する処理の際に、少なくとも、当該第2の情報処理部1906に対する前記管理操作を矛盾なく実行可能である、という効果を奏する。
なお、図19に例示した構成においては、本実施形態における情報処理装置1903は、前記第1の情報処理システム1901とは別の独立した構成要素として図示されているが、本実施形態はこのような構成に限定されない。本実施形態においては、例えば情報処理装置1903は、第1の情報処理システム1901や、第1の情報処理部1904を構成する構成要素として設けてもよい。
以上、本発明を、上述した模範的な実施形態に適用した例として説明した。しかしながら、本発明の技術的範囲は、上述した各実施形態に記載した範囲には限定されない。当業者には、係る実施形態に対して多様な変更または改良を加えることが可能であることは明らかである。そのような場合、係る変更または改良を加えた新たな実施形態も、本発明の技術的範囲に含まれ得る。そしてこのことは、特許請求の範囲に記載した事項から明らかである。
尚、上述した実施形態及びその変形例の一部または全部は、以下の付記のようにも記載されうる。しかしながら、上述した実施形態及びその変形例により例示的に説明した本発明は、以下には限られない。
(付記1)
特定のサービスを実行する第1の情報処理部を有する第1の情報処理システムに通信可能に接続され、当該第1の情報処理システムに特定の事象が発生した際に、前記第1の情報処理部と連携して、前記特定のサービスの実行を前記第1の情報処理部から引き継ぐフェイルオーバ処理を実行する第2の情報処理部を有する第2の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第2の情報処理部の性能を管理する性能管理部を有する、
情報処理装置。
(付記2)
前記性能管理部は、
前記第1の情報処理部と、前記第2の情報処理部と間の連携を解除し、
前記第2の情報処理部の性能を変更する性能変更処理を実行する、
付記1に記載の情報システムの管理装置。
(付記3)
前記性能管理部は、前記第2の情報処理部の性能に関する情報を含むスケールレベル設定情報に基づいて、前記性能変更処理を実行する、
付記2に記載の、情報処理装置。
(付記4)
前記性能管理部は、前記第2の情報処理部に対する前記性能変更処理を実行する際、当該性能変更処理の実行状態を含むスケール状態情報を更新する、
付記2または付記3に記載の、情報処理装置。
(付記5)
前記第2の情報処理システムが、1以上の仮想計算機を有し、当該仮想計算機を管理する管理要求を受け付ける仮想計算機環境を提供する場合に、
前記性能管理部は、前記第2の情報処理システムに対して、前記第2の情報処理システムを構成する仮想計算機である前記第2の情報処理部の処理性能を変更する管理要求を送信する、
付記2乃至付記4の何れかに記載の、情報処理装置。
(付記6)
前記性能管理部は、
前記第1の情報処理部における、前記特定のサービスに関するサービス関連情報を前記第2の情報処理部に複製する処理を停止し、
前記第1の情報処理部と、前記第2の情報処理部との間の前記フェイルオーバ処理のための連携を解除し、
前記第2の情報処理システムに対して、前記第2の情報処理部の処理性能を変更する管理要求を送信する、
付記5に記載の、情報処理装置。
(付記7)
前記第2の情報処理部の処理性能を変更する管理要求は、少なくとも、
前記第2の情報処理部を停止する要求と、
前記第2の情報処理部の性能を変更する要求と、
前記第2の情報処理部の状態を取得する要求と、
を含む、
付記5または付記6に記載の情報処理装置。
(付記8)
前記スケール状態情報を参照して前記性能管理部において前記第2の情報処理部の性能変更処理を実行中であるか否かを確認し、前記確認の結果、前記性能変更処理を実行中であると判定した場合、前記性能変更処理が完了するまで前記フェイルオーバ処理の実行を抑制するフェイルオーバ抑制部を、更に有する、
付記4乃至付記7の何れかに記載の情報処理装置。
(付記9)
前記第1の情報処理部が、複数の前記サービスを実行し、当該複数のサービスそれぞれに対して前記フェイルオーバ処理を実行する少なくとも1以上の前記第2の情報処理部を有する、少なくとも1以上の前記第2の情報処理システムが存在する場合に、
前記性能管理部は、当該第2の情報処理システムに対して、前記第2の情報処理部の処理性能を変更する管理要求を送信する、
付記5乃至付記8のいずれかに記載の情報処理装置。
(付記10)
前記第1の情報処理システムが、前記第1の情報処理システムにおいて発生し得る障害の傾向を分析し、当該分析結果に基づいて、前記第2の情報処理部の性能を変更する要求を前記性能管理部に送信する性能分析部を有する場合に、
前記性能管理部は、前記性能分析部から送信される要求に応じて、前記第2の情報処理部に対する前記性能変更処理を実行する、
付記5乃至付記9のいずれかに記載の情報処理装置。
(付記11)
前記第2の情報処理システムと、に通信可能に接続され、
前記第2の情報処理システムと通信可能に接続される前記第1の情報処理部の一部を構成するか、または当該第1の情報処理部と通信可能に接続される、
付記1乃至付記10に記載の情報システムの管理装置。
(付記12)
特定のサービスを実行する第1の情報処理部を有する第1の情報処理システムに通信可能に接続され、当該第1の情報処理システムに特定の事象が発生した際に、前記第1の情報処理部と連携して、前記特定のサービスの実行を前記第1の情報処理部から引き継ぐフェイルオーバ処理を実行する第2の情報処理部を有する第2の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第2の情報処理部の性能を管理する
情報処理方法。
(付記13)
情報処理プログラムであって、
特定のサービスを実行する第1の情報処理部を有する第1の情報処理システムに通信可能に接続され、当該第1の情報処理システムに特定の事象が発生した際に、前記第1の情報処理部と連携して、前記特定のサービスの実行を前記第1の情報処理部から引き継ぐフェイルオーバ処理を実行する第2の情報処理部を有する第2の情報処理システムに対して、特定の順序に従って管理操作を実行することにより、前記第2の情報処理部の性能を管理する処理を、コンピュータに実行させる、
プログラム。