EMC ScaleIO 與 Starwind Virtual SAN
我正在設置一個測試實驗室來評估未來生產使用的最佳解決方案。用於 SMB 的生產場，因此存在預算，但也有限。
生產目標：3 台具有 Windows Server 2012 R2 故障轉移虛擬化集群和軟體定義儲存解決方案作為共享儲存的超融合伺服器。短期內，集群將擴展到總共 5 台伺服器。SAN 網路是專用的。
測試實驗室的目標：找到滿足以下條件的 SDS 解決方案：
為 Hyper-V 集群提供共享儲存。
橫向擴展：可以在不關閉集群的情況下添加-刪除磁碟（最好也包括節點）。
3.容錯。在失去 1 個節點後可用（如果在失去 2 個節點後可以恢復 - 這太棒了！）。
低網路成本/延遲（也將用於 SQL Server）。
定價合理（Storage Spaces Direct 因此不可接受）。
在閱讀並查看了一些產品之後，我的候選名單是 EMC ScaleIO 和 Starwind Virtual SAN。
兩種都試了，發現星風VSAN提供的HA非常有限：據我了解，這個方案只是跨節點鏡像虛擬磁碟（即文件），只允許在託管磁碟的範圍內擴展容量。相反，ScaleIO 將數據分佈在節點之間，並允許添加新的儲存和重新平衡卷。
所以，我的問題是：
- 我的假設是否正確，或者 Starwind VSAN 允許在每個節點的多個磁碟上創建 HA 卷並稍後添加磁碟？
- 您認為哪種解決方案更適合我的應用程序（請解釋）？
- 建議解決方案的缺點是什麼？
先感謝您！
這裡沒有好壞之分：兩種 ref’d 解決方案只是在擴展方式、在集群節點之間分配數據的方式以及處理組件故障的方式上大不相同。
1）**寬條帶與數據局部性。**SIO 執行所謂的“寬條帶化”：它們將捲數據保留在所有集群節點上（與 VMware VSAN 和 HPE VSA 相同），而 StarWind 則負責所謂的“數據局部性”（與 Nutanix NDFS 和SimpliVity/HPE 會這樣做）並將數據保存在有限數量的“合作夥伴”上。實際上，這兩種方法各有利弊。
https://www.nutanix.com/2013/12/03/data-locality-sql-vdi-on-the-same-nutanix-cluster/
https://www.simplivity.com/blog/2016/05/importance-data-locality/
https://www.starwindsoftware.com/data-locality-page
2)**單一統一地址空間與虛擬磁碟。**SIO 確實可以創建一個統一的地址空間，但現實情況是它在您的環境中是一個無用的（至少！充其量是壞主意！）功能：Microsoft / Hyper-V 確實需要每個集群節點至少一個 CSV / 虛擬 LUN，所以在您的情況下，虛擬 LUN 的最佳數量是相同的，無論您使用 SIO 還是 StarWind。
https://technet.microsoft.com/en-us/library/jj612868%28v=ws.11%29.aspx
https://www.petri.com/how-many-csvs-should-a-scale-out-file-server-have
https://blogs.msdn.microsoft.com/clustering/2013/12/02/cluster-shared-volume-csv-inside-out/
3）**節點數量和容錯能力。**SIO 在這裡與 Ceph 非常相似：它需要相當多的節點（8-10）才能獲得合理的性能（感謝“寬條帶化”）。還要確保您了解 SIO 僅用於複製，最終容量為 (N-1)/2，因此五個節點將為您提供 2 個節點容量，可用於 2 路複製，並且僅失去一個節點 (N+1)。StarWind 使用複制和本地重構程式碼（糾刪碼）的組合來同時承受多個故障，這要歸功於多個故障域，不僅有跨節點複製保護，還有類似本地“RAID”的保護，同樣方式 SimpliVity 和微軟在 Azure/S2D 中所做的類似。
https://www.emc.com/collateral/white-papers/h15148-emc-scaleio-deployment-guide.pdf
https://www.simplivity.com/blog/2016/10/data-storage-built-resiliency/
https://www.microsoft.com/en-us/research/publication/erasure-coding-in-windows-azure-storage/
https://www.starwindsoftware.com/grid-architecture-page
TL;DR：總的來說，我建議為這兩個候選名單建立一個 POC，看看一切進展如何。