负载均衡的原理说明.doc

-
. z.
大家都知道一台效劳器的处理能力，主要受限于效劳器自身的可扩展硬件能力。所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通效劳器组成一个系统，来完成高网络系统设计与实现USENI*研讨会〔NSDI'16〕上，来自谷歌、加州大学洛杉矶分校、Space*公司的工程师们分享了"Maglev：快速、可靠的软件网络负载均衡器"，介绍了从2021年开场在生产环境投入使用的软件负载均衡器。其设计理念和我们非常相似，同样是ECMP+一致性哈希；同样是KernelBypass模式；单机性能也和我们的Vorte*非常接近。
关于Vorte*的HighAvailability实现
四层负载均衡器的主要功能是将收到的数据包转发给不同的后端效劳器，但必须保证将五元组一样的数据包发送到同一台后端效劳器，否则后端效劳器将无法正确处理该数据包。
以常见的HTTP连接为例，如果报文没有被发送到同一台后端效劳器，操作系统的TCP协议栈无法找到对应的TCP连接或者是验证TCP序列号错误将会无声无息的丢弃报文，发送端不会得到任何的通知。如果应用层没有超时机制的话，效劳将会长期不可用。
Vorte*的可靠性设计面临的最大问题就是如何在任何情况下防止该情况发生。Vorte*通过ECMP集群和一致性哈希来实现极致程度的可靠性。
首先，我们来考察一下负载均衡效劳器变化场景。这种场景下，可能由于负载均衡效劳器故障被动触发，也可能由于运维需要主动增加或者减少负载均衡效劳器。
此时交换时机通过动态路由协议检测负载均衡效劳器集群的变化，但除思科的*些型号外大多数交换机都采用简单的取模算法，导致大多数数据包被发送到不同的负载均衡效劳器。
Vorte*效劳器的一致性哈希算法能够保证即使是不同的Vorte*效劳器收到了数据包，仍然能够将该数据包转发到同一台后端效劳器，从而保证客户应用对此类变化无感知，业务不受任何影响。
-
. z.
这种场景下，如果负载均衡器是LVS且采用RR(RoundRobin)算法的话，该数据包会被送到错误的后端效劳器，且上层应用无法得到任何通知。
如果LVS配置了SH(SourceHash)算法的话，该数据包会被送到正确的后端效劳器，上层应用对此类变化无感知，业务不受任何影响；
如果负载均衡器是NGIN*的话，该数据包会被TCP协议栈无声无息地丢弃，上层应用不会得到任何通知。
其次，来考察后端效劳器变化的场景。
这种场景下，可能由于后端效劳器故障由安康检查机制检查出来，也可能由于运维需要主动增加或者减少后端效劳器。
此时，Vorte*效劳器会通过连接追踪机制保证当前活动连接的数据包被送往之前选择的效劳器，而所有新建连接则会在变化后的效劳器集群中进展负载分担。
同时，Vorte*一致性哈希算法能保证大局部新建连接与后端效劳器的映射关系保持不变，只有最少数量的映射关系发生变化，从而最大限度地减小了对客户端到端的应用层面的影响。
这种场景下，如果负载均衡器是LVS且SH算法的话，大局部新建连接与后端效劳器的映射关系会发生变化。*些应用，例如缓存效劳器，如果发生映射关系的突变，将造成大量的cachemiss，从而需要从