Platform Clusterware(TM) 管理者 Version 5.1 June 2003 お問い合わせ : doc-japan@platform.com 著作権表示 Platform Clusterware(TM) Version 5.1 © 2002-2003, Platform Computing Corporation. All rights reserved. この製品では、ワークロードの管理に Platform LSF® 5.1 ソフトウェアを使用します。 (© 1994-2003, Platform Computing Corporation. All rights reserved). ご意見をお聞かせくださ い 本書の内容、構成、情報の有効性についてご意見をお聞かせください。本書を改良するときの参考に させていただきます。間違いを発見した場合、または改良のヒントをお持ちの場合は、 doc-japan@platform.com 宛にコメントをお寄せください。 ただし、LSF のドキュメンテーションについてのコメント以外は、ご容赦ください。製品のサポート については、support-japan@platform.com へご連絡ください。 本書に記載されている情報については慎重に確認していますが、Platform Computing Corporation (Platform) は誤謬や欠落がないという保証をいたしかねます。Platform は、本書中の情報に対して訂 正、更新、改訂または変更を行う権利を保有します。 プラットフォーム コンピューティング コーポレーションの書面による別途の規定がない限り、本書に 記述されたプログラムは現状のままとして提供され、明示または黙示を問わず、いかなる保証を行う ものではありません。ただしこの保証には、商品性と特定目的への適合性についての黙示の保証を含 みますが、それに限定されません。いかなる場合であっても、プラットフォーム コンピューティング コーポレーションは、本プログラムの使用または本プログラムの使用不能を原因とする逸失利益また は逸失節約を含む特別損害、間接的損害、付随的損害または派生的損害に対して責任を負いません。 商標 ® LSF は、Platform Computing Corporation の米国およびその他の国における登録商標です。 (TM) CLUSTERWARE、THE BOTTOM LINE IN DISTRIBUTED COMPUTING、PLATFORM COMPUTING、PLATFORM、および LSF ロゴは、Platform Computing Corporation の米国およびその 他の国における商標です。 UNIX は、The Open Group の米国およびその他の国における登録商標です。 その他、記載されているすべての会社名、製品名、ロゴおよび商標はそれぞれ各社の商標、または登 録商標です。 最終更新日 最新バージョン May 13 2003 www.platform.com/services/support/docs_home.asp 目次 はじめに . . . . . . . 本書について . . . . . . . . . . . . . . . Platform 製品に関する情報 テクニカル サポート . . . 第 1 章 Platform Clusterware とは クラスタの概念 . . . . . . . . ジョブのライフ サイクル 第 2 章 システムの動作 . ジョブの投入 . . . . . . . . . . . . . . . . . . . . ジョブの実行環境 . . . . . . . . . . . . . . . . . . 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 . . . . . . . . . . . . . . . . . . ジョブのスケジューリングとディスパッチ ホストの選択 . . . . . . . . . . . . . . . . . . . . . . . . . 29 . . . . . . . . . . . . . . . . . . . . . . . . 30 . . . . . . . . . . . . . . . . . . . . . . . . 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 第 I 部 : クラスタの管理 第 3 章 クラスタの操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 クラスタ情報の参照 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 クラスタ管理者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 デーモンの制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 mbatchd の制御 クラスタの再構成 第 4 章 ホストの操作 . . ホストの状態 . . . . . . ホスト情報の参照 ホストの制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 . . . . . . . . . . . . . . . . . 64 ホストの動的な追加と削除 lsf.shared にホスト タイプとホスト モデルを追加する サービス ポートの登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 複数のアドレスを備えたホスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 CPU 係数の調整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 ホスト名を指定する . . . . . . . . . . Platform Clusterware 管理者 3 目次 第 5 章 キューの操作 . . キューの状態 . . . . . . キュー情報の参照 キューの制御 . . . . . . . ジョブの状態 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 キューを追加 / 削除する 第 6 章 ジョブの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 キュー内のジョブの順番を入れ替える . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 ジョブを他のキューに切り替える . . . ジョブ情報の参照 ジョブを強制的に実行する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 ジョブを中断 / 再開する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 ジョブを強制終了する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 . ジョブにシグナルを送出する 第 II 部 : リソースの管理 第 7 章 リソースの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 LSF のリソースとは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 リソースの分類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 . . . LSF でのリソースの使用 負荷インデックス 静的リソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 ハードウェア再構成の自動検出 第 8 章 リソースの追加 . . . . 構成リソースとは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 . . . . . . . . . . . . . . . . . 116 lsf.cluster.cluster_name ファイルの ResourceMap セクションを設定する . . . . . . . 117 外部負荷インデックスと ELIM . . . . . . . . . . クラスタに新しいリソースを追加する lsf.shared ファイルの Resource セクションを設定する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 組込み負荷インデックスを修正する . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 . . 第 I I I 部 : スケジューリング ポリシー 第 9 章 時間の構文と構成 時刻の指定 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 時間帯の指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Platform Clusterware 管理者 目次 第 10 章 リソース要件の指定 . リソース要件とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 キュー レベルのリソース要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 ジョブ レベルのリソース要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 . . . . . リソース要件文字列とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 select 文字列 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 order 文字列 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 第 IV 部 : ジョブのスケジューリングとディスパッチ 第 11 章 ディスパッチ時間帯と実行時間帯 . ディスパッチ時間帯と実行時間帯 実行時間帯 . . . . . . . . . . . . . . . . . . . . . 145 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 ディスパッチ時間帯 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 . 第 12 章 ジョブの依存性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 . ジョブ依存スケジューリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 依存条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 . . 第 13 章 ジョブの優先順位 . . . . . . . . . . . . . . . . . . . ジョブの優先順位の手動割り当て . . . . . 第 14 章 ジョブのキューへの再登録と再実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 . . . . 156 159 . ジョブのキューへの再登録とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 ジョブのキューへの自動再登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 ジョブのキュー末尾への再登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 ジョブのキューへの除外再登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 ジョブのキューへのユーザ指定再登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 ジョブの自動再実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 . . . . . . . . . . 第 15 章 ジョブのチェックポイント、再起動、移行 . . . . . . . . . . . . . . . . 167 . ジョブのチェックポイント機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 チェックポイント機能の手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 . アプリケーション レベルのチェックポイント用カスタム echkpnt および erestart の作成 170 チェックポイントを実行する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 ジョブをチェックポイント機能に対応させる . . . . . . . . . . . . . . . . . . . . . . . 175 ジョブのチェックポイントを手動で実行する . . . . . . . . . . . . . . . . . . . . . . . 176 ジョブの定期的チェックポイント機能を有効にする . . . . . . . . . . . . . . . . . . . 177 ジョブのチェックポイントを自動的に実行する . . . . . . . . . . . . . . . . . . . 178 . チェックポイント ディレクトリ . . . . Platform Clusterware 管理者 5 目次 ジョブの移行 第 16 章 ジョブ配列 . . . . . . . . . . . ジョブ配列の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 181 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 入力ファイルと出力ファイルの処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 標準入力と標準出力の転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 コマンド行での引数の受渡し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 ジョブ配列の依存 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 ジョブ配列のモニタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 ジョブ配列の制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 ジョブ配列のジョブ スロット制限 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 . ジョブ配列のリキュー 第 V 部 : ジョブの実行の制御 第 17 章 実行時のリソース使用制限 リソース使用制限とは . . . . . . . . . . . . . . . . . . . . . . . . . 197 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 リソース使用制限を指定する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 使用可能なリソース使用制限の構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 CPU 時間と実行時間の正規化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 第 18 章 負荷しきい値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 第 19 章 実行前コマンドと実行後コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 . . . . . . . . . . . . ジョブの自動中断 . . . . . . . . 中断条件 . . . 217 . 実行前および実行後コマンドについて . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 実行前および実行後コマンドの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 第 20 章 ジョブ スタータ . . . . . . ジョブ スタータの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 キュー レベルのジョブ スタータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 . . . . . . . . . . . . . . . . . . . . . . . . . . 228 . . . . ジョブ スタータによる実行環境の制御 第 21 章 外部ジョブの投入と実行と制御 外部実行可能プログラム esub の使用 . . . . . . . . . . . . . . . . . . . . . . . 229 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 eexec の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 第 22 章 ジョブ制御の設定 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 . デフォルトのジョブ制御アクション . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 ジョブ制御アクションの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Platform Clusterware 管理者 . . . . 目次 第 V I 部 : 対話型のジョブ 第 23 章 bsub を使用した対話型ジョブ . . . . . . . . . . . . . . . . . . . . . . . . 247 . 対話型ジョブについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 対話型ジョブの投入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 . . . . . . . . . . . . . . . . . . 252 . . . . . . . . . . . . . . . . . . 256 . 対話型バッチ ジョブのパフォーマンス チューニング ジョブ スクリプトの作成 . . . . . . . . . 第 24 章 対話型タスクとリモート タスクの実行 リモート タスクの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . 259 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 対話型セッションの負荷分散 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 対話型タスク . . . . . . X アプリケーションの負荷分散 第 V I I 部 : 並列ジョブの実行 第 25 章 並列ジョブの実行 . . . . . . . LSF による並列ジョブの実行 . . . . . . . . . . . . . . . . . . . . . . . . 271 . . . . . . . . . . . . . . . . . . . . . . . . . 272 並列ジョブを投入するための環境変数の準備 . . . . . . . . . . . . . . . . . . . . . . . 273 並列ジョブの投入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 lstools を使用した並列タスクの起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 並列ジョブのジョブ スロット制限 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 . . . . . . . . . . 第 VIII 部 : クラスタの監視 第 26 章 クラスタのチューニング LIM のチューニング . . . LIM パラメータの調整 負荷しきい値 第 27 章 認証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 . ユーザの認証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 ホストの認証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 デーモンの認証 第 28 章 ジョブ電子メール、ジョブ ファイル スプール ジョブ開始時のメール通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ジョブ入力ファイル、ジョブ出力ファイル、ジョブ コマンド ファイルのスプール 第 29 章 エラーとイベント ログ . . . . . . . . . . . . . . . . . . . 302 . . . . . . . . . . . . . . . . . . . . . . . 303 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 . . . 297 . . . . . . . . . . . 294 LSF システム ディレクトリとログ ファイル . . . . . . . . エラー ログの管理 . 293 . . Platform Clusterware 管理者 7 目次 システム イベント ログ . . . . . . . . . . . . . . . 第 30 章 トラブルシューティングとエラー メッセージ 共有ファイル アクセス 索引 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 305 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 LSF の一般的な問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 エラー メッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 . Platform Clusterware 管理者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 はじめに 内容 ◆ ◆ ◆ 10 ページの「本書について」 12 ページの「Platform 製品に関する情報」 13 ページの「テクニカル サポート」 Platform Clusterware 管理者 9 本書について 本書について 目的 本書では、Platform Cluster w ar e(TM) ソフトウェア("Clusterw are")の管理と構成 について説明しています。ここでは、次の項目について説明しています。 ◆ ◆ ◆ ◆ ◆ ◆ クラスタの構成と管理 キュー、ホスト、およびユーザの構成と管理 ジョブの実行とその制御 リソースの理解とその管理 スケジューリング ポリシーの理解とその構成 ジョブのスケジューリングとディスパッチの管理 対象読者 本書は、Clusterw are でのビジネス ポリシーの実現を目指す Platform Clusterw are ク ラスタ管理者を対象としています。Clusterw are の動作についてより詳細な知識が必 要なユーザの方も本書をお読みください。自分のジョブの実行とそのモニタだけを 行うユーザの方は、 『Ru n n in g Jo b s w ith Pla tfo rm Clu ste rw a re 』を参照してください。 前提知識 本書は、読者に次の知識があることを前提としています。 ◆ ◆ ユーザ アカウントの作成、NFS(ネットワーク ファイル システム)パーティ ションの共有とマウント、システムのバックアップといったシステム管理作業 の知識 LSF の基本的な概念および LSF の基本操作に関する十分な知識 表記規則 書体 意味 例 Courier(クーリ エ) Bold Courier 画面上の出力、コマンド名、ファイル名、ディレクトリ名 lsid コマンド そのまま入力する必要のある文字列 Ita lic s ◆ cd /bin と入力し ます qu e u e _n a m e で指定 したキュー ◆ Bold Sans Serif 10 Platform Clusterware 管理者 ◆ ブック タイトル、新出の語句や用語、強調語句 実際の名前や値に置き換えて入力するコマンド行文字 列 操作する GUI エレメント名 OK をクリックする はじめに コマンド表記規則 表記 引用符 " または ' カンマ , 省略記号 … イタリック体 OR バー | 括弧 ( ) 角括弧 [ ] で囲んだ オプションまたは 変数 シェル プロンプト 意味 例 そのまま入力する そのまま入力する 直前の引数を複数回入力可能。省略記号 そのものは入力しない。 実際の値に置き換えて入力する必要のあ る引数 バーで区切られた項目のいずれか 1 つを 入力。複数入力は不可。バーそのものは 入力しない。 そのまま入力する "jo b _ID[in d e x_list]" -C tim e 0,tim e 1 jo b _ID ... 角括弧の中の引数は省略可能。角括弧そ のものは入力しない。 C シェル : % Bourne シェルおよび Korn シェル : $ ◆ ルート アカウント : # 特に指定しない限り、コマンド例では C シェル プロンプトを使用 ◆ jo b _ID [-h | -V] -X "e xc e ptio n _c o n d ([pa ra m s])::a c tio n ] ... lsid [-h] % cd /bin ◆ Platform Clusterware 管理者 11 Platform 製品に関する情報 Platform 製品に関する情報 World Wide Web および FTP サポートされている Platform LSF および Clusterw are の全リリースに関する最新情 報は、Platform の Web サイト ( www.platform.com) で入手できます。最新の README ファイル、リリース ノート、アップグレード情報、よくある質問とその 回答 (FAQ)、トラブルシューティング、およびその他の支援情報は、Online Support のエリアで参照してください。 Platform の FTP サイト ( ftp.platform.com) でも、サポートされている Platform LSF および Clusterw are の全リリースに関する最新の README ファイルとリリース ノートを提供しています。 分散グリッド コンピューティングに関する作業負荷管理と戦略の話題については、 www.platformusers.net の Platform ユーザ フォーラムに参加してみてくださ い。 Platform の Web サイトや FTP サイトにアクセスできない場合は、 support-japan@platform.com 宛に電子メールをお送りください。 Platform LSF マニュアル Platform のプロフェッショナル サービス トレーニング コースでは、Platform 製品 を効率よくインストール、設定、および管理するために必要な技術を身に付けるこ とができます。初級ユーザ、上級ユーザ、および管理者の皆様にプラットフォーム コンピューティング株式会社でこのコースを受講していただくことができます。 Platform トレーニングについては、 www.platform.co.jp/cgi/training.html を参照してください。 Platform のマニュアル すべての Platform 製品のマニュアルは、Platform の Web サイト (www.platform.com/lsf_docs)から、HTML と PDF のどちらのフォーマット でも入手できます。 12 Platform Clusterware 管理者 はじめに テクニカル サポート テクニカル サポートが必要な場合は、サポート契約をご締結いただいている LSF ベ ンダにご連絡ください。プラットフォーム コンピューティング社のテクニカル サ ポートに連絡をとるには、以下のいずれかの方法をご利用ください。 電子メール support-japan@platform.com World Wide Web www.platform.co.jp 電話 ◆ 03-5326-3105 郵送 〒 163-1030 東京都新宿区西新宿 3-7-1 新宿パークタワー N30F プラットフォーム コンピューティング株式会社 プロフェッショナル サービス担当宛 当社に連絡される際は、正式な会社名をお知らせください。 ご意見をお聞かせください 本書またはその他の Platform マニュアルに誤りがあった場合や、マニュアルに対す るご意見をお持ちの場合は、以下の方法でお知らせください。 電子メール doc-japan@platform.com 郵送 〒 163-1030 東京都新宿区西新宿 3-7-1 新宿パークタワー N30F プラットフォーム コンピューティング株式会社 プロダクトマネージメント担当宛 この際、必ず以下の点を明記してください。 ◆ ◆ ◆ 意見をお持ちのマニュアルの名前 使用している製品のバージョン マニュアルの形式(HTML または PDF) Platform Clusterware 管理者 13 テクニカル サポート 14 Platform Clusterware 管理者 第1章 Platform Clusterware とは 内容 ◆ ◆ 16 ページの「クラスタの概念」 27 ページの「ジョブのライフ サイクル」 Platform Clusterware 管理者 15 クラスタの概念 クラスタの概念 Commands sbatchd Commands Commands mbschd sbatchd Commands pim sbatchd res Master lim res Master Host Server Host lim Submission Host Server Host res lim Queues mbatchd Submission Host Client Host pim pim Execution Host Server Host Commands Commands sbatchd pim res lim Execution Host Server Host sbatchd pim res lim Execution Host Server Host クラスタ、ジョブ、キュー クラスタ LSF を実行しているコンピュータ(ホスト)の集まりで、計算能力を結合し、ワー クロードとリソースを共有して、1 つのユニットとして機能します。クラスタは、多 種多様なコンピューティング リソースを単一システムとして捕らえられるように します。 さまざまな方法でホストをグループ化し、クラスタを構成することができます。た とえば、個々のクラスタを次のようなホストで構成することができます。 ◆ ◆ ◆ 1 つの管理グループ内の全ホスト 1 つのファイル サーバまたはサブネットワーク上の全ホスト 似たような処理を実行するホスト コマンド ◆ ◆ ◆ ◆ lshosts -クラスタ内のホストの静的リソース情報を参照する bhosts -クラスタ内のサーバ ホストのリソースおよびジョブ情報を参照する lsid -クラスタ名を参照する lsclusters -クラスタの状態とサイズを参照する 設定 ◆ クラスタ内のホストを lsf.cluster.cluster_name ファイルに定義する クラスタの名前は一意でなければなりません。他のホストまたはキューと同じ名前を使用す ることはできません。 16 Platform Clusterware 管理者 第1章 Platform Clusterware とは ジョブ LSF システムで実行される作業の単位です。ジョブは、LSF に投入され、実行され るコマンドです。LSF では、指定されたポリシーに従って、ジョブをスケジューリ ング、制御、追跡できます。 複雑な問題、シミュレーションのシナリオ、大規模な計算、その他計算能力を必要 とするあらゆる作業がジョブになります。 コマンド ◆ ◆ bjobs -システム内のジョブを参照する bsub -ジョブの投入 ジョブ スロット ジョブ スロットは、LSF システム内の作業単位の収容場所です。ホストに多数の ジョブ スロットを用意しておき、それらのジョブ スロットがすべて埋まるまで、 キューからジョブをディスパッチできます。 コマンド ◆ ◆ ◆ bhosts -ホストおよびホスト グループのジョブ スロット制限を参照する bqueues -キューのジョブ スロット制限を参照する busers -ユーザのジョブ スロット制限を参照する ジョブの状態 LSF のジョブは次の状態になります。 ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ PEND-スケジュールされ、ディスパッチされるのをキューの中で待っている状 態 RUN-ホストにディスパッチされ、実行されている状態 DONE-終了値ゼロで正常に終了した状態 EXITED-実行終了(終了値 ≠ 0) PSUSP-PEND 状態の中断中 USUSP-ユーザによって実行を中断中 SSUSP-LSF システムによって実行を中断中 POST_DONE-後処理が正常終了 POST_ERR-後処理が異常終了 キュー クラスタ全体にわたるジョブのコンテナです。すべてのジョブは、スケジュールさ れ、ホストにディスパッチされるまで、キューで待機します。 キューは特定のホストと関連付けられていません。個々のキューをクラスタ内のす べてのサーバ ホストに対応付けることも、一部のサーバ ホストだけに対応付ける こともできます。 ジョブをキューに投入するときに、実行ホストを指定する必要はありません。LSF は、クラスタ内の使用可能な実行ホストのうち、そのジョブを実行するのに最適な 実行ホストにジョブをディスパッチします。 キューごとに別々のスケジューリング ポリシーと制御ポリシーを適用できます。 コマンド ◆ ◆ bqueues -使用可能なキューを参照する bsub -q -指定したキューにジョブを投入する Platform Clusterware 管理者 17 クラスタの概念 設定 ◆ キューを lsb.queues ファイルに定義する キューの名前は一意でなければなりません。クラスタ名やクラスタ内のホストと同じ名前を 使用することはできません。 先着順(FCFS)スケジューリング LSF のデフォルトのスケジューリング方式です。ジョブのディスパッチは、キュー 内に収容された順序に基づいて検討されます。 ホスト ホスト クラスタ内の単一のコンピュータです。 1 つのホストが複数のプロセッサを持つ場合もあります。マルチプロセッサ ホスト は、並列ジョブを実行する際に使用されます。マルチプロセッサ ホストでも、プロ セス キューが 1 つしかなければ、単一のマシンとして扱われます。これに対して、 プロセッサごとに専用のプロセス キューを備えているマルチプロセッサ ホスト は、個別のマシンの集まりとして扱われます。 コマンド ◆ ◆ ◆ lsload -ホストに対する負荷を参照する lshosts -CPU の数、ホスト モデル、ホスト タイプ、クライアントかサーバか の区別など、クラスタ内のホストに関する構成情報を参照する bhosts -クラスタ内のバッチ サーバ ホストを参照する ホストの名前は一意でなければなりません。クラスタ名やクラスタに定義されているキュー と同じ名前を使用することはできません。 投入ホスト クラスタへのジョブの投入元ホストです。 ジョブは、bsub コマンドを使用して投入されるか、LSF API を使用するアプリケー ションから投入されます。 クライアント ホストとサーバ ホストを投入ホストとして使用することができま す。 コマンド ◆ ◆ bsub -ジョブを投入する bjobs -投入されたジョブを参照する 実行ホスト ジョブが実行されるホストです。投入ホストと同じ場合もあります。実行ホストは すべてサーバ ホストです。 コマンド ◆ 18 Platform Clusterware 管理者 bjobs -ジョブが実行される場所を参照する 第1章 Platform Clusterware とは サーバ ホスト ジョブを投入および実行する機能を持つホストです。サーバ ホストは、sbatchd を実行して、サーバ要求を実行したりローカル ポリシーを適用します。 コマンド ◆ lshosts -サーバ ホスト(server=Yes)を参照する 設定 ◆ サーバ ホストは、lsf.cluster.cluster_name ファイルで、server の値 に 1 を設定することで定義する。 クライアント ホス クラスタへのジョブの投入だけを行うことができるホストです。クライアント ホ ト ストは LSF コマンドを実行し、投入ホストとしてのみ機能します。クライアント ホ ストでは、ジョブを実行したり、LSF デーモンを実行することはできません。 コマンド ◆ lshosts -クライアント ホスト(server=No)を参照する 設定 ◆ クライアント ホストは、lsf.cluster.cluster_name ファイルで、server の値に 0 を設定することで定義する。 マスタ ホスト マスタ LIM と mbatchd を実行しているホストです。LSF サーバ ホストは、クラス タ全体を統合する役割を果たします。クラスタごとに 1 つのマスタ ホストが存在 し、ジョブのスケジューリングとディスパッチをすべて受け持ちます。マスタ ホス トがダウンした場合、そのクラスタ内の別の LSF サーバがマスタ ホストになりま す。 マスタ ホストでは、すべての LSF デーモンが実行されます。マスタ ホストで実行 される LIM をマスタ LIM と呼びます。 コマンド ◆ lsid -マスタ ホスト名を参照する LSF デーモン mbatchd job requests and dispatch mbschd job scheduling sbatchd job execution res lim host information pim job process information mbatchd マスタ ホスト上で実行されているマスタ バッチ デーモン。sbatchd によって起動 されます。システム内のジョブの全体的な状態を管理します。 投入されたジョブと、情報問い合わせ要求を受け取ります。キュー内に収容されて いるジョブを管理します。mbschd の判断に従って、ジョブをホストにディスパッ チします。 設定 ◆ lsf.conf ファイルにポート番号を定義する。 Platform Clusterware 管理者 19 クラスタの概念 mbschd マスタ ホスト上で実行されているマスタ バッチ スケジューラ。mbatchd と連動し ます。mbatchd によって起動されます。 ジョブの要件とポリシーに基づいて、スケジュールを決定します。 sbatchd 各サーバ ホスト上で実行されているスレーブ バッチ デーモン。mbatchd からの ジョブ実行要求を受け取り、ジョブのローカル実行を管理します。ローカル ポリ シーを適用し、ホスト上のジョブの状態を管理する役割を果たします。 sbatchd は、すべてのジョブに対して子 sbatchd をフォークします。子 sbatchd は res のインスタンスを実行して、ジョブの実行環境を作成します。子 sbatchd は、ジョブが完了すると終了します。 コマンド ◆ ◆ ◆ badmin hstartup - sbatchd を起動する badmin hshutdown - sbatchd をシャットダウンする badmin hrestart - sbatchd を再起動する 設定 ◆ lsf.conf ファイルにポート番号を定義する。 res 各サーバ ホスト上で実行されるリモート実行サーバ。リモート実行の要求を受け 入れ、ジョブおよびタスクのリモート実行が透過的かつ安全に行われるようにしま す。 コマンド ◆ ◆ ◆ lsadmin resstartup -res を起動する lsadmin resshutdown -res をシャットダウンする lsadmin resrestart -res を再起動する 設定 ◆ lsf.conf ファイルにポート番号を定義する。 lim 各サーバ ホスト上で実行される負荷情報マネージャ。ホストの負荷情報と構成情 報を収集し、それをマスタ ホスト上で実行されているマスタ LIM に渡します。 lsload および lshosts によって表示される情報を報告します。 静的インデックスが報告されるのは、LIM が起動されたときと、CPU の数(ncpus) が変更されたときです。次の静的インデックスがあります。 CPU の数(ncpus) ディスクの数(ndisks) ◆ 使用可能な最大メモリ容量(maxmem) ◆ 使用可能な合計スワップ容量(maxsw p) ◆ 使用可能な合計 temp 容量(maxtmp) ◆ ホストの動的負荷インデックスは、定期的に収集されます。 ◆ ◆ ◆ ◆ ◆ ◆ ◆ 20 Platform Clusterware 管理者 ホスト状態(status) 15 秒、1 分、および 15 分の実行キュー長(r15s、r1m、および r15m) CPU 使用率(ut) ページング率(pg) ログイン セッション数(ls) 対話型アイドル時間(it) 第1章 Platform Clusterware とは ◆ ◆ ◆ ◆ 空きスワップ スペース(sw p) 空きメモリ容量(mem) 空き temp 容量(tmp) ディスク I/O 率(io) コマンド ◆ ◆ ◆ ◆ ◆ lsadmin limstartup -lim を起動する lsadmin limshutdown -lim をシャットダウンする lsadmin limrestart -lim を再起動する lsload -動的負荷値を参照する lshosts -静的負荷値を参照する 設定 ◆ lsf.conf ファイルにポート番号を定義する。 マスタ LIM マスタ ホストで実行される LIM。クラスタ内の各ホストで実行されている LIM から 負荷情報を受け取ります。 マスタ LIM は負荷情報を mbatchd に渡し、mbatchd はこの情報を mbschd に渡 します。mbschd は、この情報を利用してスケジュールを決定します。マスタ LIM が使用不能になった場合は、他のホストの LIM がその役割を自動的に引き継ぎま す。 コマンド ◆ ◆ ◆ ◆ ◆ lsadmin limstartup -lim を起動する lsadmin limshutdown -lim をシャットダウンする lsadmin limrestart -lim を再起動する lsload -動的負荷値を参照する lshosts -静的負荷値を参照する 設定 ◆ lsf.conf ファイルにポート番号を定義する。 ELIM ELIM(外部 LIM)は、サイトで独自に定義した実行可能プログラムで、カスタムな 動的負荷インデックスの収集と追跡を行います。ELIM はシェル スクリプトか、コ ンパイル済みバイナリ プログラムのいずれかの形式を取り、ユーザが定義した動的 リソースの値を返します。ELIM の実行可能プログラムは、名前を elim とし、 LSF_SERVERDIR に置く必要があります。 pim 各サーバ ホスト上で実行されるプロセス情報マネージャ。LIM は pim を定期的に チェックし、ダウンしていた場合は pim を再起動します。 ホスト上で実行されているジョブのプロセスに関して、そのジョブに使用されてい る CPU やメモリなどの情報を収集し、その情報を sbatchd に報告します。 コマンド ◆ bjobs -ジョブ情報を参照する Platform Clusterware 管理者 21 クラスタの概念 バッチ ジョブとタスク ジョブは、2 種類の方法で実行できます。1 つはバッチ システムからジョブを実行 する方法で、この場合、ジョブはキューに収容されます。もう 1 つはバッチ シス テムを使用せずに、対話形式でタスクを実行する方法です。この方法はテストのと きなどに使用されます。 ジョブ LSF システムで実行される作業の単位です。ジョブは、bsub コマンドを使用して LSF に投入され、実行されるコマンドです。LSF では、指定されたポリシーに従っ て、ジョブをスケジューリング、制御、追跡できます。 複雑な問題、シミュレーションのシナリオ、大規模な計算、その他計算能力を必要 とするあらゆる作業がジョブになります。 コマンド ◆ ◆ bjobs -システム内のジョブを参照する bsub -ジョブの投入 対話型バッチ ジョ このバッチ ジョブでは、LSF のスケジューリング ポリシーと耐障害性を活用しな ブ がら、アプリケーションと対話することもできます。すべての入力と出力は、ジョ ブ投入コマンドを入力するときに使用した端末を介して行われます。 対話型ジョブを投入すると、ジョブがスケジュールされるのを待つ間、メッセージ が表示されます。対話型ジョブが完了するか、終了するまでは、次のジョブを投入 することはできません。 bsub コマンドは、ジョブが完了するまでシェルからの出力の表示を中止し、デフォ ルトでは、ユーザへのメールの送信は行われません。Ctrl-C を使用すると、いつ でもジョブを終了することができます。 コマンド ◆ bsub -I -対話型ジョブを投入する 対話型タスク バッチ キューに投入されることも、LSF によってスケジュールされることもなく、 即座にディスパッチされるコマンドです。LSF はタスクに必要なリソースを突き止 め、候補のホストの中から必要なリソースを備えた、負荷の少ない最適なホストを 選択します。各コマンドは、単一のプロセスの場合もあれば、連携して動作するプ ロセス群の場合もあります。 タスクは、LSF のバッチ処理機能を使わずに実行されますが、リソース要件と負荷 に基づいて、タスクを実行するために最適なホストを選択する機能を利用していま す。 コマンド ◆ ◆ lsrun -対話型タスクを投入する lsgrun -ホスト グループに対話型タスクを投入する ローカル タスク リモート実行では意味をなさないアプリケーションまたはコマンドです。たとえ ば、UNIX の ls コマンドなどがあります。 コマンド ◆ 22 Platform Clusterware 管理者 lsltasks -タスクの表示と追加を行う 第1章 Platform Clusterware とは 設定 ◆ ◆ ◆ lsf.task -システム規模でタスクのリソース要件を構成する lsf.task.cluster -クラスタ規模でタスクのリソース要件を構成する .lsftasks -ユーザ固有のタスクを構成する リモート タスク クラスタ内の他のマシンで実行可能なアプリケーションまたはコマンドです。 コマンド ◆ lsrtasks -タスクの表示と追加を行う 設定 ◆ ◆ ◆ lsf.task -システム規模でタスクのリソース要件を構成する lsf.task.cluster -クラスタ規模でタスクのリソース要件を構成する .lsftasks -ユーザ固有のタスクを構成する ホスト タイプとホスト モデル LSF では、ホストの特性をホスト タイプとホスト モデルで表します。 次の例では HP ホストを使用しています。HPPA がホスト タイプです。HPN4000、 HPJ210、などがホスト モデルになります。 HPPA Host type Host models HPN4000 HPJ210 HPC200 HPC3000 ホスト タイプ オペレーティング システムのバージョンとホストの CPU アーキテクチャの組み合 わせで表します。 同じコンピュータ アーキテクチャに基づいて、同じオペレーティング システムを 実行しているコンピュータは、すべて同タイプであり、相互にバイナリ互換がある ということになります。 通常、ホスト タイプごとに個別の LSF バイナリ ファイル セットが必要です。 コマンド ◆ lsinfo -t - lsf.shared ファイルに定義されているすべてのホスト タイプ を参照する 設定 ◆ ◆ lsf.shared ファイルに定義する lsf.cluster.cluster_name ファイルでホストにマッピングする ホスト モデル ホスト タイプと CPU の処理速度(CPU 係数)の組み合わせで表します。 相対的な処理速度が同じであるホストには、すべて同じホスト モデルが割り当てら れます。 CPU 係数は、ジョブがディスパッチされるときの判断基準となります。 Platform Clusterware 管理者 23 クラスタの概念 コマンド ◆ ◆ lsinfo -m -現在実行されているモデルのリストを参照する lsinfo -M - lsf.shared ファイルに定義されているすべてのホスト モデル を参照する 設定 ◆ ◆ lsf.shared ファイルに定義する lsf.cluster.cluster_name ファイルでホストにマッピングする ユーザと管理者 LSF ユーザ LSF クラスタにジョブを投入する権限を持つユーザ アカウントです。 LSF 管理者 一般に、他の LSF ユーザに影響する操作は LSF 管理者だけが実行できます。それぞ れのクラスタには、プライマリ LSF 管理者が 1 名ずつ必要です。この管理者は、LSF のインストール時に指定します。クラスタのレベルやキューのレベルで、さらに別 の管理者を指定することもできます。 プライマリ LSF 管 インストール時に指定された最初のクラスタ管理者であり、 理者 lsf.cluster.cluster_name ファイルに最初に設定されている管理者です。プ ライマリ LSF 管理者アカウントは、構成ファイルとログ ファイルを所有します。プ ライマリ LSF 管理者は、クラスタ全体の操作、構成ファイルの変更、クラスタの再 構成、すべてのユーザ投入ジョブの制御を行う権限が与えられています。 クラスタ管理者 LSF のインストール時に指定されるか、またはインストール後に構成されます。ク ラスタ管理者は、クラスタ内のすべてのジョブとキューに対して管理作業を実施す ることができます。さらに、クラスタ全体の操作に関してプライマリ LSF 管理者と 同じ特権を持っています。ただし、LSF 構成ファイルの変更は許可されていないこ とがあります。 たとえば、クラスタ管理者は、任意のキューへのジョブの投入、別のユーザのジョ ブの終了、などを実行できます。 キュー管理者 特定のキューについての管理者特権だけを持つ LSF 管理者のユーザ アカウントで す。LSF キュー管理者は、該当するキューやその中のジョブの管理はできますが、 LSF の構成変更や LSF デーモンの操作などはできません。 リソース リソース使用量 LSF システムでは、組込みリソースおよび設定されたリソースを使用して、リソー (rusage) スの可用性と使用状況を追跡します。ジョブは、個々のホストの使用可能なリソー スに基づいてスケジュールされます。 LSF に投入したジョブが実行されると、そのジョブで消費されるリソースが監視さ れます。リソース制限機能、負荷しきい値機能は、この情報に基づいて実行されま す。 LSF では、次の情報を収集します。 ◆ ◆ 24 Platform Clusterware 管理者 ジョブの全プロセスの合計 CPU 消費時間 ジョブの現時点で実行されている全プロセスの合計実メモリ使用量(KB) 第1章 Platform Clusterware とは ◆ ◆ ◆ ジョブの現時点で実行されている全プロセスの合計仮想メモリ使用量(KB) ジョブの現時点でアクティブなプロセス グループの ID ジョブの現時点でアクティブなプロセス コマンド ◆ ◆ lsinfo -クラスタ内の使用可能なリソースを参照する bjobs -l -現時点でジョブが消費しているリソースを参照する 負荷インデックス 負荷インデックスは、クラスタ内のホストに搭載されている、共有されていない動 的リソースの可用性を表しています。LIM に組み込まれている負荷インデックス は、定期的に更新されます。 コマンド ◆ bhosts -l -特定のホストの負荷レベルを参照する 外部負荷インデック LSF 管理者が定義および設定し、外部負荷情報マネージャ(ELIM)プログラムに ス よって収集されます。ELIM は、新しい値を受け取ると、LIM の更新も行います。 静的リソース ユーザ プロセスが使用できる最大 RAM 容量、マシン上のプロセッサ数のように、 時間が経過しても変化しないホスト情報です。静的リソースのほとんどは、起動時 に LIM によって特定されます。 静的リソースを使用すると、バイナリ アーキテクチャ、CPU の相対的な処理速度、 システム構成を考慮して、特定のジョブに適したホストを選択できます。 負荷しきい値 LSF 管理者は、キュー内のジョブをスケジュールするために、2 種類の負荷しきい 値を設定することができます。各負荷しきい値は、負荷インデックス値を指定しま す。 loadSched は、保留中のジョブをディスパッチする負荷条件を指定します。負 荷が loadSched に設定されている値を超えているホストでは、ジョブは開始 されません。このしきい値は、中断中のジョブを再開する条件としても使用さ れます。 ◆ loadStop は、実行中のジョブを中断する条件を示しています。 ホストにジョブをスケジュールするには、そのホストの負荷レベルが、当該ホスト に設定されているしきい値とジョブのディスパッチ元のキューのしきい値の両方 に適合していなければなりません。 ◆ 負荷インデックスには、負荷が高くなるほど数値が大きくなるものと、逆に負荷が 高くなるほど数値が小さくなるものがあります。したがって、ホストの負荷レベル としきい値を比較する際には、使用する負荷インデックスに応じて比較演算子、す なわち '>' ( ~より大きい ) や '<' ( ~より小さい ) を使用する必要があります。 Platform Clusterware 管理者 25 クラスタの概念 コマンド ◆ ◆ ◆ bhosts-l -ホストの中断条件を参照する bqueues -l -キューの中断条件を参照する bjobs -l -特定のジョブに対する中断条件とジョブの再開時期を決定するス ケジューリングしきい値を参照する 設定 ◆ ◆ lsb.bhosts -ホストのしきい値を設定する lsb.queues -キューのしきい値を設定する 実行時の消費リソー ジョブが実行中に使用できるリソースを制限します。指定した量よりも多くのリ ス制限 ソースを消費するジョブにはシグナルが送られるか、優先順位が下げられます。 設定 ◆ lsb.queues -キューの消費リソース制限を設定する hard および soft 制 キュー レベルのリソース制限は hard 制限で、一方ジョブ投入時に指定される制限 限 は soft 制限です。hard 制限と soft 制限の概念については、setrlimit(2) マニュ アル ページを参照してください。 リソース要件 ジョブを実行できるホストを制限します。リソース要件と一致するホストが候補ホ (bsub -R) ストとなります。LSF がジョブをスケジュールするときは、すべての候補ホストの 負荷インデックス値を収集し、その値をスケジューリング条件と比較します。すべ ての負荷値がスケジューリングしきい値内にある場合のみ、そのホストにジョブが ディスパッチされます。 コマンド ◆ bsub-R -ジョブのリソース要件文字列を指定する 設定 ◆ 26 Platform Clusterware 管理者 lsb.queues -キューのリソース要件を設定する 第1章 Platform Clusterware とは ジョブのライフ サイクル 6 email job report Submit job (bsub) Submission Host job report (output, errors, info) 5 Job PEND Queues mbatchd 1 mbschd pim sbatchd 2 pim Commands res lim res Master lim 4 dispatch job sbatchd Master Host Server Host Job RUN 3 Commands 2 Execution Host Server Host 1 ジョブを投入する LSF クライアントまたはサーバから、bsub コマンドを使用してジョブを投入しま す。 ジョブ投入時にキューを指定しなければ、デフォルト キューに投入されます。 ジョブはスケジュールされるまでキューで待機し、その間は PEND 状態になりま す。ジョブは、LSF_SHAREDIR/cluster_name/logdir/info/ ディレクトリ内 のジョブ ファイルに格納されます。 ジョブ ID ジョブを投入すると、LSF によってそれぞれのジョブに固有のジョブ ID が割り当 てられます。 ジョブ名 bsub コマンドに -J オプションを指定すると、ジョブに名前も割り当てることが できます。ジョブ ID と異なり、ジョブ名は重複していてもかまいません。 2 ジョブをスケジュールする mbatchd は、あらかじめ設定されている間隔(lsb.params ファイルの JOB_SCHEDULING_INTERVAL パラメータで定義)でキュー内のジョブを調べ、 スケジューリングが行われるように、ジョブを mbschd に送ります。 2 mbschd は、次の設定に基づいてジョブを評価し、スケジューリングを行いま す。 ジョブの優先順位 ❖ スケジューリング ポリシー ❖ 使用可能なリソース ❖ 3 mbschd は、ジョブを実行できる最適なホストを選択し、決定を mbatchd に 送り返します。 マスタ LIM はあらかじめ設定されている間隔で、サーバ ホスト上の LIM からリソー ス情報を収集します。マスタ LIM はこの情報を mbatchd に伝え、そこから mbschd に伝えられて、スケジュール決定に使用されます。 1 Platform Clusterware 管理者 27 ジョブのライフ サイクル 3 ジョブをディスパッチする mbatchd は、スケジュール決定を受け取ると、即座にそのジョブをホストにディ スパッチします。 4 ジョブを実行する sbatchd は次の手順でジョブを実行します。 1 mbatchd から要求を受け取る 2 ジョブ用の子 sbatchd を作成する 3 実行環境を作成する 4 res を使用してジョブを起動する 実行環境は、投入ホストから実行ホストにコピーされます。実行環境は次の要素か ら構成されます。 ジョブに必要な環境変数 作業ディレクトリ(ジョブの起動元のディレクトリ) ◆ その他の次のようなシステムに依存する環境設定 ◆ リソース制限と umask(UNIX の場合) ❖ デスクトップや Window s ルート ディレクトリ(Window s の場合) ❖ ジョブは、そのジョブを投入したユーザ アカウントで実行され、状態は RUN にな ります。 ◆ 5 出力を返す ジョブが完了すると、正常に終了した場合は DONE の状態が割り当てられます。エ ラーのために最後まで実行されなかった場合は、EXIT の状態が割り当てられます。 sbatchd は、エラーと出力を含めたジョブ情報を mbatchd に伝えます。 6 クライアントに電子メールを送信する mbatchd は、ジョブ出力、ジョブ エラー、およびジョブ情報を電子メールで投入 ホストに返します。bsub コマンドの -o オプションと -e オプションを使用する と、ジョブ出力とエラーがファイルに送られます。 ジョブ レポート ジョブ レポートは、LSF クライアントに電子メールで送信されます。このレポート には、次の情報が含まれています。 ◆ ◆ ◆ 28 Platform Clusterware 管理者 ジョブ情報 CPU 使用率 ❖ メモリ使用率 ❖ ジョブを投入したアカウントの名前 ❖ ジョブ出力 エラー 第2章 システムの動作 LSF にはさまざまな構成方法があり、構成のしかたによってジョブのスケジューリ ングが影響を受けます。デフォルト設定では、LSF は次のようにジョブを処理しま す。 1 2 3 4 5 内容 ◆ ◆ ◆ ◆ ジョブを受け入れ、ジョブ ファイルを作成し、ユーザにジョブ ID を返す。 ジョブをスケジュールし、使用可能なホストから最適なホストを選択する。 選択したホストにジョブをディスパッチする。 ホストの環境を設定する。 ジョブを開始する。 30 32 34 36 ページの「ジョブの投入」 ページの「ジョブのスケジューリングとディスパッチ」 ページの「ホストの選択」 ページの「ジョブの実行環境」 Platform Clusterware 管理者 29 ジョブの投入 ジョブの投入 ジョブのライフ サイクルは、ユーザが LSF にジョブを投入したときから始まりま す。コマンド行では、bsub コマンドでジョブを投入します。このコマンドの各種 のオプションを使用して、LSF のデフォルトの動作を変更できます。ジョブはキュー に投入する必要があります。 キュー キューとは、現在保留状態で、LSF のリソースが使用可能になるまで待機している ジョブを一定の順番に並べたものです。LSF では、キューごとに別々のスケジュー リング ポリシーと制御ポリシーを適用できます。同じキューに投入されたジョブ は、同じスケジューリング ポリシーと制御ポリシーを共有します。キューとホスト との間には特定の対応関係はありません。それぞれのキューをクラスタ内のすべて のサーバ ホストに対応付けたり、一部のサーバ ホストだけに対応付けたりできま す。 LSF のキューは、ネットワーク全体にわたるジョブの収容場所です。キューにジョ ブを収容するには、bsub コマンドを使用します。LSF では、1 つ以上のデフォルト キューを指定できます。特に投入先を指定されていないジョブは、そのジョブを受 け入れ可能な最初のデフォルト キューに割り当てられます。それぞれのキューには 次の属性があります。 優先度(値が大きいほど優先) 名前(キューを識別するための固有の文字列) 制限事項(ホスト、ジョブ数、ユーザ、グループ、プロセッサなどについての制約) ◆ UNIX の標準的な制限事項(メモリ、スワップ、プロセス、CPU など) ◆ 管理者 ◆ ◆ 実行条件 負荷分散しきい値(キューに負荷分散を適用するのに使用) ◆ UNIX の nice(1) 値(UNIX のスケジューラでの優先度) ◆ キューの例を次に示します。 ◆ ◆ Begin Queue QUEUE_NAME = normal PRIORITY = 30 STACKLIMIT= 2048 DESCRIPTION = For normal low priority jobs, running only if hosts are lightly loaded. QJOB_LIMIT = 60 # job limit of the queue PJOB_LIMIT = 2 # job limit per processor ut = 0.2 io = 50/240 USERS = all HOSTS = all NICE = 20 End Queue 30 Platform Clusterware 管理者 第2章 システムの動作 キューの優先度 キューの優先度とは、処理するジョブを検出する際のキューの検索順を定めたもの です。キューの優先度は LSF 管理者が指定し、数値が大きくなるほど優先度が高く なります。LSF は、優先度が高い順にキューを処理します。 キューの自動選択 通常、クラスタには複数のキューがあります。ジョブを投入するときは、そのジョ ブの収容先のキュー名を指定します。キュー名を指定しないでジョブを投入した場 合は、ジョブに必要な条件を考慮して、デフォルト キューのリストの中から、その ジョブに適したキューが自動的に選択されます。デフォルト キューを 1 つも定義 していない場合は、デフォルト設定のキューが新しく作成され、そのキューにジョ ブが投入されます。 キューの自動選択自 LSF は、次の基準に従ってジョブに適したキューを選択します。 動キュー選択の機能 ユーザ アクセス制限 - 該当するユーザからの投入を許可していない ◆ ◆ ホスト制限 - ジョブを実行可能なホストが明示的に指定されている場合、選 択されるキューの設定を指定されたすべてのホストにジョブを送出可能とする 必要がある。 キューの状態 - クローズ中のキューは除外する。 ◆ ジョブの要求リソース - ジョブが要求しているリソースが、キューで設定し ◆ ているリソースの制約に適合している場合しか選択の対象にしない。 上記の条件をすべて満たしているキューが複数ある場合は、(DEFAULT_QUEUE パ ラメータや LSB_DEFAULTQUEUE 環境変数で定義する ) キューの候補リストのう ち、条件を満たしている最初のキューが選択されます。 ジョブ ファイル キューに投入したバッチ ジョブは、LSF Batch によってジョブ ファイルに格納さ れ、実行可能な状態になるまで保存されます。ジョブの実行には、このジョブ ファ イルが使われます。 ジョブ ファイルは、実行時にバッチ デーモンによって実行される Bourne シェル スクリプトです。 Platform Clusterware 管理者 31 ジョブのスケジューリングとディスパッチ ジョブのスケジューリングとディスパッチ 投入されたジョブは、スケジュールされ、実行ホストにディスパッチされるまで、 キューで待機します。ユーザがジョブを投入すると、LSF は次のようなさまざまな 要因を考慮し、ジョブをいつ、どのホストで実行するかを決定します。 ◆ ◆ ◆ ◆ ◆ ◆ キューやホストの有効時間帯 ジョブのリソース要件 適格ホストの可用性 ジョブ スロットの制約 ジョブの依存性の条件 負荷の状態 スケジューリング ポリシー 先着順(FCFS)ス デフォルト設定では、同じキュー内のジョブは先着順(FCFS)にディスパッチされ ケジューリング ます。つまり、ジョブはキュー内の順番どおりにディスパッチされることになりま す。キュー内のジョブは、ジョブの優先順位に基づいて並べられているため、投入 された順番でディスパッチされるとは限りません。さらに、ユーザや管理者は キュー内のジョブの順番を変更することもできます。 スケジューリングとディスパッチ ジ ョ ブ は 一 定 間 隔 で ス ケ ジ ュ ー ル さ れ ま す(デ フ ォ ル ト 設 定 で は 5 秒 お き。 lsb.params ファイル内の JOB_SCHEDULING_INTERVAL パラメータで設定可能)。 スケジュールされたジョブは、即座にホストにディスパッチされます。 ただし、同じホストに複数のジョブを送出する場合は、ホストの過負荷を防ぐため に、最初のジョブを送出してから次のジョブを送出するまでの間に一定の間隔が空 けられます。この待機時間は、lsb.params ファイルや lsb.queues ファイル内 の JOB_ACCEPT_INTERVAL パラメータで、ディスパッチ期間を単位として設定でき ます。このパラメータのデフォルト値は 1 です。このパラメータ値を 0(ゼロ)に 設定すると、同じディスパッチ期間に同一のホストで複数のジョブを開始できま す。 32 Platform Clusterware 管理者 第2章 システムの動作 ディスパッチ オーダ ジョブは投入順にディスパッチされるとは限りません。 それぞれのキューには優先度があり、LSF は、最も優先度の高いキューに格納され ているジョブから先に開始しようとします。この優先度は、キューを定義するとき に、LSF 管理者が設定します。 デフォルト設定では、LSF は次の順にディスパッチの検討を行います。 個々のキューについては優先度が高い順 優先順位が同じキューが複数ある場 合は、それらのキューからのジョブをすべて先着順にスケジューリングする。 同じキュー内の個々のジョブについては FCFS 順 ◆ ジョブの実行に適したホストが見つかった場合は、そのうちの最適なホストで ◆ ジョブを実行し、JOB_ACCEPT_INTERVAL で指定された時間が過ぎるまで、そ のホストでの他のジョブの実行を禁止 前処理条件が満たされていない場合や、特定のホストやリソースが使用できなかっ たりビジー状態になっている場合、また、ユーザのジョブ スロット数が上限に達し ている場合は、ジョブのディスパッチ オーダが入れ替わる可能性があります。 ◆ キュー内のジョブの キュー内のジョブの順番を参照するには、bjobs コマンドを使用します。FCFS ス 順番の参照 ケジューリング ポリシーでは、この順にジョブがディスパッチされます。 キュー内のジョブの キュー内のジョブの順番を入れ替えるには、btop コマンドや bbot コマンドを使 順番の変更(btop 用します。 および bbot) 詳細については、88 ページの「キュー内のジョブの順番を入れ替える」を参照して ください。 Platform Clusterware 管理者 33 ホストの選択 ホストの選択 LSF は、ジョブをディスパッチしようとするたびに、そのジョブの実行にどのホス トが適しているかをチェックします。実行に適しているホストは、次の各種の条件 に基づいて決定されます。 ホストへのディスパッチが可能な時間帯 ジョブのリソース要件 キューで指定されているリソース要件 ◆ キューで指定されているホスト リスト ◆ ホストの負荷レベル ◆ ◆ ホストのジョブ スロットの制約 あるホストについて、これらの条件がすべて満たされている場合は、そのホストが ジョブの実行に適しているとみなされます。ジョブがキューに収容されていて、か つそのジョブに適したホストが見つかった場合は、そのホストにジョブが配置され ます。実行に適したホストが複数見つかった場合は、それらのホストのうち、ジョ ブとキューのリソース要件に最も適したホストでジョブが開始されます。 ◆ ◆ ホストの負荷レベル ホストが使用可能とみなされるのは、そのホストの負荷指標(r1m、pg、mem など) の値が、事前に設定したスケジューリングしきい値の範囲内に収まっている場合で す。スケジューリングしきい値には、ホストごとに設定するものと、キューごとに 設定するものの 2 種類があります。ホストのいずれかの負荷指標の値が、これらの どちらか一方(または両方)のしきい値を超過している場合は、そのホストはジョ ブの実行に適していないと判断されます。 ホストの負荷レベル ◆ の参照 ◆ ホストのしきい値を表示するには、bhosts -l コマンドを使用する。 キューのしきい値を表示するには、bqueues -l コマンドを使用する。 適格ホスト LSF は、ジョブを配置しようとするときに、すべてのホストの現在の負荷の情報を 収集します。 収集された個々のホストの負荷レベルは、ホストごとのスケジューリングしきい値 (lsb.hosts ファイルの Host セクションで指定)や、キューごとのスケジューリ ングしきい値(lsb.queues ファイルで指定)と比較されます。 ホストのいずれかの負荷指標の値が、ディスパッチ元のキューやホスト自身のスケ ジューリングしきい値を超えている場合は、そのホストでは新しいジョブは開始さ れません。 適格ホストの参照 bjobs -lp コマンドを使用すると、現時点ではジョブの受け入れができないホス トの名前とその理由を参照できます。 34 Platform Clusterware 管理者 第2章 システムの動作 リソースの要件 スケジューリング条件は、キュー レベルでのリソースの要件(r1m<0.4 && pg<3 など)という形でも指定できます。 優先度の高い(または順番が先の)バッチ ジョブは、そのジョブに必要な条件を満 たしているホストがその時点で使用できない場合のみ、後続のジョブにディスパッ チの順番を譲ります。 現時点で使用可能なホストがあるものの、そのホストが特定のジョブの実行に適し ていない場合は、LSF は後続のジョブがそのホストで実行できるかどうかをチェッ クし、そのホストに適しているジョブのうち、順番が一番先のものを開始します。 Platform Clusterware 管理者 35 ジョブの実行環境 ジョブの実行環境 LSF は、ユーザに対してできるだけ透過的にジョブを実行しようとします。デフォ ルト設定では、実行先の環境は投入元の環境となるべく同じになるように構築され ます。LSF は、投入ホストの環境を実行ホストにコピーします。実行環境は次の要 素から構成されます。 ジョブに必要な環境変数 作業ディレクトリ(ジョブの起動元のディレクトリ) その他、消費リソース制限や umask など、システムに依存する環境設定 ◆ ネットワークには、さまざまな機種のホストが混在している場合があります。その ため、投入ホストの実行環境を実行ホスト上に常に再現できるとは限りません。ま た、再現することが望ましくないこともあります。たとえば、投入ホストと実行ホ ストの間でホーム ディレクトリが共有されていない場合は、LSF は実行ホスト上の /tmp ディレクトリでジョブを実行します。また、Unix:0.0 や :0.0 などの DISPLAY 環境変数値は、事前に処理しないと実行ホストでは使用できません。これ らの処理は LSF が自動的に受け持ちます。 ◆ ◆ デフォルトの実行環境は、次の方法で変更できます。 ジョブ スタータ bsub -L LSF は、リソースを制御するために実行環境の一部を変更します。nice 値、リソー スの制限など、ジョブ スタータで設定した環境も、この目的のために変更される場 合があります。 ◆ ◆ 共有ユーザ ディレクトリ LSF を最大限に活用できるのは、クラスタ内の全ホストでユーザ ホーム ディレク トリを共有しているときです。透過的なリモート実行を実現するには、すべての LSF ホスト上でユーザ ホーム ディレクトリを共有する必要があります。 透過的なリモート実行を実現するために、LSF コマンドはユーザのカレント作業 ディレクトリを判断し、リモート ホストでそのディレクトリを使用します。 たとえば、cc file.c コマンドがリモートで実行される場合、リモート コマンド が同じディレクトリで実行されるときは、cc は正しい file.c を検索するだけで 済みます。 LSF は、実行ホスト上のユーザのホーム ディレクトリに .lsbatch サブディレク トリを自動的に作成します。このディレクトリは、ジョブの一時入出力ファイルを 保存するために使用されます。 36 Platform Clusterware 管理者 第2章 システムの動作 実行可能プログラムと PATH 環境変数 実行可能プログラムの検索パス(PATH 環境変数)は、変更なしでリモート実行ホ ストに渡されます。混合クラスタでは、ユーザ バイナリ ディレクトリ(たとえば、 /usr/bin /usr/local/bin など)に他のホスト タイプと同じパスが設定されて いる場合、LSF を最大限に活用できます。この場合、PATH 変数はすべてのホスト で有効になります。 通常、LSF 構成ファイルは共有ディレクトリに保存されます。こうすることで管理 は容易になりますが、構成ファイルが読み取られることはめったにないので、パ フォーマンスは多少低下します。 Platform Clusterware 管理者 37 ジョブの実行環境 38 Platform Clusterware 管理者 第I部 クラスタの管理 内容 ◆ ◆ ◆ ◆ 第 第 第 第 3 4 5 6 章、「クラスタの操作」 章、「ホストの操作」 章、「キューの操作」 章、「ジョブの管理」 第3章 クラスタの操作 内容 ◆ ◆ ◆ ◆ ◆ 42 43 44 47 48 ページの「クラスタ情報の参照」 ページの「クラスタ管理者」 ページの「デーモンの制御」 ページの「mbatchd の制御」 ページの「クラスタの再構成」 Platform Clusterware 管理者 41 クラスタ情報の参照 クラスタ情報の参照 LSF では、各種のコマンドを使用して、クラスタに関する情報を参照できます。ク ラスタの情報には、マスタ ホスト、クラスタ名、リソース定義、クラスタ管理者な どが含まれます。 表示される情報 RUN ... LSF のバージョン クラスタ名 現在のマスタ ホスト名 クラスタ管理者 lsid lsid lsid lsclusters LSF のバージョン、クラスタ名、現在のマスタ ホストを参照する LSF のバージョン、クラスタの名前、現在のマスタ ホストを参照するには、lsid コ マンドを使用します。 % lsid LSF 5.1, Clusterware Edition Feb 17 2003 Copyright 1992- 2003 Platform Computing Corporation My cluster name is cluster1 My master name is hostA クラスタ管理者を参照する クラスタ管理者を確認したり、クラスタの概要を参照するには、lsclusters コマ ンドを使用します。 % lsclusters CLUSTER_NAME cluster1 STATUS ok MASTER_HOST hostA ADMIN lsfadmin HOSTS 6 SERVERS 6 LSF MultiCluster 製品を使用している場合は、lsclusters の出力の中に、ローカ ル クラスタに接続しているクラスタが、各行に 1 つずつ表示されます。 42 Platform Clusterware 管理者 第3章 クラスタの操作 クラスタ管理者 プライマリ クラス 必須です。インストール時に指定する 1 人目のクラスタ管理者です。プライマリ タ管理者 LSF 管理者のアカウントは、構成ファイルとログ ファイルを所有します。プライマ リ LSF 管理者は、クラスタ全体の操作、構成ファイルの変更、クラスタの再構成、 すべてのユーザ投入ジョブの制御を実施する権限を持ちます。 クラスタ管理者 任意指定です。インストール後に指定することもできます。 クラスタ管理者は、クラスタ内のすべてのジョブとキューに対して管理作業を実施 できます。プライマリ LSF 管理者と同様に、クラスタ管理者にもクラスタ全体の操 作を実施する権限がありますが、例外として、LSF の構成ファイルを変更すること はできません。 クラスタ管理者の追加 1 lsf.cluster.cluster_name ファイルの ClusterAdmins セクションに、 ADMINISTRATORS とその後にクラスタ管理者のリストを指定します。個々のク ラスタ管理者は空白文字で区切ります。このリストの先頭の管理者がプライマ リ LSF 管理者で、その他はクラスタ管理者になります。ユーザ名やグループ名 を指定できます。たとえば、次のように指定します。 Begin ClusterAdmins ADMINISTRATORS = lsfadmin admin1 admin2 End ClusterAdmins 2 3 4 変更内容を保存します。 lsadmin reconfig コマンドを実行し、LIM を再構成します。 badmin reconfig コマンドを実行し、mbatchd を再構成します。 Platform Clusterware 管理者 43 デーモンの制御 デーモンの制御 前提条件 クラスタ内のすべてのデーモンを制御できるようにするには、次の準備作業が必要 です。 ◆ root ユーザ、または /etc/lsf.sudoers ファイルで指定されたユーザとして ログオンすること。 『Pla tfo rm LSF Re fe re n c e 』を lsf.sudoers ファイルの設定の詳細については、 参照してください。 ◆ パスワードを入力しなくも、すべての LSF ホストで rsh または ssh コマンド 実行できること。 rsh および ssh コマンドの設定方法については、使用しているオペレーティン グ システムのマニュアルを参照してください。 lsf.conf ファイルの LSF_RSH で指定されるシェル コマンドは、rsh を試す 前に使用されます。 デーモン コマンド LSF デーモンの制御に使用するコマンドの概要を、次の表に示します。 デーモン 操作 使用するコマンド 必要な権限 起動 badmin hstartup [host_name ...|all] 再起動 シャットダ ウン 再起動 badmin hrestart [host_name ...|all] badmin hshutdow n [host_name ...|all] 起動コマンドは、root ユーザま たは lsf.sudoers ファイル で指定されたユーザだけが実行 可能 その他のコマンドは、root ユー ザまたは LSF 管理者だけが実行 可能 RES シャットダ ウン 再構成 起動 badmin hshutdow n badmin mbdrestart badmin reconfig lsadmin resstartup [host_name ...|all] lsadmin resshutdow n [host_name ...|all] LIM シャットダ ウン 再起動 起動 sbatchd mbatchd mbschd 44 Platform Clusterware 管理者 badmin mbdrestart これらのコマンドは、root ユー ザまたは LSF 管理者だけが実行 可 1 2 lsadmin resrestart [host_name ...|all] lsadmin limstartup [host_name ...|all] 起動コマンドは、root ユーザま たは lsf.sudoers ファイル で指定されたユーザだけが実行 可能 その他のコマンドは、LSF 管理 者だけが実行可能 起動コマンドは、root ユーザま たは lsf.sudoers ファイル で指定されたユーザだけが実行 可能 第3章 クラスタの操作 デーモン 操作 使用するコマンド 必要な権限 シャットダ ウン 再起動 クラスタ内 のすべての LIM の再起 動 lsadmin limshutdow n [host_name ...|all] その他のコマンドは、LSF 管理 者だけが実行可能 lsadmin limrestart [host_name ...|all] lsadmin reconfig Platform Clusterware 管理者 45 デーモンの制御 sbatchd ホスト上の sbatchd を再起動しても、そのホストで実行中のジョブは影響を受け ません。 sbatchd をシャットダウンすると、そのホストでは新しいジョブを実行できなく なります。そのホストですでに実行中のジョブはそのまま実行を続けますが、ユー ザにその結果が送信されるのは、停止していた sbatchd が再起動されてからにな ります。 LIM と RES ホスト上で実行中のジョブは、デーモンを再起動しても影響を受けません。 このコマンドを使用したときに、いずれかのデーモンがネットワーク接続に応答し ない場合は、エラー メッセージが出力され、該当するホスト名が通知されます。そ の場合は、そのデーモンを手動で強制終了し、再起動する必要があります。 現在のマスタ ホスト上の LIM が停止すると、他のホストがマスタ ホストの役割を 自動的に引き継ぎます。 また、対話型のリモート タスクを実行しているホスト上の RES が停止した場合は、 実行中のタスクは引き続き実行されますが、新しいタスクの受け入れはできなくな ります。 46 Platform Clusterware 管理者 第3章 クラスタの操作 mbatchd の制御 badmin reconfig コマンドでクラスタを再構成しても、構成ファイルが再ロード されるだけで、mbatchd は再起動されません。 ホスト グループにホストを追加したり、キューにホストを追加した場合、再構成を 行う前に投入されていたジョブは、新しいホストを認識しません。これらのジョブ に新しいホストを認識させたい場合は、mbatchd を再起動する必要があります。 mbatchd の再起動 badmin mbdrestart コマンドを実行します。LSF は構成ファイルにエラーがない かどうかをチェックし、その結果を stderr に出力します。エラーが見つからな かった場合は、次の処理が行われます。 構成ファイルを再ロードする。 mbatchd を再起動する。 ◆ lsb.events ファイルからイベント情報を読み取り、mbatchd の直前の実効 状態を復元する。 再起動している間、mbatchd は使用不能になり、サービス要求に応じることがで きません。大規模なクラスタでは、lsb.events ファイルに多数のイベントが記録 されるので、mbatchd の再起動に多少時間がかかることがあります。lsb.events ファイル内のイベントを再現する必要がない場合は、badmin reconfig コマンド を使用します。 ◆ ◆ mbatchd のシャットダウン 1 badmin hshutdown コマンドを実行し、マスタ ホスト上の sbatchd を シャットダウンします。たとえば、次のように指定します。 % badmin hshutdown hostD Shut down slave batch daemon on <hostD> .... done 2 badmin mbdrestart コマンドを実行します。 % badmin mbdrestart Checking configuration files ... No errors found. これによって、mbatchd と mbschd は終了しますが、mbatchd の再起動に必 要な sbatchd がシャットダウンされているので、mbatchd は停止したままに なります。すべての LSF サービスが一時的に使用不能になりますが、既存の ジョブはその影響を受けません。後で sbatchd によって mbatchd が起動さ れると、イベント ログ ファイルの内容に基づいて以前の状態が復元され、ジョ ブのスケジューリングが続行されます。 Platform Clusterware 管理者 47 クラスタの再構成 クラスタの再構成 LSF の構成ファイルを変更した場合は、それらのファイルを LSF に再ロードし、構 成を更新する必要があります。クラスタの再構成には、次の 3 つのコマンドを使用 できます。 ◆ lsadmin reconfig badmin reconfig ◆ badmin mbdrestart 変更したファイルに応じて、再構成コマンドを使い分ける必要があります。次の表 を参考にしてください。 ◆ 変更したファイル 使用するコマンド 実施される処理 ホスト lsb.hosts lsb.modules lsb.params lsb.queues lsf.cluster.cluster_name badmin badmin badmin badmin badmin 構成ファイルの再ロード 構成ファイルの再ロード 構成ファイルの再ロード 構成ファイルの再ロード 構成ファイルの再ロード LIM の再構成および構成ファイルの再 ロード LIM の再構成および構成ファイルの再 ロード LIM の再構成および構成ファイルの再 ロード 構成ファイルの再ロード LIM の再構成および構成ファイルの再 ロード reconfig reconfig reconfig reconfig reconfig lsadmin reconfig および badmin reconfig lsf.conf lsadmin reconfig および badmin reconfig lsf.shared lsadmin reconfig および badmin reconfig badmin reconfig lsf.sudoers lsf.task lsadmin reconfig および badmin reconfig lsadmin と badmin を使用してクラスタを再構成する 1 2 rroot ユーザまたは LSF 管理者としてホストにログオンします。 lsadmin reconfig コマンドを実行し、LIM を再構成します。 % lsadmin reconfig Checking configuration files ... No errors found. Do you really want to restart Restart LIM on <hosta> ...... Restart LIM on <hostc> ...... Restart LIM on <hostd> ...... LIMs on all hosts? [y/n] y done done done lsadmin reconfig コマンドは、構成にエラーがないかチェックします。 エラーが見つからなければ、すべてのホストの lim を再起動するかどうかを確 認するメッセージが表示され、lim が再構成されます。重大なエラーが見つ かった場合、再構成は中止されます。 48 Platform Clusterware 管理者 第3章 クラスタの操作 3 badmin reconfig コマンドを実行し、mbatchd を再構成します。 % badmin reconfig Checking configuration files ... No errors found. Do you want to reconfigure? [y/n] y Reconfiguration initiated badmin reconfig コマンドは、構成にエラーがないかチェックします。 重大なエラーが見つからなければ、再構成を行うかどうかを確認するメッセー ジが表示されます。重大なエラーが見つかった場合、再構成は中止されます。 mbatchd の再起動によってクラスタを再構成する badmin mbdrestart コマンドを実行し、mbatchd を再起動します。 % badmin mbdrestart Checking configuration files ... No errors found. Do you want to restart? [y/n] y MBD restart initiated badmin mbdrestart コマンドは、構成にエラーがないかチェックします。 重大なエラーが見つからなければ、mbatchd を再起動するかどうかを確認する メッセージが表示されます。重大なエラーが見つかった場合、一切のアクションを 実施せずにコマンドが終了します。 lsb.events ファイルに大量の情報が含まれている場合や、多数のジョブが実行されてい る場合は、 mbatchd が再起動するまでに多少時間がかかることがあります。さらに、再起 動している間、 mbatchd は使用不能になり、サービス要求に応じることができません。 構成エラーを参照する 次のコマンドを使用すると、構成エラーを参照できます。 ◆ lsadmin ckconfig -v badmin ckconfig -v これらのコマンドを実行すると、すべてのエラーが端末に報告されます。 ◆ Platform Clusterware 管理者 49 クラスタの再構成 50 Platform Clusterware 管理者 第4章 ホストの操作 内容 ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ 52 54 58 59 64 65 68 69 72 ページの「ホストの状態」 ページの「ホスト情報の参照」 ページの「ホストの制御」 ページの「ホストの動的な追加と削除」 ページの「lsf.shared にホスト タイプとホスト モデルを追加する」 ページの「サービス ポートの登録」 ページの「ホスト名を指定する」 ページの「複数のアドレスを備えたホスト」 ページの「CPU 係数の調整」 Platform Clusterware 管理者 51 ホストの状態 ホストの状態 ホストの状態は、ホストがバッチ ジョブを受け付け、実行する能力をデーモンの状 態、負荷レベル、実行管理という形で表しています。ホストの状態は bhosts コマ ンドと lsload コマンドで表示します。 bhosts ホストの現在の状態を表示します。 状態 説明 ok ホストは使用可能で、新しいバッチ ジョブを受け付け、実行す ることができます。 ホストがダウンしているか、LIM や sbatchd にアクセスできま せん。 LIM は稼働していますが、sbatchd にアクセスできません。 ホストが新しいジョブを受け付けません。bhosts -l コマンド を使用すると、理由を表示できます。 ホストに有効なライセンスが割り当てられていません。 unavail unreach closed unlicensed bhosts -l ホストが閉鎖されている理由を表示します。閉鎖中のホストでは、新しいバッチ ジョブを受け付けません。 状態 closed_Adm closed_Busy closed_Full closed_LIM closed_Lock closed_Wind 説明 LSF 管理者または root ユーザが badmin hclose を使用して意図的 にホストを閉鎖しました。実行中のジョブは影響を受けません。 負荷インデックスの値がしきい値(inlsb.hosts ファイルに設定さ れ、bhosts -l で表示)を超えました。実行中のジョブは影響を 受けません。しきい値を超えたインデックスはアスタリスク (*)付きで表示されます。 実行中のジョブ数が最大ジョブ数の設定値に達しています。実 行中のジョブは影響を受けません。 sbatchd は稼働していますが、LIM にアクセスできません。 LSF 管理者または root ユーザが lsadmin limlock を使用して意図 的にホストをロックしました。実行中のジョブは中断されます (SSUSP)。 lsb.hosts ファイルに定義されているディスパッチ時間帯のため に閉鎖されています。実行中のジョブは影響を受けません。 % bhosts HOST_NAME STATUS JL/U MAX hostA ok 55 hostB closed 20 ... % bhosts -l hostB HOST hostB STATUS CPUF JL/U MAX NJOBS closed_Adm 23.10 55 2 CURRENT LOAD USED FOR SCHEDULING: r15s r1m r15m ut pg 52 Platform Clusterware 管理者 NJOBS 2 16 RUN 2 16 RUN 2 SSUSP 0 io ls SSUSP 0 0 USUSP 0 it tmp USUSP 0 0 RSV 0 0 RSV DISPATCH_WINDOW 0 swp mem 第4章 ホストの操作 Total 1.0 -0.0 -0.0 4% Reserved 0.0 0.0 0.0 0% LOAD THRESHOLD USED FOR SCHEDULING: r15s r1m r15m ut loadSched loadStop - 9.4 0.0 pg - 148 0 io - 2 0 ls - 3 4231M 0 0M it - tmp - 698M 0M 233M 0M swp - mem - lsload ホストの現在の状態を表示します。 状態(status) ok -ok busy lockW lockU unavail unlicensed $ lsload HOST_NAME hostA hostB ... status ok ok r15s 0.0 1.0 説明 ホストは使用可能で、バッチ ジョブとリモート タスクを受け付 け、実行することができます。 LIM は稼働中ですが、RES にアクセスできません。 バッチ ジョブには影響しませんが、リモート タスクを配置(す なわち lsrun)する際に考慮されます。負荷インデックスの値が しきい値(lsf.cluster.c lu ste r_n a m e ファイルに設定され、 lshosts -l で表示)を超えました。しきい値を超えたインデック スはアスタリスク(*)付きで表示されます。 バッチ ジョブには影響しませんが、リモート タスクを配置(す なわち lsrun)する際に考慮されます。ホストは実行時間帯 (lsf.cluster.c lu ste r_n a m e ファイルに設定され、lshosts -l で表示) によってロックされています。 新しいバッチ ジョブまたはリモート タスクを受け付けません。 LSF 管理者または root ユーザが意図的にホストをロック(すな わち lsadmin limlock)しました。実行中のジョブは影響を受け ません。 ホストがダウンしているか、LIM にアクセスできません。 このホストには有効なライセンスが割り当てられていません。 r1m 0.0 0.0 r15m 0.0 0.0 ut 4% 4% pg 0.4 8.2 ls 0 2 it tmp 4316 10G 14 4231M swp 302M 698M mem 252M 232M Platform Clusterware 管理者 53 ホスト情報の参照 ホスト情報の参照 LSF では、クラスタ内のすべてのホストまたは一部のホストを実行ホストとして使 用します。どのホストを実行ホストとして使用するかは、LSF 管理者が設定したホ スト リストによって決まります。bhosts コマンドを使用すると、ホストに関する 情報を参照できます。また、lsload コマンドを使用すると、ホストの負荷情報を 参照できます。 表示する情報 RUN... クラスタ内の全ホストとその状態 サーバ ホストの詳細情報 bhosts bhosts -l および lshosts l lsload lshosts badmin hhist lsinfo 各ホストのホスト負荷 ホストのアーキテクチャ情報 ホストの履歴 ホスト モデルおよびホスト タイプ情報 クラスタ内の全ホストとその状態を参照する bhosts コマンドを実行すると、全ホストに関する情報とその状態が次のように表示 されます。 % bhosts HOST_NAME hostA hostD hostB STATUS ok ok ok JL/U 2 2 1 MAX 2 4 2 NJOBS 0 2 2 RUN 0 1 1 SSUSP 0 0 0 USUSP 0 0 1 RSV 0 1 0 サーバ ホストの詳細情報を参照する bhosts -l host_name および lshosts -l host_name コマンドを実行すると、 各サーバ ホストに関して、CPU 速度係数、ジョブを開始、中断、再開するための 負荷しきい値などの情報がすべて表示されます。これらのコマンドの例を次に示し ます。 % bhosts -l hostB HOST hostB STATUS CPUF JL/U MAX NJOBS RUN SSUSP USUSP ok 20.20 0 0 0 0 CURRENT LOAD USED FOR SCHEDULING: r15s r1m r15m ut pg io ls it tmp Total 0.1 0.1 0.1 9% 0.7 24 17 0 394M Reserved 0.0 0.0 0.0 0% 0.0 0 0 0 0M LOAD THRESHOLD USED FOR SCHEDULING: r15s r1m r15m ut pg io ls it tmp loadSched loadStop - % lshosts -l hostB HOST_NAME: hostB type model cpuf Sun4 Ultra2 20.2 ncpus 2 RESOURCES: Not defined 54 Platform Clusterware 管理者 ndisks 1 maxmem 256M maxswp 710M RSV 0 DISPATCH_WINDOWS - swp 396M 0M mem 12M 0M swp - maxtmp 466M mem - rexpri 0 server Yes 第4章 ホストの操作 RUN_WINDOWS: (always open) LICENSES_ENABLED: (LSF_Base LSF_Manager LSF_MultiCluster LSF_Make LSF_Parallel) LOAD_THRESHOLDS: r15s r1m r15m 1.0 - ut - pg - io - ls - it - tmp - swp - mem 4M ホストごとのホスト負荷を参照する lsload コマンドは、クラスタ内のホストの現在の状態と負荷レベルを報告します。 また、lshosts -l コマンドを使用すると負荷しきい値が表示されます。 lsmon コマンドは、負荷情報を動的に表示します。LSF 管理者は、これらのツール を使用して、使用不可能なホストや過負荷状態のホストを特定できます。 lsload コマンドを実行すると、ホストごとの負荷レベルが次のように表示されま す。 % lsload HOST_NAME hostD hostB hostA status ok -ok busy r15s 1.3 0.1 8.0 r1m 1.2 0.3 *7.0 r15m 0.9 0.7 4.9 ut 92% 0% 84% pg 0.0 0.0 4.6 ls 2 1 6 it 20 67 17 tmp 5M 45M 1M swp 148M 25M 81M mem 88M 34M 27M 出力の 1 行目には負荷インデックスの名前が表示され、2 行目以降には、その負荷 インデックスの値がホストごとに表示されます。 ホストのアーキテクチャ情報を参照する LSF のクラスタには、アーキテクチャや処理速度の異なるホストを混在させること ができます。lshosts コマンドを使用すると、これらのホストの構成情報を参照 できます。これらの情報には、LSF 管理者が LSF の構成ファイルで定義するものと、 LIM によってシステムから直接収集されるものの 2 種類があります。 ホスト タイプは、バイナリ レベルで互換性のあるホストを表しています。ホスト タイプが共通のホストは、同じ実行可能ファイルを実行できます。また、ホスト モ デルは、各種のプロセッサの相対的な CPU 性能を表しています。たとえば、次のよ うに表示されます。 % lshosts HOST_NAME type model cpuf ncpus maxmem maxswp server hostD SUNSOL SunSparc 6.0 1 64M 112M Yes hostB ALPHA DEC3000 10.0 1 94M 168M Yes hostM RS6K IBM350 7.0 1 64M 124M Yes hostC SGI6 R10K 14.0 16 1024M 1896M Yes hostA HPPA HP715 6.0 1 98M 200M Yes RESOURCES (solaris cserver) (alpha cserver) (cserver aix) (irix cserver) (hpux fserver) この例では、ホスト タイプ SUNSOL は Solaris を実行している Sun SPARC システ ム、ホスト タイプ ALPHA は Digital Unix を実行している Digital Alpha サーバです。 lshosts コマンドの出力には、それぞれのホスト上のリソースも表示されます。 type ホスト タイプです。ホストの CPU アーキテクチャを表しています。同じバイナリ プログラムを実行可能なホストには、同じホスト タイプを割り当てる必要がありま す。 Platform Clusterware 管理者 55 ホスト情報の参照 ホスト タイプやホスト モデルが UNKNOWN と表示される場合は、該当するホスト か、そのホスト上の LIM がダウンしています。その場合の対処法については、 310 ページの「ホスト タイプやホスト モデルが UNKNOWN になっている」を参照 してください。 ホスト タイプやホスト モデルの自動検出が失敗すると、該当するホスト タイプや ホスト モデルが DEFAULT に設定されます。LSF はこれらのホストでも機能します。 ただし、ホスト モデルが DEFAULT の場合は、CPU 係数が正しく設定されないため に、処理効率が低下する可能性があります。また、ホスト タイプが DEFAULT の場 合は、"DEFAULT" ホスト タイプのジョブが他の "DEFAULT" ホスト タイプに移され る可能性があるため、バイナリ コードの互換性の問題が発生することがあります。 ホストの履歴を参照する badmin hhist コマンドを実行すると、ホストの開放 / 閉鎖時刻などの履歴が次 のように表示されます。 % badmin hhist hostB Wed Nov 20 14:41:58: Host <hostB> closed by administrator <lsf>. Wed Nov 20 15:23:39: Host <hostB> opened by administrator <lsf>. ホスト モデルおよびホスト タイプ情報を参照する lsinfo -m コマンドを実行すると、クラスタ内に存在するホスト モデルに関する 情報を参照できます。 % lsinfo -m MODEL_NAME PC1133 HP9K735 HP9K778 Ultra5S Ultra2 Enterprise3000 CPU_FACTOR 23.10 4.50 5.50 10.30 20.20 20.00 ARCHITECTURE x6_1189_PentiumIIICoppermine HP9000735_125 HP9000778 SUNWUltra510_270_sparcv9 SUNWUltra2_300_sparc SUNWUltraEnterprise_167_sparc lsinfo -M コマンドを実行すると、lsf.shared ファイルに定義されているすべての ホスト モデルが表示されます。 % lsinfo -M MODEL_NAME CPU_FACTOR UNKNOWN_AUTO_DETECT 1.00 DEFAULT 1.00 LINUX133 2.50 PC200 4.50 Intel_IA64 12.00 Ultra5S 10.30 PowerPC_G4 12.00 HP300 1.00 SunSparc 12.00 ARCHITECTURE UNKNOWN_AUTO_DETECT x586_53_Pentium75 i86pc_200 ia64 SUNWUltra5_270_sparcv9 x7400G4 また、lim -t コマンドを実行すると、現行ホストのモデルを参照できます。この コマンドは LSF 管理者しか使用できません。 56 Platform Clusterware 管理者 第4章 ホストの操作 % lim -t Host Type Host Architecture Matched Type Matched Architecture Matched Model CPU Factor : : : : : : SOL732 SUNWUltra2_200_sparcv9 SOL732 SUNWUltra2_300_sparc Ultra2 20.2 Platform Clusterware 管理者 57 ホストの制御 ホストの制御 ホストの開放と閉鎖は、LSF 管理者または root ユーザがコマンドを発行するか、ま たは設定されているディスパッチ時間帯を使用して行います。 ホストを閉鎖する badmin hclose コマンドを実行します。 % badmin hclose hostB Close <hostB> ...... done コマンドが失敗する場合は、ネットワーク障害のためにホストにアクセスできない か、そのホストでデーモンが実行されていない可能性があります。 ホストを解放する badmin hopen コマンドを実行します。 % badmin hopen hostB Open <hostB> ...... done ディスパッチ時間帯 ディスパッチ時間帯は、ホストが新しいバッチ ジョブを受け入れる期間を指定する ものです。指定された時間帯以外は、ホストはジョブを受け付けません。ディス パッチ時間帯は、ジョブの投入や実行中のジョブには影響しません(実行中のジョ ブは完了するまで実行を継続することが可能)。デフォルト設定では、ディスパッ チ時間帯は設定されません。 ディスパッチ時間帯を設定するには、次の作業を行います。 1 2 lsb.hosts ファイルを編集します。 DISPATCH_WINDOW 列に 1 つ以上の時間帯を指定します。たとえば、次のよ うに指定します。 Begin Host HOST_NAME ... hostB ... End Host 3 4 58 Platform Clusterware 管理者 r1m pg ls tmp DISPATCH_WINDOW 3.5/4.5 15/ 12/15 0 (4:30-12:00) クラスタを再構成します。 a lsadmin reconfig コマンドを実行し、LIM を再構成します。 b badmin reconfig コマンドを実行し、mbatchd を再構成します。 bhosts -l を実行し、ディスパッチ時間帯を表示します。 第4章 ホストの操作 ホストの動的な追加と削除 デフォルトでは、LSF に対して行われたすべての構成変更は静的です。手動で構成 を変更し、クラスタ(または、少なくともすべてのマスタ候補)を再起動する必要 があります。動的ホスト構成では、手動で構成を変更しなくても、クラスタにホス トを追加したり、削除することができます。 警告 動的ホスト構成を有効にすると、任意のホストがクラスタに参加できるようになります。 lsf.cluster.cluster_name の LSF_HOST_ADDR_RANGE パラメータで、LSF ホ ストにできるホストを制限できます。 動的ホスト構成の動作 マスタ LIM 動的ホスト構成では、マスタ LIM は次のように動作します。 ◆ ◆ ◆ ホスト追加要求を受け取る ホストが追加または削除されると、他のマスタ候補に更新を行うように通知す る 利用できないホストを検出し、LSF_DYNAMIC_HOST_TIMEOUT が定義されて いる場合は、マスタ候補ではない使用できないホストを削除する マスタ候補 LIM(LSF_MASTER_LIST) 動的ホスト構成を有効にするには、 lsf.conf で LSF_MASTER_LIST を定義する必要が あります。クラスタのマスタ ホストになり得るホストのリストを指定します。 このホスト リストは、クラスタに新しいホストが追加されると、LSF 構成ファイル を読み取ります。他のホスト(スレーブ ホスト)は、マスタ LIM からホスト構成 を受け取るだけです。また、LSF_MASTER_LIST は、構成変更後に再構成する必要が あるホストを特定します。 新しいホストが追加されると、マスタ候補ホストが通知されます。マスタ候補がマ スタ ホストになると、その LIM が動的ホストからクラスタへの追加要求を受け取 ります。 マスタ候補ホストは、LSF 構成とバイナリを共有する必要があります。 スレーブ LIM 動的に追加された LSF ホストのうち、マスタ候補ではないホストをスレーブ ホスト と呼びます。各動的スレーブ ホストは、LSF バイナリ、ローカルの lsf.conf、お よびシェルの環境スクリプト(cshrc.lsf と profile.lsf)を独自に保有しま す。各スレーブ ホストに LSF をインストールする必要があります。 スレーブ LIM は、起動すると、自身の可用性をマスタ LIM に報告します。各スレー ブ ホストは、起動すると、まず自身をクラスタに追加するようにマスタ LIM に連 絡します。マスタ ホストは、そのホストがホスト テーブルに存在しない場合は追 加します。ホストがすでに追加されている場合は、ok を返します。 スレーブ ホストの スレーブ ホスト上に存在するローカル リソースのインスタンスを定義するには、 ローカル リソース ローカライズされた lsf.conf にある LSF_LOCAL_RESOURCES を使用します。 ◆ 数値リソースの場合は、次の名前と値のペアを定義します。 Platform Clusterware 管理者 59 ホストの動的な追加と削除 [resourcemap value*resource_name] ◆ Boolean リソースの場合は、次の形式のリソース名を定義します。 [resource resource_name] スレーブ ホストは、マスタ ホストを呼び出してそれ自身の追加を要求する際に、自 身のローカル リソースについても報告します。追加されるローカル リソースは、 lsf.shared で定義する必要があります。 同じリソースが、default または all として lsf.cluster.cluster_name で すでに定義されている場合、そのリソースをローカル リソースとして追加すること はできません。共有リソースは、ローカル リソースより優先されます。 リソースは、lsf.cluster.cluster_name の ResourceMap セクションでホストにマッピング されている必要があります。ResourceMap セクションが存在しない場合、ローカル リソー スは追加されません。 LSF_LOCAL_RESOURCES は、通常、インストール時に slave.config ファイルで設 定されます。LSF_LOCAL_RESOURCES がスレーブ ホストのローカルの lsf.conf です でに定義されている場合、 lsfinstall は、ユーザが slave.config の LSF_LOCAL_RESOURCES で定義したリソースを追加しません。 lsf.conf に複数の LSF_LOCAL_RESOURCES エントリを設定することはできません。ロー カル リソースが複数定義されている場合は、最後の定義だけが有効になります。 lsadmin コマンド LSF 以外のホストで lsadmin コマンドを実行できるようになりました。lsadmin limstartup を使用すると、新しく追加された動的ホストで LIM を起動できます。 マスタ フェイル マスタ LIM が停止した場合は、次のマスタ候補が、クラスタ内に動的に追加された オーバー ホストについてマスタ LIM と同じ情報を取得します。 mbatchd mbatchd は、マスタ LIM からホスト情報を取得します。ホストが動的に追加また は削除されたことを検出すると、mbatchd は、自分自身を動的に再構成します。 バッチ ホストを動的に追加した後で、 mbatchd がホストを検出して再構成するまで、し ばらく待たなければならない場合があります。システムの負荷に応じて、 mbatchd は、再 構成を行う前に最大 10 分間待機します。 lsb.hosts と lsb.queues のホスト構成 動的に追加されたホストに lsb.hosts と lsb.queues のホスト構成を適用する には、クラスタ内のすべてのホストに構成が適用されるように、必要に応じて default または all を使用します。 共有ファイル システムでのホストの動的追加 新しく動的に追加されたホストが、通常のホストと同じ構成ファイルとバイナリ ファイルを共有する場合、そのホスト上で LSF デーモンを起動するだけで、マスタ はそのホストを LSF ホストとして認識します。 新規インストール 1 60 Platform Clusterware 管理者 install.config でインストール オプションを指定します。 第4章 ホストの操作 次のパラメータは必須です。 ❖ ❖ ❖ ❖ 2 既存インストール 1 LSF_TOP="/pa th " LSF_ADMINS="u se r_n a m e [u se r_n a m e ...]" LSF_CLUSTER_NAME="c lu ste r_n a m e " LSF_MASTER_LIST="h o st_n a m e [h o st_n a m e ...]" クラスタのマスタ ホストになり得るホストをリストします。 lsfinstall -f install.config を使用して LSF をインストールします。 マスタ ホストで次のパラメータを設定します。 ❖ lsf.conf: ✧ LSF_MASTER_LIST="h o st_n a m e [h o st_n a m e ...]" クラスタのマスタ ホストになり得るホストをリストします。 ✧ LSF_DYNAMIC_HOST_TIMEOUT=h o u rs(オプション) オプションのタイムアウトの値を時間単位で設定します。動的ホスト が指定した時間より長い間使用できない場合、そのホストはクラスタか ら削除されます。 lsf.cluster.c lu ste r_n a m e (オプション) ✧ LSF_HOST_ADDR_RANGE=IP_a d d re ss ... クラスタに参加する各ホストに root ユーザとしてログオンします。 次のいずれかを使用して LSF の環境を設定します。 ❖ csh または tscsh の場合 ❖ 2 3 % source LSF_TOP/conf/cshrc.lsf ❖ sh、ksh または bash の場合 $ . LSF_TOP/conf/profile.lsf 4 オプションで、各 LSF サーバ ホストで hostsetup を実行します。 hostsetup を実行する必要があるのは、ホストが再起動されたときに LSF が 自動的に起動するようにする場合だけです。次に例を示します。 # cd /usr/share/lsf/5.1/install # ./hostsetup --top="/usr/share/lsf" --boot="y" hostsetup の使用を完了には、hostsetup -h と入力します。 5 次のコマンドを使用して LSF を起動します。 # lsadmin limstartup # lsadmin resstartup # badmin hstartup 非共有ファイル システムでのホストの動的追加(スレーブ ホスト) 各動的スレーブ ホストが、LSF バイナリ、ローカルの lsf.conf、およびシェルの 環境スクリプト(cshrc.lsf と profile.lsf)を独自に所有する場合は、各ス レーブ ホストに LSF をインストールする必要があります。 1 slave.config ファイルでインストール オプションを指定します。 次のパラメータは必須です。 LSF_SERVER_HOSTS="h o st_n a m e [h o st_n a m e ...]" LSF_TARDIR="/pa th " LSF_TOP="/pa th " ❖ 次のパラメータはオプションです。 ❖ ❖ Platform Clusterware 管理者 61 ホストの動的な追加と削除 ❖ LSF_LIM_PORT=po rt_n u m b e r マスタ ホストがデフォルトの LSF_LIM_PORT を使用していない場合は、マ スタ ホストの lsf.conf で定義されているものと同じ LSF_LIM_PORT を 指定する必要があります。 ❖ LSF_LOCAL_RESOURCES=re so u rc e ... 動的ホストのローカル リソースを定義します。 ✧ 数値リソースの場合は、次の名前と値のペアを定義します。 [resourcemap value*resource_name] ✧ Boolean リソースの場合は、次の形式のリソース名を定義します。 [resource resource_name] たとえば、次のように指定します。 LSF_LOCAL_RESOURCES=[resourcemap 1*verilog] [resource linux] LSF_LOCAL_RESOURCES がスレーブ ホストのローカルの lsf.conf ですでに定義され ている場合、 lsfinstall は、ユーザが slave.config の LSF_LOCAL_RESOURCES で定義したリソースを追加しません。 2 lsfinstall -s -f slave.config を使用して動的スレーブ ホストをイン ストールします。 lsfinstall は、スレーブ ホスト用のローカルの lsf.conf を作成します。 このファイルでは、次のパラメータが設定されます。 LSF_CONFDIR="/pa th " LSF_GET_CONF=lim LSF_LIM_PORT=po rt_n u m b e r(マスタ LIM のポート番号と同じ) ❖ LSF_LOCAL_RESOURCES=re so u rc e ... ❖ LSF_SERVER_HOSTS="h o st_n a m e [h o st_n a m e ...]" ❖ LSF_VERSION=Version 5.1 ❖ 次のいずれかを使用して LSF の環境を設定します。 ❖ csh または tscsh の場合 ❖ ❖ 3 % source LSF_TOP/conf/cshrc.lsf ❖ sh、ksh または bash の場合 $ . LSF_TOP/conf/profile.lsf 4 オプションで、各 LSF サーバ ホストで hostsetup を実行します。 hostsetup を実行する必要があるのは、ホストが再起動されたときに LSF が 自動的に起動するようにする場合だけです。たとえば、次のように指定します。 # cd /usr/local/lsf/5.1/install # ./hostsetup --top="/usr/local/lsf" --boot="y" hostsetup の使用を完了には、hostsetup -h と入力します。 5 62 Platform Clusterware 管理者 次のコマンドを使用して LSF を起動します。 # lsadmin limstartup # lsadmin resstartup # badmin hstartup 第4章 ホストの操作 制約 非共有スレーブ ホストがクラスタに初めて参加する場合、新しいホスト上のデーモ ンは、ローカル ホストでのみ起動できます。たとえば、LSF 管理者が lsadmin limstartup hostB を使用して hostA から hostB 上のデーモンを起動すること はできません。それには、ホストがクラスタに初めて参加する際に、次のコマンド を使用します。 # rsh hostB lsadmin limstartup クラスタに参加できるホストの制限 デフォルトでは、任意のホストをクラスタに動的に追加できます。承認されていな いホストがクラスタに参加することを防ぐには、オプションで、 lsf.cluster.cluster_name で LSF_HOST_ADDR_RANGE を使用して IP アド レスの範囲を定義し、LSF ホストとして動的に追加できるホストを識別できるよう にします。 LSF_HOST_ADDR_RANGE (lsf.cluster.cluster_name) LSF_HOST_ADDR_RANGE に値を定義すると、ホストの動的追加および削除のセ キュリティが有効になり、指定された範囲内の IP アドレスを持つホストだけをク ラスタに動的に追加または削除できるようになります。 動的に追加されたホストの自動削除 デフォルトでは、動的に追加されたホストは、クラスタ内に永続的に留まります。 オプションで、lsf.conf で LSF_DYNAMIC_HOST_TIMEOUT を使用すると、タイ ムアウトの値を時間単位で設定できます。 LSF_DYNAMIC_HOST_TIMEOUT (lsf.conf) LSF_DYNAMIC_HOST_TIMEOUT が定義されており、ホストがマスタ候補でない場 合、指定した時間より長い間ホストが使用できなくなると、そのホストはクラスタ から削除されます。 Platform Clusterware 管理者 63 lsf.shared にホスト タイプとホスト モデルを追加する lsf.shared にホスト タイプとホスト モデルを追加する lsf.shared ファイルには、ホスト タイプとホスト モデルの名前のリストが記録 され、その情報はほとんどのオペレーティング システムで使用されます。このリス トは、ホスト タイプ名やホスト モデル名を新たに追加したり、名前を変更してカ スタマイズすることができます。ホスト タイプ名とホスト モデル名には、最大 29 文字までの英数字を使用できます。 独自のホスト タイプまたはホスト モデルを追加する 1 2 クラスタ内の任意のホストに LSF 管理者としてログオンします。 lsf.shared ファイルを編集します。 a 新しいホスト タイプを追加する場合は、HostType セクションを修正しま す。 Begin HostType TYPENAME DEFAULT CRAYJ CRAYC CRAYT DigitalUNIX HPPA IBMAIX4 SGI6 SUNSOL SONY WIN95 End HostType b # Keyword 新しいホスト モデルを追加する場合は、HostModel セクションを修正し ます。 新しいモデルとその CPU 係数(CPU の相対的な処理速度)の情報を追加し ます。CPU 係数の詳細については、72 ページの「CPU 係数の調整」を参照 してください。 Begin HostModel MODELNAME CPUFACTOR ARCHITECTURE # keyword # x86 (Solaris, NT, Linux): approximate values, based on SpecBench results # for Intel processors (Sparc/NT) and BogoMIPS results (Linux). PC75 1.5 (i86pc_75 i586_75 x586_30) PC90 1.7 (i86pc_90 i586_90 x586_34 x586_35 x586_36) HP9K715 4.2 (HP9000715_100) SunSparc 12.0 () CRAYJ90 18.0 () IBM350 18.0 () End HostModel 3 4 5 64 Platform Clusterware 管理者 lsf.shared ファイルに変更内容を保存します。 lsadmin reconfig コマンドを実行し、LIM を再構成します。 badmin reconfig コマンドを実行し、mbatchd を再構成します。 第4章 ホストの操作 サービス ポートの登録 LSF では、UDP ポートと TCP ポートを通信に使用します。クラスタ内のホストが 相互に通信を行うためには、すべてのホストで使用するポート番号を統一する必要 があります。 サービス ポートの番号は、他のサービスが使用していない数字であれば、1024 ~ 65535 の範囲の任意の数字を指定できます。指定しようとしているポート番号が、 サービス データベースに登録されているアプリケーションによって使用されてい ないことを確認するために、/etc/services をチェックするか、コマンド ypcat services を使用します。 デフォルトでは、LSF サービスのポート番号は lsf.conf ファイルに定義されてい ますが、ポートを設定する別の方法として、/etc/services ファイルや、NIS ま たは NIS+ データベースを修正することもできます。 lsf.conf 1 2 任意のホストに root としてログオンします。 lsf.conf ファイルを編集し、次の行を追加します。 LSF_LIM_PORT=3879 LSF_RES_PORT=3878 LSB_MBD_PORT=3881 LSB_SBD_PORT=3882 3 4 5 6 7 すべてのホスト上の lsf.conf ファイルに、同じ情報を追加します。 lsf.conf ファイルを保存します。 lsadmin reconfig コマンドを実行し、LIM を再構成します。 badmin reconfig コマンドを実行し、mbatchd を再構成します。 クラスタ内のすべてのデーモンを再起動します。 /etc/services インストール時に、 hostsetup --boot="y" オプションを使用して、サービス データ ベースで LSF ポート番号を設定します。 サービスの手動設定 LSF_TOP/version/install/instlib/example.services フ ァ イ ル を 参 考 にして、サービス データベースに LSF エントリを追加します。 サービス データベースに設定されている他のサービスが使用しているポート番号 が LSF サービスのポート番号と重複している場合、LSF サービスのポート番号を変 更する必要があります。ただし、どの LSF ホストでも同じポート番号を使用しなけ ればなりません。 1 2 任意のホストに root としてログオンします。 ファイルを編集し、 /etc/services LSF_TOP/version/install/instlib/example.services ファイルの内 容を追加します。 Platform Clusterware 管理者 65 サービス ポートの登録 # /etc/services entries for LSF daemons # res 3878/tcp # remote execution server lim 3879/udp # load information manager mbatchd 3881/tcp # master lsbatch daemon sbatchd 3882/tcp # slave lsbatch daemon # # Add this if ident is not already defined # in your /etc/services file ident 113/tcp auth tap # identd 3 4 5 lsadmin reconfig コマンドを実行し、LIM を再構成します。 badmin reconfig コマンドを実行し、mbatchd を再構成します。 クラスタ内のすべてのデーモンを再起動します。 NIS または NIS+ データベース NIS を実行している場合は、NIS マスタ ホストごとに 1 回だけサービス データベー スを修正するだけです。ホストによって、NIS データベースとコマンドが /var/yp ディレクトリに格納されている場合と、/etc/yp に存在する場合があります。 1 2 3 任意のホストに root としてログオンします。 クラスタ内のすべてのデーモンを停止します。 NIS マスタ ホストの名前を確認するには、次のコマンドを使用します。 % ypwhich -m services 4 5 NIS マスタ ホストに root としてログオンします。 NIS マスタ ホスト上の ファイルまたは /var/yp/src/services フ ァ イ ル を 編 集 し、 /etc/yp/src/services LSF_TOP/version/install/instlib/example.services ファイルの内 容を追加します。 # /etc/services entries for LSF daemons. # res 3878/tcp # remote execution server lim 3879/udp # load information manager mbatchd 3881/tcp # master lsbatch daemon sbatchd 3882/tcp # slave lsbatch daemon # # Add this if ident is not already defined # in your /etc/services file ident 113/tcp auth tap # identd 追加したすべての行には、有効なサービス エントリが含まれているか、または コメント文字(#)が先頭にあることを確認してください。空白行は追加できま せん。 6 7 /var/yp または /etc/yp ディレクトリに移動します。 次のコマンドを実行します。 % ypmake services ホストによっては、サービス データベースのマスタ コピーが別の場所に格納 されている場合があります。 NIS+ を実行しているシステムでも、実施する手順はほぼ同じです。詳細につい ては、使用しているシステムのマニュアルを参照してください。 66 Platform Clusterware 管理者 第4章 ホストの操作 8 lsadmin reconfig コマンドを実行し、LIM を再構成します。 9 badmin reconfig コマンドを実行し、mbatchd を再構成します。 10 クラスタ内のすべてのデーモンを再起動します。 Platform Clusterware 管理者 67 ホスト名を指定する ホスト名を指定する LSF では、ホスト名をインターネット ホスト アドレスに対応付ける必要がありま す。 LSF は、次の情報源からホストの名前とアドレスを検出します。 ◆ ◆ ◆ /etc/hosts ファイル Sun の NIS (Netw ork Information Service) または YP (Yellow pages) Internet Domain Name Service(DNS) DNS を BIND(Berkeley Internet Name Domain)または named と呼ぶ場合もあ ります(named は BIND デーモンの名前です)。 これらの情報源を組み合わせてそれぞれのホストを構成できます。 ネットワーク アドレス それぞれのホストには 1 つ以上のネットワーク アドレス(通常はホストが直接接 続しているネットワークごとに 1 つずつ)を割り当てます。1 つのホストに複数の ホスト名を割り当てることもできます。 公式ホスト名 アドレスごとに設定した最初のホスト名を「公式ホスト名(または公式名)」と呼 びます。 別名 公式名以外のホスト名を「別名」と呼びます。 LSF は、各ホスト上のホスト命名システムを使用して、ホストのアドレスや別名か ら公式ホスト名を特定します。LSF では入力として別名を使用できますが、画面上 には常に公式名が表示されるのはそのためです。 ホスト名サービス Digital UNIX Digital UNIX システムでは、/etc/svc.conf ファイルでどのホスト名サービスを 使用するかを指定します。 Solaris Solaris システムでは、/etc/nsswitch.conf ファイルでネーム サービスを制御 します。 その他の UNIX プ その他の UNIX プラットフォームでは、次の規則が適用されます。 ラットフォーム ◆ ホストに /etc/resolv.conf ファイルがある場合は、DNS を使用してホスト 名を検出します。 ◆ ypcat hosts コマンドでホスト アドレスとホスト名のリストが出力される場 合は、そのシステムでは NIS でホスト名を検出しています。 上記のどちらにも該当しない場合は、/etc/hosts ファイルからホスト名を検 ◆ 出します。 詳細情報の参照先 ホスト名の検出の詳細については、gethostbyname 関数、ypbind デーモン、 named デ ー モ ン、resolver 関 数、hosts フ ァ イ ル、svc.conf フ ァ イ ル、 nsswitch.conf ファイル、resolv.conf ファイルの各 man ページを参照して ください。 68 Platform Clusterware 管理者 第4章 ホストの操作 複数のアドレスを備えたホスト マルチ ホーム ホス 複数のネットワーク インタフェースを備えているホストでは、通常はそれらのイン ト タフェースごとにインターネット アドレスを 1 つずつ割り当てます。このような ホストを「マルチ ホーム ホスト」と呼びます。LSF ではホストを名前で識別するた め、これらのアドレスを単一のホスト名に対応付ける必要があります。それには、 あるホストのどのインターネット アドレスからも同じホスト名を検出できるよう に、ホスト名の情報を構成する必要があります。 ホスト名の情報を構成するには、次の 2 とおりの方法があります。 ◆ ◆ システム ホスト ファイル(etc/hosts)を修正し、修正した内容をシステム 全体に反映する。 LSF ホスト ファイル(LSF_CONFDIR/hosts)を作成し、LSF を複数のアドレ スから同じホストを検出する唯一のアプリケーションとして使用する。 複数ネットワーク インタフェース 一部のシステム メーカーは、ネットワーク インタフェースごとに(言い換えれば インターネット アドレスごとに)別々のホスト名を割り当てることを推奨していま す。この構成方式は、それぞれのネットワーク インタフェースにホスト名で直接ア クセスできるという利点があり、NFS の要求をルータ経由でネットワーク インタ フェースに渡すのではなく、ファイル サーバ上の一番近いネットワーク インタ フェースに確実に渡せるようにしたい場合によく使われます。しかし、そのままで は LSF が混乱してしまいます。別々のホスト名(アドレス)が同じホストを指して いることを識別する手段がないからです。LSF には、この問題に対する回避策が用 意されています。 すなわち、それぞれのネットワーク インタフェースに別々の名前でアクセスできる ようにしながら、あるホストのどのアドレスからも同じホスト名が返されるように ホスト命名システムを構成できます。ホストごとに 1 つの公式名と複数の別名(公 式名以外の名前)を割り当てることができます。この機能を使用して、ネットワー ク インタフェースの公式名をすべて同じにし、それぞれの別名を別々にすると、ホ ストの公式名を 1 つに保つと同時に、それぞれのネットワーク インタフェースを 別々の別名で呼び出すことができます。 LSF ホスト ファイルを構成する クラスタで複数のネットワーク インタフェースを備えたホストを使用していて、そ のホストに複数の公式名を割り当てている場合は、ホスト名の構成を修正するか、 LSF 用の hosts ファイルを作成する必要があります。 LSF の hosts ファイルは LSF_CONFDIR に保存します。このファイルの書式は /etc/hosts と同じです。 LSF の hosts ファイルを作成するときは、システムの hosts データベースの情報 を複製し、該当するホストのすべてのエントリで公式名が同じになるように内容を 修正します。そのホストの他の名前はすべて別名として定義し、ホストをそれらの どの名前でも呼べるようにします。 Platform Clusterware 管理者 69 複数のアドレスを備えたホスト 例 たとえば、/etc/hosts ファイルに次の情報が含まれていたとします。 AA.AA.AA.AA BB.BB.BB.BB host-AA host # first interface host-BB # second interface その場合は、LSF_CONFDIR/hosts ファイルの内容を次のように設定します。 AA.AA.AA.AA BB.BB.BB.BB host host-AA # first interface host host-BB # second interface /etc/hosts のエントリの例 固有の公式名がない 以下は、2 つのインタフェースを備え、それぞれの公式名が別々のホストの例です。 場合 # Address Official name Aliases # Interface on network A AA.AA.AA.AA host-AA.domain # Interface on network B BB.BB.BB.BB host-BB.domain host.domain host-AA host host-BB host この場合は、アドレス AA.AA.AA.AA からは host-AA.domain という公式名が、 アドレス BB.BB.BB.BB からは host-BB.domain という公式名が検出されます。 この 2 つの名前を結び付ける情報はないため、LSF からはこの 2 つの名前(および 2 つのアドレス)が同じホストを指していることがわかりません。 この問題を解決するには、これらのアドレスに同じホスト名を割り当てる必要があ ります。システム ファイルではこの変更ができないため、LSF のホスト ファイル を作成し、その中でこの情報を指定します。 両方のアドレスの公 以下は、上記と同じホストで、両方のアドレスに同じ公式名を割り当てた例です。 式名が同じ場合 # Address Official name Aliases # Interface on network A AA.AA.AA.AA host.domain # Interface on network B BB.BB.BB.BB host.domain host-AA.domain host-AA host host-BB.domain host-BB host この場合は、どちらのアドレスからも host.domain という公式名が返されます。 LSF(およびその他のすべてのアプリケーション)は、これらのアドレスやホスト 名が同じホストを指していることを認識できます。さらに、host-AA および hostBB という別名を使用すれば、それぞれのインタフェースを区別して指定すること もできます。 Sun の NIS では、NIS マスタ ホスト上の /etc/hosts ファイルを入力として使用 します。そのため、NIS のエントリの書式は、/etc/hosts の場合と同じになりま す。 この場合は、LSF 自身で問題を解決できるので、LSF のホスト ファイルを作成する 必要はありません。 70 Platform Clusterware 管理者 第4章 ホストの操作 DNS の構成情報 DNS では構成情報の書式が異なりますが、インターネット アドレスごとにアドレ ス(A)のレコードを 2 つずつ設定すれば同じ結果になります。たとえば、先ほど の例は DNS では次のようになります。 # name host.domain host.domain host-AA.domain host-BB.domain class IN IN IN IN type A A A A address AA.AA.AA.AA BB.BB.BB.BB AA.AA.AA.AA BB.BB.BB.BB 公式ホスト名からは、どちらか一方のアドレスが検出されます。インタフェースご とに固有のホスト名を使用すれば、それぞれのインタフェースの正しいアドレスを 検出できます。 DNS の PTR レコー DNS でのアドレスからホスト名への変換は、PTR レコードを使用して処理されま ド す。次のように、どちらのアドレスの PTR レコードからも公式名が返されるように 設定する必要があります。 # address AA.AA.AA.AA.in-addr.arpa BB.BB.BB.BB.in-addr.arpa class IN IN type PTR PTR name host.domain host.domain システムのホスト名データベースを変更できない場合は、LSF システム用の hosts ファイルを作成し、その中でマルチ ホーム ホストのエントリを設定します。この ファイルに含まれていないホスト名やアドレスは、ホスト上の標準の名前システム で検出されます。 Platform Clusterware 管理者 71 CPU 係数の調整 CPU 係数の調整 CPU 係数は、マシンによる処理性能の違いを識別するために使用するパラメータで す。LSF は、応答時間がなるべく小さくなるように、最適なマシンを選んでジョブ を実行します。 この機能を正しく活用するには、それぞれのホスト モデルに適切な CPU 係数を割 り当てる必要があります。 CPU 係数と処理性能の関係 CPU 係数を正しく設定しないと、次の 2 つの点で LSF の処理性能に悪影響が現れ ます。 ホストの CPU 係数を低く設定しすぎると、そのホストが使用できるにもかかわ らず、それよりも低速なホストでジョブが実行されてしまう可能性があります。 すなわち、その時点で使用可能なホストのうち、最も高速なホスト上でジョブ が実行されるとは限らなくなります。 ホストの CPU 係数を高く設定しすぎると、そのホストにジョブが集中しすぎて ◆ しまいます。実際には、それよりも低速で、空いているホストのジョブが早く 終了するにもかかわらず、それらのホストが活用されない可能性があります。 LSF では、これらの状況は自動的に緩和されます。ホストの CPU 係数を高く設定し すぎた場合は、ジョブがそのホストに集中的に送出されます。しかし、最終的には CPU の負荷がしきい値に達します。それ以後は、そのホストがビジー状態と認識さ れ、新しいジョブが送出されなくなります。また、ホストの CPU 係数を低く設定 しすぎた場合は、ジョブがより低速なホストに送出されてしまう可能性があります が、その結果として、そのホストの負荷が上昇すると、本来のホストにジョブが送 出されやすくなります。 ◆ CPU 係数の決定方法 CPU 係数は、実際のワークロードを反映したベンチマークに基づいて設定します。 適切なベンチマークを用意できない場合は、代わりに生の CPU 性能を基準にしま す。 最も低速なホストの CPU 係数を 1 に設定します。それ以外のホストの CPU 係数 は、最も低速なホストに対する比率で表します。 例 hostA と hostB の 2 つのホストからなるクラスタを考えてみましょう。hostA で はベンチマークの実行に 30 秒かかり、hostB では同じベンチマークが 15 秒で終 了したとします。その場合は、hostA の CPU 係数を 1 に設定します。また、hostB は hostA の 2 倍の性能を持っているため、hostB の CPU 係数は 2 に設定します。 正規化した処理性能を参照する 正規化した処理性能を表示するには、lsload -N コマンドを実行します。LSF は、正 規化した CPU 処理性能に基づいて、最も CPU 性能が高いホストを判断します。こ のコマンドでは、クラスタ内のホストが処理性能の高い順にリストアップされま す。このコマンドで報告される CPU 実行キュー長の値は、負荷がなく、CPU 係数 が 1 のホストで 1 作業単位を実行するのにかかる時間を基準にして、当該ホストで 新しく 1 作業単位を実行するのに要する時間を見積もったものです。 72 Platform Clusterware 管理者 第4章 ホストの操作 CPU 係数を調整する 1 2 クラスタ内の任意のホストに LSF 管理者としてログオンします。 lsf.shared ファイルの HostModel セクションを修正します。 Begin HostModel MODELNAME CPUFACTOR #HPUX (HPPA) HP9K712S 2.5 HP9K712M 2.5 HP9K712F 4.0 ARCHITECTURE # keyword (HP9000712_60) (HP9000712_80) (HP9000712_100) lsf.shared ファイルの詳細については、『Pla tfo rm LSF Re fe re n c e 』を参照し てください。 3 4 5 lsf.shared ファイルに変更内容を保存します。 lsadmin reconfig コマンドを実行し、LIM を再構成します。 badmin reconfig コマンドを実行し、mbatchd を再構成します。 Platform Clusterware 管理者 73 CPU 係数の調整 74 Platform Clusterware 管理者 第5章 キューの操作 内容 ◆ ◆ ◆ ◆ 76 77 79 81 ページの「キューの状態」 ページの「キュー情報の参照」 ページの「キューの制御」 ページの「キューを追加 / 削除する」 Platform Clusterware 管理者 75 キューの状態 キューの状態 bqueues によって表示されるキューの状態は、次の状態を組み合わせて、キューが バッチ ジョブを受け入れて起動できるかどうかを示しています。 ◆ ◆ ◆ ◆ 開放されているキューは、新しいジョブを受け入れる 閉鎖されているキューは、新しいジョブを受け入れない 有効なキューは、使用可能なホスト上でジョブを起動する 無効なキューは、すべてのジョブを保持する 状態 Open:Active Open:Inact Closed:Active Closed:Inact 説明 新しいジョブを受け入れ、起動する(通常処理) 新しいジョブを受け入れ、保持する(収集処理) 新しいジョブは受け入れないが、既存ジョブの起動は続行 する-ドレイン処理 新しいジョブを受け入れず、既存ジョブの起動もしない (すべての機能を停止) LSF 管理者や root ユーザは、キューの状態を変更できます。 76 Platform Clusterware 管理者 第5章 キューの操作 キュー情報の参照 キューの情報を参照するには、bqueues コマンドを使用します。また、このコマ ンドに -l オプションを付けると、キュー内のジョブの総数、実行中のジョブ数、 中断中のジョブ数といった、特定のキューに含まれているジョブについての最新の 統計情報を確認できます。 bqueues コマンドの詳細については、bqueues(1) の man ページを参照してくだ さい。 使用可能なキューとその状態を参照する bqueues コマンドを使用すると、特定のキューやキューすべての現在の状態を参 照できます。このコマンドでは、クラスタ内の使用可能なキューも確認できます。 % bqueues QUEUE_NAME interactive priority night short license normal idle PRIO 400 43 40 35 33 30 20 STATUS Open:Active Open:Active Open:Inactive Open:Active Open:Active Open:Active Open:Active MAX - JL/H - NJOBS 2 16 4 6 0 0 6 PEND 0 4 4 1 0 0 3 RUN 2 11 0 5 0 0 SUSP 0 1 0 0 0 0 1 2 ダッシュ(-)は、該当する値がないことを示しています。 Platform Clusterware 管理者 77 キュー情報の参照 キューの詳細情報を参照する bqueues -l コマンドを実行すると、それぞれのキューの状態と設定に関する詳細 情報が表示されます。コマンド行でキュー名を指定し、特定のキューについての情 報だけを表示することもできます。次の例では、キュー normal の詳細情報を表示 しています。 % bqueues -l normal QUEUE: normal --For normal low priority jobs, running only if hosts are lightly loaded. This is the default queue. PARAMETERS/STATISTICS PRIO NICE STATUS MAX JL/U JL/P NJOBS PEND RUN SSUSP USUSP 40 20 Open:Active 100 50 11 1 1 0 0 0 Migration threshold is 30 min. CPULIMIT 20 min of IBM350 FILELIMIT 20000 K RUNLIMIT 342800 min of IBM350 DATALIMIT 20000 K STACKLIMIT 2048 K SCHEDULING PARAMETERS r15s r1m r15m loadSched 0.7 1.0 loadStop 1.5 2.5 ut 0.2 - CORELIMIT 20000 K pg 4.0 8.0 io 50 240 MEMLIMIT 5000 K ls - it - tmp - swp - mem - DEFAULT HOST SPECIFICATION : IBM350 USERS: groupA/ groupB/ user5 HOSTS: hostA, hostD, hostB PRE_EXEC: /tmp/apex_pre.x > /tmp/preexec.log 2>&1 POST_EXEC: /tmp/apex_post.x > /tmp/postexec.log 2>&1 REQUEUE_EXIT_VALUES: 45 キューの状態の変更履歴を参照する badmin qhist コマンドを実行すると、キューがいつ開放 / 閉鎖されたり、有効 / 無効にされたかが表示されます。 % badmin qhist Wed Mar 31 09:03:14: Queue <normal> closed by user or administrator <root>. Wed Mar 31 09:03:29: Queue <normal> opened by user or administrator <root>. キュー管理者を参照する キューを指定して bqueues -l を使用します。 78 Platform Clusterware 管理者 第5章 キューの操作 キューの制御 LSF 管理者または root ユーザは、コマンドを発行したり、ディスパッチ時間帯およ び実行時間帯を設定したりしてキューを制御することができます。 キューを閉鎖する badmin qclose コマンドを実行します。 % badmin qclose normal Queue <normal> is closed 閉鎖されているキューにユーザがジョブを投入しようとすると、次のようなメッ セージが表示されます。 % bsub -q normal ... normal: Queue has been closed キューを開放する badmin qopen コマンドを実行します。 % badmin qopen normal Queue <normal> is opened キューを無効にする badmin qinact コマンドを実行します。 % badmin qinact normal Queue <normal> is inactivated キューを有効にする badmin qact コマンドを実行します。 % badmin qact normal Queue <normal> is activated Platform Clusterware 管理者 79 キューの制御 ディスパッチ時間帯 ディスパッチ時間帯は、ホスト上で実行するためにバッチ ジョブがディスパッチさ れる期間を指定するものです。指定された時間帯以外は、ジョブのディスパッチは 行われません。ディスパッチ時間帯は、ジョブの投入や実行中のジョブには影響し ません(実行中のジョブは完了するまで実行を継続することが可能)。デフォルト 設定では、ディスパッチ時間帯は設定されず、キューは常に有効な状態にあります。 ディスパッチ時間帯を設定するには、次の作業を行います。 1 2 lsb.queues ファイルを編集します。 該当するキューに DISPATCH_WINDOW キーワードを設定し、1 つ以上の時間 帯を指定します。たとえば、次のように指定します。 Begin Queue QUEUE_NAME = queue1 PRIORITY = 45 DISPATCH_WINDOW = 4:30-12:00 End Queue 3 4 次のコマンドを使用して、クラスタを再構成します。 a lsadmin reconfig b badmin reconfig bqueues -l コマンドを実行し、ディスパッチ時間帯を表示します。 実行時間帯 実行時間帯は、特定のキューからディスパッチされたジョブを実行できる期間を指 定するものです。実行時間帯を過ぎると、実行中のジョブは中断され、保留中の ジョブは保留されたままになります。中断されたジョブは、再び実行時間帯になっ た時点で再開されます。デフォルト設定では、実行時間帯は設定されず、キューは 常に有効な状態にあり、ジョブは最後まで実行されます。 実行時間帯を設定するには、次の作業を行います。 1 2 lsb.queues ファイルを編集します。 該当するキューに RUN_WINDOW キーワードを設定し、1 つ以上の時間帯を指 定します。たとえば、次のように指定します。 Begin Queue QUEUE_NAME = queue1 PRIORITY = 45 RUN_WINDOW = 4:30-12:00 End Queue 3 4 80 Platform Clusterware 管理者 次のコマンドを使用して、クラスタを再構成します。 a lsadmin reconfig. b badmin reconfig. bqueues -l コマンドを実行し、実行時間帯を表示します。 第5章 キューの操作 キューを追加 / 削除する キューを追加する 1 2 クラスタ内の任意のホストに LSF 管理者としてログオンします。 lsb.queues ファイルを編集し、新しいキューの定義を追加します。 このファイルに含まれている他のキューの定義をコピーし、ひな形として使用 すると作業が楽になります。ただし、QUEUE_NAME を変更することを忘れない でください。 3 4 lsb.queues ファイルの内容を保存します。 badmin reconfig コマンドを実行し、mbatchd を再構成します。 キューを追加しても、保留中や実行中のジョブは影響を受けません。 キューを削除する キューを削除する前に、そのキューにジョブが収容されていないことを確認する必要があり ます。 削除したいキューにジョブが含まれていた場合は、保留中や実行中のジョブを他の キューに移してから、該当するキューを削除します。ジョブを含んでいるキューを そのまま削除した場合は、それらのジョブが lost_and_found キューに一時的に 移されます。このキューに移されたジョブは、ユーザや LSF 管理者が bswitch コ マンドで通常のキューに戻すまで、保留状態のままになります。それ以外のキュー に含まれているジョブは影響を受けません。 1 2 クラスタ内の任意のホストに LSF 管理者としてログオンします。 削除したいキューを閉鎖して、ジョブがこれ以上投入されないようにします。 たとえば、次のように指定します。 % badmin qclose night Queue <night> is closed 3 保留中のジョブと実行中のジョブを別のキューに移します。次の例では、 bswitch コマンドに -q night 引数を付けて、night キューのジョブを選択 しています。また、ここでは 0(ゼロ)というジョブ ID を指定しているため、 このキューのすべてのジョブが移動の対象になります。 % bjobs -u all -q night JOBID USER STAT QUEUE FROM_HOST SUBMIT_TIME 5308 user5 RUN night hostA 18:16 5310 user5 PEND night hostA 18:17 EXEC_HOST JOB_NAME hostD job5 Nov 21 hostC job10 Nov 21 % bswitch -q night idle 0 Job <5308> is switched to queue <idle> Job <5310> is switched to queue <idle> 4 5 6 lsb.queues ファイルを編集し、削除したいキューの定義を取り除くか、コメ ント アウトします。 lsb.queues ファイルの内容を保存します。 badmin reconfig コマンドを実行し、mbatchd を再構成します。 Platform Clusterware 管理者 81 キューを追加 / 削除する 82 Platform Clusterware 管理者 第6章 ジョブの管理 内容 ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ 84 87 88 89 90 91 92 93 ページの「ジョブの状態」 ページの「ジョブ情報の参照」 ページの「キュー内のジョブの順番を入れ替える」 ページの「ジョブを他のキューに切り替える」 ページの「ジョブを強制的に実行する」 ページの「ジョブを中断 / 再開する」 ページの「ジョブを強制終了する」 ページの「ジョブにシグナルを送出する」 Platform Clusterware 管理者 83 ジョブの状態 ジョブの状態 bjobs コマンドを使用すると、ジョブの現在の状態を表示することができます。 正常なジョブの状態 ほとんどのジョブは、次の 3 種類の状態のいずれかになります。 ジョブの状態 説明 PEND スケジュールされ、ディスパッチされるのをキューの中で待っ ている状態 ホストにディスパッチされ、実行されている状態 終了値ゼロで正常に終了した状態 RUN DONE 中断されたジョブの 中断されたジョブは、次の 3 種類の状態のいずれかになります。 状態 ジョブの状態 説明 PSUSP PEND 状態のときに、所有者または LSF 管理者によって中断され た ディスパッチされた後、所有者または LSF 管理者によって中断 された ディスパッチされた後、LSF によって中断された USUSP SSUSP 状態の推移 それぞれのジョブは、さまざまな状態を経て、最終的には正常終了するか、異常終 了するか、強制終了されます。ジョブのライフ サイクル全体にわたる状態の移り変 わりを次の図に示します。 suitable host found normal completion bsub PEND RUN migration DONE bresume host OK host overloaded bstop PSUSP SSUSP bstop bkill EXIT bkill or abnormal exit bresume USUSP bkill 実行中のジョブを参 bjobs -r コマンドを使用すると、実行中のジョブが表示されます。 照する 終了したジョブを参 bjobs -d コマンドを使用すると、最近完了したジョブが表示されます。 照する 84 Platform Clusterware 管理者 第6章 ジョブの管理 保留中のジョブ ジョブは、実行に必要な条件がすべて満たされるまでキューの中で待機します。こ れが「PEND(保留)状態」です。ジョブの実行条件には、次のようなものがあります。 ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ジョブの投入時にユーザが指定した開始時刻 適格ホストの負荷の状態 ディスパッチ時間帯(キューからのジョブのディスパッチ、および適格ホスト でのジョブの受け入れが可能な時間帯) 実行時間帯(ジョブを実行可能な時間帯) キュー、ホスト、ユーザごとのジョブ スロット数の制約 他のユーザやジョブに対する優先度 リソースの可用性 ジョブの依存関係と前処理条件 保留理由を参照する bjobs -p コマンドを使用すると、ジョブが保留されている理由が表示されます。 中断中のジョブ ジョブはいつでも中断できます。ジョブの中断方法には、ジョブの所有者による中 断、LSF 管理者による中断、root ユーザ(スーパーユーザ)による中断、LSF によ る中断の 4 種類があります。 すでにディスパッチされ、ホスト上で実行されているジョブは、LSF によって中断 される場合があります。LSF は、ジョブの実行中に、実行先のホストの負荷レベル を定期的にチェックし、いずれかの負荷指標がホストごと、またはキューごとの中 断条件に適合している場合に、該当するホスト上の最も優先度の低いジョブを中断 します。 実行先のホストの負荷が高くなりすぎると、バッチ ジョブどうし、またはバッチ ジョブと対話型ジョブの間で競合が発生する可能性があります。その場合は、これ らのジョブの一部を中断し、ホストの処理性能や対話型ジョブの応答時間を保つ必 要があります。 LSF がどのジョブを中断するかは、それぞれのジョブの所属先のキューの優先度に 基づいて決められます。ホストがビジー状態になると、LSF はこの優先度が低いジョ ブから順に中断します。ただし、ジョブに適用されているスケジューリング ポリ シーのために中断できないジョブは除きます。 また、ジョブの所属先のキューで実行時間帯を設定している場合は、現在時刻がそ の時間帯を過ぎたときにも、LSF によって該当するジョブが中断されます。 LSF が中断したジョブは、実行先のホストの負荷レベルが十分に低下したときや、 現在時刻が再び実行時間帯に入ったときに自動的に再開できます。 中断理由の参照 bjobs -s コマンドを使用すると、ジョブが中断した理由が表示されます。 Platform Clusterware 管理者 85 ジョブの状態 完了ジョブ ジョブは各種の原因で異常終了することがあります。この異常終了は、ジョブがど の状態のときでも発生する可能性があります。異常終了したジョブは EXIT 状態に なります。異常終了が発生するのは、ジョブが次のような状態になった場合です。 ジョブが保留状態のとき、またはホストにディスパッチされた後で、所有者ま たは LSF 管理者によって中止された。 ジョブがディスパッチされないうちに終了期限になり、LSF によって破棄され ◆ た。 ジョブを開始できなかった(投入時にユーザが不適切な実行可能ファイルを指 ◆ 定した場合など)。 このような場合、ジョブはゼロ(0)以外の終了値で終了します。 ◆ 実行後の状態 ジョブによっては、後処理が行われるまでは終了したとはみなせない場合がありま す。たとえば、ジョブの終了後に、実行後ジョブ スクリプトを介してジョブを終了 させたり、ジョブ ファイルのクリーン アップを行ったり、出力を転送したりする 場合があります。 DONE または EXIT というジョブ状態からは、後処理が完了したかどうかは判断で きません。したがって、処理に依存するジョブが時期尚早に開始される可能性があ ります。そこで、bsub -w コマンドに post_done および post_err キーワード を使用して、ジョブの後処理に対してジョブ依存の条件を指定します。各キーワー ドに対応するジョブ状態、POST_DONE および POST_ERR に後処理の状態が示され ます。 ジョブが終了した後は、後処理に対してジョブ制御を行うことはできません。後処 理の終了コードは、LSF Batch に報告されません。繰り返しジョブの後処理が繰り 返し期間より長くなることはありません。 実行後の状態を参照 bhist コマンドを使用すると、POST_DONE および POST_ERR 状態が表示されま する す。後処理のリソース使用率は、ジョブのリソース使用率には含まれません。 詳細については、第 19 章、 「実行前コマンドと実行後コマンド」を参照してくださ い。 86 Platform Clusterware 管理者 第6章 ジョブの管理 ジョブ情報の参照 bjobs コマンドを使用して、ジョブ情報を表示できます。デフォルトでは、bjobs コマンドを実行したユーザに対して情報が表示されます。bjobs の詳細について は、 『LSF リファレンス』および bjobs(1) のマニュアル ページを参照してくださ い。 ユーザ全員のすべてのジョブを参照する bjobs コマンドに -u all オプションを付けると、ユーザ全員のジョブが次の規 則に従って表示されます。 実行中のジョブを先に表示 保留中のジョブはスケジューリング順に表示 優先度の高いキューに含まれているジョブは、優先度の低いキューに含まれて いるジョブより先に表示 たとえば、次のように表示されます。 1 2 3 % bjobs JOBID 1004 1235 1234 1250 -u all USER user1 user3 user2 user1 STAT RUN PEND SSUSP PEND QUEUE short priority normal short FROM_HOST hostA hostM hostD hostA EXEC_HOST hostA hostM JOB_NAME job0 job1 job3 job4 SUBMIT_TIME Dec 16 09:23 Dec 11 13:55 Dec 11 10:09 Dec 11 13:59 特定のユーザのジョブを参照する bjobs -u user_name コマンドを実行すると、特定のユーザのジョブが表示されま す。たとえば、次のようなコマンドを実行します。 % bjobs JOBID 2225 2226 2227 -u user1 USER STAT user1 USUSP user1 PSUSP user1 PSUSP QUEUE normal normal normal FROM_HOST hostA hostA hostA EXEC_HOST JOB_NAME job1 job2 job3 SUBMIT_TIME Nov 16 11:55 Nov 16 12:30 Nov 16 12:31 Platform Clusterware 管理者 87 キュー内のジョブの順番を入れ替える キュー内のジョブの順番を入れ替える LSF では、特に指定しない限り、適切なサーバ ホストが使用できるかどうかに応じ て、キュー内のジョブが収容された順に(すなわち先着順に)ディスパッチされま す。 bbot コマンドや btop コマンドを使用すると、保留中のジョブを入れ替えて、ディ スパッチの検討順序を修正できます。それぞれのユーザは自分自身のジョブの相対 的な順番しか入れ替えられませんが、LSF 管理者はユーザ全員のジョブの順番を入 れ替えることができます。 bbot ジョブをキューの末尾に移動します。 通常のユーザが使用した場合は、このコマンドで指定したジョブが、該当するユー ザの同じ優先度のジョブの末尾に移されます。 LSF 管理者が使用した場合は、このコマンドで指定したジョブが、同じ優先度のす べてのジョブの末尾に移されます。 btop ジョブをキューの先頭に移動します。 通常のユーザが使用した場合は、このコマンドで指定したジョブが、該当するユー ザの同じ優先度のジョブの先頭に移されます。 LSF 管理者が使用した場合は、このコマンドで指定したジョブが、同じ優先度のす べてのジョブの先頭に移されます。 ジョブをキューの先頭に移動する 次の例では、ジョブ 5311 をキューの先頭に移動しています。ジョブ 5308 はすでに 開始されているため、ジョブ 5311 はこのジョブの直後に配置されます。 user1 のジョブの位置は変化しないことに注意してください。user2 が btop コ マンドで特定のジョブを前に移すと、そのユーザの残りのジョブが後ろに移動しま す。user 2 のいくつものジョブをキューの先頭に移動できるわけではありません。 % bjobs -u JOBID USER 5308 user2 5309 user2 5310 user1 5311 user2 all STAT RUN PEND PEND PEND QUEUE normal night night night FROM_HOST hostA hostA hostB hostA EXEC_HOST hostD JOB_NAME /s500 /s200 /myjob /s700 SUBMIT_TIME Oct 23 10:16 Oct 23 11:04 Oct 23 13:45 Oct 23 18:17 % btop 5311 Job <5311> has been moved to position 1 from top. % bjobs -u JOBID USER 5308 user2 5311 user2 5310 user1 5309 user2 88 all STAT RUN PEND PEND PEND Platform Clusterware 管理者 QUEUE normal night night night FROM_HOST hostA hostA hostB hostA EXEC_HOST hostD JOB_NAME /s500 /s200 /myjob /s700 SUBMIT_TIME Oct 23 10:16 Oct 23 18:17 Oct 23 13:45 Oct 23 11:04 第6章 ジョブの管理 ジョブを他のキューに切り替える ジョブの収容先を、あるキューから別のキューに切り替えるには、bswitch コマ ンドを使用します。このコマンドは、ジョブを不適切なキューに投入してしまった 場合や、キューのしきい値や実行時間帯の条件のために中断されたジョブを再開し たい場合に役立ちます。 特定のジョブを切り替える bswitch コマンドを実行すると、特定のキューに含まれている保留中または実行 中のジョブを、他のキューに移動できます。 次の例では、ジョブ 5309 を priority キューに切り替えています。 % bswitch priority 5309 Job <5309> is switched to queue <priority> % bjobs -u all JOBID USER 5308 user2 5309 user2 5311 user2 5310 user1 STAT RUN RUN PEND PEND QUEUE normal priority night night FROM_HOST hostA hostA hostA hostB EXEC_HOST hostD hostB JOB_NAME /job500 /job200 /job700 /myjob SUBMIT_TIME Oct 23 10:16 Oct 23 11:04 Oct 23 18:17 Oct 23 13:45 すべてのジョブを切り替える bswitch -q from_queue to_queue 0 コマンドを実行すると、特定のキューに 含まれているすべてのジョブを、他のキューに切り替えることができます。次の例 では、night キューの中の特定のジョブを idle キューに切り替えています。 -q オプションは、特定のキューに含まれているジョブ全体を操作対象にしたいと きに使用します。また、ここでは 0(ゼロ)というジョブ ID を指定しているため、 night キューの中のすべてのジョブが idle キューに移されます。 % bswitch -q night idle 0 Job <5308> is switched to queue <idle> Job <5310> is switched to queue <idle> Platform Clusterware 管理者 89 ジョブを強制的に実行する ジョブを強制的に実行する brun コマンドを使用すると、保留中のジョブを強制的に実行できます。この操作 は LSF 管理者だけが実施できます。 ジョブを強制的に実行する際に、特定のホストで実行すること、中断せずに最後ま で実行すること、およびその他の制限を加えることができます。詳細については、 brun コマンドの説明を参照してください。 ジョブが強制的に実行された場合、リソース要件や依存関係など、そのジョブで指 定されている実行条件はすべて無視されます。 保留中のジョブを強制的に実行する brun -m hostname job_ID コマンドを実行すると、保留中のジョブを強制的に 実行することができます。この場合、ジョブを実行するホストを指定する必要があ ります。たとえば、順次ジョブ 104 を hostA で強制的に実行するには、次のコマ ンドを使用します。 % brun -m hostA 104 90 Platform Clusterware 管理者 第6章 ジョブの管理 ジョブを中断 / 再開する ジョブの所有者や LSF 管理者はジョブを中断できます。これらのジョブはユーザに よる中断と解釈され、bjobs コマンドではその状態が USUSP と表示されます。 ジョブを中断する bstop job_ID コマンドを実行します。ジョブを中断すると、すでに開始されてい るジョブは、USUSP 状態になり、保留中のジョブは、PSUSP 状態になります。た とえば、次のコマンドを実行するとします。たとえば、次のコマンドを実行すると します。 % bstop 3421 Job <3421> is being stopped ジョブ 3421 が中断されます。 bstop コマンドを実行すると、ジョブに次のシグナルが送出されます。 ◆ SIGSTOP(順次ジョブの場合) ユーザ プログラムはこのシグナルを受けることはできません。SIGSTOP シグ ナルは、lsf.conf ファイル内の LSB_SIGSTOP パラメータで設定できます。 ジョブを再開する bresume job_ID コマンドを実行します。たとえば、次のコマンドを実行すると します。 % bresume 3421 Job <3421> is being resumed ジョブ 3421 が再開されます。 ユーザが中断したジョブは、このコマンドを使用してもすぐには RUN 状態に切り 替わりません。実行中に中断したジョブを再開すると、そのジョブがまず SSUSP 状態になり、負荷の状態に従って SBD がスケジューリングを行うまで、その状態 が保たれます。 Platform Clusterware 管理者 91 ジョブを強制終了する ジョブを強制終了する bkill コマンドを使用すると、保留中のバッチ ジョブを取り消したり、実行中の ジョブにシグナルを送出できます。特に指定しなければ、実行中のジョブには SIGKILL シグナルが送出されます(UNIX の場合)。 bkill コマンドは、SIGKILL シグナルを送出する前に SIGINT と SIGTERM の 2 つのシグナルを送出し、ジョブにシグナルを捕捉し、クリーン アップ処理を行う機 会を与えます。これらのシグナルは MBD から SBD に渡され、SBD は該当するジョ ブが強制終了されるまで待ってからジョブの状態を報告します。この時間的な遅れ があるため、bkill コマンドを実行してからしばらくの間は、bjobs コマンドで はそのジョブの状態が実行中(RUN)と報告される場合があります。 ジョブを強制終了する bkill job_ID を実行します。 % bkill 3421 Job <3421> is being terminated ジョブ 3421 を強制終了します。 ジョブを強制的に削除する bkill -r コマンドを実行すると、LSF からジョブを強制的に削除することができ ます。このオプションは、オペレーティング システムではジョブを強制終了できな い場合に使用します。 このコマンドは、オペレーティング システムによってジョブが強制終了されるのを 待たずに、そのジョブを LSF から削除します。このコマンドを使用した場合も、r オプションを指定しなかった場合と同じ 3 つのシグナルが順番に送出されます が、該当するジョブは LSF システムから直ちに取り除かれ、EXIT 状態に切り替え られます。LSF が監視しているジョブのリソースは、LSF が最初のシグナルを受け 取ったときに即座に解放されます。 92 Platform Clusterware 管理者 第6章 ジョブの管理 ジョブにシグナルを送出する LSF では、ジョブの制御、スケジューリング ポリシーの適用、ユーザの要求への応 答にシグナルを使用しています。LSF で使用される主なシグナルは、ジョブを中断 するための SIGSTOP、ジョブを再開するための SIGCONT、ジョブを終了させるた めの SIGKILL です。 場合によっては、デフォルト アクションを指定変更することが必要なこともありま す。たとえば、ジョブを中断する代わりに、ジョブを強制終了するか、またはチェッ ク ポ イ ン ト を 実 行 し た い 場 合 も あ り ま す。こ の よ う な 場 合 は、キ ュ ー 定 義 に JOB_CONTROLS パラメータを指定することにより、デフォルトのジョブ制御アク ションを指定変更します。ジョブ制御アクションは、キューごとに定義することが できます。 ジョブに直接シグナルを送出することもできますが、保留中のジョブに送出できる シグナルには制限があります。ほとんどのシグナルは、実行中のジョブにだけ有効 です。ただし、LSF では保留中のジョブについても強制終了、中断、再開を行うこ とができます。 ジョブにシグナルを送出できるのは、そのジョブの所有者と LSF 管理者だけです。 bkill -s コマンドを使用すると、ジョブにシグナルを送出することができます。 -s オプションを付けずに bkill コマンドを発行すると、該当するジョブに SIGKILL シグナルが送出され、そのジョブが強制終了されます。SIGKILL シグナルが送出 される 20 秒前に SIGTERM および SIGINT シグナルが送出され、ジョブにシグナ ルを捕捉し、クリーン アップ処理を行う機会が与えられます。 プラットフォームによるシグナルの違い ホスト タイプの違いに応じて、同じシグナルに別の番号が付けられている場合があ ります。LSF には、異なるプラットフォームの間でシグナル番号を変換する機能が あります。シグナル番号の意味は、bkill コマンドの発行元のマシンで解釈されま す。 たとえば、SunOS 4.x のホストからシグナル番号 18 を送出したとします。このマ シンでは、番号 18 は SIGTSTP を意味しています。ジョブが HP-UX マシンで実行 されていて、このマシンでは SIGTSTP のシグナル番号が 25 と定義されていたとす ると、LSF は該当するジョブにシグナル番号 25 を送出します。 ジョブにシグナルを送出する bkill -s signal job_id コマンドを実行するとき、signal にはシグナル名と シグナル番号のどちらでも指定できます。たとえば、次のコマンドを実行するとし ます。 % bkill -s TSTP 3421 Job <3421> is being signaled この場合、ジョブ 3421 に TSTP シグナルが送出されます。 ほとんどの UNIX では、kill( 1) や signal(2) のマニュアル ページで、シグナル名 とシグナル番号のリストを参照できます。 Platform Clusterware 管理者 93 ジョブにシグナルを送出する 94 Platform Clusterware 管理者 第 II 部 リソースの管理 内容 ◆ ◆ 第 7 章、「リソースの概要」 第 8 章、「リソースの追加」 第7章 リソースの概要 内容 ◆ ◆ ◆ ◆ ◆ ◆ 98 ページの「LSF のリソースとは」 100 ページの「リソースの分類」 104 ページの「LSF でのリソースの使用」 105 ページの「負荷インデックス」 109 ページの「静的リソース」 110 ページの「ハードウェア再構成の自動検出」 Platform Clusterware 管理者 97 LSF のリソースとは LSF のリソースとは LSF システムでは、組込みリソースと構成リソースを使用して、ジョブのリソース 要件の追跡や、各ホスト上で使用可能なリソースに基づいたジョブのスケジューリ ングを行います。 使用可能なリソースを参照する lsinfo lsinfo: コマンドを使用すると、クラスタで使用可能なリソースがリストアップ されます。このコマンドを使用して、全リソースの名前とその説明を参照できます。 % lsinfo RESOURCE_NAME r15s r1m r15m ut pg io ls it tmp swp mem ncpus ndisks maxmem maxswp maxtmp cpuf rexpri server irix hpux solaris cserver fserver aix type model status hname TYPE Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Boolean Boolean Boolean Boolean Boolean Boolean Boolean String String String String TYPE_NAME HPPA SGI6 ALPHA SUNSOL RS6K NTX86 MODEL_NAME DEC3000 98 CPU_FACTOR 10.00 Platform Clusterware 管理者 ORDER Inc Inc Inc Inc Inc Inc Inc Dec Dec Dec Dec Dec Dec Dec Dec Dec Dec N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A DESCRIPTION 15-second CPU run queue length 1-minute CPU run queue length (alias:cpu) 15-minute CPU run queue length 1-minute CPU utilization (0.0 to 1.0) Paging rate (pages/second) Disk IO rate (Kbytes/second) Number of login sessions (alias: login) Idle time (minutes) (alias: idle) Disk space in /tmp (Mbytes) Available swap space (Mbytes) (alias:swap) Available memory (Mbytes) Number of CPUs Number of local disks Maximum memory (Mbytes) Maximum swap space (Mbytes) Maximum /tmp space (Mbytes) CPU factor Remote execution priority LSF server host IRIX UNIX HP_UX Sun Solaris Compute server File server AIX UNIX Host type Host model Host status Host name 第7章 リソースの概要 R10K PENT200 IBM350 SunSparc HP735 HP715 14.00 6.00 7.00 6.00 9.00 5.00 lshosts lshosts コマンドを使用すると、特定のホストに定義されているリソースのリス トを参照できます。 % lshosts hostA HOST_NAME type hostA SOL732 model Ultra2 cpuf ncpus maxmem maxswp server RESOURCES 20.2 2 256M 679M Yes () ホストの負荷をリソースごとに参照する lshosts lshosts -s コマンドを使用すると、共有リソースごとにホスト負荷を参照できま す。 % lshosts -s RESOURCE VALUE tot_lic 5 tot_scratch 500 LOCATION host1 host2 host1 host2 上記の出力から、使用可能なライセンスが 5 つあり、共有スクラッチ ディレクト リの現在の容量が 500 MB であることがわかります。 VALUE の列はリソース量を示し、LOCATION 列はそのリソースを共有しているホ ストを示しています。lshosts -s コマンドでは静的共有リソースが表示され、 lsload -s コマンドでは動的共有リソースが表示されます。 Platform Clusterware 管理者 99 リソースの分類 リソースの分類 値に基づく分類 Boolean リソース 数値リソース ストリング リソー ス 値の変動性に基づく 分類 動的リソース 静的リソース 定義に基づく分類 構成リソース 組込みリソース 有効範囲に基づく分 類 ホスト ベース リ ソース 共有リソース ある特定の特性に該当しているかどうかを示すリソースで す。 値が数値のリソースです。負荷インデックス、ホストのプ ロセッサ数、ホストの CPU 係数などがあります。 値が文字列のリソースです。ホスト タイプ、ホスト モデ ル、ホスト状態などがあります。 値が動的に変化するリソースです。ホスト状態と負荷イン デックスは動的リソースです。 値が変化しないリソースです。ホスト状態と負荷インデッ クス以外のリソースは、すべて静的リソースです。 個々のサイトで定義するリソースです。外部負荷インデッ クスや lsf.shared(共有リソース)ファイルで定義するリ ソースは構成リソースです。 LSF であらかじめ定義されているリソースです。負荷イン デックス、CPU 数、合計スワップ容量などがあります。 複数のホストで共有するのではなく、ホストごとに使用す るリソースです。たとえば、スワップ容量、CPU、メモリ などがあります。これらのリソースは、該当するホストで 実行されるアプリケーションからしか使用できません。あ るホストでメモリが使い尽くされたとしても、他のホスト で使用可能なメモリは影響を受けません。 ホストごとに使用するのではなく、クラスタ全体で(また はクラスタ内の一部のホストの間で)共有するリソースで す。たとえば、浮動ライセンス、共有ファイル システムな どがあります。これらのリソースは、該当するリソースを 共有するように設定されているどのホスト上のアプリケー ションからも使用できます。ただし、使用した分だけ他の ホストから使用可能なリソース量が減ります。 Boolean リソース Boolean リソース(LSF サーバ ホストかどうかを示す server など)の値は、該当 するホストに対して定義されている場合は 1 になり、それ以外のホストに対して定 義されている場合は 0(ゼロ)になります。Boolean リソースは、ジョブの実行先 ホストを選択するときに使用されるホスト属性を設定するときに使用されます。た とえば、次のような場合に使用します。 ◆ ◆ ◆ 100 Platform Clusterware 管理者 ホスト タイプやオペレーティング システムのバージョンがマシンごとに異な る場合がある。 それぞれのマシンが別々の役割を果たしている場合がある。たとえば、ファイ ル サーバとして使用するマシンもあれば、演算サーバとして使用するマシンも ある。 一部のマシンに、特定のアプリケーションに必要な専用デバイスを搭載してい る場合がある。 第7章 リソースの概要 ソフトウェア パッケージやソフトウェア ライセンスの中には、一部のマシン でしか使用できないものがある。 ジョブのリソース要件選択条件文字列に Boolean リソースを指定すると、そのジョ ブを実行できるホストを限定することができます。たとえば、この文字列は次のよ うになります。 ◆ Platform Clusterware 管理者 101 リソースの分類 Boolean リソースには次のようなものがあります。 リソース名 内容 このリソース名の意味 cs fs solaris クラスタでの役割 クラスタでの役割 オペレーティング シス テム 使用可能なソフトウェ ア 演算サーバ ファイル サーバ Solaris オペレーティング システ ム FrameMaker ライセンス frame 共有リソース 共有リソースは、ホストごとに使用するのではなく、クラスタ全体またはクラスタ 内の一部のホスト間で共有する構成リソースです。たとえば、次のようなものがあ ります。 ソフトウェア パッケージの浮動ライセンス 複数のマシンからマウントしているファイル サーバ上のディスク スペース ホスト間の接続に使用している物理ネットワーク ◆ 共有リソースは、そのリソースを使用可能などのホスト上のアプリケーションから も使用できます。たとえば、クラスタ内の各ホストにローカル ディスクがあり、そ れらのホストからファイル サーバ上のディスクにもアクセスできるとします。その 場合は、ファイル サーバ上のディスクが共有リソース、ローカル ディスクがホス ト ベース リソースです。メモリ、スワップ容量といったホスト ベース リソースと は違って、あるマシンから共有リソースを使用すると、他のマシンから見たそのリ ソースの可用性が変化します。共有リソースの使用量の測定値は、クラスタ全体で 1 つしかありません。これに対して、ホスト ベース リソースの使用量はホストご とに測定されます。 ◆ ◆ LSF には、あらかじめ定義された共有リソースはありません。共有リソースは、す べて LSF 管理者が自分で定義する必要があります。このリソースは、動的リソース としても、静的リソースとしても定義できます。上記の例では、共有ディスクの総 容量は静的リソースとして、現在の空き容量は動的リソースとして定義できます。 さらに、共有リソースは数値リソース、ストリング リソース、Boolean リソースの どれにでもすることができます。 共有リソースには、次の使用上の制約があります。 ◆ ◆ 102 Platform Clusterware 管理者 lsf.cluster.cluster_name ファイル内の Hosts セクションで指定する 負荷しきい値としては使用できない。 lsb.queues ファイル内のキュー定義で指定する STOP_COND パラメータや RESUME_COND パラメータ、および loadSched/loadStop しきい値では使用 できない。 第7章 リソースの概要 ホストの共有リソースを参照する bhosts -s コマンドを実行すると、ホストで共有されるリソースを参照できます。 次のように使用します。 % bhosts -s RESOURCE tot_lic tot_scratch avail_lic avail_scratch TOTAL 5 00 2 100 RESERVED 0.0 0.0 3.0 400.0 LOCATION hostA hostB hostA hostB hostA hostB hostA hostB TOTAL 列には該当するリソースの量が表示されます。動的リソースについては、実 行中のジョブによって予約されているリソース量が RESERVED 列に表示されます。 Platform Clusterware 管理者 103 LSF でのリソースの使用 LSF でのリソースの使用 LSF に投入したジョブが実行されると、そのジョブで消費されるリソースが監視さ れます。リソース制限機能、負荷しきい値機能は、この情報に基づいて実行されま す。 LSF が収集する情報には、次のようなものがあります。 ジョブの全プロセスの合計 CPU 消費時間 ジョブの現時点で実行されている全プロセスの合計実メモリ使用量(KB) ジョブの現時点で実行されている全プロセスの合計仮想メモリ使用量(KB) ◆ ジョブの現時点でアクティブなプロセス グループの ID ◆ ジョブの現時点でアクティブなプロセス ◆ UNIX では、PIM(プロセス情報マネージャ)という特殊なプロセスを介してジョブ レベルの消費リソース量が収集されます。PIM は LSF によって内部的に管理されま す。 ◆ ◆ ジョブの消費リソース量を参照する -l オプションを付けた bjobs コマンドを使用すると、ジョブがその時点で消費し ているリソース量を参照できます。この情報は、PIM によって 30 秒おきに測定さ れます。sbatchd は、定期的に(lsb.params ファイル内の SBD_SLEEP_TIME パ ラメータで指定する秒間隔で)この情報を収集し、mbatchd に送出します。ただ し、実際にこの値が更新されるのは、CPU 時間、実メモリ使用量、仮想メモリ使用 量の直前の更新時からの変動率が 10% を超えた場合と、新しいプロセスやプロセス グループが作成された場合に限られます。 ホストの負荷を参照する -l オプションを付けた bhosts コマンドを使用すると、ホストの負荷レベルを チェックし、その情報に基づいてホストやキューの中断条件を必要に応じて修正で きます。このコマンドでは、ジョブのスケジューリングに使用されている最新の負 荷が表示されます。出力の中のダッシュ(-)は、該当するしきい値が定義されて いないことを示しています。 % bhosts -l hostB HOST: hostB STATUS CPUF JL/U MAX NJOBS RUN SSUSP USUSP RSV ok 20.00 2 2 0 0 0 0 0 CURRENT LOAD USED FOR SCHEDULING: r15s r1m r15m ut pg io Total 0.3 0.8 0.9 61% 3.8 72 Reserved 0.0 0.0 0.0 0% 0.0 0 LOAD THRESHOLD USED FOR r15s r1m loadSched loadStop - 104 Platform Clusterware 管理者 SCHEDULING: r15m ut pg - ls 26 0 io - t 0 0 ls - tmp 6M 0M it - swp mem 253M 297M 0M 0M tmp - swp - mem - 第7章 リソースの概要 負荷インデックス 負荷インデックスは、LSF クラスタ内のホストに搭載されている、共有されていな い動的リソースの可用性を表すための組込みリソースです。 LIM に組み込まれている負荷インデックスは、定期的に更新されます。 外部負荷インデックスは、LSF 管理者が定義 / 設定します。外部負荷情報マネージャ (ELIM)プログラムが指定された外部負荷インデックスの値を収集し、新しい値を 受け取ると LIM を更新します。 LIM が収集する負荷インデックス . インデッ クス 測定対象 状態 r15s r1m r15m ut pg ホストの状態 実行キュー長 実行キュー長 実行キュー長 CPU 使用率 ページング率 ls it swp mem tmp ログイン セッション数 アイドル時間 空きスワップ容量 空きメモリ容量 一時ファイル システムの空 き容量 ディスク I/O (lsload -l で表示 KB/ 秒 ) io nam e 単位 文字列 プロセス数 プロセス数 プロセス数 (パーセント) (ページイン + ペー ジアウト)/ 秒 ユーザ数 分 MB MB MB LSF 管理者が設定した外部負荷インデックス 方向 平均値の測 定時間 更新間隔 増加 増加 増加 増加 増加 15 秒 1分 15 分 1分 1分 15 15 15 15 15 15 増加 減少 減少 減少 減少 N/A N/A N/A N/A N/A 30 秒 30 秒 15 秒 15 秒 120 秒 増加 1分 15 秒 秒 秒 秒 秒 秒 秒 サイトで定 義 状態(status) 状態(status)は、ホストの現在の状態を示す文字列です。この状態は、LIM と RES の両方に当てはまります。 この値は次のいずれかになります。 状態(status) 説明 ok このホストは使用可能で、リモート ジョブを受け付けています。 LIM はリモート実行用にこのホストを選択できます。 -ok ホストの状態の前にダッシュ(-)が付いている場合、LIM は稼働中ですが、RES がそのホスト上で実行されていない か、または応答していません。 busy いずれかの負荷インデックスが設定されたしきい値を超えてい るため、このホストは過負荷(busy)状態になっています。し きい値を超えたインデックスにはアスタリスク(*)が付けられ ます。LIM は対話型ジョブ用としてこのホストを選択しません。 このホストは実行時間帯によってロックされています。lshosts コマンドを使用すると、実行時間帯を表示できます。 lockW Platform Clusterware 管理者 105 負荷インデックス 状態(status) 説明 lockU このホストは、LSF 管理者または root ユーザによってロックさ れています。 このホストがダウンしているか、ホスト上の LIM が実行されて いないか、応答しません。 このホストには有効なライセンスが割り当てられていません。 unavail unlicensed CPU 実行キュー長(r15s, r1m, r15m) r15s、r1m、r15m は、それぞれ直前の 15 秒間、1 分間、15 分間の CPU 実行キュー 長の平均値です。これらの期間に CPU を使用する平均プロセス数を表しています。 UNIX では、この値は uptime(1) コマンドから出力される平均負荷とは必ずしも 一致しません。一部のプラットフォームでは、このコマンドから出力される平均負 荷に、少しの間待機状態になっているプロセス数(ページングやディスク I/O など) も加えられるからです。 実行キューの実効長 マルチプロセッサ システムでは、同時に複数のプロセスを実行できます。そのた め、LSF にはユニプロセッサとマルチプロセッサの CPU 負荷を比較できるように、 マルチプロセッサ システムの実行キュー長を修正する機能があります。修正後の値 を「実行キューの実効長」と呼びます。 実行キューの実効長は、lsload -E コマンドで確認できます。 正規化実行キュー長 さらに、LSF にはプロセッサの相対的な処理速度(CPU 係数)に基づいて、実行 キュー長を修正する機能もあります。プロセッサ数と CPU 処理速度の両方を加味 して修正した値を、「正規化実行キュー長」と呼びます。正規化実行キュー長が小 さいホストほど、大量の CPU 処理能力が必要なジョブを高速に実行できます。 正規化実行キュー長は、lsload -N コマンドで確認できます。 CPU 使用率(ut) CPU 使用率(ut)は、システム コードやユーザ コードを実行するために消費され た CPU 時間の割合です。この値は、プロセスを 1 つも実行していないホストでは 0% になり、CPU が常時ビジー状態のホストでは 100% になります。 ページング率(pg) ページング率(pg)は、仮想メモリのページング率を秒当たりのページ数で表した ものです。この値は、使用可能な RAM 容量や、ホスト上で実行中のプロセスの合 計サイズと密接な関係があります。プロセスをすべて収容できるだけの RAM 容量 がないと、ページング率が高くなります。また、ページング率は対話型処理の応答 速度の目安にもなります。ページングが頻繁に発生するマシンでは、体感的な処理 速度が非常に遅くなります。 対話型アイドル時間(it) 対話型アイドル時間(it)は、ホスト上の対話型処理のアイドル時間を分単位の時 間で表したものです。この値は、直接接続されている端末や、ログイン セッション に対応しているネットワーク疑似端末での最後の入力または出力からの経過時間 です。Solaris システムと HP-UX システムを除けば、CAD アプリケーション、emacs ウィンドウといった X サーバから直接実行される処理は対話型処理には含まれま せん。 106 Platform Clusterware 管理者 第7章 リソースの概要 一時ディレクトリ(tmp) 一時ディレクトリ(tmp)は、一時ディレクトリの収容先のファイル システムの MB 単位の空き容量です。( UNIX では /tmp) スワップ容量(swp) スワップ容量(swp)は、MB 単位の空きスワップ容量です。この値は、該当する ホストでどの程度のサイズまでのプロセスを実行できるかを表しています。 メモリ容量(mem) メモリ容量(mem)は、ユーザ プロセスで現在使用可能な実メモリ容量です。この 値は、ページングを引き起こさずに、該当するホストでどの程度のサイズまでのプ ロセスを実行できるかを表しています。 LIM が使用可能な空きメモリ容量を報告し、LSF は物理メモリの空き容量、キャッ シュ メモリ、バッファ メモリ、および調整値を合計して、空きメモリ容量を計算 します。vmstat コマンドでも空きメモリ容量を表示できますが、これらの値が 別々に表示されます。ただし、オペレーティング システムによって仮想メモリの振 る舞いが異なるため、LIM によって報告されるメモリ容量と vmstat コマンドに よって報告されるメモリ容量が同じになるとは限りません。独自に ELIM を作成し、 LIM によって報告される空きメモリ容量を変更することができます。 I/O 率(io) I/O 率(io)は、このホストに直接接続されているディスクとの I/O スループット を、秒当たりの KB 数で表したものです。他のホストからマウントされているディ スクとの I/O は含みません。 Platform Clusterware 管理者 107 負荷インデックス 負荷インデックスの情報を参照する lsinfo -l lsinfo -l コマンドを使用すると、システム内の負荷インデックスに関する情報 がすべて表示されます。また、特定のインデックスに関する情報だけが表示される ように、コマンド行で負荷インデックスを指定することもできます。 % lsinfo -l swp RESOURCE_NAME: swp DESCRIPTION: Available swap space (Mbytes) (alias: swap) TYPE ORDER INTERVAL BUILTIN DYNAMIC RELEASE Numeric Dec 60 Yes Yes NO lsload -l lsload -l コマンドを使用すると、すべての負荷インデックスの値が表示されま す。外部負荷インデックスは LSF 管理者が設定します。 % lsload HOST_NAME hostN hostK hostF hostG hostV 108 status ok -ok busy busy unavail Platform Clusterware 管理者 r15s 0.0 0.0 0.1 *6.2 r1m 0.0 0.0 0.1 6.9 r15m 0.1 0.0 0.3 9.5 ut 1% 3% 7% 85% pg 0.0 0.0 *17 1.1 ls 1 3 6 30 it 224 0 0 0 tmp 43M 38M 9M 5M swp 67M 40M 23M 400M mem 3M 7M 28M 385M 第7章 リソースの概要 静的リソース 静的リソースは、ユーザ プロセスから使用可能な最大 RAM 容量、マシン上のプロ セッサ数のように、時間が経過しても変化しないホスト情報です。静的リソースの ほとんどは、起動時に LIM によって特定されます。起動時、または LSF がハード ウェア構成の変更を検出したときに、LIM によって特定されます。 静的リソースを使用すると、バイナリ アーキテクチャ、CPU の相対的な処理速度、 システム構成を考慮して、特定のジョブに適したホストを選択できます。 ncpus、maxmem、maxswp、maxtmp の各リソースは、ハードウェアの動的再構成 に対応した UNIX ホストでは静的ではありません。 LIM が報告する静的リソース インデック ス 測定対象 単位 特定手段 type model hname cpuf server ホスト タイプ ホスト モデル ホスト名 CPU 係数 リモート ジョブを実行可 能なホスト 実行優先順位(UNIX の み) プロセッサ数 ローカル ディスク数 ユーザが使用可能な最大 RAM 容量 最大スワップ容量 一時ファイル システムの 最大容量 文字列 文字列 文字列 相対値 論理値 構成情報 構成情報 構成情報 構成情報 構成情報 nice(2) の引数 構成情報 プロセッサ数 ディスク数 MB LIM LIM LIM MB MB LIM LIM rexpri ncpus ndisks maxmem maxswp maxtmp CPU 係数(cpuf) CPU 係数は、クラスタ内の他のホストに対する、該当するホストの相対的な CPU 処理速度です。あるプロセッサに別のプロセッサの 2 倍の処理速度があったとする と、その CPU 係数も 2 倍になります。この値は LSF 管理者が定義します。マルチ プロセッサ ホストの CPU 係数は、単一のプロセッサの処理速度で表します。LSF は、複数のプロセッサがあることを考慮して、そのホストの CPU 負荷を自動的に 換算します。 サーバ(server) サーバ(server)は論理値をとる静的リソースです。次のいずれかの値になります。 ◆ ◆ 1 の場合、そのホストは他のホストから投入されたジョブを実行するように設 定されている。 0 の場合、そのホストは他のホストにジョブを投入する LSF クライアントとし て設定されている。 Platform Clusterware 管理者 109 ハードウェア再構成の自動検出 ハードウェア再構成の自動検出 一部の UNIX オペレーティング システムは、ハードウェアの動的再構成に対応して います。 「ハードウェアの動的再構成」とは、ホストを再起動することなく、シス テムを稼働させたままシステム基板を脱着する機能です。 対応プラットフォーム LSF は、次のプラットフォームで ncpus、maxmem、maxswp、maxtmp の動的変更 を認識できます。 ◆ ◆ ◆ ◆ ◆ Sun Solaris 2.5+ HP-UX 10.10+ Compaq Alpha 5.0+ IBM AIX 4.0+ SGI IRIX 6.2+ ncpus の動的変更 ハードウェアの動的再構成に対応しているシステムでは、LSF は ncpus(プロセッ サ数)の変更を自動的に検出できます。 ローカル LIM は、2 分間隔でプロセッサ数が変更されたかどうかをチェックし、プ ロセッサ数が変更されている場合は、maxmem(最大メモリ容量)、maxswp(最大 スワップ容量)、maxtmp(最大一時スペース)についてもチェックを行い、新しい 情報をマスタ LIM に通知します。 maxmem、maxswp、maxtmp の動的変更 プロセッサ数は変更せず、maxmem(最大メモリ容量)、maxswp(最大スワップ容 量)、maxtmp(最 大 一 時 ス ペ ー ス)だ け を 動 的 に 変 更 し た 場 合 は、lsadmin limrestart コマンドでローカル LIM を再起動しないと、変更が認識されません。 プロセッサ数を変更した場合は、maxmem、maxswp、maxtmp の変更が自動的に認 識されます。プロセッサ数の変更が検出されると、ローカル LIM は maxmem、 maxswp、maxtmp についても変更が発生していないかどうかをチェックします。 ハードウェアの動的変更の LSF への反映 lsxxx コマンド lsxxx コマンドが変更を認識するまでに(たとえば lshosts コマンドの出力に変 更後の情報が反映されるまでに)、最大で 2 分の時間がかかります。 bxxx コマンド bxxx コマンドが変更を認識するまでに(たとえば bhosts -l コマンドの出力に 変更後の情報が反映されるまでに)、最大で(2 + 10)分の時間がかかります。 これは、MBD が 10 分間隔でマスタ LIM と通信するためです。 Platform ローカル クラスタの構成変更は、(2 × CACHE_INTERVAL) 秒間隔でマスタ LIM か MultiCluster ら リ モ ー ト ク ラ ス タ に 通 知 さ れ ま す。CACHE_INTERVAL パ ラ メ ー タ の 値 は、 lsf.cluster.cluster_name ファイル("c lu ste r_n a m e " はクラスタ名)で指定 します。このパラメータのデフォルト値は 60 秒です。 そ の た め、リ モ ー ト ク ラ ス タ が 変 更 を 認 識 す る ま で に、最 大 で 2 分 + (2 × CACHE_INTERVAL) 秒の時間がかかります。 110 Platform Clusterware 管理者 第7章 リソースの概要 ハードウェアの動的変更の LSF への影響 LSF は、ncpus、maxmem、maxswp、maxtmp の値に基づいて負荷を決定し、スケ ジューリングを行います。 また、LSF で使用されるライセンス数はプロセッサ数と関係しているため、プロセッ サを追加したり、取り除いたりすると、LSF のライセンス管理に影響が及びます。 いずれかのプロセッサをオフラインにすると、 ホストごと、キューごとの負荷しきい値に達しやすくなります。これは、CPU 数と相対的な CPU 速度をもとに、実行キューの実効長が算出されるためです。 CPU 実行キュー長(r15s、r1m、r15m)の値が増加します。 ◆ 負荷しきい値のためにジョブが中断されたり、ディスパッチされなかったりす ◆ る可能性があります。 プロセッサごとのジョブ スロット数制限(lsb.queues ファイルの ◆ PJOB_LIMIT パラメータ値)に達しやすくなります。 新しいプロセッサをオンラインにすると、 ◆ 負荷しきい値に達しにくくなります。 CPU 実行キュー長(r15s、r1m、r15m)の値が減少します。 負荷しきい値のために中断されているジョブを再開できるようになります。 ◆ プロセッサごとのジョブ スロット数制限(lsb.queues ファイルの PJOB_LIMIT パラメータ値)に達しにくくなります。 ◆ ◆ Platform Clusterware 管理者 111 ハードウェア再構成の自動検出 112 Platform Clusterware 管理者 第8章 リソースの追加 内容 ◆ ◆ ◆ ◆ 114 115 119 124 ページの「構成リソースとは」 ページの「クラスタに新しいリソースを追加する」 ページの「外部負荷インデックスと ELIM」 ページの「組込み負荷インデックスを修正する」 Platform Clusterware 管理者 113 構成リソースとは 構成リソースとは LSF では、使用可能なリソースに基づいてジョブをスケジューリングできます。多 数の組込みリソースがあらかじめ定義されていますが、この他にユーザ独自のリ ソースを追加することもできます。ユーザが追加したリソースは、LSF の組込みリ ソースと同じように使用できます。 この機能を最大限に活用するためには、ユーザ独自のリソースについても、その特 性を明確に定義し、正しい選択ができるようにする必要があります。たとえば、 Ethernet と FDDI の両方に接続しているマシンと、Ethernet だけに接続しているマ シンがあった場合を考えてみましょう。その場合は、fddi というリソースを定義 し、それを FDDI に接続しているマシンに関連付けます。このようにすると、ジョ ブを FDDI に接続しているマシンで実行したい場合に、fddi というリソース名を 使用して、そのことを指定できます。 114 Platform Clusterware 管理者 第8章 リソースの追加 クラスタに新しいリソースを追加する クラスタにホスト リソースを追加するには、次の手順に従います。 1 2 クラスタ内の任意のホストに LSF 管理者としてログオンします。 lsf.shared ファイルの Resource セクションで新しいリソースを定義しま す。少なくとも、lsinfo コマンドで表示されるリソース名と短い説明を指定 する必要があります。 詳細については、116 ページの「lsf.shared ファイルの Resource セクションを 設定する」を参照してください。 3 4 静的 Boolean リソースの場合は、lsf.cluster.cluster_name ファイルの Host セクションで、新しいリソースを備えるすべてのホストの RESOURCES 列 にリソース名を追加します。 共有リソースの場合は、新しいリソースを共有するすべてのホストについて、 リソースとホストを関連付けます。このセクションで非共有リソースを設定す る必要がある場合もあります。 詳細については、117 ページの 「lsf.cluster.cluster_name ファイルの ResourceMap セクションを設定する」を参照してください。 5 クラスタを再構成します。 Platform Clusterware 管理者 115 lsf.shared ファイルの Resource セクションを設定する lsf.shared ファイルの Resource セクションを設定する カスタム リソースは lsf.shared ファイルの Resource セクションで定義しま す。共有リソースと非共有リソースの定義方法に違いはありません。 少なくとも RESOURCENAME キーワードと DESCRIPTION キーワードを使用し、リ ソース名と説明情報を指定する必要があります。 ◆ ◆ 数字で始まるリソース名は指定できません。 リソース名には次の文字は使用できません。 : ◆ . ( ) [ + - * / ! & | < > @ = リソース名には次の予約語は使用できません。 cpu cpuf io logins ls idle maxmem maxswp maxtmp type model status it mem ncpus ndisks pg r15m r15s r1m swap swp tmp ut リソース名の大文字と小文字は区別されます。 リソース名の長さは 29 文字以内に制限されています。 ◆ リソース名と説明情報に加えて、次の情報も指定できます。 ◆ ◆ リソースの型(TYPE = Boolean | String | Numeric) デフォルト設定は Boolean です。 動的リソースの場合は秒単位の更新間隔(INTERVAL) 数値リソースの場合は大きい値が高い負荷を表しているかどうか ◆ (INCREASING =Y) 共有数値リソースの場合は、そのリソースを使用しているジョブが中断された ◆ ときにリソースを解放するかどうか(RELEASE = Y) これらの任意指定の属性を指定しなかった場合は、そのリソースは静的な Boolean リソースとして取り扱われます。 ◆ 例 Begin Resource RESOURCENAME TYPE INTERVAL mips Boolean () dec Boolean () scratch Numeric 30 synopsys Numeric 30 verilog Numeric 30 console String 30 End Resource 116 Platform Clusterware 管理者 INCREASING DESCRIPTION () (MIPS architecture) () (DECStation system) N (Shared scratch space on server) N (Floating licenses for Synopsys) N (Floating licenses for Verilog) N (User Logged in on console) 第8章 リソースの追加 lsf.cluster.cluster_name ファイルの ResourceMap セク ションを設定する lsf.cluster.cluster_name ファイルの ResourceMap セクションで、それぞれ のリソースを、そのリソースを使用可能なホストに関連付けます。 リソースごとに、リソース名とそのリソースを搭載しているホストを指定する必要 があります。 ResourceMap セクションを定義しなかった場合、lsf.shared ファイルで指定し たすべての動的リソースは、特定のホストには割り当てられず、クラスタ内の全ホ スト間で共有されます。 例 ここでは、host1、host2、host3 という 3 つのホストからなるクラスタを想定 しています。 Begin ResourceMap RESOURCENAME LOCATION verilog (5@[all ~host1 ~host2]) synopsys (2@[host1 host2] 2@[others]) console (1@[host1] 1@[host2]1@[host3]) xyz (1@[default]) End ResourceMap この例では、各リソースが次のように使用されます。 ◆ ◆ ◆ 5 単位の verilog リソースが host3 だけに(host1 と host2 を除くすべて のホストに)割り当てられます。 2 単位の synopsys リソースが host1 と host2 で共有され、もう 2 単位の synopsys リソースが host3 に(クラスタ内の残りのすべてのホストに)割 り当てられます。 クラスタ内の各ホストに、それぞれ 1 単位の console リソースが割り当てら れます(明示的な割り当て)。さらに、それらのホストにそれぞれ 1 単位の xyz リソースが割り当てられます(default キーワードによる割り当て)。 RESOURCENAME lsf.shared ファイルで定義したリソース名を指定します。 LOCATION リソースの種類(共有リソースまたは非共有リソース)、その割り当て先のホスト、 およびその初期値を指定します。 リソースには次の 3 とおりの使用方法があります。 ◆ ◆ ◆ クラスタ内のホストごとに使用する クラスタ内のすべてのホストで共有する 複数のインスタンスに分割し、それぞれのインスタンスを別々のホスト群で共 有する Platform Clusterware 管理者 117 lsf.cluster.cluster_name ファイルの ResourceMap セクションを設定する 構文 ([resource_value@][host_name... | all [~host_name]... | others | default] ...) ◆ ◆ ◆ ◆ ◆ ◆ 静的リソースの場合は、リソース量を示すリソース値を指定する必要がありま す。動的リソースの場合は、リソース値を指定しないでください。動的リソー スに関する情報は、ELIM によって更新されます。 上記のように、ホスト リストは [ ] で囲みます。ホスト リストを 1 組しか指定 しない場合は、一番外側の( )を省略できます。 [ ] で囲んだ個々のホスト リストは、リソースのインスタンスを表しています。 同じリソースの各インスタンスには、別々のホストを含める必要があります。 リソース値で指定したリソース量は、該当するインスタンスの中のすべてのホ ストで共有されます。 キーワード all は、クラスタ内のすべてのサーバ ホストを集合的に表してい ます。その中から特定のホストやホスト群を除外するには、否定演算子(~)を 使用します。 キーワード others は、明示しているホスト以外のすべてのホストを表してい ます。 キーワード default は、クラスタ内の各ホストを個別に表しています。 LSF Batch 以外の設定 LSF Base でのリソースの設定では、次のことに注意してください。 ◆ ◆ ◆ 118 Platform Clusterware 管理者 lsf.cluster.cluster_name ファイルでは、Host セクションの後に ResourceMap セクションを配置する必要があります。これは、ResourceMap セ クションで指定するホスト名を、Host セクションで定義しているためです。 静的 Boolean リソースを特定のホストに関連付けるには、 lsf.cluster.cluster_name ファイルの Host セクション内の RESOURCES 列を使用します。 ResourceMap セクションで指定したほとんどのリソースは、LSF コマンドで は共有リソースとみなされ、lsload -s コマンドや lshosts -s コマンドで 表示されます。ただし、次のリソースはこれに当てはまりません。 共有されない静的リソース ❖ ❖ default キーワードを使用して指定された動的数値リソース。これらはホ スト ベースのリソースで、mem や swap などの組込み負荷インデックスと 同 様 に 処 理 さ れ ま す。こ れ ら の リ ソ ー ス は、lsload -l コ マ ン ド や lsload -I コマンドを使用して参照できます。 第8章 リソースの追加 外部負荷インデックスと ELIM LSF 負荷情報マネージャ(LIM)は、ホスト上の CPU、メモリ、ディスク、I/O、対 話型処理の負荷を示す組込み負荷インデックスを収集されます。 ほとんどのジョブでは、組込み負荷インデックスを使用するだけで十分ですが、特 殊なワークロードやリソースの依存関係があるために、LSF 管理者が独自の外部負 荷インデックス を定義して設定する必要がある場合もあります。このような場合 は、組込み負荷インデックスと同様に、外部負荷インデックスからの負荷と共有リ ソースの情報をジョブのスケジューリングやホストの選択に使用できます。 設定された外部負荷インデックスの値を収集し、新しい値を受け取ると LIM を更新 する外部負荷情報マネージャ(ELIM)プログラムを記述できます。 ELIM は、短いスクリプトのような単純なものから、高度な C プログラムのような 複雑なものまで、さまざまな方法で作成できます。ELIM と LIM との情報のやり取 りには、あらかじめ定められたプロトコルを使用します。 ELIM 実行可能プログラムは、LSF_SERVERDIR に置く必要があります。 ◆ ◆ ◆ ◆ ◆ 119 120 120 121 123 ページの「LSF による複数の ELIM サポート」 ページの「アプリケーション固有の SELIM の設定」 ページの「ELIM による外部リソース情報の収集方法」 ページの「ELIM を作成する」 ページの「ELIM をデバッグする」 LSF による複数の ELIM サポート LSF の信頼性を高めるため、LSF Version 5.1 では、複数の ELIM 実行可能プログラ ムの設定がサポートされています。 マスタ ELIM マスタ ELIM(melim)は、LSF_SERVERDIR にインストールされます。 (melim) melim は、サイトで定義された複数のサブ ELIM(SELIM)を管理し、外部負荷情 報を LIM に報告します。melim には、次の機能があります。 ◆ ◆ ◆ ◆ SELIM を起動 / 停止する LIM に代わって負荷情報報告の構文をチェックする SELIM から報告された負荷情報を収集する 各 SELIM からの最新の有効な負荷レポートをマージし、マージされた負荷情報 を LIM に戻す ELIM の失敗 マスタ ELIM によって管理される複数のスレーブ ELIM は、LIM を保護することに よって信頼性が向上します。 ◆ ◆ ◆ ELIM 出力はバッファ処理される ELIM が不正なリソース フォーマットまたは値をチェックする SELIM は互いに独立している。負荷情報を待つ間ハングしている SELIM があっ ても、他の SELIM は影響を受けない エラー ログ MELIM は、自分自身の動作と日付をログ ファイル LSF_LOGDIR/melim.log.host_name に記録します。 Platform Clusterware 管理者 119 外部負荷インデックスと ELIM アプリケーション固有の SELIM の設定 マスタ ELIM は LSF_SERVERDIR/melim としてインストールされます。インス トール後、次のように操作します。 1 2 3 必要な外部リソースを定義します。 これらのリソースを追跡するためにアプリケーション固有の SELIM を記述し ます。詳細については、121 ページの「ELIM を作成する」を参照してください。 ELIM を LSF_SERVERIR に置きます。 ELIM 名の指定 次の命名規則を使用します。 ◆ UNIX では、LSF_SERVERDIR/elim.application のように命名する 例 : elim.license ◆ Window s では、LSF_SERVERDIR¥elim.application.[exe |bat] のよう に命名する 例 : elim.license.exe 既存の ELIM 既存の ELIM は、この命名規則に従う必要はなく、名前を変更する必要はありません。ただ し、melim は、この命名規則に従う ELIM を呼び出すため、ELIM のバックアップ コピーは、 LSF_SERVERDIR の外に移動するか、この命名規則に従わない名前にします。たとえば、 elim.bak の代わりに elim_bak を使用します。 予約済みの elim.user という名前は、以前の製品との互換性のために予約されています。アプリケー elim.user ション固有の elim には、elim.user という名前を使用しないでください。 ELIM による外部リソース情報の収集方法 静的な外部リソースの値は、lsf.cluster.cluster_name 構成ファイルで指定し ます。動的な外部リソースについては、それらが共有リソースかホスト ベース リ ソースかに関係なく、その値を ELIM で収集します。 ELIM の起動時期 ELIM は、次の場合に実行されます。 ◆ ◆ ◆ 120 Platform Clusterware 管理者 ホスト ベース リソースとして設定している外部動的リソースがある場合に、そ れぞれのホスト上で実行。たとえば、lsf.cluster.cluster_name ファイル の ResourceMap セクションで、LOCATION フィールドを ([default]) と設 定している場合は、それぞれのホストで ELIM が実行されます。 クラスタ全体で共有する外部リソースがある場合に、マスタ ホスト上で実行。 たとえば、lsf.cluster.cluster_name ファイルの ResourceMap セクション で、LOCATION フィールドを ([all]) と設定している場合は、マスタ ホスト 上で ELIM が実行されます。 クラスタの中で、外部リソースを複数のインスタンスに分割してホストに割り 当てている場合に、それぞれのインスタンスで最初に指定したホスト上で実行。 たとえば、lsf.cluster.cluster_name ファイルの ResourceMap セクショ ンで、LOCATION フィールドを ([hostA hostB hostC] [hostD hostE hostF]) と設定している場合は、hostA と hostD で ELIM が実行され、該当す るホスト グループで使用されるリソース量が報告されます。 第8章 リソースの追加 ELIM の実行先のホストがダウンした場合は、該当するインスタンスで次に使用 可能なホストで ELIM が実行されます。たとえば、上記の例で hostA が稼働を 停止したとすると、代わりに hostB で ELIM が実行されます。hostA が稼働を 再開した場合は、hostB 上の ELIM がシャットダウンされ、hostA 上の ELIM が 再起動されます。 報告するリソースの数がいくつあったとしても、ELIM はホストごとに 1 つずつし か実行できません。クラスタ全体のリソースの情報だけを収集する場合は、マスタ ホストだけで ELIM が実行されます。 環境変数 LIM が起動すると、ELIM 用の次の環境変数が設定されます。 ◆ ◆ LSF_MASTER: マスタ ホスト上の ELIM が呼び出されている場合だけ定義。それ 以外の場合は未定義。この変数を使用すると、クラスタ全体のリソースを報告 する必要があるかどうかを確認できます。マスタ ホスト以外のホスト上の ELIM は、この情報を報告する必要はありません。 LSF_RESOURCES: リソース名を空白文字で区切った形式で、ELIM から報告する 必要のあるリソースのリストを記録。ELIM の実行先のホストが、該当するリ ソースのインスタンスを共有している場合のみ、このリストにそのリソース名 が挿入されます。 ELIM を作成する ELIM は、実行可能なプログラムであれば何でもかまいません。インタプリタで解 釈されるスクリプトと、コンパイル済みのコードのどちらの形式でも ELIM を作成 できます。 ELIM の出力 ELIM では、標準出力に定期的に負荷更新文字列を出力することで、LIM に負荷情報 を報告します。この文字列では、インデックス数に続けて、インデックス名とイン デックス値のペアを記述します。この文字列の構文は次のとおりです。 number_indices [index_name index_value]... たとえば、この文字列は次のようになります。 3 tmp2 47.5 nio 344.0 licenses 5 この例では、tmp2、nio、licenses の 3 つのインデックスの値を、それぞれ 47.5、 344.0、5 と報告しています。インデックス値は、lsf.h ヘッダ ファイル内の INFINIT_LOAD と INFINIT_LOAD で定義した範囲内になければなりません。 ELIM を C プログラムとして実装した場合は、初期化時にそのプログラムから setbuf(3) を実行し、stdout にバッファを介さずに情報を出力できるようにす る必要があります。 ELIM では、負荷更新文字列全体が stdout に書き出されたことを確認する必要が あります。それには、ELIM を C プログラムとして実装した場合は printf(3s) の 戻り値を、シェル スクリプトとして実装した場合は /bin/echo(1) の戻り値を チェックします。負荷情報の書き出しが失敗した場合は、ELIM を終了する必要が あります。 それぞれの LIM は、負荷の更新情報を 15 秒おきにマスタ LIM に渡します。した がって、ELIM では最高で 15 秒に 1 回ずつ負荷更新文字列を書き出します。この文 字列を書き出す間隔は、外部負荷インデックスがどの程度頻繁に変動するかに応じ Platform Clusterware 管理者 121 外部負荷インデックスと ELIM て調整できます。たとえば、インデックス値が変動することがあまりなければ、値 が変化したことを検出したときだけ最新の値を書き出すことができます。LIM は、 新しい値を受け取るまでは古い値を使用し続けます。 ELIM の配置場所 ELIM の実行可能ファイルは、LSF_SERVERDIR に置く必要があります。 次の命名規則を使用します。 ◆ UNIX では、LSF_SERVERDIR/elim.application のように命名する 例 : elim.license ◆ Window s では、LSF_SERVERDIR¥elim.application.[exe |bat] のよう に命名する 例 : elim.license.exe 構成情報に従って何らかのリソースが ELIM によって収集される場合、LIM は、起 動時に自動的に ELIM を呼び出します。ELIM は、LIM と同じユーザ ID とファイル アクセス権で実行されます。 ELIM の再起動 ELIM が終了した場合は、LIM によってその ELIM が再起動されます。ただし、ELIM に重大なエラーが含まれていた場合の問題を回避するため、ELIM は最高でも 90 秒 に 1 回ずつしか再起動されません。また、LIM が強制終了された場合は、その LIM から ELIM に SIGTERM シグナルが送出されます。このシグナルを受け取った場合 は、ELIM は直ちに終了しなければなりません。 例 1 ELIM を作成します。 次のサンプル ELIM(LSF_SERVERDIR/elim.mysrc)では、myrsc リソース の値を 2 に設定しています。実際に作成する ELIM では、値を検索するための コマンドと設定する値は、必要に応じて変更してください。 #!/bin/sh while : do # set the value for resource "myrsc" val=2 # create an output string in the format: # number_indices index1_name index1_value... reportStr="1 myrsc $val" echo "$reportStr" # wait for 30 seconds before reporting again sleep 30 done 2 作成した ELIM をコマンド行から実行して、テストします。 % ./elim.myrsc 次のような出力が得られるはずです。 1 myrsc 2 3 4 122 Platform Clusterware 管理者 ELIM を LSF_SERVERDIR にコピーし、名前が elim.myrsrc になっていること を確認します。 lsf.shared ファイルに myrsc リソースを定義します。 第8章 リソースの追加 この例では、数値を受け入れられるように、リソースを Numeric 型として定義 しています。負荷が増えても値は増えません。 Begin Resource RESOURCENAME TYPE INTERVAL INCREASING DESCRIPTION myrsc Numeric 30 N (custom resource to trigger elim to start up) End Resource 5 lsf.cluster.cluster_name ファイルで、myrsc リソースをホストにマッ ピングします。この例では、このリソースを hostA 上にだけ配置します。 Begin ResourceMap RESOURCENAME myrsc End ResourceMap 6 7 HOST_NAME hostA status ok LOCATION [hostA] 次のコマンドを使用して LSF を再構成します。 ❖ lsadmin reconfig ❖ badmin reconfig lsload -l コマンドを使用して、リソースを表示します。次のように、新し いリソースとその値が表示されるはずです。 r15s 0.4 r1m r15m 0.4 0.4 ut pg io ls it tmp swp mem myrsc 0% 0.0 0 22 0 24M 26M 6M 2 その他の例 LSF_MISC/examples ディレクトリには、ELIM の他のサンプル コードも格納され ています。elim.c ファイルは C 言語で書かれた ELIM のサンプルです。これらの サンプルは、目的の負荷インデックスを収集できるように修正することができま す。 ELIM をデバッグする lsf.cluster.cluster_name のパラメータ セクションでパラメータ LSF_ELIM_DEBUG=y を指定し、LIM が ELIM から受け取ったすべての負荷情報を LIM のログ ファイルに記録します。 lsf.cluster.cluster_name のパラメータ セクションでパラメータ LSF_ELIM_BLOCKTIME=seconds を指定し、LIM が ELIM を再起動するまでの待 ち時間を設定します。 lsf.cluster.cluster_name のパラメータ セクションでパラメータ LSF_ELIM_RESTARTS=integer を指定し、ELIM の再起動回数を制限します。 これらのパラメータの詳細については、 『Pla tfo rm LSF Re fe re n c e 』を参照してくださ い。 Platform Clusterware 管理者 123 組込み負荷インデックスを修正する 組込み負荷インデックスを修正する ELIM では、組込み負荷インデックスの値を報告することもできます。その場合は、 ELIM が報告した値によって、LIM が収集した値が上書きされます。 考慮点 ◆ ◆ ◆ ELIM から組込み負荷インデックスの値を報告する場合は、その意味が lsinfo(1) コマンドで表示されるものと同じになるように注意してくださ い。 ELIM で使用する外部負荷インデックス名には、組込みリソースの別名(cpu、 idle、logins、swap のいずれか)は使用できません。これらのインデック スを上書きするには、その正式名(r1m、it、ls、swp)を使用します。 組込み負荷インデックスを上書きする場合も、外部負荷インデックスを設定す る必要があります。 手順 一時ディレクトリとして /usr/tmp を使用しているサイトがあるとします。 tmp 負荷インデックスを変更するには、次の作業を行います。 1 /usr/tmp ファイル システムの容量を定期的に測定し、その値を標準出力に書 き出すプログラムを作成します。フォーマットの詳細については、121 ページ の「ELIM を作成する」を参照してください。 この例では、プログラムの標準出力は次のようになります。 1 tmp 47.5 2 このプログラムに elim という名前を付けて、LSF_SERVERDIR ディレクトリに 保存します。 デフォルトの負荷インデックスは、すべてローカル リソースなので、elim は 個々のマシンでローカルに実行する必要があります。 3 リソースを定義します。 組込負荷インデックスの名前は、lsf.shared ファイルに使用できないので、elim を開始するために独自のリソースを定義します。 たとえば、次のように指定します。 Begin Resource RESOURCENAME TYPE INTERVAL INCREASING DESCRIPTION my_tmp Numeric 30 N (custom resource to trigger elim to start up) End Resource 4 lsf.cluster.cluster_name ファイルで、定義したリソースをホストに マッピングします。 各ホスト上の tmp 負荷インデックスを指定変更するには、default キー ❖ ワードを指定します。 Begin ResourceMap RESOURCENAME my_tmp End ResourceMap 124 Platform Clusterware 管理者 LOCATION [default] 第8章 リソースの追加 ❖ 特定のホスト上でのみ tmp 負荷インデックスを指定変更するには、該当す るホスト名を指定します。 Begin ResourceMap RESOURCENAME my_tmp End ResourceMap LOCATION ([host1][host2][host3]) Platform Clusterware 管理者 125 組込み負荷インデックスを修正する 126 Platform Clusterware 管理者 第 III 部 スケジューリング ポリシー 内容 ◆ ◆ 第 9 章、「時間の構文と構成」 第 10 章、「リソース要件の指定」 第9章 時間の構文と構成 内容 ◆ ◆ 130 ページの「時刻の指定」 131 ページの「時間帯の指定」 Platform Clusterware 管理者 129 時刻の指定 時刻の指定 時刻、すなわち特定の時点を指定するには、曜日、時間、分を指定します。このう ち、時間の指定は必須です。曜日と分の指定は省略できます。 時刻の構文 time = hour | hour:minute | day:hour:minute hour 時間(X 時 X 分の「時」)を 0 ~ 23 の整数で指定します。 minute 分(X 時 X 分の「分」)を 0 ~ 59 の整数で指定します。 この値を省略した場合は、正時(:00)が指定されたとみなされます。 day 曜日を 0(日曜日)~ 6(土曜日)の整数で指定します。 この値を省略した場合は、毎日と解釈されます。また、この値を指定した場合は、 分の指定が必須になります。 130 Platform Clusterware 管理者 第9章 時間の構文と構成 時間帯の指定 時間帯を指定するには、次のように 2 つの時刻をハイフン(-)で連結します。 time_window = time1-time2 time1 では時間帯の開始時刻を、time2 では時間帯の終了時刻をそれぞれ指定しま す。両方の時刻を同じ構文で指定する必要があります。したがって、時間帯を指定 するには次の 3 とおりの方法があります。 ◆ ◆ ◆ h o u r -h o u r h o u r :m in u te -h o u r :m in u te d a y :h o u r :m in u te -d a y :h o u r :m in u te 時間帯の指定例 毎日 毎日の一定の時間帯を指定するには day フィールドを省略します。すなわち、 hour-hour または hour:minute-hour:minute の構文を使用します。たとえ ば、毎日の AM 8:30 ~ PM 6:30 を指定するには次のようにします。 8:30-18:30 夜間 日付をまたいだ夜間の時間帯を指定するには、time1 を time2 より大きくします。 たとえば、PM 6:30 から翌日の AM 8:30 までを指定するには、次のようにします。 18:30-8:30 週末 数日間の週末を指定するには day フィールドを使用します。たとえば、金曜日の PM 6:30 から月曜日の AM 8:30 までを指定するには、次のようにします。 5:18:30-1:8:30 Platform Clusterware 管理者 131 時間帯の指定 132 Platform Clusterware 管理者 第 10 章 リソース要件の指定 内容 ◆ ◆ ◆ ◆ ◆ ◆ 134 135 137 138 140 142 ページの「リソース要件とは」 ページの「キュー レベルのリソース要件」 ページの「ジョブ レベルのリソース要件」 ページの「リソース要件文字列とは」 ページの「select 文字列」 ページの「order 文字列」 Platform Clusterware 管理者 133 リソース要件とは リソース要件とは リソース要件によって、ジョブを実行できるホストが決定されます。ジョブにはそ れぞれのリソース要件があり、その要件を満たしているホストだけが、そのジョブ を実行可能な候補ホストになります。LSF によるジョブのスケジューリングでは、 これらの候補ホストの負荷インデックス値がスケジューリング条件と比較され、こ れらのホストのうち、スケジューリングしきい値を超えている負荷値が 1 つもない ホストにジョブがディスパッチされます。 LSF のデフォルトの動作では、リソース要件が指定されていないジョブは投入する ホストとホスト タイプが同一のホストに配置されます(i.e., type==any)。これに 対して、ジョブに文字列または Boolean リソース要件が指定され、ホスト タイプ は指定されていない場合、そのジョブはリソース要件を満たす任意のホスト(すな わち type==any)に配置されます。 このデフォルトの動作を無効にするには、リソース要件を明示的に指定する必要が あります。リソース要件にはキューごとに指定するもの、アプリケーションごとに 指定するもの、ジョブごとに指定するものの 3 種類があり、それらを組み合わせる ことができます。 ジョブの実行先のホストを適切に決定するには、アプリケーションごとにリソース 要件を指定すると便利です。このようにすると、ジョブを投入するたびにリソース 要件を指定する必要がなくなります。これらのリソース要件は、LSF 管理者が指定 する場合もあれば、ユーザが各自のリモート タスク リストでタスク名と共に指定 する場合もあります。 bsub コマンドでジョブを投入すると、そのジョブのリソース要件がリモート タス ク リストから自動的に検出されます。 リソース要件は、リソース名と演算子を使用した式の形式で指定します。 134 Platform Clusterware 管理者 第 10 章 リソース要件の指定 キュー レベルのリソース要件 キューで指定したリソース要件は、該当するキューに収容されているすべてのジョ ブに適用されます。このキュー レベルのリソース要件は、そのキューに含まれてい るジョブに共通のジョブ スケジューリング条件としても使用できます。 ジョブ レベルのリソース要件を指定しなかった場合は、キュー レベルのリソース 要件が該当するジョブのデフォルトのリソース要件になります。 構文 ジョブのホストへのディスパッチ条件を指定するには、キュー レベルの RES_REQ パラメータを使用します。このパラメータは、lsb.queues ファイル内のキュー定 義で指定します。 例 RES_REQ=select[((type==ALPHA && r1m < 2.0)||(type==HPPA && r1m < 1.0))] ALPHA ホストと HPPA ホストをディスパッチ先として使用可能なキューで、これ らのホスト タイプごとに別々のしきい値を割り当てています。 RES_REQ=select[((hname==hostA && mem > 50)||(hname==hostB && mem > 100))] リソース要件の中で hname というリソース名を使用すると、ディスパッチ先のホ ストごとに別々の条件を指定できます。 負荷しきい値 LSF 管理者は、負荷しきい値を指定することで、キュー内のジョブのスケジューリ ングを制御できます。負荷しきい値には 2 種類あります。 loadSched 保留中のジョブをディスパッチする負荷条件を指定するスケジューリングしきい 値です。いずれかの負荷インデックス値が loadSched に定義されている値を超え ているホストでは、ジョブは開始されません。このしきい値は、中断中のジョブを 再開する条件としても使用されます。 loadStop 実行中のジョブを中断する条件です。 これらのしきい値は、キューごとやホストごとに、またはその両方で指定できます。 ホストにジョブをスケジューリングするには、そのホストの負荷レベルが、該当す るホストのしきい値とジョブのディスパッチ元のキューのしきい値の両方に適合 していなければなりません。 負荷インデックスには、負荷が高くなるほど数値が大きくなるものと、逆に負荷が 高くなるほど数値が小さくなるものがあります。したがって、ホストの負荷レベル としきい値を比較する際には、使用する負荷インデックスに応じて比較演算子、す なわち '>' ( ~より大きい ) や '<' ( ~より小さい ) を使用する必要があります。 中断条件の詳細と負荷しきい値の設定方法については、第 18 章、「負荷しきい値」 を参照してください。 キュー レベルのリソース要件の参照 bqueues -l を使用すると、キューに定義されているリソース要件(RES_REQ)を 表示できます。 Platform Clusterware 管理者 135 キュー レベルのリソース要件 % bqueues -l normal QUEUE: normal -- No description provided. ... ... RES_REQ: select[type==any] ... ... 136 Platform Clusterware 管理者 This is the default queue. 第 10 章 リソース要件の指定 ジョブ レベルのリソース要件 リソース要件をジョブごとに指定することもできます。このジョブ レベルのリソー ス要件は、リモート タスク リストで指定したリソース要件よりも優先されます。 キュー レベルのリソース要件を使用して、特定のリソースの上限値や下限値を設定 している場合は、その範囲外のジョブは拒否されてしまいます。 構文 ジョブのリソース要件を指定するには、bsub -R コマンドを使用します。リソー ス要件の指定方法は今までのものと同じです。 例 % bsub -R "swp > 15 && hpux order[cpu]" myjob myjob というジョブを、負荷が軽く(CPU 使用率が低く)、かつ使用可能なスワッ プ メモリが 15 MB 以上の HP-UX ホストで実行します。 ジョブ レベルのリソース要件の参照 bjobs -l を使用すると、ジョブに定義されているリソース要件を表示できます。 % bsub -R type==any -q normal myjob Job <2533> is submitted to queue <normal>. % bjobs -l 2533 Job <2533>, User <user1>, Project <default>, Status <DONE>, Queue <normal>, Command <myjob> Fri May 10 17:21:26: Submitted from host <hostA>, CWD <$HOME>, Requested Resources <type==any>; Fri May 10 17:21:31: Started on <hostB>, Execution Home </home/user1>,Execution CWD </home/user1>; Fri May 10 17:21:47: Done successfully. The CPU time used is 0.3 seconds. ... ジョブが終了したら、bhist -l を使用して、ジョブに定義されたリソース要件を 表示できます。 % bhist -l 2533 Job <2533>, User <user1>, Project <default>, Command <myjob> Fri May 10 17:21:26: Submitted from host <hostA>, to Queue <normal>, CWD <$HOME>, Requested Resources <type==any>; Fri May 10 17:21:31: Dispatched to <hostB>; Fri May 10 17:21:32: Starting (Pid 1850232); Fri May 10 17:21:33: Running with execution home </home/user1>, Execution CWD </home/user1>, Execution Pid <1850232>; Fri May 10 17:21:45: Done successfully. The CPU time used is 0.3 seconds; ... Platform Clusterware 管理者 137 リソース要件文字列とは リソース要件文字列とは LSF のほとんどのコマンドでは、-R res_req オプションでリソース要件を指定で きます。ただし、その使われ方はコマンドによって異なります。たとえば、lsload コマンドでリソース要件を指定した場合は、該当するリソースを備えているホスト の負荷レベルが表示されます。 また、lsrun コマンドでリソース要件を指定した場合は、該当するリソースを備え ているホスト群の中から、実行に最適なホストが選択されます。 リソース要件文字列は、ジョブに必要なリソースを記述したものです。LSF は、こ の文字列で指定されたリソース要件に基づいて、リモート実行用のホストやジョブ の実行先のホストを選択します。 リソース要件文字列セクション ◆ ◆ select セクション。ホストの選択条件を指定します。 order セクション。選択条件に適合しているホストのソート方法を指定しま す。 適用されるセクショ 使用するコマンドに応じて、これらのうちの 1 つ以上のセクションを指定できま ン す。たとえば、次のように指定します。 ◆ ◆ ◆ ◆ bsub コマンドでは 4 つのセクションをすべて指定できます。 lshosts コマンドでは、ホストの選択はできますが、ソートはできません。 lsload コマンドでは、ホストの選択とソートの両方が可能です。 lsplace コマンドは、select と order の各セクションの情報に基づいて、 タスクに適したホストを選択します。 構文 select[selection_string] order[order_string] 角括弧は示されているとおりに入力してください。 セクション名は、select と order です。コマンドに適用されないセクションは 無視されます。 セクション名を省略した場合は、文字列全体が select セクションとして取り扱わ れます。また、リソース要件の先頭で select セクションを記述する場合は、 select キーワードを省略できます。 使用する構文は、セクションごとに別々になります。 138 Platform Clusterware 管理者 第 10 章 リソース要件の指定 キュー レベルの要件とジョブ レベルの要件の解決方法 キュー レベルのリソース要件に加えて、ジョブ レベルのリソース要件も指定した 場合は、次のように処理されます。 ◆ ◆ ジョブをディスパッチするには、select 文字列のホスト名がキュー レベルと ジョブ レベルの両方の要件を満たしている必要があります。 キュー レベルとジョブ レベルで異なる order 要件を指定した場合、キュー レ ベルで定義した order セクションは無視されます。デフォルトの order 文字 列は r15s:pg です。 注意 : span と same は、Platform Computing から LSF スケジューリング プラグインで提供され ています。 Platform Clusterware 管理者 139 select 文字列 select 文字列 select 文字列では、ホストの選択条件(どのようなホストをリソース要件に適合し ているとみなすか)をリソース名を使用した論理式で指定します。select 文字列は ホストごとに評価されます。その結果が 0(ゼロ)でなければ、そのホストが選択 されます。 構文 select 文字列は、リソース名、論理演算子、算術演算子を組み合わせて指定できま す。0(ゼロ)以外の数値は TRUE として、0(ゼロ)は FALSE として解釈されま す。Boolean リソース(LSF サーバ ホストかどうかを示す server など)では、該 当するホストに対して定義されている場合は値が 1 になり、それ以外のホストに対 して定義されている場合は値が 0(ゼロ)になります。 select 文字列では、swp、it、ls、r1m の各リソースの別名として、swap、idle、 logins、cpu を使用できます。 ut では、CPU 使用率のパーセンテージを 0 ~ 100 の正数で指定します。 type と model の 2 つのリソースについては、any と local という特殊な値を指 定できます。any は任意の値、local はローカル ホストと同じ値を表しています。 たとえば、type==local と指定すると、ジョブの投入元のホストとホスト タイプ が 同 じ ホ ス ト が 選 択 さ れ ま す。ジ ョ ブ が ど の ホ ス ト で も 実 行 可 能 な 場 合 は、 type==any と指定します。 type を指定しなかった場合は、コマンドごとに別々のデフォルト設定が使用され ます。lshosts、lsload、lsmon、lslogin の各コマンドでは、デフォルト設定 は type==any になります。これに対して、lsplace、lsrun、lsgrun、bsub の 各コマンドでは、model や Boolean リソースを指定している場合はデフォルト設定 が type==any に、それ以外の場合はデフォルト設定が type==local になりま す。 演算子 select 文字列では演算子を使用できます。指定可能な演算子を優先順位の高い順に 並べたリストを次に示します。 140 Platform Clusterware 管理者 構文 意味 -a !a a *b a /b a +b a-b a >b a <b a >= b a <= b a == b a != b a && b a || b a の負数 論理否定(a==0 であれば 1、そうでなければ 0) a に b を掛ける a を b で割る a に b を足す a から b を引く a が b より大きければ 1、そうでなければ 0 a が b より小さければ 1、そうでなければ 0 a が b 以上であれば 1、そうでなければ 0 a が b 以下であれば 1、そうでなければ 0 a が b と等しければ 1、そうでなければ 0 a が b と等しくなければ 1、そうでなければ 0 論理積(a と b の両方がゼロでなければ 1、そうでなければ 0) 論理和(a と b のどちらかがゼロでなければ 1、そうでなければ 0) 第 10 章 リソース要件の指定 例 select[(swp > 50 && type == MIPS) || (swp > 35 && type == ALPHA)] select[((2*r15s + 3*r1m + r15m) / 6 < 1.0) && !fs && (cpuf > 4.0)] defined キーワードで共有リソースを指定する リソース要件文字列では、どの LSF コマンドで使用するものでも共有リソースを指 定できます。たとえば、所定の容量の共有スクラッチ領域が必要なジョブは、次の ようなコマンドで投入できます。 % bsub -R "avail_scratch > 200 && swap > 50" myjob この例は、クラスタ内のすべてのホストから共有スクラッチ領域にアクセスできる ことを前提としています。このジョブは、avail_scratch リソースの値が 200 MB を超えている場合だけスケジューリングされ、50 MB を超える空きスワップ容量の あるホストで実行されます。 システムによっては、クラスタ内の一部のホストからしか共有スクラッチ領域にア クセスできない場合があります。リソース要件文字列で "defined(resource_name)" という構文を使用すると、共有リソースにアクセス できないホストを選択の対象から除外できます。 たとえば、次のように指定します。 % bsub -R "defined(avail_scratch) && avail_scratch > 100 && swap > 100" myjob この例では、共有スクラッチ領域にアクセスできないホストを選択の対象から除外 しています。特定の共有リソースにどのホストからアクセスできるかは、LSF 管理 者が設定します。 Platform Clusterware 管理者 141 order 文字列 order 文字列 order 文字列を使用すると、select 文字列で選択したホストを、リソースの値を基準 にしてソートできます。r15s、r1m、r15m の各リソースについては、( lsload N コマンドで表示される ) 正規化後の負荷インデックス値がソート基準として使用 されます。 order 文字列は、ホストをソートしてから選択したい場合に使用します。ソート処 理は、order 文字列の右端のインデックスから順に実行されます。各ホストはそれ ぞれのインデックスを基準にしてソートされ、要求されているものより多くのホス トがある場合は、ソート後の順番が後ろのものが取り除かれます。残されたホスト は、次のインデックスを基準にして再びソートされます。 order 文字列の左端のインデックスを基準にしたソートが終了すると、各ホストの status 情報に従って最終的なソートが行われ、負荷共有に使用できないホスト(ok 状態ではないホスト)が後ろに移されます。 インデックスごとにソートがやり直されるため、ホストの最終的な順番に影響する のは、ホストの status 情報と order 文字列の左端のインデックスだけです。それ以 外のインデックスは、望ましくないホストを取り除くためだけに使用されます。 それぞれのインデックスを基準にしたソートで、昇順と降順のどちらでソートが行 われるかは、( lsinfo コマンドで表示される ) 該当するインデックスの order 情報 に基づいて決定されます。特に指定しない限り、そのインデックスの観点から見て、 ホストが望ましい順に並ぶようにソート順が決められます。 構文 [-]resource_name [:[-]resource_name]... どの動的リソース、静的リソース、外部負荷インデックスでも指定できます。 インデックス名の先頭にマイナス記号(-)を付けるとソート順が逆になり、該当す るインデックスの観点から見て望ましくない順にホストが並べられます。 デフォルト設定 デ フ ォ ル ト の orde r 文 字 列 は r15s:pg で す(た だ し、lslogin(1) の 場 合 は ls:r1m になります)。 例 swp:r1m:tmp:r15s 142 Platform Clusterware 管理者 第 IV 部 ジョブのスケジューリングとディス パッチ 内容 ◆ ◆ ◆ ◆ ◆ ◆ 第 第 第 第 第 第 11 12 13 14 15 16 章、「ディスパッチ時間帯と実行時間帯」 章、「ジョブの依存性」 章、「ジョブの優先順位」 章、「ジョブのキューへの再登録と再実行」 章、「ジョブのチェックポイント、再起動、移行」 章、「ジョブ配列」 第 11 章 ディスパッチ時間帯と実行時間帯 内容 ◆ ◆ ◆ 146 ページの「ディスパッチ時間帯と実行時間帯」 147 ページの「実行時間帯」 148 ページの「ディスパッチ時間帯」 Platform Clusterware 管理者 145 ディスパッチ時間帯と実行時間帯 ディスパッチ時間帯と実行時間帯 ディスパッチ時間帯と実行時間帯は、両方とも LSF のジョブをいつ開始 / 実行でき るかに関係しています。 ◆ ◆ ◆ ◆ ◆ 146 Platform Clusterware 管理者 lsb.hosts ファイルではディスパッチ時間帯を、lsb.queues ファイルでは ディスパッチ時間帯と実行時間帯の両方を定義できます。 ホストにはディスパッチ時間帯しかありませんが、キューにはディスパッチ時 間帯と実行時間帯の両方があります。 ディスパッチ時間帯はジョブの開始に影響し、実行時間帯はジョブの開始と中 断の両方に影響します。 ディスパッチ時間帯は、ホストやキューをいつオープン /クローズするかを定義 したものです。ホストやキューがクローズ状態のときは、新しいジョブの受け 入れはできません。LSF は、そのホストやキューにはジョブを配置できません。 実行時間帯は、ジョブがいつ実行可能で、いつ実行不可能かを定めたものです。 実行時間帯が過ぎると、該当するキューに収容されているジョブを開始できな くなります。また、このキューからディスパッチされ、すでに実行中のジョブ はすべて中断されます。 ディスパッチ時間帯が過ぎても、実行中のジョブは終了するまで続行されます が、該当するホストやキューには新しいジョブを送出できなくなります。実行 時間帯が過ぎると、実行中のジョブは中断されますが、新しいジョブは引き続 き該当するキューに送出できます。 第 11 章 ディスパッチ時間帯と実行時間帯 実行時間帯 キューでは実行時間帯を設定できます。実行時間帯とは、そのキューに含まれてい るジョブを実行可能な時間帯を指定したものです。実行時間帯を設定すると、その 時間帯以外はジョブの実行が不可能になります。 キューにはいつでもジョブを投入できます。実行時間帯が過ぎている場合は、これ らのジョブは再び実行時間帯になるまで保留されます。実行時間帯になっている場 合は、これらのジョブは通常どおりディスパッチされます。実行時間帯が過ぎると、 実行中のジョブは中断され、保留中のジョブは保留されたままになります。中断さ れたジョブは、再び実行時間帯になったときに再開されます。 実行時間帯を設定する 実行時間帯を設定するには、lsb.queues ファイルで RUN_WINDOW パラメータ を指定します。 たとえば、AM 4:30 から正午までを実行時間帯として設定するには次のようにしま す。 RUN_WINDOW = 4:30-12:00 このパラメータでは複数の時間帯を指定できます。 時間帯の構文については、131 ページの「時間帯の指定」を参照してください。 実行時間帯の情報を参照する キューの実行時間帯についての情報を参照するには、bqueues -l コマンドを使用 します。 Platform Clusterware 管理者 147 ディスパッチ時間帯 ディスパッチ時間帯 キューやホストではディスパッチ時間帯を設定できます。キューのディスパッチ時 間帯は、そのキューからジョブをディスパッチ可能な時間帯です。また、ホストの ディスパッチ時間帯は、そのホストでジョブを受け入れ可能な時間帯です。 ディスパッチ時間帯を設定した場合は、その時間帯以外はジョブのディスパッチが できません。デフォルト設定では、ディスパッチ時間帯は設定されていません(常 時ディスパッチできます)。 ディスパッチ時間帯は、すでに実行先のホストにディスパッチされているジョブに は影響しません。これらのジョブは、キューの実行時間帯の条件が満たされている 限り実行できます。 キュー レベル キューごとにディスパッチ時間帯を設定できます。それぞれのキューからは、この 時間帯だけジョブをディスパッチできます。 キューにはいつでもジョブを投入できます。キューのディスパッチ時間帯が過ぎて いる場合は、これらのジョブは再びディスパッチ時間帯になるまで保留されます。 ホスト レベル ホストごとにディスパッチ時間帯を設定できます。それぞれのホストは、この時間 帯だけジョブを受け入れることができます。 ディスパッチ時間帯を設定する ディスパッチ時間帯は、キューとホストの両方で定義できます。デフォルト設定で は、この時間帯の制限はありません(常時ディスパッチできます)。 ファイルで ホストのディスパッ ホ ス ト の デ ィ ス パ ッ チ 時 間 帯 を 設 定 す る に は、l s b . h o s t s チ時間帯 DISPATCH_WINDOW パラメータを設定し、1 つ以上の時間帯を指定します。この 時間帯を 1 つも指定しなかった場合は、常時ディスパッチ可能になります。 ファイルで キューのディスパッ キ ュ ー の デ ィ ス パ ッ チ 時 間 帯 を 設 定 す る に は、l s b . q u e u e s チ時間帯 DISPATCH_WINDOW パラメータを設定し、1 つ以上の時間帯を指定します。この 時間帯を 1 つも指定しなかった場合は、常時ディスパッチ可能になります。 ディスパッチ時間帯を表示する ホストのディスパッ ホストのディスパッチ時間帯を表示するには、bhosts -l コマンドを使用します。 チ時間帯 キューのディスパッ キューのディスパッチ時間帯を表示するには、bqueues -l コマンドを使用しま チ時間帯 す。 148 Platform Clusterware 管理者 第 12 章 ジョブの依存性 内容 ◆ ◆ 150 ページの「ジョブ依存スケジューリング」 151 ページの「依存条件」 Platform Clusterware 管理者 149 ジョブ依存スケジューリング ジョブ依存スケジューリング ジョブ依存スケジューリングとは 状況によっては、あるジョブの結果に応じて他のジョブを開始するかどうかを決定 したい場合があります。たとえば、一連のジョブを使用して、入力データを処理し、 シミュレーションを実行し、その結果に基づいて画像を生成し、生成した画像を高 解像度フィルム出力装置に記録する場合を考えてみましょう。それぞれの工程は、 先行する工程が終了しないと開始できず、ある工程が異常終了した場合は、それ以 降の工程をすべて破棄しなければなりません。 ジョブによっては、後処理が行われるまでは終了したとはみなせない場合がありま す。たとえば、ジョブの終了後に、実行後ジョブ スクリプトを介してジョブを終了 させたり、ジョブ ファイルのクリーン アップを行ったり、出力を転送したりする 場合があります。 LSF では、あらゆるジョブを他のジョブに依存させることができます。それには、 bsub コマンドでジョブを投入するときに、-w オプションを使用して依存式を指定 します。この依存式では、通常は先行するジョブの状態に基づいた依存条件を指定 します。 この依存式の評価結果が TRUE にならない限り、投入したジョブはディスパッチさ れません。依存式で、LSF から検出できないジョブ(まだ投入されていないジョブ など)に対する依存性を指定した場合は、ジョブの投入そのものが拒否されます。 ジョブの依存性を指定する ジョブの依存性を指定するには、bsub コマンドの -w オプションで、ジョブの依 存式を指定します。 構文 bsub -w 'd e pe n d e n c y _e xpre ssio n ' 依存式は、1 つ以上の依存条件からなる論理式です。個々の依存条件の構文につい ては、151 ページの「依存条件」を参照してください。 複数の依存条件からなる依存式を指定する場合は、次の論理演算子を使用します。 && (AND) || (OR) ! (NOT) ❖ 必要であれば、( ) を使用して演算の順序を指定できます。 特殊文字(空白文字、論理演算子、括弧)を使用する場合は、それらがシェル によって解釈されないように、依存式を一重引用符(')で囲みます。その場合 は、依存式の中の引用符が必要な項目(ジョブ名など)は二重引用符(")で囲 みます。 LSF 管理者以外のユーザは、他人のジョブのジョブ名は指定できません。 数字で始まるジョブ名は二重引用符(")で囲みます。 ジョブ名の指定では、文字列の末尾にワイルドカード文字(*)を付けて、名前 がその文字列で始まるすべてのジョブを指定できます。たとえば、jobA* とい うジョブ名は、jobA、jobA1、jobA_test、jobA.log などに該当します。 ❖ ❖ ◆ ◆ ◆ ◆ ◆ 150 Platform Clusterware 管理者 第 12 章 ジョブの依存性 依存条件 どのジョブについても、次の依存条件を指定できます。 ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ done(jo b _ID | "jo b _n a m e ") ended(jo b _ID | "jo b _n a m e ") exit(jo b _ID [,[o p ] e xit_c o d e ]) exit("jo b _n a m e "[,[o p] e xit_c o d e ]) jo b _ID | "jo b _n a m e " post_done(jo b _ID | "jo b _n a m e ") post_err(jo b _ID | "jo b _n a m e ") started(jo b _ID | "jo b _n a m e ") done 構文 done(jo b _ID | "jo b _n a m e ") 説明 ジョブが DONE 状態のときに TRUE になります。 ended 構文 ended(jo b _ID | "jo b _n a m e ") 説明 ジョブが EXIT 状態または DONE 状態のときに TRUE になります。 exit 構文 exit(jo b _ID | "jo b _n a m e "[,[o pe ra to r] e xit_c o d e ]) ここで、o pe ra to r は次の関係演算子のいずれかです。 ◆ ◆ ◆ ◆ ◆ ◆ > >= < <= == != 説明 ジョブが EXIT 状態で、その終了コードが判定式の条件を満たしているときに TRUE になります。 演算子を付けずに、終了コードだけを指定した場合は、等しいかどうかが判定され ます(演算子として '==' が使用されます)。 ジョブ(ジョブ ID またはジョブ名)だけを指定した場合は、どの終了コードでも 判定式が成立します。 Platform Clusterware 管理者 151 依存条件 例 ◆ exit (myjob) myjob という名前のジョブが EXIT 状態のときに TRUE になります。終了コー ドは何でもかまいません。 ◆ exit (678,0) ID が 678 のジョブが EXIT 状態で、その終了コードが 0(ゼロ)のときに TRUE になります。 ◆ exit ("678",!=0) 678 という名前のジョブが EXIT 状態で、その終了コードが 0(ゼロ)以外の ときに TRUE になります。 ジョブ ID またはジョブ名 構文 jo b _ID | "jo b _n a m e " 説明 このように、ジョブ ID やジョブ名だけを指定した場合は、そのジョブが DONE 状 態かどうかが評価されます(LSF では "done" がデフォルトの依存条件になります)。 post_done 構文 post_done(jo b _ID | "jo b _n a m e ") 説明 ジョブが POST_DONE 状態のときに(このジョブの後処理が正常終了したときに) TRUE になります。 post_err 構文 post_err(jo b _ID | "jo b _n a m e ") 説明 ジョブが POST_ERR 状態のときに(このジョブの後処理が異常終了したときに) TRUE になります。 152 Platform Clusterware 管理者 第 12 章 ジョブの依存性 started 構文 started(jo b _ID | "jo b _n a m e ") 説明 ジョブ状態は次のとおりです。 ◆ ◆ RUN 状態、DONE 状態、EXIT 状態 PEND 状態または PSUSP 状態で、かつ(bsub -E コマンドで指定された)事 前実行コマンドが実行中 高度な依存条件 ジョブ配列 ジョブ配列を使用している場合は、ジョブ配列固有の依存条件を指定できます。 それ以外の依存条件を指定する場合は、通常どおりにジョブ配列の要素を指定しま す。 依存条件の指定例 ◆ 最も単純なのは、依存式で 1 つの依存条件だけを指定する場合です。たとえば、 JobB が正常終了したときだけ JobA を実行したい場合は、JobA を次のように 投入します。 bsub -J "JobA" -w 'done(JobB)' command ◆ -w 'done(312) && (started(Job2)||exit("99Job"))' ID が 312 のジョブが正常終了し、さらに Job2 という名前のジョブが開始され るか、または 99Job という名前のジョブが異常終了してから、投入したジョ ブを開始します。 ◆ -w '"210"' 210 という名前のジョブが正常終了したときだけ、投入したジョブを開始しま す。このジョブ名は、ここで示しているように引用符で二重に囲む必要があり ます。-w "210" と指定すると、UNIX のシェルがそれを -w 210 と解釈し、 ID が 210 のジョブが評価対象になってしまいます。 Platform Clusterware 管理者 153 依存条件 154 Platform Clusterware 管理者 第 13 章 ジョブの優先順位 内容 ◆ 156 ページの「ジョブの優先順位の手動割り当て」 Platform Clusterware 管理者 155 ジョブの優先順位の手動割り当て ジョブの優先順位の手動割り当て ジョブの優先順位を手動で割り当てると、キューの中でのジョブの順番を入れ替え ることができます。ジョブをディスパッチできるかどうかを検討する際には、この 順番が第一の検討事項になります。ジョブはスケジューリング ポリシーの影響も受 けますが、同じ優先順位のジョブは先着順に並べられます。 ジョブの所有者は、自分自身のジョブの優先順位しか変更できませんが、LSF 管理 者とキュー管理者は、キューの中のすべてのジョブの優先順位を変更できます。 ジョブの優先順位の手動割り当て機能は、クラスタ内のどのキューにも適用できま す。 考慮点 btop コマンドや bbot コマンドでは、優先順位が同じジョブの相対的な順番が入 れ替えられます。これらのコマンドを使用しても、ジョブの優先順位は変更されま せん。 ジョブの優先順位を設定する ジョブの優先順位の手動割り当て機能を設定するには、lsb.params ファイルを編 集し、MAX_USER_PRIORITY パラメータを定義します。このパラメータで設定した 値は、クラスタ内のすべてのキューに適用されます。 構文 MAX_USER_PRIORITY=max_priority ここで、 m a x_prio rity は、ユーザがジョブに割り当て可能な最高優先順位です。1 以上の整数を指定でき ます。この値が大きいジョブほど優先されます。1 が最低の優先順位です。 LSF 管理者やキュー管理者は、m a x_prio rity 値を超える優先順位を割り当てること ができます。 例 MAX_USER_PRIORITY=100 この例では、ユーザは 100 までの優先順位をジョブに割り当てることができます。 156 Platform Clusterware 管理者 第 13 章 ジョブの優先順位 ジョブの優先順位を指定する 投入時にジョブの優先順位を指定するには bsub コマンドを、投入後にジョブの優 先順位を変更するには bmod コマンドを使用します。優先順位を指定しないでジョ ブ を 投 入 し た 場 合 は、そ の ジ ョ ブ に デ フ ォ ル ト の 優 先 順 位、す な わ ち MAX_USER_PRIORITY/2 が割り当てられます。 構文 bsub -sp priority bmod [-sp priority | -spn] job_ID ここで、 ◆ -sp prio rity ジョブの優先順位を指定します。1 から MAX_USER_PRIORITY 値までの任意の 整数を指定できます。それ以外の値は拒否されます。 LSF 管理者やキュー管理者は、MAX_USER_PRIORITY 値を超える優先順位を指 定できます。 ◆ -spn このオプションを指定すると、ジョブの優先順位がデフォルト値、すなわち MAX_USER_PRIORITY/2 に設定されます。 ジョブの優先順位の情報を参照する 次のコマンドを使用すると、ジョブの履歴情報、ジョブの現在の状態、システムの 構成情報を参照できます。 bhist -l job_ID ジョブの優先順位の変更履歴を始めとする、ジョブの履歴情報を表示します。 bjobs -l [job_ID] ジョブの投入時の優先順位と現在の優先順位を表示します。ジョブの優先順位は、 ジョブの所有者、または LSF 管理者やキュー管理者によって変更されます。 Platform Clusterware 管理者 157 ジョブの優先順位の手動割り当て 158 Platform Clusterware 管理者 第 14 章 ジョブのキューへの再登録と再実行 内容 ◆ ◆ ◆ ◆ ◆ ◆ 160 161 162 163 164 165 ページの「ジョブのキューへの再登録とは」 ページの「ジョブのキューへの自動再登録」 ページの「ジョブのキュー末尾への再登録」 ページの「ジョブのキューへの除外再登録」 ページの「ジョブのキューへのユーザ指定再登録」 ページの「ジョブの自動再実行」 Platform Clusterware 管理者 159 ジョブのキューへの再登録とは ジョブのキューへの再登録とは ネットワーク コンピューティング環境では、ネットワーク サービスやプロセッサ リソースの障害や、一時的な異常の影響を受けやすくなります。たとえば、NFS の 無効ハンドル エラー、ディスク満杯エラー、プロセス テーブル満杯エラー、ネッ トワーク接続障害などが発生する可能性があります。さらに、ソフトウェア ライセ ンスの問題や、アプリケーションのバグのために不定期に発生するエラーのよう に、システム以外の原因によってアプリケーションが影響を受けることもありま す。 このようなエラーは一時的なもので、通常は頻繁に発生することはなく、複数のホ ストで発生することもあまりありません。そのため、これらのエラーのために全部 のジョブが異常終了しても、そのことに半日たつまで気づかないこともあります。 LSF には、一時的なエラーからの自動回復機能があります。特定の終了コードを指 定しておき、それらのいずれかの値を返してジョブが異常終了した場合に、それら のジョブを自動的にキューに再登録することができます。これらのジョブは、まだ ディスパッチされていないジョブと同じように取り扱われ、後ほど再びディスパッ チされます。キューに再登録されたジョブを、異常終了したホストに再びスケ ジューリングしないように設定することもできます。 160 Platform Clusterware 管理者 第 14 章 ジョブのキューへの再登録と再実行 ジョブのキューへの自動再登録 ジョブのキューへの自動再登録とは キューで所定の設定を行うと、指定した終了コードを返して異常終了したジョブ を、自動的にキューに再登録することができます。 ◆ ◆ ◆ ◆ 再登録されたジョブは、ディスパッチ元のキューの先頭に配置されます。ただ し、lsf.conf ファイルで LSB_REQUEUE_TO_BOTTOM パラメータを設定し た場合を除きます。 ジョブが再登録された場合は、異常終了時の出力は保存されません。 ジョブが再登録された場合は、電子メールによるユーザへの通知は行われませ ん。 シグナルによって終了されたジョブは再登録されません。 ジョブをキューに自動再登録する ジョブをキューに自動再登録するには、キュー定義(lsb.queues ファイル)で REQUEUE_EXIT_VALUES パラメータを設定し、ジョブがどの終了コードを返したと きに再登録するかを指定します。 例 Begin Queue ... REQUEUE_EXIT_VALUES = 99 100 ... End Queue この場合は、99 と 100 のどちらかの終了コードを返して終了したジョブがキュー に再登録されます。 Platform Clusterware 管理者 161 ジョブのキュー末尾への再登録 ジョブのキュー末尾への再登録 ジョブのキュー末尾への再登録とは ジョブのキューへの自動再登録では、通常はジョブがキューの先頭に再登録されま す。代わりにジョブをキューの末尾に再登録することもできます。ジョブの優先順 位は変わりません。 ジョブをキュー末尾に再登録する 前提条件として、ジョブの自動再登録を有効にしておく(lsb.queues ファイルで REQUEUE_EXIT_VALUES パラメータを指定しておく)必要があります。 ジョブをキュー末尾に再登録するには、 1 2 lsf.conf ファイルで LSB_REQUEUE_TO_BOTTOM パラメータを 1 に設定し ます。 lsadmin reconfig コマンドか badmin reconfig コマンドでクラスタを再 構成します。 例 LSB_REQUEUE_TO_BOTTOM=1 162 Platform Clusterware 管理者 第 14 章 ジョブのキューへの再登録と再実行 ジョブのキューへの除外再登録 ジョブのキューへの除外再登録とは ジョブのキューへの自動再登録では、異常終了したジョブを同じホストでは再実行 しないように設定できます。 制約 ◆ ◆ ◆ mbatchd を再起動すると、どのホストが除外されているかについての情報が失 われてしまうため、この機能は正しく機能しません。あるホストで実行された ジョブが除外終了コードを返して異常終了し、その後で mbatchd を再起動す ると、そのジョブが同じホストに再びディスパッチされてしまう可能性があり ます。 この機能は、MultiCluster ジョブや並列ジョブには適用できません。 シグナルによって終了されたジョブは、キューには再登録されません。 ジョブをキューに除外再登録する キュー定義(lsb.queues ファイル)で REQUEUE_EXIT_VALUES パラメータを設 定し、次のように EXCLUDE キーワードに続けて終了コードを( )で囲んで指定し ます。 EXCLUDE(exit_code...) ここで指定した終了コードを返して異常終了したジョブは、キューに再登録され、 異常終了したホストとは別のホストにディスパッチされます。この終了コードを 「除外終了コード」と呼びます。 例 Begin Queue ... REQUEUE_EXIT_VALUES=30 EXCLUDE(20) HOSTS=hostA hostB hostC ... End Queue このキューのジョブを、hostA、hostB、hostC のいずれかのホストにディスパッ チできる場合を考えてみましょう。 hostA で実行され、終了コード 30 を返して異常終了し、キューに再登録された ジョブは、hostA、hostB、hostC のどのホストにもディスパッチできます。これ に対して、hostA で実行され、終了コード 20 を返して異常終了し、キューに再登 録されたジョブは、hostB と hostC のどちらかのホストにしかディスパッチでき ません。 このジョブが hostB で再実行され、終了コード 20 を返して再び異常終了した場合 は、そのジョブは hostC にしかディスパッチできません。さらに、そのジョブが hostC でも終了コード 20 を返して異常終了した場合は、どのホストへのディス パッチも不可能になり、そのジョブが永久に保留状態になります。 Platform Clusterware 管理者 163 ジョブのキューへのユーザ指定再登録 ジョブのキューへのユーザ指定再登録 ジョブのキューへのユーザ指定再登録とは brequeue コマンドを使用すると、ユーザが手動でジョブを中止し、キューに再登 録できます。この方法でキューに再登録されたジョブは保留(PEND)状態になり、 同じ優先順位の他のジョブの末尾に配置されます。 ジョブをキューに手動再登録する ジョブをキューに手動で再登録するには、brequeue コマンドを使用します。 ◆ ◆ ◆ このコマンドは、実行中(RUN 状態)、ユーザによる中断中(USUSP 状態) 、シ ステムによる中断中(SSUSP 状態)のいずれかのジョブだけに適用できます。 ユーザは、このコマンドを自分自身のジョブにしか適用できませんが、root ユーザや LSF 管理者は、このコマンドを他のユーザのジョブにも適用できます。 brequeue コマンドは、対話型バッチ ジョブには適用できません。 例 % brequeue 109 ID が 109 のジョブを中止し、PEND 状態でキューに再登録します。このジョブの優 先順位が 4 だったとすると、このジョブは優先順位が 4 のすべてのジョブの末尾に 配置されます。 % brequeue -u User5 45 67 90 User5 が所有しているジョブのうち、ID が 45、67、90 の 3 つのジョブを中止し、 キューに再登録します。 164 Platform Clusterware 管理者 第 14 章 ジョブのキューへの再登録と再実行 ジョブの自動再実行 ジョブのキューへの再登録とジョブの再実行の違い ジョブのキューへの自動再登録は、ジョブが特定の終了コードを返して終了した場 合に実行されます(この終了コードは、通常は何らかのエラーを示しています)。 ジョブの自動再実行は、ジョブの実行中に実行ホストが使用不能になったり、シス テムに障害が発生した場合に実行されます。ジョブ自身のエラーでは、この処理は 行われません。 ジョブの再実行とは 再実行(または再起動)されるジョブは、ディスパッチ元のキューに、ディスパッ チする前と同じオプションで再登録されます。また、このジョブの優先順位は、そ のキューの中の他のジョブより先にディスパッチされるように引き上げられます。 ジョブ ID は前回の実行時と同じものが使用されます。実行に適したホストが使用 可能になり、このジョブが実行されると、ジョブの所有者に電子メールが送付され、 ジョブが再実行されたことが通知されます。 ジョブの自動再実行は、ユーザがジョブ レベルで、または LSF 管理者がキュー レ ベルで有効にできます。この機能を有効にすると、次の状態になったときにジョブ が自動的に再実行されます。 ジョブの実行中に実行ホストが使用不能になった ジョブの実行中にシステムに障害が発生した ◆ 再実行されるジョブは、サブミッション キューに再登録され、それまでと同じジョ ブ ID が割り当てられます。特に指定しなければ、LSF は、チェックポイントを実 行したジョブであっても、新しく投入されたジョブと同じようにディスパッチしま す。 ◆ 実行ホストの障害 実行ホストが使用不能になった場合は、再実行ジョブは他のホストにディスパッチ されます。ユーザには、ホストに障害が発生したために、ジョブをキューに再登録 したことを通知する電子メール メッセージが送付されます。 LSF システムの障 システムに障害が発生した場合は、再実行ジョブはシステムが再開したときに 害 キューに再登録されます。 キュー レベルでジョブの再実行を設定する キュー レベルでジョブの自動再実行を有効にするには、lsb.queues ファイルで RERUNNABLE パラメータを yes に設定します。 例 RERUNNABLE = yes ジョブを再実行できるように投入する ジョブ レベルでジョブの自動再実行を有効にするには、bsub -r コマンドでジョ ブを投入します。 対話型バッチ ジョブ(bsub -I)は再実行できません。 Platform Clusterware 管理者 165 ジョブの自動再実行 166 Platform Clusterware 管理者 第 15 章 ジョブのチェックポイント、再起 動、移行 内容 ◆ ◆ ◆ ◆ 168 ページの「ジョブのチェックポイント機能」 169 ページの「チェックポイント機能の手法」 170 ページの「アプリケーション レベルのチェックポイント用カスタム echkpnt および erestart の作成」 179 ページの「ジョブの移行」 Platform Clusterware 管理者 167 ジョブのチェックポイント機能 ジョブのチェックポイント機能 ジョブのチェックポイント機能とは、実行中のジョブの状態と、そのジョブの再起 動に必要なデータを保存し、それまでの処理を繰り返す手間を省く機能です。ジョ ブの状態情報はチェックポイント ファイルに保存されます。次のように、この機能 はさまざまな目的で使用できます。 フォールト トレランス ジョブをフォールト トレランスに対応させるには、ジョブの実行中にチェックポイ ントを一定の間隔で(定期的に)設定します。ジョブが中止または移行されたり、 ホスト障害以外の理由でジョブが失敗した場合、最後のチェックポイントから再起 動できるため、それまでの処理を繰り返す手間を省くことができます。 移行 チェックポイント機能は、ジョブの移行にも役立ちます。移行したジョブを最初か らやり直すのではなく、途中から再開できます。ホストに障害が発生したり、高負 荷のためにホストが使用不能になったときに、ジョブを移行することができます。 負荷分散 ジョブのチェックポイントを実行し、別のホストで再起動する(すなわち移行する) と、高負荷のホストから低負荷のホストに負荷(ジョブ)を移し、負荷を分散する ことができます。 168 Platform Clusterware 管理者 第 15 章 ジョブのチェックポイント、再起動、移行 チェックポイント機能の手法 LSF は、echkpnt と erestart の 2 つの統一されたインタフェースを通じて、ほ とんどのチェックポイント機能と再起動機能に対応しています。LSF とチェックポ イント機能との情報の受け渡しは、これらのコマンドがすべて処理します。これら のコマンドの詳細については、echkpnt(8) と erestart(8) の man ページを参 照してください。 チェックポイント機能と再起動機能は、チェックポイントを処理するしくみと、実 行可能コードでどの程度チェックポイントを意識する必要があるかに応じて、いく つかのタイプに分類できます。一般には、これらの機能はカーネル レベル、ユーザ レベル、アプリケーション レベルの 3 種類に分類されます。 アプリケーション レベルのチェックポイント機能 アプリケーション レベルのチェックポイント機能では、アプリケーション自身に チェックポイントの設定と再起動のためのコードを組み込みます。アプリケーショ ンの作成者は、これらのコードに加えて、LSF とのインタフェースとして使用する e c h k p n t と e r e s t a r t も 作 成 し な け れ ば な り ま せ ん。詳 細 に つ い て は、 echkpnt(8) と erestart(8) の man ページを参照してください。これらのアプ リケーションでは、定期的に、または他のプロセスからシグナルを受け取ったとき に、アプリケーション自身がチェックポイントを実行します。また、再起動の際に は、アプリケーション自身がチェックポイント ファイルを検出し、状態を復元しま す。 Platform Clusterware 管理者 169 アプリケーション レベルのチェックポイント用カスタム echkpnt および erestart の作成 アプリケーション レベルのチェックポイント用カスタム echkpnt および erestart の作成 ア プ リ ケ ー シ ョ ン ご と に 専 用 の チ ェ ッ ク ポ イ ン ト 機 能 や、echkpnt お よ び erestart プログラムが必要な場合があります。 ユーザは、特定のアプリケーション用の echkpnt および erestart プログラムを 作成し、どのアプリケーションでそれらのプログラムを使用するかを LSF に通知す ることができます。 ◆ ◆ 170 ページの「echkpnt および erestart カスタム プログラムを作成する」 172 ページの「echkpnt および erestart カスタム プログラムを LSF に認識させ る」 echkpnt および erestart カスタム プログラムを作成する プログラミング言語 ユーザ独自の echkpnt および erestart プログラムは、C 言語または Fortran で 作成できます。 名前 作成した echkpnt および erestart カスタム プログラムに、 echkpnt.method_name および erestart.method_name という名前を付けま す。ここでの method_name が、特定アプリケーション用のプログラムであること を示す識別名になります。 たとえば、my_app というアプリケーション用の echkpnt および erestart カス タム プログラムを作成した場合は、それらに echkpnt.my_app、 erestart.my_app といった名前を付けます。 配置先 echkpnt.method_name および erestart.method_name は、LSF_SERVERDIR ディレクトリか、LSB_ECHKPNT_METHOD_DIR パラメータを使用して指定した別 のディレクトリに配置します。LSB_ECHKPNT_METHOD_DIR パラメータは環境変 数として使用するか、または lsf.conf ファイルに設定します。 同じクラスタの中では、メソッド名(LSB_ECHKPNT_METHOD を lsf.conf ファ イルで、または環境変数として)とメソッド ディレクトリ (LSB_ECHKPNT_METHOD_DIR)の組み合わせが重複しないようにする必要があり ます。たとえば、2 つの echkpnt カスタム プログラムに、echkpnt.mymethod のような同じ名前を付けることができますが、その場合は LSB_ECHKPNT_METHOD_DIR で別々のディレクトリを指定し、この 2 つのプログ ラムの区別を付けます。 チェックポイント メソッドのディレクトリには、カスタムの echkpnt プログラム と erestart プログラムを実行するすべてのユーザがアクセスできる必要があり ます。 echkpnt の構文 echkpnt.method_name は、次の構文で指定されたコマンドを認識できなければ なりません。これらは、echkpnt が echkpnt.method_name に情報を渡すため に必要なオプションです。 echkpnt [-c] [-f] [-k | -s] [-d checkpoint_dir] [-x] process_group_ID 詳細については、echkpnt(8) の man ページを参照してください。 170 Platform Clusterware 管理者 第 15 章 ジョブのチェックポイント、再起動、移行 erestart の構文 erestart.method_name は、次の構文で指定されたコマンドを認識できなければ なりません。これらは、erestart が erestart.method_name に情報を渡すた めに必要なオプションです。 erestart [-c] [-f] checkpoint_dir 詳細については、erestart(8) の man ページを参照してください。 echkpnt.method_name の戻り値 echkpnt.method_name は、ジョブを正常にチェックポイントできた場合、戻り 値 0(ゼロ)を返して終了します。チェックポイントが失敗した場合は、代わりに 0(ゼロ)以外の戻り値を返します。 LSF は、stderr と stdout を無視します。ただし、lsf.conf ファイルで、また は環境変数として LSB_ECHKPNT_KEEP_OUTPUT=y を指定すると、これらの出力 をファイルに保存できます。 erestart.method_name の戻り値 erestart.method_name は、 checkpoint_dir/$LSB_JOB_ID/.restart_cmd というファイルを作成し、こ のファイルにジョブやプロセス グループを再起動するコマンドを、 "LSB_RESTART_CMD=restart_command" の形式で書き込みます。 LSB_RESTART_CMD=restart_command たとえば、ジョブを再起動するコマンドが my_restart my_job だとすると、 erestart.method_name は .restart_cmd ファイルに次の情報を書き込みま す。 LSB_RESTART_CMD=my_restart my_job この後で、erestart がこのファイルを読み取り、LSB_RESTART_CMD で指定され たコマンドを、ジョブを再起動するコマンドとして使用します。 実際には、.restart_cmd ファイルへの書き込みは任意です。 erestart.method_name は、.restart_cmd ファイルにジョブの再起動コマン ドを書き込んだ場合、およびこのファイルに意図的に何も書き込まなかった場合に 戻り値 0(ゼロ)を返し、ジョブの再起動を行えなかった場合に 0(ゼロ)以外の 戻り値を返す必要があります。 ユーザ レベルのチェックポイント機能の場合、erestart.method_name はジョ ブの終了コードを収集し、その後そのジョブと同じ終了コードで終了する必要があ ります。これ以外の方法では、ジョブの終了状態が LSF に正確に報告されません。 一方、カーネル レベルのチェックポイント機能は、ユーザ レベルのチェックポイ ント機能とは異なる方法でジョブを再起動するので、erestart.method_name か らの情報を必要としません。 erestart.method_name の条件 元のコマンド行にアクセスできなければなりません。 ◆ erestart.method_name から、ジョブの起動に使用された元のコマンド行に アクセスする必要があります。 戻り値を返す必要があります。erestart.method_name からアプリケーショ ◆ ンを実行してジョブを再起動してはなりません。 Platform Clusterware 管理者 171 アプリケーション レベルのチェックポイント用カスタム echkpnt および erestart の作成 注 echkpnt が stderr に何らかの情報を書き込むと、 sbatchd は echkpnt が失敗した ものと解釈します。ただし、すべてのエラーが致命的ということではなく、 chkpnt が stdout または stderr に明示的に "Checkpoint done" と書き込んだ場合、 sbatchd は echkpnt が正常に終了したと判断します。 echkpnt および erestart カスタム プログラムを LSF に認識させる lsf.conf ファイルで、または環境変数として次のパラメータを指定できます。こ れらのパラメータを lsf.conf ファイルで指定した場合は、その設定がクラスタ 全体に適用されるデフォルト値になります。これらのパラメータを環境変数として 指定した場合は、その設定のほうが lsf.conf ファイルでの設定よりも優先しま す。 これらのパラメータを lsf.conf ファイルで指定した場合は、設定を有効にする ために、lsadmin reconfig コマンドと badmin reconfig コマンドでクラス タを再構成する必要があります。 1 lsf.conf ファイルで、または環境変数として LSB_ECHKPNT_METHOD=method_name を指定します。 または ジョブを投入するときに、チェックポイント メソッドと再起動メソッドの名前 を指定します。たとえば次のようにします。 % bsub -k "mydir method=myapp" job1 2 作成した echkpnt.method_name と erestart.method_name を LSF_SERVERDIR ディレクトリにコピーします。 または echkpnt.method_name と erestart.method_name を LSF_SERVERDIR 以 外のディレクトリに配置したい場合は、lsf.conf ファイルで、または環境変 数として LSB_ECHKPNT_METHOD_DIR パラメータを使用し、配置先のディレ クトリの絶対パス名を指定します。 チェックポイント メソッドのディレクトリには、カスタムの echkpnt プログ ラムと erestart プログラムを実行するすべてのユーザがアクセスできる必 要があります。 3 (任意) echkpnt.method_name と erestart.method_name の標準エラー / 標準出 力メッセージを保存したい場合は、lsf.conf ファイルで、または環境変数と して LSB_ECHKPNT_KEEP_OUTPUT=y を指定します。 このパラメータを指定すると、echkpnt.method_name の stdout と stderr の出力先が次のファイルに切り替わります。 ❖ checkpoint_dir/$LSB_JOBID/echkpnt.out checkpoint_dir/$LSB_JOBID/echkpnt.err また、erestart.method_name の stdout と stderr の出力先は次のファ イルに切り替わります。 ❖ ❖ checkpoint_dir/$LSB_JOBID/erestart.out checkpoint_dir/$LSB_JOBID/erestart.err LSB_ECHKPNT_KEEP_OUTPUT を定義しなかった場合は、標準エラーと標準出 力の出力先は /dev/null になり、LSF から無視されます。 ❖ 172 Platform Clusterware 管理者 第 15 章 ジョブのチェックポイント、再起動、移行 チェックポイントを実行する LSF からジョブのチェックポイントを実行するには、そのジョブをチェックポイン ト機能に対応させる必要があります。LSF では、自動的に、または手動でジョブを チェックポイント機能に対応させ、チェックポイントを実行することができます。 これらのジョブを使用するには、チェックポイント ディレクトリを必ず指定する必 要があります。さらに、チェックポイント間隔を指定して、定期的にチェックポイ ントを実行することもできます。 LSF は、次の手順でジョブのチェックポイントを実行します。 1 2 3 ジョブが実行中の場合は実行を停止する チェックポイント ディレクトリにチェックポイント ファイルを作成する ジョブを再起動する 前提条件 LSF は、適格なジョブのチェックポイントを作成できます。アプリケーションと環 境がチェックポイントに適しているかどうかを確認するには、169 ページの「チェッ クポイント機能の手法」の説明を参照してください。 Platform Clusterware 管理者 173 チェックポイント ディレクトリ チェックポイント ディレクトリ チェックポイント機能に対応したジョブでは、チェックポイント ディレクトリを必 ず指定する必要があります。このディレクトリには、ジョブの再起動に必要な チェックポイント ファイルが保存されます。ジョブの所有者は、このディレクトリ への書き込み権限を取得しておく必要があります。また、ジョブを他のホストで再 起動する(ジョブを移行する)場合は、このディレクトリに両方のホストからアク セスできるようにしておく必要があります。作成されたチェックポイント ファイル は自動的には削除されません。このファイルの管理はユーザに任されています。 チェックポイント ファイルは、チェックポイント ディレクトリのサブディレクト リに保存され、このサブディレクトリには該当するジョブのジョブ ID と同じ名前 が付けられます。このしくみにより、共通のチェックポイント ディレクトリを使用 して、複数のジョブのチェックポイントを実行できます。たとえば、my_dir とい うチェックポイント ディレクトリを指定し、ジョブ 123 のチェックポイントを実 行したとしましょう。このジョブのチェックポイント ファイルは次のディレクトリ に保存されます。 my_dir/123/ チェックポイントされたジョブが再起動すると、再起動後のジョブ ID に合わせて チェックポイント ディレクトリ名が変更され、それまでのチェックポイント ディ レクトリから新しいチェックポイント ディレクトリへのシンボリック リンクが作 成されます。たとえば、ジョブ ID が 123 のジョブが、456 というジョブ ID で再起 動した場合は、チェックポイント ディレクトリ名は次のように変更されます。 my_dir/456/ 174 Platform Clusterware 管理者 第 15 章 ジョブのチェックポイント、再起動、移行 ジョブをチェックポイント機能に対応させる ジョブをチェックポイント機能に対応させるには、チェックポイント ディレクトリ の場所を指定します。コマンド行から手動で指定する方法と、構成情報を通じて自 動的に指定する方法があります。 手動による設定 ジョブを手動でチェックポイント機能に対応させるには、コマンド行でチェックポ イント ディレクトリを指定します。まだ作成されていないディレクトリを指定した 場合は、LSF がそのディレクトリを自動的に作成します。チェックポイント ディレ クトリは、ジョブの投入時に指定することも、投入後に指定することもできます。 ジョブの投入時 ジョブを投入するときにチェックポイント ディレクトリを指定するには、bsub コ マンドの -k "chkpoint_dir" オプションを使用します。たとえば、my_job の チェックポイント ディレクトリを my_dir に設定するには、次のコマンドを使用 します。 % bsub -k "my_dir" my_job Job <123> is submitted to default queue <default>. ジョブの投入後 ジョブを投入した後でチェックポイント ディレクトリを指定するには、bmod コマ ンドの -k "chkpoint_dir" オプションを使用します。たとえば、ジョブ ID が 123 のジョブのチェックポイント ディレクトリを my_dir に設定するには、次のコ マンドを使用します。 % bmod -k "my_dir" 123 Parameters of job <123> are being changed 自動的な設定 ジョブを自動的にチェックポイント機能に対応させるには、チェックポイント ジョ ブ用のキューにジョブを投入します。このキューを設定するには、lsb.queues ファイルを編集し、該当するキューの CHKPNT パラメータでチェックポイント ディレクトリを指定します。ここで指定するチェックポイント ディレクトリは、事 前に作成しておく必要があります。このディレクトリは自動的には作成されませ ん。 たとえば、チェックポイント ジョブ用のキューを設定し、チェックポイント ディ レクトリとして my_dir を指定するには、lsb.queues ファイルに次の情報を記 述します。 Begin Queue ... CHKPNT=my_dir DESCRIPTION = Make jobs checkpointable using "my_dir" ... End Queue Platform Clusterware 管理者 175 ジョブのチェックポイントを手動で実行する ジョブのチェックポイントを手動で実行する LSF の bchkpnt コマンドを使用すると、ジョブのチェックポイントを手動で実行 できます。ただし、LSF を介してジョブのチェックポイントを実行するためには、 そのジョブをチェックポイント機能に対応させておく必要があります。この手順に ついては、175 ページの「ジョブをチェックポイント機能に対応させる」を参照し てください。たとえば、ジョブ ID が 123 のジョブのチェックポイントを実行する には、次のコマンドを使用します。 % bchkpnt 123 Job <123> is being checkpointed 対話型ジョブ bsub -I はチェックポイントを実行できません。 チェックポイントの実行後にジョブを中止する デフォルト設定では、チェックポイントの実行が完了すると、ジョブが引き続き実 行されます。チェックポイント ファイルを作成した後でジョブを中止するには、 bchkpnt -k コマンドを使用します。その場合は、それ以降は該当するジョブの処 理や I/O は発生しません。たとえば、ジョブ ID が 123 のジョブについて、チェッ クポイントを実行したうえで実行を中止するには、次のコマンドを使用します。 % bchkpnt -k 123 Job <123> is being checkpointed 176 Platform Clusterware 管理者 第 15 章 ジョブのチェックポイント、再起動、移行 ジョブの定期的チェックポイント機能を有効にする ジョブの定期的チェックポイント機能を有効にするには、ジョブの実行中にチェッ クポイント ファイルを一定の時間間隔で作成します。この設定は、コマンド行から 手動で行うことも、構成情報を通じて自動的に行うこともできます。ここでは、手 動による設定手順を説明しています。構成情報による自動的な設定については、 178 ページの「ジョブのチェックポイントを自動的に実行する」を参照してくださ い。なお、LSF を介してジョブのチェックポイントを実行するためには、そのジョ ブをチェックポイント機能に対応させておく必要があります。この手順について は、175 ページの「ジョブをチェックポイント機能に対応させる」を参照してくだ さい。 手動で定期的チェックポイント機能を有効にするには、チェックポイント間隔を分 単位の時間で指定します。 ジョブの投入時 ジョブを投入するときに定期的チェックポイント機能を有効にするには、bsub コ マンドの -k "checkpoint_dir checkpoint period" オプションを使用しま す。たとえば、my_job のチェックポイントを 2 時間(120 分)おきに設定するに は、次のコマンドを使用します。 % bsub -k "my_dir 120" my_job Job <123> is submitted to default queue <default>. ジョブの投入後 ジョブを投入した後で定期的チェックポイント機能を有効にするには、bchkpnt コマンドの -p period オプションを使用します。LSF は、このコマンドの実行直 後にチェックポイントを実行し、以後は指定された時間間隔でチェックポイントを 定期的に設定します。たとえば、ジョブ ID が 123 のジョブのチェックポイントを 2 時間(120 分)おきに設定するには、次のコマンドを使用します。 % bchkpnt -p 120 123 Job <123> is being checkpointed bchkpnt コマンドの -p period オプションは、チェックポイント間隔を変更する ときにも使用できます。たとえば、ジョブ ID が 123 のジョブのチェックポイント 間隔を 4 時間(240 分)に変更するには、次のコマンドを使用します。 % bchkpnt -p 240 123 Job <123> is being checkpointed 定期的チェックポイント機能を無効にする 定期的チェックポイント機能を無効にするには、チェックポイント間隔を 0(ゼロ) に設定します。たとえば、ジョブ ID が 123 のジョブの定期的チェックポイント機 能を無効にするには、次のコマンドを使用します。 % bchkpnt -p 0 123 Job <123> is being checkpointed Platform Clusterware 管理者 177 ジョブのチェックポイントを自動的に実行する ジョブのチェックポイントを自動的に実行する ジョブのチェックポイントを自動的に実行するには、定期的チェックポイント用の キューにジョブを投入します。このキューを設定するには、lsb.queues ファイル を編集し、該当するキューの CHKPNT パラメータで、チェックポイント ディレク トリとチェックポイント間隔を指定します。ここで指定するチェックポイント ディ レクトリは、自動的には作成されないため、事前に作成しておく必要があります。 また、チェックポイント間隔は分単位の時間で指定します。このキューに投入した すべてのジョブについて、チェックポイントが自動的に実行されます。たとえば、 定期的チェックポイント用のキューを設定し、チェックポイント間隔として 4 時間 (240 分)を、チェックポイント ディレクトリとして my_dir を指定するには、 lsb.queues ファイルに次の情報を記述します。 Begin Queue ... CHKPNT=my_dir 240 DESCRIPTION=Auto chkpnt every 4 hrs (240 min) to my_dir ... End Queue このキューに投入したジョブについて、bchkpnt コマンドでチェックポイントを 実行することもできます。-k、-r、-p、-kn オプションを使用してジョブを投入 または修正した場合は、キューで設定したオプションは無効になります。 178 Platform Clusterware 管理者 第 15 章 ジョブのチェックポイント、再起動、移行 ジョブの移行 移行とは、チェックポイント機能に対応しているジョブや再実行可能なジョブを、 あるホストから別のホストに移す機能です。 チェックポイント機能を使用すると、移行したジョブを最後のチェックポイントか ら再起動することで、処理を途中から再開できます。再実行は可能なものの、チェッ クポイント機能には対応していないジョブは、はじめから再起動されます。LSF で は、コマンド行から手動で、または構成情報を通じて自動的にジョブを移行させる ことができます。ジョブを移行する際には、LSF は次の処理を実行します。 1 2 3 4 ジョブが実行中の場合は実行を停止する ジョブがチェックポイント機能に対応している場合はチェックポイントを実行 する 現行のホストでジョブを中止する 次に使用可能なホストで、そのホストで保留中のどのジョブより先にジョブを 再起動または再実行する 要件 チェックポイント機能に対応したジョブを別のホストに移行するには、移行前のホ ストと移行後のホストの両方が次の条件を満たしていなければなりません。 ◆ ◆ ◆ ◆ ◆ バイナリ レベルで互換性がある 同じバージョンのオペレーティング システムを使用している(バージョンが完 全に一致していないと、予期しない結果になることがある) 実行可能コードにアクセスできる 開かれているファイルにすべてアクセスできる(LSF は絶対パス名でしかこれ らのファイルを検出できない) チェックポイント ファイルにアクセスできる ジョブを手動で移行する ジョブを手動で移行するには、bmig コマンドを使用します。チェックポイント機 能に対応したジョブや、再実行可能なジョブであれば、どのジョブでも移行できま す。ただし、ジョブを手動で移行できるのは、そのジョブの所有者、キュー管理者、 LSF 管理者に限られています。たとえば、ジョブ ID が 123 のジョブを移行するに は、次のコマンドを使用します。 % bmig 123 Job <123> is being migrated % bhist -l 123 Job Id <123>, User <user1>, Command <my_job> Tue Feb 29 16:50:27: Submitted from host <hostA> to Queue <default>, C WD <$HOME/tmp>, Checkpoint directory <chkpnt_dir/123>; Tue Feb 29 16:50:28: Started on <hostB>, Pid <4705>; Tue Feb 29 16:53:42: Migration requested; Tue Feb 29 16:54:03: Migration checkpoint initiated (actpid 4746); Tue Feb 29 16:54:15: Migration checkpoint succeeded (actpid 4746); Tue Feb 29 16:54:15: Pending: Migrating job is waiting for reschedule; Tue Feb 29 16:55:16: Started on <hostC>, Pid <10354>. Summary of time in seconds spent in various states by Tue Feb 29 16:57:26 PEND PSUSP RUN USUSP SSUSP UNKWN TOTAL 62 0 357 0 0 0 419 Platform Clusterware 管理者 179 ジョブの移行 ジョブを自動的に移行する ジョブの自動移行機能は、実行先のホストに高い負荷がかかり、負荷の状態などの ためにジョブが長期間中断されている(SSUSP 状態になっている)場合に効力を発 揮します。移行しきい値を設定することで、中断しているジョブを他のホストに移 して再開し、実行先のホストの負荷を軽減できます。このしきい値は、キュー レベ ルやホスト レベルで、分単位の時間で指定します。 キュー レベルで設定した移行しきい値は、該当するキューに投入したすべてのジョ ブに適用され、ホスト レベルで設定した移行しきい値は、該当するホストで実行さ れているすべてのジョブに適用されます。移行しきい値をキューとホストの両方で 設定した場合は、低いほうのしきい値が使用されます。移行しきい値を 0(ゼロ) に設定した場合は、ジョブは中断されると(SSUSP 状態になると)直ちに移行され ます。 bmig コマンドで手動で移行するジョブには、移行しきい値の設定は適用されませ ん。 キューの移行しきい キューの移行しきい値を設定するには、lsb.queues ファイルを編集し、MIG パ 値を設定する ラメータでしきい値を指定します。たとえば、中断されたジョブを 30 分後に移行 させるには、該当するキューを次のように設定します。 Begin Queue ... MIG=30 # Migration threshold set to 30 mins DESCRIPTION=Migrate suspended jobs after 30 mins ... End Queue ホストの移行しきい ホストの移行しきい値を設定するには、lsb.hosts ファイルを編集し、ホスト用 値を設定する の MIG パラメータでしきい値を指定します。たとえば、中断されたジョブを 30 分 後に移行させるには、該当するホストを次のように設定します。 Begin Host HOST_NAME ... hostA ... End Host r1m pg MIG # Keywords 5.0 18 30 移行したジョブをキューに再登録する デフォルト設定では、移行したジョブは次に使用可能なホスト上で、そのホストで 保留中のどのジョブよりも先に再起動または再実行されます。 移行したジョブを直ちに再起動または再実行する代わりに、キューに再登録するこ ともできます。その場合は、ジョブは PEND 状態でキューに再登録され、当初のサ ブミッション時刻と優先順位に応じた順番が割り当てられます。この機能を有効に するには、lsf.conf ファイルを編集し、LSB_MIG2PEND=1 を指定します。 さらに、移行したジョブをキューの末尾に再登録することもできます。その場合は、 lsf.conf ファイルを編集し、LSB_MIG2PEND=1 と共に LSB_REQUEUE_TO_BOTTOM=1 を指定します。 180 Platform Clusterware 管理者 第 16 章 ジョブ配列 LSF ではジョブ配列と呼ばれる構造を使用することができます。ジョブ配列を使用 すると、同じ実行可能プログラムとリソース要件を共有し、入力ファイルが異なる 連続するジョブを単一ユニットとして投入、制御、または監視できます。標準の LSF コマンド使用して、ジョブ配列から投入された個々のジョブおよびジョブ グループ の制御とモニタを行うこともできます。 ジョブ配列が投入された後、LSF は個々のジョブを別個にスケジュールし、ディス パッチします。ジョブ配列から投入された各ジョブは、ジョブ配列と同じジョブ ID を持ち、配列インデックスを使用して個別に参照されます。ジョブ配列の次元と構 造は、ジョブ配列を作成するときに定義されます。 内容 ◆ ◆ ◆ ◆ ◆ ◆ ◆ 182 184 187 188 190 191 192 ページの「ジョブ配列の作成」 ページの「入力ファイルと出力ファイルの処理」 ページの「ジョブ配列の依存」 ページの「ジョブ配列のモニタ」 ページの「ジョブ配列の制御」 ページの「ジョブ配列のリキュー」 ページの「ジョブ配列のジョブ スロット制限」 Platform Clusterware 管理者 181 ジョブ配列の作成 ジョブ配列の作成 ジョブ配列は、ジョブの投入時に bsub の -J オプションを使用して作成します。 たとえば、次のコマンドでは、1000 個のジョブで構成される myArray という名前 のジョブ配列が作成されます。 % bsub -J "myArray[1-1000]" myJob Job <123> is submitted to default queue <normal>. 構文 ジョブ配列を作成するときの bsub の構文を次に示します。 % bsub -J "arrayName[indexList, ...]" myJob ここで、 -J "arrayName[indexList, ...]" ジョブ配列を作成し、名前を付けます。indexList の前後の角括弧 [ ] は、前述 のとおりに必ず入力し、配列名を指定するときは、引用符で囲む必要があります。 カンマ(,)は、複数の indexList エントリを区切るために使用します。最大 255 文字まで指定できます。 arrayName ジョブ配列を識別するために使用される文字列をユーザが指定します。値には、次 の文字を組み合わせて使用できます。 a-z | A-Z | 0-9 | . | - | _ indexList = start[-end[:step]] ジョブ配列のサイズと次元を指定します。各項目の意味は次のとおりです。 182 Platform Clusterware 管理者 ◆ start end と組み合わせて使用し、インデックスの範囲の開始値を指定します。また、 インデックスを個々に指定することもできます。有効な値は、固有の正の整数 です。たとえば、[1-5] および [1, 2, 3, 4, 5] とした場合、1 から 5 ま でのインデックスで 5 個のジョブを指定します。 ◆ end インデックスの範囲の終わりを指定します。有効な値は、固有の正の整数です。 ◆ step 範囲内でのインデックスの増分を指定します。インデックスは start から始 まり、end の値になるまで、step の値が加算されます。デフォルト値は、1 で す。有効な値は、正の整数です。たとえば、[1-10:2] と指定すると、1 から 10 までの範囲で増分は 2 になるので、1、3、5、7、9 のインデックスが作成さ れます。 第 16 章 ジョブ配列 ジョブ配列が作成(投入)された後、個々のジョブはジョブ配列名またはジョブ ID とインデックス値を使用して参照されます。たとえば、次の一連のジョブ配列文は、 1000 個のジョブから構成され、123 というジョブ ID を持つ myArray という名前 のジョブ配列から投入されたジョブを参照しています。 myArray[1], myArray[2], myArray[3], ..., myArray[1000] 123[1], 123[2], 123[3], ..., 123[1000] ジョブ配列の最大サイズ ジョブ配列が大きいと、ジョブの 1 回の投入でユーザはシステムに多数のジョブを 投入できます。 デフォルト設定では、ジョブ配列の最大のインデックス値は 1000 です。したがっ て、1 つのジョブ配列には 1000 個までのジョブを収容できます。 最大のインデックス値を 1000 から変更するには、lsb.params ファイル内の MAX_JOB_ARRAY_SIZE パラメータで、65534 以下の任意の値を指定します。 Platform Clusterware 管理者 183 入力ファイルと出力ファイルの処理 入力ファイルと出力ファイルの処理 LSF では、ジョブ配列の投入時に作成された複数ジョブに関して、それぞれの入力 ファイルと出力ファイルを統一するメソッドを提供しています。このメソッドは、 入力ファイルが一様に用意されていることを前提としています。標準入力と標準出 力を使用する実行可能プログラムを組み込むために、LSF では実行時に拡張される 実行時変数を提供しています。また、コマンド行引数を読み取る実行可能プログラ ムを組み込むために、実行環境で設定される環境変数も用意されています。 メソッド ◆ ◆ 185 ページの「標準入力と標準出力の転送」 186 ページの「コマンド行での引数の受渡し」 ファイルの準備 LSF では、ジョブ配列内のジョブに使用されるすべての入力ファイルは同じディレ クトリに格納されている必要があります。デフォルトでは、bsub が発行されたカ レント作業ディレクトリ(CWD)にあることを前提とします。CWD を指定変更す るには、ジョブ配列を投入するときに、絶対パスを指定します。 各ファイルの名前は、固定の名前文字列と配列インデックスと直接対応する変数整 数の 2 つの要素から構成されます。次に、ジョブ配列の有効な入力ファイル名の例 を紹介します。これらの名前は、input という固定名と 1 から 1000 までの範囲の ジョブ配列インデックスに対応する整数で構成されます。 input.1, input.2, input.3, ..., input.1000 184 Platform Clusterware 管理者 第 16 章 ジョブ配列 標準入力と標準出力の転送 変数 %I および %J は、ジョブ配列から投入されたジョブのファイルを転送するた めに置換文字列として使用されます。実行時には、%I はカレント ジョブのジョブ 配列インデックス値を提供するために展開され、%J はジョブ配列のジョブ ID を提 供するために展開されます。 標準入力 実行可能プログラムが標準入力から読み取るときは、bsub の -i オプションと %I 変数を使用します。%I を使用するには、すべての入力ファイルに対して、ジョブ配 列のインデックスに対応する変数要素を持つ一貫した名前を付ける必要がありま す。たとえば、次のような名前にします。 input.1, input.2, input.3, ..., input.N 次のコマンドの例では、入力ファイル名が input.1、input.2、input.3、...、 input.1000 で、カレント作業ディレクトリに存在する、1000 個のジョブのジョ ブ配列を投入しています。 % bsub -J "myArray[1-1000]" -i "input.%I" myJob 標準出力とエラー 実行可能プログラムが標準出力とエラーに書き込むときは、bsub の -o オプショ ンと %I および %J 変数を使用します。 ジョブ配列から投入された個々のジョブに対応する出力ファイルを作成するには、 出力ファイル名の一部として %I を指定します。たとえば、次のコマンドでは、出 力ファイルが output.1、output.2、output.3、...、output.1000 という名 前で CWD に格納される、1000 個のジョブのジョブ配列を投入しています。 % bsub -J "myArray[1-1000]" -o "output.%I" myJob ファイル名の一部にジョブ配列のジョブ ID が含まれた出力ファイルを作成するに は %J を指定します。次のコマンドの例では、出力ファイルが output.123.1、 output.123.2、output.123.3、...、output.123.1000 という名前で CWD に 格納される、1000 個のジョブのジョブ配列を投入しています。このジョブ配列の ジョブ ID は 123 です。 % bsub -J "myArray[1-1000]" -o "output.%J.%I" myJob Platform Clusterware 管理者 185 コマンド行での引数の受渡し コマンド行での引数の受渡し LSB_JOBINDEX 環境変数は、コマンド行でジョブ配列インデックスを受け渡しでき るようにするための置換文字列として使用します。ジョブがディスパッチされる と、LSF は実行環境の LSB_JOBINDEX にカレント ジョブのジョブ配列インデック スを設定します。LSB_JOBINDEX は、すべてのジョブに設定されます。非配列の ジョブでは、LSB_JOBINDEX が 0(ゼロ)に設定されます。 LSB_JOBINDEX を使用するには、すべての入力ファイルの名前を統一し、ジョブ配 列のインデックスに対応する変数要素を付加する必要があります。たとえば、次の ような名前にします。 input.1, input.2, input.3, ..., input.N bsub による変数の展開がシェルに妨げられないように、バックスラッシュ \ を使 用して LSB_JOBINDEX をエスケープする必要があります。たとえば、次のコマン ドでは、入力ファイル名が input.1、input.2、input.3、...、input.1000 で、 カレント作業ディレクトリに存在する、1000 個のジョブのジョブ配列を投入してい ます。実行可能プログラムには、入力ファイルの名前を指定する引数が渡されます。 % bsub -J "myArray[1-1000]" myJob -f input.\$LSB_JOBINDEX 186 Platform Clusterware 管理者 第 16 章 ジョブ配列 ジョブ配列の依存 LSF の他のジョブと同様に、ジョブ配列もジョブまたは他のジョブ配列の完了また は部分的な完了に依存することがあります。LSF には、ジョブ配列固有の依存条件 がいくつか用意されています。 全配列依存 ジョブまたは他のジョブ配列の完了に依存するジョブ配列を作成するには、bsub の -w "dependency_condition" オプションを使用します。たとえば、ジョブ ID 123 のジョブまたはジョブ配列に依存する配列を作成するには、次のコマンドを 使用します。 % bsub -w "done(123)" -J "myArray2[1-1000]" myJob 部分配列依存 既存のジョブ配列に依存するジョブまたはジョブ配列を作成するには、次の依存条 件のいずれかを使用します。 条件 説明 numrun(jobArrayJobId, op num) numpend(jobArrayJobId, op num) numdone(jobArrayJobId, op num) numexit(jobArrayJobId, op num) numended(jobArrayJobId, op num) numhold(jobArrayJobId, op num) numstart(jobArrayJobId, op num) RUN 状態のジョブの数を評価 PEND 状態のジョブの数を評価 DONE 状態のジョブの数を評価 EXIT 状態のジョブの数を評価 DONE および EXIT 状態のジョブの数を評価 PSUSP 状態のジョブの数を評価 RUN、SSUSP、および USUSP 状態のジョブ の数を評価 次の演算子(op)の 1 つを正の整数(num)と組み合わせて使用して、条件を設定 します。 == | > | < | >= |<= | != 任意で num の代わりにアスタリスク(*)を使用して、そのジョブ配列から投入さ りたすべてのジョブを表すこともできます。 たとえば、ジョブ ID 123 のジョブ配列の 100 以上の要素が正常に終了したときに、 myJob という名前のジョブを開始するには、次のように指定します。 % bsub -w "numdone(123, >= 100)" myJob Platform Clusterware 管理者 187 ジョブ配列のモニタ ジョブ配列のモニタ bjobs と bhist を使用すると、ジョブ配列の現在と過去の状態を監視することが できます。 ジョブ配列の状態 ジョブ配列から投入され、現在実行されているジョブに関する要約情報を表示する には、bjobs の -A オプションを使用します。たとえば、ジョブ ID 123 の 10 個の ジョブを持つジョブ配列の場合、次のように入力します。 % bjobs -A 123 JOBID ARRAY_SPEC OWNER NJOBS PEND DONE 123 myArra[1-10] user1 10 3 RUN EXIT SSUSP USUSP PSUSP 3 4 0 0 0 0 個々のジョブの状態 現在 ジョブ配列から投入された個々のジョブの状態を表示するには、bjobs でジョブ配 列のジョブ ID を指定します。ジョブ配列から投入されたジョブの場合、[JOBID] に はジョブ配列のジョブ ID が、また [JOBNAME] にはジョブ配列名と各ジョブのイン デックス値がそれぞれ表示されます。ジョブ ID 123 のジョブ配列の表示例を次に 示します。 % bjobs 123 JOBID USER 123 user1 123 user1 123 user1 123 user1 123 user1 123 user1 123 user1 123 user1 123 user1 123 user1 STAT DONE DONE DONE RUN RUN RUN RUN PEND PEND PEND QUEUE default default default default default default default default default default FROM_HOST hostA hostA hostA hostA hostA hostA hostA hostA hostA hostA EXEC_HOST hostC hostQ hostB hostC hostL hostB hostQ JOB_NAME myArray[1] myArray[2] myArray[3] myArray[4] myArray[5] myArray[6] myArray[7] myArray[8] myArray[9] myArray[10] SUBMIT_TIME Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 Feb 29 12:34 過去 ジョブ配列から投入された各ジョブの過去の状態を表示するには、bhist でジョブ 配列のジョブ ID を指定します。ジョブ ID 456 のジョブ配列の履歴を表示する例を 次に示します。 % bhist 456 Summary of time in seconds spent in various states: JOBID USER JOB_NAME PEND PSUSP RUN USUSP 456[1] user1 *rray[1] 14 0 65 0 456[2] user1 *rray[2] 74 0 25 0 456[3] user1 *rray[3] 121 0 26 0 456[4] user1 *rray[4] 167 0 30 0 456[5] user1 *rray[5] 214 0 29 0 456[6] user1 *rray[6] 250 0 35 0 456[7] user1 *rray[7] 295 0 33 0 456[8] user1 *rray[8] 339 0 29 0 456[9] user1 *rray[9] 356 0 26 0 456[10]user1 *ray[10] 375 0 24 0 188 Platform Clusterware 管理者 SSUSP 0 0 0 0 0 0 0 0 0 0 UNKWN 0 0 0 0 0 0 0 0 0 0 TOTAL 79 99 147 197 243 285 328 368 382 399 第 16 章 ジョブ配列 特定のジョブの状態 現在 ジョブ配列から投入された特定のジョブの現状を表示するには、bjobs に引用符で 囲んだジョブ配列のジョブ ID とインデックス値を指定します。たとえば、ジョブ ID 123 のジョブ配列の 5 番目のジョブ状態を表示するには、次のように指定しま す。 % bjobs "123[5]" JOBID USER STAT 123 user1 RUN QUEUE default FROM_HOST hostA EXEC_HOST hostL JOB_NAME myArray[5] SUBMIT_TIME Feb 29 12:34 過去 ジョブ配列から投入された特定のジョブの過去の状態を表示するには、bhist に引 用符で囲んだジョブ配列のジョブ ID とインデックス値を指定します。たとえば、 ジョブ ID 456 のジョブ配列の 5 番目のジョブ履歴を表示するには、次のように指 定します。 % bhist "456[5]" Summary of time in seconds spent in various states: JOBID USER JOB_NAME PEND PSUSP RUN USUSP 456[5] user1 *rray[5] 214 0 29 0 SSUSP 0 UNKWN 0 TOTAL 243 Platform Clusterware 管理者 189 ジョブ配列の制御 ジョブ配列の制御 配列全体、すなわちジョブ配列から投入されたすべてのジョブを 1 つのコマンドで 制御することができます。さらに、ジョブ配列から投入された個々のジョブまたは ジョブ グループを制御する機能もあります。ジョブ配列に対してコマンドを発行す るときは、ジョブ配列名ではなく、ジョブ配列のジョブ ID を使用します。LSF で は、ジョブ名は固有ではないので、ジョブ配列名を使用してコマンドを発行すると、 予期しない結果になることがあります。 ほとんどの LSF コマンドは、ジョブ配列全体、個々のジョブ、ジョブ グループの どれに対しても作用します。このようなコマンドには bkill、bstop、bresume、 bmod が含まれます。 コマンドの中にはジョブ配列から投入された個々のジョブにだけ作用するものも あります。この例として、btop、bbot、bswitch が挙げられます。 全配列 配列全体を制御するには、単一のジョブに対して使用するように、ジョブ ID だけ を使用してコマンドを指定します。たとえば、ジョブ ID 123 のジョブ配列を中止 するには、次のコマンドを使用します。 % bkill 123 個々のジョブ ジョブ配列から投入された個々のジョブを制御するには、ジョブ配列のジョブ ID とジョブに対応するインデックス値を使用してコマンドを指定します。ジョブ ID とインデックス値は引用符で囲みます。たとえば、ジョブ ID 123 のジョブ配列の 5 番目のジョブを中止するには、次のコマンドを使用します。 % bkill "123[5]" ジョブ グループ ジョブ配列から投入されたジョブ グループを制御するには、個々のジョブに対して 使用するようにコマンドを指定し、indexList 構文を使用してジョブを指定しま す。たとえば、ジョブ ID 123 のジョブ配列のジョブのうち、1 から 5 までと 239 および 487 のジョブをキルするには、次のコマンドを使用します。 % bkill "123[1-5, 239, 487]" 190 Platform Clusterware 管理者 第 16 章 ジョブ配列 ジョブ配列のリキュー ジョブ配列をリキューするためには brequeue を使います。ジョブはリキューさ れると PEND 状態になり、キューの中での新しい位置は同じ優先度の他のジョブの 後ろになります。以下のジョブに対してリキューを行うことができます。 DONE 状態のジョブ EXIT 状態のジョブ ◆ ジョブ配列のジョブ(すべてのジョブ状態) ◆ EXIT、RUN、DONE の各ジョブを PSUSP 状態にする ◆ RUN 状態のジョブ ◆ brequeue はマルチクラスタ環境ではサポートされません。 ◆ DONE 状態のジョブのリキュー DONE ジョブをリキューするには、brequeue の -d オプションを使います。たと えば、コマンド brequeue -J "myarray[1-10]" -d 123 はジョブ ID 123 で DONE 状態のジョブをリキューします。 EXIT 状態のジョブのリキュー EXIT ジョブをリキューするには、brequeue の -e オプションを使います。たと えば、コマンド brequeue -J "myarray[1-10]" -e 123 はジョブ ID 123 で EXIT 状態のジョブをリキューします。 ジョブの状態に関係なく配列の中のすべてのジョブをリキューする 投入されたジョブ配列は異なるジョブ状態のジョブを持つことができます。ジョブ の状態に関係なくすべての配列ジョブをリキューするには、brequeue の -a オプ ションを使います。たとえば、コマンド brequeue -J "myarray[1-10]" -a 123 はジョブ ID 123 で状態に関係なくすべてのジョブをリキューします。 RUN 状態のジョブをリキューして PSUSP 状態にする RUN ジョブをリキューして PSUSP 状態にするには、brequeue の -H オプション を使います。たとえば、コマンド brequeue -J "myarray[1-10]" -H 123 は ジョブ ID 123 で RUN 状態のジョブを PSUSP にしてリキューします。 RUN 状態のジョブをリキューする RUN ジョブをリキューするには、brequeue の -r オプションを使います。たとえ ば、コマンド brequeue -J "myarray[1-10]" -r 123 はジョブ ID 123 で RUN 状態のジョブをリキューします。 Platform Clusterware 管理者 191 ジョブ配列のジョブ スロット制限 ジョブ配列のジョブ スロット制限 ジョブ配列のジョブ スロット制限は、1 つのジョブ配列から投入されたジョブを一 度に実行できる最大数を指定するために使用します。ジョブ配列を使用すると、1 つのコマンドで多数のジョブを投入できるので、システムを満杯にする可能性があ るため、ジョブ スロット制限機能を提供し、ジョブ配列がシステムに与える影響を 制限できるようにしています。ジョブ配列のジョブ スロット制限は、次の構文を使 用して指定します。 % bsub -J "arrayName[indexList]%jobLimit" myJob 各項目の意味は次のとおりです。 %jobLimit 一度に実行できるジョブの最大数を指定します。パーセント記号 % は、ここに記述 されているとおりに入力します。有効な値は、ジョブ配列の最大インデックス値よ り小さい正の整数です。 ジョブ配列のジョブ スロット制限の設定 ジョブ配列のジョブ スロット制限は、bsub を使用して投入時に設定するか、また は bmod を使用して投入した後で設定できます。 投入時 たとえば、1000 個のジョブを持つジョブ配列のジョブ スロット制限を 100 ジョブ に設定するには、次のように指定します。 % bsub -J "jobArrayName[1000]%100" myJob 投入後 For example, to set a job array job slot limit of 100 jobs for an array with job ID 123: % bmod -J "%100" 123 ジョブ配列のジョブ スロット制限の変更 ジョブ配列のジョブ スロット制限を変更する方法は、投入後に制限を設定するとき と同じです。たとえば、ジョブ ID 123 のジョブ配列のジョブ スロット制限を 250 に変更するには、次のように指定します。 % bmod -J "%250" 123 192 Platform Clusterware 管理者 第 16 章 ジョブ配列 ジョブ配列のジョブ スロット制限の表示 ジョブ配列のジョブ スロット制限を表示するには、bjobs の -A および -l オプ ションを使用します。ジョブ配列のジョブ スロット制限は、[Job Name] フィールド に、設定したときと同じフォーマットで表示されます。次の出力例には、ジョブ ID 123 のジョブ配列に 100 のジョブ配列ジョブ スロット制限が設定されていること が表示されます。 % bjobs -A -l 123 Job <123>, Job Name <myArray[1-1000]%100>, User <user1>, Sta tus <PEND>, Queue <normal>, Job Priority <20>, Command <my Job> Wed Feb 29 12:34:56: Submitted from host <hostA>, CWD <$HOME>; COUNTERS: NJOBS PEND DONE RUN EXIT SSUSP USUSP PSUSP 10 9 0 1 0 0 0 0 Platform Clusterware 管理者 193 ジョブ配列のジョブ スロット制限 194 Platform Clusterware 管理者 第V部 ジョブの実行の制御 内容 ◆ ◆ ◆ ◆ ◆ ◆ 第 第 第 第 第 第 17 18 19 20 21 22 章、「実行時のリソース使用制限」 章、「負荷しきい値」 章、「実行前コマンドと実行後コマンド」 章、「ジョブ スタータ」 章、「外部ジョブの投入と実行と制御」 章、「ジョブ制御の設定」 第 17 章 実行時のリソース使用制限 内容 ◆ ◆ ◆ ◆ 198 200 202 207 ページの「リソース使用制限とは」 ページの「リソース使用制限を指定する」 ページの「使用可能なリソース使用制限の構文」 ページの「CPU 時間と実行時間の正規化」 Platform Clusterware 管理者 197 リソース使用制限とは リソース使用制限とは リソース使用制限とは、実行中のジョブが消費できるリソースの量を制限する機能 です。指定された量よりも多くのリソースを使用するジョブにはシグナルが送出さ れるか、優先順位が下げられます。 制限値は、LSF 管理者が(lsb.queues ファイルに)キュー レベルで指定するか、 ユーザがジョブを投入するときにジョブ レベルで指定することができます。 たとえば、優先順位の高い short キューを定義すると、短いジョブを長いジョブよ りも優先してスケジューリングできます。しかし、この短いジョブ固有のキューに、 ユーザが長いジョブを投入してしまうことも考えられます。それを防ぐために、こ のキューに CPU 時間制限を設定し、この制限値よりも実行時間の長いジョブが投 入されないようにすることができます。 キュー レベルで指定される制限は h a rd 制限値で、ジョブ投入時に指定されるのは so ft 制限値です。hard 制限値と soft 制限値の概念については、setrlimit(2) マ ニュアル ページを参照してください。 リソース使用制限とリソース割り当て制限 リソース使用制限は、リソース割り当て制限とは異なります。リソース割り当て制 限はジョブのスケジューリング中、ジョブがディスパッチされる前に適用されま す。リソース割り当て制限は、ジョブのスケジューリング中に使用可能でなければ ならない特定のリソース量に対する制限とその制限を適用するリソース コン シューマを、開始するジョブのクラスごてに設定します。 リソース使用制限の要約 198 制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 コア ファイル サイ ズ制限 CPU 時間制限 -C c o re _lim it CORELIMIT=limit in te g e r KB -c c pu _lim it CPULIMIT=[default] maximum データ セグメント サイズ制限 ファイル サイズ制 限 メモリ制限 -D d a ta _lim it DATALIMIT=[default] maximum [h o u rs :]m in u te s[/h o st_n a m e | /h o st_m o d e l] in te g e r KB -F file _lim it FILELIMIT=limit in te g e r KB -M m e m _lim it in te g e r KB プロセス制限 -p pro c e ss_lim it 実行時間制限 -W ru n _lim it MEMLIMIT=[default] maximum PROCESSLIMIT=[default] maximum RUNLIMIT=[default] maximum スタック セグメン ト サイズ制限 仮想メモリ制限 -S sta c k_lim it STACKLIMIT=limit [h o u rs :]m in u te s[/h o st_n a m e | /h o st_m o d e l] in te g e r KB -v sw a p_lim it SWAPLIMIT=limit in te g e r KB Platform Clusterware 管理者 in te g e r KB 第 17 章 実行時のリソース使用制限 リソース使用制限の優先順位 ジョブ投入時にリソース制限を指定しなかった場合は、キューに投入したジョブに 次のリソース制限が適用されます。 状況 処理 デフォルト制限値と最大制限値の両方を指定してい る場合 最大制限値だけを指定している場合 制限値を指定していない場合 デフォルト制限値を適用 最大制限値を適用 制限を適用しない 不正なリソース使用制限 クラスタの再構成時や再起動時に、不正な制限は無視され、警告メッセージが表示 されます。また、警告メッセージは、LSF が起動するときに、mbatchd ログ ファイ ルにも記録されます。 ジョブ投入時にリソース制限を指定しなかった場合は、キューに投入したジョブに 次のリソース制限が適用されます。 状況 処理 デフォルト制限値が不正な場 合 デフォルト制限値と最大制限 値の両方を指定していて、最 大制限値が不正な場合 デフォルト制限値と最大制限 値の両方が不正な場合 デフォルト制限値を無視し、最大制限値を適用 最大制限値を無視し、デフォルト制限値だけを適 用 デフォルト制限値と最大制限値の両方を無視し、 リソース制限を適用しない ジョブ投入時に指定するリソース使用制限値は、lsb.queues ファイルで指定した最 大値より小さくなければなりません。ユーザが指定した制限値がキュー レベルの最 大値を超えている場合、ジョブの投入が拒否され、次のメッセージが出力されます。 Cannot exceed queue's hard limit(s). Job not submitted. Platform Clusterware 管理者 199 リソース使用制限を指定する リソース使用制限を指定する それぞれのキューでは、実行中のジョブにリソース使用制限を適用できます。LSF は、オペレーティング システムのほとんどのリソース制限機能に対応しています。 さらに、一部のリソースについては、オペレーティング システムには用意されてい ない制限機能も使用できます。 キュー レベルのリソース使用制限を指定するには、lsb.queues ファイル内のパ ラメータを使用します。 キュー レベルのリソース使用制限を指定する lsb.queues ファイルに設定されている制限は、キューに投入されるすべてのジョ ブに適用されます。ジョブの投入時に指定されるジョブ レベルのリソース使用制限 は、キューに定義されている制限より優先されます。 最大値のみ リソースの最大制限値だけを指定します。 た と え ば、最 大 実 行 時 間 制 限 値 を 指 定 す る に は、lsb.queues フ ァ イ ル 内 の RUNLIMIT パラメータで 1 つの値を指定します。 RUNLIMIT = 10 このキューでは、最大実行時間制限値が 10 分になります。このキューに投入され たジョブは、最大でも 10 分までしか実行できません。RUN 状態になっている時間 が 10 分を超えたジョブは、LSF によって強制終了されます。 指定されている実行時間制限が 1 つだけの場合、bsub -W コマンドで、この値を 超える実行時間制限値を指定して投入されたジョブは、実行が許可されません。 bsub 1-W コマンドを使用しないで投入したジョブは実行を許可されますが、実行 時間が最大実行時間制限値を超えた時点で強制終了されます。 たとえば、lsb.queues ファイルに次のパラメータが設定されているとします。 RUNLIMIT = 10 このキューでは、最大実行時間制限値が 10 分になります。このキューに投入され たジョブは、最大でも 10 分までしか実行できません。 デフォルト制限値と 制限値を 2 つ指定した場合、最初の値が、そのキューに投入されたジョブのデフォ 最大制限値 ルト(soft)制限値で、2 番目の値が最大(hard)制限値になります。これらの値は 両方とも 1 以上の整数で指定します。また、デフォルト制限値は最大制限値より小 さな値を指定する必要があります。最大制限値より大きいと、デフォルト制限値は 無視されます。 デフォルト制限値を使用すると、bsub コマンドでリソース使用制限を指定する必 要がなくなります。 200 Platform Clusterware 管理者 第 17 章 実行時のリソース使用制限 たとえば、デフォルト実行時間制限値と最大実行時間制限値を指定するには、 lsb.queues ファイルの RUNLIMIT パラメータで 2 つの値を指定します。 RUNLIMIT = 10 15 最初の値はデフォルト実行時間制限値になります。この値は、ジョブ固有の実 行時間制限値を指定しないで(bsub -W コマンドを使用しないで)、このキュー に投入したジョブに適用されます。 2 番目の値は最大実行時間制限値になります。この値は、ジョブ固有の実行時 ◆ 間制限値を指定して(bsub -W コマンドを使用して)、このキューに投入した ジョブに適用されます。デフォルト実行時間制限値は最大実行時間制限値より 小さくなければなりません。 次のリソース使用制限については、lsb.queues ファイルにデフォルト値と最大値の 両方を指定できます。 ◆ ◆ ◆ ◆ ◆ ◆ CPULIMIT DATALIMIT MEMLIMIT PROCESSLIMIT RUNLIMIT 2 つの制限を持つホ CPU 時間制限または実行時間制限にデフォルト制限値と最大制限値の両方を指定 ストの指定 した場合、ホストは 1 つしか指定できません。たとえば、次の CPU 時間制限は有 効です(どちらでも同じ結果が得られます)。 ◆ CPULIMIT = 400/hostA 600 ◆ CPULIMIT = 400 600/hostA 次の CPU 時間制限は不正です。 CPULIMIT = 400/hostA 600/hostB 次の実行時間制限は有効です(どちらでも同じ結果が得られます)。 ◆ RUNLIMIT = 10/hostA 15 RUNLIMIT = 10 15/hostA 次の実行時間制限は不正です。 ◆ RUNLIMIT = 10/hostA 15/hostB ジョブ レベルのリソース使用制限を指定する ジョブの投入時に指定されるジョブ レベルのリソース使用制限は、キューに定義さ れている制限より優先されます。 Platform Clusterware 管理者 201 使用可能なリソース使用制限の構文 使用可能なリソース使用制限の構文 コア ファイル サイズ制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -C c o re _lim it in te g e r KB CORELIMIT=limit 該当するバッチ ジョブのプロセス当たりのコア ファイル サイズ制限値(soft 制限 値)を KB 単位で指定します。プロセスのイメージがここで指定したコア制限値を 超えた場合に、コア ファイルの作成が中止されるシステムもあれば、イメージの先 頭から core_limit に指定された KB 数だけがダンプされるシステムもあります。 デフォルト設定では、soft 制限値はありません。 CPU 時間制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -c c pu _lim it [h o u rs :]m in u te s[/h o st_n a m e | /h o st_m o d e l] CPULIMIT=[default] maximum 該当するバッチ ジョブの CPU 時間の制限値(soft 制限値)を c pu _lim it に指定しま す。デフォルト設定では、この制限値はありません。このオプションは、リソース を大量に使用する暴走ジョブを防止するために役立ちます。ジョブの各プロセスが 消費する CPU 時間は、LSF が常に監視しています。 該当するジョブの CPU 時間の合計がこの制限値に達すると、そのジョブのすべて のプロセスに SIGXCPU シグナルが送出されます。そのジョブに SIGXCPU 用のシグ ナ ル ハ ン ド ラ が 含 ま れ て い な け れ ば、ジ ョ ブ の 実 行 が 直 ち に 中 止 さ れ ま す。 SIGXCPU シグナルがアプリケーションによって、処理されたり、ブロックされた り、あるいは無視された場合は、一定期間が経過した後、LSF が SIGINT、SIGTERM、 および SIGKILL シグナルを送出し、ジョブを中止します。 CPU 時間の制限値は、OS によってプロセスごとに適用することも、LSF によって ジョブごとに適用することもできます。どちらを適用するかは、lsf.conf ファイ ルの LSB_JOB_CPULIMIT パラメータで指定します。 CPU 時間の制限値は、実行ホストの CPU 係数に基づいて正規化されます。詳細に ついては、207 ページの「CPU 時間と実行時間の正規化」を参照してください。 構文 c pu _lim it は [h o u r :]m in u te の形式で指定します。この m in u te には 60 以上も指定 できます。したがって、3.5 時間は 3:30 と 210 のどちらの形式でも指定できます。 ここで指定した CPU 時間の制限値は、ジョブの投入元のホストと実行先のホスト の CPU 係数に基づいて自動的に変換されます。CPU 時間の制限値が同じであれば、 ジョブがどのホストで実行されるかに関係なく、処理能力の最大消費量はほぼ同じ になります。 たとえば、CPU 係数が 2 のホストから投入したジョブを、CPU 係数が 3 のホスト で実行した場合を考えてみましょう。その場合は、実行先のホストでは投入元のホ ストの 2/3 の時間で処理が完了するため、このオプションで指定した制限値に 2/3 が掛けられます。 このオプションでホスト名やホスト モデルの指定を省略した場合、CPU 制限値は lsb.params ファイルに指定された DEFAULT_HOST_SPEC パラメータに基づいて 変換されます(DEFAULT_HOST_SPEC パラメータが定義されていない場合は、クラ 202 Platform Clusterware 管理者 第 17 章 実行時のリソース使用制限 スタ内で最も高速なバッチ ホストがデフォルト ホストになります)。ホスト名やホ スト モデルを指定した場合は、その CPU 係数を基準にして、実行先のホストでの CPU 時間の制限値が算出されます。 次の例では、myjob というジョブの実行時間を、DEC3000 ホストの場合に 10 分間 (それ以外のホストではそれに相当する時間)に制限しています。 % bsub -c 10/DEC3000 myjob データ セグメント サイズ制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -D d a ta _lim it in te g e r KB DATALIMIT=[default] maximum 該当するバッチ ジョブのプロセス当たりのデータ セグメント サイズ制限値(soft 制限値)を KB 単位で指定します。sbrk() や malloc() を呼び出して、ここで指 定した値を超えてデータ セグメントを拡張しようとすると、エラーが返されます。 デフォルト設定では、soft 制限値はありません。 ファイル サイズ制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -F file _lim it in te g e r KB FILELIMIT=limit 該当するバッチ ジョブのプロセス当たりのファイル サイズ制限値(soft 制限値)を KB 単位で指定します。このジョブのいずれかのプロセスがファイルへの書き込み を行おうとして、その結果、ファイル サイズがここで指定した値を超える可能性が ある場合、そのプロセスに SIGXFSZ シグナルが送出されます。通常は、この状態 になるとプロセスが終了しますが、この状態を検出して処理を行うこともできま す。デフォルト設定では、soft 制限値はありません。 メモリ制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -M m e m _lim it in te g e r KB MEMLIMIT=[default] maximum メモリ制限値を KB 単位で指定します。 lsf.conf ファイルで LSB_MEMLIMIT_ENFORCE または LSB_JOB_MEMLIMIT パラ メータを y に設定すると、該当するジョブは、消費メモリ量がこのメモリ制限値を 超えた時点で中止されます。それ以外の場合は、メモリ制限の処理はオペレーティ ング システムに任されます。オペレーティング システムによっては、プロセスご とにメモリ制限が適用される場合も、メモリ制限がまったく適用されない場合もあ ります。 LSF のメモリ制限 LS F ファイルで の メ モ リ 制 限 機 能 を 適 用 す る に は、l s f . c o n f の適用 LSB_MEMLIMIT_ENFORCE パラメータを y に設定します。その場合は、実行中のプ ロセスが m e m _lim it 値を超えてメモリを割り当てたときに、そのプロセスを中止す るシグナルが明示的に送出されます。 LSF によるメモリ制限は、lsf.conf ファイルで LSB_JOB_MEMLIMIT パラメータ を y に設定した場合にも有効になります。このパラメータを使用した場合は、 LSB_MEMLIMIT_ENFORCE パラメータを使用した場合と異なり、LSF によるジョブ 単位のメモリ制限だけが有効になり、OS によるプロセス単位のメモリ制限は無効 Platform Clusterware 管理者 203 使用可能なリソース使用制限の構文 になります。LSB_MEMLIMIT_ENFORCE パラメータを y に設定した場合は、LSF に よるジョブ単位のメモリ制限と OS によるプロセス単位のメモリ制限の両方が有効 になります。 LSB_JOB_MEMLIMIT パラメータを使用した場合は、OS によるプロセス単位のメモ リ制限が無効になり、LSF によるジョブ単位のメモリ制限だけが有効になります。 この場合、ジョブの全プロセスの合計割り当てメモリが制限値を超えると、LSF は SIGINT、SIGTERM、SIGKILL の順番でシグナルを送出し、ジョブを強制終了します。 UNIX では、SIGINT、SIGTERM、SIGKILL の各シグナルの送出間隔を、lsb.params ファイル内の JOB_TERMINATE_INTERVAL パラメータで設定できます。 OS メモリ制限の適 OS のメモリ制限機能を適用した場合、通常はプロセスを最後まで実行できます。 用 LSF は m e m _lim it 値を OS に渡し、OS はこの値に基づいてシステム スケジューラ やメモリ アロケータを制御します。メモリに余裕があれば、プロセスにこの値を上 回るメモリが割り当てられますが、メモリに余裕がなくなると、m e m _lim it に設定 された値を超えているプロセスからメモリが奪われ、そのスケジューリング優先順 位が下げられます(nice 値が変更されます)。 OS のメモリ制限機能は、setrlimit() の RLIMIT_RSS オプションに対応してい るシステムでしか使用できません。 プロセス制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -p pro c e ss_lim it in te g e r KB PROCESSLIMIT=[default] maximum ジョブ全体に対するプロセス数の制限値を pro c e ss_lim it に設定します。デフォルト 設定では、制限はありません。プロセス数が指定された制限値を超えると、その ジョブは終了します。 特定のジョブに割り当て可能な並行プロセスの数を制限します。 デフォルト制限値が指定されている場合、ジョブ レベルのプロセス数制限値を指定 せずにキューに投入されたジョブは、デフォルトのプロセス数制限値に達した時点 で中止されます。 制限値を 1 つだけ指定した場合、その値は、最大(hard)プロセス数制限値になり ます。制限値を 2 つ指定した場合は、最初の値がデフォルト(soft)制限値で、2 番 目の値が最大制限値になります。 実行時間制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -W ru n _lim it [h o u rs :]m in u te s[/h o st_n a m e | /h o st_m o d e l] RUNLIMIT=[default] maximum 実行時間制限は、あるジョブが実行を終了するまでにかけられる最大時間数を制限 します。該当するジョブの実時間での実行時間制限値を指定します。デフォルト設 定では、この制限はありません。該当するジョブが RUN 状態になっている時間の 合計がこの制限値に達すると、そのジョブに USR2 シグナルが送出されます。この シグナルが送出されてから 10 分以内に終了しなければ、ジョブの実行が中止され ます。デッドライン制約スケジューリングを使用している場合は、この値はジョブ の想定所用時間としても使用されます。その場合、終了期限までの時間がこの値以 上でなければ、ジョブは開始されません。 204 Platform Clusterware 管理者 第 17 章 実行時のリソース使用制限 スタック セグメント サイズ制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -S sta c k_lim it in te g e r KB STACKLIMIT=limit 該当するバッチ ジョブのプロセス当たりのスタック セグメント サイズ制限値(soft 制限値)を KB 単位で指定します。sbrk() を呼び出して、ここで指定した値を超 えてスタック セグメントを拡張しようとすると、該当するプロセスが終了します。 デフォルト設定では、この制限値はありません。 仮想メモリ(スワップ)制限 ジョブ構文(bsub) キュー構文(lsb.queues) フォーマット / 単位 -v sw a p _lim it in te g e r KB SWAPLIMIT=limit ジョブ全体に対するプロセス仮想メモリの総容量の制限値を sw a p_lim it に KB 単位 で設定します。デフォルト設定では、制限はありません。仮想メモリ量が指定され た制限値を超えると、そのジョブは終了します。 ジョブに含まれるプロセス数とは関係なく、この制限値はジョブ全体に適用されま す。 例 キュー レベルの制 ◆ 限 CPULIMIT = 20/hostA 15 最初の値が CPU 時間のデフォルト制限値で、2 番目の値が CPU 時間の最大制 限値です。 ただし、ここで指定しているデフォルト制限値は、最大制限値を超えているの で、無視されます。 ◆ CPULIMIT = 10/hostA この例では、2 番目の値が指定されていないので、CPU 時間のデフォルト制限 は指定されないことになります。ここで指定している値は、CPU 時間のデフォ ルト制限値と最大制限値の両方として使用されます。 ◆ RUNLIMIT = 10/hostA 15 最初の値が実行時間のデフォルト制限値で、2 番目の値が実行時間の最大制限 値です。 最初に指定した値がデフォルト実行時間制限値で、ジョブ投入時に実行時間制 限が指定されなかった(bsub コマンドに -W オプションを付けなかった)ジョ ブに使用されます。 ◆ RUNLIMIT = 10/hostA デフォルト実行時間制限値は指定されません。ここで指定している値は、デフォ ルト制限値と最大制限値の両方として使用されます。 Platform Clusterware 管理者 205 使用可能なリソース使用制限の構文 206 ジョブ レベルの制 ◆ 限 % bsub -M 5000 myjob 使用可能メモリを 5000 KB に制限して、myjob というジョブを投入していま す。 ◆ % bsub -W 14 myjob ジョブ myjob は 14 分間で実行できるという前提で投入されています。bsub -W で指定されている実行時間制限値がキューに設定されている制限値を超え ていなければ、このジョブの実行が許可されますが、超えている場合は、実行 を拒否されます。 Platform Clusterware 管理者 第 17 章 実行時のリソース使用制限 CPU 時間と実行時間の正規化 CPU 時間制限と実行時間制限をプラットフォームに関係なく設定できるようにす るために、LSF には処理に関与しているホストの CPU 係数に基づいて、制限値を変 換する機能があります。ジョブが実行ホストにディスパッチされると、実行ホスト の CPU 係数に基づいて、制限値が正規化されます。 実行ホストでの実際の制限時間は、指定された CPU 時間または実行時間の正規化 された制限値に正規化ホストの CPU 係数を掛けて、その値を実行ホストの CPU 係 数で割ったものになります。 正規化ホスト CPU 時間または実行時間だけを指定し、ホスト名やホスト モデルを指定しなかっ た場合は、キュー レベルで(lsb.queues ファイルの DEFAULT_HOST_SPEC パラ メータで)定義されていれば、そのホストが CPU 時間のデフォルト正規化ホスト になります。このホストが未定義の場合は、クラスタ レベルで(lsb.params ファ イルの DEFAULT_HOST_SPEC パラメータで)定義されていれば、そのホストが CPU 時間のデフォルト正規化ホストになり、このホストも未定義の場合は、サブミッ ション ホストが代わりに使用されます。 例 CPULIMIT=10/hostA hostA の CPU 係数が 2、hostB の CPU 係数が 1 だと仮定します(hostA のほう が hostB より高速です)。この例では、hostA(または CPU 係数が 2 の任意のホス ト)での実際の制限時間を 10 分に設定しています。ただし、hostB が実行ホスト になると、hostB での実際の制限時間は 20 分(10 * 2 / 1)になります。 CPU 時間制限と実行時間制限の正規化ホスト CPU 時間制限と実行時間制限では、有効なホスト係数のうち、最初に検出されたも のが使用されます。有効なホスト係数にするには、ホスト名を指定する部分で、LSF クラスタに所属している有効なホスト名を指定する必要があります。このホスト係 数は、指定した制限が有効でない場合にも使用されます。 CPU 時間制限と実行時間制限で別々のホストを指定した場合は、CPU 時間制限で指 定したホストが適用されます。 CPU 時間制限や実行時間制限でホストやホスト モデルを指定しなかった場合は、デ フォルト正規化ホストは次の順に決定されます。 1 2 3 lsb.queues ファイル内の DEFAULT_HOST_SPEC パラメータで指定されたホ スト lsb.params ファイル内の DEFAULT_HOST_SPEC パラメータで指定されたホ スト ファイルと ファイルのどちらにも lsb.queues lsb.params DEFAULT_HOST_SPEC パラメータが指定されていない場合は、CPU 係数が最大 のホスト Platform Clusterware 管理者 207 CPU 時間と実行時間の正規化 208 Platform Clusterware 管理者 第 18 章 負荷しきい値 内容 ◆ ◆ 210 ページの「ジョブの自動中断」 212 ページの「中断条件」 Platform Clusterware 管理者 209 ジョブの自動中断 ジョブの自動中断 LSF で実行したジョブは、実行先のホストの負荷の状態に応じて中断できます。そ れには、ホストごとやキューごとに一連の中断条件を設定しておきます。実行先の ホストの負荷の状態が、該当するホストやキューの中断条件を上回ると、負荷を軽 くするために、そのホストで実行されているジョブが 1 つ以上中断されます。 LSF は、ジョブを中断するときに SUSPEND アクションを呼び出します。デフォル トの SUSPEND アクションでは、中断するジョブに SIGSTOP シグナルが送出され ます。 中断されたジョブは、デフォルト設定では負荷レベルが中断条件を下回ったときに 再開されます。チェックポイントを実行可能なジョブや、再実行が可能なジョブに ついては、代わりに実行先のホストを自動的に切り替えることもできます。 中断しきい値を設定していない負荷インデックスは、ジョブを中断するかどうかの 判断材料としては使われません。 中断しきい値は、あるキューを他のキューより優先させる目的でも使用できます。 たとえば、次のような場合を考えてみましょう。r1m(1 分間の CPU 実行キュー長) のスケジューリングしきい値が 0.25、中断しきい値が 1.75 の優先順位の低いキュー があります。マシンがアイドル状態のときに、このキューから 1 つのジョブが開始 されます。その結果として r1m の値が 0.25 から 1.25 に上昇します。このときに、 r1m のスケジューリングしきい値が 1.5 で、中断しきい値が無制限の優先順位の高 いキューから、同じホストに別のジョブが送出され、r1m の値が 2.25 まで上昇した とします。この値は優先順位の低いキューの中断しきい値を超えているため、結果 として、キューから送出されていたジョブが中断されます。もう一方のジョブは続 行されているため、r1m の値は 0.25 以下には下がりません。このジョブが終了する と、r1m の値がアイドル レベルまで下がり、中断されていた優先順位の低いジョブ が再開されます。 LSF は、ジョブの実行中に実行先のホストの負荷レベルを定期的にチェックします。 いずれかの負荷インデックスが、該当するホストやキューの中断しきい値を上回っ た場合は、そのジョブが中断されます。一旦中断されたジョブは、負荷レベルがス ケジューリングしきい値の条件を満たすまで中断されたままになります。 LSF は、定期的にホストの負荷レベルを収集します。この収集間隔は、lsb.params ファイル内の SBD_SLEEP_TIME パラメータで定義します。収集された負荷レベル は、ホスト上で実行中のジョブごとに、ホストやキューの中断条件と比較されます。 負荷の増大により、これらの中断条件のいずれかが満たされた場合は、そのジョブ が中断されます。ジョブが中断されるのは、ホストの負荷レベルが、該当するジョ ブの中断しきい値を上回っている場合に限られます。 LSF がジョブを中断してから、LIM から見たホストの負荷が変化するまでには時間 的なずれがあります。LIM から見たホストの負荷が、ジョブの中断を反映した値に なるまでの時間を稼ぐため、LSF では同じホスト上のジョブはディスパッチ オーダ ごとに 1 つずつしか中断されません。 ジョブを中断するかどうかを決定する際には、優先順位が最も低いキューから送出 されたジョブが最初にチェックされます。同じホストで 2 つのジョブを実行してい て、そのホストが過度のビジー状態になった場合は、優先順位の低いほうのジョブ が先に中断されます。次のディスパッチ オーダになっても負荷レベルが依然として 高い場合は、優先順位の高いほうのジョブも中断されます。 ジョブがそのジョブ自身の負荷のために中断された場合は、負荷は直ちに減少しま す。負荷がしきい値の範囲内に戻ると、そのジョブが再開され、その結果として負 荷が増加すると、そのジョブが再び中断されます。 210 Platform Clusterware 管理者 第 18 章 負荷しきい値 例外 次の場合は、負荷レベルが高まってもジョブは自動的には中断されません。 ◆ ホスト上で実行中のジョブが 1 つしかなく、そのホストが対話型処理に使用さ れていない場合 ホスト上で実行中のジョブが 1 つしかない場合は、そのジョブは中断されませ ん。ただし、そのホスト上の対話型処理がアイドル状態ではない場合(it 負荷 インデックス値が 1 分未満の場合)を除きます。すなわち、ホスト上で一旦 ジョブが開始されると、そのホストを対話型ユーザが使用している場合を除い て、少なくとも 1 つのジョブは実行が継続されます。このジョブが中断された 場合は、対話型ユーザの処理が妨害されるのを防ぐため、スケジューリング条 件がすべて満たされるまではジョブが再開されません。 ◆ ホストのページング率が高まり、そのホストが対話型処理に使用されていない 場合 該当するホストを対話型ユーザが使用している場合は、ページング率が高まる とジョブが中断され、対話型処理の応答時間が確保されます。これに対して、 対話型ユーザがいない場合は、pg(ページング率)負荷インデックスは無視さ れます。この振る舞いは、lsb.params ファイル内の PG_SUSP_IT パラメータ で制御できます。すなわち、対話型処理がアイドル状態になっている時間が、 このパラメータで指定した値(単位は分)を超えると、pg 負荷インデックスと 中断しきい値との比較が行われなくなります。 Platform Clusterware 管理者 211 中断条件 中断条件 LSF では、ジョブの中断条件をさまざまな方法で指定できます。ホスト レベルの中 断条件は負荷しきい値として設定しますが、キュー レベルの中断条件は負荷しきい 値として設定することも、lsb.queues ファイル内の STOP_COND パラメータで 設定することも、その両方を組み合わせて設定することもできます。 中断条件で最もよく使用する負荷インデックスには、CPU 実行キュー長(r15s、 r1m、r15m)、ページング率(pg)、アイドル時間(it)の 3 種類があります。(sw p) インデックスと(tmp)インデックスも、ジョブを中断するかどうかの判断材料と して使用されます。 対話型ユーザを優先するため、it ( アイドル時間 ) インデックスの中断しきい値 は 0(ゼロ)以外の値に設定します。このようにすると、対話型ユーザがアクティ ブになるとジョブが直ちに(約 1.5 分以内に)中断され、ホストのアイドル時間が it インデックスのスケジューリング条件で指定した値になったときに、そのジョブ が再開されます。 ページング率の中断しきい値を最適化するには、使用するアプリケーションの振る 舞いを把握することが重要です。まず、アイドル状態のマシンで、lsload コマン ドを使用してページング率をチェックします。次に、そのマシンでアプリケーショ ンを起動します。ページング率がどのように変化するかを確認します。アイドル状 態のページング率からアクティブなページング率を引いた値が、そのアプリケー ションのページング率になります。ページング率の中断しきい値を決定する場合 は、この値の少なくとも 1.5 倍の余裕を見込んでください。ページング率のスケ ジューリングしきい値を超えない限り、ページング率の値に関係なくジョブをスケ ジューリングできます。したがって、ページング率の中断しきい値は、最低でもこ のスケジューリングしきい値に、アプリケーションのページング率の 1.5 倍を加え た値にします。これだけのマージンをとらないと、スケジューリングされたジョブ が、そのジョブ自身のページングによって直ちに中断されてしまう場合がありま す。 CPU 実行キューの実効長の条件も、ページング率と同じ要領で指定します。大量の CPU 処理能力が必要な順次ジョブでは、実行キューの実効長のインデックスはジョ ブごとに約 1 ずつ増加します。複数のプロセスを使用するジョブでは、何回か試験 的な実行を行って、このインデックスに対するジョブの影響を確認します。ページ ング率の場合と同様に、この中断しきい値を、最低でもスケジューリングしきい値 にジョブ当たりの負荷の 1.5 倍を加えた値に設定してください。 キュー レベルの負荷しきい値を設定する キュー定義(lsb.queues ファイル)を使用して、0 個以上の負荷インデックスの しきい値を指定できます。しきい値を指定していない負荷インデックスは、ジョブ のスケジューリングには影響しません。 構文 次の構文を使用し、各行に負荷インデックスを 1 つずつ指定します。 load_index = loadSched/loadStop load_index は負荷インデックス名です。たとえば、1 分間の CPU 実行キュー長 は r1m、ページング率は pg と指定します。loadSched はこの負荷インデックス のスケジューリングしきい値、loadStop はこの負荷インデックスの中断しきい値 です。ホストが loadSched の条件を満たしている場合は、そのホストにジョブが 212 Platform Clusterware 管理者 第 18 章 負荷しきい値 ディスパッチされ、そのホストで中断されているジョブが再開されます。また、 loadStop の条件が成立している場合は、そのホストで実行されているジョブが中 断されます。 loadSched しきい値と loadStop しきい値では、単純な AND/OR ロジックを使 用して条件を指定できます。たとえば、次のような指定が可能です。 MEM=100/10 SWAP=200/30 こ の 例 で は、loadSched 条 件 は mem>=100 && swap>=200 と 解 釈 さ れ、 loadStop 条件は mem < 10 || swap < 30 と解釈されます。 原則 ◆ ◆ CPU 実行キュー長(r15s、r1m、r15m)の条件は、lsload -E コマンドで報 告される実行キューの実効長と比較されます。マルチプロセッサ ホストでは、 実効長は正規化された値になります。これらのしきい値は、シングルプロセッ サ ホストを想定した値に設定してください。 キューごとの負荷しきい値が矛盾しないように注意してください。優先順位の 低いキューの中断しきい値を、優先順位の高いキューの中断しきい値より高く すると、優先順位の高いキューのジョブのほうが先に中断されてしまいます。 ホスト レベルの負荷しきい値を設定する lsf.cluster.cluster_name ファイル内の Hosts セクションで指定する負荷 しきい値としては使用できない。 キュー レベルの中断条件を設定する ジョブの中断条件は、キュー レベルの STOP_COND パラメータで指定できます。 この値は、リソース要件文字列の形式で定義します。その中の select セクションが ジョブを中断する条件として使われます。それ以外のセクションはすべて無視され ます。 このパラメータの機能は loadStop と同じですが、loadStop よりも複雑な条件 を指定できます。 STOP_COND パ ラ メ ー タ と loadStop し き い 値 の 両 方 を 指 定 し た 場 合 は、 STOP_COND の結果が TRUE になるか、負荷インデックスが loadStop しきい値 を超過した場合にジョブが中断されます。 例 次の例では、デスクトップ マシンのアイドル時間と、コンピュータ サーバの空き メモリ容量と空きスワップ容量に基づいてジョブが中断されます。ここで、cs は、 lsf.shared ファイルで定義し、lsf.cluster.cluster_name ファイルで指定す る Boolean リソースで、ホストがコンピュータ サーバかどうかを表しています。 Begin Queue . STOP_COND= select[((!cs && it < 5) || (cs && mem < 15 && swap < 50))] . End Queue Platform Clusterware 管理者 213 中断条件 ホスト レベルとキュー レベルの中断条件を参照する ホスト レベルやキュー レベルの中断条件を参照するには、bhosts -l コマンドや bqueues -l コマンドを使用します。 ジョブ レベルの中断条件を参照する 特定のジョブだけに適用されるジョブ レベルの中断条件を指定すると、ホスト レ ベルやキュー レベルのしきい値をさらに制限できます。この中断条件を参照するに は、bjobs -l コマンドを使用します。 中断理由を参照する bjobs -lp コマンドを使用すると、ジョブを中断する原因になった負荷しきい値 と、スケジューリング パラメータを同時に参照できます。 STOP_COND パラメータを使用するかどうかで、bjobs コマンドを実行したときに 中断理由が表示されるかどうかが決まります。キュー レベルで STOP_COND パラ メータを指定し、かつ loadStop しきい値を指定しなかった場合は、負荷インデッ クスごとの中断理由は表示されなくなります。 中断中のジョブを再開する ホストが過負荷になったり、対話型処理が妨害されたり、より重要なジョブを実行 する必要がある場合は、実行中のジョブが中断されます。ホストの過負荷が解消さ れた場合は、中断されたジョブの実行を再開する必要があります。 LSF は、ジョブを自動的に再開するときに、RESUME アクションを呼び出します。 デフォルトの RESUME アクションでは、SIGCONT シグナルが送出されます。 ホスト上に中断中のジョブがある場合は、LSF はディスパッチ オーダごとに負荷レ ベルをチェックします。 これらの負荷レベルがキューやホストのスケジューリングしきい値の範囲内に収 ま っ て い て、か つ キ ュ ー レ ベ ル の 再 開 条 件(l s b . q u e u e s フ ァ イ ル 内 の RESUME_COND パラメータ)がすべて満たされている場合は、そのジョブが再開さ れます。 RESUME_COND パラメータが未定義の場合は、loadSched しきい値がジョブを再 開するかどうかの条件として使われます。すなわち、loadSched しきい値の条件 がすべて成立している場合は、該当するジョブが再開されます。RESUME_COND パ ラメータを定義している場合は、loadSched しきい値は無視されます。 ジョブを再開するかどうかを決定する際には、優先順位が最も高いキューから送出 されたジョブが最初にチェックされます。ホストが再び過負荷になるのを防ぐた め、ジョブはディスパッチ オーダごとに 1 つずつしか再開されません。 再開条件を指定する 中 断 中 の ジ ョ ブ を 再 開 す る 条 件 を 指 定 す る に は、l sb . qu e ue s フ ァ イ ル で RESUME_COND パラメータを指定します。 このパラメータの値は、リソース要件文字列の形式で定義します。その中の select セクションがジョブを再開する条件として使われます。それ以外のセクションはす べて無視されます。 214 Platform Clusterware 管理者 第 18 章 負荷しきい値 再開しきい値を参照する ジョブを再開するかどうかを決定するときに使用されるスケジューリングしきい 値を参照するには、bjobs -l コマンドを使用します。 Platform Clusterware 管理者 215 中断条件 216 Platform Clusterware 管理者 第 19 章 実行前コマンドと実行後コマンド ジョブを投入するときは、任意で実行前および実行後コマンドを指定することがで きます。実行前コマンドまたは実行後コマンドは、ジョブの開始前またはジョブ終 了後に実行する任意のコマンドです。 内容 ◆ ◆ 218 ページの「実行前および実行後コマンドについて」 220 ページの「実行前および実行後コマンドの設定」 Platform Clusterware 管理者 217 実行前および実行後コマンドについて 実行前および実行後コマンドについて バッチ ジョブは、任意で実行前および実行後コマンドを指定して投入することがで きます。実行前コマンドおよび実行後コマンドには、ジョブの開始前またはジョブ 終了後に実行される任意のコマンド行を指定できます。 バッチ ジョブの中には、LSF では直接サポートしていないリソースを必要とするも のもあります。さまざまな状況に対応するために適切な実行前および実行後コマン ドを使用することができます。 テープ装置などの装置の確保 ジョブ用のスクラッチ ディレクトリの作成と削除 ◆ ◆ カスタマイズされたスケジューリング ソフトウェア ライセンスの可用性チェック ◆ SMP マシンの特定のプロセッサで実行するジョブの割り当て ◆ デフォルトでは、実行前コマンドと実行後コマンドは、バッチ ジョブと同じユーザ ID、環境、ホームおよび作業ディレクトリで実行されます。標準の実行パスにない コマンドに関しては、フルパス名を指定する必要があります。 ◆ 実行前コマンド 実行前コマンドは、LSF に直接設定できないジョブ開始の決定に使用することがで きます。LSF では、ジョブ レベルとキュー レベルのどちらの実行前コマンドも使 用できます。 実行前コマンドは、その終了状態を使用して LSF に情報を返します。実行前コマン ドが指定されている場合、指定された実行前コマンドが終了状態ゼロ(0)を返す まで、ジョブはキューの中に保持されます。 実行前コマンドがゼロ以外の状態で終了した場合、バッチ ジョブはディスパッチさ れません。ジョブは PEND 状態に戻り、LSF はそのホストに別のジョブをディス パッチします。ジョブが保留されている間、他のジョブが先に処理されます。LSF が次にジョブのディスパッチを試みるときに、このプロセスが繰り返されます。 実行前コマンドが 99 の値で終了した場合、ジョブは PEND 状態にはならず、終了 します。これによって、実行前コマンドが失敗した場合、ジョブを異常終了させる という選択肢が与えられます。 LSF では、実行前コマンドによる副作用はないことを前提としています。たとえば、 実行前コマンドでソフトウェア ライセンスやその他のリソースを確保する場合、同 じバッチ ジョブに同じリソースを再度確保することはできません。 218 Platform Clusterware 管理者 第 19 章 実行前コマンドと実行後コマンド 実行後コマンド 実行後コマンドを指定すると、そのコマンドはジョブが終了した後で実行されま す。 通常、実行後コマンドは、実行前コマンドとジョブの実行によって残された状態を クリアするために使用されます。実行後コマンドは、キュー レベルでのみ使用でき ます。 ジョブ レベル コマンド bsub -E オプションは、バッチ ジョブを開始する前に実行する任意のコマンドを 指定します。LSF がジョブの実行に適したホストを検出すると、そのホスト上で実 行前コマンドが実行されます。実行前コマンドの実行が正常に終了すると、バッチ ジョブが開始されます。 ジョブ レベルの実行後コマンドはサポートしていません。 キュー レベル コマンド 状況によっては(たとえば、ライセンス チェック時など)、bsub の -E オプション を指定して個々のジョブを投入するよりも、キュー レベルの実行前コマンドを指定 したほうがよい場合もあります。 キュー レベルのコマンドは、キューからジョブが実行される前後に、実行ホスト上 で実行されます。 LSF 管理者は、lsb.queues の PRE_EXEC および POST_EXEC パラメータを使用 して、キュー レベルの実行前および実行後コマンドを設定できます。 実行後のジョブの状態 ジョブによっては、後処理が行われるまでは終了したとはみなせない場合がありま す。たとえば、ジョブの終了後に、実行後ジョブ スクリプトを介してジョブを終了 させたり、ジョブ ファイルのクリーン アップを行ったり、出力を転送したりする 場合があります。 DONE または EXIT というジョブ状態からは、後処理が完了したかどうかは判断で きません。したがって、処理に依存するジョブが時期尚早に開始される可能性があ ります。そこで、bsub -w コマンドに post_done および post_err キーワード を使用して、ジョブの後処理に対してジョブ依存の条件を指定します。各キーワー ドに対応するジョブ状態、POST_DONE および POST_ERR に後処理の状態が示され ます。 bhist コマンドを使用して、POST_DONE および POST_ERR 状態を表示します。後 処理のリソース使用率は、ジョブのリソース使用率には含まれません。 ジョブが終了した後は、後処理に対してジョブ制御を行うことはできません。後処 理の終了コードは、LSF Batch に報告されません。繰り返しジョブの後処理が繰り 返し期間より長くなることはありません。 Platform Clusterware 管理者 219 実行前および実行後コマンドの設定 実行前および実行後コマンドの設定 実行前および実行後コマンドは、ジョブ レベルで設定するか、またはキューに入れ る前に設定することができます。 ジョブ レベル コマンド ジョブ レベルの実行前コマンドには、設定は不要です。bsub -E オプションを使 用して、ジョブを開始する前に実行する任意のコマンドを指定します。 例 次の例は、テープ装置を必要とするバッチ ジョブを示しています。指定されたテー プ装置の準備ができている場合、ユーザ プログラム tapeCheck は、状態ゼロで終 了します。 % bsub -E "/usr/share/bin/tapeCheck /dev/rmt01" myJob キュー レベル コマンド キュー定義(lsb.queues)に PRE_EXEC および POST_EXEC キーワードを使用 して、実行前および実行後コマンドを指定します。 キュー レベルで実行前および実行後コマンドを設定するときは、次の点を考慮する 必要があります。 ◆ ◆ ◆ ◆ ◆ 実行前コマンドがゼロ以外の終了コードで終了した場合、その処理は失敗した とみなされ、そのジョブはキューの先頭に再登録されます。この機能を使用し て、ジョブをディスパッチするための条件が満たされていない場合は実行前コ マンドを失敗させることで、スケジュールをカスタマイズすることができます。 ジョブに設定されている他の環境変数も、実行前および実行後コマンドに設定 することができます。 実行前コマンドが指定されているキューからジョブがディスパッチされると、 LSF はジョブがディスパッチされたキューに定義されている実行後コマンドを 記憶します。後で、そのジョブが他のキューに切り替えられたり、そのキュー の実行後コマンドが変更された場合でも、LSF はこのジョブの元の実行後コマ ンドを実行します。 実行後コマンドが実行されると、環境変数 LSB_JOBEXIT_STAT にはそのジョ ブの終了状態が設定されます。終了状態のフォーマットについては、wait(2) コマンドのマニュアル ページを参照してください。 ジョブの実行環境のセットアップが失敗したためにキューに再登録された場合 や、ジョブがキューの REQUEUE_EXIT_VALUES のいずれかで終了した場合も、 実行後コマンドが実行されます。 LSB_JOBPEND 環境変数は、ジョブがキューに再登録されたときに設定されま す。ジョブの実行環境がセットアップできなかった場合、LSB_JOBEXIT_STAT は 0 に設定されます。 詳細については、161 ページの「ジョブのキューへの自動再登録」を参照して ください。 ◆ キュー レベルとジョブ レベルの両方の実行前コマンドが指定されている場合、 キュー レベルの実行前コマンドが実行された後で、ジョブ レベルの実行前コ マンドが実行されます。 実行前および実行後コマンドの構成行の全コンテンツが /bin/sh -c で実行され るため、コマンドでシェル機能を使用することができます。 220 Platform Clusterware 管理者 第 19 章 実行前コマンドと実行後コマンド 次に有効な例を示します。 PRE_EXEC = /usr/share/lsf/misc/testq_pre >> /tmp/pre.out POST_EXEC = /usr/share/lsf/misc/testq_post | grep -v "Hey!" 実行前および実行後コマンドは /tmp で実行されます。 標準入力、標準出力、およびエラーは、/dev/null に設定されます。実行前およ び実行後コマンドからの出力は、明示したデバッグ用のファイルに転送することが できます。 PATH 環境変数は、次のように設定されます。 PATH='/bin /usr/bin /sbin /usr/sbin' 例 次のキューは、実行前コマンドに /usr/local/lsf/pri_prexec を、実行後コ マンドに /usr/local/lsf/pri_postexec を指定しています。 Begin Queue QUEUE_NAME PRIORITY NICE PRE_EXEC POST_EXEC End Queue = = = = = priority 43 10 /usr/share/lsf/pri_prexec /usr/share/lsf/pri_postexec LSB_PRE_POST_EXEC_USER パラメータ(lsf.sudoers) デフォルトでは、実行前コマンドも実行後コマンドもユーザとして実行されます。 lsf.sudoers の LSB_PRE_POST_EXEC_USER パラメータを使用すると、キュー レベルの実行前および実行後コマンドに別のユーザ ID を指定することができま す。 例 たとえば、実行前および実行後コマンドで root 許可が必要な特権命令を実行する 場合、次のように指定します。 LSB_PRE_POST_EXEC_USER=root 『Pla tfo rm LSF Re fe re n c e 』を参照してく lsf.sudoers ファイルの詳細については、 ださい。 Platform Clusterware 管理者 221 実行前および実行後コマンドの設定 222 Platform Clusterware 管理者 第 20 章 ジョブ スタータ ジョブ スタータは、ジョブのための環境をセットアップし、そのジョブを実行する LSF コマンドを呼び出す特殊なシェル スクリプトあるいは実行可能プログラムで す。本章では、LSF でジョブ スタータを実行する 2 とおりの方法を紹介し、それを セットアップし、使用する方法について説明します。 内容 ◆ ◆ ◆ 224 ページの「ジョブ スタータの概要」 226 ページの「キュー レベルのジョブ スタータ」 228 ページの「ジョブ スタータによる実行環境の制御」 Platform Clusterware 管理者 223 ジョブ スタータの概要 ジョブ スタータの概要 ジョブの中には、特別な環境で実行しなければならないものや、実行前にある種の セットアップが必要なものがあります。シェル環境では、ジョブ セットアップは、 目的のジョブを起動するための呼び出しが組み込まれたラッパー シェル スクリプ ト ファイルに書き込まれるのが一般的です。 ジョブ スタータとは、特定のラッパー スクリプトあるいは実行可能プログラムの ことで、通常はジョブのための環境設定を行ってから、そのジョブを呼び出します。 呼び出されたジョブは、ジョブ スタータによって作成された実行環境を継承しま す。LSF は、ジョブではなく、ジョブ スタータのプロセスを制御します。ジョブ ス タータの典型的な使用例としては、Alias Renderer または Rational ClearCase などの 特定のアプリケーション環境で使用するために LSF をカスタマイズする場合が挙 げられます。 ジョブ スタータを実行する 2 とおりの方法 LSF では、2 とおりの方法でジョブ スタータを実行します。どちらのジョブ スター タでも同様の結果が得られますが、機能的に多少の違いがあります。 コマンド レベルの これは、ユーザ定義のジョブ スタータで、lsrun、lsgrun、または ch を使用し ジョブ スタータ て投入される対話型ジョブを実行します。コマンド レベルのジョブ スタータは、 bsub -I によって実行される対話型バッチ ジョブも含め、バッチ ジョブには使用 できません。 対話型ジョブに使用するジョブ スタータを指定するには、LSF_JOB_STARTER 環境 変数を使用します。詳細については、228 ページの「ジョブ スタータによる実行環 境の制御」を参照してください。 キュー レベルの これは、LSF 管理者によって定義され、JOB_STARTER パラメータ セットで定義さ ジョブ スタータ れたキューに投入されたバッチ ジョブを実行します。キュー レベルのジョブ ス タータは bsub を使用して実行します。 キュー レベルのジョブ スタータは lsb.queues 内のキュー定義に設定されます。 詳細については、226 ページの「キュー レベルのジョブ スタータ」を参照してく ださい。 実行前コマンドとジョブ スタータの違い ジョブ スタータは実行前コマンドとは異なります。実行前コマンドは正常に実行さ れ、LSF ジョブが開始する前に終了する必要があります。実行前コマンドはジョブ を投入するように LSF に合図することはできますが、そのプロセスはジョブとは関 係がないので、ジョブを制御したり、ジョブの実行環境を変更することはありませ ん。一方、ジョブ スタータは LSF が制御するプロセスで、LSF を呼び出し、ジョブ の実行環境を制御します。 詳細については、第 19 章、 「実行前コマンドと実行後コマンド」を参照してくださ い。 224 Platform Clusterware 管理者 第 20 章 ジョブ スタータ 例 次に、ジョブ スタータの例をいくつか紹介します。 ◆ ◆ ◆ UNIX では、/bin/ksh -C と定義されたジョブ スタータは、ジョブを Korn シェル環境で実行させる。 lsb.queues の JOB_STARTER パラメータを $USER_STARTER に設定すると、 ユーザは USER_STARTER 環境変数を定義することにより、独自のジョブ スター タを定義できるようになる。 ジョブ スタータに make clean を設定すると、ユーザ ジョブの前に make clean コマンドが実行される。 Platform Clusterware 管理者 225 キュー レベルのジョブ スタータ キュー レベルのジョブ スタータ LSF 管理者は、個々のキュー用のジョブ スタータを定義して、ジョブを実行するた めの特別な環境を作成できます。キュー レベルのジョブ スタータは、必要なセッ トアップを行う実行可能プログラムを指定し、セットアップが完了した時点でジョ ブを実行します。lsb.queues の JOB_STARTER パラメータを使用して、キュー のジョブ スタータになるコマンドまたはスクリプトを指定します。 このセクションでは、キュー レベルのジョブ スタータをセットアップし、使用す る方法について説明します。 キュー レベルのジョブ スタータは対話型ジョブには使用できません。ただし、対 話型バッチ ジョブとしてキューに投入された対話型ジョブは例外です。対話型バッ チ ジョブの詳細については、第 23 章、 「bsub を使用した対話型ジョブ」を参照し てください。 キュー レベルのジョブ スタータの設定 lsb.queues の JOB_STARTER パラメータを使用して、キュー定義にキュー レベ ルのジョブ スタータを指定します。このキューに投入されたジョブは、すべてジョ ブ スタータを使用して実行されます。ジョブは、バッチ デーモン プロセスによっ て開始される代わりに、指定されたジョブ スタータ プロセスによって呼び出され ます。 たとえば、次のように指定します。 Begin Queue . JOB_STARTER = xterm -e . End Queue このキューに投入されたジョブは、すべて xterm 端末エミュレータを使用して実 行されます。 JOB_STARTER パラメータ(lsb.queues) キュー定義(lsb.queues)内の JOB_STARTER パラメータのフォーマットは次の ようになっています。 JOB_STARTER = starter [starter] [%USRCMD] [starter] 文字列 sta rte r は、このジョブを起動するために使用するコマンドまたはスクリプト を表します。ここには、ジョブを入力引数として受け取ることのできる任意の実行 可能プログラムを指定できます。任意で、文字列を追加指定することもできます。 ジョブが開始されると、LSF は JOB_STARTER コマンドを実行し、ジョブ コマンド が含まれるシェル スクリプトを引数としてジョブ スタータに渡します。ジョブ ス タータは、いくつかの処理を行ってから、ジョブ コマンドが組み込まれたシェル スクリプトを実行します。コマンドは /bin/sh -c で実行され、有効な Bourne シェル構文を組み込むこともできます。 226 Platform Clusterware 管理者 第 20 章 ジョブ スタータ %USRCMD 文字列 特殊文字列 %USRCMD は、ジョブ コマンド行内のジョブ スタータ コマンドの位置 を示します。デフォルトでは、ユーザ コマンドはジョブ スタータの後で実行され るので、通常、%USRCMD 文字列は必要ありません。たとえば、次の 2 つのジョブ スタータでは、同じ結果が得られます。 JOB_STARTER = /bin/csh -c JOB_STARTER = /bin/csh -c %USRCMD %USRCMD 文字列は、引用符で囲んだり、その後にコマンドを追加することもでき ます。次に例を示します。 JOB_STARTER = /bin/csh -c "%USRCMD;sleep 10" このジョブ スタータが指定されたキューにユーザが次のジョブを投入したとしま す。 % bsub myjob arguments 実際には次のコマンドが実行されます。 % /bin/csh -c "myjob arguments; sleep 10" 詳細情報の参照先 lsb.queues ファイルの JOB_STARTER パラメータの詳細については、 『Pla tfo rm LSF Re fe re n c e 』を参照してください。 Platform Clusterware 管理者 227 ジョブ スタータによる実行環境の制御 ジョブ スタータによる実行環境の制御 場合によっては、bsub -L コマンドを使用しても、実行ホストの実行環境が正し く設定されないことがあります。LSF には次の 2 種類のジョブ スタータが付属して います。 ◆ ◆ preservestarter -投入ホストのデフォルト環境を再現します。実行ホストの 設定情報は取り込みません。 augmentstarter -実行ホストのデフォルト環境に、投入ホストの設定情報の うち、実行ホストで定義されていないものを追加します。 ジョブ スタータ プログラムの配置先 デフォルト設定では、これらのジョブ スタータ プログラムは LSF_BINDIR ディレ クトリにインストールされます。別のディレクトリに保存したい場合は、実行ホス トのデフォルトの PATH 変数で指定されているディレクトリに保存してください。 たとえば、次のように指定します。 ◆ UNIX では $HOME/bin に保存します。 ジョブ スタータの ジョブ スタータのソース コードは、LSF_MISC/examples に含まれています。 ソース コード 初期ログイン環境の追加設定 デフォルト設定では、preservestarter ジョブ スタータは、RES が実行ホスト で構築した環境を破棄し、実行ホスト上のユーザのログイン環境に含まれている次 の変数に基づいて、ユーザの初期ログイン環境を構築します。 HOME USER ◆ SHELL ◆ LOGNAME ◆ そのため、preservestarter ジョブ スタータのソース コードに、投入ホスト上のユー ザのログイン環境に含まれている環境変数を追加する必要があります。 ◆ 228 Platform Clusterware 管理者 第 21 章 外部ジョブの投入と実行と制御 本章では、外部ジョブの投入と実行を制御する esub および eexec と呼ばれる実 行可能プログラムの使用方法について説明します。これらはユーザが作成するサイ ト固有の実行可能プログラムで、ジョブ投入の妥当性検査、修正、拒否、ジョブ実 行環境へのデータの受渡し、および実行環境の修正に使用されます。 内容 ◆ ◆ ◆ 230 ページの「外部実行可能プログラム」 231 ページの「esub の使用」 237 ページの「eexec の使用」 Platform Clusterware 管理者 229 外部実行可能プログラム 外部実行可能プログラム esub と eexec について LSF では、ジョブ投入の妥当性検査、修正、または拒否を行ったり、実行環境を修 正したり、投入ホストから実行ホストに直接データを渡すことできます。この機能 には、esub と eexec と呼ばれる 2 つの実行可能プログラムが使用されます。こ れ ら の 実 行 可 能 プ ロ グ ラ ム は サ イ ト 固 有 で、ユ ー ザ に よ っ て 作 成 さ れ、 LSF_SERVERDIR に格納されている必要があります。 ジョブの妥当性検 ジョブの妥当性検査、修正、または拒否を行うには、esub を作成する必要があり 査、修正、または拒 ます。詳細については、231 ページの「esub の使用」を参照してください。 否 実行環境の修正 実行ホスト上の実行環境を修正するには、eexec を作成する必要があります。詳細 については、237 ページの「eexec の使用」を参照してください。 データの受渡し 直接実行ホストにデータを渡すには、esub と eexec を作成する必要があります。 詳細については、237 ページの「esub と eexec を使用した実行環境へのデータの受 渡し」を参照してください。 対話型リモート実行 esub と eexec が LSF_SERVERDIR で検出された場合、対話型リモート実行でこの 2 つを実行することができます。たとえば、タスクを開始する前に、lsrun で esub を呼び出し、RES で eexec を実行します。esub は ls_connect(3) コールのとき に呼び出され、RES はリモート タスクが実行されるたびに eexec を呼び出します。 LSF Batch とは異なり、RES はタスクの開始時にだけ eexec を実行します。 DCE 資格認定と AFS トークン esub と eexec は、DCE 資格認定と AFS トークンの処理にも使用することができ ます。詳細については、プラットフォーム コンピューティングの Web サイトで、 次のマニュアルを参照してください。 「Installing LSF on AFS」 ◆ 「Installing LSF on DCE/DFS」 ◆ 230 Platform Clusterware 管理者 第 21 章 外部ジョブの投入と実行と制御 esub の使用 esub について esub は、external submission の略で、ユーザが作成し、ジョブの妥当性検査、修 正、または拒否に使用できる実行可能プログラム(バイナリまたはスクリプト)で す。esub は、ジョブが投入、再起動、および修正されたときに LSF がその存在を 確認できるように、LSF_SERVERDIR ( lsf.conf 内に定義 ) に格納します。LSF は esub を検出し、実行します。ジョブが投入されるか、修正されるか、拒否される かは、esub に構築されているロジックによって決定されます。 ユーザに通知する必要のあるメッセージは、標準出力(stdout)ストリームでは なく、標準エラー(stderr)ストリームに送られる必要があります。 このセクションの内 ◆ 容 ◆ ◆ ◆ ◆ ◆ ◆ 231 233 234 234 235 235 236 ページの「esub と LSF のブリッジとなる環境変数」 ページの「一般的な esub ロジック」 ページの「ジョブの拒否」 ページの「ジョブ投入パラメータの修正」 ページの「LSF による複数の esub サポート」 ページの「マスタ esub によるアプリケーション固有 esub の呼び出し」 ページの「マスタ esub およびアプリケーション固有 esub の設定」 esub と LSF のブリッジとなる環境変数 LSF では、esub の実行環境で次の環境変数を使用します。 LSB_SUB_PARM_FILE この変数は、ジョブ パラメータが格納されているファイルの場所を示します。ジョ ブが投入されると、esub はこのファイルを読み取ります。投入パラメータは、1 行 に 1 つずつ " オプション名 = 値 " の形式で記述された名前と値のセットで構成され ます。このファイルのオプション名を次に示します。 オプション 説明 LSB_SUB_ADDITIONAL bsub の -a オプションの値が格納される任意の文字列形式のパラ メータ -a の値は esub に渡されるが、他の bsub パラメータまたは振る 舞いに直接影響することはない 開始時刻。00:00:00 GMT、1970 年 1 月 1 日起算の秒数 チェックポイント ディレクトリ ジョブ コマンド チェックポイントの期間 依頼条件 標準エラー ファイル名 例外条件 bsub -extsched オプションの妥当性検査または修正 ホスト指定子 実行ホスト名のリスト 標準入力ファイル名 LSB_SUB_BEGIN_TIME LSB_SUB_CHKPNT_DIR LSB_SUB_COMMAND_LINE LSB_SUB_CHKPNT_PERIOD LSB_SUB_DEPEND_COND LSB_SUB_ERR_FILE LSB_SUB_EXCEPTION LSB_SUB_EXTSCHED_PARAM LSB_SUB_HOST_SPEC LSB_SUB_HOSTS LSB_SUB_IN_FILE Platform Clusterware 管理者 231 esub の使用 オプション LSB_SUB_INTERACTIVE LSB_SUB_LOGIN_SHELL LSB_SUB_JOB_NAME LSB_SUB_MAIL_USER 説明 "Y" の場合、対話型ジョブを指定 ログイン シェル ジョブ名 LSF Batch がジョブ電子メールを送信するために使用する電子メー ル アドレス LSB_SUB_MAX_NUM_PROCESSORS 要求されるプロセッサの最大数 LSB_SUB_MODIFY "Y" の場合、修正要求を指定 LSB_SUB_MODIFY_ONCE "Y" の場合、1 回修正要求を指定 LSB_SUB_NOTIFY_BEGIN "Y" の場合、電子メールでジョブの開始を通知 LSB_SUB_NOTIFY_END "Y" の場合、電子メールでジョブの終了を通知 LSB_SUB_NUM_PROCESSORS 要求されるプロセッサの最小数 LSB_SUB_OTHER_FILES 転送されるファイル数をリセットするために bmod が実行される ように定義する場合は常に "SUB_RESET" LSB_SUB_OTHER_FILES_n u m b e r n u m b e r は、特定のファイル転送値が指定されたファイル転送式 であることを示すインデックス番号。 たとえば、bsub -f "a > b" -f "c < d" の場合、次のように 定義されます。 ◆ LSB_SUB_OTHER_FILES_0="a > b" ◆ LSB_SUB_OTHER_FILES_1="c < d" LSB_SUB_OUT_FILE 標準出力ファイル名 LSB_SUB_PRE_EXEC 実行前コマンド LSB_SUB_PTY "Y" の場合、PTY サポートによる対話型ジョブを指定 LSB_SUB_PTY_SHELL "Y" の場合、PTY シェルサポートによる対話型ジョブを指定 LSB_SUB_QUEUE 投入キュー名 LSB_SUB_RERUNNABLE "Y" の場合、再実行可能なジョブを指定 LSB_SUB_RES_REQ リソース要件文字列 LSB_SUB_RESTART "Y" の場合、ジョブの再起動を指定 LSB_SUB_RESTART_FORCE "Y" の場合、ジョブの強制再起動を指定 LSB_SUB_RLIMIT_CORE コア ファイル サイズ制限 LSB_SUB_RLIMIT_CPU CPU 制限 LSB_SUB_RLIMIT_DATA データ サイズ制限 LSB_SUB_RLIMIT_FSIZE ファイル サイズ制限 LSB_SUB_RLIMIT_RSS 常駐サイズ制限 LSB_SUB_RLIMIT_RUN Wall clock 実行制限 LSB_SUB_RLIMIT_STACK スタック サイズ制限 LSB_SUB_TERM_TIME 終了時刻。00:00:00 GMT、1970 年 1 月 1 日起算の秒数 LSB_SUB_TIME_EVENT タイム イベント式 232 Platform Clusterware 管理者 第 21 章 外部ジョブの投入と実行と制御 投入パラメータ ファイルの例 ユーザが次のジョブを投入するとします。 % bsub -q normal -x -R "r1m" -n 90 sleep 10 この場合、LSB_SUB_PARM_FILE の内容は、次のようになります。 LSB_SUB_QUEUE="normal" LSB_SUB_EXCLUSIVE=Y LSB_SUB_RES_REQ="r1m" LSB_SUB_COMMAND_LINE="sleep 10" LSB_SUB_NUM_PROCESSORS=90 LSB_SUB_MAX_NUM_PROCESSORS=90 LSB_SUB_ABORT_VALUE この変数は、LSF にジョブの投入を拒否させる場合、esub が終了するときに使用 する値を示します。 LSB_SUB_MODIFY_ENVFILE esub がジョブの環境変数への変更を書き込むファイルです。 esub が修正された変数をこのファイルに書き込むときは、LSB_SUB_PARM_FILE ファイルと同じ形式を使用します。ただし、変数の順序は同じとは限りません。 esub が実行された後、LSF は LSB_SUB_MODIFY_ENVFILE で変更をチェックし、 変更されていた場合は、その内容をジョブ環境変数に適用します。 LSB_SUB_MODIFY_FILE esub が投入パラメータへの変更を書き込むファイルです。 esub が 修 正 の 必 要 な ジ ョ ブ オ プ シ ョ ン を こ の フ ァ イ ル に 書 き 込 む と き は、 LSB_SUB_PARM_FILE ファイルと同じ形式を使用します。ただし、オプションの順 序は同じとは限りません。esub が実行された後、LSF は LSB_SUB_MODIFY_FILE で変更をチェックし、変更されていた場合は、その内容をジョブに適用します。 一般的な esub ロジック esub の実行後、LSF によって次のチェックが行われます。 1 2 3 4 5 esub の終了値は LSB_SUB_ABORT_VALUE ですか ? a 等しい場合、ステップ 2 に進みます。 b 等しくない場合、ステップ 4 に進みます。 ジョブを拒否します。 ステップ 5 に進みます。 LSB_SUB_MODIFY_FILE または LSB_SUB_MODIFY_ENVFILE が存在しますか ? 変更の適用 ❖ 終了 Platform Clusterware 管理者 233 esub の使用 ジョブの拒否 ポリシーに基づいて、ジョブを拒否することもできます。ジョブを拒否するには、 esub を LSB_SUB_ABORT_VALUE で終了させます。 esub がジョブを拒否する場合、LSB_SUB_MODIFY_FILE または LSB_SUB_MODIFY_ENVFILE への書き込みは行われません。 例 次の Bourne シェル esub は、LSB_SUB_ABORT_VALUE で終了することによって、 すべてのジョブ投入を拒否します。 #!/bin/sh # Redirect stderr to stdout so echo can be used for # error messages exec 1>&2 # Reject the submission echo "LSF is Rejecting your job submission..." exit $LSB_SUB_ABORT_VALUE ジョブ投入パラメータの修正 ジョブを実際に投入する前に、esub を使用して投入パラメータとジョブ環境を修 正することができます。 以下の例では、LSB_SUB_MODIFY_FILE に次のパラメータへの修正を書き込んでい ます。 LSB_SUB_QUEUE USER ◆ SHELL ◆ この例では、userA というユーザは queueA というキューにだけ、ジョブを投入で きます。userB というユーザは Bourne シェル(/bin/sh)を使用する必要があり、 userC というユーザはジョブを投入できません。 ◆ #!/bin/sh . $LSB_SUB_PARM_FILE # Redirect stderr to stdout so echo can be used for error messages exec 1>&2 USER='whoami' # Ensure userA is using the right queue queueA if [ $USER="userA" -a $LSB_SUB_QUEUE != "queueA" ]; then echo "userA has submitted a job to an incorrect queue" echo "...submitting to queueA" echo 'LSB_SUB_QUEUE="queueA"' > $LSB_SUB_MODIFY_FILE fi # Ensure userB is using the right shell (/bin/sh) if [ $USER="userB" -a $SHELL != "/bin/sh" ]; then echo "userB has submitted a job using $SHELL" echo "...using /bin/sh instead" echo 'SHELL="/bin/sh"' > $LSB_SUB_MODIFY_ENVFILE fi 234 Platform Clusterware 管理者 第 21 章 外部ジョブの投入と実行と制御 # Deny userC the ability to submit a job if [ $USER="userC" ]; then echo "You are not permitted to submit a job." exit $LSB_SUB_ABORT_VALUE fi LSF による複数の esub サポート LSF には、個別の esub 実行可能プログラムの呼び出しとアプリケーションのジョ ブ投入要件を処理するためにマスタ esub(LSF_SERVERDIR/mesub)があります。 bsub の -a オプションを使用すると、LSF を介して実行しているアプリケーション を指定できます。 たとえば、FLUENT ジョブを投入するには、次のコマンドを実行します。 bsub -a fluent bsub_options fluent_command メソッド名 fluent は、FLUENT ジョブ(LSF_SERVERDIR/esub.fluent)に対 して esub を使用します。これは、echkpnt.fluent と erestart.fluent を使 用するためにチェックポイント メソッド LSB_ECHKPNT_METHOD="fluent" を 設定します。 LSB_ESUB_METHOD (lsf.conf) すべてのジョブ投入に適用される必須 esub メソッドを指定するには、lsf.conf に LSB_ESUB_METHOD を設定します。 LSB_ESUB_METHOD には、bsub -a オプションで指定されたメソッドに追加して 使用される esub メソッドの名前を指定します。 たとえば、LSB_ESUB_METHOD="dce fluent" は、必須のセキュリティ システ ムとして DCE を、また、すべてのジョブで使用される必須アプリケーションとし て FLUENT を定義します。 マスタ esub によるアプリケーション固有 esub の呼び出し bsub は、ジョブの投入時に mesub を呼び出し、mesub は、次の esub を呼び出し ます。 1 2 3 必須 esub プログラム(LSB_ESUB_METHOD によって定義) esub(存在する場合) アプリケーション固有の esub プログラム(bsub -a オプションが指定されて いる場合) Platform Clusterware 管理者 235 esub の使用 例 LSB_ESUB_METHOD=dce (lsf.conf) esub.dce bsub -a fluent mesub esub esub.fluent この例では、esub.dce が必須 esub として定義されています。esub はすでに LSF_SERVERDIR に 存 在 し ま す。ジ ョ ブ は FLUENT ジ ョ ブ と し て 投 入 さ れ、 esub.fluent が使用されます。 マスタ esub およびアプリケーション固有 esub の設定 マスタ esub は LSF_SERVERDIR/mesub としてインストールされます。インス トール後、次のように操作します。 1 2 アプリケーション固有の esub を作成します。 オプションです。lsf.conf に LSB_ESUB_METHOD を設定し、すべてのジョ ブ投入で使用される必須 esub を指定します。 esub 名の指定 次の命名規則を使用します。 ◆ UNIX では、FLUENT ジョブを LSF_SERVERDIR/esub.application のよう に命名する 例 : esub.fluent ◆ Window s では、LSF_SERVERDIR¥esub.application.[exe |bat] のよう に命名する 例 : esub.fluent.exe 既存 esub 既存の esub は、この命名規則に従う必要はなく、名前を変更する必要はありません。ただ し、mesub は、この命名規則に従う esub を呼び出すため、esubs のバックアップ コピー は、LSF_SERVERDIR の外に移動するか、この命名規則に従わない名前にします。たとえ ば、esub.bak の代わりに esub_bak を使用します。 予約済みの esub.user という名前は、以前の製品との互換性のために予約されています。アプリケー esub.user ション固有の esub には、esub.user という名前を使用しないでください。 236 Platform Clusterware 管理者 第 21 章 外部ジョブの投入と実行と制御 eexec の使用 eexec について eexec プログラムは、ジョブの開始時と終了時、およびチェックポイントが開始さ れた時点で、実行ホスト上で実行されます。eexec は、ジョブ環境変数が設定され た後、ユーザとして実行されます。環境変数 LS_EXEC_T には、eexec が呼び出さ れる時期を示すために、START、END、CHKPNT のいずれかが設定されます。 eexec を root などの別のユーザとして実行する必要がある場合は、 /etc/lsf.sudoers ファイルに LSF_EEXEC_USER を設定しなければなりません。 『Pla tfo rm LSF Re fe re n c e 』を参照してください。 lsf.sudoers ファイルについては、 親ジョブのプロセスは、eexec の実行が終了するのを待って、処理を開始するの で、eexec は終了する必要があります。環境変数 LS_JOBPID には、eexec を呼び 出したプロセスのプロセス ID が格納されます。ジョブの実行を監視することが eexec の目的である場合、eexec は子をフォークし、親 eexec のプロセスを終了 させる必要があります。子 eexec は、LS_JOBPID 変数を使用して、ジョブ プロセ スが活動中かどうか、定期的にテストします。 esub と eexec を使用した実行環境へのデータの受渡し esub から eexec に何らかのデータを渡す必要がある場合、esub がそのデータを 標準出力に書き込むと、eexec は標準入力からデータを読み取ることができます。 LSF は、esub と eexec の間のパイプとして効果的に機能します(例、esub | eexec)。 esub の標準出力(stdout)は、自動的に eexec に送信されます。 制約 eexec は、複数の標準出力ストリームを扱うことができないため、標準出力を使用 してデータを標準入力として eexec に生成できる esub は、1 つだけです。 たとえば、AFS の esub(esub.afs)は、認証トークンを標準出力として eexec に送信します。AFS を使用する場合、他の esub は標準出力を使用できません。 Platform Clusterware 管理者 237 eexec の使用 238 Platform Clusterware 管理者 第 22 章 ジョブ制御の設定 ジョブが開始された後、システム、LSF ユーザ、LSF 管理者は、そのジョブを中止、 中断、または再開することができます。LSF ジョブ制御アクションにより、ジョブ の状態が変わります。本章では、ジョブ制御アクションを設定し、デフォルトの ジョブ制御アクションを指定変更したり、増補する方法について説明します。 内容 ◆ ◆ 240 ページの「デフォルトのジョブ制御アクション」 242 ページの「ジョブ制御アクションの設定」 Platform Clusterware 管理者 239 デフォルトのジョブ制御アクション デフォルトのジョブ制御アクション ジョブが開始された後、システム、LSF ユーザ、LSF 管理者は、そのジョブを中止、 中断、または再開することができます。LSF ジョブ制御アクションにより、ジョブ の状態が変わります。LSF では、デフォルトで次のジョブ制御のためにアクション をサポートしています。 SUSPEND RESUME TERMINATE ◆ ジョブ制御アクションが正常に終了すると、LSF ジョブ制御コマンドによってジョ ブの状態が変更されます。 ◆ ◆ ジョブ制御アクションが開始されると、LS_EXEC_T 環境変数にはそのジョブの JOB_CONTROLS の値が設定されます。 ジョブ制御とそれを実行する LSF コマンドの詳細については、92 ページの「ジョ ブを強制終了する」を参照してください。 SUSPEND アクション 実行中のジョブの状態を RUN から次のいずれかの状態に変更します。 bstop または bkill に応答して USUSP または PSUSP ◆ LSF システムがジョブを中断したときは SSUSP 状態 デフォルト アクションは、ジョブに次のシグナルを送ります。 ◆ ◆ 並列または対話型ジョブに対しては SIGTSTP マスタ プロセスがこのシグナルを受け、他のホストで実行されているすべての スレーブ プロセスに渡します。 ◆ 順次ジョブに対しては SIGSTOP ユーザ プログラムはこのシグナルを受けることができません。SIGSTOP シグ ナルの内容は、lsf.conf ファイル内の LSB_SIGSTOP パラメータで設定でき ます。 LSF は、次の状況で SUSPEND アクションを呼び出します。 ◆ ◆ ◆ 240 Platform Clusterware 管理者 ユーザまたは LSF 管理者がジョブに bstop または bkill コマンドを発行した とき 実行ホストの負荷状態が次のいずれかを満たしているとき ❖ lsb.queues の STOP_COND パラメータで指定されているキューの中断条 件 キューまたは実行ホストのスケジューリングしきい値 ❖ キューの実行ウィンドウが閉じたとき 第 22 章 ジョブ制御の設定 RESUME アクション 中断されていたジョブの状態を SSUSP、USUSP、または PSUSP から RUN 状態に変 更します。デフォルト アクションは SIGCONT シグナルを送ります。 LSF は、次の状況で RESUME アクションを呼び出します。 ◆ ◆ ◆ ユーザまたは LSF 管理者がジョブに bresume コマンドを発行したとき 実行ホストの負荷状態が次の条件をすべて満たしているとき ❖ lsb.queues の RESUME_COND パラメータに指定されているキューの再 開条件 キューまたは実行ホストのスケジューリングしきい値 ❖ 閉じられていたキューの実行ウィンドウが再度開かれたとき TERMINATE アクション ジョブを終了します。通常、このアクションにより、ジョブは EXIT 状態になりま す。デ フ ォ ル ト ア ク シ ョ ン は 最 初 に SIGINT を 送 信 し、SIGINT の 10 秒 後 に SIGTERM を送信します。さらに、SIGTERM の 10 秒後に SIGKILL を送信します。 ジョブが終了する前に、ユーザ プログラムがシグナルを受け取り、クリーン アッ プできるように、各シグナルは時間をずらして送信されます。 10 秒の間隔を指定変更するには、lsb.params ファイルの JOB_TERMINATE_INTERVAL パラメータを使用します。lsb.params ファイルの詳 細については、『Pla tfo rm LSF Re fe re n c e 』を参照してください。 LSF は、次の状況で TERMINATE アクションを呼び出します。 ユーザまたは LSF 管理者がジョブに bkill、または brequeue コマンドを発 行したとき ◆ TERMINATE_WHEN パラメータによって SUSPEND アクションが TERMINATE に変更されたとき ジョブが CPULIMIT、MEMLIMT、RUNLIMIT、または PROCESSLIMIT に達したとき ◆ アクションが実行されている間は、それが TERMINATE アクションである場合を除 き、それ以外のアクションは開始されません。TERMINATE アクションは、PEND 状 態以外のすべてのジョブに対して発行されます。 ◆ Platform Clusterware 管理者 241 ジョブ制御アクションの設定 ジョブ制御アクションの設定 ジョブ制御のデフォルト アクションを指定変更したり、増補することが必要になる 状況は、いくつか考えられます。たとえば、次の状況があります。 ジョブが中断、再開、または終了されたときにユーザに通知する ジョブが中断されているために解放されないリソース(ライセンスなど)をア プリケーションが保持している。管理者は、ジョブが中断される前にライセン スの割り当てを解除し、ジョブが再開されたときに再取得するためのアクショ ンをセットアップすることができます。 管理者が、次の処理の前にジョブのチェックポイントを実行する必要があると ◆ き。 実行ウィンドウが閉じたため、中断されたとき ❖ RUNLIMIT に達して中止されたとき ❖ SUSPEND、RESUME、および TERMINATE ジョブ制御のデフォルト アクションを指 定変更するには、lsb.queues 内のキュー定義に JOB_CONTROLS パラメータを指 定します。 ◆ ◆ JOB_CONTROLS パラメータ(lsb.queues) JOB_CONTROLS パラメータのフォーマットは次のようになります。 Begin Queue ... JOB_CONTROLS = SUSPEND[signal | CHKPNT | command] \ RESUME[signal | command] \ TERMINATE[signal | CHKPNT | command] ... End Queue LSF でジョブを中断、再開、または終了する必要がある場合、SUSPEND、RESUME、 TERMINATE の指定に従って、次のアクションのいずれかを呼び出します。 signal UNIX のシグナル名(SIGTSTP、SIGTERM など)。指定されたシグナルがジョブに送 られます。 サポートされているシグナル セットは、UNIX システムによって異なります。各シ ステムでサポートされているシグナルの記号名(SIG 接頭部のないもの)のリスト を表示するには、kill -l コマンドを使用します。 CHKPNT ジョブのチェックポイントを実行します。SUSPEND および TERMINATE アクショ ンにだけ有効です。 ◆ ◆ 242 Platform Clusterware 管理者 SUSPEND アクションが CHKPNT の場合、自動的にそのジョブにチェックポイ ントが設定され、ジョブに SIGSTOP シグナルが送られて停止する。 TERMINATE アクションが CHKPNT の場合、自動的にそのジョブにチェックポ イントが実行され、中止される。 第 22 章 ジョブ制御の設定 command /bin/sh コマンド行。アクション定義内のコマンドは引用できません。 lsb.queues ファイルの詳細については、『Pla tfo rm LSF Re fe re n c e 』を参照してく ださい。 ジョブ制御アクションとしてのコマンドの使用 次の状況では、コマンドをジョブ制御アクションとして使用できます。 ◆ ◆ ◆ アクションのためのコマンド行は /bin/sh -c を使用して実行されるので、コ マンドにシェル機能を使用できる。 ジョブのユーザとしてコマンドが実行される。 ジョブの環境変数セットがそのままコマンド アクションのセットでもある。 次の環境変数の設定が追加されます。 LSB_JOBPGIDS - ジョブの現行プロセス グループ ID のリスト LSB_JOBPIDS - ジョブの現行プロセス ID のリスト SUSPEND アクション コマンドに関しては、次の環境変数も設定されます。 LSB_SUSP_REASONS - lsbatch.h に定義されている中断理由のビットマップ を表す整数。 ❖ ❖ ◆ 中断理由を使用すると、ジョブを中断している理由に基づいて、コマンドでさ まざまなアクションを実行することができます。 ◆ コマンドの標準入力、出力、エラーは NULL 装置に転送されるので、コマンド が正常に実行されたかどうかを直接判断できない。UNIX のデフォルトの NULL 装置は /dev/null です。 コマンド行が正しいかどうかを確認する必要があります。テストの目的で、コ マンドの出力を参照したい場合、コマンド行内のファイルに出力を転送します。 TERMINATE Job アクション ジョブの中止以外の処理も行う TERMINATE Job アクションを設定するときは、十 分な注意が必要です。たとえば、リソースによって TERMINATE Job がジョブの状 態を SSUSP に変更するのを制限され、一方で、LSF がジョブの終了を待っているこ とがあります。TERMINATE アクションによってジョブが中止されない場合、中断 状態が無期限に続きます。 Platform Clusterware 管理者 243 ジョブ制御アクションの設定 TERMINATE_WHEN パラメータ(lsb.queues) 場合によっては、デフォルトの SUSPEND アクションを呼び出す代わりに、ジョブ を終了させたいことがあります。たとえば、キューの実行ウィンドウが閉じたので、 ジョブを中止したい場合、TERMINATE_WHEN パラメータを使用して、SUSPEND の代わりに TERMINATE アクションを呼び出すようにキューを設定します。 lsb.queues ファイルの詳細については、『Pla tfo rm LSF Re fe re n c e 』を参照してく ださい。 構文 TERMINATE_WHEN = WINDOW | LOAD 例 次の例では、実行ウィンドウが閉じた場合、ジョブを中止する night キューを定義 しています。 Begin Queue NAME = night RUN_WINDOW = 20:00-08:00 TERMINATE_WHEN = WINDOW JOB_CONTROLS = TERMINATE[ kill -KILL $LSB_JOBPIDS; echo "job $LSB_JOBID killed by queue run window" | mail $USER ] End Queue LSB_SIGSTOP パラメータ(lsf.conf) LSB_SIGSTOP を使用して、デフォルトの SUSPEND アクションによって送られる SIGSTOP シグナルを設定します。 LSB_SIGSTOP が SIGSTOP 以外に設定されている場合、通常 SUSPEND アクション に よ っ て 送 信 さ れ て い る S IGTS TP シ グ ナ ル は 送 信 さ れ ま せ ん。た と え ば、 LSB_SIGSTOP=SIGKILL の場合、TERMINATE アクションによって送信されるデフォ ルトの 3 つのシグナル(SIGINT、SIGTERM、および SIGKILL)は 10 秒間隔で送信 されます。 l sf.conf ファイルの詳細については、 『Pla tfo rm LSF Re fe re n c e 』を参照してくださ い。 シグナルとアクションのデッドロックの回避 ジョブ制御には、そこに関連付けられているアクションと同じシグナルまたはコマ ンドを組み込むことはできません。このような設定を行うと、シグナルとアクショ ンの間でデッドロックが発生します。 たとえば、bkill コマンドは TERMINATE アクションを使用するので、TERMINATE アクションの中に bkill コマンドが含まれていると、デッドロックが発生します。 次のようなジョブ制御指定は、デッドロックの原因になります。 ◆ ◆ ◆ ◆ 244 Platform Clusterware 管理者 JOB_CONTROLS=TERMINATE[bkill] JOB_CONTROLS=TERMINATE[brequeue] JOB_CONTROLS=RESUME[bresume] JOB_CONTROLS=SUSPEND[bstop] 第 VI 部 対話型のジョブ 内容 ◆ ◆ 第 23 章、「bsub を使用した対話型ジョブ」 第 24 章、「対話型タスクとリモート タスクの実行」 第 23 章 bsub を使用した対話型ジョブ 内容 ◆ ◆ ◆ ◆ 248 249 252 256 ページの「対話型ジョブについて」 ページの「対話型ジョブの投入」 ページの「対話型バッチ ジョブのパフォーマンス チューニング」 ページの「ジョブ スクリプトの作成」 Platform Clusterware 管理者 247 対話型ジョブについて 対話型ジョブについて システム管理の観点からすると、すべてのワークロードを 1 つの集中型スケジュー ラ、すなわち LSF Batch から制御することが必要な場合もあります。 LSF Batch を使用して対話型ジョブを実行すると、リソース集約型ジョブに対して バッチ スケジュール ポリシーとホスト選択機能を利用することができます。ジョ ブを投入すると、そのジョブを実行するために、負荷が最小のホストが選択されま す。 LSF Batch に投入されたすべての対話型ジョブは、LSF Batch のポリシーに従うので、 システム制御が容易になります。たとえば、2 つのサーバを対話型サーバ専用に設 定し、この 2 つの対話型サーバだけを使用する対話型キューを定義することによ り、それ以外のサーバには対話型アクセスを行えないようにすることもできます。 スケジューリング ポリシー LSF Batch を使用して対話型ジョブを実行すると、リソース集約型ジョブにバッチ スケジュール ポリシーとホスト選択機能を利用することができます。 対話型バッチ ジョブは、キュー内の他のジョブと同じポリシーを使用してスケ ジュールされます。したがって、対話型ジョブがディスパッチされるまで、長時間 待たされることもあります。応答時間を短縮する必要がある場合は、対話型ジョブ をスケジュールの制約が寛容で、優先順位の高いキューに投入する必要がありま す。 対話型キュー lsb.queues の INTERACTIVE パラメータを使用すると、キューを対話型専用、バッ チ専用、または対話型とバッチ両用に設定することができます。 lsb.queues ファイルに対話型キューを設定する方法については、『Pla tfo rm LSF Re fe re n c e 』を参照してください。 バッチ以外のユーティリティを使用した対話型ジョブ lsrun、lsgrun、などのバッチ以外のユーティリティは、対話型のタスクを実行 するときに、LIM の簡易配置アドバイスを使用してホストを選択します。対話型の タスクを実行するバッチ以外のユーティリティの詳細については、259 ページの「対 話型タスクとリモート タスクの実行」を参照してください。 248 Platform Clusterware 管理者 第 23 章 bsub を使用した対話型ジョブ 対話型ジョブの投入 バッチの対話型ジョブを投入するには、bsub -I オプションを使用し、疑似端末 でバッチの対話型ジョブを投入するには、bsub -Is と -Ip オプションを使用し ます。 詳細については、bsub(1) のマニュアル ページを参照してください。 対話型ジョブを受け付けるキューの検出 対話型ジョブを投入する前に、bqueues -l コマンドを使用して、対話型ジョブを 受け付けるキューを検出する必要があります。 このコマンドの出力に次の内容が含まれている場合、これはバッチ専用のキューで す。このキューは対話型ジョブを受け付けません。 SCHEDULING POLICIES: NO_INTERACTIVE このコマンドの出力に次の内容が含まれている場合、これは対話型専用のキューで す。 SCHEDULING POLICIES: ONLY_INTERACTIVE 上記のどちらも定義されていない場合、または bqueues -l の出力に SCHEDULING POLICIES が存在しない場合、このキューは対話型とバッチの両方 のジョブを受け付けます。 対話型キューは、lsb.queues ファイルに設定します。 対話型ジョブの投入 バッチ対話型ジョブを投入するには、busb -I オプションを使用します。すべて の入力と出力がコマンドを入力した端末を経由するように、ジョブを投入すること ができます。 対話型ジョブが完了するか、終了するまでは、次のジョブを投入することはできま せん。 対話型ジョブを投入すると、ジョブがスケジュールを待っている間、メッセージが 表示されます。bsub コマンドは、ジョブが終了するまでシェルからの出力の表示 を中止し、デフォルトではユーザへのメールの送信は行われません。ctrl-c を使 用すると、随時ジョブを終了させることができます。 対話型ジョブはチェックポイントできません。 対話型バッチ ジョブは再実行可能にできません(bsub -r)。また、再実行可能 キューに投入することはできません(lsb.queues で RERUNNABLE=y)。 例 ◆ ◆ % bsub -I ls ls の出力をユーザの端末に表示するバッチの対話型ジョブを投入します。 % bsub -I -q interactive -n 4,10 lsmake <<Waiting for dispatch ...>> この例では、4 から 10 までのプロセッサで Platform Make を開始し、出力を端 末に表示します。 Platform Clusterware 管理者 249 対話型ジョブの投入 疑似端末を使用した対話型ジョブの投入 bsub -Ip 疑似端末を使用してバッチ対話型ジョブを投入するには、bsub -Ip オプションを 使用します。 -Ip オプションを指定すると、bsub はバッチ対話型ジョブを投入し、ジョブが開 始された時点で疑似端末を作成します。vi など、一部のアプリケーションには、正 しく実行するために疑似端末が必要になります。 たとえば、次のように指定します。 % bsub -Ip vi myfile myfile ファイルを編集するバッチ対話型ジョブを投入します。 bsub -Is バッチ対話型ジョブを投入し、シェル モードをサポートする疑似端末を作成するに は、bsub -Is オプションを使用します。 -Is オプションを指定すると、bsub はバッチ対話型ジョブを投入し、ジョブが開 始された時点でシェル モードをサポートする疑似端末を作成します。このオプショ ンは、投入する対話型シェル、または CTRL-C および CTRL-Z キーを再定義するア プリケーション(jove など)に対して指定する必要があります。 例 % bsub -Is csh csh を対話型シェルとして起動するバッチ対話型ジョブを投入します。 対話型ジョブの投入とストリームのファイルへの転送 bsub -i, -o, -e -I オプションを bsub の -i、-o、および -e オプションと一緒に使用すると、特 定のストリームをファイルに転送することができます。詳細については、bsub(1) のマニュアル ページを参照してください。 たとえば、次のように指定します。 % bsub -I -q interactive -e job.err lsmake 標準のエラー ストリームは job.err ファイルに保存され、標準の入力と出力は、 端末から送られます。 250 Platform Clusterware 管理者 第 23 章 bsub を使用した対話型ジョブ sdtout と stderr の エンド ユーザが LSF や LSF 固有のオプションを意識する必要がないように、bsub 分離 コマンドや LSF コマンドへのラッパー プログラムを使用している環境では、> オペ レータ演算子を使用して、対話型バッチ ジョブの標準出力と標準エラーをファイル にリダイレクトすることができます。 デフォルト設定では、対話型バッチ ジョブの標準エラー メッセージと標準出力 メッセージは、両方とも投入ホストの stdout に書き出されます。 たとえば、次のように指定します。 % bsub -I myjob 2>mystderr 1>mystdout この例では、stderr と stdout の両方が mystdout に書き出されます。 stderr と stdout を別々のファイルにリダイレクトするには、lsf.conf ファイ ルで、または環境変数として LSF_INTERACTIVE_STDERR=y を設定します。この設 定を行った場合に、上と同じコマンドを実行すると、 % bsub -I myjob 2>mystderr 1>mystdout stderr は mystderr にリダイレクトされ、stdout は mystdout にリダイレク トされます。 LSF_INTERACTIVE_STDERR パラメータについては、『Pla tfo rm LSF Re fe re n c e 』を参 照してください。 Platform Clusterware 管理者 251 対話型バッチ ジョブのパフォーマンス チューニング 対話型バッチ ジョブのパフォーマンス チューニング LSF は、対話型ユーザとバッチ ユーザの両方に対応したシステムでよく使われま す。負荷共有機能を使用する際には、ユーザのワークステーションが過負荷になり、 そのワークステーションで実行されている対話型処理の速度が低下しないように 配慮する必要があります。また、重要なバッチ ジョブについては、リソースを確実 に確保できるように専用のマシンで実行したい場合もあります。たとえワークロー ドがバッチ ジョブしかなかったとしても、リソースの競合とオペレーティング シ ステムの過負荷をなるべく抑えて、リソースを最大限に活用できるようにする必要 があります。 LSF では、さまざまなパラメータを使用してリソースの割り当てを制御し、競合を 回避できます。 負荷条件の種類 発生した競合は負荷インデックスに反映されることが多いため、LSF では負荷の変 動に基づいて競合を回避または軽減します。LSF は、各種の負荷条件に従って、ジョ ブを開始する前や、ジョブの実行中に競合を抑えるための対処を行います。これら の負荷条件のほとんどは、キュー レベルとホスト レベルの両方で設定できます。 キュー レベルで設定した負荷条件は、そのキューで使用されているすべてのホスト に適用されます。また、ホスト レベルで設定した負荷条件は、そのホストを使用し ているすべてのキューに適用されます。 スケジューリング条 スケジューリング条件が満たされている場合は、さらに多くのジョブが開始されま 件 す。この条件は、負荷しきい値やリソース要件として定義します。 キュー レベルのスケジューリング条件は、リソース要件やスケジューリング負荷し きい値として定義し、lsb.queues ファイルに記録します。また、ホスト レベル の ス ケ ジ ュ ー リ ン グ 条 件 は、ス ケ ジ ュ ー リ ン グ 負 荷 し き い 値 と し て 定 義 し、 lsb.hosts ファイルに記録します。 中断条件 中断条件は実行中のジョブに影響します。この条件が成立すると、実行中のジョブ に SUSPEND アクションが適用されます。 キュー レベルの中断条件は、中断負荷しきい値として STOP_COND パラメータで 定義し、lsb.queues ファイルに記録します。また、ホスト レベルの中断条件は、 中断負荷しきい値として定義し、lsb.hosts ファイルに記録します。 再開条件 再開条件は、中断したジョブを再開するための条件です。この条件が成立すると、 中断されているジョブに RESUME アクションが適用されます。 キュー レベルの再開条件は、RESUME_COND パラメータで定義し、lsb.queues ファイルに記録するか、または該当するキューの loadSched しきい値を使用して 定義します。 負荷インデックスの種類 ジョブどうしの競合を効率的に軽減するには、適切な負荷インデックスを正しく活 用する必要があります。ここでは、よく使用する負荷インデックスの例を示します。 252 Platform Clusterware 管理者 第 23 章 bsub を使用した対話型ジョブ LIM が収集する負荷インデックス . インデック ス 測定対象 状態 r15s r1m r15m ut pg ホストの状態 実行キュー長 実行キュー長 実行キュー長 CPU 使用率 ページング率 ls it swp mem tmp io nam e 単位 文字列 プロセス数 プロセス数 プロセス数 (パーセント) (ページイン + ペー ジアウト)/ 秒 ログイン セッション数 ユーザ数 アイドル時間 分 MB 空きスワップ容量 MB 空きメモリ容量 一時ファイル システム MB の空き容量 ディスク I/O (lsload -l KB/ 秒 で表示 ) LSF 管理者が設定した外部負荷インデックス 方向 平均値の測定 時間 更新間隔 増加 増加 増加 増加 増加 15 秒 1分 15 分 1分 1分 15 15 15 15 15 15 増加 減少 減少 減少 減少 N/A N/A N/A N/A N/A 30 秒 30 秒 15 秒 15 秒 120 秒 増加 1分 15 秒 秒 秒 秒 秒 秒 秒 サイトで定 義 負荷インデックスの lsinfo コマンドを使用すると、外部負荷インデックスのリストが表示され、 情報を参照する lsload -l コマンドを使用すると、すべての負荷インデックスの値が表示されま す。外部負荷インデックスは LSF 管理者が設定します。 lsload コマンドの出力の例を、以下に示します。 % lsload HOST_NAME hostN hostK hostG hostF hostV status ok -ok busy busy unavail r15s 0.0 0.0 *6.2 0.1 r1m 0.0 0.0 6.9 0.1 r15m 0.1 0.0 9.5 0.3 ut 1% 3% 85% 7% pg 0.0 0.0 1.1 *17 ls 1 3 30 6 it 224 0 0 0 tmp 43M 38M 5M 9M swp 67M 40M 400M 23M mem 3M 7M 385M 28M ページング率(pg) ページング率(pg)は、対話型処理の体感的な応答速度と密接に関係しています。 アプリケーションがディスクにページングされると、ユーザ インタフェースの動作 が非常に遅くなります。 ページング率は物理メモリ不足の指標でもあります。アプリケーションのページイ ンとページアウトが頻繁に発生すると、オーバーヘッドを処理するために大量の時 間が消費され、その結果として処理性能が低下してしまいます。 ページング率は、該当するホストへの新しいジョブの送出を禁止したり、すでにそ のホストで実行中のバッチ ジョブを中断して、対話型ユーザを優先させるためのし きい値として使用できます。 Platform Clusterware 管理者 253 対話型バッチ ジョブのパフォーマンス チューニング この負荷インデックスは、各種の構成ファイルで別々の目的に使用できます。たと えば、lsf.cluster.cluster_name ファイルでページング率のしきい値を定義す ると、LIM がいつホストをビジー状態とみなすかを指定し、そのホストでそれ以上 のジョブが実行されないようにすることができます。 また、キューやホストのスケジューリング条件としてページング率を指定すると、 ページング率が高すぎるマシンではジョブが開始されないようにしたり、コンソー ル上の対話型ユーザに影響が出ている場合にジョブを中断(または中止)したりで きます。 ページング率のしきい値のために中断されたジョブは、たとえ再開条件が成立して いたとしても、該当するマシンの対話型アイドル時間が PG_SUSP_IT パラメータで 指定した秒数を超えるまでは再開されません。 対話型アイドル時間 アイドル時間(it)を使用すると、綿密な制御が可能になります。この負荷イン (it) デックスは、最後の対話型端末処理からの経過分数を示しています。対話型端末に は、ハードワイヤード tty、rlogin セッション、lslogin セッション、xterm の ような X シェル ウィンドウなどがあります。ホストによっては、マウス処理やキー ボード処理も検出の対象になります。 通常、アイドル時間は、バッチ ジョブによって対話型処理が妨害されるのを防ぐた めに使用します。たとえば、あるキューで中断条件を it<1 && pg>50 と定義す ると、マシン上の対話型処理がアイドル状態ではなく、かつページング率が 50 ペー ジ / 秒を超えている場合に、該当するキューからのジョブが中断されます。さらに、 このキューで再開条件を it>5 && pg<10 と定義すると、アイドル時間が 5 分を 超え、かつページング率が 10 ページ / 秒を下回ったときに、中断されていたジョ ブが再開されます。 アイドル時間が 0 ( ゼロ ) 以外の値になるのは、アクティブな対話型ユーザがいな いときだけです。上記の例のように、アイドル時間のしきい値を 5 分に設定すると、 対話型ユーザが思考している時間を考慮に入れながら、ユーザがログオンしている にもかかわらず、その時点ではマシンを使用していないことを的確に検出して、マ シンを負荷共有に使用できる状態に復帰させることができます。 優先順位の低いバッチ キューについては、lsb.queues ファイルでアイドル時間 の中断しきい値を 2 分に、そのスケジューリングしきい値を 10 分に設定するとよ いでしょう。このようにすると、実行先のホストが使用中のときは該当するキュー からのジョブをすみやかに中断し、そのホストがアイドル状態になってしばらくし てからそのジョブを再開できます。また、あるホストで、あらゆるバッチ ジョブを (その重要度に関係なく)中断する必要がある場合は、lsb.hosts ファイルでホス トごとの中断しきい値を設定します。 CPU 実行キュー長 同じマシンで複数の(マルチプロセッサ マシンでは CPU 当たり複数の)CPU バウ (r15s、r1m、r15m) ンドなプロセスを実行すると、対話型ユーザの処理が妨害されるだけでなく、オペ レーティング システムのオーバーヘッドのために全体スループットも低下してし まいます。コンパイルなど、実行する作業によっては、たった 1 回の処理を行うだ けで、CPU バウンドなタスクが複数生成される場合があります。 通常、それぞれのキューでは、CPU 実行キューのスケジューリングしきい値を 1.0 未満に設定します。このようにすると、すでに CPU バウンドなジョブを実行して いるホストでは、新しいジョブが開始されなくなります。マルチプロセッサ マシン については、実行キューの実効長を使用して、このしきい値が自動的に変換される ため、この条件ではプロセッサごとに 1 つのジョブが割り当てられます。 254 Platform Clusterware 管理者 第 23 章 bsub を使用した対話型ジョブ 長さが中程度以下のジョブでは r1m を使用し、長さがそれ以上のジョブでは r1m と r15m を組み合わせて使用します。ただし、キューの優先順位が高く、全体ス ループットよりもターンアラウンド時間のほうが重要な場合は除きます。このよう なキューでは、r1m のスケジューリングしきい値を 2.0 に設定するとよいでしょう。 CPU 使用率(ut) CPU 使用率(ut)は、CPU の合計消費時間を表しています。CPU 時間がすべて消 費されているホストに新しいジョブを送出しても、そのホストの処理能力がネット ワーク上の他のホストより大幅に高い場合を除いて、メリットはほとんどありませ ん。CPU 使用率のしきい値を 90% に設定すると、CPU の余力が残されていないホ ストへのジョブの送出を防止できます。 ホストの pg 値を非常に高くし、ut 値を低く設定すると、一部のジョブを中断し、 競合を軽減するのに効果的な場合があります。 CPU 使用率を 0 ~ 100 のパーセント値で報告するコマンドもあれば、0 ~ 1 の小 数で報告するコマンドもあります。lsf.cluster.cluster_name ファイルや構成 ファイル内の構成パラメータでは、この値を 0 ~ 1 の小数で指定します。これに対 して、bsub -R コマンドのリソース要件では、この値を 1 ~ 100 の整数で指定し ます。 bhist コマンドを使用すると、バッチ ジョブの実行履歴(ジョブがキューで待機 していた時間、システムの負荷条件のために中断されていた時間など)を確認でき ます。 bjobs -p コマンドを使用すると、ジョブが保留されていた理由を参照できます。 スケジューリング条件とリソースしきい値 キューの定義では、RES_REQ、STOP_COND、RESUME_COND の 3 つのパラメータ を指定できます。ただし、キュー レベルでジョブのディスパッチ条件を指定する場 合は、スケジューリング条件を使用するほうが一般的です。これらのパラメータで は、リソース要件文字列の形式で値を指定できるため、loadSched しきい値や loadStop しきい値を使用する場合よりも柔軟に条件を指定できます。 Platform Clusterware 管理者 255 ジョブ スクリプトの作成 ジョブ スクリプトの作成 ジョブ ファイルは、投入するジョブを指定せずに bsub を実行することにより、一 度に 1 行ずつ構築するか、または別のファイルから作成することができます。この 作業を行うときは、bsub が標準入力からコマンド行を読み取り、それを単一バッ チ ジョブとして投入する対話型セッションを開始します。bsub> プロンプトから 1 行ずつ入力します。 bsub -Zs コマンドを使用すると、ファイルをスプールできます。 bsub オプションの詳細については、bsub(1) のマニュアル ページを参照してく ださい。 ジョブ ファイルを 1 行ずつ作成する方法 % bsub -q simulation bsub> cd /work/data/myhomedir bsub> myjob arg1 arg2 ...... bsub> rm myjob.log bsub> ^D Job <1234> submitted to queue <simulation>. 上記の例では、3 つのコマンド行が Bourne シェル(/bin/sh)スクリプトとして 実行されます。この場合、有効な Bourne シェル コマンド行だけが受け付けられま す。 ファイルへのジョブ オプションの指定 次の例では、ジョブを実行するためのオプションは、options_file に指定され ます。 % bsub -q simulation < options_file Job <1234> submitted to queue <simulation>. UNIX では、options_file は Bourne シェル コマンド行が格納されたテキスト ファイルでなければなりません。バイナリ実行可能ファイルは使用できません。 256 Platform Clusterware 管理者 第 23 章 bsub を使用した対話型ジョブ ジョブ コマンド ファイルのスプール bsu b - Zs を 使 用 す る と、ジ ョ ブ コ マ ン ド フ ァ イ ル を l sb.p ara ms の JOB_SPOOL_DIR パラメータで指定したディレクトリにスプールし、スプールされ たファイルをジョブのコマンド ファイルとして使用することができます。 bmod -Zsn コマンドを使用すると、ジョブが投入された後でコマンド ファイルを 修正または削除することができます。元の入力ファイルの削除または修正を行って も、投入されたジョブには影響しません。 bsub 標準入力へのスクリプトの転送 bsub コマンドの標準入力にスクリプトを転送することができます。 % bsub < myscript Job <1234> submitted to queue <test>. 上記の例では、myscript ファイルには、実行されるコマンド行だけでなく、ジョ ブ投入オプションも格納されています。bsub コマンドは標準入力からスクリプト を読み取ります。bsub コマンドから制御が返された直後に、次のジョブ投入に合 わせてスクリプトを修正できます。 bsub コマンド行でスクリプトが指定されている場合、スクリプトはスプールされ ません。 % bsub myscript Job <1234> submitted to default queue <normal>. 上記の例では、myscript ファイルの内容とは関係なく、myscript コマンド行は LSF Batch によってスプールされます。後で myscript ファイルの内容を修正する と、ジョブの振る舞いに影響します。 埋込み投入オプションの指定 ジョブ投入オプションは、bsub コマンドによって標準入力から読み取られるスク リプトに、#BSUB で始まる行を使用して指定できます。 % bsub -q simulation bsub> #BSUB -q test bsub> #BSUB -o outfile -R "mem>10" bsub> myjob arg1 arg2 bsub> #BSUB -J simjob bsub> ^D Job <1234> submitted to queue <simulation>. 次の点に注意してください。 ◆ ◆ ◆ コマンド行オプションは、埋込みオプションを指定変更します。前述の例では、 ジョブは test キューではなく、simulation キュー に投入されます。 投入オプションは標準入力のどこにでも指定できます。前述の例では、bsub の -J オプションは、実行されるコマンドの後に指定されています。 前述の例のように、1 行に複数のオプションを指定できます。 特殊なシェルでのジョブの実行 デフォルトでは、LSF は Bourne ( /bin/sh) シェルを使用してバッチ ジョブを実行 します。ジョブが実行されるシェルを指定することもできます。シェルを指定する には、スクリプトの 1 行目にインタプリタを指定します。 Platform Clusterware 管理者 257 ジョブ スクリプトの作成 たとえば、次のように指定します。 % bsub bsub> #!/bin/csh -f bsub> set coredump='ls |grep core' bsub> if ( "$coredump" != "") then bsub> mv core core.'date | cut -d" " -f1' bsub> endif bsub> myjob bsub> ^D Job <1234> is submitted to default queue <normal>. bsub コマンドは、実行シェルを設定するために、標準入力からスクリプトを読み 取る必要があります。シェルを指定しないスクリプトは、/bin/sh を使用して実 行されます。スクリプトの 1 行目が # で始まり、その直後に感嘆符(!)がない場 合は、/bin/csh を使用してジョブが実行されます。 たとえば、次のように指定します。 % bsub bsub> # This is a comment line. This tells the system to use /bin/csh to bsub> # interpret the script. bsub> bsub> setenv DAY 'date | cut -d" " -f1' bsub> myjob bsub> ^D Job <1234> is submitted to default queue <normal>. 特殊なシェルでのジョブの実行が頻繁に必要になる場合、コマンド レベルのジョブ スタータを使用して代替シェルを指定し、対話形式でジョブを実行することができ ます。詳細については、228 ページの「ジョブ スタータによる実行環境の制御」を 参照してください。 258 Platform Clusterware 管理者 第 24 章 対話型タスクとリモート タスクの 実行 本章では、lsrun、lsgrun、lslogin などの非バッチ ユーティリティを使用し て、タスクを対話形式で実行したり、リモートで実行する方法について説明します。 内容 ◆ ◆ ◆ 260 ページの「リモート タスクの実行」 262 ページの「対話型タスク」 265 ページの「対話型セッションの負荷分散」 Platform Clusterware 管理者 259 リモート タスクの実行 リモート タスクの実行 lsrun は、リモート ホストでタスクを実行するための非バッチ ユーティリティで す。lsgrun は、同じタスクを多数のホストで、一カ所ずつ順番に、または並行し て実行するための非バッチ ユーティリティです。 デフォルトでは、lsrun は CPU 負荷が最小(正規化 CPU 実行キュー長が最小)で 使用可能メモリが最大のホスト上でジョブを実行します。コマンド行引数を使用し て、他のリソース要件を選択したり、実行ホストを指定することができます。 リモート ジョブを実行するたびに lsrun コマンドを入力する手間を省くために、 シェル別名やスクリプトを使用してジョブを実行することも可能です。 lsrun および lsgrun オプションの詳細については、lsrun(1) および lsgrun(1) のマニュアル ページを参照してください。 このセクションの内 ◆ 容 ◆ ◆ ◆ ◆ ◆ ◆ 260 260 261 261 261 261 261 ページの「最適なホストでのタスクの実行」 ページの「特殊なリソースを持つホストでのタスクの実行」 ページの「指定したホストでのタスクの実行」 ページの「疑似端末を使用したタスクの実行」 ページの「複数ホストでの同一タスクの順次実行」 ページの「並列タスクの実行」 ページの「ファイルで指定したホストでのタスクの実行」 最適なホストでのタスクの実行 mytask を最適なホストで実行するには、次のように入力します。 % lsrun mytask LSF は、ローカル ホストと同じタイプのホストが使用可能であれば、それを自動的 に選択します。デフォルトでは、CPU とメモリの負荷が最小のホストが選択されま す。 特殊なリソースを持つホストでのタスクの実行 特殊なリソース要件を満たすホストで mytask を実行したい場合は、lsrun の -R re s_re q オプションを使用して、リソース要件を指定することができます。 たとえば、次のように指定します。 % lsrun -R 'cserver && swp>100' mytask 上記の例の mytask は、リソース cserver と最低でも 100 MB の仮想メモリを使 用できるホストで実行しなければなりません。 さらに、特定のタスクのリソース要件を保存するように LSF を設定することもでき ます。LSF にタスクのリソース要件を設定しておくと、コマンド行で lsrun の -R re s_re q オプションを指定する必要がなくなります。コマンド行でリソース要件 を指定した場合は、設定されていたリソース要件が指定された内容に変更されま す。 lsf.task ファイルにリソース要件を設定する方法については、『Pla tfo rm LSF Re fe re n c e 』を参照してください。 260 Platform Clusterware 管理者 第 24 章 対話型タスクとリモート タスクの実行 指定したホストでのタスクの実行 特定のホストでタスクを実行したい場合は、lsrun -m オプションを使用します。 % lsrun -m hostD mytask 疑似端末を使用したタスクの実行 テキスト エディタなど、一部のタスクには、特殊な端末操作が要求されます。これ らのタスクは疑似端末を使用して実行し、ネットワーク上で特殊な端末操作を使用 できるようにする必要があります。 lsrun の -P オプションは、ジョブが疑似端末を使用して実行されるように指定し ます。 % lsrun -P vi 複数ホストでの同一タスクの順次実行 lsgrun コマンドを使用すると、同じタスクを多数のホストで、一カ所ずつ順番に、 または並行して実行することができます。 たとえば、hostA、hostD、hostB の各ホスト上の /tmp/out ファイルをマージ して、gout という名前の 1 つのファイルを作成する場合、次のように入力します。 % lsgrun -m "hostA hostD hostB" cat /tmp/out >> gout 並列タスクの実行 lsgrun -p -p オプションは、指定したタスクを同時に実行するように lsgrun に指示します。 詳細については、lsgrun(1) のマニュアル ページを参照してください。 3 つのホストから /tmp/core ファイルを削除するには、次のように入力します。 % lsgrun -m "hostA hostD hostB" -p rm -r /tmp/core ファイルで指定したホストでのタスクの実行 lsgrun -f host_file lsgrun -f h o st_file オプションは、h o st_file ファイルを読み取って、タスクを実行 するホストのリストを取得します。 Platform Clusterware 管理者 261 対話型タスク 対話型タスク LSF では、クラスタ内のすべてのサーバ ホストで透過的にタスクを実行することが 可能です。したがって、最適なホストでプログラムを実行し、自分のワークステー ションで実行されている場合と同様にプログラムと対話することができます。 CTRL-Z や CTRL-C などのキーボード シグナルも要求どおりに機能します。 対話型タスクはユーザとリアルタイムでやり取りします。vi などのプログラムは テ キ ス ト ベ ー ス の 端 末 イ ン タ フ ェ ー ス を 使 用 し ま す。CAD (Compute r Aide d Design) や DTP (desktop publishing) アプリケーションでは、通常 GUI(グラフィ カル ユーザ インタフェース)が使用されます。 このセクションでは、lsrun、lsgrun、などの非バッチ ユーティリティを使用し て対話型タスクを実行する方法について、概要を紹介します。これらのユーティリ ティを使用して対話型タスクを実行するには、-i オプションを使用します。 詳細については、lsrun(1) および lsgrun(1) のマニュアル ページを参照して ください。 このセクションの内 ◆ 容 ◆ ◆ ◆ ◆ ◆ 262 262 263 263 263 264 ページの「リモート ホストの対話型タスク」 ページの「対話型処理とスケジュール ポリシー」 ページの「共有ファイルとユーザ ID」 ページの「リモート実行のシェル モード」 ページの「実行ウィンドウ」 ページの「ストリームのファイルへのリダイレクト」 リモート ホストの対話型タスク ジョブ制御 リモート ホストで対話型タスクを実行するときも、ローカルで実行されている場合 とほぼ同様にジョブを制御することができます。ジョブ制御が可能なシェルを使用 している場合、ローカル タスクと同様に、タスクの中断や再開、バックグラウンド とフォアグラウンドの切り替えを行うことができます。 詳細については、lsrun(1) のマニュアル ページを参照してください。 リモート実行の非表 1 行のシェル スクリプトか csh 別名を記述して、リモート実行を隠すことができ 示 ます。たとえば、次のように入力します。 #!/bin/sh # Script to remotely execute mytask exec lsrun -m hostD mytask または % alias mytask "lsrun -m hostD mytask" 対話型処理とスケジュール ポリシー LSF では、自分の端末またはワークステーションを使用して、ネットワーク上のど のコンピュータでも対話型タスクを実行できます。対話型タスクは直ちに実行さ れ、通常は、テキスト ベースまたはグラフィカル ユーザ インタフェースから、何 らかの入力が必要です。ローカル ホストとジョブの実行ホスト間での入力と出力の 送信は、すべてユーザには意識させずに行われます。 262 Platform Clusterware 管理者 第 24 章 対話型タスクとリモート タスクの実行 共有ファイルとユーザ ID LSF がリモート ホストでタスクを実行する場合、タスクは標準の UNIX システム コールを使用してファイルと装置にアクセスします。ユーザはリモート ホストにア カウントを持っている必要があります。リモート ホスト上の操作は、すべてユーザ のアカウント許可に従って行われます。 ファイルの読み取りと書き込みを行うタスクは、リモート ホスト上のファイルにア クセスします。したがって、負荷分散が透過的に行われるためには、NFS や AFS な どのファイル共有方式を使用して、必要なファイルをクラスタ内のどのホストでも 使用できるようにしておく必要があります。クラスタ内のどのホストでもファイル を使用できる場合、ファイルへのアクセス方法を気にせずに、どのホストでもタス クを実行することができます。 LSF は、前述の条件が満たされていなくても、正常に機能しますが、期待どおりの 結果を得られない可能性があります。たとえば、/tmp ディレクトリは、通常はど のホストでも私用なので、リモート ホストの /tmp にファイルをコピーした場合、 そのファイルは同一のリモート ホスト以外では読み取れなくなります。 すべてのホストでファイルを使用できない場合も LSF を使用することができます。 LSF の提供する lsrcp コマンドを使用すると、LSF ホスト間でファイルをコピーす ることができます。パイプを使用して、リモート コマンドの標準入出力を転送した り、データ ファイルを実行ホストにコピーするスクリプトを作成することができま す。 リモート実行のシェル モード UNIX では、RES を使用してアプリケーションを実行するために、シェル モードが サポートされています。 対話型シェルまたは CTRL-C および CTRL-Z キーを再定義するアプリケーション (jove など)を実行するときに、シェル モードが必要になります。 lsrun、ch、または lsgrun の -S オプションを指定すると、シェル モードをサ ポートするリモート タスクが作成されます。デフォルトでは、シェル モードのサ ポートは有効化されていません。 実行ウィンドウ 実行ウィンドウは、バッチ ジョブにだけ適用されます。LIM によってスケジュール される対話型ジョブは、別の実行ウィンドウ セットによって制御されます。 Platform Clusterware 管理者 263 対話型タスク ストリームのファイルへのリダイレクト デフォルト設定では、対話型タスクの標準エラー メッセージと標準出力メッセージ は、両方とも投入ホストの stdout に書き出されます。 stderr と stdout を分離して、別々のファイルにリダイレクトするには、 lsf.conf ファイルで、または環境変数として LSF_INTERACTIVE_STDERR=y を設 定します。 この設定を行った状態で、次のようにして stdout と stderr を別々のファイル にリダイレクトします。 % lsrun mytask 2>mystderr 1>mystdout この例では、stderr は mystderr にリダイレクトされ、stdout は mystdout にリダイレクトされます。LSF_INTERACTIVE_STDERR を設定していない場合、 stderr と stdout の両方が mystdout に書き出されます。 LSF_INTERACTIVE_STDERR パラメータについては、『Pla tfo rm LSF Re fe re n c e 』を参 照してください。 264 Platform Clusterware 管理者 第 24 章 対話型タスクとリモート タスクの実行 対話型セッションの負荷分散 LSF を使用して最適なホストで対話型セッションを開始するには、いくつかの方法 があります。 最小負荷ホストへのログオン 最小負荷ホストにログオンするには、lslogin コマンドを使用します。 lslogin を使用すると、LSF は自動的に最適なホストを選択し、そのホストへ rlogin します。 引数を指定しない場合、lslogin は、比較的 CPU 負荷が軽く、ログイン セッショ ンがほとんどない、現行ホストと互換性のあるバイナリを持つホストを選択しま す。 特殊リソースを持つホストへのログオン 特定のリソース要件を満たすホストにログオンしたい場合は、 lslogin -R res_req オプションを使用します。 % lslogin -R "solaris order[ls:cpu]" このコマンドは、sunos リソースを持ち、他のユーザがほとんどログインしていな い、CPU 負荷レベルの低いホストへリモート ログインします。このコマンドは、 lsplace を使用して最適なホストを検出し、rlogin を使用してそのホストにロ グインするのと同じ処理を行います。 % rlogin 'lsplace -R "sunos order[ls:cpu]"' Platform Clusterware 管理者 265 X アプリケーションの負荷分散 X アプリケーションの負荷分散 X Window での xterm の起動 X Window System を使用している場合、次のように入力すると、最小負荷ホストで シェル セッションを開始する xterm を起動することができます。 % lsrun sh -c xterm & 上記のコマンド行の & は、xterm の実行が開始されたら、X 端末をバックグラウ ンドで実行することにより、ホスト上のリソースを解放するという重要な意味があ ります。 前述の例では、ローカル ホストでプロセスは実行されていません。lsrun は、 xterm が起動した時点で終了し、リモート ホスト上の xterm が直接ローカル ホ ストの X サーバに接続します。 PC 上の xterm X アプリケーションは、ユーザのデスクトップの X ディスプレイに、個々にネット ワ ー ク 接 続 し ま す。通 常、ア プ リ ケ ー シ ョ ン は デ ィ ス プ レ イ に 関 す る 情 報 を DISPLAY 環境変数から取得します。 eXceed などの X ベースのシステムは、UNIX サーバにリモート シェル接続し、 DISPLAY 環境変数を設定してから、X アプリケーションを呼び出して、アプリケー ションを起動します。アプリケーションが起動された後は、そのディスプレイと独 自に接続するので、最初のリモート シェルは不要になります。 この方法をさらに拡張して、リモート アプリケーションの負荷共有を行うこともで きます。X ディスプレイ ホストで実行されているクライアント ソフトウェアは、 LSF クラスタ内の任意のサーバ ホストにリモート シェル接続を行います。クライ アントは直接 X アプリケーションを実行する代わりに、スクリプトを呼び出して、 LSF を使用して最適なホストを選択し、そのホストでアプリケーションを起動しま す。その後、アプリケーションはディスプレイと直接接続するので、中間接続はす べてクローズできます。ディスプレイ ホスト上のクライアント ソフトウェアは、ク ラスタ内のホストを選択し、接続する必要があります。このホストは任意に選択で きます。LSF が最適なホストを選択し、そこで X アプリケーションを開始したら、 最初のホストは使用されなくなり、処理中の負荷はなくなります。 最小負荷ホストで X セッションを開始するための X 端末のセットアップ デスクトップ マシンとして PC を使用していて、その PC で X Window サーバを実 行している場合、最小負荷ホストで X セッションを開始するとができます。 次の手順は、Hummingbird Communications の Exceed を使用していることを前提 としています。この手順を使用して、X ベース アプリケーションの負荷分散を行う ことができます。 -R "..." で指定したリソース要件を変更することで、ホストの選択をカスタマイ ズできます。たとえば、xterm プログラム グループに、それぞれ Best、Best_Sun、 Best_SGI という名前のアイコンを設定できます。 最小負荷ホストにログオンする Exceed のセットアップ 最小負荷ホストにログオンするように Exceed をセットアップするには、次の作業 を行います。 266 Platform Clusterware 管理者 第 24 章 対話型タスクとリモート タスクの実行 1 2 3 [Exceed] プログラム グループの [Xstart] アイコンをクリックします。 開始メソッドとして [REXEC (TCP/IP, ...)] を選択し、プログラム タイプは X ウィ ンドウにします。 LSF クラスタ内の任意のサーバ ホストをホストに設定します。 lsrun -R "type==any order[cpu:mem:login]" lsbg xterm -sb -ls display your_PC:0.0 4 5 記述に [Best] を設定します。 [Xstart] ウィンドウで、[Install] ボタンをクリックします。 この処理により、選択したプログラム グループ(たとえば、xterm)のアイコ ンとして Best がインストールされます。 この設定により、ユーザは、[Xstart] プログラム グループの [Best] をクリック すると、最適なホストにログオンできるようになります。 Exceed での xterm の起動 xterm を起動するには、次の作業を行います。 ◆ [Best] アイコンをダブルクリックします。 xterm がクラスタ内の最適なホストで起動され、画面に表示されます。 例 最小負荷ホストでの任意のアプリケーションの実行 ライセンスされている最適なマシンで appY を実行するには、Exceed に次のよう なコマンド行を設定し、記述に appY を設定します。 lsrun -R "type==any && appY order[mem:cpu]" sh -c "appY -display your_PC:0.0 &" appY 用にライセンスされたすべての UNIX サーバにリソース “appY” が設定され ていることを確認します。この例では、グラフィックスが埋め込まれている場合、 appY には大量のメモリが必要なので、“mem” を適切なサーバの中から最適なホス トを選択するときの最重要考慮点にしています。 X デスクトップ環境の最小負荷ホストでの X セッションの開始 前述の方法は、他の X デスクトップ環境にも適用できます。通常、最適なホストで X セッションを開始したい場合は、LSF ホストで次のコマンドを実行します。 lsrun -R "resource_requirement" lsbg my_Xapp -display your_PC:0.0 この中で、 resource_requirement は、リソース要件文字列です。 Platform Clusterware 管理者 267 X アプリケーションの負荷分散 自動的にリソース要件を指定するためのスクリプト 前述の例では、ユーザがリソース要件文字列を指定する必要があります。この指定 を集中化して、すべてのユーザが同じリソース指定を使用するようにしたい場合も あります。 この場合、中央スクリプト(たとえば、lslaunch)を作成し、それを /lsf/bin ディレクトリに格納します。たとえば、次のように設定します。 #!/bin/sh lsrun -R "order[cpu:mem:login]" lsbg $@ exit $? コマンド文字列は、次のように単純化できます。 lslaunch xterm -sb -ls -display your_PC:0.0 これをさらに一歩進めると、次のような lsxterm になります。 #!/bin/sh lsrun -R "order[cpu:mem:login]" lsbg xterm -sb -sl $@ exit $? コマンド文字列は、次のように単純化できます。 lsxterm -display your_PC:0.0 268 Platform Clusterware 管理者 第 VII 部 並列ジョブの実行 内容 ◆ 第 25 章、「並列ジョブの実行」 第 25 章 並列ジョブの実行 内容 ◆ ◆ ◆ ◆ ◆ 272 273 274 275 276 ページの「LSF による並列ジョブの実行」 ページの「並列ジョブを投入するための環境変数の準備」 ページの「並列ジョブの投入」 ページの「lstools を使用した並列タスクの起動」 ページの「並列ジョブのジョブ スロット制限」 Platform Clusterware 管理者 271 LSF による並列ジョブの実行 LSF による並列ジョブの実行 LSF がジョブを実行する場合、LSB_HOSTS 変数にはバッチ ジョブを実行するホス トの名前が設定されます。並列バッチ ジョブの場合、LSB_HOSTS には LSF Batch がジョブに割り当てたホストのリストが格納されます。 LSF は、このホスト リストに含まれている最初のホストで、並列バッチ ジョブ用 の制御プロセスを開始します。並列アプリケーションは、LSB_HOSTS 環境変数を 読み取ってホスト リストを取得し、割り当てられた残りの全ホストで並列ジョブの 構成要素を開始する必要があります。 272 Platform Clusterware 管理者 第 25 章 並列ジョブの実行 並列ジョブを投入するための環境変数の準備 ホスト リストの取得 アプリケーションの中には、このホスト リストをコマンド行パラメータとして直接 受け取ることができるものもあります。それ以外のアプリケーションに関しては、 ホスト リストを処理する必要があります。 例 次の /bin/sh スクリプトでは、ホスト リストのすべてのホストを処理し、さらに ジョブ スクリプトが実行されているホストを識別しています。 #!/bin/sh # Process the list of host names in LSB_HOSTS for host in $LSB_HOSTS ; do handle_host $host done 並列ジョブ スクリプト 並列プログラミング パッケージは、並列ジョブが使用するホストの指定方法と通信 方法に関して、それぞれ異なる要件を持っています。LSF は特定の並列プログラミ ング パッケージに合わせて設計されているのではなく、シェル スクリプトやラッ パー プログラムを作成すれば、どの並列パッケージでも使用できるように、汎用イ ンタフェースを提供しています。 ジョブ スタータの使用 スクリプトは、ジョブ スタータとしてキューに組み込むことができます。その結 果、すべてのユーザがスクリプト名を入力しなくても並列ジョブを投入できるよう になります。ジョブ スタータの詳細については、226 ページの「キュー レベルの ジョブ スタータ」を参照してください。 キューにジョブ スタータが定義されているかどうかを確認するには、 bqueues -l を実行します。 Platform Clusterware 管理者 273 並列ジョブの投入 並列ジョブの投入 LSF ではジョブを実行するためのホストまたはプロセッサを複数割り当てることが でき、並列ジョブが実行されている間、ジョブの状態を自動的に追跡します。 プロセッサ数の指定 複数のプロセッサが必要な並列ジョブを投入するときは、使用するプロセッサの正 確な数を指定することができます。 並列ジョブを投入するには、bsub -n コマンドを使用し、複数のプロセッサを指 定します。 例 % bsub -n 4 myjob このコマンドは、myjob を並列ジョブとして投入します。このジョブは 10 個のジョ ブ スロットが使用可能になった時点で開始されます。 274 Platform Clusterware 管理者 第 25 章 並列ジョブの実行 lstools を使用した並列タスクの起動 単純な並列ジョブの場合は、lstools コマンドを使用して、ジョブの要素を他の ホストで開始することができます。lstools コマンドではシグナルを透過的に処 理するので、LSF ではプログラムを修正しなくても、ジョブのすべての構成要素を 中断したり、再開することができます。 最も単純な並列ジョブは、各ホストで同一の実行可能プログラムのコピーを実行す るものです。lsgrun コマンドはホスト名のリストを取得して、各ホストで指定さ れたタスクを実行します。lsgrun -p コマンドは、各ホストでタスクが並行して 実行されるように指定します。 例 次の例では、lsgrun を使用して、myjob を指定したすべてのホストで同時に実行 するジョブを投入しています。 % bsub -n 10 'lsgrun -p -m "$LSB_HOSTS" myjob' Job <3856> is submitted to default queue <normal>. より複雑なジョブの場合は、lsrun をバックグラウンドで実行し、各構成要素を開 始するシェル スクリプトを作成することができます。 Platform Clusterware 管理者 275 並列ジョブのジョブ スロット制限 並列ジョブのジョブ スロット制限 ジョブ スロットは、LSF におけるプロセッサ割振りの基本単位です。順次ジョブは、 1 つのジョブ スロットを使用します。N 個の構成要素(タスク)を持つ並列ジョブ は、N 個のジョブ スロットを使用します。これらのジョブ スロットは複数のホスト に分散していることもあります。 デフォルトでは、実行中ジョブと中断されたジョブは、それに関連するキュー、ユー ザ、ホスト、プロセッサのジョブ スロット制限の対象としてカウントします。 276 Platform Clusterware 管理者 第 VIII 部 クラスタの監視 内容 ◆ ◆ ◆ ◆ ◆ 第 第 第 第 第 26 27 28 29 30 章、「クラスタのチューニング」 章、「認証」 章、「ジョブ電子メール、ジョブ ファイル スプール」 章、「エラーとイベント ログ」 章、「トラブルシューティングとエラー メッセージ」 第 26 章 クラスタのチューニング 内容 ◆ 280 ページの「LIM のチューニング」 Platform Clusterware 管理者 279 LIM のチューニング LIM のチューニング LIM は、すべての LSF 構成要素に重要なサービスを提供します。リソース情報を適 時収集するだけでなく、ホスト選択とジョブ配置ポリシーも提供します。さらに、 Platform MultiCluster を使用している場合、クラスタ間で負荷やリソースの情報を交 換する方法も LIM によって決定されます。LIM のポリシーとパラメータは、パ フォーマンスを改善するためにチューニングすることができます。 LIM では、負荷しきい値を使用して、リモート ジョブをホストに配置するかどうか を判断します。LSF の負荷インデックスが、対応するしきい値を超えている(過度 のユーザ、スワップ スペースの不足、など)場合、そのホストはビジー状態である と認識され、LIM はジョブを割り当てないようにします。LIM の負荷しきい値も チューニングすることができます。 さらに、LIM のデフォルトの振る舞いを変更したり、事前に選択されたホストをマ スタに指定して、パフォーマンスを改善することもできます。 このセクションの内 ◆ 容 ◆ 280 Platform Clusterware 管理者 281 ページの「LIM パラメータの調整」 282 ページの「負荷しきい値」 第 26 章 クラスタのチューニング LIM パラメータの調整 LIM 構成パラメータを調整する 2 つの主な目的は、応答時間の短縮と対話形式の使 用との競合の回避です。応答時間を短縮するには、各ジョブに最適なホストが正し く選択されるように LSF を調整します。競合を削減するには、すべてのホストの過 負荷を回避するように LSF を調整します。 LIM ポリシーは、アプリケーションに対する助言情報です。アプリケーションは、 LIM からの配置決定を使用することも、LIM からの情報に基づいて詳細な決定を行 うこともできます。 lsrun や lstcsh など、LSF Base の対話型ツールの多くは、LIM ポリシーを使用して ネットワークにジョブを配置しています。LSF Batch では、LIM からの負荷情報と リソース情報を使用し、さらに負荷情報以外の要素も考慮して、独自の配置決定を 行います。 LIM に影響するファイルは、lsf.shared、lsf.cluster.cluster_name です。 この cluster_name には、実際の LSF クラスタ名が使用されます。 RUNWINDOW パラメータ ジョブ配置に関する LIM のアドバイスには LIM しきい値と実行ウィンドウが影響 します。ジョブ配置に関するアドバイスは、LIM によって強制されるわけではあり ません。 lsf.cluster.cluster_name の RUNWINDOW ウィンドウ パラメータは時間 ウィンドウを定義します。この期間そのホストは他のホストからの負荷の分散に使 用可能とみなされます。現在時刻が、定義されているすべての時間ウィンドウの範 囲外である場合、そのホストはロックされているとみなされ、LIM はアプリケー ションに対してこのホストでジョブを実行するようにアドバイスしなくなります。 Platform Clusterware 管理者 281 負荷しきい値 負荷しきい値 負荷しきい値パラメータには、LIM がホストをビジー状態と判断するときの条件を 定義します。このパラメータは、LSF のパフォーマンスに影響する重要な要素です。 LIM ポリシーに従うと、ビジー状態のホストにはジョブがディスパッチされません。 これらのパラメータは、それぞれ負荷インデックス値を示し、ホストの負荷がその 値を超えると、このホストはビジー状態になります。 LIM は負荷しきい値を使用して、リモート ジョブをホストに配置するかどうかを判 断します。LSF の負荷インデックスが、対応するしきい値を超えている(過度のユー ザ、スワップ スペースの不足、など)場合、そのホストはビジー状態であると認識 され、LIM はジョブを割り当てないようにします。 しきい値は、LIM によって内部的にサポートされている負荷インデックスと、外部 負荷インデックスに設定できます。 特定の負荷インデックスが指定されない場合、LIM はその負荷インデックスにしき い値がないと判断します。積極的にジョブを実行したいホストには、余裕のある値 を定義します。 詳細については、209 ページの「負荷しきい値」を参照してください。 このセクションの内 ◆ 容 ◆ ◆ ◆ ◆ 282 282 283 283 284 ページの「LIM に影響する負荷インデックス」 ページの「LIM 負荷しきい値の比較」 ページの「LIM からホストのビジー状態が頻繁に報告される場合」 ページの「対話型ジョブの応答が遅くなった場合」 ページの「マルチプロセッサ システム」 LIM に影響する負荷インデックス Load index 説明 r15s r1m r15m pg swp it ls 15 秒 CPU 実行キュー長 1 分 CPU 実行キュー長 15 分 CPU 実行キュー長 1 秒当たりのページ数によるページング レート 使用可能なスワップ スペース 対話形式のアイドル時間 ログインしたユーザ数 負荷インデックスの詳細については、105 ページの「負荷インデックス」を参照し てください。 LIM 負荷しきい値の比較 LIM 負荷しきい値をチューニングするには、lsload の出力と lshosts -l によっ て報告されたしきい値を比較します。 lsload コマンドと lsmon コマンドは、しきい値を超えている負荷インデックス の横にアスタリスク * を表示します。 282 Platform Clusterware 管理者 第 26 章 クラスタのチューニング 例 次の lshosts -l および lsload からの出力例について考えてみます。 % lshosts -l HOST_NAME: hostD ... LOAD_THRESHOLDS: r15s r1m r15m 3.5 - ut - pg 15 io - ls - it - tmp - swp 2M mem 1M HOST_NAME: hostA ... LOAD_THRESHOLDS: r15s r1m r15m 3.5 - ut - pg 15 io - ls - it - tmp - swp 2M mem 1M % lsload HOST_NAME status r15s hostD ok 0.0 hostA busy 1.9 r1m 0.0 2.1 r15m 0.0 1.9 ut 0% 47% pg ls 0.0 6 *69.6 21 it 0 0 tmp 30M 38M swp 32M 96M mem 10M 60M この例では、各リソースが次のように使用されます。 ◆ ◆ hostD は ok。 hostA は busy - pg(ページング レート)インデックスが 69.6 で、しきい値 の 15 を超えています。 LIM からホストのビジー状態が頻繁に報告される場合 CPU 使用率と実行キュー長の値が比較的低く、システムが迅速に応答しているとき に、LIM からホストが busy であると報告されることがあれば、ほとんどの場合、 ページング レートしきい値に原因があります。pg しきい値を高く設定してみてく ださい。 オペレーティング システムが異なると、ページング レート統計の意味合いも微妙 に違ってくるので、ホスト タイプごとに、しきい値に異なるレベルを設定する必要 があります。特に、HP-UX システムでは、pg 値をかなり高く設定する必要があり ます。最初は値を 50 に設定してください。 効果が縮小するポイントがあります。ページング レートが上昇するに従って、シス テムがページングを待つ時間が非常に長くなり、CPU 使用率が低下します。ページ ング レートは、認識される対話の応答に最も直接的に影響する要素です。システム のページングが過度になると、非常に遅く感じられます。 対話型ジョブの応答が遅くなった場合 LIM からの報告では ok とされているホストで、対話型ジョブの応答が遅くなって いる場合は、CPU 実行キュー長(r15s、r1m、r15m)を短くします。同様に、わ ずかな負荷でもホストがビジー状態になる場合は、CPU 実行キュー長を長くしま す。 Platform Clusterware 管理者 283 負荷しきい値 マルチプロセッサ システム マルチプロセッサ システムでは、CPU 実行キュー長(r15s、r1m、r15m)が lsload -E コマンドによって表示される効果的な実行キュー長と比較されます。 CPU 実行キュー長には、1 つのプロセッサの負荷制限を設定する必要があります。 多種多様なユニプロセッサ マシンとマルチプロセッサ マシンが混在するサイトで は、構成ファイルには、標準値として r15s、r1m、および r15m を使用すること ができます。その結果、マルチプロセッサ マシンでは、自動的により多くのジョブ が実行されます。 lsload -N によって表示される正常な実行キュー長は、プロセッサ数に応じて拡 大されています。効果的な実行キュー長と正常な実行キュー長の概念については、 105 ページの「負荷インデックス」を参照してください。 284 Platform Clusterware 管理者 第 27 章 認証 リモート実行の使用を制御するには、次の 2 つの処理が必要です。 ◆ ユーザを認証する ユーザが実行するリモート コマンドは、そのユーザのアクセス権を使用して実 行しなければなりません。そのため、LSF のデーモンは、どのユーザがリモー ト実行を要求しているのかを知る必要があります。 ◆ リモート ホストのアクセス制御をチェックする 該当するホストでコマンドをリモート実行する権限が、ユーザに与えられてい なければなりません。 本章では、LSF でのユーザ、ホスト、デーモンの認証について説明します。 内容 ◆ ◆ ◆ 286 ページの「ユーザの認証」 291 ページの「ホストの認証」 292 ページの「デーモンの認証」 Platform Clusterware 管理者 285 ユーザの認証 ユーザの認証 ◆ UNIX 環境では、ユーザ アカウントはシステム レベルで検証されるため、すべ てのホストで有効になります。 ユーザ認証方式 LSF ユーザがコマンドをリモート実行できるようにするには、LSF がネットワーク を介してリモート実行を許可するために使用する認証方式を指定する必要があり ます。 次の認証方式を選択できます。 外部認証(eauth) 特権ポート(setuid) ◆ 識別デーモン(identd) ◆ LSF のデーモンの実行中に認証方式を変更した場合は、それぞれの LSF サーバ ホス トで、これらのデーモンを一旦停止してから再起動し、これらのデーモンが新しい 認証方式を使用できるようにする必要があります。 ◆ 外部認証(eauth) LSF が使用するデフォルトのユーザ認証方式です。この認証方式では、 LSF_SERVERDIR ディレクトリにインストールされた、LSF の eauth プログラムを 使用します。代わりに、GSSAPI を使用した Kerberos(または DCE)クライアント 認証など、サイト固有の認証方式を使用する独自の eauth プログラムを作成する こともできます。 LSF_MISC/examples/krb ディレクトリと LSF_MISC/examples/dce ディレ クトリに、これらのプログラムのサンプルが含まれています。サンプル プログラム のインストール手順については、これらのディレクトリにある README ファイル を参照してください。 デフォルトでは、eauth は内部キーを使用して認証データを暗号化します。セキュ リティを強化するために外部キーを使用したい場合は、lsf.sudoers ファイルで LSF_EAUTH_KEY パラメータを設定します。デフォルトの eauth プログラムは、 setuid 権限を付けずにインストールされますが、LSF_EAUTH_KEY を使用する場 合は、eauth を setuid しておく必要があります。 eauth による認証方式では、ユーザのデータ(認証情報など)を実行ホストに渡す ことができます。それには、LSF_EAUTH_AUX_DATA 環境変数で、これらのデータ の保存先のファイルをフルパス名で指定します。また、eauth -c および eauth -s を使用すると、LSF のデーモンどうしが、これらのデータを安全な方法 で受け渡すことができます。 eauth -c host_name コマンドが呼び出されると、クライアント プログラムは eauth -c host_name を自動的に実行し、外部認証データを取得します。ここで、h o st_n a m e は、処理を 行う LSF のデーモン(RES など)の実行先のホスト名です。取得された外部ユーザ 認証データは、eauth プログラムの標準出力を介して LSF に渡されます。 286 Platform Clusterware 管理者 第 27 章 認証 eauth -s 要求を受け取った LSF のデーモンは、ユーザ認証データを処理するために、プライ マリ LSF 管理者のユーザ ID で eauth -s を実行します。 プライマリ LSF 管理者のユーザ ID では認証を実行できないサイトでは、 /etc/lsf.sudoers ファイルで LSF_EAUTH_USER パラメータを設定する必要が あります。 LSF のデーモンは、eauth -s によって標準出力に書き出された情報を次のように 解釈します。 1 - 認証が成功 0 - 認証が失敗 同じ eauth -s プロセスで複数の認証要求を処理できます。このプロセスが終了 すると、LSF のデーモンは eauth -s を再び呼び出し、次の認証要求を処理します。 ◆ ◆ 『Pla tfo rm LSF Re fe re n c e 』を参照し lsf.sudoers ファイルの設定方法については、 てください。 eauth プログラムの標準入力ストリーム eauth -s は、標準入力を介してユーザ認証データを受け取ります。eauth の標 準入力ストリームの形式は次のようになります。 u id g id u se r_n a m e c lie n t_a d d r c lie n t_p o rt u se r_a u th _d a ta _le n u se r_a u th _d a ta 各項目の意味は次のとおりです。 ◆ ◆ ◆ ◆ ◆ ◆ ◆ u id - クライアント ユーザのユーザ ID (ASCII 形式 ) g id - クライアント ユーザのグループ ID (ASCII 形式 ) u se r_n a m e - クライアント ユーザのユーザ名 c lie n t_a d d r - クライアント ホストのホスト アドレス(ドット表記、ASCII 形式) c lie n t_po rt - クライアント要求の送出元のポート番号 u se r_a u th _d a ta _le n - クライアントから渡された ASCII 形式の外部ユーザ認証 データの長さ u se r_a u th _d a ta - クライアントから渡された外部ユーザ認証データ Platform Clusterware 管理者 287 ユーザの認証 特権ポート認証(setuid) 外部認証を使用しなかった場合、特権ポート(setuid)認証が使用されます。こ れは、UNIX のほとんどのリモート ユーティリティで使用される認証方式です。こ の認証方式を使用するには、LSF のコマンドを setuid プログラムとしてインス トールし、その所有者を root ユーザに設定しておく必要があります。 負荷分散プログラムが root ユーザによって所有されていて、そのプログラムの setuid ビットがセットされている場合、LSF の API 関数は特権ポートを使用して LSF サーバと通信し、LSF サーバは呼び出し元のプログラムから渡されたユーザ ID を受け取ります。これは、UNIX の rlogin コマンドや rsh コマンドで使用される ユーザ認証方式と同じです。 setuid アプリケーションが LSLIB の初期化ルーチンを呼び出すと、LSF サーバと のリモート接続用に多数の特権ポートが割り当てられ、その後で実効ユーザ ID が 実ユーザ ID に戻されます。そのため、リモート接続の数が制限されます。 LSF ユーティリティは、RES との接続を、該当するホストでのすべてのリモート タ スクの実行で再利用します。そのため、特権ポートの数によって制限されるのは、 1 つのアプリケーションから使用できるリモート ホストの数だけで、リモート タ スクの数は制限されません。LSLIB を使用するプログラムは、初期化時に作成する 特権ポートの数を指定できます。 識別デーモン(identd) LSF は、RFC 931 や RFC 1413 で定められた認証プロトコルを使用した認証方式にも 対応しています。これらのプロトコルでは、ユーザ プログラムを root ユーザによっ て所有された setuid プログラムとしてインストールする必要はありません。ただ し、パブリック ドメイン ソフトウェアとして公開されている identd デーモンを インストールしておく必要があります。 RFC 1413 プロトコルと RFC 931 プロトコルでは、それぞれのクライアント ホスト で実行されている識別デーモンを使用します。RFC 1413 のほうが RFC 931 より新 しい標準です。LSF は、どちらの標準にも対応しています。識別デーモンを使用す るとオーバーヘッドが増えますが、LSF アプリケーションによる特権ポートの割り 当てを行う必要がなくなります。 識別デーモンは、root ユーザによって所有され、setuid ビットがセットされたプ ログラムをサイトにインストールできない場合や、LSLIB を使用する新しい負荷分 散アプリケーションを C 言語で作成しているソフトウェア開発者がいる場合に使 用します。 pidentd、authd を始めとする RFC 931 や RFC1413 を実装した識別デーモンが、 パブリック ドメイン ソフトウェアとして公開されています。インターネットに FTP プロトコルでアクセスできる場合は、たとえばホスト ftp.lysator.liu.se の ディレクトリ pub/ident/servers から、これらのデーモンを入手できます。 LSF によるユーザ認証方式の決定方法 LSF は、lsf.conf ファイルの LSF_AUTH パラメータを使用して、どの認証方式を 使用するかを決定します。 このパラメータの値が eauth(デフォルト値)に設定されている場合は、外部ユー ザ認証が使用されます。その場合、LSF は LSF_SERVERDIR ディレクトリにある外 部プログラム、eauth を実行して認証を行います。 288 Platform Clusterware 管理者 第 27 章 認証 負荷分散アプリケーションが root ユーザに setuid されていない場合は、ライブ ラ リ 関 数 は 非 特 権 ポ ー ト を 使 用 し ま す。そ の 場 合 に、lsf.conf フ ァ イ ル で LSF_AUTH パラメータが設定されていないと、接続が拒否されてしまいます。 LSF_AUTH パラメータの値が ident に設定されている場合は、リモート ホスト上 の RES ( bsub コマンドの場合は mbatchd) が、ローカル ホスト上の識別デーモン に接続し、ユーザ ID を検証します。ローカル ホスト上の識別デーモンは、カーネ ルを直接参照し、使用されているネットワーク ポート番号が、指定されたユーザが 実行しているプログラムに接続されているかどうかを確認します。 LSF では、特権ポートと識別デーモンの 2 種類の認証方式を同時に使用できます。 負荷分散アプリケーションの実効ユーザ ID が root だった場合は、RES との接続に 特権ポート番号が使用されます。その場合、たとえ LSF_AUTH パラメータの値が ident に設定されていたとしても、RES は常に既知のホストの特権ポートから要求 を受け取ります。アプリケーションの実効ユーザ ID が root ではなく、LSF_AUTH パラメータの値が ident に設定されている場合は、通常のポート番号が使用され、 RES は識別デーモンに接続してユーザ ID を検証します。 管理コマンドの setuid 権限 lsadmin、badmin といった LSF の管理コマンドは、デフォルトで setuid プロ グラムとしてインストールされます。LSF のそれ以外のコマンドは、識別デーモン を使用すれば、setuid 権限を付けずに実行できます。 setuid 権限を許可しないファイル サーバを使用している場合は、setuid 権限を 設定できるファイル システムに LSF_BINDIR ディレクトリをインストールしてく ださい。 LSF 認証のセキュリティ LSF が対応しているどの認証方式も、クラスタ内のすべてのホストの root アカウン トのセキュリティの上に成り立っています。root アカウントにアクセスできるユー ザがいれば、これらの認証方式は破られてしまいます。ただし、root 以外のユーザ による、他のユーザの権限でのプログラムの実行を可能にする、既知のセキュリ ティ ホールはありません。 RFC 1413 識別デーモンなどのセキュリティ スキームの脆弱性に不安を感じている 人々もいます。未知のホストから要求が着信した場合、そのホスト上の識別デーモ ンが、要求の送出元のユーザを正しく特定しているかどうかを確認する方法はあり ません。 ただし、LSF は、LSF クラスタ内のホストから送出されたジョブ実行要求だけを受 け取るため、識別デーモンを信頼することができます。 LSF は、システム環境変数 LSF_ENVDIR を参照して、lsf.conf ファイルの配置先 を取得します。このファイルには、LSF のさまざまな構成ファイルの場所が記録さ れています。そのため、システム環境変数を変更できるユーザがいる場合、その ユ ー ザ が LSF_ENVDIR 環 境 変 数 の 値 を 変 更 し て 独 自 の 構 成 情 報 を 参 照 さ せ、 l sfadmin アカウント(LSF 管理者のアカウント)でプログラムを起動してしまう可 能性があります。 LSF のデーモンから呼び出される外部プログラム(esub、eexec、elim、eauth、 キュー レベルの実行前 / 実行後コマンドなど)は、すべて lsfadmin アカウントで 実行されます。 Platform Clusterware 管理者 289 ユーザの認証 UNIX UNIX では、デフォルトで外部認証がインストールされます。認証プロトコル (identd)を使用して認証を行う場合、LSF は UNIX の特権ポートの範囲内のポー トを使用します。そのため、一般ユーザが、ハッキングした識別デーモンを LSF ホ スト上で実行することは不可能です。 すなわち、UNIX では、認証は特権ポートを使用して行われ、認証が必要なプログ ラム(bsub など)は root ユーザが所有する setuid プログラム(setuid-root プ ログラム)としてインストールされます。 ユーザ認証エラーの修正 LSF がユーザ ID を検証できない場合、LSF のコマンドから「User permission denied」というエラー メッセージが返されます。 このエラーが発生した場合、次の原因が考えられます。 ◆ ◆ ◆ ◆ ◆ 290 Platform Clusterware 管理者 LSF アプリケーションが setuid プログラムとしてインストールされていない NFS ディレクトリが nosuid オプションを指定してマウントされている ローカル ホストまたは投入ホストに識別デーモンが存在しない 外部認証が失敗した ruserok() を使用するように LSF が設定されているにもかかわらず、マスタ ホスト上やリモート ホスト上の /etc/hosts.equiv ファイルや $HOME/.rhosts ファイルでクライアント ホストが指定されていない 第 27 章 認証 ホストの認証 LSF は、バッチ ジョブやリモート実行の要求を受け取ると、まずユーザ ID を特定 します。ユーザ ID が既知のものだった場合、LSF は次に要求の送出元のホストが 信頼できるかどうかを判断します。 LSF ホストの信頼 通常、LSF では root 以外のすべてのユーザによる、LSF クラスタ内の全ホストから のリモート実行が許可されます。すなわち、LSF はクラスタに含まれているすべて のホストを信頼しています。その理由は、LSF クラスタを構成することで、複数の マシンからなるネットワークが単一のコンピュータへと変換されているからです。 すべてのホストで、ユーザに有効なアカウントを割り当ててください。このように すれば、クラスタのどのホストでも、ユーザ全員が自分自身の権限でジョブを実行 できます。LSF クラスタに含まれていないホストからのリモート実行の要求やバッ チ ジョブの投入は拒否されます。 それぞれのサイトでは、追加ユーザや追加ホストを承認する外部プログラムを設定 できます。lsf.conf ファイルで LSF_AUTH パラメータの値を eauth に設定する と、LSF のデーモンは、認証と承認が必要な要求を受け取ったときに eauth -s を 呼び出します。eauth は、クライアント ユーザがユーザ リストに含まれているか どうか、ホストを信頼してもよいかどうか、といったことをチェックできます。 /etc/hosts.equiv (UNIX) lsf.conf ファイルで LSF_USE_HOSTEQUIV パラメータを設定すると、LSF は rsh コマンドと同じリモート実行アクセス制御方式を使用します。すなわち、リモート ホストでジョブが実行されるときに、ユーザ名とジョブの送出元のホストが、リ モート ホスト上で ruserok(3) 関数を使用してチェックされるようになります。 ruserok(3) 関数は、/etc/hosts.equiv ファイルとユーザの $HOME/.rhosts ファイルをチェックし、該当するユーザにジョブの実行権限が与えられているかど うかを判断します。 このリストの中でローカル ホスト名を指定しておく必要があります。RES はローカ ル ホストからの接続に対して ruserok() を呼び出します。また、mbatchd はマ スタ ホスト上の ruserok() を呼び出します。そのため、マスタ ホストでは、LSF のユーザ全員に有効なアカウントとリモート実行権限を割り当てておく必要があ ります。 /etc/hosts.equiv ファイルと $HOME/.rhosts ファイルを使用する方式には 欠点があります。それは、パスワードを指定しなくても、rlogin コマンドや rsh コマンドの使用権限が与えられてしまうことです。サイトによっては、このような アクセスがセキュリティ ポリシーによって制限されています。 詳細情報の参照先 ファイルの形式と、実行されるアクセス チェックの詳細については、 hosts.equiv(5) と ruserok(3) のマニュアル ページを参照してください。 Platform Clusterware 管理者 291 デーモンの認証 デーモンの認証 LSF の Kerberos 統合パッケージには、以下に説明する拡張外部認証機能用の eauth プログラムが含まれています。このプログラムの詳細(インストール、設定など) については、Kerberos 統合パッケージを参照してください。 デーモン認証 デフォルトでは、eauth プログラムはユーザ認証(LSF ユーザから RES や mbatchd への要求の認証)のためだけに使用されます。 同じ eauth プログラムを、デーモン間の次の通信の認証に使用することもできます。 mbatchd から sbatchd への要求 sbatchd から mbatchd への更新 PAM と sbatchd との通信 ◆ この eauth プログラムは、次の環境変数を使用してコンテキスト情報を提供でき ます。 ◆ ◆ ◆ ◆ LSF_EAUTH_CLIENT - 認証要求の送出元 LSF_EAUTH_SERVER - 認証要求の受取先 デーモン認証の設定 デーモン認証を有効にするには、次のように lsf.conf ファイルで LSF_AUTH_DAEMONS パラメータを設定します。 LSF_AUTH_DAEMONS=1 292 Platform Clusterware 管理者 第 28 章 ジョブ電子メール、ジョブ ファイル スプール 内容 ◆ ◆ 294 ページの「ジョブ開始時のメール通知」 297 ページの「ジョブ入力ファイル、ジョブ出力ファイル、ジョブ コマンド ファイルのスプール」 Platform Clusterware 管理者 293 ジョブ開始時のメール通知 ジョブ開始時のメール通知 デフォルトでは、バッチ ジョブが完了または終了すると、LSF は投入元のユーザ ア カウントに電子メールでジョブ レポートを送信します。このレポートには、次の情 報が含まれています。 ジョブの標準出力(stdout) ジョブの標準エラー(stderr) ◆ ◆ CPU、プロセス、メモリの使用率などの LSF ジョブ情報 stdout と stderr からの出力は、ジョブが対話形式で実行されたように、印刷順 にマージされています。デフォルトの標準入力(stdin)ファイルは null 装置で す。UNIX の null 装置は /dev/null です。 ◆ bsub メール オプション -B ジョブがディスパッチされ、実行が開始されたときに、ジョブの投入元に電子メー ルを送信します。電子メールのデフォルトの宛先は、lsf.conf の LSB_MAILTO に 定義されています。 -u user_name 他のユーザにメールが送信されるようにするには、bsub コマンドに -u u se r_n a m e オプションを使用します。そのジョブに関連するメールは、投入したユーザ アカウ ントではなく、指定されたユーザに送信されます。 -N ジョブ出力とジョブ レポート情報を分割する場合は、-N オプションを使用して、 ジョブ レポート情報が電子メールで送信されるように指定します。 -o オプションと -e 通常、bsub コマンドの -o オプションを使用して作成された出力には、ジョブ出 オプション 力の他にジョブ レポートも含まれます。この中には、投入したユーザとホスト、実 行ホスト、ジョブに使用された CPU 時間(ユーザ時間とシステム時間の合計)、終 了状態などの情報が含まれます。 -o o u tp u t_file オプションを指定し、-e e rro r_file オプションは指定しなかった場 合、標準出力と標準エラーが結合され、その結果が o u tpu t_file に保存されます。 stdin からの読み込みが必要なジョブでは、標準入力ファイルも指定できます。 -o オプションと -e オプションで指定された出力ファイルは、実行ホストに作成さ れます。 294 Platform Clusterware 管理者 第 28 章 ジョブ電子メール、ジョブ ファイル スプール ジョブ電子メールの ジョブの出力が電子メールで送信されないようにするには、-o オプションや -e オ 無効化 プションで stdout や stderr をファイルとして指定します。たとえば、次のコ マンドを使用すると、stdout と stderr の出力先が /tmp/job_out というファ イルに切り替えられ、電子メールが送信されなくなります。 bsub -o /tmp/job_out sleep 5 UNIX では、出力ファイルとして /dev/null を指定すると、ジョブの出力と電子 メールの送信の両方を無効にできます。 bsub -o /dev/null sleep 5 例 次の例では、myjob を night キューに投入しています。 % bsub -q night -i job_in -o job_out -e job_err myjob ジョブは、job_in ファイルから入力を読み取ります。標準出力は job_out ファ イルに格納され、標準エラーは job_err ファイルに格納されます。 -o output_file オプションを指定し、-e error_file オプションを指定しない と、標準出力と標準エラーがマージされ、output_file に格納されます。 ジョブ電子メールのサイズ バッチ ジョブによっては、大量の出力が作成される可能性があります。大容量な ジョブ出力ファイルによってメール システムが妨害されるのを回避するために、 lsf.conf の LSB_MAILSIZE_LIMIT パラメータを使用して、ジョブ出力情報を含む 電子メールの最大サイズを KB 単位で指定します。 デフォルトでは、LSB_MAILSIZE_LIMIT は有効化されていません。したがって、バッ チ ジョブ出力電子メールのサイズは制限されていません。 ジョブ出力電子メールのサイズが LSB_MAILSIZE_LIMIT を超えた場合、出力は JOB_SPOOL_DIR の中のファイルに保存されます。JOB_SPOOL_DIR が定義されて いない場合は、デフォルトのジョブ出力ディレクトリのファイルに保存されます。 ジョブ出力の場所は電子メールでユーザに通知されます。 の オ プ シ ョ ン が 使 用 さ れ た 場 合、ジ ョ ブ 出 力 の サ イ ズ は bsub -o LSB_MAILSIZE_LIMIT とチェックされません。 LSB_MAILSIZE 環 LSF は、ジ ョ ブ 出 力 情 報 が 格 納 さ れ て い る 電 子 メ ー ル の お お よ そ の サ イ ズ を 境変数 LSB_MAILSIZE に KB 単位で設定し、カスタム メール プログラムが必要な量を超え た 出 力 を 遮 断 で き る よ う に し ま す。LSB_MAILPROG パ ラ メ ー タ を 使 用 し て、 LSB_MAILSIZE 環境変数を使用できるカスタム メール プログラムを指定している 場合は、LSB_MAILSIZE_LIMIT を設定する必要はありません。 LSF のデフォルトのメール プログラムで LSB_MAILSIZE は認識されません。した がって、大量のジョブ出力ファイルによってメール システムが妨害されるのを回避 するには、LSB_MAILSIZE_LIMIT を使用して、ジョブ情報が格納されている電子メー ルの最大サイズを KB 単位で設定します。 LSB_MAILSIZE の LSB_MAILSIZE 環境変数は次の値に設定される可能性があります。 設定値 ◆ 正の整数 電子メールによる出力の送出中は、メール サイズの KB 単位の推定値に設定さ れます。 ◆ -1 Platform Clusterware 管理者 295 ジョブ開始時のメール通知 出力エラーが発生した場合や、出力を読み取れない場合は -1 に設定されます。 lsf.conf ファイルで LSB_MAILPROG パラメータが指定されている場合は、 そのパラメータで指定されたメール プログラムが使用され、出力が電子メール で送出されます。 ◆ 未定義 -o オプションや -e オプションを付けた bsub コマンドを使用した場合は、出 力は出力ファイルにリダイレクトされます。その場合は、出力は電子メールで 送出されないため、LSB_MAILSIZE 環境変数は使用されず、LSB_MAILPROG パラメータで指定されたメール プログラムも呼び出されません。 bsub コマンドで -o オプションと共に -N オプションも指定した場合は、 LSB_MAILSIZE は設定されません。 ジョブ出力のディレクトリ bsub および bmod コマンドの -o オプションと -e オプションには、ファイル名 かディレクトリ パスを使用できます。LSF は、このディレクトリに標準出力と標準 エラーを作成します。これらのオプションでディレクトリ パスだけを指定した場合 は、ジョブの出力ファイルとエラー ファイルがジョブ ID に基づく固有の名前を付 けて作成されるため、出力ディレクトリをジョブごとに別々にする必要はなく、す べてのジョブ出力で同じディレクトリを使用できます。 ジョブ出力のディレクトリの指定 パスの最後の文字を、UNIX ではスラッシュ(/)にします。最後のスラッシュを省 略すると、指定した文字列がファイル名として取り扱われます。 指定されたディレクトリが存在しないときは、LSF が標準エラーと標準出力を作成 するときに、実行ホスト上にそのディレクトリを作成します。 デフォルトでは、出力ファイルのフォーマットは、次のようになります。 標準出力 output_directory/job_ID.out 標準エラー error_directory/job_ID.err 例 次のコマンドでは、/usr/share/lsf_out ディレクトリが存在しなければこれを 作 成 し、ジ ョ ブ が 完 了 し た 時 点 で こ の デ ィ レ ク ト リ に 標 準 出 力 フ ァ イ ル job_ID.out を作成します。 % bsub -o /usr/share/lsf_out/ myjob 詳細情報の参照先 LSB_MAILSIZE 環境変数と lsf.conf ファイルの LSB_MAILTO、 LSB_MAILSIZE_LIMIT、および JOB_SPOOL_DIR パラメータに関する情報は、 『Pla tfo rm LSF Re fe re n c e 』を参照してください。 296 Platform Clusterware 管理者 第 28 章 ジョブ電子メール、ジョブ ファイル スプール ジョブ入力ファイル、ジョブ出力ファイル、ジョブ コマ ンド ファイルのスプール ジョブ ファイルのスプールとは LSF では、ジョブの入力と出力をバッファリングするためのディレクトリとファイ ルを作成しておくと、ジョブ入力ファイルとコマンド ファイルがスプールされま す。これらのファイルは、ジョブが完了した時点で LSF によって削除されます。 ファイル スプール機能を使用するには、ジョブを投入するときに、bsub に -is お よび -Zs オプションを指定します。bmod に同様のオプションを使用すると、ジョ ブに対するスプール ファイル指定を修正したり、取り消すことができます。ファイ ルのスプール オプションは、ジョブが完了する前に、元のジョブ入力やコマンド ファイルを修正したり、削除する必要があるときに使用します。元のジョブ入力や コマンド ファイルを修正したり、削除しても、投入されたジョブには影響しません。 ジョブ入力ファイルの指定 bsub -i input_file コマンドと bsub -is input_file コマンドを使用する と、input_file で指定されたファイル パス名からジョブの標準入力を取得できます。 パスには、絶対パスか現在の作業ディレクトリへの相対パスを使用できます。入力 ファイルのファイル タイプは任意ですが、通常はシェル スクリプト テキスト ファ イルが使用されます。 LSF は最初に実行ホストをチェックして、入力ファイルが存在しているか確認しま す。ファイルが実行ホストに存在する場合、このファイルをジョブの入力ファイル として使用します。 実行ホストにファイルが存在しない場合、サブミッション ホストから実行ホストに ファイルをコピーします。ファイルが正常にコピーされるためには、リモート コ ピー アクセス(rcp)が許可されているか、RES が実行されているサーバ ホストか らジョブを投入する必要があります。ファイルは、サブミッション ホストから JOB_SPOOL_DIR パラメータで指定されたディレクトリまたは実行ホスト上の $HOME/.lsbatch ディレクトリの一時ファイルにコピーされます。このファイル は、ジョブが完了すると LSF によって削除されます。 bsub の -is オプションを使用すると、lsb.params の JOB_SPOOL_DIR パラメー タで指定されたディレクトリに入力ファイルがスプールされ、そのスプール ファイ ルがジョブの入力ファイルとして使用されます。 ジョブが完了する前に、元の入力ファイルを変更する必要があるときは、bsub is コマンドを使用します。元の入力ファイルを削除したり、修正しても、投入さ れたジョブには影響しません。 -is を使用しない場合、入力ファイルの名前に特殊文字 %J および %I を使用する ことができます。%J はジョブ ID に置き換えられます。また %I は、ジョブが配列 のメンバである場合は、配列内のジョブのインデックスに置き換えられ、配列のメ ンバでない場合は、0(ゼロ)に置き換えられます。特殊文字 %J および %I は、is オプションと同時には使用できません。 Platform Clusterware 管理者 297 ジョブ入力ファイル、ジョブ出力ファイル、ジョブ コマンド ファイルのスプール ジョブ コマンド ファイルの指定(bsub -Zs) bsub -Zs コマンドを使用すると、lsb.params の JOB_SPOOL_DIR パラメータ で指定されたディレクトリにジョブ コマンドをスプールできます。LSF は、スプー ルしたファイルをジョブのコマンド ファイルとして使用します。 ジョブが投入された後で、コマンド ファイルを変更する必要がある場合は、 bmod -Zs コマンドを使用します。元の入力ファイルを変更しても、投入された ジョブには影響しません。bmod -Zsn を使用すると、最後にスプールされたコマ ンド ファイルが取り消され、元のスプール ファイルが使用されます。 LSF では埋込みジョブ コマンドにスプールされる最初のコマンドを判断できない ので、埋込みジョブ コマンドに対しては bsub -Zs オプションを使用することは できません。 ジョブ スプール ディレクトリ(JOB_SPOOL_DIR) lsb.params に JOB_SPOOL_DIR が指定されている場合、次のように処理されま す。 bsub -is のジョブ入力ファイルは JOB_SPOOL_DIR/lsf_indir にスプー ルされます。lsf_indir ディレクトリが存在しない場合、ファイルをスプー ルする前に、LSF が作成します。スプール ファイルはジョブが完了した時点で 削除されます。 ◆ bsub -Zs のジョブ コマンド ファイルは JOB_SPOOL_DIR/lsf_cmddir に スプールされます。lsf_cmddir ディレクトリが存在しない場合、ファイルを スプールする前に、LSF が作成します。スプール ファイルはジョブが完了した 時点で削除されます。 JOB_SPOOL_DIR ディレクトリは、マスタ ホスト、サブミッション ホスト、実行 ホストからアクセス可能な共有ディレクトリでなければなりません。また、この ディレクトリはジョブを投入したユーザが読み取りと書き込みを行える必要があ ります。 ◆ bsub -is および bsub -Zs を除き、JOB_SPOOL_DIR がアクセス不可能な場合や 存在しない場合、出力はデフォルトのジョブ出力ディレクトリ .lsbatch にスプー ルされます。 bsub -is および bsub -Zs に関しては、JOB_SPOOL_DIR はジョブを投入した ユーザが読み取りおよび書き込みを行える必要があります。指定したディレクトリ にアクセスできないか、または存在しない場合、bsub -is と bsub -Zs はデフォ ルト ディレクトリに書き込めないため、ジョブは失敗します。 JOB_SPOOL_DIR が lsb.params に指定されていない場合、次の処理が行われま す。 ◆ ◆ 298 Platform Clusterware 管理者 bsub -is のジョブ入力ファイルは LSB_SHAREDIR/cluster_name/lsf_indir にスプールされます。 lsf_indir ディレクトリが存在しない場合、ファイルをスプールする前に LSF が作成します。スプール ファイルはジョブが完了した時点で削除されます。 bsub -Zs のジョブ コマンド ファイルは LSB_SHAREDIR/cluster_name/lsf_cmddir にスプールされます。 lsf_cmddir が存在しない場合、ファイルをスプールする前に LSF が作成しま す。スプール ファイルはジョブが完了した時点で削除されます。 第 28 章 ジョブ電子メール、ジョブ ファイル スプール JOB_SPOOL_DIR を指定せずにジョブ ファイルをスプールする場合は、 LSB_SHAREDIR/cluster_name ディレクトリはジョブを投入するすべてのユー ザが読み取りおよび書き込みを行える必要があります。これが不可能なサイトで は、ジョブを投入するすべてのユーザが読み取りおよび書き込みを行える LSB_SHAREDIR/cluster_name の下に lsf_indir および lsf_cmddir I ディ レクトリを手動で作成する必要があります。 ジョブ入力ファイルの修正 bmod の -i および -is オプションを使用して、新しいジョブ入力ファイルを指定 します。-in および -isn オプションは、-i または -is オプションを使用して ジョブ入力ファイルに対して行った最後の修正を取り消します。 ジョブ コマンド ファイルの修正 bmod の -Z および -Zs オプションを使用して、ジョブ コマンド ファイルの指定 を修正します。-Z はスプールなしで投入されるコマンドの修正に、Zs はスプール されたコマンド ファイルの修正に使用します。bmod の -Zsn オプションは、-Zs を使用してジョブ コマンド ファイルに対して行った最後の修正を取り消し、ス プールされた元のコマンドを使用します。 詳細情報の参照先 bsub お よ び bmod コ マ ン ド、lsb.params の JOB_SPOOL_DIR パ ラ メ ー タ、 LSF_TMPDIR 環境変数に関する情報は、 『Pla tfo rm LSF Re fe re n c e 』を参照してくださ い。 Platform Clusterware 管理者 299 ジョブ入力ファイル、ジョブ出力ファイル、ジョブ コマンド ファイルのスプール 300 Platform Clusterware 管理者 第 29 章 エラーとイベント ログ 内容 ◆ ◆ ◆ 302 ページの「LSF システム ディレクトリとログ ファイル」 303 ページの「エラー ログの管理」 304 ページの「システム イベント ログ」 Platform Clusterware 管理者 301 LSF システム ディレクトリとログ ファイル LSF システム ディレクトリとログ ファイル LSF では、一時作業ファイル用、ログ ファイルとトランザクション ファイル用、お よびスプール用のディレクトリを使用します。 LSF は、ワーク サブツリーにてトランザクション ログを保守することにより、シ ステム内のすべてのジョブを追跡しています。LSF Batch のログ ファイルは、 LSB_SHAREDIR/cluster_name/logdir ディレクトリに保存されます。 LSF Batch システムの状態を保守するために、次のファイルが使用されます。 lsb.events LSF は、lsb.events ファイルを使用して、すべてのジョブの状態を追跡します。各 ジョブは、ジョブの投入からジョブ完了までのトランザクションです。LSF Batch シ ステムは、ジョブに関するあらゆることを追跡し、lsb.events ファイルに記録し ます。 lsb.events.n イベント ファイルが整理され、古いジョブ イベントは lsb.event.n ファイルに 保存されます。この作業は LSF Batch によって自動的に行われます。MBD が開始さ れるときは、lsb.events ファイルだけが参照され、lsb.events.n ファイルは 使用されません。これらのファイルを参照できるのは、bhist コマンドだけです。 info ディレクトリのジョブ スクリプト ファイル ユーザがシェル プロンプトから bsub コマンドを実行すると、LSF は bsub コマン ド行で指定されたすべてのコマンドを収集し、そのデータを mbatchd にスプール します。mbatchd は、bsub コマンドのスクリプトを info ディレクトリに保存し、 ディスパッチ時やジョブを再実行する場合に使用します。info ディレクトリは LSF によって管理されます。どのユーザも、このディレクトリの内容を変更しないでく ださい。 ログ ディレクトリのアクセス権と所有者 LSF_LOGDIR ディレクトリのアクセス権が、root ユーザによる書き込みができる ように設定されていることを確認してください。また、このディレクトリの所有者 は LSF 管理者でなければなりません。 302 Platform Clusterware 管理者 第 29 章 エラーとイベント ログ エラー ログの管理 エラー ログは、LSF 操作に関する重要な情報を保守します。LSF で異常な振る舞い が見られる場合は、最初に適切なエラー ログをチェックして、問題の原因を見つけ だします。 LSF ログ ファイルは、時間の経過と共に大きくなるので、手動または自動スクリプ トを使用して、ときどきクリアする必要があります。 デーモン エラー ログ LSF ログ ファイルは、メッセージが記録されるたびに開かれるので、LSF デーモン のログ ファイルの名前を変更したり、削除すると、デーモンが自動的に新しいログ ファイルを作成します。 LSF デーモンは、問題や異常な状況を検出したときに、メッセージをログします。 これらのメッセージがファイルに書き込まれるようにデーモンを設定することも できます。 LSF Base システム デーモン、LIM、および RES のエラー ログ ファイル名は次のと おりです。 ◆ lim.log.host_name res.log.host_name ◆ pim.log.host_name ◆ sbatchd.log.host_name ◆ mbatchd.log.host_name ◆ mbschd.log.host_name LSF デーモンは、さまざまなレベルでエラー メッセージをログするので、すべての メッセージをログするか、重要と判断したメッセージだけをログするかを選択でき ます。メッセージのログは lsf.conf の LSF_LOG_MASK パラメータで制御されま す。このパラメータの有効な値として、/usr/include/sys/syslog.h に定義さ れているログ優先順位記号のいずれかを設定できます。LSF_LOG_MASK のデフォル ト値は LOG_WARNING です。 ◆ エラー ログ 任意指定の LSF_LOGDIR パラメータが lsf.conf に定義されている場合、LSF サー バからのエラー メッセージはこのディレクトリのファイルに記録されます。 LSF_LOGDIR が定義されていても、デーモンがそのディレクトリのファイルに書き 込めない場合、エラー ログ ファイルは /tmp に作成されます。 LSF_LOGDIR が定義されていない場合、エラーは LOG_DAEMON 機能を使用して、 システム エラー ログ(syslog)に記録されます。syslog メッセージは自由に構 成することができ、デフォルトの構成もシステムごとに大幅に異なります。とりあ えず /etc/syslog.conf ファイルを検索し、syslog( 3) および syslogd( 1) の マニュアル ページを参照してください。 エラー ログが syslog によって管理されている場合、あらかじめ自動的にクリア されているのが普通です。 LSF デーモンが起動されたときに lsf.conf を検出できない場合、LSF_LOGDIR の 定義は検索しません。この場合、エラー メッセージは syslog に書き込まれます。 ログ ファイルでエラー メッセージを検出できない場合、syslog に記録されてい る可能性があります。 Platform Clusterware 管理者 303 システム イベント ログ システム イベント ログ LSF の各デーモンは、lsb.events ファイルにイベント ログを記録します。この 情報は、mbatchd デーモンによるサーバの障害、ホストの再起動、mbatchd の再 起動からの回復に使われます。lsb.events ファイルの情報は、bhist コマンド によるバッチ ジョブの詳細な実行履歴の表示や、badmin コマンドによるホスト、 キュー、デーモンの運用履歴の表示にも使われます。 デフォルトでは、MBD は、1000 個のバッチ ジョブが完了するたびに、lsb.events ファイルを自動的にバックアップし、リライトします。この値は、lsb.params ファイルの MAX_JOB_NUM パラメータで制御されます。古い lsb.events ファイ ル は lsb.events.1 に 移 動 さ れ、個 々 の 古 い lsb.events. n フ ァ イ ル は lsb.events.n+1 に移動されます。MBD でこれらのファイルを削除することはあ りません。ディスク記憶容量が問題になる場合、LSF 管理者は古い lsb.events.n ファイルを定期時にアーカイブまたは削除するための方法を用意する必要があり ます。 警告 現行の lsb.events ファイルは、削除したり、修正しないでください。 lsb.events ファイルの削除または修正を行うと、バッチ ジョブが失われる可能性があります。 304 Platform Clusterware 管理者 第 30 章 トラブルシューティングとエラー メッセージ 内容 ◆ ◆ ◆ 306 ページの「共有ファイル アクセス」 307 ページの「LSF の一般的な問題」 313 ページの「エラー メッセージ」 Platform Clusterware 管理者 305 共有ファイル アクセス 共有ファイル アクセス LSF で発生しがちなのが、ファイル空間が統一されていないために、ファイルにア クセスできない問題です。タスクがリモート ホストで実行される場合に、同じファ イル名を使用して必要なファイルにアクセスできないと、エラーが発生します。ま た、LSF のほとんどの対話型コマンドは、ユーザのカレント作業ディレクトリがリ モート ホスト上に見つからないと、処理を実行できません。 ファイルの共有 NFS を実行している場合は、NFS のマウント テーブルによって、この問題が解決さ れる場合があります。automount サーバを実行している場合は、LSF がファイル 名のマッピングを行おうとし、ほとんどの場合はマッピングが成功します。ただし、 共有マウントを使用している場合は、ファイル名のマッピングが失敗することがあ ります。その場合は、問題に個別に対処する必要があります。 オートマウント(automount)マップは、NIS を使用して管理する必要があります。 LSF によるファイル名のマッピングは、オートマウント ファイル システムが /tmp_mnt ディレクトリにマウントされていることが前提条件になります。 306 Platform Clusterware 管理者 第 30 章 トラブルシューティングとエラー メッセージ LSF の一般的な問題 このセクションでは、LIM、RES、mbatchd、sbatchd、および対話型アプリケー ションでの一般的な問題を説明します。 これらの問題のほとんどは、インストール状態や構成が正しくないことに原因があ ります。エラー ログ ファイルをチェックしてください。多くの場合、記録された ログ メッセージから問題を直接特定できます。 LIM が応答しない 次のコマンドを実行し、LIM の構成ファイルにエラーが含まれていないどうかを チェックします。 % lsadmin ckconfig -v ほとんどの構成エラーは、この方法で確認できます。このコマンドを実行してもエ ラーが報告されなかった場合は、LIM のエラー ログをチェックします。 LIM を使用できない LIM が起動しているにもかかわらず、lsload コマンドを実行すると、次のエラー メッセージが表示されることがあります。 Communication time out. LIM が起動した直後であれば、この状態は正常です。LIM を初期化するために、構 成ファイルを読み取り、他の LIM に接続するには時間がかかるからです。 1 ~ 2 分たっても LIM が使用可能にならない場合は、現在使用しているホスト用の LIM のエラー ログをチェックします。 ローカル LIM は起動していて、クラスタにマスタ LIM がない場合、次のメッセー ジが表示されます。 Cannot locate master LIM now, try later. その場合、lsf.cluster.cluster_name ファイルの Host セクションで定義さ れている最初の数台のホストで、LIM のエラー ログをチェックします。 RES が起動しない RES のエラー ログをチェックします。 RES が lsf.conf ファイルを読み取れず、エラー メッセージの出力先を知ること ができない場合、エラーは syslog(3) に出力されます。 Platform Clusterware 管理者 307 LSF の一般的な問題 ユーザのアクセス権が拒否される リモート実行が失敗し、次のエラー メッセージが返された場合は、リモート ホス トがリモート実行の要求元のユーザのユーザ ID を安全に特定できていません。 User permission denied. リモート ホストで RES のエラー ログをチェックします。通常は、このログの中に、 より詳しいエラー メッセージが含まれています。 識別デーモンを使用していない場合 (lsf.conf ファイルで LSF_AUTH パラメー タが定義されていない場合 ) は、リモート実行を行うすべてのアプリケーションの 所有者を root ユーザにし、その setuid ビットをセットする必要があります。こ の設定は次のコマンドで行うことができます。 % chmod 4755 filename バイナリ ファイルが NFS でマウントされたファイル システムに配置されている場 合は、そのファイル システムが nosuid フラグを付けてマウントされていないこ とを確認します。 識別デーモンを使用している場合(lsf.conf ファイルの LSF_AUTH パラメータで 定義します)は、inetd を設定し、inetd から識別デーモンを起動させる必要が あります。識別デーモンを直接起動してはなりません。 lsf.conf ファイルで LSF_USE_HOSTEQUIV パラメータが定義されている場合は、 実行先のホストの /etc/hosts.equiv ファイルや HOME/.rhosts ファイルで、 クライアント ホスト名が指定されているかどうかをチェックします。これらのファ イルで指定されているホスト名と、ネーム サーバで指定されているホスト名が一致 していない場合も、この問題が発生します。 ネーム サーバを SGI ホストで実行されている場合は、SGI ホストで次のコマンドを 実行すると、ネーム サーバを呼び出す前に、/etc/hosts ファイルを使用してホ スト名を検出させることができます。 % setenv HOSTRESORDER "local,nis,bind" ファイル名空間が統一されていない ファイル名空間が統一されていないために、コマンドの実行が失敗し、次のエラー メッセージが返される場合があります。 chdir(...) failed: no such file or directory この問題が発生するのは、コマンドをリモート実行しようとしたときに、ユーザの カレント作業ディレクトリがリモート ホストに存在していないか、ユーザのカレン ト作業ディレクトリがリモート ホストでは別の名前にマッピングされている場合 です。 カレント作業ディレクトリがリモート ホストに存在していない場合は、そのホスト ではコマンドのリモート実行はできません。 On UNIX カレント作業ディレクトリは存在しているものの、そのディレクトリがリモート ホ ストでは別の名前にマッピングされている場合は、シンボリック リンクを作成し て、名前を同じにする必要があります。 308 Platform Clusterware 管理者 第 30 章 トラブルシューティングとエラー メッセージ automount を使用すると、この問題のほとんどを解決できます(すべての問題が 解決されるわけではありません)。オートマウント(automount)マップは、NIS を 使用して管理する必要があります。automount を実行しているにもかかわらず、LSF がリモート ホスト上のディレクトリを検出できない場合は、『Release Notes』の手 順に従ってテクニカル サポートを受けてください。 バッチ デーモンが応答しない まず、sbatchd と mbatchd のエラー ログをチェックします。さらに、次のコマ ンドで構成エラーをチェックします。 % badmin ckconfig ほとんどのエラーは、この方法で確認できます。LSF 管理者のメールボックスに電 子メールが着信していないかどうかも確認してください。mbatchd は起動してい るものの、一部のホストで sbatchd がダウンしている場合、それらのホストを使 用するように mbatchd が設定されていない可能性があります。 309 ページの「LSF で使用されないホストがある」を参照してください。 sbatchd は起動するが、mbatchd が起動しない LIM が起動しているかどうかをチェックします。LIM が起動しているかどうかは、 lsid コマンドで確認できます。LIM が正しく起動していない場合は、まず本章に 記載している手順に従って LIM を修復します。マスタ LIM を一時的に検出できな いために、mbatchd が一時的に使用できない場合があります。その場合は、次の エラー メッセージが表示されます。 sbatchd: unknown service LSF で使用されないホストがある lsb.hosts ファイルの Host セクションでサーバ ホストのリストが指定されてい る場合は、mbatchd はそれらのホストでしか sbatchd の実行を許可しません。 lsb.hosts ファイルの lsb.queues ファイル内のキュー用の HOSTS 定義で、そ れ以外のホストが指定されていると、mbatchd から次のメッセージが出力されま す。 mbatchd on host: LSB_CONFDIR/cluster/configdir/file(line #): Host hostname is not used by lsbatch; ignored mbatchd が認識していないホストで sbatchd を起動すると、mbatchd はその sbatchd を拒否します。mbatchd から拒否された sbatchd は、次のメッセージ を出力して終了します。 This host is not used by lsbatch system. 通常、これらのエラーが発生するのは、ホストを構成情報に追加した後で、次のコ マンドをこの順に実行していない場合です。 lsadmin reconfig badmin reconfig 新しいホストでデーモンを起動する前に、この 2 つのコマンドを必ず実行してくだ さい。 Platform Clusterware 管理者 309 LSF の一般的な問題 ホスト タイプやホスト モデルが UNKNOWN になっている ホスト タイプやホスト モデルが UNKNOWN かどうかの確認 lshosts コマンドを実行します。UNKNOWN と表示されるホスト タイプやホスト モデルがある場合は、該当するホストか、そのホスト上の LIM がダウンしていま す。その場合は、すみやかな対処が必要です。たとえば、次のように表示されます。 % lshosts HOST_NAME type hostA UNKNOWN model Ultra2 UNKNOWN のホス 1 ト タイプやホスト 2 モデルの修正 cpuf 20.2 ncpus 2 maxmem 256M maxswp 710M server Yes RESOURCES () 該当するホストを起動します。 lsadmin limstartup コマンドを使用して、該当するホストで LIM を起動し ます。たとえば次のようにします。 # lsadmin limstartup hostA Starting up LIM on <hostA> .... done 複数のホスト名を指定すると、複数のホストで LIM を起動できます。また、ホ スト名の指定を省略した場合は、このコマンドの投入元のホストで LIM が起動 します。 UNIX でリモート ホスト上の LIM を起動する場合は、このコマンドを実行する ユーザは、root ユーザまたは lsf.sudoers ファイルで指定されたユーザでな ければなりません。さらに、このユーザは、パスワードを入力しなくても、す べてのホストで rsh コマンドを実行できなければなりません。詳細について は、44 ページの「前提条件」を参照してください。 3 数秒後に lshosts コマンドをもう一度実行します。UNKNOWN の代わりに特 定のホスト タイプやホスト モデル(または DEFAULT という文字列)が表示さ れれば、修正は成功です。DEFAULT という文字列が表示された場合は、ホスト タイプやホスト モデルの自動検出が失敗しています。ホスト タイプやホスト モデルの自動検出が失敗すると、該当するホスト タイプやホスト モデルが DEFAULT に設定されます。LSF はこれらのホストでも機能します。ただし、ホ スト モデルが DEFAULT の場合は、CPU 係数が正しく設定されないために、処 理効率が低下する可能性があります。また、ホスト タイプが DEFAULT の場合 は、"DEFAULT" ホスト タイプのジョブが他の "DEFAULT" ホスト タイプに移さ れる可能性があるため、バイナリ コードの互換性の問題が発生することがあり ます。 ホスト タイプやホスト モデルが DEFAULT になっている ホスト タイプやホ スト モデルが DEFAULT かどうか の確認 % lshosts HOST_NAME hostA 310 type DEFAULT Platform Clusterware 管理者 lshosts コマンドを実行します。ホスト モデルとホスト タイプの自動検出機能が 有効になっているときに、DEFAULT と表示されるホスト タイプやホスト モデルが ある場合は、そのまま放置することも、修正することもできます。たとえば、次の ように表示されます。 model DEFAULT cpuf 1 ncpus 2 maxmem 256M maxswp 710M server Yes RESOURCES () 第 30 章 トラブルシューティングとエラー メッセージ ホスト モデルが DEFAULT の場合は、LSF は正しく機能しますが、該当するホスト の CPU 係数が 1 に設定されるために、そのホストを効率的に使用できない可能性 があります。 また、ホスト タイプが DEFAULT の場合は、バイナリ レベルでの互換性の問題が 発生することがあります。例として、2 台のホストがあり、そのうちの一方が Solaris マシン、もう一方が HP マシンだった場合を考えます。これらのホストのホスト タ イプが両方とも DEFAULT に設定されたとすると、実行中のジョブが Solaris ホスト から HP ホストへと(またはその逆の方向へと)移される可能性があります。 DEFAULT のホスト 1 タイプの修正 該当するホスト(ホスト タイプが DEFAULT のホスト)で lim -t コマンドを 実行します。 % lim -t Host Type Host Architecture Matched Type Matched Architecture Matched Model CPU Factor : : : : : : sun4 SUNWUltra2_200_sparcv9 DEFAULT SUNWUltra2_300_sparc Ultra2 20.2 Host Type と Host Architecture の値をメモしておきます。 2 lsf.shared ファイルを編集します。 HostType セクションに新しいホスト タイプを追加します。ここで、手順 1 で メモしておいたホスト タイプ名を使用します。たとえば、次のように指定しま す。 Begin HostType TYPENAME DEFAULT CRAYJ sun4 ... 3 4 DEFAULT のホスト 1 モデルの修正 lsf.shared ファイルの編集内容を保存します。 lsadmin reconfig コマンドを実行し、LIM を再構成します。 該当するホスト(ホスト モデルが DEFAULT のホスト)で lim -t コマンドを 実行します。 % lim -t Host Type Host Architecture Matched Type Matched Architecture Matched Model CPU Factor : : : : : : sun4 SUNWUltra2_200_sparcv9 DEFAULT SUNWUltra2_300_sparc DEFAULT 20.2 Host Architecture の値をメモしておきます。 2 lsf.shared ファイルを編集します。 HostModel セクションに新しいホスト モデルを追加し、そのアーキテクチャ 名と CPU 係数を指定します。新しいホスト モデルは、ホスト モデル リストの 末尾に追加します。このリストのエントリ数は 127 に制限されています。ただ し、ポンド記号(#)でコメント アウトした行は、この制限に含まれません。 次のように、手順 1 でメモしておいたアーキテクチャ名を使用します。 Platform Clusterware 管理者 311 LSF の一般的な問題 Begin HostModel MODELNAME CPUFACTOR Ultra2 20 End HostModel 3 4 312 Platform Clusterware 管理者 ARCHITECTURE # keyword SUNWUltra2_200_sparcv9 lsf.shared ファイルの編集内容を保存します。 lsadmin reconfig コマンドを実行し、LIM を再構成します。 第 30 章 トラブルシューティングとエラー メッセージ エラー メッセージ ここでは、LSF のデーモンによってログに記録される、または次のコマンドを実行 したときに表示されるエラー メッセージについて説明します。 lsadmin ckconfig badmin ckconfig 共通メッセージ 次のメッセージは、LSF のどのデーモンによっても生成される可能性があります。 can't open file: error e rro r で示された理由により、デーモンが指定されたファイルを開くことができま せん。通常、このエラーが発生するのは、ファイルのアクセス権が正しく設定され ていないか、ファイルが存在していない場合です。構成ファイルのパスとして指定 されているディレクトリには、LSF 管理者に対する実行(x)権が与えられていなけ ればなりません。また、実際のファイルには読み取り(r)権が与えられていなけ ればなりません。ファイルが存在していない場合は、lsf.conf ファイルで指定さ れているパス名に誤りがあるか、デーモンの実行先のホストに構成ファイルがイン ストールされていないか、シンボリック リンクで示されたファイルやディレクトリ が存在していない可能性があります。 file(line): malloc failed メモリの割り当てが失敗しました。ホストのメモリ容量やスワップ容量が不足して いるか、デーモンの内部エラーが発生しています。ホストで実行されているプログ ラムや、ホストの空きスワップ容量をチェックしてください。スワップ容量が満杯 になっている場合は、スワップ容量を増やすか、該当するホストで実行されている プログラム数を減らす(または実行されているプログラムをより軽量なものに変更 する)必要があります。 auth_user: getservbyname(ident/tcp) failed: error; ident must be registered in services lsf.conf ファイルで LSF_AUTH=ident パラメータが定義されていますが、サービ ス データベースには ident/tcp サービスが登録されていません。サービス デー タ ベ ー ス に ident/tcp サ ー ビ ス を 追 加 す る か、lsf.conf フ ァ イ ル か ら LSF_AUTH パラメータを取り除いて、認証が必要な LSF のバイナリ ファイルを setuid root してください。 auth_user: operation(<host>/<port>) failed: error lsf.conf ファイルで LSF_AUTH=ident パラメータが定義されていますが、デーモ ンがホスト上の identd デーモンに接続できません。inetd.conf ファイルで identd が定義されているかどうか、ホスト上で identd デーモンが起動している かどうかを確認してください。 auth_user: Authentication data format error (rbuf=<data>) from <host>/<port> auth_user: Authentication port mismatch (...) from <host>/<port> lsf.conf ファイルで LSF_AUTH=ident パラメータが定義されていますが、h o st で 示されたホスト上の識別デーモンと LSF との間でプロトコル エラーが発生してい ます。ホスト上の識別デーモンが正しく設定されているかどうかを確認してくださ い。 Platform Clusterware 管理者 313 エラー メッセージ userok: Request from bad port (<port_number>), denied LSF_AUTH パラメータが未定義になっていて、デーモンが非特権ポートからの要求 を受け取りました。この要求は処理されません。 LSF のバイナリ ファイルの所有者を root ユーザにして、setuid ビットをセット するか、LSF_AUTH=ident パラメータを定義して、クラスタのすべてのホストで認 証サーバを設定してください。LSF のバイナリ ファイルが NFS でマウントされた ファイル システムに配置されている場合は、そのファイル システムが nosuid フ ラグを付けてマウントされていないかどうかを確認してください。 userok: Forged username suspected from <host>/<port>: <claimed_user>/<actual_user> c la im e d _u se r で示されたユーザからのサービス要求が着信しましたが、認証機能に よって、その要求の送出元が実際には a c tu a l_u se r で示されたユーザだということ が判明しました。この要求は処理されません。 userok: ruserok(<host>,<uid>) failed lsf.conf ファイルで LSF_USE_HOSTEQUIV パラメータが定義されていますが、 h o st で示されたホストが代替ホスト(/etc/host.equiv ファイルを参照)として 設定されていません。また、u id で示されたユーザの .rhosts ファイルも設定さ れていません。 init_AcceptSock: RES service(res) not registered, exiting init_AcceptSock: res/tcp: unknown service, exiting initSock: LIM service not registered. initSock: Service lim/udp is unknown. Read LSF Guide for help init_AcceptSock: Can't bind daemon socket to port <port>: error, exiting init_ServSock: Could not bind socket to port <port>: error これらのエラー メッセージは、LSF のデーモンをもう 1 つ起動しようとしたとき (たとえば、RES が起動しているにもかかわらず、RES をもう一度起動しようとした とき)に生成されます。このような場合に新しいデーモンを起動するには、実行中 のデーモンを終了させるか、lsadmin コマンドや badmin コマンドでデーモンを シャットダウン(または再起動)する必要があります。 構成エラー 次のメッセージは、LSF の構成ファイルに問題があるときに生成されます。最初に 汎用のエラーを、その後で個々の構成ファイルに固有のエラーを記載します。 file(line): Section name expected after Begin; ignoring section file(line): Invalid section name name; ignoring section line で示された行のキーワード begin に続けてセクション名が指定されていませ ん。または認識できないセクション名が指定されています。 file(line): section section: Premature EOF section で示されたセクションの end section 行を読み取る前に、ファイルの末 尾に到達しました。 file(line): keyword line format error for section section; Ignore this section 314 Platform Clusterware 管理者 第 30 章 トラブルシューティングとエラー メッセージ セクションの最初の行には、キーワードのリストが含まれていなければなりませ ん。このエラーは、キーワード行が正しくない場合、またはキーワード行に認識で きないキーワードが含まれているときに発生します。 file(line): values do not match keys for section section; Ignoring line 構成セクションの行に含まれているフィールド数が、キーワード数と一致していま せん。デフォルト値を示す ( ) が抜けている列がある可能性があります。 file: HostModel section missing or invalid file: Resource section missing or invalid file: HostType section missing or invalid lsf.shared ファイルに HostModel セクション、Resource セクション、また は HostType セクションがありません。または、これらのセクションに修復でき ないエラーが含まれています。 file(line): Name name reserved or previously defined. Ignoring index 外部負荷インデックスに付けられた名前が、組み込みの(またはすでに定義されて いる)リソースや負荷インデックスの名前と同じです。 file(line): Duplicate clustername name in section cluster. Ignoring current line 同じ lsf.shared ファイルの中で 2 回定義されているクラスタ名があります。2 番目の定義は無視されます。 file(line): Bad cpuFactor for host model model. Ignoring line lsf.shared ファイルで指定されているホスト モデルの CPU 係数が、有効な数値 ではありません。 file(line): Too many host models, ignoring model name lsf.shared ファイルでは、最大で 127 のホスト モデルしか宣言できません。 file(line): Resource name name too long in section resource. Should be less than 40 characters. Ignoring line リソース名は 39 文字以下でなければなりません。リソース名を短くしてください。 file(line): Resource name name reserved or previously defined. Ignoring line. LSF によって予約されているリソース名、または lsf.shared ファイルですでに 定義されているリソース名が定義されています。リソース名を別のものに変更して ください。 file(line): illegal character in resource name: name, section resource. Line ignored. リソース名はアルファベット([a-zA-Z])で始まり、その後に任意の文字が続き、ア ルファベット、数字、またはアンダースコア([a-zA-Z0-9_])で終わらなければなり ません。 Platform Clusterware 管理者 315 エラー メッセージ LIM のメッセージ 次のメッセージは LIM によって記録されます。 main: LIM cannot run without licenses, exiting LSF ソフトウェアのライセンス キーが見つからないか、ライセンス キーの有効期 限が切れています。FLEXlm が正しく設定されているかどうかを確認してください。 または、LSF のテクニカル サポートにご連絡ください。 main: Received request from unlicensed host <host>/<port> LIM は、ライセンスを保有していないホストからの要求は処理しません。ライセン スの有効期限が切れているか、ライセンス キーで認められている数より多くのホス トで LSF が構成されています。 initLicense: Trying to get license for LIM from source <LSF_CONFDIR/license.dat> getLicense: Can't get software license for LIM from license file <LSF_CONFDIR/license.dat>: feature not yet available. LSF のライセンスがまだ有効になっていません。システム クロックが正しいかどう かを確認してください。 findHostbyAddr/<proc>: Host <host>/<port> is unknown by <myhostname> function: Gethostbyaddr_(<host>/<port>) failed: error main: Request from unknown host <host>/<port>: error function: Received request from non-LSF host <host>/<port> デーモンが h o st で示されたホストを認識していません。要求は処理されません。こ れらのメッセージは、h o st で示されたホストが構成ファイルに追加された後で、再 構成が行われていないデーモンがあり、これらのデーモンに新しい構成情報が読み 込まれていない場合に発生することがあります。すべてのデーモンを再構成しても 問題が解決しない場合は、該当するホストに複数のアドレスが割り当てられていな いかどうかを確認してください。 rcvLoadVector: Sender (<host>/<port>) may have different config? MasterRegister: Sender (host) may have different config? LIM が、送出元の LIM との構成情報の不整合を検出しました。次のコマンドを実行 し、すべての LIM の構成情報を同じにしてください。 % lsadmin reconfig 接続できなかったホストをメモしてください。 rcvLoadVector: Got load from client-only host <host>/<port>. Kill LIM on <host>/<port> クライアント ホストで起動している LIM があります。次のコマンドを実行するか、 該当するクライアント ホストに移動し、LIM デーモンを終了させてください。 % lsadmin limshutdown host saveIndx: Unknown index name <name> from ELIM 316 Platform Clusterware 管理者 第 30 章 トラブルシューティングとエラー メッセージ LIM が lsf.shared ファイルで定義されていない外部負荷インデックス名を受け 取りました。このインデックス名が lsf.shared ファイルで定義されている場合 は、LIM を再構成してください。定義されていない場合は、このインデックス名を lsf.shared ファイルに追加し、すべての LIM を再構成してください。 saveIndx: ELIM over-riding value of index <name> これは警告メッセージです。ELIM から、いずれかの組込みインデックス名の値が 送出されました。LIM は、カーネルから取得した値の代わりに、ELIM から渡された 値を使用します。 getusr: Protocol error numIndx not read (cc=num): error getusr: Protocol error on index number (cc=num): error ELIM と LIM との間でプロトコル エラーが発生しています。 RES のメッセージ 次のメッセージは RES によって記録されます。 doacceptconn: getpwnam(<username>@<host>/<port>) failed: error doacceptconn: User <username> has uid <uid1> on client host <host>/<port>, uid <uid2> on RES host; assume bad user authRequest: username/uid <userName>/<uid>@<host>/<port> does not exist authRequest: Submitter's name <clname>@<clhost> is different from name <lname> on this host RES は、ユーザのユーザ ID とユーザ名がすべてのホストで統一されているものと みなします。これらのメッセージは、この前提条件が成立していない場合に記録さ れます。該当するユーザが LSF を対話型リモート実行に使用することが認められて いる場合、そのユーザのアカウントに対して、すべての LSF ホストで同じユーザ ID とユーザ名が割り当てられているかどうかを確認してください。 doacceptconn: root remote execution permission denied authRequest: root job submission rejected root ユーザがジョブの実行や投入を行おうとしましたが、lsf.conf ファイルで LSF_ROOT_REX パラメータが定義されていません。 resControl: operation permission denied, uid = <uid> u id で示されたユーザ ID を持つユーザには、RES に要求を制御させる権限が与え られていません。RES に要求を制御させることができるのは、LSF 管理者か root ユーザ(lsf.conf ファイルで LSF_ROOT_REX パラメータが定義されている場合) だけです。 resControl: access(respath, X_OK): error RES が 再 起 動 要 求 を 受 け 取 り ま し た が、RES 自 身 を 再 起 動 す る た め に 必 要 な respath ファイルが見つかりません。respath ファイルに RES のバイナリ ファ イルのパスが含まれているかどうか、そのファイルに実行権が割り当てられている かどうかを確認してください。 Platform Clusterware 管理者 317 エラー メッセージ mbatchd と sbatchd のメッセージ 次のメッセージは mbatchd デーモンや sbatchd デーモンによって記録されます。 renewJob: Job <jobId>: rename(<from>,<to>) failed: error mbatchd が再実行可能なジョブの再投入に失敗しました。fro m で示されたファイ ルが存在しているかどうか、LSF 管理者にそのファイルの名前を変更する権限が与 えられているかどうかを確認してください。fro m で示されたファイルが AFS ディ レクトリに含まれている場合は、LSF 管理者のトークン処理が正しく設定されてい るかどうかを確認してください。 AFS へのインストールについては、Platform LSF パッケージ内にある「Installing LSF on AFS」という文書を参照してください。 logJobInfo_: fopen(<logdir/info/jobfile>) failed: error logJobInfo_: write <logdir/info/jobfile> <data> failed: error logJobInfo_: seek <logdir/info/jobfile> failed: error logJobInfo_: write <logdir/info/jobfile> xdrpos <pos> failed: error logJobInfo_: write <logdir/info/jobfile> xdr buf len <len> failed: error logJobInfo_: close(<logdir/info/jobfile>) failed: error rmLogJobInfo: Job <jobId>: can't unlink(<logdir/info/jobfile>): error rmLogJobInfo_: Job <jobId>: can't stat(<logdir/info/jobfile>): error readLogJobInfo: Job <jobId> can't open(<logdir/info/jobfile>): error start_job: Job <jobId>: readLogJobInfo failed: error readLogJobInfo: Job <jobId>: can't read(<logdir/info/jobfile>) size size: error initLog: mkdir(<logdir/info>) failed: error <fname>: fopen(<logdir/file>) failed: error getElogLock: Can't open existing lock file <logdir/file>: error getElogLock: Error in opening lock file <logdir/file>: error releaseElogLock: unlink(<logdir/lockfile>) failed: error touchElogLock: Failed to open lock file <logdir/file>: error touchElogLock: close <logdir/file> failed: error e rro r で示された理由により、mbatchd が、ログ ディレクトリまたはログ ディレ クトリに含まれているファイルの作成、削除、読み取り、書き込みのいずれかの処 理に失敗しました。LSF 管理者に、logdir で示されたディレクトリに対する読み 取り権、書き込み権、実行権が与えられているかどうかを確認してください。 replay_newjob: File <logfile> at line <line>: Queue <queue> not found, saving to queue <lost_and_found> 318 Platform Clusterware 管理者 第 30 章 トラブルシューティングとエラー メッセージ replay_switchjob: File <logfile> at line <line>: Destination queue <queue> not found, switching to queue <lost_and_found> mbatchd が再構成されたときに、qu e u e で示されたキューにジョブが含まれてい ましたが、再構成によってそのキューが削除されました。 replay_startjob: JobId <jobId>: exec host <host> not found, saving to host <lost_and_found> mbatchd が再構成されたときに、ホストにディスパッチされたジョブがイベント ログに記録されていましたが、再構成によってそのホストが LSF が使用するホスト から取り除かれました。 do_restartReq: Failed to get hData of host <host_name>/<host_addr> mbatchd が h o st_n a m e で示されたホスト上の sbatchd から要求を受け取りまし たが、そのホストは mbatchd から認識されていません。構成ファイルの変更後に mbatchd の再構成が行われていないため、新しい構成情報が読み込まれていない か、または h o st_n a m e で示されたホストがクライアント ホストにもかかわらず、そ のホストで sbatchd デーモンが実行されている可能性があります。次のコマンド を実行して mbatchd を再構成するか、h o st_n a m e で示されたホスト上の sbatchd デーモンを終了させてください。 % badmin reconfig Platform Clusterware 管理者 319 エラー メッセージ 320 Platform Clusterware 管理者 索引 記号 $HOME/.lsbatch ディレクトリ 36 $HOME/.rhosts ファイル 欠点 291 認証 291 .lsbatch ディレクトリ 36 .rhosts ファイル 欠点 291 トラブルシューティング 308 認証 291 /etc/hosts.equiv ファイル トラブルシューティング 308 認証 291 /etc/hosts ファイル トラブルシューティング 308 ホストのエントリの例 70 ホスト名の検出 68 ホスト名の指定 68 /etc/hosts ファイルのエントリの実例 70 /etc/hosts ファイルを使用したホスト名の検出 /etc/services ファイル LSF エントリを~へ追加する 65 /etc/syslog.conf ファイル 303 /tmp_mnt ディレクトリ 306 /tmp ディレクトリ デフォルト LSF_LOGDIR 303 /usr/include/sys/syslog.h ファイル 303 ホスト名の指定 68 bhist command LSF event logs 304 bhosts コマンド 使用する 54 BIND(Berkeley Internet Name Domain) ホスト名の指定 68 bmod -is 299 bmod -Zs 299 Boolean リソース 100 brun コマンド ジョブを強制的に実行する bsub -is 297 bsub -Zs 298 68 A AFS(Andrew File System)トークン , esub と eexec 230 augmentstarter ジョブ スタータ 228 authd デーモン 288 automount コマンド NFS(Network File System) 306 B badmin コマンド hopen 58 hrestart 44 hshutdown 44 hstartup 44 LSF event logs 304 mbdrestart 44, 49 qact 79 qclose 79 qinact 79 qopen 79 setuid 権限 289 Batch ログ ファイル →「ログ ファイル」を参照 Berkeley Internet Name Domain(BIND) 90 bsub コマンド 電子メールによるジョブ通知 294 入出力 294 busy しきい値 , チューニング 282 busy ホスト状態 lsload コマンド 53 status 負荷インデックス 105 C closed_Adm 状態 , bhosts -l の出力 52 closed_Busy 状態 , bhosts -l の出力 52 closed_Full 状態 , bhosts -l の出力 52 closed_LIM 状態 , bhosts -l の出力 52 closed_Lock 状態 , bhosts -l の出力 52 closed_Wind 状態 , bhosts -l の出力 52 closed ホスト状態 bhosts コマンド 52, 54 CPU CPU 使用率(ut)負荷インデックス 106, 255 lsf.shared ファイルでの調整 72 係数 係数 72 時間の正規化 207 静的リソース 109 時間制限 ジョブ レベルのリソース制限 202 実行キュー長 , 説明 254 実行キュー長を参照する 72 正規化 207 制限 ジョブごと 202 プロセスごと 202 CPU 係数(cpuf)静的リソース 109 CPU 係数の設定のためのベンチマーク 72 Platform Clusterware 管理者 321 索引 D DCE/DFS(Distributed File System) 資格認定 , esub と eexec 230 DEFAULT lshosts コマンドでモデルやホスト DISPATCH_WINDOW キュー 80 Domain Name Service(DNS) ホスト名の指定 68 done ジョブ依存条件 151 DONE ジョブの状態 実行後コマンド 219 説明 84 310 E eauth lsf.sudoers の LSF_EAUTH_KEY パラメータ 286 lsf.sudoers の LSF_EAUTH_USER パラメータ 287 実行可能場所(LSF_SERVERDIR) 288 説明 286 標準入出力 287 eauth への client_addr 引数 287 eauth への client_port 引数 287 eauth への gid 引数 287 eauth への uid 引数 287 eauth への user_auth_data_len 引数 287 eauth への user_auth_data 引数 287 eauth への username 引数 287 ELIM(外部 LIM) カスタム リソース 119 デバッグする 123 ended ジョブ依存条件 151 erestart プログラム アプリケーション レベルのチェックポイント機能 170 esub 230 esub(外部投入)実行可能プログラム 環境変数 231 説明 231 必須メソッド(LSB_ESUB_METHOD) 235 esub スクリプト 説明 230 非 root として実行する 237 esub メソッド(LSB_ESUB_METHOD) 235 example.services ファイル 65 exit ジョブ依存条件 151 EXIT ジョブ状態 実行前コマンドと実行後コマンド 219 ジョブの異常終了 86 G gethostbyname 関数(ホスト名の検出) 68 H hname 静的リソース 109 hopen badmin コマンド 58 HOSTRESORDER 環境変数 hosts.equiv ファイル 認証 291 hosts ファイル 設定する 69 322 Platform Clusterware 管理者 308 ホストのエントリの例 70 ホスト名の指定 68 hrestart badmin コマンド 44 hshutdown badmin コマンド 44 hstartup badmin コマンド 44 I Internet Domain Name Service(DNS) ホスト名の指定 68 io 負荷インデックス 107 it 負荷インデックス 106 ジョブの自動中断 211 説明 254 中断条件 212 K Kerberos 認証 286 L lim.log.host_name ファイル 303 LIM(Load Information Manager) チューニング 実行時間帯 281 負荷インデックス 282 負荷しきい値 282 ポリシー 281 負荷情報をログ ファイルに記録する 123 待ち時間を設定する 123 lockU および lockW ホスト状態 status 負荷インデックス 106 lockU ホスト状態 lsload コマンド 53 lockW ホスト状態 lsload コマンド 53 status 負荷インデックス 105 LOG_DAEMON 機能 , LSF エラー ログ出力 303 lost_and_found キュー 81 ls_connect API コール 230 LS_EXEC_T 環境変数 240 LS_JOBPID 環境変数 237 lsadmin コマンド limunlock 58 setuid 権限 289 lsb.events ファイル イベント ログを管理する 304 lsb.params の JOB_SPOOL_DIR パラメータ 297 lsb.params ファイル JOB_ACCEPT_INTERVAL パラメータ 32 JOB_SCHEDULING_INTERVAL パラメータ 32 lsb.events ファイルのリライトを制御する 304 ジョブ入力ファイルの指定 297 lsb.params ファイル内の JOB_ACCEPT_INTERVAL パラメー タ 32 lsb.params ファイル内の JOB_SCHEDULING_INTERVAL パ ラメータ 32 lsb.params ファイル内の JOB_TERMINATE_INTERVAL パラ メータ 241 lsb.params ファイル内の MAX_JOB_NUM パラメータ 304 lsb.queues の CHKPNT パラメータ 175 lsb.queues の JOB_CONTROLS パラメータ 242 索引 lsb.queues の JOB_STARTER パラメータ 226 lsb.queues の QUEUE_NAME パラメータ 81 lsb.queues の RESUME_COND パラメータ 241 lsb.queues の STOP_COND パラメータ 240 lsb.queues の TERMINATE_WHEN パラメータ TERMINATE ジョブ制御アクション 241 デフォルトの SUSPEND アクションを変更する 244 lsb.queues ファイル キューを追加する 81 LSB_ECHKPNT_KEEP_OUTPUT 環境変数 172 LSB_ECHKPNT_METHOD_DIR 環境変数 170 LSB_ECHKPNT_METHOD 環境変数 172 LSB_HOSTS 環境変数 272 LSB_JOBEXIT_STAT 環境変数 220 LSB_JOBINDEX 環境変数 186 LSB_JOBPEND 環境変数 220 LSB_JOBPGIDS 環境変数 243 LSB_JOBPIDS 環境変数 243 LSB_MAILSIZE 環境変数 295 LSB_SHAREDIR/cluster_name/logdir LSF ログ ファイル 302 LSB_SUB_ABORT_VALUE 環境変数 233 LSB_SUB_PARM_FILE 環境変数 231 LSB_SUSP_REASON 環境変数 243 lsf.cluster.cluster_name の ResourceMap セクション 117 lsf.cluster.cluster_name ファイル クラスタ管理者を設定する 43 lsf.cluster.cluster_name ファイルの ADMINISTRATORS パラ メータ 43 lsf.conf 中の LSB_SBD_PORT パラメータ 65 lsf.conf の LSB_ECHKPNT_KEEP_OUTPUT 172 lsf.conf の LSB_ECHKPNT_METHOD 172 lsf.conf の LSB_ECHKPNT_METHOD_DIR 170 lsf.conf の LSB_ESUB_METHOD 235 lsf.conf の LSB_MAILSIZE_LIMIT パラメータ 295 lsf.conf の LSB_MAILTO パラメータ 294 lsf.conf の LSB_MBD_PORT パラメータ 65 lsf.conf の LSF_AUTH_DAEMONS パラメータ 292 lsf.conf の LSF_AUTH パラメータ 288 lsf.conf の LSF_LIM_PORT パラメータ 65 lsf.conf の LSF_LOG_MASK パラメータ 303 lsf.conf の LSF_LOGDIR パラメータ 303 lsf.conf の LSF_USE_HOSTEQUIV パラメータ 291 lsf.conf ファイル TCP サービス ポートを設定する 65 エラー ログを管理する 303 ジョブ提出者に電子メールを送信する 294 ジョブ電子メールのサイズ制限 295 デーモン認証の設定 292 デーモンのサービス ポート 65 認証 291 リモート実行 288 lsf.conf ファイルの LSB_SIGSTOP パラメータ 244 lsf.conf ファイルの LSF_RES_PORT パラメータ 65 lsf.conf ファイルの LSF_RSH パラメータ デーモンを制御する 44 lsf.shared ファイル CPU 係数を調整する 72 独自のホスト タイプとホスト モデルを追加する 64 lsf.sudoers の LSF_EAUTH_KEY パラメータ 286 lsf.sudoers の LSF_EAUTH_USER パラメータ 287 lsf.sudoers ファイル 外部認証(eauth) 286, 287 LSF_EAUTH_AUX_DATA 環境変数 286 LSF_EAUTH_CLIENT 環境変数 292 LSF_EAUTH_SERVER 環境変数 292 LSF_SERVERDIR ディレクトリ 実行可能 eauth 288 LSF デーモン エラー ログ 303 LSF のバージョン 表示する 42 lshosts コマンド DEFAULT のホスト モデルやホスト タイプ 310 lsinfo 負荷インデックスを表示する 253 LSLIB(負荷共有ライブラリ) 特権ポート認証を初期化する 288 lsload 負荷インデックスを表示する 253 M maxmem 静的リソース 109 maxswp 静的リソース 109 maxtmp 静的リソース 109 mbatchd.log.host_name ファイル 303 mbatchd(マスタ バッチ デーモン) 再起動 47 シャットダウンする 47 mbdrestart badmin コマンド 44 mbschd.log.host_name ファイル 303 mem 負荷インデックス 107 mesub(マスタ esub) 設定する 236 説明 235 model 静的リソース 109 N ncpus 静的リソース LIM が報告する~ 109 プロセッサの動的な変更 110 ndisks 静的リソース 109 NFS(Network File System) automount コマンド 306 nosuid オプション 290 NIS(ネットワーク情報サービス) LSF でのホスト名の検出 68 ypcat hosts.byname 68 ポート番号を構成する 66 nosuid オプション , NFS マウント 290 numdone 依存条件 187 numended 依存条件 187 numexit 依存条件 187 numhold 依存条件 187 numpend 依存条件 187 numrun 依存条件 187 numstart 依存条件 187 Platform Clusterware 管理者 323 索引 O -ok ホスト状態 lsload コマンド 53 status 負荷インデックス ok ホスト状態 bhosts コマンド 52 lsload コマンド 53 status 負荷インデックス order 文字列 142 OS メモリ制限 204 105 105 P PATH 環境変数 共有ユーザ ディレクトリ 37 PEND ジョブの状態 84 pg 負荷インデックス 中断条件 212 pidentd デーモン 288 pim.log.host_name ファイル 303 PIM(プロセス情報マネージャ) リソースの使用 104 POST_DONE 実行後のジョブの状態 86, 219 post_done ジョブ依存条件 152, 219 POST_ERR 実行後のジョブの状態 86, 219 post_err ジョブ依存条件 152, 219 preservestarter ジョブ スタータ 228 PSUSP ジョブの状態 概要 84 説明 91 pub/ident/server 288 Q qact badmin コマンド 79 qclose badmin コマンド 79 qinact badmin コマンド 79 qopen badmin コマンド 79 R r15m 負荷インデックス 組込みリソース 106 説明 254 中断条件 212 r15s 負荷インデックス 組込みリソース 106 説明 254 中断条件 212 r1m 負荷インデックス 組込みリソース 106 説明 254 中断条件 212 res.log.host_name ファイル 303 resolv.conf ファイル 68 resolver 関数 68 RESUME ジョブ制御アクション 241 rexpri 静的リソース 109 RFC 1413 と RFC 931 プロトコル 識別デーモン認証 288 rlogin コマンド 324 Platform Clusterware 管理者 対話型端末 254 特権ポート認証 288 -R res_req コマンドの引数 138 rsh コマンド lsfrestart 44 特権ポート認証 288 RUN_WINDOW キュー 80 RUN ジョブの状態 概要 84 ruserok ファンクション 認証で使用する /etc/hosts.equiv 291 S sbatchd.log.host_name ファイル 303 sbatchd(スレーブ バッチ デーモン) 再起動 46 シャットダウンする 46 select 文字列 140 server 静的リソース 109 setuid 許可 badmin コマンド 289 lsadmin 289 特権ポート認証 288 認証 288 setuid 権限 308 SIGCONT シグナル ジョブ制御 93 デフォルトの RESUME アクション 241 SIGINT シグナル ジョブ制御アクション 93 SIGKILL シグナル ジョブ制御 93 ジョブにシグナルを送出する 93 デフォルトの TERMINATE アクション 241 SIGQUIT シグナル デフォルトの TERMINATE アクション 241 SIGSTOP シグナル bstop 91 ジョブ制御 93 設定する 91, 240, 244 デフォルトの SUSPEND アクション 240 SIGTERM シグナル ジョブ制御アクション 93 デフォルトの TERMINATE アクション 241 SIGTSTP シグナル デフォルトの SUSPEND アクション 240 SSUSP ジョブの状態 概要 84 説明 91 started ジョブ依存条件 153 stderr と stdout 対話型ジョブの~を分割する 250 ファイルにリダイレクトする 264 stdin と stdout esub と eexec の間でデータを渡す 237 Sun の NID(Network Information Service)または YP (Yellow Pages)→「NIS」を参照 SUSPEND ジョブ制御アクション 索引 lsb.events の LSF バッチ ログ ファイル 304 インターネット アドレス ホスト名と対応する 68 インタフェース , ネットワーク 69 デフォルト 240 svc.conf ファイル(ネーム サービス) 68 syslog.h ファイル 303 T TCP サービスのポート番号 LSF へ登録する 65 NIS または NIS+ データベース用に構成する TERMINATE ジョブ制御アクション 241 tmp 負荷インデックス 説明 107 tmp 負荷インデックス 中断条件 212 type 静的リソース 109 え 66 U か UDP サービスのポート番号 LSF へ登録する 65 unavail ホスト状態 bhosts コマンド 52 lsload コマンド 53 status 負荷インデックス status 負荷インデックス 106 unlicensed ホスト状態 bhosts コマンド 52 lsload コマンド 53 status 負荷インデックス 106 unreach ホスト状態 bhosts コマンド 52 USUSP ジョブの状態 概要 84 ジョブを中断 / 再開する 91 説明 91 外部 ジョブ投入実行可能プログラム(esub) 231 負荷インデックス , ELIM を使用する 119 外部認証(eauth) 説明 286 標準入出力 287 カスタム リソース 設定する 116 説明 114 追加 116 リソースの種類 100 仮想メモリ 中断条件 212 負荷インデックス 107 空きメモリ 107 環境変数 → 各環境変数名を参照 管理者 キュー管理者を表示する 44 クラスタ管理者の説明 43 プライマリ LSF 管理者 43 V vmstat コマンド 107 X xterm LSF Base で実行する き 266 Y ypbind デーモン 68 ypcat hosts.byname 68 ypmake コマンド エラー 構成~を参照する 49 エラー ログ LSF_LOG_MASK パラメータ 303 LSF デーモン 303 UNIX と Windows NT 303 ログ ディレクトリ LSF_LOGDIR 303 ログ ファイル 303 ログ ファイルを管理する 303 66 あ アイドル時間 組込み負荷インデックス 106 説明 254 中断条件 212 アプリケーション レベルのチェックポイント機能 い 移行 →「ジョブの移行」を参照 依存条件 →「ジョブの依存性の条件」を参照 一時領域 中断条件 212 イベント ログ 169 疑似端末 ~を使用したタスクの実行 261 ~を使用して対話型ジョブを投入する 250 キュー lost_and_found 81 REQUEUE_EXIT_VALUES パラメータ 220 概要 30 管理者を参照する 42 キュー管理者を表示する 44 キュー選択 31 キュー内のジョブの順序変更 88 再実行レベルを設定する 165 実行時間帯 80 自動選択 31 ジョブの移行 180 ジョブのキューへの再登録 161 ジョブの再実行 165 設定する ジョブ制御 242 中断条件 213 対話型 248 Platform Clusterware 管理者 325 索引 チェックポイント 178 中断条件を設定する 213 追加と削除 81 ディスパッチ時間帯 80 デフォルト 31 表示する キューの詳細情報 78 使用可能な 77 状態 77 対話型ジョブ 249 履歴 78 キュー間の優先順位 210 キュー管理者 表示する 44 キューしきい値 表示する 34 キューのディスパッチ時間帯 148 キューの優先度 31 キュー末尾への再登録 162 キュー レベル 移行しきい値 設定する 180 実行制限 201 実行前コマンドと実行後コマンド 設定する 220 説明 219 ジョブ スタータ 226 ジョブをチェックポイント機能に対応させる 175 定期的チェックポイント機能を有効にする 178 リソース制限 200 リソースの要件 135 キュー レベル リソース制限 , デフォルト 200 共有ファイル 306 共有ユーザ ディレクトリ 36 共有リソース 説明 102 表示する 103 許可 setuid badmin コマンド 289 lsadmin コマンド 289 ユーザの認証 291 ログ ディレクトリ 302 く 組込み~ 負荷インデックス 上書きする 124 リソース 100 クラスタ 構成ファイルのクイック リファレンス 再設定する コマンド 48 情報を表示する 42 表示する ~についての情報 42 クラスタ管理者 説明 43 表示する 42 クラスタ名 表示する 42 326 Platform Clusterware 管理者 48 こ コア ファイル サイズ制限 202 公式ホスト名 68 構成情報 チューニング busy しきい値 282 LIM ポリシー 281 実行時間帯 281 負荷インデックス 282 負荷しきい値 282 追加と削除 キュー 81 表示する エラー 49 構成ファイル 再構成のクイック リファレンス 48 高度な依存条件 153 コマンド 実行後 →「実行後コマンド」を参照 実行前 →「実行前コマンド」を参照 ジョブ スタータ 224 ジョブ制御アクションで使用する 243 ユーザ ID を指定して実行する 221 コマンド ファイル スプール lsb.params の JOB_SPOOL_DIR パラメータ 297 説明 297 デフォルト ディレクトリ 298 「ジョブ ファイル スプール」を参照 さ サーバ状態 closed 54 サーバ ホスト , 詳細情報を参照する サービス データベース例 65 サービス ポート(TCP と UDP) 登録する 65 再開しきい値 表示する 215 最大の 実行制限 200 リソース使用制限 200 再登録されたジョブ 160 54 し シェル 対話型ジョブのデフォルト シェル 258 対話型ジョブの~を指定する 257 シェル モード , 有効にする 263 時間帯 構文 131 時間の正規化 CPU 係数 207 しきい値 34 LIM のチューニング 282 スケジューリングと中断 214 ホストとキュー 34 識別デーモン(identd)認証 288 シグナル SIGINT 93 SIGSTOP を設定する 91, 240, 244 SIGTERM 93 索引 ジョブ アクションのデッドロックを回避する ジョブに~を送出する 93 時刻 指定する 130 実行 環境 36 ジョブの強制 90 優先順位 109 実行キュー 実効 106 正規化 106 中断条件 212 実行キューの実効長 LIM のチューニング 284 組込みリソース 106 説明 254 実行後 ジョブの依存性の条件 219 ジョブの状態 219 実行後コマンド 概要 218 キュー レベル 219 設定する 220 ユーザ ID を指定して実行する 221 実行時間 正規化 207 実行時間帯 LIM のチューニング 281 キュー 80 説明 147 実行時間の上限 200 実行制限 最大の 200 指定する 206 上限の 200 設定する 198, 204 実行中のジョブ , 参照する 84 実行前コマンド 概要 218 キュー レベル 219 ジョブ レベル 219 設定する 220 ユーザ ID を指定して実行する 221 終了したジョブ , 参照する 84 出力ファイルのスプール デフォルト ディレクトリ 298 使用制限 →「リソース使用制限」を参照 状態 bhosts 52 bhosts 中の closed 54 ジョブ配列 188, 191 表示する キュー 77 ホスト 54 負荷インデックス 105 ジョブ CHKPNT 242 移行したジョブを再登録する 180 キューに再登録する 191 キューへの再登録 , 説明 164 キュー レベルで中断する 213 244 キューを切り替える 89 強制終了 92 コマンドおよびジョブ ファイルをスプールする 257 再開 91 再開する 214 再起動 165 自動 165 再実行を有効にする 165 実行順の変更 88 実行の強制 90 自動的に移行する 180 自動的に再実行する 165 手動で移行する 179 対話型~のオプションを指定する 256 対話型~のシェルを指定する 257 対話型 →「対話型ジョブ」を参照 チェックポイント 手動による設定 176 前提条件 173 チェックポイント対応 175 中断 91, 214 中断する 210 定期的チェックポイント機能を有効にする 177 ディスパッチ オーダ 33 電子メールの通知 オプション 294 無効にする 295 入力、出力、コマンド ファイルをスプールする 297 表示する キュー内の順番 33 ユーザごと 87 保留中 85 メモリ使用制限を適用する 203 優先権 210 ~に特定のシグナルを送出する 93 ジョブ スクリプト 対話型ジョブの~を記述する 256 ジョブ スタータ augmentstarter 228 preservestarter 228 キュー レベル 設定する 226 説明 224 コマンドまたはスクリプトを指定する 226 コマンド レベル 224 ユーザ コマンド 226 ジョブ スタータの %USRCMD 文字列 226 ジョブ スロット制限 ジョブ配列 192 並列ジョブ用 276 ジョブ制御 CHKPNT 242 LS_EXEC_T 240 RESUME 241 SUSPEND 240 TERMINATE 241 TERMINATE アクションのシグナル間隔を無効にす る 241 コマンドを使用する 243 終了する 244 設定する 242 デフォルトのアクション 240 Platform Clusterware 管理者 327 索引 ジョブの移行 概要 179 キュー 180 ジョブを再登録する 180 チェックポイント 168 チェックポイント可能なジョブ 179 ジョブの異常終了 86 ジョブの依存性の条件 done 151 ended 151 exit 151 post_done 152, 219 post_err 152, 219 started 153 高度な~ 153 後処理 219 指定する 150 ジョブ ID を指定する 152 ジョブ配列 187 ジョブ名 152 スケジューリング 150 説明 151 例 153 ジョブの開始と終了 →「バッチ ジョブ」 、「実行前コマンド」 を参照 ジョブの環境 36 ジョブのキューへの再登録 キュー 161 キュー末尾への再登録 162 排他~ 163 ユーザ指定 164 ジョブのキューへのユーザ指定再登録 164 ジョブの再登録 , 説明 160 ジョブの実行環境 36 ジョブの実行順の変更 88 ジョブの実行を強制 90 ジョブの状態 DONE 実行後コマンド 219 説明 84 EXIT 実行前コマンドと実行後コマンド 219 ジョブの異常終了 86 PEND 84 POST_DONE 86, 219 POST_ERR 86, 219 PSUSP 84 RUN 84 SSUSP 84 USUSP 84 実行後 219 説明 84 ジョブの電子メール bsub オプション 294 LSB_MAILSIZE_LIMIT によってサイズを制限する 295 バッチ ジョブ無効化の通知 295 ジョブの投入 30 ジョブ配列 %I 置換文字列 185 %J 置換文字列 185 依存条件 187 328 Platform Clusterware 管理者 インデックス リスト 182 概要 181 監視する 188, 191 キューに再登録する 191 構文 182 最大サイズ 183 作成する 182 状態 188, 191 ジョブ スロット制限を指定する 192 制御する 190 投入する 182 入出力のリダイレクト 184 入出力ファイル 184 引数の受け渡し 186 引数を渡す 186 標準入出力 185 ファイルの準備 184 フォーマット 182 履歴 188, 191 ジョブ配列内の %I 置換文字列 185 ジョブ配列内の %J 置換文字列 185 ジョブ配列のインデックス リスト 182 ジョブ ファイル 31 ジョブ ファイル スプール lsb.params の JOB_SPOOL_DIR パラメータ 297 説明 297 デフォルト ディレクトリ 298 「コマンド ファイル スプール」を参照 297 ジョブ レベル 実行制限 204 実行前コマンド 設定する 220 説明 219 チェックポイント 176 リソースの要件 137 ジョブ レベルの中断条件 表示する 214 す 数値リソース 100 スクリプト 対話型ジョブのために標準入力に転送する 257 対話型ジョブの~を記述する 256 スケジューリング しきい値 キュー レベルのリソース要件 135 ホストの選択 34 スタック セグメント サイズ制限 205 ストリング リソース 100 スプール →「コマンド ファイルのスプール」、「ジョブ ファ イルのスプール」を参照 スワップ スペース 中断条件 212 負荷インデックス 107 スワップ領域 説明 107 中断条件 212 せ 正規化 CPU 時間制限 207 索引 実行時間制限 207 ホスト 207 正規化実行キュー長 LIM のチューニング 284 説明 106 制限 ハード 200 リモート接続数 288 静的リソース 各リソース名も参照 説明 109 制約 リモート接続数 288 セキュリティ LSF 認証 289 リモート実行 288 先着順(FCFS)スケジューリング 中断されたジョブの状態 85 中断しきい値 214 中断条件 表示する 214 中断条件 , 設定する 213 中断中のジョブ 再開する 214 中断理由 表示する 214 中断理由 , 参照する 85 て 32 た 対話型ジョブ sdtout と stderr を分離する 250 受け付けるキューを設定する 248 埋込み投入オプションの指定 257 疑似端末を使用して投入する 250 キューを表示する 249 シェルを指定する 257 ジョブ コマンド ファイルをスプールする 257 ジョブ スクリプトを記述する 256 ジョブ ファイルを 1 行ずつ記述する 256 スケジューリング ポリシー 248 投入する 249 標準入力にスクリプトを転送する 257 ファイルへのジョブ オプションの指定 256 ~を投入し , ストリームをファイルに転送する 250 対話型ジョブの埋込み投入オプション 257 対話型セッション 起動する 265 対話型タスク LSF Base で実行する 262 ファイル アクセス 263 対話型タスクにアクセスを許可する 263 タスク LSF Base で実行する 262 ファイル アクセス 263 ファイルで指定したホストでタスクを実行する 261 複数のホストで同一タスクを順次実行する 261 並列~を起動する 275 ~を実行するためのホストを選択する 260 ち チェックポイント 174 チェックポイント可能なジョブ 説明 175 チェックポイント機能 アプリケーション レベル 169 概要 168 カスタム プログラムを作成する キュー 178 定期的 177 フォールト トレランス 168 負荷分散 168 170 定期的タスク 303 定期的チェックポイント機能を有効にする キュー レベル 178 ジョブ レベル 177 説明 177 無効にする 177 ディスク数 I/O 率 107 ディスパッチ期間 説明 32 ディスパッチ時間帯 LIM のチューニング 281 キュー 80 説明 148 ホスト 58 ディレクトリ .lsbatch 36 LSF_SERVERDIR 実行可能 eauth 288 LSF_SERVERDIR, esub と eexec 231 共有 36 ディレクトリ 174 ユーザ アカウント 36 リモート アクセス 230 ログ アクセス権と所有者 302 データ セグメント サイズ制限 203 デーモン authd 288 pidentd 288 TCP サービス ポート 65 ypbind 68 エラー ログ 303 コマンド 44 再起動 mbatchd 47 sbatchd 46 シャットダウンする mbatchd 47 sbatchd 46 認証 292 適格ホスト 34 デッドロック , シグナルとジョブ アクションで回避する デフォルト JOB_SPOOL_DIR 298 LSF_LOGDIR 303 LSF ログ ファイルの場所 302 出力ファイルのスプール 298 ジョブ制御 240 244 Platform Clusterware 管理者 329 索引 ホスト名の指定 68 /etc/lsf.sudoers ファイル 287 /etc/services ファイル LSF エントリを~へ追加する /usr/bin/ 37 入力ファイルのスプール 298 リソース使用制限 200 電子的なメール →「電子メール」を参照 電子メール ジョブ オプション 294 ジョブ電子メールのサイズ制限 295 バッチ ジョブ無効化の通知 295 と 動的 リソース 100 投入オプション 対話型ジョブの埋込み~ 257 投入実行可能プログラム(esub) 231 特権ポート認証(setuid) 制限 288 説明 288 特権ポート認証の LSLIB(負荷共有ライブラリ)を初期化す る 288 に 入出力ファイル sdtout と stderr を分離する 250 ジョブ配列 184 対話型ジョブ 250 ディレクトリのスプール 298 入出力ファイル , ジョブ配列 185 認証 DCE クライアントが GSSAPI を使用する 286 Kerberos 286 lsf.conf の LSF_AUTH パラメータ 288 lsf.conf の LSF_USE_HOSTEQUIV パラメータ 291 lsf.sudoers の LSF_EAUTH_KEY パラメータ 286 lsf.sudoers の LSF_EAUTH_USER パラメータ 287 RFC 1413 と RFC 931 288 外部認証(eauth) 286 概要 285 識別デーモン(identd) 288 セキュリティ 289 デーモン間 292 特権ポート(setuid) 288 認証環境 286 ね ネットワーク インタフェース 69 ポート番号 NIS または NIS+ データベース用に構成する ネットワーク情報サービス →「NIS」を参照 は ハードのリソース使用制限 例 200 排他ジョブ キューへの再登録 163 パス /etc/hosts.equiv ファイル 291 認証 291 /etc/hosts ファイル ホストのエントリの例 70 ホスト名の検出 68 330 Platform Clusterware 管理者 バッチ キュー →「キュー」を参照 バッチ ジョブ キューへの再登録 160 強制終了 92 再実行と再起動 165 シグナル 92 実行前コマンドと実行後コマンド ジョブについての電子メール オプション 294 無効にする 295 入出力 294 ファイル アクセス 230 プロセッサを割り当てる 274 パフォーマンス チューニング busy しきい値 282 LIM の実行ウィンドウ 281 LIM ポリシー 281 負荷インデックス 282 負荷しきい値 282 範囲 時間 131 実行 147 ディスパッチ 148 65 218 ひ 引数 ジョブ配列に渡す 186 必須 esub メソッド(LSB_ESUB_METHOD) 235 表示する 構成エラー 49 ホストの状態 54 標準出力とエラー ファイルにリダイレクトする 264 標準出力と標準入力 esub と eexec の間でデータを渡す 237 標準入出力 for eauth 287 ジョブ配列 185 標準入力とエラー 対話型ジョブの~を分割する 250 ふ 66 ファイル /etc/hosts ホストのエントリの例 70 ホスト名の検出 68 ホスト名の指定 68 /etc/services LSF エントリを~へ追加する 65 lsb.params JOB_ACCEPT_INTERVAL パラメータ 32 JOB_SCHEDULING_INTERVAL パラメータ 32 lsf.conf TCP サービス ポートを設定する 65 デーモンのサービス ポート 65 lsf.shared 独自のホスト タイプまたはホスト モデルを追加す 索引 る 64 resolv.conf 68 stdout と stderrr をリダイレクトする 264 svc.conf(ネーム サービス) 68 コマンドおよびジョブ ファイルをスプールする 257 転送する 250 ホスト 設定する 69 ホスト間で~をコピーする 263 ファイル サイズ使用制限 203 ファイル スプール →「コマンド ファイルのスプール」 、 「ジョブ ファイルのスプール」を参照 297 ファイルにアクセス 263 ファイルの共有 36 ファイルの準備 , ジョブ配列 184 フォールト トレランス ジョブのチェックポイント 168 負荷インデックス io 107 it 106 LIM のチューニング 282 mem 107 pg 106 r15m 106 r15s 106 r1m 106 swp 107 tmp 107 ut 106 組込みリソース 106 組込み~ 上書きする 124 概要 105 説明 255 表示する 42, 108 分類 252 ⇒「リソース」を参照 負荷しきい値 LIM のチューニング 282 キュー レベル 212 設定する 212 説明 135 チューニング 282 ページング レート 283 負荷分散 168 負荷レベル クラスタに関して参照する 42 ホストに関して参照する 55 リソースごとに参照する 99 複数 esub 235 へ 平均負荷 106 並列ジョブ 概要 271 ジョブ スロット制限 276 投入する 274 プロセッサを割り当てる 274 並列タスク lsgrun で実行する 261 起動する 275 並列プログラミング パッケージ 273 ページング率 ジョブの自動中断 211 説明 106, 253 チェックする 212 中断条件 212 負荷インデックス 106 別名 ホスト名として使用 68 別名 , リソース名 140 変数 → 各環境変数名を参照 295 ほ ポート デーモンのサービス~を登録する 65 特権 setuid 認証 288 番号 NIS または NIS+ データベース用に構成する ホーム ディレクトリ 共有 36 ホスト 開放する 58 公式名 68 最小負荷ホストへログオンする 265 制御する 58 タスク用に選択する 260 ディスパッチ時間帯 58 表示する 54 アーキテクチャ情報 55 共有リソース 103 詳細情報 54 状態 54 中断条件 214 適格ホスト 34 閉鎖されたサーバの状態 54 ホストごとの負荷 55, 104 ホストとホストの状態 54 リソースごとの負荷 99 履歴 56 ファイル 68 複数ネットワーク インタフェース 69 閉鎖する 58 リソースを関連付ける 117 リソースを検出する 265 ~間でファイルをコピーする 263 ホスト タイプ DEFAULT 310 lsf.shared に独自の名前を追加する 64 リソースの要件 134 ホスト タイプの静的リソース 55, 109 ホストのアーキテクチャ情報を参照する 55 ホストのエントリ 例 70 ホストの状態 busy 53, 105 closed 52, 54 lockU 53 lockU および lockW 106 66 Platform Clusterware 管理者 331 索引 lockW 53, 105 -ok 53, 105 ok 52, 53, 105 unavail 52, 53, 106 unlicensed 52, 53, 106 unreach 52 インデックス 105 表示する 54 ホストの選択 138 ホストの負荷レベル 34 ホスト ベースのリソース 100 ホストへのディスパッチが可能な時間帯 148 ホスト名 /etc/hosts ファイル 68 DNS の使用 68 resolv.conf ファイル 68 resolver 関数 68 インターネット アドレスに対応付ける 68 別名 68 ホスト名の静的リソース 109 ホスト モデル CPU 係数を調整する 73 DEFAULT 310 lsf.shared に独自の名前を追加する 64 ホスト モデルの静的リソース 109 ホスト レベル 移行しきい値 180 ポリシー LIM のチューニング 281 保留理由 , 参照する 85 ま マスタ esub(mesub) 設定する 236 説明 235 マスタ ホスト 現在の~を参照する 42 マルチプロセッサ ホスト LIM のチューニング 284 キュー レベル負荷しきい値を設定する マルチ ホーム ホスト 69 め メール ジョブ オプション 294 ジョブ電子メールのサイズ制限 295 バッチ ジョブ無効化の通知 295 メモリ 使用可能な 107 使用制限 203 ゆ ユーザ数 投入されたジョブを参照する ユーザの認証 許可 291 認証 285 ユーザ ホーム ディレクトリ 共有 36 332 Platform Clusterware 管理者 87 213 り リソース カスタム 114 カスタム設定する 116 カスタム リソースを追加する 116 共有 102, 103 組込み~ 105 追加 115 表示する 共有 42 使用可能な 42, 98 ホストの負荷 99 分類 100 ホストに関連付ける 117 論理値 100 →「負荷インデックス」も参照 252 リソース使用制限 最大の 200 上限の 200 設定する 200 ソフト 200 デフォルト 200 ハード 200 リソース使用制限の上限 200 リソース使用量(rusage) 表示する 104 リソース制限 指定する 200 デフォルト 200 リソースのソフト制限 説明 198 例 200 リソースのハード制限 説明 198 リソースの要件 説明 134 ホスト タイプ 134 ホストの順序付け 138, 142 ホストを選択する 138, 140 リソース名 説明 116 別名 140 リモート実行 lsf.conf の LSF_AUTH パラメータ 288 lsf.sudoers の LSF_EAUTH_KEY パラメータ 286 lsf.sudoers の LSF_EAUTH_USER パラメータ 287 RFC 1413 と RFC 931 288 外部(eauth) 286 概要 285 環境 286 識別デーモン(identd) 288 セキュリティ 289 特権ポート(setuid) 288 リモート ジョブ 実行優先順位(UNIX のみ) 109 リモート接続 特権ポート認証の制限 288 履歴 ジョブ配列 188, 191 索引 れ 例 /etc/hosts ファイルのエントリ ろ ログ ディレクトリの所有者 302 ログ ファイル lim.log.host_name 303 70 mbatchd.log.host_name 303 mbschd.log.host_name 303 pim.log.host_name 303 res.log.host_name 303 sbatchd.log.host_name 303 管理する 303 ディレクトリのアクセス権と所有者 デフォルトの場所 302 保守する 303 302 Platform Clusterware 管理者 333 索引 334 Platform Clusterware 管理者
© Copyright 2024 Paperzz