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).
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.
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 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.
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.
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.
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.
Problemen die gemeenschappelijk zijn voor opslag en IP/Layer 2-netwerken worden in deze sectie besproken.
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.
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.
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.
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.
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 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.
De meeste moderne besturingssystemen bieden de mogelijkheid om een juiste jumboframes configuratie te testen met een eenvoudige ICMP-test (Internet Control Message Protocol).
9000 bytes - IP header zonder opties (20 bytes) - ICMP header (8 bytes) = 8972 bytes van gegevens
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
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.
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 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.
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:
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.
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.
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.
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:
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.
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.
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:
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
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.
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.
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.
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.
Zoals bij elke snelle probleemoplossing is het heel belangrijk om het probleem te vernauwen en de juiste vragen te stellen.
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.
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.
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:
NetApp biedt een volledige set hulpprogramma's om problemen op te lossen met hun opslagcontrollers:
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:
Dit artikel beschrijft hoe u NetApp moet configureren: NetApp Ethernet Storage Best Practices.
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.
In veel gevallen zal de TAC-ingenieur u vragen om basisinformatie te verzamelen voordat een onderzoek kan worden gestart.
connect nxos A|B
show queuing interface | no-more
show interface priority-flow-control | no-more
show interface flowcontrol | no-more.
dmesg | egrep -i 'enic|fnic'
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.