JP2018088114A

JP2018088114A - 管理システム、および制御方法

Info

Publication number: JP2018088114A
Application number: JP2016230824A
Authority: JP
Inventors: 祐貴白河; Yuki Shirakawa
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-11-29
Filing date: 2016-11-29
Publication date: 2018-06-07
Anticipated expiration: 2036-11-29
Also published as: CN108124000A; US20180150336A1; JP6783638B2

Abstract

【課題】クライアント環境の設定により、クライアントからのリクエストが第１の処理環境の装置に送信された場合であっても、該リクエストを第２の処理環境の仮想マシンで処理させることを可能とする。【解決手段】管理システムは、負荷分散装置から、いずれの仮想マシンにリクエストを転送させるかを管理し、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないよう管理する。【選択図】図５

Description

本発明は、仮想マシンと負荷分散装置を含む処理環境を管理する管理システム、および制御方法に関する。

近年、アプリケーションや仮想マシン、ストレージなどのコンピュータリソースをユーザが必要なときに必要な分だけ利用できるクラウドサービスが増えてきた。このようなクラウドサービスは、ＳａａＳ、ＰａａＳ、ＩａａＳなどと呼ばれ、クラウドサービスベンダが提供するアプリケーションやコンピュータリソースをユーザが独自に組み合わせて使用することができる。ユーザはクラウド上にシステムを構成することで、自身がサービスベンダとなり、エンドユーザにサービスを提供することができる。クラウドサービスベンダはユーザが利用したアプリケーションやコンピュータリソースの量に応じて課金する仕組みとなっている。

従来、システムを構築する際には提供する機能やサービスの規模を考慮した上でシステム構成を決定し、アプリケーションを動作させるためのコンピュータリソースを選定する必要があった。サービスを運用していく過程でシステム構成を変更したい場合や、システムへの負荷やパフォーマンスを考慮してマシンスペックを上げたい場合は、コンピュータリソースを変更・追加する必要がある。しかし、稼働中の環境においてコンピュータリソースを変更・追加することは容易ではなく、既存コンピュータリソースへの設定ファイルやプログラムのデプロイメントとシステムの切り戻しを考慮して停止時間を設けていた。

停止時間を設けなければならないことや作業中のオペレーションミスなどを改善するために、近年は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントと呼ばれるシステムバージョンアップの方法が利用されている。ここで、システムのバージョンアップとは、例えば、システム内の仮想マシンで実行されるアプリケーションのバージョンアップが含まれる。バージョンアップ後のシステムは、提供できる機能が追加されたり、管理するデータの種類や形式が変更されたりする。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピューターである。

ここで、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによるシステムバージョンアップの方法を説明する。まず、クラウドサービス上で、クライアントからのリクエストを受け付ける設定が行われている装置（ロードバランサ、仮想マシン）の属する処理環境が、本番環境として機能している。処理環境は、少なくとも、リクエストを処理する１以上の仮想マシンと、それらにリクエストを分散させる負荷分散装置として機能するロードバランサとを有する。そこで、処理環境をバージョンアップさせたい場合に、現行のバージョンの処理環境とは異なる、バージョンアップ後の処理環境をクラウドサービス上に更に構築する。その後、バージョンアップさせたいタイミングになったら、クライアントからのリクエストを受け付ける装置についての設定の変更などを行い、本番環境として機能させる処理環境を切り替える。この切り替えによって、システムのバージョンアップが実現される。ここで、接続先を切り替える方法としては、サービス提供者が管理するＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバーのＤＮＳレコードが記載された設定ファイルを書き換えるという方法などがある。

特許文献１には、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによるシステムバージョンアップの方法が記載されている。

特開２０１６−１１５３３３号公報

上述したＢｌｕｅ−Ｇｒｅｅｎデプロイメントの実行によって、本番環境として機能する処理環境が切り替えられたにも関わらず、旧本番環境の負荷分散装置がクライアントからのリクエストを受け付けてしまうことがある。例えば、クライアント環境の設定として、クライアントのローカルネットワーク環境にあるＤＮＳサーバーの更新が遅れていたり、クライアントのキャッシュサーバーなどで古いＤＮＳキャッシュを保持し続けていたりする場合がある。そのような場合に、クライアントがリクエストを送信する際に、古いＤＮＳレコードが名前解決に使用される。すると、本番環境として機能する処理環境が切り替えられたにも関わらず、クライアントからのリクエストは、旧本番環境（第１の処理環境）が受け付けることとなり、現在の本番環境（第２の処理環境）で処理されなくなってしまう。つまり、バージョンアップ後のサービスがクライアントへ提供されなくなってしまう。また、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントが実行された直後に、新しいバージョンの処理環境（第１の処理環境）での異常発生により本番環境を古いバージョンの処理環境（第２の処理環境）に戻した場合においても、同様である。

本発明は、クライアント環境の設定により、クライアントからのリクエストが第１の処理環境の装置に送信された場合であっても、該リクエストを第２の処理環境の仮想マシンで処理させることを可能とするための仕組みを提供することを目的とする。

上記課題を解決するために、本発明は、クライアントからのリクエストを処理可能な複数の仮想マシンと、前記複数の仮想マシンにリクエストを転送する負荷分散装置とを少なくとも備える複数の処理環境を管理する管理システムであって、負荷分散装置から、いずれの仮想マシンにリクエストを転送させるかを管理する管理手段を有し、前記管理手段は、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から前記第１の処理環境とは別の第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないよう管理することを特徴とする。

本発明によれば、クライアント環境の設定により、クライアントからのリクエストが第１の処理環境の装置に送信された場合であっても、該リクエストを第２の処理環境の仮想マシンで処理させることが可能となる。

ネットワークシステム構成の一例を示す図情報処理機能を有するハードウェアの構成例を示す図クラウドシステムの構成例を示す図コンピュータリソースの設定値を管理するテーブルの一例を示す図Ｂｌｕｅ−Ｇｒｅｅｎデプロイメント実行後のクラウドシステムの構成例を示す図デプロイ処理の手順例を示すフローチャート実施例２のクラウドシステムの構成例を示す図処理環境のバージョン管理テーブルの例を示す図バージョン管理テーブルの更新の手順例を示すフローチャート旧Ｂｌｕｅのコンピュータリソースの削除処理の手順例を示すフローチャート

以下、本発明を実施するための最良の形態について図面を用いて説明する。

（実施例１）
図１は、本発明の実施形態に係るネットワークシステム構成の一例を示す図である。情報処理装置１０４は、光回線などでプロバイダ１０３と通信し、プロバイダ１０３を介してインターネット１０２と繋がるＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）やプリンター、複合機などである。情報処理端末１０７は基地局１０６と無線で通信し、コアネットワーク１０５を介してインターネット１０２と繋がる端末で、例えばタブレットやスマートフォン、ノートＰＣなどである。情報処理端末１０７には、無線通信機能を備えたデスクトップＰＣやプリンターなども含まれる。サーバー１０１は、インターネット１０２を介し、各情報処理端末にＷｅｂページやＷｅｂＡＰＩを提供するクラウドシステムとして機能する。本実施例のクラウドシステムは、ＩａａＳやＰａａＳなどのクラウドサービスによって提供されるプラットフォームやリソースを利用して構築される、ネットワークデバイスやそれらを保有する顧客を管理するためのサービスを提供するシステムである。なお、複数台のサーバー１０１によってクラウドシステムが構築されてもよい。

図２は、サーバー１０１、情報処理装置１０４、情報処理端末１０７、およびクラウドシステムが構築されるデータセンター上に存在するサーバーコンピューターなどの情報処理機能を有するハードウェアの構成例を示す図である。

入出力インターフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネル、ボタンなどによる、情報や信号の入出力を行う。なお、これらのハードウェアを備えないコンピューターは、リモートデスクトップやリモートシェルなどにより、他のコンピューターから接続・操作することも可能である。ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行う。ＲＯＭ２０４には、組込済みプログラムおよびデータが記録されている。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤやフラッシュメモリに代表されるような記憶装置である。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行する。各部は、内部バス２０７を介して接続されている。サーバー１０１などは、ＲＯＭ２０４に格納されているプログラムを実行するＣＰＵ２０３を備え、内部バス２０７を介して各部を総括的に制御する。

図３は、クラウドシステムの構成例を示す図である。図３（ａ）は、クラウドシステムの全体構成の一例を示す図である。３０１はサービスを提供するために必要なコンピュータリソースから構成されるクラウドシステムである。３０２はクラウドシステム３０１で管理するサービスを利用する情報処理装置１０４、情報処理端末１０７などの情報処理機能を有するクライアントである。

３１０は、ロードバランサ３１１、仮想マシン３１２、キュー３１３および仮想マシン３１４を含む処理環境である。処理環境３１０は、クライアント３０２からのリクエストを受け付ける設定がＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバー３４０によって行われている。ＤＮＳサーバー３４０の設定において、クライアントからのリクエストを受け付ける設定が行われている装置（ロードバランサ、仮想マシンなど）の属する処理環境を、以下では、Ｂｌｕｅ環境または本番環境と呼ぶ。３１１はＢｌｕｅ環境のロードバランサ（負荷分散装置）であり、クライアント３０２からのリクエストを受け付ける。なお、ロードバランサはリクエストの分散先である仮想マシンに対して、ヘルスチェックを定期的に実行しているものとする。ヘルスチェックでは、仮想マシンが正常に稼働しているか、仮想マシンと通信可能であるかなどの確認が行われる。３１２はロードバランサ３１１によるリクエストの転送先であり、転送されたリクエストを処理可能な仮想マシン（以下ＶＭと呼ぶ）である。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピューターである。ＶＭ３１２は、単位時間あたりのリクエスト数やＶＭ３１２自身のリソースの使用率に応じて自動的にスケールアウトする設定がなされていてもよい。

３１３は、ＶＭ３１２が処理依頼を示すデータを格納するキューである。３１４はキューに格納されるデータ（タスク、メッセージなどとも呼ばれる）を定期的に取得して処理するＶＭである。ＶＭ３１４はキュー３１３の存在により、通常はＶＭ３１２のように自動的にスケールアウトされる設定を行われない。ただし、キュー３１３に格納されるデータを規定時間内に処理できない場合や、キュー３１３自身が定期的にＶＭ３１４に対してデキューを行う場合などには、自動的にスケールアウトする設定がなされていてもよい。

３２０は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントの実行後に本番環境となる処理環境である。３２０内のＶＭでは、３１０内のＶＭと比べて、バージョンアップされたアプリケーションが動作する。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントの実行後に本番環境となる処理環境を、以下では、Ｇｒｅｅｎ環境と呼ぶ。３２１はＧｒｅｅｎ環境のロードバランサであり、３２２はロードバランサ３２１によるリクエストの分散先となるＶＭである。ＶＭ３２２は、Ｂｌｕｅ環境のＶＭ３１２と比較して、バージョンアップされたアプリケーションが動作している。３２３は、ＶＭ３２２が処理依頼を示すデータを格納するキューである。３２４はキューに格納されるデータを定期的に取得して処理するＶＭである。ＶＭ３２４は、Ｂｌｕｅ環境のＶＭ３１４と比較して、バージョンアップされたアプリケーションが動作している。Ｇｒｅｅｎ環境には、通常はクライアント３０２からリクエストが送信されることはない。ただし、テスト目的などで、クライアント３０２やシステム管理部３６０などがＧｒｅｅｎ環境のエンドポイントを指定してリクエストを送信した場合は、Ｂｌｕｅ環境と同様に処理を実行することも可能である。

上述したように、Ｂｌｕｅ環境３１０とＧｒｅｅｎ環境３２０はそれぞれ、基本的には同じ構成を備えている。ただしバージョンアップに伴い、Ｇｒｅｅｎ環境は、Ｂｌｕｅ環境と比較して、コンピュータリソースの数やスペックないしはアプリケーションロジックが変更されている。

ここで、クラウドサービスを利用して構築されるシステムは、比較的短期間でバージョンアップを繰り返すことが多く、一日に数十回、数百回とバージョンアップされる場合もある。そのような場合においても、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントを行うことにより、サービス提供者はコンピュータリソースの変更やアプリケーションのバージョンアップも無停止かつ容易に行うことができる。また、サービスは止まることがないため、クライアントはサービス側の変更を意識することなく、継続的にサービスを利用することができる。

接続先の切り替えでは、ＦＱＤＮ（ＦｕｌｌｙＱｕａｌｉｆｉｅｄＤｏｍａｉｎＮａｍｅ）を変更せずに、外部リクエストの接続先が新たな本番環境へ切り替わるように設定ファイルが書き換えられる。クライアントは、更新されたＤＮＳレコードをもとに名前解決を行うため、ＦＱＤＮの変更を行うことなく新しい本番環境へリクエストを送信することができる。しかしながら、サービス提供者が管理するＤＮＳサーバーでＴＴＬ（ＴｉｍｅｔｏＬｉｖｅ）を設定していたとしても、エンドユーザの階層上にあるＤＮＳサーバーの更新間隔が必ずしも保証されるわけではない。例えば、クライアントのローカルネットワーク環境にある特定のＤＮＳサーバーで更新が遅れていたり、クライアントのキャッシュサーバーなどでＤＮＳキャッシュを保持し続けていたりする場合に、更新前の古いＤＮＳレコードが名前解決に使用される。したがって、クライアントからのリクエストは、新しいバージョンである現在の本番環境ではなく、古いバージョンである旧本番環境で処理されてしまう。

図３（ａ）の説明に戻る。３３０はＢｌｕｅ環境３１０やＧｒｅｅｎ環境３２０が使用するデータストアである。データストア３３０は、冗長化目的で複数配置されていたり、システムの特性により異なる種類のデータストアが複数配置されていたりしてもよい。なお、図３ではＢｌｕｅ環境とＧｒｅｅｎ環境でデータストアを共有しているが、それぞれの処理環境ごとにデータストアが配置されていてもよい。３４０はＤＮＳレコードなどが記載された設定ファイルとして、ドメイン情報やクラウドシステム３０１内の各エンドポイントの紐付け情報を管理するＤＮＳサーバーである。後述するリソース管理部３５０がＤＮＳサーバー３４０の設定ファイルを書き換えることで、Ｂｌｕｅ環境とＧｒｅｅｎ環境を切り替えるＢｌｕｅ−Ｇｒｅｅｎデプロイメントを実現している。具体的にはリソース管理部３５０が、ロードバランサ３１１、３２１のエンドポイントをクラウドシステム３０１で管理するサービスの正式なＦＱＤＮに紐付けるようにＤＮＳサーバー３４０の設定ファイルを書き換えることで処理環境の切り替えを行っている。

図３（ｂ）は、リソース管理部の構成の一例を示す図である。３５０は、クラウドシステム３０１内のコンピュータリソースの監視や操作を行うためのリソース管理部で、クラウドサービスベンダによって提供される機能である。３５１は、処理環境やデータストアなどのコンピュータリソースを生成する機能を有するリソース生成部である。３５２は、ＤＮＳサーバー３４０の設定ファイル（後述する図４（ａ））を更新する機能を有する設定値更新部である。設定値更新部３５２は、システム管理部３６０のリソース操作部３６１から指示を受けて、ＤＮＳサーバー３４０の設定ファイルを直接書き換えたり、各コンピュータリソースが提供するＡＰＩを呼び出したりすることによって設定値の更新を行う。３５３はクラウドシステム３０１内のコンピュータリソースの状態やアクセスログ、動作ログを監視する機能を有するリソース監視部である。３５４はクラウドシステム３０１内のコンピュータリソースを削除する機能を有するリソース削除部である。リソース削除部３５４は、予め削除処理をスケジューラに登録しておくことで、定期的に不要なコンピュータリソースを削除するように設定されていてもよい。

図３（ｃ）は、システム管理部の構成の一例を示す図である。３６０は、クラウドシステム３０１内の各コンピュータリソースを操作するためにリソース管理部３５０に対して指示を出すシステム管理部である。システム管理部３６０は、本実施例の管理システムとして機能し、クラウドシステム３０１を管理するシステム開発者によって作成される。システム管理部３６０は、ＤＮＳサーバー３４０、リソース管理部３５０および管理用データストア３７０と通信可能である。３６１は、クラウドシステム３０１を管理するシステム開発者の開発ＰＣなどからリクエストを受け付け、クラウドシステム３０１のコンピュータリソースを操作するために前述したリソース管理部３５０の各部に対して指示を出すリソース操作部である。リソース操作部３６１は、各処理環境の構成情報を管理するテーブル（後述する図４（ｂ））や、各処理環境のロードバランサの設定情報を管理するテーブル（後述する図４（ｃ））などを管理する。３６２は、各処理環境の動作・通信確認を行うためのテスト用リクエストを処理環境に送信する機能を有するアプリケーションテスト部である。アプリケーションテスト部３６２（以下、テスト部３６２）は、クラウドシステム３０１を管理するサービス提供者が予め作成したテストを管理用データストア３７０などに配置しておく。テスト部３６２は、テストを実行する際にテストツールなどを用いてテスト用リクエストを任意の処理環境に対して送信する。また、テスト部３６２はリソース管理部３５０を介して、ロードバランサ３１１、３２１からＶＭ３１２、３２２に対してヘルスチェックを実行する指示を出すことも可能である。３７０はリソース操作部３６１の指示を記した管理用プログラムや処理環境３１０、３２０のアプリケーションプログラム、アクセスログなどのクラウドシステム３０１内で使用・生成されるデータを格納する管理用のデータストアである。

図４は、コンピュータリソースの設定値を管理するテーブルの一例を示す図である。後述するが、図４の各テーブルの設定値は、図５のＤＮＳサーバー３４０および処理環境５１０、５２０の状態に関係する。また、本実施例では、テーブルのようなマトリクス形式で設定値を管理しているが、ＪＳＯＮのようなキーバリュー形式の設定ファイルとして管理することも可能である。

図４（ａ）で示す４００は、ＤＮＳサーバー３４０のＤＮＳレコードが記載された設定ファイルである。設定ファイル４００は、ＤＮＳサーバー３４０で保持される。クライアント３０２は設定ファイル４００をもとに名前解決を行う。４０１はクライアント３０２がＢｌｕｅ環境３１０にリクエストを送信する際の宛先となるホスト名を示している。４０２はＤＮＳレコードのレコードタイプを示している。４０３は４０１で設定されているホスト名に紐付けるエンドポイントの宛先を示している。４０４は各ＤＮＳレコードが有効である期間を示すＴＴＬである。４０５は各レコードが有効であるか無効であるかを示している。

図４（ｂ）で示す４１０は、各処理環境の構成情報を管理するテーブルである。テーブル４１０は、管理用データストア３７０で保持される。リソース生成部３５１や設定値更新部３５２、リソース削除部３５４により処理環境および処理環境内のコンピュータリソースが生成、更新、削除された場合に、リソース操作部３６１により管理テーブル４１０は更新される。４１１は処理環境のシステムバージョンを示している。システムバージョンはリソース生成部３５１により処理環境が生成された際に発行される処理環境を区別するためのユニークなＩＤである。４１２はロードバランサ３１１、３２１などのクライアント３０２からアクセス可能な外部公開されているロードバランサを示すユニークなＩＤである。４１３はＶＭ３１２、３２２などの処理環境のフロントエンドサーバーに該当するＶＭを示すユニークなＩＤである。４１４はキュー３１３、３２３などの処理環境のキューに該当するキューを示すユニークなＩＤである。４１５はＶＭ３１４や３２４などの処理環境のバックエンドサーバーやバッチサーバーに該当するＶＭを示すユニークなＩＤである。

４１６は、処理環境内のロードバランサがリクエストを転送する対象となるＶＭを示す設定値である。処理環境内のロードバランサは、４１６で示すＶＭのいずれかにリクエストを転送する。４１６の設定値は、Ｂｌｕｅ−Ｇｒｅｅｎ切り替え後に、リソース操作部３６１により更新される。管理テーブル４１０では、１行目（“ＳＹＳＴＥＭＶＥＲＳＩＯＮ”が２０１６０１０１−００００００の行）の処理環境は、４１２に記載のロードバランサでリクエストを受けた後、４１６に設定されたＶＭにリクエストを転送することを示している。管理テーブル４１０の１行目の処理環境では、４１２に記載のロードバランサは管理テーブル４１０の２行目の処理環境に記載の４１３のＶＭに対してリクエストを転送している。管理テーブル４１０の２行目の処理環境では、４１６が“ｍｙｓｅｌｆ”であるため、他の処理環境のＶＭではなく、同じ処理環境のＶＭにリクエストを転送していることを示す。つまり、管理テーブル４１０で、ロードバランサ４１２と、リクエストの転送先となるＶＭ４１６との対応付けが管理されている。

つまり、ここでは、１行目の処理環境が旧本番環境で、２行目の処理環境が現在の本番環境であり、旧本番環境のロードバランサから本番環境のＶＭにリクエストが転送されることを示している。また、本番環境のロードバランサは、従来通り、本番環境のＶＭにリクエストを転送する。なお、テーブル４１０は処理環境のシステム構成によってテーブル定義が変わるため、処理環境構成情報を管理するテーブルはテーブル４１０のテーブル定義に限定するわけではない。

図４（ｃ）で示す４２０は、各処理環境のロードバランサの設定情報を管理するテーブルである。テーブル４２０は、管理用データストア３７０で保持される。リソース生成部３５１や設定値更新部３５２、リソース削除部３５４によりロードバランサが生成、更新、削除された場合に、リソース操作部３６１によりテーブル４２０が更新される。４２１はロードバランサ３１１、３２１などのクライアント３０２からアクセス可能な外部公開されているロードバランサを示すユニークなＩＤであり、４１２と対応している。４２２はロードバランサのエンドポイントを示す値であり、ＤＮＳ名やＩＰアドレスが設定されている。４２３はロードバランサのファイアウォールの設定値を示している。ファイアウォールの設定値４２３には通信を許可するプロトコルやポート、インバウンド、アウトバウンドのルールなどが記載されている。４２４はヘルスチェックの設定値を示している。ヘルスチェックの設定値４２４には、ヘルスチェックで送信するリクエストの宛先やポート番号、ヘルスチェックが正常であるためのルールなどが記載されている。ファイアウォールの設定値４２３やヘルスチェックの設定値４２４は、図４のようにテーブル４２０には設定ファイルを指定してもよいし、直接値を設定してもよい。

図５は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメト実行後の処理環境の構成例を示す図である。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメント実行後とは、設定値更新部３５２が設定ファイル４００を書き換えることで、クラウドシステム３０１で管理するサービスの正式なＦＱＤＮとロードバランサのＤＮＳ名などの紐付けを切り替えた後のことを意味する。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントのことを、以下では単に切り替えと呼ぶ。

５０２は、切り替え後にクライアントのネットワーク環境でＤＮＳキャッシュが更新されないなどが原因で、旧処理環境にリクエストを送信し続けるクライアントである。５０３は、切り替え後に正しく新処理環境にリクエストを送信するクライアントである。５１０は切り替え後の旧処理環境である。以下旧処理環境のことを旧Ｂｌｕｅ環境とも呼ぶ。一方、５２０は新処理環境であり、以下Ｂｌｕｅ環境とも呼ぶ。旧Ｂｌｕｅ環境は切り替え後も稼働している。

前述した通り、図４の管理テーブル４１０の１行目の処理環境と旧Ｂｌｕｅ環境５１０の処理環境は対応している。５１１は旧Ｂｌｕｅ環境のロードバランサであり、管理テーブル４１０の１行目の処理環境の４１２と対応している。切り替え後であっても旧Ｂｌｕｅ環境は稼働し続けているため、ロードバランサ５１１はクライアント５０２からのリクエストを受け付ける。切り替え後、リソース操作部３６１は、ロードバランサ５１１からＶＭ５２２にリクエストを転送させるようにロードバランサ５１１の設定値を更新する。さらに、リソース操作部３６１は、ロードバランサ５１１からＶＭ５１２にリクエストを転送させないようにロードバランサ５１１の設定値を更新する。このとき、管理テーブル４１０の１行目（旧Ｂｌｕｅ環境５１０の処理環境構成情報）の４１６には管理テーブル４１０の２行目（Ｂｌｕｅ環境５２０の処理環境構成情報）の４１３（ＶＭ５２２）が設定値としてリソース操作部３６１により更新される。この更新により、旧Ｂｌｕｅ環境５１０のエンドポイントであるロードバランサ５１１がクライアント５０２からリクエストを受けた場合でも、実際のリクエストの転送先はＶＭ５２２であるため、Ｂｌｕｅ環境にリクエストを転送する。なお、ＶＭ５１２、キュー５１３、ＶＭ５１４は稼働しているため、新規にリクエストが転送されることはないが、処理中のリクエストは正常に処理される。５２０は切り替え後の新処理環境であり、前述した通りＢｌｕｅ環境に相当する処理環境である。Ｂｌｕｅ環境は、クラウドシステム３０１で管理するサービスの正式なＦＱＤＮと紐付いたロードバランサ５２１を有する処理環境である。

また、図４の管理テーブル４１０の２行目の処理環境とＢｌｕｅ環境５２０の処理環境は対応している。５２１はＢｌｕｅ環境のロードバランサである。ロードバランサ５２１は、切り替え後にクライアントのネットワーク環境でＤＮＳキャッシュが更新され、正しく送信されたリクエストを受け付けるロードバランサである。ロードバランサ５２１は、旧ＢｌｕｅリクエストをＶＭ５２２に転送し、その後、キュー５２３、ＶＭ５２４へと処理を渡していく。Ｂｌｕｅ環境５２０では旧Ｂｌｕｅ環境５１０とは違い、クライアント５０３からのリクエストを他の処理環境に転送する必要がないため、管理テーブル４１０は更新されない。

なお、旧Ｂｌｕｅ環境５１０のロードバランサ５１１がクライアントからのリクエストを受け付けた際に、送信元となるクライアントにエラーを返すなどして、クライアントに新しいＤＮＳレコードを取得させるといったことも考えられる。ただし、クラウドシステム３０１にアクセスする全てのクライアントにそのような仕組みを設ける必要がある。

図６は、デプロイ処理の手順例を示すフローチャートである。図６のフローチャートに示す処理は、システム管理部３６０により実行される。すなわち、図６のフローチャートの処理は、データセンター上のサーバーコンピューターのＣＰＵ２０３が、ＲＯＭ２０４または二次記憶装置２０６に記録されたプログラムを読み出して実行することにより実現される。

Ｓ６０１では、リソース操作部３６１が、リソース生成部３５１に対してＧｒｅｅｎ環境の構築を指示する。Ｇｒｅｅｎ環境が構築されると、テーブル４１０および４２０に各種コンピュータリソースの情報が追加される。Ｓ６０２では、リソース操作部３６１が、設定値更新部３５２に対して、Ｂｌｕｅ−Ｇｒｅｅｎ切り替えの実行を指示する。具体的には、ＤＮＳサーバー３４０の設定ファイルが更新されることで、クラウドシステムの外部にいるクライアントからのリクエストを受け付けるロードバランサが変更される。Ｓ６０３では、リソース操作部３６１が、設定値更新部３５２に問い合わせて、正常に切り替えが行われたことが確認された場合はＳ６０４を実行し、正常に切り替えが行われなかったことが確認された場合は、本フローチャートの処理を終了する。Ｓ６０４ではテスト部３６２がＢｌｕｅ環境５２０に対して動作・通信確認テストを行うなどして正常に稼働しているか確認する。テスト部３６２は、Ｂｌｕｅ環境５２０が正常に稼働していると判断した場合はＳ６０５を実行し、正常に稼働していないと判断した場合はＳ６１０を実行する。

Ｓ６０５では、リソース操作部３６１が、旧Ｂｌｕｅ環境５１０のロードバランサ５１１とＢｌｕｅ環境５２０のＶＭ５２２とを対応付けるようにテーブル４１０を更新する。具体的には、管理テーブル４１０の１行目の４１６に、管理テーブル４１０の２行目の４１３のＶＭが、リクエストの転送先の候補として追加される。この対応付けが行われた時点では、旧Ｂｌｕｅ環境５１０のロードバランサ５１１からＢｌｕｅ環境５２０のＶＭ５２２へのヘルスチェックが完了していないため、クライアント５０２からのリクエストはＢｌｕｅ環境５２０のＶＭ５２２に転送されない。Ｓ６０６ではテスト部３６２が、旧Ｂｌｕｅ環境５１０のロードバランサ５１１に、Ｓ６０５で追加したＢｌｕｅ環境５２０のＶＭ５２２に対してヘルスチェックを行うように指示する。ヘルスチェックでは、仮想マシンが正常に稼働しているか、仮想マシンと通信可能であるかなどの確認が行われる。なお、旧Ｂｌｕｅ環境５１０のロードバランサ５１１からＢｌｕｅ環境５２０のＶＭ５２２へのヘルスチェックを実行する際に、旧Ｂｌｕｅ環境５１０とＢｌｕｅ環境５２０でロードバランサの設定値に差異があり、ヘルスチェックが失敗する可能性がある。従って、テスト部３６２は、テーブル４２０の情報をもとにＢｌｕｅ環境５２０のロードバランサ５２１の設定値を旧Ｂｌｕｅ環境５１０のロードバランサ５１１に適用した上でヘルスチェックの実行指示を出してもよい。Ｓ６０７ではテスト部３６２がＳ６０６で実行したヘルスチェックの結果に基づき、Ｂｌｕｅ環境５２０のＶＭ５２２にリクエストを転送可能であると確認された場合はＳ６０８を実行し、転送可能でないと確認された場合はＳ６１２を実行する。なお、ヘルスチェックに失敗した場合も、テスト部３６２はＳ６１２を実行する。

Ｓ６０８ではリソース操作部３６１が、旧Ｂｌｕｅ環境５１０のロードバランサ５１１に対して、クライアント５０２からのリクエストをＳ６０５で追加したＢｌｕｅ環境５２０のＶＭ５２２へ転送するように指示する。Ｓ６０９ではリソース操作部３６１は、クライアント５０２からのリクエストが旧Ｂｌｕｅ環境のＶＭに転送されないように、旧Ｂｌｕｅ環境５１０のロードバランサ５１１とＶＭ５１２との対応付けを解除するようにテーブル４１０を更新する。すなわち、リソース操作部３６１が、管理テーブル４１０の１行目の処理環境の４１３、４１４、４１５に設定された値を削除したり、あるいは取り外しフラグを付与したりするなどして、管理テーブル４１０を更新する。ロードバランサ５１１の設定で、ロードバランサ５１１からリクエストの分散先であるＶＭ５１２への通信を閉塞できる場合は、ロードバランサ５１１とＶＭ５１２との対応付けを解除せず、通信を閉塞するだけでもよい。通信を閉塞する場合においても同様に、リソース操作部３６１が管理テーブル４１０の４１３、４１４、４１５の設定値を更新する。その後、本デプロイ処理を終了する。

Ｓ６１０ではリソース操作部３６１は、設定値更新部３５２に対して、Ｓ６０２で実行した設定ファイル４００の更新を再度実行し、Ｂｌｕｅ環境５２０から旧Ｂｌｕｅ環境５１０へ切り戻すよう指示する。Ｓ６１１ではリソース操作部３６１は、切り戻しにより旧Ｂｌｕｅ環境になった処理環境５２０のロードバランサ５２１に、切り戻しによりＢｌｕｅ環境になった処理環境５１０のＶＭ５１２を、追加するようにテーブル４１０を更新する。なお、Ｓ６１１の時点では、クライアントからのリクエストはＶＭ５１２にはまだ転送されない。

Ｓ６１２ではリソース操作部３６１は、Ｂｌｕｅ環境のＶＭと旧Ｂｌｕｅ環境の外部公開しているロードバランサとの対応付けを解除するようにテーブル４１０を再度更新し、デプロイ処理を終了する。なお、ヘルスチェックが不要である場合は、Ｓ６０６およびＳ６０７を省略して、Ｓ６０８に処理を進めてもよい。また、Ｓ６０８でリソース操作部３６１がロードバランサ５１１に対する指示を行わずに、図４（ｂ）のテーブルで対応付けが行われたことに応じて、ロードバランサ５１１がＶＭ５２２へリクエストを転送してもよい。

本実施例で説明したように、処理環境５２０がクライアントからのリクエストを受け付ける設定がＤＮＳサーバーのレコードで保持されている場合であっても、処理環境５１０のロードバランサがクライアントからのリクエストを受け付けることがある。その場合に、本実施例では、システム管理部３６０が、処理環境５１０のロードバランサと処理環境５２０の仮想マシンとの対応付けを行い、かつ、処理環境５１０のロードバランサと処理環境５１０の仮想マシンとの対応付けを解除した。本実施例により、ＤＮＳサーバーで本番環境として設定されていない処理環境の負荷分散装置が受け付けたリクエストを、本番環境として設定されている処理環境の仮想マシンで処理することが可能となる。

（実施例２）
実施例１では切り替え後のＢｌｕｅ環境と旧Ｂｌｕｅ環境の２つの環境に対して、ロードバランサからＶＭにリクエストを転送するための設定値の更新フローを説明した。しかし、処理環境のバージョンアップが頻繁に行われる場合、並存する環境は２つに限られない。バージョンアップごとに処理環境を作成して、不要になった処理環境を削除するというデプロイメント手法がしばしば用いられる。つまり、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントにおいて接続先の切り替えが完了し、システムに問題がないことが確認できた場合には、旧本番環境は不要となるため旧本番環境を削除することも可能である。そのような場合においても実施例１で説明した同様の理由で、古い処理環境にリクエストを送信し続けるクライアントは存在するため、クライアントのリクエスト送信先を最新バージョンの処理環境に向ける必要がある。実施例２では実施例１の応用例として、本番環境ではない処理環境が複数存在する場合の処理環境の管理方法について説明する。

図７は、切り替え後に処理環境が３以上存在する場合のクラウドシステム構成例を示す図である。７０２と７０３は実施例１と同様に、クライアントのネットワーク環境でＤＮＳキャッシュが更新されないなどが原因で、旧処理環境にリクエストを送信し続けるクライアントである。クライアント７０３は旧Ｂｌｕｅ環境７２０にリクエストを送信し、クライアント７０２は旧Ｂｌｕｅより更に古い処理環境（旧々Ｂｌｕｅと呼ぶ）７１０にリクエストを送信するクライアントである。クライアント７０４はクラウドシステム３０１で管理するサービスの正式なＦＱＤＮと紐付いたロードバランサ７３１を有するＢｌｕｅ環境７３０にリクエストを送信するクライアントである。切り替え後、リソース操作部３６１は、ロードバランサ７１１、７２１からＶＭ７３２にリクエストを転送するようにロードバランサ７１１と７２１の設定値を更新する。それと共に、リソース操作部３６１は、ロードバランサ７１１からはＶＭ７１２に、ロードバランサ７２１からはＶＭ７２２にリクエストを転送しないようにロードバランサ７１１と７２１設定値を更新する。

図８は、処理環境の管理テーブルを処理工程ごとに示した図である。８００は処理環境をバージョンごとに管理するための管理テーブルである。管理テーブル８００は、図４の管理テーブル４１０を拡張したテーブルを想定しているが、新たに用意したテーブルでもよい。管理テーブル８００は、管理用データストア３７０で保持されて、デプロイメント中の各工程においてリソース操作部３６１により更新される。

８０１は処理環境のバージョンを示しており、図４の４１１に対応する。８０２は外部公開しているロードバランサをユニークなＩＤで示したものであり、４１２に相当する。８０３は外部公開しているロードバランサ７１１、７２１、７３１などがリクエストを転送する先のＭＶを示しており、図４の４１６に対応する。８０４は処理環境のシステムモードを示している。本実施例では説明の便宜上“ｏｌｄｂｌｕｅ”， “ｂｌｕｅ”， “ｇｒｅｅｎ”， “ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”， “ｓｗｉｔｃｈｂａｃｋ”の５つのシステムモードを定義した。“ｏｌｄｂｌｕｅ”は過去にＢｌｕｅ環境として稼働していた処理環境である。“ｂｌｕｅ”は、Ｂｌｕｅ環境として稼働している処理環境であり、実施例１で説明したような他の処理環境のロードバランサからのリクエストの転送先であるＶＭを有する処理環境である。“ｇｒｅｅｎ”は、Ｇｒｅｅｎ環境として稼働している処理環境であり、“ｂｌｕｅ”の処理環境にリクエストを転送しない唯一の処理環境である。“ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”は、過去にＢｌｕｅ環境であったが、切り戻しがある場合に再度Ｂｌｕｅ環境になり得る処理環境であり、前回“ｂｌｕｅ”であった処理環境が切り替えにより“ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”となる。“ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”は、所定期間が経過した後、“ｂｌｕｅ”が正常稼働していると判断された後に、“ｏｌｄｂｌｕｅ”になる。所定期間としては、１週間から１か月程度の期間が想定される。“ｓｗｉｔｃｈｂａｃｋ”は、Ｂｌｕｅ環境で異常が発生した際などに、切り戻されて再度Ｂｌｕｅ環境になった処理環境である。８０５はシステムモードが変更された際のシステムモード更新日時を示している。

図８（ａ）はＧｒｅｅｎ環境を構築してから切り替え前までの管理テーブル８００である。図８（ｂ）は切り替え後から“ｂｌｕｅ”が正常に稼働していると判断されるまでの管理テーブル８００である。図８（ｃ）は“ｂｌｕｅ”が正常に稼働していると判断されず、切り戻しを行った後の管理テーブル８００の例である。具体的には、後述する図９のＳ９０２後の状態が図８（ａ）、Ｓ９０５後の状態が図８（ｂ）、Ｓ９１３後の状態が図８（ｃ）に対応している。

図９は処理環境の管理テーブルを用いた一連のデプロイメント処理の手順例を示すフローチャートである。すなわち、図９のフローチャートの処理は、データセンター上のサーバーコンピューターのＣＰＵ２０３が、ＲＯＭ２０４または二次記憶装置２０６に記録されたプログラムを読み出して実行することにより実現される。

Ｓ９０１では、リソース操作部３６１が、Ｓ６０１と同様にリソース生成部３５１に対してＧｒｅｅｎ環境の構築の指示を行う。Ｓ９０２では、リソース操作部３６１は、Ｓ９０１で構築されたＧｒｅｅｎ環境を管理テーブル８００に追加する。Ｓ９０３は、リソース操作部３６１が、Ｓ６０２と同様に切り替えを指示する。Ｓ９０４では、正常に切り替えが実行されたか確認を行い、正常に切り替えられた場合はＳ９０５を実行し、正常に切り替えられなかった場合はデプロイメント処理を終了する。

Ｓ９０５では、リソース操作部３６１は、管理テーブル８００の各環境の情報を更新する。まず、リソース操作部３６１はシステムモード８０２が“ｂｌｕｅ”である処理環境を“ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”に、“ｇｒｅｅｎ”である処理環境を“ｂｌｕｅ”に更新する。次に、リソース操作部３６１は、システムモード８０２が更新された処理環境のシステムモード更新日時８０５を更新する。最後に、リソース操作部３６１は、システムモードが“ｏｌｄｂｌｕｅ”，“ｗａｉｔｉｎｇｏｌｄ”に更新された処理環境のロードバランサのリクエストの転送先のＶＭを“ｂｌｕｅ”のＶＭに更新する。Ｓ９０６ではシステムモード８０２が“ｂｌｕｅ”の処理環境が正常に稼働しているかどうかが確認され、正常に稼働している場合はＳ９０７を実行し、正常に稼働していない場合はＳ９１２を実行する。正常に稼働しているかどうかは、テスト部３６２が実行したテストをパスしたことや、一定時間経過後、一定リクエスト処理後にエラーが発生しなかったこと、などを基準に判断される。

Ｓ９０７では、リソース操作部３６１はシステムモード８０２が“ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”の処理環境を“ｏｌｄｂｌｕｅ”に変更すると共に、システムモード更新日時８０５を更新する。Ｓ９０８ではテスト部３６２およびリソース操作部３６１は、システムモード８０２が“ｏｌｄｂｌｕｅ”のロードバランサと、リクエストの転送先としての“ｂｌｕｅ”のＶＭとの対応付けを行う。さらにテスト部３６２は、ヘルスチェックを実行するように指示する。Ｓ９０９では、Ｓ６０７と同様にヘルスチェックの結果に基づき、テスト部３６２は、“ｂｌｕｅ”のＶＭへリクエストを転送可能であると確認された場合はＳ９１０を実行し、転送可能でないと確認された場合はＳ９１５を実行する。なお、ヘルスチェックに失敗した場合も、テスト部３６２はＳ９１５を実行する。

Ｓ９１０ではリソース操作部３６１は、Ｓ９０９にてヘルスチェックが成功したロードバランサとＶＭの組に対して、ロードバランサからＶＭにリクエストを転送するように指示する。Ｓ９１１ではリソース操作部３６１は、管理テーブル８００の情報をもとに、システムモード８０２が“ｏｌｄｂｌｕｅ”および“ｓｗｉｔｃｈｂａｃｋ”の処理環境のロードバランサと自身の環境のＶＭとの対応付けを解除する。なお、Ｓ６０９と同様に、リソース操作部３６１は、ロードバランサとＶＭとの対応付けを解除するのではなく、通信を閉塞するだけでもよい。

Ｓ９１２では、リソース操作部３６１はＳ６１０と同様に切り戻しを実行する。このとき、切り戻した結果Ｂｌｕｅ環境になるのは、システムモード８０２が“ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”である処理環境である。Ｓ９１３では、まず、リソース操作部３６１はシステムモード８０２が“ｗａｉｔｉｎｇｏｌｄｂｌｕｅ”であった処理環境を“ｂｌｕｅ”に、“ｂｌｕｅ”であった処理環境が“ｓｗｉｔｃｈｂａｃｋ”になるように管理テーブル８００を更新する。次に、リソース操作部３６１はシステムモード８０２を変更した処理環境のシステムモード更新日時８０５を更新する。最後に、リソース操作部３６１はロードバランサからのリクエストの転送先ＶＭを“ｂｌｕｅ”の処理環境ＶＭに設定する。Ｓ９１４ではテスト部３６２およびリソース操作部３６１は、切り戻された処理環境（この時点で“ｓｗｉｔｃｈｂａｃｋ”）のロードバランサに、切り戻した処理環境（この時点で“ｂｌｕｅ”）のＶＭを追加し、ヘルスチェックを実行する。

Ｓ９１５ではリソース操作部３６１は、ヘルスチェックに失敗した“ｏｌｄｂｌｕｅ”と“ｓｗｉｔｃｈｂａｃｋ”の処理環境のロードバランサとリクエストの転送先である“ｂｌｕｅ”のＶＭとの対応付けを解除する。

前述した通り、バージョンアップの頻度が高いサービスの場合、旧Ｂｌｕｅ環境を残し続けることも可能であるが、運用コストが高くなるため、不要な処理環境は削除するのが望ましい。クライアントがアクセス可能な外部公開しているロードバランサをのみを残し、ロードバランサ配下のコンピュータリソースを条件に応じて削除する方法を説明する。

図１０は旧Ｂｌｕｅ環境のリソースの削除処理の手順例を示すフローチャートである。Ｓ１００１では、リソース監視部３５３は、システムモード８０２が、“ｏｌｄｂｌｕｅ”の処理環境の各種コンピュータリソースの使用状況、アクセスログ、動作ログなどをリソース監視部３５３が監視する。Ｓ１００２では、リソース監視部３５３は、システムモード８０２が“ｏｌｄｂｌｕｅ”の処理環境の外部公開されているロードバランサ以外のコンピュータリソースの使用状況を確認する。リソース監視部３５３は、サーバーに一定時間以上アクセスが無いか、キューにデータがないかなどの条件で判断を行い、条件を満たすと判断した場合はＳ１００３を実行する。そうでない場合は再度時間をおいてリソース監視部３５３がコンピュータリソースの使用状況やログを確認する。Ｓ１００３ではシステムモード８０２が“ｏｌｄｂｌｕｅ”の処理環境の外部公開されているロードバランサ以外のコンピュータリソースを削除する。Ｓ１００４ではシステムモード８０２が“ｏｌｄｂｌｕｅ”の処理環境の外部公開されているロードバランサのアクセスログを確認する。一定時間以上アクセスログが確認できない場合は、Ｓ１００５を実行し、一定時間以内にアクセスログがある場合は再度時間をおいてリソース監視部３５３がロードバランサのアクセスログを確認する。Ｓ１００５ではシステムモード８０２が“ｏｌｄｂｌｕｅ”の処理環境の外部公開されているロードバランサを削除する。

なお、Ｓ１００３において、旧Ｂｌｕｅ環境のキューにメッセージがまだ残っている場合には、旧Ｂｌｕｅ環境のＶＭ７２２のみを削除して、旧Ｂｌｕｅ環境のキューおよびキュー内のメッセージを処理するＶＭを削除しないようにしてもよい。

本実施例では、クラウドシステム内に処理環境が３つ並存する場合に、システム管理部３６０は、ＤＮＳサーバーで本番環境として設定されていない処理環境の負荷分散装置と、本番環境として設定されている処理環境の仮想マシンとを対応付けた。さらに、システム管理部３６０は、本番環境として設定されていない処理環境の仮想マシンを削除した。本実施例により、ＤＮＳサーバーで本番環境として設定されていない処理環境の負荷分散装置が受け付けたリクエストを、本番環境として設定されている処理環境の仮想マシンで処理することが可能となる。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１０１サーバー
２０３ＣＰＵ
３０１クラウドシステム
３６０システム管理部
３６１リソース操作部

Claims

クライアントからのリクエストを処理可能な複数の仮想マシンと、前記複数の仮想マシンにリクエストを転送する負荷分散装置とを少なくとも備える複数の処理環境を管理する管理システムであって、
負荷分散装置から、いずれの仮想マシンにリクエストを転送させるかを管理する管理手段を有し、
前記管理手段は、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から前記第１の処理環境とは別の第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないよう管理することを特徴とする管理システム。
負荷分散装置から、転送先の候補となる仮想マシンへリクエストを転送可能であるか否かの確認を、前記負荷分散装置に対して指示する第１の指示手段を有し、
前記指示に基づき、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンへリクエストを転送可能であると確認された際に、前記第１の処理環境の負荷分散装置が受け付けたリクエストが前記第２の処理環境の仮想マシンに転送されることを特徴とする請求項１に記載の管理システム。
前記管理手段は、前記第１の指示手段の指示に基づき、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンへリクエストを転送可能であると確認された際に、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないように管理することを特徴とする請求項２に記載の管理システム。
クライアントからのリクエストを受け付ける装置についての設定は、前記管理システムがアクセス可能なＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバーで保持されることを特徴とする請求項１乃至３のいずれか１項に記載の管理システム。
仮想マシンの生成または削除を実行するリソース管理部に対して指示を行う第２の指示手段を有し、
前記第２の指示手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更されてから第１の所定期間が経過した際に、前記第１の処理環境の仮想マシンを削除するための指示を前記リソース管理部に対して行うことを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
前記第２の指示手段は、前記リソース管理部に対して、負荷分散装置の生成または削除の指示を更に行うことが可能であり、
前記第２の指示手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更されてから前記第１の所定期間よりも長い第２の所定期間が経過した際に、前記第１の処理環境の負荷分散装置を削除するための指示を前記リソース管理部に対して行うことを特徴とする請求項５に記載の管理システム。
前記第２の指示手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更されてから前記第２の所定期間が経過した際に、前記第１の処理環境の負荷分散装置がクライアントからのリクエストを受け付けていない場合には、前記第１の処理環境の負荷分散装置を削除するための指示を前記リソース管理部に対して行うことを特徴とする請求項６に記載の管理システム。
前記第２の処理環境の仮想マシンで動作するアプリケーションのバージョンは、前記第１の処理環境の仮想マシンで動作するアプリケーションのバージョンよりも新しいことを特徴とする請求項１乃至７のいずれか１項に記載の管理システム。
前記第１の処理環境は複数存在することを特徴とする請求項８に記載の管理システム。
前記管理手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更された後、更に前記第１の処理環境の負荷分散装置へ変更された際に、
前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させるよう管理し、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させないよう管理し、前記第２の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第２の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させないよう管理することを特徴とする請求項１乃至８のいずれか１項に記載の管理システム。
クライアントからのリクエストを処理可能な複数の仮想マシンと、前記複数の仮想マシンにリクエストを転送する負荷分散装置とを少なくとも備える複数の処理環境を管理する管理システムの制御方法であって、
負荷分散装置からいずれの仮想マシンにリクエストを転送させるかを管理する管理工程を有し、
前記管理工程では、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から前記第１の処理環境とは別の第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストが転送されるよう管理され、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストが転送されないよう管理されることを特徴とする制御方法。