Find Communities by: Category | Product

1. 原理


1.1 SRDF复制模式


  • 复制模式
    • 同步复制:Synchronous Replication SRDF/S)
    • 异步复制:Asynchronous Replication (SRDF/A)
    • 自适应拷贝复制:Adaptive Copy Replication
  • 复制模式可以动态更改
  • 操作方法可以按设备指定
  • 性能、同步级别和I/O序列化要求决定采用哪种操作模式合适
  • 所有复制模式可以在Symmetrix阵列内共存


1.2 SRDF/A主机写IO处理


            当源盘阵收到数据立刻反馈给主机,主机可以继续写入,不保证数据是否已在目标盘阵

1.png

    数据变动保存在源盘阵内存

2.png

    达到传送周期即打包发送给目标盘阵

3.png

          形成新的周期数据包

4.png

1.3 常见的SRDF/A连接


  • 通过IP广域网连接
    • 距离远
    • 中间链路稳定性低于FC

5.png

1.4 SRDF/A对于链路抖动等的处理机制


  • Link Limbo: 单条链路,短期中断
    • 缺省10
  • Transmit IdleSRDF/A组中所有链路中断
    • 数据传输中断
    • R1盘阵缓存需要传输的数据,达到内存上限则将session suspend
    • 应与DSE共用,用硬盘辅助缓存数据
  • Write Pacing:延长主机写IO响应时间避免内存超限导致的SRDF/A中断
    • Group-level
    • Device-level:用于RDF设备同时参与TimeFinder操作的场景
  • Tolerance Mode:临时设置,在性能与数据一致性间加以平衡
    • 允许若干设备在R1NRR2RWSRDF/A仍为active
    • 此时R2数据的一致性不予保证
    • MSC不支持


1.5 SRDF/A对于内存占用的限制


  • SRDF/A占用内存上限
    • Write Pending Limit
      • 5875之前:盘阵可用内存的80%
      • 5875及之后:在binfile中设置Cache Allocation Policy参数,为可用内存的50%~75%
    • SRDF/A cache usage limit: SRDF/A可用内存占WP的百分比,VMAX缺省为74%VMAX之前缺省94%

ExVMAX WP 75%SRDF/A 74%SRDF/A可用总内存的55.5%

  • SRDF/A组优先级:在内存资源不足时先放弃优先级较低的组
    • 0-FF,缺省80
    • 数值越低,优先级越高


1.6 VMAX3SRDF/A的改进


  • VMAX3单个SRDF/A的组就可以产生多个cycle,小cycle易于完成传输,有利于及时释放内存
  • Multi-cycle mode环境:VMAX3 – VMAX3
    • R1: one capture cycle, multiple transmit cycle
    • R2: one receive cycle, one apply cycle
  • 典型案例
    • R2盘阵内存小于R1盘阵内存
    • 链路丢包较多

 

2. 管理界面及错误信息


2.1 Unisphere for VMAX图形界面


Solutions Enabler提供了命令行界面管理SRDFUnisphere for VMAX提供了图形界面,例如下图。

6.png

2.2 Enginuity错误信息


例如:

  • 047D                – one link lost
  • 046D                – all links for a group lost
  • 047E                – A single link has been gained
  • 046E                – All links in an RDF group have been regained
  • CACA   – SRDF/A session drop due to non-user requests


2.3 symevent错误信息


例子:

  • 单条链路断
  • 组内所有链路断组将会进入suspend状态
    • 如果配置了transmit idle,将首先进入transmit idle状态

7.png

  • 内存超限

8.png

3. SRDF/A常见中断原因及解决


除了前面所说的链路问题,SRDF/A常见的中断原因是需要传输的数据超出了传输链路带宽,数据积压占用内存达到上限而自动中断。当然,盘阵性能问题导致占用内存过多也会有相同的结果。

  • 传输带宽不足:增加传输链路带宽
  • 短期带宽不足:DSE
  • 盘阵性能问题:解决性能问题


3.1 链路带宽不足

9.png

  • 配置
    • B点到C点间为SRDF/A
    • 3对盘阵的SRDF/A远程复制共用带宽为622Mb的专线。
  • 问题
    • 某一台盘阵的SRDF/A组经常在17:30左右宕掉
  • 原因
    • 取性能数据检查,在17:30开始经常出现所有SRDF/A组的流量需求总和超过90MB/s,即720Mb/s的现象,超过了链路带宽
    • 由于在高峰时段链路带宽不足,导致SRDF/A组断掉

时间点

所有组流量需求总和

11/12/2013 17:20

  1. 87.94

11/12/2013 17:25

  1. 94.59

11/12/2013 17:30

  1. 71.96

11/12/2013 17:35

  1. 73.58

11/12/2013 17:40

  1. 79.58

11/12/2013 17:45

  1. 79.58

11/12/2013 17:50

  1. 78.46

 

  • 解决
    • 增加链路带宽

3.2 短期带宽不足

10.png

11.png

  • 问题:从性能数据看,SRDF/A流量突增,然后整个groupoffline了。
  • 日志分析:从盘阵日志看到,出现CACA.10错误,意味着盘阵的内存使用超出限制,主动中断SRDF/A
  • 情况分析:
    • 峰值时间很短
    • 未使用DSE
    • 后端资源不忙
  • 结论:建议使用DSE

下面是使用DSE后的性能图表。

12.png

  • 解决:同样的盘阵,在使用DSE之后,从SRDF/S group 206短期传来大量数据需要通过SRDF/A group 207传输到远程灾备盘阵,可以看到DSE缓存了大量数据,SRDF/A group 207在接近传输上限的程度运行了一段时间,但SRDF/A group并未中断。

3.3 链路问题导致内存超限


  • 日志分析:
    • 16:30报错显示cycle number已经一个小时没有切换

13.png

    • 23:44报错显示内存超限导致SRDF/A中断。从性能数据看当时Write Pending达到79%

14.png

  • 性能数据分析:15:30开始,cycle number不再增长,但rdfa的状态仍然是active,之后,active cycle size持续增长,占用内存也持续增长,一直到23:45时变成了inactive

15.png

16.png

  • 原因:链路质量问题导致R2无法正常接收cycle,导致cycle size持续增长,最终超过Cache usage limit
  • 解决:修复有质量问题的链路。

众所周知,NetWorker可以在备份组结束后自动发起克隆任务。这样对于有数据多份要求的客户有很多的便利,他们可以保证每次的备份数据都可以正常保存两份。而且他们不需要去单独配置克隆任务或者发起克隆命令。

 

那么NetWorker会根据什么设置去执行克隆作业呢?大家都知道在组属性中我们可以选择在备份执行后发起克隆,发起的方式有如下图两种:

 

克隆模式:

Start on each save set completion

Start on group completion

nw1.png

 

 

那么我们就根据这两种不同的配置来解释一下克隆的工作原理

Start on Group Completion

==========

1. 克隆任务在该组所有备份任务完成后发起。

2. nsrclone发起之前,备份服务器会去检查备份的媒体数据库来确认需要克隆哪些存储集

3. 备份服务器的媒体数据库通过这个检索规则来确认只有最近的备份数据才会被克隆任务执行:“save set start time” >= “save group start time”

4. 但检索媒体数据库完成,所有需要克隆的存储集的SSID都会被返回给nsrclone。如下面命令行:

nsrclone -s bdi-prd-nwk.corp.danamon.co.id -v -D 5 -b ddboost_sql_bsd_clone -C 1 -S -f < 497909124 514686338

 

所以我们需要明白克隆的完成需要同时参考客户端和服务器。“save set start time”这个参数是由备份客户端提供的,也就是客户端启动备份的时间。但是“save group start time” 这个参数则是由备份服务器提供。这个是备份组发起的时间。如果备份服务器和备份客户端之间的时间有差异,那么就可能会出现有些数据不会被克隆的情况。 也就是我们常说的数据丢失。

 

 

如果需要了解媒体数据库检索的具体情况,可以对nsrd开启-D5或者以上,结果会返回检索命令。

On Each Saveset Completion

==========

1. 在备份组发起的时候,克隆任务就发起来了。

2. 一个临时文件会创建出来作为克隆的源文件。默认路径是:\\nsr\\tmp\\sg\\<groupName>\\<.groupName>

3. 命令nsrclone会根据下面的参数来运行:

nsrclone -s bdi-prd-nwk.corp.danamon.co.id -v -D 5 -b ddboost_sql_bsd_clone -C 1 -i "D:\\Program Files\\EMC NetWorker\\nsr\\tmp\\sg\\PRD-Adhoc-SQL-Cumulative\\.PRD-Adhoc-SQL-Cumulative" -g PRD-Adhoc-SQL-Cumulative

4. 每当一个save任务运行结束,就会把SSID写入到\\nsr\\tmp\\sg\\<groupName>\\<.groupName>

5. 在备份组完成之后,这个临时文件就会被删除。

 

所以为了保证克隆精确完成,我们必须保证在组启动前这个临时文件不存在,同时在组备份成功完成后这个临时文件不再存在。同时如果我们对于克隆的存储集有疑问,也可以打开这个临时文件检查。

 

 

Mandy Xu

Technical Support Engineer, NetWorker

Dell EMC | Customer Service

 

Filter Blog

By date:
By tag: