全局服务器负载均衡

对于更大规模的设置，需要的就不仅仅是简单的独立加载的（或活跃/非活跃对）负载平衡器了。对于特定应用领域的大型程序， 可能需要把应用的服务划分成一个或者多个透明的集群。使用第七层负载平衡器，可以把真实的服务器划分成多个池，每个池处理特定集合的URL。这种情况下， 可以按树结构安排负载平衡器，前端平衡器将流量划分到集群，每个集群都有自己的VIP。每个机器都有另一个负载平衡器，在集群的相同节点之间平衡请求。

对这样的负载平衡器配置的需求很少，负载均衡因为可以使用单个智能化的负载平衡器运行整个配置。有些情况下，对于集群级别的第七层负载平衡，可能需要把应用程序划分成多个区域，每个都有它自己的平衡器，以避免hash表的空间被耗尽。

需要大规模平衡负载时，更经常需要的是全局服务器负载平衡（GSLB），从而在两个或者三个DC之间平衡负载。GSLB执 行一些比简单的循环负载平衡更为复杂的函数。使用不同的度量，我们能从最近的DC（这里的最近是指跳跃计数或者跳跃延时）为用户提供内容，尽可能地减少用 户延时。在靠近用户的多个DC处安置应用程序并不少见。如果在美国东海岸和西海岸各有一个DC，在欧洲有一个，东亚有一个，那么总会有一个DC离用户比较 近。

延的长短很重要，但多数据中心负载均衡还带来了一些其他特性，这些特性一般是在数据中心内部负载平衡时所期望的。对我们 而言，其中主要的特性是能检测故障和路由流量以绕过故障点。负载均衡在机器层，常规的负载平衡器能保护我们。如果一台机器出现故障，负载平衡器会停止向它发送流 量。使用GSLB，可以在DC层级做同样的事情——如果一个数据中心下线了，还是能通过其余的数据中心提供所有的流量服务，保持应用程序在线，并且用户根 本意识不到有数据中心下线了。

当然，事情
们的顺序是随机的。客户端尝试第一个地址，负载均衡并且被导向某个DC的负载平衡器，继而到达某个真正的服务器。如果数据中心不在 线，并且IP地址变成unreachable，客户端会尝试列表中的下一个地址，连接到另一个DC的负载平衡器。想要一切都运行良好，就要让负载平衡器理 解，当它后端的所有服务器都不可用了，它需要显示自身处于死机状态。如果介于负载平衡器和后台真实服务器之间的连接被破坏（有可能是某个网络电缆被拔出或 负载均衡者某个交换机失灵），那么我们希望将流量故障转移到另一个数据中心。或者，后台服务器出现故障的那台负载平衡器可以把所有连接都引导到另一个数据中心的 VIP上去。

通过灵活处理DNS请求，可以添加粗略的基于近似关系的DC平衡。当一个DNS请求进入时，可以判断它来自哪个用户，找出 和这个用户最近的数据中心。负载均衡接着把这个数据中心的VIP的IP地址作为DNS响应返回。世界各地的用户请求DNS解析我们的域名时，他们将得到不同的答 案。但这种方法存在一定的问题。这里提到了最近的DC，所谓的远近，是到用户本地的DNS服务器的实际距离。这和用户实际接入网络时所在地点往往是不同 的，有可能超出10跳之远。使用在另一个国家的DNS服务器的用户，会由他本地的DNS服务器所在国家的DC提供服务，而不是根据当前所用的

非HTTP流量
需要平衡的不仅仅是HTTP流量，其他向外部提供的服务或者 自己内部使用的服务也需要流量平衡。向外部用户提供的其他主营服务可能是电子邮件，将一个公开的DNS MX记录指向一个IP地址。就和Web服务一样，可以将这条记录指向一个负载均衡过的VIP，在后端其实有多台机器。和HTTP不一样，在DC服务中断 时，我们还可以处理邮件路由的少量中断。当一台邮件服务器尝试发送邮件到另一台服务器（比如我们的应用程序），并且发现对方无法抵达时，它会把邮件放入队 列，并且以后再次尝试。对于基于DNS的负载平衡，可以只提供最近处的DC的IP地址，在当前选择的DC不可用时，依赖DNS

缓存超时将流量导向新的DC。实际上，电子邮件为我们提供了另一种DNS负载平衡的故障安全的处理方法。在zone文件中的MX记录看起来如下所示：

我们为列出的每个IP地址都附上了一个优先级，首先尝试数值负载均衡最低的那条记录。如果连接失败，继续尝试列表中的下一个，直到 找到可达的服务器。我们完全可以只用DNS接近度平衡来将邮件均衡到地理位置上的各个数据中心，并且无需任何成本即可拥有DC故障转移的语义。所需要做 的，只是给予最近的DC最高优先级（数值最低），给第二接近的DC第二高的优先级（数值第二低），依此类推。

因为SMTP和HTTP如此类似（基于文本的协议，有MIME标头和主体），基本上可以使用HTTP负载平衡来均衡邮件流 量。全部要做的就是创建一个新的服务（从负载平衡器的角度讲）监听端口25，并且将它关联到后台真正的服务器。不同之处在于如何检测真实服务器是否活跃。 只要执行HTTP检查的负载平衡器（比如说Perlbal）就不能均衡SMTP流量——在这样的平衡器看来，端口25上的HTTP后台进程好像已经僵死 了。

要平衡其他种类的流量，可以使用一种欺骗性的手段，将它们封装成HTTP消息，并且使用常规的HTTP负载平衡器。假定应 用程序有一个服务，返回了一个当前用户的对象的列表。一开始，我们可以使用PHP函数调用本地“连接”到这个服务。随着应用程序的增长，我们发现这个服务 组件对CPU要求很高，因此将它分离出来，独占一台机器，并且使用某种定制的基于套接字的协议来和它连接。负载均衡事情进一步演化，当需要把这个服务划分到多台机 器上去时，就需要某种方法来决定对于每个请求使用哪台机器进行连接。如果能更改这个服务，让请求和响应遵循HTTP协议，那么只需要在负责服务的那些机器 前端添加一个负载平衡器，然后通过VIP连接到这个服务。这样就把均衡逻辑从应用程序层级移出，而且看起来就像一直都是连接同一台单独的服务器。