随着医疗、大型企业行业上云步伐的加快,上云后的业务系统安全性如何保障成为客户关注的重点。对于医疗、大型企业客户,往往建有自己的数据中心,如何保障极端情况下业务系统的稳定运行?双活、灾备,能帮到我们!
一、单数据中心架构的隐患
单数据中心的常见架构如下图所示,如果在该数据中心在极端情况下,出现网络全阻、设备掉电全阻等情况,业务可能发生全阻。大型数据中心一般为多路由的网络、电源拉入,出现此类情况的概率极低,但对于医疗、金融等客户,也会带来灾难。
在此架构下,一般建议至少买两台云主机,挂在负载均衡下面,避免单云主机出现业务中断。同时数据库与web、应用服务器不建议放在同一台云主机上,避免互相争抢资源,云端建议买RDS Paas服务,减少麻烦。
二、云上多AZ的应用高可用方案
一些云服务商在同一个城市部署了两个数据中心,中间通过高速的二层网络形成互连,形成了双AZ(可用区)的架构。
1、当可用区1的主用SLB中断时,会将IP地址浮动至可用区2的备用SLB上。该方式是通过BGP路由的动态路由检测来完成。
2、当可用区1的主用ECS全部中断时,主用SLB会将业务流量倒至备用区的ECS。因此高速的二层网络将在此时承担大量的数据流量。
3、当可用区1的主用RDS中断时,也将该主用RDS的ip地址浮动至可用区2的备用RDS库中。
三、线上、线下结合的应用高可用方案
如果希望将公有云及企业自建的私有云进行联动,可以采用如下的系统架构,该方式与双AZ方式有很大的区别。
1、通过智能DNS服务,实时两个SLB的连通性进行检测,当主用SLB中断时,进行秒极的检测,将备用SLB同步至全网的DNS服务器。
2、如果两朵云都是客户自建的,则可以通过高速网络进行二层互通,实现云主机的分组,相互倒流。
3、对于数据库的同步,可以通过数据库自带的脚本,或采用第三方的工具进行数据库的日志级同步。
四、两地三中心的应用双活架构
该架构实际是以上两种方式的结合。双活架构一般是发生是两个数据中心相邻距离不远的场景。如果对于金融级的客户,还会考虑异地的灾备。则采用以下的架构。保障双活的公有云中断时,异地的私有云还能够在一定的时间内接管业务。
五、数据灾备级的容灾方案
对于以上的方案,投入的代价较大,例如需要支付双活数据中心的高速通道费用、相同配置的云主机费用。因此对于一般中型企业,也会提出将数据进行灾备,保障当主用数据中心中断时,原有的私有云能够在几个小时的时间内容逐步恢复业务系统的运行。
该方案实际是企业用得较多的形式,就算业务没有恢复,但数据还在我自己的机房中有备份。
业内的实际方案较多,有基于硬件的灾备一体机,也有纯软件实现的方案。
1、例如下图,本地通过灾备一体机进行数据的压缩、加密、存储,同时在云端也进行一份灾备存储。这样当业务系统中断时,可以选择在云端恢复、或线下私有云恢复。
2、例如下图,也可以通过纯软件的方式进行灾备,直接将备份的文件放下云端、或线下私有云。
这两种方式本质上都是文件级的灾备方案,因此对于数据库等高可靠性的业务支撑不如日志级的数据同步方案。建议将灾备的周期可以设置为一小时及以上,以保障数据库的运行稳定安全。同时为避免数据库在异常情况下无法恢复,建议使用原厂的工具进行数据实时日志级同步,如Oracle DG、Mysql的主从脚本等。
六、小结
1、如果中型企业、资金预算较充足,可以选择双AZ方案、或线上+线下的双活高可用方案。
2、对于金融级客户,可以选择两地三中心的方案。
3、对于普通企业客户,可以选择数据级的灾备方案。