Este documento describe los problemas de rendimiento comunes en los entornos de FlexPod, proporciona a un método para resolver problemas los problemas, y proporciona a los pasos de la mitigación. Se piensa como punto de partida para los clientes que miran para resolver problemas el funcionamiento en un entorno de FlexPod. Este documento fue escrito como resultado de los problemas considerados por el equipo del Centro de Asistencia Técnica (TAC) de las soluciones del centro de datos estos últimos meses.
Un FlexPod consiste en un ordenador del sistema de la Computación unificada (UCS) conectado vía un conmutador del nexo con el almacenamiento de NetApp y las redes IP.
El FlexPod más común consiste en un chasis de las B-series de Cisco UCS conectado vía la tela interconecta (FIs) a los 5500 Switch del nexo a los limadores de NetApp. Otra solución, llamada el FlexPod expreso, utiliza un chasis de la serie C UCS conectado con los 3000 Switch del nexo. Este documento discute el FlexPod más común.
En los entornos complejos con los partidos responsables del múltiplo según lo visto típicamente en un FlexPod, usted necesita considerar los aspectos múltiples para resolver problemas el problema. Los problemas de rendimiento típicos en la capa 2 y las redes IP provendrían:
Es importante conocer el entorno para el cual se mide el funcionamiento. Las preguntas sobre el tipo y protocolo del almacenamiento, así como el sistema operativo del servidor afectado (OS) y la ubicación, se deben aumentar para estrechar correctamente el problema abajo. Un Diagrama de topología que resume la Conectividad es el mínimo.
Usted necesita conocer se mide qué y se mide cómo él. Ciertas aplicaciones, así como la mayoría de los vendedores del almacenamiento y del hipervisor, proporcionan a las medidas de una cierta clase que indican el funcionamiento/la salud del sistema. Estas medidas son una buena punta a comenzar en pues no son un substituto para la mayoría de las metodologías del troubleshooting.
Como un ejemplo, una medida del tiempo de espera del almacenamiento del Network File System (NFS) en el hipervisor pudo indicar que va el funcionamiento abajo, no obstante en sus los propio no implica la red. En el caso de un NFS, un ping simple del host a la red IP del almacenamiento NFS pudo indicar si la red es culpar.
Esta punta no se puede subrayar bastantes, especialmente cuando usted abre un caso de TAC. Para indicar que el funcionamiento es insatisfactorio, el parámetro medido necesita ser indicado. Esto incluye el valor previsto y probado. Idealmente, usted debe mostrar los datos anteriores y la metodología de prueba usada para alcanzar esos datos.
Como un ejemplo; el tiempo de espera 10ms alcanzado cuando estaba probado, con una escritura-solamente de un solo iniciador a un solo número de unidad lógica (LUN), no pudo ser indicativo de lo que se supone el tiempo de espera para estar para completamente un sistema cargado.
Puesto que este documento se piensa como referencia para la mayoría de los entornos de FlexPod, resume solamente la mayoría de los problemas frecuentes como considerado por el Equipo del TAC responsable de las soluciones del centro de datos.
Los problemas comunes al almacenamiento y las redes IP/Layer 2 se discuten en esta sección.
El capítulo y la pérdida del paquete es el factor más frecuente ese funcionamiento de los impactos. Uno de los lugares comunes para buscar las indicaciones de un problema está en el nivel de la interfaz. Del nexo 5000 o del sistema operativo del nexo UCS (NX-OS) CLI, ingrese el interfaz de la demostración | el sec “está encima de” | ^ del egrep (Eth|fc)|deseche|descenso|Comando crc. Para los interfaces que están para arriba, enumera el nombre y desecha los contadores y los descensos. Semejantemente, se visualiza una gran descripción cuando usted ingresa el comando error de los contadores de la interfaz de la demostración que muestra las estadísticas del error para todos los interfaces.
Es importante saber que los contadores en non-0 no pudieron indicar un problema. En ciertos decorados esos contadores se pudieron haber aumentado en la disposición inicial o en los cambios operativos anteriores. Un aumento de los contadores debe ser vigilado.
Uno puede también recolectar los contadores de ASIC llano, que pudieron ser más indicativa. Específicamente, para el error del control de la redundancia cíclica (CRC) en los interfaces, un comando preferido TAC de ingresar es el carmel interno crc de la dotación física de la demostración. Carmel es el nombre de ASIC responsable de la expedición del puerto-nivel.
La salida similar se puede tomar de las 6100 Series FIs o de los 5600 Switch del nexo en una basada en cada puerto. Para el FI 6100, los gatos ASIC, ingresan este comando:
show hardware internal gatos port ethernet X/Y | grep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"
Para el nexo 5600, del bigsur ASIC, ingrese este comando:
show hardware internal bigsur port eth x/y | egrep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"
El comando para el carmel ASIC muestra donde se han recibido los paquetes CRC y al donde se han remitido, y lo que es más importante si se han pisado fuerte o no.
Puesto que el nexo 5000 y la operación UCS NX-OS está corte-por, los marcos del modo que cambian con la Secuencia de verificación de tramas (FCS) incorrecta se pisan fuerte solamente antes de remitir. Es importante descubrir de adónde los marcos corrompidos vienen.
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 |
Este ejemplo muestra los paquetes pisados fuerte que vienen de Eth 1/17 y Eth 1/18, que es uplink al nexo 5000. Uno puede asumir que esos marcos fueron enviados después abajo a Eth 1/34, tal como Eth 1/17 + Eth que pisa fuerte 1/18 rx = Eth pisa fuerte 1/34 tx.
Una mirada similar en el nexo 5000 muestra:
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 | --- | --- | --- |
Esta salida muestra que los CRCs recibidos en dos links y marcados como pisa fuerte antes de remitir. Para más información, vea el guía de Troubleshooting del nexo 5000.
Un método simple de buscar los descensos (discrds, error, los CRCs, agotamiento del crédito de B2B) está vía el comando del fc de los contadores de la interfaz de la demostración.
Este comando, disponibles en los nexos 5000 y la interconexión de la tela, da una buena indicación de qué sucede en el mundo del canal de la fibra.
Por ejemplo:
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
(...)
Este interfaz no está ocupado, y la salida muestra que sucedieron ningunos descartes o error.
Además, las transiciones del crédito de B2B a partir de la 0 fueron destacadas; debido a los ID de bug CSCue80063 y CSCut08353 de Cisco, esos contadores no pueden ser confiados en. Trabajan muy bien en Cisco MDS, pero no en el UCS de las Plataformas Nexus5k. También usted puede verificar el ID de bug CSCsz95889 de Cisco.
Semejantemente al carmel en el mundo de los Ethernetes para el canal de la fibra (FC) el recurso del fc-mac puede ser utilizado. Como un ejemplo, para el puerto fc2/1, ingresa el comando statistics interno del puerto 1 del fc-mac 2 de la dotación física de la demostración. Los contadores presentados están en el formato hexadecimal.
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
La salida muestra 15 descartes en la entrada. Esto se puede corresponder con a FCP_CNTR_PIF_RX_DROP que contó a 0xf (15 en el decimal). Esta información se puede correlacionar otra vez a la información FWM (encargado de la expedición).
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
Sin embargo, este tellls el administrador la cantidad de descensos y que es el número correspondiente de ASIC. La información del conseguir sobre la razón de eso cayó las necesidades de ASIC de ser preguntado.
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]
En este caso, el tráfico fue caído por la lista de control de acceso (ACL) del ingreso, típicamente en el mundo FC - Establecimiento de zonas.
En los entornos de FlexPod es importante acomodar la configuración máxima de punta a punta de la unidad de la transición (MTU) para las aplicaciones y los protocolos donde se requiere. En el caso de la mayoría de los entornos, éste es canal de la fibra sobre los Ethernetes (FCoE) y las Tramas gigantes.
, Ocurre la fragmentación, el rendimiento disminuido debe además ser esperado. En caso de los protocolos tales como Network File System (NFS) y Interfaz de sistema informático reducida de Internet (iSCSI), es importante probar y probar el tamaño de punta a punta del Maximum Transmission Unit IP (MTU) y del segmento máxima TCP (MSS).
Si usted resuelve problemas las Tramas gigantes o FCoE, es importante recordar que ambos ésos necesitan la configuración constante y el Clase de Servicio (CoS) que marcan a través del entorno para actuar correctamente.
En el caso del UCS y del nexo, un comando que es útil para validar el por-interfaz, por la configuración de MTU del QoS-grupo es interfaz de Datos en espera de la demostración | i que hace cola|qos-grupo|MTU.
Un aspecto sabido del UCS y del nexo es la visualización de MTUs en el interfaz. Esta salida demuestra un interfaz configurado para hacer cola las Tramas gigantes y 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)
Al mismo tiempo, el comando show interface visualiza 1500 bytes:
bdsol-6248-06-A(nxos)# show int e1/1 | i MTU
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec
Si está comparado a ASIC del carmel la información, ASIC muestra la capacidad MTU de un puerto dado.
show hardware internal carmel port ethernet 1/1 | egrep -i MTU
mtu : 9260
Esta discordancía MTU en la visualización se espera en las Plataformas ya mencionadas, y podría potencialmente engañar a los neófitos.
La configuración constante de punta a punta es la única forma de garantizar el funcionamiento apropiado. Las Tramas gigantes configuración y pasos para el lado de Cisco, así como VMware ESXi, se describen en el UCS con el ejemplo de punta a punta de la configuración MTU del jumbo de VMware ESXi.
El UCS FCoE Uplink el ejemplo de la configuración muestra una configuración UCS y del nexo 5000. Vea el Apéndice A en el documento referido para un esquema de una configuración básica del nexo 5000.
Ponga la Conectividad de FCoE para los focos de una cuchilla de Cisco UCS en la configuración UCS para FCoE. El nexo 5000 NPIV FCoE con FCoE NPV asoció los focos del ejemplo de la configuración UCS en la configuración del nexo.
La mayoría de los sistemas operativos de los modernos ofrecen la capacidad de probar una configuración apropiada de las Tramas gigantes con una prueba simple del Internet Control Message Protocol (ICMP).
9000 bytes - Encabezado IP sin las opciones (20 bytes) - encabezado ICMP (8 bytes) = 8972 bytes de dato
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
Problemas relacionados del tiempo de espera que protegen y los otros están entre las causas comunes de la degradación del rendimiento en el entorno de FlexPod. No todos los problemas señalados como tiempo de espera provienen los problemas reales del buffering, muy algunas medidas pudieron indicar el tiempo de espera de punta a punta. Por ejemplo, en el caso de NFS, el período del tiempo informado pudo ser con éxito read/write necesario al almacenamiento y no al tiempo de espera de red real.
La congestión es la mayoría de la causa común para proteger. En el mundo de la capa 2, la congestión puede causar el buffering e incluso ata los descensos de los bastidores. Para evitar los descensos durante los períodos de congestión, las tramas de pausa de IEEE 802.3x y el control de flujo de la prioridad (PFC) fueron introducidos. Ambos confían en pedir la punto final para llevar a cabo las transmisiones por un período corto mientras que la congestión dura. Esto se puede causar por la congestión de red (abrume recibido con el periodo de los datos) o porque un marco prioritario necesita pasar, como en el caso para FCoE.
Para verificar qué interfaces tienen control de flujo activado, ingrese el comando flowcontrol del interfaz de la demostración. Es importante seguir la recomendación del vendedor del almacenamiento con respecto al control de flujo que es activado.
Un ejemplo que muestra cómo los trabajos del control de flujo 802.3x se muestran aquí.
PFC no se requiere para todas las disposiciones, sino se recomienda para la mayoría. Para verificar qué interfaces tienen PFC activado, el prioridad-flujo-control de interfaz de la demostración | i en el comando puede ser ejecutado en el NX-OS y el nexo 5000 UCS.
Los interfaces entre FIs y el nexo 5000 deben ser visibles en esa lista. Si no, la configuración de QoS necesita ser verificada. QoS necesita ser de punta a punta constante para aprovecharse de PFC. Para controlar porqué el PFC no sube en una interfaz particular, ingrese el comando interno de las interfaces Ethernet x/y del registro del dcbx del sistema de la demostración para obtener el centro de datos que puentea el registro del Exchange Protocol de las capacidades (DCBX).
Un ejemplo que muestra cómo las tramas de pausa funcionan con PFC se muestra aquí.
El comando de prioridad-flujo-control del interfaz de la demostración permite que el administrador observe por-QoS el comportamiento de la clase de las tramas de pausa de la prioridad.
Aquí tiene un ejemplo:
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)
Esta salida muestra que, en la segunda clase, el dispositivo acaba de transmitir (TX) un marco PPP.
En este caso, el Ethernet 1/1 es puerto que hace frente a IOM y mientras que el puerto total no tendrá PFC activado, puede ser que procese los marcos PPP para los puertos FEX.
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
En este caso, los interfaces FEX están implicados.
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
Los puertos FEX que están implicados se pueden también controlar vía el detalle del fex X de la demostración donde está el número X de chasis.
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
Vea estos documentos para más información sobre los mecanismos de la pausa.
Los nexos 5000 y el UCS NX-OS no pierden de vista los descartes del ingreso debido a la espera en a por la base del QOS-grupo. Por ejemplo:
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)
El descarte del ingreso debe suceder solamente en las colas de administración del tráfico que se configuran para permitir los descensos.
Los descartes de espera del ingreso pueden suceder debido a estas razones:
Cisco proporciona a dos drivers del sistema operativo para el UCS, enic y fnic. Enic es responsable de la Conectividad de Ethernet y fnic es responsable de la Conectividad del canal y de FCoE de la fibra. Es muy importante que los drivers enic y fnic están exactamente como se especifica en la Matriz de interoperabilidad UCS. Los problemas introducidos por los drivers incorrectos se extienden de la pérdida del paquete y del tiempo de espera agregado a un proceso de cargador del programa inicial más largo o completan la falta de Conectividad.
Cisco-proporcionó al adaptador puede proporcionar a una buena medida sobre el tráfico se pasa que, así como cae. Este ejemplo muestra cómo conectar con el chasis X, el servidor Y, y el adaptador 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.
De aquí, el administrador puede abrirse una sesión al centro de la supervisión para el recurso del funcionamiento (MCP).
adapter 1/2/1 (top):1# attach-mcp
No entry for terminal type "dumb";
using dumb terminal settings
El recurso MCP permite que usted vigile el uso del tráfico por la interfaz lógica (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
Los chasis 1, separan 1, y el adaptador 1 tiene dos indicadores luminosos LED amarillo de la placa muestra gravedad menor de interfaz de red virtual (VNICs) asociados las interfaces virtuales (los Ethernetes virtuales o canal virtual de la fibra) a 834 y a 836. Ésos tienen números 2 y 3. Las estadísticas para LIF 2 y 3 se pueden controlar como se muestra aquí:
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
Es importante observar que proporcionan el administrador del UCS las columnas del total y del delta (entre dos ejecuciones subsiguientes de los lifstats) así como la carga de tráfico actual por-LIF y la información sobre cualquier error que pudieran haber ocurrido.
El ejemplo anterior muestra los interfaces sin ningunos errores con una carga muy pequeña. Este ejemplo muestra un diverso servidor.
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
Dos bits interesantes de información muestran que 96 marcos fueron caídos por el adaptador debido faltar del almacenador intermediario o el buffering inhabilitaron y además los segmentos de descarga del segmento TCP (TSO) que eran procesados.
El diagrama mostrado aquí resume el flujo de paquetes lógico en un entorno de FlexPod.
Se significa este diagrama como un desglose de los componentes que un marco pasó a través en la manera vía el entorno de FlexPod. No refleja la complejidad de los bloques uces de los y es simplemente una manera memorizar donde las funciones particulares deben ser configuradas y ser verificadas.
Tal y como se muestra en del diagrama lógico del flujo de paquetes, el módulo de entrada-salida (IOM) es un componente en el medio de toda la comunicación que pase con el UCS. Para conectar con el IOM en los chasis X, ingrese el comando x del iom de la conexión.
Aquí están varios otros comandos útiles:
Muestra los interfaces de red (NIs) que lleve a FIs, en este caso allí es ocho de ellos, con cuatro de ellos para arriba. Además, muestra los interfaces del host (el suyo) que lleve, dentro del chasis, a las cuchillas determinadas.
Debido a la manera que la infraestructura subyacente trabaja, los contadores se muestran solamente para los interfaces cuáles han experimentado cualquier ejecución media de la pérdida de los dos comandos. En este ejemplo, usted ve que el interfaz NI2 recibió 82 tramas de pausa y que 28 tramas de pausa fueron transmitidas para interconectar HI23, que usted conoce se asocia a la cuchilla 3.
Un FlexPod permite una configuración flexible y una disposición del almacenamiento y de la red de datos. Con la flexibilidad también vienen los desafíos adicionales. Es vital seguir los documentos y un diseño validado Cisco (CVD) de las mejores prácticas:
Un problema común considerado por los ingenieros de TAC es sobreutilización de los links debido a la selección de 1 Ethernet de Gbit en vez de 10 Ethernetes de Gbit referidos a los documentos de la mejor práctica. Como ejemplo acentuado, el funcionamiento del flujo único no será mejor en diez links de 1 Gbit comparados a un link de 10 Gbit. En el Canal de puerto un flujo único puede pasar un solo link.
Para descubrir qué método del Equilibrio de carga se utiliza en NX-OS del nexo y/o FI, ingrese el comando port-channel load-balance de la demostración. El administrador puede también descubrir que interconectan en un Canal de puerto será elegido como la interfaz saliente para un paquete o un marco. Un ejemplo simple de un bastidor en VLAN49 entre dos host se muestra aquí:
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
Los problemas discutidos previamente son comunes a los datos y a las Redes de almacenamiento. Por lo completo, los problemas de rendimiento específicos a la Red de área de almacenamiento (SAN) también se mencionan. Los protocolos de almacenamiento fueron construidos con la elasticidad y la mutli-dirección todavía se aumenta. Con la llegada de las Tecnologías tales como asignación asimétrica de la unidad lógica (ALUA) e IO de trayectoria múltiple (MPIO), más flexibilidad y opciones se presentan a los administradores.
Otra consideración es colocación del almacenamiento. Un diseño de FlexPod dicta que el almacenamiento debe ser asociado en el Switches del nexo. El almacenamiento directamente asociado no se ajusta al CVD. Los diseños con el almacenamiento directamente asociado se utilizan, si se siguen las mejores prácticas. Al mismo tiempo, esos diseños no son estrictamente FlexPod.
Esto no es técnico un problema de Cisco, pues la mayor parte de esas opciones son transparentes a los dispositivos de Cisco. Es un problema común a escoger y a pegarse a un trayecto óptimo. Un módulo específico del dispositivo moderno (el DSM) se puede presentar con los trayectos múltiples y las necesidades de escoger óptimo un uno Este tiro de pantalla muestra cuatro trayectorias disponibles para NetApp DSM para Microsoft Windows y las opciones del Equilibrio de carga.
Las configuraciones recomendadas se deben escoger sobre la base de una discusión con el vendedor del almacenamiento. Esas configuraciones pudieron afectar a los problemas de rendimiento. Una prueba típica que TAC pudo pedirle que se realice es una prueba de lectura/grabación a través solamente de la tela A o de la tela B. Esto permite típicamente que usted estreche abajo los problemas de rendimiento a las situaciones discutidas en la sección de los “problemas comunes” de este documento.
Esta punta es específica al componente del cálculo, sin importar el vendedor. Una forma sencilla de poner una red de almacenamiento para los hipervisores desde el punto de vista del cálculo es crear dos adaptadores del bus del host (HBA), uno para cada fibra, y ejecuta el tráfico del tráfico del cargador del programa inicial LUN y del almacenamiento de la máquina virtual (VM) sobre esos dos interfaces. Se recomienda siempre para partir el tráfico del tráfico del cargador del programa inicial LUN y del almacenamiento VM. Esto permite el mejor rendimiento y permite además una fractura lógica entre las dos clases de tráfico. Vea la sección de los “problemas conocidos” para un ejemplo.
Como en el caso de cualquier troubleshooting rápido, es muy importante estrechar abajo el problema y hacer las preguntas de la derecha.
En este interfaz del documento, ASIC que hace cola los contadores se discute. Los contadores también dan una visión en una punta a tiempo, así que es importante vigilar el aumento de los contadores. Ciertos contadores no se pueden borrar por el diseño. Por ejemplo, el carmel ASIC mencionado previamente.
Para dar un ejemplo acentuado, la presencia de CRC o los descartes en un interfaz no pudo ser ideales, sino que puede ser que se espere que sus valores sean no-cero. Los contadores habrían podido subir en algún momento, posiblemente durante la transición o la disposición inicial. Por lo tanto es importante observar el aumento de los contadores y cuando era la última vez ellos fue borrado.
Mientras que es útil revisar los contadores, es importante saber que ciertos problemas del avión de los datos no pudieron encontrar una reflexión fácil para controlar los contadores y las herramientas planos. Como ejemplo acentuado, el ethanalyzer es mismo una herramienta útil que está disponible en UCS y el nexo 5000. Sin embargo, puede capturar solamente el tráfico del plano del control. Una captura del tráfico es lo que pide TAC a menudo, especialmente cuando no está claro donde miente el incidente.
Una captura confiable del tráfico adquirida los host de extremo puede verter la luz en un problema de rendimiento y estrecharla abajo muy rápidamente. El nexo 5000 y SPAN del tráfico de la oferta UCS. Específicamente, las opciones UCS de SPANing HBA determinados y los lados de la tela son útiles. Para aprender más sobre las capacidades de la captura del tráfico cuando usted vigila una sesión sobre el UCS, vea estas referencias:
NetApp ofrece a un conjunto completo de utilidades para resolver problemas sus controladores de almacenamiento, entre ellos es:
Hay entre los comandos mas comunes:
sysstat -x 2
sysstat -M 2
Aquí están algunas cosas a buscar en el sysstat - x 2 hecho salir que pudo indicar el arsenal sobrecargado o los discos de NetApp:
Este artículo describe cómo configurar NetApp: Mejores prácticas del almacenamiento de los Ethernetes de NetApp.
ESXi proporciona al acceso del Secure Shell (SSH), con el cual usted puede resolver problemas. Entre la mayoría de las herramientas útiles proporcionadas a los administradores son el esxtop y el perfmon.
En muchos de los casos, el ingeniero de TAC pedirá que usted recoja una cierta información básica antes de que una investigación pueda ser comenzada.
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'
Utilice el botón Feedback Button para proporcionar al feedback sobre este documento o sus experiencias. Pondremos al día continuamente este documento como ocurren los progresos y después del feedback nos recibimos.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
20-Feb-2015 |
Versión inicial |