NetApp Tech OnTap
     

Dar vida a Avatar

Avatar pulverizó todos los récords de taquilla con unos ingresos de más de 2.700 millones de USD brutos en todo el mundo, cifra que sigue en aumento. Weta Digital, la empresa que se encargó de los efectos especiales de la película, tuvo que batir algunos de sus propios récords para crear los espectaculares efectos en 3D de Avatar. Weta Digital tenía una amplia experiencia en el exigente procesamiento de gráficos gracias a su trabajo en la trilogía de El Señor de los Anillos y en otras películas recientes, pese a ello, la creación de Avatar supuso un esfuerzo técnico tremendo.

Weta Digital forzó los límites de su infraestructura informática y de almacenamiento mucho más de lo que lo había hecho antes. Cuando comenzó a trabajar en Avatar en 2006, Weta Digital estaba acabando la producción de King Kong. En esos momentos, disponía de apenas 4.400 núcleos de CPU en su "renderwall" (equipos dedicados a la animación) y unos 100 TB de almacenamiento. Al finalizar la producción de Avatar, la empresa contaba con alrededor de 35.000 núcleos de CPU en su "renderwall" y 3.000 TB de almacenamiento. La capacidad de la memoria RAM, sólo del "renderwall", supera actualmente la capacidad total de almacenamiento en disco que tenía Weta Digital al finalizar la producción de King Kong.

Comencé a trabajar en Weta Digital en 2003 como administrador de sistemas, cuando se estaba completando la última película de El Señor de los Anillos. Desde ese momento, mi función principal en Weta Digital fue la de responsable de su equipo de infraestructura. Equipo encargado de todos los servidores, redes y almacenamiento. Nuestro trabajo consistió en crear la infraestructura que hizo posible Avatar y solucionar los problemas técnicos que pudieron surgir.

Hacer frente a la escala

Pese al increíble crecimiento que experimentó Weta Digital durante la creación de Avatar, la gestión del cambio de escala no resultó ser tan desafiante como temíamos. Esto se debió, en gran medida, al bien avenido equipo que demostró increíbles cualidades de cooperación. El equipo estaba muy unido y cuando algo fallaba, enseguida interveníamos para solucionarlo. Trabajamos mucho y, durante la mayor parte del tiempo, conseguimos ser proactivos en lugar de reactivos.

Muy pronto, nos dimos cuenta de que debíamos emprender dos grandes medidas para llegar donde necesitábamos estar para crear Avatar.

  • Establecer de un nuevo centro de datos. Weta Digital había utilizado varias salas pequeñas de máquinas diseminadas en diversos edificios. Se creó un nuevo centro de datos que proporcionó una ubicación central para consolidar la nueva infraestructura que necesitábamos incorporar durante el desarrollo del proyecto Avatar, (utilice la barra lateral para ver más detalles sobre el centro de datos).
  • Implantar la fibra óptica de alta velocidad. Weta Digital no dispone de un campus localizado. En su lugar, nuestro campus se compone de varios edificios independientes en las afueras de Wellington. Implantamos un anillo de fibra óptica de alta velocidad que conectaba todos estos edificios con el nuevo centro de datos. Cada edificio estaba conectado con un mínimo de conexiones redundantes de 10 Gbps con conexiones de enlaces EtherChannel de 40 Gbps por si era necesario conectar el almacenamiento con el "renderwall".

Ambos elementos nos proporcionaron la capacidad física para escalar nuestra infraestructura a medida que crecía y el ancho de banda para transportar datos entre ubicaciones libremente. La nueva infraestructura de servidores para el "renderwall" actualizado se creó mediante servidores Blade de HP. Con 8 núcleos y 24 GB de RAM por tarjeta, fuimos capaces de aprovisionar 1.024 núcleos y 3 TB de RAM por rack. El nuevo centro de datos se organizó en filas de 10 racks, de forma que construimos nuestros servidores en unidades de 10 racks o 10.240 núcleos. Implantamos los primeros 10.000, esperamos un poco y añadimos otros 10.000, esperamos otro poco más y añadimos otros 10.000; finalmente, colocamos los últimos 5.000 núcleos para dar el empujón final.

Contamos con una infraestructura de almacenamiento de múltiples proveedores, pero el núcleo de almacenamiento estaba compuesto de sistemas de almacenamiento de NetApp® que proporcionaban aproximadamente 1.000 TB. Hacia el final de Avatar, habíamos reemplazado todos nuestros antiguos sistemas FAS980 y FAS3050 con clústeres FAS6080. Durante los ocho últimos meses del proyecto también añadimos dispositivos de aceleración del almacenamiento SA600 para solucionar un problema particularmente molesto que afectaba al rendimiento.

Aceleración del tiempo de acceso a ficheros de texturas con almacenamiento en caché adaptativa

En el sector de los efectos visuales, una textura es una imagen que se aplica a un modelo 3D para hacerlo parecer real. Las texturas envuelven el modelo para darle detalle, color y sombras, de forma que no parezca solamente un modelo gris y liso. Un "conjunto de texturas" está formado por la totalidad de imágenes diferentes que se deben aplicar a un modelo concreto para darle apariencia de árbol, persona o criatura. La mayoría de las renderizaciones que incluyen un objeto también le aplican texturas, por lo que se convierten en un artículo muy solicitado en el "renderwall" y se utilizan continuamente.

Un grupo determinado de conjuntos de texturas podría ser solicitado por miles de núcleos al mismo tiempo. Un grupo superpuesto podría ser solicitado por otros tantos miles de núcleos y así sucesivamente. Todo lo que podamos hacer para mejorar la velocidad con la que se entregan las texturas tiene un efecto drástico en el rendimiento de todo el "renderwall".

Un servidor de ficheros, por sí solo, no podría ofrecer el ancho de banda necesario para entregar los conjuntos de texturas, de forma que desarrollamos un proceso de publicación diseñado para crear réplicas de cada conjunto de texturas nuevo tras su creación. Esto se ilustra en la Figura 1.

Método antiguo para incrementar el ancho de banda para conjuntos de texturas.

Figura 1) Método antiguo para incrementar el ancho de banda para conjuntos de texturas.

Cuando un trabajo que se ejecutaba en el "renderwall" necesitaba acceder al conjunto de texturas, elegía un servidor de ficheros aleatorio y accedía a las texturas desde esa réplica. Al poder repartir la carga de texturas en varios servidores de ficheros, este proceso mejoró significativamente el rendimiento. Se trataba de una solución mejor que confiar en un único servidor de ficheros; sin embargo, los procesos de publicación y replicación eran complejos y requerían comprobaciones de coherencia, que llevaban mucho tiempo, para asegurarse de que las réplicas eran idénticas.

Comenzamos a considerar FlexCache® y el acelerador del almacenamiento SA600 de NetApp como la forma más sencilla de solucionar los problemas de rendimiento que creaban los conjuntos de texturas. El software FlexCache crea, en la infraestructura de almacenamiento, un nivel de caché que se adapta automáticamente a las distintas necesidades de uso, lo que se refleja en la eliminación de cuellos de botella y en el aumento del rendimiento. Hace réplicas de forma automática y entrega conjuntos de datos activos en la infraestructura mediante volúmenes locales de almacenamiento en caché.

En lugar de copiar manualmente los datos de texturas a servidores de ficheros múltiples, FlexCache nos permitía almacenar en caché de forma dinámica las texturas más utilizadas en esos momentos y ofrecerlas al "renderwall" desde los SA600. Probamos la solución y comprobamos que funcionaba realmente bien en nuestro entorno; así que ocho meses antes de terminar Avatar, decidimos arriesgarnos e instalamos cuatro sistemas SA600, cada uno de ellos con dos módulos Performance Acceleration Module (PAM) de 16 GB. (PAM se utiliza como una memoria caché para reducir más la latencia).

Método mejorado de incremento del ancho de banda para los conjuntos de texturas mediante el uso de FlexCache, SA600 y PAM de NetApp.

Figura 2) Método mejorado de incremento del ancho de banda para los conjuntos de texturas mediante el uso de NetApp FlexCache, SA600 y PAM de NetApp.

El conjunto de texturas total tenía un tamaño aproximado de 5 TB, pero una vez implantado FlexCache, nos percatamos de que solamente 500 GB estaban activos en todo momento. Cada SA600 disponía de suficiente espacio en el disco local para aceptar el conjunto de datos activos y, cuando este fluctuaba, la memoria caché se adaptaba sin necesidad de que tuviésemos que hacer nada. El rendimiento total era superior a 4 GB/s, mucho más de lo que nunca antes habíamos conseguido.

El almacenamiento en caché de texturas con FlexCache fue una solución excelente. Gracias
a él, todo iba más rápido y se simplificaba la tarea de gestionar conjuntos de texturas. Nos encontrábamos en el último año de un proyecto cinematográfico de cuatro. Si tras instalar los SA600 hubiésemos tenido problemas que no hubiésemos podido solucionar con rapidez, probablemente los hubiésemos tenido que sustituir. Pero tras una semana, prácticamente nos olvidamos de ellos hasta finalizar la película. Esta es la forma de hacer que el personal de TI se sienta lo más satisfecho posible.

El rendimiento del almacenamiento tiene un efecto enorme en la velocidad a la que se produce la renderización. Los cuellos de botella del almacenamiento pueden taponar el rendimiento de la red de renderización. En los últimos años de Avatar, comenzamos a profundizar en ese tema, y añadimos muchísimas capacidades y estadísticas de supervisión en cada trabajo.

Había una constante acumulación de tareas a la espera de ser ejecutadas; cada día se acumulaban más de las que podíamos completar. El equipo de "vaqueros" de Weta Digital supervisa los trabajos para asegurarse de que todo se desarrolla como corresponde. La mañana tras la implantación de FlexCache, el jefe de los "vaqueros" entró en mi despacho para informarme de que todas las tareas se habían completado. Había ido tan rápido que pensó que algo había fallado.

Razones para elegir NetApp

Soy seguidor de NetApp desde hace mucho tiempo. Lo utilicé por vez primera cuando trabajaba como proveedor de servicios de Internet en Alaska durante el boom de los dominios "punto com" a finales de los años 90. Estaba tan satisfecho que, posteriormente, introduje el almacenamiento de NetApp en otras empresas. Fue muy grato comprobar que cuando me incorporé a Weta Digital ya se utilizaba el almacenamiento de NetApp.

Para una empresa como Weta Digital es normal que algo falle, porque nadie más fuerza la infraestructura como ella. La clave está en que, cuando algo falla, se necesitan proveedores que ayuden a arreglarlo. Incluso cuando trabajé en empresas más pequeñas, en NetApp, siempre había alguien dispuesto a tomarse el tiempo de ayudarme con un problema hasta que se solucionara. Quizá se pueda pensar que esto es lo habitual, pero según mi experiencia, en realidad es bastante raro.

El almacenamiento puede ser algo complejo. La tecnología de NetApp lleva el almacenamiento a su estado más simple. Hay aspectos que me gustaría que NetApp mejorase, pero, en comparación con el resto de cosas que he visto, NetApp es un producto versátil, fácil de utilizar y, además, respaldado por su soporte técnico. Estas son las razones por las que seguimos eligiendo NetApp.

Comunidad de NetApp
 ¿Algún comentario sobre el almacenamiento en caché adaptativa?

Formule preguntas, intercambie ideas y comparta sus opiniones
en las comunidades en línea de NetApp.


Adam Shand

Adam Shand
Anterior Jefe del Equipo de Infraestructura
Weta Digital

Adam comenzó su carrera de TI en Nueva Zelanda, donde, junto con su padre, fundó una de las primeras empresas de Internet del país. Su siguiente trabajo, en 1997, le llevó a Internet Alaska y, posteriormente, trabajó en el sector de ADE en Portland, Oregón. Las similitudes entre ADE y los efectos especiales, junto con la oportunidad de acercarse a su hogar, llevaron a Adam hasta Weta Digital en 2003. Tras siete años en esta empresa, Adam decidió cambiar Weta Digital por un merecidísimo descanso en forma de año sabático a su cargo en el sudeste asiático.

 
En profundidad