架构云爆发

Oracle参考架构云基础架构3.
0版E24529-012011年11月云基础架构,3.
0版E24529-01Copyright2009-2010,Oracle和/或其分支机构.
保留所有权利.
主要作者:MarkWilkins特约作者:StephenBennett、JamesBaty特别感谢:AnbuKrishnaswamyAnbarasu、MarkCarlson、MargretLee担保免责声明本文档及文中提供的所有信息均为原样提供并仅供参考.
ORACLE明确拒绝任何形式(无论明示还是暗示)的任何担保,包括但不限于对适销性、特定用途的适用性和不侵犯知识产权的暗示担保.
ORACLE不保证这里的信息完全正确、准确和可靠.
ORACLE有权随时更改或更新文档内容,恕不另行通知.
由于企业自身需求取决于诸多因素,各家企业之间可能极不相同,因此企业在作出技术基础架构决策时应进行自己的测试和评估.
本文档不包含在您的许可协议之中,也不可纳入任何与Oracle或其分支机构的合同协议之中.
如发现任何错误,请以书面形式向我们报告.
第三方内容、产品和服务免责声明本文档可能提供有关第三方内容、产品和服务的有关信息.
Oracle不负责并且明确拒绝有关第三方内容、产品和服务的任何形式的任何担保.
对于由于访问或使用第三方内容、产品或服务而招致的任何损失、成本或损害,Oracle概不负责.
责任限制在任何情况下,Oracle对因访问或使用本文档或本文信息引起的,由您或任何第三方造成的(不论是合同还是侵权行为引发起诉而造成的)任何形式的损失概不负责,包括直接损失、间接损失、意外损失、特殊损失、后果性损失,或利润和收入损失、数据丢失或无法使用造成的损失.
Oracle是OracleCorporation和/或其分支机构的注册商标.
其他名称可能是其各自所有者的商标.
iii目录将您的意见发送给我们vii前言.
ixOracleIT战略(ITSO)简介ix文档用途x目标读者xi文档结构xi如何使用本文档xi约定xi1简介1.
1云计算的不同之处1-21.
2云计算的起源1-21.
3本文档所涉及的范围1-31.
4前提1-32优势、前景和挑战2.
1主要考虑事项2-22.
1.
1效率与敏捷性2-22.
1.
2战术与战略2-32.
1.
3目标应用程序开发模式2-42.
1.
4业务战略协调2-42.
1.
5降低入门成本/加速投资回报2-42.
2云架构需要应对的挑战2-62.
2.
1控制委派/所有权缺乏/抽象2-72.
2.
2应用程序可移植性2-72.
2.
3安全性2-82.
2.
4泛滥与版本控制2-82.
2.
5地理位置2-92.
2.
6透明性2-93术语和概念3.
1基本特征3-23.
1.
1按需自助服务3-2iv3.
1.
2资源池化3-23.
1.
3快速伸缩3-23.
1.
4可度量的服务3-33.
1.
5广泛的网络访问3-33.
2其他特征3-33.
2.
1多承租方3-33.
2.
2开发-运营转变3-33.
2.
3开发周期3-43.
2.
4规模与速度3-43.
3服务模型3-43.
4部署模型3-63.
5选择服务和部署模型3-73.
6术语3-73.
6.
1服务和服务产品3-74云概念架构4.
1云架构需求4-14.
2概念架构视图4-24.
2.
1访问层4-44.
2.
2管理层4-44.
2.
3服务层4-54.
2.
4资源4-54.
2.
5云使用者4-54.
2.
6云代理商4-54.
3架构概念4-64.
3.
1虚拟化4-64.
3.
2可部署实体4-64.
3.
3变化速度4-74.
3.
4对构建时和运行时的丰富支持4-74.
3.
5对各种角色的支持4-84.
3.
6异构资源管理4-84.
3.
7多区域能力4-84.
4架构约束4-84.
4.
1Brewer的CAP理论4-94.
5云案例/用例4-104.
5.
1云爆发4-104.
5.
2开发和测试4-104.
5.
3弹性伸缩4-104.
5.
4整合4-114.
5.
5灾难恢复4-114.
5.
6临时负载4-114.
6架构原则与准则4-114.
6.
1符合标准4-124.
6.
2感知简单性4-124.
6.
3可见性4-134.
6.
4透明性4-134.
6.
5原地失败4-13v4.
7技术与标准4-144.
7.
1美国国家标准与技术研究所(NIST)4-144.
7.
2DMTF4-144.
7.
3存储网络行业协会(SNIA)4-144.
7.
4其他4-144.
7.
5云API.
4-144.
7.
6MapReduce和Hadoop4-155ORA密切关系5.
1ORA水平层.
5-25.
1.
1共享基础架构.
5-25.
1.
2信息管理.
5-35.
1.
3应用程序基础架构.
5-35.
1.
4交互.
5-35.
2支持的功能.
5-36总结A延伸阅读A.
1相关文档.
A-1A.
1.
1建议的预先阅读.
A-1术语表vi图表清单2–1传统成本汇总示例2-52–2等效资源的云成本2-63–1NIST云计算定义3-13–2云服务模型层次结构3-54–1云概念架构4-34–2云管理层4-44–3构建时与运行时角色4-75–1Oracle参考架构5-15–2服务模型与ORA间的对应关系5-2vii将您的意见发送给我们云基础架构,3.
0版E24529-01Oracle欢迎您对本出版物的质量和有效性提出评论和建议.
您的反馈将成为后续修订的重要信息组成.
您是否发现文档中存在任何错误提供的信息是否清晰您是否需要更多信息如果需要,是哪方面的信息示例是否都正确您是否需要更多示例本文档有哪些特点是您最喜欢的如果您发现任何错误,或者有任何其他改进建议,请指明文档的标题和编号、章号、节号和页码(如果适用).
您可以通过its_feedback_ww@oracle.
com将您的意见发送给我们.
viiiix前言Oracle参考架构(ORA)是一个与产品无关的现代IT基础的规划蓝图.
通过发现常见的业务需求并将业务需求与IT能力、原则、标准及最佳实践相对应,ORA描述了一个一致的、可互操作的、持久的环境,从而将产品不兼容与产品过时的风险降至最小.
ORA云文档从云的视角提出了ORA的概念,作为ORA核心概念的详尽阐述,重点介绍了云的特定细节.
ORA云视角文档有两个:云基础(CloudFoundation):主要介绍云的概念架构,从业务和运营层面说明云的架构特征和预期前景.
该文档还包括云架构的架构原则、标准、概念、云架构概念视图及其与ORA的关系.
云基础设施(CloudInfrastructure):将概念架构定义的云的特征和要求与Oracle基础架构联系起来,并提供一些架构视图来帮助专注于云的架构师和开发人员.
本文档是介绍Oracle云技术战略的系列文档中的一篇.
此"云基础(CloudFoundation)"文档提供云概念的底层架构定义,给出了重要的云基本概念,这对于构建基于云的应用、准备将IT转型到云和更广泛地在企业普及云来说至关重要.
OracleIT战略(ITSO)简介OracleIT战略(ITSO)由一系列文档和支持材料组成,旨在帮助企业制定以架构为中心的方法来实现企业级IT计划.
ITSO通过阐明普遍采用的架构概念、原则、准则、标准和模式来展示成功的技术战略和解决方案设计.
xITSO主要由三个部分构成:Oracle参考架构(ORA)定义详细、一致的架构以便基于Oracle技术开发和集成解决方案.
该参考架构根据全体Oracle技术专家的建议提出架构原则和准则.
它涵盖了与技术架构有关的各种考虑要素,包括中间件、数据库、硬件、流程和服务.
企业技术战略(ETS)为企业采用横向技术提供有益的指导.
它们阐明如何通过解决有关架构、技术、设计、战略和治理方方面面的问题以成功执行战略.
组织可以使用这个材料来衡量自身的成熟度、制定自己的战略、实现更高水平的采用和更大的成功.
此外,每个ETS通过增加由特定技术提供的独特能力和组件而扩展了Oracle参考架构.
它基于横向技术展现ORA.
企业解决方案设计(ESD)从行业视角出发提供基于ORA的行业特定解决方案.
它们定义了高级业务流程及功能,定义了构建企业级行业解决方案所需的底层技术基础架构的软件能力.
ESD还将相关的应用和技术产品与解决方案相对应,说明Oracle全面集成体系的能力如何能够最好地满足特定行业的业务、技术和服务质量要求.
本文档是构成云企业技术战略的系列文档的组成部分,它包含于OracleIT战略文档集中.
有关云与ORA文档的完整清单以及ITSO系列的其他材料的信息,请访问ITSO网站.
文档用途ORA文档按技术关注点与主题领域相对应以体现文档用途.
云基础架构文档的这种对应关系如下图所示:xi该基础架构的目标是定义关键实体(资源池、控制面板、可部署实体等)、功能(服务供应、用户注册等),设计原则(如资源分离与云管理),重要相关标准(Oracle云API/DMTF用例)和技术.
目标读者本文档面向企业架构师、应用程序架构师、项目经理和开发人员.
内容适合有兴趣了解云架构以及有兴趣了解如何为开发企业级云基础架构做准备的技术读者.
文档结构本文按章节组织,章节内容包括简介、背景、概念架构、标准与技术、ORA相关内容和附录.
本文档的主要章节如下:第1章简要介绍云并说明本文档所涉及的范围和用途.
第2章概要介绍云架构的优势、前景和面临的挑战.
第3章定义云架构特有的术语和概念.
第4章介绍云的概念架构.
第5章描述云与ORA其他方面的关系.
第6章文档总结.
附录A提供相关附助阅读资料和参考资料的列表.
术语表提供整个文档中所用术语的列表.
如何使用本文档应将本文档作为ORA云基础架构文档的必读文档来阅读.
xii约定本文档使用以下字体约定:约定含义粗体文本粗体文本表示在文本中或ORA主要术语表中,或者在这两个位置定义的一个术语.
斜体文本斜体文字表示文档或外部参考资料的名称.
下划线文本下划线文本表示超文本链接.
"云"与"云计算"—云与云计算这两个术语意思相同,在整个文档中可以互换使用.
术语"云服务"表示由云计算向云消费者提供的服务.
因为"服务"一词用来表示许多不同的内容,因此,为避免混淆,在整个文档中它将跟在自己所属领域的名称之后.
该约定与SOAETS文档采用的约定有所不同.
简介1-11简介云计算是IT向硬件及其他计算资源商品化发展的重要成果.
正如SOA通过抽象技术实现细节提供可快速组合的强健的业务服务,从而在业务应用创建领域实现了革命性的创新,云也对计算资源(基础架构、平台、应用程序)进行了抽象化以便实现快速组装与部署.
云计算带来了许多商机,其中包括IT成本与敏捷性的明显改善(各种其他优势在第2章中介绍).
但是这些优势也带来了挑战和变革的需要,这些挑战和变革不仅涉及到底层IT架构,也涉及到开发和运营战略、支持组织以及IT文化.
本文档重点探讨作为云实施的广泛战略评估和发展规划组成部分的最高层的架构方面的考虑事项.
云计算,或者任何IT变革,不只是购买一些新的技术这样简单.
防火墙软件设备自身不能构建安全性,同样,仅仅在服务器中引入虚拟化并不能构造出云环境.
但这并不意味着云计算是更复杂的IT.
事实上,云计算能够也应该在基础架构的构建和使用上带来简化.
但是,这确实需要在设计上有所考虑,有可能"重构"IT职责.
某些按常规需要在前期实现的应用程序架构,现在转化为"运行时"架构,由云消费者来激活;同时,某些传统上一般由系统管理员执行的运行时操作,也变为随后支持自助服务的设计时架构.
特别地,云计算能够选择合适的抽象化级别、API和标准,从而使选定的IT投资寿命最长久.
这也正是云架构在考虑云的时候非常重要的原因所在.
强健的云实施方法必须考虑以下方面:业务理由.
洞察为实施云计算指定可衡量的转型目标的重要性.
云架构.
高阶架构框架不仅要强调云架构的关键组件,也要提前应对实现主要逻辑抽象时存在的一些问题.
演进路线.
在选择和开发了高阶云架构后,重要的是要对现有环境进行评估(包括组织在诸如运营、治理等重要方面的成熟度),还要制定指导这一战略实施的演进路线规划.
本文档关注云架构的起点:具体来说就是云的概念架构,是其他具体的云架构定义的基础,这些具体的云架构可以在ORA的另一篇文档中看到:云基础设施架构.
1-2云基础架构云计算的不同之处本文档还简要介绍了业务优势和前景,用以支持确定概念模型所需的架构能力,演进路线规划和在前面列出的相关准则将成为其他ITSO云企业技术战略文档的主题.
1.
1云计算的不同之处简而言之,云是这样的一种计算方式,这种计算方式可通过网络(通常是互联网)将可动态伸缩和可快速部署的IT资源作为服务来提供.
通常,也将云计算定义为基于订阅并通过网络提供(及消费)计算资源和其他IT能力.
但是,这第二个定义似乎跟"托管"并无不同.
云与"托管"的主要区别之一就是,它能够按需扩展和使用资源(即"动态伸缩").
这一特征也称作"弹性",是云计算的主要能力,而传统"托管"不具备提供这一能力.
此外,与基础架构和平台托管相比,云服务的范围要广得多,目前包括诸如存储、信息、安全、测试、应用程序等服务,直到"虚拟数据中心"的全面服务.
云有何不同于外包和托管外包和托管在许多方面为云铺平了道路,但云是这条发展之路上的一个重大进步.
传统外包通过法律合同提供屏蔽技术细节(运行时间、系统性能、灾难恢复等)的IT服务(应用程序、数据存储等).
托管服务则借助技术标准化(如LAMP),也提供更多技术能力,使得可以在独立租用的计算资源(服务器、磁盘、网络容量等)单元内开发和托管应用程序.
而云通过提供虚拟资源(计算基础架构、平台和应用程序)、各种形式的自助服务以及抽象的管理和控制,将这些基本概念提升到了更高层次.
云的另一个不同之处在于这样一种发展趋势:创建和使用更多定义良好的服务(这些服务有自己的接口、服务质量特征等).
这一更多服务目录方法的发展趋势,能够帮助IT组织更好地传播他们提供的服务、改善所支持的服务质量级别、降低与之相关的成本.
1.
2云计算的起源上世纪六十年代,JohnMcCarthy说过:"也许有一天可以将计算作为公用事业来进行组织.
"2006年,当EricSchmidt将Google的数据中心称为"云服务器"以及Amazon启动了AmazonWeb服务时,才开始使用"云"计算这一说法.
现在,这一说法已获得广泛认可,它描述了IT从大型机,到客户端服务器、n层,再到"按需"基础架构这一发展过程的新阶段.
美国国家标准与技术研究所信息技术实验室(NIST)给出了以下普遍认可的定义:"云计算是一种允许通过网络方便地按需访问共享的可配置计算资源池(如网络、服务器、存储、应用程序和服务)的模式,它只需最少的管理工作或服务提供方交互即可快速供应和释放这些资源.
"简介1-3前提NIST还指出"这种云模式能够提高可用性,它具备五个基本特征、三种服务模型和四种部署模型",但是,这些特征和模型并不同样适用于所有"云",例如,自助式开发人员公有云很可能与政府机构"社区"云有着完全不同的实现.
那么,如果我们考虑"企业"云计算,那么与普遍认可的云定义相比,它具体是一种什么情况呢这就是本文档所要回答的核心问题.
1.
3本文档所涉及的范围本文档所涉及的范围主要限定于适用于企业的云模型:这包括涵盖基础架构即服务、平台即服务和软件即服务(IaaS、PaaS和SaaS)的私有云和混合云.
在这个范围内,本文档重点从企业(即不包括云消费者)的视角出发关注公有云和私有云.
特别是,本文档不涉及大型计算需求(如科学计算).
1.
4假定云架构仍处于发展之中,对于其架构定义、能力和特性,目前在行业中仅有有限的共识.
因此,云的预期前景可能改变,相应的标准和技术也将不断发展.
本文通过探讨为了满足当前所了解的云的需求而须具备的架构特征来尝试提供一个与技术无关的云架构开端.
前提1-4云基础架构优势、前景与挑战2-52优势、前景和挑战云计算通常被视为能在成本缩减和业务灵活性方面带来显著优势的IT战略.
2008年,IDC提供了一份企业对云计算的期望的重要分析报告,在这份报告中,244名IT高管指出了他们所认识到的云的优势.
这次调查表明,通过云获取IT服务的最大优势就是部署速度加快并且易于部署.
大家普遍坚信,云计算能够解决在传统IT环境中开发和部署业务应用程序速度过慢的问题.
下面的三个主要优势可提高企业在IT使用方面的经济性:按使用情况衡量成本减少对内部IT人员(及其相关成本)的需求用分散付款取代大规模的前期财务支出(或者说将资本支出转换为运营支出)最后一点凸显了云成本模型带来的另一个重大商机,也就是消除了前期IT投资成本,让新的想法和计划不再因前期IT投资成本而受阻:无论是刚成立的小企业,还是大型企业,当他们能够轻松地按需创建和按需购买基础设施、平台或软件服务时,源自技术密集理念的业务计划不再需要担心花费大量成本和时间来部署新硬件.
第2.
1.
5节"降低入门成本/加速投资回报"中详细介绍了一个示例以说明这种影响.
可以通过减少人员来实现简单的成本节省,也可以选择另一种方法,即投入资金对现有IT人员进行再培训以最大程度发挥云带来的优势,最终提高IT生产力.
例如,通过对IT人员进行系统管理或治理角色的交叉培训,云实施的重点就从通过整合实现简单的成本节省转向提高服务质量和效率.
云服务带来的另一个受到高度认可的预期优势是能够让业务系统和服务跟上市场潮流.
由于云服务是以共享资源模型为基础,因此与传统模型相比,供应商应能相当轻松地向所有用户提供对新功能的"即时"访问.
迁移到云的最常见动机是为了节约成本,而头号公认的障碍则是安全性.
然而实际上,云计算很可能会带来更多重大的可能出乎意料之外的优势,例如它让企业能够将核心竞争力转化为服务进行销售(以及外包非核心功能);同时,在云中可以更一致地应用安全性,最终云的安全性将超越我们行业的现有安全性.
我们总结一下云的预期前景,包括:降低成本主要考虑事项2-2云基础架构提高可用性不受限制的IT能力的增加消除了技术密集型业务启动的障碍加快市场响应速度获得更多IT选择上面所列并非详尽无遗,但它是建立云架构业务需求的一个起点.
2.
1主要考虑事项在对寻求制定云计算战略的企业的业务需求进行评估时,重要的是要考虑以下五个方面:1.
效率与敏捷性—企业寻求的主要优势在本质上是成本降低,还是转型,即是否期望获得功能性业务改进,比如说大幅减少新客户服务的上市时间(TTM).
2.
战术与战略—企业寻求通过云计算获得的优势本质上是战术性的,也就是,整个组织以渐进增加方式实现云功能(例如,随处实现虚拟化),还是战略性的,即着手进行IT战略的革命性转型(创建新的自助式服务开发环境和模型).
3.
传统客client-server应用程序与Web2.
0/富互联网应用程序—企业需要了解自己的应用程序开发模型,在传统企业计算或下一代以web为中心的应用程序之间做出选择.
典型的公有云服务可能不是适合复杂企业应用程序架构的模型,但是,企业可以在公有云中专门开发资源池来支持更多的传统应用程序模型,或将这些应用程序模型纳入私有云中.
4.
云如何与更大的业务战略保持一致例如,企业自身是在寻求提升业务控制的集中度,还是在寻求一种去中心化的资源模型.
5.
是否有一些重要的功能化IT用例需要考虑例如,开发和测试、峰值负载管理、资源整合.
很显然,以上几个方面存在着潜在相互依赖关系,但也有两种极端情况:(1)云计算战略是采用新的应用程序开发范式进而在服务提供方面建立竞争优势的重大战略项目,(2)云计算是降低整个企业现有应用程序和基础架构的成本的战术方法.
然而另一方面,改变应用程序开发模型的计划可能实现节省成本的目标.
也可以采取这样一种战略,将分别在多个项目或计划中的战术目标和战略目标结合在一起.
在任何情况下,围绕特定的业务目标设计基础设施,并同时又能进行有效的监视和优势评估,这是非常重要的.
以下各节将逐个详细讨论这五个业务方面.
2.
1.
1效率与敏捷性企业采用云计算的主要动机是为了降低IT成本.
IT成本的一个主要目标就是硬件利用率(HUG—简单说就是服务器的CPU、磁盘、内存等资源利用的百分比).
目主要考虑事项优势、前景和挑战2-3前数据中心硬件利用率的一般水平约为7-15%.
造成这一情况的主要原因是由于负载由专用服务器分别承担.
云计算架构将应用程序负载的移动性与池化资源的虚拟化相结合,为解决这一问题提供了有力的保障.
但是,与传统服务器整合工作一样,要衡量云计算的企业投资回报率还是要基于成本的降低.
成本降低的计算还包括基础架构电力效率(DCIE—数据中心基础架构效率和PUE—电力使用效率、绿色电网建议的IT设备耗电与总设施耗电的比率,等等)、软件许可、管理成本等.
最终计算结果随不同的企业而不同,但一般来讲使用云计算来降低成本是切实可行且可以衡量的.
除去简单的电力使用,构成总拥有成本(TCO)的还有许多其他直接成本因素.
这些因素包括硬件和软件支出、操作和服务台人工、财务与行政管理成本等.
尽管云计算可以轻松地缩减部分资本和运营成本,但它也可能增加软件许可成本的复杂性.
这可能需要一些机制来监视和记录许可的并发使用情况.
除这些直接成本外,在云计算计划中还有许多间接成本可能需要考虑.
这些间接成本包含以IT团队为最终用户提供预期服务的效率来衡量的成本,可能未纳入预算.
如果IT管理和解决方案效率低下,那么最终用户可能会在自助支持和单点支持上花费大量时间.
这些成本在云计算环境中可能会减少,但是,如果没有针对这些成本进行规划,那么在IT转为自助服务模式后这些成本有可能增加.
除减少基本成本外,云计算还将极大改善应用程序开发和服务部署的上线时间(TTM),因此在提高整体业务敏捷性方面也带来了许多好处.
经典云计算用例之一就是利用池化的云资源来进行开发和测试.
但是,要充分利用云计算实现业务敏捷性,可能需要将很多业务从传统应用程序架构转到更加以服务为中心的互联网应用程序模型.
这当然意味着更复杂的投资回报考虑事项,还可能意味着在纯粹的内部IT计划之外的一个战略性企业投资.
2.
1.
2战术与战略正像随后讨论在云计算启动时应用IT成熟度模型中介绍的,云计算意味着开发和自动化运营过程的重大进展.
极端情况是希望首先转变为自助式IT模型.
一个企业采用怎样的云计算演进路线,主要取决于企业的目标及其IT成熟度.
那些需要较低IT成熟度的目标可以跨整个企业用战术方式轻松实现(例如,通常的"虚拟化无处不在"战略).
但是,需要高度IT成熟度的云计算目标,很可能需要通过专注于特定业务目标的战略转型项目来实现.
两个排他的实施方向(战术或战略),可能最终会由于压力而采取相反的方向.
例如,战略转型项目最终得到更广泛的采用.
此外,在效率和敏捷性方面,大多数企业都可能追求综合目标,因此,企业云计算战略很可能既包括战术性的广泛实施努力,也包括有针对性的战略项目.
主要考虑事项2-4云基础架构2.
1.
3目标应用程序开发模型由AmazonWebServices(AWS)率先倡导的云计算模型曾经特别有助于富互联网应用程序(RIA)的开发.
RIA是Web应用程序,通常使用网络中最终用户设备内运行的轻型客户端应用程序提供与桌面应用程序相同的特性和功能.
从数据中心的视角看,这些应用程序基于无状态的web服务而构建,这些web服务可以通过动态资源池方便地进行负载均衡和迁移.
这与传统企业应用程序形成了鲜明对比,传统企业应用程序实现动态供应要更加复杂,也更困难.
另一方面,大多数企业正在独立地迁移到更加无状态的、以web为中心的应用程序架构.
一家企业的云计算战略是否合适,很大程度上取决于规划的应用程序开发模型是基于互联网交付的开发模型,还是施加了诸如应用程序有状态性和执行可移植性等设计限制的开发模型.
这类挑战有些可能能够通过增加现有应用程序功能的服务抽象来应对,但是,根本上讲,对于大多数企业来说转变为云计算模型则意味着有可能进一步发展现有web服务和互联网应用开发模型.
但是,对于当今业务流程中常见的并由传统管理软件(如CRM、ERP等)支持的复杂业务功能的编排和业务实体的维护,还没有替代产品.
虽然,很明显的是,简单的高度可伸缩功能(如搜索)非常适合于云计算,但是,能够将云模型应用于更广泛的企业需求也很重要.
通过在抽象业务流程的同时将应用程序以SOA方式分解为更小的可移植独立业务功能,就可以最高效地实现云模型的广泛应用,从而促进云迁移.
2.
1.
4业务战略一致性在宏观层面上,云计算战略还应与更大的业务战略相辅相成.
例如,如今在许多行业,通过整体业务整合以及相关的合并和收购实现增长的战略成为主流.
在这种情况下,全面的IT战略及相关的云战略可能在支持现有IT基础架构整合和加快伴随收购而来的IT应用程序整合方面发挥重要作用.
另一方面,有些行业通过扩张到新市场(也许是海外市场)来推动业务增长.
在这些情况下,可以设计云战略来支持微型扩展,也就是小规模构建虚拟业务基础架构以支持进入新市场的独立运营.
在另一些情况下,行业发展的高度竞争可能会导致将服务的竞争差异化作为主要战略,而相辅相成的云战略可以支持这些服务的快速开发和扩展.
在有些领域,云战略不仅能够简单地支持特定的业务战略,而且还是业务战略的巨大推动器.
在任何情况下都应该考虑云战略对整体业务战略的贡献.
2.
1.
5降低入门成本/加速投资回报新项目(无论是现有企业内,还是全新业务)的一个主要业务驱动因素是尽可能去除计算成本从而降低进入门槛.
云所具有的"按需购买"、"按需使用"的性质几乎可以消除启动成本并且可以延迟计算基础设施的成本投入,因而可以加快创新速度.
主要考虑事项优势、前景和挑战2-5传统上,任何新的计算项目均需要在硬件、安装、管理和交付时间上投入大量先期成本.
这一固定成本的存在必然导致滞后很长时间才能实现某种程度的投资回报.
图2–1显示一个新项目的成本-销量-利润分析1,项目由于前期过高固定成本资本投入导致未能按预期实现盈利.
图2–1传统成本汇总示例图2–2显示了类似的成本分析,其中同样的项目由于固定成本较低,尽管可变成本升高25%,仍然提前实现了自己的盈利目标.
这种成功在云环境中是可以预期的,因为在云环境中,能够根据需要以小得多的增量方式使用资源(并为之而付费),从而使得成本的积累与收益相关联.
1成本-销量-利润分析的详细信息可参阅http://en.
wikipedia.
org/wiki/Cost-Volume-Profit_Analysis2-6云基础架构云架构需要应对的挑战图2–2等效资源的云成本这种入门成本的节约在公有云环境中表现得最为突出,在公有云中,云基础架构、设施、管理等方面的投资都是分散支出的.
不过,在私有云的情况下,建立云的初始成本很可能需要由大量的应用程序迁移而非像这样的投资回报时间模型来验证其合理性(进而承担该成本).
2.
2云架构需要应对的挑战和SOA一样,云是从已经存在的概念演化而来的新术语.
"外包"和"托管"是人们广为接受的技术,它们降低拥有系统的复杂度,同时保证成本更低,运营更有效.
同样和SOA一样,云不是灵丹妙药,云也不得不面对自身的挑战.
如标题所示,本节重点关注云架构必须应对的问题.
值得注意的是架构不可能解决一项新技术的发展过程中出现的所有问题.
例如,云提供商面临的主要挑战之一就是由不再拥有有形硬件资产而带来的不适.
在企业云的情况下,并不一定存在这一问题,但是,即使这种情况下,习惯于拥有自己的硬件的部门将不再能够接近集中的数据中心,随着时间的推移那些资产将可能变得越来越无形.
本文档不会讨论此类"情感依恋"问题以及与组织、治理、项目管理等有关的其他类似问题.
类似地,由于易于访问并且新开发入门成本的降低而产生了另一种风险,就是诱惑业务部门通过转到公有云服务来满足自己的IT需求而绕过他们公司的IT战略.
这将导致IT分裂,正如由于微型计算机的出现而推动了部门计算的浪潮,从而摆脱了优势、前景和挑战2-7云架构需要应对的挑战大型机计算的束缚.
不过,这是一个治理问题,超出了本文档的范围.
下面列出的挑战大部分是云所特有的挑战.
下面所列旨在突出云架构必须应对的问题,但本节不探讨解决方案(除基本建议外).
需要重点指出的是,本节并非是要罗列不遵守云战略的理由!
2.
2.
1控制委派/所有权缺乏/抽象在本文档的前面几节中,已经指出了这组广泛问题的多个方面,但是本节的目的是要从纯架构视角考虑这些挑战.
这一挑战确实涉及到抽象的影响.
当然,抽象会带来很多好处:它简化了对象(云环境中的IT资源)的使用,鼓励标准化和模块化;不过,它也"隐藏"了那些对象或服务不需要的底层细节.
这就存在一个问题:需要在对象或服务的整个生命周期的各个阶段确定哪些细节是需要的而哪些又是不需要的.
此外,通常很难通过用于抽象的机制来公开某些类型的信息.
2.
2.
2应用程序可移植性正如ORA云基础设施文档的逻辑模型所示,当采用某些前提作为逻辑架构的约束时,能够最有效地提供云计算:从根本上说,当云实现遵循了基于由网络连接的、可以按需分配的许多小计算资源(CPU和内存)单元的架构战略时,云实现将十分简单.
就此而论,在没有其他计算模型(如大规模SMP、NUMA等)的情况下,应用程序、数据库和其他平台软件,如果没有设计为在这种环境中进行扩展,则并不适合直接迁移到云.
那些通过增加紧密耦合的计算资源—如多核芯片和/或SMP主板、处理器RAM或其他直接共享内存(即由内部总线连接的处理器和内存)—来扩展自己所支持的使用数量、交易率或其他种种处理能力的应用程序(和其他软件),都称为垂直扩展的应用程序.
在大量IO需求的情况下,某些应用程序(主要是数据库)还需要直接控制磁盘组织(如数据库表和索引分区,改善性能的条带化等),虽然这一需求随着缓存技术和高容量网络上的SAN的出现已不太常见.
应用程序架构要求垂直可伸缩性这一基本约束的产生,是由于应用程序和基础设施组件之间需要特定耦合,而基础设施组件按需提供则是非常困难.
垂直扩展应用程序需要低级硬件配置,而通过软件控制提供这种配置十分困难.
简而言之,对底层平台架构和设计存在特定要求的应用程序理论上并不适合云环境.
当然,这也不是一成不变的规则,在使垂直扩展应用程序适用于云环境方面也存在许多变通方法,例如:软件架构设计上支持多租户(参见第3.
2.
12节的定义),使许多不同用户能够"共享"垂直扩展平台(如非常大的SMP基础架构上的传统RDBMS)上的单个应用程序2-8云基础架构云架构需要应对的挑战消费者不需要基于基础设施来提供极致的伸缩性(如使用MySQL的开发环境)然而,这些变通方法缺乏云预期具备的弹性和某些其他特征,除非设计高度复杂(很可能是专用)的基础架构管理能力来弥补这些不足.
有必要再次指出,并不是所有云特征在任何情况下都是必要的(它们的重要程度也并不相同),因此为了支持垂直应用程序而放弃弹性可能是一种比较周到的做法.
鉴于上述所有原因,典型的云(及其与之密切相关的技术、虚拟化)更容易提供水平可伸缩性.
水平伸缩架构以小规模固定增量来增加计算能力,以此来支持平台和应用程序的增长.
这种固定增量扩展的物理表现,可能是由2个CPU处理器、数个Gb的RAM和相对应的网络带宽和磁盘IO带宽所组成的"largefarm";另一方面,虚拟化环境可能为它的消费者提供类似的增长途径,但它是由后台更多样化的基础设施所组成.
考虑到许多复杂企业应用程序的性质、以及当前IT的多样性,云基础设施如果同时支持水平和垂直应用程序可伸缩性(也许还结合其他折中办法,如应用程序级多租户支持),则既可以带来许多云优势,同时又能够保持高性能并简化迁移.
2.
2.
3安全性遗憾的是,安全性是一个涉及情感的主题,至少在目前,人们对于将关键业务信息和运营托付于云这样抽象的环境(无论是公有云还是私有云),在安全性上还是存有担心的.
从根本上说,人们普遍认为"军事级的安全性"是可以实现的,但是,由于成本(有时是缺乏经验)方面的原因,大多数企业采取的是折中方案,然而,由于云所具有的规模经济,并且由于安全性更加利害攸关而产生更高的安全动机、云计算应会带来固若金汤的安全性.
2.
2.
4滥用与版本控制将会发生滥用吗正如帕金森定律("不到最后一刻,工作就会一直进行,直到用完所有的时间")已应用于数据、软件(例如"软件不断扩展,直到用完所有可用内存")等领域,在云中可以轻松启用服务的情况下,似乎可以不断地启用服务器实例,直到用完所有可用资源(物理上的"大自然痛恨真空").
对这一极其常见后果的补救办法就是规章制度,这从根本上来说涉及到治理;但是,在这种情况下,治理需要计量形式的架构支持,即使在私有云的情况下也是如此.
如果没有对资源使用情况进行计量的有效方法,用户不会主动关闭和弃用实例、释放存储资源,也不会从资源库中注销不再使用的映像.
虽然在公共消费模型中计量通常会导致计费,但在私有云的情况下也必须有同等的机制.
这种机制可以有多种形式,但为了避免帕金森效应,最基本的是需要针对资源使用进行成本分配.
优势、前景和挑战2-9云架构需要应对的挑战实施必要的规章制度以减少滥用的其他的可能的办法还包括为云中的服务规定一个过期时间.
这一措施也可以扩展(或演变)为限制持有版本的数量.
2.
2.
5地理位置原则上,虚拟化服务、服务器或数据中心可以位于任何地方,在网络带宽充足的情况下,它们可以遍布多个物理位置.
在纯技术方面,硬件的位置并不重要;然而,许多国家/地区都有各种不同的法律,规定数据不能跨越国家(有时是州或其他区域)边界.
在实际中,互相协作的计算中心之间的网络带宽可能是有关资源组装的重要架构约束,例如,数据库服务和应用程序之间的网络带宽.
2.
2.
6透明性云消费者需要了解多少如果您只是SaaS模型中某个应用程序的消费者,您需要了解的一切都可以在SLA中进行管理,即,应用程序将支持的并发用户数、正常运行时间和灾难恢复应急措施等.
在这种情况下,系统架构、运行的服务器数量、处理器架构等对SaaS消费者来说并不重要.
然而,即使是SaaS模型也很难预先安排好一切,而我们在考虑PaaS和IaaS模型时,这些细节(以及类似的更多细节)会变得非常重要.
消费者需要了解的其他方面的问题还有:例如,SOX和其他国家法规应该要求云提供商分享有关其他合规性问题、安全违规、停机等方面的信息吗有关透明性的另一个担心涉及地理位置问题—大多数云消费者需要知道他们的数据存放在何处,这需要云提供商一方面约束数据的移动,另一方面又能根据特定需求提供数据的位置.
2-10云基础架构云架构需要应对的挑战术语与概念3-13术语和概念本节介绍术语和概念、云特征、服务和部署模型.
根据当今被广泛接受的NIST定义,云计算包含五个基本特征、三种服务模型和四种部署模型.
本文档将比较详细地介绍这些内容,并探讨其他可能的考虑事项,目的是作为云概念架构定义的前奏,阐释一套全面的架构能力.
图3–1,"NIST云计算定义"汇总了这五个基本特征、三种服务模型和四种部署模型.
图3–1NIST云计算定义下面几节详细阐明了这些特征和模型.
3-2云基础架构基本特征3.
1基本特征并不是所有的云都将以同样的方式或程度实现NIST模型的五个基本特征.
例如,"快速弹性"对于公有云开发人员意味着云可以向最终用户即时开通服务器,而企业云很可能会限制向生产云中开通的内容、需要对请求资源的操作者进行验证,并且还负有监视相应负载的合规性责任.
在这样的企业环境中,"按需自助服务"可能意味着将开通企业IT的时间从数月减少至数周或几天—这仍然具有大幅改进的潜力.
3.
1.
1按需自助服务消费者可以单方面根据需要自动开通计算能力,如服务器时间和网络存储,而无需与每个服务提供商进行人员交互.
自助服务是云环境的共同目标,但在企业环境中,与纯粹的消费者/公有云自助服务模型相比,仍旧需要对IT施加一定程度的运营管控.
在传统IT中,对于分配系统资源或安装应用程序组件的请求,通常需要请求用户通过复杂的工作流(包括任务单,也可能通过人工电话呼叫等)与支持人员交互.
云计算旨在自动化执行这些常用的供应流程,从而使最终用户看似无需人员交互就可以直接获得资源供应.
显然这需要对目标资源、开发和实现部署模型以及负载计量基础设施(如服务目录、配置数据库)进行预开通.
3.
1.
2资源池化提供商的计算资源经过池化处理,可以根据使用者的需求动态分配和重新分配各种物理和虚拟资源,从而可以通过多租户模型为多个消费者提供服务.
客户一般无法控制和知道所获得资源的确切位置,这给人以位置不相关的感觉,但是也许能够在较高抽象级别(如国家、州或数据中心)指定位置.
池化资源的例子包括存储、处理器、内存、网络带宽和虚拟机.
私有云还可以包括其他"云"(如外部公有云)作为整体混合云模型可利用的一种池化资源.
虽然通常都可以期望混合云能够以低成本进行扩展,但是它们也给企业信息保护带来了特殊挑战.
可以仅对某些业务用例或数据类别使用混合云模型.
3.
1.
3快速弹性云可以快速和弹性地开通计算能力(有些情况下是自动供应),实现了计算能力的快速扩展和快速收缩(通过快速释放).
对使用者来说,可开通的计算能力通常似乎是没有限制的,可以随时以任何数量定购.
正如前面的"弹性"中所介绍的,可以通过一定程度的企业控制实现"快速"特性,这对传统IT采购模型带来了显著改进.
术语与概念3-3其他特征3.
1.
4可度量的服务云系统可以利用适合服务类型的一定抽象级别的计量能力,自动控制和优化资源使用(如存储、处理器、带宽和活动用户帐户).
可以监视、控制和报告资源的使用情况,这为提供商和利用服务的消费者提供了透明性.
在私有企业云部署中,可能有大量需求和机会来定义前所未有的新的资源度量和分配模型.
3.
1.
5广泛的网络访问可通过网络提供各种计算能力并通过标准机制让异构的瘦或胖客户端平台(如移动电话、笔记本电脑和掌上电脑)访问这些能力.
企业/私有云可能意味着对网络访问的更高程度的控制,这既可以保护传输中的数据,又可以提供多租户之间的强大隔离(每个租户可能有不同的应用程序或部门信息安全要求).
3.
2其他特征下面列出了与云架构开发有关的一些其他特征.
3.
2.
1多租户多租户虽然没有在NIST模型中列为云的一个独立的基本特征,但是在定义中专门提到了这一特征.
公有云一定要应对多租户的信息保护问题,同时,私有企业云可能也需要认真反思其治理及合规性制度,以便顺应向云模型的迁移,尤其是能够考虑混合模型.
在传统IT环境中,系统基础设施都是为特定应用程序而构建的.
整合通常也就是将一些同类的、具有共同组织所有权的应用程序相组合.
而云则意味着多样的、异构的多租户.
这会增加运营风险安全性问题.
实现此目的的技术不只是操作系统虚拟化.
这可能要包括从较低级操作系统分区到应用服务器共同承租等一切技术.
重要的是云多租户功能设法让每个租户都感觉仿佛他们是唯一的用户,不具有对其它执行和用户环境的可视性.
3.
2.
2开发-运营转变传统IT不仅意味着明确的独立角色定义(网络、运营、开发等),通常还意味着这些角色通过各个独立的组织相互隔离.
这就使得开发和部署应用程序后要想弄清如何对其进行扩展变得十分困难.
而开发-运营这一理念则意味着将开发和运营的角色和责任融入进一个综合团队,既开发应用程序又负责将应用程序移动到生产环境并负责其持续运营.
其目的是从根本上提高市场响应速度,但是,这不仅意味着部署新工具和新技术,还意味着转变组织的IT文化和组织结构.
3-4云基础架构服务模型3.
2.
3开发周期如果开发-运营模型意味着以往角色的重构或组合,那么云模型则可能还意味着构建基础设施以及独立构建服务和应用程序之间新的角色分离.
传统地,应用程序是在其构建时与系统环境同时部署.
云模型则分成了前期的资源池建设和后期的应用服务部署两个分离的阶段.
在极端情况下,这意味着实际应用程序"架构"的实例化被延迟到了运行时.
同样地,以往以被动方式执行的运营,现在越来越多地在前期构建到了自助式自动化过程中.
3.
2.
4规模与速度云计算的大部分基本组成都是经典的IT原则、虚拟化、整合、自动化等.
主要区别也许是规模和速度,即应用这些技术和架构要素的规模与速度.
简单地说,传统IT环境可能包含数十个或数百个系统,而这些系统的配置每年只变化几次.
相比之下,云基础设施将多个架构组合成包含大量资源(服务器等)的、几乎是不断变化(每天甚至每小时)的共享池.
这通常要求在IT流程的实现和执行方式上有一个根本转变.
当然,与以开发人员为中心的公有云服务相比,企业云计算在这些云特征的实现上可能会有很大不同.
大多数企业云环境很可能对企业云中可以部署的代码类型设置限制.
由于逻辑和物理安全性问题以及软件许可,可能还实施其他限制.
企业云环境中的按需弹性供应程度可能需要某一级别的组织批准.
最后,企业云计算会极大改善服务的可用性并显著降低成本,尽管它比典型的公有云环境的限制性更强.
3.
3服务模型云计算建议:以前由IT提供的一切都将作为一种服务来提供("一切"即服务,通常称为"XaaS").
分层服务类型的概念不是十分严格,但业内通常将其划分为三个不同的环境和市场.
软件即服务(SaaS):"消费者"使用云基础设施上运行的应用程序.
SaaS提供商管理或控制整个软件和基础设施.
平台即服务(PaaS):消费者使用由PaaS提供商支持的编程语言和工具,然后控制部署的应用程序.
PaaS提供商管理或控制底层云平台,其中包括运行时执行环境之下的一切内容.
基础架构即服务(IaaS):消费者部署和运行任意软件,并开通处理器、存储、网络和其他基本计算资源.
IaaS提供商管理或控制底层物理云基础设施(即操作系统层之下的一切内容).
术语与概念3-5服务模型另外还建议了其他"X"即服务模型,但通常它们只是上述三种模型的特殊情况.
存储网络行业协会(SNIA)定义了一种数据存储即服务模型(DaaS),它有别于任何IaaS、PaaS和SaaS模型,并可由任何IaaS、PaaS和SaaS模型所使用.
该模型描述了当前的一组云存储服务,这些服务通常独立于其他服务(虽然Amazon确实将EC3与S3相关联).
事实上,数据即服务(DaaS,也称为云数据)概念产生的原因可能是,原始数据被提取并打包后可被云提供商执行广泛分析,从而产生额外的收益:即由供应商为其提供主要服务的诸多消费者的"数据下脚料"生成的这些信息本身成为了供应商的可用资源.
下图显示了三种主要服务(未添加DaaS).
图左侧的列表显示了各种服务级别的使用类型,而右边的一列列出了云服务中一些较常用的专门用法,并表明与更一般的服务类型的对应关系.
图3–2云服务模型层次结构图3的示意图中展示的云服务类型只是说明服务层次,表示不断增加的IT服务范围,并不是暗示更高级别的服务需要以较低级别服务的存在为前提.
另一方面,如果云服务以这种堆栈形式分层,那么就要适用典型的架构分层原则,即任何层只能与自己的直接下层通信.
例如,SaaS只应该从PaaS获取信息,而不应该从IaaS获取信息.
这意味着PaaS要向消费者提供他所需要的全部管理信息,消费者无需知道更低层的架构与实现如何,从而维持隔离.
由于这些服务模型中的每一个都需要某种程度的抽象以仅公开必要的可执行和管理能力,因此不要求每一层必须建立于另一层之上.
例如,想想这样一家公司,该公司将其人力资源软件需求(即,其IT应用程序需求,而不是其人力资源能力)进行外包:自然它会对HR软件的功能感兴趣,也需要管理(如监视、审计)HR的运营.
该公司对其人力资源软件的可用性(正常运行时间和灾难恢复)及其数据的安全性感兴趣,但通常对平台运行效率和物理资源分配或利用率不感兴趣.
3-6云基础架构部署模型理想情况下,任何云层的服务表示都应该以如下方式将底层实现抽象出来:该层的管理(或其服务的使用者)无需感知实现细节;但是,许多情况下需要进行优化以支持特定架构需要.
当这些优化无法通过通用接口提供时(如对跨磁盘物理数据组织的控制),则有必要专门设计较低层来支持任何特定云服务层的架构需求(例如,存储和基础设施都合并到PaaS内,而不是在IaaS上建立PaaS层).
综上而述,在任何给定层(软件、平台或基础设施)创建云服务模型都可能从另一层(如,在IaaS基础架构上部署PaaS)提供的服务获得潜在好处,但并不一定要将这些模型部署在一起,事实上,可能由于需要在支持层中进行优化所带来的限制而排除这种方法.
3.
4部署模型云计算可以分为4种不同的部署模型.
私有云—纯粹为单个组织运营.
社区云—由一个相关"社区"中的几个组织共享.
公有云—出售云服务的组织可以向公众或行业提供自身拥有的基础设施.
混合云—由两个或更多云(私有、社区或公有云,它们通过数据和应用程序可移植性联系在一起)组成的云.
大多数的企业云改革都将明确归为两个主要模型:1.
中小企业(SME)市场以及大型企业的特定项目或功能,可以托付给公有云服务提供商.
2.
寻求更低成本、IT灵活性,但仍关注数据所有权、服务的可靠性等的大型企业市场,也将越来越多地转向私有云模型.
大多数情况下,社区云适用于支持多个机构的政府服务部门,但是,有些社区云可能也适用于那些作为多个独立运营公司的服务机构的企业IT环境.
当然,逻辑上云计算的理想境界是混合云,在混合云中,很大一部分IT负载运行在内部服务上,但是这些应用程序可以弹性伸缩并悄悄地扩展到公有云提供商.
到目前为止,在建立混合云API和管理模型的全行业标准方面仍有许多重要工作要做,因此短期内,混合模型很可能局限在两个领域:1.
自治的、相对无状态的、低安全性的负载,如web内容服务或面向项目的数据处理2.
公有云和私有云都支持特定专有应用程序环境或云管理抽象的领域混合云一词指的是计算模型的组合.
使用混合云的最可能情况是:应用程序开发和术语与概念3-7术语测试在云环境中进行,但企业最初没有准备将任务关键应用程序放在云中,而是为生产部署保留了传统数据中心环境.
3.
5选择服务和部署模型这是一个针对云评价模型和从业人员指导的基本主题,然而,在本文档后面的架构功能中可以看到最初的区别.
3.
6术语虽然术语表中定义了很多术语,但是在进一步阅读本文档前还是应该对有些术语有一个清楚的理解.
3.
6.
1服务和服务产品不能将云服务与SOA(或任何其他)服务相混淆.
很多行业都使用术语"服务"和"服务产品",但它们在各行业中可能表达不同的内容.
就云来说,一个服务就是一个作为服务产品(由服务提供商)提供给使用者的打包的IT能力.
这些术语将以这样的语境(除非另有说明)出现在整个文档中.
3-8云基础架构术语云概念性架构4-14云概念架构与应用程序和中间件技术战略不同,云架构非常强调开通和运营,因此,在有关基础设施的文档中可以看到更多相关细节;但是,我们必须首先描绘一个非技术性的视图并考虑技术解决方案应满足的业务需求.
云概念架构旨在为提供云优势、遵循云基本特征并应对挑战奠定基础.
在描述概念架构之后,还描述了架构的约束、原则和准则,并简要介绍了用于将架构转向下一阶段—ORA云基础设施的技术和标准.
4.
1云架构需求为了让云概念架构专注于业务,而不是技术问题,这里概括说明业务需求.
并非所有需求都在概念架构中有简单的实际表示,但是,从这个业务需求清单开始来探讨各个阶段的架构开发仍是很重要的.
任何业务计算平台的最终目标都是利用计算机化应用系统来支持和增强业务的运行.
许多IT需求都源自上述目的,不过,这里重提一些一般需求,是因为云架构对这些需求有进一步提高.
云的常见特定业务需求包括以下:改善业务运营(这是一般的IT需求,但云应对此有所提高)能够有效度量业务活动支持业务伸缩随业务增长而扩展支持(提供或促进)创新提高效率/降低成本提高业务产品质量提高员工满意度和雇员素质长寿(TCO和灵活性满足未来需要)4-2云基础架构概念性架构视图支持业务敏捷性(顺应业务变化)技术灵活性(适应未来的技术改进)所有这些都以某种方式与提高利益相关方价值这一普遍目标潜在关联.
下面考虑云如何帮助满足这些需求.
云普遍带来的良机:抽象和隔离(通过SOA模型)可伸缩性潜能改善容量管理与利用率第三方云服务("外包"服务)特别带来的良机:通过消除分散注意力的IT活动,使企业专注于其核心业务活动.
消除非核心活动是常见的业务战略,这一直是IT(及其他)外包的理由.
重构成本.
知识—有权利用知识产权和更广泛的经验和知识.
与第三方签订合同,通过使服务更具可预测性和防止不佳的SLA而改善可管理性(经济补偿手段).
利用人才业务专长更多选择规模经济促进变革—外包商成为变革代理商责任—组织可以选择将内在责任转移给组织核心竞争力之外的特定业务流程或服务.
下面的概念模型满足了许多这些需求,同时与云有关的更广泛的领域(以及Oracle云技术战略)也提供了与标准化、整合/合理化及简化有关的优势.
云架构及其相关领域在简单性、减少技术和流程的多样性等方面提供了实实在在的好处,使组织能够将精力集中于他们的业务,而不是IT.
4.
2概念架构视图Oracle云概念架构关注三个主要区域:所有各类设计时和运行时消费者接入云的接口,归入接入层(Accesslayer)云管理功能,归入管理层(Managementlayer)被用于消费资源的可部署实体,归入服务层(ServiceLayer)底层计算资源和应用程序资源未被视为概念模型的组成部分,但它们会出现在云基础设施文档中的资源层中.
云概念性架构4-3概念性架构视图下面图4–1显示了这三个层和关键子组件以及支持元素(监视、安全性和虚拟化资源),但是在本概念阶段未考虑它们之间的关系.
图4–1云概念架构与n层架构模型非常类似,该概念架构视图的每一层旨在满足主要需求,同时仍然呈现一种松散耦合的架构,以满足诸如可伸缩性和高可用性等主要非功能性需求.
要理解这一架构,重要的是将"运行应用程序的云"(即云本身)与"云中运行的应用程序"(即云服务、可部署实体或虚拟数据中心)区分开来.
这一架构很大程度上以"云"为中心,它指的是将能力、资源和服务协同工作为开发人员、最终用户和应用程序所有者提供IaaS、PaaS和SaaS服务.
它是"云中运行的应用程序"的基础设施.
因此,该视图主要考虑了对应用程序所有者、云运营商和开发人员来说重要的云自身应具有的特征,而没有考虑云应用程序最终用户.
此概念图强调了该架构的几个主要考虑事项:可部署实体可由多种云服务模型组成.
明确区分云管理责任和资源管理的责任.
突出监视、安全和虚拟化的关键支撑元素.
4-4云基础架构概念性架构视图在下面的章节中,我们将探讨每一层的详细情况.
4.
2.
1访问层访问层支持最终用户、开发人员和应用程序所有者访问服务层(和托管的云应用程序)以及云管理接口.
该层类似于传统n层应用程序架构模型的表示层,具有类似的功能.
但是,与传统n层架构不同的是,该层还通过云管理接口公开许多应用程序管理功能.
4.
2.
2管理层云管理层向开发人员和应用程序所有者开放设计、开通和管理云服务所需的云逻辑.
它还为云运营者提供管理底层云基础设施的控制平面.
同样与传统n层架构模型相比,可以将该层视为企业应用程序的业务逻辑和管理平面的组合.
Oracle预见在云管理层应主要关注以下五个方面:业务管理,涵盖云业务管理的方方面面.
运营,支持云基础设施的运行时能力.
安全和策略管理,支持云基础设施的安全和策略管理需求.
设计时,支持模型管理和设计时工具.
编排,提供编排云基础设施中的主要管理活动所需的能力.
以上所述参见图4–2.
图4–2云管理层需要注意的是管理层位于访问层和资源层之间,作为所有通信的中介.
来自访问层的通信不能直接与资源层交互.
云概念性架构4-5概念性架构视图对于向云计算用户提供的服务,这些用户无需具备云中支持这些服务的底层基础架构方面的知识或专长,也不需要控制这一底层基础设施.
随着企业将其现有的IT基础设施和资源迁移到共享云范式,云实现者有必要提供统一的API,企业可以使用这样的API对云进行裁剪以适合自己的业务流程和经济模式.
随着IT部署变得越来越复杂,基础设施资源的抽象也越来越牵涉到合规性及配置的处理考虑.
此外,这种抽象让消费者在没有任何重要管理员参与的情况下,既能以自助的方式获得他们正合需要的正确的服务,又能操纵控制这些服务.
基础设施提供商通过这样的API支持其客户进行以下操作从而为客户提供服务:浏览包含逻辑服务单元的定义和元数据的模板将模板部署到云中并按需构造IT拓扑结构对资源执行操作(如ONLINE、OFFLINE、进行备份等)ORA云基础设施文档更详细地介绍了管理层.
4.
2.
3服务层如前几节所讨论的,服务层包含由云的基础设施、平台和/或软件服务构建的可部署实体.
可部署实体是消费者可以与之交互的、有用的聚合资源的实例(请参阅下面的4.
3.
2节).
4.
2.
4资源资源层有两个目标:聚合并管理物理或虚拟资源.
向管理层公开虚拟或物理资源池,以便它们可以被编排在云服务中.
物理资源和虚拟资源可能是各种简单或复杂的对象.
例如,可能是IaaS云中虚拟服务器或挂载的文件系统这样简单的对象.
也可能是集群化J2EE容器或消息队列这样复杂得多的对象.
资源层还代表混合云与传统资源的重要集成点.
4.
2.
5云消费者图4–1的概念架构图中的云消费者代表使用云功能的所有类型的用户.
除了访问层(使用者通过该层访问云)中讨论的内容,云服务的使用超出了本文的范围.
一种特殊的云服务消费(以及同步开通的开通)情况将以4.
2.
6节描述的云代理的形式出现.
4.
2.
6云代理商云代理代表一类特殊的云提供商和云消费者.
代理商表现出云提供商的许多架构特征,特别是管理层方面的特征,但通常不包括资源层的内容.
代理商消费其他云提供4-6云基础架构架构概念商提供的云服务作为自己的资源,然后将这些资源(可能以修改后的形式)再提供给自己的消费者.
和任何其他业务方案一样,代理商必须提供某种附加价值,从提高其他提供商服务的市场营销能力/可见性,到通过编排其他提供商产品同时可能融入自己的服务而获得独特的、高价值服务组合.
4.
3架构概念为了开发全面的云架构,首先必须了解云架构提供的能力.
在这种概念层面上,能力源自声明的预期业务优势以及前面概括的云特征(更详细的技术功能将在随后的云基础设施文档的架构视图中描述).
能力描述了架构需要提供些什么,并用于创建本章中的概念模型.
概念性能力将被用于进一步开发在此架构中描述的重要功能性和非功能性需求.
为了完成概念架构描述,本章最后给出一组所有云实现都必须遵守的架构原则.
4.
3.
1虚拟化在云概念出现之前,通常按照以下陈述来定义虚拟化:"虚拟化支持在一个主机上运行多个操作系统环境.
每个环境包含操作系统和所有打包在一起的支持进程.
虚拟环境可以在物理计算机之间进行部署和迁移.
"在云范式中,有可能对传统计算机系统的许多元素进行虚拟化,而不仅仅是处理器虚拟化.
示例包括存储虚拟化、操作系统虚拟化,甚至应用程序虚拟化.
通常,虚拟化的部分是系统的功能接口,而不是管理接口.
4.
3.
2可部署实体尽管很多人谈论云服务模型时都将其视为严格的IaaS、PaaS或SaaS,但现实情况是,大多数企业级应用程序将包括一个或多个服务模型(甚至可能是非云服务和资源)的元素.
例如,J2EE应用程序可以在PaaS服务上运行,同时它也可以通过非云存储资源(也许是企业SAN)或运行在云资源上的数据库来访问数据,这些云资源可以是数据存储即服务(Data-storageasaService)或数据库即服务(DBaaS).
某些应用程序可能是严格的SaaS应用程序,但可能需要提取数据以运行季末批处理进程,而季末批处理进程将在IaaS解决方案上运行.
为涵盖以上所有的可能性,Oracle使用了称为可部署实体的概念.
可部署实体是一个或多个云服务(可能是静态资源)及其伴随元数据的集合,集合中的这些成员在云基础设施中协同工作以提供最终用户计算.
从更高的逻辑层面看,可部署实体可能包括:可租售服务(负载)云概念性架构4-7架构概念云IaaS、PaaS或SaaS资源像公司存储区域网络(SAN)这样的非云IT资源资源模板服务合约(元数据)运行时策略部署脚本与数据配置信息虽然可部署实体是一个概念,而不是产品,但是,可在虚拟数据中心从逻辑上看到它们的部分功能(Oracle的API规范中的vDC或DMTF中的可租售服务),也可在(由OracleVirtualAssemblyBuilder产品生成的)组合件内实际看到它们的部分功能.
4.
3.
3快速应对在传统计算模型中,企业数据中心可能有100台服务器,这些服务器可能每年配置/重新配置两次.
可以手动处理或借助脚本自动处理这200次变更.
而在新的"云模型"中,可能有更多的虚拟服务器,并且为了适应负载有可能需要每小时对计算机进行重新配置.
传统的手动配置管理流程和系统将无法跟上这样的变化速度.
4.
3.
4对构建时和运行时的丰富支持与传统部署环境不同,云需要提供能支持应用程序构建时(开发环境)和应用程序运行时(部署环境)的功能和基础设施.
图4–3构建时与运行时角色构建时特征可能包括:标准化打包工具和格式服务目录部署和控制API4-8云基础架构架构约束调试和验证云服务目录主要运行时特征可能包括:计量监视容量规划与管理SLA实施4.
3.
5对各种角色的支持云基础设施需要支持多种类别的角色:云服务提供商:云计算基础设施的运营商和提供商.
该类别中的角色将包括云构建者和云运营商.
云服务开发人员:这些角色负责设计、创建、打包和部署云应用程序以供最终用户使用.
此类别中的典型角色包括服务开发人员、应用程序所有者和服务部署人员.
云服务消费者:云计算的最终用户.
这些角色包括云应用程序的实际用户以及应用程序所有者.
4.
3.
6异构资源管理云架构应该能够支持各种资源池和池管理者,无论是不同类型的资源(计算、存储等),不同的资源供应商,不同的部署模型(公有或私有),还是来自同一供应商的不同产品.
这些应基于不同的服务质量属性(性能、成本、可用性等),并且都应涵盖在与质量和计量成本相对应的服务定义中.
4.
3.
7多区域能力与任何典型IT环境都能跨多个物理位置一样,云架构也将如此.
但是,与当前IT环境不同,云管理需要感知其物理数据中心的差异以便相应部署应用程序.
这点对用户可能是完全隐藏的(通常会在SaaS或PaaS云中),也可能通过部署接口作为配置选项而公开.
4.
4架构约束在Google、Amazon和其他应用中所见到的那种超大规模计算,需要特别关注架构.
具体而言,这种规模的计算需要数据、基础设施、平台和应用程序的并行化.
传统的事务管理数据库遵守ACID(原子性、一致性、隔离、持久性)原则.
在这种数据库的情况下,水平伸缩需要跨多个节点(一个集群或网格内)分布数据.
有许多技术可以实现数据分布,常用的有表或列划分(在关系数据用语中使用"分区"这一术语,但在这里的讨论中该术语有不同的含义),或按行分布(使用"水平分云概念性架构4-9架构约束区").
遗憾的是,这会导致可用性问题:当一个节点出现故障时(在多节点系统中可能经常发生这种情况)就出现"分区"现象.
传统集群需要冗余和数据复制以避免这种分区,然而,这种方法会产生很大的开销,在非常大的分布式系统中,这种方法变得不切实际.
有时,一致性是绝对必要的(例如通过AMT进行的财务交易),但也并非总是这样,也可以通过BASE原则(基本可用、软状态,最终一致)采用另一种方法.
BASE在逻辑上与ACID相反,在多节点系统中,它牺牲了一致性保证来支持可用性.
"最终一致性"这一措辞指的是一种乐观的信念,即:随着时间的推移,变更将通过复制和分发的系统进行传播.
以这种方式伸缩应用程序的关系数据库方法包括乐观锁定(参见OCC)和分片.
乐观锁定经常可以应用在具有低数据争用的环境中,但如果发生冲突,反复重启事务的开销会大大影响性能.
另一方面,分片是表数据跨schema的多个实例进行分布.
分片有一个优点,对大型分布表的负载搜索可以拆分到多个节点,这与数据的基本水平分区不同,后者被限定于单个schema.
这两者的主要架构区别是,水平分区需要服务器的紧密耦合,而分片运用的是无任何共享的方法:一旦分片,各片可以跨多个服务器各自存在于相互分离的逻辑schema实例中,甚至有可能在地理上也是分离的.
因此,分片对地理上分布的应用程序是很有用的,在这种情况下,若不使用这种方法,数据中心间的网络带宽将会成为瓶颈.
但是,分片需要schema实例间的复制机制,因此,表与应用程序需求保持严格同步.
这意味着对分片系统需要做更谨慎的架构选择.
理想的选择是那些数据"近似只读"的架构,也就是很少进行更新且以批处理方式进行更新的架构.
在数据变更比较频繁的情况下,也许可以动态复制表,但是,这种方法会消减某些优势.
4.
4.
1Brewer的CAP理论EricBrewer提出(在有关分布式计算原则的ACM论文集中首次提出),在开始设计和部署分布式环境中的应用程序时,有三个以特殊关系存在的核心系统需求.
这三个需求是:一致性、可用性和分区容忍性(CAP).
人们早已十分了解一致性和可用性(参阅其他ITSO文档),但大规模计算要求并行化,这导致了计算资源的分区(在这里,分区指的是意想不到的网络隔离或其他节点故障),并引发了分区容忍性问题(Gilbert和Lynch将分区容忍性定义为"除了整个网络的故障外,其他的故障都不能导致系统无法正确响应").
从根本上说,Brewer认为,不可能总是具备全部三个特性(一致性、可用性和分区容忍性),从统计学上说,在大规模并行/分布式系统中,节点故障(分区)是不可避免的,分区容忍性可能比最终一致性更重要.
也就是说,有时宁愿牺牲一些数据一致性,转而保证性能或避免由单个节点故障引起的完全中断.
4-10云基础架构云案例/用例因此CAP原则要求针对系统数据的各个方面在ACID和BASE中作出选择,通常,不同的业务需求会要求应用各种方法满足特定需要.
最后要说明的是,选择满足最终一致性会把一致性问题推给客户端,它们需要在自己的应用程序中进行一致性检查.
4.
5云场景/用例在不考虑独特业务需求的条件下,这里的几个典型的云使用场景都既能提供优势又易于实现.
4.
5.
1云爆发大多数IT部门都要投入可观的成本与努力为峰值负载(如市场营销活动带来的大量订单)做准备,而这些额外容量中的大部分在非峰值时间都处于空闲状态.
云爆发是一种技术,它允许公司以适合"常规负载"的容量运行自己的IT基础设施,而在峰值负载期间利用外部的共享云环境来补充自己的计算资源.
采用这种方法,公司能够大大减少资本支出,只需为峰值负载时段使用的云资源进行支付.
特别是,通过让资本成本与云利用率之间达到最佳平衡,消费者将受益于这样的安排.
企业虽然最初保留了拥有自己IT资源的独立性,但随着时间的推移,可能会发现云成本模型如此具有吸引力,于是会将这种方法视为一种迁移战略.
乍一看,似乎是满足公司峰值需求所需的超额容量的成本只不过转移到了另一个业务实体;然而,随着外部云拥有更多租户,(各租户独有的)负载峰值的效果渐渐平缓下来,达到一个相对稳定的使用状态.
云爆发的主要挑战是建立最适合云的应用程序架构(也就是说可在高度分布式环境中无缝操作).
另一个重要的考虑因素是"爆发"应用程序需要的数据必须已经在云中.
为避免长时间的启动延迟,云必须整装待发,随时可以运行.
尽管这些数据不会永久占用CPU和内存资源,但即使它们在不使用时也始终占用存储资源.
另外,还必须将数据变更同步复制到云中,这也将占用网络资源.
4.
5.
2开发和测试或许这些用例中最常提及的一个就是按需开发和测试环境.
从多个专用和不断重新布线的开发环境转移到可动态管理池化资源的环境,这一简单举措会带来几个数量级的TTM(上线时间)改善.
这无疑会将采购和部署新系统所用的时间由可能的数月减少为数天或数小时.
4.
5.
3弹性伸缩开通IT环境需要的成本和时间,以及为了承担峰值负载而开通资源所带来的成本增加(会造成整体利用率降低),一直是IT面临的一个挑战.
通过公共动态可配置共享资源来预先开通资源可实现按需伸缩.
当然,这假设各种峰值负载不会同时并发.
因此,云计算是一种新的"整合".
架构原则与准则云概念性架构4-114.
5.
4整合与特定服务应用程序有关的资源的成本管理一直是IT面临的一个挑战.
专用的烟囱资源(每个应用程序占用专用的超额容量)导致低下的整体利用率和高昂的成本.
长期以来,企业致力于通过整合项目将多个应用程序迁移到整合基础设施上.
而云计算正是这种企业IT战略的顺理成章的延伸,只有云计算才提供了机会让我们可以将更多的应用程序、数据库、服务等整合到共享基础设施资源池.
很多规划和实现都是相同的.
必须首先清点应用程序来确定它们的兼容性和亲和性(类似的技术要求、业务优先级等),然后必须实施项目将这些物理上相互隔离的服务迁移到虚拟资源上.
4.
5.
5灾难恢复任务关键应用程序需要有用于灾难恢复的应急预案,这往往不只是出于商业目的,也是为了满足监管要求.
这些架构不仅需要额外资源,而且还需要能够同步数据、迁移控制和最终恢复原始生产的计划.
即使成本高昂的热备份设施能够被证明是合理的,但仍然存在一些可能同时危及生产和灾难恢复站点的故障事件.
云战略所提供的灾难恢复策略,不仅可以降低成本,而且有可能提高整体可靠性水平.
基于云的灾难恢复可能更多地使用动态开通的共享私有云资源,也可能依托公有云提供商,或利用混合了公有和私有云资源的混合云,混合云具有成本更低及更可伸缩的故障转移潜力.
当然,使用公有云进行灾难恢复可能意味着为了预先开通数据和应用程序资源而要付出显著的基本成本.
4.
5.
6临时负载也许讨论最多的一个云计算企业商机是将峰值负载或临时负载从专用的企业(私有云)基础设施分流给公有云提供商.
与灾难恢复用例类似,企业应该可以扩建以支持通常的平均负载情况,同时使用混合云模型来应对高峰负载.
在高峰负载不可预测并且可能很大的情况下,这种方法尤其具有吸引力.
与灾难恢复情况相同,这可能需要预先开通应用程序和数据,从而导致同步方面的挑战.
当然,某些峰值负载(例如年度财务决算)可能更具可预测性.
此外,云资源,无论是公有云还是私有云,都可以构成承载临时项目带来的高负载的理想平台.
4.
6架构原则与准则本节包含成功的云架构必须遵循的高级架构原则.
这里以云架构必须遵守的规则来说明这些原则.
对于每项原则,这里指出了需要这一原则的理由.
此外,还给出了一个或多个含义,意在指明满足该原则可能涉及的问题.
在各种粒度级别使用原则来定义必须遵守的规则,以便保持在架构约束之内,同时符合标准,并最终创建一个成功的架构解决方案.
这一云基础架构(CloudFoundationArchitecture)文档提供了最高级别(最粗粒度)的原则,而在云基础设4-12云基础架构架构原则与准则施(CloudInfrastructure)文档中可以找到更多特定于实现的具体原则.
准则与原则类似,但它们并非是所有情况下所必须遵循的,它们也可能只是建议(在架构治理中可能不会严格跟踪准则).
下面的列表并不是要给出一组详尽的云架构原则;而是为制订更具体的云架构提供一个起点.
4.
6.
1符合标准原则符合标准说明云接口和格式必须符合相关的行业标准.
原因必须符合标准以确保云架构所有层面(即开发、运营和运行时使用)的互操作性.
含义必须认真评估和选择标准,以便顺应特定架构的最终目标.
为避免以互操作性为代价的单点解决方案,架构师必须十分了解新兴标准.
4.
6.
2感知简单性原则感知简单性说明系统必须只呈现执行每个特定功能所必需的信息(接口等).
理由"一切都应尽可能地简单,而非更简单"(阿尔伯特·爱因斯坦).
所有计算系统本身就已经很复杂了,但不需要使其更复杂(即难以了解或使用).
为实现可伸缩性,云架构必须避免复杂性造成的开销.
含义执行特定功能所不必要的复杂性(或细节)应从消费者一方抽象出来.
为了向不同的消费者提供系统功能,可能需要进行许多抽象.
为简化许多任务(例如资源扩展)可能需要自动化.
应该用策略取代常规问题(例如用"超出增长/开销阈值时发出警告"取代"您需要多少磁盘空间")云概念性架构4-13架构原则与准则4.
6.
3可见性原则可见性说明架构应该对云消费者和提供商所要求的各种资源使用情况的各个方面提供监视.
理由如果系统不可测量,也就不能进行管理.
含义按消费者应用程序实例来隔离资源的使用,这将对底层系统带来挑战(例如,对于许多应用程序以及许租户所共享的一个物理总线,如何确定该物理总线上单个消费者应用程序的磁盘IO).
在共享的虚拟化环境中分析应用程序资源占用可能会产生错误的结果(例如磁盘IO等待时间有可能因共享环境中的其他用户而失真).
除了单纯的资源使用数据,还可能期望系统提供其他"智能"选项.
4.
6.
4透明性原则透明性说明云提供商承诺的任何可靠性、可用性、安全性和性能都必须是可核查的.
理由因为需要抽象许多细节(如物理服务器数量、位置等),因此云的成功很大程度上依赖于信任.
业务连续性(RASP等)非常重要,它的参数必须完全公开.
含义考虑到消费群的潜在变化,并且每个使用者都有不同服务级别要求,因此必须不断更新复杂的风险模型并确定必要的措施.
为了避免因公有云提供商的自我监督而可能产生的虚假声明,可能需要独立的核查机构.
4.
6.
5原地失败原则原地失败说明可用性不应受到不可避免的硬件故障的限制.
理由在规模极大的情况下,不冒与硬件更换有关的有可能延迟(由于修复、更换和重启)的风险,而是通过软件手段(忽略、取消选择、或弃用故障节点和动态重新路由工作),也许可以最有效地实现可用性.
含义水平扩展、资源池化与服务器群.
4-14云基础架构技术与标准4.
7技术与标准以下是相关云标准的简短摘要.
4.
7.
1美国国家标准与技术研究所(NIST)NIST—云计算定义:http://csrc.
nist.
gov/groups/SNS/Cloud-computing/Cloud-def-v15.
docNIST定义了四种云部署模型:公有云(向公众或大型行业集团提供的云基础架构)私有云(单纯为某个组织运营的云基础架构)社区云(由几个组织共享的云基础架构)混合云(合并了两个或更多云的云基础架构)4.
7.
2DMTFDMTF—云计算标准http://dmtf.
org/standards/Cloud提供角色、服务模型和参考架构的说明.
DMTF已经将自己的云标准工作过渡给一个工作组,预计将于2012年初发布标准的IaaS自助式管理接口.
4.
7.
3存储网络行业协会(SNIA)http://www.
snia.
org/SNIA已创建了一个标准云存储接口:用于数据存储即服务(DaaS)的云数据管理接口(CDMI).
CDMI是到云的数据路径,也是通过标准化元数据来管理数据和数据需求的控制路径.
备份、归档和保留等高级数据服务通过该接口实现了标准化.
SNIA计划于2011年晚些时候提交CDMI作为国际标准.
存储客户端使用者可以直接连接数据(寻址物理存储资源),也可以借助各种标准化和专用协议(如HFS、WebDAV、SQL*net等)通过逻辑包含表示连接数据.
客户端的云存储管理可以是独立的,也可以作为整个云管理的组成部分.
4.
7.
4其他OGF—开放云计算接口(OCCI)对云管理模型和协议实现标准化主要由大学和科研院所实现4.
7.
5云APIOracle云API云概念性架构4-15技术与标准请参阅http://www.
oracle.
com/technetwork/topics/Cloud/oracle-Cloud-resource-model-api-154279.
pdf(不久将会根据它在12c中的实际实现进行更新).
Oracle云API为基于Oracle解决方案体系的IaaS云消费者定义了一个应用程序编程接口(API).
基础设施提供商通过这个Oracle云API支持其客户进行如下操作从而为他们提供服务:浏览包含逻辑服务单元的定义和元数据的模板将模板部署到云中并按需构造IT拓扑结构对资源执行操作(如ONLINE、OFFLINE)执行资源备份这里提出的RESTful(表现状态传输)API侧重于资源模型及其属性.
此云API的规范包括:适用于所有请求及响应、错误消息、公共资源属性的共同行为资源模型,它们描述了请求和响应中使用的JSON数据结构可以发送给云资源的请求以及预期响应.
共同行为不会针对每个资源进行描述4.
7.
6MapReduce和HadoopMapReduce和Hadoop是云的典型应用程序.
这两个应用程序本身并不是"云"(一个常见的误解),但它们却是最适合于大规模并行云基础架构的、高度可伸缩的软件架构的很好的示例.
MapReduce是Google发明的一种软件框架,用于解决跨大规模数据集的搜索问题.
它采用了专为大规模松散耦合分布式计算设计的并行应用程序架构,对由商用(廉价)计算机集群运行的大型数据集进行处理.
Hadoop是一个适用于数据密集型分布式应用程序的开源软件框架.
它让应用程序能够操纵数千个节点和数PB的数据.
Hadoop由Google的MapReduce和GoogleFileSystem(GFS)论文获得灵感.
Hadoop是用Java编程语言编写的Apache项目.
Yahoo是该项目的最大贡献者,它在自己的全部业务中广泛使用Hadoop.
Yahoo正在为企业采用而发起一个侧重于创建基于Hadoop的产品的商业组织.
该合资企业将被命名为"HortonWorks".
4-16云基础架构技术与标准ORA相关内容5-15ORA密切关系在本文档的开始我们介绍OracleIT战略(ITSO)作为帮助组织计划、实施和管理企业架构和IT计划的系列文档和支持宣传资料.
ITSO模型的核心是Oracle参考架构(ORA),如图5–1所示.
图5–1Oracle参考架构ORA是一个跨越整个Oracle技术空间的单个统一参考架构,对图中的每个元素,它定义了以下架构特征:架构概念原则与准则架构视图组件下钻产品对应关系5-2云基础架构ORA水平层ORA云视角文档提供了这些架构特征特定于云的定义(依赖于与更一般的IT架构一致的通用ORA核心定义),从而扩展ORA以支持云企业技术战略(ETS).
"ORA云基础"文档着重介绍了云概念、术语定义、原则和准则,以及标准.
以下几节简要介绍ORA模型的每个元素的云架构角色.
5.
1ORA水平层ORA模型的水平层对应于任何现代架构的最常见层.
每一层都依赖于它下面的层,体系从下向上的每一层都为迈向提供业务服务这一最终目标提供了越来越精炼的功能.
一般情况下,ORA模型的水平层与云服务模型相对应,如图5–2所示.
图5–2服务模型与ORA间的对应关系图5–2中从左到右的箭头指示特定的云部署模型支持ORA架构分组的机会(例如PaaS可能支持信息管理、应用程序基础设施和/或交互).
从右到左的箭头显示能够提供云部署模型中功能的ORA模型的更具体的元素.
但是,与ORA体系不同,云服务模型彼此不相互依赖(如本文档3.
3节所述).
这意味着,ORA的任何一层都可作为云服务提供,但是它可能依次(上方和下方)受ORA模型的传统架构战略的支持.
例如,SaaS云可能受ORA信息管理描述的传统架构方法的支持,并且可通过ORA交互进行访问.
5.
1.
1共享基础设施ORA体系的底部与云计算有着最明显的联系,很显然这是IaaS主要关注的区域.
然而,共享基础设施有多种形式,其中的一些不一定符合云的基本特征,所以ORA核心架构提供了一个更广泛、更通用的定义.
ORA相关内容5-3支持的功能5.
1.
2信息管理信息管理可以由诸如数据存储即服务、数据库即服务、信息即服务等云数据为主题的许多变种所满足.
5.
1.
3应用程序基础设施应用程序基础设施主要包括平台即服务(PaaS),但是,其包含的业务流程和业务服务扩展了该层的范围,使其包括了软件即服务及其相关的业务服务变种.
5.
1.
4交互ORA交互描述了到业务应用程序和服务的人机接口的架构战略.
人机接口的架构主要由云应用程序所满足(如到业务应用程序的web接口),不过,类似手机、电视等其他传送渠道可能由云基础架构和/或平台提供.
5.
2支持的功能ORA模型的垂直层代表对任何系统的支持功能.
三个ORA垂直层中的两个(管理和安全)在云概念模型中有相应表示,而云上下文中的开发并非足够独特,因而未包含于本文档中.
支持能力5-4云基础架构总结6-16总结云是一个源自托管和SOA的广泛而复杂的IT战略,诞生于Google和Amazon的简单服务激增.
如果云要成为IT的下一个范式转变,那么它需要沿着通向效用计算的乌托邦之路满足更广泛的企业应用需要.
本文档除了提供云概念的基本定义,还尝试指出通过使用云而在满足IT业务使用者需要(并解决问题)方面带来的好处.
这一方法产生了以业务为重点的非技术性概念架构,它为后续的ORA云基础设施文档提供了基础.
6-2云基础架构延伸阅读A-1A延伸阅读OracleIT战略系列包含大量文档,提供了许多技术方面的见解和指导.
特别地,您可能对下面的文档感兴趣:ORA云基础,该文档是构成Oracle参考架构的系列文档的组成部分,它包含在OracleIT战略(ITSO)文档集中.
虽然本文档作为独立文档编写,并且包含了介绍云主题的足够背景信息,但它还是假设读者熟悉支持概念.
A.
1相关文档Oracle参考架构(ORA)由一套文档构成,每个文档针对Oracle计算环境的一个具体方面.
该套文档介绍事件驱动架构的各个方面.
参考架构材料还包括以下相关的文档:ORA监视与管理—该文档为设计满足现代IT环境需要的管理和监视框架提供了一个参考架构.
ORA安全性—ORA安全性文档描述了安全性的重要方面,包括身份、角色和授权管理,身份验证、授权和审计(AAA),以及传输、消息和数据的安全性.
A.
1.
1建议的预先阅读为了更充分理解本文档建立的概念,建议您预先阅读下列文档.
ITSO概述—通过该文了解ITSO和ORA的范围和文档方法.
6-2云基础架构术语表为便于参考,这里给出了云专用术语和缩写词.
有关各种ORA文档中所用的其他术语,请参阅ORA主要术语表.
CAPEX表示资本支出的常用业务术语.
企业将钱花在有形资产上时将发生资本支出.
LAMPLinux、Apache、MySQL和PHP(Perl或Python).
一个非常普及且高度可移植的免费开源服务器软件体系,它组成了通用web服务器的核心组件.
NUMA非一致性内存访问:多处理系统中的一种计算机内存设计,它利用了这样一个事实,即:处理器访问本地内存比访问分配给另一个处理器(或与之共享的)的内存要快.
OPEX表示运营支出的常用业务术语.
运营支出表示业务的运行成本.
SMP对称多处理:一种计算机硬件架构,在该架构中,两个或多个CPU共享同一内存,并由同一操作系统控制.
乐观并发控制(OCC)也称为乐观锁定,是一种并发控制方法,它假定可以在互不影响的情况下完成多个事务,并且还假定因此无需锁定事务影响的资源就能继续执行事务.
在每个事务提交之前,它会验证没有其它事务修改了自己的数据.
如果检查结果表明存在冲突的修改,则回滚正在提交的事务.
[1]OCC通常用在低数据争用环境中.
当冲突很少时,无需锁管理开销就能完成事务,并且不存在需清除其他事务锁造成的事务等待,与其他并发控制方法相比这可以带来更高的吞吐量.
但是,如果经常发生冲突,反复重启事务带来的开销会损害性能;在这种情况下,其他并发控制方法则有更好的性能.
甲骨文(中国)软件系统有限公司北京远洋光华中心办公室地址:北京市朝阳区景华南街5号远洋光华中心C座21层邮编:100020电话:(86.
10)6535-6688传真:(86.
10)6515-1015北京上地6号办公室地址:北京市海淀区上地信息产业基地,上地西路8号,上地六号大厦D座702室邮编:100085电话:(86.
10)8278-7300传真:(86.
10)8278-7373上海分公司地址:上海市黄浦区天津路155号名人商业大厦12层邮编:200021电话:(86.
21)2302-3000传真:(86.
21)6340-6055广州分公司地址:广州市天河区珠江新城华夏路8号合景国际金融广场18楼邮编:510623电话:(86.
20)8513-2000传真:(86.
20)8513-2380成都分公司(川信大厦办公室)地址:成都市人民南路二段18号四川川信大厦20层A&D座邮编:610016电话:(86.
28)8619-7200传真:(86.
28)8619-9573成都分公司(高新国际广场办公室)地址:成都市高新区天韵路150号高新国际广场D座四楼18-19,22-25单元邮编:610041电话:(86.
28)8530-8600传真:(86.
28)8530-8699大连分公司地址:大连软件园东路23号大连软件园国际信息服务中心2号楼五层502号A区邮编:116023电话:(86.
411)8465-6000传真:(86.
411)8465-6499济南分公司地址:济南市泺源大街150号,中信广场11层1113单元邮编:250011电话:(86.
531)8518-1122传真:(86.
531)8518-1133沈阳分公司地址:沈阳市沈河区青年大街219号,华新国际大厦17层D单元邮编:110016电话:(86.
24)23961175传真:(86.
24)23961033南京分公司地址:南京市玄武区洪武北路55号,置地广场19层1911室邮编:210028电话:(86.
25)8476-5228传真:(86.
25)8476-5226杭州分公司地址:杭州市西湖区杭大路15号,嘉华国际商务中心702室邮编:310007电话:(86.
571)8717-5300传真:(86.
571)8717-5299西安分公司地址:西安市高新区科技二路72号,零壹广场主楼1401室邮编:710075电话:(86.
29)8833-9800传真:(86.
29)8833-9829福州分公司地址:福州市五四路158号,环球广场1601室邮编:350003电话:(86.
591)8801-0338传真:(86.
591)8801-0330重庆分公司地址:重庆市渝中区邹容路68号,大都会商厦1611室邮编:400010电话:(86.
23)6370-8898传真:(86.
23)6370-8700深圳分公司地址:深圳市南山区高新南一道飞亚达大厦16层邮编:518057电话:(86.
755)8396-5000传真:(86.
755)8601-3837甲骨文软件研究开发中心(北京)有限公司地址:北京市海淀区中关村软件园孵化器2号楼A座一层邮编:100094电话:(86.
10)8278-6000传真:(86.
10)8282-6455深圳分公司地址:深圳市南山区高新南一道德赛科技大厦8层0801-0803单元邮编:518057电话:(86.
755)8660-7100传真:(86.
755)2167-1299甲骨文亚洲研发中心-上海地址:上海市杨浦区淞沪路290号创智天地10号楼512-516单元邮编:200433电话:(86.
21)6095-2500传真:(86.
21)6095-2555Oracle参考架构云基础架构2011年11月公司网址:http://www.
oracle.
com(英文)中文网址:http://www.
oracle.
com/cn(简体中文)销售中心:800-810-0161售后服务热线:800-810-0366培训服务热线:800-810-9931欢迎访问:http://www.
oracle.
com(英文)http://www.
oracle.
com/cn(简体中文)版权2011归Oracle公司所有.
未经允许,不得以任何形式和手段复制和使用.
本文的宗旨只是提供相关信息,其内容如有变动,恕不另行通知.
Oracle公司对本文内容的准确性不提供任何保证,也不做任何口头或法律形式的其他保证或条件,包括关于适销性或符合特定用途的所有默示保证和条件.
本公司特别声明对本文档不承担任何义务,而且本文档也不能构成任何直接或间接的合同责任.
未经Oracle公司事先书面许可,严禁将此文档为了任何目的,以任何形式或手段(无论是电子的还是机械的)进行复制或传播.
Oracle是Oracle公司和/或其分公司的注册商标.
其他名字均可能是各相应公司的商标.