我正在运行一个存储系统。 容错性在应用程序级别进行处理（文件存储在多个服务器上，甚至数据中心上）。
因此，我不需要，甚至不需要在一台服务器冗余（Raid 5会好，但我运行商品预算服务器，所以任何资源密集型或需要昂贵的硬件是坏的）。
目前，我正在使用LVM在服务器中的所有驱动器中创build卷组，然后在其上放置一个大卷。
这工作很好迄今。
问题是我想在未来使用更大的服务器，包含多达40多个驱动器。
一个驱动失败的可能性，从而摧毁整个卷组是不可接受的高。 数据存储在其他地方，可以由应用程序恢复，但通过互联网对等恢复100多TB是昂贵的，需要很长时间。
如果一个驱动器出现故障，我只想放松存储在该磁盘上的文件。
如果这些文件可以作为一个整体存储在一个磁盘上，并且在一定程度上均匀地分布在多个磁盘上（出于性能方面的考虑，并且减less了一个驱动器出现故障时需要恢复的数据量），这也是完美的。
有什么适合我的需求吗？
我认为在大型卷组中，这是一个非常普遍的问题。
呈现“合并视图”并通过导火线安装的小程序将是完美的。
不幸的是我的应用程序不够灵活，无法处理一个服务器内的多个卷。
我知道lvm有恢复手段，但说实话，我真的不想在生产系统中运行它们。
另外：lvm如何在一个卷组中的多个设备上“传播”数据？ 它是否增加到第一个，直到完整，然后开始第二个？ 还是更像是随机的地方？
编辑：
这不是一个真正的问题？ 这个问题不是关于“什么是一个好的方法……”这个问题也不是关于容错的冗余。
我的问题非常具体。 这有点不同寻常。 这就是为什么我需要问一个问题，而不是input到谷歌。
我可以使用什么程序将多个驱动器合并为一个大容量，并且只有在一个驱动器出现故障时才会释放存储在一个驱动器中的文件
Raid – >不这样做。 Raid可以存储冗余信息以防止首先丢失。 Raid也可以将多个驱动器合并为一个。
想象一个小秘书拿到一个文件。 把它放在一个有自由空间的驱动器上。 如果你要求它，他会search它，或记住它在哪里，并从那个驱动器给你。
如果一个驱动器走了，小秘书道歉，并说他不再有该设备上的文件，但他可以给你所有的其他人。
我没有testing过这个，但是我会安装每个磁盘，并使用像UnionFS或mhddfs这样的文件系统将它们合并在一起。 这样，如果一个磁盘发生故障，只有该磁盘上的文件丢失，这正是你正在寻找的。
这可能是一个延伸，但是由于您只关心特定存储单元上的文件的完整性，请查看这里提到的ZFS文件系统副本选项，并在Oracle网站的这里和这里详细介绍（如“ditto-blocks”）。 这非常重视文件级保护，但可能与您正在寻找的内容保持一致。
目前，ZFS可用于某些Linux发行版，因此Solaris衍生的操作系统不再是一个严格的要求。
没有，如果没有，但是 – 在实际的机器上你需要某种forms的RAID，我知道你正在做整个复制，但是你不能指望处理单个驱动器故障 – 即使你只是有巨大的R6arrays，它总比没有好。
除此之外，它听起来像你只需要一个群集文件系统，像gluster，hadoop dfs或类似的东西。
如果您在应用程序级别处理容错，我会使用更便宜/更小的服务器。 如果应用程序正确分发，这意味着它将运行得更快。
另一种select（不知道是否可能）可能会运行针对每个磁盘的应用程序的多个实例。
我认为Raidarrays不适合您的使用情况。
问候。