F負(fù)載均衡器維護(hù)手冊

F5負(fù)載均衡器維護(hù)手冊目錄F5負(fù)載均衡器維護(hù)手冊 1一、基本原理 41．1負(fù)載均衡器的基本原理 41．2負(fù)載均衡器幾要素 41．3F5BIG-IPLTM基本元素 51．4BIG-IPLTM的TMM 81．5BIG-IPLTM的負(fù)載均衡算法 91．6BIG-IPLTM會話保持 101．6．1會話保持的需求： 101．6．2源地址會話保持： 121．6．3哈希會話保持 131．6．4Cookie會話保持. 131．7健康檢查 151．7．1基于ICMP的健康檢查 151．7．2基于TCP端口的健康檢查 161．7．3基于應(yīng)用協(xié)議的健康檢查 17二、F5BIG-IPLTM日常維護(hù) 192．1F5BIG-IPLTM外觀 192．2F5BIG-IPLTM配置備份和恢復(fù) 202．3F5BIG-IPLTM性能狀態(tài) 212．3．1F5BIG-IPLTM實(shí)時(shí)連接狀態(tài) 212．3．2F5BIG-IPLTM性能狀態(tài) 242．3．3F5BIG-IPLTM告警日志 26三、F5BIG-IPLTM服務(wù)配置 273．1F5BIG-IPLTM創(chuàng)建用戶 273．2F5BIG-IPLTM開啟本地服務(wù) 283．3手動(dòng)切換主備狀態(tài) 293．4修改admin和root密碼 293．5健康檢查的管理和維護(hù) 303．6pool的管理和維護(hù) 323．7VS的管理和維護(hù) 343．8iRules管理和維護(hù) 363．9rofile管理和維護(hù) 39四、F5BIG-IPLTM故障處理 404．1應(yīng)用服務(wù)故障 404．2F5BIG-IPLTM硬件故障 42一、基本原理1．1負(fù)載均衡器的基本原理應(yīng)用負(fù)載均衡器對外提供一個(gè)虛擬的應(yīng)用服務(wù)器，接收所有的客戶端請求應(yīng)用負(fù)載均衡器通過負(fù)載均衡算法處理，將客戶端請求轉(zhuǎn)發(fā)到后臺的多個(gè)應(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ù)載分配策略：負(fù)載分配策略是應(yīng)用負(fù)載均衡的整個(gè)核心，如何對用戶的流量進(jìn)行分配，使后臺服務(wù)器的處理更加合理。達(dá)到均衡負(fù)載，保證用戶的最佳體驗(yàn)的目的，和負(fù)載分配策略具有密不可分的關(guān)系。健康檢查策略：在一個(gè)良好設(shè)計(jì)的系統(tǒng)中，負(fù)載均衡器往往處于一個(gè)系統(tǒng)的核心位置，很多用戶使用四層負(fù)載均衡的一個(gè)主要原因就是要實(shí)現(xiàn)應(yīng)用的高可用性而非性能問題。如何讓負(fù)載均衡器能智能的檢查到服務(wù)器真實(shí)的健康狀態(tài)，在系統(tǒng)的設(shè)計(jì)中起到至關(guān)重要的作用。會話保持策略：就目前而言，只有很少的應(yīng)用系統(tǒng)是專為多服務(wù)器并行處理而設(shè)計(jì)，用戶的登錄信息，SessionID等還是在單臺服務(wù)器上存放，并沒有同步到其他的服務(wù)器上，因此，會話保持策略的豐富性也是四層負(fù)載均衡一個(gè)巨大的挑戰(zhàn)。冗余切換策略：在保證了后臺設(shè)備的高可用性之后，出于系統(tǒng)核心位置的負(fù)載均衡器自身的高可用性就變得尤其重要，并且由于應(yīng)用訪問的不透明性，造成在緊急情況下很難對所有的應(yīng)用進(jìn)行遷移工作。這時(shí)負(fù)載均衡器的冗余切換策略和手段將關(guān)系到整個(gè)系統(tǒng)的高可用性。網(wǎng)絡(luò)結(jié)構(gòu)的靈活性：對于一個(gè)橫跨網(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ù)載均衡器部署的范圍和使用。1．3F5BIG-IPLTM基本元素在BIG-IPLTM中，針對應(yīng)用負(fù)載均衡的應(yīng)用特色和系統(tǒng)需求，將整個(gè)流量的處理過程按照以下方式進(jìn)行定義：VS：VirtualServer是進(jìn)入BIG-IPLTM處理流量的入口。VS的定義包含了IP和端口和VLAN，其中，IP可以是一個(gè)IP，也可以是用掩碼掩出來的一段IP，端口可以是一個(gè)固定的端口，比如80，也可以是0端口，0端口的意思就是偵聽所有的端口。VS的定義的含義就是對于發(fā)送到BIG-IPLTM上的流量，只有同時(shí)命中VS的IP和端口的流量才進(jìn)行處理。Profile：當(dāng)流量進(jìn)入BIG-IPLTM之后，怎樣去處理和識別進(jìn)入VS的流量，就需要由Profile來定義了。Profile分了幾種類型，有協(xié)議層的Profile比如TCPprofile,UDPprofile。有應(yīng)用層的Profile比如HTTPprofile，F(xiàn)TPProfile。還有SSLProfile、會話保持相關(guān)的Profile、認(rèn)證的Profile和其他一些Profile類型。所有的Profile都需要關(guān)聯(lián)在VS上才能生效。有些Profile之間是互斥的關(guān)系，比如TCP和UDP,HTTP和FTP，VS上關(guān)聯(lián)了TCPprofile，就不能再關(guān)聯(lián)UDPProfile了。因?yàn)橐坏╆P(guān)聯(lián)了某個(gè)Profile，VS就會按照這個(gè)Profile的定義方式去處理流量。所以有些Profile也是相互依存的，比如要關(guān)聯(lián)HTTPProfile，就必須先關(guān)聯(lián)TCPProfile。Pool：Pool在LTM的內(nèi)部是一個(gè)邏輯概念，是指的一組相同服務(wù)的資源的組合。Pool的作用很簡單，就是根據(jù)自身定義的分發(fā)規(guī)則，對VS接收進(jìn)來，并且被Profile處理之后的流量進(jìn)行分發(fā)，分發(fā)到Pool內(nèi)的member去。Member:一個(gè)應(yīng)用服務(wù)，通常情況下，一個(gè)Member就是后臺服務(wù)器的一個(gè)偵聽進(jìn)程，是由IP:port格式組成。Node:Node通常用來表示后臺的一個(gè)服務(wù)IP地址，一個(gè)Node上面可以有一個(gè)或多個(gè)Member。Node不需要進(jìn)行配置，在配置了Member之后自動(dòng)產(chǎn)生，系統(tǒng)會根據(jù)每一個(gè)不同的MemberIP地址生成一個(gè)Node地址iRules：iRules相當(dāng)于在整個(gè)數(shù)據(jù)包通路上進(jìn)行一個(gè)監(jiān)控和處理。VS-Pool-SNAT的這一條路上，iRules可以通過事件驅(qū)動(dòng)方式，在通路上的任何一個(gè)位置上對數(shù)據(jù)包進(jìn)行判斷和處理。比如Client_Accepted事件就是當(dāng)請求命中VS的時(shí)候被激活，poolwebpool這條指令用于指示BIG-IPLTM將流量分配到那個(gè)Pool里面去。而iRules的事件是否能觸發(fā)或者iRules能獲取和處理那些信息，則都是由關(guān)聯(lián)的Profile來決定的。比如VS只關(guān)聯(lián)了TCPProfile，而沒關(guān)聯(lián)HTTPProfile。那即使通過VS的流量都是HTTP請求，iRules也無法去獲取URI、header等信息。只有關(guān)聯(lián)了HTTPProfile之后，iRules才能觸發(fā)HTTP相關(guān)事件和按照HTTP協(xié)議的相關(guān)規(guī)范對請求內(nèi)容進(jìn)行識別和判斷。1．4BIG-IPLTM的TMMTMM就是一個(gè)應(yīng)用程序。TMM一旦啟動(dòng)，就會搶占系統(tǒng)的大部分內(nèi)存(內(nèi)存分配可以在系統(tǒng)Provision的時(shí)候進(jìn)行分配)，接管所有的業(yè)務(wù)端口流量、SSL加解密芯片和HTTP硬件壓縮芯片等資源，然后根據(jù)自己的需求進(jìn)行使用。只要從BIG-IPLTM前面板的業(yè)務(wù)端口進(jìn)入的流量，都會先經(jīng)過TMM的處理。當(dāng)BIG-IPLTM只有單核CPU時(shí)，主要的CPU資源都優(yōu)先分配給TMM進(jìn)程。在這種結(jié)構(gòu)下，所有的流量處理都在TMM里直接處理，則可以到很高的性能，除了負(fù)載均衡以外，在BIG-IPLTMLTM上的SSL、RamCache、Compress、SSLVPN、WOM等功能都是在TMM內(nèi)部處理的。而一些比較大型的工作模塊如GTM(GlobalTrafficManager)、WA（WebAccelerator）、ASM(ApplicationSecurityManager)和認(rèn)證等一些功能則是通過其他的進(jìn)程進(jìn)行處理，這些進(jìn)程通過內(nèi)部的Plugin結(jié)構(gòu)和TMM進(jìn)行通訊。多核CPU平臺：當(dāng)系統(tǒng)中有多個(gè)CPU內(nèi)核存在時(shí)，BIG-IPLTM將進(jìn)入CMP(ClusterMutiProcessor)的工作模式，所謂CMP，就是在BIG-IPLTMLTM的內(nèi)部，使用硬件芯片HSB（HighSpeedBridge）對進(jìn)入生產(chǎn)端口的流量在內(nèi)部進(jìn)行了一次負(fù)載均衡，使流量均勻的分布到每個(gè)TMM核心上去。而每個(gè)TMM核心占據(jù)一個(gè)CPU內(nèi)核1．5BIG-IPLTM的負(fù)載均衡算法輪詢算法（RoundRobin）：BIG-IPLTM順序循環(huán)將請求一次順序循環(huán)地連接每個(gè)服務(wù)器。當(dāng)其中某個(gè)服務(wù)器發(fā)生第2到第7層的故障，則將其從順序循環(huán)隊(duì)列中拿出，不參加下一次的輪詢，直到其恢復(fù)正常。比率算法（Ratio）：在BIG-IPLTM上給每個(gè)服務(wù)器分配一個(gè)加權(quán)值為比例，根椐這個(gè)比例，BIG-IPLTM把用戶的請求分配到每個(gè)服務(wù)器。當(dāng)其中某個(gè)服務(wù)器發(fā)生第2到第7層的故障，就把其從服務(wù)器隊(duì)列中拿出，不參加下一次的用戶請求的分配,直到其恢復(fù)正常。最少連接數(shù)（LeastConnections）：在BIG-IPLTM上對每一臺服務(wù)器的當(dāng)前連接數(shù)進(jìn)行統(tǒng)計(jì)，當(dāng)有新的請求進(jìn)入時(shí)，將新的請求分配給當(dāng)前最少連接處理的服務(wù)器。當(dāng)其中某個(gè)服務(wù)器發(fā)生第2到第7層的故障，BIG-IPLTM就把其從服務(wù)器隊(duì)列中拿出，不參加下一次的用戶請求的分配,直到其恢復(fù)正常。最快響應(yīng)速度（Fastest）：在BIG-IPLTM上通過觀察每臺服務(wù)器得應(yīng)用響應(yīng)速度，當(dāng)有新的請求進(jìn)入的時(shí)候，將新的請求分配給響應(yīng)最快的服務(wù)器。當(dāng)其中某個(gè)服務(wù)器發(fā)生第2到第7層的故障，BIG-IPLTM就把其從服務(wù)器隊(duì)列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。觀察模式（Observed）：連接數(shù)目和響應(yīng)時(shí)間以這兩項(xiàng)的最佳平衡為依據(jù)為新的請求選擇服務(wù)器。當(dāng)其中某個(gè)服務(wù)器發(fā)生第二到第7層的故障，BIG/IP就把其從服務(wù)器隊(duì)列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。性能預(yù)測分配：（Predictive）由負(fù)載均衡設(shè)備收集到的應(yīng)用程序和應(yīng)用服務(wù)器的各項(xiàng)性能參數(shù)如CPU占用率，內(nèi)存占用率、當(dāng)前并發(fā)用戶數(shù)等關(guān)鍵信息，并可進(jìn)行加權(quán)處理。當(dāng)有新的請求進(jìn)入的時(shí)候，將新的請求分配給綜合性能最佳的服務(wù)器。當(dāng)其中某個(gè)服務(wù)器發(fā)生第2到第7層的故障，BIG-IPLTM就把其從服務(wù)器隊(duì)列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。1．6BIG-IPLTM會話保持1．6．1會話保持的需求：以最典型的HTTP應(yīng)用為例，在大多數(shù)電子商務(wù)的應(yīng)用系統(tǒng)或者需要進(jìn)行用戶身份認(rèn)證的在線系統(tǒng)中，一個(gè)客戶與服務(wù)器經(jīng)常經(jīng)過好幾次的交互過程才能完成一筆交易或者是一個(gè)請求的完成。由于這幾次交互過程是密切相關(guān)的，服務(wù)器在進(jìn)行這些交互過程的某一個(gè)交互步驟時(shí)，往往需要了解上一次交互過程的處理結(jié)果，或者上幾步的交互過程結(jié)果，服務(wù)器進(jìn)行下一步操作時(shí)需要這就要求所有這些相關(guān)的交互過程都由一臺服務(wù)器完成，而不能被負(fù)載均衡器分散到不同的服務(wù)器上。一個(gè)典型的HTTP請求流程如下：客戶端發(fā)起一個(gè)連接到服務(wù)器的服務(wù)端口，并在此連接中發(fā)送HTTP請求服務(wù)器在接收到用戶請求后，在本地產(chǎn)生一個(gè)內(nèi)部SessionID用于唯一標(biāo)識該用戶服務(wù)器將返回內(nèi)容進(jìn)行組織后，同時(shí)將SessionID通過Cookie返回給用戶用戶在收到回應(yīng)后，將Cookie保存在內(nèi)存中。用戶下一次點(diǎn)擊重新發(fā)起一個(gè)連接到服務(wù)器的服務(wù)端口用戶在新建連接中發(fā)送HTTP請求，并帶上Cookie進(jìn)行發(fā)送。服務(wù)器在收到請求后，從Cookie中獲得該用戶的SessionID,根據(jù)此SessionID進(jìn)行相關(guān)處理1．6．2源地址會話保持：源地址會話保持的一個(gè)基本概念就是將一個(gè)源地址認(rèn)為是一個(gè)用戶，凡是同一個(gè)源地發(fā)送過來的連接，則認(rèn)為是同一個(gè)用戶發(fā)起的多個(gè)請求，根據(jù)會話保持策略，將這些連接/請求都轉(zhuǎn)發(fā)到同一臺服務(wù)器。當(dāng)一個(gè)新的連接請求發(fā)送到虛擬服務(wù)后，首先查找源地址會話保持表，如果在源地址會話保持表中查詢到了該請求發(fā)起的源地址對應(yīng)的服務(wù)器，則直接將該請求轉(zhuǎn)發(fā)到相應(yīng)的服務(wù)器上，如果在源地址會話保持表中沒有查詢到相應(yīng)的條目，則按照負(fù)載均衡算法將請求轉(zhuǎn)發(fā)到相應(yīng)的服務(wù)器，同時(shí)，將該請求發(fā)起的源地址和對應(yīng)的服務(wù)器地址添加到源地址會話保持表中。這樣，下次同一IP地址再發(fā)起新建連接到該虛擬服務(wù)時(shí)，則在源地址會話保持表中已經(jīng)存在相應(yīng)的條目，新的連接則會根據(jù)源地址會話保持表的對應(yīng)項(xiàng)轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)器上。源地址會話保持同時(shí)還存在有一個(gè)超時(shí)時(shí)間參數(shù)。每次有有新建連接請求或已建立的連接中有數(shù)據(jù)在傳輸時(shí)，就會刷新會話保持表中的超時(shí)時(shí)間。比如設(shè)置源IP會話保持的超時(shí)時(shí)間為300秒，則對于同一個(gè)源IP，只要有新建連接或已建連接有數(shù)據(jù)傳輸，則在源地址會話保持表中的超時(shí)時(shí)間一直刷新為0。當(dāng)沒有新建連接或者數(shù)據(jù)傳輸時(shí)，該值就開始按秒進(jìn)行累加，一旦超出300秒沒有新建連接請求或沒有數(shù)據(jù)傳輸。則將其條目從源地址會話保持表中清除。如果該IP地址在在過了超時(shí)時(shí)間之后又有新的連接請求，則以第一次連接請求按照負(fù)載均衡的算法進(jìn)行處理，此時(shí)，源地址會話保持表中的超時(shí)時(shí)間又從0開始計(jì)算。1．6．3哈希會話保持哈希會話保持的一個(gè)基本概念就是將一個(gè)連接中的源IP和目的IP地址進(jìn)行Hash計(jì)算，根據(jù)計(jì)算得到的結(jié)果并根據(jù)后臺存在多少臺服務(wù)器來選擇將請求分配到那臺服務(wù)器。哈希會話保持的特點(diǎn)是在后臺服務(wù)器的健康狀態(tài)不發(fā)生改變的時(shí)候，每個(gè)特定的源IP地址被分配到的服務(wù)器是固定的。并且，哈希會話保持可以沒有會話保持表，而僅僅是根據(jù)計(jì)算的結(jié)果來確定一個(gè)源IP被分配到那臺服務(wù)器。哈希會話保持通常被用于一些特定場合，如要求客戶端按照IP地址被固定分配的場合，或者在一些會話保持表查詢的開銷已經(jīng)遠(yuǎn)遠(yuǎn)大于Hash計(jì)算開銷的情況下，采用hash會話保持可以提高系統(tǒng)的處理能力和響應(yīng)速度。在實(shí)際的應(yīng)用場景中，針對后臺采用Cache服務(wù)器的情況，還有對URL進(jìn)行Hash的處理方式，將同一個(gè)URL的請求分配到同一臺Cache服務(wù)器，這樣，對后臺的Cache服務(wù)器群組來說，每臺Cache服務(wù)器上存放的內(nèi)容都是不一樣的，提高Cache服務(wù)器的利用率。1．6．4Cookie會話保持.Cookie是在瀏覽器訪問WEB服務(wù)器的某個(gè)資源時(shí)，由WEB服務(wù)器在HTTP響應(yīng)消息頭中附帶傳送給瀏覽器的一片數(shù)據(jù)，WEB服務(wù)器傳送給各個(gè)客戶端瀏覽器的數(shù)據(jù)是可以各不相同的。瀏覽器可以決定是否保存這片數(shù)據(jù)，一旦WEB瀏覽器保存了這片數(shù)據(jù)，那么它在以后每次訪問該WEB服務(wù)器時(shí)，都應(yīng)在HTTP請求頭中將這片數(shù)據(jù)回傳給WEB服務(wù)器。顯然，Cookie最先是由WEB服務(wù)器發(fā)出的，是否發(fā)送Cookie和發(fā)送的Cookie的具體內(nèi)容，完全是由WEB服務(wù)器決定的。例如，用一個(gè)Cookie來標(biāo)識訪問者的姓名，有效時(shí)間等。CookieInsert會話保持模式因?yàn)镃ookie被如此廣泛的使用，特別是SessionCookie技術(shù)，基本上在所有的電子商務(wù)網(wǎng)站中都在使用這種技術(shù)。因此，在BIG-IPLTM中可以通過插入自己可識別的Cookie來實(shí)現(xiàn)會話保持。當(dāng)客戶進(jìn)行第一次請求時(shí)，客戶HTTP請求（不帶cookie）進(jìn)入BIG-IPLTM，BIG-IPLTM根據(jù)負(fù)載均衡算法策略選擇后端一臺服務(wù)器，并將請求發(fā)送至該服務(wù)器，后端服務(wù)器進(jìn)行HTTP回復(fù)（不帶cookie）被發(fā)回BIG-IPLTM，然后BIG-IPLTM插入cookie，將HTTP回復(fù)返回到客戶端。當(dāng)客戶請求再次發(fā)生時(shí)，客戶HTTP請求（帶有上次BIG-IPLTM插入的cookie）進(jìn)入BIG-IPLTM，然后BIG-IPLTM讀出cookie里的會話保持?jǐn)?shù)值，將HTTP請求（帶有與上面同樣的cookie）發(fā)到指定的服務(wù)器，然后后端服務(wù)器進(jìn)行請求回復(fù)，由于服務(wù)器并不寫入cookie，HTTP響應(yīng)將不帶有cookie，服務(wù)器響應(yīng)再次經(jīng)過進(jìn)入BIG-IPLTM時(shí)，BIG-IPLTM再次寫入更新后的會話保持cookie。1．7健康檢查健康檢查是負(fù)載均衡處理中一個(gè)非常重要的環(huán)節(jié)。負(fù)載均衡的主要作用就是將客戶端的請求分配到多臺服務(wù)器上，如果沒有健康檢查，在后臺服務(wù)器發(fā)生故障的時(shí)候，部分的客戶端將會被分配到故障的服務(wù)器上，從而導(dǎo)致用戶的訪問失敗。在一些情況下，甚至可能出現(xiàn)服務(wù)器本身還在工作，但其上運(yùn)行的應(yīng)用系統(tǒng)已經(jīng)故障導(dǎo)致無法處理請求，都將會導(dǎo)致用戶的請求失敗。在BIG-IPLTM上應(yīng)當(dāng)能檢查到這些故障，并在進(jìn)行負(fù)載均衡的時(shí)候?qū)⑦@些故障的服務(wù)器進(jìn)行自動(dòng)摘除，保證應(yīng)用的持續(xù)性和高可用性。1．7．1基于ICMP的健康檢查基于ICMP的健康檢查屬于最基本的健康檢查方式，BIG-IPLTM主動(dòng)給服務(wù)器發(fā)送一個(gè)ICMP(互聯(lián)網(wǎng)控制信息協(xié)議)數(shù)據(jù)包，如果BIG-IPLTM收到了服務(wù)器的正確響應(yīng)，則說明檢查成功。ICMP健康檢查通常用于網(wǎng)關(guān)類型設(shè)備的健康檢查，如防火墻、路由器等。這些設(shè)備通常不提供其他的健康檢查手段，因此ICMP屬于最佳的檢查方式。另外，在一些無法使用高級健康檢查手段的情況下，也只能使用ICMP健康檢查手段。1．7．2基于TCP端口的健康檢查在基于TCP協(xié)議的應(yīng)用中，每個(gè)應(yīng)用系統(tǒng)都會綁定一個(gè)TCP端口，應(yīng)用通過偵聽這個(gè)端口接受客戶端的請求。比如我們常見的80端口在默認(rèn)情況下就是服務(wù)于HTTP服務(wù)，通常為IIS、Apache等應(yīng)用系統(tǒng)使用，另外還有FTP（20、21）、HTTPS（443）、SMTP（25）、POP3（110）等。判斷這些應(yīng)用系統(tǒng)是否在工作最簡單的方法就是從BIG-IPLTM和對應(yīng)的服務(wù)器端口做一次完整的TCP握手，如果TCP握手成功，則認(rèn)為服務(wù)器正常工作，如果握手失敗，在超過一定的檢查次數(shù)均握手失敗的情況下，BIG-IPLTM則將失敗的服務(wù)器標(biāo)記為Down，而將新的客戶端請求都發(fā)送到其他仍然正常工作的服務(wù)器上。在TCP健康檢查中還可能出現(xiàn)的一種情況就是在頻繁檢查的情況下，健康檢查的流量可能導(dǎo)致一些比較“脆弱”的應(yīng)用系統(tǒng)產(chǎn)生故障。通常有兩種情況會出現(xiàn)這種故障情況：1.服務(wù)器的Socket偵聽程序不完善，對于TCP健康檢查沒有正確關(guān)閉連接2.服務(wù)器對每個(gè)試圖連接都進(jìn)行l(wèi)og，最后整個(gè)應(yīng)用系統(tǒng)的Log都被健康檢查的連接所充滿。而導(dǎo)致磁盤空間溢出或者正常的log信息無法察看。在這種情況下，有兩種解決方式：1.采用TCPhalfopen的方式進(jìn)行健康檢查，所謂TCPhalfopen就是BIG-IPLTM向服務(wù)器發(fā)送一個(gè)Syn數(shù)據(jù)包，一旦受到來自該服務(wù)的Syn-ACK數(shù)據(jù)包，則認(rèn)為該服務(wù)正常工作，然后立即發(fā)送一個(gè)RESET數(shù)據(jù)包到服務(wù)。在一些情況下，這種TCP半連接模式并不會被記錄下來。2.采用基于代理的健康檢查，即在服務(wù)器上另外編寫一個(gè)進(jìn)程，專門用于健康檢查使用，專用的健康檢查進(jìn)程將會負(fù)責(zé)BIG-IPLTM的健康查詢，而保護(hù)主進(jìn)程的不受干擾的運(yùn)行。1．7．3基于應(yīng)用協(xié)議的健康檢查由于在ICMP、TCP端口和UDP端口的健康檢查中，我們都不一定能確認(rèn)服務(wù)器的真實(shí)工作狀態(tài)。在實(shí)際中經(jīng)常有可能出現(xiàn)這樣的情況：服務(wù)器IP地址還可以ping，但是應(yīng)用服務(wù)已經(jīng)crash了應(yīng)用服務(wù)還在監(jiān)聽80端口，但是已經(jīng)不接收任何請求了應(yīng)用服務(wù)仍然接收請求，但是每次都返回503服務(wù)器內(nèi)部錯(cuò)誤這種服務(wù)已經(jīng)不正常，但是端口仍在監(jiān)聽的情況，在一些非關(guān)鍵業(yè)務(wù)上還可以容忍，但在一些關(guān)鍵業(yè)務(wù)的應(yīng)用中就不可接受了。以HTTP協(xié)議為例，基于HTTP協(xié)議的健康檢查過程如下：BIG-IPLTM發(fā)起一個(gè)HTTP請求到服務(wù)器，請求特定的資源服務(wù)器進(jìn)行回應(yīng)BIG-IPLTM在返回的內(nèi)容中查找一個(gè)關(guān)鍵字，如果存在該關(guān)鍵字，則認(rèn)為Web服務(wù)器正常工作中。HTTP協(xié)議層的健康檢查通常用于應(yīng)用服務(wù)器的健康檢查，如WebLogic、WebSphare、Tomcat等。和IIS、Apache服務(wù)相比，這些應(yīng)用服務(wù)器出現(xiàn)故障的幾率通常較大。而且最容易出現(xiàn)端口仍然在偵聽，但應(yīng)用已經(jīng)不工作的情況。典型的基于應(yīng)用協(xié)議的健康檢查通常還有：FTP:由BIG-IPLTM向FTP服務(wù)器發(fā)起FTP請求，在驗(yàn)證用戶名和密碼后，下載一個(gè)文件（通常不會保存這個(gè)文件），如果文件下載成功，則認(rèn)為服務(wù)器工作正常。這樣整個(gè)FTP服務(wù)器的用戶認(rèn)證、磁盤存儲連接等服務(wù)都進(jìn)行了檢查。DNS:由BIG-IPLTM向DNS服務(wù)器發(fā)起一個(gè)DNS請求，請求特定的域名，并檢查返回的結(jié)果，如果正確，則認(rèn)為服務(wù)器工作正常。HTTPS:由BIG-IPLTM向HTTPS發(fā)起一個(gè)HTTPS請求，通常，在HTTPS的健康檢查中可能還需要配置客戶端證書等，在服務(wù)器響應(yīng)返回后，在返回的數(shù)據(jù)中查找特定的字符串，如果匹配成功，則認(rèn)為HTTPS服務(wù)器工作正常。POP3：由BIG-IPLTM向POP3服務(wù)器發(fā)起一個(gè)請求，并進(jìn)行用戶名和密碼驗(yàn)證。如果登陸成功，則認(rèn)為POP3服務(wù)器工作正常。SMTP：由BIG-IPLTM向SMTP服務(wù)器發(fā)送一個(gè)標(biāo)準(zhǔn)的SMTP請求，如果服務(wù)器按照標(biāo)準(zhǔn)SMTP響應(yīng)返回HELO或QUIT，則認(rèn)為SMTP服務(wù)工作正常。通常情況下，SMTP健康檢查在發(fā)送請求的時(shí)候還需要指定域名。數(shù)據(jù)庫：由BIG-IPLTM向數(shù)據(jù)庫服務(wù)器發(fā)起一次數(shù)據(jù)庫查詢請求，然后判斷數(shù)據(jù)庫服務(wù)器返回的結(jié)果中是否包含特定的字符串，如果匹配成功，則認(rèn)為數(shù)據(jù)庫服務(wù)器工作正常。二、F5BIG-IPLTM日常維護(hù)2．1F5BIG-IPLTM外觀F5在設(shè)備前面板上劃分明顯不同的三個(gè)區(qū)域，最左側(cè)設(shè)計(jì)有failover和console接口；中部為各種網(wǎng)絡(luò)接口；最右側(cè)為液晶屏幕、狀態(tài)顯示燈、6個(gè)控制按鈕及F5的紅色logo燈泡。面板前部設(shè)計(jì)有冷風(fēng)入口。電源設(shè)計(jì)在設(shè)備的尾部以方便機(jī)架上電源線接入，設(shè)備產(chǎn)生的熱量從尾部的熱風(fēng)出口散出。1.管理口2.USB接口3.Console口4.Failover口5.10/100/1000自適應(yīng)接口6.SFP接口7.指示燈8.液晶屏9.液晶屏控制按鈕1.電源模塊一2.電源模塊二3.散熱風(fēng)扇通過LCD按鍵修改管理網(wǎng)口IP地址的方法如下：1. 按紅色X按鍵進(jìn)入Options選項(xiàng)；2. 在液晶面板上通過按鍵按以下順序設(shè)置管理網(wǎng)口的網(wǎng)絡(luò)地址：Options->System->IPAddress/Netmask->Commit2．2F5BIG-IPLTM配置備份和恢復(fù)可以通過以下WEB界面進(jìn)行配置的備份與修改：進(jìn)入System?Archives，點(diǎn)擊Create：配置備份好后，點(diǎn)擊設(shè)配置文件并下載到外部電腦上：恢復(fù)系統(tǒng)時(shí)點(diǎn)擊Restore如果是需要一個(gè)完全干凈的系統(tǒng)，建議通過重裝系統(tǒng)來恢復(fù)到出廠設(shè)置。如果沒辦法重裝系統(tǒng)，但需要將配置清空以重新進(jìn)行配置，方法如下：從管理網(wǎng)口用命令行登陸B(tài)IG-IP，然后執(zhí)行以下命令：#bdballreset#breset#bsave#bbasereset#bbasesave2．3F5BIG-IPLTM性能狀態(tài)2．3．1F5BIG-IPLTM實(shí)時(shí)連接狀態(tài)在命令行模式輸入：bconn查看當(dāng)前端口的狀態(tài)查看當(dāng)前node信息查看pool狀態(tài)查看當(dāng)前VS信息2．3．2F5BIG-IPLTM性能狀態(tài)查看當(dāng)前F5性能狀態(tài)通過WEB頁面，Overview選項(xiàng)卡中的Performance查看當(dāng)前F5BIG-IPLTM的主備狀態(tài)查看當(dāng)前F5BIG-IPLTM的組件狀態(tài)命令行模式：bplatform查看當(dāng)前F5BIG-IPLTMTOP狀態(tài)命令行模式：bigtop查看F5BIG-IPLTMTMM內(nèi)存狀態(tài)命令行模式：bmemoryshow2．3．3F5BIG-IPLTM告警日志通過WEBSystem選項(xiàng)中的logs或者在命令行模式輸入more/var/log/messages查看F5系統(tǒng)日志more/var/log/ltm查看member和node狀態(tài)日志收集F5BIG-IPLTM后臺錯(cuò)誤日志提交F5官方分析命令行模式輸入：三、F5BIG-IPLTM服務(wù)配置3．1F5BIG-IPLTM創(chuàng)建用戶通過WEB界面，在System選項(xiàng)卡中選擇UsersCreate3．2F5BIG-IPLTM開啟本地服務(wù)選擇某服務(wù)，start即可注：ntpd服務(wù)需要在命令行模式修改vi/etc/ntp.conf中，增加ntpserver3．3手動(dòng)切換主備狀態(tài)3．4修改admin和root密碼3．5健康檢查的管理和維護(hù)根據(jù)需求選擇類型以http為例命名規(guī)則：類型_端口號，如http_8001Interval：間隔時(shí)間，即為健康檢查服務(wù)向節(jié)點(diǎn)發(fā)送兩次檢查數(shù)據(jù)包的間隔時(shí)間。Timeout：超時(shí)時(shí)間，即為健康檢查服務(wù)向節(jié)點(diǎn)發(fā)送健康檢查數(shù)據(jù)包沒有回執(zhí)的超時(shí)時(shí)間。SendString和ReceiveString：F5會向節(jié)點(diǎn)發(fā)送SendString中的內(nèi)容，如果回執(zhí)與ReceiveString中的內(nèi)容一致，則視為該節(jié)點(diǎn)正常。該功能需要有應(yīng)用人員提供相應(yīng)的代碼。也可以為空。AliasServicePort：指定服務(wù)8001端口3．6pool的管理和維護(hù)Pool命名規(guī)則：pool_（地市名）_系統(tǒng)名（用途），如：pool_oa，pool_anqing_oajkHealthMonitors：指定該pool的健康檢查ActionOnServiceDown：節(jié)點(diǎn)中服務(wù)down了以后的處理方式，一般這里都選擇轉(zhuǎn)發(fā)（Reselect）LoadBalancingMethod：負(fù)載均衡的方式，根據(jù)需求，一般我們選擇RoundRobin。NewMember：這里加入需要負(fù)載均衡的應(yīng)用節(jié)點(diǎn)。后續(xù)增加pool中的節(jié)點(diǎn)在Pool列表選擇某個(gè)Pool，點(diǎn)擊列表上的Members個(gè)數(shù)鏈接，或點(diǎn)擊Pool名稱后，選擇Members頁簽在Member列表，點(diǎn)擊右上方的Add按鈕，出現(xiàn)添加頁面填寫ip和端口，configuration選擇Advanced，選擇monitors,Http服務(wù)選擇http，其他服務(wù)選擇tcp（根據(jù)具體情況），點(diǎn)擊Finished按鈕添加完成。如果要移除pool下的節(jié)點(diǎn)，可以在pool的列表界面，選中節(jié)點(diǎn)，直接點(diǎn)delete，沒有確認(rèn)。3．7VS的管理和維護(hù)VS命名規(guī)則：vs_（地市）_系統(tǒng)用途，例如：vs_oajk，vs_anqing_jtjkDestination：對外提供服務(wù)的IPServicePort：對外提供服務(wù)的端口如果是http服務(wù)，httpprofile需要選上OneConectProfile：鏈路復(fù)用的功能，如果是用cookiesinster的會話保持方式時(shí)，這一項(xiàng)必須選擇oneconnect?；蛘哂袝挶３值拈L連接也需要開啟這個(gè)功能。SNATPool：必須選擇AutoMap如果VS只提供單一的服務(wù)，不需要irules做條件判斷，DefaultPool就選擇相應(yīng)的服務(wù)節(jié)點(diǎn)。如果VS需要有irules做條件判斷，來轉(zhuǎn)發(fā)vs下屬的多個(gè)pool，則DefaultPool選擇none。3．8iRules管理和維護(hù)iRules運(yùn)用TCL運(yùn)行引擎執(zhí)行腳本。能夠?qū)α髁恐苯硬倏睾蛯θ我釯P應(yīng)用流量的管理。iRules命名規(guī)則：iRules_服務(wù)名稱，如：iRules_oajk網(wǎng)廳iRules腳本whenHTTP_REQUEST{if{[HTTP::uri]starts_with"/sso"}{poolpool_wt_sso}elseif{[HTTP::uri]starts_with"/biz"}{poolpool_wt_biz}elseif{[HTTP::uri]starts_with"/activity"}{poolpool_wt_activity}elseif{[HTTP::uri]starts_with"/vip"}{poolpool_wt_vip}elseif{[HTTP::uri]starts_with"/track"}{poolpool_wt_track}elseif{[HTTP::uri]starts_with"/search"}{poolpool_wt_search}elseif{[HTTP::uri]starts_with"/shop"}{poolpool_wt_shop}elseif{[HTTP::uri]starts_with"/"and[HTTP::uri]ends_with".gif"}{poolpool_wt_zy}elseif{[HTTP::uri]starts_with"/"and[HTTP::uri]ends_with".jpg"}{poolpool_wt_zy}elseif{[HTTP::uri]starts_with"/"and[HTTP::uri]ends_with".jpeg"}{poolpool_wt_zy}elseif{[HTTP::uri]starts_with"/"and[HTTP::uri]ends_with".png"}{poolpool_wt_zy}elseif{[HTTP::uri]starts_with"/"and[HTTP::uri]ends_with".bmp"}{poolpool_wt_zy}elseif{[HTTP::uri]starts_with"/"and[HTTP::uri]ends_with".swf"}{poolpool_wt_zy}elseif{[HTTP::uri]starts_w