在准备基础设施以利用分布式存储系统时驼鹿或者文件系统那么，各个节点应该如何向环境的其余部分呈现存储？
分区是否应该靠近物理硬件来呈现，或者各个节点是否应该呈现逻辑卷和/或卷组？
在之前的一个问题中，“有没有办法通过 NFS 实现类似 LVM 的操作？“，我实现了与使用分布式系统类似的结果集群文件系统通过 VMware 中介。
对于分布式文件系统，应该如何最好地处理这种情况？方法是否因所选的分布式文件系统而异？
答案1
似乎有两种通用方法（至少在 MooseFS 和 XtreemFS 世界中）：
一次开车
对于 MooseFS，最好的方法是使用一个 HDD 作为连接到 ChunkServer 的一个 XFS 分区。我们不建议使用任何 RAID、LVM 配置。
为什么？
首先是硬盘错误。如果你的硬盘开始变慢，很难发现它是在 LVM 上。在 MFS 上，你可以很快找到它，甚至可以从 MFS 主网站上找到它。第二件事：向 MooseFS 添加或删除硬盘比向 LVM 组添加或删除更容易。只需将 HDD 添加到块服务器，格式化为 XFS，重新加载块服务器，你的实例上就有了额外的空间。第三件事是 MoooseFS 有许多更好的排序算法来将块放置在多个硬盘上，因此所有硬盘都有平衡的流量 - LVM 没有
一次处理多个数据的方法
XtreemFS OSD（以及其他服务）依赖本地文件系统来存储数据和元数据。因此，在具有多个磁盘的机器上，您有两种可能性。首先，您可以将一台机器上的多个磁盘组合成一个文件系统，例如通过使用 RAID、LVM 或 ZFS 池。其次，每个磁盘（包括 SSD 等）都拥有自己的本地文件系统，并由自己的 XtreemFS OSD 服务导出。
这两种可能性各有优缺点，我无法给出一般性建议。第一种选择在使用的 RAID 级别或可能附加的 SSD 缓存方面具有灵活性。此外，维护和监控每台机器一个 OSD 进程可能比每个磁盘一个进程更容易。
每个本地磁盘使用一个 OSD 服务器可能会带来更好的性能。在运行快速 SSD 的 RAID 时，XtreemFS OSD 可能会成为瓶颈。您还可以通过多个网络接口在一台机器上共享多个 OSD 的负载。对于复制的文件，您必须关心副本放置，并避免将一个文件的多个副本放置在运行在同一硬件上的 OSD 上。您可能必须编写自定义 OSD 选择策略。XtreemFS 为此提供了一个接口。
哪个看起来更好
根据 XtreemFS 的回应，似乎 MooseFS 可以从一次卷的方法中受益，但前提是你能很好地缓解潜在的驱动器故障。
一次一个驱动器的好处是，如果单个驱动器发生故障（这似乎是最令人担忧的物理错误），MooseFS 的排序算法和恢复系统可以复制现在未复制的数据并“忽略”故障驱动器。
一次复制卷的好处是可以强制将复制的数据放在不同的服务器上 - 但不能保证数据均匀/水平个人驱动器使用情况。