快网CloudXNS授权转发简述

　　有幸全程参与了基于DPDK[^1]下一代高性能CloudXNS[^2]服务器开发，从未知到慢慢熟悉，其中也走了些弯路也踩过一些坑，一路走来有些感受与心得体会，在此进行梳理下，以对这一阶段做下些小的总结，也可以与同僚们进行交流学**。

　　背景

　　上一代XNS服务器是基于Linux内核进行开发，单机性能达到数百万级别QPS[^3]，相对于BIND[^4]来说已经高了很多,平常处理正常毫无压力，但在受大量DDOS攻击时服务质量**降低,虽然我们采用了远端清洗与近地防御的安措施，与受攻击时调度其他应急服务器来抗，但增加了服务器与人工干预成本。为了更好的抗DDOS攻击与服务更多的用户，需求单机处理千万级别的替代方案呼之欲出。

　　目标设定

单机处理能力千万级别。

性能，性能，性能。(重要的事重复三遍)

稳定压倒一切。(此话不是我说的)

社区活跃，已有商用案例。

需求调研

　　按照上述的目标设定需求，要达到单机处理千万级别的只能采用轮询而非中断方式，在市面上的可实现技术方案有DPDK/pf_ring/netmap等。

　　其中DPDK为Intel公司主推，并有BAT之类的大型公司进行商用，而且也比较适合处理UDP类型协议。经过权衡之下，我们决定采用DPDK进行下一代XNS的替代方案。

　　优点

性能高

用户态开发

死后易重启

缺点

无网络协议栈

开发困难，周期长

参考资料相对还匮乏

DPDK核心思想组织结构

　　DPDK 的组成架构如下图所示,相关技术原理概述如下:

　　在最底部的内核态(Linux Kernel)DPDK 有两个模块:KNI 与 IGB_UIO。其中,KNI 提供给用户一个使用 Linux 内核态的协议栈,以及传统的 Linux 网络工具(如ethtool, ifconfig)。IGB_UIO(igb_uio.ko 和kni.ko. IGB_UIO)则借助了 UIO 技术,在初始化过程中将网卡硬件寄存器映射到用户态。

　　DPDK 的上层用户态由很多库组成,主要包括核心部件库(Core Libraries)、平台相关模块(Platform)、网卡轮询模式驱动模块(PMD-Natives&Virtual)、QoS 库、报文转发分类算法(Classify)等几大类,用户应用程序可以使用这些库进行二次开发。

　　用户态模式下的PMD Driver

去除了中断影响，减少了操作系统内核的开销，消除了IO吞吐瓶颈；

避免了内核态和用户态的报文拷贝；用户态下软件崩溃，不会影响系统的稳定性；

Intel提供的PMD驱动，充分利用指令和网卡的性能；

HugePage和m_buf管理

提供2M和1G的巨页，减少了TLB Miss，TLB Miss严重影响报文转发性能；

高效的m_buf管理，能够灵活的组织报文，包括多buffer接收，分片/重组，都能够轻松应对；

Ring

无锁化的消息队列，实际验证，性能充足；

82599 SR-IOV NIC

实现虚拟化下高速吞吐；

Vector Instance /向量指令

明显的降低内存等待开销，提升CPU的流水线效率。

项目规划

　　为了使DPDK更好的在我司使用与发扬光大，我大致规划了初期、中期与长期三步走策略实现目标。

　　初期目标

　　实现一个最简单的DNS demo.

　　需求：

网络可达。

Dig示例域名可正确响应。

中期目标

　　实现一个高性能高并发的DNS服务

　　需求:

单机性能提高5倍以上。

形成完整DNS产品服务(XNS、public DNS)。

平台与服务逻辑分离。

长期目标

　　实现高性能高并发的网络加速平台与应用体系

　　需求：

平台具有可移植性。

可透明承载多种业务(UDP/TCP)服务。

平台与服务物理分离。

可承载其他高级语言与虚拟化。

开发初试

　　为了验证其的可行性，我们对它进行了最小原型开发，实现了一个最简单的DNS服务程序，使其网络可达，dig能正确响应。

　　由于刚开始对DPDK一无所知，为了网络可达首先要面对的问题是服务器IP在哪儿配置的问题(这也许是一些初学者会面对的幼稚问题)，还好已有前辈在QQ大致网上了解一些原理与其源码示例，采用其源码examples目录下l3fwd为基础进行最小原型开发demo。

　　为了使网络可达，我们做了如下开发：

先在simpleDNS服务端中临时配置一个服务IP进行过滤.

在DNS客户端通过手工配置ARP表使得客户端ping/dig操作的请求包可达服务端，

在simpleDNS服务端做解析请求包，如果是DNS请求构造响应包，其他类型如ARP/ICMP请求则通过KNI入接口ingress()重入Linux内核由

　　其来处理后再通过KNI的egress()接口响应给客户端。

　　经过上述编码调试后，最简单的原型验证通过了，为下面的全面开发提供了参考依据。

架构设计

　　由于此项目是在基于DPDK进行二次开发，我一般对开源项目的使用原则是：

　　应使开源项目融入到项目工程中，而不是项目工程融入到开源项目中

　　因此我对它们进行分3层设计与实现：

内核层

　　主要为Linux内核本身与**igb_uio.ko与rte_kni.ko.

平台层

分为DPDK原生库与fastNP扩展库，分别在不同目录进行隔离。

DPDK源码树本身，没有任务的修改，是为了更好的升级、开发与维护。

对DPDK某些接口进行二次封装与业务所需的公共库，一般各种业务应用调用。

业务层

　　业务应用的各种实现，可直接调用fastNP平台层与DPDK原生层的API。

全面开发源码组织管理

　　为了所有源码可以一键编译、一键打包，编写一套符合所需的Makefile进行源码管理。

　　fastNP扩展库开发

　　扩展库源码不在DPDK源码目录中，需要很好的理解DPDK下面mk/目录下的各种Makefile原理，使其的各种编译选项与属性能够传递到扩展库中。

　　扩展库主要实现如下部分功能：

基础数据结构库。

　　如：高效双链表、用户态RCU接口等。

轻量级用户态协议栈

　　目前主要实现轻量级简易型UDP协议栈，以实现二三层转发为主。

HOOK挂载与处理机制

　　仿造了Linux netfilter框架实现5个点钩子挂载与处理。

高性能日志库

　　参考了目录主流高性能日志与线程安全，实现了一个数百万行打印的高性能日志系统。

　　等等…

业务层开发

　　第一个应用主要是把原有内核版本的KANS源码移植到用户态的SANSD中。

　　控制查看命令开发

　　为了方便对平台与业务层的查看与控制，我们基于Libcmdline库开发了sansctl命令，可支持命令补全等。

　　发包工具开发

　　为了能进行千万级别的高性能测试，基于pktgen-dpdk进行开发使其可以构造DNS请求与控制发送速率功能的spktgen，主界面如下图：

　　抓包工具开发

　　由于现有tcpdump不能抓取DPDK接管的网卡数据，也在其基础上开发可在DPDK下抓包的spktdump，以便调试与定位。

　　其他开发

　　从略。

　　踩过的坑架构模式选择

　　DPDK提供了两种模式可供选择：Run-to-completion与pipeline模式。在官网文档与DPDK开发者大会中都提到了这两种模式，但都没说哪种模式更好，要看场景而定。我们在最初设计时，不仅考虑DNS服务器还考虑以后负载均衡设备的使用，选择了可支持这两种模式。

　　在测试性能时，发现某种情况下不同模式都有优缺点，经常在这两种模式中来回切换测试，造成了一些干扰与浪费了点时间。

　　编译选项一致

　　在测试性能时一定使用-O3选项并且编译选项需与DPDK本身app编译选项一致。否则会影响很大的性能。

　　DPDK本身app编译选项可以在编译目录下的.XXX.o.cmd文件查看到。

　　变量percore化

　　所用的全局变量尽量percore化，这样可以防止cache miss。例如统计部分要用percore化，计算或显示时再把他们加到一起，这个也影响不小的性能。

　　代码逻辑简化

　　由于业务层代码是从内核版本中移植过来的，老早功能就通过了，但性能一直上不来，后来经过代码review发现很多影响性能点，又重新优化或精简了下代码逻辑，去掉了不少冗余代码。

　　RCU锁占用性能

　　扩大RCU临界区

　　域名压缩占用性能

　　应答区中的域名不压缩。

　　有待完善DPDK 缺少配置文件

　　现在DPDK代码与核数越来越多,依然使用命令行参数的方式进行启动，可配置与阅读性比较差，应该有自己的配置文件进行解析即可。

　　尤其是网卡、队列、逻辑核配置序列太难配置了，尤其是使用核数比较多的情况。

　　例如：(0,0,2),(0,1,4),(0,2,6),(0,3,8),(0,4,10),(0,5,12),(0,6,14),(0,7,16),(0,8,18),(0,9,20),(0,10,22),(0,11,24),(0,12,26),(0,13,28)

　　不知道各位同学知不道有什么国际规范的缩写方式配置,请麻烦告知一下，OK？

　　pktgen-dpdk驱动bug

　　当使用pktgen-dpdk进行测试时，频繁的启停可能会使万兆光纤网卡处于DOWN状态，重启命令或reboot系统都不管用，必须对服务器进行冷重启才行，这对测试比较浪费时间或者远程调试操作堪忧。

　　examples下编码质量参差不齐

　　DPDK库本身的编码质量还是比较规范统一的，而其examples下的示例代码编码质量参差不齐。

　　fastNP本身

BOND与多网卡有待支持。

邻居发现与路由功能有待支持。

TCP协议栈有待支持。

虚拟化功能有待支持。

更高级语言功能有待支持。

Libc与系统调用劫持功能有待支持。

总结

　　经过这一段时间的开发，使得我对DPDK、内存、CPU、用户态网卡驱动有了更深的了解，使得性能达到了万兆网卡线速水平，单机抗攻击能力为1300万QPS，收发平衡能力为1000万QPS的预期目标，总之DPDK框架代码写得还是挺不错的，值得仔细研究，现在我只是对它怎么使用与部分源码有了一定的认识，很多精华部分有待深入剖析。

　　Footnotes

　　[^1]: DPDK: intel dpdk(Data Plane Development Kit,数据面开发套件)是 intel 公司发布的一款数据包转发处理套件；

　　[^2]: CloudXNS: 面向云计算的权威智能DNS。

　　[^3]: QPS: 每秒查询率(Query Per Second).

　　[^4]: BIND: Bind是一款开放源码的DNS服务器软件,Bind由美国加州大学Berkeley分校开发和维护的,全名为Berkeley Internet Name Domain, 它是目前世界上使用最为广泛的DNS服务器软件.

　　近期技术活动 ，期待与你线下相见

　　「北京、上海」 技术风暴强势来袭，4月22号北京上海双城联动

　　「北京」你离优秀架构师有多远？

　　商务合作，请加微信yunweibang555