作者：陈熹
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件定义数据中心：技术与实践试读：
前言
对于IT设备和服务厂商来说，“这是一个最好的时代，也是一个最坏的时代”。一方面，Amazon、Google和层出不穷的初创公司能轻而易举地从资本市场拿到源源不断的投资，似乎根本不用担心成本压力和盈利预期；另一方面，IBM、HP等传统IT巨头不得不焦头烂额地应对业绩的压力、对发展前景的质疑，希望通过转型继续在企业IT市场生存下来。外行人看来，还不是做着一样的生意吗？怎么前两年风生水起的大公司，这么快就裁的裁、撤的撤，纷纷转型自救了？俗话说得好：“形势比人强”。任由你是业界的“巨无霸”，也抵挡不住时代的大潮。这一波拍过来的浪潮无疑就是第三平台。在第三平台的大浪中，移动应用、社交应用、大数据应用是冒头的浪尖，而提供动力的是云计算。
作为第三平台的支柱，云计算吸引了IT厂商最多的资源。因为大家都对第二平台时代Windows操作系统+Intel CPU（简称Wintel）的联盟记忆犹新，谁占据了基础架构平台，谁就能主宰一个时代。在这个问题上，传统IT厂商和互联网背景的IT服务商是有重大分歧的。互联网公司没有老本可吃，也没有历史包袱，他们希望能让用户一步到位，直接上公有云；而传统IT厂商则多立足于现有的产品线，希望能让用户实现从On-premise（IT的本地运营）到off-premise（异地运营，如IDC）到私有云、混合云的过渡。然而无论是哪种云，都会碰到一系列共同的问题：硬件资源利用率、扩展性、自动化管理等。硬件的更新换代需要经年累月的时间，通常很难满足快速发展的业务需求，软件定义才是现实可行的出路。这也是为什么软件定义数据中心迅速成为IT产业的热门关键词的原因。
本书呈现了EMC中国研究院在这一领域多年的研究成果，并在此基础上总结梳理出软件定义数据中心的发展历程和未来方向。在内容组织上，全书分为四个部分：第一部分是总体介绍，试图回答一些关于软件定义数据中心的基本问题，告诉读者“什么是软件定义数据中心”、“为什么需要软件定义”；第二部分深入介绍了软件定义数据中心的关键技术，涵盖了计算、存储、网络、资源管理和调度、安全和高可用性；第三部分在了解了关键技术的基础上，向读者展示了软件定义数据中心可以提供的一些应用场景；第四部分选取了两个软件定义数据中心的实例，一个是面向公有云的AWS，另一个是面向流媒体的PPTV，希望能让读者更有临场感，能看一看现在业界的“大拿们”是怎么“玩”的。
在本书的编写过程中，我们得到了Pivotal公司技术总监Ray Feng先生、我们的前EMC同事的大力支持，Ray对第三平台的精辟论述也出现在了本书第1章。同时感谢PPTV的特约编委们、Ricky的前微软同事们、以PPTV研发副总裁Bill Huang为领导的研发团队的同事们，他们提供了大量第一手资料，并共同编写了一章大型实例。此外，还要感谢EMC中国研发集团总经理Wei Liu和EMC高级总监Xiaoye Jiang在本书编写的过程中给予的大力支持。最后，我们衷心感谢在本书的撰写和出版过程中对我们给予巨大帮助的机械工业出版社华章公司的编辑们，没有她们的辛勤工作和耐心配合，这本书不会成为现实。
由于时间有限，本书的内容难免存在错漏之处，还请各位读者和专家不吝赐教。陈熹、Ricky Sun（孙宇熙）第一部分 总体介绍
第1章 基本概念第1章 基本概念
软件定义数据中心（Softwares Defined Data Center，SDDC）是个新概念。新到什么程度呢？2012年以前还没有人系统阐述它。随着软件定义计算、软件定义存储、软件定义网络等一系列“软件定义”新技术的蓬勃发展，已经有几十年发展历史的数据中心眼看着将要迎来另一场深刻的变革。原有的设备还可以继续运转，但是管理员不再需要频繁出入轰鸣的机房去照看它们；网络不需要重新连线也可以被划分成完全隔离的区域，并且不用担心IP地址之间会发生冲突；在数据中心部署负载均衡、备份恢复、数据库不再需要变动硬件，也不再需要动辄几天的部署测试，管理员只需点几下鼠标，几秒钟就能完成；资源是按需分配的，再也不会有机器长年累月全速运转，而没有人知道上面运行的是什么业务；软件导致的系统崩溃几乎总是不可避免的，但是在系统管理员甚至还没有发现这些问题的时候，它们已经被自动修复了，当然，所有的过程都被记录了下来……
在机房里汗流浃背地摆弄过服务器的网线、光纤线、串口线和各种按钮的系统管理员看到这种情景会是什么心情？回忆起往日给上百台服务器装系统、打补丁时手忙脚乱的画面，如今都已经成了过眼云烟，不免有些悲喜交加。不管是悲是喜，这些事情都正在发生。也许你所接触到的一些计算环境已经开始大规模应用计算虚拟化，但是还在使用传统的以太网和基于IP的网络划分；也许有人已经将存储资源全部抽象成了块存储、文件存储和对象存储，但是还需要大量的手工配置去设置一个备份服务……这不是一场风暴，原有的技术和架构不会在一夜之间被摧毁；这也不是海底火山喷发，信息孤岛不会转眼间就消失。SDDC所涉及的概念、技术、架构、规范都在迅速发展，但又并不同步。我们要展示给大家的是一个日新月异的领域。要想用一两句话为SDDC下一个准确的定义本身就不够严谨。
要了解什么是SDDC，至少要回答以下几个基本的问题：
·SDDC是在什么基础上发展而来的？
·是什么驱动了SDDC的演化？（解决了什么问题？）
·SDDC是由什么组成的？
·SDDC将向何处发展？
接下来，我们先循着技术发展的脉络，看看在SDDC出现之前，已有的计算环境是什么样的。1.1 数据中心的历史
顾名思义，数据中心（Data Center）是数据集中存储、计算、交换的中心。从硬件角度考虑，它给人最直观的印象就是计算设备运作的环境。因此，数据中心的发展是与计算机（包括分化出的存储和网络设备）的发展紧密联系在一起的。
从第一台电子计算机出现开始，这些精密的设备就一直处于严密周到的保护中。由于最早的电子计算机几乎都应用于军事，不对公众开放服务，而且每台计算机所需要的附属设施都是单独设计的，因此参考价值非常有限。
商用计算机的大量应用开始于20世纪60年代，其中最具代表性的是IBM的主机（Mainframe）系列，包括700/7000系列、System/360、System/370、System/390和今天仍占据市场主要份额的System Z。这些都是重达几十吨、占地数百平方米的“大家伙”，与之略显不相称的是这些机器缓慢的计算速度和较小的数据存储规模（仅指20世纪60年代，如今的System Z已经非常强大）。在当时，拥有这样一台计算机是非常奢侈的事，更不要说在一个机房同时部署几台这样的庞然大物。
图1-1中，是20世纪60年代的一个主机机房。一排排的机柜就是计算机的主体，而整个篮球馆一样大小的房间就是当时的数据中心。显而易见，这里仅有一台计算机，因此这个数据中心是不需要如今概念上的网络的，也没有专门的存储节点。从管理角度看，这时候数据中心的管理员是需要精细分工的，有专人管理电传打字机（Teletype），有专人管理纸带录入，有专人管理磁带……可以想象，要运行这台计算机不是一件容易的事情。图1-1 IBM主机所在的机房
值得一提的是，尽管很多与那个年代的数据中心有关的东西都进入博物馆，我们还是可以在现在的计算机上找到一些痕迹。用过UNIX/Linux的读者也许会记得系统中的虚拟终端会用TTY来表示，这就来源于Teletype。
随着大规模集成电路的发展，20世纪80年代开始，大量相对廉价的微型计算机出现了。数据的存储和计算呈现一种分散的趋势，越来越多的微型计算机被部署在政府、公司、医院、学校……绝大多数微型计算机是互不联通的，信息的交换更多依靠磁盘、磁带等介质。到了90年代，计算的操作变得越来越复杂，原有的微型计算机开始扮演客户端的角色，而大型的任务如数据库查询被迁移到服务器端，著名的客户端/服务器模式开始大行其道，这直接推动了数据中心的发展。让我们看看，在经过20世纪50年代至80年代计算机科学理论发展的黄金年代后，计算机工业又经历了怎样的飞速发展。
·1981年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。
……
数据中心再也不是只有一台计算机，机架式服务器的出现，更加大幅度提升了数据中心中服务器的密度。随着越来越多的计算机被堆叠在一起，机器之间的互联就显得日益重要起来。无论是局域网还是广域网，网络技术都在这一时期取得了飞速的发展，为互联网时代打下了坚实的基础。数据中心里的网络设备也从计算机中分化出来，不再是“用于数据交换的计算机”。软件方面，UNIX仍然是数据中心的主流操作系统，但是Linux已经出现，并且在这之后的岁月里展现出了惊人的生命力。
进入21世纪，伴随着互联网的出现和被公众迅速接受，数据中心从技术发展到运行规模，都经历了前所未有的发展高潮。几乎所有的公司都需要高速的网络连接与Internet相连，而且公司的运营对于IT设施的依赖性越来越高，需要不间断运行的服务器支撑公司的业务。试想，如果一家公司的电子邮件系统处于时断时续的状态，如何保证公司的正常运作？然而，每家公司都自行构建这样一套基础架构实在太不划算，也没有这个必要。于是，IDC（Internet Data Center）就应运而生了。这是第一次出现以运营数据中心为主要业务的公司。由于竞争的需要，IDC竞相采用最新的计算机，采购最快速的网络连接设备和存储设备，应用最新的IT管理软件和管理流程，力图使自己的数据中心能吸引更多的互联网用户。不仅仅是IT技术，作为专业的数据中心运营商，IDC为了提高整个系统的可靠性、可用性和安全性，对建筑规范、电源、空调等都做了比以往更详尽的设计。
一个普通的IDC可以有数千台服务器、几个TB的网络带宽、若干PB的存储。99.99%的初级程序员和系统分析员都会觉得这已经够大了，只要把应用不断部署进去就可以了。而且，服务器、存储、网络带宽都还有扩充的余地，IDC就像汪洋大海一样，永远不会被用尽。区别只是需要把应用部署在哪个IDC中。这就像当时设计IPv4协议时对待IP地址的态度：IP地址太多了，足够了。IPv4的主地址池好歹分了30年才分完，而孤立的IDC还没有撑过10年就已经进入了互连互通的时期。没办法，总有那么些新东西是我们预见不到的。IPv4的地址会迅速枯竭，主要是因为设计者没有预见到互联网用户的激增和各种移动设备的出现。对于IDC来说，推动互连互通的主要是这样一些需求：
1）跨地域的机构需要就近访问数据和计算能力。例如，许多跨国公司在中国的研发中心，几千人不可能都远程登录到总部的数据中心工作，浪费昂贵的国际流量还在其次，关键是用户体验达不到要求。这些研发中心都有本地的数据中心，并且与公司位于其他国家的数据中心有统一的网络规划、管理流程。
2）越来越大的分布式应用。例如，作为谷歌存储系统核心的GFS，运行在几乎所有的服务器中。较大的GFS跨数千台机器，看起来还可以勉强“塞”进某个数据中心，可惜这样的大文件系统不是一个两个……
3）云计算的出现。与前两个不同，云计算的出现是推动IDC向CDC（Cloud Data Center）发展的最关键因素。提到云计算，就不能不提亚马逊的AWS（Amazon Web Service）。亚马逊在以下地区都有大型数据中心，以支撑AWS的服务：
·爱尔兰的都柏林
·新加坡的新加坡市
·美国的加利福尼亚州帕罗奥图（Palo Alto）
·美国的弗吉尼亚州阿什本（Ashburn）
·日本的东京
·澳大利亚的悉尼
由于这些因素的推动，数据中心之间的联系变得更紧密。不同数据中心的用户不会觉得自己是在一个孤立的环境中，因为跨数据中心的计算资源、存储空间、网络带宽都可以共享，管理流程也很相近。这让所有用户感觉自己工作在一个巨大、统一的数据中心中。多么巨大的应用也不再是问题。需要更多服务器？扩展到下一个空闲的数据中心吧。不仅仅需要物理机器，而是需要把虚拟机在全球范围内迁移？这也能办到，亚马逊已经在这么做了。
回过头看看数据中心的发展历史，如图1-2所示，数据中心中机器的数量从一台到几千几万台，似乎是朝着不断分散的目标发展。但是从管理员和用户的角度看，访问大型机上的计算资源是从一个大的资源池中分出一块，访问云数据中心中的计算资源也是如此。用户体验经历了集中——分散——集中的发展过程。新的集中访问资源的模式和资源的质量都已经远远超越了大型机时代。从一台机器独占巨大的机房，到少量计算机同时各自提供服务，再到无数的机器可以高速互通信息、同时提供服务，可以分配的资源被越分越细，数据中心的密度也越来越高。有趣的是，管理数据中心的人员并没有增长得这么快。网络的发展让管理员可以随时访问数据中心中任何一台机器，IT管理软件帮助管理员可以轻松管理数千台机器。如果管理员不借助专业IT管理软件，一个人管理几十台机器就已经手忙脚乱了。从这个角度看，传统的数据中心是“软件管理的数据中心”。图1-2 数据中心的发展1.2 继续发展的推动力
的确，“软件管理的数据中心”已经发展得非常完善了，仅就可管理的硬件数量而言并没有迅速发展的必要，场地维护、电力、空调等基础设施的管理也成熟到足够在一个数据中心容纳数万台机器。例如雅虎（Yahoo！）在美国纽约州建设的数据中心拥有约2800个机柜，足以容纳5万台到10万台服务器同时工作，DCIM（Data Center Infrastructure Management）系统会监控每一台服务器的运行状态，确保整个数据中心没有一台机器会热得烧起来（服务器自身也有温度控制系统，这种情况很少发生），确保UPS在风暴来临而突然断电的时候能正确切换到工作负载上。虽然亚马逊的数据中心在2012年出过一点小差错，但是绝大部分时间里，这些系统是工作得很好的。
照理说，数据中心的管理人员应该比以往任何时候都要轻松。如果没有什么需要继续改进，那就按照现在的模式，再多建几座数据中心，就能解决所有的问题了。这对于数据中心基础设施的管理员来说应该是好事，而系统管理员却并不这么想。让我们来看看有什么样的麻烦困扰着系统管理员。1.机器实在太多
如果只是把机器堆在机房里还好，可是想想看给1000台机器配置好操作系统、配置好网络连接、登记在管理系统内、划分一部分给某个申请用户使用，或许还需要为该用户配置一部分软件……这看起来实在是劳动密集型任务。想想谷歌吧，它经常需要部署一个数千节点的GFS环境给新的应用，那么是不是需要一支训练有素、数量庞大的IT劳务大军？2.机器的利用率太低
Mozilla数据中心的数据让人有些担心。据称，Mozilla数据中心的服务器CPU占用率在6%~10%之间。也许这与应用的类型有关，例如在提供分布式文件系统的机器上CPU就很空闲，与之对应的是内存和I/O操作很繁忙。如果这只是个例，就完全没有必要担心，但服务器利用率低下恰恰是一个普遍存在的问题。一个造价昂贵的数据中心再加上数额巨大的电费账单，最后却遗憾地发现只有不到10%的资源被合理利用了，剩下超过90%是用来制造热量的。别忘了，散热还需要花一大笔钱。3.应用迁移太困难
只要摩尔定律还在起作用，硬件的升级换代就还是那么快。对于数据中心来说，每隔一段时间就更新硬件是必须的。困难的不是把服务器下架，交给回收商，而是把新的服务器上架，按以前一样配置网络和存储，并把原有的应用恢复起来。新的操作系统可能有驱动的问题，网络和存储可能无法正常连接，应用在新环境中不能运行……最后很可能不得不请工程师到现场调试，追踪问题到底是出在硬件、软件上，还是哪个配置选项没有选中。4.存储需求增长得太快
2012年全球产生的数据总量约为2.7ZB（1ZB=1万亿GB），相比2011年增长了48%。即使不考虑为了存储这些数据需要配备的空闲存储，也意味着数据中心不得不在一年内增加50%左右的存储容量。用不了几年，数据中心就会堆满了各种厂家、各种接口的存储设备。管理它们需要不同的管理软件，而且常常互相不兼容。存储设备的更新比服务器更关键，因为所存储的数据可能是我们每个人的银行账号、余额、交易记录。旧的设备不能随便换，新的设备还在每天涌进来。学习存储管理软件的速度也许还赶不上存储设备的增长。
问题绝不仅仅只有这么几点，但是我们已经可以从这些例子得到一些启示。像以往数据中心的发展一样，首先是应用的发展推动了数据中心的发展。之前提到的超大型分布式系统和云计算服务平台都是类似的应用。我们在后面还会介绍更多这样的应用场景。这些应用有一个共同的特点，没有任何悬念，它们需要比以往更多的计算、存储、网络资源，而且需要灵活、迅速的部署和管理。为了满足如此苛刻的要求，仅仅增加机器已经无济于事了。与此同时，人们“终于”发现数据中心的服务器利用率竟然只有不到10%。但是应用迁移却如此困难，明知有些机器在99.9%的时间都空闲，却不得不为了那0.1%的峰值负荷而让它们一直空转着。如果说服务器只是有些浪费，还勉强说得过去的话，存储就更让人头疼了。数据产生的速度越来越快，存储设备要么不够，要么实在太多无法全面管理……1.3 软件定义的必要性
正是因为有了上述挑战，无论是数据中心的管理员，还是应用系统的开发人员，或是最终用户，都意识到将数据中心的各个组成部分从硬件中抽象出来、集中协调与管理、统一提供服务的重要性。如图1-3所示，在传统的数据中心中，如果我们需要部署一套业务系统，例如文件及打印服务，就要为该业务划分存储空间，分配运行文件及打印服务的服务器，配置好服务器与存储的网络。图1-3 传统数据中心中的资源
这需要多长时间呢？这可没准。不同的计算中心都有各自的管理流程，大多数情况下都要先向IT管理员提交一个请求，注明需要哪些资源。IT管理员拿到这个请求之后，会在现有的资源列表中寻找适合的服务器、存储、网络资源。假设运气很好，不需要额外采购就能满足文件服务器的要求，最快也需要1~2天的时间。如果碰到现有的资源数量和质量无法满足需求，那就继续等待吧，询价、采购、发货、配置上线……这么折腾下来，不经过十天半个月的等待，怕是根本没办法开始部署业务系统。对于一个文件及打印服务来说，等一下也无可厚非，实在不行可以把数据暂时存储在U盘里，再凑合使用旧的打印服务器。可是如果一家公司的核心业务系统紧急需要资源怎么办？2012年开始在国内炒得火热的双十一促销是各个电商平台的整体较量，对它们来说都是重头戏。可万事开头难，就在2012年11月11日这一天，淘宝和京东的后台系统从飞速变成了“龟速”。京东的CEO刘强东微博回应：紧急采购服务器扩容！先不说业务系统的设计是否支持这样迅速的扩容，单就IT资源的管理角度，如果这样的业务需要等上几天，那双十一大战是必然要落败了。公司高层领导当然可以省却许多繁琐的流程，但是服务器也不可能“飞”到京东的机房来，无论如何都已太慢。
从图1-3还可以看到，如果有6个业务系统，就需要6套服务器，这很合理。在生产环境的服务器上再部署、调试其他业务只会带来更多的麻烦，而且实际上，文件打印这些服务需要的计算能力很弱，数据库系统需要很大的内存和非常好的I/O能力，高性能计算需要强大的CPU。显而易见，为不同的业务采购不同配置的服务器是必需的，而且对于各项性能的要求几乎完全来自于估计，没有人会确切地知道是否需要256GB的内存而不是128GB。因此，IT管理员需要面对的就是千奇百怪的配置表和永远无法清楚描述的性能需求。因此IT管理员在采购硬件的时候自然而然会采取最安全的策略：尽量买最好的。这就出现了上文提到过的问题：服务器的利用率低得惊人。
高端的存储可以较好地实现存储资源池，并且理论上可以同时支持所有的应用。但是把EMC的高端存储用来支持打印服务器，似乎显得太奢侈了。实际情况下，这些业务系统会至少共享2~3种存储设备。每个子系统都使用各自的子网，但是一个网段分给了某项业务，即使并不会被用完，其他系统也不能再用了。
幸好虚拟化技术重新回到了人们的视野当中。在计算机发展的早期，虚拟化技术其实就已经出现了，当时是为了能够充分利用昂贵的计算机。数十年后，虚拟化技术再一次变成人们重点关注的对象，这依然跟提高资源的利用效率有密不可分的关系。而且这次虚拟化技术不仅在计算节点上被广泛应用，相同的概念也被很好地复制到了存储、网络、安全等与计算相关的方方面面。虚拟化的本质是将一种资源或能力以软件的形式从具体的设备中抽象出来，并作为服务提供给用户。当这种思想应用到计算节点，计算本身就是一种资源，被以软件的形式——各种虚拟机从物理机器中抽象出来——按需分配给用户使用。虚拟化思想应用于存储时，数据的保存和读写是一种资源，而对数据的备份、迁移、优化等控制功能是另一种资源，这些资源被各种软件抽象出来，通过编程接口（API）或用户界面提供给用户使用。网络的虚拟化也是这样，数据传输的能力作为一种资源，被网络虚拟化软件划分成互相隔离的虚拟网络，提供如OpenFlow这样的通用接口给用户使用。当主要的基础资源如计算、存储、网络被充分虚拟化之后，数据中心的逻辑结构将如图1-4所示。图1-4 虚拟化的计算、存储、网络
资源的可用性是原生的，是买来这些设备时就已经具备的。但是如何发挥其使用效果，却要靠创新的思路和方法。我们可以看到，当服务器虚拟化之后，计算能力就可以真正做到“按需分配”，而不是必须给每种服务配置物理的机器。过去的IT管理员当然也希望能够做到“按需”而不是“按业务”分配，但是没有虚拟化技术，没有人会愿意冒风险把可能互相影响的系统放在同一台服务器上。存储也被虚拟化了。用户不用再关心买了什么磁盘阵列，每个阵列到底能够承载多少业务，因为他们看到的将是一个统一管理的资源池，资源池中的存储按照容量、响应时间、吞吐能力、可靠性等指标被分成了若干个等级。系统管理员可以“按需”从各个资源池中分配和回收资源。虚拟的网络可以“按需”增减和配置，而不需要动手配置网络设备和连线。能做到这一步，至少就能够解决以下问题：
·资源的利用效率低下，不能充分利用硬件的能力。
·资源的分配缺乏弹性，不能根据运行情况调整投入。
·在提供基础设施服务时，必须考虑不同硬件的性能。
·需要改变配置时，不得不重新连线和做硬件配置的调整。
需要特别注意的是，在虚拟化这一概念中，利用软件来抽象可用的资源这一点尤为重要，因为这样才能实现资源与具体硬件的分离（Decouple），从而使进一步发展数据中心成为可能。这也是“软件定义数据中心”的由来。
当主要的资源都已经虚拟化，“软件定义”还并没有实现，这是因为虚拟化在解决大量现有问题的同时，也带来一些新的挑战。
首先，虚拟化让资源得以按需分配和回收，这使得资源的管理更加精细。不仅如此，管理的对象也发生了变化。传统的数据中心资源管理以硬件为核心，所有的系统和流程根据硬件使用的生命周期来制定。当资源虚拟化之后，系统管理员不仅需要管理原有的硬件环境，而且新增加了对虚拟对象的管理。虚拟对象的管理兼有软件和硬件的管理特性。从用户的使用体验来说，虚拟对象更像硬件设备，例如服务器、磁盘、专有的网络等；而从具体的实现形式和收费来说，虚拟对象却是在软件的范畴里。为了适应这种改变，资源管理要能够将虚拟对象与硬件环境甚至更上层的业务结合起来，统一管理。
虚拟化令资源的划分更加细致，不仅带来了管理方式上的挑战，被管理对象的数量也上升了至少一个数量级。原本一台服务器单独作为一个管理单位，现在虚拟机变成了计算的基本管理单位。随着多核技术的发展，如今非常普通的一台物理服务器可以有2个CPU，每个CPU上有8个物理计算核心（Core），每个计算核心借助超线程技术可以运行2个线程，因而也可以被认为是2个虚拟CPU。因此，一台物理服务器上往往可以轻松运行15~30个虚拟机实例。存储的例子更加明显。传统的存储设备为物理机器提供服务，假设每台机器分配2个LUN（逻辑单元号）作为块存储设备，如今虚拟化之后需要分配的LUN也变成原来的几十倍。不仅如此，因为存储虚拟化带来的资源的集中管理，释放了许多原来不能满足的存储需求，因此跨设备的存储资源分配也变成了现实。这使得存储资源的管理对象数量更加庞大了。网络的数量恐怕不用赘述了。想想看为什么大家不能满足于VLAN，而要转向VxLAN。一个很重要的因素是VLAN tag对虚拟网络有数量的限制，4096个网络都已经不够了（详见第4章）。要管理数量巨大的虚拟对象，仅仅依靠一两张电子表格是完全应付不了的，连传统的管理软件也无法满足要求。例如，某知名IT管理软件在导航栏里有一项功能，用列表的方式列出所有服务器的摘要信息。在虚拟化环境中试用时，由于虚拟服务器数量太多，导致浏览器无法响应，不得不“恳请”用户不要轻易使用。
虚拟环境带来的另一个挑战是安全。这里既有新瓶装老酒的经典问题，也有虚拟化特有的安全挑战。应用运行在虚拟机上和运行在物理服务器上都会面临同样的攻击，操作系统和应用程序的漏洞依然需要用传统的方式来解决。好在如果某个应用在虚拟机上崩溃了，不会影响物理服务器上其他应用继续工作。从这点来看，虚拟化确实提高了计算的安全性。虚拟化的一个重要特点是多用户可以共享资源，无论是计算、存储、网络，共享带来的好处显而易见，然而也带来了可能互相影响的安全隐患。例如，在同一台物理服务器上的虚拟机真的完全不会互相影响吗？早期，亚马逊的AWS就出现过某些用户运行计算量非常大的应用，而导致同一台物理机器上的其他虚拟机用户响应缓慢的情况。存储的安全性就更关键了。如果你在一个虚拟存储卷上存放了公司的财务报表，即使你已经想尽办法删除了数据，你还是会担心如果这个卷被分配给一个有能力恢复数据的人，就会存在安全隐患。
可见，仅仅将资源虚拟化，只是解决问题的第一步。对虚拟对象的管理是下一步要完成的任务。如图1-5所示，新的资源管理和安全并不是着眼于物理设备的，而是把重点放在管理虚拟对象上，使虚拟环境能够真正被系统管理员和用户所接受。图1-5 新的资源管理与安全
当虚拟资源各就各位，管理员动动鼠标就能够安全地分配、访问、回收任何计算、存储、网络资源的时候，数据中心就可以算得上是完全被软件接管了。可是这并不意味着软件定义数据中心已经能够发挥最大的作用。因为资源虽然已经虚拟化，纳入了统一管理的资源池，可以随需调用，但是什么时候需要什么样的资源还是要依靠人来判断，部署一项业务到底需要哪些资源还是停留在技术文档的层面。数据中心的资源确实已经由软件来定义如何发挥作用，但是数据中心的运行流程还没有发生根本改变。以部署MySQL数据库为例，需要2个计算节点、3个LUN和1个虚拟网络。知道了这些还远远不够，在一个安全有保证的虚拟化环境中，管理员要部署这样一个数据库实例需要完成以下流程：
不难发现，除了使用的资源已经被虚拟化，这套流程并没有任何新意。当然，是否有新意并不重要，重要的是好用、能解决问题。看起来这样的流程并不复杂。那让我们再考虑一下，仅仅部署一个MySQL数据库常常不是最终的目标，要提供一个能面向用户的应用，还需要更多的组件加入进来。假设我们需要部署一个移动应用的后台系统，包括一个MySQL数据库、Django框架、日志分析引擎，按照上面的流程，工作量就至少是原来的3倍。如果我们需要为不同的用户部署1000个移动应用的后台系统呢？
回过头来想想，既然资源都已经虚拟化并且置于资源池中，管理员对虚拟资源理应有更大的控制权，那么在部署虚拟机的时候，自然可以在模板中留下一些辅助配置的“后门”。不仅仅是虚拟机，存储和网络虚拟化提供的接口也提供了类似的配置功能。既然可以用“后门”间接控制虚拟资源被分配后的配置，那将整个流程自动化就是顺理成章的事情了。管理员需要做的是经过实验，事先定义一套工作流程，按照流程管理系统的规则将工作流程变成可重复执行的配置文件，在实际应用的时候配置几个简单的参数即可。经过自动改造的MySQL部署流程将变成：
在这个过程中，如果需要部署的流程并不需要特殊的参数，而是可以用预设值工作，甚至可以做到真正的“一键部署”，那么软件定义数据中心就可以显示出强大的优势了。不仅仅资源的利用可以做到按需分配，分配之后如何配置成用户熟悉的服务也将能够自动完成。
如果你需要的是几台虚拟机，现在已经能够轻松做到了；如果你需要的是同时分配虚拟机、存储和网络，现在也能够做到了；如果你还需要把这些资源包装成一个数据库服务，现在也只需要动动手指就能完成。程序员们应该已经非常满足，管理员也完全有理由沾沾自喜了。毕竟，之前要汗流浃背重复劳动几天的工作，现在弹指间就可以全部搞定。可是对于那些要使用成熟应用的终端用户来说，这和以前没有什么区别。例如，等待CRM（Customer Relation Management）系统上线的用户，并不真正在意如何分配资源，如何建立数据库，唯一能让他们感到满意的是能够登录CRM系统，开始使用这个系统管理用户信息。
要解决这个问题，让应用真正能面向用户，可以有几种方法。在这个阶段，数据中心的资源已经不是单纯跟资源管理者有关系了，而是与用户的应用程序产生了交集。相应的，无论我们采用哪一种方法去建立应用程序的运行环境，也都必须视应用本身的特性而定。如表1-1所示，第一种方法是发展了自动部署数据库的流程，将这套流程扩展到部署用户的应用，同样还是利用自动化的流程控制来配置用户程序。第二种是部署一套PaaS（Platform as a Service）的环境，将用户程序运行在PaaS之上。第三种看起来更简单，让用户自己设计自动部署的方法，是否集成到数据中心的管理环境中则视情况而定。表1-1 运行环境自动部署方法比较
各种方法都有其适用的场景，并不能一概而论，这是数据中心的基础架构面向用户的关键一步。如果说之前的虚拟化、资源管理、安全设置、自动化流程控制都还是数据中心的管理员关心的话题，那部署应用这一步已经实实在在把花了钱、买了这些服务的用户拉进来了。在成功部署了应用之后，软件定义数据中心才算是真正自底向上地建立了起来。
如图1-6所示，软件定义数据中心是一个从硬件到应用的完整框架。用户的需求永远是技术发展的原动力，软件定义数据中心也不例外。我们在上文中提到了数据中心在云与大数据的年代面临的诸多挑战，传统数据中心的计算、存储、网络、安全、管理都已无法应对日益变化的用户需求。在这种四面楚歌的状况下，软件定义计算（或称计算虚拟化）作为一种既成熟又新颖的技术，成为了解决困局的突破口。随之而来的是软件定义存储和网络技术。在资源的虚拟化已经完成之后，虚拟环境中的安全与管理需求变成了第二波创新的主题。在这之后，数据中心的自动化流程控制进一步释放了软件定义技术的潜在威力，让管理员不踏足机房就能够如同指挥千军万马一般调配成千上万的虚拟机配置数据库、文件服务、活动目录等服务，甚至可以更进一步，自动部署成熟的用户程序提供给用户使用。图1-6 支持具体应用的软件定义数据中心
软件定义数据中心是应用户需求而发展的，但并不是一蹴而就地满足了用户的初始需求。“非不为也，实不能也”。软件定义数据中心是一项庞大的系统工程，基础如果不稳固，仓促地提供服务只会带来严重的后果。云计算服务就是个很好的例子。云计算服务的后端无疑需要强大的软件定义数据中心做支撑。国内有数家学习亚马逊的企业，本着“一手抓学习，一手抓运营”的精神，在技术并不成熟的情况下，“勇敢”地向大家提供云计算服务，但是计算的稳定性、存储的可靠性、网络的可用性都暴露出了许多问题，用户体验实在无法让人满意。
当然，并不是任何一个软件定义数据中心都需要完全如上文所述，搭建从硬件到用户的完整框架，也不是所有可以称为软件定义数据中心的计算环境都具备上文所述的所有功能。一切还是应用说了算。例如，用户可能仅仅需要虚拟桌面服务并不需要复杂的虚拟网络，但是安全和自动控制流程要特别加强；用户需要大规模可扩展的存储做数据分析，那软件定义存储将扮演更重要的角色，计算虚拟化就可以弱化一些。一切以满足用户需求为前提是软件定义数据中心发展的动力，也是目标。1.4 架构分析
需求推动着软件定义数据中心一步步完善自己的体系架构，这也充分说明，“软件定义”的必要性不是凭空想象出来的，是由实际的需求推动产生的。回顾之前描述的发展路径，我们已经可以大致归纳出软件定义数据中心的层次结构，但是思路还不够清晰。因此，有必要从系统分析的角度，清楚地描述一下软件定义数据中心包括哪些部分或层次，以及实现这些组件需要的关键技术和整个系统提供的交互接口。1.4.1 基本功能模块
软件定义数据中心最核心的资源是计算、存储与网络，这三者无疑是基本功能模块。与传统的概念不同，软件定义数据中心更强调从硬件抽象出的能力，而并非硬件本身。
对于计算来说，计算能力需要从硬件平台上抽象出来，让计算资源脱离硬件的限制，形成资源池。计算资源还需要能够在软件定义数据中心范围内迁移，这样才能动态调整负载。虽然虚拟化并不是必要条件，但是目前能够实现这些需求的，仍非虚拟化莫属。对存储和网络的要求则首先是控制层（Control Plane）与数据层（Data Plane）的分离，这是脱离硬件控制的第一步，也是能够用软件定义这些设备行为的初级阶段。在这之后，才有条件考虑如何将控制层与数据层分别接入软件定义数据中心。安全越来越成为数据中心需要单独考量的一个因素。安全隐患既可能出现在基本的计算、存储与网络之间，也有可能隐藏在数据中心的管理系统或者用户的应用程序中。因此，有必要把安全单独作为一个基本功能，与以上3种基本资源并列。
有了这些基本的功能还不够，还需要集中的管理平台把它们联系在一起。如图1-7所示，自动化的管理是将软件定义数据中心的各基本模块组织起来的关键。这里必须强调“自动化”管理，而不只是一套精美的界面。原因我们前面已经提到，软件定义数据中心的一个重要推动力是用户对于超大规模数据中心的管理，“自动化”无疑是必选项。图1-7 软件定义数据中心功能划分1.4.2 层次细分
了解了软件定义数据中心有哪些基本功能后，我们再看一下这些基本功能是怎样按照层次化的定义逐级被实现并提供服务的。分层的思路其实已经出现在关于“软件定义的必要性”的探讨中，之所以出现这样的层次，并不是出于自顶向下的预先设计，而是用户需求推动的结果。现实中无数的例子告诉我们，只有用户的需求或者说市场的认可才是技术得以生存和发展的原动力。
如图1-8所示，在软件定义数据中心最底层是硬件基础设施，主要包括服务器、存储和各种网络交换设备。软件定义数据中心对于硬件并没有特殊的要求。服务器最好能支持最新的硬件虚拟化并具备完善的带内（In Band）、带外（Out of Band）管理功能，这样可以最大限度提升虚拟机的性能和提供自动化管理功能。但是，即使没有硬件虚拟化的支持，服务器一样可以工作，只是由于部分功能需要由软件模拟，性能会稍打折扣。这说明软件定义数据中心对于硬件环境的依赖性很小，新的旧的硬件都可以统一管理，共同发挥作用。另外，当更新的硬件出现时，又能够充分发挥新硬件的能力，也让用户有充足的动力不断升级硬件配置，以求更好的性能。图1-8 软件定义数据中心的分层模型
在传统的数据中心，硬件之上应该就是系统软件和应用软件了。但是在软件定义数据中心里，硬件的能力需要被抽象成为能够统一调度管理的资源池，因此，必须有新技术完成这一工作。计算、存储和网络资源的抽象方式各不相同，在这一层次，主要有以下一些关键技术可以帮助我们完成虚拟化和“池化”（Pooling）的工作。更多的技术细节在后续章节会有详细的介绍。
·软件定义计算：虚拟化是软件定义计算最主要的解决途径。虽然类似的技术早在IBM S/360系列的机器中已经出现过，但是其真正“平民化”、走入大规模数据中心还是在VMware推出基于x86架构处理器的虚拟化产品之后。随后，还有基于XEN、KVM等的开源解决方案。虚拟机成为计算调度和管理的单位，可以在数据中心甚至跨数据中心的范围内动态迁移而不用担心服务会中断。
·软件定义存储：主流的技术方案是管理接口与数据读写实现分离，由统一的管理接口与上层管理软件交互，而在数据交互方面，则可以兼容各种不同的连接方式。这种方式可以很好地与传统的软硬件环境兼容，从而避免“破坏性”的改造。例如EMC的ViPR既能够支持光纤通道（Fiber Channel）的连接，也支持基于以太网技术的iSCSI等多种不同的协议。如何最合理地利用各级存储资源，在数据中心的级别上提供分层、缓存也是需要特别考虑的。
·软件定义网络：同软件定义存储一样，管理接口与数据读写首先要分离。由软件定义的不仅仅是网络的拓扑结构，还可能有层叠的结构。前者可以利用开放的网络管理接口例如OpenFlow来完成，后者则可能是基于VxLAN的层叠虚拟网络。
当服务器、存储和网络已经被抽象成虚拟机、虚拟存储对象（块设备、文件系统、对象存储）、虚拟网络，回到图1-8我们可以发现各种资源在数量上和表现形式上都与硬件有明显的区别。这个时候，数据中心至多可以被称为“软件抽象”的，但还不是软件定义的。因为各种资源现在还无法建立起有效的联系。要统一管理虚拟化之后的资源，不仅仅是将状态信息汇总、显示在同一个界面，而是需要能够用一套统一的接口更进一步集中管理这些资源。例如VMware的vCenter和vCloud Director系列产品能够让用户对数据中心中的计算、存储、网络资源进行集中管理，如图1-9所示，并能提供权限控制、数据备份、高可靠等额外的特性。图1-9 vCenter对资源的集中管理
比资源管理更贴近最终用户的是一系列的服务，如图1-8所示，可以是普通的邮件服务、文件服务、数据库服务，也可以是针对大数据分析的Hadoop集群等服务。对于配置这些服务来说，软件定义数据中心的独特优势是自动化。例如VMware的vCAC（vCloud Automation Center）就可以按照管理员预先设定的步骤，自动部署从数据库到文件服务器的几乎任何传统服务。绝大多数部署的细节都是预先定义的，管理员只需要调整几个参数就能完成配置。这对于在Linux环境中安装过Oracle数据库的工程师来说，简直如同梦幻一般。即使有个别特殊的服务（例如用户自己开发的服务）没有事先定义的部署流程，但也可以通过图形化的工具来编辑工作流程，并且反复使用。
从底层硬件到提供服务给用户，资源经过了分割（虚拟化）、重组（资源池）、再分配（服务）的过程，增加了许多额外的层次。从这个角度看，“软件定义”不是没有代价的，但层次化的设计有利于各种技术并行发展和协同工作。这与网络协议的发展非常类似。TCP/IP协议簇正是因为清晰地定义了各协议层次的职责和互相的接口，才使参与各方都能协同发展。研究以太网的可以关注提高传输速度和链路状态的维护，研究IP层的则可以只关心与IP路由相关的问题。让专家去解决他们各自领域内的专业问题，无疑是效率最高的。软件定义数据中心的每一个层次都涉及许多关键技术。回顾一下上文的层次结构，我们可以发现，有些技术由来已久，但是被重新定义和发展了，例如软件定义计算、统一的资源管理、安全计算和高可靠等；有些技术则是全新的，并仍在迅速发展，例如软件定义存储、软件定义网络、自动化的流程控制。这些技术是软件定义数据中心赖以运转的关键，也是软件定义数据中心的核心优势。本书的第2章将对这些关键技术加以深入讨论。1.4.3 接口与标准
任何一个复杂的系统都应该可以被划分成若干个模块，既方便开发也方便使用和维护。按照相同的逻辑，复杂的模块本身也是一个系统，又可以被继续细分。在模块和层次划分的过程中，只要清晰地定义了模块、层次之间的接口，就不必担心各部分无法联合成一个整体。我们已经列举了软件定义数据中心的模块和层次，下面再看看不同的具体实现采用了哪些接口。作为数据中心发展的新阶段，软件定义数据中心在快速发展，但还没有出现一种统一的或是占主导优势的标准。我们可以从成熟度和开放性两个方面，对一些接口标准作个比较，如表1-2所示。表1-2 接口标准比较
从对比我们可以看到，这几个可以用于构建软件定义数据中心的软件集在编程接口（API）的成熟度和开放程度上各有特点。作为针对企业级部署的成熟产品，VMware和微软的产品从接口上看都提供更丰富全面的功能，发展方向也有迹可循。作为开源解决方案代表的OpenStack则采用了“野蛮生长”的策略，例如Neutron（原名Quantum）最初发布的版本简陋得几乎无法使用，但是不到半年，提供的API就能够驱动NVP等强大的网络控制器。迅速迭代的代价就是用户始终难以预计下一版本是否会变动编程接口，影响了用户对OpenStack的接受度。1.5 现状与发展
说了这么多数据中心发生的变化，固然激动人心，但是视角仍略显单一。单单从技术角度考量，历史上许多优秀的技术革新与发明创造都具有划时代的意义，但其中很多却没有如大家预期产生应有的影响，或者拖延了很久才重新被人们所认识。例如RISC架构的处理器设计、虚拟化技术、瘦客户机、分布式文件系统等，数不胜数。因此，我们不妨暂时走出纯技术的思路，站在旁观者的角度看一下产业界是如何看待和发展软件定义数据中心的。
在对待软件定义数据中心的态度上，用户是最积极的。这里所说的用户，并不是每天逛淘宝的买家，也不是拿着手机不停刷微博、微信的“准网瘾患者”，而是运行这些应用的服务提供商。这些“用户”传统上会租用成熟的数据中心，把自己的服务器、存储托管在数据中心的机房。这种模式的优势显而易见，数据中心会负责机房管理、日常维护、电力供应、防火、空调等自己擅长的工作，保证硬件设备的最大可用性；同时，应用服务提供商可以专注维护他们自己的应用系统。但是好景不长，数据中心的大客户们很快发现随着自己业务的增长，已经没有一个单独的数据中心能满足自己的需求了，而软件、硬件的采购与部署也日益成为业务发展的瓶颈。2012年谷歌在全球有数十万台服务器为用户提供服务，并且每天在全球各地的数据中心都有以机柜计数的服务器上架运行，以至于谷歌的基础架构设计师也无法确切知道到底全球有多少台服务器在为它服务。
面临急剧增长的计算需求，这些往日数据中心的大客户不得不自己动手定制数据中心。谷歌是这一潮流的先行者。有趣的是，它将自己的数据中心技术作为公司的核心机密。据称，谷歌与接触数据中心技术的雇员签订了保密协议，即使这些雇员离职，一定期限内也不能透露其数据中心的技术细节。社交网络巨头Facebook也清楚地意识到下一代数据中心技术对于未来互联网乃至整个IT技术发展至关重要的意义。与谷歌不同，Facebook并没有试图包揽从数据中心硬件到软件的所有设计，而是拉来了很多合作伙伴，并把自己数据中心的设计“开源”出来变成了“开放计算项目”（Open Compute Project，OCP）。OCP并不仅限于软硬件设计，还包括数据中心的建筑规范、电力、制冷、机架机械设计等内容，是一份建设数据中心的蓝图。国内的互联网和IT巨头也在发展自己的数据中心技术。由BAT（百度、阿里巴巴、腾讯）发起的“天蝎计划”（Scorpio）主要包括一套开放机架设计方案，目标是提供标准化的计算模块，能够迅速部署到数据中心提供服务。他们的共同特点是模块化的设计和为大规模迅速部署做出的优化。细心的读者可能会发现，在这些标准中，涉及软件的部分很少。这么大规模的硬件部署，是如何管理的呢？是不是在下一个版本的文档发布时就会说明了？非常遗憾，这正是互联网巨头们的核心机密。
系统集成商和服务提供商对于数据中心发展的看法与传统的数据中心用户略有不同，而且并不统一。IBM和HP这类公司是从制造设备向系统和服务转型的例子。在对待下一代数据中心的发展上，这类公司很自然地倾向于能够充分发挥自己在设备制造和系统集成方面的既有优势，利用现有的技术储备引导数据中心技术的发展方向。
微软作为一个传统上卖软件的公司，在制定Azure的发展路线上也很自然地从PaaS入手，并且试图通过“虚拟机代理”技术（VM Agent and Background Info Extension）模糊PaaS和IaaS（Infrastructure as a Service）之间的界限，从而充分发挥自身在软件平台方面的优势来打造后台由System Center支撑、提供PaaS服务的数据中心。最后还有一个特例。几年以前，某家公司跟IT服务还不沾边，勤勤恳恳卖了多年的书，赚了些钱，又继续卖了许多年的百货商品，突然有一天，它开始卖计算和存储能力了。没错，这就是亚马逊。之所以不把亚马逊作为谷歌、Facebook一样的数据中心的用户，是因为AWS（Amazon Web Service）虽然脱胎于亚马逊的电子商务支撑平台，但是已经成为一套独立的业务发展了。作为特例的亚马逊有特别的思路：“需要数据中心服务吗？来用AWS公有云吧。”
最后还有传统的硬件提供商。Intel作为最主要的硬件厂商之一，为了应对巨型的、可扩展的、自动管理的未来数据中心的需要，也提出了自己全新架构的硬件——RSA（Rack Scale Architecture）。在软件、系统管理和服务层面，Intel非常积极地与OCP、天蝎计划、OpenStack等组织合作，试图在下一代数据中心中仍然牢牢地占据硬件平台的领导地位。从设计思路上，RSA并不是为了软件定义数据中心而设计，恰恰相反，RSA架构希望能在硬件级别上提供横向扩展（Scale-Out）的能力，避免“被定义”。有趣的是，对RSA架构很有兴趣的用户发现，硬件扩展能力更强的情况下，软件定义计算、存储与网络正好可以在更大的范围内调配资源。
通过概览未来数据中心业务的参与者，我们可以大致梳理一下软件定义数据中心的现状与发展方向。
·需求推动，有先行者。未来数据中心的需求不仅是巨大的，而且是非常迫切的，以至于本来数据中心的用户们等不及，必须自己动手建立数据中心。而传统的系统和服务提供商则显得行动不够迅速。这有些反常，但却又非常合理。以往用户对数据中心的需求会通过IDC的运营商传达给系统和服务提供商，因为后者对于构建和管理数据中心更有经验，相应的能提供性价比更高的服务。然而，新的、由软件定义数据中心是对资源全新的管理和组织方式，核心技术落在“软件”上，那些传统的系统和服务提供商在这一领域并没有绝对的优势。数据中心的大客户们，例如谷歌、Facebook、阿里巴巴本身在软件方面恰恰有强大的研发实力，并且没有人比他们更了解自己对数据中心的需求，于是他们干脆自己建造数据中心就是很自然的事了。
·新技术不断涌现，发展迅速。软件定义数据中心发端于服务器虚拟化技术。从VMware在2006年发布成熟的面向数据中心的VMware Server产品到本书编写只有短短的7年时间。在这段时间，不仅仅是服务器的虚拟化经历了从全虚拟化到硬件支持的虚拟化以至下一代可扩展虚拟化技术的发展，软件定义存储、软件定义网络也迅速发展起来，并成为数据中心中实用的技术。在数据中心管理方面，VMware的vCloud Director依然是最成熟的管理软件定义数据中心的工具。但是，以OpenStack为代表的开源解决方案也显现出惊人的生命力和发展速度。OpenStack从2010年出现到变成云计算圈子里人尽皆知的明星项目只用了不到两年时间。
试读结束[说明：试读内容隐藏了图片]