双活容灾是最值得选择的容灾(一)
摘要:
浪擎带您从投入成本、运维工作量、容灾技术指标、容灾可靠性、方案配备这些方面来选择适合自己的容灾技术或方案。本文所述的灾难是广义的,是一些常常发生的、导致生产系统停止运转的故障,而非重大自然灾害;一般而言,最需要保护的数据是结构化数据,即存
浪擎带您从投入成本、运维工作量、容灾技术指标、容灾可靠性、方案配备这些方面来选择适合自己的容灾技术或方案。本文所述的灾难是广义的,是一些常常发生的、导致生产系统停止运转的故障,而非重大自然灾害;一般而言,最需要保护的数据是结构化数据,即存储在数据库的数据。这是本文探讨的出发点。
一、 选择容灾技术或方案需要考虑的问题
1.建设目标必需适合实际需求
容灾建设需要符合实际需求。如果完全按照国标规定的七个要素来建设,资金、人力投入太大。在实际的建设过程中,不必好高骛远,而应根据自身的实际需求来定义容灾建设目的。仅就大部分的用户而言,建设容灾的目的就是防范一些常见故障,如防备软硬件故障、机房停电、感染病毒、黑客入侵、人为故障等破坏因素,或者准备一套备用系统用于例行维护使用,或者实现生产、查询相分离的业务建设。这样的目的是合适的、实惠的。因此,用户选择不同机房、不同楼层或楼宇的本地容灾。
容灾建设量力而为。对于银行、电信运营商、医疗、证券、电力、交通等行业而言,核心业务系统的数据对于企业的正常运行至关重要,一旦数据大量丢失或业务长时间中断,造成的影响是无可估量的。而对于一般行业(例如中小企业),一方面受到资金投入、技术门槛、人员素质、管理及维护复杂度等因素的制约,另一方面发生灾难所带来的损失也不那么大,因此完全没有必要一味追求高的容灾建设等级,而是结合自身条件来选择符合RTO、RPO需求的容灾等级。
考虑投入产出比。除RTO和RPO两个技术指标外,用户还必需关注容灾方案的投入产出ROI(投入产出比),衡量用户的投入与从中所获得的收益的比率。表明上看,容灾系统不像其它业务系统那样会给用户带来直接的产出收益。但事实上,容灾系统确实是有收益的。容灾系统的收益主要来源于发生故障时为用户所挽回的损失,这种损失不只包括收入方面的,信誉、客户忠诚度、法律风险等方面的损失也包含在内。如果容灾系统能够把由于故障而导致的业务停止时间显著缩短,也就间接为客户创造了收益。
因此,从这些角度讲,选择合适的容灾技术路线,例如基于主机的应用层复制容灾方案显得更有优势,因为这类方案不仅能大幅降低容灾系统的初始部署成本,而且管理成本也相对要低很多。
2.不同业务系统采用不同的容灾技术、打组合拳
不同业务系统采用不同的技术。故障给不同类型的业务所带来的损失是不同的,因此不能采用一刀切的方式进行灾备系统建设,而是需要细致分析业务单位信息系统的重要程度,有效区分核心业务和非核心业务,并平衡业务系统的实际需求和总体成本的关系。核心业务采用等级很高的容灾技术,例如医院的HIS、银行的“核心、授信、网银等交易系统、证券的核心交易系统等等,可采用实时复制、零恢复的技术等级;而另外一些非核心业务,如OA、报表统计等等,可暂缓考虑,或选择较低一个等级的技术。因此,用户在容灾建设时,需要根据业务系统重要性的不同,采用不同的容灾等级。
总而言之,在进行容灾建设规划时,单靠一种方案或一种技术是行不通的,为了实现多种等级容灾,需要有一个完整的容灾方案和技术体系作支撑。
3.按照“先本地、再异地”的由近及远原则建设
从投入成本和故障发生概率来考虑,可以先建设本地的容灾,在同一个机房不同的主机和存储上建设,或在不同的楼层建设一个备份中心,或在不同的楼宇建设一个备份中心。经济条件具备的,考虑同城建设一个备份机房。在实际的操作中,很多企业基本都会在本地建设一个高等级的、投入也不大的容灾,然后在分部或者同城其他地方再做一个异地备份。这样的建设方案投入不大、比较实惠。
4.“平战结合”、充分发挥容灾系统的作用
投入上百万的资金建设一套容灾,仅在自然灾难或其他软硬故障时发挥作用,或者软硬件放置在机房折旧贬值,没有几家公司的老板愿意这样做。
“平战”并不是狭窄的指在和平或战争条件,更广义的指在发生各种常见故障或者正常运行。那么,“平战结合”就是要充分发挥一套投入较大的容灾系统的额外价值。在容灾系统上部署一些供用户内部使用的业务系统,例如报表系统可以利用容灾数据库实现查询统计功能。
5.传统备份技术和实时复制容灾技术需并存
传统的数据备份难于满足高等级容灾的技术要求。虽说定时备份在一定程度上可以保证数据安全,但应用于容灾时却面临备份窗口大、备份间隔大、数据可恢复性差和恢复时间长、性能影响剧烈等众多问题,也不能满足RTO和RPO趋于0的要求。因此,传统的数据备份技术作为一种廉价的、成熟的技术,在整体的解决方案中,为容灾系统提供一种补充,或者为一些比较小的、不太重要的业务建设定时备份系统。
备份技术可弥补实时数据复制自身可能存在故障,或弥补实时复制技术不能克服数据逻辑错误的缺陷。
因此,在完整的容灾方案中,这两种技术是并存的。
6.定期的验证和演练是确保容灾系统可靠性的一种手段
需要定期的验证和演练对容灾系统而言是必需的,校验出可能导致数据不一致的因素。由于存在两端数据不一致,理论上也无法确保故障发生时容灾端数据就是好的。这就需要容灾系统提供一个可供验证和演练的方法和界面。
应用层的复制可以随时、直接的提供一个校验手段。因为容灾端的应用程序处于运行状态,直接查询数据就可校验数据了。也可以用自己的业务系统来连接容灾端数据来校验,例如医疗行业的用户可以用HIS软件去连接容灾端数据库。
7.选择懂得数据库的厂商或集成商来提供容灾方案
除了上述技术性选择外,还必须考量厂商或集成商的技术实力。做容灾,最主要一点就是保障数据库的稳定性和可靠性。因为,在每个企业内部存在结构化数据和非结构化数据两类数据,尤以结构化为主,就是以存在数据库的数据为主。数据库是极其复杂的应用程序,如Oracle、SQLServer等大型关系数据库,正常使用很简单,但是维护却需要极其全面和深厚的技术功底,还需要懂得操作系统和存储。不懂得数据库的存储原理和内部逻辑架构是很难做得好容灾的。这也是应用层的优势,也是浪擎科技的优势。
二、 四种容灾复制方案的说明
根据操作系统的I/O(读写操作)路径以及复制对象划分为四种容灾技术:基于应用层事务复制技术、基于文件层复制技术、基于逻辑卷复制技术、基于磁盘阵列复制技术。当然,目前出现了基于SAN交换机的复制,但是相对技术不太成熟,应用很少。
双活容灾采用应用层事务复制技术。双活容灾复制对象为应用事务,实时捕获生产数据库的变化事务,例如SQLServer或Oracle数据库的事务,经由传输组件传输到容灾服务器,然后装载进程按照数据库的关系原理排序事务,将变化事务保存到容灾数据库。容灾数据库处于在线运行状态,因此这样的容灾叫双活容灾。双活容灾代表厂商:浪擎、DSG、Goldengate、Quest、Oracle、微软等。
双活容灾严格保障数据库一致性,是最可靠的容灾,是最适合数据库的容灾。当生产数据库发生故障时,直接使用容灾数据库即可恢复业务运行,其容灾的RTO指标趋于零。
但双活容灾支持的应用有限,仅支持有限的数据库,一般为SQLServer、 Oracle、Sybase、DB2、MySQL等数据库。
双活容灾方案的硬件配置,需要添置容灾服务器、容灾存储等设备,但无需架设专门的光纤传输网络。当然也可以采用现有的或旧的的服务器来作为容灾服务器。如果数据量不大则无需购置容灾存储设备,直接使用容灾服务器的硬盘。
2.基于磁盘阵列复制的容灾
基于磁盘阵列的复制是磁盘阵列厂商提供的复制技术。其复制磁盘阵列上变化的数据块,经过专门的光纤传输到容灾磁盘阵列,然后保存到相应的位置。磁盘阵列层代表厂商:IBM、HP、EMC、HDS等。
基于磁盘阵列复制的容灾不能完全保障数据库一致性,目标数据库处于脱机状态。当生产数据库发生故障时,需要启动数据库才能恢复业务,正是由于不能保障数据库一致性,很可能数据库不能正常启动。尽管存在这样的缺陷,但这一层的复制对主机的影响极其轻微,所以还是可应用在一些非常大型、繁忙的数据库容灾,作为一种补充保护手段。
基于磁盘阵列复制的容灾方案成本高昂,且实施复杂。需要购置与生产存储相同规格的容灾存储、容灾服务器、光纤交换机等设备,还需要专门的专门的光纤传输网络。
3.基于逻辑卷复制的容灾
基于逻辑卷层的复制,一般采用采用同步复制机制,复制对象为逻辑卷层的变化Block,其过程为:捕获变化块,同步写入目标存储,等于在一个主机上将同一数据写入两个不同的逻辑磁盘。这种复制方式对I/O性能影响很大。另外,在实施时可能需要改造生产环境,例如赛门VM、VVR需要自身的卷管理格式才能支持复制,所以如果用于非新部署的业务系统其实施非常复杂。逻辑卷层代表厂商:赛门铁克、飞康等。
基于逻辑卷复制的容灾不能完全保障数据库一致性,目标数据库处于脱机状态。当生产数据库发生故障时,需要启动数据库才能恢复业务,正是由于不能保障数据库一致性,很可能数据库不能正常启动。因此,这层复制技术很少用于大型数据库的容灾。
基于逻辑卷复制的容灾方案成本高昂,且实施复杂。需要购置与生产存储相同规格的容灾存储、容灾服务器等设备。实施时,还需改造生产系统的卷存储格式使之与容灾软件所需的存储格式一样。
4.基于文件复制的容灾
基于文件层的复制,一般采用采用异步复制机制,复制对象为文件I/O,其过程为:复制上层应用传递下来的I/O,然后缓存起来,再经由传输组件传输到目标服务器,再由目标服务器写入目标存储,完成一次复制。文件层代表厂商:赛门铁克的低端文件复制、国内大部分的容灾厂商。
基于文件复制的容灾不能保障数据库一致性,目标数据库处于脱机状态。当生产数据库发生故障时,需要启动数据库才能恢复业务,正是由于不能保障数据库一致性,很可能数据库不能正常启动。所以文件复制适用于事务很少、数据量很小的数据库。
基于文件复制的容灾方案的成本低廉,实施简单。需要添置容灾服务器、容灾存储等设备,但无需架设专门的光纤传输网络。当然也可以采用现有的或旧的的服务器来作为容灾服务器。如果数据量不大则无需购置容灾存储设备,直接使用容灾服务器的硬盘。
三、 不得不考虑的核心问题——容灾数据的可靠性
1.保障容灾端数据一致性的意义
容灾系统与生产系统的数据一致性考虑在容灾建设中极其重要。什么叫数据一致性,这是个非常专业的问题。简单的讲,就是要保证生产系统、容灾系统的数据相一致。可以这样讲,如果各层不能保障复制过去的数据的一致性,那么容灾端的数据就不完整,整个应用系统就不可用,容灾完全失去意义。
而四种复制技术由于所属层次不一严,各层的数据一致性含义是不同的。
2.双活容灾完全能保障容灾端的数据一致性
双活容灾的数据一致性是指容灾业务数据和生产端业务数据相同,例如股票交易业务,生产端交易了10000笔,如果容灾端只复制了9999笔,那么就产生了数据不一致的问题。但是,双活容灾的数据不一致性相对应用程序而言是不致命的,甚至应用程序都无法感知,只有上层业务才能感知,就如同这个例子丢了一笔交易数据,那么此时需要人工干预补齐一下数据。从这个角度讲只有基于数据库事务复制的容灾才能确保应用程序的完整性和一致性。
3.其他三种容灾保障数据一致性的难题
其他三种容灾的数据不一致性对应用程序而言是致命的,很可能导致应用程序无法启动。其他三种的数据一致性比双活容灾的数据一致性含义复杂,这是由于复制所属层次和复制对象不一样导致的。其他三种的数据一致性包含两方面的含义:一是在磁盘上或文件上的应用程序的数据一致性,这是因为每个应用程序对存在磁盘上的数据都有一个内在的组织结构和秩序,如果这种结构和秩序不完整或被破坏,那应用程序很可能就无法启动了;二是两端的数据一致性。在I/O的路径上各层都有自己的缓存,很有可能会滞留一些I/O在自己的缓存中。
如果在系统发生故障时,仍有部分I/O“滞留”在I/O操作中,真正写到磁盘中的数据就会少于应用程序实际写出的数据,造成数据的不一致,从而导致结构和秩序不完整或被破坏。异步复制顺序地将这些I/O复制到容灾端,故障发生时可能导致I/O复制不完整,从而也会导致这种情况发生,这就是基于文件复制的容灾不可靠的原因。
逻辑卷和磁盘阵列采用同步复制,关闭各层缓存,这样的情况一般不会发生,但是由于应用程序和操作系统的复杂性,这种复杂性本身可能导致I/O的坏块。同时,这两种还可能存在卷组一致性的问题,应用程序的数据存在多个逻辑卷或物理卷中,在这两层中很可能会出现应用程序串行写而这两种并行写的状况,从而导致磁盘上的数据的写秩序不一致,这是很可怕的。存在这样的问题,需要在调研阶段搞清楚应用程序的存储状况的,从而有针对性的实施方案。
4.非常繁忙的数据库的容灾挑战
在浪擎科技的数据库容灾研究过程中发现,当SQLServer数据库面对大量的事务时,采用非顺序写日志,这与一个空闲的数据库线性写日志完全不同,颠覆了先前对数据库线性写日志的认识。有兴趣研究的同行,可以构造一个这样的测试场景,一直不断提交事务给数据库,然后监测数据库的日志I/O状况。我们猜想可能是这样的原因:当日志缓存剧烈消耗时,数据库进程采用了多线程并行写日志,这样的好处可能加快写的速度,但是采用这样的写机制会导致一个乱序的日志文件来,对数据库在磁盘上的状态来说却是一个灾难;或是,数据库发出串行的异步写调用,但操作系统内部并行写,回复状态按照调用顺序而已,这个猜想可能是错误的,这需要很懂Windows操作系统I/O管理机构的技术高手来解释。
这样的SQLServer数据库写对其他三种的容灾技术来说,简直就是灾难,或许同步复制能保障,但是异步复制,例如文件复制,却是不能保障容灾端数据库的一致性。所以,文件复制容灾不能确保容灾数据库是好的,只能通过其他机制来补偿缺陷,例如通过回滚重试每个I/O来验证容灾数据库的好坏。
正因如此,象医院、证券、海关、税务、电力、公安、社保、电商、交通、银行、电信等提供公共服务的业务系统在工作时间都非常繁忙,这样的数据库采用文件复制来实现容灾是不可行的,更好的方法是采用双活容灾或基于磁盘阵列复制的容灾。
四、 四种容灾技术或方案的对比
就综合复制技术原理与优缺点、投入成本、资源消耗、实施工作量、维护工作量等等方面来说,双活容灾和基于磁盘阵列复制的容灾是主要的容灾技术,占据很大的容灾市场份额,且应用于关键的、重要的应用系统。浪擎科技正是双活容灾的杰出代表,围绕应用事务复制这个核心,结合文件层的快速复制,采用直接的原始数据装载技术,克服了双活容灾复制速度慢的问题,是目前应用层里面做得最好的一种技术路线。基于磁盘阵列复制的容灾很难克服数据不一致的问题,需结合定时备份技术来防备此类问题的发生。
基于文件复制的容灾主要用于一些非常低端的应用,并且文件复制不能支持AIX、HPUX等UNIX操作系统。
下面从技术原理、实施、维护、资源消耗、适应场合等总结四种容灾。
比较项 |
双活容灾 |
基于磁盘阵列复制的容灾 |
基于逻辑卷复制的容灾 |
基于文件复制的容灾 |
同步/异步 |
异步 |
同步/异步 |
同步/异步 |
异步 |
复制对象 |
数据库事务 |
数据块 |
数据块 |
文件I/O |
主机型复制 |
是 |
不是 |
是 |
是 |
数据库一致性和可靠性保障 |
严格确保可靠性 |
仅同步可以 |
仅同步可以 |
不能保障可靠性 |
容灾端数据库状态 |
在线运行 |
不在线 |
不在线 |
不在线 |
容灾过程 |
直接切换至容灾数据库 |
需启动容灾数据库,才能切换 |
需启动容灾数据库,才能切换 |
需启动容灾数据库,才能切换 |
能否在复制期间校验容灾数据库 |
直接校验 |
需分离或通过快照来校验一个过去状态的数据库 |
不能 |
需分离或通过快照来校验一个过去状态的数据库 |
实施需停机 |
无需,自动化全量复制;全量和实时复制自动衔接 |
需要,直到拷贝全量结束 |
需要,直到全量拷贝结束 |
需要,直到拷贝全量结束 |
是否改变生产环境 |
无需 |
无需 |
需要 |
无需 |
支持复制的数据 |
仅支持主流数据库 |
不限 |
不限 |
不限 |
支持操作系统 |
支持Windows、Linux、AIX、HPUX、Solaris |
支持Windows、Linux、AIX、HPUX、Solaris |
支持Windows、Linux、AIX、HPUX、Solaris |
仅支持Windows、Linux |
是否集成容错 |
支持CDP |
通过快照,但很少 |
无 |
支持CDP |
网络带宽要求 |
少,IP网络 |
高,需光纤直连或波分设备 |
高,IP网络或光纤网络 |
高,IP网络 |
适应场合 |
重要的业务系统 |
重要的业务系统 |
重要的业务系统 |
一般性的业务系统 |
投入成本与方案配备 |
较高。需添置容灾服务器,资金充足也可添置容灾存储。 |
极高。需添置容灾服务器、容灾存储、专门的光纤网络。 |
很高。需添置容灾服务器、容灾存储。 |
少。需添置容灾服务器,资金充足也可添置容灾存储。 |