?随着互联网业务快速发展多IDC嘚业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行今天为您介绍一下到底这是什么？
其中两地是指同城、异地；三中心是指生产中心、同城容灾中心、异地容灾中心
在早期，比较典型的是国内外银行多采用“两地三中心”建设方案这种模式下，多个数据中心是主备关系即存在主次，业务同安排同部署同落实优先级存在差别针对灾难的响应与切换周期非常长，RTO与RPO目标无法实現业务零中断资源利用率低下，投资回报无法达到预期两地三中心本质上是一种通过简单资源堆砌提高可用性的模式，对高可用的提高、业务连续性的保证仍然只是量变业务连续性及容灾备份一直没有实质性的跨越。
目前以银行为代表的、包括政府、公共交通、能源电力等诸多行业用户，开始将关注点转向“分布式多活数据中心”
通过双活的方案具有两类特点。
一是多IDC中心之间地位均等在正常模式下协同工作，并行的为业务访问提供服务实现了对资源的充分利用，避免一个或两个备份中心处于闲置状态造成资源与投资浪费，通过资源整合多活数据中心的服务能力往往双倍甚至数倍于主备数据中心模式；二是在一个数据中心发生故障或灾难的情况下，其他數据中心可以正常运行并对关键业务或全部业务实现接管达到互为备份的效果，实现用户的“故障无感知”复制代码
结合公司目前的業务运营情况，IDC机房主要在xxxx,xxx,同时在xxxx区域同安排同部署同落实有一些IDC机房其中数据中心主要以xxx为主，所以在两地三中心方案中同城双活較为符合发展的趋势。
而两地三中心方案的设计不光需要数据库层基于分布式进行改造，同时在业务层系统层，网络层都需要相关的方案适配
两地三中心的设计原则为同城双活，异地容灾其中同城暂定为HB30,HB21,异地容灾暂定为华中或华东的IDC节点
改造设计需要和业务端进行密切配合，从业务场景出发选择合适的方案
考虑跨机房的支持需要引入consul方案，实现service_name的高可用管理
同城双活的数据要求为最终一致性异哋容灾暂不对业务开放，在30分钟内可以快速恢复业务
可以设定短期目标和长期目标短期目标可以充分借助开源红利和业务场景进行落地，在落地过程中不断的迭代改进；长期目标可以选择更为通用技术挑战较大，业务效果好的方案（如异地多活）
为了确保方案的有效，需要定期进行演练
两地三中心方案中基于设定的短期目标可以明确同城双活和异地容灾的方案组合。
则设计重点为同城双活即在同城的数据中心之间，一般通过高速光纤相连在网络带宽有保障的前提下，网络延迟一般在可接受范围内两个机房之间可以认为在同一個局域网内。
在设计上可以和应用层结合起来有两种同安排同部署同落实模式：分为应用层双活和数据库双活，应用层双活和数据库单活
应用层双活，数据库单活：两个机房的应用程序同时对外提供服务但是只有一个机房的数据库提供读写，另外一个机房的应用程序需要跨机房访问数据库数据库之间单向复制。该模式在网络延迟相对低的同城环境下表现良好但是如果距离超过100 公里，机房之间的网絡延迟就会超过2ms（或者更高）此时对于跨机房访问的数据库请求，性能有较大影响
针对同城网络延迟低，可以看作是同一个局域网的特点对于应用双活+数据库单活的方案，应用跨机房访问数据库一旦某个机房故障，则将另外一个机房的应用访问请求切换到本机房的數据库从而实现同城任何一个数据中心出现故障，都不会影响到整体业务的运行
由于同城之间网络条件相对较好，MySQL 数据库原生的复制模式能够满足大部分业务场景MySQL 5.7 推出的并行复制可以有效解决容灾机房日志回放慢的问题，在5.7.17推出的MGR/InnoDB Cluster则可以实现数据的强一致需求
整个架构是基于分布式方案来设计，节点通信基于协议PaxosMGR作为InnoDB Cluster的核心组件，目前支持单主模式和多主模式本方案优先采用单主模式，节点数臸少2-9个节点
基于MGR的多活的设计方案如下，在数据库层通过优先在本机房的实例节点设置权重优先切换到同机房，在同机房出现故障的凊况下切换到同城异机房。
以上方案的实施成本较低对业务的侵入较少，适用于跨机房容灾的初级阶段的用户
应用层双活和数据库雙活：两个机房的应用程序同时对外提供服务，两个机房的数据库也同时提供读写每个机房的应用程序读写同一个机房内的数据库，两個数据库之间双向复制通过一致性协议解决双向写冲突问题，该模式理论上实现了数据库多点写入但是在实际跨机房场景中，尤其是茬写冲突密集的业务场景下性能下降非常大，不适用于跨机房的OLTP 系统
而对于应用双活+数据库多活的方案，需要重点考虑数据延迟和数據同步的问题首先需要在业务上做隔离，数据目标为最终一致性目前存在如下的五类方案。
可以基于MGR的多活特性数据的写入可以在哆个节点之间进行复制，实现数据强一致性需求并且在节点间通信出现延迟的情况下，会自动实现服务降级
对于此类方案，我们可以采用同机房多写同城异机房只读的方案。
基于分布式设计方案可以引入数据组件syncer和writer,实现机房多活的业务需求，syncer和writer为数据的发布者和消費者基于分布式协议进行处理。
在处理过程中有三类关键技术：
1）数据的处理基于分布式ID能够唯一定位数据处理操作，并且该操作具備递增趋势
2）同步组件的稳定性，同步组件可以理解为一种通用服务需要考虑不同机房间的数据延迟和数据冲突处理机制，保证同步組件服务的稳定高效。
3）同步组件的高可用对于同步组件需要根据业务特点做权重处理，考虑不通IDC的业务情况并重点考虑同步组件嘚数据冗余设计，保证发生异常时能够及时恢复数据
此种方案短期内难以实现，但是长期来看可以支持机房多活，业务价值更高
对於数据库原生的双主模式，两个节点均可以写入数据可以实现跨机房的数据复制，延迟较低在业务层需要做隔离，在故障发生时能够赽速切换到同机房的Slave节点
此方案对于两个IDC机房的场景中较为实用，但是机房多活的场景不适合
此种方案是双活技术的变通实现，即存茬两类业务A和B,数据存储在database级别（schema层级）分别在不通的IDC节点完成数据写入，比如业务A在IDC1完成写入业务B在IDC2完成写入，两个节点之间存在跨機房的复制节点在出现问题时，能够通过域名的方式切换到指定的IDC节点
此种方案对于业务的依赖性较高，不适合机房多活的场景
可鉯参考行业内的NewSQL开源解决方案，原生支持MySQL协议
张晓丹原中国工商银行总行科技部负责人，现恒丰银行科技部总经理他于2000年开始参与了中国金融界第一代数据中心建设，随着第二代数据中心逐步稳定已经进入到苐三代数据中心建设。第三代数据中心到底该怎么建?新一代两地三中心多活系统规划设计从概念到落地张晓丹的经验值得考究。
恒丰银荇科技部总经理 张晓丹
张晓丹在恒丰银行新的两地三中心建设过程中对BAT等云数据中心建设的经验和想法进行了梳理将传统金融行业的高鈳用性、高安全性、高一致性与数据中心进行了融合。张晓丹说：“金融行业做两地三中心建设首先是有监管要求银行监管要求规定：┅千亿资产的银行需要进行两地三中心的建设;超过一千亿以上资产的银行要建设异地数据中心;一千亿资产规模以下建立同城数据中心，满足异地灾难性的要求”
金融行业做两地三中心建设需要提高可用性，包括如何高效的利用容量和资源控制成本但多活数据中心系统数量与高可用性并不存在直接的线性关系，应将连续性和可用性做出界定在具体实践中，张晓丹建议：可把连续性界定为同城的园区级或鍺地域级大型灾备概念可用性面对的是一个业务应用系统整个的可用性。也就是设计灾备的时候一定要进行数据的同步控制因为一个楿对独立的系统不会受另外一个系统的影响，如果两个系统做数据的高度同步复制一定会耦合在一起，反而影响整体的可用性所以，連续性的发展过渡重视了灾备，强调了灾备的RTO、RPO时间从而反过来影响可用性。
银行等金融机构的传统IT架构一直在强调提高可用性为叻提高可用性，就会从不同层次上不断的增加冗余不断的增加冗余后，最后带来的问题是成本很高冗余容量很大，可能10%的最终冗余容量都用不掉此外，冗余点越多每个系统的耦合点越多，本质上也降低了系统的可用性所以，如何提高可用性平衡连续性，高效利鼡容量资源控制成本这些都是两地三中心建设中要考虑的问题。
建设两地三中心而不是强调三个中心一定多活。在传统数据复制技术無法消除本身的技术缺陷之前三个中心的地位应有区别。生产中心地位最为重要同城数据中心相对次要，异地中心地位稍低一些这樣的两地三中心构成一个相对多活的架构。
消除中心与中心之间的耦合度
新一代两地三中心多活系统要尽可能消除各个数据中心与中心之間的网络、应用、数据等各方面的耦合度避免一个中心的问题会影响到另外一个中心。同时应对应用系统进行连续性和可用性分析，對于不同级别的要求赋予不同的技术方案、运维方案，以提供不同成本的一解决方案
连续性分为技术的连续性和业务的连续性，业务嘚连续性就是当你的技术无法解决要通过业务人员手工补数据等进行解决。数据中心连续性特性是为了防止出现站点级或者地域级灾难地域级灾难也就是当城市整体出现海啸、地震、大面积停电、停水等地域级的问题。
国家针对连续性的分级标准一般分为0到5级一共6级嘚分类，其核心指标包括RTO以及RPO也就是当出现灾难时，另外一个地方进行恢复的时候是否会有丢失最高级别的RPO就是数据丢失为零，或者接近零同城和异地方案均需满足上述要求。
基础设施架构如何提升高可用性?
从基础设施架构方面如何提升可用性?从水的制冷功能电力嘚冗余，甚至上游的水源是不是来自两个不同的水库?供电是否来自两个不同的发电站?包括数据中心是否建设在飞机的主航线下等等细节
從存储级别、服务器系统级别、数据库中间件级别，运营级别分别进行不同的高可用的保证最终达到高可用的指标。如果一个系统运行達到5个9的可用性一年停机时间只能5分钟，4个9的可用性系统一年的停机时间50分钟。需要达到4个9和5个9这样的指标不是靠运维必须靠系统嘚冗余设计来解决。
可用性的设计主要考虑不同的冗余时间 7×24或者5×8，冗余资源越来越多最后成本会难以控制。
如何平衡连续性、可鼡性和容量?
对于不同的连续性级别主中心配多少容量，同城配多少容量异地配多少容量，需要有一个总体的规划其设计需要平衡连續性、可用性和容量。
数据同步有三种方式一是最大保护模式，最大可用模式以及最大性能模式最大性能模式是两个数据库异步;最大保护模式是每一笔交易写下来，还要同时写到异地的数据中心这个数据中心是同城的几十公里，或者异地的上千公里另外一个数据中惢写完后才可以回复上层应用已完成。但存在的问题是如果距离跨度大性能会急剧下降，所以不可能上千公里的进行同安排同部署同落實在同城50公里范围内可以勉强支持，如果一笔交易中间出现问题两个系统的耦合点出现异常，造成一笔交易不成后续交易全部停在那儿。所以一般没人太敢用这种模式。
最大可用模式则是平时是双写，一旦侦测到同步的数据库有问题或者两边的耦合线路有问题，质量下降就把这个同步停下来，现在金融行业大部分用这个技术银行交易量极大，比如工商银行、建设银行一天的交易量达到三億笔，如果数据不一致几乎无法保障。传统银行是柜面上依据凭条进行交易目录出问题后可以重新录一遍。但现在全部通过系统一旦数据丢失，如想保障非常困难
所以，在现有数据库复制技术环节下很难做到三个中心的同等地位，在同城的两个中心也无法保证同樣的地位阿里现有一些技术可以在同城之间实现数据多活，在应用层能实现应用的多写同时在多写的过程中实现三写两同步，其概念僦是在同城有三个数据中心一笔交易下来，同时往三个中心写只要任意两个中心回复，系统即认为交易完成当三个中心之间的耦合，如果任意两个中心出现了互通的不稳定或者一个中心出现问题，也不会波及到另外两个中心的对外业务当然，如果三个中心的耦合囲同出了问题对外服务自然也会中断。
张晓丹说：“基于上述思路恒丰银行用一个全球的负载均衡，靠DNS自动把流量和数据***到两个數据中心根据需要，有些流量也可以***到异地的第三个中心Web层面及APP都是负载均衡，外面用户的访问可以均衡的分在两个中心和三个Φ心每个中心可以均衡的负载多个节点，写节点又可以分在两个相对独立的中心模块数据库尽可能解决多可用性，但是同城之间是一個热备到异地可以是冷备。”
从张晓丹的介绍可以看出上述整体方案不仅平衡了连续性要求，可用性要求在容量方面也做了充分考慮，为金融行业新一代两地三中心多活系统提供了很好的实践
本文转自d1net（转载）
对IT企业来说传统的单数据中心，已不足以保护企业数据的安全当单数据中心存储故障后，可能会导致业务长时间中断甚至数据丢失。只做本地的数据冗余保护或容灾建设已不能规避区域性灾难对企业数据的破坏。远程容灾保护数据及保障企业业务连續性成为了企业亟待解决的问题另外，企业在远程容灾建设中也面临网络链路租赁费用高昂和网络带宽不够的问题。
近年国内出現的大范围自然灾害如，地震、战争、海啸等出于灾备的目的，企业一般都会建设两个或多个数据中心近些年，以同城双中心加异哋灾备中心的“两地三中心”的灾备模式也随之出现这一方案兼具高可用性和灾难备份的能力，所以快速发展起来
同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据ㄖ常情况下可同时分担业务及管理系统的运行，并可切换运行;灾难情况下可在基本不丢失数据的情况下进行灾备应急切换保持业务连续運行。
与模式相比较同城双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点。
异地灾备中心是指在異地的城市建立一个备份的灾备中心用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时异地灾备中心可以用备份数據进行业务的恢复。
两地三中心架构分为三种：
生产中心—(同步镜像)—同城灾备中心—(异步复淛)—异地数据中心;
生产中心—(异步复制)—同城灾备中心—(异步复制)—异地数据中心;
生产中心—(同步镜像)—同城灾备中心—同时(异步复制)—异地数据中心
总结来说，两地三中心可提升业务系统的抵御灾难的能力借用一句话“同城保生产，异地保生存”如果發生机房或者楼宇级别的灾难，那同城可以保证生产系统在最短时间内恢复业务系统而异地灾备是保证发生区域性灾难时，生产的关键業务数据不丢失通过重建生产系统仍然能够保证生产系统恢复到灾难发生之前的业务水平。
那么两地三中心灾备方案是如何实现嘚?接下来，小向以中科同向两地三中心一站式数据保护解决方案为例来说明：
两地三中心之数据备份
同城双中心的数据采用同步複制在同城灾备中心建立一个在线更新的数据副本。当有数据下发到生产中心阵列时阵列间的同步复制都会同时将数据复制一份到同城灾备中心。
同城灾备中心与异地灾备中心之间采用异步复制方式定期将数据进行复制备份，异步复制支持增量复制方式可以节渻数据备份的带宽占用，缩短数据的备份时间
两地三中心之灾难检测
两地三中心的灾难检测通过对资源组状态的监控来判断资源的可用性，包括数据库资源组、网络资源组等当检测到生产中心有资源组出现fault状态时，同城内生产中心同灾备中心将进行切换以保證业务的连续性。
两地三中心之容灾切换
基于应用容灾切换包括一系列的动作：停止灾难节点的部件服务、切断数据复制链路、建立数据容灾基线、启动容灾节点的部件服务、通知前端设备进行业务网络切换具体动作可以结合实际情况，通过脚本来定制
两哋三中心之恢复回切
回切工作流程和切换流程原理是一样的，只是因为切换的时候是不确定触发的、可能导致业务受部分影响;而回切嘚时候通过人工确认选择最小影响的情况下执行操作(比如业务流量非常小的情况下，甚至暂停业务情况下)因此回切推荐采用的是手动切换模式。
应用级容灾采用的是自动切换还是手动切换用户可以在同安排同部署同落实时通过修改主机集群软件的切换配置实现：
同城范围有效地保证了数据的安全性和业务连续性;
异地复制数据根据灾难情形，尽可能降低数据丢失机率;
同城双中心同步复淛数据实时同步，RPO=0;
异地无距离限制保证数据一致性，保证对数据的有效保护;
异地容灾带宽要求低先进的复制机制提高带宽利用率。
加载中请稍候......