我即将建立一个由 5 个物理服务器节点组成的 Linux 集群（可能稍后会添加更多节点）。
- 集群将由普罗克斯莫克斯（是的，它在软件 RAID 中有效）
- 共享存储将采用格鲁斯特在多余的设置每个物理服务器都持有一块砖（因此，所有机器上的数据都可以冗余使用）
- Percona XtraDB 集群将用作主多主数据库 - 同样由所有物理机器共享数据
- 每台机器将配备两块硬盘，每块大小约为 2-3 TB，采用 RAID1 设置
- 所有机器都将托管在具有冗余电源等的大型数据中心。
- 可以看到服务器规格这里
- 整个集群的作用是分散工作负载 + 实现高可用性。一台机器随时可能宕机，但对整个系统来说不会造成问题。
剩下要做的决定之一是是否使用软件 RAID1或者硬件 RAID1 + BBU。
软件 RAID 是我非常熟悉的解决方案（我管理了 15 年的服务器，我知道这些工具是如何工作的）。我从来没有遇到过严重的问题（主要是硬盘故障）。以下是原因我更喜欢软件 RAID。
我不喜欢硬件 RAID 的原因是控制器供应商之间不兼容，而且我缺乏使用它们的经验：不同的配置选项、不同的监控方法、不同的实用程序 - 这对于创建集群系统来说感觉不太好。
我知道，使用 BBU 时，硬件 RAID 既可以快速地和可靠的（通过缓存写入）。但是，由于所有数据都将以高度冗余的方式存储在集群中，我的想法是使用软件 RAID1 和禁用文件系统中的屏障提高写入性能。我预计这将导致与硬件 RAID1 类似的性能当然，由于易失性写缓存，我冒着数据丢失的风险，但恕我直言，这应该由集群机制来处理（整个机器应该能够在故障后从其他节点恢复数据）。
我并不担心软件 RAID 实现所需的 CPU 资源。
我的假设正确吗？还是我遗漏了一些可以帮助我做出正确选择的重要细节？
答案1
在单台服务器上，我更喜欢软件 RAID 而不是硬件 RAID，因为硬件 RAID 迫使管理员采取预防措施，以防 RAID 控制器出现硬件故障。这通常需要储备并定期测试备用 RAID 控制器。
不过，在您的设置中，我假设冗余是在节点级别，而不是在磁盘级别。如果某个节点因任何原因（CPU、电源、RAID 控制器等）发生故障，该节点将脱离集群，并尽快用新节点或修复后的节点替换，然后数据将从集群重建，而不是从 RAID 重建。话虽如此，问题是，您是否需要 RAID！
您可能会说：“我的数据库大部分是读取的，RAID 1 大约会使吞吐量翻倍，因为读取可以分布在两个磁盘之间”。但请注意，磁盘故障后更换该磁盘并重建 RAID 会暂时将该节点上的读取率降低到单个磁盘级别。如果您的数据库无法通过向慢速节点提供较少的流量来在不平等的节点之间合理地共享流量，那么数据库可以处理的整个负载将下降到正常值的一半！这可能会迫使您将发生磁盘故障的节点完全从数据库中移除，只要它忙于其内部 RAID 重建。但这会使 RAID 几乎毫无用处。
另一种方法是不使用任何 RAID，而是让任何节点两次加入数据库，每个磁盘一次。这会给 CPU 带来更多负担，但如果磁盘是您的限制因素，那么谁会关心 CPU 时间呢？如果磁盘发生故障，该特定半节点将脱机，并在更换磁盘后再次加入。因此，负载将公平地分担到所有磁盘。
如果写入负载较高，则独立磁盘解决方案将提供比 RAID 1 两倍的写入吞吐量。
因此，基本上，仍然考虑 BBU 的唯一原因是，如果您的延迟要求非常窄，以至于您无法等待数据物理进入磁盘。如果发生电源故障，BBU 将确保数据仍被写入。但也有替代方案，即 SSD 缓存模块，如 dm-cache 或 bcache。在写回模式下，它们首先将数据写入 SSD，这比写入磁盘要快得多，然后已经提交写入。即使在断电后，它们也会正确地从 SSD 读取块。dm-cache 和 bcache 随附所有最新的 Linux 内核，小型（如 64 或 128 GB）服务器级（！！）SSD 仍然比 BBU RAID 控制器便宜。