精华内容
下载资源
问答
  • 容灾设计学习笔记

    千次阅读 2017-09-24 16:26:40
    逻辑层服务一般都设计从无状态服务,客户端当前请求和下次请求在逻辑层没有任何的关联,因此客户端可以在在多次请求中分别到不同的机器上,而返回的结果和一直在同一台机器上一样。由于这种特性的存在使得逻辑层可以...

                          容灾设计学习笔记

     

    一:逻辑层容灾:

        逻辑层服务一般都设计从无状态服务,客户端当前请求和下次请求在逻辑层没有任何的关联,因此客户端可以在在多次请求中分别到不同的机器上,而返回的结果和一直在同一台机器上一样。由于这种特性的存在使得逻辑层可以通过多级备份来实现容灾。

    备份可以有 :主备(1+1), 一主多备(1+n),多主一备(n+1), 无备(1+0),互相备份(n)

     

       切换的策略可以为:

       冷切:即主完全承担所有业务,当主不可服务时再启用备,该方式由于备机一直处于不服务状态,会出现当要切换到备的时候,备也不可服务,可信度低。

        热切:主和备一起分担所有请求,主备只承担部分业务请求(总和为100%)。这样可以解决之前的冷切遇到的信任度低的问题。同时业务由主备共同分担,节约成本。但是在主完全不可服务时,备有过载的风险。这里可以没有主备之分,在我们的实践中常用多台机器组成的集群来实现互为备份。

        双在线:主备各跑100%的任务。这个可以同时解决上面的遇到的问题。但是成本高(带宽、电力、机房维护成本等)

     

    二:数据层容灾:

        相对于逻辑层是无状态的服务,数据层服务需要存储和用户相关的数据,用户的多次请求之间的数据是有关联的。因此如何在多机容灾备份的情况下保证数据一致性成为一个关键问题。

        数据一致性的问题:

        最终一致性:这个是弱一致性的一种,不保证在任意时刻同一份数据在所有节点上都是一致 的,但是在一段时间之后时间会最终一致。对于我们互联网的应用来说大多数是采用这种策略。

        强一致性:在任意时刻同一份数据在所有节点上都是一致 的。对于银行、金融行业来说基本采用这种策略。

        中心化备份策略:

        在传统的数据库、数据服务器设计中往往采用中心化的的模型。每台机器中存储全量的数据,其中有只有一台可写的主机,有一台或多台机器可读的备机去同步主机的数据。当主机不可服务时,其中一台备机升级为主机。

        数据增量同步:只对有更新的数据进行同步, 当主机有数据更新时, 会先在本地生成Binlog及同步相关的信息,主机与备机之间通过一定的协议将数据同步到备机。

        数据全量同步: 每次都全量同步主机的数据。一般会一段时间内做一次,是增量同步的一个补充。可以一块一数据计算MD5值进行比较,只同步MD5值不相等的数 据快。

        问题:只有一台可写容易出现单点问题(虽然可以切换,但是还是会在一定时间内不可服务)、由于网络问题可能出现多主。

        去中心化备份策略

        相对于中心化只有一个主可写,其他备机都只是同步主机的数据,去中心化没有主备之分, 所有的机器都可读可写,这样写的性能会有很大的提高,但是要做到数据的一致性比较复杂。目前主要的设计方案有: RNW协议、2pc、3pc协议、paxos协议等,有兴趣的同学可以用自己去了解。

     

    三:容灾判定:

        我们有了容灾的可行性方案,现在看一下如何去判断是否出现了问题。

        中央判断

        中心主动探测:该方法是中心主动和其他子系统或服务定时发送消息(可用私有协议或ping消息等),根据回包来判定服务是否可用。

         等待服务上报:该方法是子系统或者服务,又或者是专门agent主动的将服务的运行状态上报给中心系统,中心系统通过上报消息来判定服务是否运行正常。

        上述两种策略相结合的方式。

        请求者判定:

        即服务的使用方将根据请求的服务状态(延迟、是否成功等信息)来判定服务是否正常,请求者在本地记录这些信息,只将请求发送到那些正常的服务。这种方式相对于中央判定可以防止中心和其他子服务之间由于网络问题而导致误判。

     

    四:异地部署:

        某些重要的服务为了在局部的网络不可用、自然灾害等问题时也能保证服务的可用性,需要将服务部署在不同的城市、机房。这样一方面可以保证服务的可靠性,也可以让不同地区的用户就近访,提高服务质量。

     

    五、负载均衡:

        接入负载:通过代理服务将服务分发到不同的机器上,这个可以通过单独部署负载均衡服务器、LVS、DNS、http重定向、nginx方向代理、NAT等实现。

        号段负载:通过请求自身的特殊性将不同的请求分发到固定的服务上进行处理。如通过一致性hash将hash值相关的请求路由到固定的服务,也可以将固定号段的qq号路由到固定的服务。如何分配不够离散化,可能会导致某些热点请求都集中在同一台服务,从而导致负载不均衡。

        用户自助负载:这种类似于游戏服务器中用户选择不同的服来分配不同的机器,达到将不同的请求分配到不同的机器的目的。

     

    六:过载保护:

        当负载达到系统处理能力的上限时,系统的处理能力将随着负载的增加急剧下降,俗称滚雪球。在系统设计的时候做好过载保护是一项很重要的工作。过载保护的方法有:

        1:轻重分离、隔离部署:将系统、业务、功能隔离部署(可以分不同的set),确保系统过载状态不会扩散到其他业务系统,对其他业务系统造成影响,使得影响最小化。

        2:频率控制:控制单位时间内的请求量(可以是总的请求量也可以是单个用户的请求量),这样可以保证系统在过载的时候不会被压垮,保证部分用户的请求可以被处理。

        3:设置请求的有效时间: 用户的请求都期望在一定时间范围内返回结果。如果没有返回则会当做超时出错处理。如果服务端一直在处理这样的请求,那么其实是在无用功,对用户没有如何意义。因此我们需要对每个请求做超时限制,在一定的时间内没有处理完则丢弃该请求,理想的状态是从收到请求开始计时,这样可以防止数据包在队列中已经超时。

        4:有损服务:服务做好有损处理,当系统过载时,可以将某些非关键性的服务下掉,从而保证关键业务可以正常服务。如果是底层非关键性的服务过载,则可以不去请求该服务的数据而直接反回给前端。同时前端也可以做相应的有损策略,防止后台服务过载时给用户不好的体验。

     

    七:常见的互联网事故及解决策略

           

    服务器硬件故障死机:集群部署、多机备份、自动检测并切换

    网络丢包、光钎断:异地部署、自动检测故障并切换

    服务器雪崩:负载均衡、过载保护、容量告警

    外部依赖故障:柔性逻辑、降级服务、限制重试

    DNS故障 :自搭建类DNS服务、使用IP列表替代DNS

    程序CORE:自动拉起、实时告警

    操作失望:灰度、保护逻辑、人员备份确认

     

     

    展开全文
  • 点击下方公众号「关注」和「星标」回复“1024”获取独家整理的学习资料!今天谈下多数据中心和异地容灾备份方面的内容。在前面一篇文章里面我详细谈到过一个软件业务系统的高可用性设计,其中既包括...

    点击下方公众号关注星标

    回复“1024”获取独家整理的学习资料!

    今天谈下多数据中心和异地容灾备份方面的内容。在前面一篇文章里面我详细谈到过一个软件业务系统的高可用性设计,其中既包括了IT基础设施的高可用,也包括了业务软件系统设计方面的高可用性设计。

    对于高可用,我想再简单总结下,核心为三个方面的内容:

    • 高可靠:冗余性设计,无任何单点故障

    • 高性能:能够满足大数据量或海量并发访问下响应需求

    • 高扩展:能够动态水平弹性扩展 对于三者之间的关系,我前面整理过下面一个图来进一步说明:

    上图可以看到高可靠,高性能和高扩展性三者之间的关系。

    对于高可靠性来来说,传统的HA架构,冗余设计都可以满足高可靠性要求,但是并不代表系统具备了高性能和可扩展性能力。反过来说,当系统具备了高扩展性的时候,一般我们在设计扩展性的时候都会考虑到同时兼顾冗余和高可靠,比如我们常说的集群技术。

    对于高性能和高扩展性两点来说,高扩展性是高性能的必要条件,但是并不是充分条件。一个业务系统的高性能不是简单的具备扩展能力就可以,而是需要业务系统本身软件架构设计,代码编写各方面都满足高性能设计要求。

    对于高可靠和高性能,两者反而表现出来一种相互制约的关系,即在高性能支撑的状态下,往往是对系统的高可靠性形成严峻挑战,也正是这个原因我们会看到类似限流熔断,SLA服务降级等各种措施来控制异常状态下的大并发访问和调用。

    容灾备份概述

    前面谈高可靠性可以看到,我们更多的还是谈的在一个数据中心里面的冗余和集群设计,以确保整个IT基础设施架构没有任何的单点故障。但是如果整个数据中心都出现问题,那么我们的应用自然会受到影响处于不可用状态,同时我们的数据存储也存在丢失的问题。

    这也是我们谈容灾备份,很多大的集团企业建设自己的两地三中心的一个原因。

    什么是容灾备份?

    对于容灾,简单来说就是当数据中心发生各种未知灾难的时候,能够确保数据不丢失或少丢失,同时IT业务系统能够不间断运行或快速切换恢复。

    这里面实际上强调了两个重点, 即:

    • 数据本身不丢失或少丢失

    • 应用本身不间断或少间断

    整个容灾设计就是围绕这两个关键目标来实现。

    而对于容灾备份则是通过在异地建立和维护一个备份存储系统,利用地理上的分离来保证系统和数据对灾难性事件的抵御能力

    根据容灾系统对灾难的抵抗程度,可分为数据容灾和应用容灾 。

    • 数据容灾是指建立一个异地的数据系统

    • 应用容灾比数据容灾层次更高,即在异地建立一套完整的、与本地系统相当的备份系统

    当前可以看到,我们更多的已经不再是间断的数据层面的容灾备份,而是需要具备保持业务连续性的应用级容灾能力。

    简单来说,就是我们需要设计要整体应用所涉及到的IT基础设施,数据库,应用中间件和应用部署包全部在2个数据中心进行部署。部署完成的架构需要确保即使某一个数据中心完全瘫痪,也不应该影响到业务系统的正常运行和连续性。

    对于容灾等级的定义可以参考下图:

    从图中可以看到,如果要实现业务系统本身的异地双活和不间断运行,那么就必须达到第七级的异地同步应用容灾的标准。即是:

    在异地建立一个与生产系统完全相同的备用系统,他们之间采用同步的方式进行数据复制。当生产中心发生灾难时,备用系统接替其工作。该级别的容灾,在发生灾难时,可以基本保证数据零丢失和业务的连续性。

    也正因为如此,我们看到,多数据中心之间的数据库同步复制能力将是构建一个异地同步容灾备份设计的关键内容。

    数据库同步复制技术

    前面已经谈到,要实现应用级的容灾备份,一个关键就是通过数据库的实时同步和复制,在A地出现机房故障和问题的时候可以平滑快速的迁移到B地。虽然这种远程数据复制和同步存在一定的延迟,但是基本已经可以满足业务连续性的需求。

    谈到数据库的实时复制,一般会谈到一个重要产品,即Oracle公司的GoldenGate,该软件是一种基于日志的结构化数据复制软件,它通过解析源数据库在线日志或归档日志获得数据的增删改变化,再将这些变化应用到目标数据库,实现源数据库与目标数据库同步、双活。

    GoldenGate可以在异构的IT基础结构(包括几乎所有常用操作系统平台和数据库平台)之间实现大量数据亚秒一级的实时复制。

    GoldenGate是一种基于软件的数据复制方式,它从数据库的日志解析数据的变化(数据量只有日志的四分之一左右)。该将数据变化转化为自己的格式,直接通过TCP/IP网络传输,无需依赖于数据库自身的传递方式,而且可以通过高达9:1的压缩率对数据进行压缩,可以大大降低带宽需求。在目标端,GoldenGate TDM可以通过交易重组,分批加载等技术手段大大加快数据投递的速度和效率,降低目标系统的资源占用,可以在亚秒级实现大量数据的复制。

    GoldenGate的工作原理可以用下图描述:

    在任何实时数据同步和复制中,需要考虑如下几个关键问题:

    • 事务一致性:在复制目标端需要按照源端相同的事务环境进行,确保目标上数据一致性。

    • 检查点机制:在抽取和装载时都需要记录检查点,确保网络故障下仍然能够完整复制。

    • 可靠数据传输:需要保证数据传输的完整性,请求和应答,同时提供数据加密压缩。

    对于数据实时同步和复制工具,其核心是需要基于日志来实现,这一方面是可以实现准实时的数据同步,一方面是基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束。我们也看到有些基于数据库表设计增加触发器或存储过程来实现的数据库复制,这些本身都是损耗了性能和增加了复杂度。

    对于数据库的实时同步和复制,阿里巴巴专门有一个开源项目,即otter来实现分布式数据库的同步复制,其核心思想仍然是通过获取数据库的增量数据日志,来进行准实时的同步复制。因此otter本身又依赖于另外一个开源项目即canal,该项目重点则是获取增量数据库同步日志信息。

    当前otter的重点是实现mysql间的数据库同步复制,其实这个在前面我一些文档里面谈到基于mysql数据库的dual-master架构的时候已经谈到过,基本即利用的类似技术来实现两个mysql数据库间的双向同步数据库复制。

    要注意这个双向本身指既可以A->B,也可以从B->A,在某个时间节点本身是单向的。

    对于otter的功能和支持的数据库比GoldenGate要少得多,除了支持mysql数据库间的实时数据同步和复制外,还支持mysql->oracle的单向数据同步和复制。但是不支持oracle->mysql的数据同步和复制。但是otter本身提供了一个很好的开源框架,我们可以基于该框架扩展对其它数据库的支持。

    在扩展的时候有一个重点,即数据库本身是否提供了增量数据日志,对于mysql数据库容易实现其主要原因还是mysql数据库提供了相当方便的binlog日志功能,这些log日志本身就很方便的转换为朝目标端执行的sql语句。

    而对于常见的数据库,在网上搜索下,可以看到一些做法。

    对于oracle,重点是监控oracle的redo log,即在线重做日志和归档日志。对于一些商用产品可以直接监控到redo log,仅仅依赖于该文件而不耗费其它资源。而如果我们来实现,则常用的方法还是基于oracle logminer来对redo log进行解析。虽然性能上稍微有差异,但是基本可以达到准实时的数据库解析和同步。

    对于Sql Server数据库的日志分析,首先可以看到网上有一个专门的商业工具,即log explorer,这个工具可以用来做sql server数据库的日志解析和分析。其中对于事务,检查点等都有详细的记录。其次可以使用fn_dblog解析Sql Server的数据库日志,网上有专门的方法在这里不展开,现在还没有具体测试过,但是整个方法思路是没有问题的。

    而对于sql server 之间的数据库同步和复制,则sql server本身就提供有方便的基于快照或基于事务的数据库同步复制工具,只需要经过简单的配置即可以实现。正因为这个原因,我们也看到,对于sql server数据库本身在日志解析和分析方面开放出来的能力本身是相当较弱的。

    随着国家对自主研发数据库和中间件技术的大力支持,当前还没一个能够实现国产数据库如人大金仓,达梦数据库同国外的oracle ,sql server数据库间的数据实时同步和复制工具。对于这类工具是可以基于开源otter产品的思路来进行定制开发和实现的,但是前提还是各个数据库厂家需要开放相应的日志采集和处理能力。

    基于GoldenGate实现数据库同步复制

    GoldenGate TDM(交易数据管理)软件是一种基于日志的结构化数据复制软件,它通过解析源数据库在线日志或归档日志获得数据的增删改变化,再将这些变化应用到目标数据库,实现源数据库与目标数据库同步、双活。

    GoldenGate TDM 软件可以在异构的IT基础结构(包括几乎所有常用操作系统平台和数据库平台)之间实现大量数据亚秒一级的实时复制,其复制过程简图如下:

    GoldenGate TDM的数据复制过程如下:

    利用捕捉进程(Capture Process)在源系统端读取Online Redo Log或Archive Log,然后进行解析,只提取其中数据的变化如增、删、改操作,并将相关信息转换为GoldenGate TDM自定义的中间格式存放在队列文件中。再利用传送进程将队列文件通过TCP/IP传送到目标系统。捕捉进程在每次读完log中的数据变化并在数据传送到目标系统后,会写检查点,记录当前完成捕捉的log位置,检查点的存在可以使捕捉进程在终止并恢复后可从检查点位置继续复制;

    目标系统接受数据变化并缓存到GoldenGate TDM队列当中,队列为一系列临时存储数据变化的文件,等待投递进程读取数据;

    GoldenGate TDM投递进程从队列中读取数据变化并创建对应的SQL语句,通过数据库的本地接口执行,提交到数据库成功后更新自己的检查点,记录已经完成复制的位置,数据的复制过程最终完成。

    由此可见,GoldenGate TDM是一种基于软件的数据复制方式,它从数据库的日志解析数据的变化(数据量只有日志的四分之一左右)。GoldenGate TDM将数据变化转化为自己的格式,直接通过TCP/IP网络传输,无需依赖于数据库自身的传递方式,而且可以通过高达9:1的压缩率对数据进行压缩,可以大大降低带宽需求。在目标端,GoldenGate TDM可以通过交易重组,分批加载等技术手段大大加快数据投递的速度和效率,降低目标系统的资源占用,可以在亚秒级实现大量数据的复制,并且目标端数据库是活动的

    GoldenGate TDM提供了灵活的应用方案,基于其先进、灵活的技术架构可以根据用户需求组成各种拓扑结构,如图所示:

    GoldenGate TDM 可以提供可靠的数据复制,主要体现在下面三点:

    保证事务一致性

    GoldenGate TDM 在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同,并且按照相同的事务环境提交,确保在目标系统上数据的完整性和读一致性,为实时查询和事务处理创造了条件。

    检查点机制保障数据无丢失

    GoldenGate TDM的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程,其检查点记录当前已经抽取日志的位置和写队列文件的位置;对于投递进程,其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或GoldenGate TDM进程故障重启后数据无丢失。

    可靠的数据传输机制

    GoldenGate TDM 用应答机制传输交易数据,只有在得到确认消息后才认为数据传输完成,否则将自动重新传输数据,从而保证了抽取出的所有数据都能发送到备份端。数据传输过程中支持128位加密和数据压缩功能。

    Oracle 公司的GoldenGate产品,可以在异构的IT基础结构之间实现大量数据的秒一级的数据捕捉、转换和投递。GoldenGate可以支持几乎所有常用操作系统如和数据库平台:

    操作系统支持:MS NT, 2000, XP, Linux, Sun Solaris, HP-UX, IBM AIX, HP NonStop, TRU64, IBM z/OS,OS/390 数据库支持:Oracle, DB2, MS SQL Server, MySQL, Enscribe, SQL/MP, SQL/MX, Sybase, Teradata, 其他ODBC 兼容数据库

    GoldenGate的应用场景-容灾和应急备份

    其中一主一备,快速恢复和切换,最小化数据损失,重新同步主备两端数据。主库数据变化能够实时的同步到备库,用途主要是在非计划性停机时候保持业务的连续性。

    GoldenGate的应用场景-减少计划内停机

    主要是保障业务零或近似零停机,在滚动升级中降低业务中断带来的损失。主要用途是保障系统/应用/数据库在升级,移植和维护期间业务的可用性。

    GoldenGate的应用场景-双业务中心

    主要是实现负载均衡(需要考虑全局多点的负载均衡,既提高性能,又避免业务中心的整体单点故障),提供系统整体性能。保障连续可用,快递的容灾接管,实现冲突的监测和处理。

    业务系统数据库双活和主备设计

    首先我们还是回顾下业务系统容灾备份设计的目标究竟是什么?

    简单来讲就是要避免在单个数据中心出现无预知灾难的时候,整个数据不丢失,整个应用仍然能够正常持续运行。而对于持续不间断运行,我们仍然可以分为两个层面。

    • 完全不间断,自动实现切换,对业务无感知

    • 短暂间断,需要人工手工切换负载均衡或IP地址完成

    对于生产运营类的企业IT系统需要做到完全不间断,而对于内部管理类的信息系统往往做到短暂间断也可以接受。比如我们常说的电信运营商的BSS域系统,那么就需要做到完全不间断自动切换,而对于MSS域围绕ERP管理系统等,能在30分钟内完成切换调整就可以满足需求。

    对于一个双业务中心的设计,可以看到里面有两个重点,一个就是数据库本身的双活设计,还有一个就是应用服务器集群本身的双活设计。

    数据库双活或主备设计

    对于数据库本身的技术种类,对双活读写的支持,数据延迟的大小,可靠性等可以参考上图进一步了解。在考虑双活数据库设计的时候可以重点参考。

    对于双业务中心和异地双活设计,前面我很多文章都已经谈到过,实际上最难的就是数据库如何保证双活,大部分的异地容灾方案数据库本身都是单活的,一个作为备份库。

    对于数据库双活和主备设计,实际上在数据库层面分为三个层面。

    • 数据库单活:一个做为备份库,平时不工作,在出现问题再动态切换

    • 数据库写单活,读双活:只有主库可以写,但是两个数据中心数据可以同时读

    • 数据库双活:即表格里面谈到的Oracle ASM Extended RAC方案,这个没怎么接触过

    对于应用服务器的Cluster集群,实际要做到双活就比较简单,由于不存在数据持久化的问题,因此只需要搭配上层的全局负载均衡往往就容易实现上层应用服务器集群的双活配置。

    方式1:通过GoldenGate来实现数据库单活设计

    对于GoldenGate既支持数据单向复制,也支持数据库双向同步复制。

    我们可以通过数据库单向复制来实现数据库的主备模式双活,即一个作为Master主节点数据库,一个作为Standby的备库。如下:

    当主库出现无法预知的灾难故障的时候,我们可以将访问切换到备库节点上,在主库节点恢复后备库节点重新返回备库模式,前端访问用户也重新连回到主库节点。

    也就是说在主库恢复后,实际上还有一个过程即:

    备库上所做出的修改和更新需要实时同步更新回主库。

    因此虽然说这种模式是数据库单向复制,实际上是指在某一个时点只允许一个方向的数据流。而不是说数据只能够从主节点朝备节点同步。

    方式2:通过GoldenGate来实现数据库双活设计

    对于数据库双活设计即可以采用GoldenGate数据库双向同步复制来实现。实际上我们并不建议这种方式,主要是以下几个方面的考虑。

    即在数据双向复制的情况下对应用系统本身的设计会有额外的要求,比如全局序列号的起始值的规划,如何防止数据循环复制,如果网络存在延迟,如何确保一个大的业务操作实时的数据一致性要求等。这些往往都是双活数据库本身存在的问题。

    其次,在数据库双活设计下,应用集群和数据库间往往存在两种方式如下:

    对于方式1即应用集群只固定访问同数据中心的数据库,对于方式2即应用集群全部访问上层两个数据库暴露的VIP地址,通过VIP来确定访问两个数据库。

    对于方式1我们看到,实际上在数据库中心A的数据库宕机后,由于应用集群可能没有宕机,那么全局负载均衡仍然会分发路由请求给应用集群A,这个时候实际仍然出现访问中断的情况。

    而对于方式2采用了数据库VIP后,虽然解决了上面的问题,但是很容易出现应用集群A要跨域访问到数据库中心B的数据库服务的情况。

    也就是在采用浮动VIP时候,希望是要做到应用集群A优先访问数据库A,只有当数据库A出现故障的时候才路由访问数据库B。

    方式3:不采用GoldenGate的思路

    如果不采用GoldenGate,那么我们就需要手工去处理以保证两个数据库间的数据同步复制。在我们实施ESB服务总线项目的时候,由于数据库实例本身无状态和一致性要求,因此我们完全可以采用晚上定时进行数据库增量脚本同步的方式来同步数据。

    其次,对于修改元数据的相关操作,则需要应用程序同时在两个数据中心的数据库同时进行操作,这个同时操作也可以通过应用自动实现,也可以人工同时操作,毕竟对元数据配置修改往往本身就是低频操作。

    全局负载均衡和智能DNS路由

    当我们谈双活数据中心的时候,前面更多谈的数据库的部署和同步方案,既然是双活,那么APP Server应用服务器就必须要做到能够同时工作。而对于应用服务器集群我们考虑的时候要注意,实际上在我们配置的时候,数据中心A和数据中心B两个集群都是操作数据中心A的数据库,否则就会出现数据库双向同步复制问题。

    要做到应用集群双活,在前面文章方案已经谈到,必须在数据库中心A和B上面还有一个全局的负载均衡设备进行全局负载均衡,同时全局负载均衡设备本身还需要HA配置确保无单点故障。

    对于最终用户的访问,我们企业DNS域名进行访问。

    同时在两个数据中心配置智能DNS设备,本身进行HA架构冗余设计,如下。

    智能DNS设备实际上要完成的事情很简单,就是用户通过域名访问,智能DNS能够返回具体某个数据中心的上层负载均衡IP地址信息。

    我们以单活架构来进行说明如下:

    • 用户通过域名访问,将请求发送给智能DNS解析设备

    • 智能DNS在主数据中心正常情况下返回主数据中心的负载均衡IP地址

    • 在获取到IP地址后,应用再发起对主数据中心的实际业务访问

    如果主数据中心本身出现灾难宕机

    那么这个时候请问到DNS的时候则返回数据中心B的负载均衡IP地址信息。这个时候备库数据库自动变化为主库承担应用的读写任务。

    应用集群本身的Admin设置和应用部署

    对于应用服务器集群,往往会有一个Admin集群管理节点,通过Admin可以实现对应用集群内所有节点的状态监控,应用的部署,负载均衡等相关操作。

    即使我们采用了类似F5等负载均衡设备,往往集群仍然需要设置管理节点以方便集群监控和应用程序的部署。

    那么在启用双数据中心后可以看到,对于Admin节点建议仍然是在两个数据中心各自一套,即应用程序的更新和部署仍然在两个数据中心各自手工部署来完成。特别是在主备模式下,这种手工方式处理基本没有任何影响。

    但是如果在双活架构模式下,如果手工完成往往就存在一定的延迟性的问题。

    这个实际又有两种解决方案和思路。

    • 其一是通过一个Admin来管理两个数据库的所有集群节点

    • 其二是通过灰度发布策略等方法来控制部署时间上的延后

    对于第一种方式实际我们不建议,其本身增加了了两个数据中心集群的耦合度,同时本身管理的复杂度,集群本身的状态一致性保证复杂度都会增加。最好的方式仍然是通过灰度发布等策略控制来解决该问题。

    作者:人月神话  

    https://www.toutiao.com/i6874741202076303883/

    推荐阅读 点击标题可跳转

    超牛逼!这款轻量级性能监控系统真强大~

    从 0 到 1 手把手教你制作酷炫可视化大屏

    超详细!K8s 面试题总结

    这篇 ElasticSearch 详细使用教程,内部分享时被老大表扬了

    MySQL 8.0 的 5 个新特性,太实用了!

    软件系统高可用架构思考

    这一份最全的TCP总结,请务必收下

    API 快速开发平台设计思考

    展开全文
  • 系统容灾设计 计费系统的每个数据都和钱息息相关,系统不稳定,数据不可靠直接损失的是钱,主要面临着以下的核心问题, 怎么样保证系统与数据的可靠与稳定,是我们系统在容灾设计上需要去重点考虑的点: 这些问题我们是...

    822df352121a6f3476d1f07bd639b184.png

    互联网广告系统本身是一个对稳定性和可靠性要求极高的系统,每天面对数十亿级别的请求,广告投放主多样的投放方式变化与用户关注点及兴趣频繁的更新,同时对时效性要求严格,而作为电商广告的计费系统,则要求更加严格, 从打点到计费任何一环节出现问题,都会带来巨大的经济损失和平台信任度危机,涉及到商家账户资金,系统实时反作弊和防刷,亿级别点击(曝光)等高效稳定账务扣费,数据的强一致性和最终一致性的保证及全链路高效可靠的监控..

    本次主要介绍下蘑菇街广告计费系统的持续优化改进中,系统容灾方面做的一些事情

    一.计费系统介绍:

    广告对很多互联网公司营收占有非常重要的比重,对互联网广告大家应该不陌生,日常pc和app应该见过很多(弹窗广告,视频广告等),电商来说也是非常重要的营收方式,那么这些广告是怎样计费的,先来了解下几种常见的计费模式

    CPC(Cost Per Click ) : 按点击计费的商业产品,对于电商,常用于站内广告资源位,用于推广商品
    CPS (CostPer Sale ) :按成交计费的商业产品,站外引流,站外长尾流量,用于推广商品/店铺
    CPM(Cost Per Mille, 或者Cost Per Thousand;Cost Per Impressions) : 按曝光计费的商业产品,站内banner位等资源,用于推广品牌店铺
    其他还有比较常用的,如:CPD(按天计费),CPT(按时间计费),CPA(按激活或者行为等).

    广告计费系统的数据流,如下图所示:

    5b5f2bb39a9dace236c4331ee28841f7.png
    计费系统模块图

    数据来源:web端用户对广告触发行为产生数据,主要是广告资源位上广告的曝光,点击等

    数据收集:用于接收web产生的广告数据,为了保证下游系统的稳定性,盗刷及恶意流量一般这层要给拦截住,核心必须保证性能高效及数据防刷功能

    数据处理:广告系统计费最核心的功能部分,主要是计费数据的处理,涉及到计费策略,计费金额核算,反作弊及对余额或者预算不足广告进行上下架等操作

    数据存储:主要是对处理过的流水,账务及广告数据的持久化

    和数据流结构对应,我们来了解下蘑菇街现在广告计费系统,整体架构如下,其中billingWorker是处理计费数据最核心的程序,unionLogAgent是自研支持规则定制和流量切分的数据收集程序,后面会对每个部分的技术及设计做重点的介绍.

    a01bec2b3cad124838b6870352ac7b78.png

    二.系统容灾设计

    计费系统的每个数据都和钱息息相关,系统不稳定,数据不可靠直接损失的是钱,主要面临着以下的核心问题, 怎么样保证系统与数据的可靠与稳定,是我们系统在容灾设计上需要去重点考虑的点:

    4026001516ab03b5a0f61f95c71a0212.png

    这些问题我们是怎样考虑的了?接下来主要从数据/系统/链路完整性及监控方面重点介绍蘑菇街广告计费系统的容灾设计.

    1.数据流

    数据流面临的问题:

    1.恶意流量攻击,异常数据对系统的冲击

    2.数据回溯,快速定位失败数据

    3.链路数据的一致性,数据丢失或者重复

    面临着数亿级别曝光和点击,既要保证数据的一致性,不发送漏扣或多扣,又要保证系统的稳定可靠,整体在设计阶段必须重点考虑系统的容灾,先介绍下我们在数据采集阶段的设计.

    ▶数据采集

    数据采集阶段,从整体的设计上,必须满足三个目标:

    1.采集程序的性能要高效,尽量做到业务无关性,能弹性面对我们的热点流量
    2.我们期望在最上层就将恶意流量拦截掉,避免对下游冲击,面对恶意盗刷或攻击(人为或者第三方程序刷点击,刷曝光,爬虫),能快速灵活定制化我们的规则拦截无效流量
    3. 保证系统的稳定及能快速恢复,并且做到简单快速并保证无数据丢失

    最开始在技术选型方面,主要考虑以下3种方案:

    2bf130fadf26d9003f8c4de306470418.png

    最终采用方案1-2,优点是 :

    1.nginx只管接收数据, 日志落盘和收集解耦,不会有任何业务逻辑,能保证性能的高效

    2.unionlogagent独立开发,完全自己维护,并提供防刷模块,支持规则定义及流量拆分,可以有效拦截高频恶意流量

    3. 定制优化kafka客户端,对于每一条消息无论成功或失败都进行ack操作,确保不会出现数据丢失的可能

    4. unionlogagent会实时持久化成功最小offset,出现异常能快速恢复并能快速自动回溯数据

    方案0:公司默认的方案0,最大的问题是unionlog采用php,由于php线程切换导致性能不会很高,同时利用共享内存缓冲, 共享内存容量有限,面对热点流量冲击时,会造成共享内存满,数据丢失..同时logagent采用scala的kafka客户端,当客户端超时,消息重试3次仍失败,会丢弃而且业务无感知,可能造成数据丢失

    方案2:数据收集和下发耦合,收集程序出现异常及重启过程,也会造成数据丢失,同时依赖web容器,环境重,性能无法比拟单纯nginx

    其中unionlogagent主要的架构图如下:

    c233f7583ba8f2f4b26c6749c8c35761.png

    防刷模块:主要是根据时间跨度,MD5校验和小黑屋来拦截异常流量

    时间跨度,曝光和点击时间差或点击数据与当前时间差较大,就认为是异常流量,重点针对爬虫或者单接口攻击

    MD5校验,会有前端用户身份标示及后端动态口令,保证数据的有效性,能有效拦截各种盗刷及恶意分享产生的行为

    小黑屋更多和反作弊结合,根据用户某段时间的行为做黑名单处理

    构造MD5唯一ID,这个是非常重要的点, 会对每条日志生成唯一身份标示,对日志追踪有非常重要的作用

    unionlogagent还通过一套ACK机制,会持久最小成功offset的持久化,能支持下游链路灾备的切换,保证系统的容灾及数据的快速恢复及回溯

    ▶数据缓冲

    数据缓冲部分的设计就比较简单,主要的消息中间件是用kafka, 通过redis做灾备(轻量级,出问题恢复时间及数据量可控,redismq能稳定支持)

    d433ccdf56d7b3cd494562d7aff0c637.png

    之所以选用kafka,主要是kafka对于数据的持久性可靠性能保证,同时容错性做得非常好,比如kafka我们设置的副本数是3个,4台机器,就算集群中2台机器出现问题, 整个集群也能正常运行,同时在高并发和高吞吐上kafka也能很好的满足

    这里要着重补充一点,为了保证kafka整个集群分区数据的一致性,我们将kafka的ack等级设置为all,保证异常情况就是出现主从分区切换,也不会出现数据丢失

    ▶数据处理

    计费系统最核心的部分就是数处理,最核心功能是消息分发的负载均衡 及 消费端异常的接管,同时能支持很好的水平扩展, 这部分的设计,最终选用方案1

    我们利用了kafka本身有partition的机制及容灾方面非常好的设计,基于kafka+zk的方式实现动态的负载均衡和调度,整个过程根据partition和billingWorker的数量,采用固定策略做自动负载分配及接管,无需人工参与,异常情况系统也具有自愈功能

    71e89b60cde957014e306a0101dc3970.png

    当有新的partition进行扩展或者billingWorker出现异常或者扩容,系统能自动重新分配partition和消费的billingworker,支持系统自愈和平滑扩容的功能.

    ▶数据一致性

    链路比较长,核心主要在两个阶段:数据收集和数据处理.中间面临着很多问题:每个节点的故障,kafka分区的切换,计费程序的故障,DB操作失败等等

    出现这些问题时,怎样保证数据不丢失不重复,从全局能保证数据的一致性, 异常数据能够被系统感知并快速消费,因此只有在每个阶段消费成功的offset能够被追溯, 在出问题时才能快速定点恢复异常数据

    要保证全局的一致性,那必须先保证局部的一致性,因此我们设计了两套ack机制来保证我们的数据一致..两套ACK机制的核心思想如下:

    d7fcaed56676fda06089465325cb44a2.png

    最小成功offset持久化保存,能支持失败数据快速回溯,利用fail队列支持重试机制,通过数据收集和数据处理阶段的ACK机制,通过局部数据的一致性,最终保证全局数据的一致性

    2.系统容灾

    系统稳定性面临的问题

    1.系统幂等,扣费时效性及热点数据处理

    2.系统大流量的冲击,系统的雪崩

    3.自身AB及不停服切换,平滑升级

    ▶系统幂等性

    为了保证数据具有去重功能,过程中需要对于失败数据的重复消费,灵活快速回溯各种数据,而且最终要避免多扣,那么扣费系统需要“幂等”功能,对于有状态环节,同一数据结果必须幂等,实现计费链路去重逻辑.

    ae0bef7b44eb09d4159433dfe987fa71.png

    系统上为了实现幂等,首先必须保证每条数据的唯一性,刚刚在数据采集阶段也说过,日志的生产端的时候,就会构造单条扣费日志唯一性主键(GUID).

    其次整个数据流上要做到无状态,整个系统有状态的环节,其实主要有两部分,一是:反作弊程序, 主要是由于反作弊规则中单用户对单广告有类似次数限制的规则,二是:计费程序,要保证这个阶段中间任何一环节,重试机制都需要加入去重逻辑,保证程序的幂等

    讨论过很多次,从稳定又简单的方案考虑,我们最终选用缓存的方式保证反作弊唯一结果,DB的唯一索引来保证计费的去重逻辑

    ▶扣费时效性

    效果广告计费是个非常实时的过程,对时效性要求非常高,出现延迟会导致投放时间差的漏洞,也会造成平台的损失(缓存点击),那么必须保证扣费的时效性

    首先系统层面, 导致系统低效的原因主要如下:

    1.第三方依赖(DB,redis)链接及数据传输网络开销

    2.第三方逻辑耦合在主流程中,占用主链路的开销

    3. 线程的频繁创建与销毁,频繁的上下文切换

    4. 热点数据的分布不均匀,不能高效的利用CPU

    针对这几个问题,我们的主要改进如下:

    Ø减少不必要的依赖:强依赖转弱依赖

    1、第三方依赖异步化(kafka/sentry/数据统计),保证主流程安全,同时提高主流程效率。

    2、弱依赖埋好开关,在出现性能瓶颈时可以及时关闭。

    3、连接池应用及网络部署优化,减少中间网络开销

    Ø根据业务特点,找到相对合适的上下文切换

    CPU密集型:线程数=2 *核数

    IO密集型:线程数=核数/(1-阻塞系数) 阻塞系数=链路中IO占用的时间占比

    除了系统外,扣费时效性上,在实际投放过程中,我们还面临着热点数据的挑战 ,存在热点商家或者热点流量,一种情况很多大商家全部被分到同一个线程队列中处理,则会导致某些线程阻塞而某些线程空闲,未能最大化并发效果, 处理不好同时还有可能造成系统雪崩;

    1.过程中如果只是以特定的线程来处理一个队列,由于点击在商家维度的不均衡性,一定会出现某些队列堵塞。

    2. 大队列堵塞会导致大量的缓存点击,会影响收入

    针对这个问题,其实我们的解决方案核心思想很简单,就是:分而治之

    1.按照userId的方式进行hash队列拆分,分拆合适粒度的队列,多队列并行,消费程序(billingWorker)分布式部署分配接管队列消费

    2. 线程和队列分离,按队列数据长度,动态分配线程,提高热点数据消费效率.

    ▶限流降级方案

    在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流。

    缓存:提升系统访问速度和增大系统能处理的容量,可谓是抗高并发流量的银弹

    降级:暂时屏蔽掉非核心流程,避免对主流程造成影响,待高峰或者问题解决后再打开

    限流:一个时间窗口内的的请求进行限速来保护系统,常见的限流算法有:令牌桶、漏桶、计数器也可以进行粗暴限流实现

    而有些场景并不能用缓存和降级来解决,比如稀缺资源(流量飙升的会场,活动页广告)、写服务(如大量扣费,冲击下游),因此需有一种手段来限制这些场景的并发/请求量,即限流

    计费系统主要采用三级限流保护:

    一级:接入层限流

    数据总入口,根据入口流量及系统流量瓶颈,进行限流。

    二级:系统级限流

    程序本身计费逻辑限流,保证队列不会出现堵塞:在程序数据拉取过程中,判断计费队列中的消息数量,比如当数量大于某个阈值(10000)时,限制流量进入(如:当前队列数据10240个,在QPS 4500时计费队列平均10000个),同时控制总量,避免内存队列堆积大量数据。

    当出现断电式故障时,可以快速确定丢失的数量,进行数据恢复。

    三级:重试机制限流

    程序拉取上游数据限流:当程序下游雪崩时,程序会出现大量异常,异常数据会存储入fail队列,计费程序将根据异常的出现次数,fail队列的长度,决定是否继续从上游获取数据、是否进行不进行重试,走fail队列消费逻辑进行数据恢复。

    系统自身AB&平滑上线

    为保证系统的7*24小时服务,对于新改造的系统也需要保证稳定性,并支持小流量平滑上线 ,同时对于新的业务模式做一些计费验证,因此利用unionlogagent在数据收集阶段做流量切分服务,能够支持自定义规则的流量切分,保证我们的计费程序能做自身和业务的AB,同时也能小流量平滑上线,新程序出现故障时可以快速切回,主要的设计方案如下:

    4257d7b47488ea290135338099ac9689.png

    很多时候除了数据流层面和系统层面的问题,还面临整个链路完整性的问题,要保证后端接收到的数求是OK,那怎么去确认前端发送请求的链路没有丢失?后端业务数据处理没有异常? 前端链路是否出现流量劫持,是否出现第三方拦截?因此链路完整性也非常重要

    同时系统必须具备一个非常重要的功能:监控,除了防范与未然,还需要更快的发现系统存在的问题,并能更好的定位问题,计费容灾下部分,将重点分享下此部分.

    展开全文
  • 容灾

    2010-05-18 16:18:00
    容灾系统是指在相隔较远的异地,建立两套或多套功能相同的IT系统,互相之间可以进行健康状态监视和功能切换,当一处系统因意外(如火灾、地震等)停止工作时,整个应用系统可以切换到另一处,使得该系统功能可以继续...

      容灾系统是指在相隔较远的异地,建立两套或多套功能相同的IT系统,互相之间可以进行健康状态监视和功能切换,当一处系统因意外(如火灾、地震等)停止工作时,整个应用系统可以切换到另一处,使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分,容灾系统更加强调处理外界环境对系统的影响,特别是灾难性事件对整个IT节点的影响,提供节点级别的系统恢复功能。

      从其对系统的保护程度来分,可以将容灾系统分为:数据容灾和应用容灾,描述如下:

      .数据容灾就是指建立一个异地的数据系统,该系统是本地关键应用数据的一个实时复制。

      .应用容灾是在数据容灾的基础上,在异地建立一套完整的与本地生产系统相当的备份应用系统(可以是互为备份),在灾难情况下,远程系统迅速接管业务运行。数据容灾是抗御灾难的保障,而应用容灾则是容灾系统建设的目标。

      数据容灾

      所谓数据容灾,就是指建立一个异地的数据系统,该系统是本地关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时,系统至少在异地保存有一份可用的关键业务的数据。该数据可以是与本地生产数据的完全实时复制,也可以比本地数据略微落后,但一定是可用的。采用的主要技术是数据备份和数据复制技术。

      数据容灾技术,又称为异地数据复制技术,按照其实现的技术方式来说,主要可以分为同步传输方式和异步异步传输方式(各厂商在技术用语上可能有所不同),另外,也有如“半同步”这样的方式。半同步传输方式基本与同步传输方式相同,只是在Read占I/O比重比较大时,相对同步传输方式,可以略微提高I/O的速度。而根据容灾的距离,数据容灾又可以分成远程数据容灾和近程数据容灾方式。下面,我们将主要按同步传输方式和异步异步传输方式对数据容灾展开讨论,其中也会涉及到远程容灾和近程容灾的概念,并作相应的分析。

      应用容灾

      所谓应用容灾,是在数据容灾的基础上,在异地建立一套完整的与本地生产系统相当的备份应用系统(可以是互为备份)。建立这样一个系统是相对比较复杂的,不仅需要一份可用的数据复制,还要有包括网络、主机、应用、甚至IP等资源,以及各资源之间的良好协调。主要的技术包括负载均衡、集群技术。数据容灾是应用容灾的技术,应用容灾是数据容灾的目标。

      在选择容灾系统的构造时,还要建立多层次的广域网络故障切换机制。本地的高可用系统指在多个服务器运行一个或多种应用的情况下,应确保任意服务器出现任何故障时,其运行的应用不能中断,应用程序和系统应能迅速切换到其它服务器上运行,即本地系统集群和热备份。

      在远程的容灾系统中,要实现完整的应用容灾,既要包含本地系统的安全机制、远程的数据复制机制,还应具有广域网范围的远程故障切换能力和故障诊断能力。也就是说,一旦故障发生,系统要有强大的故障诊断和切换策略制订机制,确保快速的反应和迅速的业务接管。实际上,广域网范围的高可用能力与本地系统的高可用能力应形成一个整体,实现多级的故障切换和恢复机制,确保系统在各个范围的可靠和安全。

      集群系统是在冗余的通常可用性系统基础之上,运行高可靠性软件而构成。高可靠性软件用于自动检测系统的运行状态,在一台服务器出现故障的情况下,自动地把设定的服务转到另一台服务器上。当运行服务器提供的服务不可用时,备份服务器自动接替运行服务器的工作而不用重新启动系统,而当运行服务器恢复正常后,按照使用者的设定以自动或手动方式将服务切换到运行服务上运行。备份服务器除了在运行服务器出现故障时接替其服务,还可以执行其他应用程序。因此,一台性能配备充分的主机可同时作为某一服务的运行服务器和另一服务的备份服务器使用,即两台服务器互为备份。一台主机可以运行多个服务,也可作为多个服务的备份服务器。

      数据容灾系统,对于IT而言,就是为计算机信息系统提供的一个能应付各种灾难的环境。当计算机系统在遭受如火灾、水灾、地震、战争等不可抗拒的自然灾难以及计算机犯罪、计算机病毒、掉电、网络/通信失败、硬件/软件错误和人为操作错误等人为灾难时,容灾系统将保证用户数据的安全性(数据容灾),甚至,一个更加完善的容灾系统,还能提供不间断的应用服务(应用容灾)。可以说,容灾系统是数据存储备份的最高层次。

      数据容灾备份的等级

      容灾备份是通过在异地建立和维护一个备份存储系统,利用地理上的分离来保证系统和数据对灾难性事件的抵御能力。

      根据容灾系统对灾难的抵抗程度,可分为数据容灾和应用容灾。数据容灾是指建立一个异地的数据系统,该系统是对本地系统关键应用数据实时复制。当出现灾难时,可由异地系统迅速接替本地系统而保证业务的连续性。应用容灾比数据容灾层次更高,即在异地建立一套完整的、与本地数据系统相当的备份应用系统(可以同本地应用系统互为备份,也可与本地应用系统共同工作)。在灾难出现后,远程应用系统迅速接管或承担本地应用系统的业务运行。

      设计一个容灾备份系统,需要考虑多方面的因素,如备份/恢复数据量大小、应用数据中心和备援数据中心之间的距离和数据传输方式、灾难发生时所要求的恢复速度、备援中心的管理及投入资金等。根据这些因素和不同的应用场合,通常可将容灾备份分为四个等级。

      第0级:没有备援中心

      这一级容灾备份,实际上没有灾难恢复能力,它只在本地进行数据备份,并且被备份的数据只在本地保存,没有送往异地。

      第1级:本地磁带备份,异地保存

      在本地将关键数据备份,然后送到异地保存。灾难发生后,按预定数据恢复程序恢复系统和数据。这种方案成本低、易于配置。但当数据量增大时,存在存储介质难管理的问题,并且当灾难发生时存在大量数据难以及时恢复的问题。为了解决此问题,灾难发生时,先恢复关键数据,后恢复非关键数据。

      第2级:热备份站点备份

      在异地建立一个热备份点,通过网络进行数据备份。也就是通过网络以同步或异步方式,把主站点的数据备份到备份站点,备份站点一般只备份数据,不承担业务。当出现灾难时,备份站点接替主站点的业务,从而维护业务运行的连续性。

      第3级:活动备援中心

      在相隔较远的地方分别建立两个数据中心,它们都处于工作状态,并进行相互数据备份。当某个数据中心发生灾难时,另一个数据中心接替其工作任务。这种级别的备份根据实际要求和投入资金的多少,又可分为两种:①两个数据中心之间只限于关键数据的相互备份;②两个数据中心之间互为镜像,即零数据丢失等。零数据丢失是目前要求最高的一种容灾备份方式,它要求不管什么灾难发生,系统都能保证数据的安全。所以,它需要配置复杂的管理软件和专用的硬件设备,需要投资相对而言是最大的,但恢复速度也是最快的。

      容灾备份的关键技术

      在建立容灾备份系统时会涉及到多种技术,如:SAN或NAS技术、远程镜像技术、基于IP的SAN的互连技术、快照技术等。这里重点介绍远程镜像、快照和互连技术。

      1. 远程镜像技术

      远程镜像技术是在主数据中心和备援中心之间的数据备份时用到。镜像是在两个或多个磁盘或磁盘子系统上产生同一个数据的镜像视图的信息存储过程,一个叫主镜像系统,另一个叫从镜像系统。按主从镜像存储系统所处的位置可分为本地镜像和远程镜像。远程镜像又叫远程复制,是容灾备份的核心技术,同时也是保持远程数据同步和实现灾难恢复的基础。远程镜像按请求镜像的主机是否需要远程镜像站点的确认信息,又可分为同步远程镜像和异步远程镜像。

      同步远程镜像(同步复制技术)是指通过远程镜像软件,将本地数据以完全同步的方式复制到异地,每一本地的I/O事务均需等待远程复制的完成确认信息,方予以释放。同步镜像使远程拷贝总能与本地机要求复制的内容相匹配。当主站点出现故障时,用户的应用程序切换到备份的替代站点后,被镜像的远程副本可以保证业务继续执行而没有数据的丢失。但它存在往返传播造成延时较长的缺点,只限于在相对较近的距离上应用。

      异步远程镜像(异步复制技术)保证在更新远程存储视图前完成向本地存储系统的基本I/O操作,而由本地存储系统提供给请求镜像主机的I/O操作完成确认信息。远程的数据复制是以后台同步的方式进行的,这使本地系统性能受到的影响很小,传输距离长(可达1000公里以上),对网络带宽要求小。但是,许多远程的从属存储子系统的写没有得到确认,当某种因素造成数据传输失败,可能出现数据一致性问题。为了解决这个问题,目前大多采用延迟复制的技术(本地数据复制均在后台日志区进行),即在确保本地数据完好无损后进行远程数据更新。

      2.快照技术

      远程镜像技术往往同快照技术结合起来实现远程备份,即通过镜像把数据备份到远程存储系统中,再用快照技术把远程存储系统中的信息备份到远程的磁带库、光盘库中。

      快照是通过软件对要备份的磁盘子系统的数据快速扫描,建立一个要备份数据的快照逻辑单元号LUN和快照cache。在快速扫描时,把备份过程中即将要修改的数据块同时快速拷贝到快照cache中。快照LUN是一组指针,它指向快照cache和磁盘子系统中不变的数据块(在备份过程中)。在正常业务进行的同时,利用快照LUN实现对原数据的一个完全的备份。它可使用户在正常业务不受影响的情况下(主要指容灾备份系统),实时提取当前在线业务数据。其“备份窗口”接近于零,可大大增加系统业务的连续性,为实现系统真正的7×24运转提供了保证。

      快照是通过内存作为缓冲区(快照cache),由快照软件提供系统磁盘存储的即时数据映像,它存在缓冲区调度的问题。

      3.互连技术

      早期的主数据中心和备援数据中心之间的数据备份,主要是基于SAN的远程复制(镜像),即通过光纤通道FC,把两个SAN连接起来,进行远程镜像(复制)。当灾难发生时,由备援数据中心替代主数据中心保证系统工作的连续性。这种远程容灾备份方式存在一些缺陷,如:实现成本高、设备的互操作性差、跨越的地理距离短(10公里)等,这些因素阻碍了它的进一步推广和应用。

      目前,出现了多种基于IP的SAN的远程数据容灾备份技术。它们是利用基于IP的SAN的互连协议,将主数据中心SAN中的信息通过现有的TCP/IP网络,远程复制到备援中心SAN中。当备援中心存储的数据量过大时,可利用快照技术将其备份到磁带库或光盘库中。这种基于IP的SAN的远程容灾备份,可以跨越LAN、MAN和WAN,成本低、可扩展性好,具有广阔的发展前景。基于IP的互连协议包括:FCIP、iFCP、Infiniband、iSCSI等。

      衡量容灾备份的两个技术指标

      RPO(Recovery Point Objective):即数据恢复点目标,主要指的是业务系统所能容忍的数据丢失量。

      RTO(Recovery Time Objective):即恢复时间目标,主要指的是所能容忍的业务停止服务的最长时间,也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。

      RPO针对的是数据丢失,而RTO针对的是服务丢失,二者没有必然的关联性。RTO和RPO的确定必须在进行风险分析和业务影响分析后根据不同的业务需求确定。对于不同企业的同一种业务,RTO和RPO的需求也会有所不同。

    转载于:https://www.cnblogs.com/liangyours/archive/2010/05/18/1738374.html

    展开全文
  • 摘要:一个系统可能包含很多模块,如...对于数据库服务而言,高可用的实现可能更加复杂,对用户的服务可用,不仅仅是能访问,还需要有正确性保证,因此讨论数据库的高可用方案时,在容灾之外,还要同时考... ...
  •  同理,可靠性、可用性和容灾设计这些活动都是围绕 “安全” 这个核心,而性能优化,提升响应性则是围绕 “效率”。 有些关键的软件系统必须同时兼顾 “安全” 和 “效率”,例如用在飞机、汽车内用于控制起落、...
  • 何为容灾

    千次阅读 2016-05-17 16:35:21
    容灾系统是指在相隔较远的异地,建立两套或多套功能相同的IT系统,互相之间可以进行健康状态监视和功能切换,当一处系统因意外(如火灾、地震等)停止工作时,整个应用系统可以切换到另一处,使得该系统功能可以继续...
  • 数据容灾

    千次阅读 2012-12-06 15:58:42
    1 数据容灾的概念:  数据容灾就是指建立一个异地的数据系统,该系统是本地关键应用数据的一个实时复制。当今的世界,正在跨入信息时代,数据和信息逐渐成为各行各业的业务基础和命脉。 如何实现业务数据的共享...
  • 所以我们希望通过设计一套容灾缓存服务,实现在应用本身或者依赖的服务发生超时等异常情况时,可以返回缓存数据给到前端和用户,来减少空结果数量,并且保证这些数据尽可能是用户感兴趣的。 二、设计与实现 设计...
  • 二、架构可靠性设计是容错容灾的基础 接下来,架构的可靠性设计,这个是容灾容错的一个基础和必要条件。没有这个的话实际谈不上真正系统的高可用性,架构的设计肯定是差异化的,不可能一概而论。 1、可靠性的差异化...
  • 什么叫容灾

    2017-01-21 17:17:47
    容灾技术是系统的高可用性技术的一个组成部分,容灾系统更加强调处理外界环境对系统的影响,特别是灾难性事件对整个IT节点的影响,提供节点级别的系统恢复功能。 从其对系统的保护程度来分,可...
  • 【亲述】Uber容错设计与多机房容灾方案 - 高可用架构系列 2015-07-22 赵磊 高可用架构 此文是根据赵磊在【QCON高可用架构群】中的分享内容整理而成,转发请注明来自公众号高可用架构(ArchNotes)。 ...
  • 电子商务安全风险管理是对电子商务系统信息的安全风险进行识别衡量分析并在此基础上有效地处置风险以最低的成本或代价实现最大可能信息安全保障的科学管理方法重点要解决风险分析容灾设计等工作 9.1 电子商务系统...
  • 容灾技术及建设经验介绍

    千次阅读 2014-07-21 14:21:20
    容灾系统是指建立两套或duotao
  • 连日来,号称史上最强台风的“海燕”给途径的各国造成了巨大损害,...那么如何才能建立一个共享集约、管理简洁、安全可靠的远程容灾系统,从而降低容灾系统的管理和运维复杂度,保证企业业务的持续运行呢? 保障民生...
  • 如何做好容灾测试

    2020-11-01 00:11:33
    概述:容灾,也是灾难恢复,是一个综合很多技术使用的一个系统性工程,对于容灾测试除了具备扎实的测试技能,同时也要有系统性的分析思维来拆解,将难度降低到一个个小小的场景和用例中去,以下做一些简单的介绍,只...
  • 数据容灾系统

    2008-10-12 18:50:47
    数据容灾系统 汕头海关 黄任之当今的世界,正在跨入信息时代,数据和信息逐渐成为各行各业的业务基础和命脉。当企业因为信息化带来快捷的服务决策和方便管理时,也必须面对着数据丢失的危险。 数据容灾系统,对于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,389
精华内容 2,955
关键字:

容灾设计重点