OpenStack 入门3

OpenStack 的各组件的架构和功能

Nova 组件解析

负责虚拟机建立、管理和销毁、提供计算资源服务的 Nova；

经过 Nova 能够实现：

• 访问虚拟机
• 建立和启动虚拟机

Nova 是怎么运做的？除了图形界面和命令行以外，咱们还须要怎样去配置和使用 Nova？

1-1. Nova 的架构

Nova-console 和 Nova-consoleauth 这两个组件，主要是为了让用户可以经过 VNC 客户端或 SPICE 客户端来访问虚拟机的界面。推荐使用 SPICE 客户端，由于SPICE 客户端提供了不少高级的特性，比方说，对 USB 设备的支持，SPICE 还支持多屏显示等等功能，这些特性在桌面虚拟化环境中很是有用处，在桌面云环境中也很是有用，但使用 SPICE 就须要对 nova.conf 文件作一些修改，好比：

// nova.conf的修改：
[spice]
enabled = True [default] vnc_enabled = False

1-2. 虚拟机的调度机制

• 第一个方面：placement（放置）。 把虚拟机放在哪一个物理机上启动
• 第二个方面：migration（迁移）。 从哪一个物理机迁移到哪一个物理机上

Nova 有一个组件叫做调度器，Scheduler 直译过来就是调度器，它实际上只完成了 placement 的工做，migration 其实是由其它组件来协同完成的。

在 OpenStack 的上下文里，特指这个运行的 nova-compute 服务的机器才叫作宿主机。

1-3. Nova 对虚拟机的调度机制

经过修改 nova.conf 文件修改调度器的配置，nova 默认的这个调度器成为 filter scheduler，这种调度器分两步来决定虚拟机的位置。第一步先通过一些 filters，filters 的每一种都表明着一种限制条件，经过这些 filters 选出来一些可用的 host，做为第二步的输入；第二步是称重，其实是对宿主机进行排序。

下面举个例子进行说明，这里有一个很是经常使用的 filter 叫做 Ramfilter，Ram：设置超配比例。

[ Nova 对虚拟机的调度机制：]

（1）把全部的 filters 都用上：

scheduler_available_filters = nova.scheduler.filters.all_filters

（2）选择其中的一部分：

scheduler_default_filter = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter，ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter

（3）用 Python 实现本身的 filter，老师用 RamFilter 作的例子如图所示：

对虚拟机进行排序（称重 weighting）

两种选择：

• 但愿负载尽量均衡
• 但愿负载尽量集中，用尽量少的 host 来承载咱们的虚拟机，咱们使用的 host 就会比较少，那么运维的成本包括用电、制冷的费用都会比较低

Swift 组件解析

提供对象存储服务的分布式存储 Swift；

[ Swift 的特色：]

1. Swift 历史比较长
2. Swift 比较独立（和其余组件的耦合度比较低；不依赖于第三方的软件或设备，甚至不依赖于 Keystone 作用户的认证和受权；）
3. Swift 是作对象存储的（这里的对象存储就是指，采用 RESTful 接口，支持直接从互联网访问存储系统进行数据的读写。对象存储每每采用扁平的数据组织形式，在文件数量不少的状况下不至于出现明显的性能衰减，也就是咱们说对象存储的概念哦

OpenStack 其它的不少项目实现具体功能的时候每每须要依赖于第三方的软件或设备，好比说 Nova 启动虚拟机、管理虚拟机就必须经过一个第三方的 Hypervisor，还有 Cinder 提供块存储服务必须经过第三方的存储设备。Swift 就不一样了，Swift 能够从上面的 RESTful 接口把堆栈一直管到底，以致于管到最后把数据到底放在哪一个服务器的哪一个硬盘上均可以作到，整个是完整的存储系统，如今有专门基于 Swift 实现的存储系统例如 swiftstack；

swift 提供的对象存储 和 ceph这类分布式存储

[ Swift 数据的组织形式：]

扁平的组织形式，Swift 的数据组织形式分为三级，只有这三级

• Account
• Container
• Object

与能够分 N 多层可以不断有文件夹的建立的数据组织形式不同，Swift 的整个存储结构从逻辑上划分为一个个的 Account，而后每一个 Account 底下再分为一个个的 Container，每一个 Object 其实是放在每一个 Container 底下的。

[ Swift 的接口：]

与 OpenStack 的其它组件的接口很相似，也是 RESTful Web API，总共有四个部分组成。第一个是 HTTP 操做（GET/PUT/DELETE/POST）；第二个是认证信息（主要是身份信息）；第三个是指示资源地址的 URL（具体到 Swift，应该包含存储系统的域名/地址加上存储数据的 Account、Container、Object 的整个信息的完整的 URL）；第四个是数据与元数据。

例子：

crul -i -X GET 

https://storage.clouddrive.com/v1/my_account?format=json\-H

"X-Auth-User:jdoe" -H "X-Auth-Key:jdoepassword"

storage.clouddrive.com 是对象存储的域名或者说地址，接着取 my_account 下面的 Container 的信息，后面带的是用户的认证信息 username 和 password 。先看下方返回结果：

根据上图我能够发现，API 调用之后返回的结果 Response 主要分为两段：1.头部。有两个要点，一个是它给出了这个 Account 下面 Container 的数量是 2，而后这个 Account 里面总共用了多大的存储空间，用了多少的字节或者说存了多少字节的数据进去，这里是 14。接着看下面的内容：

根据上图我能够发现，这是一个 json 的返回形式，把每个 Container 都列出来了，能够看到第一个 Container 里面没有 Object，因此它占用的字节数也是 0。

[ Swift 的软件架构：]

如图所示：

从上面下来是 Swift API，经过 Proxy Server 来实现，Proxy Server 左右两边分别连了两个东西：一个是作身份认证用的，每每是 Keystone，右边是一个 Cache 服务，这个 Cache 不去缓存实际的 Object 的数据，缓存的主要是用户的身份信息，别的会缓存一点其余的东西，不会去缓存数据，因此 Swift 是没有缓存的，原生设计就是没有缓存的；从 Proxy Server 下来会有三个 ring：Object Ring，Container Ring 和 Account Ring，ring 是一致性 HASH 实现。（一致性 HASH 是什么？ 分布式存储系统中为了把数据分布到各个节点上，用的一种数据结构就是一致性 HASH，后续会详细展开探讨。）下面是实际提供存储服务的进程或者说 Server，有 Object Server，Container Server 和 Account Server，有一个统一的称呼：Storage Server，对这些信息的默认的存储方式都是三副本。

[ 搭建 Swift 时须要的注意事项：]

Swift 的部署须要注意哪些？一个典型的 Swift 部署像图里画的样子：

图所示的是一个小型的 Swift 集群典型配置，想让 Swift 进行良好的工做，须要注意一些容易被人去忽视和常常犯错的地方，避免对 Swift 产生一些错误的认识，误认为 Swift 可靠性不行或性能不行，注意下面五个点：

1. 采用的是全对等架构，就是每一个节点每一个 Server 都是同样的，有 Proxy Server，有 Object Server， 有 Container Server 等等都是同样的。（实际上 Swift 从软件到部署都是一个全对等的概念在里面，是 Swift 架构的最突出的特色之一，让 Swift 可以很好的去作横向扩展，没有单点故障）。
2. 怎么把服务器组织起来呢？实际上，上面它有一个 Load Banlancer，可以把服务器（其实是 Proxy Server）组成一个集群，Load Banlancer 可以把用户的这些请求给它分配到各个实际的服务节点上。
3. 每一个服务器是一个zone Swift 是要求分 zone 的，要把服务器存储区域给隔离开，而后把这些副本放到不一样的 zone 里面去，因此这地方小规模集群通常都是让每一个 Server 做为一个 zone。
4. 做为小规模的部署，服务器的数量最少是5个（官方推荐的最小集群，达到比较好的效果）。
5. 不要用虚拟机（存数据的地方都不可能说是用虚拟化去作支撑的），不要用 RAID（用服务器用盘阵的时候常常会对它作 RAID，可是作完 RAID 之后会对咱们的 Swift 带来一些性能上不可预知的结果，Swift 自己具备数据管理的机制）。

[ Swift2.0的新功能：]

存储策略：让用户可以自由的选择数据的存储策略

Swift 的存储策略一部分由搭建存储系统的 Deployer 决定，另一部分是由使用存储系统的 Client 决定的，用户在这个里面以 Container 为力度，能够去指定这个存储策略。

Cinder 组件解析

提供块存储服务的 Cinder；

传统数据中心的存储设备常常听到 SAN 或者盘阵这些词汇，是经过网络链接给服务器提供存储空间的一类设备。硬盘对应了一个术语：块设备，传统存储也叫块存储。SAN 是典型的块存储，还有一类存储设备叫做 NUS。硬盘或者 LUN 是挂在服务器上的。

若是是在虚拟化环境之下，也能够像云硬盘同样挂载到虚拟机上，做为虚拟机的一个硬盘，也就是虚拟机的一个卷 Volume。Cinder 是提供块存储服务的，有时候也会说 Cinder 提供卷管理或者说是提供卷服务的。

SAN 设备与网络的两种链接主要有两种形式：第一种是 Fibre Channel（光纤通道，简称 FC），另一种是 iSCSI（是基于以太网协议的）。

若是是 FC，须要在服务器上装上 HBA 卡，用专用的光纤给它连到存储设备上。若是是 iSCSI 的话，走的是以太网协议和 IP 协议，因此不须要专用存储的网络链接了，用 iSCSI 的愈来愈多。

3-1 Cinder的组成架构

如上图所示，Cinder 的架构仍是很是简单的，里面有 Cinder 的 API，是用来提供 RESTful API 的，供客户端或者是其它组件来访问；中间还有一个 database，一样还有消息队列，Cinder 比较核心的两个组件：左边的 Cinder Scheduler 调度器，右边的 Cinder Volume。

一般状况下，若是咱们使用了多个存储设备来作 Cinder 的后端，一般须要运行多个 Volume 的实例，如图示意：

Scheduler 的任务是在有访问请求的时候、有建立 Volume 请求的时候选择经过哪一个 Cinder Volume 实例来建立卷，这就是 Scheduler 和 Volume 的分工。

重点分析一下 Volume，特别须要注意的一点是数据的流向，与 Swift 的区别是比较大的，Swift 对它的操做不只仅是经过 Swift Proxy Server 提供的 RESTful API 进行操做，它的数据也是经过 RESTful API 走的，咱们要把数据放在 Swift 里面或者从 Swift 里把数据拿出来，都经过 RESTful Web API。可是在 Cinder 不同，Cinder API 基本上只能提供一些操做和管理功能，是直接经过 FC/iSCSI 传输数据到服务器。那 Volume 的做用究竟是什么呢？数据不会经过 Volume 去走，也不会经过 RESTful API。实际上 Volume 里边有一个模块叫 Volume Driver，这个 driver 针对每个存储设备都不同，也被称为 Volume 插件，这个插件每每是由存储设备的厂商提供的。Volume 的核心主要是做用在这个 Driver 上，driver 的做用是什么？Driver 跟咱们一般的单机的操做系统的驱动的含义不同，这里的 Volume Driver 驱动主要是至关于一个适配的功能，把后端的设备的接口适配成 Cinder 的统一接口。

[ 补充：什么是软件定义存储？]

随着咱们数据中心的存储设备数量和种类以及上层应用的种类愈来愈多，上层应用对存储的需求也各不相同，因此就出现一个问题，怎么样去把这些设备给整合起来从而怎么样去更好的服务于上层应用，因而就出现了软件定义存储的概念。看一张从 EMC 官网上获得的图：

软件定义存储，一方面是为了隐藏底下的硬件的异构性，不论咱们用的是什么硬件，不论咱们用的是什么规模的硬件，不论咱们用的是什么型号的硬件，不论咱们用的是哪一个厂商的硬件，只要软件定义存储这一套软件支持，它对上层隐藏了底层的异构性；另一方面是对上层应用的支持，提供了多样化存储的接口，好比说常常提到的 Hadoop 的 HDFS，还有提供对象存储的接口，还有块存储的接口，用来支持不一样的应用。有了这样一个系统，那么加存储设备的人和构建底下这些存储基础设施的人就不用去担忧上层应用会怎么样，只须要按照如今存储规模的需求和性能的需求往上加存储设备就好了，或者说只要扩大如今的存储设备的容量就好了，上层应用也不用担忧底下怎么样去适应。只要暴露接口就好了。

OpenStack 的存储最主要的两个组件是 Swift（提供的是对象存储的接口）和 Cinder(提供了一堆 driver，Volume 里面嵌入的，这些 driver 能够调用不一样的存储设备，只要有 driver 就能够把存储设备给链接上，实际上就起到了屏蔽底层硬件异构性的做用。第二，Cinder 提供的是块存储的接口)，实际上也就是说咱们如今在网页上这个层面，至少已经支持了最经常使用的两种存储接口，正好对应了软件定义存储的两个方面。基于 OpenStack 咱们实际上是能够作一个软件定义存储的系统出来的。

Swift 提供对象存储时，对底层硬件是否有异构性限制。

 

Neutron 组件解析

软件定义网络项目 Neutron；

Nrutron 又被称为 OpenStack networking。

有一个概念叫做层（Tier/Layer）。两种层有什么区别呢？先说一下传统的网络，传统数据中心的网络是分为几个级别的，首先是服务器接入第一级交换机叫做接入交换机，接入交换机每每是在一个机架的顶部（因此也被称为架顶交换机 TOR），多是有堆叠的好比说是两个交换机来实现的，以下图所示最上部分的两个交换机。而后，会接入一个叫做汇聚层的交换机（汇聚交换机），每每是放在一排机架的顶头位置，这一层每每被叫作汇聚层。而后接入的是核心交换机，把汇聚交换机连起来的交换机就是核心交换机，核心交换机是数据中心很是大的网络节点，每每也不仅一个。

传统中心的数据网络分为接入层、汇聚层和核心层，也叫做三个层次（Tier）。现在的网络对三层网络作了演进。

可是在 OpenStack 里，层不是指的 Tier，而是协议栈的层，也就是 Layer。根据 ISO 的网络模型，实际上网络是分为七个 Layer，OpenStack 主要关注的是第二和第三层。第二层是数据量层 Datalink，第三层是网络层 Network。交换机 Switches 是工做在数据量层的典型设备，而路由器 Routers 是典型的工做在网络层的，Neutron 主要关注这两层。

假如没有 OpenStack Neutron ，虚拟化世界的网络是什么样子的？ 会使用虚拟网桥，是一个二层设备，是软件实现的网桥，不存在物理信号的问题，被认为是一个虚拟的跑在服务器寄主机内部的交换机，把虚拟机都连在这个交换机上，以下拓扑图：

若是仅仅是作一个虚拟化的环境，问题却是不大，但若是放在云的环境上就会出现问题了，由于云涉及到租户之间流量隔离的问题，网桥没法知足这种需求，网桥彻底是一个连通的，跟一个普通的交换机没啥区别。那么，说一说 Nova-network 又是怎么样的状况呢？

Nova-network 在之前的网桥的基础上，加了一个模块，所以能够有两种工做模式。第一种是：Flat DHCP 工做模式。能够提供像 DHCP 同样的功能。

第二种是：基于 VLAN 的隔离。可使用 VLAN 的方式把各类租户隔离开，勉强知足了云的需求，在一个对网络要求不是很高的简单云计算环境中使用 Nova-Network 就能够了。

事实上咱们还有其它的一些需求，好比咱们要实现一个比较大的二层，要实现对流量的控制，Nova-network 就不能知足要求了。那么，Neutron 在一种很是广泛的环境中跟 Nova-network 有多大的区别呢？

[ Neutron 有的功能：]

• 提供 VLAN 的隔离
• 提供软件定义网络 SDN（好比：L2-in-L3 的隧道，像 VXLAN、GRE 隧道；还支持 OpenFlow 协议）
• 支持第三方的 API 扩展
• 支持第三方的 Plugin 扩展

咱们能够开发本身的组件、插件放在 Neutron 生态里，与 Cinder 很是相似。

Neutron 支持租户建立本身的虚拟网络，看一个例子如图：

图里有两个租户，每一个租户建立了本身的网络，有本身的路由器，租户之间的网络是隔离的，而且每一个租户还能够定义本身网络的拓扑，这点很重要，复拓扑（Rich Topologies）是开发 Neutron 项目的重要目的。

在传统的物理网络架构中，会但愿对每层应用都互相使用相对隔离的网络，而后咱们能够在上面对每层进行负载均衡或者是作一些集群的方案，可是在虚拟世界中，若是咱们使用 Nova-network 很难实现。而 Neutron 诞生之后，这个问题就获得了解决。后续学习的 Heat 在工做的过程当中就利用了 Neutron 的功能，是 Neutron 的一个很好的应用案例。

PS：构建一个基于三层架构的Web服务

• 第一层：Web 页面服务器
• 第二层：应用服务器
• 第三层：数据库服务器

Horizon 组件解析

提供基于 Web 的一个 GUI 的 Horizon；

Horizon 提供可视化的 GUI 图形界面。让用户去操做这些项目使用的各类资源。Horizon 的内部架构是怎么样的？咱们若是要作二次开发，应该怎么去作？了解 Horizon 能够不妨先去了解 Python 的一个 Web 开发框架 Django。

[ 内部分为三个层次：]

1. Dashboard
2. PanelGroup
3. Panel

每一组可视化的界面都是 PanelGroup，每个 Dashboard 在 Django 里都是一个 App，OpenStack 的文件夹里的 openstackdashboard 文件夹里有一个 settings.py 文件，里面有一个变量叫 INSTALLEDAPP 定义了目前存在的这些 dashboard

官方的社区版里面通常有四个 dashboard

1. openstack_dashboard.dashboards.project // 普通用户 2. openstack_dashboard.dashboards.admin // 管理员 3. openstack_dashboard.dashboards.settings // 右上角设置面板 4. openstack_dashboard.dashboards.router // 通常是看不见的

 

Glance 组件解析

提供虚拟机镜像管理和存储服务的 Glance；

虚拟机镜像存储服务的，典型的对象存储应用

[ Glance 的架构：]

Glance API Server 提供 RESTful API，全部的访问请求会经过它 Glance Registry Server 组件对镜像进行注册，还能够提供镜像检索服务 Glance 可使用不一样的存储后端，有亚马逊的 S3 Store，有 Swift 对象存储，有 HTTP Store，有 Filesystem Store（Glance 本地的一个文件存储）

PS：对象存储这种扁平的数据组织结构的存储方式必定是未来的一个趋势，为何？人在使用计算机的时候会使用一级一级的目录去把文件塞到不一样的目录底下，创建一个树状的结构是为了方便咱们本身去查找。而在写程序的时候，是经过数据库去管理这些数据，经过索引去管理这些元数据，并不须要一级一级的目录结果，Glance 经过 Registry Server 去找到这些镜像、检索这些镜像，因此咱们的程序真正须要的是一个地址加上一个 ID，或者是一个地址加上一个 key。那么，对象存储正好就是地址加上 ID。因此说，对象存储会逐渐取代分布式文件系统，成为 Server 端的主流。（PS：固然，块存储是被替代不了的）不知道为何。

[ Glance的缓存机制：]

把 Glance API Server 作横向扩展，作一个负载均衡的集群，下面再转到实际的存储后端去，可是可能某些镜像会特别的有不少访问，这样的话某一个点的压力仍是会很大，因而就有了缓存机制，每一个经过 Glance 到达服务器的 Server 端的镜像，都会缓存到 API Server 上，注意，若是咱们有多个 API Server，随着用户访问请求的增多，被常常访问的那个同一个镜像会在每个 API Server 上都有一个，酱紫的话，在后续再有访问请求的时候就会直接用 API Server 上的镜像文件，而不会再去访问到存储后端上来，这个机制对终端用户来讲是透明的，终端用户并不清楚这个 Glance 服务获取的镜像究竟是存在哪里的。

[ 缓存管理须要注意的几个地方：]

• 对 Cache 总量大小的限制（周期性的运行，glance-cache-pruner --image_cache_max_size=*）
• 要清理一些状态异常的 Cache 文件（glance-cache-cleaner）
• 若是新加了一个 API Server 到负载均衡的集群环境里，新的 API Server 上没有缓存，因此还提供了预取某些热门镜像到新增的 API 节点中的机制（glance-cache-manage --host=<HOST> queue-image <IMAGE_ID>）PS：这也是在云环境中常常会去使用的一种方法
• 咱们能够手动删除缓存镜像来释放空间

Keystone 组件解析

提供身份认证和受权的 Keystone；

在 OpenStack 里面 Keystone 有两个做用。

• 第一个是：权限管理（用户的建权、受权；涉及到的概念有用户、租户、角色），租户是一组用户的集合，租户能够是一个企业一个部门一个小组等等。租户与用户之间每每是多对多的关系。
• 第二个是：服务目录（服务、端点），OpenStack 的每一个服务须要在 Keystone 里注册之后才能提供给用户去使用，端点 Endpoint 能够理解为服务暴露出来的访问点，，每个端点都对应一个服务的访问接口的实例。

关于角色 Role，安全领域有一个叫做基于角色的访问控制，Keystone 也是这样的一种安全机制，Role 是 Keystone 的访问机制里面的核心。那么对于 Role 怎么去操做呢？它最重要的命令就是 user-role-add，简单来讲这个命令就是指定某个用户具备某个角色。还有一个很是重要的用途，那就是实现用户和租户多对多的关系。下面举个例子怎么样去实现用户和租户之间多对多关系的操做方法。

// 建立租户tenant1
# keystone tenant-create --name tenant1 --enabled true // 建立另一个租户tenant2 # keystone tenant -create --name tenant2 --enabled true // 建立两个用户 user1 和 user2 和登陆密码 # keystone user -create --name user1 --tenant -id <tenant-id of tenant1> --pass password --enabled true # keystone user -create --name user2 --tenant -id <tenant-id of tenant2> --pass password --enabled true // user-role-add 命令，这里的-user-id 其实是 上面的 user2 的 id，-tenant-id 其实是前面咱们的tenant1 的 id，将 user2 加到 tenant1 里面，tenant1 就对应了两个用户：user1 和 user2，user2 就对应了两个tenant：tenant1 和 tenant2 # keystone user-role-add -user-id 7b32f4fc92704947802d2eca95edff0d -role-id 2493283f09c1475198f2337a47aa398f -tenant-id 0647347fa21d4221b0197cd282465a00

Role 在 Keystone 里面是一个关键的东西。

有一个问题，Keystone 是否解决了 OpenStack 的云安全问题呢？其实远远不够，它只是实现了对 OpenStack 各类服务的访问权限的控制。Keystone 不能和云安全划等号的。公有云上常见的安全防御手段有：

• 安全访问（OpenStack 会暴露出来一些 API 或 Endpoint，客户是经过 HTTP 协议访问的，实际上咱们应该容许经过 HTTPS 协议访问）
• 内置防火墙功能（FWIIS，Firewall as a Service，用户能够经过配置内置防火墙让云上的和环境或者应用更安全）
• 加密数据存储（云的管理员能够获取云存储上的文件，因此用户的文件须要加密让云的管理员没法查看、检索、分析，可是不是全部的客户端都提供给用户加密数据存储的功能）
• 帮助用户检测安全情况（主动监测租户的安全情况并给出提示，给出一些安全防御的提示，甚至在出现严重安全问题的状况下，会主动去把租户的服务下线以保证整个云的安全）

8. 总结

Nova

• nova-console
• nova-consoleauth
• nova-compute
• nova-conductor
• nova-scheduler

Swift

• 对象存储的特色
• 强调 Swift 的全对等架构
• 极高的可扩展性
• Swift 集群部署中的注意事项

Cinder

• 提供块存储服务或者说卷服务
• 经过 Cinder-volume 里面的 Driver 支持不一样的存储设备

Neutron

• 租用能够制定本身的 rich toplogy 的虚拟网络
• 经过各类 agent 和 plugin 实现具体的功能并和第三方设备、软件对接

Horizon

• 三级代码组织形式

Glance

• 掌握了 Glance 的镜像
• 对 Glance 作负载均衡

Keystone

• 经过 Role 进行权限管理
• 经过 Role 将同一个用户分配到不一样的 tenant 中

能够说，OPENSTACK不只是一种产品，更是一种模式。