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

Last reviewed 2024-11-13 UTC

對許多客戶而言，採用 Google Cloud產品的第一步，就是將資料導入 Google Cloud。本文件將說明這項程序，包括規劃資料移轉作業，以及實施計畫時的最佳做法。

轉移大型資料集時，您必須建立適當的團隊、及早規劃，並在正式環境中實作前測試轉移計畫。雖然這些步驟可能會花費與轉移作業本身相同的時間，但這類準備工作有助於在轉移期間盡量減少對業務運作的影響。

本文是下列多部分系列文章的一部分，這些文章說明如何遷移至Google Cloud：

什麼是資料轉移？

在本文件中，資料轉移是指不經過轉換程序就移動資料的過程，例如將檔案原封不動地移至物件。

資料移轉並非想像中簡單

您可能會將資料傳輸視為一個大型 FTP 工作階段，將檔案放入一端，等待檔案從另一端傳出。不過，在大多數企業環境中，轉移程序會涉及許多因素，例如：

  • 擬定移轉計畫時，請考量行政作業所需的時間，包括決定移轉選項、取得核准，以及處理意外問題所需的時間。
  • 協調貴機構中的人員，例如執行轉移作業的團隊、核准工具和架構的人員，以及關心遷移資料可能帶來的價值和中斷情形的業務利益相關者。
  • 根據資源、成本、時間和其他專案考量因素，選擇合適的轉移工具。
  • 克服資料傳輸的挑戰，包括「光速」問題 (頻寬不足)、移動正在使用的資料集、在傳輸期間保護及監控資料，以及確保資料順利傳輸。

本文件旨在協助您順利展開轉移計畫。

下列清單包含本文件未涵蓋的其他類型資料移轉專案資源：

步驟 1：組成團隊

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

  • 啟用轉移作業所需的資源：儲存空間、IT 和網路管理員、高階主管贊助人和其他顧問 (例如 Google 帳戶團隊或整合合作夥伴)
  • 核准移轉決定：資料擁有者或管理者 (針對可將哪些資料移轉給誰的內部政策)、法律顧問 (針對資料相關法規) 和安全性管理員 (針對資料存取權保護方式的內部政策)
  • 執行轉移作業：團隊主管、專案經理 (執行及追蹤專案)、工程團隊，以及現場收貨和出貨 (收取家電硬體)

請務必找出負責轉移專案前置作業的人員，並視需要將他們納入規劃和決策會議。組織規劃不良經常是轉移計畫失敗的原因。

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

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

設計轉移計畫時，建議您先收集資料轉移的相關需求，再決定轉移選項。如要收集需求，您可以使用下列程序：

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

在規劃的下一階段評估及選取轉移選項之前，建議您先評估 IT 模型的任何部分 (例如資料治理、組織和安全性) 是否可改善。

您的安全性模型

在資料移轉專案中，許多移轉團隊成員可能會在 Google Cloud 機構中獲得新的角色。規劃資料移轉作業時，請務必檢查 Identity and Access Management (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 頻寬足以符合專案期限 Storage Transfer Service for On Premises Data
您的私人資料中心到 Google Cloud 頻寬不足，無法在專案期限內完成 Transfer Appliance

gcloud storage 指令：用於傳輸較少的 On-Premises 資料

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

gcloud storage 指令特別適合用於下列情況：

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

使用 Storage 移轉服務大量轉移內部部署資料

與 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 主控台 中提供來源目錄、目的地儲存空間桶，以及時間或時間表，以啟動移轉作業。Storage 移轉服務會遞迴地檢索來源目錄中的子目錄和檔案，並在 Cloud Storage 中建立具有對應名稱的物件 (物件 /dir/foo/file.txt 會成為名為 /dir/foo/file.txt 的目標值區中的物件)。Storage 移轉服務在遇到任何暫時性錯誤時，會自動重新嘗試轉移。傳輸作業執行期間，您可以監控移動的檔案數量和整體傳輸速度，並查看錯誤樣本。

Storage 移轉服務完成轉移作業後，會產生以分隔符分隔的檔案 (TSV)，其中包含所有受影響檔案的完整記錄，以及收到的任何錯誤訊息。代理程式具有容錯功能，因此如果某個代理程式發生故障，轉移作業會繼續使用其他代理程式。代理程式也會自動更新和修復，因此您不必擔心要為最新版本進行修補，也不必擔心在發生意外問題導致程序停止運作時，要重新啟動程序。

使用 Storage 移轉服務時，請考量下列事項：

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

使用 Transfer Appliance 處理大量資料移轉作業

對於大規模的轉移作業 (尤其是網路頻寬有限的轉移作業)，轉移工具 是絕佳的選擇，尤其是當無法取得快速的網路連線，且取得更多頻寬的成本過高時。

轉移裝置特別適合用於下列情況：

  • 資料中心位於偏遠地區，頻寬有限或無法存取。
  • 頻寬可用，但無法及時取得，無法符合您的期限。
  • 你有物流資源，可接收並將裝置連線至網路。

使用這個選項時，請考慮下列事項：

  • 轉移工具包要求你能夠收到並寄回 Google 自有硬體。
  • 視網路連線狀況而定，使用 Transfer Appliance 將資料傳輸至 Google Cloud 的延遲時間通常會比線上傳輸時間長。
  • 轉移工具僅適用於特定國家/地區。

使用 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。他們必須擁有資料夾和本機檔案的權限，才能移動資料。
Storage Transfer Service for On Premises Data 存取金鑰是存取 Cloud Storage 的必要條件，且會在靜態時加密。代理程式處理程序可根據作業系統權限存取本機檔案。 資料會透過 HTTPS 傳送，並在傳輸過程中加密。 您必須具備物件編輯器權限，才能存取 Cloud Storage 值區。
Storage 移轉服務 非Google Cloud 資源 (例如 Amazon S3) 需要的存取金鑰。您必須使用存取金鑰才能存取 Cloud Storage，該服務會在靜態時加密。 資料會透過 HTTPS 傳送，並在傳輸過程中加密。 您必須具備服務帳戶的 IAM 權限，才能存取任何 Cloud Storage 值區的來源和物件編輯器權限。

為了提升基本安全性，使用 gcloud storage 指令透過 HTTPS 完成至Google Cloud 的線上傳輸作業，在傳輸過程中加密資料，並預設將 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 級資料遺失。通常，在來源端執行的應用程式已能容許這些錯誤，因此不需要額外驗證。在某些特殊情況下 (例如長期封存)，您必須進行更多驗證，才能安全地從來源刪除資料。

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

後續步驟

貢獻者

作者：