迁移到 Google Cloud：验证迁移计划的最佳实践

Last reviewed 2023-11-29 UTC

本文档介绍用于验证将工作负载迁移到 Google Cloud 的计划的最佳实践。本文档未列出验证迁移计划的所有可能的最佳实践，并且它不保证您可以成功。但是，它可以帮助您促进对迁移计划的潜在更改和改进的讨论。

如果您计划从本地环境、私有托管环境或其他云提供商迁移到 Google Cloud，则本文档非常有用。如果您要评估迁移的时机并希望了解潜在的情况，本文档也可以提供帮助。

本文档是关于迁移到 Google Cloud 的以下系列文章中的一篇：

评估

执行完整的工作负载和环境评估有助于确保您深入了解工作负载和环境。了解这一点有助于您最大限度地降低在迁移到 Google Cloud 期间和之后出现问题的风险。

进行完整的评估

在继续执行评估阶段之后的步骤之前，请完成工作负载和环境评估。如需进行完整的评估，请考虑以下经常被忽略的项目：

  • 清单：确保要迁移的工作负载清单为最新，并且您已完成评估。例如，考虑源数据用于评估的新鲜度和可靠性，以及数据中可能存在哪些差距。

  • 停机时间：评估哪些工作负载可以承受停机时间，以及这些停机时间可能持续的最长时间。迁移停机时间为零或接近零的工作负载比迁移可承受停机时间的工作负载更困难。如需完成停机时间为零的迁移，您需要为要迁移的每个工作负载设计和实现冗余。您还需要协调这些冗余实例。

    在评估工作负载可以承受的停机时间时，请评估停机时间为零的迁移的业务优势是否大于增加的迁移复杂程度。尽可能避免为工作负载创建停机时间为零的要求。

  • 集群和冗余：评估哪些工作负载支持聚簇和冗余。如果工作负载支持集群和冗余，您可以部署该工作负载的多个实例，甚至可以在不同的环境（例如来源环境和目标环境）中部署。集群化和冗余部署可能会简化迁移，因为这些工作负载可以相互协调，所需的干预有限。

  • 配置更新：评估如何更新工作负载配置。例如，考虑如何提供要迁移的每个工作负载的配置的更新。此注意事项对于成功迁移至关重要，因为在将工作负载迁移到目标环境时，您可能需要更新工作负载的配置。

  • 生成多个评估报告：在评估阶段，生成多个评估报告以将不同的场景考虑在内可能很有用。例如，您可以生成报告，以考虑工作负载的不同负载配置文件，例如高峰时段和非高峰时段。

评估工作负载支持的故障模式

了解您的工作负载在异常情况下的行为有助于确保您不会使它们遇到不可恢复的条件中。在评估过程中，应收集有关您的工作负载支持且可自动从中恢复的故障模式及其影响以及哪些故障模式需要干预的信息。例如，您可以先考虑可能的故障模式相关问题，例如：

  • 如果工作负载断开与网络的连接，会发生什么情况？
  • 工作负载在停止后是否可以从上次停止的位置继续工作？
  • 如果工作负载或其依赖项性能不足，会出现什么情况？
  • 如果架构中有两个工作负载具有相同的标识符会发生什么情况？
  • 如果计划的任务不运行会发生什么？
  • 如果两个工作负载处理同一请求会发生什么情况？

不受支持的故障模式的另一个来源可能是迁移计划本身。确定您的迁移计划是否包含依赖于特定条件成功的步骤，以及它是否包含在出现不满足条件的情况时的应急措施。包含这些类型的条件的计划可能表示计划本身可能会失败，或者个别组件在迁移期间可能会失败。

评估这些失败模式及其影响后，通过模拟失败并注入模拟这些失败模式的故障，从而在非关键环境中验证发现结果。例如，如果工作负载设计为在网络连接断开后自动恢复，则通过强制中断其连接并在之后恢复来验证自动恢复。

评估数据处理流水线

您的工作负载评估应该能够回答以下问题：

  • 资源大小是否适合迁移？
  • 迁移工作负载所需的数据需要多长时间？
  • 目标环境能否容纳全部数据？
  • 工作负载必须应对给定时段需求激增或它们产生的数据量激增时，它们行为如何？
  • 如果需求激增或者工作负载产生的数据量激增，是否存在不利影响，例如延迟时间增加或响应延迟？
  • 工作负载启动后，它们是否需要时间逐步提升到预期的性能水平？

此评估的结果通常是工作负载满足的需求以及工作负载在给定时间范围内生成的数据的模型。在收集数据点来生成此类模型时，请考虑这些数据点在高峰时段和非高峰时段之间可能存在显著差异。如需详细了解监控方法以及监控内容，请参阅《站点可靠性工程》一书中的服务等级目标。

确保您可以更新和部署要迁移的每个工作负载

在迁移过程中，您可能需要更新一些您正在迁移的工作负载。例如，您可能需要部署问题的修复，或回滚导致问题的最近更改。对于您正在迁移的每个工作负载，请确保您可以应用和部署更改。例如，如果您正在迁移您有其源代码的工作负载，请确保可以访问该源代码，并且可以根据需要构建、打包和部署源代码。

迁移可能包括您无法向其应用和部署更改的工作负载（例如专有软件）。在这种情况下，请重构迁移计划以考虑其他措施来缓解迁移这些工作负载后可能出现的问题。

评估网络基础架构

正常工作的网络基础架构是迁移的基础。您可以在迁移工具中使用网络基础架构。例如，您可以根据迁移计划使用负载均衡器和 DNS 服务器来定向流量。

为避免迁移期间出现问题，请务必评估网络基础架构，并评估它可以支持迁移的程度。例如，您可以先考虑有关负载均和基础架构的问题，例如：

  • 重新配置负载均衡器时会发生什么情况？
  • 更新后的配置需要多长时间才能生效？
  • 对于停机时间为零的迁移，如果在更新后的配置实施之前出现流量高峰，会发生什么情况？

考虑有关负载均衡基础架构的问题后，接下来需要考虑有关 DNS 基础架构的问题，例如：

  • 应更新哪些 DNS 记录以指向目标环境？何时更新？
  • 哪些客户端正在使用这些 DNS 记录？
  • 如何配置 DNS 记录的存留时间 (TTL)？
  • 能否在迁移过程中将 DNS 记录 TTL 设置为最小值？
  • 您的 DNS 客户端是否遵循要更新的 DNS 记录的 TTL？例如，您的应用是否具有忽略为迁移配置的 TTL 的客户端 DNS 缓存？

迁移规划

仔细计划迁移有助于避免在迁移期间和迁移后出现问题。计划还有助于避免处理意外任务。

为迁移计划的每个步骤制定回滚策略

在迁移期间，您执行的迁移计划的任何步骤都可能会导致意外问题。为确保您能够从这些问题中恢复，请为迁移计划的每个步骤准备回滚策略。为避免在服务中断期间浪费时间，请执行以下操作：

  • 定期检查和测试每个回滚策略，以确保您的回滚策略有效。
  • 为每个迁移步骤设置允许的最长执行时间。允许的执行时间到期后，您的团队将开始回滚迁移步骤。

即使您准备了针对迁移计划的每个步骤的回滚策略，其中一些步骤可能仍然可能会中断。可能会中断的步骤即使回滚也可能导致某种类型的丢失，例如数据丢失。评估迁移计划中的哪些步骤可能会中断。

如果您将迁移计划的任何步骤自动化，请确保当自动化失败时，每个自动化的步骤都有预先计划的过程。与回滚策略一样，请定期检查和测试每个预先计划的过程。

如果您在迁移过程中设置了通信渠道，以确保您不会被锁在自己的环境之外，请预配可用于从失败中恢复的备用渠道。例如，如果您设置了合作伙伴互连，则还可以在预配和配置期间设置可通过公共互联网的备用访问权限，以应对在迁移过程期间遇到的任何问题。

计划逐步发布和部署

如需缩小在迁移过程中可能出现的问题的范围，请避免大规模更改，并设计迁移计划以逐步部署更改。例如，计划逐步部署和配置更改。

如果您计划逐步发布，以降低更改造成的意外问题的风险，请尽可能减少更改的数量和大小。在第一个小规模发布中发现并解决问题后，您可以针对类似更改以较大的规模进行后续发布。

提醒开发和运营团队

为了降低迁移过程中可能发生的问题的影响，请提醒负责迁移任何工作负载的团队。此外，还要提醒负责来源环境和目标环境基础架构的团队。

如果您的团队在不同时区工作，请确保以下几点：

  • 您的团队正确覆盖这些时区，并且覆盖多个连续班次，因为他们可能无法在单个班次期间解决问题。
  • 您的团队已准备好收集有关他们可能遇到的问题的详细信息。此收集可为下一个班次的工程师提供上一个班次已执行的工作和执行原因的完整信息。
  • 团队中的特定人员负责任何给定的班次。

从目标生产环境中移除概念验证资源

作为评估的一部分，您可能使用目标环境来托管实验和概念验证。在迁移之前，请从目标环境的生产环境中移除您在这些实验和概念验证期间创建的所有资源。

在迁移过程中，您可以保留目标环境的非生产区域中的资源，因为这些资源可以帮助您收集有关在迁移过程中可能出现的任何问题的信息。例如，要诊断在迁移后会影响生产工作负载的问题，您可以将生产工作负载的配置和数据日志与概念验证和实验的配置和数据日志进行比较。

完成迁移并验证目标环境按预期运行后，您可以删除目标环境的非生产区域中的资源。

定义安全停用来源环境的标准

为避免无限期地运行两个环境的费用，请定义必须满足哪些条件才能安全停用来源环境，例如：

  • 所有工作负载（包括其备份和高可用性以及灾难恢复机制）都已成功迁移到目标环境。
  • 迁移到目标环境中的数据一致、可访问且可使用。
  • 迁移后数据的准确性和完整性符合定义的标准。
  • 保留在来源环境中的资源不是迁移范围之外的工作负载的依赖项。
  • 您的工作负载在目标环境中的性能满足 SLA 目标。
  • 您的监控系统报告没有应定向到目标环境的流向来源环境的网络流量。
  • 工作负载在目标环境中正确无误运行达到定义的时间段后，您确信不再需要回退到来源环境的能力。

运维

要在迁移期间高效地管理来源环境和目标环境，您还需要设计运维流程。

监控您的环境

如需观察来源环境和目标环境的行为并帮助您诊断出现的问题，请设置以下项目：

  • 监控系统，用于收集对场景有用的指标。
  • 日志记录系统，用于观察由工作负载和其他环境组件执行的操作流。
  • 提醒系统，可在有问题的事件发生之前向您发出警告。

Google Cloud Observability 支持您的 Google Cloud 环境的集成监控、日志记录和提醒。

由于工作负载及其依赖项跨多个环境，因此您可能需要考虑针对不同环境使用多个监控和提醒工具。考虑迁移支持工作负载的监控和提醒政策的时间。例如，如果您的来源环境配置为在特定服务器关闭时发出提醒，则会在您有意关闭该服务器时触发提醒。提醒触发器是预期的，但它是无用的行为。在迁移过程中，您需要不断调整针对来源环境的提醒，并为目标环境重新配置提醒。

管理迁移

如需管理迁移，您需要查看迁移性能以收集信息，供迁移完成后用于回顾。收集信息后，您可以使用这些信息来分析迁移性能并准备有关环境潜在改进的数据点。

例如，如需开始计划管理迁移，请考虑以下问题：

  • 迁移计划的每个步骤用了多长时间？
  • 迁移计划中是否有任何步骤用时超出预期？
  • 是否缺少了任何步骤或检查？
  • 迁移期间是否发生了任何不良事件？

后续步骤