F5負(fù)載均衡器維護(hù)手冊范本

1、F5負(fù)載均衡器維護(hù)手冊目錄F5負(fù)瞬衡器維護(hù)手冊1一、基本原理41.1負(fù)載均衡器的基本原理41.2負(fù)載均衡器幾要素41 . 3 F5 BIG-IP LTM 基本元素51 . 4 BIG-IPLTM 的 TMM81 . 5 BIG-IP LTM的負(fù)瞬衡算法91 . 6 BIG-IP LTM寺101.6.1竊爲(wèi)寺的需求:101.6.2源地址會話保持:121.6.3 哈希3彳尉寺131.6.4 Cookie 3借寺131 . 7健康檢查151.7.1基于ICMP的健康檢查151.7.2基于TCP端口的健康檢查161.7.3基于應(yīng)用協(xié)議的健康檢查17二、F5 BIG-IP LTM 日常維護(hù)182 . 1

2、 F5 BIG-IP LTM 夕卜觀182 . 2 F5 BIG-IP LTM配置備份和恢復(fù)192 . 3 F5 BIG-IP LTM 性能狀態(tài)212 . 3 . 1 F5 BIG-IP LTM 實(shí)時連接狀態(tài)212.3.2 F5 BIG-IP LTM 性能狀態(tài)232.3.3 F5 BIG-IP LTM 告警日志26三、F5 BIG-IP LTM服務(wù)配置273 . 1 F5 BIG-IP LTM 創(chuàng)建用戶2732 F5 BIG-IP LTM開啟本地服務(wù)283.3手動切換主備狀態(tài)2834 修改 admin 和 root 密碼293.5健康檢查的管理和維護(hù)293 . 6pool的管理和維護(hù)313 .

3、 7VS的管理和纟鉀3338iRules管理和維護(hù)353 . 9rofile管理和維護(hù)38四、F5 BIG-IP LTM故障處理394 . 1應(yīng)用服務(wù)故障394.2F5 BIG-IP LTM 硬件故障41基本原理1.1負(fù)載均衡器的基本原理應(yīng)用負(fù)載均衡器對外提供一個虛擬的應(yīng)用服務(wù)器，接收所有的客戶端請求應(yīng)用負(fù)載均衡器通過負(fù)載均衡算法處理，將客戶端請求轉(zhuǎn)發(fā)到后臺的多個應(yīng)用實(shí)例應(yīng)用負(fù)載均衡器通過應(yīng)用健康檢查，準(zhǔn)確的判斷應(yīng)用程序的工作和服務(wù)狀態(tài)，一旦發(fā)現(xiàn)應(yīng)用不能提供服務(wù)，則將其從負(fù)載均衡組中摘除1.2負(fù)載均衡器幾要素員載分配策略:負(fù)載分配策略是應(yīng)用負(fù)載均衡的整個核心，如何對用戶的流星進(jìn)行分配，使后臺服

4、務(wù)器的處理更加合理。達(dá)到均衡負(fù)載，保證用戶的最佳體驗的目的”和負(fù)載分配策略具有密不可分的健康檢查策略:在一個良好設(shè)計的系統(tǒng)中，負(fù)載均衡器往往處于一個系統(tǒng)的核心位置，很多用戶使用四層負(fù) 載均衡的一個主要原因就是要實(shí)現(xiàn)應(yīng)用的高可用性而非性能問題。如何讓負(fù)載均衡器能智能 的檢查到服務(wù)器真實(shí)的健康狀態(tài)，在系統(tǒng)的設(shè)計中起到至關(guān)重要的作用。會話保持策略:就目前而言，只有很少的應(yīng)用系統(tǒng)是專為多服務(wù)器并行處理而設(shè)計，用戶的登錄信息， Session ID等還是在單臺服務(wù)器上存放,并沒有同步到其他的服務(wù)器上，因此,會話保持 策略的豐冨性也是四層負(fù)載均衡一個巨大的挑戰(zhàn)。冗余切換策略:在保證了后臺設(shè)備的高可用性之后

5、，岀于系統(tǒng)核心位置的負(fù)載均衡器自身的高可用性就變得 尤其重要，并且由于應(yīng)用訪問的不透明性，造成在緊急情況下很難對所有的應(yīng)用進(jìn)行遷移工 作。這時負(fù)載均衡器的冗余切換策略和手段將關(guān)系到整個系統(tǒng)的高可用性。網(wǎng)絡(luò)結(jié)構(gòu)的靈活性：對于一個橫跨網(wǎng)絡(luò)和應(yīng)用的設(shè)備來說，對于網(wǎng)絡(luò)結(jié)構(gòu)和應(yīng)用結(jié)構(gòu)的完整支持特性變得尤其重 要，網(wǎng)絡(luò)層的基本技術(shù)如VLAN、Trunk. Spanning. Tree、IPV4/V6、靜態(tài)路由、OSPF 等都將成為負(fù)載均衡器的基本配置。而另外對于應(yīng)用中的各種特殊協(xié)議的支持，也決走了負(fù) 載均衡器部署的圍和使用。13 F5 BIG-IP LTM基本元素在BIG-IP LTM中,針對應(yīng)用負(fù)勻衡的

6、應(yīng)用特色和系統(tǒng)需求，將整個流星的處理過程按照以下方式進(jìn)行走義:iRulesVS : Virtual Server是逬入BIG-IP LTM處理流量的入口。VS的走義包含了 IP和端口和 VLAN，其中，IP可以是一個IP ,也可以是用掩碼掩出來的一段IP ,端口可以是一個固定 的端口 ,比如80,也可以是0端口，0端口的意思就是偵聽所有的端口。VS的走義的含義 就是對于發(fā)送到BIG-IP LTM上的流呈，只有同時命中VS的IP和端口的流臺才進(jìn)行處理。Profile當(dāng)流星進(jìn)入BIG-IP LTM之后怎樣去處理和識別進(jìn)入VS的流量就需要由Profile 來定義了。Profile 分了幾種類型，有協(xié)

7、議層的 ProfileTCP profile, UDP profileo 有應(yīng)用層的 Profile 比如 HTTP profile ,FTP Profile。還有 SSL Profile、會話保持相關(guān)的 Profile. 認(rèn)證的Profile和其他一些Profile類型。所有的Profile都需要關(guān)聯(lián)在VS上才能生效。有 些Profile之間是互斥的關(guān)系上匕如TCP和UDR HTTP和FTP ,VS上關(guān)聯(lián)了 TCP profile , 就不能再關(guān)聯(lián)UDP Profile 了。因為一旦關(guān)聯(lián)了某個Profile , VS就會按照這個Profile的 走義方式去處理流呈。所以有些Profile也是

8、相互依存的，比如要關(guān)聯(lián)HTTP Profile ,就必 須先關(guān)聯(lián)TCP Profile.Pool: Pool在LTM的部是一個邏輯概念，是指的一組相同服務(wù)的資源的組合。Pool的作 用很簡單，就是根據(jù)自身走義的分發(fā)規(guī)則,對VS接收進(jìn)來，并且被Profile處理之后的流 呈進(jìn)行分發(fā)，分發(fā)到Pool的member去。Member:個應(yīng)用服勢,通常情況下，一個Member就是后臺服勢器的一個偵聽進(jìn)程， 是由IP：port格式組成。Node: Node通常用來表示后臺的一個服務(wù)IP地址，一個Node上面可以有一個或多個 Member. Node不需要進(jìn)行配置,在配置了 Member之后自動產(chǎn)生,系統(tǒng)會

9、根據(jù)每一個 不同的Member IP地址生成一個Node地址iRules : iRules相當(dāng)于在整個婁包通路上進(jìn)行一個雌和處理。vs -Pool-SNAT的這_條路上,iRules可以通過事件驅(qū)動方式f在通路上的田可一個位置上對數(shù)據(jù)包進(jìn)行判斷和 處理。比如ClienLAccepted事件就是當(dāng)請求命中VS的時候被激活，pool webpool這條 指令用于指示BIG-IP LTM將流呈分配那個Pool里面去。而iRules的事件是否能觸發(fā)或者iRules能獲取和處理那些信息貝睹0是由關(guān)聯(lián)的Profile來決走的。比如VS只關(guān)聯(lián)了 TCPProfile f而沒關(guān)聯(lián)HTTP Profile.那即

10、使通過VS的流星都是HTTP請求,iRules也無法 去獲取URI、header等信息。只有關(guān)聯(lián)了 HTTP Profile之后f iRules才能觸發(fā)HTTP相關(guān)事件和按照HTTP協(xié)議的相關(guān)規(guī)對請求容逬行識別和判斷。1 4 BIGIP LTM3TMMTMM禪砌TE冊渤羽。TMM 血DI畧、s莎部DT洲法sx幾y?it(時y聞凹旺m洲 siprovisions魚溼qlo聞)、口第 SSL 莒需珊甘亓君 HTTP 劇耳 詡盞也聶朋騎、滉Dp諾誦皿C1J3制洱ffiz持迪。汨yfflM BIGdP LTM 口st s第* 映莎汗彼sTMM 31脹 bgip |_tm 汨血#或 CPU 同、w炯3C

11、PU TMM 聲艸 ml f 塔血3第摩懈幾mTMM rawlffl 拆7卻舞必醱遼學(xué)、 fflBIGdp LTM LTMh-sss 廠 RamCach 卩 compress, SSL VPM WOM 無注跡SSB 砌m TMM 頭停ffls。刮膜 bbxBsH 亠-TTr鎏合 GTM(G_oba 一 Traffic Manager)，WA( Web Acce-erato 二 ASM(APP=cation security Manager)siAiR 僻膜程砌觀寺3毎 程qlffl. pcgin is TMM 倂了尹RamcacheCompressSSLOMoadTcy當(dāng)883瞎選貼 cpuu

12、 味洲浴甘皿選-cpu 誘fflsBGIP LTM 萌蘿 CMP(c_us(er Muti processgsznTrr游斗 F孟 CMP 鐸砌mBIGLP LTM n、B囲燼耳甘耳 HSR High Speed Bridge ) 口3第m頭倂qlN另卻姚進(jìn)薄 a個TMM核心上去。而每個TMM核匕占據(jù)一個CPU核客戶端客戶端客戶蝶客戶端1 . 5 BIG-IP LTM的負(fù)載均衡算法輪詢算法(Round Robin ):BIG-IP LTM順序循環(huán)I各請求一次J頃序循環(huán)t也連接每個服勢器。當(dāng)其中某個服勢器發(fā)生第2 到第7層的故障，則將其從順序循環(huán)隊列中拿出，不參加下一次的輪詢，直到其恢復(fù)正常。比

13、率算法(Ratio ):在BIG-IP LTM上給每個服務(wù)器分配一個加權(quán)值為比例，根據(jù)這個比例,BIG-IP LTM把用 戶的請求分配到每個服勢器。當(dāng)其中某個服勢器發(fā)生第2到第7層的故障，就把其從服勢 器隊列中拿出,不參加下一次的用戶請求的分配，直到具恢復(fù)正常。最少連接數(shù)(Least Connections ):在BIG-IP LTM上對每一臺服務(wù)器的當(dāng)前連接數(shù)進(jìn)行統(tǒng)計，當(dāng)有新的請求進(jìn)入時,將新的請求分配給當(dāng)前最少連接處理的服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第2到第7層的故障.BIG-IPLTM就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到具恢復(fù)正常。最快響應(yīng)速度（Fastest）:在

14、BIG-IP LTM上通過觀察每臺服勢器得應(yīng)用響應(yīng)速度,當(dāng)有新的請求進(jìn)入的時候，將新的請求分配給響應(yīng)最快的服勢器。當(dāng)其中某個服務(wù)器發(fā)生第2到第7層的故障，BIG-IP LTM就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直至懼恢復(fù)正常。觀察模式（Observed）:連接數(shù)目和響應(yīng)時間以這兩項的最佳平衡為依據(jù)為新的請求選擇服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7層的I, BIG/IP就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。性能預(yù)測分配：（Predictive ）由負(fù)載均衡設(shè)備收集到的應(yīng)用程序和應(yīng)用服勢器的各項性能參數(shù)如CPU占用率存占用率、 當(dāng)前并發(fā)用戶數(shù)

15、等關(guān)鍵信息，并可進(jìn)行加權(quán)處理。當(dāng)有新的請求進(jìn)入的時候,將新的請求分 配給綜合性能最佳的服務(wù)器。當(dāng)其中某個服勢器發(fā)生第2到第7層的故障，BIG-IP LTM就 把其從服務(wù)器隊列中拿出不參加下一次的用戶請求的分配,直到具恢復(fù)正常。16 BIG-IP LTM會話保持1 6 1會話保持的需求以最典型的http應(yīng)用為例在大多數(shù)電子商務(wù)的應(yīng)用系統(tǒng)或者需要進(jìn)行用戶身份認(rèn)證的在線系統(tǒng)中，一個客戶與服務(wù)器經(jīng)常經(jīng)過好幾次的交互過程才能完成一筆交易或者是一個 請求的完成。由于這幾次交互過程是密切相關(guān)的，服勢器在迸行這些交互過程的某一個交互 步驟時,往往需要了解上一次交互過程的處理結(jié)果,或者上幾步的交互過程結(jié)果,服務(wù)

16、器逬 行下一步操作時需要這就要求所有這些相關(guān)的交互過程都由一臺服務(wù)器完成，而不能被負(fù)載 均衡器分散到不同的服勢器上。個典型的http請求流程如下：保存 SessionlD客戶端在每次發(fā) 起對服務(wù)器的請 求的時候.都在 話求中發(fā)送包含 Session ID信息的 CookieHTTP Request: GET /index.jspII 產(chǎn)生SessionlDHTTP RESPONSE: index.jspcookie： Jsessionid:234234234HTTP Request: GET /info.jspCookie： J$es$ionid:234234234再產(chǎn)生SessionlD后，

17、服務(wù)器則通HTTP RESPONSE: Info.jspilSessionlD的值cookie： Jsessionid:234234234_來區(qū)別每一個用戶端HTTP Request: GET /detail.jspICookie： Jsessionid:234234234客戶端瀏覽器服務(wù)器應(yīng)用實(shí)例客戶端發(fā)起一個連接到服務(wù)器的服務(wù)端口 ,并在此連接中發(fā)送HTTP請求服勢器在接收到用戶請求后，在本地產(chǎn)生一個部SessionlD用于唯一標(biāo)識該用戶服務(wù)器將返回容進(jìn)行組織后，同時將Session ID通過Cookie返回給用戶用戶在收到回應(yīng)后，將Cookie保存在存中。用戶下一次點(diǎn)擊重新發(fā)起一個連接到

18、服務(wù)器的服務(wù)端口用戶在新建連接中發(fā)送HTTP請求,并帶上Cookie進(jìn)行發(fā)送。服勢器在收到請求后,從Cookie中獲得該用戶的Session ID,根據(jù)此Session ID進(jìn)行相關(guān)處理1.6.2源地址會話保持:源地址會話保持的一個基本概念就是將一個源地址認(rèn)為是一個用戶，凡是同一個源地發(fā) 送過來的連接，則認(rèn)為是同一個用戶發(fā)起的多個請求,根據(jù)會話保持策略，將這些連接/請 求都轉(zhuǎn)發(fā)到同一臺服務(wù)器。當(dāng)一個新的連接請求發(fā)送到虛擬服務(wù)后，首先查找源地址會話保持表，如果在源t也址會 話保持表中查詢到了該請求發(fā)起的源地址7寸應(yīng)的服務(wù)器，則直接將該請求轉(zhuǎn)發(fā)到相應(yīng)的服勢 器上，如果在源地址會話保持表中沒有查詢到

19、相應(yīng)的條且，則按照負(fù)載均衡算法將請求轉(zhuǎn)發(fā) 到相應(yīng)的服務(wù)器，同時，將該請求發(fā)起的源地址和對應(yīng)的服務(wù)器地址添加到源地址會話保持 表中。這樣,下次同_ IP地址再發(fā)起新建連接到該虛擬服務(wù)時,則在源地址會話保持表中 已經(jīng)存在相應(yīng)的條目，新的連接則會根據(jù)源地址會話保持表的對應(yīng)項轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)器上。源地址會話保持同時還存在有一個超時時間參數(shù)。每次有有新建連接請求或已建立的連接中有在傳輸時,就會刷新會話保持表中的超時時間。比如設(shè)置源IP會話保持的超時 時間為300秒f則對于同一個源IP ,只要有親斤建連接或已建連接有數(shù)據(jù)傳輸，則在源地址傳輸時，該值就開始按秒會話保持表中的超時時間一直刷新為0。當(dāng)沒有新建連

20、接或者婁旦超出300秒沒有新建連接請求或沒有:傳輸。則將其條目從源地址會話保持表中清除。如果該IP地址在在過了超時時間之后又有新的連接請求，則以第一次連接 請求按照負(fù)載均衡的算法進(jìn)行處理，此時,源地址會話保持表中的超時時間又從0開始計1*6.3哈希會話保持哈希會話保持的一個基本概念就是將一個連接中的源IP和目的IP地址逬行Hash計算, 根據(jù)計算得至啲結(jié)果并根據(jù)后臺存在多少臺服務(wù)器來選擇將請求分配到那臺服務(wù)器。哈希會話保持的持點(diǎn)是在后臺服務(wù)器的健康狀態(tài)不發(fā)生改變的時候，每個特走的源IP 地址被分配到的服務(wù)器是固走的。并且,哈希會話保持可以沒有會話保持表,而僅僅是根據(jù) 計算的結(jié)果來確走一個源IP

21、被分配到那臺服勢器。哈希會話保持通常被用于一些特走場合，如要求客戶端按照IP地址被固定分配的場合， 或者在一些會話保持表查詢的開銷已經(jīng)遠(yuǎn)遠(yuǎn)大于Hash計算開銷的情況下,采用hash會話 保J寺可城高系統(tǒng)的處理能力和響應(yīng)速度。在實(shí)際的應(yīng)用場景中，針對后臺采用Cache服務(wù)器的情況,還有對URL逬行Hash的 處理方式，將同一個URL的請求分配到同一臺Cache服勢器,這樣,對后臺的Cache服 務(wù)器群組來說每臺Cache服務(wù)器上存放的容都是不一樣的提高Cache服務(wù)器的利用率。1.6.4 Cookie會話保持.Cookie是在瀏覽器訪問WEB服勢器的某個資源時，由WEB服務(wù)器在HTTP響應(yīng)消息

22、頭中附帶傳送給瀏覽器的一片數(shù)據(jù),WEB服務(wù)器傳送給各個客戶端瀏覽器的數(shù)據(jù)是可以各 不相同的。瀏覽器可以決走是否保存這片數(shù)據(jù),旦WEB瀏覽器保存了這片數(shù)據(jù),那么它 在以后每次訪問該WEB服務(wù)器時 都應(yīng)在HTTP請求頭中將這片數(shù)據(jù)回傳給WEB服務(wù)器。顯然,Cookie最先是由WEB服務(wù)器發(fā)出的是否發(fā)送Cookie和發(fā)送的Cookie的具體容，完全是由WEB服務(wù)器決定的。例如r用一個Cookie來標(biāo)識訪問者的，有效時間等。Cookie Insert會話保持模式因為Cookie被如此廣泛的使用，特別是Session Cookie技術(shù)r基本上在所有的電子商務(wù)中都在使用這種技術(shù)。因此,在BIG-IP LT

23、M中可以通過插入自己可識別的Cookie來實(shí)現(xiàn)會話保持?？蛻艉?求.SWCookie在股務(wù)器響應(yīng)中瓶入特定Cookie客戶如請*.包含特定CgS衽展務(wù)郵 應(yīng)中更 彌定Coo血容戶端殳處蘭點(diǎn)sfe旬欽城h 算鉉分配根據(jù)Cookie內(nèi)容分配負(fù)載均衡轉(zhuǎn)發(fā)不色含Cookk的請求廢務(wù)答響應(yīng).沒有Cookie丿I?務(wù)25響應(yīng)，沒有Cookie服務(wù)器當(dāng)客戶進(jìn)行第一次請求時，客戶HTTP請求（不帶cookie ）進(jìn)入BIG-IP LTM , BIG-IP LTM根據(jù)負(fù)載均衡算法策略選擇后端一臺服務(wù)器,并將請求發(fā)送至該服務(wù)器，后端服務(wù)器 進(jìn)行HTTP回復(fù)（不帶cookie ）被發(fā)回BIG-IP LTM ,然后B

24、IG-IP LTM插入cookie ,將 HTTP回復(fù)返回到客戶端。當(dāng)客戶請求再次發(fā)生時，客戶HTTP請求（帶有上次BIG-IP LTM 插入的cookie ）進(jìn)入BIG-IP LTM ,然后BIG-IP LTM讀出cookie里的會話保持?jǐn)?shù)值，將 HTTP請求（帶有與上面同樣的cookie ）發(fā)到指走的服務(wù)器,然后后端服務(wù)器逬行請求回 復(fù),由于服勢器并不寫入cookie , HTTP響應(yīng)將不帶有cookie ,服務(wù)器響應(yīng)再次經(jīng)過逬入BIG-IP LTM時r BIG-IP LTM再次寫入更新后的會話保持cookie。健康檢查是負(fù)載均衡處理中一個非常重要的壞節(jié)。負(fù)載均衡的主要作用就是將客戶端的

25、請求分配到多臺服務(wù)器上,如果沒有健康檢查，在后臺服務(wù)器發(fā)生故噫的時候，部分的客戶 端將會被分配到故隱的服務(wù)器上，從而導(dǎo)致用戶的訪問失敗。在一些情況下，甚至可能出現(xiàn) 服務(wù)器本身還在工作，但其上運(yùn)行的應(yīng)用系統(tǒng)已經(jīng)故嚏導(dǎo)致無法處理請求，都將會導(dǎo)致用戶 的請求失敗。在BIG-IP LTM上應(yīng)當(dāng)能檢查至I這些故瞳,并在進(jìn)行負(fù)載均衡的時候?qū)⑦@些故 障的服務(wù)器逬行自動摘除，保證應(yīng)用的持續(xù)性和高可用性。1.7.1基于ICMP的健康檢查基于ICMP的健康檢查屬于最基本的健康檢查方式，BIG-IP LTM主動給服勢器發(fā)送一 個ICMP（互聯(lián)網(wǎng)控制信息協(xié)議）數(shù)據(jù)包,如果BIG-IP LTM收到了服務(wù)器的正確響應(yīng)，則

26、說 明檢查成功。ICMP健康檢查通常用于網(wǎng)關(guān)類型設(shè)備的健康檢查，如防火墻、路由器等。這些設(shè)備通 常不提供其他的健康檢查手段，因此ICMP屬于最1圭的檢查方式。另外,在一些無:去使用高 級健康檢查手段的情況下,也只能使用ICMP健康檢查手段。ICMP健康檢查方式簡 單的使用ping去探測 服務(wù)器的狀態(tài)，只要 服務(wù)器回應(yīng)ICMP譴求, 則認(rèn)為服務(wù)器在正営 工作1.7.2基于TCP端口的健康檢查在基于TCP協(xié)議的應(yīng)用中，每個應(yīng)用系統(tǒng)都會綁走一個TCP端口，應(yīng)用通過偵聽這個端口接受客戶端的請求。比如我們常見的80端口在默認(rèn)情況下就是服務(wù)于HTTP服務(wù)r通 常為HS、Apache等應(yīng)用系統(tǒng)使用，另外還有

27、FTP( 20、21 HTTPS( 443 SMTP( 25 POP3 ( 110 )等。判斷這些應(yīng)用系統(tǒng)是否在工作最簡單的方法就是從BIG-IP LTM和對應(yīng) 的服務(wù)器端口做一次完整的TCP握手，如果TCP握手成功,則認(rèn)為服務(wù)器正常工作,如果 握手失敗，在超過一走的檢查次數(shù)均握手失敗的情況下,BIG-IP LTM則將失敗的服務(wù)器標(biāo) 記為Down ,而將新的客戶端請求都發(fā)送到其他仍然正常工作的服務(wù)器上。在TCP健康檢查中還可能出現(xiàn)的一種情況就是在頻繁檢查的情況下,健康檢查的流臺 可能導(dǎo)致一些匕匕較脆弱的應(yīng)用系統(tǒng)產(chǎn)生故障。通常有兩種情況會出現(xiàn)這種故障情況：1. 服務(wù)器的Socket偵聽程序不完善

28、,對于TCP健康檢查沒有正確關(guān)閉連接2. 服務(wù)器對每個試圖連接都進(jìn)行l(wèi)og ,最后整個應(yīng)用系統(tǒng)的Log都被健康檢查的連接所充 滿。而導(dǎo)致磁盤空間溢出或者正常的log信息無法察看。在這種情況下，有兩種解決方式：1. 采用TCP half open的方式進(jìn)行健康檢查，所謂TCP half open就是BIG-IP LTM向服務(wù)器發(fā)送一個Syn t旦受到來自該服務(wù)的Syn-ACK數(shù)據(jù)包，則認(rèn)為該服務(wù)正常工作，然后立即發(fā)送一個RESET數(shù)據(jù)包到服務(wù)。在一些情況下，這種TCP半連接模式并不會 被記錄下來。2. 采用基于代理的健康檢查r即在服勢器上另外編寫一個逬程，專門用于健康檢查使用，專用的健康檢查進(jìn)程

29、將會負(fù)責(zé)BIG-IP LTM的健康查詢,而保護(hù)主逬程的不受干擾的運(yùn)行。1.7.3基于應(yīng)用協(xié)議的健康檢查由于在ICMP、TCP端口和UDP端口的健康檢查中，我們都不一走能確認(rèn)服務(wù)器的真 實(shí)工作狀態(tài)。在實(shí)際中經(jīng)常有可能出現(xiàn)這樣的情況：服勢器IP地址還可以ping，但是應(yīng)用服務(wù)已經(jīng)crash 了應(yīng)用服務(wù)還在監(jiān)聽80端口，但是已經(jīng)不接收任何請求了應(yīng)用服務(wù)仍然接收請求，但是每次都返回503服勢器部錯誤這種服務(wù)已經(jīng)不正常，但是端口仍在監(jiān)聽的情況,在一些非關(guān)鍵業(yè)務(wù)上還可以容忍，但 在一些關(guān)鍵業(yè)勢的應(yīng)用中就不可接受了。以HTTP協(xié)議為例，基于HTTP協(xié)議的健康檢查過程如下：BIG-IP LTM發(fā)起一個HTTP

30、請求到服務(wù)器，請求特走的資源服勢器進(jìn)行回應(yīng)BIG-IP LTM在返回的容中查找一個關(guān)鍵字，如果存在該關(guān)鍵字,則認(rèn)為Web服務(wù)器 正常工作中。HTTP協(xié)議層的健康檢查通常用于應(yīng)用服務(wù)器的健康檢查，如WebLogic、WebSphare.Tomcat等。和IIS、Apache服勢相比,這些應(yīng)用服務(wù)器出現(xiàn)故障的幾率通常較大。而且最 容易出現(xiàn)端口仍然在偵聽，但應(yīng)用已經(jīng)不工作的情況。典型的基于應(yīng)用協(xié)議的健康檢查通常還有：FTP:由BIG-IP LTM向FTP服務(wù)器發(fā)起FTP請求，在驗證用戶名和密碼后，下載一個文件 （通常不會保存這個文件）,如果文件下載成功,則認(rèn)為服務(wù)器工作正常。這樣整個FTP服 務(wù)器的

31、用戶認(rèn)證、磁盤存儲連接等服務(wù)都進(jìn)行了檢查。DNS:由BIG-IP LTM向DNS服務(wù)器發(fā)起一個DNS請求#請求特定的域名,并檢查返回的結(jié)果，如果正確則認(rèn)為服務(wù)器工作正常。HTTPS:由BIG-IP LTM向HTTPS發(fā)起一個HTTPS請求，通常，在HTTPS的健康檢查中 可能還需要配置客戶端證書等,在服勢器響應(yīng)返回后，在返回的數(shù)據(jù)中查找特走的字符串, 如果匹配成功，則認(rèn)為HTTPS服務(wù)器工作正常。POP3 :由BIG-IP LTM向POP3服務(wù)器發(fā)起一個請求f并進(jìn)行用戶名和密碼驗證。如果登 陸成功r則認(rèn)為POP3服務(wù)器工作正常。SMTP :由BIG-IP LTM向SMTP服務(wù)器發(fā)送一個標(biāo)準(zhǔn)的S

32、MTP請求，如果服務(wù)器按照標(biāo)準(zhǔn)SMTP響應(yīng)返回HELO或QUIT ,則認(rèn)為SMTP服務(wù)工作正常。通常情況下，SMTP健康檢 查在發(fā)送請求的時候還需要指走域名。庫查詢請求，然后判斷數(shù)據(jù)庫服務(wù)器數(shù)據(jù)庫：由BIG-IP LTM向數(shù)據(jù)庫服勢器發(fā)起一次1返回的結(jié)果中是否包含特走的字符串，如果匹配成功，則認(rèn)為數(shù)據(jù)庫服務(wù)器工作正常。二F5BIGJPLTM日常維護(hù)2 1 F5 BIG-IP LTM 外觀F5在設(shè)備前面板上劃分明顯不同的三個區(qū)域 最左側(cè)設(shè)計有failover和console接口 ； 中部為各種網(wǎng)絡(luò)接口 ；最右側(cè)為液晶屏幕、狀態(tài)顯示燈、6個控制按鈕及F5的紅色logo 燈泡。面板前部設(shè)計有冷風(fēng)入口

33、。電源設(shè)計在設(shè)備的尾部以方便機(jī)架上電源線接入，設(shè)備產(chǎn) 生的熱星從尾部的熱風(fēng)出口散出。9診冬二匚估1.WI1 口 2.USB接口 3Console 口 4.Failover 口 5.10/100/1000 自甌接口 6.SFP接口 7指示燈8液晶屏9 液晶屏控制按鈕1 電源模塊一2電源模塊二3散熱風(fēng)扇通過LCD按鍵修改管理網(wǎng)口 IP地址的方法如下：1. 按紅色X按鍵進(jìn)入O ptions選項；2. 在液晶面板上通過按鍵按以下順序設(shè)置管理網(wǎng)口的網(wǎng)絡(luò)地址：Options-System-IP Address/Netmask-Commit22 F5 BIG-IP LTM配置備份和恢復(fù)可以通過以下WEB界面

34、逬行配置的備份與修改： 進(jìn)入 System?Archives ,點(diǎn)擊 Create :System Archfvee Mew Archive.Operation StatusGeiiei J Pi opcticsI File M?neZ.HZ-P5-MMS3-9A0120060525“.1Saving actconTigurjation.B-cryptionDisabted vPrivate KeysI Iviucfe V IVcrscnBO-P 9.2.3 Buid 34.3Cancel | Fhisfed |配置備份好后，點(diǎn)擊設(shè)配置文件并下載到夕卜部電腦上:System Atchivev

35、ZJHZ4S MMSJ SWM.2W0425.ucGeikm .il Profertic5Fie MsmeZJHZ-PS-MMS3 Wl J0L60525JX&Yerslan94P9 2.3Bul(i34 3EnciyptodDoteSEONoThuMw2S2O:l3.2CCSr 2306195KI0W6SArchive FifeDovAibad NHZP5MWS匸SVW仁200旳525 uw恢復(fù)系統(tǒng)時點(diǎn)擊Restore如果是需要一個完全干凈的系統(tǒng)，建議通過重裝系統(tǒng)來恢復(fù)到出廠設(shè)置。如果沒辦法重 裝系統(tǒng)，但需要將配置清空以重新逬行配置，方法如下：從管理網(wǎng)口用命令行登陸B(tài)IG-IP ,然后執(zhí)行以

36、下命令：#b db all reset#b reset#b save#b base reset#b base save23 F5 BIG-IP LTM性能狀態(tài)2.3.1 F5 BIG-IP LTM實(shí)時連接狀態(tài)在命令行模式輸入：b conntrootinh-2:Activej config * b conn35 :4560 35:4564 35:4566 134.72,135.122:1260 134.72.135.I22SL282 22:1284 22:1286134.74.

37、127.70:4332 0:7081 :7081 0:4338 13.W.105.90：70KL :7081 0:4340 134.64.105. 0:70&1 134.64.2 09.5:7081 46:2058 0:7081 134.64. ?09. 5:7081 :1210 0:7081 :7082 28:54524 134.64.1

38、0 5.90:7081 :7082 25:41566 any: 154.64.2 0.247:80019:4254 134.64.90:7031 134.W.209.5 :134.4.1Q5.12 5：2132e any:any 134.-54.209.201:8 1cmp 30:4387 2 ：hdp ：hltp lB35:hylafax 0:7081 :7082 134.64.10S.9

39、0：7081 :7082 154.7&.1Q5.235H563 131.105.90： 7Q81 134.54.209. b： 708235:4565 0:7081 :7082 25:22288 any:any 01:8 18:2172124.7D.231.U.8：2173 134.70.2 31.118:2177 18:2178 134.7Q.231.118：2179 18:21

40、80 18:2181 18:2182 18:2183 25:62747 22:1281 :134；76*105；235：4?61 查看當(dāng)前端口的狀態(tài)g * b conn0：/Q810:70810:70810:70810:70810:70810:7081134. 4.209.:7082 :

41、7082 :7082134 64.209.6:7082134.64.209.b：70S2 :7082 l?4.f4.209.6:7082tcpnv 工一_1364.102.22:httpL34.64.1Q2.22：hT：Tp 2:http2:hrtpL34.b4.102.22：htTp 1346420222：hUtp 2:http 2:http 2 ：htTpany:any 21:813464.105.QD:

42、7081 :7082 I 4.4, O1*. h :ncrtip：http ：hTTp :http :hrtp 134.e4.1Q2.b：hTTp 134.e4.102.6：hTLp :http :http 134.&4.1Q2.：hTXp 1cmpgTCP tup TCP TCP tcp tcp tcp tcp tcpTCPTCP KPTCP tcPTCP TCP TCPtcpUP DM DNJ UP UP UP UPLrootSn

43、n- iritprface10.0CG8.60Gt runktrunk-1 t rurik-1errorst12 3 412 q2.2.2 :Activel speed Mb/S FD FD FD FD FD FD FD1000100010001000100010001000config 半 b 彳 pkts pkts 1n out02 721 101510 8 12 0 0435G 5.872G 70.3M 874 訥rrterrace pkts drop 0 0 0165 8M 7811.15H 8952showpkts coll0000000bits 1n 210.9M 5672 0 2

44、&.37T 688.9G 51.52Tbits out 80.11M 7660 0 22.931 716.9G 4 9.79T 45.17T00O0000查看當(dāng)前node信息rootnh-2:Active config 冷 b node shwnode unchecked session nableI (cur. max. liirit. toxj - (Q. 57. Q. 3762)(:pkT5.bit5)1n (18978, 11.79M), OUT - (5085, 12.21M) I requests (totals - 0NODE 0?

45、uncheckedsessicn enableCcur, max, Inirit, tot) = (0, 63, 0t 465) (pkTstbnt5)in = (2712, 3.5BSM), out = (24 31, requests (total) = 0NODS unchecked session enablecur. rnax5 limit, tot) = 127, 1192. 0. dl. 77w) pkis,b1ts) 1n - G2何9 5 78.2G). uul - (371.3M. 2.948T) requests Ctotal) - 0node 1

46、4.102. unchecked session cnablaI (CUr. max. lU1t. TOT) - (160. 720, 0. 41.59M)CpkTS.biTS) 1n (399.3M, 5 84 66), OUT -(373 71% 2.956T) I requests (total) - 0NODE 1S4.t4.102.7unchecked session enableCcur, max, limit, tot) = (146, 81 f 0, 41.30lx) (pkrs.bits) in = (3W.SM, S73.1G), out = (369.3m, 2.935T

47、 requests (total) = 0NODE 1S unchecked session enable(cur. max, limit. lot) = (141, 727. 0. dl.53m) 1, 577. 9g), out (3 九 5叫 2.941T) requests Ctotal) - 0NODE 134.t4.102.9 unchecked session enableI (cur, maxr limit, tot) - (214, e41. 0. 41.33M) (pkT5.bit5)1n (390 9Mt 566.86), OUT - (366. W,

48、 2.898T)I requests (totals - 0NODE 0 unchecked session enableCcur, max, limit, rot) = (183, ?2?f 0, 41.S4M) (pkts.bits) in = (402.6M, 595.1G), out = (387.3M, 2.992T) requests (total) = 0查看pool狀態(tài)roottih-2:Actnve corifig * b pool showPOOL CPMIS_POOL LB KETHOD round robin MIN/CUR ACTIVE WEWB

49、SP.S 0/2I (cur, max, litfilT, tot)(335, 2650, 0, 134.9M) (pkTs,bnts) th = (S.934G, 12.S6TJ, our = C7.9S5G, 6$.1ST) + - PL MEMBER CPMIS_POOL/134 64 209 5 ；081 active.Up session enabled priorlry 1 ratio 1(cur, niax. limit, tot) = 06. 926. 0, 67.ISM)(pkts.bits) In - (2.047G. 6.118TJ. Out C3.955G. 32.4O

50、T) requests (total) - 675.3J4+ - 9RL r PL MEH SEP. k2cl i ent_pool /134 64 20S 201:S2S2 inactive, down session enabled priority 1 ratio 1 (cur, max, liirit, tot)(0, 79, O, 2.12 5M) (pkts,b-its) in = (14.8, 16.56G). out = 1O.85M, 13.14G) requests Ciotdl?! - 0+ MEMBER k2elient_poo1/134.64.10S. 202:S2S

51、2 active,up session enabledpriority 1 ratio 1(cur r max, limit r tot) 60r 101, 0, 5.103) (pkts,bits) % 二(3S.8CC-, 39.8SG), out = Q6.0QM, 31.665) requests (total) - 0pool kzserver-pool lb method round roWn min/cijr active mgmqers 0/2 Ccur, max, litnir, tot) = (0, SO, 0. ?. 262M) fpkxs.blts) 1ri - (72

52、.73M. &92g) OUT - (65.65m. POOL MEMBER k2server_poo1/01:5555 active,Up session enabled卩riority 1 ratio 1(cur, nux llmli. ica) - 0, 16. 0. 2.11Coij (pfcts ,bits) 1n 二(31.16W, 40&了G), out = C?8. 21M, 25.13G) requests (total) = 0FWL MEMBER k2server.-poo1/02:5555 acx1ve,up session enabled priority 1 ratio 1 (cur, nux limit tot) = 0 M4. 0. 4.152M) (pkT5tb-lT5)1n (41, 57TK, 48.24G), OUt (37.43M, 40.293) requests Totall = 0查看當(dāng)前vs信息0/1UNIT 1ARP enablePJA accel er axion nonerequest5 (total) = 684.2MARP enable4prioriratio 1rootnh-2:Act 1ve