云计算宝典:技术与实践


II 内 容 简 介 探究核心技术,总结实践方法。本书四篇十二章,对云计算进行了系统的探讨。战略蓝图篇以 概述云计算为起点,纵览其在一系列重要行业中的应用场景和实践方针,继而深入实施步骤,为云 计算产业参与者勾画了蓝图。技术基石篇首先描述数据中心的核心功能,管理维护方法,以及新一 代数据中心的需求和挑战,随后介绍云计算的技术基础:服务器虚拟化和虚拟器件。系统架构篇从 横向和纵向两个维度定义了云架构,在基础设施即服务、平台即服务和软件即服务的层面进行了深 入的技术探讨,并给出相关的参考实现。业界动态篇勾勒了生态系统的动态和趋势,从虚拟化和云 计算两个维度介绍了业界的基本情况和主流产品。 通过阅读本书,您可以系统地了解云计算的产生背景、发展现状、技术要点和未来趋势,更加 准确地把握业界前沿的科技和理念,认清信息技术发展的大脉络,形成适应于产业未来的大局观。 本书将为您打开一扇通往未来的窗户,帮助您拓宽视野,完善知识结构,储备适用于下一代信息产 业的技能和智慧。 未经许可,不得以任何方式复制或抄袭本书之部分或全部内容。 版权所有,侵权必究。 图书在版编目(CIP)数据 云计算宝典:技术与实践/虚拟化与云计算小组著. —北京:电子工业出版社,2011.9 ISBN 978-7-121-14103-4 Ⅰ. ①云… Ⅱ. ①虚… Ⅲ. ①计算机网络 Ⅳ.①TP393 中国版本图书馆CIP数据核字(2011)第138980号 策划编辑:刘 皎 责任编辑:高洪霞 印  刷:北京东光印刷厂 装  订:三河市皇庄路通装订厂 出版发行:电子工业出版社 北京市海淀区万寿路173信箱 邮编100036 开  本:787×980 1/16 印张:27.75 字数:677千字 印  次:2011年9月第1次印刷 印  数:4000册 定价:75.00元 凡所购买电子工业出版社图书有缺损问题,请向购买书店调换。若书店售缺,请与本社发行部联 系,联系及邮购电话:(010)88254888。 质量投诉请发邮件至zlts@phei.com.cn,盗版侵权举报请发邮件至dbqq@phei.com.cn。 服务热线:(010)88258888。 III 本书作者大多曾供职于IBM中国研究院虚拟化与云计算研究部。自2006年成立以来, 该部门一直致力于研究如何使用虚拟化和云计算技术来简化服务部署、提高运行维护效 率、降低管理复杂性、提升资源利用率,从而打造节能环保的数据中心。我们开创了应用 虚拟器件技术及云平台技术来管理信息服务和数据中心的完整方法,其中部分成果已经成 为IBM和产业界的标准。我们研发了一系列与之配套的管理工具,用于虚拟器件的制作、 激活、部署、动态资源调度、运行时管理等。利用这些方法和工具,我们将凝聚了IBM多 年经验的软件产品和最佳实践解决方案封装成基于虚拟器件的云平台解决方案,并通过快 捷部署激活工具简化应用上线的过程,为用户提供更稳定、更可靠的服务,为管理人员提供 更简捷、更智慧的管理模式。 作为长期工作在产业前沿的研究团队,让更多的技术人员深刻理解虚拟化以及云计 算技术是我们肩负的一份责任。我们到国内各大高校做了多场虚拟化和云计算的主题演 讲,也发表了一些中文论文,并有部分英文论文被译成中文,但这些零散的资料很难系统 地论述相关知识。于是,我们在2009年10月写作完成了小组的第一本专著《虚拟化与云计 算》,让广大同行和读者了解本领域最新的技术成果,共同感受信息产业变革带来的机遇 与挑战。该书获得了51CTO 2009年最受读者喜爱的IT原创图书奖,我们也获得了电子工业 出版社2009年优秀作者奖。2010年,我们在台湾地区出版了《虚拟化与云计算》的繁体修 订版《雲端策略》,之后又创作完成小组的第二本专著《云计算实践之道——战略蓝图与 技术架构》,书中我们加深阐述了对于云计算本质及优势的理解,增加了云计算的行业实 践以及云计算的实施两大部分内容,从而解答读者对于云计算的收益、实施场景、实施方 法以及实施要点等问题。 自这三本书出版以来,业界对云计算的认识和实践已经出现了很大变化。一方面, 作者序 IV 用户已经很少再询问诸如:“云计算的基本特点是什么?”“我们能从云计算当中得到什 么样的好处?”之类的问题。取而代之的是用户更加希望了解云计算的各种技术细节,从 而帮助他们更深刻地认识自身IT设施和应用,在迁移到云平台的过程中做出更加有效的决 策。另外一方面,最近一两年云计算技术领域出现了大量创新性技术和应用,进一步深化 了云计算的内涵,同时与传统计算技术结合在一起,在商业上也获得了巨大的成功。这两 方面的变化是我们写这本《云计算宝典——技术与实践》的主要驱动力。本书应大量读者的 要求,用更多的篇幅来展示云计算技术层面的内容,期望将各种令人眼花缭乱的相关技术 组织起来,向读者展示一个统一的云计算视图,并阐释其中各种技术、应用和服务背后的 本质推动力。 在这两年中,又有几位新同事加入了IBM中国研究院虚拟化与云计算研究团队,使 我们的研究范围同云计算的发展一起壮大。我们研发了新的大规模、高可靠的云平台技 术及原型系统,参与了全球技术团队的虚拟化与云计算产品策划、立项、开发,与销售 部门、服务部门配合参与了多个云计算客户项目,并在几所高校设立了云计算的合作科 研课题。我们分别获得了IBM全球研究贡献奖和IBM全球研究杰出贡献奖。在这些工作 中,我们不断积累经验并整理思路,最终形成了现在您所看到的这本书。本书与之前出 版的三本书之间的内容关系如下图所示,可以看出新书是在前三本书基础上的全面修订 和集中整合。 在写作过程中,我们力求用严谨而又通俗的语言来阐述云计算中涉及的各种技术上 和商业上的概念、定义和方法。希望读者能够从本书中获得对于云计算的清晰、实用、有 指导性的认识。此外,我们力求反映业界当前对云计算的最新认识和实践。当然,由于篇 幅、时间以及作者水平所限,本书中我们只对(我们认为)比较重要的内容进行了阐述,文 笔也略显笨拙,如有遗漏和纰误,请各位读者不吝指教。  我们的联系方式如下: 陈 滢 新浪微博 http://weibo.com/deepb1ue 王庆波 新浪微博 http://weibo.com/wangqbo 金 涬 新浪微博 http://weibo.com/jinxing9 何 乐 新浪微博 http://weibo.com/helebest 赵 阳 新浪微博 http://weibo.com/zhaohuli 邹志乐 新浪微博 http://weibo.com/zhilezou 吴玉会 新浪微博 http://weibo.com/ssse7en 杨 林 电子邮箱 cameling_yang@hotmail.com 田瑞雄 电子邮箱 tianruix@gmail.com 谢苏苏 新浪微博 http://weibo.com/drxiesusu 操保华 电子邮箱 caobaohua@gmail.com 王 仕 电子邮箱 thyme_se@hotmail.com VI 在过去的半个多世纪,信息技术的发展,尤其是计算机和互联网技术的进步极大地 改变了人们的工作和生活方式。大量企业开始采用以数据中心为业务运营平台的信息服 务模式。进入新世纪后,数据中心变得空前重要和复杂,这对管理工作提出了全新的挑 战,一系列问题接踵而来:企业如何通过数据中心快速地创建服务并高效地管理业务? 怎样根据需求动态调整资源以降低运营成本?如何更加灵活、高效、安全地使用和管理 各种资源?如何共享已有的计算平台而不是重复创建自己的数据中心?业内人士普遍认 为,信息产业本身需要更加彻底的技术变革和商业模式转型,云计算正是在这样的背景下应 运而生的。 早在大型机盛行的20世纪五六十年代,计算资源就是采用“租借”的方式对外提供 服务的。IBM公司当时的首席执行官Thomas Watson曾预言道:“全世界只需要五台计 算机”,过去三十年的PC大繁荣似乎正在推翻这个论断,人们也常常引用这个例子,来 说明信息产业的不可预测性。然而,信息技术变革并不总是直线前进,而是螺旋式上升 的。半导体、互联网和虚拟化技术的飞速发展使得业界不得不重新思考这一构想,这些 支撑技术的成熟让我们有可能把全世界的数据中心进行适度的集中,从而实现规模化经 济效应。人们只需远程租用这些共享资源,从而消除企业为了使用信息技术而进行的数 据中心构建、硬件采购、软件安装、系统维护等环节。 云计算是这种构想的代名词,它创新的计算模式使用户通过互联网随时获得近乎无 限的计算能力和丰富多样的信息服务,它创新的商业模式使用户对计算和服务可以取用 自由、按量付费。目前的云计算融合了以虚拟化、服务管理自动化和标准化为代表的大 量革新技术。云计算借助虚拟化技术的伸缩性和灵活性,提高了资源利用率,简化了资 前 言 VII 源和服务的管理和维护;利用信息服务自动化技术,将资源封装为服务交付给用户,减少 了数据中心的运营成本;利用标准化,方便了服务的开发和交付,缩短了客户服务的上线 时间。 云计算技术正在快速地发展,业界各大厂商纷纷制定相应的战略,新的概念、 观点和产品不断涌现。云计算的技术热点也呈现百花齐放的局面,比如以互联网为平 台的虚拟化解决方案的运行平台,基于多租户技术的业务系统在线开发、运行时和运 营平台,大规模云存储服务,大规模云通信服务等。云计算的出现为信息技术领域带 来了新的挑战,也为信息技术产业带来了新的机遇。然而,真正系统、全面地阐述云 计算概念和技术及实施方法和步骤的书却是寥寥无几。本书作为第一本同时兼顾云计 算技术与实践的图书,正好弥补了这一空白,为对云计算感兴趣的读者讲述相关的知 识、理论和案例。 本书分为四篇十二章,第1至3章为战略蓝图篇;第4至6章为技术基石篇;第7至10章 为系统架构篇,第11章和第12章为业界动态篇。为方便读者阅读,下面给出本书的导读 简图: 下面对各章内容分别进行简单介绍: 第1章对云计算进行了概述。本章首先从四个典型案例出发,介绍了云计算的概念, VIII 对云进行分类,针对云计算与其他相关概念进行了辨析以加深读者的理解;接着介绍了云 计算的本质以及带来的好处;随后讨论了云计算产生的原动力;最后论述了云计算对相关 产业带来的变革。 第2章包含了一系列云计算的行业实践,即云计算在各个行业中的应用场景。我们重 点介绍云计算在政府、银行、电信、物流、医疗、制造、互联网、教育等八个行业中的运 用,分别讨论了每个行业对于信息服务需求的特点,以及云计算在该行业的典型使用场 景。希望能够帮助读者认识到云计算如何在一个行业中发挥出其力量。 第3章介绍了云计算的实施。本章首先将需要实施云计算的角色类型分为云计算的 使用者和云计算的运营者两类,随后介绍了相应的关键步骤:规划、实施、运维。希 望读者通过这一章的阅读,能够根据自己的需求进行云计算实施的可行性评估和执行 方案。 第4章为读者揭开了数据中心的神秘面纱,介绍数据中心的基本概念、核心功能、管理和 维护工作,以及新一代数据中心的需求和挑战。 第5章介绍了虚拟化技术的定义,重点剖析当前最重要的服务器虚拟化技术,对它的 概念、支撑技术、优势特点及性能进行分析和阐述,并讨论在数据中心中被广泛采纳的其 他虚拟化技术。 第6章以虚拟器件生命周期的三个阶段为主线,介绍了实施服务器虚拟化的关键技 术,重点讨论了构成服务器虚拟化的虚拟镜像和虚拟器件概念,以及在虚拟器件的创 建、部署和运行流程中的关键技术。 第7章从横向和纵向两个维度定义了云架构。根据功能的依赖关系,云架构在横向上 可以分为基础设施即服务、平台即服务层和软件即服务;根据企业IT系统对云计算的采用 层次,云计算在纵向上可以分为传统的IT系统、基于IaaS的IT系统、基于PaaS的IT系统和 基于SaaS的IT系统。 IX 第8章首先介绍了提供基础设施即服务的服务模型与接口,然后深入介绍计算即服 务、存储即服务和网络即服务。对于每一类具体的服务形式,本章各用一节介绍了对应的 服务模型和访问接口,实现服务的关键技术。 第9章首先阐述了平台即服务产生的驱动力,然后介绍了实现PaaS系统的核心系统 和扩展系统,最后针对平台层的两种主要运用形式,Web服务和数据分析服务,通 过实例来剖析面向这两类服务的PaaS实现要点,帮助读者对平台即服务获得更深刻 的理解。 第10章首先介绍了软件即服务层的架构,然后分析了SaaS平台的设计要点和关键技 术,分别从大规模多租户、认证和安全、定价和计费、服务整合、开发和定制五个方面深 入展开,并给出了一个SaaS平台系统的参考实现。 第11章对虚拟化业界四家主要厂商的基本情况和主要产品进行了介绍,他们是IBM, VMware, Xen和Microsoft,并向读者介绍了他们各自的发展历程和技术特点。 第12章介绍了云计算的业界动态,主要涉及几个领先的云计算厂商,包括IBM、 Amazon、Google、Salesforce.com、Microsoft等,以及较成功的开源云计算产品。本章概 要地介绍了每个厂商的云计算产品线,并分析其产品的功能和特点,使读者能够对主要的 云计算厂商和产品有一个总体的认识,对业界的最新动态有较为全面的了解。 在附录中我们列出了本书的参考文献和索引。有兴趣的读者可以通过它们获取更多的 云计算知识和资料。 在编写本书时,我们力图使不同职业和背景的读者都能从本书中获益。 如果您是企业的技术负责人或数据中心运行维护人员,您将更深刻体会到云计算技 术为企业IT部门、信息系统规划和数据中心运行维修带来的深刻变革。我们提供的技术讨 论、产品比较和案例分析,将有助于您在脑海中勾画下一步的战略。 如果您是从业的技术研发人员,您能系统地了解云计算的产生背景、发展现状、技术要  点和未来趋势。通过本书的梳理,能够更加准确地把握业界前沿的科技和理念,认清信息技 术发展的大脉络,形成适用于产业未来的大局观。 如果您是大专院校计算机及相关专业的学生,您将获得无法从现有课本中得到的技术 知识。本书将为您打开一扇通往未来的窗户,帮助您拓宽视野,完善知识结构,储备适 用于未来信息产业的知识和技能。 本书适合于从头至尾阅读,也可以按照喜好和关注点挑选独立的章节阅读。我们希望 本书的介绍能加深您对云计算的理解,获得您所期待的信息。 XI 《云计算宝典》一书不仅仅凝结了各位作者辛勤的汗水,从构思、写作、修订到出 版,作者们得到了业界许多同仁的无私帮助,在此要对他们致以最衷心的感谢。 首先感谢IBM中国研究院给我们提供了良好而宽松的研究氛围,能让我们在科研工作 之余,抽出时间完成本书,这种以创新为本的研究氛围也激发了我们很多灵感。同事们的 鼓励和鞭策激励着我们迎接更大的挑战。 本书的作者团队在多年的工作中一直与IBM大中华区的其他部门有着深入的合作,这些合 作让我们加深了对行业领域的认识。感谢多年来和我们一起工作的IBM全球研发团队。通过和他 们在虚拟化和云计算领域的合作,我们积累了大量的实践经验和行业认知,否则本书只能是纸 上谈兵。 感谢一直以来身处政府、电信、教育、互联网等行业的合作伙伴,与他们的紧密合作 使我们一直走在时代的前沿。还有很多朋友无私地与我们分享了对云计算的理解,阅读了 本书的审阅稿,并提出了宝贵的意见,在此特别感谢。 我们要向电子工业出版社博文视点团队表示感谢。感谢他们在创作、编辑、出版过程 中对我们一如既往的热情支持。感谢与我们合作的编辑人员,他们细致耐心的工作使本书 能够顺利出版。 最后,感谢家人对我们一如既往的支持,正是他们在生活上心甘情愿地主动承担了大 多数家庭的责任才使得我们有充足的时间完成本书的编写,他们永远是我们努力工作和快 乐生活的动力源泉。 致 谢 XII 读者在阅读本书内容之前,请仔细阅读本声明。凡以任何方式阅读或直接、间接使用 本书内容者,均视为对本声明全部内容的认可和接受。 1. 本书所有内容仅代表本书作者的个人观点,与IBM公司的立场无关。IBM公司不对 本书内容的准确性、可靠性或完整性提供任何明示或暗示的保证。对于任何因直接或间接 采用、转载本书内容而造成的损失,本书作者和IBM公司均不承担责任。 2. 本书作者或IBM公司对本书所引用资料的版权归属和权力的瑕疵情况不承担核实责 任。如任何单位或个人认为本书涉嫌侵犯其合法权益,应及时向本书作者提出书面意见并 提供相关证明材料和理由,本书作者在收到上述文件后将采取相应措施。 3. 本书所引用的资料涉及的非IBM公司产品,这些资料是从相应产品供应商所提供的 说明或其他公开获得的资料中获取的。本书作者或IBM公司没有对这些产品进行测试,无 法确认其功能、性能、兼容性,也无法确保该产品完全具备声明的其他特性。 4. 本书所引用资料的作者不因本书的引用行为而与本书作者或IBM公司之间产生任何 关系或关联。 5. 本免责声明以及其修改权、更新权及最终解释权均属本书作者所有。 免责声明 目录 XIII 目 录 第一篇 战略蓝图篇 第 1 章 云计算概论 ....................................................................... 003 1.1 云计算的概念 ............................................................................................003 1.1.1 走近云计算 ...................................................................................................004 1.1.2 云计算的定义 ................................................................................................007 1.1.3 云计算的特征 ................................................................................................010 1.1.4 云计算的分类 ................................................................................................012 1.1.5 相关概念辨析 ................................................................................................017 1.2 云计算的优势 ...........................................................................................020 1.2.1 优化产业布局 ................................................................................................020 1.2.2 推进专业分工 ................................................................................................021 1.2.3 提升资源利用率 ............................................................................................022 1.2.4 减少初期投资 ................................................................................................024 1.2.5 降低运营成本 ................................................................................................026 1.2.6 产生新创价值 ................................................................................................026 1.3 云计算产生的原动力 ............................................................................................... 027 1.3.1 芯片与硬件技术 ............................................................................................029 1.3.2 资源虚拟化 ...................................................................................................029 1.3.3 面向服务架构 ................................................................................................030 1.3.4 软件即服务 ...................................................................................................031 1.3.5 互联网技术 ...................................................................................................031 1.3.6 Web 2.0技术 .................................................................................................032 1.4 云计算带来的变革 ....................................................................................033 1.4.1 大势所趋的转型 ............................................................................................033 1.4.2 新兴的产业链 ................................................................................................034 1.5 小结..........................................................................................................039 CONTENTS 第 2 章 云计算的行业实践 ........................................................ 040 2.1 概述.......................................................................................................... 041 目录XIV 第 3 章 云计算的实施 .............................................................. 070 3.1 云计算的实施要点 .................................................................................... 071 3.2 企业实施云计算的战略规划 .....................................................................072 3.2.1 战略规划概述 ................................................................................................073 3.2.2 价值分析 .......................................................................................................074 3.2.3 风险评估 .......................................................................................................075 3.2.4 战略定位分析 ................................................................................................077 3.2.5 业务适应性分析 ............................................................................................078 3.3 企业云计算业务的实施 ............................................................................084 3.3.1 实施基础设施层云计算业务 ...........................................................................085 3.3.2 实施平台层云计算业务 ..................................................................................086 3.3.3 实施应用层云计算业务 ..................................................................................090 3.4 云计算提供商的业务模型 .........................................................................090 3.4.1 业务模型设计 ................................................................................................091 3.4.2 业务模型示例 ................................................................................................094 2.2 云计算在公共服务行业的应用 .................................................................043 2.3 云计算在银行业的应用 ............................................................................047 2.3.1 中间业务创新 ................................................................................................047 2.3.2 核心业务创新 ................................................................................................049 2.3.3 开发测试业务创新 .........................................................................................051 2.4 云计算在电信行业的应用 .........................................................................052 2.5 云计算在物流行业的应用 ..........................................................................055 2.6 云计算在医疗行业的应用 .........................................................................057 2.7 云计算在制造行业的应用 .........................................................................059 2.8 云计算在教育科研领域的应用 .................................................................063 2.8.1 云计算在课堂教学领域的应用 .......................................................................063 2.8.2 云计算在教学实验中的应用 ...........................................................................064 2.8.3 云计算在教辅领域的应用 ..............................................................................065 2.8.4 云计算在促进科研合作中的应用 ....................................................................065 2.9 小结 .........................................................................................................067 目录 XV 3.5 云计算提供商的平台构建 .........................................................................096 3.6 云计算平台的运维管理 ............................................................................098 3.6.1 运维管理的目标 ............................................................................................099 3.6.2 运维管理的核心 ............................................................................................100 3.6.3 运维管理的平台 ............................................................................................102 3.6.4 平台信息安全管理 .........................................................................................105 3.7 小结 ...........................................................................................................111 第二篇 技术基石篇 第 4 章 新一代绿色数据中心 ..................................................... 113 4.1 数据中心概述 ............................................................................................114 4.1.1 数据中心的概念 ....................................................................................114 4.1.2 数据中心的发展过程 .............................................................................115 4.1.3 数据中心的分类与分级 ..........................................................................116 4.2 数据中心的设计和构建 ............................................................................. 117 4.2.1 总体设计 ...............................................................................................117 4.2.2 建筑的设计与构建 .................................................................................118 4.2.3 基础设施的设计与构建 ..........................................................................120 4.2.4 数据中心上线 ........................................................................................122 4.3 数据中心的管理和维护 ............................................................................ 125 4.3.1 硬件的管理和维护 .................................................................................126 4.3.2 软件的管理和维护 .................................................................................126 4.3.3 数据的管理和维护 .................................................................................127 4.3.4 资源管理 ...............................................................................................128 4.3.5 安全管理 ...............................................................................................129 4.4 新一代数据中心的需求 ............................................................................ 130 4.4.1 合理规划 ...............................................................................................130 4.4.2 流程化 ..................................................................................................131 4.4.3 可管理性 ...............................................................................................133 4.4.4 可伸缩性 ...............................................................................................134 4.4.5 可靠性 ..................................................................................................135 目录XVI 4.5 绿色数据中心 ........................................................................................... 136 4.5.1 经济型数据中心 ....................................................................................136 4.5.2 数据中心能效分析 .................................................................................137 4.6 小结 ......................................................................................................... 140 第 5 章 虚拟化概论 ................................................................. 142 5.1 虚拟化的定义 ........................................................................................... 143 5.1.1 走近虚拟化 ...........................................................................................143 5.1.2 虚拟化的定义 ........................................................................................144 5.1.3 虚拟化的常见类型 .................................................................................146 5.2 服务器虚拟化 ........................................................................................... 149 5.2.1 基本概念 ...............................................................................................149 5.2.2 典型实现 ...............................................................................................151 5.2.3 关键特性 ...............................................................................................152 5.2.4 核心技术 ...............................................................................................153 5.2.5 性能分析 ...............................................................................................161 5.2.6 技术优势 ...............................................................................................164 5.3 其他虚拟化技术 ....................................................................................... 167 5.3.1 网络虚拟化 ...........................................................................................167 5.3.2 存储虚拟化 ...........................................................................................168 5.3.3 桌面虚拟化 ...........................................................................................169 5.3.4 应用虚拟化 ...........................................................................................170 5.4 小结 ......................................................................................................... 172 第 6 章 虚拟化管理 ................................................................. 173 6.1 创建虚拟化解决方案 ................................................................................ 174 6.1.1 创建基本虚拟镜像 .................................................................................174 6.1.2 创建虚拟器件镜像 .................................................................................176 6.1.3 发布虚拟器件镜像 .................................................................................180 6.1.4 管理虚拟器件镜像 .................................................................................182 第 5 章 虚拟化概论 ................................................................. 142 第 6 章 虚拟化管理 ................................................................. 173 目录 XVII 6.1.5 迁移到虚拟化环境 .................................................................................183 6.2 部署虚拟化解决方案 ................................................................................ 185 6.2.1 规划部署环境 ........................................................................................185 6.2.2 部署虚拟器件 ........................................................................................187 6.2.3 激活虚拟器件 ........................................................................................191 6.3 管理虚拟化解决方案 ................................................................................ 192 6.3.1 集中监控 ...............................................................................................193 6.3.2 快捷管理 ...............................................................................................194 6.3.3 动态优化 ...............................................................................................196 6.3.4 高效备份 ...............................................................................................198 6.4 小结 .........................................................................................................200 第三篇 系统架构篇 第 7 章 云架构 ....................................................................... 202 7.1 云架构的层次 ...........................................................................................203 7.1.1 云架构的基本层次 .................................................................................203 7.1.2 云架构的服务层次 .................................................................................205 7.2 云架构的特性 ...........................................................................................207 7.2.1 大规模 ..................................................................................................207 7.2.2 高可用 ..................................................................................................209 7.2.3 可伸缩 ..................................................................................................210 7.2.4 高性能 ..................................................................................................210 7.3 云架构的准则 ............................................................................................211 7.3.1 信息安全与保密 ....................................................................................211 7.3.2 许可证与计费 ........................................................................................213 7.3.3 集成与标准化 ........................................................................................215 7.4 小结 ......................................................................................................... 217 第 8 章 基础设施即服务 ........................................................... 218 8.1 概述.......................................................................................................... 219 8.2 服务模型与接口 ....................................................................................... 219 目录XVIII 8.3 计算即服务 ..............................................................................................222 8.3.1 服务模型及接口 ....................................................................................222 8.3.2 关键技术 ...............................................................................................224 8.3.3 参考实现 ...............................................................................................229 8.4 存储即服务 ..............................................................................................238 8.4.1 服务模型及接口 ....................................................................................239 8.4.2 关键技术 ...............................................................................................240 8.4.3 参考实现 ...............................................................................................245 8.5 网络即服务 ..............................................................................................247 8.5.1 服务模型及接口 ....................................................................................247 8.5.2 关键技术 ...............................................................................................249 8.6 小结 .........................................................................................................253 第 9 章 平台即服务 ................................................................. 254 9.1 概述..........................................................................................................255 9.1.1 驱动力 ..................................................................................................255 9.1.2 主流类型 ...............................................................................................257 9.1.3 功能角色 ...............................................................................................258 9.2 核心系统 ..................................................................................................260 9.2.1 简化的应用开发和部署模型 ...................................................................260 9.2.2 自动的资源获取和应用激活 ...................................................................262 9.2.3 自动的应用运行管理 .............................................................................263 9.2.4 平台级优化 ...........................................................................................265 9.3 扩展系统 ..................................................................................................266 9.3.1 非关系型数据存取 .................................................................................266 9.3.2 大规模消息通信 ....................................................................................272 9.3.3 海量数据分析 ........................................................................................274 9.4 参考实现 .................................................................................................278 9.4.1 事务处理类 ...........................................................................................279 9.4.2 数据分析类 ...........................................................................................283 目录 XIX 9.5 小结 ......................................................................................................... 291 第 10 章 软件即服务 ................................................................ 292 10.1 概述 ........................................................................................................293 10.1.1 生态系统与实现层次 ............................................................................294 10.1.2 技术发展历程 ......................................................................................295 10.2 支撑平台 ................................................................................................296 10.2.1 支撑平台的架构 ...................................................................................296 10.2.2 支撑平台的关键技术 ............................................................................298 10.2.3 支撑平台的参考实现 ............................................................................309 10.3 云应用 .....................................................................................................311 10.3.1 云应用的特征 ......................................................................................311 10.3.2 云应用的分类 ......................................................................................312 10.3.3 云应用的典型示例 ...............................................................................314 10.4 小结 ........................................................................................................ 318 第四篇 业界动态篇 第 11 章 虚拟化的业界动态........................................................ 320 11.1 IBM .......................................................................................................... 321 11.1.1 概述 ....................................................................................................321 11.1.2 z系列服务器 ........................................................................................323 11.1.3 p系列服务器 ........................................................................................325 11.1.4 虚拟化管理 ..........................................................................................328 11.2 VMware ..................................................................................................330 11.2.1 概述 ....................................................................................................330 11.2.2 数据中心虚拟化 ...................................................................................331 11.2.3 桌面和应用虚拟化 ...............................................................................334 11.2.4 虚拟化辅助工具 ...................................................................................335 11.3 Xen/Citrix ................................................................................................336 目录XX 11.3.1 概述 ....................................................................................................336 11.3.2 服务器虚拟化 ......................................................................................337 11.3.3 应用虚拟化 ..........................................................................................338 11.3.4 桌面虚拟化 ..........................................................................................338 11.4 KVM/Red Hat ..........................................................................................339 11.4.1 概述 ....................................................................................................339 11.4.2 架构 ....................................................................................................340 11.4.3 展望 ....................................................................................................342 11.5 Microsoft .................................................................................................342 11.5.1 概述 ....................................................................................................342 11.5.2 服务器虚拟化 ......................................................................................344 11.5.3 应用虚拟化 ..........................................................................................344 11.5.4 桌面虚拟化 ..........................................................................................345 11.5.5 虚拟化管理 ..........................................................................................346 11.6  小结 .......................................................................................................346 第 12 章 云计算的业界动态 ....................................................... 348 12.1 IBM..........................................................................................................349 12.1.1 概述 ....................................................................................................349 12.1.2 IBM云业务咨询服务 ............................................................................351 12.1.3 IBM云计算基础架构策略和计划服务 ...................................................353 12.1.4 IBM Smart Business Development and Test Cloud ................................. 355 12.1.5 IBM Smart Business Desktop Cloud ....................................................... 358 12.1.6 IBM Smart Business Analytics Cloud ..................................................... 362 12.1.7 IBM Smart Business Storage Cloud ........................................................ 363 12.1.8 IBM LotusLive .....................................................................................365 12.1.9 IBM TSAM..........................................................................................366 12.1.10 IBM WebSphere CloudBurst Appliance ...............................................369 12.1.11 IBM System Director ..........................................................................372 12.2 Amazon ..................................................................................................376 12.2.1 概述 ....................................................................................................376 12.2.2 Amazon S3 ...........................................................................................378 12.2.3 Amazon SimpleDB ...............................................................................379 目录 XXI 12.2.4 Amazon RDS .......................................................................................380 12.2.5 Amazon SQS ........................................................................................381 12.2.6 Amazon EC2 ........................................................................................382 12.3 Google....................................................................................................384 12.3.1 概述 ....................................................................................................384 12.3.2 分布式存储服务 ...................................................................................385 12.3.3 应用程序运行时环境 ............................................................................386 12.3.4 应用开发套件 ......................................................................................386 12.3.5 云应用 .................................................................................................387 12.4 Salesforce.com .......................................................................................388 12.4.1 概述 ....................................................................................................388 12.4.2 基础服务 .............................................................................................388 12.4.3 数据库服务 ..........................................................................................389 12.4.4 应用开发服务 ......................................................................................390 12.4.5 应用打包服务 ......................................................................................391 12.5 Microsoft ................................................................................................392 12.5.1 Windows Azure platform ......................................................................393 12.5.2 Live服务 ..............................................................................................398 12.6 开源云计算 .............................................................................................400 12.6.1 Eucalyptus ...........................................................................................400 12.6.2 NoSQL ................................................................................................404 12.6.3 OpenStack ...........................................................................................407 12.6.4 Nimbus ................................................................................................408 12.6.5 AppScale ..............................................................................................409 12.7 小结 .........................................................................................................411 附录A:参考文献 ............................................................................................. 413 第一篇 战略蓝图篇 第1章 云计算概论 第2章 云计算的行业实践 第3章 云计算的实施 第一篇 战略蓝图篇 ╗ ╗ 云计算概论 1.1 云计算的概念 1.2 云计算的优势 1.3 云计算产生的原动力 1.4 云计算带来的变革 1.5 小结 第 1 章 第1章 云计算概论 003 从20世纪40年代世界上第一台电子计算机诞生至今,已经过去了半个多世纪。在 这几十年里,计算模式经历了单机、终端—主机、客户端—服务器几个重要时代,发 生了翻天覆地的变化。半导体芯片技术遵循着摩尔定律不断发展,到2009年,世界 上最快的计算机IBM Roadrunner已经达到每秒千万亿次的运算速度。在过去的二十年 里,互联网将全世界的企业与个人连接了起来,并深刻地影响着每个企业的业务运作 及每个人的日常生活。用户对互联网内容的贡献空前增加,软件更多地以服务的形式 通过互联网被发布和访问,而这些网络服务需要海量的存储和计算能力来满足日益增 长的业务需求。 互联网使得人们对软件的认识和使用模式发生了潜移默化的改变。计算模式的 变革必将带来一系列的挑战。如何获取海量的存储和计算资源?如何在互联网这个 无所不包的平台上更经济地运营服务?各种新的IT技术对各行业将会产生怎样的影 响?如何才能使互联网服务更加敏捷、更随需应变?如何让企业和个人用户更加方 便、透彻地理解与运用层出不穷的服务?“云计算”正是顺应这个时代大潮而诞生 的信息技术理念。目前,无论是信息产业的行业巨头还是新兴科技公司,无不把云 计算作为企业发展战略中的重要组成部分。云计算的号角已经吹响,势不可当。本 章将解释云计算的确切含义与分类,分析云计算的优势及其带来的变革,并阐述云计 算的来龙去脉。 1.1 云计算的概念 “云计算”这个词相对于“分布式计算”或“网格计算”等技术类名词的确显得更 加浪漫,甚至很难让人们从这个词本身推断它所涵盖的范畴。事实上,不但第一次听 说“云计算”的普通技术工作者会感到不知所云,就连众多行业精英和学术专家们也 很难对云计算给出一个准确的定义,每个人从不同的角度会有不同的解释。本节将首先 呈现云计算的四个典型案例,并以这些案例为脉络,探究云计算的内涵,领略云中的真 实世界。 云计算宝典——技术与实战004 1.1.1 走近云计算 1.1.1.1 相关案例 【案例一】   2008年3月19日上午10点,美国国家档案馆公开了希拉里·克林顿在1993—2001 年作为第一夫人期间的白宫日程档案。由于这些档案是新闻记者团体和独立调查机 构依据“信息自由法案”向国会多次请愿才得以公开的,因此具有极高的社会关注 度与新闻时效性。但是,这些档案是不可检索的低质量PDF文件,若想将其转换为 可以检索并便于浏览的文件格式,需要进行再处理。   华盛顿邮报希望将这些档案在第一时间上传到互联网,以便公众查询,但是据 估算仅每一页的操作,以报社现有的计算能力就需要30分钟。因此,华盛顿邮报将这个 档案的转换工程交给Amazon EC2(Elastic Compute Cloud)。Amazon EC2同时使用200 个虚拟服务器案例,每个服务器的单页平均处理时间都缩短为一分钟,并在9小时内将 所有的档案转换完毕,以最快的速度将这些第一手资料呈现给读者。 【案例二】   Giftag是一款Web 2.0应用,它能被以插件的形式安装在Firefox和IE浏览器上。 互联网用户在浏览网页,尤其是在浏览购物网站的时候,可以利用这个插件将心仪 的商品加入到由Giftag维护的商品清单中,并将这个清单与好友分享。这个应用一经 推出便广泛流行起来,注册用户数量激增,每天Giftag的服务器都要响应数以百万计 的请求,并存储用户提交的海量信息,没过多久服务器就不堪重负。   后来,Giftag将应用迁移到Google App Engine(GAE)平台,基于GAE的开放 API,Giftag可以利用Google具有可伸缩性的计算处理性能来响应高峰期的用户请 求,利用Google的分布式数据库来存储用户数据,甚至可以使用Gmail邮箱和Google 的搜索功能来增强用户体验。Giftag实现了从一个初创的Web 2.0应用向一个稳定 的、持续增长的网络服务的平稳过渡。 【案例三】   哈根达斯是著名的冰激凌供应商,其加盟店遍布世界各地。因此,公司需要一 【案例一】 【案例二】 【案例三】 第1章 云计算概论 005 个CRM(客户关系管理)系统对所有的加盟店进行管理。当时哈根达斯用Excel表 单来管理和跟踪主要的加盟店,用Access数据库来存储协议加盟店的数据,但是使用虚 拟专用网(VPN)来访问该数据库的效果总是不太好。因此,公司急需一个能够让分布在 各地的员工沟通协作的解决方案,并且该方案应该能够根据不同的需求进行灵活配置。   哈根达斯公司选择了Salesforce CRM企业版,应用系统在不到6个月的时间就上 线了。除此之外,该系统将Microsoft Outlook和Salesforce CRM集成了起来,从而使 员工能够轻松地访问Outlook中的联系人列表、日程和商业信息。Salesforce.com还为 哈根达斯的解决方案提供了员工培训模块、加盟店跟踪模块,以及新店选址模块。 哈根达斯公司用更少的成本获得了超预期的效果。 【案例四】   国际商业机器公司(IBM)作为全球整合的大型跨国企业,在全球共拥有9所研 究院,汇聚了3000多位顶尖的科学家和研究员。在他们之中共有6位诺贝尔奖获得者 和6位图灵奖获得者。在2009年,共有4914项美国专利在IBM诞生。在这里,每天都 有不计其数的科学实验在进行着,其中有些实验需要有海量的计算和存储资源作为支 撑。虽然每所研究院都配备了先进的IT设备,但仍然满足不了某些实验的需求。除此 之外,由于这些研究院分布在世界各地,处于不同的时区,给合作科研提出了挑战。   为了给研究部门的创新提供源源不断的支持,也为提高各研究院间的沟通协作 效率,IBM公司构建了IBM Research Compute Cloud(RC2)将分散在各个研究院 的资源系统(如服务器、存储)整合,为公司内部所使用。该系统为科研人员提供 了共享计算和存储资源的平台,通过任务调度和安排,为每一项科学实验提供了有 保障的动态资源供给,而且不需要科学实验人员来管理这些资源。不仅如此,不论 是实验的中间流程还是最终结果,都是在该系统中完成和保存的,所以有效地保证 了数据的安全,并使得身处世界各地的研究人员随时可以对它们进行查询和交换。这 一切大大提高了协同科研的效率,为IBM公司不断深入的创新提供了强大的推动力。 1.1.1.2 案例分析 在案例一中,如果没有Amazon EC2提供的计算能力,华盛顿邮报需要超过一年的时间 来完成全部档案的格式转换工作。显然,这样的效率不能满足新闻的时效性和公众对于信 【案例四】 云计算宝典——技术与实战006 息的期盼。恰恰是Amazon公司通过其EC2平台,将计算资源打包提供给客户,使报社在9小 时内就得到了1407小时的虚拟服务器机时,在第一时间完成了档案的转换,而华盛顿邮报 仅需要向Amazon公司支付144.62美元的费用。 在案例二中,Giftag公司和其他初创型Web 2.0公司一样,面临着高昂的基础设施投入 费用,如购置服务器、租用带宽等。而基础设施的投入往往是不易估量的,如果一次投入 过大而应用并没有达到预期的流行度,就会造成投资的浪费;反之,如果应用获得了超预 期的反响,用户数量激增,那么就会给服务器、带宽带来巨大的压力,从而造成应用服务 质量下降和客户的流失。 此外,Web应用需要复杂的软件配置,包括数据库、中间件、Web服务器等要素,如 果其中一项配置得不合理,就会产生连锁反应,影响整个应用的表现。这些潜在问题都给 创业公司提出了巨大的挑战。在GAE平台上,Giftag可以将自己的精力集中于业务本身,而 将诸如服务器动态扩展、数据库访问、负载均衡等各个层次的问题交给GAE平台来解决。 正是由于GAE将Web应用所需的基础功能作为服务提供给了Giftag,才使得其可以专注于应 用的开发和优化。 在案例三中,哈根达斯公司要搭建自己的CRM平台,传统的做法是先聘请一支专业的 顾问团队研究公司的业务流程,建模分析并提出咨询报告。然后再雇用一家IT外包公司, 进驻自己的公司对平台进行开发,可能会多次出现需求→设计→实施→需求变更→再设计 →再实施的循环。同时,哈根达斯作为一家冰淇淋制作厂商,还需要投资IT设备,如购买 服务器、交换机、防火墙、各种各样的软件,以及租用带宽等,为系统上线做准备。经历 了这令人精疲力竭的过程后系统终于上线了,但它是不是真的满足了哈根达斯公司最初的 愿望呢?可能永远不会有人知道和提起了。 幸运的是,哈根达斯公司没有重复这条被别的公司走过无数次的老路。Salesforce.com 作为CRM系统的专业提供商,对这个领域有着精深的理解。同时,它能够将已经完成的 CRM应用模块打包,供用户选择。用户只需要如同在超市选购商品一样选择自己需要的功 能模块,让Salesforce.com进行定制集成,一个属于自己的CRM系统就完成了,系统的上线 和维护也将由Salesforce.com的专业团队负责。这样,一家非IT公司就可以专注于它的主营 业务,使IT真正成为公司的支撑而不是拖累。 在案例四中,IBM公司分布在世界各地的9所研究院虽然各自拥有强大的IT基础设施, 第1章 云计算概论 007 但有时单个科学实验对资源的需求超出了其所在研究院具有的资源规模,而且以往各自分 割独立的组织方式很难让各个机构间协作完成一项工作。实际上,蓝色巨人IBM一直在努 力整合自己的IT资源,以降低运营成本。早在2007年,IBM公司就开始着手将运行在3900 台服务器上的业务迁移到30台大型机上,从而减少了80%的电力消耗,同时也促进了公司 业务的整合。 IBM Research Compute Cloud(RC2)的建立把分散于各地的资源从物理和逻辑 上整合在一起,为研究院的科研提供了一个近乎取之不尽的资源池。此外,计算资源 的整合带动了业务的整合,研究员们可以在IBM RC2上共享实验所需的工具、平台甚 至是结果,大大加速了科研的进程。值得注意的是,与前三个案例不同,IBM RC2是 供IBM公司内部使用的私有系统,而不是一个为公司以外的用户提供服务的第三方公 用平台。 通过以上四个典型案例,相信读者已经初步领略到了云计算的魅力和价值。是的,云 计算就是一种更加智慧的信息技术,它化繁为简、化难为易、化不可能为可能。 1.1.2 云计算的定义 1.1.2.1 云计算的来源 在云计算最早被提出的时候,曾经有一种流行的说法来解释“云计算”为何被称 为“云”计算:在互联网技术刚刚兴起的时候,人们画图时习惯用一朵云来表示互联 网,因此在选择一个名词来表示这种基于互联网的新一代计算方式时就选择了“云计 算”这个名词。虽然这个解释非常有趣和浪漫,但是却容易让人们陷入云里雾中,不 得其正解。 进入互联网时代后,人们热衷于上网冲浪,通过浏览网页来获得资讯。当用户在 浏览器上输入网址后,浏览器将会与DNS服务器和网站服务器进行一系列的交互,将 网页内容呈现在用户面前,而这些交互过程是通过互联网经过多次路由转发最终完成 的。因为这个过程对用户是透明的,所以当时人们在绘制互联网示意图时,将网络抽 象成一朵云,意在不去关心网络的转发过程,而去关注服务器端和客户端,如图1.1左 侧所示。 云计算宝典——技术与实战008 图1.1 云计算中的“云” 随着互联网的发展,带宽得到了显著提高,无线接入方式也变得丰富起来,除了个人 电脑外,越来越多的设备已经具有了接入互联网的能力,比如移动电话、办公设备甚至是 家用电器。同样,互联网的作用也不再局限于浏览网页和收发电子邮件,还能够为企业提 供诸如电子商务、客户关系管理等信息服务;为普通用户提供诸如博客、视频等服务;为科 研机构提供强大的计算处理能力。因此,互联网的含义变得充实起来,除了人们普遍认知的接 入、路由等含义,还包括了计算、存储、服务和软件等元素。因此,“云计算”这个名词就应 运而生了。从图1.1右侧我们可以看出,云计算中的“云”不仅包含了网络,更包含了那些曾 经被描绘在云外的事物。这个小小的改变在图上看似简单,实际上蕴含着深刻的变革。 正如用云描绘网络来强调对网络的运用而非关注于其实现细节一样,云计算用云描绘 包括网络、计算、存储等在内的信息服务基础设施,以及包括操作系统、应用平台、Web 服务等在内的软件,就是为了强调对这些资源的运用,而不是它们的实现细节。 1.1.2.2 什么是云计算 了解了云计算为什么被称之为“云”之后,下面我们将给出云计算的定义。其实,这 个概念被提出的时间并不长,然而对这个概念的定义却是百家争鸣。这体现了云计算 包罗万象的特质,也说明业界对它的重视——既然所有人都希望成为云计算产业链 中的一个角色,自然都会从自身的角度出发来定义云计算,那么对于概念的提取就 是一个求同存异的过程。下面,我们先列举一些被人们普遍认可的云计算定义,然 后再给出本书的定义。 在维基百科(Wikipedia.org)中,截止到2010年7月,“云计算”的词条被表述为是一 第1章 云计算概论 009 种基于互联网的计算,在其中共享的资源、软件和信息以一种按需的方式提供给计算机和 设备,就如同日常生活中的电网一样。 专业的IT名词百科Whatis.com援引来自SearchCloudComputing.com的定义,广义地将云 计算解释为一切能够通过互联网提供的服务,这些服务被划分为三个层次:基础设施即服 务(Infrastructure as a Service, IaaS)、平台即服务(Platform as a Service, Paas)和软件即服 务(Software as a Service, SaaS)。 在美国加州大学伯克利分校(UC Berkeley)发表的一篇关于云计算的报告中,云计算 既指在互联网上以服务形式提供的应用,也指在数据中心里提供这些服务的硬件和软件, 而这些数据中心里的硬件和软件则被称为云。 《商业周刊》(BussinessWeek.com)发表文章指出,Google的云就是由网络连接 起来的几十万甚至上百万台的廉价计算机,这些大规模的计算机集群每天都处理着来 自互联网的海量检索数据和搜索业务请求。《商业周刊》在另一篇文章中总结说,从 Amazon的角度看,云计算就是在一个大规模的系统环境中,不同的系统之间相互提供服 务,软件都是以服务的方式运行的,当所有这些系统相互协作并在互联网上提供服务时, 这些系统的总体就成为云。 Salesforce.com认为云计算是一种更友好的业务运行模式。在这种模式中,用户的应用 程序运行在共享的数据中心中,用户只需要通过登录和个性化定制就可以使用这些数据中 心的应用程序。 IBM认为云计算是一种革新的信息技术与商业服务的消费与交付模式。在这种模式 中,用户可以采用按需的自助模式,通过访问无处不在的网络,获得来自于与地理无关 的资源池中被快速分配的资源,并按实际使用情况付费。本书沿用IBM的定义。这种模式 的主体是所有连接着互联网的实体,可以是人、设备或程序。这种模式的客体是服务本 身,包括我们现在接触到的,以及会在不远的将来出现的各种信息与商业服务。这种 模式的核心原则是: 硬件和软件都是资源并被封装为服务,用户可以通过网络按需地访问和使用。 在云计算中,IT业务通常运行在远程的分布式系统上,而不是在本地计算机或者单个 服务器上。这个分布式系统由互联网相互连接,通过开放的技术和标准把硬件和软件抽象 云计算宝典——技术与实战010 为动态可扩展、可配置的资源,并对外以服务的形式提供给用户。该系统允许用户通过互 联网访问这些服务并获取资源。服务接口将资源在逻辑上以整合实体的形式呈现,隐蔽其 中的实现细节。该系统中业务的创建、发布、执行和管理都可以在网络上进行,而用户只 需要按资源的使用量或者业务规模付费。 1.1.3 云计算的特征 在云计算的定义中有四个关键要素,如图1.2所示。 图1.2 云计算的特征 1. 硬件和软件都是资源,通过网络以服务的方式提供给用户 正如上一节所描述的,Amazon EC2将计算处理能力打包为资源提供给用户;Google App Engine将从设计开发到部署实施Web应用所需的软件、硬件平台一起打包提供给用 户;Salesforce.com将专业的客户关系管理应用模块打包成解决方案提供给用户。 在云计算中,资源已经不限定在诸如处理器机时、网络带宽等物理范畴,而是扩展 到了软件平台、Web服务和应用程序的软件范畴。传统模式下自给自足的IT运用模式,在 云计算中已经改变成分工专业、协同配合的运用模式。对于企业和机构而言,他们不再需 要规划属于自己的数据中心,也不需要将精力耗费在与自己主营业务无关的IT管理上。相 反,他们可以将这些功能放到云中,由专业公司为他们提供不同程度、不同类型的信息服 第1章 云计算概论 011 务。对于个人用户而言,也不再需要一次性投入大量费用购买软件,因为云中的服务已提 供了他所需要的功能。 2. 这些资源都可以根据需要进行动态扩展和配置 例如在前面的典型案例中,Amazon EC2可以在极短的时间内为华盛顿邮报初始化200 台虚拟服务器的资源,并在9小时的任务完成后快速地回收这些资源;Google App Engine可 以满足Giftag的快速增长,不断为其提供更多的存储空间、更高的带宽和更快速的处理能 力;Salesforce.com可以为哈根达斯公司在已经成型的CRM系统中动态地添加和删除应用 模块,来满足客户不断改进的业务需求。这些例子都体现了云计算可动态扩展和配置的 特性。 3. 这些资源在物理上以分布式的方式存在,为云中的用户所共享,但最终在逻辑上 以单一整体的形式呈现 对于分布式的理解有两个方面。一方面,计算密集型的应用需要并行计算来提高运 算效率。例如,一个Web应用是由多个服务器通过集群的方式来实现的,此类的分布式系 统,往往是在同一个数据中心中实现的,虽然有较大的规模,由几千甚至上万台计算机组 成,但是在地域上仍然相对集中。 另一方面,就是地域上的分布式。例如,一款商业应用的服务器可以设在位于纽约的华 尔街,但是它的数据备份却由位于德州戈壁中的数据中心完成。 在前面介绍的典型案例四中,IBM公司在世界范围内共拥有9所研究院,IBM RC2将这 些研究院中的数据中心通过企业内部网连接起来,为世界各地的研究员提供服务。作为最 终用户,这些研究员们并不知道也不关心某一次科学运算运行在哪个研究院的哪台服务器 上,因为云计算中分布式的资源向用户隐藏了实现细节,并最终以单一整体的形式呈现给 用户。 4. 用户按需使用云中的资源,按实际使用量付费,而不需要管理它们 例如,华盛顿邮报为尽快完成档案的转换任务,使用了200台虚拟服务器,并为 其所获得的1407小时机时支付了144.62美元。虽然华盛顿邮报没有足够的运算处理能 力,但是云给了它强大的资源来快速完成任务,而它仅需要根据实际使用量来付费。 对于华盛顿邮报来说,如此巨大计算量的任务并不经常出现,因此按照这个标准购置 云计算宝典——技术与实战012 IT设备显然是不合理的。如果没有Amazon EC2,华盛顿邮报在9小时内完成档案的 转换工作将是不可能的。 同样,在Giftag的例子中,Giftag需要做的仅仅是根据其业务的增长而使用更多的 Google App Engine的资源。依托Google强大的数据中心,Giftag拥有近乎无限的资源来满足 新用户的注册,从而避免了自己投资IT基础设施而可能出现的浪费现象或客户流失。 总之,在云计算中软、硬件资源以分布式共享的形式存在,可以被动态地扩展和配 置,最终以服务的形式提供给用户。用户按需使用云中的资源,不需要管理,只需按实际 使用量付费。这些特征决定了云计算区别于自给自足的传统IT运用模式,必将引领信息产 业发展的新浪潮。 1.1.4 云计算的分类 以上我们分析了云计算中“云”的含义,给出了云计算的例子和定义,并总结了云计 算的关键特征。在云计算中,硬件和软件都被抽象为资源并被封装为服务,向用户提供; 用户以互联网为主要接入方式,获取云中提供的服务。细心的读者可能已经发现,本章开 始给出的四个案例之间既有共同点又存在着差别。相同点是,用户都获取了云中的服务, 快速、高效地完成了工作;不同点是,用户获取的服务类型不尽相同。下面我们分别从云 计算提供的服务类型和服务方式的角度出发,为云计算分类。 1.1.4.1 按服务类型分类 所谓云计算的服务类型,就是指为用户提供什么样的服务;通过这样的服务,用 户可以获得什么样的资源,以及用户该如何去使用这样的服务。目前业界普遍认为, 云计算可以按照服务类型分为以下三类,如图1.3所示。 1. 基础设施云(Infrastructure Cloud) 例如在前面的案例一中提到的Amazon EC2。这种云为用户提供的是底层的、接近于直接 操作硬件资源的服务接口。通过调用这些接口,用户可以直接获得计算资源、存储资源和网络 资源,而且非常自由灵活,几乎不受逻辑上的限制。但是,用户需要进行大量的工作来设计 和实现自己的应用,因为基础设施云除了为用户提供计算和存储等基础功能外,不做进一步 任何应用类型的假设。 第1章 云计算概论 013 图1.3 云计算的服务类型 2. 平台云(Platform Cloud) 在前面案例二中提到的Google App Engine就是平台云。这种云为用户提供一个托管平 台,用户可以将他们所开发和运营的应用托管到云平台中。但是,这个应用的开发和部署 必须遵守该平台特定的规则和限制,如语言、编程框架、数据存储模型等。通常,能够在 该平台上运行的应用类型也会受到一定的限制,比如Google App Engine主要为Web应用提供 运行环境。但是,一旦客户的应用被开发和部署完成,所涉及的其他管理工作,如动态资 源调整等,都将由该平台层负责。 3. 应用云(Application Cloud) 例如在前面案例三中提到的Salesforce.com。这种云为用户提供可以为其直接所用 的应用,这些应用一般是基于浏览器的,针对某一项特定的功能。应用云最容易被用 户使用,因为它们都是开发完成的软件,只需要进行一些定制就可以交付。但是,它 们也是灵活性最低的,因为一种应用云只针对一种特定的功能,无法提供其他功能的 应用。 表1.1总结了从服务类型的角度来划分的云计算类型。实际上,正如我们现在所熟 悉的软件架构范式,自底向上依次为计算机硬件—操作系统—中间件—应用一样,这 种云计算的分类也暗含了相似的层次关系。这里不同类型的云其实就是云的不同层次 提供的云计算服务,我们将在第4章从技术的角度详细分析云计算的层次架构,给出 每一层次的主要功能和实现示例。 云计算宝典——技术与实战014 表1.1 按服务类型划分云计算 分类 服务类型 运用的灵活性 运用的难易程度 基础设施云 接近原始的计算存储能力 高 难 平台云 应用的托管环境 中 中 应用云 特定功能的应用 低 易 1.1.4.2 按服务方式分类 云计算作为一种革新性的计算模式,虽然具有许多现有计算模式所不具备的优 势(云计算带来的优势将在后面进行具体分析),但是也不可否认地带来了一系列挑 战,不论是从商业模式上还是从技术上。首先就是安全问题,对于那些对数据安全要 求很高的企业(如银行、保险、贸易、军事等)来说,客户信息是最宝贵的财富,一 旦被人窃取或损坏,后果将不堪设想。其次就是可靠性问题,例如银行希望每一笔交易 都能快速、准确地完成,因为准确的数据记录和可靠的信息传输是让用户满意的必要条 件。还有就是监管问题,有的企业希望自己的IT部门完全被公司掌握,不受外界的干扰和 控制。虽然云计算可以通过系统隔离和安全保护措施为用户提供有保障的数据安全,通过 服务质量管理来为用户提供可靠的服务,但是仍有可能不能满足用户的所有需求。 针对这一系列问题,业界以云计算提供者与使用者的所属关系为划分标准,将云计算 分为三类,即公有云、私有云和混合云,如图1.4所示。用户可以根据需求选择适合自己的 云计算模式。   图1.4 云计算的服务方式 1. 公有云(Public Cloud) 公有云是由若干企业和用户共同使用的云环境,IT业务和功能以服务的方式,通过 互联网来为广泛的外部用户提供;用户无须具备针对该服务在技术层面的知识,无须雇 第1章 云计算概论 015 佣相关的技术专家,无须拥有或管理所需的IT基础设施。我们前面所列举的Amazon EC2、 Google AppEngine和Salesforce.com都属于公有云的范畴。在公有云中,用户所需的服务由一 个独立的、第三方云提供商提供。该云提供商也同时为其他用户服务,这些用户共享这个 云提供商所拥有的资源。 2. 私有云(Private Cloud) 私有云是由某个企业独立构建和使用的云环境,IT能力通过企业内部网,在防火墙内 以服务的形式为企业内部用户提供;私有云的所有者不与其他企业或组织共享任何资源, 例如我们前面提及的IBM RC2。私有云是企业或组织所专有的云计算环境。在其中,用户 是这个企业或组织的内部成员,他们共享着该云计算环境所提供的所有资源,公司或组织 以外的用户无法访问这个云计算环境提供的服务。 3. 混合云(Hybird Cloud) 混合云是整合了公有云与私有云所提供服务的云环境。用户根据自身因素和业务需求 选择合适的整合方式,制订其使用混合云的规则和策略。在这里,自身因素是指用户本身 所面临的限制与约束,如信息安全的要求、任务的关键程度和现有基础设施的情况等,而 业务需求是指用户期望从云环境中所获得的服务类型。有研究表明,例如网络会议、帮助 与培训系统这样的服务适合于从公有云中获得;例如数据仓库、分析与决策系统这样的服 务适合于从私有云中获得。 一般来说,对安全性、可靠性及IT可监控性要求高的公司或组织,如金融机构、政 府机关、大型企业等,是私有云的潜在使用者。因为他们已经拥有了规模庞大的IT基础设 施,因此只需进行少量的投资,将自己的IT系统升级,就可以拥有云计算带来的灵活与高 效,同时有效地避免使用公有云可能带来的负面影响。除此之外,他们也可以选择混合 云,将一些对安全性和可靠性需求相对较低的日常事务性的支撑性应用部署在公有云上, 来减轻对自身IT基础设施的负担。相关分析指出,一般中小型企业和创业公司将选择公有 云,而金融机构、政府机关和大型企业则更倾向于选择私有云或混合云。 值得注意的是,虽然私有云能够为企业或组织创建一个独占的云环境,具有防火墙 内的信息安全保障,提供资源与服务共享的便利,但是拥有与运维一个私有云需要较高的 资金投入与持续的技术支持,即便是实力雄厚的公司也会力不从心。同样,虽然公有云能 够为用户快速而便捷地提供IT能力,但是有些企业和组织希望能够获得更强的私密性,因 云计算宝典——技术与实战016 此,在现实的生产环境中,云的私有性和公有性并不是泾渭分明的,而是存在着多种逐级 过渡的方案,如图1.5所示。 图1.5 私有云至公有云的逐级过渡 除了完全由自己拥有和运维的私有云外,用户还可以选择“被管理的私有云”和“被 托管的私有云”两种提供模式。在被管理的私有云中,承载云环境的IT设备和基础设施仍 由所属的企业或组织拥有,在物理上位于企业的数据中心内,但其私有云的创建和运维将 由专业的第三方公司来完成。一般来说,这样的第三方公司常常会通过以下步骤来帮助客 户完成私有云的搭建:第一,将客户现有的物理资源通过虚拟化技术进行逻辑化,形成便 于划分的资源池;第二,在该逻辑资源池上创建业务应用,并订立服务目录以便使用者浏 览;第三,为业务应用提供自助访问接口和用量计费功能,服务上线并为私有云所属的企 业或组织内用户所用。此后,该第三方公司还将为客户持续地提供在运维上的支持,如安 全管理、业务升级、新服务上线等。 与被管理的私有云相同,被托管的私有云的创建与运维将由第三方公司来完成。相比前 者更进一步,如果客户选择后者作为自己拥有私有云的模式,它将不再需要建设自己的数据 中心,云环境所需的IT设备和基础设施将被托管在由第三方公司提供的专业数据中心内,并 可根据合同的订立来保证客户在该数据中心内对资源在物理上或逻辑上的独占性。这种独占 性是该模式与公有云的本质区别。在公有云中,不同客户需通过多租户(Multi Tenancy) 技术来共享底层资源,有关该技术细节将在第10章中介绍。 同样,用户对于公有云的选择还可以分为排他的公有云和开放的公有云两种。在排他 云中,云服务的提供者和使用者不是同一个企业,但它们事先知道谁会提供何种服务,谁 会使用何种服务,它们通过线下的协商确定服务价格和服务质量。排他云通常出现在企业 的联盟中,例如:某大企业与它的众多供应商和业务伙伴间可以建立排他云,大企业为供 应商们提供云服务;某一行业联盟中的企业间可以建立排他云,比如:航空公司、酒店、 旅行社等组成的联盟。 第1章 云计算概论 017 在开放的公有云中,服务的使用者和提供者在服务预订前彼此不知晓对方,他们的关 系是通过在线服务订阅的方式确立的。服务条款通常是由服务提供方预先定义和控制的, 而服务价格和服务质量约定也是自动的和标准化的,由服务提供方预先设定。 综上,从私有云到公有云,第三方公司能够为客户提供不同深度的自底向上的整合服 务,帮助用户便捷可靠地获得私有云,同时有效减轻其建设数据中心、购置基础设施和运 维云环境的负担。 1.1.5 相关概念辨析 在计算机科学技术发展的历史上,曾经出现过一些里程碑式的技术。这些技术产生 的时间或远或近,但都对当今世界的IT运用模式产生了巨大的影响。这些技术包括并行计 算、网格计算和效用计算。罗马不是一天建成的,同样,云计算也不是一蹴而就的,云计 算是从这些技术中逐渐演进而来的,既一脉相承,又有所不同。下面我们就来辨析云计算 与这些相关概念的异同。 1.1.5.1 并行计算 并行计算(Parallel Computing)将一个科学计算问题分解为多个小的计算任务,并 将这些小任务在并行计算机上同时执行,利用并行处理的方式达到快速解决复杂运算问 题的目的。并行计算一般应用于诸如军事、能源勘探、生物、医疗等对计算性能要求极 高的领域,因此也被称为高性能计算(High Performance Computing)或超级计算(Super Computing)。并行计算机是一群同构处理单元的集合,这些处理单元通过通信和协作来 更快地解决大规模计算问题。常见的并行计算机系统结构包括共享存储的对称多处理器 (SMP)、分布式存储的大规模并行机(MPP)和松散耦合的分布式工作站集群(COW) 等。解决计算问题的并行程序往往需要特殊的算法,编写并行程序需要考虑很多问题之外的 因素,例如各个并发执行的进程之间如何协调运行、任务如何分配到各个进程上运行等。 并行计算机可以说是云环境的重要组成部分,例如案例四中IBM研究院科研人员使用 的IBM RC2。与云计算的思想相似,目前世界各国已经集中建立了若干超级计算中心来服 务于该区域内有并行计算需求的用户,并采用分担成本的方式进行付费。但是,云计算与 传统意义上的并行计算相比,又存在明显的区别。 首先,并行计算需要采用特定的编程范例来执行单个大型计算任务或者运行某些特定 云计算宝典——技术与实战018 应用,而云计算需要考虑的是如何为数以千万计的不同种类应用提供高质量的服务环境, 以及如何提高这个环境对用户需求的响应从而加速业务创新。一般来说,云计算对用户的 编程模型和应用类型等没有特殊限定,用户不再需要开发复杂的程序,就可以把他们的各 类企业和个人应用迁移到云计算环境中。 其次,在并行计算中,计算资源往往集中在单个数据中心的若干台机器或者集群上。 云计算则更加强调用户通过互联网使用云服务,并在云中利用虚拟化进行大规模的系统资 源抽象和管理。云计算中资源的分布更加广泛,正如上文所述,它已经不再局限于某个数 据中心,而是扩展到了多个不同的地理位置。同时,由于采用了虚拟化技术,云计算中的 资源利用率可以得到有效的提升。 由此可见,云计算是互联网技术和信息产业蓬勃发展背景下的产物,完成了从传统 的、面向任务的单一计算模式向现代的、面向服务的多元计算模式的转变。 1.1.5.2 网格计算 网格计算(Grid Computing)是一种分布式计算模式。网格计算技术将分散在网络中的空 闲服务器、存储系统和网络连接在一起,形成一个整合系统,为用户提供功能强大的计算及存 储能力来处理特定的任务。对于使用网格的最终用户或应用程序来说,网格看起来就像是一个 拥有超强性能的虚拟计算机。网格计算的本质在于以高效的方式来管理各种加入了该分布式系 统的异构松耦合资源,并通过任务调度来协调这些资源合作完成一项特定的计算任务。 可见,网格计算着重于管理通过网络连接起来的异构资源,并保证这些资源能够充分 为计算任务服务。通常,用户需要基于某个网格的框架来构建自己的网格系统,并对其进 行管理,执行计算任务。而云计算则不同,用户只需要使用云中的资源,不需要关注系统 资源的管理和整合。这一切都将由云提供者进行处理,用户看到的是一个逻辑上单一的 整体。因此,在资源的所属关系上存在着较大差异,也可以说在网格计算中是多个零散 资源为单个任务提供运行环境,而在云计算中是单个整合资源为多个用户提供服务。 另外由于网络因素,网格计算的终端通常只进行小量的计算和数据传输。因此网格 计算通常不适合需要大规模数据传输的计算。 1.1.5.3 效用计算 效用计算(Utility Computing)强调的是IT资源,如计算和存储等,能够根据用户的要 第1章 云计算概论 019 求被按需地提供,而且用户只需要按照实际使用情况付费。效用计算的目标是IT资源能够 像传统公共设施(如水和电等)一样地供应和收费。效用计算使得企业和个人不再需要一 次性的巨额投入就可以拥有计算资源,而且能够降低使用和管理这些资源的成本。效用计 算追求的是提高资源的有效利用率,最大程度地降低资源的使用成本和提高资源使用的灵 活性。 效用计算所提倡的资源按需供应、用户按使用量付费的理念与云计算中的资源使用理念 相符。云计算也可以按照用户的资源需求分配运算、存储、网络等各种基础资源。比效用计 算更进一步的是,云计算已经有了很多实际应用案例,所涉及的技术和架构可行性更强。 云计算所关注的是如何在互联网时代以其自身为平台开发、运行和管理不同的服务。 云计算不但注重基础资源的提供,而且注重服务的提供。在云计算环境中,不但硬件等IT 基础资源能够以服务的形式来提供,应用的开发、运行和管理也是以服务的形式提供的, 应用本身也可以采用服务的形式来提供。因此,云计算与效用计算相比,技术和理念所涵 盖的范围更广泛,可行性更强。 1.1.5.4 物联网 物联网(Internet of Things,IoT)是一个将人、物理实体和信息系统互联起来的遍布全 球的系统。它通过可扩展、价格可以接受的技术,如大范围的数据搜集、智能网络、预测 分析和深度优化等,来更好地管理物理世界。物联网是当前重要的创新领域。国务院总理 温家宝2009年11月3日在人民大会堂向首都科技界发表题为《让科技引领中国可持续发展》 的讲话中明确指出:信息网络产业是世界经济复苏的重要驱动力。全球互联网正在向下一代 升级,传感网和物联网方兴未艾。温总理的讲话将物联网提升到国家战略的高度,物联网的 应用也日趋丰富,如高速公路不停车收费系统、公路铁路车辆调度系统、物流货品追踪管 理、学生进出校门管理、手机移动支付系统等,都是基于物联网理论的应用探索。 物联网的核心和基础在于物品与物品之间的互联。相对于传统的互联网,物联网将计 算机间的互联互通延伸和扩展到物与物之间。云计算与物联网在概念上有很强的关联性。 我们可以将物联网看做是处于前端的传感器与网络设备、处于核心的云计算海量数据处理 平台和处于上层的应用系统这三者的结合体。 云计算作为物联网数据处理的核心平台,适于处理物联网中地域分散、数据海量、动 态性和虚拟性强的应用场景。它能够促进物联网底层传感数据的共享,为分析与优化提供 云计算宝典——技术与实战020 超级计算能力,从而更高效地提供更可靠的服务。如果将物联网比喻为人体,那么传感器 就如同感知器官,网络就如同神经系统,云计算就如同大脑。传感器所获得的物理世界的 信息通过网络汇聚到云中,通过云计算提供的处理、存储和共享能力,进行有针对性的调 优,再通过一定的反馈机制作用于物理世界,使其更加智慧而有效地运行。可见,物联网 与云计算是相辅相成的概念。云计算为物联网提供了使其发挥效用的核心能力,物联网为 云计算提供了宽广而前景光明的舞台。 1.2 云计算的优势 正如达尔文在其著作《物种起源》中指出的那样,自然界中的生物是按照物竞天择、 适者生存的规律一步一步进化而来的,优秀的物种会发展出适应当前环境的特征,而正是 这些特征使得该物种能够战胜残酷的生存考验,最终繁衍下来。云计算作为互联网时代最 新提出的IT运用模式,必然有其技术的进步和独到的优势,才能在IT这个高速发展的产业 里成长起来。本节将按照从商业到技术的顺序,首先在IT产业的层面,从优化产业布局和 推进专业分工的角度分析云计算的优势,再逐渐深入到云计算的运行和维护层面,从提升 资源效率、减少运营投资、降低管理成本的角度分析云计算的本质优势。相信读者阅读过 本节后,将对云计算的未来充满信心。 1.2.1 优化产业布局 正如前面所述,云计算将企业原先自给自足的I T运用模式改变为由云计算提供商按需 供给的模式。IT业界将出现一些实力雄厚的云计算提供商,他们拥有雄厚的技术实力和管 理经验,雇用专业的商业专家和研发人员。最重要的是,他们有一座甚至许多座规模巨大 的计算中心来支撑云中的服务。在摩尔定律的指引下,硬件成本正在不断降低,这些未来 的云计算运营商心目中的关键资源不再是服务器,而是运行这些服务器所必不可少的电力 资源。 以正在大规模投资云计算的Google公司为例,据推测(关于数据中心的建造细节一直 以来被各个公司列为商业机密),该公司在多个地点拥有约40余座数据中心,在这些数 第1章 云计算概论 021 据中心里同时运行着数百万台服务器。据估计,仅以该公司在美国华盛顿州Dalles建设的 数据中心为例,其电力消耗就高达约103兆瓦,相当于82000户家庭一年的用电量。 电力作为一种传统资源,分布很不均匀。由于自然条件和政策法规的影响,各地的电 价具有很大差异,如表1.2所示。在当前技术条件下,用电网传送电力的成本和产生的浪费 要远大于用互联网传输数据,而电价又忠实地反映了获取电力资源的难易程度,因此云计 算提供商在建立大规模数据中心的时候都会充分考虑这个因素,将大型数据中心建造在电 力资源丰富、地理条件安全、很少有自然灾害的地方;同时又要充分考虑诸如当地法律政 策、是否靠近互联网重要结点等非自然因素。 表1.2 美国部分地区工业电价比较(2008年) 电价(美分/千瓦时) 地点 可能的原因 4.48 爱达荷州 丰富的水电资源 10.04 加州 电网远距离传输,州法律禁止火电厂的建造 26.05 夏威夷 油料需要通过海运进岛进行发电 可见,进入云计算时代后,IT产业已经从以前那种自给自足的作坊模式,转化为具有 规模化效应的工业化运营,一些小规模的单个公司专有的数据中心将被淘汰,取而代之的 是规模巨大而且充分考虑资源合理配置的大规模数据中心。而正是这种更迭,生动地体现 了IT产业的一次升级,从以前分散的、高耗能的模式转变为集中的、资源友好的模式,顺 应了历史发展的潮流。 1.2.2 推进专业分工 正如1.2.1节所述,不同于中小型企业的数据中心只能在距离企业不太远的地方选址以 便维护,专业公司的大型数据中心可以充分利用选址灵活的优势合理配置资源。此外,大 型数据中心具有实力雄厚的科研技术团队、丰富的维护管理经验来体现专业分工的优势。 云计算提供商普遍采用大规模数据中心,比中小型数据中心更专业,管理水平更高, 提供单位计算力所需的成本更低廉,如表1.3所示。中小规模的数据中心采用风冷的方式进 行温度调节,空调耗电量较大,而大型数据中心一般采用专业的水冷与风冷相结合的方式 进行温度调节,这样的数据中心一般建立在水资源丰富的河边,将用于制冷的水抽取到制 冷单元,当水温升高后再送到室外自然冷却,相对风冷来说这是一种既节能环保又经济的 云计算宝典——技术与实战022 温度调节方式。 表1.3 大型数据中心与中小型数据中心相比的成本优势 数据中心属性 中小型数据中心 大型数据中心 服务器个数 < 2000 > 2000 每个管理员管理服务器数 < 500 > 500 PUE值 2.0~2.5 1.0~1.5 服务器供电方式 交流电 直流电 电价 高 低 制冷方式 风冷 水冷 + 风冷 提供单位计算力的成本 高 低 注:PUE即Power Usage Effectiveness,是数据中心总设备能耗与IT设备能耗的比值,PUE越接近1表明数据中心的 能效水平越好。 同时,专业的云计算提供商可以有更多的科研和经费投入来推动数据中心的技术革 新。例如,目前大多中小型数据中心采用交流电的供电方式,仅能达到约75%的能效比,其 中有25%的电能被白白浪费,转化成了热量,加剧了温度调节所需的能源消耗。但通过技术 革新,改用直流电源的方式进行供电,仅此一项,大型专业数据中心就可以节电约30%。 除了在硬件上更加专业,云计算提供商还具有更完善的软件,这包括具有丰富知识和 经验的管理团队及与其配套的管理软件。在中小型的数据中心,平均每个工作人员最多可 以管理170台服务器。而在大型数据中心,由于有专业团队和工具的支持,每个工作人员 可以同时管理的服务器数量达1000台以上。因此,人力成本这一项可以被大幅度削减。 由此可见,云计算带来的是更加专业的分工,更进一步优化的IT产业格局。通过让专 业的人做专业的事,各取所长,扬长避短,有效避免了IT产业中可能产生的内耗。另一方 面,专业分工也孕育了新的产业契机,除了现有的大型IT公司外,一批新兴的高科技企业 也将在云计算中找到自己的位置并逐渐成长起来。 1.2.3 提升资源利用率 前面我们在IT产业的层面,从产业布局和专业分工的角度阐述了云计算的优势。下面我 们将深入到云计算所涉及的各个实体,讨论这个新兴的计算模式将赋予它们怎样的优势。 第1章 云计算概论 023 在云计算模式下,高科技企业、传统行业甚至是互联网公司的IT业务都可以在不同程 度上外包给专业的云计算提供商进行管理。如在上文介绍的典型案例二中,Giftag公司就将 其设计的Web 2.0应用交由Google App Engine托管,Google公司根据其业务量的变化来调整 和分配其所需的资源。值得注意的是,Giftag并不是Google App Engine平台上唯一的托管应 用。实际上,它与成千上万其他的Web应用一起共享这个平台提供的服务与资源。 如图1.6所示是一个Web应用的典型负载变化图,从图中可以看出负载呈现出三个主要 规律:其一是负载的周期性变化规律,通常由昼夜差异和周末与工作日的差异引起,基本 可以通过长期观察来预测;其二是一次性任务或突发事件引起的负载,例如某热门话题会 引起网站的访问量激增,通常无法预测;其三是由于业务增长引起的负载长期增长趋势, 一定程度上可以预测。 面对这样变化的负载,传统的Web应用提供商或者企业专有数据中心应该如何来规 划资源呢?一般来说无外乎图中的A、B、C三种方式。方式A仅考虑短期的负载来分配资 源,该方式产生的浪费最少,仅在负载周期低谷时有较大资源浪费。然而,在不对业务发 展进行预测的情况下分配资源,会导致一段时间后因资源不足影响业务系统运行,或不久 就需要再次扩容,带来管理上的复杂性。目前被采用较多的是方式B,这种方式考虑了负 载长期的增长趋势,有一定预见性地增加了资源,但相比方式A来说,造成短期内一定的 资源浪费。方式C为了应对不可预测的突发事件或一次性任务而准备大量资源,在绝大多 数情况下资源处于严重浪费的状态。这种方式仅适用于业务系统极其重要、为保证可用性 可以不计成本的应用。 图1.6 典型的业务系统负载变化及传统的资源分配方式 云计算宝典——技术与实战024 可见,传统的数据中心无法兼顾业务的可用性和资源的高效利用,只能在二者之间 达到某种程度的平衡。一般来说,企业为了保证业务系统的高可用性,会牺牲掉资源的 高效性。据统计,多数企业数据中心的资源利用率在15%以下,有的还不到5%。而在云 计算的平台中,若干企业的业务系统共用同一个大的资源池,资源池的大小可以适时调 整,还可以通过动态资源调度机制对资源进行实时的合理分配。即使有突发事件对某一 个业务系统产生冲击,也不会对整个资源池造成很大影响。通过这些手段,云计算平台 中的资源利用率可达80%以上,与传统数据中心的资源利用率相比有大幅度提升。 1.2.4 减少初期投资 从云服务提供商的角度看,同时托管多个服务提高了资源利用率,也降低了长期的运 营成本。同样,对于将自己的IT业务外包给云计算提供商的公司,他们的一次性IT投入也 降到了最低,从而有效地规避了财务风险。 云计算将取代传统的企业专有数据中心。企业无须拥有硬件,而是直接使用云中的计 算资源。云计算即用即付费的方式消除了企业的一次性投入,包括数据中心的营建,以及 硬件设备的购置和定期更换。这种一次性投入对企业的现金流冲击较大,它意味着企业预 付了若干年的投入。IT设备的平均寿命是3~5年;制冷设备、监控设备、门禁系统等其他 设备的使用寿命则是10~20年;如果再考虑上数据中心的建筑寿命,就可以达到几十年之 久。这样巨额的一次性投入将使企业背负沉重的负担。此外,一旦企业发生较大变化,如 业务转型、系统下线、政策变化等,前期投入的资产就有可能面临被折价处置的困境。 在大多数情况下,软件同样也是一项高昂的支出。如果需要一套高质量的行业解决方 案,企业首先要购买构建该解决方案所必需的中间件软件的许可证,然后在这个基础上购 买或者开发自己所需要的特定解决方案。除此之外,当这些服务器或者软件被购入以后, 很多时候它们其实并没有被充分利用。因为系统的负载是不均衡的,甚至有些时候系统是 空闲的,即并不处理任何用户请求。 回顾本章开始时华盛顿邮报的例子,显然以报社现有的IT资源是无法完成档案格式转 换工作的。但是,报社也不可能为了这个任务而进行一次性投入,购买功能强大的计算机 设备。而恰好是云计算提供的“按使用付费”的计价模型有效地降低了用户的IT成本,使 不可能的任务成为可能。 第1章 云计算概论 025 云计算帮助用户降低IT成本体现在两个方面: (1)用户不再需要进行巨大的一次性IT投资,彻底省去了购置、安装、管理软硬件 的费用,因为他们可以从云计算提供商那里租用这些IT基础设施; (2)用户在使用这些IT资源时,可以按照自己的实际使用量付费。如表1.4所 示列出了Amazon公司的AWS业务为美国东海岸用户提供的打包计算资源实例及计价 标准。在这种计价模型中,时间是按照小时来计算的,运算平台分为Linux/UNIX和 Windows两种,并根据占用资源的情况分为若干等级,各个等级的计价有所不同。用户 可以在负载较低的时候选择较小的实例,甚至在空闲的时候停止部分虚拟机的运行。 表1.4 Amazon公司提供的配置实例和收费标准(美国东海岸,2010年7月) 类型 型号 实例配置 Linux/UNIX系统 Windows系统 标准 小 1.7GB内存,1个EC2计算单元,160GB存储, 32位平台 0.085美元/小时 0.12美元/小时 大 7.5GB内存,4个EC2计算单元,850GB存储, 64位平台 0.34美元/小时 0.48美元/小时 超大 15GB内存,8个EC2计算单元,1690GB存储, 64位平台 0.68美元/小时 0.96美元/小时 高CPU 中 1.7GB内存,5个EC2计算单元,350GB存储, 32位平台 0.17美元/小时 0.29美元/小时 超大 7GB内存,20个EC2计算单元,1690GB存储, 64位平台 0.68美元/小时 1.16美元/小时 高内存 超大 17.1GB内存,6.5个EC2计算单元,420GB存 储,64位平台 0.5美元/小时 0.62美元/小时 双倍超大 34.2GB内存,13个EC2计算单元,850GB存 储,64位平台 1.2美元/小时 1.44美元/小时 四倍超大 68.4GB内存,26个EC2计算单元,1690GB存 储,64位平台 2.4美元/小时 2.88美元/小时 除了以上这种按小时的快速实例计费方案,Amazon公司还提供了其他可选方案,比如 包年和竞拍方案。采用包年方案的用户只需一次性支付一定数额的费用,即可以相对更低 的小时资费获得案例一的一年或者三年的使用权,该方案适合明确而稳健的业务需求;采 用竞拍方案的用户能够以极低的价格拍得AWS在系统低负载时的实例,该方案适合对成本 要求严格但对可用性要求较低的业务需求,或者离线处理的非实时性应用。 云计算宝典——技术与实战026 综上所述,云计算提供的这种在类型和时间上更加细粒度、在租期和要约上更加灵活 的计费模型将有助于用户根据自身业务需求的特点来进行因地制宜的选择,达到减少初期 IT投资的目标。 1.2.5 降低运营成本 对于云计算的用户来说,除了降低IT的使用门槛,更重要的是云计算平台还可以帮助 他们实现应用的自动化管理。对于应用的运行和管理来讲,云计算的出现能够使用户获得 更高的灵活性和自动化。 对应用管理的动态、高效率、自动化是云计算的核心。它要保证用户在创建一个服务 的时候,能够用最少的操作和极短的时间就完成资源分配、服务配置、服务上线和服务激 活等一系列操作。与此类似,当用户需要停用一个服务的时候,云计算能够自动完成服务 停止、服务下线、删除服务配置和资源回收等操作。在虚拟化技术的支持下,Web应用可 以被做成虚拟器件,当需要启动服务的时候,被快速部署到云计算环境中;当服务不再需 要时,可以取消部署以释放占用的资源。可见,云计算可以在软件和解决方案等不同层次 提供极大的灵活性与自动化。 除了应用的部署与删除,在应用的整个生命周期中,时时刻刻需要按照其当前状态进 行动态管理,比如根据业务需求增删功能模块、增减资源配置等。在云计算中,这些工作也 将在不同程度上由云平台自动完成,云平台为用户提供了灵活的业务管理和便捷的服务。 1.2.6 产生新创价值 作为一种革命性的信息产业浪潮,云计算能够形成新的业务价值链,促进跨领域的创 新协作,从而产生更高的价值。在以云计算推动的新价值链产生过程中,能够创造更多的 就业机会,产生更多的新兴服务,建立新兴产业。 以我国台湾地区为例,随着2010年4月“云计算产业发展方案”的推出,一项跨度5 年、投资240亿元新台币的规划进入人们的视野,预计该规划将在2年内改变千万民众的生 活,创造5万个就业岗位,并最终实现1万亿元新台币的产值。台湾地区计划整合其在信息 第1章 云计算概论 027 技术、工程制造和基础设施上的优势,通过推动云计算来实现产业升级与节能减排的目 标。“云计算产业发展方案”将由5大组成部分全方位推动,包括发挥台湾当地整体施政 效益,提升该地区运作效能;提升民众生活水平;提升硬件附加价值;带动产业投资,加 速产业转型;加强基础研究与产业科技研发等。 可见,云计算的革新虽然来自于IT行业,却将对诸如行政、教育、医疗等各个行业产 生深远的影响。例如在中国台湾,2年后纸发票就有可能被全面取代,未来学生将连书包 也不用带,市民看病也有统一的电子病历。云计算帮助实现了信息的整合与快速获取,将 流程化繁为简,改变了人们的生活形态,并在这种新的形态中孕育了创新价值。 1.3 云计算产生的原动力 在1.2.6节,我们介绍了云计算的本质优势。实际上,早在1966年,D. F. Parkhill就在其 经典的《计算机效用事业的挑战》(The Challenge of the Computer Utility)一书中大胆预测 了一个计算能力如同水和电一样被供给的世界。此后,计算机科学家们向着这个目标不断 努力探索,却始终没有一个成功的方案让工业界与市场接受。但是,云计算的出现正在改 变这一切。云计算让人们了解到,原来计算、存储和应用也可以像水和电一样地去获得。 在过去的三十年中,我们目睹了发达国家将低端制造业向发展中国家转移,从而完成 自身产业升级的全过程。上一节分析了云计算带来的优势,从IT产业的角度出发,云计算 顺应了资源合理配置、合理专业化分工的历史潮流。由此,规模效益与全球化分工在IT业 界逐渐形成。正如托马斯·弗里德曼在《世界是平的》这本书中所述,分布在世界各地的 企业和个人正在由互联网更紧密地联系起来,世界正变得越来越平坦,资源合理配置、专 业化分工和规模效益这些原本只在传统制造业中出现的名词已经被应用于IT产业。 可见,云计算带来的是I T产业的转型和升级。不仅各个微观经济实体成为了云计算产 业链中的参与者,各国政府也同样重视这一产业的重要变革。毕竟,就如同制造业的变革 导致了全球范围内的重新分工,云计算的出现也将引发IT产业在世界范围内的再分工。世界 各国,尤其是新兴发展中国家不应错过这个难得的机遇以实现自己产业结构的升级。各国政 府对于高科技产业的重视程度和投入力度是推动云计算向前发展的重要动力。 云计算宝典——技术与实战028 在技术层面,云计算之所以在今天产生,是六方面原动力共同作用的结果,如图1.7 所示。 图1.7 云计算产生的原动力 (1)芯片和硬件技术的飞速发展,使得硬件能力激增、成本大幅下降,让独立运作 的公司集中可观的硬件能力实现规模效益成为可能。 (2)虚拟化技术的成熟,使得这些硬件资源可以被有效地细粒度分割和管理,以服 务的形式提供硬件和软件资源成为可能。 (3)面向服务架构的广泛应用,使得开放式的数据模型和通信标准越来越广泛地为 人们使用,为云中资源与服务的组织方式提供了可行的方案。 (4)软件即服务模式的流行,云计算以服务的形式向最终用户交付应用的模式被越 来越多的用户所接受。 (5)互联网技术的发展,让网络的带宽和可靠性都有了质的提高,使得云计算通过 互联网为用户提供服务成为可能。 (6)Web 2.0技术的流行和广泛接受,改变了人们使用互联网的方式,通过创新的用 户体验为云计算培育了使用群。 第1章 云计算概论 029 下面具体介绍这些推动云计算出现和发展的技术原动力。 1.3.1 芯片与硬件技术 半导体芯片技术遵循着摩尔定律在不断发展,摩尔定律是指集成电路上可容纳的晶 体管数目,约每隔18个月便会增加一倍,性能也将提升一倍。同时计算能力、内存容量、 磁盘存储容量也相应地快速提升。多核技术可以在一枚处理器中集成多个完整的计算引 擎,它的出现规避了仅仅提高单核芯片的速度而产生过多热量且无法带来相应的性能改 善的问题。处理器位数的提高与总线技术的提升,使系统能够支持容量与吞吐量都更大 的内存,满足日益增长的应用需求,使更多的任务可以同时运行。随着磁记录技术和机 械工艺的不断改进,磁盘的存储容量在增大,数据传输率在提高,寻迹时间在缩短。这 些芯片与硬件技术的变革直接作用于计算机系统,使单个系统的能力越来越强,成本越 来越低。 除了计算机系统能力的提高,系统间的通信能力也在增强。IEEE 802.3ae定义了带宽 为10GB的以太网标准,企业级交换机也支持了10GB全速第二层转发。大量相对廉价的x86 系统可以通过高速网络被组织成为大规模的分布式系统,通过协同和冗余来获得以往在大 型机上才能达到的处理速度和可靠性。但是,大量地运用廉价系统也带来了这样或那样的 问题,如大规模系统难于维护、资源消耗高等。在探索解决这些问题的新技术的过程中, 云计算应运而生。 芯片与硬件技术的提升也为数据中心的建造创造了便利条件。伴随着速度的不断 提升,硬件价格也在不断下降。以前,建设大规模数据中心所需的巨大资金投入,只 有极少数企业或者政府机构能够负担得起。现在,由于硬件性能的提升和价格的下降, 建造大型数据中心已经不再是不可实现的目标。这就为云服务提供商构建公有云,为企业 机构用户构建私有云创造了可能。 1.3.2 资源虚拟化 在云计算中,数据、应用和服务都存储在云中,云就是用户的超级计算机。因此,云 计算要求所有的资源能够被这个超级计算机统一管理。但是,各种硬件设备间的差异使它 们之间的兼容性很差,这为统一的资源管理提出了挑战。 云计算宝典——技术与实战030 虚拟化技术可以将物理资源等底层架构进行抽象,使得设备的差异和兼容性对上层应 用透明,从而允许云对底层千差万别的资源进行统一管理。此外,虚拟化简化了应用编写 的工作,使得开发人员可以仅关注于业务逻辑,而不需要考虑底层资源的供给与调度。在 虚拟化技术中,这些应用和服务驻留在各自的虚拟机上,有效地形成了隔离,一个应用的 崩溃不至于影响到其他应用和服务的正常运行。不仅如此,运用虚拟化技术还可以随时方 便地进行资源调度,实现资源的按需分配,应用和服务既不会因为缺乏资源而性能下降, 也不会由于长期处于空闲状态而造成资源的浪费。最后,虚拟机的易创建性使应用和服务 可以拥有更多的虚拟机来进行容错和灾难恢复,从而提高了自身的可靠性和可用性。 可见,正是由于虚拟化技术的成熟和广泛运用,云计算中计算、存储、应用和服务都 变成了资源,这些资源可以被动态扩展和配置,云计算最终在逻辑上以单一整体形式呈现 的特性才能实现。虚拟化技术是云计算中最关键、最核心的技术原动力。 1.3.3 面向服务架构 面向服务架构(Service Oriented Architecture,SOA)是一种IT架构设计模式,通过这 种设计,用户的业务可以被直接转换成为能够通过网络访问的一组相互连接的服务模块。 这个网络可以是本地网络或者是互联网。面向服务架构所强调的是将业务直接映射到模块 化的信息服务,并且最大程度地重用IT资产,尤其是软件资产。当使用面向服务架构来实 现业务时,用户可以快速创建适合自己的商业应用,并通过流程管理技术来加速业务的处 理,促进业务的创新。面向服务架构还可以为用户屏蔽掉运行平台及数据来源上的差异, 从而使得IT系统能够以一种一致的方式提供服务。 面向服务架构的设计思想引领了Web服务技术的发展,使得开放式的数据模型和通信 标准越来越广泛地为人们使用,更大程度地促进了已有信息系统的互联。面向服务架构通 过基础设施层、业务层、服务层、流程层的层次划分,将模块化的服务和标准化的流程封 装成为可以被用户直接应用的组件,允许用户按照自己的实际情况选择、搭建灵活的IT架 构,满足业务需求。 资源和功能服务化是云计算的一个核心思想。面向服务架构为云中的资源与服务 的组织方式提供了可行的方案。云计算依赖于面向服务架构的思想,通过标准化、流 程化和自动化的松耦合组件为用户提供服务。不过,云计算将不仅是一种设计架构的 第1章 云计算概论 031 模式或方法,而且是一个完整的应用运行平台,基于面向服务架构思想构建的解决方 案将在云中运行,服务于云外的用户。 1.3.4 软件即服务 软件即服务(Software as a Service,SaaS)是一种通过互联网提供软件的服务模式, 用户不用再一次性购买软件,而改向服务提供商租用软件,且无须对软件进行维护,服务 提供商会全权管理和维护软件。其核心理念是将软件直接提供为服务,从而改变目前常见 的软件销售并安装在客户自己的计算机上的这种消费及使用模型。对于中小型企业来说, SaaS消除了购买、安装和维护基础设施、中间件和应用程序的投资环节。从技术方面来 看,企业无须再配备专业技术人员进行管理,同时又能得到最新的技术应用。 此外,SaaS也深刻改变了IT业界的商业模式。“长尾理论”被认为是使SaaS在商业上 取得成功的理论基础。长尾理论讲求的是充分发掘那80%的零散但充满潜力的市场。从同 样的理论出发,利用软件即服务的思想,云计算可以开发那部分曾经无法拥有专业计算中 心和Web应用的客户,尤其是中小企业和初创型公司,为他们提供那些曾经只有实力雄厚 的大公司才能够负担得起的IT基础设施和应用。 软件即服务技术是云计算的先行者,比如软件的远程使用、按需付费模式。然而软件 即服务提供商一般仅仅提供某一种特定的应用软件。云计算就是把这种单一的模式更广泛 推广的技术,其采用的虚拟化等技术使得普通软件也可以成为服务,比如Amazon公司的计 算和存储服务就可以适应于企业的更多应用类型。 1.3.5 互联网技术 近二十年来,世界各国在互联网基础设施建设方面进行了巨额的投资,互联网的带 宽和可靠性都得到了大幅提升,网络的触角所涉及的区域也越来越广。目前,信息技术的 发展使得世界上大部分的业务都离不开互联网的支持,互联网已成为世界运转不可缺少的 平台。网上纷繁复杂的业务对于互联网上资源的稳定性、可靠性、安全性、可用性、灵活 性、可管理性、自动化程度甚至节能环保等特性都提出了苛刻的要求,这一切都在不断推 动着互联网技术的发展。正是由于互联网的发展,使得云计算中跨地域的资源共享与服务 提供成为可能。 云计算宝典——技术与实战032 除了骨干网的发展,互联网的接入方式也发生了质的转变。从PSTN拨号上网到ADSL 宽带上网,从单一的有线连接到灵活的无线接入,从高速而廉价的WiFi到潜力巨大的3G和 LTE,从单一的计算机接入到手机、汽车及各种家用电器的接入,可以说,互联网已经是 随时随处可用了。不论是在办公室、在家,还是在路途中,稳定的互联网接入是用户获取 云计算中丰富多彩资源的基础,不断提高的带宽是用户获得完美体验的前提。正是由于互 联网接入的普及和改善,使得用户通过互联网使用远程云端的服务成为可能,在用户和云 间搭起了宽阔的桥梁。 1.3.6 Web 2.0技术 Web 2.0浪潮推动了Web的功能创新性、信息共享程度和用户使用体验的长足进 步。今天,它已经成为实际意义上的标准互联网运用模式。以博客(Blog)、内容聚合 (RSS)、百科全书(Wiki)、社会网络(SNS)和对等网络(P2P)为代表的Web 2.0应 用已经被用户广泛地接受和使用。Web 2.0的出现让用户从信息的获得者变成了信息的贡 献者,也让富互联网应用(Rich Internet Application,RIA)成为网络应用的发展趋势。例 如,Ajax是支持RIA的编程框架,帮助RIA在客户端实现友好而丰富的使用感受。在该框架 中,HTML和CSS为信息提供静态表述,JavaScript负责信息的动态呈现及信息与用户的交 互。在Ajax中,浏览器和服务器之间的交互是异步的,这样就避免了页面被重复刷新,从 而实现了类似于本地程序的用户体验。 Web 2.0的出现和广泛流行深刻地影响了用户使用互联网的方式。现在,人们越来越 习惯从互联网上获得所需的应用与服务,同时将自己的数据在网络上共享与保存。而以 往,这些都是用户在个人电脑上完成的工作。个人电脑渐渐不再是为用户提供应用、保存 用户数据的中心,它蜕变成为接入互联网的终端设备。Web 2.0提供了云计算的接入模式, 也为云计算培养了用户习惯。 Web 2.0为云计算的出现提出了内在需求。随着Web 2.0的产生和流行,互联网用户更 加习惯将自己的数据在网络上存储和共享。每天,视频网站和图片共享网站都要接受海量 的上载数据。同时,为了给用户提供新颖而有吸引力的服务,Web应用的开发周期越来越 短,只有更加快捷的业务响应才能让应用提供商在激烈的竞争中生存。因此,他们需要有 这样一个平台,能够提供充足的资源保证其业务增长,能够提供可以复用的功能和非功能 模块来保证其快速开发。这些,都是云计算产生的内在需求。 第1章 云计算概论 033 1.4 云计算带来的变革 前面我们从IT产业和各个实体的角度分析了云计算的本质优势,总结了云计算产生的 原动力。变革的到来已势不可当。如果我们将视野放宽,把当下所处的时代定位于技术与 经济发展的历史长河中,就能够更加清晰地理解云计算所带来的变革与机遇。Carlota Perez 在其著作《技术革命与金融资本》(Technology Revolutions and Financial Captial)中梳理了 从18世纪工业革命起到当今信息时代近250年的人类社会发展史,回顾了五次由于基础性 的技术革命而主导的社会更迭,归纳了在这些更迭中由技术引致的从萌芽到高速发展、躁 动到泡沫破裂、重建到最终成熟的循环规律。当前,我们正处于由IT技术主导的信息与通 信时代,经历了.com泡沫的破裂,目睹了金融危机的爆发,社会的技术与经济正经历着秩 序的重建。在这个过程中,虽然不再有虚幻的传奇和狂躁,但技术的沉淀和演进将越走越 实,其中蕴藏的机遇和财富将越来越广。 1.4.1 大势所趋的转型 变革的背后往往蕴藏着规律,云计算的到来也不例外。它并不是随机的、意外的,而 是当科学技术和社会经济发展到一定程度时必然发生的。在这里,我们将计算技术的发展 与社会经济的发展做一个类比(如图1.8所示),便不难探究出其中的规律。 图1.8 社会经济与计算技术发展的规律 在农耕时代,家家户户过着“采菊东篱下,悠然见南山”般的生活,自己制作工具, 自己耕种收获,看起来惬意,但只是低效地满足了有限的基本生活需求。随着铁制工具的 云计算宝典——技术与实战034 使用和生产技术的进步,农业劳动生产率获得提高,也使农具的生产变得多样而复杂,不 能再由一家一户独立进行了。在这个背景下出现了人类历史上的“第二次社会大分工”, 由工匠进行专业农具生产,由农民专门从事农业活动。随着社会生产率的进一步提高,工 具的生产逐渐标准化和规模化,手工作坊的规模越来越大,农业生产的能力也越来越大, 简单的交换已无法容纳社会经济发展的需求。在这个背景下,商人出现了,完成了“第三 次社会大分工”。随着分工的不断精细化,每个人和社会整体的效率与效益都获得了提 高,人类社会逐渐从荒蛮走向文明。 反观近百年来计算技术的发展,我们不难从中发现与社会经济相似的规律。在早期的 大型机时代,公司或机构自己购买、营运并使用计算设备。随着半导体、网络和软件技术 的综合发展,计算技术进入个人电脑时代。互联网上出现了多种多样的服务提供商,崭新 的业务模式层出不穷。在这个过程中,提供商通过制定标准来巩固自己的专业地位与业务 规模。这样的专业化与规模化不断深入,伴随着技术的成熟,IT服务将逐渐变得如水和电 一样,可以通过无处不在的互联网随处获得。这就是云计算,顺应着历史发展的脉络在我 们这个时代诞生。当下,仅是一个开始,随着IT生态系统的进一步精细分工,云计算将孕 育出新兴的产业链。新的参与者将加入,旧的参与者必须相机而变。 1.4.2 新兴的产业链 云计算作为一种新兴的IT运用模式,带来了IT产业调整和升级,同时也催生了一条全 新的产业链。这条产业链中主要包含硬件供应商、基础软件提供商、云提供商、云服务提 供商、应用提供商、企业机构用户和个人用户等不同角色。 云计算产业结构中的角色如图1.9所示。在云计算的产业结构中,位于中心的是云提供 商。云提供商为云服务提供商搭建公有云环境,为企业和机构用户搭建私有云环境。云提 供商从硬件提供商和基础软件提供商那里采购硬件和软件,向上提供构建云计算环境所需 的解决方案。应用提供商从云服务提供商那里获得所需的资源来开发和运营自己的应用, 为个人用户和企业机构用户提供服务。除了从云提供商那里获得私有云,从应用提供商那 里获得随时可用的软件外,企业机构用户还可以直接从云服务提供商那里获得计算和存储 资源来运行企业机构内部的自有应用。可见,位于产业链中游的云提供商、云服务提供商 和应用提供商从事着与云计算直接相关的业务活动,我们将他们统称为云计算提供商。 第1章 云计算概论 035        图1.9 云计算产业结构中的角色 云计算将为IT产业带来深刻的变革,也为创业者带来新的机遇。本节将自底向上从这 条产业链中的各个角色出发,简要介绍云计算带来的变革。 1.4.2.1 硬件提供商 云计算对当前硬件提供商的业务具有很大的影响。作为硬件的行业客户,一些企业和 机构考虑按照云提供商给出的解决方案,增购服务器或者进行技术升级,来构建完全可以 由自己控制的私有云环境;也有一些公司将继续以传统的方式使用服务器并且不改变服务 器的购买计划。但是,云计算会使得更多的公司,尤其是中小型企业都开始重新考虑甚至 放弃原有的服务器购买计划,转而通过使用公有云来提高业务的灵活性,降低运营成本。 然而,这并不意味着云计算会打压硬件提供商的业务。相反,为了满足用户对公有云 的需求,云服务提供商将建设更多的公有云环境。这将创造市场对硬件产品的新需求,并 促进硬件产品在技术上的创新。那些更加节能、灵活并且能够支持云计算技术要求,尤其 是支持虚拟化功能的硬件产品,将在未来的市场中占据更大的份额。 1.4.2.2 基础软件提供商 基础软件包括传统意义上的操作系统和中间件。云计算对于基础软件提供商的影响 是巨大的。云计算所带来的变革将影响从操作系统到上层应用整个软件体系结构的每个角 落。在云计算中,互联网就像是一个巨大的操作系统,它运行着云中所有的软件并向用户 提供服务。由于越来越多的应用都从桌面操作系统搬到了互联网上,这使得传统操作系 统提供商承受着巨大的挑战和压力,一方面必须在新版本的操作系统中引入对云计算核心 技术的支持,如虚拟化技术,从而在未来云基础设施领域中占据更多的市场份额;另一方 云计算宝典——技术与实战036 面,如果已有客户要采纳这些新技术,就意味着比较复杂的升级周期,这在从操作系统桌 面应用升级到云应用的过程中体现得最为明显。 与操作系统相同,中间件为上层服务提供了通用的功能模块,并且隐蔽了实现细 节,使得上层软件的开发可以着重于业务逻辑,而非烦琐的底层细节。在云计算环境 中,中间件对上层依然需要提供相同的便捷功能,但是对下层它需要隐藏的细节就更 加复杂了。首先,中间件运行在云之上,而不是在传统意义上的单个服务器上,这样 它不但需要适应单个云服务提供商的运行环境,而且要具有跨多个云服务提供商的互 操作性。其次,在云上运行的中间件必须支持云计算的核心特征——可扩展性,可以 随时随地为任何用户调整资源以满足业务上的需求。可见,作为提供操作系统和中间件 的基础软件提供商,新技术的研发和新产品的推出速度将决定其能否在云计算中占据领 先地位。 1.4.2.3 云提供商 云提供商处于云计算产业的核心位置,它向下采购(或者通过咨询服务的方式建议 云服务提供商和企业机构用户采购)硬件提供商及基础软件提供商的硬件与软件产品,向 上为云服务提供商提供构建公有云的解决方案,为企业机构用户提供构建私有云的解决方 案。可见,云提供商在云计算产业中处于“造云者”的角色。可以说,在云计算产业中, 其他角色的业务流转都是围绕云提供商展开的。 云提供商需要具有三个显著特点。 1. 具有丰富的硬件系统集成经验 云计算无疑将带来现有数据中心的技术升级和扩容,以及新兴大型数据中心的建造。 为这些数据中心提供从处理、存储到网络的集成解决方案是一项复杂的系统工程,因此需 要云提供商在这方面具有深刻的认识和丰富的经验。 2. 具有丰富的软件系统集成经验 硬件是云计算的躯体,软件是云计算的灵魂。从操作系统到中间件,从数据库、Web 服务到管理套件,软件的选择、配置与集成方案种类众多、千变万化,如何帮助用户做出 最合适的选择,需要云提供商对软件集成具有深刻的理解。 第1章 云计算概论 037 3. 具有丰富的行业背景 这一点主要是针对企业机构的私有云建设。由于用户是身处各行各业的不同企业机 构,其业务也不尽相同,因此如何为用户设计出最适合自己的私有云解决方案,就需要云 提供商对该行业具有深刻的理解和丰富的行业经验。 总之,云提供商需要同时具有丰富的硬件、软件和行业经验才能保证其在云计算产业 中的核心位置。云计算产业中的其他角色围绕着云提供商运营流转。云提供商为产业链中 的其他角色提供服务,创造价值。 1.4.2.4 云服务提供商 云计算是互联网时代信息技术发展和信息服务需求共同作用下的产物。传统的软件提 供商所提供的产品并不能直接适用于云计算环境。规模较小的独立软件提供商一般没有强大 的技术实力去实现云计算技术的创新,而规模庞大的专业软件提供商在实现传统软件产品转 型时遇到的技术和业务压力也是空前的,这就给那些眼光卓越的精英们带来了创业机会。 这些新兴企业在面对变革时没有沉重的包袱,能够充分而直接地构建适合互联网时代 需求的云计算产品。他们与云提供商紧密合作,提供适合市场需求的云计算环境。无疑, 云计算打开了一片宽广的市场空间,无论是基础设施云、平台云还是应用云,都有着巨大 的潜在需求。因此,对于每一家云服务提供商,只要能够通过变革和创新来提供便捷的、 差异化的云计算服务,就能够在云计算产业中获得成功。 1.4.2.5 应用提供商 传统的应用提供商将其应用运行在自己的服务器或者在数据中心中租赁的服务器上, 这种传统的方式有着几个弊端。首先,应用提供商要负担更高的成本,因为需要购买或者 租赁物理机器,购买相应的各种软件。其次,应用提供商需要对所有的机器和软件进行维 护,保证整个系统从硬件到软件都正常地工作。更重要的是,由于成本控制,应用提供商 很难用更为低廉的方式获取更多的资源,这会使得服务质量在服务高峰期受到很大影响。 在云计算中,应用提供商所提供的服务运行在云中,并且是以服务的方式通过互联网 提供的。云计算能够有效地使应用提供商避免上述弊端,从而为中小企业和刚刚起步的企 业降低成本。 云计算宝典——技术与实战038 (1)应用提供商不需要购买专门的服务器硬件及各种软件,只需要将应用部署在云 平台中即可,所需的硬件资源和软件服务都由云提供。 (2)由于云平台由专人维护,应用提供商也省去了维护费用。 (3)云计算中所有的资源都按照具体使用情况付费,从而避免了传统方式中资源空 闲所造成的浪费。 (4)云平台上的软件都以服务的形式运行,应用提供商在开发新业务的时候能够以 较低的成本充分利用云平台所提供的各种服务,从而加速业务上的创新。 1.4.2.6 个人用户 云计算时代将产生越来越多的基于互联网的服务,这些服务丰富全面、功能强大、使 用方便、付费灵活、安全可靠,个人用户将从主要使用软件变为主要使用服务。在云计算 中,服务运行在云端,用户不再需要购买昂贵的高性能的电脑来运行种类繁多的软件,也 不需要对这些软件进行安装、维护和升级,这样可以有效减少用户端系统的成本与安全漏 洞。更重要的是,与传统软件的使用方式相比,云计算能够更好地服务于用户。在传统方 式中,一个人所能使用的软件仅为其个人电脑上的所有软件。而在云计算中,用户可以通 过互联网随时访问不同种类和功能的服务。 云计算将数据放在云端的方式给很多人带来了顾虑,通常人们认为数据只有保存在自 己看得见、摸得着的电脑里才最安全,其实不然,因为个人电脑可能会不小心被损坏、遭 受病毒攻击,导致硬盘上的数据无法恢复,数据也有可能被木马程序或者有机会接触到电 脑的不法之徒窃取或删除,笔记本电脑还存在丢失的风险。而在云环境里,有专业的团队来 帮用户管理信息,有先进的数据中心帮助用户备份数据。同时,严格的权限管理策略可以帮 助用户放心地与指定的人共享数据。这就如同把钱存到银行里比放在家里更安全一样。 1.4.2.7 企业机构用户 对于一个企业用户来讲,云计算意味着很多。正如上文所述,企业不必再拥有自己的 数据中心,大大降低了运营IT部门所需的各种成本。由于云所拥有的众多设备资源往往不 是某一个企业所能拥有的,并且这些设备资源由更加专业的团队进行维护,因此企业的各 种软件系统可以获得更高的性能和可靠性。另外,企业不需要为每个新业务重新开发新的 系统,云中提供了大量的基础服务和丰富的上层应用,企业能够很好地基于这些已有的服 第1章 云计算概论 039 务和应用,在更短的时间内推出新业务。 当然,也有很多争论说云计算并不适合所有的企业和机构,比如对安全性、可靠性都 要求极高的银行、金融企业,还有涉及国家机密的军事单位等,另外如何将现有的系统迁 入到云中也是一个难题。尽管如此,很多普通制造业、零售业等类型的企业都是潜在的能 够受益于云计算的企业。而且,那些对安全性和可靠性要求很高的企业和机构,也可以选 择在云提供商的帮助下建立自己的私有云。随着云计算的发展,必将有更多的企业用户从 不同方面受益于云计算。 1.5 小结 本章从四个典型案例出发,介绍了云计算的概念与分类,分析了云计算的特征,并将 云计算与其他相关概念进行了辨析。随后,我们从产业到技术,首先在IT产业的层面,从 合理配置资源和专业分工的角度分析了云计算的本质优势,再逐渐深入到云计算的实体层 面,从技术革新及提高效益的角度分析了云计算的本质优势。然后,为读者解析了云计算 产生的原动力。最后,从云计算催生的产业链的角度出发,分析了云计算为这条产业链上 每一类参与者带来的深刻变革,以及为创业者带来的新的机遇。 本章作为本书的引子,概述了云计算。在接下来的第2章将介绍几个典型行业中运用 云计算的不同实践;在第3章,将按步骤介绍云计算的实施;在第4章,将深入技术层面, 分析云计算的架构;在第5章,将介绍云环境构建的关键技术;在第6章,将介绍云计算的 最新业界动态。 新一代绿色数据中心 4.1 数据中心概述 4.2 数据中心的设计和构建 4.3 数据中心的管理和维护 4.4 新一代数据中心的需求 4.5 绿色数据中心 4.6 小结 第 4 章 第4章 新一代绿色数据中心 第5章 虚拟化概论 第6章 虚拟化管理 114 云计算宝典——技术与实战 对于大多数人来说,“数据中心”是个略带神秘色彩的地方,没有窗户的高墙,恒 定的温度和湿度,排列整齐的机架,跳跃闪烁的指示灯,海量的数据在这里穿梭,关键的 业务在这里运行,这一切都充满科幻的色彩。但实际上,数据中心离我们每个普通人并没 有那么遥远,甚至可以说是紧密相连的。当你在银行办理业务时,整个交易的流程都在银 行的数据中心中完成。当你在互联网上冲浪搜索信息时,请求都被搜索引擎的数据中心接 收、处理和返回。如果说信息是血液,网络是血管,那么数据中心就是最关键的心脏,是 信息世界的核心所在。 本章将揭开数据中心的神秘面纱,向读者介绍数据中心的基本概念、核心功能、管理 和维护工作,以及新一代数据中心的需求和挑战。 4.1 数据中心概述 4.1.1 数据中心的概念 数据中心是信息系统的中心,通过网络向企业或公众提供信息服务。具体来说,数据 中心是在一幢建筑物内,以特定的业务应用中的各类数据为核心,依托IT技术,按照统一 的标准,建立数据处理、存储、传输、综合分析的一体化数据信息管理体系。信息系统为 企业带来了业务流程的标准化和运营效率的提升,数据中心则为信息系统提供稳定、可靠 的基础设施和运行环境,并保证可以方便地维护和管理信息系统。 图4.1展示了数据中心的逻辑示意图。一个完整的数据中心在其建筑之中,由支撑系 统、计算设备和业务信息系统这三个逻辑部分组成。支撑系统主要包括建筑、电力设备、 环境调节设备、照明设备和监控设备,这些系统是保证上层计算机设备正常、安全运转的 必要条件。计算设备主要包括服务器、存储设备、网络设备、通信设备等,这些设施支撑 着上层的业务信息系统。业务信息系统是为企业或公众提供特定信息服务的软件系统,信 息服务的质量依赖于底层支撑系统和计算机设备的服务能力。只有整体统筹兼顾,才能保 证数据中心的良好运行,为用户提供高质量、可信赖的服务。 第4章 新一代绿色数据中心 115 图4.1  数据中心逻辑示意图 可见,数据中心的概念既包括物理的范畴,也包括数据和应用的范畴。数据中心容纳 了支撑业务系统运行的基础设施,为其中的所有业务系统提供运营环境,并具有一套完整 的运行、维护体系以保证业务系统高效、稳定、不间断地运行。 4.1.2 数据中心的发展过程 早期的数据中心可以追溯到20世纪50年代,数据中心是存放大型主机的机房。当时的 大型主机主要用于科学研究机构或国防军事领域,这些大型主机的主要器件以晶体管和电 子管为主,占地面积大,价格也十分昂贵。为了充分利用大型主机的资源,多个用户通过 终端和网络连接到主机上来共享计算资源。 20世纪70年代以后,随着大规模集成电路的快速发展,计算机价格迅速下降, 性能也飞速提升。发展到20世纪80年代,计算机向微型机的方向不断演进,只要购 买一台廉价的个人计算机,即可完成很多计算任务。在这一阶段,计算机的发展由 集中走向分布,小型机房得到了快速的发展。 进入到20世纪90年代,客户端/服务器的计算模式得到了广泛应用,用户安装客户端 软件后,通过互联网或局域网与服务器相互配合完成计算任务。在这种计算模式中,数据 中心存放服务器(个人计算机所占的比重超过了大型机)并提供服务。互联网将全球的计 算机整合在一起,使得数据中心的发展又从分布逐渐走向了集中。互联网的蓬勃发展掀起 116 云计算宝典——技术与实战 了建设数据中心的高潮,不但政府机构和金融电信等大型企业扩建自己的数据中心,中小 企业也纷纷构建数据中心,提供协同办公、客户关系管理等信息服务系统以支持业务的发 展。 最近几年,网上银行、网上证券和娱乐资讯等网络服务逐渐普及,网络用户数量 的不断攀升也促进了各种规模数据中心的涌现,数据中心的发展进入了鼎盛时期,数 据中心的建设规模和服务器数量每年都在以惊人的速度增长。 如今,飞速发展的信息服务和对IT系统的要求给数据中心带来了新的挑战。以往的企 业数据中心往往只简单地追求计算力与性能,而当前的经济环境让企业更加注重数据中心 的成本,绿色、节能、低碳的概念也逐渐深入人心。新一代的绿色数据中心通过自动化的 管理方式、虚拟化的资源整合方式,结合新的能源管理技术,来解决数据中心日益突出的 管理复杂、能耗严重、成本增加及信息安全等方面的挑战,实现高效、节能、环保、易于 管理的数据中心。 4.1.3 数据中心的分类与分级 依据业务应用系统在规模类型,服务的对象,服务质量的要求等各方面的不同,数据 中心的规模、配置也有很大的不同。 数据中心按照服务的对象来分,可以分为企业数据中心和互联网数据中心。企业数 据中心指由企业或机构构建并所有,服务于企业或机构自身业务的数据中心,它为企业、 客户及合作伙伴提供数据处理、数据访问等信息服务。企业数据中心的服务器可以自己购 买,也可以从电信级机房中租用,运营维护的方式也很自由,既可以由企业内部的IT部门 负责运营维护,也可外包给专业的IT公司运营维护。互联网数据中心由服务提供商所有, 通过互联网向客户提供有偿信息服务。相对于企业数据中心来讲,互联网数据中心的服务 对象更广,规模更大,设备与管理更为专业。 长期以来,业界采用等级划分的方式来规划和评估数据中心的可用性和整体性能。采 用这种方法可以明确设计者的设计意图,帮助决策者理解投资效果。美国Uptime Institute提 出的等级分类系统已经被广泛采用,成为设计人员在规划数据中心时的重要参考依据。在 该系统中,数据中心按照其可用性的不同,被分为四个等级(Tier)。 第4章 新一代绿色数据中心 117 第一等级(TierⅠ)被称为“ 基础级”(Basic Site Infrastructure),该级别的数据 中心没有冗余设备(包括计算和存储),所有设备由一套线路系统(包括电力和 网络)相连通。 第二等级(Tier Ⅱ)被称为“具冗余设备级”(Redundant Capacity Components Site Infrastructure),该级别数据中心具有冗余设备,但是所有设备仍由一套线路系统 相连通。 第三等级(Tier Ⅲ)被称为“可并行维护级”(Concurrently Maintainable Site Infrastructure),该级别数据中心具有冗余设备,所有计算机设备都具备双电源并 按照数据中心的建筑结构合理安装。此外,Tier III要求数据中心拥有多套线路系 统,任何时刻只有一套线路被使用。 第四等级(Tier Ⅳ)被称为“容错级”(Fault Tolerant Site Infrastructure),该级别 数据中心具有多重的、独立的、物理上相互分隔的冗余设备,所有计算机设备都 具备双电源并按照数据中心的建筑结构合理安装。此外,Tier IV要求数据中心拥 有动态分布的多套线路系统来同时连通计算机设备。 可见,随着等级的提高,数据中心具有了更强的可用性和整体性能。目前,已落成的 数据中心在进行升级改造时都在力争达到Tier IV的要求。而面向云计算的下一代数据中心 在设计时更是以Tier IV作为建设的标准。 4.2 数据中心的设计和构建 数据中心的设计和构建是一项系统工程,相关人员需要相互协作来完成总体设计、建筑 和基础设施的构建,以及软硬件的采购和上线。本节将为读者介绍这些工作和相关的流程。 4.2.1 总体设计 数据中心的设计是一个系统、复杂、迭代的过程。数据中心设计者要在特定预算的情 118 云计算宝典——技术与实战 况下,让数据中心能够满足公司现有及将来不断增长的业务需求。数据中心的设计过程需 要各类参与者不断地协商,平衡多方面的因素,比如在预算的限制和数据中心的性能间进 行平衡。通常情况下,设计阶段决定了落成后数据中心的质量。合理的评估规划、全面周 详的设计是构建数据中心关键的第一步。 从20世纪60年代初开始,世界各地的工程人员在构建数据中心的过程中不断总结,形 成了系统的数据中心建设标准,如我国的国家标准《电子信息系统机房设计规范》(GB 50174-2008)和美国的《数据中心电信基础设施标准》(TIA-942)。这些标准为数据中 心的设计,尤其是建筑、机电、通风等基础设施的规划提供了基本的依据。除了有标准可 以依据,设计人员还可以参考以往工程中积累下来的实践经验,以现实需求为基础,合理 运用新技术,提高数据中心的管理效率和整体性能。 建设数据中心的目标是为了满足企业信息化建设中的各项信息服务的需求,为它们提 供高性能、高可用、高可扩展的安全的基础设施及软件平台。建设数据中心包括建设机房 环境,为数据中心提供可靠、易用的电力、环境控制、消防等辅助配套设施,提供高效的 网络环境,构建高效、稳定的服务器系统,存储系统,并建立安全体系和灾备系统。 构建数据中心需要遵守一些核心设计理念,遵守这些理念可以使得数据中心的设计清 晰、高效、有条理。简单的理念要求设计容易被理解和验证;灵活的理念保证数据中心能 不断适应新的需求;可扩展的理念使数据中心系统机构和设备易于扩展,能够随着业务的 增长而扩大;模块化的理念是将复杂的工程分解为若干个小规模任务,使设计工作可控 而易管理;标准化的理念要求采用先进成熟的技术和设计规范,保证能够适应信息技术 的发展趋势;经济性的理念要求选用性价比高的设备,系统可以方便地升级,充分利用 原有投资。 4.2.2 建筑的设计与构建 构建一个数据中心有多种方式,究竟采用什么方式取决于企业的发展战略和预算。租 用机房对于资金较少的公司是一个不错的选择,这样可以节省建设机房及管理维护数据中 心的成本。对于需要拥有独立数据中心的企业,可以选择利用现有的建筑构建数据中心或 者设计修建一个新的建筑作为数据中心。数据中心的建筑在安全、高度和承重方面都有严 格的标准,无论是利用现有的建筑还是修建新的建筑都需要考虑数据中心构建标准。 第4章 新一代绿色数据中心 119 构建数据中心,面临的第一个问题就是选址。选址要综合考虑多种因素,包括公司发 展战略、预算、运营成本和安全等诸多因素,其中通信、电力和地理位置是选址的三个主 要考虑因素。光纤通信技术的发展解决了信息的长距离、高带宽快速传递的问题,因此, 数据中心的选址不存在服务半径的问题,只要能够方便地接入主干通信网,即可向全球提 供服务。电力供应是构建数据中心需要考虑的另一个因素,数据中心所在位置必须能够提 供充足、稳定的电力供应,并且电力成本足够低,因为电力是数据中心长期运营成本中的 一大笔开销。为了提供可靠、稳定的服务,数据中心对可靠性和可用性都有严格的要求, 所以选择地理位置的时候,安全是必须考虑的因素,应该尽量远离核电站、化工厂、飞机 场、通信基站、军事目标和自然灾害频发的地带。 其次,构建数据中心需要考虑建筑要求,包括建筑的规模、布局、高度、地板的承重 能力和室内布局等。数据中心可以小到一个房间,大到一层楼甚至是整幢楼房。数据中心 的规模取决于企业的需求和预算,这直接关系到能承载多少服务器,以及将来可以扩展到 多大的规模。从土建角度来讲,数据中心楼板的承重要求高于普通建筑,因为数据中心的 服务器一般比较密集,大型机柜、网络设备的重量大于普通的家具和办公设备。因此在设 计建筑的承重能力时需要综合考虑数据中心的容量,包括服务器的数量、制冷设备等相关 辅助设备的数量。 数据中心对楼层的高度也有要求,设计时需要计算铺设地板和安装吊顶以后的净高。 因为一般数据中心都采用下进线方式,地板下要覆设走线槽和通风通道,所以地板净 高至少需要30~50厘米;而房顶吊顶中要留足灯具和消防设备暗埋高度,这样房间的 净高至少累计减少70~80厘米,普通楼房的高度在机房装修后会显得较低,也不利于 设备的安装。所以数据中心的房间净高度最好在3.3米以上。布局的设计要考虑到各 个房间的大小、分布、面积和功能等,比如要考虑如何设置配线间、服务器存放区域 和管理员房间等。良好的布局能够提高制冷效率,降低制冷成本。此外,数据中心对 室内环境要求较高,许多设备对温度、湿度和灰尘都有特定的要求,通常要避免室内 设有窗户,要在屋顶布置照明、防火、安全监控等设施。 数据中心设计完成后,就进入了施工阶段,也就是根据设计实现数据中心的阶段。与 建造其他建筑类似,施工阶段有许多烦琐的工作需要处理。为了保证工程质量,需要有专 门的监管部门控制施工进度,并根据设定的标准进行阶段性验收,项目完成后还需要进行 全面验收才能交付。 120 云计算宝典——技术与实战 4.2.3 基础设施的设计与构建 为了确保设备的正常运行,网络、电力和环境控制设施等基础设施是必不可少 的。如图4.2 所示,电力是数据中心运行的动力,网络保证了服务器及存储的互联和 访问,环境控制设施为设备运行提供了合适的温度、湿度等环境条件。基础设施的设 计同IT 设备的规模是紧密相关的。比如服务器的数量直接影响所需要的电量;服务 器数量越多,释放出来的热量会随之增长,制冷设备也需要相应增加。为了使IT 设 备相互连接,网络设施的设计建造同样是至关重要的。下面详细介绍上面三种基础设 施的设计和构建。 图4.2 数据中心基础设施示意图 电力系统的设计是数据中心基础设施设计中最为关键的部分,关系到数据中心能否持 续、稳定地运行。电力系统的设计需要考虑数据中心的电力负荷限制、电力公司和冗余配 备、电力设施的布局。数据中心内的电力负载主要有照明用电、消防应急系统用电、计算 机设备用电和制冷设备用电。由于业务的重要性,以上各项电力负载均需要冗余来保证其 可用性。在电力负荷确定后,数据中心的规划等级决定了电力冗余设备的配置。 举例来说,Tier IV数据中心的电力系统可靠性需要达到99.99%,意味着平均每5年才 会发生一次电力事故,平均每年电力事故引起的宕机时间为0.8小时。应对这样的可用性要 求,数据中心需要采用市电双路供电,设置双总线UPS(Uninterruptible Power Supply,不 间断电源)冗余,延时15分钟,同时配备柴油发电机作为第二重备份,在市电仍未恢复且 第4章 新一代绿色数据中心 121 UPS耗尽前及时接入。在数据中心的设计中,电力线路和插座的布局也是很重要的。数据 中心内部IT系统和环境控制设备等基础设施(比如服务器、交换机及空调等)的分布直接 影响电力线路的布局。设计线路布局还需要考虑将来扩展的需求及支持设备的类型,不同 国家的设备对电压、电流的要求也是有差异的。此外,数据中心的电力系统还需要进行机 房接地系统和防雷接地系统的设计,保证数据中心的电力安全。 环境控制设施保证了数据中心的设备有一个适宜的运行环境,包括温度、湿度及灰尘的 控制。设计环境控制设施需要考虑IT设施的规模、服务器的类型和数量等。温度控制作为环境 控制中最为重要的问题已经被广泛研究,现在数据中心常采用的制冷方式有:风冷、水冷和机 架内利用空气—水热交换制冷等。依据Tier IV标准,数据中心要求具有双路冷源和双冗余管 路系统。如图4.3所示,为了布线方便,一般都将机房地板架空,利用这个空间铺设网络线 路、电力线路,以及将冷气分发到数据中心的每个角落。精密空调通过循环吸收热空气,制 造冷气。在机架的前方,通过镂空的地板,将冷气送入机架,冷气流经机架带走服务器的热 量,转换成热空气从机架后面重新流入制冷装置的进风口。 风冷的设计有两个关键点:一是热通道和冷通道的设计,要避免热空气流入服务器机 架中;二是单位时间送给每个机架的冷气必须能够满足整个机架的需求,否则机架下层的 服务器排出的热空气就可能向上流动,使机架上层的服务器不能获得良好的制冷效果。风 冷的一个主要问题是制冷能力有限,所以机架内服务器的密度不能太大。机架内空气—水 交换制冷能有效提高机架内机器密度。随着绿色数据中心概念的推广,节能已经是数据中 心设计的一个重要目标,水冷在节能和制冷效果方面都具有明显的优势,正被越来越多的 数据中心采用。 图4.3  数据中心风冷示意图 如果数据是血液,网络就是血管。网络系统是信息的高速公路,在数据中心内及数据 122 云计算宝典——技术与实战 中心之间起着至关重要的作用。网络基础设施的设计与电力系统的设计类似,需要与企业 的业务需求紧密结合,主要包括网络供应商的选择和内部网络拓扑的设计。现在多数业务 都支持通过互联网进行访问,所以业务的可用性和服务质量在一定程度上取决于网络供应 商的服务质量。如果业务对网络服务质量的要求比较高(比如银行ATM服务),则需要考 虑多家网络供应商接入。一般数据中心的网络包含至少三级结构:网络供应商的网络接入 连接到数据中心的核心交换机;二级交换机向上连接到核心交换机,向下同数据中心的机 架互连;机架内部的服务器则通过机架内置的网络交换模块同二级交换机连接。每级交换 机的性能和出口、入口的带宽选择都与数据中心内部的负载分布密切相关。 数据中心的网络设备主要有交换机和路由器。交换机是一种基于MAC地址识别的封 装转发数据包功能的网络设备。与集线器共享带宽的广播方式不同,交换机可以识别数据 帧的发送者和目标接收者,使数据帧直接从源地址到达目的地址。通过交换机的过滤和转 发,可以有效地解决广播风暴问题,减少误包和错包的出现,避免共享冲突。 从传输速度上来分,局域网交换机可以分为以太网交换机、快速以太网交换机、千兆 以太网交换机等。插槽与扩展槽数、支持网络类型、背板吞吐量、最大可堆叠数等是选取 以太网交换机的主要参数。路由器用于连接多个逻辑上分开的网络,当收到数据时,通过 路由规则判断网络地址并选择路径,完成数据在多个子网间的传输。路由器的主要工作目 标是尽可能选择通常快捷的网络路径,提高通信速度,减轻网络系统通信负荷,节约网络 资源,提高网络畅通率,从而让网络发挥出更大的效益。选购路由器时,应重点考虑路由 器所支持的路由协议类型、吞吐量、转发延时、路由表的容量,以及路由器的稳定性等因 素。 4.2.4 数据中心上线 数据中心上线包括以下几个步骤:选择服务器、选择软件、机器上架及软件部署和测 试。下面将分别介绍这些步骤。 选择服务器需要综合考虑多方面因素,比如数据中心支持的服务器数量及数据中心将 来要达到的规模和服务器的性能等。由于服务器是主要的耗电设备,所以节能也是一个重 要的考虑因素。数据中心的服务器按照类型可以分为塔式服务器、机架式服务器和刀片服 务器这三大类。下面将分别介绍这三种最常见的服务器。 第4章 新一代绿色数据中心 123 塔式服务器的外观与个人计算机的主机差不多,如图4.4所示。与普通PC相比,塔式 服务器的主板可扩展性较强,接口和插槽比普通PC多一些,机箱的尺寸比普通PC稍大。塔 式服务器成本较低,能够灵活地定制,可以满足入门级服务器的需求,所以应用范围非常 广泛。不过塔式服务器也有其局限性:由于扩展性有限,塔式服务器很难满足规模较大的 并行处理应用的要求;另外,由于占用空间较大,不便于挪动和管理。   图4.4  塔式服务器 机架式服务器是一种外观按照统一标准设计的、配合机柜使用的服务器,如图4.5所 示。由于采用统一的机架式结构,服务器可以方便地与其他网络设备连接,简化了机房的 布线和管理。机架式服务器的尺寸有统一的标准:服务器的宽度为19英寸,高度以U为单 位(U是表示服务器外部高度的单位,是Unit的简称,1U=1.75英寸,由美国电子工业协 会确定)。通常标准的服务器高度在1U至7U之间,机柜的高度从22U至42U不等。 图4.5描绘了从1U到4U四种不同尺寸的机架式服务器。与塔式服务器相比,机架式服 务器的优点是占用空间较小,单位空间可放置更多的服务器,且管理方便。机架式服务器 的不足是对制冷要求较高。机架式服务器广泛适用于服务器第三方托管(如电信托管)的 企业,因为这种托管的费用常常是按照机器的空间收取的。另外,由于占用空间小,机架 式服务器适用于服务器数量较大或者空间有限的数据中心。 图4.5  机架式服务器 124 云计算宝典——技术与实战 刀片服务器是在标准高度的机箱上插装多个卡式的服务器单元,由于这些服务器单元 的外观很薄,故得名刀片服务器,如图4.6所示。实际上,每一块“刀片”都是一个独立的 服务器,包括系统主板、硬盘、内存等设备,可以通过板载硬盘启动操作系统。若干刀片 服务器连接起来,就形成了一个集群服务器,由所在的机箱提供高速的网络环境,同时共 享机箱中的其他资源,协同完成计算任务。 刀片服务器支持热插拔,这大大降低了系统维护的成本。刀片服务器比机架式服务 器更加节省空间,光驱、显示器和制冷装置都是共享的,在一定程度上降低了成本。 刀片服务器一般应用于大型数据中心或者计算密集的领域,如电信、金融行业和互联 网数据中心等。对于企业和互联网服务提供商来说,随着业务的发展和对服务器需求 的增长,刀片服务器在节约空间、便于管理、可扩展性方面拥有显著的优势,将成为 未来服务器的主流产品。 图4.6  刀片服务器 数据中心的软件主要包括操作系统、数据中心管理监控软件和与业务相关的软件(中 间件、邮件管理系统、客户关系管理系统等软件)。 目前数据中心服务器操作系统主要有三大类:UNIX系统、Windows系统和Linux系统。 数据中心要根据具体的业务需求选择适合的操作系统。 UNIX是一种技术成熟、可靠性高、安全性高的多任务分时操作系统。UNIX可满足政 府机构和各行业大型企业的需求,适合运行企业的重要业务,是主流的企业IT操作平台。 UNIX系统最早的雏形在1969年诞生于AT&T贝尔实验室,当时UNIX的所有者AT&T公司发 布了UNIX的源码,许多机构在这个UNIX雏形的基础上进行了改进,产生了若干个UNIX的 变种版本,如AIX、Solaris等。UNIX系统常常与硬件配套,比如采购了IBM的小型机就应选 用AIX系统,从而达到最佳的系统性能。 Linux是一套可以免费使用和自由传播的、开源的类UNIX操作系统,由世界各地成千 第4章 新一代绿色数据中心 125 上万的程序员设计和实现。Linux系统在x86架构上实现了UNIX的主要特性,因而得到众多 爱好者的广泛采用。Linux的发行版众多,常见的发行版有Ubuntu、SUSE和Redhat等。 Windows是Microsoft公司开发的操作系统,用于服务器的操作系统有Windows Server 2003和Windows Server 2008等。 数据中心大多以Web的形式向外提供服务,Web服务一般采用三层架构,从前端到后 端依次为表现层、业务逻辑层和数据访问层。三层架构目前均有相关中间件的支持,如表现 层的HTTP服务器,业务逻辑层的Web应用服务器,数据访问层的数据库服务器。主要产品有 IBM公司的WebSphere(HTTP服务器,Web应用服务器)和DB2(数据库服务器),开源的产 品有Apache(HTTP服务器)、Tomcat(Web应用服务器)和MySQL(数据库服务器)等。 数据中心的管理和监控软件种类繁多,功能涵盖系统部署、软件升级、系统、网络、 中间件及应用的监控等。比如IBM的Tivoli系列产品和Cisco的网络管理产品等,用户可以根 据自己的需要进行选择。 机器上架和系统初始化阶段主要完成服务器和系统的安装和配置工作。首先将机架按 照数据中心设计的拓扑结构进行合理摆放,服务器组装完成后进行网络连接,最后安装和 配置操作系统、相应的中间件和应用软件。这几个阶段都需要专业人员的参与,否则系统 可能无法发挥最大的性能,甚至不能正常工作。举例来说,数据库软件安装完成后,需要根 据服务器的硬件配置及应用的需求进行性能调优,这样才能最大程度地发挥数据库系统的性 能。目前已经有了一些系统管理方案,支持自动地进行系统部署、安装和配置,这在一定程 度上减少了技术人员的工作复杂度,简化了系统初始化的流程,提高了系统部署的效率。 服务器和软件安装配置完成后,就要开始对整个系统进行联合测试,检验软件是 否正常运行、网络带宽是否足够,以及应用性能是否达到预期等。这个阶段需要参照 设计阶段的文档逐条验证,测试系统是否满足设计要求。 4.3 数据中心的管理和维护 数据中心的管理和维护包含很多工作,涉及多种角色,包括系统管理员、应用管理 126 云计算宝典——技术与实战 员、硬件管理员、机房管理员、数据管理员和网络管理员等,每个角色都不可或缺。在 中小规模的数据中心里,经常一人身兼若干角色。本节将介绍数据中心管理和维护的主 要工作。 4.3.1 硬件的管理和维护 硬件的管理和维护包括对硬件的升级、定期维护和更新等。业务规模的增长和系统负 载的增加要求对服务器进行升级以适应业务发展的需要。系统运行一段时间后要定 期对硬件进行检查和维护,保证硬件的稳定运行。当服务器发生硬件故障时,需要 及时检测和定位故障,更换发生故障的部件。 升级或者更换部件时,不但要考虑服务器内各种部件的兼容性,还要协调这些 部件的性能,消除性能瓶颈。服务器的CPU频率、内存大小、磁盘容量、I/O性能、 网络带宽和电源供给能力等要达到均衡和协调,才能避免浪费并且使系统整体性能 达到最优。在选取组件时,应尽量选取同一品牌和型号的组件,这样做一方面可以 提高不同服务器组件之间的可替换性和兼容性,另一方面可以减少由于组件型号不 同而对系统性能产生的影响。 灰尘是导致服务器故障的一个重要因素,服务器的散热风扇在运转时容易将尘土带入 机箱,尘土中夹带的水分和腐蚀性物质附着在电子元件上,会影响散热或产生短路,增加 系统的不稳定性。因此,定期清理除尘是必不可少的。 4.3.2 软件的管理和维护 数据中心的常见软件包括操作系统、中间件、业务软件和相关的一些辅助软件,其管 理和维护工作包括软件的安装、配置、升级和监控等。 操作系统的安装主要有两种方式:通过系统安装文件安装和克隆安装。安装文件 的优势是支持多种安装环境和机器类型,但是安装中大多需要人工干预,容易出错,而 且效率较低。对同一类服务器,则可以采用镜像克隆方式安装,避免手动安装引入的错 误,减少人为原因引起的配置差异,提高部署效率。系统升级需要遵守严格的流程,包 括新补丁的测试、验证及最后在整个数据中心进行规模分发和安装。补丁的分发有两种 第4章 新一代绿色数据中心 127 方式:一种是“推”方式,由中央服务器将软件包分发到目标机器上,然后通过远程命 令或者脚本安装;另一种是“拉”方式,在目标机器上安装一个代理,定期从服务器上 获取更新。 安全性是操作系统管理和维护的重要内容,常见的措施包括安装补丁、设置防火墙、 安装杀毒软件、设置账号密码保护和检测系统日志等。遵循稳定优先的原则,服务器一旦 运行在稳定的状态,应避免不必要的升级,以免引入诸如软件和系统不兼容等问题。中间 件和其他软件的管理和维护工作与操作系统类似,包括软件的安装、配置、维护和定期升 级等。虚拟化技术的发展简化了软件的安装和配置工作,这部分内容将在后面的章节中进 行详细介绍。 4.3.3 数据的管理和维护 数据是信息系统最重要的资产。事实上,构建信息系统的目标就是对数据的管理, 保证数据安全、有效和可用。采用有效的数据备份和恢复策略能保证企业数据的安全,即 使在灾难发生后,也能快速地恢复数据。数据中常常包含企业的商业机密,因此数据维护 是数据中心维护工作的重中之重。随着信息技术的快速发展,数据量正在呈指数级增长。 2003年全球人均数据量仅为0.8GB,2006年即上涨至24GB,并将在2010年突破300GB,如 此快速的增长趋势给数据维护带来了更大的挑战。 数据管理和维护主要包括数据备份与恢复、数据整合、数据存档和数据挖掘等,下面 将逐一介绍这些内容。 数据备份是指创建数据的副本,在系统失效或数据丢失时通过副本恢复原有数据。数 据备份的种类包括文件系统备份、应用系统备份、数据库备份和操作系统备份等。数据库 备份应用最为广泛,主流的数据库产品都提供数据备份和恢复功能,支持不同策略的数据 备份机制,并在需要时将系统数据恢复到备份时刻。目前数据库技术已经相当成熟,商业 数据库软件的功能也很强大,管理员可在数据库中设置定时备份,也可以通过某种事件 触发备份或者手动备份,使用起来很方便。例如,IBM DB2数据库支持完全备份和增量 备份两种策略,实际使用中两者可以结合使用。为了保证数据安全,备份数据应存储 在和原数据不同的物理介质上,以规避物理介质损坏所产生的风险。 数据整合通过将一种格式的数据转换成另一种格式,达到在多个系统之间共享 128 云计算宝典——技术与实战 数据和消除冗余的目的。一些企业由于历史原因拥有多个信息系统,各个系统承担不 同的功能,在某种程度上又和其他系统有交叉,数据整合可以满足这些系统间的数据 共享需求。数据归档是指将长期不用的数据提取出来保存到其他数据库的过程。数据 挖掘是从归档数据库中分析寻找有价值的信息的过程。在业务系统运行过程中,会时 刻产生新的业务数据,随着数据量的不断增大,数据库的规模越来越庞大,如果不能 有效地处理这些数据,数据库的访问效率就会变差,进而影响业务系统的性能。归档 的数据库也被称为数据仓库,可以为企业经营决策提供数据依据。保存在数据仓库中 的数据一般只能被添加和查找,不能被修改和删除。归档时可按需对数据进行一些处 理:首先清洗数据,去除错误或无效的数据;其次精简数据,将数据中可用于统计分 析的信息抽取出来,将无用的信息删除,从而减少存档数据量,数据精简往往需要进 行数据格式的转换。 4.3.4 资源管理 负载均衡是资源管理的重要内容,数据中心管理和维护时应做到负载均衡,以避免资 源浪费或形成系统瓶颈。系统负载不均衡主要体现在以下几个方面。 (1)同一服务器内不同类型的资源使用不均衡,例如内存已经严重不足,但CPU利 用率仅为10%。这种问题的出现多是由于在购买和升级服务器时没有很好地分析应用对资 源的需求。对于计算密集型应用,应为服务器配置高主频CPU;对于I/O密集型应用,应配 置高速大容量磁盘;对于网络密集型应用,应配置高速网络。 (2)同一应用不同服务器间的负载不均衡。Web应用往往采用表现层、应用层和数 据层的三层架构,三层协同工作处理用户请求。同样的请求对这三层的压力往往是不同 的,因此要根据业务请求的压力分配情况决定服务器的配置。如果应用层压力较大而其他 两层压力较小,则要为应用层提供较高的配置;如果仍然不能满足需求,可以搭建应用层 集群环境,使用多个服务器平衡负载。 (3)不同应用之间的资源分配不均衡。数据中心往往运行着多个应用,每个应用对 资源的需求是不同的,应按照应用的具体要求来分配系统资源。 (4)时间不均衡。用户对业务的使用存在高峰期和低谷期,这种不均衡具有一定的 规律,例如对于在线游戏来说,晚上的负载大于白天,白天的负载大于深夜,周末和节 第4章 新一代绿色数据中心 129 假日的负载大于工作日。此外,从长期来看,随着企业的发展,业务系统的负载往往呈 上升趋势。与前述其他情况相比,时间不均衡有其特殊性:时间不均衡不能通过静态配 置的方式解决,只能通过动态调整资源来解决,这给系统的管理和维护工作提出了更高的 要求。 总之,有效的资源管理方式能提高资源利用率,合理的资源分配能够有效地均衡负 载,减少资源浪费,避免系统瓶颈的出现,保障业务系统的正常运行。 4.3.5 安全管理 作为企业信息系统的心脏,数据中心的安全问题尤为重要。数据中心的安全包括物理 安全和系统安全。为了保证物理安全,数据中心需要配备完善的安保系统,该系统应实现 7×24小时实时监控和录像、人员出入控制、人员远距离定位和联网报警功能。管理人员 和授权用户可以随时随地接入系统获得相应的监控信息和回放资料。 系统安全主要是防止恶意用户攻击系统或窃取数据。系统攻击大致分为两类:一类以 扰乱服务器正常工作为目的,如拒绝服务攻击等;另一类以入侵或破坏服务器为目的,如 窃取服务器机密数据、修改服务器网页等,这一类攻击的影响更为严重。数据中心需要采 取安全措施,有效地避免这两类攻击,常见的安全措施有以下几种。 (1)给服务器的账号设定安全的密码。账号和密码是保护服务器的最重要的一道防 线,设定的密码要有足够的长度和强度,最好是数字、字母和符号的混合、大写和小写字 母的混合,避免使用名字、生日等容易被猜中的密码,并且定期更换。 (2)采用安全防御系统,包括防火墙、入侵检测系统等。防火墙可以防止黑客的非 法访问和流量攻击,将恶意的网络连接挡在防火墙之外。入侵检测系统可以监视服务器的 出入口,通过与常见的黑客攻击模式匹配,识别并过滤入侵性质的访问。此外,网络管理 员与安全防御系统配合可以进一步提高安全系数。管理员需要熟悉路由器、交换机和服 务器等各种设备的网络配置,包括IP地址、网关、子网掩码、端口、代理服务器等,了解 网络拓扑结构,在发现问题后迅速定位。网络管理员还要根据不同IP和端口的访问流量统 计,识别出非正常使用的情况并加以封禁。 (3)定时升级,及时给系统打补丁。不存在没有漏洞的系统,系统中的漏洞很多都 130 云计算宝典——技术与实战 隐藏在深处,不易被发现。一旦某个系统漏洞被黑客发现,就会对此类系统进行攻击或开 发针对此类系统的病毒。与此同时,系统的开发者也会尽快发布补丁。攻击与防御,是一 场速度的比拼。系统使用者要争取在第一时间安装系统补丁,不给黑客和病毒可乘之机。 (4)关闭不必要的系统服务。黑客可能通过有漏洞的服务攻击系统,即使无法通过 这些服务攻击,开启的服务也可以给黑客提供信息,因此应该关闭不必要的服务。 (5)保留服务器的日志。虽然保留日志无法直接防止黑客入侵,但管理员可以根据 日志分析出黑客利用了哪些系统漏洞、在系统中安装了哪些木马程序,以便快速定位和解 决问题。 4.4 新一代数据中心的需求 数据中心为信息服务提供运行平台,对新一代数据中心的需求从根本上源于对新一 代信息服务的需求。随着信息服务在数量和种类上的快速增长,企业纷纷把核心业务和数 据放到IT系统中运营。与此同时,用户数量也在不断攀升,用户对信息服务的依赖越来越 强,企业和个人都需要更安全可靠、易于管理、成本低廉的信息服务。对信息服务的更高 要求指明了新一代数据中心的发展方向,下面将从合理规划、流程化、可管理性、可伸缩 性、可靠性这几个方面分别讨论。 4.4.1 合理规划 数据中心的建设是一项系统工程,从规划到设计,从选址到建设,从计算机设备到制 冷系统,从网络安全到灾难防备,无一不需要合理规划。一个数据中心通常可以运行三十 年左右,要使得数据中心在这三十年的时间内始终保持经济的运行状态,有很多复杂的因 素需要考虑。比如需要考虑各种设备的更新换代,计算机设备通常以五年为更换周期,制 冷系统的寿命可达十年以上,更新时需要合理选择设备,使用过度超前的设备或迟迟不 更新都不能达到最经济的效果。再比如需要考虑设备冗余量,设备冗余可以提升系统的 可用性,保证个别设备出现故障时整个系统仍能正常运转。但是过多冗余会导致设备长 期闲置、资源浪费,因此规划时需要具体分析,保证增加的冗余设备可以切实提高系统 第4章 新一代绿色数据中心 131 的可用性。 然而,由于企业难以预测IT系统的需求变化,有一些问题不能在设计数据中心时做出 准确的规划。一方面,企业的整体运营越来越依赖于IT平台,而这些IT系统的负载并非长 期不变,往往随着业务的发展而快速增长。有些企业甚至难以预见一年以后业务发展会带 来怎样的系统负载变化。另一方面,IT系统的触角正逐渐伸展到企业业务和管理的各个角 落,新上线的系统层出不穷,很难预测旧的管理方式和系统何时会被新系统取代。此外, IT系统本身越来越复杂,不可预见性也变得越来越强。这些变化的发生难以预测,一旦发 生,数据中心的IT基础架构将无法支撑,急需扩容。同样,为难以预测的负载准备大量冗 余也是不可取的。 综上所述,搭建数据中心需要合理规划各个环节,以保证数据中心在较为经济的状态 下运营。同时,业务的动态性和不确定性会给数据中心的准确规划带来挑战。 4.4.2 流程化 通过合理规划和系统构建,落成后的数据中心需要为信息服务提供高效、可靠、稳定 的运行环境和平台。因为信息服务的质量和成本是客户最关注的问题,信息服务管理自然 成为数据中心的一项基本工作,其重要性不言而喻。信息服务管理的含义是以信息服务的 形式为客户创造价值的一套组织能力,这种能力以流程的形式贯穿信息服务的整个生命 周期。信息服务管理的核心是通过信息流程的标准化,帮助企业根据业务目标实现创新 的、可视的、自动的、可控的信息服务,提高企业的运行效率和服务质量,为用户创造 最大价值。 20世纪80年代,英国政府认为行政机构的信息服务质量有待提高,于是任命英国中 央计算机与电信局(Central Computer and Telecommunications Agency, CCTA)制定一套 指导行政机构使用信息资源的方法。CCTA将英国各行业在信息管理方面的最佳实践总 结归纳起来,制定了信息技术基础构架库(Information Technology Infrastructure Library, ITIL)。这套信息服务管理流程库在英国各行业中得到了广泛认可和应用,并逐步延伸 到全球。 ITIL从出现起至今经历了三个版本:最初版本ITIL V1总结了一系列关于信息资源使用 的实践,形成了一套标准化、可计量的信息资源使用指导规范;ITIL V2在ITIL V1的基础上 132 云计算宝典——技术与实战 进行了重新组织和完善扩充,形成了一套清晰的信息实践指导流程;ITIL V3是目前最新的 版本,是对ITIL V1和ITIL V2的重构和丰富,融入了新的时代元素,突出了服务的核心地 位。ITIL V3由三大部分组成:核心组件、补充组件和网络组件。核心组件涵盖了服务从创 建到下线每个阶段的任务、目标及流程,由它们构成了通用的最佳实践。补充组件对不同 行业领域的具体状况进行了深入探讨和剖析,并给出了专业的指导。网络组件是对前两个 组件的扩充,提供了一个供用户学习、交流和发布信息的在线平台。 ITIL V3以服务为核心,覆盖了服务管理的整个生命周期,包括服务战略、服务设计、 服务转换、服务运营和服务改进五个阶段,形成了富有生命活力的信息服务管理实践框 架。下面将分别介绍这五个阶段的主要任务和目标。 服务战略的任务是了解现状、认清目标和设定规划。首先需要的是获取公司的资产、 业务发展计划、职能部门和流程、市场和人员等信息,通过分析这些信息得到可以满足客 户需求、为客户创造价值的服务目标,然后对贯穿整个服务生命周期的策略、指南和流程 进行整体规划。 服务设计是对服务战略的实现,该实现依据的是服务战略中对服务设计和开发的描 述,以及相关服务管理的流程定义,包括服务组合管理、服务级别管理、服务连续性和可 用性管理等方面。服务转换指的是采用有效的、低风险的方式将服务投入到运行环境中, 还包括了对服务的变更、配置、测试、发布和评价等管理,同时将对整个过程中积累下来 的知识进行组织和管理。 服务运营将最终实现服务战略的目标,服务运营需要保证服务交付的效果和支持和效 率,从而实现客户和服务供应商的价值。这个阶段要保证服务的稳定性和可靠性,能满足 服务设计变更及业务不断发展的需求。 持续的服务改进则是推动服务生命周期运转的源动力,通过在服务战略、设计、转换 和运营方面进行改革创新,为客户提供更高质量的服务,在保证服务质量的前提下降低运 营商的运营成本,从而达到客户和运营商双方的利益最大化。服务改进还涉及怎样将服务 战略、服务设计、服务转换及服务运营同服务改进的效果有效关联,从而形成一个良性循 环系统。 ITIL V3生命周期的核心框架是以服务战略为指导,以服务改进为原动力,来推进 设计、转换、运营三个阶段的迭代和螺旋上升,从而促进信息服务管理的改进,满足 第4章 新一代绿色数据中心 133 业务不断发展的需求。服务和业务在这种框架中结合得更为紧密,充分体现了以创造 客户价值和降低运营成本为目标的理念,形成了一个不断发展、优化的信息服务管理 生态系统。 ITIL作为信息服务管理标准化的最佳实践,有效保证了信息服务质量。由于在信息 服务管理方面的优势,它被广泛应用于世界各地的数据中心。实施ITIL有助于规范企业的 流程,明确不同部门的角色和职责,增进业务部门与IT部门的沟通,提高信息服务的可靠 性、可用性和灵活性,降低信息服务管理的风险,从而降低企业的管理成本。对用户而 言,ITIL贯彻了以用户为中心的理念,规范了明晰的服务标准和业务流程,不仅有利于保 证服务质量,而且方便了用户使用信息服务,提高了用户的满意度。 4.4.3 可管理性 可管理性(Manageability)是指一个系统能够满足管理需求的能力及管理该系统的 便利程度。系统管理是一个非常广泛的概念,包括全面深入地了解系统的运行状况、 定期做系统维护以降低系统故障率、发现故障或系统瓶颈并及时修复、根据业务需求 调整系统运行方式、根据业务负载增减资源,以及保证系统关键数据的安全等。大 多数系统管理任务由系统管理员通过使用一系列管理工具来完成,少数管理任务需 要领域专家的参与,另外一些任务可由管理系统自动完成。令人遗憾的是,很多数 据中心由于没有管理工具而导致管理功能的缺失,还有一些管理系统或工具存在设 计缺陷,导致系统的管理复杂烦琐。具体来说,数据中心的可管理性需求包含以下 几个方面。 完备性保障了数据中心可以提供完整的管理功能集。数据中心包含种类繁多的软 件和硬件设备,每个设备都要有相应的工具提供全面的管理支持,例如网络流量 监控、数据库软件的参数配置、服务器所处环境温度监测等。 远程管理是指在远程控制台上通过网络对设备进行管理,免去了到设备现场进行 管理的烦恼。 集成控制台将多个设备的管理功能集成起来,管理员可以在控制台上定义集成化 的任务,通过一个指令完成对若干设备的协调控制,这简化了管理员的操作。 134 云计算宝典——技术与实战 快速响应保障了发出的管理指令能够被尽快执行,即便执行指令需要较长的时 间,也能较准确地把当前状态告知管理员,例如数据备份时需要显示备份的 进度。 可追踪性保障了管理操作历史和重要的事务都能记录在案,以备查找。这些记录 可以作为故障诊断的依据,帮助管理员或领域专家及时定位和解决问题。 方便性保障了管理功能对于管理员来说是真正可操作的,不会烦琐到无法承受的 地步。这一方面要求将重复性的机械化的管理任务用工具替代而非手动完成,另 一方面需要提供统一、简洁、直观的界面,管理员可以容易地找到被管理对象并 发出管理指令。 自动化给可管理性提出了更高的要求,自动化程度越高,管理员的负担越小。 自动化一般采用事件驱动模式,即当特定事件发生时采取特定的行动,若无 法通过程序处理,则应立即发出警报通知管理员。很多管理系统都实现了一 定程度的管理自动化,例如自动化故障诊断、定期自动检查磁盘空间、超过 临界值时发出警报消息等。 4.4.4 可伸缩性 可伸缩性(Scalability)是指一个系统适应负载变化的能力,在负载变大的时候提 高自身的能力以适应负载。例如,一个银行的营业厅可以在等候办理业务人数较多的 时候开启更多的服务窗口,而人少的时候仅开启一两个窗口。一个可伸缩的算法可以 容易地适应大规模的问题,一个可伸缩的计算机系统可以很容易地通过增加硬件来提 高吞吐量。 数据中心需要具备高可伸缩性的IT基础架构,可伸缩性可以从“伸”和“缩”两个角 度理解。“伸”在信息服务上线运行或需要更多资源的时候及时、适量地给予资源分配, 保证业务的正常运行不受影响。“缩”在信息服务下线或资源需求减少的时候适时回收资 源,保证系统的资源高效利用,从而节省运营成本。 第4章 新一代绿色数据中心 135 高可伸缩性的需求主要源于以下几点。首先,用户对服务的使用呈现规律性的高峰期 和低谷期,虽然这种规律一定程度上可以预测,但仍然存在较大波动。其次,突发事件会 对信息服务的负载造成难以预测的影响,例如一个网络上流行的新闻、图片或视频,可以 使相关网站的负载达到平时的百倍甚至千倍以上。此外,信息服务的使用量会随着业务的 发展而增长,长期来看呈现上升的趋势。最后,新的服务层出不穷,对资源的需求也难以 预测。 新一代数据中心对高可伸缩性的要求是及时、适量、细粒度、自动化和预动性。及时 讲求的是快速反应,一旦发出指令后能在较短时间完成伸缩;适量需要分配给信息服务合 适的资源;细粒度要求能以CPU、内存、磁盘为单位分配资源,而不是以物理服务器为单 位,细粒度是适量分配的基础;自动化是指可以在一个控制台上,通过简单的操作完成为 信息服务增加资源或服务器等工作,不需要人工进行准备机器、连接电缆、安装软件等烦 琐的操作;预动性是指能有效预测出信息服务负载的变化趋势,并在负载增加之前就做好 准备,以防负载变化后资源不足,对业务运行造成影响。 4.4.5 可靠性 可靠性(Reliability)是指一个组件或系统执行其功能的能力,系统成功完成指定功能 的概率是衡量系统可靠性的常用指标。系统的可靠性取决于组成系统的组件本身的可靠性 及组件之间的连接关系。组件之间常见的连接方式有串联、并联、K/N表决系统和混合连 接,这几种连接方式构成了可靠性分析的基本模型。如果系统以串联方式连接,任意一个 组件失效则整个系统失效;如果系统以并联方式连接,全部组件失效时整个系统才失效; K/N表决系统包含N个组件,当且仅当不少于K个组件失效时整个系统失效;复杂系统一般 以上述几种方式组合的形式连接。 可靠性对数据中心的重要性不言而喻,在设计数据中心时应尽早考虑。从理论上讲, 数据中心各层组件之间呈串联关系,联合起来为信息服务提供支撑,一旦某一层的 组件失效,就可能导致信息服务的失效。提高可靠性的主要方法有故障避免和故障容 错。故障避免是指提高单个组件的可靠性,减小其失效的概率。要做到故障避免需要 研究组件失效的机理,如寿命失效、设计失效等,并针对不同的失效机理分别应对。 故障容错是指增加冗余组件,利用组件之间的并联关系提升系统的可靠性,例如增加 136 云计算宝典——技术与实战 备份电源等手段。 目前数据中心可靠性分析出现了一些新的趋势,对可靠性的认识也更加深刻。首先, 将可靠性与可维护性结合起来考虑,对于可维修或容易维修的故障,分析其修复率、平均 修复时间等指标。一般来讲,对容易修复的故障容忍程度要高于难修复或不可修复的故 障。其次,要重视对故障系统的管理,因为发生故障时信息服务停止运行的总时间为等待 维修时间与维修时间之和,等待维修时间则取决于故障管理水平,如果管理水平低下,停 机时间将会大大超过维修时间。再次,考虑故障的可容忍性时要对故障引发的后果的严重 程度进行综合分析,以区分致命故障、严重故障和轻度故障。最后,需要用多种指标从不 同维度来衡量可靠性,例如目前普遍认为使用无维修连续工作时间比单纯用失效概率来衡 量可靠性对数据中心的管理人员更有实际意义。 4.5 绿色数据中心 4.5.1 经济型数据中心 企业在IT系统上的投入逐年增多,20世纪70年代,普通的美国公司大约用10%的资本 预算来购买信息技术,而30年以后这一比例已经上升到45%。许多企业因此不堪重负,他 们普遍希望IT部门减少开支和提升效率,降低成本已经成为当前面临的大问题。此外,IT 系统数量和规模的快速增长也使数据中心成本问题显得更为突出。 数据中心的成本构成分为一次性成本和运营成本。一次性成本主要包括建筑成本、服 务器采购成本和其他设备采购成本;运营成本主要包括电力消耗和管理维护成本。服务器 采购、电力消耗和管理维护成本是最主要的三项开支。20世纪60年代,计算机是非常昂贵 的设备,一台大型主机的月租金可达几万美金,相比之下,其他成本都显得微不足道。随 着IT产业的发展,尤其是x86处理器广泛普及以后,计算机在几十年之间变成了廉价的设 备。随着处理器频率的不断提高,单处理器的能耗不断增加,经历了时代的变迁,电力消 耗和管理维护的成本占数据中心成本的比例越来越高。图4.7为数据中心的成本构成及发展 趋势。一方面,在过去几年中,企业的服务器数量在快速增加。另一方面,虽然企业用于 采购服务器的开销基本维持不变,但是数据中心装机规模的增长使得管理和维护工作的复 第4章 新一代绿色数据中心 137 杂度迅速增加,管理成本和能耗也随之增大。 图4.7  数据中心成本构成及发展趋势 降低服务器的采购成本需要合理规划服务器更新换代的周期。IT设备更新换代很快, 一旦服务器闲置,就会造成无形折旧,增加数据中心成本。因此规划时要结合业务需求, 尽可能保证服务器的高利用率。平均每个管理员可管理的服务器数量是评价数据中心管理 维护是否高效的重要标准。当数据中心规模较小时,少数管理员即可承担管理维护任务, 对管理维护水平的要求也相对较低。随着数据中心规模的增大,这种人力密集型的管理手 段难以应付,使用专业的数据中心管理软件、工具和科学的方法可以大幅提升管理效率。 4.5.2 数据中心能效分析 美国环境保护署在2007年8月提交的一份报告中指出,全美数据中心的能源消耗在 2006年占美国能耗的1.5%,预计到2011年将会增加一倍,节能环保已经成为IT基础设施建 设中日益重要的话题。从经济角度来看,国际能源商品价格长期以来处于不断上涨的趋势 中,随着企业对IT基础设施建设的投入不断加大,IT系统的能耗也随之攀升,摆在企业CIO 们面前的一大问题是如何打造绿色数据中心,通过节能减少开支。从环境角度来看,环保 是每一个企业的社会责任,企业需要通过减少耗电量来减少碳排放量,减缓全球变暖的步 伐。已经有一些政府对达到绿色节能环保标准的数据中心给予政策性补贴。然而令人遗憾 的是,很多企业数据中心的耗电量、耗电结构仍然是一笔糊涂账,有的企业甚至将数据中 心的电费账单和办公楼的电费账单混在一起,完全没有节能环保方面的考虑。 138 云计算宝典——技术与实战 图4.8  数据中心耗电比例示意图 图4.8是一个典型的数据中心电力消耗的示意图。据美国能源部统计,电力输送到数据 中心后,平均只有45%被IT设备使用,其他55%则用于冷却系统等耗电设备。用于IT设备 的部分,只有30%被处理器所用,剩下的70%则用于电源、风扇、内存、磁盘等部件。处 理器的平均负载只有5%~20%,剩余部分都被浪费了。 电能利用率(Power Usage Effectiveness,PUE)是在分析数据中心电力消耗时用到的重 要概念,该标准由绿色网格联盟提出,已经成为国际上比较通行的衡量数据中心电力使用 效率的指标。 PUE= 总能耗 IT设备能耗 从PUE的定义可以看出,PUE是总能耗与IT设备能耗的比值,是一个大于1.0的数值, PUE值越接近于1.0说明其他设备的能耗越小,效率也就越高。从这个角度来看,要想降低 数据中心的总能耗,需要从降低IT设备能耗和降低PUE值两方面入手。 首先来谈谈如何降低IT设备的能耗。降低IT设备的能耗需要定期更新设备,人们普遍 存在这样一个误区,认为增加服务器的使用年限可以降低数据中心的成本,于是仍然使用 一些早该淘汰的服务器。其实恰恰相反,落后的服务器能耗更高,占地面积更大,出现故 障的几率也随之增大。刀片服务器是当前数据中心服务器发展的主流趋势。刀片服务器体 积小,通常一个刀片服务器机架可以插入8~16个刀片服务器,这些刀片服务器共用一个 系统背板和冗余电源、风扇、网络端口和其他外部设备,通过这种共享方式,单个刀片服 第4章 新一代绿色数据中心 139 务器的能耗大大降低,服务器电源的工作效率也得到提升。因此,刀片服务器与塔式服务 器和机架式服务器相比性能更高,仅从单位性能耗电量一项指标考虑,改用刀片服务器节 省的电能就可以抵过购买刀片服务器所增加的成本。 提高服务器资源利用率是降低IT设备能耗的另一个方法。目前数据中心服务器的利 用率普遍很低,企业数据中心服务器资源平均利用率在10%~30%之间,很多Windows系 统的服务器利用率不足10%。无论如何这样的数据都让CIO们难以接受,他们不愿相信一 半以上的IT投资都在被浪费。服务器的性能越来越强,而被有效利用部分的比例却越来 越小。 要了解为什么提高服务器资源利用率可以省电,先来了解一下服务器利用率和能耗的 关系。服务器的能耗通常可以分为两部分:一部分是CPU的能耗,这部分能耗和CPU的利 用率直接相关,CPU的利用率越高则能耗越高;另一部分是主板、内存、网络等其他部件 的能耗,这一部分能耗基本为固定值,只与服务器是否开机有关。 举一个简单的例子,假设有三台服务器的CPU利用率都是10%,如果把上面的应用迁 移到一台服务器上,关掉剩下的两台就可以省下这两台服务器的固定能耗,而运行的服 务器的CPU能耗也不会增加太多。电力使用效率是消耗单位电能可提供的计算力,大 致是CPU频率和服务器功率的比值。虚拟化技术使得多个虚拟机可以共享同一台物理 机,从而达到提升服务器资源利用率的目的。虚拟化技术正在被越来越多的企业广泛 采纳,已有很多成功案例。 如果将PUE公式中的总能耗分解,可得 IT设备的能耗取决于IT设备的性能和业务负载,在不更新IT设备的前提下,其能耗由 业务负载直接决定,由于短期内业务负载不会发生巨大改变,所以可以认为短期内IT设 备的能耗是一个固定值。于是,总能耗与PUE值成正比,而PUE值取决于数据中心基础 140 云计算宝典——技术与实战 设施的设计和建设水平及所处环境的气候条件。据统计,国外先进的数据中心PUE值可 达1.6~1.8,而国内的数据中心PUE值平均在2.0~2.5之间,中小规模的数据中心PUE 值更高,有的甚至在3.0以上。近几年新设计建造的数据中心,PUE值可以达到1.8左 右。一个典型的PUE为2.2的数据中心,IT设备耗电量占45%,空调设备耗电量占45%, 而照明等其他设备耗电量之和不过10%,可以看出,一半以上的电量都被空调等设备消 耗了。 节省数据中心的电力消耗需要从两方面着手:一方面需要在保证业务系统需求的前提 下,尽量降低IT设备的能耗;另一方面需要降低PUE值,提高电力使用效率,因为数据中 心的能耗等于IT设备能耗和PUE值的乘积。 降低PUE值需要对数据中心的制冷系统做合理的设计和优化。常见的降低PUE值的方 法包括数据中心选址、合理设定服务器间隔和空调温度、集中冷却、水冷降温等。首先是 数据中心选址,由于空调的能耗与室外温度密切相关,因此将数据中心建在温度较低的地 区可以有效减少制冷系统的能耗。其次,需要合理设定服务器间隔和空调温度。服务器太 密集不利于通风散热,服务器太稀疏会增大数据中心面积,从而影响制冷效果。设定空调 温度的原则是够用即可,并非越低越好。再次,集中冷却方法是给机柜加上一个隔热门, 将机柜内外的空气隔开,让空调的出风口直接将冷风送到机柜内部,这样做的好处是 不需要对整个机房全部进行冷却。最后,水冷降温是比用空调降温更节能环保的方 法,可以作为制冷系统的补充。例如Google公司在美国俄勒冈州Dalles的数据中心就建 在一个河边,利用河水对数据中心进行冷却,冷水温度升高后被送到室外自然冷却, 这一循环过程几乎不消耗电能。 4.6 小结 数据中心是企业的信息中心,它通过网络向企业和公众提供信息服务。随着计算机 产业和互联网的发展,数据中心作为信息服务的运行环境,在人们的生活中扮演着越来越 重要的角色。设计和构建数据中心是一项复杂而专业的系统工程,涉及总体规划、建筑、 电力、网络、制冷、服务器、管理软件及应用软件等各个方面,需要遵循一定的规范和标 准,借鉴以往的成功经验,各类人员相互协作方可顺利完成。 第4章 新一代绿色数据中心 141 数据中心上线后,管理和维护工作同样重要,尽管很多管理工具可以辅助完成这些 复杂而专业的工作,但是随着数据中心规模的扩大及对服务质量要求的提高,数据中 心的复杂性和管理开销逐年增加,这都给新一代数据中心提出了更高的要求,如果合 理规划,可以提高其可管理性、可伸缩性、可靠性,并在降低成本的同时实现节能环 保。本书的后续章节将介绍虚拟化和云计算,这两项技术将会在很大程度上解决新一 代数据中心所面临的问题。 虚拟化管理 6.1 创建虚拟化解决方案 6.2 部署虚拟化解决方案 6.3 管理虚拟化解决方案 6.4 小结 第 6 章 174 云计算宝典——技术与实战 虚拟化技术给数据中心管理带来了诸多优势,它一方面可以提升基础设施利用率,实 现运营开销成本最小化;另一方面可以通过整合应用栈和即时应用镜像部署来实现业务管 理的高效敏捷。目前,如何在数据中心实施虚拟化和实施中的关键技术成为业界关注的重 点。如图6.1所示,实施虚拟化的顺序按照其生命周期可以简单划分为三个重要阶段:创 建、部署和管理。本章将逐一介绍各个阶段所涉及的关键技术。 图6.1 虚拟化解决方案生命周期示意图 6.1 创建虚拟化解决方案 虚拟化解决方案的创建一般由服务提供商和服务集成商完成。由于虚拟化解决方案是 由一系列虚拟镜像或虚拟器件组成的,因此,在这部分我们首先介绍如何创建基本的虚拟镜 像,再描述如何创建、组装和发布虚拟器件,然后讨论虚拟器件发布后的镜像管理,最后阐 述将物理机环境转换为虚拟机环境的技术。 6.1.1 创建基本虚拟镜像 根据第5章给出的定义,虚拟机是指通过虚拟化软件套件模拟的、具有完整硬件功能 的、运行在一个隔离环境中的逻辑计算机系统。虚拟机里的操作系统被称为客户操作系统 (Guest Operating System,Guest OS),在客户操作系统上可以安装中间件和上层应用程 序,从而构成一个完整的软件栈。虚拟镜像是虚拟机的存储实体,它通常是一个或者多个 文件,其中包括了虚拟机的配置信息和磁盘数据,还可能包括内存数据。 第6章 虚拟化管理 175 虚拟镜像的主要使用场景是开发和测试环境:软件开发人员在虚拟机内部对应用进行 开发测试,把虚拟镜像作为应用在初始状态或某一中间状态的备份来使用,这样能够在当 前的环境发生不可恢复的变更时方便地用虚拟镜像恢复到所需要的状态。 虚拟镜像大致可以分为两类:一类是在虚拟机停机状态下创建的镜像,由于这时的虚 拟机内存没有数据需要保存,因此这种镜像只有虚拟机的磁盘数据;另一类是在虚拟机运 行过程中做快照所生成的镜像,在这种情况下,虚拟机内存中的数据会被导出到一个文件 中,因此这种镜像能够保存虚拟机做快照时的内存状态,在用户重新使用虚拟机时可以立 即恢复到进行快照时的状态,不需要进行启动客户操作系统和软件的工作。由于目前使用 较广泛的是停机状态下创建的虚拟镜像,因此下文主要讨论这类虚拟镜像。对于快照技术 及快照镜像会在6.2.2节中做介绍。 创建一个最基本的虚拟镜像的流程包括以下三个步骤:创建虚拟机、安装操作系统和 关停虚拟机,如图6.2所示。第一步,在虚拟化管理平台上选择虚拟机类型,并设定虚拟硬 件参数。参数主要包括虚拟机的CPU数量、内存大小、虚拟磁盘大小、挂载的虚拟光驱及 虚拟磁盘等,其中虚拟磁盘的设定要充分考虑到后续安装软件所需空间的实际情况。虚拟 化管理平台将依据这些参数创建相应的虚拟机。第二步,选择客户机操作系统并安装,这 个过程一般在虚拟化软件套件提供的虚拟机窗口界面上进行,类似于在一台普通的物理机 器上安装操作系统。安装客户机操作系统时要遵循“够用即可”的原则,移除不必要的模 块、组件和功能,这样既能提高虚拟机运行时的性能,又可以降低虚拟机受攻击的风险。 最后一步是关停虚拟机,保存生成的虚拟镜像和配置文件。经过这三个步骤,一个最基本 的虚拟镜像就创建完毕了,整个过程一般需要十几分钟左右。 图6.2 创建虚拟镜像流程图 176 云计算宝典——技术与实战 目前主流的虚拟化软件套件都提供了非常方便的虚拟镜像创建功能,一般来说都是图 形化、流程化的,用户只需要根据虚拟化软件提供的提示,填写必要的信息,就可以很方 便地完成虚拟镜像的创建。 6.1.2 创建虚拟器件镜像 在上一节中介绍了如何创建一个最基本的虚拟镜像,但对于用户来说,这样的虚拟镜像并 不足以直接使用,因为用户使用虚拟化的目的是希望能够将自己的应用、服务、解决方案运行 在虚拟化平台上,而基本虚拟镜像中只安装了操作系统,并没有安装客户需要使用的应用及运 行应用所需的中间件等组件。当用户拿到虚拟镜像后,还要进行复杂的中间件安装,以及应用 程序的部署和配置工作,加上还需要熟悉虚拟化环境等,反而有可能使用户感觉使用不便了。 虚拟器件(Virtual Appliance)技术能够很好地解决上述难题。虚拟器件技术是服务器 虚拟化技术和计算机器件(Appliance)技术结合的产物,有效吸收了两种技术的优点。根据 Wikipedia的定义,计算机器件是具有特定功能和有限的配置能力的计算设备,例如硬件防火 墙、家用路由器等设备都可以看做是计算机器件。虚拟器件则是一个包括了预安装、预配置的 操作系统、中间件和应用的最小化的虚拟机。如图6.3所示,和虚拟镜像相比,虚拟器件文件 中既包含客户操作系统,也包含中间件及应用软件,用户拿到虚拟器件文件后经过简单的配置 即可使用。与计算机器件相比,虚拟器件摆脱了硬件的束缚,可以更加容易地创建和发布。 图6.3 虚拟器件结构图 第6章 虚拟化管理 177 虚拟器件的一个主要使用场景是软件发布。传统的软件发布方式是软件提供商将自己 的软件安装文件刻成光盘或者放在网站上,用户通过购买光盘或者下载并购买软件许可证 的方法得到安装文件,然后在自己的环境中安装。对于大型的应用软件和中间件,则还需 要进行复杂的安装配置,整个过程可能耗时几个小时甚至几天。而采用虚拟器件技术,软 件提供商可以将自己的软件及对应的操作系统打包成虚拟器件,供客户下载,客户下载到 虚拟器件文件后,在自己的虚拟化环境中启动虚拟器件,再进行一些简单的配置就可以使 用,这样的过程只耗时几分钟到几十分钟。 可以看出,通过采用虚拟器件的方式,软件发布的过程被大大简化了。认识到虚拟 器件的好处之后,很多软件提供商都已经开始采用虚拟器件的方式来发布软件。例如, VMware的官方网站已经有“虚拟器件市场”;在Amazon EC2环境里,虚拟器件已经用于商 业目的;IBM的内部网站上包含IBM主要软件产品的虚拟器件正在被大量下载和使用。可 以预见,在不远的将来,虚拟器件将成为最为普及的软件和服务的发布方式,用户不再需 要花费大量的人力、物力和时间去安装、配置软件,工作效率会得到很大提高。 上文谈到了虚拟器件的基本概念及使用场景,而为了更方便、高效地使用虚拟器件, 并让它支持复杂的企业级虚拟化解决方案,创建虚拟器件的过程需要一系列技术的支持, 如图6.4所示。在制作虚拟器件之前,需要考虑两方面的关键技术:对多个虚拟器件组成的 复杂虚拟化解决方案进行预先规划和通过配置元数据和脚本实现虚拟器件的高度灵活性和 模板化。 图6.4 虚拟器件创建流程图 178 云计算宝典——技术与实战 虚拟器件在很多场景下都要支持复杂的企业级应用和服务,而应用和服务的特点是需 要多个虚拟器件组合交付,在虚拟器件的创建阶段需要考虑各个虚拟器件的关联关系,因 而前期调研显得尤为重要。在创建虚拟器件之前,我们首先要调研和分析如何把现有的服 务迁移、封装成若干个虚拟器件,然后编写相应配置脚本、规范配置参数并进行多次测试 和验证,最后才是真正创建虚拟器件。制作出来的虚拟器件是一个模板,部署者在后续的 部署过程中可以将其复制并生成多个实例,将解决方案交付给最终用户。下面详细介绍以 上三个阶段的工作。 在开始的调研工作中,需要分析解决方案都由哪些应用模块组成。从基于单机的小型 LAMP(Linux-Apache-MySQL-PHP)解决方案(如图6.5所示),到基于集群的企业级解 决方案,设计人员需要针对不同的应用场景进行调研工作。例如,IBM公司的模拟股票交 易软件Trade,用户虽然只是通过Web方式访问,但是,底层的支撑模块包括了Web服务器 (IBM HTTP Server,IHS)、应用服务器集群(IBM WebSphere Application Server,WAS) 和后端的数据库(IBM DB2 Server),如图6.6所示,而且,这三者并不是单独运行的实 体,它们之间需要相互关联才能支撑模拟股票交易的服务。 因此,要将这种复杂的应用封装到多个虚拟器件上,需要对其进行大致的分层或者分 类,将不同层次或类型的支撑模块分别安装在不同的虚拟器件中。 在前面的例子中,针对于Web服务器、应用服务器和数据库服务器,至少需要三个虚 拟器件。需要注意的是,中间件或者应用可能出现多种形态,比如刚才提到的IBM WAS服 务器,它可以按需被配置成多种形态,如Deployment Manager、Standalone、Managed Node、 Cell等。对于这种情况,虚拟解决方案中只需要一个WAS虚拟器件就可以了,因为通过在 部署阶段读取传入的参数,配置脚本可以将其实例化成上面提到的各种形态。在分层或分 类以后,需要考虑支撑模块和操作系统之间的兼容性和配置优化问题。在对支撑模块优 化完成以后,还需要对整个解决方案进行联调,目的主要是对网络参数、安全参数等参 数进行配置,对请求连接数、数据源缓存等进行优化,这部分工作对后面配置脚本的编 写很重要。 第6章 虚拟化管理 179 图6.5 LAMP 解决方案 图6.6 IHS-WAS-DB2 解决方案 调研工作完成以后,设计人员就可以编写配置脚本并进行测试了。在前期工作中,我 们知道了如何对虚拟器件操作系统和支撑模块调优,由于虚拟器件中的软件栈已经固定, 因此这些调优基本上都是一次性的,只需要在创建虚拟器件时配置成最优的固定值即可。 但是,对中间件或模块的多态处理、联调时的网络配置、应用参数的设定等操作才是虚拟 器件能够适应各种部署环境的根本所在。这些内容的配置需要编制脚本,并根据部署时传 入的参数完成。通过脚本实现配置的设定是一个相对简单的操作,只要支撑模块开放命令 行接口,脚本就能通过执行一系列命令的方法来使得配置生效。在脚本编制完成以后,设 计人员需要确定配置参数及调用脚本的逻辑顺序,并进行测试和验证,使得配置脚本能够 满足不同实例化的要求。测试过程分为单元测试和集成测试,单元测试主要检测单个脚本 的正确性,而集成测试模拟脚本执行的顺序来逐一测试脚本,以保证最终用户需要的解决 方案能够被成功部署。 最后一个步骤是创建虚拟器件,这个过程包括三个子步骤:第一步,创建虚拟镜像; 第二步,分别在虚拟镜像中安装和优化服务解决方案所需的中间件和支撑模块;第三步, 180 云计算宝典——技术与实战 安装上文所提到的配置脚本,并且配置相应的脚本执行逻辑和参数,从而使得脚本在虚拟 器件的启动、配置过程中能够按照一定的顺行执行。 当与一个应用或服务相关的虚拟器件都创建完成以后,可以将它们保存起来,供发布 和部署时使用。 6.1.3 发布虚拟器件镜像 随着服务器虚拟化技术的发展,各大厂商都推出了自己的虚拟器件,但是这些产品的 接口规范、操作模式互不兼容,妨碍了用户将多个不同厂商的虚拟器件组装成自己所需的 虚拟化解决方案,也阻碍了虚拟化技术的进一步发展和推广。在这种背景下,需要统一的 标准来明确接口规范,提高互操作性,规范各大厂商的虚拟器件组装和发布过程。 在IBM、VMware、微软、思杰和英特尔等虚拟化厂商的倡导下,DMTF(Distributed Management Task Force)非赢利标准化组织制定了开放虚拟化格式(Open Virtualization Format,OVF)。 OVF标准为虚拟器件的包装和分发提供了开放、安全、可移植、高效和可扩展的描述 格式。OVF标准定义了三类关键格式:虚拟器件模板和由虚拟器件组成的解决方案模板的 OVF描述文件、虚拟器件的发布格式OVF包(OVF Package),以及虚拟器件的部署配置文 件OVF Environment。下面分别介绍OVF描述文件和OVF包,而OVF Environment的内容将在 6.2节中介绍。 每个虚拟化解决方案都能够通过一个OVF文件来描述。目前,最新的OVF1.0规 范中定义了虚拟器件的数量,以及每个虚拟器件的硬件参数信息、软件配置参数信 息和磁盘信息等各种信息。图6.7描述了一个OVF描述文件的实例结构。OVF描述文 件通过对标准的XML格式进行扩展来描述一个虚拟器件(在OVF规范中称为Virtual System),或者若干个虚拟器件整合成的一个解决方案(在OVF规范中称为Virtual System Collection),这些虚拟器件可以来自不同厂商。由于OVF描述文件中包括了整 合后的各个虚拟器件之间的关联关系、配置属性和启动的先后顺序等关键信息,因此 用户或者任何第三方厂商编写的部署工具都能够解析OVF文件,并快速地部署其中描述 的各个虚拟器件。 第6章 虚拟化管理 181 图6.7 OVF描述文件结构示意图 OVF包是虚拟器件最终发布的打包格式,它是一个按照IEEE 1003.1USTAR POSIX标 准归档的以.ova为后缀的文件。OVF包里面包含了以下几种文件:一个以.ovf为后缀结尾的 OVF文件、一个以.mf为后缀结尾的摘要清单文件、一个以.cert为后缀结尾的证书文件、若 干个其他资源文件和若干个虚拟器件的镜像文件,如图6.8所示。 图6.8 OVF包结构示意图 如前所述,OVF文件描述了整个解决方案的组成部分,以及每个组成部分的内在特性 和组成部分之间的关联关系。镜像文件既可以是虚拟器件的二进制磁盘文件,也可以是一 个磁盘配置文件,它记录了下载二进制磁盘文件的URI地址。摘要清单文件记录了OVF包 182 云计算宝典——技术与实战 里面每个文件的哈希摘要值、所采用的摘要算法(比如SHA-1、MD5)等信息。证书文件 是对摘要清单文件的签名摘要,用户可以利用这个摘要文件来对整个包进行认证。资源文 件是一些与发布的虚拟器件相关的文件,比如ISO文件等。这些文件中,摘要清单文件、 证书文件和资源文件是可选的,而OVF文件和镜像文件是必需的。 以OVF包的方式发布虚拟器件,包含以下几个步骤。第一,创建需要发布的虚拟器件 所对应的OVF文件。第二,准备好需要添加到OVF包里的虚拟器件镜像,为了减小OVF包 的体积,二进制格式的虚拟磁盘可以采用GZIP格式进行压缩。第三,为了防止恶意用户 对发布的OVF包进行篡改,应该对OVF包里面的文件做哈希摘要和签名,并将这些信息保 存到摘要清单文件和证书文件,但是这个步骤目前并不是必需的。第四,如果有必要,准 备好相关的资源文件。最后,用TAR方式对OVF文件、虚拟器件的镜像文件、摘要清单文 件、证书文件和相关资源文件进行打包,并放置在一个公共的可访问的空间,准备被用户 下载或部署。 为了简化组装、发布虚拟器件的操作,IBM公司发布了OVF工具箱,它是一个Eclipse 插件程序,功能包括可视化地创建、编辑OVF,对OVF所含信息进行完整性校验,以及将 虚拟器件打包成OVF包格式。VMware公司也推出了一款叫做VMware Studio的产品,该工具 在基于网页的控制台上为虚拟器件创建OVF包,还能够为已经部署的OVF镜像包提供自动 更新。思杰(Citrix)公司于2008年底也发布了支持OVF的工具Kensho(预览版),该软件 能够将虚拟器件打包成OVF包,并将其导入到多种虚拟化管理平台上。此外,思杰公司还 和Amazon公司合作,将该工具应用于Amazon EC2云计算平台上。 6.1.4 管理虚拟器件镜像 如上面几节所述,用户按照流程创建、打包好虚拟器件镜像后,会将镜像发布到公共 的可访问的仓库,准备被下载或部署。这样的公共仓库会储存大量的虚拟器件镜像,而一 般来说一个虚拟器件镜像文件都有几GB甚至几十GB,在这种情况下,对大量虚拟器件镜 像的有效管理显得十分重要。 镜像文件管理的目标主要有三个:一是保证镜像文件能够被快速地检索到,二是尽 量减小公共仓库的磁盘使用量,三是能够对镜像进行版本控制。目前比较成熟的解决办法 是对镜像文件的元数据信息和文件内容分别存储。镜像文件的元数据信息主要包括文件的 第6章 虚拟化管理 183 大小、文件名、创建日期、修改日期、读写权限等,以及指向文件内容的指针链接。而镜 像文件的实际内容一般会采用切片的方式进行存储,将一个很大的镜像文件切成很多的小 文件片,再将这些文件片作为一个个的文件单独存放,为每一个文件分配一个唯一的标识 符,以及文件内容的摘要串。这需要在镜像文件的元数据里增加新的信息,这个信息记录 了镜像文件对应的各个文件片。 采用文件切片方法的好处在于,由于很多镜像文件具有相似的部分,例如相同的操作 系统目录,通过镜像切片及生成的内容摘要,镜像管理系统可以发现这些镜像文件中相同 的文件片,然后对这些文件片进行去重操作,在文件系统中只保存单一的切片备份,这种 方法可以大大地减少镜像文件的磁盘空间占用量。文件切片同样有利于镜像的版本管理, 因为一般来说,一个文件的版本更新只涉及整个文件的一小部分,通过镜像切片技术,当 一个镜像的新版本进入系统时,系统会通过切片及生成摘要,识别出新版本中哪些切片的 内容与之前的版本不同,然后只保存这些不同的切片。 在采用了文件切片和版本管理的镜像管理系统上获取一个虚拟器件镜像的流程大致如 下:第一步,用户选择虚拟器件的名称或标识符,以及虚拟器件的版本号码,如果用户没 有给出版本号码,系统会默认用户需要最新版本;第二步,系统根据用户给出的虚拟器件 名称或标识符,在镜像文件库中找到对应的元数据描述文件;第三步,根据用户给出的或 由系统生成的版本号码,在元数据文件中找到对应的版本信息;第四步,系统根据元数据 文件对应版本中标明的文件切片信息,从文件切片库中找到对应的切片;第五步,系统根 据元数据文件中文件切片的顺序,对找到的文件切片进行拼接;第六步,系统将组装好的 虚拟器件镜像文件包返回给用户。 6.1.5 迁移到虚拟化环境 在虚拟化广泛普及之前,数据中心的绝大多数服务都部署在物理机上。随着时间的推 移,这些物理设备逐渐老化,性能逐渐下降,所运行的服务的稳定性和可靠性都受到了极 大的影响。然而,想要把服务迁移到新的系统上会面临很大的风险。这主要有两个方面原 因:一方面是开发人员的流动性,当需要迁移服务时,可能已经找不到以前开发团队的相 关人员了;另一方面是服务对系统的兼容性问题,服务所依赖的老系统的特定接口或者函 数库在新的系统里面并不一定兼容,这些问题长期困扰着传统数据中心的管理。 184 云计算宝典——技术与实战 随着虚拟化的日益流行和其优势的不断体现,人们也在思考如何让已有的服务迁 移到虚拟化环境里来充分利用虚拟化所带来的好处。虚拟化的辅助技术P2V(Physical to Virtual)成为决定服务器虚拟化技术能否顺利推广的关键技术。顾名思义,P2V就是物理 到虚拟,它是指将操作系统、应用程序和数据从物理计算机的运行环境迁移到虚拟环境 中,如图6.9所示。P2V技术能够把应用服务与操作系统一起从物理服务器上迁移到虚拟环 境中,通过这样整体性的解决方案,管理员不再需要触及与系统紧密整合的应用的相关代 码,大大提高了系统迁移的可行性和成功率。 图6.9 P2V示意图 当然,P2V技术的原理并不是文件拷贝那么简单。例如,在操作系统启动过程中, 操作系统内核负责发现必要的硬件设备和相应的驱动程序,如果内核没有发现合适的驱 动,硬件设备就无法正常运行。因此,要将物理机上的整套系统迁移到虚拟机上,硬件 设备从“真实的”变成了“虚拟的”,相应的驱动程序也需要替换成能够驱动“虚拟” 硬件的程序。 绝大多数实现P2V技术的软件都遵循了上述原理。下面,我们来看看用户操作P2V软 件的基本步骤。 第一步制作镜像,通过镜像制作工具将物理机的系统整体制作成物理机的镜像。这里 的镜像制作工具既可以是P2V软件自带的,也可以是第三方的软件。 第二步选择驱动,替换掉镜像中与特定硬件设备相关的驱动程序或者磁盘驱动器,并 且保证镜像中新的驱动程序和其他驱动程序在系统初始化时有序启动,以使镜像能够在虚 拟环境中运行。 第6章 虚拟化管理 185 第三步定制配置,用户手动输入必要的参数,例如虚拟机的CPU、内存、MAC地址 等,P2V软件根据数据的参数生成能够让镜像被虚拟机监视器所识别的配置文件。 总之,P2V软件需要捕捉物理系统的所有硬件配置、软件配置、磁盘内容等信息,并 对与客户环境定制化相关的配置参数进行抽象,将所有这些信息打包成一个镜像及相应的 虚拟机监视器相关的配置文件。 就具体的操作系统而言,由于Linux系统内核是开放的,因此实现P2V的过程相对较为 简单;Windows系统内核没有公开,P2V相对比较复杂,如果不能很好地解决驱动替换,在 虚拟机启动时很可能出现不能操作的现象,因此存在一定的风险。 值得一提的是,伴随P2V技术的还有V2P(Virtual to Physical)和V2V(Virtual to Virtual)技术。所谓V2P就是将虚拟机向物理机迁移,类似于我们日常所用的Symantec Ghost软件,只是增加了对各种不同物理平台的硬件设备的驱动支持。而V2V技术使得系统 和服务可以在不同的虚拟化平台之间进行迁移,比如现有的系统和服务运行在Xen虚拟机 上,通过V2V迁移,使得系统和服务可以运行在VMware ESX虚拟机上。 6.2 部署虚拟化解决方案 当虚拟器件被创建、发布以后,它们需要通过某种方式被部署到数据中心里才能被 用户使用。在这个阶段,我们首先要考虑如何规划虚拟化环境,选择合适的虚拟化厂商和 产品,将数据中心的计算资源、存储资源和网络资源进行虚拟化,从而保证虚拟器件能够 在虚拟化环境里面正常运行,这些内容将在6.2.1节“规划部署环境”中讲述。6.2.2节“部 署虚拟器件”将介绍把虚拟器件部署到虚拟化环境里面的具体步骤及相应的关键技术。最 后,在6.2.3节“激活虚拟器件”中将介绍在虚拟器件内部对于虚拟器件模板进行实例化的 过程和技术。通过这三个过程,虚拟器件就可以最终被用户使用了。 6.2.1 规划部署环境 通过第2章的讲述我们知道,数据中心采用虚拟化能够显著地提高服务器利用率,缩 186 云计算宝典——技术与实战 短服务部署时间,减少能耗、制冷和维护等成本。然而不可否认的是,虚拟化技术同时带 来了新的问题:在管理层次上增加了虚拟机层,增加了资源管理和调度的复杂性。另外, 面向服务的架构(Service Oriented Architecture,SOA)催生了大量的由松散耦合的功能模 块组成的业务,当这些业务被部署在数据中心时需要更加快捷、便利。因此,在数据中心 构建虚拟化环境时,用户应该进行投资回报分析,根据自己的业务需求来规划数据中心的 计算资源、存储资源和网络资源,并选择适合的虚拟化厂商和产品来寻找虚拟化环境的管 理能力及成本的平衡点。 下面将根据构建虚拟化环境的三个步骤即投资回报分析、资源规划和虚拟化平台厂商 及产品的选择来分别介绍相关的关键技术。 第一个步骤是投资回报分析。作为企业的管理人员,最关心的是自己的投资能否获得 更高的回报,对数据中心实施虚拟化同样要考虑这样的问题,在实施虚拟化之前进行投资 回报(Return On Investment,ROI)分析就显得尤为重要。投资回报分析是通过一系列的 经济学方法对数据中心内各种资源的成本进行处理分析,得到数据中心实施虚拟化以后 效益是否能够提高的预测值。通常,在分析过程中需要考虑直接投资成本和间接投资成 本。比较常见的直接投资成本包括:服务器硬件设备成本、网络硬件设备成本、存储设 备成本、配套制冷设备成本、虚拟化软件成本、构建虚拟化环境的时间成本和相关设施 的维护成本等。 另外,还需要结合服务器硬件性能和虚拟化软件来考察数据中心的整体虚拟化能力, 这个能力决定了该数据中心能够容纳的虚拟机的数量,从而间接得出能够容纳的虚拟化 解决方案数量。很多虚拟化厂商都提供简单的计算工具方便用户计算投资回报率,比如 VMware公司的在线ROI计算器、PlateSpin公司的PlateSpin Recon。对于复杂的大型数据中 心,用户也可以找第三方的专业公司来分析投资回报率。 第二步是资源规划。数据中心的资源主要包括三大类:计算资源、存储资源和网络资 源。计算资源是指物理服务器的计算处理能力,和CPU、内存相关;存储资源是指数据中 心的存储能力,和磁带、磁盘、存储系统的空间相关;网络资源是指数据中心的网关、子 网、带宽和IP等资源。通过虚拟化技术,数据中心里面的各种资源被整合成了统一的资源 池。资源规划就是要研究如何把由虚拟器件组成的解决方案部署在虚拟化环境里,合理分 配资源,并且保证资源的高效利用。 第6章 虚拟化管理 187 资源规划一般从计算资源规划入手,资源规划者在能够保证虚拟化解决方案所需要的 计算资源的前提下,再考虑与存储、网络资源池分配相适应的资源。对于计算资源,常用 的衡量指标是VM/Core,它指单台物理机的CPU里每个核(Core)上所能运行的虚拟机的数 量。如果单台物理服务器的计算资源无法满足解决方案服务的需求,就需要用到多台服务 器资源。这时,虚拟机的负载均衡就成为很重要的因素。可以保证规划阶段分配的资源能 够得到充分利用。当然,还需要考虑存储资源的I/O负载均衡、网络资源的带宽均衡等。在 产品方面,VMware公司推出的资源规划辅助工具Capacity Planner能够帮助数据中心更方便 地进行规划。IBM公司的全球技术服务部(GTS)也提供了相关的服务来帮助客户对数据 中心现有资产做出评估,并在战略上实施资源规划。 第三步是虚拟化平台厂商及产品的选择。在第2章我们曾简单介绍了x86平台下的主 流虚拟化厂商。目前,主流的企业级虚拟化平台有VMware公司的ESX Server、Xen及微软 公司的Hyper-V。用户在进行选择时,需要综合考虑这些产品的价格、功能、兼容性, 找到适合自己的产品。从价格上来说,VMware ESX Server按服务器的内核数量来计价, Hyper-V是随着Windows Server2008系统一同发售的,而Xen有两个版本:商业版(Critix Xen Server)和开源版,其中开源版可以免费下载和使用。从功能上来说,各个厂商都提供 了基本的虚拟化平台及虚拟机管理命令。在这些功能之外,VMware提供了集成化的数据中 心管理平台Virtual Infrastructure,以及之上的迁移、容错、备份等套件,XenServer也有对应的 数据中心管理工具,微软Hyper-V的附加功能目前比较少。从兼容性上来说,Xen和VMware 都对Linux系统有很好的兼容性,在Windows平台下,VMware也能够提供大部分管理功能,并 支持创建Windows虚拟机,作为Windows一部分的Hyper-V能够对Windows操作系统提供良好的 支持。 6.2.2 部署虚拟器件 准备工作完成以后,就可以进行虚拟器件的部署了。部署虚拟器件是将虚拟器件支持 的解决方案交付给用户的过程中最重要的一个环节,即虚拟机实例化的阶段。在6.1节所提 到的步骤中,我们已经知道了如何创建虚拟器件和发布虚拟器件,而部署阶段所要做的工 作就是使虚拟器件适应新的虚拟化环境,并将其承载的解决方案交付给用户。 部署虚拟器件的流程(如图6.10所示)大致可以分为以下6个步骤: 188 云计算宝典——技术与实战 1.选择虚拟器件并定制化;2.保存定制化参数文件为OVF Environment文件;3.选择部 署的目标物理机;4.复制虚拟器件的镜像文件和配置文件;5.启动虚拟器件;6.在虚拟器件 中进行激活。目前,比较主流的部署工具都能够完成流程中前5步操作,下面我们详细介 绍每一个步骤,而第6步操作在虚拟机内部进行,我们将在6.2.3节中单独介绍。 1. 选择虚拟器件并定制化 3. 选择目标物理机 4. 复制虚拟器件相关文件 5. 启动虚拟器件 6. 激活虚拟器件 镜像仓库 虚拟器件 虚拟化数据中心 2. 保存定制化参数 部署服务器 OVF Environment文件 图6.10 部署虚拟器件流程图 第1步,选择虚拟器件并定制化。在部署虚拟器件之前,用户首先要选择需要部署的 虚拟器件,并输入配置参数。这一步是整个部署过程中少数需要用户参与的步骤之一,由 于采用了虚拟器件技术,需要用户配置的参数相对于传统的部署已经变得非常简单,而且 部署工具还能够帮助用户对这些参数进行配置,进一步减少了用户操作的复杂性。概括 来说,用户可以配置的参数信息包括虚拟机的虚拟硬件信息(CPU、内存等),以及少量 的软件信息。软件信息是指虚拟机内部软件栈(操作系统、中间件、应用程序)相关的配 置,其中与网络和账户相关的参数必不可少。网络参数是连接各个虚拟器件从而构成整体 解决方案的重要信息,包括IP地址、子网掩码、DNS服务器、主机名、域名、端口等,它 们既可以由用户手动分配,也可以由部署工具自动分配。账户参数的设定是用户定制化最 重要的环节,主要包括虚拟机的用户名和密码、某个软件的用户名和密码,或者某个数据 源的用户名和密码等。出于安全方面的考虑,这些参数一般情况下需要用户去指定,而不 采用默认值。 第2步,保存定制化参数文件。在第1步生成的定制化信息需要保存在文件中,以便被 后续的虚拟机配置程序调用。一般来说,定制化信息被保存为两个文件:一个文件保存虚 拟机的硬件配置信息,用于被虚拟化平台调用来启动虚拟机;另一个文件保存的是对于虚 拟器件内的软件进行定制的信息。虚拟机配置文件与虚拟机的平台相关,因此需要遵循厂 商指定的文件格式规范。对于虚拟器件的软件定制化信息,由于在虚拟化技术产生的初期 第6章 虚拟化管理 189 各个厂商独自开发自己的部署工具,使得保存定制化参数的方式各不相同,例如有些厂商 使用文本配置文件,有些厂商使用XML文件。在上文提到的开放虚拟化格式(OVF)成为 工业标准以后,这一问题得到了有效的解决,目前各大厂商都会按照OVF Environment文件 的格式来保存定制化的信息。 在6.1.3节中已经介绍了OVF标准及其定义的文件格式,具体对于OVF Environment文 件,OVF标准是这样定义的:该文件定义了虚拟机中的软件和部署平台的交互方式,允许 这些软件获取部署平台相关的信息,比如用户指定的属性值,而这些属性本身是在OVF文 件里定义的。OVF Environment规范分为两个部分,一个是协议部分,另外一个是传输部 分。协议部分定义了能够被虚拟机上软件获取的XML文档的格式和语义,而传输部分定义 了信息是怎样在虚拟机软件和部署平台上通信的。综合来说,虚拟器件的模板描述信息、 能够被用户配置的属性项信息、属性的默认值等信息在OVF文件里进行了描述,而客户在 第1步填写的定制化信息在OVF Environment文件里面描述。两个文件通过将属性的名称作 为关键字进行匹配。 第3步,选择部署的目标物理机服务器。目标机至少需要满足下列几个条件:网络畅 通、有足够的磁盘空间放置虚拟镜像文件、物理资源满足虚拟机的硬件资源需求(CPU、 内存数量足够)、虚拟化平台与虚拟器件的格式兼容(例如Xen平台支持Xen虚拟器件、 VMware平台支持VMware虚拟器件)。目前的部署工具都能够自动完成对上述几个条件的 检查工作。具体来说,部署工具会通过网络连接目标服务器,连接成功后,通过执行系统 命令检查服务器上的CPU、内存、磁盘空间、虚拟化平台。在检查通过后,返回给用户可 以部署的信息。另外,有些部署工具可以提供更高级、更智能的部署能力,让用户事先输 入一组服务器的列表,组成一个服务器池,当用户选择要部署一个虚拟器件时,部署系统 根据上述几个条件自动从服务器池中选择出满足条件的一台服务器,作为部署的目标机。 部署工具还可以考虑用户的定制化需求,将虚拟器件部署到网络较好的服务器,或者部署 到硬件性能比较好的服务器,或者部署到没有运行其他虚拟机的服务器,或者考虑一个解 决方案中的多个虚拟器件的关系,将它们部署到同一个服务器或者多个不同的服务器上。 第4步,拷贝虚拟器件的相关文件。在用户完成参数定制化并选择了目标物理机以 后,部署工具就可以从虚拟器件库中提取出用户选择的虚拟器件的OVF包,再将它们与第2 步生成的OVF Environment文件、虚拟机配置文件一起复制到目标物理机上。由于虚拟器件 镜像的大小一般都在几GB到几十GB,而目前的网络主要是百兆网或者千兆网,因此部署 190 云计算宝典——技术与实战 的时间瓶颈在于传输所耗费的时间。随着虚拟化服务越来越受到人们的重视,相应的厂商 也不断开发出新的技术来解决部署费时的问题,目前比较成熟的技术有镜像流技术和快照 技术。 镜像流传输类似于在线视频播放的流媒体:通过流媒体技术,用户可以边下载影音文 件,边播放已下载的部分。这样的好处是用户不需要等待整个文件下载完毕再播放,节省 了时间,优化了用户体验。对于典型的虚拟器件,其内容包括操作系统、中间件、应用软 件,以及用户需要使用的剩余空间。用户在启动虚拟器件时,主要是启动虚拟器件的操作 系统、中间件和应用软件,这些部分仅占整个虚拟器件文件中的一小部分,通过镜像流技 术就可以无须下载整个虚拟器件而即时启动虚拟机。 简单来说,在虚拟器件启动时,虚拟器件通过流传输的方式从镜像存储服务器传输到 虚拟化平台上,虚拟器件在接收其镜像的一部分后,即可开始启动过程。虚拟器件余下的 部分可以按需从镜像存储服务器中获取,从而减少了虚拟器件的部署时间,使得部署的总 时间只需要几十秒钟到几分钟。镜像流传输技术与6.1.4节中提到的镜像切片技术可以很好 地结合,部署系统按照流传输方式请求镜像时,镜像管理系统无须将文件片打包成镜像文 件包再整体返回给部署工具,而是按照文件片的顺序,依次将文件片以文件流的方式传输 给部署工具。通过省去虚拟器件文件片组装打包的过程,进一步缩短了整个部署的时间。 快照技术的本意是用来帮助虚拟机进行备份和恢复,但是它同样可以辅助虚拟化服 务的部署。快照技术在部署中的典型应用场景是:在部署虚拟器件时,部署工具会检查在 部署目标机上是否已经存在被部署虚拟器件的快照,如果存在,就不需要再将虚拟器件镜 像文件复制到虚拟化平台,而是通过虚拟化平台的应用接口将快照作为模板,快速复制出 新的虚拟器件,并通过定制化配置成为用户可用的状态;如果快照不存在,在虚拟器件镜 像被部署后,部署工具会通过虚拟化平台提供的应用接口对虚拟器件做快照,方便以后使 用。快照技术的好处在于可以减少二次至多次部署的时间。 第5步,在目标机上启动部署后的虚拟器件。部署工具会通过远程连接的方式,在目 标机上执行一组命令,来完成虚拟器件的启动。在启动过程中有一个关键过程,是将第2 步生成的软件配置参数文件传送到虚拟器件中。目前采用虚拟磁盘的方法进行传送,也就 是说将OVF Environment文件打包为一个ISO镜像文件,在虚拟器件的配置文件中添加一个 虚拟磁盘的配置项,将其指向打包的ISO镜像文件。这样,当虚拟器件启动后,在虚拟器 件内部就可以看到一个磁盘设备,其中存放着OVF Environment文件。总体来说,这一步需 第6章 虚拟化管理 191 要执行的操作依次为:将OVF Environment文件打包为ISO文件,修改虚拟器件配置文件创 建虚拟磁盘项,在虚拟机管理平台上注册虚拟器件信息,启动虚拟器件。 6.2.3 激活虚拟器件 虚拟器件部署的最后一个步骤是在虚拟器件内部读取OVF Environment文件的信 息,根据这些信息对虚拟器件内的软件进行定制,这个过程被称为虚拟器件的激活 (Activation)。根据激活的自动化程度及功能,激活可以划分为:完全手动的激活、基于 脚本的手动激活、单个虚拟器件的自动激活、组成解决方案的多个虚拟器件的协同激活。 下面将分别介绍这几种场景。 完全手动的激活适用于所有的虚拟器件,用户在虚拟器件内部读取OVF Environment文 件的内容,判断其中的配置项属于哪个软件,并根据自己的知识对该软件进行配置。显 然,这种场景对用户的要求较高,要求用户了解OVF Environment文件的格式,能够读懂 其中的内容,并具备对各种操作系统、中间件、应用软件进行配置的知识,即使用户具 备这些知识,但是由于配置过程非常复杂,也可能因为误操作或者系统异常终止而导致 激活失败。 6.1.2节中介绍的脚本技术可以简化激活的过程。脚本是由虚拟器件的创建者、发布者 编制的,在激活过程中,用户只需要调用配置脚本,并将OVF Environment文件中的配置信 息作为脚本的输入参数,就可以完成激活,用户不需要了解激活脚本的工作流程,因此也 不需要具备对各种软件产品进行配置的知识。不过这种方式对用户仍有一定的要求,一是 用户需要读懂OVF Environment文件的内容;二是用户需要了解激活脚本暴露的接口格式, 并将OVF Environment文件对应的内容传给脚本;三是用户需要了解并协调多个脚本的执行 过程,因为在激活中,多个软件的激活可能需要遵循一定的顺序。而下文介绍的自动化激 活问题,正是为了满足上面的几个要求。 一个典型的自动化激活单个虚拟器件的工具的工作原理如下:在虚拟器件启动过 程中,激活工具从虚拟磁盘中获取OVF Environment文件,根据激活的先后顺序读取OVF Environment文件中的参数,执行激活脚本,配置虚拟器件中的软件,在不需要用户干预的 情况下,得到定制化的可用的虚拟器件。这样的部署方式改进了传统的软件安装和部署方 式,免去了那些费时并且容易出错的部署步骤,比如编译、兼容性和优化配置,并且这种 192 云计算宝典——技术与实战 方式在虚拟资源池智能管理的支持下能够做到完全自动化,非常适合在虚拟化环境中对软 件和服务进行快速部署。目前,很多公司开发的虚拟器件都内置了简单的激活工具,例如 IBM Activation Engine作为一个自动化激活工具,在IBM公司发布的虚拟器件中得到了广泛 使用。 在6.1.2节中提到,多个虚拟器件会组合成一个解决方案,而在激活过程中,这些虚 拟器件可能有配置参数的依赖关系和激活顺序关系。通过在虚拟器件内部植入具备网络通 信功能的激活工具,可以统筹整个解决方案的激活过程,协作地完成解决方案的激活。当 然,这需要借助现有的OVF文件中定义的参数依赖关系及激活顺序。 6.3 管理虚拟化解决方案 数据中心的管理需要资源的自动化调度和与业务相关的智能。一个数据中心好比一 个交响乐队,每一个业务和它所占有的资源就好比一个乐手和他的乐器,乐手必须熟练 运用好乐器才能演奏出美妙动人的独奏。乐队里面有弦乐、管乐和打击乐三大声部,包 括数十乃至上百件乐器,如果不能很好地协调在一起,即使每个乐手都是世界一流的, 整个乐队演奏出来的也是毫无组织、杂乱无章的。因此,乐队需要一个指挥家,作为整 个乐队的灵魂,将乐队的各个部分组织起来,对各个声部进行有序的调度,形成一个整 体呈现给听众。同样,现代数据中心既需要单个业务能够自治管理,也需要一个负责全 局控制和协调的中心节点(Orchestrator)对数据中心的业务和资源进行统一监控、管理 和调度。 在传统的服务管理模式中,管理员需要登录若干个软件的控制台来获取信息、执行 操作,这种分别针对软件、硬件和系统的方式缺乏面向服务的统一视图。而采用虚拟器件 后,管理员可以通过虚拟化平台提供的管理功能来完成对虚拟机的管理工作,例如开关虚 拟机、调整虚拟机资源、执行实时迁移等,也可以通过虚拟器件内部嵌入的管理模块来管 理解决方案,如服务监控、服务开停控制、服务自动性能调优等。这两类管理操作都可以 被统一到集中式的管理平台中。 在虚拟化环境里面,不仅仅需要实时监测宿主机的电源和性能的变化,还需要了解 第6章 虚拟化管理 193 虚拟机CPU和内存的利用率,甚至是业务的访问量,这些信息对于资源管理和调度是至关 重要的。采集到这些信息以后,中心节点会根据应用特征选择最合适的调度算法,将这些 信息抽象成该算法的输入,计算出最优化的调度结果,之后按照调度结果对虚拟机进行调 度。除此之外,数据中心管理程序还需要考虑各种常规的管理操作,例如开关、配置等, 通过对流程的自动化来简化数据中心管理员的工作。 本节将介绍虚拟器件管理阶段的四类关键技术:集中监控、快捷管理、动态优化和高 效备份。 6.3.1 集中监控 虚拟化技术为数据中心带来先进的功能已是不争的事实。但是,由于引入了虚拟 化,对数据中心资源的管理和监控任务也随之增多。传统的数据中心大致分为硬件、操 作系统、中间件和应用四层。引入虚拟化以后,一台物理服务器上会运行多个虚拟机, 这使得硬件和操作系统之间又多了一个层次,数据中心需要管理维护的对象的数量和复 杂度也增加了。数据中心的管理平台中需要能够对虚拟化环境进行集中监控的技术,以 便更好地监控虚拟化环境中的资源及运行在虚拟器件上的解决方案。数据中心的管理平 台在监控方面必须做到以下两点:第一,能够集中监控数据中心的所有资源;第二,能 够集中监控所有虚拟器件上运行的解决方案的状态和流程。下面我们分别阐述这两点所 涉及的技术。 对所有资源集中监控,就是通过对采集到的数据进行分析、优化和分组,以图表等形 式,让管理员在单一界面对虚拟化环境中的计算资源、存储资源和网络资源的总量、使用 情况、性能和健康状况等信息有明确、量化的了解。比如,对于每个物理服务器,管理员 要能看到它的CPU和内存的使用情况、它上面运行的虚拟机数量,以及每个虚拟机的负载 情况、所占用的IP资源、带宽资源等。管理员还要能够监控各个物理机上的虚拟机的拓扑 结构图,以及虚拟机和物理服务器的位置关系等。 另外,通过资源集中监控,还能帮助管理员发现负载不均衡的情况,以及排除故障。 在集中监控方面,IBM的Systems Director通过Virtualization Manager扩展功能(如图6.11所 示),可以让管理员快速地查看数据中心的物理机、虚拟机、存储设备等资源的数量、健 康状况、逻辑关系等,另外还可以让管理员定制视图,从而进一步获得更详细的信息。 194 云计算宝典——技术与实战 图6.11 IBM Systems Director集中控制台 对虚拟器件上运行的解决方案的状态及流程进行集中监控,首先要能够让用户实时跟 踪这些解决方案在部署及运行期间的状态和流程的实时情况。虚拟化服务从被部署开始, 要经历多个状态,包括部署、激活、管理,直到最后生命周期结束而被销毁。虽然部署 与激活的流程可以根据用户的配置自动完成,但是仍要求有一个集中的可视化监控环境 为用户提供他们所关心的信息。如部署所采用的虚拟器件包、预留的物理资源、部署 (虚拟器件文件传输)的进度等。在激活过程中,这些信息包括解决方案的配置及激活 操作的结果等。 同样,当解决方案经过激活运行起来以后,管理员所关心的主要有解决方案的性能信 息,包括它所提供的服务的响应时间、吞吐量等,以及每个虚拟器件的运行状态,如 虚拟CPU、处理器和磁盘的使用率等。将这些信息以可视化的方式展现给管理员,他 们便可以有的放矢地对在数据中心中托管的虚拟器件及解决方案进行管理和调优。最 后,当虚拟器件完成了其任务并准备被销毁时,其销毁的过程及销毁后的状态也需要 进行监控,来帮助管理员完成对虚拟器件整个生命周期的管理,并保证所有的资源被 有效地回收。 6.3.2 快捷管理 在数据中心中,管理员或者管理程序下达的管理指令主要针对三种类型的实体:第一 类是基础设施,常规操作有开关物理机、配置网络等;第二类是虚拟机,常规操作有开关 虚拟机、调整虚拟机资源、迁移虚拟机、进行快照操作等;第三类是虚拟器件内的应用、 第6章 虚拟化管理 195 软件、解决方案,常规操作有开关软件、配置软件等。如何将这三类实体涉及的多种管理 操作简化、流程化、自动化,就是简化管理要解决的问题。具体来说,简化管理可以分为 物理机和虚拟机的简化管理,以及虚拟器件内部应用的简化管理两个问题。 对于虚拟器件内部的应用和解决方案,简化管理需要借助虚拟器件内部的管理模块, 这些管理模块既可以在创建虚拟器件时安装,也可以在虚拟器件部署以后由部署工具植入 进去。这些模块与数据中心管理程序中的简化管理模块协同工作,来完成大部分简化管理 的操作。 举例来说,一个典型的管理操作是启动一个虚拟化解决方案,如果对于6.1.2节中描述 的Trade应用,传统的数据中心管理员需要顺序执行以下操作:分别启动三个虚拟器件所在 的物理机,分别启动三个虚拟器件,启动DB2应用,启动WAS应用,启动IHS应用。这样需 要9步操作,同样,对于一个应用的关闭也要按相反的顺序执行9步操作。在采用了简化管 理技术之后,这个启动或关闭流程都通过元数据的方式描述并存储在管理程序中,管理程 序会解析元数据中的信息,并自动按序执行开关命令,管理员只需要发出开启或关闭应用 的一个指令。 对于物理机、虚拟机的简化管理,需要考虑的主要是能够与各种物理机、虚拟机平台 进行通信,发出指令。对于物理机的简化操作可以使用很多现有技术,因而虚拟机简化操 作成为这部分的重点研究方向。目前,为了支持在虚拟化平台上进行二次开发及第三方的 管理,主流的虚拟化供应商都适时推出了软件开发包(SDK)和开放编程接口(API)以满 足用户自身定制的需要。VMware和Xen目前都有比较成熟的开放编程接口,并被业界其他 厂商广泛调用。 但是,如果虚拟环境里面有多种虚拟化平台,每个虚拟化平台都有自己的软件开发 包,就会对统一管理带来很大的麻烦。因此,对于虚拟化平台的操作也应该标准化,比如 开关虚拟机、查看虚拟机状态和资源使用情况、调整虚拟机资源、对虚拟机进行实时迁移 等,如果这些操作在不同的虚拟化产品上有不同的实现和格式,用户使用将有很大的不 便。目前,业界正在开发一套支持多种虚拟化平台的通用API集合,功能包括:得到虚 拟机平台所在物理机的资源状况、开关虚拟机、监控虚拟机状态和资源使用情况、调 整虚拟机资源、进行虚拟机实时迁移等。用户通过访问这组API,可以进行与虚拟机、 虚拟化平台相关的大多数操作,而无须关心下层虚拟化平台的特殊性。 196 云计算宝典——技术与实战 6.3.3 动态优化 自虚拟化诞生以来,采用虚拟化技术的服务性能便一直是用户和相关研究人员关心的 重要问题。因为相对物理机,虚拟机的性能有少量的下降,尤其是I/O密集型应用的性能下 降会稍大一些。不过,经过大量的实践测试,只要在虚拟化环境中采用动态优化技术,并 且配合虚拟化带来的灵活性、资源抽象等优势,不仅可以完全弥补采用虚拟化可能带来的 性能下降,而且能为客户带来更多的好处。 动态资源优化技术研究的问题是:在虚拟化环境中,如何根据应用、服务负载的变化 为其所在的虚拟机及时、有效地分配虚拟化环境中的资源,保证既不会因为资源缺乏而影 响业务系统运行,也不会造成严重的资源浪费。为了使虚拟机的资源达到供求平衡,动态 资源优化技术需要了解和掌握各个应用、服务可能的负载量,根据一定的方法或规则推算 出其需要的物理资源类型及数量;在应用、服务运行中实时监测其性能数据,预测业务变 化的趋势,做出资源再分配的决策,然后进行相应的调整。 动态优化技术需要两只“眼睛”、一个“大脑”和两只“手”来协同工作。通过先看 后想再动手的方式完成每一个优化周期,通过定期优化来获得用户期望的性能和资源供求 的动态平衡。具体来说,一只“眼睛”从虚拟化平台的角度进行资源监测,了解虚拟环境 下有多少台服务器及它们的资源状态,包括CPU、内存、存储和网络等资源的总数量和剩 余数量;另一只“眼睛”从应用、服务的角度进行监测,了解在当前虚拟化环境中运行的 所有应用、服务的负载状况,以及相应的资源使用情况。这两只“眼睛”分别从供给面和 需求面对资源进行监测。 一只“手”做宏观调整,即通过打开或者关闭服务器,或利用实时迁移技术移动虚 拟机等,调整虚拟化环境中服务器的计算资源;另一只“手”做微观调整,负责调整某 个服务、应用所在的部分或全部虚拟机的计算资源,比如调整虚拟机的CPU数量和内存 使用量等。 所谓一个“大脑”就是具备性能分析预测、进行资源动态规划和输出调度结果的算 法,它协调着两只“眼睛”和两只“手”。在优化过程中,首先,它通过两只“眼睛”得 到虚拟化平台的计算资源使用情况、应用负载情况;然后根据当前情况并结合历史信息预 测应用未来的负载状况,根据预先定义的规则做出资源分配的决策,并进而输出资源调 度指令;最后,通过两只“手”来完成调度,资源分配变化不剧烈的时候只需要第二只 第6章 虚拟化管理 197 “手”做微观调整即可,而变化剧烈时需要用上第一只“手”。“大脑”是整个动态优化 技术的核心,大脑的智能程度决定了虚拟环境是否能有效地保证每时每刻都能向应用、服 务提供充足的计算资源。 动态优化的“大脑”可以采取多种成熟的调度算法,但本质上讲它们都是一种在决策 空间中的搜索算法。搜索算法可采用贪心算法、分而治之算法或启发式算法等。需要指出 的是,“大脑”需要考虑的主要因素包括:了解虚拟化解决方案负载的变化规律,实现预 动性的调整;了解虚拟化解决方案的服务级别协定(Service Level Agreement,SLA),尽 可能满足SLA的需求;合理设定资源池,使得虚拟机只在限定的范围内移动,简化优化复 杂度;尽可能将资源消耗互补的虚拟机放在同一台物理机上,使得物理机的资源能够得到 更充分的利用;尽可能将构成集群系统的若干台虚拟机放在不同的物理机上,使得物理机 发生故障时集群系统不会完全瘫痪;准备适量的后备资源,当出现突发事件时可以立即启 用后备资源,保证服务的正常运作。 目前,实现了动态优化技术的产品有:VMware的分布式资源调度器(DRS, Distributed Resource Scheduler),它已经集成在VMware虚拟化产品Virtual Infrastructure 3 内;PlateSpin的PowerRecon,它采用了新的组合编制模块,使得数据存储能够尽量的小; 微软也有望在其虚拟管理工具Virtual Machine Manager中推出类似的技术。 数据中心的动态资源调度在执行时所使用的核心技术是在第2章中介绍过的实时迁移 技术,它使得数据中心运行的业务具有很强的可伸缩性。由于数据中心的服务器性能不尽 相同,并且虚拟机所承载的业务在不同时间访问量也有变化,因此利用实时迁移技术可以 实现根据业务流量的变化实时调整虚拟机所占用的资源。下面将介绍目前各个虚拟化厂商 比较成熟的实时迁移技术。 在Xen平台下,虚拟机的启动方式可以是本地启动,也可以是网络启动。而Xen上面的 实时迁移技术的前提是虚拟机是通过网络方式启动的,即镜像被放置在共享存储上,而虚 拟机是运行在宿主机上的(使用该宿主机的CPU和内存),宿主机上的虚拟机管理程序利 用NFS或者其他网络存储方式获得镜像上的数据。经过简单的配置,虚拟机就可以实时迁 移到另外一台宿主机上。迁移的过程对用户来讲是透明的,迁移后虚拟机使用新宿主机的 计算资源,而文件系统所在的镜像仍然在共享存储上。 VMware VMotion是VMware公司开发的实时迁移功能,该功能包含在VMware企业级产 198 云计算宝典——技术与实战 品VMware Infrastructure中。VMotion和Xen的实时迁移技术原理上十分相似。不同之处在于 VMware公司开发了一个文件系统VMFS,这种集群式文件系统允许多个VMware ESX服务器 同时访问虚拟机的镜像,因此在迁移过程中无须移动镜像,只需要将虚拟机内存中的状态 和上下文通过高速网络从源ESX宿主机传输到目标ESX宿主机。 小型机和大型机环境下的虚拟化同样提供了功能强大的实时迁移功能。在IBM POWER6架构下的System P570服务器基础上,IBM公司推出了实时分区迁移(Live Partition Mobility,LPM)技术和共享的专用容量技术。实时分区迁移可以将用户正在使用和运行的 分区从一台POWER6服务器迁移到另一台POWER6服务器,期间无须停止任何应用程序, 这样能够帮助客户避免因计划中的系统维护和工作负载管理而造成应用程序中断。 6.3.4 高效备份 在传统的数据中心中,数据备份技术已经相当成熟。如果需要对数据进行短期备份, 可以利用磁盘;如果是长期备份,则需要用到磁带库。现有的备份机制和相关软件已经发 展到可以支持存储区域网络、光纤和系统升级的功能。各个厂商也都推出了自己的存储管 理解决方案,并各具优点。 在越来越多的企业开始采用虚拟化技术的情况下,如何对虚拟化数据中心的数据进行 备份成为一个重大挑战。由于以下几个原因,传统的数据备份技术已经不能满足虚拟化平 台下的需求。 (1)大量具备高度相似的内容的虚拟机镜像并存。在传统的情况下,文件系统和服 务器之间的关系是一对一的,但是引入虚拟化以后,一台服务器上面可能运行多个虚拟 机,而每个虚拟机都有独立的文件系统作为支撑。 (2)有些虚拟化平台为了构建存储集群,采用了私有的文件系统格式,比如VMware ESX独有的文件系统VMFS。这要求数据备份软件能够识别私有的文件系统,并且有访问权 限,这就增加了数据备份的复杂性。 (3)如果企业的数据中心采用了多种虚拟化平台,那么数据备份时还需要处理虚拟 平台的异构性和多样性。 (4)多个虚拟器件才能承载一个解决方案。在企业的数据中心里面,由单一服务器 第6章 虚拟化管理 199 承载单一解决方案的情况越来越少,人们看到更多的是由多个虚拟器件组成一个解决方案 交付给终端用户。这样,解决方案和虚拟器件的对应关系是一对多的,而多个虚拟器件可 能分布在多个虚拟化平台上。在这种情况下,传统的备份策略和方法很难奏效。 (5)虚拟机可以实时迁移,从文件系统的数据备份角度来讲,很难跟踪到底虚拟机 运行在哪台物理服务器上。这些挑战都对数据备份一致性提出了更高的要求。 针对虚拟化对数据备份提出的挑战,人们对备份策略和技术做出了相应调整,主流的 备份机制有如下两种。 (1)虚拟机上备份。这种方法沿袭了传统的备份方法,认为虚拟机是一个普通的服 务器,只需要在它上面安装和物理服务器上一样的备份代理软件,与传统的备份服务器通 信,并执行由备份服务器发出的备份策略和指令。这个解决方案的优点在于它的实施过程 和传统的物理服务器备份一样,最大限度地兼容了传统的备份机制,减少了为升级备份而 投入的初期成本。很多企业出于这方面的考虑,也乐于采用这种备份方案。其缺点在于备 份冗余度过高,增加了后期存储备份数据设备的开销。造成这种情况的原因是,在虚拟机 管理器上进行的备份中,它上面虚拟机的文件系统作为普通二进制文件做了一次备份,而 虚拟机作为普通服务器,又对自己的文件系统做了一次备份。时间一长,后期存储所需的 开销将会增加,而且由于进行了重复备份,备份时间也相对较长。不过,有些数据备份厂 商已经意识到了这个问题,具有识别并删除重复数据功能的备份软件已经问世,它能够大 量地减少备份量,从而节省备份时间。 第二种是虚拟机外备份。与第一种方案不同,这个方案是在虚拟机外部实现对虚拟机 的数据备份,它充分利用了虚拟机管理器提供的备份应用接口,从而简化数据备份和数据 恢复的工作,并且减少了备份过程中对其他虚拟机的影响,大大提高了备份效率。其实, 这里提到的备份应用接口就是指虚拟机快照技术,虚拟机快照技术不仅能够针对虚拟机文 件系统进行快速备份,而且能将备份粒度降低到文件系统中的某个具体文件。有了虚拟机 管理器提供的备份接口,虚拟机外备份方案只需要关心上层的备份策略,而不用和虚拟化 平台特定的文件系统打交道。它的主要备份策略是设置虚拟机的还原点,通过逻辑单元号 (Logic Unit Number,LUN)或者磁盘驱动器中指定的位置来存储所需的备份。另外,系统 管理员还可以通过快速查询逻辑单元号对应的虚拟机,提高恢复虚拟机的响应速度。对于 删除重复数据这一项功能,虽然在虚拟机上备份解决方案中不常应用,但是在虚拟机外备 份解决方案中却属于常见功能。备份软件能够先将多次出现的相同数据识别出来,并将冗 200 云计算宝典——技术与实战 余数据删除,仅存档一份数据。 在实际的生产环境中,很多数据中心所使用的备份解决方案并没有我们上面阐述得那 么明确,而是在这两种解决方案中各取所长,可按照用户的实际需要选择恰当的技术。例 如,持续数据保护技术就是利用了前面提到的两种解决方案,采用了增量备份的策略对虚 拟化数据中心进行持续、增量的数据备份,从而缩短备份所需时间,并减少存储所需的空 间。 具体来说,在初始化的时候,该系统对数据中心所有的物理服务器和虚拟机服务器进 行一次扫描,然后进行一次初始化备份,这一次备份的时间较长。之后,数据保护系统按 照备份策略对服务器进行再次扫描,如果发现服务器的文件发生了变化,该系统会对它进 行增量备份,并且记录好时间戳。这样,一旦出现任何问题,持续数据保护系统都可以将 状态平滑地回滚到出问题以前某一个进行过数据备份的时刻。增量备份只需要很少的系统 开销,几乎不会影响到服务器上运行的应用和服务。 6.4 小结 本章以虚拟器件生命周期的三个阶段为主线,介绍了服务器虚拟化的关键技术。在虚 拟器件创建阶段,讨论了构成服务器虚拟化的虚拟镜像和虚拟器件的概念及创建、组装、 发布的流程和关键技术。另外,还阐述了这方面的业界标准,对虚拟器件镜像文件进行管 理的关键技术,以及将运行在物理服务器上的传统服务迁移到虚拟机中的P2V技术。在虚 拟器件部署阶段,首先探讨了在数据中心构建虚拟化环境需要考虑的问题和相关的虚拟化 产品,然后描述了部署虚拟器件的主要流程、提高部署效率的关键技术,以及激活的关键 技术。在虚拟器件的运行期间,为了方便管理员集中管理,以及提高应用的性能,从集中 监控、快捷管理、动态优化、高效备份四个方面讨论了相应的关键技术。 平台即服务 9.1 概述 9.2 核心系统 9.3 扩展系统 9.4 参考实现 9.5 小结 第 9 章 第9章 平台即服务 255 云计算系统架构的平台层是为应用服务提供开发、运行和管控环境,即中间件功能的 层次。基础设施层所要解决的是IT资源的虚拟化和自动化管理问题,而平台层需要解决的 问题是为某一类应用提供一致、易用而且自动的运行管理平台及相关的通用服务。在云计 算系统架构中平台层位于基础设施层与应用层之间,为应用提供共享的、按需使用的服务 和能力。 平台层的功能以服务的形式提供给用户,可以作为应用开发测试和运行管理的环境,即 平台即服务(Platform as a Service,PaaS)。平台即服务是云计算平台层的外在表现形式,是 云计算平台提供的一类重要的功能集合。本章将首先阐述平台即服务设计所满足的基本需求 和所支持的基本应用类型,从而对PaaS的功能特征有清晰了解;然后介绍实现PaaS系统的重 要技术,它们是针对PaaS的功能和使用方式而专门设计的。当前被广泛认可的云平台服务主 要针对两类应用形式,一类是Web服务,通过快速的请求/响应方式进行交互(称为事务处理 类),另一类是数据分析服务,通常处理大量的数据,需要较长的处理时间和巨大的数据空 间(称为数据分析类)。最后,本章将通过实例来剖析面向这两类应用的PaaS实现要点。 9.1 概述 与Internet的TCP/IP架构相类比,云平台层类似于网络和传输控制层的地位。即在多层 的架构中,需要一个层次来屏蔽下层物理设备的多样性,又要支持上层应用的多样性。平 台层即通过一系列的面向应用需求的基本服务和功能来提供应用运行管理的基础,而它本 身也屏蔽了基础设施层的多样性,可运行在多样的基础设施层之上。对于大规模不断演化 的系统而言,这样的架构选择具有普遍性,它既提供了一定的稳定性从而成为支持演化的 内核,又通过模块和层次化为各个子模块的独立演化提供了支持。 9.1.1 驱动力 平台即服务作为云计算中的一类重要服务类型,它的出现有其深刻的商业和技术背 景。从商业的角度讲,随着各类网络应用和服务的发展,其规模和复杂度都有了质的变 化。这使得应用的快速开发、部署及管理的简化和自动化成为一件必要的事情。从技术的 256 云计算宝典——技术与实战 角度讲,计算基础设施的发展和虚拟化技术的广泛应用使得集中式的、统一的应用运行和 管理平台成为可能。 在过去的10年里,运行在企业内部和互联网上的应用,无论是复杂度、类型还是规 模都呈现出显著的增长。随着软硬件技术的进步,IT用户的业务运作方式也有了很大的变 化,企业愈发依赖高效的IT系统和各类应用来支撑其业务。为此,企业必须寻求新的IT系 统及应用运作方式,以降低在软硬件的采购和维护、管理方面的大量成本投入。同时,随 着企业业务的发展和创新,快速开发和上线新业务和应用也是保证企业竞争力的重要手 段。企业应用的多样性和灵活性,以及对于应用的高可用性和可靠性的要求,促使企业寻 求新的应用开发和运行方式。平台即服务给企业在这方面的需求带来了高效的解决方案。 在云计算的架构中,基础设施层通过基于共享和虚拟化的服务来提供计算能力、存储 能力和网络能力。共享和服务的概念也可以适用到应用上,也就是为应用的开发、运行和 管理提供统一的环境和平台,这类似于将中间件的概念推广到了云计算的架构中。回顾分 布式计算的发展历程,我们看到中间件技术的出现,主要是为了将分布式应用所共同面对 的诸如事务管理、资源管理、多线程及进程间通信等通用性的问题及其具体实现抽象为简 单应用编程接口或系统服务,以简化应用的开发和管理。 同样,在云计算的大框架下,平台即服务提供了进一步的抽象。我们通过对云应用进 行分类,总结相关实践中的共性问题,抽象出特定的模式和解决方案。这些共性的部分, 包括负载均衡、缓存、半结构化的数据存取、大规模的消息通信等。将这些共性的部分剥 离出来,由专业的人士进行开发,通过服务的方式提供给应用使用且由专业人士维护,这 样使得它们的功能、性能和成本都较企业自己独立完成更好、更省。因此,在中间件的基 础上进一步简化应用的开发和管理而提供一组服务,即平台即服务,可以提高应用的灵活 性,降低运行管理的开销。 PaaS包括一系列的平台软件和基本服务。PaaS的提供商在平台软件和基础服务的实现 上具有多样性,各自针对用户对平台的一类或几类特定需求和使用方式。根据所针对的应 用类型,PaaS在理念、客户定位和实现方式上也会存在差异。比如,GAE(Google App Engine)就预先定义了所支持应用的基本模型,以应用编程接口(API)的方式与应用进 行交互,应用通过调用相应的编程接口来调用平台层的功能,从而实现应用的功能和运 行管理。 第9章 平台即服务 257 通常的企业客户维护着大量现存的应用。企业可以考虑把这些应用迁移到云计算平 台层上,或者保持维护现有应用,而把新的应用运行在云计算的平台层上。对于前一种选 择,企业需要考虑向云计算平台进行迁移转型的成本;而对于后一种选择,企业需要考虑 做到两类系统的有效集成。云计算平台的提供商需要考虑如何有效地平衡用户的这两个方 面的需求。这两类需求将影响到平台层的功能、实现方式和推广模式。PaaS技术的发展将 会更加贴近客户的多样化需求。 9.1.2 主流类型 当我们开发各种各样基于网络的应用时,通常会把这些应用中共有的部分或者都要使 用到的功能抽离出来作为基础服务,以供编写和运行应用时调用,从而降低应用创建和运 维的复杂性。这一系列应用所要用到的基本功能即为平台层所提供的服务。 当前,PaaS上运行的应用主要分为两类,一类是Web服务,另一类是数据分析服务。 前一类主要是通过浏览器访问、采用请求/响应模式进行交互的应用,称为事务处理类应 用。事务处理应用的要求主要包括快速响应、高可用性、大并发量等。后一类应用主要是 对大量的数据进行分析处理,称为数据分析应用。数据分析应用的主要要求包括强大的计 算能力和存储能力,对于实时性的要求不高,数据处理完毕后任务就结束运行了。为了支 持这两类应用,PaaS系统根据应用特点而有专门的设计,这将在9.3节有细致的介绍。 根据所针对的应用类型,PaaS通过编程模型和接口与应用进行交互。关于所支持的编 程模型,PaaS可以基于标准编程模型,也可以基于自定义编程标准。基于标准编程模型可 以降低用户的使用门槛,并且使得已有的应用系统更容易迁移到云平台上,比如在Google App Engine中,可以直接使用J2EE模型进行Web编程。某些PaaS为了更好地解决云计算中 的某类特殊问题而采用了自定义的编程模型,比如force.com为了更好地支持多租户技术而 自己定义了Apex编程模型。对于数据分析类应用,PaaS通常支持MapReduce模型。 作为支持某种类型应用的通用基础功能的集合,平台即服务的类型及其功能也会随着 应用的发展而变化。例如,支持大规模网络游戏的基础平台、支持社交网络的平台,或者 面向大规模数据存取操作的半结构化数据存储和非关系型数据查询平台,都可能或者正在 发展形成新型的PaaS类型。可以预见,随着市场规模的扩大和市场细分的深化,PaaS的种 类及提供PaaS的厂商将会不断增加。这些都会进一步丰富云应用的类型和开发实现方式。 258 云计算宝典——技术与实战 9.1.3 功能角色 从平台层所处的架构层次和所针对的用户需求来看,PaaS的本质是以共享和基础服 务的方式来满足多样性应用运行管理过程中的共性需求。因此,从用户需求的不同角度来 看,PaaS也展现出不同的面貌特征:从架构层次来看,它是共享的中间件平台;从功能特 征来看,它是集成的软件和服务平台;从使用模式来看,它又是虚拟的应用平台。 共享的中间件平台:从架构层次上来看,平台层是为了有效支撑大量应用实例的运行 管理,它是一类应用运行所需要的资源和服务集中起来并进行共享的中间件平台。在传统 的中间件环境中,考虑应用的性能和可靠性,通常用户需要为每个应用维护一套单独的环 境,除了硬件平台之外,还需要有单独的运营团队来进行中间件的选型、部署和配置等。 另外,为了保证应用的可靠性及突发的负载,往往需要准备额外的软硬件资源。 如图9.1所示,PaaS将这种传统的静态、独享的中间件平台转变为一种动态、共享的中 间件平台。每个应用将在云平台上统一进行管理和运行。平台层既提高了资源的利用率, 又通过对应用和平台进行概念和功能的分离进一步简化了应用和平台的运营和管理。 PaaS将“共享”扩展到更大的范围。与基础设施层所共享的对象不同,PaaS所共享的 对象是应用运行所需的资源和基础功能。PaaS通过动态资源调度实现了计算资源在不同应 用之间的共享和按需供给;通过基础服务如流量平衡器、专门的消息服务机制实现了不同 应用之间的基础功能;通过统一的管理平台实现应用运维管理的功能和方法的共享。 图9.1 PaaS作为扩展的中间件提供应用所需的资源和共享的基础功能 集成的软件和服务平台:从功能特征的角度来看,平台层整合各种不同的软硬件资源 向应用提供一致而统一的资源和功能。通过整合,应用运行所需的各种资源和基础功能以 第9章 平台即服务 259 统一的编程模型和调用接口暴露给应用使用,应用无须关注下层的细节。同时,PaaS平台 根据所支持的应用类型,可以精心选择和优化所提供给应用的资源和服务,使得应用的开 发和运行变得更为简单高效。 如图9.2所示,平台即服务可能建立在多个基础设施服务之上,需要对应用提供一个一 致的、单一的基础设施视图。PaaS还需要面向云环境中的应用提供应用在开发、测试和运 行过程中所需的基础服务。平台层除了提供Web服务器、应用服务器、消息服务器等传统 的中间件以外,还需要提供其他相关的管理支撑服务如应用部署、应用性能管理、使用计 量和计费等。另外,云应用本身可能就集成来自不同云服务提供商所提供的功能或服务, 这些也需要平台层提供相关的支持。 比如,一个企业可能将自己的应用运行在企业内部所建设的PaaS上,将客户信息保存 在企业内部的数据库里,将一些非敏感信息如产品手册和图片等文件直接放到Amazon S3 (简单存储服务)中以节省存储服务器的采购成本;为了方便与客户交流,该应用甚至可 能直接集成Microsoft的Live服务。为了支持应用这些功能需求,PaaS应该提供一致的访问接 口和编程模型,从而使得应用通过简单的接口调用就获得相应的功能,而无须单独与各自 的服务分布打交道。例如,上层应用通过PaaS所提供的统一接口来对本PaaS内部的数据和 存储在S3中的数据进行透明访问。 图9.2 位于IaaS之上的PaaS面向应用整合了各种软硬件资源 虚拟的应用平台:从使用模式上看来,作为应用运行管理的环境,PaaS模糊了物理 资源的限制,在应用看来是一个按需索取、无限可扩的虚拟平台。PaaS作为云应用的运行 环境,云应用通过PaaS所提供的编程接口(API)按需获取运行所需要的各种(虚拟的) 资源和能力。一般来讲,资源的获取是动态即时的。例如,平台层根据应用程序的负载起 伏,动态估计所需的计算和存储资源,按照服务质量的约定(SLA)按需提供所需资源。 260 云计算宝典——技术与实战 从自动化的角度来看,PaaS的基本目标是使应用更加专注在用户的功能性需求上,而平台 则自动为应用满足诸如负载均衡、自动规模调整等非功能性的需求及管理的需要。 在传统的应用开发中,用户需要花费大量时间和工作来进行软件栈(即中间件)的选 型、定制和部署。在PaaS上,这部分工作将由PaaS根据应用的需求和特点自动完成。我们 可以看到,在Google App Engine和force.com这样的PaaS上,用户不再需要手动地选择自己所 需要的Web容器和数据库产品及选择和扩展所需的管理功能。用户更多地是针对应用的特 点,对诸如运行时服务质量(QoS)需求、伸缩策略或者部署方式等应用的参数进行指定 和配置,平台层可以根据应用的相关配置自动提供支撑应用的软硬件资源,以及在运行时 进行自动的负载平衡、伸缩控制和SLA优化等。 总之,PaaS针对的是有效而自动管理大量应用的需求。PaaS的功能和结构设计要满足 这样的需求。下面我们将从功能和技术的角度来看平台层如何满足这样的需求。 9.2 核心系统 一个平台一般来讲也只能对某类应用进行高效、方便的支持。在当前的IT实践中,存 在大量不同类型的应用,因此,从用户的观点来看,PaaS与PaaS之间也存在巨大的不同。 然而,在实现PaaS的过程中,我们也会发现,PaaS作为一个系统,其中的功能和模块大致 分为两类,首先是PaaS的核心系统,包含了PaaS的一系列本质特征,即使是在不同的PaaS 中,也会有这些特征的实现;其次是PaaS的扩展系统,主要包含了针对其支持的应用类 型的支持,比如GAE作为支持事务型Web应用的PaaS,就包含了数据访问和缓存的相应模 块。本节就讨论通用的核心系统。 9.2.1 简化的应用开发和部署模型 对于一个IT应用的要求,一般分为两个方面:一方面是与业务相关的功能性需求;另 一方面就是诸如安全性、可靠性及服务质量等非功能性的需求。应用的开发阶段主要考虑 功能性要求,而运行阶段主要关注非功能要求。不同的应用在非功能性要求方面具有一定 的相似性,为了支持这些非功能性要求,人们通常总结出一定的功能模块和模式。比如, 第9章 平台即服务 261 在不同Web 2.0应用的高性能方案中,我们一般都能发现诸如负载均衡、反向代理及数据缓存 等相似模块。这些模块和模式是平台层支持应用运行的基本方式。平台层的一个重要目标就 是把业界在过去多年来在分布式应用中获得的经验总结起来作为服务提供给用户,使用户能 够将更多的精力放到与业务相关的功能性需求上去。 前面提到,平台层的基本目的是为了进一步简化大量应用的开发、部署和运行管理。 在平台层,为了实现简化应用开发和部署的目的,应用一般被定义为功能性模块和一系列 策略的组合。在进行应用开发的时候,开发人员只需考虑业务功能的实现;而非功能性要 求通过选择所提供的策略配置来表达。平台层在应用具体部署时根据这些策略选择自动提 供相应的资源、服务功能及其配置。 我们可以通过一个关于数据高可用性的例子(如图9.3所示)来看平台层给用户所带来 的便利。假设用户A和用户B都需要CRM的应用,用户A需要很高的数据可用性,而用户B 则不太关心这个问题。开发人员只需要进行一次开发就能满足这两个企业的功能性需求, 而应用管理人员则只需要在部署的时候根据业务的需求选择配置策略,云平台会自动为它 们产生不同的部署和配置。比如,在本例中,用户A的高可用性需求通过主从方式的商业 数据库来满足,而用户B的数据可用性配置为开源数据库的定期备份。 图9.3 云平台中,应用的开发和部署体现了功能性和非功能性要求的分离 一般来说,传统的中间件已经有功能性和非功能性要求满足的分离。在云计算平台 层,这种分离变得更为彻底。例如,应用管理无须考虑应用的容量需求而仅需配置所需的 服务性能策略;应用所需资源是自动按需供给的,而无须预先准备好;应用所需策略的实 262 云计算宝典——技术与实战 现可以随着时间推移而不断改进,但应用无须感知策略实现的内部变化。总之,这种分离 使得应用的开发更加简单,而应用的运行更为自动化。 9.2.2 自动的资源获取和应用激活 为支持应用的运行,平台层需要为应用分配相应的资源,包括计算资源、网络资源和 存储资源。建立在基础设施层上的平台层可以通过调用基础设施层的功能和接口获得相应 的资源并分配给相应的应用,也可以直接实现基础设施管理的功能,而无须抽象出单独的 基础设施层。平台层对应用所需资源的管理分为两个方面:在应用部署上线的时候所需初 始资源的分配,以及应用运行过程中根据性能要求进行动态的资源调整。两者所采用的方 式有所区别。前一种方式根据应用的初始配置元数据而决定资源的种类和数量;后一种方 式根据应用的运行负载变动和性能目标采用动态的模型计算所需的资源种类和数量。 前面提到,提交给云平台的应用以功能模块加上非功能性策略进行定义。云平台层首先 根据应用的这两方面的需求计算出支持这个应用所需要的资源类型、配置模式和相应的数量, 比如:虚拟机数量及其CPU、内存配置,以及所需要的各类中间件、功能软件、网络连接和存 储空间等。简单来说就是为应用创建虚拟的服务器,包括服务器上的软件栈和相应的配置。 当为应用配置好运行所需要的各类资源之后,平台层还需要进行激活操作,让应用确 实运行起来并正常提供所应有的功能。应用的激活涉及所分配基础设施层的资源的配置和 激活、平台层的功能和服务的配置与激活,以及应用层的功能和配置的启动。平台层所做 的激活工作主要包括: 首先需要完成的是资源之间的依赖关系的解析和支持。在定义应用的时候,不会也不 需要考虑支持应用的下层资源和基础服务的关系和结构,以及提供这些资源和服务实例的 具体配置。应用所涉及的各功能模块之间一般通过一系列的逻辑关系来进行连接。平台层 在激活应用的时候需要将应用的各功能模块之间的这种逻辑连接与具体的实现实例的细节 和配置相关联。比如,平台层上的应用在定义的时候指定功能模块A与功能模块B分别访问 不同的数据库,以逻辑名数据源A和数据源B来进行标示。在资源分配过程中,平台层将数 据源A和数据源B分别实例化为不同的虚拟机和数据库。在应用激活的过程中,平台层针对 功能模块A和B分别进行配置,应用服务器与数据库服务器之间将使用不同的数据连接实 例,使用不同的数据源IP和名字等。 第9章 平台即服务 263 在应用的部署过程中,可能涉及应用模型没有指定但实例化的时候必须存在的功能模 块,如一个应用服务器从单个变为多个时需要在前端添加负载均衡器,或者数据高可用性 配置中需要多个数据库实例并配置为主从关系。这些根据应用部署情景而即时添加的模块 是应用激活所需关注的。 除了解析并实现资源之间的依赖关系外,在应用能够正式运行之前,还需要对资源进 行一系列的配置和初始化工作。一般来讲,在资源分配阶段所建立的软件栈中,各软件资 源都只包含默认的配置。而不同的应用则需要对这些软件进行配置的更改,比如针对应用 的不同性能需求配置不同大小的连接池,或者指定不同的缓存失效时间等。另外,平台层 还需要对某些软件资源进行一系列的初始化工作,比如,在数据库服务器实例上为应用创 建相应的数据库和表格,或者从其他用户指定的数据源导入数据等。 平台层的一个基本特点是资源分配和应用激活的自动化操作。应用管理员在提交对应 的应用并指明所需的配置策略后,平台层能够自动解析应用的配置,转化为对应的资源分 配和配置选项,并且通过调用基础设施层的接口实现资源分配,通过其自身或者应用所提 供的配置工具实现应用从(虚拟)服务器到中间件直到应用自身的配置和启动。 9.2.3 自动的应用运行管理 在传统的中间件环境中,需要专门的应用运营管理团队针对应用进行部署、配置和 运维管理。具体的实施则是一个比较长的过程,需要选择数据中心,规划网络连接,购买 服务器,安装操作系统和中间件,根据应用的需求进行配置等。如果应用的需求发生了变 化,无论是应用升级还是根据性能要求等非功能性需求更改应用的部署和配置,都需要有 一个繁复的计划和实施过程。由于这个过程涉及软硬件多个层次的内容,因此需要具有软 硬件环境的大量专业技能和知识。应用的运维管理是企业IT支出中非常重要的一部分,许 多企业需要设置专门的团队来负责这项任务。因此,简化应用的运维管理是从应用在线运 行角度对PaaS提出的基本要求。 实际上,从应用的角度来讲,企业关注的是应用的功能及应用是否正常运行。为了 保障应用的正常运行,企业需要负责管理好应用运行的整个软硬件环境。而PaaS则提供了 应用运行环境和应用自身的分离;应用运行所需的资源、基础服务和管理操作都可以交由 PaaS平台来负责,甚至通过一系列技术实现自动化操作。在PaaS平台上,企业仅需关心应 264 云计算宝典——技术与实战 用的功能,监控应用的运行是否达到要求,而无须关心如何准备好各种资源和条件来使运 行正常运行,后者由PaaS平台来照管。 为了实现以应用为中心的管理模式,PaaS展现给用户的是以应用为中心的逻辑视图, 即展示应用逻辑层次上的功能模块,以及通过属性和策略所表达的非功能性约束。用户在 应用的逻辑视图上进行应用的管理,比如监视应用的性能、更改应用的属性和策略等。 PaaS平台则动态地调整应用所需的资源和管理策略,以保证达到应用管理人员设定的对应 用的性能及其他方面的要求。以应用为中心的管理方式是PaaS简化应用管理的基本思路。 我们在上一节就已经看到,用户的非功能性需求通过逻辑性的策略表达,消除了用户对特 定中间件的技能需求,也进一步简化了应用的部署和管理工作,降低了成本。 可以通过对于应用运行时的可靠性和伸缩性进行比较来体现PaaS相较于传统的中间件 环境中管理方式的优势。在传统的中间件环境中,为了保证可靠性和伸缩性,除了需要在 部署阶段进行支持(比如,数据库的主从配置),也需要在运行时付出大量人力。一般来 讲,在传统的中间件环境中,应用的运行状态,比如中间件实例的数量,每个实例的具体 配置,对于管理员来说都是可见的。管理员需要随时监视应用(及中间件)的运行状态,人 工判断是否存在节点失效或者负载过高等情况,一旦异常发生,管理员根据事先制定好的工 作流程来启动备用的服务器,运行相应的管理脚本来对新的服务器进行配置和初始化等。在 这个过程当中,一般都会对应用产生或多或少的影响,比如系统的扩容一般会停机维护。 在PaaS平台中,这一系列工作则由PaaS自动完成,用户在部署应用的时候只需要指定 相应的可靠性和自动伸缩策略,PaaS平台会自动跟踪和管理应用的运行状态,并调整资源 供给来满足策略要求。比如,当Web服务器负载过高时,PaaS平台会从基础设施层申请新 的虚拟机运行Web服务器形成新的实例,根据应用的属性进行相应的配置等。这些动态的 变化在应用的逻辑视图上对管理员来说可以是完全透明的。 除了向应用管理人员提供应用的逻辑视图,PaaS还通过在逻辑视图上加载适当的管理 操作接口从而形成一致的集成管理视图。集成的管理视图既展示了应用的运行信息,又展 示了管理人员可以使用的管理操作,使得以应用为中心的管理更为直观而简化。一方面, 管理人员可以在同一个管理控制台中获取来自不同层面的管理信息;另一方面,这些应用 运行信息通过以应用为中心的方式展现出来,比如,整个应用的并发请求数量或者平均响 应时间等,而不是某个具体的中间件实例的负载状况。在传统的中间件环境中,管理员直 接使用不同的中间件和系统管理工具,对每个中间件实例及对应的运行环境进行直接的管 第9章 平台即服务 265 理,往往是一个手动使用分散的管理工具及人力介入进行决策的过程。在PaaS平台中,管 理人员可以将精力集中在与应用相关的监控和管理上。 实际运行中,PaaS会搜集基础设施层和平台层上原始的各类运行状态信息,比如每个 虚拟机的CPU和内存使用状况,或者每个中间件实例的运行状态,每一个应用的访问量和 消息服务响应时间等。PaaS对这些原始信息进行一系列的处理,以便实现以应用为中心进 行数据的展示,同时根据这些数据和应用的配置策略进行相应的资源调整操作。当PaaS平 台运行在不同的基础设施层上时,这些基础设施层的差异也会被PaaS屏蔽,以便展示给应 用管理人员一致的应用运行管理视图。 在传统的中间件环境中,策略的实施往往是针对某类资源单独进行,比如网络的配 置,或者某类中间件的设置等。PaaS平台将提供更加灵活的策略组合和集成的策略实施。 根据应用的运行动态,PaaS可以实时调整提供给应用的各类资源。比如,在高负载的情况 下,为保证应用响应时间,一般需要在应用服务器和数据之间配置缓存查询数据,而这类 缓存往往会提高应用运行的成本。因此,管理人员可以配置PaaS按照应用性能和当前访问 量自动启动或者停止类似的数据缓存服务,以降低应用运行的成本。 9.2.4 平台级优化 在PaaS中,优化在两个层次上进行:在应用层次,针对应用的性能和配置策略,PaaS 动态调整应用所使用的资源,在保证达到应用要求的前提下尽量提高资源的使用率,降低 应用的运行费用;在PaaS平台层次上,在保证各个应用的运行要求下,PaaS通过资源的共 享和复用从而降低平台的运行开销,提高运行效率。可以看出,这两个层次的优化在目 标、范围、手段和实施者等方面是各不相同的。 将应用运行在PaaS平台上,应用的所有者不再拥有单独的软硬件平台,针对软硬件 平台的优化工作也需要由PaaS来进行。在传统的环境中,往往需要有经验的管理员通过大 量的分析和观测工作才能形成合理的优化方案,实施优化也需要大量的工作量和时间。在 PaaS平台上,这一系列工作被简化了,PaaS可以自动发现优化的模式,可以通过虚拟化的 能力自动、快速实施,而不影响到应用的运行。 同时,PaaS平台执行优化工作时,也需要调用所依赖的层次,如基础设施层的功能和 服务来完成。PaaS平台可以根据应用的策略及运行情况来自动进行跨层次(平台层与基础 266 云计算宝典——技术与实战 设施层)的优化和调整。例如,PaaS可以根据应用的不同组件之间的消息传递情况,将通 信量高的组件通过迁移技术逐渐调整到物理上靠近的位置,甚至同一台物理机器上,以提 高I/O效率。PaaS可以根据基础设施层所提供的资源性能和价格差异,从而将应用部署或调 整到相应的资源上,以便优化应用的运行性能和成本。 PaaS平台上运行着大量的应用,由于规模和自动化的要求,其上的优化也将面临着大 量的挑战。这是未来大规模分布式系统研究和实践的重要方面。 9.3 扩展系统 上一节从商业和技术发展的角度来看PaaS的发展动力和所扮演的重要功能。总结来 说,PaaS就是面向应用提供集成的、共享的应用开发和运行环境及一组服务。为了支撑大 量的应用运行实例,这样的环境将应用所需的基础功能抽离出来作为基础服务通过编程模 型和接口暴露给应用调用。 PaaS环境暴露给应用的基础功能既应满足应用的需要,又要考虑大量应用实例共享这 些基础功能所带来的压力。因此,合理的基础功能抽象及有效的设计和实现来满足应用对 这些基础功能的需求,将成为一个PaaS平台成功的关键。PaaS平台借鉴了传统中间件中的 一系列技术,如流量平衡、消息通信、缓存管理、容错和错误恢复等,同时PaaS也创新了 一系列新的技术,如非关系型数据存取、大规模消息通信、自动伸缩机制等,从而提高应 用运行管理的有效性和自动化程度。 针对两类当前广泛支持的PaaS应用,即事务处理和数据分析,本节选取几项关键技术 来介绍它们如何支持和简化了对应的应用并实现规模要求,这些技术包括非关系型数据存 取、大规模消息通信、海量数据分析等。PaaS采用的技术来自于大规模分布式系统方面的 进展,也推动着这方面技术的发展。希望通过本节的介绍让读者能够进一步从技术角度把 握云平台层的特征和能力。 9.3.1 非关系型数据存取 大量应用都涉及通过数据库进行数据的存取。通常采用的数据库是关系型数据库如 第9章 平台即服务 267 Oracle、DB2等。随着网络应用的发展,数据类型也丰富起来,如图片、文本甚至多媒体数 据等。这些数据的存取采用需要固定表结构的关系数据库进行读取效率不高。当前,人们 已经认识到非关系型(NoSQL)数据存储不需要固定的表结构,通常也不存在连接操作, 在大数据存取上具备关系型数据库无法比拟的性能优势。 为了支持多样数据的存储服务的高可用性和可扩展性,非关系型数据库的架构通常 比较复杂,而且具体实现也不尽相同。我们分析了几种主流的非关系型数据库,从应用接 口、数据管理、节点管理三个方面总结了它们的具体实现中的关键之处。 9.3.1.1 非关系型数据库的应用接口 应用接口是非关系型数据库提供给用户的编程接口,通过该接口用户可以访问非关 系型数据库的数据存储服务。相对传统的关系数据库而言,非关系型数据库的应用接口有 两个特点:简单和灵活。对于普通用户而言,非关系型数据库只提供几个简单而有限的接 口:存储,获取和删除,而且这些接口都是通过键(key)来操作的。所谓灵活,是指在允 许的数据大小范围内,用户可以存储任意格式的数据。 在非关系型数据库中,数据操作接口与关系型数据不同。存储操作代替了传统数 据库的插入和更改操作,它需要用户至少提供键及所对应的数据项。例如,在Cassandra 里,它的存储数据项是以行为粒度进行操作的。Cassandra的存储操作为insert(table, key, rowMutation)。这里的table是键值空间,key是数据项的键,rowMutatable是行粒度的数据 项,该行可以包括多个列值。另外,在某些实现中,比如Dynamo,存储操作还会要求提供 一些上下文对象,这些上下文对象包含了存储数据项的版本信息和所在节点信息,这些信 息对于数据管理非常重要。获取操作通过键及其他相关信息来获得对应的数据项,返回给 用户使用。在非关系型数据库中,考虑到应用的特殊需求,删除操作通常并不是物理上删 除数据项,而是将该数据项标识为已删除,有些非关系型数据库甚至不提供删除操作。 一般而言,应用接口的通信协议有两种: HTTP和Protocol Buffers。HTTP方式可以 承载XML和JSON这些用户可读的数据和信息,而Protocol Buffers将结构数据序列化传 输,然后在接收端将其反序列化。由于序列化的数据更小,从而实现快速传输,提高 系统效率。这两种方式都是与平台和语言无关的。 9.3.1.2 非关系型数据库的数据管理 通常,非关系型数据库是一个分布式系统,它所存储的数据项分布在各个节点上。 268 云计算宝典——技术与实战 该系统的数据管理需要保证数据读写的高可用性,其关键技术涵盖了分区、数据复制和读 写、数据版本管理等几个方面。 分区是保证非关系型数据库可扩展的基础,它涉及数据和节点的管理。目前,大多数 非关系型数据库的分区都是通过一致性哈希来实现的。所谓一致性哈希,是将哈希函数所 有的哈希值构成了一个首尾相接的环(最大值和最小值相接),组成非关系型数据库的每 个节点在环上随机选择一个哈希值,将该环分割成N份(N为节点数目)。在选取哈希函数 时,要尽可能将节点均匀分布在哈希环上。同样地,需要存储的数据项也通过该哈希函数 将自己映射到哈希环的某个节点上。于是,负责存储的节点和需要存储的数据项都映射在 了同一个哈希环上,并且某个数据项由从它的哈希值出发沿哈希环顺时针方向遇到的第一 个节点负责存储。 如图9.4所示,哈希环的取值空间为0~232,组成该系统的4个节点均匀分布在哈希环 上,哈希值落在(节点1,节点2]之间的数据项由节点2负责存储,哈希值落在(节点2,节点 3]之间的数据项由节点3负责,哈希值落在(节点3,节点4]之间的数据项由节点4负责,哈希 值落在(节点4,节点1]之间的数据项由节点1负责。通过这样的分区方式,数据存储的任务 被均匀分摊到各个节点上。 图9.4 采用一致性哈希来管理数据 不过,在实际应用中,哈希函数并不能完全实现均匀分配,从而造成某些范围内的 第9章 平台即服务 269 数据项过多、分区不平衡的情况。目前,有两种主流的方法解决这一问题:增加新节点或 采用虚拟节点。增加新节点是将负载过重的范围拆分,让一部分负载分配到新增节点上, Cassandra就是采用的这种方法;采用虚拟节点是将整个哈希环细分成若干小范围,每个虚 拟节点负责一个小范围,每个节点负责若干个虚拟节点的存储,对于负载较重的节点,可以 将它的部分虚拟节点重新分配到其他负载较轻的节点上,Dynamo和Riak就采用了该方法。总 之,分区是实现分布式存储的基础,数据管理和节点管理的其他部分都与它有关联。 数据复制是指通过在多个节点上进行数据冗余备份来提高数据的可用性和可靠性,一 般数据复制所要求的节点数N为大于等于3。从前面的分区部分我们了解到,某个数据项 是由从它的哈希值出发沿哈希环顺时针方向遇到的第一个节点负责存储的,那么其他节点 如何选取呢?目前的基本思想是继续沿哈希环顺时针方向选择节点,以达到备份所需的要 求。不过,如果所选取的节点都位于同一个机架上,在该机架整体失效的情况下,系统的 可靠性将大为削弱。因此,在选择节点的时候还要考虑节点的物理位置,如在不同的机架 上,甚至要分布在不同的数据中心。 前面提到,非关系数据库为了提高读写效率,在写数据项时,并不一定需要在N个节 点上成功写入以后才返回,即W(成功写入的节点数)<= N(数据复制的节点数);同 样,在读数据项时,也不需要在N个节点上成功读取以后才返回,即R(成功读取的节点 数)<= N。根据分布式系统的Quorum理论,可以证明在W+R > N的情况下,系统能够保证 强一致性,而W+R <= N的情况下能够实现最终一致性,也就是说需要牺牲同步时间来换取 快速的读或写。 由于每个数据项保存在多个节点上,客户端在每次更新该数据项时,成功写入的节点 (W)并不一定完全相同,并且小于数据复制的节点数(N),这就造成了数据版本不一 致的问题。向量时钟(Vector Clock)是解决这个问题的经典方法,也被广泛应用在流行的 分布式非关系型数据库中,比如Cassandra,Dynamo和Riak。通过时钟向量,节点给每个数 据项标记版本信息,客户端每次更新数据,相应的版本信息就递增,各个节点之间通过版 本信息来解决冲突和实现合并,从而达到数据一致性。 如图9.5所示,同一个数据项存储在三个节点上,在a时刻节点1上的数据更新了,版本 信息标记为(1,0,0);在e时刻节点3上的数据更新了,版本信息标记为(0,0,1); 在b时刻,节点1上的数据再次进行了更新,变为(2,0,0);然后,节点1上更新的数据 传播到了节点2上,这个不是由客户端发起的数据更新不改变版本信息;在c时刻,节点2 270 云计算宝典——技术与实战 上的数据被客户端更新了,版本信息变为(2,1,0);在d时刻再次被更新,变为(2, 2,0);接着,节点2上更新的数据传播到了节点3上,这时,节点3上有两个版本(0, 0,1)和(2,2,0),需要由上层应用或既定规则处理版本冲突,生成(2,2,1);在 f时刻,节点3上的数据再次被更新,版本信息变为(2,2,2);接着该版本传播到节点1 上,覆盖掉原来的(2,0,0);在g时刻,数据版本更新为(3,2,2)。通过这样的方 式进行同步和更新,达到节点之间的数据一致性。 图9.5 数据一致性示例 9.3.1.3 非关系型数据库的数据节点管理 目前,大多数非关系型数据库是由多个地位平等的节点组成的,这些节点通过网络连接 在一起。为了保证整个系统健康运行及存储数据的一致性,节点管理是必不可少的。下面介 绍节点管理的一些主要方面:消息通信、失效检测及处理、节点添加与删除、持久化存储。 为了实现节点管理,节点间的消息通信是必不可少的。在分布式的环境下,如何能 够有效地实现通信呢?解决这个问题的基本方法仍然是一个经典方法——Gossip协议,不 过不同的实现对它进行了改进。在这里只是介绍一下它的基本概念。Gossip协议的思想源 自于自然界中的病毒传播模式,在分布式环境下,每个节点都维护了状态信息及相应的版 本,这些状态信息包括了用于判断节点是否存活的心跳信息、用于记录节点负载的信息, 以及分区信息等。所有节点都会每隔一段时间随机选取一个节点进行通信,比较两个节点 的状态信息,从而更新过时信息。通过这样的方法,在节点数为N的系统中,达到同步所 需要的时间在log(N)数量级,满足了弱一致性前提下的要求。 有了Gossip协议作为分布式环境下节点通信的基础,失效检测就能很好地解决了。不 过,判定失效也有多种实现。在Dynamo的实现中,如果某个节点(假设为节点3)在一定 第9章 平台即服务 271 时间内没有响应同步信息,发起同步信息的节点(假设为节点1)便认为该节点失效。在 Cassandra中,判定节点失效采用了另外一种方法——基于疑似度的检测(Accrual Failure Detection),其基本思想是在分布式环境下,由于网络丢包或负载原因,判断一个节点是 否失效不能简单地裁定为是或否,而是通过一个值(也就是疑似度)来判断。在一定的时 间窗口内,如果节点未能响应同步消息一次,那么它的疑似度就增加一分,相反,误判几 率就小一些,达到某个阈值后,系统就确定它失效了。 当然,节点失效有可能是暂时的,也可能是永久的,这两种失效的处理方法有所不同。 在节点3失效的这段时间内,节点1会定期尝试连接它,并且所有发往节点3的数据更新操作 都会暂时转发到其他的节点上保存。如果和节点3的通信恢复,那么更新的数据将同步到节 点3上,从而避免了节点或网络的暂时失效对整个系统的可用性造成的影响,这个技术也被 称为“提示移交”(Hinted Handoff)。如果确定节点3永久失效了,则需要人工将其从分区 中删除,并且重新分配曾经由节点3负责存储的数据,相关节点还需进行数据同步。 为了实现快速地实现数据不一致检测,非关系型数据库常常采用Merkle Tree算法。简单来 说,每个节点都维护了一个Merkle Tree,这颗树的叶子节点是它所负责的分区的哈希值,树上 其他节点都是其子节点的哈希值再取哈希值。在比较数据是否一致时,只需要查看两个负责 相同分区的节点比较它们Merkle Tree根节点的值是否一致,如果不一致,再查找子节点,如果 Merkle Tree的节点数为N,那么最多采用log(N)的时间就能够找到数据不一致的分区。 如图9.6所示,节点1和节点2具有相同的分区范围,通过比较它们Merkle Tree的根节 点,发现哈希值不同,然后最终发现分区3的数据在两个节点上不一致。 图9.6 通过Merkle Tree来比较数据一致性 272 云计算宝典——技术与实战 当系统负载过重时,需要添加新的节点来分担负载,当某个节点发生不可恢复的错误 时,需要将该节点从系统中移除,这些都会引起整个系统的分区发生相应的变化。一个新 节点的加入需要完成如下几步: (1)启动前的配置; (2)启动自举; (3)提供服务。 在第一步中,节点需要选择对应的哈希值,既可以是人为指定节点,也可以是通过哈 希函数产生的,另外,为了和其他节点进行通信,它还需要知道系统中部分节点的信息, 我们将这些节点称为种子(Seed),这些主要配置工作完成以后就可以启动节点了。在 第(2)步自举过程中,新节点将自己的位置(哈希值)及分区信息告诉种子节点,种子 节点发现这是一个新的节点,然后这样的信息在节点间通过Gossip协议传播,经过一段时 间,系统中的所有节点都认识了该新节点。另外,由于它的加入,分区发生了变化,以前 由其他节点负责存储的范围划归为新节点负责,因此数据将从这些节点转移到新节点上, 在该过程中新节点不会对客户端负责数据更新,直到数据转移完成。自举完成以后,所有 节点的信息都更新了,新节点也可以提供服务了。 为了可靠地存储数据,节点需要将数据存储在持久化层中。每个非关系型存储系统 采用的方法也不尽相同,比如BigTable就利用了Google File System,Dynamo利用了Berkeley DB,而Cassandra就依赖于本地的文件系统。另外,几乎所有系统都通过提交日志(commit log)的方式在持久层记录对数据的操作,如果节点进程意外崩溃,新起的进程可以根据这 些日志对数据进行重新操作,从而很快恢复正常工作。 9.3.2 大规模消息通信 云计算的一个核心理念就是资源和软件功能都是以服务的形式进行发布的,不同 服务之间经常需要通过消息通信进行协作。可靠、安全、高性能的通信基础设施对于 云计算的成功至关重要。通常,消息通信可以分为同步通信和异步通信两种方式,如 图9.7所示。 第9章 平台即服务 273 图9.7 同步消息通信和异步消息通信 在同步消息通信中,客户端任务直接请求服务器端的服务,并等待服务结果返回后才 继续执行;在服务器端,服务的运行环境则需要保存与客户端通信的信息,在处理完成时 将结果返回给客户端。这种同步消息通信机制有可能对客户端系统的处理速度和服务器端 系统的可用性造成影响: 首先,客户端系统因为需要同步等待而无法并发处理任务; 其次,同步通信机制造成服务器端的系统资源长时间被占用,服务实例也由于需 要与远程客户端通信而无法在任务处理完成时立即处理下一个任务; 另外,同步消息通信会降低服务的可用性,因为在分布式环境中,客户端所请求的服 务实例有可能因为各种原因而不可用,从而造成客户端请求无法得到处理。因此,异步消 息通信对于云计算环境就显得尤为重要。 在异步消息通信中,客户端和服务器端并不直接通信。客户端把请求以消息的形式放 在请求消息队列里面,然后继续处理其他业务逻辑;服务实例则会从请求消息队列中获取 请求消息,并且将处理结果放入响应消息队列里面,然后立即处理下一个请求。消息通信管 理软件通过判断消息请求是否成功发给目标服务实例,来判断该实例是否可用,并且在目标 服务实例不可用的情况下将消息发给其他服务实例,从而为客户端提供高可用的服务。 异步消息通信机制已经经过了多年的发展。早在1995年就有人提出了基于生产者/消 费者模型的分布式消息队列方案,并且能够根据分析模型考量和预测消息队列的性能。 Java Message Service(JMS)是J2EE平台上的一个消息通信标准,J2EE应用程序可以通过 JMS来创建、发送、接收和阅读消息。Apache ActiveMQ是JMS的一个开源实现版本,IBM 274 云计算宝典——技术与实战 WebSphere MQ则是实现了JMS的一个商业产品,并且通过一系列的增强特性提高了JMS消 息通信的性能和可管理性。异步消息通信已经成为面向服务架构中组件解耦合及业务集成 的重要技术。 面向服务的理念使得异步消息通信对云计算更加重要。异步消息通信机制可以使得 云计算每个层次中的内部组件之间及各个层次之间解耦合,并且保证云计算服务的高可用 性。异步消息通信机制对于服务的可伸缩性也非常重要,消息队列管理软件可以通过队列 中的消息数量和消息请求的服务类型预测每种服务的工作负载变化趋势,并且通过该趋势 自动增加和减少服务实例。 云计算也给分布式系统中的消息通信带来了新的挑战。首先,消息通信服务必须 足够稳定,以保证在应用程序需要使用消息服务的时候该服务一定是可用的,并且保 证消息在互联网传输过程中不会丢失。一旦消息传送出现问题,需要有技术能够保存消 息,并不断重试传送,等待故障被修复后再次进行通信,这样就需要有消息的保存机制、 冗余备份机制、副本同步机制等。 其次,消息通信服务必须能够伸缩,从而支持大规模节点同时执行高性能的消息读写 操作,为此必须要支持多种方式的消息读写模式,如边读边写、边读边发送、边写边发送 等。云计算的安全问题一直以来备受关注,因此消息通信服务还要保证消息的传递是安全 的,从而保证业务是安全的。 此外,紧凑、高效的消息内容模型对提高消息处理效率非常重要,这在云计算这样的 大规模消息通信处理环境中体现得尤为明显。云中的消息通信还要能够支持各种各样的消 息格式,兼容多样的消息长度,因为使用云的用户并不局限于某一领域或者某一平台。 9.3.3 海量数据分析 以互联网为计算平台的云计算,将会更广泛地涉及海量数据处理任务。海量数据处理 指的是对大规模数据的计算和分析,通常数据的规模可以达到TB甚至PB级别。在互联网时 代,互联网数据的统计和分析很多是海量数据级别的,一个典型的例子就是搜索引擎。由 于数据量非常大,一台计算机不可能满足海量数据处理的性能和可靠性等方面的要求。以 往对于海量数据处理的研究通常是基于某种并行计算模型和计算机集群系统。并行计算模 型可以支持高吞吐量的分布式批处理计算任务和海量数据,计算机集群系统则在通过互联 第9章 平台即服务 275 网连接的机器集群上建立一个可扩展的可靠的计算环境。 在互联网时代,由于海量数据处理操作非常频繁,很多研究者在从事支持海量数据处 理的编程模型方面的研究。例如,Remzi等人在1999年设计了River编程模型,开发人员可 以基于该编程模型开发和执行计算任务。River编程模型的设计目的就是使得基于大规模计 算机集群的编程和计算更加容易并且获得极佳的计算性能。River编程模型有两个核心设计 特性:高性能的分布式队列和一个存储冗余机制。因此,River需要对磁盘和网络的数据传 输进行非常精心的调度。 当今世界最流行的海量数据处理的编程模型可以说是由Google公司的Jeffrey Dean等人 所设计的MapReduce编程模型。MapReduce编程模型将一个任务分成很多更细粒度的子任 务,这些子任务能够在空闲的处理节点之间调度,使得处理速度越快的节点处理越多的任 务,从而避免处理速度慢的节点延长整个任务的完成时间。下面我们将介绍MapReduce框 架的工作原理和设计原则,从而加深读者对海量数据处理系统的理解。 MapReduce框架从Lisp及很多其他类似的语言获得灵感,研究人员发现大多数分布式 运算可以抽象为Map和Reduce两个步骤,从而实现可靠、高效的分布式应用。Map步骤负 责根据输入的key/value(键/值)对生成中间结果,中间结果同样采用key/value对的形式。 Reduce步骤则将所有的中间结果根据key进行合并,然后生成最终结果。开发者只需要实现 Map和Reduce函数的逻辑,然后提交给MapReduce运行环境,计算任务便会在由大量计算 机组成的集群上被自动、并行地调度执行。运行环境负责将输入数据进行分割、调度任 务、自动处理运行过程中的机器失效,以及协调不同节点之间的数据通信。图9.8描绘 了Jeffrey Dean等人所设计的MapReduce框架的基本工作流程。 MapReduce的运行环境由两种不同类型的节点组成:Master和Worker。Worker负责数据 处理,Master负责任务调度及不同节点之间的数据共享。具体执行流程如下。 (1)利用MapReduce提供的库将输入数据切分为M份,每份的大小为16~64MB,然 后在计算机集群上启动程序。 (2)Master节点的程序负责为所有Worker节点分配子任务,其中包括M个Map子任务 和R个Reduce子任务。Master负责找出空闲的节点并分配子任务。 (3)获得Map子任务的Worker节点读入对应的输入数据,从输入数据中解析key/value 对,并调用用户编写的Map函数。Map函数的中间结果缓存在内存中并周期性地写入本地 276 云计算宝典——技术与实战 磁盘。写入本地磁盘的数据根据用户指定的划分函数被分为R个数据区。这些中间结果的 位置被发送Master节点。Master节点继续将这些数据信息发给负责Reduce任务的Worker节点 进行Reduce处理。 (4)执行Reduce子任务的Worker节点从Master节点获取子任务后,使用远程调用的方式从 执行Map任务的Worker节点的本地磁盘读取数据到缓存。执行Reduce子任务的Worker节点首先 遍历所有的中间结果,然后按照关键字进行排序。 (5)执行Reduce子任务的Worker节点遍历获得Map子任务产生的中间数据,将每个不 同的key和value进行结合并传递给用户的Reduce函数。Reduce函数的结果被写入到一个最 终的输出文件。当所有的Map子任务和Reduce子任务完成后,Master节点将R份Reduce结果 返回给用户程序。用户程序可以将这些执行Reduce子任务的Worker节点生成的结果数据合 并得到最终结果。 在设计MapReduce的时候,研究人员考虑了很多大规模分布式计算机集群进行海量数 据处理时所要考虑的关键问题:容错处理保证了在Master和Worker都失效的情况下计算任 务仍然能够正确执行;操作本地化保证了在网络等资源有限的情况下,最大程度地将计算 任务在本地执行;任务划分的粒度使得任务能够更加优化地被分解和并行执行;对于每个 未完成的子任务,Master节点都会启动一个备份子任务同时执行,无论初始任务还是备份 子任务处理完成,该子任务都会立即被标记为完成状态,通过备份任务机制可以有效避免 因个别节点处理速度过慢而延误整个任务的处理速度。MapReduce工作原理如图9.8所示。 当然,MapReduce的原语设计也会导致性能问题。美国加州大学伯克利分校最近发表 的一篇针对MapReduce的论文认为,如果将MapReduce作为一种通用的数据处理框架,它相 对于MySQL提供的数据处理操作,还缺少一个叫Merge的原语。因此该论文提出了一种叫做 Map-Reduce-Merge的改良计算模型,意图通过提供Merge原语来提高MapReduce的效率。从 MapReduce算法的流程来看,Reduce操作需要等大部分Map操作完成才能够继续,如果Map 操作耗费非常长的时间,那么Reduce操作会一直等待。在某些情况下,采用MapReduce比 集中的数据处理并不会快多少,出现这种情况的原因可能是计算的分布不均匀,或者某些 Map节点的计算能力远远低于其他Map节点。此外,由于MapReduce运行在分布式系统上, 系统中的节点通过网络进行连接,因此在MapReduce运行过程中需要大量的网络消息通 信,比如一个MapReduce计算环境中有M个Map节点和N个Reduce节点,那么可能的通信链 路就有M×N条,这些链路上的数据交换会给网络带来大量的负载。目前大部分数据中心的 第9章 平台即服务 277 网络架构还是基于共享带宽、中心交换和路由的,而不是理想的点对点连接方式,因此较高 的负载会带来额外的通信开销,甚至影响到其他节点之间通信的性能和可用性。以上这些问 题,都是采用MapReduce框架,或者实现MapReduce技术的系统需要考虑的技术挑战。 图9.8 MapReduce工作原理 另外,分布式系统常用的分布式存储在云计算环境中面临着更严重的性能问题。相 对于原有的本地存储、集中存储或者网络存储,云计算分布式大规模存储面对的是一个网 络不可控的环境。对于典型的MapReduce加上分布式存储的云计算场景,每一个Map或者 Reduce计算节点都需要从分布式存储中读取或者保存数据,由于计算网络与存储网络是分 别搭建的,绝大多数情况下计算所需要的数据存取操作都不会发生在计算节点的本地,而 是被分发到分布式存储网络的其他节点上。在最坏的情况下,一个计算节点及其对应的存 储节点可能分别处在地球的两端,这会导致严重的性能问题。解决这个问题的方法之一是 对数据安全性、可用性和数据同步要求不高且数据量比较小的应用采用本地文件系统,对 规模比较大的应用采用可以位置感知的网络存储系统,这样就可以缓解上述性能问题。 大规模数据处理的另一类新技术被称为流计算(Stream Computing)。传统的计算或 者数据处理的步骤是:首先收集数据,然后将数据储存起来,储存方式可能有数据库、文 件等,然后对储存好的数据进行计算处理,将计算结果返回或者输出。这种计算模式,在 现在的海量数据情况下遇到了挑战: 278 云计算宝典——技术与实战 (1)数据量非常大,目前互联网时代的数据不止是文本数据,而绝大多数是图像、音 频、视频等,将这些数据进行存储就是很大的问题,针对海量数据进行计算也是很大的问题; (2)用户对于计算速度的要求越来越高,比如天气预报、金融分析、市场预测等等 应用,要求数据计算产生结果的速度尽量快; (3)大量数据是实时生成的,比如用户的使用日志、交通流量实时监测、证券实时 报价等,对这些数据进行分析计算的结果,很多时候都需要实时可用,而如果等待存储— 计算—输出的过程,则无法满足需求。 流计算是正式应对这些挑战的一项新兴技术。流计算的计算模式为:数据实时地进行 输入,不需要强调存储过程,实时计算,实时输出。流计算将计算过程转化成一个流程图 的形式,每一个计算模块负责流程中的一个步骤,通过网络连接将这些模块串接成一个反 映整个计算过程的图,图的起始端就是用户输入的数据,而图的终止端就是计算输出的结 果。流计算着重在“实时”上,以此来解决上文提到的传统计算和数据处理面临的挑战。 目前,流计算还在研发阶段,需要研究对不同类型数据的处理方式、处理性能、硬 件架构、软件支持等问题,同时也需要业界逐渐接受这种新兴的计算模式。目前,IBM、 Google、NVidia等公司都在进行流计算的研发,并推出了一些产品,例如IBM的System S。 9.4 参考实现 当前,运行在PaaS上的应用主要有两类:一类是Web服务,一类是数据分析服务。前 者指通过浏览器访问的采用请求/响应模式进行交互的应用。这类应用长时间运行着,要求 保障响应时间、高可用性等。后者指对大量数据进行的分析处理。这类应用需要大型的计 算能力和存储能力,对于实时性的要求不高,数据处理完毕后就结束运行。 市场上针对这两类应用的PaaS服务也有很多,如针对Web应用有Google Apple Engine (GAE), Microsoft Azure;针对数据分析主要是基于MapReduce计算模式的数据分析平 台,如Hadoop平台和Amazon的基于Hadoop的Elastic MapReduce服务等。本节将分别介绍面 向这两类应用的PaaS平台结构和功能,以让读者对于PaaS的机制有更深入的理解。 第9章 平台即服务 279 9.4.1 事务处理类 在当前的云计算实践中,基于互联网所提供的公共服务平台,比如GAE等,已经得到 了相当的认可和应用。但是在企业环境中,普遍的做法还是局限于通过采用IaaS相关的技 术对基础的计算资源进行虚拟,而很少将企业的应用运行在PaaS上。究其原因,主要还是 在于类似GAE这样的系统由于采用了新的编程模型和接口,现存的企业应用无法直接运行 在这类PaaS上,需要重新进行投入进行软件的开发和迁移。除去这些额外开销所带来的经 济因素之外,对这些已经稳定运行的应用进行重新开发也会带来额外的风险。这里提供一 个面向企业的PaaS实现,这个实现实际上是IBM的企业级PaaS产品的一个原型版本。除了 向大家展示一个事务型PaaS的基础组成部分之外,其设计目标主要有两点:首先是通过虚 拟化和共享简化企业应用的管理,降低企业的运营成本;其次是提供一个对现有企业应用 兼容的PaaS平台,使当前存在的企业应用能够直接迁移到这个平台上。 9.4.1.1 系统概述 作为一个支持传统Java EE应用的平台,一般来讲,其架构中需要包含如图9.9所示的 几个部分。其中每个部分的主要功能简单描述如下: 图9.9 事务处理类PaaS系统架构 1. 应用管理子系统 此子系统提供了对运行在平台上的应用的管理工具和服务。在用户使用PaaS的过程 中,平台需要提供相应的工具对应用进行部署、管理和监控。由于运行在PaaS上的应用程 序的多样性,一般来讲,PaaS会制定相应的UI框架和规范,根据用户的需求和应用所提供 的一系列原数据来自动生成相应的用户界面。另外,除了针对每个应用的管理之外,系统 管理员也需要对PaaS 本身进行管理,比如配置应用的缺省策略和中间件模版,监视平台中 各项资源的总体使用情况等。 280 云计算宝典——技术与实战 2. 平台存储仓库 PaaS中需要一个全局的数据仓库用来存储平台用于管理自身及支撑应用的各种数据。 比如,平台本身的核心程序,运行应用所需要的元数据和程序文件,以及各种中间件程序 和原始的虚拟机映像等。除此之外,平台存储仓库也可以用于应用运行时的各项系统信息 的存储,比如应用当前所占用的资源信息、管理所需要的系统日志等。 3. IaaS适配层 PaaS一般建立在IaaS之上,按需从底层的IaaS申请原始的计算资源。现在市场上存在 不同的IaaS产品,虽然它们所提供的资源类型基本一致,但是其提供资源的方式和接口有 很大区别。企业一般会根据自己的需要独立(于PaaS)地选择IaaS产品,为了最大程度地 适应企业环境,企业级PaaS一般需要通过额外的IaaS适应层来为平台及其中的应用屏蔽掉 IaaS环境的细节。 4. 核心服务 这里包含了PaaS运行所需要的所有关键功能的集合。比如为应用进行分配对应的计算资 源,构造虚拟机上的软件栈等。PaaS的其他模块通过访问核心服务来实现相应的管理功能。 5. 应用程序运行时 包含了应用在运行时的所有相关的软硬件资源,即虚拟机、包含了中间件和PaaS管理 应用所需要的一系列程序的软件栈等。与传统的概念不同,PaaS中的应用程序运行时是根 据用户的需求和应用运行时状态动态改变的分布式系统,包含了负载均衡、防火墙等用户 不可见的服务程序。 9.4.1.2 关键概念 与基于传统的中间件的企业应用模式不同,PaaS中应用的部署和管理的方式和概念都 有了很大变化。这里列出其中一些主要的部分。 1. 应用模型 企业应用的需求一般分为功能性的需求和非功能性需求,比如可扩展性、响应时间 等。在传统的中间件环境中,开发团队一般专注于程序的功能性需求进行开发。一般存在 第9章 平台即服务 281 一个专门的运营团队根据应用的非功能性需求,选择相应的硬件及各种软件产品,确定软 硬件具体的配置等。在应用上线之前,运营团队制定相应的部署和后期的管理计划。随着企 业应用规模的扩大,运营上的开销已经成为企业IT支出的一大部分。在以往的实践中,我们 可以发现,大部分满足非功能性需求的解决方案实质上都是大同小异的,比如,通过负载均 衡器来实现自动的扩展性,通过主从方式的配置来解决可靠性问题等。在PaaS中,通过将这 些解决方案总结为对应的模式,交由平台来自动实现,可以降低对运营团队的需求。 将非功能性需求提取出来使得开发和部署应用的复杂度和所需要的专业技能大大减 少。用户只需要根据应用的功能性需求开发完成,然后通过PaaS所提供的建模工具以策略 的形式指定应用的非功能性需求。PaaS在部署应用的时候,会自动实现支撑这些需求所需 要的物理结构(即虚拟机及其中运行的软件栈)。同时,在应用运行的时候,PaaS会根据 应用的运行时状态,动态调整这些支撑结构,以满足这些需求。 2. 软件栈 不同的应用所使用的中间件类型往往有一定差别,即使某些应用用到相同的中间件程 序,其中的配置也往往差别很大。在传统的环境中,构造支撑不同应用所需要的软件栈往 往是一项非常繁重的劳动。在应用需要扩展的时候,管理员很难向应用中迅速提供带有解 决问题的软件栈的节点。PaaS需要能够自动根据应用的需求,动态获得计算资源(即虚拟 机),在其中安装应用所需要的一系列软件程序。 在我们的示例系统中,中间件按照其功能,以插件的形式在虚拟机上进行组织。中间 件程序作为插件,以模版的方式存储在平台存储仓库中。PaaS中存在一个关于软件栈的插 件框架,根据每个虚拟机的任务按需从仓库中下载模版,然后实例化插入到框架中,以形 成本机的中间件环境。这样的方式有如下几个好处,首先,不同应用之间,同一应用的不 同虚拟机之间,都需要不同的中间件环境,插件的方式简化了中间件程序的安装;另外, 应用往往不需要一个完整的中间件服务器。通过将中间件按照插件进行组织,能够进一步 按照应用的要求提高资源的使用率。 3. 资源组织 前面已经提到过,PaaS实际上可以看成是应用相关的软硬件资源及其他服务的集成平 台。这些资源和服务来自不同的层次甚至其他的服务提供商。PaaS需要提供给用户一个一 致的、统一的视图以完成对这些资源和服务的监控。换句话说,PaaS需要提供给用户针对 282 云计算宝典——技术与实战 应用及其部署的一个逻辑模型来对应用进行管理。在这个模型中包含了每个应用所用到的 资源,屏蔽了诸如应用的拓扑、虚拟机数量等动态物理信息。 在我们的示例系统中,用一种面向资源的方式来实现这个目的。应用中所用到的各种 (需要管理的)资源首先被分类,每类资源都通过插件的方式定义和实现了这类资源所支 持的一系列属性、监控指标及操作。PaaS为每个应用自动生成所用到的所有资源的一个统 一的界面,用户通过这个界面来对这些资源进行管理,每个管理操作会自动地被PaaS转发 到相关的资源实例上。用户不需要考虑资源的定位和相应管理功能的调用等问题。 9.4.1.3 实现细节 前面两节介绍了本示例系统的基本结构和概念,本节进一步讨论本系统的一些实现细 节,以展示PaaS的一些内部工作机制。 1. 应用实例化和激活 在用户完成应用的开发之后,需要本示例系统所提供的工具对应用的部署进行建模, 即指定应用的功能性模块和相关的非功能性策略。这实际上是提供了针对应用的、与底层 物理实现无关的逻辑视图。在应用能够部署到物理机或虚拟机上运行之前,需要针对这个 逻辑视图建立起相应的物理视图。物理视图包含为应用分配多少虚拟机,每个虚拟机需要 安装哪些软件等内容。这就是应用实例化的过程。 在实例化完成之后,应用还需要有一个激活过程,即修改软件的配置以适应应用运行 时的动态信息。比如:在物理视图中,无法提前获知虚拟机通过动态地址分配所获得的IP 地址信息,因此,在物理视图中,只能包含应用服务器和数据库服务器之间的逻辑连接信 息,在应用能够正常工作之前,需要对相关服务器上的软件配置进行更改,使应用服务器 能够获知数据库服务器的IP地址以正确地进行访问。 2. 代理框架 前面提到,本示例系统通过IaaS 适配接口来获取原始的计算能力,即虚拟机。在获取 虚拟机之后,这个时候的虚拟机,往往只有一个最基础的操作系统,需要根据应用对这个 虚拟机的要求,从平台存储仓库中下载所需要的各类软件程序。另外,在应用运行的过程 中,用户及平台本身都会对应用进行监控,发出指令到虚拟机,调用对应软件(或资源) 的管理功能。这些功能在本示例系统中由一个代理框架来负责。 第9章 平台即服务 283 本示例系统中,每个虚拟机都会运行有一个平台所提供的代理程序。这个代理程序除 了定期向平台的管理系统报告自身的状态之外,也会接收平台所发来的控制指令,比如: 下载某个资源安装到本地,或者重新启动某个中间件程序等。一个应用的所有(虚拟机上 的)代理会构建一个对等网络来进行代理之间的通信,在本地维护一个关于应用的统一的 物理视图。另外,每个应用的代理会通过分布式的选举算法,选出一个(应用范围内的) 主代理,作为应用系统控制消息的入口和分布式操作的协调者。 3. 资源配置和调用 PaaS一个重要特性就是使用户能够通过应用的逻辑视图进行管理,而不需要关心应 用运行过程当中物理结构的变化,比如由于自动伸缩和可靠性策略所导致的虚拟机的创 建和删除等。比如:用户有时候需要提高应用服务的性能,在PaaS中,他只需要在管理 界面上更改应用逻辑视图中的应用服务器的性能级别,PaaS将会自动地将这个级别转换 为中间件的新的属性(比如缓存和堆大小等)配置到所有的应用服务器实例之上,即使 系统今后为这个应用分配新的应用服务器实例,也将直接使用更新之后的属性对新的实 例进行配置。 本示例系统中所有插件都会有相应的元数据来指明每个逻辑模型中的对象及中间件程 序都支持哪些属性和行为。PaaS会自动生成相应的界面提供给用户。同时,PaaS还会自动 地将逻辑属性和行为转换为相应的中间件程序的配置和行为,通过PaaS所提供的分布式执 行引擎在每个中间件实例上进行配置和执行。同时,PaaS也会在应用程序范围内保证应用 的逻辑模型的一致性,即在新创建的中间件实例上应用最新的配置。 综上所述,我们叙述了本示例系统的重要设计原则和实现。简单来说,本示例系统 中通过建立应用部署的逻辑模型,将应用的非功能性需求通过策略来表示。平台自动将这 个逻辑模型转化为支撑应用运行的物理结构(即所需要的中间件程序及其配置)。另外, 系统中的中间件系统以插件来组织,通过系统的代理框架根据应用的不同需求自动构造相 应的软件栈。这些设计都使得以往需要大量人力和专业技能的运营工作交由平台来自动实 现,大大简化了企业的IT运营,从而节省了企业在IT上的投入。 9.4.2 数据分析类 随着数据广泛可得、数据量迅速增加、从数据中获得知识的重要性不断显现,数 284 云计算宝典——技术与实战 据分析的重要性也快速增加。当获取数据的广度和深度的扩展导致数据分析任务变得 越来越多时,对数据分析的需求就从此前特定领域如科学研究和工程模拟等扩大到通用 领域。例如,企业可以分析自身运行中获得的数据以了解企业运行状况,商场可以分析 顾客的购买行为以优化商品配置,大型网站可以分析用户的访问行为以更好地了解用户 的习惯和偏好。 当数据分析需求扩大之后,提供数据分析功能的系统就要考虑到分析需求的多样性、 提交任务的随时性、数据格式的灵活性、分析方法的可变性等。更为重要的是由于数据分 析涉及大规模的数据存储能力和计算能力,普通用户保有这些的存储和计算系统却并不时 时使用,这是一种成本上的浪费。因此,从大众化的数据分析中抽象出通用的数据分析需 求,设计能够适应大众需求的数据分析系统并通过服务的方式提供给用户使用,是数据分 析类PaaS平台发展的根本动力。 9.4.2.1 系统概述 作为数据分析系统,在处理大众的数据分析任务时,需要具有的基本能力包括: 大规模的数据存储; 处理分析任务的大型计算能力; 容纳用户的多样性分析需求; 快速的资源调度和向多个用户同时提供服务的能力。 有了这样的数据分析系统,用户可以通过简单的接口向分析系统提交待分析数据及自 己的数据分析方法,而数据分析系统调度计算资源执行分析任务并返回分析结果。由于数 据分析涉及大规模的数据量和计算量,数据分析系统本质上就是一个大规模分布式数据存 储和处理平台。 数据分析任务的特点不同导致数据分析系统的设计也不同。当前一系列的公开数据分 析系统所针对的数据分析任务特点包括: 大规模的数据量,数据往往需要存储在多个节点上; 数据可以分块且分析任务可在各数据分块上并行执行; 第9章 平台即服务 285 在同一份数据上存在多种分析任务并多次执行。 这类数据分析任务已经总结为MapReduce模型。研究人员早在二三十年前就已 认识到MapReduce模型,而Google将其应用到搜索引擎的大规模数据分析中并显示其 威力。由于MapReduce模型以及其一系列改进模型能够适应一大类实际的数据分析需 求,因此它得到重视并有多个平台支持这类分析任务。典型的平台包括Google所使用 的数据分析平台和Hadoop。事实上,Hadoop是Google数据分析系统的开源实现。由 于Hadoop的开源性,人们能够很容易地接触到它的功能和结构,因而得到相关人员的 学习和使用。 Hadoop实质上是可靠的分布式数据存储和执行MapReduce类型分析任务的平台。从功 能层次来看,Hadoop分为三个层次(如图9.10所示),最下面的是Hadoop Core,实现分布 式系统的构建和维护。它实际上包括一组部件和接口实现分布式的文件系统和通用的 I/O操作(如序列化、远程调用和数据持久化等)。在Hadoop Core之上提供三个方面 的基本功能,分别为实现数据存储的Hadoop分布式文件系统HDFS,实现数据分析的 MapReduce计算框架,以及实现分布式系统构建和管理所需通用功能的Zookeeper。在 这些基本功能之上,Hadoop提供一系列的工具,如PIG、Chukwa、Hive、HBase等。这 些工具开发和使用基于Hadoop的数据分析更为方便,用户也可以进一步定制从而实现 自身所需要的功能。 从用户角度讲,Hadoop暴露的核心功能是HDFS和MapReduce,而Zookeeper在需要自己 构建基于Hadoop的分布式应用时也会涉及。下面分别就HDFS、MapReduce和Zookeeper逐一 做简单介绍。 图9.10 Hadoop系统的功能层次 9.4.2.2 HDFS模块 HDFS是Hadoop的分布式文件系统,实现大规模数据可靠的分布式读写。HDFS针对的 286 云计算宝典——技术与实战 使用场景是数据读写具有“一次写,多次读”的特征,而数据“写”操作是顺序写,也就 是在文件创建时的写入或者在现有文件之后的添加操作。HDFS保证一个文件在一个时刻 只被一个调用者执行写操作,而可以被多个调用者执行读操作。 文件系统通常采用“块(Block)”的概念作为数据读写的操作单位。一个磁盘上 的“块”通常为512Byte,而一个本地文件系统上的“块”通常为若干KB。HDFS也采用 “块”作为其管理的文件存储单元。HDFS的“块”通常为64MB或者128MB。HDFS中的一 块数据位于一个节点上,而一个大型文件可能存储在多个块的单元中,一个文件所在块 可以位于不同的节点。HDFS系统包括三类节点:HDFS客户端、命名节点(Namenode) 和数据节点(Datanode)。客户端是用户与文件系统打交道的接口,它提供读写文件、 管理文件的接口操作。命名节点用于维护文件系统的结构和元数据,例如文件系统的目 录层次、文件信息、数据存储位置等。而数据节点是实际的数据存储地,以块为单元保 存数据。 图9.11和图9.12分别展示了在HDFS中进行数据读取和写入操作的基本流程。HDFS客 户端通过与命名节点的交互获取关于目录和文件的元信息,通过这些元信息就知道实际数 据的存储位置,然后与数据节点进行交互执行文件数据的读写操作。为了保证数据的可靠 性,HDFS可以设置数据的备份数,即同一份数据保存在多个数据节点,从而容纳节点的 失效。 图9.11 HDFS读数据的流程 第9章 平台即服务 287      图9.12 HDFS写数据流程 由于数据保存在多个位置,维护数据的一致性就是HDFS系统的一项重要任务。因为 HDFS支持的是顺序写入方式,它支持简单的一致性操作。当一个文件创建并保存后,它 对“读”是可见的。但正在向一个文件写入时,当前被写入的“块”对“读”是不可见 的,其他已经写满的块对“读”是可见的,除非执行了同步(sync)操作。也就是说,在 写入数据时,如果调用了“sync”操作且“sync”操作返回成功,到此刻写入的所有数据 都会持久化到存储系统中且对所有的“读”可见,也包括当前正在操作的数据块。因此, 在HDFS中,数据读取可能落后于数据写入,这一点值得编写分析程序时留意。 HDFS中的命名节点维护文件系统的逻辑结构、文件的元信息包括文件数据实际存储 位置信息,它是文件系统可访问的关键。命名节点将文件系统的信息存储在内存中以供快 速访问和操作,同时将数据持久化到本地文件系统和远程文件系统(如NFS)以备故障恢 复。同时,HDFS也可以使用备份命名节点并与主命名节点实现数据同步,以便主命名节 点失效后备份节点快速接管主命名节点的任务。选择性能好、可靠性高的服务器充当命名 节点也可以提高HDFS的可用性。 HDFS还使用一系列优化措施来提高系统的可靠性、可用性和访问速度,读者可以参 考关于HDFS的文档或者直接阅读HDFS的实现代码。 9.4.2.3 MapReduce模块 MapReduce既是一类数据分析任务的编程模型,也是Hadoop中实现这类数据分析任 务的功能模块。关于MapReduce模型的介绍可以参看9.3.3节,此处仅介绍Hadoop如何执行 MapReduce任务。 288 云计算宝典——技术与实战 图9.13显示了Hadoop执行MapReduce的流程。如图9.13所示,一次数据分析称为一个 MapReduce工作(Job),分为Map和Reduce两类操作,这些操作根据对所操作数据的划 分而分成多项任务。为了执行MapReduce工作,Hadoop系统中有两类节点:jobtracker和 tasktracker。Jobtracker用于接收所提交的MapReduce工作,将工作划分为相应的任务并指定 所操作的数据,它同时调度任务的执行并派发到相应的tasktracker节点,然后监控这些任 务的执行过程,如果所有的任务都执行成功或者某些任务执行失败达到返回的条件,则返 回工作执行的结果。Tasktracker节点监控自身的负载,在有空闲处理能力时向Jobtracker请 求新的任务,在得到任务时启动新的JVM线程执行对应的任务,在任务执行过程中定期向 Jobtracker汇报任务执行进展,在任务执行结束后返回任务执行的结果。 图9.13 Hadoop执行MapReduce工作的流程 为了保证工作执行的速度和可靠性,Hadoop系统有一系列的优化措施。例如,在划 分Map任务时,每一个Map任务所操作的数据量尽量与HDFS所存储的数据块相一致,且把 map任务尽量调度到存储了相应数据块的节点,从而使得数据读写发生在本地,减少了读 取数据的时间和网络带宽消耗。用户可以配置jobtracker当一个任务在某一个节点执行失败 之后,jobtracker将其调度到其他节点再次执行,从而减少整个工作返回失败的可能;如果 一个任务执行速度过慢,jobtracker还可以在其他节点启动同样的任务,以期减少该任务的 执行时间。每一个执行任务节点上的tasktracker启动新的JVM进程执行对应的任务,以减小 由于任务实现代码中的错误导致该tasktracker崩溃的概率。Tasktracker还可以在一个JVM中 执行多个来自于同一个工作的任务,从而减少启动任务执行的时间。Hadoop在MapReduce 工作执行的过程中还采取了一些措施来处理中间数据,以减少中间数据在Map和Reduce任 务之间的传输量并加快处理速度。总之,Hadoop要努力做到的是通过这些并行化操作来提 第9章 平台即服务 289 高数据分析的速度和可靠性。 9.4.2.4 Zookeeper模块 大型分布式应用需要基于一组基本服务用以维护分布式系统结构,以及协调任务 执行和信息交换。在Hadoop系统中,有一个功能部件即Zookeeper来实现该类基本服务。 Zookeeper类似于Google数据分析平台中的Chubby服务,是其开源实现。ZooKeeper以Zab算 法为基础,Zab是一种全序广播(Totally ordered broadcast)协议,实现多个分布式节点之 间的协同机制。Zookeeper可以提供分布式应用所需的同步(synchronization)、配置管理 (configuration maintenance)、群组(groups)及名称服务(naming)等。 在Zookeeper中,数据以znode的形式组织成树形结构。znode类似于文件系统中的节 点,该节点有名称属性及附加的数据。Zookeeper对一个znode的数据操作保持原子性,即整 个读取或者完全替代一个节点的数据。Zookeeper还支持观察者(Watcher)操作,当所观察 的znode发生改变时,系统会向观察者发送通知事件。 Zookeeper系统包括两部分:服务器和客户端。客户端连接到某一个服务器,通过心跳消 息保持与服务器的连接,向服务器发送请求、接收服务器响应,获取服务器事件通知。客户 端通过配置知道一组服务器,当与所对应服务器的连接断掉后,它可以转而连接到其他的服 务器。Zookeeper的服务器之间通过选举机制选出领导,由领导节点来维护系统中的数据一致 性。如图9.14所示,客户端所写入的数据通过领导节点发布到其他节点。Zookeeper采用的是 多数一致原则,即领导节点将数据提交到多数节点上保存,则数据的写操作即成功。在数据 读取时,Zookeeper的客户端节点直接从所连接的服务器读取,以分散数据读取的负载。 图9.14 Zookeeper中的基本结构 290 云计算宝典——技术与实战 基于Zookeeper系统可以实现一系列的分布式数据结构和服务。例如,分布式应用的节 点作为客户端把配置信息保存在Zookeeper中,它可以查看、修改甚至删除这些数据,而观 察这些数据的其他客户端在数据发生变化时能够及时得到通知,由此实现了配置信息的管 理和发布,并保证数据的可靠和及时性。 作为可靠的分布式数据结构和基础服务,Zookeeper已被Hadoop及相关的Hive、PIG等 采用,它也可以单独用于构建其他的分布式应用。 9.4.2.5 公用Hadoop服务 用户可以选择自己搭建并使用Hadoop进行数据分析,也可以采用公开的Hadoop或者 MapReduce服务来进行数据分析。Amazon于2009年推出基于Hadoop的MapReduce服务,称 为Amazon Elastic MapReduce。Google App Engine的SDK中内置了对MapReduce的支持。在 Microsoft Azure上也有Hadoopdotnet项目将Hadoop迁移到.NET平台上,而MySpace Qizmt是直 接使用.NET实现的MapReduce框架,可以运行在Azure上。 一般来说,使用Hadoop(或者说MapReduce类数据分析服务),要考虑的因素包括数 据存取、分析逻辑及分析任务调度。对于不同的平台,其采用的数据存取服务不同,而 分析逻辑即Map函数和Reduce函数的需要根据平台所提供的开发接口来实现。分析任务的 调度则由平台来负责,用户无须干预。因此,用户在使用基于MapReduce的数据分析服务 时,应该检查所提供的服务提供的数据存取方式,使用编程接口构建Map和Reduce函数的 便利性。 以Amazon Elastic MapReduce为例,我们可以了解使用这类服务的基本步骤。Elastic MapReduce服务通过Amazon S3服务来存取用户提交的数据和分析应用代码,通过Amazon EC2实例来执行数据分析的计算,而MapReduce服务平台则负责分析任务的划分和调度。用 户可以通过以下几个简单的步骤来使用Elastic MapReduce服务: 开发所需的数据处理程序,主要是实现Map和Reduce函数; 上载数据和数据处理程序到Amazon S3中; 登录到AWS管理控制台启动Elastic MapReduce工作流,指明所需EC2实例类型和数 量,指明处理程序和数据在Amazon S3中的位置; 第9章 平台即服务 291 从AWS管理控制台监控工作流执行过程,执行结束后从Amazon S3中获取所获得的 数据分析结果。 采用公开的Hadoop服务,用户无须关注数据存储和计算所需的资源,无须考虑Hadoop 平台的管理和维护,而可以将精力集中在数据分析逻辑本身。因此,如果用户的数据分析 任务不是过于庞大、对数据隐私和安全要求不高,且需要尽快获得分析结果时,他们可以 考虑尽量采纳公开的Hadoop服务。 9.5 小结 平台即服务将云计算平台层的功能以服务的形式提供给用户,用于应用的开发、发布 和运行管理,是一类重要的云计算功能集合。本章首先阐述了平台即服务产生的驱动力, 即其设计的基本需求,以及所支持的基本应用类型,帮助读者对PaaS的功能特征有清晰的 了解。然后,本章介绍了实现PaaS系统的几项重要组成部分,它们是针对PaaS的功能和使 用方式而专门设计的,根据其所处系统架构的位置,划分为核心系统和扩展系统。最后, 本章针对平台层的两种主要运用形式,Web服务和数据分析服务,通过实例来剖析面向这 两类服务的PaaS实现要点,帮助读者对平台即服务获得更深刻的理解。
还剩155页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

mwbg123

贡献于2013-09-30

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf