LVS
基础概念
Cluster概念
系统扩展方式：
Scale UP：向上扩展,增强（硬件性能的提高）
Scale Out：向外扩展,增加设备，调度分配问题，Cluster
Cluster：集群,为解决某个特定问题将多台计算机组合起来形成的单个系统
Linux Cluster类型：
LB：Load Balancing，负载均衡
HA：High Availiablity，高可用，SPOF（single Point Of failure）
MTBF:Mean Time Between Failure 平均无故障时间
MTTR:Mean Time To Restoration（ repair）平均恢复前时间
A=MTBF/（MTBF+MTTR）
(0,1)：99%, 99.5%, 99.9%, 99.99%, 99.999%, 99.9999%
HPC：High-performance computing，高性能 www.top500.org
分布式系统：
分布式存储：云盘 分
布式计算：hadoop，Spark
Cluster分类
LB Cluster的实现
硬件
F5 Big-IP
Citrix Netscaler
A10 A10
软件
lvs：Linux Virtual Server
nginx：支持四层调度
haproxy：支持四层调度
ats：apache traffic server，yahoo捐助
perlbal：Perl 编写
pound
基于工作的协议层次划分：
传输层（通用）：DPORT
LVS：
nginx：stream
haproxy：mode tcp
应用层（专用）：针对特定协议，自定义的请求模型分类
proxy server：
http：nginx, httpd, haproxy(mode http), ...
fastcgi：nginx, httpd, ...
mysql：mysql-proxy, ...
Cluster相关
会话保持：负载均衡
(1) session sticky：同一用户调度固定服务器 Source IP：LVS sh算法（对某一特定服务而言） Cookie
(2) session replication：每台服务器拥有全部session session multicast cluster
(3) session server：专门的session服务器 Memcached，Redis
HA集群实现方案
keepalived:vrrp协议
ais:应用接口规范
heartbeat
cman+rgmanager(RHCS)
coresync_pacemaker
LVS介绍
LVS：Linux Virtual Server字面意思是linux虚拟服务器理解为负载调度器，集成早内核中,开发者是中国人章文嵩目前在阿里任职。
官网：http://www.linuxvirtualserver.org/
VS: Virtual Server，负责调度
RS: Real Server，负责真正提供服务
L4：四层路由器或交换机
工作原理：VS根据请求报文的目标IP和目标协议及端口将其调度转发至某RS，根据调度算法来挑选RS
iptables/netfilter：
iptables：用户空间的管理工具
netfilter：内核空间上的框架
流入：PREROUTING --> INPUT
流出：OUTPUT --> POSTROUTING
转发：PREROUTING --> FORWARD --> POSTROUTING
DNAT：目标地址转换； PREROUTING
LVS概念
lvs集群类型中的术语：
VS：Virtual Server, Director, Dispatcher(调度器) Load Balancer
RS：Real Server(lvs), upstream server(nginx) backend server(haproxy)
CIP：Client IP 客户端IP地址
VIP: Virtual serve IP VS外网的IP
DIP: Director IP VS内网的IP
RIP: Real server IP 服务端IP地址
访问流程：CIP <--> VIP == DIP <--> RIP
LVS集群的类型
lvs: ipvsadm/ipvs
ipvsadm：用户空间的命令行工具，规则管理器
用于管理集群服务及RealServer
ipvs：工作于内核空间netfilter的INPUT钩子上的框架
lvs集群的类型：
lvs-nat：修改请求报文的目标IP,多目标IP的DNAT
lvs-dr（直接路由）：操纵封装新的MAC地址
lvs-tun（隧道模型）：在原请求IP报文之外新加一个IP首部
lvs-fullnat：修改请求报文的源和目标IP
lvs-nat模式
本质是多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和PORT实现转发
（1）RIP和DIP一般在同一个IP网络，且应该使用私网地址； RS的网关要指向DIP
（2）请求报文和响应报文都必须经由Director转发，Director 易于成为系统瓶颈
（3）支持端口映射，可修改请求报文的目标PORT
（4）VS必须是Linux系统，RS可以是任意OS系统
LVS做为负载均衡集群的调度器，需要配置两个IP地址，一个公网IP负责与网络中的客户端通讯，一个私网IP负责连接集群内部在服务器RS。集群内部的RS一般使用私网IP且与调度器的私网IP在同一网段，所以要求RS的网关要指向调度器的私网地址，中间由交换机连接。理论情况下，RS与调度器的IP地址可以在不同网段，如果RS与调度器不再同一网段那么就要求中间有路由器连接，路由器的效率远远不及交换机好，很可能再次成为集群的工作瓶颈。
正如上图所示，客户端访问RS服务的请求会发往LVS主机，此时，客户端请求报文的源IP为CIP，目标IP为LVS的VIP，当LVS收到客户端的请求报文时，会将请求报文中的目标IP修改为后端某 个RealServer的RIP，就以上图为例，当LVS收到客户端的请求报文时，会将报文中的VIP修改为RIP1或者RIP2，具体将VIP修改为哪个RealServer的RIP，取决于LVS使用的具体算 法，以轮询算法为例，轮询算法就是如果这次将报文的目标IP修改为RIP1，那么下次就将目标IP修改为RIP2，再下次就再将目标IP修改为RI P1，以此类推，当客户端请求报文的目标IP被修改为对应的RIP后，请求报文的源IP 为CIP，目标IP已经改为RIP，那么报文自然会被LVS转发到对应的RealServer中，当RealServer收到对应的请求报文时，会发现报文的目标IP就是自己的RIP，于是就会接收报文， 处理后进行响应，因为RealServer收到请求报文时，源IP为CIP，目标IP为RIP，所以RealServer在进行响应时，响应报文的源IP则为RIP，目标IP则为CIP，但是CIP对于RealServe r来说肯定不在一个网络内，因为CIP是一个公网IP，所以，我们要将所有RealServer的网关指向DIP，当RealServer产生响应报文时，会将响应报文发往网关DIP，而DIP就是LVS 的内网IP，当LVS收到对应的响应报文时，响应报文的源IP为RIP，目标IP为CIP，此时，LVS会将响应报文的源IP修改为VIP，修改后的响应报文的源IP为VIP，目标IP为CIP，于是响应报文被发往客户端，客户端则会收到响应报文，其实上述整个过程是一个DNAT的过程，所以，此种LVS模型被称之为LVS-NAT模型。
上述过程中，因为客户端在访问RS提供的服务时发出的请求报文的目标IP为LVS主机的VIP（外网IP），因此RS的响应报文要由中间的LVS服务器再次代替转发，将相应报文的源地址转换为VS的VIP才能使客户端顺利的接受相应报文。也就是说，RS的响应报文要与客户端发出的请求报文走同一条路线。事实上客户端的请求报文是比较轻量级的，不带有实体部分或者实体部分很小，都是一些请求信息。而RS的响应报文一般是重量级的报文，LVS服务器处理客户端的请求报文时压力比较小，但是处理RS重量级的响应报文时压力就会比较大。LVS-NAT模型因为原理的束缚处理不了大规模的集群服务，更适合小规模的服务集群。而LVS-DR模型能实现RS的相应报文不再原路返回给VS。
地址转换流程：
| 源地址 | 目标地址 | |
|---|---|---|
| 客户端请求 | CIP | VIP |
| 经VS转换 | CIP | RIP |
| 响应阶段 | ||
| RS相应报文 | RIP | CIP |
| 经VS转换 | VIP | CIP |
| 客户端收到 | VIP | CIP |
lvs-DR模式
LVS-DR：Direct Routing，直接路由，LVS默认模式,应用最广泛 ,通过为请求报文重新封装一个MAC首部进行转发，源MAC是DIP 所在的接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的 MAC地址；源IP/PORT，以及目标IP/PORT均保持不变。
LVS-DR模型与LVS-BAT模型的区别在于，LVS-DR模型中RS的相应报文不再经由VS的转发而是直接通过其他网络路径发送给客户端。大大减轻了VS的工作负担。但是要实现RS与客户端的之间的通讯的前提条件是请求报文与相应报文中的IP地址必须匹配，也就是说，客户端发送的请求报文中的目标IP地址要与RS发送的相应报文的源IP地址相同。LVS-NST模型中，所有的RS都绑定与VS相同的VIP（外网IP），这是实现RS与客户端通讯的前提，但是又会造成另一个问题，当客户端发送请求报文到VS时，VS要通过算法选择一台合适的RS去响应客户端的请求。然而这个时候后端的所有RS的IP地址都为VIP。为了解决这一问题，在LVS-DR模型中，需要把RS与VS放在同一物理网路中。并在VS中静态绑定每个RS的MAC地址。ARP广播的前提条件是不知道目标主机的MAC时才会通过IP地址发送ARP广播寻址。当VS中静态绑定每一台RS的MAC时就能通过MAC顺利的找到目标主机。
(1) 确保前端路由器将目标IP为VIP的请求报文发往Director ：LVS-DR模型中后端的每一台都绑定的有VIP，当请求报文发送到VS与RS所在的网络中时，为了避免报文不经过VS直接被RS接收，有以下三种手段：
- 在前端网关做静态绑定VIP和Director的MAC地址，这种方法可以实现客户端的请求报文到达前端的路由器时不同过ARP广播形式去寻址，而是通过静态的MAC表来直接与VS通讯。然而现实中前端的路由器不一定是企业内部的路由器
- 在RS上使用arptables工具
arptables -A IN -d $VIP -j DROP
arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP - 在RS上修改内核参数以限制arp通告及应答级别
arp_announce
arp_ignore
(2) RS的RIP可以使用私网地址，也可以是公网地址；RIP与 DIP在同一IP网络；RIP的网关不能指向DIP，以确保响应报文不会经由Director
(3) RS和Director要在同一个物理网络
(4) 请求报文要经由Director，但响应报文不经由Director，而由RS直接发往Client
(5) 不支持端口映射（端口不能修败）
(6) RS可使用大多数OS系统
LVS-DR模式IP包调度过程：
| 源地址 | 目标地址 | 源MAC | 目标MAC | |
|---|---|---|---|---|
| 客户端请求 | CIP | VIP | ||
| VS调度后 | CIP | VIP | RS-MAC | |
| RS收到 | CIP | VIP | ||
| RS相应包 | CIP | VIP | ||
LVS-TUN模式
转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为 VIP），而在原IP报文之外再封装一个IP首部（源IP是DIP，目 标IP是RIP），将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP是CIP）
(1) DIP, VIP, RIP都应该是公网地址
(2) RS的网关不能，也不可能指向DIP
(3) 请求报文要经由Director，但响应不能经由Director
(4) 不支持端口映射
(5) RS的OS须支持隧道功能
(6)LVS-TUN模式可以理解为VS将收到的客户端请求报文直接封装了一层IP信息。适合远程调用情景。
LVS-TUN模式IP包调度过程：
| 源地址 | 目标地址 | |
|---|---|---|
| 客户端请求 | CIP | VIP |
| VS转换 | DIP | RIP |
| RS接受 | DIP | RIP |
| RS响应 | VIP | CIP |
| 客户端接收 | VIP | CIP |
lvs-fullnat模式
lvs-fullnat：通过同时修改请求报文的源IP地址和目标IP地址进行转发 CIP --> DIP VIP --> RIP
(1) VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络；因此，RIP的网关一般不会指向DIP
(2) RS收到的请求报文源地址是DIP，因此，只需响应给DIP；但Director还要将其发往Client
(3) 请求和响应报文都经由Director
(4) 支持端口映射； 注意：此类型kernel默认不支持
lvs-fullnat模式IP包调度过程：
| 源地址 | 目标地址 | |
|---|---|---|
| 客户端请求 | CIP | VIP |
| VS转换 | DIP | RIP |
| RS接受 | DIP | RIP |
| RS响应 | VIP | CIP |
| 客户端接收 | VIP | CIP |
| lvs-fullnat模式IP包调度过程表面上看起来与lvs-tun模式比较类似，但是事实上是有区别的，而且工作特性也大不相同。在lvs-fullnat模式中，VS接受到客户端的请求报文时要通过算法调度出一台合适的RS去相应服务报文。VS在把客户端的请求报文转发给后端的RS之前会在请求报文外层直接封装一层IP信息，而报文原有的IP信息则作为数据被封装在报文内部。后端的RS支持隧道功能，解封装VS转发过来的请求报文以后识别报文内部原有的IP信息，实现RS的响应报文可以直接与客户端通讯而不再通过VS。但是在lvs-fullnat模式中，VS接收到客户端发来的请求报文以后，不再将原有的IP信息封装在报文内，而是做地址转化将原报文的源地址改为VS的DIP，目标地址改为RIP，RS收到的请求报文的源地址就是DIP，目标地址就是RIP所以后端的RS无法实现直接与客户端通讯。也就是说lvs-fullnat模式中RS发送的相应报文还是要在通过VS的转换之后才能到达客户端。lvs-fullnat模式实际意义并不大，而且内核默认情况下不支持该模式。 |
LVS工作模式总结
| VS/NAT | VS/TUN | VS/DR | |
|---|---|---|---|
| RS特性 | any | 支持隧道 | 忽略ARP |
| 网络 | PRIVATE | LAN/WAN | LAN |
| 负载 | 低 | 高 | 高 |
| 网关 | VS | own router | own router |
lvs-nat与lvs-fullnat：请求和响应报文都经由Director
lvs-nat：RIP的网关要指向DIP
lvs-fullnat：RIP和DIP未必在同一IP网络，但要能通信
lvs-dr与lvs-tun：请求报文要经由Director，但响应报文由RS直接 发往Client
lvs-dr：通过封装新的MAC首部实现，通过MAC网络转发
lvs-tun：通过在原IP报文外封装新IP头实现转发，支持远距离通信
ipvs scheduler
根据其调度时是否考虑各RS当前的负载状态
两种：静态方法和动态方法
静态方法：仅根据算法本身进行调度。
1、RR：roundrobin，轮询
2、WRR：Weighted RR，加权轮询
3、SH：Source Hashing，实现session sticky，源IP地址 hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定（现实生活中VS收到的请求报文中的IP地址应该是一个公网IP，然而有可能整个地区的客户端都使用这一个公网IP，对于VS来言这个公网IP对应的主机可能是数以万计甚至更多。所以这种调度方法意义不大。与源IP地址hash不同的是源cookie的hash，生活中每台主机都有自己的cookie，源cookie的hash可以有效区分不同主机。但是LVS只支持底层的四层调度，cookie则属于应用层范畴，LVS并不支持）
4、DH：Destination Hashing；目标地址哈希，将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡，如：宽带运营商
动态方法：主要根据每RS当前的负载状态及调度算法进行调度 Overhead=value 较小的RS将被调度
1、LC：least connections（最小连接数） 适用于长连接应用 Overhead=activeconns（活动连接）*256+inactiveconns（非活动连接）
2、WLC：Weighted LC，默认调度方法 Overhead=(activeconns*256+inactiveconns)/weight
3、SED：Shortest Expection Delay,初始连接高权重优先 Overhead=(activeconns+1)*256/weight
4、NQ：Never Queue，第一轮均匀分配，后续SED
5、LBLC：Locality-Based LC，动态的DH算法，使用场景： 根据负载状态实现正向代理
6、LBLCR：LBLC with Replication，带复制功能的LBLC 解决LBLC负载不均衡问题，从负载重的复制到负载轻的RS
[root@Centos6 ~]#grep -i -C 20 ipvs /boot/config-2.6.32-696.el6.x86_64
# IPVS scheduler
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#内核支持的调度算法模块
ipvs
ipvsadm/ipvs：ipvs工作在内核级别，ipvsadm则作为一个工具在用户空间让用户去管理ipvs
ipvs：
grep -i -C 10 "ipvs" /boot/config-VERSIONRELEASE.x86_64
支持的协议：TCP， UDP， AH， ESP， AH_ESP, SCTP
ipvs集群：
管理集群服务
管理服务上的RS
ipvsadm
ipvsadm包构成
程序包：ipvsadm
Unit File: ipvsadm.service
主程序：/usr/sbin/ipvsadm
规则保存工具：/usr/sbin/ipvsadm-save
规则重载工具：/usr/sbin/ipvsadm-restore
配置文件：/etc/sysconfig/ipvsadm-config
ipvsadm命令
核心功能：
集群服务管理：增、删、改
集群服务的RS管理：增、删、改
查看
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [--pe persistence_engine] [-b sched-flags]
ipvsadm -D -t|u|f service-address 删除服务地址
ipvsadm –C 清空
ipvsadm –R 重载
ipvsadm -S [-n] 保存
ipvsadm -a|e -t|u|f service-address -r server-address [options]
ipvsadm -d -t|u|f service-address -r server-address
ipvsadm -L|l [options]
ipvsadm -Z [-t|u|f service-address]清空计数器
管理集群服务VS：增、改、删
增、改：
ipvsadm -A|E -t|u|f service-address \[-s scheduler] [-p [timeout]]
-A:增加调度器地址
-E：修改调度器地址
-t|u|f：
-t: TCP协议的端口，VIP:TCP_PORT
-u: udp协议的端口，VIP:UDP_PORT
-f：firewall MARK，标记，一个数字
[-s scheduler]：指定集群的调度算法，默认为wlc
删除：
ipvsadm -D -t|u|f service-address
管理集群上的RS：增、改、删
增、改：
ipvsadm -a|e -t|u|f service-address -r server-address \[-g|i|m] [-w weight]
#service-address VS地址（vip）
#server-address RS地址（RIP）
#-a 添加RS
#-e 修改RS属性，修改时容易出现BUG，清除全部策略以后重新配置
删：
ipvsadm -d -t|u|f service-address -r serveraddress
server-address：
rip[:port] 如省略port，不作端口映射
选项：
lvs类型：
-g: gateway, dr类型，默认
-i: ipip, tun类型
-m: masquerade, nat类型
-w weight：权重
清空定义的所有内容：ipvsadm –C
清空计数器：ipvsadm -Z [-t|u|f service-address]
查看：ipvsadm -L|l [options]
--numeric, -n：以数字形式输出地址和端口号
--exact：扩展信息，精确值
--connection，-c：当前IPVS连接输出
--stats：统计信息
--rate ：输出速率信息
ipvs规则： /proc/net/ip_vs
ipvs连接：/proc/net/ip_vs_conn
保存及重载规则
保存：建议保存至/etc/sysconfig/ipvsadm
ipvsadm-save > /PATH/TO/IPVSADM_FILE
ipvsadm -S > /PATH/TO/IPVSADM_FILE
systemctl stop ipvsadm.service
重载： ipvsadm-restore < /PATH/FROM/IPVSADM_FILE
ipvsadm -R < /PATH/FROM/IPVSADM_FILE
systemctl restart ipvsadm.service
实验
LVS-NAT实现
(1)实验目的：通过四台虚拟机，实现lvs-nat负载均衡模型简单搭建
(2)实验准备：
硬件：
四台虚拟机，一台作为VS，两台RS，一台client
软件：
关闭所有虚拟机的防火墙设置和selinux设置
在VS安装ipvsadm工具，并开启路由转发功能
在RS部署http服务，并将网关设置为DIP
(3)实验拓扑
(4)实验步骤：
- 关闭所有虚拟机的防火墙服务，清空防火墙策略，禁用selinux
[root@client ~]#service iptables stop
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
[root@client ~]#getenforce
Disabled
- 在两台RS上部署http服务
[RS1 ]#echo "This is RS1 webpage" > /var/www/html/index.html
[RS2 ]#echo "This is RS2 webpage" > /var/www/html/index.html
#查看80端口是否开启
#测试能否访问index页面
- 开启VS的路由转发功能，配置RS网关，并测试
[root@ VS]#echo 1 > /proc/sys/net/ipv4/ip_forward
#开启VS路由转发功能，该设置为临时设置，也可以写入配置文件中：
#在/etc/sysctl.conf文件中加入一行：net.ipv4.ip_forward=1
[RS1 ]#route add default gw 192.168.45.33
[RS2 ]#route add default gw 192.168.45.33
#将两台RS的默认网关都指向VS的DIP
[RS1 ]#route -n
Kernel IP routing table
Destination Gateway Genmask FG Metric Ref Use Iface
0.0.0.0 192.168.45.33 0.0.0.0 UG 0 0 0 eth0
[RS2 ]#route -n
Kernel IP routing table
Destination Gateway Genmask FG Metric Ref Use Iface
0.0.0.0 192.168.45.33 0.0.0.0 UG 0 0 0 eth0
实际生活中客户端的默认网关应该指向自己的路由器，本次实现简化为客户端的路由直接指向VS的外网地址VIP
[root@client ~]#curl 192.168.45.11
This is RS1 webpage
[root@client ~]#curl 192.168.45.12
This is RS2 webpage
#以上配置完成以后，客户端直接通过RS的DIP就可以访问RS上的httpd服务
- 在VS上配置集群策略
[root@ VS]#ipvsadm -A -t 172.18.45.7:80 -s rr
#-A:添加集群服务
#-t：指定TCP协议
#172.18.45.7:80 VS的IP地址和端口号
#-s rr：指定调度算法，这里以最简单的轮询为例，默认为WLC权重轮询
[root@ VS]#ipvsadm -a -t 172.18.45.7:80 -r 192.168.45.11:80 -m
#-a：添加集群服务的RS
#-t：指定TCP协议
#172.18.45.7:80 VS的IP地址与端口号
#-r 192.168.45.11:80 指定RS的IP地址端口号
#-m：指定LVS模型m为nat类型
[root@ VS]#ipvsadm -a -t 172.18.45.7:80 -r 192.168.45.12:80 -m
[root@ VS]#ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.18.45.7:80 rr
-> 192.168.45.11:80 Masq 1 0 0
-> 192.168.45.12:80 Masq 1 0 0
- 在客户端测试
[root@client ~]#curl 172.18.45.7
This is RS2 webpage
[root@client ~]#curl 172.18.45.7
This is RS1 webpage
[root@client ~]#curl 172.18.45.7
This is RS2 webpage
[root@client ~]#curl 172.18.45.7
This is RS1 webpage
lvs设计要点
负载均衡集群设计时要注意的问题
(1) 是否需要会话保持
(2) 是否需要共享存储
共享存储：NAS， SAN， DS（分布式存储）
数据同步：
LVS-NAT
(1) RIP与DIP在同一IP网络, RIP的网关要指向DIP
(2) 支持端口映射
(3) Director要打开核心转发功能
LVS-DR
lvs-dr：
dr模型中，各主机上均需要配置VIP，解决地址冲突的方式有三种：
(1) 在前端网关做静态绑定
(2) 在各RS使用arptables
(3) 在各RS修改内核参数，来限制arp响应和通告的级别
限制响应级别：arp_ignore 0：默认值，表示可使用本地任意接口上配置的任意地址进行响应
1: 仅在请求的目标IP配置在本地主机的接收到请求报文的接口上时 ，才给予响应
限制通告级别：arp_announce 0：默认值，把本机所有接口的所有信息向每个接口的网络进行通告
1：尽量避免将接口信息向非直接连接网络进行通告
2：必须避免将接口信息向非本网络进行通告
FireWall Mark
FWM：FireWall Mark
MARK target 可用于给特定的报文打标记
--set-mark value
其中：value 为十六进制数字
借助于防火墙标记来分类报文，而后基于标记定义集群服务 ；可将多个不同的应用使用同一个集群服务进行调度
实现方法：
在Director主机打标记：
iptables -t mangle -A PREROUTING -d $vip -p $proto –m multiport --dports $port1,$port2,… -j MARK --set-mark NUMBER
在Director主机基于标记定义集群服务：
ipvsadm -A -f NUMBER [options]
持久连接
session 绑定：对共享同一组RS的多个集群服务，需要统一进行绑 定，lvs sh算法无法实现
持久连接（ lvs persistence ）模板：实现无论使用任何调度算法 ，在一段时间内（默认360s ），能够实现将来自同一个地址的请求 始终发往同一个RS
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]
持久连接实现方式：
每端口持久（PPC）：每个端口对应定义为一个集群服务，每集群服务单独调度
每防火墙标记持久（PFWMC）:
基于防火墙标记定义集群服务； 可实现将多个端口上的应用统一调度，即所谓的port Affinity
每客户端持久（PCC）:
基于0端口（表示所有服务）定义集群服 务，即将客户端对所有应用的请求都调度至后端主机，必须定义 为持久模式
LVS高可用性
1 Director不可用，整个系统将不可用；SPoF Single Point of Failure
解决方案：
高可用 keepalived heartbeat/corosync
2 某RS不可用时，Director依然会调度请求至此RS 解决方案：
由Director对各RS健康状态进行检查，失败时禁 用，成功时启用 keepalived heartbeat/corosync, ldirectord
检测方式：
(a) 网络层检测，icmp
(b) 传输层检测，端口探测
(c) 应用层检测，请求某关键资源
RS全不用时：back server, sorry server
ldirectord
ldirectord：监控和控制LVS守护进程，可管理LVS规则
包名：ldirectord-3.9.6-0rc1.1.1.x86_64.rpm
文件：
/etc/ha.d/ldirectord.cf 主配置文件
/usr/share/doc/ldirectord-3.9.6/ldirectord.cf 配置模版
/usr/lib/systemd/system/ldirectord.service 服务
/usr/sbin/ldirectord 主程序
/var/log/ldirectord.log 日志
/var/run/ldirectord.ldirectord.pid pid文件
Ldirectord配置文件示例
checktimeout=3
checkinterval=1
autoreload=yes
logfile=“/var/log/ldirectord.log“ #日志文件
quiescent=no #down时yes权重为0，no为删除
virtual=5 #指定VS的FWM或IP：port
real=172.16.0.7:80 gate 2
real=172.16.0.8:80 gate 1
fallback=127.0.0.1:80 gate #sorry server
service=http
scheduler=wrr
checktype=negotiate
checkport=80
reques="index.html" #测试页面
receive=“Test Ldirectord" #出现这个语句就返回错误
