當(dāng)災(zāi)難襲來,所有你需要考慮的是將用戶流量以最快速度轉(zhuǎn)移,離開問題區(qū)域。你需要立即降低影響。不要過于擔(dān)心根源問題的修復(fù),一旦將影響制止住,會(huì)有很多時(shí)間來解決這次事故。有些少見的事故,如前面提到的爆炸,需要數(shù)周的時(shí)間來恢復(fù)。但當(dāng)數(shù)據(jù)中心變得越來越大的時(shí)候,即使常見的事故,如短暫的掉電,也可能需要幾天來恢復(fù)。讓一個(gè)有幾千臺(tái)服務(wù)器的數(shù)據(jù)中心運(yùn)轉(zhuǎn)起來需要很長(zhǎng)的時(shí)間。在架構(gòu)上要專注于最小化影響的持續(xù)時(shí)間,而不是事故持續(xù)時(shí)間間(通常它也不在你的掌握之中)。
那么,怎樣才能將流量從問題站點(diǎn)轉(zhuǎn)出呢?通常的方案是使用全局負(fù)載均衡(Global Server Load Balancing,GLSB)平臺(tái)。這實(shí)際是一個(gè)動(dòng)態(tài)的授權(quán)DNS服務(wù)器,它能夠根據(jù)相關(guān)因素對(duì)同一域名給出不同的P地址。最常見的因素是鄰近性和可用性。假設(shè)你有兩個(gè)服務(wù)器,一個(gè)在西海岸,一個(gè)在東海岸,有不同的IP地址。當(dāng)一來自舊金山的瀏覽器查詢你的域名時(shí),GSLB通常會(huì)返回西海岸服務(wù)器的IP地址,因?yàn)樗拷脩舨a(chǎn)生最佳的性能表現(xiàn)。如果駝鹿吃了西海岸的服務(wù)器,GSLB發(fā)現(xiàn)它不再響應(yīng),會(huì)給出東海岸服務(wù)器的P。這可能有點(diǎn)遠(yuǎn),但至少能工作。
事實(shí)上,GSLB并不像這樣簡(jiǎn)單,或者說完美,它有兩個(gè)主要問題。第一,瀏覽器實(shí)際從不直接詢問GSLB。相反,它和當(dāng)?shù)氐木彺孢f歸DNS服務(wù)器會(huì)話。不要和授權(quán)DNS服務(wù)器(如你的GSLB)混淆,當(dāng)?shù)氐慕馕銎?recursor)為整個(gè)用戶群做了大部分的工作,緩存結(jié)果顯著地降低了授權(quán)DNS服務(wù)器的流量,同時(shí)又為最終用戶改善了性能。真正和和你的GSLB會(huì)話的是解析器。所以,你的平臺(tái)只能根據(jù)解析器的位置來決定遠(yuǎn)近,它并不知道哪個(gè)瀏覽器發(fā)出原始的請(qǐng)求和瀏覽器在哪里。大多數(shù)情況下,ISP提供解析器,他們離最終用戶相當(dāng)近。因此,基于解析器遠(yuǎn)近的路由大體上是合理的。不過,確實(shí)有這樣的情況,有人使用離她電腦半個(gè)地球那么遠(yuǎn)的解析器,這將導(dǎo)致不正確的鄰近性路由,以及較慢的互聯(lián)網(wǎng)體驗(yàn)。
第二個(gè)問題有關(guān)緩存。每個(gè)DNS回答被緩存在沿途的各個(gè)點(diǎn)。本地解析器緩存,瀏覽器也緩存。如果你的GSLB決定突然返回一個(gè)不同的網(wǎng)站建設(shè)IP,那將需要一些時(shí)間來讓老地址在緩存中失效,從而讓新地址通過。大部分人在GSLB記錄上設(shè)定1~5分鐘的存活時(shí)間(TTL),所以你可預(yù)期流量切換也至少需要這么長(zhǎng)的時(shí)間(通常會(huì)更長(zhǎng)一些)。注意有些解析器、瀏覽器與其他設(shè)備因各種理由不遵守TL,它們將永遠(yuǎn)掛在老的被駝鹿吃了的P地址上,而不管事實(shí)上它已經(jīng)過期,并且不再工作了。結(jié)果在短時(shí)間內(nèi),一小部分用戶就會(huì)不能切換到新的數(shù)據(jù)中心。不過其數(shù)量微不足道。因?yàn)檫@些原因,一些人認(rèn)為GSLB濫用DNS系統(tǒng),我認(rèn)為它多數(shù)情況下還是有效的。
本文地址:http://m.hbbqcd.cn//article/3360.html