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

1. 原始方案

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

?

2.mfs 方案

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

?

3. iscsi級聯(lián)+raid方案

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

?

4.負載均衡方案

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

?

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

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

結(jié)語：

最終我們采用了方案3。

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

?

私有云存儲服務(wù)4節(jié)點部署各方案對比