FlexPod-problemen met gemeenschappelijke prestaties

Inleiding

Dit document beschrijft gemeenschappelijke prestatieproblemen in FlexPod-omgevingen, biedt een methode om problemen met probleemoplossing op te lossen en biedt limiteringsstappen. Het is bedoeld als startpunt voor klanten die zich richten op de prestaties van probleemoplossing in een FlexPod-omgeving. Dit document is geschreven naar aanleiding van problemen die de afgelopen maanden zijn vastgesteld door het team van het Data Center Solutions Technical Assistance Center (TAC).

FlexPod-contentoverzicht

Een FlexPod bestaat uit een Unified Computing System (UCS)-computer, die via een Nexus-schakelaar wordt aangesloten op NetApp-opslag en IP-netwerken.

De meest voorkomende FlexPod bestaat uit een Cisco UCS B-Series chassis dat via Fabric Interconnect (FI’s) is aangesloten op Nexus 5500 switches naar NetApp-filters. Een andere oplossing, de FlexPod Express genoemd, gebruikt een UCS C-Series chassis dat is aangesloten op Nexus 3000-switches. Dit document behandelt de meest voorkomende FlexPod.

Prestatieoverwegingen

In complexe omgevingen met meerdere verantwoordelijke partijen zoals gewoonlijk in een FlexPod wordt gezien, moet u meerdere aspecten in overweging nemen om het probleem op te lossen. De typische prestatiesproblemen in Layer 2 en IP netwerken zouden voortkomen uit:

• Het verlies van stukjes of frame-bits leidt tot een negatief effect op de prestaties van toepassingen.
• Buffering - als een pakket of kader te veel tijd in een wachtrij of buffer doorbrengt, kunnen bepaalde implicaties voor de prestaties door toepassingen worden gezien, vooral in het geval van een opslagnetwerk. Problemen met latentie, herschikking en normalisatie vallen onder deze categorie.
• MTU's maken problemen en fragmentatie niet goed op elkaar af - een probleem dat veel voorkomt wanneer je hogere prestaties haalt. Kwesties die verband houden met fragmentatie en inconsistentie binnen de MTU vallen in deze categorie.

Omgeving

Het is belangrijk om de omgeving te kennen waarvoor de prestaties worden gemeten. Vragen over opslagtype en -protocol, evenals het besturingssysteem en de locatie van de getroffen server, moeten worden opgeworpen om het probleem goed te vernauwen. Een topologie-diagram dat connectiviteit beschrijft is het minimale.

meting

Je moet weten wat gemeten wordt en hoe het gemeten wordt. Bepaalde toepassingen, evenals de meeste opslagbedrijven en hypervisors, leveren metingen van een of ander soort die de prestaties/gezondheid van het systeem aangeven. Deze metingen zijn een goed punt om te beginnen aangezien zij geen vervanging zijn voor de meeste methodologieën voor probleemoplossing.

Als voorbeeld kan een NFS-opslaglatentiemeting (Network File System) in hypersupervisor erop wijzen dat de prestaties dalen, maar op zichzelf impliceert dit niet het netwerk. In het geval van een NFS, kan een eenvoudig pingelen van de gastheer aan het NFS netwerk van de opslag IP erop wijzen of het netwerk schuldig is.

Baseline

Dit punt kan niet genoeg worden benadrukt, vooral niet wanneer u een TAC-case opent. Om aan te geven dat de prestaties onbevredigend zijn, moet de gemeten parameter worden aangegeven. Dit omvat de verwachte en geteste waarde. Idealiter zou u vorige gegevens en de testmethode tonen die gebruikt is om die gegevens te bereiken.

Als voorbeeld; Een vertraging van 10 ms die werd bereikt bij testen, met alleen een schrijfmachine van één initiator naar één Logical Unit Number (LUN), is mogelijk geen indicatie van wat de vertraging zou moeten zijn voor een volledig geladen systeem.

Prestatieproblemen in een FlexPod

Aangezien dit document is bedoeld als referentie voor de meeste FlexPod-omgevingen, worden alleen de meest voorkomende problemen beschreven zoals die worden gezien door het TAC-team dat verantwoordelijk is voor Data Center Solutions.

Vaak voorkomende problemen

Problemen die gemeenschappelijk zijn voor opslag en IP/Layer 2-netwerken worden in deze sectie besproken.

Frame Relay- en pakketverlies

Frame- en pakketverlies is de meest frequente factor die de prestaties beïnvloedt. Een van de gemeenschappelijke plekken om aanwijzingen voor een probleem te vinden, is het interfaceniveau. Voer vanuit de Nexus 5000 of de UCS Nexus Operating System (NX-OS) CLI de show interface in | sec "omhoog" | egrep ^(Eth|FC)|teruggooi|droppen|CRC-opdracht. Voor interfaces die omhoog zijn, maakt het een lijst van de naam en gooit tellers en druppels weg. Op dezelfde manier wordt een groot overzicht weergegeven wanneer u de opdracht van de de show interface tellers fout ingaat die foutstatistieken voor alle interfaces toont.

Ethernet World

Het is belangrijk om te weten dat tellers op niet-0 misschien geen probleem kunnen aangeven. In bepaalde scenario's zouden deze tellers bij de eerste opzet of bij eerdere operationele veranderingen kunnen zijn gebracht. Een toename van de tellers dient te worden gecontroleerd.

Je kunt ook tellers op het ASIC-niveau verzamelen, wat indicatieve waarden kunnen zijn. Met name, voor de fout van de Cyclic Redundancy Control (CRC) op interfaces, is een TAC-favoriete opdracht om in te voeren, de hardware-inwendige carmel-crc. Carmel is de naam van de ASIC die verantwoordelijk is voor de verzending op het niveau van de haven.

Een soortgelijke uitvoer kan per poort worden genomen van 6100 Series FI's of Nexus 5600 switches. Voor de FI 6100, gatos ASIC, voer deze opdracht in:

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

Ga voor de Nexus 5600 vanuit bigsur ASIC naar deze opdracht: 

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

De opdracht voor karmel ASIC toont waar CRC-pakketten zijn ontvangen en waar ze naar zijn doorgestuurd, en, nog belangrijker, of ze al dan niet zijn weggespoeld.

Aangezien zowel Nexus 5000 als UCS NX-OS-bewerking is doorgesneden, worden de omschakeling van mode-frames met een incorrecte Frame Control Sequence (FCS) alleen gemaskeerd voordat u doorsturen. Het is belangrijk om uit te vinden waar de gecorrumpeerde frames vandaan komen. 

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 |

In dit voorbeeld worden pakketten met stomp weergegeven die van Eth 1/17 en Eth 1/18 komen, wat een uplink naar de Nexus 5000 is. Je kan ervan uitgaan dat die frames later werden verzonden naar Tabel 1/34, zoals Eth 1/17 + Eth 1/18 rx Stomp = Eth 1/34 tx Stomp.

Een gelijkaardige blik op de Nexus 5000 shows:

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 |        --- |        --- |        --- |

Deze uitvoer toont CRC's die op twee koppelingen zijn ontvangen en als stompen zijn gemarkeerd voordat u het verzenden. Zie de Handleiding voor probleemoplossing Nexus 5000.

Fibre Channel World

Een makkelijke manier om naar druppels te zoeken (weggooien, fouten, CRC's, B2B uitputting) is via de opdracht van de showinterface tellers.

Deze opdracht, beschikbaar op Nexus 5000 en Fabric Interconnect, geeft een goede indicatie van wat er gebeurt in de Fibre Channel-wereld. 

Bijvoorbeeld:

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
(...)

Deze interface is niet bezig en de output toont dat er geen fouten of fouten zijn gemaakt. 

Daarnaast werd de nadruk gelegd op B2B-kredietoverboekingen van 0; vanwege Cisco bug-ID’s CSCue80063 en CSCut08353, kunnen deze tellers niet worden vertrouwd. Ze werken prima op Cisco MDS, maar niet op de UCS van Nexus5k-platforms. U kunt ook Cisco bug-ID CSCsz9589 controleren. 

Op dezelfde manier als bij verbranding in Ethernet world voor Fibre Channel (FC) kan de FC-mac-faciliteit worden gebruikt. Als voorbeeld, voor port FC2/1, voer de show hardware interne FC-mac 2 port 1 statistics opdracht in. De aangeboden tellers zijn in hexadecimale vorm.

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

De output laat 15 teruggooi zien bij invoer. Dit kan worden gevonden in FCP_CNTR_PIF_RX_DROP die is geteld op 0xf (15 in decimale volgorde). Deze informatie kan opnieuw worden gecorreleerd aan informatie van FWM (Forwarding Manager).

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

Dit geeft de beheerder echter het aantal druppels en het corresponderende ASIC-nummer. De informatie over de reden van die ingetrokken ASIC moet worden opgevraagd.

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]

In dit geval werd het verkeer gedropt door de toegangscontrolelijst (ACL), doorgaans in FC World - zoning.

MTU-wanverhouding

In FlexPod-omgevingen is het belangrijk om de end-to-end Maximum Transition Unit (MTU) instelling voor toepassingen en protocollen aan te passen waar deze nodig is. In het geval van de meeste omgevingen, is dit Fibre Channel over Ethernet (FCoE) en jumboframes.

Daarnaast moeten, indien fragmentatie optreedt, verminderde prestaties worden verwacht. In het geval van protocollen zoals Network File System (NFS) en Internet Small Computer System Interface (iSCSI), is het belangrijk om end-to-end IP Max Transmission Unit (MTU) en TCP Maximum Segment Size (MSS) te testen en te bewijzen.

Of u nu jumboframes of FCoE probleemoplossing hebt, is het belangrijk om in gedachten te houden dat beide soorten CoS-markering (consistente configuratie en Class of Service) over het hele milieu nodig hebben om correct te kunnen werken.

In het geval van UCS en Nexus wordt er een opdracht die handig is om de per-interface te valideren, per QoS-groep MTU-instelling een wachtrij-interface getoond | In de wachtrij |qos-groep|MTU.

MTU-display op Nexus 5000- en UCS-platforms

Een bekend aspect van zowel UCS als Nexus is de weergave van MTU's op de interface. Deze uitvoer demonstreert een interface die is geconfigureerd om in de rij Jumboframes en FCoE te zetten:

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)

Tegelijkertijd geeft de opdracht interface-opdracht 1500 bytes weer:

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

In vergelijking met de ASIC-informatie over karmel toont de ASIC de MTU-capaciteit van een bepaalde haven.  

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

Deze MTU mismatch in display wordt op de genoemde platforms verwacht en kan neophyten misleiden.

End-to-end configuratie

End-to-end consistente configuratie is de enige manier om goede prestaties te garanderen. De configuratie en stappen van de Jumboframes voor Cisco-zijde en VMware ESXi worden beschreven in UCS met VMware ESXi end-to-end Jumbo MTU Configuration Voorbeeld.

UCS FCoE Uplink Configuration Voorbeeld toont een UCS en Nexus 5000-configuratie. Zie Bijlage A in het referentiedocument voor een overzicht van de basisconfiguratie van Nexus 5000.

Stel FCoE Connectivity in voor een Cisco UCS Blade die zich op UCS-configuratie voor FCoE richt. Nexus 5000 NPIV FCoE met FCoE NPV Bijgevoegd UCS Configuration Voorbeeld focust op de Nexus-configuratie.

End-to-end Jumboframes testen

De meeste moderne besturingssystemen bieden de mogelijkheid om een juiste jumboframes configuratie te testen met een eenvoudige ICMP-test (Internet Control Message Protocol).

Berekening

9000 bytes - IP header zonder opties (20 bytes) - ICMP header (8 bytes) = 8972 bytes van gegevens

Opdrachten in populaire besturingssystemen

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

Problemen met Buffer

Buffering en andere met latentie samenhangende problemen behoren tot de gemeenschappelijke oorzaken van de verslechtering van de prestaties in de FlexPod-omgeving. Niet alle problemen die worden gemeld als 'latency' vloeien voort uit feitelijke bufferproblemen, maar veel metingen kunnen duiden op end-to-end latentie. In het geval van NFS kan de gerapporteerde periode bijvoorbeeld nodig zijn om met succes te kunnen lezen/schrijven naar opslag en niet naar echte netwerklatentie.

Congestie is de meest voorkomende oorzaak van buffering. In Layer 2 wereld kan stremming bufferen en zelfs druppels frames veroorzaken. Om tijdens stremming-periodes watervallen te voorkomen, werden de IEEE 802.3x-pauzekaders en de Priority Flow Control (PFC) geïntroduceerd. Vertrouwen beide op het vragen van het eindpunt om transmissies een korte tijd vast te houden terwijl de congestie aanhoudt. Dit kan worden veroorzaakt door netwerkcongestie (overweldig de ontvangen met hoeveelheid gegevens) of omdat een geprioriteerd frame moet doorlopen, zoals in het geval van FCoE.

Flow Control - 802.3x

Om te verifiëren welke interfaces stroomcontrole toegelaten hebben, voer de opdracht van de show debietcontrole in. Het is van belang de aanbeveling van de opslagverkoper te volgen wat betreft het mogelijk maken van stroomcontrole.

Hier wordt een illustratie weergegeven die toont hoe het 802.3x-debietcontrolesysteem werkt.

PFC - 802.1QB

PFC is niet vereist voor alle instellingen, maar wordt voor de meeste instellingen aanbevolen. Om te verifiëren welke interfaces PFC hebben toegelaten, de show interface prioriteit-flow-control | I On commando kan uitgevoerd worden op de UCS NX-OS en Nexus 5000. 

De interfaces tussen de FI's en de Nexus 5000 moeten op die lijst zichtbaar zijn. Zo niet, dan moet de QoS-configuratie worden geverifieerd. QoS moet consistent end-to-end zijn om voordeel te halen uit PFC. Om te controleren waarom de PFC niet op een bepaalde interface komt, voer het systeem interne dcbx-loginterface Ethernet x/y-opdracht in om het Data Center Bridging Capilities Exchange Protocol (DCBX) te verkrijgen.

Een illustratie die laat zien hoe pauzekaders met PFC werken, wordt hier weergegeven.

De opdracht prioritair-flow-control tonen staat de beheerder toe om het per-QoS klassegedrag van prioriteitspauzekaders te waarnemen. 

Hier is een voorbeeld:

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)

Deze uitvoer toont aan dat, in tweede klasse, het apparaat net een PPP kader (TX) overbracht. 

In dit geval, is Ethernet 1/1 haven die aan IOM is gericht en terwijl de algemene haven niet PFC zal hebben toegelaten, zou het PPP frames voor FEX poorten kunnen verwerken. 

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

In dit geval zijn FEX-interfaces betrokken. 

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 

De FEX-poorten die hierbij betrokken zijn, kunnen ook worden gecontroleerd via show fex detaillist waar X het chassis nummer is. 

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

Zie deze documenten voor meer informatie over pauzemechanismen. 

• Fibre Channel over Ethernet-bewerkingen
• Unified Fabric White Paper-Fibre Channel over Ethernet (FCoE)

Wachtrijen

Zowel de Nexus 5000 als de UCS NX-OS houden het spoor van teruggooi door in de wachtrij te plaatsen op basis van QOS-groepen. Bijvoorbeeld:

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)

Ingreress moet alleen in wachtrijen worden geplaatst, zodat de items kunnen vallen.

Vluchtelingen in de wachtrij kunnen om deze redenen voorkomen:

• Switched Port Analyzer (SPAN)/bewakingssessie ingeschakeld op sommige interfaces (zie Cisco bug ID CSCur25521)
• Achterdruk vanuit een andere interface worden pauzeknopen normaal gezien wanneer ze ingeschakeld zijn
• Verkeersniveau naar de CPU’s 

Stuurprobleem

Cisco biedt twee besturingssysteemstuurprogramma’s voor UCS, enisch en snel. Enic is verantwoordelijk voor de Ethernet-connectiviteit en -verbinding, is verantwoordelijk voor de Fibre Channel- en FCoE-connectiviteit. Het is erg belangrijk dat enische en bovendrijvende bestuurders precies zijn zoals aangegeven in de UCS interoperabiliteitsmatrix. Problemen die door onjuiste chauffeurs worden geïntroduceerd variëren van pakketverlies en extra latentie tot een langer laars proces of compleet gebrek aan connectiviteit.

Adapter-informatie

Een door Cisco meegeleverde adapter kan een goede meting leveren van het verkeer dat wordt doorgegeven, evenals druppels. Dit voorbeeld toont hoe te verbinden met chassis X, server Y, en adapter 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.

Vanaf hier kan de beheerder inloggen bij de MCP-faciliteit (Monitoring Center for Performance).

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

Met de MCP-faciliteit kunt u gebruik van verkeer per logische interface (LIF) bewaken. 

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   

Chassis 1, sever 1 en adapter 1 hebben twee Virtual Network Interface Cards (VNIC's) gekoppeld aan virtuele interfaces (Virtual Ethernet of Virtual Fibre Channel) 834 en 836. Deze hebben de nummers 2 en 3. De statistieken voor LIF 2 en 3 kunnen worden gecontroleerd zoals hieronder wordt getoond:

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

Het is belangrijk op te merken dat de beheerder van UCS de totale en delta-kolommen (tussen twee opeenvolgende executies van levens), de huidige verkeersbelasting per LIF en informatie over eventuele fouten heeft ontvangen.

Het vorige voorbeeld toont interfaces zonder fouten met een zeer kleine lading. Dit voorbeeld toont een andere server.

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

Twee interessante bits informatie laten zien dat 96 frames door de adapter zijn gevallen vanwege een gebrek aan buffer of het bufferen van uitgeschakeld en daarnaast TCP Segment Offloading (TSO)-segmenten die werden verwerkt.

Logische pakketstroom

In het onderstaande schema wordt een logische pakketstroom in een FlexPod-omgeving beschreven.

Dit diagram is bedoeld als een uitsplitsing van componenten in een kader dat op weg via de FlexPod-omgeving wordt doorgegeven. Het is geen weerspiegeling van de complexiteit van een van de blokken en is slechts een manier om te onthouden waar specifieke kenmerken moeten worden geconfigureerd en geverifieerd. 

I/O-module

Zoals in het logische pakketstroomschema wordt aangegeven, is de I/O-module (IOM) een onderdeel in het midden van alle communicatie die door de UCS gaat. Voer de verbindingsiom x-opdracht in om verbinding te maken met de IOM in chassis X.

Hier zijn verschillende andere nuttige opdrachten:

• Topologische informatie - de opdracht van de toonplatformsoftware [woodside|redwood] toont topologische informatie vanuit het oogpunt van de IOM.

  

  Het laat netwerkinterfaces (NI's) zien die tot FI's leiden, in dit geval zijn er acht, met er vier omhoog. Daarnaast bevat het host interfaces (HI's) die binnen het chassis naar bepaalde blades leiden.

• Verkeerssnelheid - de opdracht platformsoftware [woodside|redwood] wordt gebruikt om de snelheid van het verkeer te controleren die door de HI interfaces passeert zodra de topologie en de HI interface aan Blade mapping bekend is.

  

• Verkeersverlies - voer de verliesopdracht van de showplatform software [woodside|redwood] in. De uitvoering van deze opdracht stelt de verliesposten op. Hiermee kunt u pauzekaders zien en op een per-interface-basis vallen.

  

  Wegens de manier waarop de onderliggende infrastructuur werkt, worden de tellers slechts getoond voor interfaces die enig verlies tussen de uitvoering van de twee opdrachten hebben ervaren.  In dit voorbeeld zie je dat de NI2-interface 82 pauzoframes ontving en dat 28 pauzefkaders werden doorgegeven naar interface HI23, waarvan je weet dat het is aangesloten op mes 3.

Ontwerpoverwegingen

Een FlexPod staat voor een flexibele configuratie en het instellen van opslag- en datanetwerken toe. Met flexibiliteit komen ook extra uitdagingen. Het is van cruciaal belang om documenten met beste praktijken en een Cisco gevalideerd ontwerp (CVD) te volgen:

• CVD - FlexPod-implementatiegids
• NetApp-opslagoptimale werkwijzen (niet specifiek voor FlexiPoD) - Cisco Unified Computing System (UCS) Opslagconnectiviteitsopties en beste praktijken voor NetApp-opslag

Selectie van poortsnelheid en poortkanaaloverwegingen

Een algemeen probleem dat door TAC engineers wordt gezien, is overbenutting van links door de selectie van 1 Gigabit Ethernet in plaats van 10 Gigabit Ethernet waarnaar in best practice-documenten wordt verwezen. Als duidelijk voorbeeld zullen single flow performance niet beter zijn op tien 1 Gbit links dan op één 10 Gbit link. In poortkanalen kan één enkele stroom over één enkele verbinding gaan. 

Om te weten te komen welke load-balances methode wordt gebruikt op Nexus en/of NX-OS van FI, voer de opdracht van de taakverdeling in het havenkanaal in. De beheerder kan ook uitvinden welke interface in een havenkanaal als uitgaande interface voor een pakket of een kader zal worden geselecteerd. Een eenvoudig voorbeeld van een kader op VLAN49 tussen twee hosts wordt hier getoond:

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

Opslagspecifieke problemen

De eerder besproken problemen zijn zowel gemeenschappelijk voor gegevens- als opslagnetwerken. Ter wille van de volledigheid worden ook de prestatieproblemen genoemd die specifiek zijn voor Storage Area Network (SAN). Opslagprotocollen werden gebouwd met veerkracht en gemuilpaden worden nog steeds uitgebreid. Dankzij technologieën zoals Asymmetric Logical Unit Assignation (ALUA) en Multi-Path IO (MPIO) worden er meer flexibiliteit en opties aan beheerders voorgesteld.

Opslagplaats

Een andere overweging is de opslag. Een FlexPod ontwerp dicteert dat de opslag op Nexus switches moet worden aangesloten. De direct aangesloten opslag voldoet niet aan CVD. Ontwerpen met rechtstreeks aangesloten opslag worden ondersteund, indien de beste praktijken worden gevolgd. Tegelijkertijd zijn deze ontwerpen niet strikt FlexPod.

Optimale selectie pad

Dit is technisch geen probleem van Cisco, aangezien de meeste van deze opties transparant zijn voor Cisco-apparaten. Het is een gebruikelijk probleem om een optimaal pad te kiezen en aan te houden. Een moderne apparaatspecifieke module (DSM) kan met meerdere paden worden aangeboden en moet een optimale module(s) kiezen, op basis van bepaalde criteria om te zorgen voor veerkracht en taakverdeling. Dit screenshot toont vier paden beschikbaar voor NetApp DSM voor Microsoft Windows en opties voor het taakverdeling.

De aanbevolen instellingen moeten worden gekozen op basis van een discussie met de opslagverkoper. Deze instellingen kunnen prestatieproblemen beïnvloeden. Een typische test die de TAC u zou kunnen vragen om uit te voeren is een lees-schrijftest die alleen materiaal A of stof B bevat. Hierdoor kunt u doorgaans prestatieproblemen beperken tot situaties die worden besproken in het gedeelte "Gemeenschappelijke problemen" van dit document.

VM en hypervisors traffic shaping

Dit punt is specifiek voor de berekende component, ongeacht de verkoper. Een makkelijke manier om een opslagnetwerk voor hypervisors op te zetten vanuit computerstandpunt is om twee Host Bus Adapters (HBA's) te creëren, één voor elke Fibre, en om zowel het LUN-verkeer als het VM-opslagverkeer (Virtual Machine) via deze twee interfaces te starten. Het wordt altijd aanbevolen het LUN-opstart- en VM-opslagverkeer te splitsen. Dit maakt betere prestaties mogelijk en maakt bovendien een logische scheiding tussen de twee soorten verkeer mogelijk. Zie het gedeelte "Known Issues" voor een voorbeeld.

Tips voor probleemoplossing

Het probleem verminderen

Zoals bij elke snelle probleemoplossing is het heel belangrijk om het probleem te vernauwen en de juiste vragen te stellen.

• Welke apparaten/toepassingen/VM worden (of niet) beïnvloed?
• Welke opslagcontroller wordt (of niet) aangetast?
• Welke paden worden (of niet) aangetast?
• Hoe vaak verschijnt het probleem (of niet)?

Cisco

Tegenbeperkingen

In deze documentinterface worden ASIC-wachttellers besproken. De telers geven ook een mening op een bepaald moment, dus het is belangrijk om de toename van tellers te controleren. Bepaalde tellers kunnen niet door ontwerp worden gewist. Zo werd de reeds genoemde karmel ASIC genoemd.

Om een duidelijk voorbeeld te geven is de aanwezigheid van CRC of teruggooi op een interface misschien niet ideaal, maar er kan wel worden verwacht dat hun waarden niet-nul zijn. De tellers hadden op een bepaald moment in tijd kunnen stijgen, misschien tijdens transitie of eerste opstelling. Daarom is het belangrijk om op te merken dat de telers zijn toegenomen en wanneer was het de laatste keer dat zij werden geklaard.

Overwegingen bij besturingsplane

Hoewel het nuttig is om tellers te herzien, is het belangrijk te weten dat bepaalde gegevensvliegtuigproblemen geen gemakkelijke reflectie kunnen vinden om vliegtuigtellers en -gereedschappen te controleren. Zoals een duidelijk voorbeeld is de ethanalyzer een zeer nuttig instrument dat beschikbaar is voor zowel UCS als Nexus 5000. Het kan echter alleen het verkeer van het besturingsplane vangen. De TAC vraagt vaak om een verkeersopname, vooral als niet duidelijk is waar de fout ligt.

Opname van verkeer

Een betrouwbare verkeersopname die op de eindhosts wordt genomen, kan licht werpen op een prestatiekort en het vrij snel verminderen. Zowel de Nexus 5000 als de UCS bieden traffic shaping aan. Met name de SPAN-opties van UCS voor bepaalde HBA's en stoffen zijkanten zijn nuttig. Om meer te weten te komen over de mogelijkheden van de verkeersopname wanneer u een sessie op UCS controleert, zie deze verwijzingen:

• UCS Traffic Analysis voor fysieke en virtuele adapters (video)
• Cisco UCS Manager GUI-configuratiegids - bewaking van verkeer

NetApp

NetApp biedt een volledige set hulpprogramma's om problemen op te lossen met hun opslagcontrollers:

• perfstat, een zeer bruikbaar programma, dat doorgaans wordt uitgevoerd voor NetApp-ondersteunend personeel
• systat - geeft informatie over hoe druk het bestand is en wat het filter doet - NetApp Support Library

Er zijn één van de meest voorkomende opdrachten:

• sysstat -x 2

• sysstat -M 2

Dit zijn een aantal dingen die je kunt vinden in sysstat -x 2 uitvoer die mogelijk duiden op een overbelaste NetApp array of schijven:

• Aanhoudende CP-kolom met veel woorden: of F
• Aanhoudende HDD tot kolom boven 20%

Dit artikel beschrijft hoe u NetApp moet configureren: NetApp Ethernet Storage Best Practices.

• VLAN-markering
• VLAN-trunking
• Jumbo MTU
• IP-switching
• FlowControl uitschakelen

VMware

ESXi biedt Secure Shell (SSH) toegang, waardoor u problemen kunt oplossen. Onder de meest bruikbare gereedschappen die aan beheerders worden geboden, zijn esxtop en perfmon.

• XEXP - net als Linux/BSD-top, stelt dit gebruikers in staat om realtime prestatiegerelateerde parameters te controleren
  Gebruik van esxtop om problemen met opslagprestaties voor ESX / ESXi te identificeren
• Hierdoor kunnen gebruikers problemen oplossen bij Microsoft Windows Virtual Machines (VM)
  Het verzamelen van de Perfmon van Windows gegevens om de prestatiekwesties van de virtuele machine te diagnosticeren
• Monteer een diagnostische bundel op ESXi - Verzamelen van diagnostische informatie voor VMware ESX/ESXi met behulp van de vSphere-client (653)
• VVMware vSwitch-taakverdeling voor Cisco B-Series servers - Routegebaseerd op IP-hash wordt niet ondersteund met Cisco UCS B200 M1/M2-bladeservers die gebruik maken van UCS 6100 Series fabric interconnects 

Bekende problemen en verbeteringen

• Cisco bug-ID CSCuj86736 - met passieve twinax-kabels kan het aantal CRC-fouten toenemen. Dit wordt veroorzaakt wanneer Nexus 5000 DFE niet optimaliseert. Voer de interne opdracht hardware-carmel-oog in om te controleren of de "Ooghoogte"-parameter hoger is dan 100 mv. Dit is vastgesteld in releases 5.2(1)N1(7) en 7.0(4)N1(1).
• Cisco bug-ID CSCuo76425 - vergelijkbaar met de vorige bug en ook aanwezig op de UCS-verbindingen. Dit is vastgelegd in release 2.2(3a).
• Cisco bug-ID CSCuo76425 - hetzelfde als bug-CSCuj86736, behalve voor UCS Fabric Interconnect.
• Cisco bug-ID CSCup40056 - timing-probleem veroorzaakt door het delen van laars met VM-verkeer dat is beschreven in Unified Computing System Live-migratie met virtuele Fibre Channel-adapters.
• Langzame afvoerdetectie en -vermijding - zeer vaak worden FC en FCoE beïnvloed door langzame afvoer. NX-OS release 7.0(0)N1(1) introduceert middelen om deze te detecteren en te vermijden. Leer meer over de optie in Cisco Nexus 5500 Series NX-OS interfacehandleiding en Snel afvoerapparaat voor detectie en congestievermijding.
• Cisco bug-ID CSCuj81245 - een beperking bestaat in PALO-gebaseerde kaarten (VIC1240 en andere kaarten) die FC-abortussen veroorzaken.
• Cisco bug-ID CSC61202 - na het upgraden naar release 2.1(3) kunt u UCS FC-software en meerdere andere problemen zien.
• Cisco bug-ID CSCtw91018 - een combinatie van MTU-instellingen voor VNIC's op één adapter op basis van PALO kan hongersnood veroorzaken voor sommige verkeersklassen.
• Cisco bug-ID CSCuq40256 - zal ervoor zorgen dat PFC wordt uitgeschakeld aan koppelingen van Fabric Interconnect naar serveradapters. Dit zal vele problemen veroorzaken die beginnen met de abortus van Fibre Channel en de out-of-order frames die aan de opslagkant zijn gemeld. Opslaginterconnects en andere prestatieproblemen kunnen worden gemeld. 

TAC-gevallen

In veel gevallen zal de TAC-ingenieur u vragen om basisinformatie te verzamelen voordat een onderzoek kan worden gestart.

• Topologisch diagram - dat poortnummers en lijnsnelheden omvat, absoluut noodzakelijk.
• UCSM technische ondersteuning - Visual Guide om technische ondersteuningsbestanden te verzamelen (B- en C-serie).
• UCS chassis technische ondersteuning voor één chassis dat problemen ervaart - zie vorige link.
• Zowel technische ondersteuning van Nexus 5000 als alle andere netwerkapparaten tussen UCS en de NetApp - omleidingsuitvoer van de opdracht technische ondersteuning van show.
• Uitvoer van het opdracht showwachtrij voor beide FI's.

  connect nxos A|B
  show queuing interface | no-more
  show interface priority-flow-control | no-more
  show interface flowcontrol | no-more.

• Host driver versies op de ESXi voeren in - voer deze opdrachten in:
  • vmkload_mod -s enic
  • vmkload_mod -s fnic
• Linux -

  dmesg | egrep -i 'enic|fnic'

• Windows - controleer de versie van het stuurprogramma in "device Manager".  Een voorbeeld uit venster 2012 R2 toont drie Cisco VIC Ethernet-interfaces en vier VIC FCoE mini-interfaces (ook verantwoordelijk voor Fibre Channel, niet alleen FCoE) en release 2.4.0.8 van het etnische stuurprogramma.

  

Feedback

Gebruik de feedback-knop om feedback over dit document of uw ervaringen te geven. We zullen dit document voortdurend bijwerken naarmate de ontwikkelingen zich voordoen en na ontvangst van feedback.