例 3: 使用可能なディスク容量の管理

一部のアプリケーションでは、ファイルに格納されている大量のデータセットを操作する必要があります。このようなアプリケーションは、実行時間全体を通じて、十分なディスク容量を利用できる必要があります。この要件は、前の例で説明した使用可能なメモリーの容量の共有に似ています。主な違いは、Grid Engine システムでは、標準的な負荷パラメータの 1 つとして空きディスク容量が用意されていない点です。ディスクは通常、サイト固有の方法でファイルシステムに分割されているため、空きディスク容量は標準的な負荷パラメータではありません。サイト固有のパーティション分割により、対象のファイルシステムの識別を自動で行うことができません。

それにもかかわらず、使用可能なディスク容量は、消費可能リソースの機能を通じて、システムによって効率的に管理することができます。この目的のためには、ホストリソース属性 h_fsize を使用する必要があります。

まず、次の図に示すように、属性を消費可能リソースとして構成する必要があります。

ローカルホストファイルシステムの場合、次の図に示すように、ディスク容量のコンシューマブルに関するリーズナブルな容量の定義を、ホスト構成に配置することができます。

このように構成された Grid Engine システムに対するジョブの発行は、以前の例と同じように機能します。

% qsub -l hf=5G big-sort.sh

ここで h_fsize 属性が推奨されているのは、h_fsize は、キュー構成において固定ファイルサイズ制限値としても使用されているためです。ファイルサイズの制限値は、ジョブ発行時に指定されるよりも大きなサイズのファイルを作成するジョブの権限を制限します。この例の qsub コマンドは、5G バイトのファイルサイズの制限値を指定しています。ジョブが属性を要求しない場合、キュー構成またはホスト構成からの対応する値が使用されます。例で h_fsize の Requestable フラグが FORCED に設定されている場合、qsub コマンドには要求が含まれている必要があります。Requestable フラグが設定されていない場合は、qsub コマンドでは要求はオプションになります。

消費可能リソースとしてキュー制限値を使用することで、ジョブスクリプトによる実際のリソース消費量の代わりに、ユーザーが指定する要求を制御します。制限値の違反は制裁されるため、最終的にはジョブが異常終了します。キュー制限値により、Grid Engine システム内部の容量計画のベースとなる、リソース要求の信頼性が確保されます。詳細については、queue_conf(5) および setrlimit(2) のマニュアルページを参照してください。

一部のオペレーティングシステムでは、プロセスごとのファイルサイズの制限値のみ使用できます。この場合は、ジョブは制限値までのサイズの複数のファイルを作成する場合があります。ジョブごとのファイルサイズの制限値をサポートしているシステムでは、Grid Engine システムは h_fsize 属性とともにこの機能を使用します。詳細については、queue_conf(5) のマニュアルページを参照してください。

Grid Engine システムに発行されないアプリケーションに、同時にディスク容量を占有させたい場合があります。このような場合、ディスク容量の不足により、内部のブックキーピングではアプリケーション障害を防ぐのに十分ではない場合があります。この問題を回避するため、ディスク容量の使用量に関する統計を定期的に受信することができます。そうした統計によって、Grid Engine システムの外部で発生しているものも含めて、全体のディスク領域の消費量が分かります。

負荷センサーインタフェースを使用すると、ファイルシステム上で使用可能なディスク容量など、サイト固有の情報を持つ、標準的な負荷パラメータのセットを強化することができます。詳細については、「サイト固有の負荷パラメータの追加」を参照してください。

適切な負荷センサーを追加し、 h_fsize に関して空きディスク容量を報告することで、消費可能リソースの管理とリソースの可用性の統計を組み合わせることができます。Grid Engine システムは、ディスク容量のジョブ要件と、使用可能な容量、および報告された最新の負荷値を比較します。使用可能な容量は、内部のリソース計画から得られます。ジョブがホストに振り分けられるのは、両方の基準が満たされた場合のみです。