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頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

F5BIG-IPLTM詳解北京先進數通信息技術一月24整理課件LTM根底架構VSType詳解Profile詳解CMP工作原理OneConnect工作原理NAT、SNAT工作原理Monitor工作原理HA工作原理LTM工作原理整理課件LTM根底架構什么是TMMTrafficManagementModuleTMOS的核心進程,有自己獨立的內存、CPU資源分配和I/O控制所有的生產流量都通過TMM接收一個CPUCore只能有一個TMM進程在V9版本上,15/34/64/68都是單TMM運行在V9版本上,16/36/69/89/84/88都是多TMM運行在V10版本上,16/36/69/89/84/88都是多TMM運行Viprion只支持9.6和10.0版本,默認都是多TMM運行整理課件TMM處理的范圍TMM內部處理功能所有的VS入口流量LTMiRiules處理Profile處理會話保持處理負載均衡算法SSL加速〔和硬件結合〕HTTP壓縮SNAT靜態CRL〔Certificaterevocationlist證書撤消清單〕文件校驗不在TMM里面處理的功能WebAcceleratorModule〔包括壓縮〕ApplicationSecurityModuleGTM的分配算法處理〔包括GTMrules〕Named域名解析健康檢查日志管理系統數據統計SNMP數據輸出HA健康檢查整理課件BIGIP內部結構-V9平臺15/34/64/68TM/OS管理CPU萬兆/千兆交換端口PVA〔PacketVelocityASIC〕四層交換專用ASICHostOSWeb界面管理健康檢查SNMP……..BridgeTMM0獨立的管理機SCCPSSL加解密HTTP壓縮AdminConsole整理課件BIGIP內部結構-Mecury平臺16/36/69/896TM/OS管理CPU萬兆/千兆交換端口HiSpeedBridgeTMM2HostOSWeb界面管理健康檢查SNMP……..TMM3TMM1TMM0獨立的管理機AOMCluster

Muti

Processor多CPU并行處理SSL加解密HTTP壓縮ConsoleAdmin整理課件Host和TMM的內存分配Host在啟動的時候限定了內存分配的大小,在沒有其他module的情況下是384MBTMM進程啟動后,將自動獲取余下的所有

物理內存HostMemoryTMMMemory整理課件查看Host內存占用情況#physmem/查看物理內存大小

8387584bmemoryshow/查看內存分配情況MEMORYSTATISTICS--|(Host)Total=3.835GBUsed=3.590GB|(TMM)Total=5.976GBUsed=93.22MB整理課件查看TMM內存占用情況TMM分配的內存是準確的,Host內存顯示在這里有一些偏差整理課件VS

Type詳解PerformanceL4StandardVSFastHTTPForwardingVS整理課件PerformanceL4TMM只是負責客戶端連接的分配和轉發,不改變TCP連接中的任何參數客戶端和效勞器自行協商TCP傳輸參數在34/64/68平臺上PerformanceL4可以有PVA參加實現硬件加速在15/16/36/69/89/Viprion平臺上都通過TMM核心進行處理PerformanceL4VS上只有4層的iRules可以使用默認狀態下,新建連接的第一個包必須是Syn包,如果是其他的數據包比方ACK、RST等如果不在連接表中,那么全部丟棄。在FastL4profile翻開Looseclose和LooseInitial的時候對非Syn包也可以建立連接表TMM客戶端客戶端客戶端效勞器端效勞器端效勞器端整理課件Performance

L4攻擊防護-SynCookie正常情況下客戶端連接和效勞器端連接是1:1的關系TMM在第一次收到客戶端Syn包時,并不建立連接表TMM的SynAck回應通過算法回應給客戶端Syn,并期待客戶端回應的值TMM對客戶端ACK進行計算,確認是真實客戶端,再和后臺效勞器建立連接在84/88上可以實現硬件的SynCookie計算,其余的平臺都是通過軟件實現SynCookie計算SynCookie工作模式下,只有成功建立連接的TCP請求才轉發到后臺TMMSynSyn,Ack(syncookie)Ack(Cookie)SynSyn-AckAckData整理課件StandardVS正常情況下客戶端連接和效勞器端連接是1:1的關系默認工作在全代理模式,客戶端和效勞器端的TCP連接完全獨立客戶端和效勞器端的TCP參數都是由TMM和雙方分別協商默認情況下以客戶端源IP和后臺建立連接,在翻開SNAT的情況下用SNAT地址和后臺建立連接StandardVS的端口永遠對外開放,無論后臺是否有效勞器在工作TMMSynSyn,AckAckSynSyn-AckAckDataData整理課件Standard模式下的攻擊防護StandardVS模式具有天然的防攻擊功能在遇到Syn攻擊的時候會導致系統的連接表過大通過System-SYNCheckActivationThreshold的設置,在到達設置值的時候系統自動啟動SynCookie,防止建立過多連接,這個值對全局生效大局部的網絡層攻擊都無法通過Standard模式的VS整理課件FastHTTPFastHTTPVS僅用于HTTP協議默認開啟OneConnectProfile,對客戶端連接進行聚合處理默認開啟SNATAutoMap,在效勞器端收到的TCP連接請求都是來自于TMM沒有會話保持功能不能處理SSL,HTTPSTMM客戶端客戶端客戶端效勞器端效勞器端效勞器端整理課件FowardingVS〔ForwardingIP〕只能使用FastL4Profile按照連接處理,類似于路由器工作,但不完全一樣,在FastL4Profile中開啟LooseInitial和LooseClose之后更為接近路由工作模式所有穿過FowardingVS的連接都將產生連接表沒有PoolMember,轉發完全取決于本地路由可以使用基于4層的RulesTMM客戶端查詢本地路由表轉發客戶端請求整理課件VS和ProfileVS作為所有流量的入口Profile依賴于VS,對進入VS的流量進行格式化處理不同的VS可以用同一個Profile或者不同的ProfileProfile之間存在有相互排斥和相互依存的關系VSTCPProfileUDPProfileFastL4ProfileHTTPRTSPClientSSLServerSSLStreamingSMTPSIPOneConnect整理課件Rules的處理必須依賴于VS對流量的接收通過事件觸發機制,Rules可以控制流量在VS內部處理的整個過程SSLCompressionClientSideServerSideTCPExpressServerTCPExpressCachingMicrokernelVirtualServeriRulesClientiControlAPITCPProxyOneConnectXMLRateShapingTrafficShieldWebAccel3rdPartyVS和Rules整理課件ServeriRulesClientSideServerSideTCPProxyClientSideEventClient_acceptClient_dataCache_requestDNS_requestHTTP_REQUESTHTTP_REQUEST_DATARTSP_REQUEST....ServerSideEventServer_connectServer_dataCache_responseDNS_responseHTTP_RESPONSEHTTP_RESPONSE_DATARTSP_RESPONSE....整理課件大局部rules只在同一個VS之內有效Rules內創立的變量以連接為生命周期一個VS上可以有多個Rules,它們將被順序執行CLIENT_ACCPTEDCLIENT_DATALB_SELECTEDLB_FAILEDSERVER_ACCPTEDSERVER_DATACLIENT_CLOSEDSERVER_CLOSEDRULE_INITVS整理課件Profile的作用和工作范圍Profile依賴于VSProfile是對VS的流量進行格式化處理舉例如果一個VS上配置了TCPProfile,那么該VS對所有的UDP流量都不會接收Profile詳解整理課件根本流量處理類型ProfileTCP,UDP,FastHTTP,FastL4,SCTP〔StreamControlTransmissionProtocol〕效勞流量處理類型ProfileHTTP,FTP,SMTP,RTSP〔RealTimeStreamingProtocol〕,SIP〔SessionInitiationProtocol〕,iSessionSSL處理類型ClientSSL,ServerSSL會話保持類型Cookie,DestinationIP,hash,msrdp,sourceIP,Universal,SSL認證處理類型Radius,CRLDP〔Constraint-BasedLabelDistributionProtocol〕,OCSP〔OnlineCertificateStatusProtocol〕其他處理類型OneConnect,Statistics,NTLM〔NTLANManager〕,Stream整理課件重要的Profile-FastL4ResetonTimeout:在連接到達Timeout的是否向兩端發送Reset包IdelTimeout:多長時間連接里面沒有數據流量的時候就刪除連接表LooseInitiation/LooseClose:是否接收非Syn包建立連接SoftareSynCookieProtection:是否在VS上啟用SynCookie,實現Syn攻擊防護可能調整的參數整理課件重要的Profile-TCP注意在ClientSide和ServerSide可以使用不同的TCPProfile通常情況下建議:Clientside:TCPWANOptimized或LANOptimizedServerside:TCPLANOptimized除非你非常了解TCP的工作原理,否那么不要調整除idelTimeout以外的任何參數整理課件重要的Profile-ClientSSL對所有進入VS的流量按照SSL協議進行處理注意ClientSSLprofile不一定只能使用在HTTPS上使用ClientSSL的VS不一定使用443端口TMM客戶端客戶端客戶端效勞器端效勞器端效勞器端SSLSSLSSL整理課件重要的Profile-FTPFTPProfile主要用于處理FTP的主動和被動傳輸兩種模式由于需要配置動態偵聽端口,因此FTP協議必須進行單獨處理通過iRules也可以到達同樣的目的,但由于FTP協議使用非常廣泛,因此使用FTPprofile來簡化配置和處理FTPProfile必須依賴于TCPprofile工作整理課件為什么要用CMP〔ClusterMulti-Processor〕性能增長要求CPU的主頻增加受到比較大的限制,目前的趨勢是以多核擴展為主ASIC(ApplicationSpecificIntergratedCircuits)、NP(NetworkProcessor)的處理架構并不適合于復雜、靈活的流量處理對于不標準的流量,采用硬件加速將導致系統設計僵化,很難參加新的功能實現市場需求需要充分利用CPU的多核處理能力來提升系統的整體性能CMP工作原理整理課件CMP的硬件支持整理課件CMP工作模式流量由HSB進行分配在多個TMM上,每個TMM占據一個CPUCore,每個TMM有自己獨立的內存空間每個TMM都具有相同的配置,包括VS/Profile/iRules/Pool/Persistence等TMM之間通過內存高速總線進行通訊共享通用信息如會話保持表,SNAT源端口等當CMP被Disable的時候,TMM0接管所有的流量64/68的硬件平臺已經支持CMP,在10.0上自動開啟VIPTMM0VIPTMM1VIPTMM2VIPTMM3HSBHSBSuperVIP整理課件如何查看CMP工作狀態btmmshow可以觀察每個TMM的狀態整理課件關于CMP必須了解的內容V9平臺啟動WA(web應用加速器)和ASM〔應用平安管理器〕將DisableCMPiRules中定義全局變量將DisableCMP所有的非TCP/UDP流量都只使用TMM0進行處理V9中使用Sessionadd,SessionLookup命令將DisableCMPConnectionLimit和RateShaping的配置是針對每個TMM生效手工關閉CMP運行bdbProvision.tmmCount1調整后必須重啟任何一個TMMCrash,將導致設備間FailoverTCPdump已經調整為可支持CMP整理課件查看VirtualServer的CMP工作狀態整理課件如何查看TMMCPU占用率top命令可以顯示每顆CPU的占用率和V9相比,TMM的CPU在Top命令中的顯示發生了變化每顆CPU的CPU占用率目前在圖形界面里都消失了,目前只有

整體的CPU占用率整理課件OneConnect工作原理連接聚合和內容交換index.htma.gifb.gifc.aspsales.htmd.gife.giff.aspsales.htmd.gife.gifindex.htma.gifb.gifc.aspServerf.aspindex.htma.gifb.gifc.aspsales.htmd.gife.giff.aspsales.htmd.gife.gifindex.htma.gifb.gifc.aspServerf.aspindex.htma.gifb.gifc.aspindex.htma.gifb.gifc.aspHTMLserverpoolGIFserverpoolASPserverpool連接聚合內容交換整理課件注:eligiblereuse符合條件的再利用整理課件OneConnect的典型工作場景實現連接聚合降低效勞器的連接總數需要對每一個請求都進行單獨處理〔注意在多數情況下,LTM只對一個連接的第一個包進行處理〕典型的,翻開Cookie會話保持有時候會出現保持不正確的情況,這時就需要翻開OneConnect通過設置Mask=55,可以使后臺服務器可以“看到〞客戶端源IP,但這個時候One-connect只對一個客戶端的連接起作用整理課件OneConnect和應用協議注意!OneConnectProfile不是必須和HTTPProfile

共用,也可以用于其他應用協議。用于其他應用協議的時候必須使用iRules編程

來調用OneConnect在需要對長連接進行拆分處理的時候,也需要用OneConnectProfile整理課件NAT的工作模式0NATAddress:0NAT和SNATSNAT全稱:SecureNetworkAddressTranslation整理課件SNAT的工作模式0SNATAddress:0整理課件NAT和SNAT之間的差異NAT1比1接收所有發往NAT地址的連接所有的連接只是通過LTM的連接表管理,但是是無狀態的,連接不會被Timeout連接不能被鏡像SNAT多對一或者多對多拒絕所有發往SNAT地址的連接請求.連接通過LTM的連接表管理,有timeout設置連接可以被鏡像整理課件SNATAutoMap當配置SNATAutoMap的時候,請求從那個VLAN發出去,那么SNAT的源地址為VLAN上的SelfIP當一個VLAN上有多個SelfIP存在的時候,SNAT的源地址是在多個SelfIP之間輪詢整理課件SNATPool的工作模式SNATPool是提供了一個可用于SNAT源地址的列表BIGIP采用最小連接數的方式在SNAT的源地址之間進行選擇整理課件通過iRules控制SNATwhenCLIENT_ACCEPTED{setsnat_addr}whenHTTP_REQUEST{setsnat_addr[HTTP::headerX-Forwarded-For]log"X-Fowarded-Foris[HTTP::headerX-Forwarded-For]"}whenLB_SELECTED{

snat$snat_addr}HTTPSSSLOffload替換源地址Server端需要在TCP連接里面獲取客戶端源地址整理課件SNAT的源地址會話保持whenRULE_INIT{#loglocal5.warning"--------$cnc_snatpool"setsnat_length[llength$cnc_snatpool]loglocal5.warning"--------snatpoollengthis$snat_length"}whenLB_SELECTED{#setclient_addr"3"setclient_ip[IP::client_addr]setclient_last[getfield$client_ip"."4]#loglocal5.warning"--------clientlastis$client_last"setsnat_addr[lindex$cnc_snatpool[expr$client_last%$snat_length]]#loglocal5.warning"------------clientsnataddr$snat_addr"snat$snat_addr}整理課件Timeout定義和鏡像SNAT可以在兩臺設備之間鏡像SNAT對于TCPidleTimeout和UDPidleTimeout可以有獨立的設置整理課件Monitor如何向外發送請求所有的Monitor請求都是由bigd進程發起Monitor流量要穿過TMM發送到Server或者其他位置在bconn中可以看到Monitor的流量TMMbigdMonitor工作原理整理課件重要的Monitor-TCPSendString:發送的請求字符串,支持C語言

的轉義符ReceiveString:在返回的內容中查詢的字符串Transparent:數據包內的三層發送目的地是AliasAddress,二層的發送目的地是NodeAddress的MAC地址整理課件重要的Monitor-ExternalMonitorMEMBER="${1}";PORT="${2}";HOST_2_RESOLV="${3}";[${#}-ne3]&&exit255PIDFILE="/var/run/pinger.${MEMBER}.eav.${PORT}.pid"if[-f"${PIDFILE}"]then

kill-9`cat"${PIDFILE}"`>/dev/null2>&1fiecho"$$">"${PIDFILE}"MEMBER=`echo$1|sed's/::ffff://'`2>/dev/nulllog_info(){

echo${*}|logger-p##stocksyslog-ngdestinations-#

-/var/log/ltm#

-/var/log/ltm#

-/var/log/messages#

-/var/log/messages

#thisisfordebugonly!donotcalllog_infobelowunless

#youwanttoseeyoursyntaxandtheshellevaluationof

#variables(variableexansion)}整理課件HA工作模式-Active/Active每個VS對外提供不同的效勞效勞器必須分組,分別指不同的網關在使用SNAT的情況下不需要效勞器指不同的網關〔建議模式〕VS1VS2HA工作原理整理課件串口心跳線的工作模式沒有數據在串口心跳線之間傳輸兩臺設備是通過監控Failover線上的電壓來決定是否切換,備機一旦檢測到主機電壓為0那么進行接管動作切換時間在200-300毫秒之間SOD(SwitchOverDeamon)進程負責監控Failover線上的電壓整理課件網絡心跳線的工作模式兩臺設備之間通過網絡互相發送心跳信號NetworkFailover可以設置2條路徑NetworkFailover和串口心跳線Failover可以同時使用在10.0里的NetworkFailover有巨大的變化整理課件靜態負載均衡算法輪詢,比率,優先權動態負載均衡算法最少連接數,最快響應速度,觀察方法,預測法,動態性能分配,動態效勞器補充,效勞質量,效勞類型,規那么模式F5負載均衡算法整理課件◆輪詢〔RoundRobin〕:順序循環將請求一次順序循環地連接每個效勞器。當其中某個效勞器發生第二到第7層的故障,BIG-IP就把其從順序循環隊列中拿出,不參加下一次的輪詢,直到其恢復正常。整理課件◆比率〔Ratio〕:給每個效勞器分配一個加權值為比例,根椐這個比例,把用戶的請求分配到每個效勞器。當其中某個效勞器發生第二到第7層的故障,BIG-IP就把其從效勞器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。整理課件◆優先權〔Priority〕:給所有效勞器分組,給每個組定義優先權,BIG-IP用戶的請求,分配給優先級最高的效勞器組〔在同一組內,采用輪詢或比率算法,分配用戶的請求〕;當最高優先級中所有效勞器出現故障,BIG-IP才將請求送給次優先級的效勞器組。這種方式,實際為用戶提供一種熱備份的方式。整理課件◆最少的連接方式〔LeastConnection〕:傳遞新的連接給那些進行最少連接處理的效勞器。當其中某個效勞器發生第二到第7層的故障,BIG-IP就把其從效勞器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。整理課件◆最快模式〔Fastest〕:傳遞連接給那些響應最快的效勞器。當其中某個服務器發生第二到第7層的故障,BIG-IP就把其從效勞器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。整理課件◆觀察模式〔Observed〕:連接數目和響應時間以這兩項的最正確平衡為依據為新的請求選擇效勞器。當其中某個效勞器發生第二到第7層的故障,BIG-IP就把其從效勞器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復正常。整理課件◆預測模式〔Predictive〕:BIG-IP利用收集到的效勞器當前的性能指標,進行預測分析,選擇一臺效勞器在下一個時間片內,其性能將到達最正確的效勞器響應用戶的請求。(被BIG-IP進行檢測)整理課件◆動態性能分配(DynamicRatio-APM):BIG-IP收集到的應用程序和應用效勞器的各項性能參數,動態調整流量分配。◆動態效勞器補充(DynamicServerAct.):當主效勞器群中因故障導致數量減少時,動態地將備份效勞器補充至主效勞器群。◆效勞質量(QoS〕:按不同的優先級對數據流進行分配。◆效勞類型(ToS):按不同的效勞類型〔在TypeofField中標識〕對數據流進行分配。◆規那么模式:針對不同的數據流設置導向規那么,用戶可自行。常用到的一般是最少連接數、最快反響、或者輪詢,決定選用那種算法,主要還是要結合實際的需求整理課件F5會話保持F5BigIP支持多種的會話保持方法,其中包括:簡單會話保持〔源地址會話保持〕、HTTPHeader的會話保持,基于SSLSessionID的會話保持,I-Rules會話保持以及基于HTTPCookie的會話保持,此外還有基于SIPID以及Cache設備的會話保持等,但常用的是簡單會話保持,HTTPHeader的會話保持以及HTTPCookie會話保持以及基于I-Rules的會話保持。整理課件簡單會話保持簡單會話保持又稱為基于源地址的會話保持,是指負載均衡器在作負載均衡時是根據訪問請求的源地址作為判斷關連會話的依據。對來自同一IP地址的所有訪問請求都會被保持到一臺效勞器上去。簡單會話保持一個很重要的參數就是連接超時值,BIGIP會為每一個進行會話保持的會話設定一個時間值,兩次會話之前的間隔如果小于這個超時值,BIGIP將會將新的連接進行會話保持,但如果這個間隔大于該超時值,BIGIP會將新來的連接認為是新的會話然后進行負載平衡。基于原地址的會話保持實現簡單,效率較高。但是多個用戶通過代理或地址轉換的方式來訪問效勞器時,會導致效勞器之間的負載嚴重失衡。另外當客戶機數量很少,但每個客戶機都產生多個并發訪問,這時用這種方法也會導致負載均衡失效。整理課件基于Cookie的會話保持整理課件Cookie插入模式在Cookie插入模式下,BigIP將負責插入cookie,后端效勞器無需作出任何修改。當客戶進行第一次請求時,客戶HTTP請求〔不帶cookie〕進入BIGIP,BIGIP根據負載平衡算法策略選擇后端一臺效勞器,并將請求發送至該效勞器,后端效勞器進行HTTP回復〔不帶cookie〕被發回BIGIP,然后BIGIP插入cookie,將HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求〔帶有上次BIGIP插入的cookie〕進入BIGIP,然后BIGIP讀出cookie里的會話保持數值,將HTTP請求〔帶有與上面同樣的cookie〕發到指定的效勞器,然后后端效勞器進行請求回復,由于效勞器并不寫入cookie,HTTP回復將不帶有cookie,恢復流量再次經過進入BIGIP時,BIGIP再次寫入更新后的會話保持cookie。整理課件整理課件Cookie重寫模式

當客戶進行第一次請求時,客戶HTTP請求〔不帶cookie〕進入BIGIP,BIGIP根據負載均衡算法策略選擇后端一臺效勞器,并將請求發送至該效勞器,后端效勞器進行HTTP回復一個空白的cookie并發回BIGIP,然后BIGIP重新在cookie里寫入會話保持數值,將HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求〔帶有上次BIGIP重寫的cookie〕進入BIGIP,然后BIGIP讀出cookie里的會話保持數值,將HTTP請求〔帶有與上面同樣的cookie〕發到指定的效勞器,然后后端效勞器進行請求回復,HTTP回復里又將帶有空的cookie,恢復流量再次經過進入BIGIP時,BIGIP再次寫入更新后會話保持數值到該cookie。整理課件整理課件PassiveCookie模式

效勞器使用特定信息來設置cookie。當客戶進行第一次請求時,客戶HTTP請求〔不帶cookie〕進入BIGIP,BIGIP根據負載平衡算法策略選擇后端一臺效勞器,并將請求發送至該效勞器,后端效勞器進行HTTP回復一個cookie并發回BIGIP,然后BIGIP將帶有效勞器寫的cookie值的HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求〔帶有上次效勞器寫的cookie〕進入BIGIP,然后BIGIP根據cookie里的會話保持數值,將HTTP請求〔帶有與上面同樣的cookie〕發到指定的效勞器,然后后端效勞器進行請求回復,HTTP回復里又將帶有更新的會話保持cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該cookie的請求回復給客戶端。整理課件整理課件CookieHash模式

當客戶進行第一次請求時,客戶HTTP請求〔不帶cookie〕進入BIGIP,BIGIP根據負載均衡算法策略選擇后端一臺效勞器,并將請求發送至該效勞器,后端效勞器進行HTTP回復一個cookie并發回BIGIP,然后BIGIP將帶有效勞器寫的cookie值的HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求〔帶有上次效勞器寫的cookie〕進入BIGIP,然后BIGIP根據cookie里的一定的某個字節的字節數來決定后臺效勞器接受請求,將HTTP請求〔帶有與上面同樣的cookie〕發到指定的效勞器,然后后端效勞器進行請求回復,HTTP回復里又將帶有更新后的cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該cookie的請求回復給客戶端。整理課件整理課件SSLSessionID會話保持在用戶的SSL訪問系統的環境里,當SSL對話首次建立時,用戶與效勞器進行首次信息交換以:1}交換平安證書,2〕商議加密和壓縮方法,3〕為每條對話建立SessionID。由于該SessionID在系統中是一個唯一數值,由此,BIGIP可以應用該數值來進行會話保持。當用戶想與該效勞器再次建立連接時,BIGIP可以通過會話中的SSLSessionID識別該用戶并進行會話保持。基于SSLSessionID的會話保持就需要客戶瀏覽器在進行會話的過程中始終保持其SSLSessionID不變,但實際上,微軟InternetExplorer被發現在經過特定一段時間后將主動改變SSLSessionID,這就使基于SSLSessionID的會話保持實際應用范圍大大縮小。整理課件基于HTTHeader的會話保持

BIGIP可以根據用戶HTTP訪問里包頭信息信息進行會話保持,HTTP包頭里包含以下信息,BIGIP可以將用戶訪問里這些信息通過表達式來獲得相應的數值從而進行會話保持。

Accept:瀏覽器可接受的MIME類型。

Accept-Charset:瀏覽器可接受的字符集。

Accept-Encoding:瀏覽器能夠進行解碼的數據編碼方式,比方gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。

Accept-Language:瀏覽器所希望的語言種類,當效勞器能夠提供一種以上的語言版本時要用到。

Authorization:授權信息,通常出現在對效勞器發送的WWW-Authenticate頭的應答中。

Connection:表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive〞,或者看到請求使用的是HTTP1.1〔HTTP1.1默認進行持久連接〕,它就可以利用持久連接的優點,當頁面包含多個元素時〔例如Applet,圖片〕,顯著地減少下載所需要的時間。要實現這一點,Servlet需要在應答中發送一個Content-Length頭,最簡單的實現方法是:先把內容寫入ByteArrayOutputStream,然后在正式寫出內容之前計算它的大小。整理課件

Content-Length:表示請求消息正文的長度。

Cookie:這是最重要的請求頭信息之一,參見后面?Cookie處理?一章中的討論。

From:請求發送者的email地址,由一些特殊的Web客戶程序使用,瀏覽器不會用到它。

Host:初始URL中的主機和端口。

If-Modified-Since:只有當所請求的內容在指定的日期之后又經過修改才返回它,否那么返回304“NotModified〞應答。

Pragma:指定“no-cache〞值表示效勞器必須返回一個刷新后的文檔,即使它是代理效勞器而且已經有了頁面的本地拷貝。

Referer:包含一個URL,用戶從該URL代表的頁面出發訪問當前請求的頁面。

User-Agent:瀏覽器類型,如果Servlet返回的內容與瀏覽器類型有關那么該值非常有用。整理課件基于I-Rules的會話保持BIGIP交換機內置有強大的搜索引擎,可以高效的探測到網絡流量中的IP包內容的局部,并可以讀出該IP包內容部分進行會話保持這些內容局部包括如下局部:整理課件下面是一個BIGIP根據IRULES進行會話保持的范例:

if(_uriends_with“.gif〞){

usepoolimage_servers

}

elseif(_uristarts_with“/foo〞){

usepoolfoo_servers

}

elseif(_cookie(“XYZ-Type〞)==“direct〞){

usepoolcookie_servers

}

elseif(findstr(_uri,“?type=〞,6,“&〞)==“cgi〞){

usepoolcgi_servers

}

else{

usepoolweb_servers

}

在此I-Rules里,可以看到,如果用戶的uri局部以.gif字段結尾,也就是說如果用戶訪問的是圖片效勞器,那么將用戶的訪問會話保持在圖片效勞器上;而如果用戶的uri局部以/foo開始,那么將會話保持到相應的效勞器上。同樣,根據用戶訪問中的cookie字段以及uri里面的某個特定字段里是否與規定的類型相符,從而進行相應的會話保持。整理課件LTM組網架構單臂接入模式雙臂接入模式遠程節點模式參加獨立SSL/WA/ASM設備防火墻負載均衡多鏈路接入災備站點靜態路由注入整理課件LTM單臂接入模式單臂模式下的網絡物理結構效勞器效勞器LTMLTM外部外部網絡

核心三層交換

Vlan

1串口心跳線整理課件核心三層交換效勞器效勞器LTM01GW:54

GW:54VS:

:80SelfIP:

53GW:545454①②③④⑤SIPSportDIPDport①②

678753

8888

18080④18053

8888⑤⑥806787⑥單臂接入-源地址替換模式數據訪問流程

Client整理課件源地址替換后的處理效勞器效勞器LTM01GW:54

GW:54VS:

:80SelfIP:

53GW:545454

核心三層交換①②③④⑤⑥HTTP

ProfilewhenHTTP_REQUEST{

HTTP::headerinsert"Client_IP=[IP::client_addr]"}Client

iRules只有HTTP協議的時候,可以通過將源地址插入到客戶端請求的HTTPHeader里,然后在效勞器上通過讀取這個Header,獲得客戶端的真實源IP地址整理課件單臂接入-npath模式數據訪問流程Client 效勞器0Lo: 效勞器1Lo:GW:54

GW:54

LTMVS:

:80SelfIP:

53GW:54①②③

54

核心三層交換54

④⑤SIPSportDIPDport①②

6787

6787

8080④⑤

80

6787npath模式的關鍵在于效勞器上配置的loopback地址在adntech上能找到各種效勞器的loopback地址如何配置的文檔整理課件單臂接入-效勞器非直連模式〔無源地址替換〕核心三層交換LTM

Client 效勞器0GW:54

GW:54VS:

:80SelfIP:

53GW:545454①②③④⑤⑦⑧ ⑥ 效勞器1SIPSportDIPDport①②③④⑤⑥⑦⑧

1

67876787

80

80

1

80

806787678754整理課件客戶端效勞器LTM0GW:541GW:54VS:

:80IP:

53GW:54同網段訪問處理-必須通過SNAT實現

54

核心三層交換SIPSportDIPDport①0678780②53

8888180③18053

8888④806787①②③④整理課件效勞器效勞器LTM單臂接入-效勞器更改網關數據訪問流程

Client01GW:53

GW:53VS:

:80SelfIP:

53GW:545454

核心三層交換①②③④⑤①②

SIPSport

6787

DIPDport

80

④⑤⑥

1

6787

80

801

8067876787⑥整理課件Client效勞器更改網關后的直接訪問效勞器問題

效勞器0GW:53

GW:53

LTMVS:

:80IP:

53GW:54

①SYN54

核心三層交換54

②SYN 效勞器③SYN-ACK1①②

SIP

1Sport

6787

80

DIP1

Dport

80

6787FastL4

Profile整理課件雙臂接入模式雙臂接入-效勞器直連

Client 效勞器0 效勞器1VS:

EXTIP:

53/VLAN

EXTINTIP:54/VLAN

INTGW:545454

核心三層交換SIPSportDIPDport①②③④

1

67876787

80

80

1

80

8067876787①②LTM

③④整理課件雙臂接入-串聯部署-擴展端口Client 效勞器0VS:

EXTIP:

53/VLAN

EXTINTIP:54/VLAN

INTGW:5454

核心三層交換54① ② 效勞器1③④ LTM效勞器接入交換SIPSportDIPDport①②③④

1

67876787

80

80

1

80

8067876787整理課件雙臂接入-串聯部署-擴展端口Client 效勞器0GW:54

GW:54VS:

EXTIP:

53/VLAN

EXTINTIP:54/VLAN

INTGW:5454

核心三層交換54① ② 效勞器1③④ LTM效勞器接入交換SIPSportDIPDport①②③④

1

67876787

80

80

1

80

8067876787整理課件雙臂接入-旁掛模式核心三層交換效勞器效勞器LTMClient

0

1GW:54

GW:54VS:

:80EXTIP:

53/VLAN

EXTINTIP:54/VLAN

INTGW:545454①②③④SIPSportDIPDport①678780②③④

1

6787

80

801

8067876787External_vlanInternal_vlan旁掛模式下LTM可以用不同的端口接入核心交換,也可以采用端口捆綁模式接入核心交換,然后在端口捆綁里通過VLAN

tag方式來劃分多個VLAN

整理課件旁掛模式下的效勞器直接訪問核心三層交換LTMClient 效勞器0 效勞器1VS:

EXTIP:

53/VLAN

EXTINTIP:54/VLAN

INTGW:

溫馨提示

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

評論

0/150

提交評論