zstack是基于openstack架构么，云主机 sf

众所周知，云计算提供三种服务模式：基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。当前IaaS相关技术热火朝天，一大批商业和开源的公有云和私有云解决方案相继涌现。

笔者从大学时代开始接触GNU/Linux，学习LFS/Gentoo源码编译的发行版，构建科研计算HPC集 群。2012年开始从事IaaS领域，接触CloudStack和OpenStack，由于工作的原因使用CloudStack较为深入。在学习过程中常常在CloudStack社区发邮件提问，同时也参与邮件讨论。实践上，部署过若干套KVM+Ceph的私有云方案并交付应用，积累一定调试和故障排错经验。然而，ZStack成为当前较为耀眼的开源IaaS方案，其开发者张鑫（Frank Zhang）就曾在Cloud.com和Citrix从事CloudStack架构设计和开发工作。正所谓“青出于蓝而胜于蓝”，ZStack能不能超越IaaS前辈们成为“最后”一个Stack？（ZStack的“Z”取义字母表最后一个字母，意为“最后”，与ZFS意思相似。）

本文将对CloudStack与ZStack功能与架构进行浅析，探讨这两个开源IaaS方案的特点，同时提供两者使用模拟器的方式，并在模拟器的场景做一些性能测试。

CloudStack架构介绍

根据CloudStack官网（http://cloudstack.apache.org/）介绍“Apache CloudStack is open source software designed to deploy and manage large networks of virtual machines, as a highly available, highly scalable Infrastructure as a Service （IaaS）cloud computing platform”，可以了解到，CloudStack是一个开源的提供IaaS服务的解决方案，强调的是高可用和高扩展的能力。CloudStack前身是Cloud.com，2011年7月被Citrix思杰收购并100%开源。2012年4月，Citrix思杰宣布把CloudStack交给Apache软件基金会管理以及开发。目前CloudStack采用Apache License v2.0开源许可证发布源码，源码托管：https://github.com/apache/cloudstack/。

当前CloudStack最新版本为4.5.1，支持虚拟化解决方案: XenServer，KVM/LXC，VMware vShpere和Hyper-V（OVM3将在4.6版本支持，即目前的master分支）。存储方面，CloudStack从功能上将存储设施分为主存储（Primary Storage）和备份存储（Secondary Storage）。其中，主存储存放虚拟机当前挂载的虚拟 磁盘（虚拟卷Volume，不同的虚拟化支持的主存储类 型略有不同，具体情况如表1所示：结合实际部署方案，采用VMware ESXi和XenServer虚拟化场景较多使用iSCSI和FC存储，而采用KVM虚拟化场景较多使用ShareMountpoint和NFC。CloudStack在备份存储方面，支持NFS、SMB/CIFS、兼容S3和Swift（Ceph RGW可提供接口访问）。

表1 CloudStack不同虚拟化支持的主存储类型

以上简单介绍了虚拟化和存储支持方面，接下来了解网络结构。CloudStack网络模式分为简单网络（Basic Networking）和高级网络（Advanced Networking），其中前者提供在一个区域（Zone）内无隔离的网络环境，后者能够在一个区域内提供隔离的网络环境。这里要注意的是，在建立一个区域时就需要选择网络模式，而且选择后不能变更，除非要重新部署。对于隔离方案，CloudStack支持了三种不同的二层隔离：VLAN、GRE和VXLAN。CloudStack在简单网络和高级网络中均可支持安全组功能。CloudStack网络功能的实现是通过虚拟路由的方式提供服务（Service VM），提供网络三层、负载均衡服务和VPN接入等服务，实现类似AWS VPC的网络功能。除此之外，CloudStack还接收来自BigSwitch、Cisco、F5、Juniper、Netscaler、Nicira和OpenDayLight等网络解决方案商（组织）提供的插件服务，通过自身产品或解决方案提供上述的网络服务，提高网络性能和组网灵活性。顺带一句，当前CloudStack已经实现通过Open vSwitch的分布式路由功能。

实际上，笔者遇到很多朋友在私有云环境下部署CloudStack采用“高级网络+VLAN”的方案（可选安全组）。首先，高级网络能够支持网络隔离，是多租户和VPC方案的必然选择。其次，VLAN是最为简单的隔离方案，在小规模私有云情况下能够满足需求，并能与企业内部原有的网络互访。至于VXLAN Overlay和Open vSwitch实现分布式路由功能，在一定的规模下会考虑，但需要网络研发人员介入才能保障稳定运行。图1是CloudStack高级网络场景下VLAN网络隔离示意图：图中的计算节点有两块物理网卡，NIC1是管理和存储网络，NIC2是业务网络。如果计算节点同时具有三个物理网卡的时候，用户可以将存储网络和管理网络分离到不同的物理网络上，通过设置Jumbo Frame巨型帧，实现一般意义上的“三网分离”。实际生产环境中，由于对网络带宽和高可用的要求，用户常做双网口绑定，笔者建议选用mode 1（master-backup）或者mode 4（LACP）的模式。在一般场景下，mode 4模式也适合在Ceph分布式存储环境下使用；但是，在iSCSI场景中，由于应用级别已经具备多路径选择（主备或轮询模式），所以不需要进行网络绑定了，如果绑定，甚至可能造成性能下降。

图1 CloudStack高级网络场景下VLAN网络隔离示意图

另外，CloudStack是采用VM as a Service的方案， SSVM和CPVM提供了备份存储服务（Secondary Storage Service）和控制台服务（Console Proxy Service），而虚拟路由（Virtual Router）提供灵活的DHCP，Gateway，DNS和VPN等三层服务。图1中的VR就是一个路由器，形成VPC网络结构。

ZStack架构介绍

ZStack是一个全新的开源IaaS解决方案，发布于2015年4月，主要开发者为张鑫和尤永康。根据官方网站（http://zstack.org/）介绍，ZStack is open source IaaS(infrastructure as a service) software aiming to automate data centers, managing resources of compute, storage, and networking all by APIs，可以了解到ZStack目标是解决数据中心自动化问题，并能通过API实现对计算、存储和网络资源的分配。CSDN上有一篇张鑫撰写的文章《直戳OpenStack痛处？IaaS开源新兵ZStack架构设计全解析》（http://www.csdn.net/article/2015-04-13/2824443），同时也有一篇用户文档《ZStack深度试用：部署、架构与网络及其与OpenStack的对比》，（http://www.csdn.net/article/2015-05-18/2824690）。关于ZStack架构设计可品读官方博客（http://zstack.org/blog/）。在ZStack官方公布的技术文档中，用户可以发现有很多不同于现有IaaS产品的架构设计，其主要特色为全异步架构、微服务和一致性哈希，可承载高并发的API请求，具备稳定的架构、非常简化的部署和升级的特点。ZStack同样采用Apache License v2.0发布源码，源码托管：https://github.com/zstackorg/zstack。图2为ZStack架构图。

图2 ZStack架构图

当前ZStack最新版本为0.8.0，暂时只支持KVM虚拟化。存储方面和CloudStack类似，逻辑上分为主存储（Primary Storage）和备份存储（Backup Storage）。

主存储支持NFS和iSCSI存储协议的共享存储方案，并支持虚拟化节点使用本地磁盘（根据ZStack Roadmap，0.9版本将支持Ceph RBD块存储)。备份存储则通过SFTP进行数据传输。ZStack实现了基础的iSCSI存储模型，类似OpenStack中的Cinder默认的存储模型。Cinder默认的存储模型为iSCSI+LVM，通过LVM划分的裸设备映射到iSCSI供计算节点访问（qemu-kvm直接访问块设备），而ZStack则通过Btrfs文件系统提供裸设备文件，通过iSCSI提供给计算节点访问。采用Btrfs，能利用其COW的写时复制特性，实现秒级的快照、回滚和克隆等操作。根据这样的iSCSI存储模型，ZStack可以较为轻巧地使用iSCSI存储，但前提是存储设备提供API访问特性。在ZStack实际测试和使用过程中，有不少朋友会问为什么不支持常规的iSCSI和FC存储。事实上要通过部署GFS/CLVM、OCFS2等具备分布式锁管理的共享文件系统才能解决共享读写问题（CloudStack+KVM场景提供ShareMountPoint就是为了兼容共享文件系统的访问，而XenServer对iSCSI和FC采用CLVM，VMware ESXi采用VMFS）。目前，ZStack支持的Primary Storage存储类型如表2所示。

表2 ZStack支持的主存储类型

网络方面，相比CloudStack只能在初始化Zone的候选择基础网络或者高级网络，ZStack支持类似EC2的弹性网络、Flat网络、多级网络和安全组特性，未来将会支持VPC。ZStack通过设定L2和L3实现对网络的自由使用。简单来说：在目标集群里所有计算节点的eth1网口提供网络接入（也可以把网卡做bond后提供bond网络设备符），首先建立一个L2网络（VLAN是可选，具体实现是建立一个Linux Bridge），然后用户建立一个L3网络并在指定L2网络上选择需要的三层服务，例如DHCP、SNAT、DNS、PortForward、ElasticIP和Security Group等。ZStack的网络模型把CloudStack的基础网络和高级网络模型统一实现，既可支持无隔离也可支持隔离的网络模型。目前，ZStack只支持VLAN网络隔离模式，未来版本会支持VXLAN。

图3是ZStack的Virtual Router和Guest VM的逻辑连接图。聪明的读者会发现，这个VM as a Service的模型 和CloudStack类似（为什么说类似，因为CloudStack操控VR是通过计算节点的cloud0网桥，此网桥是私有 的；而ZStack对VR的管理网络是网络直接访问的）。

图3 ZStack的Virtual Router和Guest VM的逻辑连接图

模拟器部署

如何管理IaaS是一个相当大的话题。故障发现、自动迁移、资源平衡和平滑升级等，都考验IaaS解决方案的强壮性。然而，除IaaS本身的管理服务，用户还需要留意IaaS底层基础设施的稳定性，操作系统发行版、内核版本、虚拟化软件版本和存储解决方案等，一不留神就会埋下隐患。下面我们专注IaaS本身，对CloudStack和ZStack进行模拟器并发测试。

一般在开发IaaS时候，开发团队为了分工，让一部分开发者专注用户API交互和逻辑处理层，而另一部分开发者专注基础资源的调用实现，此时会引入模拟器（Simulator）。例如，前端开发、资源分配、资源平衡和用户管理，基于模拟器开发将提高工作效率。

正因如此，CloudStack、OpenStack和ZStack都有自家的模拟器实现。在CloudStack中，模拟器称为“Marvin”，能够在Maven的开发者模式下（也可以在生成二进制安装文件时打包模拟器），不用直接添加具体的物理资源，只需要执行Marvin里的自动初始化配置，可以选择源码setup/dev下的advanced.cfg、advancedsg.cfg、basic.cfg、local.cfg和s3.cfg配置脚本，用户也可以参考这些配置定义场景，以初始化一个Zone并添加各类资源，这些资源都是虚拟的，但不妨碍CloudStack逻辑层的测试，包括创建云主机、卷设备、网络、计算方案和网络方案等。另一方面，结合CloudMonkey，可以测试CloudStack纯软件的调用过程和并发能力。

Cloudstack在CentOS 7.1使用模拟器

安装依赖包：

yum groupinstall "Development Tools"
yum install java-1.7.0-openjdk-devel genisoimage mariadb mariadb-ser ver ws-commons-util MySQL- python tomcat createrepo maven vim wget

配置环境：

sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config
setenforce 0
service firewalld stop && chkconfig firewalld off

启动数据库：

service mariadb start

下载&解压：

wget -c http://mirrors.aliyun.com/apache/cloudstack/releases/4.4.4/apache-cloudstack-4.4.4-src.tar.bz2
tar xf apache-cloudstack-4.4.4-src.tar.bz2
cd apache-cloudstack-4.4.4-src

运行编译：

mvn -Pdeveloper -Dsimulator -DskipTests
clean install

初始化数据库：

mvn -Pdeveloper -pl developer -Ddeploydb

初始化模拟器数据库：

mvn -Pdeveloper -pl developer -Ddeploydb-simulator

安装依赖：

yum install python-devel 
pip install requests paramiko nose ddt

编译并安装Marvin：

mvn -P developer -pl :cloud-marvin
cd tools/marvin/
python setup.py build
python setup.py install
cd ../../

运行CloudStack开发模式：

mvn -pl client jetty:run -Dsimulator

通过浏览器登录：http://ip:8080/client/，默认用户名密码：admin/password

另开终端执行建立高级网络：

python ./tools/marvin/marvin/deployDataCenter.py -i setup/dev/advanced.cfg

接下来建立完成后则可以看到相关资源状态。

接下来建议安装CloudMonkey 5.2.0版本（百度云盘：http://pan.baidu.com/s/1jWey6 密码：aois），具体安装过程参看其源码包的README.md文件。

Cloud Monkey安装完成后首次运行会生成 /root /. cloudmonkey/config配置文件：

[core]
profile = local
asyncblock = true
paramcompletion = true
history_file = /root/.cloudmonkey/history
cache_file = /root/.cloudmonkey/cache
log_file = /root/.cloudmonkey/log

[ui]
color = false
prompt = ? >
display = default

[local]
username = admin
domain = /
apikey =
url = http://localhost:8080/client/api
expires = 600
secretkey =
timeout = 3600
password = password
verifysslcert = true

此处更改color为false。默认用户名和密码为admin/password，不需要变更。

在本次测试中，笔者主要测试了在大规模并发情况下，CloudStack和ZStack能够多快地响应VM创建请求。

CloudStack批量创建VM的方法

这里提供两个批量并发脚本，读者可以根据CloudStack实验环境设置以下ID：

[root@cloudstack ~]# cat createvm.sh
----------------------------------------
#!/bin/bash

DEFAULT_SFID=b7dd8e60-3c20-4b68-8147-054f6537ab55
DEFAULT_ZONEID=5e61db8d-8be6-4d6b-8355-fa4003435794
DEFAULT_TEMPID=288a6abc-29da-11e5-b922-5254009326e9

for i in `seq 100`
do
cloudmonkey deploy virtualmachine serviceofferingid=${DEFAULT_SFID}  zoneid=${DEFAULT_ZONEID} templateid=${DEFAULT_TEMPID} 1>/dev/null 2>&1 &
done
-----------------------------------

[root@cloudstack ~]# cat destroyvm.sh 
-----------------------------------
#!/bin/bash

VMS=`cloudmonkey list virtualmachines  | grep "^id =" | awk '{print $3}'`
for i in $VMS
do
cloudmonkey destroy virtualmachine expunge=true id=$i 1>/dev/null 2>&1 &
done
-----------------------------------

ZStack在CentOS 7.1使用模拟器

ZStack官网发布了使用模拟器的方法（http://zstack.org/cn_blog/build-zstack-cloud-simulator- environemnt.html）按照上面的部署方式可建立模拟环境。相比CloudStack中需要单独编译模拟器， ZStack的模拟器搭建显得非常容易，和搭建一套非模拟器的环境非常相似。

ZStack批量创建VM的方法

[root@zstack ~]# cat zs-create_multi_vm.sh 
-------------------------------------------- 
#!/bin/bash

zstack-cli LogInByAccount accountName=admin password=password
instanceOfferingUuid=b3eee2182d2648cd9576c1f1df9a8c13
imageUuid=ecf0a34db2314d8d910e6fec0d748662
l3NetworkUuids=1ff2af5dacd54744b3b8654de7a1685e

for i in `seq 1 20`
do
    zstack-cli CreateVmInstance name=VM1 instanceOfferingUuid=$instanceOfferingUuid imageUuid=$imageUuid l3NetworkUuids=$l3NetworkUuids &
done
--------------------------------------------

[root@zstack ~]# cat zs-delete_all_vm.sh 
-------------------------------------------- 
#!/bin/bash

zstack-cli LogInByAccount accountName=admin password=password

LIST=`zstack-cli QueryVmInstance | jq .inventories.uuid`

for i in $LIST
do
   zstack-cli DestroyVmInstance uuid=$i &
#    ITEM=`jq .inventories[$i].uuid l.json`
#    zstack-cli DestroyVmInstance uuid=${ITEM} &
done
--------------------------------------------

性能测试

以下开始对CloudStack和ZStack进行并发测试。测试硬件条件如表3所示。

表3 测试硬件条件

在测试过程中，为实现并发提交任务，通过CloudMonkey和zstack-cli发出的命令添加”&”让其后台执行。然而，如果把CLI命令置于后台执行，将不能正确统计执行完成时间。目前比较简单的方案是，在先启动一个定时器，定时轮询CloudMonkey和zstack-cli进程的持续出现，最后统计数目就能估算并发过程的时间。轮询脚本如下：

[root@zstack ~]# cat zstack-time.sh 
-------------------------------------------------------- 
#!/bin/bash

rm -rf zstack-run-time.dat
while [ 1 ]; do
   sleep 0.05
   NUM=`ps -ef | grep zstack-cli | wc -l`
   if [ "$NUM" -gt 1 ]; then
      echo "zstack-cli runing !" >> zstack-run-time.dat
   fi
done
--------------------------------------------------------

[root@cloudstack ~]# cat cloudstack-time.sh
--------------------------------------------------------  
#!/bin/bash

while [ 1 ]; do
   sleep 0.05
   NUM=`ps -ef | grep cloudmonkey | wc -l`
   if [ "$NUM" -gt 1 ]; then
      echo "cloudmonkey runing !" >> cloudstack-run-time.dat
   fi
done
-------------------------------------------------------- 

以上测试均在未改变CentOS 7.1内核参数和JVM运行参数，并且保持CloudStack和ZStack默认配置。从图4可见，ZStack作为开源IaaS解决方案新秀，拥有全异步的特性，确实在并发效率方面占有一定优势。CloudStack表现较为一般，提交的作业以队列形式执行。在并发量为500情况下，CloudStack只创建了310个虚拟机，并没有完成并发任务，如图5所示。

图4 CloudStack与ZStack并发测试结果对比

图5 CloudStack并发测试表现

总结

通过上述的架构介绍和性能对比，浅析了CloudStack和ZStack。目前，CloudStack功能较为丰富，应用的案例较多，网络支持厂商较多，并经过市场验证。ZStack作为新的IaaS解决方案，在功能开发迭代方面较快，性能表现优异。不过ZStack起步较晚，不知其表现出来的架构和性能优势是否能赢取用户和市场，让我们拭目以待。

参考文献：

作者简介：郭华星，华南理工大学计算机科学与工程学院在职硕士，目前就职于某交通领域企业，从事云计算IaaS、KVM和Ceph相关工作，Ceph中国社区活跃成员，曾发布CloudStack、Ceph和Calamari相关的离线安装ISO。（责任编辑：周建丁zhoujd@csdn.net）