热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

LVS中DR模式的负载均衡及高可用

**一LVS的三种IP负载均衡技术比较**我们先分析实现虚拟网络服务的主要技术,指出IP负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术

**

一 LVS的三种IP负载均衡技术比较

**
我们先分析实现虚拟网络服务的主要技术,指出IP负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术中,主要有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器,我们称之为VS/NAT技术(Virtual Server via Network Address Translation)。在分析VS/NAT的缺点和网络服务的非对称性的基础上,我们提出了通过IP隧道实现虚拟服务器的方法VS/TUN (Virtual Server via IP Tunneling),和通过直接路由实现虚拟服务器的方法VS/DR(Virtual Server via Direct Routing),它们可以极大地提高系统的伸缩性。VS/NAT、VS/TUN和VS/DR技术是LVS集群中实现的三种IP负载均衡技术。
下面是这三种IP负载均衡技术的优缺点
这里写图片描述
注:以上三种方法所能支持最大服务器数目的估计是假设调度器使用 100M 网卡,调度器的硬件配置与后端服务器的硬件配置相同,而且是对一般 Web 服 务。使用更高的硬件配置(如千兆网卡和更快的处理器)作为调度器,调度器所能调度的服务器数量会相应增加。当应用不同时,服务器的数目也会相应地改变。所 以,以上数据估计主要是为三种方法的伸缩性进行量化比较。

VS/NAT
VS/NAT 的优点是服务器可以运行任何支持 TCP/IP 的操作系统,它只需要一个 IP 地址配置在调度器上,
服务器组可以用私有的 IP 地址。缺点是它的伸缩能力有限, 当服务器结点数目升到 20 时,调度器本身
有可能成为系统的新瓶颈,因为在 VS/NAT 中请求和响应报文都需要通过负载调度器。
VS/TUN
VS/TUN 技术对服务器有要求,即所有的服务器必须支持 “ IP Tunneling” 或者 “ IPEncapsulation”协议。目前,VS/TUN 的后端服务器主要运行 Linux 操作系统。在 VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调 度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有 100Mbps的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。所以,VS/TUN 可以极大地增加负载调度器调度的服务器数量。VS/TUN 调度器可以调度上百台服务器,而它本身不会成为系统的瓶
颈,可以 用来构建高性能的超级服务器。
VS/DR
跟 VS/TUN 方法相同,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提
高整个集群系统的吞吐量。跟 VS/TUN 相比,这种方法没有 IP 隧道的开销,但调度器和服务器组都必
须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的 HUB 相连。VIP 地址为调
度器和服务器组共享,调度器配置的 VIP 地址是对外可见的,用于接收虚拟服务的请求报文;所有的服
务器把 VIP 地址配置在各自的 Non-ARP 网络设备上,它对外面是不可见的,只是用于处 理目标地址为
VIP 的网络请求。

**

二 lvs的DR模式

**

下面用图文的方式中介绍一下DR模式
这里写图片描述
结合上图来做一个基本原理的说明:
Director 接收用户的请求,然后根据负载均衡算法选取一台 realserver,将包转发
过去,最后由 realserver 直接回复给用户。

1 client 向目标 vip 发出请求,Director 接收。
2 VS 根据负载均衡算法选择一台 active 的 realserver(假设是 172.25.1.3),将此 RIP 所在网
卡的 mac 地址作为目标 mac 地址,发送到局域网里。
3 realserver(172.25.1.3)在局域网中收到这个帧,拆开后发现目标 IP(VIP)与本地匹配,于是
处理这个报文。随后重新封装报文,发送到局域网。
4 如果 client 与 VS 同一网段,那么 client(172.25.1.250)将收到这个回复报文。如果跨了网段,
那么报文通过 gateway/路由器经由 Internet 返回给用户。

注意的问题:
vs/dr 本身不会关心 IP 层以上的信息,即使是端口号也是 tcp/ip 协议栈去判断是否正确,vs/dr 本
身主要做这么几个事:
1)接收 client 的请求,根据你设定的负载均衡算法选取一台 realserver 的 ip;
2)以选取的这个 ip 对应的 mac 地址作为目标 mac,然后重新将 IP 包封装成帧转发给这台 RS;
3)在 hashtable 中记录连接信息。
vs/dr 做的事情很少,也很简单,所以它的效率很高,不比硬件负载均衡设备差多少。
数据包、数据帧的大致流向是这样的:client –> VS –> RS –> client
vs主要作为目标地址mac地址转发而这一过程在数据链路层来实现的,所以 director 必须和 RS 在同一网段里面。

2 实验测试:
2.1 环境介绍
Load Balance:172.25.1.2
Virtual IP: 172.25.1.100
Realserver1: 172.25.1.3
Realserver1: 172.25.1.4
2.2实验步骤
1)安装ipvsadm
这里写图片描述
/etc/init.d/ipvsadm start
2 ) vs临时配置
ipvsadm -A -t 172.25.1.100:80 -s rr
-A - t添加虚拟虚拟服务为tcp模式,virtualIP为172.25.1.100轮询的机制为轮询
这里写图片描述
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.4:80 -g
-a -t 添加rs IP 172.25.1.4 端口80
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.4:80 -g
ipvsadm -ln 查看策略
这里写图片描述
ip addr add 172.25.1.100/24 dev eth0 绑定vip到eth0网卡上
这里写图片描述
3)rs临时配置
ip addr add 172.25.1.100/32 dev lo
这里写图片描述
这里有两点原因

1 既然要让 RS 能够处理目标地址为 vip 的 IP 包,首先必须要让 RS 能接收到这个包。
在 lo 上配置 vip 能够完成接收包并将结果返回 client。
2 不可以将 VIP 设置在出口网卡eth0上,否则会响应客户端的 arp request,造成 client/gateway
arp table 紊乱,以至于整个 loadbalance 都不能正常工作。

arptables -A IN -d 172.25.1.100 -j DROP 将所有访问172.25.1.100的请求都丢弃
arptables -A OUT -s 172.25.1.100 -j mangle –mangle-ip-s 172.25.1.4 将172.25.1.100地址的转为目标地址172.25.1.4向外发出
arptables -nL 输出地址查看策略
这里写图片描述

安装httpd服务更好展现实验效果
yum install httpd -y
编写httpd发布文件
vim /var/www/html/index.html
这里写图片描述
4 )客户端测试
这里写图片描述
查看rs server3的mac地址
这里写图片描述
结果分析:说明了vs主要工作就是实现目标MAC地址转发!
2.3 负载均衡
如果增加了n台rs服务器,这个时候就需要负载均衡技术了
1)再增加了一台rs 2 配置和上面一样,这里就不做演示了
2)主机测试
这里写图片描述
结果分析:在vs中配置的-s rr轮询可以看出
这个时候有个问题就是如果后端的web服务done掉了,vs不会发现,这在生产活动中是不允许的!这就需要做健康检查
2.4 工具的健康检查
1) 安装软件
yum install ldirectord-3.9.5-3.1.x86_64.rpm
这里写图片描述
2)可能安装的时候会出现安装不了的情况,针对红帽的软件来说,我们需要对yum源进行配置
这里写图片描述
3 )启动服务
/etc/init.d/ldirectord start
4)查看配置文件
rpm -ql ldirectord
这里写图片描述
cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d/
vim /etc/ha.d/ldirectord.cf

virtual=172.25.1.100:80real=172.25.1.3:80 gatereal=172.25.1.4:80 gatefallback=127.0.0.1:80 gateservice=httpscheduler=rr#persistent=600#netmask=255.255.255.255protocol=tcpchecktype=negotiatecheckport=80request="index.html"#receive="Test Page" #必须要注释掉#virtualhost=www.x.y.z

/etc/init.d/ldirectord reload
/etc/init.d/ldirectord restart
5)为了看出ldirectord的工作模式,把rs上手动添加的vip手动去掉
ip addr del 172.25.1.100/32 dev lo
只要你重新启动服务就可以看见ip会继续出现lo接口上
6)这个时候假如你done掉rs一个web,你在调度器上查看策略

这里写图片描述
这个时候你可能还会有个问题就是,万一调度器也坏掉了,系统不是就瘫痪了?
下面接下来说的就是
2.5 LVS +keepalived 高可用集群
这里写图片描述
1)源码安装三部曲
tar zxf keepalived-2.0.6.tar.gz
cd keepalived-2.0.6
yum install rpm-build.x86_64
yum install gcc -y
yum install openssl-devel
./configure –prefix=/usr/local/keepalived
./configure –prefix=/usr/local/keepalived –with-init=SYSV
make
make install
这里写图片描述
ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/keepalived/etc/keepalived /etc/
ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin
这里写图片描述
2 )关闭ldirectord服务,在某些功能上和keepalived冲突
这里写图片描述
/etc/init.d/keepalived start
2)编写配置文件 主备模式
vim /etc/keepalived/keepalived.conf

! Configuration File for keepalivedglobal_defs {notification_email {root@localhost
}notification_email_from keepalived@localhost smtp_server 127.0.0.1 #设置 smtp server 地址smtp_connect_timeout 30 #设置连接 smtp 服务器超时时间router_id LVS_DEVEL #load balancer 的标识 ID,用于 email 警报vrrp_skip_check_adv_addr#vrrp_strictvrrp_garp_interval 0vrrp_gna_interval 0
}vrrp_instance VI_1 {state MASTER #备机改为 BACKUP,此状态是由 priority 的值来决定的,当前#priority 的值小于备机的值,那么将会失去 MASTER 状态interface eth0 #HA 监测网络接口virtual_router_id 51 #主、备机的 virtual_router_id 必须相同,取值 0-255priority 100 #主机的优先级,备份机改为 50,主机优先级一定要大于备机advert_int 1 #主备之间的通告间隔秒数authentication { #主备切换时的验证auth_type PASS #设置验证类型,主要有 PASS 和 AH 两种auth_pass 1111 #设置验证密码,在一个 vrrp_instance 下,MASTER 与 BACKUP 必#须使用相同的密码才能正常通信}virtual_ipaddress { #设置虚拟 IP 地址,可以设置多个虚拟 IP 地址,每行一个172.25.1.100}
}
virtual_server 172.25.1.100 80 { #定义虚拟服务器delay_loop 6 #每隔 6 秒查询 realserver 状态lb_algo rr #lvs 调度算法,这里使用轮叫lb_kind DR LVS 是用 DR 模式#persistence_timeout 50 #会话保持时间,单位是秒,这个选项对于动态网页是非常有
用的,为集群系统中 session 共享提供了一个很好的解决方案。有了这个会话保持功能,用户的
请求会被一直分发到某个服务节点,直到超过这个会话保持时间。需要注意的是,这个会话保
持时间,是最大无响应超时时间,也就是说用户在操作动态页面时,如果在 50 秒内没有执行任
何操作,那么接下来的操作会被分发到另外节点,但是如果一直在操作动态页面,则不受 50
的时间限制。protocol TCP #指定转发协议类型,有 tcp 和 udp 两种real_server 172.25.1.3 80 { #配置服务节点weight 1 #配置服务节点的权值,权值大小用数字表示,数字越大,权
值越高,设置权值的大小可以为不同性能的服务器分配不同的负载,可以对性能高的服务器设
置较高的权值,而对性能较低的服务器设置相对较低的权值,这样就合理的利用和分配了系统
资源TCP_CHECK { #realserve 的状态检测设置部分,单位是秒connect_timeout 3 #10 秒无响应超时retry 3 #重试次数delay_before_retry 3 #重试间隔}}real_server 172.25.1.4 80 {weight 1TCP_CHECK {connect_timeout 3retry 3delay_before_retry 3}}
}

3)增加一台调度器服务器作如下的配置

! Configuration File for keepalivedglobal_defs {notification_email {root@localhost
}notification_email_from keepalived@localhostsmtp_server 127.0.0.1smtp_connect_timeout 30router_id LVS_DEVELvrrp_skip_check_adv_addr#vrrp_strictvrrp_garp_interval 0vrrp_gna_interval 0
}vrrp_instance VI_1 {state BACKUPinterface eth0virtual_router_id 51priority 50advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {172.25.1.100}
}
virtual_server 172.25.1.100 80 {delay_loop 6lb_algo rrlb_kind DR#persistence_timeout 50protocol TCPreal_server 172.25.1.3 80 {weight 1TCP_CHECK {connect_timeout 3retry 3delay_before_retry 3}}real_server 172.25.1.4 80 {weight 1TCP_CHECK {connect_timeout 3retry 3delay_before_retry 3}}
}

/etc/init.d/keepalived reload
/etc/init.d/keepalived restart
4 )高可用测试:停止 master 上的 keepalived 服务,会发现客户端仍然可以访问。


推荐阅读
  • WebSocket与Socket.io的理解
    WebSocketprotocol是HTML5一种新的协议。它的最大特点就是,服务器可以主动向客户端推送信息,客户端也可以主动向服务器发送信息,是真正的双向平等对话,属于服务器推送 ... [详细]
  • 提升Python编程效率的十点建议
    本文介绍了提升Python编程效率的十点建议,包括不使用分号、选择合适的代码编辑器、遵循Python代码规范等。这些建议可以帮助开发者节省时间,提高编程效率。同时,还提供了相关参考链接供读者深入学习。 ... [详细]
  • Linux服务器密码过期策略、登录次数限制、私钥登录等配置方法
    本文介绍了在Linux服务器上进行密码过期策略、登录次数限制、私钥登录等配置的方法。通过修改配置文件中的参数,可以设置密码的有效期、最小间隔时间、最小长度,并在密码过期前进行提示。同时还介绍了如何进行公钥登录和修改默认账户用户名的操作。详细步骤和注意事项可参考本文内容。 ... [详细]
  • 图解redis的持久化存储机制RDB和AOF的原理和优缺点
    本文通过图解的方式介绍了redis的持久化存储机制RDB和AOF的原理和优缺点。RDB是将redis内存中的数据保存为快照文件,恢复速度较快但不支持拉链式快照。AOF是将操作日志保存到磁盘,实时存储数据但恢复速度较慢。文章详细分析了两种机制的优缺点,帮助读者更好地理解redis的持久化存储策略。 ... [详细]
  • Python瓦片图下载、合并、绘图、标记的代码示例
    本文提供了Python瓦片图下载、合并、绘图、标记的代码示例,包括下载代码、多线程下载、图像处理等功能。通过参考geoserver,使用PIL、cv2、numpy、gdal、osr等库实现了瓦片图的下载、合并、绘图和标记功能。代码示例详细介绍了各个功能的实现方法,供读者参考使用。 ... [详细]
  • 深入理解Kafka服务端请求队列中请求的处理
    本文深入分析了Kafka服务端请求队列中请求的处理过程,详细介绍了请求的封装和放入请求队列的过程,以及处理请求的线程池的创建和容量设置。通过场景分析、图示说明和源码分析,帮助读者更好地理解Kafka服务端的工作原理。 ... [详细]
  • 微软评估和规划(MAP)的工具包介绍及应用实验手册
    本文介绍了微软评估和规划(MAP)的工具包,该工具包是一个无代理工具,旨在简化和精简通过网络范围内的自动发现和评估IT基础设施在多个方案规划进程。工具包支持库存和使用用于SQL Server和Windows Server迁移评估,以及评估服务器的信息最广泛使用微软的技术。此外,工具包还提供了服务器虚拟化方案,以帮助识别未被充分利用的资源和硬件需要成功巩固服务器使用微软的Hyper - V技术规格。 ... [详细]
  • 云原生边缘计算之KubeEdge简介及功能特点
    本文介绍了云原生边缘计算中的KubeEdge系统,该系统是一个开源系统,用于将容器化应用程序编排功能扩展到Edge的主机。它基于Kubernetes构建,并为网络应用程序提供基础架构支持。同时,KubeEdge具有离线模式、基于Kubernetes的节点、群集、应用程序和设备管理、资源优化等特点。此外,KubeEdge还支持跨平台工作,在私有、公共和混合云中都可以运行。同时,KubeEdge还提供数据管理和数据分析管道引擎的支持。最后,本文还介绍了KubeEdge系统生成证书的方法。 ... [详细]
  • CSS3选择器的使用方法详解,提高Web开发效率和精准度
    本文详细介绍了CSS3新增的选择器方法,包括属性选择器的使用。通过CSS3选择器,可以提高Web开发的效率和精准度,使得查找元素更加方便和快捷。同时,本文还对属性选择器的各种用法进行了详细解释,并给出了相应的代码示例。通过学习本文,读者可以更好地掌握CSS3选择器的使用方法,提升自己的Web开发能力。 ... [详细]
  • 本文讨论了如何在codeigniter中识别来自angularjs的请求,并提供了两种方法的代码示例。作者尝试了$this->input->is_ajax_request()和自定义函数is_ajax(),但都没有成功。最后,作者展示了一个ajax请求的示例代码。 ... [详细]
  • Spring常用注解(绝对经典),全靠这份Java知识点PDF大全
    本文介绍了Spring常用注解和注入bean的注解,包括@Bean、@Autowired、@Inject等,同时提供了一个Java知识点PDF大全的资源链接。其中详细介绍了ColorFactoryBean的使用,以及@Autowired和@Inject的区别和用法。此外,还提到了@Required属性的配置和使用。 ... [详细]
  • SpringMVC接收请求参数的方式总结
    本文总结了在SpringMVC开发中处理控制器参数的各种方式,包括处理使用@RequestParam注解的参数、MultipartFile类型参数和Simple类型参数的RequestParamMethodArgumentResolver,处理@RequestBody注解的参数的RequestResponseBodyMethodProcessor,以及PathVariableMapMethodArgumentResol等子类。 ... [详细]
  • python限制递归次数(python最大公约数递归)
    本文目录一览:1、python为什么要进行递归限制 ... [详细]
  • JavaWeb中读取文件资源的路径问题及解决方法
    在JavaWeb开发中,读取文件资源的路径是一个常见的问题。本文介绍了使用绝对路径和相对路径两种方法来解决这个问题,并给出了相应的代码示例。同时,还讨论了使用绝对路径的优缺点,以及如何正确使用相对路径来读取文件。通过本文的学习,读者可以掌握在JavaWeb中正确找到和读取文件资源的方法。 ... [详细]
  • Servlet多用户登录时HttpSession会话信息覆盖问题的解决方案
    本文讨论了在Servlet多用户登录时可能出现的HttpSession会话信息覆盖问题,并提供了解决方案。通过分析JSESSIONID的作用机制和编码方式,我们可以得出每个HttpSession对象都是通过客户端发送的唯一JSESSIONID来识别的,因此无需担心会话信息被覆盖的问题。需要注意的是,本文讨论的是多个客户端级别上的多用户登录,而非同一个浏览器级别上的多用户登录。 ... [详细]
author-avatar
水果jia
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有