云计算是分布式计算,并行计算,效用存储,网络存储,虚拟化,负载均衡,热备份冗余等传统计算机和网络技术发展融合的产物。


服务类型
* IaaS:将硬件设备等基础资源封装成服务供用户使用。在IaaS环境中,用户相当于在使用裸机和磁盘,既可以让它运行Windows,也可以让它运行Linux。 IaaS最大优势在于它允许用户动态申请或释放节点,按使用量计费。而IaaS是由公众共享的,因而具有更高的资源使用效率。
* PaaS:提供用户应用程序的运行环境,典型的如Google App Engine。PaaS自身负责资源的动态扩展和容错管理,用户应用程序不必过多考虑节点间的配合问题。但与此同时,用户的自主权降低,必须使用特定的编程环境并遵照特定的编程模型,只适用于解决某些特定的计算问题。
* SaaS:针对性更强,它将某些特定应用软件功能封装成服务。SaaS既不像PaaS一样提供计算或存储资源类型的服务,也不像IaaS一样提供运行用户自定义应用程序的环境,它只提供某些专门用途的服务供应用调用。


OpenStack基本概念

OpenStack即是一个社区,也算一个项目和一个开源软件,提高开放源码软件,建立公共云和私有云,它提供了一个部署云的操作平台或工具集。

    官网:

https://www.openstack.org/


 

三种网络和四种节点

管理网络 是 OpenStack 的管理节点或者说是它的管理服务对其它的节点去进行管理的这样一个网络,他们之间有 “不同组件之间的 API 调用,虚拟机之间的迁移” 等等;
存储网络 是计算节点访问存储服务的网络,包括向存储设备里面读写数据的流量基本上都需要从存储网络走,还有另外一种是服务网络;
服务网络 是由 OpenStack 去管理的虚拟机对外提供服务的网络,服务器上通常都是一台服务器上带好几块网卡,好几块网口,我们可以给各个网络做隔离。隔离的好处是,它们的流量不会交叉,比方说我们在读写存储设备的时候,可能在存储网络上的流量特别大,但是它不会影响到我们这些节点对外提供服务,同样,在我们做虚拟机迁移的时候可能在管理网络上它的数据流量会非常大,但是它同样不会影响到我们这些计算节点对存储设备的读写性能。


整个OpenStack是由控制节点,计算节点,网络节点,存储节点四大部分组成。

其中:

控制节点:负责对其余节点的控制,包含虚拟机建立,迁移,网络分配,存储分配等。

计算节点:负责虚拟机运行。

网络节点: 负责对外网络与内网络之间的通信。

存储节点:负责对虚拟机的额外存储管理等。


OpenStack组件之间的通信关系

OpenStack 组件之间的通信分为四类:

  • 基于 HTTP 协议

  • 基于 AMQP 协议(基于消息队列协议)

  • 基于数据库连接(主要是 SQL 的通信)

  • Native API(基于第三方的 API)




OpenStack几种不同的存储

OpenStack的存储服务分为三种:Glance、Swift、Cinder;


Glance(镜像存储)是一个镜像存储管理服务,本身不具备存储的功能;
Cinder (块存储)提供块存储的接口;本身也不提供数据的存储,后面也需要接一个存储的后端,像 EMC 的散设备,华为的存储设备,NetApp 的存储设备可以做它的后端。还有一个比较火的开源分布式存储叫 Ceph,Ceph 也提供块存储服务,也可以用来作为 Cinder 的后端。Cinder 的作用就是为 OpenStack 提供块存储的接口,有个很重要的功能叫卷管理功能,虚拟机并不直接去使用存储设备(并不直接去使用后端的存储系统),使用的是虚拟机上的块设备(卷 Volume),实际上 Cinder 就是创建和管理这些 Volume 并且把它挂载到虚拟机上。Cinder 是从 Nova Volume 里面独立出来的,独立出来之后很受各种存储厂商的欢迎,可以通过写 Cinder Driver 的形式把自己的存储设备纳入到 OpenStack 的生态圈里面去。
Swift (对象存储)提供的是对象存储服务,同样的具有像亚马逊 IWSS3 的特点,提供通过RESTful API 的方式去访问数据,这样做是为了解决两个问题:第一个,我们可以直接去访问一个存储,而不需要在通过自己开发的 Web 服务器去做一次数据的转发,否则对服务器的负载来说是一种压力。第二个,在我们的大数据时代,当数据量特别大的时候,如果我们用文件系统就会出现问题:文件的数量激增以后,存储的性能会急剧下降,而对象存储实际上则是解决这个问题的,对象存储抛弃了那种目录树的结构,用一种扁平化的结构去管理数据。Swift 实际上只有三层结构,即 Account、Container、Object。Object 就是最终的那个数据了,就是文件,前面有两级管理,一级是 Container 容器,它把 Object 放到容器里面,然后再上面一级是 Account,是和账户去关联的,Container 相当于是把这些 Object 做了分类,用 Account 去跟账户关联起来。



三种存储的概念:文件存储、块存储、对象存储


有 POSIX 接口或者 POSIX 兼容的接口,就可认为它是一个文件系统,比较典型的分布式文件系统有像 Glance 的 FS,Hadoop 里的 HDFS
电脑上的一个盘格式化之后是一个文件系统,那么在格式化之前是一个块设备,也就是块存储,实际上我们在数据中心里面,像 EMC 的很多设备,像华为的一些叫作 SAN 的设备,像 NetApp 的一些设备,如果是散存储一般来说就是提供块存储的;
对象存储的典型代表是亚马逊的 AWS S3,它的接口不是 POSIX,也不是像一块硬盘那样作为一个块存储的接口,是通过 RESTful Web API 去访问的,对于应用开发者来说优势在于可以很方便的去访问存储里面存的数据,对象存储里存的数据通常叫做 Object,实际上它就是 File,但是对象存储里面为了和文件系统做一个区别,便被叫作对象 Object



OpenStack服务


服务 项目名称 描述
Compute     (计算服务) Nova
负责实例生命周期的管理,计算资源的单位。对Hypervisor进行屏蔽,支持多种虚拟化技术(KVM),支持横向扩展。
Network      (网络服务) Neutron 负责虚拟网络的管理。
Identity      (身份认证服务) Keystone 对用户、租户和角色、服务 进行认证和授权
Dashboard   (控制面板服务) Horizon 提供web界面管理,与OpenStack底层服务进行交互
Image Server  (镜像服务) Glance 提供虚拟机镜像模板的注册与管理,将最好系统复制为镜像模板,在创建虚拟机时直接使用。
Block Storage (块存储服务) Cinder 负责为允许实例提供持久的块存储设备,可进行方便扩展,按需付费,支持多种后端存储。
Object Storage  (对象存储服务) Swift 为OpenStack提供基于云的弹性存储,支持群集无单点故障
Telemetry      (计量服务) Ceilometer 用于度量、监控和控制数据资源的集中来源,为OpenStack用户提供记账途径




部署OpenStack硬件需求

硬件\需求
控制节点 计算节点
CPU 支持Intel 64或AMD64 CPU扩展,启用AMD-V或Intel VT硬件虚拟化支持的64位 x86处理器
内存 2GB 至少2GB
磁盘空间 50GB 最低50GB
网络 2个1Gbps网卡 2个1Gbps网卡




OpenStack工作流程

总共有 28 个步骤,主要是和 Nova 相关的,实际上在 Keystone Glance Neutron Cinder Swift 等组件内部还有很多小步骤,加起来恐怕有50多个步骤。现在主要看这28个基本步骤,这里的大部分信息发表在来自 ilearnstack 网站上的一篇文章,在 Dashboard 上创建虚拟机的过程.


第 1 步,首先,Horizon 或者是命令行工具向 keystone 发起了 REST 调用,并且把用户名和密码发给 Keystone;
第 2 步,Keystone 对接收到的用户名及其密码进行验证,并生成 Token,这个 Token 在后面为其他组件发送 REST 调用时使用;
第 3 步,Horizon 或者命令行客户端把启动虚拟机操作或者在命令行上敲的 nova boot 命令,包括上一步说的 Token 转化成 RESTful Web API 发送给 Nova-API;
第 4 步,Nova-API 收到请求之后向Keystone 验证客户端发来的 Token 的合法性,这就是说 Nova 和 Keystone 之间有一个交互了;
第 5 步,Keystone 验证完 Token 之后,将用户的角色和权限返回给 Nova,也是返回到 Nova-API;
第 6 步,是 Nova-API与 Nova Database 之间有一个交互的过程;
第 7 步,是 Nova Database 为新的虚拟机实例创建一条记录,并且将结果返回给 Nova-API。
第 8 步,Nova-API 通过 AMQP 向 Nova-Scheduler 发送一个同步远程调用请求,这里的同步远程调用请求实际上是 AMQP 协议里的叫作 rpc.call request,这地方是同步调用,同步调用的意思就是,它发送完请求以后就一直在等待,一直等待到这个队列(消息队列)里面给它返回来结果,所以就是在等待获得新的虚拟机实例的条目和 Host ID,Host ID 是虚拟机将来要启动的寄主机的 ID;
第 9 步,Nova-Scheduler 从消息队列里面取出请求,因为中间有 AMQP 组件在这,所以 Nova 的其他各个组件之间的交互基本上都是通过 AMQP 来做的,实际上 AMQP 的实现用的是 RabbitMQ;
第 10 步,是 Nova-Scheduler 与 Nova Database 进行交互并且挑选出一台适合的宿主机来启动这个虚拟机,(挑选的过程很复杂);
第 11 步,是 Nova-Scheduler 通过 AMQP 返回给前面的 Nova-API 的调用,并且将宿主机的 ID 发送给它;
第 12 步,是 Nova-Scheduler 通过消息队列,向 Nova-Compute 发出一个在上述宿主机上启动虚拟机的异步调用请求,这里是异步调用请求(Nova-Schduler 把请求发送到消息队列里面以后它就返回了,就不用再等待这个请求给它返回结果,在 AMQP 里面是 rpc-cast 这个请求);
第 13 步,是 Nova-Compute 从队列里面取该请求;
第 14 步,是 Nova-Compute 通过消息队列向 Nova-Conducter 发送一个 rpc.call 同步调用请求获取虚拟机的信息(包括宿主机的 ID,虚拟机配置信息有内存大小、CPU 配置、硬盘大小等等);
第 15 步,Nova-Conducter 从队列里取出上述请求;
第 16 步,Nova-Conducter 与数据库进行交互;
第 17 步,Nova-Conducter 返回前面 Nova-Compute 请求的这些信息;
第 18 步,Nova-Compute 从消息队列里面取出 Nova-Conducter 返回的信息,也就是同步调用到这里就结束了;
第 19 步,是 Nova-Compute 向 Glance-API 发出带有 Token 的 REST 请求,去请求这个镜像数据;
第 20 步,是 Glance-API 向 Keystone 去验证这个 Token 的合法性,在前面有类似的步骤(Nova 去验证 Token 的合法性,其实在 19 步和 20 步两步里面还有很多细节比如说,如果是 Swift 来存储 Glance 的镜像,中间还有 Swift 和 Glance 之间的交互,Glance 内部也有一些交互);
第 21 步,是 Nova-Compute 获取镜像的元数据,前面几步相当于把镜像的元数据给获取了,知道了镜像是从哪里来的长什么样的。后面的 22 到 24 步这几步是为虚拟机去准备网络,还是以 Nova-Compute 为中心的;
第 22 步,是 Nova-Compute 向 Neutron API 发送带有 Token 的 REST 请求进行网络配置,并获得分配给待创建的这个虚拟机的 IP 地址,这中间其实 Neutron 做了一些工作,也有很多细节;
第 23 步,Neutron Server 向 Keystone 去验证 Token 的合法性;
第 24 步,Nova-Compute 就获得了网络的配置信息,后面这几步是给虚拟机去准备虚拟机的硬盘,也就是前面提到过的卷存储或块存储;
第 25 步,是 Nova-Compute 调用 Cinder-API 的 RESTful 接口给虚拟机挂载卷,也就是块设备或者是虚拟硬盘;
第 26 步,跟上面的 Glance 和 Neutron 类似,Cinder-API 也要向 Keystone 去验证,这个Token 的合法性;
第 27 步,Nova-Compute 就会得到这个虚拟机的块存储的信息;经过 27 个步骤,这样创建一个虚拟机所需要的各种信息和条件才正式地准备完毕;
第 28 步,Nova-Compute 去调用 Hypervisor 或者 Libvirt 的接口创建虚拟机,当然,在 Libvirt 或者说是 Hypervisor 去创建虚拟机的过程中,内部也是一个非常复杂的过程;
---------------------

本文部分来自:https://blog.csdn.net/Heartyhu/article/details/51033450