我今天跟大家分享的主要内容是如何在OpenStack上建立应用程序的架构。

 

 

我相信在座的各位多半做过开发,写过自己的应用程序。但是事实上你的应用程序是可以进一步的。请问你们知道之前自己写的应用程序在哪里吗?我是不知道的。

 

我们会希望自己的应用程序可以在这个世界很多地方用上,比如你在北京写了一个很好的应用程序,加入了IOT的服务,你可以把它卖去美国、日本。这就是开源,开源让你可以不用去管其他物理上的限制。

 

但是在现实生活中,我们一般没法做到这一点,因为往往会碰到一些壁垒,而这些壁垒多半是因为复杂性。先不谈云这个概念,回想一下如果5年前让你写一个大型的程序,你很难把这些东西全部放在一个客户的环境里,因为你没办法去帮他解决所有硬件和软件的问题。

 

现在看OpenStack这个概念,我们开始在云的环境中思考这个问题。五年前我们可能还在思考什么是基础架构,五年后我们开始思考可以在上面做什么样的应用。现在已经来到了一个开源的时代,这个时代对你们的假设是你们会开发东西,并且希望可以很好地整合到OpenStack上面。

 


先讲一个基本的概念。在OpenStack上,GLANCE提供镜像服务。镜像服务指的是在准备应用程序的时候,你往往还要解决整个系统需要安装什么的问题,而如果你可以提供镜像,那你就不用再去思考这个程序应该跑在哪里。

 

 

在OpenStack上,裸机可以使用镜像,虚拟机也可以使用镜像。所以你不需要再去接触底层的东西。

 

OpenStack有一个说法是连接所谓的Kubernetes。指令就是你提供它的flavor,这是一个脚本,告诉接下来要抓的资源有多大,有多少CPU和内存。基本上它给出了针对实体机的一些限制,比如说cpu-arch,限制满足后它会告诉你这是一个裸机,你不需要再去做很多工作。

 

这就是一个云的架构。当你有自己的程序,你可以把它跳过一层,不需要处理所谓的裸机。


再往上是大家今天一直提到的OpenStack的存储部分。这一部分的好处使得在OpenStack上,我们通常不直接使用服务,而是建立一个空间。写过应用程序的人一定知道你需要针对你的应用程序,搞清楚所处空间的权限、大小,甚至包括很多日志档案所占的空间,事实上你还要在程序里写好如什么时候去清理,那些空间怎么处理等信息。

 

客户可能会表示要搬地方,希望开发人员把这些东西一并打包,并与移动程序连接起来。在云的时代,你只要在CINDER上面储存,就可以真正切分所需要数据的空间,甚至可以跨地域。

 

 

再就是对大家来说最重要的网络——现在所有的程序基本上都会有各种Neutron,你不需要自己定义网络,而是把这部分交给OpenStack处理。因为很多开发者的投入,网络部分不需要你接触底层的系统。在Openstack里,网络层除了可以切分实际网段,也可以切分在这个网段里面想要哪些IP,想要哪些对外的IP。比如你要先建一个network,然后再建一个网络,network和network之间是有router的。


在OpenStack里也有隔离监控的部分,一些企业会把自己的定位移动到OpenStack上,但不满于慢的监管。值得提出的是,其实很多的监管资源是被浪费掉的。

 

再往上一层,我们希望在OpenStack里把做虚机、装网络、做存储等全部脚本化或自动化实现(Heat就是做脚本化),这样你在交付给客户的时候,不再是提供一个个分散的文件,也不再是多达上百个的步骤指南。

 

MISTRAL所做的是有状态性的。MISTRAL比较少见,接下来这一年来大家会用到这样一个图,以供参考。

 

再往上可以见到KURYR、MAGNUM、Kubernetes和docker,当然我们也有一些公司的产品。

 

建立这五者之间的关系很简单,以此为基础就可以建立出一整套“住房”。在企业中使用的时候,你绝对不会脚本开放一行一行的识别,而是利用脚本化或者部署概念。

 

另外在这个过程中还会使用一些服务,像今天提到很多的OSLO、KEYSTONE、HORIZON、DOCUMENTATION、ZAQAR。

 

 

 

再往上是BARBICON,以及SWIFT、SAHARA、MANILA、DESIGNATE。

 

 

 

 

在这样的想法下,要部署一个很庞大的服务,会有一些必须要做的事情。基本概念和要在一个环境里面部署一台机器是一样的,但是规则要复杂得多。

 

 

你可以把应用程序放到全世界很多的地方,比如全世界的OpenStack上,只要版本是对的,它就不会破坏自己的相关性。你只要告诉对方你也建OpenStack,你的版本是什么,你不会破坏原先的OpenStack,对方的东西就可以放在这上面。

 

 

再往下就是如果可以有自己的部署脚本,基本上只需要把现在的部署脚本放到OpenStack里面就得到一个Template。

 

现在假设已经在运行一套系统,首先你要想办法切分,你需要什么角色。因为你的环境是人家部署给你的,你要继续使用这个东西,就得搞清楚资料都在上面吗?所有服务的资讯也需要都在上面,因为你的服务也在上面跑。这是一个非常复杂的问题。


什么是有状态,什么是没状态?状态这个东西很简单,就是说你的服务有没有负责主管整个管理架构,再就是在这个过程中要确保服务本身是随时可以存续的。

 

这是什么意思呢?现在你的部署抽掉,也就是说如果是一个产品,你一定有部署脚本,除非你希望客户是一个月做完就走。所以,在这个环境下首先确保脚本拿出来,第二确保服务的状态,如果它是没有状态的话还好,如果它有状态,你要确保它的绝大多数状态一定要在放置这上面。

 

 

状态把底层网络这些东西放置到OpenStack上,然后你可以把多数的东西拿上来,放到上面的是有状态的,所以RPC的状态是跟着周边的东西放置到OpenStack上。


OpenStack有状态而且是有资料的,有状态有资料的情况下必须确保它的资料先过来。这一段不是那么简单,背后有非常多的逻辑。你先把它的资料搬上来之后,才开始慢慢地解决它,这样资料过来之后整个环境才有办法做好。


 

 

 

最后就是Master,Master的作用是先确保资料。当你有一个OpenStack环境的时候,你就可以提到Scripts,因为你的服务完全是切开的。当你的服务要提供到客户的时候,你不再担心这个反射弧是不是要对冲,因为安全性不会有问题。

 

这就是OpenStack,未来我们会把它做得更好。另外希望把Application相关的工作在OpenStack里面继续深化。这是我今天分享的内容,谢谢!