1 部分网络环境。城商行在建设同城灾备时一个主流的方案是大二层网络,拉通的二层一般将网关布在生产站点,自动切换要将二层的网关在同城站点启用涉及复杂路由及安全策略的配置,除非提前经过演练验证并将日常的维护做好记录梳理。如果两个站点是三层对接复杂度会降低。
2数据库的切换。目前oracle db2都有数据库容灾方案,启用备库可以设置成自动化的。但是出于数据一致性的考虑,一般启用备库人工干预的。
3 存储。存储情况比较复杂。如果搭建了同城双活的存储,配合仲裁,存储在两端可以自行管理。基于复制的存储容灾拉起备用存储可以配制成编排好的切换操作,通常不会自动切换。
收起个人觉得这个问题要考虑对这些操作的把控程度,基本上没有操作不能自动化实现。
我们采用的是同城网络大二层打通,存储复制技术(SWAP和STAR模式)实现的大同城小异地的灾备方案, 要进行网络设备、操作系统、数据库、中间件、监控、应用、存储等操作。
无论是主备机房同一个服务IP的方式(要增删服务IP和重新apply集群),还是DNS方案(流程中需要更改DNS服务器中的指向),以及外联只允许一个IP通过防火墙的特殊情况等等,都实现了自动化操作。
建设初期,我们就实现了除同城演练存储SWAP回写步骤之外的所有自动化,只是担心存储回写步骤出现问题导致在同城灾备端通过各种渠道写入的真实业务数据被抹掉而采用了人工操作,经过数次演练验证之后,现在也实现了全自动化操作。
目前,整个灾备演练流程,只有切换流程第一步“确定能否演练切换”和中间的“业务验证”,是人工操作,其他全部自动化操作。