应用负载均衡基本原理解析（二）

在第一部分中，我们从网络层面深度解析了负载均衡的本质，这一部分中我们将从应用的角度来分析负载均衡的多种关键技术。

 再来回顾一下我们在第一部分中的这幅图：

 

问题1、如果10.0.0.2不可达或者80端口服务不可用，怎么办？难道被分到这台服务器上的用户就该倒霉吗？

问题2、为何172.16.0.1的用户请求会被分配到10.0.0.2上，172.16.0.2的用户请求会被分配到10.0.0.3上？

 

以上两个问题分别涉及到负载均衡里两个基本的关键词：健康状态检测和负载均衡算法。

我们这部分主要分析健康状态检测原理。

健康状态检测是负载均衡设备的一个最基本的机制，它能确认某台服务器上的应用是否正常，如果确认不正常，则会把这台机器排除在可用来进行分发的服务器资源之外，这样就能避免出现将客户请求分发到不能正常工作的服务器上，从而导致用户访问失败。

如何才能正确判断应用的健康状态呢？

我们假设对一个运行web服务的服务器进行健康状态检测，分别以从浅到深的方式去检查：

A、 用ICMP协议的方式进行探测，看能ping通服务器的IP地址

诚然，如果正常状态下能ping通服务器，当某个时刻ping不通以后，说明链路出现故障或者服务器死机,这个时候判断应用不可用是没有问题的，但是，能ping通应用就一定正常吗？假设服务器网络正常，但是web服务的软件出现问题，导致对80端口的请求都不响应的时候，即便能ping通，但是分配到这台服务器上的请求也无法正常访问应用。所以，看来能ping通不代表业务就正常啊。

B、 用TCP协议3次握手的方式来检查80端口是否响应。

这种方式相对第一种方式，就要进步得多了。即便是能ping通，但是如果和应用的80端口无法建立3次TCP握手，则说明该服务器上应用不正常，这种方式在很大程度上避免了服务进程问题导致的不响应用户请求的问题。但是，这样就一定保险吗？假设web应用的80端口是打开的，可以响应TCP方式的探测，但是想必大家经常遇到一种情况，打开网页的时候，却看到“HTTP 404” 未找到…..。这种提示就说明服务进程是正常的，但是网页文件可能不正常，比如被误删除之类。所以，只靠TCP的检测方式也不能完全感知应用的健康程度。

C、 用http的方式来检测80端口是否正常。

   这种方式相对前2种来说，就要更加可靠了。默认设置下设备会对应用服务器的80端口模拟一个http的GET /的请求，通过设备响应的页面是否包含完整的header，body等关键元素来判断web应用是否健康，这种方式在通常情况下已经可以满足相当一部分用户对应用健康状态检测的需求了。但是，在某些情况下，这种方式依旧有局限。我们假设这种情况，如果这个web服务是一个门户网站，当我们直接访问首页的时候可以正常打开，而输入用户名、密码以后回车，却仍旧看到“HTTP 404未找到”，所以这个时候光靠GET /的方式来检测就不够了。通过定制http的检测方式，可以通过GET指定页面，使用指定的username和password登录，并指定登录以后页面包含的关键字这一系列的操作来完成深度的健康检测。

 

上面案例是以web应用为例，在现实环境中，客户的应用种类是多种多样，所以设备需要能够争对各种应用均衡做到应用级别的检测才行，以下是一些常见应用及需要的检测方式：

Radius服务：设备应能够模拟一个radius的认证请求，请求中包含一个合法的用户名和

             密码，在检测应用的时候，如果Radius服务器返回验证通过的请求，则

             说明服务状态正常；如果返回不通过或者不返回信息，则说明不正常。

LDAP服务：  设备应能够模拟一个LDAP的认证请求，请求中包含一个合法的用户名和

             密码，在检测应用的时候，如果LDAP服务器返回验证通过的请求，则

             说明服务状态正常；如果返回不通过或者不返回信息，则说明不正常。

FTP服务：   设备应能够模拟一个FTP的认证请求，请求中包含一个合法的用户名和

             密码，在检测应用的时候，如果FTP服务器返回验证通过的请求，则

             说明服务状态正常；如果返回不通过或者不返回信息，则说明不正常。

   POP3服务：  设备应能够模拟一个POP3的认证请求，请求中包含一个合法的用户名和

             密码，在检测应用的时候，如果POP3服务器返回验证通过的请求，则

             说明服务状态正常；如果返回不通过或者不返回信息，则说明不正常。

 

   同理，一些常见服务，比如SMTP，RSTP，SIP，NTP，IMAP，SNMP，DNS，HTTPS，UDP，compound等都应该能够内置支持。除了这些内置的健康状态以外，设备最好能够支持外部的健康检测方式，比如通过编写脚本来实现我们需要的健康状态检测。例如，争对TFTP的访问原理，我们编写了一个外部健康检查程序，判断是否能从服务器取回指定的文件：

 

       •    #! /bin/bash

•    server=$1

•    file=$1".txt"

•    if [ -f $file ] ; then

•    rm -f $file

•    fi

•    tftp $server << END

•    get $file

•    quit

•    END

 

•    #! /bin/bash          

•           

•    if test "$HM_SRV_IPADDR" == "" ; then             

•    echo "Please check ENV Var 'HM_SRV_IPADDR'"             

•    exit 1             

•    fi                                                                      

•    server=$HM_SRV_IPADDR                                                                

•    file=$server".txt"            

•    /tftp_getfile.sh $server                                     

•    grep  "test" $file                            

•    exit $?

 

通过以上脚本，我们可以在tftp服务器上，通过获取指定的文件，以获取的结果成功或者失败来达到深度检测应用健康状态的问题，而不是只是简单的通过UDP协议方式去检测。

 

通过以上内部内置的检测方式和灵活的外部检测方式，我们可以实现争对客户特定应用进行深度定制的健康状态检测方式。

 

（待续）

t.d.