京东数科统一接入网关JDDLB性能优化之QAT加速卡

京东云技术团队

于 2021-01-06 19:02:47 发布

阅读量6.9k

点赞数 2

本文链接：https://blog.csdn.net/JDDTechTalk/article/details/112289768

版权

硬核干货专栏收录该内容

220 篇文章 25 订阅

订阅专栏

京东数科JDDLB作为京东数科最重要的公网流量入口，承接了很多重要业务的公网流量。目前，已成功接替商业设备F5所承载的流量，并在数次618、双十一大促中体现出优越的功能、性能优势。

本文作为京东数科七层负载 | HTTPS硬件加速 (Freescale加速卡篇)的姐妹篇，将着重介绍QAT加速卡的相关内容。

一、京东数科JDDLB 整体架构

在这里插入图片描述

图1 京东数科JDDLB 整体架构

JDDLB 整体架构的核心包括：基于DPDK自主研发的四层负载SLB，定制开发扩展功能的NGINX，以及统一管控运维平台。其主要特点为：

高性能：具备千万级并发和百万级新建能力。
高可用：通过 ECMP、会话同步、健康检查等，提供由负载本身至业务服务器多层次的高可用。
可拓展：支持四层/七层负载集群、业务服务器的横向弹性伸缩、灰度发布。
四层负载能力：通过ospf 向交换机宣告vip；支持ECMP、session 同步；支持均衡算法如轮询、加权轮询、加权最小连接数、优先级、一致性哈希；FullNAT转发模式方便部署等。
七层负载能力：支持基于域名和URL的转发规则配置；支持均衡算法如轮询、基于源 IP 哈希、基于cookie等。
SSL/TLS能力：证书、私钥、握手策略的管理配置；支持 SNI 配置；支持基于多种加速卡的SSL卸载硬件加速等。
流量防控：提供一定的 Syn-Flood 防护能力；与应用防火墙结合后提供 WAF 防护能力；提供网络流量控制手段如 Qos 流控、ACL 访问控制等。
管控平台：支持多种维度的网络和业务指标监控和告警。

此外，借助于JDDLB现有能力特性，方便扩展其他新功能。例如，借助于NGINX的SSL/TLS硬件优化性能以及连接高并发处理能力，可以实现基于MQTT协议的、支持SSL/TLS协议、安全的推送长连接网关等。

本文针对JDDLB中七层负载的SSL/TLS性能优化方法之一——将耗CPU计算资源的加解密算法计算卸载到QAT加速卡——进行概述性介绍。

二、优化方案性能提升对比

1、测试方法

执行机部署适配QAT引擎后的nginx，发包测试机进行压测灌包，在CPU负载达到100%后比较得出nginx在进行QAT优化后的新建connection速率对比。

2、测试场景

在这里插入图片描述

3、本地测试数据对比

▷ 使用单张加速卡性能对比

在这里插入图片描述

▷ 使用双加速卡性能对比

在这里插入图片描述

此优化方案，通过NGINX进行HTTPS新建速率实测，与软件加解密场景做对比：

使用单加速卡，rsa平均新建速率提升3倍，ecdh新建速率提升2.5倍
使用双加速卡：rsa 平均新建速率提升6 倍，ecdh新建速率提升5.5倍

此优化方案所带来的性能提升主要依赖于：

对比fsl 加速卡、qat 采用用户态驱动的方式，实现了内核态到用户态到内存零拷贝。
NGINX采用异步模式调用OpenSSL API，代替传统的同步模式调用。
驱动支持多加速卡同时进行卸载加速。

三、硬件加解密异步处理

1、异步框架概述

JDD-LB基于nginx 原生的异步处理框架上拓展出针对异步硬件引擎的异步事件处理机制，整体框架如下图所示：

在这里插入图片描述
硬件加解密的异步框架整体依赖nginx的epoll异步框架处理机制和 openssl 协程机制。原生的nginx epoll 框架负责网络I/O 的异步事件处理，在此基础上jdd-lb重新增加了async fd 异步监听任务，在原有的连接结构体中增加新的异步来源用来接收异步引擎的通知，当执行OpenSSL相关操作时，把返回的事件fd加载到jdd-lb的异步事件框架中，openssl 当检测到硬件执行完相关操作后就会唤醒相关事件进行后续操作的执行。

关于协程的详细介绍可以参考《UAG性能优化之freescale加速卡》，里面有关于协程实现的基本语义、切换机制等详细介绍，这里不在赘述，总而言之，openssl协程机制实现在线程内的多个任务切换管理。

这里涉及到两个问题：

异步任务的上下文切换以及通知机制；
Nginx如何获取async fd，并加入epoll监听队列中，并与openssl 以及qat engine协同完成一次ssl 握手的；

2、交互流程

以ssl握手为例，nginx、openssl、qat引擎各个模块之间的交互流程如下图所示：
在这里插入图片描述

ASYNC_start_job：nginx 调用ssl lib库接口SSL_do_handshake, 开启一个异步任务。
Rsa/ecdh 加解密操作。
Qat 引擎将加密消息发送给驱动，创建异步事件监听fd，将fd绑定到异步任务的上下文中。
qat_pause_job: 调用该接口保存异步任务执行的堆栈信息，任务暂时被挂起，等待硬件加解密操作完成。同时进程堆栈切换到nginx io调用主流程，ssl返回WANT_ASYNC,nginx开始处理其他等待时间。
nginx io 处理框架获取保存在异步任务上下文中的asyncfd，并添加到epoll队列中启动监听。
加速卡处理任务完成，qat 引擎调用qat_wake_job接口唤醒任务（也就是将async fd 标记为可读），这里有一个问题，这个qat_wake_job是什么触发执行的？qat 为nginx 提供了多种轮训方式去轮训加速卡响应队列，目前jdd-lb 采用的是启发式轮训的方式，具体参数可以在配置文件中定义。
Nginx处理异步事件重新调用异步任务框架的ASYNC_start_job接口，这时候程序切换上下文，堆栈执行后跳回之前pase job的地方。

四、用户态驱动实现内存零拷贝

区别于上期我们介绍的freescale加速卡方案、qat采用用户态驱动的实现方式，利用linux uio+mmap技术实现了内存零拷贝。接下来介绍qat 实现内存零拷贝的基本原理。

在弄清楚这个问题前，我们先介绍一下uio技术的基本原理，简而言之：UIO（Userspace I/O）是运行在用户空间的I/O技术，Linux系统中的驱动设备一般都是运行在内核空间，UIO则是将驱动的很少一部分运行在内核空间，而在用户空间实现驱动的绝大多数功能。
在这里插入图片描述

工作原理图

我们先明确一个用户态程序如何操作一个pci设备?首先需要找到它的寄存器并对其进行配置，而找到寄存器的前提是拿到外设的基地址，即：通过“基地址+寄存器偏移” 就能找到寄存器所在的地址，然后就可以配置了。

综上，qat的内核模块可以分为两块基本内容：

（1）PCI设备驱动，获取pci设备的配置空间信息，申请内核资源；也就是拿到加速卡的基址寄存器地址，映射设备的地址空间。

（2）注册UIO设备，实现用户态驱动的主要功能：映射寄存器地址到用户空间，在内核态屏蔽设备中断；

利用UIO框架实现将设备的寄存器地址映射至用户空间后，QAT还需要完成用户态进程与硬件之间消息传递。QAT中消息队列的创建是在进程运行时创建，同样利用mmap 原理将一段物理地址映射至用户态进程，为了避免内核在运行过程中出现内存碎片导致性能下降，QAT 新增了usdm内核模块用于管理和维护页表。

如下图所示，显示了QAT如何将设备地址及消息队列映射到用户空间：
在这里插入图片描述
综上所示，QAT通过UIO+ mmap的方式实现了内核态到用户态到内存零拷贝，相比于freescale 和cavium等其他加速卡厂商，QAT在这一方面存在着一定优势。

关于内存映射的问题，jdd-lb nginx多进程之间必须要保证物理地址的对齐偏移量一致，jdd-lb在实际部署和上线过程中遇到过类似问题：

现象描述

装载qat加速卡机器出现宕机，我们抓取宕机的crash日志，如下图：

在这里插入图片描述

系统挂之前操作消息队列（send_null_msg），内核被踩了，另外，在挂之前截图内核日志，发现大量内存申请失败的信息：

原因分析

基于以上现象分析，机器挂之前的主要行为：1、nginx正在频繁reload；2、预分配的大页内存池不够了，新起的worker进程采用ioctl的方式从内核申请2m页，也就是我们在修复问题二之前采取的内存分配方式，这点可以从内核日志中分配内存失败的打印推断出来，因为只有通过ioctl 方式申请才会出现userMemAlloc failed的打印。3、worker 退出前访问了消息队列，这个是导致宕机的直接原因。

总结一下三条行为的因果关系，频繁reload > 老的worker还没彻底shutdown，新的worker已经起来了, 同一时间出现大量nginx > 预分配的大页内存池被占满 > 新的worker采用ioctl的方式去申请> 有个worker释放时访问消息队列 > 机器挂了。

根据以上分析，在机器挂之前nginx 的worker 进程是同时存在两种内存分配方式，但是qat是同时支持两种内存分配方式的，如果ioctl方式申请内存失败最多出现nginx qat加速卡卡降级，在问题二中已经说明了，并不会出现宕机的行为，难道是两种方式不能共存？

问题验证

带着上述疑问，采取人为手段在测试环境复现该场景，先是继续在nginx拉起前人为的消耗完2m页，在nginxworker代码中加入调试控制，shutting down之前sleep100秒（测试环境下nginx shutdown的速度非常快，并不能完全模拟线上环境的场景），然后运行一个nginx 不断reload的脚本，最后，线上环境的问题在测试环境复现，crash的日志与线上环境一致。

问题到这一步，只能说明两种内存分配方式共存的场景下，nginx释放消息队列时会引起宕机，同样的测试场景，如果只采用一种内存分配的方式申请，都不会出现宕机。总之，知其然不知其所以然。然后经过阅读源代码加点日志分析判断，最终找到点眉目，下面放结论。

usdm内核模块会维护物理地址和虚拟地址的映射关系，进程在释放队列后会去操作加速卡的CSRs，而这个物理地址是通过创建的消息队列的物理地址偏移后计算出来的，虽然两种内存申请方式按2m的大小申请的，但是通过大页内存的方式申请的物理页是按2m的大小保存的，而通过ioctl方式申请的物理页是按照4k大小保存的，因此，如果通过同时存在两种内存分配方式的话，计算得到的CSR的物理地址就不一致了。画个图说明一下：

在这里插入图片描述

五、进程级别的加速引擎调度

QAT 的引擎启动主要完成3个步骤：
（1）完成应用程序注册：打开字符串设备/dev/qat_dev_processs，将app配置信息写入驱动，App的信息必须与驱动配置中定义的配置块一致，也就是/etc/dh895xcc_dev0.conf这个配置文件中的配置信息。

（2）完成服务的注册（qat 支持cy和dc两种服务），并完成加速卡硬件相关资源的初始化操作。

（3）获取服务实例，这里的instances可以理解为应用程序与加速卡相互通信的通道，实际上就是与底层的加速卡和消息队列建立绑定关系。所以8950 加速卡最多支持128 个instance（考虑硬件队列最多就256个）。

需要说明的是：qat 的instance资源是进程级别，那么每个worker在启动之前都会调用qat_engine_init函数，qat用了一个钩子使得master进程在fork 之后子进程调用qat_engine_init函数，同时在fork之前释放引擎（master本身不需要引擎资源），流程如下图所示：

在这里插入图片描述