openstack 学习笔记 虚拟机的基础安装sql glance nova keystone 。。。。。

专业综合设计与开发
目 录
1、虚拟机的安装 6
1.1 虚拟机安装配置 6
1.2 安装epel仓库 6
1.3 克隆前的其它准备工作 6
2、Open Stack 7
2.1 OpenStack是什么？ 7
2.2、 OpenStack的九大组件： 7
2.2.2 Keystone identity 7
2.2.3 Neutron networking 7
2.2.4 Cindeblock storage 7
2.2.5 Nova computer 7
2.2.6 Glanceimage 7
2.2.7 Swift object storage 7
2.2.8 Ceilometermetering Ceilometer 8
2.2.9 Heat rochestration 8
2.3、OpenStack九大组件之间的关系图 8
2.4、Openstack的优势到底有哪些？ 8
2.4.1控制性。 8
2.4.2兼容性。 9
2.4.3可扩展性。 9
2.4.4灵活性。 9
2.4.5行业标准。 9
2.4.6实践检验。 9
2.5、openstack能干什么？ 9
2.5.1、管理支持服务： 9
2.5.2、基础管理服务： 10
2.5.3、扩展管理服务： 10
2.6、openstack项目简述 10
2.6.1 Openstack Compute(Nova) 10
2.6.2 Openstack Object Storage(Swift) 10
2.6.3 Openstack Block Storage(Cinder) 10
2.6.4 Openstack Networking(Neutron) 11
2.6.5 Openstack Dashboard(Horizon) 11
2.6.6 Openstack Identity Service(Keystone) 11
2.6.7 Openstack Image Service(Glance) 11
2.6.8 Openstack Telemetry Service(Ceilometer) 12
2.6.9 Openstack Orchestration Service(Heat) 12
2.6.10 Openstack Database Service(Trove) 12
2.7、Openstack Openstack日志 12
2.7.1 如何开启debug日志？ 12
2.7.2日志位置 12
2.7.3 日志格式 12
3、RabbitMQ 14
3.1、什么是队列？ 14
3.2、什么是消息队列？ 14
3.3、什么是RabbitMQ？ 14
3.4、RabbitMQ中的重要概念 15
3.5、RabbitMQ的使用流程 16
3.6、RabbitMQ的优缺点 16
3.6.1优点： 16
3.6.2缺点： 16
3.7、Exchange类型 17
3.7.1、Direct Exchange 17
3.7.2、Fanout Exchange 17
3.7.3、Topic Exchange 18
3.7.4、Headers Exchange 19
4、Keystone 20
4.1、什么是keystone？ 20
4.1.1数据安全 20
4.1.2身份和访问管理安全 20
4.1.3虚拟化安全 20
4.1.4基础设施安全 20
4.2、Keystone基本概念介绍 21
4.3、keystone的功能有哪些？ 22
4.4、keystone基础架构 23
4.4.1 Keystone API 23
4.4.2 Router 23
4.4.3 Service 23
4.4.4 Backend Driver 24
4.5、个人理解keystone 24
5、Glance 24
5.1、Glance概述： 25
5.1.1、什么是image？ 25
5.1.2 、Image service的功能？ 25
5.2、Glance架构: 26
5.2.1 glance-api 26
5.2.2 glance-registry 26
5.3、镜像状态： 27
5.3.1 queued 28
5.3.2 saving 28
5.3.3 active 28
5.3.4 deactivated 28
5.3.5 killed 28
5.3.6 deleted 28
5.3.7 Deactivating and Reactivating an image 29
5.4、镜像和实例 29
6、Nova： 30
6.1、什么是nova？ 30
6.2、nova功能和特点： 30
6.3、Nova 组件设计思想： 31
6.3.1. API 前端服务 31
6.3.2 Scheduler 调度服务 32
6.3.3. Worker 工作服务 32
6.3.4. Driver 框架 32
6.3.5. Messaging 服务 33
6.3.6. Database 33
7、Neutron 35
7.1 什么是Neutron？ 35
7.2、Neutron抽象出的概念 35
7.3、Neutron的整体架构分为几个部分？ 36
7.4、Neutron的组件 36
7.4.1 Neutron Server 36
7.4.2 ML2(Module Layer2)plugin 36
7.4.3其他组件 37
7.5、Neutron 的功能 37
7.5.1二层交换 Switching 37
7.5.2三层路由 Routing 37
7.5.3负载均衡 Load Balancing 38
7.5.4防火墙 Firewalling 38
7.5、Neutron 的架构 38
8、Dashboard 39
8.1、什么是Django? 39
8.2、horizon简述： 39
8.3、horizon架构： 40
9、学习open stack的感触： 42

1、 虚拟机的安装
1.1 虚拟机安装配置
1.11使用镜像CentOS-7-x86_64-DVD-1810.iso
1.12开始虚拟机的安装，在安装界面，选择【Install centos】，然后按tab键，进入kernel的启动设置界面，加入：net.ifnames=0 biosdevname=0
（如果不加则我们找不到后期要用的eth0）
1.13在安装过程中需要选择设置的选项有
时间区域 中国上海
语言支持 添加中文简体
设置root账户的密码
1.14配置文件
/etc/sysconfig/network-scripts/ifcfg-eth0
[root@linux-node1 network-scripts]# vi ifcfg-eth0
TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
#UUID=70ea9a1f-92d8-4f45-9172-eec10957f5e7
DEVICE=eth0
ONBOOT=yes
IPADDR=192.168.56.99
NETMASK=255.255.255.0
GATEWAY=192.168.56.2
保存退出连接xshell。（sysytemctl restart network）
1.15关闭防火墙
1.16设置主机名称
1.17修改为以下内容8设置DNS解析
1.2 安装epel仓库
1.2.1 虚拟机的克隆
1.2.2 OPENSTACK基础服务安装
1.3 克隆前的其它准备工作
（1）更新系统并重启
（2）确认防火墙关闭
1.3.1克隆虚拟机（选择创建完整克隆）
注意：克隆后修改目标机器的IP地址和hostname
1.3.2 测试两个节点能否通信（通过主机IP地址和域名相互测试能否ping通）

2、Open Stack
2.1 OpenStack是什么？
OpenStack是一个由NASA（美国国家航空航天局）和Rackspace合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API以进行集成。
2.2、 OpenStack的九大组件：
2.2.1 Horizon dashboard 一个基于web界面用于管理Openstack的服务。它提供了图形化的用户界面用于管理Openstack中的其他服务。例如：发布实例、管理网络、设置访问控制等。
2.2.2 Keystone identity 一个集中的身份验证服务，为Openstack中其它服务提供验证和授权。Keystone提供了一个中心的登记册，可以把Openstack中的其他服务添加或从keystone中删除。Keystone提供了多种方式的验证，包括基于用户名密码、基于令牌系统和AWS的logins。Keystone扮演着一个SSO身份。（SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。）
2.2.3 Neutron networking 目前在openstack中用于处理虚拟网络基础设施的创建和管理的服务。内容包括网络、子网、路由等。由于opensack的可插入式模块化架构，像防火墙、VPN等高级的服务也可以使用。
2.2.4 Cinder block storage 一种管理虚拟机存储卷的服务。为运行在Nova中的实例提供持续的块存储。快照的功能在cinder中常被使用。快照可以备份数据，用于数据的恢复，或用于克隆创建新的块存储。
2.2.5 Nova computer 一种用于管理运行在节点上的虚拟机网络和提供虚拟机硬件需求的服务。Nova是一个分布式的组件，使用接口让Keystone来提供认证，Glance提供虚拟机的image镜像，Horizon提供web管理界面。Nova被设计成使用scale-out方式水平地管理硬件资源，下载image，然后按照需求来发布实例。Nova使用libvirtd,qemu,and kvm技术来运行虚拟机。
2.2.6 Glance image 提供发布实例时的镜像模板集中管理.
2.2.7 Swift object storage 一个提供对象存储，允许用户存储和检索文件的服务。Swift架构是分布式的，允许水平缩放存储空间提供冗余失效验证保护。使用软件管理数据复制，比硬件设施具有更好的扩展性和冗余性
2.2.8 Ceilometer metering Ceilometer监控通过在计算节点部署compute服务，轮询其计算节点上的instance，获取各自的cpu、网络、磁盘等监控信息，发送到RabbitMQ，Collector服务负责接收信息进行持久化存储。Ceilometer项目创建时最初的目的是实现一个能为计费系统采集数据的框架。在G版的开发中，社区已经更新了他们的目标，新目标是希望Ceilometer成为OpenStack里数据采集（监控数据、计费数据）的唯一基础设施，采集到的数据提供给监控、计费、面板等项目使用。他像一个漏斗一样，能把openstack内部发生的几乎所有的时间都收集起来，然后为计费和监控以及其他服务提供数据支撑。
2.2.9 Heat rochestration 使用及通过REST API和AWS的cloudFormation兼容查询API使用cloudFormation模板格式编排多个混合的云计算应用程序的服务。Heat整合其他openstack的核心组件成为一个文件模板系统，允许使用这个模板创建大多数的资源类型（如：实例、高可用性、实例自动缩放、嵌套堆栈）。
2.3、OpenStack九大组件之间的关系图

图2-1

2.4、Openstack的优势到底有哪些？
2.4.1控制性。
开源的平台意味着不会被某个特定的厂商绑定和限制，而且模块化的设计能把遗留的和第三方的技术进行集成，从而来满足自身业务需要。OpenStack项目所提供的云计算，让IT团队可以成为自己的云计算服务厂商，虽然构建和维护一个开源私有云计算并不适合每一家公司；但是如果拥有基础设施和开发人员，OpenStack将是很好的选择。

2.4.2兼容性。
OpenStack公共云的兼容性可以使企业在将来很容易的将数据和应用迁移到基于安全策略的、经济的和其他关键商业标准的公共云中。使用亚马逊网络服务及其他云服务的企业，抱怨最多的就是“用户被绑架，无法轻易转移数据”。在云计算社区，有一个流行的概念，即数据是有重量的，一旦将数据存在某个云计算提供商那里，它就变得繁重而难以迁移，作为企业最重要的资源，如果在迁移的过程中不能保护好数据安全，很有可能会给企业带来灭顶之灾，相信没有公司愿意承担这个风险。

2.4.3可扩展性。
目前，主流的Linux操作系统，包括Fedora、SUSE等都将支持OpenStack。OpenStack在大规模部署公有云时，在可扩展性上有优势，而且也可用于私有云，一些企业特性也在逐步完善中。随着Ubuntu 12.04 LTS正式全面将Eucalyptus替换成OpenStack，OpenStack将超过Eucalyptus成为云平台基础的第一选择。

2.4.4灵活性。
灵活性是OpenStack最大的优点之一，用户可以根据自己的需要建立基础设施，也可以轻松地为自己的集群增加规模。主要用Python编写的OpenStack代码质量相当高，很容易遵循，带有一个完全文档的API，用户可以使用JSON或者XML消息格式的不同组件的代码，这相当有利于项目的发展壮大。此外，OpenStack项目的代码将在极为宽松自由的Apache 2许可下发布，这意味着任何第三方都可以重新发布这些代码，在其基础上开发私有软件并按照新的许可发布，给众多的云计算企业，留下了的更大的发展空间。

2.4.5行业标准。
来自全球十多个国家的60多家领军企业，包括Cisco、Dell、Intel以及微软都参与到了OpenStack的项目中，并且在全球使用OpenStack技术的云平台在不断的上线。云计算领军企业的加入，会无形透露出一个信息，就是OpenStack未来可能会成为一个行业标准，而且OpenStack项目研发的初衷就是制定一套开源软件标准。

2.4.6实践检验。
实践是检验真理的唯一标准，OpenStack的云操作系统，已被全球正在运营的大型公有云和私有云技术所验证过，比如，Dell公司已经推出了OpenStack安装程序Crowbar，不仅如此，OpenStack在中国的发展趋势也是非常之好，包括物联网用户、国内高校以及部分大小企业，都开始利用OpenStack建立云计算环境，整合企业架构以及治理公司内部的IT基础架构。

2.5、openstack能干什么？
OpenStack主要被应用于私有云。大多数企业用OpenStack搭建私有云，只有少数企业企业用OpenStack搭建公有云。而选择OpenStack的主要原因是节省成本。OpenStack的开源属性是其流行的主要原因之一。但有趣的是，更多企业表示节省成本是他们选择OpenStack的主要原因。、
控制节点架构，控制节点包括以下几个服务：

2.5.1、管理支持服务：
包含MySQL与Rabbit MQ两个服务
MySQL：数据库作为基础/扩展服务产生的数据存放的地方
Rabbit MQ：消息代理(也称消息中间件)为其他各种服务之间提供了统一的消息通信服务

2.5.2、基础管理服务：
包含Keystone，Glance，Nova，Neutron，Horizon五个服务
Keystone：认证管理服务，提供了其余所有组件的认证信息/令牌的管理，创建，修改等等，使用MySQL作为统一的数据库
Glance：镜像管理服务，提供了对虚拟机部署的时候所能提供的镜像的管理，包含镜像的导入，格式，以及制作相应的模板
Nova：计算管理服务，提供了对计算节点的Nova的管理，使用Nova-API进行通信
Neutron：网络管理服务，提供了对网络节点的网络拓扑管理，同时提供Neutron在Horizon的管理面板
Horizon：控制台服务，提供了以Web的形式对所有节点的所有服务的管理，通常把该服务称为DashBoard

2.5.3、扩展管理服务：
包含Cinder，Swift，Trove，Heat，Centimeter五个服务
Cinder：提供管理存储节点的Cinder相关，同时提供Cinder在Horizon中的管理面板
Swift：提供管理存储节点的Swift相关，同时提供Swift在Horizon中的管理面板
Trove：提供管理数据库节点的Trove相关，同时提供Trove在Horizon中的管理面板
Heat：提供了基于模板来实现云环境中资源的初始化，依赖关系处理，部署等基本操作，也可以解决自动收缩,负载均衡等高级特性。

2.6、openstack项目简述
2.6.1 Openstack Compute(Nova)

Nova是云计算环境中的主要控制器，主要采用Python语言编写使用目前成熟的虚拟化技术（KVM、 XenServer）来管理和自动化计算资源池的操作OpenStack 只是作为一个平台存在，并不充当计算资源的提供者和资源的消费者。

2.6.2 Openstack Object Storage(Swift)

Swift是OpenStack的对象存储（Object Storage）项目，是一个可扩展并且提供了冗余的存储系统。
对象和文件分散存储在同一集群中的多台服务器的磁盘上，由OpenStack负责数据的复制和一致性。
对象存储系统是用于存储大量静态数据的分布式存储系统，没有主节点或者管理节点，便于系统的扩展和数据的冗余和持久化。
存储的集群可以通过添加服务器完成横向的扩展。
如果集群中服务器或者磁盘出现失败的情况，OpenStack会复制数据到集群中的其他节点。

2.6.3 Openstack Block Storage(Cinder)

Cinder是OpenStack的块存储服务。
为云环境中的计算实际提供块设备的创建、添加和卸载。
Cinder目前支持多种存储平台（Linux server storage, Ceph, CloudByte, Coraid, EMC (VMAX and VNX), GlusterFS, IBM Storage (Storwize family, SAN Volume Controller, and XIV Storage System), Linux LIO, NetApp, Nexenta, Scality, SolidFire and HP (Store Virtual and StoreServ 3Par families)。
块设备适用于对性能要求较高的应用场景：比如数据库。
块设备的快照功能可以实现基于块存储卷的数据备份，而且也可以利用快照进行数据恢复。

2.6.4 Openstack Networking(Neutron)

OpenStack 的网络服务，现已由之前的 Quantum 改名为 Neutron。
Neutron 提供云计算环境下的虚拟网络功能，目的是为 OpenStack 云更灵活地划分物理网络，在多租户环境下提供给每个租户独立的网络环境。
用户可以创建自己的网络，控制网络流量，也可以控制服务器和设备连接一到时多个网络。
Neutron 服务网络管理的三种模式：
— FlatDHCP 模式
— Flat 模式
— VLAN 模式

2.6.5 Openstack Dashboard(Horizon)

Dashboard为管理员提供了一个图形化的接口。
可以访问和管理基于云计算的资源— 计算、存储、网络等。
提供了很高的可扩展性，支持添加第三方的自定义模块，比如：计费、监控和额外的管理工具。
支持其他云计算提供商在Dashboard进行二次的开发。

2.6.6 Openstack Identity Service(Keystone)

提供了用户目录的集中式存储，便于其他OpenStack服务的访问。
可以和现有的目录服务(如LDAP)相结合，提供企业内部的单点目录的访问。
创建用户和租户，并且以基于角色的方式限制用户和租户访问云计算中的计算、网络和存储等资源。
支持多种方式的校验：
— 标准的用户名和密码的校验
— 基于令牌的认证
— 基于证书的认证

2.6.7 Openstack Image Service(Glance)

Glance是OpenStack的镜像服务，提供了磁盘和服务器虚拟镜像的查询、注册和传输的功能 。

Glance本身并不存储镜像，它只是一个代理，充当镜像存储服务和其他OpenStack组件之间的纽带。
可以将磁盘和服务器镜像存储在OpenStack的后端服务上，比如对象存储系统上。
管理员可以利用镜像服务创建镜像模板，用户可以选择现有的镜像创建服务器。

2.6.8 Openstack Telemetry Service(Ceilometer)

测量服务:可以收集云计算中不同服务的统计信息,云操作人员可以查看所有资源的统计信息或者单个资源的统计信息像一个漏斗一样，能把OpenStack内部发生的几乎所有的事件都收集起来，然后为计费和监控以及其它服务提供数据支撑

2.6.9 Openstack Orchestration Service(Heat)

部署编排服务:提供了一种通过模板定义的协同部署方式。
模板驱动的引擎，允许应用开发人员使用提供的模板语言描述云环境的架构，并且以自动化的方式进行部署云计算资源。
通过和Telemetry service结合，可以更好的实现云计算资源扩展的自动化。

2.6.10 Openstack Database Service(Trove)

为用户在OpenStack的环境提供可扩展和可靠的关系型数据库引擎服务。
主要用于帮助用户在复杂管理时进行资源的隔离，方便进行自动化的管理操作
用户可以根据需要创建多个数据库。

2.7、Openstack Openstack日志
2.7.1 如何开启debug日志？

openstack开启debug日志的方式十分简单，只要在相关服务的配置文件的DEFAULT部分下配置"debug=true"配置项后重启服务即可：
openstack-config --set /etc/nova/nova.conf DEFAULT debug true
2.7.2日志位置

Openstack日志一般放在/var/log下，例如nova的日志就位于/var/log/nova下，每个服务都有自己的日志文件，从命名上很容易区分：
每个子服务都以“nova-”开头：
“nova-api.log”就是“openstack-nova-api”服务的的日志，依次类推。
图4-1
2.7.3 日志格式

Opentack日志格式都是统一的，如下:

图2-2
<时间戳><日志等级><代码模块><日志内容><源代码位置>
说明：
时间戳：日志记录的时间，包括 年 月 日 时 分 秒 毫秒
日志基本：有INFO WARNING ERROR DEBUG等
代码模块：当前运行的模块
Request ID：日志会记录连续不同的操作，为了便于区分和增加可读性，每个操作都被分配唯一的Request ID,便于查找
日志内容：这是日志的主体，记录当前正在执行的操作和结果等重要信息
源代码位置：日志代码的位置，包括方法名称，源代码文件的目录位置和行号。这一项不是所有日志都有
下面我们来举例说明：
图
这条日志我们可以得知：
代码模块是nova.api.openstack.wsgi,由此可以得知是nova API请求的的日志内容
日志的内容是json格式，内容是api送了请求的创建instance的申请，申请中包含了instance的基本信息
如果要跟踪源代码，可以到“/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py”的789行，方法“_process_stack”

3、RabbitMQ
3.1、什么是队列？

队列是常用的数据结构之一，是一种特殊的线性表，特殊之处在于它只允许在表的前端(front)进行删除操作，而在表的后端(rear)进行插入操作。
进行插入操作的端称为队尾，进行删除操作的端称为对头。

3.2、什么是消息队列？

消息是计算机/应用间传送的数据单位，可以非常简单，例如只包含文本字符串，也可以很复杂，可能包含嵌入对象。
消息队列是在消息的传输过程中保存消息的容器。
消息传输时，先发送到队列，队列的主要目的是提供路由并保证消息的传递，如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功的传递它。
可以把消息队列理解成快递公司，你需要寄一个物件（消息）给你的朋友，快递公司收到物件会保证物件送到你的朋友手中，可能存在多次寄送才送达成功的情况，比如第一次送过去，你朋友不在家。
也许有人好奇，为什么我们不直接使用JDK自带的队列，而是要使用消息队列呢？
这是因为JDK自带的队列都存储在内存中，一但应用或者服务器挂了，消息就丢失了，使用消息队列可以避免消息丢失问题（注意不是100%不丢失），就像快递公司会保证你的物件寄到你的朋友手中，但肯定有丢件的几率。

3.3、什么是RabbitMQ？

MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。RabbitMQ是用Erlang语句开发的基于高级消息队列协议(AMQP)的消息队列中间件。因为它开源，而且版本更新快，所以在国内互联网公司被广泛使用。其它使用的消息中间件还有ActiveMQ，RocketMQ，Kafka等，有兴趣的同学可以自行研究。
还有2个专业术语要了解下：
生产者：发送消息的应用程序被称为生产者。
消费者：接收消息的应用程序被称为消费者

图3-1
3.4、RabbitMQ中的重要概念

图3-2

（1）Broker：经纪人。提供一种传输服务，维护一条从生产者到消费者的传输线路，保证消息数据能按照指定的方式传输。粗略的可以将图中的RabbitMQ Server当作Broker。

（2）Exchange：消息交换机。指定消息按照什么规则路由到哪个队列Queue。

（3）Queue：消息队列。消息的载体，每条消息都会被投送到一个或多个队列中。

（4）Binding：绑定。作用就是将Exchange和Queue按照某种路由规则绑定起来。

（5）RoutingKey：路由关键字。Exchange根据RoutingKey进行消息投递。

（6）Vhost：虚拟主机。一个Broker可以有多个虚拟主机，用作不同用户的权限分离。一个虚拟主机持有一组Exchange、Queue和Binding。

（7）Producer：消息生产者。主要将消息投递到对应的Exchange上面。一般是独立的程序。

（8）Consumer：消息消费者。消息的接收者，一般是独立的程序。

（9）Channel：消息通道，也称信道。在客户端的每个连接里可以建立多个Channel，每个Channel代表一个会话任务。

3.5、RabbitMQ的使用流程

AMQP模型中，消息在producer中产生，发送到MQ的exchange上，exchange根据配置的路由方式投递到相应的Queue上，Queue又将消息发送给已经在此Queue上注册的consumer，消息从queue到consumer有push和pull两种方式。
消息队列的使用过程大概如下：

（1）客户端连接到消息队列服务器，打开一个channel。

（2）客户端声明一个exchange，并设置相关属性。

（3）客户端声明一个queue，并设置相关属性。

（4）客户端使用routing key，在exchange和queue之间建立好Binding关系。

（5）生产者客户端投递消息到exchange。

（6）exchange接收到消息后，就根据消息的RoutingKey和已经设置的binding，进行消息路由（投递），将消息投递到一个或多个队列里。

（7）消费者客户端从对应的队列中获取并处理消息。

3.6、RabbitMQ的优缺点
3.6.1优点：
（1）由Erlang语言开发，支持大量协议：AMQP、XMPP、SMTP、STOMP。
（2）支持消息的持久化、负载均衡和集群，且集群易扩展。
（3）具有一个Web监控界面，易于管理。
（4）安装部署简单，上手容易，功能丰富，强大的社区支持。
（5）支持消息确认机制、灵活的消息分发机制。

3.6.2缺点：

（1）由于牺牲了部分性能来换取稳定性，比如消息的持久化功能，使得RabbitMQ在大吞吐量性能方面不及Kafka和ZeroMQ。

（2）由于支持多种协议，使RabbitMQ非常重量级，比较适合企业级开发。因此当需要一个稳定的、高可靠性的、功能强大且易于管理的消息队列可以选择RabbitMQ。如果对消息吞吐量需求较大，且不在乎消息偶尔丢失的情况可以使用Kafka。

3.7、Exchange类型
3.7.1、Direct Exchange

（1）名称：直接交换器类型

（2）默认的预先定义exchange名字：空字符串或者amq.direct

（3）作用描述：根据Binding指定的Routing Key，将符合Key的消息发送到Binding的Queue。可以构建点对点消息传输模型。

图3-3

如图中RoutingKey分别是error、info、warning，其中error被Binding（绑定）到queue1和queue2上，info和warning被Binding到queue2上。当消息的RoutingKey是error，这条消息将被投递到queue1和queue2中（相当于消息被复制成两个分别投放到两个queue中），然后分别被Consumer1和Consumer2处理。如果消息的RoutingKey是info或者warning，这条消息只会被投递到queue2中，然后被Consumer2处理。如果消息的RoutingKey是其他的字符串，这条消息则会被丢弃。

3.7.2、Fanout Exchange
（1）名称：广播式交换器类型
（2）默认的预先定义exchange名字：amq.fanout
（3）作用描述：将同一个message发送到所有同该Exchange 绑定的queue。不论RoutingKey是什么，这条消息都会被投递到所有与此Exchange绑定的queue中。

图3-4

广播式交换器类型的工作方式：不使用任何参数将queue和Exchange进行Binding，发布者publisher向Exchange发送一条消息（注意：直接交换器类型中的producer变成了publisher，其中隐含了两种交换器的区别），然后这条消息被无条件的投递给所有和这个Exchange绑定的queue中。

如图中，没有RoutingKey的限制，只要消息到达Exchange，都会被投递到queue1和queue2中，然后被对应的Consumer处理。

3.7.3、Topic Exchange
（1）名称：主题交换器类型
（2）默认的预先定义exchange名字：amq.topic
（3）作用描述：根据Binding指定的RoutingKey，Exchange对key进行模式匹配后投递到相应的Queue，模式匹配时符号“#”匹配一个或多个词，符号“*”匹配正好一个词，而且单词与单词之间必须要用“.”符号进行分隔。此模式可以用来支持经典的发布/订阅消息传输模型-使用主题名字空间作为消息寻址模式，将消息传递给那些部分或者全部匹配主题模式的queue。

图3-5

如图中，假如消息的RoutingKey是American.action.13，这条消息将被投递到Q1和Q2中。假如RoutingKey是American.action.13.test（注意：此处是四个词），这条消息将会被丢弃，因为没有routingkey与之匹配。假如RoutingKey是Chinese.action.13，这条消息将被投递到Q2和Q3中。假如RoutingKey是Chinese.action.13.test，这条消息只会被投递到Q3中，#可以匹配一个或者多个单词，而*只能匹配一个词。

3.7.4、Headers Exchange
（1）名称：标题交换器类型

（2）默认的预先定义exchange名字：amq.match和amq.headers

（3）作用描述：同direct exchange类似，不同之处是不再使用Routing Key路由，而是使用headers（Message attributes）进行匹配路由到指定Queue。

Headers类型的exchange使用的比较少，它也是忽略routingKey的一种路由方式。是使用Headers来匹配的。Headers是一个键值对，可以定义成HashTable。发送者在发送的时候定义一些键值对，接收者也可以再绑定时候传入一些键值对，两者匹配的话，则对应的队列就可以收到消息。匹配有两种方式all和any。这两种方式是在接收端必须要用键值"x-mactch"来定义。all代表定义的多个键值对都要满足，而any则代码只要满足一个就可以了。fanout，direct，topic exchange的routingKey都需要要字符串形式的，而headers exchange则没有这个要求，因为键值对的值可以是任何类型。

4、Keystone
4.1、什么是keystone？
Keystone（OpenStack Identity Service）是OpenStack框架中，负责身份验证、服务规则和服务令牌的功能， 它实现了OpenStack的Identity API。Keystone类似一个服务总线， 或者说是整个Openstack框架的注册表， 其他服务通过keystone来注册其服务的Endpoint（服务访问的URL），任何服务之间相互的调用， 需要经过Keystone的身份验证， 来获得目标服务的Endpoint来找到目标服务。随着云计算的愈发火热，参与到其中的人越来越多，不管是政府部门还是世界的各家大小公司，纷纷参与到了这股浪潮中。而用户作为消费者选择云平台，主要是因为云计算相对于传统的方式可以带给自己费用上的节省，能获得快捷服务的体验，越来越多的用户选择云产品，意味着将会有越来越多的数据存储在“云端“，安全性如何保证无疑会成为为摆在云服务提供商以及终端用户面前一个非常现实的问题。对于任何一个任何的软件来说，安全都是一个无法忽略的问题，没有哪个软件不考虑安全性因素，当然也没有哪一款软件可以解决所有的安全性问题。那么对于提供云基础架构服务的openstack来说，安全性的设计是一个重要的考虑点。
4.1.1数据安全
云服务提供商需要保证用户的数据不被窃取或是丢失，强加密及密钥管理是云计算系统用于保护数据安全的一种核心机制。加密的数据虽然不能保证不丢失，但对于无法获取明文的数据来输，危害相对就降低了很多；密钥管理则提供了对保护资源的访问控制。在keystone中主要是引入令牌机制来保护用户对于资源的访问，同时引入PKI（公钥基础实施）对令牌加以保护。
4.1.2身份和访问管理安全
有效的身份和访问控制是云平台必不可少的一环，云计算中需要合理定义系统管理人员的控制边界，以防来自内部的攻击造成的危害。Keystone中通过Policy（访问规则）来做到基于用户角色的访问控制。
4.1.3虚拟化安全
云计算离不开虚拟化，虚拟化技术在计算能力、网络、内存等方面的应用扩展了多租户下的云服务，那么如何有效的隔离众多的虚拟机，以防发生数据污染，不同敏感度和安全性要求的虚拟机如何共存等问题，对于虚拟化安全提出了很高的要求。
4.1.4基础设施安全
基础设施安全包括服务器、存储、网络等核心的IT基础设施的安全，对于不同的基础设施引进不同安全控制机制，比如服务器层的安全控制机制：强认证、安全事件日志等，以此来提高基础设施的安全性。

4.2、Keystone基本概念介绍

4.2.1 User

User即用户，他们代表可以通过keystone进行访问的人或程序。Users通过认证信息（credentials，如密码、API Keys等）进行验证。

4.2.2 Tenant

Tenant即租户，它是各个服务中的一些可以访问的资源集合。例如，在Nova中一个tenant可以是一些机器，在Swift和Glance中一个tenant可以是一些镜像存储，在Quantum中一个tenant可以是一些网络资源。Users默认的总是绑定到某些tenant上。

4.2.3 Role

Role即角色，Roles代表一组用户可以访问的资源权限，例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的 或 租户内的角色中。在全局的role中，用户的role权限作用于所有的租户，即可以对所有的租户执行role规定的权限；在租户内的role中，用户仅能在当前租户内执行role规定的权限。

4.2.4 Service

Service即服务，如Nova、Glance、Swift。根据前三个概念（User，Tenant和Role）一个服务可以确认当前用户是否具有访问其资源的权限。但是当一个user尝试着访问其租户内的service时，他必须知道这个service是否存在以及如何访问这个service，这里通常使用一些不同的名称表示不同的服务。在上文中谈到的Role，实际上也是可以绑定到某个service的。例如，当swift需要一个管理员权限的访问进行对象创建时，对于相同的role我们并不一定也需要对nova进行管理员权限的访问。为了实现这个目标，我们应该创建两个独立的管理员role，一个绑定到swift，另一个绑定到nova，从而实现对swift进行管理员权限访问不会影响到Nova或其他服务。

4.2.5 Endpoint

Endpoint，翻译为“端点”，我们可以理解它是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道他的endpoint。因此，在keystone中包含一个endpoint模板（endpoint template，在安装keystone的时候我们可以在conf文件夹下看到这个文件），这个模板提供了所有存在的服务endpoints信息。一个endpoint template包含一个URLs列表，列表中的每个URL都对应一个服务实例的访问地址，并且具有public、private和admin这三种权限。public url可以被全局访问（如http://compute.example.com），private url只能被局域网访问（如http://compute.example.local），admin url被从常规的访问中分离。

keystone 里面的概念很多，有：User，Credentials，Authentication，Token，Tenant，Service，Endpoint，Role。在这么多概念中，其实最主要的就是 User 和 Tenant 。由于一些安全，服务问题，才引发了其它的概念。
　　那什么叫做 User ，Tenant 呢？这里我举个比较好理解的例子。我们去宾馆住的时候，我们自己就相当于 User ，而宾馆就是 Tenant 。这是最简单的情况，宾馆值提供房间，我们只需要住房。
随着后来生活物质等的提高，这种现象就变了。我们去宾馆住的时候，很多东西都不一样，比如，开房间要身份证，房间的钥匙是一个可以当卡刷的牌子，我们进出宾馆的时候需要用自己的钥匙来开启宾馆的大门；还有就是，宾馆不仅仅是用来住的了，它可以给我们提供饮食，娱乐，健身等各种服务；而且服务层次的不同，房间也不同，房间里面的配置豪华程度也不一样。在这种情况下，描述我们和宾馆之间的关系就复杂一些了，这就引发了一些新的概念。

4.3、keystone的功能有哪些？
openstack是一个SOA架构，各个项目独立提供先关的服务，且互不依赖，如nova提供计算服务，glance提供镜像服务等。防止耦合性，且扩展性不高实际上所有的组件都依赖keystone，
它有两个功能：
（1）用户管理：验证用户身份信息合法性
（2）服务目录管理：提供各个服务目录的（Service Catalog:包括service和endpoint）服务，无论任何服务或者客户访问openstack都要访问keystone获取服务列表，以及每个服务的endpoint
如下图，这个图只是一个简单的表达，具体里面的工作流程肯定不止这些，各位慢慢往下看

图4-1

作为 OpenStack 的基础支持服务，Keystone 做下面这几件事情：
管理用户及其权限
维护 OpenStack Services 的 Endpoint
Authentication（认证）和 Authorization（鉴权）

4.4、keystone基础架构
4.4.1 Keystone API
Keystone API与Openstack其他服务的API类似，也是基于ReSTFul HTTP实现的。Keystone API划分为Admin API和Public API,其中Public API不仅实现获取版本以及相应扩展信息的操作，同时包括获取Token以及Token租户信息的操作；Admin API主要提供服务开发者使用，不仅可以完成Public API的操作，同时对User、Tenant、Role和Service Endpoint进行管理操作。
4.4.2 Router
Keystone Router主要实现上层API和底层服务的映射和转换功能，包括四种Router类型。
（1） AdminRouter
负责将Admin API请求映射为相应的行为操作并转发至底层相应的服务执行；
（2） PublicRouter
与AdminRouter类似；
（3） PublicVersionRouter
对系统版本的请求API进行映射操作；
（4） AdminVersionRouter
与PublicVersionRouter类似。
4.4.3 Service
Keystone Service接收上层不同Router发来的操作请求，并根据不同后端驱动完成相应操作，主要包括四种类型；
（1） Identity Service
Identity Service提供认证凭证的验证服务，并依靠相应的后端驱动来获取User、Tenant、Role和Metadata等相关数据；Keystone支持Sql.Identity、kvs.Identity、pam.Identity、ldap.Identity四种后端驱动，系统默认的是Sql.Identity；

（2） Token Service
Token Service提供令牌相关的管理操作，当前的Keystone对于Token Service
支持Sql.Token、Memcache.Token、Kvs.Token三种后端驱动，系统默认的是
Kvs.Token；
（3） Catalog Service
Catalog Service提供service和Endpoint相关的管理操作，目前支持三种后端驱动：Sql.Catalog、Kvs.Catalog、Templated.TemplatedCatalog三种后端驱动，系统默认的是Templated.TemplatedCatalog；

（4） Policy Service
Policy Service提供一个基于规则的授权驱动，当前支持一种简单的规则匹配，即给定一个匹配列表，来确认凭证中是否包含相应的规则，并根据匹配情况决定最后的授权。
4.4.4 Backend Driver
Backend Driver具有多种类型，不同的Service选择不同的Backend Driver。

4.5、个人理解keystone
我的理解是：当用户向 Keystone 提供自己的身份验证信息，登录用户名和密码。Keystone 会从数据库中读取数据对其验证，如果验证通过，会向用户返回一个 token，此后用户所有的请求都会使用该 token 进行身份验证。如用户向 Nova 申请虚拟机服务，nova 会将用户提供的 token 发给 Keystone 进行验证，Keystone 会根据 token 判断用户是否拥有进行此项操作的权限，若验证通过那么 nova 会向其提供相对应的服务。其它组件和 Keystone 也会相互验证吧。我的理解就是这样。

图4-2

5、Glance
5.1、Glance概述：
Glance（OpenStack Image Service）是一个提供发现，注册，和下载镜像的服务。Glance 提供了虚拟机镜像的集中存储。通过 Glance 的 RESTful API，可以查询镜像元数据、下载镜像。虚拟机的镜像可以很方便的存储在各种地方，从简单的文件系统到对象存储系统(比如 OpenStack Swift)。在 Glance 里镜像被当做模板来存储，用于启动新实例。Glance 还可以从正在运行的实例建立快照用于备份虚拟机的状态。
Glance 具体功能如下：
提供 RESTful API 让用户能够查询和获取镜像的元数据和镜像本身；
支持多种方式存储镜像，包括普通的文件系统、Swift、Ceph 等；
对实例执行快照创建新的镜像。
Clance 在整个 OpenStack 架构中的位置如下图：

5.1.1、什么是image？
要理解Image Service先得搞清楚什么是Image， 以及为什么要用Image？

5.1.2 、Image service的功能？
Image Service的功能是管理Image，让用户能够发现、 获取和保存 Image。
在OpenStack中， 提供Image Service的是 Glance， 其具体功能如下：
提供REST API， 让用户能够查询和获取 image的元数据和image 本身。
支持多种方式存储image， 包括普通的文件系统、Swift、Amazon S3等。
对Instance执行Snapshot创建新的image。

图5-1

5.2、Glance架构:
在 Newton 之前的版本中，Glance 支持两种 RESTful API V1和V2，两者区别为：
V1只提供了基本的镜像和用户操作功能：镜像创建、删除、下载、列表、详细信息查询、更新，以及镜像租户成员的创建、删除和列表。
V2除了支持V1的所有功能外，主要是增加了如下功能：
● 镜像 location 的添加、删除和修改等操作；
● metadata namespace 操作；
● 镜像 tag 操作。
V1 和V2对镜像后端存储的支持是相同的。
V1版本的实现，具有 glance-api 和 glance-registry 两个 WSGI 服务，二者都提供 RESTful API，但需要强调的一点是，glance-registry 提供的 RESTful API 是给 glance-api 使用的，并不开放给外部用户。

图5-2

5.2.1 glance-api
glance-api 是系统后台运行的服务进程。 对外提供 RESTful API，响应镜像查询、获取和存储的调用。glance-api 不会真正处理请求。

如果是与镜像 metadata（元数据）相关的操作，glance-api 会把请求转发给 glance-registry；
如果是与镜像自身存取相关的操作，glance-api 会把请求转发给该 image 的存储后端。

5.2.2 glance-registry
glance-registry 是系统后台运行的服务进程。 负责处理和存取镜像的 metadata，例如镜像的大小和类型。
V2版本的实现就是将 glance-registry 集成到了 glance-api 内部，这么做的好处是减少了一个中间的处理环节。V1版本在 Newton 中标注被弃用，目前已经被移除。
Glance 支持多种格式的镜像，包括：

图5-3

Glance 自己并不存储镜像。 真正的镜像是存放在后端存储中的。Glance 支持多种后端存储，包括：
A directory on a local file system：这是默认配置，在本地的文件系统里进行保存镜像。
GridFS：使用MongoDB存储镜像。
Ceph RBD：使用Ceph的RBD接口存储到Ceph集群中。
Amazon S3：亚马逊的S3。
Sheepdog：专为QEMU/KVM提供的一个分布式存储系统。
OpenStack Block Storage (Cinder)
OpenStack Object Storage (Swift)
HTTP：可以使用英特网上的http服务获取镜像。这种方式只能只读。
VMware ESX/ESXi or vCenter。
具体使用哪种 backend，是在 /etc/glance/glance-api.conf 中配置的

5.3、镜像状态：
上传镜像时 Glance 会显示镜像的各种状态。当我们上传镜像时，第一步就是入队列，经过短时间的验证，镜像进入 queued 状态，保存镜像并开始上传。之后镜像会进入 saving 的状态，表示还没有完全上传完毕。镜像完全上传后，状态会变成 active。如果上传失败，将会变成 killed 或 deleted 状态。

图5-4

5.3.1 queued
在 Glance registry 里已经通过验证可以开始存储。暂时没有镜像数据被上传到 Glance，镜像大小在上传时设置为0。

5.3.2 saving
表示正在上传镜像到 Glance。通过POST /images 接口注册镜像，如果有 x-image-meta-location http 头，这个镜像将不会处于 saving 状态（因为镜像数据在其他位置已经可用）。

5.3.3 active
表示在 Glance 里是一个完全可用的镜像。当镜像上传成功后，会切换到这个状态。.

5.3.4 deactivated
表示不允许任何非管理的用户访问。禁止下载镜像，同时也禁止所以可能获取镜像数据的操作，比如镜像导出和镜像克隆等操作。

5.3.5 killed
表示上传镜像时发生错误，这个镜像不可用。

5.3.6 deleted
Glance 仍然保留了镜像的相关信息，但不能在被使用。这个状态下的镜像将会被自动删除。

5.3.7 Deactivating and Reactivating an image
可以停用镜像。也可以重新激活，或者删除。当管理员对镜像进行更新时，可以先把镜像停用，这样镜像对非管理员用户就不可见了，当更新完成后，可以重新激活镜像，以便用户可以用更新后镜像启动虚拟机。

5.4、镜像和实例
镜像作为模板存储，镜像服务存储和管理镜像。实例是在计算节点上运行的单个虚拟机，计算节点管理这些实例。用户可以从用同一个镜像启动任意数量的实例。每个启动的实例都是基于镜像的一个副本，所以实例上的任何修改都不会影响到镜像。我们可以对正在运行实例做快照，并可以用快照于启动另一个新的实例。

当我们启动一个实例时，我们需要指定 flavor。flavor 定义了实例可以有多少个虚拟 CPU，多大的 RAM 以及根磁盘、临时磁盘的大小。

下图显示了启动实例的系统状态。glance 包含一定数量的镜像，compute node 包含可用的 vcpu，内存和本地磁盘资源，cinder-volume 包含一定数量的 volume。

图5-5

启动实例之前，需要选择一个镜像，flavor 和任何可选属性。选定的 flavor 提供一个系统盘，标记为 vda，另外一个临时盘被标记为 vdb（如果 flavor 中临时磁盘为0，则启动实例时不创建 vdb，一般默认也是这样设置）。

6、Nova：
6.1、什么是nova？
Nova是OpenStack云中的计算组织控制器。支持OpenStack云中实例（instances）生命周期的所有活动都由Nova处理。这样使得Nova成为一个负责管理计算资源、网络、认证、所需可扩展性的平台。但是，Nova自身并没有提供任何虚拟化能力，相反它使用libvirt API来与被支持的Hypervisors交互。Nova 通过一个与Amazon Web Services（AWS）EC2 API兼容的web services API来对外提供服务。
Nova是openstack中最核心的组件，完成了虚拟机管理的所有工作，openstack中的其他组件都是为了为nova配置资源而存在的。
（1） MySQL：为nova提供数据库服务；
（2） Keystone：为nova提供安全认证服务；
（3） Swift：作为Glance的后端，存储了nova中虚拟机的映像；
（4） Glance：为nova中的虚拟机提供镜像的存储服务；
（5） Cinder：为nova中的虚拟机提供块存储服务；
（6） Neutron：为nova中的虚拟机提供网络连接服务；
（7） Dashboard：为nova提供Web UI管理功能；

图6-1
6.2、nova功能和特点：
1）实例生命周期管理
2）管理计算资源
3）网络和认证管理
4）REST风格的API
5）异步的一致性通信
6）Hypervisor透明：支持Xen,XenServer/XCP, KVM, UML, VMware vSphere and Hyper-V
Nova是openstack中最核心的组件。openstack的其他组件归根结底是为Nova组件服务的。
Nova服务是由多个子服务构成，子服务是通过RPC实现通信。服务之间有很松的耦合性。
概念框架与逻辑框架的对应

6.3、Nova 组件设计思想：
其实也是 OpenStack 的组件设计思想，OpenStack 的所有组件设计都遵循此思想。

6.3.1. API 前端服务
nova-api 接收和响应用户的 API 调用。
除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。也就是说，如果用户以前使用 Amazon EC2，并且用 EC2 的 API 开发了一些工具来管理虚机，那么如果现在要换成 OpenStack，这些工具可以无缝迁移到OpenStack，因为nova-api兼容EC2 API，无需做任何修改。
Compute Core
nova-scheduler
虚机调度服务，负责决定在哪个计算节点上运行虚机
nova-compute
管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理
Hypervisor
计算节点上跑的虚拟化管理程序，虚拟机管理最底层的程序。不同虚拟化技术提供自己的 Hypervisor。 常用的Hypervisor 有 KVM，Xen， VMWare 等
nova-conductor
nova-conductor 经常需要更新数据库，比如更新虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 novaconductor.

Console Interface
nova-console
用户可以通过多种方式访问虚机的控制台：
nova-novncproxy，基于 Web 浏览器的 VNC 访问 nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问 nova-xvncproxy，基于 Java 客户端的 VNC 访问 nova-consoleauth
负责对访问虚机控制台请求提供 Token 认证
nova-cert
提供 x509 证书支持

设计 API 前端服务的好处在于：
对外提供统一接口，隐藏实现细节
API 提供 REST 标准调用服务，便于与第三方系统集成
可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程

图6-2

6.3.2 Scheduler 调度服务
对于某项操作，如果有多个实体都能够完成任务，那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。
Nova 有多个计算节点， 当需要创建虚机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。
除了 Nova，块服务组件 Cinder 也有 scheduler 子服务。

6.3.3. Worker 工作服务
调度服务只管分配任务，真正执行任务的是 Worker 工作服务。

在 Nova 中，这个 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 非常容易扩展：
当计算资源不够了无法创建虚机时，可以增加计算节点（增加 Worker）
当客户的请求量太大调度不过来时，可以增加 Scheduler

6.3.4. Driver 框架
OpenStack 作为开放的云操作系统，支持业界各种优秀的技术。这种开放的架构使得 OpenStack 能够在技术上保持先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。OpenStack 的这种开放性一个重要的方面就是采用基于 Driver 的框架。
以 Nova 为例，OpenStack 的计算节点支持多种 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。
nova-compute 为这些 Hypervisor 定义了统一的接口，hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。 Glance、Cinder 和 Neutron 都有 driver 框架的应用 。

6.3.5. Messaging 服务

nova-* 子服务之间的调用严重依赖 Messaging。Messaging 是 nova-* 子服务交互的中枢。带来以下好处：
解耦各子服务。子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。
提高性能。异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。
提高伸缩性。子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。

6.3.6. Database
OpenStack 各组件都需要维护自己的状态信息。比如 Nova 中有虚机的规格、状态，这些信息都是在数据库中维护的。每个 OpenStack 组件都有自己的数据库。
总结 Nova 组件设计思想的特点：
分布式：由多个逻辑和物理上均可分离的组件组成，实现灵活部署
无中心：可以通过增加组件部署实例来实现水平扩展
无状态：所有组件无本地持久化状态数据
异步执行：大部分执行流通过消息机制实现异步执行
插件化、可配置：大量使用插件机制、配置参数实现灵活的扩展与变更
RESTful API：支持 RESTful 方式访问的 API，方便客户端访问，方便集成到其他应用系统

图6-3

6.4、Nova个人总结：

Nova组件其实非常好的体现了软件设计时候的”高内聚、低耦合”方法标准。组件内部各个功能模块，通过消息队列Queue传递操作信息，而对外与OpenStack其他组件进行关联的时候统一通过nova-api，并没有与其他keystone、glance等组件进行嵌入式的强代码关联，所以可以很好的独立升级增补功能。而本身作为虚拟化技术与云计算管理之间的计算桥梁而存在，同时也是云计算发展最为长久、最原始的资源交付方式，即虚拟机。
其实个人理解，开源软件最为贡献大的，并不是提供软件架构的原型设计或源代码，而是能够提供一套行之有效影响各个技术发展走向的想法与思路。比如就像OpenStack与各个公有云和私有云产品或服务，其他厂商商用了以后基本算是已经重构全部代码了，但是仔细看看还是离不开OpenStack原生的设计思想。

7、Neutron
7.1 什么是Neutron？

“软件定义网络（sofeware-defined networking,SDN）”所有具有的灵活性和自动化优势使其成为云时代网络管理的主流。 Neutron为openstack的虚拟机提供网络方面的功能；原来没有neutron这个组件（G版名称是Quantum）的时候，网络的主要功能也是在nova组件里实现的，那时候底层采用的大多是linuxbridge，无法实现灵活组网和高级的网络功能；为此Openstack把网络大部分功能转到了neutron组件来开发实现，但是nova里还有些网络功能被保留，比如虚拟机的网卡方面的功能。

7.2、Neutron抽象出的概念
Neutron提供以下抽象对象：networks，subnets，ports和routers，每个都有映射到他们物理层面的功能：networks包含subnets，routers管理不同的子网、网络之间的路由通信。

任何给定的网络设置有至少一个外部网络。这个网络和其他的网络不一样，不仅仅是一个虚拟定义的网络。他代表从一部分外部网络（外部网络访问Openstack安装）的视角。外部网络的IP地址可以被外网的任何人访问。因为这个网络仅仅代表一部分外部网络，所以DHCP在该网络上被禁止。

对外部网络进行补充，每个网络模块设置有一个或多个的内部网络，在内部网络中每个网络都使能DHCP功能。这些软件定义的网络直接连接在虚拟机上。只要虚拟机在任何给定的内部网络上，或者子网通过接口连接到一个路由器，就可以直接连接到网络访问虚拟机。如下图所示，虚拟机在内部网络中的拓扑结构。

每个路由有一个网络使他能被一个网络和许多连接到子网的接口所连接。就像一个物理路由器一样，子网能通过同一个路由访问到不同子网的机器，而且通过路由的网关可访问到外部网络。

更多的，你可以在外部网络把IP地址分配给内部网络端口。你可以将外部网络IP地址与虚拟机上的端口相关联。这样，外部网络上的实体即可访问虚拟机。

Neutron将网络按照三层交换机的概念分为：

Network：相当于交换机根据vlan创建的一个三层接口；

Subnet：相当于交换机创建了一个三层接口地址；

Port：相当于交换机的一个物理端口，但是这个端口有一个MAC地址；

7.3、Neutron的整体架构分为几个部分？
Neutron的整体架构，逻辑上可以分为三个部分。最上面的一部分是OpenStack的控制平台，它通过用户操作直接或者间接向网络组件Neutron发送标准的命令。第二层是Neutron组件，它通常是位于一个独立的控制节点上（一台服务器），它有一套标准的API对应上层应用发给它的每个命令，这些API包括create_network、create_port、create_subnet等创建多租户网络以及创建Firewall、Load Balancer等各种业务的API。NeutronAPI从SDN的架构上来看属于北向接口。在Neutron组件内部有很多个不同的插件（plugin），这些插件大多数都是vSwitch插件，例如OVS、LinuxBridge和OpenFlow Controller等，也有部分硬件交换机插件，目前已经存在的包括Cisco、Arista和Mellanox。用户可以选择自己的网络使用哪种方式，然后选择相应的插件，这些插件会处理Neutron API调用，将它们转换为每种插件对应的switch所提供的API调用，然后通过各自定义的方式，发消息去调用虚拟交换机或者物理交换机提供的API，switch API从SDN的架构来看属于南向接口。

7.4、Neutron的组件
7.4.1 Neutron Server

这一部分包含守护进程neutron-server和各种插件neutron-*-plugin，它们既可以安装在控制节点也可以安装在网络节点。neutron-server提供API接口，并把对API的调用请求传给已经配置好的插件进行后续处理。插件需要访问数据库来维护各种配置数据和对应关系，例如路由器、网络、子网、端口、浮动IP、安全组等等。

7.4.2 ML2(Module Layer2)plugin

图7-1
上述整体框架中提到Neutron组件内部有很多个不同的插件（plugin），而在Neutron中，实现一个插件包括两个部分的内容：一部分与数据库db打交道称之为plugin（虽然都是plugin，但是这个是具体实现中的plugin），一部分是调用具体的网络设备真正干活的称之为agent。

与db进行交互的plugin在功能上有很多重复，所以在代码上有很多重复，因此在Neutron中提供了一个公共的plugin叫ML2(ModuleLayer2) plugin。所以ML2 plugin的第一个作用就是：提供与数据库交互的公共plugin。

ML2的第二个作用就是实现支持多种pulgin（原先使用linux bridge，就不能用openvswitch），ML2通过MechanismDriver实现。MechanismDriver的作用是将agent的类型agent_type和vif_type关联，这样vif_type就可以直接通过扩展api设置了。

ML2的第三个作用就是支持不同的网络拓扑，如flat, vlan, gre, vxlan，直接在ml2_conf.ini这个配置文件里都配上即可。
什么是ml2？
Moduler Layer 2（ML2）是 Neutron 在 Havana 版本中实现的一个 新的 core plugin，用于替代原有的 linux bridge plugin 和 open vswitch plugin。
为什么要提出ml2？
ML2 作为新一代的 core plugin，提供了一个框架，允许在 OpenStack 网络中同时使用多种 Layer 2 网络技术，不同的节点可以使用不同的 网络实现机制

7.4.3其他组件

上面的ml2解决的只是网络中L2层的问题，对于L3层的路由功能，neturon单独用l3-agent实现，为客户机访问外部网络提供3层转发服务。而dhcp-agent负责为各个租户网络提供DHCP服务，至于再之上的L4-L7层的FwaaS,VPNaaS, DNATaaS, DNSaaS的内容，在neutron又出来一个新的服务框架用于将所有这些除L2层以外的网络服务类似于上述ml2的思想在数据库这块一网打尽。

7.5、Neutron 的功能
7.5.1二层交换 Switching
Nova 的 Instance 是通过虚拟交换机连接到虚拟二层网络的。
Neutron 支持多种虚拟交换机，包括 Linux 原生的 Linux Bridge 和
Open vSwitch。 Open vSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。
利用 Linux Bridge 和 OVS，Neutron 除了可以创建传统的 VLAN 网络，还可以创建基于隧道技术的 Overlay 网络，比如 VxLAN 和 GRE（Linux
Bridge 目前只支持 VxLAN）。
7.5.2三层路由 Routing
Instance 可以配置不同网段的 IP，Neutron 的 router（虚拟路由器）实现 instance 跨网段通信。router 通过 IP forwarding，iptables 等技术来实现路由和 NAT。
个人理解：Neutron设计的目的是为OpenStack虚拟环境提供灵活地网络功能，为多租户环境下的每个租户提供独立的网络环境，功能类似于VMware NSX虚拟网络功能，可是实现原理不同。Neutron通过API实现这种目标，用户可以创建自己的网络对象，该项目发展迅速。
7.5.3负载均衡 Load Balancing
Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service
（LBaaS），提供了将负载分发到多个instance 的能力。LBaaS 支持多种负载均衡产品和方案，不同的实现以 Plugin 的形式集成到 Neutron，目前默认的 Plugin 是 HAProxy。
7.5.4防火墙 Firewalling
Neutron 通过下面两种方式来保障 instance 和网络的安全性。
Security Group
通过 iptables 限制进出 instance 的网络包。
Firewall-as-a-Service
FWaaS，限制进出虚拟路由器的网络包，也是通过 iptables 实现。

7.5、Neutron 的架构

（1） plugin 解决的是 What的问题，即网络要配置成什么样子？而至于如何配 置 How 的工作则交由 agent 完成。
（2） plugin，agent 和 network provider 是配套使用的，比如上例中 network provider 是 linux bridge，那么就得使用linux bridge 的 plungin 和 agent； 如果 network provider 换成了 OVS 或者物理交换机，plugin 和 agent 也得替换。
（3） plugin 的一个主要的职责是在数据库中维护 Neutron 网络的状态信息， 这就造成一个问题：所有 network provider 的 plugin 都要编写一套非常类 似的数据库访问代码。为了解决这个问题，Neutron 在 Havana 版本实现 了一个 ML2（Modular Layer 2）plugin，对 plgin 的功能进行抽象和封装。 有了 ML2 plugin，各种 network provider 无需开发自己的 plugin，只需要 针对 ML2 开发相应的 driver 就可以了，工作量和难度都大大减少。ML2 会在后面详细讨论。
（4） plugin 按照功能分为两类： core plugin 和 service plugin。core plugin 维 护 Neutron 的 netowrk, subnet 和 port 相关资源的信息，与 core plugin 对 应的 agent 包括 linux bridge, OVS 等； service plugin 提供 routing, firewall, load balance 等服务，也有相应的 agent。后面也会分别详细讨论。

8、Dashboard
8.1、什么是Django?
1.1 Django是一个基于Python的高效的Web开发框架，它提供了通用的Web开发模式的高度抽象；目的是为了可以简便的、快速的开发数据库驱动的网站，强调代码的复用，多个组件可以很方便的以“插件”的形式存在于整个框架中。

1.2 组成部分
1）. 对象关系映射：以python类的形式定义数据模型，将模型和关系数据库连接起来，将得到一个易使用的数据库API；
2）. URL分派：使用正则式匹配URL，可以任意设计URL；
3）. 模版系统：使用django强大的可扩展的模版语言，可以设计分隔设计内容和Python代码，应具有可继承性；
4）．表单处理：可以方便的生成表单类型，实现表单的饿有效性检验；
5）. Cachece系统：可以挂在内存缓存或其他的框架实现超级缓冲
6）. 会话：用户登录与权限检查
7）. 国际化：开发多种语言的网站；
8）．自动的管理界面：自带ADMIN site；
1.3 文件组成
Django是基于MVC设计实现的，主要包含四类文件：
1）. Models：主要用Python类；来描述数据表。可以使用简单的Python代码来创建、检索、更新、删除数据库中的记录；
2）. Views：包含页面的业务逻辑；
3）. Urls：指出了什么样的URL调用什么样的视图；
4）. Templates：HTML模板，描述了这个页面是怎么样设计的，在模板里面可以使用带基本逻辑声明的模板语言，如{%for user in user list%}；
8.2、horizon简述：
Horizon 为 Openstack 提供一个 WEB 前端的管理界面 (UI 服务 )通过 Horizone 所提供的 DashBoard 服务 , 管理员可以使用通过 WEB UI 对 Openstack 整体云环境进行管理 , 并可直观看到各种操作结果与运行状态。
(代号为“Horizon”) 为所有OpenStack的服务提供了一个模块化的web-based用户界面。使用这个Web GUI，可以在云上完成大多数的操作，如启动实例，分配IP地址，设置访问控制等
Horizon为两种用户提供了两种不同的功能界面：

1. 云管理员：提供了一个整体的视图可以总览整个云的资源大小及运行状况，可以创建终端用户和项目，向终端用户分配项目并进行项目的资源配额管理；
2. 终端用户：提供了一个自主服务的门户，可以在管理员分配的项目中，在不超过额定配额的限制内，自由操作、使用和 存储网络资源；

Demo用户的界面

图8-1

Admin用户的界面

图8-2

8.3、horizon架构：
Horizon主要由三个dashboard组成：用户dashboard、系统dashboard和设置dashboard。

用户dashboard界面

图8-3

系统dashboard

图8-4

设置dashboard

图8-5

9、学习open stack的感触：

通过一学期的努力学习终于完成了open stack的组件安装，对于刚开始学习新东西的我感到十分好奇，却也不乏困难重重，每一个组件都得细致入微的解决。首先我觉得这次成功的主要因素便是细心，和上课认真听讲。

这学期的任务比较繁重，的确是偷懒，成功的成为了老师口中的文档搬运工。在粘贴复制的过程中的确是没有学到任何有用的知识，还好老师要求做学习笔记，刚刚开学前几个周的学习，就只是简单的学习到了如何装虚拟机，还记得上课老师给的第一个问题为什么刚开始要输入net.ifnmes=0 biosdevname=0? 第一次学习Linux系统的我也很不解，经过度娘和不断地探索终于发现：按Tab键再按一个空格输入下面的命令,开始检查并安装系统。net.ifnames=0 biosdevname=0如果不写上面的命令安装,那么网卡会变成CentOS7默认的名字ens33或者ens34开头了,不会再有eth0这类型的名称了。而我们后期正是用的eth0这种类型的。Linux基础安装的最重要的就是外网的连通，看着别人外网给都能够连通，而我一直卡住不动检查了网卡配置和DNS解析也没有任何problem。百度也没有任何结果，最终在同学的提醒下在计算机的服务中启开了VMware Workstation Server 、VMware DHCP Service 和VMware NAT Service，然后才成功的连接到了外网。Open stack的基础安装是rocky版的，而我安的ocata版的确是没有好好听老师讲课得到的后果。经过艰难努力终于完成了虚拟机的基础环境安装。

MySQL的安装与配置也是至关重要的，而我在设置密码的时候并没有按照老师说的密码为mysql，给后面的组件安装带来了不少的麻烦。总之到这儿还一切顺利吧。RabbitMQ的安装与配置中成功的完成了RabbitMQ的验证，Openstack的认证服务——keystone中同步数据库，还有配置Apache HTTP Server稍有不细心就要导致恢复快照，对于我来说出现的问题很多1、配置HTTP下的keystone文件粘贴复制老师的文档直接少了Listen 5000的前两个字母：2、chown keystone:keystone policy.json的权限忘记修改；3、/var/log/keystone/keystone.log的权限是keystone；现在回头看都是些可笑的小问题，粗细加浮躁导致default域都创建不成功。南啊，花了半晚上重做。Openstack的镜像服务——Glance 在这个组件中无疑是吃了大亏，一个首字母大写的Glance，使我们从头再来。数据库建表开始，修改一个个glance为了能上传镜像， 一切以为没啥问题的会成功的，结果遇到了第二个粗心，在配置 [keystone_authtoken] ，过程中以为找到了auth_uri 就可以了，结果空表一直出不来，验证一直不能通过。我还以为是Glance又粗心写错了，不下十次的快照让我终于明白Glance没错，一定是哪里配置错了。让室友帮我做了一边结过还是出不来，最终换了个文档终于做出来了。皇天不负有心人，努力的人还是有好运气的，我的做完后还帮助了很多有这样问题的同学，他们都是找错行数，以为相似就粘贴上，结果这儿真的是有大学问的。镜像上传成功后，我变得越加谨慎，不敢丝毫马虎。OPENSTACK的计算服务——NOVA组件中几乎没有出现任何差池，完美收工，着实让别人羡慕。掌握好控制节点和计算节点，在两台机子上细心配置，肯定不会出错。利用这段时间查找关于openstack相关的知识，查漏补缺，包括在云计算课本，都看见了openstack 的身影。完成nova的配置，确认好了机器是否支持CPU的虚拟加速，验证成功。Neutron的安装，在细心的基础上，配置好节点，按照官方文档对比最后解决了老师设置的小陷阱。而且配置网络的时候一定要输对以前所设置的密码，不然又得卷土从来。

一学期的努力终于见到了可视化的界面，付出没有白费，这不是终点，open stack功能强大，这才是搭建完成，后期的学习使用才是我们真正的开始，加油努力，在这条路上继续开始探索吧！