サーバ - ユニファイド コンピューティング : Cisco Unified Computing System

FlexPod コモン パフォーマンス問題

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料は FlexPod 環境でよくあるパフォーマンス問題を記述し、問題を解決するために方式を提供し軽減ステップを提供したものです。 それは FlexPod 環境のパフォーマンスを解決するために検知 する 顧客向けの開始点として意図されています。 この資料はデータセンタ ソリューション テクニカル アシスタンス センタ (TAC)チームによってここ数カ月で見られた問題の結果として書かれていました。

著者:Cisco TAC エンジニア、Marcin Latosiewicz

FlexPod 概念について

FlexPod は NetApp ストレージおよび IP ネットワークに Nexus スイッチによって接続されるユニファイド コンピューティング システム(UCS)コンピュータで構成されています。

もっとも一般的な FlexPod はファブリックによって相互接続します接続される Cisco UCS B シリーズ シャーシで NetApp ファイラに Nexus 5500 スイッチに(FIs)構成されています。 FlexPod Express と呼ばれる別のソリューションは Nexus 3000 スイッチに接続される UCS Cシリーズ シャーシを使用します。 この資料はもっとも一般的な FlexPod を説明します。

パフォーマンスに関する考慮事項

FlexPod で一般的に見られるように複数の責任があるパーティが付いている複雑 な 環境では、問題を解決するために複数の側面を考慮する必要があります。 レイヤ2 の典型的なパフォーマンス問題および IP ネットワークはから生じます:

  • パケットかフレーム損失-データのビットの損失によりアプリケーションのパフォーマンスに対する悪影響を引き起こします。
  • -パケットかフレームが Storage Networking の場合にはある特定のパフォーマンスへの影響がアプリケーションによって見られるかもしれないキュー/バッファのたくさんの時間を特に費やす場合バッファリングします。 レイテンシー、追加注文、およびノーマライザー問題はこのカテゴリの下で下ります。
  • MTU ミスマッチ問題およびフラグメンテーション-高性能に達する場合のよくある問題。 フラグメンテーションおよび MTU 不整合に関連している問題はこのカテゴリで落ちます。

環境

パフォーマンスが測定される環境を知っていることは重要です。 ストレージ型についての質問およびプロトコル、また影響を受けたサーバの Operating System (OS)および位置は、きちんと問題を狭めるために上げる必要があります。 接続の輪郭を描くトポロジーダイアグラムは最低限です。

測定単位

測定されるものが、そしてそれ測定されるどのように知る必要があります。 ある特定のアプリケーション、またほとんどのストレージおよび hypervisor ベンダーは、システムのパフォーマンス/健全性を示す並べ替えの測定単位を提供します。 これらの測定単位はほとんどのトラブルシューティング手順のための代替ではないのでで開始するべき良い点です。

一例として、hypervisor の Network File System (NFS) ストレージ レイテンシー測定単位は単独でネットワークをどんなに関係させなくてもパフォーマンスがダウン状態になることを示すかもしれません。 NFS の場合には、ホストからの NFS ストレージ IPネットワークへの単純なping はネットワークが責任にすることであるかどうか示すかもしれません。

ベースライン

このポイントは特に TAC ケースをオープンするとき十分重点を置くことができません。 パフォーマンスが不十分であることを示すために、測定されたパラメータは示される必要があります。 これには期待され、テストされた値が含まれています。 理想的には、そのデータを実現させるのに前の使用されるデータおよびテスト の 方法論を示す必要があります。

一例として; 、単一 発信側からの単一 論理的装置番号(LUN)に書き込み専用とテストされたとき実現する 10ms レイテンシーは、レイテンシーがロードされたシステムのためである十分にはずであるものを表さないかもしれません。

FlexPod のパフォーマンス問題

この資料が FlexPod 環境の大半のための参照として意図されているので、データセンタ ソリューションに責任があるようにほとんどの頻繁に起こる問題だけ TACチームによって見られて概説します。

一般的な問題

ストレージによくある問題および IP/Layer 2 ネットワークはこのセクションで説明されています。

フレームおよびパケットロス

フレームおよびパケットロスは最も頻繁なファクタその影響パフォーマンスです。 問題の示す値をインターフェイス レベルに探すよくある場所の 1 つはあります。 Nexus 5000 か UCS Nexus オペレーティング システム(NX-OS)から CLI、show interface を入力して下さい | 秒は「ありますの上で」 | egrep ^ (Eth|fc)|discard|廃棄|Crc コマンド。 稼働しているインターフェイスに関しては、それは名前をリストし、カウンターおよびドロップを廃棄します。 同様に、大きい外観はすべてのインターフェイスのためのエラー統計情報を表示する show interface カウンター エラー コマンドを入力するとき表示する。

イーサネット世界

non-0 のカウンターが問題を示唆しないかもしれませんことを確認することは重要です。 ある特定の場合それらのカウンターは初期セットアップまたは前の操作上変更で上がるかもしれません。 カウンターの増加は監視する必要があります。

1 つはまたより表すかもしれない ASIC レベルからのカウンターを収集できます。 具体的には、インターフェイスの巡回冗長検査(CRC)エラーのために、入るべき TAC 好みのコマンドは show hardware 内部 carmel CRC です。 Carmel はポートレベル フォワーディングに責任がある ASIC の名前です。

同じような出力は 6100 シリーズ FIs かポートごとに Nexus 5600 スイッチから奪取 することができます。 FI 6100 に関しては、gatos ASIC は、このコマンドを入力します:

show hardware internal gatos port ethernet X/Y | grep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"

Nexus 5600 に関しては、bigsur ASIC からの、このコマンドを入力して下さい: 

show hardware internal bigsur port eth x/y | egrep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"

彼らがずかずかと歩かれたかどうか、そしてにどこに受信された、もっと重大にか転送されたかどこに CRC パケットが carmel ASIC のためのコマンドに示され。

Nexus 5000 および UCS NX-OS オペレーションが両方カットスルーであるので、不正確なフレーム チェック シーケンス (FCS)の切り替えモード帯は転送する前だけにずかずかと歩かれます。 破損した帯がどこにから来るか調べることは重要です。 

bdsol-6248-06-A(nxos)# show hardware internal carmel crc 

+----------+------------+------------+------------+------------+------------+------------+------------+
|   Port   | MM rx CRC  | MM Rx Stomp| FI rx CRC  | FI Rx Stomp| FI tx CRC  | FI tx Stomp| MM tx CRC  |
+----------+------------+------------+------------+------------+------------+------------+------------+
(....)
| Eth 1/17 |        --- |        --- |        --- |     908100 |        --- |        --- |        --- |
| Eth 1/18 |        --- |        --- |        --- |     298658 |        --- |        --- |        --- |
(....)
| Eth 1/34 |        --- |        --- |        --- |        --- |        --- |    1206758 |    1206758 |

この例は Nexus 5000 へアップリンクである、Eth 1/17 および Eth 1/18 から来るずかずかと歩かれたパケットを示したものです。 1 つは Eth 1/17 のような + 1/18 の rx が = 1/34 の tx がずかずかと歩く Eth ずかずかと歩く Eth、それらの帯が Eth 1/34 にあとで送られたと仮定できます。

Nexus 5000 の同じような外観は示します:

bdsol-n5548-05# show hardware internal carmel crc 
+----------+------------+------------+------------+------------+------------+------------+------------+
|   Port   | MM rx CRC  | MM Rx Stomp| FI rx CRC  | FI Rx Stomp| FI tx CRC  | FI tx Stomp| MM tx CRC  |
+----------+------------+------------+------------+------------+------------+------------+------------+
(....)
| Eth 1/14 |         13 |        --- |        --- |         13 |        --- |        --- |        --- |
(.....)
| Eth 1/19 |       7578 |        --- |        --- |       7463 |        --- |        --- |        --- |

この出力は 2 つのリンクで受け取ったおよび転送することをことを前にとしてずかずかと歩くマークされる CRC 示します。 詳細については、Nexus 5000 トラブルシューティングガイドを参照して下さい。

Fibre Channel 世界

ドロップ(discrds、エラー、CRC、B2B クレジット枯渇)を探す 単純な方法は show interface カウンター fc コマンドによってあります。

起こることの Fibre Channel 世界で Nexus 5000 およびファブリック相互接続のこのコマンド、利用可能 な、よい示す値を与えたものです。 

次に、例を示します。

bdsol-n5548-05# show interface counters fc | i fc|disc|error|B2B|rate|put
fc2/16
1 minute input rate 72648 bits/sec, 9081 bytes/sec, 6 frames/sec
1 minute output rate 74624 bits/sec, 9328 bytes/sec, 5 frames/sec
96879643 frames input, 155712103332 bytes
0 discards, 0 errors, 0 CRC
113265534 frames output, 201553309480 bytes
0 discards, 0 errors
0 input OLS, 1 LRR, 0 NOS, 0 loop inits
1 output OLS, 2 LRR, 0 NOS, 0 loop inits
0 transmit B2B credit transitions from zero
0 receive B2B credit transitions from zero
16 receive B2B credit remaining
32 transmit B2B credit remaining
0 low priority transmit B2B credit remaining
(...)

このインターフェイスは使用中ではないし、破棄かエラーが起こらなかったことを出力は示したものです。 

さらに、0 からの B2B クレジット遷移は強調表示されました; Cisco バグ ID CSCue80063 および CSCut08353 が原因で、それらのカウンターは信頼される場合がありません。 それらは Cisco MDS で、ない Nexus5k プラットフォームの UCS でうまく働きます。 また Cisco バグ ID CSCsz95889 を確認できます。 

同様に Fibre Channel (FC)のためのイーサネット世界の carmel に fc MAC ファシリティは使用することができます。 一例として、ポート fc2/1 のために、show hardware 内部 fc MAC 2 ポート 1 statistics コマンドを入力して下さい。 示されるカウンターは 16進フォーマットにあります。

bdsol-6248-06-A(nxos)# show interface fc1/32 | i disc
        15 discards, 0 errors
        0 discards, 0 errors
bdsol-6248-06-A(nxos)# show hardware internal fc-mac 1 port 32 statistics 
 ADDRESS     STAT                                                   COUNT
__________ ________                                           __________________
0x0000003d FCP_CNTR_MAC_RX_BAD_WORDS_FROM_DECODER                           0x70
0x00000042 FCP_CNTR_MAC_CREDIT_IG_XG_MUX_SEND_RRDY_REQ                0x1e4f1026
0x00000043 FCP_CNTR_MAC_CREDIT_EG_DEC_RRDY                             0x66cafd1
0x00000061 FCP_CNTR_MAC_DATA_RX_CLASS3_FRAMES                         0x1e4f1026
0x00000069 FCP_CNTR_MAC_DATA_RX_CLASS3_WORDS                        0xe80946c708
0x000d834c FCP_CNTR_PIF_RX_DROP                                              0xf
0x00000065 FCP_CNTR_MAC_DATA_TX_CLASS3_FRAMES                          0x66cafd1
0x0000006d FCP_CNTR_MAC_DATA_TX_CLASS3_WORDS                        0x2b0fae9588
0xffffffff FCP_CNTR_OLS_IN                                                   0x1
0xffffffff FCP_CNTR_LRR_IN                                                   0x1
0xffffffff FCP_CNTR_OLS_OUT                                                  0x1

出力は入力の 15 の破棄を示したものです。 これは 0xf (小数点の 15)に数えた FCP_CNTR_PIF_RX_DROP に一致させることができます。 この情報は FWM (フォワーディング マネージャ)情報に再度関連させることができます。

bdsol-6248-06-A(nxos)# show platform fwm info pif fc 1/32 verbose | i drop|discard|asic
fc1/32 pd: slot 0 logical port num 31 slot_asic_num 3 global_asic_num 3 fwm_inst 7
fc 0
fc1/32 pd: tx stats: bytes 191196731188 frames 107908990 discard 0 drop 0
fc1/32 pd: rx stats: bytes 998251154572 frames 509332733 discard 0 drop 15
fc1/32 pd fcoe: tx stats: bytes 191196731188 frames 107908990 discard 0 drop 0
fc1/32 pd fcoe: rx stats: bytes 998251154572 frames 509332733 discard 0 drop 15

ただし、この tellls 管理者ドロップの量対応する ASIC 数であり。 それの原因についての得情報は廃棄された ASIC 問い合わせられる必要があります。

bdsol-6248-06-A(nxos)# show platform fwm info asic-errors 3 
Printing non zero Carmel error registers: 
DROP_SHOULD_HAVE_INT_MULTICAST: res0 = 25 res1 = 0 [36]
DROP_INGRESS_ACL: res0 = 15 res1 = 0 [46]

この場合、トラフィックは FC 世界の入力 Access Control List (ACL)によって、一般的に-ゾーニング廃棄されました。

MTU の不一致

FlexPod 環境でそれが必要となるアプリケーションおよびプロトコルのエンドツーエンド最大遷移ユニット(MTU)設定を取り扱うことは重要です。 ほとんどの環境の場合には、これはイーサネット(FCoE)およびジャンボ フレーム上の Fibre Channel です。

フラグメンテーションが行われれば、低下した パフォーマンスは期待されるさらにべきです。 Network File System (NFS)および Internet Small Computer System Interface (iSCSI)のようなプロトコルの場合には、エンドツーエンド IPの最大伝送単位(MTU)および TCP Maximum Segment Size (MSS)をテストし、証明することは重要です。

ジャンボ フレームか FCoE を解決するかどうか、それらの両方が正しく動作するために環境を渡って示す一貫した構成およびサービスの分類 (CoS)を必要とすることを覚えておくことは重要です。

インターフェースごとを検証して役立つ UCS および Nexus の場合には、Qos-group MTU設定ごとのコマンドは示しますキューインターフェイスをあります | 並べる I|qos-group|MTU.

MTU は Nexus 5000 および UCS プラットフォームで表示する

UCS および Nexus 両方の既知側面はインターフェイスの MTU のディスプレイです。 この出力はジャンボ フレームおよび FCoE を並べるために設定されるインターフェイスを示したものです:

bdsol-6248-06-A(nxos)# show queuing interface e1/1 | i MTU
    q-size: 360640, HW MTU: 9126 (9126 configured)
    q-size: 79360, HW MTU: 2158 (2158 configured)

同時に、show interface コマンドは 1500 バイトを表示する:

bdsol-6248-06-A(nxos)# show int e1/1 | i MTU
  MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec

carmel ASIC 情報と比較された場合、ASIC はある特定のポートの MTU 機能を示します。  

show hardware internal carmel port ethernet 1/1 | egrep -i MTU
        mtu                : 9260

ディスプレイのこの MTU ミスマッチは前述プラットフォームで期待され、可能性としては初心者を誤解させる可能性があります。

エンドツーエンド設定

エンドツーエンド 一貫した構成は適切なパフォーマンスを保証する唯一の方法です。 Cisco 側のためのジャンボ フレーム 設定およびステップ、また VMware ESXi は VMware ESXi エンドツーエンド ジャンボ MTU 設定例の UCS に、説明があります。

UCS FCoE アップリンク 設定例は UCS および Nexus 5000 設定を示します。 基本的な Nexus 5000 設定の輪郭については参照されるドキュメントの付録 A を参照して下さい。

FCoE のための UCS 設定の Cisco UCS ブレード フォーカスのための FCoE 接続を設定して下さいFCoE NPV の Nexus 5000 NPIV FCoE は Nexus 設定の UCS 設定例フォーカスを接続しました

エンドツーエンド ジャンボ フレームをテストして下さい

ほとんどの現代日オペレーティング システムは簡単なインターネット制御メッセージ プロトコル (ICMP)テストとの適切なジャンボ フレーム 設定をテストする機能を提供します。

計算

オプション(20 バイト)のない 9000 バイトの IP ヘッダー- ICMPヘッダー(8 バイト) = 8972 バイトのデータ

一般的 な オペレーティング システムのコマンド

Linux

ping a.b.c.d -M do -s 8972

Microsoft Windows

ping -f -l 8972 a.b.c.d

ESXi

vmkping -d -s 8972 a.b.c.d

バッファ 関連問題

バッファリングし、他のレイテンシー 関連問題は FlexPod 環境のよくあるパフォーマンス低下原因間にあります。 レイテンシーとして報告されるすべての問題が実際のバッファリング問題から、かなりの数の測定単位エンドツーエンド レイテンシーを示すかもしれません生じません。 たとえば、NFS の場合には、報 告 された 時間期間はストレージおよび実際のネットワーク 待ち時間へ正常に必要な読み書きであるかもしれません。

輻輳はバッファリングのためのもっとも一般的な原因です。 レイヤ2 世界では、輻輳によりバッファリングを引き起こす場合があり、帯のドロップを後につきます。 ドロップを輻輳期間の間に回避するために、IEEE 802.3x 休止フレームおよび優先順位 フロー制御(PFC)はもたらされました。 輻輳が持続する間、両方とも伝達を短い間保持するためにエンドポイントを頼むことに頼ります。 これはネットワーク輻輳によって引き起こされる場合があります(受け取ったデータの量と圧倒して下さい)またはので渡る優先順位をつけられたフレーム必要次 FCoE のためのケース。

フロー制御- 802.3x

どのインターフェイスが有効に なる フロー制御があるか確認するために show interface flowcontrol コマンドを入力して下さい。 有効に なる フロー制御に関してストレージ ベンダーの推奨事項に従うことは重要です。

802.3x フロー制御作業がどのようにここに示されているか示す実例。

PFC - 802.1Qbb

すべてのセットアップ用に PFC が必要となりませんが、ほとんどのために推奨されます。 どのインターフェイスが有効に なる PFC があるか確認するため show interface 優先順位フロー コントロール | I コマンド UCS の NX-OS および Nexus 5000 で動作することができます。 

FIs と Nexus 5000 間のインターフェイスはそのリストで目に見えるはずです。 そうでなかったら、QoS 設定は確認される必要があります。 QoS は PFC を利用するために一貫したエンドツーエンドである必要があります。 PFC が特定のインターフェイスでなぜアップしないかチェックするために、データセンタ ブリッジ機能交換 プロトコル(DCBX)ログを得るために show system 内部 dcbx ログ インターフェイス イーサネット x/y コマンドを入力して下さい。

休止フレームが PFC をどのように使用するか示す実例はここに示されています。

show interface 優先順位フロー コントロール コマンドは管理者が優先順位 休止フレームの毎 QoS クラスの動作を観察することを可能にします。 

次に例を示します。

bdsol-6120-05-A(nxos)# show queuing interface ethernet 1/1 | i prio
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Per-priority-pause status : Rx (Inactive), Tx (Active)

この出力は、第 2 クラスで、デバイスがちょうど(TX) PPP フレームを送信していたことを示したものです。 

この場合、イーサネット 1/1 は IOM に直面するポートであり、全面的なポートに有効に なった PFC がないが FEX ポートのための PPP 帯を処理するかもしれません。 

bdsol-6120-05-A(nxos)# show interface e1/1 priority-flow-control 
============================================================
Port Mode Oper(VL bmap) RxPPP TxPPP
============================================================
Ethernet1/1 Auto Off 4885 3709920

この場合、FEX インターフェイスは複雑です。 

bdsol-6120-05-A(nxos)# show interface priority-flow-control | egrep .*\/.*\/ 
Ethernet1/1/1 Auto Off 0 0
Ethernet1/1/2 Auto Off 0 0
Ethernet1/1/3 Auto Off 0 0
Ethernet1/1/4 Auto Off 0 0
Ethernet1/1/5 Auto On (8) 8202210 15038419
Ethernet1/1/6 Auto On (8) 0 1073455
Ethernet1/1/7 Auto Off 0 0
Ethernet1/1/8 Auto On (8) 0 3956077
Ethernet1/1/9 Auto Off 0 0

複雑である FEX ポートはまた X がシャーシ数どこにであるか示します fex X 詳細にを経てチェックすることができます。 

bdsol-6120-05-A(nxos)# show fex 1 detail | section "Fex Port"
Fex Port State Fabric Port
Eth1/1/1 Down Eth1/1
Eth1/1/2 Down Eth1/2
Eth1/1/3 Down None
Eth1/1/4 Down None
Eth1/1/5 Up Eth1/1
Eth1/1/6 Up Eth1/2
Eth1/1/7 Down None
Eth1/1/8 Up Eth1/2
Eth1/1/9 Up Eth1/2

一時停止メカニズムに関する詳細についてはこれらの文書を参照して下さい。 

キューイング破棄

Nexus 5000 および UCS 両方 NX-OS は Qos-group 基礎ごとの a のキューイングによる入力破棄を把握します。 次に、例を示します。

bdsol-6120-05-A(nxos)# show queuing interface 
Ethernet1/1 queuing information:
  TX Queuing
    qos-group  sched-type  oper-bandwidth
        0       WRR             50
        1       WRR             50
  RX Queuing
    qos-group 0
    q-size: 243200, HW MTU: 9280 (9216 configured)
    drop-type: drop, xon: 0, xoff: 243200
    Statistics:
        Pkts received over the port             : 31051574
        Ucast pkts sent to the cross-bar        : 30272680
        Mcast pkts sent to the cross-bar        : 778894
        Ucast pkts received from the cross-bar  : 27988565
        Pkts sent to the port                   : 34600961
        Pkts discarded on ingress               : 0
        Per-priority-pause status               : Rx (Inactive), Tx (Active)

入力 廃棄はドロップを割り当てるために設定されるキューでだけ起こるはずです

入力 キューイング破棄はこれらの原因が原因で起こる場合があります:

  • いくつかのインターフェイスで有効に なる スイッチ型ポートアナライザ (SPAN) /Monitoring セッション(Cisco バグ ID CSCur25521 を参照して下さい)
  • 別のインターフェイスからのバック プレッシャは、休止フレーム 一般的に 有効に されたとき見られます
  • CPU にパントされるトラフィック 

ドライバ 問題

Cisco は UCS に 2 つのオペレーティング システム ドライバを、enic および fnic 提供します。 Enic はイーサネット接続に責任があり、fnic Fibre Channel および FCoE 接続に責任があります。 enic および fnic ドライバが UCS インターオペラビリティ マトリックスで指定どおりに丁度あることは非常に重要です。 不正確なドライバによってもたらされる問題はパケットロスおよび追加されたレイテンシーからより長いブートプロセスまで及ぶか、または接続の欠如を完了します。

アダプタ 情報

Cisco が提供 した アダプタはトラフィックについてのよい測定単位を提供渡されるできましたり、また廃棄します。 この例にシャーシ X、サーバ Y、およびアダプタ Z.に接続する方法を示されています。

bdsol-6248-06-A# connect adapter X/Y/Z
adapter X/Y/Z # connect 
No entry for terminal type "dumb";
using dumb terminal settings.

ここから、管理者はパフォーマンス(MCP)ファシリティのためのモニタリング センターにログインできます。

adapter 1/2/1 (top):1# attach-mcp
No entry for terminal type "dumb";
using dumb terminal settings

MCP ファシリティは論理インターフェイス(LIF)ごとのトラフィックの使用方法を監視することを可能にします。 

adapter 1/2/1 (mcp):1# vnic
(...)
---------------------------------------- --------- --------------------------
                v n i c                    l i f             v i f           
id  name           type    bb:dd.f state lif state uif  ucsm   idx vlan state 
--- -------------- ------- ------- ----- --- ----- --- ----- ----- ---- -----
 13 vnic_1         enet    06:00.0 UP      2 UP    =>0   834    20 3709 UP     
 14 vnic_2         fc      07:00.0 UP      3 UP    =>0   836    17  970 UP   

シャーシ 1 は、1 つを断絶し、アダプタ 1 は仮想インターフェイス(仮想 な イーサネットまたは仮想ファイバ チャネル) 834 および 836 をと関連付けられる 2 枚のバーチャルネットワーク インターフェイス カード(VNICs)を備えています。 それに第 2 および 3.があります。 LIF 2 および 3 のための統計情報はここに示されているようにチェックすることができます:

adapter 1/2/1 (mcp):3# lifstats 2
               DELTA                TOTAL DESCRIPTION
                   4                    4 Tx unicast frames without error
               53999                53999 Tx multicast frames without error
               69489                69489 Tx broadcast frames without error
                 500                  500 Tx unicast bytes without error
             8361780              8361780 Tx multicast bytes without error
            22309578             22309578 Tx broadcast bytes without error
                   2                    2 Rx unicast frames without error
             2791371              2791371 Rx multicast frames without error
             4595548              4595548 Rx broadcast frames without error
                 188                  188 Rx unicast bytes without error
           260068999            260068999 Rx multicast bytes without error
           514082967            514082967 Rx broadcast bytes without error
             3668331              3668331 Rx frames len == 64
             2485417              2485417 Rx frames 64 < len <= 127
              655185               655185 Rx frames 128 <= len <= 255
              434424               434424 Rx frames 256 <= len <= 511
              143564               143564 Rx frames 512 <= len <= 1023
              94.599bps                   Tx rate
               2.631kbps                  Rx rate

UCS の管理者が合計および差分(lifstats の 2 つのそれに続く実行間で)カラム、また現在のトラフィック負荷毎LIF のおよび生じるかもしれないあらゆるエラーについての情報を与えられることに注意することは重要です。

前例は非常に小さいロードのインターフェイスをエラーなしで示します。 この例は異なるサーバーを示したものです。

adapter 4/4/1 (mcp):2# lifstats 2
              DELTA                TOTAL DESCRIPTION
           127927993            127927993 Tx unicast frames without error
              273955               273955 Tx multicast frames without error
              122540               122540 Tx broadcast frames without error
         50648286058          50648286058 Tx unicast bytes without error
            40207322             40207322 Tx multicast bytes without error
            13984837             13984837 Tx broadcast bytes without error

            28008032             28008032 Tx TSO frames
           262357491            262357491 Rx unicast frames without error
            55256866             55256866 Rx multicast frames without error
            51088959             51088959 Rx broadcast frames without error
        286578757623         286578757623 Rx unicast bytes without error
          4998435976           4998435976 Rx multicast bytes without error
          7657961343           7657961343 Rx broadcast bytes without error

                  96                   96 Rx rq drop pkts (no bufs or rq disabled)

              136256               136256 Rx rq drop bytes (no bufs or rq disabled)
             5245223              5245223 Rx frames len == 64
           136998234            136998234 Rx frames 64 < len <= 127
             9787080              9787080 Rx frames 128 <= len <= 255
            14176908             14176908 Rx frames 256 <= len <= 511
            11318174             11318174 Rx frames 512 <= len <= 1023
            61181991             61181991 Rx frames 1024 <= len <= 1518
           129995706            129995706 Rx frames len > 1518

             136.241kbps                  Tx rate

             784.185kbps                  Rx rate

情報の 2 つの興味深いビットは処理される 96 の帯がバッファかバッファリングのディセーブルにされた欠けること当然のアダプタおよびその上に(TSO)セグメントをオフロードする TCP セグメントによって廃棄されたことを示します。

論理的なパケットフロー

ここに示されているダイアグラムは FlexPod 環境の論理的なパケットフローの輪郭を描きます。

このダイアグラムはフレームが FlexPod 環境によって方法で渡したコンポーネントの内訳ように意味されます。 それはブロックの何れかの複雑な状況を単に反映しないし、特定 の 機能がどこに設定され、確認する必要があるか暗記する方法です。 

入出力 モジュール

論理的なパケットフロー流れ図に示すように、入出力 モジュール(IOM)は UCS を通過するすべての通信の真中にコンポーネントです。 シャーシ X の IOM に接続するために、接続 iom x コマンドを入力して下さい。

他の複数の役に立つコマンドはここにあります:

  • トポロジー情報-提示プラットフォームソフトウェア[woodside|レッドウッド] sts コマンドは IOM の観点からの位層幾何学情報を示したものです。

    FIs まで導きなさいことネットワーク インターフェイス(NIs)を、この場合そこにですそれらの 4 とそれらの 8 時、示します。 さらに、それは特定のブレードに、シャーシの内で、導きなさいことホスト インターフェイスを(彼の)示します。

  • トラフィックレート-提示プラットフォームソフトウェア[woodside|HI インターフェイスを通してトポロジーを一度渡し、ブレード マッピングへの HI がインターフェイス知られているレッドウッド] rate コマンドがトラフィックの比率をチェックするのに使用されています。

  • トラフィック損失-提示プラットフォームソフトウェア[woodside を入力して下さい|レッドウッド]損失コマンド。 このの実行損失が逆らうコマンド ゼロ。 それはインターフェイスごとに休止フレームおよびドロップを参照することを可能にします。

    基礎的なインフラストラクチャがはたらく方法が原因で、カウンターはインターフェイスのためにだけ 2 つのコマンドの損失中間実行を経験したかどれが示されています。  この例では、28 の休止フレームがインターフェイスするために送信されたこと NI2 インターフェイスが 82 の休止フレームを受信した知っている HI23 ことがわかり、ブレード 3.に接続されます。

設計上の考慮事項

FlexPod はストレージおよびデータ 網の柔軟 な 設定およびセットアップを可能にします。 柔軟性によってまた追加チャレンジは来ます。 最良 の 方法 文書および Cisco によって検証される設計(CVD)に続くことは重要です:

ポート速度選択およびポート チャネル考慮事項

TAC エンジニアが見るよくある問題は最良 の 方法 文書で参照される Gbit 10 イーサネットの代りに Gbit 1 イーサネットの選択によるリンクの過度の使用です。 先の尖った例として、シングルフロー パフォーマンスは Gbit 1 10 リンクと比較された 1 Gbit 10 のリンクでよりよくないです。 ポート チャネルではシングルフローは単一 の リンクに行くことができます。 

どんなロード バランシング 方式が Nexus や FI の NX-OS で使用されるか調べるために、show port channel ロードバランス コマンドを入力して下さい。 管理者はまた調べることができますパケットまたはフレームのための発信インターフェイスとしてポート チャネルで選択されるインターフェイスする。 2 つのホスト間の VLAN49 のフレームの簡単な例はここに示されています:

show port-channel load-balance forwarding-path interface port-channel 928 vlan 49
src-mac 70ca.9bce.ee24 dst-mac 8478.ac55.2fc2
Missing params will be substituted by 0's.
Load-balance Algorithm on switch: source-dest-ip
crc8_hash: 2    Outgoing port id: Ethernet1/27 
Param(s) used to calculate load-balance:
        dst-mac:  8478.ac55.2fc2
        src-mac:  70ca.9bce.ee24

ストレージ仕様問題

以前に論議される問題はデータおよび Storage Networking 両方によくあります。 完全を期すために、ストレージ エリア ネットワーク(SAN)に特定のパフォーマンス問題はまた述べられます。 ストレージ プロトコルは復元力と構築され、mutli 経路はまだ増加されます。 非対称的な論理ユニット 割り当て(ALUA)のようなテクノロジーの出現でおよび多重通路 IO (MPIO)、より多くの柔軟性およびオプション 管理者に示されます。

ストレージ 配置

もう一つの考慮事項はストレージの配置です。 FlexPod 設計はストレージが Nexus スイッチで接続されるべきであることを定めます。 直接接続されたストレージは CVD に合致しません。 直接接続されたストレージの設計は最良 の 方法が続かれる場合、サポートされます。 同時に、それらの設計は厳しく FlexPod ではないです。

最適パス選択

これはそれらのオプションのほとんどが Ciscoデバイスに対して透過的であるように、技術的に Cisco 問題ではないです。 それは最適パスに選び、スタックするべきよくある問題です。 現代デバイス特有のモジュール(DSM)はマルチパスおよび必要と示すことができます選ぶ最適物を このスクリーン ショットは Microsoft Windows およびロード バランシング オプションのために NetApp DSM に利用可能 な 4 つのパスを表示します。

推奨 設定はストレージ ベンダーとの説明に基づいて選ぶ必要があります。 それらの設定はパフォーマンス問題に影響を与えるかもしれません。 TAC が行うように頼むかもしれない典型的なテストはファブリック A かファブリックだけ B.を通って読み書きテストです。 これは一般的にこの資料の「よくある問題」セクションで説明されている状況にパフォーマンス問題を狭めることを可能にします。

VM および Hypervisor トラフィック共有

このポイントはベンダーに関係なく計算コンポーネントに特定、です。 計算観点からの hypervisors 設定する簡単な方法は 2 個のホスト バス アダプタ(HBAs)、各ファイバのための 1 をのためのストレージ ネットワークを作成することそれら二つのインターフェイス上のブート LUN トラフィックおよび Virtual Machine (VM) ストレージ両方トラフィックを実行します。 ブート LUN トラフィックおよび VM ストレージ トラフィックを分割することを常に推奨します。 これは方がパフォーマンスを可能にし、その上にトラフィックの 2 つの種類間の論理的な分割を可能にします。 例については「既知の問題」セクションを参照して下さい。

トラブルシューティングのヒント

問題を狭めて下さい

あらゆるファースト トラブルシューティングの場合にはように、問題を狭め、権限質問をすることは非常に重要です。

  • どのデバイス/applications/VM が(/not)影響を受けていますか。
  • どのストレージ コントローラが(/not)影響を受けていますか。
  • どのパスが(/not)影響を受けていますか。
  • どの位の割りで問題(/not)は現われますか。

Cisco

カウンター制限

このドキュメント インターフェイスでは、ASIC キューイング カウンターは説明されています。 カウンターはまた時点でビューを与えます、従ってカウンターの増加を監視することは重要です。 ある特定のカウンターは意図的にクリアすることができません。 たとえば、以前に述べられる carmel ASIC。

先の尖った例を与えるために、CRC の存在かインターフェイスの破棄は理想的ではないかもしれませんが値がゼロ以外であることが期待されるかもしれません。 カウンターは遷移か初期セットアップの間にある時点で、可能性のある上がったかもしれません。 それ故に最後はあったときにカウンターの増加に注意することは重要それらクリアされましたであり。

コントロール プレーン考慮事項

カウンターを検討することは役立っている間、ある特定のデータ平面問題がコントロール プレーン カウンターおよびツールに容易なリフレクションを見つけないかもしれませんことを確認することは重要です。 先の尖った例として、ethanalyzer は UCS および Nexus 両方 5000 で利用可能の非常に役に立つツールです。 ただし、それはコントロール プレーン トラフィックしかキャプチャ しないことができます。 トラフィック キャプチャはエラーがあるところに特にそれがクリアのとき TAC が頻繁に要求することです。

キャプチャ トラフィック

エンドホストで奪取 される信頼できるトラフィック キャプチャはかなり速くパフォーマンス問題の光を取除き、狭くすることができます。 Nexus 5000 および UCS オファー トラフィック SPAN 両方。 具体的には、UCS の SPANing 特定の HBAs のオプションおよびファブリック側は役立ちます。 UCS のセッションを監視するとき詳細をトラフィック キャプチャ capabilties について学ぶために、これらの参照を参照して下さい:

NetApp

NetApp はその中のストレージ コントローラを、解決するためにユーティリティの完全 セットを次のとおりです提供します:

  • perfstat -非常に有用なユーティリティは NetApp サポート 要員のために、一般的に動作します
  • 使用中ファイラがどのようにあり、ことをについてのファイラがしているか systat -情報を提供します- NetApp サポート ライブラリ

もっとも一般的なコマンド間にあります:

  • sysstat -x 2
  • sysstat -M 2

sysstat で探すいくつかの事柄は-出力される過剰にされた NetApp アレイかディスクを示すかもしれない x 2 ここにあります:

  • 多くの支えられた CP ty カラム: または F
  • 20% の上の支えられた HDD util カラム

この技術情報は NetApp を設定する方法を記述します: NetApp イーサネット ストレージ 最良 の 方法

  • VLAN タギング
  • VLANトランキング
  • ジャンボ MTU
  • IP ハッシュ
  • ディセーブル フロー制御

VMware

ESXi は解決できるセキュア シェル(SSH) アクセスを提供します。 管理者に提供されるほとんどの役に立つツールの間で esxtop および perfmon はあります。

既知の問題および機能拡張

  • Cisco バグ ID CSCuj86736 -受動 twinax ケーブル CRCエラーと…増加するかもしれないです。 これは Nexus 5000 が DFE を最適化しないとき引き起こされます。 「目高さ」パラメータが 100 mv の上にあることを確認するために show hardware 内部 carmel 目コマンドを入力して下さい。 これはリリース 5.2(1)N1(7) および 7.0(4)N1(1) で固定されました。
  • Cisco バグ ID CSCuo76425 - UCS ファブリックの前の不具合およびまた存在と相互接続します同じような。 これはリリース 2.2(3a) で固定されます。
  • Cisco バグ ID CSCuo76425 -煩わせる UCS ファブリック相互接続を除く CSCuj86736 同じ。
  • Cisco バグ ID CSCup40056 は仮想ファイバ チャネルアダプターによって-ユニファイド コンピューティング システム仮想マシン ライブ移行に説明がある VM トラフィックとブート トラフィックの共有によって引き起こされるタイミングに関する問題失敗します
  • 遅い下水管検出および無効化-頻繁に FC および FCoE は遅い下水管から影響を受けます。 NX-OS リリース 7.0(0)N1(1) はそれを検出する、避けるために手段(方法)を導入します。 詳細を Cisco Nexus 5500 シリーズ NX-OS インターフェイス コンフィギュレーション ガイドの機能について学び、下水管デバイス 検出および輻輳回避を遅らせて下さい
  • Cisco バグ ID CSCuj81245 - PALO で存在 する 制限はカードを(VIC1240 および他)その原因 FC アボート基づかせていました。
  • Cisco バグ ID CSCuh61202 他の問題は- 2.1(3)、UCS ファームウェア FC アボートおよび倍数をリリースするアップグレードの後で…見られる場合があります。
  • Cisco バグ ID CSCtw91018 -単一の PALO ベースのアダプタの VNICs の MTU設定のミックスによりいくつかのトラフィック クラスのための飢餓を引き起こす場合があります。
  • Cisco バグ ID CSCuq40256 はサーバアダプタに- PFC をファブリック相互接続からのリンクでディセーブルにします。 これにより Fibre Channel アボートから開始し、ストレージで報告される故障中の帯が味方する問題の変化を引き起こします。 ストレージ切断および他のパフォーマンス問題は報告されるかもしれません。 

TAC ケース

ケースの多数では、TAC エンジニアは調査が開始することができる前に基本情報を収集するように頼みます。

  • ポート番号およびラインスピードが含まれているトポロジーダイアグラム-、絶対に必要。
  • UCSM テクニカル サポート-テクニカルサポート ファイルを集める視覚ガイド(B および C シリーズ)。
  • 経験する 1 シャーシのための UCS シャーシ テクニカル サポート問題-前のリンクを参照して下さい。
  • UCS と NetApp 間の Nexus 両方 5000 テクニカル サポートおよび他のネットワークデバイス- show tech-support 詳細の出力をリダイレクトして命じて下さい
  • FIs の両方の show queueing interface コマンドの出力。
    connect nxos A|B
    show queuing interface | no-more
    show interface priority-flow-control | no-more
    show interface flowcontrol | no-more.
  • ESXi のホストドライバ バージョンは実行します-これらのコマンドを入力して下さい:
    • vmkload_mod - enic s
    • vmkload_mod -s fnic
  • Linux -
    dmesg | egrep -i 'enic|fnic'
  • Windows - 「デバイスマネージャ」のドライババージョンをチェックして下さい。  ウィンドウ 2012 R2 からの例は Cisco 3 つの VIC イーサネットインターフェイスおよび 4 つの VIC FCoE miniport インターフェイス(Fibre Channel にまた、だけでなく、FCoE 責任がある)および fnic ドライバのリリース 2.4.0.8 示したものです。

フィードバック

この資料または経験についてのフィードバックを提供するのに feedback ボタンを使用して下さい。 開発が発生する受け取られますアップデートし、ようにフィードバックの後で絶えずこの資料を。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 118362