我们公司业务快速扩张之后，单机NFS与传统RAID阵列逐渐无法满足高可用性与数据灾备的需求。特别是面对每日数TB的数据增长和跨IDC的实时访问请求，传统方案在性能与可扩展性方面都频频踩雷。
于是我决定在香港服务器集群上部署Ceph，构建一套支持弹性扩容、高可靠性与高性能的数据平台，同时结合远程异地灾备机制，支撑我们的视频内容分发、归档存储与备份系统。
本文将完整记录我如何从零构建这套基于Ceph的分布式存储系统，包括部署架构、性能调优、故障容灾设计等细节。
一、部署前的架构规划
1.1 需求评估
- 每日数据增长：2-3 TB
- 访问模式：95%为顺序读写，5%为高并发小文件访问
- 灾备目标：RPO < 15 分钟，RTO < 10 分钟
- 数据中心：香港沙田主机房 + 异地金钟容灾点
1.2 架构设计
我采用了 Ceph Octopus（15.2）版本构建三副本的分布式对象存储，结合 RADOS Gateway 提供 S3 兼容接口，同时配合异地同步进行灾备。架构如下：
[Clients]──►[HAProxy + RGW x2]
│
┌─────┴─────┐
│ MON x3 │
│ MGR x2 │
└────┬──────┘
│
┌──────┴───────┐
│ OSD Node x6│
│ NVMe + HDD混布│
└──────────────┘
│
[远程同步到金钟备份集群]
二、部署实操步骤
2.1 安装前准备（以Ubuntu 22.04为例）
sudo apt update
sudo apt install ntp chrony lvm2 cephadm -y
sudo cephadm bootstrap --mon-ip 192.168.100.11 --cluster-network 10.10.10.0/24
将部署节点标记为管理节点后添加其他主机：
ceph orch host add osd-node1 192.168.100.21
ceph orch host add osd-node2 192.168.100.22
...
2.2 OSD配置
采用 lvm batch 批量部署，NVMe作DB，HDD作数据盘：
ceph orch daemon add osd osd-node1:/dev/nvme0n1 --block-db /dev/sda
优化journal、filestore参数（针对机械盘）：
ceph config set osd osd_mkfs_type xfs
ceph config set osd osd_mkfs_options_xfs "-f -i size=2048"
2.3 RGW部署（作为S3接口层）
ceph orch apply rgw myrealm.myzone --placement="2 osd-node1 osd-node2"
并配置反向代理（HAProxy）做流量入口：
frontend s3_front
bind *:80
default_backend s3_backend
backend s3_backend
server rgw1 192.168.100.21:7480 check
server rgw2 192.168.100.22:7480 check
三、性能优化与配置细节
3.1 网络层优化
- 启用 Jumbo Frame：MTU 调至 9000
- Bonding 模式使用 LACP 802.3ad
开启内核参数调优：
sysctl -w net.core.rmem_max=268435456
sysctl -w net.core.wmem_max=268435456
3.2 Ceph 参数优化
ceph config set global osd_pool_default_pg_num 512
ceph config set global osd_pool_default_pgp_num 512
ceph config set global mon_osd_down_out_interval 600
ceph config set global mon_osd_min_down_reporters 2
3.3 数据分层策略（HDD + NVMe）
通过 ceph-volume 分层：
- NVMe 用于 writeback 缓存（block.db）
- HDD 存储冷数据
- 使用 ceph balancer 动态平衡 I/O 分布
四、容灾机制：异地集群 + 异步同步
我在金钟IDC部署了一套轻量级 Ceph 集群，仅包含 MON + MGR + OSD（2副本）。通过 rclone + radosgw-admin 脚本定时同步：
rclone sync s3://prod-bucket s3://backup-bucket \
--s3-endpoint=https://backup.rgw.hk \
--s3-access-key=XXX --s3-secret-key=YYY
配合 Prometheus + Alertmanager 检测同步延迟，一旦RPO > 10min即报警。
五、监控与日常维护
使用 ceph dashboard、Prometheus 结合 Grafana：
- 关键指标：OSD利用率、PG状态、客户端读写延迟
- 关键告警规则示例（Prometheus）：
- alert: CephOSDDown
expr: ceph_osd_up == 0
for: 5m
labels:
severity: critical
我还定期执行如下检查脚本：
ceph health detail
ceph osd df tree
ceph pg dump | grep inactive
六、经验教训
Ceph虽然部署曲线陡峭，但它真正解决了我们以往存储扩展受限、节点单点风险和异地备份难以自动化的问题。以下是我踩过的坑与建议：
- OSD混部要小心：不同磁盘性能差距大时需设置 bluestore_cache_autotune=false 进行手动调节；
- RGW 性能瓶颈：避免将多个RGW服务绑定在单个OSD节点上，避免IO争抢；
- 灾备延迟监控：千万别依赖“看起来正常”，需要量化 RPO、RTO 与可用性指标。
- 目前我们在香港Ceph集群上存储超过2PB数据，月度成本比ECS+OSS方案节省近40%，且稳定性显著提升。未来我们还计划引入 CephFS 进行高性能视频转码中间缓存。
如你也在香港机房构建大规模分布式存储，Ceph 绝对是值得投入时间深入研究的方案。希望本文能为你节省一些踩坑时间。
七、典型故障案例排查
在Ceph集群运行过程中，我遇到过数个典型的故障场景，如果未能及时定位，将直接影响存储的可用性甚至造成服务中断。以下列出我实际遇到的三类关键问题及排查过程。
案例一：OSD频繁掉线，数据写入卡顿
现象：
集群状态从 HEALTH_OK 变为 HEALTH_WARN；
某些 OSD 显示为 down 状态，客户端写入请求明显变慢。
排查步骤：
登录 MON 节点查看详细健康信息：
ceph health detail
输出中提示：
1 osds down
Reduced data availability: 100 pgs degraded
查看 OSD 守护进程日志：
journalctl -u ceph-osd@15
日志中发现有如下错误：
heartbeat_no_reply from osd.15 since ... marked down
登录 OSD 节点，发现网络异常：
ping -I bond0 192.168.100.11
丢包率 > 30%，排查发现是 bond0 配置未启用 LACP，链路抖动。
解决方案：
修改网卡 bonding 模式为 802.3ad；
优化 switch 与服务器的 LACP 配置；
重启网络后恢复 OSD 状态：
ceph osd in 15
案例二：RADOS Gateway S3接口频繁超时
现象：
- 使用 S3 接口上传大文件失败；
- 客户端日志提示超时或连接重置；
- RGW 日志中无明显异常。
排查步骤：
检查RGW节点的系统负载：
top
iotop -ao
发现 RGW 所在节点 CPU/IO使用率飙升，尤其是磁盘延迟明显。
查看RGW与OSD部署分布：
ceph orch ps | grep rgw
原来 RGW 与多个高IO OSD混布在同一台物理机上。
检查radosgw日志：
tail -f /var/log/ceph/ceph-rgw.*
并未出现内部错误，但处理请求耗时较长。
解决方案：
- 将 RGW 与 OSD 进行物理隔离；
- 增加 RGW 节点，并使用 HAProxy 做负载均衡；
针对大文件上传开启 multipart 配置：
rgw_s3_chunked_upload = true
rgw_max_chunk_size = 100MB
案例三：集群PG状态异常，部分数据无法读取
现象：
ceph health detail 报告有 PG 处于 stuck degraded 或 incomplete；
某些对象无法读取，提示 error -2 (No such file or directory)。
排查步骤：
查找异常 PG 编号：
ceph pg dump | grep incomplete
查看 PG 的详细状态：
ceph pg 5.23 query
显示其中一副本的 OSD 永久丢失，且没有足够副本完成恢复。
结合日志排查丢失对象：
ceph pg 5.23 list_missing
显示若干对象处于 lost 状态。
解决方案：
手动标记对象为丢失（如果确实无副本）：
ceph pg 5.23 mark_unfound_lost revert
或者，如果业务可以容忍数据缺失，标记为删除：
ceph pg 5.23 mark_unfound_lost delete
后续增强措施：开启 EC（Erasure Coding）池和对象多副本校验，提升容错能力。
Ceph 的复杂性在于其分布式架构中，网络、存储、服务进程三者之间高度耦合，任何一个环节的小抖动都可能放大为业务故障。我的经验是：
- 第一时间看 ceph health detail；
- 善用 ceph pg query、ceph osd tree、ceph orch ps等命令定位状态；
- 日志优先查/var/log/ceph与systemd journal；
- RGW类问题一般先查IO与混布问题。
保持监控告警的实时性、日志归档完整性以及节点角色分离，是确保Ceph在香港业务场景中长期稳定运行的核心策略。
