自建存儲與使用微軟Azure、七牛等第三方雲存儲綜合考察分析

 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

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. 使用第三方雲存儲方案對比

目前在國內市場作雲主機的基本都有專門的存儲系統，在本方案中，只側重於存儲方面，而不涉及雲主機及其它服務。咱們以前在挑選存儲合做夥伴時，作了一個對比表格：

其實在通過技術指數對比後感受七牛雲比較適合咱們的應用，專門作存儲，支持功能多，文檔清晰價格也還能夠。但後來經朋友介紹，瞭解到微軟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萬之後其花費花更多一些。所謂合適，其實就是某種程度上的折衷，適合咱們的纔是最好的。

http://www.cnblogs.com/sennly/p/4136734.html