Univa Grid Engine (UGE) Release Notes

v8.4.4 (2017-01-17)

(1) Define behaviour if epilog script dies because of signal

 

execd_params RESCHEDULE_ON_KILLED_EPILOG (see also man page sge_conf(5)) を定義することで、シグナルにより epilog が終了した場合に、ジョブが再スケジューリングされることを防ぐことができるようになります。このデフォルトの値は、"TRUE" または "1" で、これまでと同じ動き、つまり、そのキューは、error state にセットされ、ジョブがぺディングされているジョブリストに再配置されます。"FALSE" または "0" にした場合には、ジョブは終了し、稼働統計に記録され、ジョブリストから除外されます。そのようなジョブの"failed"フィールドは、"15 : in epilog" にセットされます。しかし、exit_status は、そのジョブ自身のものが表示されます。これは、epilog が重要ではないジョブの終了処理を行う場合で、その終了処理の問題のためにジョブのワークフローが妨害されるべきではない場合に役立ちます。epilog がシグナルされていると検知された場合には、exit_status が稼働統計に記録され、epilog が 127 より上の status で exit したものと扱われます。

 

(2) Docker integration

Docker integration の特徴

 

Univa Grid Engine 8.4.4 は、Docker コンテナ とのインテグレーションを提供します。この技術は、Docker イメージから作成された Docker container をジョブが使うように指定するものです。詳しくは、ユーザーガイド の7.9章「Jobs using Docker Containers」及び 2.5.2章の「Configuring Queues」を御確認ください。

 

Univa Grd Engine 8.4.2 の新機能

Univa Grid Engine は、コンテナが作成された Docker イメージで定義されている Entrypoint を使用できるようになりました。これにはいくつかの制限がありますが、バッチコンテナを簡単に開始できます。ジョブが定義された Entrypoint を使用するためには、ジョブスクリプト "NONE" を使用してバイナリジョブとして送信します。例:$ qsub -l docker、docker_images = "* myapp:latest *" -b y NONEこれはシーケンシャルジョブでのみ許可されます。対話型および並列ジョブはサポートされていません。詳細は UsersGuide の章7.9 "Jobs sing Docker Containers" を参照してください。

※制限事項

  • アーキテクチャ:x64 Linux のみ対応。他のアーキテクチャはサポートしません。

  • Docker version: 1.8.2から1.10.3

  • Docker の API は、後方互換性が図られないことが良くあるため、より新しいバージョンの Docker はサポートされません。Docker インテグレーションは動作するかもしれませんが、保証の範囲外です。Docker API の問題は診断が難しいため、Univa Grid Engine が実行ホスト上でサポートされていないバージョンのDockerデーモンを検出すると、そのホストを使用可能なDocker ホストとしてレポートするのではなく、Docker がインストールされていないホストとしてレポートします。

  • 時々、Docker デーモンは "docker images" 要求に対して有効な、しかし空のメッセージで応答しますが、ジョブ実行デーモンは、イメージを使用できないDockerの有効な応答と区別できません。このような空のメッセージが発生した場合、実行デーモンにGrid Engineリリースノートv 8.4.4 7 3の修正および拡張を開始するジョブがある場合、実行デーモンはイメージが削除されたとみなしてジョブを開始できないため、このジョブは失敗します。

  • コンテナで実行されるジョブのチェックポインティングは、サポートされません。

  • コンテナでは、ビルトインされた対話的なジョブのみがサポートされます。

  • ジョブ投入時の -xd オプション は実験的に加えられました。高度な利用用途では、問題が発生する可能性があります。例えば、ネットワーク設定を複数指定する場合や、データを重複して指定する場合などがそれに該当します。尚、-xdv オプションは、推奨されず、-xd -v オプションにリプレイスされます。

 

(3) Host resolving and host_aliases file

 

  • 負荷センサーによって報告されたホスト名は、実行側で解決されます。 host_aliases ファイルの設定は、外部負荷センサーを介した負荷レポートにも使用されるようになりました。

  • qmasterの起動時に、データベース内のスプールされたオブジェクトのホスト名解決が検証されます。設定リスト、管理ホストリスト、execdリスト、またはサブミットホストリストで参照されるホストの結果のホスト名が変更された場合、すべてのスプールされたデータオブジェクトは新しい結果のホスト名と一致するように調整されます。

  • リソースホスト名要求(-l h =)は、正規表現要求でのプレーンなホスト名の解決をサポートするようになりました。これには、エイリアス化されたホスト名の使用も含まれます。

  • qmaster デーモンの実行中に host_aliases ファイルに新しいエントリを追加できるようになりました。すでに参照されているホスト名を変更するには、qmaster を再起動する必要があります。現在の host_aliases の変更が再起動を必要とする場合、qmaster プロセスはこの情報をメッセージファイルに記録します。ランタイム中にすでにアクティブなホストエイリアスを変更するには、対応するホストを Univa Grid Engine から削除する必要があります。実行中の sge_qmaster サービスまたは sge_execd サービスのインタフェースに影響するホスト名の変更は、常にサービスの再起動が必要です(動作は変更されません)。

  • クライアントツールの qping および gethostbyname には、サービスを解決した後に結果のホスト名を表示するための新しいオプション(-all_rr)が追加されました。このツールは、実行中の qmaster が host_aliases ファイルの変更を引き継ぐまで待機するために使用できます。

  • (qmaster_paramsを介して)内部ホスト名キャッシュ用の個々の qmaster パラメータを設定することができます。キャッシュされたエントリの数は、qping または PROF_COMMLIB_TIME qmaster param で取得できます。

 

(4) Scheduler specific changes

 

  • スケジューラ設定パラメータ "params"を使用してプロファイリングを有効にすることができます(PROFILE = true)。「WARN_DISPATCHING_TIME」の値と組み合わせて、ジョブスケジューリングの最長時間と最短時間に関する追加情報を表示することができます。

  • スケジューラプロファイリングは、スレッド固有のユーザおよびシステム時間測定(Linuxカーネル> = 2.6.26およびSolarisオペレーティングシステム)をサポートするアーキテクチャに基づくスレッドになりました。これにより、スケジューラー・スレッドのシステム時間とユーザー時間が正確になります。他のアーキテクチャでは、ユーザーの時間とシステム時間がプロセス全体で測定されます。これは、wallclock時間だけがスケジューラスレッドのオーバーヘッドを反映していることを意味します。この場合、システムとユーザーの時間はプロセスのすべてのスレッドの使用状況を示し、スケジューラのスレッド固有のものではありません。

  • スケジューラスレッドのプロファイリングサマリには、RQS(Resource Quota Sets)計算に使用された時間に関する情報が含まれます。一部のRQSルールがスケジューリング時間に予期しない大きな影響を与える場合、このルールのプロファイリングデータもプロファイリング出力に発生します。

  • 定義済みのRQSは、スケジューラがジョブをディスパッチしている間に明確なRQS処理順序を定義できるように、名前に英数字でソートされるようになりました。処理オーダはスケジューリング時間に影響を与える可能性があり、最適化することができます。最も制限の厳しいルールが最初のルールになります。

  • スケジューラーによって使用されるフィルター規則が現在アクティブであるため、qsub / qalter -w コマンドによるスケジュール情報メッセージが、 異なるメッセージを提供するようになりました。 qsub / qualter -w を介したシミュレートされたスケジューリング実行によって得られた結果のスケジューリング情報は、より良い結果を生むはずです。

 

(5) Execution daemon specific changes

 

GE-5849の実装により、特に -masterl スイッチが使用されている場合、限界設定と観測動作を変更する必要がありました。パラレル環境設定(PE) "master_forks_slave" の場合、結果の制限はマスター・タスク自体に使用される制限値だけ増加します(マニュアル・ページsge_peを参照)。 "master_forks_slave" PE 設定は、PE設定 "control_slaves" を false(Loose Integration)に設定するためにも使用されるようになりました。 Univa Grid Engine 8.4.2のインストール後に "control_slaves = false" の PE を使用するジョブの制限に達した場合は、ジョブのスロット数に応じて "master_forks_slave = TRUE" を使用して制限を増やすことができます。

 

(6) Intel® Xeon Phi™ x200 (Knights Landing) integration

 

Univa Grid Engine 8.4.4 は、Intel®Xeon Phi™x200(Knights Landing)プロセッサのインテグレーションを提供します。pre-compiled load-sensor は、現在のクラスターを x200 マシンの現在のメモリー・モードとしても自動的に検出します。さらに、現在の MCDRAM 分布がレポートされます。詳細については、管理者ガイドの“Configure and Install Intel Xeon Phi x200 (Knights Landing) Processors support” を参照してください。

v.8.4.1 (2016-07-12)

(1) Features of the Docker integration

UGE 8.4.1は、Docker container のインテグレーションを提供します。この技術は、Dockerイメージから作成された Docker container をジョブが使うように指定するものです。詳しくは、ユーザーガイド の7.9章「Jobs using Docker Containers」及び 2.5.2章の「Configuring Queues」を御確認ください。


※制限事項

  • アーキテクチャ:x64 Linux のみ対応。他のアーキテクチャはサポートしません。

  • Docker version: 1.8.2から1.10.3

    • Docker の API は、後方互換性が図られないことが良くあるため、より新しいバージョンのDockerはサポートされません。Docker インテグレーションは動作するかもしれませんが、保証の範囲外です。

  • 現状は、ジョブを container の中で実行されるように指定する必要がありますが、Docker イメージの中で container が作成されると同時にアプリケーションが自動的に実行されるように指定されている場合は、指定されたジョブによって上書きされます。

  • Docker デーモンは、Docker イメージを要求する際に空のメッセージを返す場合がありますが、ジョブ実行デーモンは、このレスポンスと利用できるイメージが無い場合の Docker インストールの有効なレスポンスとを見分けることができません。そのような空のメッセージを受け取った時に開始するべきジョブがある場合には、そのジョブは失敗します。それは、イメージが削除され、ジョブがスタートできないと判断するためです。

  • container で実行されるジョブのチェックポインティングは、サポートされません。

  • container では、ビルトインされた対話的なジョブのみがサポートされます。

  • ジョブ投入時の -xd オプション は実験的に加えられました。高度な利用用途では、問題が発生する可能性があります。例えば、ネットワーク設定を複数指定する場合や、データを重複して指定する場合などがそれに該当します。尚、-xdv オプションは、推奨されず、-xd -v オプションにリプレイスされます。

(2) Host resolving and host_aliases file

  • load sensor によってホストネームがレポートされる場合は、実行ホスト側で名前が解決されることになります。host_aliases ファイルの設定は、外部のload sensor を経由した負荷情報に対しても利用されます。

  • qmaster の起動時には、データベース内のスプールオブジェクトのホスト名の解決を確認します。得られたホスト名が構成リスト(admin host list, execd list , submit host list )で参照されているホストと異なる場合は、すべてのスプールされたデータオブジェクトは、新しい結果のホスト名と一致するように調整されます。

  • -l h= オプションによるホストリソースの要求は、正規表現によるプレーンなホストネームを新たにサポートします。これは、エイリアスされたホストネームを使用することも含みます。

  • qmaster デーモンの実行中に host_aliases ファイルに新たなホストが追加されるとそれが動的に反映するようになりました。既存のホストネームが変更された場合は、qmaster をリスタートする必要があります。既存のホストネームを変更し、qmaster デーモンをリスタートした場合は、qmaster デーモンは、messagaes ファイルに、「Grid Engine Release Notes v 8.4.1 7 3 Fixes and Enhancements」の情報をログに残します。UGE の動作中に既存のアクティブなホストネームを反映させるためには、対応するホストを UGE から削除する必要があります。qmaster デーモンや execd デーモンを実行しているインターフェースに影響するホストネームの変更は、常に必ずそのデーモンの再起動が必要です(デーモンの動作に変更はありません)。

  • クライアントツールである qping や、gethostbyname は、デーモンで解釈されたホストネームを表示するために新たに -all_rr オプションが追加されました。このツールは、動作中の qmaster が、host_aliasesファイルの変更を引き継ぐまで待つために使用されます。

  • 個々のqmasterパラメータを内部のホスト名キャッシュ(qmaster_paramsを通して)に設定することができます。 キャッシュされたエントリの数は、qpingまたはPROF_COMMLIB_TIME を通して得ることができます。

(3) Scheduler specific changes

  • スケジューラーの "params" パラメーターで、プロファイリング(PROFILE=true) を有効にできるようになりました。“WARN_DISPATCHING_TIME" の値と組み合わせて使うことで、ジョブがスケジュールされる最大時間と最短時間についての追加情報を表示することができます。

  • スケジューラープロファイリングは、スレッドベースの user time 及び system time をサポートするアーキテクチャとなりました (linux kernel >= 2.6.26 and solaris operating systems)。このため、スケジューラースレッドに対する user time 及び system time が正確となります。別のアーキテクチャによって、user time 及び system time は、プロセス全体で計測されています。つまり、wallclock time のみが、スケジューラースレッドのオーバーヘッドを反映していることを意味します。この場合、system time と user time は、特定のスケジューラースレッドだけではなく、プロセスの全スレッドの使用時間を示します。

  • スケジューラ・スレッドのプロファイリング概要はRQS(Resource Quota Sets )の計算に使用する時間に関する情報が含まれます。いくつかのRQSルールがスケジューリング時間に予想外に高い影響力を持っている場合、このルールのためのプロファイリングデータはまたプロファイル出力に発生します。

  • 定義されたRQSは、スケジューラがジョブをディスパッチしている間明確なRQS処理順序を定義するために自分の名前にアルファベット順にソートされます。処理順序は、スケジューリング時間に影響を与える可能性があり、最適化することができるようになりました。最も制限の強いルールは、最初のルールでなければなりません。

  • qsub/qalter -w コマンドが提供するスケジュール情報メッセージは、スケジューラによって使用されているフィルタルールがアクティブになりますので、現在はさまざまなメッセージを提供するかもしれませんが、qsub/qalter -w コマンドを経由してスケジュールがシミュレーションされる結果、スケジューリング情報は今より良い結果が得られるはずです。

© 2006-2019 HPC Technologies Co., Ltd. All rights reserved.