场景介绍
引入VPC的概念
DPVS社区最初设计的应用场景是IDC的经典网络，并不适用于云化场景。云化场景与IDC经典网络最核心的区别是：经典网络提供的是多用户共享的网络，而VPC提供的是用户专属的网络。VPC内用户可以任意定义云主机的IP地址，而在经典网络模式下，大家挤在一个二层网络里面，IP地址首先要保证不能重合。
如上图所示，VIP:PORT可以唯一表示一个服务，服务后面挂载了多个实例，但在云化场景下，其VIP地址是可以重复的，所以仍然使用VIP:PORT来表示一个具体服务就行不通了。因此DPVS-VXLAN转发层面不能继续沿用DPVS原有的处理逻辑，为了解决这个问题研发团队引入了租户VPC的概念，把服务和VPC关联起来，
不同的VPC可以有相同的VIP:PORT，这也与实际使用方式相吻合，改造后就变成了VXLAN+VIP:PORT来表示一个服务
测试环境
验证环境：vmware虚拟机，服务端centos5.10镜像，DPVS端centos3.10镜像
验证目的：验证dpvs支持VXLAN分支代码功能
验证过程：通过搭建DOCKER VXLAN网络和DPVS-VXLAN软件验证流量转发状态是否正常
转发路径：client->dpvs->vxlan-docker->nginx-docker、
在VM2配置DOCKER VXLAN网络和nginx软件
docker pull nginx
docker network create --subnet 172.18.0.0/16 mynetwork
docker run -d \
--net mynetwork \
--ip 172.18.0.2 \
--restart always \
--name network \
-p 80:80 \
-v /opt/data/nginx:/etc/nginx \
-v /opt/log/nginx:/var/log/nginxo \
-v /opt/share/nginx/html:/usr/share/nginx/html \
nginx:latest
ip link add vxlan_dpvs type vxlan id 100 remote 192.168.209.172 local 192.168.209.165 dstport 4789 dev ens33
ip link set vxlan_dpvs up
ip -d link show vxlan_dpvs
brctl addif br-0187de5d38cb vxlan_dpvs
DPVS配置VXLAN隧道规则表
VIP=192.168.209.172
LIP=172.18.0.7
RS=172.18.0.2
# 将wan ip设置到dpdk0接口
./dpip addr add ${VIP}/32 dev dpdk0
# 添加服务<VIP:vport>用于转发
./ipvsadm -A -t ${VIP}:80 -s rr
# 添加real server
./ipvsadm -a -t ${VIP}:80 -r ${RS} -b --vxlan local=192.168.209.171,remote=192.168.209.165,rport=4789,vni=100,mac=02:42:ac:12:00:02
# 添加local ipVXLAN
./ipvsadm --add-laddr -z ${LIP} -t ${VIP}:80 -F dpdk0
./dpip addr add 192.168.209.171/24 dev dpdk0
ifconfig dpdk0.kni 192.168.209.171 netmask 255.255.255.0
ipvsadm -ln
执行后可查看到规则
| IP Virtual Server version 0.0.0 (size=0) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.209.172:80 rr -> 172.18.0.2 FullNat 3 0 0 192.168.209.171-192.168.209.165:4789-100-02:42:ac:12:00:02 |
在Client端执行curl请求DPVS 的VIP可通
