OpenVPN性能-数据采集

环境:所有的机器全部千兆以太网线直连,无switch,系统不使用任何netfilter
操作系统及内核版本:
Debian6 2.6.32-5-amd64
网卡驱动信息:
driver: e1000e
version: 1.3.10a-NAPI
firmware-version: 2.1-0
bus-info: 0000:01:00.0
机器部署:
S0:
eth0:192.168.188.195 mtu 1500 e1000e 1000baseT-FD flow-control ->S1:eth0
route:10.0.188.139   gw  192.168.188.193
S1:
eth0:192.168.188.193 mtu 1500 e1000e 1000baseT-FD flow-control ->S0:eth0
eth1:10.0.188.193    mtu 1500 e1000e 1000baseT-FD flow-control ->S2:eth1
S2:
eth1:10.0.188.139    mtu 1500 e1000e 1000baseT-FD flow-control ->S1:eth1
测试一:估算裸速率
1.1.wget -O /dev/null http://10.0.188.139/5G.file
116M/s
1.2.ab -k -c 8 -n 500 http://10.0.188.138/5m.html
Transfer rate:          114621.05 [Kbytes/sec] received
1.3.启动两个wget -O /dev/null http://10.0.188.139/5G.file
3M/s+3M/s
1.4.
wget -O /dev/null http://10.0.188.139/5G.file
wget -O /dev/null http://192.168.188.193/5G.file
102M/s+98M/s
结论:
裸速率大致为115M/s左右,1.3的速率很低是由于apache服务器的并发随机读大文件引起的,对于5m.html是可以缓存于内存的。
测试二:估算OpenVPN的传输速率以及LVS的影响
OpenVPN+LVS
命令:ab -k -c 8 -n 500 http://10.0.188.139/5m.html
部署S3和S4机器用于LVS,删除S0上的10.0.188.139路由:
S3:
eth0:192.168.188.194 mtu 1500 e1000e 1000baseT-FD flow-control ->千兆hub1(对应S1:eth0也连入hub1)
eth1:10.0.188.194    mtu 1500 e1000e 1000baseT-FD flow-control ->千兆hub2(对应S2:eth1也连入hub2)
lo:  192.168.188.34  eth0.arp_ignore=2
S4:
eth0:192.168.188.196 mtu 1500 e1000e 1000baseT-FD flow-control ->千兆hub1(对应S0:eth0也连入hub1)
LVS部署在S1上:
ipvsadm -A -t 192.168.188.34:1194 -s wrr
ipvsadm -a -t 192.168.188.34:1194 -r 192.168.188.193:1194 -g -w 1
ipvsadm -a -t 192.168.188.34:1194 -r 192.168.188.194:1194 -g -w 1
arping -i eth0 -S 192.168.188.34 -B -c 1
S0和S4上启动OpenVPN,确认负载到了S1和S3:
0.0.0.0 tcp 1194
在共享的同一个池中分配虚拟ip
2.1.S0和S4添加10网段路由到tun网关,S0执行:ab -k -c 8 -n 500 http://10.0.188.139/5m.html
Transfer rate:          30704.92 [Kbytes/sec] received
2.2.S0和S4添加10网段路由到tun网关,S0和S4同时执行:ab -k -c 8 -n 500 http://10.0.188.139/5m.html
Transfer rate:          29501.07 [Kbytes/sec] received
2.3.S0和S4添加10网段路由到tun网关,S0上执行两个:ab -k -c 8 -n 500 http://10.0.188.139/5m.html
Transfer rate:          14106.03 [Kbytes/sec] received
Transfer rate:          15710.12 [Kbytes/sec] received
结论1:LVS对总负载量是线性叠加的,以下为了简单,撤掉LVS,撤掉S3
2.4.S0上执行1个:ab -k -c 8 -n 500 http://10.0.188.139/5m.html
Transfer rate:          31334.25 [Kbytes/sec] received
cpuS0:30%
cpuS1:100%
2.5.S0上执行2个:ab -k -c 8 -n 500 http://10.0.188.139/5m.html
Transfer rate:          13650.10 [Kbytes/sec] received
Transfer rate:          12030.41 [Kbytes/sec] received
cpuS0:32%
cpuS1:100%
2.6.S4连接S1,S4和S0上各执行1个:ab -k -c 8 -n 500 http://10.0.188.139/5m.html
Transfer rate:          14010.40 [Kbytes/sec] received
Transfer rate:          14261.39 [Kbytes/sec] received
cpuS0:17%
cpuS1:100%
结论2:OpenVPN服务端总速率最大就是30M/s左右了,所有客户端分享总的30M/s,一旦多一个客户端,原有客户端的速率就会下降到(1/N),同时cpu利用率也会大致等比下降,因此猜测当有三个客户端接入时,各自速率会在10M/s左右,各自cpu利用率降至10%以下。
2.7.证实了结论2的猜测。
2.8.由于OpenVPN的架构为一个while(1),因为无法利用多cpu优势,并且还会因为存在多个cpu,调度器将OpenVPN在多个cpu上调度,减少cache亲和力从而带来劣势:
2.8.1.只要有数据传输,服务器端cpu基本在100%,且只占用一个,此由OpenVPN的结构导致--一个while大循环
2.8.2.设置cipher none,降低cpu在计算上的使用,但是增加了其在传输上的使用
2.8.3.==〉启动多个OpenVPN,绑定于多个cpu上
2.8.4.每物理机器2个OpenVPN进程,每个进程绑定在不同的cpu上(可以通过mount -t cpuset cpu /cpuset来实现)。带来1M/s左右的影响
结论3:操作系统内核的调度系统值得信赖,没有必要绑定进程到cpu。之所以2.8.4没有带来什么优化,可能是因为除了绑定cpu外,还要将网卡中断以及softirq绑定在同一个cpu上,具体没有测试。如果绑定两个OpenVPN到相同的cpu,很显然,速率减半。
2.9.日志输出也是一种损耗,故设置:verb 0,但是不到1M/s的影响
2.10.考虑到tso的影响,tcp模式的OpenVPN两端打开/关闭OpenVPN传输网卡的tso速率影响不到1M/s
2.11.tcp和udp
2.11.1.udp
千兆以太网,单客户端,单机器单服务器,统计速率28M/s
2.11.2.tcp
千兆以太网,单客户端,单机器单服务器,统计速率30M/s
2.11.3.tcp+udp
千兆以太网,两客户端,单机器两服务器,统计速率tcp为30M/s,udp为27M/s
tcp和udp的抓包情况
tcpdump-tcp:length 1448
tcpdump-udp:length 1450,length 77
结论4:千兆局域网环境tcp丢包率低,两段速率匹配,窗口稳定,又有丰富的优化算法,因此tcp虽然要ack,速率也很快;千兆环境udp传输了额外的包。
网络环境好的情况下(hub/交换机直连速率自协商或者通过有限个路由器且速率匹配的以太网环境),tcp性能优于udp;网络环境差,丢包率高,会引起重传迭加导致重传风暴,udp效率高于tcp
总体结论:
1.开启tso,虽然意义不明显
2.单个物理机器启动cpus个OpenVPN进程
3.设置简单cipher,比如bf,rc4之类的
4.启动特定服务S,伪实时监控cpus个OpenVPN进程,等待client连接,然后汇报负载最小的OpenVPN所在机器的ip和protocol/port
5.不使用LVS进行单台机器自负载,而是在连接前动态从服务端特定服务S下载ip+port,然后连接该ip和port
6.除了不得已使用netfilter之外,不要使用。
7.1-6一直在抱怨外部环境,比如tso,netfilter之类的,还是想想自己哪里不对吧,比如tun设备,比如OpenVPN程序
8.tun驱动的字符设备的read例程每次仅仅取出一个以太帧
9.OpenVPN调用了mss_fixup修改了mss,如何发现的呢?
9.1.设置服务器/客户端两端tun的mtu为9000,在客户端的tun0上抓取本地发起的到OpenVPN服务器端虚拟ip地址连接的tcp syn包,mss为8933多,而服务端的synack的mss为1383多,而同时在OpenVPN服务端抓取的同样连接的syn包的mss为1383,而synack的mss为8933,中间仅经过了tun字符设备和OpenVPN,tun字符设备不会修改用户数据,只有OpenVPN了,然后就找到了mss_fixup调用,这实在是一次中间人攻击。

标签: 无
返回文章列表 文章二维码
本页链接的二维码
打赏二维码