Skip to content

Введение

1. Цели и задачи

  1. Помощь пользователям, особенно тем, которые платят.
  2. Обучение пользователей работе с сервисом, для уменьшения запросов в ТП.
  3. Максимизация прибыли:
  • Приоритет загрузки нашим пулам, против сторонних.
  • привлечение юзеров попробовать или проверить сервис.
  1. Минимизация издержек:
  • Бан халявщиков (Скрипты SQL M:\manualRender\Scripts\SQL).
  • Предотвращение неоплат (ухода в большой минус по балансу).

2. Понятия и определения

  1. Портал (Portal) - ASP.NET сайт, реализующий web-интерфейс и бОльшую часть бизнес логики онлайн сервиса.
  2. ЦС (целевая система) - кластер (массив компьютеров), интегрированный в нашу распределённую систему рендеринга.
  3. ББ (бэкбурнер) - очередь рендеринга от компании Автодеск.
  4. TSI (Target System Interface) - это SOAP-сервис, написанный на Python 2.7, который предоставляет, посредством выложенных наружу (порт 5555) SOAP-функций, интерфейс для работы с ЦС. Такие функции как поставить/снять с синка, проверить статус синхронизации, распаковать архив, удалить папку, отправить задачу в ББ. Обычно TSI отождествляется с понятием ЦС.
  5. Импорт - папка с общими файлами, необходимыми для рендеринга на каждой машине. Это текстуры, прокси, кеши, запеченное глобальное освещение. Дополнительно содержит сцену пользователя, обработанную скриптом импорта. Структура папки всегда одинаковая и соответствует структуре стандартного проекта макса.
  6. Импортирование - процесс подготовки сцены пользователя для рендеринга на наших компах. Этот процесс включает в себя распаковку архива со сценой и создание правильной структуры папок проекта, прописывание в сцену наших путей к текстурам и прочим файлам, используемым в сцене.
  7. Аккаунтинг - сбор статистики рендеринга в базу данных.
  8. Папка задачи - папка с именем задачи, указанным юзером, содержащая отрендеренные кадры, а на целевых системах ещё и распакованную сцену.
  9. Апплаер - скрипт applier.ms содержащий настройки которые сделал пользователь на сайте.
  10. Распределённый рендеринг - вид рендеринга, при котором одна картинка рендерится несколькими машинами одновременно. Этот механизм приносит дополнительные накладные расходы на синхронизацию процесса между всеми машинами, что отражается на цене рендеринга в большую сторону.
  11. Спавнер (vrayspawner.exe или DrServer.exe) - запускалка вирея/короны в режиме слейва для распределённого рендеринга.
  12. Ассеты - текстуры, прокси, кеши, запеченное глобальное освещение и любые другие файлы, которые требуются для рендеринга сцены.
  13. Домашний каталог юзера - папка на МЕГАХОСТИНГЕ M:\data<user_id>. В эту папку смотрит символьная ссылка С:\inetpub\portal\ftp_folder. Без этой ссылки пользователь не будет видеть свои файлы при выборе сцены для запуска проверки.
  14. Megahosting - наш аппаратный сервер. На нём крутятся виртуальные сервера необходимые для функционирования инфраструктуры.
  15. ImportHost - виртуалка, на которой производится проверка (импорт) сцен, а так же работают все технологические процессы сервиса.
  16. BTSync - программа для синхронизации данных (исходников сцен и готовых кадров) между Megahosting и целевыми системами. Сайт разработчиков https://www.resilio.com/
  17. Redis - программа, обеспечивающая асинхронный обмен сообщениями между своими клиентами (обычно тоже программы), другими словами очередь сообщений. Одна программа может положить туда сообщения - другая прочитать это сообщение.
  18. Deadline - очередь рендеринга от Thinkbox.

3. Задачи дежурного

1. Мониторинг ББ и машин

  1. Мониторинг машин вручную и по заббиксу. Упавшие машины поднимаем.Если машина не поднимается, сообщаем на 2 линию - отмечаем в админке.
  2. Перегревающиеся машины снимаем с рендера и сообщаем на 2 линию.
  3. Мониторинг состояния всех систем по заббиксу. О критических проблемах сообщать на 2ю линию.
  4. Мониторинг доступности личного кабинета my.megarender.com.

2. Мониторинг процесса рендеринга

  1. По РДП следить за процессом рендеринга на предмет наличия следующих проблем:
  • Память занята полностью, а загрузка процессора менее 50% - задачу останавливаем с комментарием повысить память или оптимизировать расход памяти в сцене.
  • Если несколько максов - прибиваем “лишний макс” или перезапускаем сеанс на машине.
  • Макс не набирает память (менее 460 Мб) и не рендерит. Лечится это удалением аппдаты C:\Users\каталог_юзера\AppData\Local\Autodesk\3dsMax\20ХХ - 64bit
  • Бакеты застряли.
  • Макс показывает до окончания очень много времени(больше 20 часов);
  • Распределённые задачи не подхватили машины (слейвы не отдают пассы или не появилось бакетов от слейвов).
  1. Устраняем проблемы в процессе рендеринга, если есть, либо стопорим задачу и отписываем в комментарий при остановке задачи квадратиком. Лучше всегда написать содержание ошибки, чем ставить стандартную отписку: это поможет следующему дежурному быстрее разобраться с повторной проблемой.
  2. Для одиночных кадров длительностью менее 1 часа - оптимизируем пул (снимает кадр с главной машины в пуле и удаляем (крестиком) задачу из списка активных в админке).
  3. Одиночные кадры (меньше 5 кадров на пользователя) длительностью более 1 часа каждый - стопорим (квадратиком) и предлагаем юзеру запустить распределённый (пишем комментарий в админке при остановке задачи). Объясняем юзеру опасность рендеринга одиночных кадров без распределёнки при окончании баланса. Одиночные кадры длительностью более 5 часов - в любом случае отправляем в распределёнку.
  4. Оптимизируем пул, если в нём остаётся не менее 80% свободных машин.
  5. Загрузка оперативки и проца, если загрузка проца низкая.

3. Мониторинг очереди

  1. Быстрое продвижение задач в очереди. Обращаем внимание на задачи которые долго не стартуют.
  2. Застрявшие задачи нужно протолкнуть до постановки в ББ. Обычно проблема с синками - нужно проверить BTSync - подкладывать мелкий файлик в папку или поснимать лишние папки.
  3. Ошибочные задачи - выяснить в чем ошибка, если можно исправить то исправить и протолкнуть до запуска в ББ, если нет то отписать юзеру в вербокс или на почту.
  4. Если ошибка в ББ или Deadline, то остановить задачу в ББ/Deadline, потом решать проблему. Если можно решить - исправляем и снова запускаем, иначе отписать юзеру в комментарий к задаче.
  5. Остановленные задачи чистим крестиком в админке.
  6. Сверяем занятые пулы по админке и по ББ/Deadline, если не соответствует - разбираемся и фиксим.
  7. Архивировать жёлтые задачи, которые захолдены юзером или админом и которые не имеют ошибок.
  8. При появлении ошибок вида “JPEG - Invalid Image File Header”. Вместо жипега может быть любой формат указан проверяем наличие выгруженной картинки и доначисляем юзеру вручную. см. Известные проблемы п.18
  9. Следить за задачами за день, чтобы не было бесконечно ожидающих задач.

4. Подчищать битисинки (не актуально)

  1. Протухшие папки снимаем с синка сначала через новую админку, а потом напрямую в битисинках. Папки считаются протухшими если они старше 24 часов и они не используются в данный момент в рендере (это важно, рендер может идти несколько суток)

5. Следить за тяжёлыми рендерами (обещает рендериться более 1 часа на tnode)

  1. Если юзер новенький, рендерит на бонус, то проверяем баланс, хватит ли ему минут.
  2. Если минут не хватит более чем на 200, но картинка более-менее приличная - останавливаем с сохранением так, чтобы баланс не ушёл далеко в минус более чем на -200. Если рендерится что-то непонятное - просто останавливаем и пишем в коммент чтобы оптимизировал сцену.
  3. Если юзер старенький, а рендер тяжелее его предыдущих рендеров более чем в 3 раза, то пытаемся связаться с юзером в чате или по почте и предупредить о цене рендера. Если связаться не удалось, то смотрим по уровню текущего и желаемого шума и делаем аналогично предыдущему.
  4. Если юзер старенький, задача не сильно дороже его предыдущих рендеров - то передаём вопрос на уровень выше и записываем в пересменку.
  5. При передаче смены передаём инфу о тяжёлых рендерах (тяжелее 2х часов), на случай если придётся выгружать сохранённые кадры.
  6. Если на анимацию поставлен тяжёлый рендер…

  7. Если рендерится неадекватная картинка…

6. Отвечать в чат юзерам

  1. Каждый диалог завершайте своим сообщением или комментом, чтобы не просыпать чаты, а ответственному за чаты было удобнее следить за ними.

Изображение

  1. Чтобы видеть все эти значки, настройки чата нужно ставить как в п.12.2

4. Структура онлайн сервиса

Изображение

1. Запуск сервиса

  1. Для запуска сервиса идем в папку C:\!Megarender\bat\importhost\ и запускаем батники и ярлыки в порядке нумерации:
  • 0_BB_Manager - ББ менеджер.
  • 1_Redis - очередь сообщений Редис.
  • 2_TSI - питоновые сервисы ЦС (автоматом запустятся максы и BTSync) (Мышкой в окно TSI НЕ тыкать, иначе остановится).
  • 3_Closer - закрывалка всплывающих окон.
  • 4_billing.bat - запрашивает страницу биллинга каждые 10 сек. Логи работы биллинга здесь D:\!Megarender\log\billing, время отработки биллинга не должно превышать 60 сек.
  • 5_accounting.bat - запрашивает страницу сбора аккаунтинга (не менее 20 и не более 40 сек).
  • 6_BT_sync_Collector - чистка битисинков и ЦС.
  • 7_Import.Broker - запускалка импортов.
  1. Проверяем работоспособность Crush_FTP (доступность сайта https://my.megarender.com:9090).

2. Запуск целевых систем

  1. Проверяем наличие папки M:\data (далее по тексту <папка_дата>). Это папка, где лежат сцены и кадры, рендерящихся в ДАННЫЙ МОМЕНТ сцен. Это горячие данные, находящиеся на быстром но маленьком диске, которые синхронизируются с мегахостингом и праймом. Эти папки затираются через 15 минут после окончания рендера.
  2. Проверяем наличие символьной ссылки C:\data на M:\data. Если нет - создаём командой от админа “mklink /D c:\data m:\data”.
  3. Определяем где находится папка TSI’ки (далее по тексту <TSI_root>)
  • NeoPrime (наша ЦС) = C:\!Megarender
  • NewSupport (Казахстан) = M:\MTSI
  • Mega (ЮУрГУ) = C:\Program Files (x86)\MTSI
  • Boss (московские) = C:\Program Files (x86)\MTSI
  • Support = M:\MTSI

Идем в папку <TSI_root>\bat<имя машины>, запускаем батники и ярлыки в порядке нумерации:

  • 0_BB_Manager - ББ_менеджер
  • 1_Redis.bat - очередь сообщений Редис, без неё не будут работать спавнеры и останов задач с сохранением
  • 2_run_tsi.bat - питоновые сервисы Убедимся что битисинк(на Неопрайме 2 битисинка) запустился и ничего не спрашивает. Проверяем, чтобы все машины поднялись в ББ_мониторе и Deadline и на них был запущен клозер.
  1. Приводим в админке ЦС и пулы в соответствие с текущим состоянием. (Alive - ЦС жива, spendable - с данной ЦС собирается Аккаунтинг).
  2. В случае неполадок стучимся на 2ю линию

5. Тех. процесс онлайн сервиса

1. Добавление сцены (проверка сцены)

  1. Загрузка архива со сценой происходит на ImportHost в папку M:\Data\user_id
  2. В таблицу User_project добавляется строка проекта, а в таблицу Task добавляется задача импорта в статусе QUEUED;
  3. Биллинг подхватывает задачи импорта в статусе QUEUED в порядке очереди и в количестве, равном количеству свободных max_consumer’ов и отправляет их на проверку, а именно:
  4. В Redis отправляется сообщение (команда запуска проверки сцены), а задача переводится в статус STARTED; При этом задаче назначается пул №7 (специальный пул только для импорта)
  5. Max_consumer’ы прослушивают Redis и, тот кто первый забрал сообщение, выполняет команду, тем самым запуская алгоритм проверки сцены:
  • Сообщает в очередь, что импорт начался (биллинг получив это сообщение переводит задачу импорта в статус RUNNING)
  • Распаковывает архив в папку M:\data\user_id\имя архива\_import_XXXXX
  • Если в архиве было несколько сцен, то сразу выходит и пишет ошибку.
  • Открывает сцену и переназначает пути в сцене.
  • По ходу импорта отправляет лог в Redis, который затем попадает в базу и отображается юзеру;
  • Создаёт отчет об импорте user_id\имя архива\_import_XXXXX\scenes\mr_3dmax.log. В нем можно посмотреть версию плагина/макса/vray, посмотреть все ли текстуры подгрузились и каких не хватает;
  • Сохраняет сцену (время изменения позже чем отчет об импорте)
  • Создаётся сцена-заглушка (proxy.max)
  • Сообщает в очередь Redis об успешном окончании импорта
  • Создаёт файл \user_id\имя архива\имя архива.xml
  1. Когда в очередь Redis приходит сообщение об успехе импорта, биллинг начинает проверять файлы (“имя_архива.xml” существует и XMLка валидная и не содержит спец символов), проверяет даты изменения файлов сцены. Если всё в порядке, биллинг переводит проект в статус CREATED, задачу в статус FINISHED и освобождает пул.
  2. В случае ошибки или таймаута, биллинг переводит задачу и проект в статус ERROR. Пул НЕ освобождается.
  3. Только из проекта в статусе CREATED можно создавать задачи.

2. Постановка задачи на рендер

  1. Запись в базу Запуск задачи из личного кабинета означает лишь запись в таблицу TASK строки задачи в статусе CREATED (или 2х строк если распределёнка). В этот момент известны только параметры которые задал юзер и имя задачи.
  2. Подготовка в базе Биллинг собирает все задачи в статусе CREATED, заполняет для каждой задачи поля frames, camera, resolution, outputFilename, формирует скрипт апплаера (на языке MAXScript) и записывает эти параметры в базу. И переводит задачу в статус QUEUED.
  3. Старт импортов Биллинг собирает все задачи импорта в статусе QUEUED и сразу отправляет в брокер команду на импортирование сцены (но не больше 3х импортов одновременно).
  4. Выбор задач для запуска. Задачи рендера сортируются в порядке приоритетов тарифов и в порядке поступления; Перед запуском QUEUED задач проводится проверка пользователя по следующим пунктам:
  • Пользователь должен быть активным (user.status = 0 | -1);
  • У пользователя должен быть положительный баланс+кредит;
  • У пользователя должны быть пополнения минимум на 500 минут (включая бонусы);
  • Пользователь должен пройти проверку на "халявщика", в противном случае, он будет заблокирован, а его задачи - остановлены.

Если пользователь удовлетворяет всем вышеперечисленным требованиям, то для каждой его задачи выполняется алгоритм запуска.
5. Старт алгоритма запуска

  • подбирается пул из доступных юзеру, подходящий по памяти, типу задачи и выбранному юзером софту
  • Если у юзера достаточно power’а, чтобы занять этот пул, то задача рендера переводится в статус STARTED и задаче назначается пул;
  • статус задачи переходит в READY_TO_RUN
  • в таблице Pool_IN_USE делается отметка о занятии пула
  1. Создание папки задачи
  • На ИмпортХосте создаётся папка задачи M:\data\user_id\имя_сцены\имя_задачи, внутри которой создаётся директория "scenes" и в нее записываются 2 пустых файла "file1" и "file2" для дальнейшей синхронизации задачи.
  • статус задачи переводится в APPLIER_COMPLETED;
  • Если это задача-распределёнка, то задача спавнера сразу сабмитится в ББ. Подробнее см. Рендер распределёнки
  1. Синхронизация импорта
  • На ИмпортХосте пакуется (если ещё не запакованы) два мах-файла (со сценой и вспомогательный) в архив max_portal.zip.
  • На ИмпортХосте и на нужной ЦС ставится на синхронизацию папка импорта (статус задачи := SYNC_IMPORT_STARTED);
  • Запускается поток, который постоянно опрашивает ЦС на предмет завершения синхронизации. Синхронизация проверяется по ответу битисинка + по совпадению количества файлов.
  • Для каждого потока в таблице Threads создаётся запись. Поток постоянно обновляет метку времени в этой таблице.
  • Как только условия синхронизации выполнены, поток стирает себя из таблицы Threads, переводит задачу в статус := SYNC_IMPORT_COMPLETED и завершается.
  1. Распаковка сцены на ЦС
  • Биллинг переводит статус задачи := ZIP_UNPACK_STARTED;
  • Портал отправляет в нужную TSI команду на создание папки задачи и распаковку сцены с помощью 7-Zip.
  • На ЦС из папки импорта из файла max_portal.zip, мах-файлы распаковываются в папку задачи (тут создаётся папка задачи на ЦС!!!) (m:\data\user_id\...\имя_задачи).
  • Если распаковка прошла успешно, статус := ZIP_UNPACK_COMPLETED, а иначе статус задачи откатывается до SYNC_IMPORT_COMPLETED, и увеличивается счетчик ошибок. Внимание если распаковка не прошла (места не хватило), это часто незаметно и задача зависает в статусе SYNC_IMPORT_COMPLETED.
  1. Синк задачи.
  • Биллинг переводит задачу в статус := SYNC_STARTED;
  • На ИмпортХосте и на нужной ЦС ставится на синхронизацию папка задачи, но на исключение ставятся *.max файлы (так как сцену мы синкаем на этапе синхронизации папки импорта). Поэтому здесь происходит синхронизация только 2х пустых файлов. (Это старый костыль проверки синхронизации, который хочет чтобы любая папка содержала не менее 2х файлов.)
  • Запускается поток, который постоянно опрашивает ЦС на предмет завершения синхронизации. Синхронизация проверяется по ответу битисинка и по совпадению количества файлов.
  • Для каждого потока в таблице Threads создаётся запись. Поток постоянно обновляет свою метку времени в этой таблице.
  • Как только условия синхронизации выполнены, поток стирает себя из таблицы Threads, переводит лаунч-статус := SYNC_COMPLETED и завершается.
  1. Сабмит задачи в ББ
  • Биллинг переводит статус := RENDER_STARTED;
  • Далее всё происходит уже на головной машине ЦС
  • Если задача была распределёнка, то задача спавнера уже должна быть в ББ, и её просто активирует в ББ.
  • В папку <TSI_root>\submit_sripts\...\задача\ сохраняется скрипт с параметрами которые поменял юзеер = applier.ms (который в дальнейшем и накатывает апплаер на сцену при запуске макса на каждой машине)
  • Создаётся XML’ка для сабмита сцены в ББ
  • Выполняется скрипт <TSI_root>\bin\start_render.exe, с передачей ему кучи параметров (лог лежит здесь <TSI_root>\submit_sripts\...\задача\log_render.txt)
  • Который в свою очередь запускается 3dsmaxcmd.exe в режиме создания XML
  • Создаёт вспомогательный скрипт mr_applierrunner.ms
  • Затем все вместе (XML-ка, скрипты) сабмитятся в ББ снова через 3dsmaxcmd.exe. Задача сразу запускается в рендер и уже силами ББ раскидывается по машинам.
  • Когда Accounting получит статистику из ББ и увидит, что у задачи есть кадры, то задача считается запущенной и переходит в статус RUNNING и LAUNCH_COMPLETED.
  1. Если статус задачи не меняется, то сперва пробуем откатить статус в предыдущий терминальный, если не помогает, значит проблема в переходе на новый статус, начинаем смотреть по алгоритму описанному выше, что должно было произойти, читаем логи и ищем проблему.

3. Рендеринг анимации

  1. Из предыдущих пунктов следует, что задача уже запущена в ББ.
  2. На каждую машину ББ_менеджер отправляется сцену с пререндер-скриптом (MR_apply_spawn.ms), который выполняется один раз при открытии сцены на самой машине.
  3. Каждая машина открывает сцену, выполняет пререндер-скрипт, в котором прописан запуск апплаера и скрипта сбора превью:
  • Лог выполнения апплаера на каждой машине записывается в c:\tmp\log_applier_дата.txt
  • Лог скрипта захвата записывается в C:\tmp\vfb_saver_logs
  1. Машина получает от ББ-менеджера номера кадров, которые необходимо рендерить и рендерит.

4. Рендер распределёнки (не актуально):

  1. Когда биллинг подхватил распределёнку, он первым делом сабмитит в ББ задачу спавнера в режиме suspended. Лог команды сабмита лежит в m:\data\user_id\проект\имя_задачи_спавнера.
  2. Суть задачи спавнера - это выполнить на каждой машине программу "start_run_spawner.exe", которая готовит машины для распределёнки:
  • подкладывает пререндер-скрипт в нужную папку и запускает максы в режиме слейвов (процессы vray_spawner_XXXX.exe или DrServer.exe), а на главной машине ждёт, пока все слейвы не отпишутся в редиску о готовности.

ВАЖНО:

Менять главную машину напрямую в ББ НЕЛЬЗЯ, за исключением случая, когда запуск распределёнки происходит на Тредриппер.

  • start_run_spawner.exe мониторит загрузку процессора и памяти и постоянно пишет в лог c:\tmp\имя_задачи.log. По этому логу впоследствии можно определить работали слейвы или нет.
  • start_run_spawner.exe не отпускает слейвы, пока не получит сообщение из Редиски об окончании рендера.
  • а главную не отпускает пока все слейвы не отпишутся о готовности или не пройдёт таймаут ожидания слейвов (1,5 минуты на каждый слейв). Если таймаут прошёл, то главная машина запускает следующий spawn и снова ждёт 1,5 минуты. Таким образом недоступные слейвы будут пропущены в задаче спавнера.
  1. Когда прошла синхронизация, в ББ сабмитится задача дистрибута. Здесь механизм как в п. 5.2.9
  2. После того, как задача спавнера опускает главную машину, на ней запускается задача рендера.
  3. Далее задача рендера рендерится так же как анимация.
  4. После завершения всех кадров в задаче рендера, она чернеет в ББ.
  5. Аккаунтинг получается инфу об окончании задачи рендера и биллинг отправляет команду в редиску об окончании рендера.
  6. run_spawner.exe, получив команду на завершение, отпускает слейвы и задача спавнера тоже завершается.

5. Сбор превью

  1. Превью теперь собираются самим максом и сохраняются в папку M:\data\preview\preview<имя_машины>. Лог работы MR_VfbSaver.ms пишется в C:\tmp\vfb_saver_logs
  2. Если макс ругается на Runtime error: dotNet runtime exception: An attempt was made to load an assembly from a network location, то нужно прописать в файле C:\Program Files\Autodesk\3ds Max 20ХХ\3dsmax.exe.config
md
<configuration>
   <runtime>
  	<loadFromRemoteSources enabled="true"/>
   </runtime>
</configuration>
  1. Мегахостинг запрашивает эти картинки у TSI’ки. TSI’ка жмёт картинку и отдаёт в BASE64 формате.

6. Список статусов задачи (LAUNCH_STATUS) задачи

  1. READY_TO_RUN - сгенерированы необходимые поля в таблице Task. Задача готова к запуску (терминальный)
  2. APPLIER_STARTED - на мегахостинге создаётся папка задачи
  3. APPLIER_COMPLETED - папка создана, аплаер сформирован и записан в базе (терминальный) Этап запуска APPLIER_STARTED => APPLIER_COMPLETED в настоящий момент устарел и работает только для того, чтобы не нарушать работающий техпроцесс. Сейчас файл апплаера создается на целевой системе непосредственно перед отправкой задачи в ББ на этапе RENDER_STARTED.
  4. SYNC_IMPORT_STARTED - поставлена на синхронизацию папки импорта на нужную целевую систему
  5. SYNC_IMPORT_COMPLETED - синхра папки импорта закончилась (терминальный)
  6. ZIP_UNPACK_STARTED - на целевой системе архив со сценой распаковывается в папку задачи
  7. ZIP_UNPACK_COMPLETED (терминальный)
  8. SYNC_STARTED - поставлена на синхронизацию папка задачи на нужную целевую систему
  9. SYNC_COMPLETED (терминальный)
  10. RENDER_STARTED - отправлена команда в ББ на сабмит сцены в очередь
  11. LAUNCH_COMPLETED - сцена успешно стартанула в ББ
  12. DELETED - исходники задачи уже удалены биллингом с ЦС, продолжение задачи невозможно.