Linux Virtual Server(LVS)

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了Linux Virtual Server(LVS)，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含17013字，纯文字阅读大概需要25分钟。

内容图文

Linux Virtual Server(LVS)

时间: 20181115

个人小站: www.winthcloud.top

目录

为何要使用LVS?

Cluster基本概念

LB Cluster的实现方式(Load Balancing)

会话保持负载均衡(session sticky,session replication, session server)

HA集群实现方案

LVS介绍

lvs集群类型中的术语(VIP,DIP,RIP,CIP)

lvs集群的类型(lvs-nat,lvs-DR,lvs-tunnel,lvs-fullnat)

lvs: ipvsadm/ipvs

ipvs scheduler(RR,WRR,SH,DH,LC,WLC,SED,NQ,LBLC,LBLCR)

ipvs模块(要想使用lvs需要查看内核是否支持)

ipvsadm包构成

ipvsadm命令

ipvs规则保存和重载

lvs工作模式需要注意的地方和其配置实现

FireWall Mark(基于iptables将某些端口打标使用lvs来进行基于打标的标识转发)

持久连接

ldirectord

总结

为何要使用LVS?

单台服务器如web服务，一台服务器所响应用户的web请求终归有其最大上限，当单台机器即使

加高其配置，也难以解决用户请求其web页面的量太大。 在此时便出现了另外一种想法，即将

一台web服务器变成多台web服务器，由多台web服务器来响应用户的web请求，此时便解决了单

台服务器响应其请求上限的问题，但是如何将这多台web服务器响应web请求的能力合并起来

变成一台服务器呢？因为每个web服务器的ip地址不同一般dns解析域名对应的是一个web IP，

这个又要如何实现？如果你公司只有一个外网IP的情况下如何将这一堆web服务器的响应请求

能力合并起来？  这便出现了如lvs这样的工具，它可以实现将多台服务器的响应能力合并成一

个。当然这里只是粗略的解释一下lvs的作用，当然lvs只是这实现这种架构的其中一种方式，

还有其它的像haproxy, nginx等。  下边便是其具体的实现方式的步骤和概念

Cluster概念

系统扩展方式(当一台服务器满足不了业务需求时，为满足其业务需求系统服务的扩展方式)

Scale UP：向上扩展,增强单台机器的性能如cpu, memory,等

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%

HPC：High-performance computing，高性能 www.top500.org

分布式系统：

分布式存储：云盘

分布式计算：hadoop，Spark

LB Cluster的实现方式(Load Balancing)

硬件

F5 Big-IP

Citrix Netscaler

A10 A10

软件

lvs：Linux Virtual Server 4层调度 即只能将指定某个端口的流量导向某个后端

nginx：支持七层调度  可以实现访问web某些资源时导向某个后端

haproxy：支持七层调度

ats：apache traffic server，yahoo捐助

perlbal：Perl 编写

pound

4层和7层调度的区别就是其维度更细化，精准，当然越细所耗费的时间越长

基于工作的协议层次划分：

传输层（通用）：DPORT

LVS：

nginx：stream

haproxy：mode tcp

应用层（专用）：针对特定协议，自定义的请求模型分类

proxy server：

http：nginx, httpd, haproxy(mode http), ...

fastcgi：nginx, httpd, ...

mysql：mysql-proxy, ...

会话保持负载均衡

如果每个调度都导向一个新的服务器时，其用户所登录的信息等都会消失，因为保存的信息

没有在新的服务器上，这便是lvs需要解决的问题

(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，负载调度器，集成内核 章文嵩 阿里

官网：http://www.linuxvirtualserver.org/

VS: Virtual Server，负责调度

RS: Real Server，负责真正提供服务

L4：四层路由器或交换机

工作原理：VS根据请求报文的目标IP和目标协议及端口将其调度转发至某RS，

根据调度算法来挑选RS

lvs集群类型中的术语：

VS：Virtual Server，Director Server(DS)

Dispatcher(调度器)，Load Balancer

RS：Real Server(lvs), upstream server(nginx) backend server(haproxy)

CIP：Client IP

VIP: Virtual serve IP VS外网的IP

DIP: Director IP VS内网的IP

RIP: Real server IP

访问流程：CIP <--> VIP == DIP <--> RIP

lvs集群的类型

lvs-nat：修改请求报文的目标IP,多目标IP的DNAT

lvs-dr：操纵封装新的MAC地址

lvs-tun：在原请求IP报文之外新加一个IP首部

lvs-fullnat：修改请求报文的源和目标IP

lvs: ipvsadm/ipvs

ipvsadm：用户空间的命令行工具，规则管理器

用于管理集群服务及RealServer

ipvs：工作于内核空间netfilter的INPUT钩子上的框架

lvs-nat模式

本质是多目标IP的DNAT，通过某个调度算法将请求报文中的目标地址和目标端口修改为

某个挑出的RS的RIP和PORT实现转发

（1）RIP和DIP应在同一个IP网络，且应使用私网地址；RS的网关要指向DIP

（2）请求报文和响应报文都必须经由Director转发，Director易成为系统瓶颈

（3）支持端口映射，可修改请求报文的目标PORT

（4）LVS必须是Linux系统，RS可以是任意OS系统

LVS-DR模式

LVS-DR：Direct Routing，直接路由，LVS默认模式,应用最广泛,通过为请求报文重新

封装一个MAC首部进行转发，源MAC是DIP所在的接口的MAC，目标MAC是某挑选出的RS的

RIP所在接口的MAC地址; 源IP/PORT，以及目标IP/PORT均保持不变

（1） Director和各RS都配置有VIP

（2） 确保前端路由器将目标IP为VIP的请求报文发往Director

在前端网关做静态绑定VIP和Director的MAC地址

在RS上使用arptables工具

arptables -A IN -d $VIP -j DROP

arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP

在RS上修改内核参数以限制arp通告及应答级别

/proc/sys/net/ipv4/conf/all/arp_ignore

/proc/sys/net/ipv4/conf/all/arp_announce

（3）RS的RIP可以使用私网地址，也可以是公网地址；RIP与DIP必须在同一IP网络；

RIP的网关不能指向DIP，以确保响应报文不会经由Director

（4）RS和Director要在同一个物理网络

（5）请求报文要经由Director，但响应报文不经由Director，而由RS直接发往Client

（6）不支持端口映射（端口不能修败）因为请求报文没有变动只是由DR做了转发

（7）RS可使用大多数OS系统

arp_announce - INTEGER

Define different restriction levels for announcing the local

source IP address from IP packets in ARP requests sent on

interface:

0 - (default) Use any local address, configured on any interface

1 - Try to avoid local addresses that are not in the target's

subnet for this interface. This mode is useful when target

hosts reachable via this interface require the source IP

address in ARP requests to be part of their logical network

configured on the receiving interface. When we generate the

request we will check all our subnets that include the

target IP and will preserve the source address if it is from

such subnet. If there is no such subnet we select source

address according to the rules for level 2.

2 - Always use the best local address for this target.

In this mode we ignore the source address in the IP packet

and try to select local address that we prefer for talks with

the target host. Such local address is selected by looking

for primary IP addresses on all our subnets on the outgoing

interface that include the target IP address. If no suitable

local address is found we select the first local address

we have on the outgoing interface or on all other interfaces,

with the hope we will receive reply for our request and

even sometimes no matter the source IP address we announce.

The max value from conf/{all,interface}/arp_announce is used.

Increasing the restriction level gives more chance for

receiving answer from the resolved target while decreasing

the level announces more valid sender's information.

arp_ignore - INTEGER

Define different modes for sending replies in response to

received ARP requests that resolve local target IP addresses:

0 - (default): reply for any local target IP address, configured

on any interface

1 - reply only if the target IP address is local address

configured on the incoming interface

2 - reply only if the target IP address is local address

configured on the incoming interface and both with the

sender's IP address are part from same subnet on this interface

3 - do not reply for local addresses configured with scope host,

only resolutions for global and link addresses are replied

4-7 - reserved

8 - do not reply for all local addresses

The max value from conf/{all,interface}/arp_ignore is used

when ARP request is received on the {interface}

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须支持隧道功能

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默认不支持

ipvs scheduler

ipvs scheduler：根据其调度时是否考虑各RS当前的负载状态

两种：静态方法和动态方法

静态方法：仅根据算法本身进行调度

1、RR：roundrobin，轮询

2、WRR：Weighted RR，加权轮询

3、SH：Source Hashing，实现session sticky，源IP地址hash；将来自

于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定

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

ipvs模块(要想使用lvs需要查看内核是否支持)

ipvsadm/ipvs：

ipvs：

grep -i -C 10 "ipvs" /boot/config-VERSION-RELEASE.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]

管理集群服务：增、改、删

增、改：

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]

删除：

ipvsadm -D -t|u|f service-address

service-address：

-t|u|f：

-t: TCP协议的端口，VIP:TCP_PORT

-u: UDP协议的端口，VIP:UDP_PORT

-f：firewall MARK，标记，一个数字

[-s scheduler]：指定集群的调度算法，默认为wlc

管理集群上的RS：增、改、删

增、改：ipvsadm -a|e -t|u|f service-address -r server-address 

[-g|i|m] [-w weight]

删：ipvsadm -d -t|u|f service-address -r server-address

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工作模式需要注意的地方和其配置实现

负载均衡集群设计时要注意的问题

(1) 是否需要会话保持

(2) 是否需要共享存储

共享存储：NAS， SAN， DS（分布式存储）

数据同步：

lvs-nat：

设计要点：

(1) RIP与DIP在同一IP网络, RIP的网关要指向DIP

(2) 支持端口映射

(3) Director要打开核心转发功能

LVS-DR

DR模型中各主机上均需要配置VIP，解决地址冲突的方式有三种：

(1) 在前端网关做静态绑定

(2) 在各RS使用arptables

(3) 在各RS修改内核参数，来限制arp响应和通告的级别

限制响应级别：arp_ignore

0：默认值，表示可使用本地任意接口上配置的任意地址进行响应

1: 仅在请求的目标IP配置在本地主机的接收到请求报文的接口上时，才给予响应

限制通告级别：arp_announce

0：默认值，把本机所有接口的所有信息向每个接口的网络进行通告

1：尽量避免将接口信息向非直接连接网络进行通告

2：必须避免将接口信息向非本网络进行通告

RS的配置脚本 (注意这里只是临时配置生效哦，要想永久还是需要保存到配置文件)

#!/bin/bash

vip=10.0.0.100

mask='255.255.255.255‘

dev=lo:1

case $1 in

start)

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

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

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

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

ifconfig $dev $vip netmask $mask #broadcast $vip up

#route add -host $vip dev $dev

;;

stop)

ifconfig $dev down

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

echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore

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

echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce

;;

*)

echo "Usage: $(basename $0) start|stop"

exit 1

;;

esac

VS的配置脚本(注意这里只是临时配置生效哦，要想永久还是需要保存到配置文件)

#!/bin/bash

vip='10.0.0.100'

iface='eth0:1'

mask='255.255.255.255'

port='80'

rs1='192.168.0.101'

rs2='192.168.0.102'

scheduler='wrr'

type='-g'

case $1 in

start)

ifconfig $iface $vip netmask $mask #broadcast $vip up

iptables -F

ipvsadm -A -t ${vip}:${port} -s $scheduler

ipvsadm -a -t ${vip}:${port} -r ${rs1} $type -w 1

ipvsadm -a -t ${vip}:${port} -r ${rs2} $type -w 1

;;

stop)

ipvsadm -C

ifconfig $iface down

;;

*)

echo "Usage $(basename $0) start|stop“

exit 1

esac

FireWall Mark

FWM：FireWall Mark

MARK target 可用于给特定的报文打标记

--set-mark value

其中：value 可为0xffff格式，表示十六进制数字

借助于防火墙标记来分类报文，而后基于标记定义集群服务；可将多个不同的应用

使用同一个集群服务进行调度

实现方法：

在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全不用时：backup server, sorry server

ldirectord

本来后端服务的监控需要自己写脚本实现，但这款软件可以实现监控后端RS是否工作正常，并

根据其状态来修改lvs规则

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

request="index.html"

receive=“Test Ldirectord"

总结:

dr模型的问题

dr模型里为何Director知道访问VIP时发送至后端所指定的RS?

答:这就是lvs的转发机制通过广播获得后端RS的mac地址，并将请求VIP的数据包,修改其目的

mac地址实现向后端RS发送数据包

dr模型RS为何会在接收Director所发送的请求包，在构建响应报文时为何用自己的VIP来做源

地址封装？

答:因为RS在拆封装ip头部信息时，查看到是去VIP的数据包，自己的主机上也配置此VIP地址

所以会接收其数据包，第二个是因为RS所接收到的请求数据包的目的地址是VIP所以发送响应

报文时也得或说是必须是使用VIP来做源地址

dr模型RS封装响应报文时使用vip做ip地址，mac使用谁的？如果是自己的出接口，这样发

送到路由器那里为何路由器不会进行地址学习 mac与ip地址的对应关系？

答:学习mac地址和IP之间的对应关系是通过专用的arp广播来实现的这里是传输数据而并非广播

所以不会学习其源地址和ip之间对应关系，只有通过广播后收到arp回应包才会学习其ip和mac

地址对应关系，因为RS已经将广播包和免费arp都禁用在其指定接口下所以不会向外广播其所拥

有的vip地址的广播包，只有lvs会回应此广播包所以路由器只会学习到lvs上的vip和mac地址的

对应关系。

如果学习了是不是下次来请求时是不是绕过DR而直接发送给了RS啊？    

答:上一题已经解释其原理，所以这里不会出现此题所描述的情况。

查看内核将什么功能编译为模块，什么功能直接收入至内核中，查看如下配置文件

vim /boot/config 内核编译的配置文件可以查看内核所启用的功能

内容总结

以上是互联网集市为您收集整理的Linux Virtual Server(LVS)全部内容，希望文章能够帮你解决Linux Virtual Server(LVS)所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---