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

 

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

 

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