2008年5月31日下午5點鐘(當?shù)貢r間)，托管服務(wù)提供商一一地球(The Planet)一一位于休斯敦的數(shù)據(jù)中心的主配電間高壓線短路，導致的爆炸太大了，震倒了三面墻。出于防火安全的考慮也關(guān)閉了備用發(fā)電機。幾天后，部分的電力供應(yīng)得以恢復。但對數(shù)千臺服務(wù)器來說，這種情況下的故障轉(zhuǎn)移卻是指物理上將這些機器運往其他的數(shù)據(jù)中心。



當災(zāi)難襲來，所有你需要考慮的是將用戶流量以最快速度轉(zhuǎn)移，離開問題區(qū)域。你需要立即降低影響。不要過于擔心根源問題的修復，一旦將影響制止住，會有很多時間來解決這次事故。有些少見的事故，如前面提到的爆炸，需要數(shù)周的時間來恢復。但當數(shù)據(jù)中心變得越來越大的時候，即使常見的事故，如短暫的掉電，也可能需要幾天來恢復。讓一個有幾千臺服務(wù)器的數(shù)據(jù)中心運轉(zhuǎn)起來需要很長的時間。在架構(gòu)上要專注于最小化影響的持續(xù)時間，而不是事故持續(xù)時間間(通常它也不在你的掌握之中)。

那么，怎樣才能將流量從問題站點轉(zhuǎn)出呢?通常的方案是使用全局負載均衡(Global Server Load Balancing，GLSB)平臺。這實際是一個動態(tài)的授權(quán)DNS服務(wù)器，它能夠根據(jù)相關(guān)因素對同一域名給出不同的P地址。最常見的因素是鄰近性和可用性。假設(shè)你有兩個服務(wù)器，一個在西海岸，一個在東海岸，有不同的IP地址。當一來自舊金山的瀏覽器查詢你的域名時，GSLB通常會返回西海岸服務(wù)器的IP地址，因為它靠近用戶并產(chǎn)生最佳的性能表現(xiàn)。如果駝鹿吃了西海岸的服務(wù)器，GSLB發(fā)現(xiàn)它不再響應(yīng)，會給出東海岸服務(wù)器的P。這可能有點遠，但至少能工作。

事實上，GSLB并不像這樣簡單，或者說完美，它有兩個主要問題。第一，瀏覽器實際從不直接詢問GSLB。相反，它和當?shù)氐木彺孢f歸DNS服務(wù)器會話。不要和授權(quán)DNS服務(wù)器(如你的GSLB)混淆，當?shù)氐慕馕銎?recursor)為整個用戶群做了大部分的工作，緩存結(jié)果顯著地降低了授權(quán)DNS服務(wù)器的流量，同時又為最終用戶改善了性能。真正和和你的GSLB會話的是解析器。所以，你的平臺只能根據(jù)解析器的位置來決定遠近，它并不知道哪個瀏覽器發(fā)出原始的請求和瀏覽器在哪里。大多數(shù)情況下，ISP提供解析器，他們離最終用戶相當近。因此，基于解析器遠近的路由大體上是合理的。不過，確實有這樣的情況，有人使用離她電腦半個地球那么遠的解析器，這將導致不正確的鄰近性路由，以及較慢的互聯(lián)網(wǎng)體驗。

第二個問題有關(guān)緩存。每個DNS回答被緩存在沿途的各個點。本地解析器緩存，瀏覽器也緩存。如果你的GSLB決定突然返回一個不同的網(wǎng)站建設(shè)IP，那將需要一些時間來讓老地址在緩存中失效，從而讓新地址通過。大部分人在GSLB記錄上設(shè)定1~5分鐘的存活時間(TTL)，所以你可預期流量切換也至少需要這么長的時間(通常會更長一些)。注意有些解析器、瀏覽器與其他設(shè)備因各種理由不遵守TL，它們將永遠掛在老的被駝鹿吃了的P地址上，而不管事實上它已經(jīng)過期，并且不再工作了。結(jié)果在短時間內(nèi)，一小部分用戶就會不能切換到新的數(shù)據(jù)中心。不過其數(shù)量微不足道。因為這些原因，一些人認為GSLB濫用DNS系統(tǒng)，我認為它多數(shù)情況下還是有效的。