F5 BIG-IP LTM 詳解(工作原理 配置手冊(cè))

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

Muti

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

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

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

Type詳解PerformanceL4StandardVSFastHTTPForwardingVS整理課件PerformanceL4TMM只是負(fù)責(zé)客戶端連接的分配和轉(zhuǎn)發(fā)，不改變TCP連接中的任何參數(shù)客戶端和效勞器自行協(xié)商TCP傳輸參數(shù)在34/64/68平臺(tái)上PerformanceL4可以有PVA參加實(shí)現(xiàn)硬件加速在15/16/36/69/89/Viprion平臺(tái)上都通過TMM核心進(jìn)行處理PerformanceL4VS上只有4層的iRules可以使用默認(rèn)狀態(tài)下，新建連接的第一個(gè)包必須是Syn包，如果是其他的數(shù)據(jù)包比方ACK、RST等如果不在連接表中，那么全部丟棄。在FastL4profile翻開Looseclose和LooseInitial的時(shí)候?qū)Ψ荢yn包也可以建立連接表TMM客戶端客戶端客戶端效勞器端效勞器端效勞器端整理課件Performance

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

整體的CPU占用率整理課件OneConnect工作原理連接聚合和內(nèi)容交換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連接聚合內(nèi)容交換整理課件注：eligiblereuse符合條件的再利用整理課件OneConnect的典型工作場(chǎng)景實(shí)現(xiàn)連接聚合降低效勞器的連接總數(shù)需要對(duì)每一個(gè)請(qǐng)求都進(jìn)行單獨(dú)處理〔注意在多數(shù)情況下，LTM只對(duì)一個(gè)連接的第一個(gè)包進(jìn)行處理〕典型的，翻開Cookie會(huì)話保持有時(shí)候會(huì)出現(xiàn)保持不正確的情況，這時(shí)就需要翻開OneConnect通過設(shè)置Mask=55，可以使后臺(tái)服務(wù)器可以“看到〞客戶端源IP，但這個(gè)時(shí)候One-connect只對(duì)一個(gè)客戶端的連接起作用整理課件OneConnect和應(yīng)用協(xié)議注意！OneConnectProfile不是必須和HTTPProfile

共用，也可以用于其他應(yīng)用協(xié)議。用于其他應(yīng)用協(xié)議的時(shí)候必須使用iRules編程

來調(diào)用OneConnect在需要對(duì)長(zhǎng)連接進(jìn)行拆分處理的時(shí)候，也需要用OneConnectProfile整理課件NAT的工作模式0NATAddress:0NAT和SNATSNAT全稱：SecureNetworkAddressTranslation整理課件SNAT的工作模式0SNATAddress:0整理課件NAT和SNAT之間的差異NAT1比1接收所有發(fā)往NAT地址的連接所有的連接只是通過LTM的連接表管理，但是是無狀態(tài)的，連接不會(huì)被Timeout連接不能被鏡像SNAT多對(duì)一或者多對(duì)多拒絕所有發(fā)往SNAT地址的連接請(qǐng)求.連接通過LTM的連接表管理，有timeout設(shè)置連接可以被鏡像整理課件SNATAutoMap當(dāng)配置SNATAutoMap的時(shí)候，請(qǐng)求從那個(gè)VLAN發(fā)出去，那么SNAT的源地址為VLAN上的SelfIP當(dāng)一個(gè)VLAN上有多個(gè)SelfIP存在的時(shí)候，SNAT的源地址是在多個(gè)SelfIP之間輪詢整理課件SNATPool的工作模式SNATPool是提供了一個(gè)可用于SNAT源地址的列表BIGIP采用最小連接數(shù)的方式在SNAT的源地址之間進(jìn)行選擇整理課件通過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的源地址會(huì)話保持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可以在兩臺(tái)設(shè)備之間鏡像SNAT對(duì)于TCPidleTimeout和UDPidleTimeout可以有獨(dú)立的設(shè)置整理課件Monitor如何向外發(fā)送請(qǐng)求所有的Monitor請(qǐng)求都是由bigd進(jìn)程發(fā)起Monitor流量要穿過TMM發(fā)送到Server或者其他位置在bconn中可以看到Monitor的流量TMMbigdMonitor工作原理整理課件重要的Monitor-TCPSendString:發(fā)送的請(qǐng)求字符串，支持C語言

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

當(dāng)客戶進(jìn)行第一次請(qǐng)求時(shí)，客戶HTTP請(qǐng)求〔不帶cookie〕進(jìn)入BIGIP，BIGIP根據(jù)負(fù)載均衡算法策略選擇后端一臺(tái)效勞器，并將請(qǐng)求發(fā)送至該效勞器，后端效勞器進(jìn)行HTTP回復(fù)一個(gè)空白的cookie并發(fā)回BIGIP，然后BIGIP重新在cookie里寫入會(huì)話保持?jǐn)?shù)值，將HTTP回復(fù)返回到客戶端。當(dāng)客戶請(qǐng)求再次發(fā)生時(shí)，客戶HTTP請(qǐng)求〔帶有上次BIGIP重寫的cookie〕進(jìn)入BIGIP，然后BIGIP讀出cookie里的會(huì)話保持?jǐn)?shù)值，將HTTP請(qǐng)求〔帶有與上面同樣的cookie〕發(fā)到指定的效勞器，然后后端效勞器進(jìn)行請(qǐng)求回復(fù)，HTTP回復(fù)里又將帶有空的cookie，恢復(fù)流量再次經(jīng)過進(jìn)入BIGIP時(shí)，BIGIP再次寫入更新后會(huì)話保持?jǐn)?shù)值到該cookie。整理課件整理課件PassiveCookie模式

效勞器使用特定信息來設(shè)置cookie。當(dāng)客戶進(jìn)行第一次請(qǐng)求時(shí)，客戶HTTP請(qǐng)求〔不帶cookie〕進(jìn)入BIGIP，BIGIP根據(jù)負(fù)載平衡算法策略選擇后端一臺(tái)效勞器，并將請(qǐng)求發(fā)送至該效勞器，后端效勞器進(jìn)行HTTP回復(fù)一個(gè)cookie并發(fā)回BIGIP，然后BIGIP將帶有效勞器寫的cookie值的HTTP回復(fù)返回到客戶端。當(dāng)客戶請(qǐng)求再次發(fā)生時(shí)，客戶HTTP請(qǐng)求〔帶有上次效勞器寫的cookie〕進(jìn)入BIGIP，然后BIGIP根據(jù)cookie里的會(huì)話保持?jǐn)?shù)值，將HTTP請(qǐng)求〔帶有與上面同樣的cookie〕發(fā)到指定的效勞器，然后后端效勞器進(jìn)行請(qǐng)求回復(fù)，HTTP回復(fù)里又將帶有更新的會(huì)話保持cookie，恢復(fù)流量再次經(jīng)過進(jìn)入BIGIP時(shí)，BIGIP將帶有該cookie的請(qǐng)求回復(fù)給客戶端。整理課件整理課件CookieHash模式

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

BIGIP可以根據(jù)用戶HTTP訪問里包頭信息信息進(jìn)行會(huì)話保持，HTTP包頭里包含以下信息，BIGIP可以將用戶訪問里這些信息通過表達(dá)式來獲得相應(yīng)的數(shù)值從而進(jìn)行會(huì)話保持。

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

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

Accept-Encoding：瀏覽器能夠進(jìn)行解碼的數(shù)據(jù)編碼方式，比方gzip。Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時(shí)間。

Accept-Language：瀏覽器所希望的語言種類，當(dāng)效勞器能夠提供一種以上的語言版本時(shí)要用到。

Authorization：授權(quán)信息，通常出現(xiàn)在對(duì)效勞器發(fā)送的WWW-Authenticate頭的應(yīng)答中。

Connection：表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive〞，或者看到請(qǐng)求使用的是HTTP1.1〔HTTP1.1默認(rèn)進(jìn)行持久連接〕，它就可以利用持久連接的優(yōu)點(diǎn)，當(dāng)頁面包含多個(gè)元素時(shí)〔例如Applet，圖片〕，顯著地減少下載所需要的時(shí)間。要實(shí)現(xiàn)這一點(diǎn)，Servlet需要在應(yīng)答中發(fā)送一個(gè)Content-Length頭，最簡(jiǎn)單的實(shí)現(xiàn)方法是：先把內(nèi)容寫入ByteArrayOutputStream，然后在正式寫出內(nèi)容之前計(jì)算它的大小。整理課件

Content-Length：表示請(qǐng)求消息正文的長(zhǎng)度。

Cookie：這是最重要的請(qǐng)求頭信息之一，參見后面?Cookie處理?一章中的討論。

From：請(qǐng)求發(fā)送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會(huì)用到它。

Host：初始URL中的主機(jī)和端口。

If-Modified-Since：只有當(dāng)所請(qǐng)求的內(nèi)容在指定的日期之后又經(jīng)過修改才返回它，否那么返回304“NotModified〞應(yīng)答。

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

Referer：包含一個(gè)URL，用戶從該URL代表的頁面出發(fā)訪問當(dāng)前請(qǐng)求的頁面。

User-Agent：瀏覽器類型，如果Servlet返回的內(nèi)容與瀏覽器類型有關(guān)那么該值非常有用。整理課件基于I-Rules的會(huì)話保持BIGIP交換機(jī)內(nèi)置有強(qiáng)大的搜索引擎，可以高效的探測(cè)到網(wǎng)絡(luò)流量中的IP包內(nèi)容的局部，并可以讀出該IP包內(nèi)容部分進(jìn)行會(huì)話保持這些內(nèi)容局部包括如下局部:整理課件下面是一個(gè)BIGIP根據(jù)IRULES進(jìn)行會(huì)話保持的范例：

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字段結(jié)尾，也就是說如果用戶訪問的是圖片效勞器，那么將用戶的訪問會(huì)話保持在圖片效勞器上；而如果用戶的uri局部以/foo開始，那么將會(huì)話保持到相應(yīng)的效勞器上。同樣，根據(jù)用戶訪問中的cookie字段以及uri里面的某個(gè)特定字段里是否與規(guī)定的類型相符，從而進(jìn)行相應(yīng)的會(huì)話保持。整理課件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)效勞器效勞器LTMLTM外部外部網(wǎng)絡(luò)

核心三層交換

Vlan

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

GW:54VS:

:80SelfIP:

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

③

678753

8888

18080④18053

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

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

GW:54VS:

：80SelfIP:

53GW:545454

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

ProfilewhenHTTP_REQUEST{

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

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

GW:54

LTMVS:

:80SelfIP:

53GW:54①②③

54

核心三層交換54

④⑤SIPSportDIPDport①②

6787

③

6787

8080④⑤

80

6787npath模式的關(guān)鍵在于效勞器上配置的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同網(wǎng)段訪問處理-必須通過SNAT實(shí)現(xiàn)

54

核心三層交換SIPSportDIPDport①0678780②53

8888180③18053

8888④806787①②③④整理課件效勞器效勞器LTM單臂接入-效勞器更改網(wǎng)關(guān)數(shù)據(jù)訪問流程

Client01GW:53

GW:53VS:

:80SelfIP:

53GW:545454

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

SIPSport

6787

DIPDport

80

③

④⑤⑥

1

6787

80

801

8067876787⑥整理課件Client效勞器更改網(wǎng)關(guān)后的直接訪問效勞器問題

效勞器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

③④整理課件雙臂接入-串聯(lián)部署-擴(kuò)展端口Client 效勞器0VS:

EXTIP:

53/VLAN

EXTINTIP:54/VLAN

INTGW:5454

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

1

67876787

80

80

1

80

8067876787整理課件雙臂接入-串聯(lián)部署-擴(kuò)展端口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方式來劃分多個(gè)VLAN

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

EXTIP:

53/VLAN

EXTINTIP:54/VLAN

INTGW: