大导演詹姆斯·卡梅隆的旷世巨作《阿凡达》(AVATAR) 好评如潮，观众无不被片中呈现的美轮美奂的画面所震撼。电影惊人的动画效果由 Weta Digital 公司制作，我们可以从这篇 Processing AVATAR 了解到一点关于制作该片特效的超级计算机的情况。
Weta Digital 的计算集群在 2008 重新进行了设计，采用了 HP Cluster Platform 3000BL 集群平台作为其解决方案， 操作系统是 Linux ，在 TOP 500 超级计算机中排名也从最初的 400 多上升到了 190 多名(refer)。这套环境在 2008 年的时候是 4096 个 Core，到 2009 年增加到 5936 个(refer)，而不是所说的 40000 个 (refer，我猜测是笔误)，在 TOP 500 超级计算机中一度排名第一的 IBM 的走鹃（Roadrunner），也不过才 12 万个核而已。
总内存有 104 TB，内联采用的是万兆以太网，没有使用 Infiniband 。BL2x220c 是惠普面向高性能计算推出的刀片服务器，其独到之处是一个刀片内放两台服务器，每服务器有两个 4 核 CPU，用的是 Intel Xeon 处理器(支持 EM64T 技术)。
整部电影大约 3 PB 的数据存放在 BlueArc 和 NetApp 的存储上，数据传输走光纤通道。电影完成时一帧的数据是 12 MB，一秒钟 24 帧，每分钟的数据就有 17.28 GB，而整部 AVATAR 长达 160 多分钟。我想不会有哪个人在自己的 PC 上有这么样的一部电影吧，恐怕也是没办法播放的。
Weta Digital 大有来头，这是彼得·杰克逊（Peter Jackson）创建的公司，因为给《指环王》制作特效而受到业界瞩目，其实还有不少电影，比如《金刚》《机械公敌》以及前不久的 《2012》，也都是由 Weta Digital 制作的特效。不知道我们国内的导演有没有创建过类似的公司，当然，我相信他们对动画特效的运用与理解恐怕还差得很远。
计算机集群能力的提升从一定程度上推动电影艺术的发展，对电影来说，电影越来越好看，票价也是越来越贵。而因为摩尔定律依然有效，计算机集群的运算能力是逐年提升的，成本反而下降，只要能取得更震撼的视觉效果，剧情不太白痴，投入产出似乎倒也是一笔明白账。
–EOF–
原文是说电影完成时每帧的数据量是12MB，不是说最后一帧是12MB。 ：） 不过Avatar真是一部不错的电影！
为啥是3PB呢? 貌似是3TB?
“不知道我们国内的导演有没有创建过类似的公司”
国内就算是IT公司，看重技术的都没几家，更不要说娱乐行业了。
Urumchi 的评论:
为啥是3PB呢? 貌似是3TB?
3TB才等于1024GBX3，市场上随便找3块1TB硬盘就可以了，你觉得可能吗？
————-
貌似“数据传输走光线通道。”笔误？
根据“17.28 GB/min”、 “160分钟”，计算出来应该是约3TB吧？
3PB是原始数据吧 3TB只是渲染过的视频文件
3TB是最终的数据吧..
前期制作需要很多数据…各个版本都要寸起来…这样达到3PB也正常…
我曾是一家叫无限影像的三维动画的网络管理员，我知道动画是逐帧渲染出来的JPEG图片，然后合成为AVI，再剪辑和配音成为电影的，最终输出为DVD的时候实际上是用MPEG2压缩的。
如果 根据“17.28 GB/min”、 “160分钟”，计算出来应该是约3TB，这是成品电影的体积，但原始AVI或原始的JPEG图片可能是3PB的体积。
过几天再去看..
现在买票都不方便..!
^_^
也准备看看
计算机集群太虎了，陆川导演也能感慨，电影没看过想看。
明天就可以看了，呵呵。
第一次来到，留下个脚印咯。
这个博客不错！！！
该域名没有备案叶。
3TB,TB才到PB.差点被骗了.
看了阿凡达，拍的不错，建议大家都去看啊
我不懂技术，我知道我的公司还有很多路要走。肯定上不了这些名单。
Render farm 完全是拼“体力”的活，十年前和现在没什么区别，除了核的数量是几何级数倍的。
可怜的 SGI 啊，Rackable 也没能救得了它么，昔日的超级计算机霸主
现在TOP 500 超级计算机已经被 IBM 拿下来许多了
《阿凡达》的幕后英雄：存储集群NAS
http://www.searchstorage.com.cn/showcontent_31322.htm
【TechTarget中国原创】随着《阿凡达》的全球热映，为影片制作数字特效的新西兰公司Weta Digital也越来越受到关注。据该公司介绍，影片中的细节动画所需要的马力远远超过一个集群NAS系统自身能够提供的马力。
为了支持该项目，其中包括3D角色脸部动画的新突破，Weta Digital建立的存储系统结合了BlueArc的Titan 集群NAS阵列以及NetApp的FlexCache。随着特效变得越来越先进，对容量和性能的要求开始超过Weta Digital之前支持过的最大系统，例如2005年的《金刚》。“《金刚》使用了100 TB的存储，”Weta Digital首席技术官Paul Ryan说，“而《阿凡达》，（我们的服务器群）就有100 TB的RAM。”
为了支持数字特效的渲染过程，Weta Digital有一个服务器群，被称为“渲染墙”，包含35,000个CPU内核。 在渲染过程中，同一图像的多个层次和局部画面合并形成一帧完整的电影画面。“这给存储造成了一些有趣的问题，”瑞恩说， “也就是说，我们会碰到这种情况，‘渲染墙’中有一万个过程同时试图访问同一文件或文件组，从而导致了我们存储中的热点。”
大文件的服务者：Titan
为了缓解这一问题，该公司首先引进了三个四节点的配置，是BlueArc的Titan 3200集群NAS系统，每个系统拥有200TB容量，来支持《阿凡达》。BlueArc系统的市场定位是为数量大的大文件提供服务，而像Weta digital这样的媒体和娱乐公司通常使用大文件。一个配置完全的3200集群可以容纳高达4PB的容量；BlueArc声称，3200可以支持高达20万IOPS或高达20 Gbps的吞吐量。Ryan介绍，Weta Digital曾经使用过一个Titan 3200群集。
但仍存在另一个问题。 “我们有一个纹理数据，是一个相当小的数据集, 总共在1TB到5TB，但几乎每一个在‘渲染墙’的过程都想访问该纹理数据。”Ryan说。由于这种数据访问模式，“我们发现，无论我们分配多大的带宽给纹理数据，渲染墙都将消耗所有的带宽。”
“热”数据的复制者：FlexCache
Ryan说：“我们和NetApp合作已久。”估计Weta Digital使用NetApp 文件服务器至少有十年之久，公司已经有将近600TB的NetApp存储用来服务用户文件共享。 约九个月前，Weta Digital 引进了一个新的双节点高可用性集群，是NetApp的高端FAS6080集群系统，以及也是配置成双节点高可用性的集群：八台NetApp的FlexCache设备。
NetApp的FlexCache旨在支持类似Weta Digital 渲染墙这样的应用。它通过使用本地缓存卷自动复制“热”数据，从而适应不断变化的使用模式。
虽然NetApp和BlueArc的系统不相互“交谈”，但Weta Digital找到了一种方法，让它们有效地共存。 NetApp的集群负责提供数据给渲染墙，而BlueArc的系统负责存储渲染系统产生的电影画面。 “我们知道BlueArc的产品不错，我们也知道它们速度快，而且绝对符合我们的期望值。”瑞恩说， “但是，在过去的一年中令我们眼前一亮的新事物是FlexCache。”
Ryan说，自动性能管理是FlexCache的一大亮点。 “我们以前用过普通文件服务器来服务纹理文件，但是这需要我们手动对复制进行管理。我们不得不在许多不同的文件服务器上都保留这些纹理文件的副本。”他说。
虽然目前的设置运作良好，“我们一直在寻找更加细化的工具来寻找存储热点以及哪些用户试图访问，”Ryan说，“增加BlueArc的功能可以延迟问题的出现，FlexCache则提供更多的带宽。不过，当热点出现时，如何对热点进行分析，仍然存在一定的难度。”
40,000个core不是笔误。top 500那里的”core”实际上是node，真正的core＃ ＝ 5936 × 2 × 4。
可以自己算算准确的数目：
http://www.datacenterknowledge.com/archives/2009/12/22/the-data-crunching-powerhouse-behind-avatar/说了里面有34个rack,每个rack32个machine, hp的BL2X220c中的每个machine有2*4=8个core。
所以当时他们的core# = 34 * 32 * 8 = 34, 816 cores。文章有的地方用40,000，有的地方35,000，都是靠谱的数据。
Top500的数据可能是系统升级后的，所以多了一些。