遷移至 Google Cloud:轉移大型資料集

Last reviewed 2024-11-13 UTC

對許多客戶而言,採用 Google Cloud產品的第一步就是將資料匯入 Google Cloud。本文將探討這個程序,包括規劃資料移轉和實施計畫的最佳做法。

轉移大型資料集需要組建合適的團隊、提早規劃,以及在正式環境中實作轉移計畫前先進行測試。雖然這些步驟可能需要與移轉本身一樣多的時間,但這類準備工作有助於在移轉期間,盡量減少對業務營運的干擾。

本文是下列多部分系列文章之一,探討如何遷移至Google Cloud:

什麼是資料轉移?

就本文而言,資料轉移是指在不轉換資料的情況下移動資料,例如將檔案原封不動地移至物件。

資料移轉並不如想像中簡單

您可能會想將資料移轉視為一個巨大的 FTP 工作階段,將檔案放在一端,然後等待檔案出現在另一端。不過,在大多數企業環境中,轉移程序會受到許多因素影響,例如:

  • 制定移轉計畫,將行政時間納入考量,包括決定移轉選項、取得核准,以及處理意料之外的問題。
  • 協調貴機構中的人員,例如執行轉移作業的團隊、核准工具和架構的人員,以及關心資料轉移價值和中斷情況的業務利害關係人。
  • 根據資源、費用、時間和其他專案考量,選擇合適的轉移工具。
  • 克服資料傳輸挑戰,包括「光速」問題 (頻寬不足)、移動正在使用的資料集、在資料傳輸期間保護及監控資料,以及確保資料順利傳輸。

這份文件旨在協助您順利啟動轉移計畫。

下表列出其他類型資料移轉專案的資源,這些專案不在本文涵蓋範圍內:

步驟 1:組建團隊

規劃移轉作業時,通常需要具備下列角色和職責的人員:

  • 移轉所需的資源:儲存空間、IT 和網路管理員、執行長贊助者,以及其他顧問 (例如 Google 帳戶團隊或整合合作夥伴)
  • 核准移轉決策:資料擁有者或管理員 (根據內部政策,決定哪些人可以移轉哪些資料)、法律顧問 (根據資料相關法規),以及安全管理員 (根據內部政策,決定如何保護資料存取權)
  • 執行轉移作業:團隊負責人、專案經理 (負責執行及追蹤專案)、工程團隊,以及現場接收和運送團隊 (負責接收設備硬體)

請務必找出負責先前責任的人員,並在適當情況下邀請他們參加規劃和決策會議。組織規劃不當通常是導致轉移計畫失敗的原因。

收集專案需求和這些利害關係人的意見可能很困難,但制定計畫並明確劃分角色和職責,將有助於專案順利進行。您不可能瞭解所有資料的詳細資訊,組建團隊可讓您更深入瞭解業務需求。建議您先找出潛在問題,再投入時間、金錢和資源完成轉移。

步驟 2:收集需求和可用資源

設計轉移計畫時,建議您先收集資料轉移需求,然後再決定轉移選項。如要收集需求,請按照下列程序操作:

  1. 找出需要移動的資料集。
    • 選取「資料目錄」等工具,將資料整理成邏輯群組,以便一起移動及使用。
    • 與機構內的團隊合作,驗證或更新這些分組。
  2. 找出可以移動的資料集。
    • 請考量法規、安全性或其他因素,確認是否禁止轉移部分資料集。
    • 如果需要在遷移資料前轉換部分資料 (例如移除機密資料或重整資料),建議使用資料整合產品 (如 DataflowCloud Data Fusion),或工作流程自動化調度管理產品 (如 Cloud Composer)。
  3. 針對可移動的資料集,決定要將每個資料集移轉至何處。
    • 記錄您選取的資料儲存選項。通常,Google Cloud 上的目標儲存系統是 Cloud Storage。即使應用程式上線運作後,您需要更複雜的解決方案,Cloud Storage 仍是可擴充且耐用的儲存選項。
    • 瞭解遷移後必須維持哪些資料存取權政策。
    • 判斷是否需要將這項資料儲存在特定區域
    • 規劃如何在目的地建構這項資料。例如,是否與來源相同或不同?
    • 判斷是否需要持續轉移資料。
  4. 如果是可移動的資料集,請判斷可用的移動資源。
    • 時間:何時需要完成轉移?
    • 費用:團隊可用的預算和轉移費用是多少?
    • 人員:誰可以執行轉移作業?
    • 頻寬 (線上轉移):可分配多少可用頻寬 Google Cloud 用於轉移,以及分配時間長度?

在規劃的下一階段評估及選取轉移選項前,建議您先評估 IT 模式是否有任何可改善之處,例如資料控管、機構和安全性。

您的安全模型

在資料移轉專案中,移轉團隊的許多成員可能會在貴機構 Google Cloud 獲得新角色。規劃資料移轉作業時,不妨一併檢查身分與存取權管理 (IAM) 權限,並參閱安全使用 IAM 的最佳做法。這些問題可能會影響您授予儲存空間存取權的方式。舉例來說,您可能會嚴格限制因法規原因而封存的資料寫入權限,但允許許多使用者和應用程式將資料寫入測試環境。

貴機構 Google Cloud

在 Google Cloud 上安排資料結構的方式,取決於您打算如何使用Google Cloud。將資料儲存在執行應用程式的同一個 Google Cloud 專案中或許可行,但從管理角度來看可能不是最佳做法。部分開發人員可能沒有權限查看正式版資料。在這種情況下,開發人員可以在範例資料上開發程式碼,而具備權限的服務帳戶則可存取正式環境資料。因此,您可能會想將整個實際工作環境資料集保留在個別Google Cloud 專案中,然後使用服務帳戶,允許從每個應用程式專案存取資料。

Google Cloud 是以專案為中心。專案可以分組至資料夾,資料夾則可分組至機構底下。角色是在專案層級建立,存取權限則是在 Cloud Storage 值區層級新增至這些角色。這項結構與其他物件儲存空間供應商的權限結構一致。

如要瞭解機構結構的最佳做法,請參閱為 Google Cloud 登陸區決定資源階層。 Google Cloud

步驟 3:評估轉移選項

如要評估資料移轉選項,移轉團隊需要考量多項因素,包括:

  • 費用
  • 轉移時間
  • 離線與線上轉移選項
  • 轉移工具和技術
  • 安全性

費用

資料移轉相關費用大多包括下列項目:

  • 網路費用
    • 輸入 Cloud Storage 無須付費。不過,如果您將資料託管在公有雲供應商,則可能需要支付輸出費用,以及資料轉移的儲存空間費用 (例如讀取作業)。這項費用適用於來自 Google 或其他雲端服務供應商的資料。
    • 如果資料代管在您營運的私人資料中心,您可能也需要為設定更多頻寬支付額外費用。 Google Cloud
  • 資料移轉期間和移轉後,Cloud Storage 的儲存空間和作業費用
  • 產品費用 (例如 Transfer Appliance)
  • 組建團隊和取得後勤支援的人事成本

轉移時間

在運算領域中,很少有事情能像傳輸大量資料一樣,凸顯網路的硬體限制。理想情況下,透過 1 Gbps 網路傳輸 1 GB 的資料,只需要八秒。如果將資料集擴大到 100 TB,轉移時間就會延長至 12 天。傳輸巨量資料集可能會測試基礎架構的極限,並可能導致業務問題。

估算移轉作業可能需要多少時間時,請將下列因素納入計算:

  • 要移動的資料集大小。
  • 可供轉移的頻寬。
  • 管理時間的特定百分比。
  • 頻寬效率,這也會影響傳輸時間。

您可能不想在工作尖峰時段,將大型資料集移出公司網路。如果傳輸作業造成網路過載,其他人就無法完成必要或重要業務的工作。因此,移轉團隊必須考慮時間因素。

資料移轉至 Cloud Storage 後,您可以使用多種技術處理新檔案,例如 Dataflow。

增加網路頻寬

增加網路頻寬的方法取決於您連線至Google Cloud的方式。

在 Google Cloud 和其他雲端供應商之間進行雲端至雲端移轉時,Google 會在雲端供應商資料中心之間佈建連線,您無須進行任何設定。

如果您要在私人資料中心和Google Cloud之間轉移資料,可以採取下列幾種做法:

  • 使用公開 API 的公開網際網路連線
  • 使用公開 API 進行直接對等互連
  • 使用私人 API 存取 Cloud Interconnect

評估這些方法時,請考量長期連線需求。您可能會認為單純為了傳輸而取得頻寬的成本過高,但考量到長期使用Google Cloud 和整個機構的網路需求,這項投資可能物有所值。如要進一步瞭解如何將網路連線至Google Cloud,請參閱「選擇網路連線產品」。

如果您選擇透過公用網際網路傳輸資料,建議您先向安全管理員確認公司政策是否禁止這類傳輸作業。此外,請檢查生產流量是否使用公開網際網路連線。最後,請注意大規模資料移轉可能會對生產網路的效能造成負面影響。

線上與離線移轉

重要決策是資料轉移要使用離線或線上程序。也就是說,您必須選擇透過網路 (無論是 Cloud Interconnect 或公開網際網路) 傳輸,或是使用儲存裝置傳輸。

為協助您做出決定,下圖也顯示各種資料集大小和頻寬的移轉速度。這些計算結果已納入一定程度的管理間接費用。

圖表:顯示傳輸大小與傳輸速度之間的關係。

如先前所述,您可能需要考慮,為降低資料移轉延遲時間而付出的成本 (例如取得網路頻寬),是否能為貴機構帶來相應價值。

Google 提供的選項

Google 提供多項工具和技術,協助您轉移資料。

選擇 Google 的轉移選項

選擇移轉選項時,請參考下表,根據您的用途選擇。

資料遷移來源 情境 建議產品
其他雲端服務供應商 (例如 Amazon Web Services 或 Microsoft Azure) Google Cloud Storage 移轉服務
Cloud Storage 至 Cloud Storage (兩個不同的值區) Storage 移轉服務
您的私人資料中心到 Google Cloud 頻寬充足,可如期完成專案 gcloud storage 指令
您的私有資料中心到 Google Cloud 頻寬充足,可如期完成專案 Transfer Service for On Premises Data
您的私有資料中心到 Google Cloud 頻寬不足,無法在專案期限內完成 Transfer Appliance

gcloud storage 指令,用於較小規模的內部部署資料傳輸作業

gcloud storage 指令是標準工具,適用於透過一般企業規模網路,從私人資料中心或從其他雲端供應商移轉至 Google Cloud的中小型移轉作業。雖然 gcloud storage 支援上傳物件,最大可達Cloud Storage 物件大小上限,但與時間較短的傳輸作業相比,大型物件的傳輸作業更容易失敗。如要進一步瞭解如何將大型物件轉移至 Cloud Storage,請參閱使用 Storage Transfer Service 大規模轉移地端部署資料

gcloud storage 指令在下列情況特別實用:

  • 您必須視需要執行轉移作業,或在使用者執行命令列工作階段時執行。
  • 你只轉移幾個檔案或非常大的檔案,或兩者皆是。
  • 您正在使用程式的輸出內容 (將輸出內容串流至 Cloud Storage)。
  • 您需要監控檔案數量適中的目錄,並以極低的延遲時間同步處理任何更新。

Storage Transfer Service for On Premises Data

gcloud storage 指令類似,Storage Transfer Service for On Premises Data 可將資料從網路檔案系統 (NFS) 儲存空間轉移至 Cloud Storage。Storage Transfer Service for On Premises Data 專為大規模轉移作業而設計 (最多可轉移數 PB 的資料,數十億個檔案)。這項工具支援完整副本或增量副本,適用於先前在「決定 Google 轉移選項」一節中列出的所有轉移選項。此外,這項工具還提供受管理的圖形使用者介面,即使是不擅長技術的使用者 (設定完成後) 也能用來轉移資料。

Transfer Service for On Premises Data 特別適合用於下列情境:

  • 您有足夠的可用頻寬來移動資料量。
  • 您支援大量內部使用者,他們可能會覺得指令列工具難以使用。
  • 您需要健全的錯誤回報機制,以及所有已移動檔案和物件的記錄。
  • 您需要限制轉移作業對資料中心其他工作負載的影響 (這項產品可維持在使用者指定的頻寬限制內)。
  • 您希望按照時間表執行週期性移轉。

如要設定 Storage Transfer Service for On Premises Data,請在資料中心的電腦上安裝內部部署軟體 (稱為「代理程式」)。

設定 Storage 移轉服務後,您可以在Google Cloud 控制台中提供來源目錄、目的地 bucket 和時間或排程,即可啟動移轉作業。Storage 移轉服務會遞迴檢索來源目錄中的子目錄和檔案,並在 Cloud Storage 中建立名稱對應的物件 (物件 /dir/foo/file.txt 會成為目標 bucket 中名為 /dir/foo/file.txt 的物件)。如果遇到任何暫時性錯誤,Storage 移轉服務會自動重新嘗試移轉。傳輸作業執行期間,您可以監控已移動的檔案數量和整體傳輸速度,並查看錯誤樣本。

Storage 移轉服務完成移轉後,會產生以 Tab 分隔的檔案 (TSV),其中包含所有已處理檔案的完整記錄,以及收到的任何錯誤訊息。代理程式具有容錯能力,因此即使有代理程式停止運作,轉移作業仍會繼續進行。代理程式也會自動更新和自我修復,因此您不必擔心修補最新版本,或因發生預料外的問題而重新啟動程序。

使用 Storage 移轉服務時,請注意下列事項:

  • 在每部電腦上使用相同的代理程式設定。所有代理程式都應以相同方式 (相同相對路徑) 查看相同的網路檔案系統 (NFS) 掛接點。產品必須完成這項設定才能運作。
  • 代理程式越多,速度就越快。由於系統會自動在所有代理程式之間平行處理轉移作業,建議您部署多個代理程式,充分利用可用頻寬。
  • 頻寬上限可保護工作負載。其他工作負載可能會使用資料中心頻寬,因此請設定頻寬上限,避免轉移作業影響服務水準協議。
  • 預留時間檢查錯誤。大型轉移作業通常會導致錯誤,需要審查。您可透過 Storage 移轉服務,直接在 Google Cloud 控制台中查看遇到的錯誤範例。如有需要,您可以將所有移轉錯誤的完整記錄載入 BigQuery,檢查檔案或評估重試後仍存在的錯誤。這些錯誤可能是因為在轉移期間執行寫入來源的應用程式所致,也可能顯示需要排解的問題 (例如權限錯誤)。
  • 設定 Cloud Monitoring,監控長時間執行的轉移作業。 Storage 移轉服務可讓 Monitoring 監控代理程式健康狀態和輸送量,因此您可以設定快訊,在代理程式停止運作或需要注意時收到通知。如果移轉作業需要數天或數週才能完成,請務必處理代理程式失敗問題,以免發生重大延遲或中斷,導致專案時程延誤。

使用 Transfer Appliance 移轉大量資料

對於大規模傳輸 (尤其是網路頻寬有限的傳輸作業),Transfer Appliance 是絕佳選擇,尤其是在無法使用快速網路連線,且取得更多頻寬的成本過高時。

Transfer Appliance 特別適合下列情境:

  • 資料中心位於偏遠地區,頻寬有限或無法存取頻寬。
  • 有可用頻寬,但無法及時取得,因此無法在期限內完成作業。
  • 你擁有物流資源,可接收家電並連上網路。

使用這個選項時,請注意下列事項:

  • 使用 Transfer Appliance 時,您必須能夠接收並寄回 Google 擁有的硬體。
  • 視網路連線而定,使用 Transfer Appliance 將資料傳輸到 Google Cloud 的延遲時間通常會比線上傳輸長。
  • Transfer Appliance 僅適用於特定國家/地區。

使用 Transfer Appliance 時,主要考量因素是成本和速度。如果網路連線速度合理 (例如 1 Gbps),線上轉移 100 TB 的資料需要超過 10 天才能完成。如果這個費率可以接受,線上轉移可能就是符合您需求的解決方案。如果連線速度只有 100 Mbps (或更慢,例如從遠端位置連線),同樣的轉移作業會耗費超過 100 天。此時,不妨考慮使用 Transfer Appliance 等離線移轉選項。

取得 Transfer Appliance 的程序相當簡單。在Google Cloud 控制台中,您可以申請 Transfer Appliance,指出資料量,然後 Google 會將一或多部設備運送到您要求的位置。您有幾天的時間可將資料傳輸到設備中 (「資料擷取」),然後將設備送回 Google。

適用於雲端對雲端移轉作業的 Storage 移轉服務

Storage 移轉服務是一項全代管的擴充型服務,可自動將其他公有雲的資料移轉至 Cloud Storage。舉例來說,您可以使用 Storage 移轉服務,將資料從 Amazon S3 移轉至 Cloud Storage

如果是 HTTP,您可以提供特定格式的公開網址清單給 Storage 移轉服務。這個方法需要您編寫指令碼,提供每個檔案的大小 (以位元組為單位),以及檔案內容的 Base64 編碼 MD5 雜湊。有時來源網站會提供檔案大小和雜湊值。如果不是,您需要本機存取檔案,在這種情況下,使用 gcloud storage 指令可能比較容易,如先前所述。

如果您已進行移轉,Storage 移轉服務是取得及保留資料的絕佳方式,特別是從其他公有雲移轉資料時。

如要從 Storage 移轉服務不支援的其他雲端服務移轉資料,可以使用雲端代管虛擬機器執行個體的 gcloud storage 指令。

安全性

對許多 Google Cloud 使用者而言,安全性是主要考量,因此我們提供不同等級的安全性。請考慮以下幾個安全層面:保護靜態資料 (授權及存取來源和目的地儲存系統)、保護傳輸中的資料,以及保護轉移產品的存取權。下表列出各產品的安全性層面。

產品 靜態資料 傳輸中的資料 轉移產品的存取權
Transfer Appliance 所有靜態資料都會經過加密。 資料會受到客戶管理的金鑰保護。 任何人都可以訂購裝置,但必須有資料來源的存取權才能使用。
gcloud storage 指令 存取 Cloud Storage 時需要存取金鑰,該服務會加密靜態資料。 資料會透過 HTTPS 傳送,並在傳輸過程中加密。 任何人都可以下載及執行 Google Cloud CLI。他們必須擁有 Bucket 和本機檔案的權限,才能移動資料。
Transfer Service for On Premises Data 存取 Cloud Storage 時需要存取金鑰,該金鑰會以靜態加密方式儲存。代理程式程序可存取本機檔案,但須符合作業系統權限規定。 資料會透過 HTTPS 傳送,並在傳輸過程中加密。 您必須具備物件編輯者權限,才能存取 Cloud Storage 值區。
Storage 移轉服務 非Google Cloud 資源 (例如 Amazon S3) 需要存取金鑰。存取 Cloud Storage 時需要存取金鑰,而 Cloud Storage 會進行靜態加密。 資料會透過 HTTPS 傳送,並在傳輸過程中加密。 您必須具備服務帳戶的 IAM 權限,才能存取任何 Cloud Storage bucket 的來源和物件編輯器權限。

為達到基本安全強化效果,使用 gcloud storage 指令線上移轉至Google Cloud 的資料會透過 HTTPS 傳輸,且傳輸中的資料會經過加密,而 Cloud Storage 中的所有資料預設都會經過靜態加密。如果您使用Transfer Appliance,您控管的安全金鑰可協助保護資料。一般來說,我們建議您與安全團隊合作,確保移轉計畫符合貴公司和法規要求。

第三方轉移產品

如果是進階網路層級最佳化或進行中的資料移轉工作流程,您可能會想要使用更進階的工具。如要進一步瞭解更進階的工具,請參閱Google Cloud 合作夥伴

步驟 4:評估資料遷移方法

遷移資料時,一般而言可以採取以下步驟:

  1. 將資料從舊網站遷移到新網站。
  2. 解決當中出現的任何資料整合問題,例如同步處理多個來源的相同資料。
  3. 驗證資料遷移。
  4. 將新網站推送為主要副本。
  5. 當您不再需要舊網站做為備用選項時,就淘汰它。

您應該根據下列問題建立資料遷移方法:

  • 有多少資料需要遷移?
  • 這些資料多久要變更一次?
  • 您是否能承受遷移資料時的轉換空窗期停機時間?
  • 您目前的資料一致性模型為何?

沒有最好的方法,請選擇適合您的環境與要求的方法。

以下各節將介紹四個資料遷移方法:

  • 定期維護
  • 持續複製
  • Y (寫入及讀取)
  • 資料存取微服務

視資料遷移的規模和要求而定,每個方法分別可以解決不同的問題。

資料存取微服務方法是最適合微服務架構的方法,但其他方法也很適合用來進行資料遷移。在進行基礎架構現代化,轉換成使用資料存取微服務方法的這段過渡期間,這些方法也都能發揮各自的功用。

下圖概要比較每個方法的轉換空窗期長短、重構工作量和靈活性。

長條圖,圖中的每個長條分別顯示這四種方法的相對靈活度、重構工作量和轉換空窗期長短。

在採用任何方法之前,請確認您已在新環境中完成必要的基礎架構設定。

定期維護

如果您的工作負載能夠承受轉換空窗期,那麼定期維護法 (也稱為一次性遷移或大爆炸遷移) 會是理想的選擇。(定期的意義在於您可以規劃轉換空窗期的發生時間)。

此方法的遷移作業包括以下步驟:

  1. 將舊網站中的資料複製到新網站。這個初步複製工作可縮短轉換空窗期;完成初步複製工作後,您之後就只需要複製在這段空窗期變更的資料。
  2. 執行資料驗證和一致性檢查,比對舊網站中的資料和新網站中的複製資料。
  3. 停止對複製資料有寫入權限的工作負載及服務,確保資料不會發生任何進一步的變更。
  4. 同步處理在初步複製工作後發生的資料變更。
  5. 重構工作負載及服務,使其使用新網站。
  6. 啟動工作負載及服務。
  7. 當您不再需要舊網站做為備用選項時,就淘汰它。

定期維護法將大部分的負擔放在營運端,因為所需的重構工作負載及服務最少。

持續複製

由於並非所有工作負載都能承受長時間的轉換空窗期,您可以在完成初步複製及驗證步驟後,利用持續複製機制來建立定期維護方法。在設計這樣的機制時,您還應該考慮資料變更的速率;要使兩個系統保持同步可能是件相當具有挑戰性的事情。

持續複製法 (也稱為線上遷移或涓滴遷移) 比定期維護法更為複雜。但持續複製法具有能縮短轉換空窗期的優點,因為它能大幅減少您需要同步處理的資料。持續複製遷移作業的步驟如下:

  1. 將舊網站中的資料複製到新網站。這個初步複製工作可縮短轉換空窗期;完成初步複製工作後,您之後就只需要複製在這段空窗期變更的資料。
  2. 執行資料驗證和一致性檢查,比對舊網站中的資料和新網站中的複製資料。
  3. 設定從舊網站到新網站的持續複製機制。
  4. 停止對要遷移的資料有存取權限的工作負載及服務 (亦即,前一個步驟所牽涉的資料)。
  5. 重構工作負載及服務,使其使用新網站。
  6. 等候複製,以將新網站與舊網站完整同步。
  7. 啟動工作負載及服務。
  8. 當您不再需要舊網站做為備用選項時,就淘汰它。

和定期維護法一樣,持續複製法也將大部分的負擔放在營運端。

Y (寫入及讀取)

如果您的工作負載有嚴格的高可用性要求,而且不能承受轉換空窗期的停機時間,那麼就必須採取不同的方法。針對這種情況,您可以使用本文中稱為「Y (寫入及讀取)」平行遷移方法。使用這種方法時,工作負載在遷移期間會同時在舊網站和新網站執行讀取和寫入資料的作業 (字母「Y」代表遷移期間資料流動方式的圖示)。

此方法的步驟摘述如下:

  1. 重構工作負載及服務,使其將資料寫入舊網站和新網站,並且從舊網站讀取資料。
  2. 識別在您啟用新網站的寫入功能前已寫入的資料,並將其從舊網站複製到新網站。連同前述的重構工作,這將能確保資料庫的一致性。
  3. 執行資料驗證和一致性檢查,比對舊網站和新網站的資料。
  4. 將讀取作業從舊網站切換到新網站。
  5. 再執行一次資料驗證和一致性檢查,比對舊網站和新網站的資料。
  6. 停用舊網站的寫入功能。
  7. 當您不再需要舊網站做為備用選項時,就淘汰它。

和定期維護法及持續複製法不同,Y (讀取及寫入) 方法將大部分的工作負擔放在開發端,而不是營運端,因為它需要進行多次的重構工作。

資料存取微服務

如果您想要減少 Y (寫入及讀取) 方法的重構工作量,您可以透過將工作負載及服務重構為使用資料存取微服務,來集中處理資料的讀取及寫入作業。這個可擴充的微服務將成為資料儲存層的唯一進入點,其作用如同該儲存層的 Proxy。在本文討論的所有方法中,此方法能為您提供最大的靈活度,因為可以在不影響架構中其他元件且不需要轉換空窗期的情況下重構這個元件。

資料存取微服務與 Y (寫入及讀取) 方法在做法上非常相似,差別在於前者的重構工作只集中在資料存取微服務上,不需要像後者一樣重構所有存取資料儲存層的工作負載及服務。此方法的步驟摘述如下:

  1. 重構資料存取微服務,使其將資料寫入舊網站和新網站,並且從舊網站讀取資料。
  2. 識別在您啟用新網站的寫入功能前已寫入的資料,並將其從舊網站複製到新網站。連同前述的重構工作,這將能確保資料庫的一致性。
  3. 執行資料驗證和一致性檢查,比對舊網站和新網站的資料。
  4. 重構資料存取微服務,使其從新網站讀取資料。
  5. 再執行一次資料驗證和一致性檢查,比對舊網站和新網站的資料。
  6. 重構資料存取微服務,使其只將資料寫入新網站。
  7. 當您不再需要舊網站做為備用選項時,就淘汰它。

和 Y (寫入及讀取) 方法一樣,資料存取微服務法也將大部分的負擔放在開發端,但其工作負擔明顯小於 Y (寫入及讀取) 方法,因為重構工作只集中在資料存取微服務上。

步驟 5:準備轉移

如果是大型移轉或有重大依附元件的移轉,請務必瞭解如何操作移轉產品。顧客通常會完成下列步驟:

  1. 價格和投資報酬率估算。這個步驟提供許多選項,可協助您做出決策。
  2. 功能測試。在這個步驟中,請確認產品可以順利設定,且網路連線 (如適用) 正常運作。您也可以測試是否能將代表性資料樣本 (包括隨附的非轉移步驟,例如移動 VM 執行個體) 移至目的地。

    通常,您可以在分配所有資源 (例如轉移機器或頻寬) 之前執行這個步驟。這個步驟的目標包括:

    • 確認你可以安裝及操作轉移程序。
    • 找出可能導致專案停止的問題,例如阻礙資料移動的網路路徑,或是阻礙作業的因素 (例如非轉移步驟需要訓練)。
  3. 效能測試。在這個步驟中,您會分配生產資源,對大量資料樣本 (通常為 3% 至 5%) 執行移轉作業,以進行下列操作:

    • 確認您可以耗用所有已分配的資源,並達到預期速度。
    • 找出並修正瓶頸 (例如來源儲存系統速度緩慢)。

步驟 6:確保轉移作業完整無缺

為確保資料在轉移期間的完整性,建議採取下列防護措施:

  • 在目的地啟用版本管理和備份功能,以減少意外刪除造成的損害。
  • 請先驗證資料,再移除來源資料。

如果資料傳輸規模龐大 (PB 級資料和數十億個檔案),即使基礎來源儲存系統的基準延遲錯誤率低至 0.0001%,仍會導致數千個檔案和 GB 級資料遺失。通常在來源執行的應用程式已可容許這些錯誤,因此不需要額外驗證。在某些特殊情況下 (例如長期封存),必須經過更多驗證,才能視為可安全地從來源刪除資料。

視應用程式需求而定,我們建議您在移轉完成後執行一些資料完整性測試,確保應用程式能繼續正常運作。許多轉移產品都內建資料完整性檢查功能。不過,視風險狀況而定,您可能需要在從來源刪除資料前,對資料和讀取資料的應用程式進行額外檢查。舉例來說,您可能想確認自行記錄及計算的檢查碼是否與寫入目的地的資料相符,或是確認應用程式使用的資料集是否已順利轉移。

後續步驟

貢獻者

作者: