在计算机领域,集群早在 1960 年就出现,随着互联网和计算机相关技术的发展,现在
集群这一技术已经在各大互联网公司普及。
计算机集群指一组通过计算机网络连接的计算机,它们一起工作,在许多方面,它们可以
被视为一个单一的系统。与网格计算机不同,计算机集群的每个节点都被设置为执行相同
的任务,由特定的软件控制和调度。
集群是一组服务器实体,它们共同提供比单个服务实体更具可伸缩性和可用性的服务平台。
在接受服务的客户端看来,集群类似于单个服务实体,但实际上,集群是由一组服务器组
成的一个集群。与单个服务器相比,集群提供了以下两个关键特性:
Scalability:可伸缩性,也就是集群的性能不局限于单个服务器,新的服务器可以
动态地添加到集群中,从而提高集群的性能。
High availability: 高可用性,也即是集群使得客户能够通过多台服务器冗余避免
突然失去服务。在集群中,相同的服务可以由多个服务器提供。如果一个服务器不可用,
另一个服务器将接管不可用的服务器。集群提供的将错误从一个服务器恢复到另一个服务器
的功能增强了应用程序的可用性。
为了获得可伸缩性和高可用性,集群必须具备以下两个能力:
Load Balancing:负载均衡,负载均衡可以将任务均匀地分配到集群环境中的计算和
网络资源,使得集群持续健康的对外提供服务。
Error recovery:错误恢复能力,集群中的某节点(某个服务器)由于某种原因执行某
任务的过程中出现错误,执行失败,而另一个服务器自动执行相同的任务,并完成服务。
这样就恢复了错误,使得集群可以持续提供服务。
实现集群服务需要两种关键技术:
Cluster address:集群地址,客服端通过访问集群的地址来获取集群内部各服务器
提供的服务,集群对外是只有一个地址的。负责维护整个集群地址的服务器称为负载均衡
器,在客户端访问集群时,其负责将集群的地址转换为集群内部某个计算机的地址,具体
转换到哪个服务器的地址根据调度算法定。
Internal communication: 为了协同工作,实现负载均衡和错误恢复,集群实体间
必须频繁通信,如服务器上的负载均衡器心跳测试信息、服务器之间的任务执行上下文
信息通信等。
使用相同的集群地址,客户机可以访问集群提供的计算服务,集群地址隐藏了每个服务
实体的内部地址,以便客户机所需的计算服务可以分布在各个服务实体之间。内部通信
是集群正常工作的基础,它使集群具有均衡的负载和错误恢复能力。
见此文–MySQL 高可用
分布式系统指在许多不同的服务器中部署不同的服务模块,并通过远程调用协作完成特定
任务以提供服务。
一般分布式系统都会部署分布式应用程序和服务,对应用程序和服务进行分层和分段,然后
以分布式方式部署应用程序和服务模块到各个节点。它不仅可以提高并发访问能力,而且可
以减少数据库连接和资源消耗,还可以使不同的应用程序重用公共服务,使业务易于扩展。
分布式存储:
分布式计算
分布式常见应用
分布式系统处理任务是平行的,集群处理任务是串联的。
例如:包含 100 个子任务的客户请求分别到达 10 台分布式服务系统和 10 台集群服务
系统。假设单个任务单台服务器需要 1 分钟完成。那么分布式服务器系统的每台服务器
会花费 1 分钟完成一个任务,接着完成下一个任务,不考虑任务之间的依赖关系。这样
10 分钟后,就完成了 100 个任务;而在集群系统中,总是有 10 个任务被同时分配到
10 台服务器上处理,接着处理后面 10 个任务,这样在 10 分钟后,也完成了 100 个
任务。注意:在分布式中一般不会同时处理 10 个任务后又同时处理下面的 10 个任务。
集群:同一个业务系统,部署在多台服务器上。集群中,每一台服务器实现的功能
没有差别,数据和代码都是一样的
分布式:一个业务被拆成多个子业务,或者本身就是不同的业务,部署在多台服务
器上。分布式中,每一台服务器实现的功能是有差别的,数据和代码也是不一样的,分
布式每台服务器功能加起来,才是完整的业务。
一句话:分布式是通过缩短单个任务的执行时间来提高效率,集群是通过增加单位
时间内执行的任务数量来提高效率。
例如:对于大型网站,访问用户很多,实现一个群集,在前面部署一个负载均衡服务器,
后面几台服务器完成同一业务。如果有用户进行相应业务访问时,负载均衡器根据后端
哪台服务器的负载情况,决定由给哪一台去完成响应,并且一台服务器垮了,其它的服
务器可以顶上来。分布式的每一个节点,都完成不 的业务,如果一个节点垮了,那这个
业务可能就会失败。
lvs
:Linux Virtual Server,阿里四层 SLB (Server Load Balance)使用
nginx
:支持七层调度,阿里七层 SLB 使用 Tengine
haproxy
:支持七层调度
ats
:Apache Traffic Server,yahoo 捐助给 apache
perlbal
:Perl 编写
pound
这里的七层和四层指的是网络协议栈的层,比如:nginx 能够调度 http 协议
请求,二 http 为应用层在网络协议栈 ISO 模型的第七层;而 LVS 只能调度
TCP 等请求,TCP 在 ISO 模型的第四层传输层。
高可用的实现方案已报有两种
使用 Virtual Redundant Routing Protocol (VRRP)协议来实现高可用
实现 vrrp 协议的软件如 keepalived,其配合 LVS 是典型的高可用集群的常用实现
LVS 是由张文松在 1998 年 5 月启动的自由和开源项目,遵循 GNU 通用公共许
可证(GPL)第 2 版的要求。该项目的任务是使用集群技术为 Linux 构建一个高性
能、高可用的服务器,它提供了良好的可伸缩性、可靠性和可服务性。
LVS 项目的主要工作是开发高级 IP 负载平衡软件(IPVS)、应用程序级负载平衡
软件(KTCPVS)和集群管理组件。
IPVS:在Linux内核中实现的一种高级IP负载平衡软件。IP Virtual Server代码合
已经被合并到版本2.4.x和更新的Linux内核主线。
KTCPVS:在Linux内核中实现应用程序级负载平衡,截至2011年2月仍在开发中。
LVS 可用于构建高度可伸缩和高度可用的网络服务,如 web、电子邮件、媒体和
VoIP 服务,并将可伸缩的网络服务集成到大型可靠的电子商务或电子政府应用程
序中。基于 LVS 的解决方案已经部署在世界各地的许多实际应用程序中,
包括维基百科 Wikipedia。维基百科简化版的架构如下:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zQeSey5f-1692004918997)(png/2019-12-31-17-54-51.png)]
LVS 组件依赖于 Linux Netfilter 框架,其源代码可以在 Linux 内核源代码的
net/netfilter/ipvs
子目录中找到。LVS 能够处理 UDP、TCP 等 4 层协议,
通过检查第 7 层数据包,也可以处理 FTP 被动连接。
用于配置 LVS 的用户空间实用程序称为 ipvsadm,它需要超级用户特权才能运行。
LVS 官网
LVS 相关术语
VS
: Virtual Server,负责调度的服务器
RS
: Real Server,负责真正提供服务
VS 根据请求报文的目标 IP 和目标协议及端口将其调度转发至某 RS,根据调度算法
来挑选 RS。LVS 是内核级功能,工作在 INPUT 链的位置,将发往 INPUT 的流量
进行"处理"。
查看内核对 LVS 的支持
[root@steve ~]$grep -i -C 10 ipvs /boot/config-3.10.0-1062.4.1.el7.x86_64
CONFIG_NETFILTER_XT_MATCH_CPU=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ECN=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_IPVS=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_NFACCT=m
CONFIG_NETFILTER_XT_MATCH_OSF=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
--
CONFIG_IP_SET_HASH_NETNET=m
CONFIG_IP_SET_HASH_NETPORT=m
CONFIG_IP_SET_HASH_NETIFACE=m
CONFIG_IP_SET_LIST_SET=m
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
#
# 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 SH scheduler
#
CONFIG_IP_VS_SH_TAB_BITS=8
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BF6T0PBF-1692004918999)(png/DR.png)]
如果业务应用访问量很高,可以通过配置监听规则将流量分发到不同的云服务器 ECS
(Elastic Compute Service 弹性计算服务)实例上。此外,可以使用会话保持功能
将同一客户端的请求转发到同一台后端 ECS。
可以根据业务发展的需要,随时添加和移除 ECS 实例来扩展应用系统的服务能力,
适用于各种 Web 服务器和 App 服务器。
可以在负载均衡实例下添加多台 ECS 实例。当其中一部分 ECS 实例发生故障后,
负载均衡会自动屏蔽故障的 ECS 实例,将请求分发给正常运行的 ECS 实例,保
证应用系统仍能正常工作
为了提供更加稳定可靠的负载均衡服务,阿里云的负载均衡实现在各地域部署了
多可用区以实现同地域容灾。当主可用区出现机房故障或不可用时,负载均衡仍
然有能力在非常短的时间内(如:大约 30s 中断)切换到另外一个备可用区恢复
服务能力;当主可用区恢复时,负载均衡同样会自动切换到主可用区提供服务。
使用负载均衡时,可以将负载均衡实例部署在支持多可用区的地域以实现同城容灾。
此外,还需要结合自身的应用需要,综合考虑后端服务器的部署。如果每个可用区
均至少添加了一台 ECS 实例,那么此种部署模式下的负载均衡服务的效率是最高的。
如下图所示,在负载均衡实例下绑定不同可用区的 ECS 实例。正常情况下,用户访
问流量将同时转至发主、备可用区内的 ECS 实例;当可用区 A 发生故障时,用户
访问流量将只转发至备可用区内的 ECS 实例。此种部署既可以避免因为单个可用区
的故障而导致对外服务的不可用,也可以通过不同产品间可用区的选择来降低延迟。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pw7Fq2U7-1692004919000)(png/LVS-BACK.png)]
如果在负载均衡实例的主可用区(可用区 A)下绑定多台 ECS 实例,而在备可用区
(可用区 B)没有任何 ECS 实例。当主可用区发生故障时会造成业务中断,因为备
可用区没有 ECS 实例来接收请求。这样的部署方式很明显是以牺牲高可用性为代
价来获取低延时。
可以在不同地域下部署负载均衡实例,并分别挂载相应地域内不同可用区的 ECS。
上层利用云解析做智能 DNS,将域名解析到不同地域的负载均衡实例服务地址下,
可实现全局负载均衡。当某个地域出现不可用时,暂停对应解析即可实现所有
用户访问不受影响。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0vpuEGFe-1692004919006)(png/LVS-area.png)]
对象存储(Object Storage Service,简称 OSS),是阿里云对外提供的海量、安全和
高可靠的云存储服务
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ajRJcWah-1692004919007)(png/2019-12-28-17-53-30.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2yuCtLPo-1692004919007)(png/2019-12-28-17-53-54.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2x9DP9N3-1692004919008)(png/2019-12-28-17-54-53.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R9xPeppn-1692004919008)(png/2019-12-28-17-56-29.png)]
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
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FiHqiu8T-1692004919008)(png/VS-NAT.gif)]
vs-nat:本质是多目标 IP 的 DNAT,通过将请求报文中的目标地址和目标端口修改为
某挑出的 RS 的 RIP 和 PORT 实现转发,特点:
(1)RIP 和 DIP 应在同一个 IP 网络,且应使用私网地址;RS 的网关要指向 DIP
(2)请求报文和响应报文都必须经由 Director 转发,Director 易于成为系统瓶颈
(3)支持端口映射,可修改请求报文的目标 PORT
(4)VS 必须是 Linux 系统,RS 可以是任意 OS 系统
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-83QXANlx-1692004919008)(png/natflow.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6CodrSkq-1692004919009)(png/VS-DRouting.gif)]
LVS-DR:Direct Routing,直接路由,LVS 默认模式,应用最广泛,通过为请求报文
重新封装一个 MAC 首部进行转发,源 MAC 是 DIP 所在的接口的 MAC,目标 MAC 是某挑选
出的 RS 的 RIP 所在接口的 MAC 地址;源 IP/PORT,以及目标 IP/PORT 均保持不变
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xjQ98zXl-1692004919009)(png/DR-flow-me.png)]
DR 模式的特点:
arptables -A IN -d $VIP -j DROP
arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
在 RS 上修改内核参数以限制 arp 通告及应答级别[^1]/proc/sys/net/ipv4/conf/all/arp_ignore
/proc/sys/net/ipv4/conf/all/arp_announce
转发方式:不修改请求报文的 IP 首部(源 IP 为 CIP,目标 IP 为 VIP),而
在原 IP 报文之外再封装一个 IP 首部(源 IP 是 DIP,目标 IP 是 RIP),将
报文发往挑选出的目标 RS;RS 直接响应给客户端(源 IP 是 VIP,目标 IP 是 CIP)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2EwnGrWh-1692004919009)(png/VS-IPTunneling.gif)]
TUN 模式特点:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mLNN8gJm-1692004919009)(png/fullnat.jpg)]
fullnat 模式特点:
注意:此类型 kernel 默认不支持
服务器参数\LVS 模式 | VS/NAT | VS/TUN | VS/DR |
---|---|---|---|
Server | any | Tunneling | Non-arp device |
server network | private | LAN/WAN | LAN |
server number | low (10~20) | High (100) | High (100) |
server gateway | load balancer | own router | Own router |
LVS 调度算法可以根据其调度是是否考虑各 RS 当前的负载状态分为静态调度方法
和动态调度方法。由ipvs scheduler
调度。内核 4.15 版本以前总共有十种调度
算法,各调度算法和源码的对应关系如下:
调度算法 | 源码文件 |
---|---|
Round-robin | (ip_vs_rr.c) |
Weighted round-robin | (ip_vs_wrr.c) |
Least-connection | (ip_vs_lc.c) |
Weighted least-connection | (ip_vs_wlc.c) |
Locality-based least-connection | (ip_vs_lblc.c) |
Locality-based least-connection with replication | (ip_vs_lblcr.c) |
Destination hashing | (ip_vs_dh.c) |
Source hashing | (ip_vs_sh.c) |
Shortest expected delay | (ip_vs_sed.c) |
Never queue | (ip_vs_nq.c) |
root@ubuntu1904:/data#ll linux-5.4.6/net/netfilter/ipvs/
total 588
-rw-rw-r-- 1 root root 13438 Dec 21 18:05 ip_vs_app.c
-rw-rw-r-- 1 root root 37075 Dec 21 18:05 ip_vs_conn.c
-rw-rw-r-- 1 root root 67225 Dec 21 18:05 ip_vs_core.c
-rw-rw-r-- 1 root root 107931 Dec 21 18:05 ip_vs_ctl.c
-rw-rw-r-- 1 root root 6328 Dec 21 18:05 ip_vs_dh.c
-rw-rw-r-- 1 root root 5535 Dec 21 18:05 ip_vs_est.c
-rw-rw-r-- 1 root root 1876 Dec 21 18:05 ip_vs_fo.c
-rw-rw-r-- 1 root root 15949 Dec 21 18:05 ip_vs_ftp.c
-rw-rw-r-- 1 root root 15908 Dec 21 18:05 ip_vs_lblc.c
-rw-rw-r-- 1 root root 20389 Dec 21 18:05 ip_vs_lblcr.c
-rw-rw-r-- 1 root root 2232 Dec 21 18:05 ip_vs_lc.c
-rw-rw-r-- 1 root root 13657 Dec 21 18:05 ip_vs_mh.c
-rw-rw-r-- 1 root root 9010 Dec 21 18:05 ip_vs_nfct.c
-rw-rw-r-- 1 root root 3359 Dec 21 18:05 ip_vs_nq.c
-rw-rw-r-- 1 root root 2132 Dec 21 18:05 ip_vs_ovf.c
-rw-rw-r-- 1 root root 2501 Dec 21 18:05 ip_vs_pe.c
-rw-rw-r-- 1 root root 4877 Dec 21 18:05 ip_vs_pe_sip.c
-rw-rw-r-- 1 root root 3832 Dec 21 18:05 ip_vs_proto_ah_esp.c
-rw-rw-r-- 1 root root 8570 Dec 21 18:05 ip_vs_proto.c
-rw-rw-r-- 1 root root 18326 Dec 21 18:05 ip_vs_proto_sctp.c
-rw-rw-r-- 1 root root 20142 Dec 21 18:05 ip_vs_proto_tcp.c
-rw-rw-r-- 1 root root 12350 Dec 21 18:05 ip_vs_proto_udp.c
-rw-rw-r-- 1 root root 3310 Dec 21 18:05 ip_vs_rr.c
-rw-rw-r-- 1 root root 5727 Dec 21 18:05 ip_vs_sched.c
-rw-rw-r-- 1 root root 3758 Dec 21 18:05 ip_vs_sed.c
-rw-rw-r-- 1 root root 9445 Dec 21 18:05 ip_vs_sh.c
-rw-rw-r-- 1 root root 55183 Dec 21 18:05 ip_vs_sync.c
-rw-rw-r-- 1 root root 3044 Dec 21 18:05 ip_vs_wlc.c
-rw-rw-r-- 1 root root 6950 Dec 21 18:05 ip_vs_wrr.c
-rw-rw-r-- 1 root root 43486 Dec 21 18:05 ip_vs_xmit.c
-rw-rw-r-- 1 root root 13157 Dec 21 18:05 Kconfig
-rw-rw-r-- 1 root root 1428 Dec 21 18:05 Makefile
10 种算法的官方说明
循环调度算法:该调度算法是 LVS 最简单的调度策略,其将每个传入的请求发送到
其列表的下一个服务器。例如:在三个服务器的集群中(A、B 和 C 服务器),请求 1
将被 调度到服务器 A,请求 2 将被调度到服务器 B,请求 3 将被 C 服务器处理,
请求 4 又被调度到服务器 A。从而让集群中的服务器循环的提供服务,该调度策略
平等对待所有服务器,其不考虑到来的连接或请求数量和服务器的响应时间(或是负
载情况),其性能高于传统的 DNS 轮询。
加权轮询调度算法:该调度策略旨在处理不同的性能的服务器在接收请求和处理请求
时的权重呵呵优先顺序。在调度期间,每个服务器的性能有差异,各自会被分配不同
的权重值,一个表示处理能力的整数值。权重较大的服务器比权重小的服务器优先
处理新连接,权重较大的服务器也比权重较小的服务器获得更多的连接,权重相同
的服务器获得相同的连接数。例如:RS 服务器分别为 A、B 和 C,它们分别有权重
4、3 和 2,那么一个比较理想的调度序列会是 AABABCABC,可以看到在三次轮询过
程中,不同权重的 RS 被分配了不同的连接数,但是整个过程中各自总的处理连接比
例接近 4:3:2(A 处理了 4 次,B 处理了 3 次,C 处理了 2 次)。
在加权轮询调度的实现中,在管理员修改 VS 的服务器调度策略后,会根据具体的配
置权重来生成调度序列。基于该序列以轮询调度方式将不同的网络连接定向到后端不
同的 RS 服务器。
当后端 RS 服务器的处理性能不一时,此算法是比单纯的轮询调度算法优异的。但是,
如果有不间断的高负载的请求到来时,可能造成各服务器的动态负载严重不均衡。
也就是说,可能会有很大部分的高负载请求都被调度到相同的 RS 上。此时,该 RS
的复制将会很高。
而实际上,轮询是加权轮询策略的特例,即是加权轮询的权重值都为 1 的情况。
目标地址哈希调度:该调度策略是根据目标 IP 地址来查找静态分配的哈希表,将网
络连接分配给相应的服务器。第一次轮询调度至 RS,后续将发往同一个目标地址的
请求始终转发至第一次挑中的 RS。该调度策略的典型使用场景是正向代理缓存场景
中的负载均衡,如:宽带运营商
源地址哈希调度算法:该调度策略查找由源 IP 地址静态分配的哈希表,将网络连接
分配给服务器。其将来自于同一个 IP 地址的请求始终发往第一次挑中的 RS,从而实
现会话绑定。
最少连接调度算法:该调度策略将网络连接调度给建立连接数量最少的 RS 服务器。
该调度算法会动态的记录各服务器的活动连接数。如果后端的一群 RS 服务器的处理
性能相近,那么最少连接调度策略有助于在请求的负载有大幅变化时平滑分配负载。
VS 将把请求定向到有最少的活动连接的 RS。
乍一看,该调度策略应该可以在服务器的处理性能各不相同的情况下表现良好,因为
处理性能高的服务器会接到更多的请求并处理。然而由于 TCP 协议的TIME_WAIT
状态导致了其表现并不好。TCP 定义的TIME_WAIT
状态为 2 分钟,在这两分钟内
某个繁忙的站点可能已经收到了好几千个请求。例如:RS-A 的处理性能是 RS-B 的
两倍,RS-A 可能已经按照正常的速度完成了这些请求并将它们保持在了TIME_WAIT
状态(也就是在 2 分钟内完成了分配的请求),而 RS-B 正挣扎着完成分配到自己的
好几千的请求,在这种情况下就没法均衡负载了。
加权的最少连接调度算法:该调度策略允许为每个 RS 服务器分配一个性能权重值。
具有较高权重值的服务器在任何时候都将接收到较大百分比的活动连接。VS 管理员
可以给每个 RS 服务器分配一个权重值,网络连接会被调度到每个 RS 服务器并且
每个服务器的当前活动连接数的百分比与其权重成比例。
加权的最少连接调度算法相比最少连接算法需要额外的除法来区分不同比例。为了
在服务器处理能力接近相同的情况下最小化调度工作的开销,才有了非加权和加权
的最少连接算法。
基于位置的最少连接调度算法:该调度策略专用于目的 IP 的负载均衡。一般被用于
缓存集群。该算法通常会将到某个 IP 地址的数据包定向到负责处理其的服务器,前
提是该服务器是活动的并且负载不高。如果该服务过载(活动连接数大于其权重)并且
有一个服务器目前只有一半的负载,那就会将加权的最少连接服务器(一般负载的服
务器)分配给该 IP。
基于位置的带复制的最少连接调度算法:该调度策略也用于目的 IP 的负载均衡。一般
用于缓存集群。在以下方面其和 LBLC 调度策略不同:调度服务器 LVS 会维护某个目
的 IP 到可能为其提供服务的服务器节点的映射。发往目标 IP 的请求将被调度到该目
标 IP 对应的服务器节点集中拥有最少连接的节点。如果该服务器集的节点均过载,那
么 LVS 会在整个集群中挑选一个最少连接的节点加入到这个服务器集(可能为该目标
IP 服务的节点集合)。
最短期望时延调度算法:该算法将网络连接调度分配给预期最小时延的服务器。发送到
集群中的第 i 个节点最小时延可表示为:(Ci + 1)/Ui。Ci 是第 i 个服务器的连接数,
Ui 是第 i 个服务器的权重。
不排队算法: 该调度策略在有空闲的服务器时将请求调度到该空闲服务器。如果没有空
闲服务器,请求将被调度到最少期望时延的节点(SED)。
FO(Weighted Fail Over)调度算法,在此 FO 算法中,会遍历虚拟服务所关联的真实服务
器链表,找到还未过载(未设置 IP_VS_DEST_F_OVERLOAD 标志)的且权重最高的真实服务器,
进行调度
OVF(Overflow-connection)调度算法,基于真实服务器的活动连接数量和权重值实现。
将新连接调度到权重值最高的真实服务器,直到其活动连接数量超过权重值位置,之后调
度到下一个权重值最高的真实服务器,在此 OVF 算法中,遍历虚拟服务相关联的真实服务器
链表,找到权重值最高的可用真实服务器。一个可用的真实服务器需要同时满足以下条件:
ipvsadm
,相关的工具如下
ipvsadm 核心功能
ipvsadm 工具用法
# 管理集群服务
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] # 保存
# 管理集群中的RS
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
管理集群上的 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:
清空定义的所有内容
ipvsadm -C
清空计数器
ipvsadm -Z [-t|u|f service-address]
查看
ipvsadm -L|l [options]
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
systemctl restart ipvsadm.service
WM:FireWall Mark
MARK target 用于给特定的报文打标记
其中:value 可为 0xffff 格式,表示十六进制数字
借助于防火墙标记来分类报文,而后基于标记定义集群服务;可将多个不同的应用使用同
一个集群服务进行调度
实现方法:
iptables -t mangle -A PREROUTING -d $vip -p $proto -m multiport --dports $port1,$port2,… -j MARK --set-mark NUMBER
ipvsadm -A -f NUMBER [options]
例如:
[root@lvs ~]#ipvsadm -A -f 10
[root@lvs ~]#ipvsadm -a -f 10 -r 192.168.39.17 -g
[root@lvs ~]#ipvsadm -a -f 10 -r 192.168.39.7 -g
[root@lvs ~]#ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 10 wlc
-> 192.168.39.7:0 Route 1 0 0
-> 192.168.39.17:0 Route 1 0 0
session 绑定:对共享同一组 RS 的多个集群服务,需要统一进行绑定,lvs 的 SH
算法无法实现持久连接( lvs persistence )
模板:实现无论使用任何调度算法,在一段时间内(默认 360s ),能够实现将来自同
一个地址的请求始终发往同一个 RS
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]
例如
[root@lvs ~]#ipvsadm -E -f 10 -p
[root@lvs ~]#ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 10 wlc persistent 360
-> 192.168.39.7:0 Route 1 0 15
-> 192.168.39.17:0 Route 1 0 7
[root@lvs ~]#ipvsadm -E -f 10 -p 3600
[root@lvs ~]#ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 10 wlc persistent 3600
-> 192.168.39.7:0 Route 1 0 79
-> 192.168.39.17:0 Route 1 0 7
各主机 IP
主机 | IP |
---|---|
Client | eth0:172.20.2.37/16 |
LVS | eth0:172.20.2.43/16 |
eth1:192.168.10.200/24 | |
RS-A | eth0:192.168.10.201/24 |
RS-B | eth0:192.168.10.202/24 |
大致结构如下,本次实验略去中间的路由器和防火墙,客户端和 LVS 在同一网段
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PU0DbDkD-1692004919010)(png/LVS-NAT.png)]
操作过程
# 1. 在LVS上
~$ vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
...
~$ sysctl -p
# 增加集群调度规则
~$ ipvsadm -A -t 172.20.2.43:80 -s rr
# 增加被调度的RS,-m表示使用NAT模式
~$ ipvsadm -a -t 172.20.2.43:80 -r 192.168.10.201 -m
~$ ipvsadm -a -t 172.20.2.43:80 -r 192.168.10.202 -m
# 2.在RS-A和RS-B上
~$ yum install httpd -y
~$ echo "This is RS-A." > /var/www/html/index.html
~$ systemctl start httpd
# 3.在客户端访问测试
~$ while : ; do curl -connect-timeout 3 172.20.2.43 ; sleep 1 ; done
限制响应级别:arp_ignore
限制通告级别:arp_announce
各主机 IP
主机 | IP |
---|---|
Client | eth0:172.20.2.37/16 |
Router | eth0:172.20.2.43/16 |
eth1:192.168.10.200/24 | |
LVS | eth0:192.168.10.100/24 |
lo:1 192.168.10.101/32 | |
RS-A | eth0:192.168.10.201/24 |
lo:1 192.168.10.101/32 | |
RS-B | eth0:192.168.10.202/24 |
lo:1 192.168.10.101/32 |
大致结构如下,客户端和 LVS 在不同网段
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gpcin6kS-1692004919010)(png/LVS-DR.png)]
配置过程
# 1. 修改RS-A和RS-B内核参数
# RS-A
~$ echo 1 > /proc/sys/net/ipv4/all/arp_ignore
~$ echo 1 > /proc/sys/net/ipv4/lo/arp_ignore
~$ echo 2 > /proc/sys/net/ipv4/all/arp_announce
~$ echo 2 > /proc/sys/net/ipv4/lo/arp_announce
# RS-B
~$ echo 1 > /proc/sys/net/ipv4/all/arp_ignore
~$ echo 1 > /proc/sys/net/ipv4/lo/arp_ignore
~$ echo 2 > /proc/sys/net/ipv4/all/arp_announce
~$ echo 2 > /proc/sys/net/ipv4/lo/arp_announce
# 2. 将client:172.20.2.37的网关指向路由器eth0口
~$ route add -net 0 gw 172.10.2.43
# 3. 将RS-A:192.168.10.201和RS-B:192.168.10.202的网关指向路由器eth1口
# RS-A
~$ route add -net 0 gw 192.168.10.200
# RS-B
~$ route add -net 0 gw 192.168.10.200
# 4. 在LVS和RS的本地环回网卡添加VIP
# LVS
~$ ifconfig lo:1 192.168.10.101/32
# RS-A 和 RS-B
~$ ifconfig lo:1 192.168.10.101/32
# 5. 在LVS: 192.168.10.100上添加调度规则和被调度主机
~$ ipvsadm -A -t 192.168.10.101:80 -r wlc
~$ ipvsadm -a -t 192.168.10.101:80 -r 192.168.10.201 -g
~$ ipvsadm -a -t 192.168.10.101:80 -r 192.168.10.202 -g
# 6. 在客户端172.20.2.37测试
~$ while : ; do curl --connect-timeout 3 192.168.10.101 ; sleep 2 ;done
#!/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 $You can't use 'macro parameter character #' in
math modemask #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
#!/bin/bash
vip='10.0.0.100'
iface='lo:1'
mask='255.255.255.255'
port='80'
rs1='192.168.8.101'
rs2='192.168.8.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
RS 全部宕机或者是维护时:可以使用 LVS 调度器来响应客户,告知大致情况,此时的服务称为:
sorry server(道歉服务)
ldirectord:监控和控制 LVS 守护进程,可管理 LVS 规则
包名:ldirectord-3.9.6-0rc1.1.2.x86_64.rpm
下载地址
安装
[root@LVS data]#wget http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/x86_64/ldirectord-3.9.6-0rc1.1.2.x86_64.rpm
[root@LVS data]#yum localindtall ldirectord-3.9.6-0rc1.1.2.x86_64.rpm -y
[root@LVS data]# rpm -ql ldirectord
/etc/ha.d
/etc/ha.d/resource.d
/etc/ha.d/resource.d/ldirectord
/etc/logrotate.d/ldirectord
/usr/lib/ocf/resource.d/heartbeat/ldirectord
/usr/lib/systemd/system/ldirectord.service
/usr/sbin/ldirectord
/usr/share/doc/ldirectord-3.9.6
/usr/share/doc/ldirectord-3.9.6/COPYING
/usr/share/doc/ldirectord-3.9.6/ldirectord.cf
/usr/share/man/man8/ldirectord.8.gz
配置 ldirectord 支持 ipvs 的 DR 模型
[root@LVS data]# cat /etc/ha.d/ldirectord.cf
checktimeout=3
checkinterval=1
autoreload=yes
logfile="/var/log/ldirectord.log"
quiescent=no # 当RS down时 yes将修改权重为0,此配置有bug ,no为从调度列表中删除RS
virtual=192.168.10.101:80
real=192.168.10.201 gate 1 # gate 表示DR模式,1 表示weight
real=192.168.10.202 gate 2
fallback=127.0.0.1:80 gate
service=http
scheduler=wrr
# persistent=600
# netmask=255.255.255.255
protocol=tcp
checktype=negotiate
checkport=80
[root@LVS data]# systemctl status ldirectord
● ldirectord.service - Monitor and administer real servers in a LVS cluster of load balanced virtual servers
Loaded: loaded (/usr/lib/systemd/system/ldirectord.service; disabled; vendor preset: disabled)
Active: inactive (dead)
[root@LVS data]# systemctl start ldirectord
[root@LVS data]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.10.101:80 wrr
-> 192.168.10.201:80 Route 1 0 11
-> 192.168.10.202:80 Route 2 0 9
配置 ldirectord 支持 ipvs 的 DR 模型并且具有 Firewall Mark
[root@LVS data]# /etc/ha.d/ldirectord.cf
checktimeout=3
checkinterval=1
autoreload=yes
logfile="/var/log/ldirectord.log" # 日志文件
quiescent=no # 当RS down时 yes将修改权重为0,此配置有bug ,no为从调度列表中删除RS
virtual=5 # 指定VS的FWM 或 IP:PORT
real=192.168.10.201:80 gate 2 # DR模型,权重为 2
real=192.168.10.202:80 gate 1
fallback=127.0.0.1:80 gate # sorry server
service=http
scheduler=wrr
# protocol=tcp # 如果FWM模式,此行必须注释掉
checktype=negotiate
checkport=80
request="index.html"
receive=“Test Ldirectord"