标签:LVS
时间:2018.3.1大容量网站相关技术概念
一个网站的体验度,注册用户数>在线用户数>并发数
而并发数量达到一定值的时候,用户打开一个页面所需的时间就是体验度
当一台服务器无法满足用户体验度的时候,2中方式
scale up 向上扩展,提高更强大的机器处理能力,有上限,成本高
scale out 向外扩展,增加多台设备负载
所谓凡事有2面性,因此scale out 带来的问题就是基于何种方式把响应发给多台服务器,多台服务器之前如何保证数据的同步性。
解决问题的解决方案,不停的升级改变,形成一定的架构。
各种应用场景,各种需求下,使用的是不一样的架构,不一样的解决方案。
解决老问题的同时又必然会带来新的问题,
通过前端调度器/负载均衡设备等多种称呼的设备,来解决如何将相应转发给多台服务器,但是产生的问题就是这台LB设备存在SPOF的问题,因此LB要做HA,多台服务器如果有设备出现问题如法相应要怎么解决,这就需要LB能够用户健康检查的机制,及时将故障设备剔除服务池,当故障恢复后再自动加入到服务池提供服务
解决的问题
1、如何解决把何种方式响应发给多台服务器
2、当服务器无法响应时怎么办
3、基于无连接的http协议访问,session如何保存。
cluster分类:
LB(load balance)
权重
LB Cluster的实现
硬件:
F5
Citrix NetScaler
A10
等如浪潮inspair,深信服sangfor国产的硬件设备
软件:
lvs:Linux Virtual Server
nginx:支持四层调度
haproxy:支持四层调度
ats
perbal
pound
各种软件适用于各种平台,需求都不一样等等
但是万变不离其宗的是原理都是一样的,只不过在处理方式上,功能性能上各有千秋罢了,所以一开始的解决方案带给我了理解处理问题的思路后,其实许多其他也只是其功能的扩展或者增强而已。
会话保持
调度算法
健康检查
HA(high available)
SPOF single point of failtrue
heartbeat
keepalived
HPC(high-)
分布式部署
CDN
官网
工作原理
VS根据请求报文的目的IP地址和协议及端口将其调度转发至某RS,根据调度算法来选择RS
VS为virtual server,RS为real server
就是个老鸨子,有人来了请求,小班的有一批人,大班的有一批人,一批人中业务熟练就多给几个人,老鸨子就是LVS。
计算机是人的思想产物,人的思想产物造就了社会系统,同样适用于计算机系统。
LVS类似于iptables中
内核中用ipvs实现
通过ipvsadm来配置先关的调度策略
ipvs工作与类似iptables中的netfilter的INPUT前,当数据包来了之后,在INPUT前做了ipvs,然后根据报文的ip地址和端口信息然后截胡,将其按照ipvsadm指定的转发规则,重新发给响应的RS服务器。
所以LVS工作在OSI模型的四层,
LVS的优缺点
优点:
1、性能好
2、应用在并发链接很多的情况下使用
缺点:
1、功能单一,只能基于4层调度
2、不能检查后端的RS的健康状态
VS
RS
CIP:client ip
VIP:virtual server ip
DIP:director ip
RIP:real server ip
lvs: ipvsadm/ipvs
ipvsadm:用户空间的命令行工具,规则管理器
用于管理集群服务及RealServer
ipvs:工作于内核空间netfilter的INPUT钩子上的框架
lvs集群的类型:
lvs-nat:修改请求报文的目标IP,多目标IP的DNAT
lvs-dr:操纵封装新的MAC地址
lvs-tun:在原请求IP报文之外新加一个IP首部
lvs-fullnat:修改请求报文的源和目标IP
工作原理:
主要是数据到达VS后,VS根据VSIP和调度算法,去服务地址池中去查找哪些节点提供此服务,然后将数据包的Dip改为RSip,可能还会改变Dport。然后RS上的网关需指向DIP。
VS最终对用户做响应
应用场景:
1、此模式对RS修改较少,
工作原理:
主要是数据回去不经过VS,CIP数据到网关,然后网关去找VIP地址,数据到达VIP之后,VIP根据调度算法,转发给响应的RIP,此时目标MAC构建为RIP的MAC地址,此时数据转发出去,不经过TCP/IP的ip层检查。不会经过网关,通过交换机时查看mac表,然后转发给RIP,因此VS和RS必须在同一个交换机下,但是不用在同一个ip网络中,然后RIP收到ip地址,查看mac是自己的,然后再看DIP是VIP,为本机的lo地址,所以处理响应,然后响应时,通过查找路由表,源ip为VIP,源mac为RS MAC,目的ip为CIP,目的mac为CMAC
换句话只有VS的VIP是真实的对外提供arp响应的,RS的VIP是虚拟的值只是用于对VS转发来的报文进行本地处理和本地路由转发,可以不经过来时的路,因为VS直接通过目的MAC为RS转发给RS,当报文从VS的接口发出后直接到达交换机,交换机通过MAC table去进行二层转发到RS上,RS收到报文后发现目的ip为本机lo的地址,则进行处理,然后封装报文,源ip为vip,目的ip为cip,然后通过路由转发。因此前提VS和RS必须在同连接到同一个广播域的物理设备上。否则通过二层转发,vs不能将数据包发给rs。
RS最终对用户做响应
修改ARP不处理:
要使RS的VIP称为虚的VIP,不对外提供arp的响应和发布,
1、arptables工具
2、sysctl修改内核参数
3、在路由器上做arp静态帮助,发往vip的数据包只发给VS,但是rs的内核参数依然要改,要不然如windows os上如果ip地址冲突会报警的。而且会有一些不必要的影响。
应用场景:
1、对服务器操作较多。
2、VS和RS不能跨广播域
工作原理:
方式和DR类似,不同的是不是封装目的MAC地址,而是通过在IP报文首部前加上新的IP首部(源ip为DIP,目的ip为RIP),将报文发往调度的RS,RS直接响应给客户端。
应用场景:
1、VS和RS可以不在同一广播域。
2、VS对外提供真实的VIP地址
3、
工作原理:
此类型kernel默认不支持
同时修改请求报文的源ip和目的ip地址进行转发,CIP改为DIP,VIP改为RIP
应用场景:
1、VS和RS可以跨网段,这个我在浪潮负载上做的就是LVS-NAT和LVS-FULLNAT模式。
FULLNAT就要给VIP做一个NAT地址池,此处用于将CIP改为地址池的中的地址,RS指定的网关为源网关只要能到达NAT地址池中的地址也就是DIP即可。RS服务器本身也不需要修改内核arp参数,配置VIP地址。
5、LVS工作模式对比分析
LVS-NAT和LVS-FULLNAT:请求报文和响应报文都要经过VS,因为有nat session
LVS-DR和LVS-TUN:
ipvs scheduler
根据其调度时是否考虑服务器的负载情况分为两种:静态和动态方法,共10种
静态方法:
1、RR:RoundRobin 轮询
2、WRR:Weigh RoundRobin 加权
3、SH:Source Hash 源地址哈希
4、DH:Destination Hash 目的地址哈希,应用于RS前有多台防火墙时
通过计算RS的overload,负载越小,优先转发
1、LC:Least Connnections
overload=active*256+inactive
2、WLC:Weighted LC,默认调度算法
overload=(active*256+inactive)/weight
3、SED:Shortest Expection Delay
overload=(active+1)*256/weight
4、NQ:Never Queue
5、LBLC:Locality-Based LC
6、LBLCR:
我又要开始扯了,调度算法就像工厂里干活一样。
接了一批活,然后有一批人,那么怎么分配活给这些工人呢,活就是客户端的请求,一批工人就是服务器RS,分配怎么干活的就是VS调度器了。老板接活员工干,有4种静态的方法分配工作。
1、轮询的方式:就是流水线。
2、加权的方式:这个员工干的快,多给他些活干,加工资
3、源地址哈希:这个A公司的活你干过你熟悉,你来
4、目的地址哈希:这个是给B公司的活你干活你熟悉,你来
以上不考虑员工死活的做法,老板早晚得倒闭
所以有根据员工工作量的情况来分配的方法
1、谁现在工作最少给谁优先多些活干,但是没有考虑到你给他活,但是它干的慢啊
2、因此在上个基础上又有了新的解决方案,wlc,权重高又工作量少的优先干
3、
ipvs为内核中代码,ipvsadm为用户空间命令,用来配置LVS
yum install ipvsadm
Usage:
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 --set tcp tcpfin udp
ipvsadm --start-daemon state [--mcast-interface interface] [--syncid sid]
ipvsadm --stop-daemon state
ipvsadm -h
Commands:
Either long or short options are allowed.
--add-service -A add virtual service with options
--edit-service -E edit virtual service with options
--delete-service -D delete virtual service
--clear -C clear the whole table
--restore -R restore rules from stdin
--save -S save rules to stdout
--add-server -a add real server with options
--edit-server -e edit real server with options
--delete-server -d delete real server
--list -L|-l list the table
--zero -Z zero counters in a service or all services
--set tcp tcpfin udp set connection timeout values
--start-daemon start connection sync daemon
--stop-daemon stop connection sync daemon
--help -h display this help message
选项
集群服务相关:
-A|E:添加/修改集群服务
-t:tcp
-u:udp
-f:firewall_mark
service_address
-t:ip:port
-u:ip:port
-f:firewall_mark
-s:指定调度算法 默认wlc
-p:president connection timeout
-D:删除集群服务
-C:清空定义的集群服务
-L|l:查看集群服务
-n: 数字形式
--stats:
--rate:
-c:connnection
-Z:清零集群服务的统计信息
RS相关:
-a|e:添加/修改指定集群服务的节点
-t|u|f service_address:指名添加到那个集群服务
-r service_address:指定RS的地址,ip[:port]当允许端口映射时,可以指定端口
-g|i|m:指定LVS模式类型 -g gateway,DR模式;-i ipip,TUN模式;-m manquerade,NAT模式,默认-g
-w:weight当调度算法有权重时使用
-d:删除指定集群服务的节点/real server
备份(到标准输出)
ipvsadm -S
ipvsadm-save
恢复(从标准输入)
ipvsadm -R
ipvsadm-restore
1、session绑定:始终将统一请求的链接调度到同一服务器,没有容错能力,有损调度效果
2、session同步:在RS之间同步session,RS上有所有集群的session,大规模集群模式下不适用
3、session服务器:部署一台session服务器,专门存放session信息。存在SPOF,需要做HA
对共享同一组RS的多个集群服务,需要统一进行绑定,无法使用lvs sh算法进行调度。
实现无论使用任何调度算法,在一段时间内(默认360s ),能够实现将来自同一个地址的请求始终发往同一个RS
PCC:每客户端持久,来自同一客户端访问某个VIP的所有链接统一转发个某个RS,范围太大
PPC:每端口持久,来自同一客户端访问某个VIP的某个端口的连接统一转发给某个RS,范围太小
PFMC:每防火墙标记持久,基于firewall mark的,将来自同一客户端访问某个VIP的多个端口的连接统一转发给某个RS,
ipvsadm -A -t 172.18.0.1:0 -p 200
ipvsadm -A -t 172.18.0.1:80 -p 200
ipvsadm -A -f 1 -p 200
对应以上三种持久性连接配置
ipvsadm -vnL --persistent-conn 查看持久性连接信息
1 Director不可用,整个系统将不可用;SPoF Single Point of Failure
解决方案:高可用
keepalived heartbeat/corosync
2 某RS不可用时,Director依然会调度请求至此RS
解决方案: 由Director对各RS健康状态进行检查,失败时禁用,成功时启用
keepalived heartbeat/corosync ldirectord
检测方式:
(a) 网络层检测,icmp
(b) 传输层检测,端口探测
(c) 应用层检测,请求某关键资源
3、RS全不用时:backup server, sorry server
? ldirectord:监控和控制LVS守护进程,可管理LVS规则
? 包名:ldirectord-3.9.6-0rc1.1.1.x86_64.rpm yum install ldirectord
? 文件:
/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"
实例
参考普通笔记之LVS之DR,NAT模式配置
标签:LVS
原文地址:http://blog.51cto.com/lajifeiwomoshu/2085092