华为存储远程复制技术白皮书
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
远程复制技术白皮书
文档版本
01 发布日期 2012-04-20
华为技术有限公司
修订记录/Change History
目录
1 概述 (5)
2 OceanStor存储阵列远程复制的设计思路 (7)
3 同步远程复制HyperMirror/S (8)
3.1 HyperMirror/S的工作原理 (8)
3.2 HyperMirror/S的主要功能 (9)
3.2.1 零数据丢失(Zero Data Loss) (9)
3.2.2 关键数据双备份 (9)
3.2.3 支持分裂模式 (9)
3.2.4 快速响应故障和故障恢复 (10)
3.2.5 支持复制的主从切换 (10)
3.2.6 一致性组相关功能 (12)
3.3 HyperMirror/S的灾备流程 (13)
4 异步远程复制HyperMirror/A (14)
4.1 HyperMirror/A的工作原理 (14)
4.2 HyperMirror/A的主要功能 (15)
4.2.1 快速响应主机写请求 (15)
4.2.2 支持镜像分裂、主从切换和故障快速恢复 (15)
4.2.3 从LUN数据完全保护 (16)
4.2.4 支持一致性组功能 (17)
4.3 HyperMirror/A的灾备流程 (17)
5 远程复制HyperMirror的技术特点 (18)
5.1 任意的组网方式 (18)
5.2 灵活的成员LUN设置 (18)
5.3 多台阵列互联 (19)
5.4 互为镜像 (20)
5.5 可变的网络连接 (20)
6 远程复制HyperMirror的应用场景 (21)
6.1 组建中央数据备份站点 (21)
6.2 组建Active-Active业务站点 (22)
6.3 组建数据双备份站点 (23)
6.4 远程复制代理:HyperMirrorAgent (24)
1 概述
随着各行业数字化进程的推进,数据逐渐成为企事业单位的运营核心,用户对承载数据的存储系统的稳定性要求也越来越高。
虽然不少存储厂商能够向用户提供稳定性极高的存储设备,但还是无法防止各种自然灾难对生产系统造成不可恢复的毁坏。
为了保证数据存取的持续性、可恢复性和高可用性,远程容灾解决方案应运而生,而远程复制技术则是远程容灾方案中的关键技术之一。
远程复制(Remote Mirror)又称远程镜像,是数据镜像技术的一种,它能够在两个或多个站点维护若干个数据副本,利用长距离来避免灾难发生时的数据丢失。
图1为一个典型的远程复制系统的拓扑图。
图1-1远程复制系统拓扑图
实现远程复制功能的技术较多,业界使用最为广泛的主要有同步远程复制和异步远程复制两种。
OceanStor存储阵列同时支持同步远程复制(HyperMirror/S)和异步远程复制(HyperMirror/A)两种主流的远程复制技术,以满足用户对数据容灾方式的多重选择。
本文档分别对同步远程复制和异步远程复制进行了描述,包括其工作原理、主要功能、应用场景和技术特点。
2 OceanStor存储阵列远程复制的设计思路
在设计远程复制时,需要考虑以下几个设计需求:
1.尽可能保证主、从LUN之间的紧密同步,从而减少灾难发生时的数据丢失量(data
loss);
2.尽可能减少系统对前台应用程序的写延迟,从而达到减少系统响应时间、提高数据
吞吐量和性能的效果;
3.在异常或灾难发生时,能够保证主站点和复制站点数据可用性。
由于通信链路上存在不可避免的延时,前两个设计需求几乎不可能同时最优化:当前者
达到最优时,主站点收到本地I/O写操作后,立即发向复制站点,等待写I/O同时写入
主LUN和从LUN后才返回前台应用程序写完成——这种方式称为同步远程复制;当后
者达到最优时,主站点先记录收到的I/O写操作导致的差异,写入主LUN后就立即返
回写完成,当差异累积到一定程度时(或经过一段固定的时间)再一次性把所有差异更
新到复制站点的从LUN——这种方式称为异步远程复制。
无论是同步远程复制还是异
步远程复制,都必须满足第三个设计需求——任何情况下的数据可用性。
下面分别介绍OceanStor 存储阵列的同步远程复制和异步远程复制。
3 同步远程复制HyperMirror/S
3.1 HyperMirror/S的工作原理
OceanStor 存储阵列的同步远程复制名为HyperMirror/S,利用日志原理实现主、从LUN
的数据一致性,其实现原理如下:
1.当主站点的主LUN和远端复制站点的从LUN建立同步远程复制关系以后,会启动
一个初始同步,也就是将主LUN数据全量拷贝到从LUN。
2.如果在初始同步时主LUN收到生产主机写请求,需要检查同步进度:若要写入位
置的数据块尚未拷贝到从LUN,只需要写主LUN即可返回主机成功,稍后利用同
步任务将整个数据块同步到从LUN;若要写入位置的数据块已经拷贝,需要分别
写入主LUN和从LUN;若要写入位置的数据块正在拷贝,需要等待该数据块拷贝
完成后分别写入主LUN和从LUN。
3.初始同步完成以后,主、从LUN数据完全一致,如果此时主LUN收到生产主机写
请求,按照下面的流程进行I/O处理(原理图见图3-1):
图3-1同步远程复制I/O处理原理图
1.主LUN接收生产主机写请求,记录这个I/O对应数据块的差异日志值为“有差异”;
2.同时把写请求的数据写入主LUN和从LUN,写从LUN时需要利用配置好的链路
将数据发送到远端复制站点;
3.判断写主LUN和写从LUN的执行结果,如果都成功,则将差异日志改为“无差异”,
否则保留“有差异”,在下一次启动同步时重新拷贝这一个数据块;
4.主LUN返回生产主机写请求完成。
3.2 HyperMirror/S的主要功能
3.2.1 零数据丢失(Zero Data Loss)
OceanStor存储阵列的同步远程复制对主、从LUN同时进行紧密的数据更新,保证恢复
点目标(RPO,Recovery Point Objective,为了恢复业务而必须恢复数据的时间点,表征
业务可以容忍的数据丢失量)为0。
换句话说,利用同步远程复制建立的远程容灾系统,
能够实现灾难恢复级别较高的数据级容灾(“Tier 6—零数据丢失”)。
3.2.2 关键数据双备份
OceanStor存储阵列的同步远程复制支持一个主LUN对应两个从LUN的模式,实现对
关键数据的冗余双备份,如图3-2。
也就是说,同步远程复制的LUN级扇出为2(LUN
级扇出需要区别于后文会提到的阵列级扇出)。
图3-2同步远程复制一对二模式示意图
在一对二模式下,对主LUN的写操作会同时写到两个从LUN中,两个从LUN需要处
于不同的复制站点。
利用一对二模式的同步远程复制,可以使同一份数据在不同的三
地保存三份,对极其重要的关键数据容灾提供了一种解决方案。
3.2.3 支持分裂模式
OceanStor存储阵列的同步远程复制支持分裂模式,在分裂状态下,生产主机对主LUN
的写请求只会写到主LUN,满足用户的一些需求:如暂时性的链路维修、网络带宽扩
容、需要从LUN保存某一个时间点的数据等等。
如图3-3所示,同步远程复制处于分裂时,由于写请求只写入主LUN,会造成此时主、
从数据有差异,我们利用差异日志来记录它们。
当用户希望重新保持主、从LUN数据
无差异时,可以进行一次手动启动同步操作。
同步远程复制的同步过程,就是将差异日
志中标为“有差异”的数据块从主LUN增量拷贝到从LUN的过程,其I/O处理原理与
初始同步的原理类似。
图3-3同步远程复制的分裂和同步过程
3.2.4 快速响应故障和故障恢复
OceanStor存储阵列的同步远程复制检测到系统故障(包括链路断开、主LUN或从LUN
失效等等)时能够立即进入断开状态。
在断开状态下,同步远程复制的I/O处理原理与
分裂时类似,只将I/O写入主LUN并记录差异(注意:若故障为主LUN失效,那么在
故障排除之前主LUN无法接收生产主机的I/O请求)。
当这些故障排除时,同步远程复
制可以在极短的时间内根据恢复策略进行相应的操作:如果恢复策略为自动恢复,同步
远程复制会自动进入“同步”状态,将有差异的数据增量同步到从LUN;如果恢复策
略为手动恢复,同步远程复制会进入“待恢复”状态,等待用户手动启动同步。
由于断
开后的同步采用的是增量同步,可以大大地减少同步远程复制的灾难恢复时间。
3.2.5 支持复制的主从切换
OceanStor存储阵列的同步远程复制支持用户进行主从切换操作(示意图见图3-4)。
图3-4同步远程复制主从切换示意图
在介绍主从切换以前,我们先了解一下从LUN数据状态这个概念。
从LUN数据状态是标识从LUN当前的数据的可用情况,一共分为4种状态:
1.一致:从LUN上的数据是主LUN之前一个时间点的副本,此时从LUN的数据是
可用的,但不一定与当前的主LUN数据完全一致;
2.同步中:远程复制处于同步状态时从LUN数据状态为同步中,此时从LUN的数据
是不可用的;
3.不一致:从LUN上的数据不是主LUN之前一个时间点的副本,从LUN的数据不
可用。
4.已同步:当前从LUN上的数据与主LUN上的数据完全一致,数据的可用性较高。
图3-4所示,主站点的主LUN在切换后变成了新的从LUN,而复制站点的从LUN在切换后变成了新的主LUN。
经过一些在主机侧的简单操作以后(主要是将新主LUN映射给备用生产主机,也可提前映射),复制站点的备用生产主机接管业务并对新主LUN下发读写请求。
进行主从切换时,从LUN数据状态不能为不一致和同步中,因为此时从LUN的数据是不可用的,切换是没有意义的。
当从LUN数据状态为一致时,主从切换以后需要进行一次新主LUN到新从LUN的全量同步;当从LUN数据状态为已同步时,主从切换以后不需要进行全量同步,因为这时新主LUN和新从LUN的数据是完全一致的(见表3-1)。
表3-1主从切换与从LUN数据状态的关系
此外,OceanStor存储阵列的同步远程复制还允许用户在链路异常的情况下,对复制站
点的从LUN进行“强行主从切换”,让用户可以在复制站点使用新主LUN的数据。
强
行主从切换以后的新主LUN没有从LUN,如果要对新主LUN进行容灾,必须重新指
定一个从LUN。
主从切换能够在几秒钟之内,让业务在相隔较远的两地随意切换并确保数据一致性,满
足了用户切换业务的需求。
3.2.6 一致性组相关功能
在大中型数据库应用中,数据、日志、修改信息等存储在磁盘阵列的不同LUN中,缺
少其中一个LUN的数据,都将导致其他LUN中的数据失效,无法继续使用。
如果需要
同时对这些LUN进行远程容灾,那么就要考虑如何保持多个远程复制对的数据在时间
上的一致性。
OceanStor存储阵列的同步远程复制提供一致性组功能来保证多个LUN之
间复制数据时间一致性。
用户创建一致性组以后,可以将最多8个远程复制对添加到一致性组中,如图3-5。
一
致性组也可以进行分裂、同步和主从切换等操作,在进行这些操作时,一致性组的所有
成员复制对同时进行分裂、同步、主从切换和强行主从切换。
此外,当遇到故障时,一
致性组的所有复制对都会一起进入断开状态。
OceanStor存储阵列没有对同一个一致性组中的主LUN以及从LUN的工作控制器做任
何限制,也就是说,不同的主LUN可以处于不同的工作控制器(同样适用于从LUN),
为用户提供更为灵活多变的配置方式。
图3-5同步远程复制一致性组示意图
3.3 HyperMirror/S的灾备流程
下面介绍一下OceanStor存储阵列同步远程复制的灾备流程:
1.正常情况下,主站点提供业务,主站点存储设备的主LUN的数据以同步的方式复
制到复制站点存储设备的从LUN;
2.主站灾难发生后,远程复制关系被断开,此时在复制站点进行强行主从切换,将复
制站点的从LUN提升为新的主LUN;
3.复制站点接替主站点的业务,保证业务不被中断(OceanStor存储阵列同步远程复
制向上预留了接口,如果主机侧有相关的自动切换软件,就可以实现灾难发生时的
自动切换业务,从而使灾难恢复级别达到最高级别);
4.灾难恢复后,重新建立远程复制pair关系,将复制站点上“新主LUN”的数据同
步到主站点的“新从LUN”;
5.复制站点停止业务后再次进行主从切换,恢复最初的同步远程复制的镜像关系;
6.最后,主站点重新恢复业务,完成整个灾备流程。
4 异步远程复制HyperMirror/A
4.1 HyperMirror/A的工作原理
OceanStor 存储阵列的异步远程复制名为HyperMirror/A,其实现原理如下:
1.与同步远程复制类似,当主站点的主LUN和远端复制站点的从LUN建立异步远程
复制关系以后,也会启动一个初始同步。
2.如果在初始同步时主LUN收到生产主机写请求,只会将数据写入主LUN。
3.初始同步完成后,从LUN数据状态变为已同步或一致(在整个初始同步过程中都
没有主机写请求下发时,从LUN数据状态为已同步,否则为一致),然后开始按
照下面的流程进行I/O处理(原理图见图4-1):
1)主LUN接收生产主机的写请求;
2)写请求数据写入主LUN后,立即响应主机写完成;
3)每当间隔一个同步周期(由用户设定,范围为1-1440分钟)以后,会自动启动
一个将主LUN数据增量同步到从LUN的同步过程(如果同步类型为手动,
则需要用户来触发同步)。
在同步开始以前,先对主LUN和从LUN分别生
成快照:主LUN的快照可以保证同步过程中读取到的主LUN数据是具备一
致性的;从LUN的快照用于备份从LUN在同步开始前的数据,避免同步过
程发生异常导致从LUN的数据不可用;
4)主LUN向从LUN同步数据时,读取主LUN快照的数据,复制到从LUN;
5)主LUN向从LUN同步数据完成后,分别取消主LUN和从LUN的快照,然后
等待下一个同步的到来。
图4-1异步远程复制I/O处理原理图
4.2 HyperMirror/A的主要功能
4.2.1 快速响应主机写请求
OceanStor 存储阵列的异步远程复制可以实现对应用主机写请求的快速响应。
主机对主
LUN的写请求在主站点完成后即可响应主机写完成,不必等待数据写到从LUN。
换句
话说,异步远程复制主LUN的访问延迟与普通LUN相同。
并且,数据由主LUN到从
LUN同步过程是在后台进行的,不会影响主机对主LUN的正常访问。
由于异步远程复制主LUN上的数据更新不是立即同步到从LUN的,所以数据遗失量取
决于用户设置的同步周期,用户可以根据应用场景设置不同的同步周期(范围是1-1440
分钟)。
4.2.2 支持镜像分裂、主从切换和故障快速恢复
OceanStor 存储阵列的异步远程复制与同步远程复制类似,同样拥有分裂、同步、主从
切换和断开后恢复的功能。
分裂以后的异步远程复制,不会再进行周期性的同步,直到用户手动进行“同步”操作,
然后按照制定好的同步策略(手动或自动)进行同步。
异步远程复制的同步类型分为手动和自动,由用户进行设置。
当同步类型为手动时,复
制不会自动地启动同步,而是等待用户来触发同步。
选择手动同步时,用户可以根据自
己的意愿将数据更新到从LUN,以此来决定从LUN的数据是哪一个时间点上主LUN
的副本。
自动同步类型又分为两种:第一种是同步开始后定时等待,也就是启动同步时
开始计时,等待一个同步周期后再次启动同步并计时;第二种是同步完成后定时等待,
也就是上一次同步完成以后再进行下一次同步周期的计时。
三种不同的同步类型应用于
不同的场合,用户可以根据具体情况进行选择。
异步远程复制的同步过程与同步远程复制不同,使用差异日志和进度日志来保证数据的
一致性,下面介绍一下异步远程复制的同步原理(原理图见图4-2):
图4-2异步远程复制同步过程原理图
1.使用差异日志记录连续两次同步的时间点之间,主LUN发生的数据更新;
2.启动同步时,差异日志转换为进度日志,根据进度日志中的记录,进行增量同步(只
复制更新过的数据)。
此时新差异日志又开始重新记录主LUN后续发生的数据更
新,为下一次同步做准备;
3.异步复制的同步可以由用户手动触发,也可以设定计时后,自动触发;
4.同步速率可以动态调整;
5.创建异步远程复制时,默认会进行一次初始同步(全同步)。
用户可以选择不进行
初始同步,适用于主、从LUN本来无差异的情况(比如刚创建并格式化后的LUN),
以节省时间。
OceanStor 存储阵列的异步远程复制同样支持主从切换、强行主从切换以及断开后的迅
速恢复,原理和同步远程复制类似,在此不再赘述。
4.2.3 从LUN数据完全保护
OceanStor 存储阵列的异步远程复制支持对从LUN数据的完全保护,当从LUN的数据
不可用时,可以利用复制站点的快照对从LUN进行回滚,使数据恢复到最近一次同步
开始前时间点的可用数据。
异步远程复制进行主从切换后,根据原从LUN数据的可用情况,决定是否对原从LUN
进行数据恢复:如果原从LUN数据本身是可用的,则不必对原从LUN回滚;如果原从
LUN数据不可用,则启动原从LUN快照的回滚,开始数据恢复。
进行原从LUN数据
恢复的回滚过程是在后台进行的,回滚完成后会提示用户数据恢复完成。
从LUN的数据恢复不仅仅应用在主从切换的过程中,用户还可以通过数据恢复立即访
问到从LUN数据,使业务中断时间(RTO)降到最低。
换句话说,如果当用户解除从
LUN远程复制关系时从LUN数据暂时不可用,也会自动触发数据恢复。
4.2.4 支持一致性组功能
与同步远程复制相同,OceanStor 存储阵列的异步远程复制也支持一致性组的相关功能,
包括一致性组的创建、删除、添加成员、删除成员、分裂、同步、主从切换、强行主从
切换等等。
4.3 HyperMirror/A的灾备流程
下面介绍一下异步远程复制的灾备流程:
1.正常情况下,主站点提供业务,主站点存储设备的主LUN的数据以异步方式复制
到复制站点存储设备的从LUN;
2.主站灾难发生后,远程复制关系被断开,此时在复制站点进行强行主从切换,将复
制站点的从LUN提升为新的主LUN;
3.复制站点接替主站点的业务,保证业务不被中断(当主机侧有自动切换软件时,异
步远程复制同样可以实现自动切换功能);
4.主站点在灾难恢复后,重新建立远程复制pair关系,将复制站点上“新主LUN”
的数据同步到主站点的“新从LUN”,再多次启动同步,使得“新主LUN”与“新
从LUN”间滞后的写操作降到比较小的程度;
5.复制站点停止业务;
6.再启动一次同步,使得“新主LUN”与“新从LUN”数据完全一致(这次同步主
要是消除上一次同步时主机写操作造成的差异,因为之前的多次同步,此次同步会
很快完成);
7.再进行一次主从切换操作,恢复最初的异步远程复制的镜像关系;
8.最后,主站点重新恢复业务,完成整个灾备流程。
5 远程复制HyperMirror的技术特点
5.1 任意的组网方式
OceanStor 存储阵列的远程复制支持平行组网和交叉组网两种方式,如图5-1。
由于采用
了双链路冗余模式,任意一条链路断开都不会影响业务。
图5-1远程复制组网图
5.2 灵活的成员LUN设置
OceanStor 存储阵列的远程复制对其成员LUN的工作控制器没有任何限制,用户可以灵
活的设置LUN的工作控制器,如图5-2。
任意单个控制器故障,LUN都可自动切换到
其它控制器上,不会中断业务。
图5-2灵活的工作控制器设置方式
5.3 多台阵列互联
OceanStor 存储阵列的远程复制支持一台阵列最多与8台阵列互联,如图5-3。
从图上我
们可以看出,OceanStor 存储阵列远程复制的阵列级扇出和阵列级扇入都为8。
图5-3与多台阵列互联
5.4 互为镜像
OceanStor 存储阵列的远程复制支持两台阵列互为镜像,如图5-4:
图5-4互为镜像
5.5 可变的网络连接
OceanStor 存储阵列的远程复制支持FC和iSCSI两种网络连接(如图5-5),并且可以
根据用户的具体应用场景,适应阵列直连、通过FC光纤交换机连接、通过IP交换机连
接、通过IP-WAN连接等复杂网络环境。
图5-5支持FC和iSCSI
6 远程复制HyperMirror的应用场景
OceanStor存储阵列的远程复制HyperMirror主要应用于数据的容灾备份。
对于同步远程复制而言,每一个写请求都需要同时写到主站点和远端复制站点以后才会
返回生产主机写完成,在主站点和复制站点相距较远的情况下,存储系统对前台应用程
序的写延迟较高,不利于用户正常业务的运行。
因此,同步远程复制HyperMirror/S主
要应用于主站点和复制站点相距较近的容灾场景,如同城灾备。
对于异步远程复制而言,存储系统对前台应用程序的写延迟与主站点和复制站点的距离
无关,所以异步远程复制HyperMirror/A适用于长距离或网络带宽有限情况下的容灾场
景。
OceanStor存储阵列远程复制在不同组网方式下支持的最大传输距离见1:
1.远程复制在不同组网方式下的最大复制距离
下面介绍几个典型的OceanStor存储阵列的远程复制的应用场景,大多数应用场景同时
适用于同步远程复制和异步远程复制。
6.1 组建中央数据备份站点
1.场景描述:
客户的业务分散在不同的异地;
需要对每一个分站点的数据进行远程容灾;
需要对所有备份数据进行统一管理。
2.场景示意图:图6-1
图6-1中央数据备份站点示意图
3.场景特点:
●集中管理备份数据,便于用户在不影响正常业务的情况下,对所有数据进行分析和
挖掘;
●任何一个分站点遭遇灾难,中央数据备份站点都可以接管其业务,便于统一管理业
务的切换;
●OceanStor存储阵列的远程复制支持组建拥有最多32个分站点的中央数据备份站点
(与最大扇入数Fan-in有关);
●每一个分站点可以根据自己与中央数据备份站点的距离,灵活决定选择同步远程复
制还是异步远程复制。
6.2 组建Active-Active业务站点
1.场景描述:
客户的业务在不同的两地;
两个业务站点都需要进行远程容灾。
2.场景示意图:图6-2
图6-2Active-Active业务站点示意图
3.场景特点:
●两个业务站点可以独立的运行自己的业务,互不干扰;
●两个业务站点互为备份站点,不需要搭建专门的复制站点,可以有效地减少整个容
灾系统的成本;
●当一个站点发生灾难时,另一个站点可以立即接管它的业务;
●可以扩展到三个及三个以上的业务站点互为镜像;
●具体选用同步远程复制还是异步远程复制可以综合考虑业务特点和站点间隔距离
进行灵活地选择。
6.3 组建数据双备份站点
1.场景描述:
●用户的数据十分重要,需要在不同的三地保存三个副本;
●容灾系统的灾难恢复级别需要达到零数据丢失以上。
2.场景示意图:图6-3
图6-3数据双备份站点示意图
3.场景特点:
●适用于对关键数据进行远程容灾,防止二次灾难带来的数据丢失;
●业务站点发生灾难时,两个复制站点都可以接管业务;
●OceanStor存储阵列目前支持组建同步远程复制的数据双备份站点。
6.4 远程复制代理:HyperMirrorAgent
HyperMirrorAgent负责调用阵列上的HyperMirror增值特性,通过与ConsistentAgent结
合,它能够保证在执行远程复制时,存储在阵列上的数据库数据的一致性。
HyperMirrorAgent只用于异步远程复制。
使用HyperMirrorAgent执行远程复制时,其工作原理如图6-4(以S5000阵列为例)。
图6-4图17 HyperMirrorAgent工作原理
1.当发起方准备执行HyperMirror时,发起方调用安装在主机上的HyperMirrorAgent。
2.HyperMirrorAgent调用ConsistentAgent,由ConsistentAgent完成对需要保证数据一
致性的数据库的“刷盘”功能,即将数据库设置为备份模式,并将将数据库缓存在主机内存中的数据写到阵列上,此时数据库暂停向阵列上的写操作。
3.ConsistentAgent完成“刷盘”操作后,HyperMirrorAgent执行一系列的检查工作,
然后调用阵列上的HyperMirror增值特性,对数据库的各个LUN执行远程复制。
4.远程复制成功启动之后,HyperMirrorAgent再次调用ConsistentAgent,结束数据库
的备份模式,并让数据库恢复正常的写操作。