JP4808275B2 - ネットワークブートシステム - Google Patents

Description

本発明は、ネットワークを介してオペレーティングシステムを起動するシステムに関するものである。

近年、ネットワークを介してオペレーティングシステム（以下、「ＯＳ」という。）を起動するシステム（以下、「ネットワークブートシステム」という。）が注目されている。このシステムは、少なくとも１台のネットワークブートサーバ（Ｉ／Ｏサーバ）と複数台のクライアント端末とがネットワークを介して接続されたものである。システム構成にはいくつかの種類があるが、最も一般的な構成は、クライアント端末で動作するＯＳやアプリケーションソフトなどの全てのプログラム及びデータをサーバ側の記憶装置（ハードディスク等）にイメージデータとして保存し、クライアント端末を起動するとネットワークを介してクライアント端末上にＯＳが読み込まれるというものである。

ネットワークブートシステムはサーバ側の記憶装置を複数のクライアント端末で共有する仕組みを持つことによって、クライアント端末がディスクレスすなわちハードディスクを持つ必要が無くなり、クライアント端末のＯＳを含む全てのデータをサーバ側で集中管理することができる利点がある。そのため、多くのクライアント端末が稼働するシステムに適している。

また、ＯＳやアプリケーションソフトを各クライアント端末側のＣＰＵと物理メモリで実行するため、クライアント端末の性能を最大限に発揮してサーバの負荷を最小限に抑えられる利点もある。

このシステムは、ｎ台のクライアントが同時にサーバにアクセスした場合、サーバの処理能力は単純に１／ｎに低下するが、通常の使用時には個々のクライアント端末で発生する負荷が時間的に分散するのでそれほど深刻な問題とはならない。そのため、同時に使用するクライアント端末の数が増大しても、通常の使用時には、自身でオペレーティングシステムを起動する通常の（ネットワークブートではない）コンピューターシステムなどと比較しても全く遜色のない性能を発揮できる。なお、本発明の背景技術に関する文献として、下記特許文献１などが存在している。

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

ところが、本件発明者たちは、あるＯＳの起動時のトラフィックを測定したところ、１２０Ｍｂｐｓ程度であるとの結果を得た。これによると、サーバ側のネットワークの通信速度は現状のところ最大でも１Ｇｂｐｓ程度であるので、クライアント端末８台（１Ｇｂｐｓ÷１２０Ｍｂｐｓ）が性能維持の限界であると見積もられる。すなわち、ネットワークブートシステムにおいては「多数のクライアント端末が一斉に起動する」というケースを想定した場合、一般に考えられているよりも深刻な性能の低下が起こることになる。

本発明は、上記の知見に基づいてなされたものであり、サーバへのネットワークアクセスを大幅に軽減することを可能にする新規な仕組みを提供することを技術的課題とする。

本発明に係るネットワークブートシステムは、クライアント端末上で動作するオペレーティングシステムを提供するネットワークブートサーバと、物理的な記憶装置を備えたクライアント端末とがネットワークを通じて接続され、前記クライアント端末は、前記オペレーティングシステム起動中に必要なデータを一時的に保存することができる物理メモリと、前記ネットワークを介して前記サーバにアクセスするためのネットワークインターフェースとを備えていると共に、前記オペレーティングシステムは、前記ネットワークインターフェースを駆動するためのネットワークドライバと、前記クライアント端末のローカルバスに対するアクセスを前記ネットワークに対するアクセスに変換するためのフィルタドライバと、前記記憶装置を駆動するためのリードキャッシュドライバを備えており、前記リードキャッシュドライバが、前記フィルタドライバによって前記サーバから読み出されたデータを前記記憶装置に読み出しキャッシュすることを特徴とする。

このシステムにおいて、サーバ上のデータは通常イメージデータとして保存されているが、ここで「読み出しキャッシュ」とは「読み出し専用のキャッシュ」、つまり、上記イメージデータに一切変更が加えられていないコピーをクライアント端末の記憶装置内にキャッシュすることを意味する。このシステムによると、上記「読み出しキャッシュ」がＯＳ及びその上で動作するアプリケーションソフトに対して極めて効果的に機能するため、読み取りについてはローカルディスクと同等以上の速度が得られ、また、起動速度が大幅に改善する。さらに、クライアント端末の２回目以降の起動処理の際にサーバへのネットワークアクセスが殆ど発生しなくなり、これら結果として一台のサーバに接続できるクライアント端末を従来よりも飛躍的に増大することができる。

このシステムにおける前記クライアント端末は、前記リードキャッシュドライバが前記サーバから読み出されたデータが書き込み済であるか否かを判別するための管理フラグを前記物理メモリに保持すると共に、前記記憶装置は、前記サーバから受け取ったデータを保持するための読み出しキャッシュ領域を備えることが好ましい。書き込み済であるかを判別する方法にはいくつかの方法が考えられるが、クライアント端末の物理メモリに管理フラグを設ける方法が最も簡便でかつ高速だからである。なお、単に「管理フラグ」という場合は、サーバから読み出そうとする領域に書き込みが行われた否かを判別するための「書き込み管理フラグ」と、サーバから読み出されたデータが前記物理的な記憶装置に書き込み済みであるか否かを判別するための「読み込み管理フラグ」の２つがある。

ただし、物理メモリはクライアント端末のＯＳを終了するとその内容が消去されてしまうため、２回目以降の起動の際に読み出しキャッシュ領域に保持されたデータを利用するために、管理フラグの少なくとも一部の内容を保存することが一層好ましい。そこで、前記記憶装置は、さらに、前記物理メモリに保持されている管理フラグの少なくとも一部を書き戻すためのキャッシュ管理領域を備えていることが好ましい。このようにすれば、ＯＳ再起動後もすでにサーバから読み出したデータについてはネットワークを介して再度取得する必要がなくなるからである。この記憶装置への書き戻し処理は、管理フラグのバックアップであるから、任意のタイミングで随時行ってよい。例えば、フィルタドライバに対する読み出しや書き込み処理と非同期に行っても構わない。なお、「管理フラグの少なくとも一部」とは、具体的には、「読み出し管理フラグ」のことを指している。

また、前記記憶装置は、前記物理メモリに記憶されているデータの一部を一時的に保存するためのスワップ領域や、前記サーバに対して書き込みを行ったデータを保存することが許容された書き込みキャッシュ領域や、前記オペレーティングシステム上で動作するアプリケーションソフトのワークエリアなどを備えていてもよい。本システムは、クライアント端末がローカルに記憶装置を持ち、そこに読み出しキャッシュする仕組みを提供するものであるが、その一部をこれらの用途に用いることでクライアント端末の操作環境が一層改善されるからである。

また、前記サーバは前記クライアント端末が用いるオペレーティングシステム、アプリケーションソフトその他のデータを保持するための仮想ディスクを具備し、前記仮想ディスクはその更新情報を保持するための領域を備えていると共に、前記仮想ディスクが更新された場合には、前記記憶装置にキャッシュされている全てのデータを使用しないように構成することが好ましい。本システムはサーバ側のイメージデータが更新されないことを前提として設計することができ、この場合、仮想ディスクの実体はサーバ側の記憶装置の一部であるのでサーバ側において、仮想ディスクの更新情報を管理しておくことが好都合だからである。

また、前記記憶装置は一部又は全部が暗号化されていることが好ましい。こうすると、クライアント端末側のハードディスク等をそのまま持ち去られてもデータの漏洩を防止できるからである。

本発明に係るネットワークブートシステムによれば、クライアント端末のローカルディスクがその一部に「読み出しキャッシュ」を備えるため、同じデータの２度目以降の読み出し時には、ネットワークアクセスが一切発生せず、サーバへのネットワークアクセスを劇的に減らすことができる。また、一部のクライアント端末側の物理ディスクに障害が発生した場合でも、同様の障害が他のクライアント端末においても同時に多発しない限り、サーバへのネットワークアクセスが急増することはなく、システム全体としてみた場合のパフォーマンスの問題も生じない。

図１（ａ）及び図１（ｂ）は、第１の実施形態のネットワークブートシステムの基本構成を説明するための概念図である。 図２は、このシステムにおけるディスクアクセスの関係を説明した図である。 図３（ａ）及び図３（ｂ）は、クライアント端末のディスク構成を示した図である。図３（ｃ） は 第１のパーティションＰ１に割り当てる機能の一例を説明する図である。 図４（ａ）は、「キャッシュ管理テーブル」を示している。図４（ｂ）は、キャッシュ管理テーブルの状態とその動作をまとめた一覧表を示す図である。 図５は第１の実施形態の変形例を示しており、読み出しキャッシュを主体しつつ、書き込みキャッシュを補助的に用いたこのシステムにおけるディスクアクセスの関係を説明した図である。 図６（ａ）及び図６（ｂ）は、いずれも一般的なコンピュータシステムにおけるディスクアクセスの関係を説明するための図である。

符号の説明

１０ サーバ（ネットワークブートサーバ）
１１ 物理ディスク（ハードディスク）
２０ クライアント端末
２１ ローカルディスク
２２ 仮想ディスク（Ｖｄｉｓｋ）
４０ クライアントＯＳ（又はアプリケーションソフト）
４６ フィルタドライバ
４８ ネットワークドライバ
５０ リードキャッシュドライバ

本明細書における用語の解釈は以下の通りとする。ただし、ここで定義しないものについては適宜文中において指摘する。
・「サーバ」とは、クライアント端末上で動作するオペレーティングシステムを提供する少なくとも１台のコンピューターを指すものとする。サーバはクライアント端末が使用するＯＳ、アプリケーションソフトその他のデータを含む仮想ディスクをイメージデータとして保存している。
・「仮想ディスク」とは、クライアント端末上のＯＳからネットワークを介して見えるイメージディスク（これを「Ｖｄｉｓｋ」と表記する場合がある。）を指し、その実体はネットワークを介して接続されるサーバ上の物理ディスクに保存されているデータの一部を指すものである。
・「ローカル」とは、ＬＡＮなどの外部ネットワークを介さずクライアント端末の内部バスに接続されたデバイスを意味する。
・「物理ディスク」とは、ローカルバスに接続された実体を伴うハードディスクその他の記憶手段を指し、「ローカルディスク」という場合もある。但し、ＯＳが認識できるかぎりハードディスクの種類（例えば、ＳＣＳＩディスクやＩＤＥディスクやＳＡＴＡなど）は問わない。また、ディスク状であるかを問題とせず、例えば半導体メモリーその他ハードディスクに代替する実現可能な記憶手段を全て含むものとする。
・「ユーザーデータなど」というときは、ユーザーがクライアント端末を操作することによってクライアント端末のＯＳ又はそのＯＳ上で動作するアプリケーションソフトが保存する全てのデータをいうものとする。
・特に明示せず単に「ＯＳ」という場合は、クライアント端末で動作するＯＳを意味するものとする。また、「ＯＳ側からの書き込み（又は読み出し）要求信号」という場合も、ＯＳ側で動作するアプリケーションソフトがフィルタドライバに向けて発する要求信号を含むものとする。

（ネットワークブートシステムの基本原理）
ここで、一般的なネットワークブートシステムの基本原理について簡単に説明する。図６（ａ）及び図６（ｂ）は、いずれも一般的なコンピュータシステムにおけるディスクアクセスの関係を説明するための図である。

図６（ａ）は、一般的なコンピュータシステムがローカルディスクにデータの読み出し及び書き込みを行う仕組みを説明した図である。クライアント端末上のＯＳ又はアプリケーションソフト１０１がローカルディスク１０３に対して読み出し及び書き込み要求信号送るとディスクドライバ１０２がこの要求信号に応じてローカルディスク１０３に対するデータの読み出し及び書き込みを制御する。

図６（ｂ）は、ネットワークブートシステムが仮想ディスク（Ｖｄｉｓｋ）にデータの読み出し及び書き込みを行う仕組みを説明した図である。ＯＳ或いはアプリケーションソフト１０４が仮想ディスク１０５に対して読み出し及び書き込み要求信号送るとディスクドライバの代わりにフィルタドライバ１０６が最初にこの要求信号を受け取り、これをネットワークドライバ１０７に転送し、図示しないネットワークインターフェースを介してサーバ上に実体があるディスクイメージ（仮想ディスク１０５）に対するデータの読み出し及び書き込みを制御する。

このように、各クライアント端末のフィルタドライバ１０６がローカルディスクへのアクセスをネットワークアクセスに変換することにより、クライアント端末のＣＰＵは、ローカルディスクにアクセスすることに代えて、サーバのディスクイメージにアクセスする。

ここで、「フィルタドライバ」とは、クライアント端末側のＯＳで動作するデバイスドライバの一種であり、その後段にネットワークドライバが設けられる。ネットワークドライバはネットワークインターフェース（イーサーネットカード等）を介してサーバ側の仮想ディスク（Ｖｄｉｓｋ）と通信し、受け取ったディスクアクセスのための要求信号に基づいてデータの授受を行う。すなわち、仮想ディスクが読み出し要求信号を受けた場合はクライアント端末側にデータを返し、書き込み要求信号を受けた場合は仮想ディスクに対してデータの書き込みを行う。

（第１の実施形態）
以下、本発明にネットワークブートシステムの第１の実施態様について図面を参照して詳述する。

［１］システムの全体構成
図１（ａ）及び図１（ｂ）は、第１の実施形態のネットワークブートシステムの基本構成を説明するための概念図である。図１（ａ）に示すように、このシステムは少なくとも１台のサーバ（ネットワークブートサーバ）１０と、複数台のクライアント端末２０（２０ａ，２０ｂ，・・・）とがネットワークを介して接続されている。また、図１（ｂ）に示すように、システムサーバ１０は物理ディスク（例えばハードディスク）１１を備えている。そのほか、システムサーバ１０は図示しないＣＰＵやメモリーなどサーバとしての基本的な構成を備えている。さらに、あるクライアント端末２０ａは、ローカルディスク２１ａを備えている。但し、システム全体の中の一部に「ローカルディスクを持たないクライアント端末」が含まれていても構わない。

サーバ１０の物理ディスク１１には、各クライアント端末２０（２０ａ，２０ｂ，・・・）ごとに対応するディスクイメージがそれぞれ格納されている。なお、全てのクライアント端末に共通のディスクイメージと各クライアント端末ごとの更新データを保持する場合が含まれる。このディスクイメージはネットワークを介してクライアント端末上のＯＳにマウントされ、クライアント端末上からは仮想ディスク２２（２２ａ，２２ｂ，・・・）がネットワークを介して接続されているように見える（図１（ｂ）参照）。

このように本発明の第１の実施形態では、クライアント端末が仮想ディスクとローカルディスクの両方を持つことになる。

図２は、このシステムにおけるディスクアクセスの関係を説明した図である。上述の通りこのシステムのクライアント端末はローカルディスク２１ａと仮想ディスク２２ａを各一つずつ持つ。このため、基本的な動作としては、ローカルディスク２１ａへのアクセスはディスクドライバによって図示しない内部バス（例えば、ＳＣＳＩバス或いはＩＤＥバス等）を経由して行われるのに対し、仮想ディスク２２ａへのアクセスはフィルタドライバ４６及びネットワークドライバ４８を介してネットワークを経由して行われる。

このシステムは、フィルタドライバ４６の前段に「リードキャッシュドライバ５０」を備えている。リードキャッシュドライバ５０はローカルディスク２１ａにおける特定のパーティションに割り当てられた読み出しキャッシュ領域Ｐ２に対するデータのアクセス（書き込み及び読み出し）を行う。このリードキャッシュドライバ５０はフィルタドライバ４６によってサーバから読み出されたデータをローカルディスクに読み出しキャッシュさせる働きをするが、その動作の詳細については「［４］システムの動作」において説明する。

［２］クライアント端末側ディスク構成
図３（ａ）及び図３（ｂ）は、クライアント端末側のディスク構成を示した図である。この図に示すように、クライアント端末は、ローカルディスク２１ａと仮想ディスク（Ｖｄｉｓｋ）２２ａとから構成される。

上述の通り、仮想ディスクは、クライアント端末からみるとネットワーク越しに見える論理ドライブ（ＯＳによってはこれを「ネットワークドライブ」という場合もある）と扱われ、ＯＳのシステムやユーザーデータなどをまるでユーザーのローカルディスクに保存するかのごとく、ネットワークを介してサーバ側のディスクイメージに保存することができる。一方、クライアント端末がもつ物理的なハードディスク（これを「ローカルディスク」とよぶ。）は内部バスに直接接続されている。

（１）物理ディスクの構成
図３（ａ）は物理ディスクの構成を説明するための図である。物理ディスクは、クライアント端末側に直接接続されたローカルディスクであって、この実施形態においては、少なくとも３つの領域（パーティション）に分けられている。
図３（ｃ）は、第１のパーティションＰ１に割り当てる機能の一例を説明するための図であり、以下の（ｉ）〜（ｉｉｉ）の各説明に対応するものである。なお、第１のパーティションＰ１はクライアント端末側のＯＳにとって論理ドライブ或いはファイルやディレクトリとして認識されるのに対して、第２及び第３のパーティションＰ２及びＰ３は論理ドライブ或いはファイルやディレクトリといったアプリケーションのレベルで認識されるものではなく、ローカルディスク上のセクタ或いはクラスタといった物理的なレベルで認識されるものにとどまる。

（ｉ）第１のパーティションＰ１
物理ディスクの第１のパーティションＰ１には、必要に応じて、クライアント端末側ＯＳの「スワップ領域」や、「書き込みキャッシュ」や「クライアント端末側で動作するアプリケーションソフトのワークエリア」などを割り当てることができる。なお、第１のパーティションＰ１は、本発明において必須のものではないが、これを設けるといずれもクライアント端末の処理能力が向上する利点がある。

ａ．スワップ領域
「スワップ」とはクライアント端末の物理メモリの不足分を補うためにローカルハードディスクの一部をメモリのように使用するＯＳの機能の一つである。スワップ動作とは、ハードディスク上に「スワップ領域」を用意して、メモリ容量が不足してきたら使われていないメモリ領域の内容を一時的にハードディスクに退避させ、必要に応じてメモリに書き戻す動作のことを言う。そうした機能を用いて確保された実際のメモリ容量以上のメモリ領域を「仮想メモリ」という。クライアント端末がディスクレスの場合、クライアント端末側にスワップ領域を設けることができないため、メモリからあふれたデータは全てサーバ側のスワップ領域に送られることになり、サーバのリソースを消費すると共にネットワークの負荷がかかる原因ともなっていた。しかし、本発明に係るネットワークブートシステムのクライアント端末はローカルディスクを備えているため、物理領域の一部にスワップ領域を確保できることとなる。このようにネットワークを介してサーバ側でスワップ動作することを回避できる利点は大きい。

ｂ．書き込みキャッシュ
クライアント端末側のＯＳ等４０から書き込み要求信号がフィルタドライバ４６に送られた場合、その書き込みデータをローカルディスクの物理領域にキャッシュする、いわゆる「書き込みキャッシュ」として用いることができる。なお、「書き込みキャッシュ」は「読み出しキャッシュ」としても用いることができる（但し、「読み出しキャッシュ」として読み出されるキャッシュデータはユーザーデータなどの書込みが行われた後のデータが含まれる。）。これにより、クライアント端末の更新情報（ユーザーデータなど）をクライアント端末側に保存できるため、ネットワーク負荷を軽減する利点がある。

ｃ．アプリケーションソフトのワークエリア
クライアント端末側で動作するアプリケーションソフトのワークエリアを割り当てることにより、ネットワーク負荷を軽減する利点がある。

（ｉｉ）第２のパーティションＰ２
物理ディスクの第２のパーティションＰ２には、「読み出しキャッシュ領域」が割り当てられる。この領域Ｐ２の使用方法については「［４］システムの動作」において説明するが、ここでは、この領域には書き込みが行われた後のデータを一切保存しないことが重要でありこの意味において「（ｉ）ｂ．書き込みキャッシュ」において説明したものとは技術的意義が全く異なるものである。

（ｉｉｉ）第３のパーティションＰ３
物理ディスクの第３のパーティションＰ３には、「キャッシュ管理領域」が割り当てられる。この領域Ｐ３の使用方法については後述の「［４］システムの動作」において説明する。

（２）仮想ディスクの構成
図３（ｂ）は、仮想ディスクの構成を示した図である。仮想ディスクはクライアント端末上のＯＳから認識されるものであるが、その実体はサーバ上のハードディスクの一部であって、この実施形態においては、全体が少なくとも２つの領域（パーティション）に分けられている。第１のパーティション（これを「Ｖ１」という。）は、クライアント端末側のＯＳによって認識される論理ドライブ（例えば、「Ｃドライブ」）となるが、第２のパーティション（これを「Ｖ２」という。）は、クライアント端末側のＯＳによって認識されない領域となる。第２のパーティションＶ２には、仮想ディスクの更新履歴情報などが記憶され、そして専用のツールによりサーバ上でディスクイメージ更新のたびごとにサーバ側のプログラムによって更新情報などが書き込まれる。

なお、更新履歴などの情報は極めてデータ量が小さいため、第２のパーティションＶ２の容量は、第１のパーティションＶ１の容量と比べて極めて小さくて良い。例えば、第１のパーティションが１５〜３０ＧＢであるとき、第２のパーティションは１ＭＢ程度とする。

以上をまとめると、この実施態様においてクライアント端末のユーザーがＯＳ上でその存在を確認できるのは、仮想ディスクの第１のパーティションＶ１に対応する論理ドライブ（例えば、Ｃドライブ）と、物理ディスクの第１のパーティションＰ１に対応する一部の論理ドライブとなる。

［３］サーバ側ディスク構成
サーバ側ディスクへのディスクイメージの格納方法には、シェアーモードとプライベートモードの２つがある。シェアーモードは、全てのクライアント端末に共通のディスクイメージ１つと各クライアントごとの書き込みデータ（これを「ライトバックキャッシュデータ」という。）を必要数分だけ保存する構成である。一方、プライベートモードはクライアント端末と同数のディスクイメージを保存する構成である。前者はディスクの利用効率が高いなどの利点があり、後者はクライアントごとに異なるＯＳを提供したり、一つのクライアント端末で異なる動作環境を使い分けて使用できるなどの利点がある。

本発明に係るネットワークブートシステムは、クライアント端末側の設定を変更すればいずれのモードでも動作する。すなわち、サーバ側の構成は殆ど手を加える必要が無く、クライアント端末側の構成変更によって実現することができる。以下、システムの動作について説明する。

［４］システムの動作
（１）「リードキャッシュドライバ」の基本動作
はじめに、「リードキャッシュドライバ」の基本動作について説明する。図２において、「クライアントＯＳ（アプリケーション）」４０を起点として、ローカルディスク２１ａ及び仮想ディスク２２ａに向かう実線矢印は、読み出し又は書き込み要求信号（リクエスト信号）を意味している。この信号を受けた後、デバイスドライバはそれぞれのディスクと通信してデータの授受を行う。要求信号に隣接した一点鎖線の両矢印はデータ授受を表している。例えば、読み出し要求信号であればその後ディスク側からデータが読み出されてＯＳ側に送出され、逆に書き込み要求信号であればその後ＯＳ側からディスク側にデータが送出されディスクに書き込まれる。

リードキャッシュドライバとは、ローカルディスクの読み出しキャッシュ領域（Ｐ２）に対して「読み出しキャッシュ」を行うためのプログラムであって、その動作は以下の通りである。

（ｉ）読み出し要求信号の処理
クライアント端末側のＯＳ（又はアプリケーションソフト）４０が「読み出し要求信号」を送出した場合、リードキャッシュドライバ５０はフィルタドライバ４６よりも先にこの「読み出し要求信号」を受け取ることになる。この場合は、「キャッシュ管理テーブル」を用いて物理ディスクの第２のパーティションＰ２に割り当てられている「読み出しキャッシュ領域」に記憶されているデータが存在しているか否か及び存在している場合はそのデータが書き込み済であるかどうかを判断し、もし書き込み済でない場合には、直ちにその読み出しキャッシュデータをＯＳに返す。しかし、読み出しキャッシュデータが書き込み済である場合又は読み出しキャッシュデータが存在しない場合には、リードキャッシュドライバ５０は受け取った「読み出し要求信号」をそのまま後段のフィルタドライバ４６に送る。なお、フィルタドライバ４６が「読み出し要求信号」を受け取った場合は通常通りネットワークドライバ４８を通じてサーバ側からデータの読み出しを行う。

（ｉｉ）読み出しキャッシュデータの更新
上記（ｉ）の場合、最終的にはサーバ側から読み出したデータがフィルタドライバ４６及びリードキャッシュドライバ５０をこの順序で通過してＯＳ側４０に送出されることになる。その際、リードキャッシュドライバ５０は物理ディスクの第２のパーティションＰ２に割り当てられている「読み出しキャッシュ領域」にフィルタドライバ４６が読み取ったデータをコピーすると共に、物理メモリ上のキャッシュ管理テーブルのフラグを変更して読み出しキャッシュデータが読み出し済の状態であることを記憶する。

（ｉｉｉ）書き込み要求信号の処理
クライアント端末のＯＳ（又はアプリケーションソフト）４０が「書き込み要求信号」を送出した場合、リードキャッシュドライバ５０はフィルタドライバ４６よりも先にこの「書き込み要求信号」を受け取る。しかし、「書き込み要求信号」をリードキャッシュドライバ５０が受け取った場合には、リードキャッシュドライバは特に何もせずにこの「書き込み要求信号」をそのまま後段のフィルタドライバ４６に送る。なお、フィルタドライバ４６が「書き込み要求信号」を受け取った場合は通常通りネットワークドライバ４８を通じてサーバ側にデータの書き込みを行う。

（２）「キャッシュ管理テーブル」の仕組み
図４（ａ）は、「キャッシュ管理テーブル」を示している。キャッシュ管理テーブルは、ローカルディスク（物理ディスク）の読み取り単位ごとに２ビットの管理フラグを割り当て、以下に説明する２つの値（状態）を保持する。また、この管理フラグは物理メモリ上の非ページ領域（スワップ領域に退避されない領域）に確保する。

（ｉ）管理フラグ
「キャッシュ管理テーブル」は２つの管理フラグを用いて読み出しキャッシュデータの状態を記憶する。これらのフラグの初期状態はいずれも０とする。
ａ．読み出し管理フラグ（０又は１）
ｂ．書き込み管理フラグ（０又は１）

（ｉｉ）読み出しキャッシュデータが無い状態において、ＯＳからの読み出し信号に対する応答としてフィルタドライバが受け取ったデータをコピーした場合、読み出し済であることを記憶するため、読み出し管理フラグのデータを０から１に変更する。すなわち、読み出し管理フラグが１であれば、読み出しキャッシュデータが存在することを表す。しかし、これだけでは、読み出しキャッシュデータがその後書き込みが行われて内容が更新されたかどうかを判別することができない。

（ｉｉｉ）上述の通りフィルタドライバがＯＳから「書き込み要求信号」を受け取った場合には、リードキャッシュドライバは特に何もせずフィルタドライバにデータを送り、ネットワークインターフェースを介してサーバ側の仮想ディスクに書き込みを行う。この時、書き込み管理フラグの状態を０から１に変更する。すなわち、読み出し管理フラグが１であっても、書き込み管理フラグが１であるときは、その後に書き込み処理が行われているため読み出しキャッシュデータの内容が初期の状態から変更されているので、そのセクタに対する読み出し要求信号に対しては、以後読み出しキャッシュデータを一切使用してはならないことを意味する。書き込み管理フラグが１となった後は、クライアント端末側のＯＳをシャットダウンするときまでその状態が保持される。換言すれば、「書き込み要求信号」を一度でも受け取ったかどうかを調べることにより、「あるセクタにデータが書き込み済であるかどうか」を判別することができる。

図４（ｂ）は、キャッシュ管理テーブルの状態とその動作をまとめた一覧表を示す図である。状態Ｉは、読み出しキャッシュデータが存在しない場合であるから、データの読み出しについてはフィルタドライバ４６に委任することになるが、フィルタドライバ４６が受け取ったデータをＯＳ側４０に渡す際に読み出しキャッシュデータをコピーすると共に読み出し管理フラグの値を１に変更してキャッシュ管理テーブルを状態ＩＩに遷移させる。状態ＩＩは読み出しキャッシュが利用できる状態であり、読み出し要求信号に対して直ちに読み出しキャッシュデータの内容を応答する。状態ＩＩＩは、書き込み管理フラグに１がたっているため、キャッシュデータの状態が書き込み済であることを表している。従って、このセクタに保持されているキャッシュデータを以後使用してはならない。状態ＩＶはＯＳ起動後読み込み処理が一度も行われていないうちに書き込み要求信号が送られた場合を表す。この場合にも書き込み管理フラグに１が立っているためこのセクタに保持されているキャッシュデータを以後使用してはならない。なお、後述するように、管理フラグの状態は常に状態Ｉ→状態ＩＩ→状態ＩＩＩ又は状態I→状態IVと遷移する。

なお、「（２）（ｉ）ｂ．」において説明したように、物理ディスクの第１のパーティションＰ１に書き込みキャッシュを割り当てることによって、クライアント端末側のローカルディスクの一部に書き込み済データの保持を許容するキャッシュ領域を更に設け、これを書き込みキャッシュ（ライトキャッシュ）として利用してネットワーク負荷を軽減してもよい。ただし、この書き込みキャッシュ領域（Ｐ１）は、上述した「読み出しキャッシュ領域（Ｐ２）」とは異なる領域でなければならない。

（ｉｖ）キャッシュ管理テーブルのバックアップ
管理フラグは物理メモリの非ページ領域（スワップ領域に退避されない領域）に読み込まれるため、ＯＳを再起動すればその内容はすべて消去される。しかし、読み出しキャッシュデータをＯＳ再起動後も利用するためには、ＯＳ再起動前の読み出し管理フラグの状態を保持しておく必要がある。そこで、読み出し管理フラグの状態を物理ディスクの第３のパーティション（Ｐ３）の「キャッシュ管理領域」に定期的にバックアップする。このバックアップ動作はフィルタドライバに対するデータの読み出しや書き込み処理とは非同期に行ってよい。但し、同期漏れ（同期間隔の間に更新されること）があっても、そのセクタについては読み出しキャッシュデータの利用を断念し、後段のフィルタドライバに処理を委任する。これは、読み出しキャッシュであるため、状態Ｉに遷移して再度サーバ側ディスクイメージから読出しを行えばデータの不整合は生じないからである。

キャッシュ管理テーブルは、ＯＳ起動中は、読み出し単位毎に「読み出し管理フラグ」と「書き込み管理フラグ」の合計２ビット必要である。例えば、ＳＣＳＩディスクの場合１セクタが５１２バイトであるから、５１２バイトあたり２ビットの物理メモリが必要となる。しかし、書き込み管理フラグについては再起動後はすべて０とするため、キャッシュ管理テーブルの状態を記憶する「キャッシュ管理領域（Ｐ３）」は、読み出し管理フラグの状態のみ保存すればよいので、５１２バイトあたり１ビットのディスク容量、つまり、読み出しキャッシュデータ１ＧＢ（ギガバイト）あたり、０．２５ＭＢ（メガバイト）のキャッシュ管理領域が最低限必要となる。

但し、実際の運用では、読み出しキャッシュデータの利用効率と高めるために、「読み出し管理フラグ」のデータを少なくともキャッシュ管理領域の異なる２箇所以上の場所に交互にかつ定期的に書き込むことによって、信頼性を高めることが好ましい。２個の複製をバックアップする運用を採用した場合、必要なキャッシュ管理領域の容量は、読み出しキャッシュデータ１ＧＢ（ギガバイト）あたり、０．５ＭＢ（メガバイト）、例えば、読み出しキャッシュデータ領域が３０ＧＢ（ギガバイト）であれば、１５ＭＢ（メガバイト）となる。

（ｖ）まとめ
ａ．書き込み管理フラグ及び読み出し管理フラグが共に０の場合には、読み出しキャッシュデータが存在しないため、リードキャッシュドライバ５０はＯＳ側４０からの読み出し要求信号の処理を後段のフィルタドライバ４６に委任すると共に、フィルタドライバ４６が受け取ったデータを読み出しキャッシュパーティション（Ｐ２）にコピーして読み出し管理フラグを０から１に変更する。（状態Ｉ→状態ＩＩ）
ｂ．書き込み管理フラグが０であって、読み出し管理フラグが１の場合（状態ＩＩ）には、リードキャッシュドライバ５０はＯＳ等４０からの読み出し要求信号に対して読み出しキャッシュデータから読み出したデータを応答する。
ｃ．書き込み要求信号を受け取った場合は、読み出しキャッシュデータを利用せず、リードキャッシュドライバ５０は常に後段のフィルタドライバ４６に書き込み要求信号をスルーさせ、以後の処理は後段のフィルタドライバ４６に委任すると共に書き込み管理フラグを０から１に変更する（状態ＩＩ→状態ＩＩＩ）。また、ＯＳ起動後、一度も読み込みが行われていない領域に、書き込みが行われた場合は、読み出し管理フラグ及び書き込み管理フラグが共に０の状態から、書き込み管理フラグのみを１に変更する（状態Ｉ→状態ＩＶ）。書き込み管理フラグに１がたっている時（状態ＩＩＩ及び状態ＩＶ）は、読み出しキャッシュデータを使用してはならない。
ｄ．サーバ側のイメージデータが更新されている場合やキャッシュデータが破損した場合等は、読み出し管理フラグと書き込み管理フラグの両方を０に変更する。

［５］本システムの利点
以上のような構成により、ネットワークブートを１度行ったクライアント端末が多数存在している場合は、２度目以降の起動はネットワークを経由せずローカルディスクのキャッシュデータを用いて起動することができるため、ネットワーク負荷を劇的に軽減することができる。

特に、キャッシュデータを持つ多数のクライアントが一斉に起動しても、ネットワークアクセスが実質上ゼロとなり、全てのクライアントがローカルディスクと同等の速度で起動することができるようになる。その結果、サーバ１台あたりに接続できるクライアント端末数を大幅に増大させることができる。さらに、書き込み処理が行われたセクタをキャッシュの利用対象から除外しながら読み出しキャッシュデータをＯＳの再起動後も保存していくため、クライアント端末を使用すればするほどネットワーク負荷が軽減されていく。

しかも、読み出し専用のキャッシュであるから、ハードディスク障害時など、万一データの読み出しに失敗した場合は仮想ディスクイメージからネットワークブートによって起動するため、従来通りのディスクレス端末として動作させることもできる。

また、読み出しキャッシュ領域に加えて、スワップ領域やアプリケーションソフトのワークエリアや書き込みキャッシュ領域を別途を確保すれば、クライアント端末が一層快適に動作する。

（第１の実施形態の変形例）
図５は第１の実施形態の変形例を示しており、読み出しキャッシュを主体としつつ、書き込みキャッシュを補助的に用いたこのシステムにおけるディスクアクセスの関係を説明した図である。この場合、書き込みが行われた場合の情報についてもローカルディスクに設けられた書き込みキャッシュによってネットワークアクセス無しにＯＳ側に応答することができる。このような構成は本システムに特有の構成であり、その効果は上述の通り極めて大きいものである。

本発明者たちの研究によると、書き込みキャッシュ１段のみで構成した場合（これには、書き込みキャッシュをサーバ側におく方法と、ローカルディスクにおく場合の２通りの方法が考えられるが）には、クライアント端末の動作は極めて遅くなることが判明している。この理由は、多くの説明を要するが、主として書き込み遅延の影響によるものである。つまり、書き込みキャッシュのみでは、クライアント数が増大するほど読み出し速度が低下するという問題は解消されないのである。これに対し、本実施形態の構成のごとく、読み出しキャッシュを主体としつつ、書き込みキャッシュを補助的に用いると、クライアント端末の動作は極めて速くなるのである。

（第２の実施形態）−各パーティションの暗号化−
仮想ディスクは実体がサーバ側に存在するためセキュリティ上の問題は殆ど無いが、クライアント端末に直接接続されたローカルディスク（物理ディスク）に読み出しキャッシュデータ或いはライトキャッシュデータをクライアント端末側に保存することは、データをサーバ側で集中管理することを特徴とするネットワークブートシステムにおいて、セキュリティの脆弱部となる可能性がある。特に、物理ディスクの第１パーティションはＯＳ上でドライブとして認識されるものであることを踏まえると、この部分はドライブ或いはディスク全体を暗号化しておくことが望ましい。物理ディスクの第２及び第３のパーティションは、セクタやクラスタレベルで扱われるものであるため、暗号化の必要性は第１のパーティションよりは小さいが、ローカルディスクごと盗難される場合などに備えて、暗号化しておくことが好ましい。

本発明にかかるネットワークブートシステムは、ネットワーク負荷を大幅に軽減して１台のネットワークブートサーバに接続できるクライアント端末数を飛躍的に増大することができる。また、クライアント端末の一部に変更を加えるだけでよいため、既存のサーバやディスクレス端末がある場合にも、そのまま使用し続けることができる。このように、本発明を実施した場合の産業上の利用可能性は極めて大きい。

Claims (8)

1. クライアント端末上で動作するオペレーティングシステムを提供するネットワークブートサーバと、物理的な記憶装置を備えたクライアント端末とがネットワークを通じて接続され、
   前記クライアント端末は、前記オペレーティングシステム起動中に必要なデータを一時的に保存することができる物理メモリと、前記ネットワークを介して前記サーバにアクセスするためのネットワークインターフェースとを備えていると共に、
   前記オペレーティングシステムは、
   前記ネットワークインターフェースを駆動するためのネットワークドライバと、前記クライアント端末のローカルバスに対するアクセスを前記ネットワークに対するアクセスに変換するためのフィルタドライバと、前記記憶装置を駆動するためのリードキャッシュドライバを備えており、
   前記リードキャッシュドライバが、前記クライアント端末から読み出し要求信号を受けた際には前記フィルタドライバによって前記サーバから読み出されたデータを前記記憶装置の読み出しキャッシュ領域にキャッシュデータとして保存し、
   前記読み出しキャッシュ領域に対して書き込み要求信号を受けた際には書き込み要求信号を受けたことを記憶すると共にその領域に対するキャッシュデータを使用しないように制御することを特徴とするネットワークブートシステム。
2. 前記クライアント端末は、前記リードキャッシュドライバが前記サーバから読み出されたデータが書き込み済であるか否かを判別するための管理フラグを前記物理メモリに保持することを特徴とする請求項１記載のネットワークブートシステム。
3. 前記クライアント端末は、前記リードキャッシュドライバが前記サーバから読み出されたデータが書き込み済であるか否かを判別するための管理フラグを前記物理メモリに保持すると共に、
   前記記憶装置は、前記物理メモリに保持されている管理フラグの少なくとも一部を書き戻すためのキャッシュ管理領域を備えていることを特徴とする請求項２記載のネットワークブートシステム。
4. 前記記憶装置は、前記物理メモリに記憶されているデータの一部を一時的に保存するためのスワップ領域を備えていることを特徴とする請求項１記載のネットワークブートシステム。
5. 前記記憶装置は、前記サーバに対して書き込みを行ったデータを保存することが許容された書き込みキャッシュ領域を備えていることを特徴とする請求項１記載のネットワークブートシステム。
6. 前記記憶装置は、前記オペレーティングシステム上で動作するアプリケーションソフトのワークエリアを備えていることを特徴とする請求項１記載のネットワークブートシステム。
7. 前記サーバは前記クライアント端末が用いるオペレーティングシステム、アプリケーションソフトその他のデータを保持するための仮想ディスクを具備し、前記仮想ディスクはその更新情報を保持するための領域を備えていると共に、前記仮想ディスクが更新された場合には、前記記憶装置にキャッシュされている全てのデータを使用しないことを特徴とする請求項１記載のネットワークブートシステム。
8. 前記記憶装置は一部又は全部が暗号化されていることを特徴とする請求項１記載のネットワークブートシステム。

Images