OpenStack与ZStack深度对比：架构、部署、计算存储与网络、运维监控等

摘要

OpenStack从2010年开源至今，已经走过8个年头，其正在进入主流企业市场，但该项目依然面临较难部署和管理的老问题。有一点是毫无疑问的，那就是OpenStack保持着高速增长的态势，超过585家企业，接近4万人通过各种方式支持着这个超过2000万行的开源项目的持续发展。

ZStack项目初始于2015年，相对OpenStack要年轻很多，由于其具有易用、稳定、灵活、超高性能等特点，迅速成为市场的新宠儿，其功能在不断的完善，其性能在不断的加强。发展以及成熟的速度远快于OpenStack，其市场认可程度不弱于OpenStack。

介绍

OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API以进行集成。开源于2010年，当前最新版本Queens。

ZStack是下一代开源的云计算IaaS（基础架构即服务）软件。它主要面向的是未来的智能数据中心，通过提供全完善的API来管理包括计算、存储和网络在内的数据中心的各种资源。ZStack具有易用、稳定、灵活、超高性能等特点。分为商业版以及开源社区版本。起步于2015年，当前最新版本2.5.1。

架构

OpenStack架构图如下图。以前有个朋友吐槽说，这是一群小蜘蛛在结网，虽然有序，但每一个小蜘蛛的网都不尽相同。当这些网连起来的时候，就会让人看的眼花缭乱。因为每一次的请求任务都需要在各个子系统之间来回协调，任何一处出问题，都将导致创建失败。比如当创建虚拟机的时候，需要从认证，计算，网络，镜像，存储等环节都走通，否则就不要想创建一个健康运行的虚拟机。下面的图展示出了OpenStack的主要的几个组件的调用关系。

消息队列在OpenStack整个架构中扮演着至关重要的作用，正是因为OpenStack部署的灵活性、模块的松耦合、架构的扁平化，反而使OpenStack更加依赖于消息队列，所以消息队列收发消息的性能和消息队列的HA能力直接影响OpenStack的性能。最典型的场景就是如果当大量的监控数据充斥着消息队列时，平台性能将呈现直线下滑。下图展示出了OpenStack中消息队列关系。

OpenStack相比，ZStack服务之间的交互调用要简单很多，消息队列为核心，所有服务交互都通过消息队列，结构拓扑呈现星状，简单直接，因而核心出问题就会影响到大多数的功能。但全异步架构以及无状态服务大大加强了平台的健壮。ZStack的强一致性使其很简单就可以实现HA，而无需像OpenStack那样必须借助第三方工具实现HA高可用。下图展示了ZStack的星形拓扑结构。

部署

安装一直是OpenStack的几大难题之一，尤其是对刚接触到OpenStack的新人而言。这也客观上提高了大家学习OpenStack云计算的技术门槛。笔者13年开始接触OpenStack，有幸在公司申请到三台高配的物理服务器一个月的使用权限。作为一个OpenStack小白，当时的规划是一星期的安装，一星期的架构学习，两星期的综合学习，最后变成一个月都是在安装。想想，直到现在都是满眼心酸泪。当然这都是早时期，现在针对部署与安装也有了很多工具，比如puppet，ansible，容器化的kolla。虽然这些工具也大大简化了OpenStack的部署安装，但是依然却无法解决openstack运维的复杂度，更不用说后续新版本的升级。

安装部署以及升级对ZStack而言，从来都是简单，快速，无感。ZStack自定义了ISO，封装了网络配置以及ZStack服务管理的命令，哪怕是一个运维小白也能够很快安装好一个ZSack平台，不需要太长的学习周期。同时官方文档以及案例都很齐全，有任何问题只要在官方群里留言都能获取ZStack一线工程师快速的恢复。

计算、存储与网络

OpenStack的计算，存储，网络组件分别是nova，cinder，neutron。其中nova作为最早期的项目，其成熟度已经很高，稳定性已经大大加强，功能也在不停的扩展。比如GPU支持，裸机管理，heat编排，容器编排，大数据计算等。cinder作为核心的块存储模块在openstack中提供着至关重要的角色，后端支持ceph，lvm，glusterfs，nfs以及各种商业存储，配置比较麻烦，需要更改配置文件，调试，重启服务，甚至是更改代码去适配对应的存储。至于云主机默认是不支持增量快照的，只支持全量备份功能，针对传统的系统盘庞大的情况，会影响效率，浪费磁盘空间。

neutron是网络管理模块，底层支持flat，vlan，vxlan，gre等网络模式。neutron支持多种高级特性，比如vpn功能，负载均衡功能，HA功能，DVR功能。可用性还是比较强的，而且针对很多厂商的网络设备都有plugin支持。当然，neutron的效率，复杂性也是容易让人诟病的，至今，已经有多次的代码重构。当然，重构也不仅仅是因为代码混乱复杂以及效率低的问题，同时也是为了能够与openstack的其他项目，如容器的kuryr等项目更好的结合使用。

相对而言ZStack就会简单容易很多。ZStack在一键安装之后，无论是计算，存储还是网络，都只要在页面控制台点击操作相应的资源，不涉及到任何后端复杂配置修改。配置修改实时生效，也不需要重启任何服务。ZStack计算节点页面添加，拥有动态扩容，实时监控，自动愈合等多种特性，无需过多的人工参与。不管是开源的ceph，glusterf，nfs还是商业的Fusionstor，san光钎存储，页面直接添加。云主机与云盘都支持增量快照，全量备份功能，这一点与OpenStack完全相反。

ZStack的网络模型是二层+三层，二层决定了是novlan,vlan,vxlan的类型，三层决定了是扁平，路由，vpc的类型。网络灵活配置。同时，物理网卡支持复用，可以创建多个同种类型的二层网络。支持分布式网络，可以缓解dns的压力与优化东西向的流量，云路由网络以及vpc网络是使用优化过的vyos作为平台路由器，配置简单，支持多种高级特性，可以支持热迁移，支持分布式，稳定性以及性能都不错。虽然不支持HA功能，但是自愈能力强。vyos本质上是虚拟机，因此会占一定的宿主机资源，性能与物理设备相比较而言会有部分损耗。

运维监控

早期的OpenStack云平台监控项目Ceilometer被一分为四（Ceilometer、Gnocchi、Aodh、Panko），各司其职！其中Ceilometer负责采集计量数据并加工预处理；Gnocchi主要用来提供资源索引和存储时序计量数据；Aodh主要提供预警和计量通知服务；Panko主要提供事件存储服务。促成Ceilometer分裂的主要原因是性能开销很大，并且随着时间的推移性能瓶颈会愈加明显直至奔溃。至于底层运维监控可以使用zabbix，也可以集成到现有的ceilometer体系中。至今，OpenStack已经发展到Queens版本，监控依然是其性能瓶颈之一。dashboard默认没有集成监控与告警，需要额外的自定义开发。

ZStack的监控方案采用开源prometheus和influxdb，监控信息存储在prometheus数据库，告警则使用prometheus自带的alertmanager，至于事件以及审计等信息存储在influxdb与mysql数据库中。平台拥有大多数的监控项，支持自定义告警项添加，但暂时还未支持模板方式批量添加监控告警项。借助于prometheus的高效率的函数计算以及汇聚，zstack也提供了监控大屏和监控top5的功能，有助于实时分析平台的资源使用情况。当然，openstack也可以借助prometheus或者zabbix实现类似的功能。

其他

OpenStack是当前最流行，同时也是目前最为流行的开源云操作系统框架。OpenStack提供的不仅仅提供IAAS的服务，同时也提供PAAS服务，不管其孵化项目是否成熟，但至少拥有了一个开放，廉价的解决方案，比如数据库服务，容器服务，大数据处理，裸机管理，计费管理等项目。国内的也有公有云等借助或者借鉴OpenStack，而实现了自身的安全稳定的公有云平台。而也有专业的OpenStack厂商实现了私有云或混合云平台。近几年来，OpenStack借助国家去IOE的策略，已经遍布多家银行，政企以及运营商。

相对OpenStack，ZStack依然很年轻。其核心以是私有云与混合云为主，主要提供IAAS服务，核心代码开源，提供企业版本。几乎每个月都会发布一个新版本，但是升级基本不会存在任何问题，一句命令全部搞定，这一点是OpenStack远远比不上的。尽管如此，当前在某些方面，ZStack还是无法替代openstack相比，比如容器服务，数据库服务，大数据管理等。至于以后ZStack是否会添加新功能，那要等以后再说。

总结

本文主要是从运维管理，计算，存储，网络等方面对OpenStack与ZStack进行了简单的对比，两者各有优劣。笔者认为，OpenStack适合有研发能力，有较高的运维能力，有PAAS甚至是SAAS需要的组织。ZStack能够提供一整套安全可靠，方便快捷的私有云或者混合云环境，ZStack更加适合资源有限，没有办法投入太多在研发以及运维上的组织。当然，这也并不是绝对的，利用ZStack或者OpenStack实现私有云都不乏案例。至于是选择OpenStack还是ZStack还是要结合真实的需求。

作者：祝祥新钛云服运维架构师

十年运维经验，曾任刻通云运维工程师、微烛云和某互联网金融平台首席运维架构师。拥有OpenStack、CCIE、阿里云、ZStack等技术认证。有上万台云主机，PB级别分布式存储运维经验。熟悉各种虚拟化技术，软硬件，网络，容器编排等技术，拥有python开发经验。热爱各种开源技术。

https://www.ysidc.top 云速博客,数据库,云速,虚拟主机,域名注册,域名,云服务器,云主机,云建站,ysidc.top

OpenStack与ZStack深度对比：架构、部署、计算存储与网络、运维监控等相关推荐

智和信通，部署智慧交通运维系统，构建一站式运维监控平台
交通作为国民经济和社会发展的基础性.先行性产业,在整个社会经济.民生发展中占有举足轻重的地位,随着包括5G基站建设.城际高速铁路和城市轨道交通.大数据中心.工业互联网在内的新基建按下加速键,轨道交通云 ...
python 运维管理架构_企业运维监控平台架构设计与实现（ganglia篇）
一.Cacti/Nagios/Zabbix/centreon/Ganglia之抉择 1.cacti Cacti是一套基于PHP,MySQL,SNMP及RRDTool开发的网络流量监测图形分析工具. 简 ...
ChinaSoft 论坛巡礼 | 泛在计算时代的智能化运维
2022年CCF中国软件大会(CCF ChinaSoft 2022)将于2022年11月25-27日在上海国际会议中心举行.预期将有林惠民.陈左宁.邬江兴.何积丰.梅宏.吕建.柴洪峰.王怀民.郑纬民. ...
2022 CCF中国软件大会（CCF Chinasoft）“泛在计算时代的智能化运维”论坛成功召开...
2022年11月27日,2022 CCF中国软件大会(CCF ChinaSoft)泛在计算时代的智能化运维论坛成功举办.本次大会由中国计算机学会(CCF)主办,CCF软件工程专委会.系统软件专委会.形 ...
开源运维管理软件排名_企业运维监控平台架构设计与实现（ganglia篇）
一.Cacti/Nagios/Zabbix/centreon/Ganglia之抉择 1.cacti Cacti是一套基于PHP,MySQL,SNMP及RRDTool开发的网络流量监测图形分析工具. 简 ...
Kafka教程（一）基础入门：基本概念、安装部署、运维监控、命令行使用
Kafka教程(一)基础入门 1.基本概念背景领英->Apache 分布式.消息发布订阅系统角色存储系统消息系统流处理平台-Kafka Streaming 特点高吞吐.低延迟 cg ...
【云原生之Docker实战】使用docker部署nightingale运维监控平台
[云原生之Docker实战]使用docker部署nightingale运维监控平台一.nightingale平台介绍 1.nightingale简介 2.nightingale特点 3.nighti ...
运维监控软件的选择对比----Zabbix vs Prometheus
近期遇到项目需要定制开发运维监控软件,考虑到监控的规模比较大,数量比较多,所以不能随随便便找个开源的监控软件就能应付了事的,还是要认真对待. N年以前笔者曾经使用过Nagios,catti以及MRTG ...
可快速部署的轻量级运维监控系统——WGCLOUD
WGCLOUD,是国人开源的一款运维监控系统,轻巧实用,具备高性能.自动化等特点,对新手来讲,几乎没有什么学习成本,上手可用,部署方便. 这是一张wgcloud运行的数据通信图 WGCLOUD的ser ...

OpenStack与ZStack深度对比：架构、部署、计算存储与网络、运维监控等

OpenStack与ZStack深度对比：架构、部署、计算存储与网络、运维监控等相关推荐

最新文章

热门文章