数据中心“搬家”是银行发展历程中的重大事件，当数据中心现有规模不能满足业务的不断拓展，或者技术更新迭代、成本优化、安全合规、机房租赁到期等相关要求发生变化时，数据中心搬迁势在必行。搬迁工作是一次对业务和架构调整的重要契机，在调整中可以提升金融产品服务能力，优化现有系统架构，大幅提升各项资源扩展能力，压缩运营成本以及完成设备老旧更新工作，可谓一举多得。但除了高额成本投入外，数据中心搬迁风险高、难度大，可能对业务连续性造成影响。如何在搬迁中降低风险、避免或减少业务中断时间、保护数据安全及完整性？

　　社区近期组织了”中小银行数据中心整体搬迁实践难点”答疑活动，邀请了社区多位技术专家一同参与线上交流，本文是对“银行业数据中心搬迁实践难点解析”的探讨精华和同行共识的总结，对于搬迁中常遇的难点痛点皆有涉及，希望能为大家提供参考。

　　答疑嘉宾：微笑笑西西 某城市商业银行 系统工程师czjing 某城市商业银行 系统运维工程师fan 某城市商业银行 系统架构师笑看风云淡 自由 IT顾问金祥 东吴证券 网络通信队长

　　如果是在线迁移，业务连续性保障的关键环节包括做好各项割接任务、验证新环境的可用性。有几点经验：

　　1.在正式割接前，多做演练，把割接日的任务细化固化，合理评估每个任务的时间，预留风险处置时间。

　　4.账务和最重要交易优先内部验证，问题优先解决。影响面较小的业务，如果存在问题，可以评估暂缓处理，恢复对外业务。

　　演练旨在为迁移过程中所涉及的各方面资源提供一次互相熟悉与配合的机会，通过演练检查搬迁通道是否顺畅，防范搬迁过程中的数据丢失，验证备份数据是否可用可恢复，实操检验新系统、网络、应用的可用性，充分论证数据中心搬迁方案、步骤、流程、操作、人员分工的合理性， 提前查缺补漏，保障业务连续性。

　　以我行为例，在生产数据中心整体搬迁时安排了针对核心系统的1次实战演练和针对核心、渠道和管理类系统的3次桌面演练。

　　数据中心整体搬迁不可避免的在业务系统割接的那个过程会有系统停机切换的过程，对单个系统来说，可能只有切换的时候需要停机。但从业务角度，一个完整的业务在数据的链路上可能涉及很多业务系统，比如一个简单的手机银行的转账业务操作，可能涉及手机银行、支付系统、核心、网联银联、短信平台等等，因此要最大程度保证业务的连续性，减少停机时间就必须要从数据中心整体上考虑实现，通过多批次切换迁移，完成数据中心的整体搬迁。

　　1.按照业务对业务系统进行划分。一般分为，开发测试、OA办公、管理类、交易类、核心。前两类相对简单，一般在合适的时间段整体停机搬迁即可，不会对生产业务产生影响。但管理、交易和核心类三个大类业务需要仔细考虑，从减少业务停机的角度考虑，需要梳理清楚各业务系统之间的关联关系，主要是重要业务在各个系统之间的调用关系，这个任务比较繁琐但有必要。将强关联的业务系统在同一批次切换迁移，可大大减少业务的停机时间，提高业务连续性。

　　2.梳理业务系统与设备间分配关系。数据中心搬迁说到底就是网络和设备的搬迁，承载业务的设备可能是虚拟化，那依据业务之间的关联关系，可大致梳理出对应的设备、网络条件。对于信息统的逻辑架构，高可用技术、资源等方面都要有足够的把握。需要在前期做好充足的调研和方案的细化确认。这一点也是减少差错需要做的必要工作。

　　3.人员沟通、测试验证、切换演练等必要的配合测试性的工作。搬迁主体工作一般在运维人员，在搬迁实施前需要对所有待搬迁业务系统搬迁方案、搬迁计划、测试安排、验证计划等逐一完成沟通确认。沟通确认的过程主要是系统开发人员，必要时需要对业务部门作阶段性的通报。切换演练的验证比较重要，这是检验方案有效性的最直接有效的途径，提前解决搬迁过程可能出现的各个问题是保障搬迁业务连续性最直接也最有效的方法。

　　总的来说，就是从业务关联系，方案有效性、资源保障等各个方面保障搬迁的业务连续性。重视搬迁前的各类事项的沟通，工作细化到人和具体的事项，提供必要的资源完成方案的测试验证。以笔者参与过搬迁案例来说，搬迁分为三个大批次，每个批次内业务系统完成关联性分析后，对各个系统作迁移方案的仔细评估和完善，在按照计划完成系统搬迁。

　　1.生产数据中心和同城数据中心机房之间个人不建议二层互联，既然部署了不同的核心交换机，个人建议走三层网络更为安全；

　　2.第三个站点与主备数据中心也建议用DWDM裸光纤连接，第三个站点的定位是主中心的扩容，还是同城三中心，不同的需求网络互联的架构也不一样，特别是与第三方或者分支机构的互联模式，是否只保留到主备中心，第三节点只对主备中心有业务数据互联；

　　3.如果第三机房是短期的使用计划，不想再投入波分设备的成本，使用运营商OTN的光纤高带宽网络也能满足要求，可以租赁1G或者10G以上网络，投入成本低，也为以后新机房的投入使用降低成本。

　　鉴于场景中搬迁设备为生产设备，建议生产数据中心、同城数据中心和第三数据中心的网络采用骨干环网架构设计。

　　核心层设备（骨干路由器）部署在主数据中心、同城数据中心和第三数据中心三个节点，每个节点分别有2个站点，安放两台骨干路由器（主数据中心和同城数据中心已有），主数据中心、同城数据中心与第三站点之间通过租用运营商专线解决（以我行为例，租用了2条200M专线）。

　　为降低线路资费成本，提高分支行网络部署效率与便利性，分支行接入第三数据中心启用4G/5G无线备份线路，采用国密算法进行加密传输，满足了监管部门的要求；不使用不产生流量，从而有效降低广域网线路资金投入。

　　我们知道，理想的网络架构应该类似电信行业的骨干（SDH）环网架构，而且是三个网络节点（生产、同城、异地）物理独立于计算节点，其他中心（例如培训中心、应急指挥中心等）、分支行网络任意接入2个中心即可。然而，这样的投入是巨大的，通常只有全球性银行或大型商业银行才有能力实施，对于非城市商业银行而言，这不是首选方案，它更像是网络架构的理想状态。

　　对于城市商业银行来说，现阶段网络实现三活（三区、三域，单中心内冗余且负载均衡。整个对外服务由智能DNS负责）同城DWDM大二层打通已经可以了。

　　我觉得有两种选择，一是异地容灾维持有效直到迁移割接，二是异地容灾提前一段时间失效而接入新中心。综合考虑 异地容灾是否作为迁移的最后保障手段、异地容灾重新搭建对新中心的风险性 等因素来选择。如果同城还有另一个中心在运行，为了降低新中心启用后搭建灾备的风险，可以选择第二种。重大的搬迁，一般可能会选择第一种，防止迁移过程或割接过程中，目标和源数据中心都出现不可用，且不可回退的时候，还有最后的保底。

　　首先数据容灾方面，一是存储级数据同步，这种方式相对简单，只需要在新数据中心先行建立好与原数据中心、异地灾备中心的存储级三点复制关系(MM或GM)，搬迁割接的时候将新数据中心存储置为主存储，拉起数据即可；二是数据库级数据同步，这种方式需要在搬迁割接时删除和重建数据库同步关系。以我行DB2 HADR为例，搬迁前在新数据中心新建DB2数据库并导入搬迁前某一临近时点数据，割接时通过日志回滚恢复原库，同时建立新数据中心与异地灾备中心的HADR复制关系，由于存在配置删除与重配的过程，这种情况的割接时间窗口会比较长。若分布式数据库（如TDSQL），则可以有效减少搬迁切换时间。

　　其次是应用容灾，一是非集群部署，这种情况在搬迁割接时需要经历原数据中心整体下线、新数据中心整体上线的过程，风险较大；二是集群部署（包括分布式微服务、虚拟化集群、应用集群/双活等），可将新数据中心应用加入原有集群或新建集群，通过负载均衡流量配比的方式进行割接，这种情况可在搬迁后快速恢复业务，并可复用原有灾备方案，为应用容灾方案首选。

　　通常情况下，商用的大数据、数据库都有数据同步工具，区别是数据库同步工具可以准实时同步，大数据的同步工具一般是固定时间增量同步。大数据的同步时长，与中心之间带宽、同步并发数等有关系，需要关注不断调优。

　　在线同步迁移的方式，主要确保的是数据一致性，通常需要在正式搬迁切割前，有演练阶段。在演练阶段模拟断开数据同步工具，对比源和目标数据的一致性，为了安全起见，可以设计两种以上的验证方案，比如工具自身对同步情况的校验、写脚本查询数据比对等。演练没有问题后，在正式割接 的时候执行。

　　如果数据量大，通常还是需要数小时到天级别的割接窗口，源端停止业务，确认没有数据写入后，等待增量数据同步完成，然后开展数据一致性的验证，验证没有问题后，才能启用目标数据。这个窗口时间要多长，可以在演练阶段确定。

　　1.针对海量结构化数据，个人觉得采用的是存储底层复制的方式进行迁移是首选方案具体做法是在新机房购置同样型号/系列存储设备，搭建两个机房之间的存储复制链路（一般是裸光纤），建立存储底层复制关系，将老机房数据先行同步至新机房，搬迁割接时只需要进行应用切换即可，最大程度保障了数据安全和业务连续性。若老机房存储没有同步复制或异步复制功能，可以在上层架设存储网关，通过网关实现海量数据同步。

　　2.针对海量非结构化数据或海量零碎小文件，通过分布式存储集群的方式解决。海量非结构化数据和零碎小文件一般存储在分布式存储或对象存储，可以在新机房新建分布式存储节点或集群，部署双活分布式存储集群，在割接之前实现海量非结构化数据同步。

　　一般来说，几个T或者十几个T的数据不算很大了，一般上百个T的数据量才算特别大的数据量。以笔者的经验来说，一般重要的信息系统数据量类似核心一般几个T数据量，外围关联的相关系统也以10T以内的数据量为多。

　　标准数据库数据目前对于数据同步和复制都有比较成熟的方案。对于底层网络和存储具备复制条件的可以通过使用存储同步方式完成。简单来说就是在新的数据中心配置好与原机房同等配置的存储环境，打通存储复制的链路，通过存储自身完成数据的迁移和同步，这种同步是实时的，搬迁的时间点停掉原数据中心业务后，起用新机房的数据即可，典型的实现方式使用存储网关。这种实现方式操作简单，对业务影响较小，但成本相对较大，存储的灾备体系需要硬件体系的支撑。数据库复制的方式即通过数据库多副本的方式完成数据到新数据中心的复制同步，操作相对复杂，但投入较小。

　　这类系统数据量很大，且分布分散，在短时间的窗口内很难完成整理数据的迁移。因此为降低迁移对业务系统本身的影响，通常的做法是考虑如何在不影响生产的情况下进行数据的迁移。目前这类系统数据目前都在进行对象分布式存储的改造，以笔者的经验来说，可考虑在新数据中心搭建新的分布式存储和应用，这样原数据中心的系统不需要做任何变更。对于系统新产生的数据直接写入到新存储中，保证原系统不在产生新数据。对于原来的海量数据，则通过适当的方式慢慢完成迁移，待所有数据迁移完成后即完成了业务系统的整体搬迁，整个数据的迁移过程源端数据是可以对外提供访问服务的，因此业务系统并不会中断。

　　5、数据中心搬迁，业务系统IP地址与不更换两个方案的优缺点，对于中小城商行采用哪个方案更为合适？

　　数据中心各个业务系统不是孤立的，而是相互关联的。各个节点之间有明确的访问关联关系，对于是否要更换IP，需要基于数据中心网络环境做进一步决策。

　　1.对于数据中心有统一但是DNS服务端方案网络环境来说，是否更换IP都是可行的方式，各有优劣。更换IP，意味着有更充足的时间对新系统作测试验证等，在完成所有准备工作后通过更换DNS的域名解析完成信息系统的割接，整个过程只需要保证整个数据中心一份完成DNS域名解析记录即可，如果切换失败还可通过更改DNS记录完成业务系统的回退。不更换IP，则不需要更新域名解析，但是需要再业务系统进行切换割接时，完成新旧信息系统节点的IP地址互换。

　　2.对于没有统一DNS域名解析服务的网络来说，还是不要更换IP了。要不然网络策略相关的梳理工作将是巨量的，且很容易出现纰漏。所有原IP具有的网络策略在新IP上都需要开通准备。所以这种环境通用的做法要么是接搬迁的机会完成网络环境统一DNS改造，要么就采用不更换IP的方式完成应用系统的迁移。

　　个人觉得首选搭建全行级DNS服务的方案。对全行待搬迁系统进行访问方式改造，由原有的IP地址访问改造成DNS域名访问。改造完成之后，搬迁将不受制于IP地址，系统与系统之间访问仅通过域名即可，底层IP可以随意更改，方便日常运维，也最大程度保证了搬迁过程中的业务连续性。

　　根据我行实际搬迁经验，若采用这种方案，最好在系统建设初期就规划建设了全行级DNS服务，否则就必须要由领导层牵头，自上而下对全行系统进行大刀阔斧改造。若无法搭建全行级DNS服务，则还是采用网络二层/三层打通，IP地址不更换的方案较为稳妥。

　　个人认为，除非根据网络规划，必须要更换IP地址，才考虑对应制定对应的方案，涉及操作系统、网络和安全、应用一起来讨论制定。如果还涉及到数据库或中间件，则需要更加谨慎，评估修改IP地址后，对软件的正常运行是否有影响，通常需要修改多个配置参数，提前做好手册和测试验证，有些软件可能需要重新安装。

　　如果搬迁涉及的操作系统较多，最好是IP地址保持不变。减少搬迁后的恢复时间，减轻调试工作量。特别是生产系统的话，降低交易出错的概率。

　　1.不更改IP情况。IP地址一般是跟着VLAN，或者说是二层的网络交换机一起的变更的，如果一个交换机下的相关联业务系统整体搬迁，即网络、系统集体搬迁的话，正常不用变更原系统IP，但实际上这种场景操作难度大，一组网络交换机涉及业务系统范围较广，是否能协调到相同的停机时间窗口，是否能有相同容忍的停机时间，比较难凑到一起。此外，对原系统先重建，再切换的搬迁方式，基本是必须修改IP地址。

　　2.更改IP情况。应用程序及关联的业务系统在技术上或者说在改造成本上是否能容忍。如果应用程序代码中或者配置中使用的是域名访问的形式，那后期调整IP就相对简单。但如果使用IP地址访问，那么哪些程序代码（包含编译后的代码）使用到地址，关联业务系统访问了哪些IP地址，都需要全面排查，漏改一处，都可能导致后续业务中断或某只交易中断（交易触发点不同，隐埋的故障点不定时爆发）。此外，对于一些大行，搬迁的都是老旧系统，原系统不一定还有维护、开发的支持，对地址修改更是难上加难。

　　总结来看，对于一些非关键系统，允许整体搬迁，允许同业时间相对较长（5*9业务，允许整个周末进行搬迁的），可使用不更换IP形式。对于关键核心系统，考虑采用“腾挪”的方式，即采购新设备在新位置重建，业务系统重新部署测试，新老业务系统切换，再对老系统设备下线。下线的原设备可回归到新资源池中减少浪费。

　　数据中心的搬迁，涉及网络（包括IP）是否调整或者优化，最大的考虑点应该是整体的网络规划。数据中心搬迁是全行网络DNS改造的一次重大机会，应当好好把握。至于IP地址是否变动所带来的风险，其实并不是首要考虑的问题，只要做好测试、演练、预案，这些风险都可以有效的降低。

　　考虑到各行网络架构的发展历程，技术力量、维护能力等因素都各不相同，其实没有最完美的方案，仅有最适合自己的方案，关键是找到最符合自身实际需求的解决策略。个人观点，仅供参考。

　　如果是在线搬迁，才需要考虑数据迁移，通常包括以下数据分类：数据库、SAN存储数据、大数据、NAS文件、OSS对象文件、备份类离线.数据库通过对应的工具可实现在线同步，割接窗口等待数据同步完成，验证一致性后即可启用。

　　2.SAN存储的数据，通常是提供给数据库和操作系统(虚拟化)使用，相同品牌也有同步能力，不过我们的做法是通过应用实现，也就是使用数据库的同步工具、虚机迁移工具/在新中心重新部署操作系统及应用。

　　3.大数据看厂家是否有迁移工具，有些没有，或者很费劲，则考虑提早在新中心部署完成，两个中心并行抽数处理一段时间。

　　4.NAS、OSS如果在两个中心是相同厂商，也有同步方案。如果是不同厂商，则NAS需要rsync 从操作系统层面来同步，稍微麻烦。

　　5.备份类离线数据 可以评估某些重要的，通过备份软件复制一份至新中心，不太重要的可以直接不用再迁移。

　　一般NAS数据迁移涉及到NAS数据的存储方式，按照金融机构通用的方式，以使用存储方式的居多。一般数据的迁移通过存储端复制的技术迁移速度更快，但是对源端和目标端NAS设备有品牌、型号和版本的要求，为了满足这个要求可能要对老NAS设备进行版本升级。在这个时候NAS数据迁移是选择使用客户端进行迁移还是通过存储端进行数据迁移,同样是需要考虑的问题。主要的考虑因素如下。

　　存储端迁移更多依赖存储厂商和存储设备自身的功能，借助存储底层的数据同步功能完成数据迁移，这种方案速度最快相对也最安全稳定，不用担心操作系统和文件系统对存储文件的影响。缺点是源端和目标端NAS设备的要求相同，且都支持存储端复制的技术。价格高同时要考虑设备兼容性。但存储端迁移的收益也比较明显，因为存储端数据迁移的整个过程几乎可以做到用户无感知，业务无感知。且仅在初始数据同步时占用部分存储带宽，后续增量数据的复制数据可以做到实时同步，且可以保证目录及文件的权限无变化。最后仅需要在存储切割时影响业务访问。

　　一般情况都是主机端进行迁移，因为一般都不是同一品牌的，即使是统一品牌，估计新旧存储的双活兼容也不容易。为了尽量减小对生产环境的影响，在实施过程中尽量避免安装额外的工具客户端，使用系统自带的rsync工具文件同步的方式完成迁移。rsync同步过程需要考虑的因素包括文件权限、网络带宽占用、增量同步的时间间隔，NAS存储切割时间点的数据校验等。总体需要人工控制的因素较多，因此实施过程会相对复杂，且对生产环境带来一定影响。有实施案例中，rsync同步过程因为碎文件较多，在未限制同步带宽的情况下因长时间占用带宽影响其他业务系统访问性能的问题，后续通过带宽限制解决，带宽限速又会大大延长同步的时间。

　　综合以上，在有条件选择存储端同步的情况下有限选择存储端同步。如若不可，在主机端同步需要充分考虑同步过程数据的一致性、文件及目录的权限、对生产环境带来的可能影响等内网如何查看代理服务器ip，做好应急预案。避免出现问题时，长时间影响业务的情况发生。在进行数据迁移之前，需要进行充分的备份和测试，以确保数据的完整性和可靠性。同时也需要注意数据的安全性和隐私保护，避免数据泄露和丢失。

　　前期我们对数据中心整体搬迁的准备工作和注意事项进行了全面的剖析，本期聚焦于搬迁实践中的难点痛点问题逐个深入分析，总结来看包括了关键信息梳理、降低中断风险、全局视角规划、容灾备份验证、数据在线、关键信息梳理

　　网络互联关系梳理。搬迁其实是对设备的搬迁，故需明确物理架构下生产业务网、存储网（FCSAN或IPSAN）、带外管理网、心跳网等各网络内的互联关系，需具体到网络设备与对端设备的具体端口。需特别强调的事，端口信息不能依赖于设备、线缆上的标签，这些在初期或后期调整中都可能出现错误，故登记后的信息要与设备上识别到的唯一标识码（WWN、MAC）比对，此外该工作需双人复核进行，确保登记信息准确，搬迁后端口的互联正常。

　　业务地址变更评估。如果需要变更IP地址，在有全局DNS的情况下，更换IP地址的代价、难度及影响较小。对于没有DNS的情况下，更换IP地址要评估是否支持更换地址，更换地址带来的应用程序的配置、代码内容调整工作量，后续的测试验证工作量，以及原IP地址策略在新的网络域中重新打通的工作量。故调整IP存在工作量大，修改易遗漏，风险高等问题，将给系统运行带来诸多不确定性。在非极端场景下，都不建议调整原系统的IP地址。

　　划分不同批次搬迁。根据业务停机时间窗口不同、互联关系不同等分批次搬迁，优先进行5*9业务或非对客类业务的搬迁，对互访关系多、数据交互密集等强关联的业务系统同批次搬迁。

　　系统重构改造。全盘考虑搬迁对现有科技架构调整的影响，也是一次重新调整的契机，借此机会考虑系统在物理架构、逻辑架构是否要调整，在功能性需求和非功能性需求上是否要完善扩充。

　　数据迁移的方法。底层数据级同步，依赖于各家存储软件，如分布式集群内数据同步跨中心的存储级复制工具；因存储异构、软件成本等因素未使用存储级复制的，可使用应用层数据传输工具，具体如rsync、oracle DG、OceanBase OMS、Hadoop Sqoop等开源或商用工具，属于系统层通用或特定应用程序自带软件，成本低，使用管理上稍复杂，但可以确保数据对应用的完整可用性。

　　综上内容，数据中心机房搬迁在金融行业不乏成熟的实施方案及案例，但套用出适合自己单位内的机房搬迁方案并不容易，因为在搬迁需求、基础环境、业务特性、系统软硬件部署、人员流程管控、领导决策思路等诸多方面存在巨大差异，故制定出适用的搬迁计划还需要经过充分的调研论证，必要的测试验证，领导的支持，不断打磨细化的实施方案，最终整体搬迁落地时，才能事半功倍，达到预期的目标和效果。