JP5275456B2 - ハイパーバイザーを使用したディスクレスクライアント - Google Patents

Description

本発明は、ディスクレスクライアントおよびこれらの効果的でコスト効率の高い管理に関する。

共通のサーバに接続されたデスクトップ・コンピュータのパラグラムには、コストと管理性に関する問題が長い間存在している。第１には、各デスクトップがハードドライブを有することに起因して絶えず発生する安全性に関する深刻な懸念、すなわち、許可されていないファイルのコピーやダウンロードを助長したり、各デスクトップに導入されるものを管理することの難しさの見地から、システムの破壊のリスクが大いに増加する。

そのため、小企業や大企業でも、大部分のデスクトップハードドライブを取り除いたディスクレスクライアントを提供する傾向が進行中である。それ故、全てのデータは中央サーバ上で見つけられ、全てのファイル管理を１つの中央位置で実行できる。大部分のデスクトップは、バックアップが実行される間、アクティブにする必要がなく、必要とされる「パッチ管理」はサーバエンドで実行できるため、システムバックアップはかなり促進してきている。

しかしながら、上述した変更を実行するための大きな障害は、殆どのＯＳは、ディスクレスシステムで通常要求される種類のリモートブートの助けとならないことである。概して、各ＯＳは、ある種のローカルストレージを要求する特定のタイプのブーティング用に構成されており、対応できるブートの点で、多様性（汎用性）に欠けている。例えば、ブートの間、ＯＳは、リモートストレージまたはローカルストレージから、ワイヤレスまたはＬＡＮ（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”で見つけられる。

本発明の実施の形態によれば、共通のハイパーバイザーをベースとして、１つ以上のＯＳを動作させることが考えられる。例えば、Ｗｉｎｄｏｗｓ（登録商標）ＸＰとＬｉｎｕｘを単一のハイパーバイザー上で動作させることができる。ハイパーバイザーは、両方のＯＳからのリード／ライトを、ローカルからリモートストレージに変換することができる。実際、共通のハイパーバイザー上で動作させるＯＳの数は限定されないことが理解される。

また、本発明では、望ましい実施の形態の１つによれば、好適なソフトウェアプログラムを実行する少なくとも１つの汎用目的のコンピュータ上に実装されるエレメントを含むことができる。これらのエレメントは、少なくとも１つの集積回路または少なくとも１つの集積回路の一部に実装されてもよい。すなわち、本発明は、ハードウェア、ソフトウェア、または、両者の組み合わせに実装してもよいことが理解される。

また、ここで断りが無ければ、全ての特許、特許出願、特許公開、および他の文献（ｗｅｂで公開されたものを含む）で言及や引用された全てのことは、参照により、本明細書に組み込まれる。

本発明の説得的な実施の形態を、添付図面を参照して説明したが、本発明は、これらの正確な実施の形態に限定されるものではなく、発明の範囲又は精神を逸脱することなしに、当業者によって各種変形や変更が可能であることは明らかである。

１０ タイプ１のハイパーバイザー
２０ ＯＳ１
３０ ＯＳ２
４０，１４０ ハイパーバイザー
５０，１８０ ハードウェア
１２０ ＯＳ
１６０ ローディング
１７０ 中央サーバ
１７５ コール
１８０ ローカルハードドライブ
１８５ ファイルへのアクセス
１９０ 中央サーバとの通信

Claims (17)

1. クライアント用のオペレーティングシステムと、
   リモートストレージデバイスと、
   前記オペレーティングシステム下で動作し、ローカルストレージデバイスに対する前記
   オペレーティングシステムからのリード／ライトアクションを捕捉し、当該リード／ライ
   トアクションを前記リモートストレージデバイスに転送するハイパーバイザーと、
   を備えたディスクレスクライアントシステム。
2. 前記ハイパーバイザーは、ローカルハードディスクに対する前記オペレーティングシス
   テムからのリード／ライトアクションを捕捉し、当該リード／ライトアクションを前記リモートデバイスに転送する請求項１に記載のディスクレスクライアントシステム。
3. 前記ハイパーバイザーは、前記オペレーティングシステムのブートの間に、前記リモー
   トストレージデバイスと通信するために動作する請求項１に記載のディスクレスクライア
   ントシステム。
4. 前記リモートストレージデバイスは、中央サーバを含む請求項１に記載のディスクレス
   クライアントシステム。
5. 前記オペレーティングシステムは、
   第１のオペレーティングシステムと、第２のオペレーティングシステムとを含み、
   前記ハイパーバイザーは、前記第１および第２のオペレーティングシステムからの通信
   アクションを捕捉し、当該通信アクションを前記リモートストレージデバイスに転送する
   ために動作する請求項１に記載のディスクレスクライアントシステム。
6. さらに、前記ハイパーバイザーをロードするローディング機構を備えた請求項１に記載
   のディスクレスクライアントシステム。
7. 前記ローディング機構は、ｉＳＣＳＩプロトコルを使用することを特徴とする請求項６
   に記載のディスクレスクライアントシステム。
8. 前記ローディング機構は、前記オペレーティングシステムをロードする前に前記ハイパ
   ーバイザーをロードすることを特徴とする請求項６に記載のディスクレスクライアントシ
   ステム。
9. ディスクレスクライアントが、オペレーティングシステムをロードするステップと、
   前記ディスクレスクライアントが、ハイパーバイザーをロードするステップと、
   前記ロードされたハイパーバイザーが、前記オペレーティングシステムからの通信アクションを捕捉して、当該通信アクションを、前記リモートストレージデバイスに転送するステップと、
   を含む方法。
10. 前記リード／ライトアクションの捕捉は、ローカルストレージデバイスに対する前記オ
    ペレーティングシステムからのリード／ライトアクションの捕捉を含む請求項９に記載の
    方法。
11. 前記ローカルストレージデバイスに対する前記オペレーティングシステムからのリード
    ／ライトアクションの捕捉は、ローカルハードディスクに対する前記オペレーティングシ
    ステムからのリード／ライトアクションの捕捉を含む請求項１０に記載の方法。
12. 前記リード／ライトアクションの転送は、中央サーバへのリード／ライトアクションの転送を含む請求項９に記載の方法。
13. 前記オペレーティングシステムをロードするステップでは、第１のオペレーティングシ
    ステムと、第２のオペレーティングシステムをロードし、
    前記転送するステップでは、前記第１および第２のオペレーティングシステムからの通信アクションを捕捉し、当該通信アクションを前記リモートストレージデバイスに転送する請求項９に記載の方法。
14. 前記ハイパーバイザーをロードするステップでは、ｉＳＣＳＩプロトコルを使用する請
    求項９に記載の方法。
15. 前記ハイパーバイザーをロードするステップでは、前記ＯＳをロードする前に前記ハイ
    パーバイザーをロードする請求項９に記載の方法。
16. さらに、
    前記ディスクレスクライアントが、前記オペレーティングシステムをブートするステップと、
    前記ディスクレスクライアントが、前記ブートの間に、前記ハイパーバイザーと前記リモートストレージデバイスの間の通信を有効にするステップと、
    を含む請求項９に記載の方法。
17. ディスクレスクライアントが、オペレーティングシステムをロードするステップと、
    前記ディスクレスクライアントが、ハイパーバイザーをロードするステップと、
    前記ロードされたハイパーバイザーが、前記オペレーティングシステムからの通信アクションを捕捉して、当該通信アクションをリモートストレージデバイスに転送するステップと、
    をコンピュータに実行させるためのプログラムを格納したコンピュータが読取可能な記
    録媒体。

Images