http://www.cnblogs.com/sennly/p/4136734.html
各種雲服務這兩年炒的火熱，加之可以降低成本，公司想先在部分業務上嘗試使用下，剛好最近有個項目有大量小文件需要存儲，借着這個機會，研究分析下自建存儲與使用第三方雲存儲，如果小規模試用后滿意的話，會將更多的業務遷移到公有雲上去。
一般而言存儲功能我們會關注方案的功能可靠性及綜合使用成本兩大方面。
功能可靠性包含：
Ø 服務穩定性
Ø 服務性能
Ø 服務可擴展性
Ø 數據安全性
綜合使用成本包含：
Ø 存儲設備費用
Ø 帶寬費用
Ø 額外備份費用
Ø 后期維護費用
我們下面從幾個主要關注點來分析。
1. 自建存儲的性能分析與預估
目前分布式文件系統用的較多的有MFS、TFS、FastDFS等，，TFS對運維同學的要求比較高，需要對TFS本身有較多了解，且淘寶對外開源的版本不太穩定，這一方面我們踩過坑。在我們以往的項目中，MFS使用的較多，簡單，方便，可通過Fuse直接掛載到系統中，對於不是非常大量的小文件存儲很合適，有不足的地方就是其較輕量級，應付不了很密集的訪問。
1.1. 測試環境
測試環境有5台機器做存儲服務，1台Master，3台客戶端，通過1000Mbps網卡相連。
| 名稱 |
CPU |
內存 |
硬盤 |
| Master |
8核 HT |
32G |
15K Raid5 |
| Trunk |
8核 HT |
32G |
15K Raid5 |
| Trunk |
8核 HT |
32G |
15K Raid5 |
| Trunk |
8核 HT |
32G |
15K Raid5 |
| Trunk |
8核 HT |
32G |
15K Raid5 |
| Trunk |
8核 HT |
32G |
15K Raid5 |
| Client |
8核 HT |
32G |
15K Raid5 |
| Client |
8核 HT |
32G |
15K Raid5 |
| Client |
8核 HT |
32G |
15K Raid5 |
1.2. 業務場景相關數值估算
Ø 上傳圖片用戶數
我們這個子項目目標用戶量是2000萬，因此以2000萬為用戶基數。由於沒有有效的歷史數據，因此在活躍用戶估算、上傳圖片用戶估算過程中，我們廣泛使用80/20法則，以這種方法，估算出日活躍用戶、上傳圖片用戶數。
日活躍用戶數：2000萬X 0.2 = 400萬
上傳圖片用戶數：400萬 X 0.2 = 80萬
Ø 上傳圖片大小
我們假設用戶上傳原圖大小為2M
Ø 活躍時間分布
同樣使用80/20法則，每天24小時中有大概16個小時是人的活動時間，我們假設其中的20%時間用戶發送圖片且均衡分布，那么我們計算出活躍時間為：16 x 0.2 =3.2小時。
1.3. 內存預估
在官方文檔中我們查到2500萬個文件大概要占用Master Server 8G內存，因為MFS的技術架構所有文件的meta信息只能存儲在Master Server中，因此不能平行擴展。業務上線初期，我們計划子項目的存儲系統須滿足正常情況下1個月的需求，上傳圖片的活躍用戶數為80萬，每人每天上傳1張圖片，所需存儲文件總數為：80萬 X 30 = 2400萬。
每用戶每天平均上傳1張圖片內存預估
| 活躍用戶/萬 |
單用戶每天上傳圖片數 |
時間區間/月 |
總文件數/萬 |
內存/G |
| 80 |
1 |
1 |
2400 |
8 |
| 80 |
1 |
2 |
4800 |
16 |
| 80 |
1 |
3 |
7200 |
24 |
| 80 |
1 |
6 |
14400 |
48 |
| 80 |
1 |
12 |
28800 |
96 |
如果我們假設用戶每天平均上傳2張圖片呢？將會有如下數據：
每用戶每天平均上傳2張圖片內存預估
| 活躍用戶/萬 |
單用戶每天上傳圖片數 |
時間區間/月 |
總文件數/萬 |
內存/G |
| 80 |
2 |
1 |
4800 |
16 |
| 80 |
2 |
2 |
9600 |
32 |
| 80 |
2 |
3 |
14400 |
48 |
| 80 |
2 |
6 |
28800 |
96 |
| 80 |
2 |
12 |
57600 |
192 |
即，我們現有的32G內存的服務器，大概可以支撐前3個月。隨着時間延長，所需內存越來越多，如果平均每活躍用戶每天上傳2張圖片，那么1年之內需要一台256G內在的服務器。除可縱向增大服務器內存外，更靠譜的方式是進行業務拆分。
1.4. 存儲預估
在這里，我們同樣以用戶每天上傳圖片數及時間區間為變量分別計算。
| 活躍用戶/萬 |
單用戶每天上傳圖片數 |
時間區間/月 |
文件大小 |
文件備份數 |
總文件個數 |
磁盤空間/T |
| 80 |
1 |
1 |
2 |
3 |
2400 |
14.4 |
| 80 |
1 |
2 |
2 |
3 |
4800 |
28.8 |
| 80 |
1 |
3 |
2 |
3 |
7200 |
43.2 |
| 80 |
1 |
6 |
2 |
3 |
14400 |
86.4 |
| 80 |
1 |
12 |
2 |
3 |
28800 |
172.8 |
| 活躍用戶/萬 |
單用戶每天上傳圖片數 |
時間區間/月 |
文件大小 |
文件備份數 |
總文件個數/萬 |
磁盤空間/T |
| 80 |
2 |
1 |
2 |
3 |
4800 |
28.8 |
| 80 |
2 |
2 |
2 |
3 |
9600 |
57.6 |
| 80 |
2 |
3 |
2 |
3 |
14400 |
86.4 |
| 80 |
2 |
6 |
2 |
3 |
28800 |
172.8 |
| 80 |
2 |
12 |
2 |
3 |
57600 |
345.6 |
1.5. 並發量預估
Ø 上傳文件數每秒並發量
計算公式為：上傳圖片活躍用戶數X每天上傳圖片數/每天活躍時長X3600
800000X1/3.2X3600 = 69.4
800000X2/3.2X3600 = 138.8
若活躍用戶數每天上傳1張圖片，圖片上傳接口須滿足至少每秒上傳69.4個文件
若活躍用戶數每天上傳2張圖片，圖片上傳接口須滿足至少每秒上傳138.8個文件
Ø 上傳流量每秒並發量
計算公式為：上傳文件數每秒並發量X圖片平均大小
使用上面得出的上傳文件數每秒並發量，圖片平均大小為2，得出以下結果：
69.2X2M = 138.8M
138.8*2M = 277.6M
若活躍用戶數每天上傳1張圖片，圖片上傳接口須滿足至少每秒上傳138.8M流量
若活躍用戶數每天上傳2張圖片，圖片上傳接口須滿足至少每秒上傳277.6M流量
1.6. MFS性能測試
在我們的測試環境中，5台Trunk Server，3台Client，千兆的交換網絡，測試出以下結果。
雙機並發測試
| 大小/M |
個數 |
文件總大小 |
花費時間 |
速率個/秒 |
速率M/S |
| 0.25 |
80000 |
20000 |
456 |
175 |
44 |
| 0.5 |
40000 |
20000 |
332 |
120 |
60 |
| 1 |
20000 |
20000 |
258.5 |
77 |
77 |
| 2 |
10000 |
20000 |
247 |
40 |
81 |
三機並發測試
| 大小/M |
個數 |
文件總大小 |
花費時間 |
速率個/秒 |
速率M/S |
| 0.125 |
240000 |
30000 |
1106 |
217 |
27 |
| 1 |
30000 |
30000 |
367 |
82 |
82 |
| 2 |
15000 |
30000 |
343 |
44 |
87 |
測試結果總結如下：
Ø 文件上傳個數的速率與上傳文件大小成反比，文件越小，每秒鍾上傳個數越多。
Ø 文件上傳流量的速率與上傳文件大小成正比，文件越大，每秒鍾上傳流量速率越大。
1.7. 理論數據與實驗數據的對比
現在讓我們將上面理論估算出來的值與測試環境中所得結果做一對比，主要看每秒鍾上傳文件個數與流量速率。
Ø 每秒鍾上傳文件個數
每天上傳1張圖片理論需求：69.4
每天上傳2張圖片理論需求：138.8
實際能力：44
Ø 每秒鍾流量速率
每天上傳1張圖片理論需求：138.8MB
每天上傳2張圖片理論需求：277.6MB
實際能力：87MB
注意：
以上只是單純的上傳測試，在實際生產環境，是讀/寫混合操作，讀的數量會大大多於寫操作，因此以上所得到的值為理論極大值。實際業務不會是平均分布，往往會有大的短時並發。
1.8. 業務解決方案
MFS具有簡單易用的優點，但因其較輕量級，存在着一些缺陷。通過以上的估算及測試，我們會發現單一的MFS似乎不能滿足我們基本業務需要，如果條件允許，則需要對業務進行切分，每個集群只應對一塊業務，以減縮業務量，而切分的依據則可根據本文中得出的相關數據。
2. 自建MFS存儲的測試數據
2.1. 1MB文件寫入
1M文件寫入，4台客戶端執行，共12GB數據，數據備份數為3
客戶端 花費時間
192.168.1.159 145
192.168.1.111 150
192.168.1.167 147
192.168.1.66 141
結果：每秒寫入速率為82m/s，寫入文件個數速率為：82pcs。
2.2. 128KB小文件寫入
128KB文件寫入，4台客戶端執行，共12GB數據，數據備份數為3
客戶端 花費時間
192.168.1.159 271
192.168.1.111 309
192.168.1.167 339
192.168.1.66 386
結果：每秒寫入速率為37.7m/s，寫入文件個數速率為：294pcs。
2.3. 1m文件讀取
1m文件讀取，4台客戶端執行，共12GB數據
客戶端 花費時間
192.168.1.159 61
192.168.1.111 157
192.168.1.167 113
192.168.1.66 137
結果：每秒讀取速率為105m/s，讀取文件個數速率為：105pcs。
2.4. 長時穩定性測試
1M文件寫入，4台客戶端執行，連續寫入測試 14.5小時 寫入文件4T 速度為 80.35m/s
![clip_image002[6]](/image/aHR0cHM6Ly9pbWFnZXMwLmNuYmxvZ3MuY29tL2Jsb2cvODIxODUvMjAxNDEyLzAyMTExOTEyMDMwODIzNi5naWY=.png "clip_image002[6]")
![clip_image004[6]](/image/aHR0cHM6Ly9pbWFnZXMwLmNuYmxvZ3MuY29tL2Jsb2cvODIxODUvMjAxNDEyLzAyMTExOTMxMzExNzE3OS5naWY=.png "clip_image004[6]")
3. 自建存儲系統的成本估算
以下以使用MFS自建存儲服務為例，核算其使用成本。假設未來業務的規范如下：
Ø 平均文件大小 2MB
Ø 文件數量 1000萬
Ø 每日上傳數量 100萬
3.1. 需求計算
Ø 存儲需求
存儲大概需要2T空間，如果使用3份冗余的話，則需要6T空間。
Ø 帶寬需求
根據2/8原則，將全天訪問量的80%（100萬X2X0.8），分布於20%的時間（24X0.2=4.8小時），因此計算出帶寬需求為：93MB/S。
3.2. 自建存儲服務器的預計成本
Ø 服務器及硬件
包含三台存儲服務器，1台Web服務器（兼圖片處理及視頻處理），此處未做服務器的高可用及單獨的計算模組，最低綜合成本為：2萬X4=8萬
Ø 服務器托管費
以BGP機房的一般價格8000元/年/台，計算，則一年期的服務器托管費為：8000X4=3.2萬
Ø 帶寬費用
由於需求計算中所需帶寬為93MB/S，因此我們至少需要1G帶寬，以每100元/Mb/月價格計算，則一年期帶寬費用為100X1000X12=120萬
Ø 人力及維護成本
以維護人員薪資8000/月計，此人員每年平均使用20%的精力維護此組服務，則全年人力及維護成本為：8000X12X0.2=2.4萬
經綜合計算，自建存儲服務器最低成本為：8萬+3.2萬+120萬+2.4萬=133.6萬 ，因為不能按需使用，因此只能按照規划容量購買資源。
還有一種方式為使用普通機房的帶寬（如東莞的資源），帶寬便宜，20元/Mb/月，外加CDN加速，由於帶寬主要還是在CDN上，而CDN價格一般在100元/Mb/月，因此價格不會少，反而可能會多。
4. 使用第三方雲存儲方案對比
目前在國內市場做雲主機的基本都有專門的存儲系統，在本方案中，只側重於存儲方面，而不涉及雲主機及其它服務。我們之前在挑選存儲合作伙伴時，做了一個對比表格：
![clip_image006[6]](/image/aHR0cHM6Ly9pbWFnZXMwLmNuYmxvZ3MuY29tL2Jsb2cvODIxODUvMjAxNDEyLzAyMTExOTMyMzQyMzc2My5naWY=.png "clip_image006[6]")
其實在經過技術指數對比后感覺七牛雲比較適合我們的應用，專門做存儲，支持功能多，文檔清晰價格也還可以。但后來經朋友介紹，了解到微軟Azure已經在中國大陸運營，運營方是鼎鼎大名的世紀互聯，因此又分配了些人力對微軟Azure的雲存儲做了調研，綜合分析后得出結論：微軟的雲存儲更適合我們。
4.1. 成本對比
七牛雲收費的大頭在流量，而存儲本身占用的比例很小，只有10%左右；微軟Azure的存儲使用成本與七牛雲不同，其帶寬成本低，每個月前20T流量免費，而存儲本身成本高，1T的存儲每個月需要1000元左右，如果將這個項目的全部數據放在Azure上的話，費用非常嚇人，但與運營的同事咨詢后得知我們這個項目所上傳的文件在一小段時間后是可以刪除的，存儲的文件最多也是2T，每月存儲成本在2000元左右。經過我們計算在控制文件存儲數量的情況下，微軟Azure的使用成本會更低。
4.2. 資源優勢對比
Windows Azure由世紀互聯運營，擁有北京、上海的頂級骨干機房，我們有做長期監控測試，網絡質量非常好，再加上微軟的技術實力及大規模的運營團隊來做服務保障，服務質量能夠得到保障。而七牛雲，雖然其功能完整且使用也方便，但其各項網絡及硬件資源可能無法與世紀互聯相比，因此為了保障業務后續的穩定性，我們更傾向於使用Windows Azure的存儲。
4.3. 七牛雲的SLA服務質量保證
我們特意查看了七牛雲的服務條款，對於SLA服務質量有如下描述，感覺服務質量級別不高。
Ø 數據安全
您了解七牛雲存儲無法保證其所提供的服務毫無瑕疵（如七牛雲存儲安全產品並不能保證您的硬件或軟件的絕對安全），同時七牛雲存儲承諾不斷提升服務質量與服務水平。所以您同意：即使七牛雲存儲提供的服務存在瑕疵，但上述瑕疵是當時行業技術水平所無法避免的，其將不被視為七牛雲存儲違約。您同意和七牛雲存儲一同合作解決上述瑕疵問題。
數據備份系您的義務和責任，七牛雲系統具有數據備份功能不意味着數據備份是七牛雲存儲的義務。七牛雲存儲不保證完全備份用戶數據，亦不對用戶數據備份工作或結果承擔任何責任。
您理解並充分認可，雖然七牛雲存儲已經建立（並將根據技術的發展不斷完善）必要的技術措施來防御包括計算機病毒、網絡入侵和攻擊破壞（包括但不限於DDoS）等危害網絡安全事項或行為（以下統稱該等行為），但鑒於網絡安全技術的局限性、相對性以及該等行為的不可預見性，因此如因您網站遭遇該等行為而給七牛雲存儲或者七牛雲存儲的其他用戶的網絡或服務器（包括但不限於本地及外地和國際的網絡、服務器等）帶來危害，或影響七牛雲存儲與國際互聯網或者七牛雲存儲與特定網絡、服務器及七牛雲存儲內部的通暢聯系，七牛雲存儲可決定暫停或終止服務。
Ø 終止協議
七牛雲存儲可提前30天在七牛官網上通告、給您發網站內通知以及郵件通知的方式終止本協議。屆時七牛雲存儲將您已支付但未消費的款項退還您指定的銀行賬戶或其它可收款賬戶。
Ø 服務質量及賠償
您理解，鑒於計算機、互聯網的特殊性，下述情況不屬於七牛雲存儲違約：七牛雲存儲在進行服務器配置、維護時，需要短時間中斷服務；由於互聯網上的通路阻塞造成您網站訪問速度下降；
如果因七牛雲存儲原因造成您不能正常使用七牛雲存儲服務的，七牛雲存儲以小時為單位向您賠償損失，即連續達1小時不能正常提供服務的，延長一小時的服務期（以此類推）。如果因七牛雲存儲原因造成您連續72小時不能正常使用服務的，或因七牛雲硬件故障而給您造成損失（非因七牛雲存儲過錯造成的故障除外），您可以終止接受服務並可以要求賠償損失，但非七牛雲存儲控制之內的原因引起的除外。
在任何情況下，七牛雲存儲均不對任何間接性、后果性、懲戒性、偶然性、特殊性的損害，包括您使用七牛雲存儲服務而遭受的利潤損失承擔責任（即使您已被告知該等損失的可能性）。
在任何情況下，七牛雲存儲對本協議所承擔的違約賠償責任總額不超過向您收取的違約所涉服務之年服務費總額的25%。
4.4. 微軟Azure的SLA服務質量保證
我們保證至少在 99.9% 的時間，我們將成功地處理請求以便讀取來自讀取訪問地域冗余存儲 (RA-GRS) 帳戶的數據，只要在輔助區域上重試從主區域讀取數據的失敗嘗試。 我們保證至少在 99.9% 的時間成功地處理請求以便從本地冗余存儲 (LRS)、區域冗余存儲 (ZRS) 和地域冗余存儲 (GRS) 帳戶讀取數據。 我們保證至少在 99.9% 的時間成功地處理請求以便將數據寫入本地冗余存儲 (LRS)、區域冗余存儲 (ZRS) 和地域冗余存儲 (GRS) 帳戶，以及讀取訪問地域冗余存儲 (RA-GRS) 帳戶。
我們在網絡上找尋了一些資料，有如下描述：
Microsoft Azure在全球從沒有丟失過數據，在中國提供3*2的備份，在上海和北京兩地各三份備份。第二是微軟的雲計算有混合的優勢，無論是私有雲、公有雲等，微軟都可以提供無縫的對接，包括開發環境、框架、安全、身份認證等。第三是承諾，微軟有技術、大規模運營的經驗，了解中國對標准政策的法律法規，花費很長時間儲備、建立研發團隊，尋找合作伙伴，建設數據中心，要做到無縫的運營、保證較高的穩定性和質量是很難的。由世紀互聯運營的Microsoft Azure提供99.95%的企業級服務等級協議（SLA）保證，每年停機檢修時間不超過4.38小時，用戶可以放心構建和運行高可用的應用程序，而不必擔心將經歷放在基礎架構上。
5. 我們的選擇
使用自建存儲服務器，由於不能彈性使用且無法合理預估使用量，因此簽合同時一般情況下只能按較大需求來購買資源，一年的使用成本為133萬左右，且需要熟悉分布式存儲的成熟的運維團隊來維護，自如建的成本更高。而使用第三方的雲存儲，則需要考慮的方面更多些，除了要考慮功能性是否滿足外，更重要的是穩定性、安全性以及品牌成熟度，畢竟管理層通常會認為大品牌的產品質量更有保證些。通過這次考查及分析，我們認為微軟Azure的雲存儲會更適合我們，雖然在我們這個子項目活躍用戶數達到1000萬以后其花費花更多一些。所謂合適，其實就是某種程度上的折衷，適合我們的才是最好的。