Вдыхая жизнь в Avatar

:

image
Хотя на Хабре уже публиковались некоторые заметки о технической стороне создания фильма Avatar, например в блоге компании HP была заметка о создании рендерфермы, построенной на blade-системах HP, мне показалось, что эта тема остается весьма любопытной для «технарей», как же там все делается «за кадром», в проектах такого масштаба, тем более, что системы NetApp непосредственно участвовали в создании фильма. Поэтому я решил перевести эксклюзивно для Хабра статью из недавно вышедшей свежей «электронной ежемесячной газеты» Tech Ontap. Кстати, можно подписаться и на русскую ее версию.

Фильм Avatar, вышедший на экраны в этом году, побил все рекорды сборов, добравшись до величины в 2.7 миллиардов долларов, и продолжая собирать кассу. Weta Digital, компания создания визуальных эффектов, занимавшаяся созданием спецэффектов и компьютерной анимации для этого фильм, также побила несколько своих собственных рекордов при создании впечатляющего 3D-мира Avatar. Weta Digital получила широкую известность в профессиональной среде после выхода трилогии «Властелин Колец» ( The Lord of the Rings) и ряда последующих фильмов, таких, как King Kong и District#9, но создание Avatar потребовало совершенно особых технических усилий.
 
Weta Digital далеко раздвинула границы своих вычислительных инфраструктур и систем хранения, много дальше, чем то, с чем нам приходилось работать ранее. Когда началась работа над Avatar в 2006 году, Weta Digital только завершила работу над фильмом King Kong. В этот момент он располагала примерно 4400 ядрами CPU в своей ферме рендеринга и около 100TB пространства хранения. Завершая производство Avatar, компания имела около 35000 ядер CPU и свыше 3000TB хранилища. Емкость только RAM фермы рендеринга сегодня превышает общую дисковую емкость Weta Digital на момент завершения работ над фильмом King Kong.
Я начал работать в Weta Digital в 2003 году системным администратором, когда завершалась работа над последней частью Lord of the Rings. Вскоре моей основной задачей стало руководство отделом инфраструктурных решений Weta Digital. Этот отдел отвечал за все сервера, сети и системы хранения. Нашей задачей было создать такую инфраструктуру, чтобы сделать возможным создание фильма уровня Avatar, а также решать все возникающие в ходе работы над ним проблемы технического плана.

Сражение за рост


Несмотря на тот гигантский рост, который произошел в Weta Digital в ходе работы над Avatar, управление выросшей инфраструктурой не стало такой проблемой, как мы боялись. В значительной степени это была заслуга команды, знающей как работать вместе. Команда держалась вместе, и, когда что-то шло не так, мы подскакивали и неслись это исправлять все вместе. Мы напряженно работали, и, в большинстве случаев, нам удавалось упреждать ситуации, вместо того, чтобы исправлять что-то уже случившееся.
Мы быстро поняли, что для того, чтобы справиться с Avatar нам потребуется сделать два важных шага.
  • Построить новый датацентр. Weta Digital использовала до сих пор несколько небольших серверных комнат, разбросанных по нескольким зданиям. Новый датацентр обеспечивает централизованное размещение и консолидацию всей новой инфраструктуры, которую потребуется нарастить в ходе реализации проекта Avatar.
  • Проложить высокоскоростной оптоволоконный канал. Weta Digital не имеет локализованного кампуса. Вместо этого наш «кампус» состоит из нескольких независимых зданий, разбросанных в пригороде Веллингтона. Мы разработали и соорудили высокоскоростное «кольцо» с использованием оптоволокна, которое соединило все эти здания с новым датацентром. Каждое здание соединялось избыточным соединением, с пропускной способностью 10Gbit/s каждое, суммарно образующих EtherСhannel в 40Gbit/s, для соединения системы хранения и серверов фермы рендера.

Эти два элемента дали нам физическую возможность масштабировать нашу инфраструктуру, нарастив ее и пропускную способность, чтобы свободно перемещать данные между локациями. Новая серверная инфраструктура обновленной фермы рендеринга была создана с использованием blade-серверов HP. C 8 ядрами и 24GB RAM на blade, мы получили возможность уместить до 1024 ядер и до 3TB RAM на стойку. Новый датацентр был организован в виде ряда из 10 стоек, суммарно 10240 ядер. Мы установили первые 10000, поработали немного на них, добавили еще 10000, еще поработали, добавили еще 10000, и, наконец, поставили пока на сегодня последние 5000 ядер.

Датацентр имеет ряд уникальных элементов конструкции:

  • Водяное охлаждение. Так как обычная погода в Веллингтоне, Новая Зеландия, городе, где находится Weta Digital, редко бывает очень жаркой, вода большую часть времени прокачивается непосредственно из охлаждаемых ей стоек в расположенные на крыше здания радиаторы, для естественного теплообмена. Сервера работают в относительно «теплом» режиме, при температуре в 23º C.
  • Высокая плотность электропитания. Датацентр обеспечивает подачу мощности до 30 киловатт на стойку.
  • Высокопрочные стойки. Каждая стойка Rittal с встроенным водяным охлаждением выдерживает нагрузку по весу размещенного в ней оборудования и системы охлаждения до одной тонны.

В нашей инфраструктуре хранения мы использовали продукцию нескольких производителей, но ядро ее состоит из систем хранения производства NetApp, на которых находится около 1000TB данных. К концу работы над Avatar, мы заменили все наши старые FAS980 и FAS3050 на кластерные FAS6080. В последние восемь месяцев проекта мы также добавили четыре системы SA600 storage accelerator для того, чтобы решить одну особо болезненную проблему производительности.

Ускорение доступа к текстурным файлам с помощью адаптивного кэширования


В индустрии визуальных спецэффектов «текстуры» это специальные файлы изображений, которые «наносятся» на 3D-модель, делая ее реалистичной. Модель «обернута» текстурами, которые создают необходимые детали, цвет, тени, характер поверхности модели, без которых 3D-модель выглядит всего лишь однотонно серой. «Набор текстур» (texture set) это все разнообразные картинки, которые должны быть нанесены на конкретную модель, чтобы она выглядела как дерево, персонаж или существо. Большинство рендеров включающих в себя объекты, включают также и текстуры, применяемые на эти объекты; таким образом, содержимое файлов текстур постоянно требуются серверам фермы при создании сцены.

Определенная группа наборов текстур может быть запрошена одновременно несколькими тысячами ядер процессоров рендера. Перекрывающаяся по содержимому с первой, другая группа может быть затребована другой тысячей ядер, и так далее. Все что мы можем сделать для улучшения ситуации со скоростью доступа к текстурам, резко увеличит производительность всей фермы рендеринга в целом.
Никакой отдельный файловый сервер не может обеспечить достаточную полосу пропускания для подгрузки всех наших наборов текстур, поэтому мы разработали специальный процесс «публикации», который предназначен для создания реплик каждого созданного набора текстур. Это показано на рисунке 1.
weta infrastructure before

Рисунок 1) Старый метод увеличения пропускной способности при передаче наборов текстур.

Когда задача рендера запускается на ферме, им требуется доступ к набору используемых в проекте текстур, она выбирает случайный файл-сервер и считывает содержимое текстуры с одной из его реплик. Позволив нам распределить содержимое текстур по нескольким файл-серверам этот процесс значительно увеличил производительность системы. Хотя такое решение было лучше, чем вариант с одним файл-сервером, процесс публикации и репликации был довольно сложен и требовал затрат времени на контроль целостности, чтобы быть уверенным в том, что все реплики на всех серверах абсолютно идентичны.
Мы начали использовать NetApp FlexCache и SA600 storage accelerator как простой способ решить проблему с нехваткой производительности, связанной с работой с наборами текстур. ПО FlexCache создает уровень кэширования в инфраструктуре хранения, автоматически обрабатывающий изменяющиеся паттерны доступа и устраняющий «узкое место» производительности. Оно автоматически реплицирует и обслуживает доступ к активным наборам данных, вне зависимости от того, где эти данные находятся в инфраструктуре хранения, с помощью локальных кэширующих томов.
Вместо ручного копирования наших текстур на несколько файловых серверов, FlexCache позволяет нам динамически кэшировать используемые в данный момент в проекте текстуры и отдавать их на ферму рендеринга с устройств SA600. Мы протестировали это решение и увидели, что оно работает очень хорошо в условиях нашей системы, поэтому за 8 месяцев до окончания работы над фильмом мы решили рискнуть и установили четыре системы SA600, каждая с двумя модулями Performance Accelerator Modules (PAM) емкостью 16GB каждой. (PAM работает как кэш, снижая время отклика при доступе к данным. подробнее: eng и рус)

weta infrastructure after

Рисунок 2) Улучшенный метод увеличения полосы пропускания для наборов текстур, используя NetApp FlexCache, SA600, и PAM.

Полный размер набора текстур составляет около 5TB, но когда мы включили FlexCache, мы выяснили, что только 500GB из них активно используются в каждый момент времени. Каждый SA600 имеет достаточно пространства на его локальных дисках, чтобы разместить этот активный набор данных, и, когда текстуры в активном наборе данных изменяются, кэш автоматически перезагружает свое содержимое, не требуя от нас ручного вмешательства в этот процесс. Агрегированная полоса пропускания составила 4GB/сек, гораздо больше, чем мы достигали до сих пор.
Кэширование текстур с помощью FlexCache оказалось превосходным решением. Все работает быстрее, упрощается работа по управлению текстурами и их наборами. Был заключительный год проекта, занявшего четыре года труда по созданию фильма. Если бы мы решились поставить SA600 и с ними начались бы проблемы, нам бы пришлось срочно менять все назад, чтобы не сорвать сроки. Но после того, как прошла неделя, мы практически забыли о их существовании (исключая, конечно, факт увеличившейся скорости). Это самый простой способ сделать IT-шника счастливым.
Производительность подсистемы хранения оказывает значительное влияние на скорость обработки заданий рендера. Узкие места и недостаток производительности не позволяет работать ферме рендеринга в полную мощь. В последний год создания Avatar мы углубились в детали процессов и добавили много возможностей по мониторингу и снятию статистики в каждом задании.
Мы постоянно отставали от графика, у нас постоянно висели задержанные задачи, ожидавшие очереди на запуск; каждый день копилось все больше заданий, ожидавших, когда у рендерфермы дойдет до них очередь. Команда так называемых «пастухов» (wranglers) в Weta Digital занимается тем, что наблюдает за тем, чтобы все задания и работы по рендеру шли правильно и в нужном порядке. Наутро, после того, как мы ночью установили и запустили FlexCache, «старший пастух» пришел к нам с отчетом, что все задания выполнены. Все работало так неожиданно быстро, что он решил, что у нас что-то сломалось.

Почему именно NetApp?


Я давний фанат продукции NetApp. Впервые мне довелось использовать системы NetApp, когда я работал в интернет-провайдере на Аляске, во времена «дотком бума» в конце 90-х — я был достаточно впечатлен их возможностями, чтобы последовательно продвигать их в дальнейшем в тех компаниях, где я работал. Я был рад увидеть, что системы хранения NetApp уже используются в Weta Digital, когда я в нее пришел.
Для таких компаний, как Weta Digital, вполне обычное дело что-нибудь «сломать», так как обычно никто больше не делает такого с инфраструктурой, как приходится делать нам. Ключевой момент в ситуации состоит в том, что вам может потребоваться помощь вендора, чтобы исправить ситуацию (например в анализе причин возникновения проблемы, или даже срочном выпуске патча для ПО, в случае обнаружения бага). Даже если вы работаете в небольшой компании, в NetApp всегда найдется кто-то, кто будет заниматься вашей проблемой вместе с вами, пока она не будет наконец решена. Вы думаете, что так оно и должно происходить всегда? Мой опыт, показывает, что у других вендоров так получается довольно редко.
Хранилища данных могут быть сложны. Технологии NetApp делают системы хранения такими простыми, как это только возможно. Есть вещи, которые мне хотелось бы, чтобы NetApp делал лучше, чем он их делает сейчас, но, в сравнении со всеми другими, я вижу, что NetApp делает надежный и разносторонний продукт, который просто использовать, и который обеспечивается надежной поддержкой. Вот почему мы по прежнему используем именно NetApp.


Adam Shand
Ранее руководитель инфраструктурного отдела
Weta Digital
Адам начал свою карьеру в Новой Зеландии где основал одну из первых интернет-компаний страны, совместно со своим отцом. Его следующая работа, в 1997, привела его на Аляску, затем он работал в Портленде, штат Орегон в индустрии EDA. Сходство между EDA и производством визуальных эффектов, плюс возможность работать ближе к дому, привела Адама в 2003 году в Weta Digital. После нескольких лет в Weta Digital Адам решил оставить компанию, и отправился в годичное путешествие по Юго-Восточной Азии.