• GSLB Selecting the Best Site


    先得说一个重要问题:假如采用DNS-GSLB,向GSLB服务器发出查询的是LocalDNS而不是end user, GSLB得不到end user的ip地址,也无法保证local DNS有和end user相近的响应时间。

    Site Health Conditions

    GSLB需要检查每个SITE的健康情况,GSLB只能把用户导向能够正常服务的SITE. 假如每个SITE有一个load balancer, 那么GSLB就向SLB的VIP发送健康检查请求。SLB把健康检查请求当作一个正常请求并将它forward到real server。健康检查的方式很多,就好象做server的健康检查一样:layer 2/ 3/ 4/ 7 都可以做检查,GSLB可以发送HTTP请求检查返回代码,检查返回内容中的关键词或者校验和。

    image

    Site Response Time

    GSLB可以测量每个site的请求/回应往返时间,就使用健康检查的往返时间就可以了。但是要知道,GSLB到服务器的往返时间和end user的体验并没有直接关系,往返时间可以分为3部分,客户端延时+服务器响应时间+网络延迟。GSLB测量得到的数据无法体现user-server网络延迟。

    GSLB可以测量的响应时间本质上反映了一个site的服务器响应时间,假如一个SITE有SLB和多个real server,那么几次请求会被导向到不同的real server,结果会有不同,所以最好测量多次相应的平均时间。Local Server load balancer 可以测量所有服务器的加权平均响应时间报告给GSLB。

    Site Load Conditions

    我们必须同时考虑site的服务能力和服务负载。GSLB将user导向最优服务能力的site是有必要的。但是如何定义服务器负载是一个有争议的话题。当前的并发连接是一个可用的指标,服务器响应时间也反映了服务器负载。没有一个特定的方法来定义服务器负载。

    通过DNS,即使采用某种方法选择负载最轻的服务器后,你无法预知会影响多少个新的请求,因为LocalDNS有cache,也许接下来只有一个请求,或者是上万次的请求都会定向到那台服务器。

    Geography−Based Site Selection

    ip地址被分为很多块对应于国家和大陆,GSLB将LocalDNS的地址匹配地址块,选择相近的服务器服务。这个方法只能近似的选择合适的服务器,不过误差是可以容忍的。

    因为服务器负载或者临时性的网络拥塞,一个用户选择相近的服务器未必能够得到最好的体验。

    User Response Time−Based Site Selection

    end−user response time = client−side delay + Internet delay + and server−side delay

    服务端delay是独立于用户的位置并且是GSLB可以测量的,客户端delay我们啥也不能做,网络延时取决于客户端和服务器的位置。我们知道服务器的位置,但是无法确知用户的位置,他们可能遍布世界各地。测量网络延时有几种方法,但是没有一个是完美的。

    Ping

    GSLB解析DNS请求的时候,让每个SLB去ping LocalDNS,报告ping 时间给GSLB,GSLB选择最短的ping时间服务器。这种方式下,GSLB必须等待各个SLB的ping结果报告,有明显的性能问题。解决的方法是GSLB先使用其他策略,在后台收集SLB ping local dns的数据,供下次请求使用。这样就不会影响性能,但是影响第一次dns请求的解析结果。

    另外, ping结果本身并非很准确,需要测量多次取平均值,而且容易被防火墙挡住。

    DNS Reply Race

    GSLB转发dns 请求给SLB,SLB发送自己的VIP给local DNS, Local DNS采用第一个收到的dns reply。这里有个关键问题是如何让SLB在同一个时间点发送dns reply,无论如何调整,这个也只能做到近似,而且,这样找到最少网络延时也只是一个瞬间状态而不是有代表性的平均值。

    TCP Response Time

    GSLB先使用其他策略,local SLB测量client发送的SYN和ACK之间的时间差,就可以知道网络延时,这种测量不需要额外的流量,非常有效率,而且即使local dns在防火墙后面也无所谓。

    SLB要将测量的结果报告GSLB。GSLB为了比较不同的SLB-用户网络延时,需要将同样的用户导向各个SLB。

    一个问题:SLB测量的是end-user的网络延时,但是GSLB只知道LocalDNS的地址,将用户的ip地址和local DNS地址关联是个较大的挑战。

    定义group的方法不多说,现在其实我们做出了两个假设:同一个group的ip地址有相同的时延,而且使用相同的local DNS。

    一个重要的概念是如何将internet地址分组,像Border Gateway Protocol (BGP)这样的路由协议可以帮助我们。

    因为要不断的收集数据,总有些用户会被分到延时较远的site,这无疑会影响他们的体验。一种替代的方法是在网络上广泛使用机器人来测量延时,但是部署是个大问题。

    Routing Cost

    用户到SLB经过多少跳可以作为网络延时的一个指标。假如GSLB使用BGP协议,他就可以得到地址段到SLB之间的跳数信息。

    但是跳数不一定能够准确的反映网络延时信息,因为拥塞等原因

     

    Affinity

    Tolerance Values

    Selecting the Best Site

    当收到请求的时候,GSLB必须确保只有功能正常的site选中,然后再通过其他方式缩小可选范围,我们可以使用加权的各种尺度来衡量最佳的site。

    当选择出最佳的站点后,GSLB可以只回应一个ip地址或者是一个地址列表,假如回应地址列表,localDNS一般会采用轮转的方法来回应请求。假如只返回一个ip地址,当别选择服务器宕机后,我们只能等待local dns  or client cache time-out。

  • 相关阅读:
    菜鸟也能飞:SQL数据库实战专业教程(二)
    菜鸟也能飞:SQL数据库实战专业教程(三)
    我的时间管理柳暗花明
    真正的全能文件批量重命名工具(命令形式)
    关于提高班最近的一些事
    菜鸟也能飞:SQL数据库实战专业教程(一)
    JQuery以POST方法从ASP.NET服务器获取Json数据完整示例
    先有鸡还是先有蛋:数据库中的相互依赖
    一个简单的性能计数器:CodeTimer
    数据库范式
  • 原文地址:https://www.cnblogs.com/peon/p/1054715.html
Copyright © 2020-2023  润新知