iSCSI para NetApp FAS: alta latência para carga de gravação

Question

Problema

Um iniciador Linux iSCSI está obtendo altos tempos de serviço ao gravar em um destino NetApp FAS, expondo um grupo de LUNs. Onde procurar a causa e como resolver isso?

Reprodução

Estou usando iostats e sa do pacote sysstat para fazer o cálculo de "await" - o tempo que uma solicitação específica está aguardando em média:

dd if=/dev/urandom of=test bs=8K count=1000000 & iostat -xdm 5 sdy dm-26
[...]
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sdy               0.00  1115.60    0.10   47.50     0.00     7.94   341.68     1.63   34.05   2.00   9.52
dm-26             0.00     0.00    0.10 2032.90     0.00     7.94     8.00   328.10  161.39   0.05   9.52

Nesse cenário, o valor esperado para "await" seria uma magnitude menor que a medida por iostats . Os 10 segundos de tráfego de rede transmitidos no período de tempo do exemplo acima são disponíveis no CloudShark . dm-26 é o dispositivo de mapeamento de dispositivo que hospeda o sistema de arquivos (volume NSS de disco único) referente ao dispositivo sdy "físico".

Ambiente

Iniciador e Alvo são colocados na mesma sub-rede. O host iniciador tem o IP de 192.168.20.72, o alvo é 192.168.20.33, o tráfego é comutado de 1GbE, os Jumbo Frames são habilitados (e confirmados para uso através de um rastreamento de rede), iSCSI Immediate Data é habilitado (e em uso como pelo rastreio mencionado), os resumos não estão ativados.

informações da sessão iSCSI:

iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
version 2.0-873.suse
Target: iqn.1992-08.com.netapp:sn.151745715
        Current Portal: 192.168.20.33:3260,2003
        Persistent Portal: 192.168.20.33:3260,2003
                **********
                Interface:
                **********
                Iface Name: default
                Iface Transport: tcp
                Iface Initiatorname: iqn.2015-06.de.example.dom:01:gw-cl-07
                Iface IPaddress: 192.168.20.72
                Iface HWaddress: <empty>
                Iface Netdev: <empty>
                SID: 1
                iSCSI Connection State: LOGGED IN
                iSCSI Session State: LOGGED_IN
                Internal iscsid Session State: NO CHANGE
                *********
                Timeouts:
                *********
                Recovery Timeout: 120
                Target Reset Timeout: 30
                LUN Reset Timeout: 30
                Abort Timeout: 15
                *****
                CHAP:
                *****
                username: <empty>
                password: ********
                username_in: <empty>
                password_in: ********
                ************************
                Negotiated iSCSI params:
                ************************
                HeaderDigest: None
                DataDigest: None
                MaxRecvDataSegmentLength: 262144
                MaxXmitDataSegmentLength: 65536
                FirstBurstLength: 65536
                MaxBurstLength: 65536
                ImmediateData: Yes
                InitialR2T: No
                MaxOutstandingR2T: 1
                ************************
                Attached SCSI devices:
                ************************
                Host Number: 3  State: running
                scsi3 Channel 00 Id 0 Lun: 0
                        Attached scsi disk sdb          State: running
                scsi3 Channel 00 Id 0 Lun: 1
                        Attached scsi disk sdc          State: running
                scsi3 Channel 00 Id 0 Lun: 10
                        Attached scsi disk sdl          State: running
                scsi3 Channel 00 Id 0 Lun: 11
                        Attached scsi disk sdm          State: running
                scsi3 Channel 00 Id 0 Lun: 12
                        Attached scsi disk sdn          State: running
                scsi3 Channel 00 Id 0 Lun: 13
                        Attached scsi disk sdo          State: running
                scsi3 Channel 00 Id 0 Lun: 14
                        Attached scsi disk sdp          State: running
                scsi3 Channel 00 Id 0 Lun: 15
                        Attached scsi disk sdq          State: running
                scsi3 Channel 00 Id 0 Lun: 16
                        Attached scsi disk sdr          State: running
                scsi3 Channel 00 Id 0 Lun: 17
                        Attached scsi disk sds          State: running
                scsi3 Channel 00 Id 0 Lun: 18
                        Attached scsi disk sdt          State: running
                scsi3 Channel 00 Id 0 Lun: 19
                        Attached scsi disk sdu          State: running
                scsi3 Channel 00 Id 0 Lun: 2
                        Attached scsi disk sdd          State: running
                scsi3 Channel 00 Id 0 Lun: 20
                        Attached scsi disk sdv          State: running
                scsi3 Channel 00 Id 0 Lun: 21
                        Attached scsi disk sdw          State: running
                scsi3 Channel 00 Id 0 Lun: 22
                        Attached scsi disk sdx          State: running
                scsi3 Channel 00 Id 0 Lun: 23
                        Attached scsi disk sdy          State: running
                scsi3 Channel 00 Id 0 Lun: 24
                        Attached scsi disk sdz          State: running
                scsi3 Channel 00 Id 0 Lun: 25
                        Attached scsi disk sdaa         State: running
                scsi3 Channel 00 Id 0 Lun: 26
                        Attached scsi disk sdab         State: running
                scsi3 Channel 00 Id 0 Lun: 27
                        Attached scsi disk sdac         State: running
                scsi3 Channel 00 Id 0 Lun: 28
                        Attached scsi disk sdad         State: running
                scsi3 Channel 00 Id 0 Lun: 3
                        Attached scsi disk sde          State: running
                scsi3 Channel 00 Id 0 Lun: 4
                        Attached scsi disk sdf          State: running
                scsi3 Channel 00 Id 0 Lun: 5
                        Attached scsi disk sdg          State: running
                scsi3 Channel 00 Id 0 Lun: 6
                        Attached scsi disk sdh          State: running
                scsi3 Channel 00 Id 0 Lun: 7
                        Attached scsi disk sdi          State: running
                scsi3 Channel 00 Id 0 Lun: 8
                        Attached scsi disk sdj          State: running
                scsi3 Channel 00 Id 0 Lun: 9
                        Attached scsi disk sdk          State: running

Outras observações

Por um motivo ou outro, o dispositivo dm que está mapeando para o LUN "físico" está mostrando um aumento considerável nos tempos de espera sempre que as solicitações de gravação são mescladas na fila de solicitações. Mas a minha pergunta é realmente sobre o esperado no dispositivo subjacente - o NetApp FAS deve simplesmente colocar todos os pedidos de gravação em sua NVRAM e confirmar instantaneamente, mesmo para gravações síncronas, então eu nunca deveria ver espera superior a 5ms, desde que o link de rede não está saturado (o que não é) e a NVRAM não está com contrapressão (o que não é - o FAS atualmente não está lidando com nenhuma outra carga).

Os tempos "await" são consideravelmente menores para operações de leitura, mesmo para leituras aleatórias. Os dados sysstat de 10 segundos visualizados de um intervalo em que iozone estava executando o teste aleatório de leitura / gravação (single-threaded automatic teste de tipo executado com O_DSYNC ativado, tamanho do bloco de 8K) está mostrando o efeito: a primeira metade do gráfico são leituras aleatórias, executando em ~ 2-4 kIOPS e ~ 3ms de latência. No segundo semestre, a carga de trabalho está mudando para gravações aleatórias, espera está aumentando para > 10ms e IOPS estão caindo para ~ 100 (a carga é limitada por latência e single-threaded, portanto as IOPS são inversamente proporcionais à latência)

Por algum motivo, ao analisar a captura de tráfego de rede acima, o recurso de estatísticas de tempo de resposta do serviço do Wireshark para SCSI falha ao reconhecer a maioria das chamadas write , encontrando apenas 19 solicitações e reportando um tempo médio de resposta de serviço de 3ms. espere cerca de 500 chamadas e um valor médio de SRT semelhante ao esperado de 34 ms.

O Linux usado é SuSE SLES 11 SP3, Kernel 3.0.101-0.47.55-default.

    

Answer 1

Demasiado longo para um comentário;

Eu não sou um guru do Linux, mas no Windows desabilito o TCP Large Send Offload na NIC, já que ele pode gerar atrasos. Ele envia menos pacotes, mas é maior, mas para IO crítico não é recomendado.

Uma explicação oficial;

The TCP Large Send Offload option allows the AIX TCP layer to build a TCP message up to 64 KB long and send it in one call down the stack through IP and the Ethernet device driver. The adapter then re-segments the message into multiple TCP frames to transmit on the wire. The TCP packets sent on the wire are either 1500-byte frames for a Maximum Transmission Unit (MTU) of 1500 or up to 9000-byte frames for a MTU of 9000 (jumbo frames).

    

Answer 2

Vou editar esta resposta com base em mais informações. Primeiro, precisamos determinar se a espera também está sendo observada pelo Netapp ou apenas pelo host. Se o host detectar um tempo de serviço alto, mas o NAS alegar ter um tempo de serviço baixo, isso é algo entre as portas NAS e a pilha SCSI do servidor.

Qual versão dos dados ontap você está executando? 7 modos ou CDOT? Qual é a configuração do LUN OS e a configuração do igroup OS? Com essas informações, posso fornecer comandos que você pode usar no Netapp para verificar a latência observada no armazenamento.