《软件定义数据中心——技术与实践.html.pdf》由会员分享，可在线阅读，更多相关《软件定义数据中心——技术与实践.html.pdf（234页珍藏版）》请在三一文库上搜索。
1、编委会 主编 陈熹 EMC中国研发集团高级经理 Ricky Sun（孙宇熙） EMC首席技术官办公室技术总监 编写组（按姓氏拼音排序）：EMC中国研究院 曹逾 陈平 董哲 范晨辉 郭小燕 李三平 刘伟 陶隽 王俊元 杨子夜 赵丽媛 周宝曜 特约编委 黄彦林 金昀 陈文春 Ray Feng Ariel Duan 联合策划 朱捷（EMC中国研究院） 序 说到软件定义数据中心，我们要先从互联网说起。互联网在过去二十年里，更新了我们的沟通模式，加速了我们的信息获取，变革了我们的购物习惯，彻底地改变了我们的生活。不仅如此，互联网还 颠覆了许多行业，而此颠覆仍是进行时。在企业级IT行业，云计算就是这场颠覆
2、的名字。 由于互联网的远程商业服务模式与超大规模技术架构的推广与成熟，使得各行各业看到一个新的IT云服务模式和一个新的IT云基础架构。这个服务模式就是“as a Service”（即服务）的模式，包含了 IaaS、PaaS、SaaS，及总称ITaaS。而这个新的基础架构就是这本书的主角SDDC，即软件定义数据中心。 如果拜访任何一个成功的云服务商或任何一个大规模的互联网服务商的数据中心，我们会发现它们的创新与技术几乎完全是由软件来完成的。这些数据中心的硬件往往会非常统一，而不同的计算、存 储、网络以及管理功能则由软件来实现。由于这个特性，使得它们的硬件使用率提高，伸缩规模相对简单，部署应用尤其
3、迅捷。 而回头看现在的企业级数据中心，还不完全是这样。同时，大多数企业并不能摒弃自己的数据中心而完全依赖公有云的服务。但是，把云基础架构运用到企业级数据中心的时机已经成熟。企业可以在 自己的数据中心搭起软件定义的私有云，并与公有云相通，形成混合云。 有了以软件定义数据中心为基础的混合云，企业就可以进退有度，游刃有余。加上成功管理新的移动终端技术，可轻松进入“云移动”时代！这也是为什么软件定义数据中心最近获得大家关注的根本 原因。EMC中国研究院编著的这本软件定义数据中心：技术与实践恰逢其时，它会向读者详细解说怎么实现软件定义数据中心。 从2006年开始，我与EMC中国研究院（ELC）的同事一起
4、工作、合作，深深地被ELC的研究员们的踏实、专业与聪颖所打动。这八年是云计算和软件定义数据中心从无到有、从稚嫩到完善的一个激动 人心的过程，也是EMC中国研究院从无到有、不断发展、日益成熟的过程。 我相信对所有前瞻性的正在迈入云移动时代的企业IT部门来说，这是一本有“干货”的好书；对业界与学界研究云计算与数据中心架构的专家、学者、学生来说，也是一本有参考价值的好书。 希望你会喜欢它。 Charles Fan VMware高级副总裁，EMC中国卓越研发集团创始人 前言 对于IT设备和服务厂商来说，“这是一个最好的时代，也是一个最坏的时代”。一方面，Amazon、Google和层出不穷的初创公司能
5、轻而易举地从资本市场拿到源源不断的投资，似乎根本不用担心成 本压力和盈利预期；另一方面，IBM、HP等传统IT巨头不得不焦头烂额地应对业绩的压力、对发展前景的质疑，希望通过转型继续在企业IT市场生存下来。外行人看来，还不是做着一样的生意吗？怎么前 两年风生水起的大公司，这么快就裁的裁、撤的撤，纷纷转型自救了？俗话说得好：“形势比人强”。任由你是业界的“巨无霸”，也抵挡不住时代的大潮。这一波拍过来的浪潮无疑就是第三平台。在第 三平台的大浪中，移动应用、社交应用、大数据应用是冒头的浪尖，而提供动力的是云计算。 作为第三平台的支柱，云计算吸引了IT厂商最多的资源。因为大家都对第二平台时代Window
6、s操作系统+Intel CPU（简称Wintel）的联盟记忆犹新，谁占据了基础架构平台，谁就能主宰一个时代。在 这个问题上，传统IT厂商和互联网背景的IT服务商是有重大分歧的。互联网公司没有老本可吃，也没有历史包袱，他们希望能让用户一步到位，直接上公有云；而传统IT厂商则多立足于现有的产品线，希望 能让用户实现从On-premise（IT的本地运营）到off-premise（异地运营，如IDC）到私有云、混合云的过渡。然而无论是哪种云，都会碰到一系列共同的问题：硬件资源利用率、扩展性、自动化管理 等。硬件的更新换代需要经年累月的时间，通常很难满足快速发展的业务需求，软件定义才是现实可行的出路。
7、这也是为什么软件定义数据中心迅速成为IT产业的热门关键词的原因。 本书呈现了EMC中国研究院在这一领域多年的研究成果，并在此基础上总结梳理出软件定义数据中心的发展历程和未来方向。在内容组织上，全书分为四个部分：第一部分是总体介绍，试图回答一些 关于软件定义数据中心的基本问题，告诉读者“什么是软件定义数据中心”、“为什么需要软件定义”；第二部分深入介绍了软件定义数据中心的关键技术，涵盖了计算、存储、网络、资源管理和调度、 安全和高可用性；第三部分在了解了关键技术的基础上，向读者展示了软件定义数据中心可以提供的一些应用场景；第四部分选取了两个软件定义数据中心的实例，一个是面向公有云的AWS，另一个
8、是面 向流媒体的PPTV，希望能让读者更有临场感，能看一看现在业界的“大拿们”是怎么“玩”的。 在本书的编写过程中，我们得到了Pivotal公司技术总监Ray Feng先生、我们的前EMC同事的大力支持，Ray对第三平台的精辟论述也出现在了本书第1章。同时感谢PPTV的特约编委们、Ricky的前微 软同事们、以PPTV研发副总裁Bill Huang为领导的研发团队的同事们，他们提供了大量第一手资料，并共同编写了一章大型实例。此外，还要感谢EMC中国研发集团总经理Wei Liu和EMC高级总监Xiaoye Jiang在本书编写的过程中给予的大力支持。最后，我们衷心感谢在本书的撰写和出版过程中对我
9、们给予巨大帮助的机械工业出版社华章公司的编辑们，没有她们的辛勤工作和耐心配合，这本书不会成为现 实。 由于时间有限，本书的内容难免存在错漏之处，还请各位读者和专家不吝赐教。 陈熹、Ricky Sun（孙宇熙） 第一部分 总体介绍 第1章 基本概念 第1章 基本概念 软件定义数据中心（Softwares Defined Data Center，SDDC）是个新概念。新到什么程度呢？2012年以前还没有人系统阐述它。随着软件定义计算、软件定义存储、软件定义网络等一系列“软件 定义”新技术的蓬勃发展，已经有几十年发展历史的数据中心眼看着将要迎来另一场深刻的变革。原有的设备还可以继续运转，但是管理员不
10、再需要频繁出入轰鸣的机房去照看它们；网络不需要重新连线 也可以被划分成完全隔离的区域，并且不用担心IP地址之间会发生冲突；在数据中心部署负载均衡、备份恢复、数据库不再需要变动硬件，也不再需要动辄几天的部署测试，管理员只需点几下鼠标，几秒 钟就能完成；资源是按需分配的，再也不会有机器长年累月全速运转，而没有人知道上面运行的是什么业务；软件导致的系统崩溃几乎总是不可避免的，但是在系统管理员甚至还没有发现这些问题的时 候，它们已经被自动修复了，当然，所有的过程都被记录了下来 在机房里汗流浃背地摆弄过服务器的网线、光纤线、串口线和各种按钮的系统管理员看到这种情景会是什么心情？回忆起往日给上百台服务器装
11、系统、打补丁时手忙脚乱的画面，如今都已经成了过眼 云烟，不免有些悲喜交加。不管是悲是喜，这些事情都正在发生。也许你所接触到的一些计算环境已经开始大规模应用计算虚拟化，但是还在使用传统的以太网和基于IP的网络划分；也许有人已经将存储 资源全部抽象成了块存储、文件存储和对象存储，但是还需要大量的手工配置去设置一个备份服务这不是一场风暴，原有的技术和架构不会在一夜之间被摧毁；这也不是海底火山喷发，信息孤岛不会转 眼间就消失。SDDC所涉及的概念、技术、架构、规范都在迅速发展，但又并不同步。我们要展示给大家的是一个日新月异的领域。要想用一两句话为SDDC下一个准确的定义本身就不够严谨。 要了解什么是S
12、DDC，至少要回答以下几个基本的问题： SDDC是在什么基础上发展而来的？ 是什么驱动了SDDC的演化？（解决了什么问题？） SDDC是由什么组成的？ SDDC将向何处发展？ 接下来，我们先循着技术发展的脉络，看看在SDDC出现之前，已有的计算环境是什么样的。 1.1 数据中心的历史 顾名思义，数据中心（Data Center）是数据集中存储、计算、交换的中心。从硬件角度考虑，它给人最直观的印象就是计算设备运作的环境。因此，数据中心的发展是与计算机（包括分化出的存储 和网络设备）的发展紧密联系在一起的。 从第一台电子计算机出现开始，这些精密的设备就一直处于严密周到的保护中。由于最早的电子计算机
13、几乎都应用于军事，不对公众开放服务，而且每台计算机所需要的附属设施都是单独设计的，因 此参考价值非常有限。 商用计算机的大量应用开始于20世纪60年代，其中最具代表性的是IBM的主机（Mainframe）系列，包括700/7000系列、System/360、System/370、System/390和今天仍占据市场主要份额的 System Z。这些都是重达几十吨、占地数百平方米的“大家伙”，与之略显不相称的是这些机器缓慢的计算速度和较小的数据存储规模（仅指20世纪60年代，如今的System Z已经非常强大）。在当时， 拥有这样一台计算机是非常奢侈的事，更不要说在一个机房同时部署几台这样的庞然
14、大物。 图1-1中，是20世纪60年代的一个主机机房。一排排的机柜就是计算机的主体，而整个篮球馆一样大小的房间就是当时的数据中心。显而易见，这里仅有一台计算机，因此这个数据中心是不需要如今 概念上的网络的，也没有专门的存储节点。从管理角度看，这时候数据中心的管理员是需要精细分工的，有专人管理电传打字机（Teletype），有专人管理纸带录入，有专人管理磁带可以想象，要运行 这台计算机不是一件容易的事情。 图1-1 IBM主机所在的机房 值得一提的是，尽管很多与那个年代的数据中心有关的东西都进入博物馆，我们还是可以在现在的计算机上找到一些痕迹。用过UNIX/Linux的读者也许会记得系统中的虚拟
15、终端会用TTY来表示，这就 来源于Teletype。 随着大规模集成电路的发展，20世纪80年代开始，大量相对廉价的微型计算机出现了。数据的存储和计算呈现一种分散的趋势，越来越多的微型计算机被部署在政府、公司、医院、学校绝大多数 微型计算机是互不联通的，信息的交换更多依靠磁盘、磁带等介质。到了90年代，计算的操作变得越来越复杂，原有的微型计算机开始扮演客户端的角色，而大型的任务如数据库查询被迁移到服务器端， 著名的客户端/服务器模式开始大行其道，这直接推动了数据中心的发展。让我们看看，在经过20世纪50年代至80年代计算机科学理论发展的黄金年代后，计算机工业又经历了怎样的飞速发展。 1981年
16、Hayes出品了300bps的Smartmodem 300，并发明了AT命令作为标准。 1983年以太网作为IEEE 802.3标准出现。 1985年Intel公司出品了80386处理器。 1986年IBM公司在Model 3090中第一次应用了1兆主频的芯片。 1987年Sun公司出品了第一块SPARC芯片。 1989年SQL Server发布。 1991年Linux登上历史舞台。 1994年Compaq公司出品了第一款机架式服务器ProLiant。 数据中心再也不是只有一台计算机，机架式服务器的出现，更加大幅度提升了数据中心中服务器的密度。随着越来越多的计算机被堆叠在一起，机器之间的互联就
17、显得日益重要起来。无论是局域网还 是广域网，网络技术都在这一时期取得了飞速的发展，为互联网时代打下了坚实的基础。数据中心里的网络设备也从计算机中分化出来，不再是“用于数据交换的计算机”。软件方面，UNIX仍然是数据中 心的主流操作系统，但是Linux已经出现，并且在这之后的岁月里展现出了惊人的生命力。 进入21世纪，伴随着互联网的出现和被公众迅速接受，数据中心从技术发展到运行规模，都经历了前所未有的发展高潮。几乎所有的公司都需要高速的网络连接与Internet相连，而且公司的运营对于 IT设施的依赖性越来越高，需要不间断运行的服务器支撑公司的业务。试想，如果一家公司的电子邮件系统处于时断时续的
18、状态，如何保证公司的正常运作？然而，每家公司都自行构建这样一套基础架构 实在太不划算，也没有这个必要。于是，IDC（Internet Data Center）就应运而生了。这是第一次出现以运营数据中心为主要业务的公司。由于竞争的需要，IDC竞相采用最新的计算机，采购最快速的网 络连接设备和存储设备，应用最新的IT管理软件和管理流程，力图使自己的数据中心能吸引更多的互联网用户。不仅仅是IT技术，作为专业的数据中心运营商，IDC为了提高整个系统的可靠性、可用性和安 全性，对建筑规范、电源、空调等都做了比以往更详尽的设计。 一个普通的IDC可以有数千台服务器、几个TB的网络带宽、若干PB的存储。99
19、.99%的初级程序员和系统分析员都会觉得这已经够大了，只要把应用不断部署进去就可以了。而且，服务器、存储、网络 带宽都还有扩充的余地，IDC就像汪洋大海一样，永远不会被用尽。区别只是需要把应用部署在哪个IDC中。这就像当时设计IPv4协议时对待IP地址的态度：IP地址太多了，足够了。IPv4的主地址池好歹分 了30年才分完，而孤立的IDC还没有撑过10年就已经进入了互连互通的时期。没办法，总有那么些新东西是我们预见不到的。IPv4的地址会迅速枯竭，主要是因为设计者没有预见到互联网用户的激增和各 种移动设备的出现。对于IDC来说，推动互连互通的主要是这样一些需求： 1）跨地域的机构需要就近访问数
20、据和计算能力。例如，许多跨国公司在中国的研发中心，几千人不可能都远程登录到总部的数据中心工作，浪费昂贵的国际流量还在其次，关键是用户体验达不到要 求。这些研发中心都有本地的数据中心，并且与公司位于其他国家的数据中心有统一的网络规划、管理流程。 2）越来越大的分布式应用。例如，作为谷歌存储系统核心的GFS，运行在几乎所有的服务器中。较大的GFS跨数千台机器，看起来还可以勉强“塞”进某个数据中心，可惜这样的大文件系统不是一个 两个 3）云计算的出现。与前两个不同，云计算的出现是推动IDC向CDC（Cloud Data Center）发展的最关键因素。提到云计算，就不能不提亚马逊的AWS（Amazo
21、n Web Service）。亚马逊在以下地区 都有大型数据中心，以支撑AWS的服务： 爱尔兰的都柏林 新加坡的新加坡市 美国的加利福尼亚州帕罗奥图（Palo Alto） 美国的弗吉尼亚州阿什本（Ashburn） 日本的东京 澳大利亚的悉尼 由于这些因素的推动，数据中心之间的联系变得更紧密。不同数据中心的用户不会觉得自己是在一个孤立的环境中，因为跨数据中心的计算资源、存储空间、网络带宽都可以共享，管理流程也很相 近。这让所有用户感觉自己工作在一个巨大、统一的数据中心中。多么巨大的应用也不再是问题。需要更多服务器？扩展到下一个空闲的数据中心吧。不仅仅需要物理机器，而是需要把虚拟机在全球范围 内迁
22、移？这也能办到，亚马逊已经在这么做了。 回过头看看数据中心的发展历史，如图1-2所示，数据中心中机器的数量从一台到几千几万台，似乎是朝着不断分散的目标发展。但是从管理员和用户的角度看，访问大型机上的计算资源是从一个大的 资源池中分出一块，访问云数据中心中的计算资源也是如此。用户体验经历了集中分散集中的发展过程。新的集中访问资源的模式和资源的质量都已经远远超越了大型机时代。从一台机器独占巨 大的机房，到少量计算机同时各自提供服务，再到无数的机器可以高速互通信息、同时提供服务，可以分配的资源被越分越细，数据中心的密度也越来越高。有趣的是，管理数据中心的人员并没有增长得 这么快。网络的发展让管理员可
23、以随时访问数据中心中任何一台机器，IT管理软件帮助管理员可以轻松管理数千台机器。如果管理员不借助专业IT管理软件，一个人管理几十台机器就已经手忙脚乱了。从 这个角度看，传统的数据中心是“软件管理的数据中心”。 图1-2 数据中心的发展 1.2 继续发展的推动力 的确，“软件管理的数据中心”已经发展得非常完善了，仅就可管理的硬件数量而言并没有迅速发展的必要，场地维护、电力、空调等基础设施的管理也成熟到足够在一个数据中心容纳数万台机器。 例如雅虎（Yahoo！）在美国纽约州建设的数据中心拥有约2800个机柜，足以容纳5万台到10万台服务器同时工作，DCIM（Data Center Infrastr
24、ucture Management）系统会监控每一台服务器的运行 状态，确保整个数据中心没有一台机器会热得烧起来（服务器自身也有温度控制系统，这种情况很少发生），确保UPS在风暴来临而突然断电的时候能正确切换到工作负载上。虽然亚马逊的数据中心在 2012年出过一点小差错，但是绝大部分时间里，这些系统是工作得很好的。 照理说，数据中心的管理人员应该比以往任何时候都要轻松。如果没有什么需要继续改进，那就按照现在的模式，再多建几座数据中心，就能解决所有的问题了。这对于数据中心基础设施的管理员来 说应该是好事，而系统管理员却并不这么想。让我们来看看有什么样的麻烦困扰着系统管理员。 1.机器实在太多 如
25、果只是把机器堆在机房里还好，可是想想看给1000台机器配置好操作系统、配置好网络连接、登记在管理系统内、划分一部分给某个申请用户使用，或许还需要为该用户配置一部分软件这看起 来实在是劳动密集型任务。想想谷歌吧，它经常需要部署一个数千节点的GFS环境给新的应用，那么是不是需要一支训练有素、数量庞大的IT劳务大军？ 2.机器的利用率太低 Mozilla数据中心的数据让人有些担心。据称，Mozilla数据中心的服务器CPU占用率在6%10%之间。也许这与应用的类型有关，例如在提供分布式文件系统的机器上CPU就很空闲，与之对应的是内 存和I/O操作很繁忙。如果这只是个例，就完全没有必要担心，但服务器利
26、用率低下恰恰是一个普遍存在的问题。一个造价昂贵的数据中心再加上数额巨大的电费账单，最后却遗憾地发现只有不到10%的资 源被合理利用了，剩下超过90%是用来制造热量的。别忘了，散热还需要花一大笔钱。 3.应用迁移太困难 只要摩尔定律还在起作用，硬件的升级换代就还是那么快。对于数据中心来说，每隔一段时间就更新硬件是必须的。困难的不是把服务器下架，交给回收商，而是把新的服务器上架，按以前一样配置 网络和存储，并把原有的应用恢复起来。新的操作系统可能有驱动的问题，网络和存储可能无法正常连接，应用在新环境中不能运行最后很可能不得不请工程师到现场调试，追踪问题到底是出在硬件、 软件上，还是哪个配置选项没有
27、选中。 4.存储需求增长得太快 2012年全球产生的数据总量约为2.7ZB（1ZB=1万亿GB），相比2011年增长了48%。即使不考虑为了存储这些数据需要配备的空闲存储，也意味着数据中心不得不在一年内增加50%左右的存储容量。 用不了几年，数据中心就会堆满了各种厂家、各种接口的存储设备。管理它们需要不同的管理软件，而且常常互相不兼容。存储设备的更新比服务器更关键，因为所存储的数据可能是我们每个人的银行账 号、余额、交易记录。旧的设备不能随便换，新的设备还在每天涌进来。学习存储管理软件的速度也许还赶不上存储设备的增长。 问题绝不仅仅只有这么几点，但是我们已经可以从这些例子得到一些启示。像以往数
28、据中心的发展一样，首先是应用的发展推动了数据中心的发展。之前提到的超大型分布式系统和云计算服务平台都 是类似的应用。我们在后面还会介绍更多这样的应用场景。这些应用有一个共同的特点，没有任何悬念，它们需要比以往更多的计算、存储、网络资源，而且需要灵活、迅速的部署和管理。为了满足如此 苛刻的要求，仅仅增加机器已经无济于事了。与此同时，人们“终于”发现数据中心的服务器利用率竟然只有不到10%。但是应用迁移却如此困难，明知有些机器在99.9%的时间都空闲，却不得不为了那 0.1%的峰值负荷而让它们一直空转着。如果说服务器只是有些浪费，还勉强说得过去的话，存储就更让人头疼了。数据产生的速度越来越快，存储
29、设备要么不够，要么实在太多无法全面管理 1.3 软件定义的必要性 正是因为有了上述挑战，无论是数据中心的管理员，还是应用系统的开发人员，或是最终用户，都意识到将数据中心的各个组成部分从硬件中抽象出来、集中协调与管理、统一提供服务的重要性。如 图1-3所示，在传统的数据中心中，如果我们需要部署一套业务系统，例如文件及打印服务，就要为该业务划分存储空间，分配运行文件及打印服务的服务器，配置好服务器与存储的网络。 图1-3 传统数据中心中的资源 这需要多长时间呢？这可没准。不同的计算中心都有各自的管理流程，大多数情况下都要先向IT管理员提交一个请求，注明需要哪些资源。IT管理员拿到这个请求之后，会在
30、现有的资源列表中寻找适 合的服务器、存储、网络资源。假设运气很好，不需要额外采购就能满足文件服务器的要求，最快也需要12天的时间。如果碰到现有的资源数量和质量无法满足需求，那就继续等待吧，询价、采购、发 货、配置上线这么折腾下来，不经过十天半个月的等待，怕是根本没办法开始部署业务系统。对于一个文件及打印服务来说，等一下也无可厚非，实在不行可以把数据暂时存储在U盘里，再凑合使用旧 的打印服务器。可是如果一家公司的核心业务系统紧急需要资源怎么办？2012年开始在国内炒得火热的双十一促销是各个电商平台的整体较量，对它们来说都是重头戏。可万事开头难，就在2012年11月 11日这一天，淘宝和京东的后台
31、系统从飞速变成了“龟速”。京东的CEO刘强东微博回应：紧急采购服务器扩容！先不说业务系统的设计是否支持这样迅速的扩容，单就IT资源的管理角度，如果这样的业 务需要等上几天，那双十一大战是必然要落败了。公司高层领导当然可以省却许多繁琐的流程，但是服务器也不可能“飞”到京东的机房来，无论如何都已太慢。 从图1-3还可以看到，如果有6个业务系统，就需要6套服务器，这很合理。在生产环境的服务器上再部署、调试其他业务只会带来更多的麻烦，而且实际上，文件打印这些服务需要的计算能力很弱， 数据库系统需要很大的内存和非常好的I/O能力，高性能计算需要强大的CPU。显而易见，为不同的业务采购不同配置的服务器是必
32、需的，而且对于各项性能的要求几乎完全来自于估计，没有人会确切地知 道是否需要256GB的内存而不是128GB。因此，IT管理员需要面对的就是千奇百怪的配置表和永远无法清楚描述的性能需求。因此IT管理员在采购硬件的时候自然而然会采取最安全的策略：尽量买最好 的。这就出现了上文提到过的问题：服务器的利用率低得惊人。 高端的存储可以较好地实现存储资源池，并且理论上可以同时支持所有的应用。但是把EMC的高端存储用来支持打印服务器，似乎显得太奢侈了。实际情况下，这些业务系统会至少共享23种存储设 备。每个子系统都使用各自的子网，但是一个网段分给了某项业务，即使并不会被用完，其他系统也不能再用了。 幸好虚
33、拟化技术重新回到了人们的视野当中。在计算机发展的早期，虚拟化技术其实就已经出现了，当时是为了能够充分利用昂贵的计算机。数十年后，虚拟化技术再一次变成人们重点关注的对象， 这依然跟提高资源的利用效率有密不可分的关系。而且这次虚拟化技术不仅在计算节点上被广泛应用，相同的概念也被很好地复制到了存储、网络、安全等与计算相关的方方面面。虚拟化的本质是将一种 资源或能力以软件的形式从具体的设备中抽象出来，并作为服务提供给用户。当这种思想应用到计算节点，计算本身就是一种资源，被以软件的形式各种虚拟机从物理机器中抽象出来按需分配给 用户使用。虚拟化思想应用于存储时，数据的保存和读写是一种资源，而对数据的备份、
34、迁移、优化等控制功能是另一种资源，这些资源被各种软件抽象出来，通过编程接口（API）或用户界面提供给用户 使用。网络的虚拟化也是这样，数据传输的能力作为一种资源，被网络虚拟化软件划分成互相隔离的虚拟网络，提供如OpenFlow这样的通用接口给用户使用。当主要的基础资源如计算、存储、网络被充 分虚拟化之后，数据中心的逻辑结构将如图1-4所示。 图1-4 虚拟化的计算、存储、网络 资源的可用性是原生的，是买来这些设备时就已经具备的。但是如何发挥其使用效果，却要靠创新的思路和方法。我们可以看到，当服务器虚拟化之后，计算能力就可以真正做到“按需分配”，而不 是必须给每种服务配置物理的机器。过去的IT管
35、理员当然也希望能够做到“按需”而不是“按业务”分配，但是没有虚拟化技术，没有人会愿意冒风险把可能互相影响的系统放在同一台服务器上。存储也 被虚拟化了。用户不用再关心买了什么磁盘阵列，每个阵列到底能够承载多少业务，因为他们看到的将是一个统一管理的资源池，资源池中的存储按照容量、响应时间、吞吐能力、可靠性等指标被分成了 若干个等级。系统管理员可以“按需”从各个资源池中分配和回收资源。虚拟的网络可以“按需”增减和配置，而不需要动手配置网络设备和连线。能做到这一步，至少就能够解决以下问题： 资源的利用效率低下，不能充分利用硬件的能力。 资源的分配缺乏弹性，不能根据运行情况调整投入。 在提供基础设施服务
36、时，必须考虑不同硬件的性能。 需要改变配置时，不得不重新连线和做硬件配置的调整。 需要特别注意的是，在虚拟化这一概念中，利用软件来抽象可用的资源这一点尤为重要，因为这样才能实现资源与具体硬件的分离（Decouple），从而使进一步发展数据中心成为可能。这也是“软件 定义数据中心”的由来。 当主要的资源都已经虚拟化，“软件定义”还并没有实现，这是因为虚拟化在解决大量现有问题的同时，也带来一些新的挑战。 首先，虚拟化让资源得以按需分配和回收，这使得资源的管理更加精细。不仅如此，管理的对象也发生了变化。传统的数据中心资源管理以硬件为核心，所有的系统和流程根据硬件使用的生命周期来 制定。当资源虚拟化之
37、后，系统管理员不仅需要管理原有的硬件环境，而且新增加了对虚拟对象的管理。虚拟对象的管理兼有软件和硬件的管理特性。从用户的使用体验来说，虚拟对象更像硬件设备，例 如服务器、磁盘、专有的网络等；而从具体的实现形式和收费来说，虚拟对象却是在软件的范畴里。为了适应这种改变，资源管理要能够将虚拟对象与硬件环境甚至更上层的业务结合起来，统一管理。 虚拟化令资源的划分更加细致，不仅带来了管理方式上的挑战，被管理对象的数量也上升了至少一个数量级。原本一台服务器单独作为一个管理单位，现在虚拟机变成了计算的基本管理单位。随着多 核技术的发展，如今非常普通的一台物理服务器可以有2个CPU，每个CPU上有8个物理计算
38、核心（Core），每个计算核心借助超线程技术可以运行2个线程，因而也可以被认为是2个虚拟CPU。因此，一 台物理服务器上往往可以轻松运行1530个虚拟机实例。存储的例子更加明显。传统的存储设备为物理机器提供服务，假设每台机器分配2个LUN（逻辑单元号）作为块存储设备，如今虚拟化之后需要分配 的LUN也变成原来的几十倍。不仅如此，因为存储虚拟化带来的资源的集中管理，释放了许多原来不能满足的存储需求，因此跨设备的存储资源分配也变成了现实。这使得存储资源的管理对象数量更加庞 大了。网络的数量恐怕不用赘述了。想想看为什么大家不能满足于VLAN，而要转向VxLAN。一个很重要的因素是VLAN tag对虚
39、拟网络有数量的限制，4096个网络都已经不够了（详见第4章）。要管理数 量巨大的虚拟对象，仅仅依靠一两张电子表格是完全应付不了的，连传统的管理软件也无法满足要求。例如，某知名IT管理软件在导航栏里有一项功能，用列表的方式列出所有服务器的摘要信息。在虚拟 化环境中试用时，由于虚拟服务器数量太多，导致浏览器无法响应，不得不“恳请”用户不要轻易使用。 虚拟环境带来的另一个挑战是安全。这里既有新瓶装老酒的经典问题，也有虚拟化特有的安全挑战。应用运行在虚拟机上和运行在物理服务器上都会面临同样的攻击，操作系统和应用程序的漏洞依然 需要用传统的方式来解决。好在如果某个应用在虚拟机上崩溃了，不会影响物理服务器
40、上其他应用继续工作。从这点来看，虚拟化确实提高了计算的安全性。虚拟化的一个重要特点是多用户可以共享资 源，无论是计算、存储、网络，共享带来的好处显而易见，然而也带来了可能互相影响的安全隐患。例如，在同一台物理服务器上的虚拟机真的完全不会互相影响吗？早期，亚马逊的AWS就出现过某些用 户运行计算量非常大的应用，而导致同一台物理机器上的其他虚拟机用户响应缓慢的情况。存储的安全性就更关键了。如果你在一个虚拟存储卷上存放了公司的财务报表，即使你已经想尽办法删除了数 据，你还是会担心如果这个卷被分配给一个有能力恢复数据的人，就会存在安全隐患。 可见，仅仅将资源虚拟化，只是解决问题的第一步。对虚拟对象的管
41、理是下一步要完成的任务。如图1-5所示，新的资源管理和安全并不是着眼于物理设备的，而是把重点放在管理虚拟对象上，使虚拟 环境能够真正被系统管理员和用户所接受。 图1-5 新的资源管理与安全 当虚拟资源各就各位，管理员动动鼠标就能够安全地分配、访问、回收任何计算、存储、网络资源的时候，数据中心就可以算得上是完全被软件接管了。可是这并不意味着软件定义数据中心已经能够 发挥最大的作用。因为资源虽然已经虚拟化，纳入了统一管理的资源池，可以随需调用，但是什么时候需要什么样的资源还是要依靠人来判断，部署一项业务到底需要哪些资源还是停留在技术文档的层 面。数据中心的资源确实已经由软件来定义如何发挥作用，但是
42、数据中心的运行流程还没有发生根本改变。以部署MySQL数据库为例，需要2个计算节点、3个LUN和1个虚拟网络。知道了这些还远远不 够，在一个安全有保证的虚拟化环境中，管理员要部署这样一个数据库实例需要完成以下流程： 不难发现，除了使用的资源已经被虚拟化，这套流程并没有任何新意。当然，是否有新意并不重要，重要的是好用、能解决问题。看起来这样的流程并不复杂。那让我们再考虑一下，仅仅部署一个 MySQL数据库常常不是最终的目标，要提供一个能面向用户的应用，还需要更多的组件加入进来。假设我们需要部署一个移动应用的后台系统，包括一个MySQL数据库、Django框架、日志分析引擎，按 照上面的流程，工作
43、量就至少是原来的3倍。如果我们需要为不同的用户部署1000个移动应用的后台系统呢？ 回过头来想想，既然资源都已经虚拟化并且置于资源池中，管理员对虚拟资源理应有更大的控制权，那么在部署虚拟机的时候，自然可以在模板中留下一些辅助配置的“后门”。不仅仅是虚拟机，存 储和网络虚拟化提供的接口也提供了类似的配置功能。既然可以用“后门”间接控制虚拟资源被分配后的配置，那将整个流程自动化就是顺理成章的事情了。管理员需要做的是经过实验，事先定义一套工 作流程，按照流程管理系统的规则将工作流程变成可重复执行的配置文件，在实际应用的时候配置几个简单的参数即可。经过自动改造的MySQL部署流程将变成： 在这个过程中
44、，如果需要部署的流程并不需要特殊的参数，而是可以用预设值工作，甚至可以做到真正的“一键部署”，那么软件定义数据中心就可以显示出强大的优势了。不仅仅资源的利用可以做 到按需分配，分配之后如何配置成用户熟悉的服务也将能够自动完成。 如果你需要的是几台虚拟机，现在已经能够轻松做到了；如果你需要的是同时分配虚拟机、存储和网络，现在也能够做到了；如果你还需要把这些资源包装成一个数据库服务，现在也只需要动动手指 就能完成。程序员们应该已经非常满足，管理员也完全有理由沾沾自喜了。毕竟，之前要汗流浃背重复劳动几天的工作，现在弹指间就可以全部搞定。可是对于那些要使用成熟应用的终端用户来说，这和 以前没有什么区别
45、。例如，等待CRM（Customer Relation Management）系统上线的用户，并不真正在意如何分配资源，如何建立数据库，唯一能让他们感到满意的是能够登录CRM系统，开始使用这 个系统管理用户信息。 要解决这个问题，让应用真正能面向用户，可以有几种方法。在这个阶段，数据中心的资源已经不是单纯跟资源管理者有关系了，而是与用户的应用程序产生了交集。相应的，无论我们采用哪一种方 法去建立应用程序的运行环境，也都必须视应用本身的特性而定。如表1-1所示，第一种方法是发展了自动部署数据库的流程，将这套流程扩展到部署用户的应用，同样还是利用自动化的流程控制来配置用 户程序。第二种是部署一套P
46、aaS（Platform as a Service）的环境，将用户程序运行在PaaS之上。第三种看起来更简单，让用户自己设计自动部署的方法，是否集成到数据中心的管理环境中则视情况而 定。 表1-1 运行环境自动部署方法比较 各种方法都有其适用的场景，并不能一概而论，这是数据中心的基础架构面向用户的关键一步。如果说之前的虚拟化、资源管理、安全设置、自动化流程控制都还是数据中心的管理员关心的话题，那 部署应用这一步已经实实在在把花了钱、买了这些服务的用户拉进来了。在成功部署了应用之后，软件定义数据中心才算是真正自底向上地建立了起来。 如图1-6所示，软件定义数据中心是一个从硬件到应用的完整框架。用
47、户的需求永远是技术发展的原动力，软件定义数据中心也不例外。我们在上文中提到了数据中心在云与大数据的年代面临的诸多挑 战，传统数据中心的计算、存储、网络、安全、管理都已无法应对日益变化的用户需求。在这种四面楚歌的状况下，软件定义计算（或称计算虚拟化）作为一种既成熟又新颖的技术，成为了解决困局的突 破口。随之而来的是软件定义存储和网络技术。在资源的虚拟化已经完成之后，虚拟环境中的安全与管理需求变成了第二波创新的主题。在这之后，数据中心的自动化流程控制进一步释放了软件定义技术 的潜在威力，让管理员不踏足机房就能够如同指挥千军万马一般调配成千上万的虚拟机配置数据库、文件服务、活动目录等服务，甚至可以更
48、进一步，自动部署成熟的用户程序提供给用户使用。 图1-6 支持具体应用的软件定义数据中心 软件定义数据中心是应用户需求而发展的，但并不是一蹴而就地满足了用户的初始需求。“非不为也，实不能也”。软件定义数据中心是一项庞大的系统工程，基础如果不稳固，仓促地提供服务只会 带来严重的后果。云计算服务就是个很好的例子。云计算服务的后端无疑需要强大的软件定义数据中心做支撑。国内有数家学习亚马逊的企业，本着“一手抓学习，一手抓运营”的精神，在技术并不成熟 的情况下，“勇敢”地向大家提供云计算服务，但是计算的稳定性、存储的可靠性、网络的可用性都暴露出了许多问题，用户体验实在无法让人满意。 当然，并不是任何一个
49、软件定义数据中心都需要完全如上文所述，搭建从硬件到用户的完整框架，也不是所有可以称为软件定义数据中心的计算环境都具备上文所述的所有功能。一切还是应用说了 算。例如，用户可能仅仅需要虚拟桌面服务并不需要复杂的虚拟网络，但是安全和自动控制流程要特别加强；用户需要大规模可扩展的存储做数据分析，那软件定义存储将扮演更重要的角色，计算虚拟化 就可以弱化一些。一切以满足用户需求为前提是软件定义数据中心发展的动力，也是目标。 1.4 架构分析 需求推动着软件定义数据中心一步步完善自己的体系架构，这也充分说明，“软件定义”的必要性不是凭空想象出来的，是由实际的需求推动产生的。回顾之前描述的发展路径，我们已经可以大致归 纳出软件定义数据中心的层次结构，但是思路还不够清晰。因此，有必要从系统分析的角度，清楚地描述一下软件定义数据中心包括哪些部分或层次，以及实现这些组件需要的关键技术和整个系统提供的 交互接口。 1.4.1 基本功能模块 软件定义数据中心最核心的资源是计算、存储与网络，这三者无疑是基本功能模块。与传统的概念不同，软件定义数据中心更强调从硬件抽象出的能力，而并非硬件本身。 对于计算来说，计算能力需要从硬件平台上抽象出来，让计算资源脱离硬件的限制，形成资源池。计算资源还需要能