2018年XXX卡中心重點進行分佈式對象存儲池初期建設規劃。通過對語音存儲、雲計算平臺、影像平臺、圖片資源平臺等相關業務系統存儲需求進行調研，確定了各個業務系統系統對存儲資源池需求狀況。此外選取了當前國內具體一定實力的對象存儲廠商進行了相關的產品驗證，下面對本人一年之內所做工作進行一個完整總結。
- 完成分佈式對象存儲系統需求整理
初期，通過調研卡中心各個業務系統中文件存儲情況，對各個業務系統進行系統的需求整理。通過需求調研發現，當前卡中心非結構化文件存儲採用傳統文件存儲系統（如NAS）做爲主要存儲方案，NAS存在單卷容量上限（約100T）和文件數量上限的問題，而隨着文件數量的增加NAS的讀寫性能會明顯下降。爲了對後期存儲池建設提供數據支撐，和卡中心業務部門進行了詳細的文件數量估算，具體文件量如下：影像系統每月210 萬個文件，5 年存儲空間預估將超過4PB；語音系統每日50萬通錄音、每月1500 萬個文件，分析平臺使用3個月，錄音需存儲近2PB。
1、需求背景
目前卡中心採用傳統文件存儲系統（如NAS）做爲主要存儲方案，NAS存在單卷容量上限（約100T）和文件數量上限的問題，而隨着文件數量的增加NAS的讀寫性能會明顯下降。隨着業務的發展，文件量存儲將會急劇上升，比如影像系統每月210 萬個文件，5 年存儲空間預估將超過4PB；語音系統每日50萬通錄音、每月1500 萬個文件，分析平臺使用3個月，錄音需存儲近2PB。目前NAS主要通過分卷的形式提供服務來降低單卷容量和減少文件數量，同時多卷組合提供大容量服務來臨時解決海量文件存儲問題，同時將歷史數據歸檔來降低在線數據的容量需求。爲解決海量文件存儲問題，企業及解決方案是引入分佈式對象存儲，藉助軟件整合服務器及其磁盤資源，提高存儲的服務器能力，實現軟件定義存儲。
2、需求的業務可行性和必要性
通過以上需求調研，確認了分佈式對象存資源池完整建設需求。建設存儲資源池爲構建高可用、高性能的分佈式存儲系統，併爲影像系統、雲計算平臺、圖片資源平臺等業務系統提供存儲服務，滿足數據的全量存儲和實時在線訪問的需求，提高數據訪問效率。
3、需求目標
一期目標爲完成分佈式存儲的平臺建設，搭建完整的資源池，實現存儲資源的快速交付；對接現有的雲計算平臺的存儲模塊，併爲影像、語音等業務應用系統提供海量存儲服務，替換FastDFS爲圖片資源平臺提供圖像存儲，總容量規劃1PB。
4、業務概述
分佈式對象存儲提供高可用、高性能、易操作、易維護、易監控的存儲服務，並對接影像系統、雲計算平臺、FastDFS替換、語音平臺等業務系統，滿足數據的全量存儲和實時在線訪問。
容器雲計算平臺已經承載34套互聯網系統，近5000個容器，但是鏡像模塊和發佈模塊仍使用傳統存儲，文件系統侵入雲平臺主機層，存在嚴重的耦合現象。通過引入對象存儲，雲平臺通過API靈活調用，達到鏡像文件和發佈包與雲平臺完全解耦的目標。
影像平臺採用本地存儲（傳統NAS）分卷疊加的方式進行數據存儲，僅能滿足短期存儲的需求，現需將歷史影像數據及在線數據進行統一整合，達到數據永久保留以及影像實時調閱的業務目標，同時增加圖像處理（圖片轉換、圖片壓縮、水印處理、批量上傳下載、異常鑑別）和圖像智能識別（鑑黃、鑑暴、政治敏感識別）等功能，實現存儲和數據處理一體化功能。
目前圖片資源平臺存儲互聯網系統的圖像資源，使用FastDFS實現，並對外提供圖片瀏覽服務，隨着卡中心日益激增的業務需求，對接系統已達23個，需增加用戶、權限、鑑權、監控、配額、運維、報表等方面的功能，形成存儲的統一管理和可視化管理。
5、功能需求
功能性需求包括存儲平臺功能和數據處理功能兩大功能。
存儲平臺功能主要包括歷史版本、數據遷移、接口類型、存儲管理、安全管理、日誌管理、文件管理、多數據中心、監控管理、系統管理、報表統計等11個模塊，數據處理圖像處理、音視頻處理、其他處理等3個模塊。
6、非功能需求
非功能需求中從業務量指標、數據存儲要求、服務等級指標、存儲性能要求、高可用要求等方面進行了完整的概述，爲後期POC性能測試提供了完整需求參考。
7、風險預估及應急方案
爲了保證分佈式對象存儲的安全穩定，對系統運行過程中可能發生的風險點進行預估，並制定應急方案，及時排查解決系統異常。
- 硬件異常和處理機制
當硬盤發生故障時，停止硬盤服務，待業務低峯期停止服務器並更換硬盤，由於系統高可用，磁盤不影響存儲服務器。
當服務器發生異常時，服務器停止服務進行檢查，徹底查明原因後，再提供服務。由於系統高可用，服務器異常時不影響存儲服務。
- 軟件異常處理機制
系統有完善的日誌模塊和監控模塊，當發生軟件故障，可以快速定位故障點，並排除故障。系統提供高可用機制，單臺服務器軟件故障時不影響存儲服務。
- 系統網絡異常處理機制
如果系統網絡發生異常，及時調度相關技術人員，檢查網絡設備，更換或者重新裝配設備，保證儘快修復網絡異常。
- 數據庫異常處理機制
數據庫採用主備同步操作，做好數據的備份與保存。定期檢查數據庫硬件設備與性能指標，監控相關閥值設置，爲數據庫做健康檢查。
- 保障機制
定期或國家法定長假，國家重大會議活動等進行預防性維護服務，檢查系統的工作情況，記錄並分析系統的報警記錄及運行指標，排查故障和隱患，保證系統正常運行
- 完成分佈式對象存儲測試方案
爲了對各家供應商存儲產品進行驗證，在POC測試之前，制定了完成的測試方案，測試分爲兩個部分，功能性測試和非功能性測試。功能性測試包括存儲基本功能、數據處理功能，共計申請54臺虛擬機服務器；非功能性測試包括基準性能測試、100T數據模擬遷移測試等，共計申請存儲節點6臺（內存128G PCIE SSD卡1.6T×1），管理節點服務器：3臺 內存64G，壓力測試服務器：4臺 內存64G，數據庫服務器：1臺 內存64G。
1、功能性測試方案
功能性測試包括存儲基本功能和數據處理功能。
存儲基本功能從歷史版本、數據遷移、接口類型、存儲管理、數據安全管理、日誌管理、文件管理、多數據中心、監控管理、系統管理、生命週期管理、報表統計、服務器管理、內外網管理、數據庫需求、其他功能等15個維度進行全面測試，共計131項測試案例。
數據處理功能從3個維度進行全面測試，包括圖片處理、視頻處理、其他，共計24項測試案例。
2、非功能性測試方案
非功能測試具體測試案例包括：100T數據遷移測試、Cosbench基準性能測試、高可用測試、穩定性測試、Poc測試系統優缺點等。
從以上幾個維度制定了完整的存儲測試方案，爲後期各家廠商產品測試提供了完整的測試參考用例依據。
- 完成廠商POC測試報告
經過前期功能需求、非功能需求、業務功能需求以及方案審覈調研，選定6家供應商進行對象存儲POC測試，六家廠商產品測試周期爲3個多月（2018-03-23至2018-06-30）。
POC測試測試中深入瞭解了各家廠商產品功能完整性、產品讀寫性能及其系統穩定性。通過對象存儲功能（20%）、圖像音視頻處理（10%）、100T數據遷移（20%）、cosbench併發讀寫速度和響應時間（32%）、PoC測試中發現的BUG（5%）、用戶體驗（5%）以及產品優勢（4%）和其他（4%）等維度進行了完整的POC測試，最終產生各家廠商POC測試報告。
- 完成對象存儲項目技術可行性方案
計劃第一階段實現對象存儲異地雙活集羣搭建，實現存儲資源的快速交付；對接現有的雲計算平臺的存儲模塊，併爲影像、語音等業務應用系統提供海量存儲服務，替換FastDFS爲好無聊系統提供圖像存儲，總容量規劃1PB。需求的適用範圍和影響範圍，包括行內機構適用範圍、用戶適用範圍、客戶適用範圍、渠道適用範圍等。
在非功能性需求中從以下維度進行了完整的考察。
1、讀寫性能
分別考察大文件和小文件在各種併發之下讀寫性能
|
讀寫性能考察維度 |
文件大小 |
4K |
|
16K |
||
|
256K |
||
|
1M |
||
|
4M |
||
|
20M |
||
|
256M |
||
|
512M |
||
|
併發數量 |
2G |
|
|
5G |
||
|
50 |
||
|
200 |
||
|
400 |
||
|
600 |
||
|
1000 |
||
|
2000 |
||
|
請求類型 |
上傳 |
|
|
下載 |
通過以上維度記錄文件平均讀寫速度、響應時間、procTime、TPS等指標值，如下圖：
|
read |
速度/MBps |
|
響應時間/ms |
|
|
procTime |
|
|
TPS/k |
|
|
write |
速度/MBps |
|
響應時間/ms |
|
|
procTime |
|
|
TPS/k |
2、集羣高可用
爲了保證集羣在個別異常情況之下能夠提供正常服務，並有自動感知、告警、處理異常能能力，需要搭建高可靠的集羣環境。分別從異地容災、集羣故障、服務器故障、磁盤損壞、應用崩潰等維度考察產品的高可用。
|
硬盤損壞 |
|
|
故障恢復 |
|
|
高併發是否數據統計錯誤 |
|
|
存儲節點服務器1-n故障 |
|
|
元數據節點故障/leader切換 |
|
|
網絡故障 |
|
|
存儲應用奔潰 |
|
3、系統穩定性
除了提供高可靠的分佈式資源池，還需要考慮在長時間、高負荷等環境之下系統的穩定性。需要從如下幾點考察系統服務能力：1、24小時無故障服務；2、大數據量情況iops指標無明顯變動；3、大數據量下吞吐量指標無明顯變化；4、系統負載在一定閥值下服務。具體通過對cpu，內存，網絡，io，磁盤等資源性能指標進行監控記錄。
|
24小時無故障服務 |
|
|
大數據量情況iops指標無明顯變動 |
|
|
大數據量下吞吐量指標無明顯變化 |
|
|
系統負載在一定閥值下服務 |
|
4、100T 數據遷移
爲了考察產品的最佳性能和穩定性，需要通過遷移100T數據來完成集羣在海量小文件數據執行系統性能。具體記錄的項目爲：1、100T數據推送是否中斷。2、數據寫入過程中系統是否平穩，iops波動情況3、隨着併發數增加，TPS和帶寬有增長趨勢，性能是否提升。4、數據遷移過程中系統內存，cpu相關資源負荷以及IO吞吐量記錄。此外還需要具體記錄如下指標，供後期對產品性能分析和判斷：
|
實際推送數據量 |
|
|
總遷移時間 |
|
|
平均推送速度 |
|
|
數據遷移bug記錄 |
|
|
系統資源指標記錄 |
|
|
成功遷移文件數 |
|
|
遷移失敗文件數 |
|
|
100T數據遷移優點記錄 |
|
5、安全需求
系統應以一定的安全機制保證業務系統數據與分佈式對象存儲數據讀寫的安全性，例如關鍵數據加密、數據一致性檢查、數據讀寫權限、提供多租戶功能，實現不同用戶之間的數據隔離訪問，並可控制用戶的配額管理；提供審計日誌功能，可以對文件的變更操作（增/刪/改）進行記錄和查詢；提供鑑權和授權機制，及白名單、防盜鏈、主子賬號功能。對於非法用戶和無讀寫權限數據做合法性校驗，給出明確錯誤提示，減少與後臺服務的交互。
- 完成對象存儲容量評估
爲了建設合理容量的存儲池，並且對未來5年內存儲需求提供建設依據，我們對當前卡中心業務系統容量進行了系統的調研評估。分別完成影像系統容量、雲計算平臺數據存儲容量、FastDFS存儲替換容量、企業網盤存儲容量、語音存儲容量相關業務系統容量評估。具體評估數據統計如下。
1、影像系統容量評估
當前影像系統歷史容量有80T數據量，一年增加320T數據。當前共有400T數據。考慮到數據存儲5年，並且年增20%數據量。通過計算共計2.4PB數據量。
|
業務需求 |
影像系統 |
|
容量 |
歷史：80T,一年：320T,共計：400T,考慮存儲5年，按年增20%計算，共計2.4P |
|
應用場景 |
圖片存儲,歷史爲tif，改造後爲jpg |
|
文件大小 |
1-5M不等 |
|
文件數量 |
每月210萬 |
|
文件處理 |
具體圖像處理需求溝通中 |
|
多中心 |
異地災備 |
|
存儲年限 |
永久 |
|
應用改造 |
NAS遷移到對象存儲 |
|
備註 |
對影像系統後期存儲評估：a) 按日進件量20w預估，每份申請的影像圖片包括展示圖和縮略圖（小圖），影像系統的圖片張數日增長量爲100w張（（20w+20w*15%*10）*2）；b) 按日進件量爲20w預估，考慮到後續無紙化申請項目的開展，將PAD進件申請量預估到30%，且附件大小預估爲30M/份；影像系統的存儲日增長量約900G（20w*30%*30M*50%+300K*20w）；當前一年900G*365/1024=320T |
2、雲計算平臺數據存儲評估
雲計算當前承載5000個容器應用。當前鏡像文件逐年增加。隨着業務的發展，鏡像文件、應用發佈包，依賴包等相關非結構化數據增加較快。通過計算單副本需要9T容量，考慮到3副本存儲，需要9T*3=27T存儲容量。
|
業務需求 |
雲計算平臺存儲 |
|
容量 |
9T |
|
應用場景 |
鏡像存儲、發佈包存儲、卷掛載 |
|
文件大小 |
未定 |
|
文件數量 |
百萬級別 |
|
文件處理 |
暫無 |
|
多中心 |
異地災備 |
|
存儲年限 |
永久 |
|
應用改造 |
GlusterFS遷移到對象存儲 |
|
備註 |
每個區域1TB，考慮兩地三中心，共4套環境，每套環境2個區域（WEB和APP），此外再加上一套內網區域，共計9T*3=27T |
3、FastDFS存儲替換容量評估
當前卡中心圖像資源平臺中，圖片存儲使用FastDFS進行存儲，並對外提供圖片瀏覽服務。由於FastDFS在運維管理、監控管理、用戶管理等功能較爲欠缺，因此需使用對象存儲產品滿足相關功能需求，並進行存儲的統一管理和可視化管理，後續將FastDFS中存儲文件遷移到對象存儲，需要5T容量。
|
業務需求 |
FastDFS存儲替換 |
|
容量 |
4T |
|
應用場景 |
內部API訪問接口,外網訪問接口,小圖片、視頻存儲 |
|
文件大小 |
TB級別 |
|
文件數量 |
海量圖片視頻 |
|
文件處理 |
暫無 |
|
多中心 |
待定 |
|
存儲年限 |
永久 |
|
應用改造 |
FastDFS遷移到對象存儲 |
|
備註 |
|
4、企業網盤存儲容量評估
|
業務需求 |
企業網盤 |
|
容量 |
現狀：20T,總量：待評估 |
|
應用場景 |
owncloud |
|
文件大小 |
各種均有 |
|
文件數量 |
海量（未能估計） |
|
文件處理 |
暫無 |
|
多中心 |
異地災備 |
|
存儲年限 |
永久 |
|
應用改造 |
NFS遷移到對象存儲 |
|
備註 |
優先級較低 |
5、語音存儲容量評估
客服中心語音目前每天平均產生約50W個語音文件，單個文件大小爲20~50MB之間，質檢系統存儲需要保存3個月的客服中心語音，超過3個月的數據自動刪除。
在語音處理過程會將2個語音文件合併爲1個合成文件，再將合成文件語音轉碼爲轉譯系統可以識別的語音格式文件，最後在轉譯爲文本文件存儲。中間文件都會保存到存儲系統，所以實際需要的存儲容量是比較大的，通過各種調研計算，具體系統1.72PB容量。
根據存儲規劃，幾類型文件的存儲時間和容量計算如下：
|
業務需求 |
語音存儲 |
|
容量 |
1,72P |
|
應用場景 |
錄音文件 |
|
文件大小 |
30-50M |
|
文件數量 |
每天50萬比數據量 |
|
文件處理 |
合併、轉碼 |
|
多中心 |
異地災備 |
|
存儲年限 |
未合併之前（7天） |
|
應用改造 |
GlusterFS遷移到對象存儲 |
|
備註 |
考慮風險，暫不改造 |
- 完成存儲池服務器規劃
通過對業務系統需求分析和六家廠商測試結果，卡中心領導對當前存儲系統進行了細緻的分析，確定初期按照1PB有效容量來規劃當前存儲池。通過計算需要負載均衡服務器3臺，存儲節點服務器40臺，索引池節點、數據處理、後臺管理服務器5臺，MySQL數據庫服務器2臺。具體物理服務器架構規劃如下。
總結：
通過以上各個方面的總結，最終爲2019年存儲池建設提供了完整的建設依據。後期計劃項目分爲兩個階段進行實施。
第一階段目標爲完成分佈式存儲的平臺建設，搭建完整的資源池，爲業務系統提供高可用、高性能、易操作、易維護、易監控的存儲服務，並實現存儲資源的快速交付。整個實施計劃從2019年1月1日開始實施，到2019年3月31日上線完成，存儲總容量規劃1PB。
第二階段目標是應用對接和存儲切換，共計三個系統，計劃從2019年4月1日到2018年12月31日，首先對接圖片資源平臺替換FastDFS進行試點，推廣對接影像系統從NAS切換到對象存儲，最後對接現有的雲計算平臺的存儲模塊爲鏡像和應用發佈包提供存儲服務。
以上就是本人在該年度做的具體工作，本人在一年當中對分佈式對象存儲也有了深入了了解，對本人的技術能力有了很大的提升，希望2019年存儲資源池建設順利。