摘要: 在由云棲社區(qū)和阿里云網(wǎng)絡(luò)團(tuán)隊(duì)聯(lián)合主辦的2017阿里云網(wǎng)絡(luò)技術(shù)在線高峰論壇上,阿里云技術(shù)專(zhuān)家添毅分享了網(wǎng)絡(luò)產(chǎn)品部根據(jù)客戶(hù)和阿里云運(yùn)維的反饋提煉出的幾大最主要和最常見(jiàn)的在使用SLB產(chǎn)品中發(fā)生的問(wèn)題,并為大家介紹了針對(duì)這些常見(jiàn)問(wèn)題的相應(yīng)處理方法。
創(chuàng)新互聯(lián)建站長(zhǎng)期為上千客戶(hù)提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年,關(guān)注不同地域、不同群體,并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù);打造開(kāi)放共贏平臺(tái),與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為安平企業(yè)提供專(zhuān)業(yè)的做網(wǎng)站、網(wǎng)站建設(shè),安平網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。
摘要: 在由云棲社區(qū)和阿里云網(wǎng)絡(luò)團(tuán)隊(duì)聯(lián)合主辦的2017阿里云網(wǎng)絡(luò)技術(shù)在線高峰論壇上,阿里云技術(shù)專(zhuān)家添毅分享了網(wǎng)絡(luò)產(chǎn)品部根據(jù)客戶(hù)和阿里云運(yùn)維的反饋提煉出的幾大最主要和最常見(jiàn)的在使用SLB產(chǎn)品中發(fā)生的問(wèn)題,并為大家介紹了針對(duì)這些常見(jiàn)問(wèn)題的相應(yīng)處理方法。想知道如何借助SLB構(gòu)建高可用系統(tǒng)以及健康檢查是如何實(shí)現(xiàn)的,本文不容錯(cuò)過(guò)!
本文內(nèi)容根據(jù)演講嘉賓分享視頻以及PPT整理而成。
本次的分享將會(huì)主要圍繞以下5個(gè)部分
基本概念回顧
如何構(gòu)建高可用系統(tǒng)
選擇性能共享型還是性能保障型實(shí)例
為什么健康檢查異常
為什么負(fù)載不均衡
一、基本概念回顧
SLB是什么
SLB是阿里云推出的一款云負(fù)載均衡服務(wù),其主要針對(duì)于多臺(tái)云服務(wù)器進(jìn)行流量分發(fā),能夠?qū)I(yè)務(wù)流量分發(fā)到由多臺(tái)云服務(wù)器所組成的后端服務(wù)器池上去,以此來(lái)提升系統(tǒng)的處理能力。負(fù)載均衡所解決的問(wèn)題主要包括兩點(diǎn):第一點(diǎn),SLB能夠消除系統(tǒng)的單點(diǎn)故障,這是因?yàn)镾LB的后面是由多臺(tái)云服務(wù)器組成的服務(wù)器池,那么當(dāng)其中某一臺(tái)服務(wù)器出現(xiàn)故障的時(shí)候并不會(huì)影響整個(gè)系統(tǒng)的可服務(wù)性。第二點(diǎn),由于后端的云服務(wù)器能夠橫向地進(jìn)行擴(kuò)展,所以也具有為海量業(yè)務(wù)提供服務(wù)的能力。那么,為什么要使用云上的負(fù)載均衡呢?這是因?yàn)樵粕县?fù)載均衡主要有這樣的幾個(gè)特點(diǎn):高可靠、高性能、低成本、安全性、易用性。
SLB基本組件
阿里云的SLB主要包括了三個(gè)基本組件,這里也進(jìn)行簡(jiǎn)單地介紹。第一個(gè)基本組件就是實(shí)例,每個(gè)實(shí)例都唯一地標(biāo)識(shí)了云負(fù)載均衡器,并且每個(gè)實(shí)例都對(duì)應(yīng)一個(gè)VIP,VIP唯一地標(biāo)識(shí)了負(fù)載均衡實(shí)例,也是負(fù)載均衡對(duì)外提供服務(wù)的地址。第二個(gè)組件是監(jiān)聽(tīng),監(jiān)聽(tīng)是由VIP+端口號(hào)來(lái)唯一標(biāo)識(shí)的,一個(gè)監(jiān)聽(tīng)中包含用戶(hù)定制的負(fù)載均衡策略和轉(zhuǎn)發(fā)規(guī)則。最后一個(gè)基本組件就是后端掛載的服務(wù)器,也就是云服務(wù)器ECS,負(fù)責(zé)處理真正的業(yè)務(wù)請(qǐng)求。
二、如何構(gòu)建高可用系統(tǒng)
多層次的高可用
如下圖所示,阿里云的負(fù)載均衡是從四個(gè)層面上去構(gòu)建高可用的。從底層往上層看,分別是應(yīng)用級(jí)別的高可用、集群級(jí)別的高可用、可用區(qū)級(jí)別(AZ)的高可用以及地域級(jí)別(Region)的高可用。
應(yīng)用級(jí)別的高可用主要是通過(guò)針對(duì)SLB后端的ECS實(shí)例的健康檢查來(lái)實(shí)現(xiàn)的。當(dāng)SLB發(fā)現(xiàn)后端不健康的或者不能正常工作的ECS的時(shí)候,會(huì)將這些不健康的ECS從SLB的轉(zhuǎn)發(fā)路徑中剔除掉,保證業(yè)務(wù)流量能夠轉(zhuǎn)發(fā)到正常的工作服務(wù)器當(dāng)中。集群級(jí)別的高可用主要是通過(guò)集群中LVS機(jī)器間的session同步來(lái)保障任何一個(gè)用戶(hù)的業(yè)務(wù)會(huì)話都能夠在所有的LVS機(jī)器上是相互同步的,當(dāng)其中某一臺(tái)LVS出現(xiàn)故障時(shí),可以由其他的LVS來(lái)接替出現(xiàn)故障的機(jī)器的工作。同時(shí),由于會(huì)話保持的存在,用戶(hù)的業(yè)務(wù)是不會(huì)發(fā)生中斷的。對(duì)于可用區(qū)級(jí)別的高可用和地域級(jí)別的高可用,在本文的后面會(huì)進(jìn)行更加詳細(xì)的介紹。
細(xì)說(shuō)可用區(qū)級(jí)別容災(zāi)
這里詳細(xì)地介紹一下可用區(qū)級(jí)別的容災(zāi)。可用區(qū)級(jí)別容災(zāi)的設(shè)計(jì)初衷是在當(dāng)一個(gè)可用區(qū)出現(xiàn)重大災(zāi)情的時(shí)候,比如整個(gè)可用區(qū)的機(jī)房發(fā)生了掉電、光纜出現(xiàn)了中斷、整個(gè)可用區(qū)機(jī)房中所有的物理機(jī)都無(wú)法正常工作的時(shí)候,也就是整個(gè)可用區(qū)都宕掉了的情況下,能夠由備可用區(qū)來(lái)繼續(xù)提供服務(wù),這就是可用區(qū)級(jí)別容災(zāi)的設(shè)計(jì)初衷??捎脜^(qū)級(jí)別的容災(zāi)并不是說(shuō)某一個(gè)可用區(qū)中的某一個(gè)實(shí)例或者是某幾個(gè)實(shí)例出現(xiàn)了故障就會(huì)發(fā)生可用區(qū)的切換,實(shí)例自動(dòng)從可用區(qū)A切換到可用區(qū)B,這是一個(gè)比較常見(jiàn)的誤區(qū)。而針對(duì)于這樣的誤區(qū),阿里云也建議用戶(hù)在構(gòu)建可用區(qū)級(jí)別的高可用的時(shí)候采取以下兩個(gè)步驟:
首先,建議用戶(hù)在SLB實(shí)例的后端盡可能地去掛載多個(gè)可用區(qū)的ECS實(shí)例。SLB能夠支持跨可用區(qū)地掛載ECS云服務(wù)器,這樣可以避免某個(gè)可用區(qū)的ECS都出現(xiàn)故障的情況下,還有其他可用區(qū)的ECS能夠接替工作,雖然跨可用區(qū)掛在ECS會(huì)存在大約2毫秒左右的延遲,但是卻能夠大大地提升服務(wù)的可用性。
第二步就是針對(duì)于一些特別重要的業(yè)務(wù),建議在不同的可用區(qū)分別地去購(gòu)買(mǎi)SLB的實(shí)例。比如在可用區(qū)A和可用區(qū)B各自購(gòu)買(mǎi)一個(gè)SLB實(shí)例,在此基礎(chǔ)之上再使用全球負(fù)載均衡GSLB來(lái)進(jìn)行實(shí)例間的調(diào)度。
跨地域容災(zāi)的實(shí)現(xiàn)
跨地域容災(zāi)這一部分與上面介紹的可用區(qū)級(jí)別容災(zāi)的第二步非常相似,也是借助于GSLB產(chǎn)品實(shí)現(xiàn)的,GSLB即 智能DNS實(shí)現(xiàn)了針對(duì)于后端的健康檢查、路由調(diào)度的優(yōu)化功能,能夠?qū)崿F(xiàn)在地域之間的負(fù)載均衡實(shí)例的調(diào)度。關(guān)于這部分的更詳細(xì)的內(nèi)容請(qǐng)參考:全球負(fù)載均衡跨地域容災(zāi)解決方案()。
三、選擇性能共享型還是性能保障型實(shí)例
共享型vs保障型-WHY保障型
在如今這個(gè)共享經(jīng)濟(jì)的時(shí)代,像滴滴打車(chē)這樣的模式是非常火的。但是即便是有了滴滴打車(chē),但是還有人會(huì)去買(mǎi)車(chē),這是因?yàn)闀?huì)出現(xiàn)如下兩個(gè)大家可能曾經(jīng)都碰到過(guò)的場(chǎng)景:
早晚高峰叫不到車(chē)?雨雪天氣路邊凍成狗?還大幅提價(jià)?
假期想遠(yuǎn)離塵囂,找個(gè)僻靜曠野放空自我,叫個(gè)滴滴?也許有去,但保證無(wú)回!
所以說(shuō)共享和保障都是客戶(hù)的需求。出于對(duì)于類(lèi)似需求的考慮,阿里云的負(fù)載均衡也推出了性能保障型實(shí)例。以前所推出的SLB共享型實(shí)例是因?yàn)樾阅苤笜?biāo)沒(méi)有辦法實(shí)現(xiàn)隔離,因?yàn)樗械墓蚕硇蛯?shí)例都處于同一個(gè)大共享資源池中,所以在高峰期的時(shí)候就會(huì)出現(xiàn)資源的爭(zhēng)搶?zhuān)@樣就無(wú)法滿(mǎn)足對(duì)于性能具有剛性需求的大客戶(hù)的訴求。除此之外,還有一些體量特別大的超級(jí)用戶(hù),他們對(duì)于性能的要求會(huì)是非常高的,但是由于共享型實(shí)例無(wú)法做到性能隔離,也支持不了大顆粒度的性能指標(biāo),所以也無(wú)法完成這樣的工作。因此,阿里云推出了性能保障型的負(fù)載均衡實(shí)例。
超強(qiáng)性能
保障型實(shí)例的性能規(guī)格如上圖所示,其并發(fā)連接數(shù)最大可以達(dá)到500萬(wàn),每秒的新建鏈接數(shù)(CPS)可以達(dá)到50萬(wàn),針對(duì)于七層負(fù)載均衡系統(tǒng)的QPS可以達(dá)到10萬(wàn)。除此之外,性能保障型實(shí)例還具有以下的特點(diǎn):
超強(qiáng)HTTPS性能。 性能保障型實(shí)例針對(duì)于七層系統(tǒng),特別是HTTPS的業(yè)務(wù)進(jìn)行了優(yōu)化,實(shí)現(xiàn)了高性能硬加解卡,并且能夠?qū)崿F(xiàn)使HTTPS的業(yè)務(wù)單實(shí)例可達(dá)10萬(wàn)QPS。
超大并發(fā)連接數(shù)。 性能保障型實(shí)例的單實(shí)例的并發(fā)連接數(shù)可達(dá)500萬(wàn),所以其可承載物聯(lián)網(wǎng)場(chǎng)景的下海量連接,可以支撐共享自行車(chē)、智能手表等存在特別大量長(zhǎng)連接的場(chǎng)景。
共享型實(shí)例平滑升級(jí)。 原有的共享型實(shí)例可以平滑升級(jí)至性能保障型實(shí)例,而無(wú)需更換VIP。
完善的業(yè)務(wù)監(jiān)控系統(tǒng)。 在推出性能保障型實(shí)例之后,因?yàn)槊總€(gè)實(shí)例都有相應(yīng)的性能規(guī)格和性能指標(biāo),所以阿里云也為用戶(hù)提供了完整的業(yè)務(wù)指標(biāo)監(jiān)控系統(tǒng),并支持電話、短信、釘釘企業(yè)群等方式的告警。
性能規(guī)格
上圖所展現(xiàn)的是阿里云SLB性能保障型實(shí)例的規(guī)格參數(shù)。圖中的最后兩行規(guī)格7、8默認(rèn)在控制臺(tái)上是無(wú)法購(gòu)買(mǎi)的,目前只針對(duì)企業(yè)級(jí)用戶(hù),而且需通過(guò)客戶(hù)經(jīng)理申請(qǐng)后,通過(guò)白名單開(kāi)放。
如何選擇規(guī)格
對(duì)于保障型實(shí)例而言,主要有如下幾個(gè)性能指標(biāo):
最大連接數(shù):一個(gè)實(shí)例可承載的最大連接數(shù)。
新建連接數(shù):CPS表示一個(gè)實(shí)例每秒可以新建的鏈接數(shù)。
每秒查詢(xún)數(shù):QPS表示一個(gè)實(shí)例7層的像HTTP或者HTTPS系統(tǒng)的吞吐量。
通常一個(gè)4層SLB的性能好壞由最大連接數(shù)和新建連接數(shù)來(lái)衡量,它們表示了一個(gè)SLB系統(tǒng)的并發(fā)能力和處理突發(fā)連接的能力。通常一個(gè)7層SLB的性能好壞主要由QPS決定,QPS表示了一個(gè)7層系統(tǒng)的吞吐量。這里需要注意的是QPS是7層獨(dú)有概念。雖然每個(gè)規(guī)格都定義了三個(gè)性能指標(biāo),但是這并不代表這三個(gè)性能指標(biāo)在任何一個(gè)性能場(chǎng)景下或者任何一個(gè)時(shí)刻都能夠同時(shí)達(dá)到最大值,這里存在一個(gè)性能指標(biāo)的短木板原則。比如在某一個(gè)應(yīng)用系統(tǒng)中,QPS已經(jīng)達(dá)到指標(biāo)上限,但最大連接數(shù)還遠(yuǎn)遠(yuǎn)沒(méi)有達(dá)到上限,這時(shí)不論怎樣加大客戶(hù)端數(shù)量,最大連接數(shù)都會(huì)因?yàn)镼PS達(dá)到上限,而無(wú)法達(dá)到最大值。
對(duì)于規(guī)格的選擇而言,需要通過(guò)之前提到的業(yè)務(wù)監(jiān)控系統(tǒng)來(lái)獲取相關(guān)指標(biāo)。如果用戶(hù)十分了解自己業(yè)務(wù)的相關(guān)指標(biāo),也就是對(duì)于高峰期的并發(fā)連接數(shù)會(huì)達(dá)到多少以及QPS會(huì)達(dá)到多少都有非常清晰的了解,也可以直接在控制臺(tái)上選購(gòu)。但是如果用戶(hù)并不清楚自己的相關(guān)業(yè)務(wù)指標(biāo),可以在初期選購(gòu)按量付費(fèi)的較高規(guī)格的實(shí)例,并且在一個(gè)業(yè)務(wù)周期內(nèi)監(jiān)控流量的峰值,在峰值確定好之后再通過(guò)變配的方式改變到比較合適的實(shí)例規(guī)格。目前性能保障型實(shí)例還處于公測(cè)階段,所以現(xiàn)在還沒(méi)有對(duì)于實(shí)例收取規(guī)格費(fèi)用,也就是說(shuō)在這個(gè)階段無(wú)論用戶(hù)選擇最小規(guī)格還是最大規(guī)格,實(shí)際上都只需要花費(fèi)IP配置費(fèi)和帶寬費(fèi)就可以了,這樣也比較便于用戶(hù)去熟悉和使用阿里云的性能保障型實(shí)例。
監(jiān)控和告警
前面也有所提及,在負(fù)載均衡的控制臺(tái)上面能夠直接地顯示出相應(yīng)的一些性能指標(biāo),但是在這里只能夠?qū)崿F(xiàn)對(duì)于性能指標(biāo)的監(jiān)控,卻無(wú)法進(jìn)行告警。如果用戶(hù)需要進(jìn)行監(jiān)控告警,可以在阿里云所提供的云監(jiān)控控制臺(tái)進(jìn)行操作。云監(jiān)控平臺(tái)可以監(jiān)控阿里云中的所有產(chǎn)品并且實(shí)現(xiàn)業(yè)務(wù)告警的定制,并且可以選擇包括短信郵件、電話、企業(yè)釘釘群等方式進(jìn)行業(yè)務(wù)的實(shí)時(shí)告警。
四、為什么健康檢查異常
健康檢查機(jī)制
接下來(lái)分享在負(fù)載均衡的日常使用中出現(xiàn)的問(wèn)題,特別是很多用戶(hù)都存在疑問(wèn)的健康檢查部分的問(wèn)題。
阿里云的負(fù)載均衡一共可以支持四種協(xié)議,四層的負(fù)載均衡系統(tǒng)主要包括了TCP、HTTP以及UDP協(xié)議,而七層的系統(tǒng)則包括了HTTP和HTTPS,而由于目前HTTP和HTTPS都是使用的普通的HTTP方式,所以其實(shí)也可以歸結(jié)為三類(lèi)協(xié)議。對(duì)于TCP而言,健康檢查的過(guò)程是通過(guò)發(fā)送ACK這種TCP的探測(cè)報(bào)文去探測(cè)端口是否仍然存活;對(duì)于HTTP而言,則主要使用的是HEAD的請(qǐng)求方式來(lái)檢查目標(biāo)的頁(yè)面是否正常;UDP部分則主要借鑒了SMP協(xié)議的原理。
健康檢查部分主要會(huì)涉及到幾個(gè)指標(biāo),這些指標(biāo)需要用戶(hù)在控制臺(tái)上進(jìn)行設(shè)置,上圖中給出了一些默認(rèn)的建議值,比如響應(yīng)的超時(shí)時(shí)間,也就是在每一次進(jìn)行健康檢查的時(shí)候,如果超過(guò)一定時(shí)間健康檢查還沒(méi)有回應(yīng)就認(rèn)為這次的健康檢查是失敗的;還有健康檢查間隔,也就是兩次健康檢查之間通常需要間隔2秒鐘;而所謂的不健康閥值和健康閥值就是在網(wǎng)絡(luò)環(huán)境中往往會(huì)由于網(wǎng)絡(luò)的抖動(dòng)以及其他的因素導(dǎo)致偶爾的一次健康檢查失敗了,但是這時(shí)候并不能認(rèn)為服務(wù)是真的失敗了,所以需要設(shè)置一個(gè)閥值,比如3次就指的是當(dāng)3次健康檢查都失敗的時(shí)候才會(huì)認(rèn)為后端的服務(wù)是存在問(wèn)題的,然后將其從轉(zhuǎn)發(fā)路徑中摘除掉。同樣的,當(dāng)服務(wù)從不健康變?yōu)榻】档臅r(shí)候,也需要進(jìn)行連續(xù)的幾次探測(cè),當(dāng)確定處于穩(wěn)定的健康狀態(tài)之后再將其加入到SLB的后端中去。
為啥會(huì)失敗(TCP)
TCP的健康檢查也經(jīng)常會(huì)出現(xiàn)一些失敗的情況,這里也為大家提供了簡(jiǎn)單的故障排查順序供參考。當(dāng)出現(xiàn)健康檢查失敗的時(shí)候,首先可以檢查一下后端的服務(wù)器是否已經(jīng)啟動(dòng)。如果后端服務(wù)器的負(fù)載是比較高的,也可能會(huì)因?yàn)闆](méi)有CPU時(shí)間去處理健檢查的回應(yīng),這樣就有可能導(dǎo)致健康檢查失敗。除此之外,因?yàn)閷?duì)于阿里云的負(fù)載均衡而言,健康檢查使用的都是私網(wǎng)地址實(shí)現(xiàn)的,所以如果根本沒(méi)有監(jiān)聽(tīng)到私網(wǎng)地址或者私網(wǎng)地址本身存在故障也會(huì)導(dǎo)致健康檢查的失敗。還有服務(wù)器上可能存在防火墻,將監(jiān)聽(tīng)端口屏蔽掉了,導(dǎo)致健康檢查并未通過(guò)。此外還可能存在一些配置方面的問(wèn)題,比如提供服務(wù)的端口和做健康檢查的端口不一致也可能存在健康檢查失敗。
針對(duì)于TCP的健康檢查而言,很多用戶(hù)會(huì)經(jīng)??吹阶约旱暮蠖朔?wù)器上日志上面有很多10或者16這些網(wǎng)段的訪問(wèn),并且訪問(wèn)流量還比較大,這是因?yàn)橹八岬降慕】禉z查具有一定的間隔時(shí)間,比如2秒或者3秒一次。這時(shí)候一些用戶(hù)可能就會(huì)認(rèn)為健康檢查會(huì)影響服務(wù)器的性能,占了很多的服務(wù)器的連接數(shù)。其實(shí)可以從上圖中左側(cè)的報(bào)文交互情況看到,當(dāng)SLB對(duì)于云服務(wù)器發(fā)起健康檢查的時(shí)候首先會(huì)發(fā)一個(gè)SYN的請(qǐng)求,如果服務(wù)器端口是存活的,那么它會(huì)回應(yīng)一個(gè)ACK,這個(gè)時(shí)候SLB端就會(huì)緊接著發(fā)送RST報(bào)文。也就是說(shuō)實(shí)際上連接是并沒(méi)有建立的,所以也不會(huì)占用后端服務(wù)器的連接數(shù)的資源,并且對(duì)于性能的影響也是極為有限的。
為啥會(huì)失敗(HTTP)
HTTP常見(jiàn)的健康檢查失敗原因大概會(huì)有這樣的三點(diǎn):最常見(jiàn)的情況就是有些用戶(hù)把服務(wù)器的HEAD請(qǐng)求方式禁掉了,因?yàn)槟J(rèn)在使用瀏覽器或者手機(jī)等請(qǐng)求一個(gè)頁(yè)面的時(shí)候使用的都是GET方式,有時(shí)候可能需要上傳數(shù)據(jù)則會(huì)使用POST方式,雖然很多服務(wù)器都支持HEAD請(qǐng)求方式,但是有些服務(wù)器可能會(huì)處于安全或者其他復(fù)雜因素的考慮將HEAD請(qǐng)求禁掉。所以在這里建議客戶(hù)將服務(wù)器的HEAD請(qǐng)求方式打開(kāi),因?yàn)榘⒗镌曝?fù)載均衡七層健康檢查方案就是使用的HEAD方案。另外一種常見(jiàn)情況就是頁(yè)面訪問(wèn)本身上就存在問(wèn)題,這樣的情況下健康檢查也是無(wú)法通過(guò)的。最后一種常見(jiàn)情況就是期望結(jié)果配置錯(cuò)誤,針對(duì)于七層的健康檢查是通過(guò)使用HEAD請(qǐng)求方式去請(qǐng)求頁(yè)面,頁(yè)面返回碼可能會(huì)是200、300或者400以及500等,用戶(hù)可以在健康檢查的配置中設(shè)定預(yù)期的正常情況下的返回碼值,當(dāng)健康檢查返回碼值與預(yù)期值不一致就會(huì)判定健康檢查是失敗的。
為啥會(huì)失敗(UDP)
這里介紹一下UDP健康檢查的原理。首先,健康檢查通過(guò)SLB向后端發(fā)送UDP報(bào)文探測(cè)來(lái)獲取狀態(tài)信息。SLB會(huì)周期性地給后端ECS發(fā)送UDP報(bào)文,如果UDP端口的業(yè)務(wù)處于正常情況,則沒(méi)有任何回應(yīng)。而當(dāng)服務(wù)出現(xiàn)問(wèn)題,比如指定的UDP服務(wù)端口處于不可達(dá)的情況或者無(wú)服務(wù)的狀態(tài)的時(shí)候,會(huì)回復(fù)ICMP的不可達(dá)報(bào)文。這里也會(huì)存在一個(gè)問(wèn)題就是如果后端服務(wù)器已經(jīng)變成了網(wǎng)絡(luò)中的孤島,比如出現(xiàn)了整個(gè)服務(wù)器的掉電、關(guān)機(jī)情況這樣完全不能工作的狀態(tài),這時(shí)候的ICMP不可達(dá)報(bào)文是永遠(yuǎn)不可能收到的,因?yàn)楹蠖说姆?wù)器無(wú)法收到SLB發(fā)來(lái)的UDP探測(cè)報(bào)文,那么在這種情況下,可能會(huì)出現(xiàn)誤認(rèn)為后端健康的情況,但是實(shí)際上這個(gè)服務(wù)可能已經(jīng)宕掉了。為了應(yīng)對(duì)這種情況,健康檢查還提供用戶(hù)自定義UDP應(yīng)答報(bào)文來(lái)實(shí)現(xiàn)精確的UDP健康檢查,也就是由用戶(hù)自定義指定一個(gè)字符串,當(dāng)后端的云服務(wù)器收到UDP健康檢查的探測(cè)的時(shí)候,也回應(yīng)指定的字符串,之后SLB對(duì)于這個(gè)字符串進(jìn)行對(duì)比和校驗(yàn),如果匹配成功則認(rèn)為服務(wù)一定是健康的,這樣就可以實(shí)現(xiàn)非常精確的健康檢查。
而UDP的健康檢查失敗也有很多原因,比如在協(xié)議棧里面有可能會(huì)有ICMP限速保護(hù)。當(dāng)頻率達(dá)到一定速率的時(shí)候,ICMP會(huì)被協(xié)議棧限制,后端無(wú)法回應(yīng)ICMP不可達(dá)報(bào)文,進(jìn)而導(dǎo)致SLB收不到ICMP的報(bào)文,出現(xiàn)健康檢查的失敗情況。所以這部分是需要注意的,如果可能盡量將速率限制放大一些。
其他問(wèn)題
健康檢查時(shí)好時(shí)壞的可能原因如下:
HTTP類(lèi)型健康檢查目標(biāo)URI響應(yīng)慢。比如本身是動(dòng)態(tài)頁(yè)面,會(huì)涉及到大量的計(jì)算才能夠渲染完成并返回到前端,這樣肯定就會(huì)導(dǎo)致健康檢查響應(yīng)比較慢。如果服務(wù)器負(fù)載過(guò)高同樣也會(huì)出現(xiàn)這樣的問(wèn)題。
未全部放開(kāi)對(duì)SLB健康檢查源地址的限制導(dǎo)致分布式健康檢查失敗。因?yàn)榘⒗镌频姆?wù)器都是分布式的部署,健康檢查也會(huì)是分布式的探測(cè),LVS等機(jī)器在后端有不同的源去針對(duì)某一個(gè)云服務(wù)器進(jìn)行探測(cè)的,所以如果沒(méi)有將這些源地址都放開(kāi),實(shí)際上也會(huì)影響健康檢查的效率,因?yàn)閷?duì)于這么多機(jī)器而言,只要有一臺(tái)機(jī)器檢測(cè)到是正常的那么就是正常的。
還可能出現(xiàn)直接訪問(wèn)正常,但是健康檢查失敗的情況。造成這樣情況的可能原因如下:
防火墻限制。
目的端口不一致。
檢查方法不同,可能使用瀏覽器看頁(yè)面是沒(méi)問(wèn)題的,但是健康檢查卻不行,這就是因?yàn)閯偛潘岬降腍EAD方法沒(méi)有開(kāi)啟?;蛘咂邔拥慕】禉z查配置了URL按照域名轉(zhuǎn)發(fā),但是在瀏覽器上直接訪問(wèn)則是使用域名去做的,而健康檢查是使用IP地址做的,這樣也可能出現(xiàn)轉(zhuǎn)發(fā)和預(yù)期結(jié)果的不同。
檢查頻率不同,ICMP限速。
五、為什么負(fù)載不均衡
調(diào)度算法與會(huì)話保持
首先介紹一下負(fù)載均衡的調(diào)度算法。阿里云的負(fù)載均衡支持三種算法,第一種算法是單純的輪詢(xún)(RR),也就是將業(yè)務(wù)的請(qǐng)求依次地分發(fā)到后端的服務(wù)器。第二種算法是加權(quán)輪詢(xún)(WRR),也就是在處理調(diào)度的時(shí)候會(huì)根據(jù)針對(duì)于每一臺(tái)后端服務(wù)器設(shè)置權(quán)重來(lái)進(jìn)行轉(zhuǎn)發(fā)。這里之所以設(shè)置權(quán)重是因?yàn)楹蠖朔?wù)器的處理能力可能是不同的,如果使用相同的權(quán)重進(jìn)行輪詢(xún)可能就會(huì)把后端處理能力比較弱的服務(wù)器擠爆,所以需要針對(duì)于服務(wù)器的處理能力設(shè)置一些權(quán)重。第三種算法是針對(duì)于加權(quán)最小連接數(shù)的輪詢(xún)(WLC),也就是除了根據(jù)每臺(tái)后端服務(wù)器設(shè)定的權(quán)重值來(lái)進(jìn)行輪詢(xún),同時(shí)還考慮后端服務(wù)器的實(shí)際負(fù)載,也就是連接數(shù)。當(dāng)權(quán)重值相同時(shí),當(dāng)前連接數(shù)越小的后端服務(wù)器被輪詢(xún)到的次數(shù)也越高,這樣就能夠保證負(fù)載盡量地均衡。如果不考慮這一點(diǎn)就會(huì)造成某些服務(wù)器連接數(shù)已經(jīng)很高了但是流量依然還往上面分發(fā),而另外一些服務(wù)器卻一直處于空閑狀態(tài)。
會(huì)話保持指的是來(lái)自同一用戶(hù)請(qǐng)求始終保持分發(fā)到同一臺(tái)后端的云服務(wù)器上。對(duì)于同一用戶(hù)而言,使用的是四層的負(fù)載均衡和使用七層的負(fù)載均衡在理解上是不一樣的。如果是四層負(fù)載均衡,則會(huì)使用源IP地址標(biāo)識(shí)同一用戶(hù),所以如果在可能會(huì)有很多辦公電腦的大型企業(yè)中,這些電腦在企業(yè)內(nèi)部是通過(guò)局域網(wǎng)的IP進(jìn)行通信的,在訪問(wèn)公網(wǎng)的時(shí)候都是通過(guò)NAT網(wǎng)關(guān)處理的,所以在走到Internet的時(shí)候,源地址通常會(huì)是一個(gè)或者很有限的幾個(gè)。在這種情況下,如果是四層的負(fù)載均衡就會(huì)把里面所有的請(qǐng)求都視為來(lái)自同一個(gè)用戶(hù)的,這種情況下如果開(kāi)啟了會(huì)話保持,就會(huì)發(fā)生問(wèn)題。而七層的負(fù)載均衡是根據(jù)用戶(hù)瀏覽器中的Cookie來(lái)進(jìn)行唯一識(shí)別的,對(duì)于剛才的案例在大型企業(yè)里面因?yàn)閮?nèi)網(wǎng)訪問(wèn)公網(wǎng)的源地址都是一樣的,導(dǎo)致沒(méi)有辦法識(shí)別到底是不是同一個(gè)用戶(hù),此時(shí)建議使用七層的負(fù)載均衡方案解決,因?yàn)镃ookie是每個(gè)瀏覽器都唯一的。會(huì)話的保持時(shí)間是可以在控制臺(tái)上配置的,四層的負(fù)載均衡方案最大可達(dá)1小時(shí),而七層的方案最大可達(dá)24小時(shí)。
為何不均衡
最后分享一下不均衡的常見(jiàn)情況。有時(shí)候會(huì)需要新加一個(gè)服務(wù)器進(jìn)來(lái),這時(shí)候往往到新加進(jìn)來(lái)的服務(wù)器上的連接會(huì)很少,這是因?yàn)榭赡軙?huì)存在以下原因:
存在會(huì)話保持的情況下,會(huì)話保持會(huì)讓請(qǐng)求停留在原有的服務(wù)器上,這樣到新加進(jìn)來(lái)的服務(wù)器上的連接自然會(huì)少一些。
權(quán)重設(shè)置不一致,如果在權(quán)重的設(shè)置上存在區(qū)別,而新加進(jìn)來(lái)的服務(wù)器的權(quán)重如果很低,連接也過(guò)不去。
應(yīng)用屬于長(zhǎng)連接類(lèi)型,因?yàn)樾枰赥CP上復(fù)用,如果客戶(hù)端不主動(dòng)斷開(kāi)連接,后續(xù)所有的請(qǐng)求都會(huì)繼續(xù)復(fù)用當(dāng)前服務(wù)器上的連接,只有新建連接才有可能到新的服務(wù)器上。
而有時(shí)候在業(yè)務(wù)量或者新建連接較少時(shí),也會(huì)出現(xiàn)負(fù)載不均衡的問(wèn)題。這是因?yàn)槊總€(gè)Core都是獨(dú)立的調(diào)度單元,因此可能存在將某個(gè)Client的多條業(yè)務(wù)經(jīng)過(guò)不同core的調(diào)度后全部轉(zhuǎn)發(fā)到一臺(tái)ECS上的情況,同時(shí)由于業(yè)務(wù)量較少,因此出現(xiàn)了不均衡。建議使用輪詢(xún)算法解決,在RR輪詢(xún)算法中加入了擾亂因子,可以更加有效的打散SLB到后端的轉(zhuǎn)發(fā)路徑。
原文鏈接
DNS:
本身可用性比較高,會(huì)有一個(gè)本地機(jī)房的local dns,如果這個(gè)local dns掛掉,會(huì)走其他機(jī)房的dns
dns不可用預(yù)案:
(1) 綁定hosts
(2) 開(kāi)啟NSCD,相當(dāng)于本地dns緩存,可以防止一些抖動(dòng)情況,且可以防止對(duì)dns的壓力過(guò)大
SLB:
slb本身具備高可用機(jī)制,每個(gè)slb都會(huì)有主有備(且是在其他可用區(qū)),如果主掛掉,備會(huì)接替主,同時(shí)我們slb會(huì)是一個(gè)集群,至少3臺(tái),掛了其中一臺(tái)(立馬下掉),其他可以承受整體流量
slb不可用預(yù)案:
對(duì)slb有一系列的監(jiān)控,如果有問(wèn)題能立馬感知,同時(shí)我們有slb一鍵擴(kuò)容功能(在開(kāi)發(fā))
負(fù)載均衡構(gòu)建在原有網(wǎng)絡(luò)結(jié)構(gòu)之上,它提供了一種透明且廉價(jià)有效的方法擴(kuò)展服務(wù)器和網(wǎng)絡(luò)設(shè)備的帶寬、加強(qiáng)網(wǎng)絡(luò)數(shù)據(jù)處理能力、增加吞吐量、提高網(wǎng)絡(luò)的可用性和靈活性。
擁有大量用戶(hù)的企業(yè),經(jīng)常會(huì)面臨如下的難題:在高并發(fā)的情況下,經(jīng)常會(huì)導(dǎo)致服務(wù)器響應(yīng)速度慢,嚴(yán)重的情況會(huì)直接導(dǎo)致服務(wù)器停止服務(wù)。此時(shí),會(huì)導(dǎo)致企業(yè)的業(yè)務(wù)中斷,影響客戶(hù)的正常訪問(wèn)。
負(fù)載均衡應(yīng)運(yùn)而生
u需求:本次實(shí)驗(yàn)最低需求兩臺(tái)云服務(wù)器ECS/u
上圖創(chuàng)建了兩臺(tái)云服務(wù)器ECS實(shí)例和一個(gè)負(fù)載均衡實(shí)例,它們各自擁有各自的彈性IP地址
在瀏覽器兩個(gè)頁(yè)面分別輸入兩臺(tái)云服務(wù)器ECS的彈性IP訪問(wèn)
比較兩臺(tái)ECS的訪問(wèn)結(jié)果,發(fā)現(xiàn)部署的網(wǎng)站內(nèi)容相同,只是顯示的后端服務(wù)器IP不同。
在阿里云登陸界面選擇用RAM用戶(hù)登錄
使用實(shí)驗(yàn)提供的 子用戶(hù)名稱(chēng) 和 子用戶(hù)名密碼 登陸阿里云管理控制臺(tái)
img src="" alt="4.登陸.png" style="zoom:50%;" /
img src="" alt="5.登陸.png" style="zoom:50%;" /
登錄后點(diǎn)擊左側(cè) 導(dǎo)航欄的 產(chǎn)品與服務(wù) 選擇 負(fù)載均衡
img src="" alt="6.png" style="zoom: 67%;" /
a. 在控制臺(tái)點(diǎn)擊左側(cè) 實(shí)例管理 ,在右側(cè)頁(yè)面中的紅框處看到負(fù)載均衡的 公網(wǎng)服務(wù)地址
該公網(wǎng)服務(wù)地址即為負(fù)載均衡實(shí)例的彈性IP地址
b.在瀏覽器上輸入a的公網(wǎng)服務(wù)地址并訪問(wèn)
可見(jiàn)后端服務(wù)器IP尾數(shù)為131(ECS-2),但當(dāng)我們刷新一遍后,如下圖
后端服務(wù)器IP尾數(shù)變?yōu)?30(第二臺(tái)ECS-1)
當(dāng)我們不停的刷新,會(huì)發(fā)現(xiàn)后端服務(wù)器IP 實(shí)在這兩臺(tái)ECS的 內(nèi)外地址 之間輪流轉(zhuǎn)換
因?yàn)槲覀冊(cè)诘诙脚渲玫膬膳_(tái)ECS的權(quán)重是相同的
下一步我們?cè)囍淖儍膳_(tái)ECS的權(quán)重不相同看看效果如何
a.進(jìn)入控制臺(tái)--選擇負(fù)載均衡--實(shí)例管理--點(diǎn)擊進(jìn)入實(shí)例--默認(rèn)服務(wù)器組,進(jìn)入如下圖所示
b.勾選兩臺(tái)服務(wù)器--點(diǎn)擊修改權(quán)重
c.設(shè)置權(quán)重 30,90,效果如下圖
d.在瀏覽器中,刷新多次 負(fù)載均衡服務(wù)地址 的頁(yè)面,統(tǒng)計(jì)頁(yè)面的 后端服務(wù)器IP 。
可以發(fā)現(xiàn):每 4 次刷新,將有 3 次訪問(wèn) 權(quán)重 為 90 的 ECS實(shí)例, 1 次訪問(wèn)權(quán)重為 30 的 ECS實(shí)例。
用戶(hù)可以根據(jù)實(shí)際情況調(diào)整負(fù)載均衡器的請(qǐng)求分發(fā),一般將 配置高的服務(wù)器設(shè)置的權(quán)重調(diào)高 , 配置較低的服務(wù)器設(shè)置的權(quán)重調(diào)低 。這樣可以避免在高并發(fā)時(shí),配置較低的服務(wù)器因?yàn)閴毫^大服務(wù)異常的發(fā)生。
a.實(shí)例管理界面---監(jiān)聽(tīng)---修改監(jiān)聽(tīng)配置
b.點(diǎn)擊修改
c.開(kāi)啟會(huì)話保持、可選擇修改會(huì)話保持超時(shí)時(shí)間
d.依次點(diǎn)擊下一步,不修改
e. 再次在瀏覽器中輸入 負(fù)載均衡 的 IP地址 , 多次刷新 ,發(fā)現(xiàn)在會(huì)話保持的超時(shí)時(shí)間內(nèi)請(qǐng)求 只會(huì)分發(fā)到某一臺(tái) ECS 上(究竟是哪一臺(tái) ECS 沒(méi)有規(guī)定),時(shí)間超出后,重新按照權(quán)重比例分發(fā)。
a.進(jìn)入實(shí)例
b.點(diǎn)擊停止
img src="" alt="28.png" style="zoom:67%;" /
c.返回,顯示如下圖所示,ECS-2已關(guān)閉
d.在監(jiān)聽(tīng)頁(yè)面和實(shí)例管理頁(yè)面,健康狀態(tài)顯示異常
e. 再次刷新瀏覽器中 負(fù)載均衡 的 IP地址 ,此時(shí),請(qǐng)求發(fā)送到 健康檢查狀態(tài) 為 正常 的ECS-1上。
ECS是云服務(wù)器
RDS是云數(shù)據(jù)庫(kù)
OSS是對(duì)象存儲(chǔ)
SLB是負(fù)載均衡