29.OpenStack对象存储-Swift、编排管理-heat及网络管理-neutron

2301_78732849

940人浏览 · 2025-11-04 18:53:38

2301_78732849 · 2025-11-04 18:53:38 发布

OpenStack对象存储-Swift

swift在openstack中的作用

在这里插入图片描述

Swift并不是文件系统或者实时的数据存储系统，它称为对象存储，用于永久类型的静态数据的长期存储，这些数据可以检索、调整，必要时进行更新
最适合存储的数据类型的例子是虚拟机镜像、图片存储、邮件存储和存档备份
因为没有中心单元或主控结点，Swift提供了更强的扩展性、冗余和持久性

使用命令swift stat可以显示Swift中的帐户、容器和对象的信息。

Swift为帐户，容器和对象分别定义了Ring（环）将虚拟节点（分区）映射到一组物理存储设备上，包括Account Ring、 Container Ring 、 Object Ring。

Ring记录了存储对象与物理位置的映射关系，通过Zone、 Device、 Partition和Replica来维护映射信息。

在这里插入图片描述

Swift实验

在这里插入图片描述

控制节点新添加一块20GB磁盘

新添磁盘分成两个区，并格式化

分区一：挂载到obs1目录

分区二：挂载到obs2目录

[root@controller ~ 15:38:44]# fdisk /dev/sdb

Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xf29be5d0.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-41943039, default 2048): 
Last sector, +sectors or +size{K,M,G,T,P} (2048-41943039, default 41943039): +10G

Created a new partition 1 of type 'Linux' and of size 10 GiB.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (20973568-41943039, default 20973568): 
Last sector, +sectors or +size{K,M,G,T,P} (20973568-41943039, default 41943039): 

Created a new partition 2 of type 'Linux' and of size 10 GiB.

Command (m for help): p
Disk /dev/sdb: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf29be5d0

Device     Boot    Start      End  Sectors Size Id Type
/dev/sdb1           2048 20973567 20971520  10G 83 Linux
/dev/sdb2       20973568 41943039 20969472  10G 83 Linux

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

# 将两个分区格式化为xfs格式
[root@controller ~ 15:40:04]# mkfs.xfs /dev/sdb1
[root@controller ~ 15:40:20]# mkfs.xfs /dev/sdb2

# 下面为默认挂给swift的虚拟设备分区，将其卸载
[root@controller ~ 15:40:27]# lsblk
NAME                                            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0                                             7:0    0     2G  0 loop /srv/node/swiftloopback
......
[root@controller ~ 15:40:32]# umount /srv/node/swiftloopback

#切换到swift目录
[root@controller ~ 15:40:56]# cd /srv/node
[root@controller node 15:41:06]# ls
swiftloopback
[root@controller node 15:41:08]# rm -rf swiftloopback/

#创建新的挂载目录，分别挂载sdb1,sbd2
[root@controller node 15:41:27]# mkdir obs1 obs2
[root@controller node 15:41:37]# vim /etc/fstab 
# 注释该行
#/srv/loopback-device/swiftloopback /srv/node/swiftloopback ext4 noatime,nodiratime,nofail,loop,user_xattr 0 0
# 添加
/dev/sdb1 /srv/node/obs1 xfs defaults 0 0
/dev/sdb2 /srv/node/obs2 xfs defaults 0 0

[root@controller node 15:43:41]# mount -a
[root@controller node 15:43:45]# df
......
/dev/sdb1            10475520  106088  10369432   2% /srv/node/obs1
/dev/sdb2            10474496  106088  10368408   2% /srv/node/obs2

修改obs1目录和obs2目录权限

[root@controller node 15:43:49]# chown swift:swift obs1
[root@controller node 15:44:10]# chown swift:swift obs2
[root@controller node 15:44:16]# ll
total 0
drwxr-xr-x 2 swift swift 6 Oct 30 15:40 obs1
drwxr-xr-x 2 swift swift 6 Oct 30 15:40 obs2

创建swfit ring：

[root@controller node 15:44:18]# cd /etc/swift/
[root@controller swift 15:44:30]# ls
account.builder      backups                    container-server       object-expirer.conf  proxy-server
account.ring.gz      container.builder          container-server.conf  object.ring.gz       proxy-server.conf
account-server       container-reconciler.conf  internal-client.conf   object-server        swift.conf
account-server.conf  container.ring.gz          object.builder         object-server.conf
[root@controller swift 15:44:32]# swift-ring-builder container.builder create --help
swift-ring-builder <builder_file> create <part_power> <replicas>
                                         <min_part_hours>
    Creates <builder_file> with 2^<part_power> partitions and <replicas>.
    <min_part_hours> is number of hours to restrict moving a partition more
    than once.
[root@controller swift 15:45:09]# swift-ring-builder container.builder create 12 2 1
[root@controller swift 15:45:39]# swift-ring-builder account.builder create 12 2 1
[root@controller swift 15:45:52]# swift-ring-builder object.builder create 12 2 1
#12表示ring分区数量为2^12
#2表示2个副本
#1表示最少1个小时后才能更改ring配置

创建ring映射关系：

#查看配置文件，分别查看account,container，obeject的bind_port记录下来
[root@controller swift 15:46:05]# cat account-server.conf |grep bind_port
bind_port = 6002
[root@controller swift 15:46:39]# cat container-server.conf |grep bind_port
bind_port = 6001
[root@controller swift 15:46:55]# cat object-server.conf |grep bind_port
bind_port = 6000

[root@controller swift 15:47:19]# swift-ring-builder account.builder add z1-192.168.108.10:6002/obs1 100
WARNING: No region specified for z1-192.168.108.10:6002/obs1. Defaulting to region 1.
Device d0r1z1-192.168.108.10:6002R192.168.108.10:6002/obs1_"" with 100.0 weight got id 0
[root@controller swift 15:47:55]# swift-ring-builder account.builder add z2-192.168.108.10:6002/obs2 100
[root@controller swift 15:48:38]# swift-ring-builder container.builder add z1-192.168.108.10:6001/obs1 100
[root@controller swift 15:49:13]# swift-ring-builder container.builder add z2-192.168.108.10:6001/obs2 100
[root@controller swift 15:49:41]# swift-ring-builder object.builder add z1-192.168.108.10:6000/obs1 100
[root@controller swift 15:50:04]# swift-ring-builder object.builder add z2-192.168.108.10:6000/obs2 100

再平衡：

[root@controller swift 15:50:15]# swift-ring-builder account.builder rebalance
Reassigned 8192 (200.00%) partitions. Balance is now 0.00.  Dispersion is now 0.00
[root@controller swift 15:50:52]# swift-ring-builder container.builder rebalance
Reassigned 8192 (200.00%) partitions. Balance is now 0.00.  Dispersion is now 0.00
[root@controller swift 15:51:07]# swift-ring-builder object.builder rebalance
Reassigned 8192 (200.00%) partitions. Balance is now 0.00.  Dispersion is now 0.00

在这里插入图片描述

#刚才上传的文件，2副本，分别在obs1目录，obs2目录各存了一份
[root@controller swift 15:51:16]# find /srv/node -name *data
/srv/node/obs1/objects/1133/ef1/46d1222599af4619df08926127bc9ef1/1761810747.73808.data
/srv/node/obs2/objects/1133/ef1/46d1222599af4619df08926127bc9ef1/1761810747.73808.data

OpenStack编排管理-heat

heat作用

Heat是一种通过OpenStack原生REST API使用声明性模板格式编排复合云应用程序的服务，提供与其他OpenStack核心项目的紧密集成

Heat模板以文本文件的形式描述了云应用程序的基础架构，文本文件可供用户读写，并且支持通过版本控制工具进行管理
Heat模板指定资源之间的关系，使得Heat能够调用OpenStack API以正确的顺序创建用户所需的基础架构，从而完全启动用户的应用程序

heat与其他服务之间的关系

在这里插入图片描述

Heat是位于Nova、Neutron等服务之上的一个组件，它充当了OpenStack对外接口的角色，用户不需要直接接触OpenStack其他服务，只需把对各种资源的需求写在Heat模版里，Heat就会自动调用相关服务的接口来配置资源，从而满足用户的需求

heat架构

在这里插入图片描述

用户在Horizon中或者命令行中提交包含模板和参数输入的请求，Horizon或者命令行工具会把请求转化为REST格式的API调用，然后调用Heat-api或者是Heat-api-cfn。Heat-api 和Heat-api-cfn会验证模板的正确性，然后通过消息队列传递给Heat Engine来处理请求。
Heat中的模板是OpenStack资源的集合（虚拟机、网络、存储、告警、浮动IP、安全组、伸缩组、嵌套stack等），通过定义模板，可以将需要创建的资源在模板中描述，用此模板可以多次创建需要的资源。

heat组件

在这里插入图片描述

Heat-api：提供REST API服务，是其他组件与Heat交互的入口，接收API请求并传送给heat-engine。
Heat-api-cfn：提供兼容AWS CloudFormation的API，接收API请求并转发给heat-engine。
Heat-engine：Heat的核心，主要实现任务调度、资源生命周期管理等作用，自身并不提供资源创建功能，只负责编排资源后交由其他组件去处理

heat engine架构

在这里插入图片描述

heat模板

在这里插入图片描述

Heat模板默认编写语言-YAML语法

YAML Ain’t Markup Language
使用缩进（一个或多个空格）排版
序列项用短划线表示
MAP中的key-value对用冒号表示

heat模板结构

在这里插入图片描述

OpenStack网络管理-neutron

物理网络与虚拟网络区别

在这里插入图片描述

Switch：物理交换机

vSwitch：虚拟交换机

NIC：网络接口卡、网络适配器、网卡

vNIC：虚拟网卡

Switch有很多品牌：cisco、华为

vSwitch有很多软件：linuxbridge、ovs、ovn

Neutron最为核心的工作是对二层物理网络的抽象与管理，物理服务器虚拟化后，虚拟机的网络功能由虚拟网卡（vNIC）和虚拟交换机提供，各个vNIC连接在vSwitch的端口上，最后这些vSwitch通过物理服务器的物理网卡访问外部的物理网络。

Linux网络虚拟化技术

网卡虚拟化：

TAP
TUN
VETH PAIR

交换机虚拟化：

linux bridge
open vswitch

网络隔离：

network namespace

Linux网卡虚拟化TAP/TUN/VETH

在这里插入图片描述

TAP设备：模拟一个二层的网络设备，可以接收和发送二层网包

TUN设备：模拟一个三层的网络设备，可以接收和发送三层网包

VETH：虚拟ethernet接口，通常以pair的方式出现，一端发出的网包，会被另一端接收，可以形成两个网桥之间的通道

TAP/TUN提供了一台主机内用户空间的数据传输机制。它虚拟了一套网络接口，这套接口和物理的接口无任何区别，可以配置IP，可以路由流量，不同的是，它的流量只在主机内流通。
TAP/TUN有些许的不同，TUN只操作三层的IP包，而TAP操作二层的以太网帧。
Veth-Pair是成对出现的一种虚拟网络设备，一端连接着协议栈，一端连接着彼此，数据从一端出，从另一端进。它的这个特性常常用来连接不同的虚拟网络组件，构建大规模的虚拟网络拓扑，比如连接LinuxBridge、OVS、LXC容器等。一个很常见的案例就是它被用于OpenStack Neutron，构建非常复杂的网络形态。

Linux bridge

在这里插入图片描述

Linux bridge：工作于二层的网络设备，功能类似于物理交换机

Bridge可以绑定Linux上的其他网络设备，并将这些设备虚拟化为端口

当一个设备被绑定到bridge时，就相当于物理交换机端口插入了一条连接着终端的网线

使用brctl命令配置Linux bridge：

brctl addbr BRIDGE

brctl addif BRIDGE DEVICE

Linux Bridge结构如上图所示，Bridge设备br0绑定了实际设备eth0与虚拟设备tap0和tap1，但是对于Hypervisor的网络协议栈上层来说，只能看到br0，并不会关心桥接的细节。
当这些设备接收到数据包时，会将其提交给br0决定数据包的去向，br0会根据MAC地址与端口的映射关系进行转发。
因为Bridge工作在二层，所以绑定在br0上的从设备eth0、tap0与tap1均不需要再设置IP地址，对于上层路由器来说，它们都位于同一子网，因此只需为br0设置IP地址。因为br0具有自己的IP地址，br0可以被加入路由表，并利用它来发送数据，但是最终实际的发送过程则是由某个从设备来完成。
即使eth0原本具有自己的IP地址，但是在被绑定到br0上后，它的IP地址会失效，用户程序不能接收到这个IP地址的数据。只有目的地址为br0的IP地址的数据包才会被Linux接收。
brctl addbr BRIDGE：表示添加BRIDGE。
brctl addif BRIDGE DEVICE：表示添加接口到bridge。

OVS

在这里插入图片描述

Open vSwitch是产品级的虚拟交换机

Linux bridge更适用于小规模，主机内部间通信场景

Open vSwitch更适合于大规模、多主机间通信场景

华为的FusionCompute用的就是DVS(基于EVS，EVS基于OVS)

Open vSwitch常用的命令：

ovs-vsctl add-br BRIDGE
ovs-vsctl add-port PORT
ovs-vsctl show BRIDGE
ovs-vsctl dump-ports-desc BRIDGE
ovs-vsctl dump-flows BRIDGE

•Open vSwitch负责连接vNIC与物理网卡，同时桥接同一物理Server内的各个vNIC。其实Linux Bridge已经能够很好地充当这样的角色，为什么我们还需要Open vSwitch？

•因为Open vSwitch的引入使得云环境中对虚拟网络的管理及对网络状态和流量的监控变得更容易。

•我们可以像配置物理交换机一样，将接入Open vSwitch的各个VM分配到不同的VLAN中以实现网络的隔离。我们也可以在Open vSwitch端口上为VM配置QoS，同时Open vSwitch也支持包括NetFlow、sFlow等很多标准的管理接口和协议，我们可以通过这些接口完成流量监控等工作。

•Open vSwitch在云环境中的各种虚拟化平台（如Xen与KVM）上实现了分布式的虚拟交换机（Distributed Virtual Switch），一个物理Server上的vSwitch可以透明地与另一个物理Server上的vSwitch连接在一起。

Neutron功能概述

Neutron 的难度会比前面所有模块都大一些，内容也多一些。为了帮助大家更好的掌握 Neutorn，也会分析地更详细一些。

Neutron概述

传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备；而云环境下的网络已经变得非常复杂，特别是在多租户场景里，用户随时都可能需要创建、修改和删除网络，网络的连通性和隔离不已经太可能通过手工配置来保证了。

如何快速响应业务的需求对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作，而“软件定义网络（software-defined networking, SDN）”所具有的灵活性和自动化优势使其成为云时代网络管理的主流。

Neutron 的设计目标是实现“网络即服务（Networking as a Service）”。为了达到这一目标，在设计上遵循了基于 SDN 实现网络虚拟化的原则，在实现上充分利用了 Linux 系统上的各种网络相关的技术。在这一章，我们将讨论 Neutron 的功能和它的各个组件，学习部署和配置 OpenStack 网络的不同方法，会涉及软件和硬件设备多个层面。

Neutron功能

Neutron 为整个 OpenStack 环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和 VPN

等。Neutron 提供了一个灵活的框架，通过配置，无论是开源还是商业软件都可以被用来实现这些功

能。

二层交换Switching

Nova 的 Instance 是通过虚拟交换机连接到虚拟二层网络的。Neutron 支持多种虚拟交换机，包括Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。

利用 Linux Bridge 和 OVS，Neutron 除了可以创建传统的 VLAN 网络，还可以创建基于隧道技术的Overlay 网络，比如 VxLAN 和 GRE（Linux Bridge 目前只支持 VxLAN）。在后面章节我们会学习如何使用和配置 Linux Bridge 和 Open vSwitch

三层路由Routing

Instance 可以配置不同网段的 IP，Neutron 的 router（虚拟路由器）实现 instance 跨网段通信。router 通过 IP forwarding，iptables 等技术来实现路由和 NAT。我们将在后面章节讨论如何在Neutron 中配置 router 来实现 instance 之间，以及与外部网络的通信。

负载均衡 Load Balancing

Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service（LBaaS），提供了将负载分发到多个 instance 的能力。LBaaS 支持多种负载均衡产品和方案，不同的实现以 Plugin 的形式集成到Neutron，目前默认的 Plugin 是 HAProxy。我们会在后面章节学习 LBaaS 的使用和配置。

防火墙 Firewalling

Neutron 通过下面两种方式来保障 instance 和网络的安全性。

Security Group

通过 iptables 限制进出 instance 的网络包。

Firewall-as-a-Service

FWaaS，限制进出虚拟路由器的网络包，也是通过 iptables 实现

Neutron功能概述

上次我们讨论了 Neutron 提供的功能，接下来我们学习 Neutron 模块几个重要的概念。Neutron 管理的网络资源包括 Network，subnet 和 port，下面依次介绍。

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。Project 与network 之间是 1对多关系。

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 有重叠

networkA 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”}

networkB 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 都可以被路由。

这里只是先简单做个说明，我们会在后面三层路由的章节详细分析这种场景。

port

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

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

Neutron架构

前面我们讨论了 Neutron 的基本概念，接下来我们开始分析 Neutron 的架构。

Neutron 架构

与 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 也是采用分布式架构，由多个组件（子服务）共同对外提供网络服务。

[外链图片转存中…(img-f6NGugC7-1762253013399)]

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 等。

AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

深入理解 AI Agent 02｜混合检索与重排序实战：BM25、RRF 与 Cross-Encoder 的工程实践

AI Agent技术社区

多Agent协作平台怎么选？2026年主流AI Agent协作平台盘点

AI Agent技术社区

开源项目第172期：agentOS — 以库的形式给 AI Agent 一个操作系统，冷启动 92x 更快、内存 47x 更少

AI Agent技术社区

所有评论(0)

查看更多评论

2301_78732849

@2301_78732849

已为社区贡献3条内容

29.OpenStack对象存储-Swift、编排管理-heat及网络管理-neutron

2301_78732849

文章目录

OpenStack对象存储-Swift

swift在openstack中的作用

Swift实验

OpenStack编排管理-heat

heat作用

heat与其他服务之间的关系

heat架构

heat组件

heat engine架构

heat模板

Heat模板默认编写语言-YAML语法

heat模板结构

OpenStack网络管理-neutron

物理网络与虚拟网络区别

Linux网络虚拟化技术

Linux网卡虚拟化TAP/TUN/VETH

Linux bridge

OVS

Neutron功能概述

Neutron概述

Neutron功能

二层交换Switching

三层路由Routing

Neutron功能概述

network

local

flat

vlan

vxlan

gre

subnet

port

Neutron架构

Neutron 架构

所有评论(0)

温馨提示：您尚未绑定手机号

2301_78732849