一些性能比较

我进行了一些基本的测试，将 Ceph 与 NFS 在一个简单的基准测试（Linux 内核 untar）上进行比较。 我试图尽可能地做到“苹果对苹果”的比较。 相同的客户端机器用于 NFS 和 Ceph；另一台机器要么是 NFS 服务器，要么是 Ceph MDS。 相同的磁盘类型用于两种测试。 NFS 服务器的基础文件系统是 ext2。 在 Ceph 的情况下，使用了额外的机器作为 OSD（每个使用 btrfs）。 Ceph 的速度介于 NFS sync 和 async 之间

• NFS async – ~60s
• Ceph – ~90s
• NFS sync – ~120s

这个比较在很多方面并不理想。 最明显的是，NFS 服务器是一个单点故障，而 Ceph 正在尽最大努力在多个节点上复制所有数据，并无缝容忍其中任何一个节点的故障（在本例中，所有内容都复制了 2 次）。 此外，NFS async 情况会从客户端的角度丢弃所有数据安全：应用程序 fsync() 没有意义。 相比之下，虽然 Ceph 以某种异步方式运行（对于元数据和数据操作），但文件或目录上的 fsync() 意味着它应该意味着的内容。

我不能说我对这些结果感到非常满意（我预计速度会更快），但我们还没有完成。 对于每个文件，Ceph 仍然需要向 MDS 发送两次往返（创建和关闭文件），向 OSD 发送一次（写入数据）。 虽然 OSD 操作和第二次 MDS 操作是异步的，但它们仍然需要时间（特别是 MDS 上的第二次 MDS 操作）。 最终目标是通过预分配未使用的 inode 编号给客户端来异步完成文件创建；这将允许客户端使用单个 MDS 操作创建和关闭（已写入）文件。 但目前这已经是一个不错的开始。

我应该提到 OSD 写入延迟对这些数字的影响很小；客户端文件数据回写和 MDS 通常不会在等待 IO 完成时阻塞前进。 使用昂贵的硬件（NVRAM）进行存储将改善其他方面的性能（特别是当多个客户端访问相同的文件时，并且 MDS 等待更改命中日志时），但它不会对像这个单客户端工作负载产生太大影响。