精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

當前位置:云計算云存儲 → 正文

如何搞定TB級數據上云備份保護

責任編輯:editor005 作者:陳元強 |來源:企業網D1Net  2015-05-18 14:23:13 本文摘自:oschina博客

大規模數據備份保護現狀

從多備份目前10萬多用戶中發掘的大型客戶看,業務規模稍微大一點,日志,DB歸檔,在線編輯,生產加工產生的數據,設計類文檔,及日常運營的累積的數據等就輕松超過TB級。而對于TB級數據,有幾種場景定義和區別:

單個節點的數據量上TB級

總量上TB級,但分布在多個節點

總量上TB,但單個文件量上百GB

總量上TB, 文件數規模很大,上萬千,甚至過億

總量上TB,類型不一樣,有的是DB備份后的壓縮文件,有的是圖片,有的是文檔類

TB級數據是用戶產生,從用戶中來,到用戶中去,比如視頻,圖片等UGC內容,對于這類冷的數據,逐步也需要進行歸檔冷備起來

對于目前以上6種情況,我們了解到,絕大部分企業,并沒有做比較系統的保護,或者說做了系統的保護,但都是在本地環境做的,一旦遇到人為原因,軟件缺陷,或 者存儲故障等,數據丟失的風險相當大; 有相當能力的,自己做了異地或自己做云存儲備份方案,但在靈活,系統化的,擴展性,成本方面并沒有優勢,畢竟對企業來說這不是核心運營的業務。

目前市面上的一些現有解決方案的特點:

策略一般就是全量+增量結合,選用專用的存儲設備,接上高速的光纖通道,配上專用的系統維護人員,這類方案在本地有足夠的優勢,備份和恢復快,但缺點也是相當的明顯,而且從設計理念上來看,以下的幾個點基本只有廠家自己革命才能解決:

第1:復雜,配置、部署以及使用操作維護都需要專業的管理人員,基本上在互聯網企業看,即使是做完B/C/D輪的,甚至IPO后的企業,出得起錢,也是不會考慮如此方案。

第2:升級擴展復雜,預先估計容量,后續擴展起來相當麻煩,必須的改變存儲策略,或重新離線做數據遷移分布。如果初始購買的存儲擴展有限,后期還不能很好的升級擴展。

第3:3-5年左右的生命周期,也就是說,數據經過幾年后,改造升級,購買新的方案是必須的,這樣當數據上到百TB級別,整個工程實施也是相當復雜了。

第4:難于對接互聯網+的思路轉換, 由于是離線的備份存儲方案,如果和業務系統對接,實際上基本上就是不太可能,尤其是目前不少企業開始加強互聯網+的運營思路的調整,數據不斷會和外部系統進行交換或對接。

第5:貴,特別的貴,如果對原始TB級數據做專業備份保護,投入得數十萬,具體到不同的行業,、性能和保護窗口參數稍微提升,投入立即上升到百萬級。

當然如果對于非常有資源和有足夠多的預算,這一切都看起來都不是問題;而事實上,這類用戶還是只有在相當土豪的機構和企業里面才有,就連銀行都無法徹底按照嚴謹的實施和維護方案落實,才會出現接二連三的銀行機房燒毀數據丟失,或者宕機幾十個小時的情況。

終歸原因,對于關鍵的業務系統的備份保護,不緊緊是上了一套專業的方案,或者做了異地災備,事情就可以完美解決;更重要的是,還得有操作簡單,容易驗證,應急性強的方案。

解決思路

多備份從2013年成立以來,一直以互聯網的簡單、親民的服務化思路演化,目前服務過的客戶,包括GB級的到TB級,涉及到關鍵運營業務系統數據庫,也包含 企業日常運營產生的文檔資料存儲備份保護等。經過上PB級的數據訓練,多備份從第1代全云的架構方案,到目前迭代的到最新的第2代基于混合云架構的保護方 案。

第2代方案設計的目標主要面向TB級數據保護需求,徹底切分TB級數據6個構成面,并主要分解為如下幾個點:

最大化降低備份存儲空間,數倍降低企業TCO投入

簡化使用門檻,包括配置流程,以及保護策略

數據備份和恢復的速度要在基于云的架構下,足夠的快

按需在線擴展,永不停機,足夠可靠

支持數據按需流動,真正意義讓數據在必要的時候,能動起來

僅由客戶全程加密掌控數據,充分保護數據隱私

基于以上6個設計目標,我們從幾個方面來剖析多備份是如何做到的

以云為核心,外網IT存儲設施混合的本地+云的混合設計模型

多備份創始人解析如何搞定TB級數據上云備份保護

  首先,多備份整體架構,圍繞云來設計,充分利用云的幾個特點

按需擴展,對客戶,對多備份自身服務的投入按需增加

可靠,云的計算和存儲分布特點,使得系統在計算和存儲都具備傳統結構不具備的數倍的可靠性

安全,基礎云服務商自身在安全方面不計成本,比起自己構建IT設施,來得更加專業

擴展,開放性更好,使得構建的服務,更容易外部系統對接

目前在具體的基礎實施平臺中,重點包括阿里云,騰訊云,AWS,金山云,微軟AZURE,移動云,七牛,百度云等平臺,這些都是全球或國內知名的大型云平臺。

其次,為了更好融合企業IT場景,以及一些合規規定,多備份在第1代云的基礎上,增加了外圍對接,支持數據備份存儲在本地環境的存儲設施,如NAS, SAN 或者節點的另外的磁盤分區等,這樣一來有3個好處:

數據可以在本地存儲一份,特別是熱一點的數據, 其他數據可以部分或者全部上云進行備份保護起來

常規的備份和恢復任務的會第1時間在本地環境完成,數據會在本地完成后,最快的時間同步上云

一些政企合規的數據可以保存在內部,其他的非敏感類的數據可以加密上云。

數據發現,傳輸,存儲等全部采用全增量+時間點版本映射結構設計

具備時間刻度特性的,本地和云兩級全增量索引

為了實現更低的存儲開銷,更快的備份和恢復速度,多備份從索引的設計,數據版本組織策略上都采用全增量模型,并且支持任意時間點的版本和索引的映射,這樣就為任一時間點的數據恢復或下載等提供了可行支持。

多備份創始人解析如何搞定TB級數據上云備份保護

索引是構成整個系統的關鍵,數據的變化,無論從本地往云,還是從云往本地,都以來索引來快速找到對應的數據塊。而傳統的方案里面,索引也存在。多備份的特點 在于,結合了云以后,索引全部采用分區分段構建云索引中心的擴展模型,在量級,動態遷移是傳統的方案無法比較的。理論上,客戶越多,數據越大,邊際效應就 越好,給客戶回饋的成本優勢就更越明顯。

在這里,本地的索引用來快速支持數據的變化檢查,云端的索引用于本地失效后的變化檢測,以及在線數據服務接口的支持。

在每一次的數據備份時刻,都會記錄相應的數據映射關系,這樣可以滿足任意時間點的數據恢復和使用檢索需求。

按 照目前的設計,在本地可以支持2TB的數據索引關系,支持的數據量可以到達PB級,文檔(含數據庫備份壓縮備份歸檔數據文件)數量可以到達十億級別規模。 而在云上集中的存儲規模理論上受限于云平臺本身的存儲容量,幸運的是,即使在這一刻,多備份也可以正常運行,原因在于,多備份底層已經支持多個云的分布或 聚合。

本地+云兩級全增量策略保護模型,更快,更省的本性

多備份創始人解析如何搞定TB級數據上云備份保護

多備份在數據策略化組織這里全部采用增量模型,與傳統的定期全量+增量模型在存儲空間和效率方面有著顯著的區別。一般原始數據在500GB規模的,按照通常的服務溝通模型下來,3個月下來也得有10TB級規模了,如果采用傳統的方案,成本將到達百萬級投入規模。

多備份依托于云存儲的冗余分布特性,在時間和空間分布的可靠性方面已經遠遠大于本地存儲。正因為如此,多備份的增量備份存儲策略機制在保持最小的數據開銷規模下,每次的備份效率都出奇的高,同樣,按照時間點任意恢復數據的時候速度也相當快。

同樣,由于其邊掃描邊備份,實時增量檢測,塊級存儲的增量特性,以及壓縮策略智能化,單個幾百GB規模的文件,文本和圖片視頻,還是在數量眾多的千萬級規模下都可以勝任。

基于云的兩級增量模型最大的好處就是在TB級數據規模下,具備超低投入,甚至低至傳統方案的1/10 TCO,高速度;同樣,具備時間刻度恢復的特點、

端到端AES256加密機制,與Cloud 5分塊算術冗余分布機制,讓數據足夠的安全與可靠

多備份創始人解析如何搞定TB級數據上云備份保護

在多備份的整個體系設計中,安全是從端到后臺,整體設計全程考慮,不打折扣,嚴格從機制上保證數據上云的機密性。

數據從客戶端接入數據后,立即進行AES256加密,加密后的數據分布在云存儲中,而加密用的密鑰則是在安裝過程中,由客戶端產生并有客戶自己保存下來。對 于特別要求可靠的數據,Cloud 5技術可以在保持2倍的成本投入下,進一步在多個不同種類的云存儲,或者單個云的多個存儲中心之間提高備份數據可靠性,幾乎就是永不丟失。

圍繞80%的場景設計, 安裝設置與維護盡可能快和簡單

多備份在具體的部署方案上,分成控制中心和客戶端設計,當然還有無安裝模型。目前無論是控制中心,還是客戶端都采用80/20場景適應的原則來考慮,在具體 使用流程和參數布局上,全面改變傳統的幾百個令人發暈的參數配置方案。所有的標準化操作考慮80%的場景覆蓋,除了頻率,內容設置,速度限制,必要的鏈接 參數外,其他都不在多備份主流程中。這樣在具體的功能組合,流程模板顯示,操作菜單,以及按鈕都可以保持非常簡單的流程和交互設計。

作者介紹:

聯合創始人& CTO - 陳元強 曾就職于寶德、騰訊、盛大(旅游)、宜搜、4399,歷任經理、總監等核心研發崗位。主導過國家級IT安全系統研發和實施;負責家庭戰略項目的產品研發管 理工作,主導QQ空間大數據分析和騰訊網分布式流量分析平臺的研發。在海量用戶、數據安全、網絡通訊和大數據挖掘等應用領域方面具有豐富的經驗。

關鍵字:TB數據映射變化檢測

本文摘自:oschina博客

x 如何搞定TB級數據上云備份保護 掃一掃
分享本文到朋友圈
當前位置:云計算云存儲 → 正文

如何搞定TB級數據上云備份保護

責任編輯:editor005 作者:陳元強 |來源:企業網D1Net  2015-05-18 14:23:13 本文摘自:oschina博客

大規模數據備份保護現狀

從多備份目前10萬多用戶中發掘的大型客戶看,業務規模稍微大一點,日志,DB歸檔,在線編輯,生產加工產生的數據,設計類文檔,及日常運營的累積的數據等就輕松超過TB級。而對于TB級數據,有幾種場景定義和區別:

單個節點的數據量上TB級

總量上TB級,但分布在多個節點

總量上TB,但單個文件量上百GB

總量上TB, 文件數規模很大,上萬千,甚至過億

總量上TB,類型不一樣,有的是DB備份后的壓縮文件,有的是圖片,有的是文檔類

TB級數據是用戶產生,從用戶中來,到用戶中去,比如視頻,圖片等UGC內容,對于這類冷的數據,逐步也需要進行歸檔冷備起來

對于目前以上6種情況,我們了解到,絕大部分企業,并沒有做比較系統的保護,或者說做了系統的保護,但都是在本地環境做的,一旦遇到人為原因,軟件缺陷,或 者存儲故障等,數據丟失的風險相當大; 有相當能力的,自己做了異地或自己做云存儲備份方案,但在靈活,系統化的,擴展性,成本方面并沒有優勢,畢竟對企業來說這不是核心運營的業務。

目前市面上的一些現有解決方案的特點:

策略一般就是全量+增量結合,選用專用的存儲設備,接上高速的光纖通道,配上專用的系統維護人員,這類方案在本地有足夠的優勢,備份和恢復快,但缺點也是相當的明顯,而且從設計理念上來看,以下的幾個點基本只有廠家自己革命才能解決:

第1:復雜,配置、部署以及使用操作維護都需要專業的管理人員,基本上在互聯網企業看,即使是做完B/C/D輪的,甚至IPO后的企業,出得起錢,也是不會考慮如此方案。

第2:升級擴展復雜,預先估計容量,后續擴展起來相當麻煩,必須的改變存儲策略,或重新離線做數據遷移分布。如果初始購買的存儲擴展有限,后期還不能很好的升級擴展。

第3:3-5年左右的生命周期,也就是說,數據經過幾年后,改造升級,購買新的方案是必須的,這樣當數據上到百TB級別,整個工程實施也是相當復雜了。

第4:難于對接互聯網+的思路轉換, 由于是離線的備份存儲方案,如果和業務系統對接,實際上基本上就是不太可能,尤其是目前不少企業開始加強互聯網+的運營思路的調整,數據不斷會和外部系統進行交換或對接。

第5:貴,特別的貴,如果對原始TB級數據做專業備份保護,投入得數十萬,具體到不同的行業,、性能和保護窗口參數稍微提升,投入立即上升到百萬級。

當然如果對于非常有資源和有足夠多的預算,這一切都看起來都不是問題;而事實上,這類用戶還是只有在相當土豪的機構和企業里面才有,就連銀行都無法徹底按照嚴謹的實施和維護方案落實,才會出現接二連三的銀行機房燒毀數據丟失,或者宕機幾十個小時的情況。

終歸原因,對于關鍵的業務系統的備份保護,不緊緊是上了一套專業的方案,或者做了異地災備,事情就可以完美解決;更重要的是,還得有操作簡單,容易驗證,應急性強的方案。

解決思路

多備份從2013年成立以來,一直以互聯網的簡單、親民的服務化思路演化,目前服務過的客戶,包括GB級的到TB級,涉及到關鍵運營業務系統數據庫,也包含 企業日常運營產生的文檔資料存儲備份保護等。經過上PB級的數據訓練,多備份從第1代全云的架構方案,到目前迭代的到最新的第2代基于混合云架構的保護方 案。

第2代方案設計的目標主要面向TB級數據保護需求,徹底切分TB級數據6個構成面,并主要分解為如下幾個點:

最大化降低備份存儲空間,數倍降低企業TCO投入

簡化使用門檻,包括配置流程,以及保護策略

數據備份和恢復的速度要在基于云的架構下,足夠的快

按需在線擴展,永不停機,足夠可靠

支持數據按需流動,真正意義讓數據在必要的時候,能動起來

僅由客戶全程加密掌控數據,充分保護數據隱私

基于以上6個設計目標,我們從幾個方面來剖析多備份是如何做到的

以云為核心,外網IT存儲設施混合的本地+云的混合設計模型

多備份創始人解析如何搞定TB級數據上云備份保護

  首先,多備份整體架構,圍繞云來設計,充分利用云的幾個特點

按需擴展,對客戶,對多備份自身服務的投入按需增加

可靠,云的計算和存儲分布特點,使得系統在計算和存儲都具備傳統結構不具備的數倍的可靠性

安全,基礎云服務商自身在安全方面不計成本,比起自己構建IT設施,來得更加專業

擴展,開放性更好,使得構建的服務,更容易外部系統對接

目前在具體的基礎實施平臺中,重點包括阿里云,騰訊云,AWS,金山云,微軟AZURE,移動云,七牛,百度云等平臺,這些都是全球或國內知名的大型云平臺。

其次,為了更好融合企業IT場景,以及一些合規規定,多備份在第1代云的基礎上,增加了外圍對接,支持數據備份存儲在本地環境的存儲設施,如NAS, SAN 或者節點的另外的磁盤分區等,這樣一來有3個好處:

數據可以在本地存儲一份,特別是熱一點的數據, 其他數據可以部分或者全部上云進行備份保護起來

常規的備份和恢復任務的會第1時間在本地環境完成,數據會在本地完成后,最快的時間同步上云

一些政企合規的數據可以保存在內部,其他的非敏感類的數據可以加密上云。

數據發現,傳輸,存儲等全部采用全增量+時間點版本映射結構設計

具備時間刻度特性的,本地和云兩級全增量索引

為了實現更低的存儲開銷,更快的備份和恢復速度,多備份從索引的設計,數據版本組織策略上都采用全增量模型,并且支持任意時間點的版本和索引的映射,這樣就為任一時間點的數據恢復或下載等提供了可行支持。

多備份創始人解析如何搞定TB級數據上云備份保護

索引是構成整個系統的關鍵,數據的變化,無論從本地往云,還是從云往本地,都以來索引來快速找到對應的數據塊。而傳統的方案里面,索引也存在。多備份的特點 在于,結合了云以后,索引全部采用分區分段構建云索引中心的擴展模型,在量級,動態遷移是傳統的方案無法比較的。理論上,客戶越多,數據越大,邊際效應就 越好,給客戶回饋的成本優勢就更越明顯。

在這里,本地的索引用來快速支持數據的變化檢查,云端的索引用于本地失效后的變化檢測,以及在線數據服務接口的支持。

在每一次的數據備份時刻,都會記錄相應的數據映射關系,這樣可以滿足任意時間點的數據恢復和使用檢索需求。

按 照目前的設計,在本地可以支持2TB的數據索引關系,支持的數據量可以到達PB級,文檔(含數據庫備份壓縮備份歸檔數據文件)數量可以到達十億級別規模。 而在云上集中的存儲規模理論上受限于云平臺本身的存儲容量,幸運的是,即使在這一刻,多備份也可以正常運行,原因在于,多備份底層已經支持多個云的分布或 聚合。

本地+云兩級全增量策略保護模型,更快,更省的本性

多備份創始人解析如何搞定TB級數據上云備份保護

多備份在數據策略化組織這里全部采用增量模型,與傳統的定期全量+增量模型在存儲空間和效率方面有著顯著的區別。一般原始數據在500GB規模的,按照通常的服務溝通模型下來,3個月下來也得有10TB級規模了,如果采用傳統的方案,成本將到達百萬級投入規模。

多備份依托于云存儲的冗余分布特性,在時間和空間分布的可靠性方面已經遠遠大于本地存儲。正因為如此,多備份的增量備份存儲策略機制在保持最小的數據開銷規模下,每次的備份效率都出奇的高,同樣,按照時間點任意恢復數據的時候速度也相當快。

同樣,由于其邊掃描邊備份,實時增量檢測,塊級存儲的增量特性,以及壓縮策略智能化,單個幾百GB規模的文件,文本和圖片視頻,還是在數量眾多的千萬級規模下都可以勝任。

基于云的兩級增量模型最大的好處就是在TB級數據規模下,具備超低投入,甚至低至傳統方案的1/10 TCO,高速度;同樣,具備時間刻度恢復的特點、

端到端AES256加密機制,與Cloud 5分塊算術冗余分布機制,讓數據足夠的安全與可靠

多備份創始人解析如何搞定TB級數據上云備份保護

在多備份的整個體系設計中,安全是從端到后臺,整體設計全程考慮,不打折扣,嚴格從機制上保證數據上云的機密性。

數據從客戶端接入數據后,立即進行AES256加密,加密后的數據分布在云存儲中,而加密用的密鑰則是在安裝過程中,由客戶端產生并有客戶自己保存下來。對 于特別要求可靠的數據,Cloud 5技術可以在保持2倍的成本投入下,進一步在多個不同種類的云存儲,或者單個云的多個存儲中心之間提高備份數據可靠性,幾乎就是永不丟失。

圍繞80%的場景設計, 安裝設置與維護盡可能快和簡單

多備份在具體的部署方案上,分成控制中心和客戶端設計,當然還有無安裝模型。目前無論是控制中心,還是客戶端都采用80/20場景適應的原則來考慮,在具體 使用流程和參數布局上,全面改變傳統的幾百個令人發暈的參數配置方案。所有的標準化操作考慮80%的場景覆蓋,除了頻率,內容設置,速度限制,必要的鏈接 參數外,其他都不在多備份主流程中。這樣在具體的功能組合,流程模板顯示,操作菜單,以及按鈕都可以保持非常簡單的流程和交互設計。

作者介紹:

聯合創始人& CTO - 陳元強 曾就職于寶德、騰訊、盛大(旅游)、宜搜、4399,歷任經理、總監等核心研發崗位。主導過國家級IT安全系統研發和實施;負責家庭戰略項目的產品研發管 理工作,主導QQ空間大數據分析和騰訊網分布式流量分析平臺的研發。在海量用戶、數據安全、網絡通訊和大數據挖掘等應用領域方面具有豐富的經驗。

關鍵字:TB數據映射變化檢測

本文摘自:oschina博客

電子周刊
回到頂部

關于我們聯系我們版權聲明隱私條款廣告服務友情鏈接投稿中心招賢納士

企業網版權所有 ©2010-2024 京ICP備09108050號-6 京公網安備 11010502049343號

^
  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 屏东县| 安多县| 喜德县| 山丹县| 夏河县| 古交市| 重庆市| 玛纳斯县| 襄城县| 朝阳市| 南木林县| 慈利县| 佛学| 宁明县| 呼和浩特市| 亚东县| 茂名市| 盘山县| 普宁市| 新营市| 陆川县| 平泉县| 浏阳市| 田东县| 东阿县| 无为县| 祁阳县| 江口县| 长沙县| 岱山县| 阜新| 宕昌县| 乌鲁木齐县| 巴彦淖尔市| 博客| 云霄县| 丰城市| 青岛市| 连云港市| 岑溪市| 景德镇市|