tcpcopy线上部署以及github提交的一个issue

给自己留存一个美好的回忆
github提交的issue

● 发现tcpcopy在开启单个进程多倍流量转发时会出现cpu单核心使用率过高导致rst包的现象，后来通过抓包排查等多钟方法以外发现是单进程tcpcopy的cpu无法响应造成的，后来启动6个tcpcopy进程同时一倍流量没有啥问题。

● Online Server(OS)：上面要部署 TCPCopy，从数据链路层(pcap 接口)抓请求数据包，发包是从IP层发出去；
● Test Server(TS)：最新的架构调整把 intercept 的工作从 TS 中 offload 出来。TS 设置路由信息，把 被测应用 的需要被捕获的响应数据包信息路由到 AS；
● Assistant Server(AS)：这是一台独立的辅助服务器，原则上一定要用同网段的一台闲置服务器来充当辅助服务器。AS 在数据链路层截获到响应包，从中抽取出有用的信息，再返回给相应的 OS 上的 tcpcopy 进程。

请配合下图1理解：

10.116.95.87 target server

10.116.95.81 intercept
/usr/local/intercept/sbin/intercept -i eth1 -F 'tcp and src port 9999'  -l /data/intercept.log -d

10.116.95.82线上
/usr/local/tcpcopy/sbin/tcpcopy -x 80-10.116.95.87:9999 -s 10.116.95.81  -m 20480 -c 192.168.2.x -n 1  -l  /data/tcpcopy.log -d

线上服务器
10.116.95.82
## 部署
cd /usr/local/src && rsync -avzP bigdata.vxlan.net::wVioz35SWO9zywesmagfOrP9XjigoF8j/tcpcopy/* .
cd /usr/local/src/tcpcopy && ./configure --prefix=/usr/local/tcpcopy/   && make -j 10 && make install

target server
10.116.95.81
yum install -y libpcap-devel
mkdir /usr/local/src/intercept
cd /usr/local/src/intercept && rsync -avzP bigdata.vxlan.net::wVioz35SWO9zywesmagfOrP9XjigoF8j/tcpcopy/intercept/* .
cd /usr/local/src/intercept && ./configure --prefix=/usr/local/intercept/ && make -j 10 && make install

使用
第一步

10.116.95.87
route add -net 192.168.2.0/24 gw 10.116.95.81
#route del -net 192.168.2.0/24 gw 10.116.95.82
10.116.95.81
/usr/local/intercept/sbin/intercept -i eth1 -F 'tcp and src port 9999'  -l /data/intercept.log -d
第二步
10.116.95.82
/usr/local/tcpcopy/sbin/tcpcopy -x 80-10.116.95.87:9999 -s 10.116.95.81  -m 20480 -c 192.168.2.x -n 1  -l  /data/tcpcopy.log -d
/usr/local/tcpcopy/sbin/tcpcopy -x 80-10.116.95.87:9999 -s 10.116.95.81  -m 20480 -c 192.168.2.x -n 1  -l  /data/tcpcopy.log -d

内核调一调

内核参数调整一下
kernel.sysrq = 1
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.ip_forward = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
#############################
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.arp_announce = 2
##net.nf_conntrack_max= 2031616
##net.netfilter.nf_conntrack_checksum = 0
##net.netfilter.nf_conntrack_tcp_timeout_established= 38
############ bigdata define ###########
net.core.somaxconn = 20480
net.ipv4.ip_local_reserved_ports = 8000-9000,28000-29000
net.ipv6.conf.all.disable_ipv6 = 1
net.core.netdev_max_backlog = 20480
net.ipv4.tcp_max_tw_buckets = 800000
net.ipv4.tcp_max_syn_backlog = 20480
net.ipv4.tcp_keepalive_time=30
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=3
##net.netfilter.nf_conntrack_max = 4096000

如果采用的是IP Queue模块来截获响应包，则intercept程序密切跟ip queue内核模块相关，所以当压力很大的时候请求丢失率很高，需要优化sysctl系统参数才能达到好的效果（通过cat /proc/net/ip_queue，查看ip queue运行情况，如果Queue dropped的数值不断增大，则需要修改ip_queue_maxlen参数，比如echo 4096 > /proc/sys/net/ipv4/ip_queue_maxlen；如果Netlink dropped的数值不断增大，修改net.core.rmem_max和net.core.wmem_max参数,比如sysctl -w net.core.rmem_max=16777216和sysctl -w net.core.wmem_max=16777216）
从给的少量log来看，存在着ip_queue内核模块丢响应包的可能性。
先从ip queue入手，调大后，看是否还有此问题


pf_ring安装

yum -y install subversion flex bison ethtool