負載平衡介紹

load balence

傳統的負載平衡器

傳統的負載平衡器幾乎都是由一台特定的硬體服務器來處理,著名的廠商譬如 F5。而這類型的負載平衡器為了達到高可用性(HA),所以在建置上通常都會部署兩台機器,採取AP(Active-Passive)模式來運行。這樣的優勢就是當一台機器壞時,另外一台能夠接取其任務繼續服務。然而其缺點就是其能夠服務的能力不夠大,整個處理速率都受限於一台機器本身,同時不論後端的服務機器數量有多少,前面都只有兩台負載平衡器再處理,因此整體服務的效率低落。最後,其本身沒有彈性且沒有辦法透過程式去進行修改,在整個更新與變化的需求上沒有辦法滿足Google如此快速成長的環境。

Google Maglev

maglev
Maglev 期待中的角色就如同上圖右半邊所示,Maglev希望是個分散式的軟體架構,可以根據背後的需求來動態的調整Maglev的數量,同時所有的機器都能夠同時用來處理所有的流量需求。
Google本身的服務,譬如 Gmail, Google Search本身都含有一組或是多組以上的 IP address,而這些 IP address 被稱為 Virtual IP(VIP)。原因是這些 IP 本身是不存在於任何實體網卡上,只是讓網際網路中的路由器能夠根據這些 VIP 將這些封包給導向到 Google 的服務器之中。接下來這些封包就會傳送到 Maglev這群服務器中去處理,再根據VIP找到對應的服務,然後把封包傳送給真正的服務器去處理。

當 Maglev 收到這封包的時候,他就會根據目的地的 VIP 去反查,就可以知道當前這個封包應該要往哪個 service傳送,但是我們知道因為 VIP 本身是不存在的,所以這時候 Maglev 會幫當前整個封包再多包上一層 Generic Routing Encapsulation(GRE) 的標頭檔,該標頭內的資訊則是後端服務器真正的 IP address,因此封包就能夠順利的到達後端服務器,這也是圖中所標示Encapped inbound traffic的流向。

當後端服務器處理完畢請求時,這時候會回傳封包到發送端(也就是使用者電腦),這邊有個要注意的事情是通常情況下, 使用端發出的請求封包會比服務器發出的回應封包還要來得小很多,因此 Maglev 並不想要讓這些回應封包還要回歸到 Maglev 去處理。
所以當服務器收到封包後,要先解讀GRE,接下來讀取到本來的 VIP,然後將此 VIP 當作封包的來源IP後讓該封包直接送回給使用者端。
detail
所以就如同該圖示中三號紅色的 Unencapped outbound traffic。至於要如何讓這些封包能夠從服務器本身不經過 Maglev 而直接到達上層的 Router,這邊論文內本身並沒有說明,只有提到透過 Direct Server Return (DSR)的技術來達到此功能。
如同前面所述, Maglev 本身會透過 BGP 的方式向路由器去通知路由表的更新,因此在 Maglev 內部會有兩個元件,分別是 Forwarder 以及 Controller。這兩個元件會透過 Config Objects來學習 VIP的資訊,可以是透過讀取檔案的方式,或是透過 RPC 的方式來更新。
Controller 會定期檢查 Forwarder 的資訊,只要當前有任何 VIP 變動,不論是新增或是減少,都會透過透過 BGP 將 VIP的更動一路往外宣傳,根據這種舉動可以確保 Router 要轉發封包時,一定會轉發到能夠正常運作的 Maglev 伺服器。
而當 VIP 的封包到達 Maglev 時,都會交由 Forwarder 來處理,對於 Forwarder 來說,每個 VIP 可以對應到一個或多個的 Backend Pool,而每個 Backend Pool 可能包含一組或多組的實體 IP,而這些IP則會對應到後方真正的服務器 IP。
對於每個 Backend Pool來說,背後都會對應到一組或多組的 Health Checker,這些 Health Checker會去檢查該 Backend Pool內所有的服務是否當前都運作正常,只有都運作的正常的Backend Pool才會被 Forwarder 視為一個封包轉送目的地的候選人。根據此架構圖,其實可以看到有些後方服務器(IP)是對應到多組的 Backend Pool,所以在 Health Checker的時候會特別去進行這邊的去重複化,避免相同的事情重複多次來減少額外的開銷。
forwarder

參考資料