CloudStack云计算平台架构详解

第四届中国云计算大会于2012年5月23-25日在北京国家会议中心隆重举行。本次大会由中国电子学会主办，北京市经济和信息化委员会协办，中国云计算技术与产业联盟、中国电子学会云计算专家委员会承办，CSDN与《程序员》杂志协办。在2012国内公共云全面开花、云计算实践元年之际，本次大会云集云计算核心专家，就国内外云计算核心技术以及行业应用创新实践进行了深入探讨。

思杰系统公司VMOps创始工程师、CloudStack架构师Alex Huang

思杰系统公司VMOps创始工程师、CloudStack架构师Alex Huang带来了《CloudStack架构详解》主题演讲，他先简明扼要得介绍了CloudStack开源云计算解决方案，以及具有加速高伸缩性的公共和私有云IaaS的部署、管理和配置。并且分享了如何使用CloudStack作为基础，数据中心操作者如何快速方便地通过现有基础架构创建云服务。

文字实录如下：

大家好！谢谢大家参加CloudStack架构的详讲。我很荣幸在这里跟大家讲CloudStack的组成。

CloudStack都有哪些功能？

先看看CloudStack的功能是什么，其实它是很简单的，我们希望CloudStack能够提供相关功能给它的客户，自动的用VM，取得VM。这个问题本来是很简单的。我们先看看这个组件，组件里面有Hosts，也有主存储，这些东西连在一起，我们就会有一个Cluster ，再把这些Cluster连在一起就是Pod。

存储为什么要分两套？因为这与成本有很大关联，云端操作里面有了多东西不需要很高的IOPs。看看我们的Deployment Architecture，把Cluster连在一起就是Pod，一个Pod在一个数据中心里面可以是一个，也可以是多个，这些Pod连在一起再加上我们的二存储，这就是一个CloudStack。

这是一开始的图案，本来很简单的，可是一旦加上Control，就变得复杂了，因为它想向不同的东西支持这个运算，在网络上说一定要F5去做，它可以去Control。在User也有同样的问题，要看User是不是已经到了服务的阶层。譬如说用户只能够起5个VM，但是他要起第六个VM的时候就必须让他停止。再加。上这个Complexity，譬如某一个公司用户退户的时候，我必须要把他的数据留30天，这些东西我们都必须要做。对用户来说，我们也必须要给出很多不同的选择。譬如说，这个是很多用户想要的，就是每一个用户需要自己的Network、自己的网络，在这两个网络里面IP是一样的，那我们就不能让用户1的VM去访问用户2的VM。这是很多用户想要的，这是很普遍的，他们可以痛殴我们的VM访问互联网，但是不能从互联网回去访问这些VM。

这又是另外一种模式，以前我们VM是两个网络里面共享的，然后通过这两个网络去联络，在这里他们只有自己的网络，然后我们控制谁可以看到什么网络。同时，我们的Virtual Router可以访问顾客中心，也可以提供这个网络。在这上面他们就可以为这个顾客提供其他的服务，譬如它可以加上VM的监护。

下面看看我们的软件架构是怎么处理的，这是CloudStack Management Server的架构。这里面有OAMAPI ，也有End User API,也有Ec2API,也有其他的API。这些东西弄好之后有很多步骤。这些步骤是用Orchestration Engine弄好的。在Orchestration Engine里面我们是把步骤弄好，因为有不同的硬件、不同的物理机，他们做东西是不同的，那我们就靠这个来实现。同时，我们Management Server也会告诉其他的软件VM已经起来了或者某个用户已经不在了，这些东西要搜集在我们的Usage Server里面。

这个就是我们的Orchestration Engine，我们用它将不同的东西加到CloudStack中。这是我们的一个Plugin，如果真的需要跟它的物理机联系，它就要发命令给ServerResource,这个 ServerResource可以直接跟物理机交互，做好命令以后就返回了。

这是我们里面可以加上去的：第一个是NetworkGuru,这个NetworkGuru是告诉CloudStack可以提供这种服务。第二个是NetworkElement，在网络上提供不同的服务，因为我们有很多不同的硬件可以做这种东西，所以我们用NetworkElement，去实现这种服务。第三个是我们也有DeploymentPlanner，我们把这些东西摆在里面，让其他人去做这个。还有其他的，大家可以进去看看。

如何实现高扩展性？

软件架构设计好之后，我们还要应付其他问题，最大的问题就是Scalability。谈到Scalability有几个问题：一个是它的压力是从哪里来的，CloudStack的压力当然是用户越多要执行的任务就越多；另一个压力是管理的物理机越多，它幕后执行的服务也会越来越多；第三个是CloudStack系统哪里有限制——DB Connections和Network Bandwidth，因为云里面数据流量非常大，所以这两样东西都要控制好了。

我们先看看怎么做，把Management server 分成两步，第一步是API server，第二步是Orchestration Server。如果API访问数据库，那么API Server就去访问数据库。但是做Orchestration的时候，就让Orchestration Server把它提出来，去执行这些任务。另外一件事是物理机越来越多，我们做的事就越来越多，有很多这些幕后的服务在运行的。当物理机越来越多时，我们这个服务就越来越忙了。

我们可以看两套不同的软件写在CloudStack，有些什么问题和CloudStack是怎样处理问题的。第一，我们的Stats Collector,可用来看用了多少CPU和内存，每5分钟运行一次，它代表所有的逻辑都在我们的Server上。另外一个是VMSync，它每一分钟运行一次。

我们看看这个Numbers，假设我们有1万台host,有50个VM，2个management servers就有66个requests 。结果，虽然有50万个VM，可是我们management servers需要做的东西就少很多。而且在每一个management servers上做的不同，它看哪个management servers哪些资源、哪些物理机，其他的物理机就留给其他的management servers。

软件管理和分配

另外，我们很小心地把管理分开。在这个例子里有三个不同，当我们需要在这些DataCenter里面互相移动数据的时候，我们management servers就会在里面其他的虚拟机，虚拟机有一部分插在数据中心的网络里面，另外一部分是去互联网，当这些虚拟机起来了，它就可以自己去做模板和ISO。这也一样，提供看到VM的UI，我们去起把这个Data弄进互联网，用户可以从那里看到VM的UI，management servers并不在其中。有了这么多不同的Deployment，我们首先会有一个Database cloud去提供。如果API Server发现它只需要访问数据库，它就还回去了。这每一个都可以自己去，就不再是一套的东西了。

那我们看看软件的分配是什么样的，在API Server上可以加不同的API。Orchestration Server我也谈了一点，真的要物理机联络的时候琢磨就通过这个去做。那我们看看当我们要VM的时候做什么东西，一个用户说要这个VM。如果它可以的话，就会在我们的数据库里面把所需要的东西写好。当这些东西在我们数据库里面弄好了，我们就会返回，可以继续问我们结果如何，我们也会告诉它。

这里只是比较简单地介绍CloudStack，CloudStack有三年的历史，我们也学了很多东西。对于是Design against failure，很多东西都可以failure，一旦有问题，我们会把所有的封掉。谢谢！

更多精彩内容，请关注CSDN云计算频道微博，第四届中国云计算大会专题报道。

欢迎投稿：“第四届中国云计算大会”之我见——征稿启事