Find Communities by: Category | Product

1 2 Previous Next

工程师手记

18 Posts authored by: EMC企业存储远程支持部

今天我们来聊一聊Thin Provision的概念。

 

据姿姿了解,这种技术在各个平台的存储内得到了广泛的应用。

与VMware对VMFS的thin provision类似,(他有三种设备形式: thin, zeroedthick, eagerzeroedthick)symmetrix也适用了这样的技术。

 

本文着重介绍Sym内部的thin provision

 

中文翻译过来叫受供给。

1.jpg2.png
不对。

瘦供给。

怎么理解呢?

 

把它理解成完全虚拟的东西,它呈现给你的只是表面,真正的用于存储数据的还是在thin device后面的data device。

来看下面的图:

640.jpg

 

左半部份的Thin device就是直接呈现给客户主机的设备。主机可以看到并且访问的就是thin device。

创建方法如下(通过Solutions Enabler):

create dev count=n, size=n, emulation=xxx, config=

通过这样的命令可以创建任意大小的和数目的thin device。是不是很开心?

 

继续往右看:

看到有多个Data device。

这个就不是thin那么假的东西了,而是实实在在存数据的设备。这个device是不能被客户主机看得到的。

 

有两个Pool-池子。池子就是用来存放多个Data device的东西。一般来说一个池子内的盘的类型最好一致,这是为了更好的性能。相信大家知道symmetrix内有一个FAST的功能,将热数据移动到性能强劲的EFD盘,冷数据移动到性能一般的SATA盘,中间层留给FC的盘,这样自动的调度数据以保证存储的良好性能。那么在FAST这个特性里面就是通过把同类型的盘放到一个池子里,进行了数据迁移。

 

好像扯到FAST上去了,回来。。

 

就像上面的图片那样,thin device通过一种bind的操作,绑定到后面的一个特定池子。接下来主机发来一个写数据的命令下来,数据会找到与thin device绑定到的池子,然后并行的写到整个池子的data device内。

 

既然提到了bind,顺便也介绍一下Solutions Enabler的命令。

bind tdev symdevname in DG dgName to pool PoolName;

 

在做thin device与pool的绑定操作时,可以做一种叫preallocate的操作。也就是预先分配。正常来讲,只有当数据写下来时才会给thindevice分配实际的数据空间。预分配的设定下,系统会先分配一定的空间给到thin,数据写下来时直接使用预分配的空间。

 

 

ok数据该写的写下来了,空间该用的也用完了,满了咋整?

 

2.png
别怕~再加device到pool里呀

我们假设现在有一个32device的大池子。但是即将达到近95%-100%的状态,这时候可以再加一定数量的设备到池子里面。

3.jpg

 


如上图。

 

姿姿建议再做一个rebalance的操作:将部分数据从已经使用的设备迁移到新加入的设备。因为在数据写入池子里时,它会把数据平均下来写给每一个设备。加入之前的设备已经被数据撑满,那么新数据写入池子里时它们只能写到新的设备,这样明显出现了性能问题。

 

4.jpg


还可以通过一种操作实现这个功能:Drain

通过Drain操作可以排空一个Datadevice内的所有数据,并将数据移到其他的data device里面,以达到0%使用率的data device的目的。

操作过程如下:

1, 首先deactive老的32个device,这种操作之后不会有新数据写入这些设备。

5.jpg

2, 对这些32个设备执行drain操作,(每次只能执行五个,需要分批执行)

在此过程需要实时的计算最佳的使用率,这些data device的使用率达到预期的瞬间,终止drain的操作。(由于新数据一直写到了新加入的16块盘,整个pool内的设备使用率会达到相对的均匀分配)

 


今天就讲这么多。


 

作者信息:

 

Kevin Li(李启明)

3年Symmetrix技术支持经验

熟悉SRDF架构以及相关解决方案

什么是SCSI Reservation?

总的来说,SCSI reservation是一个锁,主机在访问Symmetrix的device之前会先在device上加上锁,通常适用于多主机的集群环境中(多台集群主机可以同时看到某一个device)。 SCSI Reservation可以防止多台主机在同一时间访问同一个device。


SCSI Reservation的种类:

  • Exclusive Reservation SCSI-2 (Windows 2000 server之前)
  • Group Reservation SCSI-2 (周记使用EMC PowerPath)
  • Persistent Group Reservation SCSI-3 (供比较新的主机使用)
  • Hardware-Assisted locking (采用Sector级别的锁)

1. SCSI-2 Exclusive Reservation

单个主机通过单独的HBA 端口以及单独的路径将device锁住,所有来自于其他主机以及同一台主机的其他HBA端口都不能访问这个device。因此,这种类型的锁阻止了同一台主机通过多路径访问同一个device。

当锁住device的主机关机或重启之后,此种类型的SCSI Reservation 锁就会被释放。主机如果检测到一个device的访问有问题,会采用BUS RESETS 来解决问题。

SCSI-2释放锁的方式有以下几种

     1)    另一个主机发起方发出了新的reserve的命令

     2)    主机发起方发起了release的命令

     3)    主机重启

     4)    Device接收到了BUS Device Reset的命令

     5)    主机断电

2. EMC PowerPath Group Reservation

此种类型的reservation通过EMC PowerPath软件来reserve/ release 主机到device的多条访问路径。主机可以使用Active/Active的IO load balancing。这种类型的group reservation比SCSI-3 Persistent Group Reservation少见。

Capture2.JPG.jpg

同一台主机的不同HBA拥有相同的GID。GID 和时间有关。

3. SCSI-3 Persistent Group Reservation (PGR)

每一个主机发起方都会使用一组reservation key来注册自己。任何注册主机都可以在某个时间点锁住这个device。

锁的信息是persistent的,因为锁的信息是存在Symmetrix的SFS (Symmetrix file system)中的,并且不受SCSI bus reset影响。

这意味着主机可以关机,但是锁依然存在,直到拥有锁的注册主机release锁。

通常情况下,一个主机的不同HBA拥有相同的reservation key。

Symmetrix的一个device最多可以注册340个initiator。在Symmetrix FA端口上,SCSI-3的flag必须打开,在Enginutiy 5875以上,SCSI-3的flag默认是自动打开的。

Capture3.JPG.jpg

4. Hardware-assisted locking

也叫做Atomic Test and Set (ATS)。ATS通常由VMware用于在支持VAAI的阵列上在Sector级别上进行锁定,相较LUN级别锁定的SCSI Reservation更为优异。

VMFS 同时支持SCSI reservations和ATS锁定。vSphere 6的VMFS datastore可以仅使用 ATS锁定(ATS-only),或同时使用ATS锁定和SCSI reservation (ATS+SCSI)。对于支持ATS的datastore(存储设备支持硬件加速+新格式化生成的VMFS 5),仅使用ATS锁定;对于不支持ATS的datastore(存储设备不支持硬件加速,或者VMFS 5是由VMFS 3升级而来),则会先尝试ATS锁定,失败后转为SCSI reservation。




关于作者:

Astrid Zhuang

证件照s.jpg

EMC Symmetrix高级技术支持工程师,在Symmetrix存储产品的领域已经有将近五年的经验。精通Symmetrix存储的硬件架构,数据结构以及本地和远程复制。对于客户数据中心发生的各类问题都能够给予及时准确的支持,多次获得客户好评。

常常听到客户反映在其环境中的Brocade交换机上很多端口显示状态异常,但是异常报错内容或是端口具体信息并未做更详尽的说明;还有的时候会听到客户反映遇到严重的性能问题,但是哪些具体的设备受到了影响却不能明确告知。

 

那么,当EMC交换机技术支持工程师遇到此类信息不完整的情况时,通常怎样做初步的故障排查呢?答案是通过porterrshow的输出结果初步了解端口报错。

 

但在此之前,还有一项非常重要的内容需要检查,那就是计数器的有效性。什么是计数器的有效性?

举个简单的例子,倘若故障发生点为20151212日,但是交换机上计数器的最后一次清空时间为20141212日,那么该计数器便是无效的,因为该值为累计值,整一年的时间,沧海桑田,今非昔比,大量的历史累积值对当前的故障排查是没有帮助的。

那么是不是说清空计数器的时间点距离故障发生时间点越近越好?非也。若是客户在20151211日清空过计数器,可是之后客户为了排查故障又执行过其它操作,如重启相关主机/重置交换机端口/更换光纤模块/光纤线等,那么该计数器也是无效的。因为此时我们看到的porterrshow输出结果中除包含故障报错增长外,还包含外界操作带来的计数器增长。

另外一种情况是在发生故障之后,计数器被清空了,若是此时的清空计数器行为是为了监测之后的故障重现,这一定是高级工程师会执行的操作,更有经验的工程师会建议先收日志再清计数器然后监测故障。若是在20151212日故障发生后清空了计数器,再之后收集了日志交给工程师调查初始故障发生原因,那工程师只能含怨问苍天了。

当计数器有效时,porterrshow的输出结果才有了意义。


通常porterrshow输出内容如下:

Capture.JPG.jpg

接下来我们解释一下各项指标代表的含义,以及我们在看到该项指标时都在关注些什么。

frames tx/rx: tx代表端口发送的数据帧,rx代表端口收到的数据帧。这两个值反映了通过该端口的数据流量,通常可用来粗略判断哪些端口为使用中,哪些端口为闲置状态。

enc_in: 8bit/10bit数据帧帧内的编码错误。数据的损坏会造成该值增长,因此该项指标用于标记数据帧内的编码错误。有时相连末端设备重置/重启也会造成该值增长。

crc_err: 数据帧 CRC 校验错误。数据帧在Payload之后,在EOF (end of frame)之前会添加一个可用于接收端口校验所接收数据是否损坏的校验码。若数据帧损坏,接收端会发现该值不一致,继而该报错值增长。

crc_g_eof: 数据帧 CRC 校验错误,且数据帧 EOF是好的。当数据帧首次被交换机检测到CRC错误时,交换机在转发该帧时,会把EOF置为bad(EOFni);所以后续接收该帧的交换机的端口上,只会有crc_err增长,而crc_g_eof的值保持不变,这样就能很直观的找到产生CRC错误的源头。

too_long: 通常FC数据帧最大为 2148 字节。若EOF损坏或数据帧生成不正确,则该值随之增长。
too_short: 如果在SOF (start of frame) EOF间的长度小于28(24 Header+ 4 CRC)个字节,则该值随之增长。数据发送方故障和链路的不稳定均可能造成该计数器的增长。
bad_eof: 数据帧 EOF 报错。

enc_out: 8bit/10bit 数据帧帧外编码错误造成的错误值累积,通常反映了线缆质量问题,或末端设备异常。此外,由于末端设备的重启带来的端口上下线也可能会引起enc_out的增长。

disc c3: Class 3数据帧被交换机丢弃。若目标地址不可达或者源端口还没有登录到交换机,以及由于拥塞产生超时丢帧(timeout discards)后,该值均会增长。这个参数仅仅代表有丢包发生,但不能说是这个端口本身存在故障。

Brocade Fabric OS微码版本v6.3.1之前,c3 timeout discards值是不分方向的,v6.3.1之后被分为er_rx_c3_timeouter_tx_c3_timeout两项,rx表示接收数据,tx表示发送数据。当端口发送或者接收帧之后,会消耗掉相应的方向上的缓存,Buffer-to-Buffer credit值减少。如果超过500毫秒(默认情况下,依配置不同可能会有改变)credit值始终为0,则认为后续分发动作无法完成,丢弃尚在缓存中的帧,计数器值增加。有大量er_tx_c3_timeout数值累积的F_Port通常为性能问题的故障点,也就是我们常说的瓶颈设备。

关于瓶颈设备的检查,请参照之前的Blog“如何在博科交换机的SAN环境中排查瓶颈设备(Slow Drain Device)?”:

https://community.emc.com/community/support/chinese/storagehw/blog

link fail: 当交换机端口在 LR (Link Reset)接收状态的时间超过 R_A_TOV值时,该错误计数器增长。Link Reset的超时通常会导致Link Failure,且该状态通常说明端口loss of signal loss of sync的时长大于R_A_TOV

loss sync: bit 或者 transmission-word无法被准确区分确认时会引起信号同步失败。末端设备的重启,光纤线的拔插,或交换机端口的上下线均可能带来该问题。
loss sig: 接收方没有成功收到信号。与loss sync类似,末端设备的重启,光纤线的拔插,或交换机端口的上下线都有可能信号的丢失。

link fail, loss sync, loss sig这三个报错在链路初始化的过程中都会产生。而当链路不稳定时,这些错误计数值通常也会随之增长。

frjt: class 2数据帧无法处理时会返回F_RJT报错。
fbsy: class 2数据帧无法在E_D_TOV时间内处理时会被丢弃并返回F_BSY报错。
frjtfbsy用于 class 2。通常说来,FC SAN多用class 3数据帧,因此这两类错误较少见,一般多出现在FICON环境中。


porterrshow的输出结果能够使我们对当前网络中的所有端口报错有一个全局性的了解,当遇到具体问题时,还需查看日志中的其它输出以定位故障点。

 

 

 

#############

# 扩展:er_bad_os #

#############

Brocade交换机中,另外一种常见的问题是不正确的填充字(fillword)配置。当该值设置有悖于最佳实践时,我们用portstatsshow命令可以在端口上观察到大量的er_bad_os

对于8G及以上速率的FC链路,为了减少电磁干扰,T11协议组织在FC-PI-4FC-FS-3 标准里规定了应用arb(ff)信号作为填充字。当末端设备以F_Port/8G速率连入Brocade 8G平台(Condor 2或GoldenEye2 ASIC)时,交换机上需对fillword模式做修改。

Brocade交换机的fillword配置方式为以下4(8G平台,Fabric OS 6.3及后续版本)

     0 | -idle-idle (默认)

          使用idle信号作为端口初始化信号,使用idle作为端口填充字

     1 | -arbff-arbff

          使用arb(ff)信号作为端口初始化信号,使用arb(ff)作为端口填充字

     2 | -idle-arbff

          使用idle信号作为端口初始化信号,使用arb(ff)作为端口填充字

     3 | -aa-then-ia

          先尝试模式1再尝试模式2

EMC的最佳实践是将fillword模式设置为3此模式下交换机首先会尝试先用arb(ff)信号作为端口初始化信号,并使用arb(ff)作为端口填充字;若此法不通,则尝试用idle信号作为端口初始化信号,并使用arb(ff)作为端口填充字。




关于作者:

Vivien Wang

Capture1.JPG.jpg

2014年加入EMC远程技术支持交换机团队。对存储区域网络有较为深入的研究和较为突出的排错能力。持有EMC SAN Specialist及VMware VCP等证书。

在存储网络环境中,性能问题是经常遇到的故障。当性能问题发生时,设备处理速度明显降低、或报I/O的告警,这都会对业务系统造成影响。

性能问题的成因可以是主机、存储,或者是交换机端口。由于某种原因,它们不能及时返回缓存信用(Buffer Credit)到上游设备,于是发生延迟、拥塞甚至(超过规定时间时)丢帧,从而引发性能问题。造成瓶颈设备的可能因素可以是物理层面(如光纤模块(SFP)、光纤线(Cable)、配线架(Patch Panel或ODF)),或是终端设备(如主机CPU、内存不足,有问题的SQL语句,存储性能不足等),也可以是由于SAN环境本身设计的问题,如实际业务量超过设备最大处理能力等。本文将介绍如何在Cisco MDS交换机的SAN网络下排查瓶颈设备。

 

一、瓶颈设备(Slow Drain Device)的成因
要理解瓶颈设备出现的原因,首先要理解交换机是如何实现流量控制的。上文中提及的缓存信用,在流量控制中起到关键作用。每个交换机端口都有若干个缓存信用,其数量在链路起来的时候由该端口和所连设备协商确定。只有当存在可用收发缓存信用时,端口才能够发送流量,同时会消耗其一个可用的缓存信用。当对端接收到这个帧,并且回复了一个确认消息,即分发成功,发送端的可用缓存信用个数才会恢复。由于缓存信用是有限的,当交换机端口没有可用的缓存信用时,不能发送新的帧而进入等待状态,便会产生延时。当然,没有分发出去的帧不会一直占用缓存信用。当占用时间达到500ms(默认配置下)而仍未分发成功时,该帧会被抛弃,链路重置并释放出缓存信用。此时在终端设备上(如主机或存储)一般会提示有I/O报错,而在思科MDS交换机上,对应的计数器值会增长。

 

二、清零SAN中所有思科MDS交换机的计数器(Counter)是排错的第一步
由于计数器的值是累加的,所以性能故障出现后,单纯在第一时间收集日志往往并不能及时帮助判断出问题所在。如果性能故障持续,将交换机计数器(Counter)清零是排错的第一步。清零计数器的命令行(CLI)命令如下:
清除普通端口计数器
To clear interface counters:
MDS-9509# clear counters interface all
清除Port-Channel端口计数器
To clear interface counters if port-channels are configured:
MDS-9509# clear counters interface port-channel <1-256>
清除ASIC计数器
To clear ASIC counters it's required to 'attach' to all line cards:
MDS-9509# attach module 1
Attaching to module 1 ...
To exit type 'exit', to abort type '$.'
Bad terminal type: "ansi". Will assume vt100.
module-1# clear asic-cnt all
在FCIP的拓扑网络中,我们需要用如下命令与IP相关的计数器:
To clear IPS stats on a GigabitEthernet port:

MDS-9509# clear ips stats all
计数器清零后,一般我们推荐等待4-6个小时,或者在严重性能问题出现后等待半小时,再收集以下两条命令的输出:
show tech-support details
show logging onboard
如果知道出现性能问题的初始时间点,我们可以收集:
show logging onboard starttime  mm/dd/yy-HH:MM:SS
比如15年9月29日6点23分50秒:
show logging onboard starttime 09/29/15-06:23:50

 

三、确定SAN网络的拓扑图
对于多交换机网络,会有级联链路(ISL)和级联端口(E-Port)。确定SAN网络的拓扑图有助于梳理有性能问题的数据传输路径。
如下所示,show topology的输出显示了本机与相邻交换机之间的级联情况。show fcs ie的输出显示了本机所在VSAN中所有交换机信息。
Sh9222i-2# show topology
FC Topology for VSAN 1 :
--------------------------------------------------------------------------------
       Interface  Peer Domain Peer Interface     Peer IP Address(Switch Name)
--------------------------------------------------------------------------------
  port-channel100   0x01(1)  port-channel 100  10.32.167.225(Sh9222i-1)
FC Topology for VSAN 30 :
--------------------------------------------------------------------------------
       Interface  Peer Domain Peer Interface     Peer IP Address(Switch Name)
--------------------------------------------------------------------------------
  port-channel100  0x0a(10)  port-channel100  10.32.167.225(Sh9222i-1)
FC Topology for VSAN 40 :
--------------------------------------------------------------------------------
       Interface  Peer Domain Peer Interface     Peer IP Address(Switch Name)
--------------------------------------------------------------------------------
  port-channel100 0x91(145)  port-channel100  10.32.167.225(Sh9222i-1)
Sh9222i-2# show fcs ie
IE List for VSAN: 1
-------------------------------------------------------------------------------
IE-WWN                   IE     Mgmt-Id  Mgmt-Addr (Switch-name)
-------------------------------------------------------------------------------
20:01:00:05:73:ad:26:01  S(Loc) 0xfffc03 10.32.167.226 (Sh9222i-2)
20:01:00:05:73:ad:2a:01  S(Adj) 0xfffc01 10.32.167.225 (Sh9222i-1)
[Total 2 IEs in Fabric]
IE List for VSAN: 30
-------------------------------------------------------------------------------
IE-WWN                   IE     Mgmt-Id  Mgmt-Addr (Switch-name)
-------------------------------------------------------------------------------
20:1e:00:05:73:ad:26:01  S(Loc) 0xfffc14 10.32.167.226 (Sh9222i-2)
20:1e:00:05:73:ad:2a:01  S(Adj) 0xfffc0a 10.32.167.225 (Sh9222i-1)
[Total 2 IEs in Fabric]
IE List for VSAN: 40
-------------------------------------------------------------------------------
IE-WWN                   IE     Mgmt-Id  Mgmt-Addr (Switch-name)
-------------------------------------------------------------------------------
20:28:00:05:73:ad:26:01  S(Loc) 0xfffc90 10.32.167.226 (Sh9222i-2)
20:28:00:05:73:ad:2a:01  S(Adj) 0xfffc91 10.32.167.225 (Sh9222i-1)
[Total 2 IEs in Fabric]

其中Loc代表本交换机,Adj代表直接级联的交换机,Rem代表非直接级联但是在同一个VSAN中的远端交换机。

 

四、存储网络性能分析
一个典型的SAN拓扑如下:
两台交换机级联,均接有设备,中间由四根ISL捆绑成port-channel。4.jpg

 

瓶颈可能出现在如下节点:
边界交换机:

- 服务器性能问题:应用或者操作系统
- HBA问题:驱动或者硬件错误
- 速度不 匹配:存储网络中一个快设备,一个瓶颈设备
- 在虚拟环境中非正常的虚机,导致FC的帧在HBA队列里面无法发出
- 存储子系统性能问题,包括过载

级联链路:

- 缺少buffer信用,尤其是对于长距离传输的拓扑来说
- 终端设备有瓶颈设备存在
- 边界交换机的速度大于网络中间级联口的速度

首先我们需要查看端口计数器的值,检查是否出现discard或者CRC的情况;其次,查看在show logging onboard命令输出中,搜索一些端口是否timeout、credit loss、packet drop之类的错误信息。
下图是用于考量性能问题的计数器及其说明:
5.jpg

其中比较重要的是
FCP_SW_CNTR_TX_AVG_B2B_ZERO
代表端口剩余的缓存信用(Buffer Credit)数量为0的时间。当然缓存信用数量降为0是常见现象,特别是在级联端口或者被共享的存储端口上。该值增长并不等同于出现性能问题,但是如果这个数值的占时间的比例比较高,则意味着可能出现了拥塞。一般来说如果,这个数值如果小于所传输帧数的30%,则被视为是正常的。
c3_timeout
用于判断是否出现丢帧。分为rx_c3_timeout和tx_c3_timeout两种,rx表示接收数据,tx表示发送数据。当端口发送或者接受一个帧之后,消耗掉相应的方向上的缓存信用,并开始计时,如果超过500ms依然没有收到对方的回应,则认为该分发动作没有完成,丢弃该帧,计数器加1。这个数值往往意味着性能故障。

Show logging onboard输出中的计数器种类非常多 ,简单总结了下,我们主要关注如下几个:
1)所有TX发方向的lack of credit error
FCP_CNTR_QMM_CH0_LACK_OF_TRANSMIT_CREDIT 
AK_FCP_CNTR_RCM_CH0_LACK_OF_CREDIT 
2)所有timeout 或者 packet drop的信息
FCP CNTR  LAF C3 TIMEOUT FRMAES DISCARD
THB_TMM_TOLB_TIMEOUT_DROP_CNT
FCP_CNTR_LAF_TOTAL_TIMEOUT_FRAMES
3)所有buffer average to Zero的信息
FCP_SW_CNTR_TX_AVG_B2B_ZERO
在这些计数参数频繁出现时候,我们需要特别注意交换机所连的终端设备,这些设备很可能是瓶颈设备,也就是我们常说的Slow Drain Device。

通过如下命令可以查看端口剩余的buffer credit值:
Sh9222i-2# show interface fc1/7 | inc "fc|redit"
fc1/7 is trunking
    Transmit B2B Credit is 250
    Receive B2B Credit is 250
      250 receive B2B credit remaining
      250 transmit B2B credit remaining
      250 low priority transmit B2B credit remaining

示例:

6.jpg

 

交换机1端口57上有FCP_CNTR_QMM_CH0_LACK_OF_TRANSMIT_CREDIT或者c3 Tx方向的timeout,表示该端口向下游发送数据时,对方回应不及时,Transmit B2B credit降到0超过0.5秒,即而发生丢帧。
接下来让我们看看下游端口的数据。交换机2端口55有timeout相关的counter存在,说明该端口收到上游发送来的帧之后,尝试继续向交换机2上的出口端口转发时,却也因为下一条端口没有可用Credit,超过0.5秒后丢帧。
如果交换机内部没有发生拥塞,或者级联链路没有物理层故障,那么在下游交换机2上应该有一个我们所说的瓶颈设备(Slow Drain Device)。通过show interface counters可以很快的找到这个设备。比如fc1/1是设备口,以下命令输出显示buffer credit明显不够,并且有较多的output discard信息:
Sh9222i-2# show int fc1/1 counters
fc1/1
    5148945 frames output,429093396 bytes
      100 discards, 0 errors
      100 timeout discards, 14130 credit loss
      2745464 Transmit B2B credit transitions to zero
      11 Receive B2B credit transitions to zero
      32 receive B2B credit remaining
      1 transmit B2B credit remaining
      1 low priority transmit B2B credit remaining
同时我们也可以检查在logging onboard日志中是否有credit-loss、request-timeout等出现。

 

五、性能问题排查总结
找出该瓶颈设备(Slow Drain Device)的一般步骤如下:
1.通过show topology和show fcs ie绘制SAN拓扑结构
2.检查show interface中端口是否有errors或者discards的报错;
3.检查show interface transceiver details该端口光线模块收发光情况异常;
4.检查show logging log是否有端口重置link failure的现象
5.检查show logging onboard日志查看是否有credit loss或者packet drop报错比较多的终端设备
6.如上述步骤均未现异常,则说明网络侧不是造成性能问题的原因,此时应检查末端设备(主机、阵列)自身是否有问题。

 

六、其他
排查思科SAN网络中的性能问题,认清重要计数器的含义非常重要。在设备运行正常的时候,经常清零计数器是我们极力推荐的。历

史计数器值会对排错产生误导,在性能问题出现时的统计生成的计数器数据才是排查过程中最得力的工具。




关于作者:

柴佳波 Jimmy Chai

无命名.jpg

2012年加入EMC远程技术支持部光纤交换机团队。对存储区域网络有深入的研究和极强的排错能力。持有EMC SAN Expert、思科CCIE Data Center、博科BCFA/BCFP/BANAS/BATSSVmware VCP等认证。

Symmetrix内部使用的一致性组

Device group(DG)是由用户创建的,用于查看和管理相关Symmetrix设备的对象。Device group中的所有设备应位于同一Symmetrix阵列上。一般来说,device group分为五种类型:Regular,R1,R2,R21和Any。如果没有明确指定类型,将采用默认类型的Regular。对于TimeFinder/Clone,TimeFinder VP SNAP和TimeFinder/Snap操作,应该创建Regular类型的device group。

 

TimeFinder中使用一致性组Consistent Group
一般是由用户定义,其中包含多个设备或者设备组,这些设备或设备组可属于一个或多个本地连接的Symmetrix阵列以及Symmetrix阵列中的一个或多个SRDF组。

一致性组与设备组的规则相同,设备组可以跨多个本地Symmetrix阵列。创建一致性组以及对其中包含的设备执行复制操作时,只能使用SYMCLI命令行界面。

1.jpg

 

SRDF中的一致性组

SRDF一致性组是一个由SRDF设备构成的复合组,它们可以协同合作,对分布在多个Symmetrix阵列或同一阵列的多个设备维护写操作的一致性。

创建一致性组及对其中包含的设备执行复制操作时,只能通过SYMCLI命令行界面完成。

 

Symmetrix内部设备状态
一般来说,在执行业务连续性的操作时,设备会有多种状态。如:RW可读可写,WD禁止写,NR设备未就绪,等等。当复制副本设备的状态必须为读写(RW)才能被主机访问。
在TimeFinder操作里面,只有Activate一个会话时,目标设备的状态才会变为RW.

在常规SRDF操作中,远程设备R2将呈现禁止写入WD状态。如果想对R2进行读写,可执行SRDF故障切换或者SRDF split操作。

 

TimeFinder/Clone
TimeFinder/Clone 是一个Symmetrix内部的本地复制解决方案,可以给Symmetrix内的设备提供快速的时间点拷贝。源设备和目标设备可以是标准设备或者BCV。这里的TimeFinder/Clone和5773版本的TimeFinder/Mirror不同的一点是,克隆拷贝在激活克隆会话时立即可用,而实际的数据拷贝可在后台进行。

2.jpg

 

针对TimeFinder/Clone的操作

Create:

创建标准设备和克隆之间的关系。

创建之后目标设备会对主机呈现为NR状态,主机将不能访问目标设备。
在执行Create操作时,也可以加上两个参数 –precopy 和 –nocopy。
-precopy这个选项在创建会话后立即开始拷贝。数据持续的从源端拷贝至目标。不过,目标设备仅在会话激活后才允许读/写。

Activate:
使克隆立即进入活动状态以进行读/写访问。
在执行了activate命令之后,目标设备会被置于R/W状态。主机可以对其进行访问。
一般启用这个数据拷贝时,默认选项为-copy和-differential。
如果之前会话是使用-nocopy选项创建的,则数据拷贝将延迟至源端或者目标的刺刀写入数据后执行。
如果会话是使用-precopy创建的,则激活操作会将此选项转换为-copy。

Recreate:
将克隆重新连接到标准设备以进行新的时间点拷贝。

Establish:
创建/重新创建并激活。

Restore:
重新连接到标准设备并执行增量恢复或完整恢复。

Split:
可以使用symclone split命令针对处于“restored”状态的克隆设备对进行split操作。

Terminate:
删除源设备和目标设备之间的配对关系。

 

以上是TimeFinder/Clone中对设备进行的命令及操作结果。下面接下来看一下TimeFinder/Snap。

 

TimeFinder/Snap
TimeFinder/Snap可创建源卷的逻辑时间点映象,这个是非常节省空间的。这些快照并非数据的完整拷贝,而是基于快照创建时间为原始信息生成的逻辑映象。激活快照时,将立即创建一组指向源卷的track的指针。这些指针将存储在虚拟设备中。会允许目标主机访问该虚拟设备。一般,默认的快照最大数量为16个。

3.jpg

TimeFinder/Snap功能是通过拷贝会话来管理的,该会话将源设备与目标设备进行配对。会话将保留在Symmetrix阵列中,并且可进行查询以验证当前设备状态。

首先必须创建一个拷贝会话(copy session),用以定义参与拷贝操作的快照设备。随后激活该会话后,目标虚拟设备的主机便可以访问该目标的虚拟设备。

简单罗列一下TimeFinder/Snap的特点:

  • 目标设备是一个虚拟设备,其中包含指向原始元数据的track的指针
  • 目标设备可以像其他设备一样被mount
  • 仅当存在对源或目标的写入时,才执行拷贝
  • 仅将必须更改的原始数据拷贝之保存设备,因而只需要一小部分空间即可完成整个源的拷贝
  • 拷贝由拷贝会话(copy session)控制,可以使用symsnap命令执行操作

 

一些常用的Snap操作:
Create, Activate, Restore, Terminate, Recreate, Establish

 

以上是Symmetrix内部的一致性组概念以及TimeFinder的本地复制的一些基本概念。




关于作者:

李启明 Kevin Li

无命名.jpg

20137月加入EMC远程技术支持Symmetrix产品部。两年以上的Symmetrix相关硬件软件的维护经验。持有EMC Symmetrix SA/IE SpecialistSymmetrix SA Expert,Vplex IE Specialist,以及思科CCIE Routing and switching等证书。

本文将向大家介绍VMAX3系统柜的主要物理部件。VMAX3 有三个型号,100K200K400K。不论何种型号,系统均由18个(或者14个)系统柜组成。

VMAX3中,用户可以选择Single Engine BayDual Engine Bay两种配置。Single Engine Bay在一个系统柜里只有一个Engine(最多8个系统柜),Dual Engine Bay在一个系统柜里有两个Engine(最多4个系统柜)。

1.jpg

Single Engine Bay的配置下,系统柜 1中的主要部件包括:用于支持Engine的电池SPSEnginePDUKVM(鼠标、键盘、显示器),以太网交换机,DAE

需要注意的是最下方的一个SPS tray,只有在多于一个Engine的配置下才会出现。这是因为,只有在多于一个Engine的配置下,我们才会使用Infiniband交换机。

系统柜28中,不存在以下部件:Infiniband交换机,最下方的一个SPS trayKVM和以太网交换机。并且请注意,Work Tray代替了KVM

2.jpg

SPS2.2KW的容量。在系统突然断电时,可以提供25分钟的供电时间,系统可以利用这段时间将内存数据存放到Flash上,这被称为Vault

Single Engine Bay配置下,当整个系统的Engine数量大于1时,系统柜 1最多有2SPS trays(也就是4SPS)用于支持EngineInfiniband交换机。

在系统柜 28里,只有一个SPS Tray2SPS)用于支持Engine

3.jpg

Dual Engine Bay配置下,系统柜1将有3SPS trays6SPS)用于支持Engine 1Infiniband交换机。SPS 2A/2B用于支持Engine 2

对于系统柜 24,每个系统柜有2SPS trays4SPS)用于支持2Engine

4.jpg

系统的内部Fabric连接使用Infiniband交换机。Infiniband交换机只会出现在多于一个Engine的系统配置下,且只出现在系统柜1

VMAX3有两种Infiniband交换机。400K使用18个端口的交换机,100K200K使用12个端口的交换机。

18个端口的交换机采用冗余的即插即用电源和风扇,可以单独更换某个电源或风扇。12个端口的交换机也有冗余电源,由于不是FRU,因为一旦电源损坏,需要将整台交换机一起更换。

5.jpg

每个VMAX3Engine包含两个director。上面的是Even Director,下面的是Odd Director。每个Director都有冗余的电源保护。

6.jpg

PDU包含了VMAX2PDPPower Distribution Panel)和PDU的功能,为整个阵列供电。

7.jpg

VMAX3支持两种类型的DAE60-drive DAE可以容纳603.5英寸的不同容量,不同转速的磁盘。120-drive DAE可以容纳1202.5英寸的不同容量,不同转速的磁盘。

9.jpg

无论在何种配置下,系统柜 1中都有一对以太网交换机,它们连接到Engine,用于监控系统环境。

10.jpg

KVM(鼠标、键盘、显示器)位于系统柜 1中。现场工程师可以使用KVM登录Simplified Symmwin,对VMAX3进行维护。

11.jpg

系统柜28没有KVM,只有Work Tray。它包含电源线和网线。通过它,现场工程师可以将自带的笔记本电脑,连入MMCS,登录Simplified Symmwin

由于VMAX3支持Dispersed的配置,因此其他系统柜可能和系统柜 1距离较远,Work Tray的设计,是为了方便现场工程师运行系统维护以及部件更换的脚本。

 

通过今天简单的介绍,希望大家对新一代的VMAX3的硬件组成有更加清晰的了解。

新一代的VMAX存储已于14年的最后一个季度正式上市,这次给大家就这代VMAX 3做个简要介绍。

VMAX 3共分为三个型号,VMAX 100k200k400k

1.jpg

集成了HYPERMAX OS 5977 VMAX 3 包括经济型的100k,企业型的200k和最高端的400k三个型号。在存储系统需求及标准日益增长的今天,新一代VMAX 3家族可以使用全部闪盘的配置来应对低延时及高IPO的要求。

2.jpg

VMAX 3家族中每个引擎最多可以配置7202.5’的磁盘或者3603.5’的磁盘,磁盘的类型可以是混合型或者全部由闪盘组成。系统柜之间的距离可以延长至25米。Vault device将不复存在因为每个engine中都有配置flash空间来提供vault的功能。系统柜可以有单引擎和双引擎两种配置方式。原先的service processor也被最新的Management Module Control Station (MMCS)取代(MMCSSystem Bay 1中).

 

下面来分别介绍一下不同的三款型号的存储,

3.jpg

VMAX 100K 可以有单引擎或双引擎组成。在双引擎的配置中,100k最多可以支持1440 2.5’的磁盘或者7203.5’的磁盘,提供最多0.5 PBu的容量。满配的100k,可以有最多64个前端口来给客户主机使用。系统内部的通信使用的是两块Infiniband ,共12-port switches 来提供冗余和可靠性。

4.jpg

VMAX 200K 可以有单个至4个引擎组成。在4引擎的配置中,200k最多可以支持2880 2.5’的磁盘或者14403.5’的磁盘,提供最多2.1 PBu的容量。满配的200k,可以有最多128个前端口来给客户主机使用。系统内部的通信使用的是两块Infiniband ,共12-port switches 来提供冗余和可靠性。

5.jpg

VMAX 400K 可以有单个至8个引擎组成。在8引擎的配置中,400k最多可以支持5780 2.5’的磁盘或者28803.5’的磁盘,提供最多4 PBu的容量。满配的400k,可以有最多256个前端口来给客户主机使用。系统内部的通信使用的是两块Infiniband ,共12-port switches 来提供冗余和可靠性。

6.jpg

(上图整合了3个型号来做对比)

 

 

下面来简单的介绍一下系统柜的构成(单引擎及双引擎)。

7.jpg

就像名字描述的一样,每个单引擎的机柜共包含一个引擎,引擎的电池是由一对在机柜顶端的SPS所提供。单引擎的机柜最多可以装配6个DAE。引擎支持两条磁盘链路(标签为A和B的两条链路),每条链路可以有一个直连的DAE和1至2个级联的DAE。

8.jpg

双引擎机柜包含1至2个引擎,最多4个DAE。每个引擎的电池由一对SPS提供(SPS 1A/1B及SPS 3A/3B)。同样的,每个引擎由两条磁盘链路组成,每条链路可以有1个级联DAE。

值得注意的是,单引擎的机柜与双引擎的机柜无法混合搭配。

 

VMAX 3中,除了原先的symmwin,现在有了另一个链接storage体统的方式:Simplified Symmwin

9.jpg

10.jpg

Simplified Symmwin提供了一些服务脚本,例如硬件更换,微码升级,确认脚本(来验证安装及线材链接)。Simplified Symmwin是一个简单的,容易使用的图形界面,并且对常用的服务功能提供了详细的指导。

 

通过今天简单的介绍,希望大家对新一代的VMAX 3有了简单的认识。

如何在博科交换机的SAN环境中排查瓶颈设备(Slow Drain Device)?

 

SAN环境中,性能问题是经常遇到的故障。在性能问题中,设备处理速度明显降低、或者是有丢帧的告警,都会对业务造成影响。而引起此类故障的原因,往往在于某个或某些设备,即瓶颈设备(Slow Drain Device),可以是主机、存储或者是交换机的级联部分,由于某种原因,它们收到的数据量超过了自身的处理能力,以至于不能及时返回缓存信用(Buffer Credit)到上游设备,于是发生延迟、拥塞甚至(超过规定时间时)丢帧,从而引发性能问题。造成瓶颈设备的可能因素可以是物理层面,如光纤模块(SFP)、光纤线(Cable)、终端设备等,也可以是由于SAN环境本身设计的问题,如实际业务量超过设备最大处理能力等。本文将介绍如何在博科交换机的SAN网络下排查瓶颈设备。

 

一、瓶颈设备(Slow Drain Device)的成因

要理解瓶颈设备出现的原因,首先要理解交换机是如何实现流量控制的。上文中提及的缓存信用,在流量控制中起到关键作用。每个交换机端口都有若干个缓存信用,其数量在链路起来的时候由该端口和所连设备协商确定。只有当存在可用缓存信用时,端口才能够发送出一个帧,同时会消耗其一个可用的缓存信用。当对端接收到这个帧,并且回复了一个确认消息,即分发成功,发送端的可用缓存信用个数才会加一。由于缓存信用是有限的,交换机端口没有可用的缓存信用时,不能发送新的帧而进入等待状态,便可能发生延时。当然,没有分发出去的帧不会一直占用缓存信用,当占用时间达到500ms而仍未分发成功时,该帧会被抛弃,并释放出缓存信用,此时即发生丢帧。

由于缓存信用控制流量的机制,瓶颈设备的产生会导致其整条数据传输路径上发生拥塞。如果该路径上包括交换机级联线,则所有经过该级联的数据传输路径都会受到影响。因此,一个瓶颈设备可能导致整个网络中的拥塞,在性能故障中及时的排查瓶颈设备尤为重要。

在终端设备上,如主机或存储,一般会提示发现瓶颈(Bottleneck)。而在博科交换机上,可能会发现类似如下的告警。此类告警往往会持续一段时间。

2015/01/15-18:55:34, [AN-1004], 335118, SLOT 6 | FID 128, WARNING, CHD_1B_TLI_SAN1, Congestion bottleneck on port 10/32. 91.33 pct. of 300 secs. affected.

2015/01/15-19:00:37, [AN-1004], 335119, SLOT 6 | FID 128, WARNING, CHD_1B_TLI_SAN1, Congestion bottleneck on port 10/32. 88.67 pct. of 300 secs. affected.

2015/01/15-19:05:40, [AN-1004], 335120, SLOT 6 | FID 128, WARNING, CHD_1B_TLI_SAN1, Congestion bottleneck on port 10/32. 83.33 pct. of 300 secs. affected.

 

二、清零SAN中所有博科交换机的计数器(Counter

对于性能故障,及时将交换机计数器(Counter)清零是排错的第一步。在问题出现之前,定时做这项任务是一个良好的习惯。清零计数器的命令行(CLI)命令如下:

#>statsclear

#>slotstatsclear

如果问题出现之前清零过计数器,则在问题发生时收集该SAN环境中所有博科交换机的日志supportshowsupportsave用于分析。

如果问题出现之前没有清零过计数器,建议先收集该SAN环境中所有交换机的日志supportshowsupportsave,然后马上清零所有交换机上的计数器,以便其记录接下来的性能问题的蛛丝马迹(这些将在若干小时后第二次收集的日志中用于分析)。第一次收集的日志中可以做简单的分析:porterrshow的输出会罗列出所有端口是否有报错,虽然这些报错都是历史性的,不能用于判断本次性能故障,但是可以对某些报错比较突出的端口进一步查看;sfpshow的输出可以用于查看端口收发光情况是否正常。这些分析方法在后面会详细叙述。

 

三、确定SAN网络的拓扑图

对于单交换机网络,即SAN中只有一台博科交换机,其端口所链接的设备为存储或主机;对于多交换机网络,则会有级联线(ISL)和级联端口(E-Port)。确定SAN网络的拓扑图有助于理清有性能问题的数据传输路径。

如下例所示,islshow的输出显示了本地的博科交换机与对端交换机之间的级联情况。序号1,本地交换机的57口与对端交换机CHD_1C_TLI_SAN155口级联,序号2,本地交换机的129口与对端交换机CHD_1D_NGN_SAN1135口级联。

islshow        :

  1: 57-> 55 10:00:00:05:1e:d2:c4:00   7 CHD_1C_TLI_SAN1 sp:  8.000G bw:  8.000G TRUNK QOS

  2:129->135 10:00:00:05:33:83:e3:00   5 CHD_1D_NGN_SAN1 sp:  8.000G bw:  8.000G TRUNK QOS

<truncated>

以下排错过程将以双交换机网络为例,单交换机网络可看作是多交换机网络的特例。

 

四、分析有效的端口报错信息

如下图所示,两台博科交换机组成的SAN网络,均接有设备。

11.jpg

我们将清过计数器之后收集的日志中的信息称之为有效信息,以下均以有效信息为例。

如上述级联本地交换机57口连CHD_1C_TLI_SAN155口,查看本地交换机日志中的portstatsshow 57如下(仅取了我们感兴趣的部分输出):

portstatsshow 57

tim_txcrd_z 1381820     Time TX Credit Zero (2.5Us ticks)

tim_txcrd_z_vc  0- 3:  0           0           228512      231010        

tim_txcrd_z_vc  4- 7:  521007      401291      0           0        

tim_txcrd_z_vc 8-11:  0           0 0           0        

tim_txcrd_z_vc 12-15: 0           0           0           0        

er_rx_c3_timeout 0           Class 3 receive frames discarded due to timeout

er_tx_c3_timeout 23 Class 3 transmit frames discarded due to timeout

Time TX Credit Zero代表的是这个端口剩余的缓存信用(Buffer Credit)数量为0的时间。缓存信用数量为0并等同于出现性能问题,但是如果这个数值的占时间的比例比较高,则意味着可能出现了拥塞。一般来说如果,这个数值如果小于所传输帧数的30%,则被视为是正常的。

c3_timeout值用于判断是否出现丢帧。在博科FOS微码版本为6.3.1之前,这个值是不分方向的,6.3.1之后分为er_rx_c3_timeouter_tx_c3_timeout两种,rx表示接收数据,tx表示发送数据。当端口发送或者接受一个帧之后,消耗掉相应的方向上的缓存信用,并开始计时,如果超过500ms依然没有收到对方的回应,则认为该分发动作没有完成,丢弃该帧,计数器加1。这个数值往往意味着性能故障。

在这里,er_tx_c3_timeout数值非零,表示本地交换机的端口57向下游发送数据时,对方回应不及时而发生丢帧。接下来让我们看看下游端口的数据。以下均仅截取所需部分。

portstatsshow 55

tim_txcrd_z 1259255     Time TX Credit Zero (2.5Us ticks)

tim_txcrd_z_vc  0- 3:  0           0           239711      218720        

tim_txcrd_z_vc  4- 7:  403321      397503      0           0        

tim_txcrd_z_vc 8-11:  0           0 0           0        

tim_txcrd_z_vc 12-15: 0           0           0           0        

er_rx_c3_timeout 31 Class 3 receive frames discarded due to timeout

er_tx_c3_timeout 0           Class 3 transmit frames discarded due to timeout

下游端口55er_rx_c3_timeout数值非零,说明该端口收到上游发送来的帧之后,继续向交换机出口端口(即连接下游交换机或者终端设备的端口),却也因为超过500ms没有收到回应而丢帧。注意,上游的er_tx_c3_timeout数值并不一定与下游的er_rx_c3_timeout数值相等,毕竟两个计数器开始和结束的时间很难完全一致(分别取决于清零计数器的时间和收集日志的时间)。

到目前为止,已经查过了两台交换机之间的级联线,接下来要找出造成这次拥塞的设备。之前已经提过,在上游交换机的级联口看到了er_tx_c3_timeout,在下游交换机对应的级联口看到了er_rx_c3_timeout,那么相应的,在上游交换机应该有一个F-Port,即连接设备的端口,其计数器上存在着er_rx_c3_timeout报错,而在下游交换机上也应该有一个F-Port存在着er_tx_c3_timeout报错。

如何找到这些有问题的端口?我们可以先看一下两台交换机的porterrshow,毕竟porterrshow的数据是对各端口portstatsshow中数据的总结。

很快,我们找到了对应的端口为上游交换机的端口21和下游交换机的端口27,前者有22rx方向的丢帧,后者有31tx方向的丢帧。以下均仅截取所需部分。

portstatsshow 21

er_rx_c3_timeout 22 Class 3 receive frames discarded due to timeout

er_tx_c3_timeout 0           Class 3 transmit frames discarded due to timeout

 

portstatsshow 27

er_rx_c3_timeout 0           Class 3 receive frames discarded due to timeout

er_tx_c3_timeout 31 Class 3 transmit frames discarded due to timeout

以上这些报错的证据都对得上,说明原因一直在证据链的尾端,即下游交换机端口27所连接的设备,该设备即是我们要找的瓶颈设备。让我们来看一看如下这张图,请注意图中各端口上都有哪些报错。

12.jpg

是否其他端口,比如上游交换机的22口和23口、下游交换机的26口,是否就是没有报错的呢?因为上、下游交换机之间只有一个级联线,且这条级联线正好处于拥塞的传输路径上,因此通过该级联线的其他传输路径也会发生拥塞。结果如下图所示。注意,下游交换机的端口26并未受到影响,因为它应该收到的数据在上游就被堵塞了,而它分发到一号主机的数据并未发生延迟。

13.jpg

对于更多交换机组成的SAN网络,也应参照上述方法排查可能路径上端口的portstatsshow输出是否有异常。对于单交换机SAN网络,则只需查看那些F-Port有问题的端口。

 

五、排查瓶颈设备端

接下来找出该设备成为瓶颈的原因,其一般步骤如下:

  1. 检查porterrshowportstatsshow中是否有物理层的报错;
  2. 检查sfpshow该端口光线模块收发光情况异常;
  3. 检查switchshow中是否有端口状态报错;
  4. 检查fabriclog --showzhong是否有端口重置;
  5. 如上述4步均未现异常,则说明交换机一侧没有问题,应检查设备自身是否有问题。

在本例中,下游交换机端口27,即连设备端口,有一些物理层的报错,且端口收光较弱(Rx小于-7dBm),故需要检查端口与设备之间的光纤线。以下均仅截取所需部分。

portstatsshow 27

er_enc_out 34181       Encoding error outside of frames

er_bad_os 23541       Invalid ordered set

 

sfpshow 27

RX Power:    -23.0   dBm (0.5  uW) 10.0 uW 1258.9 uW   15.8   uW 1000.0 uW

TX Power: -3.2    dBm (477.3 uW)125.9  uW 631.0  uW  158.5 uW   562.3  uW

14.jpg

本例中,经过更换该光纤线,性能问题消失,说明就是因为光纤线的问题影响了性能。在其他的实例中,交换机端找不出问题,此时需要排查该设备(如HBA)是否有故障。也有一些情况下,设备也没有问题,则可能是由于该博科SAN环境设计上的缺陷,导致正常的设备也无法满足所加载业务的需求。

 

总结

在博科SAN网络中排查性能问题,最核心的一点是沿着拥塞的链路往下游寻找瓶颈设备。寻找的过程中,各个交换机端口的计数器是判断拥塞的依据,认清楚er_rx_c3_timeouter_tx_c3_timeout的区别非常重要。

在设备运行正常的时候,经常清零计数器是我们极力推荐的。因为在性能问题出现时,只有代表该问题的计数器数据才是排查过程中最得力的工具。

 

 

 

作者简介:

陈晟

2013年毕业于上海交通大学,获得硕士学位,并加入EMC远程技术支持部交换机团队。对存储区域网络有较为深入的研究和较为突出的排错能力。持有EMCSAN Specialist证书EMCIEEMCSA,博科SAN证书BCFABCFPBANASBATSSVMwareVCP证书等。

15.jpg

随着存储数据的激增,企业数据中心正在寻找各种方法来提高现有存储资源的价值,降低对其的管理成本并使其发挥在当前环境中的最大性能。但是在实施过程中要考虑到这样的问题:既要把数据放在合适的存储层级上来保证数据的可用性,还要考虑到成本的控制。

EMC Symmetrix的联合分层存储考虑到了所有的情况,即把现有的经过认证的存储阵列作为Symmetrix Vmax的物理磁盘空间,这样就公司的IT/存储部门就可以通过Symmetrix的软件和微码功能,例如SRDF, TimeFinder, Virtual Provisioning以及FAST VP来管理不同的存储阵列。


联合分层存储允许使用外部存储上的LUNSymmetrix VMAX提供物理空间。这些外部的LUN可以作为“裸”存储空间创建Symmetrix设备,这和Symmetrix内部的磁盘是同样的工作原理。这些设备被称为“eDisk”。外部LUN上的数据也可以通过Symmetrix的设备进行维护和访问。

通过FTS,外部阵列上的数据也可以使用由Symmetrix提供的功能,比如本地备份、远程备份、存储分层,数据管理以及数据迁移。


FTS的组成部分

FTS是完全通过微码本身来部署的,并不需要额外的Symmetrix硬件。FTS中,和外部存储的连接仍然采用目前用于FARF的连接方式,即光纤模块。虽然和FA(前端口,用于和交换机或主机HBA连接)以及RF(即SRDF口)采用同样的连接方式,但是FTS却使用了一种全新的“代码”。

 

DX 控制器:

这是一种全新的“代码”,亦即DX(用于外部DA),这种代码可以让传统的DA模块(和磁盘柜相连)作用于外部存储的LUN上,也就是把它们当成物理磁盘来工作。事实上,和DA访问内部LUN不同的是,通过DX访问外部LUN对于其他控制器的“代码”以及微码本身来说,是完全透明的。对于大部分非磁盘指向型的功能来说,DX的功能和DA没有任何区别。

 

eDisks:

eDisk可以理解为外部存储中的LUN在加入VMAX配置之后的“代表”。当把这个外部的LUN放到外部的disk group以及一个虚拟RAID group中时,“eDisk”和“external spindle”指代的都是同一个意思,即这个外部LUN

 

External disk group:

外部磁盘组可以理解为由包含eDisk的用户创建的虚拟磁盘组。外部磁盘组的编号从512开始。在一个磁盘组内部,外部磁盘(external spindle)和内部物理磁盘不能混合放置。

 

 

Virtual RAID group:

对于每一个新添加的eDisk,系统都会为其创建一个无保护的虚拟的Raid groupRaid group之所以是虚拟的,是因为eDisksVMAX本地没有任何保护;它们只能依靠外部存储提供的保护。

 

FTS部署示意图:

tt.jpg

FTS的优势包括以下几点

  • 通过SMASSolution Enabler以及ProSphere等软件对不同类型阵列进行管理,简化对不同虚拟化厂商或者EMC存储的管理
  • 允许数据在不同阵列之间或者不同阵列与VMAX之间进行迁移
  • 外部存储可以享用Virtual Provisioning带来的优势
  • 可以通过VMAX的企业级数据迁移技术,例如SRDFTimeFinder等,来实现外部存储上数据的拷贝和复制

       把外部存储阵列作为额外的一个层级,拓展了现有阵列的使用价值

 

联合分层存储(FTS)是Symmetrix5876微码中引入的新功能,它允许EMC支持的SAN存储阵列给Symmetrix VMAX提供额外的磁盘空间。该功能可以让用户对存放在SymmetrixSymmetrix以外(借助熟知的EMC软件和微码功能)阵列上的数据进行管理、监控、迁移以及复制。

一.什么是zone

ZoneFC-SAN交换机上的一种独有的逻辑配置,通过配置特定的设备加入zone,从而允许设备之间互相通信。当交换机上配置了zone时,同在一个zone里的设备之间可以互相通信,没有加入任何zone的设备不能与其他设备通信。

早期交换机厂商根据zone的实现方式,把zone分为hard zonesoft zone,区别在于前者通过硬件芯片来实现,后者通过软件来实现。后来大家把基于domain ID/端口号的zone叫做hard zone,基于wwnzonesoft zone。现在这两种类型的zone都是基于硬件芯片实现。

Zone的类型:

1.  基于Domain ID/端口号(D,P)的普通zone模式

这种zone允许接在某几个端口上的设备互相通信,即使端口上的设备改变也不会影响zone的使用,在更换主机HBA卡时不需要进行任何zone配置的更改。

 

2.  基于wwpn/wwnn的普通zone模式

这种zone允许拥有特定wwn的设备之间互相通信,不关心设备接在交换机的哪个口上。当某个设备从一个端口移到另一个端口时,不需要进行任何zone配置的更改。但更换主机HBA卡时,需要根据新HBA卡的wwn更改zone配置。注意如果交换机上接有NPIV模式的刀片交换机或主机集群时,必须使用基于wwnzone

 

3.  混合zone(session based hard zoning)

当一台设备在两个或多个zone里分别使用D,Pwwn模式的zone,这台设备会进入混合zone模式。在混合zone模式里的设备在跟其他设备通信时需要通过交换机CPU进行软件验证。

 

4.  LSAN zone

LSAN zone只有在启用了FCR时才会被应用到,它能允许在不同的fabric中的设备通过fc router进行通信。需要在交换机上安装integrated routing license后才能打开FCR功能。

 

5.  TI zone(Traffic Isolation zone)

TI zone可以把一根或者多根ISL设置成某个zone的专用ISL,不需要license

 

6.  QOS zone

QOS zone在网络中出现拥堵时可以允许高QOSzone成员优先通信,需要在交换机上安装adaptive networking license

 

Zonesetzone的集合。一台交换机同时只能启用一个zoneset,同一个SAN网络中交换机的active zoneset必须保持一致,不然会造成网络分裂(fabric segment)

Alias,或叫做别名,是使配置zone更简便的一个功能。对于每台设备,可以预先设置好alias,之后在配置zone时使用alias来代替D,Pwwn

Default zone:思科与博科交换机都有default zone,它的功能是在没有任何zone配置时允许所有连接在交换机上的设备互相通信。

 

二.如何做zone

  1. 1. 博科交换机CLI命令行:

首先对每个需要做zone的设备创建alias,然后创建zone并把alias加入,创建cfg(zoneset)并把需要的zone加入,最后启用cfg

帮助命令: zonehelp

显示现有配置:cfgshow

创建/增加成员/移除成员/删除alias

     alicreate "aliName","member[; member...]"

     aliadd "aliName","member[; member...]"

     aliremove "aliName","member[; member...]"

     alidelete "aliName"

创建/增加成员/移除成员/删除zone:

     zonecreate "zonename", "member[;member...]"

     zoneadd "zoneName", "member[;member...]"

     zoneremove "zoneName", "member[;member...]"

     zonedelete "zoneName"

注意:根据zone的最佳实践,EMC推荐每个zone里只放一个initiator(主机,VplexBE口等)。多个initiator互相zone在一起会导致很多反常现象。

创建/增加成员/移除成员/删除cfg

     cfgcreate "cfgName", "member[;member...]"

     cfgadd "cfgName", "member[;member...]"

     cfgremove "cfgName", "member[;member...]"

     cfgdelete "cfgName", "member[;member...]"

保存/启用cfg

     cfgsave

     cfgenable "cfgName"

注意:激活某个cfg会使其他正被使用cfg停止工作,一个fabric里同时只能有一个cfg处于工作状态。

更改default zone配置:

     defzone [--noaccess | --allaccess | --show]

 

  1. 2. 博科交换机GUI界面:

进入webtools后点击Zone Admin,进入zone配置界面。

V6.x.x界面:

1.jpg

V7.x.x界面:

2.jpg

进入Zone Adminv6.x.xv7.x.x版本的界面基本一致。

3.jpg

创建alias

4.jpg

点击New键或右边的new alias键,输入alias名字,注意只能输入数字字母或下划线。

5.jpg

点击OK后注意6.jpg 栏内已经显示刚才输入的alias名字,然后从左边的列表里选中相应的wwn或交换机端口,点击add member键加入右边的alias members里。

创建zone并添加成员:

选中标签页中的zone标签,点击New按键,输入zone名字并点击OK

7.jpg

然后从左边列表里选中相应的wwn,交换机端口或之前设置好的alias,点击add member键加入右边的zone members里。

注意:根据zone的最佳实践,EMC推荐每个zone里只放一个initiator(主机,VplexBE口等)。多个initiator互相zone在一起会导致很多反常现象。

 

创建cfg并添加成员:

选中标签页中的zone config标签,点击New键,输入cfg的名字并点击OK

9.jpg

然后从左边列表里选中相应的zone,点击add member键加入到右边的zone config members里。

 

保存并激活cfg

选中标签页中的zone config标签,查看name右边下拉菜单,确认当前的cfg是需要激活的cfg

9.jpg

点击save config按钮,保存之前更改好的cfg

点击enable config按钮,激活当前选中的cfg

注意:激活某个cfg会使其他正被使用cfg停止工作,一个fabric里同时只能有一个cfg处于工作状态。

 

更改default zone配置:

点选zoning actions菜单,选中set default mode里的no accessall access

10.jpg

 

3. 思科交换机CLI命令行:

思科交换机与博科交换机最大的不同就是vsan,每个vsan都拥有自己独立的zonezoneset

其次还有enhanced zoningbasic zoning的区别。

enhanced zoning会在用户试图更改zone配置时创建一个session,防止其他用户同时更改配置造成配置丢失。开启了enhanced zoning功能的交换机在做完zone配置更改之后需要commit以使配置生效并关闭session

另外需要注意的是enhanced zoning会自动开启广播zone,而MDS9500系列在升级到第四代端口板的时候需要禁用广播zone才能是第四代端口板生效。

显示命令:

     # show fcalias vsan x

     # show zoneset vsan x

     # show active zoneset vsan x

     # show zone status vsan x

启用enhanced zoning

     # configure terminal

     (config)# zone mode enhanced vsan x

更改alias

     (config)# fcalias name A123 vsan x

     (config-fcalias)# member pwwn 10:00:00:00:00:00:00:00

     (config-fcalias)# exit

     (config)# zone commit vsan x

更改zone

     (config)# zone name zone123 vsan x

     (config-zone)# member interface fc1/1

     (config-zone)# member pwwn 20:00:00:00:00:00:00:00

     (config-zone)# member fcalias A123

     (config-zone)# exit

     (config)# zone commit vsan x

更改zoneset

     (config)# zoneset name zoneset123 vsan x

     (config-zoneset)# member zone123

     (config-zoneset)# exit

     (config)# zone commit vsan x

激活zoneset(只在basic zone模式下有效)

     (config)# zoneset activate name zoneset123 vsan 1

禁用广播zone

     (config)# no zone broadcast enable vsan x

 

4. 思科交换机GUI界面(DCNMDCFM基本一致)

点击DCNM界面zone菜单中的edit local full zone database…

11.jpg

编辑zone的界面如下:

13.jpg

编辑fcalias

首先在左下角找到fc-alias,右键点击insert并输入alias名和wwn

14.jpg15.jpg

点击OK后创建alias的窗口并不会立刻关闭,可以更改alias名和wwn,再点击OK来连续创建其他alias

 

编辑zone

点击左下角的zones,右击并选中insert,可以创建zone

16.jpg17.jpg

点击OK后会看到新创的zone显示在列表里,在左下角点开zones前的加号,选中新增的zone来编辑其成员。

18.jpg19.jpg

在右下角的列表里找到相应的wwndevice alias,点击add to zone加入到zone里,或在左下角把fcalias拖进相应的zone里。

20.jpg

编辑zoneset

把之前编辑好的zone从左下角拖进左上角的zoneset即可。

 

确认编辑/激活zoneset

点击右下角的commit changes按钮,会把对该vsan做的更改发布到整个SAN网络里。

21.jpg

选中某个zoneset,点击右下角的activate按钮,会显示之前对这个zoneset做过的更改。

22.jpg

23.jpg

点击close之后显示保存running-configstartup-config的对话框,如果确实要执行该操作,打上选项前的勾并点击continue activation

24.jpg

25.jpg

显示success了就说明激活zoneset并保存配置成功了。

 

 

三.如何做好zone

做一个zone很简单,但是如何做好zone,却要考虑到方方面面的问题。

1.  推荐使用wwn zone(客户有特殊要求或FICON环境除外),原因如下:

1)  port zone只能通过物理隔离来保证zone安全,而wwn zone能限制只有指定设备才能访问zone

2)  NPIVAG环境中,只能使用wwn zone来划分zonecluster上的主机或虚机。

3)  IVR/FCR和磁带加速技术只能使用wwn zone

 

2.  LUN maskingzone同时使用

ZoneLUN masking都可以隔离主机和存储之间的通信,但是这两者作用在不同的层面。Zone在交换机上面生效,LUN masking在存储端口生效,两者无法做相互取代。

 

3.  alias命名应该清晰易懂,确保不会混淆。

 

4.  博科交换机尽量避免使用混合zone模式。博科交换机在6.4.3之前有一个bug,会导致在混合zone里的主机自动登出存储。

 

5.  思科交换机使用enhanced zoning,防止多个用户同时更改zone配置导致配置丢失。

 

6.  关闭default zone,避免未经验证的设备登入网络。

 

 

附录:

相关命令可参考EMC论坛专题:https://community.emc.com/docs/DOC-32182

SAN网络学习资料可参考EMC论坛专题:https://community.emc.com/thread/147284

EMCSAN网络专家认证考试为E20-532,详细内容可参考以下链接:https://education.emc.com/content/_common/docs/exam_descriptions/e20_532_SA_Networked_Storage_SAN_Specialist_exam.pdf

 

    数据迁移长久以来一直是一个困扰用户的问题。随着IT系统的复杂性与日俱增,制定迁移方案也经常是存储管理员非常头疼的一件事。要实现在线的迁移有时候的确也是不小的挑战。

    正是针对这样一个背景,EMCSymmetrix VMAX推出了Federated Live Migration这样一个全新的特性。

       Federated Live Migration提供从DMX/VMAXVMAX的真正无中断迁移。FLM将基于阵列的数据迁移(由 EMC Open Replicator for Symmetrix 提供)与主机级别的应用程序重定向(由 EMC PowerPathVeritas DMP或主机 MPIO 提供)联系在一起,从而实现上述功能。 它通过EMC图形化管理软件或SYMCLI 使用一组协调命令启动迁移会话,并从一个中心点协调主机应用程序重定向,确保迁移过程真正无中断。此外,Federated Live Migration 还支持大量预先审核过的阵列堆栈、PowerPath和主机操作系统,它们可帮助避免耗时的补救过程。Federated Live Migration也相当灵活;它能够支持密集到密集、密集到精简和精简到精简的迁移组合,并支持将多个系统整合到一个 Symmetrix

      Federated Live Migration (FLM) 允许用户将数据从旧存储移动到新的Enginuity 5875/5876 阵列,而不会造成应用程序主机停机。Federated Live Migration (FLM)的运行方式为:使新的 VMAX 设备采用原 Symmetrix DMX 设备的标识和结构,然后执行 Open Replicator (ORS)操作作为新阵列和原阵列之间的当前数据移动方法。新的VMAX设备必须等于或大于原DMX设备,才允许执行迁移操作。原存储必须为 Symmetrix,而原设备不能参与任何类型的本地或远程复制。需要进行此限制,才能确保新设备上的数据完整性,因为如果在运行Open Replicator 拉入会话时将新数据写入原 DMX 设备,则该会话将无法复制一致的数据。

 

FLM 配置包括网络、存储阵列、应用程序主机,以及 Solutions Enabler(SE) 主机,如下所示:

1.png


Federated Live Migration主要应用于以下的两个场景:

2.png


Federated Live MigrationMigration Flow如下:

3.png

  • 最开始的时候我们可以看到应用是跑在旧的DMX阵列上的
  • 紧接着,我们在VMAXFADMXFA之间建立一个可用的Zone,以保证他们之间能够通信
  • 主机的HBA和新的VMAX前端口之间也要建立好Zone

 

4.png

  • 在新的VAMX阵列上根据具体需要创建好一个新的device,并且map到此存储的前端口上。在第四步和第五步之间新的FLM session必须被创建,此时新的VMAX上的device会进入一种叫passive的状态
  • 在第五步,我们把新的VMAX devicemasking让主机看见
  • FLM session被激活后新的VMAX device会改变成active的状态,而原先的DMX上的device会变为passive状态。此时VMAX上运作的是ORS Hot Pull with Donor Updatesession。此时hostIO便被重定向到VMAX device上了



下面提供一个简单实际的操作案例供大家参考:

1. 创建一个文件,里面包含标准ORS Pull Sessionsourcetarget 设备

## FLM PAIR FILE

##

## COLUMN1: FLM Target [ VMAX - 5875 ]

## COLUMN2: FLM Source [ DMX - 5671 ]

symdev=000194900275:0328 symdev=000187490076:0720

symdev=000194900275:0329 symdev=000187490076:075F

symdev=000194900275:032A symdev=000187490076:07B6

symdev=000194900275:032B symdev=000187490076:07E9

 

2. 使用命令 symrcopy create –pull –migrate 创建一个NoCopyFLM session

C:\> symrcopy -f win_flm create -pull -migrate -host_type windows -mp_type ppath_45

 

3. 使用symrcopy query命令去验证FLM Pairs出现在Migration Session中,并且已经在Created State

C:\> symrcopy -f win_flm query

Device File Name : win_flm

       Control Device                  Remote Device      Flags      Status Done

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

Protected

SID:symdev Tracks    Identification           RI CDSHUTZ  CTL <=> REM    (%)

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

000194900275:0328 60000 000187490076:0720        SD ...XXM. Created         N/A

 

Flag列下面的M代表着这是一个FLM Migration Session

 

4. VMAX上的DeviceMapMasking

C:\> symaccess –sid 275 create view -name win_flm_mv -sg win_flm_sg -pg win_flm_pg  -ig win_flm_ig

C:\> symaccess -sid 275 show view win_flm_mv

 

5. 主机端验证VMAXdevice已经可以被主机看见了

C:\> powermt display dev=all

Pseudo name=harddisk14

Symmetrix ID=000187490076

Logical device ID=0720

state=alive; policy=SymmOpt; priority=0; queued-IOs=0

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

---------------- Host ---------------   - Stor - -- I/O Path -  -- Stats ---

### HW Path                 I/O Paths    Interf. Mode    State  Q-IOs Errors

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

   5 port5\path0\tgt10\lun6    c5t10d6   FA 14cA active  alive      0 0

   5 port5\path0\tgt11\lun6    c5t11d6   FA 14cB active  alive      0 0

   5 port5\path0\tgt4\lun1     c5t4d1    FA 7eC   active  dead 0      1

   5 port5\path0\tgt6\lun1     c5t6d1    FA 8eC   active  dead 0      1

 

6. 激活FLM session

C:\> symrcopy -f win_flm activate -migrate

 

7. 确认FLM Session正在Copy数据

C:\> symrcopy -f win_flm query

Device File Name : win_flm

       Control Device                  Remote Device      Flags Status    Done

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

Protected

SID:symdev Tracks    Identification           RI CDSHUTZ  CTL <=> REM    (%)

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

000194900275:0328 45580 000187490076:0720        SD X..XXM. CopyInProg       24

000194900275:0329 45399 000187490076:075F        SD X..XXM. CopyInProg       24

000194900275:032A 45411 000187490076:07B6        SD X..XXM. CopyInProg       24

000194900275:032B 550 000187490076:07E9        SD X..XXM. CopyInProg       96

Total ---------

  Track(s)            136940

  MB(s)               8558.8

 

8. 确认主机端应用已经从原先的DMX切换到VMAX上了

C:\> powermt display dev=all

Pseudo name=harddisk14

Symmetrix ID=000187490076

Logical device ID=0720

state=alive; policy=SymmOpt; priority=0; queued-IOs=0

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

---------------- Host ---------------   - Stor - -- I/O Path -  -- Stats ---

### HW Path                 I/O Paths    Interf. Mode    State  Q-IOs Errors

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

   5 port5\path0\tgt10\lun6    c5t10d6   FA 14cA active  dead       0 1

   5 port5\path0\tgt11\lun6    c5t11d6   FA 14cB active  dead       0 1

   5 port5\path0\tgt4\lun1     c5t4d1    FA 7eC   active  alive 0      1

   5 port5\path0\tgt6\lun1     c5t6d1    FA 8eC   active  alive 0      1

 

9.过了一段时间后,确认FLM拷贝已经完全结束了

C:\> symrcopy -f win_flm query

Device File Name      : win_flm

Control Device Remote Device      Flags      Status Done

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

                   Protected

SID:symdev         Tracks    Identification           RI CDSHUTZ  CTL <=> REM    (%)

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

000194900275:0328          0 000187490076:0720        SD X..XXM. Copied          100

000194900275:0329          0 000187490076:075F        SD X..XXM. Copied          100

000194900275:032A          0 000187490076:07B6        SD X..XXM. Copied          100

000194900275:032B          0 000187490076:07E9        SD X..XXM. Copied          100

Total              ---------

Track(s)                 0

MB(s)                  0.0

...

C:\> symrcopy -f win_flm verify

All device(s) in the list are in 'Copied' state.

 

10. Terminate结束了的FLM Session

C:\> symrcopy -f win_flm terminate -migrate

一. VPlex系统的系统组成

一套VPlex 完整的配置共包括以下几种硬件构成,(但并不是每种VPlex模型都包含全部设备类型),具体的系统组件如下:

  1. 引擎 Engine – VPlex的核心,提供数据的I/O及路径的冗余,每个引擎均有director-A director-B组成);
  2. 管理服务器 MS – Management Server,管理/维护/日志收取);
  3. Fibre Channel COM 交换机(只作为内部director间通讯,不做前后端I/O相关连接);
  4. UPS (为VPlex 内部FC 交换机及管理服务器进行供电);
  5. SPS (为VPlex directors进行供电);

VPlex根据客户选择引擎的数量有三种默认出厂配置可供选择,以满足不同客户对的性能和拓扑的需求(单引擎/

双引擎/4引擎),如(图一)所示:

1.jpg

1.  VPlex共有单引擎/双引擎/4引擎三种默认配置可供选择

 

二. 引擎 Engine

Vplex 第二代引擎我们这里简称为 VPLEX VS2 引擎。每个Vplex VS2 引擎由两个directorA B)组成,每一个director均提供了前端和后端的I/O连接。这里就是Vplex的一个最简单的模型,既Vplex Local 单引擎模型,更复杂的多引擎环境及MetroGeo的高级架构都是基于该模型做出的硬件扩展。

在满足网络拓扑冗余符合最佳实施方案的大前提下,通常这样一个单引擎模型已经可以为客户的一个简单本地环境提供高效的前端及后端的冗余架构了,如:部分前端主机/交换机/Vplex director,又或者是部分后端存储发生或者同时发生故障的情况下,均可提供无缝I/O的切换,以确保客户生产系统不会有I/O中断(DU- data unreachable)又或数据丢失(DL – data lost)的情况发生。

2.jpg

2.  VPlex前后端布局图


(图3)提供的是Vplex VS2引擎的后部物理结构。通过与(图2)中物理实际照片的对比,我们可以看到VS2 引擎的director A在我们的右手边,而director B在左手边。

3.jpg


3. VPlex 后端模块顺序图


对于每个单一director自左到右的模块分别为:

  1. 管理模块;
  2. 前端模块;
  3. 后端模块;
  4. 广域网(WAN)模块;
  5. 本地(Local)模块;

  6. 保留模块插槽;

每个VS2 director包含的物理结构是固定的,每个I/O 模块的位置都是设计好的,并且具有特定的功能。通过(图3)我们可以看到有三种类型的模块可以供不同架构的VPlex选择

  1. 1. 8Gb/s Fibre Channel (4 8Gb/s 的端口,可以用于前端,后端及广域网WAN的连接);
  2. 2. 10 Gb/s Ethernet (Geo);
  3. 3. Filler Module  (Vplex Local Only).

Vplex VS2引擎每个模块上的SFP也是特定的厂家生产的,不能通过交换机或者其他部件上的SFP自行更换。

相对与上一代Vplex 引擎的一些差异如下:

  1. 首先就是新一代的Vplex VS22U)引擎对于第一代的引擎(VS1 - 4U)来说体积上更小;
  2. 新一代VS2引擎SLIC 插槽简化了架构 ,现在只有5个插槽了;
  3. CPUPCI-E的总线架构更快了(Westmere 2.4 GHZ – 4 Core and PCI-E V2;

关于序列号的查找:

通常,从设备的背面位置看过去,VPlex设备的序列号-TLA Top Level Assembly #)位于盖体的右下角位置如(图4 所示:

4.jpg

4. VPlex 序列号位置

 

关于director的命名规则如下:

Director-1-1-A

第一个1 表示的是Cluster-1 site A)中的一个Director

第二个1表示的是Engine-1 site A Engine)中的一个director

合起来表示的是Cluster-1 中引擎1director A

例子: director-2-4-B

表示的是Cluster-2 Site B)中引擎4 engine-4)的director B 通过对(图1)中4引擎的机架位置我们可以知道,该引擎位于 机架最上端左边的一个引擎。

 

  关于SFP 位置的命名规则如下,如(图5)所示:

5.jpg

5. SFP 的顺序及命名规则

 

三. 管理服务器 MS – Management Server

管理服务器是管理和认识VPlex的一个接口,通常我们都是是通过管理服务器来实现(CLI界面或者是网页的GUI界面)管理配置及日志收取的。管理服务器与director之间的IP网段也是私有的,并与客户的IP网段相互隔离互不影响,如(图6)所示。

VPlex 管理服务器只是作为一个管理维护的窗口,在MetroGeo的环境中两个Site各配置了一个管理服务器(MS),两个管理服务器均可以通过管理服务器之间建立的VPN对另外一个Site进行管理。管理服务器故障不会影响主机到存储之间 I/O的相关操作。


管理服务器也可以配置EMCESRS网关及激活Call Home的服务。

6.jpg

6. 管理服务器连接示意图


下图(图7)显示了一个高阶架构中管理服务器和director之间的连接方式。通过演示我们可以看到,VPlex 管理服务器和director之间的连接时是不用通过IP交换机的。Director是通过菊花链的方式通过两个冗余的以太口与其他两个director相互连接。管理服务器也连接到了两组Director A B组) 来实现冗余。

管理服务器也是VPlex架构中唯一配置了“Public IP”(客户提供的数据中心管理网段地址)的设备。通过这个地址, 客户就能够通过 SSH PUTTY接入)命令行(CLI)或者 HTTPs的网页(GUI)形式来配置或者维护VPlex设备了。

VPlex日志的收取目前只能通过SSH的方式来进行,并且通常只要在一边收取日志即可。在极个别特殊情况下, Metro Geo环境中 VPN/FC-WAN/IP-WAN都中断后,需要在两边的管理服务器上收取VPlex日志。

7.jpg

7.管理服务器拓扑结构图


四. Fibre Channel COM 交换机

VPlex双引擎及4引擎的配置中使用了光纤交换机。 其中双引擎系统每个交换机使用了4个端口。4引擎系统每个交换机使用了8个端口。 Local-com 网络是完全独立于生产系统的光纤交换机的。并且不允许其他的设备使用VPlex内部交换机。VPlex

的内部交换机通过UPS 来供电。

8.jpg

8. Inter FC Switch


五. 关于SPSUPS设备

SPS负责给VPlex引擎的director供电,UPS则为Inter-FC交换机及管理服务器提供电源。

 

 

希望通过对以上VPlex基础架构的简要介绍能够帮助大家对VPlex有个直观的了解,并能够在工程师间进行进行快速高效的沟通。如果对VPlex硬件架构需要进一步了解的朋友可以参考以下技术文档:

  1. VPlex Product Guide》;
  2. VPlex Architecture Details》;
  3. VPlex Configuration Guide – Part B. Reference》;

  4. SolVe Desktop – VPlex Replacement

FAST VP从诞生以来就一直可以为启用了SRDF远程复制的卷进行自动分层服务,不过运行在SRDF站点两端阵列上的FAST VP是独立运行的,彼此之间没有关联。

通常生产站点的SRDF卷(以下简称R1)会接收到来自主机的读写I/O,但在备份站点的SRDF卷(以下简称R2)只接收来自R1的写I/O,读I/O不会从R1发送至R2。这样R1阵列上的FAST VP基于R1的读写繁忙程度来产生数据迁移计划,而R2阵列上的FAST VP只基于R2的写繁忙程度来生产数据迁移计划。因此,SRDF两端阵列上的SRDF卷的数据分层情况是不同的。如果用户遭遇故障将生产应用failover到了R2端,R2阵列的数据分层情况很可能不是最优的,尤其是对于读I/O繁忙的应用。

从5876.229开始,Symmetrix支持将R1的数据统计信息发送至R2阵列,这样R2阵列上运行的FAST VP针对SRDF卷将生成与R1相同的数据迁移计划,从而保证同一个SRDF卷在SRDF两端的数据分布是一致的。该功能需要SRDF两端阵列运行的微码版本都支持FAST VP与SRDF集成的功能。

这个功能可以在绑定了FAST VP策略的卷组(SG)上被打开或关闭,系统默认是关闭的。打开或关闭该功能只需要在R1阵列上进行操作,除非用户进行了SRDF swap操作。

FAST VP与SRDF的集成也不限于只有两个站点的情况,它还支持Concurrent SRDF和Cascaded SRDF的环境,并且对SRDF的运行模式(同步、异步等)也没有限制。此外,它还支持运行PPRC的大型机环境。

由于R1的数据统计信息是通过SRDF链路进行传送的,所以当SRDF链路出现中断时,R2阵列将无法使用最新的统计数据来生成数据迁移计划。除了链路的物理中断,SRDF链路还可能处于Split、Suspended、Failover和Partitioned的状态中,在这几种状态下,统计数据也不会发送至R2阵列。

 

通过Solutions Enabler打开或关闭FAST VP与SRDF集成功能的命令是:

#symfast -sid <SymmID> [-i <Interval>] [-c <Count>]-fp_name <FastPolicyName> associate -sg <SgName> [-priority <PriorityValue>] [-rdf_coordination <ENABLE | DISABLE>]

#symfast -sid <SymmID> [-i <Interval>] [-c <Count>]-fp_name <FastPolicyName> modify -sg <SgName> [-priority <PriorityValue>][-rdf_coordination <ENABLE | DISABLE>]

前者用于现有的卷组,后者用于在修改卷组与FAST VP策略关联的时候。

 

我们也可以在Unisphere中的Associate Storage Group界面中打开或关闭该功能。

111.bmp

在上一期的Symmetrix 技术日志中(参见https://community.emc.com/community/support/chinese/storagehw/blog/2013/11/12/symmetrix%E7%9A%84%E7%A3%81%E7%9B%98%E5%A4%87%E7%94%A8%E6%8A%80%E6%9C%AF),我们为大家介绍了Symmetrix中的几种磁盘备用技术的原理。在今天的日志中,我们将继续为大家进一步的分析和比较这些磁盘备用技术的区别和各自的优缺点。

本文将通过以下几个点来分析和比较:

  1. 是否占用Mirror位:
  2. 数据拷贝性能:
  3. 配置要求:
  4. 数据保护安全性:
  5. 换盘需求:

   6.  后台自动触发和call home情况:


Dynamic Spare V.S Global Spare:

Dynamic Spare会占用Symmetrix的一个mirror位,而global spare不会占用mirror位,从Symmetrix的数据结构上来说,节省了一个用作数据保护的空间。

1.png

从数据拷贝性能上来说, 在坏盘没有完全Not Ready的情况下, Dynamic Spare的数据拷贝做的是从坏盘到备份盘的直接拷贝,所以拷贝的速度会比较快。而Global Spare由于先要把坏盘踢出Raid组与备份盘进行身份互换之后,才进行数据拷贝,此时坏盘已经不在RAID group内,所以此时的拷贝将会从其他RAID 成员进行rebuild,这样的拷贝,数据是需要从其他成员计算回来的,所以拷贝的过程相比dynamic spare会更长。当然,如果是RAID-1的话,由于数据不需要重算,所以两者是相同的。

从配置要求来看,global sparing的配置要求更高,他所对应的的需要系统配置更多的备份盘。因为对Dynamic sparing来说,由于它是作为额外的mirror,所以他不需要盘的大小和速度完全和坏盘相同,有时候一块坏盘可能会同时触发多块dynamic spare盘。而global spare则不同,因为他要和坏盘做配置交换,所以他就要求需要和老盘大小、性能全部一致才可以。

从数据的保护上来说,也有所不同。大家可能听说过DUAL RAID FAILURE的情况,也就是说,在RAID-1 RAID-5保护的数据盘中,一个组坏了两块硬盘。我们知道,在RAID-1RAID-5的情况下,在一个成员坏掉的情况下,我们可以通过其他成员算出这个成员的数据,但是如果一个RAID 组里同时坏了两块盘,就没有办法再进行数据重算了。这也就是我们建立备用盘机制的原因,也就是防止这样情况的产生。但是,如果在备份盘的数据同步过程中,还没有同步完的时候,同一个RAID组里的另一块盘坏了,该如何修复呢?

针对dynamic spare的情况,如果此时坏盘没有NOT READY 那么数据将会是从坏盘往备份盘上拷贝,并且两者共享同一份数据,所以此时这份坏盘上的数据,要么在自己上面,要么在备份盘上面,那么这一份数据是不存在丢失的,也就是说,虽然一个组坏了两块硬盘,但是其中一块硬盘是有保护的,所以此时数据是安全的。假如此时坏盘已经NOT READY,那么数据无法从坏盘往备份盘上面拷贝,就会出现数据无法访问的情况了,此时我们可以尝试将not ready的坏盘拉起来,这样数据就能成功拷贝到备份盘上了。

再来说说global spare的情况,由于global spare本身就是从其他成员上把数据算过来,如果出现DUAL RAID FAILURE的情况的话,数据就可能没有办法算回来了。此时可以把另一块坏盘拉起来,但是如果无法拉起来的话,就需要通过已被踢出RAID组的坏盘中尝试把数据修复过来了。

从换盘需求角度看,由于global spare直接对坏盘和备份盘做了配置更换,也就是说,更换完以后,原来的坏盘已经和该RAID组没有关系了,所以这块坏盘将不会影响客户的数据访问。在这样的情况下,有一个Deferred service的特性,启用该特性后,可等待坏盘数量达到一定阀值后再统一进行坏盘更换。减少了磁盘更换的次数。

再来说一说Symmetrix后台自动脚本如何处理备用磁盘的使用。不论是何种备用盘技术,当一块磁盘报了某种系统认定的致命报错后,系统就会触发引用备用磁盘的脚本,来进行备份盘的数据保护。为了确保数据的安全性,脚本在引用备份盘后,会通过后台的脚本来对数据的同步情况进行监控。不论对于哪一种备份盘机制,将会在数据同步完以后,自动call home并派单到现场进行磁盘更换。

 

DSPS

结合了以上dynamicglobal spare机制的优缺点,我们在DMX设备中,从微码5773.176开始,引入了DSPS的备用磁盘技术,可以说集合了以上两者的优点。改进的最大目的就是尽可能的减少由于dual drive failure造成的数据无法访问的风险。

2.png

DSPS技术简单来说,就是先触发Dynamic spare,从而让数据直接从坏盘上拷贝到备份盘上(在可能的情况下),只有当拷贝完成后,他会继续触发global spare,对坏盘和热备盘进行身份的互换。

DSPS由于运用了dynamic spare,因此他会占用一个mirror位。从数据拷贝性能上看,前期的dynamic spare我们知道,采用的是直接拷贝,所以拷贝性能是非常好的。而后期的global spare呢?这一点上,其实DSPS技术也加快了拷贝速度。因为此时我们的dynamic spare还是存在的,所以DSPS中的global spare的部分,其实是把数据直接从dynamic spare上拷贝到global spare上,而并非通过RAID组重建,所以从拷贝性能上来说,也是快速的。

从数据的安全性来说,这样的备份磁盘架构相当于双保险,所以数据安全性增加了不少。即使是针对DUAL RAID failure的情况,也规避了不少风险。Symmetrix后台的脚本会在dynamic spare同步完全以后自动发送dial home,但仅作为通知目的。当global spare同步完全以后,将会有第二次call home,并且会自动派单到现场工程师做磁盘更换。


DMS V.S DSPS

3.png

最后来说说VMAX 5876微码中最新的DMS技术和DSPS的比较。比起DSPSDMS可以说又做了很多优化。首先,DMS不占用mirror位,由于DMS将备份盘直接加在RAID组中作为一个新的member,而并不是通过mirror位的方式安插进去,因为节省了一份数据复制的空间。从拷贝性能上来说,数据同样是从坏盘上直接拷贝到备份盘上,所以,性能上来说都是很好的。但是不同的是,由于DMS在等数据同步完全之后,直接把这块盘和坏盘做身份互换,省去了DSPS中再次拷贝到global spare的过程,因而减少了一次数据拷贝的过程,时间上来说更快速。

从数据的保护上来说,由于是在数据同步完以后再做配置变更,同样也继承了DSPS中对Dual RAID failure情况的保护作用。而同DSPS一样,脚本会分别在配置备份盘引用和数据同步完之后分别dial home,并在数据同步完,保证数据安全的情况下派单换盘。


以上就是目前Symmetrix各种备用磁盘技术的简单介绍,我们大致可以看到在不同的微码下的不同的磁盘备用机制。随着微码的更新,Symmetrix的磁盘备用技术也同样在更新,并且从各方面看,也在不断的进步,加快数据同步的速度和性能,同时也加强了对数据的保障。

RP工作原理

EMC RecoverPoint是一种企业级解决方案,旨在保护SAN连接的异构服务器和存储阵列上的应用程序数据。RecoverPoint在带外应用装置上运行,结合了业界领先的连续数据保护技术与带宽效率、无数据丢失复制技术。

EMC RecoverPoint提供本地和远程数据保护,支持跨任意距离可靠地复制数据,也就是说,支持在同一个站点内的本地复制以及到另一个站点的远程复制。具体而言,RecoverPoint可保护和支持应用程序通过光纤通道写入本地SAN连接存储的数据复制。RecoverPoint利用现有的光纤通道基础架构与现有主机应用程序和数据存储子系统无缝集成。对于远距离,RecoverPoint使用现有的IP网络在WAN上发送复制数据。


RecoverPoint复制基于写拆分器。拆分器的主要功能是“拆分”应用程序写入数据,一边数据不仅可以发送至正常指定的存储卷,还可以发送至RPA。所有可用的拆分器分为以下四种:基于主机、基于SAN/结构、基于阵列以及VPLEX拆分器。

1.jpg

1 基于阵列的拆分器

2.jpg

2 基于SAN交换机的拆分器

RP远程复制

RecoverPoint CRR在光纤通道和IP网络上使用异步、同步和快照技术提供跨任意距离的双向、异构、数据块级别复制。

3.jpg

3 基于IPRecoverPoint远程复制

一致性组

一致性组由生产卷、日志卷和复制卷组成。一致性组确保复制副本中的数据更新与生产卷中的数据更新以相同的顺序写入,并且是一致的。

副本High Load

由于各种资源的限制,复制副本会遇到High Load问题。频繁出现High Load会导致用户体验下降。用户通常会开case来搞清楚High Load的原因。

常见的High Load是副本进入temporary high load

以下四种情况会导致副本进入temporary high load:

·         极端情况下,长时间超量的写负荷

·         日志卷和复制卷分发数据太慢

·         WAN带宽不够

·         压缩级别太高

超量写负荷与压缩级别太高在性能统计中比较容易识别,日志卷和复制卷数据分发慢以及WAN带宽问题比较隐蔽,下面介绍下这两个问题的排查。

WAN带宽问题排查。

首先确定High load的时间。High load的时间可以在RPA日志的CLI文件中查到。

High load事件

  Time:             Wed Aug  7 10:41:24 2013

  Topic:            GROUP

  Scope:            DETAILED

  Level:            WARNING

  Event ID:         4019

  Site:             7DaysInn_KXC

  Links:            [WFO-04_CG, WFO-04_KXC -> WFO-04_RMZ]

  Summary:          Group in high load -- transfer to be paused temporarily  Service Request info:N/A

检查该时间点之前的Incoming write速率。这个速率是性能数据,可以在性能日志文件中找到。

在此之前10分钟左右,大约平均每秒10-20MB/s的数据量

2013/08/07 02:32:07.910 GMT    2013/08/07 02:33:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      15.2306 Megabytes/sec

2013/08/07 02:33:07.910 GMT    2013/08/07 02:34:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      12.8331 Megabytes/sec

2013/08/07 02:34:07.910 GMT    2013/08/07 02:35:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      5.81344 Megabytes/sec

2013/08/07 02:35:07.910 GMT    2013/08/07 02:36:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      17.8956 Megabytes/sec

2013/08/07 02:36:07.910 GMT    2013/08/07 02:37:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      20.43     Megabytes/sec

2013/08/07 02:37:07.910 GMT    2013/08/07 02:38:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      19.557   Megabytes/sec

2013/08/07 02:38:07.910 GMT    2013/08/07 02:39:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      21.2274 Megabytes/sec

2013/08/07 02:39:07.910 GMT    2013/08/07 02:40:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      11.2537 Megabytes/sec

2013/08/07 02:40:07.910 GMT    2013/08/07 02:41:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      16.1114 Megabytes/sec

2013/08/07 02:41:07.910 GMT    2013/08/07 02:42:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    Incoming writes rate for link                                      17.0141 Megabytes/sec

直接导致Lag100M左右直线上升到7G

2013/08/07 02:31:07.910 GMT    2013/08/07 02:32:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          106.659                Megabytes

2013/08/07 02:32:07.910 GMT    2013/08/07 02:33:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          673.536                Megabytes

2013/08/07 02:33:07.910 GMT    2013/08/07 02:34:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          1405.1                Megabytes

2013/08/07 02:34:07.910 GMT    2013/08/07 02:35:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          1745.29                Megabytes

2013/08/07 02:35:07.910 GMT    2013/08/07 02:36:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          2469.8                Megabytes

2013/08/07 02:36:07.910 GMT    2013/08/07 02:37:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          3581.55                Megabytes

2013/08/07 02:37:07.910 GMT    2013/08/07 02:38:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          4447.67                Megabytes

2013/08/07 02:38:07.910 GMT    2013/08/07 02:39:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          5613.29                Megabytes

2013/08/07 02:39:07.910 GMT    2013/08/07 02:40:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          6738.1                Megabytes

2013/08/07 02:40:07.910 GMT    2013/08/07 02:41:07.910 GMT    long term            7DaysInn_KXC   RPA1     WFO-04_CG                WFO-04_KXC     WFO-04_RMZ                    RPO - lag in data between replicas during transfer after init          7099.98                Megabytes

从这两个数据可以判断,High load可能的原因是

1 WAN带宽不够,导致数据积压在网络上面。

2 Slow Storage,导致DR那边写积压。

这时,如果客户能够确认上述资源那一种存在瓶颈,那么基本可以定位原因了。如果客户也没有办法确认,那么还需要进一步的数据来辅助分析。

进一步的数据分析显示,WAN的平均速率在忙时只有3Mbps+

2013/08/06 20:04:07.910 GMT    2013/08/06 20:05:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              1.50716 Megabits/sec     

2013/08/06 20:05:07.910 GMT    2013/08/06 20:06:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              3.18644 Megabits/sec     

2013/08/06 20:06:07.910 GMT    2013/08/06 20:07:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              3.35739 Megabits/sec     

2013/08/06 20:07:07.910 GMT    2013/08/06 20:08:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              3.32743 Megabits/sec     

2013/08/06 20:08:07.910 GMT    2013/08/06 20:09:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              5.50845 Megabits/sec     

2013/08/06 20:09:07.910 GMT    2013/08/06 20:10:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              7.36306 Megabits/sec     

2013/08/06 20:10:07.910 GMT    2013/08/06 20:11:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              6.83884 Megabits/sec     

2013/08/06 20:11:07.910 GMT    2013/08/06 20:12:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              6.1095   Megabits/sec     

2013/08/06 20:12:07.910 GMT    2013/08/06 20:13:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              3.18375 Megabits/sec     

2013/08/06 20:13:07.910 GMT    2013/08/06 20:14:07.910 GMT    long term            7DaysInn_KXC                   WAN throughput from site              0.375969              Megabits/sec   

至此已经完全确定WAN带宽不足。通过检查发现用户的带宽是配置问题,导致40Mbps带宽只能用到3Mbps

Journal卷分发速度太慢。

首先确定High load的时间点。同样在CLI文件中。

  Time:             Wed Dec 18 00:45:19 2013

  Topic:            GROUP

  Scope:            DETAILED

  Level:            WARNING

  Event ID:         4019

  Site:             Chai_Wan

  Links:            [IOCM, IOCM-DC -> IOCM-DR]

  Summary:          Group in high load -- transfer to be paused temporarily  Service Request info:N/A

其次,查看与journal卷分发相关性能日志。主要是下面的两个统计指标。

1 Distributor phase 2 thread load : Journalphase 2分发的时间占总分发时间的百分比

2 Distributor phase 2 effective speed : Journalphase 2分发的速率

2013/12/17 16:36:05.869 GMT    2013/12/17 16:37:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        87.272   % of time

2013/12/17 16:37:05.869 GMT    2013/12/17 16:38:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        97.4623 % of time

2013/12/17 16:38:05.869 GMT    2013/12/17 16:39:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        95.9147 % of time

2013/12/17 16:39:05.869 GMT    2013/12/17 16:40:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        90.7287 % of time

2013/12/17 16:40:05.869 GMT    2013/12/17 16:41:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        87.7186 % of time

2013/12/17 16:41:05.869 GMT    2013/12/17 16:42:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        91.9028 % of time

2013/12/17 16:42:05.869 GMT    2013/12/17 16:43:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        91.6016 % of time

2013/12/17 16:43:05.869 GMT    2013/12/17 16:44:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        92.5544 % of time

2013/12/17 16:44:05.869 GMT    2013/12/17 16:45:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        96.4623 % of time

2013/12/17 16:45:05.869 GMT    2013/12/17 16:46:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        85.6245 % of time

2013/12/17 16:46:05.869 GMT    2013/12/17 16:47:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        87.484   % of time

2013/12/17 16:47:05.869 GMT    2013/12/17 16:48:05.869 GMT                    IOCM    IOCM-DR                                             Distributor phase 2 thread load        94.5462 % of time

2013/12/17 16:38:05.869 GMT    2013/12/17 16:39:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               3.63361 Megabytes/sec

2013/12/17 16:39:05.869 GMT    2013/12/17 16:40:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               5.08614 Megabytes/sec

2013/12/17 16:40:05.869 GMT    2013/12/17 16:41:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               5.44455 Megabytes/sec

2013/12/17 16:41:05.869 GMT    2013/12/17 16:42:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               6.10622 Megabytes/sec

2013/12/17 16:42:05.869 GMT    2013/12/17 16:43:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               5.67813 Megabytes/sec

2013/12/17 16:43:05.869 GMT    2013/12/17 16:44:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               4.28963 Megabytes/sec

2013/12/17 16:44:05.869 GMT    2013/12/17 16:45:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               3.59579 Megabytes/sec

2013/12/17 16:45:05.869 GMT    2013/12/17 16:46:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               3.03741 Megabytes/sec

2013/12/17 16:46:05.869 GMT    2013/12/17 16:47:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               2.95798 Megabytes/sec

2013/12/17 16:47:05.869 GMT    2013/12/17 16:48:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               4.20823 Megabytes/sec

2013/12/17 16:48:05.869 GMT    2013/12/17 16:49:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               3.99813 Megabytes/sec

2013/12/17 16:49:05.869 GMT    2013/12/17 16:50:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               4.75266 Megabytes/sec

2013/12/17 16:50:05.869 GMT    2013/12/17 16:51:05.869 GMT    RPA1     IOCM    IOCM-DR                                             Distributor phase 2 effective speed               7.01075 Megabytes/sec

通过性能日志,可以发现Distributor phase 2 thread load 很高,而Distributor phase 2 effective speed很低。由此可以判断Journal分发数据太慢,可能的原因是SAN网络问题或者Storage的性能存在瓶颈。

通过以上分析,我们基本可以判别两类最基本的High Load的原因。当然High Load分析并不是到此为止的。比如WAN带宽不足的问题,从事IP网络维护的工程师都会了解,存在非常多可能原因、问题导致WAN带宽没法达到预期,这个问题的分析本身就是一个很好的课题。再比如Journal卷分发太慢的问题,可能是Connectivity问题,也可能是Slow Storage问题,这两个因素本身也需要一个复杂的排查过程。由于这些问题的排查都处于RP的外部,所以本篇内容不展开讨论。需要记住的是性能问题的原因是多种多样的,并且涉及多个设备,需要相当的经验。


最后希望以上的内容能为有需要的人提供帮助。

Filter Blog

By date:
By tag: