Je connais des taux de transfert OpenVPN extrêmement lents entre deux serveurs. Pour cette question, je vais appeler les serveurs Serveur A et Serveur B.
Le serveur A et le serveur B exécutent CentOS 6.6. Les deux sont situés dans des centres de données avec une ligne de 100 Mbits et les transferts de données entre les deux serveurs en dehors d'OpenVPN tournent près de ~ 88 Mbps.
Cependant, lorsque j'essaie de transférer des fichiers via la connexion OpenVPN que j'ai établie entre le serveur A et le serveur B, j'obtiens un débit d'environ 6,5 Mbps.
Résultats des tests d'iperf:
[ 4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49184
[ 4] 0.0-10.0 sec 7.38 MBytes 6.19 Mbits/sec
[ 4] 0.0-10.5 sec 7.75 MBytes 6.21 Mbits/sec
[ 5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49185
[ 5] 0.0-10.0 sec 7.40 MBytes 6.21 Mbits/sec
[ 5] 0.0-10.4 sec 7.75 MBytes 6.26 Mbits/sec
Mis à part ces tests OpenVPN iperf, les deux serveurs sont pratiquement complètement inactifs avec une charge nulle.
Le serveur A se voit attribuer l'IP 10.0.0.1 et c'est le serveur OpenVPN. Le serveur B se voit attribuer l'IP 10.0.0.2 et c'est le client OpenVPN.
La configuration OpenVPN pour le serveur A est la suivante:
port 1194
proto tcp-server
dev tun0
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
verb 3
La configuration OpenVPN pour le serveur B est la suivante:
port 1194
proto tcp-client
dev tun0
remote 204.11.60.69
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
verb 3
Ce que j'ai remarqué:
1. Ma première pensée a été que je goulot d'étranglement du CPU sur le serveur. OpenVPN est monothread et ces deux serveurs exécutent des processeurs Intel Xeon L5520 qui ne sont pas les plus rapides. Cependant, j'ai exécuté une top
commande lors de l'un des tests iperf et j'ai appuyé 1
pour afficher l'utilisation du processeur par cœur et j'ai constaté que la charge du processeur était très faible sur chaque cœur:
top - 14:32:51 up 13:56, 2 users, load average: 0.22, 0.08, 0.06
Tasks: 257 total, 1 running, 256 sleeping, 0 stopped, 0 zombie
Cpu0 : 2.4%us, 1.4%sy, 0.0%ni, 94.8%id, 0.3%wa, 0.0%hi, 1.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu3 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu8 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu9 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu10 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu12 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu13 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu14 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu15 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 946768k total, 633640k used, 313128k free, 68168k buffers
Swap: 4192188k total, 0k used, 4192188k free, 361572k cached
2. Les temps de ping augmentent considérablement sur le tunnel OpenVPN pendant que iperf est en cours d'exécution. Lorsque iperf n'est pas en cours d'exécution, les temps de ping sur le tunnel sont systématiquement de 60 ms (normal). Mais lorsque iperf fonctionne et pousse un trafic dense, les temps de ping deviennent irréguliers. Vous pouvez voir ci-dessous comment les temps de ping sont stables jusqu'au 4ème ping lorsque j'ai commencé le test iperf:
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=60.2 ms
** iperf test begins **
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=85.6 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=176 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=204 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=231 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=197 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=233 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=152 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=216 ms
3. Comme mentionné ci-dessus, j'ai exécuté iperf en dehors du tunnel OpenVPN et le débit était normal - ~ 88 Mbps en permanence.
Ce que j'ai essayé:
1. Je pensais que la compression pouvait salir les choses, j'ai donc désactivé la compression en supprimant les comp-lzo
deux configurations et en redémarrant OpenVPN. Pas d'amélioration.
2. Même si j'avais précédemment constaté que l'utilisation du processeur était faible, je pensais que le chiffrement par défaut pouvait être un peu trop intensif pour que le système puisse suivre. J'ai donc ajouté cipher RC2-40-CBC
aux deux configurations (un chiffrement très léger) et redémarré OpenVPN. Pas d'amélioration.
3. J'ai lu sur divers forums comment l'ajustement du fragment, de mssfix et de mtu-tun pourrait améliorer les performances. J'ai joué avec quelques variations comme décrit dans cet article , mais encore une fois, aucune amélioration.
Avez-vous des idées sur ce qui pourrait causer de si mauvaises performances OpenVPN?
cipher none
même si je doute que cela puisse aider.