dhcplb

为什么要这样做?

dhcplb 的创建是因为之前围绕 DHCP 的基础设施导致了在仅使用 Anycast+ECMP 时，区域内 DHCP 服务器的负载极不平衡（例如，10 台服务器中只有一台接收了超过 65% 的请求）。Facebook 的 DHCP 基础设施曾在 SRECon15 Ireland 上展示过（https://www.usenix.org/conference/srecon15europe/program/presentation/failla）。后来，增加了使其负责服务 DHCP 请求（服务器模式）的支持。之所以这样做，是因为拥有一个单线程应用程序（ISC KEA）在排队处理包同时向另一服务进行后端调用，对于我们来说并不具备很好的扩展性。

• 互联网上可用的所有中继实现都缺乏负载均衡功能。 * 控制代码可以让您实现以下功能: * 对我们的 DHCP 服务器的新版本进行 A/B 测试 * 实现覆盖机制 * 实现您需要的其他功能 # 为什么不使用现有的服务器? 我们需要一个服务器实现,可以同时实现以下两个功能: * 多线程设计,以避免在执行后端调用时阻塞请求 * 一个接口,可以调用其他服务以获取 IP 分配、引导文件 URL 等 # 在 Facebook 中如何使用 dhcplb? 以下图片展示了我们如何在生产基础架构中部署 dhcplb:

Facebook 的 TORs (机架顶部交换机)运行 DHCP 代理,这些代理负责转发广播 DHCP 流量