Univa Grid Engine (UGE) Release Notes

Univa Grid Engine v8.5.3 Release Notes  (3 Fixes and Enhancements を抽出)

原文はこちらのURLから取得してください。http://www.univa.com/resources/releases.php

3.1 Summary

3.1.1 8.5.1: Changed limit calculation
 

Univa Grid Engine 8.5.1 ではジョブの limit の計算が改善され、Univa Grid Engine の以前のバージョンと比較して変更されました。最も重要な変更点は次のとおりです。

  • 指定された消費可能なリソースの型(NO、YES、JOB、HOST)は、 tight integrated parallel jobs の結果の制限に影響しません。

  • Univa Grid Engine の以前のバージョンの計算された limit 値は、高すぎます(peおよび消費可能なリソースの型の設定に依存)。

  • cgroups h_vmem による制限についても観察されます。


8.5.1より前の Univa Grid Engine のバージョンでは、 "h_vmem" のような制限値に対して高すぎる値が設定されていました。その結果、ジョブは制限を超過したにもかかわらずkillされませんでした。8.5.1では、limit 値の計算が修正されるようになりました。limit 監視の詳細な概要とその動作は、sge_diagnostics(1)のマニュアルページ(JOB LIMITS)に説明されています。注意:以前のバージョンから8.5.1に更新する場合は、ジョブの limit 要求を確認してください。要求されたlimit 値を変更する必要があるかもしれません。limit 値を低く設定したり、以前の limit 値を調整したりすると、このバージョンをインストールした後、正常に動作していたジョブが失敗することがあります。

3.1.2 8.5.1: Improved rescheduling behaviour

execd_params パラメータ RESCHEDULE_ON_MISSING_EPILOG が導入されました。デフォルト値は true で、古い動作が発生します。 false に設定すると、設定されたエピローグスクリプトが見つからない場合、ジョブは再スケジュールされず、キューはエラー状態に設定されません。代わりに、Univa Grid Engine は、エピローグスクリプトが設定されていないかのように動作します。このパラメーターは、並列環境の stop_proc_args スクリプト(pe_stopスクリプトとも呼ばれます)にも適用されます。

3.1.3 8.5.1: Possibility to reduce qhost data request sizes at sge_qmaster
 

環境変数 SGE_GDI_REQUEST_REDUCE_LEVEL を設定することにより、sge_qmaster から qhost クライアントに転送されるデータの量を減らすことができます。詳細な説明は、qhost(1)のマニュアルページ(環境変数)を参照してください。

3.1.4 8.5.1: New environment variables in the job environment
 

Univa Grid Engineは、ジョブ、prolog、pe_start、pe_stop、および epilog スクリプトの環境内に2つの新しい環境変数を設定します。

 

SGE_RERUN_REQUESTED = <0 | 1 | 2>

値「0」は、ジョブのサブミット・コマンド行に「-r <y | n>」要求がなかったことを意味します. 値「1」は「-r y」が要求されたことを意味し、「2」は「-r n」が要求されたことを意味します。

SGE_RERUN_JOB=<0|1> 

値「1」は、ジョブがエラー時に再スケジュールされることを意味します。この値は SGE_RERUN_REQUESTED 値とジョブが実行されるキューの rerun 設定値から決定されます。

さらに、Univa Grid Engine は以下の新しい環境変数を pe_stop および epilog スクリプトの環境に設定します。

SGE_JOB_EXIT_STATUS

この変数は終了ステータスに設定されます。これは、exit_status フィールドへのアカウンティング情報に書き込まれるものと同じ値です。

3.1.5 8.5.1: New example script for jsv and core-binding

JSVを使用してコア・バインディングを示す新しいサンプル・スクリプトは、

「$ SGE_ROOT/util/resources/jsv/ core_binding_jsv.sh」にあります。

3.1.6 8.5.1: sgepasswd renewal 


アップグレードおよびインストールスクリプトは、CSP / sgepasswd キーストアがバックアップされ、クローンアップグレードで正しく復元されるように更新されました。現在 CSP または sgepasswd を使用している場合、あなたの設定を以下のものでユーザー root として保存する必要があります。

#$SGE_ROOT/util/upgrade_modules/save_sge_config.sh <backupdir>

次に、既存のインストールの元のスクリプトを新しい Univa Grid Engine 8.5.1 に置き換えて、既存の sgeCA インフラストラクチャを確実にバックアップします。これで、inst_sge -upd -csp でアップグレードすると、バックアップされたキーストアが復元されます。新しい sgeCA インフラストラクチャを作成して新しいキーストアを作成する場合は、root として次のコマンドを使用して、既存の sgepasswd ファイルを手動で再暗号化する必要があります。


#$SGE_ROOT/bin/<sge_arch>/sgepasswd -n \

  /var/sgeCA/<old port number>/<old sge_cell> .backup/private/key.pem

元のsgepasswdファイルは、以下のように保存されます。

#ls $SGE_ROOT/$SGE_CELL/common/sgepasswd.oldcert_backup

再暗号化されたファイルは以下で利用できます。

#ls $SGE_ROOT/$SGE_CELL/common/sgepasswd

元のファイルを保存せずにこのプロセスを繰り返さないでください。そうしないと、元の情報が失われ、sgepasswd ファイルを最初から再作成する必要があります。バージョン 8.5.0 では暗号化アルゴリズムが変更されていることに注意してください。 8.5.0 より前の古いインストールからアップグレードする場合は、セクション「5.2 Changes in Windows execution host sgepasswd file」の手順を実行する必要があります。

3.1.7 Performance Improvements and Memory Requirements

Univa Grid Engine 8.5.3 では、Univa Grid Engine のさまざまなコンポーネントとライブラリのパフォーマンスを改善するためにかなりの時間を費やしました。 Univa Grid Engine 8.4.4 の Univa Grid Engine と比較して、以下のクラスタのメトリックが改善されました。

  • 送信速度(ジョブの種類と要求された機能に応じて5〜15%増加)

  • スケジュール時間(使用されたポリシーに応じて5〜30%削減)

  • 対話型ジョブの場合、ディスパッチされたジョブをsge_execd espにすばやく配信

  • リクエストのハンドリングに対して要求されるメモリの量を(5〜10%削減)。特に qstat, qhost 等の read-only の要求については、5〜30%削減)

  • 実行ホストが送信する要求の処理と応答時間(特定の要求はqmaster内で並列処理されるようになりました)

  • qstat / qhost のようなクライアント要求の処理(同じメモリー要件で同じ時間内に処理できる要求が約30%増加する)

  • ジョブのターンアラウンド時間

これにより、クラスタ全体のスループットが向上し、Univa Grid Engine クラスタとのやりとりが向上します。尚、クラスタのスピードアップは、クラスタ設定の詳細と、有効または無効になっている Univa Grid Engine の機能によって異なります。

3.1.8 Standing Reservations
 

Univa Grid Engine 8.5.3 では、アドバンスリザベーション機能がスタンディング予約を可能にするように拡張されました。スタンディング・リザベーションは、定期的な事前予約です。個々のアドバンスリザベーションの開始時刻と終了時刻はカレンダーで指定し、追加のコマンドラインオプションでは一度に予約できる数と予約が許可されない場合の動作を指定できます。リソースリクエストなどの事前予約で利用可能なすべてのオプションは、スタンディング予約でも利用できます。

詳しくは、ユーザーガイドのリザベーションの項目を参照ください。

3.1.9 Policy Scheme: Consider Slots Instead of Jobs

Univa Grid Engine 8.5.3 は、共有ツリーによって定義された共有ゴールに向けてユーザーとプロジェクトの貢献度を計算する場合に、実行中のジョブと保留中のジョブで使用されるスロットを考慮する設定ができるようになりました。つまり、4つのスロットを使用する並列ジョブは、4つのシリアルジョブに対するリソース使用量の点で同等と見なされます。以前のシェアツリーアルゴリズムではスロットの使用は考慮されていませんでした。つまり、並列ジョブとシリアルジョブが実行中または保留中で混在している場合には、保留中のジョブに付与されたチケットの数が正しいラインタイムの共有割合にならず、共有ツリーの目標は達成されませんでした。例えば、2つのプロジェクト "a" と "b" が同じシェアの共有ツリーの同じレベルに設定されている場合、スケジューラはプロジェクトの使用率が均等になるようにジョブをスケジューリングする必要があります。しかし、プロジェクト "a" がほとんど並列ジョブを持つ場合、以前の共有ツリーアルゴリズムはすべてのジョブを等しく扱うので、より多くの使用を得る傾向があります。実際、古いアルゴリズムでは、プロジェクト "a" の保留中の 4 スロットジョブの優先順位と、使用しない共有ツリーの保留中の 1 スロットジョブ(プロジェクト"b")を見ると、保留中のジョブはインタリーブされました(abababab ...)。新しいアルゴリズムでは、スロット使用率に基づいて保留中のジョブが順序付けされていることがわかります(a b b b b b b b b ...)。これにより、適切なランタイム共有率が得られる可能性が高くなります。 urgency_slots PE属性は、スロット範囲を持つ保留中のジョブによって使用される想定スロット数を決定するために使用されます。詳細については、sge_pe(5)のマニュアルページのurgency_slotsを参照してください。 sched_conf(5)のparams属性で、Having_BASED_ON_SLOTS = false(デフォルト)を設定しておくことができます。新しい動作(スロットに基づく共有)は、sched_conf(5)params属性でSHARE_BASED_ON_SLOTS = true を設定することで設定できます。詳細は、sched_conf(5)のマニュアルページを参照してください。

$ qconf -msconf

  ...

  params SHARE_BASED_ON_SLOTS=true

  ...
 

Univa Grid Engineのバージョン8.6.0から、SHARE_BASED_ON_SLOTSのデフォルトはfalseからtrueに変更されます。

3.1.10 RSMAP Enhancements
 

Univa Grid Engine 8.5.3では、RESTRING(詳細は complex(5)のマニュアルページを参照)で使用される構文を使用して、コマンドラインからリソースマップコンプレックス(RSMAP)の特定の ID を要求することができます。次の例では、complex "GPU" の 4つの Id ( "gpu1" または "gpu2" という名前の 3つの Id、および "gpu3" という名前の 1つの Id ) を要求するジョブを送信します。

qsub -l GPU=3(gpu1|gpu2)&1(gpu3) $SGE_ROOT/examples/jobs/sleeper.sh 3600
 

ホストの設定と使用可能な ID によりますが、このジョブに割り当てられる ID の組み合わせの可能性としては、gpu1 gpu1 gpu2 gpu3 となる場合があります。異なる名前の空き ID が十分にある場合でも、スケジューラが要求された名前で十分な空き ID を見つけられない場合、ジョブをスケジュールすることはできません。 Univa Grid Engine 8.5.3で導入された構文拡張なしで RSMAP complex を使用することは可能です。スケジューラは以前のバージョンと同様に動作し、空き ID を使用します。非常に複雑なリクエストはスケジューラを遅くするかもしれないことに注意してください。 RSMAP の設定を簡単にするために、ショートカットが追加されました。

The syntax is:
 

 complex_values complex_name=amount(complex_id:amount)
 

次の例では、 "gpu1" という名前の5つの利用可能なIDと "gpu2" という名前の5つの ID を持つ "GPU" という名前の複合体を定義しています。

qconf -me exechost1

  ...

  complex_values GPU=10(gpu1:5 gpu2:5)

  ...

3.1.11 Improved Scheduler Profiling
 

Univa Grid Engine の以前のバージョンでは、スケジューラプロフィリングはスケジューリングメインループを完全にカバーしませんでした。これは、誤ったデータや不足しているデータにつながります。 Univa Grid Engine には、メインループをカバーする追加の診断機能があります。スケジューラープロファイルの詳細については、sge_diagnostics(1)のマニュアルページを参照してください。

3.1.12 Improved Logging


sge_diagnostics(1)のマニュアルページは、使用可能なロギングと診断オプションの概要を説明するために導入されました。最も重要な変更と新しいオプションは次のとおりです。

  • worker と reader の要求キュー( "MONITOR_REQUEST_QUEUES"、manページ "sge_conf(5)"を参照)の要求タイプに関する統計情報を表示する

  • 閾値を超えるスプーリングのロギング(「LOG_SPOOLING_TIME」、manページ「sge_conf(5)」を参照)

  • /tmp/execd_messagesにロギングしていない最初の起動時の通信エラー。

  • プロファイリングとスタートアップ動作のための通信に関する拡張  ("PROF_COMMLIB_TIME"、manページ "sge_conf(5)"を参照)

  • ジョブ確認時間が閾値を超えていることをロギング(「LOG_JOB_VERIFICATION_TIME」、manページ「sge_conf(5)」を参照)。

  • 閾値を超えたリクエスト処理のロギング(「LOG_REQUEST_PROCESSING_TIME」、manページ「sge_conf(5)」を参照)

3.1.13 Encryption in CSP mode / sgepasswd

暗号化アルゴリズムがRC4からAES256_CBCに変更されました。これは、CSP 暗号化と Windows execd sgepasswd ファイルの暗号化を行います。 CSP モードに必要な追加のアップグレード手順はありません。Windows の手順については、以下のセクションで説明します。(5.2 Changes in Windows execution host sgepasswd fil)

3.1.14 Online usage of running Windows jobs
 

省略

3.1.15 Docker Related Enhancements
 

Univa Grid Engine 8.5.3 では、サブミットコマンドライン、sge_requestファイル、ジョブスクリプト、ジョブクラス、およびジョブサブミットの検証で、 "-xd"オプションのサブオプションで可変プレースホルダが許可されています。これらの可変プレースホルダは、スケジューラがジョブのタスクに対して選択する特定のRSMAPコンプレックスの対応する要素によって解決されます。

 

これらのプレースホルダの形式は次のとおりです。

  placeholder := '${' complex_name '(' index ')' '}' .
 

complex_name は対応する RSMAP コンプレックスの名前、index はこのジョブの RSMAP からスケジューラが選択する要素のインデックスで、0から始まります。

 

例:リソースマップによってホスト上でこれらの値が定義されている場合:gpu_map = 4(0 1 2 3)

このqsubコマンドラインが使用されます:

# qsub -l docker,docker_images="*some_image*",gpu_map=2 -xd "--device=/dev/gpu${gpu_map(0)}:/dev/gpu0, --device=/dev/gpu${gpu_map(1)}:/dev/gpu1" ...
 

スケジューラがリソースマップから要素 "1"と "3"を選択すると、コマンドラインは次のように解決されます。

# qsub -l docker,docker_images"*some_image*",gpu_map=2 -xd "--device=/dev/gpu1:/dev/gpu0, --device=/dev/gpu3:/dev/gpu1"...
 

つまり、物理GPU「gpu1」と「gpu3」はコンテナ内の仮想GPU「gpu0」と「gpu1」にマッピングされ、同時にすべての Univa Grid Engine ジョブの中で現在のジョブ専用に予約されています。

3.1.16 Host Aliasing and Resolving
 

Univa Grid Engine は、Univa Grid Engine の実行中に host_aliases ファイルへの変更をサポートするようになりました。 DNS や NISのような定期的な名前付けサービスが更新され、ホスト名が変更される可能性があります。さらに、管理者は host_aliases ファイルを更新する可能性があります。これらの状況の両方が、Univa Grid Engine のホスト名解決を変更します。 Univa Grid Engine は次のような状況に対応するように拡張されました。

Adding host_aliases while Univa Grid Engine is running:

Univa Grid Engine の設定で結果の名前とマップされたホスト名のいずれも参照されない場合、Univa Grid Engine の実行中にhost_aliases ファイルに新しいエントリを追加することはサポートされています。変更または追加された Univa Grid Engine 構成オブジェクトで参照されるホスト名は無視され、メッセージは qmaster メッセージファイルに記録されます。

Update of internal name resolution database on daemon startup: 

qmasterデーモンの起動時に、構成内のホスト名の変更が検出され、名前解決データベースがこの変更を反映するように調整されます。名前解決の変更が exec_host に影響を及ぼす場合には、管理者が exec_host を再始動する必要があります。

Additional Improvements: 

ホストネームがシステムに認識される個所(例えば、正規表現を使用されたプレーンなホストネームやロードセンサーによって報告されたホストネーム)を改善しました。スケジュールできなかったジョブやその他の問題は発生しなくなりました。最終的な Univa Grid Engine のバージョンでは、更新された host_aliases のマニュアルページと更新された管理ガイド(GE-6013)が付属します。

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


Univa Grid Engine 8.5.3 は、インテル®Xeon®Phi™x200(Knights Landing)プロセッサー用の integration を提供します。事前にコンパイルされた負荷センサーは、現在のクラスターと、x200 マシンの現在のメモリー・モードを自動的に検出します。さらに、現在の MCDRAM 分布が報告されます。詳細については、管理者ガイドの「Configure and Install Intel Xeon Phi x200 (Knights Landing) Processors support」を参照してください。

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