学习目的
熟悉OpenStack框架，作为云安全的基础
学习程度
熟悉框架，重点学习网络、认证和计算模块
初识OpenStack
（1）OpenStack是一个云操作系统，可以控制整个数据中心的大型计算、存储和网络资源池，所有这些操作都通过控制台进行管理，该管理器可让管理员进行控制，同时允许用户通过Web界面供应资源。
（2）OpenStack是开源的，由开源社区公开设计和开发。
（3）Openstack是开发人员和云计算技术专家全球协作，为公有云和私有云提供的无所不在的开源云计算平台。该项目旨在通过易于实施，大规模扩展和功能丰富来为所有类型的云提供解决方案。该技术由一系列相关项目组成，为云基础设施解决方案提供各种组件。
（4）有一系列的软件工具，用于构建和管理公有/私有云计算平台，背后有基金会和一系列大公司支撑。使得用户可以很快的部署、管理虚拟机资源，提供云计算服务。
（5）openstack通过网络将用户和网络背后丰富的硬件资源分离开。1.管理和控制硬件资源（Hypervisor）；2.为用户提供虚拟机；
（6）跟阿里云、AWS、Azure等Iaas平台类似。
OpenStack的基本设计原则
- 1.可扩展性和伸缩性是我们的主要目标
- 2.任何影响到可扩展性和伸缩性的功能都必须是可选的
- 3.一切都应该是异步的，如果不能异步实现，请参考第2条设计原则
- 4.所有的基础组件必须能横向扩展
- 5.始终使用无共享架构，如果您不能，请参考第2条设计原则。
- 6.所有都是分布式的，尤其是逻辑。把逻辑放在状态应该存在的地方。
- 7.接受最终的一致性，并在适当的条件下使用。
- 8.充足的测试，提交的代码都需要测试。
OpenStack的组成/架构
主要组成部分：
- Identity(Keystone) 认证
- Compute(Nova) 计算
- Image service(Glance) 镜像服务
- Networking(Neutron) 网络
- Object Storage(Swift) 对象存储
- Block Storage(Cinder) 块存储
- Dashboard(Horizon) 控制台
- Telemetry(Ceilometer) 计量和监控
- 等一系列服务
下图是OpenStack极简结构图
可以看出，OpenStack主要管理三大核心资源：计算、网络和存储。
image.png
下图是OpenStack简化架构图
图中的VM是虚拟机，围绕VM的长方形是OpenStack的不同服务
image.png
下面分别介绍：
Nova：管理VM的生命周期，是OpenStack中最核心的服务。（核心服务）
Neutron：为OpenStack提供网络连接服务，负责创建和管理L2、L3网络，为VM提供虚拟网络和物理网络连接。（核心服务）
Glance：管理VM的启动镜像，Nova创建VM时将使用Glance提供的镜像。（核心服务）
Cinder：为VM提供块存储服务。Cinder提供的每一个Volume在VM看来就是一块虚拟硬盘，一般用作数据盘。（核心服务）
Swift：提供对象存储服务。VM可以通过RESTful API存放对象数据。作为可选方案，Glance可将镜像存放在Swift中，Cinder也可将Volume备份到Swift中。（可选服务）
Keystone：为OpenStack的各种服务提供认证和权限管理服务。简单的说，OpenStack上的每一个操作都必须通过Keystone的审核。（核心服务）
Ceilometer：提供OpenStack监控和计量服务，为报警、统计或计费提供数据。（可选服务）
Horizon：为OpenStack用户提供一个Web的自服务Portal。（刚开始是核心服务，后来变为可选）
下图是OpenStack逻辑架构图
image.png
可以看出，各个服务是由更小的组件组成的。在实际的部署方案上，各个组件可以部署到不同的物理节点上。OpenStack本身是一个分布式系统，不但各个服务可以分布部署，服务中的组件也可以分布部署。这种分布式特性让OpenStack具备极大的灵活性、伸缩性和高可用性。
当然从另一个角度讲，这也使得OpenStack比一般系统复杂，学习难度也更大。
下面对各个服务的组件做下说明
（1）compute（Nova）
提供虚拟机服务，比如创建、热迁移等。
nova-api 被用户调用
nova-compute 安装在物理机上的服务进程
nova-scheduler 负责调度创建虚拟机
nova-conductor 处于compute和db之间的中间件（安全性）
nova-db 数据库
nova-console/nova-consule 提供虚拟机控制台服务
nova-cert x509严重管理服务（CA）
nova-objectstore 在glance中注册镜像的接口服务
（2）Object Storage（Swift）
存储检索对象/文件，以低成本方式通过RESTful API管理大量无结构数据。
proxy-server 分发/接收请求
account-server 账号管理
container-server 容器/文件夹的映射关系
object-server 管理存储节点上的实际对象/文件
（3）Identity（Keystone）
为所有服务提供身份验证、授权、跟踪用户以及用户权限，提供可用服务以及API的列表。
keystone-api
keystone-db
（4）Dashboard（Horizon）
为所有服务提供模块化的基于Django的界面
（5）Block Storage（Cinder）
提供块存储服务，volume
cinder-api 接收外部的API请求，并将请求交给cinder-volume执行
cinder-volume 负责与底层的块存储服务交互（中间件），实际的操作由volumeprovider完成
cinder-db 用于记录和维护块设备的信息
cinder-scheduler 调度+策略，寻找最佳创建volume的节点
（6）Network（Neutron）
提供网络连接服务，允许用户创建自己的虚拟网络并连接各种网络设备接口。
通过插件（plugin）方式对众多的网络设备提供商进行支持，比如Cisco、Juniper等，同时也支持很多流行的技术，比如Openvswitch、OpenDaylight和SDN等。
neutron-server 接收外部API请求，并交给合适的neutron插件处理
neutron-agent 代理
neutron-provider 驱动（适配器）
neutron-plugin 插件
neutron-db 数据库
（7）Image Service（Glance）
镜像服务组件，提供虚拟机镜像的存储、查询和检索服务。通过提供一个虚拟磁盘将新的目录和数据库，为Nova的虚拟机提供镜像服务。
glance-api 接收外部API请求，包括镜像发现、获取和存储
glance-registry 用于存储、处理和获取镜像元数据
glance-db 存储镜像元数据
通过创建虚拟机的例子，来看上述核心组件如何相互配合：
1.用户通过界面（Horizon）发起创建虚拟机的请求，发送到OpenStack的后端
2.nova从glance获取镜像，glance从swift中得到镜像交给nova
3.nova从cinder得到volume
4.nova从neutron得到网络服务
5.创建虚拟机
6.用户通过keystone认证之后访问到新建的虚拟机资源
开发基础
1.资源：社区、文档（docs.openstack.org）、源码、书籍
2.基础：Python、Linux环境编程、网络基础、虚拟化、Git
3.开发环境：Git、devstack
虚拟化
云计算的一个核心思想就是在服务端提供集中的物理计算资源。这些资源可被分解成更小的单位去独立地服务于不同的用户，也就是在共享物理资源的同时，为每个用户提供隔离、安全、可信的虚拟工作环境，而这一切不可避免地要依赖于虚拟化技术。
“远古”：虚拟内存、虚拟服务器（Time-sharing）。
核心就是提供抽象层。
标准的计算机系统层次结构
image.png
每个层次都向上一层呈现一个抽象，并且每一层只需要知道下一层抽象的接口，而不需要了解其内部运作机制。
这样抽象的好处是，每一层只需要考虑本层的设计以及与相邻层间的交互接口，从而大大降低了系统设计的复杂性，提高了软件的移植性。从另一个方面来说，这样的设计也给下一层软件模块为上一层软件模块创建“虚拟世界”提供了条件。
本质上，虚拟化就是由位于下层的软件模块，根据上一层软件模块的期待，抽象出一个虚拟的软件或硬件接口，使上一层软件可以直接运行在与自己所期待的运行环境完全一致的虚拟环境上。
对云计算而言，特别是提供基础架构即服务的云计算，更关心的是硬件抽象层上的虚拟化。因为，只有把物理计算机系统虚拟化为多台虚拟计算机系统，通过网络将这些虚拟计算机系统互联互通，才能够形成现代意义上的基础架构，即服务云计算系统。
系统虚拟化
image.png
硬件抽象层上的虚拟化是指通过虚拟硬件抽象层来实现虚拟机，为客户机操作系统呈现出与物理硬件相同或相近的硬件抽象层。由于客户机操作系统所能看到的只有硬件抽象层，因此客户机操作系统的行为和其在物理平台上没有什么区别。
这种硬件抽象层上的虚拟化又被称为系统虚拟化，是指将一台物理计算机系统虚拟化为一台或多台虚拟计算机系统。每个虚拟计算机系统（简称为虚拟机，也就是上面所称的客户机）都拥有自己的虚拟硬件，如CPU、内存和设备等，并提供一个独立的虚拟机执行环境。通过虚拟机监控器（VirtualMachineMonitor，VMM，也可以称为Hypervisor）的模拟，虚拟机中的操作系统（GuestOS，客户机操作系统）认为自己仍然是独占一个系统在运行。在一台物理计算机上运行的每个虚拟机中的操作系统都是可以完全不同的，并且它们的执行环境是完全独立的。
虚拟机的实现方式
1.完全虚拟化
VMM直接运行在硬件平台上，控制所有的硬件并管理客户操作系统。
2.类虚拟化
VMM运行在一个传统的操作系统里（第一软件层），VMM是第二软件层，而客户机操作系统是第三软件层。KVM和VirtualBox是这一种方式。
image.png
上图中TYPE1是完全虚拟化，可以看出，对于每个OS，都基于同一个硬件抽象层；TYPE2是类虚拟化，最上面的OS的硬件抽象层是基于中间OS而建立的。
虚拟化的核心技术
CPU虚拟化
内存虚拟化
I /O虚拟化
网络虚拟化
GPU虚拟化
与虚拟化联系最紧密的是Nova，Nova是虚拟化管理工具，负责管理虚拟机。Nova提供了一个Virt Driver的框架支持各种的虚拟化实现。
LIbvirt提供通用、稳定的抽象层来安全地管理一个节点上的虚拟机。
OpenStack通用技术
有句话叫Don't Revinvent the Wheel！软件开发讲究不要重复造轮子，尽量使用现有的轮子，做更多有价值的东西。
计算机的体系结构演变为：硬件、操作系统、数据库管理系统和应用程序。
OpenStack使用了大量开发框架作为通用库，下面是OpenStack通用库，以及各个项目使用到的大量其他技术和第三方库的介绍。
1.消息总线
在OpenStack中，项目之间通过RESTful API进行通信；项目内部，不同服务进程之间的通信，必须通过消息总线。这种设计思想保证了各个项目对外提供服务的接口可以被不同类型的客户端高效支持，同时也保证了项目内部通信接口的可扩展性和可靠性，以支持大规模的部署。
软件从最早的面向过程、面向对象，再到面向服务，要求我们去考虑各个服务之间如何去传递消息。借鉴硬件总线的概念，消息总线的模式被引入，顾名思义，一些服务向总线发送消息，其他服务从总线上获取消息。oslo.messaging库通过以下两种方式来完成项目内部各服务进程之间的通信。
（1）远程过程调用（Remote Procedure Call，RPC）
通过RPC，A服务进程可以调用B服务进程的方法，有两种调用方式：call和cast。
call 同步，阻塞等待结果返回
cast 异步，不阻塞，需要另发请求获取结果
可使用RabbitMQ实现
（2）事件通知（Event Notification）
某个服务把事件通知发送到消息总线上，该消息总线上所有对此类事件感兴趣的服务进程，都可以获得此事件通知并进行进一步的处理，处理的结果并不返回给事件发送者。（Ceilometer通过这种方式大量获取其他项目的事件通知，从而进行计量和监控）
可使用Kafka实现
2.SQLAlchemy和数据库
SQLAlchemy提供SQL工具包以及对象关系映射器（Object Relational Mapper，ORM），这样SQLAlchemy能让Python开发人员简单灵活地运用SQL操作后台数据库。
SQLAlchemy主要分为两部分：SQLAlchemy Core和SQLAlchemy ORM。SQLAlchemyCore包括SQL语言表达式、数据引擎、连接池等，所有这一切的实现，都是为了连接不同类型的后台数据库、提交查询和更新SQL请求去后台执行、定义数据库数据类型和定义Schema等目的。SQLAlchemyORM提供数据映射模式，即把程序语言的对象数据映射成数据库中的关系数据，或把关系数据映射成对象数据。架构图如下：
image.png
3.RESTful API和WSGI
（1）RESTful API
REST Representational State Transfer表述性状态转移
核心概念是“资源”，使用HTTP的GET、POST、PUT、DELETE使服务端的“资源”发生“状态转化”。
（2）WSGI（web server gateway interface）
RESTful只是设计风格不是标准，Web服务中通常使用基于HTTP的符合RESTful风格的API。而WSGI则是Python语言中所定义的Web服务器和Web应用程序或框架之间的通用接口标准。
WSGI是一个网关，作用是在协议之间进行转换。
WSGI是一座桥梁，桥梁的一端是服务端或者网关端，另一端是应用端或者框架段。当处理一个WSGI请求时，服务端为应用端提供上下文信息和一个回调函数，应用端处理完请求后，使用服务端所提供的回调函数返回相对应请求的相应。
作为一个桥梁，WSGI将Web组件分成了3类：Web服务器（WSGIServer）、Web中间件（WSGIMiddleware）与Web应用程序（WSGIApplication）。WSGIServer接收HTTP请求，封装一系列环境变量，按照WSGI接口标准调用注册的WSGIApplication，最后将响应返回给客户端。
4.Eventlet
OpenStack大部分项目都采用协程（coroutine）模型。
协程跟线程类似，也是一个执行序列，拥有自己独立的栈和局部变量，同时又于其他协程共享全局变量。协程与线程的主要区别是，多个线程可以同时运行，而同一个时间内只有一个协程在运行，无需考虑很多锁的问题，因此开发和调试也简单方便。
线程的执行完成由操作系统控制，而协程的执行顺序与时间完全由程序自己决定。
支持协程的Python库：Eventlet、AsyncIO
5.OpenStack通用库Oslo
（1）Cliff 构建命令行程序
（2）olso.config 用于解析命令行和配置文件中的配置选项
（3）oslo.db 对SQLAlchemy访问的抽象
（4）oslo.i18n 对Python gettext模块的封装，主要用于字符串的翻译和国际化
（5）oslo.messaging 为OpenStack各个项目使用RPC和事件通知提供一套统一接口
（6）stevedore 动态载入代码
（7）taskflow 控制任务的执行
（8）cookiecutter 开发用
（9）oslo.policy 控制用户的权限
（10）oslo.rootwarp 让其他服务以root身份执行shell命令
（11）oslo.test 提供单元测试的基础框架
（12）oslo.versionedobjects 版本控制
计算
Nova专注于提供统一的计算资源抽象（可以是物理机、虚拟机、容器）
1.体系结构
下面是Nova服务的体系结构
image.png
Nova服务创建虚拟机的工作流程如下
（1）novaclient发起创建虚拟机的命令给API
（2）API将请求转换为AMQP消息，通过消息队列调用Conductor
（3）Conductor接收服务后，做一些准备工作，再通过消息队列告诉Scheduler，Scheduler选择一个满足虚拟机创建要求的主机
（4）Conductor拿到Scheduler提供的目标主机后，要求Compute服务创建虚拟机
注意：短时服务删除虚拟机操作不需要Scheduler服务，API通过消息队列直接告诉Compute删除虚拟机。
2.Nova Api
作为客户端和Nova之间的中间层/中间人
有多个版本：V1、V2、V2.1
基于WSGI实现，负责将请求路由到对应的处理函数
3.Rolling Upgrade
之前都是offline升级，导致downtime时间过长，后来逐渐改为分布升级，最后做到Rolling Upgrade（滚动升级），Zero downtime（最终目标）。滚动升级的过程中，除了重启管理节点时会发生短暂的downtime，其他部分都可以通过技术手段不产生downtime。
更新步骤：
（1）更新代码（内存中仍运行旧代码）
（2）升级旧数据库（数据库schema向后做兼容）
（3）重启管理节点（用SIG_TERM信号，友好方式）（唯一会downtime处）
（4）滚动升级计算节点，同时友好的中止服务进程。
（5）计算节点完成后，发送SIG_HUP给服务进程使其开始使用新的RPC接口
（6）运行数据库线升级
实现技术：
（1）RPCVersioning
保证各组件可以在不同版本上工作，兼容
（2）VersionedObject
数据库版本化，可兼容
（3）Conductor
a.连接nova-api、nova-compute和nova-scheduler，提供长时任务编排功能
b.为nova-compute提供数据库的代理访问控制
c.提供版本兼容功能
4.Scheduler
决定虚拟机的生存空间和资源分配，通过各种规则，包括内存使用率、cpu负载等，为虚拟机选择一个合适的主机。
（1）调度器
用于挑选最佳节点
a.调度器缓存更新（主机情况缓存）
b.Filtering 过滤
c.Weighting 权重
（2）Resource Tracker
Resource Tracker的claim机制，在创建虚拟机之前预先测试一下主机的资源是否充足，如果满则，则更新数据库中ComputerNode记录。
另外，更新ComputeNode的还有一个Periodic Task服务，负责周期性更新。
（3）调度流程
image.png
5.典型工作流程
创建虚拟机
创建虚拟机过程如下图所示
image.png
1.nova-api监听到创建虚拟机的HTTP请求，然后通过RPC cast调用告知nova-conductor去构建实例
2.nova-conductor会整理请求信息，然后再通过RPC call调用nova-scheduler去选择一个最佳的主机
3.然后nova-conductor将所有信息通过RPC cast调用nova-compute创建虚拟机
4.nova-compute在创建虚拟机之前，首先会使用Resource Tracker的Claim机制去检测主机的可用资源是否足够，然后通过具体的Virt Driver创建虚拟机
冷/热迁移与Resize
操作：将虚拟机从A计算节点转移到B计算节点
冷迁移指的是虚拟机关机情况下执行上述操作，热迁移是指虚拟机运行状态下执行上述操作。
Resize是根据需求调整虚拟机的计算能力和资源，和冷迁移的工作流程相同。
挂起和恢复
从Hypervisor角度来说，有两种挂起和恢复虚拟机的方式，挂起是Suspend和Pause，对于的恢复是Resume和Unpause。
区别就是：
Suspend会通知虚拟机，虚拟机从内部进行挂起的动作，Resume也是虚拟机主动恢复。
Pause和Unpause时，虚拟机是被动的，Hypervisor直接从CPU调度方面挂起虚拟机，虚拟机本身感知不到。
rebuild（重建）和evacuate（高可用）
rebuild是虚拟机的重建，可以理解为系统的重装或更换系统。
evacuate可以理解为OpenStack HA的基础技术，保证系统的高可用。
存储
存储包括两部分，对象存储（swift）和块存储（Cinder）。
Swift
体系结构
对象存储，存储静态的、更新频率低的数据，比如镜像、数据备份等，如果需要实时更新数据，选择Cinder。
存储的逻辑单元是对象，不是文件。传统上，文件由两部分构成：文件本身以及相关的元数据。Swift中的对象包含了内容与元数据两部分。
image.png
优点：a.高的数据持久性；b.安全对称的系统架构；c.无限的可扩展性；
与Glance相结合，为其存储镜像文件，与Cinder结合，为其做Volume备份。
Ring
用来实现对物理节点的管理，包括记录对象与物理存储位置间的映射、物理节点的添加和删除等。
Swift API
功能：存储对象、压缩、删除（可批量）
认证
对请求做认证（外部认证通过keystone、内部认证通过Tempauth）
image.png
对象管理与操作
Swift通过Account、Container、Object 3个层次进行对象的组织与管理，对象最终以二进制文件形式存储，需要对这些对象进行描述，并将抽象的对象跟实际的文件联系起来。
数据一致性
Cinder
由nova-volume独立产生，为VM提供持久化存储，实现VM Volume的创建、挂载、卸载、快照等。
Cinder在VM和具体存储设备之间引入了一层“逻辑存储卷”的抽象，它提供的RESTful API主要针对逻辑存储卷的管理。
image.png
cinder-api 接收外部RESTful请求
cinder-volume 运行在存储节点上，管理具体存储设备的存储空间，每个存储节点上运行一个，多个构成一个存储资源池。
cinder-scheduler 根据预定的策略，调度选择何时的volume节点
cinder-backup 提供存储卷的备份功能
Glance
体系结构
提供镜像服务，与Swift、Cinder并列存储相关三驾马车，不负责实际的存储，默认存在Swift中。功能单一，只完成一些镜像的管理工作。
image.png
API
提供镜像管理功能，如Image导入/导出，镜像元数据的管理等。
Ceph
一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式的存储系统。
统一性：可同时提供对象存储、块存储和文件系统存储
分布式：无中心架构，系统规模没有理论上的上限
网络
Neutron，由nova-network独立产生，为了
- 更为丰富的拓扑结构
- 支持更多的网络类型
- 更好的扩展性
体系结构
类似于各个计算节点在Nova中被泛化为计算资源池，OpenStack所在的整个物理网络在Neutron中也被泛化为网络资源池，通过对物理网络资源的灵活划分与管理，Neutron能够为同一物理网络上的每个项目提供独立的虚拟网络环境。
使用Neutron构建私有网络的过程，就是创建各种Neutron资源对象并进行连接的过程，完全类似于使用真实的物理网络设备来规划自己的网络环境。
image.png
Router对应真实网络中的路由器（路由/NAT）
network对应一个二层局域网（LAN）
subnet属于网络中的3层，指定一段IPv4或IPv6b并描述其相关的配置，它附加在一个二层Network上，指明属于这个network的虚拟机的可用IP地址范围。
Linux虚拟网络
Neturon最核心的工作是对二层物理网络network的抽象和管理
下图是传统二层物理网络，物理网卡连接物理交换机。
image.png
下图是虚拟网络结构，包含虚拟网络层、虚拟网卡、虚拟交换机。
image.png
（1）TAP/TUN/VETH
TAP/TUN是linux内核实现的一堆虚拟网络，TAP工作在二层，TUN工作在三层，Linux内核通过TAP/TUN设备向绑定该设备的用户空间程序发送数据，反之，用户空间程序也可以像操作硬件网络设备那样，通过TAP/TUN设备发送数据。
基于TAP驱动，实现虚拟网卡功能，每个vNIC都与Hypervisor中的一个TAP设备相连。
VETH设备总是成对出现，送到一端的请求发送的数据总是从另一端以请求接受的形式出现。
（2）Linux Bridge
网桥，L2层，虚拟网络，类似物理交换机，可桥接其他设备，这些设备都在同一个网段内。
下图是Linux Bridge结构：
image.png
（3）Open vSwitch
虚拟交换机
A.负责连接vNIC与物理网卡，同时桥接一物理Service内的所有vNIC
B.为什么Linux Bridge已经可桥接，还要Open vSwitch?因为虚拟机情况下无法区分，需要Open vSwitch来区分是哪个VM，哪个OS，哪个用户
C.实现了分布式虚拟交换机
image.png
网络抽象
L2的抽象 router 提供路由功能
L3的抽象 network/subnet 完成对二层物理网络的映射
L2层的抽象会映射到真正的物理网络
架构
Neutron只有一个主要的服务进程neutron-server，它运行于网络控制节点上，提供RESTfulAPI作为访问Neutron的入口，neutron-server接收到的用户HTTP请求最终由遍布于计算节点和网络节点上的各种Agent来完成。
API资源有：L2的抽象network/subnet/port（核心）、L3的router和众多高层次服务（扩展）
为了扩展性，利用Plugin方式组织代码，每个plugin有一组API，这些操作由Plugin通过RPC调用对应的Agent来完成。
Core plugin 处于L2 至少实现L2的三个抽象
Service plugin 其他的，比如L3的Router service plugin
Agent一般专属于某个功能，用于使用物理网络设备或一些虚拟化技术完成某些实际的操作。比如实现router具体操作的L3Agent。
ML2框架，移除各厂商的Plugin及SDN，独立维护，为了减少重复代码，H版之后实现了ML2 core plugin，意在取代所有core plugin
image.png
Neutron API
Core API ，核心资源，包含L2层的network/subnet/port 3种抽象
Extension API，扩展资源，包含其余层的抽象
Neutron Server
唯一的服务进程，接收用户的RESTful API请求并分发处理
使用协程
ML2 Plugin
目的是取代所有的Core Plugin，实现了network/subnet/port
ML2解耦了网络拓扑类型与底层的虚拟网络实现机制，并分别通过Driver的形式进行扩展，其中，不同的网络拓扑类型对应着TypeDriver，由TypeManager管理，不同的网络实现机制对应着MechanismDriver，由MechanismManager管理。
image.png
Port Binding扩展
Extension API有两种方式扩展现有资源
（1）为network/port/subnet增加属性（比如Port Binding）
（2）增加一些新资源，比如VPNasS
Open vSwitch Agent
ML2Plugin的主要工作是管理虚拟网络资源，保证数据正确无误，具体物理设备的设置则由Agent完成。
基于Plugin提供的信息，OVSAgent负责在计算节点或者网络节点上，通过对OVS虚拟交换机的管理将一个network映射到物理网络。
Service Plugin
（1）Firewall
FWaas给VM提供虚拟防火墙，定义的数据模型有三个：firewall、policy和rule。租户可以创建firewall，每个firewall关联一组policy，而policy是rule的有序列表。
（2）LoadBalance
LBaas提供在VM Instance之间做负载均衡的能力。
将网络流量负载均衡到各个VM
在不同协议（TCP/HTTP）之间做LB
监控应用和服务状态
链接限制
Session persistence
使用LB Plugin配置负载均衡
1.创建LB，并创建一个LB listener跟它关联
2.为计算池添加几个成员
3.创建health monitor
SDN
software define network，软件定义网络.
SDN致力于实现一个ControlPlane（控制平面）和DataPlane（数据平面）分离的网络架构，并使之标准化。
可以这样简述SDN，在现有设备中配备OpenFlow规范的接口软件，随后一个集中的控制器就可以操作所有这些设备，并通过API呈现一个统一接口的网络接口给App。
SDN的本质是把网络软件化，提高网络可编程能力和易修改性。SDN没有改变网络的功能，而是重构了网络的架构。
image.png
安全
概述
云安全需要考虑：
（1）数据安全
保护云用户的数据不被窃取或丢失。强加密及秘钥管理是保护数据的核心机制。秘钥管理提供了对资源的访问控制。
keystone中使用令牌机制来管理用户对资源的访问，并引入PKI对令牌加以保护。
（2）身份与访问管理安全（必不可少）
需要合理定义内部管理员的控制边界。
keystone使用policy（访问规则）来做到基于用户角色的访问控制。
（3）虚拟化安全
虚拟化，需隔离各个虚拟机
（4）基础设施安全
包括服务器、存储、网络等核心IT基础设施的安全
服务器层：强认证、安全事件日志、入侵检测、防御系统
网络层：传输数据加密
可信计算池：intel硬件保证
Keystone
Keystone是openstack中的一个独立的提供安全认证的模块，主要负责用户的身份认证、令牌管理、提供访问资源的服务目录，以及基于用户角色的访问控制。
keystone的作用类似一个服务总线，其他服务通过keystone来注册其服务的Endpoint（服务的访问点），针对这些服务的任何调用都需要经过keystone的身份认证，并获得服务的Endpoint进行访问。
体系结构
- Domain：域，keystone中的一个虚拟概念，是一组User、Group或Project的容器，必须全局唯一。
- User：用户，通过keystone访问OpenStack服务的个人、系统或某个服务，keystone会通过认证信息验证用户请求的合法性，通过验证的用户将会分配到一个特定的令牌，该令牌可以用作后续资源访问的一个通行证，非全局唯一，只要域内唯一。
- Group：用户组，一组Users的容器，可以向Group中添加用户，并直接给Group分配角色。（类似linux的用户、组）
- Project：项目，是各个服务中的一些可访问的资源集合。
- Role：角色，一个用户所具有的角色，角色不同意味着被赋予的权限不同。
- Service：服务，比如Nova、Swift、Glance、Cinder等。根据User、Tenant和Role，一个服务可以确认当前用户是否具有访问其资源的权限。服务对外暴露一个或者多个端点（Endpoint），用户只有通过这些端点才可以访问所需资源或者执行某些操作。
- Endpoint：端点，指一个可以用来访问某个具体服务的网络地址。如果需要访问一个服务，就必须知道它的Endpoint。URL细分为Public、Internal和Admin 3种。
- Token：令牌，是允许访问特定资源的凭证。通过Credentials获得。
- Credentials：凭证，用户的用户名和密码。
image.png
Keystone主要提供了Authentication（认证）、Token（令牌）、Catalog（目录）和Policy（安全策略/访问控制）4个方面的核心服务。
- Authentication：对用户身份进行验证
- Token：令牌
- Catalog：提供服务的查询列表（可访问列表）
- Policy：一个基于规则的身份验证引擎
keystone工作流程：
用户从keystone获取令牌以及服务列表
用户访问服务时发送自己的令牌
相关的服务向keystone求证令牌的合法性
keystone架构
image.png
keystone认证过程
1.keystone使用私钥对用户元数据进行签名，生成令牌
2.每个服务端会保存一份签名公钥证书、CA公钥证书和证书吊销列表，在本地对令牌进行校验。
计量与监控
Telemetry包含子项目：
- Aodh：根据已保存的使用数据进行报警。
- Ceilometer：提供一个获取和保存各类使用数据的统一框架。（核心）
- Gnocchi：用来保存基于时间序的数据，并对其提供索引服务。
- Panko：用来保存事件Event信息。
物理机管理
物理机的应用方式：
- 高性能计算
- 有些物理设备无法虚拟化
- 数据库应用
- 裸机托管
- 云环境的部署
使用OpenStack Ironic项目进行处理。
控制面板
Dashboard项目Horizon，核心价值：
- 核心支持 — 支持所有的OpenStack项目
- 可扩展性 — 每个开发者都能增加组件
- 易于管理 — 架构和代码易于管理，浏览方便
- 视图一致 — 各组件的界面和交互模式保持一致
- 可兼容性 — API向后兼容
- 易于使用 — 界面用户友好
体系结构
Horizon提供了一个模块化的基于Web的图形界面，用户可以通过浏览器使用Horizon提供的控制面板来访问和控制它们的计算、存储和网络资源，比如启动虚拟机实例、创建子网、分配IP地址、设置访问控制等。
采用Django架构，同时采用了各种前端技术。
Horizon和Django
Django遵循MVC设计模式
在Django App中，一般有4种文件，models.py（数据库），view.py（业务），url.py（url分发）以及html网页文件（前端开发）。
MVC 模型/视图/控制器 —>(框架自动处理C) MTV 模型/模板/视图（存取层/表现层/业务逻辑层）
Django的设计哲学：业务逻辑与表现逻辑分开。
视图向模板传入上下文（context），模板利用传入的上下文渲染网页。
Django遵循DRY原则，专注于代码的高度可重用。Horizon秉承了这种哲学，致力于可扩展、可重复利用。
Horizon网端布局
面板设计分三层：Dashboard、PanelGroup和Panel.
容器
容器技术
操作系统级虚拟化，与虚拟化技术相比，两者都提供了资源的隔离访问，但从原理上根本不同。
OpenStack与容器技术如何结合？
- 在OpenStack集群上部署和管理容器
- 通过容器集群部署和管理OpenStack服务
- 同时存在物理机上
部署
由于OpenStack有众多服务，每个服务又有众多组件，又有繁琐的配置选项，所以如何简化一直是热点问题。
主要的配置工具有：puppet、chef、ansible和salt。这里ansilbe和salt是python编写的，并且复杂性低，容易入门。
ansible，要求有一台安装了Ansible软件的机器作为管理节点，可以通过ssh访问到被管理的机器。
inventory：需要编辑inventory文件，告知Ansible需要管理哪些机器。
模块：Ansible对被管理机器所执行的操作都是由模块完成的，模块相当于Ansible的命令。
编排（Playbook）：复杂命令的执行需要用到ansible-playbook，格式是yaml。
2018.04.26
yaoel
参考
1.what-is-openstack
2.如何成为OpenStack工程师
3.OpenStack开源云计算平台
4.OpenStack设计与实现（第2版）
网友评论