dpvs部署

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 处理的网络这块