给DPVS加上SESSION同步功能

前言

DPVS是一款爱奇艺开源的基于DPDK的优秀软件(https://github.com/iqiyi/dpvs)。利用DPDK工作在用户空间的特性，相比于内核空间的LVS,我们可以使用用户空间的一系列工具/中间件等完成很多在内核空间很难完成的功能。

Just for fun

虽然笔者日常工作中是搞Java中间件开发的，但一直都对底层技术尤其是在网络层面抱有很大的激情与好奇心。偶然接触到DPDK这个用户态数据平面开发套件,看了其官方文档和源码后，不禁技痒难耐，于是就尝试在DPVS上增加一个Session同步功能。虽然和工作关系不大，但搞技术的乐趣不就在于不停的折腾么,Just For Fun!当然，由于精力原因，只是写出了原型并测试成功，距离生产环境还有很大的距离，毕竟不靠这个吃饭^_^。

DPVS

DPVS事实上就是一个负载均衡软件，源于LVS，我们常说的Virtual IP(VIP)就可以使用DPVS来支持，如下图所示:
这次笔者就是在DPVS在FullNAT模式下对于主从模式增加了Session同步功能。如下图所示:

没有SESSION同步功能会如何

由于DPVS的数据转发是通过内部的session表来分发数据包的,如果没有Session同步功能,那么对应的数据库由于找不到对应的Session进而被丢弃。如果Client端是通过tcp进行连接的话:
那么将会在配置的tcp重传超时之后报错。

TCP Client RealServer

如果SESSION同步会如何

如果Session同步后，由于新晋升的DPVS2 Master依旧能够知道将这个Packet发送到后面哪台RealServer，如果是采用TCP连接的话，在一次重传之后，依旧能够保证连接的稳定。

SESSION同步方法

笔者这次尝试的是主从模式下FullNat的Session同步,事实上只需要将FullNat下的两张Session表(Session_IN和Session_OUT)从Master同步到Slave即可。

如果工作在内核态的LVS如何同步

由于LVS这一类的软件工作在内核态，那么就需要使用比较复杂且难于调试的问题进行主从之间的通信，如下图所示:
内核态的调试由于比起用户态来说相对复杂,而且没什么好用的中间件，笔者就没有做这方面的尝试。

在用户态笔者采用Redis Pub/Sub同步

而在用户态，可用的工具就太多了,于是笔者就选择了使用Redis的订阅/发布(Pub/Sub)功能将Session表信息从Master同步到Slave,如下图所示:
由于FullNat采用五元组，所以笔者在Redis中Pub的Key为:

session_key_(af协议簇)
			 _(proto协议)
			 _(client源地址)
			 _(client端口号)
			 _(vip地址)
			 _(vip端口号)
			 _(localIP)
			 _(localPort)
			 _(RealServer目的地址)
			 _(RS目的端口号)
			 _(当前session所在CPUID)

SESSION同步工作线程

首先，笔者在DPVS启动的main函数除了DPVS的线程之外用pthread新建了两个线程，用于reids的Send(Pub)和Receive(Sub)。

线程间通信

发布信息到Redis

DPDK线程与Send/Recv线程间，同时ring_buffer进行通信。所以一开始创建的时候，就给每个DPDK线程创建了一个rte_ring(session_rings)。当每有新建连接动作时候，DPDK线程就会将新建连接的动作封装成一个消息扔到里面，然后由SendPub线程去消费。如下图所示:
由于ring_buffer是有限的，可能出现消息丢失的现象。 新建连接的DPVS运行栈为:

__dp_vs_in
	|->conn_sched
		|->tcp_conn_sched (tcp协议)
			/* only TCP-SYN without other flag can be scheduled */
			/* 即只有TCP-SYN包才会走新建连接的逻辑 */
			|->dp_vs_schedule
				|->dp_vs_snat_schedule (FullNAT模式)
					

在最终的dp_vs_snat_schedule代码中，加入一段代码:

static struct dp_vs_conn *dp_vs_snat_schedule(......)
{
	conn = dp_vs_conn_new(mbuf,iph,&param,dest,0);
	......
	// 加入把conn信息放入session_buffer的逻辑
	session_info_enqueue(conn);
	return conn;
}

放入逻辑，其实就是将conn的信息组装成一个sesion_msg结构体，然后将之前session_key的9个信息从conn中提取:

void session_info_enqueue(struct dp_vs_conn* conn){
	......
	int cid = rte_lcore_id();
	struct session_msg* msg;
	if(rte_mempool_get(message_pool,(void**)&msg) < 0){
		......
		return;
	}
	copy_conn_to_msg(conn,msg);
	if(rte_ring_enqueue(session_rings[cid],msg) != 0){
		...
		rete_mempool_put(message_pool,msg);
		return;
	}
}

从Redis订阅消息

同样的，有一个Recv(Sub)线程从Redis订阅信息，然后Recv(Sub)线程和DPDK间的线程也用ring_buffer来同步，不过另用了一个session_subscribe_buffer。
如图中所示，从Redis订阅到信息之后，将消息重新塞到session_subscribe_buffer(每个线程都有)里面。然后利用DPVS的job回调方法在每个线程中处理subscribe消息并通过此消息重建session表:

lcore_job_recv_fwd
	|->lcore_process_session_subscribe_ring

void lcore_process_session_subscribe_ring(...){
	struct rte_ring* ring = session_subscribe_rings[cid];
	...
	struct session_msg* msg;
	if(rte_ring_dequeue(ring,(void**)&msg) < 0){
		return;
	}
	new_dpvs_conn(msg);
	rte_mempool_put(message_pool,msg);
}

笔者在new_dpvs_conn里面做了FullNAT的两张session表同步操作。

void dp_vs_conn_new_from_session(struct session_msg* msg){
	......
	/*init inbound conn tuple hash*/
	// SESSION IN 表项构建
	t->af = msg->af;
	t->proto = msg->proto;
	......
	/*init outbound conn tuple hash*/
	// SESSION OUT 表项构建
	new->af = msg->af;
	new->proto = msg->proto;
	......
	// 绑定dest
	err = dp_vs_conn_bind_dest(new,dest);
	......
	// 绑定hash表
	dp_vs_conn_hash(new);
}	

MQ消费重放

用Redis做Pub/Sub只是笔者为了保持编码简单而做的选择。如果正式用在产线,笔者觉得还是要把这种Session发到Kafka这种queue里面，那么就可以将Session的变化落到本地。这样，在主备都宕机的情况下，可以通过消费Kafka中已有的消息重建Session表。

遇到的小坑

在笔者进行测试的时候，遇到的一个问题时，在Session同步之后，虽然Session表项同步无误，但始终tcp连接被断开，在加了各种Print判断和TCP dump了一堆之后。才发现，DPVS本身会对TCP的sequence进行重写以增加toa字段，所以导致TCP sequence对不上，进而连接被断开。为了简单起见，笔者注掉了这段代码，然后终于成功了！

static int tcp_fnat_in_handle(...)
{
	struct tcphdr *th;
	......
	// tcp_in_add_toa(conn,mbuf,th);
	// tcp_in_adjust_seq(conn,th);
	th->source = conn->lport;
	th->dest = conn->dport;
	
	return tcp_send_csum(af,iphdrlen,th,conn,mbuf);
}

不足之处

当前笔者只做了Session新建动作的同步，Session删除等其它动作还需要慢慢斟酌。 另外，由于时间精力所限，笔者对DPVS的编码只相当于做了一次简单的原型验证，还远远达不到产线高可用的要求。
不过，当测试成功，Master宕机后另一台Slave立马接上后，长连接(用的MySQL Client做测试)保持不断,查询数据依旧丝滑,仿佛什么都没发生过的时候(如果没有这个功能，只能坐等25s左右的卡主超时了,tcp_retries2=5)，就感觉非常的有成就感！

总结

笔者爱折腾、喜欢做有挑战的事。笔者在玩只狼的时候,在挑战蝴蝶夫人70多次败北终于成功后，那种喜悦难以言喻。这次玩DPVS也一样，在Debug了大半天之后，终于成功的感觉和只狼如出一辙，这也是我乐此不疲的原因,Just For Fun! 关注笔者公众号,获取更多干货文章: