项目迁移实践
在存算分离的上线过程中，迭代速度非常快，仅用了两个月时间就完成了整个项目的落地。JuiceFS 的易用性，是能够让我们在巨大压力下按时保量解决问题的重要前提。同时，在实践中，JuiceFS 在解决一些关键问题方面也发挥了非常重要的作用。
第一：PB 级的支撑能力
- 解决元数据存储和连接压力
在之前的 JuiceFS 测试中，选择使用 Redis 作为元数据引擎，数据存储在 Redis 中，整体性能非常好。但是，随着搭建了几百台机器，每个节点启动 Yarn 任务时，每个容器都会访问元数据，导致 Redis 崩溃。因此，将其替换为 TiKV。
- 时间戳写竞争压力
在众多集群中，即使时间窗口是保持一致的，由于机器规模非常庞大，仍然可能出现时间冲突和竞争的问题。为了解决这个问题，添加了一些补丁来优化时间和竞争，放宽了相应的一些参数配置。
- 垃圾清理速度瓶颈
我们发现 Ceph 存储的数据量越来越高，并没有完全释放下去，主要是因为 DPI 的业务数据量非常大，只会去存几天的数据，所以每天都会去写入 PB 级数据，然后消费 PB 级数据，以及删除PB级数据。
- 回收站清理线程泄露问题
在部署监控后发现，有些特定时间点会出现 TiKV 和 Ceph的稳定性问题。经过排查，发现问题出现在客户端回收站线程泄露上。
第二：在高负载下提升性能
流量轨迹项目试点时，为了满足 32TB 计算和 10PB 存储的需求 ，选择了一部分性能较好的机器。然而，在评估 Ceph 的时候，没有考虑到 Ceph 所使用的内存和 CPU 资源，导致每台机器的吞吐量、网络带宽和磁盘带宽基本上都已经打满了，处于类似于压力测试一样的环境。在这种高负载的环境下，不得不对 Ceph 进行调整以解决内存溢出导致的宕机问题，并优化适配 JuiceFS 以加速 Ceph 的数据删除和写入性能。
机器 CPU 内存规划不合理
在规划时期 Ceph 占用的 CPU、内存没有考虑，导致机器内存耗尽、机器负载持续偏高造成服务器宕机，引发任务失败。Ceph 节点与 Hadoop 集群共用一块网卡，节点宕机触发 OSD 数据迁移，计算任务 Shuffle 与数据迁移打满网卡，经过实践优化配置：
• 所有节点：需两块 SSD Raid1 方式做根盘，以此来提高稳定性。 • 计算节点：建议 CPU 线程数：内存 为 1:4 | 1:5 左右，混合部署预留出 Ceph 占用资源 • 存储节点：单个 OSD（单块盘）建议分配 6GB 内存，高性能服务器建议使用双网络平面；如果条件允许，建议将内外网分开，将 Ceph 内部的数据同步和外部的访问分开，这是一种更加理想的状态 • 元数据节点：建议高性能 NVME 磁盘 这是与 PingCAP 做了多次沟通后得出的结论，磁盘的负载包括 TiKV 在当前 180 台计算高频的使用下，压力很大，到 70%~80% 的情况。 • Ceph节点操作系统：CentOS-Stream-8 • 其他节点操作系统：CentOS-7.6+、CentOS-Stream-8
NodeManager 本地目录不合理
在高负载、PB 级别的情况下，任务需要大量的磁盘空间，因此将几乎所有的磁盘空间都分配给了 Ceph，而 HDFS 只有一块机械硬盘。然而，在任务高峰期，由于中间数据需要写入到这块机械硬盘中，导致磁盘 IO 延迟过高，最终成为了任务执行的瓶颈。
