>   >  痴山紘史の日本CG見聞録:第19回:クラウド環境構築[ローカル環境とクラウト環境の連携]
第19回:クラウド環境構築[ローカル環境とクラウト環境の連携]

第19回:クラウド環境構築[ローカル環境とクラウト環境の連携]

みなさんこんにちは。早いもので今年ももう終わりです。この1年間、有意義に過ごすことができたでしょうか? 私は先日発売されたRyzen 3950Xを入手してホクホクです。今回からは心機一転、Ryzenマシン上に環境構築をして記事を書いていきます。

TEXT_痴山紘史 / Hiroshi Chiyama(日本CGサービス
EDIT_尾形美幸 / Miyuki Ogata(CGWORLD)

ローカル環境とクラウド環境で連携して処理を行う

前回まででHTCondor Annexを使用したクラウド環境の構築、AWSのS3を使用したファイルサーバの構築、そしてAWS SFTPサーバを使用したファイルの転送という、クラウド上で処理を行うために必要な3つの環境構築が一通りできました。今回は、この環境とローカル環境を連携させて各種ジョブを実行できるようにしていきます。

社内インフラとクラウド環境を連携させて使用するためには、社内のデータのクラウド上へのアップロードと、クラウド上で作成されたデータのダウンロードが必要となります。まずはここを考えてみます。

よくある要望として、社内のファイルサーバとクラウド上のサーバとが自動的に同期をとり、常に両方の環境に最新のデータが全て用意されるようにしてほしいというものがあります。これは、プロダクションでクラウド環境をつくる場合に、まずまちがいなく上がってくる要望です。ユーザーからすれば、最近は計算機もネットワークも速いし、それくらいチョチョイッとできるでしょ? という感じの軽い気持ちでの要望だったりするのですが、まずまちがいなくまともに実現できないと考えた方がよいです。以前、実証実験を行なった際には3TBのデータを転送するために約1週間を要し、その上システムに負荷がかかることでほかの問題を引き起こし、通常業務にも少なからぬ影響をおよぼすことになりました(※)。

※ 平成25年度 我が国経済社会の情報化・サービス化に係る基盤整備 (CG・VFX産業クラウド活用・高連携実証事業)P. 38
www.dcaj.or.jp/project/report/pdf/2013/dc_13_01.pdf

これでは気軽にクラウド環境を使うのは難しいです。そこで最近のクラウドレンダリングサービスでは、レンダリングジョブを投げるためのツールを用意し、その中でシーンで使用しているファイルを自動的に集めて転送する機能が用意されています。この方法はとてもお手軽で、個人で使用するには効果的です。

本連載ではもう一歩進んで、チームの誰かが一度でもファイルをアップロードしたら、ほかのメンバーはアップロード済みのデータを流用できるようなしくみをつくっていきます。

しくみをつくるためには、いくつかルールを決める必要があります。今回は、あまり開発に負荷をかけずに実現できる方法を探っていきます。

構築したシステムの微調整

本題に入る前に、記事を書き進める中で、これまで構築した環境にいくつか問題が見つかったので、微調整します。


・s3fsのマウント方法修正

s3fsは、Roleの指定方法によっては/etc/fstabにマウントポイントを記述する方法では正常にマウントができないようです。その場合、/etc/rc.localでマウントします。また、このときにhtcondorプロセスを実行しているのと同じuid, gid(condor, condor)でマウントしておきます。

[ec2-user@ip-172-31-89-155 condor]$ cat /etc/rc.local
#!/bin/bash
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.

touch /var/lock/subsys/local

/usr/bin/s3fs condorannexdata /gs -o passwd_file=/etc/passwd-s3fs,rw,allow_other,uid=996,gid=993
[ec2-user@ip-172-31-89-155 condor]$

この場合、コメントに書かれているようにchmod +x /etc/rc.d/rc.localを実行することを忘れないようにします。


・condor_annexのオプション調整

condor_annexで起動したインスタンスで実行できるジョブは、ユーザー名によって制限をかけることができます。複数人でクラウド環境を使用する場合に必要な機能ですが、現時点ではユーザー管理関連の設定を省略してしまっている関係で都合が悪いので調整が必要です。今回はcondor_annexに-no-ownerオプションをつけることで制限を撤廃しました。


・計算ノードで実行するプロセスのオーナーを変更

ユーザー情報がきちんと管理されていれば、計算ノード上で実行するプロセスはジョブのオーナーと同じアカウントで実行されます。しかし、今のところわれわれはユーザー情報の管理を行なっていないため、condor_annexのデフォルトで指定されている、slot1~slot32というユーザーで各スロットのジョブが実行されてしまいます。これはアクセス権の問題などで困ったことになってしまうため、ジョブも全てcondorアカウントで実行するようにします。

そのために、セントラルマネージャで用意している計算ノード用の設定を追加します。

-bash-4.1$ cat condor-8.8.5/etc/condor.aws/01slot-users.config
 SLOT1_USER = condor
 SLOT2_USER = condor
 SLOT3_USER = condor
 SLOT4_USER = condor
 SLOT5_USER = condor
 SLOT6_USER = condor
 SLOT7_USER = condor
 SLOT8_USER = condor
 SLOT9_USER = condor
SLOT10_USER = condor
SLOT11_USER = condor
SLOT12_USER = condor
SLOT13_USER = condor
SLOT14_USER = condor
SLOT15_USER = condor
SLOT16_USER = condor
SLOT17_USER = condor
SLOT18_USER = condor
SLOT19_USER = condor
SLOT20_USER = condor
SLOT21_USER = condor
SLOT22_USER = condor
SLOT23_USER = condor
SLOT24_USER = condor
SLOT25_USER = condor
SLOT26_USER = condor
SLOT27_USER = condor
SLOT28_USER = condor
SLOT29_USER = condor
SLOT30_USER = condor
SLOT31_USER = condor
SLOT32_USER = condor

STARTER_ALLOW_RUNAS_OWNER = TRUE
DEDICATED_EXECUTE_ACCOUNT_REGEXP = slot[0-9]+

-bash-4.1$

以上三点を修正します。

ファイル管理ルールを決める

ローカルとクラウドのディレクトリ構成を決めます。

ローカルの作業環境とAWS上のインスタンスの両方に/gsディレクトリを用意します。ローカル環境の場合は/gsはローカルのファイルサーバを参照し、インスタンスではS3上のデータをs3fsでマウントします。

また、ローカル環境ではS3上のデータをs3fsで/s3fsディレクトリにマウントします。

環境構築

環境構築は、これまでやってきた方法を組み合わせるだけで実現できます。PublicなIPアドレスをもった環境にセントラルマネージャを置き、クラウド上の計算ノードとローカルの計算ノードの両方を参加させます。以下では、AWS上の計算ノードが2つ、ローカルの計算ノードが1つ、同じプール上に登録されています。


ローカル環境では、前述の通り/gsと/s3fsを用意します。

[neo@matrix ~]$ ls /gs
[neo@matrix ~]$ ls /s3fs
foobar  Kitchen_set  test2  test3  WinSCP
[neo@matrix ~]$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
(中略)
s3fs on /s3fs type fuse.s3fs (rw,relatime,user_id=0,group_id=0,allow_other)
[neo@matrix ~]$

AWS上のインスタンスでは/gsのみを用意します。

[ec2-user@ip-172-31-86-188 ~]$ ls /gs
foobar  Kitchen_set  test2  test3  WinSCP
[ec2-user@ip-172-31-86-188 ~]$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
(中略)
s3fs on /gs type fuse.s3fs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
[ec2-user@ip-172-31-86-188 ~]$

次ページ:
aws cliのセットアップ

その他の連載