OpenStack零基础入门：云管理操作系统的核心原理与实战

1
2
3
4
5

"虚拟机会了，Docker也会了，
  但企业里真正跑业务的云平台是什么？
  OpenStack听起来很厉害，但一打开官方文档，
  十几种服务（Nova、Neutron、Cinder、Glance……）
  完全不知道从哪下手。"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

VMware的作用：
  → 在一台物理服务器上虚拟出多台虚拟机
  → 解决的是"一台物理机怎么变成多台用"的问题
  → 工具是VMware ESXi / vSphere

OpenStack的作用：
  → 把整个数据中心的所有物理资源（计算/存储/网络）统一管理
  → 向上层用户提供"按需申请"的资源服务
  → 解决的是"数据中心怎么像一台计算机一样被按需使用"的问题
  → 工具是OpenStack（一个分布式软件平台）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

传统数据中心 = 一家没有接待台、没有预约系统的酒店
  → 客人（应用）来了，要自己找房间、自己通水电、自己铺床
  → 没有标准化，没有自动化

VMware虚拟化 = 酒店有了前台
  → 可以分配房间（虚拟机）了
  → 但客人还是要自己布置房间

OpenStack = 酒店的完整智能化系统
  → 接待台自动分配房间（计算资源）
  → 房间里的水电按需供应（弹性伸缩）
  → 订房、退房全部自动化（API接口）
  → 酒店根据入住率自动开关楼层（资源调度）
  → 客人不需要知道酒店有多少房间、哪台空调在哪层

1
2
3
4
5

OpenStack官方定义：
  "OpenStack是一个云操作系统，
   控制整个数据中心的大量计算、存储和网络资源，
   通过一个仪表盘统一管理，
   同时提供一套API供外部程序调用。"

1
2
3

关键词1：控制 → 不自己跑业务，而是管理别人
关键词2：资源池 → 把分散的物理资源整合成统一的池
关键词3：API → 所有操作都可以通过编程接口调用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

商业云 vs OpenStack开源云：

商业云（AWS/阿里云）：
  → 技术栈不透明（你不知道底层怎么实现的）
  → 定价权在服务商（说涨价就涨价）
  → 迁移成本高（被绑定）
  → 数据在自己服务器上（合规性好，适合金融/政务）

OpenStack开源云：
  → 技术栈完全透明（代码都在GitHub上）
  → 任何公司都可以免费使用和修改
  → 不被单一厂商绑定（可以用华为的插件，也可以用红帽的）
  → 适合企业自建私有云（政务云、金融云、科研云）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

类比：安卓手机 vs 苹果手机

苹果（iOS）：
  → 所有组件（相机/相册/短信/浏览器）都是苹果自己的
  → 高度整合，但你想换一个相机应用？没门
  → 苹果说用什么，就用什么

安卓（Android）：
  → 相机可以用Google Camera，也可以用小米相机
  → 短信可以用系统默认，也可以换成QQ邮箱
  → 自由度高，但碎片化问题严重

OpenStack的做法：
  → 相机的接口是统一的（标准API）
  → 但相机本身可以是华为写的，也可以是红帽写的
  → 保证了自由度的同时，又不至于碎片化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

OpenStack核心组件记忆法："KNGNC"（凯恩尼克）

K - Keystone   （认证服务）
N - Neutron    （网络服务）
G - Glance     （镜像服务）
N - Nova       （计算服务）
C - Cinder     （块存储服务）

加上一个界面：
  Horizon      （Web管理界面）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

顾客（用户）
    ↓
迎宾台（Horizon Web界面 / OpenStack API）
    ↓
┌──────────────────────────────────────────┐
│           OpenStack 云平台                │
│                                          │
│  [Keystone]  ←→  "你的身份证有效吗？"   │
│                                          │
│  [Glance]    ←→  "今天供应什么菜品？"   │
│                                          │
│  [Nova]      ←→  "你的餐盘在哪？"       │
│                                          │
│  [Neutron]   ←→  "菜怎么送到你桌上？"   │
│                                          │
│  [Cinder]    ←→  "你有足够的盘子吗？"   │
│                                          │
└──────────────────────────────────────────┘
    ↓
上菜（云主机实例启动成功）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

小区A（没有门禁）：
  → 任何人可以进入任何楼栋
  → 张三可以进李四家（安全隐患）
  → 王五可以随意使用公共设施
  → 出了问题不知道是谁干的

小区B（有Keystone门禁）：
  → 每个人进门要刷卡
  → 系统记录：谁、什么时候、进了哪栋楼
  → 没有合法身份的人进不来
  → 所有行为都有据可查

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Keystone验证流程：

用户发请求："帮我创建一台云主机"
    ↓
Keystone问两个问题：

问题一：你是谁？（Authentication 认证）
    → 验证用户名和密码（Token机制）
    → 类似于刷身份证，门禁系统查你是否是本小区居民

问题二：你能做什么？（Authorization 授权）
    → 查权限表：普通租户 vs 管理员
    → 普通租户：可以创建2台云主机
    → 管理员：可以创建100台云主机，可以管理所有租户
    → 类似于普通住户卡只能开自家大门，管理员卡可以开所有门

验证通过：
    ↓
Keystone发一张"临时通行证"（Token）
    ↓
用户拿着通行证去Nova（计算服务）申请云主机
    ↓
Nova看到通行证有效，才会执行创建操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

生活中的租户概念：

写字楼租户：
  → A公司租了3楼（租户A）
  → B公司租了5楼（租户B）
  → 两家公司的员工互不相通（物理隔离）
  → 租户A的员工不能进B公司的楼层

OpenStack多租户：
  → A业务部门（租户A）：分配了100核CPU、500GB内存
  → B业务部门（租户B）：分配了50核CPU、200GB内存
  → 两家部门的云主机完全隔离（网络隔离 + 资源隔离）
  → 租户A的云主机绝对访问不到租户B的资源

1
2
3
4
5

镜像（Image）是什么：
  → 类似于装好了操作系统的U盘
  → Windows镜像：装好了Windows Server 2022的完整系统
  → Linux镜像：装好了Ubuntu 22.04的完整系统
  → 你告诉OpenStack"用哪个镜像"，它就会给你一台预装好系统的云主机

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Glance的两大职责：

职责1：存储镜像
  → 大量操作系统镜像文件统一存储在一个地方
  → 支持多种格式：qcow2（最常用）、vhd、vmdk、raw
  → qcow2格式支持"写时复制"（Copy-on-Write），节省存储空间

职责2：提供镜像API
  → 上传镜像、查询镜像、删除镜像
  → 其他服务（Nova）通过API获取镜像
  → 支持镜像版本管理（同一个OS的多个版本）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

qcow2 vs raw（两种镜像格式）：

raw格式（原始镜像）：
  → 镜像文件有多大，占用存储就有多大
  → 例如：Ubuntu 22.04 raw镜像 40GB，你就要占用40GB存储
  → 优点：性能最好
  → 缺点：占用存储，不支持快照

qcow2格式（写时复制镜像）：
  → 基础镜像（base image）只有40GB
  → 但如果有100台云主机，它们共享同一个基础镜像
  → 每台主机新写入的数据才单独占用空间
  → 100台云主机，实际可能只占60GB，而不是4000GB
  → 优点：节省存储空间，支持快照和克隆
  → 缺点：性能略低于raw（约5-10%损耗）
  → 生产环境最常用

1
2
3
4
5
6
7
8
9

Nova的组成部分（每个都是一个独立进程）：

nova-api          → 接收用户请求（创建/删除/查询云主机）
nova-scheduler    → 决策"在哪台物理机上创建"（调度器）
nova-conductor    → 连接数据库，查询和更新数据
nova-compute      → 真正执行创建云主机的进程（在计算节点上）
nova-cert         → 证书服务（X.509证书管理）
nova-consoleauth  → 控制台认证（让你通过浏览器看到云主机界面）
nova-novncproxy   → VNC代理（远程桌面访问）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

用户点击"创建云主机"（通过Horizon界面或API）
    ↓
第1步：nova-api接收请求
    → "用户要创建一台云主机：4核CPU、8GB内存、Ubuntu 22.04"
    → 验证Token是否有效（问Keystone）
    → 验证通过，继续

第2步：nova-api查询数据库
    → 查询镜像信息（Ubuntu 22.04的Glance镜像在哪？）
    → 查询网络信息（这个租户有哪些网络可用？）
    → 查询可用域信息（有哪些计算节点？）

第3步：nova-api请求nova-scheduler调度
    → "这台云主机应该在哪台物理机上创建？"

第4步：nova-scheduler做调度决策
    → 考虑因素：
      ├─ CPU负载：选负载最低的节点
      ├─ 内存：选内存最充裕的节点
      ├─ 可用域：某些云主机要求在特定可用域
      └─ 亲和性/反亲和性：某些服务要分布在不同物理机（防止一台宕机全挂）
    → 决策：选Compute-03节点

第5步：nova-api告诉nova-conductor调度结果
    → "Compute-03节点，请创建这台云主机"

第6步：nova-conductor通过消息队列（RabbitMQ）通知Compute-03

第7步：Compute-03节点的nova-compute收到消息
    → 向Glance下载Ubuntu 22.04镜像
    → 向Neutron申请网络（IP、端口）
    → 向Cinder申请云硬盘（如果需要）

第8步：nova-compute调用Hypervisor（KVM）创建虚拟机
    → KVM读取镜像文件
    → 分配vCPU和内存
    → 配置虚拟网卡
    → 挂载云硬盘
    → 启动虚拟机

第9步：云主机启动成功
    → nova-compute向数据库报告状态：ACTIVE
    → 用户可以在Horizon界面看到云主机状态变为"运行中"

第10步：用户通过VNC或SSH连接云主机
    → nova-novncproxy提供远程桌面访问
    → Neutron配置的浮动IP提供公网访问

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

常用调度算法：

算法1：Chance Scheduler（随机调度）
  → 随机选一台有可用资源的节点
  → 简单，但不智能
  → 适合测试环境

算法2：Filter Scheduler（过滤调度）⭐最常用
  → 第一步过滤（Filter）：排除不符合条件的节点
      ├─ AvailabilityZoneFilter：排除不在指定可用域的节点
      ├─ CoreFilter：排除CPU核心数不足的节点
      ├─ RAMFilter：排除内存不足的节点
      └─ DiskFilter：排除磁盘空间不足的节点
  → 第二步权重（Weighing）：对过滤后的节点按优先级排序
      ├─ 内存优先：选剩余内存最多的节点
      ├─ 负载最低：选当前CPU负载最低的节点
      └─ 最小空闲资源：尽量让所有节点负载均衡

算法3：Filters调度顺序（生产环境典型配置）
  RetryFilter → AvailabilityZoneFilter → ComputeFilter
      → ComputeCapabilitiesFilter → ImagePropertiesFilter → ServerGroupAntiAffinityFilter

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

现实生活中的网络需求：

需求A：公司内部通信
  → 市场部的人要和财务部的人互相通信
  → 但不能让竞争对手通过互联网访问公司内部

需求B：对外提供服务
  → 公司的网站需要被公网用户访问
  → 但不能让公网用户访问公司内部其他系统

需求C：隔离
  → 财务部的数据不能被其他部门看到
  → 不同项目组之间的网络要隔离

需求D：弹性
  → 业务高峰期要能临时增加带宽
  → 业务低峰期要能释放资源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

OpenStack网络三种模式（类比：小区网络建设）：

模式1：Flat（扁平网络）——最简单
  → 小区里只有一个网段，所有住户都在同一个大局域网里
  → 优点：简单，不需要配置
  → 缺点：无法隔离，IP容易冲突
  → 类比：整个小区共用一个交换机，所有人都在同一层

模式2：FlatDHCP（DHCP扁平网络）——加了DHCP自动分配
  → 还是同一个网段，但IP由DHCP服务器自动分配
  → 优点：IP分配自动，不容易冲突
  → 缺点：隔离性差，多租户场景不适用

模式3：vLAN（虚拟局域网）——生产环境标准配置 ⭐
  → 小区分成多个楼栋（vLAN），每个楼栋有独立网络
  → 楼栋之间不能直接互访（隔离）
  → 但楼栋内的住户可以互相通信
  → 住户要访问公网，通过统一的出口网关
  → 优点：完全隔离，适合多租户
  → 缺点：配置复杂，需要交换机支持vLAN

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

Neutron的四个核心概念：

1. 网络（Network）—— 一张虚拟的"网"
  → 可以理解为一个楼栋（vLAN）
  → 每个网络有独立的网络ID
  → 不同网络的云主机不能直接通信（除非通过路由器）

2. 子网（Subnet）—— 网络里的"门牌号段"
  → 例如：子网A = 192.168.1.0/24
  → 子网B = 10.0.0.0/24
  → 定义IP范围、网关、DNS服务器

3. 端口（Port）—— 云主机接入网络的"网线接口"
  → 每连接一个网络，就需要一个端口
  → 端口分配一个IP（从子网的地址池里取）
  → 端口可以绑定安全组（类似于防火墙规则）

4. 路由器（Router）—— 连接不同网络的"楼栋大门"
  → 网络A的子网，要访问网络B，必须经过路由器
  → 路由器还连接外部网络（Provider Network / 外部网络）
  → 云主机通过路由器访问公网

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

# 实验：在OpenStack中创建一台能上网的云主机

# 步骤1：创建外部网络（Provider Network，连接公网）
openstack network create --external \
  --provider-network-type flat \
  --provider-physical-network physnet1 \
  ext-net

# 步骤2：在外部网络上创建子网（公网IP段）
openstack subnet create \
  --network ext-net \
  --subnet-range 202.96.209.0/24 \
  --gateway 202.96.209.1 \
  --allocation-pool start=202.96.209.100,end=202.96.209.200 \
  --dhcp \
  ext-subnet

# 步骤3：创建租户网络（内部网络）
openstack network create internal-net

# 步骤4：在租户网络创建子网（私有IP段）
openstack subnet create \
  --network internal-net \
  --subnet-range 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  internal-subnet

# 步骤5：创建路由器（连接内部网络和外部网络）
openstack router create my-router

# 步骤6：把路由器的内部接口连接到租户网络
openstack router add subnet my-router internal-subnet

# 步骤7：把路由器的外部接口连接到外部网络
openstack router set --external-gateway ext-net my-router

# 步骤8：创建云主机，连接到租户网络
openstack server create \
  --flavor m2.large \
  --image Ubuntu-22.04 \
  --network internal-net \
  --key-name my-keypair \
  my-vm

# 步骤9：创建浮动IP并绑定到云主机（实现公网访问）
openstack floating ip create ext-net
openstack server add floating ip my-vm <floating-ip-address>

# 结果：
# → 云主机在 192.168.10.x 网段（内部网络）
# → 通过路由器NAT转换访问公网（上网）
# → 绑定浮动IP后可以从公网SSH进来

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Cinder解决了什么问题：

场景：你的云主机系统盘只有40GB，但业务需要200GB的数据盘

不用Cinder：
  → 只能在创建云主机时就指定大硬盘
  → 硬盘大小不能动态调整
  → 重装系统数据全丢

用Cinder：
  → 可以随时创建一块200GB的云硬盘
  → 随时挂载到任何云主机
  → 随时扩容（从200GB扩到500GB）
  → 随时从云主机卸载
  → 云硬盘可以备份（快照），不怕数据丢失

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

Cinder存储后端对比：

后端1：LVM（逻辑卷管理）
  → 基于本地磁盘
  → 性能：★★★★★（最快，因为是本地磁盘）
  → 容量：受单台物理机磁盘限制
  → 可用性：单节点故障会导致数据丢失
  → 适用：测试环境、对性能要求极高的场景

后端2：NFS（网络文件系统）
  → 连接到专门的存储服务器（NFS Server）
  → 性能：★★★☆☆（通过网络，有延迟）
  → 容量：取决于NFS服务器容量
  → 可用性：高（存储服务器冗余）
  → 适用：需要共享存储的集群场景

后端3：Ceph RBD ⭐（生产环境最常用）
  → 分布式存储，3副本机制（数据同时存3份）
  → 性能：★★★★☆（高吞吐，低延迟）
  → 容量：可线性扩展（加机器就加空间）
  → 可用性：极高（任何一台机器故障，数据不丢失）
  → 适用：生产环境，高可用需求

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

创建并挂载一块100GB云硬盘的过程：

用户请求："帮我创建一块100GB的云硬盘，挂载到my-vm上"
    ↓
Cinder-api接收请求，验证身份和权限
    ↓
Cinder-scheduler选择最优存储节点
    ↓
选中的存储节点创建LVM卷（或Ceph RBD块设备）
    ↓
通过消息队列通知Nova-compute
    ↓
Nova-compute执行挂载操作
    → 在KVM中新增一个虚拟磁盘设备（/dev/vdb）
    ↓
云主机内部识别到新硬盘（/dev/vdb）
    ↓
用户登录云主机，执行分区和挂载：
  fdisk /dev/vdb        # 分区
  mkfs.ext4 /dev/vdb1   # 格式化
  mount /dev/vdb1 /data # 挂载到/data目录
    ↓
云硬盘使用成功！可以往/data目录写入数据了

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Horizon的主要功能：

左侧导航栏：
  ├─ 项目（Project）  → 查看和管理自己的资源（云主机、网络、硬盘）
  ├─ 管理（Admin）   → 管理员才能看到，管理所有租户、资源配额
  ├─ 身份（Identity）→ 管理员管理用户、角色、项目
  └─ 运维（Operator）→ 系统状态监控（可选）

每个菜单下的操作：
  → 实例：创建/启动/停止/删除/控制台访问
  → 网络：创建网络、子网、路由器、浮动IP
  → 硬盘：创建/挂载/卸载/扩容云硬盘
  → 镜像：上传/下载/删除镜像
  → 安全组：配置防火墙规则

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

三种管理OpenStack的方式：

方式1：Horizon（Web界面）——最直观
  → 优点：可视化，点鼠标就能操作，适合初学者
  → 缺点：效率低，无法自动化，复杂操作不支持

方式2：OpenStack CLI（命令行）——最常用
  → 优点：效率高，可重复执行，适合DevOps
  → 缺点：需要记命令，错误提示不如界面直观

方式3：OpenStack API（编程接口）——最灵活
  → 优点：完全自动化，可以写程序调用
  → 缺点：需要开发能力
  → 实际生产环境：Ansible/Terraform调用OpenStack API
    自动创建和管理整个基础设施（Infrastructure as Code）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

OpenStack最小生产架构：

┌─────────────────────────────────────────┐
│         控制节点（Controller Node）      │
│                                         │
│  ┌─────────────────────────────────┐    │
│  │         物理服务器（1台）         │    │
│  │                                  │    │
│  │  Keystone（认证） ←──┐            │    │
│  │  Glance（镜像）  ←──┤            │    │
│  │  Nova-API       ←──┤  MySQL DB   │    │
│  │  Neutron-server ←──┤  (数据库)   │    │
│  │  Cinder-api     ←──┤            │    │
│  │  Horizon         ←──┘            │    │
│  │  Neutron-agent   (网络插件)      │    │
│  │  nova-compute    (实验/小规模)   │    │
│  │  RabbitMQ        (消息队列)      │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘
            ↓  管理网络
            ↓  数据网络
            ↓  存储网络
┌─────────────────────────────────────────┐
│         计算节点（Compute Node 1~N）     │
│                                         │
│  ┌─────────────────────────────────┐    │
│  │         物理服务器（1台起）       │    │
│  │                                  │    │
│  │  nova-compute   （KVM虚拟机管理器）│    │
│  │  neutron-linuxbridge-agent       │    │
│  │                                  │    │
│  │  ┌──────┐ ┌──────┐ ┌──────┐     │    │
│  │  │ VM1  │ │ VM2  │ │ VM3  │     │    │
│  │  │ 租户A │ │ 租户A │ │ 租户B │     │    │
│  │  └──────┘ └──────┘ └──────┘     │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘
            ↓  存储网络
┌─────────────────────────────────────────┐
│         存储节点（Cinder Storage）       │
│                                         │
│  ┌─────────────────────────────────┐    │
│  │  Cinder-Volume（LVM/Ceph）       │    │
│  │  或者独立的Ceph集群               │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

OpenStack生产环境资源规划：

控制节点（建议2台，做高可用）：
  CPU：32核+
  内存：64GB+
  磁盘：500GB+（SSD，系统盘）
  网络：万兆网卡（管理网+API网+数据网分离）

计算节点（按需扩展）：
  CPU：32核+（支持虚拟化VT-x/AMD-V）
  内存：128GB+
  磁盘：系统盘SSD 200GB+ + 数据盘（大容量）
  网络：万兆网卡（虚拟机流量很大）
  数量：起步3台，每台跑20-40台云主机

存储节点（Ceph集群，至少3台）：
  CPU：16核+
  内存：64GB+
  磁盘：多盘位（每台8-12块硬盘，混合HDD+SSD）
  网络：万兆网卡（存储I/O密集）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

OpenStack学习路线图：

第1步：理解整体架构
  → OpenStack = 控制节点 + 计算节点 + 存储节点
  → 组件间通过消息队列（RabbitMQ）和API通信
  → Keystone是守门人，所有请求先认证

第2步：掌握核心5组件
  → Keystone：身份认证 + 租户管理
  → Glance：操作系统镜像仓库
  → Nova：云主机创建和调度
  → Neutron：虚拟网络（Flat/vLAN/路由器）
  → Cinder：云硬盘（块存储）

第3步：理解调度原理
  → nova-scheduler通过Filter + Weight选择最优节点
  → 考虑CPU/内存/可用域/亲和性等因素

第4步：理解网络模型
  → 外部网络（Provider）连接公网
  → 租户网络（Tenant）实现多租户隔离
  → 路由器连接内外网络
  → 浮动IP实现从公网访问云主机

第5步：实战部署
  → 两节点部署（控制节点+计算节点）
  → 用OpenStack Ansible或Kolla-Ansible自动化部署
  → 用Terraform管理基础设施（IaC）