-.z.F5負載均衡器維護手冊目錄F5負載均衡器維護手冊1一、根本原理31．1負載均衡器的根本原理31．2負載均衡器幾要素31．3F5BIG-IPLTM根本元素31．4BIG-IPLTM的TMM31．5BIG-IPLTM的負載均衡算法31．6BIG-IPLTM會話保持31．6．1會話保持的需求：31．6．2源地址會話保持：31．6．3哈希會話保持31．6．4Cookie會話保持.31．7安康檢查31．7．1基于ICMP的安康檢查31．7．2基于TCP端口的安康檢查31．7．3基于應用協議的安康檢查3二、F5BIG-IPLTM日常維護32．1F5BIG-IPLTM外觀32．2F5BIG-IPLTM配置備份和恢復32．3F5BIG-IPLTM性能狀態32．3．1F5BIG-IPLTM實時連接狀態32．3．2F5BIG-IPLTM性能狀態32．3．3F5BIG-IPLTM告警日志3三、F5BIG-IPLTM效勞配置33．1F5BIG-IPLTM創立用戶33．2F5BIG-IPLTM開啟本地效勞33．3手動切換主備狀態33．4修改admin和root密碼33．5安康檢查的管理和維護33．6pool的管理和維護33．7VS的管理和維護33．8iRules管理和維護33．9rofile管理和維護3四、F5BIG-IPLTM故障處理34．1應用效勞故障34．2F5BIG-IPLTM硬件故障3一、根本原理1．1負載均衡器的根本原理應用負載均衡器對外提供一個虛擬的應用效勞器，接收所有的客戶端請求應用負載均衡器通過負載均衡算法處理，將客戶端請求轉發到后臺的多個應用實例應用負載均衡器通過應用安康檢查，準確的判斷應用程序的工作和效勞狀態，一旦發現應用不能提供效勞，則將其從負載均衡組中摘除1．2負載均衡器幾要素負載分配策略：負載分配策略是應用負載均衡的整個核心，如何對用戶的流量進展分配，使后臺效勞器的處理更加合理。到達均衡負載，保證用戶的最正確體驗的目的，和負載分配策略具有密不可分的關系。安康檢查策略：在一個良好設計的系統中，負載均衡器往往處于一個系統的核心位置，很多用戶使用四層負載均衡的一個主要原因就是要實現應用的高可用性而非性能問題。如何讓負載均衡器能智能的檢查到效勞器真實的安康狀態，在系統的設計中起到至關重要的作用。會話保持策略：就目前而言，只有很少的應用系統是專為多效勞器并行處理而設計，用戶的登錄信息，SessionID等還是在單臺效勞器上存放，并沒有同步到其他的效勞器上，因此，會話保持策略的豐富性也是四層負載均衡一個巨大的挑戰。冗余切換策略：在保證了后臺設備的高可用性之后，出于系統核心位置的負載均衡器自身的高可用性就變得尤其重要，并且由于應用訪問的不透明性，造成在緊急情況下很難對所有的應用進展遷移工作。這時負載均衡器的冗余切換策略和手段將關系到整個系統的高可用性。網絡構造的靈活性：對于一個橫跨網絡和應用的設備來說，對于網絡構造和應用構造的完整支持特性變得尤其重要，網絡層的根本技術如VLAN、Trunk、Spanning、Tree、IPV4/V6、靜態路由、OSPF等都將成為負載均衡器的根本配置。而另外對于應用中的各種特殊協議的支持，也決定了負載均衡器部署的圍和使用。1．3F5BIG-IPLTM根本元素在BIG-IPLTM中，針對應用負載均衡的應用特色和系統需求，將整個流量的處理過程按照以下方式進展定義：VS：VirtualServer是進入BIG-IPLTM處理流量的入口。VS的定義包含了IP和端口和VLAN，其中，IP可以是一個IP，也可以是用掩碼掩出來的一段IP，端口可以是一個固定的端口，比方80，也可以是0端口，0端口的意思就是偵聽所有的端口。VS的定義的含義就是對于發送到BIG-IPLTM上的流量，只有同時命中VS的IP和端口的流量才進展處理。Profile：當流量進入BIG-IPLTM之后，怎樣去處理和識別進入VS的流量，就需要由Profile來定義了。Profile分了幾種類型，有協議層的Profile比方TCPprofile,UDPprofile。有應用層的Profile比方profile，FTPProfile。還有SSLProfile、會話保持相關的Profile、認證的Profile和其他一些Profile類型。所有的Profile都需要關聯在VS上才能生效。有些Profile之間是互斥的關系，比方TCP和UDP,和FTP，VS上關聯了TCPprofile，就不能再關聯UDPProfile了。因為一旦關聯了*個Profile，VS就會按照這個Profile的定義方式去處理流量。所以有些Profile也是相互依存的，比方要關聯Profile，就必須先關聯TCPProfile。Pool：Pool在LTM的部是一個邏輯概念，是指的一組一樣效勞的資源的組合。Pool的作用很簡單，就是根據自身定義的分發規則，對VS接收進來，并且被Profile處理之后的流量進展分發，分發到Pool的member去。Member:一個應用效勞，通常情況下，一個Member就是后臺效勞器的一個偵聽進程，是由IP:port格式組成。Node:Node通常用來表示后臺的一個效勞IP地址，一個Node上面可以有一個或多個Member。Node不需要進展配置，在配置了Member之后自動產生，系統會根據每一個不同的MemberIP地址生成一個Node地址iRules：iRules相當于在整個數據包通路上進展一個監控和處理。VS-Pool-SNAT的這一條路上，iRules可以通過事件驅動方式，在通路上的任何一個位置上對數據包進展判斷和處理。比方Client_Accepted事件就是當請求命中VS的時候被激活，poolwebpool這條指令用于指示BIG-IPLTM將流量分配到那個Pool里面去。而iRules的事件是否能觸發或者iRules能獲取和處理那些信息，則都是由關聯的Profile來決定的。比方VS只關聯了TCPProfile，而沒關聯Profile。那即使通過VS的流量都是請求，iRules也無法去獲取URI、header等信息。只有關聯了Profile之后，iRules才能觸發相關事件和按照協議的相關規對請求容進展識別和判斷。1．4BIG-IPLTM的TMMTMM就是一個應用程序。TMM一旦啟動，就會搶占系統的大局部存(存分配可以在系統Provision的時候進展分配)，接收所有的業務端口流量、SSL加解密芯片和硬件壓縮芯片等資源，然后根據自己的需求進展使用。只要從BIG-IPLTM前面板的業務端口進入的流量，都會先經過TMM的處理。當BIG-IPLTM只有單核CPU時，主要的CPU資源都優先分配給TMM進程。在這種構造下，所有的流量處理都在TMM里直接處理，則可以到很高的性能，除了負載均衡以外，在BIG-IPLTMLTM上的SSL、RamCache、press、SSLVPN、WOM等功能都是在TMM部處理的。而一些比擬大型的工作模塊如GTM(GlobalTrafficManager)、WA〔WebAccelerator〕、ASM(ApplicationSecurityManager)和認證等一些功能則是通過其他的進程進展處理，這些進程通過部的Plugin構造和TMM進展通訊。多核CPU平臺：當系統中有多個CPU核存在時，BIG-IPLTM將進入CMP(ClusterMutiProcessor)的工作模式，所謂CMP，就是在BIG-IPLTMLTM的部，使用硬件芯片HSB〔HighSpeedBridge〕對進入生產端口的流量在部進展了一次負載均衡，使流量均勻的分布到每個TMM核心上去。而每個TMM核心占據一個CPU核1．5BIG-IPLTM的負載均衡算法輪詢算法〔RoundRobin〕：BIG-IPLTM順序循環將請求一次順序循環地連接每個效勞器。當其中*個效勞器發生第2到第7層的故障，則將其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢復正常。比率算法〔Ratio〕：在BIG-IPLTM上給每個效勞器分配一個加權值為比例，根椐這個比例，BIG-IPLTM把用戶的請求分配到每個效勞器。當其中*個效勞器發生第2到第7層的故障，就把其從效勞器隊列中拿出，不參加下一次的用戶請求的分配,直到其恢復正常。最少連接數〔LeastConnections〕：在BIG-IPLTM上對每一臺效勞器的當前連接數進展統計，當有新的請求進入時，將新的請求分配給當前最少連接處理的效勞器。當其中*個效勞器發生第2到第7層的故障，BIG-IPLTM就把其從效勞器隊列中拿出，不參加下一次的用戶請求的分配,直到其恢復正常。最快響應速度〔Fastest〕：在BIG-IPLTM上通過觀察每臺效勞器得應用響應速度，當有新的請求進入的時候，將新的請求分配給響應最快的效勞器。當其中*個效勞器發生第2到第7層的故障，BIG-IPLTM就把其從效勞器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。觀察模式〔Observed〕：連接數目和響應時間以這兩項的最正確平衡為依據為新的請求選擇效勞器。當其中*個效勞器發生第二到第7層的故障，BIG/IP就把其從效勞器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。性能預測分配：〔Predictive〕由負載均衡設備收集到的應用程序和應用效勞器的各項性能參數如CPU占用率，存占用率、當前并發用戶數等關鍵信息，并可進展加權處理。當有新的請求進入的時候，將新的請求分配給綜合性能最正確的效勞器。當其中*個效勞器發生第2到第7層的故障，BIG-IPLTM就把其從效勞器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。1．6BIG-IPLTM會話保持1．6．1會話保持的需求：以最典型的應用為例，在大多數電子商務的應用系統或者需要進展用戶身份認證的在線系統中，一個客戶與效勞器經常經過好幾次的交互過程才能完成一筆交易或者是一個請求的完成。由于這幾次交互過程是密切相關的，效勞器在進展這些交互過程的*一個交互步驟時，往往需要了解上一次交互過程的處理結果，或者上幾步的交互過程結果，效勞器進展下一步操作時需要這就要求所有這些相關的交互過程都由一臺效勞器完成，而不能被負載均衡器分散到不同的效勞器上。一個典型的請求流程如下：客戶端發起一個連接到效勞器的效勞端口，并在此連接中發送請求效勞器在接收到用戶請求后，在本地產生一個部SessionID用于唯一標識該用戶效勞器將返回容進展組織后，同時將SessionID通過Cookie返回給用戶用戶在收到回應后，將Cookie保存在存中。用戶下一次點擊重新發起一個連接到效勞器的效勞端口用戶在新建連接中發送請求，并帶上Cookie進展發送。效勞器在收到請求后，從Cookie中獲得該用戶的SessionID,根據此SessionID進展相關處理1．6．2源地址會話保持：源地址會話保持的一個根本概念就是將一個源地址認為是一個用戶，但凡同一個源地發送過來的連接，則認為是同一個用戶發起的多個請求，根據會話保持策略，將這些連接/請求都轉發到同一臺效勞器。當一個新的連接請求發送到虛擬效勞后，首先查找源地址會話保持表，如果在源地址會話保持表中查詢到了該請求發起的源地址對應的效勞器，則直接將該請求轉發到相應的效勞器上，如果在源地址會話保持表中沒有查詢到相應的條目，則按照負載均衡算法將請求轉發到相應的效勞器，同時，將該請求發起的源地址和對應的效勞器地址添加到源地址會話保持表中。這樣，下次同一IP地址再發起新建連接到該虛擬效勞時，則在源地址會話保持表中已經存在相應的條目，新的連接則會根據源地址會話保持表的對應項轉發到對應的效勞器上。源地址會話保持同時還存在有一個超時時間參數。每次有有新建連接請求或已建立的連接中有數據在傳輸時，就會刷新會話保持表中的超時時間。比方設置源IP會話保持的超時時間為300秒，則對于同一個源IP，只要有新建連接或已建連接有數據傳輸，則在源地址會話保持表中的超時時間一直刷新為0。當沒有新建連接或者數據傳輸時，該值就開場按秒進展累加，一旦超出300秒沒有新建連接請求或沒有數據傳輸。則將其條目從源地址會話保持表中去除。如果該IP地址在在過了超時時間之后又有新的連接請求，則以第一次連接請求按照負載均衡的算法進展處理，此時，源地址會話保持表中的超時時間又從0開場計算。1．6．3哈希會話保持哈希會話保持的一個根本概念就是將一個連接中的源IP和目的IP地址進展Hash計算，根據計算得到的結果并根據后臺存在多少臺效勞器來選擇將請求分配到那臺效勞器。哈希會話保持的特點是在后臺效勞器的安康狀態不發生改變的時候，每個特定的源IP地址被分配到的效勞器是固定的。并且，哈希會話保持可以沒有會話保持表，而僅僅是根據計算的結果來確定一個源IP被分配到那臺效勞器。哈希會話保持通常被用于一些特定場合，如要求客戶端按照IP地址被固定分配的場合，或者在一些會話保持表查詢的開銷已經遠遠大于Hash計算開銷的情況下，采用hash會話保持可以提高系統的處理能力和響應速度。在實際的應用場景中，針對后臺采用Cache效勞器的情況，還有對URL進展Hash的處理方式，將同一個URL的請求分配到同一臺Cache效勞器，這樣，對后臺的Cache效勞器群組來說，每臺Cache效勞器上存放的容都是不一樣的，提高Cache效勞器的利用率。1．6．4Cookie會話保持.Cookie是在瀏覽器訪問WEB效勞器的*個資源時，由WEB效勞器在響應消息頭中附帶傳送給瀏覽器的一片數據，WEB效勞器傳送給各個客戶端瀏覽器的數據是可以各不一樣的。瀏覽器可以決定是否保存這片數據，一旦WEB瀏覽器保存了這片數據，則它在以后每次訪問該WEB效勞器時，都應在請求頭中將這片數據回傳給WEB效勞器。顯然，Cookie最先是由WEB效勞器發出的，是否發送Cookie和發送的Cookie的具體容，完全是由WEB效勞器決定的。例如，用一個Cookie來標識訪問者的，有效時間等。CookieInsert會話保持模式因為Cookie被如此廣泛的使用，特別是SessionCookie技術，根本上在所有的電子商務中都在使用這種技術。因此，在BIG-IPLTM中可以通過插入自己可識別的Cookie來實現會話保持。當客戶進展第一次請求時，客戶請求〔不帶cookie〕進入BIG-IPLTM，BIG-IPLTM根據負載均衡算法策略選擇后端一臺效勞器，并將請求發送至該效勞器，后端效勞器進展回復〔不帶cookie〕被發回BIG-IPLTM，然后BIG-IPLTM插入cookie，將回復返回到客戶端。當客戶請求再次發生時，客戶請求〔帶有上次BIG-IPLTM插入的cookie〕進入BIG-IPLTM，然后BIG-IPLTM讀出cookie里的會話保持數值，將請求〔帶有與上面同樣的cookie〕發到指定的效勞器，然后后端效勞器進展請求回復，由于效勞器并不寫入cookie，響應將不帶有cookie，效勞器響應再次經過進入BIG-IPLTM時，BIG-IPLTM再次寫入更新后的會話保持cookie。1．7安康檢查安康檢查是負載均衡處理中一個非常重要的環節。負載均衡的主要作用就是將客戶端的請求分配到多臺效勞器上，如果沒有安康檢查，在后臺效勞器發生故障的時候，局部的客戶端將會被分配到故障的效勞器上，從而導致用戶的訪問失敗。在一些情況下，甚至可能出現效勞器本身還在工作，但其上運行的應用系統已經故障導致無法處理請求，都將會導致用戶的請求失敗。在BIG-IPLTM上應當能檢查到這些故障，并在進展負載均衡的時候將這些故障的效勞器進展自動摘除，保證應用的持續性和高可用性。1．7．1基于ICMP的安康檢查基于ICMP的安康檢查屬于最根本的安康檢查方式，BIG-IPLTM主動給效勞器發送一個ICMP(互聯網控制信息協議)數據包，如果BIG-IPLTM收到了效勞器的正確響應，則說明檢查成功。ICMP安康檢查通常用于網關類型設備的安康檢查，如防火墻、路由器等。這些設備通常不提供其他的安康檢查手段，因此ICMP屬于最正確的檢查方式。另外，在一些無法使用高級安康檢查手段的情況下，也只能使用ICMP安康檢查手段。1．7．2基于TCP端口的安康檢查在基于TCP協議的應用中，每個應用系統都會綁定一個TCP端口，應用通過偵聽這個端口承受客戶端的請求。比方我們常見的80端口在默認情況下就是效勞于效勞，通常為IIS、Apache等應用系統使用，另外還有FTP〔20、21〕、S〔443〕、SMTP〔25〕、POP3〔110〕等。判斷這些應用系統是否在工作最簡單的方法就是從BIG-IPLTM和對應的效勞器端口做一次完整的TCP握手，如果TCP握手成功，則認為效勞器正常工作，如果握手失敗，在超過一定的檢查次數均握手失敗的情況下，BIG-IPLTM則將失敗的效勞器標記為Down，而將新的客戶端請求都發送到其他仍然正常工作的效勞器上。在TCP安康檢查中還可能出現的一種情況就是在頻繁檢查的情況下，安康檢查的流量可能導致一些比擬“脆弱〞的應用系統產生故障。通常有兩種情況會出現這種故障情況：1.效勞器的Socket偵聽程序不完善，對于TCP安康檢查沒有正確關閉連接2.效勞器對每個試圖連接都進展log，最后整個應用系統的Log都被安康檢查的連接所充滿。而導致磁盤空間溢出或者正常的log信息無法觀察。在這種情況下，有兩種解決方式：1.采用TCPhalfopen的方式進展安康檢查，所謂TCPhalfopen就是BIG-IPLTM向效勞器發送一個Syn數據包，一旦受到來自該效勞的Syn-ACK數據包，則認為該效勞正常工作，然后立即發送一個RESET數據包到效勞。在一些情況下，這種TCP半連接模式并不會被記錄下來。2.采用基于代理的安康檢查，即在效勞器上另外編寫一個進程，專門用于安康檢查使用，專用的安康檢查進程將會負責BIG-IPLTM的安康查詢，而保護主進程的不受干擾的運行。1．7．3基于應用協議的安康檢查由于在ICMP、TCP端口和UDP端口的安康檢查中，我們都不一定能確認效勞器的真實工作狀態。在實際中經常有可能出現這樣的情況：效勞器IP地址還可以ping，但是應用效勞已經crash了應用效勞還在監聽80端口，但是已經不接收任何請求了應用效勞仍然接收請求，但是每次都返回503效勞器部錯誤這種效勞已經不正常，但是端口仍在監聽的情況，在一些非關鍵業務上還可以容忍，但在一些關鍵業務的應用中就不可承受了。以協議為例，基于協議的安康檢查過程如下：BIG-IPLTM發起一個請求到效勞器，請求特定的資源效勞器進展回應BIG-IPLTM在返回的容中查找一個關鍵字，如果存在該關鍵字，則認為Web效勞器正常工作中。協議層的安康檢查通常用于應用效勞器的安康檢查，如WebLogic、WebSphare、Tomcat等。和IIS、Apache效勞相比，這些應用效勞器出現故障的幾率通常較大。而且最容易出現端口仍然在偵聽，但應用已經不工作的情況。典型的基于應用協議的安康檢查通常還有：FTP:由BIG-IPLTM向FTP效勞器發起FTP請求，在驗證用戶名和密碼后，下載一個文件〔通常不會保存這個文件〕，如果文件下載成功，則認為效勞器工作正常。這樣整個FTP效勞器的用戶認證、磁盤存儲連接等效勞都進展了檢查。DNS:由BIG-IPLTM向DNS效勞器發起一個DNS請求，請求特定的域名，并檢查返回的結果，如果正確，則認為效勞器工作正常。S:由BIG-IPLTM向S發起一個S請求，通常，在S的安康檢查中可能還需要配置客戶端證書等，在效勞器響應返回后，在返回的數據中查找特定的字符串，如果匹配成功，則認為S效勞器工作正常。POP3：由BIG-IPLTM向POP3效勞器發起一個請求，并進展用戶名和密碼驗證。如果登陸成功，則認為POP3效勞器工作正常。SMTP：由BIG-IPLTM向SMTP效勞器發送一個標準的SMTP請求，如果效勞器按照標準SMTP響應返回HELO或QUIT，則認為SMTP效勞工作正常。通常情況下，SMTP安康檢查在發送請求的時候還需要指定域名。數據庫：由BIG-IPLTM向數據庫效勞器發起一次數據庫查詢請求，然后判斷數據庫效勞器返回的結果中是否包含特定的字符串，如果匹配成功，則認為數據庫效勞器工作正常。二、F5BIG-IPLTM日常維護2．1F5BIG-IPLTM外觀F5在設備前面板上劃清楚顯不同的三個區域，最左側設計有failover和console接口；中部為各種網絡接口；最右側為液晶屏幕、狀態顯示燈、6個控制按鈕及F5的紅色logo燈泡。面板前部設計有冷風入口。電源設計在設備的尾部以方便機架上電源線接入，設備產生的熱量從尾部的熱風出口散出。1.管理口2.USB接口3.Console口4.Failover口5.10/100/1000自適應接口6.SFP接口7.指示燈8.液晶屏9.液晶屏控制按鈕1.電源模塊一2.電源模塊二3.散熱風扇通過LCD按鍵修改管理網口IP地址的方法如下：1. 按紅色*按鍵進入Options選項；2. 在液晶面板上通過按鍵按以下順序設置管理網口的網絡地址：Options->System->IPAddress/Netmask->mit2．2F5BIG-IPLTM配置備份和恢復可以通過以下WEB界面進展配置的備份與修改：進入System"Archives，點擊Create：配置備份好后，點擊設配置文件并下載到外部電腦上：恢復系統時點擊Restore如果是需要一個完全干凈的系統，建議通過重裝系統來恢復到出廠設置。如果沒方法重裝系統，但需要將配置清空以重新進展配置，方法如下：從管理網口用命令行登陸BIG-IP，然后執行以下命令：*bdballreset*breset*bsave*bbasereset*bbasesave2．3F5BIG-IPLTM性能狀態2．3．1F5BIG-IPLTM實時連接狀態在命令行模式輸入：bconn查看當前端口的狀態查看當前node信息查看pool狀態查看當前VS信息2．3．2F5BIG-IPLTM性能狀態查看當前F5性能狀態通過WEB頁面，Overview選項卡中的Performance查看當前F5BIG-IPLTM的主備狀態查看當前F5BIG-IPLTM的組件狀態命令行模式：bplatform查看當前F5BIG-IPLTMTOP狀態命令行模式：bigtop查看F5BIG-IPLTMTMM存狀態命令行模式：bmemoryshow2．3．3F5BIG-IPLTM告警日志通過WEBSystem選項中的logs或者在命令行模式輸入more/var/log/messages查看F5系統日志more/var/log/ltm查看member和node狀態日志收集F5BIG-IPLTM后臺錯誤日志提交F5官方分析命令行模式輸入：三、F5BIG-IPLTM效勞配置3．1F5BIG-IPLTM創立用戶通過WEB界面，在System選項卡中選擇UsersCreate3．2F5BIG-IPLTM開啟本地效勞選擇*效勞，start即可注：ntpd效勞需要在命令行模式修改vi/etc/ntp.conf中，增加ntpserver3．3手動切換主備狀態3．4修改admin和root密碼3．5安康檢查的管理和維護根據需求選擇類型以為例命名規則：類型_端口號，如_8001Interval：間隔時間，即為安康檢查效勞向節點發送兩次檢查數據包的間隔時間。Timeout：超時時間，即為安康檢查效勞向節點發送安康檢查數據包沒有回執的超時時間。SendString和ReceiveString：F5會向節點發送SendString中的容，如果回執與ReceiveString中的容一致，則視為該節點正常。該功能需要有應用人員提供相應的代碼。也可以為空。AliasServicePort：指定效勞8001端口3．6pool的管理和維護Pool命名規則：pool_〔地市名〕_系統名〔用途〕，如：pool_oa，pool_anqing_oajkHealthMonitors：指定該pool的安康檢查ActionOnServiceDown：節點中效勞down了以后的處理方式，一般這里都選擇轉發〔Reselect〕LoadBalancingMethod：負載均衡的方式，根據需求，一般我們選擇RoundRobin。NewMember：這里參加需要負載均衡的應用節點。后續增加pool中的節點在Pool列表選擇*個Pool，點擊列表上的Members個數，或點擊Pool名稱后，選擇Members頁簽在Member列表，點擊右上方的Add按鈕，出現添加頁面填寫ip和端口，configuration選擇Advanced，選擇monitors,效勞選擇，其他效勞選擇tcp〔根據具體情況〕，點擊Finished按鈕添加完成。如果要移除pool下的節點，可以在pool的列表界面，選中節點，直接點delete，沒有確認。3．7VS的管理和維護VS命名規則：vs_〔地市〕_系統用途，例如：vs_oajk，vs_anqing_jtjkDestination：對外提供效勞的IPServicePort：對外提供效勞的端口如果是效勞，profile需要選上OneConectProfile：鏈路復用的功能，如果是用cookiesinster的會話保持方式時，這一項必須選擇oneconnect。或者有會話保持的長連接也需要開啟這個功能。SNATPool：必須選擇AutoMap如果VS只提供單一的效勞，不需要irules做條件判斷，DefaultPool就選擇相應的效勞節點。如果VS需要有irules做條件判斷，來轉發vs下屬的多個pool，則DefaultPool選擇none。3．8iRules管理和維護iRules運用TCL運行引擎執行腳本。能夠對流量直接操控和對任意IP應用流量的管理。iRules命名規則：iRules_效勞名稱，如：iRules_oajk網廳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