各位管理员您好，我正在就以下情况寻求高级指导：
首先是环境的上下文：内部，所有虚拟（vmware），仅用于开发，在整个堆栈中优化性能，停机时间是可以接受的（一次几台服务器 1-2 天），预算意识强，大量写入 OLTP工作负载，SAN（Synology 全闪存 SAS）和主机之间的 10Gbps 链接，小团队我们都不是正式的 DBA，所有数据库都有简单的恢复模型，SAN 卷是 ext4，LUN 上的厚配置也是如此。
由于我只是一个婴儿管理员备份和冗余已经冲击到我的脑海。直到现在我一直遵循它，因为预算有限，并且有 90 TB 的大量数据跨 20 台服务器（Linux 上的 SQL Server（Ubuntu 以避免 Windows 许可成本））和大约 40 个数据库。因此我们使用 RAID 0。这样做是因为我们有繁重的写入工作负载，并且用例/应用程序/业务即使是开发也需要高吞吐量，所有驱动器都在支持列表中。
导致当前配置的情况有很多。配置是，单卷存储池（RAID 0 中的 4 个 4/8TB SSD），单卷，单 LUN，单 VMFS，如果 4TB 驱动器卷有 2-6 个 VM（6 到 2TB），则为 8TB 的两倍，厚渴望配置，SAN LUN 使用 98% 的可用容量，其他一切使用 100%。我知道这会降低容量规划的全面可见性，否则此处未涵盖如何处理。因为我们使用 RAID 0 来节省成本和提高性能，所以我们将其限制为 4 个驱动器，以在驱动器发生故障时减少受影响的服务器。这也有助于服务器不相互冲突，使用 vmware IO 限制的意愿很低。
为了便于讨论，假设不可能大幅增加预算（2,000 美元以上）。应该知道，我们对停机风险有完整的 c 级签名。
最后一点，我们必须有几个 50TB 的数据存储，其中存储池配置为 RAID 10 8 x 7.2K HDD，而不是 RAID 0 和 SSD，这种性能水平还不够，因为工作负载对于HDDS 可以产生的 IOPS。
这给我们带来了我的问题，考虑到这些限制，这是一种提高性能的好方法吗？其他人对类似的目标和限制做了什么？请记住，在驱动器故障的情况下，某些服务器一次停机是可以接受的，因为这不是生产工作负载，而是在 AWS 和 Azure 上。
我知道这个问题跨越了很多领域，但我也知道现在很多 DBA 不得不熟悉这些领域，我真的在为那些有类似情况的人寻求建议。
谢谢
在白天完成备份还原测试。销毁存储卷以模拟 RAID 0 存储池故障，这将使测试系统停机。从备份媒体复制，并完成恢复。如果组织对恢复感到满意并能容忍这么长的停机时间，那么 RAID 0 方案就可以工作。（我怀疑他们会容忍几个小时，但也许吧。）
恢复测试对任何存储都很有用，但如果在第一次驱动器故障时需要恢复，则尤为重要。
在工作时间进行这样的恢复测试很重要。驱动器故障不等待数小时后。因此，这迫使用户了解恢复真正意味着多少停机时间。此外，您的系统管理员不应该为记录在案的不太重要的测试系统加班。
关于性能，为您的容量规划定义 IOPS 预算。从数据库、主机或存储阵列级别查看 IOPS 数字，并观察性能何时可以接受。
小块随机负载下的 7200 RPM 驱动器每个原始的 IOPS 可能为 70。不是很多。将您的 IOPS 要求除以该值，以近似所需的心轴数。对固态执行相同的操作，每个驱动器应该有数千个 IOPS。比较每 IOPS 的价格以及每容量的价格。
这几乎没有涵盖存储设计可能性的开始。例如，具有 SSD 和心轴的混合阵列是可能的。但是，那些在具有缓存层或像 RAID 4 这样的明显瓶颈的存储中效果最好。对于大多数 RAID 类型，统一存储更易于管理。