NetApp Tech OnTap
     

Die Geburt von Avatar

Avatar brach alle Rekorde an den Kinokassen und spielte weltweit mehr als 2,7 Milliarden Dollar ein - und ein Ende ist noch nicht absehbar. Weta Digital, die für die Visual Effects des Films zuständige Firma, setzte mit den verblüffenden 3D-Effekten von Avatar selbst völlig neue Maßstäbe. Weta Digital hatte bereits mit der Trilogie Der Herr der Ringe und anderen kürzlich erschienenen Filmen große Erfahrung in der Entwicklung beeindruckender Bilder gesammelt. Dennoch erwies sich die Produktion von Avatar als enorme technische Herausforderung.

Ein noch nie da gewesener Rechen- und Speicherbedarf musste gedeckt werden. Weta Digital hatte gerade die Arbeiten an King Kong beendet, als im Jahr 2006 die Produktion von Avatar begann. Zu dieser Zeit hatte das Unternehmen etwa 4.400 CPU-Kerne in seiner Renderwall und etwa 100 TB Storage. Am Ende der Produktion von Avatar verfügte man über etwa 35.000 CPU-Kerne in der Renderwall und 3.000 TB Storage. Allein die zu dieser Zeit verfügbare RAM-Kapazität in der Renderwall überstieg die gesamte Festplattenspeicherkapazität nach King Kong.

Ich fing im Jahr 2003 bei Weta Digital als Systemadministrator an, gerade als der letzte Film der Herr der Ringe-Trilogie produziert wurde. Meine Funktion war die Leitung des Infrastrukturteams. Dieses Team war für alle Server, Netzwerke und den gesamten Storage verantwortlich. Es war unsere Aufgabe, die Infrastruktur aufzubauen, die Avatar möglich machte, und auftretende technische Probleme zu beheben.

Bewältigung der Skalierung

Trotz des enormen Wachstums, das mit der Produktion von Avatar einherging, war das Management dieser neuen Größenordnungen nicht so schwierig, wie wir befürchtet hatten. Das lag zum größten Teil daran, dass wir ein erfahrenes Team waren, das gut zusammenarbeitete. Wir legten uns also ins Zeug, und wenn etwas schief ging, waren wir zur Stelle, um Hand anzulegen. Auch konnten wir meist agieren, anstatt zu reagieren.

Wir begriffen schnell, dass zwei große Schritte notwendig waren, um Avatar zu realisieren.

  • Errichtung eines neuen Datacenters. Weta Digital verfügte über mehrere kleine Maschinenräume, die auf zahlreiche Gebäude verstreut waren. Mit einem neuen Datacenter an einem zentralen Standort sollte die Infrastruktur konsolidiert werden, die wir für das Avatar-Projekt brauchten. (Details zum Datacenter siehe rechts.)
  • Einrichtung eines Hochgeschwindigkeits-Glasfasernetzes. Weta Digital hatte keinen lokalisierten Campus. Stattdessen bestand unser Campus aus mehreren unabhängigen Gebäuden in mehreren Vororten von Wellington. Wir implementierten ein Hochgeschwindigkeits-Glasfasernetz, um diese Gebäude mit dem neuen Datacenter zu verbinden. Jedes Gebäude war jederzeit mindestens über redundante 10 GBit/s-Verbindungen mit 40 GBit/s-EtherChannel Trunks verbunden, wenn der Storage und die Renderwall miteinander kommunizieren mussten.

Diese beiden Elemente machten es physisch möglich, unsere wachsende Infrastruktur sowie die Bandbreite zu skalieren, um Daten zwischen den Standorten übertragen zu können. Mit HP Blade Servern wurde eine neue Serverinfrastruktur für die aktualisierte Renderwall errichtet. Mit 8 Kernen und 24 GB RAM pro Blade konnten wir 1.024 Kerne und 3 TB RAM pro Rack bereitstellen. Das neue Datacenter wurde in Reihen von 10 Racks organisiert, sodass wir unsere Server in Einheiten von 10 Racks oder 10.240 Kernen aufbauen konnten. Nach den ersten 10.000 Kernen warteten wir eine Weile, fügten weitere 10.000 hinzu, warteten wieder, fügten weitere 10.000 und schließlich die letzten 5.000 Kerne hinzu, um die Implementierung zum Abschluss zu bringen.

Die Storage-Infrastruktur bestand aus Storage von verschiedenen Anbietern, aber das Herzstück war ein NetApp Storage-System mit etwa 1.000 TB. Am Ende der Produktion von Avatar hatten wir alle alten FAS980- und FAS3050-Systeme durch FAS6080-Cluster ersetzt. In den letzten acht Monaten des Projekts implementierten wir darüber hinaus vier SA600 Storage Acceleration Appliances, um ein sehr lästiges Performance-Problem zu beheben.

Beschleunigung des Zugriffs auf Strukturdateien mit adaptiver
Cache-Speicherung

In der Branche der Visual Effects versteht man unter einer Struktur ein Bild, das auf ein 3D-Modell angewendet wird, damit dieses echt aussieht. Das Modell wird von Strukturen umgeben, um ihm Tiefe, Farbe und Schattierung zu verleihen. Dadurch wirkt es lebendiger als ein normales, undifferenziertes Modell. Bei Strukturdaten handelt es sich um sämtliche Bilder, die auf ein bestimmtes Modell angewendet werden müssen, damit es wie ein Baum, ein Tier oder eine Person aussieht. Die meisten Darstellungen, die ein Objekt enthalten, wenden Strukturen auf das Objekt an. Die Renderwall hat einen hohen Bedarf an diesen Strukturen, die immer wieder verwendet werden.

Mehrere tausend Kerne können jederzeit Bedarf an einer bestimmten Gruppe von Strukturen haben. Weitere tausend Kerne wiederum können Bedarf an einer überlappenden Gruppe haben, usw. Alles, was wir tun können, um die Geschwindigkeit der Übertragung von Strukturen zu beschleunigen, wirkt sich massiv auf die Performance der gesamten Renderwall aus.

Da ein einzelner Dateiserver nie die nötige Bandbreite für unsere Strukturdaten liefern konnte, haben wir einen Prozess zur Erstellung von Replikaten für jede neu erstellte Struktur entwickelt. Siehe Abbildung 1.

Alte Methode zur Vergrößerung der Bandbreite für Strukturdaten.

Abbildung 1) Alte Methode zur Vergrößerung der Bandbreite für Strukturdaten.

Wenn eine Aufgabe, die von der Renderwall ausgeführt wurde, auf Strukturdaten zugreifen musste, wurden Replikate der Strukturen durch einen beliebigen Dateiserver aufgerufen. Da die Verarbeitung der Strukturen auf mehrere Dateiserver verteilt wurde, konnte die Performance bedeutend gesteigert werden. Dies war besser, als sich auf einen einzelnen Dateiserver zu verlassen. Allerdings verlangten die komplexen Verteilungs- und Replizierungsprozesse die Durchführung von zeitaufwändigen Konsistenzprüfungen, um die Übereinstimmung der Replikate sicherzustellen.

Nun sahen wir in NetApp FlexCache und dem SA600 Storage Accelerator eine einfachere Möglichkeit, die von den Strukturdaten verursachten Performance-Probleme zu lösen. FlexCache erstellt eine Caching-Schicht in der Storage-Infrastruktur, die sich automatisch an das sich ändernde Nutzungsverhalten anpasst und so Performance-Engpässe verhindert. Die Software repliziert Hot Data Sets und stellt diese durch Verwendung lokaler Caching Volumes automatisch an jedem beliebigen Ort in der Infrastruktur bereit.

Anstatt unsere Strukturdaten manuell auf mehrere Dateiserver zu kopieren, konnten wir mit FlexCache die aktuellen Strukturen dynamisch zwischenspeichern und über die SA600-Systeme an die Renderwall weitergeben. Wir testeten diese Lösung und stellten fest, dass sie in unserer Umgebung sehr gut funktionierte. Acht Monate vor der geplanten Fertigstellung von Avatar wagten wir es daher, vier SA600-Systeme mit je zwei 16 GB Performance Accelerator Modulen (PAMs) zu installieren. (PAMs dienen als Speicher-Cache zur Reduzierung der Latenz.)

Verbesserte Methode zur Vergrößerung der Bandbreite für Strukturdaten mithilfe von NetApp FlexCache, SA600 und PAMs.

Abbildung 2) Verbesserte Methode zur Vergrößerung der Bandbreite für Strukturdaten mithilfe von NetApp FlexCache, SA600 und PAMs.

Die Gesamtgröße der Strukturdaten betrug etwa 5 TB. Sobald jedoch FlexCache installiert war, stellten wir fest, dass nur etwa 500 GB davon genutzt wurden. Jedes SA600 hatte genug lokalen Festplattenspeicher für die Hot Data Sets, und wenn diese sich veränderten, passten sich die Cache-Speicher an, ohne dass ein Zutun unsererseits erforderlich war. Der aggregierte Durchsatz war größer als 4 GB/s - weit mehr als je zuvor.

Die Cache-Speicherung von Strukturen mit FlexCache war ein durchschlagender Erfolg. Dadurch wurden Abläufe beschleunigt und das Management der Strukturdaten vereinfacht. Wir befanden uns im letzten Jahr eines Vierjahres-Filmprojekts. Wären Probleme aufgetaucht, die wir nicht rechtzeitig hätten beheben können, dann hätten wir die SA600-Systeme wahrscheinlich wieder entfernen müssen. Nachdem aber eine Woche verstrichen war, zerstreuten sich unsere Bedenken, und es gab bis zum Ende des Filmprojekts keinerlei Schwierigkeiten. Es gibt nichts, das einen IT-Techniker glücklicher macht.

Die Storage-Performance hat großen Einfluss auf die Geschwindigkeit der Bildaufbereitung. Storage-Engpässe können den Durchsatz Ihrer Renderfarm verringern. In den letzten Jahren des Avatar-Projekts befassten wir uns intensiver mit dieser Problematik und richteten zahlreiche Überwachungsfunktionen und Statistiken für sämtliche Prozesse ein.

Es gab ständig einen großen Überhang an unerledigten Aufgaben. Jedem Tag standen viel mehr Bildaufbereitungen an, als die Renderwall bewältigen konnte. Die Techniker des Weta Digital Teams überwachten die Aufgaben, um die ordnungsgemäße Erledigung sicherzustellen. Am Morgen nach der Installation von FlexCache kam der leitende Techniker in mein Büro, um mir mitzuteilen, dass alle Aufgaben erledigt waren. Es ging wider Erwarten alles so schnell, dass wir befürchteten, etwas falsch gemacht zu haben.

Warum NetApp?

Ich bin seit langem ein großer Fan von NetApp. Ich verwendete NetApp erstmals, als ich während des Dotcom-Booms in den späten 90er Jahren für einen ISP in Alaska arbeitete. Ich war so beeindruckt, dass ich NetApp Storage später in vielen anderen Unternehmen einführte. Als ich bei Weta Digital anfing, sah ich zu meiner Freude, dass NetApp Storage dort bereits eingesetzt wurde.

Bei einem Unternehmen wie Weta Digital gehören IT-Schwierigkeiten zum Tagesgeschäft, denn kaum jemand sonst hat eine so rasant wachsende Infrastruktur wie Weta Digital. Wenn etwas nicht funktioniert, braucht man Dienstleister, die einem bei der Problembehebung helfen. Selbst als ich in kleineren Unternehmen beschäftigt war, fand sich stets ein Mitarbeiter von NetApp, der sich die Zeit nahm, mit mir über ein Problem zu sprechen und eine Lösung zu finden. Vielleicht halten Sie eine solche Unterstützung für selbstverständlich. Meiner Erfahrung nach aber geschieht dies recht selten.

Mit Storage können komplexe Anforderungen verbunden sein. NetApp Technologie macht Storage so einfach wie nur möglich. Es gibt Dinge, die NetApp meiner Meinung nach hätte besser machen können. Aber im Vergleich zu allem anderen, das ich erlebt habe, bietet NetApp vielseitige, einfach zu handhabende Lösungen und den entsprechenden Support. Aus diesem Grunde bleibe ich bei NetApp.

NetApp Community
 Was ist Ihre Meinung zur Cache-Speicherung?

Stellen Sie Fragen, tauschen Sie Ideen aus und äußern Sie Ihre Ansichten online in den NetApp Communitys.


Adam Shand

Adam Shand
ehemaliger Leiter des Infrastrukturteams bei
Weta Digital

Die IT-Laufbahn von Adam Shand begann in Neuseeland, wo er zusammen mit seinem Vater eine der ersten Internetfirmen Neuseelands gründete. Sein nächster Job führte ihn 1997 zu Internet Alaska. Anschließend war er in der EDA-Branche in Portland, Oregon tätig. Die Ähnlichkeiten zwischen EDA und Visual Effects sowie die Möglichkeit, wieder in seiner Heimat zu arbeiten, führten Adam Shand im Jahr 2003 zu Weta Digital. Nach sieben Jahren bei Weta Digital beschloss Adam Shand, das Unternehmen zu verlassen und zur dringend benötigten Erholung ein selbstfinanziertes Urlaubsjahr in Südostasien zu verbringen.

 
Weitere Infos hier