高性能Linux服务器 第11章 构建高可用的LVS负载均衡集群
libnet软件包《-依赖-heartbeat（包含ldirectord插件（需要perl-MailTools的rpm包））
ldirectord插件-》调用ipvsadm命令
本章主要介绍高可用LVS负载均衡集群系统的搭建，首先介绍LVS的组成和特点，然
后介绍高可用LVS集群系统的拓扑结构，接着通过3个实例详细介绍如何通过heartbeat、
Keepalived及piranha来构建高可用LVS集群，最后，总结通过这3种方式构建高可用LVS
集群的优缺点。本章实践性强，实例都是真实环境的模拟。学完本章，读者能够对LVS集群
有更深的理解和认识。
11.1 LVS集群的组成与特点
Linux虚拟服务器(Linux Virtual Server，LVS)．是一个由章文嵩开发的一款*软件。利用LVS可以实现高可用的、可伸缩的Web、Mail、Cache和Media等网络服务。
并在此基础上开发支持庞大用户数的、可伸缩的、高可用的电子商务应用。LVS自1998年发展到现在，已经变得比较成熟，目前广泛应用在各种网络服务和电子商务应用中。
LVS具有很好的可伸缩性、可靠性和可管理性，通过LVS要实现的最终目标是：利用
Linux操作系统和LVS集群软件实现一个高可用、高性能、低成本的服务器应用集群。
11.1.1 LVS集群的组成
利用LVS架设的服务器集群系统由3个部分组成：最前端的是负载均衡层（这里用Load Balancer表示），中间是服务器群组层（用Server Array表示），底端是数据共享存储层（用Shared Storage表示）。
在用户看来，整个LVS集群系统的所有内部应用结构都是透明的，最终用户只是在使用一个虚拟服务器提供的高性能服务。
LVS体系结构如图11-1所示。
下面对LVS的各个组成部分进行详细介绍。
负载均衡层：位于整个集群系统的最前端，由一台或多台负载调度器( Director Server)
组成。LVS核心模板IPVS就安装在Director Server上，而Director的主要作用类似于
一个路由器，它含有为完成LVS功能所设定的路由表，通过这些路由表把用户的请求
分发给服务器群组层的应用服务器( Real Server)。同时，在Director Server上还要安装
对Real Server的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状
况。在Real Server不可用时可以将其从LVS路由表中剔除，在恢复时重新加入。
服务器群组层：由一组实际运行应用服务的机器组成，Rcal Server可以是Web服务
器、Mail服务器、FTP服务器、DNS服务器、视频服务器中的一个或多个，每个Real
Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director
Server也可以同时兼任Real Server的角色。
共享存储层：是为所有Real Server提供共享存储空间和内容一致性的存储区域，一
般由磁盘阵列设备组成。为了提供内容的一致性，一般可以通过NFS网络文件系统共
享数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系
统，例如Red Hat的GFS文件系统，Oracle提供的OCFS2文件系统等。
从整个LVS结构可以看出，Director Server是整个LVS的核心。目前，用于Directar Server
的操作系统只有Linux和FreeBSD，Linux 2.6内核完全内置了LVS的各个模块，不用任何设置就可以支持LVS功能。
对于Real Server，几乎所有的系统平台，如Linux、Windows、Solaris、AIX、BSD系列等都能很好地支持它。
11 .1.2 LVS集群的特点
1.IP负载均衡与负载调度算法
(1) IP负载均衡技术
负载均衡技术有很多实现方案，有基于DNS域名轮流解析的方法，有基于客户端调度访问的方法，有基于应用层系统负载的调度方法，还有基于IP地址的调度方法。
在这些负载调度算法中，执行效率最高的是IP负载均衡技术。
LVS的IP负载均衡技术是通过IPVS模块来实现的。IPVS是LVS集群系统的核心软件，它的主要作用是：安装在Director Server上，同时在Director Server上虚拟出一个IP地址，用户必须通过这个虚拟的IP地址访问服务器。
这个虚拟IP -般称为LVS的VIP，即Virtual IP。访问的请求首先经过VIP到达负载调度器，然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求。
在用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的Real Server节点，而Real Server节点如何返回数据给用户，是IPVS实现的重点技术。
IPVS实现负载均衡的方式有3种，分别是NAT、TUN和DR。下面进行详细介绍。
VS/NAT：即Virtual Server via Network Addrcss Translation，也就是网络地址翻译技术实
现虚拟服务器。当用户请求到达调度器时，调度器将请求报文的目棕地址（即虚拟IP
地址）改写成选定的Real Server地址，同时将报文的目标端口也改成选定的Real Server
的相应端口，最后将报文请求发送到选定的Real Server。在服务器端得到数据后，Real
Server将数据返回给用户时，需要再次经过负载调度器将报文的源地址和源端口改成
虚拟IP地址和相应端口，然后把数据发送给用户，完成整个负载调度过程。
可以看出，在NAT方式下，用户请求和响应报文都必须经过Director Server地址重写，
当用户请求越来越多时，调度器的处理能力将成为瓶颈。
VS/TUN：即Virtual Server via IP Tunneling，也就是通过IP隧道技术实现虚拟服务器。
这种方式的连接调度和管理与VS/NAT方式一样，只是报文转发方法不同。在VS/TUN
方式中，调度器采用IP隧道技术将用户请求转发到某个Real Server，而这个Real Server
将直接响应用户的请求，不再经过前端调度器。此外，对Real Server的地域位置没
有要求，可以和Director Server位于同一个网段，也可以在独立的一个网络中。因此，
在TUN方式中，调度器将只处理用户的报文谙求，从而使集群系统的吞吐量大大提高。
VS/DR:即Virtual Server via Direct Routing，也就是用直接路由技术实现虚拟服务器。这
种方式的连接调度和管理与前两种一样，但它的报文转发方法又有所不同，VS/DR
通过改写请求报文的MAC地址，将请求发送到Real Server．而Real Server将响应直
接返回给客户，免去了VS/TUN中的IP隧道开销。这种方式是3种负载调度方式中性
能最好的，但是要求Director Server与Real Server必须由一块网卡连在同一物理网段上（二层网络）。
(2)负载调度算法
前面介绍过，负载调度器是根据各个服务器的负载情况，动态地选择一台Real Serve响应用户请求。那么动态选择是如何实现呢？其实就是通过这里要说的负载调度算法。
根据不同的网络服务需求和服务器配置，IPVS实现了8种负载调度算法。这里详细讲述最常用的4
种调度算法。
□轮叫调度( Round Robin)。
“轮叫”调度也叫1:1调度，调度器通过“轮叫”调度算法将外部用户请求按顺序1：1地分配到集群中每个Real Server上。这种算法平等地对待每一台Real Server，而不管服务器上实际的负载状况和连接状态。
□加权轮叫调度（Wcighted Round Robin）。
“加权轮叫”调度算法根据Real Server的不同处理能力来调度访问请求。可以对每台Real Server设置不同的调度权值，对性能相对较好的Real Server可以设置较高的权值，
而对处理能力较弱的Real Server，可以设置较低的权值。这样保证了处理能力强的服务器处理更
多的访问流量，充分合理地利用了服务器资源。同时，调度器还可以自动查询Real Server的负载情况，并动态地调整其权值。
□最少连接调度( Least Connections)。
“最少连接”调度算法动态地将网络请求调度到已建立的连接数最少的服务器上。如果集群系统的真实服务器具有相近的系绕性能，采用“最小连接”调度算法可以较好地均衡负载。
□加权最少连接调度( Weighted Least Connections)。
“加权最少连接调度”是“最少连接调度”的超集。每个服务节点可以用相应的权值表
示其处理能力，而系统管理员可以动态地设置相应的权值，默认权值为1。加权最小连接调
度在分配新连接请求时尽可能使服务节点的已建立连接数和其权值成正比。
其他4种调度算法分别为：基于局部性的最少连接（Locality-Based Least Connections）、
带复制的基于局部性最少连接（Locality-Based Least Connections with Replication）、目标地
址散列( Destination Hashing)和源地址散列(Source Hashing)。如果想深入了解这4种调度策略，可以登录LVS中文站点zh.linuxvinualserver.org，查阅更详细的信息。
2．高可用性
LVS是一个基于内核级别的应用软件，因此具有很高的处理性能。由LVS构建的负载均衡集群系统具有优秀的处理能力，每个服务节点的故障不会影响整个系统的正常使用，又能够实现负载的合理均衡，
使应用具有超离负荷的服务能力，可支持上百万个并发连接请求。如配置百兆网卡，采用VS/TUN或VS/DR调度技术，整个集群系统的吞吐量可高达1Gbit/s:又如配置千兆网卡，系统的最大吞吐量可接近10Gbit/s。
3．高可靠性
LVS负载均衡集群软件已经在企业和学校中得到了很好的普及，国内外很多大型的、关键性的Web站点也都采用了LVS集群软件，所以它的可靠性在实践中得到了很好印证。
有很多由LVS构成的负载均衡系统，运行很长时间，从未进行过重新启动。这些都说明了LVS的高稳定性和高可靠性。
4．适用环境
目前LVS仅支持Linux和FreeBSD系统作为前端Director Server．但是支持大多数的TCP和UDP协议。支持TCP协议的应用有：HTTP、HTTPS、FTP、SMTP、POP3、IMAP4、PROXY、LDAP和SSMTP等；
支持UDP协议的应用有：DNS、NTP、ICP、视频和音频流播放协议等。
LVS对Real Server的操作系统没有任何限制，Real Server可运行在任何支持TCP/IP的操作系统上，包括Linux，各种UNIX（如FreeBSD、Sun Solaris、HP Unix等），Mac OS和Window等。
5．开源软件
LVS集群软件是按GPL (GNU Public License)许可证发行的*软件，因此，使用者可以得到软件的源代码，并且可以根据自己的需要进行各种修改，但是修改必须以GPL方式发行。
11.1.3 LVS集群系统的优缺点
LVS是一款*软件，任何人都可以免费获取并使用它，而且Linux也是一个开源操作系统，这二者的组合大大节约了企业的应用成本。同时LVS具有高稳定性和高可靠性，在高
并发和高吞吐量下，其有高负荷处理能力，当某个服务节点出现故障时，并不影响整个系统
服务的正常运行。这些优点使LVS已经广泛应用在企业、教育行业以及很多知名网站。
细心的读者可能已经发现了，LVS在具有上述优点的同时，还存在一个致命的缺点，从
图11-1可以清楚地看出，所有的用户请求都经过Director Server将任务分发到各个服务器节
点，那么，当只有一台Director Server时，将会出现单点故障点，如果这个Director Server出现故障，整个LVS系统将陷入瘫痪状态。
虽然Director Server仅完成用户请求的分发处理，负载并不是很大，但是对于一个健壮
的集群系统来说，单点故障是绝对不允许的。要避免这种单点故障，最实用、最简单的办法
就是对Director Server进行高可用集群，常见的方案就是为Director Server做一个双机热备：
正常状态下主Director Server工作，备用Director Server监控主Director Server的状态，当主Director Scrver出现异常或者故障时，备用Director Server马上接过主Director Server的工作，负责对用户请求进行分发处理。
这样就避免了一台Director Server的单点故障问题，保证了负载均衡端持续地提供服务。
11.2高可用LVS负载均衡集群体系结构
单一的Director Server可能会造成整个LVS集群系统的单点故障，为了解决这个问题，就需要保证Director Server的高可用性，最常用的方法就是在负载均衡层构建Director Server双机热备系统。
高可用的LVS负载均衡集群体系结构如图11-2所示。
从图11-2可以看出，整个体系结构仍然分为三层，在HA负载均衡层由主、备两台Director Server构成双机热备系统，双机之间通过心跳线连接。
在正常状态下主Director Server使用虚拟IP接收用户请求，并根据设定好的策略和算法将请求分发给各个服务节点，备用Director Server负责监控主Director Server的运行状态。
当主Director Server发生异常或出现故障时，备用Director Server负责接管主Director Server的虚拟IP和服务并继续接收用户请求和分发处理。通过这种相互监控策略，任意一方主机出故障时，
另一方都能够将IP和服务接管，这就保证了负载均衡层业务请求的不间断运行。
服务器群组层和共享存储层实现的功能与图11-1完全相同，不再讲述。
11.3 高可用性软件Heartbeat与Keepalived
11.3.1 开源HA软件Heartbeat的介绍
heartbeat是Linux-HA顼目中的一个组件，也是目前开源HA项目中最成功的一个例子，它提供了所有HA软件需要的基本功能，比如心跳检测和资源接管，监测集群中的系统服务，在群集的节点间转移共享IP地址的所有者等。
自1999年开始到现在，heartbeat在行业内得到了广泛应用，也发行了很多的版本。可以从Linux-HA的官方网站www.linux-ha.org下载到heartbeat的最新版本。
11.3.2安装heartbeat
这里下载的软件包是heartbeat-2.1.3.tar.gz，可通过源码进行安装。
同时还需要安装一个Iibnet工具包。libnet是一个高层次的API工具，可以从http://sourceforge.net/projects/libnet-dev/下载到，这里下载的是libnet-1.1.4.tar.gz。
heartbeat的安装非常简单，基本操作步骤如下：
(1)安装libnet。
[root@ DRI -] #tar -zxvf libnet-.1.4.tar.gz
[root@ DRl -] #cd libnet-1.1.
[root@ DRI -/libnet] #./configure
[root@ DRl -/libnet] #make
[root@ DRI -/libnet] #make install
(2)安装 heartbeat。
[root@ DRI -] #tar -zxvf heartbeat-2.1..tar.gz
[root@ DRI -] #cd heartbeat-2.1.
[root@ DRI -/heartbeat-.1.3]#./ConfigureMe configure\
>- - disable-swig --diaable - snmp- subagent
[root@ DRI -/heartbeat-.1.3] #make
[root@ DRI -/heartbeat-.1.3]#make inatall
[root@ DRI -/heartbeat-.1.3]#cp doc/ha.cf doc/haresources doc/authkeys /etc/ha.d/
[root@ DRI -/heartbeat-.1.3]#cp ldirectord/ldirectord.cf /etc/ha.d/
[root@ DRI -/heartbeat-.1.3]#groupadd -g haclient
[root@ DRI -/heartbeat-.1.3]#useradd -u -g haclient hacluster
heartbeat的安装包中包含了一个ldirectord插件，这个插件以后会用到。在heartbeat安装完毕后，此插件默认已经安装。但是为了保证ldirectord可用，还需要一个perl-MaiITools
的rpm包，这个rpm从系统盘中找到后安装即可。
11.3.3 开源HA软件Keepalived的介绍
Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态。它根据Iayer3，4&5交换机制检测每个服务节点的状态，如果某个服务节点出现异常，或工作出
现故障，Keepalived将检测到，并将出现故障的服务节点从集群系统中剔除，而当故障节点
恢复正常后，Keepalived又可以自动将此服务节点重新加入到服务器集群中。这些工作全部
自动完成，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。
Keepalived后来又加入了VRRP的功能。VRRP是Virtual Router Redundancy Protocol(虚拟路由器冗余协议）的缩写，它的作用是解决静态路由出现的单点故障问题，它能够保证网络不间断地、稳定地运行。
综上所述，Keepalived 一方面具有服务器运行检测功能，另一方面也具有HA cluster功能。因此通过Keepalived可以搭建一个高可用的LVS负载均衡集群系统。
11 .3.4 安装Keepalived
Keepalived的官方网址是http://www.keepalived.org，可以在这里下载到各种版本的Keepalived，这里下载的是keepalived-1.1.19.tar.gz。安装步骤如下：
[root@DRl -] #tar -zxvf keepalived-...tar.gz
[root@DRl -] #cd keepalived-..
[root@DRl keepalived - ..] # ./configure - - aysconf=/etc \
> --with- kernel-dir=/usr/src/kernela/2.6.-.el5-i686
[root@DRl keepalived-..]#make
[root@DRl keepalived-..]#make install
[root@DRl keepalived-..]#ln -s /usr/local/sbin/keepalived /sbin/
在编译选项中，“-sysconf”指定了Keepalived配置文件的安装路径，即路径为/etc/Keepalived/Keepalived.conf。“-with-kernel-dir”是个很重要的参数，但这个参数并不是要把Keepalived编译进内核，
而是指定使用内核源码中的头文件，即include目录。只有使用LVS时，才需要用到此参数，其他时候是不需要的。
安装完成，执行如下操作：
[root@drl -] # keepalived --help
Keepalived v1. . (/, )
Usage :
keepalived
keepalived -n
keepalived -f keepalived. conf
keepalived -d
keepalived -h
keepalived -v
Commands :
Either long or short options are allowed.
keepalived --vrrp -P Only run with VRRP subsystem.
keepalived --check -C Only run with Health-checker subsyatem.
keepalived -dont-release-vrrp -V Dcnt remove VRRP VIPs & VROUTEs on daemon atcp.
keepalived -dont-release-ipva -I Dont remove IPVS topology on daemon stop.
keepalived -dont-fork -n Dont fork the daemon process.
keepalived -use-file -f Use the specified configuration file.
Def ault is /etc/keepalived/keepalived . conf .
keepalived --dump-conf -d Dump the cortiguration data.
keepalived --log-console -l Log mesaage to local console.
keepalived - -log-detail -D Detailed log messages .
keepalived - -log- facility -s - Set syslog facility to LOG_LOCAL [-] .
( default=LOG_DAEMON)
keepalived --help -h Display this short inlined help screen.
keepalived --version -v Display the version number
keepalived --pid -p pidfile
keepalived --checkers_pid -c checkers pidfile
keepalived --vrrp_pid -r vrrp pidfile
这里列出了Keepalived的各种用法，同时也表明Keepalived已安装成功。
11.4安装LVS软件
LVS是通过IPVS模块来实现的。IPVS是LVS集群系统的核心软件，主要用于完成用户的请求到达负载调度器后，如何将请求发送到每个Real Server节点、Real Server节点如何返回数据给用户等。
11 .4.1 配置与检查安装环境
这里设定，操作系统采用CentOS 5.4，该版本内核默认支持LVS功能。为了方便编译
安装IPVS管理软件，在安装操作系统时，建议选择如下这些安装包：
□桌面环境：xwindows system、GNOME desktop environment。
□开发工具：development tools、x sofiware development、gnome software、development、
kde sottware development。
系统安装完毕后，可以通过如下命令检查kemel是否已经支持LVS的IPVS模块。
[root@DRl -] #modprobe -l |grep ipvs
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs.ko
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs_dh.ko
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs_f tp.ko
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs_lblc.ka
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs_lblcr.ko
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs_vs_lc.ko
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs_nq.ko
/lib/modules/2.6.-164.11..e15PAE/kernel/net/ipv4/ipVB/ip_vs_rr.ko
如果有类似上面的输出，表明系统内核默认支持IPVS模块。接下来就可以安装IPVS
管理软件了。
11.4.2 在Director Server上安装IPVS管理软件
IPVS提供的软件包有源码方式的也有rpm方式的，这里介绍如何通过源码方式安装IPVS。
首先从http://www.linuxvilrualserver.org/sofiware/ipvs.html下载对应版本的ipvs源码，由于这里采用的操作系统为CentOS 5.4舨本，因此，下载对应的ipvsadm-l .24版本，接着进行安装。
[root@DRI-]#tar zxvf ipvsadm-..tar.gz
[root@DRI-]#cd ipvsadm-1.24
[root@DRI-]#make
[root@DRI-]#make install
注意，在执行make时可能会出现类似如下的错误编译信息：
libipvs.h: 14:23: error: net/ip_vs .h: No such file or directory
这是由于编译程序找不到对应内核造成的。按照如下操作就可以正常编译：
[root@ DRl-]# In -s/usr/src/kernels/2.6.-.e15-i686 /usr/src/linux
也可以通过yum方式在线安装：
[root@ DRI-}#yum install ipvsadm
然后执行：
[root@ DRl-]# ipvsadm --help
如果看到帮助提示，表明IPVS已经成功安装。
11.5搭建高可用LVS集群
LVS集群有DR、TUN、NAT三种配置模式，可以对www服务、FTP服务、MAIL服务等进行负载均衡。下面通过3个实例详细讲述如何搭建www服务的离可用LVS集群系统,以及基于DR模式的LVS集群配置。
在进行实例介绍之前进行约定：操作系统采用CentOS 5.4，地址规划如表11-1所示。
表11-1地址规划情况
|
节点类型 |
IP地址规划 |
主机名 |
类型 |
|
主Director Server |
eth0:192.168.12.130 |
DR1 |
Pnblic IP |
|
eth1:10.10.10.1 |
priv1 |
private IP |
|
|
eth0:0:192.168.12.200 |
无 |
Virtual IP |
|
|
备用Director Server |
eth0:192.168.12.131 |
DR2 |
Public IP |
|
eth1:10.10.10.2 |
priv1 |
private IP |
|
|
Real server 1 |
eth0:192.168.12.132 |
rs1 |
Public IP |
|
lo:0:192.168.12.200 |
无 |
Virtual IP |
|
|
Real server 2 |
eth0:192.168.12.133 |
rs2 |
Public IP |
|
lo:0:192.168.12.200 |
无 |
Virtual IP |
整个高可用LVS集群系统的拓扑结构如图11-3所示。
11.5.1 通过heartbeat搭建LVS高可用性集群
1．配置LVS集群
配置LVS的方法有很多，可以通过LVS提供的ipvsadm命令进行配置，也可以通过第三方插件或工具来进行配置，例如通过Ldirectord来配置LVS．或者通过Rcdhat提供的界面工具piranha来配置等。
这里选择通过Ldirectord来配置LVS。
(1)通过Ldirectord在主、备Director Server上配置LVS
Ldirectord是heartbeat的一个插件，在安装heartbeat时，默认已经安装了此插件。Ldirectord主要用于监控集群系统中每个服务节点的运行状态，当某个节点的服务出现异常或主机出现故障时，
将此节点从集群系统中剔除，并且在节点恢复正常后，重新将此节点加入集群系统。
除了监控服务节点外，Ldirectord的另一个功能是配置LVS，只需设置好Ldirectord的配置文件，启动服务即可，Ldirectord会自动调用ipvsadm命令创建LVS路由表信息。
Ldirectord配置文件的默认路径为/etc/ha.d/ldirectord.cf。这里详细介绍一下这个文件中每个选项的含义。
下面是需要配置的选项。
checktimeout=20 #判定Real Server出错的时间间隔
Checkinterval=10 #指定Ldirectord在两次检查之同的间隔时间
Fallback=127.0.0.1:80 #当所有的Real Server节点不能工作时，Web服务重定向的地址
autoreload=yes #是否自动重载配置文件，选yea时，配置文件发生变化，自动载入配置信息
logfile=”/var/log/ldirectord. Log”
#设定Ldirectord日志输出文件路径
quiescent（静止的）=no #当选择no时，如果一个节点在checktimeout设置的时问周期内没有响应，
#ldirectord将会从LVS的硌由表中直接移除Real Server．此时，将中断
#现有的客户端连接，并使LVS丢掉所有的连接跟踪记录和持续连接模扳；
#如果选择yea，当某个Real Server失效时．Ldirectord将失效节点的
#权值设置为0，新的连接将不能到达，但是并不会从LVS路由表中清除此
#节点，同时，连接跟踪记录和程序连接模板仍然保留庄Director上
注意，以上几行为ldirectord．cf文件的全局设置，它们可以应用到多个虚拟主机。下面是每个虚拟主机的配置。
Virtual=192.168.12.200:80 #指定虚拟的IP地址和端口号，注意，在virtual这行后面的行
#必须缩进4个空格或以一个tab字符进行标记
real=192.168.12.132:80 gate #指定Real Server服务器地址和端口，同时设定LVS工作模式,
#用gate表示DR模式，ipip表示TUNL模式，masq表示NAT模式
real=192.168.60.133:80 gate
fallback=127.0.0.1:80 gate
Service=http #指定服务的类型，这里是对HTTP服务进行负载均衡
Request=”index .html” # Ldirectord将根据指定的Real Senrer地址，结合该选项给
#出的请求页面，发送访问请求，检童Real Server上的服务是
#否正常运行，必须确保这里给出的页面地址是可访问的，不然
#Ldirectord会误认为此节点已经失效，发生错误监控现象
receive=”Test Page “ #指定请求和应答字串，也就是index．html的内容
scheduler=rr #指定调度算法，这里是rr（轮询）算法
protocol=tcp #指定协议的类型，LVS支持TCP和UDP协议
checktype=negotiate #指定Ldirectord的检测类型，checktype可以是connect、
# external、negotiate、off、on、ping和checktimeout
#这几个，默认为negatiate，通过页面交互未判断服务器节点
#是否正常
sheckport=80 #指定监控的端口号
virtualhost=www. Ixdba.net #虚拟服务嚣的名称，可任意指定
配置完毕后就可以执行如下命令启动或关闭Ldirectord服务：
/etc/init.d/ldirectord {start |stop}
(2) Real server的配置
在LVS的DR和TUN模式下，用户的访问请求到达Real Server后，是直接返回给用户的，不再经过前端的Director Server，因此，需要在每个Real server节点上增加虚拟的VIP地址，这样数据才能直接返回给用户。
增加VIP地址的操作可以通过创建脚本的方式来实现。创建文件/etc/init.d/lvsrs，脚本内容如下：
[root@rsl -] #more /etc/init.d/lvsra
# !/bin/baah
#description : Start Real Server
VIP=.168.12.
. /etc/rc.d/ini.d/functions
case "$1” in
start)
echo " Start LVS of Real Server “
/sbin/ifconfig lo: $VIP broadcaat $VIP netmask 255.255.255.255 up
echo “” >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo “” >/proc/sys/net/ipv4/conf/lo/arp_announce
echo “” >/proc/sys/net/ipv4/conf/all/arp_ignore
echo “” >/proc/sya/net/ipv4/conf/all/arp_announce
;;
stop)
/sbin/ifconfig lo : down
echo” close LVS Director aerver”
echo “” >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo “” >/proc/sys/net/ipv4/conf/lo/arp_announce
echo “” >/proc/sys/net/ipv4/conf/all/arp_ignore
echo “” >/proc/sys/net/ipv4/conf/all/arp_announce
;;
*)
echo "Usage: $O {start|stop} “
exit
esac
然后修改lvsrs使其具有可执行权限。
[root@rsl -] #chomd /etc/init.d/lvsrs
最后，可以通过下面的命令启动或关闭lvsrs：
service lvsrs { start | stop }
2.在主、备Director Server上配置heartbeat
在搭建Director Server的双机热备系统之前，首先需要在两台主机上安装heartbeat软件。heartbeat的安装已经在前面介绍过，这里不再讲述，直接进入heartbeat的配置。
(1)配置heartbeat的主配置文件(/etc/ha.d/ha.cf)
下面对ha．cf文件的每个选项进行详细介绍。
#debugfile /var/ log/ha - debug
logfile /var/log/ha- log #指定heartbeat酌日志存放位置
#crm yes #是否开启ClusterReaourceManager（集群资源管理）功能
bcast ethl #指定心跳使用以太网广播方式，并且在ethl接口上进行广播
logfacility loca10
keepalive 2 #指定心跳间隔时间为2秒（即每2秒在eth1上发送一次广播）
deadtime 30 #如果指定各用节点在30秒内没有收到主节点的心跳信号，则
#立即接管主节点的服务资源
warntime 10 #指定心跳延迟的时闻为10秒。当10秒内备用机不能接收到主节点的
#心跳信号时，就会在日志中写入一个警告信息，但此时不会切换服务
initdead 120 #在某些系统上，系统启动或重启之后需要经过一段时间网络才能
#正常工作，该选项用于设置这种情况产生的时间间隔，取值至少为
#deadtime的两倍
udpport 694 #设置广播通信使用的端口，694为默认使用的端口号
baud 19200 #设置串行通信的比特率
serial /dev/ttyS0 #选择串行通信设套，用于双机使用串口线连接的情况。如果双机
#通过以太网连接，则应该关闭该选项
#ucaat eth0 192.168.1.2 #采用网卡eth0的UDP单播来组织心跳，后面跟的IP地址应为
#双机中对方的IP地址
#mcast eth0 225.0.0.1 6941 0 #采用网卡eth0的UDP多播来组织心跳，一般在备用机不止
#一台时使用，bcast、ucast和mcast分别代表广播、单播和
#多播，是组织心跳的3种方式，任选其一即可
auto_failback on #用来定义当主节点恢复后，是否将服务自动切回，heartbeat的两
#台主机分别为主节点和备用节点。主节点在正常情况下占用资源
#并运行所有的服务，遇叫故障时把资源交给备用节点并由备用
#节点运行服务。在将该选项为on的情况下，一旦主节点恢复运行，
#则自动获取资源并取代备用节点；如果该选项设置为off，那么，
#主节点恢复后，将变为备用节点，而原来的备用节点成为主节点
#stonith baytech/etc/ha. d/conf/stonith. baytech
#stanith的主要作用是使出现问题的节点从集群环境中脱离，进而释放集群
#资源，避免两个节点争用—个资源的情况发生，保证共享数据的安全性和完整性
#watchdog /dev/watchdog #该选项是是可选配置，通过heartbeat来监控系统的运行状态。使用该
#特性，需要在内核中载入“softdog”内核模块，用来生成实际的设备
#文件，如果系统中没有这个内核模块，就需要指定此模块，重新编译内核。
#编译完成后输入“insmod softdog”加载该模块，然后输入“grep
# misc /proc/devices”（应为10），输入“cat /proc/miac |
# grep watchdog”（应为130），最后，生成设备文件“mknod/dev/
#watchdog c 10 130”即可使用此功能
node DR1 #主节点主机名，可以通过命令“uanme -n”查看
node DR2 #备用节点主机名
ping 192.168.12.1 #选择ping的节点，ping节点选择得越好，HA集群就越强壮。可以选择
#固定的路由器作为ping节点，但是最好不要选择集群中的成员作为ping
#节点，ping节点使用来测试网络连接
ping node 192 . 168 . 12 . 188 192. 168. 12. 100
#指定ping node。ping node并不是双机中的两个节点，仅仅用来测试
#网络的连通性
respawn hacluster /usr/lib/heartbeat/ipfail #respawn inittab文件自动重启杀不死
#该选项是可选配置，列出与heartbeat 一起启动和关闭的进程，该进程
#一般是和heartbeat集成的插件，这些进程遇到故障可以白动重新启动。
#最常用的进程是ipfail，此进程用于检测和处理网络故障，需要配合ping
#语句指定的ping node未检测网络的连通性。其中hacluster表示启动
#ipfail进程的身份
(2)配置heartbeat的资源文件(/etc/ha.d/haresources)
haresources文件用于指定双机系统的主节点、集群IP、子网掩码、广播地址以及启动的服务等集群资源。文件每一行可以包含一个或乡个资源脚本名，资源脚本名之间用空格隔开，参数之间使用两个冒号隔开。
DRl IPaddr：：192. 168. 12. 200/24/etho ldirectord #设置 DRI为主节点，集群服务器
#的IP地址为192 .168 .12. 200，
#netmask为255.255.255.0,
#同时指定此IP使用的网络接口为
#eth0, heartbeat托管的服务
#为ldirectord
注意，这里的Ldirectord对应的文件为/etc/init.d/ldirectord，即Ldirectord服务的启动文件，也就是将Ldirectord的启动与关闭交给heartbeat来管理。
另外，LVS主节点和备份节点中的资源文件haresources要完全一致，当指定DRI是主节点后，另一个节点DR2就是备份
节点。
(3)配置heartbeat的认证文件（etc/ha.d/authkeys)
authkeys文件用于设定hcartbeat的认证方式，该文件中有3种可用的认证方式：crc、
shal和md5，这里使用crc认证方式。设置如下：
auth
crc
# ahal ahal_any_password
# md5 md5_any_pa8aword
需要说明的一点是，无论“auth”后面指定的是什么数字，在下一行必须作为关键字再
次出现，例如指定了"auth 6”，下面一定要有一行“6认证类型”。
最后确保这个文件的权限是600（即-rw-----）。
3．启动heartbeat+LVS集群系统
(1)启动heartbeat服务
所有配置完成后，就可以在主、备Director Server上启动heartbeat服务了。可以通过如下方式管理heartbeat服务：
[root@DRl-] #/etc/init.d/heartbeat\
>{start|stop|atatus|reatart| reload|force - reload}
由于heartbeat托管了主、备Dircctor Server上的Ldirectord服务，因此只需在主、备两
台机器上启动heartbeat服务即可，这样Ldirectord服务就在主机上启动起来了。
(2)启动Real Server节点服务
分别在两个Rcal Servcr节点上执行如下脚本：
[root@rsl～]#/etc/init.d/lvsrs start
至此，通过heartbeat构建的高可用LVS集群系统已经配置完成并运行起来了。
11.5.2 通过Keepalived搭建LVS高可用性集群系统
1．配置Keepalived
Keepalived的配置非常简单，仅需要一个配置文件即可完成对HA cluster和LVS服务节点监控。Kcepalived的安装已经在前面介绍过，在通过Keepalived搭建高可用的LVS集群实
例中，主、备Director Server都需要安装Keepalived软件，安装成功后，默认的配置文件路
径为/etc/Keepalived/Keepalived.conf。一个完整的keepalived配置文件由3个部分组成，分别是全局定义部分、vrrp实例定义部分以及虚拟服务器定义部分。下面详细介绍这个配置文
件中每个选项的详细含义和用法。
http://www.ituring.com.cn/article/179808
http://www.cnblogs.com/quiet/archive/2012/03/19/2406606.html
keepalived采用关键字分层的方式来组织配置文件， 在上面摘取的配置文件片段中，共有4层关键字，位于第零层的关键字有：global_defs, vrrp_instance, vritual_server等， 位于第一层的关键字有：notification_email, state, delay_loop, real_server等， 位于第二层的关键字有weight, SSL_GET, 位于第三层的关键字有url等， 位于第四层的关键字有path, digest等。若把位于同一层的关键字组织成一个列表(或者叫向量vector)， 则该列表具有这样的特性：它的每一个元素都是一个关键字， 而该关键字可能指向下一层的关键字列表，如此反复。
keepalived的配置文件还支持include的用法， 可以在当前配置文件中用include newconf的方式包含下一个配置文件， 且下一个配置文件里面也可以用include包含下下一个配置文件。而且一个配置文件里面也可以用多个include语句包含多个配置文件进行。此外， keepalived还支持在传递配置文件名字时， 采用包含正则表达式的记法， 如：你可以传递一个”*.conf”作为配置文件的名字， 对应的是解析当前目录下所有以.conf结尾的文件。
如上所述， keepalived在配置文件解析方面拥有非常灵活的方式， 采用关键字分层（每层的关键字数量不限，且关键字的层次也不限制）的方法进行组织一个配置文件， 且支持include语句和正则表达式记法的配置文件名， 要怎么设计才可以实现这样的功能？ keepalived是用C语言实现的， 不像python等拥有很多封装好的库可以使用。 具体的解析过程在接下来的文章里面会进行具体地分析。
#全局定义部分
! Configuration File for keepalived
global_defs{
#notification_email {
# dba.gao@gmail.com #设置报警邮件地址，可以设置多个，每行一个。注意，如果要开启邮件报警，需要开启本机的sendmail服务
# ixdba@．com
#}
# Notification_email_from Alexandre.Cassen@firewall.loc #设置邮件的发送地址
# smtp_server .168.200. #设置smtp server地址
# smtp_connect_timeout #设置连接smtp server的超时时间
Router_id LVS_DEVEL #表示运行Keepalived服务器的一个标识,负载均衡器标识，同一网段内，可以相同。发邮件时显示在邮件主题中的信息
} #vrrp 实例定义部分
vrrp_instance VI- { #定义vrrp实例
state MASTER #指定Keepalived的角色，MASTER表示此主机是主服务器，BACKUP表示此主机是备用服务器
interface eth0 #指定HA监测网络的接口,LVS监控的网络接口
Virtual_router_id #虚拟路由标识，这个标识是一个数字，同一个vrrp实例使用唯一的标识，即同一个vrrp_instance下，MASTER和BACKUP必须是一致的
mcast_src_ip 192.168.0.211 #发送多播包的地址，如果不设置，默认使用绑定的网卡的primary IP。
priority #定义优先级，数字越大，优先级越高。在一个vrrp_instance下，MASTER的优先级必须大于BACKUP的优先级
advert_int #设定MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒
nopreempt #设置不抢占，注意这个设置只能设置在backup状态主机上，而且这个主机的priority必须比另外的主机高
#reempt_delay #抢占延迟，默认5分钟
Authentication { #设定验证类型和密码
auth_type PASS #设置验证类型，主要有PASS和AH两种
auth_pass #设置验证密码，在一个vrrp_instance下,MASTER与BACKUP必须使用相同的密码才能正常通信
}
virtual_ipaddress{ #设置虚拟IP地址，可以设置多个虚拟IP地址，每行一个
192.168.12.200
# 192.168.1.9 //如果有多个，往下加就行了
# 192.168.1.7
}
} #虚拟服务器定义部分
virtual_server 192.168.12.200 { #设置虚拟服务嚣，需要指定虚拟IP地址和服务端口，IP与端口之间用空格隔开
delay_loop #设置运行情况检查时间，单位是秒
lb_algo rr #设置负载调度算法，这里设置为rr．即轮询算法
lb_kind DR #设置 LVS实现负载均衡的机制，有NAT、TUN和DR三个模式可选
Persistence_timeout #会话保持时问，单位是秒，这个选项对动态
#网页是非常有用的，为集群系统中的session共享
#提供了一个很好的解决方案。有了这个会话保持功能，用户的请求会被
#一直分发到某个服务节点，直到超过这个会话的保持时间。需要注意的是，
#这个会话保持时间是最大无响应超时时间，也就是说，用户在操作动态页
#面时，如果在50秒内没有执行任何操作，那么接下来的操作会被分发到
#另外的节点，但是如果用户一直在操作动态页面，则不受50秒的时间限制
protocol TCP #指定转发协议类型，有TCP和UDP两种
Real_server 192.168.12.132 { #配置服务节点1,需要指定real aerver的真实IP地址和端口，IP与端口之间用空格隔开
weight #配置服务节点的权值，权值大小用数字表示，数字越大，权值越高，设置
#权值的大小可以为不同性能的服务器分配不同的负载，可以为性能高的
#服务器设置较高的权值，而为性能较低的服务器设置相对较低的权值，
#这样才能合理地利用和分配系统资源
TCP_CHECK { #Real_server的状态检测设置部分，单位是秒 ,通过tcpcheck判断RealServer的健康状态
connect_timeout #表示5秒无响应超时
nb_get_retry #表示重试次数
delay_before_retry #表示重试间隔
connect_port #检测端口
}
}
real_server 192.168.12.133 { #配置服务节点2
weight
TCP_CHECK {
connect_timeout
nb_get_retry
delay_before_retry
connect_port
}
} real_server 192.168.201.100 {
weight
TCP_CHECK {
connect_timeout
nb_get_retry
delay_before_retry
} SSL_GET {
url {
path /
digest ff20ad2481f97b1754ef3e12ecd3a9cc
}
url {
path /mrtg/
digest 9b3a0c85a887a256d6939da88aabd8cd
}
connect_timeout
nb_get_retry
delay_before_retry
}
} real_server 192.168.200.2 {
weight
HTTP_GET {
url {
path /testurl/test.jsp
digest 640205b7b0fc66c1ea91c463fac6334d
}
url {
path /testurl2/test.jsp
digest 640205b7b0fc66c1ea91c463fac6334d
}
url {
path /testurl3/test.jsp
digest 640205b7b0fc66c1ea91c463fac6334d
}
connect_timeout
nb_get_retry
delay_before_retry
}
}
在配置Keepalived.conf时，需要特别注意配置文件的语法格式，因为Keepalived在启动时并不检测配置文件的正确性，即使没有配置文件，Keepalived也照样能够启动，所以一定要保证配置文件正确。
在默认情况下，Kecpalived在启动时会查找/ctc/Keepalived/Keepalived.conf配置文件，如果配置文件放在了其他路径下，可以通过“Keepalived-f”参数指定配置文件的路径即可。
Keepalived.conf配置完毕后，将此文件复制到备用Dircctor Servcr对应的路径下，然后进行以下两个简单的修改即可：
口将“state MASTER”更改为“state BACKUP”。
口将“priority 100”更改为一个较小的值，这里改为“priority 80”。
2．配置Real server节点
与heartbeat+LVS类似，Keepalived+LVS也需要为Rcal server节点配置相关的脚本，以达到与Director Server相互通信的目的。脚本的内容已经在前面介绍过，这里不再讲述。
3．启动Keepalived+LVS集群系统
在主、备Director Server上分别启动Keepalived服务，可以执行如下操作：
[ root@DRI ~] #/etc/ init . d/Keepalived start
接着在两个Real server上执行如下脚本：
[ root@rsl-l #/etc/init.d/lvars start
至此，Keepalived+LVS高可用的LVS集群系统已经运行起来了。
11.5.3通过piranha搭建LVS高可用性集群
piranha是REDHAT提供的一个基于Web的LVS配置软件，通过piranha可以省去手工配置LVS的繁琐工作。同时，piranha也可以单独提供集群功能，例如，可以通过piranha激活Dircctor Server的备用主机。
这里利用piranha来配置Director Server的双机热备功能。
1．安装与配置piranha
piranha工具的安装非常简单，下载piranha的rpm包，在主、备Director Server上进行
安装即可。过程如下：
[rootaDRl~}#rpm -ivh piranha-0.8.- i386.rpm
也可以通过yum命令直接在线安装。过程如下：
[root@DR2 ] # yum install piranha
piranha妄装完毕后，会产生/etc/sysconfig/ha/lvs.cf配置文件。默认此文件是空的，可以
通过piranha提供的Web界面配置此文件，也可以直接手动编辑此文件。编辑好的lvs.cf文
件内容大致如下。
[root@DRI -]# more /etc/sysconfig/ha/ha.cf
Serial_no= #序号
primary =.168.60. #指定主Director Server的真实IP地址
service - Ivs #指定双机的服务名
backup_active= #是否激活套用Directar Server.””表示不激活，“1一表示激活。
#这里选择激活
backup =... #这里指定备用Director Senrer的真实IP地址，如果没有备用
#Director Server，可以用“0.0.0.0”代替
heartbeat = #是否开启心跳．1表示开启，0表示不开启
heartbeat_port -= #指定心跳的UDP通信端口。
keepalive = #心跳间隔时间，单位是秒
deadtime -= #如果主Director Server在deadtime{秒）后没有响应，那么备用
#Director Server就会接管主Director Server的服务
netvork =direct #指定LVS的工作模式，direct表示DR模式，nat表示NAT模式，tunne1
#表示TUN模式
debug_level = NONE #定义debug调试信息级别
virtual vvww. ixdba _ net { #指定虚拟服务的名称
active = #是否激活此服务
address =... eth0: #虚拟服务绑定IP及网络设备名
port = #虚拟服务的端口
send=”GET/HTTP/.\r\n\r\n" #向real 发送的验证字符串
expect =”HTTP ” #服务器正常运行时应该返回的文本应答信息，用来判断Real Server
#是否工作正常
use_regex = # expect选项中是否使用正则表达式，0表示不使用，1表示使用
Load_monitor = none #LVS中的Director Server能够使用rup或ruptime来监视各个
#Real Server的负载状态。该选项有3个可选值，rup、ruptime和
#none，如果选择rup，每个Real Server就必须运行rstatd服务。
#如果选择了ruptime，每个Real Server就必须运行rwhod服务
scheduler = rr #指定LVS的调度算法
protocol = tcp #虚拟服务使用的协议类型
timeout = #Real Senrer失效后从LVS路由列表中移除失效Real Server所必须持续
#的时同，以秒为单位
reentry = #某个Real Server被移除后，重新加入LVS路由列表中必须持续的时间，
#以秒为单位
quiesce_server = #如果此选项为1，那么当某个新的节点加入集群时，最少连接数会被重设
#为零，因此LVS会发送大量请求到此服务节点，造成新的节点服务阻塞，
#建议设置为0
server RSl { #指定Real Server服务名
address =192.168.12.132 #指定Real Server的IP地址
active = #是否激活此Real Senrer服务
weight = #指定此Real Senrer的权值，是整数值，权值是相对于所有Real Server
#节点而言的，权值高的Real Server处理负载的性能相对较强
}
server RS2 {
address =192.168.12.133
active =
weight =
}
}
接着，还需要对两个Real Server节点进行配置，也就是创建/etc/init.d/lvsrs脚本，这个
脚本在前面已经讲述，这里不再介绍。
2．启动通过piranha配置的LVS集群系统
将编辑好的lvs.cf从Director Server的主节点复制到备用节点，然后在主、备节点上分
别启动pulse服务，即启动LVS服务。过程如下：
[root@DRl-]#service pulse start
接下来，还要在主、备节点上启用系统的包转发功能（其实只有在NAT模式下需要）。
命如下：
[rootODRl-]#echo “”>/proc/sys/net/ipv4/ip_forward
最后，在两个Real server节点上执行lvsrs脚本。命令如下：
[root@rsl-]#/etc/init.d/lvsrs start
到此为止，利用piranba工具搭建的高可用LVS集群系统已经运行起来了。
11.6测试高可用LVS负载均衡集群系统
高可用的LVS负载均衡系统能够实现LVS的高可用性、负载均衡特性和故障自动切换特性，因此，对其进行的测试也针对这3个方面进行。这里只对Keepalived+LVS实例进行测试,其他实例也有类似的效果，不一一讲述。
11 .6.1 高可用性功能测试
高可用性是通过LVS的两个Director Server完成的。为了模拟故障，先将主Director Server上面的Keepalived服务停止，然后观察备用Director Server上Keepalived的运行日志。信息如下：
May 4 16:50:04 DR2 Keepalived_vrrp: VRRP_lnatance (VI_l) Tranaition to MASTER STATE
May 4 16:50:05 DR2 Keepalived_vrrp: VRRP_Inatance(VI_l) Entering MASTER STATE
May 4 16:50:05 DR2 Keepalived_vrrp: VRRP Inatance (VI_l) setting protocol VIPs.
May 4 16:50:05 DR2 Keepalived_vrrp: VRRP_Inatance(VI_1) Sending gratuitous（无理由的） ARPs on
Eth0 for 192.168.12.200
May 4 16:50:05 DR2 Keepalived_vrrp: Netlink reflector reports IP 192.168.12.200
added
May 4 16:50:05 DR2 Keepalived_healthcheckers : Netlink reflector reports IP
192 . 168 .12 .200 added
May 4 16:50:05 DR2 avahi-daemon [2551] : Registering new address record for
192 . 168 . 12 . 200 on eth0.
May 4 16:50:10 DR2 Keepalived_vrrp: VRRP_Inatancece(VI_ l) Sending gratuitous ARPs on
eth0 for 192 . 168.12 . 200
从日志中可以看出，主机出现故障后，备用机立刻检测到，此时备用机变为MASTER
角色，并且接管了主机的虚拟IP资源，最后将虚拟IP绑定在eth0设备上。
按着，重新启动主Director Server上的Keepalived服务，继续观察备用Dircctor Server
的日志状态。
May 4 16:51:30 DR2 Keepalived_vrrp:VRRP_lnstance(VI_I) Received higher prio advert
May 4 16:51:30 DR2 Keepalived_vrrp:VRRP_lnstance(VI_I) Entering BACKUP STATE
May 4 16:51:30 DR2 Keepalived_vrrp:VRRP_lnstance(VI_I) removing protocol VIPs.
May 4 16:51:30 DR2 Keepalived_vrrp:Netlink reflector reports IP 192.168.12.200
removed
May 4 16:51:30 DR2 Keepalived_healthcheckers: Netlink reflector reports IP
192 . 168 .12 . 200 removed
May4 16:51:30 DR2 avahi-daemon [2551]:Withdrawing address record for 192.168.12.200
on eth0.
从日志可知，备用机在检测到主机重新恢复正常后，重新返回BACKUP角色，并且释
放了虚拟IP资源。
Linux就这个范儿 第11章 独霸网络的蜘蛛神功 第11章
http://www.cnblogs.com/MYSQLZOUQI/p/5257200.html
Linux就这个范儿 第15章 七种武器
http://www.cnblogs.com/MYSQLZOUQI/p/5335649.html
控制操作方面，用户空间是通过netlink下发控制命令的。例如NFC_CMD_START_POLL
和NFC_CMD_STOP_POLL是用来查询目标的操作，而NFC_EVENT_TARGETS_FOUND事件用来返回查询结果。有关netlink操作可参考代码4：
代码4：
Int nfcctl_init{struct nfcctl *ctx}
{
Int id;
Int rc;
printdbg { " IN " } ;
ctx->nlsk = nl_socket_alloc ( ) ;
if ( !ctx->nlsk) {
printdbg ( " Invalid context " ) ;
return -ENOMEM;
}
rc = genl_connect ( ctx->nlsk) ;
if (rc) {
rc = -nlerr2syserr ( -rc) ;
printdbg ( " Error connecting to generic netlink : %s " , strerror ( -rc)} ;
goto free_nlsk;
}
ctx- >nlf amily = genl_c trl_resolve ( ctx->nlsk, NFC_GENL_NAME ) ;
if (ctx->nlfamily < ) {
rc = -nlerr2 syserr ( -ctx->nlfamily) ;
printdbg ( " Error resolving genl NFC family: %s" , strerror (-rc)} ;
goto free_nlsk;
}
id = get_multicast_id ( ctx , NFC_GENL_NAME ,
NFC_GENL_MCAST_EVENT_NAME);
If (id<=) {
rc = id;
goto free_nlsk;
}
rc = nl_socket_add membership (ctx->nlsk, id) ;
if (rc) {
printdbg ( " Error adding nl socket to membership " ) ;
rc = -nlerr2syserr ( -rc ) ;
goto free_nlsk
}
......
用户空间和控制命令处理程序之间用的是netlink，在第15章“七种武器”中的“module
与用户通信：netlink方式”部分我们做了分析与讲解。最好的学习方法是贯彻理论与实践相结合的科学发展观，结合那节内容与这个NFC实例一起看。
netlink方式
netlink通过为内核模块提供一组特殊的API，并为用户程序提供了一组标准的socket接口的方式，实现了一种全双工的通信连接。
类似于TCP/IP中使用AF_INET地址族一样，netlink使用地址族AF_NETLINK。这种通信机制相对于系统调用、ioctl以及/proc文件系统而言具有以下优点：
(1) netlink使用标准的socket API，易用性好。用户仅需要在flinux/netlink.h中增加一个新类型的netlink协议定义即可，
如#defrne NETLINK_MYTEST 17。然后，内核和用户态应用就可以立即通过socket API使用该netlink协议类型进行数据交换。但用其他方法增加新的特性可不是一件容易的事情，
因为我们要冒着污染内核代码并且可能破坏系统稳定性的风险去完成这件事情。系统调用需要增加新的系统调用，ioctl则需要增加设备或文件，
那需要不少代码，proc文件系统则需要在/proc下添加新的文件或目录，那将使本来就混乱的/proc更加混乱。
(2) netlink是一种异步通信机制，在内核与用户态应用之间传递的消息保存在socket缓存队列中，发送消息只是把消息保存在接收者的socket的接收队列，
而不需要等待接收者收到消息，但系统调用与ioctl则是同步通信机制，如果传递的数据太长，将影响调度粒度。
(3)使用netlink的内核部分可以采用模块的方式实现，使用netlink的应用部分和内核部分没有编译时依赖，
但系统调用就有依赖，而且新的系统调用的实现必须静态地连接到内核中，它无法在模块中实现(动态库方式实现)，使用新系统调用的应用在编译时需要依赖内核。
(4) netlink支持多播，内核模块或应用可以把消息多播给一个netlink组，属于该neilink组的任何内核模块或应用都能接收到该消息，内核事件向用户态的通知机制就使用了这一特性，任何对内核事件感兴趣的应用都能收到该子系统发送的内核事件。
(5)内核可以使用netlink首先发起会话，但系统调用和ioctl只能由用户应用首先发起调用。
不仅如此，对于我这种钟爱BSD风格的开发者来讲，使用这种socket API函数有一种亲切感，相对于系统调用或者ioctl方式而言上手更快一些。
11.6.2负载均衡测试
这里假定两个Real Server节点上配置www服务的网页文件的根目录均为/wcbdata/www目录，然后分别执行如下操作：
在real serverl执行：
echo “This is real serverl” /webdata/www/index. html
在real server2执行：
echo "Thie is real server2” /webdata/www/index.html
接着打开浏览器，访问http://192.168.12.200这个地址，然后不断刷新此页面。如果
能分别看到“This is real serverl”和“This is real server2”就表明LVS已经在进行负载均衡了。
11.6.3故障切换测试
故障切换是测试在某个节点出现故障后，Keepalived监控模块是否能及时发现，然后屏
蔽故障节点，同时将服务转移到正常节点上执行。
这里将real server 1节点服务停掉，假定这个节点出现故障，然后查看主、备机日志信息。相关日志如下：
May 4 17:01:51 DR1 Keepalived_healthcheckers: TCP connection to
[192. 168. 12. 132: 80] failed !!!
May4 17:01:51 DR1 Keepalived_healthcheckers: Removing service [192 .168 .12 .132: 80]
from VS[192. 168. 12 .200: 80]
May 4 17:01:51 DRl Keepalived_healthcheckers: Remote SMTP server [127.0.0.1:25]
connected．
May 4 17:02:02 DRI Keepalived_healthcheckers: SMTP alert successfully sent.
通过日志可以看出，Keepalived监控模块检测到192.168.12.132这台主机出现故障后，将此节点从集群系统中剔除掉了。
此时访问http://192.168.12.200这个地址，应该只能看到“This is real server2”了。这是因为节点1出现故障，Keepalived监控模块将节点l从集群系统中剔除了。
下面重新启动real server l节点的服务，可以看到Keepalived日志信息如下：
May 4 17:07:57 DR1 Keepalived_healthcheckers: TCP connection to
[192 168 .12 . 132 : 80] success.
May 4 17:07:57 DR1 Keepalived_healthcheckers: Adding service [192 . 168 . 12 .132 : 80]
to VS [192 168 12.200 : 80]
May4 17:07:57 DR1 Keepalived_healthcheckers: Remote SMTP server [127.0.0 .1:25]
connected .
May 4 17:07:57 DR1 Keepalived_healthcheckers:SMTP alert auccessfully sent .
从日志可知，Keepajived监控模块检测到192.168.12.132这台主机恢复正常后，又将此节点加入到集群系统中。
此时再次访问http://192.168.12.200这个地址，然后不断刷新此页面，应该又能分别看到“This is real serverl”和“This is real server2”页面了，这说明在real server l节点恢复正常后，Keepalived监控模块将此节点加入到集群系统中。
11.7本章小结
这一章详细讲述了通过LVS+heartbeat+Ldirectord、LVS+Keepalived及piranha三种方式来配置高可用LVS集群系统的过程。这三种方式各有优缺点，读者可以根据自己的需要选择最适合自己的方式。
下面是对这三种方式的总结：
□LVS+heartbeat+Ldirectord方式：
优点：安装简单，并且无需单独为ipvsadm编写脚本。同时，Ldirectord支持端口和
页面方式进行服务节点监控，配置灵活，可以根据需要进行选择。
缺点：配置比较复杂，需要对heartbeat和Ldirectord分别进行配置。
□LVS+Keepalived方式
优点：安装简单、配置简单，仅需要一个配置文件即可完成所有配量，同时无需单独
为ipvsadm编写脚本。Keepalived对后端服务节点的检测是基于底层网络通信协议的，
因此检测效率很高，故障切换速度最快。
□piranha方式
优点：安装简单，配置简单，只需一个Ivs.cf文件即可完成所有配置，也无需为
ipvsadm编写脚本。
缺点：在HA cluster双机切换过程中，没有主、备机之分，也就是说先启动的是主机，
最后启动的是备用机，并且没有类似heartbet中的auto- failback功能。
cat /proc/devices
Character devices:
1 mem
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
14 sound
21 sg
29 fb
99 ppdev
116 alsa
128 ptm
136 pts
162 raw
180 usb
189 usb_device
202 cpu/msr
203 cpu/cpuid
249 hidraw
250 usbmon
251 bsg
252 pcmcia
253 watchdog
254 rtc
Block devices:
1 ramdisk
259 blkext
7 loop
8 sd
9 md
11 sr
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
253 device-mapper
254 mdp
[root@steven ~]# cat /proc/misc
57 autofs
184 microcode
58 device-mapper
59 network_throughput
60 network_latency
61 cpu_dma_latency
62 crash
175 agpgart
144 nvram
228 hpet
231 snapshot
227 mcelog
63 vga_arbiter
负载均衡的发展历程
http://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=403078442&idx=2&sn=bd31fddfccafde520a2fb0060e9b6522&scene=0#wechat_redirect
1996 F5成立
1998 LVS项目成立
2000 HAProxy项目成立
2004 NGINX推出公共版本
2004 F5推出TMOS平台
2007 F5开始提供应用交付（ADC）产品
负载平衡､SSL卸载、压缩优化、TCP连接优化
（一）LVS的痛点
LVS最常用的有NAT、DR以及新的FULL NAT模式。上图比较了几种常见转发模式的优缺点。
我们认为LVS的每种模式都有其优点和缺点，但最大的问题是其复杂性。相信很多朋友看到这三种方式的优缺点、还有F5的单臂模式、双臂模式都会有云里雾里的感觉。
（二）LVS集群的痛点
雪上加霜的是咱们还需要考虑LVS的性能扩展和容灾方法，这使得整个方案更加的复杂。常见的有基于Keepalived的主备方式和ECMP两种。
Keepalived
主备模式设备利用率低；不能横向扩展；VRRP协议，有脑裂的风险。而ECMP的方式需要了解动态路由协议，LVS和交换机均需要较复杂配置；交换机的
HASH算法一般比较简单，增加删除节点会造成HASH重分布，可能导致当前TCP连接全部中断；部分交换机的ECMP在处理分片包时会有BUG。
基于DR转发方式
LVS
支持四种转发模式：NAT、DR、TUNNEL和FULLNAT(FULLNAT最近新加入的模式
还为合并到内核主线)，其实各有利弊。Vortex在设计之初就对四种模式做了评估，最后发现在虚拟化的环境下DR方式在各方面比较平衡，并且符合我们追
求极致性能的理念。
DR方式最大的优点是绝佳的性能，只有request需要负载均衡器处理，response可以直接从后端服务器返回客户机，不论是吞吐还是延时都是最好的分发方式。
其次，DR方式不像NAT模式需要复杂的路由设置，而且不像NAT模式当client和后端服务器处于同一个子网就无法正常工作。DR的这个特性使他特别合适作为内网负载均衡。
此外，不像FULLNAT一样需要先修改源IP再使用 TOA 传递源地址，还得在负载均衡器和后端服务器上都编译非主线的Kernel Module，DR可以KISS（Keep It Simple, Stupid）地将源地址传递给后端服务器。
最
后，虚拟化环境中已经采用Overlay虚拟网络了，所以TUNNEL的方式变得完全多余。而DR方式最大的缺点：需要LB和后端服务器在同一个二层网
络，而这在UCloud的虚拟化网络中完全不是问题。主流的SDN方案追求的正是大二层带来的无缝迁移体验，且早已采用各种优化手段（例如ARP代理）来
优化大二层虚拟网络。