Find Communities by: Category | Product

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

”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

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

如何在博科交换机的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

  转眼又是新的一年,小伙伴们是不是摩拳擦掌准备在技术上更进一层楼呢?快有半年没更新这个博客了,小编真没闲着,在无数的VNX技术案例中小编整理了几个疑难杂症,想要和大伙一同来探讨。

 

问题一. 为何将Java6升级到78 原本可以管理VNX阵列的Unisphere突然无法使用了呢?(EMC KB 176712)

原因: Java7 更新版本51以后,安全级别默认被调成了高级(High), 没有通过证书认证的应用都会被屏蔽。

解决办法:将VNX管理IP添加到Java可信任列表

  1. 打开控制面板
  2. 选择Program
  3. 选择Java (32-bit)
  4. 选择安全选项
  5. 选择Edit Site List
  6. 加入VNX SPCS的管理IP
  7. 选择应用

1.png

 

问题二. 为何有时候无法使用 vSphere VSI Unified Storage Manager管理VNX Block呢?(EMC KB 188286)

现象:安装VSI后会看到告警 "Could not find valid software header for entry line.  Unable to validate the identity of the server. There are issues with the certificate presented"

原因: NaviCLI 管理VNX时,可以通过证书认证。但是VSI管理VNX时,无法对证书请求进行响应。

解决办法:重新安装

NaviCLI并勾选某些特殊选项。


目录Start > All Programs > EMC > NavisphereCLI > Uninstall Navisphere CLI


选择"Repair / Reinstall"


"Set Verification Level", 选择Low

"Create Security File", 选择 Do not create security credentials file

选择 Next 然后 Install
2.png


问题三. 为何有时选择copy to hot spare操作会失败?(EMC KB 9174)

原因: 热备盘的使用规则是,如果阵列配置了多块热备,最后一块热备将被系统自动预留。没有坏盘的情况下手动操作copy to hotspare这类预防操作Proactive Copy将失败。只有当某块磁盘彻底损坏变成faulted状态时系统才会自动使用最后一块热备盘。可以理解为最后一块盘是用于“救治”而非“预防”

如阵列仅配置了一块热备,copy to hotspare这类预防操作Proactive Copy是可行的。

 

问题四. VNX上配置dial home模板时出现告警 EMC KB56270

现象: "Logging event to system log by agent on SP is not supported."  when use dial home template on SPA or SPB

解决办法: 右击模板. 取消勾选 "Log to System log"

 

问题五. 请问用哪些方法改变VNX 控制器SPIP地址呢?

请参考此表格

设备型号

登录方式

可修改参数

备注

VNX unified

Setup page

IP address, subnet mask, gateway

Grayed out

VNX unified

Proxy ARP

IP address, subnet mask, gateway

No reboot

VNX block | CLARiiON

Setup page

IP address, subnet mask, gateway, Network name

SP reboot

VNX block | CLARiiON

NaviCLI

IP address, subnet mask, gateway

No reboot

VNX block | CLARiiON

NaviCLI

Network name

SP reboot


问题六. 在使用Unisphere Central管理阵列时, 系统为何将大于10GB的存储一分为二?

3.png


4.jpg

Unisphere Central界面说明中,我们可以得知 Unisphere Central 会将大于10GB的存储分成两个部分。

5.png


问题七. 为何VNX 在扩容完成后Unisphere界面仍旧一直显示正在均衡 (rebalancing)状态呢? (EMC KB 174088)

6.jpg


原因: 这是VNX设计使然。Rebalancing后面的百分百会显示本次扩容是否完成,但是rebalancing会一直保留,来提醒用户这个Pool有扩容历史。


【作者姓名】

Nancy Qian

EMC资深技术支持,从事远程技术支持6年。目前就职于EMC VNX支持团队,主要负责VNX 系列产品的系统维护升级。熟悉数据中心的运行维护,熟悉Linux环境。熟悉数据中心存储基础架构,对VNX运维有丰富经验。


【照片】

pic.png

Filter Blog

By date:
By tag: