グリッドRPC

分散コンピューティングにおけるGridRPCは、グリッド上のリモートプロシージャコールです。このパラダイムは、 Open Grid Forum (OGF)のGridRPCワーキンググループ^[1]によって提案され、クライアントが関数呼び出しと同じくらい簡単にリモートサーバーにアクセスできるようにAPIが定義されています^{[2] 。実装が簡単なため、多くのグリッド}ミドルウェアで使用されており、2007年にOGFによって標準化されました。既存のさまざまなミドルウェア間の相互運用性の理由から、APIに続いて、さまざまなGridRPC API実装の適切な使用方法と動作を説明するドキュメント^{[3]が作成されました。その後、GridRPCデータ管理[4]}の作業が行われ、2011年に標準化されました。

この標準の範囲は、ミドルウェアの実装に関する推奨事項を提供することです。次のトピックを扱います。

• GridRPC ミドルウェアの引数の特定のデータ構造の定義。
• 引数のデータ構造と組み合わせて使用​​されるデータ型の定義。
• 引数のデータ構造の作成、破棄、有効期間、およびコピーのセマンティクスの定義。
• リモート関数の呼び出し引数と属性 (データ型、カウントなど) の可能なイントロスペクション機能の定義。
• 永続的なデータを処理するためのメカニズムの定義。たとえば、「データ ハンドル」などの概念の定義と使用 (grpc_data_t データ型と同じか類似している可能性があります)。これには、遅延コピーセマンティクス、データ リース、タイムアウトなどの概念も含まれる場合があります。
• ワークフロー管理を可能にする API メカニズムの定義。
• Web サービス リソース フレームワークなどの他のシステムとの互換性と相互運用性を評価します。
• 望ましい特性 - 提案された勧告では、スレッド セーフティ、セキュリティ、フォールト トレランスなどの特性を必ずしも指定するわけではありませんが、そのような有用な特性と矛盾があってはなりません。
• API のすべての部分の実装可能性を実証します。
• 完全な GridRPC ミドルウェア推奨事項の少なくとも 2 つの実装をデモンストレーションし、評価します。

既存のミドルウェアおよびアプリケーション プログラミング アプローチの中で、シンプルで強力かつ柔軟なアプローチの 1 つは、従来のクライアント サーバーまたはリモート プロシージャ コール(RPC) パラダイムを通じて、さまざまな管理ドメインで使用可能なサーバーを使用することです。ネットワーク対応サーバー (NES) は、GridRPC とも呼ばれるこのモデルを実装します。クライアントは、グリッドで使用可能なサーバーを見つけることを目的とするリソース ブローカーに計算要求を送信します。サーバー間の作業のバランスをとるために、頻繁にスケジューリングが適用され、使用可能なサーバーのリストがクライアントに返されます。その後、クライアントは、提案されたサーバーの 1 つにデータと要求を送信して問題を解決できます。ネットワーク帯域幅の拡大とネットワーク待ち時間の短縮により、小さな計算要求をグリッドで使用可能なサーバーに送信できるようになりました。今日のスケーラブルなリソース プラットフォームを効果的に使用するには、ミドルウェア レイヤーでもスケーラビリティを確保することが重要です。このサービス指向のアプローチは新しいものではありません。

過去には、いくつかの研究プロジェクトがこのパラダイムをターゲットにしてきました。APIを実装する主なミドルウェアは、DIET、NetSolve/GridSolve、Ninfですが、 OGFのSAGAインターフェースのように、標準化されたAPI呼び出しなしでそれを使用する環境もあります。OmmiRPC、XtremWebなどです。インターネット上のRPCモデルも、いくつかのアプリケーションで使用されています。インターネットを介して透過的に、リモート画像処理計算用のWebページを埋めるだけで、さまざまなアプローチを使用して大規模な最適化問題を解決できます。数学ライブラリの使用、またはGridTLSEのようなスパース線形代数のヒューリスティックと解決方法の研究。^[5]インターネットを介して計算サービスを提供するこのアプローチは、サービス指向コンピューティング（SOA）パラダイムに非常に近く、クラウドコンピューティングの中核です。

コンピューティング グリッドでジョブを実行するためのシンプルかつ効果的な方法の 1 つは、GridRPC パラダイムに依存する GridRPC ミドルウェアを使用することです。各リクエストに対して、GridRPC ミドルウェアは、送信、入出力データ、リモート リソースでのジョブの実行などの管理を行います。サービスを利用可能にするには、プログラマーは 2 つのコードを実装する必要があります。1 つは、データが定義され、サービス要求時にユーザーによって実行されるクライアント、もう 1 つは、リモート リソースで実行されるサービスの実装を含むサーバーです。

^{このようなコードの開発を容易にするための1つのステップとして、 2002}年11月にドラフトとして提案され 、2007年9月からOpen Grid Forum (OGF)標準となっているGridRPC APIを定義することが行われました。したがって、特定のミドルウェアデータを含まないGridRPCソースコードは、任意のGridRPC準拠ミドルウェアでコンパイルおよび実行できます。

GridRPC API の実装の選択の違いにより、GridRPC ミドルウェア間の相互運用性を説明するドキュメントも作成されました。その主な目的は、GridRPC ミドルウェアの動作の違いを説明し、すべての GridRPC ミドルウェアが合格しなければならない共通テストを提案することです。

その後、GridRPC ミドルウェア内のデータ管理について議論が行われました。API のドラフトは、2007 年 10 月の OGF'21 で提案されました。このドキュメントの目的は、GridRPC プラットフォームとクライアント間のデータ交換を操作するための明示的な関数を提供することです。その理由は、(1) グリッド アプリケーションで使用されるデータのサイズは大きい場合があり、無駄なデータ転送は避ける必要があること、(2) データは必ずしもクライアント側に格納されるわけではなく、ストレージ リソース上または GridRPC プラットフォーム内で使用可能になる場合があることです。したがって、副次的な効果として、GridRPC データ管理 API を実装する任意の GridRPC ミドルウェアを使用して、完全に GridRPC 準拠のコードを作成し、コンパイルすることができます。

GridRPC モデルは、次の図に示されています。通信は次のように処理されます: (1) サーバーはサービスをレジストリに登録します。(2) クライアントがサービスの実行を必要とする場合、レジストリに接続し、(3) レジストリはハンドルをクライアントに返します。(4) 次に、クライアントはハンドルを使用してサーバー上のサービスを呼び出し、(5) 最終的に結果を受け取ります。

API に含まれるメカニズムは、サービスへの同期呼び出しや非同期呼び出しを行う手段を提供する必要があります。後者の場合、クライアントは特定のサービスの完了後にブロッキングまたは非ブロッキング方式で待機できる必要があります。当然、これにはいくつかのデータ構造が関係し、API の機能の厳密な定義につながります。

GridRPC データ型

API を実装するには、3 つの主なデータ型が必要です。(1) grpc_function_handle_tは、特定のサーバーにバインドされたリモート関数を表す変数の型です。クライアントによって割り当てられると、このような変数を使用して、必要な回数だけサービスを起動できます。不要になった場合は、ユーザーによって明示的に無効化されます。(2) grpc_session_tは、特定の非ブロッキング GridRPC 呼び出しを識別するために使用される変数の型です。このような変数は、クライアントが呼び出しの後に待機したり、呼び出しをキャンセルしたり、呼び出しのエラー ステータスを確認したりするために、ジョブのステータスに関する情報を取得するために必須です。(3) grpc_error_tは、あらゆる種類のエラーをグループ化し、GridRPC API に関連するステータス コードを返します。

GridRPC 関数

grpc_initialize()およびgrpc_finalize()関数は、 MPIの初期化および終了呼び出しに似ています。これら 2 つの呼び出しの間には、必ず GridRPC 呼び出しを実行する必要があります。これらの関数は、構成ファイルを読み取り、GridRPC 環境を準備して終了します。

関数ハンドルを初期化および破棄するには、grpc_function_handle_init()およびgrpc_function_handle_destruct()関数を呼び出す必要があります。関数ハンドルは、たとえばリソース検出メカニズムによりサーバーに動的に関連付けられる可能性があるため、 grpc_function_handle_default()を呼び出すと、ハンドルで実際の呼び出しが行われるまでサーバーの選択を延期できます。

grpc_get_handle() を使用すると、クライアントは以前に実行されたセッション ID (たとえば、非ブロッキング呼び出し) に対応する関数ハンドルを取得できます。

呼び出しのタイプ（ブロッキングまたは非ブロッキング）に応じて、クライアントはgrpc_call()およびgrpc_call_async() 関数を使用できます。後者の場合、クライアントは呼び出し後にセッション ID を保持します。この ID は、それぞれ完了を調査または待機したり、呼び出しをキャンセルしたり、非ブロッキング呼び出しのエラー状態を確認したりするために使用できます。

一意のまたは多数の非ブロッキング呼び出しを発行した後、クライアントは、grpc_probe() を使用してサービスの実行が完了したかどうかを確認します。grpc_probe_or () を使用して、以前の非ブロッキング呼び出しの 1 つが完了したかどうかを確認します。grpc_cancel () を使用して呼び出しをキャンセルします。grpc_wait () を使用して、要求されたサービスが完了するまでブロックします。grpc_wait_and ( )を使用して、パラメータとして使用されたセッション ID に対応するすべてのサービスが終了するまでブロックします。grpc_wait_or () を使用して、パラメータとして使用されたセッション ID に対応するいずれかのサービスが終了するまでブロックします。grpc_wait_all () を使用して、すべての非ブロッキング呼び出しが完了するまでブロックします。grpc_wait_any ()を使用して、以前に発行された非ブロッキング要求が完了するまで待機します。

コードをコンパイルする必要があるライブラリ（+リンク）について説明し、基本的な例を示します。

• エンドユーザー アプリケーション向け GridRPC モデルと API。OGFリファレンス: GFD-R.52 (2007)
• GridRPC API 仕様の相互運用性テスト。OGF リファレンス: GFD.102 (2007)
• GridRPC 内のデータ管理 API。OGFリファレンス: GFD-RP.186 (2011)

• 食事^[7]
• ネットソルブ/グリッドソルブ^[8]
• ニンフ^[9]
• オムニRPC ^[10]
• エクストリームウェブ
• グリッドアプリケーション用のシンプルなAPI

• GridRPC ワーキンググループ