2008年5月31日下昼5点钟(本地时光)，托管办事供给商一一地球(ThePlanet)一一位于休斯敦的数据中间的主配电间高压线短路，导致的爆炸太年夜了，震倒了三面墙。出于防火平安的斟酌也封闭了备用发电机。几天后，部门的电力供给得以恢复。但对数千台办事器来说，这种情形下的故障转移倒是指物理大将这些机械运往其他的数据中间。

当灾害袭来，所有你须要斟酌的是将用户流量以最快速度转移，分开问题区域。你须要立刻下降影响。不要过于担忧根源问题的修复，一旦将影响禁止住，会有许多时光来解决此次变乱。有些少见的变乱，如前面提到的爆炸，须要数周的时光来恢复。但当数据中间变得越来越年夜的时刻，即使常见的变乱，如短暂的失落电，也可能须要几天来恢复。让一个有几千台办事器的数据中间运转起来须要很长的时光。在架构上要专注于最小化影响的连续时光，而不是变乱连续时光间(平日它也不在你的控制之中)。

那么，如何能力将流量从问题站点转出呢?平日的计划是应用全局负载平衡(GlobalServerLoadBalancing，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体系，我以为它多半情形下照样有用的。