njtukang

切换虚拟机的方案有两个问题，不知道解决没有，一个是切换后虚机还保留之前的ip？如果保留，在一套网络里面如何解决ip冲突问题。其次，数据复制都有延迟，这些延迟的数据有哪些，业务是否容忍。在真实故障下，可能没有机会再同步数据

个人感觉切换自动化工具技术上来说，跟应急自动化工具，运维自动化工具技术上是一致的，市面上很少有一套即插即用的切换工具平台，原因不是技术，而是各行的数据中心，应用系统，现有监控工具，自动化脚本，自动化工具都存在差异和个性

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

1、生产网和灾备网隔离，想转变到双活数据中心，关键问题在应用上，只要应用支持，网络层可以让生产网和灾备网打通。这个不是技术困难，只要在数据中心架构设计时定好 ，定好原则就行2、同城网络上有大二层的方案，可以便于应用部

1、脑裂主要一般说的是一些部件高可用协议层面，两个节点同时认为自己为主节点。在双活架构下，一般数据中心级别切换一般需要人工介入，全部自动化触发同城切换的案例我还没有见到（一方面监控主要、切换工具自身可能存在故

1、提高系统可用性，这个话题几乎涉及到it的各个阶段和环节，包括业务需求、系统设计、软件开发、软件测试、生产运维。也就运维人员至少需要架构设计阶段介入，对于系统高可用设计以及应急切换方案进行把控。个人理解最重

1、结合个人的经验，在灾备系统数量较多的情况，应该以业界连续行管理理论作为指导，首先从业务角度进行分级管理，高等级应用优先保证回复，例如达到几十分钟级别，低等级应用可以容忍恢复时间，在几天内完成2、对于灾容场景复杂，场