(57)【要約】      （修正有）【課題】サービスに影響を与えることなく、システム全体のファイル更新に関する試験を行う分散処理システム及び分散処理方法を提供する。【解決手段】管理装置４０は、ＤＢ領域１２ａに対して、試験用の試験領域１２ｂをストレージ１２に設定する領域設定部４３７と、ファイル更新処理の際、アドレス割り当てが行われたＡＰサーバ１０のＶＭ２（更新予定の仮想マシン）及び、稼働状態（Ａｃｔ）であり試験領域１２ｂを参照するＤＢサーバ１１ＡのＶＭ２を対象にした所定の試験を実施し、アドレス割り当てが行われたＡＰサーバ１０のＶＭ２及び、待機状態（Ｓｔｂ）から稼働状態（Ａｃｔ）に切り替わったときに試験領域１２ｂを参照したＤＢサーバ１１ＢのＶＭ２を対象にした所定の試験を実施する試験実施部４３８と、を備える。【選択図】図１
2016143202.tif 000002
【特許請求の範囲】
【請求項１】
所定のサービスを提供するための１または複数の仮想マシンが作成される、複数のＡＰサーバ、運用系ＤＢサーバ、および、待機系ＤＢサーバと、
前記運用系ＤＢサーバおよび前記待機系ＤＢサーバが参照するＤＢ領域が設定されるストレージと、
外部装置からのアクセスの振り分け先となる前記ＡＰサーバの仮想マシンを選択する振り分け装置と、
前記ＡＰサーバ、前記運用系ＤＢサーバ、前記待機系ＤＢサーバ、前記ストレージ、および前記振り分け装置を制御する管理装置と、を備える分散処理システムであって、
前記管理装置は、
前記ＤＢ領域に対して、試験用の試験領域を前記ストレージに設定する領域設定部と、
前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの各々に、新たな仮想マシンを作成させ、前記ＡＰサーバの新たな仮想マシンに対しアドレス割り当てを行う仮想マシン制御部と、
前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に対しファイル更新処理を行うファイル更新部と、
前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、稼働状態であり前記試験領域を参照する前記運用系ＤＢサーバの新たな仮想マシンを対象にした所定の試験を実施し、
前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、待機状態から稼働状態に切り替わったときに前記試験領域を参照した前記待機系ＤＢサーバの新たな仮想マシンを対象にした前記所定の試験を実施する試験実施部と、を備える、
ことを特徴とする分散処理システム。
【請求項２】
前記管理装置は、
前記ファイル更新処理によって、前記アクセスの振り分け先となる前記ＡＰサーバの仮想マシンのアドレスのすべてを、当該ＡＰサーバの前記新たな仮想マシンのアドレスに更新するアドレス情報更新部と、をさらに備える、
ことを特徴とする請求項１に記載の分散処理システム。
【請求項３】
前記管理装置は、
前記ファイル更新処理の完了後であっても、所定の条件を満たすまでは、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの各々において、前記所定のサービスを提供するために元々作成されていた前記仮想マシンと、前記仮想マシン制御部によって作成された前記新たな仮想マシンとを併存させる、
ことを特徴とする請求項１または請求項２に記載の分散処理システム。
【請求項４】
前記管理装置は、
前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に対し、当該ＡＰサーバ、当該運用系ＤＢサーバ、および当該待機系ＤＢサーバの余剰リソースからリソースの割り当てを行うリソース割り当て部と、をさらに備え、
前記リソース割り当て部は、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に、少なくとも１コール分の処理を実行可能なリソースを割り当てる、
ことを特徴とする請求項１から請求項３のいずれか一項に記載の分散処理システム。
【請求項５】
所定のサービスを提供するための１または複数の仮想マシンが作成される、複数のＡＰサーバ、運用系ＤＢサーバ、および、待機系ＤＢサーバと、
前記運用系ＤＢサーバおよび前記待機系ＤＢサーバが参照するＤＢ領域が設定されるストレージと、
外部装置からのアクセスの振り分け先となる前記ＡＰサーバの仮想マシンを選択する振り分け装置と、
前記ＡＰサーバ、前記運用系ＤＢサーバ、前記待機系ＤＢサーバ、前記ストレージ、および前記振り分け装置を制御する管理装置と、を備える分散処理システムにて、
前記管理装置が、
前記ＤＢ領域に対して、試験用の試験領域を前記ストレージに設定する領域設定ステップと、
前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの各々に、新たな仮想マシンを作成させ、前記ＡＰサーバの新たな仮想マシンに対しアドレス割り当てを行う仮想マシン制御ステップと、
前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に対しファイル更新処理を行うファイル更新ステップと、
前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、稼働状態であり前記試験領域を参照する前記運用系ＤＢサーバの新たな仮想マシンを対象にした所定の試験を実施し、
前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、待機状態から稼働状態に切り替わったときに前記試験領域を参照した前記待機系ＤＢサーバの新たな仮想マシンを対象にした前記所定の試験を実施する試験実施ステップ、とを実行する、
ことを特徴とする分散処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバからなるシステムの分散処理の技術に関し、特に、システムのファイル更新の技術に関する。
【背景技術】
【０００２】
以下の説明において、「ＡＰ」はアプリケーション、「ＤＢ」はデータベースを表す。また、「Ａｃｔ」（Active）は稼働、運用、または、オンラインを表し、「Ｓｔｂ」（Standby）は、待機、または、オフラインを表す。また、「サーバ」という語は、ＡＰサーバおよびＤＢサーバを包含する。
【０００３】
システムのファイル更新に関する技術として、例えば特許文献１の技術がある。特許文献１には、Ｎ台構成のシステムに、追加リソースとしてさらにＮ台のファイル更新用のサーバを用意し、このＮ台のサーバで並行してファイル更新を行う技術が開示されている。このような方法によれば、サービスに影響を与えることなく、短時間でシステム内の各サーバのファイル更新を行うことができる。
【０００４】
Ｎ＋１台のＡＰサーバからなるＡｃｔシステム、および、運用系（０系）／待機系（１系）のＤＢサーバからなるＡｃｔ／Ｓｔｂシステムで構成され、分散処理を行って所定のサービスを提供する分散処理システムに関して、サービスの提供中にＡＰサーバおよびＤＢサーバのファイル更新を行いたいという要望がある。このファイル更新の際には、サービスの品質維持のために、ＡＰサーバ〜ＤＢサーバを通したシステム全体に対する所定の試験（例：１コール試験）を行うことが欠かせない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−９６１６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来では、ＤＢサーバのファイル更新に関しては、運用系／待機系の切替前に、システム全体に対する事前試験を行うことができない。つまり、従来では、オフラインであるため試験用の１コールを処理できない待機系のＤＢサーバについては、まず、ファイル更新を実施した後、運用系／待機系の切替をし、運用系としたとき初めて、システム全体の１コール試験が実施可能な状態になる。しかし、切替が完了すれば、端末（エンドユーザ）がサービスを利用することができる（リリースが完了）状態にもなる。よって、運用系に切り替わった元待機系のＤＢサーバについては、サービスの提供後に１コール試験を行わざるを得なかった。その結果、ファイル更新が実施されてもサービス提供を開始するまでにシステム全体に内在する不具合を発見することができない、という問題がある。
【０００７】
しかし、特許文献１の技術を含め、上記した事前試験に関する問題を解消できる技術は何ら開示されていない。
【０００８】
そこで、本発明は、上記事情に鑑みて、サービスに影響を与えることなく、システム全体のファイル更新に関する試験を行うことができるようにすることを課題とする。
【課題を解決するための手段】
【０００９】
前記課題を解決するために、請求項１の発明は、所定のサービスを提供するための１または複数の仮想マシンが作成される、複数のＡＰサーバ、運用系ＤＢサーバ、および、待機系ＤＢサーバと、前記運用系ＤＢサーバおよび前記待機系ＤＢサーバが参照するＤＢ領域が設定されるストレージと、外部装置からのアクセスの振り分け先となる前記ＡＰサーバの仮想マシンを選択する振り分け装置と、前記ＡＰサーバ、前記運用系ＤＢサーバ、前記待機系ＤＢサーバ、前記ストレージ、および前記振り分け装置を制御する管理装置と、を備える分散処理システムであって、前記管理装置は、前記ＤＢ領域に対して、試験用の試験領域を前記ストレージに設定する領域設定部と、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの各々に、新たな仮想マシンを作成させ、前記ＡＰサーバの新たな仮想マシンに対しアドレス割り当てを行う仮想マシン制御部と、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に対しファイル更新処理を行うファイル更新部と、前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、稼働状態であり前記試験領域を参照する前記運用系ＤＢサーバの新たな仮想マシンを対象にした所定の試験を実施し、前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、待機状態から稼働状態に切り替わったときに前記試験領域を参照した前記待機系ＤＢサーバの新たな仮想マシンを対象にした前記所定の試験を実施する試験実施部と、を備える、ことを特徴とする。
【００１０】
また、請求項５の発明は、所定のサービスを提供するための１または複数の仮想マシンが作成される、複数のＡＰサーバ、運用系ＤＢサーバ、および、待機系ＤＢサーバと、前記運用系ＤＢサーバおよび前記待機系ＤＢサーバが参照するＤＢ領域が設定されるストレージと、外部装置からのアクセスの振り分け先となる前記ＡＰサーバの仮想マシンを選択する振り分け装置と、前記ＡＰサーバ、前記運用系ＤＢサーバ、前記待機系ＤＢサーバ、前記ストレージ、および前記振り分け装置を制御する管理装置と、を備える分散処理システムにて、前記管理装置が、前記ＤＢ領域に対して、試験用の試験領域を前記ストレージに設定する領域設定ステップと、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの各々に、新たな仮想マシンを作成させ、前記ＡＰサーバの新たな仮想マシンに対しアドレス割り当てを行う仮想マシン制御ステップと、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に対しファイル更新処理を行うファイル更新ステップと、前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、稼働状態であり前記試験領域を参照する前記運用系ＤＢサーバの新たな仮想マシンを対象にした所定の試験を実施し、前記アドレス割り当てが行われたＡＰサーバの新たな仮想マシン、および、待機状態から稼働状態に切り替わったときに前記試験領域を参照した前記待機系ＤＢサーバの新たな仮想マシンを対象にした前記所定の試験を実施する試験実施ステップ、とを実行する、ことを特徴とする分散処理方法である。
【００１１】
請求項１、５の発明によれば、試験実施部（試験実施ステップ）による２つの試験は、現在サービスを提供している仮想マシンとは独立した新たな仮想マシンを対象にすることができる。このため、これらの試験は、新たな仮想マシンによるサービスのリリースが完了する前に行うことができる。よって、ファイル更新が実施されてもサービス提供を開始するまでにシステム全体に内在する不具合を発見することができる。したがって、本実施形態の分散処理システムは、サービスに影響を与えることなく、システム全体のファイル更新に関する試験を行うことができるようにする。
【００１２】
また、請求項２の発明は、請求項１に記載の分散処理システムであって、前記管理装置は、前記ファイル更新処理によって、前記アクセスの振り分け先となる前記ＡＰサーバの仮想マシンのアドレスのすべてを、当該ＡＰサーバの前記新たな仮想マシンのアドレスに更新するアドレス情報更新部と、をさらに備える、ことを特徴とする。
【００１３】
請求項２の発明によれば、ファイル更新処理によって、アクセスの振り分け先となるＡＰサーバの仮想マシンのアドレスのすべてを、当該ＡＰサーバの新たな仮想マシンのアドレスに同じタイミングで更新することができるため、ＡＰサーバのファイル更新に要する時間を短縮することができる。このとき、新たな仮想マシンをＡＰサーバの各々に作成するため、余剰リソースとなるＡＰサーバの追加は必要としない。
【００１４】
また、請求項３の発明は、請求項１または請求項２に記載の分散処理システムであって、前記管理装置は、前記ファイル更新処理の完了後であっても、所定の条件を満たすまでは、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの各々において、前記所定のサービスを提供するために元々作成されていた前記仮想マシンと、前記仮想マシン制御部によって作成された前記新たな仮想マシンとを併存させる、ことを特徴とする。
【００１５】
請求項３の発明によれば、ＡＰサーバ、運用系ＤＢサーバ、待機系ＤＢサーバの各々において作成される仮想マシンおよび新たな仮想マシンは互いに影響を及ぼすことなく独立に稼働することができるため、更新ファイルの切り戻しを簡略化することができ、労力を大幅に削減することができる。
【００１６】
また、請求項４の発明は、請求項１から請求項３のいずれか一項に記載の分散処理システムであって、前記管理装置は、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に対し、当該ＡＰサーバ、当該運用系ＤＢサーバ、および当該待機系ＤＢサーバの余剰リソースからリソースの割り当てを行うリソース割り当て部と、をさらに備え、前記リソース割り当て部は、前記ＡＰサーバ、前記運用系ＤＢサーバ、および前記待機系ＤＢサーバの新たな仮想マシンの各々に、少なくとも１コール分の処理を実行可能なリソースを割り当てる、ことを特徴とする。
【００１７】
請求項４の発明によれば、ＡＰサーバ、運用系ＤＢサーバ、待機系ＤＢサーバに作成される新たな仮想マシンに対して試験を行う場合、リソースの割り当てを最小限に抑えることができる。
【発明の効果】
【００１８】
本発明によれば、サービスに影響を与えることなく、システム全体のファイル更新に関する試験を行うことができるようにする。
【図面の簡単な説明】
【００１９】
【図１】分散処理システムの構成の一例を示す図である。
【図２】アドレス情報の一例を示す図である。
【図３】管理装置の処理手順を示すフローチャートである。
【図４】分散処理システム全体の事前試験を説明する図である。
【図５】分散処理システム全体の事前試験を説明する図である。
【図６】分散処理システムにおけるサービスリリースを説明する図である。
【図７】複数のＡＰサーバについて、ＶＭを一斉に切り替える様子を説明する図である。
【図８】トラブル発生時にて、更新したＶＭの切り戻しを説明する図である。
【図９】分散処理システムにおける稼働中のＶＭおよびファイル更新の対象となる新たなＶＭのリソースの割り当てイメージを説明する図である。
【図１０】管理プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００２０】
本発明を実施するための形態（実施形態）について、図面を参照しながら詳細に説明する。
【００２１】
〔全体構成〕
図１に示すように、本実施形態の分散処理システムは、稼働サーバとなるＮ＋１台のＡＰサーバ１０と、２台のＤＢサーバ１１と、サービスを利用するための端末３０のアクセスを受けるロードバランサ（振り分け装置）２０と、試験装置５０による試験を制御する管理装置４０とを備える。
【００２２】
ＡＰサーバ１０はそれぞれ、稼働サーバであり、端末３０からのアクセスに基づく処理を実行することで所定のサービスを提供する。このＡＰサーバ１０は仮想マシン（ＶＭ:Virtual Machine）、および、ＶＭを作成し制御するホストＯＳ（Operating  System）を備える。なお、図１において、ＡＰサーバ１０はＡＰサーバ１０Ａ〜１０Ｃの３台しか描いていないが、実際にはＮ＋１台のＡＰサーバ１０が用意される。
【００２３】
ＤＢサーバ１１は、所定のデータベース管理システムが動作し、サービスの提供に必要なデータを管理する。このＤＢサーバ１１は、運用状況に応じて運用系（０系）または待機系（１系）に切り替わる。また、ＤＢサーバ１１は、仮想マシン、および、ＶＭを作成し制御するホストＯＳを備える。説明の便宜上、図１には、ＤＢサーバ１１として、ＤＢサーバ１１Ａ，１１Ｂの２台があるとするが、３台以上のＤＢサーバ１１を用意してもよい。
【００２４】
ストレージ１２は、ＤＢサーバ１１が管理するデータを記憶する外部記憶装置である。ストレージ１２には、ＤＢサーバ１１が管理するデータを読み書きするための作業領域となるＤＢ領域１２ａが設定される。また、ストレージ１２には、書き込み可能なＤＢ領域１２ａのスナップショットである試験領域１２ｂが設定される。
【００２５】
ロードバランサ２０は、インターネット等のネットワーク経由で端末３０からのアクセスを受け付けると、このアクセスをいずれかのＡＰサーバ１０のＶＭに振り分ける。ロードバランサ２０の詳細については後記する。
【００２６】
管理装置４０は、ＡＰサーバ１０、ＤＢサーバ１１、ストレージ１２、ロードバランサ２０、および試験装置５０の制御を行う。管理装置４０は、例えば、ＡＰサーバ１０のファイル更新や、ＤＢサーバ１１のファイル更新を行なったり、ロードバランサ２０に対し、端末３０からのアクセスの振り分け先の変更を指示したりする。
【００２７】
また、管理装置４０は、ＡＰサーバ１０の各々、および、ＤＢサーバ１１の各々にて、２つのＶＭをＶＭ１，ＶＭ２として作成する。ＶＭ１は、サービスの提供用として現在稼働中のＶＭであり、ＶＭ２は、ファイル更新用に新たに作成される更新予定のＶＭ（新たな仮想マシン）である。管理装置４０の詳細については後記する。
なお、管理装置４０は、ＤＢサーバ１１に関しては、１つのＤＢサーバ１１に作成されるＶＭごとに稼働状態（Ａｃｔ）および待機状態（Ｓｔｂ）を登録することができる。
【００２８】
試験装置５０は、ＡＰサーバ１０およびＤＢサーバ１１（さらにストレージ１２を含めてもよい）に対し試験を実施する。例えば、試験装置５０はＡＰサーバ１０およびＤＢサーバ１１のファイル更新が行われたとき、当該ＡＰサーバ１０および当該ＤＢサーバ１１が正常に動作するか否かを確認するための試験（例：１コール試験）を行う。
【００２９】
（ロードバランサ２０）
ロードバランサ２０は、ネットワーク経由で端末３０（外部装置）等からのアクセスを受け付けると、このアクセスをいずれかのＡＰサーバ１０のＶＭに振り分ける。ロードバランサ２０は、アドレス情報２１と、振り分け部２２とを備える。
【００３０】
アドレス情報２１は、端末３０からのアクセスの振り分け先となるＶＭのアドレス（ＩＰアドレス）を示した情報である。このＩＰアドレスは、例えば、ＲＩＰ（Real IP address）が用いられる。また、ロードバランサ２０にはＶＩＰ（Virtual IP address）が設定される。例えば、アドレス情報２１は、図２に示すように、ロードバランサ２０のＶＩＰに対し、当該ＶＩＰ宛のアクセスの振り分け先となるＶＭのＲＩＰが示される。図２の左側に示すアドレス情報２１において、ＶＩＰ「ａａａ」宛のアクセスの振り分け先は、ＲＩＰ１「ＲＩＰ１Ａ，ＲＩＰ１Ｂ，ＲＩＰ１Ｃ，・・・」のいずれかのアドレスのＶＭであることを示す。ここで、ＲＩＰ１Ａ，ＲＩＰ１Ｂ，ＲＩＰ１Ｃ，・・・はそれぞれ、ＡＰサーバ１０Ａ，１０Ｂ，１０ＣそれぞれのＶＭ１（「旧ＶＭ」と称する場合がある）に割り当てられたＲＩＰである。ロードバランサ２０は、ＡＰサーバ１０Ａ，１０Ｂ，１０Ｃ，・・・それぞれのＶＭ１に端末３０等からのアクセスを振り分ける。
【００３１】
このアドレス情報２１は、管理装置４０により更新される。その結果、図２の右側に示すアドレス情報２１において、ＶＩＰ「ａａａ」宛のアクセスの振り分け先は、ＲＩＰ２「ＲＩＰ２Ａ，ＲＩＰ２Ｂ，ＲＩＰ２Ｃ，…」のいずれかのアドレスのＶＭに変更される。ここで、ＲＩＰ２Ａ，ＲＩＰ２Ｂ，ＲＩＰ２Ｃ，・・・はそれぞれ、ＡＰサーバ１０Ａ，１０Ｂ，１０ＣそれぞれのＶＭ２（「新たなＶＭ」と称する場合がある）に割り当てられたＲＩＰである。ロードバランサ２０は、ＡＰサーバ１０Ａ，１０Ｂ，１０Ｃ，・・・それぞれのＶＭ２に端末３０等からのアクセスを振り分ける。
【００３２】
ロードバランサ２０のアドレス情報２１が更新され、ＶＩＰへの関連付けを、ＶＭ１に割り当てられたＲＩＰ１から、新たなＶＭ２のＲＩＰ２に変更すると、ＶＩＰ宛のアクセスをＶＭ２へ振り分けることができる。その結果、ＡＰサーバ１０の各々で、端末３０からのＶＩＰ宛のアクセスは、ＶＭ１からＶＭ２に切り替えられることになる。
【００３３】
振り分け部２２は端末３０からのアクセスの振り分けを行う。具体的には、振り分け部２２は、端末３０からのアクセスを受け付けたとき、アドレス情報２１を参照して、アクセス先のＶＭを選択し、この選択したＶＭへアクセスを振り分ける。
【００３４】
（管理装置４０）
管理装置４０は、入出力部４１と、通信部４２と、制御部４３と、記憶部４４とを備える。
【００３５】
入出力部４１は、図示しないＨＭＩ（Human Machine Interface）装置等から、当該管理装置４０に対する様々な指示入力や設定情報の入力を受け付ける。例えば、入出力部４１は、ＨＭＩ装置等から、各ＡＰサーバ１０のファイル更新の指示入力を受け付けたり、ロードバランサ２０に関する設定情報の入力を受け付けたりする。この入出力部４１は、ＨＭＩ装置等とのデータ入出力を行う入出力インタフェースにより実現される。
【００３６】
通信部４２は、ロードバランサ２０、ＡＰサーバ１０、ＤＢサーバ１１、ストレージ１２等との間でデータ通信を行う。例えば、通信部４２は、ロードバランサ２０内のアドレス情報２１の更新に関する情報をロードバランサ２０に送信したり、ＡＰサーバ１０やＤＢサーバ１１に対しファイル更新の指示を送信したり、ＡＰサーバ１０やＤＢサーバ１１からバックアップデータを受信したりする。この通信部４２は、所定の通信プロトコルによりＨＭＩ装置等との間でデータ通信を行う通信インタフェースにより実現される。
【００３７】
制御部４３は、管理装置４０全体の制御を司り、仮想マシン制御部４３１と、リソース割り当て部４３２と、ファイル更新部４３３と、ロードバランサ制御部４３４と、アドレス情報更新部４３５と、バックアップ部４３６と、領域設定部４３７と、試験実施部４３８とを備える。これらの各部の説明は後記する。この制御部４３は、管理装置４０の備えるＣＰＵ（Central  Processing  Unit）によるプログラム実行処理や、専用のハードウェアにより実現される。
【００３８】
記憶部４４は、新たなＶＭのバックアップデータや、システム内のサーバやＶＭのアドレス、それぞれのサーバやＶＭへの割り当てリソース、ロードバランサ２０の設定情報等を記憶する。この記憶部４４は、管理装置４０の備えるＨＤＤ（Hard  Disk  Drive）やＲＡＭ（Random  Access  Memory）等の記憶手段により実現される。
【００３９】
仮想マシン制御部４３１は、通信部４２経由で、ＡＰサーバ１０およびＤＢサーバ１１の各々のＶＭの制御を行う。具体的には、仮想マシン制御部４３１は、入出力部４１経由でＡＰサーバ１０およびＤＢサーバ１１の各々のファイル更新の指示入力を受け付けると、ＡＰサーバ１０およびＤＢサーバ１１それぞれに、ファイル更新用の新たなＶＭを作成させ、この新たなＶＭに対しアドレス（例えば、ＲＩＰ）の割り当てを行う。また、例えば、新たなＶＭの稼働開始後、入出力部４１経由でＡＰサーバ１０およびＤＢサーバ１１の各々から旧ＶＭの削除の指示入力を受け付けると、ＡＰサーバ１０およびＤＢサーバ１１それぞれに、旧ＶＭを削除させる。
【００４０】
リソース割り当て部４３２は、ＡＰサーバ１０およびＤＢサーバ１１の各々のＶＭへのリソースの割り当てを行う。例えば、リソース割り当て部４３２は、ＡＰサーバ１０およびＤＢサーバ１１の各々に新たなＶＭが作成されると、この新たなＶＭへのリソースの割り当てを行う。この新たなＶＭへのリソースの割り当ては、この新たなＶＭが作成されたＡＰサーバ１０またはＤＢサーバ１１において、稼働中のＶＭに割り当てられていないリソース（余剰リソース）から割り当てられる。なお、システム内のＡＰサーバ１０およびＤＢサーバ１１の各々には、例えば、１台分のサーバのリソースを、分散システムを構成するサーバの台数（Ｎ＋３）で割った分のリソースが予備リソースとして確保されている。よって、１台のサーバで稼働中のＶＭが利用可能なリソースをフルで使っていた場合でも、この予備リソースを用いて新たなＶＭへのリソース割り当てが可能である。
【００４１】
ファイル更新部４３３は、新たなＶＭそれぞれに対しファイル更新処理を行う。具体的には、ファイル更新部４３３は、ＡＰサーバ１０およびＤＢサーバ１１の各々に対し、当該ＡＰサーバ１０およびＤＢサーバ１１の各々で稼働中のＶＭを、当該ＶＭで作成された新たなＶＭへコピーさせ、この新たなＶＭに対しファイル更新処理を行う。
【００４２】
ロードバランサ制御部４３４は、ロードバランサ２０の閉塞、および、閉塞の解除を行う。「ロードバランサ２０の閉塞」とは、ロードバランサ２０によるアクセスの振り分けを所定期間だけ停止状態にすることをいう。例えば、ロードバランサ制御部４３４は、ファイル更新部４３３により新たなＶＭへのファイル更新処理が行われた後、ロードバランサ２０を閉塞し、アドレス情報更新部４３５によりロードバランサ２０のアドレス情報２１の更新が行われた後、閉塞を解除する。
【００４３】
アドレス情報更新部４３５は、ロードバランサ制御部４３４がロードバランサ２０を閉塞した後、ロードバランサ２０のアドレス情報２１におけるＶＭのアドレスを、新たなＶＭのアドレスに更新する。これにより、例えば、図２に示したようなアドレスの切り替えがなされる。そして、ロードバランサ２０の閉塞解除後、ロードバランサ２０が端末３０からのアクセスを受け付けると、この更新後のアドレス情報２１をもとに端末３０からのアクセスの振り分けを行う。つまり、端末３０からのアクセスはファイル更新がされた新たなＶＭへ振り分けされる。
【００４４】
バックアップ部４３６は、ＡＰサーバ１０およびＤＢサーバ１１の各々の新たなＶＭのバックアップ処理を行う。具体的には、ＡＰサーバ１０およびＤＢサーバ１１の各々の新たなＶＭへのファイル更新後、この新たなＶＭに対し試験装置５０が試験を実施し、正常な動作が確認されると、この新たなＶＭそれぞれのバックアップを取る。バックアップデータは、記憶部４４の所定領域に格納される。
【００４５】
領域設定部４３７は、サービス提供のために、ＤＢサーバ１１が参照するＤＢ領域１２ａをストレージ１２に設定する。また、領域設定部４３７は、ファイル更新後の試験を実施するために、ＤＢサーバ１１が参照する試験領域１２ｂをストレージ１２に設定する。
【００４６】
試験実施部４３８は、試験装置５０にファイル更新に対する試験を実施させる。
【００４７】
〔処理〕
図３を主に参照して、ファイル更新に関する管理装置４０の処理手順について説明する。
【００４８】
まず、仮想マシン制御部４３１は、入出力部４１を介して、システムのファイル更新の指示入力を受け付ける（ステップＳ１）。
次に、管理装置４０は、システムのＮ＋１台のＡＰサーバ１０および２台のＤＢサーバ１１の更新ファイルの準備を行う（ステップＳ２）。
次に、領域設定部４３７は、ストレージ１２に試験領域１２ｂを設定する（ステップＳ３）。
次に、仮想マシン制御部４３１は、ＡＰサーバ１０およびＤＢサーバ１１に、新たなＶＭの作成を指示する（ステップＳ４）。
次に、リソース割り当て部４３２は、ＡＰサーバ１０およびＤＢサーバ１１の新たなＶＭへのリソースの割り当てを行う（ステップＳ５）。
次に、仮想マシン制御部４３１は、新たなＶＭそれぞれへのアドレス割り当てを行う（ステップＳ６）。
【００４９】
次に、ファイル更新部４３３は、新たなＶＭそれぞれに対しファイル更新を指示する（ステップＳ７）。例えば、ファイル更新部４３３は、更新ファイルをＡＰサーバ１０およびＤＢサーバ１１の各々へ送信する。そして、ＡＰサーバ１０およびＤＢサーバ１１の各々は、自サーバで稼働中のＶＭを新たなＶＭへコピーした後、この更新ファイルによるファイル更新を行う。
【００５０】
次に、試験実施部４３８が試験装置５０に対し、ＡＰサーバ１０およびＤＢサーバ１１の各々の新たなＶＭ（ファイル更新後のＶＭ）への試験の実施指示を行う（ステップＳ８）。
ステップＳ８にて、新たなＶＭが正常に動作することを確認できた場合、バックアップ部４３６が新たなＶＭのバックアップ処理を行う（ステップＳ９）。
【００５１】
次に、ロードバランサ制御部４３４がロードバランサ２０を閉塞する（ステップＳ１０）。
次に、アドレス情報更新部４３５がロードバランサ２０のアドレス情報２１の更新を行う（ステップＳ１１）。つまり、アドレス情報更新部４３５は、アドレス情報２１におけるＶＭのアドレスを、新たなＶＭのアドレスに変更する。
次に、ロードバランサ制御部４３４はロードバランサ２０の閉塞を解除する（ステップＳ１２）。これにより、ロードバランサ２０は、更新後のアドレス情報２１を参照して、アクセスの振り分けを行うので、新たなＶＭへのアクセスが振り分けられる。
以上により、ファイル更新に関する管理装置４０の処理手順が完了する。
【００５２】
（事前試験）
図３で示したファイル更新に関する試験は、サービスの提供中であっても、ＡＰサーバ１０の新たなＶＭ、および、稼働状態であり試験領域１２ｂを参照する運用系のＤＢサーバ１１の新たなＶＭを対象にした１コール試験と、ＡＰサーバ１０の新たなＶＭ、および、待機状態（Ｓｔｂ）から稼働状態（Ａｃｔ）に切り替わったときに試験領域１２ｂを参照した待機系のＤＢサーバ１１の新たなＶＭを対象にした１コール試験として実施することができる。
【００５３】
図４に示すように、分散処理システムにおいて、ロードバランサ２０と、ＡＰサーバ１０のＶＭ１と、ＤＢサーバ１１ＡのＶＭ１（Ａｃｔ）と、ストレージ１２のＤＢ領域１２ａとは、オンライン状態で連携している（符号ａ１，ａ２の矢印参照）。そのため、ＡＰサーバ１０のＶＭ１による所定のサービスが、端末３０に対して提供中となっている。
【００５４】
ファイル更新の指示があると、ＤＢ領域１２ａのスナップショットとして試験領域１２ｂがストレージ１２に設定される（図３のステップＳ３参照）。また、ＤＢサーバ１１Ａ，１１Ｂに関して、すでに作成済みのＶＭ１とは異なる、ファイル更新用として更新予定のＶＭ２が作成され（図３のステップＳ４参照）、所定量のリソースが割り当てられる（図３のステップＳ５参照）。
【００５５】
ＤＢサーバ１１ＡのＶＭ２は、ストレージ１２の試験領域１２ｂをマウント（利用可能状態化）し、ＤＢサーバ１１Ａのデータベース管理システムを動作可能にし（符号ｂ２の矢印参照）、ＡＰサーバ１０からの接続を受け付ける。これにより、管理装置４０は、（０系）ＤＢサーバ１１ＡのＶＭ２を稼働状態（Ａｃｔ）として記憶部４４に登録する。なお、ＤＢサーバ１１ＡのＶＭ１は、ストレージ１２のＤＢ領域１２ａをマウントし、ＤＢサーバ１１Ａのデータベース管理システムを動作可能としており（符号ａ２の矢印参照）、ＡＰサーバ１０からの接続を受け付けている。また、管理装置４０は、（１系）ＤＢサーバ１１ＢのＶＭ２を待機状態（Ｓｔｂ）として記憶部４４に登録する。
【００５６】
管理装置４０は、ＤＢサーバ１１ＡのＶＭ２とＤＢサーバ１１ＢのＶＭ２とを関連付けるように処理し（図４では、この関連付けを「ＨＡ」で示す）、ファイル更新後のサービス提供に対する高可用性（ＨＡ：High Availability）を実現する。なお、管理装置４０は、ＤＢサーバ１１ＡのＶＭ１およびＤＢサーバ１１ＢのＶＭ１に対しても同様の関連付けを行っており、提供中のサービスに関する高可用性を実現している。
【００５７】
一方、ＡＰサーバ１０の各々に関して、すでに作成済みのＶＭ１とは異なる、ファイル更新用として更新予定のＶＭ２が作成され（図３のステップＳ４参照）、所定量のリソースが割り当てられる（図３のステップＳ５参照）。管理装置４０は、ＡＰサーバ１０のＶＭ２を、ＤＢサーバ１１ＡのＶＭ２と関連付けて記憶部４４に登録する。ＡＰサーバ１０の各々にて、ＶＭ１にＲＩＰ１が割り当てられているのに対してＶＭ２にはＲＩＰ２が割り当てられる（図３のステップＳ６参照）。なお、ＤＢサーバ１１Ａ，１１Ｂにも所定のＩＰアドレスがＶＭごとに割り当てられているが図４では図示を省略している。
【００５８】
したがって、試験領域１２ｂを参照可能なＤＢサーバ１１ＡのＶＭ２と連携するＡＰサーバ１０のＶＭ２に対して、試験装置５０による１コール試験が実施できる状態になる。ＡＰサーバ１０のＶＭ２、ＤＢサーバ１１ＡのＶＭ２（Ａｃｔ）、および試験領域１２ｂ（符号ｂ１，ｂ２の矢印参照）は、オンライン状態で連携している、ＡＰサーバ１０のＶＭ１、ＤＢサーバ１１ＡのＶＭ１（Ａｃｔ）、およびＤＢ領域１２ａ（符号ａ１，ａ２の矢印参照）とは独立に存在している。このため、ＡＰサーバ１０のＶＭ２、ＤＢサーバ１１ＡのＶＭ２（Ａｃｔ）、および試験領域１２ｂに対する１コール試験は、ＡＰサーバ１０のＶＭ１、ＤＢサーバ１１ＡのＶＭ１（Ａｃｔ）、ＤＢ領域１２ａによるサービス提供を妨げることなく実施される（図３のステップＳ８参照）。
【００５９】
また、図５に示すように、ＤＢサーバ１１ＢのＶＭ２が、ストレージ１２の試験領域１２ｂをマウントし、ＤＢサーバ１１Ｂのデータベース管理システムを動作可能にし（符号ｂ４の矢印参照）、ＡＰサーバ１０からの接続を受け付ける。なお、ＤＢサーバ１１ＡのＶＭ２は、ストレージ１２の試験領域１２ｂをアンマウントする（破線の矢印参照）。管理装置４０は、ＡＰサーバ１０のＶＭ２を、ＤＢサーバ１１ＢのＶＭ２と関連付けて記憶部４４に登録する。これにより、管理装置４０は、ＤＢサーバ１１ＡのＶＭ２を稼働状態（Ａｃｔ）から待機状態（Ｓｔｂ）にするとともに、ＤＢサーバ１１ＢのＶＭ２を待機状態（Ｓｔｂ）から稼働状態（Ａｃｔ）にし、ＤＢサーバ１１Ａ，１１Ｂ間のＶＭ２について運用系を切り替える。
【００６０】
したがって、試験領域１２ｂを参照可能となったＤＢサーバ１１ＢのＶＭ２と連携するＡＰサーバ１０のＶＭ２に対して、試験装置５０による１コール試験が実施できる状態になる。ＡＰサーバ１０のＶＭ２、ＤＢサーバ１１ＢのＶＭ２（Ａｃｔ）、および試験領域１２ｂ（符号ｂ３，ｂ４の矢印参照）は、オンライン状態で連携している、ＡＰサーバ１０のＶＭ１、ＤＢサーバ１１ＡのＶＭ１（Ａｃｔ）、およびＤＢ領域１２ａ（符号ａ１，ａ２の矢印参照）とは独立に存在している。このため、ＡＰサーバ１０のＶＭ２、ＤＢサーバ１１ＡのＶＭ２（Ａｃｔ）、および試験領域１２ｂに対する１コール試験は、ＡＰサーバ１０のＶＭ１、ＤＢサーバ１１ＡのＶＭ１（Ａｃｔ）、ＤＢ領域１２ａによるサービス提供を妨げることなく実施される（図３のステップＳ８参照）。
【００６１】
図４、図５を用いて説明した１コール試験にて、安定的運用の確認がなされれば、図６に示すように、サービス提供を行うＶＭを、ＶＭ１から更新予定のＶＭ２に切り替える。ロードバランサ２０は、各ＡＰサーバ１０について、アドレス情報２１におけるＶＩＰおよびＲＩＰ１との関連付けを、ＶＩＰおよびＲＩＰ２の関連付けに更新する（図３のステップＳ１０〜ステップＳ１２参照。図６の符号ｂ５の矢印参照。）。
【００６２】
さらに、ＤＢサーバ１１ＡのＶＭ１がストレージ１２のＤＢ領域１２ａをアンマウントする（破線の矢印参照）一方、ＤＢサーバ１１ＡのＶＭ２がストレージ１２のＤＢ領域１２ａをマウントし、ＤＢサーバ１１Ａのデータベース管理システムを動作可能にし（符号ｂ６の矢印参照）、ＡＰサーバ１０からの接続を受け付ける。これにより、管理装置４０は、ＤＢサーバ１１ＢのＶＭ２を待機状態（Ｓｔｂ）にするとともに、ＤＢサーバ１１ＡのＶＭ２を稼働状態（Ａｃｔ）にする。これにより、ファイル更新されたＶＭ２によるサービスリリースが完了する。その後、サービス提供が安定的に運用されているなどの所定の条件が満たされていると判断した場合、仮想マシン制御部４３１は、ファイル更新前のＶＭ１を削除する。
【００６３】
ＡＰサーバ１０の新たなＶＭ、および、稼働状態であり試験領域１２ｂを参照する運用系のＤＢサーバ１１の新たなＶＭを対象にした１コール試験（図４参照）と、ＡＰサーバ１０の新たなＶＭ、および、待機状態（Ｓｔｂ）から稼働状態（Ａｃｔ）に切り替わったときに試験領域１２ｂを参照した待機系のＤＢサーバ１１の新たなＶＭを対象にした１コール試験（図５参照）は、現在サービスを提供している仮想マシンとは独立した新たな仮想マシンを対象にすることができる。このため、これらの試験は、図６に示すサービスのリリースが完了する前に行うことができる。このため、ファイル更新が実施されてもサービス提供を開始するまでにシステム全体に内在する不具合を発見することができる。したがって、本実施形態の分散処理システムは、サービスに影響を与えることなく、システム全体のファイル更新に関する試験を行うことができるようにする。
【００６４】
（複数のＡＰサーバのファイル更新の並行実施）
すでに説明した通り、本実施形態の分散処理システムにおいて、管理装置４０は、ＡＰサーバ１０の各々のファイル更新を行う際には、ＡＰサーバ１０の各々内に現在稼働中のＶＭ１（図７では「本番」と記載）とは別に、新たなＶＭ２（図７では「更新予定」と記載）を作成する。また、管理装置４０は、この新たなＶＭ２それぞれに対する新たなＲＩＰの割り当て、リソースの割り当てを行う。そして、この新たなＶＭ２に対しファイル更新を行う。その後、管理装置４０は、ロードバランサ２０に対し、ＶＩＰに対応するＲＩＰを新たなＶＭ２のＲＩＰに変更させ、ＶＩＰ宛のアクセスをＶＭ２へ振り分ける。これにより、ＡＰサーバ１０の各々に対する、端末３０からのＶＩＰ宛のアクセスは、ＶＭ１からＶＭ２に一斉に切り替えられることになる。
【００６５】
つまり、図７に示すように、管理装置４０のアドレス情報更新部４３５は、ロードバランサ２０の閉塞中に、ＡＰサーバ１０の各々のＶＭ２に割り当てられた、ＲＩＰ１Ａ，ＲＩＰ１Ｂ，ＲＩＰ１Ｃ，・・・を、ＲＩＰ２Ａ，ＲＩＰ２Ｂ，ＲＩＰ２Ｃ，・・・に一度に変更するようにアドレス情報２１を更新することができる（図３のステップＳ１１参照）。このようなファイル更新が可能になるのは、ＡＰサーバ１０の各々に作成されたＶＭ１およびＶＭ２は、他のＡＰサーバ１０のＶＭ１およびＶＭ２と独立に動作させることができるため、ＲＩＰ１からＲＩＰ２への変更もＡＰサーバ１０の各々にて自在に行うことができるからである。
【００６６】
従来は、複数のサーバにおけるファイル更新は、サービスの提供を継続するには、１台ずつシーケンシャルに実施しなければならなかった。このため、サーバの台数が多くなるほど、ファイル更新に多大な時間を要し、ファイル更新に対するサービスの品質低下を招いていた。また、従来は、ファイル更新前と同程度の品質のサービスを提供するためには、ファイル更新が行われているサーバに対して、余剰リソースとなるサーバを１台追加しなければならなかったので、分散処理システムにおけるサーバの設置コストおよび運用コストの増大化を招いていた。
【００６７】
本実施形態の管理装置４０は、アドレス情報更新部４３５を機能させ、ファイル更新処理によって、アクセスの振り分け先となるＡＰサーバ１０のＶＭ１のアドレスのすべてを、当該ＡＰサーバ１０のＶＭ２のアドレスに同じタイミングで更新することができるため、ＡＰサーバ１０のファイル更新に要する時間を短縮することができる。このとき、ＶＭ２をＡＰサーバ１０の各々に作成するため、余剰リソースとなるＡＰサーバの追加は必要としない。
【００６８】
（想定外トラブル時の切り戻し）
ファイル更新処理後であっても、サービス提供が安定的に運用されているなどの所定の条件が満たされるまでは、ファイル更新前のＶＭ１は残存させる（図６参照）。もし、安定運用の確認後ＶＭ１の削除前に想定外のトラブルが発生した場合は、更新ファイルの切り戻しを実施する必要がある。このとき、従来では、サーバを１台ずつシーケンシャルにファイル更新を実施したため、更新ファイルの切り戻しも１台ずつシーケンシャルに行う必要があり多大な時間を要した。また、更新ファイルの切り戻しについても、ファイル更新時とは、別の手順および別の検証を必要とし多大な労力を要した。例えば、ファイル更新処理において、「機能Ａを削除」→「機能Ｂの追加」という手順をとる場合、更新ファイルの切り戻しにおいて、「機能Ｂの削除」→「機能Ａの追加」というファイル更新時とは異なる手順をとる必要がある。なお、削除対象となる機能Ａが、機能Ｂや他の機能へ及ぼす影響などを考慮すると、ファイル更新処理後であっても削除対象となる機能Ａを残存させるという方法はとることができない。また、更新内容が異なるため検証方法も別となる。
【００６９】
本実施形態では、ファイル更新処理の完了後であっても、所定の条件（安定運用確認）を満たすまでは、ＡＰサーバ１０、ＤＢサーバ１１の各々において、ＶＭ１およびＶＭ２を併存させる。図８に示すように、想定外トラブルが発生したため、更新ファイルの切り戻しを行うときは、まず、管理装置４０のアドレス情報更新部４３５は、ロードバランサ２０の閉塞中に、ＡＰサーバ１０の各々のＶＭ２に割り当てられた、ＲＩＰ２Ａ，ＲＩＰ２Ｂ，ＲＩＰ２Ｃ，・・・を、ＲＩＰ１Ａ，ＲＩＰ１Ｂ，ＲＩＰ１Ｃ，・・・に一度に変更するようにアドレス情報２１を更新する（符号ａ１の矢印参照）。
【００７０】
その後、ＤＢサーバ１１ＡのＶＭ２がストレージ１２のＤＢ領域１２ａをアンマウントする一方、ＤＢサーバ１１ＡのＶＭ１がストレージ１２のＤＢ領域１２ａをマウントし、ＤＢサーバ１１Ａのデータベース管理システムを動作可能にし（符号ａ２の矢印参照）、ＡＰサーバ１０からの接続を受け付ける。これにより、管理装置４０は、ＤＢサーバ１１ＡのＶＭ１を稼働状態（Ａｃｔ）にする。
【００７１】
したがって、ＡＰサーバ１０、ＤＢサーバ１１の各々において作成されるＶＭ１およびＶＭ２は互いに影響を及ぼすことなく独立に稼働することができるため、更新ファイルの切り戻しを簡略化することができ、労力を大幅に削減することができる。
【００７２】
（サーバリソースの有効活用）
次に、図９を用いて、管理装置４０の処理の具体例を交えながら、ＡＰサーバ１０およびＤＢサーバ１１における稼働中のＶＭおよびファイル更新の対象となる新たなＶＭのリソースの割り当てイメージを説明する。ここでは、ＡＰサーバ１０およびＤＢサーバ１１の稼働中のＶＭをＶＭ１とし、ファイル更新の対象となる新たなＶＭをＶＭ２とする。
【００７３】
まず、管理装置４０が、システム内のＡＰサーバ１０およびＤＢサーバ１１それぞれのＶＭ１が稼働した状態で、ＶＭ２の作成およびリソースの割り当てを指示する（ステップＳ２１）。次に、試験装置５０がＡＰサーバ１０およびＤＢサーバ１１それぞれのＶＭ２への事前試験を実施した後（ステップＳ２２）、ロードバランサ２０の閉塞と、ＡＰサーバ１０のＶＭ２への振り分け設定を行う（ステップＳ２３）。つまり、管理装置４０は、ロードバランサ２０を閉塞し、アドレス情報２１におけるアクセスの振り分け先をＶＭ２のアドレスに変更する。その後、管理装置４０はロードバランサ２０の閉塞を解除する。その後、管理装置４０は、ＡＰサーバ１０およびＤＢサーバ１１それぞれに対しＶＭ１の削除を指示する（ステップＳ２４）。これによりＶＭ２が稼働することになる。
【００７４】
ここで、ＡＰサーバ１０およびＤＢサーバ１１内のＶＭの実効上のリソースの割り当てには、オーバーコミットが適用される。つまり、ＶＭ２の作成からＶＭ１の削除までの間、設定上はＶＭ１、ＶＭ２それぞれに同じ物理リソース分が割り当てるが、実効上はＶＭ１、ＶＭ２へのアクセスに応じたリソースの割り当てがされる。よって、例えば、符号２０１に示すように、設定上、ＶＭ１、ＶＭ２へそれぞれ（ホストＯＳ分を除く）物理リソース分の割り当てを行う。つまり、サーバ全体では、設定上の物理リソースの約２倍のリソースを割り当てる。
【００７５】
ここで、ＶＭの実効上のリソースの割り当てにオーバーコミットを適用することで、例えば、ＶＭ１は稼働中であるが、ＶＭ２は試験装置５０からの事前試験を受けた状態であるとき（図９のステップＳ２２の状態であるとき）、符号２０２に示すように、ＶＭ２の実効上の割り当てリソース（Ｙ）は、試験に必要なリソースとなる。つまり、ＶＭ２には実効上、試験に必要なリソース（例えば、１コール分の処理を実行可能なリソース）が割り当てられればよいので、ＶＭ１と同じリソース（Ｘ）は必要ない。
【００７６】
ここで、「Ｙのリソースで処理可能なトランザクション最大値」と「分散処理システムを構成するサーバの台数」との積が、１台のサーバで処理可能なトランザクションの最大値以下となれば、システムのファイル更新を実施しても、サーバへの追加リソースは不要となる。
【００７７】
なお、各ＶＭへのリソースの実効上の割り当ては、トランザクションに応じて、ＶＭ自身が行う。ただし、ファイル更新前後で、サーバ１台あたりの最大のトランザクション数が変わることはないため、結果として図９のＸ＋Ｙがサーバの物理リソースを超えることはない。
【００７８】
したがって、本実施形態によれば、ＡＰサーバ１０およびＤＢサーバ１１に作成される新たなＶＭに対して試験を行う場合、リソースの割り当てを最小限に抑えることができる。
【００７９】
本実施形態の分散処理システムによれば、ＡＰサーバ１０およびＤＢサーバ１１の各々に、サービス提供に供しているＶＭ１およびファイル更新予定のＶＭ２を作成することで、上記したシステム全体の事前試験、複数のＡＰサーバのファイル更新の並行実施、想定外トラブル時の切り戻し、および、サーバリソースの有効活用は、新たなサーバを導入することなしに同時に実現することが可能である。
【００８０】
（プログラム）
また、上記実施形態に係る管理装置４０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、管理装置４０と同様の機能を実現する管理プログラムを実行するコンピュータの一例を説明する。
【００８１】
図１０は、管理プログラムを実行するコンピュータを示す図である。図１０に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
【００８２】
メモリ１０１０は、ＲＯＭ（Read  Only  Memory）１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。
【００８３】
ここで、図１０に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。
【００８４】
また、管理プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明した管理装置４０が実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。
【００８５】
また、管理プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。
【００８６】
なお、管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local  Area  Network）やＷＡＮ（Wide  Area  Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【００８７】
≪その他≫
試験装置５０による試験は、図１、図４に示すようにロードバランサ２０を経由して行ってもよい。しかし、試験装置５０は、ロードバランサ２０を経由することなく、ＡＰサーバ１０に直接アクセスして、ＡＰサーバ１０、ＤＢサーバ１１、ストレージ１２を対象にした本実施形態の試験を行ってもよい。
【００８８】
本実施形態の外部装置は、端末３０に限られず、例えば、ネットワーク経由でロードバランサ２０にアクセス可能なサーバ装置等も含む。
【００８９】
また、本実施形態では、ＡＰサーバ１０およびＤＢサーバ１１内のＶＭの実効上のリソースの割り当てには、オーバーコミットを適用し、ＶＭ２の実効上の割り当てリソース（Ｙ）を、試験に必要なリソース、例えば、１コール分の処理を実行可能なリソースとした。しかし、ＡＰサーバ１０およびＤＢサーバ１１の各々について、ＶＭ１およびＶＭ２の合計分となる物理リソースを事前に準備し、オーバーコミットを不要としてもよい。この場合であっても、ＶＭ１、ＶＭ２それぞれに同じ分だけ割り当てられる設定上の物理リソースを超えないので、ＡＰサーバ１０およびＤＢサーバ１１の各々について、ＶＭ１（本番）およびＶＭ２（更新予定）は共存可能となる。よって、すでに説明した、システム全体の事前試験、複数のＡＰサーバのファイル更新の並行実施、および、想定外トラブル時の切り戻しを実現することができる。
【００９０】
本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００９１】
１０，１０Ａ，１０Ｂ，１０Ｃ    ＡＰサーバ
１１，１１Ａ，１１Ｂ    ＤＢサーバ
２０    ロードバランサ（振り分け装置）
２１    アドレス情報
２２    振り分け部
３０    端末（外部装置）
４０    管理装置
４１    入出力部
４２    通信部
４３    制御部
４４    記憶部
５０    試験装置
４３１  仮想マシン制御部
４３２  リソース割り当て部
４３３  ファイル更新部
４３４  ロードバランサ制御部
４３５  アドレス情報更新部
４３６  バックアップ部
４３７  領域設定部
４３８  試験実施部
【図１】
2016143202.tif 000003
【図２】
2016143202.tif 000004
【図３】
2016143202.tif 000005
【図４】
2016143202.tif 000006
【図５】
2016143202.tif 000007
【図６】
2016143202.tif 000008
【図７】
2016143202.tif 000009
【図８】
2016143202.tif 000010
【図９】
2016143202.tif 000011
【図１０】
2016143202.tif 000012