| Twitter | Del.icio.us | Comments (20) | | Edit

Comments Powered by Disqus

留言评论 | Comments (20)

原文是说电影完成时每帧的数据量是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 也没能救得了它么,昔日的超级计算机霸主

《阿凡达》的幕后英雄:存储集群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的数据可能是系统升级后的,所以多了一些。

相关文章

关于本文

这篇文章由 Fenng 于 January 4, 2010 10:59 PM 发布.

上一篇:编程要趁早.

下一篇:2009年国内值得关注的初创公司.

回到 首页 查看最近发表的文章或者查看所有 归档文章.