dpvs部署

  • 来源:网络
  • 更新日期:2020-07-14

摘要:建站服务器 安装dpdk 官方URL https://github.com/iqiyi/dpvs dpdk-17.05.2可以兼容dpvswget https://fast.dpdk.org/rel/dpdk-17.05.2.

建站服务器

安装dpdk

官方URL https://github.com/iqiyi/dpvs

dpdk-17.05.2可以兼容dpvs
wget https://fast.dpdk.org/rel/dpdk-17.05.2.tar.xz
tar vxf dpdk-17.05.2.tar.xz

下载dpvs
git clone https://github.com/iqiyi/dpvs.git

给dpdk打补丁,加入kni驱动
cd <path-of-dpvs>
cp patch/dpdk-stable-17.05.2/*.patch dpdk-stable-17.05.2/
cd dpdk-stable-17.05.2/
patch -p 1 < 0001-PATCH-kni-use-netlink-event-for-multicast-driver-par.patch

另一个补丁,uoa模块
patch -p1 < 0002-net-support-variable-IP-header-len-for-checksum-API.patch

编译dpdk并安装
cd dpdk-stable-17.05.2/
make config T=x86_64-native-linuxapp-gcc
make
export RTE_SDK=$PWD

启动hugepage
服务器是numa系统(centos)
echo 8192 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
echo 8192 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

mkdir /mnt/huge
mount -t hugetlbfs nodev /mnt/huge

注:这个操作是临时的,如果服务器有别的应用再跑,可能已经占用hugepage了,后面给出另外的方法

安装uio驱动,并绑定网卡
modprobe uio
cd dpdk-stable-17.05.2
insmod build/kmod/igb_uio.ko
insmod build/kmod/rte_kni.ko

查看网卡状态 ./usertools/dpdk-devbind.py --status

Network devices using kernel driver

===================================

0000:01:00.0 \'I350 Gigabit Network Connection 1521\' if=eth0 drv=igb unused=

0000:01:00.1 \'I350 Gigabit Network Connection 1521\' if=eth2 drv=igb unused=

0000:01:00.2 \'I350 Gigabit Network Connection 1521\' if=eth3 drv=igb unused=

0000:01:00.3 \'I350 Gigabit Network Connection 1521\' if=eth4 drv=igb unused=

绑定eth3
./usertools/dpdk-devbind.py -b igb_uio 0000:01:00.2

注:这里绑定的网卡,最好是没有使用的,因为网卡需要down 掉才能绑

编译dpvs
cd dpdk-stable-17.05.2/
export RTE_SDK=$PWD
cd <path-of-dpvs>
make

make install

注:安装的时候 可能有依赖包报错,提示哪个,yum安装就可以了

编译后的文件
ls bin/
dpip dpvs ipvsadm keepalived

启动dpvs
cp conf/dpvs.conf.single-nic.sample /etc/dpvs.conf
cd <path-of-dpvs>/bin
./dpvs &

查看是否启动正常
./dpip link show
1: dpdk0: socket 0 mtu 1500 rx-queue 8 tx-queue 8
UP 10000 Mbps full-duplex fixed-nego promisc-off
addr A0:36:9F:9D:61:F4 OF_RX_IP_CSUM OF_TX_IP_CSUM OF_TX_TCP_CSUM OF_TX_UDP_CSUM

以DR模式举例

官方URL https://github.com/iqiyi/dpvs/blob/master/doc/tutorial.md ,各种lvs模式配置

给dpvs添加lan ip 37,这个步骤必须在添加vip之前

./dpip addr add 192.168.1.37/24 dev dpdk0

给dpvs添加vip 57

./dpip addr add 192.168.1.57/32 dev dpdk0

设置算法为rr,vip为57

./ipvsadm -A -t 192.168.1.57:80 -s rr

添加后端机器11

./ipvsadm -a -t 192.168.1.57:80 -r 192.168.1.11 -g

在11机器执行
ip addr add 192.168.1.11/32 dev lo
sysctl -w net.ipv4.conf.lo.arp_ignore=1

dpvs在启动的时候,有时候 会报错,罪魁祸首是内存碎片,app无法申请到足够多的连续大块内存,只能申请到很多小块内存。以至于内存块数目超过了系统设置的256个。

解决方式 就是申请大页内存应该在系统启动时,或系统启动后尽快申请,避免内存被割裂

https://www.cnblogs.com/cobbliu/p/6603391.html

为了省事 可以加入到kernel参数 /etc/boot/grub2.cfg

default_hugepagesz=1G hugepagesz=1G hugepages=8G

引用别人的结论:
结论:DPDK 再快也是收包到送给应用层的时间短,而不是“转发”快。收到包后,各类检查跟查表(一般都是并发环境,加锁啊什么的,无锁?……哈哈)处理的时间,基本上都是要远远超过 DPDK 的自身开销的。

想要快过 Linux,要明白为什么 Linux 网络协议栈会“慢”,这个慢是相比 DPDK 的处理而言的,对大部分应用而言,上层的业务延迟已经没多大必要在网络方面下功夫。总之,能否降低路有延迟,要看应用环境(买得起那么多物理机么?有相应的稳定可靠人才支撑么?),然后再做 profiling,看瓶颈在哪里。不要想当然的 DPDK。

举例来说吧,做 UDP 的 dns,就可以用 DPDK,绕过 Linux 协议栈提升 QPS. 如果做路由,我觉得拼不过硬件,我是不赞同这种做法的。为了低延迟,没有包的时候,DPDK 都要让 CPU 满载跑着,这时如果想提升吞吐量,延迟也会跟着上去。如果系统里边是多个干活程序一起跑的,老板穷或者不舍得买好机器,开发运维技能没跟着上去,DPDK 也会被用残的。

硬件差不多,网络 IO+内存类的程序,Linux 跑万兆是没问题的。

如果做包转发,相比 x86 linux 肯定会大大提升性能,其实大部分瓶颈不在 dpdk 处理的网络这块

新网虚拟主机