DPVS 3种转发模式

NAT模式

FNAT 模式

FNAT都是双臂模式,即正反向流量都通过DPVS节点。
FULLNAT下,客户端感知不到RS,RS也感知不到客户端,它们都只能看到DPVS。

FNAT单节点

拓扑: 如上图所示,client ip为 10.0.0.48,其他 各节点的IP地址如下:

  1. VIP: client访问的VIP为10.0.0.100:80A
  2. DPVS的local_ip为192.168.100.200
  3. RS1的local_ip 为 192.168.100.2
  4. RS2的local_ip 为 192.168.100.3

可见,此示例中client与DPVS VIP同网段,DPVS的local_ip与RS同网段。

配置

#!/bin/sh## 配置VIP到dpdk1./dpip addr add 10.0.0.100/32 dev dpdk1## 配置 DPVS接口WAN/LAN 路由./dpip route add 10.0.0.0/16 dev dpdk1./dpip route add 192.168.100.0/24 dev dpdk0## 配置VIP监听器,配置轮询模式./ipvsadm -A -t 10.0.0.100:80 -s rr## 配置后端服务器,以及转发模式(-b)./ipvsadm -a -t 10.0.0.100:80 -r 192.168.100.2 -b // -b 表示 FNAT./ipvsadm -a -t 10.0.0.100:80 -r 192.168.100.3 -b## 配置VIP监听器使用的DPVS local_ip./ipvsadm --add-laddr -z 192.168.100.200 -t 10.0.0.100:80 -F dpdk0

注意:
请使用ipvsadm-add laddr设置LIP而不是dpip addr add。。。。因为ipvs和inet模块都需要LIP地址,sapool选项将自动设置

对于FNAT,客户端(源端)的CIP:cport 将被LIP:lport替换。目的端 VIP:vport LIP将被转换为后端的RIP:rport。,如果RS需要通过socket API获取客户端的真实IP:port,例如getpeername或accept,而不是某种应用程序方式。TOA内核模块应该安装在RS上,TOA是为Linux内核的某个版本开发的,其他版本或BSD、mTCP等操作系统内核可能需要移植。

DPVS处理流程:

  1. client访问VIP,发送给DPVS;
  2. DPVS将源IPclient_ip修改为local_ip,源端口修改为某一端口,目的IPVIP修改为某一个后端的IP
  3. RS收到数据包后,因为数据报文的目的ip为自己的ip,接收处理;
  4. 处理后,查找arp、路由表,原路返回给dpvs;
  5. dpvs 将目的ip端口与源ip修改后返回client。

主备

DPVS通过keepalived使其工作在主备模式,通过VRRP协议选举哪个DPVS节点为主。

拓扑: 如上图所示,各节点的IP地址如下:

  1. VIP: client访问的VIP为192.168.100.254:80
  2. DPVS Master的local_ip为192.168.100.200
  3. DPVS Backup的local_ip为192.168.100.201
  4. RS1的local_ip 为 192.168.100.2
  5. RS2的local_ip 为 192.168.100.3

可见,此示例中DPVS、Client、RS都处在内部网络(LAN)中。

配置
使用keepalived,可以通过keepalived配置文件配置DPVS的routes、LIP、VIP和RS。
注意,dpv modified keepalived的配置参数与原始keepalived略有不同。

$ cat /etc/keepalived/keepalived.conf! Configuration File for keepalivedglobal_defs {    notification_email {        foo@example.com    }    notification_email_from bar@example.com    smtp_server 1.2.3.4    smtp_connect_timeout 60    router_id DPVS_DEVEL}## local_ip组中的IP地址,用于DPVS主、备与后端服务器通信local_address_group laddr_g1 {     192.168.100.200 dpdk0    # use DPDK interface    192.168.100.201 dpdk0    # use DPDK interface}#### VRRP 配置区##vrrp_instance VI_1 {    state MASTER                  # master    interface dpdk0.kni           # should be kni interface    dpdk_interface dpdk0          # should be DPDK interface    virtual_router_id 123         # VID should be unique in network    priority 100                  # master's priority is bigger than worker    advert_int 1    authentication {        auth_type PASS        auth_pass ****    }    virtual_ipaddress { # 主节点将配置的VIP        192.168.100.254    }}## Virtual Server Section#virtual_server_group 192.168.100.254-80 {    192.168.100.254 80}## 配置DPVS的工作模式、调度算法、VIP的后端服务器IP,以及后端服务器健康检查方式virtual_server group 192.168.100.254-80 {    delay_loop 3    lb_algo rr         # scheduling algorithm Round-Robin    lb_kind FNAT       # Forwarding Mode Full-NAT    protocol TCP       # Protocol TCP    laddr_group_name laddr_g1   # Local IP group-ID    real_server 192.168.100.2 80 { # real-server        weight 100        inhibit_on_failure        TCP_CHECK {    # health check            nb_sock_retry 2            connect_timeout 3            connect_port 80        }    }    real_server 192.168.100.3 80 { # real-server        weight 100        inhibit_on_failure        TCP_CHECK { # health check            nb_sock_retry 2            connect_timeout 3            connect_port 80        }    }}

备份的keepalived配置与Master相同,只是状态应该是backup,优先级应该更低。

vrrp_instance VI_1 {    state BACKUP    priority 80    ... ...}

在DPVS主备节点中,启动keepalived。

./keepalived -f /etc/keepalived/keepalived.conf

DPVS处理流程:

  1. client通过二层转发访问VIP,发送给DPVS;
  2. DPVS将源IPclient_ip修改为local_ip,源端口修改为某一端口,目的IPVIP修改为某一个后端的IP
  3. rs收到数据包后,因为数据报文的目的ip为自己的ip,接收处理;
  4. 处理后,查找arp、路由表,原路返回给dpvs master;
  5. dpvs master将目的ip端口与源ip修改后返回给client。

优势:
后端服务端不用为DPVS负载均衡做任何配置。

缺点:
后端服务器无法获得客户端的IP。需要使用TOA携带客户端IP到后端服务器。

主主

DPVS通过OSPF/ECMP实现主主模式。

要使用OSPF,必须将patch/dpdk xxx/中的补丁应用于相应的dpdk源代码,并安装正确的rte_kni.ko。
DPVS主主集群模式拓扑如下图所示:每一个DPVS都有一个相同的VIP,每一个DPVS都连接所有后端服务器。

对于主主集群中的单个DPVS节点,其拓扑图如下图所示。

拓扑: client的IP为20.17.11.3,其他各节点的IP地址如下:

  1. VIP: client访问的VIP为123.1.2.3:80
  2. 主主DPVS 的local_ip为192.168.100.200
  3. DPVS主1的内核态IP为 172.10.0.2/30
  4. ECMP router的IP地址为172.10.0.1/30
  5. RS1的local_ip 为 192.168.100.2
  6. RS2的local_ip 为 192.168.100.3
#!/bin/sh -## 配置VIP,调度模式为轮询./ipvsadm -A -t 123.1.2.3:80 -s rr## 配置后端服务器为FNAT,转发模式为FNAT(-b)./ipvsadm -a -t 123.1.2.3:80 -r 192.168.100.2 -b./ipvsadm -a -t 123.1.2.3:80 -r 192.168.100.3 -b## 添加DPVS的local_ip./ipvsadm --add-laddr -z 192.168.100.200 -t 123.1.2.3:80 -F dpdk0./ipvsadm --add-laddr -z 192.168.100.201 -t 123.1.2.3:80 -F dpdk0## 配置DPVS的DPDK1的IP与路由./dpip addr add 123.1.2.3/32 dev dpdk1./dpip addr add 172.10.0.2/30 dev dpdk1./dpip route add default via 172.10.0.1 dev dpdk1

配置内核态的接口Dpdk1.kni的IP地址与路由。

$ ip link set dpdk1.kni up$ ip addr add 172.10.0.2/30 dev dpdk1.kni$ ip addr add 123.1.2.3/32 dev dpdk1.kni # add VIP to kni for ospfd$ ip route add default via 172.10.0.1 dev dpdk1.kni

DPVS处理流程:

  1. client访问访问VIP,发送给DPVS,经过ECMP router;
  2. router将访问VIP的流量分发给不同的DPVS,通过修改 dst_mac为172网段的接口MAC;
  3. DPVS收到数据包后,进行FNAT后,发给后端服务器RS;
  4. RS收到数据包后,因为数据报文的目的ip为自己的ip,正常接收处理;
  5. 处理后,查找arp、路由表,原路返回给原来的dpvs节点(不同的节点DPVS的local_ip不一样);

DNAT 模式

DNAT为双臂模式。

拓扑: 如上图所示,各节点的IP地址如下:

  • client: 192.168.0.46
  • VIP: 192.168.0.89
  • DPVS local ip: 192.168.0.66, 10.140.31.48
  • RS1: 10.140.18.33
  • RS2: 10.140.18.33

可见,所有的IP地址都在一个局域网内。

DNAT模式约束:
DPVS-DNAT模式有一个严格的限制:DPVS-DNAT模式只能在单个lcore中工作。由于以下原因,dpv很难支持多lcore NAT转发模式。

  • DPVS会话条目通过RSS在lcore上进行拆分和分发。
  • DNAT转发要求正、反方向流量都通过DPVS。
  • DNAT转发只转换dest IP/端口,不更改源IP/端口。
  • NIC的fdir规则设置有限。

因此,如果没有对流量的其他控制,则出站数据包可能到达与入站数据包不同的lcore。如果是,出站数据包将被丢弃,因为会话查找未命中。

FNAT通过使用Flow Director(FDIR)解决了这个问题。但是,对于NIC,可以添加的规则非常有限,例如,对于XT-540,可以添加8K。
与FNAT不同,NAT没有本地IP/端口,因此只能在源IP/端口上设置FDIR规则,这意味着只支持数千个并发。因此,FDIR不适用于NAT。

注意:从v1.7.2开始,就为多lcore NAT模式转发提供了解决方案。其原理是通过全局重定向表和一些无锁环将出站数据包重定向到其会话项所在的正确lcore。当然,这在一定程度上会损害性能。如果要使用它,请在/etc/dpvs.conf中打开配置开关ipvs_defs/conn/redirect。

DR模式

DR是 Direct Routing 的缩写。DR模式是单臂模式。

DR模式中,DPVS改写请求报文的 dst_mac,将请求发给RS,RS响应后的处理结果直接返回给客户端用户。

拓扑: 如上图所示,各节点的IP地址如下:

  • client: 192.168.100.26
  • VIP: 192.168.100.254
  • DPVS local ip: 192.168.100.1
  • RS1: 192.168.100.2, lo接口IP配置为VIP
  • RS2: 192.168.100.3,lo接口IP配置为VIP

可见,所有的IP地址都在一个局域网内。

配置VIP与对应RS的命令如下:

## 配置VIP:port,设置调度为rr./ipvsadm -A -t 192.168.100.254:80 -s rr ## 配置VIP的RS,模式为-g,即DR模式./ipvsadm -a -t 192.168.100.254:80 -r 192.168.100.2 -g ./ipvsadm -a -t 192.168.100.254:80 -r 192.168.100.3 -g

DPVS处理流程:

  1. client通过二层转发访问VIP,发送给DPVS;
  2. DPVS将 dst_mac修改为所有RS中的一个的mac地址;
  3. RS收到数据包后,因为数据帧的MAC地址是自己的地址,并且又在同一个局域网,接收处理;
  4. 处理后,查找ARP、路由表,找到client的MAC地址后直接发给client。源IP地址还是VIP。

优势:
采用NAT模式时,由于请求和响应的报文必须通过调度器地址重写,当客户请求越来越多时,调度器处理能力将成为瓶颈。
DR模式中,RS将响应处理后的数据直接返客户端。这样调度器就只处理请求入站报文,由于一般网络服务应答数据比请求报文大很多,采用DR模式,集群系统的最大吞吐量可以提高10倍。

TUN模式

NAT模式不同,TUN与DR模式一样,LB和RS之间的传输不用改写IP地址。
TUN模式把客户请求包封装在一个IP tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后解开IP tunnel,处理响应,然后直接把包通过自己的外网地址发送给客户,不需要经过DPVS。

拓扑: 如上图所示,各节点的IP地址如下:

  • client: 10.138.85.23/22
  • VIP: 10.140.31.48/32
  • DPVS: 10.140.31.254/32 为隧道地址,
  • RS1: 10.140.31.48/32 为隧道地址,eth0 10.140.18.33/20
  • RS2: 10.140.31.48/32 为隧道地址, eth0 10.40.84.170/21

与underlay DR模式不同,隧道模式中同网段是DPVS与RS之间的隧道地址,通过dpvs和RSs之间的ipip隧道在L2网络上转发数据包。

配置VIP、RS、DPVS的命令如下:

## DPVS configs ### 配置DPVS与RS进行通信的隧道地址./dpip addr add 10.140.16.48/20 dev dpdk0# 添加 VIP地址为 DPVS 的地址./dpip addr add 10.140.31.48/32 dev dpdk0# 配置到RS隧道地址IP的路由表。所有RS中的隧道地址相同,且为 VIP 地址。./dpip route add default via 10.140.31.254 src 10.140.16.48 dev dpdk0# 配置VIP./ipvsadm -A -t 10.140.31.48:80 -s rr# 配置VIP的后端RS的eth0 IP。-i 代表隧道模式./ipvsadm -a -t 10.140.31.48:80 -r 10.140.18.33 -i  # 配置VIP的另一个后端RS的eth0 IP。-i 代表隧道模式./ipvsadm -a -t 10.140.31.48:80 -r 10.40.84.170 -i

DPVS处理流程:

  1. client 请求数据包,目标地址VIP发送到DPVS;
  2. DPVS接收到客户请求包,进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。
  3. RS节点服务器根据IP Tunnel包头信息收到请求包,然后解开IP Tunnel包头信息,得到客户的请求包并进行响应处理。
  4. 响应处理完毕之后,RS服务器使用自己的出公网的线路,将这个响应数据包发送给客户端。源IP地址还是VIP地址。(RS节点服务器需要在本地回环接口配置VIP)

参考

NFVSchool 微信公共号
NFVSchool,关注最前沿的网络技术。

Was this helpful?

0 / 0

发表回复 0