各位管理员大家好，我想针对以下情况寻求高层指导：
首先是环境背景：内部、全虚拟（vmware）、仅供开发使用、在整个堆栈中优化性能、停机时间是可以接受的（一次几台服务器需要 1-2 天）、注重预算、繁重的写入 OLTP 工作负载、SAN（Synology 全闪存 SAS）和主机之间的 10Gbps 链接、小团队，我们都不是正式的 DBA，所有数据库都有简单的恢复模型，san 卷是 ext4，LUN 上也有厚配置。
自从我还是新手管理员以来，备份和冗余就一直在我脑海中萦绕。我一直遵循这个原则，直到现在，因为预算有限，而且 20 台服务器（Linux 上的 SQL Server（Ubuntu 以避免 Windows 许可成本））上有大量 90 TB 的数据，大约有 40 个数据库。因此我们使用 RAID 0。这样做是因为我们有大量的写入工作负载，并且用例/应用程序/业务需要高吞吐量，即使是开发，所有驱动器都在 Synology 的支持列表中。
导致当前配置的情况有很多。配置为单卷存储池（RAID 0 中的 4 x 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，而不是带有 SSD 的 RAID 0，并且这种性能水平是不够的，因为工作负载对于 HDDS 可以产生的 IOPS 来说太多了。
这引出了我的问题，考虑到这些限制，这是否是一种提高性能的好方法？其他人针对类似的目标和限制做了什么？请记住，在驱动器发生故障的情况下，一些服务器同时停机是可以接受的，因为这不是生产工作负载，那些工作负载在 AWS 和 Azure 上。
我知道这个问题涉及很多领域，但我也知道现在很多 DBA 必须熟悉这些领域，我真的希望为有类似情况的人寻求建议。
谢谢
答案1
在白天完成备份恢复测试。销毁存储卷以模拟 RAID 0 存储池故障，这将导致测试系统瘫痪。从备份媒体复制并完成恢复。如果组织对恢复感到满意并能容忍这种停机时间，那么 RAID 0 方案就可以奏效。（我怀疑他们能否容忍几个小时的停机时间，但也许可以。）
恢复测试对于任何存储都很有用，但如果在第一次驱动器故障时需要恢复，则恢复测试尤为重要。
在工作时间进行这样的恢复测试很重要。驱动器故障不会等到下班后。因此，这迫使用户意识到恢复实际上意味着多少停机时间。此外，您作为系统管理员不应该在非工作时间工作，因为测试系统的重要性已被记录得较低。
关于性能，请为您的容量规划定义 IOPS 预算。查看数据库、主机或存储阵列级别的 IOPS 数字，并观察性能何时可接受。
在小块随机负载下，7200 RPM 驱动器可能每个获得 70 IOPS，原始数据。不是很多。用这个值除以 IOPS 需求，即可估算出所需的主轴数量。固态驱动器也一样，每个驱动器应该有数千 IOPS。比较每 IOPS 价格以及每容量价格。
这仅仅涵盖了存储设计可能性的开始。例如，可以采用同时具有 SSD 和主轴的混合阵列。但是，这些阵列在具有缓存层或明显瓶颈（如 RAID 4）的存储中效果最佳。对于大多数 RAID 类型来说，统一存储更易于管理。