その他
Pools、Groups、Limitsについて
はじめに
Deadlineは分散型のジョブスケジューリングを使用しており、他のアプリケーションとちょっと違った独特なものになっています。どのネットワークマシン(DeadlineでのSlave)がどのジョブを処理するかを全て決定するマネージャーアプリケーションを使用する代わりに、DeadlineはRepositoryを調べ、ジョブの設定に応じてそのジョブを選択し、処理を行うスマートSlaveを使用しています。これにより重大な脆弱性を解消しています。(集中管理型のマネージャーがクラッシュすると仕事が処理されませんが、分散型の場合Slave100台中99台が停止しても、正しく設定されていれば、残りの1台が生き残っている限り処理が継続されるでしょう。)
このため、スケジューリングに影響するジョブの様々なプロパティについて理解することは、Deadlineを最大限活用する鍵となります。
以下のDeadlineアプリケーションの解説では、スケジューリングやLimitのオプションを詳しく見ていきます。
Deadline Poolsについて
ジョブがSlaveによって、いつどのように選ばれるかに影響を与える主なプロパティがPoolです。Slaveは自動的に「none」Poolになりますが、レンダーファームをより良く構成するために、1つ以上のユーザーが定義したPoolに追加すべきです。
典型的な制作環境においてPoolは主に、あるプロジェクトでレンダリングするジョブが少ない場合にSlaveをアイドル状態にせず、他のプロジェクトで使用するようにしながら、プロジェクトごとにファームを分割するのに使われます。
Poolを理解する鍵は、SlaveのPoolリストに表示されているPoolの順序が重要であるということです。Slaveが3つのPool、「Project A」「Project B」「Project C」に、この順番で追加された場合、Slaveが複数のジョブを見つけた時にProject Aのジョブが他の2つよりも常に優先して割り当てられるようになります。もしProject Aがない場合は、他のものが処理されます。
上記の重要な点は、リソースを無駄にすること無くプロジェクトごとにレンダーファームのSlaveを分割することが出来るということです。例えばSlaveが全部で40台あると仮定します。ファームの半分を使用するProject Aというある重要なプロジェクトには、20台のマシンに第1のPool(最優先)として割り当てます。Project Bという2つ目のプロジェクトには最低15台が使用されるように、またProject Cには最低5台使用されるようにします。そのために15台のマシンにはPool listにおいてProject A、Project Cを2番目、3番目にしてProject Bが選ばれるように設定し、5台のSlaveにはProject A、Project Bを2番目、3番目とし、トップにProject Cを置きます。
アイドル状態のファーム(どのSlaveもレンダリングを開始していない状態)にユーザーがジョブを投入した場合を考えてみましょう。順にSlaveはRepositoryを確認し、Project AがPool名として設定されたジョブを発見します。ファーム上に他のジョブが無く、全40台のSlaveがProject Aをリストに持っているので、リストで異なる順位となっていても40台全てのマシンがこの新しいジョブのレンダリングタスクを実行します。
今Project Bで働いている別のユーザーがファームにジョブを投入した場合、それぞれの処理するタスクが終了したSlaveは次の仕事のためにRepositoryを確認し、そのSlaveにおいてProject BがProject AよりもPoolリストで上位になっていた場合、新しいProject Bのジョブのレンダリングに移ります。Project Bのジョブが一旦終了し、Project Aのジョブでまだ全てのタスクが完了していなかった場合、SlaveはProject Aの処理に戻ります。同様に、全てのProject Aのジョブが完了し、Project Cのジョブもない場合、40台全てのマシンがProject Bの処理を行います。
同様に、あるユーザーがProject Cのジョブを投入した場合、Pool リストの最上位にProject Cが設定されている5台のマシンは、前のタスクが終わり次第そのジョブをレンダリングし始めます。Project AやProject Bが上位にあるSlaveはProject A、Project BのPoolに割り当てられたジョブのタスクを見つけられなかった場合、最優先ではないもののProject CがPoolのリスト中にあるので、Project Cのジョブのレンダリングに参加します。
当然ながら、3つのプロジェクト全てのジョブが存在する場合は、各マシンのPoolのリストの最上位になるジョブにより、プロジェクトごとの配分は20/15/5となります。
以上のように、Slaveのグループに複数のPoolを割り当て、あるPoolが他のPoolより高い優先度のファームの一部でも、マシンをアイドル状態にせず(高い優先度のジョブがなければ低い優先度のジョブを実行)、プロジェクトごとにリソースの優先度を付けることができます。
「none」Poolにジョブを投入すると、全ての Slaveにおいて最低の
優先度となります。ユーザーが定義したPoolに割り当てられた他のジョブがない場合にのみSlaveは「none」Poolのジョブを処理します。
ジョブ優先度の解決
大きなプロジェクトにおいて、同じPoolに投入された数百〜数千のタスクを持つ数百のジョブが存在する場合があります。Slaveが仕事を探す時、大量の実行可能なジョブが見つかります。デフォルトでは、前の項で見たように、DeadlineはPoolの優先度を最初に利用するように設定されており、異なるPoolに割り当てられた2つ以上のジョブが存在する場合、SlaveのPoolリストの最上位のPoolに割り当てられたジョブから処理されます。
しかし、同じPoolに割り当てられた2つ以上のジョブがあった場合はどうなるでしょうか?
Deadlineのデフォルトでは、次にNumeric Priorityを使用します。これはユーザーの判断により緊急度を定義する、ジョブの投入時にジョブに対して0から100で割り当てられる値です。Project AのPoolに割り当てられた3つのジョブがあり、前項の例同様、最優先でProject Aをレンダリングするように設定された20台のSlaveのうちの1台が、3つのジョブのうちどのジョブを開始するか決定する場合にSlaveはPriorityの値を見ます。あるジョブが50で、2つ目のジョブが55、3つ目のジョブが90の場合、当然ながら3つ目が選ばれます。
もしこれらのジョブの2つ、または3つ全てが同じPriorityだったらどうでしょうか? これは、ほとんどのプロダクションの管理者がアーティストにPriorityは最低の値で使うよう言っているため、想像よりもよく起こる状況です。このような場合、Submission Timeが衝突の解決に使われます。(より早く投入されたジョブが先に処理されます。) タイムスタンプは日付、秒までの精度の時間が含んで与えられるので、2つのジョブが厳密に同じPool、Priority、Submission Timeを持つ確率は、天文学的低さです。
一方、DeadlineがPriority>Pool>Dateや、Date>Priority>Poolのように、他の組み合わせで優先順位を解決するよう調整することもできますが、これは推奨しておらず、Deadlineで管理されたファームの大多数がデフォルトのPool>Priority>Dateの順番を使用しています。
制限要素
ジョブの処理順を制御する要素、Priority要素について見て来ました。Pool、Priorityに加えて、ジョブに制限を加えたり.、Slaveが絶対にジョブを取得しないようにするいくつかのプロパティがあります。これら制限を制御するように配置され、異なった目的を持つシステムがいくつかあります。
Groups
GroupsはDeadlineの歴史において比較的遅くに追加されました。一般に同様のハードウェアあるいは同様のソフトウェア環境のSlaveによる特定のサブセットにジョブの処理を制限するのに使われています。Poolと比較するとGroupはジョブのスケジューリングに影響せず、ジョブに最も適合した特定のSlaveのグループを素早く取捨選択するためのものです。
例えば、16Core/RAM 32GBの全てのSlaveを「SimMachines」というグループにリストするとし、一方4Core/8GBのマシンを「TheSlowOnes」というグループにします。ユーザーが使える限りのCPUコアやメモリを使用する流体シミュレーションのジョブを投入する時に、「SimMachines」 Groupを選択するようにします。これにより確実に適切なハードウェア環境を持つSlaveだけがジョブを処理するようにできます。ジョブが前項の例で想定したProject Aの一部として投入され、もう一つ同様のシミュレーションのジョブがProject Bの一部として投入された場合、PoolやPriorityによるスケジューリングが解決されるのに加え、Slaveは「SimMachines」Groupについても確認し、自身がそのリストに載っている場合にのみ、そのジョブを処理し始めます。このように、GroupはPoolの上位にもう一つ制御レイヤーを付与します。もう一つの例として、Autodesk Mayaがインストールされている全てのSlaveを「Maya」Group、Autodesk 3ds Maxがインストールされている全てのSlaveを「3dsMax」Groupに追加します。両方の3Dアプリケーションがインストールされているマシンの場合は、両方のGroupに入ります。あるユーザーがMayaからジョブを投入する場合、実際にそのソフトウェアがインストールされたマシンだけがジョブを処理することを確実にするため、Maya Groupを選ぶことができます。
Limits
Limitは特にソフトウェアライセンスの管理をするための特別なStub(チケットの半券)ベースのシステムです。簡単に言えば、Limitsは様々なアプリケーションやプラグインの使用可能なライセンス数を表すものです。Slaveがひとつ以上のLimitが割り当てられているジョブのタスクをキューから取り出そうとするときは常にLimitからStubを得なければなりません。結果として各Limitにおいて利用できるStubの全体の数は一つづつ減り、それが0に到達すると、次のSlaveはStubを得ることができなくなり、既にライセンスを使用している他のSlaveがタスクを完了し、Stubを返すまで、タスクを処理しません。
例えば、Mayaのフローティングライセンスを20本有していて、40台のマシンにMayaがインストールされている場合に、同時に動くMayaの数を20本に制限したいとします。「Maya」Limitを全部で20に設定し、「Maya」 Limitを割り当てて投入したジョブのタスクを21番目のSlaveが処理しないようにできます。これによりライセンスに関連する失敗を防ぐことができます。またこの機能から任意のSlaveを除外することができます。(例えばそれらがアプリケーションのノードロックライセンスを持っている場合など) あるいは、任意のSlaveがスタブを取得しないようブラックリスト化することもできます。(例えば適切なソフトウェアがインストールされていない場合)
BlacklistとWhitelist
BlacklistはジョブをレンダリングさせないSlaveを名前により明示的に指定するジョブのプロパティです。Blacklistは事前に作成されませんが、ジョブが投入される前、または後に割り当てられます。これはレンダリング中に便利です。(Slaveにエラーが発生したり、何らかの理由で望んだ出力結果が出ていない場合に、Monitor中のジョブを右クリックし、そのマシンをBlacklistにするようジョブに指示をし、再度そのジョブに触らないように出来ます。)
Wintelistはどのマシンがジョブをレンダリングするのかを明示的に許可するリストです。これは、そのジョブに向かないマシンの数よりもレンダリングが行えるマシンの数がかなり少ない場合に役に立ちます。
Job Machine Limit
Job Machine Limitは同時にジョブを実行する全体のSlaveの数を指定するプロパティです。これはどのマシンかを厳密に制御せず、Slaveがジョブを選択するためのシンプルな最初の条件です。もしMachine Limitに達していた場合、Slaveは他のすべての条件に合致していても、ジョブを処理しません。Machine Limitが0に設定された場合、他の全ての条件に合致したSlaveはジョブを処理します。数百台で構成されるレンダーファームにおいて、全く制限をしないジョブは同時に過剰な台数のマシンがジョブの処理を行う原因となり、これによりある場合において、ネットワークの重大な障害の原因となります。例えば、3Dアプリケーションが最初のフレームをレンダリングする前に、ネットワークからシーンやテクスチャマップ、キャッシュなどの関連する外部参照ファイルを読み込まなければならない場合、100台以上のマシンが一斉にこれらのファイルにアクセスするというのは問題があります。これに対し、Machine Limitはタスクの進捗状況が一定のパーセンテージとなった後、制限が解除されるように設定することもできます。よって、タスクが5%に達するまでの間だけMachine Limitを10としてジョブに適用することができます。一旦Slaveがそのパーセンテージに達するとLimitから除外され、別のもう一つのSlaveがジョブを処理する事ができるようになります。このように、ネットワーク負荷を減少し、一度には少しづつだけ追加して数百台のSlaveを参加させられます。
設定のテスト
以前のバージョンのDeadlineでは、スケジューリングのオプションとLimitはレンダー時のSlaveにのみ適用されていました。いくつかの場合、特に数百のSlaveと数千のジョブを持つ大きなレンダーファームにおいて、ジョブの設定がどのようにそれを処理するSlaveの数に影響するか判断するのは容易ではありませんでした。
Deadline5ではSlave Listの左上コーナーに「Show Slaves That Can Render The Selected Job」フィルターオプションが追加されました。このオプションがチェックされている場合、この文書で述べたルールが利用可能なSlaveに適用され、Pools、Groups、LimitsやBlacklist/Whitelistによってハイライトされたジョブを実際に処理するSlaveだけがリストに表示されます。これにより、実際にレンダリングが実行される前にジョブとレンダーファームの設定を検査するのが簡単になり、なぜジョブのレンダリングが開始されないのか分かるようになります。
まとめ
以上のように、Deadlineは小規模から大規模なネットワーク環境においてリソースやジョブの優先度を管理する強力なツールを提供しています。ハードウェアやソフトウェアを最大限活用するために、これらのプロパティや制御を組み合わせて使うことができます。我々はこの文書があなたの日々の制作作業において、Deadlineのポテンシャルを開放し、あなたの助けとなることを願っています。