OpenStack 设计与实现

一、初识 OpenStack

云计算：

  • IaaS（技术架构即服务）：通过互联网向用户提供基础的计算资源，用户能申请到硬件或虚拟硬件，然后安装操作系统或其他应用程序。
  • PaaS（平台即服务）：把计算环境、开发环境等平台当作一种服务并通过互联网提供给用户，用户可以安装其他应用程序，但不能修改预先安装好的操作系统和运行环境。
  • SaaS（软件即服务）：通过互联网为用户提供软件及应用程序的一种服务方式，用户通过网络以租赁的方式使用，而不是直接购买。

OpenStack 是 IaaS，Docker 是 PaaS。

OpenStack 一方面负责与运行在物理节点上的 Hypervisor 进行交互，实现对各种硬件资源的管理与控制；另一方面为用户提供一个满足要求的虚拟机。

OpenStack 标准（曾经）的七个核心组件：

  1. 计算（Compute：Nova）：根据需求提供虚拟机服务，如创建虚拟机或对虚拟机进行热迁移。
  2. 对象存储（Object Storage：Swift）：允许存储或检索对象，能以低成本的方式通过 RESTful API 管理大量无结构数据。（**和 Riak 相比，Riak 更加轻量级，Swift 结合 OpenStack 使用，更加重量级）
  3. 认证（Identity：Keystone）：为所有 OpenStack 服务提供身份验证和授权，跟踪用户及他们的权限，提供一个可用服务及 API 的列表。
  4. 用户界面（Dashboard：Horizon）：为所有 OpenStack 服务提供一个模块化的基于 Django 的界面，用户和运维人员可以在这个界面完成多数的操作。
  5. 块存储（Block Storage：Cinder）：提供块存储服务，用以扩展 nova-volume 的功能。
  6. 网络（Network：Neutron）：提供网络连接服务，允许用户创建自己的虚拟网络并连接各种网络设备接口。
  7. 镜像服务（Image Service：Glance）：提供虚拟机镜像的存储、查询和检索服务，通过虚拟磁盘镜像的目录和存储库，为 Nova 虚拟机提供镜像服务。

用户通过 Horizon 创建虚拟机，从 Glance 下载存储在 Cinder 的虚拟机镜像文件，并使用 Cinder 的块服务和 Neutron 的网络服务，使得 Nova 虚拟机包含 Volume 存储且能分配 IP 地址与外界网络连接，之后的访问虚拟机资源的操作都需要经过 Keystone 的认证，虚拟机使用的一些配置和资源可以使用 Swift 存储。

  • 孵化继承模式：新项目首先要被孵化，然后在成熟到一定程度时，经过申请和投票决定是否把它放到集成项目里，并且它的发布版必须与 OpenStack 发布同步
  • 大帐篷模式：OpenStack 基金会用文档定义了 OpenStack 流程及其开源社区的工作方式，只要该项目符合这些流程，并经过审核批准后，就可以成为大帐篷的一员，而且该项目的发行步骤也可以根据自身的特殊要求进行小范围调整。

大帐篷模式降低了新项目变成 OpenStack 项目的门槛，使得 OpenStack 涌现大批项目，但同时项目质量也难以掌控，增加了基金会的管理难度。

OpenStack 的技术发展趋势：

  1. 裸机资源的管理：OpenStack 在架构设计上最初是以虚拟机的管理为中心的，但随着云计算用户使用场景多元化，对于虚拟机之外的计算资源的管理与编排就显得越发必要，比如裸机计算资源。
  2. 容器化：Docker 和 Kubernetes 之类的容器集群的管理平台在云计算领域大放异彩，一个新的应用在设计之初就要考虑是否云原生，即充分运用云服务的弹性和分布式的优势。（云原生=微服务+DevOps+持续交付+容器化）
  3. 多元的云计算环境：OpenStack 所主导的以虚拟化技术为中心的云计算技术路线；以容器为计算资源基础单元的容器云。（虚拟化和容器）
  4. 更加彻底的资源池化：技术资源的池化，网络资源的池化（SDN）和存储资源的池化（SDS），概括就是软件定义基础架构（SDI）
  5. 边缘计算：云计算用户迟早会遇到网络拥挤，延迟高，实时性差和性能瓶颈，从而逐渐无法满足其对业务的需求。边缘计算可以被认为是云计算的扩展和延伸。云计算把数据移到代码那一端，边缘计算把代码移到数据那一端。

二、OpenStack 开发基础

如何分析源码：

  1. 源码地图：对于大多数项目来说，通过它的编译系统可以很容易n通清除代码之间的脉络，从而从庞大的代码里定位到我们所关心的部分。
  • 例如：Linux 内核源码的 Kconfig 和 Makefile：
  1. 遍历每个源码目录（或配置指定的源码目录）Makefile
  2. 每个目录的 Makefile 会根据 Kconfig 来定制要编译对象，Kconfig就是配置哪些文件编译，那些文件不用编译
  3. 回到顶层目录的 Makeifle 执行编译
    2， setup.cfg：Python 作为解释性语言，并没有编译系统。
  • setup.py 调用 setup 函数
  • setup.cgf 配置参数
  1. entry points：代码的入口点通常是理解的突破口。
  • entry points 可以被理解为通过 Setuptools 注册的，外部可以直接调用的接口
  1. console scripts：特殊的一组 entry points.
  • 作为可执行脚本的入口点

OpenStack 代码质量保证体系：

代码应该是写给其他人来读的，而能让机器运行仅仅是其附带功能。一般来说，干净整洁的代码，往往运行速度更快，而且即使运行速度不快，也更容易地让它们的运行速度变快。

  1. 代码静态检查，代码静态检查工具是编译器功能的延伸，编译器因为考虑速度而放弃了一些较难发现的条件的检查，如内存泄露，死循环等，而代码静态检查工具可以牺牲运行的速度来换取更为彻底的词法和语法分析，更为准确地找到更多问题。
  • Flake8 是 Pyflakes、Pep8 和 Ned Batchelder’s McCabe Script 三个工具的集成，封装了功能，简化了操作，提供了扩展开发接口；OpenStack 使用一组 Flake8 插件来作为 Hacking 子项目。
  1. 代码评审 Gerrit（Code Review）：橡皮鸭程序调试法
  • git-review：封装了和 Gerrit 交互（代码提交、评审、修订、再提交）的细节。
  1. 单元测试 Tox：虽然单元测试在形式上追求 100% 的代码覆盖率，但是程序员倾向于自信（自大），而偏爱只对有意义的错误做测试。
  • 隔离：测试代码不喝数据库，文件系统交互，也不进行网络通信。
  • 速度：单元测试的粒度要足够小，确保一旦测试失败可以快速定位问题根源。
  • 可移植：测试代码可移植。
  1. 持续集成 Jenkins：Jenkins 是 OpenStack 的官方 CI 系统，每个 path 在最终合并前都必须通过 Jenkins 的测试。

文档：

  1. Wiki：设计细节，会议信息和记录
  2. RST：开发文档，API 说明
  3. DocBook：使用手册

三、虚拟化

云计算的一个核心思想就是在服务器端提供集中的物理计算资源，这些计算资源可以被分解成更小的单位去独立地服务于不同的用户，也就是在共享物理资源的同时，为每个用户提供隔离、安全、可信的虚拟工作环境，而这一切不可避免地依赖于虚拟化技术。

计算机系统是一个层次结构，每个层次只需要知道下一层次抽象的接口，而并不需要了解其内部运作机制，例如：操作系统和硬件之间的硬件抽象层，应用程序和操作系统之间的 API 抽象层。这种层次抽象使得每个层次只需要考虑本层的设计，以及与相邻层次间的交互接口，从而大大降低了系统设计的复杂性，提高了软件的可移植性；而且这样的设计还给下一层次的软件模块为上一层次的软件模块创造"虚拟世界"提供了条件。

本质上来说，虚拟化就是位于下一层次的软件模块，根据上一层次的软件模块的期待，抽象出一个虚拟的软件或硬件接口，使上一层次的软件模块可以直接运行在与自己所期待的运行环境完全一致的虚拟环境中。由于每一层只能看到下一层的接口层，所以使用虚拟机和物理机并没有什么区别。

  1. VM 直接运行在硬件平台上：很多问题如果在本身的层次上难以解决，就可以增加一个层次，使其在下面一个层次变得容易解决。硬件辅助的完全虚拟化在硬件本身加入了足够的虚拟化功能，解决了虚拟化的问题。
  2. VM 运行在传统操作系统上：对所运行的客户机操作系统做修改使其适应虚拟环境，客户机操作系统知道自己运行在虚拟平台上。

虚拟化引入的新特性：

  1. 动态迁移：将一台虚拟机从一台物理机快速迁移到另一台物理机，但是虚拟机里面的程序和网络都会保持连接。对高可用性和负载均衡（低峰期集中到一台物理机）。动态迁移的实现方法是在目的服务器上建立一台同样配置的新虚拟机，然后不断地在两台虚拟机之间同步各种状态，如内存、外设、CPU 等。在状态同步完成后，关掉旧的虚拟机，启动新的虚拟机。
  2. 虚拟机快照：保存所有的磁盘信息，内存信息和 CPU 信息，可以便捷地产生一套同样的虚拟机环境。广泛应用于测试、备份和安全等各种场景。
  3. 虚拟机克隆：把一台虚拟机的状态完全不变地复制到另一台虚拟机中，形成两个完全相同的系统并且可以同时运行，需要修改 MAC 地址等以避免冲突。
  4. P2V（Physical to Virtual Machine）：将一个物理服务器的操作系统，应用程序和数据从物理硬盘迁移到一台虚拟机的硬盘镜像中。

VM 本身只是提供了虚拟化的基础架构，配置、启动虚拟机都需要通过高层管理工具来实现，例如：XenAPI、Libvirt。

四、OpenStack 通用技术

计算机发展的整个过程，就是一个不断提取通用性的过程。

1. 消息总线

OpenStack 项目之间通过 RESTful API 进行通信；项目内部的不同服务进行之间的通信，则必须通过总线。

进程间通信：

  1. 远程过程调用（RPC）：远程调用其他服务进程的方法，用 call 同步调用和 cast 异步调用。
  2. 事件通知（Event Notification）：服务进程可以把事件通知发送到消息总线上，消息总线上所有对此类事件感兴趣的服务进程可以获得事件并进一步处理，处理结果不会返回给事件发送方。

OpenStack 的消息总线大部分使用 AMQP（Advanced Message Queuing Protocol，高级消息队列协议），使用 Exchange（消息交换）和 Queue（消息队列）来实现。生产者将消息发送给 Exchange，并由 Exchange 来决定消息的路由，即决定要将消息发送给哪个 Queue，然后由消费者从 Queue 中取出消息，进行处理。

基于 AMQP 可以实现 RPC：使用两个消息来分别执行远程方法调用操作和发送调用结果操作。

2. 数据库

SQLAlchemy 包括 SQLAlchemy core（SQL 核心）和 SQLAlchemy ORM（SQL 对象关系映射器）。

SQLAlchemy 是 Python 和各种后台数据库之间的桥梁，OpenStack 提供的 MySQL，PostgreSQL 等多种数据库的操作都使用 SQLAlchemy 进行了类封装。

3. RESTful API 和 WSGI

HTTP 基本操作，GET，POST，PUT，DELETE，使服务端上的资源发生状态转化，即表述性状态转移。

OpenStack 使用的路由系统，采用 MVC 模式，每个 Controller 对应一个 RESTful 资源，里面的很多 action 代表对该资源的操作集合，每个 action都对应一个 HTTP 的请求和回应。

RESTful 只是设计风格而不是标准，WSGI（Web Server Gateway Interface，Web 服务器网关接口）是 Python 语言中所定义的 Web 服务器和 Web 应用程序或框架之间的通用接口标准。

WSGI 是一个网关，在协议之间进行转换：（类似 thrift）

  1. Web 服务器：接收 HTTP 请求，调用 WSGI 应用，将响应结果返回给客户端。
  2. Web 中间件：同时实现了服务端和应用端的 API，在服务端看来是应用端，在应用端看来是服务端。在客户端请求传递给应用端之前做一层功能包装。
  3. Web 应用程序：一个可被调用的 Python 对象，接收两个参数：版本配置和回调函数。

4. Eventlet 和 AsyncIO

线程的调度完全由操作系统来控制，而协程的执行顺序和时间完全由程序自己决定。

  • Eventlet：适用 Python2，已过时
  • AsyncIO：适用 Python3

5. 命令行构建

Cliff 可以用来很方便地构建命令行程序。主程序只负责基本的命令行参数的解析，然后调用各个子命令去执行不同的操作。

6. OpenStack 通用库 Oslo

  1. oslo.config
  • 用于解析命令行和配置文件中的配置选项。定义好的配置选项，必须在注册后才能使用。配置选项可以注册为命令行选项，这些配置选项可以从命令行中读取，并覆盖配置选项中的值。
  1. oslo.db
  • 对 SQLAlchemy 访问的抽象。
  1. oslo.i18n
  • 对 Python gettext 模块的封装，用于字符串的翻译和国际化。
  1. oslo.messaging
  • 为 RPC 和事件通知提供了一套统一的接口。
  1. stevedore
  • 在 Setuptools 的 entry points 的基础上进行了一层封装，使得可以更容易地在运行时发现和载入插件。
  1. Taskflow
  • 控制任务的执行。
  1. cookiecutter
  1. oslo.policy
  • 控制用户的权限，指定用户能够执行什么样的操作。
  1. oslo.rootwrap
  • 可以使 OpenStack 服务能够以 root 的身份执行 shell 命令。
  1. oslo.test
  • 单元测试的基础框架。
  1. oslo.versionedobjects
  • 对数据库结构和 API 接口的改动添加版本控制，可以和 oslo.messaging 结合进行远程调用。

五、计算（Nova & Placement）

Nova 专注于提供统一的计算资源抽象，这些计算资源可以是物理机、虚拟机、容器。

Nova 对外通过 RESTful API 进行通信，对内通过 RPC 进行通信，使用一个中心 DB 来存储数据。

四个核心组件：

  1. API：进入 Nova 的横向接口，依据请求是长时任务还是短时任务，将请求发送给 Conductor 或 Compute。
  2. Compute：处理短时任务。
  3. Conductor：处理长时任务。
  4. Scheduler：对物理机上的虚拟机进行调度。

Nova 系统拥有一个最小和最大版本号，只要请求在这个范围之内就会被接受。

Rolling Upgrade（滚动升级）：避免了 offline 的升级，通过多步升级，减少了系统的 downtime。

Rolling Upgrade 关键技术：

  1. RPC Versioning：通过对 RPC 接口的版本化来实现各个组件在通信方式上的兼容。
  2. Conductor：在提供数据库代理访问和模块间通信的过程中，提供了向下的兼容性，完成不兼容对象的自动转换。
  3. Versioned Object Model：采用面向对象的思想对数据进行了封装，并为封装的数据提供了数据库代理、RPC 版本兼容、流量优化等高级功能。

Scheduler 调度器服务来决定虚拟机的生存空间和资源分配，即是否有一台主机能够容纳新的虚拟机，它会通过各种规则，考虑内存使用率，CPU 负载等多种生存因素，为虚拟机选择一个合适的主机。

Resource Tracker 监控本机资源的变化，并在数据库中更新主机的资源使用情况，包括内存、CPU、磁盘等。

调度流程：如果将 Nova 比作生命体，那么调度就相当于神经系统。它会根据变化的环境（主机的组织结构、状态及其使用情况）和刺激（虚拟机启动请求）进行决策（调度决定），并作出一系列行为反应（在选择的主机上启动虚拟机，并保存调度结果），而调度器的作用相当于神经中枢。

  • 预处理阶段：API 会对请求进行安全检查，并准备数据项和请求对象，将请求发送给 Conductor。
  • 调度决策阶段：Conductor 调用 Scheduler 进行调度决策。
  • 调度结束阶段：Conductor 调用 Compute 进行调度执行。

Cells 将计算节点划分为较小的组，每组对应一个数据库和一个消息队列。

Nova 工作流程：

  1. 创建虚拟机
  2. 冷迁移
  3. 资源伸缩
  4. 热迁移
  5. 挂起和恢复
  6. 虚拟机重建和自动重建

Placement 是管理资源的项目，其核心功能是帮助用户寻找满足资源需求的设备。对于 Nova 来说，Placement 服务操作的资源是物理主机。Placement 还服务于 Cyborg（GPU 等加速资源），Neutron（网络） 等项目

  1. 计算节点建模与资源上报：对其拥有的资源进行抽象、概括和表述。
  2. 查询备选资源。
  3. 申请资源。

六、存储（对象存储 Swift、块存储 Cinder、镜像存储 Glance）

Nova 使用的临时存储随着虚拟机的删除被自动释放，而对象存储和块存储则提供了永久存储。

Swift 对象存储

Swift 中存储的每个对象都是一个 RESTful 资源，并且拥有一个唯一的 URL，可以使用 RESTful API 来进行 CURD。

  • 访问层：Proxy Node（代理服务节点）负责 RESTful 请求的处理；Authentication（认证）负责用户身份的认证。
  • 存储层：有物理存储节点组成，负责对象数据的存储。

Ring 记录了存储对象与物理位置的映射关系。

Cinder 块存储

由 nova-volume 服务剥离而来。

Swift 在存储数据与具体存储设备和文件系统之间引入了"对象"的概念作为抽象，Cinder 在虚拟机与具体存储设备之间引入了一层"逻辑存储卷"的抽象，提供 RESTful API 主要用于逻辑存储卷的管理。

为了支持不同的后端存储技术与设备，Cinder 创建了一个 Driver 框架。

cinder-backup 可以将 Volume 备份到其他存储系统上，例如：Swift，Ceph 等。

Glance 镜像存储

依赖 Ceph 等后端存储系统来实现镜像存储服务。Glance 实际只负责镜像的管理，由 Ceph 等负责实际的存储。

使用 RESTful API 处理用户请求，然后通过后台存储系统完成镜像的存储与获取。

Ceph 存储系统

集性能、可靠性和可扩展性为一身的分布式存储系统。

  1. Ceph 块存储
  • Glance 镜像服务的存储后端
  • Cinder 块服务的存储后端
  • Nova 的虚拟 Guest Disk 的存储后端
  1. Ceph 对象存储
  • 与 Keystone 集成
  • 与 Swift 集成
  1. Ceph 文件系统
  • Ceph FS 集成

七、网络（Neutron）

Neutron 由 nova-network 服务剥离而来。

  1. TAP/TUN 是 Linux 内核实现的一对虚拟网络设备，TAP 工作在二层，TUN 工作在三层。VETH 设备总是成对出现。
  2. Linux Bridge（网桥）是工作于二层的虚拟网络设备，功能类似于物理的交换机。
  3. Open vSwitch 是一个虚拟交换机，用于连接 vNIC（虚拟网卡）和物理网卡，同时桥接同一物理 Server 内的各个 vNIC。

网络资源抽象：

  1. Network：隔离的 L2 广播域，一个用户可以有多个网络，一个网络可以有多个子网。
  2. Subnet：逻辑隔离的 L3 域，子网代表一组 IP 地址集合，即分配了 IP 地址的虚拟机。
  3. Port：虚拟网口，是 MAC 地址和 IP 地址的承载体，则是数据流量的出入口。

Neutron 支持的网络类型：Flat，VLAN 和 Overlay（VxLAN，NVGRE/GRE，GENEVE)。

Neutron 组网的三类节点：

  1. 控制节点
  2. 计算节点
  3. 网络节点

Neutron 由服务进程 neutron-server 提供 RESTful API 作为访问入口，接受到的用户 HTTP 请求最终会由遍布于计算节点和网络节点的各种 Agent 完成。

Extension API：

  1. Firewall：提供防火墙。
  2. LoadBalance：提供 VM 实例之间的负载均衡。

八、安全与认证（KeyStone & OpenAttestation）

  1. 数据安全：强加密和秘钥管理。
  2. 身份和访问管理安全：KeyStone 通过 Policy（访问规则）来进行基于用户角色的访问控制。
  3. 虚拟化安全：共享和隔离。
  4. 基础设施安全：可信计算池（Trusted Compute Pools）通过对计算节点的硬件及系统内核进行度量来确定一个可信任计算节点的集合。

KeyStone 的作用类似于一个服务总线，Nova，Glance，Horizon，Swift，Cinder 及 Neutron 等其他服务都通过 KeyStone 来注册其服务的 Endpoint（可理解为服务的访问点或 URL），针对这些服务的任何调用都需要经过 KeyStone 的身份认证，并获得服务的 Endpoint 来进行访问。

KeyStone 主要提供六个方面的核心服务：

  1. Identity：身份服务，提供身份验证凭证及有关用户和用户组的数据。
  2. Token：确认用户的身份之后，会给用户提供一个核实该身份且可以用于后续资源请求的令牌。
  3. Catalog：对外提供一个服务的查询目录，也就是每个服务可访问的 Endpoint 列表。
  4. Policy：一个基于规则的身份验证引擎，通过配置文件来定义各种动作与用户角色的匹配关系。
  5. Resource：提供关于 Domain 和 Project 的数据。
  6. Assignment：提供关于 Role 和 Role Assignment 的数据，负责角色授权。

Manager 类负责基于不同的 Backend Driver 对请求进一步处理，不同的 Backend Driver 代表着不同的后端实现方式：

  1. SQL：利用 SQLAlchemy 进行数据的持久化。
  2. KVS：结合缓存来实现数据的存储。
  3. LDAP：轻量目录访问协议，以树状的层次结构来存储数据。
  4. Template：主要用在服务目录中，通过模板的方式支持用户自定义一个当前系统环境下可用的服务目录。

KeyStone 高阶应用：

  1. 联合身份管理（Federation）：将身份认证部分单独剥离出来，即使用一个独立的节点对用户身份进行认证，用户可以使用一个密码访问多个被授权访问的云系统。（类似 SSO）
  2. KeyStone OAuth1：将用户的访问权限代理给第三方，其核心理念就是在不泄露访问服务提供者的秘钥的前提下将部分功能开放给第三方访问者。
  3. KeyStone Trust：提供了另一种方式的权限代理，委托者可以将其部分或全部权限代理给代理人。

可信计算池：保证虚拟机运行在验证为可信的计算节点之上，以此来保证运行环境是可信的。

可信认证与 OpenAttestation 项目（OAT）：使用 TCG 定义的远程认证协议，实现了标准的基于 TPM 的可信认证流程，为云计算及企业数据中心管理工具提供了主机完整性验证的 SDK。

九、计量与监控（Telemetry）

Telemetry 针对各种组成云的虚拟和物理资源，收集各类使用数据并保存，以便对这些数据进行后续分析，并在相关条件满足时触发对应的动作和报警。

  1. Aodh：根据已保存的使用数据（测量值或 Event 事件）进行报警。
  2. Ceilometer：提供一个获取和保存各类使用数据的统一框架。
  3. Gnocchi：用来保存基于时间序列的数据，并对其提供索引服务。
  4. Panko：用来保存时间 Event 信息。

Ceilometer 是核心子项目，通过两种方式获取测量值数据：

  1. 第三方的数据发送者把数据以通知消息（Notification Message）的形式发送到消息总线（Notification Bus）上，Notification Agent 会获取这些通知事件，并从中提取测量数据。
  2. Polling Agent 会根据配置定期、主动地通过各种 API 或其他通信协议去远端或本地的不同服务实体中获取所需要的测量数据。

为了适用于不同应用场景下的测量数据，可以使用 Pipeline 来控制不同的采用频率和分布方式。

由于 Ceilometer 产生的数据量特别大，Telemetry 社区建议使用 Gnocchi 来保存采样数据。

为了灵活的部署，将报警相关的功能剥离出来，形成了新项目 Aodh：

  1. API：面向用户的 RESTful API 接口，可以对后台的 SQL 数据库（保存了告警器的定义和状态）进行 CURD。
  2. Alarm Evaluator：周期性检查除 Event 类型之外的其他告警器，是否满足报警条件。
  3. Alarm Listener：根据消息总线上的 Event 事件消息，检查 Event 类型的告警器，是否满足报警条件。
  4. Alarm Notifier：当告警器的报警条件满足时，执行用户定义的动作。

Gnocchi 中保存了大量的数据。并且只保存最近的测量值，且动态地计算统计信息。解决了保存量太大和获取统计值较慢的问题。

十、物理机管理（Ironic）

云环境对虚拟机和物理机的部署和管理需要统一的接口。

提供了 RESTful API 服务，是访问并使用 Ironic 所提供的服务的唯一途径。ironic-api 在接收到 RESTful 的请求之后，会通过 RPC 调用 Conductor 完成实际的工作，而 Conductor 会根据配置使用具体的驱动。

根据物理硬件的不同，Ironic 提供了一个驱动的框架，每个驱动都需要实现核心功能：

  1. Deploy：实现机器镜像部署
  2. Power：实现机器的开机、关机和重启
  3. Console：用于获取机器的 Console 接口
  4. Management：实现机器启动设备的管理
  5. Inspect：实现机器的 Capabilities 探测
  6. RAID：实现机器存储 RAID 功能的设置
  7. Rescure：使机器进入安全模式启动
  8. Vendor：用于把各个 Vendor 特定的功能透传给驱动

Ironic 中的主要资源包括：

  • Chassis：表示一个机柜或机架，是 Node 的集合
  • Driver：表示服务里面的各种驱动资源，包括安装、部署、启动和电源控制
  • Node（核心）：表示注册在 Ironic 中的一个物理机
  • Port：表示 Neutron 中的网络端口，用来绑定物理机上的网课端口

十一、控制面板（Horizon）

Horizon 提供了一个模块化的基于 Web 的图形界面。用户通过浏览器使用 Horizon 提供的控制面板来访问、控制它们的计算、存储和网络资源。

Horizon 采用了 Django 框架，就是一个基于 Django 的网站。

十二、容器（Magnum）

容器技术是操作系统级别的虚拟化技术，和虚拟机技术都支持资源的隔离访问。但是容器系统不需要运行客户机操作系统，它可以共享主机操作系统的内核，利用各种操作系统级别的隔离技术实现容器之间资源的隔离访问。

容器技术的核心是资源隔离，同时共享内核空间内某些系统在运行时的数据，但最终访问系统硬件资源还是通过主机的内核完成的。

Linux 的容器的隔离技术：

  1. 用户/组特权隔离：通过对应用进程设置不同的用户 ID 或组 ID 来实现资源访问的限制。即 A 用户创建的资源对 B 用户不可见。
  2. 文件系统隔离：使用 chroot 的方式对文件系统进行隔离。
  3. 控制组资源隔离：cgroup 提供了对操作系统内存、CPU、IO 资源使用的限制，可对某一进程所能获得的最大资源进行限制。

Linux 的容器的命名空间：

  1. Mount 命名空间：提供 Linux 目录挂载点的隔离访问。
  2. UTS 命名空间：为容器提供主机名和域名的隔离。
  3. IPC 命名空间：用于隔离不同进程间的通信。
  4. PID 命名空间：对进程空间进行隔离，使得不同命名空间的两个进程可以有多个相同的进程号。
  5. Network 命名空间：隔离不同容器的网络，使得不同容器可以具有相同的网络资源，如同一主机上的两个容器在自己的 Network 命名空间中可以看到相同的端口号。
  6. User 命名空间：可以在新的用户命名空间中创建拥有特权的超级用户。如，特权用户的 User ID 是 0，当创建新的容器实例时，在新的用户空间中，用户的 User ID 也可以是 0，在容器内部，此用户是特权用户，但是在容器外部，该用户仍然是普通用户。

常用容器集群管理工具：

  1. Docker Swarm：Docker 公司
  2. Kubernetes：Google 公司
  3. Mesos：基于 Apache 协议的分布式计算内核

Magnum 项目利用了 OpenStack 中的计算、存储、网络、编排及认证服务来为 OpenStack 用户提供生产级可用的容器集群管理服务。其核心功能为：

  1. 容器集群的生命周期控制和管理。
  2. 抽象不同类型的容器集群，并提供可扩展的驱动方式。支持以上三种容器集群管理工具。
  3. 支持虚拟机和物理机部署容器集群。
  • Murano 提供应用程序目录服务，可以快速发布各种云应用。
  • Kolla 聚焦于如何使用 Docker 容器部署 OpenStack 服务。
  • Solum 致力于在 OpenStack 云上提供开发和生产环境的一套自动化持续集成和持续发布系统，方便发布，易于迭代和回滚。
  • Kuryr 使得 Docker 可以直接使用 Neutron 提供的网络。
  • Kata 安全容器，采用虚拟机进行容器的隔离，提高了容器的安全性能。

十三、部署

开发环境可以使用 DevStack 一键部署。

配置管理工具：Puppet，Chef，Ansible，Salt

OpenStack 部署项目包括两部分：基础操作系统的提供与 OpenStack 组件的部署：

  1. Bifrost：由一系列 Ansible 脚本组成，它可以在一套已知的硬件上通过 Ironic 自动部署一个基本的镜像，利用 Ironic 的 Standalone 模式来管理和部署硬件设备。
  2. Kolla：包括专门负责制作容器镜像和 Kolla 和专门负责部署的 kolla-ansible。
  3. TripleO：V2P（Virtual Machine to Physical Machine），P2V 即把一个物理机上的内容做成镜像并迁移到虚拟机中，而 V2P 是其逆过程，即把虚拟机的镜像迁移到物理机上。首先准备一个 OpenStack 节点镜像，然后利用已有的 OpenStack 环境的裸机服务（Ironic：Bare Metal）去部署裸机，最后通过 Heat 项目在裸机上配置运行 OpenStack。

十四、加速设备管理（Cyborg）

Cyborg 旨在为加速资源（GPU，FPGA，ASIC，NVMe，DPDK/SPDK 等）提供通用管理框架。

cyborg-api 是进入 Cyborg 的 HTTP 接口，接收和处理 RESTful API 请求。

Cyborg 只负责管理、调度各个计算节点上的硬件加速资源，并不负责运行虚拟机，创建带有硬件加速资源的虚拟机还需要使用 Nova 组件并与 Cyborg 进行交互。

Cyborg 数据库中的设备配置文件（device_profiles）和加速器请求（extend_accelerator_requests）是 Cyborg 和 Nova 交互的重要手段。