云计算是分布式计算,并行计算,效用存储,网络存储,虚拟化,负载均衡,热备份冗余等传统计算机和网络技术发展融合的产物。web
服务类型
* IaaS:将硬件设备等基础资源封装成服务供用户使用。在IaaS环境中,用户至关于在使用裸机和磁盘,既可让它运行Windows,也可让它运行Linux。 IaaS最大优点在于它容许用户动态申请或释放节点,按使用量计费。而IaaS是由公众共享的,于是具备更高的资源使用效率。
* PaaS:提供用户应用程序的运行环境,典型的如Google App Engine。PaaS自身负责资源的动态扩展和容错管理,用户应用程序没必要过多考虑节点间的配合问题。但与此同时,用户的自主权下降,必须使用特定的编程环境并遵守特定的编程模型,只适用于解决某些特定的计算问题。
* SaaS:针对性更强,它将某些特定应用软件功能封装成服务。SaaS既不像PaaS同样提供计算或存储资源类型的服务,也不像IaaS同样提供运行用户自定义应用程序的环境,它只提供某些专门用途的服务供应用调用。数据库
OpenStack基本概念
编程
OpenStack便是一个社区,也算一个项目和一个开源软件,提升开放源码软件,创建公共云和私有云,它提供了一个部署云的操做平台或工具集。后端
官网:服务器
三种网络和四种节点app
管理网络 是 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