云數(shù)據(jù)遷移中的6個(gè)潛在瓶頸

Seth Noble Monkey King

從云存儲導(dǎo)航選項(xiàng)到數(shù)據(jù)傳送后的驗(yàn)證，按照如下的步驟可以有效避免云數(shù)據(jù)遷移中的風(fēng)險(xiǎn)。

將TB甚至PB級的數(shù)據(jù)轉(zhuǎn)移到云端確實(shí)是一項(xiàng)非常有挑戰(zhàn)性的工作。但是更重要的是你需要看到比這些字節(jié)更深遠(yuǎn)的地方。你可能知道當(dāng)在云端訪問這些應(yīng)用程序時(shí)，它們的運(yùn)行行為可能會(huì)表現(xiàn)得不一樣，它們的成本結(jié)構(gòu)將會(huì)有所不同（希望是更好），并且轉(zhuǎn)移所有的數(shù)據(jù)需要花費(fèi)大量的時(shí)間。

因?yàn)槲业墓?，Data Expedition，從事的生意是高性能數(shù)據(jù)傳輸，當(dāng)客戶預(yù)期的網(wǎng)絡(luò)速度成為問題時(shí)他們就會(huì)來找我們。但是在幫助客戶企業(yè)解決這些問題的過程中，我們看到了許多其他容易被忽略的因素，有可能威脅到整個(gè)過程并導(dǎo)致云數(shù)據(jù)遷移脫軌。

收集、組織、格式化，以及驗(yàn)證你的數(shù)據(jù)要遠(yuǎn)比轉(zhuǎn)移數(shù)據(jù)的挑戰(zhàn)更大。我會(huì)列舉出云數(shù)據(jù)遷移計(jì)劃階段的一些普遍問題，可以幫助你在接下來的工作中避免浪費(fèi)更多的時(shí)間和財(cái)力。

云數(shù)據(jù)遷移瓶頸 #1： 數(shù)據(jù)存儲

我們看到的云遷移中最常見的錯(cuò)誤是將數(shù)據(jù)堆入云存儲而不考慮將會(huì)如何使用這些數(shù)據(jù)。典型的思考過程是“我想把我的文檔和數(shù)據(jù)庫放到云中，對象存儲很便宜，所以我會(huì)把文檔和數(shù)據(jù)庫文件放在那里?！钡俏募?、對象以及數(shù)據(jù)庫的行為模式是完全不同的。如果字節(jié)放錯(cuò)了位置會(huì)破壞你的整個(gè)云計(jì)劃。

文件由層次結(jié)構(gòu)的路徑、目錄樹來組織。每個(gè)文件可以快速訪問，以最小的等待時(shí)間（到首字節(jié)的時(shí)間）以及很高的速度 （數(shù)據(jù)流開始后每秒比特?cái)?shù)）?？梢暂p松地將單個(gè)文件移動(dòng)、重命名和更改到字節(jié)級別。可以有許多小文件、少量大文件，或者大小和數(shù)據(jù)類型的任意組合。傳統(tǒng)應(yīng)用程序可以像在房子里一樣在云中訪問文件，而不需要任何特殊的云意識。

所有這些優(yōu)點(diǎn)使得基于文件的存儲成為最昂貴的選擇，但是將文件存儲在云中還有一些其他缺點(diǎn)。為了實(shí)現(xiàn)高性能，大多數(shù)基于云的文件系統(tǒng) （比如 Amazon EBS） 一次只能由一個(gè)基于云的虛擬機(jī)訪問，這意味著所有需要該數(shù)據(jù)的應(yīng)用程序必須在單個(gè)云VM上運(yùn)行。如果要服務(wù)多個(gè) VM （比如 Azure Files），就需要像中小企業(yè)那樣將NAS存儲前置，但這又會(huì)使得性能嚴(yán)重受限。文件系統(tǒng)是快速、靈活和向后兼容的，但是它們很昂貴，只對在云中運(yùn)行的應(yīng)用程序有用，并且不能很好地?cái)U(kuò)展。

對象不是文件。請牢牢記住，因?yàn)楹苋菀淄洝ο笪挥谄矫婷臻g中，就像一個(gè)巨型目錄一樣。延遲很高，有時(shí)幾百或幾千毫秒，并且吞吐量很低，除非使用巧妙的技巧，否則通常達(dá)到每秒150兆比特。訪問對象的很多技巧都可以歸結(jié)為聰明的技巧，比如多部分上傳、字節(jié)范圍訪問和鍵名優(yōu)化。對象可以同時(shí)被許多云本地和基于web的應(yīng)用程序從云內(nèi)外讀取，但傳統(tǒng)的應(yīng)用程序則需要一些變通的方法。訪問對象存儲的大多數(shù)接口使得對象看起來像文件： 鍵名通過前綴過濾，使其看起來像文件夾，將自定義元數(shù)據(jù)附加到對象上，使其看起來像文件元數(shù)據(jù)或是一些系統(tǒng)，比如VM文件系統(tǒng)上的FUSE緩存對象，以允許傳統(tǒng)應(yīng)用程序訪問。但是這些方法是易碎的且破壞性能的。云存儲是廉價(jià)的、可擴(kuò)展的、云原生的，但是它也很慢，并且很難訪問。

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

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

云數(shù)據(jù)遷移瓶頸#2： 數(shù)據(jù)準(zhǔn)備

將數(shù)據(jù)移動(dòng)到云并不像將字節(jié)復(fù)制到指定的存儲類型那樣簡單。在復(fù)制任何東西之前，需要進(jìn)行大量準(zhǔn)備，而這段時(shí)間需要仔細(xì)編制預(yù)算。概念驗(yàn)證這個(gè)項(xiàng)目環(huán)節(jié)常常被忽略，這會(huì)導(dǎo)致之后的成本代價(jià)大大超支。

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

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

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

云數(shù)據(jù)遷移瓶頸#3： 信息驗(yàn)證

完整性檢查是最重要的步驟，也是最容易出錯(cuò)的步驟。通常假定在數(shù)據(jù)傳輸期間發(fā)生損壞，無論是通過物理媒體還是網(wǎng)絡(luò)傳輸，都可以通過執(zhí)行之前和之后的總和校驗(yàn)來捕獲?？偤托ｒ?yàn)在流程中是至關(guān)重要的環(huán)節(jié)，但實(shí)際上在數(shù)據(jù)的準(zhǔn)備和導(dǎo)入環(huán)節(jié)最有可能遭受數(shù)據(jù)損壞或丟失。

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

云數(shù)據(jù)遷移瓶頸#4： 傳送的安排

將單個(gè)系統(tǒng)遷移到云上是相對容易的，只需把準(zhǔn)備好的數(shù)據(jù)復(fù)制到物理媒體上或通過互聯(lián)網(wǎng)上傳即可。但這一過程很難規(guī)?；?，尤其是物理媒體。當(dāng)許多不同的系統(tǒng)開始發(fā)揮作用時(shí)，那些在概念驗(yàn)證中看起來“簡單”的內(nèi)容可能演變成為“噩夢”。

一套媒體設(shè)備，比如一套 AWS Snowball，必須與每臺機(jī)器相連接。這可能意味著設(shè)備在一個(gè)或更多的數(shù)據(jù)中心周圍進(jìn)行物理行走、適配連接器、更新驅(qū)動(dòng)程序和安裝軟件。通過本地網(wǎng)絡(luò)連接可以節(jié)省物理移動(dòng)，但是軟件設(shè)置仍然具有挑戰(zhàn)性，并且復(fù)制速度可能下降到遠(yuǎn)低于直接通過互聯(lián)網(wǎng)上傳可以實(shí)現(xiàn)的速度。通過互聯(lián)網(wǎng)直接從每臺機(jī)器傳輸數(shù)據(jù)可以節(jié)省許多步驟，特別是當(dāng)數(shù)據(jù)已經(jīng)在云端時(shí)。

如果數(shù)據(jù)準(zhǔn)備包括復(fù)制、導(dǎo)出、重新格式化或歸檔，本地存儲會(huì)成為瓶頸。有必要設(shè)置專用存儲器來存儲準(zhǔn)備好的數(shù)據(jù)。這具有允許許多系統(tǒng)并行地執(zhí)行準(zhǔn)備的優(yōu)點(diǎn)，并將可運(yùn)輸媒體和數(shù)據(jù)傳輸軟件的接觸點(diǎn)減少到僅一個(gè)系統(tǒng)之中。

云數(shù)據(jù)遷移瓶頸#5： 數(shù)據(jù)傳送

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

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

物理裝運(yùn)和網(wǎng)絡(luò)傳輸之間的最大區(qū)別在概念驗(yàn)證過程中最常被忽略。對于物理裝運(yùn)，加載到設(shè)備上的第一個(gè)字節(jié)必須等到最后一個(gè)字節(jié)加載完成后才能裝運(yùn)。這意味著，如果加載該設(shè)備需要數(shù)周時(shí)間，那么在到達(dá)云端時(shí)，其中的一些數(shù)據(jù)將過期。即使數(shù)據(jù)集達(dá)到PB級別，物理裝運(yùn)總體上可能會(huì)更快一些，但在遷移過程中保持當(dāng)前優(yōu)先級數(shù)據(jù)的能力對于關(guān)鍵資產(chǎn)的網(wǎng)絡(luò)傳輸來說仍然是有利的。認(rèn)真規(guī)劃在數(shù)據(jù)準(zhǔn)備階段中的過濾和優(yōu)先次序是必須的，也可采用混合方法。

將數(shù)據(jù)放入云提供商網(wǎng)絡(luò)中并不是數(shù)據(jù)傳輸步驟的結(jié)束。如果需要將它復(fù)制到多個(gè)區(qū)域或供應(yīng)商那兒，就需要認(rèn)真計(jì)劃如何實(shí)現(xiàn)它。通過互聯(lián)網(wǎng)上傳是免費(fèi)的，如果通過AWS，區(qū)域間數(shù)據(jù)傳輸?shù)馁M(fèi)用高達(dá)2美分每GB，傳輸?shù)狡渌乒?yīng)商的費(fèi)用高達(dá)9美分每GB。這兩種方法都面臨帶寬限制，但是可以受益于像CloudDat這樣的傳輸加速器。

云數(shù)據(jù)遷移瓶頸#6： 云計(jì)算

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

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

一旦所傳輸?shù)臄?shù)據(jù)被驗(yàn)證，在基于云的應(yīng)用程序和服務(wù)能夠使用它之前，可能需要進(jìn)一步的提取、重新格式化和分發(fā)。這與在企業(yè)內(nèi)部進(jìn)行的準(zhǔn)備和編組處理完全相反。

擴(kuò)展數(shù)據(jù)的最后一步是驗(yàn)證數(shù)據(jù)是否正確和有用。這是上面討論的信息驗(yàn)證計(jì)劃的另一方面，并且是知道你是否真的完成的唯一方法。

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