JP6072352B2 - ディスク配信システム - Google Patents

Description

本発明は、多数のクライアント端末に効率よくオペレーティングシステムを配備することを可能にするディスク配信システムに関するものである。

多数のクライアント端末（以下、「端末」という。）にオペレーティングシステム（以下、「ＯＳ」という。）を配備する方法として、近年はネットワークブートシステムが広く普及している（特許文献１）。ネットワークブートシステムは、ネットワークブートサーバー上に保存された端末用のＯＳを含むデータがディスクイメージとして保存された「ＯＳイメージデータ」を、ＬＡＮ（ローカル・エリア・ネットワーク）等の高速のネットワークを介して各端末に直接マウントして共有する点に特徴があり、ネットワークブートサーバー側でＯＳイメージデータの更新が行われるとその更新が直ちに（正確には各端末の次回再起動時から）反映される点に最大の利点がある。さらに、ネットワークブートサーバーが管理する端末のデータは１つで済むため、複数のバージョンを世代管理するといったことも比較的容易に実現することができる。

ネットワークブートシステムは、１台のネットワークブートサーバーに対して多数の端末を接続するという、『１：Ｎ接続』を前提とする。そのため、基盤技術として、高速のネットワーク環境が端末の起動時から接続されていることが前提となる。例えば、端末の数が５０台を超えるような大規模なネットワークブートシステムでは、ギガビットクラスの超高速ネットワークで接続されたＬＡＮ環境がなければ、実用に耐えうる快適な動作は期待できない。近年ネットワークブートシステムが急速に普及してきた背景は、この超高速ネットワークの普及によるところが大きい。

これに対して、共通のＯＳイメージデータをマスターデータとして、そのコピーを端末に配信して起動する技術（これを、本明細書では、「ディスク配信技術」という。）が知られている（特許文献２）。ディスク配信技術は、古くはその名前の由来ともなったＤＶＤやＣＤといったディスク状の記録メディアによりＯＳのブートイメージの配布（配信）が行われていたが、近年ではネットワークを介してサーバーからクライアント端末に配信する方法等も考えられている。ディスク配信技術のように、端末がネットワークを介さずローカル環境のみで起動する起動方法を、本明細書では、ネットワークブートに対して、「ローカルブート」と呼ぶものとする。

ＷＯ２００９／０６９３２６ 米国特許第６，１０８，６９７

近年のデスクトップ環境を前提とすると、ＯＳイメージデータのサイズは５０ＧＢ〜１００ＧＢあるいはそれ以上にも達する。そのため、ディスク配信技術により多数の端末にＯＳイメージデータを配信するには非常に長時間を要する。

例えば、記録メディアを用いて配信する場合は多数の記録メディアを準備することが必要となる。ユニキャスト配信により１台のマスターサーバーから多数の端末に配信する場合は、ネットワーク帯域の制約を受けるために、端末１台あたりの転送レートが著しく低下して、やはり配信には非常に長時間を要する。

さらに、ディスク配信技術によれば、マスターデータが更新された際にも、各端末への配信作業を一からやり直さなければならないという欠点もある。しかも、近年のデスクトップ環境は、ソフトウエアの新規インストール等の作業が全く必要ない場合でも、ＯＳやセキュリティソフトのアップデート作業のように高い頻度で更新が必要となってきており、配信に時間のかかるディスク配信の欠点は致命的なものであった。

既に述べたように、ネットワークブートシステムはこれらの問題をうまく解決するが、
（１）遅いネットワークが使えない
（２）ネットワークブートサーバーと通信を行えない状態では、起動はもちろん、動作し続けることすらできない
といった欠点がある。

なお、ネットワークブートシステムにおいて、端末側にキャッシュ機構を設けることで上記の問題点は部分的に解消できる場合があるが、サーバー上のＯＳイメージデータが更新された際にはネットワーク接続が必要となる。すなわち、ネットワークブートシステムのシステム要件は、基本的には、「ネットワークブートサーバーと端末とがネットワーク機器を介して有線ネットワークによって接続され、かつ、少なくとも端末のネットワーク機器はオンライン状態（ネットワークカード、スイッチングハブ等の全てのネットワーク機器類に電源が入っていてネットワークブートサーバーと通信できる状態）でサーバーに接続されていること」となっている。

本発明は、上記に鑑みてなされたものであり、サーバーと通信を行えない状態でも起動可能なローカルブートを前提としつつ、ネットワークブートの利点であるＯＳイメージデータの更新作業や世代管理を効率よく行うことを可能にする新規なディスク配信システムを提供することを主たる技術的課題とする。

本発明に係るディスク配信システムは、少なくとも１台のマスターサーバーと、複数の端末とがネットワークを介して接続され、
前記マスターサーバーが管理するＯＳイメージデータ又はＯＳイメージデータ及びそれに対する１つ又は複数の差分データをマスターデータとして、そのコピー又は所定のディスクフォーマット形式に変換されたデータが前記端末のブートイメージとして配備され、
前記マスターデータが更新された際には、前記端末が稼動している状態で、前記ネットワークを介して更新前のマスターデータとの差分データを前記端末が前記ネットワークを介して前記マスターサーバーから受け取り、前記端末が再起動することにより前記端末の前記ブートイメージが更新されることを特徴とする。

ここで、「マスターサーバー」とは、コピー元となる「マスターデータ」を保持する少なくとも１台のコンピュータをいう。なお、ブートイメージの更新を反映させるためには「再起動」が必要であるが、端末の再起動には種々の目的があるため、マスターサーバーから差分データを受け取った以後、どのタイミングでブートイメージを更新するかは設定による。

本発明で配信されるＯＳのディスクイメージは、端末上で仮想マシンとして動作するものではなく、通常のブートプロセスを経てローカルブートするものを前提としている。なお、「ローカルブート」は、ネットワークブートシステムにおいて、端末にキャッシュデータが保持されていて、ネットワークブートサーバーに接続されていないオフライン状態で起動できる場合を含むものと解する。

そして、マスターデータが更新された際には、端末の稼動中に、差分データのみをネットワーク経由で受け取ることができる。ここで、「端末の稼動中」とは、端末が起動プロセスを終了して、ＯＳが通常状態にあることを意味する。

前記端末は、前記端末のホスト名及びＩＰアドレスを含む各端末の固有データ及び各端末への書き込みデータ、デバイスドライバの構成情報などを前記ブートイメージに対する差分データとして保持する差分管理機構を具備していてもよい。また、前記差分管理機構は、仮想ディスクシステム又はコピー・オン・ライト方式のファイルシステムであってもよい。

前記差分データは、ＯＯＢＥ（Ｏｕｔ−Ｏｆ−Ｂｏｘ Ｅｘｐｅｒｉｅｎｃｅ）状態のＯＳイメージデータへの差分データであってもよい。より具体的には、前記端末が前記端末用オペレーティングシステムで最初に起動する際に又は起動後必要に応じて必要なデバイスドライバが前記端末用オペレーティングシステムのカーネルに読み込まれると共に、デバイスドライバの読み込みが完了した状態に相当する最新のＯＳイメージデータをＯＯＢＥ状態に対する差分データとして用いるように構成してもよい。

このような構成によれば、端末のハードウェア構成が異なっていても、最初の起動時又は、起動後必要に応じてデバイスドライバが前記端末用オペレーティングシステムのカーネルに読み込まれる。すなわち、端末側のデバイス構成が全て同一構成である必要がなくなり、デバイス構成の違いを吸収して端末を起動できるようになる。

なお、多数の端末を共通のＯＳイメージデータで起動するネットワークブートシステムにおいては、ＩＰアドレス、ホスト名、ドメイン情報などの最小限の情報のみを端末に付与しつつ比較的短時間に起動プロセスを完了させなければならないため、全ての端末が同一のハードウェア構成で構成されることを前提としハードウェア構成が異なる場合の動作は保証されない。これに対し、本システムは端末のハードウェア構成が必ずしも同一でない場合でも、動作させることができる。

ただし、ＯＯＢＥ状態のイメージデータを用いると、最初の起動時にデバイスドライバの読み込み動作が発生するため、起動が遅くなるという欠点がある。そのため、全ての端末が同一のハードウェア構成を備えている場合には、ＯＯＢＥ状態のＯＳイメージデータよりも、予めデバイスドライバ等が設定済みのＯＳイメージを含むマスターデータを１つ作っておく方が効率がよい。例えば、ネットワークブートシステムで構築されたシステムからハードウェア構成をそのまま変更せず本システムに置き換える場合には、必ずしもＯＯＢＥ状態のＯＳイメージデータを用いる必要はない。

なお、「最初の起動」とは、イメージデータが更新された直後の起動をいい、その後も毎回起動のたびごとにデバイスドライバの読み込みが行われるわけではない。

また、前記端末は、ブートイメージ又は差分データを扱うために用いられる管理用ＯＳを具備していてもよい。管理用ＯＳとは、ブート用ＯＳとは独立して起動される他のＯＳであり、ＯＳレベルでマスターデータや差分データを認識してデータを扱えるものであれば、ＯＳの種類は問わない。例えば、端末にプリインストールされているＯＳを用いてもよい。管理用ＯＳで起動するとマスターデータや差分データの初期化、コピー、リネーム、マージなどの操作が可能となる。

また、１つの端末が、１つ又は複数のライトキャッシュを具備するように構成してもよい。ライトキャッシュに書き込むようにすれば、ライトキャッシュを消去するだけで容易に書き込み前の状態に復元することができるからである。

前記端末は、マスターサーバーからネットワークを介してマスターデータ及び差分データのコピーを受け取り、前記端末の起動ディスクを初期化する機能を具備していてもよい。具体的には、例えば、端末が予めネットワーク接続可能な別のＯＳ（これを「初期化用ＯＳ」という）で稼動している状態で、ネットワークを介してマスターサーバーからマスターデータのコピーを受け取り、そのコピーをブート用ＯＳに切り替えて端末を起動させることもできる。ここで、初期化用ＯＳとは、マスターデータのＯＳとは独立して起動できる他のＯＳであれば、どのようなものでもよい。例えば端末にプリインストールされているＯＳを利用してもよいし、Ｌｉｎｕｘ（登録商標）その他のＯＳであってもよい。

また、端末の初期化直後には必ずしも「ネットワークを介して」マスターデータのコピーが配信される必要はなく、記録メディア等を用いた従来の配信方法を用いてもよい。なお、「初期化用ＯＳ」と「管理用ＯＳ」とは同一のものを指していてもよい。

この場合、コピーに代えて、そのコピーに基づいてフォーマット変換された所定のディスクフォーマット形式のデータであってもよい。いずれの場合にも、端末は、マスターデータのコピーを受け取った後、受け取ったＯＳイメージデータをブート用ＯＳとして起動するという意味においてローカルブートであり、ネットワークブートサーバーと通信を行えない状態でも起動し、かつ動作し続けることができる。これは、ネットワークブートシステムと比較した大きな利点である。

前記複数の端末のうちの１台が、マスターサーバーとしても機能するように構成してもよい。マスターサーバーは、必ずしも、専用のサーバーが稼動している必要はない。

前記マスターサーバーは、異なるハードウェア構成の端末に対して、ＯＯＢＥ状態のＯＳイメージに変換するための差分データを配信するように構成してもよい。

前記端末は、前記マスターサーバーからハードウェア構成の異なる他の端末用のＯＳイメージデータを受け取ると共に、前記受け取ったＯＳイメージデータをＯＯＢＥ状態のＯＳイメージデータに変換するための差分データを受け取り、それらを用いて端末を起動するように構成してもよい。

本発明によれば、端末をネットワークブートサーバーと通信を行えない状態でも起動できるため、起動時にネットワークアクセスが発生せず、かつ動作し続けることができる。また、マスターデータが更新された際には端末の稼動中にその差分データをネットワーク経由で受け取ることができるため、無線ＬＡＮなどの遅いネットワークやマルチキャスト配信あるいはピア・ツー・ピア配信なども可能となる。

第１の実施形態のディスク配信システムの基本構成を説明するための概念図 第２の実施形態の実施例１〜３の動作を示す概念図 第３の実施形態で説明する端末の個別設定の手順を示す概念図 第４の実施形態における端末Ａ及び端末Ｂの仮想ディスク構成を示す図 第４の実施形態における端末Ａでのマスターデータの更新及び配信手順を示す図 第４の実施形態における端末Ｂの仮想ディスクの状態を示す図 第５の実施形態における差分データ転送前の端末Ａでの仮想ディスクの処理手順を示す図 第５の実施形態における差分データ転送前の端末Ａでの差分データの作成手順を示す図 第５の実施形態における端末Ａのライトキャッシュの作成手順を示す図 第５の実施形態における差分データ転送後の端末Ｂの仮想ディスクの状態を示す図 第５の実施形態における差分データ転送後の端末Ｂの仮想ディスクの初期化手順を示す図 第５の実施形態における差分データ転送後の端末Ｂでのライトキャッシュの作成手順を示す図 第６の実施形態において、（Ａ）端末Ａから「２．ｖｈｄ」を端末Ｂに配信し、端末Ｂを起動した直後の端末Ａ（Ｂ）その時の端末Ｂの仮想ディスクの状態を示す図 第６の実施形態において、端末Ａでの仮想ディスクの処理手順を示す図 第６の実施形態において、端末Ｃの仮想ディスクの状態を示す図 第６の実施形態において、差分データ転送後の端末Ｃの仮想ディスクの状態を示す図 第６の実施形態において、差分データ転送後の端末Ｃの仮想ディスクの初期化手順を示す図

以下、本実施形態のディスク配信システムについて図面を参照して詳述する。まず、本発明が前提とするディスク配信システムの一実施態様を例示して説明する。各実施形態の記載は本発明の技術的思想を理解するために合目的的に解釈され、実施形態の記載に限定解釈されるべきものではない。また、各実施形態に記載の事項は特に明示した場合を除き、それぞれ組み合わせて実施することができる。

（第１の実施形態）−構成例−
図１は、第１の実施形態のディスク配信システムの構成例を示したものである。この実施形態では、スイッチングハブ１３などのネットワーク機器で構成されたローカル・エリア・ネットワーク（ＬＡＮ）１内に、少なくとも１台のマスターサーバー１０と、複数の端末２０（２０ａ，２０ｂ，・・・）とが、無線ＬＡＮアクセスポイント１５を介して無線ＬＡＮ３０により接続されている。

ただし、マスターサーバー１０は、端末の１台（２０ａ）がその役割をあわせ持つように構成することもできる。また、マスターサーバー１０は、仮想マシンであってもよい。また、この構成例では無線ＬＡＮを用いているが、有線ＬＡＮを用いた構成も可能である。

本発明が前提とする、「ディスク配信システム」は、ネットワークブートシステムとは異なり、各端末２０がいずれもブート用ＯＳを用いてローカルブートで起動する。そのため、有線ＬＡＮによる接続が可能であることはもちろんのこと、図１に示すような無線ＬＡＮによる接続や、ネットワークに接続されていない場合においても端末を起動できる。

まず、図１に示す環境を構築するために、初期化用ＯＳを用いる。初期化用ＯＳはマスターデータのＯＳとは独立して起動できる他のＯＳであれば、どのようなものでもよい。例えば端末にプリインストールされているＯＳを利用してもよいし、Ｌｉｎｕｘ（登録商標）その他のＯＳであってもよい。

まず、端末を初期化用ＯＳで起動する。初期化用ＯＳの稼働中はネットワークを介してマスターサーバー１０と通信が行えるため、マスターサーバー１０からマスターデータ及び差分データのコピーを受け取り、そのコピーを「ブート用ＯＳ」として端末に保存し、保存されたコピーを用いて端末を起動させる。

マスターサーバー１０によって配信されるＯＳイメージデータが例えば「仮想ディスクイメージ」であれば、初期化用ＯＳからみるとそのデータは「ファイル」として扱うことができるので、ネットワークを介してサーバーに接続されたマスターサーバー１０から「ファイルコピー」という単純な操作でデータを受け取ることになる。また、ファイルコピーに代えて、そのコピーしたデータに基づいてフォーマット変換された所定のディスクフォーマット形式のデータであってもよい。フォーマット変換の目的は圧縮、暗号化その他端末で稼動中のＯＳが認識できるフォーマット形式への変換など、種々のものが考えられる。さらには受け取ったデータをファイル形式のまま保存するだけでなく、データを Ｖ２Ｐ（仮想マシンから物理マシンへの変換）の要領で展開してディスクに書き込んでもよい。

もっとも、マスターデータのサイズは、デスクトップ用ＯＳのシステムディスクのサイズに相当するため、例えば、５０ＧＢ〜１００ＧＢ、あるいはそれ以上のサイズになることも想定され、ギガビット級のネットワークでもユニキャスト接続では転送に数十分を要する。多数の端末に転送する場合にはさらに長い時間を要する。
そこで、より配信効率の高い配信手段、例えば、マルチキャスト配信、ブロードキャスト配信、ピア・ツー・ピア配信などの配信手段を用いてもよい。あるいは、ネットワークを介さず、ＤＶＤなどの記録メディアを用いた配信手段等を用いてもよい。また、必要に応じて、データを複数に分割して転送してもよい。或いは、転送時にはチェックサムを確認し、万一転送に失敗したときは再度コピーをやり直すことで信頼度を高めることもできる。

いずれの場合にも、端末は、マスターデータのコピーを受け取った後、受け取ったＯＳイメージデータをブート用ＯＳとして起動するという意味において「ローカルブート」であり、ネットワークブートシステムとは異なり、ネットワークブートサーバーとの通信を行えない状態のままでも起動し、かつ動作し続けることができる。また、仮想マシンを用いる場合とは異なり、ＣＰＵ処理や周辺デバイスへのアクセスなどにおけるオーバーヘッドも生じない。

上述のように、データサイズの大きいマスターデータは、いずれかの手段によって順次端末の起動ディスク（端末のローカルディスクやＯＳの起動に必要なデータを保持しているディスク等）上にコピーされる必要があるが、一旦マスターデータが端末に配備された後で、マスターデータが更新された際には、更新前のマスターデータとの差分データだけをマスターサーバー１０から各端末２０へ配信する。これを行うためには、「ＯＳイメージデータを差分により管理する機構」の存在が前提となる。

配信するオペレーティングシステムにもよるが、ある種のＯＳでは、この機構がＯＳに備わっている。その１つに仮想ディスクが挙げられる。端末のＯＳ上では、仮想ディスクが特定のファイル形式でフォーマットされた１つ乃至複数の「ファイル」として構成され、更新が行われた場合、「差分ファイル」が作られる。この差分ファイルを各端末２０に配信すれば、サイズの大きい更新前のマスターデータを再度端末にコピーする必要はない。各端末２０は、マスターデータ又は差分データからブートすることができる。その際のブートプロセスは、仮想マシンとしてではなく、ＢＩＯＳ等の読み込みを含めた非仮想化環境における通常のブートプロセスである。

このような要請から、本発明では、端末がマスターデータのコピーを受け取った後、受け取ったＯＳイメージデータを仮想マシンが読み込んで利用するのではなく、ブート用ディスクとして直接起動に利用できることが必須となる。

なお、本発明における「仮想ディスク技術」の具体的かつ詳細な利用手順については後述するが、仮想マシンにおけるＯＳイメージデータの利用法と本発明における利用法とは、ＯＳイメージデータを仮想マシンが読み込んで利用する際には、
（１） ＯＳイメージデータにより起動されるＯＳと同時に、仮想マシンが動作する環境を起動するためのベースとなる別のＯＳが稼働した状態で用いられ、また、
（２） ＯＳイメージデータにより起動されたＯＳが端末のハードウェアにアクセスする際には、仮想マシンの管理下で行われるため動作にオーバーヘッドが生じる、
のに対し、本実施形態のようにブート用ディスクとして直接起動に利用する際には、
（ｉ） ＯＳイメージデータにより起動されるＯＳは、その端末でその時点で起動し
ている唯一のＯＳとして起動する、
（ｉｉ） ＯＳイメージデータにより起動されるＯＳは、端末のハードウェアに直接
アクセスできるため、動作にオーバーヘッドは生じない、
という点で、両者は本質的に相違する。

（第２の実施形態）−ディスク復元と差分管理について−
本実施形態では、差分管理の実際について詳述する。

−実施例１（ディスク復元、その１）−
端末を再起動するだけで管理者が予め設定した「初期状態」に復元できることは、例えば不特定多数のユーザーに短時間使用させるために多数の端末が配備されている施設等でしばしば求められる。第１の実施形態で示したディスク配信システムを前提にこの差分管理機構を適用すると、このようなニーズに応えることができる。

一例として、デスクトップ用のオペレーティングシステムの１つであるＷｉｎｄｏｗｓ（登録商標）では、「ＶＨＤ形式」と呼ばれる拡張子「．ｖｈｄ」乃至は「.ｖｈｄｘ」で表されるファイル形式を扱うことができる。ＶＨＤ形式のファイルは、ＯＳイメージデータなどを含む「記憶装置のある時点での状態」と関連付けられる。さらに、マスターデータとは別に、任意のタイミングでマスターデータに対する差分データを作成でき、さらに、特定の差分データに対するさらなる差分データを作成することもできる。また、複数の差分データをマージ（結合）して１つのファイルにすることもできる。

図２（Ａ）は、実施例１の動作を示す概念図である。図中の「０.ｖｈｄ」、は、ＯＳマスターデータの初期状態を表すファイルである。初期状態はＯＳインストール直後の状態であっても、一通り必要なプログラムやドライバソフトのインストール作業が完了した状態であってもよい。すなわち、どの状態を「初期状態」とするかは任意である。

この初期状態を表すファイル「０．ｖｈｄ」に対する差分データ 「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」を作成し、その差分データ「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」によって端末を起動する。図中の矢印の後端に示されるデータは、矢印の先端に示されるデータに対する差分データであることを示す。このような構成にすると、端末を起動した後においても差分データ「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」を内容ゼロの状態に「初期化」することで、即座に初期状態に復元することができる。これは、差分データ「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」をライトキャッシュとして機能させたことに相当する。なお、差分データを削除してマスターデータで起動しても同様に初期状態に復元できるが、その場合は、ライトキャッシュが存在しなくなり、マスターデータに直接データが書き込まれてしまうので、次回の起動でもライトキャッシュを機能させるためには、差分データのファイル自体は残し、内容のみを消去（初期化）するのがよい。

なお、繰り返しになるが、本実施形態においては、ＶＨＤ形式で保存されたマスターデータ「０．ｖｈｄ」や差分データ「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」に含まれるＯＳは、端末の「仮想マシン」上で実行されるのではなく、端末の物理的なＯＳとして直接実行されるものである。また、差分データ「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」で起動中に、自身「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」を消去することは、困難であると考えられる。このような場合、ブート用ＯＳとは独立して起動される他のＯＳとして「管理用ＯＳ」を別途導入しておき、一先ず管理用ＯＳで起動してから、差分データ「ｗｒｉｔｅｃａｃｈｅ０．ｖｈｄ」を初期化すればよい。

−実施例２（ディスク復元、その２）−
上述した実施例１の場合、差分データを初期化するために毎回管理用ＯＳを起動する必要があり、ディスク復元をするために待ち時間が必要となる。しかし、２つの差分データ（「ｗｒｉｔｅｃａｃｈｅ０−１．ｖｈｄ」及び「ｗｒｉｔｅｃａｃｈｅ０−２．ｖｈｄ」）を用いると、この問題を回避できる。

図２（Ｂ）は、実施例２の動作を示す概念図である。
まず、第１の差分データ「ｗｒｉｔｅｃａｃｈｅ０−１．ｖｈｄ」で起動する際に（又はそれ以前に、）第２の差分データ「ｗｒｉｔｅｃａｃｈｅ０−２．ｖｈｄ」を作成しておく。第２の差分データの中身はゼロであるから、第２の差分データ「ｗｒｉｔｅｃａｃｈｅ０−２．ｖｈｄ」は初期状態に等しい。そして、次回の起動時にはこの第２の差分データ「ｗｒｉｔｅｃａｃｈｅ０−２．ｖｈｄ」で起動する。第２の差分データでクライアントＯＳが稼動中に第１の差分データ「ｗｒｉｔｅｃａｃｈｅ０−１．ｖｈｄ」を初期化して、次回の起動はこの第１の差分データ「ｗｒｉｔｅｃａｃｈｅ０−１．ｖｈｄ」で起動する。プログラムを用いてこのプロセスを自動化してもよい。このように、マスターデータ「０．ｖｈｄ」に対する２つの差分データ「ｗｒｉｔｅｃａｃｈｅ０−１．ｖｈｄ」及び「ｗｒｉｔｅｃａｃｈｅ０−２．ｖｈｄ」を作成して一方で起動しつつ他方を初期化し、この手順を繰り返すことにより、管理用ＯＳを用いることなく、毎回初期状態に復元することが可能となる。また、「ｗｒｉｔｅｃａｃｈｅ０−１．ｖｈｄ」と「ｗｒｉｔｅｃａｃｈｅ０−２．ｖｈｄ 」とを交互に繰り返し用いるのではなく、「ｗｒｉｔｅｃａｃｈｅ０−３．ｖｈｄ」、「ｗｒｉｔｅｃａｃｈｅ０−４．ｖｈｄ」のように次々と新しい差分データを作成するように構成してもよい。

次に、実施例２の応用例として、ユーザーデータ等を消去しない運用について述べる。実施例１で説明したディスク復元機能は、端末起動時にライトキャッシュである差分イメージを初期化することにより行っていた。そのため、端末を再起動するとそのライトキャッシュにのみに含まれていたファイルなども全て失われてしまっていた。

しかし、２つのライトキャッシュ（差分データ）を用いた場合、再起動前の他方の差分データ「ｗｒｉｔｅｃａｃｈｅ０−１．ｖｈｄ」には再起動前の変更情報（例えば文書データなどのユーザーデータ）が残されているため、他方の差分データ「ｗｒｉｔｅｃａｃｈｅ０−２．ｖｈｄ」での起動中にその変更情報を同じ保存場所にコピーすれば、再起動後もユーザーデータを残す運用も可能である。このような構成で運用した場合、システムへの変更は再起動のたびに初期状態に復元される一方、ユーザーデータは消去されない。

このように、複数のライトキャッシュを設けると、管理ＯＳを不要にしたり、必要なデータを転送して保存したりすることができる運用も可能となる。

また、上記とは異なり、ユーザーが作成したファイルやユーザーによるシステム変更を可能な限り保持するために、通常の再起動時にはライトキャッシュの初期化を行わない構成を採用することもある。この構成はライトキャッシュの初期化処理をバージョンの更新時のみに限定することで容易に実現できる。しかし、マスターデータを更新した場合にはライトキャッシュの初期化が必須となってしまうが、この場合においても同様に「マスターデータ更新前のライトキャッシュの情報」を参照して「マスターデータ更新後のライトキャッシュ」に変更情報を同じ保存場所にコピーすることで、「システム部分の更新」を行いつつユーザーデータを継続して保持する構成をとることもできる。さらには、もっと単純に、「ユーザーデータは記憶装置の別領域（別ドライブ）」に保持するように構成も実現できる。

−実施例３（復元ポイントを複数作成する例）−
図２（Ｃ）は、実施例３の動作を示す概念図である。
差分データは、互いに依存関係を維持した状態で複数の階層を作成することができる。例えば、図２（Ｃ）に示すように、初期状態であるマスターデータ「０．ｖｈｄ」に対する差分データ「１．ｖｈｄ」が作成された場合、この差分データはそのベースとなった「０．ｖｈｄ」に依存している。この状態で、差分データ「１．ｖｈｄ」に対する差分データ「２．ｖｈｄ」が作成された場合、２つ目の差分データ「２．ｖｈｄ」は、そのベースとなった「１．ｖｈｄ」に依存しているだけでなく、「０．ｖｈｄ」にも依存している。

ここで、差分データ「１．ｖｈｄ」を利用して端末を起動して起動すると、その際に「１．ｖｈｄ」が更新されてしまう。そして、「１．ｖｈｄ」が更新されると、「２．ｖｈｄ」と「１．ｖｈｄ」との依存関係が破綻し、以後「２．ｖｈｄ」で起動できなくなる。

そのため、「１．ｖｈｄ」の起動用に、「１．ｖｈｄ」のクローンとして差分データ「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」を作成し、これで起動することにより、差分データ「１．ｖｈｄ」が更新されないようにする。こうすれば、差分データ「１．ｖｈｄ」と同等の内容で起動しつつ、「２．ｖｈｄ」と「１．ｖｈｄ」の依存関係を維持することができる。

（第３の実施形態）−多数の端末の初期イメージ設定手順例−
１つのマスターデータを多数の端末の起動ディスクにコピーして、「ローカルブート」する場合でも、ＩＰアドレスやホスト名など、端末ごとに「個別設定」を行う必要がある。ネットワークブートシステムの場合、端末の起動を速やかに行う必要があるため「ホスト名等の動的設定」が用いられる場合が多い。ホスト名等の動的設定は、起動時に設定が完了し、再起動も不要という点で優れている反面、全ての端末が同一のハードウェア構成であることを前提とし、ハードウェア構成の相違点を吸収することができないという欠点がある。各端末のハードウェア構成が必ずしも同一構成でない場合には、起動時にＯＳのカーネルに読み込まれるべきデバイスドライバが、端末ごとに異なってくる。

以下、新規に導入された複数の端末の起動ディスクの内容を統一する手順を示す。端末のハードウェア構成はそれぞれ異なる可能性があるため、配信されるＯＳイメージデータは「ＯＯＢＥ（Ｏｕｔ Ｏｆ Ｂｏｘ Ｅｘｐｅｒｉｅｎｃｅ）状態」と呼ばれるＯＳイメージデータを用いる。ＯＯＢＥ状態とは、「端末に依存しない状態」、換言すれば、「想定される全てのデバイスドライバを含んだ状態」をいう。ＯＯＢＥ状態のＯＳイメージデータをマスターデータとして、そのコピーを各端末の起動ディスクに配備すれば、最初の起動時にそれぞれの端末に必要なデバイスドライバが読み込まれ、かつ端末ごとの固有設定を各端末の記憶装置内に保持するので、ハードウェア構成の相違点を吸収することができる。

まず初めに、ＤＶＤやＵＳＢストレージデバイスなどのリムーバブル記録メディアによる起動やネットワークブートを利用した起動など、いずれかの方法により、まず初期化用ＯＳを起動する。次に、端末の起動ディスクにＯＯＢＥ状態のＯＳイメージデータであるマスターデータ「０．ｖｈｄ」をコピーする。また、同様に管理用ＯＳも導入する。

次に、端末ごとの個別設定を行う。個別設定を行う方法として、ハードウェアの再検出を行うツールが用意されている。例えば、Ｗｉｎｄｏｗｓ（登録商標）であれば、「ｍｉｎｉ−Ｓｅｔｕｐ」処理により行うことができる。ｍｉｎｉ−Ｓｅｔｕｐ処理は、端末にＩＰアドレスやホスト名及びドメイン参加の有無などのネットワーク接続情報を登録すると共に、端末に接続されていて未だＯＳのカーネルに登録されていないデバイスドライバを読み込むためにハードウェア情報の検出を開始する処理である。この処理を実行することでハードウェアの相違点をある程度吸収して端末のハードウェア構成に合わせた再設定、すなわち端末の個別設定が可能となる。

図３（Ａ）及び図３（Ｂ）は、第３の実施形態で説明する端末の個別設定の手順を示す概念図である。まず、図３（Ａ）に示すように、端末の起動ディスクにＯＯＢＥ状態のマスターデータ「０．ｖｈｄ」のコピーを配備する。次に、マスターデータが更新されないように、第１のライトキャッシュを準備する。具体的には、「０．ｖｈｄ」に対する差分データ 「ｍｉｎｉｓｅｔｕｐ０ａ．ｖｈｄ」 を作成する。この差分データにより端末を起動した後、直ちにｍｉｎｉ−Ｓｅｔｕｐを実行する（ステップＳ１）。

ｍｉｎｉ−Ｓｅｔｕｐ終了後、端末を一旦シャットダウンし、次に、図３（Ｂ）に示すように、第２のライトキャッシュを準備する。具体的には、先ほどの「ｍｉｎｉｓｅｔｕｐ０ａ．ｖｈｄ」に対する差分データ「ｗｒｉｔｅｃａｃｈｅ０ａ．ｖｈｄ」を作成し、そのイメージで端末を起動する（ステップＳ２）。プログラムを用いてステップＳ１からステップＳ２への手順を自動実行するように設定してもよい。

このような手順を経ることで、次に起動した際には ｍｉｎｉ−Ｓｅｔｕｐが完了した状態で起動することができる。その後、第２のライトキャッシュである差分データ「ｗｒｉｔｅｃａｃｈｅ０ａ．ｖｈｄ」を初期化することで、以後この端末では毎回 ｍｉｎｉ−Ｓｅｔｕｐ直後の状態から起動するようになる。

さらには、従来型のディスク配信機構を用いた場合には、ｍｉｎｉ−Ｓｅｔｕｐの実行に失敗することが多いことが知られている。この理由は、ｍｉｎｉ−Ｓｅｔｕｐ処理の実行時には、ドメイン参加 や ファイルサーバーのマウントなどのためにサーバーとの通信を行うことがよくあり、その際に「ネットワークに接続されていない」、あるいは「多数の端末を一斉に初期化することで、サーバーが過負荷となりタイムアウトする」といった不具合が頻繁に生じるためである。例えば、１００台の端末に対して一斉に初期化処理を実施すると、少なくとも２−３台はｍｉｎｉ−Ｓｅｔｕｐ処理に失敗することが経験的に知られている。

しかし、この手順の場合、万一ｍｉｎｉ−Ｓｅｔｕｐの実行に失敗した場合でも、再度「ｍｉｎｉｓｅｔｕｐ０ａ．ｖｈｄ」を作り直すだけで「０．ｖｈｄ」などを再度コピーする必要なく、ＯＯＢＥ状態のマスターデータ「０．ｖｈｄ」の状態からｍｉｎｉ−Ｓｅｔｕｐを再度実行することにより、確実にｍｉｎｉ−Ｓｅｔｕｐの実行に成功する。

なお、ここで述べた一連の方針であれば、１つのイメージを多数の端末に配信することもできる上に、端末ごとにハードウェア構成が異なる場合にも、統一されたイメージを配信して利用することができる。

ただし、この方法では、ディスクイメージ 「０．ｖｈｄ」を更新した際には一般にディスクイメージのサイズが大きいと考えられる「０．ｖｈｄ」を多数の端末に転送することが必要になる。

（第４の実施形態）−マスターデータの更新と配信−
本実施形態では、説明を簡単にするため、端末の台数が２台（端末Ａ、端末Ｂ）であり、このうち１台（端末Ａ）を、マスターサーバーとしても機能させることを想定して、マスターデータの更新と他の端末への配信手順について説明する。

［マスターデータの更新］
図４（Ａ）及び図４（Ｂ）は、いずれも、第４の実施形態における端末Ａ及び端末Ｂの仮想ディスク構成をそれぞれ示している。
端末Ａには、ＯＳイメージデータであるマスターデータ「０．ｖｈｄ」と、マスターデータに対する第１の差分データ「１．ｖｈｄ」とが存在している状態で、ライトキャッシュとして第１の差分データ「１．ｖｈｄ」に対する差分データ「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」を作成し、これにより端末Ａを起動させる。

端末Ａにおいてアプリケーションのインストールなどを行うと、その作業によるＯＳイメージデータに対する変更点はライトキャッシュである差分データ「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」に記録される。その後、端末Ａをシャットダウンすると、その段階での「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」の内容が他の端末に配信すべき「更新データ」となっている。ここで、管理用ＯＳで端末を起動するなどして「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」から「２．ｖｈｄ」にリネームする。さらに、次に端末Ａを起動する際に備えて先ほどリネームした「２．ｖｈｄ」に対する差分データ「ｗｒｉｔｅｃａｃｈｅ２ａ．ｖｈｄ」を作成しておく。

図５（Ａ）は、端末Ａに別途仮想ディスクとして用意したマスターデータ「ｍａｎａｇｅ．ｖｈｄ」を用いて管理用ＯＳを起動している様子を表すと共に、管理用ＯＳの稼働中に端末Ａのマスターデータの更新データをリネームし、さらにライトキャッシュである「ｗｒｉｔｅｃａｃｈｅ２ａ．ｖｈｄ」を作成した様子を示している。

［ＯＳイメージデータの配信］
管理用ＯＳで起動している図５（Ａ）の状態から、ライトキャッシュ「ｗｒｉｔｅｃａｃｈｅ２ａ．ｖｈｄ」によって端末Ａを再起動する。図５（Ｂ）は、ライトキャッシュ「ｗｒｉｔｅｃａｃｈｅ２ａ．ｖｈｄ」によって端末Ａを起動している様子を表している。この状態で、端末Ａから端末Ｂに「２．ｖｈｄ」をコピーする。いま仮に、端末Ａ上の「１．ｖｈｄ」と端末Ｂ上の「１．ｖｈｄ」とが同一であるなら、端末Ｂにコピーされた「２．ｖｈｄ」は、端末Ｂ上の「１．ｖｈｄ」からの差分ともなる。このコピー作業は端末Ｂが「ｗｒｉｔｅｃａｃｈｅ１ｂ．ｖｈｄ」での稼働中（図４（Ｂ）参照）に行うことができる。そのため、コピー転送時に利用するデバイスやメディアやプロトコルの自由度は高く、既に説明した各種の配信効率の高い配信手段等を用いることができる。もちろん、端末Ａから端末Ｂに直接転送する代わりに、何らかのサーバーや他の端末を中継するように構成することもできる。

図６（Ａ）は、端末Ｂに「２．ｖｈｄ」のコピーが終わった状態を示している。この段階においては、端末Ｂは「ｗｒｉｔｅｃａｃｈｅ１ｂ．ｖｈｄ」で起動されている。この状態で、次回の起動を更新されたマスターデータの差分データ「２．ｖｈｄ」によって行うように設定すれば更新が反映するが、そうすると、「２．ｖｈｄ」に書き込みされてしまう。そこで、図６（Ｂ）に示すように、「２．ｖｈｄ」では起動せず、「２．ｖｈｄ」に対する差分データ「ｗｒｉｔｅｃａｃｈｅ２ｂ．ｖｈｄ」を作成する。この差分データ「ｗｒｉｔｅｃａｃｈｅ２ｂ．ｖｈｄ」はもちろんライトキャッシュとして機能する。

その後、ライトキャッシュ「ｗｒｉｔｅｃａｃｈｅ２ｂ．ｖｈｄ」に対して「ＩＰアドレス、ホスト名」などの必要な設定情報の変更を行う。もし、実装上の都合で「ｗｒｉｔｅｃａｃｈｅ１ｂ．ｖｈｄ」が起動中に「ｗｒｉｔｅｃａｃｈｅ２ｂ．ｖｈｄ」の内容を書き換えることができない場合には、再起動を介して管理用ＯＳにより書き換えるように構成してもよい。また、ホスト名やＩＰアドレスを端末起動時に動的設定されるように構成している場合には、この「ｗｒｉｔｅｃａｃｈｅ２ｂ．ｖｈｄ」を書き換える手順を省略することもできる。次に「ｗｒｉｔｅｃａｃｈｅ２ｂ．ｖｈｄ」で起動するように設定をして、端末を再起動すれば、端末Ｂは差分データ「２．ｖｈｄ」相当の状態で起動することになる。再起動後は「ｗｒｉｔｅｃａｃｈｅ１ｂ．ｖｈｄ」のファイルを削除することもできる。

［多数の端末への展開］
多数の端末がある場合には、同様の手順を繰り返すことで展開することができる。また、どのタイミングでコピー処理を行うか、また、どのタイミングで新たなバージョンを他の端末での利用を許可するかといった制御を自由に行うことができる。

（第５の実施形態）−運用例−
［配信用差分データの作成手順］
第３の実施形態では、図３を参照して、マスターデータとなるＯＳイメージデータを各端末に配信する手順を述べた。この手順では各端末においてｍｉｎｉ−Ｓｅｔｕｐを行った段階で各端末の状態は異なってしまうため、それ以降に生じたマスターデータの変更を差分データとして配信することはできなかった。一方、第４の実施形態では、図４〜図６を参照して、マスターサーバーとして機能する端末Ａにおいて生じた変更を他の端末にコピーする手順について述べた。この手順では、端末ごとの個別設定はＩＰアドレスとホスト名といった程度の内容しか行うことができず、第３の実施形態のように、ハードウェア構成が異なるような場合には利用できなかった。

そこで、本実施形態では、マスターサーバーとして機能する端末Ａにおいて生じた変更を、ハードウェア構成が異なる他の複数の端末に差分データとして配信する手順について述べる。

図７（Ａ）に示すように、まず、ＯＯＢＥ状態のＯＳイメージデータ「０．ｖｈｄ」をベースとして、端末Ａのハードウェア構成に適するようにｍｉｎｉ−Ｓｅｔｕｐした段階のイメージが「ｍｉｎｉｓｅｔｕｐ０ａ．ｖｈｄ」、それに対する差分データ「ｗｒｉｔｅｃａｃｈｅ０ａ．ｖｈｄ」（ライトキャッシュ）によって端末Ａが稼働している状態を想定する。

上記の状態で端末Ａにおいてアプリケーションのインストールなどを行うとその作業によるイメージに対する変更点はライトキャッシュとして機能する差分データ「ｗｒｉｔｅｃａｃｈｅ０ａ．ｖｈｄ」に記録される。

この状態で、ＯＳイメージデータをＯＯＢＥ状態に戻す処理を実行する。Ｗｉｎｄｏｗｓ（登録商標）の場合、「ｓｙｓｐｒｅｐ」処理がこれに相当する。ｓｙｓｐｒｅｐを実行すると、図７（Ｂ）に示すように、現在起動中のＯＳイメージデータ「ｗｒｉｔｅｃａｃｈｅ０ａ．ｖｈｄ」はＯＯＢＥ状態になる。ここで、次回起動時には「管理用ＯＳ」で起動するように設定しつつ端末Ａを再起動する。

図８に示すように、管理用ＯＳで起動した後、「ｗｒｉｔｅｃａｃｈｅ０ａ．ｖｈｄ」と「ｍｉｎｉｓｅｔｕｐ０ａ．ｖｈｄ」の内容とをマージして、「１．ｖｈｄ」というファイル名のファイルを作成する。このようにして得られた「１．ｖｈｄ」は、「ＯＯＢＥ状態」かつ「０．ｖｈｄに対する差分データ」となる。

次に、図９（Ａ）に示すように、この「１．ｖｈｄ」に対する差分データとして「ｍｉｎｉｓｅｔｕｐ１ａ．ｖｈｄ」を作成し、次回起動時には「ｍｉｎｉｓｅｔｕｐ１ａ．ｖｈｄ」で起動するように設定して再起動する。いま、「ｍｉｎｉｓｅｔｕｐ１ａ．ｖｈｄ」は、「１．ｖｈｄ」に対するライトキャッシュとなっている。

この状態で、ライトキャッシュである「ｍｉｎｉｓｅｔｕｐ１ａ．ｖｈｄ」で端末Ａを起動すると、直ちにｍｉｎｉ−Ｓｅｔｕｐが行われる。ｍｉｎｉ−Ｓｅｔｕｐが終わった段階で、次回起動時には再度管理用ＯＳで起動するように設定しつつ端末Ａを再起動する。

図９（Ａ）は、現在の端末Ａにおけるマスターデータとその差分データの関連を示している。差分データ「１．ｖｈｄ」は、ＯＯＢＥ状態のディスクイメージであるため、様々なハードウェアで起動できる。

図９（Ｂ）は、図９（Ａ）の状態から、さらに「ｍｉｎｉｓｅｔｕｐ１ａ．ｖｈｄ」に対する差分として「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」を作成した様子を示している。次回はこのディスクで起動するように構成してから端末を再起動する。

このように構成することで、端末Ａは新たなバージョン「１．ｖｈｄ」に相当する状態で起動することができる。

また、ライトキャッシュ「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」を初期化すれば、ｍｉｎｉ−Ｓｅｔｕｐした状態へのディスク復元機能を実現できる。

以上の手順により、異なるハードウェア構成の端末にも、ハードウェア構成の違いを吸収しつつ配信できる差分データが得られる。

［他の端末へのコピー]
次に、端末Ａで作成された差分データ「１．ｖｈｄ」を別の端末Ｂで利用するまでの手順を述べる。以下の例では、端末Ａはマスターデータの更新後の差分データ「１．ｖｈｄ」を端末Ａに適するようにｍｉｎｉ−Ｓｅｔｕｐした状態で動作しており、端末Ｂは更新前のＯＳイメージデータ（マスターデータのコピー）「０．ｖｈｄ」を端末Ｂに適するようにｍｉｎｉ−Ｓｅｔｕｐした状態で動作している。

まず、端末Ａから端末Ｂに差分データ「１．ｖｈｄ」をコピーする。このコピー作業は端末Ｂが「ｗｒｉｔｅｃａｃｈｅ０ｂ．ｖｈｄ」での稼働中に行うことができる。そのため、転送時に利用するデバイスやメディアやプロトコルの自由度は非常に高く、既に説明した各種の配信効率の高い配信手段等を用いることができる。しかも、「１．ｖｈｄ」はマスターデータ「０．ｖｈｄ」に対する差分データでもあるため、マスターデータ「０．ｖｈｄ」よりもデータサイズが小さい。そのため、ディスクイメージ全体をコピーする場合と比較して、転送時間を大幅に短縮できる利点がある。

もちろん、端末Ａから端末Ｂに直接転送する代わりに、何らかのサーバーを中継するように構成することもできる。

さらに、端末Ａ上のマスターデータ「０.ｖｈｄ」と端末Ｂ上にコピーされた「０.ｖｈｄ」との内容は同一であるため、端末Ｂに転送された差分データ「１．ｖｈｄ」は、端末Ｂ上の「０．ｖｈｄ」からの差分ともなる。そのため、端末Ｂに「１．ｖｈｄ」への転送が終わると端末Ｂの仮想ディスクは図１０（Ａ）に示す状態になる。

次に、転送が終わった後に端末Ｂにおいて差分データ「１．ｖｈｄ」を利用するまでの手順を述べる。端末Ｂは自発的に、又はサーバーからの指示を受けて、あるいは端末Ｂを利用するユーザーからの指示を受けて、差分データ「１．ｖｈｄ」の初期化作業を開始する。まず、端末Ａをシャットダウンする際に次回起動時には管理用ＯＳで起動するように設定して再起動する。図１０（Ｂ）は端末Ｂが管理用ＯＳで再起動した状態を示している。

端末Ｂが管理用ＯＳで再起動した後、まず差分データ「１．ｖｈｄ」に対する差分データとして「ｍｉｎｉｓｅｔｕｐ１ｂ．ｖｈｄ」を作成する（図１１（Ａ））。この時点で「ｍｉｎｉｓｅｔｕｐ１ｂ．ｖｈｄ」は「１．ｖｈｄ」からの差分データを保持していないため、「ｍｉｎｉｓｅｔｕｐ１ｂ．ｖｈｄ」は「１．ｖｈｄ」と同等の内容を意味する。この「１．ｖｈｄ」の中には、ｍｉｎｉ−Ｓｅｔｕｐ時の設定内容を指示するファイル(ｕｎａｔｔｅｎｄｅｄ．ｘｍｌ)が含まれている。このファイルを適宜適切に設定することで、「ＩＰアドレス」「ホスト名」「ドメイン参加」などを含む様々な設定を行うことができる。サーバーと通信を行い、適切なｕｎａｔｔｅｎｄｅｄ．ｘｍｌファイルを取得することもできる。また、ｕｎａｔｔｅｎｄ．ｘｍｌによらず、ファイルやレジストリなど、ディスクイメージの内容を書き換えることで、端末ごとの個別設定を行うこともできる。

その後、「ｍｉｎｉｓｅｔｕｐ１ｂ．ｖｈｄ」で端末が起動するように設定を行った上で端末を再起動するとｍｉｎｉ−Ｓｅｔｕｐが実行される（図１１（Ｂ））。「ｍｉｎｉｓｅｔｕｐ１ｂ．ｖｈｄ」で起動した端末Ｂは、所定のセットアップ処理（ｍｉｎｉ−Ｓｅｔｕｐ)を実行する。また、この段階において端末ごとの個別設定をさらに行ってもよい。その後、「ｍｉｎｉｓｅｔｕｐ１ｂ．ｖｈｄ」に対する差分データ「ｗｒｉｔｅｃａｃｈｅ１ｂ．ｖｈｄ」（ライトキャッシュ）を作成し、端末Ｂをそのイメージで起動するように設定した後に再起動する（図１２）。

この手順をとることで、端末Ｂも端末Ａで作成された差分データのコピー「１．ｖｈｄ」をベースとして端末の個別化処理（ｍｉｎｉ−Ｓｅｔｕｐ）を行いつつ起動できる。さらには、この段階においてもライトキャッシュ「ｗｒｉｔｅｃａｃｈｅ０ｂ．ｖｈｄ」の内容を参照することができるので、更新前の仮想ディスク「ｗｒｉｔｅｃａｃｈｅ０ｂ．ｖｈｄ」に含まれているユーザーデータ等を、更新後の仮想ディスク「ｗｒｉｔｅｃａｃｈｅ１ｂ．ｖｈｄ」に複製するように構成してもよい。

ここまでの手順が終わった段階にて「ｍｉｎｉｓｅｔｕｐ０ｂ」と「ｗｒｉｔｅｃａｃｈｅ０ｂ．ｖｈｄ」とはこの先不要となるので、適切なタイミングに削除してもよい。

また、ここに述べた一連の手順は「２．ｖｈｄ」、「３．ｖｈｄ」など新たなイメージが作成された場合にも繰り返し適用できる。その際にも、端末間で転送されるのは各バージョンごとの差分となるため、転送量は少なくなる。

なお、多数の端末がある場合には、同様の手順を繰り返すことで展開することができる。また、どのタイミングでコピー処理を行うか、また、どのタイミングで新たなバージョンを他の端末での利用を許可するかといった制御を自由に行うことができる。

（第６の実施形態）−ハードウェア混在環境での運用−
本実施形態では、ハードウェア構成が異なる複数の端末とハードウェア構成が同一である複数の端末とが混在した環境での運用について述べる。このような場合、これらのそれぞれの環境に合わせて２つのディスクイメージを準備することでも運用は可能ではある。しかし、そうするとマスターディスクが２つとなり、それぞれを管理する必要が生じてしまう。

本実施形態では、「ハードウェア構成が異なる複数の端末」と「ハードウェア構成が同一である複数の端末」とが混在した環境であっても、マスターディスク１つで運用する手順について述べる。

まず、端末Ａがマスターサーバーであり、端末Ａで、マスターデータの更新が繰り返されるとする。また、端末Ｂは端末Ａとハードウェア構成が同一で端末であり、端末Ｃは端末Ａとハードウェア構成が異なる端末である場合を想定する。

図４は、端末Ａ及び端末Ｂの仮想ディスク構成を表している。ベースとなっている端末Ａ及びＢの「０．ｖｈｄ」と「１．ｖｈｄ」のデータは、いずれも同一である。いま、それぞれの端末はライトキャッシュとして機能させるため、「１．ｖｈｄ」に対する差分データ「ｗｒｉｔｅｃａｃｈｅ１ａ．ｖｈｄ」及び「ｗｒｉｔｅｃａｃｈｅ１ｂ．ｖｈｄ」によってそれぞれ起動している。

ここで、新たに「２．ｖｈｄ」を作成したり、マスターサーバー（端末Ａ）から端末Ｂへの配信する手順については、第４の実施形態において図５及び図６を参照して説明したとおりである。

図１３（Ａ）及び図１３（Ｂ）は、端末Ａから「２．ｖｈｄ」を端末Ｂに配信し、端末Ｂを起動した直後の端末Ａ及び端末Ｂの仮想ディスクの状態をそれぞれ示している。それぞれの端末は、いずれもライトキャッシュである差分データ「ｗｒｉｔｅｃａｃｈｅ２ａ．ｖｈｄ」、「ｗｒｉｔｅｃａｃｈｅ２ｂ．ｖｈｄ」で起動している。

ここでさらに、端末Ａにおいて「２．ｖｈｄ」に依存した差分ディスク「ｓｙｓｐｒｅｐ２．ｖｈｄ」を作成し、そのディスクで端末Ａを起動する(図１４（Ａ））。その後、端末Ａにおいてｓｙｓｐｒｅｐ処理を実施してから端末Ａをシャットダウンする。その際、次回起動時には「ｗｒｉｔｅｃａｃｈｅ２ａ．ｖｈｄ」で起動するように設定しつつ端末Ａを再起動する。図１４（Ｂ）は、この再起動後の端末Ａの仮想ディスクの状態を示している。なお、この処理は、端末Ａにおいて「２．ｖｈｄ」を作成する際に一連の処理として行うこともできる。

一方、図１５（Ａ）は、端末Ｃの仮想ディスク構成を示している。端末Ｃは、端末Ａや端末Ｂ用のハードウェアに適合したＯＳイメージデータ「０．ｖｈｄ」や「１．ｖｈｄ」が配備されている。端末Ｃは、マスターデータである「０．ｖｈｄ＋１．ｖｈｄ」で起動することはできないため、そこからｓｙｓｐｒｅｐ処理を行った後、ｍｉｎｉ−Ｓｅｔｕｐ処理を行うことで個別化処理が行われ、現在は個別化処理が完了したＯＳイメージデータ「ｍｉｎｉｓｅｔｕｐ１ｃ．ｖｈｄ」のライトキャッシュ「ｗｒｉｔｅｃａｃｈｅ１ｃ．ｖｈｄ」で起動している。

この状態で、端末Ａから、「２．ｖｈｄ」及び「ｓｙｓｐｒｅｐ２．ｖｈｄ」を端末Ｃに配信する。ここで、「２．ｖｈｄ」は「１．ｖｈｄ」に対する差分データであるため、端末Ｃは、図１６に示すような仮想ディスク構成となる。

端末Ｃは、ハードウェア構成が異なる端末Ａや端末Ｂ用のＯＳイメージ系列である「０．ｖｈｄ」及びその差分データ「１．ｖｈｄ」を保持している状態で、「１．ｖｈｄ」に対する差分データをマスターサーバー（端末Ａ）から受け取ることになる。

このあと端末Ｃで「ｍｉｎｉｓｅｔｕｐ２ｃ．ｖｈｄ」を「ｓｙｓｐｒｅｐ２．ｖｈｄ」に対する差分として作成しつつ、そのディスクで起動するように設定し、第５の実施形態で説明した手順により処理をすると、図１７に示すような状態となり、２．ｖｈｄ相当のディスクで端末Ｃが起動できる状態となる。

以上のような手順を繰り返すことで、ｓｙｓｐｒｅｐを使わずに構成された「０．ｖｈｄ」、「１．ｖｈｄ」、「２．ｖｈｄ」、・・・ の列をベースにして、ハードウェア構成が異なるためｓｙｓｐｒｅｐを要する他の端末でも同じディスクを利用できる。

（その他の実施形態）
上述の実施形態では、差分管理機構としてＷｉｎｄｏｗｓ（登録商標）で用いられる仮想マシン用のＶＨＤファイル形式を用いて説明したが、差分管理機構を提供できるシステムであれば、どのようなものでも構わない。例えば、ＺＦＳファイルシステムなどのコピー・オン・ライト方式のファイルシステムを端末の起動ディスクとしてマウントする場合や、他の仮想マシンプログラムのスナップショット機能を用いてもよい。

１０ マスターサーバー
１３ スイッチングハブ
１５ アクセスポイント
２０ 複数の端末（２０ａ，２０ｂ，・・・）
３０ 無線ＬＡＮ

Claims (8)

1. 少なくとも１台のマスターサーバーと、複数の端末とがネットワークを介して接続され、前記マスターサーバーが管理するＯＳイメージデータ、又はＯＳイメージデータ及びそれに対する１つ又は複数の差分データを、マスターデータとして、そのコピー又は所定のディスクフォーマット形式に変換されたデータが前記端末のブートイメージとして配備され、
   前記端末が稼動している状態で、前記端末が更新前のマスターデータとの差分データを前記ネットワークを介して前記マスターサーバーから受け取り、前記端末が再起動することにより前記端末の前記ブートイメージが更新されると共に、
   前記端末は、前記端末のホスト名及びＩＰアドレスを含む各端末の固有データ及び各端末への書き込みデータ、デバイスドライバの構成情報の少なくともいずれかを前記ブートイメージに対する差分データとして保持する差分管理機構を具備する
   ディスク配信システムにおいて、
   前記更新前のマスターデータとの差分データは、
   それ自体がＯＯＢＥ（Ｏｕｔ−Ｏｆ−Ｂｏｘ Ｅｘｐｅｒｉｅｎｃｅ）状態のＯＳイメージデータであって、
   前記ブートイメージに対して端末ごとの個別化が完了するまでの差分データと、
   前記個別化が完了したＯＳイメージデータを再びＯＯＢＥ状態へ戻すための差分データと、を含むと共に、
   前記更新前のマスターデータとの差分データと、前記ブートイメージに対する差分データと、の両方のデータを前記ブートイメージが更新された後も前記各端末が保持し続けることを特徴とするディスク配信システム。
2. 前記端末が端末用オペレーティングシステムが最初に起動する際に又は起動後必要に応じて必要なデバイスドライバが前記端末用オペレーティングシステムのカーネルに読み込まれると共に、
   デバイスドライバの読み込みが完了した状態に相当する最新のＯＳイメージデータをＯＯＢＥ状態に対する差分データとして保持することを特徴とする請求項１記載のディスク配信システム。
3. 前記端末は、１つ又は複数のライトキャッシュを具備することを特徴とする請求項１又は２記載のディスク配信システム。
4. 前記端末は、前記ブートイメージ又は差分データを扱うために用いられる管理用ＯＳを具備することを特徴とする請求項１又は２記載のディスク配信システム。
5. 前記端末は、マスターサーバーからネットワークを介してマスターデータ及び前記マスターデータに対する差分データのコピーを受け取り、前記端末の起動ディスクを初期化する機能を具備することを特徴とする請求項１又は２記載のディスク配信システム。
6. 前記複数の端末のうちの１台が、マスターサーバーとしても機能することを特徴とする請求項１又は２記載のディスク配信システム。
7. 前記マスターサーバーは、異なるハードウェア構成の端末に対して、ＯＯＢＥ状態のＯＳイメージに変換するための差分データを配信することを特徴とする請求項１又は２記載のディスク配信システム。
8. 前記端末は、前記マスターサーバーからハードウェア構成の異なる他の端末用のＯＳイメージデータを受け取ると共に、前記受け取ったＯＳイメージデータをＯＯＢＥ状態のＯＳイメージデータに変換するための差分データを受け取り、それらを用いて端末を起動することを特徴とする請求項７記載のディスク配信システム。

Images