OpenStack(PDF/WORD)

目标读者 ................................................................................................ 1

本书是如何组织的 .................................................................................. 1

我们为什么及如何写作此书 .................................................................... 2

方法论 ................................................................................................... 4

在云计算技术的“淘金热”中，OpenStack无疑是作为领导者出现的，在云

自助服务和基础设施即服务(IaaS)的市场，为形形色色的>组织发现更大的

灵活性，并加速这个市场。当然，要想知道它的全部好处，云必须要有正

确的架构设计。

一个完美的云架构可以提供一个稳定的IT环境，可轻松访问需要的资源、

基于使用的付费、按需扩充容量、灾难恢复、安全等。但是一个完美的云

架构不会拥有魔法般的自己构建。它需要对多种因素进行精心思考，无论

是技术的还是非技术的。

对于OpenStack云部署来说，还没有所谓的那个架构是“正

确”的。OpenStack可用于多种目的和场景，而每一种都有着自己独特的需

求和架构特点。

本书的初衷是着眼于使用OpenStack云的通用用例(即使不那么通用，至少

是作为好的案例)以及解释什么问题是应该去考虑的，以及为什么这么考

虑，提供丰富的知识和建议，以帮助一些组织设计和构建一个完美架构

的、满足独特需求的OpenStack云。

目标读者

本书是写给OpenStack云的架构师和设计师们。本书不是为那些打算部署

OpenStack的人们写的。关于部署和实战的指南请参考 OpenStack 实战指南

(http://docs.openstack.org/openstack-ops)。

读者需要有云计算架构和原理的知识背景，企业级系统设计经验，linux和

虚拟化经验，以及可理解基本的网络原理和协议。

本书是如何组织的

本书采用多个章节来组织，通过使用案例来帮助用户作出架构选择，

以OpenStack云安装来具体体现。每一章关注一个单一的架构以鼓励读者

1架构指南

July 22, 2015

当前最新

可随意的阅读，但是每一章包含的一些适用场景的信息也是其他章节需要

的。云架构师也许通过阅读所有的案例将此书作为一个全面的参考，但是

很可能仅重复阅读其中适合于某一案例的章节。当选择阅读挑选的使用案

例时，请记住需要阅读更多的章节，以为云制定完整的设计。本指南中覆

盖到的使用案例包括：

•通用型: 使用通用的组件构建一个云，是多数的使用案例，占80%。

•计算型: 专注于计算密集性、高负载的云，例如高性能计算(HPC)

•存储型: 用于存储密集负载的云，例如基于并行文件系统的数据分析。

•网络型: 依赖于网络的高性能和高可靠的云，例如 内容传送网络 (CDN)。

•多站点: 构建一个基于地理分布、可靠性、数据位置等原因的应用程序部

署且需多个站点可供服务的云。

•混合云: 一种多个不同的云相杂的架构，目的是提供可用性，失效切换，

防止单一云的突然崩溃。

•大规模扩展: 专注于云计算服务提供者或其他大规模扩展安装的架构。

章节 特殊用例阐释了上述所定义的使用案例中没有覆盖到的架构信息。

本指南的每一章都会分出以下小节：

•介绍：此架构使用案例的额要介绍

•用户需求：用户所考虑的内容，那些典型的在组织中起关键作用的。

•技术考虑：在实际案例中所处理的技术问题。

•实践考虑：在实际案例中和架构考虑中的那些不断的操作任务。

•架构：总体架构

•实例：架构设计被实际部署的一个或几个场景。

书中所用到的术语词汇表

我们为什么及如何写作此书

OpenStack环境从验证测试迁移到实际生产部署的速度决定着和架构设计相

关的问题的多寡。目前已经存在的文档中，都是定位在特定的部署、配置

以及实际操作的，还没有整体框架式的相关描述。

我们写作此书是希望能够给读者带来抛砖引玉的作用，让读者可以根据自

身所在的组织具体需求来设计OpenStack架构。此指南针对通用情况的使用

2

 

 

架构指南

July 22, 2015

当前最新

案例，抽取了我们认为重要的设计考虑，且根据我们的设计提供了具体的

例子。此指南的目标不是为安装和配置云提供相关介绍，是专注于那些和

用户需求密切相关的设计原理，相比技术和操作上的考虑也少了许多。在

OpenStack文档相关的板块中关于安装和配置的相关向导/指南已经有很多

资料了，寻找想要的即可。

本书是基于sprint格式书写的，sprint格式是一种针对写书的便利、

快速开发的一种方法。想得知更多信息，请访问Book Sprints官方站点

(www.booksprints.net)。

本书的写作共花了5天的时间，在2014年的7月份，中间当然历经辛勤的汗

水、激情以及合理的饮食。在帕洛阿尔托的VMware公司总部午饭时我们

庆祝了本书的完成。整个过程我们在Twitter中使用#OpenStackDesign 直

播。Faith Bosworth 和 Adam Hyde帮助我们轻松驾驭Book Sprint。

我们非常感谢VMware的盛情款待，以及我们的雇主，Cisco,

Cloudscaling,Comcast,EMC,Mirantis,Rackspace,Red Hat, Verizon和VMware,能

够让我们花时间做点有意义的事情。尤其感谢Anne Gentle 和 Kenneth Hui，

由于二位的领导和组织，才有此书诞生的机会。

作者团队成员有：

•Kenneth Hui (EMC) @hui_kenneth

•Alexandra Settle (Rackspace) @dewsday

•Anthony Veiga (Comcast) @daaelar

•Beth Cohen (Verizon) @bfcohen

•Kevin Jackson (Rackspace) @itarchitectkev

•Maish Saidel-Keesing (Cisco) @maishsk

•Nick Chase (Mirantis) @NickChase

•Scott Lowe (VMware) @scott_lowe

•Sean Collins (Comcast) @sc68cal

•Sean Winn (Cloudscaling) @seanmwinn

•Sebastian Gutierrez (Red Hat) @gutseb

•Stephen Gordon (Red Hat) @xsgordon

•Vinny Valdez (Red Hat) @VinnyValdez

3

 

 

架构指南

July 22, 2015

当前最新

方法论

云的魅力在于它可以干任何事。无论从健壮性还是灵活性，都是这个世界

上目前来说最好的。是的，云具有很高的灵活性，且可以做几乎任何事，

但是想要充分发挥云的威力，定义好云将如何使用是非常重要的，否则创

建和测试的使用案例意义就不复存在。此章讲述的是那些设计最适合、用

户最关注的云架构背后的思考过程。

上图展示了在获取用户需求和构建使用案例过程中的抽象流程。一旦用例

被定义，它就可以被用于设计云的架构。

用例选择规划看起来是反直觉的，比如，使用Amazon的服务，从注册到

使用也就是花5分钟的时间而已。难道Amazon真的不关心用户的计划？错

了，Amazon的产品管理部门花了大量的时间去研究吸引他们典型用户的究

竟是什么，也在琢磨着交付更好的服务。对于企业来说，计划的流程没有

什么不同，只是不会去规划外部的付费用户罢了，举例来说，用户仅仅是

内部的应用程序开发者或者是web门户。下面所列的目标在考虑创建用例时

用的到。

总体业务目标

•开发务必清晰定义，符合业务目标和需求

•增加项目的支持，积极的和业务相关人员、客户以及最终用户保持沟

通。

July 22, 2015

当前最新

•协调OpenStack架构中各个项目，努力的通过社区获得更多的支持。

•为自动化设计好的架构可大大的加速开发和部署。

•使用恰当的工具可增加开发的效率。

•创建更好的、更多的测试指标和测试工具，以支持开发的持续集成、测

试流程和自动化。

•选用好多消息工具，良好的管理支持团队。

•增强文化氛围，诸如对于开源的理解，云架构，敏捷开发，持续开发/测

试/集成等，总而言之，涉及到开发的所有环节都需要。

举例来说明上述的一切，想想一个业务目标是将其公司的电子商务站点使

用云来构建。此目标意味着应用程序将要支持每秒成千上万的会话，各种

负载以及大量复杂和瞬息完变的数据。通过识别诸如每秒并发事务，数据

库的大小等关键指标，相信构建出一个基于假设的测试方法是可行的。

基于用户场景开发功能. 基于用户场景开发功能，可轻松开发测试用例，

即可在项目的整个过程中有个掂量。假如组织没有准备好一个应用，或者

没有准备好一个用于开发用户需求的应用，那么就需要创建需求，以构建

合适的测试工具和开发可用的指标。一旦指标确认，即使遇到需求变更，

也可轻松面对快速变化，而且无须过度担心提前具体需求。将此类比于使

用创新的方法配置系统，不能因为需求的变化而每次都重新设计。

云的局限特性集. 建立需求是发掘用户痛点，而不是重新创建OpenStack

已经有的工具集。认为建立OpenStack的只有一种好办法，那只能弄巧成

拙。在开发一个平台中通过限制集中带来的慢速是非常重要的，因为它会

导致需求转变为处理工具本身，所以请不要重新创建一整套的工具。欲成

功的部署云，与技术产品负责人一起建立关键功能显得不可或缺。

为云准备好应用程序

尽管云被设计出来是让事情变得更简单，但是要意识到“使用云”不仅仅

是建立一个实例然后将应用丟进去就这么简单是非常重要的。这种一夜之

间平地起高楼的事情是需要确定的情况的，要明白在云和过去的基于服务

器硬件环境以及过去虚拟化环境是有着本质上的区别的。

在过去的环境中，还有那些过去的企业级应用，服务器和应用的运行都是

被当作“宠物”看待的，他们被精心的照看和爱护，甚至每台服务器都有

July 22, 2015

当前最新

自己的名字如“甘道夫“或”哆啦唉梦“,一旦他们生病了，则需要人去护

理直到恢复健康。所有的这些设计表明应用是不可以停止。

在云的环境中，打个比方，服务器更像是牛群中的某一头牛。它们太多

了，成千上万，命名的方式可能是类似的编号 NY-1138-Q，如果它们中的一

个出问题了，管理员会直接抛弃它，再重新安装和启动一个即可。遗留的

应用还没有准备好运行在此云环境中，所以很自然的会遭遇停运，丢失数

据，甚至更加糟糕的。

在为云设计应用还有另外一些原因需要注意。一些是防御性的，例如一些

应用并不能准确的确定在什么地方或什么样的硬件去启动，所以他们需要

灵活性，即使做不到至少应该保持适应性更强。另外一些则是主动性的，

例如，使用云的一个优点是其有高扩展性，所以应用需要被设计的能够使

用这些优点，当然云还有更多的优点，也得一并考虑。

决定那些应用程序是可在云中运行

寻找适合于在云中运行的应用，还是有几种方法可以考虑的。

那些大型的、单层次的、铁板一块的旧的应用是非常典型的不适

合云环境的。将负载分割为多个实例会获得高效，所以部分系统

失效不会特别影响其他部分的系统，或者说随应用的需要而横向

扩展。

如果应用程序依赖特别的硬件，比如特别的芯片或者是类似指

纹识别等外设，是不适合于云计算的。除非使用特别的方式来实

现。同样的，如果应用依赖于操作系统或一组程序库不能用于云

环境，或者无法在虚拟化环境中运行，这就真的成了问题了。

自包含的应用或它们所依赖的资源在云的环境无法实现，将无法

运行。也许在一些情况下，通过自定义网络解决了这些问题，但

是运行是否良好还得看选择云的环境。

尽管有服务水平协议(SLA)的存在,但是还是会有一些坏的事情发

生：服务器宕机，网络连接发生紊乱，多个租户无法访问服务。

应用程序必须足够的稳固，以应对上述事情的发生。

这里有一些原则忠告，在为一个应用设计云的时候请时刻铭记：

•做一个悲观主义者：承担一切失败，基于目标选择手段。善待那些将系

统搞坏的程序。

•将鸡蛋放在多个篮子里：考虑多个供应商，基于地理分区不同的数据中

心，多可用的zones以容纳本地存在的隐患。可移植性的设计。

July 22, 2015

当前最新

•考虑效率：低效的设计将不可扩展。高效的设计可以无须花费多少钱即

可轻松扩展。去掉那些不需要的组件或容量。

•保持偏执：深度设计防御，通过构建在每一层和每个组件之间的安全确

•但是也不要太偏执：不是所有的应用都需要钻石级的解决方案。为不同

的服务水平协议、不同的服务层和安全级别等分别设计不同的架构。

•管理数据：数据通常是最为灵活的也最复杂的一块，尤其是在云中或云

集成的架构中。要在分析和传送数据付出更多的努力。

•放手：自动化可以增加一致性、质量以及减少响应的时间。

•分离和征服：尽可能分区和并行的分层。尽可能的确保组件足够小且可

移植。在层之间使用负载均衡。

•保持弹性：随着增加的资源，确保结果是增加的性能和扩展。减少资源

要没有负面影响。

•保持动态：激活动态配置变化诸如自动扩展，失效恢复，资源发现等，

以适应变化的环境，错误的发生以及负载的变化。

•贴近原则：通过移动高度密切的组件和相似数据靠近以减少延迟。

•保持松散：松耦合，服务接口，分离关注度高的点，抽象并定义好的应

用程序接口，交付灵活。

•注意开销：自动扩展，数据传输，虚拟软件许可证，保留的实例等等均

会快速增加每月的使用支出。密切监测使用情况。