服务器在线 - 服务器软件 - 网站地图 服务器在线,专注于服务器技术!

当前位置:主页 > 云和虚拟化 > CloudStack > 正文

CloudStack云计算平台架构详解

时间:2015-01-16    来源:服务器在线    投稿:泡泡    点击:

第四届中国云计算大会于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云计算频道微博,第四届中国云计算大会专题报道。

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

如果您的问题仍未解决,还可以加入服务器在线技术交流QQ群:8017413寻求帮助。


相关内容
最新热点内容
推荐内容