浅谈CloudStack与ZStack架构与性能
2015-08-28 20:16:22 
阿炯
众所周知，云计算提供三种服务模式：基础设施即服务(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官网介绍“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开源许可证发布源码，源码托管于此。
当前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月，主要开发者为张鑫和尤永康。根据官方网站介绍，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架构设计全解析》，同时也有一篇用户文档《ZStack深度试用：部署、架构与网络及其与OpenStack的对比》。关于ZStack架构设计可品读官方博客。在ZStack官方公布的技术文档中，用户可以发现有很多不同于现有IaaS产品的架构设计，其主要特色为全异步架构、微服务和一致性哈希，可承载高并发的API请求，具备稳定的架构、非常简化的部署和升级的特点。ZStack同样采用Apache License v2.0发布源码，源码托管于此。
图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官网发布了使用模拟器的方法 使用模拟器的方法，按照上面的部署方式可建立模拟环境。相比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、测试硬件条件
--------------------------------------------------------
#!/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起步较晚，不知其表现出来的架构和性能优势是否能赢取用户和市场，让我们拭目以待。
另附CSDN记者对话张鑫
CSDN：OpenStack生态已经比较成熟，公有云私有云的成功案例都有了，我们为何还需要ZStack项目？
张鑫：IaaS领域是时候需要新鲜血液了。
自亚马逊2006年发布EC2公有云以来，IaaS（基础架构即服务）领域持续创新，先后出现了Eucalyptus, CloudStack，OpenNebula这样的开源软件。到2010年OpenStack出现，整个创新达到了一个高潮。从业者都认为云计算的春天来了，认为传统企业可以很快的从上个世纪的IT架构中解脱出来，迅速迁移到由软件定义的数据中心。但让人大跌眼镜的是，5年过去了，Eucalyptus, CloudStack，OpenNebula已渐渐淡出人们的视线，OpenStack一统天下，却迟迟打不开企业软件的市场。就在去年，OpenStack的发起者Rackspace，宣布不再以纯IaaS提供商的身份进入市场，而是转向专注于核心业务“为客户管理服务”，在跟以亚马逊为首的公有云巨头的竞争中败下阵来。最近，著名OpenStack公司Nebula倒闭，给出的理由是“市场不成熟”，更是给整个IaaS产业浇了一盆冷水。一时间各种悲观论调四起，例如认为企业云市场根本不存在，又例如公有云最终统治世界，企业不再需要自己维护数据中心。
我于2010年加入Cloud.com，作为CloudStack前核心开发人员，一直紧密的关注整个产业以及各个开源IaaS软件，深深感到市场的需求是巨大的，但当前的产品离市场的要求差距很远。随着时间的推移，这个鸿沟越来越大，丝毫没有减小的迹象。
当前开源IaaS软件的痛点可以概括为四个方面：易用性差，不稳定，性能差，难扩展。而这四个方面又是阻碍市场接受IaaS软件的至关重要的因素。根据我多年来对各个项目的观察，认为导致目前状况的原因，并不是开源社区缺乏有才能的开发人员，而是这些项目起源太早，缺乏对市场的足够理解。这些项目早期都是盲目模仿亚马逊EC2模式，在快速开发功能的同时自然生长，用俗话说就是“摸着石头过河”，导致了在架构设计方面思考过少，累积了大量欠账。而前述的几个方面，又正是不从架构入手重新设计，就不能解决的问题。但我们又不能期望像OpenStack这样拥有几百万行代码的项目从底部推到重来。基于这样的现实，我认为不重新设计一款IaaS软件是无法解决已有的问题的。在退出了原来CloudStack的工作后，我跟搭档一起建立了ZStack，希望从根源上解决当今IaaS软件遇到的各种问题，为整个行业带来一款真正能打开企业市场的软件。
CSDN：能否介绍一下ZStack的市场目标，以及社区规划？
张鑫：ZStack的最终目的，并不是为喧闹的云市场添加更多的噱头，而是解决数据中心管理的一个刚需：即面对越来越多的硬件，如何管理它们，以及如何自动化这个管理的过程。我们相信终有一天，传统企业会摆脱人工手动配置或写脚本这种上个世纪的技术，将自身的IT架构迁移到完全通过API管理的，软件定义的数据中心中。此外，随着企业软件技术的不断创新，最终会是以SaaS（软件即服务）的方式在IT设施中部署。到那个时候，企业软件再不是为某个操作系统所设计的单机程序，而是为某个云设计的分布式程序。IaaS以及之上的PaaS就是这些企业软件的入口。依托ZStack的插件架构，我们完全相信我们可以逐步完善成一个涵盖IaaS和PaaS的平台，并且由于我们是IaaS和PaaS高度集成，提供的用户体验也必然优于同类软件间的第三方集成，从而成为未来企业软件的部署入口。
ZStack是一个开源项目，并且会一直坚持开源。我从2006年加入XEN社区到现在，就一直在开源领域工作，经历过不少成也开源败也开源的例子。例如OpenStack发迹于社区，但现在遇到了很多困难也源于社区。对于ZStack，我们欢迎任何形式的，基于Apache 2.0许可证的贡献。同时我们会负责维护ZStack核心稳定，对于提交到核心服务的代码进行严格控制。这样的代码会是少量的，因为在插件架构下，大部分功能会是以单独的插件方式实现。我们会推出两个目录：plugins和contribs。凡是ZStack自己的测试架构可以保证质量的插件，我们会放到plugins目录去，由我们承诺质量。对于测试架构无法保证的插件，例如需要特殊外设配合的插件，我们会放到contribs目录，表示用户在使用时需要自担风险。
总而言之，ZStack是个年轻的项目，是IaaS领域的一个新兵。但我们继承了先行者的经验，学到了先行者的教训，所以相信我们能比先行者走的更远。对于现有的IaaS项目，我们也不是扮演一个挑战者，而是为这个领域提供多一个选择。用我搭档的话说：我们不是蚂蚁与大象跳舞，我们是站在大象背上的蚂蚁，所以能看得更远。
编辑点评：作为“站在大象背上的蚂蚁”，ZStack的插件式架构设计确有可圈可点之处。根据初步测试者的评价，ZStack也沿承了CloudStack的一些亮点。只是目前OpenStack的社区生态已经很成熟，虽然遇到各种难题，OpenStack还是在不断的实践中得到进步，被应用于各种公有云、私有云之中。例如金山云合伙人宋伟将在“2015 OpenStack技术大会”上分享“Openstack 在公有云中的运用”，分享金山云解决了哪些问题以及如何解决。已经将OpenStack应用在生产环境中的用户，不太可能改换门庭。这意味着，虽有机遇，ZStack的初期发展同时还是会遇到很大的挑战。但正如张鑫所说，为这个领域提供多一个选择，总是一件好事。祝ZStack好运！
本文源自：http://it.dataguru.cn/article-7865-1.html
笔者从大学时代开始接触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官网介绍“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开源许可证发布源码，源码托管于此。
当前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月，主要开发者为张鑫和尤永康。根据官方网站介绍，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架构设计全解析》，同时也有一篇用户文档《ZStack深度试用：部署、架构与网络及其与OpenStack的对比》。关于ZStack架构设计可品读官方博客。在ZStack官方公布的技术文档中，用户可以发现有很多不同于现有IaaS产品的架构设计，其主要特色为全异步架构、微服务和一致性哈希，可承载高并发的API请求，具备稳定的架构、非常简化的部署和升级的特点。ZStack同样采用Apache License v2.0发布源码，源码托管于此。
图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官网发布了使用模拟器的方法 使用模拟器的方法，按照上面的部署方式可建立模拟环境。相比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起步较晚，不知其表现出来的架构和性能优势是否能赢取用户和市场，让我们拭目以待。
另附CSDN记者对话张鑫
CSDN：OpenStack生态已经比较成熟，公有云私有云的成功案例都有了，我们为何还需要ZStack项目？
张鑫：IaaS领域是时候需要新鲜血液了。
自亚马逊2006年发布EC2公有云以来，IaaS（基础架构即服务）领域持续创新，先后出现了Eucalyptus, CloudStack，OpenNebula这样的开源软件。到2010年OpenStack出现，整个创新达到了一个高潮。从业者都认为云计算的春天来了，认为传统企业可以很快的从上个世纪的IT架构中解脱出来，迅速迁移到由软件定义的数据中心。但让人大跌眼镜的是，5年过去了，Eucalyptus, CloudStack，OpenNebula已渐渐淡出人们的视线，OpenStack一统天下，却迟迟打不开企业软件的市场。就在去年，OpenStack的发起者Rackspace，宣布不再以纯IaaS提供商的身份进入市场，而是转向专注于核心业务“为客户管理服务”，在跟以亚马逊为首的公有云巨头的竞争中败下阵来。最近，著名OpenStack公司Nebula倒闭，给出的理由是“市场不成熟”，更是给整个IaaS产业浇了一盆冷水。一时间各种悲观论调四起，例如认为企业云市场根本不存在，又例如公有云最终统治世界，企业不再需要自己维护数据中心。
我于2010年加入Cloud.com，作为CloudStack前核心开发人员，一直紧密的关注整个产业以及各个开源IaaS软件，深深感到市场的需求是巨大的，但当前的产品离市场的要求差距很远。随着时间的推移，这个鸿沟越来越大，丝毫没有减小的迹象。
当前开源IaaS软件的痛点可以概括为四个方面：易用性差，不稳定，性能差，难扩展。而这四个方面又是阻碍市场接受IaaS软件的至关重要的因素。根据我多年来对各个项目的观察，认为导致目前状况的原因，并不是开源社区缺乏有才能的开发人员，而是这些项目起源太早，缺乏对市场的足够理解。这些项目早期都是盲目模仿亚马逊EC2模式，在快速开发功能的同时自然生长，用俗话说就是“摸着石头过河”，导致了在架构设计方面思考过少，累积了大量欠账。而前述的几个方面，又正是不从架构入手重新设计，就不能解决的问题。但我们又不能期望像OpenStack这样拥有几百万行代码的项目从底部推到重来。基于这样的现实，我认为不重新设计一款IaaS软件是无法解决已有的问题的。在退出了原来CloudStack的工作后，我跟搭档一起建立了ZStack，希望从根源上解决当今IaaS软件遇到的各种问题，为整个行业带来一款真正能打开企业市场的软件。
CSDN：能否介绍一下ZStack的市场目标，以及社区规划？
张鑫：ZStack的最终目的，并不是为喧闹的云市场添加更多的噱头，而是解决数据中心管理的一个刚需：即面对越来越多的硬件，如何管理它们，以及如何自动化这个管理的过程。我们相信终有一天，传统企业会摆脱人工手动配置或写脚本这种上个世纪的技术，将自身的IT架构迁移到完全通过API管理的，软件定义的数据中心中。此外，随着企业软件技术的不断创新，最终会是以SaaS（软件即服务）的方式在IT设施中部署。到那个时候，企业软件再不是为某个操作系统所设计的单机程序，而是为某个云设计的分布式程序。IaaS以及之上的PaaS就是这些企业软件的入口。依托ZStack的插件架构，我们完全相信我们可以逐步完善成一个涵盖IaaS和PaaS的平台，并且由于我们是IaaS和PaaS高度集成，提供的用户体验也必然优于同类软件间的第三方集成，从而成为未来企业软件的部署入口。
ZStack是一个开源项目，并且会一直坚持开源。我从2006年加入XEN社区到现在，就一直在开源领域工作，经历过不少成也开源败也开源的例子。例如OpenStack发迹于社区，但现在遇到了很多困难也源于社区。对于ZStack，我们欢迎任何形式的，基于Apache 2.0许可证的贡献。同时我们会负责维护ZStack核心稳定，对于提交到核心服务的代码进行严格控制。这样的代码会是少量的，因为在插件架构下，大部分功能会是以单独的插件方式实现。我们会推出两个目录：plugins和contribs。凡是ZStack自己的测试架构可以保证质量的插件，我们会放到plugins目录去，由我们承诺质量。对于测试架构无法保证的插件，例如需要特殊外设配合的插件，我们会放到contribs目录，表示用户在使用时需要自担风险。
总而言之，ZStack是个年轻的项目，是IaaS领域的一个新兵。但我们继承了先行者的经验，学到了先行者的教训，所以相信我们能比先行者走的更远。对于现有的IaaS项目，我们也不是扮演一个挑战者，而是为这个领域提供多一个选择。用我搭档的话说：我们不是蚂蚁与大象跳舞，我们是站在大象背上的蚂蚁，所以能看得更远。
编辑点评：作为“站在大象背上的蚂蚁”，ZStack的插件式架构设计确有可圈可点之处。根据初步测试者的评价，ZStack也沿承了CloudStack的一些亮点。只是目前OpenStack的社区生态已经很成熟，虽然遇到各种难题，OpenStack还是在不断的实践中得到进步，被应用于各种公有云、私有云之中。例如金山云合伙人宋伟将在“2015 OpenStack技术大会”上分享“Openstack 在公有云中的运用”，分享金山云解决了哪些问题以及如何解决。已经将OpenStack应用在生产环境中的用户，不太可能改换门庭。这意味着，虽有机遇，ZStack的初期发展同时还是会遇到很大的挑战。但正如张鑫所说，为这个领域提供多一个选择，总是一件好事。祝ZStack好运！
本文源自：http://it.dataguru.cn/article-7865-1.html