現在は1人の編集者向け、将来は小規模チーム向けの10GbE編集環境の構築方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Build a 10GbE Editing Setup for One Editor Today and a Small Team Later - Zima Store Online

最初の10GbE編集席を、ストレージからワークステーションまで一貫した完全な経路として構築しつつ、スイッチ、共有、ユーザー認証、容量設計は後から編集者を増やせるようにしておきます。

ソロクリエイターが初日からスタジオ規模のネットワークを導入する必要はありません。重要なのは、2台目の編集席が登場したときに作り直さなければならない特殊な構成にならないよう、最初のワークステーションを設計することです。共有メディアには信頼できる単一のサーバー経路を用意し、交換可能なキャッシュは分離し、拡張可能なネットワークトポロジーを採用し、共有フォルダーのマウント方法を標準化します。また、編集用ストレージプールに依存しない復旧経路によって完成した作業を保護します。

2台目の編集席が増えても意味を保てる役割から始める

初期構成に必要なのは、いくつかの持続的な役割だけです。1台のクリエイターサーバーが共有カメラメディアとプロジェクトアセットを保持し、1台のワークステーションで編集を行い、可能な範囲でローカルの高速ストレージが破棄可能なキャッシュを処理し、独立した保存先が信頼できるプロジェクトデータを保護します。ハードウェアが変わっても、これらの役割は安定しているべきです。

現在クライアントが1台しかないからといって、最初のワークステーションをメディアの恒久的な所有者にしないでください。そうすると後から移行が難しくなります。2人目の編集者がアクセスする必要が生じた時点で、プロジェクトパス、キャッシュの保存場所、権限、バックアップジョブをすべて同時に変更しなければならなくなるためです。

共有メディア設計は、ストレージ経路をより高速な外付けドライブではなく、チームのリソースとして扱うことで役立ちます。ProVideo Coalitionによる複数ユーザー向けNASメディア制作の解説では、容量とスループットを1台のベンチマーク用ワークステーションだけでなく、同時接続するクライアントを基準に計画する必要性が示されています。

ストレージから編集者までの完全な経路としてネットワークを構築する

サーバーの10GbEポートは、トポロジーの一端にすぎません。実際の経路は、サーバーNIC → ケーブルまたはトランシーバー → 10GbE対応スイッチまたは直接リンク → クライアントアダプターまたはNIC → ワークステーション → 共有ファイルシステムです。すべての経路で、想定したリンク速度を維持する必要があります。

編集者が1人だけなら、ワークステーションとサーバーが通常のLANアクセスも維持できる場合、10GbEの直接接続は有効なスタート構成になります。ただし小規模チームを目指すなら、後からスイッチを追加しても使い続けられるアドレス設計と共有名を選んでください。物理的な経路が変わっても、編集者は同じ論理共有をマウントし続けられるべきです。

TechRadarの最近のネットワーク編集テストでは、NASを高速な編集用ターゲットとして動作させる前に、10GbEスイッチと互換性のあるワークステーションアダプターの両方が必要でした。これは、10GbEはストレージボックスだけでなく経路全体に必要であることを示しています。

共有メディア、プロジェクト状態、ローカルキャッシュを分離する

信頼できるカメラオリジナル、共有グラフィック、音声、納品物は、すべての編集者が一貫してアクセスできるサーバー経路に保存します。プロジェクトデータベースやライブラリをどこに置くかは別途決めてください。一般的なメディアファイルとは異なる共同作業の仕組みを求める編集アプリケーションもあるためです。

アプリケーションが対応している場合、キャッシュ、プレビューのレンダリング、波形、コンフォームファイルなど、再構築可能な状態はローカルNVMeに置くのが適しています。これにより、頻繁に書き換えられる一時データを共有プールから遠ざけながら、失われたら取り戻せない映像素材をワークステーションだけに置くことを避けられます。

頻繁に書き換えられるキャッシュには、共有カメラメディアと同じストレージ上の役割は必要ありません。現在のプロビデオ向けストレージ構成では、高速キャッシュとアクティブメディア、アーカイブ容量を分離しており、再構築可能な作業状態をNVMeに保持しながら、信頼できるすべてのファイルをフラッシュストレージへ移す必要がないことを示しています。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

共同作業の前に共有名、ユーザー認証、プロジェクトパスを標準化する

2人目の編集者が参加する前に、正規のサーバー名、共有プロジェクトルート、予測可能なフォルダー構成を1つずつ決めておきます。すべてのワークステーションで同じ論理共有名をマウントし、特定のユーザーのデスクトップ、リムーバブルドライブのボリューム名、ホームディレクトリに依存するパス規則は避けてください。

編集者が1人しかいない段階でも、個別のユーザーアカウントを作成します。最初のユーザーには広範な作業権限を付与できますが、2人目の編集者、アシスタント、読み取り専用のレビュー担当者にも、全員に同じ管理者認証情報を渡すことなく対応できる構造にしておきます。

目的は、別のワークステーションでプロジェクトを開いても、大規模な再リンクなしで同じ共有メディアを解決できるようにすることです。CineDの共同編集システムに関する記事では、編集者間で共有ストレージを使うワークフローの必要性が説明されています。このワークフローのNAS側における前提条件が、安定したユーザー認証とパスです。

バックアップとアーカイブをアクティブな編集トポロジーの外部に保つ

RAIDを使用していても、編集用プールは主要な作業ストレージにすぎません。別のストレージターゲットに2つ目のコピーを用意し、重要なチャンネル素材やクライアントアーカイブには、アクティブなサーバーの損失、削除、再構成に耐えられる復旧経路を用意してください。

最初のプロジェクトを完了する前に、ライフサイクルを定義します。アクティブサーバーへ取り込み、共有メディア上で作業し、公開または納品し、完了したプロジェクトをアーカイブポリシーに従って移動し、その価値に応じて独立したバックアップコピーを保持します。アーカイブは、インタラクティブな操作時と同じ低レイテンシーを必要としないため、より低速で大容量のストレージに置くことができます。

Richard Lackeyのポストプロダクション向けストレージワークフローでは、高速な作業用ストレージとバックアップ、長期アーカイブを分離しています。これは、編集、バックアップ、アーカイブは異なる役割であることを裏付けています。

2人目の編集者には、最初の席を再設計せず共有容量を増やして対応する

2人目の編集者が加わったとき、物理トポロジーは拡張されるべきであり、役割を変えるべきではありません。10GbEスイッチを中心に配置し、両方の編集用ワークステーションを高速なクライアントリンクで接続し、クリエイターサーバーを信頼できる共有メディアのエンドポイントとして維持します。特定の共同作業機能で必要とされない限り、ローカルキャッシュはローカルに置いたままにします。

サーバー側は、合計需要に合わせて容量を決めます。2人の編集者がそれぞれ中程度のメディアを読み込む場合、必ずしも20GbEが必要とは限りません。しかし、両方のワークステーションで重いマルチカム再生、インポート、レンダリング、大容量コピーを同時に行うと、単一の10GbEアップリンクが共有帯域の上限になる可能性があります。

実際のプロジェクトを1つ使い、続いて2つの同時ワークロードを実行してトポロジーを検証します。SmallNetBuilderの10GbEテスト手法は、次にどの層をアップグレードすべきか判断する前に、ネットワークとストレージのテストを分離すべき理由を示しています。

両方のワークステーションが同じパスと権限を使用し、ストレージプールが想定した同時編集を維持でき、バックアップが独立していれば、その構成は小規模チームへの拡張に対応できています。ネットワークリンクが正常なのに共有編集の性能が不足する場合、次に検討すべきなのは別のトポロジー再設計ではなく、ZimaSpaceの10GbE NASのボトルネック診断です。