数据中心灾难恢复指南(更新)
数据中心灾难恢复指南
（更新版）
数据中心灾难恢复指南（更新版）
当前，基于Web的应用不断普及深入，新一代的企业级数据中心建设已成为行业信息化的新热点。虚拟化、云计算等新技术和概念的提出更是为数据中心的发展开辟了新的道路。但是，无论数据中心怎样变化，企业对于数据中心容灾备份的需求是只会提高不会降低的。此外，在预算日益紧缺的情况下，灾难恢复成本也是企业考虑的重要因素之一。企业灾难因素应该考虑哪些因素？如何将虚拟化应用到灾难恢复中来？如何减少数据中心灾难恢复成本？本指南将对这些问题进行解答。
灾难恢复考虑因素
灾难恢复策略和基础架构本身就很复杂，对于大型企业来说更是这样。在这个过程中存在许多可变因素：需要确定许多标准和流程，需要对人力资源进行组织，需要对技术进行整合，需要辨别不同应用间的差异并为其排定优先次序。
数据中心灾难恢复需要考虑哪些因素？
将IT变更管理作为灾难恢复的一部分
虚拟化与灾难恢复
现在，许多公司都在它们环境的某处使用虚拟化技术。但是，他们可能不知道如何使用虚拟化技术来进行数据中心灾难恢复规划。学习如何应用虚拟化到灾难恢复很有用，也会受到很多技术上的限制。
虚拟化在数据中心灾难恢复中的作用
利用虚拟化技术来进行数据中心灾难恢复
如何节省灾难恢复成本
如今否认经济形势迫使企业减少预算。尽管灾难恢复（DR）人员在极力劝阻对这个领域预算的削减，DR也无法躲过预算危机。那么对于DR站对站数据复制解决方案的创建和维护而言，有没有什么方法或工具可以降低总的成本呢？
灾难恢复预算的头号挥霍者
使用开源复制工具来降低灾难恢复成本
你是不是在为了避免麻烦而浪费灾难恢复成本？
数据中心灾难恢复需要考虑哪些因素？
回忆一下我作为IT主管和顾问所积累的数据中心灾难恢复经验，我见到过许多处于灾难恢复标准制定、技术研发、设备部署及改进的企业。灾难恢复策略和基础架构本身就很复杂，对于大型企业来说更是这样。在这个过程中存在许多可变因素：需要确定许多标准和流程，需要对人力资源进行组织，需要对技术进行整合，需要辨别不同应用间的差异并为其排定优先次序。加上内部与灾难相关的一些不确定因素，无论发生何种事件，整个在哪恢复的过程都会变得异常复杂。
对于一些基本的事件做一定的假设并将内外部因素都考虑进去显得很关键。这使人们可以认识到在灾难恢复流程研发过程中对这些小问题进行处理的意义所在。如果不这样做，等待你的只能是严重的后果。
关于这方面我已经多次在“DR预期差距”的演示中做过阐述，其中讲到了企业的可恢复性设想往往与实际的IT技能不符。事实上，如果这些假设因素没有得到明确的界定和处理，你昨日的灾难恢复功臣就有可能变成明日的替罪羊。
当然了，在这些假定因素中，创建灾难恢复的RTO和RPO等级是最关键的，而在制定灾难恢复规划的过程中还有其它许多因素需要考虑和权衡。以下列出的是一些很实际的规划条目，这些因素对于灾难恢复方案的设计和规划而言很有意义：
员工：在执行灾难恢复计划过程中，IT员工是否都能参与？他们如何到达备用的灾难恢复站点？是否已为他们准备了短期的住所？在灾难发生后，一部分员工要待在总部，而不是立即就参与到数据中心恢复中去。
基础设施：完成灾难恢复计划需要有哪些通信和交通运输设施的支持？如果飞机不能起飞、手机无法使用或道路受到封堵该怎么办？
位置：要考虑灾备中心与总部的距离因素，以及灾备中心所能承受的灾难等级是多少？看看许多最佳措施的做法，他们的灾备中心距离都很远，为的是避免受到同一灾难的影响——而你的呢？
灾难通报：如何进行灾难通报？由谁来通报？RTO“计时器”何时开启？
灾备站点的运营：灾备站点需要运营多长时间？需要为其提供哪些支持？如果你是在使用第三方的灾备站点，这一点就显得更为重要。
期望性能：在灾难恢复过程中你是否期望所有应用性能都达到较高的标准？可以容忍什么样的性能等级，可以容忍多长时间？
安全：灾难恢复期间的安全要求是否要与灾难发生前保持一致？在许多特殊情况下，你对安全的要求要比平时生产期间更高。
数据保护：灾难恢复站点的数据备份和数据保护设备如何安置？记住，灾难恢复站点的数据每天都要进行备份。
站点保护：你有没有给灾难恢复站点也制定一个灾难恢复规划呢？如果没有，应该立即动手做一个，此外你还应该考虑由谁来对其负责？
规划地点：灾难恢复规划应该放在哪儿？（最好不在你自己的数据中心）。由谁来负责维护？如何与其进行沟通？
显然，为了保证灾难恢复的成功实施，还有许多因素需要考虑和解决，但仍希望本篇技巧能够帮助你走上正轨。
查看原文(作者：Bill Peldzus译者：王霆来源：TechTarget中国)
将IT变更管理作为灾难恢复的一部分
数据显示，大多数数据中心灾难都人为原因导致的。在与许多数据中心经理交谈过程中，我发现这些人为因素主要分为两种情况：一是缺乏精确的变更管理流程；二是在进行简单变更操作时忽略了对现有的管理流程。
这里我讲的并不全是那些飓风和暴风雪之类的大型灾难。我谈论的是打断数据中心正常业务运营、影响公司收入的所有事故。与IT员工或其它员工的认为因素相比，数据中心发生自然灾难的概率要小的多。数据中心灾难恢复规划需求具有一定的季节性，对美国企业来讲，8月份开始需求会上升，到11月份会有所减少，那时候大多数公司都已开始制定自己下一年度的预算规划了。从某种程度上讲，这与美国的飓风多发季节是保持一致的。
而如今，在各家公司即将开始准备制定下一年度预算规划的前夕，我们来讨论一下数据中心如何减少自己的宕机时间。
成熟的IT进程模式：CMM和ITIL
能力成熟度模型（CMM）将IT软件的成熟度分为5个等级，第5级是最高的。要达到每一级都需要付出大量的努力，但由此获得的回报也是很可观的。而ITIL则为IT机构提供了一种定制需求、实现更高组织成熟度等级的框架模型。
但是，让我们来看一下评估组织机构成熟度模型的现实情况。首先，这不是一个短暂的进程。多数机构升一个等级要花一年左右的时间。他们需要对员工进行相关培训，由于许多员工对于基础设施的变更都有抵制情绪，在这个过程中会有许多问题产生。不到他们自己亲身经历这些变更的时候他们是不会相信这些流程的价值的，更不用说去尽力支持了。此外，还有一些员工往往不愿意采用这些新的进程。这很不幸，这样的结果就是你将他们调整到其它位置或是将其解雇。大约一年前，我与一家致力于从CMM2级向3级晋升的公司有过接触，其副总裁拒绝部署变更流程，他认为这是一种额外的工作，没有什么价值所在。几个月后，我得知消息说公司解雇了这位副总裁并找人来代替了他的位置。
通过部署进程和管理方案可以提高组织的成熟度，并减少IT变更管理中的错误，这就最终减少了数据中心灾难的发生。但是，永远没有一个方案可以完全解除人为的错误。有时候即使是一个很小的失误也会导致灾难的发生。
即便是很小的变更也可能导致数据中心灾难发生
Burton Group的研究发现，即使是一些很小的事情也可能导致IT机构陷入麻烦。具体情况如下：
1.有的IT机构总是想寻找更高效的方式——最常见的做法是为了提高效率而对某些流
程进行删减；
2.某些小的配置变更进程似乎是可以被跳过的。通常企业会将一些看起来似乎不是很重
要的变更流程省去，为的是提高业务速度；
3.将一些可以跳过的进程提前完成；
4.有些进程第一次这样做没有引起故障，但并不代表它永远不会发生故障；
5.有的进程一旦第一次被跳过，那第二次也很可能被跳过；
所有这些非正规操作的步骤都是IT系统故障发生的隐患，这些隐患随时可能导致数据中心灾难发生。
要想提升IT进程成熟度，最基本的是要严格遵守各种既定的进程和流程，即使这些流程看似并不是很重要。这对于减少数据中心故障的发生是很有用的。
是时候该提高IT进程的成熟度了
金融危机为机构提供了一个改进IT进程成熟度的时机。在经济繁荣时期，IT机构将业务重点都放在尽可能快地构建IT基础设施和服务以支持业务增长上了。所有的CIO都明白IT进程应该为促进业务增长而服务，而不应该成为业务增长的绊脚石。就像我的一位同事所说的：“在经济繁荣时期，IT组织一直在以最快的速度为自己的…业务机车?铺设轨道，而在经济危机时期，他们就有机会重新审视一下自己的基础架构和进程，来为提高效率而对其进行一些改进了。”
如今，IT机构是时候该将他们的注意力更多地放在改进组织成熟度和效率上了，这对于降低数据中心灾难发生的人为原因来讲也是很关键的。
(作者：McFarlane译者：王霆来源：TechTarget中国)
虚拟化在数据中心灾难恢复中的作用
现在，许多公司都在它们环境的某处使用虚拟化技术。但是，他们可能不知道如何使用虚拟化技术来进行数据中心灾难恢复规划。学习如何应用虚拟化到灾难恢复很有用，也会受到很多技术上的限制。
在商业服务器领域，虚拟化技术有如野火般迅速蔓延。通过将旧服务器整合到多核多处理器的新服务器可以获得非常诱人的投资回报率（ROI），但很多IT企业虚拟化服务器的速度都还不够快。
在世界各地的研讨会和大型会议上，我与很多IT经理、主管和CIO都探讨过业务持续和灾难恢复的话题。在与他们讨论的同时，我还针对商业服务器虚拟化的应用做了民意调查，发现了一些很有趣的现象。和我讨论的这些人当中，大约75%的人在他们的环境中应用了虚拟化技术，包括测试、开发和生产。大约33%的人表示在生产系统中应用了虚拟化技术，其中，几乎100%的人都是为了获得服务器整合的效益才应用这个方案的。令人吃惊的是，很少有人（不到5%，甚至有的听众中一个都没有）使用高级软件，如VMware的DRS（分布式资源调度程序）或Vmotion。
每次，听众中都不到10%的人应用高可用性集群保护虚拟机基础设施，这让我感到很震惊。同样，很少有人积极地利用虚拟机技术进行灾难恢复（DR）。很多人表示他们倒是愿意看看如何借助虚拟化进行灾难恢复，但是目前还没有执行过。
尽管一些IT公司都一致宣誓要做好灾难恢复，但它们很少有人利用高级虚拟化软件进行灾难恢复。那么，虚拟化在灾难恢复时有什么了不起的作用呢？下面，我们一起来看看：
硬件独立：基于物理系统的灾难恢复解决方案都需要将相同的硬件保留到恢复站点，或必须经过很多复杂耗时的步骤在新的或不同的硬件上重建服务器操作系统。有时候碰巧恢复服务器就是同一个硬件模型，但是包含了最新硬盘控制器固件，会导致服务器镜像延迟。虚拟化使硬件从操作系统中抽象化，而且使操作系统中使用的设备驱动器统一化，不管是何种底层硬件模型，所有虚拟机都使用一个共同的驱动集。这样，在新服务器上安装服务器镜像时就省了很多设备驱动对应的麻烦，大大减少了恢复时间和配置错误的风险。
虚拟机磁盘格式文件：虚拟机将其子操作系统、应用、存储和配置（如IP地址）存放在一个文件里。这个文件——虚拟机磁盘格式（VMDK）或虚拟硬盘（VHD）文件，包含了整个操作系统环境以便能进行简单的虚拟机装载和保存。这个文件不仅包含了操作系统镜像和应用编码，还描述了虚拟机所需的配置，其中包括虚拟处理器、内存和设备。这个简单的可移动文件包含了组成服务器所需的一切信息、服务器环境描述、实际码和数据。从虚拟机磁盘文件启动虚拟机时系统会自动迅速设置所有参数。在灾难恢复站点进行恢复会变得很简单，只需启动VMHD或VHD。
物理工具到虚拟工具：虚拟机解决方案需要利用管理工具来创建、启动、停止和保存虚拟机镜像。为了方便创建虚拟机，有很多工具可以帮助分析物理服务器和从服务器创建VMDK或VHD。从物理系统创建的VMDK或VHD文件可以很快地部署到恢复站点。
硬件再利用：恢复站点的虚拟机硬件不必闲置在那里等着灾难发生，它也可以用作开发、测试或其它用途。当发生灾难时，关闭用于测试或开发的虚拟机，然后启动生产虚拟机，这个过程只需几秒钟即可完成。
基于虚拟化技术的灾难恢复解决方案看起来很似乎很不错，不过一定也有其不足之处，不是吗？这些解决方案对大部分工作有效，但并不是全部都管用。有些要求苛刻的应用，如高I/O数据库，可能会由于额外的虚拟化管理费用而限制了它们的性能。目前，大多数数据库厂商的产品还不支持虚拟化环境（但这即将会改变，所以请关注市场动态）。另外，有些应用或服务需要专门的硬件设备，在虚拟环境中可能不支持它们所需的那些设备。在这些特殊情况下，你就只能用统一物理硬件的方法来建立灾难恢复解决方案，忍受更加繁琐的恢复过程了。
(作者：Richard Jones译者：涂凡才王霆源：TechTarget中国)
利用虚拟化技术来进行数据中心灾难恢复
服务器虚拟化正迅速成为许多组织灾难恢复（DR）策略中的一个关键组成部分，因为借助虚拟化技术的某些特殊功能，可以精简灾难恢复的过程。
尽管如此，服务器虚拟化仍然没有广泛用于灾难恢复目的。虽然服务器虚拟化在灾难恢复过程中有许多方便之处，但也带来了新的挑战。本文将同时介绍在灾难恢复过程中使用服务器虚拟化技术带来的好处及其缺点。
虚拟机（VM）本身有两个特性对灾难恢复非常有利：
●硬件无关性：虚拟机天生就与底层的物理硬件是隔离的，它们之间由虚拟化软件进行隔
离。
●封装：虚拟机是封装在独立的存储区域中的，根据不同的虚拟化解决方案，有可能是以文
件形式或特定LUN形式进行封装。
同样，虚拟机整齐地封装到独立的存储单元后，可以简化灾难恢复时对虚拟机的处理。SAN复制软件可以将虚拟机复制到灾难恢复站点，由于虚拟机的硬件无关和封装特性，复制虚拟机比复制传统物理机要快得多。
但服务器虚拟化不是灾难恢复的灵丹妙药，使用服务器虚拟化技术进行灾难恢复也有其独有的挑战。虚拟化软件本身需要处理好存储陈列，如我在一篇文章“尽量避免VMware环境中的存储阵列快照陷阱”中描述的。如果存储阵列使用快照处理复制，必须确保快照的一致性，否则复制到灾难恢复站点的数据可能是无效不可用的，那灾难恢复站点也就发挥不了作用，因为虚拟机镜像都不是一致的。
某些服务器虚拟化解决方案强调了灾难恢复的程序性规定，用户从生产站点向灾难恢复站点复制虚拟机数据时，服务器虚拟化技术能自动识别这些虚拟机的存在吗？还是需要手动告诉服务器虚拟化软件虚拟机数据已经存在？如果存在，那么它们的存储位置在哪里？答案很可能是后者，在整个灾难恢复策略中使用虚拟化技术时必须考虑这一点。
最后，值得注意的是服务器虚拟化很多事情并未抽象化，例如底层硬件上的操作系统，组织还是要处理类似IP地址分配等问题。DHCP预留技术是控制生产数据中心和灾难恢复数据
中心服务器IP地址的一个常见方法，使用DHCP预留需要使用静态MAC地址，但有些虚拟化解决方案默认使用的是动态MAC地址。
幸运的是，已经有服务器虚拟化厂商和第三方开发者推出了新的产品，解决了这个问题，如：
●Vmware最近引入了站点恢复管理器（Site Recovery Manager，SRM），它提供了
一个工作流自动化工具，帮助使用Vmware Infrastructure进行灾难恢复。
●Double-Take软件公司推出了一个新版本的Double-Take，它可以帮助使用微软
Hyper-V进行灾难恢复，新版本提供了数据复制功能。
毫无疑问，随着服务器虚拟化市场的成熟，将来会有更多类似的产品推出，使用虚拟化技术进行灾难恢复也将越来越简单。
我只想请你记住，服务器虚拟化可以简化灾难恢复的过程，在制定总体灾难恢复策略时，服务器虚拟化应该是一个重点考虑的部分。
(作者：Scott Lowe译者：黄永兵来源：TechTarget中国)
灾难恢复预算的头号挥霍者
在如今预算紧张，能源和交通成本不断上升的日子里，哪些花费投资是在浪费资金呢？你必须从不同角度仔细地分析你的投资情况，看看哪些有可能是在浪费资金。例如，对于能够减少灾难恢复部署和测试成本的技术，如果不肯在这些技术上投资，那实际上是在浪费成本。这就是本文首先要讨论的灾难恢复预算头号挥霍者。
非虚拟化数据中心：虚拟化技术可以节省灾难恢复维护和测试的成本。我和很多客户谈过，他们采用虚拟化技术建立灾难恢复解决方案，甚至用于整合那些不容易整合的应用。换句话说，他们充分利用虚拟化技术灵活性的特点，以1：1的整合比率进行整合，从而简化了灾难恢复。
整合的虚拟化基础设施可以节省更多的成本。我们来看一个生活中的实例。有一家中型企业，与很多其它采用虚拟化的企业一样，它们也对大部分的应用和服务实施了虚拟化，以获得整合的效益。它们的CIO之前其实并不认为虚拟化会给它们带来任何额外的成本节约。然而，后来他惊奇地发现，这非常地节省灾难恢复的测试时间和人力资源。
在实行虚拟化之前，它们的灾难恢复测试工作（每年两次）需要7到10名IT人员花费3到5天的时间才能完成。而采用虚拟化之后，测试时间只需两名IT人员用一到两天的时间就可完成。那么，这能节省多少钱呢？假设聘请一位全职的IT工程师每年花费175000美元，他每年工作260天。对这个公司来说，最好的情况每年可节省64616美元（10个人花费5天减少到2个人花费1天，每年两次），这还不包括机会成本——执行灾难恢复测试任务的多余IT人员可以完成的工作。我们再看看最差的情况可以节省多少成本。7个人花费3天减少到2个人花费2天，每年两次，那么每年可以节省22884美元。总之，要充分利用虚拟化避免灾难恢复测试的成本浪费。
不维护灾难恢复计划：业务持续性规划会花费大量的时间和成本。你执行了规划，或者你认为你已经执行，对规划测试了一次或两次。但是，由于业务需要和紧张的预算，你不得不调整下一次灾难恢复测试的时间，将其推迟到完成目前关键项目之后。等到这个项目快要完成时，又有下一个关键项目涌现出来。于是，为了集中精力满足业务的需求，灾难恢复测试再一次被推延。这样的恶性循环周而复始，是不是觉得这种情况很熟悉？
这样的情形我见得太多了，即使是成熟的大型IT企业也有这样的情况。推迟规划的维护和测试工作无异于白白浪费最初投入灾难恢复的所有成本——几千到几万美元。历史不断地反复证明，没有坚持不断的测试和维护工作，恢复就一定会失败，或者至少会比预期要花费更长的时间，遇到更多的小问题，而这些小问题都是可以通过定期的规划测试和维护解决的。总之，对规划的维护和测试工作是一个很关键的工程。没有维护，一切灾难恢复投资都是白费。
缺少CEO的监督和董事会参与：我见过很多公司业务持续和灾难恢复都是由CIO掌控的，而不是CEO。所有这些公司在经历灾难时，都有一个共同特点：IT部门安然无恙，正常运作，但是其它部门的业务在灾难状态中都被中断了。
灾难恢复和业务持续是为了整个公司的健康发展，而不仅仅是为了IT部门。灾难恢复计划、测试和维护应该由CEO和董事会作为优先任务执行。它保护着公司的所有资产。如果灾难恢复不是由CEO掌控，那么之前所有花费在灾难恢复上的资金和时间都是白费。因为，如果发生灾难，公司整体上仍然是无法运作的。
我和一位CIO谈过，在他们公司（有5个仓库和一个数据中心）里是CEO主管着灾难恢复。这位CIO个人并不喜欢关心灾难恢复，但由于CEO的督促，他一直维护更新着规划。当有一次与中央数据中心的网络连接被意外切断后，规划开始发挥作用，订单如期完成。规划中的一些小问题被发现后，得到了修补。在事后分析中，确保规划对整个公司有效。当与数据中心失去连接时，各业务单元和员工保障业务的正常运行。总之，灾难恢复和业务持续只有由CEO和董事会操控并从全局考虑才会有效。只考虑IT部门而忽视其它部门的灾难恢复是浪费资金。
保护过度：尽管这个问题不如前面所说的常见，但我还是见过这样的问题。有的主管觉得每个服务和组件都是关键的，需要受到最高级别的保护——尤其是刚开始建立业务持续性规划的公司。
有的公司利用点对点（site-to-site）复制和热备份服务器执行数据中心恢复。它们忽视了系统风险，把所有服务和应用都放在热备份站点系统（hot site system）。结果，本来只需花费较低成本去保护的系统（如只需每周离线存储的磁带备份），他们却要花费很高的成本。
对每个系统进行详细的业务分析可以避免这样的问题。我们看看另一个稍有不同的例子，它可以说明这一点。有一个大型企业的CIO给我讲过一个他们公司精彩的事迹。他们公司提供的产品许可分很多级别，拥有客户几百万，而绝大部分客户购买的都是标准产品。标准产品许可已经被自动录入帐户追踪数据库系统，而这些特殊客户的许可有些特殊的需求，普通系统无法满足。于是，销售部请求他为这个特殊的客户群建一个客户账户许可追踪系统。
这位CIO提出了RFP，并得到一些提议和两到三百万美元的维护资金：改进或完全新建一个冗余的系统。然后，CIO询问销售部有多少这样的特殊客户。得知目前大概有400位特殊客户后，他又询问了这个特殊许可客户群的增长速度，以及在今后三年内的预期总数。销售部表示，这个特殊客户群最近三年的增长率可能为10%。
了解到这些业务信息之后，CIO购买了两个文件陈列柜，并雇佣了两名管理助理手动追踪这些客户。他还与公司记录办公室协作，对所有客户记录进行拷贝，并离线存档，以便为数据保护和业务持续备用。最后，这样的做法大概为他们节省了150万到250万美元。总之，要仔细分析业务的每个方面。盲目笼统地为所有事务处理进行灾难恢复投资可能是浪费资金。
(作者：Richard Jones译者：涂凡才来源：TechTarget中国)
使用开源复制工具来降低灾难恢复成本
如今否认经济形势迫使企业减少预算。尽管灾难恢复（DR）人员在极力劝阻对这个领域预算的削减，DR也无法躲过预算危机。那么对于DR站对站数据复制解决方案的创建和维护而言，有没有什么方法或工具可以降低总的成本呢？
首先，服务器虚拟化一次又一次地为各个机构的DR节约了时间和金钱。去年，我在top DR budget wasters上写了一篇技术性文章，其中分享了一个客户关于虚拟化和灾难恢复的故事。过去的几年，我和很多与次此相关的IT组织交谈过，大家的反应是一致的：虚拟化已经为DR测试带来了超过50%的时间和近50%的人力资源节省。
然而，在这篇文章里，我更愿意将重点放在另一方面——用开源工具进行数据复制及Linux/Solaris解决方案的低成本存储。通常来讲，一个企业的Linux系统要有将近2500个程序包，其中包括数百个有用的工具。然而，还有成千上万可用的相关开源工具可以帮你在更低成本的前提下完成DR目标。下面我们讨论一下数据复制领域的两个热门工具：rsync（remote sync数据镜像备份工具）和分布式复制块设备（DRBD）。
什么是rsync?
大多数企业的Linux系统都包括rsync，是一个文件级的复制工具，由Samba提供维护。去年他们发行了3.0版本，增加了递归式扫描功能来提高大文件系统的复制效率。（rsync必须对所有被复制的文件进行跟踪，运行太多文件会导致内存耗尽，新版本解决了这个问题）。
Linux和Solaris管理员多年来一直使用rsync来复制配置文件和非核心系统数据。其最近在扩展访问控制表支持（Xattrs）和递归扫描方面的改进及多年来在生产部署上的应用使自己成为基于Linux/Solaris数据中心负载的高级DR解决方案。
什么是DRBD？
分发复制块设备(DRBD)是一个由Linbit提供维护的块级开源复制技术。除Red Hat企业级Linux（RHEL）外，其它所有操作系统都支持该技术的运行。然而，其CentOS的版本与RHEL是二进制兼容的，并且能被RHEL使用。
DRBD通过TCP/IP网络在磁盘上写配置。只有主磁盘，或者活动磁盘，可以被文件系统访问。复制盘或从磁盘不能被访问，除非它被升级为主磁盘（在镜像被破环的时候）。DRBD可以被配置为同步或异步镜像。在同步模式下，发布写数据的文件系统无法接收到完整的写入，除非本地和远程磁盘已经都被写入了。这样做的结果是，距离和时间的延长限制了同步模式的使用。在长距离复制中异步模式效果最好。然而，如果TCP/IP 链接的带宽比写在主磁盘上的数据带宽小，当所有DRBD网络缓存都耗尽时主系统性能将受到带宽的限制。
JBODs（简单磁盘捆绑）使存储成本减少
JBOD阵列比商业存储阵列便宜多了。很多二级或次关键系统可以很好的应用于富含串行高级技术附件（SATA）磁盘的廉价JBOD阵列。虽然SATA磁盘相比更昂贵的存储磁盘并不能提供相同的速度和带宽,但它们足以满足大多数应用需求,特别是在进行DR操作的时候。利用rsync和DRBD复制技术,可以在低成本前提下将一个高性能的主系统复制成一个更便宜的JBOD系统。此类配置前提是，在灾难恢复期间，企业可以降低对服务等级的要求。
灾难恢复成本节约需要面对的风险
上述建议可疑被归结为是一个成本与风险间的交易。通常，预算紧缩的公司认为承担额外的风险来降低成本是可以接受的，特别是对于特定的应用和对公司风险较小的业务流程。除了改变功能系统外，将商业复制工具改为缺乏供应商支持的开源工具也会导致风险。但是，一些IT组织自身有能力来降低风险，或者他们可能会发现从一个Linux供应商处采购支持服务要比购买商业产品的成本更低，但无论任何地方出现问题都要保持平常心态。
然而，那些涉及核心业务的关键应用不应该面临太大的风险。大多数IT组织会花费更大的开支来将风险转移给供应商以获得服务质量，并视自己能够保持一个平常的心态。
查看原文
(作者：Richard Jones译者：喻英来源：TechTarget中国)
你是不是在为了避免麻烦而浪费灾难恢复成本？
在一次系统宕机或灾难发生后，大多数企业都能意识到确保系统高可用性及对核心应用和数据进行迅速灾难恢复的重要性，从而为企业避免经济损失。但是，通过与众多IT 机构的沟通，我发现只有很少企业能够实现技术成本与企业需求的平衡。
大多数IT机构并不知道他们的核心业务应用及数据是否已得到相应的保护。他们往往会利用他们认为合适的技术，但却经常发现在这方面的投资有些过多，这样做或许是为了满足某一两项核心应用的需求（实际上他们也不是很确信），殊不知对于所有其它应用而言这显然有些过盛了。
大多数IT机构都知道，实施BIA（业务影响分析）可以帮他们选择合适的技术来阻止业务的流失。然而，我发现几乎所有的企业在初次采用BIA时都会犯一个错误。
避免员工的麻烦是不是一个关键业务？
企业最常犯的一个错误就是在确定服务等级需求、RTO及RPO时试图保持业务的持续运营，就像什么事都没发生一样。
企业总是试图去解除其雇员及整个业务进程的麻烦，但这些麻烦事通常不会导致业务的流失和成本的浪费。是，有一种成本是与这些麻烦相关的，但大多数情况下，流失的是短期的机会成本因为员工必须采用手动业务流程。
这有个例子：我曾经跟一个组织严密的公司聊过，他们的IT部门要负责为公司内的业务部门提供服务。有一个业务部门来找IT部门要求灾难恢复RTO不超过15分钟、RPO时间不超过5分钟，其企业资源规划（ERP）系统也要从早上5点到晚上9点保持正常运行。这还是我第一次听说有人要求ERP系统的弹性等级，一般情况下企业要求的RTO是24小时，RPO是4小时。
IT组织会保证相应的成本能够满足他们的目标。粗略的估计一下，所花的费用是正常处理ERP系统费用的2.5倍。可复原性就更别说了，是正常使用的9倍。IT服务机构接下来一定会拿着正常花费单据和相应部门的要求所需的成本去找相应部门，然后问他们一个问题：“你们是不是准备通过提高服务等级的办法来解轻雇员的麻烦。
在停电期间，手工处理进程的确会给员工带来一些麻烦，但大多数情况下它都可以降低业务连续性的成本。在最近的一份灾难恢复预算调查中，我引用了一个例子，有一家分销商选择了部署手工处理进程来代替为实现数据中心冗余网络连接而花费200万美元。在数据中心网络连接中断期间，员工连续奋战36小时，他们通过电话、纸以及笔来记下订单，使分销商可以在下午五点之前将所有货物装船。但经过计算发现还是可以节省很多成本，即使是与停电期间相比。
一些例外
有些情况比较特殊，员工所面临的麻烦因素是在所难免的，因为这会威胁到人们的生命财产安全。911事件是一个很好的例子，在那种情况下，时间就意味着生与死的差别。
此外，有时候员工所要面对的麻烦也正是用户所面临的困难。当确定用户是否面临危机时要考虑诸多因素。在充满竞争的市场上，一个电子商务网站的宕机对企业来说就是一次财政危机。如果在宕机期间客户不能买到他们期望的产品和服务，他们就可能会转而投向企业的竞争对手。这样企业就可能会永远的失去这些用户。
在业务安全弹性与成本之间寻找平衡
紧缩的预算及对于降低成本的持续性压力使IT机构不得不对业务系统进行仔细审查，并找到业务安全弹性与其成本间的平衡点。要想实现这种平衡，企业首先要创建一个全面的BIA对一次宕机事故对业务开支的实际影响进行评估。一种可能是，企业为了追求更高的弹性而增加开支；另一种可能是，企业在安全弹性方面达不到要求而使自己抵御灾难的能力降低。不同的系统安全弹性会对企业财务产生不同的影响。最好的效果是在两者之间找到平衡。下图所示的是不同系统弹性等级对企业业务的影响，期中涉及的是一家年营业额8亿美元的电子商务企业。
左侧的粉色区域表示的是该企业在系统安全按弹性方面的开支，右侧粉色区域是这种开支状况下企业的风险等级。在这个例子中，企业的平衡点是每年宕机次数不超过一次，每次宕机恢复时间不超过一小时。
查看原文
(作者：Richard Jones译者：王霆来源：TechTarget中国)
数据中心灾备服务
数据中心灾备服务 方案相关内容 如何应对“将鸡蛋放在一个篮子里”所带来的风险？对于信息化应用而言，灾备系统的建设已成为备受关注的热点和重点。 概述 数据中心是数据大集中而形成的集成IT应用环境，它是各种IT应用服务的提供中心，是数据计算、网络、存储的中心。数据中心实现了安全策略的统一部署，以及对IT基础设施、业务应用和数据的统一运维管理。 数据大集中的同时也对数据安全提出了更高的要求，如何应对“将鸡蛋放在一个篮子里”所带来的风险，已成为备受关注的重点。面对频频发生的雪灾、地震等自然灾害，对于信息化应用而言，灾备系统的建设也已成为热点。随着2007年11月《信息系统灾难恢复规范》正式成为国家标准，许多用户将从观望、徘徊转向实际应用。对于正处于服务转型期的电信运营商来说，借助灾备中心应用热潮，提供更有价值的信息化服务，改变原有的、单一的网络接入商角色，是值得把握的一次良好机会。 灾难备份概念介绍 1. 灾难备份的分类 灾备从应用层次，大体可分为三个类别：数据级别、应用级别和业务级别。从用户整个业务连续性的保障程度来看，其高可用性级别也随之逐级提高。 1) 数据级别 数据级别灾备的关注点在于数据，即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。数据级别灾备是保障数据可用的最低底线，当数据丢失时能够保证应用系统可以重新得到所有数据。这种方案的优点是投入低，构建简单。 2) 应用级别 对于业务应用繁多，并且系统需要保持7*24小时连续运行的企业来说，显然需要高级别的应用灾备系统来满足其需求。应用级备份是在数据级灾备的基础上，在备份站点同样构建一套应用系统。应用级灾备系统能提供不间断的应用服务，使用户的服务请求能够透明地继续运行，保证信息系统提供的服务完整、可靠和安全，完全不受灾难的影响。一般来说，应用级灾备系统需要通过更多软件来实现，它可以使企业的多种应用在灾难发生时进行快速切换，确保业务的连续性。 3) 业务级别
数据中心运维投标书
数据中心运维投标书 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】
数据中心运维投标书 **有限公司 二零一四年八月
目录
第一章投标申请及声明 致：****采购中心 根据贵方为项目招标的投标邀请（项目编 号：），签字代表（姓名、职务）经正式授权并代表投标人（投标人名称、地址）提交下述文件正本一份，副本四份： 1．投标文件 2．投标一览表 3．投标分项报价表 4．服务产品说明一览表 5．偏离表 6．资格（资质）证明文件[包括招标公告中要求提供的资格（资质）证明材料] 7．招标文件要求提交的其他文件 8．投标诚信承诺书 在此，签字代表宣布同意如下： 1．我方完全了解在本项目招标公告中公布的采购预算，并承诺各包件的投标价不超预算。所附投标一览表中规定的各包件应提供和交付的服务的投标价为： （以人民币元为单位，用文字和数字分别表示）。 2．我方将按招标文件的规定履行合同责任和义务。 3．我方已详细审查全部招标文件，包括澄清文件（如有的话）以及全部参考资料和有关附件，我方完全理解并同意放弃对这方面有不明及误解的权利。 4．我方接受本项目招标文件“投标资料表”中所规定的投标有效期。。 5．我方同意提供按照贵方可能要求的与其投标有关的一切数据或资料，完全理解贵方不一定要接受最低价的投标或收到的任何投标，完全理解并接受招标人和招标机构对评标资料保密且不解释落标原因。 6．我方已按照本项目招标文件中所附的《资格（资质）性检查表》以及《符合性检查表》进行了自查，对招标机构根据《资格（资质）性检查表》
判定无效投标以及评标委员会根据《符合性检查表》判定非实质性响应投标无任何异议。 7．我方同意按照《政府采购法》及相关法律法规的规定提出询问或质疑。我方已经充分行使了对招标要求提出质疑和澄清的权利，因此我方承诺不再对招标要求提出质疑。 8．与本投标有关的一切正式往来信函请寄： 地址：邮编： 电话：传真： 手机：电子邮件： 投标人法人授权代表签字 投标人名称 公章 日期 开户银行 账号
数据中心运维管理框架
6.2数据中心运维管理框架 6.2.1.运维管理框架4Ps概述 所谓数据中心运维管理框架是指管理一个数据中心所使用的方法与手段的总称。那么，应该用什么样的方法与手段来管理数据中心呢?在此，信息技术基础架构库(InformationTechnologyInfrastructureLibrary，ITIL)给出了一个比较好的管理框架，即所谓的4Ps。数据中心运维管理框架如图6-3所示。 图6-3数据中心运维管理框架 1.人员 人员是数据中心运维管理的基础，也是数据中心运维管理的核心。一个好的数据中心运维管理框架，少不了合适的技术和管理人员。从前面数据中心运维管理概述中，可以看到数据中心所需要管理的对象，包括基础设施、IT设备、系统与数据、管理工具和人员等。只有具备相应知识背景与管理经验的人，才能有效地整合上述资源，为客户提供符合质量与合同要求的IT服务。因此，在考虑建设数据中心运维管理框架时，必须要考虑到：如何建立起一套科学合理的包括选、用、培养、考核及解聘的人员管理生命周期;如何通过合理的组织架构设计与人员分工，最大限度地发挥个人的主观能动性，为组织目标贡献力量等。 2.流程
流程是数据中心运维管理质量的保证。作为客户IT服务的物理载体，数据中心存在的目的就是保证服务可以按质、按量地提供。服务与产品有着许多的不同，其中最核心的不同在于服务本身是看不见、摸不着的，但又是能通过服务商与客户的互动为客户所感受到的。为确保最终提供给客户的服务是符合服务合同的要求，数据中心需要把现在的管理工作抽象成不同的管理流程，并把流程之间的关系、流程的角色、流程的触发点、流程的输入与输出等进行详细定义。通过这种流程的建立，一方面可以使数据中心的人员能够对工作有一个统一的认识，更重要的是通过这些服务工作的流程化使得整个服务提供过程可被监控、管理，形成真正意义上的“IT服务车间”。 3.产品 产品是数据中心运维管理的加速器。数据中心运维管理涉及的对象庞杂，且重复性工作较多。若完全依靠人工去完成这些工作，一方面对人员的技能与数量有较高的要求，另一方面在工作质量的保证方面也存在风险。为此，越来越多的数据中心在开展运维管理工作时使用大量工具，目的是通过这些工具的部署取代一些监控、操作、配置文件、工作流管理等大量重复性工作，最终实现提升运维水平、降低运维风险、减少运维成本的目的。 4.服务商 服务商是数据中心运维管理的支持者。作为专业化的数据中心运维管理，有效地整合数据中心管理对象，并最终为用户提供专业化的服务才是数据中心服务提供者的核心价值所在。而且，数据中心运维管理中涉及了太多不同种类的设备，数据中心也不可能把所有的技术与管理工作独自承担。聘用一批既懂变压器、发电机、UPS，又了解空调、消防、防火设备，同时还精通IT相关软硬件的人员，对于任何一个企业或机构均是极大的成本支出。所以，数据中心需要与许多设备供应和服务提供商建立良好的战略合作关系。 6.2.2.运维管理的人员要求 如前所述，人员既是数据中心运维管理的基础，也是数据中心运维管理的核心。一个数据中心组建团队时应注意什么呢?以下重点就人员技能、人员分工与人员管理三个方面谈一下数据中心运维管理方面的人员要求。 1.人员技能
数据中心和网络机房基础设施规划指南
避免数据中心和网络机房基础设施因过度规划造成的资金浪费
典型数据中心和网络机房基础设施最大的、可以避免的成本就是过度规划设计成本。数据中心或 网络机房中的物理和供电基础设施利用率通常在50%-60%左右。未被利用的容量就是一种原本可以避免的投资成本，这还代表着可以避免的维护和能源成本。 本文分为三个部分。首先，介绍与过度规划设计有关的情况和统计数据。接下来，讨论发生这种情况的原因。最后，介绍避免这些成本的新的架构和实现方法。 任何从事信息技术和基础设施产业的人都曾见过未被利用的数据中心空间、功率容量以及数据中心中其他未加利用的基础设施。为了对这种现象进行量化，对讨论中用到的术语进行定义是很重要的。 表1中定义了本文中有关过度规划设计的术语： 建模假设 为了收集并分析过度规划设计的相关数据，施耐德电气对用户进行了调查，并开发了一个简化模型来描述数据中心基础设施容量规划。该模型假设： ?数据中心的设计寿命为 10 年； ?数据中心规划有最终的设计容量要求和估计启动IT 负载要求； ?在数据中心典型生命周期过程中，预期负载从预期的启动负载开始呈线性增长，在预期生命周期一半的时候，达到预期最终容量。 由以上定义的模型得出下面图 1 显示的规划模型。我们假定，它是具有代表性的“一步到位”模式的系统规划模型。 简介有关过度规划设计的情况和统计数据表1 过度规划的相关定义
上图显示了一个典型的规划周期。在传统的设计方案中，供电和冷却设备的安装容量与设计容量相等。换句话说，系统从一开始就完全建成。根据计划，数据中心或网络机房的预期负载将从30% 开始，逐步增加到最终预期负载值。但是，实际启动负载通常小于预期启动负载，并且逐步增长到最终实际负载；最终实际负载有可能大大小于安装容量（注意：由于冗余或用户希望的额定值降低余量，实际安装设备的额定功率容量会大于计划安装容量）。 第143号白皮书《数据中心项目：成长模型》详细讨论了数据中心的规划以及制定一个有效的成长计划战略的关键要素。 实际安装数据收集 为了了解实际安装的情况，施耐德电气从许多客户那里收集了大量数据。这些数据是通过实际安装设备调查和客户访谈获得的。结果发现，预期启动负载通常只有最终设计容量的 30%，预期最终负载只有预期设计容量的80%-90%（留有安全余量）。进一步发现，实际启动负载通常只有最终设计负载的20%，而且实际最终负载通常为设计容量的 60% 左右。图 1 汇总了这些数据。根据设计值，通常的数据中心最终的容量设计比实际需要大 1.5 倍。在刚刚安装或调试过程中，超大规模设计甚至更加显著，通常在 5 倍左右。 与过度规划设计相关的额外成本 与过度规划设计相关的生命周期成本可以分为两个部分：投资成本和运营成本。 图 1 阴影部分指出了与投资相关的额外成本。阴影部分代表平均安装设备中未利用的系统设计容量的部分。额外容量可直接导致额外的投资成本。额外投资成本包括额外供电设备和冷却设备的成本，以及包括布线和管路系统的设计开销和安装成本。 对于一个典型的 100 kW 数据中心，供电和冷却系统有550万人民币（55元人民币/W ）左右的资本成本。分析表明，这个投资的 40% 左右被浪费掉了，相当于 220万人民币。在使用早期，这个浪费甚至更大。算进资金周转的时间成本之后，由于过度规划设计导致的损失几乎等于数据中心50%的投资成本。也就是说，单单原始资本的利息几乎就能够满足实际资本一般的需求。 与过度规划设计有关的额外生命周期成本还包括设施运行的开支。这些成本包括维护合同、消耗品和电力。如果设备按制造商的说明进行维护，年维护费用一般是系统成本（投资成本）的10%左右，因此，数据中心或网络机房的生命周期过程中的维护成本几乎等于投资成本。由于过度规划设计会产生未充分利用的设备，而且这些设备必须加以维护，所以会浪费很大一部分的维护成本。以 100 kW 数据中心为例，系统生命周期过程中浪费的成本约为 950万人民币。 0% 20% 40% 60%80%100%120% 012345678910 容量百分比数据中心运行年份 图1 数据中心生命周期过程中的设计容量和预期负载要 求
全球数据中心灾难史大盘点
触目惊心！全球数据中心灾难史大盘点2012-11-29 数据中心的常见【杀手】 数据中心，支撑整个IT系统正常运转的后台架构，囊括了计算、存储、网络等多种IT资源。也正是因为数据中心地位的重要性和在现代社会生活中扮演的重要角色，使得数据中心的安全和持久稳定运行成为了人们极为关注的问题。然而，前段时间飓风桑迪为代表给数据中心带来的灾难性创伤，再次引发了人们对数据中心的安全担忧。本文，将为读者介绍全球数据中心遭遇到的灾难事故，并从中总结得出数据中心安全杀手以及如何防范等问题。 本月早些时候，飓风桑迪重创美国东海岸，尤其是支持着整个工业园运转的数据中心在此次飓风肆虐中因断电而瘫痪，造成了难以挽回的巨大损失。 那么，数据中心常见的杀手有哪些呢？换句话说，究竟有哪些因素会影响数据中心的正常运行、而需要我们特别加以重视的呢？一般说来，以下因素或者灾害对数据中心会带来较大危害： 一、洪灾 毋庸置疑，曾经泰国洪灾给硬盘产业带来的影响就可以“窥一叶而知春秋”，数据中心也同样害怕汹涌的洪灾； 二、火灾 俗话说“大火无情”，一旦出现火灾事故，后果不堪设想。也正是如此，数据中心往往都备有消防装备； 三、网络中断 光纤网络在很多偏远地区并不常见，如果路由器、交换机出现宕机或者人为误操作（误配置）导致网络中断，后果同样不堪设想。没有网络的数据中心宛如一座孤岛——对于提供网络或者云服务的数据中心来尤其如此； 四、电力中断 相比网络中断，电力中断带来的麻烦更大。没有电力的数据中心就如同一堆废铁； 五、地震 去年日本大地震带来的影响，大家可能都历历在目。身处地震带或者地震频发周边的数据中心尤其要注意在防震方面的设计和构建。
数据中心运维服务方案
数据中心机房及信息化终端设备维护方案 一、概况 xxx客户数据中心机房于XX年投入使用，目前即将过保和需要续保运维的设备清单如下：
另外，全院网络交换机设备使用年限较长，已全部过保，存在一定的安全隐患。 二、维保的意义 通过机房设备维护保养可以提高设备的使用寿命，降低设备出现故障的概率，避免重特大事故发生，避免不必要的经济损失。设备故障时，可提供快速的备件 供应，技术支持，故障处理等服务。 通过系统的维护可以提前发现问题，并解决问题。将故障消灭在萌芽状态， 提高系统的安全性，做到为客户排忧解难，减少客户人力、物力投入的成本。为 机房内各系统及设备的正常运行提供安全保障。可延迟客户设备的淘汰时间，使 可用价值最大化。 通过引入专业的维护公司，可以将客户管理人员从日常需要完成专业性很强 的维护保养工作中解放出来，提升客户的工作效率，更好的发挥信息或科技部门 的自身职能。 通过专业的维护，将机房内各设备的运行数据进行整理，进行数据分析，给
客户的机房基础设施建设、管理和投入提供依据。 三、维护范围 1、数据中心供配电系统 2、数据中心信息化系统 3、全院信息化终端设备 4、数据库及虚拟化系统 四、提供的服务 为更好的服务好客户，确实按质按量的对设备进行维护；我公司根据国家相关标准及厂商维护标准，结合自身多年经验积累和客户需求，制定了一套自有的服务内容： 1、我公司在本地储备相应设备的备品备件，确保在系统出现故障时，及时免费更换新的器件，保障设备使用安全。 2.我公司和客户建立24小时联络机制，同时指定一名负责人与使用方保持沟通，确保7*24小时都可靠联系到工程技术人员，所有节日都照此标准执行。 3.快速进行故障抢修：故障服务响应时间不多于30分钟，2小时内至少2人以上携带相关工具、仪器到达故障现场，直到设备恢复正常运行。 4.我公司对维修维护的设施设备的使用性能负责，在维修维护过程中严格执行技术规范，保证设施设备的性能符合相关技术标准要求。在维修维护间，我方应对设施设备可能存在的故障隐患做出评估，并进行恰当的预防性处理，以保证设
云计算数据中心的运维管理
云计算数据中心的运维管理 现代信息中心已成为人们日常生活中不可缺少的部分，因此信息中心机房设备的运行正常与否就非常关键。在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。加强对云计算运维管理的要点以及相应改进方面措施的研究与探讨，以此不断提高IT运维质量，实现高效的运维管理。这就给运维是否到位提出了严格要求。 1 运维在机房中的地位 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理是，为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统地计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负合规性、可用性、经济性、服务性等四大目标。 在信息中心机房配备有运维人员，但大都是“全才”的，即什么都管，尤其是对供电系统大都是由主机运维的人员代管。当电源系统出故障时，此代管人员一问三不知，甚至连配电柜门都没开过。这实际上就是把机房的运维放在了一个次要的地位。 当然也有的地方有所分工，看似重视，实际上也没得到真正地重视。比如说机房设备长时间一直运行正常，这时如果运维人员提出要增添运维方面的测量设备，有的领导就认为多余，很难得到批准。但他不知道机房设备所以长时间一直运行正常，正是由于这些运维人员的细心维护和努力保养所获得的。并不是这些人员每天闲着无事可干，他们的这些工作一般是领导看不见的。比如同样多款的UPS在同样的环境条件下，在某卫星地面站就极少出故障，而在同系统别的地方机房同一家同规格的机器就故障连连。原来是前者的运维人员每天都在细心观察和分析机器面板LCD上显示的数据，一旦发现异常苗头及时采取措施;而后者只限于每天抄写这些数据就算完成任务，使异常苗头不断积累，以致于导致故障。比如断路器在额定闭合状态发现触点处温度高了，就要检查是不是电流过大到超过额定值，如果不是就要检查触点接触是否牢靠，是否需要再紧固一下。这样一来，故障隐患就排除了。如果一直不管不问久而久之就会导致跳闸而使系统崩溃。这都是一些小的动作，都是在巡查中顺便做的事情。所以同是运维人员在巡查，但前者在做事而后者只是走马观花。这就是数据中心可靠与不可靠的区别。 运维人员就像幼儿园的保育员和老师。孩子交到幼儿园后，起主要作用的就是保育员和老师，这时保育员和老师就是主体。机器就好比是幼儿园的孩子，孩子是否健康成长，机器是否正常运行，除去本身的健康(可靠性质量)状况外，那就是运维人员的责任了。由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性，除基于ITIL(IT 基础设施库)的常规数据中心运维管理理念之外，以下运维管理方面的内容，需要我们加以重点关注。 2 云计算数据中心运维管理的要点 (1)理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象一般可分成5大类： ①机房环境基础设施 这里主要指的是为保障数据中心所管理的设备正常运行所必需的网络通信、供配电系统、环境系统、消防系统和安保系统等。这部分设备对于用户来说几乎是透明的，比如大多数用
企业数据中心建设方案
数据中心，让企业变的智能、智慧 -------------企业数据中心建设方案 需求背景 随着电子商务的蓬勃发展，公用云、行业云的快速推广，以及社交软件、移动支付的普及，一方面是企业数据量成倍增加，另一方面是企业数据更加碎片化，造成企业经营决策越来越复杂，因此企业的数据管理水平，将直接决定公司的管理水平，数据中心将成为企业经营大脑，让企业变的智能、智慧。 同时，多年来我们一直在践行大型企业的信息化建设，参于、知悉有的大型企业采用统一规划推动建设的，也有单一业务部门推动建设的，但不管哪种模式，在战略调整、管理变革、领导变动等因素的推动下，应用系统被不断的迭代，而软件厂商不断的扮演着“换”与“被换”的角色。深入分析，业务系统是业务管理的工具，随着管理思想、管控要求、业务流程、业务规则的变化而变化属于正常迭代，而且不可避免，但业务系统的背后财务数据、人事数据、业务数据等数据一直不变，而这些数据是公司非常有价值的资产，因此必须通过数据中心的建设，将不同领域、不同单位、不同软件的数据进行集中统一管理，才能实现数据综合分析、决策支持应用。 如何采集、积累并利用数据资源？如何消除企业各业务之间的信息孤岛？如何主动适应各种应用系统迭代与升级？这个三个问题是企业数据中心建设必须面对的问题。 解决方案 方案简介 我们认为数据中心建设是建立企业级数据标准、数据模型为基础，按数据仓库、数据集市数据存储设计理念管理数据，通过主数据系统管理基础数据，数据模型装载业务数据，自动数据采集系统打通业务系统与数据中心的信息通道，企业服务总线系统打通应用系统与应用系统之间信息通道，在线填报系统补充缺少系统领域的数据，决策支持系统进行数据挖掘与展示。即2套体系7个系统，2个体系为数据标准体系、数据模型体系，7个系统为主数
云计算数据中心的运维管理-培训课件
望采纳 云计算数据中心的运维管理 现代信息中心已成为人们日常生活中不可缺少的部分，因此信息中心机房设备的运行正常与否就非常关键。在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。加强对云计算运维管理的要点以及相应改进方面措施的研究与探讨，以此不断提高IT运维质量，实现高效的运维管理。这就给运维是否到位提出了严格要求。 1 运维在机房中的地位 在数据中心生命周期中，数据中心运维管理是数据中心生命周期中最后一个、也是历时最长的一个阶段。数据中心运维管理是，为提供符合要求的信息系统服务，而对与该信息系统服务有关的数据中心各项管理对象进行系统地计划、组织、协调与控制，是信息系统服务有关各项管理工作的总称。数据中心运维管理主要肩负合规性、可用性、经济性、服务性等四大目标。 在信息中心机房配备有运维人员，但大都是“全才”的，即什么都管，尤其是对供电系统大都是由主机运维的人员代管。当电源系统出故障时，此代管人员一问三不知，甚至连配电柜门都没开过。这实际上就是把机房的运维放在了一个次要的地位。 当然也有的地方有所分工，看似重视，实际上也没得到真正地重视。比如说机房设备长时间一直运行正常，这时如果运维人员提出要增添运维方面的测量设备，有的领导就认为多余，很难得到批准。但他不知道机房设备所以长时间一直运行正常，正是由于这些运维人员的细心维护和努力保养所获得的。并不是这些人员每天闲着无事可干，他们的这些工作一般是领导看不见的。比如同样多款的UPS在同样的环境条件下，在某卫星地面站就极少出故障，而在同系统别的地方机房同一家同规格的机器就故障连连。原来是前者的运维人员每天都在细心观察和分析机器面板LCD上显示的数据，一旦发现异常苗头及时采取措施;而后者只限于每天抄写这些数据就算完成任务，使异常苗头不断积累，以致于导致故障。比如断路器在额定闭合状态发现触点处温度高了，就要检查是不是电流过大到超过额定值，如果不是就要检查触点接触是否牢靠，是否需要再紧固一下。这样一来，故障隐患就排除了。如果一直不管不问久而久之就会导致跳闸而使系统崩溃。这都是一些小的动作，都是在巡查中顺便做的事情。所以同是运维人员在巡查，但前者在做事而后者只是走马观花。这就是数据中心可靠与不可靠的区别。 运维人员就像幼儿园的保育员和老师。孩子交到幼儿园后，起主要作用的就是保育员和老师，这时保育员和老师就是主体。机器就好比是幼儿园的孩子，孩子是否健康成长，机器是否正常运行，除去本身的健康(可靠性质量)状况外，那就是运维人员的责任了。由于云计算的要求弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性，除基于ITIL(IT基础设施库)的常规数据中心运维管理理念之外，以下运维管理方面的内容，需要我们加以重点关注。 2 云计算数据中心运维管理的要点 (1)理清云计算数据中心的运维对象 数据中心的运维管理指的是与数据中心信息服务相关的管理工作的总称。云计算数据中心运维对象一般可分成5大类： ①机房环境基础设施 这里主要指的是为保障数据中心所管理的设备正常运行所必需的网络通信、供配电系统、环境系统、消防系统和安保系统等。这部分设备对于用户来说几乎是透明的，比如大多数用户都不会忽略数据中心的供电和制冷。因为这类设备如果发生意外，对依托于该基础设施的应用来说是致命的。 ②数据中心所应用的各种设备
现代数据中心建设中的几个关键点
[导读]本文通过作者近年来在基层参与多次机房建设的经验与体会,列举了大量的工作实例,就机房空调、UPS、供配电以及设备安装、管路铺设等结构方面的问题结合理论进行了深入分析与探讨，可供大家在机房建设中借鉴以及做进一步讨论。 近年来，随着计算机技术的飞速发展，数据中心机房技术的发展更是日新月异，笔者最近三年先后参与了苏州建行(全国建行系统五大城市行之一)数据中心机房、建设银行总行苏州信用卡分中心(存储和处理中国南方地区的信用卡数据与交易)的数据中心主机房的设计与建设以及苏州建行新区主机房的改建等项目。在此，就自己参与的以上项目实践经验，总结了几点在机房建设中值得注意的问题，与大家共同交流探讨。同时也希望能起到抛砖引玉的作用，愿能看到更多有价值的经验与业界的同仁分享。 一、精密空调容量规划 近年来，随着银行电算化业务量的迅猛发展和以刀片式服务器等为代表的新一代高集成度设备的大量投放到机房中运行，数据中心机房内单位面积的热负荷正日渐增大，已远非往昔，不可同日而语，如国家标准 (GB50174-93)及中国建设银行2000年分布的《计算机机房装修规范》等文件中都将200~250W/m2作为数据中心机房的制冷量标准，而实际上现在装载着刀片式服务器的机柜，负载容量超过5kW以上是很平常的事，而随着计算机和大规模集成电路技术的进一步发展，计算机设备的功率密集度将呈现越来越高的发展趋势，机房内设备功率密集度的增加势必会导致发热量也越来越高，如果我们仍按照过去有关标准所规定的200W/m2的制冷量来设计，将无法满足现今新一代数据中心机房制冷需要。 如我们苏州建行数据中心机房各种计算机设备的装机容量从2005年7月至2008年1月的两年半的时间就近翻了一番多，而且增加的多是 P550、P570以及大量的刀片式服务器等功率密度非常高的IT设备，整个装机功率已由原来的 66kVA骤增到了目前的138kVA，机房原来尚余占总面积约五分之二的空间也几乎全被新装的各种服务器、小型机所逐渐占据，原来我们的精密空调是按照 415W /m2配置的，在2005年9月机房刚启用之时，整个精密空调几乎有一倍左右的 余量，而现在每当时临夏季高温就有捉襟见肘的感觉了，盛夏来临，最担心的是邻近的两个以上精密空调模块同时发生故障，如果这样就极易造成机房局部区域制冷能力不足而导致过热的现象发生。 据了解，像这种因对机房内设备功率增加估计不足而导致机房空调制冷无法满足需求的情况是相当普遍的，如果我们在早期对机房日后负荷的增加估计不足，今后想要在已经正常运行的机房中再进行空调增容，安装新的精密空调，其难度与风险都将是非常大的，因为在负荷很大的机房中要想关掉精密空调一个甚或半个小时再施工，实际上是不太现实的事情。尤其值得注意的是新增空调当其数量众多的铜管在运行着的机房内烧焊时，稍有不慎就会因机房内运行空调出风助燃火势而引发火灾等重大事故。因此，最好的办法是能够在机房初期规划阶段就对这些问题都予以充分的考虑，放足余量。根据目前计算机设备的制冷需要并考虑到今后一段时间内的发展需求，我们认为，数据中心机房的精密空调制冷量至少应配置到每平方米700W左右，密度特别大的机房甚至还要放大。
数据中心灾备系统的分类
数据中心灾备系统的分类 根据数据中心的安全要求，应对灾难恢复系统采用的技术路线做出全面的考虑。 1.数据级容灾和应用级容灾 按照容灾系统对应用系统的保护程度可以分为数据级容灾和应用级容灾，业务级容灾的大部分内容是非IT系统。 数据级容灾系统只保证数据的完整性、可靠性和安全性，但提供实时服务的请求在灾难中会中断。应用级容灾系统能够提供不间断的应用服务，让服务请求能够透明(在灾难发生时毫无觉察)地继续运行，保证数据中心提供的服务完整、可靠、安全。因此对服务中断不太敏感的部分可以选择数据级容灾，以便节省成本，在数据级容灾的基础上构建应用级容灾系统，保证实时服务不间断运行，为用户提供更好的服务。 (1)数据级容灾。通过在异地建立一份数据复制的方式保证数据的安全性，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据。数据级容灾是容灾的基础形式，由于只需要考虑数据的复制和存放，不需要考虑备用系统，实现起来相对简单，投资也较少。数据级容灾需要考虑三方面问题:在线模式与离线模式问题;远程数据复制技术问题;同步与异步容灾问题。 (2)应用级容灾。应用级容灾能保证业务的连续性。在数据级容灾的基础上，建立备份的应用系统环境，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据和应用系统。 应用级容灾系统是建立在数据级容灾系统基础上的，同时能完成数据和应用系统环境的复制存放和管理。为实现发生灾难时的应用切换，容灾中心需要配置与工作系统同构和相同功能的业务网络、应用服务器、应用软件等。 应用级容灾还需要考虑数据复制的完全性、数据的一致性、数据的完整性、网络的通畅性、容灾切换的性能影响、应用软件的适应性改造等问题，以及为保证业务运行的所需设备、环境、人员及其相应的管理。 2.灾难恢复系统的在线/离线模式 (l)在线模式。在线灾难恢复系统要求工作系统与灾难备份系统通过网络线路连接，数据通过网络实时或定时从工作系统传输到灾难备份系统。对数据保护的实时性高，对业务连续性要求高，就需要采用在线模式。 (2)离线模式。离线灾难备份系统的数据通过存储介质(磁带、光盘等，搬运到异地保存起来实现数据的保护。离线模式适合于对数据保护的实时性要求不高的场合，离线模式设备比较简单，投资较少。 3.数据备份技术 正常情况下系统的各种应用在数据中心运行，数据存放在数据中心和灾难备份中心两地保存。当灾难发生时，使用备份数据对工作系统进行恢复或将应用切换到备份中心。灾难备份系统中数据备份技术的选择应符合数据恢复时间或系统切换时间满足业务连续性的要求。目前数据备份技术主要有如下几种: (1)磁带备份。 (2)基于应用程序的备份。通过应用程序或者中间件产品，将数据中心的数据复制到灾难备份中心。在正常情况下，数据中心的应用程序在将数据写入本地存储系统的同时将数据发送到灾难备份中心，灾难备份中心只在后台处理数据，当数据中心瘫痪时，由于灾难备份中心也存有生产数据，所以可以迅速接管业务。这种备份方式往往需要应用程序的修改，工作量比较大。另外，由应用程序本身来处理数据的复制任务，对应用系统的性能影响较大。 (3)数据库的远程数据复制。基本原理是将数据中心的数据库日志传送到远程灾难备份中心的数据库中，通过日志同步两端的数据库。这种方式需要数据库软件的支持。由于数据库方式只是传送数据库日志，与应用没有直接关系，因此无须对应用程序做大量修改。这种灾难备份方式比较适合于只对数据库有远程灾难备份需求，传输距离较长且网络传输带宽不大的用户环境。 (4)服务器逻辑卷的远程数据复制。这种方式在服务器操作系统逻辑卷管理软件基础上实现，通过IP网络将逻辑卷操作传输到异地主机，在异地主机执行同样的逻辑卷操作，保证本地和远端逻辑卷的一致性。这种灾难备份方式适合文件、数据库等多种数据的远程复制要求，并且对应用系统和数据库是透明的，但需要数据中心和灾难备份中心主机同构。 (5)基于存储备份软件实现的远程数据复制。数据的复制和同步通过存储备份软件实现，系统的灵活性很强，完全不依赖主机系统和存储系统，也不影响本地应用的响应速度，数据可以从任何存储设备上镜像到任何地点的任何存储设备上。 (6)基于智能存储设备的远程数据复制。由智能存储设备自身管理软件实现数据的远程复制，即智能存储设备将系统中的存储操作指令发送到远端的智能存储设备上，在远端智能存储设备中重做存储操作指令，实现数据远程复制。这种灾难备份方式要求数据中心和灾
数据中心布线的经验总结
数据中心布线的经验总结 数据中心布线的三大关注点 数据中心(DC)的建设者更多地会把目光放在服务器、存储等IT设备上，即使是对关注基础设施的建设者来说，供配电、制冷也会成为他们关注的主角，综合布线往往成为配角，甚至沦为“群众演员”，其结果是数据中心的“整场戏”都缺少了生命力。 大背景下的高投资回报 市场咨询公司Canalys 数据表明，2011年第三季度，全球数据中心基础设施规模达到了262亿美元，比上一季度增长了2.7%。市场分析公司 Gartner数据显示，2011年全球数据中心硬件支出达到990亿美元，同比增长12.7%，2012年预计将达1064亿美元。 这两个数据表明，数据中心市场增长强劲(虽然也有一些数据表明，全球数据中心市场增长放缓，但在“金砖国家”这一市场依然保持着快速增长，进入活跃期)，中国工程建设标准会协会信息通信专业委员会数据中心工作组于2010年～2011年就中国数据中心建设情况做过两次调查。从统计结果来看，数据中心机房面积呈现出明显增长势头，中国数据中心市场的投资比例也在不断增加。从针对用户对未来五年数据中心建设投资分析的调查结果分析可见，数据中心在未来几年的建设投资中普遍呈增长态势，基本年增长率约为5%～10%。 面对快速增长的数据中心领域，互联网数据中心和云计算已成为当前最活跃的热点。高速以太网、节能、云计算、虚拟化已经成为IT业界谈论的主角。尤其是云计算被赋予了“第三次IT产业浪潮”，更注定了其具有的强大生命力。 云计算的基础是数据中心。数据中心的建设必然会带动服务器、网络、存储等关键IT设备的发展，这些关键IT设备安全运行所需要的物理支持(如供配电、制冷、机柜、消防、布线、监控等系统)成为了数据中心关键物理基础设施。其中供配电和制冷最受建设者关注，一方面，供配电系统为数据中心内所有设备提供电力支持，合理的供配电系统设计与实施是数据中心安全可靠运行的基础，空调系统因直接和数据中心散热、气流组织相关，从而关系到节
对数据中心综合布线的一些思考
对数据中心综合布线的一些思考 摘要：根据本人近十年管理机房的经历，吸取原机房设计及建设的经验、教训，对新机房的建设，并重点就新机房的综合布线提出了自己的一些想法。 关键词：机房综合布线 一、现机房的经验教训 本单位现在使用的主机房于1995年开始建设，1997年投入使用。机房位于大楼的六层，面积有近900平米。除去办公区和辅助用房，纯机房设备区有300平米，包括放置主机、服务器的主机间，放置网络设备的网络间，放置UPS、配电柜、精密空调的配电间。 机房设计采用上吊顶、下送风、下走线方式。当时建设了一个样板工程的机房，曾有包括国家级领导人在内的各级领导、同行近百人次参观、访问。 但在十几年的运行中也发现存在很多问题，主要有以下几点： 1、当时建设时主要是近十台小型机、很少量的立式服务器。现在是以机架式高性能服务器为主，有近20个机柜，100多台服务器。UPS负载逐渐不够，于2003年由2台30KFA 的更换为2台60KFA，但现在单台负载也已接近50%。 2、设备的大量增加，使精密空调制冷无法满足需要，原2台40KW的精密空调，于2006年更换为3台35KW的精密空调，并且将2台空调直接安放在主机间。但现在夏季机房温度仍高过标准。 3、机房综合布线采用下走线方式，虽布设了走线槽，但随着设备的增加，很多线已无法由线槽容纳，而且强、弱电都是下走线，走线混乱。并由于线缆过多，对空调下送风的效果影响愈发明显。 4、由于建筑设计原因，吊顶上有水管走设，地板下高度只有20CM，并且由于强、弱电都是下走线，使制冷效果大打折扣。 5、由于当年综合布线设计的前瞻性不够，造成现在机架背面线缆密密麻麻没有秩序，地板下的线缆一片狼藉，给管理、散热等都带来问题。 做为多年管理机房的负责人，由于办公楼搬迁，我又做为新大楼机房的建设负责人，希望尽力吸取已有的经验、教训，利用这些年来在机房建设、管理上出现的新理念、新技术，建设一个满意的机房。 二、准备建设的新机房情况 随着国内口岸经济的发展，为更好服务于企业，服务于地方经济。本单位办公楼准备采用置换方式由市区搬迁到开发区。新办公楼由地方政府提供，是一个未完工的星级酒店，主体建筑完成后一直停工多年，大楼所有装修由本单位负责。 原大楼是10年前所建，层高29层，设计为酒店，未考虑建设机房。经过研究，现已确定大楼的6楼做为本单位中心机房。机房总面积是900平方米，是一个标准的正方形，楼房中间电梯、消防楼梯、通道等占去300平左右。层高不理想，净高3.1米，梁下高度为2.55米。楼板需要按机房标准加固。 新机房准备2008年年底开始进行建设，2009年年底搬迁。 三、对新机房建设的设想 虽然提供的场地不是很理想，但做为一个多年进行机房管理的技术人员，接受了新机房建设的任务后，仍然有决心建设一个满意的机房。
数据中心机房运维方案
数据中心运维外包 服 务 方 案 2019年8月
数据中心运维外包服务方案 目录 一、运维的重要性 (1) 二、维护范围 (1) 三、提供的服务 (2) 四、服务内容 (3) （一）UPS供配电系统 (3) （二）机房空调系统 (5) （三）服务器运维 (7) （四）存储系统运维 (9) （五）虚拟化平台运维 (10) （六）数据库系统运维 (11) （七）网络设备运维 (13) （八）其它有关系统或设备运维 (15) 五、运维报价服务 (16)
一、运维的重要性 数据中心的日常运维工作是至关重要的。设备故障时，应提供快速的备件供应、技术支持、故障处理等服务。通过机房设备维护保养可以提高设备的使用寿命，降低设备出现故障的概率，避免重特大事故发生，避免不必要的经济损失。 数据中心的运维工作专业性很强，通过引入专业的维护公司进行日常运维工作。建设及使用单位相关管理人员可从日常需要完成专业性很强的维护保养工作中解放出来，重点做好管理及协调工作，更好的发挥信息或科技部门的其它职能。 通过专业、系统、全面的维护可以提前发现问题，并解决问题。将故障消灭在萌芽状态，提高系统的安全性，做到为客户排忧解难，减少客户人力、物力投入的成本，为机房内各系统及设备的正常运行提供安全保障。可延迟客户设备的淘汰时间，使可用价值最大化。通过专业的维护，将数据中心机房内各类设备的运行数据进行整理，进行数据分析，给客户的机房基础设施建设、管理和投入提供依据。 二、维护范围 数据中心机房于××年×月建成并投入使用，数据中心有关设备及基础系统清单如下：
三、提供的服务 为更好的服务好客户，确实按质按量的对设备进行维护；我公司根据国家相关标准及厂商维护标准，结合自身经验积累和客户需求，制定以下服务内容： 1.我公司在本地储备相应设备的备品备件，确保在系统出现故障时，及时免费更换新的器件，保障设备使用安全。 2.我公司和客户建立24小时联络机制，同时指定一名负责人与使用方保持沟通，确保7*24小时都可靠联系到工程技术人员，所有节日都照此标准执行。 3.快速进行故障抢修：故障服务响应时间不多于30分钟，2小时内至少2人携带相关工具、仪器到达故障现场现行故障排查处理，直到设备恢复正常运行。 4.我公司对维修维护的设施设备的使用性能负责，在维修维护过程中严格执行技术规范，保证设施设备的性能符合相关技术标准要求。在维修维护间，我方应对设施设备可能存在的故障隐患做出评估，并进行恰当的预防性处理，以保证设施设备的安全运行。若故障隐患超出维修维护范围的，及时书面通知客户，并提出消除隐患建议。 5.维护巡检中我公司提供设备系统图或使用说明书：将机房内设备的整个系统等汇编成资料，由维护人员进行统一放置，便于应急查询。 6.巡检次数每年不少于四次，每次巡检后，由维修维护方提供巡检报告，并由使用方签字确认。每月由我公司客户服务人员定期进行回访，听取客户意见反馈，搭建起双方的沟通渠道。 7.提供系统应急方案：设备在12小时内还无法修复的应有备份应急处理方案。如提供适合负载功率的备机、备用空调等。 8.培训：提供专业理论知识培训和操作培训，维修维护培训，简单故障处理培训，培训文档由我公司整理。 9.人员配置：全年（包括所有的节假日期间）提供不少于2名工程师在常住贵阳本地，确保满足响应时间要求；到现场的维护维修工程师至少一名是能完全解决故障并有丰富从业经验的。 10.我公司每次巡检完毕后提供维护报告，同时还提供全年维护报告、每次维修事故报告等资料，根据事故提出相应的整体解决方案等管理规划层面的内容。
数据中心运维操作标准及流程
数据中心运维操作标准及流程 郑州向心力通信技术股份有限公司 二零一八年
1 机房运维管理前期准备 1.1 管理目标 机房基础设施运维团队应与业主管理层、IT部门、相关业务部门共同讨论确定运维管理目标。制定目标时，应综合考虑机房所支持的应用的可用性要求、机房基础设施设施的等级、容量等因素。目标宜包括可用性目标、能效目标、可以用服务等级协议（SLA）的形式呈现。不同应用的可用性目标的机房，可设定不同等级的机房基础设施的运维管理目标。 1.2 参与数据中心建设过程 机房运维团队应充分了解自己将要管理的场地基础设施。对于新建机房，应尽早参与机房基础设施的建设过程，以便将运维阶段的需求在规划、设计、建造、安装和调试等过程中得到充分的考虑；同时为后期做好运维工作打下基础。 1.2.1 应参与规划设计 机房的规划设计是一个谨慎和严谨的过程，需要所有参与机房建设的相关方共同完成，才能确保规划和设计的有效性、实用性等要求。其中，基础设施运维团队应提出运维要求，从运维经验、实际运维难度、提高运维可易性等方面对规划和设计过程进行配合。 1.2.2 应参与相关供应商遴选 机房基础设施运维团队应参与机房基础设施设备供应商选择的全过程，及时地了解各种产品及服务的品牌、型号、规格等关键参数，使之更能满足运维的要求。并就在安装、调试过程中的注意事项等提
出建议，还需要对后续的设备保修等服务提出要求。 1.2.3 应参与建造管理 机房的基础设施运维团队应积极参与机房基础设施的建造工作，并协助做好建设项目的项目管理工作，着重关注工程建造中如材料的使用、工序、建造过程等工作，重点关注隐蔽工程的安装工艺和质量。 机房基础设施运维团队应充分了解施工过程中的工艺。对于新建数据中心，从施工质量和日后运维方便性出发，尽早发现施工过程的问题，及时纠正，方便日后运维和节省日后整改成本。 1.3 测试验证 机房基础设施投产前的测试验证是确保机房基础设施满足设计要求和运行要求的关键环节。 1.3.1 时间和预算 机房的业主应设立测试验证专项预算，预算应包括外部测试验证服务提供商的相关费用，以及在测试验证阶段产生的电费、水费、油费等相关费用。应制定测试验证的工期规划，以更准确地预测机房基础设施交付投产的日期。 1.3.2 测试验证参与方 项目建设管理部门可作为测试验证工作的主体责任单位；运维管理部门可作为测试验证工作的主体审核单位；第三方测试服务商可作为测试验证的实施单位及整体组织工作的协调单位。但运维管理部门应要求测试服务商预先提供测试方案，在运维管理部门审核后方可进行。机房基础设施运维团队可参与测试验证工作，在此过程中熟悉设
数据中心设计过程详解
数据中心设计过程详解 艺术的唯美和技术的务实，似乎有着天然的距离。但当我们回顾很多技术的发展历程，就会发现，在那些取得了巅峰成就的地方，总是技术与艺术的完美结合。今天我们就一起深入了解最新的IDC机房基础设施的设计和搭建——只要用心，技术离艺术并不遥远…… 历史回顾 过去十年中，IDC机房的规模多为300-500平米，一般设在办公楼内，其建设多以应用为中心，靠应用来拉动。 现实需求和挑战 IDC机房建设发展到现在，为加强IDC机房的管理，提高其效率，安全性和可靠性，大型、超大型IDC机房的建设需求逐渐增多。而过去IDC机房的设计、建设模式已经不再适应这种发展需求了。 目前，大型IDC机房建设面临的主要挑战有： 1：设计标准落后，基础研究空白，缺乏统计数据。 国内的相关设计，建设标准是93年的，和现实需求相比过于陈旧，最新的规范尚在推广当中。用于指导电信行业的TIA-942规范并不一定对所有用户适用。 2：IDC机房所要支持的业务系统的要求，企业IT架构设计与具体的基础设施设计严重脱节。 3：设计、建造过多依靠经验，缺乏科学的方法和工具。 现有机房工程公司已难以支持，而国内的专业建筑设计院过去很少接触IDC机房设计。 4：技术经济指标，节能措施缺乏计算和考虑，效率低下。 5：缺乏专业的工程管理。 6：设计、建设、运维各个阶段脱节。 IDC机房是专业性很强的工业建筑，运维方式直接对建筑设计提出要求，而运维方式又是由IDC机房所承载的业务类型，模式所决定的，所以各个环节要全面规划。 设计IDC机房时需完全遵守现有国家标准，并广泛参考国际标准，最佳实践经验以及Gartner Infrastructure Maturity Mode。 现在企业做IDC机房建设大部分都处于集中式阶段，部分企业由集中式向标准化走。长远上看，IDC机房基本上要往基于服务，虚拟化方向发展。