eBay PB 级日志系统的存储方案实践 _日志系统

CAL(Central Application Logging)系统主要负责收集和处理 eBay 内部各个应用程序池的日志，日处理超过 3PB 的数据，供运维团队和开发团队日常监控使用。
CAL 系统通过 HTTP 接口接受应用产生的日志，将日志持久化到经 NFS 挂载的网络存储上，用户（运维团队和开发团队）可以通过 CAL 系统方便地查找、查看日志。同时，日志也会被导入 Hadoop 进行进一步的分析形成报告。该系统自 21 世纪初至今，已经有 10 多年的历史了。
CAL 从第一天起就运行在 Netapp 的商业存储上。随着业务的发展，业务产生的数据量急剧增加，单个存储集群已经无法承载 CAL 的流量和性能需求，存储团队和业务团队通过增加集群来解决性能问题。一直到 2018 年，CAL 在每个数据中心已经需要 25 个集群才能支撑起其性能需求。
虽然统计上，CAL 只使用了 eBay 5% 的 NFS Filer 总容量，但实际上却消耗了 50% 的总性能。性能和容量的巨大偏离，使得实际成本已经比该存储方案的裸 $/GB 成本高了一个数量级。
高成本，叠加上由 eBay 业务驱动的每年 30% 自然增长，这套架构亟需重构优化。
2014 年，eBay 存储团队开始在公司内将 Ceph 应用于生产环境。第一阶段主要是 RBD 块设备服务。
2017 年，Jewel 版本发布后，我们开始尝试提供 CephFS 分布式文件系统服务，多个天使应用从商业存储迁移到 CephFS 上，从中我们发现修复了 MDS 的多个 bug 并贡献回社区，也在社区首次完成了 MDS 的性能分析。
2018 年，随着 MDS 多活功能的初步成熟，我们也和业务团队一起，开始了把 CAL 迁移到 CephFS 上的征程。
2019 年初上线至今，Ceph 在大流量下稳定运行。平均读写带宽同时超过了 3GB/S ，读写请求数合计超过 100K IOPS（每秒进行读写操作的次数）, 文件系统元数据操作数超过 30K OP/S（每秒操作次数）。
01 总体设计通过对 CAL 现有业务逻辑和历史性能数据的分析，我们明确了设计目标：
1）文件系统元数据路径，支持 100K OP/S，包括：create / getattr / lookup / readdir / unlink 等文件系统操作；并预留足够的升级空间满足业务发展。
2）文件系统的数据路径，支持 150K IOPS（50% 读，50% 写），以及至少 6GB/S（50% 读，50% 写）的吞吐。
3）单集群容量需求300TB 可用空间，满足性能需求的前提下尽可能降低存储成本。
这个略显激进的设计目标，其实在很大程度上已经决定了我们的方案。

基于我们之前针对 Ceph MDS 的性能研究，单 MDS 只能支持 2K ~ 4K OP/S, 要支持 100K OP/S， MDS 多活负载均衡集群是唯一的路径。至少需要 25 个 MDS Active-Active 组成集群。同时，业务负载还要能相对均衡地分布到每个 MDS 上。
150K IOPS 的读写性能，如果单用机械硬盘 HDD ，需要至少 1500 块盘，可用容量接近 3PB ，又回到了用尽性能而浪费容量的老路。如果全部用 SSD ， 1PB 裸容量的 SSD 虽然能比商业存储省钱，但仍是一笔不小的数字。针对日志数据有明显冷热度的特点，使用分层存储，把频繁访问的数据放在 SSD 上，相对冷的数据放在 HDD 上，才能达到最佳费效比。

02 实现细节1. MDS 多活负载均衡集群要实现向外扩展（scale-out）的架构，核心是任务分配，把负载相对均等地分配到每个 MDS 上。对于文件系统来说，整个目录结构是一棵树。任务分配的本质，是通过设计目录树的结构，使得叶子（文件）平均地长在这颗树的每个枝干（目录）上。同时，每个层次的文件 / 文件夹个数必须是可控且相对均衡的，这样才能尽量降低树的深度，避免对一个巨大文件夹进行 ListDir 操作带来的延迟和开销。
CAL 原先的目录层次如下图 1 所示，一共有 15 层，100 多万个文件夹，几乎违反了上面讨论的所有原则，目录过深且不均衡。eBay 每个 pool 承担一个服务，每个服务的流量，服务器数量差异显著。更糟糕的是整个目录树，在每个小时开始的时候，几乎完全重建（虚线部分），导致每小时开始时元数据操作风暴。