翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
サービスマネージドフリートの永続的ストレージ
AWS Deadline Cloud (Deadline Cloud) 永続ストレージは、ルートブートボリュームとは別に、サービスマネージドフリート (SMF) ワーカー専用の Amazon Elastic Block Store (Amazon EBS) ボリュームを提供します。これらのボリュームは、ワーカーのライフサイクルイベント全体でデータを保持します。永続的ストレージでは、定期メンテナンスまたはスケーリングオペレーション中にワーカーが置き換えられた場合でも、conda パッケージのインストール、アプリケーションキャッシュ、アセットファイルは引き続き使用できます。
永続的ストレージの仕組み
サービスマネージドフリートで永続ストレージを有効にすると、Deadline Cloud はワーカーの Amazon EBS ボリュームのライフサイクルを自動的に管理します。
-
ワーカーが起動すると、Deadline Cloud は同じアベイラビリティーゾーンで使用可能な Amazon EBS ボリュームを作成または再利用し、そのボリュームをワーカーにアタッチします。
-
Deadline Cloud はボリュームをフォーマットし (新しい場合)、フリート設定で指定したパスにマウントします。
-
ワーカーが終了または置き換えられると、Deadline Cloud はボリュームをデタッチし、同じフリートとアベイラビリティーゾーンの将来のワーカーが再利用できるようにします。
ボリュームは同じフリートとアベイラビリティーゾーン内で再利用されるため、後続のワーカーは以前にボリュームに書き込まれたデータからメリットを得られます。ボリュームは、ワーカー間で競合することなく、専用帯域幅と IOPS を提供します。
注記
永続的ストレージは、サービスマネージドフリートでのみ使用できます。カスタマーマネージドフリートの場合は、独自のストレージインフラストラクチャを管理します。
永続的ストレージの利点
永続的ストレージは、サービスマネージドフリートワークロードに次の利点をもたらします。
-
ジョブの起動の高速化 – Conda パッケージのインストール、コンパイルされたシェーダー、および処理されたアセットは、ワーカーの置き換え後も保持されるため、ダウンロードとインストールの繰り返しがなくなります。
-
専用パフォーマンス – 各ワーカーは、専用 IOPS とスループットを備えた独自の Amazon EBS ボリュームを受け取り、共有ネットワークストレージで発生する競合を回避します。
-
自動管理 – Deadline Cloud は、手動での介入を必要とせずに、ボリュームの作成、アタッチメント、フォーマット、マウント、クリーンアップを処理します。
-
ランタイム統合 – conda キュー環境や仮想ファイルシステム (VFS) イミュータブルキャッシュなどのサポートされているランタイムコンシューマーは、使用可能な場合、ジョブ設定を変更することなく、自動的に永続的ストレージを使用します。
-
コスト管理 – 未使用のボリュームを自動的にクリーンアップし、アイドル期間中のストレージコストを削減するようにtime-to-live (TTL) を設定します。
永続ストレージを使用するタイミング
以下のシナリオでは、サービスマネージドフリートの永続ストレージを有効にすることを検討してください。
-
ジョブは、ダウンロードとインストールにかなりの時間がかかる conda パッケージを使用します。
-
レンダリングワークロードはシェーダーをコンパイルするか、後続のレンダリングで再利用できるアセットを処理します。
-
ワークスペースの同期状態によって後続の更新時のデータ転送が減少する Perforce またはその他のバージョン管理システムを使用します。
-
ジョブは仮想ファイルシステム (VFS) を使用し、永続的なイミュータブルなアセットキャッシュからメリットを得られます。
-
共有ネットワークファイルシステムの管理に伴う運用上のオーバーヘッドなしで、専用のストレージパフォーマンスが欲しい。
-
カスタムレンダラーやその他のソフトウェアをホスト設定スクリプトを介してワーカーにインストールし、それらのインストールを永続ボリュームにキャッシュするようにします。
フリートの永続ストレージの設定
永続ストレージは、新しいサービスマネージドフリートを作成するとき、または既存のフリートを更新するときに設定できます。
永続的ストレージの設定 (コンソール)
開始する前に、少なくとも 1 つのサービスマネージドフリートを持つ既存のファームがあるか、新しいフリートを作成する準備ができている必要があります。
フリートの永続ストレージを設定するには
-
AWS マネジメントコンソールにサインインし、Deadline Cloud コンソール
を開きます。 -
ナビゲーションペインで、ファームを選択し、ファームを選択します。
-
フリートタブを選択し、フリートの作成を選択するか、既存のサービスマネージドフリートを選択して編集を選択します。
-
ストレージ機能で、ストレージモード で、永続ストレージを選択します。
-
ブートボリュームのルートストレージ設定 (サイズ、IOPS、スループット) を設定します。
-
永続ストレージで、次の設定を行います。
-
サイズ – 永続ボリュームのサイズ。有効な範囲は 1~65,536 GiB です。デフォルトのサイズがレンダリングワークロードに適していることを確認し、より大きなアセットまたはキャッシュを使用するワークフローのボリュームサイズを増やすことを検討してください。
-
マウントパス – ボリュームがワーカーにマウントされる絶対パス ( の場合など
/mnt/persistentLinux)。Windows ワーカーの場合は、 などのドライブ文字を指定しますD:。 -
スループット – ボリュームのプロビジョニングされたスループット。有効な範囲は 125~2,000 MiB/秒です。
-
最大アイドル時間 – 使用可能なボリュームが削除されるまでにアイドル状態で待機できる時間。ドロップダウンから値を選択します (12 時間など)。
-
IOPS – ボリュームのプロビジョニングされた IOPS。有効な範囲は 3,000~80,000 IOPS です。IOPS は 4 倍以上のスループットである必要があります。
-
-
残りのフリート設定ステップを完了し、フリートの作成または変更の保存を選択します。
永続ストレージの設定 (AWS CLI)
AWS Command Line Interface (AWS CLI) を使用して永続ストレージを設定するには、フリートを作成または更新するときにフリート設定に persistentVolumeConfigurationパラメータを含めます。
次の例では、永続ストレージが有効になっているフリートを作成します。
{ "configuration": { "serviceManagedEc2FleetConfiguration": { "instanceCapabilities": { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 16384, "max": 32768}, "osFamily": "LINUX" }, "instanceMarketOptions": { "type": "spot" }, "persistentVolumeConfiguration": { "sizeGiB": 2048, "iops": 16000, "throughputMiB": 500, "mountPath": "/mnt/persistent", "lastUsedTtlHours": 168 } } } }
ランタイム統合
永続的ストレージがワーカーに正常にマウントされると、Deadline Cloud はDEADLINE_PERSISTENT_MOUNT環境変数を設定済みのマウントパスに設定します。次のランタイムコンシューマーは、環境変数が存在する場合、永続的ストレージを自動的に使用します。
-
Conda キュー環境 – パッケージのインストールは永続ボリュームに保存されるため、後続のワーカーは、以前にインストールされたパッケージをダウンロードして再度インストールするのではなく、再利用します。
-
仮想ファイルシステム (VFS) イミュータブルキャッシュ – VFS はイミュータブルアセットキャッシュを永続ボリュームに保存するため、以前にダウンロードしたアセットは Amazon Simple Storage Service (Amazon S3) から再ダウンロードすることなく使用できます。
独自のジョブテンプレートとスクリプトで DEADLINE_PERSISTENT_MOUNT環境変数を使用して、ワーカーライフサイクルイベント全体で保持されるデータを保存することもできます。
永続ボリュームの管理
Deadline Cloud コンソール、、または API を使用して AWS CLI、フリートの永続ボリュームを表示および管理できます。次のオペレーションを使用できます。
-
ボリュームを一覧表示する – 状態、サイズ、アベイラビリティーゾーンなど、フリートに関連付けられているすべての永続ボリュームを表示します。
-
ボリュームの詳細の取得 – 現在の状態、アタッチメントのステータス、設定など、特定のボリュームに関する詳細情報を取得します。
-
ボリュームの削除 – 不要になったアタッチされていない永続ボリュームを完全に削除します。現在ワーカーにアタッチされているボリュームは削除できません。
永続的ストレージ設定の更新
既存のフリートの永続的ストレージ設定を更新できます。以下の変更がサポートされています。
-
IOPS とスループット – Deadline Cloud は、次にボリュームをワーカーにアタッチするときに変更を適用します。
-
ボリュームサイズ (増加のみ) – Deadline Cloud は、次のアタッチメントの前にボリュームを拡大します。ボリュームサイズを小さくすることはできません。
-
永続的ストレージを無効にする – Deadline Cloud は、既存のボリュームがワーカーにアタッチされなくなったときに、それらのボリュームを自動的にクリーンアップします。
重要
設定の変更は、既存のワーカーには影響しません。変更は、更新後に起動する新しいワーカーにのみ適用されます。
暗号化
永続ボリュームは、ファームレベルで設定された暗号化設定を使用します。ファームにカスタマーマネージド AWS Key Management Service (AWS KMS) キーを設定した場合、永続ボリュームはそのキーで暗号化されます。それ以外の場合、永続ボリュームはサービス所有のキーで暗号化されます。
考慮事項
永続ストレージを使用する場合は、次の考慮事項に注意してください。
-
永続的ボリュームはキャッシュの最適化であり、耐久性のあるプライマリストレージではありません。永続ボリュームは、パッケージのインストール、コンパイルされたシェーダー、アセットキャッシュなど、再作成できるデータにのみ使用します。Deadline Cloud はいつでもボリュームを置き換えることができ、永続ボリュームに直接アクセスすることはできません。
-
Deadline Cloud は、永続的ボリュームを使用するようにワーカーのホームディレクトリを設定します。ホームディレクトリにデータを保存するソフトウェア (conda パッケージやアプリケーションキャッシュなど) は、永続化によって自動的にメリットが得られます。ソフトウェアがホームディレクトリ外のパスに書き込む場合は、永続的なマウントパスを使用するように再設定する必要があります。そうしないと、これらのファイルはワーカーライフサイクルイベント全体で保持されません。
-
永続ボリュームは複数のワーカーに同時にアタッチされません。各ボリュームは一度に 1 人のワーカーを処理しますが、ライフサイクルイベント全体で異なるワーカーによって再利用されます。
-
ボリュームは、特定のフリートとアベイラビリティーゾーンに限定されます。1 つのアベイラビリティーゾーンで作成されたボリュームを、別のアベイラビリティーゾーンのワーカーが再利用することはできません。
-
特定のワーカーは、以前に使用したものと同じボリュームを受け取るとは限りません。同じフリートとアベイラビリティーゾーンで使用可能なボリュームを割り当てることができます。
-
永続的ストレージをプロビジョニングできない場合 (クォータの制限など)、ジョブは失敗します。ワーカーは、永続的ストレージなしでは実行にフォールバックしません。
-
永続ストレージには、アクティブなボリュームの数とその設定に基づいて課金されます。アイドル期間中のコストを制御するには、TTL を設定するか、フリートから永続的ストレージ設定を削除します。