我在应用程序的基础设施设计方面遇到了问题。目前，我们从 GFSv2 2 节点集群访问大量小文件（小于 10MB）。90% 的文件访问是对此 GFSv2 分区的“随机读取”，其余 10% 是随机写入。我已经对 noatime、nodirtime 和 plocks 进行了所有调整，但 IOwait 仍然太高。对于这种情况，有哪些更好的替代方案？
其他可能相关的细节：全千兆网络，所有主机都在同一机架中，gfs 来自 SSD 分层 SAN，延迟小于 1ms，性能出色，使用 DLM 的 iowait 为 3%，每秒仅写入两个 3MB 文件。我们显然计划处理比这多得多的数据。我需要一个具有 HA 并可水平扩展的解决方案。
我知道文件系统的选择在很大程度上取决于流量的类型，所以我希望我能准确描述我的用例。
答案1
这取决于文件有多小。如果文件超过 10kb，您可以尝试 GlusterFS。它非常适合处理较大的文件，并且带有镜像的 2 节点集群应该能够处理大量吞吐量。对于非常小的文件 - gluster 会失败 :(
您还可以尝试 Ceph（对象或块存储）或 Swift（对象）。对象存储的特点是您需要使用 API 连接到它。