我们随时都可以做演练，不影响生产。现在是针对虚拟化的系统。物理机器难做演练。

几点想法，不妥的地方请指正。传统灾备：中提到的应用级别灾备，存储级别灾备，数据库级别灾备，我觉得用应用系统灾备，存储系统灾备保护，数据库系统灾备保护，这种说法歧异性小，更为合适。SRM 您提到的是VMWARE 的SRM 产品吧，实际上还是做作业流程管理的系统，这个产品并不能替代灾备复制...

我们这次背景项目中的灾备切换是采用了DNS更改的思路来做的。以往参与的项目中也有通过在灾备网络中配置NAT实现的。

基于编排管理软件Kubernetes或DockerEE等软件在LinuxONE上都是完全支持。

用智能DNS，或者全局性负载均衡。像F5就有专门的智能DNS设备，可以按照网络层面的流量按照一定策略就行流量引流，比如按照运营商、客户端区域，IP地址等进行解析，通过规则分发到不同的数据中心。另外还具备探测下一层的链路负载的连通情况，不通，就自动将流量引至其他数据中心。...

瘦核心只是应用架构上的剥离，并不是由集中式一下子过渡到了存粹的分布式基础架构。如果核心系统应用原来支持负载均衡，那么剥离之后继续支持负载均衡，只不过原来是一个系统两种类型业务，现在变为两个系统了。如果核心系统原来的数据库是关系型数据库，不管是RAC还是DB2，剥离之后...

目前GDR现有的版本中不支持自动检测触发切换。所有的切换都是依靠手动触发的。

说实话除了演练，发生应急切换同城或者异地的情况还没有发生过。所以通常不存在需要切换的场景。唯一需要切换那就是系统的所有主机房机器全不可用了，或者是整个机房掉电了。我们不能预测需要切换的场景，但是我们可以做好需要切换的一切准备。假设单中心全部不可用，在这个情况...

民生就是SOA架构，这个痛点是存在的。为了实现减少业务切换的影响，实现多个义务切换。我们从架构上就做好了准备。一方面是切换技术，网络2层打通，切换过程中服务ip可以漂移到同城中心，实现部分系统切换不影响服务。另一方面是建设灾备切换指挥平台，从平台一键切换，实现自动化可视...

多演练