擴展 NFS 掛載的 Web 伺服器和線上文件儲存
因此，幾個月前，我的老闆向我拋出“我們需要在相當短的時間內擴展到 X 客戶會發生什麼。” 那種情景，如果有的話，有點工程挑戰，但當然更多的客戶意味著更多的收入。
所以，現在我們有一個類似於下面的設置。冗餘負載均衡器，從兩個 Web 伺服器（通過 memcache 共享的會話）和兩個後端完全冗餘的文件伺服器提供數據。每個文件伺服器都有整個shabang，跨驅動器的RAID6陣列，熱空間驅動器，雙raid控制器，雙網卡，多路徑yada yada yada。
該設計是我認為可靠的設計，無單點故障的高可用性。通過將負載拆分到多個 Web 伺服器來實現高性能，在某種意義上說我們應該能夠保持水平添加越來越多的機器以擴展到越來越多的客戶端，從而實現高可擴展性。主要瓶頸是每個文件伺服器可以容納多少儲存空間，以及為每個客戶端分配多少空間。這部分的擴展速度將比系統的其餘部分更快。選擇文件伺服器/客戶端“池”路線是因為它可以水平擴展並且比說“好吧，我們需要購買更大的 SAN”更便宜。
所以，這一切都很容易，越來越多的線上儲存，意味著越來越多的 NFS 掛載。這就是我的猜測發揮作用的地方。我想確保在把任何東西落實到位之前，我已經解決了這個設計中的所有潛在問題。只要這個謎題的每一塊都得到適當的監控，我認為它是可控的，但我想先得到一些其他的意見，也許是從以前走這條路的人那裡得到的。
我知道一些必須注意的關鍵問題。
- 文件伺服器上的熱點或特定機器上的熱點比池的其餘部分更努力。
- 頻寬和後端切換。由於網路伺服器與 NFS 設備之間會有很多對話，因此必須配備具有高交換結構容量的高質量交換機。
未知問題…
- 網路伺服器上的 NFS 掛載，讓每個網路伺服器在任何給定時間打開 2…5…10…100 個 NFS 掛載會不會有任何問題？有什麼方法可以使這更容易或更友好？也許是某種 NFS 代理？（這會產生一個內部瓶頸，這讓我皺眉）。我考慮了一個分佈式文件系統，並讓網路伺服器安裝它，但是似乎非專有、POSIX 兼容、可擴展而無需停機、內部冗餘文件系統對於生產工作來說要麼太不成熟，要麼非常昂貴，要麼真的善於躲避Google。
讓我知道你們的想法，如果您看到任何建議和優化，將不勝感激。
（（由於它是一個開放式問題，沒有一個特定的“正確答案”，問題是社區 Wiki））
在您將遇到的 90% 的託管情況中，您將擁有比儲存伺服器更多的網路伺服器，這會極大地改變您的網路設計。您將成對執行儲存伺服器，因為許多主/主文件伺服器僅支持鏡像複製。如果您有一個 10g 的骨幹網，大型 NFS 伺服器可能會處理十幾個網路伺服器。您的連接線將是虛擬連接，因為您將在一個 vlan 上執行 web lan，在單獨的 vlan 上執行儲存 lan，web lan 為 gigE，儲存 lan 為 10g，具體取決於預算。您提到了雙主記憶體儲伺服器，然後提到了 NFS 掛載，這有點排他性。他們是真正執行無共享還是雙頭/雙架/單fcal設置？
在雙主伺服器中執行負載均衡器以減少切換時間並增加潛在吞吐量。不要使用超過 40% 的容量，以便在出現故障時有足夠的備用空間。
您還需要考慮 MySQL/PostgreSQL/Cassandra/etc 集群——它們並不特別喜歡 NFS 掛載。
Lefthand Networks 有一個分佈式文件系統產品。GlusterFS 有點成熟，可以根據您的工作量工作。MogileFS/Hadoop 是另一種可能性。另外，看看 Ceph、GFS 和 OCFS。
至於掛載次數，您將在每個網路伺服器上掛載每個 NFS 伺服器一次或兩次。數十個掛載並非聞所未聞，但是，您最終可能會隔離您的 Web 集群以消除數百個掛載。Hadoop 可以將自己作為跨分佈式網路的單個全域文件系統呈現給您的網路。