数据级容灾备份,和应用级容灾备份有什么区别?国内做得好的有哪几家备份厂家?

数据级容灾备份,和应用级容灾备份有什么区别?国内做得好的有哪几家备份厂家?,第1张

用形象的方式来解释:
1、数据级容灾备份,就是把建立一个数据的备份系统,或者一个容灾系统。比如数据库,文件,等等。常用的方法是基于磁盘阵列的数据复制技术。厂家有EMC,HP等等。
2、应用级的容灾,建立一个应用的备份系统。比如一套OA系统,正在运行,在远程,再建立一套同样运行的OA系统,这就是一个应用级的容灾。关键技术是要实现数据实时传递,还要保证一致性,完整性,可用性。常用的方法有数据库的复制方式。厂家有 ORACEL,中科同向等等。
3、体系级容灾,再建立一整套体系,包括软硬件,团队。比如美国总统,副总统团队实时的备份。

安全
1。防黑直接用硬件防火墙。一般防黑主要通过硬件就能达到目的,更为重要是指数据是否会因为灾难或人为错误而丢失且永久不能恢复。
2。相对来说 信息架构安全 (数据的可靠性) 是指 容灾方式和热备机制。
热备机制。保证应用的可用性,持续性。 把数据由主节点备份到副节点(在线实时数据备份)。通过心跳来检测主节点是否正常运作,容失效则接替主节点的应用继续运作。直到主节点恢复正常。
容灾是一些防止数据 因为 硬件损坏,人为误 *** 作,灾难导致数据丢失。把在线数据备份变为离线数据备份,通过光纤(连接到另外一个异地存储)或磁带机(备份完把磁带取走),实现异地容灾。

数据库级容灾备份与应用级容灾备份的区别可以从其定义以及价格所区分:

1、从其定义区分

数据库容灾备份:主要基于数据安全做的异地备份方式,在这种方式下主要通过对数据进行转码备份、备份介质转移到异地、恢复时转码恢复来实现;

应用级容灾:主要关注关键数据异地接管,业务不中断的方向;通常是通过TCP/IP协议将数据实时备份到远端,在本地均被损毁或不可用时,异地端能够及时接管;

两种方式各有优缺,数据容灾备份缺陷是恢复的时间比较长,在恢复的时候业务是中断的;应用级容灾缺点是对于特大数据量(如TB级),需要依赖比较好的专网做异地复制以及性能比较好的服务器。

2、从其价格区分

数据库级容灾只得是从存储层进行备份,这种备份的机制往往是实时的,适合关键的业务,并且能够做到实时的挂载,相对应用级别,毕竟成本高一些,但是目前已经被很多企,事业单位采用。应用级的备份是最传统的,在应用层进行复制,一般成本低廉。中、小型的金融行业全是数据级的容灾。

备份要求的是数据的复制,而容灾要求的是应用的接管。

容灾”与“备份”不是同一个概念,“容灾”是目的,而“备份”只是实现容灾的其中一种手段,不是唯一。

数据备份比较易理解,保证数据的不丢失,而应用的接管是要接管服务器的处理工作,使得应用不间断。
备份”只是将数据COPY一份,在其他介质保存,当数据丢失了,有“备份”可以用于恢复,无论手动还是自动,而有副本就相当于完成“备份”了,至于恢复不恢复,恢复完了没有,与“备份”是没有关系的,那属于“容灾”的范畴了。我们日常将东西考到U盘,光盘,移动硬盘也就是备份了。
“容灾”是为了通过一些技术手段的部署,达到出现“意外”的时候,业务不会中断或者中断后会自动恢复(注意要自动,而且恢复时间很短)。例如服务器、网络、存储哪一点出现问题,都会中断服务,所以这个时候每个点都需通过技术手段做保护,这就是容灾要考虑的事情。

与“备份”不同的是,例如你的硬盘挂了,买一个新硬盘,你再将移动硬盘的数据拷过来就OK,但是这个过程中是要停止服务的,恢复过程是需要时间的。而“容灾”是要不中断服务的,例如说你有2台电脑,然后两边数据是实时同步的,忽然一台的硬盘坏了,不要紧,直接到另外一台办公好了,因为实时同步,坏了的那台的数据这边没坏的这台也有,这种就相当于容灾了。
1、“高可用”:及HA(High Avaliablility),一般实现方式是对2台服务器上面装HA的软件,这时候就和“双机热备”的概念一样了,一般正常服务时只有主机在工作,2台服务器中间会有心跳的hello包,备机会一直发hello包检测主机是否“活着”,超过一段时间主机没有应答hello包的话,备机就会认为主机死掉,然后主动接管业务了。这样子又实现了主机的容灾了。

2、“冷备”就没有什么好说了,相当于1台坏了,另外1台还要我们手动去启动,配置,才能接管坏了那台的工作。

3、“容错”:Vmware的虚拟化软件提出的一个概念,相当于1台虚拟机运行的时候,多开1台虚拟机,当一些 *** 作在A虚机运行,会通过软件同步复制 *** 作到B。当A虚机崩溃,B主机立刻托管业务,由于 *** 作都是同步复制的,所以B不会丢失任何在A上的内容(包括内存里面的临时数据)。此种方式比“高可用”的更高级,“高可用”的方式B还要通过A没有应答hello才发现A崩溃了,中间还是有一段过度的时间会业务中断,但是可以实现自动的业务恢复。而“容错”这种方式业务完全不用中断,但是相应换来了成本需要增高,原来1台虚机,现在相当于要多开1台来与他同步,资源成本增高。
1、“负载均衡”:假设有5台服务器,如果有5个访问请求,没有负载均衡时,可能5个请求都访问机器A,这样可能引致访问速度慢,A机器崩溃等问题,而有了负载均衡,就会将5个任务按照策略进行分发,可能5台机器每台负责处理一个任务就OK了。

2、”集群”:多台服务器同时处理某一事务,听起来与“负载均衡”有点像,但是其实负载均衡是5个任务摊分给5台机器,而集群相当于一个任务拆分为5份,5台机器一起来处理同一个任务,分别完成自己负责的部分后汇总一起输出结果。例如有一个很复杂的计算任务,1台机要算5小时才能解决,那么5台同时计算,可能1小时就解决了,这个是“集群”的主要用途。

3、“虚机迁移”:与“高可用”与“容错”最大的区别,“虚机迁移”是计划内的,即需要人工手动或者安排好进行时间来实现的,所以不属于容灾的范畴。而后两者属于“容灾”范畴,可以在发生计划外的“意外”的时候,自动实现业务恢复。“虚机迁移”更合适用来处理资源池间的利用率平衡性,如A资源池80%符合,B资源池只有20%,那么可以适当“迁移”部分到B资源池,实现两边负载均衡。
双活(Active-Active),故名思义就是两边都是活动在线提供服务的 ,是相对于传统的主备模式 Active-Standby 模式的。一个真正的双活方案是应该涵盖基础设施、中间件、应用程序各个层次的。

数据中心同时对外提供业务生产服务的双活模式, 两个数据中心是对等的、不分主从、并可同时部署业务 ,可极大的提高资源的利用率和系统的工作效率、性能,让客户从容灾系统的中获得最大的价值。

1 两个生产中心部署相同的业务系统,结合网络层、主机层或应用的负载均衡技术,实现业务系统在两个数据中心并行工作和负载分担。

2两个生产中心部署不同的业务系统,互相实时灾备接管。

数据中心双活又分为:同城双活、异地双活。

出于灾备(Disaster Recovery)的目的,一般都会建设2个(或多个)数据中心。

一个是主数据中心用于承担用户的业务,一个是备份数据中心用于备份主数据中心的数据、配置、业务等。

主备数据中心之间一般有热备、冷备、双活三种备份方式。
热备的情况下,只有主数据中心承担用户的业务,此时备数据中心对主数据中心进行 实时的备份 ,当主数据中心挂掉以后,备数据中心可以自动接管主数据中心的业务,用户的业务不会中断,所以也感觉不到数据中心的切换。
冷备的情况下,也是只有主数据中心承担业务,但是备用数据中心不会对主数据中心进行实时备份,这时可能是 周期性的进行备份 或者 干脆不进行备份 ,如果主数据中心挂掉了,用户的业务就会中断。
双活是觉得备用数据中心只做备份太浪费了,所以让主备两个数据中心都同时承担用户的业务,此时,主备两个数据中心互为备份,并且进行实时备份。一般来说,主数据中心的负载可能会多一些,比如分担60~70%的业务,备数据中心只分担40%~30%的业务。

传统主备模式是一个业务只在一个数据中心运行,企业结合灾备等级需求和业务需求,在备份中心部署了大量的备份服务器,但备份中心仅为该业务提供灾备服务,只有当灾难发生、生产数据中心瘫痪时,灾备中心的业务系统才启动这些服务器,造成备份中心服务器资源浪费,广域网链路也无法得到充分的利用。

双活数据中心优点是充分利用资源,避免了一个数据中心常年处于闲置状态而造成浪费,通过资源整合,“双活”数据中心的服务能力是双倍的。

双活数据中心如果断了一个数据中心,另外一个数据中心还在运行,对用户来说是不可感知的,而一个灾备中心的模式,如果生产数据中心瘫痪,需要半个小时、甚至两个小时、甚至更长时间才能启动灾备中心,在启动灾备中心的时间里,用户交易会严重受损。
部署“双活”数据中心的难度也非常大,尤其是异地“双活”,涉及到数据同步效率问题。

如果数据同步效率达不到要求,在灾难发生时就会造成一段时间的交易丢失。在异地“双活”的模式中,两地数据中心同时接纳交易,技术难度很大,需要更改众多底层程序。

双活数据中心的建设首先要满足三个条件:

第一个是应用双活,也就是说应用系统一定要实现双活;

第二个是网络要双活,业务网络要保证能够同时联通两个数据中心;

第三个是数据要双活,两边的数据要能够实现被独立使用。
容灾备份

>网络容灾就是网络服务系统和网络存储在出现问题的时候还能保障用户正常应用。现在主要的技术就是同时运行两套系统,比如一台网络服务系统服务器,一般是同样型号的两台服务器做双机,当主服务器因为某些原因当掉时,备份服务器可以顶替主服务器,继续提供相应的服务,从而保证业务的连续性。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13389223.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-26
下一篇 2023-07-26

发表评论

登录后才能评论

评论列表(0条)

保存