当灾难袭来，所有你需要考虑的是将用户流量以最快速度转移，离开问题区域。你需要立即降低影响。不要过于担心根源问题的修复，一旦将影响制止住，会有很多时间来解决这次事故。有些少见的事故，如前面提到的爆炸，需要数周的时间来恢复。但当数据中心变得越来越大的时候，即使常见的事故，如短暂的掉电，也可能需要几天来恢复。让一个有几千台服务器的数据中心运转起来需要很长的时间。在架构上要专注于最小化影响的持续时间，而不是事故持续时间间(通常它也不在你的掌握之中)。
那么，怎样才能将流量从问题站点转出呢?通常的方案是使用全局负载均衡(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系统，我认为它多数情况下还是有效的。
本文地址：//cosda.cn//article/3360.html
