2.3 數據復制
為了保證較低的RPO和RTO目標，數據復制技術常應用于各種災備系統。數據復制是將原卷或原文件直接復制到目標卷或目標文件系統中，分別稱為卷復制和文件復制。由于數據復制的目標卷（目標文件）和源卷（源文件）的數據格式一致，可以消除備份系統中數據格式的轉換時間。數據復制又分為同步復制和異步復制。
2.3.1 同步復制
同步復制表示，在數據復制系統的源端，主機發出的I/O請求在寫入本地磁盤的同時，通過專用的數據網絡或通道將數據從本地磁盤系統同步地復制到異地磁盤系統。當異地系統完成該I/O操作后，通知本地系統I/O完成，本地的主機系統才能發出第二個I/O請求。利用同步復制方式建立異地數據災備，可以保證異地系統和本地系統數據的完全一致性。但同步復制方式對性能的要求非常高。由于每一次本地I/O必須要等到數據成功地寫到異地系統，才能進行下一個I/O操作，因此同步復制的性能受網絡帶寬、網絡的距離、中間設備及協議轉換等多方面的影響。
2.3.2 異步復制
異步復制是指在數據復制系統的源端，主機發出的/O請求在寫入本地磁盤的同時，向本地磁盤系統上預留的空間發出相同的寫請求（決定于不同的策略），然后通知本地系統I/O完成。此時，本地的主機系統可以發出第下一個I/O請求。在設定的復制規則滿足后（基于時間、基于變化量等），系統的復制功能模塊再將數據通過專用的數據網絡或通道復制到異地的存儲系統中。
2.4 災備分析
與同步復制相比，異步復制對網絡帶寬和距離的要求低很多，只要在某個時間段內能將數據全部復制到異地即可，同時異步復制對應用系統的性能影響也很小。但是，當本地系統發生災難時，異地系統上的數據可能會短暫缺失（在復制的時間間隔內數據未完整地從源端發送到目的端）。因此，當源端災難發生時，同步復制的RPO接近于0，異步復制的RPO則取決于復制時間間隔。同時，在業務恢復時間上，相對于傳統的備份系統而言，由于不存在數據格式的轉換，可以在較短的時間內恢復業務系統，從而具有較好的RTO。對于1000億元人民幣以上的銀行，銀監會要求建立200km以上的備份系統。因此只能使用遠程復制模式。同城復制可以使用光纖，但是遠程復制由于成本方面的因素，全光纖傳輸還很遙遠。因此，不可能采用同步復制。所以，遠程異步復制模式會越來越多。
3 云存儲與云災備的短板
當用戶向云存儲系統中進行數據備份時，網絡對系統性能的影響起到了至關重要的作用。當云存儲服務提供商在進行后臺的云災備時，遠程的云備份和云復制也依賴于網絡的性能。
圖4 英國劍橋大學到中國北京的網絡帶寬
3.1 網絡短板
按照Nielsen法則，終端用戶的網絡帶寬以每年50%的速度增長。然而，和局域網形成鮮明對照的是，廣域網的性能不盡人意。例如，一條T1線路的帶寬只相當于千兆網的千分之一，許多幀中繼線路的帶寬只有256kb/s。Garfinkel[19]通過測量發現從美國伯克利大學到西雅圖的平均網絡寫帶寬大約是5~18Mb/s。通過使用網絡測試工具iperf，采用256個數據流測量，數據表明在格林尼治標準時間下午7點到10點，從英國劍橋大學到中國北京的平均網絡帶寬大約是14Mb/s，如圖4所示[20]。
基于以上的測試數據，如果假設網絡帶寬為20Mb/s，Armbrust[21]等人作了簡單的計算，計算結果表明從美國伯克利大學傳輸10TB數據到西雅圖需要45d的時間（10×1012B/（20×106b/s）=4000000s=45d）。如果通過亞馬遜來進行該數據傳輸，需要另外向亞馬遜支付1000美元的網絡傳輸費用。另外，由于廣域網物理距離的原因，不可避免的時延也會對帶寬造成影響。例如，一個T3鏈路（44.736Mb/s），當時延超過40ms時，其帶寬很快就下降到與T1鏈路（1.544Mb/s）相當。
如果是進行云備份，時間上的開銷相對還可以忍受，因為用戶在本地還有一個數據拷貝可供使用。但如果是從云存儲系統中恢復數據，這是無法讓人接受的，特別是對于那些需要提供24×7×365業務連續性的企業級用戶。為了緩解這個問題，對于云存儲系統中大數據量的恢復，云存儲提供商Mozy[22]和CrashPlan[23]提供了一個不得已的選擇，在用戶許可的情況下，將數據轉存在DVD或者硬盤上，然后通過特快專遞的形式交付給用戶。
3.2 網絡優化
ACK：確認
圖5 針對廣域網數據傳輸的協議優化
針對廣域網數據傳輸的協議優化如圖5所示。為了優化廣域網環境下大規模數據傳輸的性能，我們曾將數據在套接字層在發送端進行分割，然后利用多個套接字流進行并行傳輸，最后在接收端進行數據重組（如圖5（c）所示）。理論上講，對傳輸控制協議（TCP）管道而言，其最大的吞吐量為帶寬延遲乘積，即容量=帶寬×環回時間。在傳輸窗口一定的情況下（圖5中紅色的方形區表示傳輸窗口，缺省為64kB），按通常100Mb/s的網絡帶寬來計算，傳統的單套接字流顯然無法填滿TCP管道（如圖5（a）所示），使得其效率極低。通過加大傳輸窗口可以在一定程度上提高TCP管道的利用率（如圖5（b）所示），但在丟包的情況下，會導致每次重傳的數據增加。因此，通過多個套接字流來并行傳輸的效果較好。另外，由于采用了多流，不同的數據流在必要的情況下可以走不同的路由，也能夠進一步優化廣域網的性能。
正如前面提到的，云基礎設施必須是地理上分布的，因為云的成功在很大程度上決定于其規模效應。雖然計算和存儲相對便宜，然而，由于廣域網環境下的低帶寬、高延遲和較高的丟包率，使得廣域網成為云環境下那塊最短的木板。因此，在地理上分布的云環境下進行大規模的數據傳輸是非常昂貴的。圖靈獎獲得者JimGray在2006年就指出在廣域網上處理大數據集時，應該將程序傳給數據，而不是將數據傳給程序。另外，也可以通過數據壓縮、數據去重等方法來減少網域網上的數據傳輸流量，降低對網絡帶寬的需求。還可以采用動態緩存、IP流量管理以及服務質量（QoS）控制等方法來降低廣域網的延遲。但是，這些方法只能在一定程度上來緩解網絡“瓶頸”問題，不能從根本上解決問題。因此，在設計云存儲和云災備系統時，必須要考慮廣域網的帶寬、延遲和包丟失率所帶來的影響。
4 云存儲實例分析
圖6 2.12 GB數據的備份時間
圖7 2.12 GB數據的恢復時間
對于企業用戶而言，現有的云存儲更多的是一種在線遠程備份系統。Hu等人針對Mozy、Carbonite、Dropbox、Crashplan4種云存儲系統進行了測試、比較和分析。當將8GB的文件備份到云存儲系統中時，有的系統的備份時間超過了30h，還有的系統經過4d的時間還未備份完成。當他們將數據集減小到2GB左右時，云備份系統才回復到基本正常的工作狀態。
圖6表示Hu等人在Mozy、Carbonite、Dropbox、Crashplan4個不同的云存儲系統下備份2.12GB數據時的遠程備份時間。其中橫坐標從左到右的4種情況分別表示單個2.12GB的大普通文件、單個2.12GB的大稀疏文件、很多小的普通文件組成2.12GB的數據集、很多小的稀疏文件組成2.12GB的數據集。稀疏文件表示該文件不包含用戶數據，也沒有分配用來存儲用戶數據的磁盤空間。當數據被寫入稀疏文件時，文件系統（例如微軟的NTFS）才逐漸地為其分配磁盤空間。可以看到對于正常2.12GB的文件數據4個系統的備份時間都超過了5h。
圖7表示相應的恢復時間。恢復比備份要相對快很多，這主要是由于網絡的上行鏈路和下行鏈路帶寬的不對稱造成的。通過大量的測試分析，Hu等人得出了一下結論：
（1）云存儲系統必須對于網絡失效具有回彈性，同時能夠實現大文件的增量備份。
（2）云存儲提供商在進行大數據的網絡傳輸時還要進行加密、壓縮等預處理以避免網絡延遲。
（3）云存儲用戶需要手動檢測重要的文件是否都已經進行了備份。
（4）云存儲用戶應該將云存儲系統作為本地備份系統的一種補充，而不能將其當成主要的備份策略。
本文認為，現有的云存儲應對普通用戶小數據的備份與恢復應該問題不大，但是企業級用戶大數據量的存儲與恢復則要慎重考慮。
5 結束語
云存儲面向個人的應用主要有網盤、在線文檔編輯、工作流及日程安排。面向企業的應用主要有企業空間的租賃服務，企業級數據備份和歸檔、視頻監控系統等。云災備則主要用于保證云存儲服務商后臺系統的可靠性和可用性。對兩者而言，海量數據的高度聚集會對系統帶來一系列的挑戰。例如，如何實現海量存儲系統從傳統的縱向擴展向橫向擴展轉化？如何實現系統的性能和規模線性可擴展？如何處理海量存儲系統的高度聚集帶來的能耗和冷卻？等問題都是我們在進行云存儲和云災備系統設計時必須要考慮的重要因素。當然，云存儲最終能否成功，還受到其他很多因素的影響，如大量的數據存儲在云端如何保證數據的安全和用戶隱私等。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：云存儲與云災備的原理與短板分析(下)
本文網址：http://www.guhuozai8.cn/html/consultation/1083978020.html
相關文章
