2026-05-17 技术文档|摘要

Ceph 存储 × OpenFlow 数据：技术方案与实施计划

• 一句话：用 Ceph 承接 OpenFlow/控制器产生的“流表、事件、日志、抓包、拓扑快照”等数据，提供统一对象存储/块存储/文件存储能力，并配套分层、生命周期、可观测与容灾。

• 适用人群：网络/平台工程、SRE、数据平台、负责 OpenFlow 控制器与可观测链路落盘的人。

2.1 目标（必须达成）

• 数据承载：OpenFlow 相关数据可持续写入、可检索、可回放；吞吐与容量可水平扩展。

• 成本控制：冷热分层（高频短期热数据 vs 低频长期冷数据），生命周期自动清理/归档。

• 可靠性：单机/单盘/单机架故障不丢数据；可选跨机房异地复制。

• 可观测：写入延迟、失败率、容量、对象数量、热点 bucket、PG 状态、OSD/MON 健康可看可告警。

2.2 范围（本期做什么/不做什么）

• 做：Ceph 集群（MON/MGR/OSD），RGW 对象存储（S3），可选 CephFS/RBD；OpenFlow 数据分桶规范；写入 SDK/网关；生命周期策略；监控告警；备份/容灾策略。

• 不做：业务检索/分析全套系统（如 ES/ClickHouse），只定义接口与落盘规范；不做“所有历史数据永久保存”。

3.1 数据类型与优先级

• P0（必须落盘）：控制器事件（link up/down、packet-in 采样、流表下发/回收记录）、关键日志、配置快照。

• P1（按策略落盘）：flow stats/port stats 周期采样、拓扑快照、审计日志。

• P2（可选）：pcap/镜像数据、原始报文样本（强依赖成本与合规）。

3.2 命名与分桶规范（建议）

• Bucket/目录维度：env（prod/stg）、region、cluster、controller、date（YYYY/MM/DD）。

• 对象 key：`{type}/{controller}/{switch_dpid}/{yyyy}/{mm}/{dd}/{hh}/{shard}/…`

• 元数据：tenant、业务线、采样策略、压缩方式、schema 版本、生成时间戳、hash。

4.1 组件选择与映射

• RGW（S3 对象存储）：存 OpenFlow 事件流、指标采样、拓扑快照、审计日志、pcap 文件。

• CephFS（文件存储，可选）：存共享配置、离线处理临时文件、批处理落地中间结果。

• RBD（块存储，可选）：给控制器/采集器的 VM/容器持久卷（K8s CSI 或传统映射）。

4.2 Pool 规划（建议最小集合）

• `rgw.hot`：热数据（近 7~30 天），3 副本（replicated），SSD/混合盘优先。

• `rgw.warm`：温数据（近 30~180 天），EC（如 4+2 或 6+2）节省成本。

• `rgw.cold`：冷数据（180 天以上，可选），EC 更高码率；或跨集群复制到低成本存储域。

• `cephfs.meta / cephfs.data`（可选）：CephFS 元数据与数据池，元数据池建议 3 副本。

4.3 CRUSH 与故障域

• 故障域至少到 host；有机架条件时建议到 rack。

• 不同介质（SSD/HDD）用 device class 做 CRUSH rule 隔离，实现热/温/冷分层。

4.4 一致性与可靠性取舍

• Replication：简单、性能好、成本高，适合热数据与元数据。

• Erasure Coding：成本低、写放大与修复复杂，适合温冷数据与大对象。

5.1 数据流（建议）

• OpenFlow Controller/Collector →（可选：本地缓冲/队列）→ S3 PutObject → RGW → RADOS Pool

• 后处理（可选）：离线作业从 S3 拉取 → 解析/聚合 → 写入分析库（不在本期实现）

5.2 写入策略（关键）

• 小文件合并：事件/采样按时间窗（如 1~5 分钟）合并成对象，减少对象数。

• 压缩：JSON/文本用 zstd/gzip；pcap 可不压或按场景压缩。

• 幂等：对象 key 带 time window + shard + hash，重复上传可覆盖或写入版本化前缀。

• 背压与降级：RGW/网络抖动时本地落盘缓冲 + 重试；超过阈值降采样或停写 P2 数据。

6.1 生命周期（示例）

• `hot`：保留 30 天，过期转 `warm`（或按 prefix 迁移）。

• `warm`：保留 180 天，过期转 `cold` 或删除。

• `pcap`：默认 7 天，除非命中“事件留存策略”（事故工单/审计）。

6.2 对象数治理

• 目标：控制单日对象数与单桶对象数，避免 bucket listing 成本过高。

• 约束：按 controller/switch 分片 + 时间窗合并；必要时按 hash shard 再切分。

7.1 Ceph 核心信号

• HEALTH：HEALTH_OK / WARN / ERR

• PG：inactive/undersized/degraded、peering/backfilling

• OSD：up/in 数量，延迟，重平衡速率

• RGW：5xx、PutObject 延迟、限流与队列长度

7.2 OpenFlow 写入侧信号

• 写入成功率、重试次数、端到端延迟

• 本地缓冲队列长度、落盘占用

• 单 controller/switch 产出速率与异常峰值

• 访问控制：S3 AccessKey/SecretKey 走密钥管理；按 bucket/prefix 做最小权限。

• 传输加密：TLS；内网也建议启用。

• 数据脱敏：IP/MAC/用户标识按合规要求处理；pcap 属高风险数据需审批策略。

• 审计：RGW 访问日志与关键操作日志单独落盘并保护。

9.1 阶段划分

• Phase A（基础集群）：部署 MON/MGR/OSD，完成网络与磁盘基线，验收 HEALTH_OK。

• Phase B（对象存储）：部署 RGW，创建 hot/warm pool 与 bucket，完成 SDK 写入/读回验证。

• Phase C（规范与治理）：落地对象命名、压缩/合并策略、生命周期、分层迁移。

• Phase D（可观测/容灾）：监控告警、容量与成本看板；可选跨集群复制与演练。

9.2 验收清单（关键）

• 写入：持续写入 24h，失败率低于阈值；断网/限流可恢复。

• 可靠性：模拟 OSD down、host down，数据可读且集群可自愈。

• 成本：warm/cold 生效，生命周期按策略迁移/删除。

• 可观测：关键告警可触发并定位到组件与故障域。

• 对象太碎：对象数爆炸会让 listing/元数据压力急剧上升，优先做“时间窗合并 + 分片”。

• EC 用错地方：把元数据/小对象放 EC 会很痛，热数据与元数据优先 3 副本。

• 故障域不清晰：CRUSH rule 未按 host/rack 做隔离，单点故障会放大影响面。

• RGW 缺可观测：只看 Ceph 健康不够，必须补齐 PutObject 延迟与 5xx 统计。