Render Farm方案.docx
- 文档编号:30037579
- 上传时间:2023-08-04
- 格式:DOCX
- 页数:17
- 大小:152.06KB
Render Farm方案.docx
《Render Farm方案.docx》由会员分享,可在线阅读,更多相关《Render Farm方案.docx(17页珍藏版)》请在冰豆网上搜索。
RenderFarm方案
RenderFarm方案
一、RenderFarm介绍
Renderfarm(渲染工场)其实是一种通俗的叫法,实际上我们应该叫他“分布式并行集群计算系统”,这是一种利用现成的CPU、以太网和操作系统构建的超级计算机,它使用主流的商业计算机硬件设备达到或接近超级计算机的计算能力。
渲染工场是一个高性能、高可靠、低成本的解决方案,支持以下三维及合成软件的网络渲染。
集群(cluster)指的是一组计算机通过通信协议连接在一起的计算机群,它们能够将工作负载从一个超载的计算机迁移到集群中的其他计算机上,这一特性称为负载均衡(loadbalancing),它的目标是使用主流的硬件设备组成网格计算能力,达到、甚至超过天价的超级计算机的计算性能。
目前的集群技术绝大多数都具有负载平衡的特性,他们主要应用于科学计算,这种技术应用于电影电视、CG行业时,因为主要用来解决长时间的图像渲染问题,所以被称为“Renderfarm(渲染农场)”
二、农场架构介绍
对于用户而言,渲染农场的搭建,技术难度并不完全在可见硬件设备的上,而是整体工作流程的科学规划。
通常用户关心的是:
∙渲染引擎的正常调用
∙在相同硬件和网络平台下,提交任务的速度和性能
∙渲染过程不丢失数据
∙系统扩展性能
∙失败任务修复
∙主流渲染软件的支持
∙能否支持静祯分割渲染
∙用户界面
软件架构
通常而言,渲染农场必要的部分包括如下三个:
任务分发、渲染、文件存储。
任务分发节点,通常被叫做Master、Manager或者Dispather。
负责中心调度,接受任务提交、分配、结果回收等。
这部分一般做成系统服务,并提供众多控制台接口和网络接口,以便上层GUI调用。
因为任务分发是整个系统的中心所在,所以很多其他部分也会放在这里,例如:
渲染节点的管理,用户管理,日志等等。
渲染节点,一般被称为Slave、Node、RenderClient等。
当任务分发节点将任务(Job)分割并分派后,渲染节点是实际运行子任务(Task)的节点。
这些节点一般是多核的高端机器,运行在节点上的软件一搬也作为系统服务。
如前文所提到的,因为操作系统license的问题,渲染节点支持Linux是一个普遍的需求。
文件存储节点,叫做Filerepository。
大部分的集群管理软件选择使用了局域网络共享协议,所以会将相关的文件夹共享,用来支持场景读取、图像存储等工作。
文件存储节点,可以集成在Master机器上,也可以单独的是一台PC机,在重量级的系统中,文件存储是单独的节点,一般为高性能磁盘阵列。
有了上述三个节点,整个系统就可以工作了。
当然,用户不希望整个系统的使用沉溺在各种控制台命令之中。
任务的提交,进度的查看,错误的分析,这些部分都是系统和用户之间沟通用的。
系统管理,一般叫Monitor、WebMonitor、Explore之类。
成熟的系统中,用户界面和底层系统内部逻辑是完全分离的。
甚至用户界面都是用脚本配置的,以便于系统的拓展。
用户管理系统登录连接上Master机器,读取系统状态。
用户关心的内容主要是:
任务(Job)排队状态、当前任务运行状态、渲染节点工作状态、任务(Task)分配、结果查询。
渲染器支持
专业渲染管理软件和自带工具的最大区别在于,是否支持各种主流渲染器。
举个例子,如果某个工作团队使用Maya做动画,用3DMax做建筑效果,用AfterEffect做后期合成特效,那么这个渲染农场系统至少要能同时为这三种任务做划分,然后并行渲染。
显然,任何一个自带工具(如Vraydistributedrendering、Backburner、Mayasatellite)都是无法胜任的。
渲染器的支持有几种不同的方法。
首先是调用渲染器的控制台程序,其次是用插件的形式在创作工具内部嵌入直接提交的功能。
支持三方插件的软件,比如Maya和3DMax,都可以在程序中嵌入任务提交界面。
本质而言,无论支持何种渲染器,都是从调用控制台程序开始的。
例如Maya的渲染控制台文件是”Render.exe”,按照Maya的命令行手册调用这个程序,就能在渲染节点渲染某个场景。
调用”Render.exe”不会启动用户界面,所以会比较节省计算资源。
多渲染器的支持,需要做接口抽象,将所有渲染器的共同点提取出来。
共通点包括:
场景文件、起始帧、终止帧、结果存放文件夹等。
定义了这些抽象的字段之后,实际上可以支持任意的渲染器,只要渲染器提供了相关的接口。
将这些规则做成用户手册,指导用户按照一定的格式自己可以定制新渲染器支持,包括自行开发的渲染器。
任务分割
任务分割是并行发生的基本要素,是从Job细分到Task的过程。
单帧量图像渲染,从屏幕空间对图像分割,每一块图像为一个子任务。
动画任务由一系列的单帧组成。
屏幕空间的划分,在3DMax的建筑效果渲染任务中比较常见。
但不是每一种渲染器都支持屏幕空间的划分,所以,这个特性不是通性,如果在渲染农场管理软件中很好的支持这一功能,有便捷的用户界面支持,也是一种“先进”之处。
更多的情况下,渲染农场处理的是动画任务,大部分的管理软件会把任务直接细分到单帧,也就是说每一个Task是一个动画帧,例如48帧动画中的第2帧就是一个Task。
这样的单帧任务划分方式,在一些应用下会降低整体渲染效率。
例如100帧的动画,20台渲染节点,平均每台渲染节点需要处理5帧动画。
如果5帧动画作为Task单独渲染,渲染节点需要不断的加载场景,关闭,再加载场景。
如果给渲染节点直接分配连续5帧的动画,那么场景只需要加载一次,场景之间的一致性也会较高。
上图是一个10帧任务划分的例子,一种方式是划分为10个单独的Task,另外一种方式,对Task进行了捆绑,当然这种捆绑需要一定的原则。
调度方法
理想的状态下,Task的数量正好和Node节点的数量一致,并且每一个Node节点都是一样的机器,场景复杂度也一样,最终Task会同时完成。
不过这样的情况极少发生,场景的复杂度通常是不一样的,极端的时候渲染节点之间的性能差距很大,是一种异构环境。
这个时候就需要调度算法,无论什么调度算法,从渲染农场整体利用率来看,是要让每一台机器都不空闲,最大程度的利用计算资源。
从单个任务(Job)完成的角度来看,最快速度完成某一个任务也是一个评判标准。
一种简单有效的一种方式,叫做需求驱动。
将所有的任务全部都细分为单帧Task,每当渲染节点空闲并可用时,叫像任务分发节点请求任务一个Task,完成之后,返回结果,再申请新的Task。
因为Task在计算的时候,总时间消耗是场景加载加上渲染。
场景加载又分为网络读取、场景初始化两部分。
假设一帧完成的时间是T,由网络读取时间tn,场景初始化ts,和渲染时间tr组成。
有T=tn+ts+tr。
一个任务有n帧,总时间=nx(tn+ts+tr)。
可以看到,n越大,消耗在不断的网络传输,场景加载上的时间越多,即使在本地保存副本,尽量省去tn这部分的重复工作,ts仍然造成了一定的资源浪费。
其他的调度方法,则更多的从任务本身的角度去考虑。
如上一节中提到的任务分割方法,在已经知道能够使用的渲染节点的前提下,将任务“包装”起来,一并发送给指定的渲染节点。
这种方式在tn和ts部分算法复杂度为O
(1),相比于上一种的O(n),效率提高。
但当某一台机器因为性能低,完成速度慢于其他机器时,负载不平衡的情况很容易出现,这个时候,再重新分派任务比较困难,如果重新分派,会造成重复计算。
可以发现,这两种方式,是用灵活度换取性能,还是牺牲性能获得调度自由的两难问题。
那么理想的方式为,在第一种方法下取消ts这个障碍。
正如Qube描述过的“动态划分”方法,如果能够控制渲染器在单帧结束后,不卸载场景数据,而是等待新的帧任务到来的话,性能将会有很大程度的提升。
假设能有这么一种“动态划分”的的算法存在,上图演示了一中利用连续场景之间的coherent,又能由自由调度的“两全其美”的方式。
N帧的动画任务,按照渲染节点的性能评价,不等份的将Task“打包”预指定给对应的Node节点。
Job的渲染过程开始之后,将单帧Task发送到预定的Node节点,进行计算。
因为有预定,每一个Node都会计算连续动画帧,coherent得到了发挥。
如果发生了负载不平衡的情况,如上图所示的情况,已经完成的节点按照顺序去获取没有计算完成的帧,直到所有的Task都被完成。
这种方法仅仅预期能取得一些效率的提高,单个Job的完成时间将会得到减少。
另外一点,关于异构集群的问题,从理论上来讲,异构集群对负载平衡是有害的。
文件共享方式
渲染农场的工作原理是将本地机器的工作提交给其他机器处理,那么本地场景还有一切的相关文件,都要能被其他机器访问到。
内部文件文件共享有多种方式,按照是否复制副本分为两类。
复制副本的,一般用TCP/IP协议进行文件传输,或者直接用FTP协议实现,也有部分使用Http文件传输方式的(不适合大文件)。
不复制副本的,则是局域网络文件共享协议。
在任务分发节点和渲染节点之间,涉及到数量众多的节点之间的通信,自行实现较为复杂,大多数的渲染农场管理系统选择使用局域网文件共享方式。
在Windows操作系统中,协议为SMB,而在Linux和MaxOS中,协议为Samba。
Samba是模仿windows下的SMB的一种协议,这样这几种不同的操作系统就能局域网内互相分享文件。
大部分的Linux和MacOS的发布版本是带有Samba实现的,而SMB是Windows操作系统默认的部分。
在一些公司的实现方案中,存在中心文件服务器,美工从中心服务器读取场景,进行编辑,再保存回中心文件服务器。
之后的渲染任务不需要从美工机器再次提交到分发节点。
对于一些小公司而言,为了进行集群渲染,首先还是要将自己机器上的工程文件提交给文件服务器(通常和任务分发节点是同一台机器)。
渲染农场的各个部分之间场景文件传输的代价还是比较大的,在工程文件很大的情况下,会比较耗时。
局域网中,一般情况下,FTP的速度不会超过10M每秒,1G的场景每次都需要将近2分钟来传输。
渲染节点较多时,并发的对同一台机器产生传输申请,会造成网络压力。
用户界面
早期集群渲染系统没有太多GUI,许多功能需要调用控制台程序。
随着对用户体验的重视程度越来越高,界面也逐渐人性化。
各种软件的用户界面虽然各有特色,总体而言也遵从一些设计原则。
标识1,菜单栏,任务提交一般在这个栏目。
标识2,通常设计为一个筛选器,用来分类查看任务,或者分类查看渲染节点。
标识3,基本都是为Job运行情况预留的,这里用户查看Job的属性,是否开始计算,进度等等。
标识4,辅助界面,可以用多个Tab来显示关于任务运行的一些相关信息、渲染节点的运行情况等等。
标识5,第二辅助界面,通常显示一些log、统计信息、属性信息等。
界面设计有一些要点,例如Job的状态查看是最重要的,要放在显眼指出,而且每一个Job的Task完成情况也要有界面能方便的看到。
当Job多了之后,就需要能够筛选和查询Job。
任务提交界面无论是从菜单栏拉出,还是在标识5处提交,都要做到分类明确,并可以设置默认提交渲染器。
在拥有所有底层服务接口的基础上,界面和用户交互还有很多的选择。
Web化,或者做成App。
Web界面在很久之前就在渲染农场管理软件中出现,因为一些操作系统的问题,某些管理界面不能在Linux下运行。
在Flash或者silver-light等技术的支持下,用户还是能够有机会享受更好的交互体验的。
展望和趋势
小作坊式的渲染农场,并不需要考虑诸如大规模的数据同步,存储调度等问题。
然而商业运作规律告诉我们,无论是存储还是计算,都不是一定要自行实现。
云概念下的网络基础设施可以被租赁使用,而不需要购买者去维护。
在未来,用户不必为渲染过程下载一堆软件,购买众多机器,而是通过网络提交自己的渲染服务,投资自己消耗的那部分计算。
无论是Google的MapReduce,还是亚马逊的弹性服务,还是Sun、IBM的解决方案。
“云计算”不是新概念,也不是任何一个人或一家公司的想法,而是整个行业思维方法的转变,工业化的分工细分。
2010年的Nvidia技术大会上,用户可以把自己的场景提交给iray的计算集群,GPU优化过的渲染器集群,可以在数十秒内将渲染结果反馈给用户。
同样的任务,需要一台同时代的PC计算几天到几周不等。
在新的基础设施的支持下,我们如何存放场景,如何协同工作,如何提交计算任务,如何获取计算结果,都将一步一步的发生变化。
也许有一天,你也可以加入渲染网络,用你自己的PC或者集群赚点零花钱呢。
三、搭建原则
1)基于2U平台解决方案
在标准的42U机轨上部署运算节点,高性能千兆以太网。
2)强劲的处理器支持
支持最新的四核心处理器,在2U平台上集成两颗物理核心处理器,组成双U双路结构。
3)64位系统构架
采用64位系统架构,良好兼容32位运算,平滑过渡到64位系统。
4)友善的用户界面
没有了缓慢的页面、晦涩难懂的术语和运行怪异的多平台用户界面窗口部件,取而代之的是一个单一完整的Monitor用户界面。
5)对当前各种渲染包的完美支持
除了能够支持所有标准命令行渲染工具,Renderfarm带有针对Maya,3dsmax,DigitalFusion,Lightwave,SoftimageXSI和AfterEffects等软件的自定义编写窗口,通过专门的应用软件脚本或者插件,以实现高效率及可配置性。
广泛的应用程序支持包括:
3dsmaxAfterEffectsCombustionDigitalFusionGelatoLightwaveMayaShakeSoftimageXSI
基于RIB渲染引擎3Delight、AIR、BMRT、Entropy、PRMan、Pixie、RenderDotC脚本和C++SDK插件,支持渲染引擎的脚本,SDK提供强大灵活的特性。
整合RPManager
6)多个工作时间表选项
数字显示的工作优先级、机器资源、指定的并发事件限制群以及特定工作黑名单使您既可以处理有限证件插件和渲染包,也能够准确地在多部门间控制渲染资源的分配。
7)管理和审查
管理特性可选择密码保护。
任何对工作、任务及从属项目更改都可被记录并跟踪。
整合的远程管理功能,如:
设备统计报告(CPU、磁盘空间、存储器、操作系统及修补包)、远程启动/停止/重启从属程序和设备、在远程设备上执行任意命令行。
远程错误报告直接向FranticFilmsSoftware报告渲染错误和一般应用程序错误可以缩短停工期并加快问题的解决。
9)良好的系统兼容性
Renderfarm可以良好的运行于MicrosoftWindowsServer2000、MicrosoftWindows2003Server和运行在Microsoft.NET1.1平台的顶层,他通过向一个Windows共享的文件夹读写文件实现网络渲染,没有必要在贮藏库主机上安装客户端软件。
四、组建方案
五、如何构筑商业渲染农场
指标和标准
1、专业人员服务水准
技术专业程度与熟练程度同等重要,良好的服务技术是大型项目高效低费率完成的保障,熟练的各类故障(软件或插件引起)解决手段是专业农场的必备竞争前提。
2、专业服务设备
大型高端正规服务器集群,高带宽数据调取存储网络、专业操控监测装置是衡量渲染农场专业程度的关键,杂七杂八的杂交集群,或是TCP网络存储都是跑龙套的象征;存储与调取数据不能做到网络分离,更是严重影响大型项目的渲染速度。
3、网络服务能力
全自动网络调取的远程操控程度与专业远程人员的服务能力同等重要;自动服务网络必须借助于终端高带宽的支持,但网络在线人员的半自动服务则目前时期则显得更为实际,就目前软件及插件使用情况来看;不出故障的全流畅运行具备相当大的难度,具备实时值守制度的渲染模式既能即使解决渲染中途出现的故障,又可实时检查渲染成果,做到随错随替,随漏随补。
4、渲染费用
至今全国已经丛生出诸多大大小小的真“农场”、假“农场”,部分是国有投资资产,私营利用;小部分民营投资;更有一半的山寨农场,台式、兼容乱七八糟的混搭,造就了中国商业渲染行业的奇特出生格局。
出生不一,成本必定天差万别;例如北京的某政府机构下属设备,全额政府投资,无房租电费工资之忧,几乎零成本运行;惟有上海和北京的渲染农场是标准3C机房加写字楼,其他都是形式各异的非经营性住宅;对比下来,成本区别更大。
一开始,渲染农场只有上海一家到两家时,定价原则首先是依据成本核算;后来,商业渲染被认为有利可图后,雨后春笋,定价依据就走向了市场。
从此,就再也没有了最低价格;更低的奇迹不断上演。
多数渲染农场只是出卖机器的单纯性能,50套设备掉队20套(根本无人实时监测修缮,空耗能整晚屡见不鲜)居然也是照常收费,于经营者而言成本未变,但于消费者而言,单价低了,总价浪费更明显。
低成本的运营一定是基于低成本的模式,造就的毕竟是低效率的结局。
政府设备浪费资源情有可原,山寨农场空耗掉队则纯粹是无力回天。
渲染客户根据自身项目的收费情况,将高端项目的渲染费用定为6%左右的比例;低端控制在4%左右的比率是最合适的,而非将价格完全推向竞争无序的市场;毕竟质量才是决定因素。
综上,上海渲染农场()全国份额最大,效益相对最好。
北京设备精良,但需要自行操控。
深圳以及其他一些公司无论在技术上还是在规模上对相对落后,竞争手段惟有价格。
六、思路
硬件的选型与搭建仅仅完成了我们工作的20%,你还需要花50%的精力对渲染投资进行规划。
对于渲染农场的搭建,技术难度并不在硬件设备的挑选上,而是整体工作流程的科学规划。
检验集群渲染软件的技术的技术指标主要有以下几点:
1、能否保证渲染引擎能够正常调用?
2、在相同硬件和网络平台下,提交任务的速度和性能如何?
3、能否保证渲染过程不丢失数据:
4、单机拓机,是否影响整体网络性能,并且修复失败渲染任务的方便性如何;
5、能否支持现有的主流三维动画和后期合成软件?
6、能否支持静祯分割渲染?
7、是否简单易用?
8、是否易于维护?
渲染农场的管理软件:
AxceleonEnfuzion(新型集群技术)
是国内最早建立集群渲染的管理软件,中央电视台在Enfuzion的内核上自己开发了中文图形界面,并且一直在使用,Enfuzion是从小型到大型制作公司都适合的管理软件。
Enfuzion其优势
1.Enfuzion不限平台,几乎支持所有的Windows、Osx、Linux版本,包括支持64位操作系统,可以为最新的64位的渲染系统环境,最大的获取硬件性能,
2.Enfuzion支持tilerendering方式,可以将一帧高分辨率的图像,分割成若干画面进行渲染,并且可以设置融合边的宽度,对于复杂计算和电影分辨率渲染尤其有效,这个功能受限于渲染引擎,可以支持mentalray以及Maya扫描线渲染器以及Renderman.
3.Enfuzion对mentalray又很优秀的支持,为大规模使用mentalray进行渲染的时候,使用其他分发软件只是在第一次分发任务时可以渲染成功,但不能自动获取下一个任务来继续工作,要重启才行。
4.图像浏览器和缩略图浏览器方便观看渲染的情况,这是Enfuzion最令人喜爱的独特功能,其他软件需要切换到图像浏览器里去查看渲染结果如果渲染成了TIFF文件就会更加麻烦,但在每个Enfuzion提交节点里都能看到渲染出的缩略图,点击缩略图可以浏览图像,也可以播放渲染序列。
PipelineFXQube
PipelineFXQube以其高贵的出生和传奇的经历获得了最多的关注,早在2001年,squareUSA组建了1500颗CPU的renderfarm系统,并且开发了SQB管理工具用于渲染动画电影《最终幻想》和《骇客帝国》。
随后,SQB发行了商业版本,就是现在的Qube。
优秀的性能,它已经在《最终幻想》和《蚂蚁雄兵》、《怪物史莱克》等动画电影得到应用。
PipelineFXQube其优势
1.Qube有一个多线程管理员技术(专利申请中)。
目前市场上的同类产品中没有一种拥有类似于运行在Qube上的这一引擎,该技术被证实可将渲染时间缩短一半。
2.Qube在应用层面上完全整合了Maya、3dmax、softimageIXSIAfterEffrctshake和Lightwave3d等软件,与各个软件开发公司建立了良好的合作关系。
另外,Qube支持大多数其他接受命令行的程序。
VirtualVertexMuster
Muster是较早拥有图形化界面进行任务分发管理的软件之一,可以说,Muster是最先以GUI界面获得客户好感的管理软件,到现在Muster已有六年历史,最新的5.2版本已经拥有了一系列容易使用的功能。
Muster其优势
1.支持多平台的渲染客户端,Muster需要使用WindowsNT/XP作为渲染器,但可以使用Linux和MacOSX作为渲染服务器。
2.Muster支持主流的应用软件,如,Maya、3dmax、softimageIXSI、AfterEffrct、shake、mentalray.等渲染引擎。
而且价格较低,最小型制作公司最具性价比的选择。
3.支持mentalray等某些渲染器的分割渲染功能,通过几台机器分别对同一台图形进行渲染。
FranticFilmDeadline
Deadline是著名的FranticFilms电影特效制作公司开发的基于Windows的网络渲染管理系统,允许你在Windows上排列和分配,管理电影序列的渲染工作,提供强大高效的3D和2D网络渲染解决方案。
Deadling是在制作公司成长起来的最贴近用户的方案,其用户除了FranticFilms自己以外,还有著名的暴雪游戏公司,对于小型的制作公司,特别3dmax用户来说,是不错的选择。
Deadline其优势
1.支持几乎所有的渲染引擎,Deadline包括已经定制了Maya、3dmax、softimageIXSI、AfterEffrct、shake、mentalray.等应用提交窗口,还支持Blender和Gelato。
2.支持RealFlow流体计算软件。
3.Deadine整合了RenderPassManger管理软件,使它能够为3Dmax提供最优秀的支持。
比如在同一台机器上调用多个3Dmax版本进行渲染,进行良好的用户体验。
4.工作优先权、机器Pools、限制组、特别工作黑名单、等功能允许明确控制分配了的渲染任务,管理不同部门的资源。
Deadline提供了非常详细和精确的的任务日志,不仅可以很方便的找到问题的原因,以最快的速度解决问题。
而且可以为项目管理人员提供详细的工作数据。
5.Deadine支持远程控制软件,如Realvnc等,通过远程计算机操作维护系统。
6.Deadine新版本支持半帧分割渲染
7.节电模式
Drqueue
Drqueue是一个开放源码的集群渲染管理软件,目前支持Maya8的任务提交,其他支持软件包括mentalray,shake,Renderman,以及Blender3D。
Drqueue有一个Drkeewee服务程序用来通信转递渲染任务的情况,这些都可以通过Drqman图形界面来操作渲染任务的停止,重启,优先级别等。
目前在国内外都有一些小的项目在使用Drqueue,比如MartianLa
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Render Farm方案 Farm 方案