VFX- и 3D-рендеринг-студии с NetDrive — рендер-фермы без локальных копий

Среднего размера VFX-студия хранит свою библиотеку шотов в Google Cloud Storage — закэшированные симуляции жидкости, последовательности кадров EXR и общую библиотеку текстур, которая уже превышает 30 ТБ в активных проектах. Каждому рендер-узлу на ферме нужен доступ на чтение к этой библиотеке, но загрузка всего рабочего набора на каждую машину перед запуском задачи впустую расходует место на диске, которое могло бы использоваться под локальные временные файлы, и задерживает каждый рендер на время синхронизации. Монтирование бакета как диска с помощью NetDrive позволяет каждому узлу читать по требованию именно те кадры и текстуры, которые нужны конкретной задаче, без предварительного шага копирования.

Монтировать облачное хранилище на всей рендер-ферме

NetDrive показывает Google Drive, OneDrive, S3, SFTP, WebDAV и другие хранилища как обычные диски в Windows и macOS — без синхронизации и полной загрузки файлов.

• Диски только для чтения не дают рендер-узлам изменять исходные ресурсы
• Настройки размера кэша до 1 ТБ сглаживают повторные обращения к текстурам
• Автомонтирование при загрузке держит диски готовыми без пользовательского сеанса

WindowsmacOS

Скачать NetDrive →

Бесплатный пробный период. Доступны бессрочная лицензия и подписка.

Почему доступ по требованию лучше предварительной синхронизации

Узлы рендер-фермы обычно настраиваются одинаковыми и взаимозаменяемыми — исходное допущение состоит в том, что любой узел может взять любую задачу. Это противоречит идее предварительной синхронизации всей библиотеки ресурсов на локальный диск, потому что, как только задача может оказаться на любом из пятидесяти узлов, либо всем пятидесяти нужна полная локальная копия (огромное, постоянно устаревающее дублирование), либо перед каждой задачей должен выполняться шаг синхронизации, добавляющий минуты простоя к рендеру, который может занимать всего секунды на кадр.

NetDrive монтирует бакет Google Cloud Storage как сетевой диск или диск только для чтения, и движок рендеринга видит обычный путь к файлу вроде R:\assets\textures\. Кадры и текстуры передаются только тогда, когда задача действительно их читает, а кэширование NetDrive держит недавно использованные файлы доступными для следующей задачи, которой нужна та же текстура, без повторной загрузки из бакета каждый раз.

Настройка диска ресурсов только для чтения для рендер-узлов

1. Откройте NetDrive и нажмите + Add Drive в Drive Manager.
2. Выберите Google Cloud Storage из списка провайдеров.
3. Введите учётные данные сервисной учётной записи, ограниченные бакетом библиотеки шотов — для узлов, которые только потребляют ресурсы, достаточно роли IAM только для чтения.
4. Введите имя бакета.
5. В поле Drive Type выберите Read-only drive. Рендер-узлам незачем записывать обратно в бакет с исходными ресурсами, а монтирование только для чтения исключает возможность того, что неверно настроенная задача случайно перезапишет общую текстуру.
6. Установите Mount on в значение Boot, поскольку рендер-узлы работают как автономные машины, а не как рабочие станции с активным входом в систему.
7. В настройках диска увеличьте размер кэша — NetDrive поддерживает размер кэша от 100 ГБ до 1 ТБ (добавлено в версии 3.16.589), что важно для рендер-узлов, многократно обращающихся к одному и тому же набору текстур на протяжении многих кадров последовательности.
8. Нажмите Mount.

Запись кадров обратно без остановки рендера

Доступ на чтение покрывает текстуры и кэши симуляций, но готовым кадрам всё равно нужно куда-то попасть. Второй диск, смонтированный на чтение-запись к выходному бакету, решает эту задачу. Режим фоновой загрузки NetDrive сначала записывает готовые кадры в локальный кэш, а затем асинхронно загружает их в Google Cloud Storage, так что процесс рендеринга переходит к следующему кадру, вместо того чтобы простаивать на сетевом вводе-выводе при каждой записи.

Такое разделение — только чтение для общей библиотеки ресурсов и чтение-запись с фоновой загрузкой для вывода — не даёт двум потокам данных мешать друг другу. Рендер-узел, читающий текстуру 4K, не конкурирует с собственной очередью вывода кадров за одну и ту же семантику подключения.

Масштабирование на множество узлов

Поскольку каждый узел монтирует один и тот же бакет независимо, увеличение мощности фермы сводится к настройке ещё одной машины с той же конфигурацией диска NetDrive, а не к согласованию конкуренции за общее хранилище. Узлы, уходящие в офлайн посреди задачи, не оставляют общую файловую систему в противоречивом состоянии, поскольку каждый хранит только собственный локальный кэш — сам бакет остаётся единственным источником истины.

Для студий со смешанными средами один и тот же бакет монтируется одинаково на рендер-узлах Windows и рабочих станциях художников на macOS, поэтому художник, просматривающий шот, обращается к той же структуре путей, по которой рендерила ферма.

Итог

Монтирование облачного хранилища как диска позволяет рендер-ферме обращаться с бакетом Google Cloud Storage как с обычными локальными путями: диски только для чтения защищают исходные ресурсы, а фоновая загрузка не даёт выводу кадров блокировать следующий рендер. О базовой настройке см. Монтирование Google Cloud Storage в Windows с NetDrive или Монтирование Google Cloud Storage в macOS с NetDrive. Студиям, использующим автоматизированные конвейеры рендеринга в стиле CI, также может пригодиться статья Тестовые фикстуры S3 для CI-команд — о шаблоне монтирования при загрузке, на который опираются автономные узлы.

— Morgan, NetDrive