GitHub开源自家负载平衡器GLB指引主机专案

GitHub对外开源了自家用于处理每秒数百万次请求负载平衡器GLB（GitHub Load Balancer）中的指引主机（Director）专案。由于原本的负载平衡器难以水平扩展，GitHub重新设计了GLB，而且为了拥有最好的效能，GLB在GitHub裸机云上运作，并经手了大部分GitHub的公开网页和Git流量，同时也处理一些关键的内部系统，像是高可用度的MySQL丛集的流量。

在GitHub开发GLB之前，他们使用複杂的组件建构负载平衡层，在一小组非常大型的机器上运作HAProxy，且只能使用非常特定的硬体配置以允许10G连结故障转移，并在需要的时候进行垂直扩展。这些少数大型机器都有专用的网路链结，把流量导向网路中枢，这种将网路设备、负载平衡主机和负载平衡器配置绑在一起的设计，使得水平扩展过于困难，因此GitHub开始动手设计符合需求的解决方案GLB。

GLB有许多特性，能在一般商用主机运作、方便水平扩展、支援高可用性，还能如同一般软体迭代和部署，具备适应典型的DDoS攻击等多种特性外，在典型的使用案例中，每个物理主机都分配一个公共IP，DNS可以为多重IP进行分流，进而跨多伺服器的切分流量。但是GLB能允许多伺服器提供单个IP位址的服务，也就是说，GLB的设计不再需要透过增加IP来增加容量，也不会因为伺服器故障而造成所属IP失效。在GLB中使用等价多路径（Equal-Cost Multi-Path, ECMP）路由法，跨多重路径的将封包路由到相同物理目的地伺服器。

而指引主机便是要做到这件事主角，也是这次GitHub开源的专案。GLB指引主机是第4层负载均衡器，在一开始设计时，GitHub就想改进指引主机层成为通用模式，除了可在大量的物理机器上扩展单一IP位置外，同时在伺服器变更时，尽可能的降低连线中断的情况发生，这对于生活在网路连线不稳国家的用户尤其重要。GitHub特别强调，GLB指引主机不会替换像是HAProxy和Nginx这样的服务，而是位在这些服务或任何TCP服务之前的一层，允许这些服务跨多物理机器扩展，而不需要每台机器拥有各自的IP位置。

GLB使用了Rendezvous杂凑演算法的变体，能支援常量时间搜寻。系统会生成单一固定大小的转送表格（Forwarding Table），并以Rendezvous杂凑演算法排序元件将一组代理伺服器填入表中，这个表以及代理状态会发送到所有指引主机伺服器，在代理流入流出时保持同步。当TCP资料封包到达指引主机时，系统会对来源IP进行杂凑，产生转送表中的索引。

GLB将负载平衡器的第4层与第7层两层分离，这样的设计并不少见，GLB中负责第4层工作的称为指引主机，主要用来引导流量，而第7层称为代理主机，负责代理连线到后端伺服器。GitHub提到，拆分第4层与第7层能够透过耗尽现有的连接，来从旋转（Rotation）中删除代理层节点，即使节点已经从旋转中移除，指引主机节点上的连结状态，仍将维持既存连线映射到既存的代理伺服器。由于代理层会频繁更改配置、升级或是扩展，因此存在这样的特性有助于管理工作。

GitHub在2016年就是出了GLB的消息，并且陆续开源GLB的各个部分，而直到现在，GitHub才开源了GLB关键部分之一的指引主机专案。