双活数据中心自动化切换的工具平台选型分析.docx

? ? ? ? ? ? ? 双活数据中心自动化切换的工具平台选型分析 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  在双活数据中心架构下，自动化切换的工具平台有哪些选择？自动化切换的前提条件大致有哪些? 问题来自社区会员@scottwa142 大地保险 系统工程师，下文来自twt社区众多同行实践经验分享，欢迎大家参与交流，各抒己见。 * “争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点 @cpc1989 某保险公司 存储工程师： 个人理解是，自动化切换的工具平台需要与数据中心灾备管理工作深度集成，并不是简单使用一套工具就能实现的。灾备自动化切换的工具平台大致需要满足三大功能点： 1.自动化能力，包括集成现有类似Ansible这种的自动化工具，在不同运行环境执行切换命令和脚本 。 2.流程编排能力，灾备切换演练流程能按需编排，需要设立一些检查确认点，子流程之间流程关联等。 3.与CMDB的集成，切换脚本的配置维护，切换前后的配置比对和检查，展示切换过程中的业务数据流的变化等等。 @yongjun ?工程师： 双活数据中心的运行方式，通常有两种，网络大二层打通的方式和隔离的方式。网络大二层打通的方式，可以采用负载均衡的方式，通过软件或者F5实现随机派发，写入同一套双活数据库中（如DB2 PureScale或者Oracle CRS等）。如果是网络隔离的方式，主机房和灾备机房实际上是分开的，数据库是两套，应用也不是负载均衡的方式，在应用端必须实现双写。 在切换时，网络大二层打通的方式按照流程定义的步骤直接停止再启动灾备端应用和数据库以及生产端应用和数据库，来验证单独生产端、单独灾备端能否承载业务；网络隔离方式灾备验证第一步要控制双写的应用的流量，进行流量切换，只写一端，即实现了灾备切换，之后再对应用和数据库进行启停操作，最后进行流量恢复。 更重要的是设计方案，自动化平台可以采用任意的平台，如商用BMC、MicroFocus、开源Ansible等都可以作为自动化引擎，但是需要自行设计流程，如前面“cpc1989”所讨论。 @zhangjunxi570 xjtu 系统分析师： 双活数据中心背景下，业务都改造成在两个数据中心同时对外服务，需要在两个在两个数据中心之间合理分担调度请求端（各种渠道）来的业务请求，因此通常会部署GTM全局负载均衡设备负载流量，同时一个数据中心不能对外服务后调度原来分发到该数据中心的请求切换到存活的站点。 因此双活站点自动化切换首先要能够很好的对接GTM。 要明确一个数据中心故障检测的的标志，一定要准确并且配置一定超时时间。 第三，通常不可能将不可能将所有业务改造成双活模式，双活站点也有主备之分，切换要不要自动化是值得商榷的，需要公司各级领导商讨出一个共同认可的做法的做法。通常切灾备不是自动的不是自动的。 @潘延晟? 系统工程师： 现在信息化的架构越来越复杂。虽说是双活。但是落实到每一个实际的环境中都不一样。从服务器硬件，存储和网络到上层虚拟化和实际应用都不一样。一般来说很难有那种自动化平台可以实现广泛应用。所以基本都涉及到针对实际业务的二次开发，另外，不同的公司环境也不同，信息化的投入。数据中心之间的线路，业务的实际情况，技术人员储备这些都决定双活切换是否成功。 基于以上的原则我觉得双活数据中心更应该注重的是一整套体系流程。而不能只关注双活数据中心架构的技术，因为信息化架构的问题可能是千差万别，自动化切换只能是一个美好的目标，实际环境中可能会因为各种各样的遗漏导致自动化切换失败，所以从整体的架构设计业务流程，故障流程，切换条件以及定期的应急演练。缺一不可。没有最好的自动化切换平台。只有最适合的。 @孙伟光 中国金融电子化公司 IT顾问： 传统双活架构切换，需要事先检查评估切换前环境，定义好各种切换的场景，根据实际场景进行相应的切换动作，其中涉及人员和部门就很多，业务应用，系统管理员，厂商支持人员等等，需要紧密配合和衔接才能更好地完成，切换操作大多数是手工或者脚本化完成。 随着IT技术进步，自动化定制化工具能够解决很多如上问题的弊病，比如切换前环境检查，切换步骤一个个确认，彼此协作沟通需要消耗很多大量繁琐的人力和时间，而且可视化，切换过程一目了然。但是自动化工具往往需要前期根据实际IT基础环境进行大量的开发定制工作，反复模拟演练，最终形成一套完成的自动化工具。 目前有很多专门做自动化切换的工具厂商，各自产品各有千秋，但是自动化切换的前提条件基本上都是一样的。就是按照我们IT基础架构风险评估设计的时候，根据自定义的场景，进行个性开发。虽说是自动化切换，并不是让程序本身自己判断自动切换，最终还是需要人去深度评估后，一键完成自动化切换的整个流程。 参考某厂商的产品： @t