DPVS 測試需要的環境比較復雜，按照官方文檔 simple fnat 測試一下單機雙臂 fnat. 關于安裝編繹沒啥好說的，按 github 做就可以，但是一定要打開 DEBUG 模式，并且日志級別也為 DEBUG
測試環境
ubuntu 16.04.5
# uname -a
Linux jjh-dpvs-test0 4.4.0-116-generic 140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
lspci -v | grep Eth
02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
兩個 I350 網卡用于測試，剩于網卡用于 ssh 暫時不用
ip 分配
┌───────────────────┐ ┌────────────────┐
│ dpvs │ │ │
│ │ │ real server │
│ │ ┌──────?│10.20.34.24:6379│
│ │ │ │ │
│ │ │ │ │
│ │ │ └────────────────┘
┌─────┴───────┐ ┌─────┴───────┐ │
│ │ │ │ │
│ │ │ │──────┘
┌──────────────┐ │ dpdk1 │ │ │
│ │ │ VIP │ │ dpdk0 │
│ client │ │10.20.101.43:│ │ LIP │
│ 10.34.38.43 ├───────?│ 6379 │ │10.20.102.41 │
│ │ │ │ │ │
└──────────────┘ │ │ │ │──────┐
│ │ │ │ │
└─────┬───────┘ └─────┬───────┘ │
│ │ │ ┌────────────────┐
│ │ │ │ │
│ │ │ │ real server │
│ │ └──────?│10.20.74.41:6379│
│ │ │ │
└───────────────────┘ │ │
└────────────────┘
Client IP: 10.34.38.43 測試客戶端網卡
DPDK1 VIP: 10.20.101.43 wan 網卡
DPDK0 LIP: 10.20.102.41 lan 網卡
RS1: 10.20.34.24
RS2: 10.20.74.41
配置服務
wan 網卡添加 vip
dpip addr add 10.20.101.43/32 dev dpdk1
添加 wan 默認路由
dpip route add default via 10.20.101.254 dev dpdk1
在 client 機器 ping vip 確保生效
ping 10.20.101.43
PING 10.20.101.43 (10.20.101.43) 56(84) bytes of data.
64 bytes from 10.20.101.43: icmp_seq=1 ttl=58 time=3.66 ms
64 bytes from 10.20.101.43: icmp_seq=2 ttl=58 time=3.52 ms
添加 ipvs service 輪循算法
ipvsadm -A -t 10.20.101.43:6379 -s rr
添加兩個 rs
ipvsadm -a -t 10.20.101.43:6379 -r 10.20.34.24:6379 -b
ipvsadm -a -t 10.20.101.43:6379 -r 10.20.74.41:6379 -b
添加 lan lip
ipvsadm --add-laddr -z 10.20.102.41 -t 10.20.101.43:6379 -F dpdk0
添加 dpdk0 默認路由
dpip route add default via 10.20.102.254 dev dpdk0
在 client 機器 ping lip 確保生效
ping 10.20.102.41
PING 10.20.102.41 (10.20.102.41) 56(84) bytes of data.
64 bytes from 10.20.102.41: icmp_seq=1 ttl=58 time=3.52 ms
64 bytes from 10.20.102.41: icmp_seq=2 ttl=58 time=3.43 ms
至少配置完成，這里走了些彎路，由于歷史原因交換機配置導致 lip 不通。感謝 sys 組春波同學幫忙。
測試效果
redis-cli -h 10.20.101.43 -p 6379 get a
發現在測試機訪問 redis 服務失敗，排查看看到底哪里出了問題。
client 機器執行
tcpdump port 6379 -i bond0 -n
rs 兩個機器執行
tcpdump port 6379 -i bond0 -n
dpvs 觀察日志
tail -f /var/log/dpvs.log
然后再訪問 redis 服務
redis-cli -h 10.20.101.43 -p 6379 get a
測試 client 輸出
13:32:22.130615 IP 10.34.38.43.37943 > 10.20.101.43.6379: Flags [S], seq 1653003455, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:32:23.127957 IP 10.34.38.43.37943 > 10.20.101.43.6379: Flags [S], seq 1653003455, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
連續發了兩個 syn 包，也就是說第一次 syn 超時后又重試了一次。
看下 rs 輸出
13:32:22.127008 IP 10.20.102.41.1029 > 10.20.34.24.6379: Flags [S], seq 338949052, win 29200, options [exp-9437,mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:32:22.127035 IP 10.20.34.24.6379 > 10.20.102.41.1029: Flags [S.], seq 930729927, ack 338949053, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:32:23.123551 IP 10.20.34.24.6379 > 10.20.102.41.1029: Flags [S.], seq 930729927, ack 338949053, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:32:23.124287 IP 10.20.102.41.1029 > 10.20.34.24.6379: Flags [S], seq 338949052, win 29200, options [exp-9437,mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:32:23.124304 IP 10.20.34.24.6379 > 10.20.102.41.1029: Flags [S.], seq 930729927, ack 338949053, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:32:25.123557 IP 10.20.34.24.6379 > 10.20.102.41.1029: Flags [S.], seq 930729927, ack 338949053, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
可以看到 rs 10.20.34.24 己經給 dpvs lip 10.20.102.41 回復 syn+ack 包了，但是沒有完成第三次握手。
再來看下 dpvs 日志
IPVS: conn lookup: [6] TCP 10.34.38.43:37943 -> 10.20.101.43:6379 miss
SAPOOL: sa_pool_fetch: 10.20.102.41:1029 fetched!
IPVS: new conn: [6] TCP 10.34.38.43:37943 10.20.101.43:6379 10.20.102.41:1029 10.20.34.24:6379 refs 2
IPVS: state trans: TCP in [S...] 10.34.38.43:37943->10.20.34.24:6379 state NONE->SYN_RECV conn.refcnt 2
IPVS: conn lookup: [3] TCP 10.20.34.24:6379 -> 10.20.102.41:1029 miss
IPVS: tcp_conn_sched: [3] try sched non-SYN packet: [S.A.] 10.20.34.24:6379->10.20.102.41:1029
IPVS: conn lookup: [3] TCP 10.20.34.24:6379 -> 10.20.102.41:1029 miss
IPVS: tcp_conn_sched: [3] try sched non-SYN packet: [S.A.] 10.20.34.24:6379->10.20.102.41:1029
IPVS: conn lookup: [6] TCP 10.34.38.43:37943 -> 10.20.101.43:6379 hit
IPVS: conn lookup: [3] TCP 10.20.34.24:6379 -> 10.20.102.41:1029 miss
IPVS: tcp_conn_sched: [3] try sched non-SYN packet: [S.A.] 10.20.34.24:6379->10.20.102.41:1029
IPVS: conn lookup: [3] TCP 10.20.34.24:6379 -> 10.20.102.41:1029 miss
IPVS: tcp_conn_sched: [3] try sched non-SYN packet: [S.A.] 10.20.34.24:6379->10.20.102.41:1029
首先，可以看到從 sa_pool 中正確的獲取了本地端口 1029，然后將 syn 包轉發到了后端 rs 10.20.34.24, 狀態由 NONE 變成了 SYN_RECV
然后 dpvs 接到 rs 的 syn+ack 回包，去查找 session 流表時發現 miss 然后就把包 drop 了。可以看到數據是 cpu [6] 發送的，但是返程數據接收的是 cpu[3]
問題原因
由現象可以得知，是返程數據親和性問題，通過官方 issue 及文檔，得知 我的測試網卡 I350 暫時不支持 flow director, 所以只能用 1 worker 來測試。下周申請萬兆網卡測試吧，還得做性能測試。
小感概一下，對于開源軟件，如果不懂源碼有些問題真是無從下手。
更新20181204
在 sys 組春波和文強的幫助下，換了萬兆網卡，simple fullnat 測試通過。下一步做單機的性能測試，最后是 ospf + funat
