F5 BIG-IP LTM 詳解(工作原理 配置手冊)_第1頁
F5 BIG-IP LTM 詳解(工作原理 配置手冊)_第2頁
F5 BIG-IP LTM 詳解(工作原理 配置手冊)_第3頁
F5 BIG-IP LTM 詳解(工作原理 配置手冊)_第4頁
F5 BIG-IP LTM 詳解(工作原理 配置手冊)_第5頁
已閱讀5頁,還剩91頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、F5 BIG-IP LTM詳解,北京先進(jìn)數(shù)通信息技術(shù)有限公司,2020年9月,LTM基礎(chǔ)架構(gòu) VS Type詳解 Profile詳解 CMP 工作原理 One Connect工作原理 NAT、SNAT工作原理 Monitor工作原理 HA工作原理,LTM工作原理,LTM基礎(chǔ)架構(gòu),什么是TMM,Traffic Management Module TMOS的核心進(jìn)程,有自己獨(dú)立的內(nèi)存、CPU資源分配和I/O控制 所有的生產(chǎn)流量都通過TMM接收 一個CPU Core只能有一個TMM進(jìn)程 在V9版本上,15/34/64/68都是單TMM運(yùn)行 在V9版本上,16/36/69/89/84/88都是多TMM

2、運(yùn)行 在V10版本上,16/36/69/89/84/88都是多TMM運(yùn)行 Viprion只支持9.6和10.0版本,默認(rèn)都是多TMM運(yùn)行,TMM處理的范圍,TMM內(nèi)部處理功能,所有的VS入口流量 LTM iRiules處理 Profile處理 會話保持處理 負(fù)載均衡算法 SSL加速(和硬件結(jié)合) HTTP 壓縮 SNAT 靜態(tài)CRL( Certificate revocation list 證書吊銷清單)文件校驗(yàn),不在TMM里面處理的功能,Web Accelerator Module(包括壓縮) Application Security Module GTM的分配算法處理(包括GTM rule

3、s) Named域名解析 健康檢查 日志管理 系統(tǒng)數(shù)據(jù)統(tǒng)計 SNMP數(shù)據(jù)輸出 HA健康檢查,BIGIP 內(nèi)部結(jié)構(gòu)-V9平臺15/34/64/68,TM/OS,管理CPU,萬兆/千兆交換端口,PVA(Packet Velocity ASIC) 四層交換專用ASIC,Host OS Web 界面管理 健康檢查 SNMP .,Bridge,TMM 0,獨(dú)立的管理機(jī) SCCP,SSL加解密,HTTP壓縮,Admin,Console,BIGIP 內(nèi)部結(jié)構(gòu)-Mecury平臺16/36/69/89,6,TM/OS,管理CPU,萬兆/千兆交換端口,HiSpeed Bridge,TMM 2,Host OS We

4、b 界面管理 健康檢查 SNMP .,TMM 3,TMM 1,TMM 0,獨(dú)立的管理機(jī) AOM,Cluster Muti Processor多CPU并行處理,SSL加解密,HTTP壓縮,Console,Admin,Host和TMM的內(nèi)存分配,Host在啟動的時候限 定了內(nèi)存分配的大小 ,在沒有其他module 的情況下是384MB TMM進(jìn)程啟動后,將 自動獲取余下的所有 物理內(nèi)存,Host Memory,TMM Memory,查看Host內(nèi)存占用情況,# physmem /查看物理內(nèi)存大小 8387584 b memory show /查看內(nèi)存分配情況 MEMORY STATISTICS -

5、 | (Host) Total = 3.835GB Used = 3.590GB | (TMM) Total = 5.976GB Used = 93.22MB,查看TMM內(nèi)存占用情況,TMM分配的內(nèi)存是準(zhǔn)確的,Host內(nèi)存顯示在這里有一些偏差,VS Type詳解,Performance L4 Standard VS Fast HTTP Forwarding VS,Performance L4,TMM只是負(fù)責(zé)客戶端連接的分配和轉(zhuǎn)發(fā),不改變TCP連接中的任何參數(shù) 客戶端和服務(wù)器自行協(xié)商TCP傳輸參數(shù) 在34/64/68平臺上Performance L4可以有PVA加入實(shí)現(xiàn)硬件加速 在15/16/3

6、6/69/89/Viprion平臺上都通過TMM核心進(jìn)行處理 Performance L4 VS上只有4層的iRules可以使用 默認(rèn)狀態(tài)下,新建連接的第一個包必須是Syn包,如果是其他的數(shù)據(jù)包比如ACK、RST等如果不在連接表中,則全部丟棄。 在Fast L4 profile打開Loose close和Loose Initial的時候?qū)Ψ荢yn包也可以建立連接表,TMM,客戶端,客戶端,客戶端,服務(wù)器端,服務(wù)器端,服務(wù)器端,Performance L4 攻擊防護(hù)-Syn Cookie,正常情況下客戶端連接和服務(wù)器端連接是1:1的關(guān)系 TMM在第一次收到客戶端Syn包時,并不建立連接表 TMM

7、的Syn Ack回應(yīng)通過算法回應(yīng)給客戶端Syn,并期待客戶端回應(yīng)的值 TMM對客戶端ACK進(jìn)行計算,確認(rèn)是真實(shí)客戶端,再和后臺服務(wù)器建立連接 在84/88上可以實(shí)現(xiàn)硬件的Syn Cookie計算,其余的平臺都是通過軟件實(shí)現(xiàn)SynCookie計算 Syn Cookie工作模式下,只有成功建立連接的TCP請求才轉(zhuǎn)發(fā)到后臺,TMM,Syn,Syn,Ack (syncookie),Ack(Cookie),Syn,Syn-Ack,Ack,Data,Standard VS,正常情況下客戶端連接和服務(wù)器端連接是1:1的關(guān)系 默認(rèn)工作在全代理模式,客戶端和服務(wù)器端的TCP連接完全獨(dú)立 客戶端和服務(wù)器端的TCP

8、參數(shù)都是由TMM和雙方分別協(xié)商 默認(rèn)情況下以客戶端源IP和后臺建立連接,在打開SNAT的情況下用SNAT地址和后臺建立連接 Standard VS的端口永遠(yuǎn)對外開放,無論后臺是否有服務(wù)器在工作,TMM,Syn,Syn,Ack,Ack,Syn,Syn-Ack,Ack,Data,Data,Standard 模式下的攻擊防護(hù),Standard VS模式具有天然的防攻擊功能 在遇到Syn攻擊的時候會導(dǎo)致系統(tǒng)的連接表過大 通過System-SYN Check Activation Threshold 的設(shè)置,在達(dá)到設(shè)置值的時候系統(tǒng)自動啟動 Syn Cookie,避免建立過多連接,這個值對全局生效 大部分

9、的網(wǎng)絡(luò)層攻擊都無法通過Standard模式的VS,Fast HTTP,Fast HTTP VS僅用于HTTP協(xié)議 默認(rèn)開啟One Connect Profile,對客戶端連接進(jìn)行聚合處理 默認(rèn)開啟SNAT AutoMap,在服務(wù)器端收到的TCP連接請求都是來自于TMM 沒有會話保持功能 不能處理SSL,HTTPS,TMM,客戶端,客戶端,客戶端,服務(wù)器端,服務(wù)器端,服務(wù)器端,Fowarding VS(Forwarding IP),只能使用Fast L4 Profile 按照連接處理,類似于路由器工作,但不完全一樣,在Fast L4 Profile中開啟Loose Initial和Loose C

10、lose之后更為接近路由工作模式 所有穿過Fowarding VS的連接都將產(chǎn)生連接表 沒有Pool Member,轉(zhuǎn)發(fā)完全取決于本地路由 可以使用基于4層的Rules,TMM,客戶端,查詢本地路由表,轉(zhuǎn)發(fā)客戶端請求,VS和Profile,VS作為所有流量的入口 Profile依賴于VS,對進(jìn)入VS的流量進(jìn)行格式化處理 不同的VS可以用同一個Profile或者不同的Profile Profile之間存在有相互排斥和相互依存的關(guān)系,VS,TCP Profile,UDP Profile,FastL4 Profile,HTTP,RTSP,Client SSL,Server SSL,Streaming

11、,SMTP,SIP,One Connect,Rules的處理必須依賴于VS對流量的接收 通過事件觸發(fā)機(jī)制,Rules可以控制流量在VS內(nèi)部處理的整個過程,SSL,Compression,Client Side,Server Side,TCP Express,Server,TCP Express,Caching,Microkernel,Virtual Server,iRules,Client,iControl API,TCP Proxy,OneConnect,XML,Rate Shaping,TrafficShield,Web Accel,3rd Party,VS和Rules,Server,iR

12、ules,Client Side Event Client_accept Client_data Cache_request DNS_request HTTP_REQUEST HTTP_REQUEST_DATA RTSP_REQUEST . . . .,Server Side Event Server_connect Server_data Cache_response DNS_response HTTP_RESPONSE HTTP_RESPONSE_DATA RTSP_RESPONSE . . . .,大部分rules只在同一個VS之內(nèi)有效 Rules內(nèi)創(chuàng)建的變量以連接為生命周期 一個VS上

13、可以有多個Rules,它們將被順序執(zhí)行,CLIENT_ACCPTED,CLIENT_DATA,LB_SELECTED,LB_FAILED,SERVER_ACCPTED,SERVER_DATA,CLIENT_CLOSED,SERVER_CLOSED,RULE_INIT,VS,Profile的作用和工作范圍,Profile依賴于VS Profile是對VS的流量進(jìn)行格式化處理 舉例如果一個VS上配置了TCP Profile, 則該VS對所有的UDP流量都不會接收,Profile詳解,基本流量處理類型Profile TCP, UDP, FastHTTP, Fast L4, SCTP( Stream

14、Control Transmission Protocol ) 服務(wù)流量處理類型Profile HTTP, FTP, SMTP, RTSP( Real Time Streaming Protocol ), SIP( Session Initiation Protocol ), iSession SSL處理類型 Client SSL,Server SSL 會話保持類型 Cookie, Destination IP, hash, msrdp, source IP, Universal, SSL 認(rèn)證處理類型 Radius, CRLDP( Constraint-Based Label Distrib

15、ution Protocol ), OCSP( Online Certificate Status Protocol ) 其他處理類型 One Connect, Statistics, NTLM( NT LAN Manager ), Stream,重要的Profile-FastL4,Reset on Timeout: 在連接達(dá)到Time out的是否向兩端發(fā)送Reset包 Idel Timeout:多長時間連接里面沒有數(shù)據(jù)流量的時候就刪除連接表 Loose Initiation/Loose Close: 是否接收非Syn包建立連接 Softare Syn Cookie Protection:是

16、否在VS上啟用Syn Cookie,實(shí)現(xiàn)Syn攻擊防護(hù),可能調(diào)整的參數(shù),重要的Profile-TCP,注意在Client Side和Server Side可以使 用不同的TCP Profile 通常情況下建議: Client side:TCP WAN Optimized 或LAN Optimized Server side: TCP LAN Optimized 除非你非常了解TCP的工作原理,否則不 要調(diào)整除idel Timeout以外的任何參數(shù),重要的Profile-Client SSL,對所有進(jìn)入VS的流量按照SSL協(xié)議進(jìn)行處理 注意Client SSL profile不一定只能使用在HT

17、TPS上 使用Client SSL的VS不一定使用443端口,TMM,客戶端,客戶端,客戶端,服務(wù)器端,服務(wù)器端,服務(wù)器端,SSL,SSL,SSL,重要的Profile-FTP,FTP Profile主要用于處理FTP的主動 和被動傳輸兩種模式 由于需要配置動態(tài)偵聽端口,因此FTP 協(xié)議必須進(jìn)行單獨(dú)處理 通過iRules也可以達(dá)到同樣的目的,但 由于FTP協(xié)議使用非常廣泛,因此使用 FTP profile來簡化配置和處理 FTP Profile必須依賴于TCP profile工作,為什么要用CMP(Cluster Multi-Processor),性能增長要求 CPU的主頻增加受到比較大的限制

18、,目前的趨勢是以多 核擴(kuò)展為主 ASIC(Application Specific Intergrated Circuits)、NP(Network Processor)的處理架構(gòu)并不適合于復(fù)雜、靈活的流量處理 對于不規(guī)范的流量,采用硬件加速將導(dǎo)致系統(tǒng)設(shè)計僵化, 很難加入新的功能實(shí)現(xiàn)市場需求 需要充分利用CPU的多核處理能力來提升系統(tǒng)的整體性能,CMP工作原理,CMP的硬件支持,CMP工作模式,流量由HSB進(jìn)行分配在多個TMM上,每個TMM占據(jù)一個CPU Core,每個TMM有自己獨(dú)立的內(nèi)存空間 每個TMM都具有相同的配置,包括VS/Profile/iRules/Pool/Persistenc

19、e等 TMM之間通過內(nèi)存高速總線進(jìn)行通訊共享通用信息如會話保持表,SNAT源端口等 當(dāng)CMP被Disable的時候,TMM0接管所有的流量 64/68的硬件平臺已經(jīng)支持CMP,在10.0上自動開啟,VIP TMM0,VIP TMM1,VIP TMM2,VIP TMM3,HSB,HSB,Super VIP,如何查看CMP工作狀態(tài),b tmm show可以觀察每個TMM的狀態(tài),關(guān)于CMP必須了解的內(nèi)容,V9平臺啟動WA(web應(yīng)用加速器)和ASM(應(yīng)用安全 管理器)將Disable CMP iRules中定義全局變量將Disable CMP 所有的非TCP/UDP流量都只使用TMM0進(jìn)行處理 V9

20、中使用Session add, Session Lookup命令將 Disable CMP Connection Limit和Rate Shaping的配置是針對每 個TMM生效 手工關(guān)閉CMP運(yùn)行 b db Provision.tmmCount 1 調(diào)整后必須重啟 任何一個TMM Crash,將導(dǎo)致設(shè)備間Failover TCPdump已經(jīng)調(diào)整為可支持CMP,查看Virtual Server的CMP工作狀態(tài),如何查看TMM CPU占用率,top命令可以顯示每顆CPU的占用率 和V9相比,TMM的CPU在Top命令中的顯示發(fā)生了變化 每顆CPU的CPU占用率目前在圖形界面里都消失了,目前只有

21、整體的CPU占用率,One Connect工作原理,連接聚合和內(nèi)容交換,sales.htm,d.gif,e.gif,index.htm,a.gif,b.gif,c.asp,Server,f.asp,sales.htm,d.gif,e.gif,index.htm,a.gif,b.gif,c.asp,Server,f.asp,index.htm,a.gif,b.gif,c.asp,index.htm,a.gif,b.gif,c.asp,HTML server pool,GIF server pool,ASP server pool,連接聚合,內(nèi)容交換,注:eligible reuse 符合條件的再

22、利用,One Connect的典型工作場景,實(shí)現(xiàn)連接聚合降低服務(wù)器的連接總數(shù) 需要對每一個請求都進(jìn)行單獨(dú)處理(注意在多數(shù) 情況下,LTM只對一個連接的第一個包進(jìn)行處理) 典型的,打開Cookie會話保持有時候會出現(xiàn)保持 不正確的情況,這時就需要打開One Connect 通過設(shè)置Mask=55,可以使后臺服 務(wù)器可以“看到”客戶端源IP,但這個時候 One-connect只對一個客戶端的連接起作用,One Connect和應(yīng)用協(xié)議,注意! One Connect Profile不是必須和HTTP Profile 共用,也可以用于其他應(yīng)用協(xié)議。 用于其他應(yīng)用協(xié)議的時候必

23、須使用iRules編程 來調(diào)用One Connect 在需要對長連接進(jìn)行拆分處理的時候,也需要用 One Connect Profile,NAT的工作模式,0,NAT Address: 0,NAT和SNAT,SNAT全稱:Secure Network Address Translation,SNAT的工作模式,0,,,,SNAT Address: 0,NAT和SNAT之間的差別,NAT 1比1 接收所有發(fā)往NAT地址的連接 所有的連接

24、只是通過LTM的連接表管理,但是是無狀態(tài)的,連接不會被Timeout 連接不能被鏡像,SNAT 多對一或者多對多 拒絕所有發(fā)往SNAT地址的連接請求. 連接通過LTM的連接表管理,有timeout設(shè)置 連接可以被鏡像,SNAT AutoMap,當(dāng)配置SNAT AutoMap的時候,請求從那個VLAN 發(fā)出去,則SNAT的源地址為VLAN上的SelfIP 當(dāng)一個VLAN上有多個SelfIP存在的時候,SNAT 的源地址是在多個SelfIP之間輪詢,SNAT Pool的工作模式,SNATPool是提供了一個可用于SNAT源地址的列表 BIGIP采用最小連接數(shù)的方式在SNAT的源地址之間進(jìn)行選擇,通

25、過iRules控制SNAT,when CLIENT_ACCEPTED set snat_addr when HTTP_REQUEST set snat_addr HTTP:header X-Forwarded-For log X-Fowarded-For is HTTP:header X-Forwarded-For when LB_SELECTED snat $snat_addr ,HTTPS,SSL Offload 替換源地址,Server 端需要在TCP連接里面獲取客戶端源地址,SNAT的源地址會話保持,when RULE_INIT #log local5.warning

26、-$cnc_snatpool set snat_length llength $cnc_snatpool log local5.warning -snat pool length is $snat_length when LB_SELECTED #set client_addr 3 set client_ip IP:client_addr set client_last getfield $client_ip . 4 #log local5.warning -client last is $client_last set snat_addr lindex $cnc_snatpo

27、ol expr $client_last%$snat_length #log local5.warning -client snat addr $snat_addr snat $snat_addr ,Timeout定義和鏡像,SNAT可以在兩臺設(shè)備之間鏡像 SNAT對于TCP idle Timeout 和UDP idle Timeout可以有獨(dú)立的設(shè)置,Monitor如何向外發(fā)送請求,所有的Monitor請求都是由bigd進(jìn)程發(fā)起 Monitor流量要穿過TMM發(fā)送到Server或者其他位置 在b conn中可以看到Monitor的流量,TMM,bigd,Monitor工作原理,重要的Moni

28、tor-TCP,Send String: 發(fā)送的請求字符串,支持C語言 的轉(zhuǎn)義符 Receive String:在返回的內(nèi)容中查詢的字符串 Transparent:數(shù)據(jù)包內(nèi)的三層發(fā)送目的地是 Alias Address,二層的發(fā)送目的地是 Node Address的MAC地址,重要的Monitor-External Monitor,MEMBER=$1; PORT=$2; HOST_2_RESOLV=$3; $# -ne 3 & exit 255 PIDFILE=/var/run/pinger.$MEMBER.eav.$PORT.pid if -f $PIDFILE then kill -9 c

29、at $PIDFILE /dev/null 2&1 fi echo $ $PIDFILE MEMBER=echo $1 | sed s/:ffff:/ 2/dev/null log_info() echo $* | logger -p # # stock syslog-ng destinations - # - /var/log/ltm # - /var/log/ltm # - /var/log/messages # - /var/log/messages # this is for

30、 debug only! do not call log_info below unless # you want to see your syntax and the shell evaluation of # variables (variable exansion) ,HA工作模式-Active/Active,每個VS對外提供不同的服務(wù) 服務(wù)器必須分組,分別指不同的網(wǎng)關(guān) 在使用SNAT的情況下不需要服務(wù)器指不同的網(wǎng)關(guān)(建議模式),VS 1,VS 2,HA工作原理,串口心跳線的工作模式,沒有數(shù)據(jù)在串口心跳線之間傳輸 兩臺設(shè)備是通過監(jiān)控Failover 線上的電壓來決定是否切 換,備機(jī)一旦檢

31、測到主機(jī)電壓為0則進(jìn)行接管動作 切換時間在200-300毫秒之間 SOD(Switch Over Deamon)進(jìn)程負(fù)責(zé)監(jiān)控Failover線上 的電壓,網(wǎng)絡(luò)心跳線的工作模式,兩臺設(shè)備之間通過網(wǎng)絡(luò)互相發(fā)送心跳信號 Network Failover 可以設(shè)置2條路徑 Network Failover和串口心跳線Failover可以同時使用 在10.0里的Network Failover有巨大的變化,靜態(tài)負(fù)載均衡算法 輪詢,比率,優(yōu)先權(quán) 動態(tài)負(fù)載均衡算法 最少連接數(shù),最快響應(yīng)速度,觀察方法,預(yù)測法,動態(tài)性能分配,動態(tài)服務(wù)器補(bǔ)充,服務(wù)質(zhì)量,服務(wù)類型,規(guī)則模式,F5負(fù)載均衡算法,輪詢(Round Ro

32、bin):順序循環(huán)將請求一次順序循環(huán)地連接每個服務(wù)器。 當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG-IP 就把其從順序循環(huán)隊列 中拿出,不參加下一次的輪詢,直到其恢復(fù)正常。,比率(Ratio):給每個服務(wù)器分配一個加權(quán)值為比例,根椐這個比例,把用戶的請求分配到每個服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG-IP 就把其從服務(wù)器隊列中拿出,不參加下一次的用戶請求的分配, 直到其恢復(fù)正常。,優(yōu)先權(quán)(Priority):給所有服務(wù)器分組,給每個組定義優(yōu)先權(quán),BIG-IP 用戶 的請求,分配給優(yōu)先級最高的服務(wù)器組(在同一組內(nèi),采用輪詢或比率算法, 分配用戶的請求);當(dāng)最高優(yōu)先級中所

33、有服務(wù)器出現(xiàn)故障,BIG-IP 才將請求 送給次優(yōu)先級的服務(wù)器組。這種方式,實(shí)際為用戶提供一種熱備份的方式。,最少的連接方式(Least Connection):傳遞新的連接給那些進(jìn)行最少連接處理的服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG-IP 就把其從服務(wù)器隊列中拿出,不參加下一次的用戶請求的分配, 直到其恢復(fù)正常。,最快模式(Fastest):傳遞連接給那些響應(yīng)最快的服務(wù)器。當(dāng)其中某個服 務(wù)器發(fā)生第二到第7 層的故障,BIG-IP 就把其從服務(wù)器隊列中拿出,不參加 下一次的用戶請求的分配,直到其恢復(fù)正常。,觀察模式(Observed):連接數(shù)目和響應(yīng)時間以這兩項的最佳平衡為

34、依據(jù) 為新的請求選擇服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG-IP 就把其從服務(wù)器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復(fù) 正常。,預(yù)測模式(Predictive):BIG-IP利用收集到的服務(wù)器當(dāng)前的性能指標(biāo), 進(jìn)行預(yù)測分析,選擇一臺服務(wù)器在下一個時間片內(nèi),其性能將達(dá)到最佳的 服務(wù)器響應(yīng)用戶的請求。(被BIG-IP 進(jìn)行檢測),動態(tài)性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應(yīng)用 程序和應(yīng)用服務(wù)器的各項性能參數(shù),動態(tài)調(diào)整流量分配。 動態(tài)服務(wù)器補(bǔ)充(Dynamic Server Act.):當(dāng)主服務(wù)器群中因 故障導(dǎo)致數(shù)量減少時,動態(tài)地將備份

35、服務(wù)器補(bǔ)充至主服務(wù) 器群。 服務(wù)質(zhì)量(QoS):按不同的優(yōu)先級對數(shù)據(jù)流進(jìn)行分配。 服務(wù)類型(ToS): 按不同的服務(wù)類型(在Type of Field中標(biāo)識) 對數(shù)據(jù)流進(jìn)行分配。 規(guī)則模式:針對不同的數(shù)據(jù)流設(shè)置導(dǎo)向規(guī)則,用戶可自行。,常用到的一般是最少連接數(shù)、最快反應(yīng)、或者輪詢,決定選用那種算法, 主要還是要結(jié)合實(shí)際的需求,F5會話保持,F5 BigIP支持多種的會話保持方法,其中包括:簡單會話保持(源地址會 話保持)、HTTP Header的會話保持,基于SSL Session ID的會話保持, I-Rules會話保持以及基于 HTTP Cookie的會話保持,此外還有基于SIP ID 以及

36、Cache設(shè)備的會話保持等,但常用的是簡單會話保持,HTTP Header 的會話保持以及 HTTP Cookie會話保持以及基于I-Rules的會話保持。,簡單會話保持 簡單會話保持又稱為基于源地址的會話保持,是指負(fù)載均衡器在作負(fù)載均衡時是根據(jù)訪問請求的源地址作為判斷關(guān)連會話的依據(jù)。對來自同一IP地址的所有訪問請求都會被保持到一臺服務(wù)器上去。 簡單會話保持一個很重要的參數(shù)就是連接超時值,BIGIP會為每一個進(jìn)行會話保持的會話設(shè)定一個時間值,兩次會話之前的間隔如果小于這個超時值,BIGIP將會將新的連接進(jìn)行會話保持,但如果這個間隔大于該超時值,BIGIP會將新來的連接認(rèn)為是新的會話然后進(jìn)行負(fù)載

37、平衡。 基于原地址的會話保持實(shí)現(xiàn)簡單,效率較高。但是多個用戶通過代理或地址轉(zhuǎn)換的方式來訪問服務(wù)器時,會導(dǎo)致服務(wù)器之間的負(fù)載嚴(yán)重失衡。 另外當(dāng)客戶機(jī)數(shù)量很少,但每個客戶機(jī)都產(chǎn)生多個并發(fā)訪問,這時用這種方法也會導(dǎo)致負(fù)載均衡失效。,基于Cookie的會話保持,Cookie插入模式 在Cookie插入模式下,BigIP將負(fù)責(zé)插入cookie,后端服務(wù)器無需作出任何修改。 當(dāng)客戶進(jìn)行第一次請求時,客戶HTTP請求(不帶cookie)進(jìn)入BIGIP, BIGIP根據(jù)負(fù)載平衡算法策略選擇后端一臺服務(wù)器,并將請求發(fā)送至該服務(wù)器,后端服務(wù)器進(jìn)行HTTP回復(fù)(不帶cookie)被發(fā)回BIGIP,然后BIGIP插入

38、cookie,將HTTP回復(fù)返回到客戶端。當(dāng)客戶請求再次發(fā)生時,客戶HTTP請求(帶有上次BIGIP插入的cookie)進(jìn)入BIGIP,然后BIGIP讀出cookie里的會話保持?jǐn)?shù)值,將HTTP請求(帶有與上面同樣的cookie)發(fā)到指定的服務(wù)器,然后后端服務(wù)器進(jìn)行請求回復(fù),由于服務(wù)器并不寫入cookie,HTTP回復(fù)將不帶有cookie,恢復(fù)流量再次經(jīng)過進(jìn)入BIGIP時,BIGIP再次寫入更新后的會話保持cookie。,Cookie 重寫模式 當(dāng)客戶進(jìn)行第一次請求時,客戶HTTP請求(不帶cookie)進(jìn)入BIGIP, BIGIP根據(jù)負(fù)載均衡算法策略選擇后端一臺服務(wù)器,并將請求發(fā)送至該服務(wù)器

39、,后端服務(wù)器進(jìn)行HTTP回復(fù)一個空白的cookie并發(fā)回BIGIP,然后BIGIP重新在cookie里寫入會話保持?jǐn)?shù)值,將HTTP回復(fù)返回到客戶端。當(dāng)客戶請求再次發(fā)生時,客戶HTTP請求(帶有上次BIGIP重寫的 cookie)進(jìn)入BIGIP,然后BIGIP讀出cookie里的會話保持?jǐn)?shù)值,將HTTP請求(帶有與上面同樣的cookie)發(fā)到指定的服務(wù)器,然后后端服務(wù)器進(jìn)行請求回復(fù),HTTP回復(fù)里又將帶有空的cookie,恢復(fù)流量再次經(jīng)過進(jìn)入BIGIP時,BIGIP再次寫入更新后會話保持?jǐn)?shù)值到該 cookie。,Passive Cookie 模式 服務(wù)器使用特定信息來設(shè)置cookie。當(dāng)客戶進(jìn)行

40、第一次請求時,客戶HTTP請求(不帶cookie)進(jìn)入BIGIP, BIGIP根據(jù)負(fù)載平衡算法策略選擇后端一臺服務(wù)器,并將請求發(fā)送至該服務(wù)器,后端服務(wù)器進(jìn)行HTTP回復(fù)一個cookie并發(fā)回BIGIP,然后 BIGIP將帶有服務(wù)器寫的cookie值的HTTP回復(fù)返回到客戶端。當(dāng)客戶請求再次發(fā)生時,客戶HTTP請求(帶有上次服務(wù)器寫的cookie)進(jìn)入 BIGIP,然后BIGIP根據(jù)cookie里的會話保持?jǐn)?shù)值,將HTTP請求(帶有與上面同樣的cookie)發(fā)到指定的服務(wù)器,然后后端服務(wù)器進(jìn)行請 求回復(fù),HTTP回復(fù)里又將帶有更新的會話保持cookie,恢復(fù)流量再次經(jīng)過進(jìn)入BIGIP時,BIGI

41、P將帶有該cookie的請求回復(fù)給客戶端。,Cookie Hash模式 當(dāng)客戶進(jìn)行第一次請求時,客戶HTTP請求(不帶cookie)進(jìn)入BIGIP, BIGIP根據(jù)負(fù)載均衡算法策略選擇后端一臺服務(wù)器,并將請求發(fā)送至該服務(wù)器,后端服務(wù)器進(jìn)行HTTP回復(fù)一個cookie并發(fā)回BIGIP,然后 BIGIP將帶有服務(wù)器寫的cookie值的HTTP回復(fù)返回到客戶端。當(dāng)客戶請求再次發(fā)生時,客戶HTTP請求(帶有上次服務(wù)器寫的cookie)進(jìn)入 BIGIP,然后BIGIP根據(jù)cookie里的一定的某個字節(jié)的字節(jié)數(shù)來決定后臺服務(wù)器接受請求,將HTTP請求(帶有與上面同樣的cookie)發(fā)到指定的服務(wù)器,然后后

42、端服務(wù)器進(jìn)行請求回復(fù),HTTP回復(fù)里又將帶有更新后的cookie,恢復(fù)流量再次經(jīng)過進(jìn)入BIGIP時,BIGIP將帶有該 cookie的請求回復(fù)給客戶端。,SSL Session ID會話保持 在用戶的SSL訪問系統(tǒng)的環(huán)境里,當(dāng)SSL對話首次建立時,用戶與服務(wù)器進(jìn)行首次信息交換以:1交換安全證書,2)商議加密和壓縮方法,3)為每條對話建立Session ID。由于該Session ID在系統(tǒng)中是一個唯一數(shù)值,由此,BIGIP可以應(yīng)用該數(shù)值來進(jìn)行會話保持。當(dāng)用戶想與該服務(wù)器再次建立連接時,BIGIP可以通過會話中的 SSL Session ID識別該用戶并進(jìn)行會話保持。 基于SSL Session

43、 ID的會話保持就需要客戶瀏覽器在進(jìn)行會話的過程中始終保持其SSLSession ID不變,但實(shí)際上,微軟Internet Explorer被發(fā)現(xiàn)在經(jīng)過特定一段時間后將主動改變SSL Session ID,這就使基于SSL Session ID的會話保持實(shí)際應(yīng)用范圍大大縮小。,基于HTT Header的會話保持BIGIP可以根據(jù)用戶HTTP訪問里http包頭信息信息進(jìn)行會話保持,HTTP包頭里包含以下信息,BIGIP可以將用戶訪問里這些信息通過表達(dá)式來獲得相應(yīng)的數(shù)值從而進(jìn)行會話保持。 Accept:瀏覽器可接受的MIME類型。Accept-Charset:瀏覽器可接受的字符集。Accept-E

44、ncoding:瀏覽器能夠進(jìn)行解碼的數(shù)據(jù)編碼方式,比如gzip。Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。 Accept-Language:瀏覽器所希望的語言種類,當(dāng)服務(wù)器能夠提供一種以上的語言版本時要用到。 Authorization:授權(quán)信息,通常出現(xiàn)在對服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中。 Connection:表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive”,或者看到請求使用的是HTTP 1.1(HTTP 1.1默認(rèn)進(jìn)行持久連接),它就可以利用持久連接的優(yōu)點(diǎn),當(dāng)頁

45、面包含多個元素時(例如Applet,圖片),顯著地減少下載所需要的時間。要實(shí)現(xiàn)這一點(diǎn),Servlet需要在應(yīng)答中發(fā)送一個Content-Length頭,最簡單的實(shí)現(xiàn)方法是:先把內(nèi)容寫入ByteArrayOutputStream,然后在正式寫出內(nèi)容之前計算它的大小。,Content-Length:表示請求消息正文的長度。 Cookie:這是最重要的請求頭信息之一,參見后面Cookie處理一章中的討論。 From:請求發(fā)送者的email地址,由一些特殊的Web客戶程序使用,瀏覽器不會用到它。 Host:初始URL中的主機(jī)和端口。 If-Modified-Since:只有當(dāng)所請求的內(nèi)容在指定的日期之

46、后又經(jīng)過修改才返回它,否則返回304“Not Modified”應(yīng)答。 Pragma:指定“no-cache”值表示服務(wù)器必須返回一個刷新后的文檔,即使它是代理服務(wù)器而且已經(jīng)有了頁面的本地拷貝。 Referer:包含一個URL,用戶從該URL代表的頁面出發(fā)訪問當(dāng)前請求的頁面。User-Agent:瀏覽器類型,如果Servlet返回的內(nèi)容與瀏覽器類型有關(guān)則該值非常有用。,基于I-Rules的會話保持 BIGIP交換機(jī)內(nèi)置有強(qiáng)大的搜索引擎,可以高效的探測到 網(wǎng)絡(luò)流量中的IP包內(nèi)容的部分,并可以讀出該IP包內(nèi)容部 分進(jìn)行會話保持這些內(nèi)容部分包括如下部分:,下面是一個BIGIP根據(jù)IRULES進(jìn)行會話

47、保持的范例:if (http_uri ends_with “.gif”) use pool image_serverselse if (http_uri starts_with “/foo”) use pool foo_serverselse if (http_cookie(“XYZ-Type”) = “direct”) use pool cookie_serverselse if (findstr(http_uri, “?type=”, 6, “&”) = “cgi”) use pool cgi_serverselse use pool web_servers在此I-Rules里,可以看到,

48、如果用戶的uri部分以.gif字段結(jié)尾,也就是說如果用戶訪問的是圖片服務(wù)器,則將用戶的訪問會話保持在圖片服務(wù)器上;而如果用戶的uri部分以/foo開始,則將會話保持到相應(yīng)的服務(wù)器上。同樣,根據(jù)用戶訪問中的cookie字段以及uri里面的某個特定字段里是否與規(guī)定的類型相符,從而進(jìn)行相應(yīng)的會話保持。,LTM組網(wǎng)架構(gòu),單臂接入模式 雙臂接入模式 遠(yuǎn)程節(jié)點(diǎn)模式 加入獨(dú)立SSL/WA/ASM設(shè)備 防火墻負(fù)載均衡 多鏈路接入 災(zāi)備站點(diǎn)靜態(tài)路由注入,LTM單臂接入模式 單臂模式下的網(wǎng)絡(luò)物理結(jié)構(gòu),服務(wù)器,服務(wù)器,LTM,LTM,外部 外部網(wǎng)絡(luò) 核心三層交換 Vlan 1,串口心跳線,核心三層交換,服務(wù)器,服務(wù)

49、器,LTM,0,1,GW:54 GW:54,VS: :80,SelfIP: 53 GW:54,54,54,SIP,Sport,DIP,Dport, , 6787 53 8888, 1,80 80,1,80,53 8888,,80,192.168.0

50、.1,6787,單臂接入-源地址替換模式數(shù)據(jù)訪問流程 Client,源地址替換后的處理,服務(wù)器,服務(wù)器,LTM,,0,1,GW:54 GW:54,VS: :80,SelfIP: 53 GW:54,54,54 核心三層交換,HTTP Profile,when HTTP_REQUEST HTTP:header insert Client_IP= IP:cli

51、ent_addr,Client iRules,只有HTTP協(xié)議的時候,可以通過將源地址插入到 客戶端請求的HTTP Header里,然后在服務(wù)器上,通過讀取這個Header,獲得客戶端的真實(shí)源IP地 址,單臂接入-npath模式數(shù)據(jù)訪問流程,Client,,服務(wù)器 0 Lo:,服務(wù)器 1 Lo:,GW:54 GW:54,LTM VS: :80 SelfIP: 53,GW:54,

52、54 核心三層交換 54 ,SIP,Sport,DIP,Dport, 6787 6787 ,80 80, ,80, 6787,npath模式的關(guān)鍵在于服務(wù)器上配置的loopback 地址 在上能找到各種服務(wù)器的 loopback地址如何配置的文檔,單臂接入-服務(wù)器非直連模式(無源地址替換),核心三層交換,LTM, Client,服務(wù)器 0,GW:54

53、 GW:54,VS: :80,SelfIP: 53,GW:54,54,54, 服務(wù)器 1,SIP,Sport,DIP,Dport, , 1 ,6787 6787 80 80, 1 ,80 80 6787 6787,54,客戶端,服務(wù)器,LTM,

54、0,GW:54,1,GW:54,VS: :80,IP: 53 GW:54,同網(wǎng)段訪問處理-必須通過SNAT實(shí)現(xiàn) 54 核心三層交換,SIP,Sport,DIP,Dport,0,6787,,80,53 8888,1,80,1,80,53 8888,,80,192.168.

55、0.1,6787,服務(wù)器,服務(wù)器,LTM,單臂接入-服務(wù)器更改網(wǎng)關(guān)數(shù)據(jù)訪問流程 Client,0,1,GW:53 GW:53,VS: :80,SelfIP: 53 GW:54,54,54 核心三層交換,SIP ,Sport 6787,DIP ,Dport 80, , 1 192.168.1

56、.1,6787 80 80,1 ,80 6787 6787,Client,服務(wù)器更改網(wǎng)關(guān)后的直接訪問服務(wù)器問題 ,服務(wù)器 0,GW:53 GW:53,LTM VS: :80,IP: 53 GW:54,SYN 54,核心三層交換 54 SYN,服務(wù)器 SYN-ACK 1, ,SIP 192

57、.168.1.11,Sport 6787 80,DIP 1 ,Dport 80 6787,FastL4 Profile,雙臂接入模式,雙臂接入-服務(wù)器直連 Client,服務(wù)器 0,服務(wù)器 1,VS: ,EXTIP: 53/VLAN EXT INTIP:54/VLAN INT GW:54,54,54 核心三層交換,SIP,Sport,DIP,Dport, , 1 ,6787 6787 80 80, 1

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論