Menu
Woocommerce Menu

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

0 Comment

由于受近期国内外产业环境影响,中国高科技领域的自主可控已被空前关注,目前相关讨论已延伸至云计算领域。在日前的云栖大会·南京峰会上,阿里云副总裁李津一开场首先向听众分享中国电子信息技术年会为“飞天”云操作系统颁发科技进步特等奖的消息,接着话锋一转,声称“在中国只有两种云,第一种云是拿来主义的云,第二种云是阿里云这样自主可控的云”。李津的喊话立即在科技圈引发一场口水大战。华为中国区企业级产品线一位人士针锋相对地回击:中国只有两种云,一种是“只会吹牛的云,一种是踏踏实实改变世界的云”。青云QingCloud在官方微信公众号上刊发《讨“两种云”檄》,质问拥有上千名工程师的阿里云,“真的认为中国只有‘飞天云’是自主可控的?”在国内通信领域部分核心技术被“卡脖子”的背景下,大家都不愿意沾上不自主、不可控的名声。比如,华云数据一位人士接受《中国经营报》记者采访表示,“经过多年发展,我国云计算已经有了自己的技术积淀,尤其在国产化、自主可控战略的大背景下,一大批本土云品牌依靠对自主核心技术的积累,迅速在国内市场成长起来。”关于自主可控的争论作为中国云计算产业的拓荒者,同时作为目前中国云计算市场的领军者,阿里云当然有理由说“自主可控”。据了解,阿里云从2008年开始起步,当时正值阿里巴巴电商业务快速崛起之时,一波一波的促销活动带来巨大的线上流量,让包括微软、IBM、Oracle等在内的IT技术服务商也束手无策,阿里巴巴在此时开始认识到,核心技术是买不来的,必须靠自己。就是在2008年10月24日,阿里云第一位员工在飞天团队入职,随后在2009年2月,飞天团队写下了云操作系统的第一行代码。正如李津公开所讲,“从最早的飞天云系统开始,到我们的数据库Oceanbase,到物联网平台Link,到服务器神龙,再到我们的芯片。这条路径将会越来越长,技术也会越来越高端。如果没有自己的技术,没有自己的创新能力,我们不可能在这场互联网、云计算的战争中取胜。”李津随后在媒体访问环节明确说出了自己的担忧:如果今天中国的算法都是基于OpenStack的,你觉得以后会是什么趋势?如果有一天OpenStack结束更新呢?因此,李津所谓的“两种云”,实际上指的是使用了飞天云操作系统的阿里云,和基于OpenStack开源平台的云。那么,何为OpenStack?公开资料显示,OpenStack其实是美国一家云计算厂商Rackspace和美国国家航空航天局(即NASA)在2010年7月共同发起的一个项目。当时,Rackspace是美国第二大云计算厂商,但规模只有亚马逊AWS的5%,觉得自己追赶、超越亚马逊AWS不大可能,索性将自己的项目开源了,就是后来的OpenStack存储源码(Swift)。接着,NASA贡献了Nova(计算源码),构成了当时的OpenStack项目。OpenStack包含三个核心架构服务单元,分别是计算基础架构Nova、存储基础架构Swift和镜像服务Glance。此后,OpenStack成为很多云计算公司底层架构的首选。数据显示,目前OpenStack保持高速增长态势,超过585家企业、接近4万人通过各种方式正在支持这个超过2000万行代码的开源项目的持续发展。而支撑OpenStack持续发展的OpenStack基金会拥有8个白金会员和24个黄金会员,中国企业占到了会员总数的1/3以上,其中包括白金会员华为、腾讯以及黄金会员中国移动、中国联通、中国电信、中兴通讯、浪潮、新华等。李津表示,“在北美一些最热的科技公司,事实上用开源反而很少。为什么开源在中国是最火的?大家要思考这个问题。中国有700多万程序员,却最喜欢用开源,这是为什么?值得每个技术人员去思考。”

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 项目。

二. 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 镜像服务查找和检索虚拟机的镜像系统。

图片 1

上图为 OpenStack 架构

三个元素将会与系统中的所有组件进行交互。 Horizon
是图形用户界面,管理员可以很容易地使用它来管理所有项目。 Keystone
处理授权用户的管理, Neutron 定义提供组件之间连接的网络。
Nova 被认为是 OpenStack
的核心,负责处理工作负载的流程。它的计算实例通常需要进行某种形式的持久存储,它可以是基于块的
( Cinder ) 或基于对象的 ( Swift )。 Nova
还需要一个镜像来启动一个实例。 Glance
将会处理这个请求,它可以有选择地使用 Swift 作为其存储后端。

OpenStack
架构一直努力使每个项目尽可能的独立,这使得用户可以选择只部署一个功能子集,并将它与提供类似或互补功能的其他系统和技术相集成。然而,这种独立性不应掩盖这样一个事实:全功能的私有云很可能需要使用几乎所有功能才可以正常运作,而且各元素需要被紧密地集成。

传统的软件生态模式是用户和开发者之间隔着销售、产品经理等角色,而
OpenStack 等开源的模式打破了这样一种模式, OS
只提供最最底层的框架,剩余一切都围绕着用户,用户可参与从设计、编码、测试、到运维的各种阶段。而这样的模式生命力是最强的。

三. OpenStack 的核心优势

如果仅仅是便宜,那么 OpenStack 对于企业似乎就没那么大的价值了。相反,
OpenStack 提供了一个非常好的有关如何来打造类似于主要公有云比如亚马逊(
AWS )和 Google Cloud Platform ( GCP )的弹性私有云的样板。就像 Hadoop
将 Google 的 MapReduce (加上它的参考架构)推向大众一样, OpenStack 将
AWS/GCP 式样的的基础架构即服务( IaaS
)推向了每个用户。它就是能实现企业内部 DevOps 的终极平台。

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

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

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

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

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

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

  • 2.健壮的管理和安全模型

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

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

OneAPM
的出现,使得企业可以缩减庞大运维团队的开支,
OneAPM
的产品能帮助你进行应用性能分析、告警、日志分析记录,并能实现代码级的故障诊断。

  • 3.开放的架构

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

  • 4.混合云兼容性

目前环境下,混合云兼具私有云安全性与公有云的弹性扩展能力,混合云必然成为企业云部署的第一选择。根据应用类别和业务特点,将关键应用、性能敏感型、中高密级应用部署在私有云,其他应用部署在公有云;将同一个应用的不同层部署在不同云中,时延敏感业务就近用户部署,提升最终用户体验;
Web Front 支持 Web
服务灵活扩展,集中控制关键数据;突发型应用,私有云资源不足时(如 Web
网站),向公有云临时租借资源。
混合云的难点在于解决应用的移植性问题。如果你需要一个公有云和私有云组合而成的混合云,不管应用在某个云中被开发,还是要在两个云之间做迁移,或者从一个云到另一个云,应用的可移植性都是必须的。当你选定一个应用以及它的云原生的自动化框架,并将它们从一个云移动到另一个云中,一些关键的东西必须保持一致:

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

5.可扩展的弹性架构

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

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

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

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

  • 6.全面的支持和服务

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

参考文献: The 6 Requirements of Enterprise-grade
OpenStack

OneAPM
是中国基础软件领域的新兴领军企业。致力于帮助企业用户提供全栈式的性能管理以及
IT 运维管理服务,通过一个探针就能够完成日志分析、安全防护、
APM
基础组件监控、集成报警以及大数据分析等功能。想阅读更多优秀文章,请访问
OneAPM
官方技术博客 OneAPM
官方技术博客

本文转自 OneAPM 官方博客

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图