将 IBM Db2 迁移到 Compute Engine 的策略

本文档介绍了以同构方式将 Db2 迁移到 Compute Engine 的最佳做法, 适用于想要将 Db2 环境迁移到 Google Cloud 的数据库管理员、系统管理员以及软件、数据库和运维工程师。从 Db2 迁移到其他类型的数据库不在本文档的探讨范围之内。

术语

IBM Db2
企业级关系型数据库管理系统 (RDBMS),具有复制和故障转移功能。
高可用性灾难恢复 (HADR)
Db2 的一项功能,根据数据库的日志记录将数据从主数据库复制到备用数据库。用户可利用该功能手动执行从主数据库到备用数据库的故障切换。
主机器
托管 Db2 且接受读写请求的机器。此机器是向备用机器执行复制时的数据来源
主备用机器
只能接受读取请求的备用机器。此机器支持 Db2 允许的任何同步模式,可指定为故障恢复实例以用于 HADR 目的。IBM Db2 只允许每个集群中有一个此类机器。
辅助备用机器
只能接受读取请求的备用机器。该机器仅支持 SUPERASYNC 同步模式,并且与主机器不在同一数据中心,以便在主数据中心发生故障时进行手动故障切换。
Tivoli System Automation for Multiplatforms (TSA/MP)
集群管理软件,协助将资源从主数据库自动故障切换到主备用数据库。此软件包括作为集群一部分定义的网络、存储和计算资源。Db2 企业版包含 HADR 的 TSAMP 授权
自动客户端重新路由 (ACR)
Db2 的一项功能,可将客户端应用从发生故障的服务器重定向到备用服务器,使应用可以最大程度地避免中断、继续正常工作。
变更数据捕获 (CDC)
用于检测数据库变更的一组技术或工具,例如,与其他数据库同步数据或创建审计跟踪记录。

架构

通常情况下,Db2 集群至少包含主节点和主备用节点,二者之间部署有 HADR。在较新版本的 Db2 中,您还可以添加辅助备用节点以实现灾难恢复目的。

下图描绘了一个来源环境。

两个数据中心内的典型来源环境架构。

在此环境中,主机器和主备用机器位于同一数据中心,而辅助备用机器位于不同的数据中心。

迁移目标是在 Google Cloud 上重建此环境,如下图所示。

在 Google Cloud 上重建的来源环境的架构。

下表从几个方面对各种迁移方法进行了比较。

Migrate to Virtual Machines Q Replication SQL Replication HADR
来源 VMware、Amazon Web Services (AWS) 虚拟机 任何 Db2 环境(取决于许可) 任何 Db2 环境 任何 Db2 环境
复制的内容 磁盘块级数据 数据库中的表 数据库中的表 整个数据库
切换 在 Google Cloud 中启动虚拟机需要几分钟时间 将应用和 DNS 指向 Compute Engine 实例 将应用和 DNS 指向云实例 将应用和 DNS 指向云实例
DDL 更改复制 有(复制磁盘写入内容)
同步数据复制
异步数据复制
时间点数据复制

上表旨在帮助您根据系统可用性要求和资源工作量来设置目标系统、设置复制功能以及日后维护和测试复制内容。从此表中可以发现,Migrate to VMs 方法最容易实现,但是,它在系统可用性方面的灵活度最低。另一方面,HADR、Q Replication 和 SQL Replication 对系统可用性的影响较小,但是,它们需要并行执行较多复制设置和维护工作。

迁移类型

您可以通过以下两种方式将 Db2 迁移到 Compute Engine:

  • 通过修改现有集群配置或拓扑进行迁移。
  • 通过将数据复制到全新集群进行迁移。

修改现有集群不需要在云中启动全新集群,因此迁移速度较快。另一种迁移方式需要将新集群部署到 Google Cloud,但这种方式对现有集群的影响较小,因为采用的是带外复制方式。如果您只需要复制数据库的一部分,或者您想在将数据迁移到目标之前先执行数据转换,那么这种方法也很方便。

以下部分讨论了在将 Db2 实例迁移到 Google Cloud 之前需要考虑的事项。某些常用功能可能无法在 Google Cloud 上按原样运行,或者可能需要进行一些配置更改。

浮动(虚拟)IP 地址

在可用性高的 Db2 集群中,TSA/MP 可以为主节点分配虚拟 IP 地址。此地址也称为浮动 IP 地址,意味着流量始终路由到主节点而非备用节点。

Compute Engine 在 Virtual Private Cloud (VPC) 网络中使用虚拟网络栈,因此通常的实现机制可能无法正常运行。例如,VPC 网络根据配置的路由拓扑来处理地址解析协议 (ARP) 请求,并忽略不必要的 ARP 帧。此外,使用标准路由协议(例如开放式最短路径优先协议 (OSPF)边界网关协议 (BGP))时,无法直接修改 VPC 网络路由表。因此,您必须实现浮动 IP 地址的替代方案或使用 ACR。

如果您需要迁移 Db2 集群中的部分或所有节点,请务必先停用集群的浮动 IP 地址,然后再迁移任何节点。

ACR

如果您的 Db2 环境使用 ACR,您可能需要在 DNS 名称发生更改或客户端使用 IP 地址进行连接时更改客户端上的目录。

裁定程序

为启动自动化操作,TSA/MP 要求大多数集群节点处于在线状态。如果集群包含偶数个节点,那么集群中可能恰好有一半节点处于在线状态,并且可能出现脑裂情况。 在这种情况下,TSA/MP 会使用裁定程序来确定仲裁(多数组)状态,该状态决定了是否可以启动自动化操作。

请考虑 Db2 环境可能使用的以下裁定程序:

  • 存储空间或磁盘裁定程序。 Ibm Db2 使用预留的磁盘资源来打破僵局。由于 Google Cloud 不支持预留,因此您必须选择其他类型的裁定程序
  • 网络裁定程序。 使用(集群的)外部 IP 地址来解决平衡僵局。 在混合部署中,只要可以从各集群节点访问网络裁定程序,一开始就可能不需要将其迁移到 Google Cloud。但在 Google Cloud 上运行集群后,最好在其他区域创建裁定程序,或者使用 Google Cloud 元数据服务器作为裁定程序。
  • NFS 裁定程序。 NFS 裁定程序可解决基于存储在 NFS v4 服务器上的预留文件的平衡僵局。 与网络裁定程序一样,在混合部署中,NFS 裁定程序和 NFS v4 服务器也可以保留其原有位置。但一段时间之后,您最好部署自己的 NFS 服务器,或使用 Elastifile 等合作伙伴作为 Google Cloud 上的 NFS 裁定程序目标。

使用 Migrate to VMs 进行迁移

如果您的环境同时满足以下两个条件,建议您选择“Migrate to VMs”迁移方式:

  • 您在 Amazon Elastic Compute Cloud (Amazon EC2) 中拥有 VMware vCenter 环境或虚拟机。

  • 您的环境已与 Google Cloud 建立专用连接,例如 Cloud VPN 或 Cloud Interconnect。

Migrate to VMs 用于将虚拟机从本地和云环境迁移到 Google Cloud,在几分钟内便可将虚拟机迁移到 Google Cloud。虽然数据在后台复制,但虚拟机可以完全正常运行。您必须在来源环境与 Google Cloud 项目之间建立专用连接,例如 Cloud VPN、Cloud Interconnect 或合作伙伴互连。

使用 Migrate to VMs 时,您需要重新评估云虚拟机上的数据库配置。某些配置可能未针对 Google Cloud 进行优化,例如注册表变量缓冲区池数据库管理器配置数据库配置。您可以使用 AUTOCONFIGURE 实用程序以从基准配置入手。

如需详细了解 Migrate to VMs 操作方法,请参阅虚拟机迁移生命周期

以下部分概述了如何将此方法应用于 Db2 环境。

测试克隆

测试克隆仅适用于 vCenter 环境。

Migrate to VMs 可以截取虚拟机快照,并根据该快照在 Google Cloud 上创建即用型计算实例。您可以在 Google Cloud 上重新创建 Db2 环境、尝试更改配置、执行测试,以及对部署进行基准化分析,且不会对来源环境产生任何影响。

下图展示了 Google Cloud 上的 DB2 环境,以及 Google Cloud 上执行 Migrate to VMs 测试克隆之后的并行环境。

进行测试克隆后并行环境的架构。

在 Google Cloud 上对测试克隆进行基准化分析和测试后,您可以删除这些克隆。

云端运行

激活云端运行时,Migrate to VMs 会关停来源集群,并在 Google Cloud 上启动虚拟机,同时仅提取所需的数据,而非将所有存储内容流式传输到 Google Cloud。云端运行支持回写,而且默认启用回写。借助 Migrate to VMs,您可以先对环境进行测试,然后再主动流式传输存储内容。此外,您还可以使用回滚功能将虚拟机迁回来源环境。在云到云的迁移场景中,您无法将写入内容复制回源环境。

下图展示了云运营阶段(假定所有节点均设置为云运营模式)。您可以选择逐步迁移各集群节点,而不是一次性迁移整个集群。

云端运行阶段的架构,其中所有节点均设置为在云端运行。

迁移

迁移阶段类似于云端运行阶段,但 Migrate to VMs 还会主动将存储内容流式传输到 Google Cloud。在云端运行阶段,由于您尚未表明已准备好迁移整个虚拟机,Migrate to VMs 只会按需提取数据,以节省带宽。

分离

在此阶段,Migrate to VMs 会将其缓存和对象存储区中的数据同步到 Google Cloud 上的原生数据磁盘,然后将磁盘挂接到虚拟机上。此阶段要求您关停 Google Cloud 上的虚拟机。对于 Db2,我们建议您一次分离一个集群节点。

使用复制功能

对于 Db2,复制过程会使用“捕获”程序从事务日志中捕获更改,然后使用“应用”程序将这些更改应用于其他集群。“捕获”程序捕获更改的方式以及用于将更改传输到“应用”程序的通信通道类型因复制类型而异。

下图显示了与 Db2 复制类型对应的逻辑信息流。

Db2 复制对应的信息流结构。

“捕获”应用从数据库中捕获更改并将更改发送到“应用”应用。“应用”应用将这些更改写入目标数据库。这些应用可以对数据本身进行一些转换。“捕获”和“应用”应用不一定需要在数据库服务器上运行。

SQL Replication

SQL Replication 会捕获对源表和视图的更改,并使用暂存表来存储已提交的事务性数据。然后,它会从暂存表中读取更改并将其复制到相应的目标表。截至撰写本文为止,安装 Db2 即可使用 SQL Replication

利用 SQL Replication 的迁移过程如下所示:

  1. 在 Google Cloud 上部署 Db2。
  2. 配置 SQL Replication。
  3. 启动 SQL Replication。
  4. 验证两个部署是否处于同步状态。
  5. 将您的应用指向 Google Cloud 实例。停止复制。

下图显示了一个 SQL Replication 迁移示例。

Google Cloud 上的来源环境的 SQL Replication。

在将 SQL 命令复制到您在 Google Cloud 上创建的新集群时,您的生产环境会照常运行。在上图中,复制过程在主实例上运行,但您还可以选择其他多种部署方式(这些内容不在本文的讨论范围内)。

Q Replication

Q Replication 是新近推出的一种比 SQL Replication 更高效的迁移方法,可将数据从一个 Db2 实例复制到另一个 Db2 实例。这种方法使用 IBM MQ 提供数据更改条目,这意味着您需要在来源环境和目标环境中部署 IBM MQ 实例。 这种复制方法比 SQL Replication 速度更快,因为它是在内存中进行复制。 尽管 SQL Replication 执行速度较慢,但是 Q Replication 通常较难设置,因为您需要设置 IBM MQ。根据您的 Db2 许可,您可能需要获得 Q Replication 许可。

启动 Db2 Q Replication 时,您可以选择以下两种方法之一:

  • 自动加载。通过 Q Replication 复制过程执行初始加载,即从来源备份恢复目标数据库。

  • 手动加载。由您来执行初始加载并从相应日志点开始复制。

迁移过程如下所示:

  1. 在 Google Cloud 和来源环境中部署 IBM MQ。
  2. 在 Google Cloud 上部署 Db2。
  3. 配置 Q Replication 复制。
  4. 启动 Q Replication 复制(通过手动加载或自动加载)。
  5. 验证两个部署处于同步状态。
  6. 将您的应用指向 Google Cloud 实例。停止复制。

下图显示了一个可行的 Q Replication 复制解决方案。

Google Cloud 上的来源环境的 Q Replication 复制架构。

来源环境使用 IBM Q Replication 复制将数据库更改发送到 IBM MQ 和目标环境,并将 Db2 集群扩展到 Compute Engine

这种方法会逐步将现有的 Db2 集群迁移至 Compute Engine,并依赖 HADR 在节点之间转移数据。

如果您符合以下情况,请使用此方法:

  • 您不想在 Compute Engine 上部署一个全新集群。
  • 您无法利用 Migrate to VMs。
  • 您无法使用某种复制选项。
  • 由于许可、费用或合规性等原因,您没有或无法使用合作伙伴产品。

当您的 Db2 版本不支持辅助备用实例时

您可以执行以下操作:

  1. 在 Compute Engine 上部署 Db2 实例。
  2. 从主实例中进行备份。
  3. 通过备份恢复 Compute Engine 上的 Db2 实例。
  4. 从 HADR 设置中移除备用实例。
  5. 将 Compute Engine Db2 实例作为备用实例进行连接(您可以选择同步模式,但为避免延时加重,最好使用 ASYNCNEARASYNC)。
  6. 故障切换到 Compute Engine Db2 实例并将其设为 HADR 主实例。
  7. 创建另一个 Compute Engine Db2 实例,使用备份恢复其数据,并设置为 HADR 备用实例。

下图中首先显示了如何将在 Google Cloud 上新创建的 Db2 实例设置为来源 Db2 主实例的主备用实例。

将 Google Cloud 上的 Db2 实例设置为主备用实例的架构。

在上图中,首先将 Google Cloud 实例设为 HADR 主实例。然后,移除源主备用实例,并在 Compute Engine 上连接另一个 Db2 实例作为主备用实例。

当您的 Db2 版本支持辅助备用实例时

一种选择是遵循与 Db2 版本不支持辅助备用实例时相同的步骤,但最后还需要迁移辅助备用实例。

另一个选择是利用辅助副本向 Google Cloud 进行更具容错能力的迁移,因为您的来源环境中没有主实例或主备用实例,而 Google Cloud 上也没有。以下列表概述了第二种方案所涉及的步骤:

  1. 将 Compute Engine 上的 Db2 实例(主实例、主备用实例、辅助实例(如果需要))部署到各自的位置。
  2. 从源集群中移除辅助备用节点。
  3. 配置将充当源集群的主实例和主辅助备用实例的节点。
  4. 对其中一个 Compute Engine 实例执行接管操作,以将该实例设为主实例。然后将另一个 Compute Engine 实例配置为主实例的主备用实例。

下图首先显示了在 Compute Engine 上新创建的两个 Db2 实例。

Google Cloud 上的辅助 Db2 实例的架构。

首先,将这些实例设置为源 Db2 主实例的辅助备用实例,而非来源环境中的辅助实例。接着,对其中一个 Compute Engine 实例调用接管操作,以将该实例设为 HADR 主实例,并将另一个实例配置为主备用实例。最后,将其他两个实例配置为辅助备用实例。

合作伙伴产品

有些 Google 合作伙伴的产品可以帮助完成此类迁移。 这些产品大多利用 CDC 在源 Db2 实例和目标实例之间复制数据。 这些产品不属于 Google Cloud 产品,因此您需要了解每个产品或服务的许可和价格。通常,相应服务会将数据从现有集群复制到您在 Google Cloud 上创建的其他集群,整体方法类似于本文中介绍的复制场景。

以下是一些合作伙伴产品:

后续步骤