JP5491934B2 - サーバ装置、及び情報処理システムの制御方法、並びにプログラム - Google Patents

Description

本発明は、サーバ装置、及び情報処理システムの制御方法、並びにプログラムに関し、例えば、複数の物理サーバ間でのゲストＯＳの移行に関する技術に関するものである。

近年、仮想化技術を利用し、サーバ集約によるコスト削減を実施する企業が増加してきている。また、仮想化技術を利用して構築された他社のデータセンターのリソースを、インターネット越しに利用する、いわゆるクラウドコンピューティングも普及しつつある。こうした流れを受け、現在、企業内のリソースが不足した際に、他社の物理マシンリソースを借りることを前提としたハイブリット型のデータセンターを構築する企業が増えてきている。仮想化のメリットとして、リソースの効率的な利用によるコスト削減や柔軟な拡張性等が挙げられるが、特に、ライブマイグレーションによる効果が大きい。ライブマイグレーションとは、ある仮想マシンで動作するＯＳを、他の仮想マシンに移行し動作させる技術である。ライブマイグレーションにより、データセンターにおける高可用性（常に稼動させておけること）や高メンテナンス性を実現することが可能となり、現在の仮想化技術には欠かせない技術となっている。

しかしながら、ライブマイグレーションを行うには、SAN、iSCSI等を利用して、移行元と移行先のサーバ間で共有ストレージを設定し、そこに移行元と移行先が使用するＯＳイメージを配置する必要があり、広域ネットワークを経由するデータセンター等では、ネットワーク遅延等により、ストレージを共有するのが困難な場合がある。

この問題に対し、例えば特許文献１では共有ストレージを組まないライブマイグレーション技術が提案されている。特許文献１によれば、移行元と移行先の仮想サーバ上において、移行対象となるストレージ領域を識別する制御部を持たせてストレージ管理を行うことで、移行元と移行先の仮想サーバで共有ストレージを必要としないライブマイグレーションが可能になっている。

このように、サーバでの仮想化技術が進歩する一方で、クライアントＰＣにおいても仮想化技術が浸透しつつある。例えば、セキュリティやコンプライアンス対策など、管理コストのかさむクライアントデスクトップ環境の運用コストを下げるソリューションである仮想デスクトップがある。仮想デスクトップとは、仮想サーバ上で動作しているゲストＯＳへシンクライアント端末からＲＤＰ(Remote Desktop Protocol)により接続してデスクトップ環境を使用するシステムである。

特開２００９−１４００５３号公報

仮想デスクトップ等のクライアント仮想化には、サーバ仮想化とは異なるいくつかの特徴がある。例えば、個々の仮想マシンのリソース使用量は少ないが、クライアント数が多いので、合計するとリソース使用量が多くなる。また、仮想デスクトップでは、サーバに比べて、比較的短い間隔で起動・シャットダウンが行われる。このような特徴を持つため、特許文献１のように個々の仮想マシン毎にボリュームを認識するのは管理・運用が煩雑になる問題がある。

さらに、通常の共有ストレージを使用した場合、ボリューム(ゲストＯＳイメージ)へのＩ／Ｏが広域ネットワーク越しに行われるため、ユーザインターフェース関連のレスポンスが悪い等の問題もある。特に、ＲＤＰにおいては、ゲストＯＳイメージを保存しているストレージが遠隔地にあると遅延による問題が顕著に現れる。そのため、仮想デスクトップ等のクライアント仮想化においては、共有ストレージを利用したマイグレーションは困難であり、共有ストレージが不要で、かつ、ストレージ管理を容易にするシステム構成が求められる。

本発明はこのような状況に鑑みてなされたものであり、共有ストレージを使用することなく、かつ、既存のライブマイグレーション技術を利用して、管理・運用性に優れた移行技術を提案するものである。

上記課題を解決するために、本発明では、ゲストＯＳ上において、ゲストＯＳが管理するボリュームへの書込みをメモリ上にリダイレクトしてキャッシュし、ボリュームへの書込みを禁止し、ゲストＯＳのイメージデータへの書込み・更新を抑制する。

また、移行元と移行先の２つの物理サーバがそれぞれ参照しているストレージに、同じゲストＯＳのイメージをあらかじめ配置しておく。この状態であれば、移行時に移行元の各ゲストＯＳが使用しているメモリのデータ及びＣＰＵレジスタのデータを移行先の仮想サーバへコピーすることで、移行を実施することが可能である。なお、ゲストＯＳが管理するボリュームとは、ゲストＯＳのデータが格納されている仮想化されたボリュームで、ゲストＯＳを管理するホストＯＳからはゲストＯＳイメージとして認識されているファイルである。

つまり、既存のライブマイグレート技術において、ゲストＯＳイメージを共有ストレージに配置しておかなければならない理由は、移行元と移行先の仮想マシンが同じ状態のゲストＯＳイメージを参照しなければならないからである。本発明では、ゲストＯＳ上からのゲストＯＳイメージへの書込みをリダイレクトし、ゲストＯＳが認識するメモリ領域にキャッシュすることで、ゲストＯＳイメージの更新書込みが発生しない状態を作っている。よって、ホストＯＳから見た場合、物理サーバ上で動作するゲストＯＳイメージはRead Only状態となっており、２つの物理サーバが、各々の物理サーバのローカルストレージのみを参照している状態において、あらかじめ各々のローカルストレージに同じゲストＯＳイメージを配置しておけば、各仮想マシンは同じゲストＯＳイメージを常に参照することになる。

より具体的には、本発明によるシステム（情報処理システム）は、利用者端末装置とローカルネットワーク（ＬＡＮ）で接続された第１のサーバ装置（プライベートサイト内のサーバ装置：複数あってもよい。）と、第１のサーバ装置と広域ネットワーク（ＷＡＮ）で接続された第２のサーバ装置（パブリックサイト内のサーバ装置：複数あってもよい。）と、を有し、利用者端末装置に仮想マシン上で動作するオペレーティングシステムであるゲストＯＳを提供するする情報処理システムである。そして、第１及び第２のサーバ装置がそれぞれ、ゲストＯＳ及びそれに対応するゲストＯＳイメージを認識している。ゲストＯＳイメージは、例えば、ＳＡＮストレージに格納されている。

このようなシステムにおいて、第１のサーバ装置は、ゲストＯＳに対応するゲストＯＳイメージを取得してゲストＯＳを起動させて、利用者端末装置に提供しているときに、ゲストＯＳを起動させたまま、ゲストＯＳの移行指示（例えば、自装置でのリソースが足りなくなった場合に発行される）に応答して、ゲストＯＳが使用するリソースデータ（ＣＰＵの使用量やメモリの使用容量等）を、広域ネットワークを介して第２のサーバ装置に送信する。そして、第２のサーバ装置は、送信されてきたリソースデータを用いて、第２のサーバ装置が有する前記ゲストＯＳを起動させる。第１のサーバ装置は、ゲストＯＳが第２のサーバ装置で起動した後、第１のサーバ装置で動作するゲストＯＳをシャットダウンする。なお、第１のサーバ装置が、自装置におけるリソースの状態を監視し、当該監視結果に基づいて、ゲストＯＳの移行処理を実行するか否か判断するようにしても良い。これにより、シームレスなゲストＯＳ移行を実現する。

また、第１又は第２のサーバ装置において動作するゲストＯＳは、ゲストＯＳイメージに対する書き込みをリダイレクトして、当該書き込みによる変更データを主記憶デバイスに格納し、ゲストＯＳを提供している利用者端末装置が動作している間はゲストＯＳイメージに対する変更を禁止する。そして、ゲストＯＳが動作する第１又は第２のサーバ装置は、ゲストＯＳイメージに対する変更適用の指示、或いは、利用者端末装置のシャットダウンに応答して、ゲストＯＳイメージに対する書き込みによる変更データをゲストＯＳイメージに反映させる。ゲストＯＳイメージを変更した第１又は第２のサーバ装置は、変更前のゲストＯＳイメージを有するサーバ装置に対して、ゲストＯＳが認識するゲストＯＳイメージを書き換える指示及び変更内容を送信する。一方、指示を受け取ったサーバ装置は、変更内容に従って、ゲストＯＳイメージを変更する。

第２サーバ装置にゲストＯＳが移行されている状態でも、第１のサーバ装置は、自装置におけるリソースの状態を監視し、当該監視結果に基づいて（自装置のリソースに余裕が出た場合）、第２のサーバ装置に対して、第２のサーバ装置のゲストＯＳが使用するリソースデータの転送をリクエストする。このリクエストに応答して、第２のサーバ装置は、リソースデータを前記第１のサーバ装置に転送し、第１のサーバ装置は、自装置のゲストＯＳにリソースデータを反映させて、再度ゲストＯＳを起動させる。

さらなる本発明の特徴は、以下本発明を実施するための形態および添付図面によって明らかになるものである。

本発明によれば、共有ストレージを使用することなく、かつ、既存のライブマイグレーション技術を利用して、管理・運用性に優れたゲストＯＳの移行を実現することが可能となる。

本発明の実施形態によるシ情報処理ステムの概略構成を示す図である。 仮想サーバの内部構成を示す図である。 仮想管理サーバの内部構成を示す図である。 ゲストＯＳイメージの設定、セットアップの動作を説明するためのフローチャートである。 ユーザが利用者端末装置を起動してゲストＯＳを使用するまでの動作を説明するためのフローチャートである。 書込み制御モジュールの処理動作を説明するためのフローチャートである。 ゲストＯＳの移行が実施される場合の処理を説明するためのフローチャートである。 ユーザが利用者端末装置をシャットダウンした場合の処理を説明するためのフローチャートである。 ゲストＯＳ管理テーブルの構成例を示す図である。

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

＜システム構成＞
図１は、本発明の実施形態による情報処理システムの概略構成を示す図である。当該システムは、例えば企業内ネットワークで構成されるサイトのようなプライベートサイト（サイトＡ）１０１と、例えばAmazon（登録商標）S3のようなパブリックサイト（サイトＢ）１０７と、を有し、それらがネットワークで接続されている。なお、パブリックサイトが複数存在した構成も可能であり、その場合、各パブリックサイトの内部構成はパブリックサイト１０７と同じである。

プライベートサイト１０１には、少なくとも１つの利用者端末装置１０２と、仮想化を適用した物理サーバ（以下、仮想サーバという）を管理するための仮想管理サーバ１０３と、仮想サーバＡ１０４及びそのサーバが参照するＳＡＮストレージＡ１０５と、が含まれている。仮想サーバＡとＳＡＮストレージＡの組は複数あってもよい。また、ＳＡＮストレージＡ１０５は、その中にゲストＯＳイメージＡ１０６を格納している。仮想管理サーバ１０３と仮想サーバＡ１０４の機能を１つに統合したサーバを設置するようにしても良い。

また、パブリックサイト１０７には、仮想サーバＢ１０８及びそのサーバが参照するＳＡＮストレージＢ１０９が含まれている。ＳＡＮストレージＢは、その中にゲストＯＳイメージＢ１１０を格納している。

ネットワークに関し、例えば、各サイト内のネットワークはローカルエリアネットワーク（ＬＡＮ）として構成され、サイト間（プライベートサイトとパブリックサイト間）のネットワークは広域ネットワーク（ＷＡＮ１１１）として構成される。広域ネットワークとローカルネットワークでは、ＩＰアドレス等のネットワーク構成が異なる。そのため、２つの物理サーバ（仮想サーバＡ及びＢ）が広域ネットワークを経由してデータ通信を行うには、ＶＰＮ装置を通して、同じＬＡＮネットワーク構成を実現して通信を行う。本発明では、ＶＰＮを実現するために、専用のＶＰＮ装置を使用し、複数のネットワークが単一のＬＡＮ構成であると仮定する。ただし、同じＬＡＮ構成が適用できるとしても、広域ネットワークでデータ転送が行われるため、ネットワーク遅延などは発生する。本発明は、これらの広域ネットワークの遅延による影響を受けにくいシステムであることも特徴の１つである。

なお、仮想サーバＡ１０４と仮想サーバＢ１０８の内部構成は同じであるため、内容が同じである場合は、以下では、単に「仮想サーバ」と記述する場合もある。

＜仮想サーバの内部構成＞
図２は、図１の仮想サーバＡ１０４と仮想サーバＢ１０８の内部構成を詳細に示す図である。ここでは、仮想サーバＡ１０４と仮想サーバＢ１０８の内部構成は同じであるため、“仮想サーバ２００”として説明を進める。

図２において、仮想サーバ２００は、複数のゲストＯＳ２０１と（登録されたユーザに対して１対１に割り当てられ、図１におけるゲストＯＳイメージＡ１０６やＢ１１０と同じもの）、それらのゲストＯＳを管理する１つのホストＯＳ２０２を同時に動作させる物理サーバである。そして、仮想サーバ２００は、複数のゲストＯＳ２０１と、ホストＯＳ２０２と、ホストＯＳ２０２が提供する処理動作を制御するＣＰＵ２０３と、主記憶装置（例えば、キャッシュメモリ）２０４と、入出力装置（例えば、キーボード、マウス等、及び表示装置、プリンタ等）２０５と、ホストＯＳの動作データを格納するローカルストレージ（例えば、ＨＤＤ）２０６と、ネットワークデバイス（例えばＮＩＣ等）２０７と、を有している。

ローカルストレージ２０６には、ホストＯＳ２０２及び、仮想化を実現するＶＭＭ２０８（Virtual Machine Monitor：仮想マシンモニタ）に必要なデータがインストールされている。

また、仮想サーバ２００（仮想サーバＡ及びＢ）は、ローカルストレージ２０６とは別に、ＳＡＮによるストレージ装置（図１のＳＡＮストレージＡ１０５、または、ＳＡＮストレージＢ１０９）に接続されており、それぞれのストレージ装置にゲストＯＳイメージ（図１のゲストＯＳイメージＡ１０６、または、ゲストＯＳイメージＢ１１０）を格納している。通常、ライブマイグレートを行う場合は、１つのＳＡＮストレージを、複数のサイトに配置されている複数の仮想サーバで共有する必要があるが、本発明では共有設定を必要としない。なお、ここでは、ローカルストレージ２０６に、ホストＯＳ２０２及び、ＶＭＭ２０８をインストールした構成を示したが、ＳＡＮストレージ内にそれらのデータをインストールして仮想サーバを起動する構成でも構わない。

ＶＭＭ２０８は、複数のゲストＯＳ２０１を同時に動作させるために、ゲストＯＳ毎に、仮想サーバ２００のＣＰＵ２０３、主記憶装置２０４、ネットワークデバイス２０７、ローカルストレージ２０６、及びＳＡＮストレージのハードウェアリソースの割り振り（例えば、ＣＰＵの可能使用量やメモリ使用可能容量）を実行するモジュールである。

ホストＯＳ２０２は、ＶＭＭ２０８と連携してゲストＯＳを管理する機能を有するが、より具体的には、仮想サーバ２００のハードウェアリソースの管理、ゲストＯＳ２０１の起動・シャットダウン・移行等を、ＶＭＭ２０８に命令して実行する機能を備えている。実際に、それらの機能を実行するモジュールとして、仮想マシン管理モジュール２０９と、移行管理モジュール２１０と、ストレージ管理モジュール２１１と、リソース管理モジュール２１２と、ファイル同期モジュール２１３が動作している。なお、これらのモジュールは、仮想管理サーバ１０３上の各サービスと連携して動作することが可能であるものとする。

仮想マシン管理モジュール２０９は、仮想サーバ２００上で動作するゲストＯＳ２０１の起動・シャットダウン・移行・サスペンド・レジュームをＶＭＭ２０８に命令するモジュールである。また、仮想マシン管理モジュール２０９は、ゲストＯＳ２０１用の仮想マシンの作成、削除、及び各仮想マシンに割り当てられるＣＰＵの数量、主記憶装置のサイズ、ストレージ等の設定を行う際にも利用される。

移行管理モジュール２１０は、後述する移行管理サービス３０２と連携して、ゲストＯＳを物理サーバ間で移行する機能（移行管理サービス３０２から移行命令を受け取っていこう処理を実行する機能）を有している。移行管理モジュール２１０は、仮想サーバＡ上で動作しているゲストＯＳを、仮想サーバＢへ起動状態のまま移行させて、ゲストＯＳの動作を継続することが可能である。実際の移行時の動作は、実際のゲストＯＳイメージデータを送信するのではなく、仮想サーバＡ上のゲストＯＳのＣＰＵレジスタのデータ及びメモリのデータを、ＶＭＭ２０８を経由して読み出し、移行先の仮想サーバＢに転送・コピーすることで実現している。これは、既存の移行技術を利用することで実現できる。ＷＡＮを経由してシステムを全く停止させずにゲストＯＳのライブマイグレートを実現するのは困難であるが、このようにＣＰＵレジスタのデータ及びメモリのデータの転送・コピーだけで処理できるので、システムを完全にシャットダウンせずに移行させることが可能となる。なお、移行開始のトリガーは、仮想管理サーバ１０３の移行管理サービス３０２からの移行命令による。当該移行命令は、例えば、リソースの監視の結果、仮想サーバＡのリソースに余裕がなくなってきたことを検知した場合に発行される。この処理については図７で詳細に解説する。また、任意のタイミングで管理者がＧＵＩ経由で直接命令を出すことも可能であるものとする。

ストレージ管理モジュール２１１は、仮想サーバ２００が使用するＳＡＮストレージの管理を行うモジュールである。本来ならば、仮想サーバＡと仮想サーバＢ間でゲストＯＳを移行させる際には、移行元と移行先で、１つのＳＡＮストレージを共有し、その共有ストレージにゲストＯＳイメージを配置しておく必要がある。しかし、本発明では、共有ストレージを必要とせず、起動状態での移行を可能である。これは、図５で詳細に解説する。

リソース監視モジュール２１２は、仮想サーバ２００上のＣＰＵ２０３、主記憶装置２０４、ネットワークデバイス２０７、ローカルストレージ２０６、及び、仮想サーバに接続されているＳＡＮストレージのモニタリングを行う。また、リソース監視モジュール２１２は、後述する仮想管理サーバ１０３のリソース監視サービス３０５に対して、モニタリング結果を通知する機能も有している。リソース監視モジュール２１２による監視結果がゲストＯＳの移行のタイミングを決定するために用いられる。

ファイル同期モジュール２１３は、各ＳＡＮストレージに保存されているゲストＯＳイメージを同期させる機能を有している。ここで「ゲストＯＳイメージの同期」とは、各ユーザに割り当てられているゲストＯＳイメージに変更があった場合、各ＳＡＮストレージに保存されている当該ユーザのゲストＯＳイメージを同様に変更することをいうものとする。各サイトのＳＡＮストレージに配置されるゲストＯＳイメージは、１つの利用者端末装置（１人のユーザ）につき、１つのゲストＯＳイメージが割り当てられるように、あらかじめ管理者が登録を行う（図４のフローチャートで説明する）。ファイル同期モジュール２１３の機能により、ゲストＯＳイメージは、ゲストＯＳが起動する前は常に同じ状態となる。つまり、図１では、ある利用者端末装置に割り当てられたゲストＯＳイメージＡ１０６とゲストＯＳイメージＢ１１０は同じである。また、ゲストＯＳの起動中も、後述する書込み制御モジュール２１４の機能により、ゲストＯＳイメージへの改変はなく、常に同一である。各ＳＡＮストレージのゲストＯＳイメージに差異が発生するのは、ゲストＯＳのシャットダウン時に、ユーザがデータの書込みを選択した場合である。データ書込みにより差異が発生した場合、ファイル同期モジュール２１３は、この利用者端末装置毎のゲストＯＳイメージが各ＳＡＮストレージ上で常に同一となるように同期を実行する。この同期処理について図８を用いて説明する。

ゲストＯＳ２０１は、ＲＤＰを使って利用者端末装置上のＲＤＰクライアントとの間にセッションを確立し、利用者端末装置から遠隔で使用可能なＯＳである。ゲストＯＳ２０１は仮想サーバＡ１０４、または、仮想サーバＢ１０８上で複数起動し、複数の利用者端末装置から使用される。また、ゲストＯＳの特徴として、書込み制御モジュール２１４がインストールされている。

書込み制御モジュール２１４は、ゲストＯＳ２０１、及び、ゲストＯＳ２０１上で動作しているアプリケーションが、ゲストＯＳ２０１が認識しているボリュームへ書込みを行った場合に、書込みデータをゲストＯＳ２０１が認識しているメモリ領域へリダイレクトして、ボリュームへの書込みを禁止する機能を備えている。なお、ゲストＯＳ２０１が認識しているボリュームとは、ホストＯＳ２０２から見た場合、ゲストＯＳイメージのことを意味する。書込み制御モジュール２１４の機能により、ゲストＯＳ２０１上でのゲストＯＳイメージへの書込みが無くなるため、ゲストＯＳイメージはRead Only状態となる。よって、２つの物理サーバ（仮想サーバＡ及び仮想サーバＢ）がそれぞれのＳＡＮストレージのみを参照している状態において（共有ストレージがない状態において）、あらかじめ各々のＳＡＮストレージに同一のゲストＯＳイメージを配置しておけば、書込み更新されたデータはメモリ上から読み出し、それ以外のデータは各ＳＡＮストレージ上のゲストＯＳイメージから読込むことが可能となる。以上により、書込み制御モジュール２１４を利用すれば、共有ストレージ無しで、ゲストＯＳイメージを共有ストレージに配置した時と同じ効果を得ることが可能となり、移行時に各ゲストＯＳが使用しているメモリデータ・ＣＰＵレジスタをコピーするのみで、２つの物理サーバ間（仮想サーバＡと仮想サーバＢの間）でゲストＯＳの移行を実現できる。また、書込み制御モジュール２１４のもう１つの機能として、ゲストＯＳ２０１がシャットダウンするタイミングで、メモリにキャッシュしたデータをゲストＯＳイメージに書込むことも可能であり、ゲストＯＳシャットダウン時に、利用者端末装置のユーザに対して、書込みを行うか、行わないかを選択させる機能をも持たせるようにしても良い。

＜仮想管理サーバの内部構成＞
図３は、図１の仮想管理サーバ１０３の内部構成を詳細に表した図である。なお、以下の説明において、「連携して」とは、命令や指示を受け取り、それに従った処理を実行したり、他のモジュールやサービスに当該処理の実行を指示したりすることを意味するものとする。

仮想管理サーバ１０３は、仮想サーバＡ１０４、ＳＡＮストレージＡ１０５、仮想サーバＢ１０８やＳＡＮストレージＢ１０９を統合管理するサーバである。そして、仮想管理サーバ１０３は、その内部に、ＲＤＰ管理サービス３０１と、移行管理サービス３０２と、仮想マシン管理サービス３０３と、ファイル同期サービス３０４と、リソース監視サービス３０５と、ゲストＯＳの管理情報を保存するゲストＯＳ管理テーブル３０６と、管理者が仮想管理サーバ１０３の各種設定を行えるようにＧＵＩ（Graphical User Interface）、ＣＵＩ（Console User Interface）等の管理インターフェース３０７と、を有している。

ＲＤＰ管理サービス３０１は、利用者管理端末１０２から仮想サーバＡ１０４、または、仮想サーバＢ１０８へのＲＤＰのセッションの振り分け機能を有している。ＲＤＰ接続の振り分けに関しては、図５で詳細に述べる。

移行管理サービス３０２は、リソース監視サービス３０５からの移行命令を受け取り、各仮想サーバ上の移行管理モジュール２１０と連携してゲストＯＳの移行を管理する（移行管理モジュール２１０に移行実行を指示する）。

仮想マシン管理サービス３０３は、仮想サーバ２００上のゲストＯＳ２０１の起動、シャットダウン、移行等、ゲストＯＳの管理を、仮想サーバ上の仮想マシン管理モジュール２０９と連携して、ネットワーク越しにリモートで実行することが可能な機能を有する。

ファイル同期サービス３０４は、仮想サーバ２００上のファイル同期モジュール２１３と連携し、ゲストＯＳのシャットダウン後に、ゲストＯＳイメージに更新があった場合に、複数のストレージに保存されているゲストＯＳイメージの同期管理を行う機能を備える。この処理については図８を用いて詳細に説明する。

ゲストＯＳ管理テーブル３０６は、図９で示されるゲストＯＳの管理情報を保存したテーブルである。図９に示されるように、ゲストＯＳ管理テーブル３０６は、構成項目として、ゲストＯＳを利用するユーザのユーザＩＤ９０１と、ゲストＯＳイメージ名９０２と、仮想マシン情報９０３と、仮想サーバＩＰアドレス９０４と、を有している。ユーザＩＤ９０１、ゲストＯＳイメージ名９０２、仮想マシン情報９０３は、管理者があらかじめ仮想管理サーバ１０３のインターフェースを使用して設定する情報である。仮想マシン情報９０３に含まれるＩＰアドレスは、ゲストＯＳが使用するＩＰアドレスを示している。ユーザがゲストＯＳを使用するときには、このＩＰアドレスにアクセスしてゲストＯＳを取得することになる。

仮想サーバＩＰアドレス９０４は、利用者端末装置１０２がゲストＯＳに接続を開始した際に、ゲストＯＳが起動している仮想サーバ（より特定的にはホストＯＳ）のＩＰアドレスが登録される。例えば、仮想サーバＡのＩＰアドレスがxxx.xxx.xx1.001、仮想サーバＢのＩＰアドレスがxxx.xxx.xx1.002であった場合、ユーザＩＤがＡＡＡのユーザが利用者端末装置を起動した際に、仮想サーバＡでゲストＯＳが起動されれば、ユーザＩＤがＡＡＡの仮想サーバＡのＩＰアドレス属性には、xxx.xxx.xx1.001が登録される。仮想サーバＡと仮想サーバＢのどちらでゲストＯＳが起動されるかの振り分け処理については、図５を用いて説明する。

利用者端末装置１０２は、仮想サーバ２００上のゲストＯＳ２０１にＲＤＰ接続してデスクトップ環境を使用できるシンクライアント端末である。利用者端末装置１０２には、あらかじめ、仮想管理サーバ１０３のＩＰアドレスが登録されており、ユーザが利用者端末装置１０２を起動すると、自動的にＲＤＰクライアントが立ち上がり、仮想管理サーバ１０３へ接続を行う。仮想管理サーバ１０３への接続後、ユーザＩＤ、及び、場合によっては、パスワードを入力する画面が表示され、ユーザはそれらの値を設定してＲＤＰ接続を開始する。

＜ゲストＯＳイメージの設定＞
図４は、ゲストＯＳイメージの設定及びセットアップの処理を説明するためのフローチャートである。

まず、管理者が管理者端末装置（図示せず）を用いて、１つの利用者端末装置（１人のユーザ）に割り当てられるゲストＯＳイメージを作成し、仮想管理サーバ１０３にそのゲストＯＳイメージのアップロードを実行する（ステップＳ４０１）と、仮想管理サーバ１０３の仮想マシン管理サービス３０３は当該ゲストＯＳイメージを受信する（ステップＳ４０２）。

次に管理者が仮想管理サーバ１０３のＧＵＩまたはＣＵＩの管理インターフェース３０７を用いて、配置したゲストＯＳイメージと使用するユーザＩＤのセットを仮想管理サーバ１０３のゲストＯＳ管理テーブル３０６へ登録するように指示すると、仮想マシン管理サービス３０３がそれらをゲストＯＳ管理テーブル３０６に登録する（ステップＳ４０３）。

仮想マシン管理サービス３０３による登録が完了すると、仮想管理サーバ１０３のファイル同期サービス３０４が、プライベートサイト１０１の仮想サーバＡ１０４のファイル同期モジュールＡ、及び、パブリックサイト１０７の仮想サーバＢ１０８のファイル同期モジュールＢと連携して、新しく配置されたゲストＯＳイメージをＳＡＮストレージＡ１０５、及び、ＳＡＮストレージＢ１０９に配信する（ステップＳ４０４）。

配信が終了すると、管理者からの、ゲストＯＳの使用するＣＰＵ数・メモリサイズ等の仮想マシン情報９０３、ゲストＯＳイメージ名９０２の仮想マシンの設定情報を受信し、仮想マシン管理サービス３０３は、それらをゲストＯＳ管理テーブル３０６に登録する（ステップＳ４０５）。ここで設定されたファイルは、以後、ゲストＯＳを起動する際に使用される。以上により、各仮想サーバ上のゲストＯＳを起動することが可能となる。

＜ゲストＯＳ選択・起動処理＞
図５は、ユーザが利用者端末装置を起動してゲストＯＳを使用するまでの処理を説明するためのフローチャートである。

ユーザが利用者端末装置１０２の電源を入れると（ステップＳ５０１）、利用者端末装置１０２（ＲＤＰクライアント）からの接続リクエストを、仮想管理サーバ１０３が受信する（ステップＳ５０２）。なお、ここでの利用者端末装置１０２からの接続には、あらかじめ登録されている仮想管理サーバ１０３のＩＰアドレスが使用される。

そして、仮想管理サーバ１０３の仮想マシン管理サービス３０３は、利用者端末装置１０２からのリクエストを受けて、リソース監視サービス３０５への問い合わせを行う（ステップＳ５０３）。

リソース監視サービス３０５は、仮想サーバＡ１０４のリソース監視モジュール２１２と仮想サーバＢの監視モジュール２１２から得られた情報を基に、それぞれの仮想サーバのリソース状態を判定する（ステップＳ５０４）。

仮想サーバＡ１０４のリソースが不足している場合（ステップＳ５０４でＮｏ）、仮想マシン管理サービス３０３は、仮想サーバＢ１０８の仮想マシン管理モジュール２０９に対してゲストＯＳの起動リクエストを送信する（ステップＳ５０５）。なお、リソースが不足しているか否かは、例えば、ＣＰＵの使用量、メモリの使用量やネットワークの状態を示す値が、所定値（閾値）以上となったか否かによって判断される。
その後、仮想サーバＢ１０８の仮想マシン管理モジュール２０９は、起動したゲストＯＳにＲＤＰ接続を行い、利用者端末装置とゲストＯＳの間のＲＤＰ接続を中継する（ステップＳ５０６）。

リソース状態の判定により仮想サーバＡのリソースに余裕があると判定された場合（ステップＳ５０４でＹｅｓ）、仮想マシン管理サービス３０３は、仮想サーバＡ１０４の仮想マシン管理モジュール２０９に対してゲストＯＳの起動リクエストを送信する（ステップＳ５０７）。その後、仮想サーバＡ１０４の仮想マシン管理モジュール２０９は、ゲストＯＳが起動した後、ＲＤＰ接続を行う（ステップＳ５０８）。

続いて、仮想サーバＡ１０４或いはＢ１０８の仮想マシン管理モジュール２０９は、ゲストＯＳ管理テーブルの仮想サーバＩＰアドレスに、ゲストＯＳを起動したサーバのＩＰアドレスを登録する（Ｓ５０９）。以上により、ユーザが利用者端末装置を起動し、デスクトップ環境を使用できるようになる。また、図５からも分かるように、仮想サーバＢにゲストＯＳを移行したとしても、一旦利用者端末装置がシャットダウンされると、次回のアクセス時には仮想サーバＡのゲストＯＳを使用できるか判断し、仮想サーバＡのリソースに余裕が無いときに仮想サーバＢのゲストＯＳを使うように制御される。

なお、ここでは、仮想サーバが２つ（仮想サーバＡ及びＢ）の場合について説明したが、仮想サーバの数は任意に設定することが可能である。この場合、プライベートサイト（企業内サイト等）にある仮想サーバ（仮想サーバＡがそれに該当）群内でリソースに余裕がある仮想サーバがあればそれが選択され、その選択された仮想サーバ内のゲストＯＳが起動される。一方、プライベートサイト内の仮想サーバ群にリソースの余裕が無い場合になって初めてパブリックサイト（有料サイト）にある仮想サーバ（仮想サーバＢがそれに該当）群内の１つの仮想サーバが選択され、その中のゲストＯＳが起動される。パブリックサイトの仮想サーバは、例えば、リソースに一番余裕があるもの、一番コストが安いもの等が選択されるようにすれば良い。

＜ゲストＯＳ内の書き込み制御モジュールの処理＞
図６は、ゲストＯＳに含まれる書込み制御モジュールの処理動作を説明するためのフローチャートである。

ゲストＯＳ上のアプリケーション、または、ゲストＯＳによるゲストＯＳイメージへのアクセス（Ｉ／Ｏ要求）を検知すると（ステップＳ６０１）、書込み制御モジュール２１４は、その要求が書込みに関連する要求か否かを判定する（ステップＳ６０２）。

書込み関連処理の場合（ステップＳ６０２でＹｅｓ）、書込み制御モジュール２１４は、書込みデータをメモリ上に確保した領域にキャッシュし（ステップＳ６０５）、処理を終了する（ステップＳ６０８）。なお、書込み制御が施されていないＯＳでは、この書込み要求は、ゲストＯＳイメージに書き込まれる。

書込み関連処理以外の場合（ステップＳ６０２でＮｏ）、書込み制御モジュール２１４は、ゲストＯＳイメージからデータを読み込み（ステップＳ６０３）、メモリ中にデータがキャッシュされているか否かを判定し（ステップＳ６０４）、キャッシュが存在しない場合、読み込んだデータをそのままアプリケーションに返す（ステップＳ６０６）。キャッシュデータが存在する場合（ステップＳ６０４でＹｅｓ）、書込み制御モジュール２１４は、キャッシュを読み込みデータに上書きしてアプリケーションに返す（ステップＳ６０７）。

以上により、ゲストＯＳイメージへの書込みが無くなるため、ゲストＯＳイメージはRead Only状態となる。

＜ゲストＯＳ移行処理＞
図７は、ゲストＯＳの移行処理を説明するためのフローチャートである。移行が発生する例として、仮想サーバＡと仮想サーバＢで複数台のゲストＯＳが起動し、複数台の利用者端末装置から両仮想サーバにＲＤＰ接続がなされ、かつ、仮想サーバＡの物理リソースが上限に達している状況を経由し、その後、いくつかの仮想サーバＡ上のゲストＯＳがシャットダウンされ、仮想サーバＡのリソースに余裕が出た場合を想定する。

仮想サーバＡのリソース監視モジュール２１２が仮想サーバＡのリソースに余裕が出たことを検知すると、それを仮想管理サーバ１０３に報告する（ステップＳ７０１）。

仮想管理サーバ１０３のリソース監視サービス３０５が、リソース監視モジュール２１２による定期的な、仮想サーバＡのリソース状況報告から、仮想サーバＡのリソースに余裕があることを検知する（ステップＳ７０２）。

そして、仮想管理サーバ１０３の移行管理サービス３０２は、仮想サーバＢの移行管理モジュール２１０に対し、ゲストＯＳを仮想サーバＡへ移行するようにリクエストを出す（ステップＳ７０３）。

仮想サーバＢの移行管理サービス３０２は、仮想サーバＡの移行管理モジュール２１０と連携して、ゲストＯＳを仮想サーバＡへ移行する（ステップＳ７０４）。つまり、仮想サーバＢ上のゲストＯＳのＣＰＵレジスタのデータ及びメモリデータ等から転送・コピーすることでゲストＯＳが移行される。

そして、仮想サーバＡの移行管理モジュール２１０は、移行が完了したことを、仮想管理サーバ１０３の移行管理サービス３０２に通知する（ステップＳ７０５）。

通知を受けた移行管理サービス３０２は、ＲＤＰ管理モジュール３０１にＲＤＰセッションを仮想サーバＡ上のゲストＯＳに変更する（ステップＳ７０６）。

以上により、ゲストＯＳの移行が完了し、ゲストＯＳが仮想サーバＡ上で動作することとなる。

なお、本発明の実施形態においては、利用者端末装置１０２にはシンクライアント端末を使用しているが、仮想化機構と二次記憶装置を備えるＦａｔクライアントを使用した場合は、そのＦａｔクライアントが仮想サーバＡの代わりを果たすことも可能である。つまり、二次記憶装置を備える利用者端末装置を使用している場合に、その利用者端末装置にゲストＯＳイメージを配置しておけば、仮想サーバ上のゲストＯＳを利用者端末装置へ移行することも可能である。

＜シャットダウン時の処理＞
図８は、ユーザが利用者端末装置をシャットダウンした場合の処理を説明するためのフローチャートである。

ユーザがゲストＯＳ上でシャットダウンを選択すると、そのシャットダウン指示を仮想マシン管理サービス３０３が受領する（ステップＳ８０１）。そして、仮想マシン管理サービス３０３は、ＲＤＰ管理サービス３０１と連携して、書込みデータをゲストＯＳイメージに適用するか、または、起動前の状態に戻すかの選択ウィンドを利用者端末装置１０２の表示画面に表示する（ステップＳ８０２）。

ユーザによる選択を受け付けると（ステップＳ８０３）、仮想マシン管理サービス３０３は、ＲＤＰ管理サービス３０１に命令してＲＤＰ接続を切断する（ステップＳ８０４）。

利用者端末装置１０２がシャットダウンされる（ステップＳ８０５）と、この時点で利用者端末装置１０２のシャットダウンは完了するが、仮想管理サーバ１０３は、仮想サーバ上のゲストＯＳのシャットダウン処理を継続する。これは、この時点ではまだ、ゲストＯＳが仮想サーバＡ、または、仮想サーバＢで動作している状態だからである。

選択画面でユーザがキャッシュデータをゲストＯＳイメージに適用することを選択していたことを認識すると（ステップＳ８０６でＹｅｓ）、仮想マシン管理サービス３０３は、ゲストＯＳ管理テーブル３０６の仮想サーバＩＰアドレス９０４を取得し、ゲストＯＳが動作している仮想サーバを特定する（ステップＳ８０７）。取得した結果から、対象のサーバが例えば仮想サーバＡだった場合は、仮想マシン管理サービス３０３は、仮想サーバＡの仮想マシン管理モジュール２０９に、ゲストＯＳイメージへのキャッシュデータの書込み命令を送る（ステップＳ８０８）。一方、仮想サーバＢだった場合は、仮想マシン管理サービス３０３は、仮想サーバＢの仮想マシン管理モジュール２０９に、ゲストＯＳイメージへのキャッシュデータの書込み命令を送る（ステップＳ８０８）。

仮想マシン管理モジュール２０９は、ゲストＯＳ上の書込み制御モジュール２１４に命令し、書込み制御モジュール２１４がゲストＯＳイメージへの書込みを行う（ステップＳ８０９）。ゲストＯＳイメージへの書込みが完了した時点で、ゲストＯＳはシャットダウンされる（ステップＳ８１０）。

その後、仮想マシン管理モジュール２０９は、ファイル同期サービス３０４に、ゲストＯＳイメージへの書込みを行ったことを通知し、キャッシュされている書き込みデータを送信する（ステップＳ８１１）。この時点では、当該ゲストＯＳイメージと他の仮想サーバが保持しているゲストＯＳイメージとの間に差異が発生した状態となっている。

今まで動作していた仮想サーバのファイル同期サービス３０４は、他の各仮想サーバ上のファイル同期モジュール２１３に、ゲストＯＳイメージが各仮想サーバで最新かつ、同一のゲストＯＳイメージになるように命令する（ステップＳ８１２）。

各仮想サーバ上のファイル同期モジュール２１３は、ゲストＯＳイメージの同期を取る、つまり、変更されたゲストＯＳイメージと同一の内容にする（ステップＳ８１３）。

ファイル同期が完了した時点で、仮想マシン管理サービス３０３は、ゲストＯＳ管理テーブル３０６の仮想サーバＩＰアドレス９０４をクリアする（Ｓ８１５）。

一方、起動前の状態に戻す方をユーザが選択した場合、或いは、ゲストＯＳイメージへの書き込みがなされていない場合（ステップＳ８０６でＮｏ）、ＲＤＰ管理サービス３０１は、利用者端末装置１０２を即時シャットダウンする（ステップＳ８１４）。ゲストＯＳイメージへの書込みはメモリにキャッシュされている場合には、キャッシュされたデータはシャットダウンとともに消去される。また、ゲストＯＳイメージの更新はなされないため、ファイル同期も行われない。

シャットダウンが完了された時点で、仮想マシン管理サービス３０３は、ゲストＯＳ管理テーブル３０６の仮想サーバＩＰアドレス９０４をクリアする（Ｓ８１５）。

なお、ステップＳ８０６では、ユーザがキャッシュデータをゲストＯＳイメージに適用することを選択した場合に、ゲストＯＳイメージを変更するようにしたが、ゲストＯＳへの変更がキャッシュされていた（主記憶装置に格納されていた）場合には、利用者端末装置のシャットダウン時に自動的にゲストＯＳイメージへの書き込みを実行しても良い。

＜まとめ＞
本発明では、移行元と移行先の２つの物理サーバ（仮想サーバＡ及びＢ）がそれぞれ参照しているストレージに、同じゲストＯＳのイメージをあらかじめ配置しておく。この状態であれば、移行時に移行元の各ゲストＯＳが使用しているメモリ・ＣＰＵレジスタデータを移行先の仮想サーバへコピーすることで、移行を実施することが可能である。これにより、共有ディスク設定をすることなく、複数の物理サーバ上のゲストＯＳを起動状態のまま移行させることが可能となる。この機能を使えば、例えば、企業内のサイト(プライベートサイト)の物理リソースが不足した際に、他の企業が運営するサイト(パブリックサイト)へゲストＯＳを起動状態で移行することが可能である。また、他の企業が運営するサイト(パブリックサイト)が有料である場合、パブリックサイトで動作するゲストＯＳを起動状態のまま、企業内のサイト(プライベートサイト)へ移行が可能となり、コストを削減することができる。

また、移行元の仮想サーバのリソースを監視し、リソースが不足した場合に、ゲストＯＳの移行処理を実行する。この機能により、例えば、ある企業内のデータセンター（プライベートサイト）で多数の仮想デスクトップを運用している際に、そのデータセンターのリソースが不足した時、臨時的に、他の企業が運営する社外のデータセンター（パブリックサイト）にゲストＯＳを移行させることが考えられる。また、この場合、企業内のリソースに余裕ができた場合は、企業外のデータセンターで動作するゲストＯＳを企業内のデータセンターに、起動状態のまま引き戻すことが可能であり、例えば、有料の社外データセンターを利用している場合には、無駄に社外データセンターを利用することが無くなり、コスト削減となる。

さらに、ゲストＯＳを動作させている仮想サーバ（仮想サーバＡ或いはＢ）のゲストＯＳ上において、ゲストＯＳが管理するボリュームへの書込みをメモリ上にリダイレクトしてキャッシュし、ボリュームへの書込みを禁止し、ゲストＯＳのイメージデータへの書込み・更新を抑制する。これにより、ゲストＯＳイメージの更新書込みが発生しない状態を作っている。よって、ホストＯＳから見た場合、物理サーバ（仮想サーバＡ或いはＢ）上で動作するゲストＯＳイメージはRead Only状態となっており、２つのサーバが、各々のサーバのローカルストレージのみを参照している状態において、あらかじめ各々のローカルストレージに同じゲストＯＳイメージを配置しておけば、各仮想マシン（利用者端末装置）は同じゲストＯＳイメージを常に参照することになる。

１０１…プライベートサイト
１０２…利用者端末装置
１０３…仮想管理サーバ
１０４…仮想サーバＡ
１０５…ＳＡＮストレージＡ
１０６…ゲストＯＳイメージＡ
１０７…パブリックサイト
１０８…仮想サーバＢ
１０９…ＳＡＮストレージＢ
１１０…ゲストＯＳイメージＢ
１１１…ＷＡＮ

Claims (7)

1. 利用者端末が、仮想マシン上で動作するオペレーティングシステムであるゲストＯＳを動作できるようにするサーバ装置であって、
   前記ゲストＯＳを管理するオペレーティングシステムであるホストＯＳと、
   前記ホストＯＳを動作させるプロセッサと、
   主記憶デバイスと、を有し、
   前記プロセッサは、
   前記ホストＯＳを動作させ、前記ゲストＯＳに対応するゲストＯＳイメージを取得して前記ゲストＯＳを起動させて、前記利用者端末に提供し、
   前記ゲストＯＳの移行指示に応答して、前記ゲストＯＳが使用するリソースデータを、前記ゲストＯＳと同一のＯＳである移行先ゲストＯＳを有し、対応するゲストＯＳイメージを有する他のサーバ装置に送信して、前記ゲストＯＳを自装置で起動させたまま、当該他のサーバ装置で前記移行先ゲストＯＳを起動可能とし、
   前記ゲストＯＳは、前記ゲストＯＳイメージに対する書き込みをリダイレクトして、当該書き込みによる変更データを前記主記憶デバイスに格納し、前記ゲストＯＳを提供している利用者端末が動作している間は前記ゲストＯＳイメージに対する変更を禁止し、
   前記プロセッサは、前記ゲストＯＳイメージに対する変更適用の指示、或いは、前記利用者端末のシャットダウンに応答して、前記ゲストＯＳイメージに対する書き込みによる変更データを前記ゲストＯＳイメージに反映させると共に、前記他のサーバ装置におけるゲストＯＳが有するゲストＯＳイメージを書き換えるように、前記ゲストＯＳイメージの変更情報を提供することを特徴とするサーバ装置。
2. 請求項１において、
   前記プロセッサは、前記自装置におけるリソースの状態を監視し、当該監視の結果に基づいて、前記ゲストＯＳの移行処理を実行するか否か判断することを特徴とするサーバ装置。
3. 利用者端末が、仮想マシン上で動作するオペレーティングシステムであるゲストＯＳを動作できるようにするサーバ装置であって、
   前記ゲストＯＳを管理するオペレーティングシステムであるホストＯＳと、
   前記ホストＯＳを動作させるプロセッサと、
   主記憶デバイスと、を有し、
   前記プロセッサは、
   前記ホストＯＳを動作させ、前記ゲストＯＳに対応するゲストＯＳイメージを取得して前記ゲストＯＳを起動させて、前記利用者端末に提供し、
   前記ゲストＯＳの移行指示に応答して、前記ゲストＯＳが使用するリソースデータを、前記ゲストＯＳと同一のＯＳである移行先ゲストＯＳを有し、対応するゲストＯＳイメージを有する他のサーバ装置に送信して、前記ゲストＯＳを自装置で起動させたまま、当該他のサーバ装置で前記移行先ゲストＯＳを起動可能とし、
   前記自装置のリソースの状態を監視し、当該監視の結果に基づいて、前記移行先ゲストＯＳを稼動させる前記他のサーバ装置に対して、前記移行先ゲストＯＳが使用するリソースデータの転送をリクエストし、前記他のサーバ装置から取得したリソースデータを、前記自装置の前記ゲストＯＳに反映させて、再度自装置のゲストＯＳを起動させることを特徴とするサーバ装置。
4. 利用者端末とローカルネットワークで接続された第１のサーバ装置と、当該第１のサーバ装置と広域ネットワークで接続された第２のサーバ装置と、を有し、前記利用者端末が仮想マシン上で動作するオペレーティングシステムであるゲストＯＳを動作できるようにする情報処理システムであって、前記第１及び第２のサーバ装置がそれぞれ、前記ゲストＯＳ及びそれに対応するゲストＯＳイメージを有する情報処理システムの制御方法であって、
   前記第１のサーバ装置が、前記ゲストＯＳに対応するゲストＯＳイメージを取得して前記ゲストＯＳを起動させて、前記利用者端末に提供し、
   前記第１のサーバ装置が、前記ゲストＯＳを起動させたまま、前記ゲストＯＳの移行指示に応答して、前記ゲストＯＳが使用するリソースデータを、前記広域ネットワークを介して前記第２のサーバ装置に送信し、
   前記第２のサーバ装置が、前記送信されてきたリソースデータを用いて、第２のサーバ装置が有する前記ゲストＯＳを起動させ、
   前記第１のサーバ装置が、前記ゲストＯＳが前記第２のサーバ装置で起動した後、前記第１のサーバ装置で動作する前記ゲストＯＳをシャットダウンし、
   前記第１又は第２のサーバ装置において動作する前記ゲストＯＳは、前記ゲストＯＳイメージに対する書き込みをリダイレクトして、当該書き込みによる変更データを主記憶デバイスに格納し、前記ゲストＯＳを提供している利用者端末が動作している間は前記ゲストＯＳイメージに対する変更を禁止し、
   前記ゲストＯＳが動作する前記第１又は第２のサーバ装置は、前記ゲストＯＳイメージに対する変更適用の指示、或いは、前記利用者端末のシャットダウンに応答して、前記ゲストＯＳイメージに対する書き込みによる変更データを前記ゲストＯＳイメージに反映させ、
   前記ゲストＯＳイメージを変更した前記第１又は第２のサーバ装置は、変更前のゲストＯＳイメージを有するサーバ装置に対して、前記ゲストＯＳに対応するゲストＯＳイメージを書き換える指示及び変更内容を送信し、
   前記指示を受け取ったサーバ装置が、前記変更内容に従って、前記ゲストＯＳイメージを変更することを特徴とする制御方法。
5. 請求項４において、
   さらに、前記第１のサーバ装置が、前記第１のサーバ装置におけるリソースの状態を監視し、当該監視の結果に基づいて、前記ゲストＯＳの移行処理を実行するか否か判断することを特徴とする制御方法。
6. 利用者端末とローカルネットワークで接続された第１のサーバ装置と、当該第１のサーバ装置と広域ネットワークで接続された第２のサーバ装置と、を有し、前記利用者端末が仮想マシン上で動作するオペレーティングシステムであるゲストＯＳを動作できるようにする情報処理システムであって、前記第１及び第２のサーバ装置がそれぞれ、前記ゲストＯＳ及びそれに対応するゲストＯＳイメージを有する情報処理システムの制御方法であって、
   前記第１のサーバ装置が、前記ゲストＯＳに対応するゲストＯＳイメージを取得して前記ゲストＯＳを起動させて、前記利用者端末に提供し、
   前記第１のサーバ装置が、前記ゲストＯＳを起動させたまま、前記ゲストＯＳの移行指示に応答して、前記ゲストＯＳが使用するリソースデータを、前記広域ネットワークを介して前記第２のサーバ装置に送信し、
   前記第２のサーバ装置が、前記送信されてきたリソースデータを用いて、第２のサーバ装置が有する前記ゲストＯＳを起動させ、
   前記第１のサーバ装置が、前記ゲストＯＳが前記第２のサーバ装置で起動した後、前記第１のサーバ装置で動作する前記ゲストＯＳをシャットダウンし、
   前記第１のサーバ装置が、前記第１のサーバ装置におけるリソースの状態を監視し、当該監視の結果に基づいて、前記第２のサーバ装置に対して、前記第２のサーバ装置の前記ゲストＯＳが使用するリソースデータの転送をリクエストし、
   前記第２のサーバ装置が、前記リクエストに応答して、前記リソースデータを前記第１のサーバ装置に転送し、
   前記第１のサーバ装置が、前記第１のサーバ装置の前記ゲストＯＳに前記リソースデータを反映させて、再度ゲストＯＳを起動させることを特徴とする制御方法。
7. コンピュータを請求項１又は３に記載のサーバ装置として機能させることを特徴とするプログラム。

Images