1.3.1 DNS轮询与负载均衡器的不同点 负载均衡器 （Load Balancer，也称负载分发或负载分流设备）能够将向同一IP地址发出的请求分发到多台服务器进行处理。而DNS轮询则需要分别向Web服务器分配不同的IP地址（全局地址）。因此使用负载均衡器，能够节省全局地址的使用。使用DNS轮询的情况下，在架设Web服务的冗余结构时会费心费力，而负载均衡器则无需这样的操作。 ● ●负载均衡器的行为 负载均衡器会被作为虚拟服务器使用，它拥有提供服务的全局地址。通过将来自客户端的请求中转到真正进行处理的Web服务器（下文统称为真实服务器），就像是Web服务器一样运行 ● ●负载均衡器的功能 负载均衡器是从多台真实服务器中选出其中一台，并交由其进行处理。负载均衡器不会选择健康检查失败的服务器，而一定会选择健康检查成功的服务器。因此无论哪台服务器停止运行，只要有一台服务器正常工作，都不会影响到整个服务的正常提供 ● ●引入负载均衡器的门槛 人们可能会对负载均衡器抱有“负载均衡器=昂贵的设备”这样的印象，还有可能会担心自己能否使用好这套设备等，这些顾虑都会提高引入负载均衡的门槛 关于引入负载均衡器的门槛，确实专用的服务器产品会比较贵，每月的最低消费等费用也比较高。而且万一发生故障，还有必要联系研发商以获得该负载均衡器的技术支持。根据使用情况，还有可能需要升级防火墙等，因此也不能中断维护合同来缩减运营经费。在确保一定程度的盈利之前，难以下决心引入负载均衡器的情况很常见。但是也可以选择不使用专用服务器，而使用OSS（OpenSource Software，开源软件）来搭建，并由自己来运营。接下来将正式讲解如何自行搭建生产环境中的负载均衡器。 1.3.2 IPVS……基于Linux的负载均衡器 即使不安装特别的软件，Linux也可以作为路由器（网络设备）使用。而且系统的防火墙也有很多实用的功能，例如分组过滤（Packet Filtering）技术等众多的网络功能。提供负载均衡功能的 IPVS （IP Virtual Server）模块也包含在其中。 负载均衡器的种类与IPVS的功能 接下来说明负载均衡器的种类。负载均衡器的种类按大的方向可分为四层交换机（L4 switch）与七层交换机（L7 switch）两种A。四层交换机进行的是传输层信息的处理，可以根据IP地址或端口号，指定作为分发目的地的服务器。而七层交换机进行的则是应用层信息的处理，可以根据从客户端请求的URL，指定分发目的地的目标服务器。 安装了IPVS就“相当于拥有了四层交换机的功能”，而七层交换机这里暂时不会用到。 在本书的讲解中，若没有特别说明，均可认为是四层交换机的负载均衡器B。另外，一般情况下说到负载均衡器，大多默认指“四层交换机”。 1.3.3 调度算法 将处理分发到真实服务器时，如果平均地分流到所有服务器，在不同配置的服务器混合使用的环境下就有可能造成服务器负载不平衡。在IPVS中有一种名为“调度算法”（Scheduling Algorithm）的调度器，必要的时候能够根据环境选择适当的算法。表1.3.1是主要的算法一览表。 A L4与L7在OSI参考模型中分别对应第四层（传输层，Transport Layer）与第七层（应用层，Application Layer）。 B 在使用反向代理的情况下，也有可能实现一部分七层交换机的功能。关于反向代理的详情，请参考2.1节。 表1.3.1 主要的算法 名称 行为 rr（round-robin，轮询）调度 该算法不考虑别的因素，单纯以轮叫的方式依次请求真实服务器。因此处理会被均等地分发给所有的服务器 wrr（weighted round-robin，加权轮询）调度 与上述的rr有些类似，但该算法引用了一个加权值来控制分发的比率。加权值越大，服务器被选择的概率就越高，因此为了让处理性能较高的服务器承受更多请求，只需增大其加权值即可 lc（least-connection，最小连接）调度 该算法是将新的连接请求分配到当前连接数最少的服务器。在大部分的情况下使用这个算法都没有问题。在不知道到底要选择哪种算法合适的情况下，选择这个准没错 wlc（weighted least-connection，加权最小连接）调度 与上述的lc有些类似，不过该算法引入了加权值。由于该算法通过“（连接数+1）÷加权值”算出了最小因数的服务器，所以会更有效地分配连接。与wrr一样，加大高性能的服务器的加权值是比较好的选择 sed（shortest expected delay，最短预期延时）调度 该算法会选择响应速度最快的那台服务器。但它并没有监测传送数据分组到目标服务器的应答时间，而是选择状态是ESTABLISHED的连接数（下文统称为活动连接数）最少的服务器。其行为基本上和上述的wlc一样，但wlc会把除ESTABLISHED以外的状态（TIME_WAIT或FIN_WAIT等）的连接数计算在最小因数中，这点即是wlc与sed不同的地方 nq（never queue，不排队）调度 与上述的sed算法类似，该算法会最优先选择活动连接数为0的服务器 针对真实服务器的不同配置，引入了“加权值”（Weight）这一参数，可以根据需要对加权值进行合理的设定。在某些算法中，该加权值越大就表示服务器的处理能力越高，据此可以调节分流比率。在表1.3.1中的算法行为一栏中，对每个算法如何选择真实服务器一一进行了说明。 IPVS中还包含有表1.3.1中没有列出的调度算法。通过将IPVS和透明代理（Transparent Proxy）或高速缓存服务器等并用，可以优化性能。虽然这里不会用到，不过我们还是将这些算法进行了整理，如表1.3.2所示。 表1.3.2 其他的调度算法 名称 行为 sh（source hashing，源地址散列）调度 对发出请求的IP地址（即源地址）计算散列值（Hash Value），并通过该值选择具体分发到哪个真实服务器 dh（destination hashing，目标地址散列）调度 对需要接收请求的目标IP地址计算散列值，并通过该值选择具体分发到哪个真实服务器 lblc（locality-based least-connection，基于局部性的最小连接） 调度 在连接数没有超过加权值指定的值时，将选择同一台服务器。若是超过了加权值指定的值，则选择其他的服务器。当所有服务器的连接数都超过加权值指定的值时，将选择最终所选的那台服务器 lblcr（locality-based least-connection with replication，带复制的基于局部性最小连接） 调度 与上述的lblc有些类似，当所有服务器的连接数都超过加权值指定的值时，将选择连接数最少的那台服务器 1.3.4 使用IPVS 可以通过以下软件使用IPVS的功能： ● ●ipvsadm URL http://www.linuxvirtualserver.org/software/ipvs.html ● ●keepalived URL http://www.keepalived.org/ ipvsadm ipvsadm 是由IPVS的开发商提供的命令行工具A。除了定义虚拟服务器及分配真实服务器等功能外，也可以确认设定内容和连接状态，另外也能将传输率等统计信息显示出来。 keepalived keepalived 是用C语言编写的守护程序。可以根据配置文件（/etc/keepalived/keepalived.conf）的内容来搭建IPVS的虚拟主机。其功能主要表现在：对真实服务器进行健康检查，并自动将已经宕机的服务器排除在负载均衡所分配的范围外；如果所有的真实服务器全数宕机，则会显示“服务器繁忙”等消息，即具备sorry_server功能。 A 其地位就相当于netfilter组件与iptables命令之间的关系。 截至2014年11月，最新的版本是keepalived-1.2.13，该版本支持以下健康检查。 ● ● HTTP_GET：通过发送HTTP的GET请求来确认目标服务器的应答情况 ● ● SSL_GET：通过发送HTTPS的GET请求来确认目标服务器的应答情况 ● ● TCP_CHECK：通过测试TCP连接是否正常来确认目标服务器的情况 ● ● SMTP_CHECK：通过发送SMTP的HELO命令来确认目标服务器的应答情况 ● ● MISC_CHECK：通过执行外部命令所返回的结束代码来确认目标服务器的健康状况 1.3.5 搭建负载均衡器 接下来使用keepalived搭建如图1.3.1所示的系统。这里将10.0.0.1作为服务器使用的全局IP地址。在该负载分发的拓扑结构中，当客户端访问 http://10.0.0.1/ 时，该请求就会被转到Web1与Web2进行处理。其他详细的配置参数如下。 ●调度算法：rr（round-robin） ● ●健康检查的类别：HTTP_GET ● ●健康检查的页面：http://health/health.html ● ●健康检查成功的条件：状态代码返回200 ● ●健康检查的超时时间：5秒 代码清单1.3.1是将以上参数作为keepalived的配置文件进行编写的。 代码清单1.3.1 keepalived的配置 virtual_server_group example { 10.0.0.1 80 } virtual_server group example { lvs_sched rr lvs_method NAT protocol TCP virtualhost health real_server 192.168.0.1 80 { weight 1 HTTP_GET { url { path /health.html status_code 200 } connect_port 80 connect_timeout 5 } } real_server 192.168.0.2 80 { weight 1 HTTP_GET { url { path /health.html status_code 200 } connect_port 80 connect_timeout 5 } } } 配置Web服务器 在启动keepalived前，需要确认Web服务器的配置，必要的操作有下面3点： ● ●设置默认网关为192.168.0.254 ● ●设置健康检查页面 ● ●设置用于确认运行情况的页面 在此拓扑中，来自客户端的请求与来自真实服务器的响应都必须经由负载均衡器，因此需要事先设置各Web服务器的默认网关为负载均衡器的IP地址。 Keepalived会对真实服务器进行健康检查。这里访问 http://health/health.html ，并检查是否会返回200的状态代码，因此有必要在每个Web服务器上都设置一个用来做健康检查的页面。 另外还需要准备好确认运行情况的页面。在确认运行情况时，为了更容易地把握具体分流到了哪个服务器，应该特意将index.html写入为不同的内容以示区别，这里将index.html写入主机名（Web1、Web2）。 启动keepalived 请把代码清单1.3.1放到/ect/keepalived/keepalived.conf下，然后启动keepalived，IPVS的虚拟服务器就搭建好了。如图1.3.2所示，可以使用 ipvsadm 命令确认虚拟服务器。在图1.3.2中，代码清单将连接到10.0.0.1:80的请求，分流到192.168.0.1:80与192.168.0.2:80两台主机上进行处理。 图1.3.2 确认虚拟服务器 # ipvsadm -Ln IP Virtual Server version 1.2.1 (size=1048576) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.0.0.1:80 rr -> 192.168.0.1:80 Masq 1 0 0 -> 192.168.0.2:80 Masq 1 0 0 确认负载分流 从客户端访问http://10.0.0.1/，会得出如图1.3.3所示的结果。每次访问都会交替连接到Web1与Web2，从而就可以确认负载分流的具体执行情况。 图1.3.3 确认负载分流 $ curl 'http://10.0.0.1/' Web1 $ curl 'http://10.0.0.1/' Web2 $ curl 'http://10.0.0.1/' Web1 $ curl 'http://10.0.0.1/' Web2 确认冗余的拓扑结构 下面在Web2宕机的情况下再次尝试访问。从图1.3.4中能够看出，可以正常连接到Web1的主机。所以能够确认：在冗余的拓扑结构下，即使Web2停止工作也不会产生错误，依旧可以正常访问。 图1.3.4 确认冗余的拓扑结构 $ curl 'http://10.0.0.1/' Web1 $ curl 'http://10.0.0.1/' Web1 $ curl 'http://10.0.0.1/' Web1 $ curl 'http://10.0.0.1/' Web1 1.3.6 四层交换机与七层交换机 前文提到了负载均衡器分为四层交换机与七层交换机两种。虽说都是进行负载分发，但两者的处理内容却有很大的差异。四层交换机通过解析TCP头等协议头的内容，来决定分流的目的地；而七层交换机则通过解析软件应用层的内容，来决定分流的目的地。 图1.3.5表现了四层交换机与七层交换机的不同点。在四层交换机中，客户端（Web浏览器）的通信目标是真实服务器。而在七层交换机中，负载均衡器和客户端会先通过TCP会话进行握手。也就是说，每次访问都会经过：客户端 ⇔七层交换机中黑色的框⇔七层交换机中白色的框⇔真实服务器（图中为两台）。 四层交换机与七层交换机的特点可以简明地总结如下： ● ●追求设定的灵活性就用七层交换机 ● ●追求性能就用四层交换机 专栏 七层交换机的灵活设定七层交换机可以将类似http://example.cn/*.png这样的图片文件发送的请求分配到图片专用的服务器进行处理。而对于像 http://example.cn/hoge?SESSIONID=xxxxxxxx 这样包含会话ID的请求，七层交换机还可以将同一会话ID的请求分配到同一台服务器进行处理。也就是说，类似于请求目标URL等应用软件协议的内容，可以被作为选择真实服务器时的条件使用。相反，负载均衡器不能识别的协议，则自然无法实现负载分流。比如在对SMTP进行负载分流时，虽说理论上可以通过七层交换机实现“将特定收件人的邮件发送到特定的服务器”，但若是负载均衡器不支持SMTP，那就无法使用。如何决定将什么样的协议根据什么样的规则来进行分流呢？虽说可以依靠负载均衡器所提供的功能，但“使用七层交换机就万事大吉了”这样的想法是要不得的。在选定七层交换机时，将想要做的工作都准确无误地确认好，这是很重要的。 1.3.7 四层交换机的NAT模型与DSR模型 下面对四层交换机的性能优势做个介绍。请先思考一下四层交换机的哪些模型造就了该拓扑结构的性能优势。 四层交换机可以利用图1.3.1中搭建的NAT（Network Address Translation，网络地址转换）模型，为了追求更高的性能，也可以搭建DSR（Direct Server Return，直接服务器返回）模型。DSR与NAT的不同点请参考图1.3.6。 在NAT模型下，四层交换机从客户端收到数据分组后就修改分组的目的IP地址，并将分组转发到真实服务器上。因此在真实服务器接收到应答数据分组后，需要特别返回源IP地址。而在DSR模型下，IP地址并不会被映射。四层交换机从客户端接收到分组后，不做任何修改就直接将分组从路由器发送到真实服务器上。在这种情况下，由于没有必要对应答的分组返回IP地址，因此真实服务器即使不经由四层交换机也能够返回应答。 若担心负载均衡器出现瓶颈问题，或者需要能够承受高流量的负载分发环境，这里推荐使用DSR模型。顺带一提，在使用keepalived来搭建DSR时，请将lvs_method设定为“DR”（请注意在这里不应该设定为“DSR”）。 但在DSR模型中，发送给虚拟服务器的分组（全局IP分组）没有做任何修改就原样到达了真实服务器，由于真实服务器不能处理该全局IP分组，因此无法处理该请求。也就可以说，对于NAR模型的系统，只修改负载均衡器的设定是没有办法实现负载均衡的。 最简便的设定方式是，将虚拟服务器的IP地址映射到真实服务器的环回接口（Loopback Interface）上，另外还有一种方法是，使用netfilter的相关功能，将发给虚拟服务器的分组的本地源地址映射为私有的本地全球地址（即在本地范围内扩大地址的使用范围，以扩展地址的容量），这种方式称为DNAT（Destination Network Address Translation，目的网络地址转换）。 1.3.8 同一子网下的服务器进行负载分流时需要注意的地方 至此，我们已经探讨了公网Web服务器的负载分流。其实负载均衡器的用途并不仅限于此，例如在信息发布系统中，从Web服务器到邮件服务器可能需要发送大量邮件。若只有一台邮件服务器来处理，想必会花不少时间，因此可以考虑使用负载均衡器将邮件服务器进行负载分流。类似这样的情况可以考虑参考图1.3.7，但该拓扑结构有几点需要注意的地方。 在同一子网需要负载分流时，不能使用NAT模型。NAT模型下会映射负载均衡器的源IP地址，比如在邮件服务器中，接收到的分组是从源地址192.168.0.1发送到目的地址192.168.0.151的，因此该邮件服务器返回的应答分组的源地址是192.168.0.151，目的地址是192.168.0.1。正因为源地址192.168.0.151与目的地址192.168.0.1是同一子网下的IP地址，因此不会将分组发往负载均衡器，而直接从源地址发送到Web服务器。因此该NAT模型中源地址的IP地址尚未被正确转发到目标服务器，进而就造成了不能正常完成通信。 该情况下，使用上文介绍的DSR模型是比较好的选择。因为DSR模型不用映射负载均衡器的IP地址，所以就算邮件服务器直接向Web服务器返回应答也完全没有问题。 专栏 基于Linux平台的七层交换机基于Linux平台搭建七层交换机所使用的软件还在不断开发中，以下介绍两款软件：● ●UltraMonkey-L7 URL http://sourceforge.jp/projects/ultramonkey-l7/● ●Linux Layer7 Switching URL http://zh.sourceforge.jp/projects/freshmeat_linux-l7sw/UltraMonkey-L7于2008年1月发布了1.0.1-0版本。截至目前（2014年11月），已经更新到了3.1.1-1版。现在使用UltaMonkey-L7已经可以搭建稳健的七层交换机，该软件的实用性也非常让人满意。而Linux Layer7 Switching虽然于2007年1月发布了0.1.2版本,但似乎之后该软件并没有更新，该软件有多大的实用性现在还是未知数。
