コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのオペレーティング・システム・サービスを提供する方法、コンピュータ・システム及びコンピュータ・プログラム
【課題】コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのオペレーティング・システム（ＯＳ）サービスを提供すること。
【解決手段】コンピュータ・システムは、少なくとも１つの計算ノードを含む。計算ノードは、一のＯＳ及び一のハイパーバイザを含む。ＯＳは、一のカーネルを含む。ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含む。コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するため、計算ノード上で、カーネル・プロキシが使用すべきサービス・タイプのＯＳサービスのうち１つを指定するカーネル・ポリシを設定し、カーネル・プロキシによって、指定されたＯＳサービスにアクセスする。コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムとしても実装することができる。１つ以上のＯＳサービスは、ＯＳサービス・ノード間に分散することができる。
【解決手段】コンピュータ・システムは、少なくとも１つの計算ノードを含む。計算ノードは、一のＯＳ及び一のハイパーバイザを含む。ＯＳは、一のカーネルを含む。ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含む。コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するため、計算ノード上で、カーネル・プロキシが使用すべきサービス・タイプのＯＳサービスのうち１つを指定するカーネル・ポリシを設定し、カーネル・プロキシによって、指定されたＯＳサービスにアクセスする。コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムとしても実装することができる。１つ以上のＯＳサービスは、ＯＳサービス・ノード間に分散することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理に係り、さらに詳細に説明すれば、コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのオペレーティング・システム・サービスを提供する方法、装置及びプログラムに係る。
【背景技術】
【０００２】
１９４８年のＥＤＶＡＣコンピュータ・システムの開発は、コンピュータ時代の始めとしてしばしば引用される。その時以来、コンピュータ・システムは、非常に複雑な装置へ発展した。今日のコンピュータは、ＥＤＶＡＣのような初期のシステムよりはるかに複雑となっている。コンピュータ・システムは、一般に、ハードウェア及びソフトウェア・コンポーネントの組み合わせ、アプリケーション・プログラム、オペレーティング・システム（以下「ＯＳ」と略記）、プロセッサ、バス、メモリ、入出力装置などを含む。半導体処理及びコンピュータ・アーキテクチャの進歩が高いコンピュータの性能をもたらし、精巧なソフトウェアがハードウェアの高い性能を活用するように発展した結果、今日のコンピュータ・システムは、わずか数年前よりはるかに強力になっている。
【０００３】
高性能ハードウェアを利用するためにソフトウェアが発展した１つの領域は、ＯＳである。初期のコンピュータは、どんな形式のＯＳも持っていなかった。システム管理者によってロードされるアプリケーションが、マシンを単独で使用していたからである。コンピュータを動作させるために、アプリケーションは、ハードウェアに直接にアクセスし、これを制御しなければならなかった。その後、サポート・コードのライブラリを備えたコンピュータが出現し、かかるライブラリが入出力のような動作を支援するためにアプリケーションへリンクされた。かかるライブラリは、最近のＯＳの起源であった。しかし、コンピュータは、依然として一度に単一のアプリケーションだけを稼働させるに過ぎなかった。最近のＯＳは、多数のアプリケーションを同時に稼働させることができる。さらに、最近のＯＳは、アプリケーションの開発を簡易化し、かつ１つのハードウェア・プラットフォームから他のハードウェア・プラットフォームへアプリケーションを移植する能力を援助するために、ハードウェアの抽象化層をアプリケーションに提供する。
【０００４】
カーネルは、殆どのＯＳの主要部であって、システムの資源を管理したり、ハードウェア及びソフトウェア・コンポーネント間の通信を管理する。カーネルは、ＯＳの主要部として、ハードウェア（特に、メモリ、プロセッサ、及びＩ／Ｏ）のための抽象化層を提供することにより、ハードウェアとソフトウェアが通信することを可能にする。さらに、カーネルは、プロセス間通信機構及びシステム・コールを通して、これらの機能をアプリケーション及び他のＯＳサービスに利用可能にする。
【０００５】
かかるカーネル・タスクは、カーネルが異なれば、それぞれの設計及び実装に依存して、異なった態様で遂行される。モノリシック・カーネルの場合、全てのＯＳサービスは、同じメモリ領域内に存在し、当該メモリ領域を使用して実行される。このように、モノリシック・カーネルが同じアドレス空間内の全てのコードを実行することを試みるという理由で、モノリシックカーネル・アーキテクチャは、他の解決手段よりも設計及び実装が簡単であり、よく書けている場合は、非常に効率的である。モノリシック・カーネルの主要な欠点は、システム・コンポーネント間の依存関係である。大きなカーネルは、これを維持するのが非常に難しくなり、また、カーネルの１つの部分にバグが存在すると、システム全体をクラッシュさせることがある。
【０００６】
マイクロカーネル・アーキテクチャの場合、カーネルは、最小のＯＳサービス（例えば、メモリ管理、マルチタスキング及びプロセス間通信）を実装するために、１セットのプリミティブ又はシステム・コールによって、ハードウェアに関する単純な抽象化層を提供する。ネットワーキングのようなカーネルによって通常提供されるものを含む他のサービスは、一般に、それ自体のアドレス空間を有するユーザ空間プログラム内で実装される。マイクロ・カーネルは、モノリシック・カーネルよりも維持するのがより簡単であるが、多くのシステム・コール及びコンテキスト・スイッチはシステムの性能を低下させることがある。
【０００７】
ＯＳを実装するために使用されるカーネル・アーキテクチャに拘わらず、最近のＯＳ内に提供される１セットのＯＳサービスは、当該ＯＳがインストールされるとき、固定されることが一般的である。すなわち、かかるＯＳは、当該ＯＳによって管理されるハードウェア上で稼働するアプリケーションを考慮せずに、同じメモリ管理アルゴリズム、同じＩ／Ｏスケジューリング・アルゴリズム、同じネットワーキング・アルゴリズムなどを利用する。しかし、同じ１つのＯＳサービスを利用する場合、１つのアプリケーションが資源を効率的に利用できるのに対し、他のアプリケーションは資源を効率的に利用できない、という事態がしばしば生ずる。例えば、ＯＳ内にＩ／Ｏスケジューリングを提供する一のＯＳサービスは、入出力集中的なアプリケーションが資源を効率的に使用することを可能にするのに対し、入出力集中的でないアプリケーションが資源を効率的に使用することを困難にすることがある。このように、最近のＯＳは、アプリケーションを考慮せずに同じＯＳサービスを提供するという理由で、アプリケーションとハードウェアとの間の相互作用を効率的に管理しないことが多い。従って、当分野では、ＯＳ内にＯＳサービスを提供する態様を改良することが要請されている。
【０００８】
高性能ハードウェアを利用するためにソフトウェアが発展した他の領域は、「ハイパーバイザ」と呼ばれるソフトウェア・ツールのセットである。ハイパーバイザは、ハードウェア上でＯＳ層の下で稼働するシステム・ソフトウェアの層であって、ホスト・コンピュータ上で多数のＯＳが未変更のまま同時に稼働することを可能にする。ハイパーバイザが最初に開発された１９７０年代の初めには、企業の経費を削減することを目標として、それまで多数の部門に散在していた多数のコンピュータを単一の大型コンピュータ（メインフレーム）に統合して、多数の部門にサービスを提供することが一般に行われていた。ハイパーバイザは、多数のＯＳを同時に稼働させることによって、システムに対し頑強性と安定度をもたらした。１つのＯＳがクラッシュしても、他のＯＳは中断なしに作業を継続することができたからである。確かに、ハイパーバイザを利用することにより、安定した主実働システムを危険にさらすことなく、しかも開発者が作業すべき高価な第２及び第３のシステムを必要とすることなく、ＯＳのベータ・バージョン又は実験的なバージョンを配備しデバッグすることが可能になった。
【０００９】
ハイパーバイザは、各ＯＳに１セットの仮想資源を提供することにより、ホスト・コンピュータ上で多数のＯＳが同時に稼働することを可能にする。これらの仮想資源は、各ＯＳにコンピュータの実際の資源の一部を提供する。一般に、かかる資源の部分は、当該資源が使用可能な合計時間のタイム・スライスとして実装される。ハイパーバイザを使用すると、単一コンピュータ内の資源が分配され、その結果、当該コンピュータは、あたかも２つ以上の独立したコンピュータであるかのように見える。しかし、ホスト・コンピュータ上で多数のＯＳが同時に稼働することを可能にするためにハイパーバイザを利用することには、欠点がある。すなわち、ハイパーバイザを動作させるのに必要な管理オーバーヘッドは、ＯＳ及びアプリケーションを稼働させるのに利用可能な総合的な資源を減少させてしまう。かかる管理オーバーヘッドは、ハイパーバイザと各ＯＳの間のプロセッサ・コンテキスト・スイッチの形で生じる。従って、当分野では、ＯＳの或る機能をハイパーバイザ内で実装することにより、ハイパーバイザの管理オーバーヘッドを減少させることが要請されている。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従って、本発明の目的は、コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための方法、装置及びプログラムを提供することである。
【課題を解決するための手段】
【００１１】
前記コンピュータ・システムは、少なくとも１つの計算ノードを含む。前記計算ノードは、一のＯＳ及び一のハイパーバイザを含む。前記ＯＳは、一のカーネルを含む。前記ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含む。コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供することは、前記計算ノード上で、前記カーネル・プロキシによって使用すべき前記複数のＯＳサービスのうち１つを指定するカーネル・ポリシを設定することと、前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスすることを含む。
【００１２】
また、前記コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムとして実装することができる。１つ以上のＯＳサービスは、これらのＯＳサービス・ノードの間に分散することができる。また、前記カーネル・ポリシは、前記指定されたＯＳサービスを提供すべき１つのＯＳサービス・ノードを指定することができ、その場合、前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスすることは、前記計算ノード上の前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスすることを含むことができる。
【００１３】
本発明の前記及び他の目的、特徴及び利点は、添付の図面に示されている本発明の実施形態に関する以下の説明から明らかとなるであろう。なお、図面中の同じ参照番号は、本発明の実施形態の同じ部分を指すものとする。
【発明を実施するための最良の形態】
【００１４】
以下、添付の図面を参照して、コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための、本発明の実施形態に従った方法、装置及びプログラムを説明する。図１は、ハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための、本発明の実施形態に従ったコンピュータ・システム１００を示すネットワーク図である。コンピュータ・システム１００は、計算ノード１１０を含む。計算ノード１１０は、ＯＳ１０８及びハイパーバイザ１１１を含む。ＯＳ１０８は、カーネル１０９を含む。ハイパーバイザ１１１は、カーネル・プロキシ１２０及び一のサービス・タイプの複数のＯＳサービス１２４を含む。一般に、コンピュータ・システム１００は、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するために、計算ノード１１０上で、ハイパーバイザ１１１内のカーネル・プロキシ１２０が使用すべき前記サービス・タイプの前記複数のＯＳサービス１２４のうち１つを指定するカーネル・ポリシ１２２を設定し、カーネル・プロキシ１２０によって、前記指定されたＯＳサービスにアクセスするように動作する。
【００１５】
コンピュータ・システム１００は、分散コンピュータ・システムとして実装される。分散コンピュータ・システムは、共通のタスクを遂行するために、ネットワークに接続された２つ以上の計算装置を使用するコンピュータ・システムである。分散コンピュータ・システム１００は、ネットワーク１０１を通して互いにデータ通信を行うように接続された、計算ノード１１０と、ＯＳサービス・ノード１１２、１１４、１１６と、管理ノード１１８とを含む。計算ノード１１０は、接続線１４０を通して、ネットワーク１０１に接続する。ＯＳサービス・ノード１１２、１１４、１１６は、接続線１４２、１４４、１４６を通して、ネットワーク１０１にそれぞれ接続する。管理ノード１１８は、接続線１４８を通して、ネットワーク１０１に接続する。分散コンピュータ・システム１００内の共通のタスクは、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供することを含む。
【００１６】
計算ノード１１０は、ラック１０４内に取り付けられたノード１０２のうち１つを使用して実装される。各ノード１０２は、プログラム命令を実行する処理装置である。各ノード１０２は、１つ以上のプロセッサ及び当該プロセッサに結合されたメモリを含む。ノード１０２は、サーバ・シャシに取り付けられたブレード・サーバとして実装され、これらのサーバ・シャシは、ラック１０４に取り付けられる。しかし、ノード１０２をブレード・サーバとして実装するのは、説明上のものであって、本発明を限定するものではない。実際、ノード１０２は、ネットワークに接続されたワークステーションとして、またコンピュータ・クラスタを形成するように互いに接続されたコンピュータなどとして、実装することができる。
【００１７】
計算ノード１１０は、カーネル・プロキシ１２０及びカーネル・ポリシ１２２を含む、ハイパーバイザ１１１を有するように構成されたノードである。ハイパーバイザ１１１は、ハードウェア上でＯＳ層の下で稼働するシステム・ソフトウェアの層であって、ホスト・コンピュータ上で多数のＯＳが未変更のまま同時に稼働することを可能にする。ハイパーバイザ１１１は、各ＯＳに１セットの仮想資源を提供するために、論理区画（以下「ＬＰＡＲ」と略記）を使用して各ＯＳにかかる資源を割り振る。ＬＰＡＲは、１セットのデータ構造及びサービスであって、単一コンピュータ内の資源の分配を可能にすることにより、あたかも当該コンピュータが２つ以上の独立したコンピュータであるかのように機能させる。
【００１８】
多数のＯＳが同時に稼働することを可能にするために、ハイパーバイザ１１１は、仮想プロセッサ１１５をＯＳ１０８、ゲストＯＳ１１７に割り当てるとともに、計算ノード１１０の物理プロセッサ上で仮想プロセッサ１１５をスケジュールする。仮想プロセッサは、ＬＰＡＲに対するプロセッサ時間の割り当てを実装するためのサブシステムである。物理プロセッサの共有プールは、ＬＰＡＲに対する部分的な物理プロセッサの（タイム・スライスによる）割り当てをサポートする。このようにタイム・スライスで共有される部分的な物理プロセッサは、「仮想プロセッサ」と呼ばれる。スレッドが仮想プロセッサのタイム・スライス上で稼働している場合、スレッドは仮想プロセッサ上で稼働中であると称する。サブプロセッサの複数の区画は、ＬＰＡＲ内で稼働中のＯＳには見えない態様で、１セットの仮想プロセッサ間で物理プロセッサをタイム・シェアする。ＯＳ内のマルチプログラミングでは、スレッドは、割り込み禁止のモードで稼働することにより、物理プロセッサの制御を維持することができる。これに対し、サブプロセッサ区画では、スレッドは、その仮想プロセッサのタイム・スライスの終わりにハイパーバイザによって依然として優先使用され、その結果、物理プロセッサを異なる仮想プロセッサに利用可能にすることができる。
【００１９】
ハイパーバイザ１１１は、アプリケーション１０６及びＯＳ１０８の実行環境を提供する、ＬＰＡＲ１０３に仮想資源を割り振る。さらに、ハイパーバイザ１１１は、アプリケーション１０７及びゲストＯＳ１１７の実行環境を提供する、ＬＰＡＲ１０５に仮想資源を割り振る。各アプリケーション１０６、１０７は、ユーザ・レベルのデータ処理を実装する１セットのプログラム命令である。各アプリケーション１０６、１０７は、それぞれのプログラム命令が単一の計算ノード上で実行されるような独立型のアプリケーションでもよいし、あるいはそれぞれのプログラム命令の各部分が他の計算ノード上で実行中の他の部分と直列又は並列に実行されるような分散型のアプリケーションでもよい。
【００２０】
ゲストＯＳ１１７は、計算ノード１１０上のアプリケーション１０７の実行を制御する。ゲストＯＳ１１７は、ハイパーバイザ１１１によってＬＰＡＲ１０５に割り振られた仮想資源を管理するシステム・ソフトウェアである。ゲストＯＳ１１７が遂行する基本的作業は、仮想メモリの制御及び割り振り、命令の処理の優先順位付け、仮想化入出力装置の制御、ネットワーキングの支援、仮想化ファイル・システムの管理などを含む。
【００２１】
同様に、ＯＳ１０８は、計算ノード１１０の上のアプリケーション１０６の実行を制御する。アプリケーション１０６は、カーネル１０９を通して、ＯＳ１０８によって提供される資源にアクセスする。カーネル１０９は、ＯＳ１０８のコア・コンポーネントであって、システムの資源を管理するとともに、ハイパーバイザ１１１によって提供される仮想資源とアプリケーションとの間の通信を管理する。カーネル１０９は、アプリケーションに仮想ハードウェア資源の抽象化層を提供することにより、当該アプリケーションがかかる仮想ハードウェア資源を利用することを可能にする。カーネル１０９は、プロセス間通信機構及びカーネルのアプリケーション・プログラム・インタフェース（以下「ＡＰＩ」と略記）１１９を通して、これらの抽象化層をユーザ・レベルのアプリケーションに利用可能にする。
【００２２】
ハイパーバイザ１１１は、カーネル・プロキシ１２０及びＯＳサービス１２４を使用して、ＯＳ１０８の実装の多くを行うように構成される。カーネル・プロキシ１２０は、一般に、ＯＳのカーネル内に実装されるＯＳサービスを提供するシステム・ソフトウェアである。ＯＳ１０８がハイパーバイザ１１１内に構成されるサービスを必要とする場合、カーネル１０９は、カーネル・プロキシ１２０が当該サービスを遂行することを要求する。カーネル１０９は、プロセス間通信を使用するか、又はカーネル・プロキシＡＰＩ１２１を通して、カーネル・プロキシ１２０にアクセスする。ＯＳ１０８の実装をできるだけ多く行うようにハイパーバイザ１１１を構成すると、非常に軽量のＯＳを有利に提供することができる。
【００２３】
カーネル・プロキシ１２０とＯＳサービス１２４との間の関係は、マイクロカーネル・アーキテクチャに基づいて作られる。すなわち、カーネル・プロキシ１２０は、メモリ管理、プロセス管理及びプロセス間通信のようなＯＳサービスの基本タイプの実装を含む。しかし、他のＯＳサービス１２４（例えば、ネットワーキング、割り込み処理、Ｉ／Ｏスケジューリング、デバイス・ドライバ、ファイルシステム・サービスなど）は、別個のＯＳコンポーネントを使用して実装され、当該各コンポーネントは、カーネル・プロキシ１２０とは異なるスレッドを有する。カーネル・プロキシ１２０は、プロセス間通信又はサービスＡＰＩ１２５へのシステム・コールを使用して、これらのＯＳサービス１２４にアクセスする。
【００２４】
各ＯＳサービス１２４は、カーネル・プロキシ１２０それ自体の内部で実装されないサービス・タイプを実装するか、又はカーネル・プロキシ１２０によって既に提供されているサービス・タイプの特殊バージョンを実装するシステム・ソフトウェアである。この点を説明するため、カーネル・プロキシ１２０がファイルシステム・サービス・タイプのいかなるサービスをも実装していない、という第１の例を考察する。この第１の例では、ＯＳサービス１２４のうち１つは、ＵＮＩＸ（登録商標）ファイル・システム用のファイルシステム・サービスを実装し、第２のＯＳサービス１２４は、Ｒｅｉｓｅｒファイル・システム用のファイルシステム・サービスを実装することができる。カーネル・プロキシ１２０は、ハイパーバイザ１１１内に構成されるカーネル・ポリシ１２２に依存して、ＵＮＩＸ（登録商標）ファイル・システム又はＲｅｉｓｅｒファイル・システムを使用して、ファイルシステム・サービスを提供するであろう。さらに、カーネル・プロキシ１２０が一般的なメモリ管理サービスを実装している、という第２の例を考察する。この第２の例では、ＯＳサービス１２４のうち１つは、集中的な入出力動作に適合したメモリ管理サービスを実装することができ、その結果、カーネル・プロキシ１２０は、カーネル・ポリシ１２２の構成に依存して、カーネル・プロキシ１２０内に実装された一般的なメモリ管理アルゴリズムを使用する代わりに、集中的な入出力動作に適合したメモリ管理サービスを使用することができる。
【００２５】
各ＯＳサービス１２４は、特定サービス・タイプのＯＳサービスを提供する。ＯＳサービス１２４によって提供されるサービス・タイプは、例えば、タスク・スケジューラ、ファイル・システム、メモリ管理、デバイス・ドライバ、Ｉ／Ｏスケジューラ、割り込み／信号処理、セキュリティ、ジョブ・サブミッション、ｔｔｙ（teletypewriter）処理などを含む。同じサービス・タイプのＯＳサービス１２４は、同じＡＰＩを有する。すなわち、特定のサービス・タイプを有する各ＯＳサービス１２４用のサービスＡＰＩ１２５は、同じ１セットのメンバ・メソッド及びパラメータを有しており、カーネル・プロキシ１２０はこれを使用してＯＳサービス１２４にアクセスすることができる。各サービス・タイプのサービスが同じサービスＡＰＩを有しているという理由で、カーネル・プロキシ１２０は、特定のサービス・タイプについてカーネル・ポリシ１２２内でどのＯＳサービスが指定されるかに拘わらず、同じＡＰＩを使用して、カーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスすることができる。
【００２６】
図１のコンピュータ・システム１００では、１つ以上のＯＳサービス１２４は、ＯＳサービス・ノード１１２、１１４、１１６の間に分散される。すなわち、２つ以上のＯＳサービス１２４を実装するプログラム命令は、ＯＳサービス・ノード１１２、１１４、１１６上に存在する。ＯＳサービス１３２、１３４、１３６用の対応するＯＳサービス１２４は、各ＯＳサービス１３２、１３４、１３６を実装するプログラム命令のコピーとして実装することができる。また、ＯＳサービス１３２、１３４、１３６用の対応するＯＳサービス１２４は、ＯＳサービス・ノード１１２、１１４、１１６上のＯＳサービス１３２、１３４、１３６にアクセスするデータ通信サブシステムを使用して実装することができる。かかるデータ通信サブシステムは、例えば、ウェブ・サービス・エンジンとして実装することができるし、リモート・プロシージャ・コールを使用してＯＳサービス・ノード１１２、１１４、１１６上のＯＳサービス１３２、１３４、１３６にアクセスする、計算ノード１１０の上のＣＯＲＢＡオブジェクトとして、あるいはＭＰＩライブラリなどを使用して実装することができる。
【００２７】
「ＣＯＲＢＡ」は、「Common ObjectRequest Broker Architecture」の略称であり、ObjectManagement Group（ＯＭＧ）によって策定された相互運用可能な企業アプリケーション用の仕様を指す。ＣＯＲＢＡは、１９９１年にＯＭＧによって最初に公表されたリモート・プロシージャ・コールのための仕様である。ＣＯＲＢＡは、通常のリモート・プロシージャ・コールには存在しない機能をサポートするが、リモート・プロシージャ・コールを行うための一種のオブジェクト指向の方法と考えることができる。ＣＯＲＢＡは、オブジェクトのインタフェースを記述するために、宣言型言語であるインタフェース定義言語（ＩＤＬ）を使用する。ＩＤＬで書かれたインタフェース記述は、クライアント側の「スタブ」及びサーバ側の「スケルトン」を生成するようにコンパイルされる。この生成コードを使用すると、Ｃ＋＋又はＪａｖａ（登録商標）のようなオブジェクト指向プログラミング言語によって行われる遠隔メソッドの呼び出しは、ローカル・オブジェクト内のローカル・メンバメソッドの呼び出しのように見える。
【００２８】
「ＭＰＩ」は、「Message PassingInterface」の略称であり、既存の並列通信ライブラリ、すなわち並列コンピュータ上のデータ通信用のプログラム命令のモジュールを指す。本発明の実施形態に有用な既存の並列通信ライブラリの例には、ＭＰＩ及び「Parallel Virtual Machine」（ＰＶＭ）ライブラリがある。ＰＶＭは、テネシー大学、オークリッジ国立研究所及びエモリー大学によって開発された。ＭＰＩは、ＭＰＩフォーラム（ＭＰＩ仕様を定義及び維持する多くの組織からの代表者で構成されたオープン・グループ）によって公表される。ＭＰＩは、分散メモリ型の並列コンピュータ上で並列プログラムを稼働させているノード間の通信を行うための業界標準である。説明の便宜上、本明細書では、ＭＰＩの用語を使用することもあるが、このことは、本発明を限定するものではない。
【００２９】
各ＯＳサービス・ノード１１２、１１４、１１６は、ラック１０４に取り付けられたノード１０２を使用して実装される。各ＯＳサービス・ノード１１２、１１４、１１６は、計算ノード１１０上にインストールされたハイパーバイザ１１１に対し、ＯＳサービスを提供するノードである。各ＯＳサービス・ノード１１２、１１４、１１６は、１つ以上の計算ノード上で稼働中の１つ以上のハイパーバイザに対し、１つ以上のＯＳサービスを提供することができる。しかし、多くのノードを備えた分散コンピュータ・システムでは、各ＯＳサービス・ノード１１２、１１４、１１６は、当該システム内の豊富なノードに起因して、１つだけのＯＳサービスを提供するのが普通である。図１の例では、ＯＳサービス・ノード１１２はカーネル・プロキシ１２０にＯＳサービス１３２を提供し、ＯＳサービス・ノード１１４はカーネル・プロキシ１２０にＯＳサービス１３４を提供し、ＯＳサービス・ノード１１６はカーネル・プロキシ１２０にＯＳサービス１３６を提供する。
【００３０】
カーネル・プロキシ１２０にＯＳサービスを提供するために、各ＯＳサービス・ノード１１２、１１４、１１６は、それぞれの上にＯＳサービス・サーバをインストールしている。すなわち、ＯＳサービス・ノード１１２はＯＳサービス・サーバ１３３を含み、ＯＳサービス・ノード１１４はＯＳサービス・サーバ１３５を含み、ＯＳサービス・ノード１１６はＯＳサービス・サーバ１３７を含む。各ＯＳサービス・サーバ１３３、１３５、１３７は、ハイパーバイザ１１１によって送信された要求に応答して、又はシステム管理者からの命令を受け取ることに応答して、ハイパーバイザ１１１にＯＳサービスを提供するソフトウェア・コンポーネントである。各ＯＳサービス・サーバ１３３、１３５、１３７は、要求されたＯＳサービスを実装するプログラム命令をハイパーバイザ１１１に送信するとともに、ハイパーバイザ１１１をインストールした計算ノード１１０がこれらのプログラム命令を実行するのを許可することにより、ハイパーバイザ１１１に当該ＯＳサービスを提供することができる。また、各ＯＳサービス・サーバ１３３、１３５、１３７は、要求されたＯＳサービスを実装するプログラム命令を実行するように、ＯＳサービス・サーバをインストールしたＯＳサービス・ノードに命令することにより、当該ＯＳサービスを提供することができる。ハイパーバイザ１１１のカーネル・プロキシ１２０は、各ＯＳサービス・サーバ１３３、１３５、１３７と通信するために、ＣＯＲＢＡオブジェクトの呼び出し用メンバ・メソッドを使用するか、ＭＰＩライブラリなどを使用することができる。
【００３１】
前述のように、ハイパーバイザ１１１は、特定のサービス・タイプ用の２つ以上のＯＳサービス１２４を含む。例えば、ハイパーバイザ１１１は、コンピュータ・システム１００の構成に依存して、カーネル・プロキシ１２０が使用すべきファイルシステム・サービスの２つの異なる実装を含むことができる。他の例では、ハイパーバイザ１１１は、アプリケーション１０６の必要性に依存して、メモリ管理サービスの２つの異なる実装を含むことができる。特定のサービス・タイプについて複数のＯＳサービスを有すると、計算ノード１１０のハードウェア及びソフトウェア環境に従って、ＯＳのサービス・アルゴリズムを柔軟に最適化することができる。
【００３２】
カーネル・ポリシ１２２は、ＯＳサービス１２４のうち１つをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。一般に、カーネル・ポリシ１２２は、計算ノード１１０上の実行のために構成されたアプリケーション１０６によるノード資源の利用を最適化するように、計算ノード１１０上で設定される。カーネル・プロキシ１２０は、カーネル・ポリシ１２２を使用することにより、特定のサービス・タイプについてハイパーバイザ１１１内で使用すべきＯＳサービスを識別する。ＯＳサービス１２４が計算ノード１１０上にローカルに存在するか、又はＯＳサービス・ノード１１２、１１４、１１６のような他のノード上に分散されるかどうかに拘わらず、カーネル・ポリシ１２２は、ハイパーバイザ１１１内で使用すべき特定のサービス・タイプの１つのＯＳサービスを指定する。さらに、カーネル・ポリシ１２２内で指定されたＯＳサービスがＯＳサービス・ノード１１２、１１４、１１６のうち１つに分散される場合、カーネル・ポリシ１２２は、当該指定されたＯＳサービスを提供すべきＯＳサービス・ノードを指定する。カーネル・ポリシ１２２を使用すると、カーネル・プロキシ１２０は、カーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスすることにより、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供することができる。
【００３３】
しばしば、カーネル・ポリシ１２２は、ハイパーバイザ１１１内で使用される１つのサービス・タイプ用のＯＳサービスを指定しないか、又はカーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスできないこともある。従って、ハイパーバイザ１１１は、デフォルトＯＳサービス１２６を含む。このデフォルトＯＳサービス１２６は、カーネル・ポリシ１２２が特定のサービス・タイプ用のＯＳサービスを指定しないか、又はカーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスすることができないようなときに、カーネル・プロキシ１２０が使用することができる特定のサービス・タイプのＯＳサービスである。この点を説明するため、カーネル・ポリシ１２２がハイパーバイザ１１１によって使用すべきファイルシステム・サービスを指定せず、カーネル・プロキシ１２０がファイルシステム・サービスそれ自体を実装せず、そしてデフォルトＯＳサービス１２６がＵＮＩＸ（登録商標）ファイル・システムを実装している、という例を考察する。この例では、カーネル・プロキシ１２０がファイルシステム・サービスを実装せず、ファイルシステム・サービスがカーネル・ポリシ１２２内で指定されないという理由で、カーネル・プロキシ１２０は、ＵＮＩＸ（登録商標）ファイル・システムを実装するデフォルトＯＳサービス１２６を使用するであろう。カーネル・プロキシ１２０は、プロセス間通信又はデフォルトＯＳサービスＡＰＩ１２７を使用して、デフォルトＯＳサービス１２６にアクセスすることができる。
【００３４】
分散コンピュータ・システム１００は、管理ノード１１８を通して、システム管理者１３０によって構成される。管理ノード１１８は、コンピュータ・システム１００の構成を処理する計算装置である。管理ノード１１８は、ラック１０４に取り付けられたノード１０２のうち１つとして、ノード１０２に接続されたワークステーション・ネットワークとして、又は当業者には周知の他のコンピュータとして実装することができる。
【００３５】
図１のコンピュータ・システム１００では、管理ノード１１８は、その上に管理モジュール１２８をインストールしている。管理モジュール１２８は、システム管理者１３０がそれを通してコンピュータ・システム１００を構成するソフトウェア・コンポーネントである。管理モジュール１２８は、システム管理者１３０がコンピュータ・システム１００を構成できるようにするため、システム管理者１３０が管理モジュール１２８と対話するためのユーザ・インタフェースを提供するとともに、システム管理者１３０によって１つ以上の計算ノード（例えば、計算ノード１１０）上に提供されたハイパーバイザ１１１、ＯＳ１０８、ゲストＯＳ１１７、アプリケーション１０６、１０７を構成する。管理モジュール１２８は、カーネル・プロキシ１２０が使用すべきサービス・タイプのＯＳサービス１２４のうち１つを指定するカーネル・ポリシ１２２を計算ノード１１０上に設定することにより、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するための１セットのプログラム命令を含む。
【００３６】
コンピュータ・システム１００を構成するサーバ及び他の装置の配置は、説明上のものであって、本発明を限定するものではない。当業者には明らかなように、本発明の種々の実施形態に従ったデータ処理システムは、図１には示されていない追加のサーバ、ルータ、他の装置及びピア・ツー・ピア・アーキテクチャを含むことができる。当業者には明らかなように、かかるデータ処理システム内のネットワークは、伝送制御プロトコル（ＴＣＰ）、インターネット・プロトコル（ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、無線アクセス・プロトコル（ＷＡＰ）、ハンドヘルド・デバイス伝送プロトコル（ＨＤＴＰ）、ＭＰＩプロトコルなどを含む、多くのデータ通信プロトコルをサポートすることができる。本発明の種々の実施形態は、図１に示されたものに加えて、種々のハードウェア・プラットフォーム上で実装することができる。例えば、コンピュータ・システム１００は、ＩＢＭ社の BlueGene/L のような並列コンピュータとしても実装することができる。
【００３７】
本発明に従ってコンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供することは、一般に、コンピュータを用いて、すなわち自動化計算機械を用いて実装される。例えば、図１のコンピュータ・システム１００では、全てのノードは、少なくともコンピュータとしてある程度まで実装される。従って、さらなる説明のために、図２に示されている計算ノード１１０から成る自動化計算機械は、本発明の実施形態に従って、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するのに有用である。図２の計算ノード１１０は、少なくとも１つのプロセッサ（ＣＰＵ）１５６及びランダム・アクセス・メモリ（ＲＡＭ）１６８を含み、このＲＡＭ１６８は、高速メモリ・バス１６６及びバス・アダプタ１５８を通して、プロセッサ１５６及び計算ノード１１０の他のコンポーネントに接続される。
【００３８】
ＲＡＭ１６８内には、ハイパーバイザ１１１、アプリケーション１０６、１０７、ＯＳ１０８、ゲストＯＳ１１７が格納される。ハイパーバイザ１１１は、アプリケーション１０６及びＯＳ１０８用の実行環境を提供する、ＬＰＡＲ１０３に仮想資源を割り振る。ＯＳ１０８はカーネル１０９を含む。さらに、ハイパーバイザ１１１は、アプリケーション１０７及びゲストＯＳ１１７用の実行環境を提供する、ＬＰＡＲ１０５に仮想資源を割り振る。各ＬＰＡＲ１０３、１０５は、１セットのデータ構造及びサービスであって、単一コンピュータ内の資源の分配を可能にすることにより、あたかも当該コンピュータが２つ以上の独立したコンピュータであるかのように機能させる。
【００３９】
図２のハイパーバイザ１１１は、仮想プロセッサ１１５、カーネル・プロキシ１２０、カーネル・ポリシ１２２、ＯＳサービス１２４及びデフォルトＯＳサービス１２６を含む。カーネル・ポリシ１２２は、ＯＳサービス１２４のうち１つをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。仮想プロセッサ１１５は、ＬＰＡＲへのプロセッサ時間の割り当てを実装するサブシステムである。アプリケーション１０６、１０７、ＯＳ１０８、ゲストＯＳ１１７、カーネル１０９、ハイパーバイザ１１１、カーネル・プロキシ１２０、ＯＳサービス１２４及びデフォルトＯＳサービス１２６は、ソフトウェア・コンポーネントである。すなわち、かかるソフトウェア・コンポーネントの各々は、図１を参照して既に説明したように、計算ノード１１０に関して動作するプログラム命令である。本発明に従って改良することができるＯＳには、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（商標）、ＭｉｃｒｏｓｏｆｔＮＴ（商標）、ＩＢＭ社のＡＩＸ（商標）、ＩＢＭ社のｉ５／ＯＳ（商標）などがある。図２では、ＯＳ１０８、ゲストＯＳ１１７、アプリケーション１０６、１０７、ＬＰＡＲ１０３、１０５、及びハイパーバイザ１１１が、それぞれＲＡＭ１６８内に格納されるように示されているが、かかるソフトウェア・コンポーネントの多くは、不揮発性メモリ（例えば、ディスク・ドライブ１７０）にも格納される。
【００４０】
バス・アダプタ１５８は、高速バスであるフロントサイド・バス１６２及びメモリ・バス１６６用のドライブ・エレクトロニクスに加えて、比較的低速の拡張バス１６０用のドライブ・エレクトロニクスを含む、ハードウェア・コンポーネントである。計算ノード１１０に有用なバス・アダプタ１５８の例には、インテル社のノース・ブリッジ、メモリ・コントローラ・ハブ、サウス・ブリッジ及びＩ／Ｏコントローラ・ハブがある。計算ノード１１０に有用な拡張バス１６０の例には、ＰＣＩバス及びＰＣＩＥｘｐｒｅｓバスがある。
【００４１】
図２には示されていないが、バス・アダプタ１５８は、ビデオ・アダプタと計算ノード１１０の他のコンポーネントの間のデータ通信をサポートするビデオ・バス用のドライブ・エレクトロニクスを含んでいてもよい。かかるビデオ・コンポーネントが図２に示されていない理由は、一般に、計算ノード１１０がブレード・サーバとして実装されていて、専用のビデオ・サポートを持たない並列コンピュータ内のサーバ・シャシ又はノードに取り付けられることにある。しかし、計算ノード１１０が、かかるビデオ・コンポーネントを含んでもよいことは明らかであろう。
【００４２】
ディスクドライブ・アダプタ１７２は、拡張バス１６０及びバス・アダプタ１５８を通して、プロセッサ１５６及び計算ノード１１０の他のコンポーネントに結合される。ディスクドライブ・アダプタ１７２は、ディスク・ドライブ１７０の形態を有する不揮発性のデータ記憶装置を計算ノード１１０に接続する。計算ノード１１０に有用なディスクドライブ・アダプタ１７２の例には、統合ドライブ・エレクトロニクス（ＩＤＥ）アダプタ、小型コンピュータ・システムインタフェース（ＳＣＳＩ）アダプタなどがある。さらに、計算ノード１１０用の不揮発性メモリとして、光ディスク・ドライブ、電気的消去再書き込みＲＯＭ（いわゆる「ＥＥＰＲＯＭ」あるいは「フラッシュ」メモリ）などを実装することができる。
【００４３】
１つ以上の入出力（Ｉ／Ｏ）アダプタ１７８は、ディスプレイ装置への出力を制御したり、キーボードやマウスのようなユーザ入力装置１８１からのユーザ入力を制御するために、例えばソフトウェア・ドライバ及びハードウェアを通して、ユーザ向きの入出力を実装する。図２には示されていないが、他の実施形態に従った計算ノードは、Ｉ／Ｏアダプタ１７８の１例として、ディスプレイ装置へグラフィック出力を供給するように特別に設計されたビデオ・アダプタを含むことができる。一般に、かかるビデオ・アダプタは、高速のビデオ・バス、バス・アダプタ１５８及びフロントサイド・バス１６２を通して、プロセッサ１５６に接続される。
【００４４】
通信アダプタ１６７は、他のコンピュータ１８２及びデータ通信ネットワーク１０１とのデータ通信を行うためのものである。かかるデータ通信は、ＲＳ−２３２接続を通して、ユニバーサル・シリアル・バス（ＵＳＢ）のような外部バスを通して、ＩＰデータ通信ネットワークのようなデータ通信ネットワークなどを通して、行うことができる。通信アダプタは、データ通信のハードウェア・レベルを実装し、これを通して、１つのコンピュータは、直接に又はデータ通信ネットワークを通して、データを他のコンピュータに送信する。計算ノード１１０に有用な通信アダプタ１６７の例には、有線式ダイアルアップ通信用のモデム、有線式データ通信ネットワーク通信用のＩＥＥＥ ８０２．３イーサネット（登録商標）・アダプタ及び無線式データ通信ネットワーク通信用のＩＥＥＥ ８０２．１１ｂアダプタがある。
【００４５】
以上、図２を参照して計算ノード１１０を説明したが、これと同様な自動化計算機械が、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するのに有用なＯＳサービス・ノード及び管理ノードから構成されることに留意すべきである。かかるＯＳサービス・ノード及び管理ノードは、図２の計算ノード１１０と同様に、１つ以上のプロセッサ、バス・アダプタ、バス、ＲＡＭ、通信アダプタ、Ｉ／Ｏアダプタ、ディスクドライブ・アダプタなどを含む。
【００４６】
次に、図３を参照して、ハイパーバイザ１１１によるＬＰＡＲへの仮想プロセッサの割り振りをさらに詳細に説明する。図３は、ハイパーバイザ１１１で構成された、本発明の実施形態に従った計算ノード３００を示す機能ブロック図である。
【００４７】
計算ノード３００は、ＬＰＡＲ３０２及びＬＰＡＲ３０４を含む。計算ノード３００内に含まれる２つのＯＳ３０及びＯＳ３０８は、ＬＰＡＲ３０２及びＬＰＡＲ３０４内にそれぞれ常駐する。計算ノード３００は、６つの論理プロセッサ（ＬＰ）３２０〜３２５を含み、そのうちの２つはＬＰＡＲ３０２内のＯＳ３０８用のものであり、他の４つはＬＰＡＲ３０４内のＯＳ３０８用のものである。論理プロセッサは、実行すべきスレッドをスケジュールするためのＯＳの構造である。論理プロセッサは、スレッドの実行を行うことができるプロセッサの資源の一部を表す。６つのスレッド（Ｔ）３１０〜３１５が、論理プロセッサ当たり１つのスレッドずつ、６つの論理プロセッサ３２０〜３２５上でそれぞれ稼働する。計算ノード３００は、ハイパーバイザ１１１及び４つの仮想プロセッサ（ＶＰ）３３０〜３３３を含み、そのうちの２つの仮想プロセッサ３３０及び３３１はＬＰＡＲ３０２に割り当てられ、他の２つの仮想プロセッサ３３２及び３３３はＬＰＡＲ３０４に割り当てられる。
【００４８】
さらに、計算ノード３００は、３つの物理プロセッサ３４０、３４２、３４４を含む。この例では、物理プロセッサ３４０、３４２、３４４は、処理単位に応じて共有される（但し、１.０の処理単位は、１つの物理プロセッサの処理能力を表す）。この例では、３つの物理プロセッサ３４０、３４２、３４４の処理能力は、以下のようにＬＰＡＲに配分される。
【００４９】
１．物理プロセッサ３４０の全ての処理能力が、仮想プロセッサ３３０に割り当てられる。その結果、論理プロセッサ３２０は、物理プロセッサ３４０の全ての処理能力を利用することができる。
【００５０】
２．物理プロセッサ３４２の処理能力の半分が、仮想プロセッサ３３１に割り当てられる。その結果、論理プロセッサ３２１は、（タイム・スライスにより）物理プロセッサ３４２の処理能力の半分を利用することができる。
【００５１】
３．物理プロセッサ３４２の処理能力の他の半分が、仮想プロセッサ３３２に割り当てられる。仮想プロセッサ３３２が割り当てられるＬＰＡＲ３０４では、仮想プロセッサ３３２に対応する２つの論理プロセッサ３２２及び３２３が、同時的なマルチスレッディング・モードで稼働中である。その結果、論理プロセッサ３２２及び３２３の各々は、（タイム・スライスにより）物理プロセッサ３４２の処理能力の４分の１をそれぞれ利用することができる。
【００５２】
４．物理プロセッサ３４４の全ての処理能力が、仮想プロセッサ３３３に割り当てられる。仮想プロセッサ３３３が割り当てられるＬＰＡＲ３０４では、仮想プロセッサ３３３に対応する２つの論理プロセッサ３２４及び３２５が、同時的なマルチスレッディング・モードで稼働中である。その結果、論理プロセッサ３２４及び３２５の各々は、（タイム・スライスにより）物理プロセッサ３４４の処理能力の半分をそれぞれ利用することができる。
【００５３】
計算ノード３００内の物理プロセッサ、仮想プロセッサ及び論理プロセッサの数、配置及び割り当ては、説明上のものであって、本発明を限定するものではない。本発明の実施形態に従った計算ノードは、多数のＬＰＡＲをサポートすることができ、物理プロセッサ、仮想プロセッサ及び論理プロセッサの任意の数、配置又は割り当てを含むことができる。
【００５４】
図４は、本発明の実施形態に従った方法のフローチャートを示す。図４の例では、コンピュータ・システムは、少なくとも１つの計算ノードを含む。計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び一のサービス・タイプの複数のＯＳサービスを含む。
【００５５】
図４の方法は、計算ノード上で、カーネル・プロキシ１２０が使用すべきサービス・タイプのＯＳサービスのうち１つを指定するカーネル・ポリシ１２２を設定するステップ４００を含む。カーネル・ポリシ１２２は、ＯＳサービスのうち１つをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。図４の例では、カーネル・ポリシ１２２の各レコードは、特定のサービス・タイプについてカーネル・プロキシ１２０がどのＯＳサービスを使用すべきかを識別する。かかる識別を行うため、カーネル・ポリシ１２２の各レコードは、ＯＳサービス識別子４０２及びサービス・タイプ４０４を含む。カーネル・ポリシ１２２内で指定されるＯＳサービス・タイプ４０４の例には、タスク・スケジューラ、ファイル・システム、メモリ管理、デバイス・ドライバ、Ｉ／Ｏスケジューラ、割り込み／信号処理、セキュリティ、ジョブ・サブミッション、ｔｔｙ（teletypewriter）処理などがある。本発明の実施形態に従ったカーネル・ポリシ１２２の例については、以下の表を参照されたい。
【００５６】
【表１】
【００５７】
表１のカーネル・ポリシ１２２では、ＯＳサービス識別子４０２の値「UFS_Service」をサービス・タイプ４０４の値「File_System」に関連づけることは、カーネル・プロキシ１２０がファイルシステム・サービス・タイプにアクセスする必要があるとき、カーネル・プロキシ１２０がＵＮＩＸ（登録商標）ファイル・システムを実装するＯＳサービスを使用することを指定する。ＯＳサービス識別子４０２の値「Round_Robin_MM_Algorithm」をサービス・タイプ４０４の値「Memory_Management」に関連づけることは、カーネル・プロキシ１２０がメモリ管理サービス・タイプにアクセスする必要があるとき、カーネル・プロキシ１２０がラウンドロビン・アルゴリズムを実装するＯＳサービスを使用することを指定する。ＯＳサービス識別子４０２の値「Limited_Ｉ／Ｏ_Access」をサービス・タイプ４０４の値「I/O_Scheduler」に関連づけることは、カーネル・プロキシ１２０がＩ／Ｏスケジューラ・サービス・タイプを使用するとき、カーネル・プロキシ１２０が制限されたＩ／Ｏアクセスを実装するＯＳサービスを使用することを指定する。表１のカーネル・ポリシ１２２は、説明用のものであって、本発明を限定するものではない。本発明の実施形態では、当業者には周知の他のカーネル・プロキシも使用することができる。
【００５８】
図４の設定ステップ４００は、管理モジュール１２８において、システム管理者１３０からＯＳサービスとサービス・タイプとの間のマッピングを受け取り、管理モジュール１２８によって、当該マッピングに従ったカーネル・ポリシ１２２を計算ノード上で作成することにより、実施することができる。管理モジュール１２８は、計算ノードを含むコンピュータ・システムを構成するためにシステム管理者１３０が使用することができる、ソフトウェア・コンポーネントである。カーネル・ポリシ１２２を作成するための管理モジュール１２８をインストールしている特定の計算ノードは、一般に、当該管理モジュール１２８によって提供されるユーザ・インタフェースを通して、システム管理者１３０によって指定される。管理モジュール１２８は、この計算ノード上に直接インストールするか、又はこの計算ノードに接続された他のコンピュータ・ネットワークにインストールすることができる。管理モジュール１２８は、共有メモリ空間、ＣＯＲＢＡフレームワーク、ＪＴＡＧネットワーク、ウェブ・サービス、ＭＰＩライブラリなどを使用して実装されたデータ通信接続を通して、計算ノード上にカーネル・ポリシ１２２を作成することができる。
【００５９】
「ＪＴＡＧ」は、バウンダリ・スキャンを使用してプリント配線回路ボードをテストするために使用される、「Standard Test Access Port and Boundary-Scan Architecture 」と題する、ＩＥＥＥ １１４９．１標準の俗称である。ＪＴＡＧは、非常に広汎に使用されているので、バウンダリ・スキャンと殆ど同義である。ＪＴＡＧは、プリント配線回路ボードだけでなく、集積回路のバウンダリ・スキャンを行うためにも使用され、さらに、組み込みシステムをデバッグするための機構として、当該システムへの便利な「バック・ドア」を提供するのに有用である。ＪＴＡＧネットワークを使用すると、管理モジュール１２８は、本発明の実施形態に従った、計算ノード内のプロセッサ・レジスタ及びメモリを効率的に構成することができる。
【００６０】
図４の指定ステップ４０１は、カーネル・プロキシ１２０によって、カーネル・プロキシ１２０が使用すべきサービス・タイプ４０５を指定する。カーネル・プロキシ１２０は、実行フローに沿った特定の点でカーネル・プロキシ１２０を実装するプログラム命令内にサービス・タイプ４０５を保持する命令を含めることにより、ハイパーバイザ内の使用すべきサービス・タイプ４０５を指定することができる。例えば、カーネル・プロキシ１２０用の実行フローに沿った特定の点で、カーネル・プロキシ１２０を実装するプログラム命令は、次の命令を表す機械コードを含むことができる。
【００６１】
Execute_Service（File_System）;
【００６２】
この命令内の機能「Execute_Service」は、カーネル・プロキシ１２０に対し、「File_System」の値を有するサービス・タイプ４０５についてカーネル・ポリシ１２２内で指定されたＯＳサービスを実行するように命令する機能である。この命令をカーネル・プロキシ１２０を実装するプログラム命令内に含めると、ハイパーバイザ１１１がファイルシステム・サービス・タイプのサービスを使用することを指定する。この命令は、説明用のものであって、本発明を限定するものではない。本発明の実施形態では、当業者には周知の他の命令も使用することができる。
【００６３】
図４の検索ステップ４０３は、カーネル・プロキシ１２０によって、指定されたサービス・タイプ４０５に依存して、カーネル・ポリシ１２２から指定されたＯＳサービス４０７を検索することを含む。検索ステップ４０３は、カーネル・ポリシ１２２内で、指定されたサービス・タイプ４０５と同じ値を有するサービス・タイプ４０４に関連するＯＳサービス識別子４０２を検索することにより、実施することができる。
【００６４】
図４の判定ステップ４０６は、カーネル・プロキシ１２０によって、カーネル・プロキシ１２０が指定されたＯＳサービス４０７にアクセスすることができるか否かを判定する。判定ステップ４０６は、指定されたＯＳサービス４０７用のＡＰＩの関数を呼び出すことにより、実施することができる。もし、この関数呼び出しがカーネル・プロキシ１２０に対しエラーを返すのであれば、カーネル・プロキシ１２０は、指定されたＯＳサービスにアクセスすることができない。一方、この関数呼び出しがカーネル・プロキシ１２０に対しエラーを返さなければ、カーネル・プロキシ１２０は、指定されたＯＳサービスにアクセスすることができる。前述のように、同じサービス・タイプ用のＯＳサービスは、同じＡＰＩを有することができる。各サービス・タイプ用のＡＰＩは、カーネル・プロキシ１２０を実装するプログラム命令内にコード化することができる。
【００６５】
図４の実行ステップ４０８は、カーネル・プロキシ１２０が指定されたＯＳサービス４０７にアクセスすることができない場合、計算ノードによって、サービス・タイプ４０４のデフォルトＯＳサービスを実装するプログラム命令を実行することを含む。実行ステップ４０８は、デフォルト・サービス・テーブル４１２内で、サービス・タイプ４０４に関連するデフォルトＯＳサービス識別子４１４を検索するとともに、このデフォルトＯＳサービス識別子４１４によって表わされるデフォルトＯＳサービス用のＡＰＩの関数を呼び出すことにより、実施することができる。デフォルト・サービス・テーブル４１２は、カーネル・ポリシ１２２に類似している。デフォルト・サービス・テーブル４１２の各レコードは、特定のサービス・タイプについてハイパーバイザ内のどのデフォルトＯＳサービスを使用すべきかを識別する。デフォルト・サービス・テーブル４１２の各レコードは、デフォルトＯＳサービス識別子４１４及びサービス・タイプ４０４を含む。デフォルトＯＳサービスは、図４のデフォルト・サービス・テーブル４１２内で指定されるが、かかる実施形態は、説明用のものであって、本発明を限定するものではない。他の実施形態では、カーネル・ポリシ１２２内のフィールドを使用して、特定のサービス・タイプについてＯＳ内の使用すべきデフォルトＯＳサービスを指定することができるし、あるいは、各サービス・タイプ用のデフォルト・サービスをカーネル・プロキシ１２０それ自体にコード化することができる。
【００６６】
図４のアクセス・ステップ４１０は、カーネル・プロキシ１２０によって、指定されたＯＳサービス４０７にアクセスすることを含む。アクセス・ステップ４１０は、指定されたＯＳサービス４０７用のＡＰＩの関数を呼び出すことにより、実施することができる。しかし、かかる実施形態は、説明用のものであって、本発明を限定するものではない。他の実施形態では、管理モジュール１２８は、カーネル・ポリシ１２２に従って、カーネル・プロキシ１２０のコード内にある入口及び出口フックを修正することにより、実行フロー中のカーネル・プロキシ１２０のコード内の適切な点で、プロセッサの制御がカーネル・プロキシ１２０からＯＳサービスまで移動されるようにすることができる。そのような例では、アクセス・ステップ４１０は、単にカーネル・プロキシ１２０を実装するプログラム命令を実行することにより、実施することができる。
【００６７】
前述のように、ＯＳサービスは、分散コンピュータ・システム内の１つ以上のＯＳサービス・ノード間に分散することができる。このような場合、アクセス・ステップ４１０は、ＯＳサービス・ノードから指定されたＯＳサービスを実装するプログラム命令を検索するとともに、計算ノードによって、指定されたＯＳサービスを実装するプログラム命令を実行することにより、実施することができる（図６の説明を参照）。また、アクセス・ステップ４１０は、カーネル・プロキシ１２０によって、ＯＳサービス・ノードが指定されたＯＳサービスを実行するように要求するとともに、当該ＯＳサービス・ノードによって、指定されたＯＳサービスを実装するプログラム命令を実行することにより、実施することができる（図７の説明を参照）。
【００６８】
前述のように、カーネル・ポリシ１２２は、特定のＯＳサービスをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。しかし、カーネル・ポリシ１２２は、ＯＳサービスをカーネル・プロキシ１２０によって使用されるサービスの各タイプにマップできないことがある。そのため、カーネル・プロキシ１２０は、しばしばカーネル・ポリシ１２２が特定のサービス・タイプ用のＯＳサービスを指定するか否かを識別し、カーネル・ポリシ１２２が指定されたサービス・タイプのＯＳサービスを指定しないときには、指定されたサービス・タイプのデフォルトＯＳサービスを実装するプログラム命令を実行する。従って、さらなる説明のために、図５は、本発明の実施形態に従った他の方法のフローチャートを示す。図５の方法は、カーネル・プロキシ１２０によって、カーネル・ポリシ１２２が指定されたサービス・タイプ４０５のＯＳサービスを指定するか否かを識別するステップ５００を含む。図５の例では、コンピュータ・システムは、少なくとも１つの計算ノードを含む。この計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び１つのサービス・タイプの複数のＯＳサービスを含む。
【００６９】
図５の方法は、図４の方法における設定ステップ４００、指定ステップ４０１、検索ステップ４０３及びアクセス・ステップ４１０を含むという点で、図４の方法に類似している。さらに、図５の例は、図４の例におけるデフォルト・サービス・テーブル４１２を含み、当該テーブル４１２の各レコードがデフォルトＯＳサービス識別子４１４及びサービス・タイプ４０４を含むという点で、図４の例に類似している。
【００７０】
図５の識別ステップ５００は、指定されたサービス・タイプ４０５の値に一致するサービス・タイプ４０４の値を有するレコードを求めて、カーネル・ポリシ１２２を探索することにより、実施することができる。もし、かかるレコードが見つからなければ、カーネル・ポリシ１２２は、指定されたサービス・タイプ４０５のＯＳサービスを指定しない。一方、かかるレコードが見つかれば、カーネル・ポリシ１２２は、指定されたサービス・タイプ４０５のＯＳサービスを指定する。しかし、かかる実施の形態は、説明上のものであって、本発明を限定するものではない。他の実施形態では、カーネル・ポリシ１２２は、ＯＳ内で使用すべき各サービス・タイプのレコードを保持することができる。かかる実施形態では、識別ステップ５００は、カーネル・ポリシ１２２内の特定のレコード用のＯＳサービス識別子４０２が、ＮＵＬＬ値を保持しているか否かを識別することにより、実施することができる。
【００７１】
さらに、図５の実行ステップ５０２は、カーネル・ポリシ１２２が指定されたサービス・タイプ４０５のＯＳサービスを指定しないときに、計算ノードによって、指定されたサービス・タイプ４０５のデフォルトＯＳサービスを実装するプログラム命令を実行することを含む。この実行ステップ５０２は、デフォルト・サービス・テーブル４１２において、サービス・タイプ４０４に関連するデフォルトＯＳサービス識別子４１４を検索するとともに、このデフォルトＯＳサービス識別子４１４によって表わされるデフォルトＯＳサービス用のＡＰＩの関数を呼び出すことにより、実施することができる。デフォルトＯＳサービスは、図５のデフォルト・サービス・テーブル４１２内で指定されるが、かかる実施形態は、説明上のものであって、本発明を限定するものではない。他の実施形態では、カーネル・ポリシ１２２内のフィールドを使用して、特定のサービス・タイプについてＯＳ内の使用すべきデフォルトＯＳサービスを指定することができるし、あるいは、各サービス・タイプ用のデフォルト・サービスをカーネル・プロキシ１２０それ自体にコード化することができる。
【００７２】
前述のように、ＯＳサービスは、分散コンピュータ・システム内の１つ以上のＯＳサービス・ノード間に分散することができる。このような場合、アクセス・ステップ４１０は、ＯＳサービス・ノードの指定されたＯＳサービスにアクセスすることにより、実施することができる。従って、さらなる説明のために、図６は、本発明の実施形態に従ったさらに他の方法のフローチャートを示す。図６の方法は、ＯＳサービス・ノードの指定されたＯＳサービス４０７にアクセスするステップ６０２を含む。図６の例では、コンピュータ・システムは、少なくとも１つの計算ノード及び１つ以上のＯＳサービス・ノードを含む、計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び１つのサービス・タイプの複数のＯＳサービスを含む。図６の例では、ＯＳサービスの１つ以上がＯＳサービス・ノード間に分散される。
【００７３】
図６の方法は、図４の方法における設定ステップ４００、指定ステップ４０１、検索ステップ４０３及びアクセス・ステップ４１０を含むという点で、図４の方法に類似している。さらに、図６の例は、カーネル・ポリシ１２２の各レコードがＯＳサービス識別子４０２及びサービス・タイプ４０４を含むという点で、図４の例に類似している。しかし、図６の例では、カーネル・ポリシ１２２は、各レコード内にＯＳサービス・ノード識別子６００を含めることによって、指定されたＯＳサービス４０７を提供すべきＯＳサービス・ノードを指定する。図６の例では、指定されたＯＳサービス４０７は、ＯＳサービス・ノードのうち１つに分散される。
【００７４】
図６のアクセス・ステップ４１０は、ＯＳサービス・ノードの指定されたＯＳサービス４０７にアクセスするステップ６０２を含む。このアクセス・ステップ６０２は、カーネル・プロキシ１２０によって、指定されたＯＳサービス４０７を実装するプログラム命令６０６をＯＳサービス・ノードから検索するステップ６０４により、実施することができる。かかるプログラム命令６０６は、指定されたＯＳサービス４０７を実装する機械コードを表す。かかる表現は、説明上のものであって、本発明を限定するものではない。事実、図６のプログラム命令６０６は、アセンブリ言語又はＪａｖａ（登録商標）のような高水準言語で実装されたプログラム命令を表すことができる。
【００７５】
図６の検索ステップ６０４は、指定されたＯＳサービス４０７が分散されているＯＳサービス・サーバ上のＯＳサービス・サーバに対しＯＳサービス要求を送信し、このＯＳサービス・サーバから、指定されたＯＳサービスを実装するプログラム命令６０６を受信することにより、実施することができる。このＯＳサービス要求は、ＯＳサービス・ノードに対し、ＯＳサービスをハイパーバイザ内のカーネル・プロキシ１２０に提供するように要求するものである。このＯＳサービス要求は、指定されたＯＳサービス４０７用のＯＳサービス識別子４０２を含むことができる。カーネル・プロキシ１２０は、このＯＳサービス要求をＯＳサービス・ノード上のＯＳサービス・サーバに送信した後、ウェブ・サービスを使用するか、ＣＯＲＢＡオブジェクトのメンバ・メソッドを呼び出すか、ＭＰＩライブラリなどを使用して、プログラム命令６０６を検索することができる。
【００７６】
また、図６のアクセス・ステップ６０２は、計算ノードによって、指定されたＯＳサービス６０７を実装するプログラム命令６０６を実行するステップ６０８により、実施することができる。この実行ステップ６０８は、指定されたＯＳサービス６０７を実装するプログラム命令６０６を計算ノード上で実行するようにスケジュールすることにより、実施することができる。前述のように、図６のプログラム命令６０６は、アセンブリ言語又はＪａｖａ（登録商標）のような高水準言語で実装されたプログラム命令を表すことができる。かかる実施形態では、この実行ステップ６０８は、プログラム命令６０６を機械コードへ解釈し、かかる機械コードを計算ノード上で実行するようにスケジュールすることにより、実施することができる。
【００７７】
図６のアクセス・ステップ６０２は、指定されたＯＳサービスを実装するプログラム命令を計算ノード上で実行することにより実施される。しかし、かかるアクセス・ステップ６０２は、指定されたＯＳサービスを実装するプログラム命令をＯＳサービス・ノード上で実行することによっても、実施することができる。従って、さらなる説明のために、図７は、本発明の実施形態に従ったさらに他の方法のフローチャートを示す。図７の方法は、ＯＳサービス・ノードによって、指定されたＯＳサービス４０７を実装するプログラム命令７０６を実行するステップ７０８を含む。図７の例では、コンピュータ・システムは、少なくとも１つの計算ノード及び１つ以上のＯＳサービス・ノードを含む。計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び１つのサービス・タイプの複数のＯＳサービスを含む。図７の例では、ＯＳサービスの１つ以上は、ＯＳサービス・ノード間に分散される。
【００７８】
図７の方法は、図４の方法における設定ステップ４００、指定ステップ４０１、検索ステップ４０３及びアクセス・ステップ４１０を含むという点で、図４の方法に類似している。さらに、図７の例は、カーネル・ポリシ１２２の各レコードがＯＳサービス識別子４０２及びサービス・タイプ４０４を含むという点で、図４の例に類似している。しかし、図７の例では、カーネル・ポリシ１２２は、各レコード内にＯＳサービス・ノード識別子６００を含めることにより、指定されたＯＳサービス４０７を提供すべきＯＳサービス・ノードを指定する。図７の例では、指定されたＯＳサービス４０７は、ＯＳサービス・ノードのうち１つの上に分散される。
【００７９】
図７のアクセス・ステップ４１０は、ＯＳサービス・ノードの指定されたＯＳサービス４０７にアクセスするステップ６０２を含む。このアクセス・ステップ６０２は、カーネル・プロキシ１２０によって、ＯＳサービス・ノードが指定されたＯＳサービスを遂行すべきことを要求するステップ７００を行うとともに、このＯＳサービス・ノードによって、サービス遂行要求７０２を受信するステップ７０４を行うことにより、実施される。要求ステップ７００は、指定されたＯＳサービス４０７が分散されたＯＳサービス・ノード上のＯＳサービス・サーバにサービス遂行要求７０２を送信することにより、実施することができる。サービス遂行要求７０２は、ＯＳサービス・ノードに対し、カーネル・プロキシ１２０用のＯＳサービスを遂行するように要求する。サービス遂行要求７０２は、指定されたＯＳサービス４０７用のＯＳサービス識別子４０２を含むことができる。カーネル・プロキシ１２０は、ウェブ・サービスを使用するか、ＣＯＲＢＡオブジェクトのメンバ・メソッドを呼び出すか、ＭＰＩライブラリなどを使用して、ＯＳサービス・ノード上のＯＳサービス・サーバにサービス遂行要求７０２を送信することができる。
【００８０】
図７のアクセス・ステップ６０２は、ＯＳサービス・ノードによって、指定されたＯＳサービス４０７を実装するプログラム命令７０６を実行するステップ７０８により、実施される。プログラム命令７０６は、指定されたＯＳサービス４０７を実装する機械コードを表す。実行ステップ７０８は、指定されたＯＳサービス４０７を実装するプログラム命令７０６をＯＳサービス・ノード上で実行するようにスケジュールすることにより、実施することができる。プログラム命令７０６を実行した後、ＯＳサービス・ノード上のＯＳサービス・サーバは、実行が成功したか否かを示すメッセージをカーネル・プロキシ１２０へ送信することができる。
【００８１】
本明細書の前述の説明に照らして、本発明の実施形態によれば、次の利点が得られることは明らかであろう。
【００８２】
１．ノードのハードウェア及びソフトウェア環境に基づいたＯＳサービスを提供することにより、軽量のＯＳを含む多数のＯＳをサポートするハイパーバイザで当該ノードを構成する能力。
【００８３】
２．軽量のＯＳをサポートする種々のＯＳサービスを提供することにより、ハイパーバイザによって、当該軽量のＯＳを新しい環境に適応させるか、又は新しい要件を満足させる能力。
【００８４】
３．ＯＳの機能のうち或るものをハイパーバイザ内で実装することにより、当該ハイパーバイザの管理オーバーヘッドを減少させる能力。
【００８５】
本発明の代表的な実施形態は、主として、ハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための完全に機能的なコンピュータ・システムの環境で説明された。しかし、任意の適当なデータ処理システムとともに使用するための信号担持媒体に配置されたコンピュータ・プログラムにおいても、本発明を具体化することができることは明らかであろう。かかる信号担持媒体は、伝送媒体とすることができるし、あるいは磁気媒体、光学媒体、他の適切な媒体などを含む機械可読情報用の記録可能媒体とすることができる。記録可能媒体の例には、ハード・ドライブ又はディスケット内の磁気ディスク、光ドライブ用のコンパクト・ディスク、磁気テープなどがある。伝送媒体の例には、音声通信用の電話網、イーサネット（登録商標）のようなディジタル・データ通信ネットワーク、インターネット・プロトコルを用いたネットワーク、ワールド・ワイド・ウェブ、ＩＥＥＥ ８０２．１１ファミリの規格に従って実装されたネットワークのような無線送信媒体などがある。また、本明細書で説明した代表的な実施形態のうち或るものは、ハードウェア上にインストールされ、そこで実行されるソフトウェアに基づいているが、ファームウェア又はハードウェアとして実装された他の実施形態も本発明の範囲内にあることはもちろんである。
【００８６】
前述の説明から明らかなように、本発明の要旨を逸脱することなく、本発明の種々の実施形態に対し修正及び変更を施すことができる。本明細書中の記述は、説明上のものであって、本発明を限定するものと解釈してはならない。本発明の範囲は、請求項の記載によってのみ定義される。
【図面の簡単な説明】
【００８７】
【図１】本発明の実施形態に従ったコンピュータ・システムを示すネットワーク図である。
【図２】本発明の実施形態に従った計算ノードから成る自動化計算機械を示すブロック図である。
【図３】ハイパーバイザで構成された、本発明の実施形態に従った計算ノードを示す機能ブロック図である。
【図４】本発明の実施形態に従った方法を示すフローチャートである。
【図５】本発明の実施形態に従った他の方法を示すフローチャートである。
【図６】本発明の実施形態に従ったさらに他の方法を示すフローチャートである。
【図７】本発明の実施形態に従ったさらに他の方法を示すフローチャートである。
【符号の説明】
【００８８】
１００ 分散コンピュータ・システム
１０３、１０５ ＬＰＡＲ
１０６、１０７ アプリケーション
１０８ ＯＳ
１０９ カーネル
１１０ 計算ノード
１１１ ハイパーバイザ
１１２、１１４、１１６ ＯＳサービス・ノード
１１７ ゲストＯＳ
１１８ 管理ノード
１１５ 仮想プロセッサ
１２２ カーネル・ポリシ
１２４ ＯＳサービス
１２６ デフォルトＯＳサービス
１２８ 管理モジュール
１３０ システム管理者
１３２、１３４、１３６ ＯＳサービス
１３３、１３５、１３７ ＯＳサービス・サーバ
【技術分野】
【０００１】
本発明はデータ処理に係り、さらに詳細に説明すれば、コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのオペレーティング・システム・サービスを提供する方法、装置及びプログラムに係る。
【背景技術】
【０００２】
１９４８年のＥＤＶＡＣコンピュータ・システムの開発は、コンピュータ時代の始めとしてしばしば引用される。その時以来、コンピュータ・システムは、非常に複雑な装置へ発展した。今日のコンピュータは、ＥＤＶＡＣのような初期のシステムよりはるかに複雑となっている。コンピュータ・システムは、一般に、ハードウェア及びソフトウェア・コンポーネントの組み合わせ、アプリケーション・プログラム、オペレーティング・システム（以下「ＯＳ」と略記）、プロセッサ、バス、メモリ、入出力装置などを含む。半導体処理及びコンピュータ・アーキテクチャの進歩が高いコンピュータの性能をもたらし、精巧なソフトウェアがハードウェアの高い性能を活用するように発展した結果、今日のコンピュータ・システムは、わずか数年前よりはるかに強力になっている。
【０００３】
高性能ハードウェアを利用するためにソフトウェアが発展した１つの領域は、ＯＳである。初期のコンピュータは、どんな形式のＯＳも持っていなかった。システム管理者によってロードされるアプリケーションが、マシンを単独で使用していたからである。コンピュータを動作させるために、アプリケーションは、ハードウェアに直接にアクセスし、これを制御しなければならなかった。その後、サポート・コードのライブラリを備えたコンピュータが出現し、かかるライブラリが入出力のような動作を支援するためにアプリケーションへリンクされた。かかるライブラリは、最近のＯＳの起源であった。しかし、コンピュータは、依然として一度に単一のアプリケーションだけを稼働させるに過ぎなかった。最近のＯＳは、多数のアプリケーションを同時に稼働させることができる。さらに、最近のＯＳは、アプリケーションの開発を簡易化し、かつ１つのハードウェア・プラットフォームから他のハードウェア・プラットフォームへアプリケーションを移植する能力を援助するために、ハードウェアの抽象化層をアプリケーションに提供する。
【０００４】
カーネルは、殆どのＯＳの主要部であって、システムの資源を管理したり、ハードウェア及びソフトウェア・コンポーネント間の通信を管理する。カーネルは、ＯＳの主要部として、ハードウェア（特に、メモリ、プロセッサ、及びＩ／Ｏ）のための抽象化層を提供することにより、ハードウェアとソフトウェアが通信することを可能にする。さらに、カーネルは、プロセス間通信機構及びシステム・コールを通して、これらの機能をアプリケーション及び他のＯＳサービスに利用可能にする。
【０００５】
かかるカーネル・タスクは、カーネルが異なれば、それぞれの設計及び実装に依存して、異なった態様で遂行される。モノリシック・カーネルの場合、全てのＯＳサービスは、同じメモリ領域内に存在し、当該メモリ領域を使用して実行される。このように、モノリシック・カーネルが同じアドレス空間内の全てのコードを実行することを試みるという理由で、モノリシックカーネル・アーキテクチャは、他の解決手段よりも設計及び実装が簡単であり、よく書けている場合は、非常に効率的である。モノリシック・カーネルの主要な欠点は、システム・コンポーネント間の依存関係である。大きなカーネルは、これを維持するのが非常に難しくなり、また、カーネルの１つの部分にバグが存在すると、システム全体をクラッシュさせることがある。
【０００６】
マイクロカーネル・アーキテクチャの場合、カーネルは、最小のＯＳサービス（例えば、メモリ管理、マルチタスキング及びプロセス間通信）を実装するために、１セットのプリミティブ又はシステム・コールによって、ハードウェアに関する単純な抽象化層を提供する。ネットワーキングのようなカーネルによって通常提供されるものを含む他のサービスは、一般に、それ自体のアドレス空間を有するユーザ空間プログラム内で実装される。マイクロ・カーネルは、モノリシック・カーネルよりも維持するのがより簡単であるが、多くのシステム・コール及びコンテキスト・スイッチはシステムの性能を低下させることがある。
【０００７】
ＯＳを実装するために使用されるカーネル・アーキテクチャに拘わらず、最近のＯＳ内に提供される１セットのＯＳサービスは、当該ＯＳがインストールされるとき、固定されることが一般的である。すなわち、かかるＯＳは、当該ＯＳによって管理されるハードウェア上で稼働するアプリケーションを考慮せずに、同じメモリ管理アルゴリズム、同じＩ／Ｏスケジューリング・アルゴリズム、同じネットワーキング・アルゴリズムなどを利用する。しかし、同じ１つのＯＳサービスを利用する場合、１つのアプリケーションが資源を効率的に利用できるのに対し、他のアプリケーションは資源を効率的に利用できない、という事態がしばしば生ずる。例えば、ＯＳ内にＩ／Ｏスケジューリングを提供する一のＯＳサービスは、入出力集中的なアプリケーションが資源を効率的に使用することを可能にするのに対し、入出力集中的でないアプリケーションが資源を効率的に使用することを困難にすることがある。このように、最近のＯＳは、アプリケーションを考慮せずに同じＯＳサービスを提供するという理由で、アプリケーションとハードウェアとの間の相互作用を効率的に管理しないことが多い。従って、当分野では、ＯＳ内にＯＳサービスを提供する態様を改良することが要請されている。
【０００８】
高性能ハードウェアを利用するためにソフトウェアが発展した他の領域は、「ハイパーバイザ」と呼ばれるソフトウェア・ツールのセットである。ハイパーバイザは、ハードウェア上でＯＳ層の下で稼働するシステム・ソフトウェアの層であって、ホスト・コンピュータ上で多数のＯＳが未変更のまま同時に稼働することを可能にする。ハイパーバイザが最初に開発された１９７０年代の初めには、企業の経費を削減することを目標として、それまで多数の部門に散在していた多数のコンピュータを単一の大型コンピュータ（メインフレーム）に統合して、多数の部門にサービスを提供することが一般に行われていた。ハイパーバイザは、多数のＯＳを同時に稼働させることによって、システムに対し頑強性と安定度をもたらした。１つのＯＳがクラッシュしても、他のＯＳは中断なしに作業を継続することができたからである。確かに、ハイパーバイザを利用することにより、安定した主実働システムを危険にさらすことなく、しかも開発者が作業すべき高価な第２及び第３のシステムを必要とすることなく、ＯＳのベータ・バージョン又は実験的なバージョンを配備しデバッグすることが可能になった。
【０００９】
ハイパーバイザは、各ＯＳに１セットの仮想資源を提供することにより、ホスト・コンピュータ上で多数のＯＳが同時に稼働することを可能にする。これらの仮想資源は、各ＯＳにコンピュータの実際の資源の一部を提供する。一般に、かかる資源の部分は、当該資源が使用可能な合計時間のタイム・スライスとして実装される。ハイパーバイザを使用すると、単一コンピュータ内の資源が分配され、その結果、当該コンピュータは、あたかも２つ以上の独立したコンピュータであるかのように見える。しかし、ホスト・コンピュータ上で多数のＯＳが同時に稼働することを可能にするためにハイパーバイザを利用することには、欠点がある。すなわち、ハイパーバイザを動作させるのに必要な管理オーバーヘッドは、ＯＳ及びアプリケーションを稼働させるのに利用可能な総合的な資源を減少させてしまう。かかる管理オーバーヘッドは、ハイパーバイザと各ＯＳの間のプロセッサ・コンテキスト・スイッチの形で生じる。従って、当分野では、ＯＳの或る機能をハイパーバイザ内で実装することにより、ハイパーバイザの管理オーバーヘッドを減少させることが要請されている。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従って、本発明の目的は、コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための方法、装置及びプログラムを提供することである。
【課題を解決するための手段】
【００１１】
前記コンピュータ・システムは、少なくとも１つの計算ノードを含む。前記計算ノードは、一のＯＳ及び一のハイパーバイザを含む。前記ＯＳは、一のカーネルを含む。前記ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含む。コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供することは、前記計算ノード上で、前記カーネル・プロキシによって使用すべき前記複数のＯＳサービスのうち１つを指定するカーネル・ポリシを設定することと、前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスすることを含む。
【００１２】
また、前記コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムとして実装することができる。１つ以上のＯＳサービスは、これらのＯＳサービス・ノードの間に分散することができる。また、前記カーネル・ポリシは、前記指定されたＯＳサービスを提供すべき１つのＯＳサービス・ノードを指定することができ、その場合、前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスすることは、前記計算ノード上の前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスすることを含むことができる。
【００１３】
本発明の前記及び他の目的、特徴及び利点は、添付の図面に示されている本発明の実施形態に関する以下の説明から明らかとなるであろう。なお、図面中の同じ参照番号は、本発明の実施形態の同じ部分を指すものとする。
【発明を実施するための最良の形態】
【００１４】
以下、添付の図面を参照して、コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための、本発明の実施形態に従った方法、装置及びプログラムを説明する。図１は、ハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための、本発明の実施形態に従ったコンピュータ・システム１００を示すネットワーク図である。コンピュータ・システム１００は、計算ノード１１０を含む。計算ノード１１０は、ＯＳ１０８及びハイパーバイザ１１１を含む。ＯＳ１０８は、カーネル１０９を含む。ハイパーバイザ１１１は、カーネル・プロキシ１２０及び一のサービス・タイプの複数のＯＳサービス１２４を含む。一般に、コンピュータ・システム１００は、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するために、計算ノード１１０上で、ハイパーバイザ１１１内のカーネル・プロキシ１２０が使用すべき前記サービス・タイプの前記複数のＯＳサービス１２４のうち１つを指定するカーネル・ポリシ１２２を設定し、カーネル・プロキシ１２０によって、前記指定されたＯＳサービスにアクセスするように動作する。
【００１５】
コンピュータ・システム１００は、分散コンピュータ・システムとして実装される。分散コンピュータ・システムは、共通のタスクを遂行するために、ネットワークに接続された２つ以上の計算装置を使用するコンピュータ・システムである。分散コンピュータ・システム１００は、ネットワーク１０１を通して互いにデータ通信を行うように接続された、計算ノード１１０と、ＯＳサービス・ノード１１２、１１４、１１６と、管理ノード１１８とを含む。計算ノード１１０は、接続線１４０を通して、ネットワーク１０１に接続する。ＯＳサービス・ノード１１２、１１４、１１６は、接続線１４２、１４４、１４６を通して、ネットワーク１０１にそれぞれ接続する。管理ノード１１８は、接続線１４８を通して、ネットワーク１０１に接続する。分散コンピュータ・システム１００内の共通のタスクは、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供することを含む。
【００１６】
計算ノード１１０は、ラック１０４内に取り付けられたノード１０２のうち１つを使用して実装される。各ノード１０２は、プログラム命令を実行する処理装置である。各ノード１０２は、１つ以上のプロセッサ及び当該プロセッサに結合されたメモリを含む。ノード１０２は、サーバ・シャシに取り付けられたブレード・サーバとして実装され、これらのサーバ・シャシは、ラック１０４に取り付けられる。しかし、ノード１０２をブレード・サーバとして実装するのは、説明上のものであって、本発明を限定するものではない。実際、ノード１０２は、ネットワークに接続されたワークステーションとして、またコンピュータ・クラスタを形成するように互いに接続されたコンピュータなどとして、実装することができる。
【００１７】
計算ノード１１０は、カーネル・プロキシ１２０及びカーネル・ポリシ１２２を含む、ハイパーバイザ１１１を有するように構成されたノードである。ハイパーバイザ１１１は、ハードウェア上でＯＳ層の下で稼働するシステム・ソフトウェアの層であって、ホスト・コンピュータ上で多数のＯＳが未変更のまま同時に稼働することを可能にする。ハイパーバイザ１１１は、各ＯＳに１セットの仮想資源を提供するために、論理区画（以下「ＬＰＡＲ」と略記）を使用して各ＯＳにかかる資源を割り振る。ＬＰＡＲは、１セットのデータ構造及びサービスであって、単一コンピュータ内の資源の分配を可能にすることにより、あたかも当該コンピュータが２つ以上の独立したコンピュータであるかのように機能させる。
【００１８】
多数のＯＳが同時に稼働することを可能にするために、ハイパーバイザ１１１は、仮想プロセッサ１１５をＯＳ１０８、ゲストＯＳ１１７に割り当てるとともに、計算ノード１１０の物理プロセッサ上で仮想プロセッサ１１５をスケジュールする。仮想プロセッサは、ＬＰＡＲに対するプロセッサ時間の割り当てを実装するためのサブシステムである。物理プロセッサの共有プールは、ＬＰＡＲに対する部分的な物理プロセッサの（タイム・スライスによる）割り当てをサポートする。このようにタイム・スライスで共有される部分的な物理プロセッサは、「仮想プロセッサ」と呼ばれる。スレッドが仮想プロセッサのタイム・スライス上で稼働している場合、スレッドは仮想プロセッサ上で稼働中であると称する。サブプロセッサの複数の区画は、ＬＰＡＲ内で稼働中のＯＳには見えない態様で、１セットの仮想プロセッサ間で物理プロセッサをタイム・シェアする。ＯＳ内のマルチプログラミングでは、スレッドは、割り込み禁止のモードで稼働することにより、物理プロセッサの制御を維持することができる。これに対し、サブプロセッサ区画では、スレッドは、その仮想プロセッサのタイム・スライスの終わりにハイパーバイザによって依然として優先使用され、その結果、物理プロセッサを異なる仮想プロセッサに利用可能にすることができる。
【００１９】
ハイパーバイザ１１１は、アプリケーション１０６及びＯＳ１０８の実行環境を提供する、ＬＰＡＲ１０３に仮想資源を割り振る。さらに、ハイパーバイザ１１１は、アプリケーション１０７及びゲストＯＳ１１７の実行環境を提供する、ＬＰＡＲ１０５に仮想資源を割り振る。各アプリケーション１０６、１０７は、ユーザ・レベルのデータ処理を実装する１セットのプログラム命令である。各アプリケーション１０６、１０７は、それぞれのプログラム命令が単一の計算ノード上で実行されるような独立型のアプリケーションでもよいし、あるいはそれぞれのプログラム命令の各部分が他の計算ノード上で実行中の他の部分と直列又は並列に実行されるような分散型のアプリケーションでもよい。
【００２０】
ゲストＯＳ１１７は、計算ノード１１０上のアプリケーション１０７の実行を制御する。ゲストＯＳ１１７は、ハイパーバイザ１１１によってＬＰＡＲ１０５に割り振られた仮想資源を管理するシステム・ソフトウェアである。ゲストＯＳ１１７が遂行する基本的作業は、仮想メモリの制御及び割り振り、命令の処理の優先順位付け、仮想化入出力装置の制御、ネットワーキングの支援、仮想化ファイル・システムの管理などを含む。
【００２１】
同様に、ＯＳ１０８は、計算ノード１１０の上のアプリケーション１０６の実行を制御する。アプリケーション１０６は、カーネル１０９を通して、ＯＳ１０８によって提供される資源にアクセスする。カーネル１０９は、ＯＳ１０８のコア・コンポーネントであって、システムの資源を管理するとともに、ハイパーバイザ１１１によって提供される仮想資源とアプリケーションとの間の通信を管理する。カーネル１０９は、アプリケーションに仮想ハードウェア資源の抽象化層を提供することにより、当該アプリケーションがかかる仮想ハードウェア資源を利用することを可能にする。カーネル１０９は、プロセス間通信機構及びカーネルのアプリケーション・プログラム・インタフェース（以下「ＡＰＩ」と略記）１１９を通して、これらの抽象化層をユーザ・レベルのアプリケーションに利用可能にする。
【００２２】
ハイパーバイザ１１１は、カーネル・プロキシ１２０及びＯＳサービス１２４を使用して、ＯＳ１０８の実装の多くを行うように構成される。カーネル・プロキシ１２０は、一般に、ＯＳのカーネル内に実装されるＯＳサービスを提供するシステム・ソフトウェアである。ＯＳ１０８がハイパーバイザ１１１内に構成されるサービスを必要とする場合、カーネル１０９は、カーネル・プロキシ１２０が当該サービスを遂行することを要求する。カーネル１０９は、プロセス間通信を使用するか、又はカーネル・プロキシＡＰＩ１２１を通して、カーネル・プロキシ１２０にアクセスする。ＯＳ１０８の実装をできるだけ多く行うようにハイパーバイザ１１１を構成すると、非常に軽量のＯＳを有利に提供することができる。
【００２３】
カーネル・プロキシ１２０とＯＳサービス１２４との間の関係は、マイクロカーネル・アーキテクチャに基づいて作られる。すなわち、カーネル・プロキシ１２０は、メモリ管理、プロセス管理及びプロセス間通信のようなＯＳサービスの基本タイプの実装を含む。しかし、他のＯＳサービス１２４（例えば、ネットワーキング、割り込み処理、Ｉ／Ｏスケジューリング、デバイス・ドライバ、ファイルシステム・サービスなど）は、別個のＯＳコンポーネントを使用して実装され、当該各コンポーネントは、カーネル・プロキシ１２０とは異なるスレッドを有する。カーネル・プロキシ１２０は、プロセス間通信又はサービスＡＰＩ１２５へのシステム・コールを使用して、これらのＯＳサービス１２４にアクセスする。
【００２４】
各ＯＳサービス１２４は、カーネル・プロキシ１２０それ自体の内部で実装されないサービス・タイプを実装するか、又はカーネル・プロキシ１２０によって既に提供されているサービス・タイプの特殊バージョンを実装するシステム・ソフトウェアである。この点を説明するため、カーネル・プロキシ１２０がファイルシステム・サービス・タイプのいかなるサービスをも実装していない、という第１の例を考察する。この第１の例では、ＯＳサービス１２４のうち１つは、ＵＮＩＸ（登録商標）ファイル・システム用のファイルシステム・サービスを実装し、第２のＯＳサービス１２４は、Ｒｅｉｓｅｒファイル・システム用のファイルシステム・サービスを実装することができる。カーネル・プロキシ１２０は、ハイパーバイザ１１１内に構成されるカーネル・ポリシ１２２に依存して、ＵＮＩＸ（登録商標）ファイル・システム又はＲｅｉｓｅｒファイル・システムを使用して、ファイルシステム・サービスを提供するであろう。さらに、カーネル・プロキシ１２０が一般的なメモリ管理サービスを実装している、という第２の例を考察する。この第２の例では、ＯＳサービス１２４のうち１つは、集中的な入出力動作に適合したメモリ管理サービスを実装することができ、その結果、カーネル・プロキシ１２０は、カーネル・ポリシ１２２の構成に依存して、カーネル・プロキシ１２０内に実装された一般的なメモリ管理アルゴリズムを使用する代わりに、集中的な入出力動作に適合したメモリ管理サービスを使用することができる。
【００２５】
各ＯＳサービス１２４は、特定サービス・タイプのＯＳサービスを提供する。ＯＳサービス１２４によって提供されるサービス・タイプは、例えば、タスク・スケジューラ、ファイル・システム、メモリ管理、デバイス・ドライバ、Ｉ／Ｏスケジューラ、割り込み／信号処理、セキュリティ、ジョブ・サブミッション、ｔｔｙ（teletypewriter）処理などを含む。同じサービス・タイプのＯＳサービス１２４は、同じＡＰＩを有する。すなわち、特定のサービス・タイプを有する各ＯＳサービス１２４用のサービスＡＰＩ１２５は、同じ１セットのメンバ・メソッド及びパラメータを有しており、カーネル・プロキシ１２０はこれを使用してＯＳサービス１２４にアクセスすることができる。各サービス・タイプのサービスが同じサービスＡＰＩを有しているという理由で、カーネル・プロキシ１２０は、特定のサービス・タイプについてカーネル・ポリシ１２２内でどのＯＳサービスが指定されるかに拘わらず、同じＡＰＩを使用して、カーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスすることができる。
【００２６】
図１のコンピュータ・システム１００では、１つ以上のＯＳサービス１２４は、ＯＳサービス・ノード１１２、１１４、１１６の間に分散される。すなわち、２つ以上のＯＳサービス１２４を実装するプログラム命令は、ＯＳサービス・ノード１１２、１１４、１１６上に存在する。ＯＳサービス１３２、１３４、１３６用の対応するＯＳサービス１２４は、各ＯＳサービス１３２、１３４、１３６を実装するプログラム命令のコピーとして実装することができる。また、ＯＳサービス１３２、１３４、１３６用の対応するＯＳサービス１２４は、ＯＳサービス・ノード１１２、１１４、１１６上のＯＳサービス１３２、１３４、１３６にアクセスするデータ通信サブシステムを使用して実装することができる。かかるデータ通信サブシステムは、例えば、ウェブ・サービス・エンジンとして実装することができるし、リモート・プロシージャ・コールを使用してＯＳサービス・ノード１１２、１１４、１１６上のＯＳサービス１３２、１３４、１３６にアクセスする、計算ノード１１０の上のＣＯＲＢＡオブジェクトとして、あるいはＭＰＩライブラリなどを使用して実装することができる。
【００２７】
「ＣＯＲＢＡ」は、「Common ObjectRequest Broker Architecture」の略称であり、ObjectManagement Group（ＯＭＧ）によって策定された相互運用可能な企業アプリケーション用の仕様を指す。ＣＯＲＢＡは、１９９１年にＯＭＧによって最初に公表されたリモート・プロシージャ・コールのための仕様である。ＣＯＲＢＡは、通常のリモート・プロシージャ・コールには存在しない機能をサポートするが、リモート・プロシージャ・コールを行うための一種のオブジェクト指向の方法と考えることができる。ＣＯＲＢＡは、オブジェクトのインタフェースを記述するために、宣言型言語であるインタフェース定義言語（ＩＤＬ）を使用する。ＩＤＬで書かれたインタフェース記述は、クライアント側の「スタブ」及びサーバ側の「スケルトン」を生成するようにコンパイルされる。この生成コードを使用すると、Ｃ＋＋又はＪａｖａ（登録商標）のようなオブジェクト指向プログラミング言語によって行われる遠隔メソッドの呼び出しは、ローカル・オブジェクト内のローカル・メンバメソッドの呼び出しのように見える。
【００２８】
「ＭＰＩ」は、「Message PassingInterface」の略称であり、既存の並列通信ライブラリ、すなわち並列コンピュータ上のデータ通信用のプログラム命令のモジュールを指す。本発明の実施形態に有用な既存の並列通信ライブラリの例には、ＭＰＩ及び「Parallel Virtual Machine」（ＰＶＭ）ライブラリがある。ＰＶＭは、テネシー大学、オークリッジ国立研究所及びエモリー大学によって開発された。ＭＰＩは、ＭＰＩフォーラム（ＭＰＩ仕様を定義及び維持する多くの組織からの代表者で構成されたオープン・グループ）によって公表される。ＭＰＩは、分散メモリ型の並列コンピュータ上で並列プログラムを稼働させているノード間の通信を行うための業界標準である。説明の便宜上、本明細書では、ＭＰＩの用語を使用することもあるが、このことは、本発明を限定するものではない。
【００２９】
各ＯＳサービス・ノード１１２、１１４、１１６は、ラック１０４に取り付けられたノード１０２を使用して実装される。各ＯＳサービス・ノード１１２、１１４、１１６は、計算ノード１１０上にインストールされたハイパーバイザ１１１に対し、ＯＳサービスを提供するノードである。各ＯＳサービス・ノード１１２、１１４、１１６は、１つ以上の計算ノード上で稼働中の１つ以上のハイパーバイザに対し、１つ以上のＯＳサービスを提供することができる。しかし、多くのノードを備えた分散コンピュータ・システムでは、各ＯＳサービス・ノード１１２、１１４、１１６は、当該システム内の豊富なノードに起因して、１つだけのＯＳサービスを提供するのが普通である。図１の例では、ＯＳサービス・ノード１１２はカーネル・プロキシ１２０にＯＳサービス１３２を提供し、ＯＳサービス・ノード１１４はカーネル・プロキシ１２０にＯＳサービス１３４を提供し、ＯＳサービス・ノード１１６はカーネル・プロキシ１２０にＯＳサービス１３６を提供する。
【００３０】
カーネル・プロキシ１２０にＯＳサービスを提供するために、各ＯＳサービス・ノード１１２、１１４、１１６は、それぞれの上にＯＳサービス・サーバをインストールしている。すなわち、ＯＳサービス・ノード１１２はＯＳサービス・サーバ１３３を含み、ＯＳサービス・ノード１１４はＯＳサービス・サーバ１３５を含み、ＯＳサービス・ノード１１６はＯＳサービス・サーバ１３７を含む。各ＯＳサービス・サーバ１３３、１３５、１３７は、ハイパーバイザ１１１によって送信された要求に応答して、又はシステム管理者からの命令を受け取ることに応答して、ハイパーバイザ１１１にＯＳサービスを提供するソフトウェア・コンポーネントである。各ＯＳサービス・サーバ１３３、１３５、１３７は、要求されたＯＳサービスを実装するプログラム命令をハイパーバイザ１１１に送信するとともに、ハイパーバイザ１１１をインストールした計算ノード１１０がこれらのプログラム命令を実行するのを許可することにより、ハイパーバイザ１１１に当該ＯＳサービスを提供することができる。また、各ＯＳサービス・サーバ１３３、１３５、１３７は、要求されたＯＳサービスを実装するプログラム命令を実行するように、ＯＳサービス・サーバをインストールしたＯＳサービス・ノードに命令することにより、当該ＯＳサービスを提供することができる。ハイパーバイザ１１１のカーネル・プロキシ１２０は、各ＯＳサービス・サーバ１３３、１３５、１３７と通信するために、ＣＯＲＢＡオブジェクトの呼び出し用メンバ・メソッドを使用するか、ＭＰＩライブラリなどを使用することができる。
【００３１】
前述のように、ハイパーバイザ１１１は、特定のサービス・タイプ用の２つ以上のＯＳサービス１２４を含む。例えば、ハイパーバイザ１１１は、コンピュータ・システム１００の構成に依存して、カーネル・プロキシ１２０が使用すべきファイルシステム・サービスの２つの異なる実装を含むことができる。他の例では、ハイパーバイザ１１１は、アプリケーション１０６の必要性に依存して、メモリ管理サービスの２つの異なる実装を含むことができる。特定のサービス・タイプについて複数のＯＳサービスを有すると、計算ノード１１０のハードウェア及びソフトウェア環境に従って、ＯＳのサービス・アルゴリズムを柔軟に最適化することができる。
【００３２】
カーネル・ポリシ１２２は、ＯＳサービス１２４のうち１つをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。一般に、カーネル・ポリシ１２２は、計算ノード１１０上の実行のために構成されたアプリケーション１０６によるノード資源の利用を最適化するように、計算ノード１１０上で設定される。カーネル・プロキシ１２０は、カーネル・ポリシ１２２を使用することにより、特定のサービス・タイプについてハイパーバイザ１１１内で使用すべきＯＳサービスを識別する。ＯＳサービス１２４が計算ノード１１０上にローカルに存在するか、又はＯＳサービス・ノード１１２、１１４、１１６のような他のノード上に分散されるかどうかに拘わらず、カーネル・ポリシ１２２は、ハイパーバイザ１１１内で使用すべき特定のサービス・タイプの１つのＯＳサービスを指定する。さらに、カーネル・ポリシ１２２内で指定されたＯＳサービスがＯＳサービス・ノード１１２、１１４、１１６のうち１つに分散される場合、カーネル・ポリシ１２２は、当該指定されたＯＳサービスを提供すべきＯＳサービス・ノードを指定する。カーネル・ポリシ１２２を使用すると、カーネル・プロキシ１２０は、カーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスすることにより、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供することができる。
【００３３】
しばしば、カーネル・ポリシ１２２は、ハイパーバイザ１１１内で使用される１つのサービス・タイプ用のＯＳサービスを指定しないか、又はカーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスできないこともある。従って、ハイパーバイザ１１１は、デフォルトＯＳサービス１２６を含む。このデフォルトＯＳサービス１２６は、カーネル・ポリシ１２２が特定のサービス・タイプ用のＯＳサービスを指定しないか、又はカーネル・ポリシ１２２内で指定されたＯＳサービスにアクセスすることができないようなときに、カーネル・プロキシ１２０が使用することができる特定のサービス・タイプのＯＳサービスである。この点を説明するため、カーネル・ポリシ１２２がハイパーバイザ１１１によって使用すべきファイルシステム・サービスを指定せず、カーネル・プロキシ１２０がファイルシステム・サービスそれ自体を実装せず、そしてデフォルトＯＳサービス１２６がＵＮＩＸ（登録商標）ファイル・システムを実装している、という例を考察する。この例では、カーネル・プロキシ１２０がファイルシステム・サービスを実装せず、ファイルシステム・サービスがカーネル・ポリシ１２２内で指定されないという理由で、カーネル・プロキシ１２０は、ＵＮＩＸ（登録商標）ファイル・システムを実装するデフォルトＯＳサービス１２６を使用するであろう。カーネル・プロキシ１２０は、プロセス間通信又はデフォルトＯＳサービスＡＰＩ１２７を使用して、デフォルトＯＳサービス１２６にアクセスすることができる。
【００３４】
分散コンピュータ・システム１００は、管理ノード１１８を通して、システム管理者１３０によって構成される。管理ノード１１８は、コンピュータ・システム１００の構成を処理する計算装置である。管理ノード１１８は、ラック１０４に取り付けられたノード１０２のうち１つとして、ノード１０２に接続されたワークステーション・ネットワークとして、又は当業者には周知の他のコンピュータとして実装することができる。
【００３５】
図１のコンピュータ・システム１００では、管理ノード１１８は、その上に管理モジュール１２８をインストールしている。管理モジュール１２８は、システム管理者１３０がそれを通してコンピュータ・システム１００を構成するソフトウェア・コンポーネントである。管理モジュール１２８は、システム管理者１３０がコンピュータ・システム１００を構成できるようにするため、システム管理者１３０が管理モジュール１２８と対話するためのユーザ・インタフェースを提供するとともに、システム管理者１３０によって１つ以上の計算ノード（例えば、計算ノード１１０）上に提供されたハイパーバイザ１１１、ＯＳ１０８、ゲストＯＳ１１７、アプリケーション１０６、１０７を構成する。管理モジュール１２８は、カーネル・プロキシ１２０が使用すべきサービス・タイプのＯＳサービス１２４のうち１つを指定するカーネル・ポリシ１２２を計算ノード１１０上に設定することにより、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するための１セットのプログラム命令を含む。
【００３６】
コンピュータ・システム１００を構成するサーバ及び他の装置の配置は、説明上のものであって、本発明を限定するものではない。当業者には明らかなように、本発明の種々の実施形態に従ったデータ処理システムは、図１には示されていない追加のサーバ、ルータ、他の装置及びピア・ツー・ピア・アーキテクチャを含むことができる。当業者には明らかなように、かかるデータ処理システム内のネットワークは、伝送制御プロトコル（ＴＣＰ）、インターネット・プロトコル（ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、無線アクセス・プロトコル（ＷＡＰ）、ハンドヘルド・デバイス伝送プロトコル（ＨＤＴＰ）、ＭＰＩプロトコルなどを含む、多くのデータ通信プロトコルをサポートすることができる。本発明の種々の実施形態は、図１に示されたものに加えて、種々のハードウェア・プラットフォーム上で実装することができる。例えば、コンピュータ・システム１００は、ＩＢＭ社の BlueGene/L のような並列コンピュータとしても実装することができる。
【００３７】
本発明に従ってコンピュータ・システム上のハイパーバイザ内にポリシ・ベースのＯＳサービスを提供することは、一般に、コンピュータを用いて、すなわち自動化計算機械を用いて実装される。例えば、図１のコンピュータ・システム１００では、全てのノードは、少なくともコンピュータとしてある程度まで実装される。従って、さらなる説明のために、図２に示されている計算ノード１１０から成る自動化計算機械は、本発明の実施形態に従って、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するのに有用である。図２の計算ノード１１０は、少なくとも１つのプロセッサ（ＣＰＵ）１５６及びランダム・アクセス・メモリ（ＲＡＭ）１６８を含み、このＲＡＭ１６８は、高速メモリ・バス１６６及びバス・アダプタ１５８を通して、プロセッサ１５６及び計算ノード１１０の他のコンポーネントに接続される。
【００３８】
ＲＡＭ１６８内には、ハイパーバイザ１１１、アプリケーション１０６、１０７、ＯＳ１０８、ゲストＯＳ１１７が格納される。ハイパーバイザ１１１は、アプリケーション１０６及びＯＳ１０８用の実行環境を提供する、ＬＰＡＲ１０３に仮想資源を割り振る。ＯＳ１０８はカーネル１０９を含む。さらに、ハイパーバイザ１１１は、アプリケーション１０７及びゲストＯＳ１１７用の実行環境を提供する、ＬＰＡＲ１０５に仮想資源を割り振る。各ＬＰＡＲ１０３、１０５は、１セットのデータ構造及びサービスであって、単一コンピュータ内の資源の分配を可能にすることにより、あたかも当該コンピュータが２つ以上の独立したコンピュータであるかのように機能させる。
【００３９】
図２のハイパーバイザ１１１は、仮想プロセッサ１１５、カーネル・プロキシ１２０、カーネル・ポリシ１２２、ＯＳサービス１２４及びデフォルトＯＳサービス１２６を含む。カーネル・ポリシ１２２は、ＯＳサービス１２４のうち１つをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。仮想プロセッサ１１５は、ＬＰＡＲへのプロセッサ時間の割り当てを実装するサブシステムである。アプリケーション１０６、１０７、ＯＳ１０８、ゲストＯＳ１１７、カーネル１０９、ハイパーバイザ１１１、カーネル・プロキシ１２０、ＯＳサービス１２４及びデフォルトＯＳサービス１２６は、ソフトウェア・コンポーネントである。すなわち、かかるソフトウェア・コンポーネントの各々は、図１を参照して既に説明したように、計算ノード１１０に関して動作するプログラム命令である。本発明に従って改良することができるＯＳには、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（商標）、ＭｉｃｒｏｓｏｆｔＮＴ（商標）、ＩＢＭ社のＡＩＸ（商標）、ＩＢＭ社のｉ５／ＯＳ（商標）などがある。図２では、ＯＳ１０８、ゲストＯＳ１１７、アプリケーション１０６、１０７、ＬＰＡＲ１０３、１０５、及びハイパーバイザ１１１が、それぞれＲＡＭ１６８内に格納されるように示されているが、かかるソフトウェア・コンポーネントの多くは、不揮発性メモリ（例えば、ディスク・ドライブ１７０）にも格納される。
【００４０】
バス・アダプタ１５８は、高速バスであるフロントサイド・バス１６２及びメモリ・バス１６６用のドライブ・エレクトロニクスに加えて、比較的低速の拡張バス１６０用のドライブ・エレクトロニクスを含む、ハードウェア・コンポーネントである。計算ノード１１０に有用なバス・アダプタ１５８の例には、インテル社のノース・ブリッジ、メモリ・コントローラ・ハブ、サウス・ブリッジ及びＩ／Ｏコントローラ・ハブがある。計算ノード１１０に有用な拡張バス１６０の例には、ＰＣＩバス及びＰＣＩＥｘｐｒｅｓバスがある。
【００４１】
図２には示されていないが、バス・アダプタ１５８は、ビデオ・アダプタと計算ノード１１０の他のコンポーネントの間のデータ通信をサポートするビデオ・バス用のドライブ・エレクトロニクスを含んでいてもよい。かかるビデオ・コンポーネントが図２に示されていない理由は、一般に、計算ノード１１０がブレード・サーバとして実装されていて、専用のビデオ・サポートを持たない並列コンピュータ内のサーバ・シャシ又はノードに取り付けられることにある。しかし、計算ノード１１０が、かかるビデオ・コンポーネントを含んでもよいことは明らかであろう。
【００４２】
ディスクドライブ・アダプタ１７２は、拡張バス１６０及びバス・アダプタ１５８を通して、プロセッサ１５６及び計算ノード１１０の他のコンポーネントに結合される。ディスクドライブ・アダプタ１７２は、ディスク・ドライブ１７０の形態を有する不揮発性のデータ記憶装置を計算ノード１１０に接続する。計算ノード１１０に有用なディスクドライブ・アダプタ１７２の例には、統合ドライブ・エレクトロニクス（ＩＤＥ）アダプタ、小型コンピュータ・システムインタフェース（ＳＣＳＩ）アダプタなどがある。さらに、計算ノード１１０用の不揮発性メモリとして、光ディスク・ドライブ、電気的消去再書き込みＲＯＭ（いわゆる「ＥＥＰＲＯＭ」あるいは「フラッシュ」メモリ）などを実装することができる。
【００４３】
１つ以上の入出力（Ｉ／Ｏ）アダプタ１７８は、ディスプレイ装置への出力を制御したり、キーボードやマウスのようなユーザ入力装置１８１からのユーザ入力を制御するために、例えばソフトウェア・ドライバ及びハードウェアを通して、ユーザ向きの入出力を実装する。図２には示されていないが、他の実施形態に従った計算ノードは、Ｉ／Ｏアダプタ１７８の１例として、ディスプレイ装置へグラフィック出力を供給するように特別に設計されたビデオ・アダプタを含むことができる。一般に、かかるビデオ・アダプタは、高速のビデオ・バス、バス・アダプタ１５８及びフロントサイド・バス１６２を通して、プロセッサ１５６に接続される。
【００４４】
通信アダプタ１６７は、他のコンピュータ１８２及びデータ通信ネットワーク１０１とのデータ通信を行うためのものである。かかるデータ通信は、ＲＳ−２３２接続を通して、ユニバーサル・シリアル・バス（ＵＳＢ）のような外部バスを通して、ＩＰデータ通信ネットワークのようなデータ通信ネットワークなどを通して、行うことができる。通信アダプタは、データ通信のハードウェア・レベルを実装し、これを通して、１つのコンピュータは、直接に又はデータ通信ネットワークを通して、データを他のコンピュータに送信する。計算ノード１１０に有用な通信アダプタ１６７の例には、有線式ダイアルアップ通信用のモデム、有線式データ通信ネットワーク通信用のＩＥＥＥ ８０２．３イーサネット（登録商標）・アダプタ及び無線式データ通信ネットワーク通信用のＩＥＥＥ ８０２．１１ｂアダプタがある。
【００４５】
以上、図２を参照して計算ノード１１０を説明したが、これと同様な自動化計算機械が、ハイパーバイザ１１１内にポリシ・ベースのＯＳサービスを提供するのに有用なＯＳサービス・ノード及び管理ノードから構成されることに留意すべきである。かかるＯＳサービス・ノード及び管理ノードは、図２の計算ノード１１０と同様に、１つ以上のプロセッサ、バス・アダプタ、バス、ＲＡＭ、通信アダプタ、Ｉ／Ｏアダプタ、ディスクドライブ・アダプタなどを含む。
【００４６】
次に、図３を参照して、ハイパーバイザ１１１によるＬＰＡＲへの仮想プロセッサの割り振りをさらに詳細に説明する。図３は、ハイパーバイザ１１１で構成された、本発明の実施形態に従った計算ノード３００を示す機能ブロック図である。
【００４７】
計算ノード３００は、ＬＰＡＲ３０２及びＬＰＡＲ３０４を含む。計算ノード３００内に含まれる２つのＯＳ３０及びＯＳ３０８は、ＬＰＡＲ３０２及びＬＰＡＲ３０４内にそれぞれ常駐する。計算ノード３００は、６つの論理プロセッサ（ＬＰ）３２０〜３２５を含み、そのうちの２つはＬＰＡＲ３０２内のＯＳ３０８用のものであり、他の４つはＬＰＡＲ３０４内のＯＳ３０８用のものである。論理プロセッサは、実行すべきスレッドをスケジュールするためのＯＳの構造である。論理プロセッサは、スレッドの実行を行うことができるプロセッサの資源の一部を表す。６つのスレッド（Ｔ）３１０〜３１５が、論理プロセッサ当たり１つのスレッドずつ、６つの論理プロセッサ３２０〜３２５上でそれぞれ稼働する。計算ノード３００は、ハイパーバイザ１１１及び４つの仮想プロセッサ（ＶＰ）３３０〜３３３を含み、そのうちの２つの仮想プロセッサ３３０及び３３１はＬＰＡＲ３０２に割り当てられ、他の２つの仮想プロセッサ３３２及び３３３はＬＰＡＲ３０４に割り当てられる。
【００４８】
さらに、計算ノード３００は、３つの物理プロセッサ３４０、３４２、３４４を含む。この例では、物理プロセッサ３４０、３４２、３４４は、処理単位に応じて共有される（但し、１.０の処理単位は、１つの物理プロセッサの処理能力を表す）。この例では、３つの物理プロセッサ３４０、３４２、３４４の処理能力は、以下のようにＬＰＡＲに配分される。
【００４９】
１．物理プロセッサ３４０の全ての処理能力が、仮想プロセッサ３３０に割り当てられる。その結果、論理プロセッサ３２０は、物理プロセッサ３４０の全ての処理能力を利用することができる。
【００５０】
２．物理プロセッサ３４２の処理能力の半分が、仮想プロセッサ３３１に割り当てられる。その結果、論理プロセッサ３２１は、（タイム・スライスにより）物理プロセッサ３４２の処理能力の半分を利用することができる。
【００５１】
３．物理プロセッサ３４２の処理能力の他の半分が、仮想プロセッサ３３２に割り当てられる。仮想プロセッサ３３２が割り当てられるＬＰＡＲ３０４では、仮想プロセッサ３３２に対応する２つの論理プロセッサ３２２及び３２３が、同時的なマルチスレッディング・モードで稼働中である。その結果、論理プロセッサ３２２及び３２３の各々は、（タイム・スライスにより）物理プロセッサ３４２の処理能力の４分の１をそれぞれ利用することができる。
【００５２】
４．物理プロセッサ３４４の全ての処理能力が、仮想プロセッサ３３３に割り当てられる。仮想プロセッサ３３３が割り当てられるＬＰＡＲ３０４では、仮想プロセッサ３３３に対応する２つの論理プロセッサ３２４及び３２５が、同時的なマルチスレッディング・モードで稼働中である。その結果、論理プロセッサ３２４及び３２５の各々は、（タイム・スライスにより）物理プロセッサ３４４の処理能力の半分をそれぞれ利用することができる。
【００５３】
計算ノード３００内の物理プロセッサ、仮想プロセッサ及び論理プロセッサの数、配置及び割り当ては、説明上のものであって、本発明を限定するものではない。本発明の実施形態に従った計算ノードは、多数のＬＰＡＲをサポートすることができ、物理プロセッサ、仮想プロセッサ及び論理プロセッサの任意の数、配置又は割り当てを含むことができる。
【００５４】
図４は、本発明の実施形態に従った方法のフローチャートを示す。図４の例では、コンピュータ・システムは、少なくとも１つの計算ノードを含む。計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び一のサービス・タイプの複数のＯＳサービスを含む。
【００５５】
図４の方法は、計算ノード上で、カーネル・プロキシ１２０が使用すべきサービス・タイプのＯＳサービスのうち１つを指定するカーネル・ポリシ１２２を設定するステップ４００を含む。カーネル・ポリシ１２２は、ＯＳサービスのうち１つをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。図４の例では、カーネル・ポリシ１２２の各レコードは、特定のサービス・タイプについてカーネル・プロキシ１２０がどのＯＳサービスを使用すべきかを識別する。かかる識別を行うため、カーネル・ポリシ１２２の各レコードは、ＯＳサービス識別子４０２及びサービス・タイプ４０４を含む。カーネル・ポリシ１２２内で指定されるＯＳサービス・タイプ４０４の例には、タスク・スケジューラ、ファイル・システム、メモリ管理、デバイス・ドライバ、Ｉ／Ｏスケジューラ、割り込み／信号処理、セキュリティ、ジョブ・サブミッション、ｔｔｙ（teletypewriter）処理などがある。本発明の実施形態に従ったカーネル・ポリシ１２２の例については、以下の表を参照されたい。
【００５６】
【表１】
【００５７】
表１のカーネル・ポリシ１２２では、ＯＳサービス識別子４０２の値「UFS_Service」をサービス・タイプ４０４の値「File_System」に関連づけることは、カーネル・プロキシ１２０がファイルシステム・サービス・タイプにアクセスする必要があるとき、カーネル・プロキシ１２０がＵＮＩＸ（登録商標）ファイル・システムを実装するＯＳサービスを使用することを指定する。ＯＳサービス識別子４０２の値「Round_Robin_MM_Algorithm」をサービス・タイプ４０４の値「Memory_Management」に関連づけることは、カーネル・プロキシ１２０がメモリ管理サービス・タイプにアクセスする必要があるとき、カーネル・プロキシ１２０がラウンドロビン・アルゴリズムを実装するＯＳサービスを使用することを指定する。ＯＳサービス識別子４０２の値「Limited_Ｉ／Ｏ_Access」をサービス・タイプ４０４の値「I/O_Scheduler」に関連づけることは、カーネル・プロキシ１２０がＩ／Ｏスケジューラ・サービス・タイプを使用するとき、カーネル・プロキシ１２０が制限されたＩ／Ｏアクセスを実装するＯＳサービスを使用することを指定する。表１のカーネル・ポリシ１２２は、説明用のものであって、本発明を限定するものではない。本発明の実施形態では、当業者には周知の他のカーネル・プロキシも使用することができる。
【００５８】
図４の設定ステップ４００は、管理モジュール１２８において、システム管理者１３０からＯＳサービスとサービス・タイプとの間のマッピングを受け取り、管理モジュール１２８によって、当該マッピングに従ったカーネル・ポリシ１２２を計算ノード上で作成することにより、実施することができる。管理モジュール１２８は、計算ノードを含むコンピュータ・システムを構成するためにシステム管理者１３０が使用することができる、ソフトウェア・コンポーネントである。カーネル・ポリシ１２２を作成するための管理モジュール１２８をインストールしている特定の計算ノードは、一般に、当該管理モジュール１２８によって提供されるユーザ・インタフェースを通して、システム管理者１３０によって指定される。管理モジュール１２８は、この計算ノード上に直接インストールするか、又はこの計算ノードに接続された他のコンピュータ・ネットワークにインストールすることができる。管理モジュール１２８は、共有メモリ空間、ＣＯＲＢＡフレームワーク、ＪＴＡＧネットワーク、ウェブ・サービス、ＭＰＩライブラリなどを使用して実装されたデータ通信接続を通して、計算ノード上にカーネル・ポリシ１２２を作成することができる。
【００５９】
「ＪＴＡＧ」は、バウンダリ・スキャンを使用してプリント配線回路ボードをテストするために使用される、「Standard Test Access Port and Boundary-Scan Architecture 」と題する、ＩＥＥＥ １１４９．１標準の俗称である。ＪＴＡＧは、非常に広汎に使用されているので、バウンダリ・スキャンと殆ど同義である。ＪＴＡＧは、プリント配線回路ボードだけでなく、集積回路のバウンダリ・スキャンを行うためにも使用され、さらに、組み込みシステムをデバッグするための機構として、当該システムへの便利な「バック・ドア」を提供するのに有用である。ＪＴＡＧネットワークを使用すると、管理モジュール１２８は、本発明の実施形態に従った、計算ノード内のプロセッサ・レジスタ及びメモリを効率的に構成することができる。
【００６０】
図４の指定ステップ４０１は、カーネル・プロキシ１２０によって、カーネル・プロキシ１２０が使用すべきサービス・タイプ４０５を指定する。カーネル・プロキシ１２０は、実行フローに沿った特定の点でカーネル・プロキシ１２０を実装するプログラム命令内にサービス・タイプ４０５を保持する命令を含めることにより、ハイパーバイザ内の使用すべきサービス・タイプ４０５を指定することができる。例えば、カーネル・プロキシ１２０用の実行フローに沿った特定の点で、カーネル・プロキシ１２０を実装するプログラム命令は、次の命令を表す機械コードを含むことができる。
【００６１】
Execute_Service（File_System）;
【００６２】
この命令内の機能「Execute_Service」は、カーネル・プロキシ１２０に対し、「File_System」の値を有するサービス・タイプ４０５についてカーネル・ポリシ１２２内で指定されたＯＳサービスを実行するように命令する機能である。この命令をカーネル・プロキシ１２０を実装するプログラム命令内に含めると、ハイパーバイザ１１１がファイルシステム・サービス・タイプのサービスを使用することを指定する。この命令は、説明用のものであって、本発明を限定するものではない。本発明の実施形態では、当業者には周知の他の命令も使用することができる。
【００６３】
図４の検索ステップ４０３は、カーネル・プロキシ１２０によって、指定されたサービス・タイプ４０５に依存して、カーネル・ポリシ１２２から指定されたＯＳサービス４０７を検索することを含む。検索ステップ４０３は、カーネル・ポリシ１２２内で、指定されたサービス・タイプ４０５と同じ値を有するサービス・タイプ４０４に関連するＯＳサービス識別子４０２を検索することにより、実施することができる。
【００６４】
図４の判定ステップ４０６は、カーネル・プロキシ１２０によって、カーネル・プロキシ１２０が指定されたＯＳサービス４０７にアクセスすることができるか否かを判定する。判定ステップ４０６は、指定されたＯＳサービス４０７用のＡＰＩの関数を呼び出すことにより、実施することができる。もし、この関数呼び出しがカーネル・プロキシ１２０に対しエラーを返すのであれば、カーネル・プロキシ１２０は、指定されたＯＳサービスにアクセスすることができない。一方、この関数呼び出しがカーネル・プロキシ１２０に対しエラーを返さなければ、カーネル・プロキシ１２０は、指定されたＯＳサービスにアクセスすることができる。前述のように、同じサービス・タイプ用のＯＳサービスは、同じＡＰＩを有することができる。各サービス・タイプ用のＡＰＩは、カーネル・プロキシ１２０を実装するプログラム命令内にコード化することができる。
【００６５】
図４の実行ステップ４０８は、カーネル・プロキシ１２０が指定されたＯＳサービス４０７にアクセスすることができない場合、計算ノードによって、サービス・タイプ４０４のデフォルトＯＳサービスを実装するプログラム命令を実行することを含む。実行ステップ４０８は、デフォルト・サービス・テーブル４１２内で、サービス・タイプ４０４に関連するデフォルトＯＳサービス識別子４１４を検索するとともに、このデフォルトＯＳサービス識別子４１４によって表わされるデフォルトＯＳサービス用のＡＰＩの関数を呼び出すことにより、実施することができる。デフォルト・サービス・テーブル４１２は、カーネル・ポリシ１２２に類似している。デフォルト・サービス・テーブル４１２の各レコードは、特定のサービス・タイプについてハイパーバイザ内のどのデフォルトＯＳサービスを使用すべきかを識別する。デフォルト・サービス・テーブル４１２の各レコードは、デフォルトＯＳサービス識別子４１４及びサービス・タイプ４０４を含む。デフォルトＯＳサービスは、図４のデフォルト・サービス・テーブル４１２内で指定されるが、かかる実施形態は、説明用のものであって、本発明を限定するものではない。他の実施形態では、カーネル・ポリシ１２２内のフィールドを使用して、特定のサービス・タイプについてＯＳ内の使用すべきデフォルトＯＳサービスを指定することができるし、あるいは、各サービス・タイプ用のデフォルト・サービスをカーネル・プロキシ１２０それ自体にコード化することができる。
【００６６】
図４のアクセス・ステップ４１０は、カーネル・プロキシ１２０によって、指定されたＯＳサービス４０７にアクセスすることを含む。アクセス・ステップ４１０は、指定されたＯＳサービス４０７用のＡＰＩの関数を呼び出すことにより、実施することができる。しかし、かかる実施形態は、説明用のものであって、本発明を限定するものではない。他の実施形態では、管理モジュール１２８は、カーネル・ポリシ１２２に従って、カーネル・プロキシ１２０のコード内にある入口及び出口フックを修正することにより、実行フロー中のカーネル・プロキシ１２０のコード内の適切な点で、プロセッサの制御がカーネル・プロキシ１２０からＯＳサービスまで移動されるようにすることができる。そのような例では、アクセス・ステップ４１０は、単にカーネル・プロキシ１２０を実装するプログラム命令を実行することにより、実施することができる。
【００６７】
前述のように、ＯＳサービスは、分散コンピュータ・システム内の１つ以上のＯＳサービス・ノード間に分散することができる。このような場合、アクセス・ステップ４１０は、ＯＳサービス・ノードから指定されたＯＳサービスを実装するプログラム命令を検索するとともに、計算ノードによって、指定されたＯＳサービスを実装するプログラム命令を実行することにより、実施することができる（図６の説明を参照）。また、アクセス・ステップ４１０は、カーネル・プロキシ１２０によって、ＯＳサービス・ノードが指定されたＯＳサービスを実行するように要求するとともに、当該ＯＳサービス・ノードによって、指定されたＯＳサービスを実装するプログラム命令を実行することにより、実施することができる（図７の説明を参照）。
【００６８】
前述のように、カーネル・ポリシ１２２は、特定のＯＳサービスをカーネル・プロキシ１２０によって使用されるＯＳサービスのタイプにマップするテーブルである。しかし、カーネル・ポリシ１２２は、ＯＳサービスをカーネル・プロキシ１２０によって使用されるサービスの各タイプにマップできないことがある。そのため、カーネル・プロキシ１２０は、しばしばカーネル・ポリシ１２２が特定のサービス・タイプ用のＯＳサービスを指定するか否かを識別し、カーネル・ポリシ１２２が指定されたサービス・タイプのＯＳサービスを指定しないときには、指定されたサービス・タイプのデフォルトＯＳサービスを実装するプログラム命令を実行する。従って、さらなる説明のために、図５は、本発明の実施形態に従った他の方法のフローチャートを示す。図５の方法は、カーネル・プロキシ１２０によって、カーネル・ポリシ１２２が指定されたサービス・タイプ４０５のＯＳサービスを指定するか否かを識別するステップ５００を含む。図５の例では、コンピュータ・システムは、少なくとも１つの計算ノードを含む。この計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び１つのサービス・タイプの複数のＯＳサービスを含む。
【００６９】
図５の方法は、図４の方法における設定ステップ４００、指定ステップ４０１、検索ステップ４０３及びアクセス・ステップ４１０を含むという点で、図４の方法に類似している。さらに、図５の例は、図４の例におけるデフォルト・サービス・テーブル４１２を含み、当該テーブル４１２の各レコードがデフォルトＯＳサービス識別子４１４及びサービス・タイプ４０４を含むという点で、図４の例に類似している。
【００７０】
図５の識別ステップ５００は、指定されたサービス・タイプ４０５の値に一致するサービス・タイプ４０４の値を有するレコードを求めて、カーネル・ポリシ１２２を探索することにより、実施することができる。もし、かかるレコードが見つからなければ、カーネル・ポリシ１２２は、指定されたサービス・タイプ４０５のＯＳサービスを指定しない。一方、かかるレコードが見つかれば、カーネル・ポリシ１２２は、指定されたサービス・タイプ４０５のＯＳサービスを指定する。しかし、かかる実施の形態は、説明上のものであって、本発明を限定するものではない。他の実施形態では、カーネル・ポリシ１２２は、ＯＳ内で使用すべき各サービス・タイプのレコードを保持することができる。かかる実施形態では、識別ステップ５００は、カーネル・ポリシ１２２内の特定のレコード用のＯＳサービス識別子４０２が、ＮＵＬＬ値を保持しているか否かを識別することにより、実施することができる。
【００７１】
さらに、図５の実行ステップ５０２は、カーネル・ポリシ１２２が指定されたサービス・タイプ４０５のＯＳサービスを指定しないときに、計算ノードによって、指定されたサービス・タイプ４０５のデフォルトＯＳサービスを実装するプログラム命令を実行することを含む。この実行ステップ５０２は、デフォルト・サービス・テーブル４１２において、サービス・タイプ４０４に関連するデフォルトＯＳサービス識別子４１４を検索するとともに、このデフォルトＯＳサービス識別子４１４によって表わされるデフォルトＯＳサービス用のＡＰＩの関数を呼び出すことにより、実施することができる。デフォルトＯＳサービスは、図５のデフォルト・サービス・テーブル４１２内で指定されるが、かかる実施形態は、説明上のものであって、本発明を限定するものではない。他の実施形態では、カーネル・ポリシ１２２内のフィールドを使用して、特定のサービス・タイプについてＯＳ内の使用すべきデフォルトＯＳサービスを指定することができるし、あるいは、各サービス・タイプ用のデフォルト・サービスをカーネル・プロキシ１２０それ自体にコード化することができる。
【００７２】
前述のように、ＯＳサービスは、分散コンピュータ・システム内の１つ以上のＯＳサービス・ノード間に分散することができる。このような場合、アクセス・ステップ４１０は、ＯＳサービス・ノードの指定されたＯＳサービスにアクセスすることにより、実施することができる。従って、さらなる説明のために、図６は、本発明の実施形態に従ったさらに他の方法のフローチャートを示す。図６の方法は、ＯＳサービス・ノードの指定されたＯＳサービス４０７にアクセスするステップ６０２を含む。図６の例では、コンピュータ・システムは、少なくとも１つの計算ノード及び１つ以上のＯＳサービス・ノードを含む、計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び１つのサービス・タイプの複数のＯＳサービスを含む。図６の例では、ＯＳサービスの１つ以上がＯＳサービス・ノード間に分散される。
【００７３】
図６の方法は、図４の方法における設定ステップ４００、指定ステップ４０１、検索ステップ４０３及びアクセス・ステップ４１０を含むという点で、図４の方法に類似している。さらに、図６の例は、カーネル・ポリシ１２２の各レコードがＯＳサービス識別子４０２及びサービス・タイプ４０４を含むという点で、図４の例に類似している。しかし、図６の例では、カーネル・ポリシ１２２は、各レコード内にＯＳサービス・ノード識別子６００を含めることによって、指定されたＯＳサービス４０７を提供すべきＯＳサービス・ノードを指定する。図６の例では、指定されたＯＳサービス４０７は、ＯＳサービス・ノードのうち１つに分散される。
【００７４】
図６のアクセス・ステップ４１０は、ＯＳサービス・ノードの指定されたＯＳサービス４０７にアクセスするステップ６０２を含む。このアクセス・ステップ６０２は、カーネル・プロキシ１２０によって、指定されたＯＳサービス４０７を実装するプログラム命令６０６をＯＳサービス・ノードから検索するステップ６０４により、実施することができる。かかるプログラム命令６０６は、指定されたＯＳサービス４０７を実装する機械コードを表す。かかる表現は、説明上のものであって、本発明を限定するものではない。事実、図６のプログラム命令６０６は、アセンブリ言語又はＪａｖａ（登録商標）のような高水準言語で実装されたプログラム命令を表すことができる。
【００７５】
図６の検索ステップ６０４は、指定されたＯＳサービス４０７が分散されているＯＳサービス・サーバ上のＯＳサービス・サーバに対しＯＳサービス要求を送信し、このＯＳサービス・サーバから、指定されたＯＳサービスを実装するプログラム命令６０６を受信することにより、実施することができる。このＯＳサービス要求は、ＯＳサービス・ノードに対し、ＯＳサービスをハイパーバイザ内のカーネル・プロキシ１２０に提供するように要求するものである。このＯＳサービス要求は、指定されたＯＳサービス４０７用のＯＳサービス識別子４０２を含むことができる。カーネル・プロキシ１２０は、このＯＳサービス要求をＯＳサービス・ノード上のＯＳサービス・サーバに送信した後、ウェブ・サービスを使用するか、ＣＯＲＢＡオブジェクトのメンバ・メソッドを呼び出すか、ＭＰＩライブラリなどを使用して、プログラム命令６０６を検索することができる。
【００７６】
また、図６のアクセス・ステップ６０２は、計算ノードによって、指定されたＯＳサービス６０７を実装するプログラム命令６０６を実行するステップ６０８により、実施することができる。この実行ステップ６０８は、指定されたＯＳサービス６０７を実装するプログラム命令６０６を計算ノード上で実行するようにスケジュールすることにより、実施することができる。前述のように、図６のプログラム命令６０６は、アセンブリ言語又はＪａｖａ（登録商標）のような高水準言語で実装されたプログラム命令を表すことができる。かかる実施形態では、この実行ステップ６０８は、プログラム命令６０６を機械コードへ解釈し、かかる機械コードを計算ノード上で実行するようにスケジュールすることにより、実施することができる。
【００７７】
図６のアクセス・ステップ６０２は、指定されたＯＳサービスを実装するプログラム命令を計算ノード上で実行することにより実施される。しかし、かかるアクセス・ステップ６０２は、指定されたＯＳサービスを実装するプログラム命令をＯＳサービス・ノード上で実行することによっても、実施することができる。従って、さらなる説明のために、図７は、本発明の実施形態に従ったさらに他の方法のフローチャートを示す。図７の方法は、ＯＳサービス・ノードによって、指定されたＯＳサービス４０７を実装するプログラム命令７０６を実行するステップ７０８を含む。図７の例では、コンピュータ・システムは、少なくとも１つの計算ノード及び１つ以上のＯＳサービス・ノードを含む。計算ノードは、ＯＳ及びハイパーバイザを含む。ＯＳは、カーネルを含む。ハイパーバイザは、カーネル・プロキシ１２０及び１つのサービス・タイプの複数のＯＳサービスを含む。図７の例では、ＯＳサービスの１つ以上は、ＯＳサービス・ノード間に分散される。
【００７８】
図７の方法は、図４の方法における設定ステップ４００、指定ステップ４０１、検索ステップ４０３及びアクセス・ステップ４１０を含むという点で、図４の方法に類似している。さらに、図７の例は、カーネル・ポリシ１２２の各レコードがＯＳサービス識別子４０２及びサービス・タイプ４０４を含むという点で、図４の例に類似している。しかし、図７の例では、カーネル・ポリシ１２２は、各レコード内にＯＳサービス・ノード識別子６００を含めることにより、指定されたＯＳサービス４０７を提供すべきＯＳサービス・ノードを指定する。図７の例では、指定されたＯＳサービス４０７は、ＯＳサービス・ノードのうち１つの上に分散される。
【００７９】
図７のアクセス・ステップ４１０は、ＯＳサービス・ノードの指定されたＯＳサービス４０７にアクセスするステップ６０２を含む。このアクセス・ステップ６０２は、カーネル・プロキシ１２０によって、ＯＳサービス・ノードが指定されたＯＳサービスを遂行すべきことを要求するステップ７００を行うとともに、このＯＳサービス・ノードによって、サービス遂行要求７０２を受信するステップ７０４を行うことにより、実施される。要求ステップ７００は、指定されたＯＳサービス４０７が分散されたＯＳサービス・ノード上のＯＳサービス・サーバにサービス遂行要求７０２を送信することにより、実施することができる。サービス遂行要求７０２は、ＯＳサービス・ノードに対し、カーネル・プロキシ１２０用のＯＳサービスを遂行するように要求する。サービス遂行要求７０２は、指定されたＯＳサービス４０７用のＯＳサービス識別子４０２を含むことができる。カーネル・プロキシ１２０は、ウェブ・サービスを使用するか、ＣＯＲＢＡオブジェクトのメンバ・メソッドを呼び出すか、ＭＰＩライブラリなどを使用して、ＯＳサービス・ノード上のＯＳサービス・サーバにサービス遂行要求７０２を送信することができる。
【００８０】
図７のアクセス・ステップ６０２は、ＯＳサービス・ノードによって、指定されたＯＳサービス４０７を実装するプログラム命令７０６を実行するステップ７０８により、実施される。プログラム命令７０６は、指定されたＯＳサービス４０７を実装する機械コードを表す。実行ステップ７０８は、指定されたＯＳサービス４０７を実装するプログラム命令７０６をＯＳサービス・ノード上で実行するようにスケジュールすることにより、実施することができる。プログラム命令７０６を実行した後、ＯＳサービス・ノード上のＯＳサービス・サーバは、実行が成功したか否かを示すメッセージをカーネル・プロキシ１２０へ送信することができる。
【００８１】
本明細書の前述の説明に照らして、本発明の実施形態によれば、次の利点が得られることは明らかであろう。
【００８２】
１．ノードのハードウェア及びソフトウェア環境に基づいたＯＳサービスを提供することにより、軽量のＯＳを含む多数のＯＳをサポートするハイパーバイザで当該ノードを構成する能力。
【００８３】
２．軽量のＯＳをサポートする種々のＯＳサービスを提供することにより、ハイパーバイザによって、当該軽量のＯＳを新しい環境に適応させるか、又は新しい要件を満足させる能力。
【００８４】
３．ＯＳの機能のうち或るものをハイパーバイザ内で実装することにより、当該ハイパーバイザの管理オーバーヘッドを減少させる能力。
【００８５】
本発明の代表的な実施形態は、主として、ハイパーバイザ内にポリシ・ベースのＯＳサービスを提供するための完全に機能的なコンピュータ・システムの環境で説明された。しかし、任意の適当なデータ処理システムとともに使用するための信号担持媒体に配置されたコンピュータ・プログラムにおいても、本発明を具体化することができることは明らかであろう。かかる信号担持媒体は、伝送媒体とすることができるし、あるいは磁気媒体、光学媒体、他の適切な媒体などを含む機械可読情報用の記録可能媒体とすることができる。記録可能媒体の例には、ハード・ドライブ又はディスケット内の磁気ディスク、光ドライブ用のコンパクト・ディスク、磁気テープなどがある。伝送媒体の例には、音声通信用の電話網、イーサネット（登録商標）のようなディジタル・データ通信ネットワーク、インターネット・プロトコルを用いたネットワーク、ワールド・ワイド・ウェブ、ＩＥＥＥ ８０２．１１ファミリの規格に従って実装されたネットワークのような無線送信媒体などがある。また、本明細書で説明した代表的な実施形態のうち或るものは、ハードウェア上にインストールされ、そこで実行されるソフトウェアに基づいているが、ファームウェア又はハードウェアとして実装された他の実施形態も本発明の範囲内にあることはもちろんである。
【００８６】
前述の説明から明らかなように、本発明の要旨を逸脱することなく、本発明の種々の実施形態に対し修正及び変更を施すことができる。本明細書中の記述は、説明上のものであって、本発明を限定するものと解釈してはならない。本発明の範囲は、請求項の記載によってのみ定義される。
【図面の簡単な説明】
【００８７】
【図１】本発明の実施形態に従ったコンピュータ・システムを示すネットワーク図である。
【図２】本発明の実施形態に従った計算ノードから成る自動化計算機械を示すブロック図である。
【図３】ハイパーバイザで構成された、本発明の実施形態に従った計算ノードを示す機能ブロック図である。
【図４】本発明の実施形態に従った方法を示すフローチャートである。
【図５】本発明の実施形態に従った他の方法を示すフローチャートである。
【図６】本発明の実施形態に従ったさらに他の方法を示すフローチャートである。
【図７】本発明の実施形態に従ったさらに他の方法を示すフローチャートである。
【符号の説明】
【００８８】
１００ 分散コンピュータ・システム
１０３、１０５ ＬＰＡＲ
１０６、１０７ アプリケーション
１０８ ＯＳ
１０９ カーネル
１１０ 計算ノード
１１１ ハイパーバイザ
１１２、１１４、１１６ ＯＳサービス・ノード
１１７ ゲストＯＳ
１１８ 管理ノード
１１５ 仮想プロセッサ
１２２ カーネル・ポリシ
１２４ ＯＳサービス
１２６ デフォルトＯＳサービス
１２８ 管理モジュール
１３０ システム管理者
１３２、１３４、１３６ ＯＳサービス
１３３、１３５、１３７ ＯＳサービス・サーバ
【特許請求の範囲】
【請求項１】
コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのオペレーティング・システム・サービスを提供する方法であって、
前記コンピュータ・システムは、少なくとも１つの計算ノードを含み、前記計算ノードは、一のオペレーティング・システム（以下「ＯＳ」と略記）及び一のハイパーバイザを含み、前記ＯＳは、一のカーネルを含み、前記ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含み、
前記方法は、
前記計算ノード上で、前記カーネル・プロキシが使用すべき前記複数のＯＳサービスのうち１つを指定する一のカーネル・ポリシを設定するステップと、
前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスするステップとを含む、方法。
【請求項２】
前記コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムであり、
前記複数のＯＳサービスのうち１つ以上は、前記ＯＳサービス・ノード間に分散され、
さらに、前記カーネル・ポリシは、前記指定されたＯＳサービスを提供すべき１つのＯＳサービス・ノードを指定し、
前記アクセスするステップは、前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスするステップを含む、請求項１に記載の方法。
【請求項３】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記ステップは、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードから、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を検索するステップと、
前記計算ノードによって、前記指定されたＯＳサービスを実装する前記コンピュータ・プログラム命令を実行するステップとを含む、請求項２に記載の方法。
【請求項４】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記ステップは、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードが前記指定されたＯＳサービスを遂行することを要求するステップと、
前記指定されたＯＳサービス・ノードによって、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を実行するステップとを含む、請求項２に記載の方法。
【請求項５】
前記カーネル・プロキシによって、前記カーネル・プロキシが前記指定されたＯＳサービスにアクセスすることができるか否かを判定するステップと、
前記カーネル・プロキシが前記指定されたＯＳサービスにアクセスすることができないときは、前記計算ノードによって、一のデフォルトＯＳサービスを実装するコンピュータ・プログラム命令を実行するステップとをさらに含む、請求項１に記載の方法。
【請求項６】
前記ハイパーバイザが、他のサービス・タイプの一のＯＳサービスを含み、
前記カーネル・プロキシによって、前記カーネル・ポリシが前記他のサービス・タイプの前記一のＯＳサービスを指定するか否かを識別するステップと、
前記カーネル・ポリシが前記他のサービス・タイプの前記一のＯＳサービスを指定しないときは、前記計算ノードによって、前記他のサービス・タイプの一のデフォルトＯＳサービスを実装するコンピュータ・プログラム命令を実行するステップとをさらに含む、請求項１に記載の方法。
【請求項７】
前記サービス・タイプの前記複数のＯＳサービスは、同一のアプリケーション・プログラム・インタフェース（以下「ＡＰＩ」と略記）を有し、
前記アクセスするステップは、前記カーネル・プロキシによって、前記同一のＡＰＩを使用して前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスするステップを含む、請求項１に記載の方法。
【請求項８】
前記コンピュータ・システムが並列コンピュータである、請求項１に記載の方法。
【請求項９】
ハイパーバイザ内にポリシ・ベースのオペレーティング・システム・サービスを提供するためのコンピュータ・システムであって、前記コンピュータ・システムは、少なくとも１つの計算ノードを含み、前記計算ノードは、一のオペレーティング・システム（以下「ＯＳ」と略記）及び一のハイパーバイザを含み、前記ＯＳは、一のカーネルを含み、前記ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含み、さらに前記コンピュータ・システムは、複数のプロセッサ及び当該プロセッサに結合されたメモリを含み、前記メモリ内に配置したコンピュータ・プログラム命令が、
前記計算ノード上で、前記カーネル・プロキシが使用すべき前記複数のＯＳサービスのうち１つを指定する一のカーネル・ポリシを設定する機能と、
前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスする機能とを実現する、コンピュータ・システム。
【請求項１０】
前記コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムであり、
前記複数のＯＳサービスのうち１つ以上は、前記ＯＳサービス・ノード間に分散され、
さらに、前記カーネル・ポリシは、前記指定されたＯＳサービスを提供すべき１つのＯＳサービス・ノードを指定し、
前記アクセスする機能は、前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする機能を含む、請求項９に記載のコンピュータ・システム。
【請求項１１】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記機能は、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードから、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を検索する機能と、
前記計算ノードによって、前記指定されたＯＳサービスを実装する前記コンピュータ・プログラム命令を実行する機能とを含む、請求項１０に記載のコンピュータ・システム。
【請求項１２】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記機能は、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードが前記指定されたＯＳサービスを遂行することを要求する機能と、
前記指定されたＯＳサービス・ノードによって、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を実行する機能とを含む、請求項１０に記載のコンピュータ・システム。
【請求項１３】
請求項１ないし請求項８の何れか１項に記載の方法における各ステップの処理をコンピュータに実行させるコンピュータ・プログラム。
【請求項１】
コンピュータ・システム上のハイパーバイザ内にポリシ・ベースのオペレーティング・システム・サービスを提供する方法であって、
前記コンピュータ・システムは、少なくとも１つの計算ノードを含み、前記計算ノードは、一のオペレーティング・システム（以下「ＯＳ」と略記）及び一のハイパーバイザを含み、前記ＯＳは、一のカーネルを含み、前記ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含み、
前記方法は、
前記計算ノード上で、前記カーネル・プロキシが使用すべき前記複数のＯＳサービスのうち１つを指定する一のカーネル・ポリシを設定するステップと、
前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスするステップとを含む、方法。
【請求項２】
前記コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムであり、
前記複数のＯＳサービスのうち１つ以上は、前記ＯＳサービス・ノード間に分散され、
さらに、前記カーネル・ポリシは、前記指定されたＯＳサービスを提供すべき１つのＯＳサービス・ノードを指定し、
前記アクセスするステップは、前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスするステップを含む、請求項１に記載の方法。
【請求項３】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記ステップは、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードから、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を検索するステップと、
前記計算ノードによって、前記指定されたＯＳサービスを実装する前記コンピュータ・プログラム命令を実行するステップとを含む、請求項２に記載の方法。
【請求項４】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記ステップは、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードが前記指定されたＯＳサービスを遂行することを要求するステップと、
前記指定されたＯＳサービス・ノードによって、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を実行するステップとを含む、請求項２に記載の方法。
【請求項５】
前記カーネル・プロキシによって、前記カーネル・プロキシが前記指定されたＯＳサービスにアクセスすることができるか否かを判定するステップと、
前記カーネル・プロキシが前記指定されたＯＳサービスにアクセスすることができないときは、前記計算ノードによって、一のデフォルトＯＳサービスを実装するコンピュータ・プログラム命令を実行するステップとをさらに含む、請求項１に記載の方法。
【請求項６】
前記ハイパーバイザが、他のサービス・タイプの一のＯＳサービスを含み、
前記カーネル・プロキシによって、前記カーネル・ポリシが前記他のサービス・タイプの前記一のＯＳサービスを指定するか否かを識別するステップと、
前記カーネル・ポリシが前記他のサービス・タイプの前記一のＯＳサービスを指定しないときは、前記計算ノードによって、前記他のサービス・タイプの一のデフォルトＯＳサービスを実装するコンピュータ・プログラム命令を実行するステップとをさらに含む、請求項１に記載の方法。
【請求項７】
前記サービス・タイプの前記複数のＯＳサービスは、同一のアプリケーション・プログラム・インタフェース（以下「ＡＰＩ」と略記）を有し、
前記アクセスするステップは、前記カーネル・プロキシによって、前記同一のＡＰＩを使用して前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスするステップを含む、請求項１に記載の方法。
【請求項８】
前記コンピュータ・システムが並列コンピュータである、請求項１に記載の方法。
【請求項９】
ハイパーバイザ内にポリシ・ベースのオペレーティング・システム・サービスを提供するためのコンピュータ・システムであって、前記コンピュータ・システムは、少なくとも１つの計算ノードを含み、前記計算ノードは、一のオペレーティング・システム（以下「ＯＳ」と略記）及び一のハイパーバイザを含み、前記ＯＳは、一のカーネルを含み、前記ハイパーバイザは、一のカーネル・プロキシ及び一のサービス・タイプの複数のＯＳサービスを含み、さらに前記コンピュータ・システムは、複数のプロセッサ及び当該プロセッサに結合されたメモリを含み、前記メモリ内に配置したコンピュータ・プログラム命令が、
前記計算ノード上で、前記カーネル・プロキシが使用すべき前記複数のＯＳサービスのうち１つを指定する一のカーネル・ポリシを設定する機能と、
前記カーネル・プロキシによって、前記指定されたＯＳサービスにアクセスする機能とを実現する、コンピュータ・システム。
【請求項１０】
前記コンピュータ・システムは、１つ以上のＯＳサービス・ノードを含む分散コンピュータ・システムであり、
前記複数のＯＳサービスのうち１つ以上は、前記ＯＳサービス・ノード間に分散され、
さらに、前記カーネル・ポリシは、前記指定されたＯＳサービスを提供すべき１つのＯＳサービス・ノードを指定し、
前記アクセスする機能は、前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする機能を含む、請求項９に記載のコンピュータ・システム。
【請求項１１】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記機能は、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードから、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を検索する機能と、
前記計算ノードによって、前記指定されたＯＳサービスを実装する前記コンピュータ・プログラム命令を実行する機能とを含む、請求項１０に記載のコンピュータ・システム。
【請求項１２】
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードの前記指定されたＯＳサービスにアクセスする前記機能は、
前記カーネル・プロキシによって、前記指定されたＯＳサービス・ノードが前記指定されたＯＳサービスを遂行することを要求する機能と、
前記指定されたＯＳサービス・ノードによって、前記指定されたＯＳサービスを実装するコンピュータ・プログラム命令を実行する機能とを含む、請求項１０に記載のコンピュータ・システム。
【請求項１３】
請求項１ないし請求項８の何れか１項に記載の方法における各ステップの処理をコンピュータに実行させるコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００８−１０８２６０（Ｐ２００８−１０８２６０Ａ）
【公開日】平成２０年５月８日（２００８．５．８）
【国際特許分類】
【出願番号】特願２００７−２７５１１３（Ｐ２００７−２７５１１３）
【出願日】平成１９年１０月２３日（２００７．１０．２３）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成２０年５月８日（２００８．５．８）
【国際特許分類】
【出願日】平成１９年１０月２３日（２００７．１０．２３）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]