ZStack云计算架构探秘（一）

接下来几天我们将陆续介绍ZStack的内部架构设计，好让大家进一步了解ZStack是怎么设计和实现的。

这开头的一篇我们将会总体说明一下我们的主要技术点以及ZStack安装部署后的拓扑结构。

在我们设计ZStack的时候，我们有比较明确的设计原则，一切违背原则的方法，就算再好，我们也不会采用。我们的设计原则是：

1. 可分发满足数十万客户的不同需求

2. 支持单台物理机器就可以搭建一个云环境

3. 可一键安装部署

4. 可长期稳定运行

5. 可作为未来云技术的基础和入口

在展开技术内容前，先来看看，我们之前在单台普通PC上测试出来的性能指标吧。在23分钟内，我们可以创建10000台虚拟机（其实我们后来和Dnsmasq社区进行了合作，可以把万台虚拟机的创建时间压缩到10分钟左右）。小编可以自豪的说，当前应该不会有任何公开的IaaS能够“接近”我们的性能。

为了达到这么高效的速度，我们可是有很多独门绝招，当然速度只是一方面，我们还做了大量的工作来保证IaaS的稳定性和可伸缩性。下面我们来看看ZStack的主要技术特色吧（很抱歉，为了不造成歧义，这里只有全部用英文了）：

今天我们着重来看看ZStack安装部署后的拓扑结构吧。首先来看看单节点的情况。

图中我们的核心有两个部分：ZStack Management Node和 ZStack UI Server。它们都是通过我们的All-In-One的安装包在几分钟内安装完毕。ZStack的消息传递是完全依赖RabbitMQ的。当动态添加删除各种资源（云主机，存储以及网络服务)的时候，ZStack是通过Ansible完成自动化部署，完全不需要用户提前在不同的服务器上安装其他的工具。换句话说，用户只要在一台服务器上安装All-In-One包，其他各种云的service都由ZStack自己去安装。你可能会说，这一点都不酷啊，因为所有软件就应该这样的啊！但是小编的确不能保证其他IaaS也是这样的。：）

用户控制和操作ZStack可以通过ZStack的Web UI或者一个ZStack命令行工具。命令行工具是具有prompt命令补全功能的。

单节点用于小型生产环境或者演示环境比较合适。对中大型的生产环境来说,通常就需要部署多管理节点的ZStack。我们来看看多节点的拓扑图吧：

其实相比单节点的情况，ZStack只是很自然的添加了更多的管理节点和UI Server。他们之间的通信依然还是基于稳定的Rabbitmq。当然这里的Rabbitmq和数据库（mysql）都可以采用各种冗余部署方式来提高可靠性。

让我们从二层网络拓扑的角度来看看ZStack的部署效果吧（抱歉，图可能有点小）：

ZStack的标准网络有三个层次：用于管理ZStack内部资源的Management L2（比如传递创建VM的消息），用于对外通信的Public L2 （例如访问Internet）和虚拟机所在的Guest L2 。其中Management L2 和Public L2是可以合并的。隔离这些不同的网络可以利用不同的物理网卡也可以使用其他所谓的SDN的方式。图中包含的信息，如果从管理员的角度来看ZStack，功能是：

• 一个Cluster包含了一组相似的物理主机

• 一个主存储节点能够挂在到不同的Cluster上，这样Volume就可以在Cluster之间共享

• 一个二层网络可以被挂在到不同的Cluster上，虚拟机是可以跨Cluster迁移的哦

• 一个Zone是一个逻辑的概念，包含了一个完整的云资源

• 一个备份存储能够被挂在到不同的Zones上。这样相同的VM 镜像在不同的Zone之间也只需要一份拷贝。Volume的存储快照也跨区域服务。

那用户在使用ZStack提供的虚拟机的时候，除了CPU和内存外，他还可以要求ZStack给他的虚拟机提供多块虚拟网卡，也就是一个虚拟机可以跨越多个Guest L3。ZStack提供了一个软件实现的Vritual Router来提供各种NFV的功能。

好了，今天的内容就先到这里吧。大家如果有问题的话，可以给我们的邮件组发邮件，或者到GitHub的issue里面提问题。我们的github地址是：https://github.com/zstackorg/zstack