目前，众多金融机构按照行业规范和内部要求，建立起较为完备的 IT 基础设施灾备方案和容灾演练体系。不过，已有的灾备体系大多是基于 VMware 虚拟化环境和国外灾备产品进行建设，面对信创转型趋势和越来越严格的容灾切换标准，不少金融机构都在同步探索灾备基础设施升级改造与 VMware 迁移方案。

近期，某保险资管机构基于 SmartX 超融合和 SMTX 备份与容灾进行了生产数据中心和灾备数据中心的 IT 基础架构升级改造，并利用 SMTX 迁移工具顺利迁移 50+ VMware 虚拟机至 SmartX 超融合信创集群，提升灾备演练效率的同时实现国产化替代。期间，SmartX 工程师不仅协助用户制定了详细迁移计划，还结合实践经验总结了“迁移攻略”，我们将在下文进行分享！

更多 VMware 替代方案与实践，欢迎下载阅读《VMware 升级替代专题》电子书。

实践背景

该用户生产环境的 IT 基础设施原先主要采用“VMware 虚拟化 + FC 交换机 + 集中式存储”的传统三层式架构进行建设。为了满足生产业务系统的灾备要求，用户基于相同的基础架构搭建了灾备中心，引入第三方数据备份产品 Rubrik 实现数据的异步复制，两个数据中心间通过 100M 专线进行互联。整套架构如下图所示。

为了进一步保证业务数据的可靠性，用户内部要求，针对关键生产业务系统每年应至少完成一次灾备演练。不过在采用以上架构开展演练的过程中，用户发现灾备效果和效率都不尽如人意：

  • 效果差：用户内部规定，关键业务系统灾难恢复 RTO 不应超过 30 分钟，理想情况下应在十几分钟内完成。而在灾备演练过程中，由于灾备切换涉及大量繁琐且耗时的手动操作，大幅延长了灾难恢复用时，存在不小的业务连续性风险。
  • 有代理：第三方数据备份产品基本都采用在业务虚拟机上安装备份代理软件的部署模式，存在一定的资源占用，且用户采用的产品在国内只有代理商提供支持服务，也为业务连续性带来一定的风险。
  • 资源有限：考虑到成本管控等因素，用户希望能在当前有限的网络带宽条件下尽量保障复制容灾服务的健壮性，这也为容灾方案的设计带来了一些挑战。

除了灾备方面的挑战，用户也希望能对生产环境架构进行改造，以国产虚拟化平台搭配国产 CPU 架构服务器支持更多业务系统。在这些背景下，用户计划引入一套国产基础设施，对原有生产环境和灾备环境的部分基础架构进行升级和替代。同时，作为保险资管行业的头部机构，用户对 IT 基础架构的产品能力和方案细节要求非常严格，不仅要求国产方案能够同时满足生产环境和灾备环境的性能与可用性需求，还需要具备完整、平滑的虚拟机跨平台迁移方案，保证基础架构的顺利过渡。

实践成果与经验分享

经过多方对比验证，用户选择基于 SmartX 超融合进行生产环境和灾备环境部分基础设施的改造。SmartX 超融合提供原生灾备服务 SMTX 备份与容灾，无需第三方组件，即可提供“RPO 最少 15 分钟、RTO 达到分钟级”的数据保护服务等级。SmartX 自研迁移工具 SMTX 迁移工具也可在尽量降低停机时间的前提下，保障虚拟机跨平台迁移的速率和稳定性，为用户提供方便可靠的迁移体验。

目前，用户分别基于 Intel 和鲲鹏芯片架构服务器构建了两个 SmartX 超融合集群（采用原生虚拟化 ELF），通过 SMTX 迁移工具将 VMware 平台虚拟机稳步迁移至 ELF 平台，承载 PUB 集群、OA 集群等一般生产系统与 DMZ 集群，并分别建设了相应的灾备环境。通过备份与容灾模块，能够将主机房的业务虚拟机复制到灾备备份机房进行保护（根据机构需求设置间隔 12 小时）。复制通过 150Mbps 专线完成，并可按需进行容灾备份演练。改造后的整套架构如下图所示。

采用新架构后，用户的生产和灾备中心以 SmartX 超融合作为统一的云底座，并实现了异构 CPU 集群的统一管理，在精简架构的同时完成了从 VMware 虚拟化向国产虚拟化平台的升级改造。此外，得益于 SMTX 备份与容灾和 CloudTower 的运维支持特性，该机构仅需几步简单的操作即可在 30 分钟内完成容灾切换，满足容灾演练 RTO 要求的同时免除了繁琐的手动操作。

VMware 迁移经验分享

在完成 SmartX 超融合的搭建后，用户的首要任务是将当前运行在 VMware 虚拟化平台上的业务虚拟机平滑迁移到 SmartX 超融合环境，并且确保所有业务虚拟机在迁移后能够正常稳定运行。由于 SmartX 已帮助全国范围内各类金融行业用户完成了大量的虚拟机迁移项目，具备丰富的迁移经验，用户选择采用 SMTX 迁移工具进行迁移。SMTX 迁移工具采用分段式迁移的方式，可以在虚拟机正常运行的情况下进行全量数据的同步；当全量数据同步完成后，用户可选择在保持源端虚拟机运行的情况下手动同步增量数据，降低停机同步时间，随后在维护窗口内完成最终的增量数据同步（一般停机时长不会超过 30 分钟）。

此次项目中，用户待迁移的虚拟机数量近 50 台，数据量超过 10TB，迁移周期较长，如何在对业务影响最小的前提下进行顺滑的迁移，是迁移任务首要考虑的问题。为达成这一目标，需要在迁移前期进行充分的调研和准备工作。SmartX 工程师协助该机构对待迁移虚拟机信息进行详细调研，了解虚拟机名称、对应业务系统、承载的业务、资源（vCPU、内存和存储）用量等，以便合理评估虚拟机所需的迁移时间，以及虚拟机之间的业务依赖关系，据此将待迁移虚拟机划分为多个批次进行迁移，合理控制每个批次的迁移时长，降低业务中断风险。

我们在调研过程中发现，由于业务虚拟机已经在 VMware 虚拟化上部署和运行多年，部分虚拟机运行的操作系统版本较低，不在迁移工具的兼容性列表中（如 RHEL5）；也有一些虚拟机运行特殊的定制系统（如数据防泄漏系统底层为经过厂商深度定制的 Ubuntu Linux 18.04）。为了降低迁移风险，SmartX 工程师建议用户通过手动方式将此类虚拟机重新部署在 SmartX 超融合上，并手动完成数据迁移工作。

在经过充分的环境调研和评估后，SmartX 协助用户制定了详细的迁移计划，明确了迁移环境的搭建方案、网络配置和端口策略要求、虚拟机迁移批次顺序以及应急回退方案，其中涉及技术方案部分包含了详细的技术操作步骤，例如如何部署迁移工具、迁移网络的配置方法，以及针对不同类型操作系统的迁移操作手册。

在迁移过程中，可能出现迁移的数据量与预估的数据量不一致的情况。这是由于迁移工具会对源端虚拟机分配的磁盘进行读取校验，如果当前块不为 0 则进行数据传输，为 0 则不进行数据传输，这一过程会消耗一定的时间，导致实际迁移时间长于预估时间。因此在前期规划时，SmartX 工程师也针对这一因素建议用户预留充足的迁移时间窗口，保障迁移的顺利进行。还有一些技术细节也需要用户在迁移时格外关注，例如在迁移窗口期间需要对虚拟机停止快照或备份操作，避免导致虚拟机迁移任务执行失败。

此外，虽然 SMTX 迁移工具能够将源端虚拟机的数据无损同步到超融合集群，但是由于虚拟机操作系统的自身机制、虚拟机的配置以及国外虚拟机平台的一些特性，可能导致虚拟机在迁移完成后出现一些问题，需要用户在迁移前后进行手动干预。其中比较典型的问题包括以下三类，值得用户关注：

  • 激活问题：通过 KMS 激活的 Windows Server 虚拟机在迁移之后可能显示未激活，这是由于在迁移之后 Windows Server 检测到所在的硬件环境发生了变化，导致激活失效，需要用户在迁移完成后手动处理。
  • 磁盘离线：Windows Server 虚拟机迁移完成后如果出现 SAN 磁盘离线的情况，可能是 Windows Server SAN 策略配置造成的，在迁移虚拟机之前进行合理配置即可规避。
  • DNS 配置问题：Windows Server 虚拟机迁移完成后如果出现网络异常，例如 Outlook 服务器无法连接、IP 无法共享等，需要检查并调整 DNS 配置。

更多 VMware 迁移规划和实践经验，请阅读：VMware 虚拟机迁移指南：10 大关键问题与 3 例用户实践。

灾备建设经验分享

在顺利完成虚拟机迁移后，SmartX 继续协助用户对容灾环境进行了详细的规划，包括调研计划纳入容灾的业务虚拟机信息、对机房之间复制网络专线的容量进行评估、对集群资源用量进行评估、了解容灾演练的步骤和期望效果，并在内部试验环境模拟该机构的实际环境进行了大量验证，确保方案的可行性。由于用户原有生产机房和灾备机房之间的复制专线只有 100M 带宽，承载生产机房和灾备机房之间所有数据流量，给改造工作带来了一些挑战：

  • 首次复制的数据量较大，如果完全通过复制专线进行复制任务，预计需要数天至数周才能完成首次复制，无法满足业务要求。
  • 业务增量数据可能难以在指定的复制周期内完成复制任务，影响到灾难发生时的 RPO。

为了解决上述问题，SmartX 制定了针对性的解决方案：在执行首次复制任务时，将灾备集群放置在生产机房内，使用生产机房的内部网络完成首次复制，将首次复制的时间压缩到 8 小时以内。在首次复制完成后的第二个周末，将灾备集群整体搬迁到灾备机房，恢复集群服务并在打通与生产机房之间的网络线路后，发起增量复制任务，将这一周内的增量数据复制到灾备集群。为了使增量复制能够同时满足业务和容灾监管的需求，SmartX 工程师结合各个业务的特性，对复制周期进行了合理的评估和设定，帮助用户顺利基于原有 100Mbps 的网络条件实现了灾备机房改造。后期，为了进一步保证灾备的可靠性，用户将专线更换为 150Mbps。

灾备演练经验分享

在完成首次复制和首次增量复制后，按照项目规划，需要通过容灾演练来验证复制服务的有效性。演练流程包括断开生产机房与灾备机房之间网络，以及在灾备机房将副本虚拟机拉起。演练结束后，副本虚拟机增量数据不同步回源端虚拟机。用户原先使用第三方软件 Rubrik 进行容灾演练，在整个演练过程中涉及大量的手动操作，包括：

  • 在备份机房，手动启动并确认核心支撑服务可用，如 NTP 和 AD 域服务等；
  • 手动修改全局服务入口，并断开生产与灾备间的专线；
  • 启动账户管理等支撑系统，由于其依赖 AD 域做账户判断，需要重启 AD 以修改 DNS 服务；
  • 修改内部 DNS，并重启 DNS 服务以保障内部系统间寻址正确；
  • 按照业务依赖关系，依次手动启动业务虚拟机。

这些手动操作大幅延长了用户的容灾演练用时，为了满足“基础设施 20 分钟、高优先级业务 30 分钟、主要业务 1 小时“的 RTO 目标，每次演练技术人员都有很大的压力。而采用 SmartX 超融合后，得益于智能的虚拟机分组功能和易用的操作界面，用户仅需进行简单的设置即可完成容灾切换：在演练过程中，由于生产机房和灾备机房之间网络断开，灾备集群需要使用自身的 Web 控制台进行管理操作；用户可使用 Web 控制台配置虚拟机分组，按照分组启动副本虚拟机，从而实现副本虚拟机按照业务依赖关系依次启动，并减少了大量的手动操作，有效缩短了基础设施容灾切换速度，满足 RTO 要求的同时避免误操作带来的风险，大幅提升了整套架构的可靠性。

总结

金融机构开展灾备演练的核心目标，是保证真实灾难来临时，关键数据不会丢失、核心业务系统能够连续稳定运行，因此更需要简洁、可靠、稳定的国产基础设施方案，为关键业务和数据的容灾备份保驾护航。SmartX 凭借自主研发的核心技术、靠谱的自研迁移工具、丰富的 VMware 迁移经验，和大量金融行业核心业务系统支撑实践，可帮助用户同时实现灾备建设、国产替代、信创转型、降本增效多个目标。

推荐阅读：

文章分别刊发于《中国金融电脑》2025 年第 3 期和第 5 期。转自“中国金融电脑”公众号。

继续阅读
微信公众订阅号
扫一扫关注微信，获取最前沿的 SmartX 资讯
资源
获取相关资料
博客
你可能感兴趣