1. HLB基本介紹
在網絡安裝中，硬件負載均衡器（HLB）一般安裝在服務器前面，作爲客戶端和服務器之間的透明代理，在請求轉發到服務器前進行流量管理。
一般而言，在基於TCP代理的負載均衡技術實現中，客戶端與服務器的請求通信過程如下：
1）客戶端向負載均衡器提供的虛擬IP地址VIP發送請求（CIP → VIP）；
2）負載均衡器從提前配置的多個子網IP地址中選擇一個，替代客戶端請求的源IP，並依據負載均衡算法，選擇一個服務器IP作爲目的IP，發送請求 (SNIP → SIP)；
3）服務器處理後將響應結果發回負載均衡器（SIP → SNIP）；
4）負載均衡器將最終結果返回給客戶端（VIP → CIP）。如下圖所示：
圖1.1 這樣一來，HLB與客戶端、服務器之間實際上是兩個相互獨立的TCP連接，服務器並不知道真正的客戶端IP，但CIP可作爲附加字段插入HTTP Header以告知服務器。
當然，除了TCP代理，負載均衡常用的實現機制還包括：DSR模式、Tunnel模式等。
2 流量管理
在eBay有極其龐大數目的機器（Machine）提供各樣的服務，而一組提供類似功能的機器可以簡單理解爲屬於一個Pool，那麼FE Team如何藉助負載均衡器將流量分發到不同的Machine和Pool呢？這裏以常用的負載均衡器之一NetScaler爲例介紹該過程。
2.1 NetScaler負載均衡器
NetScaler是Citrix公司提供的應用交付的硬件負載均衡器，其基本配置元素包括：虛擬服務器（Virtual Server）、服務（Service）、監控程序（Monitor）等。
- 虛擬服務器由名稱、VIP、端口、協議等表示，其端口和協議決定代表的具體服務器；
- 一般而言，虛擬服務器和服務協同工作，服務作爲LB上的邏輯抽象，綁定到虛擬服務器上，可以是服務器的IP:Port，也可以是下一層LB的虛擬服務器；
- LB對服務對象進行定時（比如每5秒）的健康探測，若探測失敗，則將服務標記爲DOWN，否則爲UP。LB分發請求時，DOWN的服務將被排除在外，流量只分發給UP的服務。
2.2 負載均衡
那麼，NetScaler如何將流量分發到不同機器上實現負載均衡流量管理呢？
舉個例子，如下圖所示，客戶端Client1和Client2均能通過NetScaler上的虛擬服務器VS_HTTP和VS_SSL連接服務，服務S1、 S2、S3和S4綁定到虛擬服務器，分別表示安裝在不同服務器上的應用程序。其中，VS_HTTP和VS_SSL具有相同的IP地址，但端口和協議均不同；服務S1和S2是服務器Server1和Server2上的HTTP應用程序，綁定到VS_HTTP，服務S3和S4是Server2和Server3上的SSL應用程序，綁定到VS_SSL。
圖2.1 當NetScaler通過10.10.10.10:80收到HTTP請求時，根據VS_HTTP上虛擬服務器和服務的綁定情況、相應的負載均衡算法選擇向Server1或Server2發送請求；同樣，當通過10.10.10.10:443收到HTTPS請求時，根據VS_SSL上的配置綁定將請求發送給Server2或Server3。由此實現了流量的分配與轉發。
2.3 負載均衡算法
NetScaler作爲業內領先的硬件負載均衡器，具有極其強大的、多元化的負載均衡算法，用於決定將客戶端請求轉發到哪一服務器。最新版本的NetScaler支持十餘種負載均衡算法，能夠適應衆多應用場景。常用的算法如：
- 最少連接算法（Least Connection），優先選擇連接數最少的後端節點，是默認的負載均衡算法，在大多數情況下提供了最佳性能；
- 輪詢算法（Round Robin），將用戶請求依次輪流分配給內部服務器；
- 最少響應時間算法（Least Response Time）， 優先選擇具有最少活躍連接和最低平均響應時間的服務器，可擴展爲基於監控程序的最小響應時間算法（LRTM）；
- 最小帶寬算法（Least Bandwidth），優先選擇當前流量吞吐最小的服務器；
還有令牌算法（Token）、基於URL的Hash算法、域名Hash算法等，不作詳述。
如果考慮不同服務器的處理能力不同，還可以給每個服務器分配不同權值，通過設置比率調整調度機率。
2.4 應用交付之七層規則
NetScaler是以軟件爲中心的應用程序交付解決方案，可以通過特定的負載均衡算法將應用中的流量分發到不同機器上，那如果應用要求分發到指定Pool，又該怎麼做呢？
這就涉及到七層規則啦。NetScaler常用的七層規則包括：
- Content Switching Policy，將請求路由到指定的下游Pool；
- Responder Policy，針對特定的HTTP請求實現重定向（HTTP Redirect）、丟棄（TCP DROP）、重置（TCP RESET）等；
- Rewrite Policy，改寫請求後轉發給後端服務，“改寫”包括：改寫URL、添加/修改/刪除Header。
一個VIP可以根據應用要求同時支持多種規則。
若用戶要求將流量分發到指定Pool，則添加Content Switching Policy，將符合要求的請求路由到相應Pool，並綁定到VIP對應的虛擬服務器上。
3. 高可用性
瞭解瞭如何將流量分發到不同的Machine和Pool後，eBay FE Team又是如何部署硬件負載均衡器確保其高可用性呢？
一般而言，FE Team爲每個負載均衡器同時部署兩臺設備。
圖3.1 其中，主設備（Primary Node）主動連接並管理服務器，輔助設備（Secondary Node）與主設備配置始終保持同步，若主設備發生故障，則輔助設備成爲主設備。主設備和輔助設備相互定時發送檢測信號和運行狀況檢查請求，從而監控彼此，以提供高可用性。
當然爲了不同場景的需要，我們還提供了BGP等方式，這裏不作詳述。
4. 多數據中心多層部署
鑑於eBay擁有多個數據中心，數萬Pool及上百萬服務單元（VM/BM/Pod等），需要同時部署多層負載均衡器以確保流量的正確轉發，每個Pool在不同數據中心的各層負載均衡器上都有配置。
如下圖所示，假設有3個數據中心，最上層GSLB/GTM作爲DNS Resolver實現DNS解析，返回給用戶不同數據中心最合適的IP列表；GSLB/GTM下面綁定兩層硬件負載均衡器，一層主要用於配置七層規則和SSL，另一層主要用於負載均衡的流量轉發。每一層中均有不同類型的硬件負載均衡器，包括常用的NetScaler和F5。
圖4.1 一般而言，將來自相同數據中心的客戶端訪問的大部分流量（如：99%）分發到本數據中心，少部分流量（如：1%）轉到其他數據中心，實現跨數據中心訪問。若一個數據中心出現問題，流量會自動轉發到其他數據中心。
5.自動化管理方案
5. 自動化管理方案流量管理是一個複雜的過程，FE Team結合多年實戰經驗，基於Python Django框架，利用eBay內部的LBMS等接口，開發出LB的控制面（Control Plane）工具：EasyLB，實現了流量管理的自動化。其功能包括：七層規則的快速準確部署，配置的標準化管理，VIP的無縫遷移，多方位的性能監控等，爲ATB（Availability to Business）提供了堅實保障。自動化方案不僅降低了人爲失誤，同時也提升了應用的交付效率。
6. 小試牛刀
介紹到這裏，小夥伴們可能會想：“這些系統都不便宜，咱也不知道，咱也不敢問呀”。其實作爲普通用戶，我們完全有辦法零成本使用負載均衡器。
以NetScaler爲例，Citrix公司提供了一個容器化的應用交付控制器NetScaler CPX，方便用戶體驗。我們應用NetScaler CPX做了2個小實驗，深入理解負載均衡流量管理和七層規則，有興趣的小夥伴可以試試。
選擇兩臺CentOS主機S1和S2，假設IP分別爲10.148.177.194和10.148.177.197，在S1上安裝Docker並設置NetScaler CPX實例，搭建負載均衡拓撲。
6.1 安裝Docker
首先安裝Docker。
圖6.1 6.2 啓動NetScaler CPX和主機端口
獲取NetScaler CPX 鏡像並在後臺以特權模式運行容器，指定NetScaler最終用戶許可協議EULA，暴露SSH 22和HTTP 80端口，並將30000端口映射出來用於實驗，設置ulimit參數core=-1不限制core文件大小，輸入密碼後進入容器僞終端。
圖6.2 使用如下腳本，分別啓動S1和S2的80端口，設置GET請求返回主機名Server及IP。
圖6.3 6.3 搭建負載均衡拓撲
實驗1：負載均衡流量管理
假設S1和S2屬於相同Pool，均安裝有應用程序A，分別表示爲服務svc-A-S1和svc-A-S2，並綁定到虛擬服務器VIP-A。CPX對外暴露30000端口用於訪問應用程序A，負載均衡拓撲、CLI命令及CPX中的配置分別如下圖所示。
圖6.4
圖6.5
圖6.6 則在S1執行for i in {1…100}; do curl -v 127.0.0.1:30000 2>/dev/null | grep Server; done訪問服務A，流量會交替分發到S1和S2上，如下圖所示，即：將流量轉發到不同的機器，實現了負載均衡的流量管理。
圖6.7 實驗2：七層規則
假設S1和S2屬於不同Pool，S1安裝應用程序A1，S2安裝應用程序A2，分別表示爲綁定到LBV-A1的服務svc-A1和綁定到LBV-A2的服務svc-A2，CPX對外暴露30000端口，默認情況下訪問S1上的應用程序A1。添加Content Switching Policy，當請求token爲/check時，將請求路由到S2上的A2，負載均衡拓撲、CLI命令及CPX中的配置分別如下圖所示。
圖6.8
圖6.9
圖6.10 則在S1上分別訪問127.0.0.1:30000和127.0.0.1:30000/check，結果如下，實際上分別訪問了服務器S1和S2，驗證了可通過添加七層規則將流量分發到不同Pool的服務器。
圖6.11 另外，NetScaler CPX還可以用於管理微服務和負載均衡東西向流量。這裏附上NetScaler官網和API，有興趣的同學可以掃碼瞭解詳情，進一步實驗喔 。
點擊上圖
掃碼查看NetScaler
點擊上圖
掃碼查看API總結
eBay FE Team應用多數據中心多層部署的硬件負載均衡器，基於負載均衡算法將流量轉發到不同Machine，基於七層規則將流量轉發到不同Pool，應用自動化工具實現了高可用的流量分發與管理，確保了用戶業務應用能夠快速、安全、可靠地交付。
爲了方便小夥伴們實驗，本文還在基於容器的NetScaler CPX上實現了無成本體驗NetScaler，大家是不是很想試試呢？
作者介紹：
Yuting Cao，eBay軟件開發工程師，2019年上海交通大學碩士畢業，目前致力於負載均衡流量管理以及自動化平臺的實現
本文轉載自公衆號eBay技術薈（ID：eBayTechRecruiting）。
原文鏈接：
