【流程】影视和游戏的IT基础设施详解

文章发于微信公众号（DanggooTD），感兴趣的话请关注查看原图文~

最近和朋友合作翻译一本国外的流程书籍，叫《Production Pipeline Fundamentals for Film and Games》，中文译为《电影和游戏生产流程基础》，这里挑了第六章翻译了出来。这章对IT的朋友来说可能很受用，我觉得这里列出的所有要点基本能够满足国内大小影视公司的通用需求。当然此书非常优秀，是少有的关于影视和游戏生产流程的书籍，还有很多关于生产流程中的一些详细介绍，有些陆续在这里（<-点这个蓝色的字！）放出来，欢迎大家去凑热闹！

感谢谷歌翻译！为我省了很多时间。如果文章中有读不懂的个别句子...请自行跳过！！。懒得排版，反正没啥人看（截至目前一共17个粉丝啦！谢谢你们的支持！），就当记个笔记，留着以后作参考。

文章太长，我就拆成了几篇来发。这篇发第一二节，剩下的章节在下面的图文里，可以点开历史消息进行查看。

第六章

系统基础设施

 

Tim Green; Matt H·esterey; Hannes Ricklefs; Mark Streatfield; Steve The·d·re; Laurent M. Abecassis: Di-·-Matic; Ben Carter: Game Devel·per and Auth·r, Heavy Spectrum Entertainment Labs; The M·ti·n Picture Ass·ciati·n ·f America; Martin Weaver: Head ·f C·re Systems, MPC; Fran Zand·nella: Internati·nal Seni·r Pipeline TD, Rhythm & Hues

 

6.1此章你将了解

生产流程的健壮性和系统基础设施（IT）息息相关。在本章中，我们将探讨这些硬件和软件如何影响流程的开发和管理。我们将首先了解电影和游戏工作所需的各种基础设施，然后检查与任何流程相关的关键问题，包括管理操作系统和实用程序软件的需求，以及流程安全性的需求。

 

6.2 电影IT：硬件类型

电影制作对数据有着极大的依赖。高精度的模型，复杂的绑定，解算缓存和高分辨率渲染，单个电影可以生成许多TB的数据，而同时运行多个项目的设备所存储的数据很容易达到PB的级别（1PB=1024TB）。在这种极端环境中，健壮的基础设施至关重要。

硬件如何组装取决于公司的组织方式。公司可以组装一套单一设施，或者——因为现在出现的越来越普遍的现象就是，收购海外的公司或者在海外设立工作室—— 组装多套设施，通过私有网络来进行连接。

任何这些方案至少需要以下类型的硬件：

·工作站（台式机和笔记本电脑）

·网络（电缆，交换机和Wi-Fi连接）

·核心服务器（用于电子邮件，用户帐户，DNS，数据库等）

·存储集群（用于数据存储和备份）

·渲染农场（用于处理计算密集型任务）

·电话和通信硬件

·备用电源（通常不足以为整个设施供电，特别是渲染服务器场，但足以使核心服务保持活动状态或正常关闭电源）

在任何这些方案中，以下类型的硬件都是可选的，但接近通用：

·额外的监视器（给艺术家）

·图形平板电脑（给艺术家）

·耳机（给动画师用于做口型）

·剧照相机，摄像机和麦克风（用于录制参考资料：这些设备通常可以在几位艺术家之间共享）

具有多个设施的方案需要以下其他类型的基础架构：

·专用网络连接或专用路由设置（以确保站点之间有足够的带宽）

·每个设施之间的加速数据传输的某种形式

·视频会议设备（理想情况下，使用远程屏幕共享系统）

其中两个主要成本是存储集群和渲染农场，特别是涉及“capex”（基本建设费用）时。我们将更详细地研究每一个。

 

6.3电影IT：存储集群

 

存储群集是保存所有生产数据的文件服务器群集。为了确保有足够的数据可用，大多数工作室将其存储分解为多个层：

•第1层：可供生产使用的存储

•第2层近线存储：生产终端计算机无法访问，但可用作“停车场”的磁盘，可以从第1层存储中快速获取离线数据

•基于磁带的存储：用于生产数据的长期归档，最有可能是最终输出给客户

 

虽然经常被忽视，但设施的工作站和本地渲染机也是存储空间的来源。本地计算机上可用的总空间通常大于托管存储中可用的空间，这意味着在规划存储要求时应考虑本地缓存策略和代理生成。

第1层和第2层存储包括来自EMC Isilon或NetApp等供应商的NAS（网络连接存储）设备。在第1层存储中使用的那些更昂贵但更快，针对读取性能进行了优化;在第2层中使用的那些更便宜但更慢。

图6.1快速网络连接存储设备（如EMC Isilon的IQ 3000x）用于为艺术家提供对生产文件的直接和“近线”访问。
 

在规划托管存储时，重要的是要考虑许多问题：

·渲染农场如何与存储交互

·如何跟踪生成的数据量以及上次访问数据的时间

·如何向艺术家呈现存储：多个磁盘或单个数据

·哪些数据对生产至关重要

·需要归档哪些数据以及需要多长时间

·如何监控存储

最大的问题之一是渲染农场与存储交互的方式。在VFX生产中工作的每个人都会遇到一种情况，即单个渲染器会使整个设施瘫痪。在大多数情况下，这是由于某个贴图文件存储在一个磁盘上，而有数千台计算机试图通过网络访问。为了避免这种情况，渲染服务器场可以连接到SSD缓存系统，例如由Avere生成的系统，或者为文件I / O（输入/输出）优化的其他专用系统。但是，这样的系统价格很高，等效的2TB高性能系统售价数千美元，CTO就会抱怨了“这也太丫的贵了吧？我刚买了一个2TB的外置硬盘只要100美元！”

集群的采购通常是递增的，每年或每次主要生产都会增加额外的产能。在较大的设施中，这是由专门的数据操作部门处理，与IT、R&D(研发)和生产联系。在较小的设施中，它由IT处理。

设施的备份和归档功能也必须与存储群集一起增长。这里，存储器由LTO（Linear Tape-Open）半英寸磁带盒组成。磁带采用条形码编码，以将它们与特定项目相关联，然后存档在“库”中。这些通常是由HP和IBM等供应商生产的自动化系统，包括一个机器人，可在需要时自动将磁带加载到磁带机中。

备份过程由诸如CommVault等商业供应商或Bacula等开源替代品生成的软件控制。备份按照工作室可以管理的频率逐步增加：通常至少每天，但不少于每周。

一旦项目完成，存档通常是一次性操作——或者对于大型项目，镜头或者序列完成时进行一次 ——并且可以涉及将数据的副本发送给客户。通常会保留两份磁带，一份在现场，一份在场外。这两个过程都有很高的“opex”（“运营支出”或“运营费用”的缩写）。此时的“快照”，即只读的数据副本，也将用于辅助数据管理。

经常被忽视的另一个步骤是恢复过程：确保您彻底了解该过程，并在需要使用之前对其进行测试。由于数据恢复管理不善导致的停机是极其不应该的，因此未经测试的备份系统根本不是备份系统。

一旦到位，存储群集将需要持续监控，以确保有足够的可用磁盘空间可用于生产。常见的数据管理策略包括在一段时间后将文件从快速存储移动到慢速存储，或者仅在线保留一定数量的先前版本的资产。一些工作室甚至设置了自动数据剔除程序，要么删除在给定时间段内未访问过的文件，要么根据文件路径（例如，Playblasts数据，或临时渲染数据（可以很容易从其他文件再次生产出来），无需长时间在线存储）。在资产管理系统的范围之外，艺术家和制作人员有责任管理他们自己的本地数据足迹，删除他们不需要的硬盘驱动器文件。

需要考虑的另一个问题是3D数据往往具有相当短的半衰期。主要商业工具的开发人员每12到18个月发布一次他们软件的新版本，专业工具和插件来去匆匆。绝对不能确定使用最新版本的软件可以可靠地打开四年或五年的文件。

这对于需要维持正在进行的IP的核心资产的工作室来说是一个严重的问题，例如可能产生续集的电影。即使不再需要旧资产进行制作，它们也是制作最新电影的艺术家的重要参考资料。

一些工作室以稳定的文件格式（例如OBJ或FBX）存档关键资产，这些资产与特定版本的第三方软件的关系较少。还有些工作室是将计算机保存起来，包括它的系统、软件和生产内容。当然，这是解决高科技问题的一种令人尴尬的低技术解决方案，但实用主义是参与生产流程的任何人的关键优势。虚拟机映像是实现相同结果的另一种方法，无需保留可能不可靠的硬件。

流程团队应记录存储设施的历史指标。在规划下一次生产需要多少存储空间时，了解每个用户，部门，镜头或项目生成了多少数据是有用的信息。强制性地，专用进程将每天搜索文件系统，查询每个文件以获取上次访问它的信息，其所有者，其大小和位置等信息。这可以与来自资产管理系统的数据（例如，拍摄文件所属的数据）相结合，并通过公司网页上的“仪表板”界面提供，高级员工可以通过该界面执行自定义分析。许多第三方软件供应商专门从事此类任务：例如，Zenoss提供用于监控存储使用情况的系统。

这样做有几个很好的缘由：

数据有成本

计算每千兆字节的存储数据的成本——包括购买，供电和维护服务器的成本，以及支付数据管理员来管理流程，使工厂能够更准确地预算未来的工作。
数据占据空间

计算每个镜头，每个资产或每个艺术家所需的平均存储量使设施能够预测未来项目所需的存储量。

数据模式使用随时间的变化

随着工作流程的发展，“重要”项目生成的数据量也会发生变化。有时，因果关系可能并不明显：例如，新工具可能会导致磁盘使用意外突然出现。将这些变化追溯到其来源使流程工作人员，能够最大限度地减少问题并更准确地预测未来的数据使用。

请记住：在视觉效果工作中，没有“存储空间太大”这样的东西。这个行业，一个流体模拟就可能达到TB级别。

图6.2在生产中，数据快速增加。这个由MPC开发的在线计算器使用户能够根据文件格式，帧速率和分辨率等参数计算出电影的单次迭代将占用多少存储空间。

 

 

管理文件的I/O（输入输出）

Fran Zandonella

International Senior Pipeline TD, Rhythm & Hues

“文件管理I / O”（文件系统输入/输出）的问题可能难以诊断，而繁重的I / O可能会导致设备停止运行。管理这种风险至关重要，因为繁重的I / O期通常发生在最糟糕的时候，例如在交付截止日期之前的“紧缩”期间。以下策略可能对此有所帮助：

确定具有大量I / O要求的部门并将其隔离

例如，FX部门的解算将对网络造成极大负担，这时可以通过使用自己的专用快速磁盘来改善。或者，其他部门（例如动画）可能有不得中断的工作，这时可以用受保护的工作场所。

识别和管理磁盘使用的高峰时间

大量艺术家同时开始或结束他们的工作日会对文件管理器I / O产生巨大影响，而计划的备份和恢复时间会对存储系统造成隐藏负担。在我工作的一个工作室，工作到很晚的艺术家常常抱怨在Unix文件系统上打开和保存文件需要多长时间。在不经意的与其中一位Mac人员进行的对话中发现，Macs在晚上7点备份，因为大部分制作人员已经离开了。推迟备份时间，在所有工作人员都离开之后再进行备份将大大提高生产力。

将不同类型的数据分配给适当的存储类型

从需要它的数据（模型，贴图，绑定）中分离出不需要高I / O访问（脚本，配置信息，Maya场景文件等）的数据，并将每种类型分配给适当类型的存储。

制定处理常用文件的策略

观察每个渲染时会多次访问的文件类型（贴图，解算数据，日志等），并关注最小程度上减小对他们I / O访问速度的影响的方法。以下可能有必要：

•将文件分发给具有大内存缓存的服务器。

•将数据本地分发到所有渲染节点，然后在需要时重新组合信息。注意本地渲染节点的磁盘速度，因为如果数据大于缓存，这可能是瓶颈。

•使用缓存设备，特别是如果可以在程序上识别它们。这对于可以分段的数据（例如，共享贴图）非常有效，特别是当它被多个镜头使用时。但是对单帧数据不是那么好用。

•将具有本地SSD存储的专用文件管理器用于特定类型的文件，并在系统之间进行循环。

遵循创建脚本时的最佳实践

创建脚本时，请记住以下几点：

•当需要检查目录和文件是否存在以及读/写权限时，通过NFS（网络文件系统协议）打开文件可能比较占用时间。记住要管理文件中的内容并将（单个目录中）文件数量保持在最低限度。

•压缩文件或将文件转换为其他格式时，在通过网络发送文件之前处理本地计算机上的文件可以节省文件管理器I / O和网络时间。

•在将帧和其他可以快速运行的任务在运送到服务器进行批量运行之前，将其先分成更大的块是很好的做法。这对于最小化共享任务（如启动应用程序或加载配置文件）所花费的时间特别有用。

使用监视和调试工具

最后，在出现紧急情况之前，先了解您的监控和调试工具。养成阅读系统日志和使用strace（Linux的实用程序监控系统调用进程）的习惯，以便在问题变得严重之前识别问题。如果最糟糕的情况发生，并且模拟或渲染使文件管理器瘫痪，请保留一个可用于测试未来新部署的样本。

 

 

图6.3视觉效果设施的存储集群和渲染服务器场，是用于对艺术家桌面工作站要求过高的任务的专用机器集。

 

6.4：电影IT：渲染农场

“渲染农场”或“渲染墙”用于需要大量计算资源的任务。在完成这些工作站时，不是将艺术家的工作站捆绑在一起，而是更有效地单独处理它们。尽管它的名称，渲染农场不仅处理渲染作业：它是一个高性能计算集群，所有离线处理都发送到该集群，包括解算模拟（用于FX），缓存（用于动画），代理（用于合成），以及与服务相关的任务，例如创建QuickTimes以交付给客户。因此，通常最好根据部门或任务类型等标准划分服务器场。这允许服务器场调度程序公平地为所有用户分配资源，并在最符合其要求的计算机上执行每个作业。

 构成渲染农场的机器通常是“无头”的——也就是说，缺少监视器和输入设备—— 并且根据以往经验，都是基于CPU的。然而，如果如今很难再买到不带图形卡的电脑了，近年来GPU上可以处理的任务数量增加，这意味着许多现代农场也包含了大量的带GPU机器。对于专门的任务——例如，可能需要一个服务器，其唯一的任务是处理动作捕获数据——这就需要专用机器，并且需要特定的配置。如果艺术家的工作站没有被使用的话，IT部门也可能将它们作为渲染农场中的“奴隶”，使用原本闲置的处理能力。

与存储集群一样，渲染服务器场的采购通常是递增的，每年或每个主要生产都会增加额外的容量。在较大的设施中，这是由专门的渲染操作部门处理，与IT，研发和生产联系。在较小的设施中，它由IT处理。

在中型和大型工作室中，服务器场可能会运行数百或数千个CPU。这意味着电源和冷却也是主要考虑因素。为了说明原因，让我们看一下运行80个服务器场所需的内容：按现代标准来看规模适中。假设两台服务器可以装入1U（一个“机架单元”：一个标准的测量单位，相当于标准服务器机架中的1.75英寸高度），每台服务器包含两个8核Intel Xeon CPU和RAM ，本地系统驱动器等。这意味着80个服务器将完全适合40 U机架（标准机架为42 U至44 U），并将包含1,280个CPU核心（80个服务器×每个服务器2个CPU×每个CPU 8个核心）。

 服务器已经相当沉重，但增加了电源管理，以太网电缆，机架导轨，螺母和螺栓，每个900 mm×600 mm机架可能重600 kg，可能更多：可能高于办公室推荐的重量限制。

两个Xeon处理器，RAM，硬盘驱动器和服务器的其他组件的总功耗可轻松为250 W至500 W，因此整个40 U机架将消耗20 kW的功率。在空调和空气处理方面增加50％，总功率消耗为30 kW。

这通常意味着限制渲染农场性能的主要因素不是通常假设的处理器功率，而是提供电力和冷却以保持农场运行的需要。为了保持运行性能，必须将农场保持在较窄的温​​度和湿度范围内。出于这个原因，数据中心的设计本身正在成为一种艺术形式，涉及建筑，设计，结构，机械和电气工程的各个方面。

渲染服务器场通常由单个软件管理——“调度程序”或“渲染管理器”——负责分发任务。生产中常用的包括Deadline，Tractor和一些开源的类似Arsenal等工具。

调度程序管理的任务可以像渲染单个高分辨率图像一样简单，也可以像在不同软件包中执行的一系列操作一样复杂。调度程序收集每个艺术家提交的任务，并根据算法将它们分配给特定服务器。该调度算法可以使用几种不同的方法，从简单的“先到先得”任务分配，到基于优先级或权重的调度，再到基于先前渲染时间，当前文件管理器或网络性能的纯度量驱动方法，以及生产计划。为此，它还必须跟踪哪些服务器当前空闲，哪些服务器正忙或离线。然后，调度程序将任务的进度报告给艺术家，如果任务遇到问题，则向他们发送错误消息。

 

 

 

在渲染农场上执行工作流程

Hannes Ricklefs

Global Head of Pipeline, MPC

在MPC，我们编写了一个Python模块，其中包含表示可以在渲染农场上执行的不同类型任务的类。 其中包括执行其他Python命令等常规任务，以及Maya或Nuke等特定应用程序。 该模块使我们能够在各个任务之间建立依赖关系，从而创建复杂的任务图。

在渲染服务器场管理软件时，任务定义和图形描述是不可知的。 为了使图表能够在特定的应用程序中执行，我们编写了将它们转换为软件原生格式的翻译器：我们支持Pixar的Alfred和Tractor。 这使技术艺术家能够快速编写自定义工作流脚本并在我们的渲染农场中执行它们。

渲染农场由渲染操作部门管理，以确保其有效运行。 这通常意味着监控农场工作的进度和分类错误：鼓励艺术家自己解决普通问题，有更大的问题的话再寻求技术支持的帮助。 技术人员（绰号render wranglers （渲染争夺者））也将管理工作的优先级，以确保关键任务按时完成。 接近截止日期的镜头或项目将优先于其他镜头或项目，但每个艺术家和部门都有其公平的资源份额也很重要。 与存储集群的数据争夺一样，渲染争夺被视为入门级职位，也是通往更高级技术角色的途径。

与存储群集一样，保留渲染农场的历史度量标准非常重要，原因如下：

渲染有成本

计算每小时一美元的处理数量，包括购买，供电，冷却和维护服务器的成本，以及支付渲染调换器来管理流程，使设施能够更准确地预算未来的工作。

 

渲染农场是一个有限的资源

计算每个镜头，每个资产或每个艺术家的平均渲染时间使设施能够预测未来项目所需的农场容量。

处理使用的模式随时间的变化

随着工作流程的发展，“典型”项目使用渲染农场的方式也会发生变化。 将这些变化追溯到其来源使流程工作人员能够最大限度地减少问题并更准确地预测未来的数据使用。

 

 

 

6.5 电影IT：管理基础设施

管理设施的基础架构有两个主要方面：配置基础架构和监视该基础架构的状态。

配置基础架构时，能够快速，轻松地部署新的计算资源非常重要。 这意味着最好为艺术家的工作站定义标准设置，并坚持下去。 有多种工具可以帮助系统管理员自动化构建和配置新机器的过程：最着名的配置管理（CM）工具包括CFEngine，Chef和Puppet。 拥有现成的磁盘映像也很重要，可以通过单次安装创建完全指定的工作站。 最后，随时都要备有备件和驱动程序：在大型工作室中，硬件故障会频繁出现，您需要防止艺术家面临的各种困境，例如硬盘驱动器损坏，电源供应不足或GPU死掉。

需要可重复的系统设置

Fran Zandonella

国际高级流程TD，Rhythm＆Hues

无论一个设施有五台机器还是五千台机器，拥有可靠的基线系统映像来构建新系统，可以更容易地在项目开始时推出机器，或者更换有缺陷的机器。可能需要几个单独的磁盘映像——例如，桌面计算机和渲染服务器，或不同部门的单独设置——但为简单起见，尽量将数量保持在最低限度。

可能还需要在整个设施中的不同机器上安装多个版本的相同软件。例如，Side Effects软件有时会在一天内发布两个新版本的Houdini，并且通常每周发布几个版本。也许一个部门需要特定的错误修复，但其他部门则不需要。能够对应用程序进行版本化有助于管理这些需求，考虑本地化不经常更改的应用程序，并在本地副本出现问题时提供网络版本的回退。

在部署之前，需要根据每个部门的需求以及当前和计划的渲染机器的样本来测试基线映像。自动化测试可降低成本并确保部署之间的一致性。

重要的是要有一个检查单个机器是否符合基线的过程，特别是在设施有员工在不同办公室工作的情况下。如果世界各地的艺术家收到不正确的更新，他们的工作可能落后于计划一天。

在为设施构建基础架构时，需要考虑的一个重要事项是在每台计算机上安装软件的方式。最常用的两种方法是将软件部署到每台计算机的本地磁盘，或者运行安装了每个应用程序的共享软件服务器。

共享软件服务器意味着只需要在各台计算机上安装基本操作系统组件：其他软件将通过服务器提供。这也意味着一旦安装了新的软件，它就会立即供每台机器使用。

然而，这样的系统需要适当的基础设施：同时为用户的软件请求提供相当大的机器，以及稳固的网络基础设施——特别是在网络负载较重的关键时期。它还会产生单点故障：如果软件服务器出现故障，整个系统将失败。解决这个问题的方法是在系统中构建“冗余”（多个服务器能够满足相同的需求，因此如果一个失败，另一个可以接管）。

在每台机器上安装所有软件可以消除对网络基础架构的这些需求。但是，安装和配置软件可能非常耗时。有时在高强度生产中，需要安装快速修复程序以在一夜之间完成渲染。如果渲染服务器场包含数千台计算机，则可能无法以足够快的速度完成安装以按时完成作业。

一些工作室使用混合方法，其中不快速变化的软件被部署到每个单独的机器，而经常变化的软件通过共享网络服务器可用。

管理设施基础设施的第二个主要方面是监控该基础设施的状态。这包括：

•网络带宽利用率

•网络流量

•各台计算机上的CPU负载

•单台机器上的内存使用情况

•特定于应用程序的统计信息，例如内存占用量，使用的CPU资源或数据库性能如何随所服务的查询数量而变化

一旦达到某个临界阈值，监控解决方案应该能够发出警报：例如，如果磁盘容量达到75％，或者数据库服务器上的负载超过某个阈值。 警报会在潜在问题影响任何用户之前通知系统管理员。 监控解决方案也应该远程工作：系统运行缓慢并不总是很清楚，因此能够在不必登录每台机器的情况下检查机器至关重要。

 

在某些时候，在流程或系统管理中工作的每个人都会收到来自用户的电话，说他们的机器“运行缓慢”。由于有很多可能的原因导致这种情况发生，因此要找到问题的根源，需要勤奋和耐心的调查。

 

“慢”的多面性

可能的地方原因包括：

•由于运行多次模拟，机器因负载过重而变慢。

•机器正在交换内存，因为渲染等单个进程占用了所有可用内存。

或者原因可能在于用户的机器：

•机器已过夜添加到渲染农场中，渲染尚未完成。

•用户正在处理存储在负载较重且无法快速检索的服务器上的文件。

•用户的应用程序要求从数据库中获取一条信息，但是其中表被锁定了，函数调用阻止了它。

要问的第一个问题之一是缓慢是否仅影响用户或周围的其他人。在第一种情况下，原因很可能是用户的机器。然后，重要的是要确定缓慢是仅影响单个应用程序还是每个应用程序。在第二种情况下，原因很可能是中心因素。在这种情况下，重要的是快速了解整个设施系统的状态。有多种工具可供选择，包括Cacti，Nagios，OpenNMS和Zabbix。

 

6.6  游戏IT：构建农场

游戏的数据需求很少像电影那样庞大，因此它们通常需要不那么令人印象深刻的基础设施。游戏工作室通常会拥有您在任何其他办公环境中所期望的资源：电子邮件，非关键数据的共享驱动器，Wiki或其他集中文档等等。

但是，找到某种集中式“构建框架”或“服务器场”的情况并不少见，这种集中式“构建框架”或“服务器场”用于执行开发人员个人计算机上执行速度太慢的所有任务。此类任务取决于游戏引擎，但通常包括渲染光照贴图或生成光探测器。该服务器场还经常用于单元测试（测试游戏引擎源代码的各个单元），连续构建（将这些单独的单元合并到代码的单个“主线”），以及烟雾和浸泡测试（测试关键特性是否有效）当构建首次运行时，它在持续负载下不会失败）。没有两个游戏团队或设施将执行完全相同的构建农场任务。

构建服务器场可以由高端机器（有或没有GPU，取决于它们所期望的任务）或旧工作站组成，这些工作站现在太慢而无法提供给开发人员，但可用于增加农场的节点数。

管理服务器场的软件与其包含的硬件一样独特。有许多商业解决方案可供使用——本章前面列出了一些——但是工作室开发自己的管理软件并不罕见。即使是简单的耕作任务的方法也可以在短时间内实现，特别是如果服务器场中的每台机器都配置为特定任务。

 

小任务的快速叠加

Tim Green

Senior Programmer, Supermassive Games

在管理游戏项目时，不要只关注大型任务。当它们一遍又一遍地重复时，小任务很快就会加起来。

游戏“哈利波特”和“火焰杯”是使用RenderWare Studio开发的：一种同步创作（level-authoring）工具，使用户能够放置对象并创作以事件为中心的游戏逻辑。在RenderWare中，一个同步包含数万个对象，每个对象都有一组属性和指向其他对象的链接。每个对象都保存为XML文件，每个同步产生数万个非常小的XML文件。

当我在刚碰到这个问题时，团队都在抱怨，加载速度很慢，通常需要长达10分钟。我是团队的新手，所以我同步了XML级文件，但发现我的机器上的所有内容都要加载30秒。

在消除了其他原因后，我得出结论，这纯粹是由于磁盘访问时间。我注意到在慢速机器上，硬盘驱动器严重碎片化，所以我们对这些驱动器进行碎片整理并重新测试它们，期望立即提速——但结果是一样的。发生了什么事？

在这一点上，我需要解释一下NTFS，PC上使用的文件系统。 NTFS将有关每个文件的元数据存储在称为主文件表（MFT）的结构中。元数据包含一些信息类似于文件名称及其创建日期，甚至可以将部分数据存储在文件中。该数据具有1kb的固定块大小。这意味着文件的数据通常位于硬盘驱动器上的某个位置，可能会分割成片段，其元数据位于MFT中，但如果文件大小不足1 kb，则它可能完全就存在于MFT中。

碎片整理会在机器的硬盘驱动器上移动文件碎片，将它们连接成连续的块以减少加载文件时的搜索时间，但它不会在MFT中移动任何内容。我们成千上万的XML文件中的大多数都在1kb以下，所以它们只存在于MFT中并且没有受到影响。加载级别时，RenderWare Studio将按顺序加载这些XML文件，要求文件系统在整个MFT中进行搜索才能执行此操作。

如果只将文件一次写入文件系统，则它们的元数据将按顺序写入MFT，这意味着需要更少的块搜索和加载。

解决方案是重命名包含文件的文件夹，将其复制回原始名称并删除旧文件夹。这意味着元数据文件现在在MFT中靠得很近，增加了缓存的MFT块包含所需数据的可能性。

一个简单的工具，超过一百人有更好的同步加载时间，每人每天节省约30分钟，或总共每天约50小时。

 

6.7  IT游戏：版本控制

虽然游戏项目可能不需要像视效项目那样多的存储，但IT基础架构的其他方面对其成功至关重要。游戏开发者必须应对游戏设计和游戏引擎的不断变化，有时甚至是不可预测的变化。出于这个原因，他们需要能够非常精确地跟踪项目过程中游戏内容的演变：例如，他们可能需要将资产回滚到早期版本以分析特别微妙的错误，或者维护不同游戏控制台的并行版本。因此，它们尤其依赖于版本控制软件。我们在前一章中研究了版本控制软件的工作原理。在这里，我们将更详细地探索特定于游戏的方面——特别是那些影响工作室基础设施的方面。

随着文件的更改，这些更改的数据和元数据将存储在文件历史记录中，但该文件的旧版本仍然可用。为这些数据维护一套安全且“冗余”的备份是迄今为止IT部门最重要的工作。如果更改导致错误，则用户能够恢复到之前的、没有错误的版本至关重要。

版本控制系统中包含的历史信息对于诊断和修复微妙的问题也至关重要。由于许多人都在处理每项资产，因此很容易因通信失误或简单的人为错误而导致问题，而这些问题可能难以解决。

版本控制软件的另一个重要优点是它能够创建项目的修改版本，同时保留原始代码和数据的完整性。 “分支”使系统能够维护相同文件的多个并发版本（包括其历史记录和元数据）。分支对于使团队的不同部分能够安全地并行工作非常有用。例如，一小部分动画师和设计师可能想要为游戏玩家角色制作一种新的动作动画原型。这将是一个缓慢的，迭代的过程，产生大量的临时错误。如果团队被分配了自己的分支，它可以在不影响工作室其他部分的情况下工作。一旦新功能可靠地运行，分支就可以重新集成到代码的主线中，以便整个团队可以共享它。

由于版本控制对游戏团队至关重要，因此选择正确的版本控制解决方案是创建游戏流程的最重要步骤之一。市场上有几种版本控制系统，包括商业版和开源版，但并非所有版本控制系统都同样适用于游戏。对于程序员来说，版本控制的当前趋势是针对分布式系统，例如Git，Subversion或Mercurial。不幸的是，这些系统针对基于文本的代码文件进行了优化，并且它们倾向于扼杀组成现代游戏的大量图形文件。配置分布式系统以使用图形文件逐渐成为可能，但这仍然是专家级任务，应谨慎对待。出于这个原因，像Perforce和Alienbrain这样的集中式版本控制系统在游戏制作中仍然比较常见。

选择系统时的一个重要考虑因素是工具链的规模和复杂性。如果您在自动化方面投入了大量资金，那么您将需要一个为脚本工具和工具程序员提供良好API访问的系统，例如Perforce或Mercurial。另一方面，如果您坚持使用现成的软件，您可以选择像Alienbrain这样的系统，为Maya和Photoshop等艺术工具提供更加精美的用户界面和现成的插件。

选择版本控制系统的另一个关键因素是分发。如果您的项目涉及多个地点之间的协作，或与场外承包商和外包商合作，您将需要决定是否允许这些团队访问您的版本控制系统。有些团队绝对拒绝以安全名义对其数据进行异地访问;其他人坚持这样做，以便他们可以使用版本控制功能来跟踪合作伙伴的活动。如果您计划允许外部访问数据存储，则需要通过基于Web的客户端或通过VPN（虚拟专用网络）连接找到允许远程访问的系统。特别是，Perforce使您能够创建代理服务器，该服务器充当来自项目主版本的数据的本地缓存。如果您希望为海外的用户提供对常用文件的更快访问权限，则这些功能非常有用。

确保您有一个明确的策略来控制对数据的访问也很重要。大多数版本控制系统都包含某种形式的身份验证，以确保只有授权人员才能查看数据。管理员还可以创建用户配置文件，以确定版本控件的哪些部分对哪些用户可见：例如，允许程序员访问已完成的游戏资产但不是原始Maya或Photoshop文件，或艺术家访问最新版本的游戏引擎但不是所有的源代码。如果您计划让外包商直接访问您的版本控制系统，则访问控制绝对至关重要。

最后，您需要确保您的版本控制系统具有足够的硬件支持。这应该包括足够的磁盘空间（这些大二进制文件的历史记录迭代的非常快），至少是一个称职的处理器。定期备份和冗余架构（如RAID驱动器）至关重要：如果您的版本控制系统出现故障，您的项目就会陷入困境。如今，一些团队为其版本控制服务器选择基于云的托管，以利用大数据中心提供的高运行时间和全天候维护——尽管许多其他团队战战兢兢地担忧自己的宝贵的项目数据被传送出去。网络本身也必须非常强大，以应对“早晨同步”：获取最新版本的游戏文件的日常仪式，这是艺术家或开发者每日第一杯咖啡的一部分——实际上，通常是在同一时间发生的。

 

6.8  管理操作系统

在电影和游戏中，通常在整个设施中使用多个操作系统（OS）以适应不同的任务或软件包。最常见的操作系统是Windows，Mac OS X和Linux。尽管许多VFX设施将自己定义为“Linux机构”，但它们通常必须在某种程度上支持所有三种操作系统，因为总有一些应用程序（例如Photoshop和After Effects）无法在主操作系统上运行。

分割单个机器以便在其上运行许多OS实例变得越来越普遍：称为“虚拟化”的过程。每个实例或“虚拟机”都获得主机物理资源的一部分，但与其他实例完全隔离，因此对于大多数用途，它们可以被视为单独的机器。 （例如，重新启动虚拟服务器不会影响在同一硬件上运行的任何其他服务器。）虚拟化允许您最大限度地利用资源，通过“热备份”启用“透明故障转移”（即，在用户使用时备份数据）访问它），并水平缩放。此方法适用于资源较少的任务，例如运行Web或FTP服务器或许可证管理。更密集的任务（例如运行文件服务器）可能仍需要专用硬件和物理连接。

为了简化管理操作系统的过程，除非严格必要，否则通常会使每台计算机都相同，并根据其“主要应用程序”选择一个操作系统：例如，如果一台机器主要用于运行Nuke，它会适合安装Linux;对于Photoshop，有必要安装Mac OS X或Windows。或者，可能需要选择与机器GPU兼容的操作系统，或与图形平板电脑等关键外围设备兼容的操作系统。

当您确定每台机器的操作系统之后，除非必要，请不要再随意进行更改（通常是升级到新版本）！

 

6.9  管理实用程序软件

许多实用工具对于保持设施运行至关重要。 许多程序都使用系统软件（例如Java Runtime Environment和Microsoft的.NET Framework和Visual C ++可再发行程序包），因此保持最新状态并供所有用户使用非常重要，尤其是在您部署的情况下 依赖于这些库的生成工具。

图形和音频驱动程序是潜在问题的另一个来源，特别是对于3D艺术家。 确保您的用户拥有这些关键基础架构的最新批准版本非常重要。 如果您有一个大型工作室，那么投资远程审核软件配置的工具是明智的——每晚通宵检查每个图形工作站的控制面板可不好受！

 

6.10 生产安全

最后，我们将研究生产安全性。这是IT基础架构的一个方面，很容易被低估。生产合同需要严格的机密性，因此IT必须有适当的设置，以确保不会发生安全漏洞。这包括身份验证（是访问他或她声称的数据的人？）和授权（该用户实际上是否有权访问这些文件？）

一般而言，除非在供应商和客户之间签订合同，否则任何生产都是保密的，并且在任何限制日期结束之前，该过程的细节仍然是禁止的。鉴于资金在紧张的消耗之中，这并不奇怪：大型项目的成本和潜在收入达到数亿甚至数十亿美元，因此有必要确保在发布之前尽可能保证内容的安全。

在视觉效果工作中尤其如此。 VFX行业受到非常强大的安全审核，可以测试生产的各个方面：员工和访客如何访问工作区，员工如何登录机器，是否可以安装外部存储设备或刻录CD和DVD，网络如何分区，以及将数据上传到互联网是多么容易。但是，到目前为止，VFX行业最大的担忧是云中的安全性：主要的电影工作室合同要求供应商确保数据在内部托管，而无需从外部访问数据。在搭建流程时必须考虑这些因素，因为以后绑定安全措施可能会非常昂贵。这些审计每年发生几次，这一点并不少见，无论是由客户还是MPAA（美国电影协会）发起的。

三十多年来，MPAA代表其成员公司，美国六大电影制片厂进行了网站安全调查：沃尔特迪斯尼影城电影公司，派拉蒙影业公司，索尼影视娱乐公司，二十世纪福克斯电影公司公司，Universal City Studios LLC和华纳兄弟娱乐公司

这些MPAA调查涉及广泛的主题，包括事件响应等管理系统;物理安全性，例如如何保护设施的访问点，以及物理存储介质和文件传输的安全性;和数字安全，包括身份验证和授权协议，以及文件管理系统的各个方面。

此类调查确定了应该实施的生产和控制风险，以将这些风险降低到适当的水平。国际标准化组织（ISO）将风险定义为“事件概率及其后果的组合”。在这种情况下，前者将包括从设施网络中窃取内容的概率;如果发生这种情况，后者将包括对设施和客户的业务后果（例如，违反合同和/或该发布窗口的收入损失）。

在与客户协商后，设施负责确定该客户的哪些资产需要更高级别的安全性。这是通过四个步骤完成的：

•识别和分类资产

•监督和评估有效性

•确定最低安全控制集

•实施控制

通常根据资产的分类，对组织的价值以及泄露或被盗的风险来选择安全控制。为了减轻已识别的风险，设施应实施与每种特定风险相称的控制措施。应根据当前的威胁环境定期评估此类措施的有效性。

图6.4 MPAA的内容安全模型（见其内容安全最佳实践指南Content Security Best Practices）包含49个安全主题，分为三类：管理系统、物理安全和数字安全。

 

6A

补充：通过定期维护和灾难计划（DISASTER PLANNING）减轻风险

Fran Zandonella

International Senior Pipeline TD, Rhythm & Hues

工作室通常期望他们的项目能够在项目交付之前顺利运行而不会中断。可悲的是，现实世界有干扰的习惯：新的硬件，软件更新，硬件故障，服务器崩溃或飓风和地震等自然灾害很少被生产计划考虑在内，但如果计划是没有到位来解决意外。规划和定期维护是控制和最小化对计划的影响的关键。

第6节补充1：计划停机时间

设施需要停机维修，但项目无论如何都要全天候运行。无论生产压力如何，都需要尽可能保护停机维护窗口。计划停机的三种类型是：

•定期维护窗口通常用于持续4-12小时的大型任务，并在非工作时间执行。

•增量维护窗口适用于可轻松分解为持续10分钟至1小时的子任务的任务，通常在一周内执行，最好在非高峰时段执行。

•轻量维护窗口用于快速重启服务器，持续时间不超过10分钟，并在工作日期间随时执行。

计划的停机时间类型取决于设施的需求和要完成的工作。如果工厂在多个时区设有办事处，这将需要办事处之间的良好沟通，以确保停机不会对他们产生负面影响。不安排计划停机时间会产生后果：无论如何都会发生故障，导致无法预测的停机时间和频率和持续时间的增加，并且会在最糟糕的时间发生。

第6节补充2：一般指南

规划有助于在分配的时间内完成平稳的停机时间。这些是适用于所有类型停机的一般指南：

•如果出现以前未公开的生产问题，请尽早将生产部门纳入停机计划。所有工作请尽可能在与生产部门达成一致的时间内完成。

•创建包括以下内容的沟通计划：

-需要联系有关停机时间的人员列表。该列表可以集成到停机通知系统中。

-如果系统关闭包含列表，则列表的硬拷贝很方便。将此列表保留在电话（办公室或移动电话）旁边是明智之举。

-需要了解影响它们的中断的其他办公室和供应商的列表。如果有人将文件发送到停机维护并希望它可用的系统，该怎么办？谁是您的ISP或服务器供应商的联系人？

-如果通常的方式通知人员因维护或紧急情况而停机，则可以通知人们停机时间。

•选择小而有凝聚力的维护区域，以便在出现问题时将测试和故障排除时间降至最低。

•创建一个清单，列出计划完成的任务，并确定哪些任务是关键的，哪些任务很好。

•创建测试计划或自动测试套件，以验证系统的状态是否可供生产部门使用。

•计划在发生意外情况时如何回滚。计划多个生产中的意外事故用于突发状况。

•对于在停机期间完成的工作多加演练，以发现假设并减少意外。

•一个好的策略是在侧面进行工作，然后在停机期间将其交换进去。

•工作完成后，向相关方发送通知。本说明应包含中断的详细信息：更改的内容，中断的持续时间，中断的原因（如果不是很明显），将来要查找的问题以及出现问题时联系的人员。

•对停机时间的成功和失败保持统计数据和“经验教训”将有助于规划未来的停机时间。应跟踪此信息，因为这对于计划每年的停机时间，预算和改进停机流程非常重要。

抓住”集中”、”测试时间”和”回滚”进行停机维护，将持续有效地推动生产继续进行。

 

第6节补充3：定期维护窗口

安排定期的时间段来执行维护是一种很好的做法。某些维护任务需要更大的窗口（四个小时或更长时间）才能完成工作，特别是如果它很复杂或影响很多系统或需要与多个供应商或系统进行大量协调。此外，如果大多数人在办公室，可以安排多个所需的任务，并执行可能影响设施的工作。在一些工作室，这项工作是在星期日进行的，当时大多数制作和工作人员都暂停了。完成的工作类型的示例可能是安装新的家庭服务器，网络维护，升级数据库或其他关键软件。与生产部门一起安排定期时间会考虑他们的需求，使调度更容易，并减少意外停机时间。

第6节补充4：增量停机时间

当难以获得更大的时间时，请在设施最能负担的时间内计划少量的定期停机时间。增量可以持续10分钟到1.5小时。除上述指南外，以下提示还可以简化：

•选择一个固定的时间在一天中的某个时间进行维护，这将影响最少的人数。确保此时间不会对其他办公室或任何期望交付的人产生不利影响。

•选择单个维护区域，以便在出现问题时最大限度地减少测试和故障排除时间。维护时间可能短至10分钟。

•准备好执行回滚计划，以防发生意外情况。将计划停机时间的一半到三分之一计划在意外之中。

•对在停机期间完成的工作多加演练，以便快速完成工作。

•当停机时间很短时，在停电期间进行工作然后在停电期间进行交换会增加成功的可能性。

短暂、集中、增量的停机时间以及测试和回滚时间有助于推动生产持续平稳进行。

 

第6节补充5: 倾翻（roll-over）

倾翻（roll-over）停机时间是闪电停机时间，不到十分钟，专注于一项维护任务。这种类型的停机时间通常在清晨，午餐或其他人不急于发布或导出其工作的时间进行。常见任务包括“滚动”数据库（上载新模式，发布非常小的补丁），添加更多磁盘空间，重新分配硬件或更换冗余或备份硬件，或分发紧急补丁。关键是通过使维护窗口非常短，维护类型极低（通过边线，测试和练习）以及易于撤消的工作来尽可能少地破坏设施。理想情况下，艺术家不会忽视停机时间。在白天进行此类维护的好处是，IT人员随时可以监控系统状态，并在发现问题时快速进行调整。即使滚动时间短而小，仍应发送有关方面的通知，并应对事件进行简要审查并记录下来，以便以后分析。

计划外/紧急停机时间

将发生意外或紧急停机。即使人们不知道何时会发生紧急情况，仍应进行规划。管理此风险的关键技术是：

•制定沟通策略

•制定计划，以便在紧急情况下采取措施

•了解谁可以提供帮助。哪些供应商可用？你需要打电话给谁？

•制定定义的升级政策。何时以及如何将其踢到楼上？

•练习，练习，练习！这就像消防演习一样，目的是了解计划的工作原理以及在紧急情况发生之前需要改进的地方。

•制定备用路线/流程，以便设施尽可能继续运行。例如：

-驻留在另一个城市的备份，以防办公空间受损（例如自然灾害等）

-备用工作人员，以防有人生病或退出或休假/无法访问

-备用网络路由

-备用磁盘驱动器

-备用计算机（可能在上次升级时遗留）

•从紧急情况中恢复后，请确保执行以下操作：

•告知相关各方

 - 紧急情况结束了，所以人们知道他们可以重新开始工作

 - 如果你知道的话，紧急情况是什么以及是什么造成的

 - 他们可能会遇到什么挥之不去的问题

 - 他们应该如何以及向谁报告问题

•举行回顾和事后调查分析以——

 - 如果可能的话，将来可以避免这种类型的问题（通过定期维护，改进硬件或进行物理改进，如用于地震安全的捆绑设备）

 - 下次可以改进响应时间和程序

 - 可以在下一个预算周期中衡量和计算成本

•在可搜索的位置（维基，Alfresco，数据库等）保存有关“经验教训”的信息，并在下一年的计划周期中对其进行审核

总之，无论是维护还是紧急情况，计划都可以在成本，进度和压力方面保持流程的可控性。