企业官网建设流程全解析

Swift 的对象存储前面只讲过概念（三兄弟、三大关键技术），这篇补上真正的重头——建环实验：给 Swift 加盘、建 Ring、验证多副本到底落在哪块盘上，删盘时又怎么安全下线。Ceilometer 则从数据采集链路讲到计量数据怎么变成计费账单，两个收尾服务一次走完。

一、Swift 定位补全：它不是文件系统

之前讲过：Swift 是对象存储，与 Cinder（块存储）、Manila（文件存储）并列持久存储三兄弟。补三条容易忽略的定位描述：

1. Swift不是文件系统、也不是实时数据存储系统——它面向「永久类型的静态数据」的长期存储，这些数据可以检索、调整、必要时更新，但不适合频繁改写的场景；
2. 最适合存的数据：虚拟机镜像、图片、邮件存储、存档备份；
3. 没有中心单元或主控节点——这是 Swift 扩展性、冗余和持久性更强的根本原因（对比：传统存储总有单点）。

常用观察命令：swift stat——显示 Swift 中的账户、容器和对象的信息。

二、Ring：三张映射表

Swift 为账户、容器、对象分别定义了 Ring（环）：

Ring 记录了存储对象与物理位置的映射关系，通过四个要素维护：Zone（区域）、Device（设备）、Partition（分区）、Replica（副本）——把虚拟节点（分区）映射到一组物理存储设备上。

对照记忆：上篇 Heat 的 HOT 模板是「一份描述反复建资源」，Ring 是「一张映射表反复找位置」——分布式系统都用「先算后找」代替「中心查询」。

三、建环实验：给 Swift 加两块「真磁盘」

实验环境里 Swift 默认挂的是一个虚拟回环设备（swiftloopback）。实验目标是：加一块 20GB 新盘，分两个区做两个存储点，让 2 副本真的落在两个不同的分区上。

3.1 新添磁盘：分区、格式化、挂载

控制节点新添加一块 20GB 磁盘（/dev/sdb），分成两个区并格式化为 xfs：分区一对应 obs1，分区二对应 obs2。

# 卸载并清理原来的 swift 虚拟设备分区umount/srv/node/swiftloopbackcd/srv/noderm-rfswiftloopback/mkdirobs1 obs2# 创建新的挂载目录，分别对应 sdb1、sdb2# 配置 /etc/fstab：注释原 swiftloopback 行，添加两行新挂载/dev/sdb1 /srv/node/obs1 xfs defaults00/dev/sdb2 /srv/node/obs2 xfs defaults00mount-a# 挂载；若提示 fstab 已改但 systemd 用旧版，先 systemctl daemon-reloaddf# 确认 obs1、obs2 已挂载# 改属主：Swift 服务用户要能读写chownswift:swift obs1chownswift:swift obs2

3.2 创建 Ring：create → add → rebalance

进/etc/swift/目录。先查三个服务的 bind_port（account 6002 / container 6001 / object 6000），然后对三个 builder 各做一遍三步曲（以 object 为例）：

cd/etc/swift/# 第 1 步：create 建环# 三个数字：12 = 分区数量 2^12；2 = 2 个副本；1 = 最少 1 小时后才允许再改 ring 配置swift-ring-builder object.builder create1221swift-ring-builder account.builder create1221swift-ring-builder container.builder create1221# 第 2 步：add 加设备（zone-IP:端口/挂载点 权重100；两个分区分属 z1、z2）swift-ring-builder object.builderaddz1-192.168.108.10:6000/obs1100swift-ring-builder object.builderaddz2-192.168.108.10:6000/obs2100# account 用 6002、container 用 6001，同样的 z1/z2 各加一遍# 第 3 步：rebalance 重平衡（重新分配分区，生成 .ring.gz）swift-ring-builder object.builder rebalance swift-ring-builder account.builder rebalance swift-ring-builder container.builder rebalance

create 12 2 1的三个数字是必背点：2^12 个分区、2 副本、1 小时变更保护。

3.3 验证：2 副本真的落了两份

界面或命令上传一个文件后：

find/srv/node-name*data# /srv/node/obs1/objects/317/0fe/13d34c83.../1727591964.07735.data# /srv/node/obs2/objects/317/0fe/13d34c83.../1727591964.07735.data

同一份对象数据在obs1 和 obs2 各存了一份——2 副本落盘成功，Ring 的分配生效。分区一、分区二分属 z1、z2 两个 zone，坏一块盘数据还在，这就是「多副本冗余」的直观形态。

四、华为 OBS 体验：云上的对象存储

华为云 OBS（Object Storage Service）是 Swift 思路在公有云上的同源产品：桶（bucket）+ 对象 + REST 访问。实验里走了一遍从开通到控制台上传下载的流程，体感上和 Swift 的「容器 + 对象」一一对应——对象存储的抽象模型在各家都是通的。

五、Ceilometer：OpenStack 的电表

5.1 定位

Ceilometer（计量服务）是 OpenStack 的「电表」——把各服务的资源用量统一测出来、存起来、供查询和计费。没有它，云平台的「谁用了多少」就没处出报表。

5.2 发展与衍生

Ceilometer 早期包揽三件事：数据收集 + 数据存储 + 告警，后来项目拆分：

• 存储拆给Gnocchi（时序数据库）；
• 告警拆给Aodh；
• Ceilometer 专注收集。

5.3 整体架构与工作流程

数据流四步：收集 → 处理 → 存储 → 告警/访问。

数据收集用两种代理，方向相反：

数据处理：对原始数据做采样、转换，经管道（pipeline）输出成统一的计量样本（sample）。

数据存储：样本（sample）与事件（event）落到存储后端（现代部署是 Gnocchi），供 API 查询；界面「计量」面板看资源用量，云平台账单从这出。

告警（Aodh）：对计量数据设阈值，触发时执行动作——比如「CPU 连续 5 分钟超 80% 就扩容」。计量管记账，告警管盯梢，两者配合是 Heat 自动伸缩的数据基础。

六、命令速查与概念锚点

三个必背锚点：

1. 三环三端口：Account 6002 / Container 6001 / Object 6000；
2. create 12 2 1：分区数、副本数、变更保护小时数；
3. Ring 四要素：Zone / Device / Partition / Replica。

附：关键英文全称

📚 参考资料（官方文档）

• Swift 官方文档（架构总览、副本与一致性）：https://docs.openstack.org/swift/latest/
• Swift Ring 与 Ring Builder（一致性哈希环、分区、rebalance）：https://docs.openstack.org/swift/latest/ring.html
• Ceilometer 官方文档（采集代理、数据类型、Gnocchi 后端）：https://docs.openstack.org/ceilometer/latest/