迁移到 Google Cloud:转移大型数据集

对于许多客户来说,采用 Google Cloud 产品的第一步是将数据导入 Google Cloud。本文档详细介绍了从规划数据转移到使用最佳做法的完整流程。

转移大型数据集的过程包括构建合适的团队、尽早规划、测试转移计划,然后在生产环境中实施。尽管这些步骤所需的时间可能与转移本身同样多,但此类准备工作有助于最大限度地减少转移过程对业务运营造成的影响。

本文档是关于迁移到 Google Cloud 的系列文章中的一篇。如果您想要了解该系列文章,请参阅迁移到 Google Cloud:选择迁移路径

本文是以下系列文章中的一篇:

下图说明了迁移过程的路径。

迁移路径包含四个阶段。

部署阶段是向 Google Cloud 迁移的第三个阶段,在此阶段中,您将为工作负载设计一个部署流程。

如果您计划从本地环境、私有托管环境或其他云提供商迁移到 Google Cloud,或者您要评估迁移机会并希望了解其具体操作,那么本文档非常有用。

什么是数据转移?

在本文档中,数据转移是指在不转换数据的情况下移动数据的过程,例如将文件按原样移动到目标位置。

数据转移不像听起来那么简单

人们很容易将数据转移视为一个巨大的 FTP 会话,您可以将文件放在一端,然后等待文件传输到另一端。但是,在大多数企业环境中,转移过程涉及许多因素,例如:

  • 制定一个涵盖管理时间的转移计划,包括确定转移方案、获得批准以及处理意外问题的时间。
  • 协调您组织中的人员,例如负责转移的团队、批准工具和架构的人员,以及关注移动数据可能带来的价值和中断的业务利益相关方。
  • 根据您的资源、费用、时间和其他项目考虑因素选择合适的转移工具。
  • 应对数据转移挑战,包括“光速”问题(带宽不足)、移动正在使用的数据集、在转移过程中保护和监控数据,以及确保数据转移成功。

本文档旨在帮助您顺利开始转移计划。

以下列表包含本文档未涵盖的其他类型的数据转移项目的资源:

  • 如果您需要转换数据(例如合并行、联接数据集或过滤个人身份信息),则应考虑使用提取、转换和加载 (ETL) 解决方案,将数据存入 Google Cloud 数据仓库。如需查看此架构的示例,请参阅 Dataflow 教程
  • 如果您需要迁移数据库和相关应用(例如直接原样迁移数据库应用),可以查看 Cloud Spanner 文档、PostgreSQLMySQL 解决方案以及有关您的数据库类型的其他文档。
  • 如果您想将数据从 HBase 迁移到与 HBase API 兼容的全代管式 NoSQL 数据库服务,并可以处理更大的工作负载,请参阅 Cloud Bigtable
  • 如果您需要移动虚拟机 (VM) 实例,请考虑使用 Google 的虚拟机迁移产品 Migrate for Compute Engine

第 1 步:组建团队

规划转移通常需要具有以下角色和责任的人员:

  • 启用转移所需的资源:存储空间、IT 和网络管理员;高级管理人员以及其他顾问(例如 Google 帐号团队或集成合作伙伴)
  • 批准转移决定:数据所有者或调控者(制定允许谁转移哪些数据的内部政策)、法律顾问(制定数据相关法规)和安全管理员(制定保护数据访问权限的内部政策)
  • 执行转移:团队负责人、项目经理(负责执行和跟踪项目)、工程团队以及现场接收和送货人员(负责接收设备硬件)

请务必确定您的转移项目的上述责任人,并在适当的时候将其纳入计划和决策会议中。糟糕的组织计划通常是导致转移失败的原因。

收集项目要求和利益相关方的意见并非易事,但制定计划并明确角色和责任能够带来好的结果。不要指望了解数据的所有详细信息。组建团队有助于您更深入地了解业务需求。最佳做法是在投入时间、资金和资源完成转移之前找出潜在问题。

第 2 步:收集要求和可用资源

在设计转移计划时,建议您先收集有关数据转移的要求,然后再决定转移方案。如需收集要求,您可以使用以下流程:

  1. 确定您需要移动的数据集。
    • 选择 Data Catalog 等工具,将数据整理成可以一起移动和使用的逻辑分组。
    • 与组织内的团队成员合作,验证或更新这些分组。
  2. 确定您可以移动的数据集。
    • 考虑是否有一些数据集出于监管、安全或其他原因无法转移。
    • 如果您需要在迁移某些数据之前对其进行转换(例如移除敏感数据或重新组织数据),请考虑使用 DataflowCloud Data Fusion 等数据集成产品或 Cloud Composer 等工作流编排产品。
  3. 对于可移动的数据集,请确定要将每个数据集转移到何处。
    • 记录您选择的存储方案以存储您的数据。通常,Google Cloud 上的目标存储系统是 Cloud Storage。 即使您在应用启动并运行后需要采用更复杂的解决方案,Cloud Storage 也是一个可扩缩且耐用的存储方案。如需了解详情,请参阅 Cloud Storage 最佳做法
    • 了解迁移后必须保留哪些数据访问政策。
    • 确定是否需要在特定地区中存储此数据。
    • 规划如何在目标位置构建此数据。例如,其结构与源数据结构相同还是不同?
    • 确定是否需要持续转移数据。
  4. 对于可移动的数据集,确定可用于迁移这些数据集的资源。
    • 时间:何时需要完成转移?
    • 费用:团队的可用预算和转移费用是多少?
    • 人员:谁可以执行转移?
    • 带宽(用于在线转移):您目前的 Google Cloud 可用带宽中有多少可以分配给转移,可以使用多长时间?

在评估和选择下一阶段计划采用的转移方案之前,建议您评估是否可以改进 IT 模型的任何部分,例如数据治理、组织和安全性。

您的安全模型

作为数据转移项目的一部分,许多转移团队的成员可能会被授予您的 Google Cloud 组织中的新角色。您可以制定数据转移计划以审核 Identity and Access Management (IAM) 权限和安全使用 IAM 的最佳做法。这些问题会影响您如何授予对存储空间的访问权限。例如,您可能对由于监管原因而归档的数据设置了严格的写入权限,但您可能允许许多用户和应用将数据写入测试环境。

您的 Google Cloud 组织

如何在 Google Cloud 上构建数据取决于您计划如何使用 Google Cloud。将数据存储在运行应用的同一 Cloud 项目中是一种简单的方法,但从管理的角度来看,这可能不是最佳做法。一些开发者可能无权查看生产数据。在这种情况下,开发者可以在示例数据上开发代码,而特权服务帐号可以访问生产数据。因此,您可能希望将整个生产数据集存储在单独的 Cloud 项目中,然后使用服务帐号来允许访问每个应用项目中的数据。

Google Cloud 围绕项目进行组织。项目可以划分到文件夹中,文件夹可以划分到您的组织下。角色在项目级创建,访问权限在 Cloud Storage 存储分区级添加到这些角色。此结构与其他对象存储提供商的权限结构一致。

如需详细了解如何构建 Google Cloud 组织,请参阅企业组织最佳做法

第 3 步:评估您的转移方案

如需评估您的数据转移方案,转移团队需要考虑以下几个因素:

  • 费用
  • 时间
  • 离线与在线转移方案的对比
  • 转移工具和技术
  • 安全性

费用

大部分与转移数据相关的费用包括:

  • 网络费用
    • 到 Cloud Storage 的入站流量是免费的。但是,如果您在公有云服务商处托管数据,则可能需要为转移数据支付出站流量费用和潜在的存储费用(例如读取操作)。此费用适用于来自 Google 或其他云服务商的数据。
    • 如果您的数据托管在您运营的私有数据中心,那么您可能还需要支付额外的费用以设置到 Google Cloud 的更多带宽。
  • 数据转移期间和之后的 Cloud Storage 存储和操作费用
  • 产品费用(例如 Transfer Appliance)
  • 组建团队并获得后勤支持的人员费用

时间

在计算方面,几乎没有什么能突出网络在转移大量数据时的硬件限制。理想情况下,您可以通过 1 Gbps 网络在 8 秒内转移 1 GB 数据。如果将其扩展为大型数据集(例如 100 TB),则转移时间为 12 天。转移大型数据集可以测试您的基础架构的限制,也可能会给您的业务带来问题。

根据要移动的数据集的大小以及转移可用的带宽,您可以使用以下计算器来了解转移可能需要的时间。一定比例的管理时间会纳入计算过程。 此外还包括有效带宽效率,使生成的数字更为实际,而不会获取理想数字。

您可能不希望在高峰工作时间将大型数据集转出公司网络。如果转移作业导致网络超载,则其他人将无法完成必要任务或关键任务。因此,转移团队需要考虑时间因素。

将数据转移到 Cloud Storage 后,您可以使用多种工具(例如 Dataflow)在新文件传入时对其进行处理。

增加网络带宽

如何增加网络带宽取决于您连接到 Google Cloud 的方式。

在 Google Cloud 与其他云服务商之间进行云间转移时,Google 会在云服务商数据中心之间预配连接,您无需进行任何设置。

如果您要在私有数据中心和 Google Cloud 之间转移数据,可以采用以下三种方法:

  • 通过公共 API 使用公共互联网连接
  • 通过公共 API 使用直接对等互连
  • 通过私有 API 使用 Cloud Interconnect

在评估这些方法时,考虑您的长期连接需求会很有帮助。您可能会得出这样的结论:仅出于转移目的获取带宽的费用过高,但如果将 Google Cloud 的长期使用以及整个组织的网络需求考虑在内,这笔投资可能物有所值。

使用公共互联网进行连接

使用公共互联网连接时,网络吞吐量的可预测性较差,因为您受互联网服务提供商 (ISP) 容量和路由的限制。ISP 可能会提供受限的服务等级协议 (SLA),或者根本不提供服务等级协议。但是,这些连接的费用相对较低,且借助 Google 的扩展对等互连方案,您的 ISP 可以在几个网络跃点内将您路由到 Google 的全球网络。

建议您联系您的安全管理员,了解您的公司政策是否禁止通过公共互联网移动某些数据集,同时了解公共互联网连接是否可用于生产流量。 大规模数据转移可能会对生产网络产生负面影响。

使用直接对等互连进行连接

如需在少于公共互联网连接的网络跃点数以内访问 Google 网络,您可以使用直接对等互连。通过使用直接对等互连,您可以在您的网络和 Google 的边缘接入点 (PoP) 之间交换互联网流量,这意味着您的数据不使用公共互联网。这样做还可以减少您的网络与 Google 网络之间的跃点数。 与 Google 的网络进行对等互连要求您设置一个经过注册的自治系统 (AS) 编号,使用互联网交换连接到 Google,并提供与您的网络运营中心的全天候联系。

使用 Cloud Interconnect 进行连接

Cloud Interconnect 通过 Google 或其中一个 Cloud Interconnect 服务提供商提供与 Google Cloud 的直接连接。此服务有助于避免数据通过公共互联网传输,并可为大型数据转移提供更一致的吞吐量。通常,Cloud Interconnect 会提供服务等级协议 (SLA) 以实现网络可用性和网络性能。 如需了解详情,请直接联系服务提供商。Cloud Interconnect 还支持私有地址 RFC 1918,因此云将成为私有数据中心的扩展,而无需公共 IP 地址或 NAT。

在线与离线转移的对比

使用离线还是在线数据转移是关键决策。也就是说,您必须选择通过网络(无论是专用互连还是公共互联网)进行转移,或者使用存储硬件进行转移。

为帮助您做出这一决策,我们提供了转移计算器来帮助您估算这两种方案的时间和费用差异。 下图还显示了各种数据集大小和带宽对应的转移速度。这些计算结果会涵盖一定的管理开销。

展示转移大小与转移速度之间关系的图表。

如前所述,您可能需要考虑实现低延迟数据转移(如获取网络带宽)所需的费用是否与贵组织的投资价值相抵。

Google 提供的方案

Google 提供了多种工具和技术来帮助您进行数据转移。

在 Google 提供的转移方案中选择

具体选择哪种转移方案取决于您的用例,如下表所示。

从何处迁移数据 场景 推荐的产品
从另一个云提供商(例如 Amazon Web Services 或 Microsoft Azure)迁移到 Google Cloud Storage Transfer Service
从 Cloud Storage 迁移到 Cloud Storage(两个不同的存储分区) Storage Transfer Service
从您的私有数据中心迁移到 Google Cloud 有足够的带宽,可在项目截止日期前完成转移
数据量小于 1 TB
gsutil
从您的私有数据中心迁移到 Google Cloud 有足够的带宽,可在项目截止日期前完成转移
数据量大于 1 TB
Storage Transfer Service for On Premises Data
从您的私有数据中心迁移到 Google Cloud 带宽不足,无法在项目截止日期前完成转移 Transfer Appliance

gsutil(用于小规模本地数据转移)

gsutil 工具是一款通过典型的企业级网络(从私有数据中心到 Google Cloud)进行中小规模转移(数据量小于 1 TB)的标准工具。我们建议您在使用 Cloud Shell 时将 gsutil 添加到默认路径中。 当您安装 Cloud SDK 时,默认也可以使用它。 这是一款可靠的工具,可提供管理 Cloud Storage 实例所需的所有基本功能,包括从本地文件系统和 Cloud Storage 复制数据及将数据复制到本地文件系统和 Cloud Storage。它还支持移动和重命名对象,以及执行到 Cloud Storage 存储分区的实时增量同步(如 rsync)。

gsutil 尤其适用于以下情况:

  • 转移作业需要按需执行,或者由您的用户在命令行会话期间执行。
  • 仅转移几个文件或非常大的文件。
  • 使用程序输出(将输出流式传输到 Cloud Storage)。
  • 需要监控文件数量适中的目录,并以非常低的延迟时间同步所有更新。

如需开始使用 gsutil,您需要创建一个 Cloud Storage 存储分区将数据复制到该存储分区。对于较大数据集的转移,需要考虑以下两个方面:

  • 对于多线程转移,请使用 gsutil -m

    系统会并行处理多个文件,从而提高转移速度。

  • 对于单个大文件,请使用复合转移

    此方法会将较大的文件拆分为多个较小的数据块,以提高转移速度。系统会并行转移和验证数据块,并将所有数据发送到 Google。当这些数据块到达 Google 后,它们会合并(称为“合成”)以形成单个对象。合成可能会导致 Cloud Storage Coldline 和 Cloud Storage Nearline 中存储的对象需支付提前删除费用,因此不建议用于这些类型的对象。

    此功能有一些缺点,例如每个数据块(而不是整个对象)需要单独进行校验,而冷存储类别的合成会导致提前检索处罚。

Transfer Service for On Premises Data(用于大规模本地数据转移)

gsutil 一样,Transfer Service for On Premises Data 支持从网络文件系统 (NFS) 存储空间到 Cloud Storage 的转移。虽然 gsutil 可以支持较小的转移量(最多 1 TB),但 Transfer Service for On Premises Data 专为大规模转移(PB 级数据,数十亿个文件)而设计。它支持完整副本或增量副本,并且适用于上文在 Google 提供的转移方案中选择部分列出的所有转移方案。它还具有一个简单的代管式图形界面;即使是不了解相关技术的用户(设置完成后)也可以使用它来移动数据。

Transfer Service for On Premises Data 尤其适用于以下情况:

  • 有足够的带宽可用于移动数据(请参阅 Google Cloud 数据转移计算器)。
  • 需要为大量难以使用 gsutil 等命令行工具的内部用户提供支持。
  • 需要可靠的错误报告,并且需要记录所有移动的文件和对象。
  • 需要限制转移对数据中心内其他工作负载的影响(此产品可能会受到用户指定的带宽限制)。
  • 希望按时间表运行定期转移作业。

您可以在数据中心的计算机上安装本地软件(称为“代理”)来设置 Transfer Service for On Premises Data。这些代理位于 Docker 容器中,可让您更轻松地运行许多代理或通过 Kubernetes 对其进行编排。

设置完成后,用户可以提供来源目录、目标存储分区以及时间或时间表在 Google Cloud Console 中启动转移作业。 Storage Transfer Service 周期性抓取来源目录中的子目录和文件,并在 Cloud Storage 中创建具有相应名称的对象(对象 /dir/foo/file.txt 会成为目标存储分区中名为 /dir/foo/file.txt 的对象)。Storage Transfer Service 会在遇到任何暂时性错误时自动重新尝试转移。 在转移作业运行期间,您可以监控转移的文件数量和整体转移速度,还可以查看错误样本。

转移完成后,系统会生成一个制表符分隔文件 (TSV),其中包含所有转移文件的完整记录以及收到的所有错误消息。代理具有容错能力,因此如果代理发生故障,转移作业将继续通过其余代理运行。代理还可以自行更新和自修复,因此您不必担心如何为最新版本打补丁或因意外问题发生故障继而导致重启进程。

使用 Storage Transfer Service 时的注意事项:

  • 在每台机器上使用完全相同的代理设置。所有代理都应以相同的方式(相同的相对路径)完成相同的网络文件系统 (NFS) 装载。此项设置是产品正常运行的必要条件。
  • 代理越多,速度越快。由于转移会自动在所有代理之间并行运行,因此我们建议您部署多个代理以使用可用带宽。
  • 带宽限制可以保护您的工作负载。您的其他工作负载可能正在使用数据中心带宽,因此请设置带宽限制,以防止转移作业影响您的服务等级协议 (SLA)。
  • 安排时间检查错误。大规模转移通常会产生需要检查的错误。借助 Storage Transfer Service,您可以直接在 Cloud Console 中查看遇到的错误样本。如果需要,您可以将所有转移错误的完整记录加载到 BigQuery,以检查文件或评估重试后仍然存在的错误。这些错误可能是由于在转移过程中运行正在向来源写入数据的应用造成的,或者这些错误可能会引发需要排查的问题(例如权限错误)。
  • 为长时间运行的转移作业设置 Cloud Monitoring。Storage Transfer Service 允许 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 的过程非常简单。您可以在 Cloud Console 中申请使用 Transfer Appliance,指定数据量,然后 Google 会将一台或多台设备寄送到您申请的地点。您有几天的时间将数据转移到此设备(“数据捕获”),然后将其寄送回 Google。

一台网络设备完成寄送、加载数据、运回、将数据上传到 Google Cloud 的预期周转时间为 20 天。如果您计算出的在线转移时间明显比这个时间长,请考虑使用 Transfer Appliance。300 TB 设备的总费用不到 $2,500。

Storage Transfer Service(适用于云间转移)

Storage Transfer Service 是一项扩容能力极强的全代管式服务,可自动完成从其他公有云到 Cloud Storage 的数据转移。它支持将数据从 Amazon S3 和 HTTP 转移到 Cloud Storage。

对于 Amazon S3,您可以提供访问密钥和 S3 存储分区,其中包含可选的 S3 对象过滤器,然后将 S3 对象复制到任意 Cloud Storage 存储分区。该服务还支持任意修改对象的每日副本。该服务目前不支持将数据转移到 Amazon S3。

对于 HTTP,您可以按特定格式为 Storage Transfer Service 提供一个公共网址列表。此方法要求您编写一个脚本,提供每个文件的大小(以字节为单位)以及文件内容的 Base64 编码 MD5 哈希。有时,文件大小和哈希可通过来源网站获取。如果无法获取,您需要对这些文件进行本地访问,在这种情况下,使用 gsutil 可能更容易(如前所述)。

如果您已完成转移,则 Storage Transfer Service 是获取和保留数据的好方法,尤其是从其他公有云转移数据时。

安全性

对于许多 Google Cloud 用户来说,安全性是其首要关注点,而安全有许多不同的级别。需要考虑的安全措施包括如何保护静态数据(对来源和目标存储系统的授权和访问)、如何保护传输中的数据以及如何保护对转移产品的访问权限。下表按产品介绍了这些安全措施。

产品 存储中的数据(静态数据) 传输中的数据 对转移产品的访问权限
Transfer Appliance 所有静态数据均经过加密。 数据由客户管理的密钥保护。 任何人都可以订购设备,但要使用该设备,用户需要具有对数据源的访问权限。
gsutil 访问 Cloud Storage 需要访问密钥,该密钥采用静态加密。 数据通过 HTTPS 发送并在传输过程中加密。 任何人都可以下载并运行 gsutil。他们必须有权访问存储分区和本地文件以移动数据。
Storage Transfer Service for On Premises Data 访问 Cloud Storage 需要访问密钥,该密钥采用静态加密。代理进程可以在操作系统权限允许的情况下访问本地文件。 数据通过 HTTPS 发送并在传输过程中加密。 您必须具有对象修改者权限才能访问 Cloud Storage 存储分区。
Storage Transfer Service 非 Google Cloud 资源(例如 Amazon S3)需要访问密钥。访问 Cloud Storage 需要访问密钥,该密钥采用静态加密。 数据通过 HTTPS 发送并在传输过程中加密。 您必须拥有服务帐号的 IAM 权限才能访问来源,必须拥有对象编辑者权限才能访问 Cloud Storage 存储分区。

为增强基本安全性,使用 gsutil 向 Google Cloud 进行在线转移通过 HTTPS 来完成,传输中的数据会进行加密,默认情况下,Cloud Storage 中的数据一律采用静态加密。如需详细了解更复杂的安全相关方案,请参阅安全与隐私权注意事项。 如果您使用 Transfer Appliance,则由您控制的安全密钥有助于保护您的数据。通常情况下,我们建议您联系您的安全团队,以确保您的转移方案符合您的公司和监管要求。

第三方转移产品

为实现高级网络级优化或持续数据转移工作流,您可能希望使用更高级的工具。如需了解更高级的工具,请访问 Google 合作伙伴

以下链接突出显示了部分选项(此处按字母顺序排列):

第 4 步:准备转移

对于大规模转移或具有重要依赖关系的转移,请务必了解如何操作转移产品。客户通常需要完成以下步骤:

  1. 价格和投资回报率估算。此步骤提供了许多选项来帮助您做出决策。
  2. 功能测试。在此步骤中,您需要确认产品可以成功设置,并且网络连接(如果适用)正常运行。您还可以测试是否可以将数据的代表性样本(包括随附的非转移步骤,如移动虚拟机实例)移动到目标位置。

    您通常可以在分配所有资源(如转移机器或带宽)之前执行此步骤。此步骤的目标如下:

    • 确认您可以安装并运行转移作业。
    • 找出可能会导致项目停止的问题,这些问题会阻止数据移动(例如网络路由)或您的操作(例如非转移步骤所需的培训)。
  3. 性能测试。在此步骤中,您将在分配生产资源后对大型数据样本(通常为 3–5%)运行转移,目的如下:

    • 确认您可以使用所有已分配的资源,并且可以达到预期速度。
    • 找出并解决瓶颈问题(例如慢源存储系统)。

第 5 步:确保转移的完整性

为了帮助确保数据在转移期间的完整性,我们建议您采取以下预防措施:

  • 在目标位置启用版本控制和备份功能,以限制意外删除造成的损失。
  • 请先验证您的数据,然后再移除源数据。

对于大规模数据转移(包含数 PB 的数据和数十亿个文件),底层源存储系统的基本潜在错误率低至 0.0001% 仍会导致丢失数 GB 的数据和数千个文件。通常,在来源位置运行的应用已经能够容忍这些错误,这种情况下无需进行额外验证。在某些例外情况下(例如长期归档),必须进行更多验证,然后才能安全地删除来源位置的数据。

根据应用的要求,我们建议您在转移完成后运行一些数据完整性测试,以确保应用能够继续按预期运行。许多转移产品都内置了数据完整性检查功能。但是,根据您的风险概况,在从来源位置删除数据之前,您可能需要对数据和读取数据的应用进行额外的检查。例如,您可能希望确认您单独记录和计算的校验和是否与目标位置写入的数据相匹配,或者确认应用使用的数据集是否成功转移。

寻求帮助

Google Cloud 提供了各种选项和资源,方便您获取必要的帮助和支持,以充分利用 Google Cloud 服务:

  • 自助资源。如果您不需要专属支持,则可以按照自己的进度使用各种选项。
  • 技术合作伙伴。Google Cloud 已与多家公司达成合作,便于您使用 Google Cloud 产品和服务。
  • Google Cloud 专业服务。我们的专业服务可以帮助您充分利用在 Google Cloud 中的投资。

Google Cloud 迁移中心提供了更多资源来帮助您将工作负载迁移到 Google Cloud。

如需详细了解这些资源,请参阅迁移到 Google Cloud:使用入门中的“寻求帮助”部分

后续步骤