所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

OceanStor 9000 V300R006C10 文件系统特性指南 05

评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
原理描述

原理描述

介绍InfoReplicator提供的相关功能和实现原理。

基础概念

在学习InfoReplicator的功能原理前,您有必要先了解Pair、同步、分裂等基础概念。

Pair

InfoReplicator特性中,Pair是一条数据复制关系,描述了数据复制的来源和目标,以及数据复制的频率等相关规则。

创建Pair时,需指定本端站点除文件系统根目录(“/”目录)之外的任意目录作为数据复制的来源(即主目录),并指定远端站点除文件系统根目录之外的任意空目录作为数据复制的目标(即从目录)。指定的从目录必须为空目录,否则无法创建Pair。
图6-1  Pair
同步

同步是指将主目录里的数据向从目录复制和更新的过程,InfoReplicator特性基于Pair对数据进行同步,维持主、从目录间的数据一致性。

InfoReplicator支持全量同步与增量同步:
  • 全量同步:是指将主目录中的所有数据全部复制到从目录中。
  • 增量同步:是指将两次同步间隔期内主目录的增量数据(包括新增、修改、删除)更新到从目录中。

创建远程复制Pair后,需要用户手动触发初始同步,将主目录中的数据全量同步至从目录。后续在主目录新增、修改数据后,每启动一次同步,系统均采取增量同步的方式,即仅对上一次同步完成后的差异数据进行同步,以此减少数据复制时间,提升复制效率。当数据在主目录中被删除时,启动同步后,从目录中的该数据也将被自动删除。

InfoReplicator支持在复制数据的同时,将主目录的基本属性、扩展属性、ACL(Access Control List)与WORM(Write Once Read Many)等属性也一并复制到从端。此外,用户也可将主目录的NFS/CIFS共享等NAS协议配置信息导出备份,以便在主站点不可用时,在从站点导入已备份的NAS协议配置,进而使从端快速接管业务。

分裂

InfoReplicator支持对Pair进行分裂,即暂时中止主、从目录间的数据同步。分裂可以灵活满足用户的某些特定需求,例如:暂时性的链路维修、网络带宽扩容、归档从目录某一时间点的数据等。

当Pair被分裂后,正在进行的Pair同步任务将暂停,Pair所指定的两端目录的主从关系不变,前端业务对主、从目录的读写权限也不会产生变化。如果用户希望恢复Pair的数据同步,重新保持主、从目录的数据一致时,只需对已分裂的Pair手动启动一次同步操作即可。上次同步由于分裂操作导致未被复制到从目录的部分差异数据将继续进行同步,而已同步的部分则无需重新同步,这样也提升了数据同步的效率(此功能也被称为断点续传)。

分裂和同步结合使用,可以对远程复制的数据同步过程进行有效的控制。

基于快照的异步复制

InfoReplicator基于目录快照实现主目录与从目录间的数据异步复制。

对Pair启动初次同步时,存储系统自动为主目录创建一份该时间点的快照,作为本次数据同步的基准快照。而后续每次增量同步,系统则再次为主目录创建一份快照,并分析两次同步期间的差异日志,然后将差异部分的数据同步至从目录,这样系统无需遍历完整的目录树,提升了增量同步的效率。同时,利用快照文件数据内容不变的特性,保证主目录能够正常接收业务读写而不影响待同步的数据。因此,在此快照时间点后的数据修改则需要在下一次同步启动时才能同步到从目录当中,确保了数据的一致性。

例如,当用户针对主目录为“/data”的Pair在14:00执行数据同步,并于14:10完成同步。在14:05用户修改了“/data”目录内的文件A,由于该数据变更没有记录在14:00创建的主目录快照中,因此,本次数据变更在下次数据同步启动前,将不会同步到从目录。

当数据同步完成时,系统在从端集群为从目录创建一份一致性快照。因此,可以通过查看从目录是否存在本次同步的一致性快照来判断同步是否完成。图6-2描述了InfoReplicator是如何基于快照进行异步复制的。
图6-2  基于快照进行复制
为了确保在系统故障时可以根据备份的快照快速恢复数据,默认情况下,主、从端集群都各自保留最新的两份快照。后续每次同步完成后,上一次同步完成后保存的两份快照中较早创建的一份快照将被删除,而保存最新同步所建立的快照。当开启从目录快照保留时长限制功能后,每次同步后所建立的从目录一致性快照都将保留一段时间而不被删除,该期限可由管理员进行配置。系统故障时,可基于最近的一致性快照进行快照回滚,将数据还原。
说明:
由于系统需要至少保留两份快照,当开启从目录快照保留时长限制功能时,有可能在启用该功能之前创建的快照即便不满足保留期限要求,也不会被删除。

远程复制快照目录位于创建Pair时指定的主目录之下,快照被命名为RepSnapPair-xxxxxxxx-PairID-xx。其中,PairID是创建Pair时由系统自动生成的全局唯一的ID,可方便用户识别该快照目录属于哪个Pair。

InfoReplicator基于InfoStamper(目录级快照)提供的快照机制创建远程复制快照,但是无需InfoStamper特性的License支持。关于快照创建、读写、删除、回滚的相关原理,请参见OceanStor 9000 InfoStamper特性指南》

同步方式

InfoReplicator采用全量同步和增量同步结合的方式,提供良好的数据同步效果。

全量同步是指将主目录待同步的数据全量复制到从目录,增量同步则是指仅将前一次同步完成到本次同步启动期间发生变更的数据增量复制到从目录。Pair初次同步采用全量同步的方式,而后续每次同步则采用增量同步的方式。
  • 全量同步通常会占用大量的带宽,耗费时间也长,对系统性能影响大。
  • 增量同步由于每次同步的数据量小,占用带宽会比全量同步小,耗费时间也短,对系统性能影响相较全量同步要小。
初始全量同步的实现原理如图6-3所示。
图6-3  初始全量同步
原理说明如下:
  1. 用户手动启动初次同步。
  2. 系统为主目录创建基准快照,并扫描主目录。
  3. 在从目录创建与主目录完全一致的目录结构。
  4. 将主目录的数据全量写入从目录对应位置。
  5. 将主目录下目录和文件的属性(包括基本属性、扩展属性、ACL、WORM等)发送到从端,并写入对应目录和文件。
  6. 数据复制完成后,从目录创建一致性快照。
由于InfoReplicator采用的是异步远程复制,当初始同步完成后,每次向主目录写入的新数据并不会立即被同步至从目录,而是由管理员手动启动一次同步或是等待Pair预先指定的同步周期到达后自动启动同步,系统才会将此期间所有写入的新数据一次性同步至从目录。该增量同步方式的实现原理如图6-4所示。
图6-4  增量同步
原理说明如下:
  1. 客户端向主目录写入数据N。
  2. 写I/O成功后,主目录向客户端返回写请求成功,并记录差异日志。
  3. 管理员手动启动同步,或同步周期到达时,系统自动启动同步。
  4. 系统创建主目录本次同步的基准快照,并分析差异日志,确定待增量同步的数据。

    差异日志记录了两次快照期间,主目录的数据与元数据的变化,包括文件与目录的创建、删除、重命名,属性修改,文件内容修改等。

  5. 主端将差异日志打包成消息后发送到从端,从端解析消息,获取差异日志,将差异数据块同步写入到从目录对应的目录或文件当中。
  6. 当主目录基准快照数量超过两份时,系统删除较早的一份快照,以节省系统空间。当基准快照数量少于或等于两份时,则不删除已有的基准快照。
  7. 在从目录创建本次同步完成的一致性快照。
  8. 根据当前从目录快照数量与快照保留策略(即从目录快照保留时长限制功能),删除多余的一致性快照。
    • 当未开启从目录快照保留时长限制时,系统仅保留最近两次同步完成后创建的一致性快照,而将更早数据同步创建的一致性快照删除,以节省系统空间。
    • 当启用了快照保留时长限制时,系统删除超过保留时长的一致性快照。在保留时长内创建的一致性快照将不会被删除,一直保存在从端存储系统中。
      说明:
      由于系统需要至少保留两份快照,当开启从目录快照保留时长限制功能时,有可能在启用该功能之前创建的快照即便不满足保留期限要求,也不会被删除。

由于InfoReplicator实现了对快照数据变更进行跟踪,因此在增量同步时,系统仅需将差异部分的数据块同步到从目录即可,而无需遍历完整的目录树。数据块最小可为16KB,这样极大提高了复制效率,降低了带宽开销。当一个文件在主目录内被移动或重命名时,系统不会先删除再创建该文件,而是会跟踪此变更,然后在从目录同步对该文件执行移动或重命名操作,这样避免了多余的复制操作。

复制链路

InfoReplicator支持通过复制区域和复制区域通道管理复制链路,确保复制任务顺利完成。

复制区域是指参与远程复制任务的节点集合。系统部署完毕激活InfoReplicator特性License后会自动生成一个复制区域,该复制区域默认不包含节点。用户可以通过增加或移除复制区域内的前端业务IP地址,限定参与远程复制任务的节点范围。参与远程复制的节点越多,单个节点的业务压力也将越小,远程复制对集群的读写性能的影响则会上升;参与远程复制的节点越少,单个节点的业务压力也将越大,远程复制对集群的读写性能的影响则会下降。

复制区域通道(Channel)是在主、从端OceanStor 9000系统两个复制区域间建立起来的一组通信链路。用户可设定该复制区域通道的带宽上限,作为远程复制任务最高可使用的单节点带宽,从而降低对系统其他业务的影响。当设定了带宽上限后,位于复制区域通道的发起端的节点传输带宽将受到限制,而接收端的节点则不受此限制。
说明:
发起端是指执行创建复制区域通道操作的一端,而另一端即为接收端。通常,用户对生产站点的性能需要进行有效监控和管理,因此建议选择主端OceanStor 9000系统作为复制区域通道的发起端,而将从端OceanStor 9000系统作为接收端。

两个OceanStor 9000集群之间仅允许创建一条复制区域通道,且这两个集群间的所有远程复制Pair将共用此通道,所有远程复制通信链路的鉴权和流控均基于此通道完成。

正常情况下,主、从端参与远程复制的节点按照以下原则建立复制链路,并组成复制区域通道,从而达到链路负载均衡。
  • 每个主端节点至少和从端节点建立两条通信链路。
  • 每个主端节点的连接数尽量一致。
  • 每个从端节点的连接数尽量一致。
  • 主端节点与从端节点必须同时使用IPv4地址或者同时使用IPv6地址。
以主、从端各三个节点参与远程复制为例(即复制区域内各三个节点),主、从端的复制链路如图6-5所示。其他节点由于不在复制区域内,因此不会建立远程复制通信链路。
图6-5  节点正常时的复制链路
当节点故障退出集群或由管理员增加、删除复制区域内的节点时,InfoReplicator将自动重新建立复制链路,使当前可用的节点间复制链路负载均衡,如图6-6所示。
图6-6  节点故障时的复制链路
只要复制区域内仍存在一个或以上的节点可正常运行,复制链路将一直连接,供远程复制任务进行主、从端节点的数据交互。
说明:
管理员同时调整主、从端复制区域内的节点,使两端同时仅保留一个节点且这两个节点之间并无复制链路连接时,主、从集群复制区域通道将短暂断开连接,并上报事件。到达自愈周期后,系统将自动修复复制区域通道,重新建立这两个节点间的复制链路,使复制区域通道恢复正常。为确保远程复制Pair正常可用,请勿同时删除主、从端复制区域内的节点。

鉴权与接入控制

InfoReplicator通过链路鉴权和客户端接入控制,确保远程复制业务安全可用。

链路鉴权
复制链路章节已介绍远程复制数据是通过复制区域通道进行传输。为了对抗数据在网络上进行传输面临的各种网络安全风险,InfoReplicator采用了链路鉴权机制,确保数据复制链路的安全。系统安装完毕后,各节点内都将部署并运行鉴权模块,使用基于TCP连接的用户名口令认证方式。
  • 首次创建复制区域通道时,必须指定专用的机机帐号进行链路鉴权。只有当主、从端鉴权通过后,才可成功创建复制区域通道,并被用于远程复制任务进行数据传输。
  • 当节点重启等原因造成链路断开,再次连接时,系统自动获取数据库中已保存的用户名口令进行认证,无需人为参与。
  • 当复制区域通道鉴权密码发生变更时,用户需要及时在复制区域通道管理界面更新此密码,才能保证复制链路故障恢复时自动进行链路重连接。否则,复制链路故障排除后,复制区域通道不会自动恢复。

由于复制链路鉴权对于来自外部的DDoS(Distributed Denial of Service)攻击尚无法有效拦截,建议用户同时部署防火墙等设备,避免短时间内资源被占满导致集群无法进行连接通信。

客户端认证与接入控制

为确保安全性,客户端接入OceanStor 9000时,系统需要对该客户端进行认证与接入控制。详细内容,请参见OceanStor 9000 管理员指南》手册的“认证与接入控制”章节。

应用InfoReplicator特性时,用户在数据同步的同时,也可将主目录的NFS/CIFS共享等NAS协议配置信息导出备份,以便在主站点不可用时,在从站点导入已备份的NAS协议配置,确保客户端访问从目录时拥有相同的权限,保证业务连续。详细要求如下:
  • 域认证
    主、从站点的OceanStor 9000系统都必须加入同一个域,即使用相同的域认证服务器保管用户帐号与客户端凭证,如图6-7所示。
    图6-7  域认证模式下的客户端认证
  • 本地认证
    使用CIFS客户端(如Windows)接入OceanStor 9000访问主、从目录时,主、从站点用于认证的本地用户和用户组ID(即UID、GID)必须保持一致,否则当主站点故障时,从站点将由于权限不对而无法正常接管业务。OceanStor 9000支持创建本地认证用户或用户组时指定UID或GID,确保具有相同UID和GID的用户访问主、从目录,如图6-8所示。
    图6-8  本地认证模式下的CIFS客户端认证

    使用NFS客户端(如Linux)接入OceanStor 9000时,当主站点故障后,只需在从站点导入已备份的NAS协议配置,即可保证客户端访问从目录时具有与访问主目录时相同的权限。

RPO/RTO

介绍影响RPO和RTO的远程复制相关因素。

国际容灾标准SHARE78定义了容灾恢复的七个级别,InfoReplicator支持“Tier6 数据级容灾”级别的容灾能力,即可以实现“没有或基本没有数据丢失”。RPO(Recovery Point Objective)和RTO(Recovery Time Objective)是衡量容灾能力的重要指标。
  • RPO又称为恢复点目标,指业务系统所允许的在灾难过程中的最大丢失数据量,用来衡量容灾系统的数据冗余备份能力。即当灾难发生后,容灾系统能将数据恢复到灾难发生前的某个时间点的数据,通常以时间长短来计量。RPO越小,意味着数据丢失越少。
  • RTO又称为恢复时间目标,指业务应用从灾难状态恢复到可运行状态所需要的时间,用来衡量容灾系统的业务恢复能力。它是灾难发生后到重新恢复系统运作所花费时间的指标。RTO越小,意味着业务中断的时间越短。

通常根据远程复制自动同步时的最小同步周期计算RPO规格。若同步周期为(N),则InfoReplicator支持的RPO最小值(T)满足:N ≤ T ≤ 2N。

影响RPO的主要因素如表6-2所示。结合这些因素与客户实际环境,有助于更好地规划InfoReplicator特性,以满足客户的容灾需求。
表6-2  影响RPO的因素

类别

因素

影响说明

数据

主目录变更的数据量

InfoReplicator在初次同步完成后,采用增量同步方式完成后续的远程复制,因此相邻两次同步之间变更的数据量决定了数据复制时间的长短。同等条件下,变更的数据量越小,数据复制时间越短。

主目录的文件数

相同数据量时,小文件场景意味着文件数更多,系统在扫描主目录时需要更多次数的I/O,从而使扫描时间加长。而大文件场景则需要较少的I/O次数。

外部

网络带宽与时延

网络能力是影响远程复制耗时的重要因素。为满足RPO需求,必须有足够的带宽和低时延来保证变更的数据在下一次同步启动前都能够被传输到从目录。否则,如果Pair同步任务启动时上一次同步仍未完成,则本次同步不会启动,意味着同步周期间隔变长,RPO也将变大。

业务负载

业务负载越高,能够参与复制传输的系统资源和性能都将下降,数据复制耗时将变长。

内部

节点性能

相同外部条件下,节点的CPU、内存运算能力越高,性能越好,在传输相同数据量时所花的时间也越短。

磁盘类型不同,I/O能力也不同,I/O能力越高,数据复制耗时越短。磁盘I/O能力:SSD > SAS > SATA。

节点数量

InfoReplicator支持配置复制区域,从而指定参与远程复制任务的节点数量。得益于OceanStor 9000的分布式架构,节点参与执行数据传输时采用的是并行方式,因此,节点数越多,数据复制耗时越短。

InfoReplicator特性配置

同步周期

在确保增量数据可在一个同步周期内完成复制的前提下,配置更短的同步周期有利于降低RPO。
说明:

在带宽、负载、速率等配置都满足条件时,InfoReplicator支持同步周期最小为15分钟,即系统满足RPO要求最小为30分钟的应用场景。

同步速率

InfoReplicator支持对远程复制任务的同步速率进行配置,以平衡复制效率与对性能的影响。同步速率越高,即数据传输速度越快,数据复制时间也越短。

带宽限制

为降低远程复制对系统性能的影响,用户可设置复制区域通道的带宽限制,将复制区域通道发起端的带宽限定在一定范围。

在满足系统性能的前提下,取消复制区域通道的带宽限制,或将限制的最大带宽调高,都将提升复制区域通道发起端的数据复制能力,缩短数据复制时间。

InfoReplicator支持将主目录的NFS/CIFS共享等NAS协议配置信息导出备份,以便在主站点不可用时,在从站点导入已备份的NAS协议配置,进而使从端快速接管业务。为实现最小RTO,用户可养成定期备份导出共享目录NAS协议配置信息的习惯,方便快速在从站点接管业务。

Failover

InfoReplicator支持手动Failover,使业务在短时间内得到恢复,确保业务持续运行。

Failover又称为故障切换或失效切换,在存储容灾领域,通常指生产站点因灾难或其他故障失效时,由灾备站点接管业务,保证业务正常运行。

InfoReplicator提供两种Failover方式。
  • 取消从目录写保护

    默认情况下,从目录处于写保护状态,以实现数据的正常复制。取消从目录写保护,可使从目录变为读写状态,允许为上层业务提供数据写服务。此时Pair的目录主从关系未发生变化,但是主目录不可向从目录同步数据。为保证数据的完整性,取消从目录写保护后,灾备站点会自动根据已保存的一致性快照回滚从目录,将从目录的数据还原至最近一次的一致性快照点状态。

  • 主从切换

    主从切换是指Pair中主、从目录的角色进行转换的过程。主从切换前必须已取消从目录写保护,切换后的Pair与原Pair使用相同的Pair ID标记。主从切换后,需为新的从目录设置写保护,确保数据由新的主目录向新的从目录进行同步。为保证数据的一致性,当启动从目录写保护后,生产站点会自动根据已保存的一致性快照回滚原主目录(即新的从目录),将原主目录的数据还原至最近一次的一致性快照点状态。

两种Failover方式有着各自的优缺点,适用于不同的应用场景,用户可灵活选择。
表6-3  Failover方式
Failover方式 优点 缺点 应用场景
取消从目录写保护 操作简单,耗时短。 无法进行数据同步,新写入的数据可靠性降低。 临时性的业务接管,如生产站点短暂故障、下电检修、容灾演练等。
主从切换 重新建立数据同步关系,确保了数据可靠性。 操作复杂,耗时长。
  • 长时间的业务接管,如生产站点计划性进行集群维护。
  • 需要将新写入的数据导回生产站点(增量Failback)的必要前提。
Failover流程和期间业务处理方式如图6-9所示。为方便理解,图6-9将取消从目录写保护与主从切换作为一个连贯流程表示。实际应用中,当取消从目录写保护后,灾备站点即可正常接管业务,此时,用户可根据自身需求自主选择是否需要进行主从切换。
图6-9  Failover流程

Failover基于每个Pair执行,如果多个Pair涉及的业务均需要由从端接管,请分别对这些Pair执行Failover操作。

Failback

InfoReplicator支持手动Failback,在故障恢复后,快速将业务回切到生产站点。

Failback又称为故障回切或故障恢复,在存储容灾领域,通常是指当生产站点从故障中恢复时,重新将业务从灾备站点回切到生产站点。

由于InfoReplicator提供了取消从目录写保护和主从切换两种Failover方式,因此,用户可基于之前选择的Failover方式,结合业务需求,灵活采用Failback方式。

主从切换后Failback
主从切换后,上层业务由灾备站点接管,新写入的数据由灾备站点向生产站点同步。Failback后,生产站点将回滚本端数据以维持数据一致性,建议先手工完成一次数据同步后再执行Failback的系列操作,避免最新写入的数据未同步到生产站点。详细业务处理流程如图6-10所示。
图6-10  主从切换后Failback
取消从目录写保护后Failback
取消从目录写保护后,上层业务可以向从目录写入数据,因此,主、从目录的数据会不一致。此时如果需要Failback,将业务切回主端,用户需要明确以哪一端的数据为基准。
  • 以主端数据为基准Failback:即不需要保留从端新写入的数据,直接恢复主、从端的数据同步即可。如图6-11所示。
    图6-11  以主端数据为基准进行故障恢复
  • 以从端数据为基准Failback:即需要通过同步从端数据至主端,以保持数据一致性,然后再将业务切回主端。如图6-12所示。
    图6-12  以从端数据为基准进行故障恢复

状态监控

通过对远程复制Pair各种状态进行监控,有效管理远程复制。

InfoReplicator支持对远程复制的运行状态进行监控,便于管理员实时掌握Pair状态,有效管理远程复制。通过查看Pair状态,可以及时地根据状态取值对远程复制进行同步、分裂、主从切换等操作,并在操作结束后判断操作是否成功。远程复制中的Pair状态及状态间的转换如图6-13所示。
图6-13  Pair状态
除监控Pair运行状态外,DeviceManager还提供了可视化的管理界面,供管理员查看远程复制任务的进度以及从端数据的完整性,有助于根据实际需求及时对远程复制任务作出调整。管理界面如图6-14所示。
图6-14  远程复制管理界面
翻译
下载文档
更新时间:2019-03-30

文档编号:EDOC1000162199

浏览量:29083

下载量:105

平均得分:
本文档适用于这些产品
相关文档
相关版本
Share
上一页 下一页