我正在考虑为我们的 SQL Server 集群之一使用 RAID0 设置。我将概述情况并寻找为什么这可能是一个坏主意。此外，如果您有用例、白皮书或其他文档，您可以就这个主题向我指出，那就太好了。
我们在 2 个数据中心有 3 台服务器，它们是 SQL 集群的一部分。它们都在一个可用性组中运行 SQL Server。主节点旁边有一个副本，另一个位于另一个数据中心。他们正在运行具有自动故障转移功能的同步复制。所有驱动器都是企业级 SSD。他们将运行 SQL Server 2017 或 2019。
我认为与其他方法相比，在 RAID0 阵列上运行它们会有很多好处，而且几乎没有真正的缺点。我目前看到的唯一负面影响是主服务器上缺乏冗余，因此失败率增加。作为优点：
如果驱动器发生故障，而不是在有人收到通知并对其进行手动操作之前以缓慢、降级的状态运行，则服务器将立即无法保持完整的操作能力。这将有一个额外的好处，即通知我们故障转移，因此我们可以更快地调查原因。
它降低了每 TB 容量的整体故障几率。由于我们不需要奇偶校验或镜像驱动器，因此我们减少了每个阵列的驱动器数量。驱动器越少，驱动器故障的总机会就越小。
这更便宜。为我们所需的容量需要更少的驱动器显然成本更低。
我知道这不是传统的商业思维，但有什么我没有考虑的吗？我喜欢任何赞成或反对的意见。
我不是为了提高查询性能而尝试这样做，但如果有有意义的，请随时指出它们。我主要担心的是没有考虑或解决我没有想到的可靠性或冗余问题。
操作系统位于单独的镜像驱动器上，因此服务器本身应该保持正常运行。这些驱动器之一可以更换并再次镜像。它很小，除了系统数据库之外没有任何数据库文件。我无法想象这需要超过几分钟。如果其中一个数据阵列出现故障，我们会更换驱动器、重建阵列、恢复并与 AG 重新同步。根据我的个人经验，恢复比 RAID5 驱动器重建快得多。我从来没有遇到过 RAID1 故障，所以我不知道重建是否会更快。恢复将来自备份并前滚以匹配主服务器，因此主服务器上的负载增加应该非常小，仅将日志的最后几分钟与恢复的副本同步。