各位管理员您好，我正在就以下情况寻求高级指导：
首先是环境的上下文：内部，所有虚拟（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 不得不熟悉这些领域，我真的在为那些有类似情况的人寻求建议。
谢谢