SLURMの環境変数をprologで割り当てる方法メモ
| 登録日 | :2024/11/19 22:16 |
|---|---|
| カテゴリ | :SLURM |
slurm.confのProlog設定を使って環境変数を読み込ませることができます。主な方法は以下の通りです:
slurm.confにProlog設定を追加:
text
Prolog=/path/to/prolog_script.sh
prolog_script.shの中で環境変数を設定:
#!/bin/bash
export MY_CUSTOM_VAR=value
source /path/to/environment_setup.sh
PrologFlagsを設定して、ジョブ割り当て時にPrologを実行:
PrologFlags=Alloc
複数のPrologスクリプトを使用する場合:
Prolog=/etc/slurm/prolog.d/*
このPrologスクリプトは、ジョブが特定のノードで最初に実行される際に、SlurmdUserの権限(通常はroot)で実行されます。ここで設定された環境変数は、そのノード上のジョブプロセスで利用可能になります。
注意点:
セキュリティ上の理由から、Prologスクリプトには完全修飾パス名を使用するか、PATH環境変数を適切に設定する必要があります。
Prologスクリプトの変更後は、scontrol reconfigureコマンドを実行して変更を反映させる必要があります。
ユーザー固有の環境変数を設定する場合は、セキュリティに十分注意してください。
この方法を使用することで、バッチジョブに割り当てられたノードで必要な環境変数を確実に設定することができます。
もっと見る
例えば、/etc/slurm/prolog.d/にファイルが何もない場合は、何も適用されないから問題ないという認識でよいですか
ソース
回答
はい、その認識で正確です。/etc/slurm/prolog.d/ ディレクトリにファイルが何もない場合、Prologスクリプトは何も実行されません。
具体的には:
slurm.confで以下のように設定されている場合:
Prolog=/etc/slurm/prolog.d/*
/etc/slurm/prolog.d/ ディレクトリが空の場合:
Slurmはこのディレクトリ内のスクリプトを実行しようとしますが、スクリプトが存在しないため何も実行されません。
これは正常な動作であり、エラーにはなりません。
空のディレクトリがあることによる影響:
ジョブの実行には影響しません。
システムのパフォーマンスにも影響しません。
注意点:
ディレクトリ自体は存在している必要があります。ディレクトリが存在しない場合はエラーが発生する可能性があります。
将来的にPrologスクリプトを追加したい場合に備えて、空のディレクトリを用意しておくのは良い習慣です。
したがって、/etc/slurm/prolog.d/ ディレクトリが空の状態でも、Slurmの動作に問題はありません。必要に応じてスクリプトを追加することで、ジョブ実行前の処理を制御できるようになります。
デフォルトは、/etc/slurm/prolog.dフォルダが存在しませんよね。
ソース
回答
その通りです。デフォルトでは、/etc/slurm/prolog.dフォルダは自動的には作成されません。
重要なポイント:
フォルダが存在しない場合の動作:
Slurmは空のフォルダや存在しないフォルダに対してエラーを出す可能性があります
ジョブの実行に影響を与える可能性があります
推奨される対応:
sudo mkdir -p /etc/slurm/prolog.d
sudo mkdir -p /etc/slurm/epilog.d
注意点:
フォルダを作成しても、中にスクリプトがない場合は問題が発生する可能性があります
スクリプトがない場合は、slurm.confの該当行をコメントアウトすることも一つの対処法です
設定確認:
sudo scontrol reconfigure
したがって、/etc/slurm/prolog.dフォルダは手動で作成する必要があり、デフォルトでは存在しません。
slurm.confを編集したとき、scontrol reconfigureでいいんでしょうか。再起動はいらないですか?
slurm.confを編集した後の対応は、変更内容によって異なります:
多くの設定変更の場合:
scontrol reconfigure コマンドで十分です。これにより、Slurmデーモンは設定ファイルを再読み込みし、新しい設定を適用します。
特定の重要な設定を変更した場合:
Slurmデーモンの再起動が必要です。以下の設定を変更した場合は再起動が必要です:
AuthType
ControlMach
PluginDir
StateSaveLocation
SlurmctldHost
SlurmctldPort
SlurmdPort
ノードの追加や削除
再起動が必要な場合の手順:
a. slurmctldの停止: sudo systemctl stop slurmctld
b. すべてのノードでslurmdの停止: sudo systemctl stop slurmd
c. slurmctldの起動: sudo systemctl start slurmctld
d. すべてのノードでslurmdの起動: sudo systemctl start slurmd
注意点:
設定ファイルの変更を全ノードに配布してから reconfigure や再起動を行ってください。
StateSaveLocationの内容は保持してください。必要に応じてバックアップを取ってください。
SlurmctldTimeout と SlurmdTimeout の設定値に注意し、長時間のダウンタイムを避けてください。
結論として、多くの場合は scontrol reconfigure で十分ですが、重要な設定変更の場合は再起動が必要です。変更内容を確認し、適切な方法を選択してください。
まとめ
以下のような設定手順
Prolog=/path/to/prolog_script.sh
prolog_script.shの中で環境変数を設定:
#!/bin/bash
export MY_CUSTOM_VAR=value
source /path/to/environment_setup.sh
PrologFlagsを設定して、ジョブ割り当て時にPrologを実行:
PrologFlags=Alloc
複数のPrologスクリプトを使用する場合:
Prolog=/etc/slurm/prolog.d/*
ーーー
/etc/slurm/prolog_script.shにて、sbatchで割り当てられたノードの/etc/profile.d/setting.shとsetting.cshを読み込ませたいです。
ソース
回答
/etc/slurm/prolog_script.shで、sbatchで割り当てられたノードの/etc/profile.d/setting.shとsetting.cshを読み込ませるには、以下のような方法が考えられます:
prolog_script.shの作成:
#!/bin/bash
# bashユーザー向け
echo ". /etc/profile.d/setting.sh" >> /etc/profile
# csh/tcshユーザー向け
echo "source /etc/profile.d/setting.csh" >> /etc/csh.login
# 現在のジョブ環境に即時反映させる
if [ -f /etc/profile.d/setting.sh ]; then
. /etc/profile.d/setting.sh
fi
実行権限の付与:
sudo chmod +x /etc/slurm/prolog_script.sh
slurm.confの設定:
Prolog=/etc/slurm/prolog_script.sh
PrologFlags=Alloc
この方法には以下の注意点があります:
このスクリプトはroot権限で実行されるため、セキュリティに十分注意してください。
/etc/profileや/etc/csh.loginを直接編集するため、システム全体に影響を与える可能性があります。
既存の設定と競合しないよう、慎重に実装する必要があります。
ジョブ終了後にこれらの変更を元に戻す epilog スクリプトも考慮する必要があるかもしれません。
より安全な代替案として、以下の方法も考えられます:
/etc/profile.d/に slurm_job_settings.sh と slurm_job_settings.csh を作成し、その中で条件分岐を使用してジョブ実行時のみ setting.sh と setting.csh を読み込むようにする。
ユーザーのジョブスクリプト内で直接 source コマンドを使用して設定ファイルを読み込む。
これらの方法は、システム全体への影響を最小限に抑えつつ、必要な環境設定を行うことができます。
ーーー
sbatchで実行されるスクリプトがbashかcshかわからない場合、両方の設定ファイルを読み込む方法が適切です。以下のようなアプローチを取ることができます:
/etc/slurm/prolog_script.sh の作成:
#!/bin/bash
# bash用の設定を読み込む
if [ -f /etc/profile.d/intelMPI.sh ]; then
. /etc/profile.d/intelMPI.sh
fi
# csh用の設定をbash形式に変換して読み込む
if [ -f /etc/profile.d/intelMPI.csh ]; then
eval "$(csh -c 'source /etc/profile.d/intelMPI.csh && env' | sed 's/^/export /' | sed 's/=/ /')"
fi
# 現在の環境変数をジョブ環境に反映させる
if [ -n "$SLURM_JOB_ID" ]; then
env > /tmp/slurm_job_env_${SLURM_JOB_ID}
echo ". /tmp/slurm_job_env_${SLURM_JOB_ID}" >> $HOME/.bashrc
echo "source /tmp/slurm_job_env_${SLURM_JOB_ID}" >> $HOME/.cshrc
fi
このスクリプトは以下のことを行います:
bash用の設定ファイル (intelMPI.sh) が存在する場合、それを読み込みます。
csh用の設定ファイル (intelMPI.csh) が存在する場合、その内容をbash形式に変換して読み込みます。
設定された環境変数を一時ファイルに保存し、ユーザーの.bashrcと.cshrcファイルにそれを読み込む設定を追加します。
注意点:
このアプローチは、bash形式のスクリプトとcsh形式のスクリプトの両方に対応します。
cshファイルの内容をbash形式に変換する際、完全な互換性は保証されません。複雑な設定の場合、手動で調整が必要な場合があります。
セキュリティ上の理由から、信頼できる設定ファイルのみを使用してください。
一時ファイルを使用しているため、ジョブ終了後にこれらのファイルを削除するepilogスクリプトも考慮する必要があります。
このアプローチにより、sbatchで実行されるスクリプトがbashでもcshでも、必要な環境変数が設定されることが期待できます。ただし、特定の環境や要件によっては、さらなる調整が必要な場合があります。
cshファイルをbashようにするのは、prolog_script.shが#!bin/bashだからですか
はい、その通りです。prolog_script.shが#!/bin/bashで始まっているため、このスクリプトはbashで実行されます。そのため、cshファイルの内容をbash形式に変換する必要があります。
主な理由は以下の通りです:
シェルの違い:
bashとcshは異なるシェルで、構文や環境変数の設定方法が異なります1。
実行環境:
prolog_script.shがbashで実行されるため、その中でcsh形式の命令を直接実行することはできません。
互換性:
bashスクリプト内でcshの設定を直接読み込むことはできないため、変換が必要になります。
環境変数の設定:
SLURMのprologスクリプトの目的は、ジョブ実行環境を準備することです。そのため、cshファイルの設定をbash環境で利用可能な形式に変換する必要があります2。
一貫性:
異なるシェル間で環境変数を共有するために、共通の形式(この場合はbash形式)に変換することで、一貫性のある環境設定が可能になります。
したがって、cshファイルの内容をbash形式に変換することで、prolog_script.sh内でcshの設定を効果的に利用することができます。これにより、bashとcshのどちらのジョブスクリプトでも、同じ環境変数設定を利用できるようになります
ーーー
Appendix 実行テスト
slurm.confに設定してテストしたところ以下のことが分かった。
- Slurmの設定でPrologスクリプトを指定する場合、そのファイルが存在し、正しく設定されていることが重要です。
- プロローグスクリプトには適切な実行権限(通常は755)が必要です。
- シバン(shebang)行は、スクリプトを正しく解釈するために重要です。通常は #!/bin/bash や #!/bin/sh を使用します。
- プロローグスクリプトに問題がある場合、ジョブの実行に影響を与え、"launch failed requeued held" などの状態を引き起こす可能性があります。
- Slurmの設定を変更した後は、必要に応じてSlurmデーモン(slurmd, slurmctld)を再起動することが重要です。
これらの点に注意することで、今後同様の問題を回避し、Slurmクラスタをより効率的に管理できるでしょう。何か新しい設定を追加する際は、まず小規模なテストを行い、問題がないことを確認してから本番環境に適用することをお勧めします。
ジョブが実行できなくなった時のステータス。
[user01@headnode work]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
60 part1 test user01 PD 0:00 1 (launch failed requeued held)