政务云灾备
1. 政策背景
随着各省分政务云的落地,各委办局基本完成了业务系统的迁移上云,但大多数是没有做灾备的,数据安全和业务的连续性难以得到可靠保障,尤其是面向公众的业务系统,一旦系统宕机,后果不可控制。
因此,各省以数据局为首陆续出台关于政务云灾备的要求,以某省为例,今年2月份出台了政务云灾备的指南,要求全省重要信息系统基于政务云实现应用和数据的灾备,第一年试行,不计入考核,预计后续会正式纳入考核范围。
1.1 政策解读
在本地备份基本落实的基础上,灾备的新要求主要是同城容灾和异地备份
同城容灾中心
用户流量按权重分发至主、备(同城容灾)中心,实现业务分担;双中心通过高速链路实时同步数据,保证数据高度完整性;当主中心因意外停止工作时,备中心接管用户流量,保障关键业务正常运行。
异地备份中心
备份软件将主中心关键数据通过电子政务外网复制至全省异地备份中心;当主中心故障导致数据损毁时,可基于异地备份数据进行数据恢复。备份和恢复应支持断点续传和自动重连技术。
异地要求两地中间距离须保证在三百公里以上,同时还必须做到“三不”, 即不在同一地震带,不在同一电网,不在同一江河流域。
当两地距离在100km~ 300km之间时,只能提供机房抵御物理破坏的能力,比如着火断电断网,但是不能有效抵御地震、洪水等级别的灾难。
1.2 灾备分类分级
从省灾备指南的要求来看,对于各委办局一般应用,按等保一二三级来区分,一级无需备份,等保二级和三级的备份要求这里还是给了业务部门很大的灵活性。
对于等保二级,也可以选择不做本地高可用和同城容灾,重要数据选择性异地备份,对于等保三级,同城容灾可以按需选择,本地高可用,本地备份和异地备份还是要做的。
这里可能是考虑各业务部门之前做等保时,没能仔细研究等保要求,导致一些本不需要做等保的系统也一窝蜂都上了,而等保一旦上了再下去就非常困难。针对这种情况,表中对于到底是无特殊要求还是用户范围广且实时性要求较高的系统,评估权还是在业务部门。
从某数管局灾备指南的要求来看,他们对于容灾和异地备份这里做了更具体的指导:
- 在本地高可用和同城容灾中更倾向于本地高可用,而对于同城容灾,只有部分等保三级的系统才要求开通。
- 将异地备份分为定时和连续性两种,高要求的系统需要使用连续性异地备份
1.3 业务连续性目标
1、RTO(Recovery Time Objective)
顾名思义,强调发生灾难时,数据在一定时间内必须恢复。即对同样数据保留两份(一般异地备份),当发生灾难一份数据,通过另外一份数据可以使系统在一定时间内运转起来,不影响客户使用。
2、RPO(Recovery Point Objective)
强调灾难发生后,容忍的数据丢失量。例如有些系统备份数据是每天备份前一天数据,当数据发生灾难需要恢复时,可恢复至前一天的数据,这样当天的数据就丢掉了。
根据上节的业务类别划分,同城容灾和异地备份产品不同的RTO/RPO指标可对应国标GB/T20988-2007的灾备分级,大多数企业的核心应用对标到第五个级别。
2. 技术方案
2.1 同城容灾
运营模式可以分为主备和双活两种形式:
2.1.1 主备模式
即生产节点正常对外提供服务时,同步将数据单项复制到备端数据中心,备端不对外提供服务。一旦生产节点故障,备端生产节点接管服务。
这种模式资源投入较低且技术实施和后期维护相对简单,但是灾后业务恢复速度慢,备端长时间处于待机状态,存在资源浪费情况。且多种潜在因素如心跳中断、网络短时间中断、应用服务器响应不及时等,容易导致在生产节点实际运行正常情况下进错误切换,即存在“脑裂”现象。
为了避免误切换,一般的办法是手动切换代替自动切换,客户需要进行培训来操作灾备软件的使用。
2.1.2 双活模式
双活模式下的两个数据节点分别对外提供服务。一旦一端故障,另一端可立即接管其业务,保障业务的连续性。这种模式相较于主备模式,其业务恢复速度更快,但整体资源投入更大,实施及运维难度更复杂,且存在业务冲突风险。
同城双读(适用只读业务)
主节点负责写入,主从节点均可读取,数据单向同步
优势:
- 部署简单,业务改造成本低
- 同城应用容灾
- 具备切换能力
劣势:
- 只针对只读业务实现容灾能力
- 网络延时带来的一致性问题
同城应用双活(应用广泛)
主从节点均可读写,数据单向同步,即数据库主从,应用双活
优势:
- 部署难度中等,业务改造成本中等
- 同城应用容灾,数据主备
- 具备切换能力
劣势:
- 业务需要能接受跨机房网络延迟
- 距离受限
同城双活
主从节点均可读写,数据双向同步,即应用双活,数据库双活
优势:
- 同城双活,容灾能力强
劣势:
- 部署复杂,成本高
负载均衡方案
- DNS
- 硬件
- 软件
2.2 异地灾备
该省的省级政企云池在某华市,为异地灾备指定资源池,想要做异地备份的委办局都可以发起申请,所以这里不再赘述。