前言

此课程为华为云学院的免费课程，从今天开始陆续学习华为和阿里的云课程，一是为了增加知识量，二是为了硕士毕业后能实现当老师的夙愿，所以会不定时的更新。再说下，写论文做实验，真是头大！！！

第一章什么是OpenStack

OpenStack是一个云操作系统，通过数据中心可控制大型的计算、存储、网络等资源池。所有的管理通过前端界面管理员就可以完成，同样也可以通过web接口让最终用户部署资源。下图为华为云IaaS架构

OpenStack的定位：

OpenStack只是云计算系统的控制面

OpenStack不包括系统的数据面组件，如hypervisor、存储和网络设备等

OpenStack只是构建云的关键组件: 骨干、框架、总线

OpenStack设计理念：

开放：开源，并尽最大可能重用已有开源项目；不要“重复发明轮子”，而要“站在巨人肩膀上

灵活：不使用任何不可替代的私有/商业组件；大量使用插件化方式进行架构设计与实现

可扩展：由多个相互独立的项目组成，每个项目包含多个独立服务组件；无中心架构、无状态架构

华为云OpenStack架构关键特点

1.可扩展性：

最大100个数据中心！

最大10万个物理计算节点！

最大100万个虚拟机！

2.全局视图和跨数据中心资源管理：

支持租户资源（配额、计量、网络、镜像等）全局视图

支持跨数据中心2层/3层网络互通

提供全局SDN功能

第二章 Openstack组件

共享服务组件（6个）：

数据库服务（database service）:Mariadb及Mongodb

消息传输(Message Queues): RabbitMQ

缓存（cache）:Memcached

时间同步(time sync)：ntp

存储（storge provider）：ceph,GFS,LVM,ISICI等

高可用及负载均衡：pacemaker,HAproxy,keepalived,lvs

核心组件：

身份服务（Identity Service）:Keystone

计算服务（compute）:Nova

镜像服务（Image Service）:Glance

网络服务（Network）:Neutron

块存储服务（Block Storage）:Cinder

Web界面服务（Dashboard）:Horizon

对象存储（Object Storage）:Swift

测量（Metering）:Ceillrmeter

部署编排（Orchestration）:Heat

第三章部分组件介绍

3.1 Nova

Nova 是一个完整的 OpenStack 计算资源管理和访问工具，负责处理规划、创建和删除操作,是openstack最核心的服务，负责维护和管理云计算计算资源。下图为nova逻辑结构图：

nova组件介绍

3.1.1nova-api

是整个nova的门户，所有对nova的请求都首先由nova-api处理。Nova-api向外暴露若干HTTP rest api 接口在keystone中，客户端可以将请求发送到endpoint指定的地址，向nova-api请求操作。

Nova-api对收到的HTTP api请求会做如下处理：

(1).检查客户端传入的参数是否合法；

(2).调用nova其他子服务的处理客户端HTTP请求；

(3).格式化nova其他子服务返回的结果并返回给客户端。

3.1.2nova-conductor

Nova-compute需要获取和更新数据库中instance的信息，但nova-compute并不会直接访问数据库，而是通过nova-conductor实现数据的访问。

使用nova-conductor的两个显著好处：

(1).更好的系统安全性：早期的openstack版本中，nova-compute可以直接访问数据库，但试想如果任意一个计算节点被黑客入侵，都会导致控制节点上的数据库面临极大的风险。为了解决这个问题，引入了nova-conductor；

(2)更好的伸缩性：nova-conductor建立后，提高了nova的伸缩性。Nova-compute与conductor是通过消息中间件交互的。这种松散的架构允许配置多个nova-conductor实例，从而应对日益增长的计算节点对数据库的访问。

3.1.3nova-scheduler

虚拟机调度服务，负责决定在哪个计算节点上运行虚机。

如何选择计算节点——启动实例调度策略

Filter scheduler(调度器)，调度过程分两步：

(1).通过过滤器（filter）选择满足条件的计算节点（运行nova-compute）

(2).通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建instance

Filter具体有哪些:

RetryFilter

AvailabilityZoneFilter

RamFilter

DiskFilter

CoreFilter

ComputeFilter

ComputeCapabilitiesFilter

ImagePropertiesFilter

ServerGroupAntiAffinityFilter

ServerGroupAffinityFilter

Weight: 默认实现是根据计算节点空闲的内存量计算权重值：空闲内存越多，权重越大，instance 将被部署到当前空闲内存最多的计算节点上。

3.1.4nova-compute（装在计算节点上）

nova-compute 在计算节点上运行，负责管理节点上的 instance。OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。

3.1.5Console Interface

nova-console:

用户可以通过多种方式访问虚机的控制台：

nova-novncproxy，基于 Web 浏览器的 VNC 访问
nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问
nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问

nova-consoleauth

负责对访问虚机控制台请求提供 Token 认证

nova-cert

提供 x509 证书支持

********************************************************************************************************************************************

3.1.6从创建虚机流程看nova子服务如何协同工作

1.客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”

2.API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”

3.Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A

4.Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”

5.计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。

6.在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

在前面创建虚机的流程示意图中，我们看到 nova-* 子服务之间的调用严重依赖 Messaging。Messaging 是 nova-* 子服务交互的中枢。

以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler，或是让Scheuler 直接调用 Compute，而是非要通过 Messaging 进行中转。这里做一些解释。程序之间的调用通常分两种：同步调用和异步调用。
同步调用

API 直接调用 Scheduler 的接口是同步调用。其特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续做后面的工作。

异步调用

API 通过 Messaging 间接调用 Scheduler 就是异步调用。其特点是 API 发出请求后不需要等待，直接返回，继续做后面的工作。 Scheduler 从 Messaging 接收到请求后执行调度操作，完成后将结果也通过 Messaging 发送给 API。在 OpenStack 这类分布式系统中，通常采用异步调用的方式，其好处是：

1.解耦各子服务。子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。

2.提高性能异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。

3.提高伸缩性子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。

********************************************************************************************************************************************

3.1.7实现 instance 生命周期的管理

nova-compute 创建 instance 的过程可以分为 4 步：

(1).为 instance 准备资源

(2).创建 instance 的镜像文件

(3).创建 instance 的 XML 定义文件

(4).创建虚拟网络并启动虚拟机

********************************************************************************************************************************************

3.1.8Nova 创建虚拟机详细过程

1.界面或命令行通过RESTful API向keystone获取认证信息。

2、keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。

3、界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。

4、nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。

5、keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。

6、通过认证后nova-api和数据库通讯。

7、初始化新建虚拟机的数据库记录。

8、nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。

9、nova-scheduler进程侦听消息队列，获取nova-api的请求。

10、nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。

11、对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。

12、nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。

13、nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。

14、nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）

15、nova-conductor从消息队队列中拿到nova-compute请求消息。

16、nova-conductor根据消息查询虚拟机对应的信息。

17、nova-conductor从数据库中获得虚拟机对应信息。

18、nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。

19、nova-compute从对应的消息队列中获取虚拟机信息消息。

20、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。

21、glance-api向keystone认证token是否有效，并返回验证结果。

22、token验证通过，nova-compute获得虚拟机镜像信息(URL)。

23、nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。

24、neutron-server向keystone认证token是否有效，并返回验证结果。

25、token验证通过，nova-compute获得虚拟机网络信息。

26、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。

27、cinder-api向keystone认证token是否有效，并返回验证结果。

28、token验证通过，nova-compute获得虚拟机持久化存储信息。

29、nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

********************************************************************************************************************************************

3.2 Cinder

块存储cinder服务是openstack中的一个核心项目，它为OpenStack中的实例提供持久的存储，块存储提供一个基础设施，用于管理卷以及和OpenStack计算服务交互，为实例提供卷、快照、卷类型等功能。

3.2.1Cinder逻辑架构

3.2.2Cinder重要组件

inder-api

用来接收API请求，并将其路由到cinder-volume执行

Cinder-volume

用来与cinder-scheduler进程进行直接交互，也可以与这些进程通过消息队列进行交互，cinder-volume是最终干活的

Cinder-scheduler

它会选择最优存储节点来创建卷，工作机制类似于nova-scheduler

cinder-backup

一种备份，cinder提供了三种驱动服务：ceph，tsm和swift（默认）

Messaging queue

在块存储服务之间传递消息，块存储服务和计算节点交互来为VM提供volume

Back-end Storage Devices

后端存储设备，默认采用本地LVM VG。此外，Cinder还支持很多种存储

Users和Tenants (Projects)

我的理解是这里也是基于Keystone的权限控制。对于租户而言，cinder quota控制可以做如下限制：创建volume的数量、创建快照的数量、每个租户总空间（volume和快照分享）。用户有权使用哪些volume是通过租户来限制的。控制硬件资源quota是对每个租户启用的，而授予vomle访问权限的key pairs是对单个用户启用的

Database Cinder

有一些数据需要存放到数据库中，一般使用 MySQL。数据库是安装在控制节点上。

3.2.3Cinder常用管理命令

创建卷类型：cinder type-create rbd#rbd是云硬盘类型名称，可自行定义

查询卷类型：cinder type-list

创建卷：cinder create 2 --name disk-01 --volume-type rbd

查询云硬盘：cinder list

查看云硬盘具体信息：cinder show <volume_name>

3.2.4从volume创建流程看cinder子服务如何协同工作

1.客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（cinder-api）发送请求：“帮我创建一个 volume”；

2.API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个 volume”

3.Scheduler（cinder-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计存储点中选出节点 A

4.Scheduler 向 Messaging 发送了一条消息：“让存储节点 A 创建这个 volume”

5.存储节点 A 的 Volume（cinder-volume）从 Messaging 中获取到 Scheduler 发给它的消息，然后通过 driver 在 volume provider 上创建 volume。

3.2.5数据持久化

如果您想创建一个使用临时存储的实例，意味着当实例被删除时数据会丢失，那么从以下启动项中选择一个：

镜像:本选项使用一个镜像启动实例。

实例快照:此选项使用一个实例快照来启动实例。

如果您想创建一个使用持久存储的实例，意味着当实例被删除时数据被保存，那么选择从以下启动项中选择一个

镜像（带有选中“创建新卷”）：此选项使用镜像来启动实例，并且创建一个新卷来持久化实例数据。您可以指定卷大小并指定在删除实例时是否删除实例。

卷：这个选项使用一个已存在的卷。它不创建新卷。您可以选择在删除实例时删除卷。注意：当选择卷时，您只能启动一个实例。

卷快照：此选项使用卷快照启动实例，并且创建一个新卷来持久化实例数据。您可以选择在删除实例时删除卷

3.3Neutron

如何快速响应业务的需求对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作，而“软件定义网络（software-defined networking, SDN）”所具有的灵活性和自动化优势使其成为云时代网络管理的主流。Neutron 的设计目标是实现“网络即服务（Networking as a Service）”。为了达到这一目标，在设计上遵循了基于 SDN 实现网络虚拟化的原则，在实现上充分利用了 Linux 系统上的各种网络相关的技术。SDN 模式服务— NeutronSDN( 软件定义网络 ), 通过使用它，网络管理员和云计算操作员可以通过程序来动态定义虚拟网络设备。Openstack 网络中的 SDN 组件就是 Quantum.但因为版权问题而改名为Neutron 。

3.3.1Neutron网络基本概念

1.network

network 是一个隔离的二层广播域。Neutron 支持多种类型的 network，包括 local, flat, VLAN, VxLAN 和 GRE。

local
local 网络与其他网络和节点隔离。local 网络中的 instance 只能与位于同一节点上同一网络的 instance 通信，local 网络主要用于单机测试。

flat
flat 网络是无 vlan tagging 的网络。flat 网络中的 instance 能与位于同一网络的 instance 通信，并且可以跨多个节点。

vlan
vlan 网络是具有 802.1q tagging 的网络。vlan 是一个二层的广播域，同一 vlan 中的 instance 可以通信，不同 vlan 只能通过 router 通信。vlan 网络可跨节点，是应用最广泛的网络类型。

vxlan
vxlan 是基于隧道技术的 overlay 网络。vxlan 网络通过唯一的 segmentation ID（也叫 VNI）与其他 vxlan 网络区分。vxlan 中数据包会通过 VNI 封装成 UDP 包进行传输。因为二层的包通过封装在三层传输，能够克服 vlan 和物理网络基础设施的限制。

gre
gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。

不同 network 之间在二层上是隔离的。以 vlan 网络为例，network A 和 network B 会分配不同的 VLAN ID，这样就保证了 network A 中的广播包不会跑到 network B 中。当然，这里的隔离是指二层上的隔离，借助路由器不同 network 是可能在三层上通信的。network 必须属于某个 Project（ Tenant 租户），Project 中可以创建多个 network。 network 与 Project 之间是 1对多关系。

********************************************************************************************************************************************

2.subnet

subnet 是一个 IPv4 或者 IPv6 地址段。instance 的 IP 从 subnet 中分配。每个 subnet 需要定义 IP 地址的范围和掩码。

network 与 subnet 是 1对多关系。一个 subnet 只能属于某个 network；一个 network 可以有多个 subnet，这些 subnet 可以是不同的 IP 段，但不能重叠。下面的配置是有效的：

network A
subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
subnet A-b: 10.10.2.0/24 {“start”: “10.10.2.1”, “end”: “10.10.2.50”}

但下面的配置则无效，因为 subnet 有重叠

network A
subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
subnet A-b: 10.10.1.0/24 {“start”: “10.10.1.51”, “end”: “10.10.1.100”}

这里不是判断 IP 是否有重叠，而是 subnet 的 CIDR 重叠（都是 10.10.1.0/24）。但是，如果 subnet 在不同的 network 中，CIDR 和 IP 都是可以重叠的，比如

network A subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
network B subnet B-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}

这里大家不免会疑惑：如果上面的IP地址是可以重叠的，那么就可能存在具有相同 IP 的两个 instance，这样会不会冲突？简单的回答是：不会！

具体原因：因为 Neutron 的 router 是通过 Linux network namespace 实现的。network namespace 是一种网络的隔离机制。通过它，每个 router 有自己独立的路由表。上面的配置有两种结果：

如果两个 subnet 是通过同一个 router 路由，根据 router 的配置，只有指定的一个 subnet 可被路由。

如果上面的两个 subnet 是通过不同 router 路由，因为 router 的路由表是独立的，所以两个 subnet 都可以被路由。

********************************************************************************************************************************************

3.port

port 可以看做虚拟交换机上的一个端口。port 上定义了 MAC 地址和 IP 地址，当 instance 的虚拟网卡 VIF（Virtual Interface）绑定到 port 时，port 会将 MAC 和 IP 分配给 VIF。

subnet 与 port 是 1对多关系。一个 port 必须属于某个 subnet；一个 subnet 可以有多个 port。

3.3.2Neutron逻辑架构

与 OpenStack 的其他服务的设计思路一样，Neutron 也是采用分布式架构，由多个组件（子服务）共同对外提供网络服务。

Neutron 由如下组件构成：

Neutron Server
对外提供 OpenStack 网络 API，接收请求，并调用 Plugin 处理请求。

Plugin
处理 Neutron Server 发来的请求，维护 OpenStack 逻辑网络状态，并调用 Agent 处理请求。

Agent
处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能。

network provider
提供网络服务的虚拟或物理网络设备，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交换机。

Queue
Neutron Server，Plugin 和 Agent 之间通过 Messaging Queue 通信和调用。

Database
存放 OpenStack 的网络状态信息，包括 Network, Subnet, Port, Router 等。

Neutron 架构非常灵活，层次较多，目的是：

1.为了支持各种现有或者将来会出现的优秀网络技术。

2.支持分布式部署，获得足够的扩展性。

以创建一个 VLAN100 的 network 为例，假设 network provider 是 linux bridge，流程如下：

Neutron Server 接收到创建 network 的请求，通过 Message Queue（RabbitMQ）通知已注册的 Linux Bridge Plugin。

Plugin 将要创建的 network 的信息（例如名称、VLAN ID等）保存到数据库中，并通过 Message Queue 通知运行在各节点上的 Agent。

Agent 收到消息后会在节点上的物理网卡（比如 eth2）上创建 VLAN 设备（比如 eth2.100），并创建 bridge （比如 brqXXX）桥接 VLAN 设备。

plugin 解决的是 What 的问题，即网络要配置成什么样子？而至于如何配置 How 的工作则交由 agent 完成。

plugin，agent 和 network provider 是配套使用的，比如上例中 network provider 是 linux bridge，那么就得使用 linux bridge 的 plungin 和 agent；如果 network provider 换成了 OVS 或者物理交换机，plugin 和 agent 也得替换。

plugin 的一个主要的职责是在数据库中维护 Neutron 网络的状态信息，这就造成一个问题：所有 network provider 的 plugin 都要编写一套非常类似的数据库访问代码。为了解决这个问题，Neutron 在 Havana 版本实现了一个 ML2（Modular Layer 2）plugin，对 plgin 的功能进行抽象和封装。有了 ML2 plugin，各种 network provider 无需开发自己的 plugin，只需要针对 ML2 开发相应的 driver 就可以了，工作量和难度都大大减少。ML2 会在后面详细讨论。

plugin 按照功能分为两类： core plugin 和 service plugin。core plugin 维护 Neutron 的 netowrk, subnet 和 port 相关资源的信息，与 core plugin 对应的 agent 包括 linux bridge, OVS 等； service plugin 提供 routing, firewall, load balance 等服务，也有相应的 agent。

【华为云学院】OpenStack原理及在华为云中的应用---知识总结相关推荐

【技术干货+限时活动】openstack原理及在华为云中的应用
五一小假提前放送,实力干货课程,讲清openstack原理及在华为云中的应用,一门路过别错过的课程!免费学习参加限时活动,评论课程,智能音响体脂秤领回家!快戳:http://u6.gg/sxHV5 转 ...
听说你还在为海量数据构建不同数据仓库？华为云学院 DataLake了解一下！
听说你还在为海量数据构建不同数据仓库?华为云学院 DataLake了解一下! By: FYS_CMSS 的CSDN 博客 "A data lake is a method of storin ...
11.11即将到来，华为云学院精品课程免费推荐奉上
一年一度的剁手季,钱包已经空空了,大家都疯狂物质消费的时候,是不是该来点精神满足? 一年一度的光棍节,近看身旁无人陪,大家都约会而你苦于一人的时候,是不是该来点精神陪伴? 11.11剁完手不剁手约完会 ...
华为云学院干货：服务创新大舞台在这里！
华为云学院干货:服务创新大舞台在这里! Service Stage--一站式微服务云应用DevOps平台.新时代带来新机遇,同时企业IT系统也面临前所未有的挑战.伴随传统业务云化,海量用户进入,访问量 ...
华为云学院新春大礼包：场景化微认证上新了！ 1
自从华为云微认证上线以来,微认证便受到了广大开发者欢迎.华为云微认证是华为云场景化的技能认证,紧贴前沿科技,覆盖云计算.大数据.物联网.人工智能等热门领域,面向ICT技术爱好者.高校学生,提供场景化的 ...
华为云IoT智慧物流案例11 | 华为云FOTA升级广和通L610模组
华为云IoT智慧物流案例11 | 华为云FOTA升级广和通L610模组一. 创建华为云平台L610产品与设备二.AT指令连接华为云IoT平台且测试三.IoT平台配置FOTA升级一. 创建华为云 ...
华为云IoT智慧物流案例06 | 华为云设备创建与接入及MQTT.fx测试
华为云IoT智慧物流案例06 | 华为云设备创建与接入及MQTT.fx测试第一章华为云设备创建与接入第二章 MQTT.fx进行MQTT测试第一章华为云设备创建与接入 1.创建产品 2.自定义 ...
云现场 | 把开发者宠上天的节奏？恐怕也只有华为云啦！——记首次探访华为云“一日游...
戳蓝字"CSDN云计算"关注我们哦! 作者:刘晶晶不久之前,华为云首次举行媒体开放日,也是小编第一次探访传说中的华为总部,并同时感受坂田园区与松山湖园区截然不同的奇特,先上几张照 ...
华为鸿蒙主题曲,【AVW分享】华为云《鲲鹏》主题曲，华为宣传片MV剪辑版，超级带感的音乐...
[分享交流] [AVW分享]华为云<鲲鹏>主题曲,华为宣传片MV剪辑版,超级带感的音乐 8540150 电梯直达 BH8AVW 花粉版主发表于 2020-3-30 09:46:20 来自 ...
把开发者宠上天的节奏？恐怕也只有华为云啦！——记首次探访华为云“一日游”
不久之前,华为云首次举行媒体开放日,也是小编第一次探访传说中的华为总部,并同时感受坂田园区与松山湖园区截然不同的奇特,先上几张照片领略下吧! 绵绵细雨.逼真城堡.亲人的黑天鹅--一路走来,遍赏美景,不 ...

【华为云学院】OpenStack原理及在华为云中的应用---知识总结

前言

第一章什么是OpenStack

第二章 Openstack组件

第三章部分组件介绍