All in one & One for all，“快杰” 云主机的技术进阶之路

自 UCloud 在 5 月 28 日的 TIC 大会上发布 “快杰” 云主机后，已通过去了近半年的时间，在这半年间，“快杰” 凭借优越的性能与极高的性价比，在云主机市场中走出了本身的独特道路。在这些成果背后，咱们用两个词来阐述 “快杰” 的技术理念：All in one & One for all。

All in one & One for all

做为云计算的基石产品，云主机的核心特性决定了云上其它能力的拓展，也直接关乎于用户的使用体验。用户选择云计算的出发点在于：简单性，速度和经济性。可是因为互联网与 IT 服务的场景多样化，业内大多数厂商都是分别推出适应不一样场景的云主机类型，但也所以带给了用户运维和采购的复杂度。

什么是 “All in one” 呢？“快杰” 将本身定义为 “简单” 的产品。简单不只意味着使用方便，还意味着多项软硬件技术的融合，以此为用户提供超高的产品性能。也就是说，当你面对各种业务场景下 CPU、网络、存储的不一样性能需求时，无需考虑太多因素，“快杰” 都可知足。

这是 “快杰” 的一组数据：

全面搭载 Intel 最新一代 Cascade Lake 处理器

配备 25G 基础网络并采用全新的网络加强 2.0 方案

支持 RDMA-SSD 云盘

网络性能最高可达 1000 万 PPS

存储性能最高可达 120 万 IOPS

在产品上线之初，咱们对 “快杰” 进行了跑分测试，测试结果显示，同等规格的配置下，“快杰” 的性能明显优于市场上同类型的云主机产品。举个例子，在一样 8 核 16G 的配置下，“快杰” 的网络性能较友商高出 3 倍多，存储性能有着近 4 倍的差别。

可是在这样的高配下，“快杰” 的价格提高却不超过 20%，部分配置机型的价格与普通机型价格基本持平或略有降低，云盘价格仅为市场同类产品的 60% 或者更低。“快杰” 用 “One for all” 的价格红利将全部技术又统统回馈给了用户。

“罗马不是一天建成的”，不管是 All in one 仍是 One for all，在这些数据的背后，都离不开 UCloud 在技术上的持续探索和积累。接下来，咱们就来聊聊 “快杰” 背后的技术进阶之路。

01

网络加强 2.0：4 倍性能提高 + 3 倍时延降低

网络通道是严重制约云主机性能的瓶颈之一，在这里，值得一提的即是 “快杰” 在 25G 智能网卡网络加强能力方面作出的技术突破。

| 硬件级别的网卡加速

基于云主机网络性能提高的需求，25G 网络逐渐成为趋势。可是因为传统软件 Virtual Switch 方案的性能瓶颈：当物理网卡接收报文后，是按照转发逻辑发送给 VHost 线程，VHost 再传递给虚拟机，所以 VHost 的处理能力就成为了影响虚拟机网络性能的关键。

在调研了业界主流的智能网卡方案以后，咱们最终采用了基于 Tc Flower Offload 的 OpenvSwitch 开源方案，为 “快杰” 提供了硬件级别的网卡加速。虚拟机网卡可直接卸载到硬件，绕过宿主机内核，实现虚拟机到网卡的直接数据访问。相较于传统方案，新的智能网卡方案在整个 Switch 的转发性能为小包 24Mpps，单 VF 的接收性能达 15Mpps，使得网卡总体性能提高 10 倍以上，应用在云主机上，使得 “快杰” 的网络能力提高至少 4 倍，时延下降 3 倍。

| 技术难点突破：虚拟机的热迁移

在该方案落地之时，咱们遇到了一个技术难题：虚拟机的热迁移。由于各个厂商的 SmartNIC 都是基于 VF passthrough 的方案，而 VF 的不可迁移性为虚拟机迁移带来了困难，在此将咱们的解决方案分享给你们。

经过调研咱们发现，用户不须要手工设置 bonding 操做或者制做特定的镜像，能够妥善解决用户介入的问题。受此启发，咱们采用了 VF+Standby Virtio-net 的方式进行虚拟机的迁移 。具体迁移过程为：

一、建立虚拟机自带 Virtio-net 网卡，随后在 Host 上选择一个 VF 做为一个 Hostdev 的网卡，设置和 Virtio-net 网卡同样的 MAC 地址，attach 到虚拟机里面，这样虚拟机就会对 Virtio-net 和 VF 网卡自动造成相似 bonding 的功能，此时，在 Host 上对于虚拟机就有两个网络 Data Plane；

二、Virtio-net backend 的 tap device 在虚拟机启动时自动加入到 Host 的 OpenvSwitch bridge 上，当虚拟机网卡进行切换的时候 datapath 也须要进行切换。VF attach 到虚拟机后，在 OpenvSwitch bridge 上将 VF_repr 置换掉 tap device。

02

RDMA-SSD 云盘：提供 120 万 IOPS 存储能力

在云盘优化方面，咱们主要从 IO 接入层性能优化、RDMA 网络加速及后端存储节点提高三方面来完成 RDMA-SSD 云盘的技术实现，最终为 “快杰” 提供 120 万 IOPS 的存储能力。

| 基于 SPDK 的 IO 接入层性能优化

以下图，为传统的 OEMU Virtio 方案示意，在第 3 步时， QEMU 里的驱动层经过 Gate 监听 Unix domain socket 的转发 IO 请求时，存在额外的拷贝开销，所以成为 IO 接入层的性能瓶颈。

图：QEMU Virtio 方案示意

针对该问题，UCloud 使用了 SPDK VHost 来优化虚拟化 IO 路径。
（1）SPDK VHost：实现转发 IO 请求的零拷贝开销

SPDK（Storage Performance Development Kit ) 提供了一组用于编写高性能、可伸缩、用户态存储应用程序的工具和库，基本组成分为用户态、轮询、异步、无锁 NVMe 驱动，提供了从用户空间应用程序直接访问 SSD 的零拷贝、高度并行的访问。

图：SPDK VHost 方案

如上图，在应用 SPDK VHost 方案后，IO 路径流程以下：
① 提交 IO 到 virtqueue；② 轮询 virtqueue，处理新到来的 IO；③+④ 后端存储集群处理来自 Gate 的 IO 请求；⑤ 经过 irqfd 通知 Guest IO 完成。
最终 SPDK VHost 经过共享大页内存的方式使得 IO 请求能够在二者之间快速传递，这个过程当中不须要作内存拷贝，彻底是指针的传递，所以极大提高了 IO 路径的性能。

以下表，咱们对新老 Gate 的性能作了测试对比。能够看到，在应用 SPDK VHost 之后，时延和 IOPS 获得了显著优化，时延下降 61us，IOPS 提高 58%。

（2）开源技术难点攻破：SPDK 热升级

在咱们使用 SPDK 时，发现 SPDK 缺乏一项重要功能 —— 热升级。咱们没法 100% 保证 SPDK 进程不会 crash 掉，一旦后端 SPDK 重启或者 crash，前端 QEMU 里 IO 就会卡住，即便 SPDK 重启后也没法恢复。

图：virtio vring 机制示意
经过深刻研究 virtio vring 的机制，咱们发如今 SPDK 正常退出时，会保证全部的 IO 都已经处理完成并返回了才退出，也就是所在的 virtio vring 中是干净的。而在乎外 crash 时是不能作这个保证的，意外 crash 时 virtio vring 中还有部分 IO 是没有被处理的，因此在 SPDK 恢复后须要扫描 virtio vring 将未处理的请求下发下去。

针对该问题，咱们在 QEMU 中针对每一个 virtio vring 申请一块共享内存，在初始化时发送给 SPDK，SPDK 在处理 IO 时会在该内存中记录每一个 virtio vring 请求的状态，并在乎外 crash 恢复后能利用该信息找出须要从新下发的请求，实现 SPDK 的热迁移。

| RDMA 网络加速

（1）TCP 瓶颈

在解决了 IO 路径优化问题后，咱们继续寻找提升云盘 IO 读写性能的关键点。在协议层面，咱们发现使用 TCP 协议存在如下问题：

TCP 收发数据存在网卡中断开销，以及内核态到用户态的拷贝开销；
TCP 是基于流式传输的，所以一般网络框架（libevent）会使用一个缓冲区暂存数据，等到数据达到可处理的长度才从缓冲区移除，一样地，发包过程为了简化 TCP 缓冲区满引发的异常，网络框架也会有一个发送缓冲区，那么这里就会产生二次拷贝。

图：TCP 协议原理示意

针对这个问题，咱们用 RDMA 协议来代替 TCP 协议，来达到提高 IOPS 和时延的能力。

（2）RDMA 代替 TCP

RDMA (Remote Direct Memory Access) 技术全称远程直接数据存取，是为了解决网络传输中服务器端数据处理的延迟而产生的。

使用 RDMA 代替 TCP 的优势以下：
① RDMA 数据面是 bypass kernel 的，数据在传输过程当中由网卡作 DMA，不存在数据拷贝问题。② RDMA 收发包过程是没有上下文切换的，发送时将数据 post_send 投递到 SQ 上，而后通知网卡进行发送，发送完成在 CQ 产生一个 CQE；接受过程有一些差别，RDMA 须要提早 post_recv 一些 buffer，网卡收包时直接写入 buffer，并在 CQ 中产生一个 CQE。③ RDMA 为消息式传输，即假设发送方发送一个长度为 4K 的包，接收方假如收到了，那么这个包的长度就是 4K，不存在只收到一部分的状况。RDMA 提供的这种能力能够简化收包流程，不须要像 TCP 同样去判断数据是否收全了，也就不存在 TCP 所需的缓冲区。④ RDMA 的协议栈由网卡实现，数据面 Offload 到网卡上，解放了 CPU，同时带来了更好的时延和吞吐。

图：RDMA 协议原理示意

| 后端存储节点 IO Path 加速

除了在 IO 路径接入与传输协议方面作了改进以外，UCloud 还针对云硬盘后端存储节点进行了优化。

对于原有的 Libaio with Kernel Driver，咱们采用了 SPDK NVMe Driver 进行了替代，下图为 Fio 对比测试二者的单核性能状况，能够看到应用 SPDK NVMe Driver 后性能有了较大的提高。

图：Libaio with Kernel Drive & SPDK NVMe Driver 单核性能比较

此外，SPDK NVMe Driver 使用轮询模式，能够配合 RDMA 发挥出后端存储的最佳性能。

综上，咱们实现了云盘的全面优化：使用 SPDK VHost 代替 QEMU，实现虚机到存储客户端的数据零拷贝；使用高性能 RDMA 做为后端存储的通讯协议，实现收发包卸载到硬件，使得 RSSD 云盘的延迟下降到 0.1 毫秒，体验几乎和本地盘一致；存储引擎由 SPDK 代替 libaio，高并发下依然能够保持较低的时延。再配合 全 25G 的底层物理网络，使 RDMA-SSD 云盘的随机读写性能达到最佳，实现 120 万 IOPS。

图：RDMA-SSD 云硬盘原理图

03

内核调优：产品综合性能提高 10%

提起云主机，更多的会想到计算、存储、网络，甚少有人关注内核。然而，内核构建是一个云主机的核心工做，它负责管理系统的进程、内存、设备驱动程序、文件和网络系统等，对云主机性能和稳定性相当重要。

未优化以前，咱们对云主机中特定业务场景进行了基准性能测试。在测试过程当中，利用 perf、systemtap、eBPF 等多种动态跟踪技术，在 Host 内核、KVM 和 Guest 内核等不一样观测层级上，对影响性能的因素进行了指令级别的分析。

在此基础上，咱们针对性的进行了内核加强和优化工做。

| CPU 加强 & 漏洞修复

咱们在 QEMU 和 KVM 中添加了 Intel 新一代 Cascade Lake 虚拟 CPU 的支持，相比上一代 Skylake，增长了 clflushopt、pku、axv512vnni 等指令集，在特定场景下性能表现更加出色。此外，针对 CPU 漏洞方面，咱们利用硬件解决了 Meltdown，MDS，L1TF 等漏洞，同时针对 Spectre_v2 补丁添加了代价更小的 Enhanced IBRS 加强修复机制，在虚拟化层面对漏洞进行了修复。最后，咱们将硬件修复能力赋予” 快杰”，使得云主机能够避免 Guest 内核在软件层面修复安全漏洞，消除这方面引发的性能开销和业务指标降低。

| CPU 对内存读写能力优化

针对 CPU 对内存读写能力的优化，咱们主要从两方面来实现。

首先咱们基于硬件内存虚拟化（Intel EPT），添加了定制化大页内存的支持，从而避免了以前内存虚拟化中存在的管理器 / 分配器开销、换页延迟等，极大减小了页表大小和 TLB miss，同时保证云主机内存与其余云主机、系统软件间相互隔离，避免影响。

其次，咱们加强了 NUMA 亲和性的使用。众所周知，跨节点访问内存的延迟远远大于本地访问所产生的，针对该问题，咱们经过合理的资源隔离和分配，使云主机的 VCPU 和内存绑定在同一个节点。此外，对于大型云主机可能存在单个节点资源不够的状况，咱们将云主机分配在两个节点，把节点的拓扑结构暴露给 Guest 内核，这样云主机能够更方便的利用 NUMA 特性对关键业务进行调度管理。

图：NUMA 亲和性的使用

| Host 内核 & KVM 优化

结合性能分析数据，咱们对 Host 内核和 KVM 也进行了大量的优化。

在 VCPU 调度方面，咱们发现 CFS 调度器会在临界区内使用时间复杂度为 O (n) 的算法，致使调度器开销太高、Guest 计算时间减小及调度延迟增大，咱们在 CFS 中修复了这一问题。

此外，在 Host/Guest 上下文切换过程当中，咱们发现某些寄存器的上下文维护代码会引入必定开销，所以在保证寄存器上下文切换正确性的同时，咱们也去掉了这些维护代码引发的开销。

在云主机运行过程当中，会产生大量的核间中断（IPI），每次 IPI 都会引发 VMExit 事件。咱们在虚拟化层引入了两个新的特性：KVM-PV-IPI 和 KVM-PV-TLB-Flush。经过 KVM 提供的 Send-IPI Hypercall，云主机内核能够应用 PV-IPI 操做消除大量 VMExit，从而实现减小 IPI 开销的目的。在云主机更新 TLB 的时候，做为发起者 VCPU 会等待其它 VCPU 完成 TLB Shootdown，云主机内核经过 PV-TLB-Flush 极大减小等待和唤醒其它 VCPU 的开销。

以上是一些比较重要的优化工做，其它内核、KVM、QEMU 功能加强和稳定性提高等内容再也不赘述。整体评估下来，经过内核调优，可帮助” 快杰” 实现 10% 以上的综合能力提高。

04

三大应用场景分析

基于强大的性能，“快杰” 可以轻松知足高并发网络集群、高性能数据库、海量数据应用的使用场景。咱们分别选取了 Nginx 集群、TiDB、ClickHouse 数据库三个应用场景，下面来看一下” 快杰” 的表现：

| 场景 1：搭建 Nginx 集群，突破网络限制

爱普新媒是一家从事广告 DSP（Demand-Side Platform，需求方平台）业务的公司，因为业务需求，爱普新媒对于网络集群的高并发要求很是高。最终，爱普新媒选择使用 “快杰” 搭建 Nginx 集群，做为 API 网关对其终端客户提供服务。
Nginx 是一款轻量级 HTTP 反向代理 Web 服务器，根据 Nginx 官网的数据，Nginx 支持了世界上大约 25% 最繁忙的网站，包括 Dropbox，Netflix，Wordpress.com 等。其特色是并发能力强，而 “快杰” 进一步提高了其并发能力。
“快杰” 突破了云主机以前的网络限制，以下图，“快杰” 的应用使得爱普新媒原有集群内主机能够大幅度减小，而且在相同服务能力下，成本减半。

图：“快杰” 在高并发网络集群场景中的表现

| 场景 2：搭建 TiDB，突破 IO 性能瓶颈

PingCAP 的 TiDB 是一款流行的开源分布式关系型数据库，为大数据时代的高并发实时写入、实时查询、实时统计分析等需求而设计，对 IO 性能的要求无疑很是高。一般，TiDB 要求底层使用 NVMe SSD 本地磁盘支撑其性能，但快杰云主机经过 RSSD 云盘便可知足 TiDB 的高要求，其性能也获得 PingCAP 工程师的实测承认。

目前，已有很多 UCloud 客户使用快杰云主机搭建 TiDB，突破了以前的数据库性能瓶颈。

图：“快杰” 在高性能数据库场景中的表现

除了 TiDB，“快杰” 实测能有效提高各种数据库的性能表现 20% 以上。

| 场景 3：搭建 ClickHouse，提高 2 倍数据吞吐量

TT 语音是一款专门为手游玩家服务的语音开黑工具，因为业务要求需将 APP 埋点数据收集到大数据集群中分析。TT 语音采用 “快杰” 搭建 ClickHouse 数据库做为整个大数据集群的核心，对比以前，每日增量达到 8 亿条记录。
除了 ClickHouse 场景，“快杰” 还能够对大数据生态进行全方位的优化，以下图，数据吞吐提高高达 2 倍，助力企业大数据业务发展。

图：“快杰” 在大数据应用场景中的表现

结语

基于 “软硬件协同设计” 的理念，“快杰” 在网络加强 2.0、RSSD 云盘优化、内核调优等方面作到了技术的大幅进阶，为用户带来了突破性的云主机性能提高。在 “快杰” 的技术进阶路上，技术的更迭与升级能够用语言描述出来，可是技术实现的背后却表明了 UCloud 为用户创造核心价值的坚持与追求。