Find Communities by: Category | Product

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

 

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

 

客户在下午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 , 其它虚机应用逐步恢复了正常。

在之前的 帖子里面,有关于远程变更管理团队的介绍(https://community.emc.com/community/support/chinese/generaldiscussion/blog/2014/10/07 )。

 

关于数据备份与恢复 (Data Protection and Availability Division) 团队:

目前我们团队主要提供AvamarData Domain产品的升级,维护以及升级前的准备工作。亚太上海团队的工作时间是周一到周日早上7点到晚上7点。

由于Avamar备份软件适用于非常多的客户端,我们在升级前会检测客户端之间的兼容性已确保升级不会影响到备份和正常使用。此前有ESAEMC Security Advisory)指出所有Data Domain客户需要升级到5.5.0.8版本, 但是请在升级之前检查各版本之间的兼容性 (或者联系我们安排预检) 目前支持Data Domain 5.5.x版本的Avamar版本仅有7.1.0-3707.1.1-141版本。

Avamar是全球第一的源端重复数据删除技术, Data Domain是全球第一的目标端重复数据删除技术。Avamar软件和Data Domain重复数据删除存储系统是目前EMC重复数据删除解决方案的核心。


ar.png

 

我们目前提供如下服务:

Avamar

  • 版本升级(目前最新版本7.1.1-141已经正式公布)
  • MCS补丁
  • GSAN补丁
  • OS安全补丁
  • Dell硬件补丁
  • FCO/TSE
  • 升级前的预检
  • NDMP加速节点升级

Avamar Extended Retention:

  • 版本升级(配合外接的Avamar服务器一同升级以保证兼容性)

Data Domain

  • FCO/TSE

 

Avamar版本升级流程简要概述:

  • 升级当天,工程师会将WebEx远程会话以邮件形式发给客户等待客户进入
  • 当客户进入之后,工程师会再做一次健康检查以确保服务器升级可以正常进行
  • 维护窗口和备份将会在升级过程处于关闭状态,同时会建立一个最新的检查点可以回滚以保证没有任何数据丢失
  • 当一切准备工作就绪,升级就将正式开始,整个升级过程是个线下升级同时会花费4-6个小时,取决于节点的数量已经数据的多少。
  • 在升级过程中,主要进程例如GSAN,MCS,EMS都将会重启。
  • 当整个升级结束之后,工程师会再做一次健康检查,包括备份测试,以确保服务器正常运行。

 

我们会之后定期地在论坛上更新升级相关的信息和问题。如果您有感兴趣的话题,也欢迎和我们联系,我们收到后将会在之后跟进这些话题。

欢迎给我们提出宝贵意见或建议,我们会持续改进服务质量。



Filter Blog

By date:
By tag: