标签：
OpenStack 是一个面向 IaaS 层的开源项目，用于实现公有云和私有云的部署及管理。拥有众多大公司的行业背书和数以千计的社区成员， OpenStack 被看作是云计算的未来。目前 OS 基金会里已有500多个企业赞助商，遍布世界170多个国家，其中不乏 HP 、 Cisco 、 Dell 、 IBM 等，值得一提的是 Google 也在2015年加入基金会。
Rackspace （一家美国的云计算厂商）和 NASA （美国国家航空航天局）在2010年共同发起了 OpenStack 项目。
那时候 Rackspace 是美国第二大云计算厂商，但规模只能占到亚马逊的5%。只依靠内部的力量来超越或者追赶亚马逊不大可能，这家公司索性就把自己的项目开源了，也就是后来的 OpenStack 的存储源码（ swift ）。
与此同时， NASA 也对自己使用的 Eucalyptus 云计算管理平台很不爽。 Eucalyptus 有两个版本，开源版本和收费版本， NASA 想给 Eucalyptus 开源版本贡献 patch ，结果 Eucalyptus 不接受，估计是和收费版本功能重叠了。当时 NASA 的六个开发人员，用了一个星期时间拿 Python 做出来一套原型，结果虚拟机在这上面运行的很成功，这就是 Nova （计算源码）的起源。
NASA 跟 Raskspace 玩的比较好，于是 NASA 贡献 Nova ， Raskspace 贡献 Swift ，在2010年的7月发起了 OpenStack 项目。
截至 Grizzly 版本， OpenStack 含七个核心项目：
其中有三个最核心的架构服务单元，分别是：计算基础架构 Nova 、存储基础架构 Swift 和镜像服务 Glance 。
Nova 是 OpenStack 云计算架构控制器，管理 OpenStack 云里的计算资源、网络、授权、和扩展需求。 Nova 不能提供本身的虚拟化功能，相反，它使用 libvirt 的 API 来支持虚拟机管理程序交互，并通过 web 服务接口开放他的所有功能并兼容亚马逊 web 服务的 EC2 接口。
Swift 为 OpenStack 提供分布式的、最终一致的虚拟对象存储。通过分布式的穿过节点， Swift 有能力存储数十亿计的对象， Swift 具有内置冗余、容错管理、存档、流媒体的功能。并且高度扩展，不论大小（多个 PB 级别）和能力（对象的数量）。
Glance 镜像服务查找和检索虚拟机的镜像系统。
上图为 OpenStack 架构
三个元素将会与系统中的所有组件进行交互。 Horizon 是图形用户界面，管理员可以很容易地使用它来管理所有项目。 Keystone 处理授权用户的管理， Neutron 定义提供组件之间连接的网络。 Nova 被认为是 OpenStack 的核心，负责处理工作负载的流程。它的计算实例通常需要进行某种形式的持久存储，它可以是基于块的 （ Cinder ） 或基于对象的 （ Swift ）。 Nova 还需要一个镜像来启动一个实例。 Glance 将会处理这个请求，它可以有选择地使用 Swift 作为其存储后端。
OpenStack 架构一直努力使每个项目尽可能的独立，这使得用户可以选择只部署一个功能子集，并将它与提供类似或互补功能的其他系统和技术相集成。然而，这种独立性不应掩盖这样一个事实：全功能的私有云很可能需要使用几乎所有功能才可以正常运作，而且各元素需要被紧密地集成。
传统的软件生态模式是用户和开发者之间隔着销售、产品经理等角色，而 OpenStack 等开源的模式打破了这样一种模式， OS 只提供最最底层的框架，剩余一切都围绕着用户，用户可参与从设计、编码、测试、到运维的各种阶段。而这样的模式生命力是最强的。
如果仅仅是便宜，那么 OpenStack 对于企业似乎就没那么大的价值了。相反， OpenStack 提供了一个非常好的有关如何来打造类似于主要公有云比如亚马逊（ AWS ）和 Google Cloud Platform （ GCP ）的弹性私有云的样板。就像 Hadoop 将 Google 的 MapReduce （加上它的参考架构）推向大众一样， OpenStack 将 AWS/GCP 式样的的基础架构即服务（ IaaS ）推向了每个用户。它就是能实现企业内部 DevOps 的终极平台。
OpenStack 能在企业内部提供类似的平台。私有云可以基于公有云模型来构造，使得开发者同时拥有集中式 IT 控制和支配。本质上，它是两者融合的最佳平台，这也是 OpenStack 驱动的私有云的真正价值。
由 OpenStack 来实现企业内部的 DevOps ，进而实现敏捷，而敏捷恰恰是驱动云计算的原动力。
四.企业级 OpenStack 的需求 企业级 OpenStack 到底需要什么呢？有以下六个关键的因素：
有高可靠性要求的应用需要高可靠的云API向全新的云和 DevOps 模型转型的一个关键能力是提供云原生应用在弹性云中的容错能力。要使一个应用能实时地适应不同组件的出错，云 API 需要有更高的可用性。
API 的可用性不是唯一的衡量标准。你的云控制平面的吞吐量（ throughoutput ）同样关键。可以将控制平面想象成云的指挥中枢。这是中央智能和编排层的核心。你的 API 是控制平面的一部分，对于 OpenStack 来说，包括所有的核心项目，以及日常的云管理系统（通常是 OpenStack 企业级套件的一部分），以及所有必要的辅助服务，比如数据库、 OpenStack 各厂商插件等等。你的云的控制平面必须能够随着云的增长而增长。这意味着，总体上，你将会获得更多的 API 操作的吞吐量（对象上传/下载、镜像上传/下载、元数据更新等待）。
安装只是管理 OpenStack 的开端。一个真正的云操作系统将提供一个从设计上就能保证基础设施团队能成功交付服务的以运维为核心的云管理工具套件。这些管理工具将提供：
OneAPM 的出现，使得企业可以缩减庞大运维团队的开支， OneAPM 的产品能帮助你进行应用性能分析、告警、日志分析记录，并能实现代码级的故障诊断。
OpenStack 的开放架构，能够减少厂商锁定，进而降低风险。
目前环境下，混合云兼具私有云安全性与公有云的弹性扩展能力，混合云必然成为企业云部署的第一选择。根据应用类别和业务特点，将关键应用、性能敏感型、中高密级应用部署在私有云，其他应用部署在公有云；将同一个应用的不同层部署在不同云中，时延敏感业务就近用户部署，提升最终用户体验； Web Front 支持 Web 服务灵活扩展，集中控制关键数据；突发型应用，私有云资源不足时（如 Web 网站），向公有云临时租借资源。 混合云的难点在于解决应用的移植性问题。如果你需要一个公有云和私有云组合而成的混合云，不管应用在某个云中被开发，还是要在两个云之间做迁移，或者从一个云到另一个云，应用的可移植性都是必须的。当你选定一个应用以及它的云原生的自动化框架，并将它们从一个云移动到另一个云中，一些关键的东西必须保持一致：
5.可扩展的弹性架构
「当我们在系统中增加资源后，其性能会按照所增加资源的某种比例增加时，我们就可以说其服务是可扩展的。」
从多方面看， OpenStack 自身就是个高扩展性的系统。它被设计为松耦合、基于消息通信的架构，这些技术在已经在各种中级到高级扩展的系统中得到应用和验证，它们也可以适应小规模的部署。问题在于当你配置和部署 OpenStack 时所做的设计上的决定。
一部分默认的配置，以及许多厂商的插件和方案在设计时并没有考虑扩展性。
基础架构从来没有真正的弹性过，可是它的特性能支持弹性的应用在它上面运行。一个弹性云，需要被设计为每个资源，比如虚机、块存储和对象存储，其成本尽可能的低。这和杰文斯悖论（ Jevon’s Paradox ）直接相关，他说随着技术的进步，效率的提升将会带来该技术被采用速度的提升。
总结： OpenStack 作为一个可扩展的打造下一代弹性云的基础架构，尽管它还不是很完美。但作为一个开源项目，它的吸引力确实不容小视。基于平台开放，会有越来越多的力量促使它更完善和强大，采用 OpenStack 意味着企业云平台会更加自主可控，并实现技术沉淀和自动化运维水平的提升。
参考文献： The 6 Requirements of Enterprise-grade OpenStack
OneAPM 是中国基础软件领域的新兴领军企业。致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务，通过一个探针就能够完成日志分析、安全防护、 APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多优秀文章，请访问 OneAPM官方技术博客 OneAPM 官方技术博客
标签：
原文地址：http://www.cnblogs.com/qijiayi/p/5175410.html
