一篇文章让你读懂 OpenStack 的起源、架构和应用（读文章）

一篇文章让你读懂 OpenStack 的起源、架构和应用（读文章）

一.关于项目起源

Rackspace （一家美国的云计算厂商）和 NASA （美国国家航空航天局）在2010年共同发起了 OpenStack 项目。

NASA 跟 Raskspace 玩的比较好，于是 NASA 贡献 Nova ， Raskspace 贡献 Swift ，在2010年的7月发起了 OpenStack 项目。

二. OpenStack 架构

截至 Grizzly 版本， OpenStack 含七个核心项目：

Compute (Nova)Networking (Neutron/Quantum)Identity Management (Keystone)Object Storage (Swift)Block Storage (Cinder)Image Service (Glance)User Interface Dashboard (Horizon)

其中有三个最核心的架构服务单元，分别是：计算基础架构 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 的核心优势

OpenStack 能在企业内部提供类似的平台。私有云可以基于公有云模型来构造，使得开发者同时拥有集中式 IT 控制和支配。本质上，它是两者融合的最佳平台，这也是 OpenStack 驱动的私有云的真正价值。

由 OpenStack 来实现企业内部的 DevOps ，进而实现敏捷，而敏捷恰恰是驱动云计算的原动力。

四.企业级 OpenStack 的需求企业级 OpenStack 到底需要什么呢？有以下六个关键的因素：

1.99.999% 的 API 可用性以及可扩展的控制平面

有高可靠性要求的应用需要高可靠的云API向全新的云和 DevOps 模型转型的一个关键能力是提供云原生应用在弹性云中的容错能力。要使一个应用能实时地适应不同组件的出错，云 API 需要有更高的可用性。

API 的可用性不是唯一的衡量标准。你的云控制平面的吞吐量（ throughoutput ）同样关键。可以将控制平面想象成云的指挥中枢。这是中央智能和编排层的核心。你的 API 是控制平面的一部分，对于 OpenStack 来说，包括所有的核心项目，以及日常的云管理系统（通常是 OpenStack 企业级套件的一部分），以及所有必要的辅助服务，比如数据库、 OpenStack 各厂商插件等等。你的云的控制平面必须能够随着云的增长而增长。这意味着，总体上，你将会获得更多的 API 操作的吞吐量（对象上传/下载、镜像上传/下载、元数据更新等待）。

安装只是管理 OpenStack 的开端。一个真正的云操作系统将提供一个从设计上就能保证基础设施团队能成功交付服务的以运维为核心的云管理工具套件。这些管理工具将提供：

可重用的架构模型，通常使用参考网络架构将小集群（ pod ）或者组（ block ）连接在在一起初始云安装和部署典型的日常云运维工具，包括日志、系统测量值和相关度分析供云运维人员使用的用来做整合和自动化的 CLI 和 API用于可视化和分析的云运维图形界面

3.开放的架构

OpenStack 的开放架构，能够减少厂商锁定，进而降低风险。

4.混合云兼容性

性能相对平稳底层的存储、网络和计算架构保持一致或者近似你应用的自动化框架必须和两个云中的 API 都兼容每个云中，运行应用的总成本（ TCO ）都应该在1/2-2倍的范围之内还有行为上的兼容性，意味着非 API 功能也需要吻合支持与相关公有云 API 的兼容

5.可扩展的弹性架构

「当我们在系统中增加资源后，其性能会按照所增加资源的某种比例增加时，我们就可以说其服务是可扩展的。」

从多方面看， OpenStack 自身就是个高扩展性的系统。它被设计为松耦合、基于消息通信的架构，这些技术在已经在各种中级到高级扩展的系统中得到应用和验证，它们也可以适应小规模的部署。问题在于当你配置和部署 OpenStack 时所做的设计上的决定。

一部分默认的配置，以及许多厂商的插件和方案在设计时并没有考虑扩展性。

基础架构从来没有真正的弹性过，可是它的特性能支持弹性的应用在它上面运行。一个弹性云，需要被设计为每个资源，比如虚机、块存储和对象存储，其成本尽可能的低。这和杰文斯悖论（ Jevon’s Paradox ）直接相关，他说随着技术的进步，效率的提升将会带来该技术被采用速度的提升。

6.全面的支持和服务

总结：OpenStack 作为一个可扩展的打造下一代弹性云的基础架构，尽管它还不是很完美。但作为一个开源项目，它的吸引力确实不容小视。基于平台开放，会有越来越多的力量促使它更完善和强大，采用 OpenStack 意味着企业云平台会更加自主可控，并实现技术沉淀和自动化运维水平的提升。