开源L4负载均衡器DPVS源码分析

1. 连接跟踪表设计

• 技术重点：DPDK ThreadLocal+哈希表+DPDK大页内存池
• Conntrack表就是很简单的5元组哈希表，哈希冲突利用双向链表来解决；
• 个人感觉为了开发方便可以直接用DPDK提供的rte_hash；
• Conntrack表使用了DPDK Threadlocal，提供无锁的Conntrack信息访问，每个核维护一个Conntrack表；
  
• Conntrack表key是五元组，value是连接上下文的地址，指向存储在DPDK的rte_mempool中连接上下文。利用内存池能加快申请和释放内存，内存池每一个socket一个。
  
  2. 连接老化设计
  • 准确来说是定时器设计，使用了很经典的时间轮算法，空间换时间，比经典的WebServer中的小根堆要快。它会占用很大的内存来存储每个时间点，但是DPDK本身就会使用大页占很多系统内存，这点真的不算什么，哈哈哈哈哈;
  • 轮子转动频率是1000HZ，就是1s会走1000次，就是每1ms走一下；
  • 只用了两级时间轮，大概是为了提高运行效率（空间换时间），然后每一级轮子有2^18个格子，能够允许的超时时长还是很大的；
  • 轮子使用rte_timer来驱动的，每1ms会驱动最低级的轮子走一格，这个也可以用rte_rdtsc()获取cpu cycles来驱动。
    

3. 无锁通信设计

• 主要是通过rte_ring来实现master核和slave核之间的无锁通信；
• 通信的目的主要是set参数值和get参数值；
• 每一个核都会单独维护virtual server和real server的信息：
  • 主核收到用户的添加服务的命令后会将virtual server核real server的信息通过rte_ring下发到各个salve核心；
  • 收到用户的获取数据的命令后，master核心会通过rte_ring获取各个slave核心的信息并进行汇总然后返回给用户；

4. FullNAT实现

• 为什么更推荐使用Full-NAT，而不是DNAT?

  • DNAT导致上行流量的五元组和下行流量的五元组不对称，从而上行流量和下行流量被rss哈希到不同核上，从而只能单核运行，多核运行就得加锁或者跨核传递数据包了；

  • 尽管现在很多网卡和中间设备都支持了对称hash，但是nat之后还是很难保证上下行流量落到相同的处理单元上；

  • Full-NAT可以在流量上行时，将流量的源地址设定成与当前队列绑定的地址，这样下行的时候能够通过rte_flow被送入正确的队列；
    

  • 每一个源ip都有一个地址池，它的端口号被平均分给不同队列，并且会跟对应的virtual server绑定；

  • 每一个virtual server都有一个源ip链表来保存源ip池，通过RR算法来决定当前连接用哪个源ip；

  • 每个核的的每个源ip都有16个池，每个池子里的端口号都是一样的，通过DNAT后的目的地址决定使用哪个池子里的源端口

    • 这意味着一个源IP:Port组合可以最多被使用16次，且这16条连接的目的地址一定不一样；
    • 源地址的复用次数往往和服务的RealServer数量强相关。
      

  • Full-NAT配置太少源地址会导致什么？

    • 会导致总链接数变得很少，在测CPS或RPS的时候源地址池要尽量大
    • DNAT模式一般不会出现这种问题，因为virtual_addr和real_addr是一对多的关系，每个连接都有多个备选的real_addr;
    • Full-NAT和snat一样，都存在着源地址枯竭的问题，本质都是将非常多的连接通过PAT方式将无数多的client地址收敛映射到少量local_addr上；
    • DPVS Full-NAT模式下一个服务（VIP:VPort）支持的最大连接数基本等于：
      • 当RealServer数量<=16, MAX-connection=源地址池中IP数 x 65536 x RealServer数量
      • 当RealServer数量>16, MAX-connection=源地址池中IP数 x 65536 x 16(如果你的hash池只配了16个)
      • 所以尽量多的去分配源IP