负载均衡-LVS
集群和分布式
系统性能扩展方式:
- ScaleUP: 垂直扩展,向上扩展,增强,性能更强的计算机运行同样的服务
- ScaleOut:水平扩展,向外扩展,增加设备,并行地运行多个服务调度分配问题,Cluster
垂直扩展不再提及:
随着计算机性能的增长,其价格会成倍增长
单台计算机的性能是有.上限的,不可能无限制地垂直扩展
多核CPU意味着即使是单台计算机也可以并行的。那么,为什么不一开始就并行化技术?
集群Cluster
Cluster:集群,为解决某个特定问题将多台计算机组合起来形成的单个系统
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%,9999%
SLA:服务等级协议(简称: SLA,全称: service level agreement)。是在一定开销下为保障服务的性能和可用性,服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。在常规的领域中,总是设定所谓的三个9,四个9来进行表示,当没有达到这种水平的时候,就会有一些列的惩罚措施,而运维,最主要的目标就是达成这种服务水平。
1 | 1年= 365天= 8760小时 |
停机时间又分为两种,一种是计划内停机时间,一种是计划外停机时间,而运维则主要关注计划外停机时间。
- HPC: High-performance computing,高性能www.top500.org
分布式系统
分布式存储: Ceph, GlusterFS, FastDFS, MogileFS
分布式计算: hadoop, Spark
分布式常见应用
- 分布式应用-服务按照功能拆分,使用微服务
- 分布式静态资源–静态资源放在不同的存储集群上
- 分布式数据和存储–使用key-value缓存系统
- 分布式计算–对特殊业务使用分布式计算,比如Hadoop集群
集群和分布式
集群:同一个业务系统,部署在多台服务器上。集群中,每一台服务器实现的功能没有差别,数据和代码都是一样的
分布式: 一个业务被拆成多个子业务,或者本身就是不同的业务,部署在多台服务器上。分布式中,每一台服务器实现的功能是有差别的,数据和代码也是不一样的,分布式每台服务器功能加起来,才是完整的业务
分布式是以缩短单个任务的执行时间来提升效率的,而集群则是通过提高单位时间内执行的任务数来提升效率。
对于大型网站,访问用户很多,实现一个群集,在前面部署一个负载均衡服务器, 后面几台服务器完成同一业务。如果有用户进行相应业务访问时,负载均衡器根据后端哪台服务器的负载情况,决定由给哪一台去完成响应,并且一台服务器垮了,其它的服务器可以顶上来。分布式的每-一个节点, 都完成不同的业务,如果一个节点垮了, 那这个业务可能就会失败
集群设计原则
- 可扩展性–集群的横向扩展能力
- 可用性–无故障时间(SLA service level agreement)
- 性能–访问响应时间
- 容量–单位时间内的最大并发吞吐量(C10K并发问题)
集群设计实现
基础设施层面
- 提升硬件资源性能–从入口防火墙到后端web server均使用更高性能的硬件资源
- 多域名–DNS 轮询A记录解析
- 多入口–将A记录解析到多个公网IP入口
- 多机房–同城+异地容灾
- CDN(Content Delivery Network)-基于GSLB(Global Server Load Balance)实现全局负载均衡,如: DNS
业务层面
- 分层:安全层、负载层、静态层、动态层、(缓存层、 存储层)持久化与非持久化
- 分割:基于功能分割大业务为小服务
- 分布式:对于特殊场景的业务,使用分布式计算
LB Cluster 负载均衡集群
按实现方式划分
- 硬件
- F5 Big-IP
- Citrix Netscaler
- A10 A10
- 软件
- LVS,阿里四层SLB使用
- Nginx:支持七层调度,阿里七层SLB使用Tengine
- Haproxy:支持七层调度
- ATS:Apache Traffic Server
- Perlbal:Perl编写
- Pound
基于工作的协议层次划分
- 传输层(通用):DNAT和DPORT
- LVS
- Nginx:stream
- Haproxy:mode tcp
- 应用层(专用):针对特定协议,常称为proxy server
- Http: nginx, httpd, haproxy(mode http), …
- Fastcgi: nginx, httpd,
- MySQL: mysql-proxy, …
负载均衡的会话保持
- session sticky:同一用户调度固定服务器
- Source IP: LVS sh算法(对某-特定服务而言)
- Cookie
- session replication:每台服务器拥有全部session
- session multicast cluster
- session server:专门的session服务器
- Memcached, Redis
HA高可用集群实现
- keepalived: vrrp协议
- Ais:应用接口规范
- heartbeat
- cman+rgmanager(RHCS)
- coresync_ pacemaker
Linux Virtual Server简介
LVS介绍
LVS: Linux Virtual Server,负载调度器,内核集成,阿里的四层SLB(Server Load Balance)是基于LVS+keepalived实现
LVS官网: http://www.linuxvirtualserver.org/
LVS相关术语
- VS: Virtual Server,负责调度
- RS: Real Server,负责真正提供服务
LVS工作原理
- 当客户端的请求到达负载均衡器的内核空间时,首先会到达PREROUTING链。
- 当内核发现请求数据包的目的地址是本机时,将数据包送往INPUT链。
- LVS由用户空间的ipvsadm和内核空间的IPVS组成,ipvsadm用来定义规则,IPVS利用ipvsadm定义的规则工作,IPVS工作在INPUT链上,当数据包到达INPUT链时,首先会被IPVS检查,如果数据包里面的目的地址及端口没有在规则里面,那么这条数据包将经过INPUT链送至用户空间,交给用户空间的进程来处理。
- 如果数据包里面的目的地址及端口在规则里面,那么这条数据报文将被修改目的地址为事先定义好的后端服务器,并送往POSTROUTING链。
- 最后经由POSTROUTING链发往后端服务器。
查看内核支持LVS
1 | [root@lb01 ~]# grep -i -C 10 ipvs /boot/config-4.18.0-147.el8.x86_64 |
LVS功能及组织架构
负载均衡的应用场景为高访问量的业务,提高应用程序的可用性和可靠性。
应用于高访问量的业务
如果您的应用访问量很高,可以通过配置监听规则将流量分发到不同的云服务器ECS (Elastic Compute Service
弹性计算服务)实例上。此外,可以使用会话保持功能将同一客户端的请求转发到同一台后端ECS
扩展应用程序
可以根据业务发展的需要,随时添加和移除ECS实例来扩展应用系统的服务能力,适用于各种Web服务器和App服务器。
消除单点故障
可以在负载均衡实例下添加多台ECS实例。当其中一部分ECS实例发生故障后,负载均衡会自动屏蔽故障的ECS实例,将请求分发给正常运行的ECS实例,保证应用系统仍能正常工作
同城容灾
为了提供更加稳定可靠的负载均衡服务,阿里云负载均衡已在各地域部署了多可用区以实现同地域容灾。当主可用区出现机房故障或不可用时,负载均衡仍然有能力在非常短的时间内(如:大约30s中断)切换到另外一个备可用区恢复服务能力;当主可用区恢复时,负载均衡同样会自动切换到主可用区提供服务。
使用负载均衡时,您可以将负载均衡实例部署在支持多可用区的地域以实现同城容灾。此外,建议您结合自身的应用需要,综合考虑后端服务器的部署。如果您的每个可用区均至少添加了一台ECS实例,那么此种部署模式下的负载均衡服务的效率是最高的。
如下图所示,在负载均衡实例下绑定不同可用区的ECS实例。正常情况下,用户访问流量将同时转至发主、备可用区内的ECS实例;当可用区A发生故障时,用户访问流量将只转发至备可用区内的ECS实例。此种部署既可以避免因为单个可用区的故障而导致对外服务的不可用,也可以通过不同产品间可用区的选择来降低延迟。
如果采取如下图所示的部署方案,即在负载均衡实例的主可用区下绑定多台ECS实例,而在备可用区没有任何ECS实例。当主可用区发生故障时会造成业务中断,因为备可用区没有ECS实例来接收请求。这样的部署方式很明显是以牺牲高可用性为代价来获取低延时。
跨地域容灾
您可以在不同地域下部署负载均衡实例,并分别挂载相应地域内不同可用区的ECS。上层利用云解析做智DNS,将域名解析到不同地域的负载均衡实例服务地址下,可实现全局负载均衡。当某个地域出现不可用时,暂停对应解析即可实现所有用户访问不受影响。
LVS应用场景
音视频大流量场景
动静请求分离,快速稳定交付
游戏业务有很多图片等静态资源需要加载,通过CDN实现全球用户访问静态资源的加速;当用户在游戏中有互动
时,产生的访问流量非常大,此时为了保证互动实时性,需要使用负载均衡进行流量分发
动态请求流量分发
动态请求量大,采用多台云服务器计算处理,并利用负载均衡服务随时进行流量分发
静态请求快速加载
静态内容选择对象存储,接入CDN服务,进一步优化内容分发链路,让内容即刻加载
多层次容灾架构场景
跨地域跨可用区的容灾方案
用户业务遍布各地域,使用云解析DNS将不同地域用户智能解析访问到相应的业务系统内,使用负载均衡进行海量的访问流量分发,还可构建地域级、可用区级的多层容灾架构
智能解析
智能判断提供最佳的访问解析地址,使访问用户获得最快捷、最流畅的体验
流量分发
业务发展快,访问流量巨大,负载均衡可对多台云服务器进行流量分发服务
多层次容灾
云解析提供跨地域的高可用,负载均衡可实现可用区级的高可用
海量访问流量分发场景
LVS集群类型中的术语
- VS: Virtual Server, Director Server(DS), Dispatcher(调度器),Load Balancer
- RS: Real Server(Ivs), 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集群的工作模式
- Ivs-nat:修改请求报文的目标IP,多目标IP的DNAT
- Ivs-dr:操纵封装新的MAC地址
- Ivs-tun:在原请求IP报文之外新加一个IP首部
- Ivs-fullnat:修改请求报文的源和目标IP
LVS的NAT模式
LVS-NAT:本质是多目标IP的DNAT,通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和PORT实现转发
- RIP和DIP应在同一个IP网络,且应使用私网地址; RS的网关要指向DIP
- 请求报文和响应报文都必须经由Director转发,Director易于成为系统瓶颈
- 支持端口映射,可修改请求报文的目标PORT
- VS必须是Linux系统,RS可以是任意OS系统
(1)当用户请求到达DirectorServer,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。
(2) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链。
(3) IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP ,在这个过程完成了目标IP的转换。
(4) POSTROUTING链通过选路,将数据包发送给Real Server。
(5) Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP 。
(6) Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP。
如图所示,NAT模式中的一大缺点就是无论是请求的数据包,还是返回的数据包,都必须要经过负载的这个点,请求的数据包一般内容较少,问题不是很大,而返回的数据包,一般都是图片,视频等等,这会给中间的调度器带来巨大的负担。
LVS的DR模式
LVS-DR: Direct Routing,直接路由,LVS默认模式,应用最广泛,通过为请求报文重新封装一个MAC首部进行转发,源MAC是DIP所在的接口的MAC,目标MAC是某挑选出的RS的RIP所在接口的MAC地址; 源IP/PORT,以及目标IP/PORT均保持不变
Director和REAL SERVER都配置同一个IP(VIP),Director将该IP配置到对外的网卡上,Real server将该IP配置到lo网卡上。配置arp_ignore为1(目的是让数据包发出apr请求时,只有Director会响应该arp请求),所有REAL SERVER对本身这个IP的ARP请求保持静默。而Director收到数据包后根据调度算法,找出对应的 REAL SERVER,把目的MAC地址改为REAL SERVER的MAC并发给这台REAL SERVER。这时REAL SERVER通过网卡eth0收到这个数据包,由于Real Server上的lo网卡配置的也有VIP,所以RS接收该数据包。处理后直接返回给客户端(这里要配置arp_announce,目的是修改返回数据包的源ip地址。)。由于DR要对二层包头进行改换,所以DR和REAL SERVER之间必须在一个广播域,也可以简单的理解为在同一台交换机上。
- 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP;
- PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链;
- IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址;
- 由于DS和RS在同一个网络中,所以是通过二层,数据链路层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server;
- RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP;
- 响应报文最终送达至客户端。
DR模式的特点:
Director和各RS都配置有VIP
确保前端路由器将目标IP为VIP的请求报文发往Director
- 在前端网关做静态绑定VIP和Director的MAC地址
- 在RS上使用arptables工具
1
2arptables -A IN -d $VIP -j DROP
arptables -A OUT -S $VIP -j mangle --mangle-ip-s $RIP- 在RS上修改内核参数以限制arp通告及应答级别
1
2/proc/sys/net/ipv4/conf/a11/arp_ignore
/proc/sys/net/ipv4/conf/a11/arp_announceRS的RIP可以使用私网地址,也可以是公网地址; RIP与DIP在同一IP网络; RIP的网关不能指向DIP,以确保响
应报文不会经由DirectorRS和Director要在同一个物理网络
请求报文要经由Director,但响应报文不经由Director,而由RS直接发往Client
不支持端口映射(端口不能修败)
RS可使用大多数OS系统
LVS的TUN模式
转发方式:不修改请求报文的IP首部(源IP为CIP,目标IP为VIP) ,而在原IP报文之外再封装一个IP首部 (源IP是DIP,目标IP是RIP) ,将报文发往挑选出的目标RS; RS直接响应给客户端(源IP是VIP, 目标IP是CIP)
1.客户端将请求发往前端的负载均衡器,请求报文源地址是CIP,目标地址为VIP。
2.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP,目标地址改为RIP,并将此包发送给RS。
3.RS收到请求报文后,会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP,所以会处理次请求报文,并将响应报文通过lo接口送给eth0网卡(这个网卡一般指和调度器在一个网段的网卡)直接发送给客户端。注意:需要设置lo接口的VIP不能在公网上出现。
TUN模式特点:
- DIP, VIP, RIP可以是公网地址
- RS的网关一般不能指向DIP
- 请求报文要经由Director,但响应不经由Director
- 不支持端口映射
- RS的OS须支持隧道功能
LVS的FULLNAT模型
通过同时修改请求报文的源IP地址和目标IP地址进行转发
CIP –> DIP
VIP –> RIP
fullnat模式特点:
- VIP是公网地址,RIP和DIP是私网地址,且通常不在同一IP网络;因此,RIP的网关一般不会指向DIP
- RS收到的请求报文源地址是DIP,因此,只需响应给DIP;但Director还要将其发往Client
- 请求和响应报文都经由Director
- 支持端口映射
**注意:**此类型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 |
Ivs-nat与Ivs-fullnat:
- 请求和响应报文都经由Director
- lvs-nat: RIP的网关要指向DIP
- Ivs-fullnat: RIP和DIP未必在同一IP网络, 但要能通信
Ivs-dr与Ivs-tun: .
- 请求报文要经由Director,但响应报文由RS直接发往Client
- lvs-dr: 通过封装新的MAC首部实现,通过MAC网络转发
- Ivs-tun: 通过在原IP报文外封装新IP头实现转发,支持远距离通信
LVS调试算法
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, 典型使用场景是正向代理缓存场景中的负载均衡,如:宽带运营商
动态方法
主要根据每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
内核4.15版本后新增调度算法 FO和OFV
FO (Weighted Fail Over)调度算法,在此FO算法中,遍历虚拟服务所关联的真实服务器链表,找到还未过载(未
设置IP_ VS_ DEST_ F_OVERLOAD标志)的且权重最高的真实服务器,进行调度
OVF (Overflow-connection) 调度算法,基于真实服务器的活动连接数量和权重值实现。将新连接调度到权重值
最高的真实服务器,直到其活动连接数量超过权重值,之后调度到下一个权重值最高的真实服务器,在此OVF算法中,遍历虚拟服务相关联的真实服务器链表,找到权重值最高的可用真实服务器。一个可用的真实服务器需要同时满足以下条件:
- 未过载(未设置IP. _VS_ DEST. F_OVERLOAD标志)
- 真实服务器当前的活动连接数量小于其权重值
- 其权重值不为零
LVS相关软件
程序包:ipvsadm
- Unit File: ipvsadm.service
- 主程序: /usr/sbin/ipvsadm
- 规则保存工具: /usr/sbin/ipvsadm-save
- 规则重载工具: /usr/sbin/ipvsadm-restore
- 配置文件: /etc/sysconfig/ipvsadm-config
- ipvs调度规则文件:/etc/sysconfig/ipvsadm
ipvsadm命令
ipvsadm核心功能:
- 集群服务管理:增、删、改
- 集群服务的RS管理:增、删、改
- 查看
ipvsadm工具用法:
1 | #管理集群服务 |
管理集群服务:增、改、删
增、修改: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]:指定集群的调度算法,默认为wIc
管理集群上的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,不作端口映射
选项: .
- Ivs类型:
- -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
1 | ipvsadm-save > /PATH/TO/IPVSADM_FILE |
重载:
1 | ipvsadm-restore < /PATH/FROM/IPVSADM_FILE |
防火墙标记
FWM: FireWall Mark
MARK target可用于给特定的报文打标记
–set-mark value
其中: value 可为0fff格式,表示十六进制数字
借助于防火墙标记来分类报文,而后基于标记定义集群服务;可将多个不同的应用使用同一个集群服务进行调度
实现方法:
在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]
范例
1 | [root@lvs ~]#ipvsadm -A -f 10 |
LVS持久连接
session绑定:对共享同一组RS的多个集群服务,需要统一进行绑定,Ivs sh算法无法实现持久连接( Ivs persistence )模板:实现无论使用任何调度算法,在一段时间内(默认360s) ,能够实现将来自同一个地址的请求始终发往同一个RS
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]
持久连接实现方式:
- 每端口持久(PPC) :每个端口定义为一个集群服务,每集群服务单独调度
- 每防火墙标记持久(PFWMC) :基于防火墙标记定义集群服务;可实现将多个端口上的应用统一调度,即所谓的port Affinity
- 每客户端持久(PCC) :基于0端口(表示所有服务)定义集群服务,即将客户端对所有应用的请求都调度至后端主机,必须定义为持久模式
范例
1 | [root@1vs ~]#ipvsadm -E -f 10 -p |
LVS实战案例
LVS-NAT模式案例
- Director服务器采用双网卡, 一个是桥接网卡连接外网,一个是仅主机网卡与后端Web服务器相连
- Web服务器采用仅主机网卡与director相连
- Web服务器网关指向10.0.0.200
- 后端web服务器不需要连接外网
范例:
环境:
1 | 共四台主机 |
配置过程:
1 | 配置过程 |
LVS-DR单网段模式案例
DR模型中各主机上均需要配置VIP,解决地址冲突的方式有3种:
(1)在前端网关做静态绑定
(2)在各RS使用arptables
(3)在各RS修改内核参数,来限制arp响应和通告的级别
限制响应级别: arp_ignore
- 0:默认值,不管哪块网卡接收到了ARP请求,只要发现本机有这个MAC都给与响应
- 1:仅在请求的目标IP配置在本地主机的接收到请求报文的接口上时,才给予响应
限制通告级别: arp_announce
- 0:默认值,把本机所有接口的所有信息向每个接口的网络进行通告
- 1:尽量避免将接口信息向非直接连接网络进行通告
- 2:必须避免将接口信息向非本网络进行通告
配置要点
- Director服务器采用双IP桥接网络,一个是VIP,一个DIP
- Web服务器采用和DIP相同的网段和Director连接
- 每个Web服务器配置VIP
- 每个web服务器可以出外网
范例:
1 | 环境:五台主机 |
配置过程
1 | #在LVS服务器上实现 |
LVS-DR多网段模式实例
以下脚本只是为了实验方便,临时有效,并未写到配置文件中!
1 | cat lvs_dr_rs.sh |
1 | cat lvs_dr_vs.sh |
LVS高可用性实现
LVS不可用时
Director不可用,整个系统将不可用; SPoF Single Point of Failure
解决方案:高可用,keepalived、heartbeat/corosync
RS不可用时
某RS不可用时,Director依然会调度请求至此RS
解决方案:由Director对各RS健康状态进行检查, 失败时禁用,成功时启用
常用解决方案:
- keepalived
- heartbeat/corosync
- ldirectord
检测方式:
- 网络层检测,icmp
- 传输层检测,端口探测
- 应用层检测,请求某关键资源
RS全不用时: backup server, sorry server
目前企业中主流使用的是keepalived,请参看此篇博客: