F5負(fù)載均衡器維護(hù)手冊(cè)

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