GaussDB关键技术方案_通信组件

GaussDB关键技术方案_通信组件

云原生数据库采用shared disk架构，各个计算节点对等，计算节点之间通过页面交换实现缓存数据的一致性，为了提高页面传递的效率，需要利用RDMA或UB单边读写的能力；云原生数据库为了管理动态资源，需要对动态资源的owner分配进行加锁，分布式锁管理需要利用原子操作和RPC消息对资源进行加解锁；多租户资源管理服务需要下发调度信息，并从计算节点读取资源状态，需要RPC消息；集群管理组件进行故障检测、发送消息需要使用RPC消息。

因此，通信组件需要能够支持原子操作、单边读写、双边RPC和RPC通信。目前市场上有三种RDMA网络，分别是Infiniband、RoCE(RDMA over Converged Ethernet)、iWARP，如下图所示。

其中，Infiniband是专为RDMA设计的网络，从硬件级别保证可靠传输 ，但是成本高昂。而RoCE 和 iWARP都是基于以太网实现的RDMA技术，在目前最广泛使用的以太网上实现了高速、超低延时、极低CPU使用率的RDMA通信。

RoCE协议有RoCEv1和RoCEv2两个版本，RoCEv1是基于以太网链路层实现的RDMA协议(交换机需要支持PFC等流控技术，在物理层保证可靠传输)，允许在同一个广播域下的任意两台主机直接访问；而RoCEv2是以太网TCP/IP协议中UDP层实现，即可以实现路由功能。

InfiniBand：设计之初就考虑了 RDMA，从硬件级别保证可靠传输，提供更高的带宽和更低的时延。但是成本高，需要IB网卡和交换机支持。

RoCE：基于Ethernet 做RDMA，消耗的资源比 iWARP 少，支持的特性比 iWARP 多。可以使用普通的以太网交换机，但是需要支持RoCE的网卡。

iWARP：基于TCP的RDMA网络，利用TCP达到可靠传输。相比RoCE，在大型组网的情况下，iWARP的大量TCP连接会占用大量的内存资源，对系统规格要求更高。可以使用普通的以太网交换机，但是需要支持iWARP的网卡。为了支持各种网卡类型的RDMA协议和实现低时延的网络通信，云原生数据库的节点通信组件的整体架构图如下:

图3 通信组件整体架构图

节点间通信组件包括以下几个模块：RPC接口层、配置管理、通用功能、会话管理，消息处理和协议层。各模块功能描述如下：

根据对通信时延的计算，一次单边通信留给CPU的时间只有3.36us，为了实现低时延通信，各个模块的设计考虑如下：

1、RPC Interface根据不同场景对通信接口的需求，RPC接口层提供消息语义、内存语义和原子操作接口，并支持同步、异步和批量调用。RDMA内存操作需先将内存注册到网卡。论文《用户态RPC over RDMA优化技术的研究与实现》实验表明，传输的块大小越小，内存注册在一次RPC调用中占比越大，当块大小小于64KB时，内存注册开销远大于传输本身的开销。为降低内存注册的开销，通信组件统一申请大块内存并注册到网卡，业务模块需要进行远端内存操作前通过调用请求内存接口获取指定长度的已注册内存。

2、配置管理配置管理主要是静态设置节点间通信信息，在通信初始化时使用，不在通信关键路径上。

3、通用模块通用模块主要负责计算节点注册内存的管理和集群间通信消息的转发，在初始化时使用，不在通信关键路径上。

4、会话管理会话管理主要包括连接管理、上下文管理和传输管理。RDMA协议通信的基本单元是QP(Queue Pair)，通信的两端都需要创建QP，不同传输模式使用的QP类型不一样，并且支持的RDMA原语也不一样，如下表。

可见，单边读写和原子操作只能使用可靠连接，即每个连接的两个节点需要各自维护一个QP，并且不能被其他目的节点的连接共享。

假设有N个节点需要相互通信，则至少需要N * (N - 1)个QP，而QP本身需要占用网卡和内存，当连接数很多时，存储资源消耗将会非常大。经计算一个未经封装的RDMA QP大概占186.67KB (0.1823M) 内存。为降低内存开销，与相同节点通信可以共享QP。

但在高并发下竞争QP资源可能成为性能瓶颈。连接分发设计需要考虑性能和资源利用率。连接管理根据QP是否可共享支持共享连接(share-connection)和线程独占连接(per-thread)两种选择。双边操作可以使用不可靠报文QP，即传输为不可靠数据报文且不同目的节点可共享QP。

为节省QP资源，减少过多QP造成网卡cache miss导致的性能下降，考虑双边通信场景选择使用不可靠报文，但是为保证数据的可靠性，需要进一步做可靠性设计。

考虑设计滑动窗口实现保序和重传机制，作为后续开发特性。(但是据FaSST测试数据，RDMA的不可靠发送丢包率近乎为0），需要设计传输管理模块实现保序、重传等功能(优先级低))。由于RDMA协议通信接口为异步接口，对于同步RPC请求，多线程共享通信队列需要上下文切换，不能满足时延要求。需要设计低时延的同步机制进行上下文切换或无锁设计。

对于TCP而言，协议本身已经提供了流控机制和传输的可靠性，需要额外提供消息的上下文管理，即对发送消息和接收消息进行关联。UB是无连接的，但与RDMA一样采用发送队列、接收队列和完成队列的方式进行通信，所以会话管理与RDMA一致。

5、消息处理根据通信接口语义，需定义不同类型的消息，包括集群内节点间RPC通信消息、远端内存访问消息、节点间原子操作消息及集群间RPC通信消息。消息处理组件根据消息类型进行封装、解析为所需的消息类型。后续根据业务需要，对不同消息类型提供序列化、反序列化能力。

6、协议层协议层需要同时适配RDMA/TCP/UB三种通信协议栈。对于RDMA协议层的设计需要考虑：多线程并行发送RDMA请求时，并发请求的响应到达顺序与请求顺序不一致，因此不能在发送线程中通过检查CQ来查看自己的响应是否到达（可能先查到其它线程的响应），需要单独一个线程去检查CQ状态，这样就需要在发送线程与检查线程间进行同步，但线程同步机制很难满足时延要求（高并发场景下加解锁可能需要上千至上万个cycle），所以需要考虑协程或者无锁设计。

如果使用协程，在线程的协程中轮询完成队列，其他协程进行发送请求，但是需要在业务模块启用协程，通信模块无法控制管理发送线程。如发送端无法采用协程设计，为了降低调度开销，对于有锁设计，CQ检查线程应该单独绑核，通过RDMA协议请求(WR)结构体ibv_send_wr、完成响应(CQE)结构体ibv_wc及响应(WR)结构体ibv_recv_wr三者的wr_id相互关联，该信息可放于双边通信的消息头的msgId字段或单边通信的立即数字段。

wr_id是由通信组件传入的参数，可设置为消息的内存地址以避免重复。对于无锁设计，考虑采用run-to-complete模型，即线程间不共享QP，在一个线程内完成消息的发送和轮询事件，但资源消耗更大，更适用于对时延要求极高的单边操作场景。

RDMA原语的轮询CQ接口采用poll实现，对于大并发场景，poll的性能不及专门用于处理有大量IO操作请求的epoll异步编程接口。考虑设计epoll接口访问系统节点，轮询CQ完成队列，取代RDMA原语接口以获取更好性能。

RDMA协议不同传输模式支持的最大传输大小如上表所示， 双边通信可使用不可靠报文以节省内存资源，提高通信效率，但是最大传输数据长度受限于网卡MTU，需要限制发送数据，或者进行拆包发送、组包接收。