云數據遷移中的6個潛在瓶頸

Seth Noble Monkey King

從云存儲導航選項到數據傳送后的驗證，按照如下的步驟可以有效避免云數據遷移中的風險。

將TB甚至PB級的數據轉移到云端確實是一項非常有挑戰性的工作。但是更重要的是你需要看到比這些字節更深遠的地方。你可能知道當在云端訪問這些應用程序時，它們的運行行為可能會表現得不一樣，它們的成本結構將會有所不同（希望是更好），并且轉移所有的數據需要花費大量的時間。

因為我的公司，Data Expedition，從事的生意是高性能數據傳輸，當客戶預期的網絡速度成為問題時他們就會來找我們。但是在幫助客戶企業解決這些問題的過程中，我們看到了許多其他容易被忽略的因素，有可能威脅到整個過程并導致云數據遷移脫軌。

收集、組織、格式化，以及驗證你的數據要遠比轉移數據的挑戰更大。我會列舉出云數據遷移計劃階段的一些普遍問題，可以幫助你在接下來的工作中避免浪費更多的時間和財力。

云數據遷移瓶頸 #1： 數據存儲

我們看到的云遷移中最常見的錯誤是將數據堆入云存儲而不考慮將會如何使用這些數據。典型的思考過程是“我想把我的文檔和數據庫放到云中，對象存儲很便宜，所以我會把文檔和數據庫文件放在那里。”但是文件、對象以及數據庫的行為模式是完全不同的。如果字節放錯了位置會破壞你的整個云計劃。

文件由層次結構的路徑、目錄樹來組織。每個文件可以快速訪問，以最小的等待時間（到首字節的時間）以及很高的速度 （數據流開始后每秒比特數）。可以輕松地將單個文件移動、重命名和更改到字節級別。可以有許多小文件、少量大文件，或者大小和數據類型的任意組合。傳統應用程序可以像在房子里一樣在云中訪問文件，而不需要任何特殊的云意識。

所有這些優點使得基于文件的存儲成為最昂貴的選擇，但是將文件存儲在云中還有一些其他缺點。為了實現高性能，大多數基于云的文件系統 （比如 Amazon EBS） 一次只能由一個基于云的虛擬機訪問，這意味著所有需要該數據的應用程序必須在單個云VM上運行。如果要服務多個 VM （比如 Azure Files），就需要像中小企業那樣將NAS存儲前置，但這又會使得性能嚴重受限。文件系統是快速、靈活和向后兼容的，但是它們很昂貴，只對在云中運行的應用程序有用，并且不能很好地擴展。

對象不是文件。請牢牢記住，因為很容易忘記。對象位于平面命名空間中，就像一個巨型目錄一樣。延遲很高，有時幾百或幾千毫秒，并且吞吐量很低，除非使用巧妙的技巧，否則通常達到每秒150兆比特。訪問對象的很多技巧都可以歸結為聰明的技巧，比如多部分上傳、字節范圍訪問和鍵名優化。對象可以同時被許多云本地和基于web的應用程序從云內外讀取，但傳統的應用程序則需要一些變通的方法。訪問對象存儲的大多數接口使得對象看起來像文件： 鍵名通過前綴過濾，使其看起來像文件夾，將自定義元數據附加到對象上，使其看起來像文件元數據或是一些系統，比如VM文件系統上的FUSE緩存對象，以允許傳統應用程序訪問。但是這些方法是易碎的且破壞性能的。云存儲是廉價的、可擴展的、云原生的，但是它也很慢，并且很難訪問。

數據庫有它們自己的復雜結構，它們可以由查詢語言（如SQL）訪問。傳統的數據庫可能由文件存儲支持，但它們需要一個實時數據庫進程來提供查詢。這可以通過將數據庫文件和應用程序復制到VM中或者通過將數據遷移到云托管的數據庫服務來提升到云中。但是將數據庫文件復制到對象存儲中僅作為脫機備份有用。數據庫作為云托管服務的一部分可擴展，但是確保依賴于數據庫的應用程序和流程完全兼容并且是云原生同樣至關重要。數據庫存儲是高度專業化和特定于應用程序的。

如何在可明顯節省成本的對象存儲與文件和數據庫的功能性之間做出平衡，就需要仔細考慮你到底需要什么功能。舉個例子，如果你想存儲和分發成千上萬的小文件，那么與其將它們存檔到單一的ZIP文件中，并作為單個對象來存儲，反倒不如將每個單獨的文件作為單獨的對象來存儲更好。不正確的存儲選擇可能會導致復雜的依賴關系，這些依賴關系在后續更改時既困難又昂貴。

云數據遷移瓶頸#2： 數據準備

將數據移動到云并不像將字節復制到指定的存儲類型那樣簡單。在復制任何東西之前，需要進行大量準備，而這段時間需要仔細編制預算。概念驗證這個項目環節常常被忽略，這會導致之后的成本代價大大超支。

過濾掉不必要的數據可以節省大量的時間和存儲成本。舉個例子，數據集可以包含不需要成為云工作流一部分的備份、早期版本或草稿文件。也許過濾過程中最重要的部分就是優先確定哪些數據需要首先轉移。正在頻繁使用的數據不能容忍在完成整個遷移過程所需的周、月或年之間失去同步。這里的關鍵是提出一種自動選擇要發送哪些數據以及何時發送數據的方法，然后仔細記錄所有已完成和未完成的工作。

不同的云工作流可能要求數據采用與內部應用程序不同的格式或組織。舉個例子，一個合法的工作流可能需要翻譯成千上萬個小Word或PDF文檔并將它們打包成ZIP文件，媒體工作流可能包含代碼轉換和元數據打包，而生物信息學的工作流可能需要挑選和分期萬億字節的基因組數據。這樣的重新格式化是一個非常費時費力的過程。它需要大量的實驗、大量的臨時存儲以及大量的異常處理。有時很容易推遲對云環境的任何重新格式化，但請記住，這并不能解決這個問題，它只是把它轉移到另一個環境，在那里你所使用的每一個資源都有明碼標價。

存儲和格式化問題的一部分可能包括關于壓縮和歸檔的決策。舉個例子，在發送數百萬個小文本文件到云中之前，對它們進行ZIP處理是有意義的，但對于幾千兆字節的媒體文件，這個方法就不適用。歸檔和壓縮數據使得傳輸和存儲數據更加容易，但是要考慮在兩端打包和解包這些歸檔所需的時間和存儲空間。

云數據遷移瓶頸#3： 信息驗證

完整性檢查是最重要的步驟，也是最容易出錯的步驟。通常假定在數據傳輸期間發生損壞，無論是通過物理媒體還是網絡傳輸，都可以通過執行之前和之后的總和校驗來捕獲。總和校驗在流程中是至關重要的環節，但實際上在數據的準備和導入環節最有可能遭受數據損壞或丟失。

當數據改變格式和應用程序時，即使字節相同，含義和功能也會丟失。軟件版本之間的不兼容性可能使千兆字節的“正確”數據變得毫無用處。提出一個可擴展的進程來驗證你的數據是否正確和可用將會是一項艱巨的任務。在最壞的情況下，它可能演變成勞動密集型的、不精確的手動進程，即 “在我看來沒問題”，但是即使是這樣也比根本沒有驗證要好。最重要的是確保能夠在遺留系統退役之前識別到問題！

云數據遷移瓶頸#4： 傳送的安排

將單個系統遷移到云上是相對容易的，只需把準備好的數據復制到物理媒體上或通過互聯網上傳即可。但這一過程很難規模化，尤其是物理媒體。當許多不同的系統開始發揮作用時，那些在概念驗證中看起來“簡單”的內容可能演變成為“噩夢”。

一套媒體設備，比如一套 AWS Snowball，必須與每臺機器相連接。這可能意味著設備在一個或更多的數據中心周圍進行物理行走、適配連接器、更新驅動程序和安裝軟件。通過本地網絡連接可以節省物理移動，但是軟件設置仍然具有挑戰性，并且復制速度可能下降到遠低于直接通過互聯網上傳可以實現的速度。通過互聯網直接從每臺機器傳輸數據可以節省許多步驟，特別是當數據已經在云端時。

如果數據準備包括復制、導出、重新格式化或歸檔，本地存儲會成為瓶頸。有必要設置專用存儲器來存儲準備好的數據。這具有允許許多系統并行地執行準備的優點，并將可運輸媒體和數據傳輸軟件的接觸點減少到僅一個系統之中。

云數據遷移瓶頸#5： 數據傳送

當我們對比網絡傳輸和媒介交付時，很容易只關注傳輸時間。舉個例子，一個80TB的 AWS Snowball 設備可能次日才能送達，然后實現每秒超過8Gb的數據速率。但是這忽略了獲取設備、配置和加載設備、設備返回以及云供應商在后端復制數據所需的時間。我們的客戶說完成這一流程，花費四周的周轉時間（從設備訂購到數據在云中可用）很普遍。這使得實際傳送設備的數據傳輸速率下降到每秒300Mb，如果設備沒有完全裝滿，則還要少得多。

網絡傳輸速度同樣取決于許多因素，首要因素是本地上行線路。你發送數據顯然不可能超過物理的網速，盡管認真的數據準備可以減少你需要發送的數據量。傳統協議，包括云供應商默認用于對象存儲的那些協議，在跨越遠程互聯網路徑的速度和可靠性方面存在障礙，這使得實現該比特率變得困難。我可以寫很多關于這里包含的挑戰的文章，但是你不必非要自己去解決。Data Expedition是少數幾個專門研究確保路徑得到充分利用的公司之一，無論數據距離其云目的地的距離有多遠。舉個例子，一條千兆互聯網連接，再使用CloudDat的加速軟件，可獲得每秒900Mb的速率，是 AWS Snowball凈吞吐量的三倍。

物理裝運和網絡傳輸之間的最大區別在概念驗證過程中最常被忽略。對于物理裝運，加載到設備上的第一個字節必須等到最后一個字節加載完成后才能裝運。這意味著，如果加載該設備需要數周時間，那么在到達云端時，其中的一些數據將過期。即使數據集達到PB級別，物理裝運總體上可能會更快一些，但在遷移過程中保持當前優先級數據的能力對于關鍵資產的網絡傳輸來說仍然是有利的。認真規劃在數據準備階段中的過濾和優先次序是必須的，也可采用混合方法。

將數據放入云提供商網絡中并不是數據傳輸步驟的結束。如果需要將它復制到多個區域或供應商那兒，就需要認真計劃如何實現它。通過互聯網上傳是免費的，如果通過AWS，區域間數據傳輸的費用高達2美分每GB，傳輸到其他云供應商的費用高達9美分每GB。這兩種方法都面臨帶寬限制，但是可以受益于像CloudDat這樣的傳輸加速器。

云數據遷移瓶頸#6： 云計算

當數據到達云中的目的地時，遷移過程僅僅只完成了一半。需要首先進行校驗和檢查： 確保到達的字節與發送的字節一致。這比你可能意識到的更棘手。文件存儲使用緩存層，這些緩存層可能會損壞剛剛上傳的數據。這種損壞并不常見，但是在清除所有緩存并重新讀取文件之前，不能確定進行任何的校驗和檢查。重新啟動實例或解除掛載存儲可以完成清除高速緩存的工作。

驗證對象存儲校驗和需要將每個對象讀出到用于計算的實例中。與普遍認知相反，對象“E-tags”沒有校驗和檢查有用。特別是使用多部件技術上傳的對象，只能通過將它們讀回來驗證。

一旦所傳輸的數據被驗證，在基于云的應用程序和服務能夠使用它之前，可能需要進一步的提取、重新格式化和分發。這與在企業內部進行的準備和編組處理完全相反。

擴展數據的最后一步是驗證數據是否正確和有用。這是上面討論的信息驗證計劃的另一方面，并且是知道你是否真的完成的唯一方法。

云遷移更多的是進程而不是數據。甚至那些看似簡單的任務（如文件分發）也可能需要復雜的遷移步驟來確保生成的云基礎設施與預期的工作流相一致。圍繞云的大量宣傳，從成本節約到可擴展性，都是合理的。但是認真地計劃和預估困難對于決定使用哪些所需的工具和方法來實現這些回報才是至關重要的。