灾备自动化切换平台产品选型以及注意事项

银行在灾备建设中采用的是大同城小异地的两地三中心灾备方案，同城两个机房采用了网络大二层打通的技术，主要目的是实现同城应用双活和系统在任意机房运行，在灾备技术方面，由于行内新核心刚刚上线不久，因此没有采用对应用有改造需求的应用端双活技术，而数据库日志传输技术可能会导致数据丢失，灾难时无法保证RPO=0，因此我们在现有技术栈基础上，采用了改造和影响最少的存储复制技术，虽然在切换过程中需要激活灾备端的各种资源，会导致RTO时间较长，但是可以尽力保证RPO=0。

灾备切换面临的主要问题除保证RPO的前提下尽量减小RTO外，还包括跨部门指挥协调问题、切换流程进度监控问题、以及众多流程的维护问题。灾备切换时要考虑如何解决这些问题，实现安全有序的灾备切换，这样就需要一款能自动化执行、对所有系统的切换流程可以指挥调度的平台。

因此，twt社区平台特别邀请了来自民生银行的灾备自动化的专家分享了：银行灾备自动化切换平台的实践经验分享，希望给大家一定的参考，借此机会希望和大家进行一次交流探讨。以下内容来自本次交流活动的内容总结。

1、灾备自动化切换平台产品选型以及注意事项？

灾备切换面临的主要问题除保证RPO的前提下尽量减小RTO外，还包括跨部门指挥协调问题、切换流程进度监控问题、以及众多流程的维护问题。灾备切换时要考虑如何解决这些问题，实现安全有序的灾备切换，这样就需要一款能自动化执行、对所有系统的切换流程可以指挥调度的平台。现在市场上有哪些比较好的灾备自动化切换平台产品？选型过程中应该考虑哪些问题，需要注意些什么？

回复1：灾备自动化带来的是灾备切换效率的提升，业务RTO减少，人为误操作可能性降低等诸多优势，但是，灾备切换由于可能会涉及到较多的业务系统，业务数据一致性和可用性的要求高，尤其是银行类业务系统，业务类型多，关联关系复杂，实现灾备自动化相对复杂度较高，需要通过业务梳理，权重判定，业务依存关系分析，脚本定制等等繁琐的工作，同时还需要通过实际切换演练，不断优化改进灾备预案。
选择灾备自动化切换平台，建议着重考虑以下几点：

1. 业务系统可以依据用户需求进行灵活定制；
2. 具备模拟灾备切换功能；
3. 提供日志系统和切换回溯功能，发现切换过程中问题所在，并提供改进建议；
4. 友好的图形化用户界面，通过图标拖拽实现复杂系统简单定制。
   以上个人观点，仅供参考。

回复2：个人感觉切换自动化工具技术上来说，跟应急自动化工具，运维自动化工具技术上是一致的，市面上很少有一套即插即用的切换工具平台，原因不是技术，而是各行的数据中心，应用系统，现有监控工具，自动化脚本，自动化工具都存在差异和个性化，所以很多都是在产厂商基本组件或者开源组件基础上自主研发。开源流程编排有activity，自动化工具有ansible，mco，saltstack，都有一些优缺点，需要结合自身特点和需求，选择的组件进行搭建和定制化开发。需要注意的点，除了大家都说到的纬度外，我觉得与日常自动化还有两点差别，一个这个工具开发要考虑真实场景，不只是演练场景。第二要考虑工具自身可用性，要避免工具自身受到故障干扰，工具串接的流程步骤也要容错，比如进入故障中心内部进行操作，这个在真实场景下可能无法成功的。

回复3：由于各个公司业务系统特性不同，IT技术使用各异，很难有一个开箱即用的商业产品能满足要求，都需要在使用过程中总结需求和使用的痛点持续改进。
正如问题所述，解决跨部门协调问题，降低沟通成本，直观展现切换流程，流程数据维护这些都是实际切换过程迫切需求，也是灾备自动化产品选型需要考虑的因素。另外我觉得还需要考虑以下因素：
1 该产品对公司现有IT技术的支持，以及未来发展的支持，如双活技术。
2 该产品性能，是否满足多套系统并行切换的要求。
3 是否满足真实切换和演练功能要求，比如流程单步执行，桌面演练，大屏展现等。
4 系统的可维护性，对于业务系统架构和技术调整，产品的变更是否方便，可追溯。

二、在灾备双活或多活架构中，多系统切换中发生脑裂如何判断并解决的？

背景：灾备体系建设，双活或多活架构
环境：小型机和x86平台，高端存储vmax200，中端存储vnx5500等，数据库db2
现场信息：距离100公里，裸光纤
思考：在灾备双活或多活架构中，多系统切换中发生脑裂如何判断并解决的？
难点：发生站点级别灾难的自动判断依据？

回复1：
1、脑裂主要一般说的是一些部件高可用协议层面，两个节点同时认为自己为主节点。在双活架构下，一般数据中心级别切换一般需要人工介入，全部自动化触发同城切换的案例我还没有见到（一方面监控主要、切换工具自身可能存在故障或者误判，并且概率较发生数据中心故障更高。第二，切换过程也包含风险，切换在部分环节需要人工介入）。人工条件下，一般不存在脑裂，是由人工指定主节点，备节点。在人工介入情况下，确实需要保证故障节点不再承载交易，不然会出现数据紊乱。一般可考虑从源头上封禁导向故障节点的流量，也可尝试在故障节点进行关机操作，但是不一定能够成功。
2、站点级建议从业务交易角度判别，因为技术故障场景很多，对于业务的影响也难以第一时间判断。其次，为了防止业务监控的误判，也独立增加一套独立的监控手段，或者可以通过收集客户反馈进行辅助验证。但是全面、快速、准确的业务影响还是依靠监控，一般业务反馈需要时间，汇总，分析以及精准度问题。

回复2：在灾备双活或多活架构中，多系统切换中发生脑裂如何判断并解决的？
需要第三方进行仲裁,
发生站点级别灾难的自动判断依据？
多级监控判断, 或者人为预警了。

回复3：双活或者多活架构下，当发生数据链路问题时，需要第三方仲裁站点提供脑裂解决方案，通过第三方站点判断是站点间链路问题？还是确实是某个站点发生了灾难。第三方仲裁站点通用的方法是采用仲裁主机，各站点通过iscsi或者其他方式获取仲裁设备。
个人不建议采用自动方式判断站点级灾难，毕竟站点级灾难发生的几率不大，而且决策因素较多，灾备应用软件再怎么智能也不能赋予它决策的功能，否则发生误操作，站点上的业务系统切来切去，搞出的事情就不是简单丢数据了。
个人建议，仅供参考！

三、虚拟化平台的应用级容灾如何实现自动切换？

我司现在所有应用系统都采用了虚拟化技术，现在规划采用存储复制的方式将虚机文件同步到容灾中心，如果主中心出现故障，将采用手工方式启动虚拟化，并通过全局负载均衡实现容灾切换。但不了解如何实现自动方式的切换，并且自动切换是否会带来安全隐患，例如在没有必要切换到容灾中心的情况下出现切换操作。

回复1：做好业务和虚拟机已经 虚拟化的物理机监控,
在监控触发业务故障情况下,进行故障分析, 需要一个elk平台和, 故障分析平台
再次通过监控分析结果触发容灾级别的故障切换,
自动化平台承接底层切换过程, 包括网络和负载均衡设备的配置.
前提示你有业务监控分析和故障分析平台。

回复2：切换虚拟机的方案有两个问题，不知道解决没有，一个是切换后虚机还保留之前的ip？如果保留，在一套网络里面如何解决ip冲突问题。其次，数据复制都有延迟，这些延迟的数据有哪些，业务是否容忍。在真实故障下，可能没有机会再同步数据。个人建议业务连续性要从业务角度考虑，不一定通过应用切换，甚至虚拟机切换去保证。全量虚机进行迁移，步骤复杂，难度大，失败率高，时间长。

回复3：vmware虚拟化的srm方案类似您的方法，通过存储复制进行虚拟机文件同步，切换时进行存储角色切换并拉起虚拟机。
如条件允许也可以考虑存储双活，如emc vplex方案，将容灾的工作交给存储负责，虚拟化层基本无感知。

四、灾备系统数量多，如何保证RTO基础上，既要做到灾备切换过程可控还要提高沟通效率，需求分析应该如何做？

考虑到场景复杂，灾备系统数量多，在确保RTO基础上，既要做到灾备切换过程可控，满足多种容灾场景，还要提高跨部门沟通效率，因此对平台建设的需求分析如何做？

回复1：
1、结合个人的经验，在灾备系统数量较多的情况，应该以业界连续行管理理论作为指导，首先从业务角度进行分级管理，高等级应用优先保证回复，例如达到几十分钟级别，低等级应用可以容忍恢复时间，在几天内完成
2、对于灾容场景复杂，场景较多的情况，如果每个都制定预案，预案多，演练多，成本高。依据个人经验，应进行场景和故障域的整合，例如如果存在整体服务器恢复的预案，则可以不需要过多考虑服务器内部某个组件的故障场景。如果做到一个机房模块的快速切换，可能就需要过多考虑一排机柜的故障。如果做到数据中心级别的快速切换，则不需要针对单独一个机房的故障。

回复2：RTO保障方面可以根据以往的灾备切换经验评估整体和各种场景的切换时间，如果RTO无法保证，可以将业务系统分模块切分，并行切换，同时保证现有模块直接的依赖关系，缩短RTO。
在灾备建设初期就要进行容灾场景设计，容灾场景覆盖大多数真实灾难情况，通过模块化的流程编排满足容灾场景的切换。
灾备建设的一项目标就是提高人员参与程度，降低沟通成本，灾备指挥平台需要实现日常切换过程需要的功能比如集合签到，公告栏，工作台等，对于不同用户设计不同展现视图。

五、银行如何实现业务由生产中心自动切换到灾备系统？自动切换的条件有哪些？如何规划？

回复1：按照系统进行分析, 切换条件和切换业务涉及的应用和内容
网络连接部分按照应用完成切换操作步骤
存储切换按照应用切换顺序进行 规划,完全需要安装切换应用的过程进行 每个业务应用切换,前验证切换条件,后验证切换是否成功 自动切换条件一般 为网络故障,应用无法连接, 存储故障, 数据库连接故障, 物理机的虚拟层故障等,需要监控进行触发, 生产切换到灾备系统需要一个自动化灾备切换软件支持流程操作的系统软件, 支持包括网络和存储接口, 设备接口openstak接口或者vcenter接口, powervc接口, hmc接口, 可包含所有物理机和网络设备以及虚拟设备 规划需要安装自身业务系统进行梳理, 业务系统关联性和网络, 存储关联性进行详细梳理和分布操作 一般金融行业都有灾备切换操作步骤(手工步骤), 安装这个进行详细梳理, 绘制流程图 部署到自动化切换软件中, 可完成大部分人为操作过程, 其它特殊步骤依然需要人为操作。

回复2：首先业务系统灾备投产时已经梳理了整个切换的流程步骤，并且通过灾备指挥平台调用切换成功。切换动作大概分为存储，操作系统，数据库，应用，网络五个部分。存储通过角色swap从主站点切换到灾备站点，操作系统涉及vg,fs,ip,ha等的启停，数据库和应用涉及相应软件的启停，网络通过操作f5 vs member做到流量更改。
切换条件分为日常演练和真实灾难情况，真实灾难可能有网络故障，主机存储故障，站点故障等，针对具体灾难场景梳理切换流程，比如主机故障那么对应主机操作的步骤可以省略，网络故障对应的f5操作可以跳过。

六、自动化切换如何做到涵盖应用？

自动化切换面对复杂多样的应用启停方式，如何做到包含基础设施和应用系统一起的自动化切换？

回复1：应用的灾备切换，这个还是要提前做好应用标准化，比如我行所有系统目前都支持在指定的标准目录使用标准命名脚本实现分步骤或者一键式启停，在实现应用标准化后也能方便接入运维自动化系统方便进行统一的管理。

回复2：应用启停和检查状态的逻辑多种多样，我们是建立一个启停应用的通用脚本，传入应用启停的脚本，用户，进程关键字，端口号，检查脚本等参数，通用脚本放在服务器自动化平台，由灾备指挥平台调用，具体应用的脚本放在服务器本地，由通用脚本调用，这样我们只负责通用脚本的逻辑。对于标准化的应用，比如weblogic应用我们是要求运维人员填写domain路径，log路径，adminserver监听地址，managedserver监听地址，应用关键字（即server的名字），由通用脚本拼接生成启停命令，不需要运维人员自己编写启停脚本，减少工作量，其他如apache,nginx等也可以类似实现。

七、灾备切换如何处理不同级别的应用？

灾备切换如何处理不同灾备级别的应用，而这些不同灾备级别的应用相互之间还有关联？

回复：我理解您说的应用是具体的业务系统，业务系统按照重要程度，灾备级别可能是2:1,2:2或者是双活，目前灾备指挥平台支持上诉场景的灾备切换。
在业务系统灾备上线时，我们会联系负责人梳理参与切换的应用模块范围，尽量保证一个灾备业务系统的闭包，使得应用内部的模块切换不依赖其他应用的切换。如果应用之间确实有依赖关系，我们采用两种方式切换：
1 将有依赖关系的两个或者多个应用作为一个逻辑应用进行切换。但是如果依赖应用过多会导致逻辑应用体量过大，切换时间长。
2 预约切换功能，即灾备切换过程定义具体应用的切换时间来实现有依赖关系的切换。

八、采用存储级同步，双活，还是采用应用的AA模式来实现，是如何考虑容灾方案的？

1 对于容灾方案的选择，民生是如何考虑的？采用存储级的同步技术，双活技术，还是采用应用的AA模式来实现？
2 在您二位关于容灾的设计方案中，容灾的演练（应急手册）是需要实现自动化的。那么这个自动化容灾平台的搭建大致需要多少人力物力？如果我们也想构建一个类似的平台需要什么样的准备？

回复：
1 由于我们灾备建设较早，当时还没有成熟的存储双活技术大规模使用，我们使用的是存储复制技术，目前也在考虑存储双活和双主模式。
2 我们是行内人员投入两人AB岗，负责灾备指挥平台设计和业务系统投产，公司人员负责具体开发，指挥平台的系统变更，运维，包括后期业务系统变更带来的指挥平台级联变更，当然变更后还是要桌面演练核对变更准确和系统负责人确认。
灾备指挥平台的建设我觉得应该首先争取领导支持，全面分析目前使用的技术栈，对灾备使用的技术进行评估，存储双活还是复制？数据库复制还是双活？项目初期明确使用的技术，规范业务系统灾备投产条件，避免以后走弯路；其次，技术方面应该争取技术人员全方面参与，单人的技术能力有限，而灾备往往涉及非常具体的技术细节，从组织架构上保证大家积极参与，避免技术上挖坑；任何灾备变更包括开发都应该全面测试，确保通过功能测试、压力测试。

九、两中心数据同步方式应该如何选择？

在同城数据中心的建设中，两中心的数据同步是个必须解决的问题，选择何种数据同步方式最稳妥，最安全？目前我所在的单位选用的是存储复制技术，正在调研数据库自带的逻辑复制方式，不知道这类技术是否成熟，会遇到哪些问题？

回复1：
1、我看到几个案例是数据库dg+存储复制。数据库复制需要需要分钟级别延迟，存储在同城情况下可以采用最大可用模式，一般情况下实时同步，双中心互联故障下会中止同步，保证主中心交易。
2、数据库自带的复制较为成熟，主要是日常情况rpo较高，但是演练过程中切换或者回切较为简单。

回复2：存储复制技术目前比较稳定，能够保证RPO，存储双活技术也是灾备的未来方向；数据库方面有自身的复制技术，但是切换过程对技术要求较高。

回复3：数据库自带的逻辑复制
用过oracle 的 dataguard.
db2也有类似技术
文件系统建议用 ibm的 cluster file.
因为上面技术都用过最后感觉还是存储复制 运维比较快速部署。

十、银行灾备演练切换频次以及哪些系统进行切换，关联业务如何处理？

灾备切换经验问题，每年民生灾备演练几次，是采用数据中心级的切换，还是单个业务系统切换，有业务关联怎么处理？

回复1：同城的灾备切换是每半年一次，我行是所有系统统一进行切换，如果是负载均衡系统需要进行停单边一周进行业务检验。
异地灾备切换目前是重要信息系统进行切换，每季度进行一次连通性测试。

回复2：按照监管要求，同城业务系统每三年一次，异地每年一次。
对于具体业务系统，我们每年根据变更安排，改造情况定制灾备切换计划，频次高于监管要求。
关联业务系统我尽量安排在同批次切换。