O que há de errado com o (s) compartilhamento (s) de rede lenta de minha rede rápida?

Question

Eu fiz testes extremos. cp, dd, rysnc, iperf, netcat, custom-dd e provavelmente mais.

O que estou vendo é uma rede strong. Os resultados do iperf abaixo mostram isso, e eu tenho outros dados para validá-lo também.

O que estou procurando é um protocolo de compartilhamento que corresponda a essas velocidades ou aproxime-se delas.

O que estou recebendo atualmente com os protocolos de compartilhamento iSCSI (FreeNAS) e CIFS (WIN7) é de cerca de 1,5 GB / ma 2,5 GB / m. Meu objetivo é de 3,0 GB / m

O que eu poderia estar estragando na minha implementação de protocolo de compartilhamento que está reduzindo drasticamente a velocidade?

root@fdas:~# ./iperf -c 192.168.2.138
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 43066 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.05 GBytes   900 Mbits/sec
root@fdas:~# ./iperf -c 192.168.2.138 -t 60
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 43067 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.22 GBytes   891 Mbits/sec
root@fdas:~# ./iperf -c 192.168.2.138 -t 600
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 35506 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-600.0 sec  62.0 GBytes   887 Mbits/sec

// edite benchmarks io disk adicionados. OBSERVAÇÃO: este teste hdparm é lido em ordem sequencial, e o objetivo final aqui é ler e gravar bytes brutos de um disco (disco inteiro, não partição)

/dev/sdd1 on /a type ext4 (rw)

NOTA: o sdd é o disco iSCSI FreeNAS

root@fdas:~# hdparm -t /dev/sdd

/dev/sdd:
 Timing buffered disk reads:  168 MB in  3.02 seconds =  55.71 MB/sec
root@fdas:~# hdparm -t -T /dev/sdd

/dev/sdd:
 Timing cached reads:   5240 MB in  2.00 seconds = 2620.70 MB/sec
 Timing buffered disk reads:  168 MB in  3.01 seconds =  55.84 MB/sec

    

Answer 1

Você executou benchmarks de E / S de disco no servidor e no cliente? A menos que os subsistemas de disco sejam capazes de obter o throughput desejado, eles serão, obviamente, o gargalo em vez da rede.

    

Answer 2

Na minha experiência, o iSCSI é a menor sobrecarga do grupo, e os jumbo-frames acabam contando. Eu vi o iSCSI saturar uma conexão GigE usando o framework iSCSI LIO-Target e um ramdisk como o alvo. Essa coisa voou. A versão mais antiga da pilha iSCSI do Linux teve alguns problemas de desempenho e não pôde usar um ramdisk para uma taxa de transferência total. Não tenho certeza do que o FreeNAS está executando atualmente, o material do LIO-Target é bastante recente.

Um dos maiores limitadores de tal throughput acaba sendo o backend do sistema de armazenamento. Como eu mencionei, eu obtive a velocidade acima através do uso de um disco RAM (o servidor tinha 32GB de RAM, então valeu a pena tentar). Quando tentei o mesmo teste usando o armazenamento distribuído em 48 discos, consegui saturar o GigE durante os testes sequenciais, mas os testes de E / S aleatórios ficaram bem abaixo disso; na faixa de 65-80MB / s, como eu me lembro.