第9回：HTCondorで処理を行う

みなさんこんにちは。2019年が明けて早くも1ヶ月が過ぎました。そしてMaya 2019がリリースされましたね。PythonやPySideのバージョンはこれまでと同じなので、ツール開発者としては一安心です。アップデート内容に関してはTwitterなんかを見ているとワクワクする新機能がないということでガッカリしている人が結構いるようですが、アニメーション再生周りのキャッシュ機能がついて高速化されるなど、高速化に重点を置いた更新が行われてます。個人的には、地味ですが仕事で使うツールとしては堅実なアップデートをしているなという印象を受けました（もちろん実際に触ってみないと、どうなのかはわからないですけどねっ！！）。

TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）

HTCondor8.8.0リリース

年明け1月4日にHTCondorも最新の安定板8.8.0がリリースされました。こちらは、前回インストールした8.7系で開発されていた新機能を取り込んだ新しい安定板となっています。今後環境構築をする場合は、こちらのStable版を使用するのがよいでしょう。本連載では、とりあえず必要になるまでは8.7.10をそのまま使うことにします。

・HTCondorで処理を行う

前回はHTCondorの基本的な使い方を試してみました。今回は一歩進んで、われわれがよく行う作業をHTCondorを使って処理してみます。まずはレンダリング、続いてデータ変換処理を行なってみましょう。

・計算サーバを追加する

実際に各種処理を行うのはこれまで連載で使用してきたLinux環境なので、これを前回作成したHTCondor Poolに計算サーバとして追加します。このマシンのホスト名はdockerなので、HTCondor上でもdockerという名前で管理されます。

インストールの手順は前回セントラルマネージャを構築したときとほぼ同じです。condor_configをWindowsと同様計算サーバとサブミットマシンとして動作するように設定します。今回はcondor_configの最後に以下の設定を追加しました。

----
CONDOR_HOST = htcondor.XXX.XXX.XXX
FILESYSTEM_DOMAIN = XXX.XXX.XXX
UID_DOMAIN = XXX.XXX.XXX

CONDOR_ADMIN =
SMTP_SERVER =
ALLOW_READ = *
ALLOW_WRITE = *
ALLOW_ADMINISTRATOR = $(IP_ADDRESS)
use POLICY : ALWAYS_RUN_JOBS
WANT_VACATE = FALSE
WANT_SUSPEND = TRUE
DAEMON_LIST = MASTER SCHEDD STARTD
----

CONDOR_HOSTはセントラルマネージャのホスト名です。Windowsの場合はインストーラで指定することで設定ファイルに自動的に追加されていましたが、Linuxでは自分で記述する必要があります。

FILESYSTEM_DOMAINとUID_DOMAINはファイルサーバとユーザーアカウントの管理を行なっているグループを識別するためのものです。ここで指定された名前が同じであれば、同じファイルサーバやアカウント管理を行なっている環境で処理を行うことができるということになります。この名前はマッチメイキングのときに使用されるだけなので、実際に使用しているドメイン名などと同じである必要はないです。ただ、複数の計算サーバを使用してHTCondor Poolを構築する場合、この設定が行われていないと各計算サーバ毎に別のファイルシステムをもっていると認識されて正常に動作しないなど、トラブルの元になりやすいようです。

・Gaffer+Arnoldでのレンダリングを行う

計算サーバの追加ができたので、まずは第5回：Gafferによるルックデヴ＆ライティングで作成したGafferのシーンをHTCondorを使用してレンダリングしてみます。

Gafferでのレンダリングをサーバ上で実行するためには、いくつかの段階に処理を分割していきます。

・HTCondorにジョブを投入する
・HTCondorがジョブを解釈してGafferを起動する
・Gafferがレンダリングを行う

ジョブを投入するのは前回行なったcondor_submitが担当し、HTCondorが解釈するためのデータはsubmit description file(sdf)です。

Gafferでシーンをコマンドラインからレンダリングする方法はマニュアルに書いてあります。

レンダリング用のシーン構成ですが、第5回の時点では正しい方法にはなっていなかったため、私のBlogで後日訂正しています。Outputノードで出力先を指定し、ArnoldRenderノードをExecuteするとレンダリングとファイルへの出力を行うことができます。

また、Gaffer上でArnoldを使用するためには環境変数を設定する必要があるので、起動用のshスクリプトを作成します。

[chiyama@docker HTCondor]$ cat ~/gaffer.sh 
#!/bin/sh

export GAFFER_ROOT=/opt/gaffer-0.50.0.0-linux
export ARNOLD_ROOT=/opt/Arnold-5.1.1.2-linux

export HOME=/home/chiyama

$GAFFER_ROOT/bin/gaffer "$@"

[chiyama@docker HTCondor]$ 

HTCondorから実行されたジョブの環境変数はコマンドラインで確認するものとかなり異なり、ほとんどの値が設定されていないです。この場合、アプリケーションによっては必要な環境変数を指定してやらないと正常に動作しない場合があります。Gafferの場合は環境変数HOMEがないと正常に処理ができないため、設定しています。

試しに、このスクリプトを使ってコマンドラインからレンダリングをしてみます。

[chiyama@docker HTCondor]$ ls render/
[chiyama@docker HTCondor]$ ~/gaffer.sh execute -script layout_Arnold.gfr  -nodes ArnoldRender -frames 1
/opt/gaffer-0.50.0.0-linux/python/pxr/Tf/__init__.py:85: RuntimeWarning: to-Python converter for boost::posix_time::ptime already registered; second conversion method ignored.
  from . import _tf

（中略）

[chiyama@docker HTCondor]$ ls render/
layout_Arnold.0001.exr
[chiyama@docker HTCondor]$ 

無事にシーンがレンダリングされました。

これをHTCondorのジョブとして投入します。実行すべきコマンドがもうわかっているので、sdfも簡単に書くことができます。

[chiyama@docker HTCondor]$ cat layout_Arnold.sdf

executable = /bin/sh

output = /home/chiyama/Documents/HTCondor/log/layout_Arnold.$(Process).out
error = /home/chiyama/Documents/HTCondor/log/layout_Arnold.$(Process).err
log = /home/chiyama/Documents/HTCondor/log/layout_Arnold.$(Process).log

arguments = /home/chiyama/gaffer.sh execute -script /home/chiyama/Documents/HTCondor/layout_Arnold.gfr  -nodes ArnoldRender -frames $(Process)

initialdir = /home/chiyama/Documents/HTCondor
requirements = TARGET.OpSys == "LINUX" && TARGET.FileSystemDomain == "XXX.XXX.XXX" && TARGET.UidDomain == "XXX.XXX.XXX" && TARGET.Machine == "docker.XXX.XXX.XXX"

should_transfer_files = no

queue 10
[chiyama@docker HTCondor]$

先ほど設定したFileSystemDomainやUidDomainをここで使用しています。

should_transfer_files = noは、ジョブ実行時に必要なファイルを転送する機能を使用しないという意味です。これを有効にするためにはTARGET.FileSystemDomainが同じ環境でジョブが実行される必要があります。実行時のファイル転送はとても強力な機能なので機会があれば試したいです。

TARGET.Machineは、ジョブを実行したいマシンを指定する場合に使用します。私の環境ではGafferが動くLinuxの計算サーバがdocker以外にないので、このマシンを指定しています。これを指定しないとセントラルマネージャ兼計算サーバとして登録されているマシンにもジョブが割り振られてしまいます。

queueに10という引数が渡されています。これは、ひとつの設定でジョブを10個登録するという意味になります。このとき、特に何もしなければ完全に同じ内容のジョブが10個登録されますが、ジョブごとに設定されるProcess変数を使用することで動作にバリエーションをつくることができます。今回はargumentsでframes引数のオプションとして使用されていますね。Process変数はジョブごとに0から順に割り当てられるため、今回の場合は0～9フレームを各々1フレームづつレンダリングする10個のジョブが作成されることになります。

次ページ：
ジョブを投入する