负载均衡设备的URL哈希(HASH)功能主要应用在两种场合:
1. 大型网站。大型网站为了提高访问速率,将视频和图片等可缓存的内容缓存到CDN节点。每个CDN节点有很多台缓存服务器,前端配置负载均衡器进行流量分 担。为了提高缓存服务器的存储效率和命中率,负载均衡器通常选择URL HASH算法分配流量到缓存服务器。正常的情况下,不同缓存服务器所缓存内容是不同的,而相同URL的访问一定会到达同一台缓存服务器。
2. 互联网出口。可以是运营商城域网出口,也可以是大型企业的出口。为了提高访问速度,负载均衡设备与缓存配合将视频和图片等静态内容缓存到本地。与网站应用类似,URL HASH可以提高缓存效率和命中率。
下图是一个简单的URL HASH示例,该例子只使用最后3个字节计算HASH值,结果就是不同后缀的文件分布在不同服务器。实际应用中通常使用较长url或整个URL计算HASH值。
在有些负载均衡器的HASH算法中,增加或减少服务器会导致整个内容重新分布,所有缓存服务器原来存储的内容大部分失效,需要重新下载。这会大大影 响用户体验。在A10的HASH负载均衡算法中,除了根据url计算出hash值外,还要根据服务器IP地址和HASH值计算一个分数。分数最高的服务器 将被选作该HASH值对应使用的服务器。当增加或减少服务器时,只需要重新计算HASH值对应服务器的分数并更新HASH表即可。如下表所示,服务器正常 时,HASH值H1,H2,H3分别对应服务器S1,S2,S3。当服务器S1宕机或删除后,HASH表将更新HASH值H1对应的服务器为分数次高的 S2,这部分访问就被分流到S2,而HASH值为H2和H3的流量不会受影响,仍然分配到原来的服务器。HASH值的数量远大于服务器数量,而每个 HASH值对应不同服务器的分数有可能不同,因此,去除一台服务器时,其对应的多个HASH值基本可以平均分散到其它服务器。
服务器\HASH值 | H1 | H2 | H3 |
S1 | 100 | 60 | 80 |
S2 | 80 | 100 | 60 |
S3 | 60 | 80 | 100 |
上面这种HASH算法在消耗很少资源的情况下保证了服务器增减不会引起大面积内容重新分布。但在极端情况下,受HASH本身算法设计限制,还是会有 一些问题产生。由于HASH保证了内容的分散,但对每个url的访问量并没有考虑进去。比如当一些热门事件发生时,个别热点链接会超过该HASH值对应服 务器的服务能力。这种情况下就需要负载均衡器可以和服务器配合,根据服务器的负担对HASH流量进行相应处理。A10根据用户需求开发了服务器负担感知的 HASH算法。其工作原理如下:
1. 服务器根据自身负担情况,在HTTP响应头中插入“Server-Status”字段,该字段的值为0、1或2。
2. 负载均衡器根据”Server-Status“反应的服务器负担,进行相应的流量调整。具体处理方式如下:
服务器状态 | 字段含义 | 负载均衡器措施 |
0 |
|
|
1 |
|
|
2 |
|
|
A10通过使用这种具有服务器负载感知的HASH算法,缓存部署碰到的问题基本得以解决。这也是越来越多缓存厂家希望与功能丰富的负载均衡厂商配合的原因之一,而不是缓存独立部署或者使用WCCP等方式引导流量。