F5掃盲及案例分享

IT那活兒發(fā)布于2023-01-11 13:20 / 1138人閱讀

F5掃盲及案例分享

說起F5，可能有些小伙伴比較陌生，先簡單介紹下F5。由于網(wǎng)絡(luò)各個核心部分隨著業(yè)務(wù)量提高，訪問量和數(shù)據(jù)流量快速增長，其處理能力和計算強度也相應(yīng)的增大，使得單一的服務(wù)器設(shè)備根本無法承擔。針對此情況衍生出來的一種廉價透明有效的方法，以此擴展現(xiàn)有網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬、增加吞吐量、加強網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的靈活性和可用性的技術(shù)就是負載均衡（LoadBalance），也稱之為F5。

F5部署模式

路由模式：

旁掛模式：

F5實現(xiàn)過程舉例說明

F5負載均衡器應(yīng)用交換機后面的一組服務(wù)器10.1.1.4:80、10.1.1.5:80、10.1.1.6:80對外構(gòu)成一臺虛擬的服務(wù)器（VirtualServer）192.168.101.1:80，對外提供服務(wù)。當一個訪問虛擬服務(wù)器192.168.101.1:80的請求到達負載均衡器后，負載均衡器根據(jù)預(yù)先設(shè)定的負載均衡算法從服務(wù)器pool(WEB_POOL)中挑選一臺服務(wù)器來服務(wù)該請求，例如選定的是10.1.1.4:80；然后通過網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）將訪問請求包的目的地址與端口轉(zhuǎn)換成10.1.1.4:80，并將數(shù)據(jù)包發(fā)給10.1.1.4。服務(wù)器10.1.1.4處理訪問請求，并作出回應(yīng)?；貞?yīng)的包必須返回到負載均衡器上，由負載均衡器將回應(yīng)包的源地址與端口轉(zhuǎn)換回虛擬服務(wù)器的地址與端口，并返回給客戶。這樣完成一次訪問過程。

會話保持方法

在大多數(shù)WEB應(yīng)用系統(tǒng)或者需要進行用戶身份認證的在線系統(tǒng)中，一個客戶與服務(wù)器經(jīng)常經(jīng)過三次以上交互過程才能完成一筆交易或一個請求。交互過程是密切相關(guān)的，服務(wù)器進行交互過程的下一個交互步驟，需要了解上一交互過程的處理結(jié)果，或者上幾步的交互過程結(jié)果，服務(wù)器進行下一步操作時就要求所有這些相關(guān)的交互過程都由一臺服務(wù)器完成，而不能被負載均衡器分散到不同的服務(wù)器上。這就涉及到會話保持，常見會話保持如下。

簡單會話保持：

簡單會話保持也被稱為基于源地址的會話保持，是指負載均衡器在作負載均衡時是根據(jù)訪問請求的源地址作為判斷關(guān)聯(lián)會話的依據(jù)。對來自同一IP地址的所有訪問，請求在作負載均時都會被保持到一臺服務(wù)器上去。

基于源地址的會話保持實現(xiàn)起來簡單，效率也比較高。存在的問題就在于當多個客戶是通過代理或地址轉(zhuǎn)換的方式來訪問服務(wù)器時，由于都分配到同一臺服務(wù)器上，會導(dǎo)致服務(wù)器之間的負載嚴重失衡。

基于Cookie的會話保持：

在Cookie插入模式下，Big-IP將負責插入cookie，后端服務(wù)器無需作出任何修改。當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIG-IP，BIG-IP根據(jù)負載平衡算法策略選擇后端一臺服務(wù)器，并將請求發(fā)送至該服務(wù)器，后端服務(wù)器進行HTTP回復(fù)（不帶cookie）被發(fā)回BIGIP，然后BIG-IP插入cookie，將HTTP回復(fù)返回到客戶端。當客戶請求再次發(fā)生時，客戶HTTP請求（帶有上次BIGIP插入的cookie）進入BIGIP，然后BIGIP讀出cookie里的會話保持數(shù)值，將HTTP請求（帶有與上面同樣的cookie）發(fā)到指定的服務(wù)器，然后后端服務(wù)器進行請求回復(fù)，由于服務(wù)器并不寫入cookie，HTTP回復(fù)將不帶有cookie，恢復(fù)流量再次經(jīng)過進入BIG-IP時，BIG-IP再次寫入更新后的會話保持cookie。

常用負載均衡算法

輪詢（RoundRobin）：順序循環(huán)將請求一次順序循環(huán)地連接每個服務(wù)器。當其中某個服務(wù)器發(fā)生故障，BIG/IP就把其從順序循環(huán)隊列中拿出，不參加下一次的輪詢，直到其恢復(fù)正常。
比率（Ratio）：給每個服務(wù)器分配一個加權(quán)值為比例，根椐這個比例，把用戶的請求分配到每個服務(wù)器。當其中某個服務(wù)器發(fā)生故障，BIG/IP就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。
優(yōu)先權(quán)（Priority）：給所有服務(wù)器分組，給每個組定義優(yōu)先權(quán)，BIG/IP用戶的請求，分配給優(yōu)先級最高的服務(wù)器組（在同一組內(nèi)，采用輪詢或比率算法，分配用戶的請求）；當最高優(yōu)先級中所有服務(wù)器出現(xiàn)故障，BIG/IP才將請求送給次優(yōu)先級的服務(wù)器組。這種方式，實際為用戶提供一種備份的方式。
最小的連接數(shù)（LeastConnection）：傳遞新的連接給那些進行最少連接處理的服務(wù)器。當其中某個服務(wù)器發(fā)生故障，BIG/IP就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。

常用檢查方式

ICMP Monitor

利用互聯(lián)網(wǎng)控制信息協(xié)議（ICMP）檢查節(jié)點的狀態(tài)。

TCP　Monitor

通過嘗試從節(jié)點接收特定內(nèi)容來驗證TCP服務(wù)。

HTTPMonitor

通過嘗試從網(wǎng)頁接收特定內(nèi)容來驗證HTTP服務(wù)。

案列解析

以某業(yè)務(wù)為例進行F5配置解析，首先創(chuàng)建http健康性檢測規(guī)則，首先進入負載均衡的健康性檢測功能模塊，點擊create創(chuàng)建健康性檢測規(guī)則，如下圖所示：

然后開始配置健康性檢測檢測路徑及返回值，協(xié)議為http協(xié)議，檢測路徑需要由項目相關(guān)開發(fā)人員提供，HTTP/1.1表示業(yè)務(wù)所使用的http版本號，200表示檢測路徑信息接收成功(也可根據(jù)業(yè)務(wù)curl返回值中特定字段進行設(shè)置，當然也可以采用tcp端口檢測以及icmp檢測等F5自帶檢測功能進行配置，此案例以http檢測為例)

對健康檢測路徑進行驗證，可使用curl以及wget命令對健康性檢測路徑進行驗證，確認路徑是否正確，可根據(jù)curl以及wget返回值來判斷業(yè)務(wù)是否正常。

pool配置，首先創(chuàng)建pool，并配置名稱、健康性檢測規(guī)則、負載方式相關(guān)信息，然后添加相應(yīng)的后臺服務(wù)器節(jié)點，status為綠色表示節(jié)點健康性檢測通過，負載方式本案例默認采用輪詢方式，也可根據(jù)具體需求進行調(diào)整，配置如下所示：