LVS管理与维护

1 .LVS系统介绍

今计算机技术已进入以网络为中心的计算时期。由于客户/服务器模型的简单性、易管理性和易维护性，客户/服务器计算模式在网上被大量采用。在九十年代中期，万维网（World Wide Web）的出现以其简单操作方式将图文并茂的网上信息带给普通大众，Web也正在从一种内容发送机制成为一种服务平台，大量的服务和应用（如新闻服务、网上银行、电子商务等）都是围绕着Web进行。这促进Internet用户剧烈增长和Internet流量爆炸式地增长，图1显示了1995至2000年与 Internet连接主机数的变化情况[1]，可见增长趋势较以往更迅猛。

图1：1995至2000年Internet主机数的变化

Internet的飞速发展给网络带宽和服务器带来巨大的挑战。从网络技术的发展来看，网络带宽的增长远高于处理器速度和内存访问速度的增长，如100M Ethernet、ATM、Gigabit Ethernet等不断地涌现，10Gigabit Ethernet即将就绪，在主干网上密集波分复用（DWDM）将成为宽带IP的主流技术[2,3]，Lucent已经推出在一根光纤跑800Gigabit的WaveStar? OLS 800G产品[4]。所以，我们深信越来越多的瓶颈会出现在服务器端。很多研究显示Gigabit Ethernet在服务器上很难使得其吞吐率达到1Gb/s的原因是协议栈（TCP/IP）和操作系统的低效，以及处理器的低效，这需要对协议的处理方法、操作系统的调度和IO的处理作更深入的研究。在高速网络上，重新设计单台服务器上的网络服务程序也是个重要课题。

比较热门的站点会吸引前所未有的访问流量，例如根据Yahoo的新闻发布，Yahoo已经每天发送6.25亿页面[5]。一些网络服务也收到巨额的流量，如American Online的Web Cache系统每天处理50.2亿个用户访问Web的请求，每个请求的平均响应长度为5.5Kbytes。与此同时，很多网络服务因为访问次数爆炸式地增长而不堪重负，不能及时处理用户的请求，导致用户进行长时间的等待，大大降低了服务质量。如何建立可伸缩的网络服务来满足不断增长的负载需求已成为迫在眉睫的问题。

大部分网站都需要提供每天24小时、每星期7天的服务，对电子商务等网站尤为突出，任何服务中断和关键性的数据丢失都会造成直接的商业损失。例如，根据 Dell的新闻发布[6]，Dell现在每天在网站上的交易收入为一千四百万美元，一个小时的服务中断都会造成平均五十八万美元的损失。所以，这对网络服务的可靠性提出了越来越高的要求。

现在Web服务中越来越多地使用CGI、动态主页等CPU密集型应用，这对服务器的性能有较高要求。未来的网络服务会提供更丰富的内容、更好的交互性、更高的安全性等，需要服务器具有更强的CPU和I/O处理能力。例如，通过HTTPS（Secure HTTP）取一个静态页面需要的处理性能比通过HTTP的高一个数量级，HTTPS正在被电子商务站点广为使用。所以，网络流量并不能说明全部问题，要考虑到应用本身的发展也需要越来越强的处理性能。

因此，对用硬件和软件方法实现高可伸缩、高可用网络服务的需求不断增长，这种需求可以归结以下几点：

• 可伸缩性（Scalability），当服务的负载增长时，系统能被扩展来满足需求，且不降低服务质量。
• 高可用性（Availability），尽管部分硬件和软件会发生故障，整个系统的服务必须是每天24小时每星期7天可用的。
• 可管理性（Manageability），整个系统可能在物理上很大，但应该容易管理。
• 价格有效性（Cost-effectiveness），整个系统实现是经济的、易支付的。

对称多处理（Symmetric Multi-Processor，简称SMP）是由多个对称的处理器、和通过总线共享的内存和I/O部件所组成的计算机系统。SMP是一种低并行度的结构，是我们通常所说的"紧耦合多处理系统"，它的可扩展能力有限，但SMP的优点是单一系统映像（Single System Image），有共享的内存和I/O，易编程。

由于SMP的可扩展能力有限，SMP服务器显然不能满足高可伸缩、高可用网络服务中的负载处理能力不断增长需求。随着负载不断增长，会导致服务器不断地升级。这种服务器升级有下列不足：一是升级过程繁琐，机器切换会使服务暂时中断，并造成原有计算资源的浪费；二是越往高端的服务器，所花费的代价越大；三是 SMP服务器是单一故障点（Single Point of Failure），一旦该服务器或应用软件失效，会导致整个服务的中断。

通过高性能网络或局域网互联的服务器集群正成为实现高可伸缩的、高可用网络服务的有效结构。这种松耦合结构的服务器集群系统有下列优点：

• 性能
  网络服务的工作负载通常是大量相互独立的任务，通过一组服务器分而治之，可以获得很高的整体性能。
• 性能/价格比
  组成集群系统的PC服务器或RISC服务器和标准网络设备因为大规模生产降低成本，价格低，具有最高的性能/价格比。若整体性能随着结点数的增长而接近线性增加，该系统的性能/价格比接近于PC服务器。所以，这种松耦合结构比紧耦合的多处理器系统具有更好的性能/价格比。
• 可伸缩性
  集群系统中的结点数目可以增长到几千个，乃至上万个，其伸缩性远超过单台超级计算机。
• 高可用性
  在硬件和软件上都有冗余，通过检测软硬件的故障，将故障屏蔽，由存活结点提供服务，可实现高可用性。

当然，用服务器集群系统实现可伸缩网络服务也存在很多挑战性的工作：

• 透明性（Transparency）
  如何高效地使得由多个独立计算机组成的松藕合的集群系统构成一个虚拟服务器；客户端应用程序与集群系统交互时，就像与一台高性能、高可用的服务器交互一样，客户端无须作任何修改。部分服务器的切入和切出不会中断服务，这对用户也是透明的。
• 性能（Performance）
  性能要接近线性加速，这需要设计很好的软硬件的体系结构，消除系统可能存在的瓶颈。将负载较均衡地调度到各台服务器上。
• 高可用性（Availability）
  需要设计和实现很好的系统资源和故障的监测和处理系统。当发现一个模块失败时，要这模块上提供的服务迁移到其他模块上。在理想状况下，这种迁移是即时的、自动的。
• 可管理性（Manageability）
  要使集群系统变得易管理，就像管理一个单一映像系统一样。在理想状况下，软硬件模块的插入能做到即插即用（Plug & Play）。
• 可编程性（Programmability）
  在集群系统上，容易开发应用程序。

项目

针对高可伸缩、高可用网络服务的需求，我们给出了基于IP层和基于内容请求分发的负载平衡调度解决方法，并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。

虚拟服务器的体系结构如图2所示，一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前端有一个负载调度器（Load Balancer）。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为Linux虚拟服务器（Linux Virtual Server）。

图2：虚拟服务器的结构

在1998年5月，我成立了Linux Virtual Server的自由软件项目，进行Linux服务器集群的开发工作。同时，Linux Virtual Server项目是国内最早出现的自由软件项目之一。

Linux Virtual Server项目的目标：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。

目前，LVS项目已提供了一个实现可伸缩网络服务的Linux Virtual Server框架，如图3所示。在LVS框架中，提供了含有三种IP负载均衡技术的IP虚拟服务器软件IPVS、基于内容请求分发的内核Layer-7交换机KTCPVS和集群管理软件。可以利用LVS框架实现高可伸缩的、高可用的Web、Cache、Mail和Media等网络服务；在此基础上，可以开发支持庞大用户数的、高可伸缩的、高可用的电子商务应用。

图3：Linux虚拟服务器框架

IP虚拟服务器软件IPVS

在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation），大多数商品化的IP负载均衡调度器产品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和 Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。所以，IPVS软件实现了这三种IP负载均衡技术，它们的大致原理如下（我们将在其他章节对其工作原理进行详细描述），

1. Virtual Server via Network Address Translation（VS/NAT）
   通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
2. Virtual Server via IP Tunneling（VS/TUN）
   采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。
3. Virtual Server via Direct Routing（VS/DR）
   VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。

针对不同的网络服务需求和服务器配置，IPVS调度器实现了如下八种负载调度算法：

1. 轮叫（Round Robin）
   调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2. 加权轮叫（Weighted Round Robin）
   调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3. 最少链接（Least Connections）
   调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
4. 加权最少链接（Weighted Least Connections）
   在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5. 基于局部性的最少链接（Locality-Based Least Connections）
   "基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务器，将请求发送到该服务器。
6. 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
   "带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
7. 目标地址散列（Destination Hashing）
   "目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
8. 源地址散列（Source Hashing）
   "源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

 

 

 

      

 

 

了解LVS中必须的rpm 包

中的rpm包

ipvsadm-1.24-6.1.i386.rpm 必需的安装包

vcompiranha-1.0.0-1.i386.rpm

检查ipvs rpm包是否都安装成功

rpm –qa |grep ipvs

rpm –qa |grep vcompiranha

 

如果哪个包没有安装，请手动安装。

 

检查LVS系统的服务状态

进程

service pulse  status

正常情况下显示:

pulse (pid 4825) is running...

进程

正常情况下显示:

ps -ef | grep nanny

root      4837  4828  0 18:04 ?        00:00:00 /usr/sbin/nanny -c -h 192.168.104.69 -p 80 -s GET / HTTP/1.0\r\n\r\n -x HTTP -a 15 -I /sbin/ipvsadm -t 6 -w 1 -V 192.168.104.99 -M i -U ruptime --lvs

root      4838  4828  0 18:04 ?        00:00:00 /usr/sbin/nanny -c -h 192.168.113.23 -p 80 -s GET / HTTP/1.0\r\n\r\n -x HTTP -a 15 -I /sbin/ipvsadm -t 6 -w 1 -V 192.168.104.99 -M i -U ruptime --lvs

root      5160  4665  0 18:43 pts/1    00:00:00 grep nanny

检查ipvs状态

命令: ipvsadm

IP Virtual Server version 1.2.0 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

TCP  192.168.104.99:http rr

  -> 192.168.113.23:http          Tunnel  1      0          0        

  -> 192.168.104.69:http          Tunnel  1      0          0

具体命令内容即参数请参考:man clustat.

 

配置文件

一个集群中的各个节点的配置文件应该是一致的位置都是在/etc/sysconfig/ha/下,名字是lvs.cf.。且内容相同。

[root@LB ha]# more /etc/sysconfig/ha/lvs.cf

serial_no = 294

primary =  192.168.104.52

service = lvs

backup_active = 1

backup = 192.168.104.98

heartbeat = 1

heartbeat_port = 539

keepalive = 6

deadtime = 18

network = tunnel

debug_level = NONE

virtual JBOSS {

     active = 1

     address = 192.168.104.99 eth0:0

     vip_nmask = 255.255.255.255

     port = 80

     persistent = 0

     send = "GET / HTTP/1.0\r\n\r\n"

     expect = "HTTP"

     use_regex = 0

     load_monitor = ruptime

     scheduler = rr

     protocol = tcp

     timeout = 6

     reentry = 15

     quiesce_server = 0

     server 192.168.104.69 {

         address = 192.168.104.69

         active = 1

         weight = 1

     }

     server 192.168.113.23 {

           address = 192.168.113.23

           active = 1

           weight = 1

     }

}

 

查看日志文件

   LVS的日志文件在可以从/var/log/message从得到.从这里你可以得到你在运行lvs各种服务时是否有报错信息,以及错误的来源与故障点,这个文件是系统排错时的理想助手.建议经常使用,方便排错与日常维护.

7 常见问题解答

常见问题解答

（1）LB上可以看到IPVS路由，但是得不到正常服务

解决办法 检查real server上web服务是否正常，检查real server的网络配置，确保real server配置正确的VIP，可以把数据包直接返回给请求客户端

 

检查办法

查看IPVS连接状态信息

ipvsadm -lcn

IPVS connection entries

pro expire state       source             virtual            destination

TCP 01:03  FIN_WAIT    192.168.14.206:1708 192.168.104.99:80  192.168.104.69:80

TCP 01:03  FIN_WAIT    192.168.14.206:1706 192.168.104.99:80  192.168.113.23:80

TCP 01:00  FIN_WAIT    192.168.14.206:1668 192.168.104.99:80  192.168.113.23:80

TCP 01:00  SYN-RECV    92.168.14.206:1670 192.168.104.99:80  192.168.104.69:80

 

             1

 

FIN_WAIT 代表TCP连接已经释放，数据发送完成

SYN-RECV 代表LB已经发起SYN请求，realserver 无响应或有异常

此时我们重点检查real server，确保realserver能正常提供服务，VIP正确配置

（2） LB可以学习到IPVS路由，real server也正常服务，但不能提供服务

在real server抓包，确保它能接受LB转发的数据包

Tcpdump –i tunl0

listening on tunl0, link-type RAW (Raw IP), capture size 96 bytes

17:52:29.220363 IP 192.168.14.206.1412 > 192.168.104.48.http: S 1584784775:1584784775(0) win 65535

17:52:29.220590 IP 192.168.14.206.1412 >  218.28.20.141.http: . ack 53993279 win 65535

17:52:29.225907 IP 192.168.14.206.1412 >  218.28.20.141 http: P 0:426(426) ack 1 win 65535

17:52:29.226780 IP 192.168.14.206.1412 >  218.28.20.141 http: . ack 230 win 65307

17:52:29.230546 IP 192.168.14.206.1412 >  218.28.20.141 http: F 426:426(0) ack 230 win 65307

如有以上信息，说明realserver已经通过 tunnnel正确接收数据包

检查realserver是否打开IP转发

0代表关闭IP转发

1代表打开IP转发

echo "1" >/proc/sys/net/ipv4/ip_forward

关闭ARP在real server上对VIP的响应，使的只有LB才会响应客户端的请求

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

在real server上配置tunnel ,

ifconfig tunl0 218.28.20.141  netmask 255.255.255.255 broadcast 218.28.20.141

route add -host 218.28.20.141  dev tunl0

 

（3 ）LB不能学习IPVS路由

确保LB上VIP正确配置，pulse 服务正常启动

检查 /usr/sbin/nanny是否正常启动，nanny进程主要是用来监控  realserver服务状态的

Ps –ef | grep nanny

在关闭pulse服务时，一定要先关闭备机上的pulse ,以避免切换到备机上

（4） iptunnel配置

Iptunnel 查看tunnel配置信息

sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc

tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc

LB上配置文件参考

该配置文件可以通过 vcompiranha管理工具配置完成后，保存生成

/etc/sysconfig/ha/lvs.cf

该配置文件的示例如下：

serial_no = 294

primary = 218.28.20.139

service = lvs

backup_active = 1

backup = 0.0.0.0

heartbeat = 1

heartbeat_port = 539

keepalive = 6

deadtime = 18

network = tunnel

debug_level = NONE

virtual JBOSS {

     active = 1

     address = 218.28.20.141 eth0:0

     vip_nmask = 255.255.255.255

     port = 80

     persistent = 0

     send = "GET / HTTP/1.0\r\n\r\n"

     expect = "HTTP"

     use_regex = 0

     load_monitor = ruptime

     scheduler = rr

     protocol = tcp

     timeout = 6

     reentry = 15

     quiesce_server = 0

     server 218.28.20.137 {

         address = 218.28.20.137

         active = 1

         weight = 1

     }

     server 218.28.47.201 {

           address = 218.28.47.201

           active = 1

           weight = 1

     }

}

在LB上配置完成后，一定要启动pulse 服务，引导LVS守护进程重新读取/etc/sysconfig/ha/lvs.cf，使新的配置生效

为保证LB重启后，pulse 服务自动启动

可以如下操作

Chkconfig –-add pulse

Chkconfig –-level 345 pulse on

（5） 常用命令和工具

 Tcpdump （参考man 手册）

 Ipvsadm  查看IPVS路由表

 Ipvsadm –lcn  以数字格式查看IPVS连接

Ping 检测网络

Route 查看路由表信息

more /proc/net/ip_vs_conn

系统日志分析

系统会/var/log下记录LVS的启动 变化 异常信息

More /var./log/messages

Apr 27 17:49:22 LB lvs[4634]: create_monitor for JBOSS/192.168.104.69 running as pid 4649

Apr 27 17:49:22 LB lvs[4634]: create_monitor for JBOSS/192.168.113.23 running as pid 4650

Apr 27 17:49:22 LB nanny[4649]: starting LVS client monitor for 192.168.104.48:80

Apr 27 17:49:22 LB nanny[4650]: starting LVS client monitor for 192.168.104.48:80

Apr 27 17:49:22 LB nanny[4650]: making 192.168.113.23:80 available

Apr 27 17:49:22 LB nanny[4649]: making 192.168.104.69:80 available

 

 

 

检查lvs集群网络:

网络问题上集群问题中最容易出错的地方,因为网络环境正常与否直接影响集群的状态.系后,应该在各个节点上远行ping命令,直接ping其它节点的ip,.查看网络是否通畅

Ping

Route 查看路由表信息

Ifconig –a 查看网络配置,检查VIP是否正确配置