みなさんこんにちは。今年もSIGGRAPHがロサンゼルスで開催されました。私は仕事に追われてほとんど話題を追えていないのですが、今年はUSD周りでホットな話題が多かったようです。各種アプリケーションがUSD対応を進めてくれれば、CG制作のながれが大きく変わる可能性が出てくるので、今後のUSD周りはとても面白くなりそうです。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
ネットワーク環境の調整
ユーザーが使用する際にも管理者が管理をする際にも、クラウドレンダリングのための専用ツールと環境を用意して使うのは敷居が高いです。社内環境でもクラウド環境でも、同じような手順で構築でき、同じツールを使用して計算できるのが理想的です。その理想を実現できるよう、今回から数回に分けて、どちらの環境でも同じような運用ができるように整備を進めていきます。
前回、最初の一歩として基本的な社内ネットワークを構築しました。これは下図の通りの構成でした。
これを元に、HTCondorの設定を行なっていきます。
実は前回作成した構成でHTCondorを動かすのには大きな問題があります。そして、クラウド上で動かす場合でも同様な問題があるため、これに対応しておく必要があります。
何が問題なのか、そしてクラウド上でHTCondorを動かす場合にどこで困るのかを知るためには、一度HTCondorのしくみを確認しなおす必要があります。問題点と対応方法については、Condor Week 2009のプレゼンテーション、 "The Condor Connection Broker" が参考になります。
HTCondorはサブミットマシンと計算ノード間で直接通信をして、ジョブの実行やファイルの転送を行います。そのため、両者が通信できない環境ではジョブの実行ができません。
※ "The Condor Connection Broker" より引用
下図の点線がファイヤウォールです。計算ノードがファイヤウォール内に存在するため、［計算ノード］→［サブミットマシン］の通信はできるものの、逆の通信はできなくなっています。
※ "The Condor Connection Broker" より引用
前回作成したネットワークも同様で、サブミットマシンと計算サーバ間の通信ができなくなっています。
この問題に対応する最も簡単な方法は、両方のネットワーク間にルータを置き、双方向に通信できるようにすることです。計算サーバがクラウドにある場合、社内ネットワークとクラウド上のネットワークでVPNを張ることになります。
ただ、本連載ではもう少し社内環境とクラウド環境を切り離した感じで運用したいので、双方向の通信を行わず、計算サーバ側はファイヤウォールの向こう側にあるような環境にします。こうすれば、計算サーバをクラウド側に置いても似たような環境が再現できるはずです。HTCondorには異なるネットワーク間にある計算サーバを使用するための方法がいくつかあり、どの方法をとるのがベストなのかは私もまだ完全に把握できていません。公式ドキュメントなどを参考にしながら手探りで進める必要があります。ひとまずは社内にあるマネージャが管理するpoolに全ての計算サーバを登録する方法で進めていきます。
今回は 前述の "The Condor Connection Broker" で紹介されている、Condor Connection Broker（CCB）を使用してこの問題に対応することにします。具体的には、下図を参考に環境をつくっていきます。
※ "The Condor Connection Broker" より引用
方針が決まったので、ネットワーク構成を見なおします。これまではセントラルマネージャが両者のネットワークに接続しているだけで、2つのネットワーク間での通信は一切できなくなっていました。
ここを見なおし、ネットワークの間にルータを挟んでセントラルマネージャをサブミットマシンのあるネットワークに配置します。また、ルータの設定を行なって、計算サーバからセントラルマネージャのあるネットワークへのアクセスはできるものの、逆方向のアクセスはできないようにしておきます。このあたりの設定はよくあるネットワーク構築のお話なので、紙面の関係で省略します。すみません。
こうすることで、クラウド上に計算サーバを置いたのと似たような状態をつくることができます。
CCBを使用した環境構築
続いて、HTCondorの設定をします。設定のキモは以下の通りです
・全てのサーバでPRIVATE_NETWORK_NAMEの設定をする
・計算サーバとサブミットマシンでFILESYSTEM_DOMAIN、UID_DOMAINの設定をする
・計算サーバとサブミットマシンでUSE_SHARED_PORTの設定をする
・計算サーバ側でCCB_ADDRESSの設定をする
・CONDOR_HOSTは192.168.0.36を指定する（きちんと名前解決できるのならホスト名でもいい）
第9回：HTCondorで処理を行うでやったように、ジョブをどの環境で実行するかの指定は、sdfファイルのrequirementsに条件を記述することで実現できます。今回は各計算ノードごとにストレージが異なるため、それで区別できるようにFILESYSTEM_DOMAIN、UID_DOMAINを設定し、レンダーファーム上の計算サーバはfarm.example.netという名前で管理します。同様に、作業環境用のマシンはintra.example.netという名前にします。
これで、レンダーファーム上の計算サーバでジョブを実行したい場合はsdfに
requirements = TARGET.FileSystemDomain == "farm.example.net" && TARGET.UidDomain == "farm.example.net"
と記述すればよくなります。
また、サブミットマシンとは異なるUID_DOMAINの計算機にジョブを投げた場合、標準では計算サーバでnobodyアカウントとしてジョブが実行されるため、アクセス権に注意する必要があります。また、当然ですがファイルを格納するストレージも別なので、サブミットマシンにあるディレクトリやファイルが計算サーバにあるとは限りません。運用の際はこの点にも注意する必要があります。
・セントラルマネージャの設定
以上を踏まえて設定を行なっていきます。まずはセントラルマネージャからです。
[chiyama@htcondor ~]$ cat /etc/condor/condor_config
######################################################################
##
## condor_config
##
## This is the global configuration file for condor. This is where
(中略)
## Install the minicondor package to run HTCondor on a single node
ALLOW_READ = *
ALLOW_WRITE = *
ALLOW_NEGOTIATOR = *
ALLOW_NEGOTIATOR_SCHEDD = *
ALLOW_ADMINISTRATOR = $(IP_ADDRESS)
WANT_VACANT = FALSE
WANT_SUSPEND = TRUE
CONDOR_HOST = 192.168.0.36
BIND_ALL_INTERFACES = True
PRIVATE_NETWORK_NAME = intra.example.net
DAEMON_LIST = MASTER, NEGOTIATOR, COLLECTOR
COLLECTOR_MAX_FILE_DESCRIPTORS = 20000
[chiyama@htcondor ~]$
作業環境用のネットワークはintra.example.netという名前にしておきます。また、セントラルマネージャしか動かさないのでMASTER、NEGOTIATOR、COLLECTORの3つだけを動かします。
・計算サーバでの設定
続いて計算サーバです。
[chiyama@worker01 ~]$ cat /etc/condor/condor_config
######################################################################
##
## condor_config
##
## This is the global configuration file for condor. This is where
(中略)
## Install the minicondor package to run HTCondor on a single node
CONDOR_HOST=192.168.0.36
FILESYSTEM_DOMAIN = farm.example.net
UID_DOMAIN = farm.example.net
CONDOR_ADMIN =
SMTP_SERVER =
ALLOW_READ = *
ALLOW_WRITE = *
ALLOW_NEGOTIATOR = *
ALLOW_ADMINISTRATOR = $(IP_ADDRESS)
use POLICY : ALWAYS_RUN_JOBS
WANT_VACATE = FALSE
WANT_SUSPEND = TRUE
PRIVATE_NETWORK_NAME = farm.example.net
DAEMON_LIST = MASTER, STARTD
CCB_ADDRESS = $(COLLECTOR_HOST)
UPDATE_COLLECTOR_WITH_TCP = TRUE
ALLOW_DAEMON = *
[chiyama@worker01 ~]$
ルータをまたいで、192.168.0.36のセントラルマネージャに接続するようにしています。計算サーバはセントラルマネージャやサブミットマシンとは別のネットワークにあるので、FILESYSTEM_DOMAIN、UID_DOMAIN、PRIVATE_NETWORK_NAMEは、全てfarm.example.netとします。また、CCB_ADDRESSの設定も行ない、CCB経由でサブミットマシンと通信するようにします。
・サブミットマシンでの設定
最後にサブミットマシンです。
[chiyama@docker ~]$ cat /etc/condor/condor_config
######################################################################
##
## condor_config
##
## This is the global configuration file for condor. This is where
(中略)
## Install the minicondor package to run HTCondor on a single node
CONDOR_HOST = 192.168.0.36
COLLECTOR_HOST = $(CONDOR_HOST)
FILESYSTEM_DOMAIN = intra.example.net
UID_DOMAIN = intra.example.net
CONDOR_ADMIN =
SMTP_SERVER =
ALLOW_READ = *
ALLOW_WRITE = *
ALLOW_ADMINISTRATOR = $(IP_ADDRESS)
use POLICY : ALWAYS_RUN_JOBS
WANT_VACATE = FALSE
WANT_SUSPEND = TRUE
PRIVATE_NETWORK_NAME = intra.example.net
DAEMON_LIST = MASTER, SCHEDD
SCHEDD_MAX_FILE_DESCRIPTORS = 20000
[chiyama@docker ~]$
サブミットマシンはセントラルマネージャと同じネットワークにあるので、FILESYSTEM_DOMAIN、UID_DOMAIN、PRIVATE_NETWORK_NAMEは、全てintra.example.netとします。また、CCBは必要ないので設定しません。
以上で HTCondorの設定ができました。
[[SplitPage]]ジョブの投入
ジョブを投入するためのSDFは以下のように書きます。
[chiyama@docker ~]$ cat simpleSubmission/simpleSubmission.sdf
executable = /usr/bin/pwd
output = /tmp/pwd.farm.$(Process).out
error = /tmp/pwd.farm.$(Process).error
log = /tmp/pwd.farm.$(Process).log
requirements = TARGET.FileSystemDomain == "farm.example.net" && TARGET.UidDomain == "farm.example.net"
should_transfer_files = yes
when_to_transfer_output = ON_EXIT
transfer_executable = false
queue
[chiyama@docker ~]$
should_transfer_filesをyesにすると、計算に必要なファイルや計算時に生成されたファイルを自動的に転送することができます。その際、transfer_executableをfalseにすることで、executableとして指定した実行ファイルは転送しないということもできます。
より具体的な例として、以下のpythonスクリプトを用意して計算サーバで実行させてみます。
[chiyama@docker simpleSubmission]$ cat test_transfer_file.py
import socket
import sys
import os
print(socket.gethostname())
print(sys.version_info)
print('== os.environ ==')
for k,v in os.environ.items():
print(k, v)
[chiyama@docker simpleSubmission]$
SDFは以下のようにします。
[chiyama@docker simpleSubmission]$ cat test_transfer_file.sdf
executable = /usr/bin/python
arguments = test_transfer_file.py
transfer_input_files = test_transfer_file.py
output = /tmp/test_transfer_file.farm.$(Process).out
error = /tmp/test_transfer_file.farm.$(Process).error
log = /tmp/test_transfer_file.farm.$(Process).log
requirements = TARGET.FileSystemDomain == "farm.example.net" && TARGET.UidDomain == "farm.example.net"
should_transfer_files = yes
when_to_transfer_output = ON_EXIT
transfer_executable = false
queue
[chiyama@docker simpleSubmission]$
ジョブを投入して結果を確認します。
[chiyama@docker simpleSubmission]$ ls /tmp/
hsperfdata_condor systemd-private-964e7e847c6049f4969affec7c6b2875-chronyd.service-hzY4Ma
hsperfdata_root systemd-private-964e7e847c6049f4969affec7c6b2875-cups.service-nGi5kg
lua_DCGcQa systemd-private-964e7e847c6049f4969affec7c6b2875-rtkit-daemon.service-Ly3UWv
[chiyama@docker simpleSubmission]$ condor_submit test_transfer_file.sdf
Submitting job(s).
1 job(s) submitted to cluster 107.
[chiyama@docker simpleSubmission]$ ls /tmp/
hsperfdata_condor systemd-private-964e7e847c6049f4969affec7c6b2875-chronyd.service-hzY4Ma test_transfer_file.farm.0.error
hsperfdata_root systemd-private-964e7e847c6049f4969affec7c6b2875-cups.service-nGi5kg test_transfer_file.farm.0.log
lua_DCGcQa systemd-private-964e7e847c6049f4969affec7c6b2875-rtkit-daemon.service-Ly3UWv test_transfer_file.farm.0.out
[chiyama@docker simpleSubmission]$ cat /tmp/test_transfer_file.farm.0.out
worker01.worker.example.net
sys.version_info(major=2, minor=7, micro=5, releaselevel='final', serial=0)
== os.environ ==
('TMP', '/var/lib/condor/execute/dir_4448')
('_CONDOR_CHIRP_CONFIG', '/var/lib/condor/execute/dir_4448/.chirp.config')
('_CONDOR_JOB_AD', '/var/lib/condor/execute/dir_4448/.job.ad')
('TEMP', '/var/lib/condor/execute/dir_4448')
('_CONDOR_JOB_PIDS', '')
('OMP_NUM_THREADS', '1')
('_CONDOR_ANCESTOR_4202', '4448:1565269153:1707118152')
('_CONDOR_SLOT', 'slot1_1')
('_CONDOR_MACHINE_AD', '/var/lib/condor/execute/dir_4448/.machine.ad')
('_CHIRP_DELAYED_UPDATE_PREFIX', 'Chirp*')
('_CONDOR_ANCESTOR_4169', '4202:1565265263:3485747309')
('BATCH_SYSTEM', 'HTCondor')
('_CONDOR_JOB_IWD', '/var/lib/condor/execute/dir_4448')
('_CONDOR_SCRATCH_DIR', '/var/lib/condor/execute/dir_4448')
('_CONDOR_ANCESTOR_4448', '4452:1565269154:4293891337')
('TMPDIR', '/var/lib/condor/execute/dir_4448')
[chiyama@docker simpleSubmission]$
元々/tmp以下になかったファイルが作成され、/tmp/test_transfer_file.farm.0.outの中を見ると、worker01.worker.example.netでtest_transfer_file.pyが実行され、その結果が戻ってきていることがわかります。
以上で、環境構築ができました。
計算サーバの設定
環境が一段落したところで計算サーバに追加の設定を行なっておきます。
HTCondorでは、何も設定をしないと計算サーバ上で同時に実行できるジョブは計算サーバの論理プロセッサ数になります。しかし、通常は1台の計算サーバで複数のCPUを使用して、ひとつの計算を行いたい場合が多いです。そのための設定をすることができます。
論理プロセッサが4個ある場合、何も設定をしないと以下のように4つのslotが登録されます。
[chiyama@worker01 ~]$ condor_status
Name OpSys Arch State Activity LoadAv Mem ActvtyTime
slot1@worker01.worker.example.net LINUX X86_64 Unclaimed Benchmarking 0.000 247 0+00:00:03
slot2@worker01.worker.example.net LINUX X86_64 Unclaimed Idle 0.000 247 0+00:00:03
slot3@worker01.worker.example.net LINUX X86_64 Unclaimed Idle 0.000 247 0+00:00:03
slot4@worker01.worker.example.net LINUX X86_64 Unclaimed Idle 0.000 247 0+00:00:03
Machines Owner Claimed Unclaimed Matched Preempting Drain
X86_64/LINUX 4 0 0 4 0 0 0
Total 4 0 0 4 0 0 0
[chiyama@worker01 ~]$ fg
計算サーバのcondor_configに以下の記述を追加すると、ひとつの計算ノードとして登録できます。
SLOT_TYPE_1 = 100%
NUM_SLOTS = 1
NUM_SLOTS_TYPE_1 = 1
SLOT_TYPE_1_PARTITIONABLE = True
SlotWeight = Cpus
[chiyama@worker01 ~]$ condor_status
Name OpSys Arch State Activity LoadAv Mem ActvtyTime
slot1@worker01.worker.example.net LINUX X86_64 Unclaimed Benchmarking 0.000 990 0+00:00:03
Machines Owner Claimed Unclaimed Matched Preempting Drain
X86_64/LINUX 1 0 0 1 0 0 0
Total 1 0 0 1 0 0 0
[chiyama@worker01 ~]$
これで、1台の計算サーバで複数のCPUを使用して処理を行うことができるようになりました。
次回予告
今回で社内にあるレンダーファームを作業用の環境から切り離し、あたかも社内にクラウドシステムがあるかのような環境をつくることができました。次回以降、さらに環境構築を進めていきます。 多分、あと2、3回で本格的なクラウド環境構築のお話にたどり着けるのではないかとおもうので、今しばらくお付き合いください。
第16回の公開は、2019年9月を予定しております。
プロフィール
