目錄：
------F5 BIG-IP LTM負載均衡策略----------
1.1 LTM VS工作模式
1.2 負載均衡策略
------F5 BIG-IP LTM會話保持----------
2.1 為什么需要會話保持
2.2 常見的會話保持
------F5 BIG-IP LTM健康檢查----------
3.健康檢查
3.1.健康檢查有以下項目：
3.2 關聯健康檢查
3.3Monitor狀態報告
3.4 Pool失敗機制
------F5 BIG-IP LTM應用優化----------
4.BIG-IP LTM應用負載優化技術
4.1 TCP應用：（列出常用profile）
------F5 BIG-IP iRules介紹----------
5.1什么是iRules：
5.2 VS和iRules關系
------F5 BIG-IP LTM負載均衡策略----------
1.1 LTM VS工作模式
F5 BIG-IP LTM的內部對於數據包的處理方式，即是VS的工作類型，存在有四種工作模式,分別針對四層數據處理和七層數據處理；
四層處理模式有：Forwarding(IP)
Performance(Layer 4)
七層處理模式有：Standard
performance（HTTP）
1.1.1 Standard
·（首先與client建立連接，再與Pool member建立連接）
·默認工作工作在全代理模式，客戶端和服務器端的TCP連接完全獨立，BIG-IP維持兩個不同的連接。
·在三次握手結束后，BIG-IP按照負載均衡算法選擇Pool Member
·客戶端和服務器端的TCP參數由TMOS和雙方分別協商；
·默認情況下，以客戶端源IP與后台建立連接；在打開SNAT的情況下用SNAT地址和后台建立連接。
·Standard vs的端口永遠對外開放，無論后台是否有服務器在工作。
1.1.2 性能HTTP
·（首先與Pool member建立連接，再與客戶端建立）
· performance HTTP VS僅用於HTTP協議，使用Fast http profile，這是一個TCP、HTTP和oneconnect profile的組合，主要用於加快Http連接速度和減少后台Http server的連接數；
· 只緩存用於分析包頭的數據，沒有會話保持功能，不能處理SSL，HTTPS；
· BIG-IP通過到Pool Member的TCP連接建立一個空閑的服務器端Flow；
· 當有client請求來時，通過負載均衡算法選擇了此服務器，如果發現服務器端Flow是空閑的，則BIG-IP標識其為占用，並發送客戶端請求到選定的服務器；
1.1.3 Performance L4模式
· Performance L4 VS基於包到包處理連接，只負責客戶端連接的分配和轉發，默認不改變TCP連接中的任何參數。
· 客戶端和服務器自行協商TCP傳輸參數。
· Perforamce Layer 4 VS上只有4層的iRules可以使用（意思是這模式下，iRules只能改TCP，改不了http、https等）
· 默認狀態下，TCP新建連接的第一個包必須是SYN包，如果是其他的數據報比如ACK、RST等如果不在連接表中，則全部丟棄。
· 利用epva（enhance Packet velocity Acceleration）硬件加速模式，所以叫性能L4模式
1.1.4 Forwarding（IP）=路由模式
·只能使用Fast L4 Profile，translate-address 和translate-port翻譯默認為Disable；
· 按照連接處理，類似路由器，但不完全一樣，在Fast L4 Profile中開啟Loose Initial和Loose Close之后更為接近路由工作模式；
· 所有穿過forwarding YS的連接都將產生連接表
· 沒有Pool Member，轉發根據目標地址查找本地路由表完成
· 可以使用基於4層的iRules，比如做SNAT
· 無法利用ePVA
1.2 負載均衡策略
BIG-IP LTM進行四層負載均衡的最小元素為TCP連接，所有分配策略均以TCP連接為最小單位，而在七層負載均衡中，最小的元素為每一個完整的交易數據報包，如一個HTTP請求，因此以交易為最小單位進行分配。
負載分配策略主要包含以下幾種：
·靜態負載均衡算法：輪詢，比率，優先權
·動態負載均衡算法：最少連接數，最快響應速度，觀察方法，預測法，動態性能分配。
·可編程控制的負載均衡策略：通過編程控制應用流量的導向。
1.2.1.a 靜態負載均衡算法;輪詢
輪詢算法下，以每個客戶端新建連接為單位，客戶端連接輪流分配到后台的服務器上。
1.2.1.b 比率算法：比率算法
比率算法下，以每個客戶端新建連接為單位，將客戶端請求按照比率分配到后台的服務器上
1.2.1.c 優先權算法
在正常情況下，所有的客戶端請求全部發送到屬於高優先級組的member上；當最高優先級群組中的健康的服務器數量小於預定值時，BIG-IP LTM才將請求發送給次優先級的服務器組。
1.2.2.a 動態負載均衡算法：最少連接數
最小連接數為最常用的負載均衡算法之一，在后台服務器處理能力均等的情況下，使用最小的連接數可以得到最為平衡的負載均衡效果。（但是BIG-IP 要維護一張並發表，上面有各個服務器的並發參數）
1.2.2.b 動態負載均衡算法：動態性能分配
前提；BIG-IP知道服務器的CPU使用率（通過健康檢查）
動態性能分配通常用於一些服務器資源敏感應用，如集中計算、視頻點播等。動態算法是通過BIG-IP上的健康檢查來檢測服務器的資源占用率，新的請求被分配到資源占用最少的服務器。
1.3 如何選擇合適的負載均衡策略：
在大部分的應用場景中，都采用最小連接算法。如果系統的每秒新建連接數非常高，如果還是采用最小連接數，由於算法在計算時候不可能實時的統計后台服務器的連接數，且是有時間間隔的去進行統計。在這種情況下，可能采用輪詢算法可以更為有效的實現負載均衡。
------F5 BIG-IP LTM會話保持----------
連接和會話的區別：
會話的概念要廣泛一些，簡單的說，一個用戶登錄后，則產生一個session。而這個會話是由多次連接完成。BIG-IP LTM將一個會話里的多次連接認為是同一個用戶發起的，是為同一個用戶服務的。
BIG-IP LTM的概念中，一個session通常就是會話保持表中的一條記錄對應的所有連接。每個命中到這條記錄的連接都是屬於同一個session的。
2.1 為什么需要會話保持
會話保持是負載均衡設備的一種機制，用於識別客戶端與服務器之間交互過程的關連性，在進行負載均衡對的同時還保證一系列相關聯的訪問請求會保持分配到同一台服務器上。
針對不同的業務場景需要不同的會話保持配置，並不是所有業務系統都需要會話保持性。以HTTP電子商務應用為例，
在在線應用系統中需要進行用戶身份，一個客戶與服務器經常經過好幾次的交互過程才能完成一比較交易。由於這幾次交互過程是密切相關的，服務器在進行這些交互過程才能完成一筆交易。由於這幾次交互過程是密切相關的，服務器在進行這些交互過程的某一個交互步驟時，往往需要了解上一次交互過程的處理結果，或者上幾步的交互過程結果。這就要求所有這些相關的交互過程由一台服務器完成，而不能被負載均衡器分散到不同的服務器上，此時需要響應的會話保持策略來保證相關的請求始終被負載到后端的一台服務器上，
2.2 常見的會話保持
<1>源地址會話保持（source persistence）
<2>Cookie會話保持
HTTP Cookie insert（插入）
HTTP Cookie passive（被動）
HTTP Cookie Rewrite（重寫）
Cookie Hash
<3>SSL ID會話保持
<4>可編程控制的會話保持
將會話保持的特性的提取
將特征與后台服務器相對應
2.2.1 源地址會話保持:將一個源地址認為是一個用戶，凡是同一個源地址發過來的連接，則認為是同一個用戶發起的多個請求。根據會話保持策略，將這些連接/請求都轉發到同一個服務器上。（BIG-IP LTM會維護一張“源地址會話保持表”）
2.2.2 Cookie會話保持
關於HTTP Cookie和Session ID，以下面一個典型的HTTP請求流程
（圖）
通過HTTP流程圖看到Cookie有效的改進了HTTP協議的無狀態性，使原本無狀態的HTTP協議變成有狀態的應用協議。
Cookie的內容包括：名字，值，過期時間，路徑和域。
若不設置過期時間，則表示這個Cookie的生命期為瀏覽器會話期間，關閉瀏覽器就會消失。這種生命期為瀏覽器會話器的cookie被稱呼session cookie，一般不存儲在硬盤上而是保存在內存里。
若設置了過期時間，瀏覽器就會把cookie保存到硬盤上。
2.2.2.a HTTP Cookie insert（插入）
（服務器端並不寫入Cookie，HTTP響應不帶有cookie，所有cookie信息只存在負載均衡設備上）
2.2.2.b TTP Cookie passive（被動）
（服務器寫入cookie，HTTP響應里將帶有更新的會話保持cookie）
2.2.2.c HTTP Cookie Rewrite（重寫）
（進入服務器，服務器創建空白cookie，HTTP回復《帶有空白cookie》返回BIG-IP應用負載設備）
2.2.3 SSL ID會話保持（冷門）
在用戶基於SSL訪問系統環境里，當SSL對話首次建立時，用戶與服務器進行首次信息交換：
·交換機安全證書
·商議加密和壓縮方法
·為每條對話建立session ID
------F5 BIG-IP LTM健康檢查----------
3.健康檢查：
定義：一個健康檢查（Monitor）就是一個測試（test）
·特定的應用程序
·一個預期的回復
·在一定時間內
所有BIG-IP 共同特點：
·間隔：每個檢查的時間間隔
·超時時間；這個時間在BIG-IP 標記Node不可用之前返回成功的健康檢查結果。
F5 BIG-IP LTM可以使用符合Monitors，所以可使用多重健康檢查：
·可以使用全部或部分的健康檢查結果來標記成員的狀態
3.1.健康檢查有以下項目：
《1》基於icmp的健康檢查；
《2》基於TCP端口的健康檢查；
《3》基於UDP端口的健康檢查；
《4》基於應用協議的健康健康
3.1.1 基於icmp的健康檢查
原理：簡單的使用ping去探測，只要服務器有回應，則認為服務器正常工作；
（基於icmp的健康檢查屬於最基本的健康檢查方式）
3.1.2 基於TCP端口的健康檢查
原理：TCP健康檢查直接向member的服務器端口發起TCP連接建立請求，連接建立成功即表示服務器的服務在正常工作。
在頻繁檢查的情況下，健康檢查的流量肯呢個導致一些比較“脆弱”的應用系統產生故障。采用TCP half open的方式，或者采用基於代理的健康檢查；
3.1.3 基於UDP端口的健康檢查
原理：大多數的udp應用特點是在是收到錯誤的請求時，沒有任何響應。但UDP協議還是設計了在端口未開放時，默認系統將會回應一個Icmp unreachable數據包，以通知客戶端連接錯誤。（只能檢查端口情況，並不能代表真實的業務情況）
3.1.4 基於應用協議的健康健康
以HTPP協議為例，基於HTTP協議的健康檢查過程如下：（負荷較大，幾乎浮現業務）
《1》BIG-IP LTM發起一個HTTP請求到服務器，請求特定資源
《2》服務器進行回應；
《3》BIG-IP LTM在返回的內容中查找一個關鍵字，如果存在該關鍵字，則認為Web服務器正常工作。
3.2 關聯健康檢查
在真實的應用中，經常還可能存在有關連性應用。比如應用A是否能正常對外提供服務，還取決於它的下級服務應用B是否能給A提供需要的數據，而此時應用B不是在負載均衡的控制范圍之內。
3.3Monitor狀態報告
·狀態基於健康檢查響應及對象層次結構
虛擬服務virtural server 狀態受POOL狀態影響
pool狀態受pool members的狀態影響
一個pool的member受這個node的服務狀態的影響
·當健康檢查失敗會發生什么？
·如果沒有得到檢查結果，超時時間未到
-開始懷疑這個成員member
-沒有新連接到這個成員member
-現有連接被維持
·在達到了超時時間前有一個成功的檢查結果
新連接發送到member
·如果達到超時時間健康檢查失敗
從pool中移除member
現有連接清楚
3.4 Pool失敗機制
Fallback Host -- 最后備份的server（適用於HTTP和HTTPS profile應用）
·當pool members 成員低於活動成員設定（？？？？回HTTP 重定向(http 302) 到客戶端）？？？）
·Fallback host server設置是沒有健康監控的（備份server）
Priority Group Activation激活低優先組
------F5 BIG-IP LTM應用優化----------
4.BIG-IP LTM應用負載優化技術
主要用於提高和優化下面以下三種流量：
《1》TCP應用
《2》UDP應用
《3》HTTP應用（HTTP由於廣泛應用，單獨設置為一分支）
4.1 TCP應用：（列出常用profile）
4.1.1 TCP Clinet-side profile
目標：提高用戶體驗
4.1.2 TCP Server-Side profile
目標：服務器壓力卸載
F5已經內置了LAN、WAN和CELL優化的TCP profile配置。通過調整TCP profile多達70個選項；
通常情況下建議：Clinet side：推薦mptcp-mobile-optimized profile 配置模板
Server side：優先推薦tcp-wan-optimized profile
除非特別了解TCP的工作原理，否則不要調整idle timeout以外的任何參數
默認tcp profile所設置idle timeout值為300秒
4.1.3 oneconnect --TCP連接復用
實現連接聚合以降低服務器的TCP的連接總數，減少建立和關閉連接的消耗和延遲。
（圖）
工作范圍：
《1》前提使用VS Standard模式；
《2》oneconnect profile不是必須和HTTP Profile共用，也可以用於其他應用協議；
《3》但應用其他應用協議時須使用iRules編程來調用oneconnect
HTTP內容（忽略，附上PPT原件自己了解）
------F5 BIG-IP iRules介紹----------
5.1什么是iRules：
集成到TMOS架構的編程語言；
基於工業標准的Tool Command；
攔截、檢查，修改，引導及跟蹤進站和出站的應用流量；
5.2 VS和iRules關系
iRules的處理必須依賴於VS對流量的接收；
通過事件觸發機制，iRules可以控制流量在VS內部處理的整個過程