作者：赵旻
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
IT基础架构：系统运维实践试读：
前言
2015年，国务院政府工作报告中提出制定“互联网+”的行动计划。在这个大背景时代的推动下，越来越多的传统行业面临着与云计算、大数据等热门技术相结合的发展趋势。在漫长的转型过程中，传统企业的IT部门面临着基础架构变革的严峻考验，运维团队不可避免地遇到了很多棘手的难题。例如，管理模式如何由集中式向分布式转型，小型机到x86的演变，海量运维模式的挑战，以及知识结构与运维思路的转变，等等。这些都是目前传统行业IT部门领导者所面临的主要问题。
随着电商的流行，也有很多非IT领域的成功企业正在酝酿着自己的O2O市场，希望借助互联网完成第二次创业。他们遇到的最大问题就是——对互联网的认知完全是一片空白。要实现从无到有的原始积累，会有很多挑战在等着他们。
为什么要写这本书
基于上述这些问题，我们策划了这套IT基础架构丛书。作为这个系列的第一部作品，我个人的压力还是蛮大的。当机械工业出版社华章公司的高婧雅编辑和我约稿时，自己竟然一时有些不知所措。算起来，我从事系统运维的工作已满十个秋冬。说来惭愧，我觉得自己并没有什么拿得出手的成绩。不论是实践还是基础，市面上这方面的书已经非常多了。那么，以什么作为出发点是合适的呢？最终，我还是[1]从《运维前线》这本书中获得了启发。2017年3月，由云技术社区创始人肖力发起并策划的《运维前线》成功出版，让我感受到了同行们乐于分享的热情，同时也看到了广大读者对实用、落地的技术方案的渴求与肯定。于是，我产生了一个新的想法：在《运维前线》主打实用的基础之上，围绕着我所擅长的系统运维方向，写一部《运维前线》的“系统版”。
本书特色
不管怎么说，技术是一个很枯燥的东西。我自己在学习的过程中也深有体会。拗口的描述、复杂的逻辑是很多技术文档的通病。也许这样的表达形式是严谨的，但它并不“亲民”。我认为，一本好书不但要有深度，更要带领读者一同到达才行。这个深度就像西游记中的水帘洞，如果只有你自己进去了，却把读者晾在一边，那真是太糟糕了。如果一本书洋洋洒洒几十万字，读者看完后没有任何收获，那我宁愿不去写它。因此，打比方和举例子是我在全书中用得最多的写作手法。通俗易懂，是我在技术分享时所秉持的一贯态度。我希望消除掉一切阻碍的门槛，让每一位读者朋友都能够从本书中获得些许的帮助。
选择撰写本书是有着特别的意义的。既然是实践，我们首先要保证技术的实用性。但从定位上讲，它又不同于以往的实践类书籍。书中讲述的所有内容都是笔者正在或者曾经使用过的，并将一些经验和观点融在其中。写这本书，也算是对我多年工作经验的一种总结，了却自己的一桩心愿吧。
读者对象
说到这本书的定位，我想它对绝大多数从事系统运维的工作者都是有益的。本书需要一点点Linux和网络的基础知识作为铺垫，除此之外再无其他要求。对于工作3～5年的朋友们，我知道你们已经厌倦了基本的系统管理，但你们也许有点儿迷茫，不知道下一步该如何进阶。对于那些传统行业面临IT基础架构转型的系统运维团队，你们可能在系统管理方面经验丰富，但是对大规模、分布式x86平台的系统运维却感到陌生。还有那些刚刚到创业公司的“中生代”技术人，你们可能在工作中会遇到更多新的挑战。我想，选择这本书对你们来说是再适合不过的了。当然，如果你早已是这方面的行家里手，也不妨来读读本书。我的一些经验也许能帮到你，我的一些经历也许能让你感同身受，我的一些观点也许能让你会心一笑，只当是我与你之间的一次未曾谋面的技术交流好了。
如何阅读本书
本书从内容上大致分为六大部分，共计16章内容。
第一部分（第1章），笔者对心中的IT基础架构标准、本书的写作初衷和特点等做了阐述。
第二部分是数据中心篇（第2～5章）。这是一个综合了数据中心、网络、系统等众多技术领域的主题。我作为一个经历过创业公司的老员工，对此深有体会。从无到有，我亲手规划、建设了多个同城的数据中心，后续又和两位牛人学习了很多相关的知识。该篇也许真的非常跨界，我想在所有讲解系统技术的书籍里，难有雷同之作。作为一名真正的SE，只懂操作系统是不合格的。所以，我认为这个跨界还是值得的。
第三部分是管理流程篇（第6章）。这是一个特殊的篇章，因为它特殊到只有一章。如果能够进一步展开，这个主题其实完全可以独立成书。管理流程是基础架构中最为重要的核心组件。我想没有人会反驳这个观点，除非他所运维的节点数量还不够多。
第四部分是基础服务篇（第7～11章）。本篇内容基于多机房和海量节点，介绍了如何去构建DNS、NTP、文件共享、配置管理等一整套服务的方法。
第五部分是系统运维篇（第12～15章）。这部分内容主要和日常运维管理的工作相关。例如，硬件故障处理与维修、安全、性能校准、Shell程序等。如果要做推荐，我会更倾向于数字证书那一章。因为那是我刚入行时的专业方向，和数字证书打了这么多年的交道，写这一篇时也算是一种情怀吧。
第六部分（第16章），这部分介绍系统运维工程师应该具备的素养，以及如何提升自己等内容。
此外，这本书中还有13个有趣的运维小故事。它们很像登山时的休息点，如果你读累了，可以在这里歇歇脚，喘口气。其实，故事里面也蕴藏着很多收获呢。
不过，这还不是本书全部的内容。既然我受到了《运维前线》的启发，为了表示敬意，我也继承了《运维前线》一书的设计形式。最后一章，藏着一个有趣的彩蛋，等待着读者朋友们去发现。好了，我想我说得已经够多的了，我们在书中相见吧。
勘误和支持
由于笔者的水平有限，编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。如有任何反馈与想法，请你发送电子邮件到itarch@qq.com。真诚地期待能够得到你的反馈，在技术之路上互勉共进。
致谢
在写作这本书时，我得到了很多朋友的帮助。例如我的同事——张望和徐铁军两位大牛。张望是网络方面的专家，铁军则有着多年的IDC管理经验。撰写数据中心篇章时，关于一些技术问题的求证，两位给予了我很多的支持与帮助。能和你们在一起工作真好，谢谢两位。
感谢云技术社区的北极熊，熊总在各大社区中不遗余力地帮忙推广本书，做了很多无私的工作。感谢我的那些新老朋友们，在我成书之时，他们帮我撰写书评，给了我很多的鼓励与支持。谢谢你们的帮助与肯定。
此外，在这里我还要特别感谢两位老师。一位是云技术社区的肖力，另一位是机械工业出版社华章公司的高婧雅老师。两位老师是指引我走上写作道路的领航人，虽然都只有一面之缘，但他们却给我提供了很多的帮助和支持。2015年，我加入了力哥发起的《运维前线》的写作团队。也正是通过这次写作得到了婧雅编辑的肯定，进而才有了这部书稿的成文。力哥在百忙之中亲自为我作序，婧雅为我的写作提供了很多有价值的指导意见。可以说，没有两位就没有这部书的出版。谢谢所有支持我、关心我、帮助我的朋友们，感激之情溢于言表，谢谢大家！
谨以此书献给广大热爱技术的朋友们！赵旻
[1] 已由机械工业出版社出版，书号978-7-111-55697-8。—编者注第1章混沌初开
混沌未分天地乱，茫茫渺渺无人见。
自从盘古破鸿蒙，开辟从兹清浊辨。
在这里，首先要感谢你能选择这本书。我已经很多年没有动过笔了。自打高考结束之后，我就很少再有机会爬格子了。这一切还是托了肖力兄的福。通过《运维前线》这部书，我结识了很多同行好友。也承蒙力哥和机械工业出版社华章分社的高婧雅编辑的鼓励与错爱，再一次燃起了我的写作热情。1.1 我眼中的基础架构
相传战国时期，魏国的国君魏文侯外出巡游，在路上遇到了一个反穿裘皮大衣的人。魏文侯觉得很奇怪，向那人问道：“你为何要将衣服的毛穿在里头，却把皮板露在外面呢？”那人回答说：“这件裘皮大衣很贵，我怕损伤了毛，所以才这样穿的。”魏文侯大笑：“难道你不知道，要是这皮板磨破了，毛也就保不住了吗？”
古人云：“兵马未动，粮草先行。”没有必要质疑基础架构的重要性。2015年至2017年可以称得上是互联网界的“三年灾害时期”。重大事故频发，很多知名企业先后“中枪”，在业内引发了很大反响。其中大多数故障与基础架构有关，从这些事件上折射出了很多问题——我们对基础架构的重视和投入是不足的。
其实“平日不烧香”倒也没什么关系，只要事后你能平心静气地承受所有的损失，不要哭天抢地、痛心疾首就好。这和买保险是一样的，投100万元还是100元，完全由你决定。但有一点我能肯定，你觉得你的基础架构值多少钱，你就会去投入多少。
做基础架构，我认为有三点非常重要——可靠、简单和高效。
1.可靠
可靠是毫无疑问的。如果底层不扎实，上面再花哨也没有用。不少企业在建设初期，为了抢占市场、追赶进度，相对于产品开发，基础设施的建设往往滞后得非常厉害。我在本书的第6章，特别强调了基础架构中的两大基石——CMDB和Workflow的重要性。试想如果没有CMDB，你的信息从哪里来？没有规范的Workflow，如何确保信息的准确性？把精力放在基础架构的建设上，要比盲目求高、求快有意义得多。
可靠性不仅仅体现在软件架构上，基础设施的可靠性同样重要。基础设施在可靠性上栽跟头的主要原因就是钱。财务、采购和技术部门经常在成本价格上发生冲突。一边要节约成本，一边要提升服务等级，每个部门都在追求自己的价值体现。部门的话语权就决定了你是否会掉进低价陷阱之中。廉价、免费是世界上最昂贵的商品。看似便宜的东西，买回来就会大呼上当。不是品质打折扣，就是后期产生无尽的费用增项。这种“抠小钱、舍大钱”的做法是非常不值的。
2.简单
简单是支撑规模增长、消除扩容瓶颈的基础要件。架构的复杂度和今后发生事故的严重程度是成正比的。底层架构的逻辑越复杂，出问题以后牵扯的东西就越多。真是因果循环、报应不爽啊。
不同的体量，架构的实现模式会有不同。因而随着规模的增长，你的架构会不自觉地增加复杂度。这是不可避免的，所以架构师要不断地为新架构减负和解耦。在削减赘肉的过程中，我们要消灭基础架构身上的三座大山。
第一，要消灭异构形式。不论是通信协议、接口规范抑或实现方式，最忌讳的事情就是大家各玩儿各的。你做一个标准，我做一个标准，每接入一个新的子系统，就要产生很多兼容性问题，最后还不是要花大力气去融合么？
第二，要消灭重复组件。底层功能的实现在业界大多有成熟的解决方案，应当尽可能地去复用或者在此基础上进行改进，而不是重复造轮子。研发精力要更多地放在业务场景的适用性上。
第三，要消灭紧耦合关系。解耦工作要从不同的角度入手，子系统和模块的紧耦合因素是不同的。
实现系统间的解耦要让架构扁平化，消灭冗余的层级。垂直层面上的内容越多，就越容易出问题。如果执行一项任务要历经十个系统。一旦任务失败，这十个系统都脱不了干系。另外，在需求迭代的过程中，每增加一个需求项，不论你所负责的系统是否需要修改，在任务没有明确之前，这十个系统的开发人员都得参与讨论。不断地开会，不断地沟通，你想这些成本代价得有多大？
实现模块间的解耦要明确职权界限。调度模块只负责调度，部署模块只负责部署。假使调度模块在调度过程中发现，环境的初始化工作没做好（例如缺少某个配置文件），那么它应当给部署模块返回错误消息，而不能让调度模块去做拉取文件的动作。如果开发任务指派了多个人去完成，则这种问题就很容易发生。等于两个模块里面都有部署的动作，它们之间的界限就模糊了，从而出现多头管理的问题。
解耦的核心是拆除过度的依赖关系，让暴露给外部的细节最小化，形成“高内聚、低耦合”的最优状态。
3.高效
团队工作的特点是人多省力、人少省心。当一件工作从一个人干变成十个人干时，你会发现信息来源的权威性、信息同步的实时性和操作指导的规范性有多重要。当运维团队增长到一定规模的时候，效率反而会有所下降。因为工作被进一步拆分了，在缓解压力的同时，相互之间的衔接环节却增多了，沟通成本以及利益冲突的负效应也会在这个时期显著放大。
影响效率的主要因素来自于CMDB和Workflow模型的成熟度。具体细节我们就不在这里过多讨论了。总而言之，基础架构做不好，整个团队的管理是一片混乱，执行效率低下，成员怨声载道。俗话讲：磨刀不误砍柴工。把精力多放在基础架构的建设上是绝对不会吃亏的。1.2 写一本怎样的书
在策划这部书的时候，我受到了《运维前线》的很多启发。2015年，我有幸加入了首部《运维前线》的写作团队。从《运维前线》的创作到出版，不仅让我感受到了同行们乐于分享的热情，同时也看到了广大读者对于实用、落地的技术方案的渴求与肯定。于是我有了一个新的想法：能否在《运维前线》主打实用的基础之上，再让它更加系统、丰富一些呢？
选择撰写这部《IT基础架构：系统运维实践》是有着特别的意义的。在定位上，它不同于以往的实践类书籍。当然，既然是“系统运维实践”，我们首先要保证技术的实用性，必须回归到具体操作的实例讲解中来。什么是实践？我想绝对不是在虚拟机上呈现一个实验结果那么简单。如果只是这样，你完全可以在互联网上找到很多类似的文档，这不是我想要的。真正的实践，一定要是你亲身用过的东西，有宝贵的经验之谈在里面。我们从来就不缺少安装文档，读者需要的是——站在架构层面上的技术应用指南。这，才是我写作的初衷。
当然，基础架构这个题目很大，绝非我一人之力所能承担，所以我并非一个人在战斗。我希望能沿用《运维前线》的众筹创作模式，汇聚业内众多专家，总结他们多年的工作经验，从而形成一套通用的解决方案模型，使之可以应用于大部分的场景。也就是说，作为抛砖引玉之作，本书只是“IT基础架构”系列丛书的第一部。我们正在邀请更多的作者加入到这个项目当中。我相信这是善举，愿这套“IT基础架构”丛书能成为真正落地的解决方案。就像马云所说的，让技术为大众去服务，而不是成为牟取暴利和树立壁垒的手段。1.2.1 英文书的伤痛
有很多人曾经都问过我，学习Linux应该看些什么书。我的建议是，最好先去读Redhat OD（官方文档）。它的权威性是不言而喻的。阅读OD时，你的心里是踏实的。尤其是到达一定技术深度的时候，知识来源的可靠性非常重要。不过很多朋友表示看OD有难度，主要是英文不过关，这一点我也是感同身受。
翻译专业文档的确是一件极其辛苦的工作，要做到“信、达、雅”谈何容易？一方面我们对于专业词汇的理解不到位。另一方面，外国人的某些表达方式与我们不同。明明很简单的道理，偏要花几大段英文来解释。而拆解成两三个短句能说清楚的事情，却非得用一个超长从句来表达，还有各种which与it的不明指代。这让我深感英文依旧是我们技术进步的最大障碍。
在讲解一些来源于英文文献的内容时，为了弄清楚各种专业词汇，我翻阅了大量的资料。例如，在时间同步这一章中，像slew、smear这类单词，即便你知道它们的原意，也未必就能很好地将其代入实际语境当中。而且就算翻译到位了，读者对专业词汇的理解也是吃力的。在充分理解原句含义的同时，再用浅显易懂的语言描述出来，我在这方面也着实是费了一番工夫的。1.2.2 有话直说——这就是我的忍道
我中学时代的一位语文老师在给我们讲写作时，曾举过一个特别生动的例子。当时中学作文的字数限制是八百字。她说，文章开篇一定要平铺直叙，快速切入主题，字数不要超过一百。写作文就像打仗，这八百个字就是打仗时你率领的士兵。有些同学写作文开篇太啰唆，一冲锋都死伤一百多个兵了，结果还不知道你要说的是啥呢。
事实上，我自己也特别痛恨这种说话兜圈子的方式。如果一部书洋洋洒洒几十万字，读者看完后没有任何收获，那我宁愿不去写它。我不能变成自己所讨厌的那种人。现在大家提倡讲干货，就是因为有些技术分享已经开始变味儿了。举几个例子，我想大家一定都有同感。（1）白皮书式的分享
白皮书式的分享就像是一个销售在推销，全程围绕着一张架构图，依次介绍里面每一个模块的名字和作用，最后展示一张效果图。分享结束后，听众发现自己和这个产品完全没有任何交集。其实，大家并不关心这些模块叫什么，做什么用。我们真正感兴趣的是，整个系统的工作流程是怎样实现的，模块之间是如何协同工作的，在实现过程中遇到了什么问题，又是如何解决的，这套系统适用于哪些场景，在什么时候会遇到瓶颈，这个模式我们能复用么？然而，这些问题都没有给出答案。（2）炫富型的分享
我觉得这种分享根本就是来“拉仇恨”的。巴拉巴拉讲了一个特别牛的产品，最后话锋一转，说这是我们团队自主研发的。言外之意就是——你们用不了！（3）表演型的分享
技术分享的目的是让大家获益，而不是用来突显你有多高明。有些分享特别热衷于过度包装，非要把简单的东西往复杂里说，刻意地堆砌各种术语以及模型公式，却又不做任何解释。这种做法完全不顾群众的接受能力，似乎一开始就没打算让你弄明白。
从上述这几个问题来看，我认为分享人的内心并不是真正开放的。写书也是一样的道理，读者并不是傻子，你自己内心的拧巴与纠结，大家看得很清楚。
如果非要下一个定义，我认为《IT基础架构：系统运维实践》是一部抽象化的实践类手册。这里面既有模型和方法，也有案例和步骤。作为抽象化的架构设计，我会交代清楚它的原理、构想以及我们为什么要这样做。作为具体的事例，我要确保它是切实可行的。读者完全可以复用到大多数场景中去，因为它们都是笔者曾经或者正在使用的技术方案。
一部书有没有价值，并不在于技术的深浅，而在于作者的诚意——有没有分享干货的意愿。我愿意尽我所能去帮助任何有需要的朋友，相信这是一部脚踏实地、有一说一的书。有话直说，这就是我的忍道。1.2.3 当行家说人话
我入行是从信息安全做起的，那时我在政府行业中做了很多国家级项目。其中某部委的一位领导，给我留下了很深的印象。有一次，我们的项目经理提交了一份文档，被她给打回来了。她让项目经理当场高声朗读这份文档。这一读不要紧，项目经理自己也觉出来了，文中语病甚多。这位领导斥责道：如果你写的文档连你自己都读不明白，怎么好意思拿给别人去看？
这件事对我的影响很深。程序员写完代码要自测，作者写完文章要自读。而且一定要念出声儿来，这一点很重要。朗读能够从心态上清空自我意识，从一个读者的角度去读自己的文章，你是不是真的能读懂你所说的话呢？
当行家、说人话，是我这次秉承的写作态度。为了避免出现“看不懂、读不通、想不明、理不清”的情况，这一部长达30万字的书，我至少写了50万字的内容。即便是这样的一个开篇，我反反复复地也删改了很多次。有时我真的很痛苦，利用通宵及周末加班写出的大段文字，最后很多都被自己删掉了。忙了几天，却发现Word的字数统计几乎没有变化。我不是职业作家，交稿的时间也很仓促，要说没有压力是骗人的。其实在临近截稿前，我感觉自己就像是一个高考结束铃响时还在奋笔疾书的考生，很想能有更多的时间来细细打磨全书。因为我希望这部书的内容能更加完善，有些呆板干涩的地方，也许还可以将它润色得更好一些。此外，我也担心因为自己的一时疏忽或者知识上的空白，而给本书留下一些错误。读者朋友们，如果你在阅读的过程中发现了任何问题或疑问，欢迎你提出批评和建议，我将在下一版中进行改进。如有任何反馈与想法，请发送电子邮件到itarch@qq.com。再次向你表示感谢。1.3 本书声明
在拟定本书目录之时，高婧雅编辑曾经给我提过一些建议，她希望本书能够有一些实际案例的讲解。我原本就有培训的工作经验，而举例子和打比方又是我喜欢的讲述风格，所以列举案例对我来说不是问题。但我又有点儿为难，案例中难免会有些反面典型。但做运维的人，谁没开过故障分析会？谁没犯过错误？案例分析不是要针对谁，而是为了达到总结经验、吸取教训、警醒后人的目的。在此我郑重声明，本书列举案例所涉及的公司和人名均为虚构，一切只为说明问题，请勿对号入座哦。你要是较真儿，那我就只能说清者自清了。还是那句老话，本书故事纯属虚构，如有雷同，实属巧合。
在撰写本书时，笔者参考了很多非常有价值的资料。有些源于Red Hat的官方文档或软件的用户手册，一些名词解释和介绍性的内容来自互联网，还有一部分摘录自笔者已经发表在《运维前线》上的文章。
除此之外，在撰写本书的第8、10和14章时，笔者还参考并借鉴了如下书籍中的部分内容。在此，我对这些书籍的作者们深表敬意。
[1] Cricket Liu，Paul Albitz.DNS and BIND[M].5版.纽约：O扲eilly Media，2009.
[2] 克鲁姆，等.精通Puppet配置管理工具[M].李超，译.2版.北京：人民邮电出版社，2014.
[3] 李松涛，魏巍，甘捷.Ansible权威指南[M].北京：机械工业出版社，2016.
[4] Joseph Hall.精通SaltStack[M].姚炫伟，译.北京：电子工业出版社，2016.
[5] 莫尔勒.深入Linux内核架构[M].郭旭，译.北京：人民邮电出版社，2016.
[6] Redhat，Inc.RedHat.System Monitoring and Performance Tuning：RH442[EB/OL].https://www.red-hat.com/en/services/training/rh442-red-hat-enterprise-performance-tuning.第2章如何选择优质的数据中心
信息化是当今世界经济和社会发展的大趋势。谁能够掌握更多、更准确、更及时的信息数据，谁就能在这个时代的发展大潮中占据主动与先机。毫不夸张地讲，对信息数据的有效掌控，将成为企业的核心竞争力。
对于小微企业和个人创业者而言，租用公有云是个不错的选择。尤其是那些非IT企业，租用公有云可以免除日常维护的烦恼。然而，随着企业规模的不断壮大与数据量的急剧增长，公有云的弊端就会逐步显露出来。
第一，业务增长导致存储和计算节点的需求激增，成本价格会成为扩容的最大障碍。
第二，公有云数据托管的安全问题一直备受争议。作为命脉的核心数据，又岂能轻易地托付于人？
因此，公有云的应用是有很大局限性的。
在“互联网+”这个大趋势之下，IT基础架构也面临着变革的考验，以x86平台为代表的大规模集群、分布式的架构必将成为主流。因此，建设一个高可靠、大容量的数据中心的必要性就不言而喻了。2.1 概述
数据中心的建设有两种方式。
第一种是采取机房自建的方式，它的优势在于满足定制化需求和后期的成本控制。但是，对于大多数企业来说，机房自建是一个相当复杂而庞大的工程。光国家标准规范就有上百部之多，需要很多专业人员参与，而且初期投资巨大，没有一定的规模，自建是得不偿失的。
还有另外一种切实可行的方式：选择一家优质可靠的数据中心，把自己的设备托管给服务商，这种方案是大多数企业的首选。不过，我们在数据中心的选择上可能没有做足功课，因为选择了一家不靠谱的运营服务商，导致业务中断、数据丢失的案例也不止一两起。
对于数据中心存在认识上的误区，我想这是问题的主要原因。大家可能总是觉得，机房工作不就是上架、布线嘛，很简单啊。那不过是日常工作而已。数据中心的建设和维护其实是一门涉猎非常广泛的学问，涵盖了地理学、建筑学、工程预算、管理学等诸多内容。想成为这个行业的佼佼者，只有技术是不够的，至少要在以下三个方面有所成就。
·专业知识——专业知识过硬是最基本的要求。
·行业情报——如果一个人深谙行业内的来龙去脉，而且总是能够第一时间了解到最新的相关消息，那么他的价值远非单纯的技术专家可比。
·人脉关系——关系的重要性自不必解释。深厚的人脉关系往往能趟平很多看似困难重重的坎儿。运维故事1：水火相容
Forever和Never是两家互为竞争对手的公司。Forever公司IT部的架构师老Z跳槽去了Never，正赶上Never正在筹划新的三地多机房数据中心，为了一显身手，老Z把Forever已经完全成熟的网络架构方案直接照搬给了自己的老板。这个架构的骨干网涉及一个问题：需要两家大型电信供应商Conflagration（火灾）和Flood（洪水）之间的链路完成互通。光看名字，就能明白这两家是世仇，可见想要实现竞争对手之间的链路互通谈何容易？老板甚至都有点儿怀疑当初聘请老Z这件事是不是有点儿不太靠谱儿。老Z自己觉得很委屈，以前在Forever的时候明明就是很容易实现的啊？他百思不得其解，于是只能给原来的老同事——Forever公司负责数据中心的经理老D打了通电话。
在听完老D洋洋得意的一番解释之后，他这才明白其中的缘由。原来老D可不只是个搞技术的，人家在IDC行业摸爬滚打了20多年，除了技术水平高，更重要的是对这里的市场行情和人脉关系门儿清。Conflagration的老总和老D早先是老同学，俩人私人关系一直不错，而Flood的高层和老D是多年的好哥们儿。所以，这趟活儿人家是托了人情的，能顺利促成也无非都是冲着老D的面子，而非像老Z那种想当然。当然，按照老D的话讲，他为了这个项目，也是把这些年积攒的人情面子一次性地全给用光了，要不是老板再三保证能给自己升职加薪，他才不会这般自讨苦吃呢。
既然数据中心如此重要，那么如何选择一家优质的数据中心呢？大家也许会说，那还不简单，找一家口碑好的不就行了？要不，就招一个数据中心专家来解决。我们是做系统运维的，这和我们又有什么关系呢？
其实，在开始写作之前，我还和高婧雅编辑就这个问题多次探讨过。系统运维扯上数据中心会不会偏离了主题呢？会不会让读者觉得枯燥呢？但是当我真正地完成了这章内容的写作时，我已经对此有了足够的信心。
从数据中心的角度讲，藤上的甜葡萄早就被人摘光了。好的数据中心有可能因为用户众多，在容量上无法满足你的需求。另外，数据中心也不是简单看看评级和口碑就能够下结论的，同级别的数据中心之间也会有很多差异。
从人的角度讲，请一位资深专家在成本预算上是比较高的，大多数情况下，这项工作可能是以兼职的形式出现的。而数据中心又是一门广泛而复杂的学问，真要去系统地学习，恐怕短时间内难以有所作为。
实话实说，我并不是数据中心方面的专家，连专业都谈不上，所以我不打算把文章写得过于理论化。相反，我会用一些浅显易懂、轻松愉快的方式来讲述。2.2 空间环境评估
从本质上讲，数据中心也是一栋建筑物。就和我们买房一样，在地理位置和房屋结构的挑选上，也需要仔细斟酌。数据中心的选址工作非常重要，地理位置决定了数据中心的安全性以及工作的便利性，而牢固的建筑结构、合理的空间布局同样非常关键。
2015年8月12日，天津港发生了特大爆炸事件。爆炸同时引发了周边地区多起火灾及二次爆炸事故，方圆数公里都有强烈震感。而位于事发地点附近的某个大型数据中心在此次事故中受到了严重冲击。由此可见，数据中心的选址工作是多么重要。
我们再来看一个场景。某客户近日需要紧急上架200台服务器。但不巧的是，当日天气突变，运输的货车刚刚到达，转眼间就下起了倾盆大雨。数据中心既没有可以避雨的场地，室内也没有充足的空间来临时放置设备，大家只好在心里默默祈祷，希望这场大雨能早一点儿停下来。从这个案例中可以看出场地条件对工作开展的限制与影响。2.2.1 地质环境
我们在选择数据中心的时候，尤其是用于灾备的异地机房，一定要做好充分的考察工作，确认数据中心所处的地理位置是安全的。
由于我国位于亚欧、太平洋、印度洋三大板块的交界处，这样的地理位置使得构造断裂活动强烈，常年均有不同程度的地质灾害发生。南部地区降水多，泥石流、洪涝灾害比较严重。尤其是西南方向，青藏高原、云贵高原以及四川盆地是地震、山体滑坡、泥石流的多发地带，四川汶川和青海玉树近年来都发生过特大地震灾害。北方的华北地区也属于地震多发带。此外，华北、西北地区还会因为地表水不足和开采过度等原因出现沉降带。而东南沿海方向，主要是受到塌陷和海啸的侵袭。
简而言之，我们选址的主要目的就是为了躲避天灾和人祸。我们要做到五个远离、三个临近以及一个确保。（1）五个远离
五个远离是指数据中心应远离水、土、火、污、磁这五大区域。
·洪涝区域，水库堤坝下游，沿海航道，江河湖泊。
·山地滑坡、泥石流地带，火山、地震、地质断裂带，低洼、沉降带。
·化工厂、加油站、面粉厂等地。
·核电站或者重污染源（包括噪声污染、化学污染、粉尘污染等）。
·发电站、变电站、铁路、机场等地会产生较强的电磁干扰，对设备的正常通信和信号接收造成影响。（2）三个临近
三个临近是指临近交通、运输和生活区。
·临近市政主干道，便于设备运输。应当具有两条以上可直连主干道的道路，确保不会发生运输线中断事件。
·临近公共交通站，为来往提供交通便利。
·临近城市及生活商业区，方便工作人员在附近就餐及安排住宿，为驻场值守工作提供便利。（3）一个确保
一个确保是说，要确保该地区有良好的移动信号，保证联络通畅。
更多的细节，我们可以参考《计算机场地通用规范》（GB/T2887——2011）。不过，在这里提示大家注意，千万不要走极端。比如加油站，它像一个巨大的储油罐，起火爆炸后产生的冲击波会波及周边的建筑群，应采取远离避让的策略。但加油站同时也是数据中心停电时有力的后援保障。尤其是大面积停电且短时间内无法恢复时，备用的柴油发电机要有足够的油料供应。数据中心可以和加油站签订协议，在特殊情况下保证油料的及时供应。所以在选址的过程中要综合考虑问题，不应按图索骥，过于教条。2.2.2 空间结构
1.机房的抗震等级和载荷
根据《建筑工程抗震设防分类标准》（GB50223——2008）中的描述我们可以得知，按照建筑物的重要程度以及发生灾害后所产生的影响，可以将抗震等级分为如下四类。
·特殊设防类（简称甲类）：使用特殊设施、涉及国家重大工程或者地震发生后会引发严重次生灾害的重点建筑。
·重点设防类（简称乙类）：指地震发生时使用功能不能发生中断或需尽快恢复的，以及地震时有可能导致大量人员伤亡的关键建筑。
·标准设防类（简称丙类）：一般建筑类。
·适度设防类（简称丁类）：适度降低要求的建筑。
对于机房的抗震等级选择，我们建议重点地区的核心机房应当优先选用乙类以上标准，抗震烈度不低于7级。机房区域的楼层活荷载2应不小于1000kN/m，UPS、柴油发电机等安装区域应不小于21600kN/m。另外，室内基础设施与服务器机柜应当采取相应的加固及减震等防护措施。
2.外场地空间的选择
外场地空间的条件是否良好，对设备安装进度会产生很大的影响。互联网公司每年的设备采购量级都很大。一次性运送、拆卸几百乃至上千台设备，对于我们来说太平常了。场地空间大小、货梯的容量与承重、人员和小推车的数量，这些条件决定了你的工作效率。如果场地空间狭小，没有足够的地方卸货，你送货的车辆可能都不一定能开进来。又或者你一次到了1000台设备，结果发现只有一部货梯和两辆小推车，每次最多只能运送30台设备。你还得考虑资源争用的问题，如果其他用户也有同样的需求，想要按时完工就很困难。再者，工作效率低对人也是一种折磨。参与过上架工作的读者应该非常清楚其中的辛苦，这是个纯体力的工作。严寒酷暑不说，还有雾霾，长时间露天工作对身体的伤害很大。此外，像夏天雷雨多发季，天气多变，如果在卸货过程中突然赶上降雨则更加麻烦。
一般来说，送货之前都要提前看天气预报，尽量避开可能降雨的日子。但如果不巧遇到突发天气，大空间的独立库房也是非常重要的，至少它可以保障设备有临时存放的空间。库房的面积和采购运输的设备数量有关，如果用户的保有量很大，在数据中心不同的楼层拥有多个机房，既可以选择分别租用各层库房的部分空间以方便物品的存放和取用，也可以选择租用独立的库房。笔者更倾向于选择后者，我宁愿要一个独立库房，也不想每层都安排一处和别人共用。一来库房过多管理起来不方便；二来租用一个大库房，空间面积的利用率更高，而且设备和别人放在一起也不太安全。至于便利性，相比起来我认为是可以舍弃的。库房主要用于临时存放物品（像存储静置或者临时避雨等情况），设备到货后都应当尽快完成上架工作。所以除了备件之外，库房日常的利用率应当比较低才对。而且我也不建议采购太多备件，硬件设备更新换代快，而x86分布式架构也不应该再出现单点服务的问题，何况库房环境不一定符合备件的存放条件。上述诸多因素表明采购备件的意义不大，除了核心设备以外，完全可以在维修的时候再进行更换。
如果你的系统对时间的精确度要求比较高（例如金融行业），需要采购NTP时间服务器，那么请不要忽略对建筑物天台的考察。如果天台的条件无法满足卫星天线的安装，则谨慎考虑将其设置为你的主机房。
3.机房的选择
选用机房时应确保平层设计，货梯和机房应当位于同一水平层面之上。两者通路之间不应设有楼梯、门槛或坡道等建筑结构，以为设备运输提供便利与安全。有的数据中心的机柜高于机房地面，而且采用了阶梯的方式，这将给运输大型设备带来不小的麻烦和隐患。如果运输途中出现了坡道设计，一定要特别注意。坡道和水平面并不属于同一个建筑结构体。小推车最大承重大多为300kg，因此要关注坡道的载荷承重。其倾斜角度不宜超过10°，以免在运输途中发生设备滑落，从而导致人员受伤和财物损失。
在机房内，要注意查看通道的宽度。最好是能够顺利地平行通过两辆小推车或移动操作台，并且留有一定的余量。平日工作时，我们经常会在某个通道内遇到其他工作人员，通道空间不足，在对向行进的时候就会撞车，势必要有一方退出去才可以。留有足够余量也是十分必要的，以免意外碰到外露的光纤或者突出的设备电源开关。
此外，机房内尤其是机柜上方是严禁有水的，凡是与机房无关的给排水、雨水管道等均不应在房间内穿越。
4.机柜的选择
在进行机柜的考察时，要检查以下问题。机柜的钢板厚度是否合规？柜门关闭后是否会留有较大的缝隙？机柜的进深是否足够（服务器设备应选用800mm以上的）？有些设备进深很大，如果选错了机柜，后期上架导致关不上门就尴尬了。测量的时候米尺和游标卡尺是必备的，如果你有现成的设备，直接上架看效果也是一个简单有效的好办法。运维故事2：奇怪的上架方式
Freedom公司最近又成立了一家分支机构。为了尽快拓展业务，新机构正在紧张地筹建数据中心。由于总部之前刚刚和一家数据中心签订了合作协议，考虑到节省资金和资源合并，IT部门的负责人希望和总部使用同一家数据中心。经过几次考察，他认为总部的需求方案和自己部门很类似，除了自己的空间利用率比总部高一些外，基本上没有什么太多的差别，于是双方很快签订了合同。这家数据中心的价格很低，所以他们只提供网络和机柜，其他服务是没有的，包括设备上架所需的材料。所以开始动工之前，部门还需要采购一大批用于设备上架的托条。在托条选购的当天，负责服务器的工程师小李被叫上一起去现场考察。小李是第一次来这家数据中心，之前的考察并没有通知他一同前往，他只知道数据中心提供43U的机柜。由于过去团队一直秉承机柜高利用率的原则，按照以往的经验，这家数据中心的供电能力可以支撑15台2U服务器。但当他到了现场看到机柜以后却愣住了。原来这家数据中心的机柜和别处的不太一样，它的进深比较短，从机柜两边放下来的强弱电线缆，多余出来的部分无法放到机架后端，否则关不上门。这个机柜底部设计了一段横梁，直接占据了最下面的2个U位，这显然是为了盘多余线缆用的。说好的43U平白无故地减少了2U不能使用，再除去留给网络设备和理线架的位置，只剩下35U了。更要命的是这个机柜使用的是标准U位（44.45mm），而不是以前常用的非标U位（46.45mm）。因为托条本身有2mm厚，使用这种机柜显然是不可能实现全部设备上架了。这样一来，需要重新计算机柜的需求量，至少需要增加50%的开销。用导轨的话，上架速度慢不说，之前也没有这方面的预算，还需要财务重新审批，项目进度等不起啊。这样一个细节的忽略是非常致命的，但当时考察的时候没有人考虑带上一线的工程师去现场确认，现在再说这些都无济于事了。
有个工人提议，托条是可以稍微有一些形变的，三个一组是6U，5组共计30U，加上每组各留一个空位正合适。但是拿了三台设备进行实际测试的时候，发现如果是两台一组还可以，上下两个设备还可以略作调整，但三台根本行不通，中间的设备已经被死死地挤在里面了，根本动弹不得。又有一个人说，要不然干脆就上一根托条，然后把三台设备摞在一起得了。这可真是个“好主意”，众人都没好气地白了他一眼。
最后还是施工方老雷出了个主意，确保不用增加预算，也不会强行挤压设备上架，方案还是使托条上架，每个设备两两一组，两台服务器之间多了一根托条的厚度（2mm），这2mm是不会对设备造成太大的受力影响的。而每组之间要有空位，但不是空一个U位，而是空一个孔。15台2U服务器共计30U，两两一组共分为8组，再加上8个孔所占的U位，最后还有富余。上架完成后，小李对老雷表示感谢：“老哥这活儿辛苦你们啦。”老王呵呵一笑：“咳，只要不影响施工进度，费点儿劲算啥？虽然不太标准，但不仔细看也没啥毛病。哈哈。”
谁说没毛病？空着的那些缝儿没法上盲板，会影响气流，制冷效果肯定不好。小李只是自个儿暗自琢磨，没好意思扫了老雷的兴。还好这家数据中心从来不考虑节能问题，冷风开很足。哎，就这么着吧。
5.辅助区域的选择
数据中心提供的工位数量应当大于两个，并接入百兆以上的共享带宽。另外，如果机房工作比较繁重或者有7×24驻厂值守的场景，可考虑申请独立的小型办公区或者休息床位。2.3 基础设施评估
如果把空间环境评估比作“看风水”，那么基础设施的评估工作可以算得上是“家装考核”了。基础设施系统主要包括电气系统、空调系统、消防系统、弱电及综合布线系统等。2.3.1 电气系统
电力是数据中心正常运转的动力之源，电气系统的重要性自不必说。如图2-1所示，这是一个简易的供电系统示意图。数据中心的电力由外部引入，当外部供电出现故障的时候，则需要利用柴油发电机作为备用手段，对数据中心进行持续保障供电。
我们对用电有三个基本要求——可靠、安全和容量。
1.可靠性要求
用电的可靠性要从如下几个方面来考虑。
首先，输电侧的高可靠性。输电侧的可靠性是重中之重，每年数据中心因停电引发的大面积宕机事件并不是个例。引入一类市电可减少类似事故的发生。图2-1 供电系统简易示意图
其次，全路径上的所有节点要保证充分冗余。说起冗余，我们作为运维人并不陌生，这也是老生常谈的话题了。所谓全路径，指的就是从输电侧到用户侧的整条输电线路。全路径上的每个环节都不能出现单点故障。这是一个逻辑与的关系，任何一处出现单点，整个系统的冗余就是零，跟没做一样。单条线路上的负载能力都应满足全部电力消耗总成，并留有一定的余量，一般应控制在80%～85%之间。在这里，经常会出现2N或N+X的概念。你可以简单地将N看成一个单点，2N就是双倍冗余，等效为存储中的RAID1。而N+X则是指，在多组节点中灵活配置的若干冗余，即可以看作RAID中的Spare盘。
再次，就是备用方案的持续支援能力。一旦主线路失效，作为最后一道防线的备用方案，除了切换及时以外，还要有强大的持续支援能力，以应对主线路无法及时修复的情况。例如我们前面提到的天津港大爆炸，它所引发的断电故障在短时间内肯定是无法恢复的。此时的首要任务是进行切换。假设极端情况下切换失败，那就只能靠备用方案来扛了。
最后一点也很重要，基础设施的采购一定要选用知名品牌，这样才会更有保障。另外，选用产品的原则是求稳不求新。对于一些新兴的技术，即便它来自于知名厂商的产品，我们还是应当慎重选择。
2.用电安全要求
除了可靠性以外，用电安全也是同等重要的。供电设施在长期使用后，会因线路老化发生漏电和人员触电的危险。因此，对于机房低压配电系统要求采用TN-S系统。什么是TN-S系统呢？在详细解释之前，我们需要先了解一些电的基本知识，看一看人体触电是怎样形成的。
电流和水的特性非常相像。常言道“人往高处走，水往低处流”，电流也是从高向低流动的。这里所说的高和低指的是电势。我们人为地将大地的电势定义为0，平时大家所说的××伏电压，指的就是输电侧相对于大地的电势差。除此之外，电流还有一个特性：如果遇到多条可以流经的路径，那么电流中的大部分电子总会选择电阻低的那条路径通过，即常说的电阻和电流成反比。这和我们平时开车是一样的。电阻意味着交通状况，谁都愿意走行驶通畅的道路。如果有两条路径，一条路径的电阻是1000Ω，另外一条路径的电阻是9000Ω，那么这两条路径上面的电流比则是9∶1。
发生触电需要两个条件。首先要具有电势差，其次要形成有效的回路。我们经常看到小鸟能站在高架电线上。那是因为鸟的双脚落在同一根电线上，而鸟的个体很小，两脚之间距离所形成的电势差几乎可以忽略不计，所以它们才能够安然无恙。但是，如果一个人不小心摸到了电门，由于人站在地面上，而大地电势为0，电流会因为电势差的关系，从输电侧经过人体流向大地并形成回路，这样就发生了触电。
为了防止发生触电危险，需要实施接地防护。以电源插座举例，插座面板上的三个孔分别为：左零，右火，中接地。火线（相线）是从输电侧引出来的线。零线（N线）由变压器二次侧中性点引出，用于和火线形成回路。电力在进入用户侧之前，由三根各成120°的相线组成。理论上，三相之间应当是平衡的。此时N线不带电，但这种状态不可能一直保持下去。三相失去平衡时在N线上会产生电流，所以N线必须接地，否则当其断开时会发生触电危险。地线是直接接地的保护线，我们称之为PE线。因为PE线的电阻非常小，相较几千欧姆的人体电阻来说要小得多。一旦人体触电，大部分电流会被它引走，从而确保人员的安全。PE线和N线的接地形式不同。PE线是从变压器中性点接地后引出主干线，并每间隔20～30m重复接地。N线则是在变压器中性点处与PE线重复接地，从而起到了双重保护的作用。
所以，接地是保证用电安全的主要手段。这里产生了一个有趣的问题：既然PE线和N线都要接地，那么如果我们把两股线合并在一起，岂不是节省了一大笔钱吗？这种系统就叫作TN-C系统，我们把这段合并的线称作PEN线。使用TN-C系统可以降低成本，但是它存在一些隐患。当PEN线路受损折断后，断点后端的设备金属外壳都会带电，此时如果有人不小心碰到就会触电。TN-S系统的PE线和N线是完全分开的，安全性高了很多，当然成本也就随之提升了。因此在实际生活当中，人们大多采用折中的TN-C-S系统，即起始路径采用两线合并的方式，在入户之前将PE线和N线分开，而且不允许再次合并。
根据国际电工委员会IEC的定义，供电系统分为三类（五种）——IT、TT、TN（包括TN-S、TN-C、TN-C-S），具体解释如下。（1）第一字母表示电力系统的对地关系
·T——中性点一点接地。
·I——所有带电部分与地绝缘，或一点经阻抗接地。（2）第二字母表示装置外露可导电部分对地关系
·T——外露可导电部分对地直接电气连接，与电力系统的任何接地点无关。
·N——外露可导电部分与电力系统的接地点做直接电气连接（在交流系统中，接地点通常就是中性点），TN系统后面还会有第三个字母。（3）第三个字母表示中性线和保护线的组合关系
·S——中性线和保护线是分开的。
·C——中性线和保护线是合一的（PEN线）。
现在大家明白了吧。PE线和N线分开与否，以及接地点的数量决定了安全等级和成本的高低。尽管选择TT系统更加安全，但它的成本过于高昂。建筑物内如采用TN-C-S系统，其前段PEN线上的中性线电流所产生的电压降会产生电势差，对设备造成信号干扰。而TN-S系统适用于内部设有变电所的建筑物。因此我们要求机房内的低压配电系统必须采用TN-S系统。
除了人员的用电安全之外，我们在选取机房的过程中，还要注意静电对设备的危害。以下这些内容是我们在实际机房选型中对接地和防静电提出的一些要求。
试读结束[说明：试读内容隐藏了图片]