企业官网建设流程全解析

简介：这份《OpenStack Ceph分布式存储安装测试报告》面向云计算运维工程师、存储架构学习者及OpenStack平台部署人员，聚焦开源云平台与分布式存储的集成实践。报告从云计算基础概念切入，系统梳理OpenStack组件构成及其与VMware的差异，并深入讲解Ceph的架构原理，包括OSD、MDS、RGW、MON等核心组件、CRUSH数据映射算法、RADOS强一致性与容错机制，以及高性能、高可靠、高扩展等优势，同时说明在OpenStack中选择Ceph作为后端存储的考量与本次测试的主机规划。资源包内含1个docx文档，约876KB，结构完整、目录清晰，便于按章节查阅。目前已有254人学习，适合希望理解OpenStack与Ceph集成逻辑、掌握部署前知识储备与测试思路的读者参考。

1. OpenStack 接 Ceph：为什么测试报告比安装本身更值钱

很多人搭 OpenStack 私有云，第一步想的是把虚拟机跑起来，第二步才想起存储。等到卷创建卡住、实例迁移失败、快照回滚丢数据，才回头翻 Ceph 集群的状态。我见过太多环境，ceph -s显示 HEALTH_OK，但 Nova 创建卷就是超时，Glance 上传镜像就是 500。问题不在 Ceph 本身，而在 OpenStack 各组件和 Ceph 之间的对接参数、认证方式、池规划没有经过系统性验证。这份安装测试报告要解决的，就是把「装完能跑」推进到「跑得稳、测得全、出了问题知道看哪里」。它适合正在用 Packstack 或手动方式搭 OpenStack 云平台、准备把后端存储从本地 LVM 切到 Ceph 的运维和开发人员。下面按实际落地顺序，把安装、对接、测试、排坑串成一条可复现的路径。

2. 装 Ceph 集群前必须定死的四个参数

2.1 为什么先定 PG 数和副本数，而不是先装包

Ceph 集群的性能和可靠性，在装包之前就被两个参数锁死了：副本数（size）和归置组数量（pg_num）。副本数决定一份数据存几份，生产环境常见做法是 3 副本，测试环境为了省资源可以设 2，但设 1 就失去了分布式存储的意义。PG 数决定数据分片的粒度，设少了会导致数据分布不均、单 OSD 过载，设多了会消耗大量内存和 CPU。我一般按公式估算：PG总数 = (OSD总数 × 100) / 副本数，然后向上取到最接近的 2 的幂。比如 6 个 OSD、3 副本，算出来是 200，向上取 256。这个值在集群建好后调整代价很高，所以要在创建池之前定下来。

另一个容易忽略的是mon_osd_full_ratio和mon_osd_nearfull_ratio。默认 full 是 0.95，nearfull 是 0.85。测试环境磁盘小，写满 85% 就开始告警，写满 95% 直接拒绝写入，Nova 创建卷会直接失败。我一般把 nearfull 调到 0.8，full 调到 0.9，留出足够的缓冲空间给恢复和重平衡。

2.2 用 ceph-deploy 或手动方式跑通最小集群

下面以三节点为例，每台机器一块数据盘/dev/sdb，系统盘/dev/sda。先在所有节点装好基础依赖，然后在 admin 节点执行部署。这里用常见的ceph-deploy方式，适合测试环境快速拉起。

# 在所有节点执行：安装依赖并配置时间同步 yum install -y epel-release yum install -y ceph ceph-radosgw chrony systemctl enable --now chronyd # 在 admin 节点执行：创建集群目录并初始化 mon mkdir -p /etc/ceph cd /etc/ceph ceph-deploy new node1 node2 node3 # 修改 ceph.conf，写入网络段和副本数 cat >> /etc/ceph/ceph.conf <<EOF public network = 192.168.1.0/24 cluster network = 192.168.1.0/24 osd pool default size = 3 osd pool default min size = 2 osd pool default pg num = 256 osd pool default pgp num = 256 EOF # 安装 ceph 到所有节点 ceph-deploy install node1 node2 node3 # 初始化 mon 并收集密钥 ceph-deploy mon create-initial ceph-deploy admin node1 node2 node3 # 部署 mgr（Luminous 之后必须） ceph-deploy mgr create node1 # 添加 OSD，每台机器一块数据盘 ceph-deploy osd create --data /dev/sdb node1 ceph-deploy osd create --data /dev/sdb node2 ceph-deploy osd create --data /dev/sdb node3

这段脚本的关键点：public network和cluster network在测试环境可以共用同一网段，但生产环境建议分开，避免客户端流量和副本复制流量互相干扰。osd pool default size = 3表示默认三副本，min size = 2表示至少两份在线才允许写入。PG 数设 256 是给后续创建的池用的默认值，实际创建池时还可以单独指定。

装完后用ceph -s检查状态，正常应该看到HEALTH_OK，三个 mon 组成 quorum，OSD 全部 up 且 in。如果看到HEALTH_WARN提示pools have too few placement groups，说明 PG 数偏少，需要调整。如果提示clock skew，检查 chrony 是否同步。

2.3 创建 OpenStack 专用池并做权限隔离

Ceph 集群跑起来后，不要直接用默认的rbd池给 OpenStack 用。常见做法是按组件分池：Glance 存镜像、Cinder 存卷、Nova 存临时盘（如果启用）、Cinder Backup 存备份。每个池单独设 PG 数和副本数，便于监控和调优。

# 创建各组件专用池 ceph osd pool create volumes 256 256 ceph osd pool create images 128 128 ceph osd pool create backups 128 128 ceph osd pool create vms 128 128 # 启用 rbd 应用模式 ceph osd pool application enable volumes rbd ceph osd pool application enable images rbd ceph osd pool application enable backups rbd ceph osd pool application enable vms rbd # 创建 OpenStack 专用用户并授权 ceph auth get-or-create client.cinder mon 'allow r' \ osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rwx pool=vms, allow rx pool=images' \ -o /etc/ceph/ceph.client.cinder.keyring ceph auth get-or-create client.glance mon 'allow r' \ osd 'allow class-read object_prefix rbd_children, allow rwx pool=images' \ -o /etc/ceph/ceph.client.glance.keyring ceph auth get-or-create client.cinder-backup mon 'allow r' \ osd 'allow class-read object_prefix rbd_children, allow rwx pool=backups' \ -o /etc/ceph/ceph.client.cinder-backup.keyring

权限隔离的意义在于：Glance 只能读写 images 池，即使凭证泄露也动不了 volumes 池的数据。object_prefix rbd_children是 RBD 克隆操作必需的权限，少了它快照克隆会失败。创建完 keyring 文件后，需要拷贝到对应组件的节点上，并确保权限是 640、属主是 ceph 或对应服务用户。

3. 把 Ceph 接进 OpenStack：Glance、Cinder、Nova 三处配置

3.1 Glance 后端切到 Ceph 的配置与验证

Glance 默认用本地文件存镜像，切到 Ceph 后镜像直接以 RBD 形式存进 images 池，多个 Glance 节点共享同一份存储，不用再同步文件。配置改在/etc/glance/glance-api.conf。

[glance_store] stores = rbd default_store = rbd rbd_store_pool = images rbd_store_user = glance rbd_store_ceph_conf = /etc/ceph/ceph.conf rbd_store_chunk_size = 8

rbd_store_chunk_size = 8表示镜像按 8MB 分块，这个值影响上传大镜像时的并发效率，测试环境用默认 8 即可，生产环境如果镜像普遍超过 10GB，可以调到 16 或 32。改完重启openstack-glance-api，然后上传一个镜像验证。

# 上传测试镜像 openstack image create --disk-format qcow2 --container-format bare \ --file cirros-0.5.2-x86_64-disk.img test-image # 在 Ceph 侧确认镜像已写入 rbd -p images ls

如果rbd ls能看到镜像对应的块设备，说明 Glance 对接成功。如果上传报 500，先看/var/log/glance/api.log，常见原因是 keyring 文件路径不对或权限不足。注意 Glance 节点上/etc/ceph/下必须有ceph.conf和ceph.client.glance.keyring，且 glance 用户可读。

3.2 Cinder 多后端配置与卷类型绑定

Cinder 对接 Ceph 稍微复杂，因为涉及卷类型和调度。配置在/etc/cinder/cinder.conf。

[DEFAULT] enabled_backends = ceph-volumes [ceph-volumes] volume_driver = cinder.volume.drivers.rbd.RBDDriver rbd_pool = volumes rbd_ceph_conf = /etc/ceph/ceph.conf rbd_user = cinder rbd_secret_uuid = <通过 ceph auth get-key 生成的 uuid> rbd_flatten_volume_from_snapshot = false rbd_max_clone_depth = 5 rbd_store_chunk_size = 4

rbd_secret_uuid不是随便填的，需要先生成一个 UUID，然后把 Cinder 用户的 key 写进 libvirt 的 secret 里，这样 Nova 才能通过 libvirt 访问 Ceph 卷。步骤是：

# 生成 UUID UUID=$(uuidgen) echo $UUID # 获取 cinder 用户的 key ceph auth get-key client.cinder # 在 Nova 计算节点上创建 libvirt secret cat > /tmp/secret.xml <<EOF <secret ephemeral='no' private='no'> <uuid>$UUID</uuid> <usage type='ceph'> <name>client.cinder secret</name> </usage> </secret> EOF virsh secret-define --file /tmp/secret.xml virsh secret-set-value --secret $UUID --base64 $(ceph auth get-key client.cinder)

rbd_max_clone_depth = 5控制从快照克隆卷的最大深度，超过这个深度会触发 flatten 操作，把克隆卷变成独立卷。设太小会导致频繁 flatten 影响性能，设太大则克隆链过长，删除卷时回收慢。测试环境 5 层够用。rbd_flatten_volume_from_snapshot = false表示从快照创建卷时不立即扁平化，保留克隆关系，节省空间。

配置完成后重启openstack-cinder-volume，创建卷类型并绑定后端。

openstack volume type create ceph-volumes openstack volume type set --property volume_backend_name=ceph-volumes ceph-volumes openstack volume create --size 10 --type ceph-volumes test-volume

创建成功后用rbd -p volumes ls应该能看到volume-<uuid>的块设备。如果卷一直卡在 creating，看/var/log/cinder/volume.log，常见原因是rbd_secret_uuid和 libvirt secret 不匹配，或者 cinder 用户没有 volumes 池的写入权限。

3.3 Nova 临时盘与镜像缓存对接 Ceph

Nova 对接 Ceph 有两个层面：一是实例的临时盘（ephemeral）直接存 Ceph，二是从 Glance 拉镜像时走 Ceph 克隆，避免全量拷贝。配置在计算节点的/etc/nova/nova.conf。

[libvirt] images_type = rbd images_rbd_pool = vms images_rbd_ceph_conf = /etc/ceph/ceph.conf rbd_user = cinder rbd_secret_uuid = <同上>

images_type = rbd表示实例磁盘用 RBD，images_rbd_pool = vms指定临时盘池。这样创建实例时，如果镜像在 Ceph 里，Nova 会直接从镜像克隆一个卷给实例用，速度比从文件拷贝快很多。注意rbd_user和rbd_secret_uuid要和 Cinder 保持一致，因为 libvirt 用的是同一个 secret。

改完重启openstack-nova-compute，然后创建一个实例验证。如果实例卡在 spawning，看/var/log/nova/nova-compute.log，常见错误是rbd: failed to open pool，说明计算节点上没有对应的 keyring 或 ceph.conf 路径不对。

4. 安装测试报告里最容易翻车的五个点

4.1 现象：ceph -s健康但 OpenStack 创建卷超时

原因通常是 Ceph 集群健康，但 OpenStack 组件用的 keyring 权限不够，或者rbd_secret_uuid没配。Ceph 的HEALTH_OK只反映集群自身状态，不反映客户端认证是否通过。解决方法是先在 Ceph 节点上用rbd -p volumes --id cinder ls手动验证 cinder 用户能否访问池，如果这条命令报权限错误，说明 auth 配置有问题，重新执行ceph auth get-or-create并确认 keyring 文件已分发到所有相关节点。

4.2 现象：Glance 上传镜像成功但实例启动失败

镜像在 images 池里，但计算节点上的 Nova 没有权限读 images 池。Nova 的rbd_user如果设成 cinder，而 cinder 用户只有 volumes 和 vms 的权限，没有 images 的读权限，克隆就会失败。解决方法是给 cinder 用户加上allow rx pool=images，或者单独给 Nova 配一个能读 images 的用户。我一般直接在 cinder 的 auth 里加上 images 的读权限，省得维护两套凭证。

4.3 现象：Cinder 卷创建后容量显示为 0 或远小于申请值

这是 Ceph 的rbd_default_features和 Cinder 的rbd_store_chunk_size不匹配导致的。Ceph 默认开启layering、exclusive-lock、object-map、fast-diff等特性，如果 Cinder 驱动版本较老，可能不识别某些特性，导致卷元数据异常。解决方法是检查/etc/ceph/ceph.conf里的rbd_default_features，测试环境可以临时设为 1（仅 layering），确认问题后再逐步开启。另外确认rbd_store_chunk_size在 Cinder 和 Glance 里保持一致，不一致会导致镜像和卷的块大小不同，影响克隆效率。

4.4 现象：删除实例后 Ceph 池空间不释放

Nova 删除实例时，如果rbd_flatten_volume_from_snapshot设成了 true，克隆卷会变成独立卷，删除实例后卷被删掉，空间应该释放。但如果设成 false，克隆链还在，删除实例只是删掉了最上层的卷，底层快照和镜像还占着空间。解决方法是定期用rbd du -p vms查看实际占用，对不再使用的克隆链执行rbd flatten或直接删除底层快照。测试环境可以设rbd_flatten_volume_from_snapshot = true，牺牲一点创建速度换取空间回收的确定性。

4.5 现象：三副本集群写入性能远低于预期

先检查ceph osd perf看各 OSD 的延迟，如果某个 OSD 的 apply/commit 延迟明显高于其他，可能是那块盘有问题。再检查网络，cluster network如果和public network共用，副本复制流量会挤占客户端流量。测试环境可以用iperf测一下节点间带宽，如果只有百兆，三副本写入会非常慢。解决方法是把cluster network分到独立的万兆网段，或者至少做网卡绑定。另外确认osd journal是否放在了 SSD 上，机械盘做 journal 会拖慢整体写入。

5. 用 rados bench 和 fio 给测试报告补上硬数据

安装测试报告如果只写「安装成功、功能正常」，说服力不够。我一般会补两组数据：Ceph 层面的rados bench和 OpenStack 卷层面的fio。rados bench直接测池的写入和读取带宽，不经过 OpenStack，能反映存储底座的真实能力。

# 写测试：4 个并发，总共写 200 秒，对象大小 4MB rados bench -p volumes 200 write --no-cleanup -b 4096 -t 4 # 顺序读测试 rados bench -p volumes 200 seq -t 4 # 清理测试数据 rados -p volumes cleanup

-b 4096表示对象大小 4MB，-t 4表示 4 个线程。测试结果里重点看Bandwidth和Average Latency。三副本、万兆网、SSD journal 的环境，写带宽通常在 200-400 MB/s，延迟在 10-20ms。如果写带宽只有几十 MB/s，先查网络和 journal。

fio则在挂载到实例的卷上跑，测的是端到端性能。

# 在实例内对数据盘跑 4K 随机写 fio --name=randwrite --ioengine=libaio --iodepth=32 \ --rw=randwrite --bs=4k --direct=1 --size=1G \ --numjobs=4 --runtime=60 --group_reporting

iodepth=32模拟高并发，direct=1绕过页缓存。4K 随机写的 IOPS 是衡量云盘性能的关键指标，Ceph 三副本环境下，单卷 4K 随机写能到 3000-5000 IOPS 算正常。如果低于 1000，检查rbd_cache是否开启，以及 OSD 的osd_op_threads是否够用。

把这两组数据写进报告，比只写「安装成功」有说服力得多。我习惯在报告里附上测试时间、集群规模、网络配置和关键参数，这样别人复现时能直接对照。踩过的坑是：rados bench的--no-cleanup会留下测试数据，跑完一定要cleanup，否则池空间被占满，后续创建卷会失败。这个坑我翻过两次，希望帮到你。

本文还有配套的精品资源，点击获取