ヘッドレス HPC 環境の落とし穴
概要
Rescale で HPC を実行する場合、または従来の HPC 環境で HPC を実行する場合は、ソルバーがヘッドレス環境で実行できることが重要です。 これが実際に意味するのは、ISV はソルバーが次の環境で実行できることを確認しているということです。 バッチ シンプル (またはそれほどシンプルではない) を使用するモード コマンドライン 説明書。 これにより、ソフトウェアのユーザーはヘッドレス HPC 環境にジョブを送信できるようになります。 従来、この環境はスケジューラの背後にある一連のサーバーです。 エンジニアまたは科学者は、スケジューラに送信するコマンドライン命令のスクリプトを作成します。 Rescaleでも同様です。 ユーザーは一連のコマンドライン命令を入力して、Rescale のプラットフォームでジョブを実行します。
OpenFOAMを例に考えてみましょう。 OpenFOAM ユーザーは通常、Allrun スクリプトを作成し、そのスクリプトを呼び出すだけで Rescale でそれを呼び出します。
./オールラン
これは簡単で、Rescale で利用可能な他のソルバー (LS-Dyna、CONVERGE、 スターCCM+、NX Nastran、XFlow など。 Rescale のすべてのソルバーは、単純なコマンドライン命令を使用してインスタンス化されます。
ヘッドレス環境
コマンドライン命令を使用してソルバーを実行できることは、ソルバーがバッチで実行されることを意味するものではありません。 たとえば、ソルバーをバッチ モードで実行するように明示的に指定せずに Star-CCM+ を実行しようとすると、プログラムがグラフィカル ユーザー インターフェイス (GUI) を起動してディスプレイ デバイスを探し、プログラムがすぐに終了します。 したがって、Star-CCM+ は、次のようなコマンドライン命令を使用して呼び出す必要があります。
starccm+ -power -np 4 -batch バッチ.java
これはとても簡単です。 同じプログラムを使用してバッチ ソルバーと GUI の両方を実行することには、言うべきことがあります。 残念ながら、このタイプの実装は不完全な場合があります。
ISV がソルバー機能をデスクトップ環境から HPC (バッチ) 環境に移行することを決定する場合、通常はこれを実行します。これは、ソルバーを複数のマシン上で実行する機能を実装しているためです。 単一マシン上でのみ実行できるソルバーは、HPC 環境で実行するとあまりメリットがありません。 最初の反復では、ISV はバッチ ソルバー内に元のデスクトップ実装の潜在的なアーティファクトを残す場合があります。 これらのソルバーはコマンドラインから実行できますが、ディスプレイへのアクセスが必要な場合があります。 Rescale では、これらの「ほぼヘッドレス」ソルバーを実行できるようにしたいため、仮想フレーム バッファーと呼ばれるツールを使用します。
X仮想フレームバッファ
X 仮想フレーム バッファー (Xvfb) はメモリ内に仮想ディスプレイをレンダリングするため、真のヘッドレスでないアプリケーションはこれを使用してグラフィック要素をレンダリングできます。 Rescale では、仮想フレーム バッファーを起動して実行するとパフォーマンスが低下するため、最後の手段として仮想フレーム バッファーを使用します。 Xvfb を使用するには、これらのソルバー プログラムの周囲にラッパーを実装する必要があります。 最も単純な形式では、これは次のように実装できます。
#!/bin/bash # ラッパー スクリプトは /usr/local/bin/solver にあります _d=1 Xvfb :${_d} > /tmp/xvfb-${_d}.log 2>&1 & _xvfb_pid=$! エクスポート DISPLAY=:${_d} /path/to/real/solver $@ kill ${_xvfb_pid}
これは非常に簡単なようです。 番号付きディスプレイ上で仮想フレーム バッファーを起動し、仮想フレーム バッファーに関連付けられたディスプレイを使用するように環境に指示し、ソルバーを起動して、最後にクリーンアップします。
ワームの缶詰
Rescale の非常に強力な機能の 100 つは、パラメーター スイープ/実験計画法 (DOE) 機能です。 DOE の複数の実行を並行して実行できます。 これは、同じサーバー上で DOE を複数実行できることも意味します。 同じノード上で上記のスクリプトを 99 回実行することを想像してみましょう。 スクリプトの各インスタンス化は、同じディスプレイ上でフレーム バッファーを起動しようとします。 これはあらゆる種類の問題を引き起こす可能性があります。 競合状態、プロセスの破損など。 これが引き起こす可能性のある低レベルの問題に関係なく、最大の高レベルの問題は、仮想フレーム バッファーの問題によりソルバーがハングした場合です。 現状では、XNUMX 回実行する DOE を開始したユーザーは、XNUMX 日の終わりに開始し、ジョブを一晩実行することができます。 翌朝、ユーザーは Xvfb の問題により XNUMX つの実行が一晩中ハングしていたことに気づくかもしれません。 まだ XNUMX 件の実行が数時間以内に終了する可能性がありますが、XNUMX 件の実行がハングしているため、クラスターは一晩中稼働し続けています。 このような事態は何としても避けたいものです。
仮想フレーム バッファーを実装するには、あらゆる種類の堅牢性の規定をラッパー スクリプトに書き込む必要があります。 単一のディスプレイ上で単一の Xvfb のみを起動し、そのディスプレイをすべてのソルバーのインスタンス化に使用することを決定する場合があります。 Xvfb が実行されているかどうかを確認し、実行されていない場合は、フレーム バッファーの起動ステップをスキップします。
if [ -z “$(ps aux | grep Xvfb | grep :${_d})” ]; 次に Xvfb :${_d}; フィ
これには、フレーム バッファーをいつシャットダウンできるかわからないという副作用があり、常にフレーム バッファーを起動しておかなければなりません。 ソルバーの要件によっては、これで問題ない場合もあります。 それが問題ない場合は、ソルバー プロセスごとに表示番号をインクリメントし、各ソルバーが終了したときに各フレーム バッファーをクリーンアップする必要があります。
ソルバーがハングしているかどうかを明示的に確認することもできます。 バックグラウンドでソルバーを起動し、フォアグラウンド ポーリング ループを使用してその PID を調べてプログラムのステータスを調べることができます。 ソルバーのインスタンス化に再試行ループを記述して、最初に失敗した場合にソルバーを再起動できます。 これは、ソルバーの呼び出し中にフレーム バッファーがまだ初期化中の場合に当てはまります。
無効なライセンスの場合
私たちがサポートしている CFD ソルバーの 2 つはフレーム バッファーを必要とします。 顧客が有効なライセンス アドレスを指定せずに単純なジョブを開始しました。 XNUMX 日後、彼は自分の仕事がまだ続いているかどうか疑問に思いました。 ソルバーはインスタンス化されてから数秒以内にハングし、XNUMX 日間アイドル状態になっていたことが判明しました。 この問題のデバッグ中に、仮想フレーム バッファーを検査することにしました。 以下を使用してスクリーンショットを撮りました。
xwd -root -silent -display :${_d} | xwdtopnm | pnmtojpeg > ss.jpg
結果として得られたスクリーンショットには、ユーザーに有効なライセンスの場所を入力するよう求めるウィンドウが表示されていました。 これは明らかに、バッチ ソルバーのデスクトップ実装におけるアーティファクトでした。 真のヘッドレス バッチ プログラムは、ユーザーにメッセージを表示して終了するだけです。 その後、私たちはこの問題を修正し、このツールを使用するときはより慎重になり、前述したように堅牢性を確保しました。
仮想フレームバッファの後処理ユーティリティ
Xvfb の非常に便利なユーティリティは、これを使用してヘッドレス環境で後処理グラフィックスをレンダリングできることです。 ParaView や LS-PrePost などのツールを呼び出して、通常は画面上にレンダリングされるシーンのムービーや画像を生成できるようになりました。
以下は、Xvfb、OpenFOAM、および ParaView を使用してシーン イメージを生成する例です。 https://www.rescale.com/resources/software/openfoam/openfoam-motorbike-post/
以下は、Xvfb、LS-Dyna、LS-PrePost を使用して衝突シミュレーションのムービーを生成する例です。 https://www.rescale.com/resources/software/ls-dyna/ls-dyna-post-processing/
ユーザーの中には、生のデータ セットをダウンロードする必要がなく、データの視覚的表現を作成することでこの機能を活用している人もいます。
教訓
Xvfb を初めて使用して以来、Xvfb の使用により有害な予期せぬ副作用が発生する場合があることがわかりました。 それ以来、私たちはすべての Xvfb の使用を可能な限り堅牢にして、最悪の副作用であるジョブの停止を防ぐことに取り組んできました。 また、Xvfb を使用すると、従来のヘッドレス HPC 環境では実行できないソルバーを実行できるため、大きなメリットがありました。 また、特定の後処理ツールを使用して画像やムービーをバッチ モードでレンダリングすることもできます。 ソルバーのデスクトップ実装しか持っていない ISV には、ヘッドレス HPC 環境で実行されるソルバーを作成することをお勧めします。ただし、その際には、ディスプレイなしでソルバーを実際に実行することが何を意味するかを念頭に置いてください。
