OpenStack项目架构设计与实践指南，主流应用场景分析，典型应用案例分享，多位院士力荐！

前 言
一、本书的初衷、读者定位及解决的问题
本书将OpenStack应用场景归为下面几类：
1．通用型应用场景；
2．计算密集型应用场景；
3．高负载存储型应用场景；
4．高吞吐网络型应用场景；
5．混合云应用场景；
6．跨地域多点型应用场景；
7．大规模可扩展型应用场景；
8．其他应用场景。
其实，它们之间并没有那么严格的界限，比如用户的场景是高性能计算，那么它不仅是计算密集型，也需要很大的存储吞吐量。我们尝试尽可能地简化，便于用户根据自身的业务做出选择。
本书是写给打算架设OpenStack 基础设施即服务云的设计师和架构师们的，以及OpenStack的咨询顾问、售前顾问。本书不是讲解OpenStack的代码设计及其体系结构的，也不是讲解如何部署和故障排查的，也不是讲如何优化、运维的。
正如各个技术媒体、市场分析所言，OpenStack本身并不是一个产品，甚至整个基础设施即服务云都不能作为产品来看待，加上OpenStack下面的一些子项目的成熟度较低，作为最终用户部署OpenStack就有了很大的难度，如针对自身的业务模式，该如何选择OpenStack组件？是否选择众多的OpenStack供应商？硬件基础设施该选择哪些？监控、计费如何解决？是否需要二次开发定制？安全性如何？运维是否和原来的服务托管有本质的不同？
如果上述这些问题正是你现在考虑的，那么本书很适合你，书中根据常见的IT场景，给出了相应的解决方案。如果本书的场景并不完全吻合你的需求，你也可以通过这些场景稍加变化，就可以设计出最适合自己的OpenStack解决方案。
二、OpenStack市场现状
根据最近的Forrest市场报告，很欣慰地看到OpenStack已经准备好企业级服务了，已经有世界级大公司成功应用于生产环境，如迪斯尼、宝马、沃尔玛等。但OpenStack也有一个失败的“领地”，那就是新兴的互联网厂商们都没有选择它，如netflix、Airbnb等。
在公有云的“领地”，其实也不太乐观，比如惠普退出了其基于OpenStack的产品，收购Encalyptus后，开始专注于为客户提供融合架构的私有云服务。在基于OpenStack的发行版厂商中，最早做OpenStack解决方案的Nubla公司于2015年5月宣布破产。虽然有一些公司因为各种原因，没有将OpenStack推向市场，或是商业模式，或是管理，但是仍然有一些公司在前行着，比如Mirantis。
让我们将目光转回到国内，基于OpenStack做私有云服务的厂商基本上算是全军覆没了，关于他们失败的总结，其实就是不理解开源生态系统，这里笔者就不多做讨论了，有兴趣的读者可以关注笔者的博客。基于OpenStack做公有云市场，比如易云捷讯、UnitedStack等。易云捷讯利用其与国内传统ERP提供商用友的关系，试图在中小型企业的企业资源规划、人力资源管理等应用提供基础设施平台。
OpenStack的热潮正在退去，这从国内的社区就可以看出端倪。我们知道国内喜欢跟风，正如2000年左右的Linux一样，但都是三分钟的热度。很多人已经转向最近更火的Docker、Mesos等项目，这样反而对OpenStack在国内的发展更加有利，因为少了那些“煽风点火”的人，多了一些沉着的态度。OpenStack真正进入企业界，才刚刚开始。随着新的项目，如Murano，Ironic，Manila等不断地完善和发布，OpenStack正在被不断地刷新，比如Murano的出现，解决了传统企业软件部署的问题。
就在最近，作为全球技术创新的领跑者Google，也正式加入了OpenStack阵营，相信OpenStack会有更加美好的明天，能够为企业和互联网提供优秀的基础设施平台。
三、阅读本书所需要的知识储备
阅读本书，要求你对如下知识点至少有所了解：
Linux 操作系统的操作；
云计算，尤其是基础设施即服务的相关架构；
TCP/IP网络协议，对SDN最好有所了解；
虚拟化相关；
企业级系统的设计；
存储知识，如SAN、NAS、分布式文件系统等；
高可用集群。
四、本书的方法论
云的魅力在于它可以干任何事，无论健壮性还是灵活性，都是相当好的。是的，云具有很高的灵活性，且几乎可以做任何事，但是想要充分发挥云的威力，定义好云将如何使用是非常重要的，否则创建和测试的使用案例意义就不复存在了。这里讲述的是那些设计最适合、用户最关注的云架构背后的思考过程。
用例选择规划看起来是反直觉的，比如使用Amazon的服务，从注册到使用也就是花5分钟的时间而已。难道Amazon真的不关心用户的计划？错了，Amazon的产品管理部门花了大量的时间去研究吸引他们典型用户的究竟是什么，也在琢磨着交付更好的服务。对于企业来说，计划的流程没有什么不同，只是不会去规划外部的付费用户罢了。举例来说，用户仅仅是内部的应用程序开发者或者是Web门户。下面所列的目标，在考虑创建用例时用得到。
总体业务目标
开发务必清晰定义，符合业务目标和需求；
增加项目的支持，积极和业务相关人员、客户以及最终用户保持沟通。
技术
协调OpenStack架构中各个项目，努力通过社区获得更多的支持；
为自动化设计一套好的流程，可大大提高开发和部署的效率；
使用恰当的工具可提高开发的效率；
创建更好的、更多的测试指标和测试工具，以支持开发的持续集成、测试流程和自动化。
组织
选用好多消息工具和良好的管理支持团队；
增强文化氛围，如对于开源的理解、云架构、敏捷开发、持续开发/测试/集成等。总而言之，涉及开发的所有环节都需要。
下面举例来进行说明，假想一个业务目标是使用云来构建某公司的电子商务站点。此目标意味着应用程序将要支持每秒成千上万的会话，各种负载以及大量复杂和瞬息万变的数据。通过识别如每秒并发事务、数据库的大小等关键指标，相信构建出一个基于假设的测试方法是可行的。
基于用户场景开发功能。基于用户场景开发功能可轻松开发测试用例，即可在项目的整个过程中有个预期。假如组织没有准备好一个应用，或者没有准备好一个用于开发用户需求的应用，那么就需要创建需求，以构建合适的测试工具和开发可用的指标。一旦指标确认，即使遇到需求变更，也可以轻松面对快速变化，而且无须过度担心提前具体需求。将此类使用创新的方法配置系统，不能因为需求的变化而每次都重新设计。
云的局限特性集。建立需求是发掘用户痛点，而不是重新创建OpenStack已经有的工具集。认为建立OpenStack只有一种好办法，那只能弄巧成拙。在开发一个平台时，通过限制集中带来的慢速是非常重要的，因为它会导致需求转变为处理工具本身，所以请不要重新创建一整套的工具。想成功部署云，与技术产品负责人一起建立关键功能十分重要。
1. 为云准备好应用程序
尽管云被设计出来是让事情变得更简单，但是要意识到“使用云”不仅仅是建立一个实例，然后将应用丟进去这么简单，这一点是非常重要的。这种一夜之间平地起高楼的事情是不会发生的，要明白在云和过去的基于服务器硬件环境，以及虚拟化环境是有着本质上的区别的。
在过去的环境中，还有那些过去的企业级应用，服务器和应用的运行都是被当作“宠物”看待的，它们被精心地照看和爱护，甚至每台服务器都有自己的名字，如“甘道夫”或“哆啦A梦”，一旦它们“生病”了，则需要人去“护理”，直到“恢复健康”。所有的这些设计表明应用是不可以停止的。
在云的环境中，打个比方，服务器更像是牛群中的某一头牛。它们太多了，成千上万，命名的方式可能是类似“NY-1138-Q”的编号，如果它们中的一个出问题了，管理员会直接抛弃它，再重新安装和启动一个即可。遗留的应用还没有准备好运行在此云环境中，所以很自然地会遭遇停运，丢失数据，甚至更加糟糕。
在为云设计应用时，还有另外一些原因需要注意。一些是防御性的，例如一些应用并不能准确地确定在什么地方，或什么样的硬件去启动，所以它们需要灵活性，即使做不到，至少应该保持适应性更强。另外一些则是主动性的，例如使用云的一个优点是具有高扩展性，所以应用需要被设计得能够使用这些优点。当然云还有更多的优点，也得一并考虑。
2. 确定哪些应用程序是可在云中运行的
寻找适合于在云中运行的应用，还是有几种方法可以考虑的。
结构：那些大型的、单层次的、“铁板一块”的旧应用是非常典型不适合云环境的。将负载分割为多个实例会获得高效，所以部分系统失效不会特别影响其他部分的系统，或者说随应用的需要而横向扩展。
依赖：如果应用程序依赖特别的硬件，比如特别的芯片或者类似指 纹识别等外设，是不适合云计算的。除非使用特别的方式来实现。同样，如果应用依赖于操作系统或一组程序库不能用于云环境，或者无法在虚拟化环境中运行，这就真的成了问题了。
连通性：自包含的应用或它们所依赖的资源在云的环境无法实现，将无法运行。也许在一些情况下，通过自定义网络解决了这些问题，但是运行是否良好，还得看选择云的环境。
耐久性和弹性：尽管有服务水平协议（SLA）的存在，但还是会有一些坏的事情发生：服务器宕机、网络连接发生紊乱、多个租户无法访问服务等。应用程序必须足够稳固，以应对上述情况的发生。
3. 设计云
这里有一些原则性忠告，在为一个应用设计云的时候请时刻铭记。
做一个悲观主义者：承担一切失败，基于目标选择手段。善待那些将系统“搞坏”的程序。
将鸡蛋放在多个篮子里：考虑多个供应商，基于地理分区不同的数据中心，多可用的Zones以容纳本地存在的隐患。可移植性的设计。
考虑效率：低效的设计将不可扩展。高效的设计可以无须花费多少钱就可以轻松扩展。去掉那些不需要的组件或容量。
保持偏执：深度设计防御，通过构建在每一层和每个组件之间的安全，确保零差错。不信任任何人。
但是也不要太偏执：不是所有的应用都需要“钻石级”的解决方案。为不同的服务水平协议、不同的服务层和安全级别等，分别设计不同的架构。
管理数据：数据通常是最灵活的，也最复杂的一块，尤其是在云中或云集成的架构中。要在分析和传送数据方面付出更多的努力。
放手：自动化可以增加一致性、质量以及减少响应时间。
分离和征服：尽可能分区和并行的分层。尽可能确保组件足够小且可移植。在层之间使用负载均衡。
保持弹性：随着增加的资源，确保结果是增加的性能和扩展。减少资源负面影响。
保持动态：激活动态配置变化，如自动扩展、失效恢复、资源发现等，以适应变化的环境、错误的发生以及负载的变化。
贴近原则：通过移动高度密切的组件和相似数据靠近以减少延迟。
保持松散：松耦合，服务接口，分离关注度高的点，抽象并定义好的应用程序接口，交付灵活。
注意开销：自动扩展、数据传输、虚拟软件许可证、保留的实例等，均会快速增加每月的使用支出。密切监测使用情况。