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