行業(yè)資訊
將PB級字節(jié)的數(shù)據(jù)移動到云端是一項艱巨的任務(wù)。人們可能知道,在云端中訪問時,其應(yīng)用程序的行為會有所不同,成本結(jié)構(gòu)會有所不同,并且需要一些時間來移動所有數(shù)據(jù)。
當(dāng)企業(yè)用戶認為網(wǎng)絡(luò)速度是一個令人頭疼的問題時,希望能夠得到幫助。但在幫助企業(yè)克服這一問題的過程中,專業(yè)人員發(fā)現(xiàn)許多其他因素被忽略,可能會影響企業(yè)的云遷移。
收集、組織、格式化和驗證數(shù)據(jù)會給企業(yè)帶來比遷移更大的挑戰(zhàn)。以下是云遷移規(guī)劃階段需要考慮的一些常見因素,以便避免出現(xiàn)一些耗時而昂貴的問題。
1:數(shù)據(jù)存儲
人們在云遷移中看到的最常見的錯誤是將數(shù)據(jù)遷移到云存儲中而未考慮如何使用這些數(shù)據(jù)。人們典型的思考過程是,“我想把文檔和數(shù)據(jù)庫放在云中,是因為對象存儲成本很低。”但是文件、對象和數(shù)據(jù)庫的行為非常不同,將其數(shù)據(jù)放到錯誤的位置會削弱企業(yè)的云計劃。
文件由路徑層次結(jié)構(gòu)組成,即目錄樹。每個文件都可以快速訪問,延遲最短,并且快速(數(shù)據(jù)開始流動時的每秒位數(shù))。單個文件可以很容易地移動、重命名并更改。企業(yè)可能有許多小文件,少量大文件或任意大小和數(shù)據(jù)類型的組合。傳統(tǒng)的應(yīng)用程序可以像在本地一樣訪問云中的文件,而不需要特別的云感知。
所有這些特點使基于文件的存儲成為最為昂貴的選擇,但將文件存儲在云中還有其他一些缺點。為了實現(xiàn)更高的性能,大多數(shù)基于云服務(wù)器的文件系統(tǒng)(如Amazon EBS)一次只能由一個基于云服務(wù)器的虛擬機訪問,這意味著所有需要該數(shù)據(jù)的應(yīng)用程序必須運行在單個云虛擬機上。要為多個虛擬機(如Azure文件)提供服務(wù),需要使用像SMB這樣的NAS(網(wǎng)絡(luò)連接存儲)協(xié)議來存儲,這會嚴(yán)重限制性能。文件系統(tǒng)是快速、靈活和兼容的,但是它們很昂貴,僅適用于運行在云中的應(yīng)用程序,并且不能很好地擴展。
對象不是文件。請記住,因為它很容易遺忘。對象位于一個平面的命名空間中,就像一個巨大的目錄。其延遲時間很長,有時甚至達到數(shù)百或數(shù)千毫秒,吞吐量也很低,除非使用了巧妙的技巧,否則通常每秒鐘可以達到150兆比特左右。關(guān)于訪問對象的大部分內(nèi)容涉及到多部分上傳、字節(jié)范圍訪問和密鑰名稱優(yōu)化等巧妙技巧。對象可以同時從云服務(wù)器內(nèi)外進行讀取,但傳統(tǒng)應(yīng)用程序需要性能低下的解決方法。大多數(shù)用于訪問對象存儲的接口使對象看起來像文件:鍵名稱按前綴過濾,以看起來像文件夾,自定義元數(shù)據(jù)附加到對象,以顯示為文件元數(shù)據(jù)。以及某些系統(tǒng)(如虛擬機文件系統(tǒng)上的FUSE緩存對象),以允許訪問通過傳統(tǒng)應(yīng)用。但是這樣的解決方法很脆弱并且表現(xiàn)不佳。云存儲價格低廉,可擴展,云原生化,但速度慢,并且難以訪問。
數(shù)據(jù)庫具有自己的復(fù)雜結(jié)構(gòu),并且可以通過查詢語言(如SQL)訪問它們。傳統(tǒng)數(shù)據(jù)庫可能由文件存儲來支持,但它們需要實時數(shù)據(jù)庫進程來提供查詢。通過將數(shù)據(jù)庫文件和應(yīng)用程序復(fù)制到虛擬機上,或者通過將數(shù)據(jù)遷移到云托管的數(shù)據(jù)庫服務(wù)中,可以將其提升到云端。但將數(shù)據(jù)庫文件復(fù)制到對象存儲中僅作為脫機備份,這很有用。數(shù)據(jù)庫可以作為云托管服務(wù)的一部分進行擴展,但確保依賴于數(shù)據(jù)庫的應(yīng)用程序和進程完全兼容,并且基于云原生非常重要。數(shù)據(jù)庫存儲是高度專業(yè)化和專用的。
對象存儲的明顯成本節(jié)省與文件和數(shù)據(jù)庫功能的平衡需要仔細考慮需要哪些功能。例如,如果要存儲和分發(fā)成千上萬的小文件,請將它們存儲為ZIP文件,并將其作為單個對象存儲,而不是將每個單獨的文件存儲為單獨的對象。錯誤的存儲選擇可能會導(dǎo)致復(fù)雜的依賴關(guān)系,這些依賴關(guān)系在以后更改很困難,并且代價較高。
2:數(shù)據(jù)準(zhǔn)備
將數(shù)據(jù)移動到云端,并不像將數(shù)據(jù)復(fù)制到指定的存儲類型那樣簡單。企業(yè)在復(fù)制任何內(nèi)容之前需要做大量的準(zhǔn)備工作,并且需要仔細規(guī)劃預(yù)算。概念驗證項目經(jīng)常忽略這一步驟,這可能會導(dǎo)致以后出現(xiàn)代價高昂的超支。
過濾掉不必要的數(shù)據(jù)可以節(jié)省大量時間和存儲成本。例如,數(shù)據(jù)集可能包含不需要成為云服務(wù)器工作流程一部分的備份文件、早期版本或臨時文件。也許過濾最重要的部分是優(yōu)先考慮哪些數(shù)據(jù)需要先移動。正在積極使用的數(shù)據(jù)不會容忍在完成整個遷移過程所需的幾周、幾個月或幾年內(nèi)不同步。這里的關(guān)鍵是想出一個自動化的方式來選擇要發(fā)送哪些數(shù)據(jù)以及何時發(fā)送,然后仔細記錄所有未完成的事情。
不同的云服務(wù)器工作流可能要求數(shù)據(jù)的格式或組織與本地應(yīng)用程序不同。例如,一個工作流可能需要編譯成千上萬的小型Word或PDF文檔并將其打包成ZIP文件,媒體工作流可能涉及代碼轉(zhuǎn)換和元數(shù)據(jù)打包,而生物信息學(xué)工作流可能需要挑選和分段TB級數(shù)量的基因組數(shù)據(jù)。這種重新格式化可能是一個非常費時和費力的過程。它可能需要大量的實驗,大量的臨時存儲以及大量的異常處理。有時很容易推遲重新格式化到云環(huán)境,但請記住,這不能解決問題,它只是將其轉(zhuǎn)移到企業(yè)使用的每種資源的環(huán)境中。
存儲和格式問題的一部分可能涉及壓縮和存檔的決定。例如,在將數(shù)百萬個小文本文件發(fā)送到云端之前將其壓縮是有意義的,而不是幾千兆字節(jié)的多媒體文件。歸檔和壓縮數(shù)據(jù)可以更輕松地傳輸和存儲數(shù)據(jù),但考慮在打包和解壓縮這些歸檔所需的時間和存儲空間。
3:信息驗證
完整性檢查是一個最重要的步驟,也是最容易出錯的步驟。通常假設(shè)數(shù)據(jù)傳輸期間會發(fā)生損壞,無論是通過物理介質(zhì)還是網(wǎng)絡(luò)傳輸,并且可以通過在前后執(zhí)行校驗和來捕獲。校驗和是這個過程的重要組成部分,但它實際上是準(zhǔn)備和導(dǎo)入最可能遭受損失或損壞的數(shù)據(jù)。
當(dāng)數(shù)據(jù)轉(zhuǎn)換格式和應(yīng)用程序時,即使字節(jié)相同,意義和功能也會丟失。軟件版本之間的簡單不兼容可能導(dǎo)致PB級的“正確”數(shù)據(jù)無用。使用可擴展的流程來驗證企業(yè)的數(shù)據(jù)是否正確可用,這可能是一項艱巨的任務(wù)。在最糟糕的情況下,它可能會轉(zhuǎn)變?yōu)閯趧用芗秃筒痪_的“看起來沒問題”的人工處理過程。但即使這樣做,也比沒有驗證要好。最重要的是確保企業(yè)能夠在遺留系統(tǒng)退役之前識別問題!