(57)【要約】【課題】ディスクレスクライアントシステムのリモートブートを容易にするための構成を提供すること。【解決手段】ハイパーバーザー１４０は、ＯＳ１２０下で動作するように、最初にロード１６０される。一旦、ロードされると、ハイパーバイザー１４０は、中央サーバ１７０との接続を確立し、ユーザデータのロード、ディスクアクセスモジュールのフックを行い、通常のブートパスに沿って処理を行う。ＯＳ１２０がローカルハードドライブ１８０上のファイルにアクセスを試みる毎に、ハイパーバイザー１４０は、このアクセスを「トラップ」して、ローカルハードドライブ１８０との通信を阻止し、中央サーバ１７０から必要なデータをリード１９０する。ハイパーバイザーのローディング機構は、ｉＳＣＳＩプロトコルを利用する。【選択図】  図２
2011523752.tif 000002
【特許請求の範囲】
【請求項１】
オペレーティングシステムと、
前記オペレーティングシステムと一般的な通信を行うリモートストレージデバイスと、  前記オペレーティングシステムからの通信アクションを捕捉して、当該通信アクションを前記リモートストレージデバイスに転送するハイパーバイザーと、
を備えたシステム。
【請求項２】
前記ハイパーバイザーは、所定の受信手段に対する前記オペレーティングシステムからのリード／ライトアクションを捕捉し、当該リード／ライトアクションを前記リモートストレージデバイスに転送する請求項１に記載のシステム。
【請求項３】
前記ハイパーバイザーは、ローカルストレージデバイスに対する前記オペレーティングシステムからのリード／ライトアクションを捕捉し、当該リード／ライトアクションを前記リモートストレージデバイスに転送する請求項２に記載のシステム。
【請求項４】
前記ハイパーバイザーは、ローカルハードディスクに対する前記オペレーティングシステムからのリード／ライトアクションを捕捉し、当該リード／ライトアクションを前記リモートデバイスに転送する請求項３に記載のシステム。
【請求項５】
前記ハイパーバイザーは、前記オペレーティングシステムのブートの間に、前記リモートストレージデバイスと通信するために動作する請求項１に記載のシステム。
【請求項６】
前記リモートストレージデバイスは、中央サーバを含む請求項１に記載のシステム。
【請求項７】
前記オペレーティングシステムは、
第１のオペレーティングシステムと、第２のオペレーティングシステムとを含み、
前記ハイパーバイザーは、前記第１および第２のオペレーティングシステムからの通信アクションを捕捉し、当該通信アクションを前記リモートストレージデバイスに転送するために動作する請求項１に記載のシステム。
【請求項８】
さらに、前記ハイパーバイザーをロードするローディング機構を備えた請求項７に記載のシステム。
【請求項９】
前記ローディング機構は、ｉＳＣＳＩプロトコルを使用することを特徴とする請求項８に記載のシステム。
【請求項１０】
前記ローディング機構は、前記オペレーティングシステムをロードする前に前記ハイパーバイザーをロードすることを特徴とする請求項８に記載のシステム。
【請求項１１】
オペレーティングシステムをロードするステップと、
ハイパーバイザーをロードするステップと、
前記オペレーティングシステムからの通信アクションを捕捉して、当該通信アクションを前記リモートストレージデバイスに転送するために、前記ハイパーバイザーを使用するステップと、
を含む方法。
【請求項１２】
前記捕捉は、所定の受信手段に対する前記オペレーティングシステムからのリード／ライトアクションの捕捉を含み、
前記転送は、前記リード／ライトアクションの前記リモートストレージデバイスへの転送を含む請求項１１に記載の方法。
【請求項１３】
前記リード／ライトアクションの捕捉は、ローカルストレージデバイスに対する前記オペレーティングシステムからのリード／ライトアクションの捕捉を含む請求項１２に記載の方法。
【請求項１４】
前記ローカルストレージデバイスに対する前記オペレーティングシステムからのリード／ライトアクションの捕捉は、ローカルハードディスクに対する前記オペレーティングシステムからのリード／ライトアクションの捕捉を含む請求項１３に記載の方法。
【請求項１５】
前記リード／ライトアクションの転送は、中央サーバへのリード／ライトアクションの転送を含む請求項１１に記載の方法。
【請求項１６】
前記オペレーティングシステムをロードするステップでは、第１のオペレーティングシステムと、第２のオペレーティングシステムをロードし、
前記ハイパーバイザーを使用するステップでは、前記第１および第２のオペレーティングシステムからの通信アクションを捕捉し、当該通信アクションを前記リモートストレージデバイスに転送する請求項１１に記載の方法。
【請求項１７】
前記ハイパーバイザーをロードするステップでは、ｉＳＣＳＩプロトコルを使用する請求項１１に記載のシステム。
【請求項１８】
前記ハイパーバイザーをロードするステップでは、前記ＯＳをロードする前に前記ハイパーバイザーをロードする請求項１１に記載のシステム。
【請求項１９】
さらに、
前記オペレーティングシステムをブートするステップと、
前記ブートの間に、前記ハイパーバイザーと前記リモートストレージデバイスの間の通信を有効にするステップと、
を含む請求項１１に記載のシステム。
【請求項２０】
オペレーティングシステムをロードするステップと、
ハイパーバイザーをロードするステップと、
前記オペレーティングシステムからの通信アクションを捕捉して、当該通信アクションをリモートストレージデバイスに転送するために、前記ハイパーバイザーを使用するステップと、
をコンピュータに実行させるためのプログラムを格納したコンピュータが読取可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディスクレスクライアントおよびこれらの効果的でコスト効率の高い管理に関する。
【背景技術】
【０００２】
共通のサーバに接続されたデスクトップ・コンピュータのパラグラムには、コストと管理性に関する問題が長い間存在している。第１には、各デスクトップがハードドライブを有することに起因して絶えず発生する安全性に関する深刻な懸念、すなわち、許可されていないファイルのコピーやダウンロードを助長したり、各デスクトップに導入されるものを管理することの難しさの見地から、システムの破壊のリスクが大いに増加する。
【０００３】
そのため、小企業や大企業でも、大部分のデスクトップハードドライブを取り除いたディスクレスクライアントを提供する傾向が進行中である。それ故、全てのデータは中央サーバ上で見つけられ、全てのファイル管理を１つの中央位置で実行できる。大部分のデスクトップは、バックアップが実行される間、アクティブにする必要がなく、必要とされる「パッチ管理」はサーバエンドで実行できるため、システムバックアップはかなり促進してきている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した変更を実行するための大きな障害は、殆どのＯＳは、ディスクレスシステムで通常要求される種類のリモートブートの助けとならないことである。概して、各ＯＳは、ある種のローカルストレージを要求する特定のタイプのブーティング用に構成されており、対応できるブートの点で、多様性（汎用性）に欠けている。例えば、ブートの間、ＯＳは、リモートストレージまたはローカルストレージから、ワイヤレスまたはＬＡＮ（Local Area Network）でブートが始まったかを認識しなければならない。多様性のかなりの程度を許容できるように実装するには、一般的に費用のかかる修正が必要となる。
【０００５】
したがって、関連する問題だけでなく汎用性の問題に取り組む切迫した必要性がある。
【課題を解決するための手段】
【０００６】
本発明の少なくとも１つの望ましい実施の形態によれば、このように、ここでは、ディスクレスクライアントシステムのリモートブートを容易にする機構を広汎に意図している。この目的を達成するため、ここでは、所定のＯＳ用に、自由に各種ブート機構に対応することができるハイパーバイザーを使用することを広汎に意図している。これは、変更、取りわけ高価な変更をしなくても、大きな汎用性を補償するためにＯＳに要求されるものを補償する。
【０００７】
要約すれば、本発明の１つの側面では、オペレーティングシステムと、前記オペレーティングシステムと一般的な通信を行うリモートストレージデバイスと、前記オペレーティングシステムから通信アクションを捕捉して、当該通信アクションを前記リモートストレージデバイスに転送するハイパーバイザーとを備えたシステムを提供する。
【０００８】
本発明の他の側面では、オペレーションシステムをロードし、ハイパーバイザーをロードし、前記オペレーティングシステムから通信アクションを捕捉して、当該通信アクションを前記リモートストレージデバイスに転送（divert）するハイパーバイザーを利用する方法を提供する。
【０００９】
さらに、本発明の付加的な側面では、マシン（コンピュータ）によって読み取り可能であり、オペレーションシステムをロードするステップと、ハイパーバイザーをロードするステップと、前記オペレーティングシステムから通信アクションを捕捉して、当該通信アクションを前記リモートストレージデバイスに転送するハイパーバイザーを利用するステップと、をマシンに実行させる指示プログラムを格納したプログラムストレージデバイスを提供する。
【００１０】
本発明をよく理解するために、それらの他のさらなる特徴および利点を、図面を参照して以下に説明する。本発明の範囲は、添付した特許請求の範囲で指摘される。
【図面の簡単な説明】
【００１１】
【図１】図１は、タイプ１のハイパーバイザーを概略的に説明するための図である。
【図２】図２は、少なくとも本発明の一実施の形態に係るハイパーバイザーを適用したシステムを概略的に説明するための図である。
【発明を実施するための形態】
【００１２】
上述したように、少なくとも本発明の望ましい一実施の形態によれば、ＯＳのブート機能をより効率的に促進し、かつ、大いに拡張する、ディスクレスクライアントシステムのハイパーバイザーの使用を広汎に意図している。より詳細には、ハイパーバイザーは、ＯＳからの全てのディスクおよびＬＡＮへのアクセスを、（以下に述べる方法で）「トラップ（trap）」することが望ましい。
【００１３】
他の方法では、ブートしている間、通常、ハードドライブに書き込むように構成される多くのＯＳを、ディスクレスシステムに組み込みたい場合に、本発明によるハイパーバイザーは、ブート状況が著しく異なるディスクレス環境のために、ＯＳを高コストに再構成する必要性を取り除くことである。リモートストレージデバイスへの全ての変換（translation）は、ハイパーバイザーによって実行されるので、ＯＳは基本的に「ブラインド（blind）」である。
【００１４】
従来、ハイパーバイザーは、仮想環境下でＯＳを実行できるように、ＯＳ環境下で実行するコードの基本セットが実装されており、「ゲストＯＳ（例えば、Ｍｉｃｒｏｓｏｆｔ  ＸＰ）」に対して、仮想環境を構築することができる。これにより、複数のＯＳは同じハードウェア上で同時に動作することが可能となる。
【００１５】
基本的に、ハイパーバイザーには２つの主なタイプがある。タイプ１は、ハードウェア上で直接動作する。タイプ２は、既存のＯＳ上で動作する。図１は、タイプ１のハイパーバイザー環境（Hypervisor environment）１０を示している。ＯＳ（Operating System）１（２０）は、例えば、Ｍｉｃｒｏｓｏｆｔ  ＸＰのようなＵＯＳ（User Operating System）とすることができる。ＯＳ２（３０）は、例えば、Ｌｉｎｕｘ（登録商標）やＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）ＰＥのようなクライアント管理用に使用するＳＯＳ（Service Operating System）とすることができる。これらの２つのＯＳと、ハイパーバイザー（Hypervisor）４０自体は、同じハードウェア（Hardware）５０上で動作する。
【００１６】
図２は、少なくとも本発明の一実施の形態に係るハイパーバイザーを適用したシステムを概略的に説明するための図である。一般的に、本発明の望ましい実施の形態によれば、ハイパーバイザー１４０は、ＯＳ１２０下で動作させるために最初にローディング（Loading）１６０される。より好ましくは、ハイパーバイザー１４０は最初にローディング１６０され、その後、ハイパーバイザー１４０がＯＳ１２０下で動作するように、ＯＳ１２０をロードする。ハイパーバイザー１４０は、一旦、ロードされると、望ましくは、中央サーバ１７０との接続を確立し、ユーザデータをロードし、ディスクアクセスモジュールを「フック（hook）」し、その後、通常のブートパスに沿った処理を行う。ディスクアクセスモジュールをフックすることによって、基本的に、ハイパーバイザー１４０は、これから説明するように、ハードドライブのリード／ライトを「トラップ（trap）」できるようにするために、ディスクアクセスモジュールを利用する。
【００１７】
したがって、ＯＳ１２０が、ローカルハードドライブ１８０上のファイルにアクセス（１８５）を試みる毎に、ハイパーバイザー１４０は、望ましくは、このアクセス（１８５）をトラップし、他のものがローカルハードドライブ１８０と通信することを防ぎ、基本的には、中央サーバ１７０から必要なデータを読み出す（１９０）。換言すると、ＯＳ１２０がハードドライブのリード／ライトと見なされることに着手した場合に、ハイパーバイザー１４０は、このリード／ライトをトラップまたはインターセプトし、このリード／ライトの宛先をネットワーク上のリモートストレージデバイスに変更する。この方法では、実際にはネットワークのリモートストレージデバイスにアクセスしている場合に、ＯＳ１２０は、ローカルハードドライブ１８０にリード／ライトしていると思う。また、アクセスで衝突しないように、ＬＡＮトラフィックをトラップすることが望ましい（通常のＬＡＮデータとは異なるように取り扱われるのが望ましく、通常のネットワークトラフィックとは対照的に、リモートストレージデバイスからのリードライトに優先権を与えるのが望ましく、例えば、それらのバンド幅の８０％またはそれ以上を割り当てることができる。）。
【００１８】
別の方法を説明すると、ＯＳ１２０は、基本的に市販の物（shrink-wrapped）であり、通常、通信するコンポーネントやアイテム（例えば、ローカルハードドライブ１８０）から分離している。ハイパーバイザー１４０は、所定のタイプの通信が行われる際のバッファまたは媒体として機能する。また、少なくとも本発明の望ましい形態によるハーパーバイザー１４０は、例えば、セクタを読み出すハードディスクへのコール（１７５）がトラップされ、その後、中央サーバ１７０に送信（１９０）された場合、クライアントのＯＳ１２０に、ローカルハードドライブ１８０からブートしている（若しくは、ローカルハードドライブ１８０に対してリード／ライトを実行している）と思わせる。したがって、ハイパーバイザー１４０は、ＯＳ１２０からの通常のブート通信（１７５）を捕捉して対応するように構成されることが望ましい。ハイパーバイザー１４０自体は、特定の媒体（例えば、ローカルハードドライブ１８０）に対してリード／ライト（通信）し、それから、各種のブートコマンドを、より自由かつ巧みに対応できる別の記憶位置（例えば、中央サーバ１７０）にそのような通信を転送（転換）するように通常、構成される。そのため、ＯＳ１２０は、多様性を保証するために高価に再構成する必要性がなくなり、ハイパーバイザー１４０は、その必要性を取り除くためにバッファまたは媒介として機能する。通信が転送されるリモート記憶位置は、もちろん、上述したような中央サーバには限られない。リモート記憶位置は、本質的に、ＳＡＮ（Storage Area Network）やＮＡＳ（Network Attached Storage）のような各種のリモートストレージデバイスであればよい。
【００１９】
ハードドライブへのリード／ライトを「トラップ」するハイパーバイザーの利用について説明したが、ハイパーバイザーは、明らかにこれ以上広い多様性があることが理解されるべきである。例えば、ＯＳがハードドライブ以外のものにリード／ライトするように構成されている場合は、ハイパーバイザーは、そのようなリード／ライトを「トラップ」することができる。本質的には、少なくとも本発明の望ましい実施の形態によれば、ＯＳからのリード／ライトは、ハイパーバイザーによって、リモートストレージに変換することができる。
【００２０】
ハイパーバイザー１４０を安全にローディング１６０するために、各種の既知のプロセスが考えられる。例えば、ローディング１６０は、Ｆｌａｓｈ、ＵＥＦＩドライバ、または、安全なＰＸＥ（Preboot Execution Environment）  ｂｏｏｔ（Boot Integrity Services[ＢＩＳ]、または、安全なロード方法）を使用することができる。現在の望ましいローディング機構は、ｉＳＣＳＩ（Internet Small Computer Systems Interface）プロトコルの使用である。ＰＸＥブートのさらなる情報は、Ｐｒｅｂｏｏｔ  Ｅｘｅｃｕｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ（ＰＸＥ）、Ｓｐｅｃｉｆｉｃａｔｉｏｎ（http colon dot dot slash slash www dot pix dot net slash software slash pxeboot slash archive slash pxespecdot pdf）で入手可能である。ｉＳＣＳＩプロトコルのさらなる情報は、ＲＦＣ３７２０（http colon slash slash www dot faqs dot org slash rfcs slash rfc3720 dot html）で入手可能である。本発明の実施の形態に応じてハイパーバイザーの好適な使用について説明してきたが、「Ｘｅｎ」ハイパーバイザーは望ましいハイパーバイザーである。Ｘｅｎハイパーバイザーは、オープンソースソフトウエアデベロップメントである。Ｘｅｎハイパーバイザーの更なる情報は、”http colon slash slash www dot faqs dot org slash rfcs slash rfc3720 dot html”で見つけられる。
【００２１】
本発明の実施の形態によれば、共通のハイパーバイザーをベースとして、１つ以上のＯＳを動作させることが考えられる。例えば、Ｗｉｎｄｏｗｓ（登録商標）ＸＰとＬｉｎｕｘを単一のハイパーバイザー上で動作させることができる。ハイパーバイザーは、両方のＯＳからのリード／ライトを、ローカルからリモートストレージに変換することができる。実際、共通のハイパーバイザー上で動作させるＯＳの数は限定されないことが理解される。
【００２２】
また、本発明では、望ましい実施の形態の１つによれば、好適なソフトウェアプログラムを実行する少なくとも１つの汎用目的のコンピュータ上に実装されるエレメントを含むことができる。これらのエレメントは、少なくとも１つの集積回路または少なくとも１つの集積回路の一部に実装されてもよい。すなわち、本発明は、ハードウェア、ソフトウェア、または、両者の組み合わせに実装してもよいことが理解される。
【００２３】
また、ここで断りが無ければ、全ての特許、特許出願、特許公開、および他の文献（ｗｅｂで公開されたものを含む）で言及や引用された全てのことは、参照により、本明細書に組み込まれる。
【００２４】
本発明の説得的な実施の形態を、添付図面を参照して説明したが、本発明は、これらの正確な実施の形態に限定されるものではなく、発明の範囲又は精神を逸脱することなしに、当業者によって各種変形や変更が可能であることは明らかである。
【符号の説明】
【００２５】
１０  タイプ１のハイパーバイザー
２０  ＯＳ１
３０  ＯＳ２
４０，１４０  ハイパーバイザー
５０，１８０  ハードウェア
１２０  ＯＳ
１６０  ローディング
１７０  中央サーバ
１７５  コール
１８０  ローカルハードドライブ
１８５  ファイルへのアクセス
１９０  中央サーバとの通信
【図１】
2011523752.tif 000003
【図２】
2011523752.tif 000004
【国際調査報告】
2011523752.tif 000005
2011523752.tif 000006
2011523752.tif 000007