金融行业数据中心的双活实现方式应该如何选择?这是一个很大的问题,其里面包含的众多技术以及相应的解决方案,虽然不至于如过江之鲫但也算得上是花团锦簌了。
那么我们一直在讨论双活技术,双活解决方案的时候,我们是否考虑过什么样的业务才最适合双活呢?难道仅仅是为了灾备而搭建双活数据中心么?双活与两地三中心的区别又在哪里呢?
1,两地三中心同时包含灾备和双活,两地的数据中心实施的是灾备,同城的两个中心实施的是双活。
2,灾备和双活是业务连续性管理中不同层次的要求,应对不同级别的故障;灾备面对的区域性灾难(地震,海啸,战争等)以及特别重大的信息系统故障(我们启动DR的条件是预计48小时内无法恢复业务),灾备恢复一般是有损的,比如不会覆盖所有的渠道,不会覆盖所有的业务类型等,毕竟是出现了这么大的事件;但DR基本上是千年等一回的情况,对于一些局部性的灾难(火灾,停电等)以及相对轻微的信息系统故障,不能花那么大的代价来启动DR,因此才提出双活概念。
3,适用于双活的业务系统一般来讲都是对客服务类的业务,内部经营类的一般就不做双活了,成本高且技术也比较复杂。
抛却形形色色的双活技术,不外乎是为了两个目的RTO,RPO:一,数据同步,不丢数据。 二,快速切换或者无切换,提高系统可用性。还有说为了提高资源利用率的,但这个基本已经不是关键的考虑点了。所以应用就是在灾备发生时,对RTO和RPO要求比较高的应用。银行的重要系统RPO几乎都要求是0。所以RTO是应用的选择考虑点。 这么筛选,大概所有的应用都符合了把:)所以还要从双活的技术特点,或者说是限制去筛选。因为距离对性能是有影响的。尤其是对于写操作。所以第二个考虑是读写比,双活适合读写比高的应用。粗略筛选基本是这样。
1:根据CVP理论,不同业务对双活的适用性会有一定差别,通常而言性能要求较低或者数据一致性要求较低的应用,较容易实现双活,如网站类应用较容易实现远距离双活。而对性能或数据一致性要求高的应用使用双活结构的时候则需要在距离上做出一些平衡与牺牲,例如一般交易类应用,多数采用同城双活。
2:一般而言,双活反应的是业务分布式处理的要求,双活最初的诉求是在国际上的大型企业需要跨区域进行业务访问、处理、支持的场景下提出的。在近几年实际工作中,双活模式很多情况下反映出更加明显的灾备特性,大多数客户选择双活是为了在传统灾备的基础上获得更好的RTO,并且更好的利用灾备资源,从而将灾备与双活进行了挂钩。
3:双活与两地三中心,在灾备领域同属于数据中心分布于定位策略的话题。大多数客户谈的两地三中心,是指同城双中心加异地中心构成的两地三中心结构,同城中心应对小规模灾害性事件,异地中心应对大规模灾害事件。而双活在灾备领域里指的是数据中心的业务状态,两地三中心建设中,如果采用同城双活,通常意味着同城两中心使用双活架构完成灾备建设并实现业务负载同城分布,异地中心与同城双中心间则采用传统主备方式完成灾备建设。