服务器负载感知的URL HASH
博客专区 > mac_zhao 的博客 > 博客详情
服务器负载感知的URL HASH
mac_zhao 发表于2年前
服务器负载感知的URL HASH
  • 发表于 2年前
  • 阅读 364
  • 收藏 2
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

摘要: http://virtualadc.blog.51cto.com/3027116/887297

负载均衡设备的URL哈希(HASH)功能主要应用在两种场合:

1. 大型网站。大型网站为了提高访问速率,将视频和图片等可缓存的内容缓存到CDN节点。每个CDN节点有很多台缓存服务器,前端配置负载均衡器进行流量分 担。为了提高缓存服务器的存储效率和命中率,负载均衡器通常选择URL HASH算法分配流量到缓存服务器。正常的情况下,不同缓存服务器所缓存内容是不同的,而相同URL的访问一定会到达同一台缓存服务器。

2. 互联网出口。可以是运营商城域网出口,也可以是大型企业的出口。为了提高访问速度,负载均衡设备与缓存配合将视频和图片等静态内容缓存到本地。与网站应用类似,URL HASH可以提高缓存效率和命中率。

下图是一个简单的URL HASH示例,该例子只使用最后3个字节计算HASH值,结果就是不同后缀的文件分布在不同服务器。实际应用中通常使用较长url或整个URL计算HASH值。

image

在有些负载均衡器的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
  • 服务器可以处理属于自己的流量
  • 也可以协助其它服务器处理流量
  • 负载均衡器正常处理该服务器对应的HASH值的流量
  • 如需要协助其它服务器处理流量
1
  • 服务器可以处理属于自己的流量
  • 但无能力协助其它服务器处理流量
  • 负载均衡器正常处理该服务器对应的HASH值的流量
  • 不会使用该服务器协助其它服务器处理流量
2
  • 服务器已经过载需要其它服务器协助
  • 至少需要另外1台状态为0的服务器进行轮询分配流量
  • 负载均衡器使用所有状态为0的服务器轮询分担该服务器的流量
  • 如没有服务器状态为0,则轮询分担流量到所有服务器

 

A10通过使用这种具有服务器负载感知的HASH算法,缓存部署碰到的问题基本得以解决。这也是越来越多缓存厂家希望与功能丰富的负载均衡厂商配合的原因之一,而不是缓存独立部署或者使用WCCP等方式引导流量。

共有 人打赏支持
粉丝 41
博文 246
码字总数 304243
×
mac_zhao
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: