ダイエット

ダイエット

開発者	INRIA、リヨン高等師範学校、SysFera、CNRS、クロード・ベルナール大学リヨン1
安定版リリース	2.8 / 11/14/11
書かれた	C++、CORBA
オペレーティング·システム	クロスプラットフォーム
タイプ	グリッドとクラウドコンピューティング
ライセンス	セシル
Webサイト	graal.ens-lyon.fr/ダイエット

DIETはグリッドコンピューティング用のソフトウェアです。ミドルウェアとして、DIETはオペレーティングシステム（ハードウェアの詳細を処理する）とアプリケーションソフトウェア（特定の計算タスクを処理する）の間に位置します。DIETは2000年に作成されました。^[1]高性能コンピューティング用に設計されました。現在はINRIA、リヨン高等師範学校、CNRS、クロード・ベルナール・リヨン第1大学、SysFeraによって開発されています。CeCILLライセンスに基づいてリリースされたオープンソースソフトウェアです。

NetSolve/GridSolveやNinfと同様に、DIETはOpen Grid ForumのGridRPC標準に準拠しています。^[2]

DIET プロジェクトの目的は、計算サーバーを構築するためのツール セットを開発することです。分散リソースは、ミドルウェアを通じて透過的に管理されます。ワークステーション、クラスター、グリッド、クラウドで動作できます。

DIET は、 IBMがフランスの 6 つの大学 (ボルドー 1、リール 1、パリ 6、ENS リヨン、ルーアンのクリアン、オルセー) にインストールしたDécrypthon Grid を管理するために使用されます。

通常、GridRPC 環境には、サーバーに問題を送信するクライアント、クライアントから送信された問題を解決するサーバー、ソフトウェアおよびハードウェア リソースに関する情報を含むデータベース、送信された問題とデータベースに含まれる情報に応じて適切なサーバーを選択するスケジューラ、および計算リソースの状態に関する情報を取得するモニターの 5 つの異なるコンポーネントがあります。

DIET のアーキテクチャは異なる設計に従っており、次の要素で構成されています。

1. クライアント - DIET を使用して問題を解決するアプリケーション。クライアントは、Web ページから、または API またはコンパイルされたプログラムを通じて DIET に接続できます。
2. クライアントからの計算要求を受信するマスター エージェント (MA)。次に、MA はサーバーから計算能力を収集し、スケジュール基準に基づいて 1 つを選択します。選択されたサーバーの参照がクライアントに返されます。クライアントは、特定のネーム サーバーまたはさまざまな MA の場所を格納する Web ページによって MA に接続できます。
3. MA とサーバーの間で要求と情報を転送することを目的とするローカル エージェント (LA)。LA に保存される情報は、要求のリスト、サブツリーごとに、特定の問題を解決できるサーバーの数、およびこのサブツリーに分散されているデータに関する情報です。基盤となるネットワーク トポロジに応じて、MA とサーバーの間に LA の階層が展開される場合があります。
4. サーバーデーモン (SeD) は、計算サーバーのエントリポイントです。プロセッサまたはクラスターを管理します。SeD に保存される情報は、サーバー上で利用可能なデータのリスト (分布とアクセス方法を含む)、サーバー上で解決できる問題のリスト、および負荷に関するすべての情報 (CPU 容量、使用可能なメモリなど) です。

2 つのアプローチが開発されました。

• マルチ MA 拡張機能はフランシュ＝コンテ大学によって開発されました。これらのマスター エージェントは通信グラフによって接続されています。複数の DIET プラットフォームは、それぞれのマスター エージェント (MA) を相互接続することによって共有されます。クライアントは通常どおり MA から利用可能な SeD を要求します。MA が問題を解決できる利用可能な SeD を見つけた場合、その参照をクライアントに返します。SeD が見つからない場合、MA は要求を他の MA に転送し、それらの MA も要求を他の MA に転送できます。MA はクライアントの要求を解決できる SeD を見つけると、その参照をクライアントの MA に返し、MA はクライアントに参照を返します。クライアントはその SeD を使用して問題を解決できます。
• DIET_j と呼ばれるP2Pマルチ MA 拡張機能も設計されました。異なる独立した DIET 階層 (マルチ階層アーキテクチャ) の集約は、P2P パラダイムを使用して管理できます。このアプローチは、MA のオンデマンド検出と接続のための JXTA - J2SE ツールボックスに基づいています。このプロジェクトは、現在メンテナンスされていません。

ワークフロー管理のために、DIET は MA DAGと呼ばれる追加のエンティティを使用します。このエンティティは 2 つのモードで動作します。1 つはワークフローの完全なスケジュール (順序付けとマッピング) を定義するモードで、もう 1 つはワークフロー実行の順序付けのみを定義するモードです。マッピングは次のステップでクライアントによって実行され、マスター エージェントを使用してワークフロー サービスを実行するサーバーを検索します。

DIET は、プラグイン スケジューラを介してスケジューリング サブシステムをある程度制御します。^[3]アプリケーションからのサービス要求が SeD に到着すると、SeD はパフォーマンス推定ベクトルを作成します。これは、そのアプリケーションのスケジューリング プロセスに関連するパフォーマンス推定値のコレクションです。この構造に格納される値は、CoRI (リソース情報コレクタ) によって提供される値、または SeD 自体によって生成されるカスタム値のいずれかです。推定ベクトルのサブシステムの設計はモジュール式です。

CoRI は、推定ベクトルに格納され、システム定義のタグによって識別される、パフォーマンス推定値の基本セットを生成します。コア数、合計メモリ、bogomips 数、ハード ドライブ速度などの静的な情報と、特定のリソースで問題を解決するために予測される時間、平均 CPU 負荷などの動的な情報が、より適切なスケジューリングのための適切な情報を提供するために、サーバー デーモンからスケジューラ エージェントに転送されます。前述のように、これらは DIET のアプリケーション駆動型スケジューラ機能と相関して使用されます。アプリケーションのニーズをよりよく理解しているサーバー デーモンは、このベクトルに格納されている情報に基づいて特定のスケジューリングを要求できます。

DIET には 3 つの異なるデータ マネージャーが統合されています。

1. フランシュ＝コンテ大学のDTM （維持されていません）
2. IRISAのJuxMEM （メンテナンスされていない）^[4]
3. リヨン高等師範学校のDAGDA 。

並列リソースは、通常、バッチ システムとも呼ばれる LRMS (ローカル リソース管理システム) を通じてアクセスできます。DIET は、ジョブを実行するために、いくつかの既存の LRMS とのインターフェイスを提供します。LoadLeveler (IBM リソース上)、OpenPBS (有名なPBSシステムのフォーク)、およびOAR (グルノーブルのIMAGによって開発された Grid'5000 研究グリッドで使用されるバッチ スケジューラ) です。送信されたジョブのほとんどは並列ジョブであり、MPICH や LAM などのインスタンス化を使用して MPI 標準を使用してコーディングされています。

DIETのクラウド拡張機能は2009年に作成されました。^[5] DIETは、既存の2つのクラウドプロバイダーを通じてクラウドリソースにアクセスできます。

1. Eucalyptusは、カリフォルニア大学サンタバーバラ校が開発したオープンソースソフトウェアです。
2. Amazon Elastic Compute Cloud は、 Amazon.comのクラウド コンピューティング サービスの商用ソフトウェアの一部です。

• Décrypthon プロジェクトのウェブサイト
• DIETのウェブサイト
• SysFeraのウェブサイト