將PB級(jí)字節(jié)的數(shù)據(jù)移動(dòng)到云端是一項(xiàng)艱巨的任務(wù)。人們可能知道，在云端中訪問時(shí)，其應(yīng)用程序的行為會(huì)有所不同，成本結(jié)構(gòu)會(huì)有所不同，并且需要一些時(shí)間來移動(dòng)所有數(shù)據(jù)。

當(dāng)企業(yè)用戶認(rèn)為網(wǎng)絡(luò)速度是一個(gè)令人頭疼的問題時(shí)，希望能夠得到幫助。但在幫助企業(yè)克服這一問題的過程中，專業(yè)人員發(fā)現(xiàn)許多其他因素被忽略，可能會(huì)影響企業(yè)的云遷移。

收集、組織、格式化和驗(yàn)證數(shù)據(jù)會(huì)給企業(yè)帶來比遷移更大的挑戰(zhàn)。以下是云遷移規(guī)劃階段需要考慮的一些常見因素，以便避免出現(xiàn)一些耗時(shí)而昂貴的問題。

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

人們?cè)谠七w移中看到的最常見的錯(cuò)誤是將數(shù)據(jù)遷移到云存儲(chǔ)中而未考慮如何使用這些數(shù)據(jù)。人們典型的思考過程是，“我想把文檔和數(shù)據(jù)庫放在云中，是因?yàn)閷?duì)象存儲(chǔ)成本很低。”但是文件、對(duì)象和數(shù)據(jù)庫的行為非常不同，將其數(shù)據(jù)放到錯(cuò)誤的位置會(huì)削弱企業(yè)的云計(jì)劃。

文件由路徑層次結(jié)構(gòu)組成，即目錄樹。每個(gè)文件都可以快速訪問，延遲最短，并且快速（數(shù)據(jù)開始流動(dòng)時(shí)的每秒位數(shù)）。單個(gè)文件可以很容易地移動(dòng)、重命名并更改。企業(yè)可能有許多小文件，少量大文件或任意大小和數(shù)據(jù)類型的組合。傳統(tǒng)的應(yīng)用程序可以像在本地一樣訪問云中的文件，而不需要特別的云感知。

所有這些特點(diǎn)使基于文件的存儲(chǔ)成為最為昂貴的選擇，但將文件存儲(chǔ)在云中還有其他一些缺點(diǎn)。為了實(shí)現(xiàn)更高的性能，大多數(shù)基于云計(jì)算的文件系統(tǒng)（如AmazonEBS）一次只能由一個(gè)基于云計(jì)算的虛擬機(jī)訪問，這意味著所有需要該數(shù)據(jù)的應(yīng)用程序必須運(yùn)行在單個(gè)云虛擬機(jī)上。要為多個(gè)虛擬機(jī)（如Azure文件）提供服務(wù)，需要使用像SMB這樣的NAS（網(wǎng)絡(luò)連接存儲(chǔ)）協(xié)議來存儲(chǔ)，這會(huì)嚴(yán)重限制性能。文件系統(tǒng)是快速、靈活和兼容的，但是它們很昂貴，僅適用于運(yùn)行在云中的應(yīng)用程序，并且不能很好地?cái)U(kuò)展。

對(duì)象不是文件。請(qǐng)記住，因?yàn)樗苋菀走z忘。對(duì)象位于一個(gè)平面的命名空間中，就像一個(gè)巨大的目錄。其延遲時(shí)間很長(zhǎng)，有時(shí)甚至達(dá)到數(shù)百或數(shù)千毫秒，吞吐量也很低，除非使用了巧妙的技巧，否則通常每秒鐘可以達(dá)到150兆比特左右。關(guān)于訪問對(duì)象的大部分內(nèi)容涉及到多部分上傳、字節(jié)范圍訪問和密鑰名稱優(yōu)化等巧妙技巧。對(duì)象可以同時(shí)從云計(jì)算內(nèi)外進(jìn)行讀取，但傳統(tǒng)應(yīng)用程序需要性能低下的解決方法。大多數(shù)用于訪問對(duì)象存儲(chǔ)的接口使對(duì)象看起來像文件：鍵名稱按前綴過濾，以看起來像文件夾，自定義元數(shù)據(jù)附加到對(duì)象，以顯示為文件元數(shù)據(jù)。以及某些系統(tǒng)（如虛擬機(jī)文件系統(tǒng)上的FUSE緩存對(duì)象），以允許訪問通過傳統(tǒng)應(yīng)用。但是這樣的解決方法很脆弱并且表現(xiàn)不佳。云存儲(chǔ)價(jià)格低廉，可擴(kuò)展，云原生化，但速度慢，并且難以訪問。

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

對(duì)象存儲(chǔ)的明顯成本節(jié)省與文件和數(shù)據(jù)庫功能的平衡需要仔細(xì)考慮需要哪些功能。例如，如果要存儲(chǔ)和分發(fā)成千上萬的小文件，請(qǐng)將它們存儲(chǔ)為ZIP文件，并將其作為單個(gè)對(duì)象存儲(chǔ)，而不是將每個(gè)單獨(dú)的文件存儲(chǔ)為單獨(dú)的對(duì)象。錯(cuò)誤的存儲(chǔ)選擇可能會(huì)導(dǎo)致復(fù)雜的依賴關(guān)系，這些依賴關(guān)系在以后更改很困難，并且代價(jià)較高。

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

將數(shù)據(jù)移動(dòng)到云端，并不像將數(shù)據(jù)復(fù)制到指定的存儲(chǔ)類型那樣簡(jiǎn)單。企業(yè)在復(fù)制任何內(nèi)容之前需要做大量的準(zhǔn)備工作，并且需要仔細(xì)規(guī)劃預(yù)算。概念驗(yàn)證項(xiàng)目經(jīng)常忽略這一步驟，這可能會(huì)導(dǎo)致以后出現(xiàn)代價(jià)高昂的超支。

過濾掉不必要的數(shù)據(jù)可以節(jié)省大量時(shí)間和存儲(chǔ)成本。例如，數(shù)據(jù)集可能包含不需要成為云計(jì)算工作流程一部分的備份文件、早期版本或臨時(shí)文件。也許過濾最重要的部分是優(yōu)先考慮哪些數(shù)據(jù)需要先移動(dòng)。正在積極使用的數(shù)據(jù)不會(huì)容忍在完成整個(gè)遷移過程所需的幾周、幾個(gè)月或幾年內(nèi)不同步。這里的關(guān)鍵是想出一個(gè)自動(dòng)化的方式來選擇要發(fā)送哪些數(shù)據(jù)以及何時(shí)發(fā)送，然后仔細(xì)記錄所有未完成的事情。

不同的云計(jì)算工作流可能要求數(shù)據(jù)的格式或組織與本地應(yīng)用程序不同。例如，一個(gè)工作流可能需要編譯成千上萬的小型Word或PDF文檔并將其打包成ZIP文件，媒體工作流可能涉及代碼轉(zhuǎn)換和元數(shù)據(jù)打包，而生物信息學(xué)工作流可能需要挑選和分段TB級(jí)數(shù)量的基因組數(shù)據(jù)。這種重新格式化可能是一個(gè)非常費(fèi)時(shí)和費(fèi)力的過程。它可能需要大量的實(shí)驗(yàn)，大量的臨時(shí)存儲(chǔ)以及大量的異常處理。有時(shí)很容易推遲重新格式化到云環(huán)境，但請(qǐng)記住，這不能解決問題，它只是將其轉(zhuǎn)移到企業(yè)使用的每種資源的環(huán)境中。

存儲(chǔ)和格式問題的一部分可能涉及壓縮和存檔的決定。例如，在將數(shù)百萬個(gè)小文本文件發(fā)送到云端之前將其壓縮是有意義的，而不是幾千兆字節(jié)的多媒體文件。歸檔和壓縮數(shù)據(jù)可以更輕松地傳輸和存儲(chǔ)數(shù)據(jù)，但考慮在打包和解壓縮這些歸檔所需的時(shí)間和存儲(chǔ)空間。

云遷移瓶頸#3：信息驗(yàn)證

完整性檢查是一個(gè)最重要的步驟，也是最容易出錯(cuò)的步驟。通常假設(shè)數(shù)據(jù)傳輸期間會(huì)發(fā)生損壞，無論是通過物理介質(zhì)還是網(wǎng)絡(luò)傳輸，并且可以通過在前后執(zhí)行校驗(yàn)和來捕獲。校驗(yàn)和是這個(gè)過程的重要組成部分，但它實(shí)際上是準(zhǔn)備和導(dǎo)入最可能遭受損失或損壞的數(shù)據(jù)。

當(dāng)數(shù)據(jù)轉(zhuǎn)換格式和應(yīng)用程序時(shí)，即使字節(jié)相同，意義和功能也會(huì)丟失。軟件版本之間的簡(jiǎn)單不兼容可能導(dǎo)致PB級(jí)的“正確”數(shù)據(jù)無用。使用可擴(kuò)展的流程來驗(yàn)證企業(yè)的數(shù)據(jù)是否正確可用，這可能是一項(xiàng)艱巨的任務(wù)。在最糟糕的情況下，它可能會(huì)轉(zhuǎn)變?yōu)閯趧?dòng)密集型和不精確的“看起來沒問題”的人工處理過程。但即使這樣做，也比沒有驗(yàn)證要好。最重要的是確保企業(yè)能夠在遺留系統(tǒng)退役之前識(shí)別問題！

云遷移瓶頸#4：轉(zhuǎn)移封送

將單個(gè)系統(tǒng)提升到云端時(shí)，將準(zhǔn)備好的數(shù)據(jù)復(fù)制到物理介質(zhì)或?qū)⑵渫扑偷饺蚧ヂ?lián)網(wǎng)上相對(duì)比較容易。但是這個(gè)過程可能難以擴(kuò)展，特別是對(duì)于物理媒體來說。在概念證明中，看起來“簡(jiǎn)單”的東西可能會(huì)在許多不同的系統(tǒng)發(fā)揮作用時(shí)變成“噩夢(mèng)”。

媒體設(shè)備（例如AWS Snowball）必須連接到每臺(tái)機(jī)器。這可能意味著要在一個(gè)或多個(gè)數(shù)據(jù)中心周圍移動(dòng)設(shè)備，進(jìn)行連接，并更新驅(qū)動(dòng)程序和安裝軟件。而通過本地網(wǎng)絡(luò)進(jìn)行連接可以省去物理移動(dòng)措施，但軟件設(shè)置仍然具有挑戰(zhàn)性，復(fù)制速度可能會(huì)降至遠(yuǎn)低于直接通過全球互聯(lián)網(wǎng)上傳可實(shí)現(xiàn)的速度。通過互聯(lián)網(wǎng)直接從每臺(tái)計(jì)算機(jī)傳輸數(shù)據(jù)可節(jié)省很多步驟，特別是在數(shù)據(jù)準(zhǔn)備就緒的情況下。

如果數(shù)據(jù)準(zhǔn)備涉及復(fù)制、導(dǎo)出、重新格式化或存檔，本地存儲(chǔ)可能成為瓶頸。可能需要設(shè)置專用存儲(chǔ)來分階段準(zhǔn)備好的數(shù)據(jù)。這具有允許許多系統(tǒng)并行地進(jìn)行準(zhǔn)備的優(yōu)點(diǎn)，并且減少了用于可運(yùn)送媒體和數(shù)據(jù)傳輸軟件的聯(lián)系點(diǎn)到只有一個(gè)系統(tǒng)。

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

將網(wǎng)絡(luò)傳輸與媒質(zhì)傳輸進(jìn)行比較時(shí)，很容易只關(guān)注發(fā)送時(shí)間。例如，通過快遞可能會(huì)發(fā)送80TB的AWS Snowball設(shè)備，從而實(shí)現(xiàn)很快的表觀數(shù)據(jù)速率。但是這忽略了獲取設(shè)備、配置和加載設(shè)備，準(zhǔn)備返回設(shè)備，以及允許云計(jì)算供應(yīng)商在后端復(fù)制數(shù)據(jù)所需的時(shí)間。而這樣做的客戶定期報(bào)告說，這樣的周轉(zhuǎn)時(shí)間（從設(shè)備訂購到云中可用的數(shù)據(jù)）是常見的。這將設(shè)備運(yùn)輸?shù)膶?shí)際數(shù)據(jù)傳輸速率降低到每秒300兆比特，如果設(shè)備沒有完全填充，則會(huì)大大降低。

網(wǎng)絡(luò)傳輸速度同樣取決于許多因素，最重要的是本地上行鏈路。盡管做好充分的數(shù)據(jù)準(zhǔn)備可以減少企業(yè)需要發(fā)送的數(shù)據(jù)量，但無法以比物理比特率更快的速度發(fā)送數(shù)據(jù)。傳統(tǒng)協(xié)議（包括云計(jì)算供應(yīng)商默認(rèn)用于對(duì)象存儲(chǔ)的那些協(xié)議）在長(zhǎng)距離全球互聯(lián)網(wǎng)路徑上的速度和可靠性方面存在困難，這可能導(dǎo)致實(shí)現(xiàn)該比特率變得困難。而用戶如果采用CloudDat等加速軟件的千兆互聯(lián)網(wǎng)連接，可達(dá)到每秒產(chǎn)生900兆比特的速率，是AWS Snowball的凈吞吐量的三倍。

物理運(yùn)輸和網(wǎng)絡(luò)傳輸之間的最大區(qū)別也是概念驗(yàn)證期間最常被忽視的問題之一。通過物理裝運(yùn)，加載到設(shè)備上的第一個(gè)字節(jié)必須等到最后一個(gè)字節(jié)全部復(fù)制之后才能發(fā)貨。這意味著如果加載設(shè)備需要幾周的時(shí)間，那么一些數(shù)據(jù)在到達(dá)云端時(shí)會(huì)過時(shí)幾周。即使數(shù)據(jù)集達(dá)到總體實(shí)際傳輸速度可能更快的PB級(jí)別，在遷移過程中保持優(yōu)先數(shù)據(jù)流動(dòng)的能力仍然可能有利于關(guān)鍵資產(chǎn)的網(wǎng)絡(luò)傳輸。在數(shù)據(jù)準(zhǔn)備的過濾和優(yōu)化階段進(jìn)行仔細(xì)的計(jì)劃是必不可少的，并且可能允許采用混合方法。

將數(shù)據(jù)導(dǎo)入云計(jì)算提供商可能不是數(shù)據(jù)傳輸步驟的結(jié)束。如果它需要復(fù)制到多個(gè)區(qū)域或提供商，請(qǐng)仔細(xì)規(guī)劃如何到達(dá)那里。通過互聯(lián)網(wǎng)上傳是免費(fèi)的，而AWS例如對(duì)于區(qū)域間數(shù)據(jù)傳輸?shù)氖召M(fèi)高達(dá)每千兆字節(jié)2美分，對(duì)于其他云計(jì)算供應(yīng)商而言，每千兆字節(jié)需要收取9美分。這兩種方法都將面臨帶寬限制，這可能會(huì)受益于傳輸加速軟件，如CloudDat.

云遷移瓶頸#6：云擴(kuò)展

一旦數(shù)據(jù)到達(dá)云端的目的地，其遷移過程只完成一半。首先檢查校驗(yàn)和，這將確保到達(dá)的字節(jié)與發(fā)送的字節(jié)匹配。這可能比人們可能意識(shí)到的更復(fù)雜。文件存儲(chǔ)使用可以隱藏剛剛上傳的數(shù)據(jù)損壞的緩存層。這種損壞非常罕見，但在清除所有緩存并重新讀取文件之前，人們無法確定任何校驗(yàn)和。重新啟動(dòng)實(shí)例或卸載存儲(chǔ)確實(shí)可以容忍清除緩存。

驗(yàn)證對(duì)象存儲(chǔ)校驗(yàn)和需要將每個(gè)對(duì)象讀出到一個(gè)實(shí)例中進(jìn)行計(jì)算。與流行的觀點(diǎn)相反，對(duì)象“電子標(biāo)簽”作為校驗(yàn)和是無用的。使用多部分技術(shù)上傳的對(duì)象只能通過讀取它們來驗(yàn)證。

一旦傳輸?shù)臄?shù)據(jù)得到驗(yàn)證，在企業(yè)的基于云計(jì)算的應(yīng)用程序和服務(wù)可以使用它之前，可能需要進(jìn)一步提取和重新格式化和分發(fā)。這與在場(chǎng)所發(fā)生的準(zhǔn)備和發(fā)送幾乎是相反的。

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

云遷移更多的是關(guān)于流程而不是數(shù)據(jù)。即使看似簡(jiǎn)單的文件分發(fā)任務(wù)也需要復(fù)雜的遷移步驟，以確保生成的云計(jì)算基礎(chǔ)架構(gòu)與所需的工作流程相匹配。而圍繞云計(jì)算技術(shù)的大量宣傳，從成本節(jié)約到可擴(kuò)展性都是有道理的。但仔細(xì)規(guī)劃和預(yù)測(cè)困難對(duì)于確定實(shí)現(xiàn)這些回報(bào)所需的工具和方法至關(guān)重要。