@嘉宾fan系统架构师某城市商业银行：
如果是在线迁移，业务连续性保障的关键环节包括做好各项割接任务、验证新环境的可用性。有几点经验：
3.协调基础和应用服务商调派精干，最好有类似经验的人员到场支持。
4.账务和最重要交易优先内部验证，问题优先解决。影响面较小的业务，如果存在问题，可以评估暂缓处理，恢复对外业务。
5.提前报备和客户公告。
@微笑笑西西某城市商业银行系统工程师：
个人觉得搬迁中业务连续性保障的关键环节是做好搬迁演练工作。
演练旨在为迁移过程中所涉及的各方面资源提供一次互相熟悉与配合的机会，通过演练检查搬迁通道是否顺畅，防范搬迁过程中的数据丢失，验证备份数据是否可用可恢复，实操检验新系统、网络、应用的可用性，充分论证数据中心搬迁方案、步骤、流程、操作、人员分工的合理性，提前查缺补漏，保障业务连续性。
以我行为例，在生产数据中心整体搬迁时安排了针对核心系统的1次实战演练和针对核心、渠道和管理类系统的3次桌面演练。
@czjing某城市商业银行系统运维工程师：
2.梳理业务系统与设备间分配关系。数据中心搬迁说到底就是网络和设备的搬迁，承载业务的设备可能是虚拟化，那依据业务之间的关联关系，可大致梳理出对应的设备、网络条件。对于信息统的逻辑架构，高可用技术、资源等方面都要有足够的把握。需要在前期做好充足的调研和方案的细化确认。这一点也是减少差错需要做的必要工作。
3.人员沟通、测试验证、切换演练等必要的配合测试性的工作。搬迁主体工作一般在运维人员，在搬迁实施前需要对所有待搬迁业务系统搬迁方案、搬迁计划、测试安排、验证计划等逐一完成沟通确认。沟通确认的过程主要是系统开发人员，必要时需要对业务部门作阶段性的通报。切换演练的验证比较重要，这是检验方案有效性的最直接有效的途径，提前解决搬迁过程可能出现的各个问题是保障搬迁业务连续性最直接也最有效的方法。
@金祥东吴证券网络通信队长：
1.生产数据中心和同城数据中心机房之间个人不建议二层互联，既然部署了不同的核心交换机，个人建议走三层网络更为安全；
2.第三个站点与主备数据中心也建议用DWDM裸光纤连接，第三个站点的定位是主中心的扩容，还是同城三中心，不同的需求网络互联的架构也不一样，特别是与第三方或者分支机构的互联模式，是否只保留到主备中心，第三节点只对主备中心有业务数据互联；
3.如果第三机房是短期的使用计划，不想再投入波分设备的成本，使用运营商OTN的光纤高带宽网络也能满足要求，可以租赁1G或者10G以上网络，投入成本低，也为以后新机房的投入使用降低成本。
鉴于场景中搬迁设备为生产设备，建议生产数据中心、同城数据中心和第三数据中心的网络采用骨干环网架构设计。
核心层设备（骨干路由器）部署在主数据中心、同城数据中心和第三数据中心三个节点，每个节点分别有2个站点，安放两台骨干路由器（主数据中心和同城数据中心已有），主数据中心、同城数据中心与第三站点之间通过租用运营商专线解决（以我行为例，租用了2条200M专线）。
为降低线路资费成本，提高分支行网络部署效率与便利性，分支行接入第三数据中心启用4G/5G无线备份线路，采用国密算法进行加密传输，满足了监管部门的要求；不使用不产生流量，从而有效降低广域网线路资金投入。
@笑看风云淡自由IT顾问：
我们知道，理想的网络架构应该类似电信行业的骨干（SDH）环网架构，而且是三个网络节点（生产、同城、异地）物理独立于计算节点，其他中心（例如培训中心、应急指挥中心等）、分支行网络任意接入2个中心即可。然而，这样的投入是巨大的，通常只有全球性银行或大型商业银行才有能力实施，对于非城市商业银行而言，这不是首选方案，它更像是网络架构的理想状态。
异地容灾的有效性在迁移前提前进行规划。
分为数据容灾的有效性和应用容灾的有效性。
我行曾经有过在线进行迁移的经验，供参考：
1.大数据量如何迁移？
2.如何保障过程中的数据安全？
在线同步迁移的方式，主要确保的是数据一致性，通常需要在正式搬迁切割前，有演练阶段。在演练阶段模拟断开数据同步工具，对比源和目标数据的一致性，为了安全起见，可以设计两种以上的验证方案，比如工具自身对同步情况的校验、写脚本查询数据比对等。演练没有问题后，在正式割接的时候执行。
3.如何保障业务连续性？
1.针对海量结构化数据，个人觉得采用的是存储底层复制的方式进行迁移是首选方案具体做法是在新机房购置同样型号/系列存储设备，搭建两个机房之间的存储复制链路（一般是裸光纤），建立存储底层复制关系，将老机房数据先行同步至新机房，搬迁割接时只需要进行应用切换即可，最大程度保障了数据安全和业务连续性。若老机房存储没有同步复制或异步复制功能，可以在上层架设存储网关，通过网关实现海量数据同步。
2.针对海量非结构化数据或海量零碎小文件，通过分布式存储集群的方式解决。海量非结构化数据和零碎小文件一般存储在分布式存储或对象存储，可以在新机房新建分布式存储节点或集群，部署双活分布式存储集群，在割接之前实现海量非结构化数据同步。
1.针对重要信息系统的结构化数据，一般通过数据库或者存储方式完成数据的迁移同步。
数据中心各个业务系统不是孤立的，而是相互关联的。各个节点之间有明确的访问关联关系，对于是否要更换IP，需要基于数据中心网络环境做进一步决策。
个人觉得首选搭建全行级DNS服务的方案。对全行待搬迁系统进行访问方式改造，由原有的IP地址访问改造成DNS域名访问。改造完成之后，搬迁将不受制于IP地址，系统与系统之间访问仅通过域名即可，底层IP可以随意更改，方便日常运维，也最大程度保证了搬迁过程中的业务连续性。
根据我行实际搬迁经验，若采用这种方案，最好在系统建设初期就规划建设了全行级DNS服务，否则就必须要由领导层牵头，自上而下对全行系统进行大刀阔斧改造。若无法搭建全行级DNS服务，则还是采用网络二层/三层打通，IP地址不更换的方案较为稳妥。
个人认为，除非根据网络规划，必须要更换IP地址，才考虑对应制定对应的方案，涉及操作系统、网络和安全、应用一起来讨论制定。如果还涉及到数据库或中间件，则需要更加谨慎，评估修改IP地址后，对软件的正常运行是否有影响，通常需要修改多个配置参数，提前做好手册和测试验证，有些软件可能需要重新安装。
@三虎某国有大行系统运维工程师：
如果在没有全局DNS的情况下，是否更换IP地址可能会产生如下影响：
2.更改IP情况。应用程序及关联的业务系统在技术上或者说在改造成本上是否能容忍。如果应用程序代码中或者配置中使用的是域名访问的形式，那后期调整IP就相对简单。但如果使用IP地址访问，那么哪些程序代码（包含编译后的代码）使用到地址，关联业务系统访问了哪些IP地址，都需要全面排查，漏改一处，都可能导致后续业务中断或某只交易中断（交易触发点不同，隐埋的故障点不定时爆发）。此外，对于一些大行，搬迁的都是老旧系统，原系统不一定还有维护、开发的支持，对地址修改更是难上加难。
数据中心的搬迁，涉及网络（包括IP）是否调整或者优化，最大的考虑点应该是整体的网络规划。数据中心搬迁是全行网络DNS改造的一次重大机会，应当好好把握。至于IP地址是否变动所带来的风险，其实并不是首要考虑的问题，只要做好测试、演练、预案，这些风险都可以有效的降低。
如果是在线搬迁，才需要考虑数据迁移，通常包括以下数据分类：数据库、SAN存储数据、大数据、NAS文件、OSS对象文件、备份类离线数据。
1.数据库通过对应的工具可实现在线同步，割接窗口等待数据同步完成，验证一致性后即可启用。
2.SAN存储的数据，通常是提供给数据库和操作系统(虚拟化)使用，相同品牌也有同步能力，不过我们的做法是通过应用实现，也就是使用数据库的同步工具、虚机迁移工具/在新中心重新部署操作系统及应用。
4.NAS、OSS如果在两个中心是相同厂商，也有同步方案。如果是不同厂商，则NAS需要rsync从操作系统层面来同步，稍微麻烦。
5.备份类离线数据可以评估某些重要的，通过备份软件复制一份至新中心，不太重要的可以直接不用再迁移。
一般NAS数据迁移涉及到NAS数据的存储方式，按照金融机构通用的方式，以使用存储方式的居多。一般数据的迁移通过存储端复制的技术迁移速度更快，但是对源端和目标端NAS设备有品牌、型号和版本的要求，为了满足这个要求可能要对老NAS设备进行版本升级。在这个时候NAS数据迁移是选择使用客户端进行迁移还是通过存储端进行数据迁移,同样是需要考虑的问题。主要的考虑因素如下。
1.存储端的迁移方式
存储端迁移更多依赖存储厂商和存储设备自身的功能，借助存储底层的数据同步功能完成数据迁移，这种方案速度最快相对也最安全稳定，不用担心操作系统和文件系统对存储文件的影响。缺点是源端和目标端NAS设备的要求相同，且都支持存储端复制的技术。价格高同时要考虑设备兼容性。但存储端迁移的收益也比较明显，因为存储端数据迁移的整个过程几乎可以做到用户无感知，业务无感知。且仅在初始数据同步时占用部分存储带宽，后续增量数据的复制数据可以做到实时同步，且可以保证目录及文件的权限无变化。最后仅需要在存储切割时影响业务访问。
2.主机端的迁移方式
@wz99999dcits系统工程师：
综上内容，数据中心机房搬迁在金融行业不乏成熟的实施方案及案例，但套用出适合自己单位内的机房搬迁方案并不容易，因为在搬迁需求、基础环境、业务特性、系统软硬件部署、人员流程管控、领导决策思路等诸多方面存在巨大差异，故制定出适用的搬迁计划还需要经过充分的调研论证，必要的测试验证，领导的支持，不断打磨细化的实施方案，最终整体搬迁落地时，才能事半功倍，达到预期的目标和效果。