云上容灾架构设计与方案

随着医疗、大型企业行业上云步伐的加快，上云后的业务系统安全性如何保障成为客户关注的重点。对于医疗、大型企业客户，往往建有自己的数据中心，如何保障极端情况下业务系统的稳定运行？双活、灾备，能帮到我们！

一、单数据中心架构的隐患

单数据中心的常见架构如下图所示，如果在该数据中心在极端情况下，出现网络全阻、设备掉电全阻等情况，业务可能发生全阻。大型数据中心一般为多路由的网络、电源拉入，出现此类情况的概率极低，但对于医疗、金融等客户，也会带来灾难。

在此架构下，一般建议至少买两台云主机，挂在负载均衡下面，避免单云主机出现业务中断。同时数据库与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、对于普通企业客户，可以选择数据级的灾备方案。