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關鍵部分之一的指引主機專案。


Advertisement

更多 iThome相關內容