1.4 CloudStack简介

1.4.1 CloudStack的发展历史

CloudStack最初是由VMOps公司开发，VMOps后改名为Cloud.com。在2010年5月，Cloud.com同时发布了CloudStack的开源版与企业版。当时开源版本采用GPLv3许可，企业版保留大概5%左右的私有代码。此时，CloudStack已经有相当多的运营商和企业客户。之后，云计算产业一直处于迅猛发展阶段，Cloud.com也陆续发布CloudStack 2.0、CloudStack 2.2等版本。

2011年7月，Citrix花费2亿美金收购了Cloud.com。作为当时OpenStack的主要支持者之一，Citrix用了很长一段时间对CloudStack未来的发展做详细规划。

到了2012年4月，Citrix最终决定将CloudStack贡献给Apache软件基金会，成为Apache孵化项目之一，这也标志着CloudStack不存在开源与企业版之分，同时其许可证也完全是ASL2.0，此时CloudStack版本是3.0。

CloudStack 3.0之前的版本，你如果选择开源版本，那要遵守GPLv3许可，这要求你做的更改需要开源；如果你是购买企业版，那应该从Citrix获得相关支持。CloudStack 3.0及之后版本是ASL2.0的许可，ASL2.0是商业极其友好的协议，你可以免费获得源代码，可以对其做任意修改不必担心再次开源及许可问题。同GPLv3的许可一样，你不但能通过社区获得免费的技术帮助，也可以通过一些商业公司获得付费的技术支持。CloudStack从2015年5月到现在也已半年多了，期间Apache CloudStack发布了社区的第一个版本：Apache CloudStack 4.0。正是得益于Apache社区的影响力和用户规模，CloudStack的用户数、开发者及其认知度都在此期间都有了爆发式的增长。

1.4.2 CloudStack整体架构

CloudStack是IT基础架构的综合管理系统，或者称为云操作系统。CloudStack可以管理不同账号下任意多的虚拟机及其对应的复杂网络。CloudStack通过对计算、网络、存储等物理资源的综合管控以及完整的账户和API的支持，使其可以被用于企业内部的私有云，或运营商托管的混合云，以及类似亚马逊EC2的公有云。CloudStack广泛支持目前流行的各种Hypervisor，包括XenServer、XCP、VMWare、KVM等。

CloudStack利用现在业界成熟的技术，结合早年商用的积累，使其拥有许多创新的特点，比如主存储及二级存储的分离，系统虚拟机和虚拟路由器的引入，资源按域、机架、集群的分层管理等。

如图1.3所示，从物理设备的角度来看，一个CloudStack可以管理节点或集群，包括提供虚拟化计算能力的服务器和存储等多种设备。

从图中可以看出，管理节点、计算节点和存储节点通常部署在一个机房内，管理节点提供上文中介绍的云服务中的管理功能，主要包含虚拟机的创建与回收、存储的分配、网络资源的创建和分配以及云环境中各种资源的监控等功能。通过管理节点的任务执行功能，在计算服务器集群上执行创建回收虚拟机等底层指令。

管理服务器（Management Server）是CloudStack这个IaaS云管理平台的核心，主要将整个IaaS平台的工作统一汇总在这个核心来处理，接受用户和管理员的操作，包括对硬件、虚拟机和网络的全面管理操作。管理节点会对发过来的操作请求进行处理，并发送给对应的计算节点或系统虚拟机去执行；管理节点还会在MySQL数据库中记录整个CloudStack系统的所有信息，并监控计算节点、存储和虚拟机的状态，以及网络资源的使用情况，帮助用户和管理员了解目前整个系统各个部分的运行情况。在安装管理节点时，分别需要安装管理服务程序、MySQL数据库和Usage服务程序（可选）3个大的组件。

·管理服务程序，基于Java语言编写，包含Tomcat服务、API服务、管理各类Hypervisor的核心服务、管理整个系统工作流程的Server服务等几个核心组件。

·MySQL数据库记录CloudStack系统中的所有元数据信息。

·Usage服务程序主要用于记录用户VM使用各种资源的统计和事件，为计费提供数据，所以当不需要计费功能时，可以不必安装此程序。

在简单环境下，可以将以上所有管理节点的组件都集中安装在一台物理服务器或虚拟机上。但在一个计划上线的生产环境下，根据设计需求，可以部署多台管理服务器分担不同的功能，如图1.4所示。

安装多个管理服务程序作为一个集群，再使用负载均衡设备放在此集群前，可以负载大量的Web访问或API请求。将MySQL数据库安装在独立的服务器中，并搭建主从方式（Master-Slave）的MySQL数据库作为一种备份方案。将Usage服务程序安装在独立服务器上，用于分担管理服务器上的压力。

为了更好地管理云中的各种资源，CloudStack在设计的时候参考自己在大规模数据中心的实践经验，对CloudStack的各种功能进行了更具体的划分，充分展现了一个健壮的云平台所具有的适用性和通用性，面对异构底层硬件的兼容性，灵活的可扩展能力。图1.5给出了CloudStack的逻辑架构图。

上图是通过浏览器登录CloudStack的Web UI后就可以看到的一个架构图，其中资源域（Zone）、提供点（Pod）、集群（Cluster）属于逻辑概念，既可以对照实际进行理解，也可以根据需求灵活配置使用。下文我们将对图中展现的各个逻辑概念做详细解释。

1. 资源域（Zone）

资源域（Zone）可以理解为一个数据中心或机房，是CloudStack系统中逻辑上最大范围的组织单元，由一组提供点（Pod）、二级存储（Secondary Storage）以及网络架构配置构成。在完成管理服务器的安装后，登录CloudStack的管理界面，第一步就是创建资源域，完成整套IaaS平台的初步整合。在创建资源域的一系列步骤中，会包括网络架构的选择，网络的各种规划和配置，计算服务器和存储的添加。对于管理员来讲，创建资源域的时候会决定该资源域的所有重要参数，必须对整个资源域有一个很好的规划，使得资源域的架构可以满足需求，并适应未来的扩展。在完成创建资源域的步骤后，随着需求的变化，还可以继续添加提供点、集群、计算服务器和存储，一个资源域内的提供点的数量是没有限制的。一套CloudStack系统中可以添加多个资源域，资源域之间可以实现完全物理隔离的，硬件资源，网络配置，虚拟机也都是独立。

一个资源域在建立的时候只能选择一种网络架构基本网络（Basic Zone）或高级网络（Advanced Zone），但如果整套系统有多个资源域，每个资源域可以选择不同的网络架构。根据这一特点，也就可以实现CloudStack对于多个物理机房的统一管理。从业务的需求上来说，也可以在一个机房内划分出两个独立的资源域，提供给需要完全隔离开的两套系统使用。由于资源域之间是相互独立的，如果需要有通信，只可以是在网络设备上配置打通资源域的公共网络，关于网络的介绍我们会在第3章详细介绍。

资源域之间只可以复制ISO和模板文件，虚拟机不可以进行资源域之间的迁移操作，所以如果有需要，解决的办法就是将虚拟机转为模板，然后复制到另一个资源域中使用。另外，资源域对用户是可见的，在管理员创建资源域的时候，可以选择该资源域是对所有用户可见的公共属性，还是只对某组用户可见的私有属性。当一个用户可以看到多个资源域时，创建虚拟机的步骤中可以选择在哪个资源域中创建虚拟机。

2. 服务提供点（Pod）

提供点（Pod）是CloudStack的资源域内第二级的逻辑组织单元，可以理解为一个物理的机架，包含交换机、服务器、存储的整合。所以参照物理机架的概念，在CloudStack的提供点中，也有网络的概念，即所有提供点内的计算服务器、系统虚拟机、客户虚拟机都在同一个子网中。

一般来说，提供点上的服务器连接至同一个或一组Layer2交换机上，所以在很多实际部署中，基本也都是以一个物理机架来进行规划。一个资源域内可以有多个独立的提供点，数量没有上限。一个提供点可以由一个或多个集群构成，一个提供点中的集群数量没有上限。出于对网络灵活扩展的目的，提供点是不可或缺的一个层级。另外，机架对最终用户不可见。

3. 集群（Cluster）

集群是CloudStack的系统中最小的逻辑组织单元，由一组计算服务器和一个或多个主存储所组成。同一个集群的计算服务器必须使用相同的Hypervisor类型，硬件型号也必须相同（带有高级功能的XenServer和vSphere可以兼容异构的CPU）。虚拟机可以在集群内的不同主机之间实现动态迁移（Live Migrate）。一个提供点可以包含多个集群，可以包含使用不同Hypervisor程序的集群。虽然CloudStack并不限制集群的数量，但由于提供点所划分的子网范围，提供点内的集群和主机数量不会是完全无限制的。而集群内主机的数量，虽然也没有限制，但根据最佳实践，一个集群内的计算服务器的数量建议不超过16台。

需要注意的是，vSphere集群由vCenter服务器进行管理。管理员必须将vCenter服务器注册到CloudStack上。每个资源域上可以放多个vCenter服务器，每个vCenter服务器可以管理多个vSphere集群。

集群内可以添加多个作为共享存储所使用的主存储（Primary Storage），主存储的类型没有限制，只要可以和计算服务器正常通信即可。在新版本中，CloudStack可以实现虚拟机所使用的镜像文件在多个主存储之前进行迁移，但肯定需要关闭虚拟机电源进行迁移。

4. 计算服务器（Host）

计算服务器是CloudStack中最基本的硬件模块之一，用于提供虚拟化能力和计算资源，并运行客户创建的虚拟机，根据系统压力可以进行弹性增减。计算服务器上需要安装Hypervisor程序，目前CloudStack支持Citrix XenServer、VMware ESXi、KVM（包括RHEL或Ubuntu类型）、Oracle VM的Hypervisor。

计算服务器通常用于提供虚拟机需要的所有CPU、内存、存储和网络资源，相互之间通过高速的网络互连，可以使异构的（表现为不同的配置），位于不同的数据中心内，采用高性能通用x86兼容服务器，自身相对可靠，但规模较大时允许出现个别服务器故障。

一般来说，CloudStack可以兼容绝大部分硬件设备，其实就是所使用的硬件是否能够被Hypervisor程序兼容。在安装Hypervisor程序之前，需要先确定该服务器所使用的CPU能支持虚拟化技术，并在BIOS中打开CPU对虚拟化技术的支持。而服务器上的所有硬件是否与Hypervisor程序兼容，建议在Citrix、VMware等官方网站上进行检查确认。

5. 主存储（Primary Storage）

主存储一般作为每个集群中多台计算服务器共同使用的共享存储存在，一个集群中可以有一个或者多个不同类型的存储。也可以通过参数配置，使用计算节点的本地磁盘作为本地存储使用。主存储用于存储所有虚拟机的镜像文件和数据卷文件。集群中的所有计算节点都可以访问共享存储，用以实现虚拟机的在线迁移（Live Migrate）和高可用（High Available）的功能。如果设置本地磁盘为主存储，虚拟机的磁盘读写有很好的性能，但无法解决主机故障导致虚拟机无法启动而出现的单点故障。

CloudStack的主存储支持的设备依赖于计算节点所使用的Hypervisor程序，如XenServer和vSphere可以全面地支持NFS、iSCSI、FC-SAN等传统存储设备。对于KVM，支持NFS较容易，但需要使用Sheard Mount Point功能来间接支持iSCSI、FC-SAN、CLVM，并可以间接支持较新的分布式存储技术架构。

6. 二级存储（Secondary Storage）

二级存储是CloudStack根据IaaS平台的特点，专门设计出来的存储。每个资源域只需一个二级存储，用于存放创建虚拟机用的ISO镜像文件、模板文件，以及对虚拟机做的快照文件。二级存储可以支持NFS存储和Ceph协议的对象存储等。