Platform Clusterware(TM) 管理者
Version 5.1
June 2003
お問い合わせ : [email protected]
著作権表示
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).
ご意見をお聞かせくださ
い
本書の内容、構成、情報の有効性についてご意見をお聞かせください。本書を改良するときの参考に
させていただきます。間違いを発見した場合、または改良のヒントをお持ちの場合は、
[email protected] 宛にコメントをお寄せください。
ただし、LSF のドキュメンテーションについてのコメント以外は、ご容赦ください。製品のサポート
については、[email protected] へご連絡ください。
本書に記載されている情報については慎重に確認していますが、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 サイトにアクセスできない場合は、
[email protected] 宛に電子メールをお送りください。
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 ベ
ンダにご連絡ください。プラットフォーム コンピューティング社のテクニカル サ
ポートに連絡をとるには、以下のいずれかの方法をご利用ください。
電子メール [email protected]
World Wide Web www.platform.co.jp
電話 ◆
03-5326-3105
郵送 〒 163-1030
東京都新宿区西新宿 3-7-1
新宿パークタワー N30F
プラットフォーム コンピューティング株式会社
プロフェッショナル サービス担当宛
当社に連絡される際は、正式な会社名をお知らせください。
ご意見をお聞かせください
本書またはその他の Platform マニュアルに誤りがあった場合や、マニュアルに対す
るご意見をお持ちの場合は、以下の方法でお知らせください。
電子メール [email protected]
郵送 〒 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- ２００３ 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 管理者

解像特性2

LSF クイックスタート

はやわかりLSF 【管理者編】

オビゴ

無限等比級数の和 - 物理のかぎしっぽ

1 ボランティア体験記 私の友人がパステル画をボランティアで始めるのだ

業務用の冷凍冷蔵機器や空調機器を所有（管理）している方は、

第23回世界スカウトジャンボリー会場運営管理要綱