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

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

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

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

评估

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

进行完整的评估

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

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

  • 停机时间：确定可以处理停机时间的工作负载。确定这些停机时间何时发生以及可以持续多长时间，以最大限度地减少中断，例如在深夜或周末。迁移停机时间为零或接近零的工作负载比迁移可承受停机时间的工作负载更困难。如需完成停机时间为零的迁移，您需要为要迁移的每个工作负载设计和实现冗余。您还需要协调这些冗余实例。

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

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

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

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

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

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

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

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

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

评估数据处理流水线

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

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

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

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

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

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

评估网络基础架构

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

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

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

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

  • 应更新哪些 DNS 记录以指向目标环境？何时更新？
  • 哪些客户端正在使用这些 DNS 记录？
  • 您计划更新的 DNS 记录的存留时间 (TTL) 是如何配置的？
  • 能否在执行迁移之前将 DNS 记录 TTL 设置为最小值（以秒为单位）？
  • 您的 DNS 客户端和中介是否遵循您计划更新的 DNS 记录的 TTL？例如，您的应用是否具有忽略为迁移配置的 TTL 的客户端 DNS 缓存？请记住，DNS 解析涉及多层缓存。考虑使用 Google 公共 DNS，以避免 ISP DNS 问题。
  • 您的 DNS 客户端是否遵循要更新的 DNS 记录的 TTL？例如，您的应用是否具有忽略为迁移配置的 TTL 的客户端 DNS 缓存？
  • 即使在完成迁移后，您是否检测到指向来源环境的流量？

考虑创建概念验证

概念验证 (POC) 是对计划迁移项目的小规模初步实现。在您承诺全面实施该项目之前，它会验证该项目的可行性、功能和潜在益处。POC 可帮助您确定迁移工作负载在目标环境中是否正常运行。

首先，定义 POC 的范围和具体成功标准。 您的成功标准可能包括完全目标工作负载兼容性、最短迁移停机时间和特定性能需求等指标。

确定成功标准后，测试并验证 POC。在迁移计划文档中，捕获您的结果、遇到的挑战以及这些挑战的任何潜在解决方案。

如果您想了解以下感兴趣的领域，不妨考虑创建 POC：

  • 验证迁移可行性：验证您的应用、工作负载和数据是否在 Google Cloud中按预期运行。
  • 估算停机时间并制定回滚计划：衡量迁移工作负载和传输数据所需的停机时间。验证回滚方案。
  • 优化迁移计划：在执行全面迁移之前，考虑以下事项来优化您的计划：
    • 确定最佳迁移方法。
    • 确定您的现代化改造或工作负载重构需求。
    • 确定迁移过程中可能存在的风险或问题。
    • 测试迁移。
  • 执行安全和合规性验证：确保迁移的安全政策、Identity and Access Management (IAM) 角色和合规性要求符合贵组织的需求。
  • 建立信心并赢得利益相关方的支持：帮助确保利益相关方满意。成功的 POC 可向领导和技术团队展示切实的好处，从而让利益相关者对迁移计划充满信心。
  • 估算费用和优化可能性：估算与迁移关联的费用。探索优化可能性，例如测试不同的目标环境规模和迁移工具。

迭代多个 POC。调整目标工作负载和迁移计划，直到创建出符合成功标准的 POC。

迁移规划

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

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

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

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

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

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

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

计划对工作负载进行现代化改造和调整

在计划向 Google Cloud迁移时，记住迁移和集成工作负载需要时间，并且可能会带来挑战。考虑创建一个概览文档来描述工作负载的总体架构，其中包括有关以下主题的信息：

  • 依赖于外部系统和第三方中间件，例如存储空间、消息传递和托管。
  • 用于对工作负载进行身份验证和授权的机制。
  • 与 IAM 集成的流程。
  • 对运行时环境的要求。
  • 与存储层选项（例如 Cloud Storage 和 Google Cloud 数据库）的互动。
  • 数据传输量和带宽要求。
  • 您在迁移期间可能对应用代码进行的更改。
  • 与 Google Cloud Observability 集成的选项。

您可能需要对工作负载进行现代化改造，例如集成用于身份验证、授权、存储和可观测性的Google Cloud 库。对旧版库进行现代化改造可能需要付出一定的努力。规划足够的时间来全面测试工作负载。

计划逐步发布和部署

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

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

提醒开发和运营团队

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

如果您的团队在不同时区工作，且您采用全天候运营模式，请确保以下几点：

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

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

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

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

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

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

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

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

计划更新所有文档和信息中心

完成迁移后，计划全面更新您的生产操作手册、支持文档和监控信息中心。您可能需要对文档进行以下更改：

  • 架构图：更新架构图以反映 Google Cloud 架构，尤其是在您对工作负载进行现代化和重构时。
  • 连接和身份验证：更新有关身份验证方法（例如 IAM）和网络配置的文档，以反映 Google Cloud 架构。
  • 安全性：更新您的文档，其中讨论了Google Cloud 安全功能，包括静态加密和传输中加密以及基于 IAM 的访问权限控制。
  • 维护和扩缩：更新有关托管式服务维护期、垂直和水平扩缩过程以及性能优化最佳实践的生产操作 runbook。
  • 高可用性和故障切换：更新有关高可用性配置、区域和可用区同步注意事项以及故障切换机制的文档。
  • 备份和恢复：更新您的备份和恢复流程，使其与 Google Cloud 和备份和灾难恢复 (DR) 服务支持的流程保持一致。这些流程包括自动备份、时间点恢复可能性以及导出和导入程序。
  • 灾难恢复：更新您的灾难恢复计划和过程，使其与 Google Cloud 的灾难恢复功能保持一致，然后测试更新的过程。
  • 监控和日志记录：将 Google Cloud Observability 集成到您的监控信息中心和提醒系统中。更新有关 Cloud 配额的文档，并指定如何解读日志、指标和提醒。

运维

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

监控您的环境

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

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

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

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

管理迁移

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

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

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

后续步骤

贡献者

作者：Marco Ferrari | 云解决方案架构师

其他贡献者：Alex Cârciu | 解决方案架构师