LVS 的传统方式是运用IP over IP（IPIP）隧道。客户端 IP 数据包封装在外部IP数据包内，并转发到代理效劳器，代理效劳器对其停止解封装。但很难在 IPIP 数据包中编码其他效劳器的元数据，由于独一可用的空间是 IP 选项，数据中心路由器传递未知 IP 的数据包四处置软件（称之为“第2层慢速途径”），速度从每秒数百万到数千个数据包。

为了避免这种状况，需求将数据隐藏在路由器不同数据包格式中，避免它试图去了解。我们最后采用原始 Foo-over-UDP（FOU）和自定义 GRE载荷（payload），基本上封装了 UDP 数据包中的一切内容。我们最近转换到通用 UDP 封装（GUE），它提供了封装外部 IP 协议的标准 UDP 数据包。我们将辅佐效劳器的 IP 放在GUE标头的私有数据中。从路由器的角度来看，这些数据包都是两个普通效劳器之间的外部数据中心 UDP 数据包。

运用 UDP 的另一个益处是源端口可以运用每个衔接的哈希填充，以便它们经过不同的途径（在数据中心内运用ECMP）在数据中心内活动，并可在代理效劳器的 NIC 的不同 RX 队列上接纳音讯（相似运用 TCP/IP 头字段的哈希）。这对 IPIP 是不能够的，由于大少数数据中心的 NIC 只能了解普通 IP，TCP/IP 和 UDP/IP。值得留意的是，NIC 无法查看 IP/IP 数据包。

当代理效劳器想要将数据包发送回客户端时，它不需求封装或经过我们的导向器层（director tier）前往，它可以直接发送数据到客户端（通常称为“Direct Server Return”）。这是典型的负载平衡器设计，关于内容提供商尤其有用，由于大少数状况都是出站流量远大于入站流量。

数据包流如下图所示：

引入DPDK

自从初次地下讨论了我们的初始设计以来，我们曾经完全运用 DPDK重写了 glb-director 。DPDK 是一个开源的经过绕过Linux内核，允许从用户空间停止十分快速的数据包处置的项目。这样就可以在普通 NIC 上经过 CPU 上完成 NIC 线路速率处置，并可轻松扩展导向器层，以处置与公共衔接所需的入站流量一样多的流量。这在防 DDoS 攻击中尤为重要，我们不希望负载平衡器成为瓶颈。

GLB 最后的目的之一是可以在通用数据中心的硬件上运转，而无需任何特殊的硬件配置。 GLB 的 Director 和代理效劳器都可像数据中心的普通效劳器一样供应。每个效劳器都有一对绑定的网络接口，这些接口在 GLB Director 效劳器上的 DPDK 和 Linux 系统之间共享。

现代 NIC 支持SR-IOV，这种技术可以使单个 NIC 从操作系统的角度看起来像多个 NIC。这通常由虚拟机管理顺序运用，以要求真实 NIC（“Physical Function”）为每个 VM 创立多个虚拟 NIC（“Virtual Functions”）。为了使 DPDK 和 Linux 内核可以共享 NIC，我们运用 flow bifurcation，它将特定流量（目的是 GLB IP 地址）发送给我们DPDK 在 Virtual Function 上处置，同时将剩余的数据包与 Linux 内核的网络堆栈保留在 Physical Function 上。

我们发现 Virtual Function 上 DPDK 的数据包处置速率可以满足要求。 GLB Director 运用 DPDK Packet Distributor形式来分发封装数据包的义务到机器上的 CPU，支持恣意数量的 CPU 中心，由于它是有形状的，可以高度并行化。

GLB Director 支持婚配和转发包含 TCP 有效负载的入站 IPv4 和 IPv6 数据包，以及作为 Path MTU Discovery的一部分的入站 ICMP Fragmentation Required 音讯。

运用Scapy为DPDK参加测试用例

一个典型的成绩是，在创立（或运用）那些运用了低级原语（例如直接与NIC通讯）但是高速运转的技术时，它们变得十分难以测试。作为创立GLB Director的一部分，我们也创立了一个测试环境，支持对我们的DPDK运用停止复杂的端对端包流测试，经过影响DPDK的方式支持一个环境笼统层（EAL），允许物理NIC和基于libpcap的本地接口，在运用视图中是相反的。

这允许我们在Scapy中写测试，运用复杂的Python的lib包查看，操作和写数据包。经过创立一个Linux的虚拟网卡驱动，一边用Scapy，另一边用DPDK，我们能传输定制的包并且验证我们软件在另一边支持的功用，这是一个残缺GUE封装的后端代理效劳希冀的数据包。

该办法允许我们测试更多的复杂行为，例如为了正确路由，遍历传输层的ICMPv4/ICMPv6头获取源IP和TCP端口，以便正确转发来自外部路由器的ICMP音讯。

安康反省

GLB的设计包含了优雅地处置效劳器缺点的部分。目前设计包含主/备，关于给定的转宣布/客户端，意味着我们可以经过安康反省经过察看每个Director来处置单效劳器缺点。我们运转一个名为glb-healthcheck的效劳，它不断验证每个后端效劳器的GUE隧道和恣意HTTP端口。

当效劳器出现缺点时，我们将切换主/备，将备换成主。这是效劳器的“软切换”，支持缺点转移的好办法。假设安康反省失败是误报，则衔接不会中缀，它们只会换一条不同的途径遍历。

proxy运用iptables提供第二次时机

构成GLB的最后一个组件是Netfilter模块和iptables的目的，它在每个代理效劳器上运转，并提供“第二次时机”停止设计。

此模块提供了一个复杂的义务，依据Linux内核TCP堆栈，确定每个GUE数据包的外部TCP / IP数据包能否在本地有效，假设不是，则将其转发到下一个代理效劳器（备效劳器），而不是在以后效劳器解封装。

在数据包是SYN（新衔接）或在本地对已树立的衔接有效的状况下，以后效劳器会接纳它。然后，我们接纳GUE包，运用包含fou模块的Linux 内核4.x GUE在本地处置它。

【编辑引荐】

外媒速递：14种错误令你的软件项目遭遇失败

微软TypeScript 3.0 正式发布：引入“项目援用”新概念

阿里巴巴开源 Sentinel，进一步完善 Dubbo 生态

GitHub 推出 Python 安全正告，辨认依赖包的安全破绽

外媒速递：区块链的演进——以开源为中心

(责任编辑：admin)