レベル: 中級 Jeff Mausolf (mausolf@us.ibm.com), IT Architect, IBM, Grid Computing Initiative
2005年 07月 12日 グリッド・システムでは、資源マネージャーがローカル資源を調整、制御します。しかし、どのように資源マネージャーを管理すればよいのでしょうか。この記事では、資源マネージャーの階層構造を統括するメタスケジューラーについて紹介し、それが複数の資源マネージャー全体でワークロードをどのようにバランスさせるかを説明し、読者のグリッド・プロジェクトにとって最適なメタスケジューラーを選択する基準を提供します。これは、テキサス大学グリッド・プロジェクトの要素の一つです。
これまでは、部門毎に、自分たちのアプリケーション用のプラットフォームを購入しピーク時の需要をサポートするための資源を購入していました。こういった資源間でワークロードを効率的に分散するために、資源マネージャーがしばしば使用されました。資源マネージャーが作業の実行依頼を受け取り、事前定義されたスケジュール・ポリシーやその時々の資源の可用性に基づいて各資源にジョブをスケジューリングしました。
時間と共に、部門毎に分かれた資源の「ポケット」が蓄積されていきました。これらの資源の「ポケット」は、低い使用率や、時にはピーク時の負荷を処理するだけの資源が不足している、と特徴づけられたりしました。部門によってピークのタイミングや頻度は異なるものの、どこでも同様の現象が見られました。
では、日常のワークロード処理に十分な資源が各部門にあればどうでしょうか。ピーク時の急激な需要に対応するために追加資源をプロビジョニングしたり、企業内のどこかにある十分活用されていない資源で現在の資源を補充したりできればどうでしょうか。資源全体の使用率が向上するという、グリッド・コンピューティングの目標の一つが達成されることでしょう。
言うまでもなく、資源マネージャーの役割は資源管理です。グリッドは資源マネージャー及び資源の集合体です。では、資源マネージャー同士が共同して働くようにするにはどうすればよいのでしょうか。これがグリッド・メタスケジューラーの入り口です。メタスケジューラーは、資源マネージャーの集合体でワークロードをバランスさせ、複数のクラスターを効率的にまとめたり、スケジューラーを階層化したりします。メタスケジューラーは複数の資源マネージャー間の通信を調整し、ビジネス・ポリシーに基づいて働き、サービス・レベル契約の強制を行い、結果として資源マネージャーはその管理対象のローカル資源上でジョブを効率的に管理します。
この記事には、ニーズに合ったメタスケジューラーを選択する際の考慮事項として、読者のグリッド・プロジェクトの特徴を評価するチェックリストを記載しています。また、個々のメタスケジューラーを評価するための質問や、評価の様々な側面の詳細も記載しています。
グリッドにおけるメタスケジューラーの位置づけ
グリッド・コンピューティングのもう一つの目標は、仮想化によって複雑なものを抽象化することです。
ユーザーの多くは、資源マネージャーにジョブの実行依頼を行います。複数の資源マネージャーが存在する場合、ユーザーは資源マネージャーそれぞれにログインし、ジョブ・キューを参照して、どれが最も早くジョブを実行できそうかを判断します。次に、ジョブ・キューの最も短い資源マネージャーにジョブの実行を依頼します。ユーザーはさまざまなシステムにアカウントを持ち、さまざまな資源マネージャーにジョブを実行依頼したり、監視したり、ジョブを制御する方法を知っていなくてはなりません。
プロセッシング・グリッドにメタスケジューラーを導入すれば、シングル・システムでの認証が可能になり、統一された方法でジョブを実行依頼できるようになって、ユーザーの負担の多くをなくすことができます。ビジネス・ポリシーとサービス・レベル契約 (SLA) に準拠しながら最短時間で完了するようにジョブを実行するにはどこで実行させるべきかを、システムが判断してくれるからです。
グリッドでは、資源マネージャーが引き続き資源を管理する一方、資源マネージャーに対するワークロードを管理するメタスケジューラーを実装できます。メタスケジューラーは、ビジネス・ポリシーや管理している資源からのフィードバックに基づいて効率的にワークロードを分散します。ユーザーがメタスケジューラーにジョブの実行を依頼すると、メタスケジューラーは、すべての資源マネージャーを調整し、現在の負荷、バックログ、キューされたジョブの優先順位を把握します。メタスケジューラーは、ビジネス・ポリシーや SLAと共に、これらの情報に基づいて、インテリジェントにスケジューリングを決定します。メタスケジューラーは、「複数の」資源マネージャーのワークロードだけでなく、「複数種類の」資源マネージャーのワークロードをも調整できるので、さまざまな部門の異種混合資源の統合が可能です。
メタスケジューラーでは一元的なジョブ管理と資源管理を提供します。そのため、異なる種類の資源マネージャーに関するジョブ実行依頼構文を知らないユーザーでも、ジョブの実行を依頼することができます。
選択プロセスの概要
UT (訳注:University of Texas) グリッド・プロジェクトでは、最適なメタスケジューラーを選択する際に、複数の現実的な意思決定が行われました。意思決定に影響を与えた主な基準を以下に示します。
- 複数のメタスケジューラーについて検討し、キャンパス・クラスターの一部で既に稼働している資源マネージャーにうまく統合されなかったメタスケジューラーを選択対象から外しました。
- 残ったメタスケジューラーの機能を調査し、最も重要な機能を提供するメタスケジューラーを評価するチームを指定しました。
- このチームの調査では、ユースケースを想定して評価を行い、完全に満たされた要件や部分的に満たされた要件を記録しました。
- 満たされなかった要件や部分的に満たされた要件については、完全に要件を満たすプロダクトにするための作業を見積もりました。
チェックリスト:メタスケジューラーの選択
ここまでで、メタスケジューラーとその役割が明らかになりました。ここからは、メタスケジューラーの選択時に考慮すべき多くの要因について検討していきます。これらの27個の要因は、プロダクト評価の基準として考えることもできます。
次に、メタスケジューラーを評価する際の主な考慮事項をリストします。これには、プロダクトを作ったり管理したりしている企業に関する質問も含まれます。
プロダクトに関する質問
- メタスケジューラーが統合するのはどの資源マネージャーですか。例:Platform LSF のサポート。
- どのプラットフォームサポートされていますか。例:LinuxR をサポート。
- どのセキュリティー・メカニズムがサポートされていますか。例:GSI セキュリティーのサポート。
- チェックポイント及びプロセス移行(migration)がサポートされていますか。
- グローバル・ネーム・スペースは前提となっていますか。
- ジョブのスケジューリングに加えて、データのステージングも調整できますか。
- どのようなスケジューリング・ポリシーが提供されていますか。
- 既存のポリシーの更新や固有のポリシーの追加のためにどのようなツールが提供されていますか。
- 動的なポリシーの更新がサポートされていますか。
- パラレル及びシリアルのジョブの実行依頼はサポートされていますか。
- 事前予約(advanced reservation) はサポートされていますか。
- 動的なクライアントはサポートされていますか。
- 動的な構成変更はサポートされていますか。
- 診断ツールは提供されていますか。
- アカウンティング及び資源消費情報は提供されますか。
- テストされている構成やサポートされている構成はどのようなものですか。
- どのようなドキュメンテーションやトレーニングが利用可能ですか。
- ライセンスにかかるコストはいくらですか。
- どのような種類のサービスが利用可能で、コストはいくらですか。
- ユーザーと管理者には、それぞれどのようなインターフェースが提供されていますか。
企業に関する質問
- その会社はどのくらいの期間ビジネスをしていますか。
- 開発部門、テスト部門、サポート部門の従業員数は何人ですか。
- オフィスの所在地はどこですか。
- カスタマー・リファレンスを持っていますか。リファレンス先に問い合わせることはできますか。
- そのプロダクトはどのぐらいの前から稼働していますか。
- インストール・ベースはどれくらいですか。
- リリース・サイクルはどれくらいですか。
次に、これらの基準をさらに詳しく説明していきます。
基準の詳細
以降のセクションでは、チェックリストの各項目について詳しく説明します。これは、前述の 27 個の質問に対する回答が、読者のプロジェクトに最適なメタスケジューラーを選択するのを容易にするツールであることの理由を理解する助けになるでしょう。
資源マネージャーのサポート
ポピュラーな資源マネージャーの例を以下に示します。
- Platform LSF
- PBS Pro または OpenPBS
- Sun Grid Engine
- Condor
- IBM LoadLevelerR
資源マネージャーが既に稼働している場合、メタスケジューラー選択時の重要な考慮事項は、メタスケジューラーは現在使用中の資源マネージャーをうまく統合できるか、どのような程度の統合が必要なのか、です。メタスケジューラーは、一部の資源マネージャーにはシームレスに統合可能です。
直接の統合が提供されていない場合、Globus Alliance によって提供されている GRAM (Global Resource Allocation Manager) を介して資源マネージャーにジョブの実行を依頼できます。
プラットフォームとチェックポイント
資源マネージャーの中には、限られたプラットフォームでのみサポートされているものがあります。限定されたプラットフォームのみをサポートし、サポートしているプラットフォームのためのソフトウェア・スタックを制御することには利点があります。カーネル・ソース・コードにアクセスして変更やカーネル拡張を行えるため、実行中のジョブのチェックポイントなどといった高度な機能をサポートできるのです。
チェックポイントや移行によって実行中のジョブの状態を保存しておけば、実行済みの計算結果を失うことなく、新たな日時に再開したり、別の資源上で再開したりできます。
資源マネージャーの中には、アプリケーションの種類に応じてチェックポイント機能や再起動機能を提供するものがあります。例えば、MPI ジョブのチェックポイントと移行は、標準的なジョブのチェックポイントよりもはるかに複雑です。これは、カーネル拡張の手段によってカーネルと調整することによってのみ達成できます。
また、チェックポイント機能と移行機能をサポートするために必要な、ジョブに対する変更---もし変更が必要なら---についても考慮する必要があります。一部のスケジューラーでは、チェックポイントやプロセス移行をサポートするには、ジョブを特定ライブラリーと再リンクしなければなりません。
このことはスケジューリング・ポリシーにも関連します。なぜなら、プリエンプティブなスケジューリング・ポリシーが選択された場合は、チェックポイントとプロセス移行が重要な考慮事項となるからです。プリエンプティブなスケジューリング・ポリシーでは、優先順位の高いジョブがジョブ・キューに入ってくると、資源上で実行されている優先順位の低いジョブは優先権を剥奪されます。優先順位の低いジョブが長時間実行されるタスクである場合、かなりの処理が既に行われているかもしれません。もしもチェックポイントがサポートされていれば、優先順位の低いジョブのチェックポイントを作成し、そのプロセスを別の資源に移行して処理を継続させることができます。これによって優先順位の高いタスク用に資源が解放されます。もしもチェックポイントがなければ、実行済みの計算結果は失われてしまいます。
セキュリティー
セキュリティーは、シングル・サインオンが望ましい分散コンピューティング環境においてはさらに複雑になります。シングル・サインオンでは、ユーザーは 1 回認証すれば、タスク実行に必要とされる 1 つ以上の資源にクレデンシャル(セキュリティー証明書)を委譲することができます。
どのようなセキュリティー・メカニズムがメタスケジューラーによってサポートされているかは、重要な考慮事項です。一部のメタスケジューラーは、基盤となるオペレーティング・システムのセキュリティーに依存しています。このような場合、ユーザーは、メタスケジューラーでの認証に使用されるのと同じユーザー ID とクレデンシャルを、ターゲット資源へのアカウントとしても持っていなくてはなりません。
ユーザー ID (UID) とグループ ID (GID) をシステム間でマッピングし、各システムで異なったID をユーザーが保有できるようにする、という高度な方法もあります。この UID/GID マッピングは通常、ユーザーのクレデンシャルの委譲をサポートというもう一つの高度な機能と併用されます。委譲により、ユーザーに代わってサービスがジョブを実行することができます。
既存のセキュリティー・メカニズムや製品によって提案されているセキュリティー・メカニズム、及び必要な統合レベルをメタスケジューラーがサポートしているかどうかを、検討して下さい。
グローバル・ネーム・スペース
メタスケジューラーの役割は、すべての使用可能資源にワークロードをバランスさせることです。ジョブの実行をメタスケジューラーに依頼するとき、どのマシンで実行されるかはまだ分りません。そのジョブが入力ファイルを必要とする場合、検討対象のメタスケジューラーは、ジョブの実行場所に関係なく、入力データへのパスと実行ファイルへのパスを同一と見なすでしょうか。
すべての資源がストレージ・エリア・ネットワーク (SAN) に接続されている場合やグローバル・ネーム・スペースを使用している場合は、同一と見なすかもしれません。しかし、そうでない場合、メタスケジューラーは、入力データのステージングを調整したり、ジョブに対して選択されたターゲット資源に向けて実行ファイルを調整したりできるでしょうか。
スケジューリング・ポリシー、測定、レポート
メタスケジューラーは通常、ワークロードをバランスさせるスケジューリング・ポリシーを持っていたり、フェア・シェアのルールを提供しています。しかしながら、ポリシーは組織によって大きく異なるため、組織のビジネス・ポリシーを実装するには、多くの場合ポリシーのカスタマイズが必要です。優先順位、入力データ、CPU 数、メモリー量、ディスク・スペースなどのジョブ属性がジョブがスケジュールされるべき場所を決定しますが、通常、ジョブの要件とコストとを関連付けるのはスケジューリング・ポリシーです。
例えば、特定のソフトウェア・ライセンスを必要とするジョブや高速相互接続の CPU を多数必要とするジョブは、より高価な資源を必要とするため、単純なアプリケーションを実行するジョブよりコストがかさみます。そのため、高価な資源のコストを回収したり、今後の資源調達の根拠とするために、何らかの測定基準をポリシーに実装する場合もあります。
検討しているメタスケジューラーは、資源消費の追跡、重要な測定データの採取、必要なレポートの生成をサポートしていますか。
カスタム・ポリシー
独自のポリシーが必要とされる場合も多いため、新しいポリシーの実装や既存のポリシーのカスタマイズがどの程度容易かについても検討しておきます。新しいポリシーの実装は、GUI でビジネス・ルールを定義する場合と同じように容易かもしれません。あるいは、独自のスケジューリング・プラグインをコーディングし、そのスケジューリング・ポリシーを適用すべき各ジョブ・キューそれぞれにインストールしなければならない場合もあるでしょう。
ポリシーの定義方法に応じて、メタスケジューラーが変更を認識する方法が決まる場合もあります。通常、ビジネス・ルールに加えた変更は実行時に追加されます。一方、カスタム開発されたスケジューラー・プラグインを追加した場合、その追加を有効にするには、システムの再起動が必要です。システム再起動に伴う機能停止は、ほとんどの環境において望ましくありません。
動的な資源
利用されていない予備サイクルを活用する環境では、資源は資源マネージャーに動的に追加または削除されます。これは、プロビジョニングやオーケストレーションが実装されている場合も同様です。
資源マネージャーは資源の動的な追加または削除をサポートしていますか。追加資源が資源マネージャーによって認識され、今後の作業に活用されるようにするには、どのようなステップが必要ですか。障害の起きた資源や削除された資源を資源マネージャーはどのように処理しますか。障害の起きた資源上で実行されているタスクについては、別の資源を使用した実行の依頼が自動的に行われますか。
事前予約 (Advanced Reservation)
ここまでは、「ジョブは最短時間で完了できる資源上で実行すべきである」いう前提の下に、ジョブの実行依頼について説明してきました。ここでは、事前予約機能の利点について検討します。事前予約によって、ユーザーは将来の日時における資源を予約できます。もし事前予約が必要ならば、検討中のメタスケジューラーは事前予約をサポートし、事前予約が要求された場合に予約対象資源に対する予約を調整することができるか検討します。
ドキュメンテーション
開発者用ガイドは API の開発に役立ちます。それ以外のドキュメンテーションもまた重要です。高品質のインストール・ガイド、管理者ガイド、ユーザー・ガイドがベンダーから提供されていますか。ユーザーや管理者はどのようなトレーニングを受講できますか。推奨されているトレーニングは何ですか。
ライセンス
メタスケジューラーがインテリジェントなスケジューリングの決定を行うには、制御対象資源からのフィードバックが必要です。この機能はエージェントが行い、エージェントは通常すべての管理されている資源上で実行されます。メタスケジューラーがインテリジェントなスケジューリングの決定を行えるように、エージェントはメタスケジューラーに情報を返送します。
一般に、メタスケジューラーのライセンス料金はエージェントごとに設定されますが、料金や料金の仕組みには大きな幅があります。詳細については、製品ベンダーに確認してください。
インターフェース
もう一つの重要な考慮事項となるのは、提供されるインターフェースです。資源状況の参照などの一部のタスクには視覚的な GUI が適していますが、コマンドライン・インターフェースのほうが適しているタスクもあります。検討しているメタスケジューラーは、ユーザー及び管理者が使用できる GUI および CLI をサポートしていますか。プログラマチックなジョブの実行の依頼、監視、制御をサポートしているAPIは存在しますか。
実装によっては、Web サービス・インターフェースや Java™ テクノロジー API が好ましい場合もあります。メタスケジューラーは、読者の組織で必要とされるインターフェースをサポートしていますか。
製品と企業の歴史
企業とソフトウェアの歴史についても考慮する必要があります。
そのプロダクトは、どのぐらいの間、業務利用されてきたものなのでしょうか。ソフトウェアはどのリリースが入手可能ですか。リリース・サイクルはどれぐらいですか。将来のリリースの内容に関するプロダクトのロードマップはベンダーから提供されていますか。現在の製品のインストール・ベースはどれくらいでしょうか。カスタマー・リファレンスは提供されていますか。提供されている場合、そのレファレンス先から製品やサービスに関する意見を直接得ることはできますか。現在稼働している構成はどのようなものですか。調整できる資源の数と種類はどうなっているでしょう。サポートされている構成及びテスト済みの構成はどのようなものでしょう。
企業情報も同様に重要です。創業して何年経過していますか。業績見通しどうでしょうか。開発部門、テスト部門、サポート部門の従業員数は何人ですか。読者のプロジェクトの開発や実行が行われている場所の近くに、フィールド・サポートのできるオフィスはあるでしょうか。サポート契約は提供されているでしょうか。応答時間、問題判別、問題の特定、解決、エスカレーションなどに関するサービス・レベル契約はあるでしょうか。
まとめ
この記事では、グリッド・メタスケジューラーがどう動くのかを説明し、読者のプロジェクトでメタスケジューラーを評価する時に考慮すべき 27 の基準について紹介しました。各製品をシンプルに比較するには、各列にプロダクト名、各行に必要な機能を記入した表を作成しましょう。各行を詳細に検討し、該当機能をサポートする製品の列にチェック・マークを付けます。
複数のサポート・レベルがある場合を考慮して、1から5のような数値を割り当て、1 は部分的なサポート、5 は完全なサポートを示すようにすることも可能です。各行を評価した後、列の評価値を合計して評価スコアを出します。
さらに洗練された比較方法は、組織にとってどの程度重要な機能なのかに基づいて、各行に加重係数を付けることです。この加重係数に行スコアを掛け合わせたものが、機能のサポート・レベルとその組織にとっての重要度を示す数値となります。
このシリーズの次の記事では、プラットフォーム・コンピューティング社から提供されている Community Scheduler Framework V4.0 メタスケジューラーについて説明します。このスケジューラーは、GT4 にテクノロジー・プレビューとしてバンドルされています。
参考文献 学ぶために
-
A Metascheduler Proof of Concept using IBM Tivoli Workload Scheduler (IBM Redpaper, April 2005) details a proof of concept project that drew together many heterogeneous local grid schedulers through a meta-scheduler.
- The Moab Grid Scheduler (previously "Silver") is a good example of an optimizing advanced reservation-based grid scheduler, which allows distributed workload to be run across independent clusters.
-
OpenPBS is the original version of the Portable Batch System. It is a flexible batch-queuing system developed for NASA that operates on networked multiplatform UNIX® environments.
議論するために
著者について  | 
| | Jeff Mausolf is a certified IT architect for the IBM e-Technology Center in Austin, Texas. He is part of the Grid Computing Initiative and has worked on numerous grid engagements. He also authored an IBM Redbook on developing grid services. He is working with the University of Texas at Austin to develop a campus grid, which will become part of the Extended TeraGrid Facility (ETF) later this year. He has worked as an application architect and software engineer on e-business engagements where he developed portals for many state governments and agencies. He has a master's degree in computer science and has been with IBM for 12 years. Before coming to IBM, he was in the aerospace industry and held positions with Lockheed, Loral, and Ford Aerospace, supporting contracts with NASA at Johnson Space Center in Houston. While in Houston, he supported mission training for astronauts in the Shuttle Engineering Simulation (SES) laboratory, helped build space station components and the mission control training facilities, and worked on the AP101S General Purpose Computer (GPC) for the space shuttle.
|
記事の評価
| 
