Problemas de desempenho da terra comum de FlexPod

Introdução

Este original descreve problemas de desempenho comuns em ambientes de FlexPod, fornece um método para pesquisar defeitos edições, e fornece etapas da mitigação. Pretende-se como o ponto de início para os clientes que olham para pesquisar defeitos o desempenho em um ambiente de FlexPod. Este original foi redigido em consequência das edições consideradas pela equipe do centro de assistência técnica (TAC) das soluções do centro de dados nos últimos meses.

Vista geral conceptual de FlexPod

Um FlexPod consiste em um computador do sistema de Unified Computing (UCS) conectado através de um interruptor do nexo ao armazenamento e às redes IP de NetApp.

O FlexPod o mais comum consiste em um chassi das B-séries de Cisco UCS conectado através da tela interconecta (FIs) aos 5500 Switch do nexo aos limador de NetApp. Uma outra solução, chamada o FlexPod expresso, usa um chassi da série C UCS conectado aos 3000 Switch do nexo. Este original discute o FlexPod o mais comum.

Considerações de desempenho

Nos ambientes complexos com partidos responsáveis múltiplos como vistos tipicamente em um FlexPod, você precisa de considerar aspectos múltiplos a fim pesquisar defeitos a edição. Os problemas de desempenho típicos na camada 2 e as redes IP proviriam de:

• Pacote ou perda de frame - a perda de bit dos dados causa um efeito adverso no desempenho dos aplicativos.
• Protegendo - se um pacote ou um quadro passam demasiada hora em uma fila/buffer que determinadas implicações de desempenho puderam ser consideradas por aplicativos, especialmente em caso da Rede de armazenamento. A latência, a requisição, e os problemas do normalizador caem sob esta categoria.
• Problemas de incompatibilidade e fragmentação MTU - um problema comum quando você alcançar o alto desempenho. Edições que se relacionam à queda da fragmentação e da inconsistência MTU nesta categoria.

Ambiente

É importante conhecer o ambiente para que o desempenho é medido. As perguntas sobre o tipo e o protocolo do armazenamento, assim como o operating system (OS) e o lugar do server afetado, devem ser levantados para reduzir corretamente para baixo o problema. Um diagrama de topologia que esboce a Conectividade é o mínimo limitado.

Medida

Você precisa de conhecer o que são medidos e como ele é medido. Determinados aplicativos, assim como a maioria de vendedores do armazenamento e do hypervisor, fornecem as medidas de algum tipo que indicam o desempenho/saúde do sistema. Estas medidas são um bom ponto a começar em porque não são um substituto para a maioria de metodologias de Troubleshooting.

Como um exemplo, uma medida da latência do armazenamento do Network File System (NFS) no hypervisor pôde indicar que o desempenho vai para baixo, porém no seus próprios não implica a rede. No caso de um NFS, um ping simples do host à rede IP do armazenamento NFS pôde indicar se a rede é responsabilizar.

Linha de base

Este ponto não pode ser forçado bastante, especialmente quando você abre um caso de TAC. A fim indicar que o desempenho é insatisfatório, o parâmetro medido precisa de ser indicado. Isto inclui o valor previsto e testado. Idealmente, você deve mostrar dados precedentes e a metodologia testando usada para conseguir esses dados.

Como um exemplo; a latência 10ms conseguida quando testada, com uma escrita-somente de um único iniciador a um único número de unidade lógica (LUN), não pôde ser indicativa do que a latência é suposta para ser para inteiramente um sistema carregado.

Problemas de desempenho em um FlexPod

Desde que este original é pretendido como a referência para a maioria de ambientes de FlexPod, esboça somente a maioria de problemas frequente como considerado pelo responsável do equipe tac para soluções do centro de dados.

Problemas comuns

Os problemas comuns ao armazenamento e as redes IP/Layer 2 são discutidos nesta seção.

Quadro e perda de pacotes

O quadro e a perda de pacotes são o fator o mais frequente esse desempenho dos impactos. Um dos lugares comuns para procurar indicações de um problema está a nível de interface. Do nexo 5000 ou do sistema operacional do nexo UCS (NX-OS) CLI, incorpore a relação da mostra | o segundo “está acima de” | ^ do egrep (Eth|fc)|discard|gota|Comando crc. Para as relações que estão acima, alista o nome e rejeita contadores e gotas. Similarmente, uma grande vista geral é indicada quando você inscreve o comando error dos contadores de interface da mostra que mostra estatísticas de erros para todas as relações.

Mundo dos Ethernet

É importante saber que os contadores em non-0 não puderam indicar um problema. Em determinadas encenações aqueles contadores puderam ter sido levantados na instalação inicial ou em mudanças operacionais precedentes. Um aumento dos contadores deve ser monitorado.

Um pode igualmente recolher contadores do nível ASIC, que pôde ser mais indicativo. Especificamente, para o erro da verificação de redundância cíclica (CRC) em relações, um comando favorito TAC entrar é centro de detecção e de controlo interno do carmel do hardware da mostra. Carmel é o nome do responsável ASIC para a transmissão do porta-nível.

A saída similar pode ser tomada do 6100 Series FIs ou dos 5600 Switch do nexo em uma base por porto. Para o FI 6100, os gatos ASIC, incorporam este comando:

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

Para o nexo 5600, do bigsur ASIC, incorpore este comando: 

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

O comando para o carmel ASIC mostra a onde os pacotes CRC foram recebidos e a onde foram enviados, e mais importante se stomped ou não.

Desde que o nexo 5000 e a operação UCS NX-OS estão corte-através de, os quadros do modo de switching com sequência de verificação de frame (FCS) incorreta stomped somente antes de enviar. É importante encontrar de aonde os quadros corrompidos vêm. 

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 exemplo mostra os pacotes stomped que vêm de Eth 1/17 e Eth 1/18, que é uplink ao nexo 5000. Se pode supor que aqueles quadros estiveram enviados mais tarde para baixo a Eth 1/34, tal como Eth 1/17 + Eth que 1/18 de rx Stomp = Eth 1/34 de tx Stomp.

Um olhar similar no nexo 5000 mostra:

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 saída mostra que os CRC recebidos em duas relações e marcados como stomps antes de enviar. Para mais informação, veja o guia de Troubleshooting do nexo 5000.

Mundo do Fibre Channel

Uma maneira simples procurar gotas (discrds, erro, CRC, exaustão do crédito de B2B) é através do comando do fc dos contadores de interface da mostra.

Estes comando, disponíveis nos nexos 5000 e na interconexão da tela, dão uma boa indicação do que acontece no mundo do Fibre Channel. 

Por exemplo:

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

Esta relação não é ocupada, e a saída mostra que nenhum descarte ou erro aconteceram. 

Adicionalmente, as transições do crédito de B2B de 0 foram destacadas; devido aos IDs CSCue80063 e CSCut08353 do Bug da Cisco, aqueles contadores não podem ser confiados. Trabalham muito bem em Cisco MDS, mas não no UCS de Plataformas Nexus5k. Igualmente você pode verificar a identificação de bug Cisco CSCsz95889. 

Similarmente ao carmel no mundo dos Ethernet para o Fibre Channel (FC) a facilidade fc-MAC pode ser usada. Como um exemplo, para a porta fc2/1, inscreva o comando statistics interno da porta fc-MAC 2 1 do hardware da mostra. Os contadores apresentados estão no 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

A saída mostra 15 descartes na entrada. Isto pode ser combinado a FCP_CNTR_PIF_RX_DROP que contou a 0xf (15 no decimal). Esta informação pode outra vez ser correlacionada à informação FWM (gerente da transmissão).

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

Contudo, este tellls o administrador a quantidade de gotas e que é o número correspondente ASIC. A informação da obtenção sobre a razão daquela ASIC deixado cair precisa de ser perguntada.

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]

Neste caso, o tráfego foi deixado cair pelo Access Control List do ingresso (ACL), tipicamente no mundo FC - Zoneamento.

Má combinação MTU

Em ambientes de FlexPod é importante acomodar o ajuste máximo fim-a-fim da unidade da transição (MTU) para aplicativos e protocolos onde se exige. No caso da maioria de ambientes, este é Fibre Channel sobre Ethernet (FCoE) e Jumbo Frames.

Adicionalmente, a fragmentação ocorrer, o desempenho degradado deve ser esperada. Em caso dos protocolos tais como o Network File System (NFS) e a interface de sistema de um pequeno computador do Internet (iSCSI), é importante testar e provar a unidade de transmissão máxima IP fim-a-fim (MTU) e o Maximum Segment Size TCP (MSS).

Se você pesquisa defeitos o Jumbo Frames ou o FCoE, é importante recordar que ambos os aqueles precisam a configuração consistente e o Classe de serviço (CoS) que marcam através do ambiente a fim se operar corretamente.

No caso do UCS e do nexo, um comando que seja útil validar a interface per., pela configuração MTU do QoS-grupo é interface de enfileiramento da mostra | mim Enfileiramento|qos-grupo|MTU.

O MTU indica no nexo 5000 e nas Plataformas UCS

Um aspecto conhecido do UCS e do nexo é o indicador dos MTU na relação. Esta saída demonstra uma relação configurada para enfileirar o Jumbo Frames e o 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)

Ao mesmo tempo, o comando show interface indica 1500 bytes:

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

Se comparado à informação do carmel ASIC, o ASIC mostra a capacidade MTU de uma porta dada.  

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

Esta má combinação MTU no indicador é esperada em Plataformas acima mencionadas, e poderia potencialmente enganar em neófitos.

Configuração de ponta a ponta

A configuração consistente fim-a-fim é a única maneira de garantir o desempenho apropriado. O Jumbo Frames configuração e etapas para o lado de Cisco, assim como VMware ESXi, são descritos no UCS com exemplo de configuração fim-a-fim do jumbo MTU de VMware ESXi.

O UCS FCoE Uplink o exemplo de configuração mostra uma configuração UCS e de nexo 5000. Veja o apêndice A no original provido para um esboço de uma configuração básica do nexo 5000.

Estabelecer a Conectividade de FCoE para focos de uma lâmina de Cisco UCS na configuração UCS para FCoE. O nexo 5000 NPIV FCoE com FCoE NPV anexou focos do exemplo de configuração UCS na configuração do nexo.

Teste o Jumbo Frames fim-a-fim

A maioria de sistemas operacionais modernos do dia oferecem a capacidade para testar uma configuração apropriada do Jumbo Frames com um teste simples do Internet Control Message Protocol (ICMP).

Cálculo

9000 bytes - Cabeçalho IP sem opções (20 bytes) - cabeçalho ICMP (8 bytes) = 8972 bytes de dados

Comandos em sistemas operacionais populares

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

Problemas relacionados de proteção e outros da latência estão entre as causas comuns da degradação do desempenho no ambiente de FlexPod. Não todos os problemas relatados como a latência provêm dos problemas reais da proteção, bastante algumas medidas puderam indicar a latência fim-a-fim. Por exemplo, no caso do NFS, o período de período relatado pôde ser com sucesso read/write necessário ao armazenamento e não à latência de rede real.

A congestão é a maioria de causa comum para proteger. No mundo da camada 2, a congestão pode causar a proteção e ata mesmo gotas dos quadros. A fim evitar gotas durante períodos de congestionamento, os frames de pausa da IEEE 802.3x e o controle de fluxo da prioridade (PFC) foram introduzidos. Ambos confiam em pedir o ponto final para guardar por um curto período de tempo transmissões quando a congestão durar. Isto pode ser causado pelo congestionamento de rede (oprima recebido com uma quantidade de dados) ou porque um quadro prioritário precisa de passar, como no argumento para FCoE.

Controle de fluxo - 802.3x

A fim verificar que relações têm o controle de fluxo permitido, inscreva o comando flowcontrol da relação da mostra. É importante seguir a recomendação do vendedor do armazenamento com respeito ao controle de fluxo que está sendo permitido.

Uma ilustração que mostre como os trabalhos do controle de fluxo 802.3x são mostrados aqui.

PFC - 802.1Qbb

O PFC não é exigido para todas as instalações, mas é recomendado para a maioria. A fim verificar que relações têm o PFC permitido, o prioridade-fluxo-controle da relação da mostra | eu no comando posso ser executado no NX-OS do UCS e no nexo 5000. 

As relações entre FIs e o nexo 5000 devem ser visíveis nessa lista. Se não, a configuração de QoS precisa de ser verificada. QoS precisa de ser fim-a-fim consistente a fim aproveitar-se do PFC. A fim verificar porque o PFC não vem acima em uma interface particular, incorpore o comando interno dos Ethernet de interface x/y do log do dcbx do sistema da mostra a fim obter o centro de dados que constrói uma ponte sobre o log do protocolo de intercâmbio das capacidades (DCBX).

Uma ilustração que mostre como os frames de pausa funcionam com PFC é mostrada aqui.

O comando do prioridade-fluxo-controle da relação da mostra permite que o administrador observe por-QoS o comportamento da classe de frames de pausa da prioridade. 

Aqui está um exemplo:

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 saída mostra que, na classe secundária, o dispositivo apenas transmitia (TX) um quadro PPP. 

Neste caso, o Ethernet 1/1 é porta que enfrenta IOM e quando a porta total não terá o PFC permitido, pôde processar quadros PPP para portas 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

Neste caso, as relações FEX são involvidas. 

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 

As portas FEX que são involvidas podem igualmente ser verificadas através do detalhe do fex X da mostra onde X é o número de chassi. 

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

Veja estes originais para obter mais informações sobre dos mecanismos da pausa. 

• Fibre Channel sobre operações de Ethernet
• Canal branco unificado da Papel-fibra da tela sobre Ethernet (FCoE)

Descartes de enfileiramento

Os nexos 5000 e o UCS NX-OS mantêm-se a par dos descartes do ingresso devido ao enfileiramento na pela base do QOS-grupo. Por exemplo:

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)

O descarte do ingresso deve acontecer somente nas filas que são configuradas para permitir gotas.

Os descartes de enfileiramento do ingresso podem acontecer devido a estas razões:

• Sessão do Switched Port Analyzer (SPAN) /Monitoring permitida em algumas das relações (veja a identificação de bug Cisco CSCur25521)
• A pressão contrária de uma outra relação, frames de pausa é vista tipicamente quando permitida
• Tráfego punted ao CPU 

Problema de driver

Cisco fornece dois direcionadores do sistema operacional para o UCS, enic e fnic. Enic é responsável para a conectividade Ethernet e fnic é responsável para a Conectividade do Fibre Channel e do FCoE. É muito importante que os direcionadores enic e fnic são exatamente como especificado na matriz de interoperabilidade UCS. Os problemas introduzidos por direcionadores incorretos variam da perda de pacotes e da latência adicionada a um processo de boot mais longo ou terminam a falta da Conectividade.

Informação do adaptador

Cisco-forneceu o adaptador pode fornecer uma boa medida sobre o tráfego que é passado, assim como deixa cair. Este exemplo mostra como conectar ao chassi X, ao server Y, e ao 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 aqui, o administrador pode entrar ao centro da monitoração para a facilidade do desempenho (MCP).

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

A facilidade MCP permite que você monitore o uso do tráfego pela interface 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   

Os chassis 1, separam 1, e o adaptador 1 tem duas placas de interface da rede virtual (VNICs) associadas com as interfaces virtuais (Ethernet virtuais ou Fibre Channel virtual) 834 e 836. Aqueles têm os números 2 e 3. As estatísticas para LIF 2 e 3 podem ser verificadas como mostrado aqui:

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

É importante notar que o administrador do UCS está fornecido com duas execuções subsequentes dos lifstats) as colunas do total e do delta (entre assim como a carga de tráfego atual por-LIF e a informação sobre todos os erros que possam ter ocorrido.

O exemplo anterior mostra relações sem nenhuns erros com uma carga muito pequena. Este exemplo mostra um server diferente.

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

Dois bit interessantes da informação mostram que 96 quadros estiveram deixados cair pelo adaptador devendo faltar do buffer ou a proteção desabilitaram e adicionalmente os segmentos Offloading do segmento TCP (TSO) que estão sendo processados.

Fluxo de pacote de informação lógico

O diagrama mostrado aqui esboça o fluxo de pacote de informação lógico em um ambiente de FlexPod.

Este diagrama é significado como uma divisão dos componentes que um quadro passou completamente na maneira através do ambiente de FlexPod. Não reflete a complexidade de alguns dos blocos e é simplesmente uma maneira de memorizar onde os recursos particulares devem ser configurados e verificado. 

Módulo de entrada/saída

Segundo as indicações do diagrama de fluxo de pacote de informação lógico, o módulo de entrada/saída (IOM) é um componente no meio de toda a comunicação que atravessa o UCS. A fim conectar ao IOM nos chassis X, inscreva o comando x do iom da conexão.

Estão aqui diversos outros comandos úteis:

• Informação de topologia - o software de plataforma da mostra [woodside|o comando sts da sequoia vermelha] mostra a informação topológica do ponto de vista do IOM.

  

  Mostra as interfaces de rede (NIs) que conduza a FIs, neste caso lá é oito delas, com os quatro deles acima. Adicionalmente, mostra relações do host (a sua) que conduza, dentro do chassi, às lâminas particulares.

• Taxa de tráfego - o software de plataforma da mostra [woodside|o comando rate da sequoia vermelha] é usado verificar a taxa de tráfego que passa através das relações HI uma vez a topologia e relação HI ao mapeamento da lâmina é sabido.

  

• Perda de tráfego - incorpore o software de plataforma da mostra [woodside|comando da perda da sequoia vermelha]. A execução de zero que deste comando a perda se opõe. Permite que você ver frames de pausa e gotas em uma base da interface per.

  

  Devido à maneira que a infraestrutura subjacente trabalha, os contadores são mostrados somente para relações quais experimentaram toda a execução no meio da perda dos dois comandos.  Neste exemplo, você vê que a relação NI2 recebeu 82 frames de pausa e que 28 frames de pausa estiveram transmitidos para conectar HI23, que você conhece é anexado à lâmina 3.

Considerações do projeto

Um FlexPod permite uma configuração flexível e estabelece-se do armazenamento e da comunicação de rede de dados. Com flexibilidade igualmente vêm os desafios adicionais. É vital seguir os originais dos melhores prática e um projeto validado Cisco (CVD):

• CVD - Guia de distribuição de FlexPod
• Melhores prática do armazenamento de NetApp (não específicos a Flexpod) - opções de conectividade e melhores prática do armazenamento do Cisco Unified Computing System (UCS) com armazenamento de NetApp

Considerações da seleção e do Canal de porta da velocidade de porta

Um problema comum considerado por coordenadores TAC é overutilization das relações devido à seleção de 1 Ethernet de Gbit em vez dos Ethernet 10 Gbit providos em originais do melhor prática. Como um exemplo aguçado, o desempenho do fluxo único não será melhor em dez relações de 1 Gbit comparadas a uma relação 10 Gbit. No Canal de porta um fluxo único pode ir sobre um link único. 

A fim encontrar que método do Balanceamento de carga é usado em NX-OS do nexo e/ou do FI, inscreva o comando port-channel load-balance da mostra. O administrador pode igualmente encontrar que que conectam em um Canal de porta será escolhido como a interface enviada para um pacote ou um quadro. Um exemplo simples de um quadro em VLAN49 entre dois anfitriões é mostrado aqui:

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

Problemas do específico do armazenamento

Os problemas discutidos previamente são comuns aos dados e à Rede de armazenamento. Para a integralidade, os problemas de desempenho específicos à rede de área de armazenamento (SAN) são mencionados igualmente. Os protocolos do armazenamento foram construídos com elasticidade e o mutli-pathing é aumentado ainda. Com o advento das Tecnologias tais como a atribuição assimétrica da unidade lógica (ALUA) e o Multi-PATH IO (MPIO), mais flexibilidade e opções são apresentados aos administradores.

Colocação do armazenamento

Uma outra consideração é colocação do armazenamento. Um projeto de FlexPod dita que o armazenamento deve ser anexado no Switches do nexo. O armazenamento diretamente anexado não se conforma ao CVD. Os projetos com armazenamento diretamente anexado estão apoiados, se os melhores prática são seguidos. Ao mesmo tempo, aqueles projetos não são restritamente FlexPod.

Seleção de caminho ótimo

Este não é tecnicamente Cisco emite, como a maioria daquelas opções são transparentes aos dispositivos Cisco. É um problema comum a escolher e colar a um caminho ótimo. Um módulo específico do dispositivo moderno (o DSM) pode é presentado com caminhos múltiplos e necessidades escolher ótimo um aquele Este tiro de tela mostra quatro trajetos disponíveis a NetApp DSM para Microsoft Windows e opções do Balanceamento de carga.

As configurações recomendadas devem ser escolhidas com base em uma discussão com o vendedor do armazenamento. Aqueles ajustes puderam afetar problemas de desempenho. Um teste típico que o TAC possa pedir que lhe execute é um teste de leitura/gravação através somente da tela A ou da tela B. Isto permite tipicamente que você reduza para baixo problemas de desempenho às situações discutidas na seção dos “problemas comuns” deste original.

VM e compartilhamento de tráfego de Hypervisor

Este ponto é específico ao componente do cálculo, apesar do vendedor. Uma maneira fácil estabelecer uma rede de armazenamento para os hypervisors do ponto de vista do cálculo é criar dois adaptadores do barramento do host (HBA), um para cada fibra, e executa o tráfego do tráfego da bota LUN e do armazenamento da máquina virtual (VM) sobre aquelas duas relações. Recomenda-se sempre rachar o tráfego do tráfego da bota LUN e do armazenamento VM. Isto permite o melhor desempenho e permite adicionalmente uma separação lógica entre os dois tipos do tráfego. Veja a seção dos “problemas conhecidos” para um exemplo.

Pesquise defeitos pontas

Reduza para baixo o problema

Como no caso de todo o Troubleshooting rápido, é muito importante reduzir para baixo o problema e fazer as perguntas do direito.

• Que dispositivos/applications/VM são (/not) afetados?
• Que controlador do armazenamento é (/not) afetado?
• Que trajetos são (/not) afetados?
• Como frequentemente o problema (/not) aparece?

Cisco

Limitações contrárias

Nesta relação do original, os contadores do Enfileiramento ASIC são discutidos. Os contadores igualmente dão uma vista em um ponto a tempo, assim que é importante monitorar o aumento dos contadores. Determinados contadores não podem ser cancelados pelo projeto. Por exemplo, o carmel ASIC mencionado previamente.

A fim dar um exemplo aguçado, a presença de CRC ou os descartes em uma relação não puderam ser ideal, mas pôde-se esperar que seus valores são diferente de zero. Os contadores poderiam ter aumentado a dada altura do tempo, possivelmente durante a transição ou a instalação inicial. Daqui é importante notar o aumento dos contadores e quando era a última vez eles foi cancelado.

Controle considerações planas

Quando for útil rever contadores, é importante saber que determinados problemas do plano dos dados não puderam encontrar uma reflexão fácil para controlar contadores e ferramentas planos. Como um exemplo aguçado, o ethanalyzer é muito uma ferramenta útil que esteja disponível em UCS e em nexo 5000. Contudo, pode somente capturar o tráfego plano do controle. Uma captação do tráfego é o que o TAC peça frequentemente, especialmente quando não é claro onde a falha se encontra.

Tráfego da captação

Uma captação segura do tráfego tomada nos host finais pode derramar a luz em um problema de desempenho e reduzi-la para baixo bastante rapidamente. O nexo 5000 e PERÍODO do tráfego da oferta UCS. Especificamente, as opções do UCS de SPANing HBA particulares e os lados da tela são úteis. A fim aprender mais sobre as capacidades da captação do tráfego quando você monitora uma sessão no UCS, veja estas referências:

• Análise de tráfego UCS para o exame e os adaptadores virtuais (vídeo)
• Manual de configuração do Cisco UCS Manager GUI - Monitorando o tráfego

NetApp

NetApp oferece um conjunto completo de utilidades a fim pesquisar defeitos seus controladores do armazenamento, entre eles é:

• perfstat - uma utilidade muito útil, é executado tipicamente para pessoais de suporte de NetApp
• systat - fornece a informação sobre como ocupado o limador é e o que o limador está fazendo - biblioteca do apoio de NetApp

Há entre os comandos os mais comuns:

• sysstat -x 2

• sysstat -M 2

Estão aqui algumas coisas a procurar no sysstat - x 2 output que pôde indicar a disposição sobrecarregada ou os discos de NetApp:

• Coluna ty sustentada CP com lotes de: ou F
• Coluna sustentada HDD util acima de 20%

Este artigo descreve como configurar NetApp: Melhores prática do armazenamento dos Ethernet de NetApp.

• Colocação de etiquetas VLAN
• Trunking VLAN
• MTU enorme
• Hashing IP
• Controlo de fluxo da inutilização

VMware

ESXi fornece o acesso do Shell Seguro (ssh), com que você pode pesquisar defeitos. Entre a maioria de ferramentas úteis fornecidas aos administradores são o esxtop e o perfmon.

• esxtop - bem como a parte superior Linux/BSD, permite que os usuários monitorem parâmetros relacionados do desempenho em tempo real
  Usando o esxtop para identificar problemas de desempenho do armazenamento para ESX/ESXi
• perfmon - permite que os usuários pesquisem defeitos as máquinas virtuais de Microsoft Windows (o VM)
  Recolhendo os dados de registro de Windows Perfmon para diagnosticar edições de desempenho da máquina virtuais
• Recolha o pacote diagnóstico em ESXi - Recolhendo a informação de diagnóstico para VMware ESX/ESXi usando o cliente do vSphere (653)
• Exigência do Balanceamento de carga do vSwitch de VMware para server das B-séries de Cisco - a rota baseada na mistura IP não é apoiada com os server da lâmina de Cisco UCS B200 M1/M2 que usam o 6100 Series que UCS a tela interconecta 

Problemas conhecidos e realces

• Identificação de bug Cisco CSCuj86736 - com erros CRC passivos dos cabos do twinax pode aumentar. Isto é causado quando o nexo 5000 não aperfeiçoa DFE. Incorpore o comando interno do olho do carmel do hardware da mostra a fim verificar que do “o parâmetro da altura olho” está acima de 100 milivolt. Isto foi fixado nas liberações 5.2(1)N1(7) e 7.0(4)N1(1).
• A identificação de bug Cisco CSCuo76425 - similar ao erro precedente e igualmente existe na tela UCS interconecta. Isto é fixado na liberação 2.2(3a).
• Identificação de bug Cisco CSCuo76425 - mesmos como introduzem erros de funcionamento CSCuj86736 à exceção da interconexão da tela UCS.
• A identificação de bug Cisco CSCup40056 - problema de cronometragem causado compartilhando do tráfego da bota com o tráfego VM descrito na migração viva da máquina virtual de sistema de Unified Computing falha com os adaptadores virtuais do Fibre Channel.
• Detecção e vacância lentas do dreno - muito frequentemente FC e FCoE são afetados pelo dreno lento. A liberação NX-OS 7.0(0)N1(1) introduz meios detectá-lo e evitar. Aprenda mais sobre a característica no manual de configuração das relações do 5500 Series NX-OS do nexo de Cisco e retarde a detecção e a fuga de congestionamento do dispositivo do dreno.
• Identificação de bug Cisco CSCuj81245 - uma limitação existe em cartões baseados PALO (VIC1240 e outro) esse abortos das causas FC.
• Identificação de bug Cisco CSCuh61202 - depois que a elevação para liberar 2.1(3), o firmware FC UCS aborta e o múltiplo outros problemas pode ser considerado.
• Identificação de bug Cisco CSCtw91018 - uma mistura de configurações MTU para VNICs em um único, adaptador PALO-baseado pode causar a inanição para algumas das classes de tráfego.
• A identificação de bug Cisco CSCuq40256 - fará com que o PFC seja desabilitado nas relações da interconexão da tela para baixo aos adaptadores de servidor. Isto causará a variedade de problemas que começa com abortos do Fibre Channel e os quadros foras de serviço relatados no armazenamento tomam partido. As disconexões do armazenamento e outros problemas de desempenho puderam ser relatados. 

Casos de TAC

Em muitos dos casos, o coordenador TAC pedirá que você recolha alguma informação básica antes que uma investigação possa ser começada.

• Diagrama de topologia - que inclui números de porta e velocidades de linha, absolutamente necessário.
• Suporte técnico UCSM - Guia visual para recolher arquivos do suporte técnico (B e série C).
• Suporte técnico do chassi UCS para um chassi que experimenta problemas - veja a relação precedente.
• Ambos os Suporte técnico do nexo 5000 e alguns outros dispositivos de rede entre o UCS e o NetApp - reorientando a saída dos detalhes do tecnologia-apoio da mostra comande.
• Saída do comando show queueing interface em ambos o FIs.

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

• As versões do drive de host no ESXi executam - incorpore estes comandos:
  • vmkload_mod - s enic
  • vmkload_mod - s fnic
• Linux -

  dmesg | egrep -i 'enic|fnic'

• Windows - verifique a versão do driver no “gerenciador de dispositivo”.  Um exemplo das mostras R2 do indicador 2012 três interfaces Ethernet de Cisco VIC e quatro relações do miniport VIC FCoE (responsável igualmente para o Fibre Channel, não somente FCoE) e liberação 2.4.0.8 do direcionador fnic.

  

Feedback

Use o botão Feedback Button para fornecer o feedback sobre este original ou suas experiências. Nós atualizaremos continuamente este original como os desenvolvimentos ocorrem e após o feedback somos recebidos.