ZStack深度试用：部署、架构与网络及其与OpenStack的对比_zstack和openstack的关系 - CSDN文库

103 浏览量更新于2023-05-03 评论收藏 641KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

ZStack深度试用：部署、架构与网络及其与深度试用：部署、架构与网络及其与OpenStack的对比的对比

摘要：本文是开源IaaS软件ZStack的深度试用报告，分别从部署、架构和网络三个层面分享作者的试用体验，并与

OpenStack进行简单的对比，文章最后也对ZStack的改进方向提出了自己的思考。

【编者按】针对采用OpenStack部署云平台的复杂性，CSDN此前介绍过的ZStack是另外一种解决方案。本文是

ZStack的深度试用报告，分别从部署、架构和网络三个层面介绍作者的试用体验，并与OpenStack进行简单对比，文

章最后也对ZStack的改进方向提出了思考。以下为全文内容：

“这是最好的时代，也是最坏的时代”。这句名言也是当前云计算大环境的真实写照。云计算给企业带来极大的便利，不

但能够充分利用现有的资源，而且能够把资源（计算、存储、网络）实现池化，像自来水一样便捷、精确地使用，形

成了新的资源计费（商业）模式。但是，如何有效地、快速地把资源池化管理，这是摆在管理者和技术人员面前的一

道难题。当前整个云生态，最成功的案例莫过于Amazon AWS 和开源的OpenStack。AWS可以说是云计算的鼻祖，它

的成功毋庸置疑，不夸张地说，是它引领了云计算的时代；但它是闭源的，我们无法窥探它内部的实现逻辑。直到开

源的OpenStack的出现，云计算才可以说“飞入寻常百姓家”了。OpenStack让整个云市场开始红火起来，各种云如雨后

春笋般冒了出来。

随着对OpenStack的深度普及，它在某些方面的弊端也不断被管理层和技术人员所提及。整个OpenStack服务组件不

断增加，新的功能陆续被扩展，各种厂商之间不断角逐，都想主导OpenStack的走向（使之符合自己的利益），而中

小企业由于缺乏技术力量，越来越玩不转庞大的OpenStack，原来期待的易用性、稳定性似乎逐渐地变成了奢望（或

者说过往）。作为OpenStack使用者的我，也蒙生了疑问：OpenStack是不是还依然适合我们的使用场景，是否有别

的替代品？在一次不经意的瞬间，发现了一个叫ZStack的云平台，在其官网赫然写着 “We name our project as ZStack

because we hope it's the last effort to make a simple, reliable, and flexible IaaS software.”抱着试一试的心态，开始了

我的ZStack之旅。

部署篇

说到部署，吐嘈下OpenStack。对于一个初次体验者，看到OpenStack浩瀚的部署手册，估计会使部分体验者望而生

畏。被强烈求知欲驱使着继续部署的人们，一步一步“复制”、“粘贴”手册里的命令（有些可能还不理解），硬件着头皮

继续前进。最后满心期待正常的DASH界面，被一个个“error"伤得体无完肤。最终能正常进入WEB界面的寥寥无几。

虽然现在也出现了不少第三方的自动化部署工具（如RDO、fuel等），但也涉及到复杂的配置（主要是OpenStack融

合很多知识），对初次体验者也不是很友好。

ZStack的部署引导就显得那么简洁明了。在”Installation"篇，总共只有三个页面，分别是”Quick Installation"、

“Maunual Installation”、“Multi-node Installation"。对初次体验者，使用“Quick Installation"即可。ZStack作者提供了一

键安装的脚本，更为贴心地是，为国内“特殊”的网络环境，定制了相应的套餐方案。

接下来开始我们一键安装部署之旅。

wget -O install-zstack.sh http://download.zstack.org/install.sh

sudo bash install-zstack.sh -a -R http://pypi.douban.com/simple/ -f http://7xi3lj.com1.z0.glb.clouddn.com/zstack-all-

in-one-0.6.2.tgz

“人品”差点的话，可能会出现如下情景（还是拜我们“特殊”的网络环境所赐，(╯﹏╰)）

传统的云管理平台在扩展方面有其特有的软肋--slow task。在并发不高的情况下，体现不是很明显，但批量的任务创建

时（如创建虚拟机），就会出现任务失败或超时。想必许多OpenStack使用者都会有这样的经历，满心期待能够顺利

创建虚拟机，却被一行行显眼的红色字体浇灭了热忱的心。其中的原因如下：

1. OpenStack里任务（或者说消息）传递的路径很长，比如以创建VM为例，一个任务要经历 " service -->

scheduler --> image service --> storage service --> network service --> hypervisor " 这条传递路径，每一环节都

要一定的耗时，大批量任务执行时，延迟效应就更明显，最后就出现任务失败。

2. 任务传递并非全异步。某些环节同步传递就会出现等待，进一步增加了任务时间。（关于同步与异步的区别，详

见 http://avaj.iteye.com/blog/151724）。下图展示一个实例：

ZStack在这方面做了改进，把服务之间的消息调用（或者API请求），以及服务内部代码方法之间的调用全部实现异步

架构，如下图所示：

全异步架构带来了效率上的提升，本人没有系统地测试（与OpenStack对比），但仅从感官上讲，在ZStack上创建一

台虚拟机，秒秒钟dash就显示创建成功了，那种享受，不言而喻。

无状态服务

在讲无状态服务之前，我先讲下有状态服务下的请求机制。这里的状态是指在有多个管理节点时，每个管理节点都会

有多个相同的微服务。那么微服务之间就要对自己管理资源的数量进行分配协商，向微服务发送请求的请求者也必须

知道是哪个微服务在管理哪个资源。话多必失，还是上图看看（我大学老师说过，一图胜千言）：

而在无状态服务下，这些事情交给hash ring处理，微服务之间无需知道自己或别人管了哪些资源。在请求里只需含一

个唯一的UUID，不再需要指出把请求提交给哪个微服务，集群内部会把请求“路由”到指定的微服务。如下图所示：

ZStack里，管理节点之间形成一个强一致的hash ring，每个节点都有一份包含所有节点信息（如节点UUID）的副本。

当新节点加入或者节点退出时，都会产生广播消息通知到其他节点，整个集群会重新动态平衡，形成新的强一致的

hash ring 。

ZStack自身强一致性的特性是其他IaaS软件（包括OpenStack）不可比拟的。OpenStack要实现服务的HA特性，必须

借助第三方高可用方案，比如keepalived+Haproxy或者pacemaker方案。诚然这些都承受了生产环境的考验，但无疑

给整个平台增加了复杂度。

剩余13页未读，继续阅读

评论0

weixin_38626080

粉丝: 8
资源: 973

会员权益专享

图片转文字

全年可省5，000元立即开通

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈