我即将build立一个由5个物理服务器节点组成的Linux集群（可能会在稍后添加更多的节点）。
剩下的一个决定是使用软件RAID1还是硬件RAID1 + BBU 。
软件RAID是我非常熟悉的解决scheme（15年来，我pipe理着许多服务器，我知道这些工具是如何工作的）。 我从来没有一个严重的问题（主要是只有硬盘故障）。 这就是我更喜欢软件RAID的原因。
我对硬件RAID不喜欢的地方是控制器厂商之间的不兼容性，以及我所缺乏的经验：不同的configuration选项，不同的监控方法，不同的应用程序 – 不是创build集群系统的好感觉。
我知道，使用BBU时，硬件RAID既可以快速又可靠 （通过caching写入）。 但是，由于所有数据都将以高度冗余的方式存储在群集中，我的想法是使用软件RAID1并禁用文件系统中的障碍来提高写入性能。 我预计这将导致类似的硬件RAID1性能 。 当然，由于易失性写入caching，我有可能会丢失数据，但恕我直言，应该由群集机制来处理（整个机器应该能够在失败后从其他节点恢复数据）。
我不担心软件RAID实现所需的CPU资源。
我的假设是正确的还是错过了一些可以帮助我做出正确select的重要细节？
我更喜欢单个服务器上的硬件RAID，因为硬件RAID会迫使pipe理员采取预防措施防止RAID控制器的硬件故障。 这通常需要备货和定期testing备用RAID控制器。
但是，在您的设置中，我假定冗余位于节点级别，而不是磁盘级别。 如果某个节点由于某种原因（CPU，电源，RAID控制器等）发生故障，那么该节点将离开集群，并且将被ASAPreplace为新的或修复的节点，然后将从集群重build数据，而不是从RAID。 话虽如此，问题是，你是否需要一个RAID！
你可能会说：“我的数据库大部分都是读取的，RAID 1将会使吞吐量增加一倍，因为读取可以在两个磁盘之间分配”。 但请注意，磁盘故障，随后更换该磁盘并重buildRAID会将该节点上的读取速率临时降低到单个磁盘级别。 如果你的数据库不能通过给慢速节点提供较less的stream量来共享不相等的节点之间的stream量，那么数据库可以处理的整个负载就会降到正常值的一半！ 这可能会迫使你无论如何都要把一个磁盘故障的节点完全从数据库中删除，因为它正在忙于其内部的RAID重build。 但是这使得RAID大多无用。
另一种方法是不使用任何RAID，但让任何节点join数据库两次，每个磁盘一次。 这会让更多的burdon在CPU上，但是如果磁盘是你的限制因素，那么谁在乎CPU时间呢？ 如果磁盘发生故障，则该特定的半节点将脱机，并在磁盘更换后重新join。 所以负载将被公平地分配给所有的磁盘。
如果写入负载较高，则单独的磁盘解决scheme将使您的写入吞吐量比RAID 1高出一倍。
所以基本上，仍然考虑BBU的唯一原因是，如果您的延迟要求太窄，您不能等待数据物理上去磁盘。 如果发生电源故障，BBU将确保数据仍然被写入。 但是还有其他的select，比如dm-cache或bcache等固态盘caching模块。 在写回模式下，他们首先将数据写入SSD，这比写入磁盘快得多，然后已经提交写入。 即使发生电源故障，他们也会正确读取SSD中的数据块。 dm-cache和bcache都附带了所有最新的linux内核，而一个小的（如64或128 GB）服务器级（!!）SSD仍然比BBU RAID控制器便宜。