业务连续管理-双活

前面吹了那么多，一个灾备系统的建设重点肯定是策略的制定，今天就来聊一聊（忽悠忽悠 ）

即然是制定策略肯定是有输入的那么输入主要是以下几个层面：

1、现有业务系统和IT基础的风险分析，一般就是说：冗余怎么做的，数据保护层面，针对人员的运维层面会不会出现有删库到跑路的可能性，机房弱电层面，保洁大妈会不会把机柜的电源碰掉之类的。

2、业务影响分析：对现有应用系统的关联关系梳理，罗列出来应用保护的等级，尽量可以实现业务系统发生灾难后可以在灾备中心恢复所有需要恢复的应用，避免发生灾备中心可以恢复A-C-D-E发现B没做灾备，还得回头来访问生产中心？你说惊不惊喜。

3、BCM的建设规范，行业监管要求：银行业就是104号文件，其它行业有iSO的22301规范可以遵从，满足以上就打60分啦，同业的经验都是民营银行向民营银行看齐，城商行向城商行看齐，很少有像宇宙第一大行看齐的，因为看齐了太贵。

4、IT发展战略：就看企业未来的发展战略，比如：上云，超融合，都可以在灾备里实现，灾备嘛平时都是备着的，发生灾难的时候才启用。当然双活就是另当别算了，双活也是生产了所以双活基本和生产的模式类似了。

5、从成功的层面考虑可以混合云的模式是最优成本了，可以平时生产运行当灾备发生的时候切换至公有云，公有云平时只购买存储空间发生灾备的时候才会消费计算资源，当然这种模式的RPO与RTO起码都是小时级甚至是天级。

接下来我们来聊一下灾备系统的建设策略吧：

双活数据中心的建设策略：

如上图所示：数据中心的双活一般是应用层，数据库层基础架构方面：就是应用负载层，网络连接层，虚拟化层，数据库层。

我们分别来聊一下：

应用层：应用负载一般采用DNS和负载均衡配合的方式来进行，当然土豪用户就是买商用产品，比较注重性价比的就买开源的互联网产品（diaosi User）当然如何区分应用是否可以实现负载一般就是无状态，短链接应用的，在本地没有数据应用都是Log，这种模式的应用不需要考虑数据的一致性（多台服务器共享NFS）现在这种应用模式也比较流程比如容器什么的都是应用这一类应用的。

数据库层面：数据库是最关键的80%的资产和数据都部署在数据库，原有的数据库灾备大多是存储复制比如：SAN Copy，NetApp SnapMirror,后来双活大行其道就是EMC的VPlex

HDS的G1000等，这几年做项目比较多的就是用Oracle的ADG或者第三方：DSG或者九桥，这两个证券用的特别多。

虚拟化层面：虚拟化这个复杂，上面运行的应用即有应用的，还有数据库（MYSQL，SQL Server等）所以我们一般建议采用虚拟机的容灾方案，比如通过SRM+存储复制，或者虚拟机的复制（vSphere Replication+SRM）或者第三方的虚拟机复制（Zerto Veeam）当然还有我们的CloudDP

其它：主要就是就是非结构化数据：影像，后督系统这些大多存储的NAS上，大多是通过NAS数据的复制来实现的。

所以应用对应DNS，负载的解决方案。

数据库：对应存储，ADG的解决方案

虚拟化同时应用存储，虚拟机复制，应用负载，数据库容灾。。。。。。

网络层面：咳咳，连通即可你是DWDM二层打通还是通过专线连通都行，没了（欢迎网络砖家拍我哈）

每种方案都有自己的优劣性，比如上中下全部打通的双活比较适合输不起的土壕，基本可以做到0 RPO 分钟级的RTO，这种已经是我们能想到的最低的了。

也有用户采用众家之所长，即有F5+DNS这种把应用层打通的，存储也不差钱做了MetroCLuster，数据库又做ADG的，我们去年就在某商业银行做过也是超级土壕类型啦。

还有好多是应用层双活。。。就是通过F5,DNS把应用都连通了，数据库还是访问一边，再通过ADG去做主从复制，这个适合差钱要面子用户。

也有用户玩多活的，应用在多地负载，数据库采用MYSQL这种多主从复制方式的，到时候他们的业务逻辑得多复杂啊，这种当自己是阿里的我们就说是追求技术极限用户吧。

虚拟化+应用负载双活

土壕MetroCLuster双活，再加一个RP EMC就得给鸡腿了。

应用负载+存储双活+跨站点RAC+ADG+虚拟机复制+SDN（这个是东北人设计的，乱炖吃的多）

综上所述： 各个厂商都有自己的方案，每个灾备策略也都有其特点，各位甲方大爷在和厂商沟通的时候呢也是被各种忽悠，最后抱着一个老王卖的大西瓜乐呵呵回家。

但是灾备中心的建设并不是为了购买一大堆的硬件盒子，中心思想不能够恢复的灾备中心都是耍流氓，我们建设灾备系统肯定还是要为业务负责的。

所以： 还是要找一个专业的服务商和靠谱的人来落地。