用於開發的 RAID 0
各位管理員您好，我正在就以下情況尋求高級指導：
首先是環境的上下文：內部，所有虛擬（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 類型，統一儲存更易於管理。