Find Communities by: Category | Product

1 2 3 Previous Next

工程师手记

40 Posts authored by: EMC中国现场支持部

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
  • 解决:修复有质量问题的链路。

GENSTATS作业运行过程中,有时会出现如下错误,导致作业运行失败:

03.10.48 J0253806  -DLMDAILY DLM4VT4  STEP1      00    58    .00    .00    .00    625  0      0      0      0    0    35

03.10.48 J0253806  -DLMDAILY DLM4VT4  STEP2      00    50    .00    .00    .00    337  0      0      0      0    0    36

03.19.48 J0253806  -DLMDAILY DLM4VT4  STEP3      00    35    .00    .00  9.00    163  0      0      0      0    0    37

03.19.48 J0253806  EDG8197I VOLUME BFL999 IS NOT DFSMSrmm MANAGED

03.19.48 J0253806 *IEC501A M 06FC,BFL999,NL,,DLMDAILY,STEP4.DLM4VT4,BFL999.FLAT

03.19.48 J0253806  IEC502E K 06FC,BFL999,NL,DLMDAILY,STEP4,BFL999.FLAT

03.19.58 J0253806  -DLMDAILY DLM4VT4  STEP4      08    65    .00    .00    .17    892  0      0      0      0    0    38

03.19.59 J0253806  -DLMDAILY DLM4VT4  GO      FLUSH      0    .00    .00    .00      0  0      0      0      0    0    39

03.19.59 J0253806  +DLM8888E An ERROR Has Occurred in last step SA390

03.19.59 J0253806  -DLMDAILY DLM4VT4  DLMWTO      12    44    .00    .00    .00    512  0      0      0      0    0    40

03.19.59 J0253806  IEF404I DLMDAILY - ENDED - TIME=03.19.59    

        这是因为主机作业运行GENSTATS时,主机发命令给DLm的VTE要求VTE收集性能数据,VTE会运行find –n BFL***.FLAT命令查找文件,这个命令会在整个目录里搜寻文件,如果找到文件,就将生成的新文件替换老文件;如果没有找到,就将新文件放到control device对应的目录下。    

        问题出在find命令上,这个find命令运行时间较长,在运行过程中有时会中断,在VTE上无法生成文件,因而造成主机的作业失败。 解决方案是在作业里直接加上path name, 例如://DLM4VT1  EXEC GENSTATR,CMD=999,UNIT=/06CC,UNIT2=06CD, PATH='/tapelibDRZJ' , 这样就省去了find命令,同时也节省了运行时间。    

        修改后的运行结果是这样:

03.02.25 J0064006  -DLMDAILY DLM4VT4  STEP1      00    38    .00    .00    .00    361  0      0      0      0    0    35

03.02.25 J0064006  -DLMDAILY DLM4VT4  STEP2      00    55    .00    .00    .00    440  0      0      0      0    0    36

03.02.26 J0064006  -DLMDAILY DLM4VT4  STEP3      00    36    .00    .00    .00    191  0      0      0      0    0    37

03.02.26 J0064006  EDG8197I VOLUME BFL999 IS NOT DFSMSrmm MANAGED

03.02.26 J0064006 *IEC501A M 06FC,BFL999,NL,,DLMDAILY,STEP4.DLM4VT4,BFL999.FLAT

03.02.27 J0064006  IEC502E K 06FC,BFL999,NL,DLMDAILY,STEP4,BFL999.FLAT

03.02.27 J0064006  -DLMDAILY DLM4VT4  STEP4      00  1384    .00    .00    .01  3557  0      0      0      0    0    38

03.02.27 J0064006  GEN100I INPUT RECORDS  : 0000001204

03.02.27 J0064006          PASSED FILTERING: 0000001204

03.02.27 J0064006          MOUNT RECORDS  : 0000000602

03.02.27 J0064006          UNLOAD RECORDS  : 0000000602

03.02.27 J0064006          MOVED VOLUMES  : 0000000000

03.02.27 J0064006  -DLMDAILY DLM4VT4  GO          00    194    .00    .00    .00    916  0      0      0      0    0    39

03.02.27 J0064006  -DLMDAILY DLM4VT4  DLMWTO  FLUSH      0    .00    .00    .00      0  0      0      0      0    0    40

03.02.27 J0064006  IEF404I DLMDAILY - ENDED - TIME=03.02.27

修改后同时看到运行时间从9分钟缩短到只剩2秒钟。

最近碰到有使用了企业级闪盘(SSD)的EMC客户询问SSD的寿命到底如何。他们有些担心,过了3~4年,SSD会因为闪盘单元的写磨损,导致批量的损坏。

vmax_vnx_logo.png

XtremIO_logo.png

大家都有基本的概念,普通PC使用的闪盘,还有U盘,每单元寿命只能承受1000多次的“写”。企业存储里,动则几万到几十万IOPS的,感觉分分秒秒的就能写坏很多闪盘单元,然后SSD用不了几年就要纷纷报销了?

实际情况如何呢?

EMC是最早开始卖带企业级闪盘的公司,从08年开始卖带SSD的存储,到现在已经进入实打实的7年了。实际看损坏率,基本可以很让人放心。

中国的第一个客户从09年开始使用9SSD,到现在为止7年多,只有一块更换,还不是因为介质问题而是其它问题更换的。其它的客户大致统计上看,更换率也低于普通磁盘。

这从原理上怎么解释呢?

EMC刚推出SSD时,官方的描述是这样的,

Characteristics of Enterprise Flash SSDs

  • Higher performance, reliability and cost technology
    • SLC NAND Flash-based persistent storage
  • Dual-ported Fibre Channel drive interface
  • Optimized for maximum lifecycle and random+sequential read/write performance
    • On-board DDR SDRAM cache for read pre-fetch, write buffering, and block mapping
      • Includes internal backup power to for destage to Flash on power failure
    • Multi-channel parallel I/O to NAND Flash components for maximum performance
  • Integral Error Correction Code (ECC) to detect and correct bit errors
  • Transparent wear-leveling to minimize and delay inherent wearing effect of rewriting
  • Reserved NAND flash capacity, used to remap bad blocks as they wear

 

上述英文说明里,关键的有几点,能说明跟寿命有关,

  1. 1. SLC NAND,这是单层单元闪存,寿命本身比消费级产品使用的多层单元闪存寿命要高很多(具体数量级在下面说明);
  2. 2. 为最长寿命优化设计,闪存盘内内置RAM缓存,有内置电源,不仅提速,还可以优化写操作;
  3. 3. 内置纠错,能修正单比特错误;
  4. 4. 保留的容量,能把损坏的单元做重新定位。

那么跟消费级的闪盘比,我们使用的SSD能经过多少次真实的写呢?答案是10万次以上。这是个100倍的关系。

08EMC发布SSD时,就有Q&A里说:we expect the Flash drives to have a much better MTBF than mechanical drives since they have no moving components. Each flash cell is guaranteed to sustain 100,000 write and typically sustains much more before wearing out.

就是说,理论上SSD(英文中的Flash drives)应该有比机械磁盘好得多的寿命。实际上SSD的寿命确实如此。假设一个73GB的闪盘(这是EMC最早推出闪盘的容量),以较高的IO压力,比如100MB/s的吞吐量,50%是写的话,寿命计算可以达到7年。而且这个假设里,容量越大,寿命越长(写密度低了)。

  还有,现在的磁盘柜是cached array,短时间重复写IO还会被“吸收”掉,SSD上长时间平均的写IO一般都是远低于50MB/s的。所以SSD的寿命问题,用户基本可以放心地使用到磁盘柜的一整个生命周期了。企业级磁盘柜,生命周期在10年左右。


EMC现场支持专家 余建云

这里存储设备一般指磁盘阵列和光纤交换机。现在的存储设备一般都有以太网类型的管理接口,有的有缺省的内部IP地址供管理使用,从管理界面来说以GUI为主,不过CLI对有些设备还是很重要和方便的,例如交换机。由于安全原因,管理接口一般只连接在客户环境中比较安全的内部网中,甚至平时不连接,待需要的时候到设备旁边直接连接进行管理。下面谈一下在连接管理接口时相关的网络知识,供大家诊断时参考。

 

我们现在使用的TCP/IP是四层协议:Link Layer, Internet Layer, Transport Layer, Application Layer。而OSI模型是七层协议:物理层、数据链路层、网络层、传输层、表示层、会话层、应用层。关于各层的详细解释和两者之间的对照就不提了,下面谈谈诊断相关的内容。

 

首先是物理层的连接。我们目前基本都在使用百兆或千兆以太网,并且常用的是RJ45接口的铜质网线,我们的设备管理口和电脑一般都是这种接口,而该RJ45接口通常会带有两个LED指示灯,这两个灯一般是一绿一黄。一般来讲,绿灯分为亮或不亮,黄灯分为闪烁或不闪烁;绿灯长亮为百兆速率或以上的连接,不亮可能是连接问题,也可能是10M连接,不过这已经很少见了。黄灯长亮表示无数据收发,闪烁表示有数据收发。所以我们连接网线后首先要看一下是否有绿灯长亮,没有的话一般就要检查是否插好或者网线本身是否有问题。可以做个交叉测试来协助判断。

 

网络层是很重要的一层,IP地址和路由就是在这层定义的。先介绍几个基本常识。
1. 私有IP
在Internet上,IPv4的地址中有三段保留地址是不出现的,也就是常说的私有IP,它们是:10.x.x.x, 172.16.x.x~172.31.x.x和192.168.x.x。这些地址常用做公司的内部IP地址,网络设备和存储设备的管理IP地址或内部地址也经常使用这些地址,电信公司拨号上网的终端地址和宽带公司分配的终端地址一般也使用这些地址。使用私有IP的终端要访问Internet时需要进行NAT/PAT地址转换。例如Brocade交换机的缺省IP地址就是10.77.77.xx地址。
2. 网络掩码
网络掩码把IP地址分成两部分:网络地址和主机地址。除了常用的A、B、C类网络掩码外,还有无类别的掩码。同一网络/子网内的地址可以直接通讯,否则需要通过网关中转。
3. 路由
世界这么大,不可能用一个网络全覆盖,不同网络间的通讯就需要路由器来中转,一般的说法是路由分三种:静态路由、动态路由、缺省路由。静态路由是在主机端指定通往特定网段由哪个网关转发;动态路由主要用在路由器之间交换信息确定可用的最佳路径,由各种路由协议运算得到且可根据实际情况的变化适时地进行调整,这里不提;缺省路由是一种特殊的静态路由,指向0.0.0.0/0.0.0.0,顾名思义,主机没有找到匹配的路由时就会使用缺省路由。终端一般只需要设定缺省路由即可,除了本网段的地址外都通过缺省路由来通信。
4. 防火墙
为了安全,公司、企业内通常都有防火墙,可以进行IP地址、TCP/UDP端口等通信限制,还可以做地址转换,如果IP或者SSH/Telnet/HTTP等不通请先检查是否有防火墙做了阻挡,以下提到的诊断手段均为没有防火墙问题的前提下进行的。

 

我们如果跟存储设备的管理口直连,那么只需设置相同网段的IP地址即可通信,否则需要设置静态或缺省路由来指定网关。查看本机IP/掩码/缺省路由的命令是ipconfig(windows)、ifconfig(unix),查看路由的命令一般用netstat -rn。如果物理层连接正常,下一步使用的诊断命令就是ping,相信大家都用过。如果ping不通,要看是否在同一网段,在同一网段的话,就要检查交换机了;不在同一网段,可以用traceroute(unix)、tracert(windows)看卡在了哪个节点。

 

最后把传输层和应用层一起说吧,我们常用的管理方式有:Telnet、SSH、HTTP/HTTPS、FTP等,这里面SSH和HTTPS是加密传输,一般都会打开,其它非加密传输的服务可能没有打开,首先要在设备配置中确认。如果能ping通但是这些服务不通,首先需要检查的是防火墙,包括网络上的防火墙和主机上的防火墙软件。为排除客户端软件的问题,可以使用telnet ip port来测试这些端口是否可通,当然这只能测试TCP类的服务。
例如用telnet ftp.emc.com 22来测试SSH服务是否打开,如果能连通的话会进入交互模式,甚至会出现提示文字;如果出现“Could not open connection to the host, on port xx”字样,就说明无法与该端口建立连接。Telnet服务使用的端口是23,telnet命令缺省连接此端口,可不加port参数,测试其它端口就需要加port参数了,SSH为22,HTTP为80,HTTPS为443,FTP用21测试,以此类推。
这里还需要注意一点,如果设备有缺省IP,把多个相同的缺省IP连接到同一网络,不注意会登录到错误的设备上,还会出现连接异常中断的现象。在安装或初始配置IP的时候一定要注意缺省IP的问题。


Author: Zhao, Zikai

一. Data domain空间使用率简介:

        在实际使用中,用户常常遇到data domain空间规划和空间使用率等问题。例如,在data domain的命令行中,可以查看到data domain空间的使用信息:

#filesys show space

pic01.jpg

/data: Pre-comp: 消重前的原始数据量

/data: Post-comp: size-全部可用空间;  used-已经使用的空间;avail-剩余可用空间;cleanable-可回收空间

/ddvar:  data domain系统自用空间(微码、日志等非用户数据)

        Data domain最佳实践建议:

A.空间使用率小于80% (空间使用率超过80%90%有告警)

B 空间清理频率每周1次(默认设置)

        Data domain空间使用达到100%时,data domain 将变为只读状态,用户的备份作业将中止,甚至出现运行data domain空间清理无效等极端情况。

        因此,在日常使用中,应关注data domain空间使用率的情况,避免上述极端情况的发生。

二.如何在规划虚拟磁带数量时避免data domain空间风险:

        在实际使用中,经常遇到data domain用户反映创建的磁带还没全部写满,但是data domain空间已经满了的情况。出现这种情况的原因,多数都是由于前期空间规划过于宽松,预估的消重比过高,而后期又没有按照实际消重比进行调整造成的。

        例如:data domain可用容量为10TB,全部用于虚拟带库备份。按照最佳实践中80%空间使用率来规划,则可用为8TB。如果客户使用LTO-3400GB的磁带,按照预估的10倍消重比,那么可以配置200盘磁带:

10TB × 80% × 10 ÷400GB = 200

但是,如果使用一段时间后,发现实际消重比只有5,那么当磁带平均空间使用到62.5%或者写满125盘磁带时,data domain系统就已经100%满了:

10TB ×5 ÷400GB = 125 或者(10TB ×5 ÷(400GB × 200= 62.5%

这样就容易造成备份意外中止。(实际上data domain空间使用超过80%90%都有告警,及时发现告警是可以避免意外发生的。)

        因此,在创建磁带时,建议先根据预估的消重比创建部分磁带而非全部。等备份运行一段时间后,再根据data domain实际消重比来调整规划的磁带数量。另外,要按照data domain可用空间的80%来规划磁带数量而非100%;此外,还要考虑data domain上其他NAS备份的空间消耗等因素的影响。

2014VMAX3的技术峰会上,关于多个SRPStorage Resource Pool)设置要求,有个表格可以参考。多个SRP的原因主要是出于风险考虑和分析。

大家知道,一个存储池里的磁盘数目越多,那么如果出现双误(2个磁盘在很接近的时间内损坏)后,数据丢失的扩散程度越大。对于RAID6则是“3误”才有数据丢失。而存储池里磁盘数目少呢,则有可能出现性能瓶颈问题。

EMC根据磁盘的类型和保护方式,还有故障率,用工具 Availability Tool”计算后,推荐了以下的表格的磁盘数目,作为单个SRP使用磁盘数目的推荐值上限。在磁盘数目超过下表的数目时,推荐使用多SRP MSRP)。

Size

Speed

7R5

3R5

R1

14R6

6R6

w SRDF

200

EFD

368

928

2960

**

**

+

400

EFD

184

476

1576

**

**

+

800

EFD

96

244

838

**

**

+

300

15K

208

604

2134

4800

4800

+

300

10K

128

396

1436

4800

4800

+

600

10K

64

208

778

4800

4800

+

1200 *

10K

32

104

389

>3232

4800

+

2000

  1. 7.2K

8

24

144

3232

4800

+

4000 *

  1. 7.2K

No

8

72

1616

4800

+

 

举个例子,600GB 10KRPM的盘,如果做成镜像,单个SRP可以用778块磁盘。如果做成(7+1RAID5,这个数字降到了64个(2015 Oct 30,修正:原来数值208个写错了)。因为7RAID5RAID成员多,校验恢复的时间远比镜像的要长,如果pool太大,风险就会变高。

SRDF的情况下,这个数目可以增加。也是表格最后一列。

这个数值,也可以用于VMAX12的单个disk groupthin pool的磁盘数目作参考。

 

作者:余建云

         大家都知道VMAX的Unisphere推出有一段时间了,其中有蛮多很好的功能,特别是客户可以直接对VMAX硬件系统及系统资源实施监控/变更/维护/管理。

         由于篇幅所限,常规的功能介绍就尽量简略了,着重介绍些功能上的亮点:

 

在系统监控管理方面:

1) 支持系统日志的监控和回溯:支持对告警级别实施客户化的自定义,可以对日志的关键词进行自定义,相关日志信息可以通过EMAIL方式自动发送给客户。请注意:目前最多可以回溯最近的512条日志记录

2) 系统运行状态的监控:支持对系统硬件运行状态的实时监控

3) 系统运行状态的管理:客户可以对关心的系统运行状态的监控实施自定义(比如资源池的使用率达到客户预设的比例了,系统可以自动告警,并依据客户事先定义的级别区分事件的严重程度)相关日志信息可以通过EMAIL方式自动发送给客户。

 

在系统硬件管理方面:

1) 客户可以直接通过Unisphere界面来实施健康检查,该健康检查的范围除了对数据卷、控制卡、微码版本等常规的检查外,还包括Vault State Test、Spare Drive Test、Memory Test、Locks Test、Emulations Test、RDF Test、Environmental Test、Battery Test等等。

2) 支持CRU,即客户可以直接通过Unisphere界面来实施硬盘的更换。

3) 还有一个对客户来说很强大的功能,支持对控制卡端口的管理和控制,客户可以通过Unisphere界面来关闭或是开启控制器端口!

4) 支持控制卡端口特性的变更,即SET PORT BIT Setting,该操作过去通常是通过BIN Change的方式来实施的。

5) 支持控制卡端口属性的变更,从前端口变更成RDF端口,或是从RDF端口变更成前端口(FAó RF, RFó FA)。

6) 另外还有一个非常重要的新功能,支持RDF端口资源池的管理,即对RDF端口上同步、异步IO以及写IO所占的CPU资源可以实施客户化的设置CPU I/O resource distribution.

 

在系统配置管理方面:

1) 配置磁盘的资源池 (Storage groups, FAST, Volume configuration, Reserving volumes, provisioning等等)

2) 配置数据卷的资源池,即在多个数据卷间,配置优先级别Assigning Symmetrix priority

3) 配置复制操作的资源池,即在多个复制操作中,配置其优先级别Setting replication QoS(Quality of Service)

4) 存储系统外部联接的主机系统资源池的配置管理(Initiator Groups, Port Groups, CU images等等)

 

         可以说对客户而言,客户可以通过简单明了的界面对系统运行状态有直接明确的认识,可以通过简单的界面操作对系统实施配置及维护管理,VMAX高端存储在高可用的基础上,其易用性和可维护性也大大增强了。

“Write hit” and “write miss”在存储系统里是常用的性能数据。这里讲的是Symmetrix

 

Symmetrix,这两个参数跟普通字面的意义有很大的差别,导致普遍被误解了。

 

普通字面的理解,“write hit=“写入数据命中缓存”,就意味着有足够的缓存给新写过来的数据使用。“write miss=“写入数据没有命中缓存”,就意味着缓存不够了,需要缓存做清理后才能腾出新的空间给这个写IO使用。

 

然而在Symmetrix里,不能这么简单的去理解。

 

Symmetrix里的write hit,其实有另外一个名字叫“Write Pending Write”。表示写数据需要使用的缓存空间(以磁道大小64KB为单位),之前就已经分配了,而且原来的数据就是还没有写入磁盘的数据(俗称“脏数据”)。这个时候新的写数据过来,可以直接覆盖它老数据占用的缓存空间。这个最快速的写操作,只需要把数据从前端传输到缓存即可。

 

Symmetrixcached array(缓存阵列),所有数据都必须通过缓存,所以“写到缓存是100%的”没错,但“写到缓存”不是“写命中缓存”。“命中(hit)”有它特殊的定义,“write hit”是不会100%的。

 

Write hit之外的,都是write miss了。Write miss也有另外一个名字,叫“LRU Write”。Write Miss需要前端处理器为这个新的写数据取得新的缓存空间,然后才能写入数据。

 

可以想象,Write Miss值比Write Hit多了一个缓存的分配过程。这个分配过程是非常快的。所以Write MissWrite Hit其实差异很小。

有一个极端情况,会使Write Miss非常慢。这就是写入的数据达到系统缓存的写上限(总可用缓存的75%)时,写IO转入“先把缓存内数据写入磁盘,再接受新写入的数据”,这叫做“delayed write”(也有称delayed fast write)可以称为“延迟的写“。此时写入速度降到跟“直写磁盘”差不多了,写性能会很差。

 

所以呢,用公式来表示如下:

     Write Hit = 直接写入到这个数据空间(目标磁道)已经占用且已有数据的缓存里。

     Write Miss =“分配缓存空间”+“写入数据”。

     Delayed Write = “把占用的缓存空间已有数据写入磁盘,腾出缓存空间后分配给新的写数据”+ “写入数据”。

 

因为“分配缓存空间”操作的速度非常快,所以平时我并不非常关注“wirte hit”,“write miss”。一般只关心是否有delayed write。这个也只需查看System Write Pending75% system cache)有没有达到,或者单个逻辑卷的write pending5% system write pending)有没有被达到即可。

在某些测试场合,需要对路径的状态进行监控。比如说,做路径断掉再自动恢复的时间观察。

”powermt display every=1”可以持续观看结果,但输出没有时间戳,时间长短完全靠人工计时。这既不准确也很费时。

可以利用PowerPath的环境变量PP_DISPLAY_TIME_STAMP,来增加显示结果的时间戳。有两种方法。具体方法如下,以AIX为例。

方法一,用PP_DISPLAY_TIME_STAMP=TIME_VERBOSE,可以显示具体的时间,

# PP_DISPLAY_TIME_STAMP=TIME_VERBOSE

# export PP_DISPLAY_TIME_STAMP

# powermt display every=1

pp_test.png

方法二,用PP_DISPLAY_TIME_STAMP=TIME_SECONDS,可以显示时间增量,如下图,

#  PP_DISPLAY_TIME_STAMP=TIME_SECONDS

# export PP_DISPLAY_TIME_STAMP

# powermt display every=1

pp_test2.png

这两种方法,都可以快速准确的记录路径变化的准确时长,方便测试分析。本人更推荐第一种方法。

        EMC Data Domain系统,是具有目标端重复数据消重功能的存储备份产品。EMC Data Domain 虚拟磁带库(VTL)软件通过光纤通道接口模拟多个磁带库,为开放系统和IBM i环境提供重复数据消除存储,为默认的NAS接口提供了补充。Data Domain VTL软件可模拟多个磁带库和磁带机,避免了与磁带相关的故障,得到了广泛的应用。本文就DDOS 5.4中的磁带类型及兼容性等进行简单介绍。

一.Data Domain VTL DDOS 5.4中支持的磁带类型与创建

        目前,Data Domain VTL DDOS 5.4中,支持的虚拟磁带类型有以下几种。请参见表一。

        表一:

Tape Code

Default Capacity

Tape Type

L1

100GiB

LTO-1

L2

200GiB

LTO-2

L3

400GiB

LTO-3

L4

800GiB

LTO-4

LA

50GiB

LTO-1

LB

30GiB

LTO-1

LC

10GiB

LTO-1

Data Domain VTL中创建磁带时,要分配一个唯一的barcode条形码给磁带。磁带的barcode条形码是8位字母与数字的组合。其中前6位为0-9,A-Z的字符,后2位为磁带类型标识,即tape code。也就是说,磁带的类型是在分配barcode条形码的时候指定的。

例如,要创建10LTO-1 L1类型的磁带,分配的首盘磁带barcode条形码为ABC100L1,那么最后一盘磁带的barcode条形码即为ABC109L1

在创建磁带时,如果不指定容量,那么将按照磁带类型的默认容量进行创建;如果指定容量,那么将按照指定的容量进行创建。创建磁带的GUI界面参见图1

1

p01.jpg

GUI界面中可以看到所创建的磁带,如图2所示:

2

   p02.jpg
如果使用命令行操作,则可以使用命令:

#vtl tape add <barcode> [capacity <capacity>] [count <count>] [pool <pool>]

实际执行情况如图3所示:

3

    p03.jpg

二.Data Domain VTL DDOS 5.4中磁带与磁带机的兼容性

         Data Domain VTL DDOS 5.4中支持的磁带机类型有IBM LTO-1IBM LTO-2IBM LTO-3 IBM LTO-4HP LTO-3 HP LTO-4等。不同类型的磁带与磁带机兼容性如表二所示:

表二:

Tape format

Tape Drive

 

LTO-4

LTO-3

LTO-2

LTO-1

LTO-4

RW

LTO-3

RW

RW

LTO-2

R

RW

RW

LTO-1

R

RW

RW

RW可读可写;R—只读;— —不兼容

        在创建磁带时,应参考磁带与Data Domain VTL磁带机的兼容性,避免出现兼容性问题。

        通过以上介绍,可以看到Data Domain提供了非常方便的GUI菜单和CLI 命令,来创建不同类型和容量的磁带设备。通过创建不同类型的磁带和磁带机,也满足了客户对兼容性的需求。

随着虚拟机的部署越来越多,客户的应用部署也越来越灵活,便捷的操作和使用带来的好处是不言而寓的,但有时也伴随着一些困扰,那就是当某台虚机出现问题的时候,快速的查找问题会带来些麻烦。

 

前些日子就遇到这么一个案例。

 

客户在下午4点左右,突然发现几十台虚机都出现了严重的性能下降,检查了相关的交换机和存储,并未发现硬件故障,而几十台虚机又是部署在不同的物理服务器上,一时间无法定位故障原因。

 

在赶到现场和用户快速交换了意见,出现虚机性能问题的物理服务器 共连接了两台brocade DCX 交换机和两台VNX存储,为了快速的定位问题,决定从存储->交换机->物理服务器->虚机 这种有简到繁的循序排查问题。

 

快速检查了两台存储,无硬件故障,也没有4点左右的相关日志,排除存储故障可能。

 

但检查两台交换机时发现一台交换机端口在15:55 开始持续link reset , 日志如下:

15:55:05.786101 SCN LR_PORT (0);g=0x0                       D2,P0  D2,P0  221   NA   

15:55:08.985736 SCN LR_PORT (0);g=0x0                       D2,P0  D2,P0  221   NA   

15:55:12.180839 SCN LR_PORT (0);g=0x0                       D2,P0  D2,P0  221   NA   

15:55:15.380806 SCN LR_PORT (0);g=0x0                       D2,P0  D2,P0  221   NA   

15:55:18.580879 SCN LR_PORT (0);g=0x0                       D2,P0  D2,P0  221   NA   

15:55:21.786292 SCN LR_PORT (0);g=0x0                       D2,P0  D2,P0  221   NA   

15:55:24.985815 SCN LR_PORT (0);g=0x0                       D2,P0  D2,P0  221   NA 

…….

port 221连接的是个什么设备呢?

得到用户确认,它是ESXi 服务器中的一块HBA ,经过对zone的检查,发现它和VNXcVNXd都有spa&spb zone的连接,对VNXc zone,设置如下:

zone:  DELL_R910E9_PCI1_VNXc                      

         10:00:00:90:fa:12:01:01

         50:06:01:61:46:e0:7a:eb           <-port:1     spa

         50:06:01:69:46:e0:7a:eb           <-port:129  spa

         50:06:01:67:46:e0:7a:eb           <-port:17    spa

         50:06:01:6f:46:e0:7a:eb           <-port:145   spb

         50:06:01:66:46:e0:7a:eb           <-port:97    spb

         50:06:01:6e:46:e0:7a:eb           <-port:225   spb

 

对于VNXd zone 如下:

zone: DELL_R910E9_PCI1_VNXd                      

         10:00:00:90:fa:12:01:01

         50:06:01:61:46:e0:7b:5e           <-port:2       spa

         50:06:01:69:46:e0:7b:5e           <-port:130    spa

         50:06:01:67:46:e0:7b:5e           <-port:18      spa

         50:06:01:6f:46:e0:7b:5e           <-port:146     spb

         50:06:01:66:46:e0:7b:5e           <-port:98      spb

         50:06:01:6e:46:e0:7b:5e           <-port:226     spb

 

对这个port 221 进行检查如下:

          frames      enc    crc    crc    too    too    bad    enc   disc   link   loss   loss   frjt   fbsy

       tx     rx      in    err    g_eof  shrt   long   eof     out   c3    fail    sync   sig

     =========================================================================================================

221:  555.8m   3.3g   0      2      2      0      0      0    146.8k  31.3k   2      2      3      0      0

 

可以看到 enc_out=146.8k  (累积值)

              Disc_c3=31.3k (累积值)

 

Disc_c3意味着曾经有过大量的丢帧。

 

portstatsshow 221 也反映出有问题。

tim_txcrd_z                                        705147375   Time TX Credit Zero (2.5Us ticks)

tim_txcrd_z_vc  0- 3:  0           0           0           705147375

tim_txcrd_z_vc  4- 7:  0           0           0           0        

tim_txcrd_z_vc  8-11:  0           0           0           0        

tim_txcrd_z_vc 12-15:  0           0           0           0        

er_enc_in                                               0           Encoding errors inside of frames

er_crc                                                          2           Frames with CRC errors

er_trunc                                                  0           Frames shorter than minimum

er_toolong                                               0           Frames longer than maximum

er_bad_eof                                              0           Frames with bad end-of-frame

er_enc_out                                          146801      Encoding error outside of frames

er_bad_os                                                    1753318851  Invalid ordered set

er_rx_c3_timeout                        0           Class 3 receive frames discarded due to timeout

er_tx_c3_timeout                      31335       Class 3 transmit frames discarded due to timeout

er_c3_dest_unreach                0           Class 3 frames discarded due to destination unreachable

 

和其它port相比,port 221tim_txcrd_z的值要高出很多,而tim_txcrd_z这个计数器为在固定的间隔内当发送的BB credit 为空时就会计数器加1 当这个值很高时,很有可能发生了堵塞。

而同时,我们也看到er_bad_os 的值也是非常高,而该值很高,通常意味着通讯协议有问题,或者HBA卡异常,当然,伴随着er_enc_out 大量的话,也有可能是接触不良或物理传输介质故障率高。

 

那当一个port 口连接的设备出现持续的性能问题时是否会让整个fabric的性能都受到影响呢? 答案是肯定的,原因如下。

 

我们看看连接 VNXc spa&spb 连接交换机DCXaport的状态。

 

portstatsshow 1

stat_wtx                                                  3592663296  4-byte words transmitted

stat_wrx                                                    2724642389  4-byte words received

stat_ftx                                                        690181059   Frames transmitted

stat_frx                                                          3815603788  Frames received

stat_c2_frx                                                   0           Class 2 frames received

stat_c3_frx                                               3815603788  Class 3 frames received

stat_lc_rx                                                  0           Link control frames received

stat_mc_rx                                                  0           Multicast frames received

stat_mc_to                                                       0           Multicast timeouts

stat_mc_tx                                                0           Multicast frames transmitted

tim_rdy_pri                                                 0           Time R_RDY high priority

tim_txcrd_z                                        1117455850  Time TX Credit Zero (2.5Us ticks)

tim_txcrd_z_vc  0- 3:  0           0           0           1117455850

tim_txcrd_z_vc  4- 7:  0           0           0           0        

tim_txcrd_z_vc  8-11:  0           0           0           0        

tim_txcrd_z_vc 12-15:  0           0           0           0        

 

这些连接VNXc spa&spb6port tim_txcrd_z 都比其它端口高出许多,有理由怀疑在port 221 长时间的link reset过程中, 这些端口的BB credit也耗尽,同样遇到了长时间的堵塞,造成了fabric中其它设备访问存储性能严重下降。

 

连接VNXd 的交换机端口也几乎是同样的现象。

 

在此基础上,客户快速的隔离了port 221连接的HBA , 其它虚机应用逐步恢复了正常。

在EMC存储连接IBM Mainframe客户的设备环境中,经常会遇到使用EMC VMAX或者DMX存储,同时使用IBM软件flashcopy来实现device本地复制, 或者文件备份的功能。在实施使用过程中,经常会遇到Flashcopy与EMC 存储的兼容性问题。这里总结几个需要注意的问题供参考。

首先,EMC软件TimeFinder Clone与IBM软件Flashcopy功能类似,在DMX存储上运行的Enginuity code 5773 上,Flashcopy和TimeFinder Clone 不能共存。在VMAX存储上两者可以共存。

目前解决的办法只有升级为VMAX。

其次,在DMX上运行多个Flashcopy作业时,可能会出现错误信息

ADR987I   UNABLE TO PERFORM FAST REPLICATION FOR DATA SET SGE.MV.X01.DS024 ON VOLUME SGE012 DIAGNOSTIC INFORMATION: 00001E19-08040FAF

这个是由于copy/move的文件数量越多,在存储DMX上需要创建的Flashcopy session数量越多,当存储处理不了这么多sessions的时候就不能保证每个dataset都能够用到Fast Replication, 这时ADR987I message就出现了。出现这个message不会造成flashcopy作业的中断,只是会作业耗时会延长。

解决的方法是减少单个作业里的copy datasets数量来减少ADR987I出现的频率,或者是升级存储到VMAX,在VMAX环境里由于VMAX本身处理能力较DMX强,单个FLASHCOPY SESSION时间短,出现这个错误信息的概率要低很多。

再有,Flashcopy的target device不可以和source device同时在一个SRDF group。当R1端有Flashcopy作业运行时,source和target devices之间生成Flashcopy session,  SRDF的link状态由R/W变为SyncInProg,意味着R2devices发现有些devices(Flashcopy的Target devices) 对R1端有Invalid tracks,  这时R2的数据不是consistent的。

解决方法是将Flashcopy的target devices从R1中分离出来,单独建立一个group。

        VPLEXEMC近年主推的虚拟化产品之一。在实际应用中,时常有客户抱怨,实施VPLEX后没有硬件故障情况下性能下降严重。遇到这种问题,往往需要我们详细询问客户并收集很多信息来分析。

     要收集并检查的信息名目种类繁多:后端 VNX性能数据、后端Symmetrix STP性能数据、后端SAN交换机日志、前端SAN 交换机日志、主机日志及性能参数(IO响应时间,IOsize大小、文件系统类型、数据类型及读写比例、主机CPU内存利用率是否偏高、主机多路径软件设置是否符合VPLEX要求、metro环境用户两地间链路情况……

        看到如此多的问题,想必各位看着都头大一圈,其实大多数情况下性能问题没有那么复杂,这里我们介绍vplex中性能问题的简单检查处理步骤及VPLEX简单性能监控功能。

首先运行普通检查程序VplexPlatformHealthCheck确保vplex没有故障,运行后检查Vplex各部件是否正常。

举例输出如下

service@ManagementServer:~> VPlexPlatformHealthCheck

System Information

------------------

     single engine(small config)system detected

 

Management Server IP Connectivity Check

---------------------------------------

Port Plugged : OK

IP interfaces : OK

IP Connectivity to Directors Check : OK

 

Local-com FC Connectivity Check

-------------------------------

Director to Director Connectivity Check : OK

 

Management Server System Check

------------------------------

Process Check : OK

Check Partitions : OK

CPU Check : OK

BMC Check : OK

 

Director (engine-1-1 director 1A 128.221.252.35) Health Check

-------------------------------------------------------------

    Process Check: OK

    CPU Check: OK

    SSD Check: OK

    Partition Check: OK

    RPM Check: OK

    flashDir Check: OK

    WWN Seed Check: OK

    Health Check: OK

    Hardware Module Check: OK

 

Director (engine-1-1 director 1B 128.221.252.36) Health Check

-------------------------------------------------------------

    Process Check: OK

    CPU Check: OK

    SSD Check: OK

    Partition Check: OK

    RPM Check: OK

    flashDir Check: OK

    WWN Seed Check: OK

    Health Check: OK

    Hardware Module Check: OK

 

第二步在vplex无故障情况下,查看Vplex提供的GUI界面monitor页,此页面可以查看CPU利用率


CPU.png

FE 前端口延迟时间

MWSnap005 2014-09-17, 16_56_42.jpg

前端口IO流量

MWSnap003 2014-09-17, 16_56_23.jpg

BE后端口延迟时间

MWSnap006 2014-09-17, 16_56_48.jpg

BE后端口IO流量

MWSnap004 2014-09-17, 16_56_36.jpg


前后端口IO延迟是否一致,前端口延迟过长还是后端口延迟过长,快速定位问题

dvbi.jpg


检查所有前端口延迟是否一致,是否有个别链路超时。检查所有后端口延迟是否一致,是否有个别端口超时。如果是Metro架构,需要观察WAN端口流量和WAN端口延迟时间是否超时


MWSnap008 2014-09-17, 16_57_35.jpgMWSnap009 2014-09-17, 16_57_49.jpg

   笔者曾遇到某医院案例,客户反映客户端处理每笔业务需要3分钟,正常情况应该在3秒内完成,检查前后端,前端口正常,后端口中有一个端口严重超时并丢包率很高,检查交换机log。对应端口显示同样是CRC错误和C3discards高,建议客户更换高质量OM3光纤线,更换后故障立即消失。通过运用同样方法解决了两家银行客户的同样问题,综合近期案例,vplex遇到问题最简单直接的方法就是利用vplex提供的monitor页面,观察和监控各个端口的流量及响应时间,快速判断定位类似“性能”故障。

        EMC Data Domain系统,是具有目标端重复数据消重功能的存储备份产品。在备份和归档过程中,由于备份数据在写入磁盘时已经消重了重复数据,因此只需要原始数据集若干分之一的磁盘空间,实现了经济高效的解决方案。

 

1. 介绍DD数据消重原理SISL

     要了解Data Domain的重复数据消重功能,就要了解Data DomainSISL架构,即Stream-Informed Segment Layout scaling architecture

     SISL工作流程分为5步,如图所示:pic01.png

1步:数据切片(segment),数据流在Data Domain RAM中会被切分成412KB的数据段;

2步:创建指纹(fingerprint),为数据切片创建指纹;

3步:指纹比对(filter),将数据切片对应的指纹与cache中的指纹ID进行比对。如果ID是新的,那么将进行下一步。如果ID是重复的,那么将舍弃这个数据切片;

4步:压缩数据(compression),经过比对的新的数据切片将被压缩成lzgzgzfast等格式;

5步:写入数据(write),将包含指纹、元数据等信息的数据切片写入虚拟容器,待虚拟容器写满后再写入磁盘。

 

2. 介绍global compressionlocal compression的含义

     data domain文件系统属性中,global compression对应于SISL的第123步的数据消重,即对重复数据切片的消重。如图所示:

pic02.png

 

     local compression对应于SISL的第45步的数据消重,即对数据切片、指纹、元数据进行数据压缩。

pic03.png

          total compression是综合了global compressionlocal compression两个效果之后的总体压缩比,也是我们最终得到的数据消重效果。

 

3. 日常监控示例

     在日常使用中,既可以通过CLI命令来查看global compressionlocal compression的数值。使用命令filesys show compression,输出结果如下图:

pic04.png

   

    从最近7天看,备份原始数据(pre-comp34260.2GiB,重复数据消重Global-Compglobal compression)的比例为2.2,消重后数据压缩Local-Complocal compression)的比例为3.2,最终写入磁盘的数据Post-Comp4899.2GiB,而总的备份数据消重压缩比为2.2x3.27.0

  从最近24小时看,备份原始数据(pre-comp4845.0GiB,重复数据消重Global-Compglobal compression)的比例为2.1,消重后数据压缩Local-Complocal compression)的比例为3.0,最终写入磁盘的数据Post-Comp784.3GiB,而总的备份数据消重压缩比为2.1x3.06.2

 

     了解以上Data Domain数据消重与压缩的属性,可以帮助用户在日常使用中更加有效的监控Data Domain空间使用情况,对调整备份策略也有一定参考意义。

 

 

 

 

 

 

对于IBM大型机,连接识别存储后(VMAX),用户往往需要对逻辑卷设定自己定义的卷标(EMC只提供默认的卷标,一般是SYMXXX标识,而且可以重复)。

IBM主机上执行相应的命令可以修改。比如:

INIT UNITADDRESS(xxxx) VOLID(yyyyyy) VTOC(0,1,60) INDEX(4,1,60) VERIFY(zzzzzz) PURGE

可是在现在连接的大型存储中,逻辑卷数目非常巨大,这个更改卷标的操作往往要耗费非常长时间(比如几千个逻辑卷,可长达一天甚至数天)。

建议在存储安装前,客户和EMC实施人员在谈设计规划时,就提供需要定义的卷标号,然后可以由EMC工程师在配置文件中直接设定,如下图(Symmwin图例),这样安装后,用户即可得到所需的卷标了。

ibm.png

注意有两个操作完成卷标更改。建议用下面一个“Set CKD Labels”,因为它专为CKD卷的规则设计,可以避免使用重复的卷。在开放系统中,重复的卷标识合法的,但CKD环境不允许。

如果VMAX新安装结束后,才要求EMC工程师来更改这些卷标,则 步骤变得很复杂。VMAX不允许在线更改卷标。虽然用删除-重新创建能完成更改,但还不如客户自己在主机上发命令去完成更改了。

Filter Blog

By date:
By tag: