JP5692829B1 - 仮想ディスクイメージを処理するシステム、クライアント端末、及び方法 - Google Patents
仮想ディスクイメージを処理するシステム、クライアント端末、及び方法 Download PDFInfo
- Publication number
- JP5692829B1 JP5692829B1 JP2013540170A JP2013540170A JP5692829B1 JP 5692829 B1 JP5692829 B1 JP 5692829B1 JP 2013540170 A JP2013540170 A JP 2013540170A JP 2013540170 A JP2013540170 A JP 2013540170A JP 5692829 B1 JP5692829 B1 JP 5692829B1
- Authority
- JP
- Japan
- Prior art keywords
- block
- generation
- disk file
- client terminal
- metafile
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
実施形態によれば、コンピュータシステムは、配信サーバとクライアント端末とを具備する。配信サーバは、管理情報を含む少なくとも2つのメタファイルを生成して、これらのメタファイルをクライアント端末に配信する。管理情報は、仮想ディスクイメージを格納した仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも1つの差分ディスクファイルから抽出される。クライアント端末は、配信されたメタファイルに基づいて有効なブロックを検出し、検出された有効なブロックの配信を配信サーバに要求する。クライアント端末は、配信された有効なブロックのデータを仮想ディスクイメージに組み合わせる。
Description
本発明の実施形態は、コンピュータシステム、同システムにおけるクライアント端末、及び同システムにおいて仮想ディスクイメージを処理する方法に関する。
従来から、サーバとクライアント端末とを備えたコンピュータシステムが知られている。このサーバとして、ディスクイメージを例えば複数のクライアント端末にネットワークを介して配信する配信サーバが知られている。ディスクイメージは、仮想マシンが参照できる仮想ディスクに配置されるのが一般的である。そこで以下の説明では、ディスクイメージを仮想ディスクイメージと称する。
仮想ディスクイメージは、オペレーティングシステム及び各種アプリケーションプログラムを含む。このような仮想ディスクイメージが配信サーバにより複数のクライアント端末に配信されることにより、当該複数のクライアント端末で実行されるオペレーティングシステム及び各種アプリケーションプログラムを統一することができる。
仮想ディスクイメージを格納したファイルは、仮想ディスクファイルと呼ばれる。クライアント端末において、この仮想ディスクファイルが配信サーバにより配信された場合、当該仮想ディスクファイルをハイパーバイザが仮想ディスクとして認識できる。以下の説明では、仮想ディスクに格納される仮想ディスクイメージ(仮想ディスクファイル)を、第1の仮想ディスクイメージ(第1の仮想ディスクファイル)と呼ぶ。
しかし、第1の仮想ディスクイメージ(第1の仮想ディスクファイル)は更新される。このため、第1の仮想ディスクイメージ(第1の仮想ディスクファイル)は、以下に述べるように、マスタディスクイメージ(マスタディスクファイル)と、少なくとも1つの差分ディスクイメージ(差分ディスクファイル)とを用いて構成されるのが一般的である。マスタディスクイメージは、最初に生成された第1世代の仮想ディスクイメージ(第2の仮想ディスクイメージ)であり、仮想ディスクのベースとして用いられる。差分ディスクイメージは、第1世代より新しい世代の仮想ディスクイメージ(第3の仮想ディスクイメージ)であり、オペレーティングシステムの更新やアプリケーションプログラムの変更(追加を含む)などにより生ずる差分(つまり変更部分)を表す。
仮想ディスクは、マスタディスクイメージ(第2の仮想ディスクイメージ)と少なくとも1つの差分ディスクイメージ(第3の仮想ディスクイメージ)とを1つに組み合わせる(マージする)ことにより構成される。そこで配信サーバは、これらのディスクイメージを全てネットワーク経由でクライアント端末に配信する。この配信方法を第1の配信方法と称する。クライアント端末は、配信された全てのディスクイメージを第1の仮想ディスクイメージに組み合わせることにより、仮想ディスクを構築する。クライアント端末は、この仮想ディスクに基づいて仮想マシンまたはオペレーティングシステム及びアプリケーションプログラムを起動する。
また、クライアント端末の負荷を軽減するための第2の配信方法も知られている。この第2の配信方法では、配信サーバが仮想ディスクを構成して、当該仮想ディスク全体のイメージ(第1の仮想ディスクイメージ)をクライアント端末に配信する。つまり、配信サーバはディスクイメージを個別に配信する代わりに、仮想ディスク全体のイメージをクライアント端末に配信する。
第1の配信方法を適用する従来技術において、クライアント端末が初めて配信サーバから配信を受ける場合を想定する。この場合、配信サーバは、マスタディスクイメージ及び全ての差分ディスクイメージをネットワーク経由で当該クライアント端末に転送する必要がある。このイメージ転送に要する時間は、差分ディスクイメージの数(世代数)が多いほど増加し、ネットワークの負荷も増大する。
また、クライアント端末は、全ての差分ディスクイメージを格納しなければならない。このためクライアント端末では、仮想ディスクイメージのために必要なディスク容量が増大する。また、このディスク容量を減らすため、配信サーバまたはクライアント端末が差分ディスクイメージ間でデータを結合することも考えられる。しかし、ディスクイメージの結合には時間がかかり、配信サーバまたはクライアント端末において負荷の増大を招く。
またクライアント端末は、例えばデータ参照のために仮想ディスクにアクセスする際、最新世代の差分ディスクイメージの管理情報にアクセスすることにより、参照されるべきデータが存在するかを判定する。もし、参照されるべきデータが存在しないならば、クライアント端末は、先行する世代の差分ディスクイメージの管理情報にアクセスする。このため、差分ディスクイメージの数(世代数)が増えるほど、仮想ディスクアクセス性能が低下する。
一方、第2の配信方法を適用する従来技術では、配信サーバは、仮想ディスク全体のイメージ、つまり、仮想ディスク全体のサイズ(論理サイズ)に相当する大きさの仮想ディスクイメージを送付する。この場合、配信サーバは、仮想ディスクにおける空き領域や削除(無効化)領域、更にはパーティションで構成されていない領域も含めて、イメージを転送しなければならない。このため第2の配信方法では、イメージの転送時間が一層増加する。ここで、仮想ディスクの論理サイズが127ギガバイト(GB)であり、実際には数GB程度しか当該仮想ディスクを使用していない場合を想定する。このような場合でも、配信サーバは、仮想ディスクの論理サイズである127GBの大きさの仮想ディスクイメージを転送しなければならない。このため、クライアント端末のディスク容量が不足するケースも発生し得る。
本発明が解決しようとする課題は、仮想ディスクを構成するマスタディスクイメージ、及び少なくとも1つの差分ディスクイメージを全て配信サーバからクライアント端末に配信することなく、当該クライアント端末において仮想ディスクを利用することができる、コンピュータシステム、クライアント端末及び仮想ディスクイメージを処理する方法を提供することにある。
実施形態によれば、コンピュータシステムは、クライアント端末と配信サーバとを具備する。前記クライアント端末は、第1のオペレーティングシステムに基づいて第1のマシンとして動作する。前記配信サーバは、前記クライアント端末とネットワークを介して接続される。前記配信サーバは、前記クライアント端末に仮想ディスクとして認識させるための第1の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも1つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信する。前記第1の仮想ディスクファイルは、第1の仮想ディスクイメージを格納する。前記第1の仮想ディスクイメージは、前記クライアント端末が第2のマシンとして動作するための第2のオペレーティングシステムを含む。前記マスタディスクファイルは、第1世代の仮想ディスクイメージを第2の仮想ディスクイメージとして格納する。前記第1世代の仮想ディスクイメージは、第1のサイズを有するN個のブロックから構成される。前記少なくとも1つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる差分ディスクイメージを、前記第1世代より新しい世代の第3の仮想ディスクイメージとして格納する。前記差分ディスクイメージは、前記第1のサイズを有するN個のブロックから構成される。前記マスタディスクファイル及び前記少なくとも1つの差分ディスクファイルの各々は管理情報を有する。前記管理情報は、対応するディスクファイルに含まれるN個のブロックの各々が有効であるかを少なくとも示す。前記配信サーバは、メタファイル生成部と配信部とを具備する。前記メタファイル生成部は、第1世代の第1のメタファイルと、前記第1世代より新しい世代の少なくとも1つの第2のメタファイルとを生成する。前記第1のメタファイルは、前記マスタディスクファイルから抽出される前記管理情報を含む。前記少なくとも1つの第2のメタファイルは、前記少なくとも1つの差分ディスクファイルから抽出される前記管理情報を含む。前記配信部は、前記第1のメタファイル及び前記少なくとも1つの第2のメタファイルを前記クライアント端末に配信し、前記クライアント端末によって要求された複数のブロックのデータを前記クライアント端末に配信する。前記クライアント端末の前記第1のマシンは、解析部と要求部とマージ部とを具備する。前記解析部は、前記第1のメタファイルに含まれている前記管理情報及び前記少なくとも1つの第2のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出する。前記要求部は、前記検出された複数の有効なブロックの配信を前記配信サーバに要求する。前記マージ部は、前記配信サーバの前記配信部によって配信された複数の有効なブロックのデータを前記第1の仮想ディスクイメージに組み合わせる。
以下、種々の実施の形態につき図面を参照して説明する。
図1は、実施形態に係るコンピュータシステムの典型的な構成を示すブロック図である。このコンピュータシステムは、配信サーバ1と、クライアント端末2及び3とを備えている。配信サーバ1とクライアント端末2及び3とはネットワーク4によって接続されている。なお、ネットワーク4に3台以上のクライアント端末が接続されていても構わない。
図1は、実施形態に係るコンピュータシステムの典型的な構成を示すブロック図である。このコンピュータシステムは、配信サーバ1と、クライアント端末2及び3とを備えている。配信サーバ1とクライアント端末2及び3とはネットワーク4によって接続されている。なお、ネットワーク4に3台以上のクライアント端末が接続されていても構わない。
配信サーバ1は、システムプール5を備えている。システムプール5は、例えば、複数の物理ディスクの記憶領域をまとめて構築される1つの大容量の仮想的(論理的)なディスクである。システムプール5の仮想ディスク50には、複数、例えば3つの仮想ディスクファイル51,52及び53が格納されている。
仮想ディスクファイル51,52及び53は、クライアント端末2及び3を含む複数のクライアント端末で用いられる仮想ディスク50を構成するのに必要な仮想ディスクイメージを格納したファイルである。配信サーバ1は、これらの仮想ディスクイメージを設定し、且つ管理する管理サーバとしての機能と、これらの仮想ディスクイメージを各クライアント端末にネットワーク4を介して配信する配信サーバとしての機能とを有する。
仮想ディスクファイル51は、最初に生成された第1世代の仮想ディスクイメージを格納したファイルであり、仮想ディスクのベースとして用いられる。そこで以下の説明では、仮想ディスクファイル51をマスタディスクファイル51と称する。仮想ディスクイメージは、第2のオペレーティングシステム及び各種アプリケーションプログラム(より詳細には、仮想ディスク50にインストールされた第2のオペレーティングシステム及び各種アプリケーションプログラムのイメージ)を含む。本実施形態において、第2のオペレーティングシステムは、ゲストオペレーティングシステム(以下、ゲストOSと称する)である。また本実施形態では、仮想ディスクイメージはセキュリティポリシーを含む。
仮想ディスクファイル52は、第2世代の仮想ディスクイメージを格納したファイルである。第2世代の仮想ディスクイメージは、マスタディスクファイル51の生成後(より詳細には、サーバ管理者からの最初の差分生成指示後)において実行された、ゲストOSの更新やアプリケーションプログラム(以下、APPと称する)の変更(追加を含む)などにより生ずる差分(つまり変更部分)を表す。そこで以下の説明では、仮想ディスクファイル52を差分ディスクファイル52(または差分#1)と称する。
仮想ディスクファイル53は、第3世代の仮想ディスクイメージを格納したファイルである。第3世代の仮想ディスクイメージは、差分ディスクファイル52の生成後(より詳細には、サーバ管理者からの2回目の差分生成指示後)において実行された、ゲストOSの更新やAPPの変更などにより生ずる差分を表す。そこで以下の説明では、仮想ディスクファイル53を差分ディスクファイル53(または差分#2)と称する。
マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル52の各々は、当該ファイルに格納されている仮想ディスクイメージの構成を示す管理情報(ディスク管理情報)を含む。これらのディスクファイル51乃至53のデータ形式については後述する。
クライアント端末2は、例えばパーソナルコンピュータ(PC)である。クライアント端末2は、PCを実現するためのハードウェア(HW)21を備えている。HW21は、CPU211、メモリ212、ハードディスクドライブ(HDD)213及びネットワークコントローラ(NC)214を含む。図2では省略されているが、HDD213には、後述する仮想化ソフトウェアプログラム及び第1のオペレーティングシステム(以下、制御OSと称する)26が格納されている。図2では、HW21が一般的に有する表示装置のような入出力装置も省略されている。なお、HDD213に代えて、ソリッドステートドライブ(SSD)のような外部記憶装置を用いても構わない。またHW21が、HDD213に加えてSSDを含んでいても構わない。
クライアント端末2は、当該クライアント端末2内で唯一完全な権限を有するハイパーバイザ22を備えている。ハイパーバイザ22は、クライアント端末2が起動されることにより、HW21上で動作する。ハイパーバイザ22は、CPU211が仮想化ソフトウェアプログラムをHDD213からメモリ212に読み込んで実行することにより実現される。
ハイパーバイザ22は、例えばクライアント端末2の起動時に、HW21を用いて制御用の仮想マシン23が動作する環境を提供することができる。つまりハイパーバイザ22は、当該ハイパーバイザ22上で動作する制御用の仮想マシン23を構築することができる。ハイパーバイザ22は、CPU211及びメモリ212のような物理リソースの使用量、及び当該物理リソースの仮想マシン23及び24への割り当てを管理する。
仮想マシン23は、制御ドメインと呼ばれる制御用の仮想マシン(第1のマシン)である。そこで以下の説明では、仮想マシン23を制御仮想マシン23と称する。制御仮想マシン23は、HDD213に格納されている制御OS26に基づいて動作して、他の仮想マシン、例えば仮想マシン24を構築し、且つ制御する。
仮想マシン24は、制御仮想マシン23の制御の下で、ゲストOS27に基づいて動作して、各種APP(アプリケーションプログラム)28を実行する仮想マシン(第2のマシン)である。そこで以下の説明では、仮想マシン24をゲスト仮想マシン24と称する。ゲストOS27及びAPP28は、ディスク領域25に格納される仮想ディスクイメージに含まれている。ディスク領域25は、ハイパーバイザ22による物理リソースの割り当てに基づいて、HDD213の一部の領域を用いて実現される。ゲスト仮想マシン24は、ディスク領域25に仮想ディスクイメージが格納された後に、制御仮想マシン23によって構築される。
本実施形態では、ハイパーバイザ22の負荷を軽減するために、制御仮想マシン23がゲスト仮想マシン24を構築する機能を有している。しかし、ハイパーバイザ22がゲスト仮想マシン24を構築しても構わない。逆に、ハイパーバイザ22の負荷を一層軽減するために、制御仮想マシン23が物理リソースの割り当てを管理しても良い。
図2は、図1に示される配信サーバ1及びクライアント端末2の典型的な機能構成を主として示すブロック図である。配信サーバ1は、仮想ディスクイメージ(VDI)生成・更新部11と、メタファイル生成部12と、配信部13とを備えている。
VDI生成・更新部11は、配信サーバ1が有する管理機能の1つである。VDI生成・更新部11は、マスタディスクファイル(MDF)生成部111と、差分ディスクファイル(DDF)生成部112とを備えている。MDF生成部111は、サーバ管理者の操作に基づいて、マスタディスクファイル51、つまり第1世代の仮想ディスクイメージが格納されたマスタディスクファイル51を生成する。
DDF生成部112は、マスタディスクファイル51の生成後におけるサーバ管理者からの最初の差分生成指示に応じて、差分ディスクファイル52(差分#1)の生成を開始する。これによりDDF生成部112は、差分ディスクファイル52、つまり第2世代の仮想ディスクイメージが格納された差分ディスクファイル52を生成する。
DDF生成部112はまた、マスタディスクファイル51の生成後におけるサーバ管理者からの2回目の差分生成指示に応じて、差分ディスクファイル52(差分#1)の生成から差分ディスクファイル53(差分#2)の生成に切り替える。これによりDDF生成部112は、差分ディスクファイル53、つまり第3世代の仮想ディスクイメージが格納された差分ディスクファイル53を生成する。
メタファイル生成部12は、配信サーバ1が有する配信機能の1つである。メタファイル生成部12は、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53に含まれている管理情報を抽出する。これによりメタファイル生成部12は、ディスクファイル51,52及び53から抽出された管理情報を含むメタファイル121,122及び123を生成する。メタファイル121,122及び123は、それぞれディスクファイル51,52及び53(より詳細には、ディスクファイル51,52及び53に格納されている仮想ディスクイメージ)に対応する。つまりメタファイル121,122及び123の世代は、それぞれ第1世代、第2世代及び第3世代である。
配信部13は、配信サーバ1が有する配信機能の他の1つである。配信部13は、クライアント端末2から配信開始が要求された場合、メタファイル121乃至123をネットワーク4経由でクライアント端末2に配信(転送)する。配信部13はまた、クライアント端末2から要求された仮想ディスクイメージのブロックのデータを、ネットワーク4経由でクライアント端末2に配信する。本実施形態において、仮想ディスクイメージの各ブロック(データブロック)は複数のセクタ(データセクタ)を含む。各セクタのサイズは、例えば512バイトである。
なお、配信サーバ1が有する管理機能を独立の管理サーバによって実現しても良い。この場合、配信サーバ1が、管理サーバとしての管理機能を必ずしも有している必要はない。つまり、配信サーバ1に代えて、VDI生成・更新部11を有する管理サーバと、メタファイル生成部12及び配信部13を有する配信サーバとを用いても良い。
一方、クライアント端末2(より詳細には、クライアント端末2の制御仮想マシン23)は、受信部231と、解析部232と、要求部233と、保存部234と、マージ部235とを備えている。本実施形態において、これらの機能要素231乃至235は、制御仮想マシン23(より詳細には、制御仮想マシン23に割り当てられたCPU211)が制御OS26の下で動作することにより実現されるソフトウェアモジュールである。
受信部231は、配信サーバ1の配信部13によって配信されるデータ(つまりメタファイル121乃至123、及びブロックデータ)を受信する。解析部232は、受信された全てのメタファイルを、最新の世代のメタファイルから順(つまり、世代の逆順)に解析することにより、仮想ディスクイメージ内の受信不要なセクタを検出する。受信不要なセクタについては後述する。解析部232は、無効化部232aを含む。無効化部232aは、受信不要なセクタを無効化する。なお、無効化部232aが解析部232から独立して備えられていても構わない。
要求部233は、受信不要なセクタが無効化部232aによって無効化された後、世代の逆順(つまり、世代番号の降順)に、且つ有効なセクタを少なくとも1つ含むブロックを単位に、当該ブロックのデータの配信を配信サーバ1に要求する。保存部234は、受信ブロックのデータをディスク領域25に保存する。
マージ部235は、受信ブロックのデータをマージすることにより、ディスク領域25内に仮想ディスク50を構築(復元)する。マージ部235は、置換部235aを含む。置換部235aは、無効セクタを含むブロック(第4のブロック)内の有効なセクタ(第4のセクタ)のデータで、ディスク領域25に保存されているブロック(第3のブロック)内のセクタ(第3のセクタ)を置き換える(書き換える)。この置き換えにより、第3のブロックのデータと第4のブロックのデータとがマージされる。ここで、第3のブロック及び第4のブロックの仮想アドレスは同一であり、第3のセクタの第3のブロック内の相対位置は、第4のブロック内の第4のセクタの相対位置に一致する。第3のセクタ及び第4のセクタの仮想アドレスは同一である。
図3は、仮想ディスク50の構成の例を示す。図3の例では、仮想ディスク50は、マスタディスクファイル51、差分ディスクファイル52(差分#1)、及び差分ディスクファイル53(差分#2)の3つの仮想ディスクファイルを格納する。この仮想ディスク50は、マージ部235がマスタディスクファイル51、差分ディスクファイル52(差分#1)、及び差分ディスクファイル53(差分#2)をマージすることにより実現される1つの仮想ディスクファイルを格納した仮想ディスクと等価である。
図3において、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53の配置位置は、双方向の矢印300で示されるように世代を表す。マスタディスクファイル51は最も古い世代(第1の世代)の仮想ディスクファイルであり、差分ディスクファイル53は最も新しい世代(第3の世代)の仮想ディスクファイルである。
図3の例では、差分ディスクファイル53は更新中の状態にある。マスタディスクファイル51が生成された時点では、仮想ディスク50は当該マスタディスクファイル51のみを格納する。また、差分ディスクファイル52が生成された時点では、仮想ディスク50はマスタディスクファイル51及び差分ディスクファイル52を格納する。つまり仮想ディスク50は、1つ以上の仮想ディスクファイルを格納する。
各仮想ディスクファイルは、ヘッダ(H)と、ブロックアロケーションテーブル(TBL)と、N個のブロックBLK_0乃至BLK_N−1と、フッタ(F)とから構成される。但し、N個のブロックBLK_0乃至BLK_N−1の全てが有効であるとは限らない。つまり各仮想ディスクファイルは、有効なブロックを最大N個格納することができる。Nの値は、ブロック(BLK)の長さと、仮想ディスク50の論理サイズとに基づいて決定される。有効なブロックは、有効なデータ(セクタデータ)を含む。図3には、有効なブロックのみが示されている。図3において矢印300に直交する方向は、仮想ディスク50の仮想アドレス空間(オフセット)を示す。仮想アドレスは、ヘッダ(H)に近づくほど小さくなり、フッタ(F)に近づくほど大きくなるものとする。
本実施形態において、ヘッダ(H)及びフッタ(F)は同一の情報を有する。ヘッダ(H)及びフッタ(F)は、当該ヘッダ(H)及びフッタ(F)を有する仮想ディスクファイル(以下、対応仮想ディスクファイルと称する)の識別子(ID)、対応する仮想ディスク(ここでは仮想ディスク50)の名称、及び親ディスクのパスを示す。親ディスクのパスは、対応仮想ディスクファイルよりも1世代前の仮想ディスクファイルの物理位置を示す。ヘッダ(H)及びフッタ(F)はまた、対応仮想ディスクファイルのファイル名、仮想ディスク50のサイズ(つまり論理サイズ)及び各ブロック(BLK)の長さを示す。ヘッダ(H)及びフッタ(F)は更に、対応仮想ディスクファイル内のブロック(BLK)の数を示す。なお、ヘッダ(H)及びフッタ(F)のいずれか一方が、上述の情報を有していても構わない。
ブロックアロケーションテーブル(TBL)は、対応仮想ディスクファイルに格納されるN個のブロックBLK_0乃至BLK_N−1の識別子(BLKID)0乃至N−1に対応付けられたN個のエントリTBLE_0乃至TBLE_N−1を有している。エントリTBLE_i(i=0,1,…,N−1)の情報は、フラグ情報と位置情報とを含む。フラグ情報は、エントリTBLE_iと対応付けられたブロック識別子(BLKID)を持つ有効なブロックBLK_iが対応仮想ディスクファイルに存在するか否かを示す。位置情報は、有効なブロックBLK_iが対応仮想ディスクファイルに存在する場合に、当該ブロックBLK_iの仮想ディスク50内の位置(つまり仮想アドレス)を示す。
図3の例では、マスタディスクファイル51は、有効なブロックBLK_0,BLK_1,BLK_2,BLK_3及びBLK_N−1を含む。各ブロック(BLK)は、マップテーブル(MAP)と、データ部(DATA)とから構成される。データ部(DATA)は、複数のセクタから構成される。この複数のセクタは、有効セクタと無効セクタとに分類される。有効セクタは有効なデータを有するセクタを指し、無効セクタは有効なデータを有さないセクタ(例えば、無効データを有するセクタ)を指す。また、データを有さないセクタ(つまり、空のセクタ)も無効セクタである。本実施形態において、ブロックの長さ(第1のサイズ)は2メガバイト(MB)であり、セクタの長さ(第2のサイズ)は512バイト(B)である。
マップテーブル(MAP)は、ブロック内の複数のセクタがそれぞれ有効であるか(つまり、有効なデータを有しているか)を示す。ここで、ブロック内のセクタの数がmであるものとする。本実施形態において、マップテーブル(MAP)は、ブロック(BLK)内のm個のセクタと対応付けられたm個のビットの列から構成されるビットマップ(ビットマップテーブル)である。このmは、マップテーブル(MAP)のビット列の長さ(つまりマップビット長)をも表す。マップテーブル(MAP)の各ビットは、例えば1の場合、対応するセクタのデータが存在する(有効である)ことを表し、0の場合、対応するセクタのデータが存在しないこと、または無効であることを表す。
差分ディスクファイル52及び53も、上述のマスタディスクファイル51と同様のデータ形式を有する。以下の説明では、ブロックBLK_i内のマップテーブル及びデータ部を、それぞれMAP_i及びDATA_iと表記する。
差分ディスクファイル52は、有効なブロックBLK_1,BLK_2及びBLK_3を含む。つまり、マスタディスクファイル51及び差分ディスクファイル52は、仮想ディスク50内の位置が同一のブロックBLK_1,BLK_2及びBLK_3を含む。このことは、サーバ管理者からの最初の差分生成指示後(マスタディスクファイル51の生成後)において、新たなブロックBLK_1,BLK_2及びBLK_3をライトする操作(ライト操作)が発生したこと、つまり、マスタディスクファイル51のブロックBLK_1,BLK_2及びBLK_3が更新(変更)されたことを表す。但し、本実施形態では、マスタディスクファイル51のブロックBLK_1,BLK_2及びBLK_3は直接更新されない。
このようにDDF生成部112は、マスタディスクファイル51のブロックBLK_1,BLK_2及びBLK_3を今回の更新が発生する前の状態に維持しながら、更新されたブロックのみを差分(差分データブロック)として含む差分ディスクファイル52(つまり、別のディスクファイル)を生成する。より詳細に述べるならば、DDF生成部112は、更新されたブロックBLK_1,BLK_2及びBLK_3のみを差分ブロックとして差分ディスクファイル52に追加する。したがって、マスタディスクファイル51のブロックBLK_1,BLK_2及びBLK_3(前者)と差分ディスクファイル52のブロックBLK_1,BLK_2及びBLK_3(後者)とは一般に異なる。つまり、後者は、最初の差分生成指示後において実行されたライト操作により生ずる差分(差分ブロック)である。なお、本実施形態では、後者は、形式的には前者が更新されたブロックであるが、前者とは無関係に新たに生成される。
ここで、サーバ管理者から2回目の差分生成が指示されたものとする。この場合、DDF生成部112は、ヘッダ(H)、ブロックアロケーションテーブル(TBL)及びフッタ(F)から構成される差分ディスクファイル53を生成する。その後、ブロックBLK_2にデータをライトするためのライト操作が実行されたものとする。このとき、最新のブロックBLK_2は、差分ディスクファイル52に存在する。この場合、DDF生成部112は、差分ディスクファイル52のブロックBLK_2を今回のライト操作(更新)が発生する前の状態に維持しながら、データがライトされた新たな(更新された)ブロックBLK_2を差分として差分ディスクファイル53に追加する。
続いて、ブロックBLK_0及びBLK_1からデータをリードするためのリード操作が順次実行されたものとする。図3の例では、ブロックBLK_0は、マスタディスクファイル51のみに存在する。この場合、矢印a1で示されるように、マスタディスクファイル51のブロックBLK_0からデータがリードされる。一方、ブロックBLK_1は、マスタディスクファイル51及び差分ディスクファイル52にそれぞれ存在する。この場合、矢印a2で示されるように、差分ディスクファイル52のブロックBLK_1(つまり、最新のブロックBLK_1)からデータがリードされる。
次に、ブロックBLK_2にデータをライトするためのライト操作が再び実行されたものとする。このとき、最新のブロックBLK_2は、差分ディスクファイル53に存在する。この場合、DDF生成部112は、図3において矢印a3で示されるように、差分ディスクファイル52のブロックBLK_2に更新データをライトする。図3は、このときの状態を示している。
その後、ブロックBLK_3にデータをライトするためのライト操作が実行されるものとする。このとき、最新のブロックBLK_3は、差分ディスクファイル52に存在する。この場合、DDF生成部112は、差分ディスクファイル52のブロックBLK_3を今回のライト操作が発生する前の状態に維持しながら、データがライトされた新たな(更新された)ブロックBLK_3を、図3において矢印a4で示すように、差分として差分ディスクファイル53に追加する。
次に、本実施形態におけるメタファイル生成部12による典型的なメタファイル生成について、図4を参照して説明する。今、図3において矢印a4で示されるライト操作が実行されたことにより、仮想ディスクファイルの生成・更新が終了したものとする。するとメタファイル生成部12は、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53に格納されている管理情報に基づいて、当該マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53にそれぞれ格納されている仮想ディスクイメージのメタファイル121,122及び123を生成する。これにより配信部13は、配信レディ状態となる。
以下、差分ディスクファイル53に基づくメタファイル123の生成について説明する。差分ディスクファイル53は、ヘッダ(H)と、ブロックアロケーションテーブル(TBL)と、有効なブロックBLK_2及びBLK_3とを含む。ブロックBLK_2はマップテーブルMAP_2及びデータ部DATA_2を含み、ブロックBLK_3はマップテーブルMAP_3及びデータ部DATA_3を含む。
メタファイル生成部12は、差分ディスクファイル53から、ヘッダ(H)と、ブロックアロケーションテーブル(TBL)と、ブロックBLK_2及びBLK_3内のマップテーブルMAP_2及びMAP_3とを取り出す。メタファイル生成部12は、取り出されたヘッダ(H)と、ブロックアロケーションテーブル(TBL)と、マップテーブルMAP_2及びMAP_3とを、差分ディスクファイル53(仮想ディスクファイル)の構成を表す管理情報として、図4に示されるように、1つのメタファイル123にまとめる。つまり差分ディスクファイル53は、ヘッダ(H)、ブロックアロケーションテーブル(TBL)、マップテーブルMAP_2及びMAP_3を、管理情報(第2の管理情報)として有する。メタファイル123の末尾には、ヘッダ(H)と同一内容のフッタ(F)が付加される。なお、差分ディスクファイル53内のフッタ(F)が用いられても構わない。
本実施形態において、差分ディスクファイル53は第3世代の仮想ディスクファイルである。そこでメタファイル生成部12は、メタファイル123に、当該メタファイル123の世代(より詳細には、当該メタファイル123の世代に対応する差分ディスクファイル53の世代)を表すファイル名、例えば0003.MTAを付与する。ファイル名0003.MTAにおける数値0003が、世代(世代番号)を表す。
同様にしてメタファイル生成部12は、マスタディスクファイル51が有する管理情報(第1の管理情報)を抽出することにより、当該管理情報(第1の管理情報)を含む、ファイル名が0001.MTAのメタファイル121を生成する。またメタファイル生成部12は、差分ディスクファイル52が有する管理情報(第2の管理情報)を抽出することにより、当該管理情報(第2の管理情報)を含む、ファイル名が0002.MTAのメタファイル122を生成する。以下の説明では、メタファイル121,122及び123を、それぞれメタファイル0001.MTA,0002.MTA及び0003.MTAと称することもある。
次に、クライアント端末2の起動時の動作について、図5乃至図8を参照して説明する。図5はクライアント端末2の起動時の典型的な動作手順を説明するためのフローチャートの一部を示す図であり、図6は同フローチャートの他の一部を示す図である。図7は同フローチャートの更に他の一部を示す図であり、図8は同フローチャートの残りを示す図である。
クライアント端末2が起動されると、ハイパーバイザ22が動作する。するとハイパーバイザ22は制御仮想マシン23を起動する。これにより制御仮想マシン23は、制御OS26に基づいて動作を開始する。
すると制御仮想マシン23の要求部233は、配信サーバ1に仮想ディスクイメージの配信開始をネットワーク4経由で要求する(ステップS1)。この要求を受けて、配信サーバ1の配信部13は、メタファイル生成部12によって生成されたメタファイル121(0001.MTA)乃至123(0003.MTA)を、ネットワーク4経由でクライアント端末2に配信(転送)する。
制御仮想マシン23の受信部231は、配信部13から配信されたメタファイル121(0001.MTA)乃至123(0003.MTA)を受信する(ステップS2)。受信されたメタファイル121(0001.MTA)乃至123(0003.MTA)は、制御仮想マシン23に割り当てられたメタファイル保存用の記憶領域に格納される。この記憶領域には、HDD213の一部の領域が用いられる。
制御仮想マシン23の解析部232は、受信されたメタファイル121(0001.MTA)乃至123(0003.MTA)を世代の逆順(世代番号の降順)にソートする(ステップS3)。これによりメタファイル121(0001.MTA)乃至123(0003.MTA)は、メタファイル123(0003.MTA)、メタファイル122(0002.MTA)、及びメタファイル121(0001.MTA)の順にソートされる(図9参照)。
次に解析部232は、処理(解析)されるべきメタファイルの世代(世代番号)を表す変数Mに、ソート(受信)されたメタファイルの総数(ここでは3)を代入する(ステップS4)。この時点における変数M=3は、最新のメタファイル0003.MTAの世代M(第M世代)に一致する。
次に解析部232は、メタファイルM.MTA(ここではメタファイル0003.MTA)をオープンする(ステップS5)。すると解析部232は、メタファイルM.MTAからブロックアロケーションテーブルTBLを取り出す(ステップS6)。次に解析部232は、ブロック識別子BLKIDとして0を設定する(ステップS7)。
次に解析部232は、ブロックアロケーションテーブルTBLのエントリTBLE_BLKID(ここではエントリTBLE_0)を参照する(ステップS8)。エントリTBLE_BLKIDは、ブロック識別子BLKIDに対応付けられている。解析部232は、参照されたエントリTBLE_BLKIDに含まれているフラグ情報に基づいて、ブロック識別子BLKIDを持つブロックBLK_BLKID(ここではブロックBLK_0)が有効であるかを判定する(ステップS9)。
もし、ブロックBLK_BLKIDが有効であるならば(ステップS9のYes)、解析部232は、メタファイルM.MTAからブロックBLK_BLKIDのマップテーブルMAP_BLKID(ここではマップテーブルMAP_0)を取り出す(ステップS10)。次に解析部232は、マップテーブル(ビットマップテーブル)MAP_BLKIDを構成するビット列の長さ(つまりマップビット長)mを、パラメータMBLとして設定する(ステップS11)。
本実施形態では、マップテーブルMAP_BLKIDのビット列のi番目(i=1,2,…)の位置をi−1と表記し、且つ、当該i番目のビット(つまりビット位置がi−1のビット)をビットBT(i−1)と表記する。そこで解析部232は、マップテーブルMAP_BLKIDのビットの位置を表す変数CurBitに先頭ビット位置を表す0を代入する(ステップS12)。
次に解析部232は、マップテーブルMAP_BLKID(つまり、ブロックBLK_BLKIDのマップテーブルMAP_BLKID)のビットBT(CurBit)を参照する(ステップS13)。ビットBT(CurBit)は、マップテーブルMAP_BLKIDのビット列に含まれていて、且つ変数CurBit(ここではCurBit=0)によって指定される位置に存在するビットである。
次に解析部232は、参照されたビットBT(CurBit)が1であるかを判定する(ステップS14)。もし、ビットBT(CurBit)が1であるならば(ステップS14のYes)、解析部232は、ビットBT(CurBit)に対応付けられているブロックBLK_BLKID(第1のブロック)内のセクタ(第1のセクタ)が有効であると判定する。
すると、無効化部232aが起動される。無効化部232aは、変数Mの示す世代(つまり第M世代)よりも古い世代のメタファイルが存在するならば、当該古い世代のメタファイルからブロックBLK_BLKIDのマップテーブルMAP_BLKIDを取り出す(ステップS15)。ここで、変数Mは3であり、したがって第M世代(第3世代)よりも古い世代のメタファイルは、メタファイルM−1.MTA(つまり、メタファイル0002.MTA)及びメタファイルM−2.MTA(つまり、メタファイル0001.MTA)である。この場合、メタファイル0002.MTA及び0001.MTAから、それぞれブロックBLK_BLKIDのマップテーブルMAP_BLKID(ここではブロックBLK_0のマップテーブルMAP_0)が取り出される。
次に無効化部232aは、第M世代よりも古い世代のメタファイルから取り出されたマップテーブルMAP_BLKIDのビットBT(CurBit)を0にセットする(ステップS16)。ここで、第M世代よりも古い世代のメタファイルにマップテーブルMAP_BLKIDが含まれていない場合、無効化部232aは、当該マップテーブルMAP_BLKIDの全ビットが0であると見なしてステップS16を実行する。なお、第M世代よりも古い世代の全てのメタファイルにマップテーブルMAP_BLKIDが含まれていない場合、無効化部232aがステップS16をスキップしても良い。
上述したように本実施形態では、第M世代のメタファイルM.MTAから取り出されたブロックBLK_BLKID(第1のブロック)のマップテーブルMAP_BLKID(第1のマップ情報)のビットBT(CurBit)が1の場合(ステップS14のYes)、無効化部232aは、第M世代よりも古い世代のマップテーブルMAP_BLKIDの相対位置が同一のビットBT(CurBit)を0にセットする(ステップS16)。即ち無効化部232aは、第M世代よりも古い世代のマップテーブルMAP_BLKID(第2のマップ情報)のビットBT(CurBit)に対応付けられた、ブロックBLK_BLKID(第2のブロック)内のセクタ(第2のセクタ)を、受信不要なセクタとして無効化する。そこで、受信不要なセクタを無効化するためのステップS16の処理を、無効化処理と呼ぶ。
無効化部232aがステップS16(つまり無効化処理)を実行すると、解析部232は変数CurBitを1インクリメントする(ステップS17)。また解析部232は、ステップS13で参照されたビットBT(CurBit)が1でない場合にも(ステップS14のNo)、変数CurBitを1インクリメントする(ステップS17)。
解析部232は、インクリメントされた変数CurBitが、パラメータMBL(つまり、マップテーブルMAP_BLKIDのマップビット長)に等しいかを判定する(ステップS18)。もし、等しくないならば(ステップS18のNo)、解析部232はステップS13に戻る。ステップS13において解析部232は、インクリメントされた変数CurBitに基づいて、マップテーブルMAP_BLKIDのビットBT(CurBit)を参照する。このようにして、ステップS13乃至S18を含む処理が、インクリメントされた変数CurBitがパラメータMBLに等しくなるまで繰り返される。
やがて、インクリメントされた変数CurBitがパラメータMBLに等しくなったものとする(ステップS18のYes)。この場合、解析部232は、ブロックBLK_BLKIDのマップテーブルMAP_BLKIDの全ビットについて処理を完了したと判定する。すると解析部232は、ブロック識別子BLKIDを1インクリメントする(ステップS19)。また、ブロックBLK_BLKIDが有効でない場合にも(ステップS9のNo)、解析部232はブロック識別子BLKIDを1インクリメントする(ステップS19)。そして解析部232は、インクリメントされたブロック識別子BLKID(ここでは1)が最大(ここではブロック数の最大値N)であるかを判定する(ステップS20)。
もし、インクリメントされたブロック識別子BLKIDが最大(N)でないならば(ステップS20のNo)、解析部232はステップS8に戻る。ステップS8において解析部232は、インクリメントされたブロック識別子BLKIDに基づいて、ブロックアロケーションテーブルTBL(メタファイルM.MTAから取り出されたブロックアロケーションテーブルTBL)のエントリTBLE_BLKID(ここではエントリTBLE_1)を参照する。このようにして、ステップS8乃至S20を含む処理が、インクリメントされたブロック識別子BLKIDが最大(N)となるまで繰り返される。
やがて、インクリメントされたブロック識別子BLKIDが最大(N)となったものとする(ステップS20のYes)。この場合、解析部232は、メタファイルM.MTAから取り出されたブロックアロケーションテーブルTBLで管理される全てのブロック識別子BLKID(ブロックBLK_BLKID)について処理を完了したと判定する。すると解析部232は、変数Mを1ディクリメントする(ステップS21)。そして解析部232は、ディクリメントされた変数M(ここでは2)が0であるかを判定する(ステップS22)。
もし、ディクリメントされた変数Mが0でないならば(ステップS22のNo)、解析部232はステップS5に戻る。ステップS5において解析部232は、ディクリメントされた変数Mで示される世代(つまり、1つ前の世代)のメタファイルM.MTA(ここではメタファイル002.MTA)をオープンする。このようにして、ステップS5乃至S22を含む処理が、ディクリメントされた変数Mが0となるまで繰り返される。
やがて、ディクリメントされた変数Mが0となったものとする(ステップS22のYes)。この場合、解析部232は、配信サーバ1によりクライアント端末2に配信させるべき有効なブロックBLK_BLKIDを検出(特定)するために、以下の処理を行う。
まず解析部232は、前述のステップS3乃至S12に相当するステップS23乃至S32を次のように実行する。解析部232は、無効化部232aによる無効化処理が行われたメタファイル121(0001.MTA)乃至123(0003.MTA)を世代の逆順にソートする(ステップS23)。次に解析部232は、変数Mに、ソートされたメタファイルの総数(ここでは3)を代入する(ステップS24)。
次に解析部232は、メタファイルM.MTAをオープンし(ステップS25)、当該メタファイルM.MTAからブロックアロケーションテーブルTBLを取り出す(ステップS26)。次に解析部232は、ブロック識別子BLKIDとして0を設定する(ステップS27)。
次に解析部232は、ブロック識別子BLKIDに基づいて、ブロックアロケーションテーブルTBLのエントリTBLE_BLKID(ここではエントリTBLE_0)を参照する(ステップS28)。解析部232は、参照されたエントリTBLE_BLKIDに含まれているフラグ情報に基づいて、ブロックBLK_BLKIDが有効であるかを判定する(ステップS29)。
もし、ブロックBLK_BLKIDが有効であるならば(ステップS29のYes)、解析部232は、メタファイルM.MTAからブロックBLK_BLKIDのマップテーブルMAP_BLKIDを取り出す(ステップS30)。次に解析部232は、マップテーブルMAP_BLKIDを構成するビット列の長さ(マップビット長)を、パラメータMBLとして設定する(ステップS31)。また解析部232は、変数CurBitに0を代入する(ステップS32)。
次に解析部232は、メタファイルM.MTAから取り出されたブロックBLK_BLKIDのマップテーブルMAP_BLKIDを参照して、当該マップテーブルMAP_BLKIDの全てのビットが0であるかを判定する(ステップS33)。もし、ブロックBLK_BLKIDのマップテーブルMAP_BLKIDの少なくとも1ビットが0でないならば(ステップS33のNo)、解析部232は、ブロックBLK_BLKIDは有効であると判定する。この場合、解析部232は要求部233を起動する。
すると要求部233は、配信サーバ1に、メタファイルM.MTAに対応する第M世代の仮想ディスクファイル(ここでは差分ディスクファイル53)に格納されているブロックBLK_BLKIDの配信を要求する(ステップS34)。この要求を受けて、配信サーバ1の配信部13は、第M世代の仮想ディスクファイル(差分ディスクファイル53)内のブロックBLK_BLKIDのデータを、ネットワーク4経由で制御仮想マシン23の受信部231に配信(転送)する。
このように本実施形態では、ブロックBLK_BLKIDのマップテーブルMAP_BLKIDの少なくとも1ビットが0でない場合(ステップS33のNo)、要求部233は、当該ブロックBLK_BLKID全体の配信を配信サーバ1に要求する。これにより、配信サーバ1の配信部13からクライアント端末2に、有効なブロックBLK_BLKIDのデータがブロック単位に配信される。このため本実施形態によれば、配信サーバ1の配信効率及びクライアント端末2の受信効率を向上できる。なお、要求部233が、マップテーブルMAP_BLKIDのビット列に基づいて、値が1のビットに対応付けられたセクタ(つまり有効なセクタ)のデータのみの配信を要求しても良い。この場合、配信サーバ1の配信部13からクライアント端末2に、有効なセクタのデータのみが配信(転送)されるため、ブロック全体の配信と比較して、データ転送量を削減できる。
制御仮想マシン23の受信部231は、配信部13から配信された第M世代の仮想ディスクファイル(差分ディスクファイル53)内のブロックBLK_BLKIDのデータを受信する(ステップS35)。すると制御仮想マシン23の保存部234は、第M世代よりも新しい世代のブロックBLK_BLKIDのデータが既にディスク領域25に保存されているかを判定する(ステップS36)。ここでは、変数Mは3であるため、第M世代よりも新しい世代は存在しない。したがって、ブロックBLK_BLKIDのデータはディスク領域25に保存されていない(ステップS36のNo)。この場合、保存部234は、受信されたブロックBLK_BLKIDのデータをディスク領域25に保存する(ステップS37)。
保存部234は、ディスクドライバを含んでおり、ステップS37を実行する際には、受信されたブロックBLK_BLKIDの仮想アドレスと物理アドレスとのマッピングを行う。保存部234は、マッピングされたディスク領域25の物理アドレスに、受信されたブロックBLK_BLKIDを保存する。ここで、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53が、後述するようにディスク領域25内で1つの仮想ディスクファイルに組み合わされた(マージされた)ものとする。このような状態では、例えばゲスト仮想マシン24のディスクドライバは、マッピングの情報に基づき、ディスク領域25を仮想ディスクイメージが格納された仮想ディスクとして利用することができる。
さて、受信されたブロックBLK_BLKIDのデータがディスク領域25に保存されると(ステップS37)、解析部232は、ブロック識別子BLKIDを1インクリメントする(ステップS45)。また、ブロックBLK_BLKIDが有効でない場合にも(ステップS29のNo)、解析部232はブロック識別子BLKIDを1インクリメントする(ステップS45)。また、ブロックBLK_BLKIDのマップテーブルMAP_BLKIDの全てのビットが0である場合にも(ステップS33のYes)、解析部232はブロック識別子BLKIDを1インクリメントする(ステップS45)。
このように本実施形態では、ブロックBLK_BLKIDが有効でない場合(ステップS29のNo)、或いはブロックBLK_BLKID(第2のブロック)のマップテーブルMAP_BLKID(第2のマップ情報)の全てのビットが0である場合(ステップS33のYes)、当該ブロックBLK_BLKIDの配信が要求されない。つまり、ステップS34が実行されない。したがって本実施形態によれば、無効なブロックBLK_BLKIDが配信サーバ1からクライアント端末2に配信(転送)される無駄を防止できる。無効なブロックBLK_BLKIDは、無効セクタのみを有するブロックBLK_BLKIDを含み、無効セクタは、ステップS16で無効化されたセクタを含む。
解析部232は、ブロック識別子BLKIDを1インクリメントすると、当該インクリメントされたブロック識別子BLKIDが最大(N)であるかを判定する(ステップS46)。もし、インクリメントされたブロック識別子BLKIDが最大(N)でないならば(ステップS46のNo)、解析部232はステップS28に戻る。ステップS28において解析部232は、メタファイルM.MTAから取り出されたブロックアロケーションテーブルTBLのエントリTBLE_BLKID(ここではエントリTBLE_1)を参照する。このようにして、ステップS28乃至S37,S45及びS46を含む処理が、インクリメントされたブロック識別子BLKIDが最大(N)となるまで繰り返される。
やがて、インクリメントされたブロック識別子BLKIDが最大(N)となったものとする(ステップS46のYes)。この場合、解析部232は、メタファイルM.MTAから取り出されたブロックアロケーションテーブルTBLで管理される全てのブロックBLK_BLKIDについて処理を完了したと判定する。すると解析部232は、変数Mを1ディクリメントする(ステップS47)。そして解析部232は、ディクリメントされた変数M(ここでは2)が0であるかを判定する(ステップS48)。
もし、ディクリメントされた変数Mが0でないならば(ステップS48のNo)、解析部232はステップS25に戻る。ステップS25において解析部232は、ディクリメントされた変数Mで示される世代のメタファイルM.MTA(ここではメタファイル002.MTA)をオープンする。
そして、後続のステップS26乃至S35が実行された結果、受信部231が、第M世代(ここでは第2世代)の仮想ディスクファイル(つまり差分ディスクファイル52)のブロックBLK_BLKIDを受信したものとする。このとき、第M世代(第2世代)よりも新しい世代(第3世代)のブロックBLK_BLKIDのデータが既にディスク領域25に保存されているものとする(ステップS36のYes)。このような場合、現在オープンされている第M世代のメタファイルM.MTAのマップテーブルMAP_BLKID(つまり、受信ブロックBLK_BLKIDのマップテーブルMAP_BLKID)は、無効化処理済みの状態にある。
解析部232は、第M世代(第2世代)のメタファイルM.MTAに含まれている無効化処理済みのマップテーブルMAP_BLKID(第4のマップ情報)のビットBT(CurBit)を参照する(ステップS38)。次に解析部232は、参照されたビットBT(CurBit)が1であるかを判定する(ステップS39)。もし、ビットBT(CurBit)が1であるならば(ステップS39のYes)、解析部232は、ビットBT(CurBit)に対応付けられている受信ブロックBLK_BLKID内のセクタが有効であると判定する。
すると制御仮想マシン23のマージ部235は、受信ブロックBLK_BLKID(第4のブロック)から、ビットBT(CurBit)に対応付けられているセクタ(第4のセクタ)のデータを取り出す(ステップS40)。マージ部235の置換部235aは、ディスク領域25に保存されているブロックBLK_BLKID(第3のブロック)に含まれ、且つビットBT(CurBit)に対応付けられているセクタ(第3のセクタ)のデータを、取り出されたデータで書き換える(つまり置き換える)(ステップS41)。また置換部235aは、ディスク領域25に保存されているブロックBLK_BLKID(第3のブロック)に含まれているマップテーブルMAP_BLKID(第3のマップ情報)のビットBT(CurBit)を1にセットする(ステップS42)。上述の置換部235aの処理を置換処理と称する。
置換部235aが置換処理(ステップS41及びS42)を実行すると、解析部232は変数CurBitを1インクリメントする(ステップS43)。また解析部232は、ステップS38で参照されたビットBT(CurBit)が1でない場合にも(ステップS39のNo)、変数CurBitを1インクリメントする(ステップS43)。
解析部232は、インクリメントされた変数CurBitが、パラメータMBL(つまり、マップテーブルMAP_BLKIDマップビット長)に等しいかを判定する(ステップS44)。もし、等しくないならば(ステップS44のNo)、解析部232はステップS38に戻る。ステップS38において解析部232は、インクリメントされた変数CurBitに基づいて、第M世代のメタファイルM.MTAに含まれている無効化処理済みのマップテーブルMAP_BLKIDのビットBT(CurBit)を参照する。このようにして、ステップS38乃至S44を含む処理が、インクリメントされた変数CurBitがパラメータMBLに等しくなるまで繰り返される。
やがて、インクリメントされた変数CurBitがパラメータMBLに等しくなったものとする(ステップS44のYes)。この場合、解析部232は、ブロックBLK_BLKIDのマップテーブルMAP_BLKIDの全ビットについて処理を完了したと判定する。すると解析部232は、ステップS29の判定がNoの場合、またはステップS33の判定がYesの場合、またはステップS37が実行された場合と同様に、ブロック識別子BLKIDを1インクリメントする(ステップS45)。
さて、ステップS25乃至S48を含む処理が、ステップS47でディクリメントされた変数Mが0となるまで繰り返され、やがて、当該ディクリメントされた変数Mが0となったものとする(ステップS48のYes)。この場合、図5乃至図8のフローチャートに従う、クライアント端末2の起動時の処理は終了する。以上の処理により、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53が、ディスク領域25内で1つの仮想ディスクファイルにマージされる。
さて、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53が、ディスク領域25内で1つの仮想ディスクファイルにマージされると、制御仮想マシン23はゲスト仮想マシン24を構築(生成)する。ゲスト仮想マシン24はディスクドライバを有している。制御仮想マシン23は、このディスクドライバを介して、ディスク領域25を仮想ディスクイメージが格納された仮想ディスクとして認識する。これによりゲスト仮想マシン24は、仮想ディスクに格納されている仮想ディスクイメージに含まれているゲストOSをゲストOS27として実行する。つまりゲスト仮想マシン24は、ゲストOS27に基づいて動作する。またゲスト仮想マシン24は、仮想ディスクに格納されている仮想ディスクイメージに含まれている各種APPを、ゲストOS27に基づいて、APP28として実行する。このとき制御仮想マシン23は、制御OS26に基づいて動作している。つまり制御仮想マシン23及びゲスト仮想マシン24は並行して動作する。
なお上述の動作の後に、配信サーバ1のDDF生成部112が、差分ディスクファイル53(#差分2)の次の世代の差分ディスクファイル(#差分2)を生成したものとする。この場合、配信サーバ1のメタファイル生成部12は、当該差分ディスクファイル(#差分2)に基づいて第4世代のメタファイル0004.MTAを生成する。この状態で、クライアント端末2が再度起動されて、クライアント端末2の要求部233から配信サーバ1に仮想ディスクイメージの配信開始が要求されたものとする。この場合、配信サーバ1の配信部13は、第4世代のメタファイル0004.MTAのみを配信すれば良い。
次に、上述した配信サーバ1の起動時の処理の具体例について図9及び図10を参照して説明する。図9は、受信不要なセクタの無効化を説明するための図であり、図10はセクタデータの置き換えを説明するための図である。
まず、受信不要なセクタの無効化(つまり無効化処理)について、図9を参照して説明する。図9は、クライアント端末2の受信部231で受信されたメタファイル0001.MTA(121),0002.MTA(122)及び0003.MTA(123)の一部を示す。より詳細に述べるならば、図9は、メタファイル0001.MTA,0002.MTA及び0003.MTAがいずれも有するマップテーブルMAP_2及びMAP_3を示す。ここでは、メタファイル0001.MTA,0002.MTA及び0003.MTAが、世代順(世代番号の降順)に配置されている。図9の例では、最新世代(第3世代)のメタファイル0003.MTAが最上段に、最も古い世代(第1世代)のメタファイル0001.MTAが最下段に配置されている。
メタファイル0001.MTA,0002.MTA及び0003.MTAのマップテーブルMAP_2及びMAP_3は、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53のブロックBLK_2及びBLK_3に含まれている。ブロックの長さが4MB、セクタの長さが512Bである本実施形態では、ブロック内のセクタの数mは8,000を超える。このため、マップテーブルのビットの数mも8,000を超える。しかし図9の例は、説明の簡略化のために、マップテーブルMAP_2及びMAP_3のビットの数mが8である場合、つまりブロックBLK_2及びBLK_3内のセクタの数が8である場合を想定している。
解析部232は、メタファイル0001.MTA,0002.MTA及び0003.MTAのマップテーブルを、ブロック識別子BLKID毎に照合する。即ち解析部232は、メタファイル0001.MTA,0002.MTA及び0003.MTAのマップテーブルMAP_BLKID(BLKID=0,1,…)を照合する。この照合は、ビット単位で行われる。そのため解析部232は、メタファイル0001.MTA,0002.MTA及び0003.MTAのマップテーブルMAP_BLKIDをビット単位で走査する。
今、解析部232が、メタファイル0001.MTA,0002.MTA及び0003.MTAのマップテーブルMAP_2(つまり、ブロック識別子BLKIDが0002のブロックBLK_2のマップテーブルMAP_2)の相対位置が同一のビット、例えば図9に示される矩形枠91内のビットを照合するものとする。矩形枠91に含まれている、最新(第3世代)のメタファイル0003.MTAのマップテーブルMAP_2のビットは、当該マップテーブルMAP_2の先頭ビットBIT(0)であり、1である(ステップS14のYes)。この場合、無効化部232aは、メタファイル0003.MTAの世代(第3世代)よりも古い世代のメタファイル0002.MTA及び0001.MTAの矩形枠91内のビットBIT(0)を0にセットする(ステップS16)。なお、メタファイル0002.MTA及び0001.MTAの矩形枠91内のビットBIT(0)は、ステップS16の実行前に0にセットされている。この場合、必ずしもステップS16が実行される必要はない。
解析部232は、照合されるべきビットBT(CurBit)の位置を、図9において矢印92で示される各マップテーブルのビット列の方向に1ビットずつずらしながら(ステップS17)、上述のビット単位の照合を実行する。図9の例では、メタファイル0003.MTA及び0001.MTAのマップテーブルMAP_2内の2番目のビットBT(1)はいずれも1である。この場合、無効化部232aは、メタファイル0001.MTAのマップテーブルMAP_2内の2番目のビットBIT(1)を、図9において矢印93で示されるように0にセット(変更)する。
同様に、図9の例では、メタファイル0003.MTA及び0002.MTAのマップテーブルMAP_2内の3番目のビットBIT(2)はいずれも1である。この場合、無効化部232aは、メタファイル0002.MTAのマップテーブルMAP_2内の3番目のビットBIT(2)を、図9において矢印94で示されるように0に変更する(ステップS16)。また図9の例では、メタファイル0003.MTA,0002.MTA及び0001.MTAのマップテーブルMAP_2内の4番目のビットBIT(3)はいずれも1である。この場合、無効化部232aは、メタファイル0002.MTA及び0001.MAPのマップテーブルMAP_2内の4番目のビットBIT(3)を、図9において矢印95a及び95bで示されるように0に変更する(ステップS16)。
また、図9の例では、メタファイル0003.MTA,0002.MTA及び0001.MTAのマップテーブルMAP_2の矩形枠96内のビットBIT(7)(マップテーブルMAP_2の最後のビット)は、それぞれ0,1及び1である。つまり、最新のメタファイル0003.MTAのマップテーブルMAP_2の矩形枠96内のビットBIT(7)は0であるが、それよりも古い世代のメタファイル0002.MTA及び0001.MTAの両マップテーブルMAP_1のビットBIT(7)はいずれも1である。この場合、無効化部232aは、最も古い世代のメタファイル0001.MTAのマップテーブルMAP_2の矩形枠96内のビットBIT(7)を、図9において矢印97で示されるように0に変更する(ステップS16)。
メタファイル0003.MTA,0002.MTA及び0001.MTAのマップテーブルMAP_3についても同様である。図9の例では、無効化部232aは、楕円枠98で囲まれたメタファイル0002.MTAのマップテーブルMAP_3の3番目のビットB(2)及び8番目のビットB(7)の各々を0に変更する。また無効化部232aは、メタファイル0001.MTAのマップテーブルMAP_3の1番目、4番目、7番目及び8番目のビットの各々を0に変更する。
次に、セクタデータの置き換えについて、図10を参照して説明する。図10の例は、メタファイル0002.MTAのマップテーブルMAP_2(100)に、図9に示されたような無効化処理が施された場合を前提としている。
まず、最新世代(第3世代)のメタファイル0003.MTAのマップテーブルMAP_2の少なくとも1ビット(ここでは4ビット)は、図9に示されるように0でない(ステップS33のNo)。そこで、クライアント端末2の要求部233から配信サーバ1に、図10に示されるような最新世代(第3世代)のブロックBLK_2(101)の配信が要求されたものとする(ステップS34)。この場合、配信サーバ1の配信部13からクライアント端末2に第3世代のブロックBLK_2(101)のデータが配信され、当該第3世代のブロックBLK_2(101)のデータがクライアント端末2の受信部231によって受信される(ステップS35)。受信された第3世代のブロックBLK_2(101)のデータは、ディスク領域25に保存される(ステップS37)。
受信され且つ保存された第3世代のブロックBLK_2(101)は、図10に示されるように、マップテーブルMAP_2と、データ部DATA_2とを含む。第3世代のブロックBLK_2(101)のマップテーブルMAP_2は、図9に示される、メタファイル0003.MTA(123)のマップテーブルMAP_2と同一内容であり、“11110000”である。この場合、第3世代のブロックBLK_2(101)のデータ部DATA_2に含まれる有効セクタは、図10において実線の矩形枠で囲まれたセクタ0乃至3である。
その後、第2世代のメタファイル0002.MTAに含まれていて、且つ無効化処理が施されたマップテーブルMAP_2(100)に基づいて、クライアント端末2の要求部233から配信サーバ1に、図10に示されるような第2世代のブロックBLK_2(102)の配信が要求されたものとする(ステップS34)。すると、配信サーバ1の配信部13からクライアント端末2に第2世代のブロックBLK_2(102)のデータが配信される。クライアント端末2に配信された第2世代のブロックBLK_2(102)のデータは、クライアント端末2の受信部231によって受信される(ステップS35)。
受信された第2世代のブロックBLK_2(102)は、図10に示されるように、マップテーブルMAP_2と、データ部DATA_2とを含む。受信された第2世代のブロックBLK_2(102)のマップテーブルMAP_2の内容は、第2世代のメタファイル0002.MTA(122)に含まれていて、且つ無効化処理が施される前のマップテーブルMAP_2(図9参照)のそれと同一である。つまり、受信された第2世代のブロックBLK_2(102)のマップテーブルMAP_2の内容は、“00110011”である。この場合、受信された第2世代のブロックBLK_2(102)のデータ部DATA_2に含まれる有効セクタは、図10において実線の矩形枠で囲まれたセクタ2,3,6及び7である。
一方、第2世代のメタファイル0002.MTA(122)に含まれていて、且つ無効化処理が施されたマップテーブルMAP_2(100)の内容は、“00000011”である。明らかなように、マップテーブルMAP_2(100)の3番目のビットBT(2)及び4番目のビットBT(3)は、無効化処理により、1から0に変更されている。しかし、マップテーブルMAP_2(100)の7番目のビットBT(6)及び8番目のビットBT(7)は、無効化処理の後も1に保持されている。このことは、第2世代よりも新しい第3世代のブロックBLK−2(101)に含まれていて、且つビットBT(6)及びBT(7)に対応するセクタ6及び7が、無効セクタであることを示す。このとき、第3世代のブロックBLK−2(101)は、既に受信部231によって受信されて、ディスク領域25に保存されている。
そこで置換部235aは、第2世代のメタファイル0002.MTA(122)に含まれていて、且つ無効化処理が施されたマップテーブルMAP_2(100)に基づき、次のような置換処理を行う。ここで、今回受信された第2世代のブロックBLK_2(102)に含まれているセクタ6及び7は、無効化処理が施されたマップテーブルMAP_2(100)のビットBT(6)及びBT(7)に図10において矢印103及び104で示されるように対応付けられている。
まず置換部235aは、この第2世代のブロックBLK_2(102)のセクタ6及び7のデータを、ディスク領域25に保存されている第3世代のブロックBLK−2(101)のセクタ6及び7に、図10において矢印105及び106で示されるように上書きする(ステップS41)。つまり置換部235aは、第2世代のブロックBLK_2(102)のセクタ6及び7のデータで、第3世代のブロックBLK−2(101)のセクタ6及び7を置き換える(書き換える)。次に置換部235aは、このセクタデータの置き換えが行われた第3世代のブロックBLK−2(101)のマップテーブルMAP_2のビットBT(6)及びBT(7)を、図10において矢印107及び108で示されるように、0から1に変更する(ステップS42)。
上述の説明から明らかなように、本実施形態は以下に列挙される効果を有する。
(1)クライアント端末2はディスクイメージの一部のみを受信すれば良く、当該クライアント端末2の負荷が低減される。また配信サーバ1は、実データのみを転送すれば良いことから、転送時間が従来技術と比較して短縮される。また、それにより、配信サーバ1及びネットワーク4の負荷を低減することができる。
(2)クライアント端末2においてディスクイメージを保存するのに用いられるディスク領域25に必要な容量を、差分間のデータ結合を実行しなくても削減できる。また、結合操作に要するコストが削減される。
(3)差分ディスクファイルの数が増えても、クライアント端末2は、重複したデータブロック、古いデータブロック、更には使用されないデータブロックを受信する必要がなく、したがって当該クライアント端末2の負荷が低減される。また、それにより、配信サーバ1及びネットワーク4の負荷を低減し、且つディスク領域25に必要な容量を削減できる。
(4)差分ディスクファイルの数が増えても、ディスクイメージを保存するのに、クライアント端末2は1つの仮想ディスク(ディスク領域25)を用意するだけで良い。これにより、仮想ディスクのアクセス性能が劣化するのを防止できる。
前記実施形態では、クライアント端末2の起動時に、制御仮想マシン23が第1のマシンとして、マスタディスクファイル51、差分ディスクファイル52及び差分ディスクファイル53を1つの仮想ディスクファイルにマージする処理を実行する。しかし、クライアント端末2の実マシン(つまり、非仮想マシン)が、制御OS26(第1のOS)に基づいて第1のマシンとして動作して、上述のマージ処理を実行しても良い。また、実マシンが、マージ処理の終了後に、制御OS26から、ディスク領域25に保存されている仮想ディスクファイル内のゲストOS(第2のOS)に切り替えて、クライアント端末2を再起動すれば良い。この場合、実マシンは、ゲストOS(第2のOS)に基づいて第2のマシンとして動作する。つまりクライアント端末2は、第1のマシンの動作から第2のマシンの動作に切り替えられる。
なお、図1に示されるコンピュータシステム以外のシステムが、前記実施形態で適用されたような仕組み(つまり、マスタディスクファイル及び少なくとも1つの差分ディスクファイルに含まれている仮想ディスクイメージを処理するための仕組み)を利用することも可能である。例えば、この仕組みは、第1の論理ディスク(論理ユニット)に格納されているマスタディスクファイル及び少なくとも1つの差分ディスクファイルのデータを、バックアップのために第2の論理ディスクにコピーするシステムに応用可能である。
以上説明した少なくとも1つの実施形態によれば、仮想ディスクを構成するマスタディスクイメージ、及び少なくとも1つの差分ディスクイメージを全て配信サーバからクライアント端末に配信することなく、当該クライアント端末において仮想ディスクを利用することができる、コンピュータシステム、クライアント端末及び仮想ディスクイメージを処理する方法を提供できる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。
Claims (5)
- 第1のオペレーティングシステムに基づいて第1のマシンとして動作するクライアント端末と、
前記クライアント端末とネットワークを介して接続される配信サーバであって、前記クライアント端末に仮想ディスクとして認識させるための第1の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも1つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信する配信サーバとを具備し、
前記第1の仮想ディスクファイルは、前記クライアント端末が第2のマシンとして動作するための第2のオペレーティングシステムを含む第1の仮想ディスクイメージを格納し、
前記マスタディスクファイルは、第1のサイズを有するN個のブロックから構成される第1世代の仮想ディスクイメージを第2の仮想ディスクイメージとして格納し、
前記少なくとも1つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる、前記第1のサイズを有するN個のブロックから構成される差分ディスクイメージを、前記第1世代より新しい世代の第3の仮想ディスクイメージとして格納し、
前記マスタディスクファイル及び前記少なくとも1つの差分ディスクファイルの各々は管理情報を有し、
前記管理情報は、対応するディスクファイルに含まれるN個のブロックの各々が有効であるかを少なくとも示し、
前記配信サーバは、
前記マスタディスクファイルから抽出される前記管理情報を含む第1世代の第1のメタファイルと、前記少なくとも1つの差分ディスクファイルから抽出される前記管理情報を含む前記第1世代より新しい世代の少なくとも1つの第2のメタファイルとを生成するメタファイル生成部と、
前記第1のメタファイル及び前記少なくとも1つの第2のメタファイルを前記クライアント端末に配信し、前記クライアント端末によって要求された複数のブロックのデータを前記クライアント端末に配信する配信部とを具備し、
前記クライアント端末の前記第1のマシンは、
前記第1のメタファイルに含まれている前記管理情報及び前記少なくとも1つの第2のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出する解析部と、
前記検出された複数の有効なブロックの配信を前記配信サーバに要求する要求部と、
前記配信サーバの前記配信部によって配信された複数の有効なブロックのデータを前記第1の仮想ディスクイメージに組み合わせるマージ部と、
第1のブロック、及び前記第1のブロックよりも古い世代の第2のブロックであって、前記第1のブロックとディスクファイル内の相対位置が同一の第2のブロックが、いずれも有効なブロックとして検出された場合、前記第2のブロックを無効化する無効化部とを具備する
コンピュータシステム。 - 前記N個のブロックの各々は、前記第1のサイズよりも小さい第2のサイズを有するm個のセクタから構成され、
前記管理情報は、対応するディスクファイルに含まれる前記N個のブロックの各々に対応付けられたマップ情報を含み、
前記マップ情報は、対応するブロックの前記m個のセクタの各々が有効であるかを示し、
前記解析部は、前記第1のメタファイルに含まれている前記管理情報及び前記少なくとも1つの第2のメタファイルに含まれている前記管理情報を世代の逆順に取り出して、前記取り出された管理情報に含まれる前記N個のブロックの各々に対応付けられたマップ情報を参照することにより、対応するブロックに含まれるm個のセクタの各々が有効であるかを判定し、
前記無効化部は、前記第1のブロックに含まれる第1のセクタが有効であると前記第1のブロックに対応付けられた第1のマップ情報に基づいて判定された場合、前記第2のブロックに対応付けられていて且つ当該判定に用いられたメタファイルよりも古い世代のメタファイルに含まれている管理情報内の第2のマップ情報を、前記第2のブロックに含まれていて且つブロック内の相対位置が前記第1のセクタと同一である第2のセクタが無効であることを示すように変更し、
前記要求部は、前記第2のマップ情報により前記第2のブロック内のm個のセクタが全て無効であると示されている場合、当該第2のブロックの配信を要求するのを抑止する
請求項1記載のコンピュータシステム。 - 前記要求部は、前記検出された複数の有効なブロックの配信を、ブロックを単位に世代の逆順に要求し
前記クライアント端末の前記第1のマシンは、前記配信部によって第3のブロックのデータが配信され、且つ当該第3のブロックとディスクファイル内の相対位置が同一のブロックがディスク領域に保存されていない場合、当該第3のブロックを前記ディスク領域に保存する保存部を更に具備し、
前記第3のブロックは第3のマップ情報を含み、
前記解析部は、前記保存部に保存されている前記第3のブロックとディスクファイル内の相対位置が同一の第4のブロックが前記配信部によって配信され、且つ、前記第4のブロックの世代に対応するメタファイルに含まれている前記第4のブロックに対応付けられた第4のマップ情報が前記無効化のために変更されている場合、当該第4のマップ情報に基づいて、前記第4のブロック内の有効なセクタを検出し、
前記マージ部は、前記有効なセクタとして第4のセクタが検出された場合、前記保存部に保存されている前記第3のブロックに含まれていて、且つブロック内の相対位置が前記第4のセクタと同一の第3のセクタを、前記第4のセクタのデータで置き換え、且つ前記第3のセクタが有効であることを示すように、前記第3のブロックに含まれている前記第3のマップ情報を変更する置換部を具備する
請求項2記載のコンピュータシステム。 - 配信サーバとネットワークを介して接続され、且つ第1のオペレーティングシステムに基づいて第1のマシンとして動作するクライアント端末において、
前記配信サーバは、前記クライアント端末に仮想ディスクとして認識させるための第1の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも1つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信し、
前記第1の仮想ディスクファイルは、前記クライアント端末が第2のマシンとして動作するための第2のオペレーティングシステムを含む第1の仮想ディスクイメージを格納し、
前記マスタディスクファイルは、第1のサイズを有するN個のブロックから構成される第1世代の仮想ディスクイメージを第2の仮想ディスクイメージとして格納し、
前記少なくとも1つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる、前記第1のサイズを有するN個のブロックから構成される差分ディスクイメージを、前記第1世代より新しい世代の第3の仮想ディスクイメージとして格納し、
前記マスタディスクファイル及び前記少なくとも1つの差分ディスクファイルの各々は管理情報を有し、
前記管理情報は、対応するディスクファイルに含まれるN個のブロックの各々が有効であるかを少なくとも示し、
前記配信サーバは、
前記マスタディスクファイルから抽出される前記管理情報を含む第1世代の第1のメタファイルと、前記少なくとも1つの差分ディスクファイルから抽出される前記管理情報を含む前記第1世代より新しい世代の少なくとも1つの第2のメタファイルとを生成するメタファイル生成部と、
前記第1のメタファイル及び前記少なくとも1つの第2のメタファイルを前記クライアント端末に配信し、前記クライアント端末によって要求された複数のブロックのデータを前記クライアント端末に配信する配信部とを具備し、
前記クライアント端末の前記第1のマシンは、
前記第1のメタファイルに含まれている前記管理情報及び前記少なくとも1つの第2のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出する解析部と、
前記検出された複数の有効なブロックの配信を前記配信サーバに要求する要求部と、
前記配信サーバの前記配信部によって配信された複数の有効なブロックのデータを前記第1の仮想ディスクイメージに組み合わせるマージ部と、
第1のブロック、及び前記第1のブロックよりも古い世代の第2のブロックであって、前記第1のブロックとディスクファイル内の相対位置が同一の第2のブロックが、いずれも有効なブロックとして検出された場合、前記第2のブロックを無効化する無効化部とを具備する
クライアント端末。 - クライアント端末と配信サーバとを具備するコンピュータシステムに適用される、仮想ディスクイメージを処理する方法において、
前記クライアント端末は、前記配信サーバとネットワークを介して接続され、且つ第1のオペレーティングシステムに基づいて第1のマシンとして動作するように構成され、
前記配信サーバは、前記クライアント端末に仮想ディスクとして認識させるための第1の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも1つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信するように構成され、
前記第1の仮想ディスクファイルは、前記クライアント端末が第2のマシンとして動作するための第2のオペレーティングシステムを含む第1の仮想ディスクイメージを格納し、
前記マスタディスクファイルは、第1のサイズを有するN個のブロックから構成される第1世代の仮想ディスクイメージを第2の仮想ディスクイメージとして格納し、
前記少なくとも1つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる、前記第1のサイズを有するN個のブロックから構成される差分ディスクイメージを、前記第1世代より新しい世代の第3の仮想ディスクイメージとして格納し、
前記マスタディスクファイル及び前記少なくとも1つの差分ディスクファイルの各々は管理情報を有し、
前記管理情報は、対応するディスクファイルに含まれるN個のブロックの各々が有効であるかを少なくとも示し、
前記方法は、
前記マスタディスクファイルから抽出される前記管理情報を含む第1世代の第1のメタファイルと、前記少なくとも1つの差分ディスクファイルから抽出される前記管理情報を含む前記第1世代より新しい世代の少なくとも1つの第2のメタファイルとを生成し、
前記配信サーバから前記クライアント端末に、前記第1のメタファイル及び前記少なくとも1つの第2のメタファイルを配信し、
前記第1のメタファイルに含まれている前記管理情報及び前記少なくとも1つの第2のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出し、
前記検出された複数の有効なブロックの配信を前記クライアント端末の前記第1のマシンから前記配信サーバに要求し、
前記配信サーバによって前記クライアント端末に配信された複数の有効なブロックのデータを前記第1の仮想ディスクイメージに組み合わせ、
第1のブロック、及び前記第1のブロックよりも古い世代の第2のブロックであって、前記第1のブロックとディスクファイル内の相対位置が同一の第2のブロックが、いずれも有効なブロックとして検出された場合、前記第2のブロックを無効化する
方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2013/068975 WO2015004769A1 (ja) | 2013-07-11 | 2013-07-11 | 仮想ディスクイメージを処理するシステム、クライアント端末、及び方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP5692829B1 true JP5692829B1 (ja) | 2015-04-01 |
JPWO2015004769A1 JPWO2015004769A1 (ja) | 2017-02-23 |
Family
ID=52279491
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013540170A Expired - Fee Related JP5692829B1 (ja) | 2013-07-11 | 2013-07-11 | 仮想ディスクイメージを処理するシステム、クライアント端末、及び方法 |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP5692829B1 (ja) |
WO (1) | WO2015004769A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110928494A (zh) * | 2019-11-01 | 2020-03-27 | 西安雷风电子科技有限公司 | 一种虚拟磁盘数据同步服务器、客户端及系统 |
CN112394969A (zh) * | 2019-08-14 | 2021-02-23 | 华为技术有限公司 | 一种补丁发布的方法、服务器及终端设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010049488A (ja) * | 2008-08-21 | 2010-03-04 | Hitachi Ltd | ストレージシステム及びデータ管理方法 |
JP2010181924A (ja) * | 2009-02-03 | 2010-08-19 | Hitachi Ltd | データベース管理方法および装置並びにその処理プログラム |
JP2010231661A (ja) * | 2009-03-27 | 2010-10-14 | Nec Corp | 仮想マシンシステム、仮想マシンシステムの動作方法、及び仮想マシンシステムの動作プログラム |
JP2012058957A (ja) * | 2010-09-08 | 2012-03-22 | Nec Corp | 仮想クライアントサーバ及び仮想クライアントサーバの制御方法 |
-
2013
- 2013-07-11 WO PCT/JP2013/068975 patent/WO2015004769A1/ja active Application Filing
- 2013-07-11 JP JP2013540170A patent/JP5692829B1/ja not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010049488A (ja) * | 2008-08-21 | 2010-03-04 | Hitachi Ltd | ストレージシステム及びデータ管理方法 |
JP2010181924A (ja) * | 2009-02-03 | 2010-08-19 | Hitachi Ltd | データベース管理方法および装置並びにその処理プログラム |
JP2010231661A (ja) * | 2009-03-27 | 2010-10-14 | Nec Corp | 仮想マシンシステム、仮想マシンシステムの動作方法、及び仮想マシンシステムの動作プログラム |
JP2012058957A (ja) * | 2010-09-08 | 2012-03-22 | Nec Corp | 仮想クライアントサーバ及び仮想クライアントサーバの制御方法 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112394969A (zh) * | 2019-08-14 | 2021-02-23 | 华为技术有限公司 | 一种补丁发布的方法、服务器及终端设备 |
CN112394969B (zh) * | 2019-08-14 | 2023-04-28 | 华为技术有限公司 | 一种补丁发布的方法、服务器及终端设备 |
CN110928494A (zh) * | 2019-11-01 | 2020-03-27 | 西安雷风电子科技有限公司 | 一种虚拟磁盘数据同步服务器、客户端及系统 |
CN110928494B (zh) * | 2019-11-01 | 2024-02-02 | 西安雷风电子科技有限公司 | 一种虚拟磁盘数据同步服务器、客户端及系统 |
Also Published As
Publication number | Publication date |
---|---|
WO2015004769A1 (ja) | 2015-01-15 |
JPWO2015004769A1 (ja) | 2017-02-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10579364B2 (en) | Upgrading bundled applications in a distributed computing system | |
CN108701048B (zh) | 数据加载方法及装置 | |
JP6450598B2 (ja) | 情報処理装置、情報処理方法およびプログラム | |
JP4884041B2 (ja) | 自動拡張可能なボリュームに対して最適なi/oコマンドを発行するストレージシステム及びその制御方法 | |
US10628235B2 (en) | Accessing log files of a distributed computing system using a simulated file system | |
JP4952308B2 (ja) | メモリ共有システム、方法、及び、プログラム | |
JP2007133471A (ja) | ストレージ装置及びスナップショットのリストア方法 | |
US10620871B1 (en) | Storage scheme for a distributed storage system | |
US11256434B2 (en) | Data de-duplication | |
US10642697B2 (en) | Implementing containers for a stateful application in a distributed computing system | |
JP6653370B2 (ja) | ストレージシステム | |
US20120066466A1 (en) | Storage system storing electronic modules applied to electronic objects common to several computers, and storage control method for the same | |
JP5692829B1 (ja) | 仮想ディスクイメージを処理するシステム、クライアント端末、及び方法 | |
CN107832097B (zh) | 数据加载方法及装置 | |
JP2023056222A (ja) | ストレージシステム及びストレージシステムにおけるデータ複製方法 | |
US11288006B2 (en) | Storage system and volume copying method where changes to address conversion table is rolled back | |
KR20150089688A (ko) | 가상 머신 이미지 파일의 캐시 관리 장치 및 방법 | |
US20190212923A1 (en) | Implementing An Interface To A High-Availability Storage System In A Distributed Computing System | |
US10503702B2 (en) | Information processing device, information processing method, and program | |
US11112973B2 (en) | Computer system and data management method | |
JP2013109404A (ja) | 情報処理装置 | |
JP2010237742A (ja) | 仮想マシンサーバ、仮想マシン制御方法及び仮想マシン制御プログラム | |
US11836110B2 (en) | Storage system, computer system, and control method | |
US11748259B2 (en) | System and method to conserve device lifetime for snapshot generation | |
JP7110615B2 (ja) | 情報処理装置、情報処理システム、情報処理方法、及び、プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20150106 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150129 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5692829 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
LAPS | Cancellation because of no payment of annual fees |