精华内容
下载资源
问答
  • 本文根据 GOPS2017·上海站演讲《饿了么异地双活数据库实战》整理发布 作者简介: 虢国飞,饿了么 DBA负责人 从事数据库行业10+年,专注于MySQL、PgSQL、MSSQL等数据库领域的管理、研究和平台的研发等工作,...

     

    本文根据 GOPS2017·上海站演讲《饿了么异地双活数据库实战》整理发布

    作者简介:

    虢国飞,饿了么 DBA负责人

    从事数据库行业10+年,专注于MySQL、PgSQL、MSSQL等数据库领域的管理、研究和平台的研发等工作,目前负责饿了么数据库团队的管理和数据库维护方面的工作。

    我今天分享是饿了么在数据库和多活数据库这块的实战经历,供大家参考。

    主要分享以下五点:

    1、多活当中的难点

    2、多活的架构

    3、数据库改造

    4、DBA 挑战

    5、收益与展望

    一、多活当中的难点

    我们先来看一下多活的第一个难点:要考虑做多活到底是同城的多活还是异地的多活,跨地域网络延时是现阶段很难突破的点,因为饿了么面临的是异地的多活,所以我们需要基于延时这个前提来考虑方案。

    从北京到上海中间有30毫秒的延迟,这个会带来什么问题?我们接下来会讲。

    饿了么

    上图是同城和异地多活不同的点,复杂性和可拓展性对架构的影响方面会有很大的不同。

    我们挑几个点讲一下:

    1、如果只是做同城多活的话,像30毫秒的延时不需要考虑,因为同城的延时通常只有几毫秒,跟同机房差不大。

    2、如果是异地30毫秒的延时就需要重点考虑了,因为如果是反复调用的应用,放大的时间就不只是30毫秒了,可能是300毫秒、500毫秒,对很多应用来说是不可接受的。

    在可扩展性方面如果做的是异地多活的话,你的可扩展性理论上来说没有太多的边界。我们做同城多活只能在上海机房里面选,如果是异地多活,可能是全国甚至是全球都可以选。

    数据

    还有一个比较难的问题,就是怎么保证数据的安全。多活数据可能面临多个写入点,可能会错乱、会冲突、循环复制、数据环路等问题,这种情况下怎么保障一致性。如果这些没有考虑好之前,你是不能上多活方案的,多点写入的风险对数据的考验是很大的。

    综合考虑下来我们选择了异地多活,所以这些问题我们都需要克服,也意味着会面临很多的改造。

    架构

    如何解决跨机房延时对业务的影响,包括各种抖动甚至是断网的问题。怎样有效区分我们访问的流量,最大限度地保障用户的访问落在正确的机房,这个都是需要解决的难点。

    我们采取了一些措施:

    1、尽量把业务做成类聚的,让一个用户的访问落在同一个地方。

    2、不是所有的业务都有多活特性的,还可以有全局使用的业务(比方用户数据),所以需要做业务类型划分。

    • 在服务划分这一层怎么定义业务调用的边界,还有我们基于什么对流量和用户做划分的呢,目前根据我们的业务特点使用的是地理围栏(POI),用户、商户、骑手当前所在的地理位置是我们入口流量划分的依据。
    • 再看看路由控制这一块,除了入口流量这一层做了机房的划分,还在内部使用了虚拟的Shardingkey,ShardingKey会把全国流量分成多个部分,并且与POI标签绑定,这样就可以把逻辑ShardingKey和物理位置对应起来,切换的时候访问就可以随ShardingKey分流到不同的机房。APIRouter就是为了完成这个工作的,它会根据配置的规则把Shardingkey对应的流量分到对应的机房。
    • 脏写预防方面,为防止数据冲突,我们也需要业务配合做一些多活规则的改造,这些规则对业务还是有一些侵入性的。另外SOA-Route就是内部跨业务调用的访问路由。还有一个DAL,就是数据库的代理层。业务访问在我们多层的路由控制下,理论上应该能正确路由到合适的机房,如果超越规则或者没有按规则改造的意外流量真正穿透到DAL这一层的时候我们是强制拒绝的,因为底层认为这个访问是属于异常的调用,流量走错了机房,这时候就会拒绝。所以我们宁愿让他失败也不能让控制之外的数据进来,这样才能保障规则和数据的可控性。
    • 数据一致性方面我们有一个重要的DRC数据同步组件,数据库这块有一些自增的控制,DBA还研发了一个数据一致性校验的工具(后面会介绍)。

    二、多活的架构

    架构

    粗略过了多活的一些难点和我们的应对方案后,我们现在来看一下整个多活的架构。这个上面是我们从入口流量、分流控制、数据多机房同步,包括各个重要组件的架构等。还有里面有globol zone这一项,它是我们刚刚讲的需要全局依赖的业务会把它放在globol zone里面。

    DRC

    DRC这是做多活时相当重要的组件,主要解决数据在多个机房当中的同步复制。我们从北京机房写入的数据,会同步到上海的机房。上海的机房写入的数据也会通过DRC这个组件同步到北京的机房。大家可以看它其实包含三块服务,Replicator、Applier和Manager,一个收集变更数据、一个将变更数据写入到另一个机房,另外一个是做管理控制。

    DB架构

    DB架构这块我们有两类(准确讲还有一类是多推的,比较少),第一类是ShardingZone,不管是数据写入还是访问都是本机房提供,出问题的时候也只是流量的切换,并不涉及到底层的变动,这个是真正多活的架构。

    还有一种是刚刚讲的,有些没有办法做业务分区的,是globolZone的架构,写是集中在一个机房,读在本地机房完成。大家可能会想到globalzone这种架构会天然面临一些刚刚讲的数据延迟的问题,所以这块我们的定义是一些写入量不大,访问量大,对数据延时是不那么敏感的业务就可以放到这里面来。

    三、数据库改造

    多活项目我们调研大概花的时间有半年左右,但真正做改造的时候时间是相当短的。从启动这个项目到真正上线就用了三个月左右的时间。那时候时间是相当紧的,大家可以看一下我列举大的为配合多活数据库所做的改造项目。

    数据库

    首先面临的问题,就是我们要把数据全量的从一个机房导入到另外一个机房,这个不光有测试环境还有生产环境都要全量的同步。我们数据有几百T数据,几百套集群,有各种主从结构需要搭建需要去搭起来,每个节点时间也很短。

    我们刚刚讲的DRC会做数据的同步,但同步的时候也会面临数据冲突的问题,为解决这个问题我们需要在所有表上增加一个DRC时间戳字段,用来判断哪一边数据是最新的,这样在数据发生冲突的时候,我们会选最新的数据作为最终的数据。

    为防止多活主键冲突,数据库做了一些自增的调整,自增步长放大后马上就会面临数据溢出的问题,所以我们需要把主键都从int调整为bigint。主键改完以后还有一些外键依赖的也会需要改造,所以整体会要做很多的DDL(几乎是全量表),而在MySQL里面DDL其实是风险比较高的操作。

    第二个大改造是因为区分了不同的业务类型(我们刚刚讲了有goloblZone这些),就会面临各种不同类型的业务原来在同一套实例上的,现在需要拆分迁移到不同的实例上,这个我们也陆陆续续迁移50+的DB,现在还在有些在迁移。

    下一个改造是我们现在用DRC做跨机房的数据同步了,所有的数据同步都是原生的改成DRC的模式,也会做很多的调整。

    还有一个问题,就是帐号网段也需要做调整,因为我们原来基于安全考虑会限制某些IP网段,现在网段范围放大了,所有帐号都要面临调整网段的问题,如果量比较多的话,调整账号风险还是挺高的(很多历史遗漏会使得主从账号不一致,同名账号不同网段等问题,如果出现不一致调整的时候主从会中断)。

    另外怎么保证全局参数的一致性,起码要保证同一个集群,在各个机房参数都是一致的,这个是比较脏活累活的东西,但是很容易出问题,到处是坑。

    另外HA也面临改造,因为原来在一个机房,现在有多个机房,怎么做到HA的可靠性也是一个问题。这块我们也做了很多的改造。

    数据库

    改造完成之后,我们对比下改造前后在数据库这端的变化。实例就翻了一倍,集群数量、Proxy配置、数据量、HA都会翻倍。这里特别列了一些DDL的变化,为什么会有变化,因为DRC不做DDL同步这个事情,这个事情都需要DBA分开机房来做(后面会细讲)。

    机器故障每周也增加了,原来一周碰不到一台,现在可能一周面临两到三台这样的机器故故障,所以必须要保证你的HA是足够可靠的。

    但是我们人数是没怎么增加,而且我们马上要上第三个zone,维护的工作量会增加更多,不过我们没有加人的计划,之所以这样是因为我们在把很多的工作通过平台、自动化和项目的方式来推动解决掉。

    四、DBA挑战

    DBA

    刚刚讲了那么多的改造前后的变化。对DBA来讲,除了业务在多活的时候做改造,架构在多活时候的支持外,我觉得做多活改动最大的就是DBA了,对DBA的挑战真的很大。就像前面说的在集群数量很大的情况下,怎么有效保障数据一致性、HA、配置、容量,还有DDL等问题。

    数据

    我们可以看一下。刚刚讲数据这块我们需要保证他不能错、不能乱,也不能说因为有一些数据的冲突,我们整个的数据流就停下来,这也不合理,否则多活就没有意义了。

    再一个即便是把前面流量的东西,都按规则走了,但你也不能保证各个组件不会出一些bug的问题,比如说DRC同步的时候就有bug,我们就要有兜底的检测,把有问题的数据及时的发现,甚至是修复好。

    所以我们DBA研发了一个DCP的平台,DCP就是为数据一致性兜底的,它会全量的对比我们各个机房的数据,告诉DBA到底什么时候有数据不一致的问题,大概是多少,是什么样的类型,怎么修复,不一致量大的时候还需要有合适的修复工具。

    对DCP设计来说,因为我们有很多套集群,变动很多,如果说一旦变动就要人为调整的话,这个维护量也是很大的,也很难保证它的准确无误,所以它必须能自适配。它需要支持全量、增量、延时的控制校验和随时手动校验。

    延时校验就是我们有时候跨机房的时候天然就面临延时,这时候如果有延时数据肯定有差异,DCP需要知道到底是因为延时导致的数据不一致还是数据真的不一致。

    还有黑白名单机制,自定义规则,白名单有一些表我们不需要校验就可以跳过。自定义规则就是可以设定一些相应的过滤条件来比较,滤掉一些不需要比较的数据。

    DCP不光是支持对数据一致性的校验,表结构不一致了也需要校验,甚至说多维数据也能提供校验支持,比如说一个订单可能根据用户做了拆分,也根据商户做了拆分,这两个数据是否一致是需要校验的。还有我们需要控制比较的时候它的延时、并发、校验的时长等,因为你的校验一直在跑,消耗过大,跑的时间很长势必对生产会造成影响。

    最后我们是需要提供灵活修复的工具和配套的脚本。这样比出来的数据才能够快速的恢复,否则你虽然知道数据有问题,但要找这些数据怎么样不一致的,怎么去修复,再根据条件去把脚本写出来,这个过程就很长了,等你修复说不定业务已经影响比较大了。

    数据

    DCP平台上线以后,每天大概有400多套集群需要校验,日均校验的数据有60多亿,分钟级别的校验频率。实际发现数据一致性的问题起码有50+例。

    不一致的原因可能是业务写错了,DRC出BUG了,还有可能是各环节(包括DB)的配置问题,如果你没有相应数据校验的工具,其实你是很难知道到底数据是不是一致的,多活做的时候这个情况必须要能掌握,否则心里没底了。

    刚刚讲的是数据校验DCP的平台,还有一个HA的保障,集群数量翻番了,这时候你需要保证任何一个节点挂了都能尽快的切过去,同时如果你的节点有调整有下线等,你都需要保证HA配置能够跟着变动,否则HA的成功率就会得不到保证,800多套集群也不可能再依赖人肉去保证了。

    所以我们做一个EMHA,他有什么作用呢?首先集群任何节点变动都能够自动感知,当然我们底层是依赖于MHA的,MHA的配置大家用过的话都知道它需要对SSH做互通,有任何一个调整需要把他从配置文件里面加进去或者删除,否则切换就有问题,所以EMHA新增了自动感知配置保持的功能,自动解决这些问题。

    第二个重要的功能是变动信息的扩散通知的机制,因为我们是通过DRC同步数据的,如果有一个master出问题切换了,这时候要通知DRC去连新的master,并且还需要提供相应的位点信息,还有各种监控也需要得到通知,要知道这个master挂了以后,新的master是哪一个,否则后面维护的信息其实都会错乱;

    第三点我们的切换需要让Proxy这一层自动感知,如果不能自动感知的话,每次切换Proxy都需要维护,这个可能会中断生产的访问,而且这个维护质量基本也得不到保证,所以EMHA也会自动完成与Porxy配置层信息的互通。

    还有配置的保持也是比较麻烦的事情,我们在代理层的配置,如果节点变动了也需要变(调整区别于切换,切换DAL可以通过EMAH自动感知)。有各种参数,如果说调整不一样了,也需要全局的同步的,这些东西都需要有很多自动发现的手段,包括自动处理的方式。

    当然我们现在有些也还没有能完成做到自动化(正在努力中),目前还有些是通过巡检脚本来发现的,起码保证能够发现它然后解决掉。

    容量这块,现在是两个机房,两个机房的流量并不一定均衡,比如上海机房70%的流量,北京机房30%的流量,但流量会随时切换,所以必须保证每个机房都能够承担所有流量。

    当然三个机房的话,不一定百分之百的冗余,但也一定要知道每套集群是不是能承载切换过来的流量,否则切换过来就面临雪崩的效应。所以对各项指标我们都要有相应的水位监控,提前发现这些问题。

    还有一个很大的困难是在DDL这块,因为DRC里面不方便做DDL这个事情,之前我们也尝试让DRC同步DDL操作,比如说我们做DDL的时候,一般是用PT工具来做,这个过程要拷贝整张表的数据,如果这个表比较大,DDL时两个机房之间的流量就会面临很大的冲击,而且延时会相当大,比如说100G的表在一个机房做完要同步到另外一个机房去,这冲击业务影响是不可接受的。

    所以DDL需要DBA在每个机房单独做,我们开发了一套DDL发布工具。因为我们有很多数据类型,有GlobalZone还有shardingZone我们还有大量Sharding 表。对单个业务逻辑表的DDL来说,实际上我们一套集群里面有几百张表,这个表又分布在多套集群里面,所以实际业务一张逻辑表的DDL操作,实际DDL需要做一千张表,同时还有各种不同的业务集群类型,我们在发布工具必须要能自动适配和识别这些情况(这个时候元数据维护相当重要了,因为人已经识别不了啦,只能依靠工具)。

    还有刚刚讲DDL的时候大家普遍用PT的工具,我们用的时候也发现了很多问题,毕竟是它是同步触发器的,一旦加上去之后,瞬间TPS很高的话,就把数据库打爆了。

    所以我们在这块也做了大量改造,到现在大部分情况下我们已经不用PT了,大家看这个图上有好几种工具可以选择。我们基于开源社区的gh-ost做了一个二次开发改造,改造后的工具叫mm-ost,是一个跨机房的DDL工具,不仅解决了DDL的时候threadrunning不可控、主从延时不可控的问题,还解决了跨机房延时的问题,速度比gh-ost要快一倍。

    我们是多机房,多机房和你做一个机房的DDL时完全不一样的,因为你的机器可能有差异或者繁忙程度不一样,可能这个机房DDL做完了,另外一边要半小时之后才能做完,尤其是一个业务逻辑表的DDL对应的是上千张物理表的DDL时,差异性就更大了,这样造成的跨机房延时业务可能没法接受,所以我们需要的不仅是能保证同机房DDL主从延时的可控,还要保证跨机房的延时的可控。

    DDL

    mm-ost现在就能够支持到跨机房同步完成DDL的时差控制在3到5秒之内。这延时对业务来说就没什么感觉了,而且他可以支持暂停、探测到DDL数据延时的时候能够减慢速度,能根据机器负载动态调整DDL的速度等,所以现在DDL基本上对业务来说是没有感觉的。

    另外,大家可以看我们的发布平台做的很复杂,它底层调用的是mm-ost,在发布平台上我们也做很多控制,比如说DDL空间满不满足,各个主机是不是都满足去做DDL的条件,主从我们需要控制的延时在30秒之内,有锁的时候需要减缓速度,还支持定时执行(因为我们有些业务的低峰是晚上4点,所以DBA不可能每次都是4点来做这个事情,这时就要定时功能的支持)。

    另外系统还可以通过识别业务高低峰推荐什么时候做DDL比较合适,还有一些风险识别的控制,我们还要预估DDL的时长,如果开发问一个500G的表DDL大概多久能做完?你需要能大概告诉他,给他一个预期。总之发布这块是我们面临最大的一个挑战,我们在上面做了很多工作。

    我们DDL数量相当多,可以说在多活改造的时候,DBA发布的量是最多的。多活改造期间我们DDL基本上每周的工单都在四位数,四位数的工单数量,放到底层来讲,可能一个逻辑表生成一千个DDL,就是最少是5位数DDL物理表的量了。

    如果完全依赖DBA来执行,也很难支持了,所以我们加了自动发布功能,对于风险不高的工单是系统自动执行的,粗略的比例大概是8:2,绝大部分都是自动发布了。风险性比较高的工单我们才需要人去处理,我们统计了一下半年大概有15000个工单。

    五、收益与展望

    大概的挑战主要的方面已经跟大家分享了。我们最后看一下多活做完以后收益有哪些。

    做多活之前,我们也面临过很多棘手的问题,比方我们之前面临着整个机房出现问题(核心交换机出问题、网络出问题),还有些机房因为在业务没有那么大之前你不可能预留特别多的机柜,但你现在说我业务涨的很快,现在要加一千台机器、两千台机器的时候,发现你加不了,因为你的IDC不能给你这个支持,他们不可能给你预留这么多机柜,这个时候你就面临单机房没法扩容的麻烦,之前只能考虑迁移到一个更大的机房去,但也是个耗时费力成本高的事情。

    我们多活做了之后,首先打破了单机房容量的瓶颈,单机房不能扩容的时候,我们现在可以在另外的机房扩容我的机器,也可以分不同的流量来满足负载,就不再受到单个机房容量的限制。

    另一个,多活上线到现在我们流量切了有20次左右,有时候是演练,有时候是真实发生故障,现在其实就不再受到单机房故障的影响,甚至是单地域的影响,假如说上海哪一天全断电了对我们影响也不大(当然只是指技术层面)。

    还有故障兜底,有的问题可能是比较麻烦的问题,一下子没有办法判断或者解决,那时候可能影响很大,但只影响单个机房,这个时候就可以把业务切到另外一个机房,等我们把问题解决了以后再把流量切回来,这样对业务就基本没有损失了,所以多活之后对我们整体可用性也有一个很大提升。

    另外一块是动态调整各个机房的流量,尤其是在做一些促销活动的时候,有些地区的流量明显是不均衡的,这时候如果能动态的调整机房之间的流量访问,这是比较好的分担压力,像阿里双11这种活动,应该会根据流量压力来调整各机房之间的分配。

    接下来在来讲下多活这块后续我们可能要做一些事情,一个是刚刚讲的多个机房,我们现在正在准备第三个机房,因为两个机房的代价比较高,冗余比较多,我们需要做第三个机房分摊这块的成本,当然一开始成本是比较高的,往后业务继续上涨的话,可能不需要做太多的扩容。而且现有百分之百冗余的机器资源,可以再做调配,这样成本往后来看的话是会下降的。

    另外一块是数据的Sharding,这个我们还没有做到,因为我们在各个机房都是全量的数据,这也是我们后面努力的方向;

    还有一个是自动动态扩缩容,我们需要有更细的控制能力来自动的完成这些动作,尤其是在硬件资源利用率上能动态调整;

    最后一个点是希望能够提供多机房数据强一致性的架构方案,因为我们现在来讲都是最终一致性的,怎么对一些非常重要的数据,提供各个机房数据及时强一致性,这块也是我们接下来需要努力的方向。

    转载于:https://www.cnblogs.com/DataArt/p/10006117.html

    展开全文
  • 【IT168 专稿】本文根据虢国飞老师在2018年5月12日【第九届中国数据库技术大会】现场演讲内容整理而成。...摘要: 异地多活(双活)技术一直是行业内一个比较大的技术挑战,当中要突破诸多的技术难点...

    【IT168 专稿】本文根据虢国飞老师在2018年5月12日【第九届中国数据库技术大会】现场演讲内容整理而成。

    讲师简介: 虢国飞,饿了么 DBA负责人。从事数据库行业10+年,专注于MySQL、PgSQL、MSSQL等数据库领域的管理、研究和平台的研发等工作,目前负责饿了么数据库团队的管理和数据库维护方面的工作。

    虢国飞:饿了么异地双活数据库实战

    摘要: 异地多活(双活)技术一直是行业内一个比较大的技术挑战,当中要突破诸多的技术难点,很多公司都做过类似的尝试,但是往往止步于灾备阶段难以向前;饿了么双活项目通过前期丰富的调研,真正启动改造实施只有短短三个月就完成了上线,并且一次性上线成功,当中也遇到了不少的问题踩过很多坑,尤其是在数据库这一块的问题会比较多,因为在多活设计中大家最担心的点是怎么保证数据在多个机房实时同步、如何才能保障数据不被写坏和怎么兜底保障数据的一致性,这些点对数据库方面的挑战很大(极容易出现重大事故),所以本次分享会对这些难点做一个全面介绍,内容包括饿了么多活中数据库的架构、改造、难点、收益与展望等,重点会介绍数据库为多活所做的改造、多活过程中和上线后DBA所面临的挑战和我们是怎么克服这些困难的,期望能为大家揭开多活技术的在数据库这层面纱,为大家进行类似技术方面的改造提供参考。

    分享大纲:

    1、多活难点&设计原则

    2、多活架构&切换

    3、数据库改造&挑战

    4、收益&展望

    正文:

    1、多活难点&设计原则

    从多活落地后回过头来看,多活的难点还是有很多的。

    首先,同城Or异地的问题。如果是做同城多活,和异地比成本投入会少很多,起码光纤距离和带宽费用就会少很多。另外,异地多活实现起来会更复杂,涉及跨网络的延时,需要有更周密的方案,而同城访问一般不需要做太多的改造,相当于是同机房的调用。异地多活的劣势是改造大、成本高,但是与同城相比,存在天然优势,最直观直观来看我们的扩容就不会受地域的限制,而同城机房就不能解决这个问题。

    异地多活除了成本高外,异常情况下的数据处理方案,如数据出现错乱,冲突,环路,或者一致性问题等,都需要重点考虑。

    总的来看,异地多活的难点其实主要有三个,第一,如何做好分流和控制;第二,如何解决跨机房延时带来的问题(访问&数据);第三, 如何解决数据安全性。

    基于上述这些问题,我们抽取了一些设计原则:

    1)、业务内聚。跨机房自然会存在延时,但我们希望一笔交易能在同一个机房完成,减少跨机房的调用; 即一个订单的生命周期在一个机房中完成,这样可以避免跨机房延迟带来的影响。

    2)、可用性优先。绝大部分互联网公司都是基于这个原则(base),优先保证系统可用,对饿了么来讲就是先让用户可以下单吃饭,容忍暂时数据不一致,事后修复。

    3)、保证正确性。在确保可用的情况下,需要对数据做保护以避免错误。

    4)、业务可感。业务团队修改逻辑,能够识别出业务单元的边界,只处理本单元的数据,打造强大的业务状态机,在出现异常时能发现和纠正错误。

    除此外,还有设计分区原则。我们在云端部署了一个智能DNS,并且是在多个云端,根据用户所在的POI位置,来完成用户的分流。相当于是对机房的一个映射,把全国分成很多区,机房和分区是一对多的关系,如果用户从某个位置进来,就会对应到某个逻辑分区,分区最终会路由到对应的物理机房,完成基于用户位置的分流。

    2、多活架构&切换

    那么,多活的实际架构是怎样的呢?

    虢国飞:饿了么异地双活数据库实战

    我们会在云端部署智能DNS,完成用户的分流,用户通过DNS进来就决定它的流量会落到哪个机房,他的整笔交易基本上是在同一个机房来完成的。所以,用户的使用不会受到跨机房的影响。另外,我们在底层也有相应兜底的架构应对方案,防止因前段路由异常情况下造成数据的错乱。

    虢国飞:饿了么异地双活数据库实战

    这是我们在做数据同步时很重要的一个组件,叫做DRC。主要任务是在底层完成两个机房之间的数据同步。设计原则是在每个机房部署相应的通道,一端接受的是数据变更,然后把变更同步到另一端机房,完成数据双向同步。

    虢国飞:饿了么异地双活数据库实战


    虢国飞:饿了么异地双活数据库实战

    在DB这端,我们看到最前面的架构图有两个。一个是ShardingZone,另外一个是GlobalZone。ShardingZone的主要特点是,适用于业务能按区域维度进行切分的应用,实现真正的多活, 而且读写都在本地机房进行;这个架构正常情况下,只需要本地机房的数据,对其他机房数据无依赖,所以跨机房数据延时是无影响的,我们设计时只需要考虑避免数据同步冲突(DRC冲突处理、自增值DB控制)。GlobalZone架构适用于特殊场景,比如需要对数据有强一致性的要求或者没有分区标签,它的写是在同一个机房,但读是在本地机房完成,这样在读的时候会有数据延时,所以我们要按照业务分,有些业务能接受一定程度的延时,他才会选用这种数据完全一致的架构。

    具体DB的切换动作是怎么操作的呢?


    虢国飞:饿了么异地双活数据库实战

    其实绝大部分情况DB都是不需要做切换动作的,因为只有GlobalZone的写入需要变动的时候才是需要DB切换的,其他情况的流量调整和切换只需要GZS控制前端做路由调整就行(DB不需要跟着切)。DB在切换的时候,会有锁、等待动作,是为了保障数据完成同步。当然,等待也有时间限制,如果超时也会强切。

    看下大概过程,比如我们把1机房的DB访问切换到2机房,会先发出一个BLOCK的操作,把1机房的DB写入先锁住,等后面的数据同步和验证操作完成后,GZS会控制其他组件把1机房的访问流量改到到机房2,DAL会完成DB写入的机房间切换。

    3、数据库改造&挑战

    在做多机房最先要做的就是要全量同步数据,包括测试环境、生产环境数据全量同步等问题。第二DRC为了解决数据冲突问题,需要增加毫秒级别的时间戳,但是我们在数据库设计阶段,并不会有这样的字段,所以要做很多更新。第三做多活后很多自增列也会调整,防止溢出。第四多活有不同的架构类型,所以不同类型的DB需要迁移,将同类型的DB拆分到对应的架构里,不同类型的拆开。还有原生复制改成DRC复制、账号网段调整、各个集群参数一致性调整、按集群类型调整HA配置等等动作。总的来说,首先要做数据搬移,然后适配多活的体系改造,还有个各种数据库的配置也需要调整。做完多活以后,实例、集群、Proxy、HA、数据量、DDL、机器故障等几乎都是翻倍状态。

    为了应对数据库改造问题,DBA做了哪些基础工作呢?

    首先,要有检测数据是不是一致性的最终方案。当然,我们在前端、后端有一些相应的保护。比如在路由这层,会有几个路由来判断订单是不是正确地进入了对应的机房,DAL这层也会判断这笔交易是不是符合路由规则,不正确的话会直接拒绝。但是还是会出现一些问题,比如:软件上的BUG,或者是没考虑到的问题和设计之外的异常场景,会导致数据穿透到底层,造成多个机房数据不一致,所以我们要做兜底的最终数据是否一致的校验。我们开发了DCP数据校验平台,能完成分钟级别的数据校验, DCP不只完成全量、增量、延时校验、手动校验,还有数据结构、多维校验,还要考虑各种延迟、并发、校验时长等情况;最重要的是要有一套比较方便的修复数据的方式或者配套工具,因为你找到不一致数据后,工具如果不能直观告诉你怎么去修复,又会是一个大问题,而且数据还会一直在变,可能会造成其他的影响。

    其次,会涉及到数据的迁移、会有大表拆小表这种动作。所以我们研发了D-Bus这套工具,它可以完成DB&Table迁移 、增量和实时同步(包括暂停、断点续传)、单表和Sharding表数据互转、数据校验等工作。

    第三,在系统切换的时候,HA如何与其他系统完成对接,这也是一个重要问题。我们做了一套自动化系统,叫做EMHA 。在HA切换的时候,可以和其他组件完成互动,进行配置、切换、联动(DAL、DRC)。

    虢国飞:饿了么异地双活数据库实战


    第四,DDL翻倍的问题。比如100G的一个表,我们如果通过DRC把变更数据传递到另外一个机房,而且是在跨地域网络的情况下,网络可能会爆掉。所以,在DRC这层实际上是不方便来做DDL操作的传递的,DRC要把这个动作滤掉。我们DDL操作类型比较多,有原生能支持Online的DDL直接分发,还有PT的工具,还有自己研发的mm-ost的工具等。

    多活场景下DDL具体要考虑什么问题呢?首先是控制,DDL的时候空间&延时&锁&定时&低峰期&风险&预估时长等要得到有效的控制;另外,我们的类型比较复杂,包括:非多活 、ShardingZone、GlobalZone、多推、 Sharding(分开分表)等业务,要控制好DDL的同步,同时要保障所有的表都达到一致的状态;还有多机房的问题,我们通过Mm-ost,保证多机房一致性问题,同时保证跨机房延时在3-5s之间。

    之前DDL很大一部分工作是由DBA来做(研发提供单DBA负责处理),现在已经不需要DBA做太多的事情了,由研发自助发布,自助发布的比例超过90%以上,极少数情况下才需要DBA来干预,还有一部分是系统自动执行(不要研发,也不需要DBA来做)。

    4、收益&展望

    很多人可能会有疑问,多活花费这么大的成本,是否值得?

    首先,看下多活的收益。第一,打破了单机房(地域)容量瓶颈,当主机房不能再放机器,而且系统容量已经到上线时,你可以把流量引流到其他机房,让多个机房能承载容量。第二,你的故障不受单机房(地域)故障影响,在做多活之前,其实我们有主力机房核心交换机出现故障的情况,当时没有多活的只能厂商来解决,核心的交换机宕机了三个小时,影响非常大,但是我们却束手无策,而且我们的业务特点有两个尖峰,尤其在中午尖峰的时候挂了,损失会很大。第三,动态调整各机房流量,如果有机房资源紧张,可做动态调配,或者哪个地方访问不均衡,也可以做动态调整。第四,Online维护(通过GZS、DAL、DRC、D-Bus、DCP这些组件的配合),有多活之后如果你想做哪些升级,可以先把流量切到一个机房,在没有流量的机房完成各种动作,都没问题,所以我们现在主要业务基本没有停机维护之说。

    针对企业未来发展,我们也有一些相应的计划。首先是,想做多个机房 。现在很多企业都在计划上云,我们也希望在云上做一个多活的Zone,去分担一部分流量,而且云上还可以动态调整资源。其次是,Data-Sharding,现在做的还是全量数据,上层流量访问是分流量的,底层我们也在考虑对数据分流。其三是, 自动动态扩缩容,这也是我们想上云的原因,考虑在业务高峰的时候多添加一些资源,低峰的时候释放掉这些资源,合理控制成本。其四是,多机房强一致,我们也在做相应方案调研,希望对一致性要求高的部分也能做到多活。

    展开全文
  • Mellanox 和沃趣科技基于对行业用户的深刻理解共同设计开发的 QData Cloud 解决方案提供了高可用、高性能、可扩展的数据库云平台,QData MetroX 更是可以帮助证券用户轻松构建同城双活业务平台从而保障业务 7x24x365...


    证券行业 IT 系统面临的压力和挑战


    近几年来,股市的跌宕起伏和井喷行情,给各大券商的业务系统带来巨大压力,其IT 系统面临前所未有的挑战。为应对日益增长的行情和业务需求,并通过信息技术的升级带动业务创新,打造差异化竞争力,证券公司均不断加强对 IT 系统的新建和改造的投入。

    目前,证券公司诸多关键业务和应用系统均运行在IOE(IBM 为代表的小型机、Oracle数据库、EMC为代表的集中式存储)架构的系统平台上,在应对突发实时交易流量暴增、保障系统高可用、提升移动互联网化的用户体验、满足行业监管要求等方面,原有的IOE基础架构平台面临着诸多不足。具体表现在如下方面:

    • 封闭系统,难于灵活扩展,扩容成本高昂。

    • 数据量激增,IO性能下降,无法满足业务响应要求。

    • 运维复杂,耗时耗力,维保费用居高不下,且难以满足7x24SLA。

    • 数据库版本过于陈旧,无法有效支撑多项业务应用的快速部署。


    高性能数据库云平台方案


    IOE作为一直占据主导地位的数据库系统架构,已经很难满足高速发展的业务需求,其性能,扩展性,成本等方面的缺点逐渐暴露了出来。与此同时,X86平台凭借自身的开放性以及兼容性等特点,积极拥抱一些革命性的硬件产品,如Flash高速存储,InfiniBand 低延迟高带宽网络,使得x86架构在企业的生产环境中承载关键的数据库系统成为可能。基于上述数据库架构发展趋势以及针对证券行业 IT 系统的应用需求,Mellanox(迈络思)联合 WOQU Technology(沃趣科技),设计开发了QData Cloud高性能数据库云平台解决方案,通过沃趣科技自主研发的QData Control群集管理软件、Cloud Manager云平台管理软件、QLink存储管理软件等软件将x86服务器,Oracle数据库,InfiniBand网络及Flash存储整合在一起,提供高可用、高性能、可扩展的数据库服务,适用于OLTP和OLAP等各种应用场景的数据库云平台。

     QData Cloud数据库云平台的系统架构如下:

    (QData Cloud高性能数据库云平台架构)

    (QData Cloud高性能数据库云平台管理界面)

    计算节点基于x86服务器构建,安装运行Oracle单实例或者RAC集群软件,提供数据运算服务,支持水平动态扩展。

    存储节点基于x86服务器构建,每个存储节点可配置PCIe Flash,SSD或者HDD,成为一个独立的存储单元,提供数据存储服务,IO资源也可按需进行水平扩展。

    网络互连采用Mellanox端到端FDR InfiniBand网络,包括交换机、网卡、线缆,提供56Gbps的高吞吐量和0.7us的超低延迟,配置两台InfiniBand交换机实现高可用,防止单点故障。

    QLink是一个基于InfiniBand网络的高速存储互连软件,它将独立的存储资源整合成共享存储池,并将远程存储资源无损地输出到计算节点。QLink基于RDMA协议实现,通过零复制和内核旁路技术,避免了内核空间和用户空间的上下文切换,显著降低了计算节点CPU损耗,从而极大地提升了系统的整体性能,轻松应对数据库高并发的 IO 请求。

    该数据库云平台方案优势如下:

    • 开放架构:基于x86通用平台和高速闪存构建,替代封闭体系的小型机和高端存储;基于用户需求提供

    • 性能卓越:5-10倍于传统架构的性能提升,在OLTP场景下性能不低于Oracle Exadata;全冗余的架构设计,计算层、互联层、存储层均无单点故障;支持实例的在线迁移,对内存、CPU 资源进行隔离等QoS服务质量管理。

    • 简单易用:产品开箱即用,提供一键式的安装和部署功能;凭借产品卓越的性能,适用于多种数据库的整合方案而达到多租户支持;提供从资源池创建、自服务、QoS、监控报警、资源下线的全生命周期管理。

    • 高性价比:凭借卓越的产品和专业的服务,总体拥有成本TCO仅为传统架构的 40%。


    数据库云平台在证券行业的应用实践


    证券公司业务系统复杂多样,对计算和存储的需求各不相同。以风控,资讯,全帐三套系统为例,风控属于OLAP,资讯和全帐属于OLTP,如果物理构建三套独立的数据库系统,存在资源浪费,利用不均的问题。同时针对不同的业务系统在数据库层面应该做好隔离。

    QData Cloud 数据库云平台为上述业务系统构建了数据库存储池,其中风控采用独立 Oracle RAC集群,占用3台存储节点。资讯,全帐共用一套Oracle cluster集群,但各自采用独立的Oracle数据库,存储层面共用 4 台存储节点。

    (基于QData Cloud部署风控、资讯、全账业务系统)

    上述部署采用冷热数据分层存放,配置快速SSD设备与慢速SAS设备,应用区分冷热表,并利用分区表进行数据生命周期管理。

    同时采用共享存储资源池架构,充分利用底层存储资源,提升空间利用率。由于所有系统在同一套。

     InfiniBand网络中,存储资源可以按需在各个系统间进行快速切换。

     相对于传统数据库架构,QData Cloud数据库云平台可以实现5-10倍的性能提升。

    (QData for Oracle 显著提升证券业务系统性能)


    核心网络架构


    数据库云平台采用Mellanox的端到端FDR InfiniBand网络互连解决方案,包括基于Mellanox SwitchX-2芯片的FDR InfiniBand交换机,以及基于Mellanox ConnectX-3 芯片的FDR InfiniBand网络适配器,借助高带宽和低延迟的性能优势,使整个方案具备了行业领先的高效能,高密度,高性价比,以及超低延迟。

     InfiniBand集群的管理采用Mellanox UFM网管套件。UFM针对InfiniBand网络完成资源管理、网络监测、性能优化,并提供了可视化的Web界面,实现InfiniBand网络统一调度管理。

    方案部署和效益:基于InfiniBand网络的QData Cloud高性能数据库云平台,已经在国内排名前十的多家证券公司成功实施并上线运行。该方案帮助客户迈出了去小型机去集中式SAN存储的第一步,使用全x86化的开放架构替代原有的封闭架构,不仅为企业节省了采购成本,还极大提升了数据库系统的整体性能。

    “使用QData Cloud数据库云平台之后,不仅系统性能得到了极大地提升,可以从容应对火爆的行情,而且管理成本也下降了很多。更重要的是,使用QData Cloud云平台帮助我们节省了百万以上的采购和维保费用。”


    双活业务系统建设面临的压力和挑战


    随着信息技术的快速发展,越来越多的企业和单位把应用、数据、系统集中处理,数据大集中的同时风险也随之而来。灾难性的突发事件发生时如何保障核心业务7x24小时不间断运行,成为业务安全的首要问题。

    虽然各个企业现都已采用数据保护的手段及方法,目的都是在积极保障业务的在线性及数据不丢失,但是,传统数据中心采用较为广泛的容灾建设模式中,或多或少还存在一些不足之处,如面临资源利用率低、切换业务时间长、突发事件中存在必然的数据损失、数据中心运维整体健康状态不可见、缺少演练等的挑战。

    当一个站点发生故障时,另外一个站点可实时接管所有业务的双活解决方案成为当前讨论和建设的热门话题,双活容灾解决方案能够盘活现有IT资源,充分发挥资源利用优势,实现应用级双活无感知切换,达到企业对外业务服务的7x24小时服务质量保证,降低灾难性事件发生后业务宕机的风险。


    数据库同城双活平台方案


    双数据中心同时对外提供业务的双活模式,两个数据中心是对等的,不分主从,并可同时部署业务,这样就极大的提高了资源的利用率和系统的工作效率,同时保证在遇到突发灾难时的数据高可用。两个生产中心部署相同的业务系统,底层实现数据双活,结合网络层、主机层或应用的负载均衡技术,实现业务系统在两个数据中心并行工作和负载分担。

    双数据中心的双活方案支持两个数据中心的存储故障、计算节点故障、机房掉电等事件发生时的自动化切换,连续对外提供生产。整个灾难切换及恢复业务的过程均无需人工干预,自动化完成,有效的降低企业客户的管理成本。

    双活方案同时对外提供生产,降低或规避了企业客户的系统维护的风险,在业务不宕机的情况下在线维护存储节点、计算节点,可以实现在线扩容,添加业务节点等,达到企业级用户在线横向扩展的需求。因此,在系统建设初期,客户可以自主选择系统的建设规模,优先满足当前实际业务需求,随着业务系统的发展和对容灾系统需求的增长,灵活的扩展生产系统和容灾系统的规模,以充分保护客户现有投资。

    双活容灾解决方案核心思想是将本地的分布式一体机的解决方案跨两个数据中心建设实施,不仅达到系统级的冗余,包括硬件、数据冗余等,同时也达到了两数据中心之间的业务级冗余。双活数据中心的业务数据是实时同步,且业务数据的镜像相对上层的业务平台透明,所有业务数据的 I/O 生产都将同时写入到两个数据中心。达到业务数据两份实时副本及在线切换的功能,以实现双活数据中心的‘零’切换‘零’丢失。

    业务系统双活的核心技术难点是数据库层的双活,传统的数据双向复制技术(存储存或数据库层)实现不了真正意义上的数据双活,而部分存储厂商报供的存储虚拟化双活技术,实然能实现数据层双活,但是其性能、成本、可管理性、可扩展性无法满足业务要求。得益于长距离 Infiniband 传输技术、Flash 高速存储的发展,使得长距双活数据库平台成为高度可用架构。

    Mellanox(迈络思)联合 WOQU Technology(沃趣科技),设计开发了QData MetroX双活数据库云平台解决方案,通过沃趣科技自主研发的长距双活平台智能管理软件、长距双活仲裁智能控制软件、QLink存储管理软件将 x86 服务器,长距双活管理软件,长距仲裁管理软件,Oracle数据库,长距InfiniBand网络以及Flash存储整合在一起,提供高可用、高性能、可扩展的真正意义上的同城双活的数据库平台,适用于OLTP和OLAP等各种应用场景。

    (Mellanox Metro 系列长距连接方案产品家族) 

    (QData MetroX 双活数据库云平台架构)

    QData MetroX的基础硬件设备是基于QData Cloud高性能数据库平台的,QData MetroX在QData Cloud的基础上,通过长距Infiniband技术,将QData Cloud做了物理距离的拉伸,在每个数据中心部署一半QData Cloud物理设备,两个数据中心之间的存储及数据库心跳通过长距Infiniband交换机互联,两个数据中心之间的光纤距离最长支持80KM。

     QData MetroX平台之上远行的数据库实现了真正意义上的双活,在两个数据中心可以对同一个数据库中的同一张表的同一条记录进行同时增、删、改、查操作。

    QData MetroX平台在实现真正双活的同时,依然可以保持超高的数据库性能,整个 QData MetroX平台可以提供100万以上的IOPS,30GB/s以上的IO吞吐,写IO延迟低于 0.5 毫秒,读 IO延迟低于1毫秒。

    QData MetroX 在继承 QData Cloud 优点的基础上,同时具备以下优势:

    • 真正双活:在两个数据中心可以对同一个数据库中的同一张表的同一条记录进行同时增、删、改、查操作;

    • 卓越性能:10 倍于传统存储双活架构的性能提升;

    • 长距链路状态感知能力:主动持续侦测长距链路状态,为管理和排障提供决策依据;

    • 链路故障主动干预:感知到链路抖动或者延迟升高的情况下,可主动干预,数据库平台整体可用性,在极短的时间内排除掉这种可以预期的故障;

    • 读 IO亲和:本地数据库中心可优先读取本地数据中心的 IO,减少跨数据中心IO 访问;

    • 一体化管理与监控:包含从底层硬件到上层数据的完整的管理和监控平台,可维护性、可管理性更强。


    结  论


    Mellanox 和沃趣科技基于对行业用户的深刻理解共同设计开发的 QData Cloud 解决方案提供了高可用、高性能、可扩展的数据库云平台,QData MetroX 更是可以帮助证券用户轻松构建同城双活业务平台从而保障业务 7x24x365 连续运行。

    原文链接:http://www.mellanox.com/related-docs/solutions/SB_WOQU_QData_Cloud.pdf

    证券行业 IT 系统面临的压力和挑战


    近几年来,股市的跌宕起伏和井喷行情,给各大券商的业务系统带来巨大压力,其IT 系统面临前所未有的挑战。为应对日益增长的行情和业务需求,并通过信息技术的升级带动业务创新,打造差异化竞争力,证券公司均不断加强对 IT 系统的新建和改造的投入。

    目前,证券公司诸多关键业务和应用系统均运行在IOE(IBM 为代表的小型机、Oracle数据库、EMC为代表的集中式存储)架构的系统平台上,在应对突发实时交易流量暴增、保障系统高可用、提升移动互联网化的用户体验、满足行业监管要求等方面,原有的IOE基础架构平台面临着诸多不足。具体表现在如下方面:

    • 封闭系统,难于灵活扩展,扩容成本高昂。

    • 数据量激增,IO性能下降,无法满足业务响应要求。

    • 运维复杂,耗时耗力,维保费用居高不下,且难以满足7x24SLA。

    • 数据库版本过于陈旧,无法有效支撑多项业务应用的快速部署。


    高性能数据库云平台方案


    IOE作为一直占据主导地位的数据库系统架构,已经很难满足高速发展的业务需求,其性能,扩展性,成本等方面的缺点逐渐暴露了出来。与此同时,X86平台凭借自身的开放性以及兼容性等特点,积极拥抱一些革命性的硬件产品,如Flash高速存储,InfiniBand 低延迟高带宽网络,使得x86架构在企业的生产环境中承载关键的数据库系统成为可能。基于上述数据库架构发展趋势以及针对证券行业 IT 系统的应用需求,Mellanox(迈络思)联合 WOQU Technology(沃趣科技),设计开发了QData Cloud高性能数据库云平台解决方案,通过沃趣科技自主研发的QData Control群集管理软件、Cloud Manager云平台管理软件、QLink存储管理软件等软件将x86服务器,Oracle数据库,InfiniBand网络及Flash存储整合在一起,提供高可用、高性能、可扩展的数据库服务,适用于OLTP和OLAP等各种应用场景的数据库云平台。

     QData Cloud数据库云平台的系统架构如下:

    (QData Cloud高性能数据库云平台架构)

    (QData Cloud高性能数据库云平台管理界面)

    计算节点基于x86服务器构建,安装运行Oracle单实例或者RAC集群软件,提供数据运算服务,支持水平动态扩展。

    存储节点基于x86服务器构建,每个存储节点可配置PCIe Flash,SSD或者HDD,成为一个独立的存储单元,提供数据存储服务,IO资源也可按需进行水平扩展。

    网络互连采用Mellanox端到端FDR InfiniBand网络,包括交换机、网卡、线缆,提供56Gbps的高吞吐量和0.7us的超低延迟,配置两台InfiniBand交换机实现高可用,防止单点故障。

    QLink是一个基于InfiniBand网络的高速存储互连软件,它将独立的存储资源整合成共享存储池,并将远程存储资源无损地输出到计算节点。QLink基于RDMA协议实现,通过零复制和内核旁路技术,避免了内核空间和用户空间的上下文切换,显著降低了计算节点CPU损耗,从而极大地提升了系统的整体性能,轻松应对数据库高并发的 IO 请求。

    该数据库云平台方案优势如下:

    • 开放架构:基于x86通用平台和高速闪存构建,替代封闭体系的小型机和高端存储;基于用户需求提供

    • 性能卓越:5-10倍于传统架构的性能提升,在OLTP场景下性能不低于Oracle Exadata;全冗余的架构设计,计算层、互联层、存储层均无单点故障;支持实例的在线迁移,对内存、CPU 资源进行隔离等QoS服务质量管理。

    • 简单易用:产品开箱即用,提供一键式的安装和部署功能;凭借产品卓越的性能,适用于多种数据库的整合方案而达到多租户支持;提供从资源池创建、自服务、QoS、监控报警、资源下线的全生命周期管理。

    • 高性价比:凭借卓越的产品和专业的服务,总体拥有成本TCO仅为传统架构的 40%。


    数据库云平台在证券行业的应用实践


    证券公司业务系统复杂多样,对计算和存储的需求各不相同。以风控,资讯,全帐三套系统为例,风控属于OLAP,资讯和全帐属于OLTP,如果物理构建三套独立的数据库系统,存在资源浪费,利用不均的问题。同时针对不同的业务系统在数据库层面应该做好隔离。

    QData Cloud 数据库云平台为上述业务系统构建了数据库存储池,其中风控采用独立 Oracle RAC集群,占用3台存储节点。资讯,全帐共用一套Oracle cluster集群,但各自采用独立的Oracle数据库,存储层面共用 4 台存储节点。

    (基于QData Cloud部署风控、资讯、全账业务系统)

    上述部署采用冷热数据分层存放,配置快速SSD设备与慢速SAS设备,应用区分冷热表,并利用分区表进行数据生命周期管理。

    同时采用共享存储资源池架构,充分利用底层存储资源,提升空间利用率。由于所有系统在同一套。

     InfiniBand网络中,存储资源可以按需在各个系统间进行快速切换。

     相对于传统数据库架构,QData Cloud数据库云平台可以实现5-10倍的性能提升。

    (QData for Oracle 显著提升证券业务系统性能)


    核心网络架构


    数据库云平台采用Mellanox的端到端FDR InfiniBand网络互连解决方案,包括基于Mellanox SwitchX-2芯片的FDR InfiniBand交换机,以及基于Mellanox ConnectX-3 芯片的FDR InfiniBand网络适配器,借助高带宽和低延迟的性能优势,使整个方案具备了行业领先的高效能,高密度,高性价比,以及超低延迟。

     InfiniBand集群的管理采用Mellanox UFM网管套件。UFM针对InfiniBand网络完成资源管理、网络监测、性能优化,并提供了可视化的Web界面,实现InfiniBand网络统一调度管理。

    方案部署和效益:基于InfiniBand网络的QData Cloud高性能数据库云平台,已经在国内排名前十的多家证券公司成功实施并上线运行。该方案帮助客户迈出了去小型机去集中式SAN存储的第一步,使用全x86化的开放架构替代原有的封闭架构,不仅为企业节省了采购成本,还极大提升了数据库系统的整体性能。

    “使用QData Cloud数据库云平台之后,不仅系统性能得到了极大地提升,可以从容应对火爆的行情,而且管理成本也下降了很多。更重要的是,使用QData Cloud云平台帮助我们节省了百万以上的采购和维保费用。”


    双活业务系统建设面临的压力和挑战


    随着信息技术的快速发展,越来越多的企业和单位把应用、数据、系统集中处理,数据大集中的同时风险也随之而来。灾难性的突发事件发生时如何保障核心业务7x24小时不间断运行,成为业务安全的首要问题。

    虽然各个企业现都已采用数据保护的手段及方法,目的都是在积极保障业务的在线性及数据不丢失,但是,传统数据中心采用较为广泛的容灾建设模式中,或多或少还存在一些不足之处,如面临资源利用率低、切换业务时间长、突发事件中存在必然的数据损失、数据中心运维整体健康状态不可见、缺少演练等的挑战。

    当一个站点发生故障时,另外一个站点可实时接管所有业务的双活解决方案成为当前讨论和建设的热门话题,双活容灾解决方案能够盘活现有IT资源,充分发挥资源利用优势,实现应用级双活无感知切换,达到企业对外业务服务的7x24小时服务质量保证,降低灾难性事件发生后业务宕机的风险。


    数据库同城双活平台方案


    双数据中心同时对外提供业务的双活模式,两个数据中心是对等的,不分主从,并可同时部署业务,这样就极大的提高了资源的利用率和系统的工作效率,同时保证在遇到突发灾难时的数据高可用。两个生产中心部署相同的业务系统,底层实现数据双活,结合网络层、主机层或应用的负载均衡技术,实现业务系统在两个数据中心并行工作和负载分担。

    双数据中心的双活方案支持两个数据中心的存储故障、计算节点故障、机房掉电等事件发生时的自动化切换,连续对外提供生产。整个灾难切换及恢复业务的过程均无需人工干预,自动化完成,有效的降低企业客户的管理成本。

    双活方案同时对外提供生产,降低或规避了企业客户的系统维护的风险,在业务不宕机的情况下在线维护存储节点、计算节点,可以实现在线扩容,添加业务节点等,达到企业级用户在线横向扩展的需求。因此,在系统建设初期,客户可以自主选择系统的建设规模,优先满足当前实际业务需求,随着业务系统的发展和对容灾系统需求的增长,灵活的扩展生产系统和容灾系统的规模,以充分保护客户现有投资。

    双活容灾解决方案核心思想是将本地的分布式一体机的解决方案跨两个数据中心建设实施,不仅达到系统级的冗余,包括硬件、数据冗余等,同时也达到了两数据中心之间的业务级冗余。双活数据中心的业务数据是实时同步,且业务数据的镜像相对上层的业务平台透明,所有业务数据的 I/O 生产都将同时写入到两个数据中心。达到业务数据两份实时副本及在线切换的功能,以实现双活数据中心的‘零’切换‘零’丢失。

    业务系统双活的核心技术难点是数据库层的双活,传统的数据双向复制技术(存储存或数据库层)实现不了真正意义上的数据双活,而部分存储厂商报供的存储虚拟化双活技术,实然能实现数据层双活,但是其性能、成本、可管理性、可扩展性无法满足业务要求。得益于长距离 Infiniband 传输技术、Flash 高速存储的发展,使得长距双活数据库平台成为高度可用架构。

    Mellanox(迈络思)联合 WOQU Technology(沃趣科技),设计开发了QData MetroX双活数据库云平台解决方案,通过沃趣科技自主研发的长距双活平台智能管理软件、长距双活仲裁智能控制软件、QLink存储管理软件将 x86 服务器,长距双活管理软件,长距仲裁管理软件,Oracle数据库,长距InfiniBand网络以及Flash存储整合在一起,提供高可用、高性能、可扩展的真正意义上的同城双活的数据库平台,适用于OLTP和OLAP等各种应用场景。

    (Mellanox Metro 系列长距连接方案产品家族) 

    (QData MetroX 双活数据库云平台架构)

    QData MetroX的基础硬件设备是基于QData Cloud高性能数据库平台的,QData MetroX在QData Cloud的基础上,通过长距Infiniband技术,将QData Cloud做了物理距离的拉伸,在每个数据中心部署一半QData Cloud物理设备,两个数据中心之间的存储及数据库心跳通过长距Infiniband交换机互联,两个数据中心之间的光纤距离最长支持80KM。

     QData MetroX平台之上远行的数据库实现了真正意义上的双活,在两个数据中心可以对同一个数据库中的同一张表的同一条记录进行同时增、删、改、查操作。

    QData MetroX平台在实现真正双活的同时,依然可以保持超高的数据库性能,整个 QData MetroX平台可以提供100万以上的IOPS,30GB/s以上的IO吞吐,写IO延迟低于 0.5 毫秒,读 IO延迟低于1毫秒。

    QData MetroX 在继承 QData Cloud 优点的基础上,同时具备以下优势:

    • 真正双活:在两个数据中心可以对同一个数据库中的同一张表的同一条记录进行同时增、删、改、查操作;

    • 卓越性能:10 倍于传统存储双活架构的性能提升;

    • 长距链路状态感知能力:主动持续侦测长距链路状态,为管理和排障提供决策依据;

    • 链路故障主动干预:感知到链路抖动或者延迟升高的情况下,可主动干预,数据库平台整体可用性,在极短的时间内排除掉这种可以预期的故障;

    • 读 IO亲和:本地数据库中心可优先读取本地数据中心的 IO,减少跨数据中心IO 访问;

    • 一体化管理与监控:包含从底层硬件到上层数据的完整的管理和监控平台,可维护性、可管理性更强。


    结  论


    Mellanox 和沃趣科技基于对行业用户的深刻理解共同设计开发的 QData Cloud 解决方案提供了高可用、高性能、可扩展的数据库云平台,QData MetroX 更是可以帮助证券用户轻松构建同城双活业务平台从而保障业务 7x24x365 连续运行。

    原文链接:http://www.mellanox.com/related-docs/solutions/SB_WOQU_QData_Cloud.pdf

    展开全文
  • 数据库双活部署

    2018-09-08 14:35:49
    介绍农行的数据库实现双活的案例,非常有参考价值。 实现灾备,实现快速反应。
  • 技术创新变革未来 ORACLE数据库双活RAC实践 目录 1多租户数据库 6DataPump的新特性 212c R2 sharding 7在线迁移活跃数据文件 3IN Memory 8表分区或子分区在线迁移 4多LGWR进程 9不可见字段 5RMAN Recover Table ...
  • 云端的数据库多租户;云端的数据库多租户;云端的数据库多租户;云端的数据库多租户;云端的数据库多租户;多租户架构;云端数据库多租户;云端数据库多租户;云端数据库多租户;云端数据库多租户;云端数据库多租户;云端...
  • 后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过F5或者任何代理的方式就可以很好的解决。 后文描述的主要是针对有状态的服务进行... 同城双活 异地

    后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过F5或者任何代理的方式就可以很好的解决。

    后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存,比如MySQL数据库,redis等内存数据库。

    除了这两种类型的维护方式,还有jvm的内存的状态维持,但jvm的状态生命周期通常很短。

    高可用的一些解决方案

    高可用,从发展来看,大致经过了这几个过程:

    • 冷备

    • 双机热备

    • 同城双活

    • 异地双活

    • 异地多活

    1. 冷备,通过停止数据库对外服务的能力,通过文件拷贝的方式将数据快速进行备份归档的操作方式。简而言之,冷备,就是复制粘贴,在linux上通过cp命令就可以很快完成。可以通过人为操作,或者定时脚本进行。有如下好处:

    • 简单

    • 快速备份(相对于其他备份方式)

    • 快速恢复。只需要将备份文件拷贝回工作目录即完成恢复过程(亦或者修改数据库的配置,直接将备份的目录修改为数据库工作目录)。更甚,通过两次mv命令就可瞬间完成恢复。

    • 可以按照时间点恢复。比如,几天前发生的拼多多优惠券漏洞被人刷掉很多钱,可以根据前一个时间点进行还原,“挽回损失”。

    以上的好处,对于以前的软件来说,是很好的方式。但是对于现如今的很多场景,已经不好用了,因为:

    • 服务需要停机。n个9肯定无法做到了。然后,以前我们的停机冷备是在凌晨没有人使用的时候进行,但是现在很多的互联网应用已经是面向全球了,所以,任何时候都是有人在使用的。

    • 数据丢失。如果不采取措施,那么在完成了数据恢复后,备份时间点到还原时间内的数据会丢失。传统的做法,是冷备还原以后,通过数据库日志手动恢复数据。比如通过redo日志,更甚者,通过业务日志去手动回放请求恢复数据。恢复是极大的体力活,错误率高,恢复时间长。

    • 冷备是全量备份。全量备份会造成磁盘空间浪费,以及容量不足的问题,只能通过将备份拷贝到其他移动设备上解决。所以,整个备份过程的时间其实更长了。想象一下每天拷贝几个T的数据到移动硬盘上,需要多少移动硬盘和时间。并且,全量备份是无法定制化的,比如只备份某一些表,是无法做到的。

    如何权衡冷备的利弊,是每个业务需要考虑的。

    2. 双机热备,和冷备比起来,主要的差别是不用停机,一边备份一边提供服务。但还原的时候还是需要停机的。由于我们讨论的是和存储相关的,所以不将共享磁盘的方式看作双机热备。

    Active/Standby模式,相当于1主1从,主节点对外提供服务,从节点作为backup。通过一些手段将数据从主节点同步到从节点,当故障发生时,将从节点设置为工作节点。数据同步的方式可以是偏软件层面,也可以是偏硬件层面的。

    偏软件层面的,比如mysql的master/slave方式,通过同步binlog的方式;sqlserver的订阅复制方式。

    偏硬件层面,通过扇区和磁盘的拦截等镜像技术,将数据拷贝到另外的磁盘。偏硬件的方式,也被叫做数据级灾备;偏软件的,被叫做应用级灾备。后文谈得更多的是应用级灾备。

    双机互备

    本质上还是Active/Standby,只是互为主从而已。双机互备并不能工作于同一个业务,只是在服务器角度来看,更好的压榨了可用的资源。比如,两个业务分别有库A和B,通过两个机器P和Q进行部署。那么对于A业务,P主Q从,对于B业务,Q主P从。整体上看起来是两个机器互为主备。这种架构下,读写分离是很好的,单写多读,减少冲突又提高了效率。

    其他的高可用方案还可以参考各类数据库的多种部署模式,比如mysql的主从、双主多从、MHA;redis的主从,哨兵,cluster等等。

    3. 同城双活,前面讲到的几种方案,基本都是在一个局域网内进行的。业务发展到后面,有了同城多活的方案。和前面比起来,不信任的粒度从机器转为了机房。这种方案可以解决某个IDC机房整体挂掉的情况(停电,断网等)。

    同城双活其实和前文提到的双机热备没有本质的区别,只是“距离”更远了,基本上还是一样(同城专线网速还是很快的)。双机热备提供了灾备能力,双机互备避免了过多的资源浪费。

    在程序代码的辅助下,有的业务还可以做到真正的双活,即同一个业务,双主,同时提供读写,只要处理好冲突的问题即可。需要注意的是,并不是所有的业务都能做到。

    业界更多采用的是两地三中心的做法。远端的备份机房能更大的提供灾备能力,能更好的抵抗地震,恐袭等情况。双活的机器必须部署到同城,距离更远的城市作为灾备机房。灾备机房是不对外提供服务的,只作为备份使用,发生故障了才切流量到灾备机房;或者是只作为数据备份。原因主要在于:距离太远,网络延迟太大

    如上图,用户流量通过负载均衡,将服务A的流量发送到IDC1,服务器集A;将服务B的流量发送到IDC2,服务器B;同时,服务器集a和b分别从A和B进行同城专线的数据同步,并且通过长距离的异地专线往IDC3进行同步。当任何一个IDC DOWN机时,将所有流量切到同城的另一个IDC机房,完成了failover。当城市1发生大面积故障时,比如发生地震导致IDC1和2同时停止工作,则数据在IDC3得以保全。同时,如果负载均衡仍然有效,也可以将流量全部转发到IDC3中。不过,此时IDC3机房的距离非常远,网络延迟变得很严重,通常用户的体验的会受到严重影响的。

    上图是一种基于Master-Slave模式的两地三中心示意图。城市1中的两个机房作为1主1从,异地机房作为从。也可以采用同城双主+keepalived+vip的方式,或者MHA的方式进行failover。但城市2不能(最好不要)被选择为Master。

     

    4. 异地双活, 同城双活可以应对大部分的灾备情况,但是碰到大面积停电,或者自然灾害的时候,服务依然会中断。对上面的两地三中心进行改造,在异地也部署前端入口节点和应用,在城市1停止服务后将流量切到城市2,可以在降低用户体验的情况下,进行降级。但用户的体验下降程度非常大。所以大多数的互联网公司采用了异地双活的方案。尤其是银行系统,大部分出于谨慎安全考虑!

    流量经过LoadBalance后分发到两个城市的服务器集群中,服务器集群只连接本地的数据库集群,只有当本地的所有数据库集群均不能访问,才failover到异地的数据库集群中。

    在这种方式下,由于异地网络问题,双向同步需要花费更多的时间。更长的同步时间将会导致更加严重的吞吐量下降,或者出现数据冲突的情况。吞吐量和冲突是两个对立的问题,你需要在其中进行权衡。例如,为了解决冲突,引入分布式锁/分布式事务;为了解决达到更高的吞吐量,利用中间状态、错误重试等手段,达到最终一致性;降低冲突,将数据进行恰当的sharding,尽可能在一个节点中完成整个事务。

    *** 对于个别一致性要求很高的应用,还有提供一种强一致的方案(Global Zone),Globa Zone是一种跨机房的读写分离机制,所有的写操作被定向到一个 Master 机房进行,以保证一致性,读操作可以在每个机房的 Slave库执行,也可以 bind 到 Master 机房进行,这一切都基于我们的数据库访问层(DAL)完成,业务基本无感知。

    5. 异地多活, 基于异地双活建设,但是要考虑到业务的延迟和数据的阻塞,最好采用中间负载服务器,将最近的业务请求转发到最近的服务器交互。

    ------------- 待定。

     

     

     

     

    展开全文
  • 详细描述了如何实现SQL SERVER数据库双活,包括最高等级的数据零丢失容灾,全自动(不需要修改客户代码的)负载均衡读写分离等功能。
  • 本PostgreSQL数据库双活部署实例使用Bucardo开源工具实现,Bucardo开源工具是一个perl语言编写的程序,其依赖PG数据库的plperl语言组件,进而严格依赖perl的版本(数据库服务器安装的perl大版本号必须和官方说明的...
  • 数据库双活和ALWAYSON相比的四大优势: 1.容灾:ALWAYSON是一主一备,主的突然故障,备的能否切换?切换后数据是否丢失?这都会有 问题的。数据库双活双活,任何一个节点突然故障,另外一个节点数据零丢失,服务 ...
  • 某银行中有关双数据中心对数据库双活和灾备的建设经验。
  • ...
  • 异地服务器间数据同步实时备份+数据库主主双活.zip

空空如也

空空如也

1 2 3 4 5 ... 15
收藏数 292
精华内容 116
关键字:

双活数据库