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
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值