Swift 对象存储建环实验 + Ceilometer 计量：两个收尾服务

Swift 的对象存储前面只讲过概念三兄弟、三大关键技术这篇补上真正的重头——建环实验给 Swift 加盘、建 Ring、验证多副本到底落在哪块盘上删盘时又怎么安全下线。Ceilometer 则从数据采集链路讲到计量数据怎么变成计费账单两个收尾服务一次走完。一、Swift 定位补全它不是文件系统之前讲过Swift 是对象存储与 Cinder块存储、Manila文件存储并列持久存储三兄弟。补三条容易忽略的定位描述Swift不是文件系统、也不是实时数据存储系统——它面向「永久类型的静态数据」的长期存储这些数据可以检索、调整、必要时更新但不适合频繁改写的场景最适合存的数据虚拟机镜像、图片、邮件存储、存档备份没有中心单元或主控节点——这是 Swift 扩展性、冗余和持久性更强的根本原因对比传统存储总有单点。常用观察命令swift stat——显示 Swift 中的账户、容器和对象的信息。二、Ring三张映射表Swift 为账户、容器、对象分别定义了 Ring环Ring对应服务端口管什么Account Ring6002账户租户级映射Container Ring6001容器对象的组织单元级映射Object Ring6000对象真正的数据级映射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 obs23.2 创建 Ringcreate → add → rebalance进/etc/swift/目录。先查三个服务的 bind_portaccount 6002 / container 6001 / object 6000然后对三个 builder 各做一遍三步曲以 object 为例cd/etc/swift/# 第 1 步create 建环# 三个数字12 分区数量 2^122 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、z2swift-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.gzswift-ring-builder object.builder rebalance swift-ring-builder account.builder rebalance swift-ring-builder container.builder rebalancecreate 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 体验云上的对象存储华为云 OBSObject Storage Service是 Swift 思路在公有云上的同源产品桶bucket 对象 REST 访问。实验里走了一遍从开通到控制台上传下载的流程体感上和 Swift 的「容器 对象」一一对应——对象存储的抽象模型在各家都是通的。五、CeilometerOpenStack 的电表5.1 定位Ceilometer计量服务是 OpenStack 的「电表」——把各服务的资源用量统一测出来、存起来、供查询和计费。没有它云平台的「谁用了多少」就没处出报表。5.2 发展与衍生Ceilometer 早期包揽三件事数据收集 数据存储 告警后来项目拆分存储拆给Gnocchi时序数据库告警拆给AodhCeilometer 专注收集。5.3 整体架构与工作流程数据流四步收集 → 处理 → 存储 → 告警/访问。数据收集用两种代理方向相反代理方式说明轮询代理 Polling主动「要」周期性地向各服务 API 请求计量数据通知代理 Notification被动「听」监听消息总线上各服务发出的事件通知数据处理对原始数据做采样、转换经管道pipeline输出成统一的计量样本sample。数据存储样本sample与事件event落到存储后端现代部署是 Gnocchi供 API 查询界面「计量」面板看资源用量云平台账单从这出。告警Aodh对计量数据设阈值触发时执行动作——比如「CPU 连续 5 分钟超 80% 就扩容」。计量管记账告警管盯梢两者配合是 Heat 自动伸缩的数据基础。六、命令速查与概念锚点命令说明swift stat查看账户/容器/对象统计信息swift-ring-builder builder create 12 2 1建环2^12 分区 / 2 副本 / 1 小时保护swift-ring-builder builder add z1-IP:PORT/挂载点 100加存储设备zone-IP:端口/目录 权重swift-ring-builder builder rebalance重平衡生成 ring.gzfind /srv/node -name *data验证多副本落盘三个必背锚点三环三端口Account 6002 / Container 6001 / Object 6000create 12 2 1分区数、副本数、变更保护小时数Ring 四要素Zone / Device / Partition / Replica。附关键英文全称缩写/术语全称含义OBSObject Storage Service华为云对象存储服务Ring—环对象到物理位置的映射表Partition—分区Ring 的虚拟节点单位2^12 即 4096 个Replica—副本数实验为 2Gnocchi—时序数据库计量数据存储后端Aodh—告警服务从 Ceilometer 拆分Polling / Notification—轮询主动要/ 通知被动听两种收集代理 参考资料官方文档Swift 官方文档架构总览、副本与一致性https://docs.openstack.org/swift/latest/Swift Ring 与 Ring Builder一致性哈希环、分区、rebalancehttps://docs.openstack.org/swift/latest/ring.htmlCeilometer 官方文档采集代理、数据类型、Gnocchi 后端https://docs.openstack.org/ceilometer/latest/