近日因工作需要在某高校安裝私有云存儲系統。部署環境是一臺4節點服務器，每個節點有16GB內存，3個硬盤，每個硬盤3TB ，每個節點可用空間約為8TB。部署的目標是充分利用所有的服務器資源，提供可靠的存儲服務，同時盡量不要修改我們的系統源代碼。由于本人在web服務部署經驗尚淺，遂問計于師哥，對比了如下多種部署方案。

1. 原始方案

• 說明：1節點部署ffmpeg轉碼服務，1節點部署私有云存儲系統（nginx+mysql+php代碼）。文件讀寫只在部署了私有云存儲的節點進行，日后購買磁盤陣列后將存儲掛載到磁盤陣列上。
• 優點：部署簡單
• 缺點：有2個節點完全沒有使用，作為轉碼服務的節點的空間利用率極低。實際可用的文件存儲空間只有安裝了云存儲系統的節點上的8TB空間。該節點壓力大，存在單點故障。
• 結論：浪費太大，可靠性差，不可

?

2.mfs 方案

• 說明：所有節點都部署mfs分布式文件系統。其中一個節點做mfs的元數據服務器，其他三個做mfs存儲服務器。此外對于這三個存儲服務器，用一臺部署nginx和php代碼做主web服務器，一臺部署ffmpeg轉碼服務，一臺部署mysql做數據庫服務器。
• 優點：首先，每個節點都得到了利用。其次，由于安裝了mfs，每個文件在三個節點中都有副本，數據安全性高，可靠性高。
• 缺點：mfs的三副本策略導致實際可用文件存儲空間只有8TB。雖然可以設置只用1副本來增加可用空間，但是會降低可靠性。mfs依然存在單點故障（mfs的元數據服務器）。這個架構中，mfs元數據服務器、或者mysql數據庫服務器、web服務器中有任意一臺掛掉都會導致整個服務中斷。此外，mfs安裝雖然容易，但是一旦發生故障我缺少處理經驗（能安裝和能排錯是完全不同的兩個層次）。
• 結論：此方案雖然服務器資源都用上了，但是在生產環境中維護成本高，單點故障多，并且空間依然只有8TB，所以再議。

?

3. iscsi級聯+raid方案

• 說明：一個節點部署ffmpeg轉碼服務，一個節點部署nginx和php代碼做主web服務器，一個節點安裝mysql做主數據庫服務器，一個節點安裝mysql做熱備數據庫服務器。除去每個節點必須的存儲空間外，剩下的存儲空間都使用iscsi級聯，并作raid10或raid5，掛載到web服務器上用于文件讀寫。
• 優點：所有節點都得到了利用，并且存儲空間利用率遠較前兩個方案高。設每個節點自用一個硬盤，另外兩個硬盤用于iscsi級聯，4個節點級聯后可用空間為24TB。采用raid10后，I/O速度提高兩倍，可靠性大幅提高，可用空間為變為12TB，依然比1，2方案高。若采用raid5，則1盤做冗余，7盤做存儲，可用空間為21TB。相對raid10而言空間利用率提高，讀寫速度降低。
• 缺點：存在一個單點故障——web服務器。
• 結論：此方案存儲空間利用率較之1，2方案而言大幅提高，并且可靠性不比2低：文件存儲空間有raid保護，數據庫有熱備，單點故障少。此外部署難度低，故障容易處理?？梢哉f是目前最好的方案。

?

4.負載均衡方案

• 說明：在3的基礎上，設置nginx負載均衡，讓主mysql服務器只負責寫，從mysql服務器只負責讀。
• 優點：主數據庫服務器負載有所下降。
• 缺點：要修改系統讀寫數據庫的源代碼，成本過高。
• 結論：在目前的4節點服務器中搞負載均衡實在是沒什么必要。由于轉碼服務需要大量cpu計算能力，所以必須分單獨一個節點來做。另外3個節點又必須分一個來單獨做數據庫服務器。對于剩下兩個節點，要么都做web服務器，要么一個做web服務器一個做從數據庫服務器。私有云存儲系統的主要壓力不在web服務，而是在數據庫讀寫和文件存儲中。所以負載均衡只能是對兩臺數據庫服務器來做，但是這樣要修改系統讀寫數據的源代碼，成本過高。不如方案3的雙機熱備。

?

5.使用openstack或者vmware vcenter搞多機虛擬化

• 說明：4個節點，一個做ffmpeg轉碼服務，另外3個物理節點用軟件openstack或者vmware vcenter變成一個虛擬機來部署安裝私有云存儲系統（nginx+mysql+php代碼）。
• 優點：只要搞定了虛擬機，代碼安裝部署比較容易。其他什么效率啊，安全啊，可靠性啊，都讓虛擬機軟件來做。
• 缺點：這種方式的虛擬機效率低，分布式共享內存效率好不了。本來內存延遲很小的，但是經過網絡之后，延遲會大幾個數量級。這又不是大型機。并且openstack和vmware vcenter這種部署方式，實際上要調的參數太多，我們并不精通，很容易出現故障，出現了也難以排除。
• 結論：這個方案顯然是一拍大腿想出來的。虛擬機雖然很好用，但是這樣引入了未知的黑洞。據我所知很少有生產環境這么搞的——效率是最直接的問題。聽說dell剛剛收購了一家公司是搞這個的，但是這種技術并不成熟。為此我還專門詢問了在做openstack的師哥，連他也沒見過這么搞的。新技術方案沒有充分的調研和實驗是不能直接上的。

結語：

最終我們采用了方案3。

系統部署方案有很多，但是每個都不是萬能的。什么是好？適應當前環境的就是好。就現在來看，方案3最好，實現了最小成本最高效率和可靠性。當然，想繼續優化也沒問題，但是從4，5兩個方案中可以看出，這樣的優化是代價越來越高，效果越來越小，帶來的副作用越來越多。搞負載均衡，那負載均衡的那個節點也是單點故障。其實要服務掛掉很容易，交換機一掛就全完了。就一個4節點服務器，還要怎么耍？把各種分布式文件系統都裝上？復雜性那么高，以后還要不要維護了？要知道簡單就是美。其實幾乎每本linux部署相關的書中一開始都會強調——“不要為了優化而優化”。只要滿足現在的要求并能為未來的優化留下空間就行，因為完美的要求永遠是動態變化的。

?

私有云存儲服務4節點部署各方案對比