[UCS B] IOM再起動後にブレードサーバー上の仮想マシンやOSの挙動が遅くなる

[JapanTAC_CSC]

2015年7月21日（初版）
 

TAC SR Collection
問題	UCS B-series のブレードサーバーにてIOMリセットや Fabric Interconnect リブート後に、外部のストレージへのI/Oの負荷がかかる状況（例：仮想マシンの起動やシャットダウン、バックアップの実行等）で特定のブレードサーバー のI/Oに関する動作が極端に重くなる事象が報告されております。
発生条件及び原因	本件はUCS Fabric Interconnectの再起動や IOM の再起動をトリガーに稀な確率で発生する可能性がございます。 IOM の再起動等により、IOM とブレードサーバーの Mezzanine カード間の通信において、PFC（priority-based flow control）機能が稀に無効になってしまう事が原因です。 PFC は輻輳によるフレームロスを防ぐために、通信に負荷がかかるとPAUSEフレームを送信する事で、フローコントロールを行う機能となります。同一リンク内 で、プライオリティ毎にリンクを論理的に分割し、特定のプライオリティに属する通信のみをPAUSEフレームで制御する事で、PAUSEフレームによりリ ンク全体の通信が止まってしまう事を防ぎます。 通常はIOMとブレードサーバー間のリンク確立時にPFCは自動で有効になるのですが、以下の問題によりリンクはUPになるのですが、稀にPFCが有効とならないケースがございます。 CSCuq40256    PFC not enabled despite NXOS config Fabric Interconnect や IOM のリブート後に、特定のブレードのI/Oの挙動が遅くなるという問題が発生した場合には、以下を参考に今回の問題に該当しているかどうかを確認する事ができます。 ・大量のAbortコマンドが発行されている UCS Manager から該当のブレードのMezzanineカードの tech support ログをご取得頂き、obfl.tar.gz のファイルを展開して下さい。 展開後、obfl/syslog ファイルを確認すると以下のように大量のAbortが発生している事が確認できます。 # less obfl/syslog :: 150325-18:29:03.381554 fls.log ecpu2 : abort called for exch 51d9, status 3 rx_id 85ed s_stat 0x1 xmit_recvd 40000 burst_offset 40000 150325-18:29:03.381749 fls.log ecpu2 : abort called for exch 51e1, status 3 rx_id 8571 s_stat 0x1 xmit_recvd 40000 burst_offset 40000 150325-18:29:03.382355 fls.log ecpu2 : abort called for exch 51e7, status 3 rx_id 837a s_stat 0x1 xmit_recvd 40000 burst_offset 40000 # grep "abort called for exch" syslog|wc -l 781 ・ブレードサーバーとIOM間のリンクがUPになっているにもかかわらず、PFCがOFFとなっている UCS に ssh でログインして頂き、connect nxos a と b を実行していただき、両方の Fabric Interconnect から該当のインターフェースの状態を確認します。 # show interface brief -------------------------------------------------------------------------------- Vethernet     VLAN   Type Mode   Status  Reason                   Speed -------------------------------------------------------------------------------- :: Eth2/1/9      1      eth  vntag  up      none                        10G(D) 1309 <--- Interface UP Eth2/1/10     1      eth  access down    Administratively down       10G(D) -- Eth2/1/11     1      eth  vntag  up      none                        10G(D) 1309 Eth2/1/12     1      eth  access down    Administratively down       10G(D) -- # show interface priority-flow-control ============================================================ Port               Mode Oper(VL bmap)  RxPPP      TxPPP ============================================================ :: Ethernet2/1/9      Auto Off           0          32593312 <---- PFC OFF Ethernet2/1/10     Auto Off           0          0 Ethernet2/1/11     Auto On  (8)       0          32559734 Ethernet2/1/12     Auto Off           0          0 Ethernet2/1/13     Auto On  (8)       0          52125838 上記の例では Eth2/1/9 のインターフェースがUPにもかかわらず PFC が OFF となっていることが確認できます。 このため、PFCが動作せず、I/Oの負荷がかかった際に輻輳が発生し、発行したI/OがAbortされ、結果として特定のブレード上で動作しているOSや仮想マシンの動作がスローダウンします。
解決策と回避策	本件は以下の問題が原因で発生します。 CSCuq40256    PFC not enabled despite NXOS config 恒久策についてはCSCuq40256をご参照下さい。 回避策としてはDCEインターフェースのリセットが有効です。 DCEインターフェースはIOMの内部ポートに接続されているブレード側のインターフェースを意味します。 DCEインターフェースをリセットする事で、リンクの再接続処理が発生致しますので、PFCが正常にONとなります。 以下にリセット対象のDCEインターフェースの特定とリセット方法をご説明いたします。 まずリセット対象のポート（PFCがOFFとなっているポート）が Ethernet2/1/9 とします。 EthernetX/Y/Z は具体的に以下を意味します。 X ---> Chassis ID Y ---> Mezznine ID Z ---> Fex Port ID つまり、Ethernet2/1/9 であれば、chassis 2 の1つ目のMezzanineカードに接続されている9番目の Fexポート（IOMのブレード側の内部ポート）という意味となります。 UCS Manager に ssh 接続し、以下のコマンドを参考に、このインターフェースがどのDCEポートと 対応しているのかを確認します。 FI-A# scope chassis 2 FI-A /chassis # scope iom 2 FI-A /chassis/iom # scope port-group host FI-A /chassis/iom/port-group # show server-if Server Facing Interface:      Port Id    Slot Id    Fabric ID Oper State       State Qual Peer Port      ---------- ---------- --------- ---------------- ---------- ---------               1          2 B         Up               sys/chassis-2/blade-1/adaptor-1/ext-eth-5               3          2 B         Up               sys/chassis-2/blade-1/adaptor-1/ext-eth-7               5          2 B         Up               sys/chassis-2/blade-2/adaptor-1/ext-eth-5               7          2 B         Up               sys/chassis-2/blade-2/adaptor-1/ext-eth-7               9          2 B         Up               sys/chassis-2/blade-3/adaptor-1/ext-eth-5 <--- Need to reset this interface              11          2 B         Up               sys/chassis-2/blade-3/adaptor-1/ext-eth-7              13          2 B         Up               sys/chassis-2/blade-4/adaptor-1/ext-eth-5              15          2 B         Up               sys/chassis-2/blade-4/adaptor-1/ext-eth-7              17          2 B         Up               sys/chassis-2/blade-5/adaptor-1/ext-eth-5              19          2 B         Up               sys/chassis-2/blade-5/adaptor-1/ext-eth-7              21          2 B         Up               sys/chassis-2/blade-6/adaptor-1/ext-eth-5              23          2 B         Up               sys/chassis-2/blade-6/adaptor-1/ext-eth-7              25          2 B         Up               sys/chassis-2/blade-7/adaptor-1/ext-eth-5              27          2 B         Up               sys/chassis-2/blade-7/adaptor-1/ext-eth-7              29          2 B         Up               sys/chassis-2/blade-8/adaptor-1/ext-eth-5              31          2 B         Up               sys/chassis-2/blade-8/adaptor-1/ext-eth-7 ------------------------------------------------------------ この例では chassis 2 の IOM 2/2 (FI-B側の2番目のIOM) に接続されているポートがPFC OFF の 影響を受けているため、`scope chassis 2` 実行後、`scope iom 2` を実行することをご注意下さい。 上記の "Port Id " は FEX port ID に相当しますので、今回の例であれば、 sys/chassis-2/blade-3/adaptor-1/ext-eth-5 がリセット対象のDCEインターフェースとなります。 DCEインターフェースのリセットは UCS Manager のGUIから行います。 今回の例であれば、UCS Manager のGUIにログインし、 Equipmentタブ -> chassis 2 -> Server 3 -> Adapters -> Adapter 1 -> DCE Interfaces -> DCE Interface 5 を選択した上で、GUI 画面に表示されている Reset Connectivity を実行して下さい。 リセット実行後、`show interface priority-flow-control` を再度実行し PFC が ON となっていることをご確認下さい。