网站数据影响持续时间对事件持续时间

发布：2018-06-28 18:07:24 浏览：7879

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系统，我认为它多数情况下还是有效的。