gluster IOPS 性能
“gluster”能否僅使用內置 HTTP 協議在沒有任何前端伺服器層的情況下提供 FLV 文件？IOPS 與標準 apache 服務相比如何？如果我將許多機器連結在一起，gluster 會幫助我解決硬碟驅動器的 I/O 限制嗎？
謝謝！
如果我將很多機器連結在一起，Gluster 會幫助我解決硬碟驅動器的 I/O 限制嗎？
如果可以，它將用….網路限制代替它。我的意思是，說真的 - 如果您將 IO 分配到 50 台機器上，您的網路需要處理它。如果您遇到 IO 限制，而不僅僅是儲存區域限制（即 TB），那麼正確的解決方案是投資於專注於 IO 的解決方案。這不像他們不存在。
“Gluster”能否僅使用內置 HTTP 協議在沒有任何前端伺服器層的情況下提供 FLV 文件？
沒有文件協議通過 HTTP 服務；）
我認為 Gluster 就像一個中型/面向儲存的系統。是的，您可以獲得空間，而且無需大量管理，是的，您可以使用便宜的機器——比如將大硬碟驅動器放入每個工作站並將它們用作文件伺服器類型事物。
但是，如果您獲得 LARGE (youtube)，您可能仍然需要專用系統（即使它們執行 Gluster），並且如果您執行大量 IO，則需要使用內容集群服務於前端的 SAN 風格的基礎架構（即對文件進行分區，以便並非每個伺服器都必須記憶體所有內容）在邏輯上是唯一的解決方案。Gluster很聰明，它不會變魔術。實際服務伺服器上的記憶體可能會過載。
將 IO 從磁碟移動到網路會導致對網路有很多非常高的要求。您可能想閱讀 Infiniband - 它實際上在 Gluster 文件中被提及。但話雖如此，如果一個便宜的（1000 美元範圍）Raid 控制器可以處理大約 200 個 SATA 磁碟，那麼 IO 限制有什麼問題？您不需要很多機器（以更高的成本）來繞過 IO 限制。這總是比專用盒子貴（顯然你必須為更多的 CPU、更多的 RAM 等付費）。而且您不會使用 Gluster 保存任何光碟 - 在兩種情況下都需要完全冗餘的數據儲存，無論是否使用 Gluster。
也就是說，出於很多原因，建議使用前端伺服器。即使 Gluster 可以在沒有大型安裝的情況下處理，不使用分離的前端伺服器也是完全愚蠢的，最好在中間有一些防火牆。