LVS集群

原创

小慕萌仔 2019-04-09 19:33:40 博主文章分类：云计算文档 ©著作权

文章标签 HA LB 文章分类 运维

©著作权归作者所有：来自51CTO博客作者小慕萌仔的原创作品，请联系作者获取转载授权，否则将追究法律责任

1/34 LVS集群如何提升服务器性能? 1、增加服务器硬件如CPU、内存或换配置更高的服务器来提升单机的性能很快会达到瓶颈, 而且成本和性能不成正比 2、应用分离主机A(Apache) + 主机B(MySQL) 依然会达到瓶颈 3、采用集群技术 LB Load Balancing 负载均衡 HA High Availability 高可用 HPC High Performance Computing 高性能计算分布式集群

整个提供一个唯一的访问入口,对最终用户透明！！！＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ HA 又称双机 Active/Standby,即一个提供服务,另一个保持等待状态,至少两台服务器； LB 是负载均衡,即两个服务器同时提供相同的服务,并分担压力,但是至少三台服务器; HPC 简单的说,高性能计算(High-Performance Computing)是计算机科学的一个分支,它致力于开发超级计算机,研究并行算法和开发相关软件。高性能集群主要用于处理复杂的计算问题,应用在需要大规模科学计算的环境中,如天气预报、石油勘探与油藏模拟、分子模拟、基因测序等。高性能集群上运行的应用程序一般使用并行算法,把一个大的普通问题根据一定的规则分为许多小的子问题,在集群内的不同节点上进行计算,而这些小问题的处理结果,经过处理可合并为原问题的最终结果。由于这些小问题的计算一般是可以并行完成的,从而可以缩短问题的处理时间。 HA集群 1.keepalived 基于vrrp协议,常用于实现前端代理的高可用, 轻量级, 不需要共享存储 2.corosync+pacemaker 实现的是Service的高可用, 需要共享存储, 一般用于多个节点 3.Heartbeat 是基于主机或网络的服务的高可用方式, 不常用 LB集群 A.硬件: F5 BIG-IP 性能好,成本高 B.软件: LVS Nginx Haproxy

LB集群三大主流软件负载均衡器对比(LVS --- Nginx --- Haproxy) 2/34 LVS：由中国的章文嵩博士开发，他就职于阿里巴巴集团。 1、抗负载能力强。抗负载能力强、性能高,能达到F5硬件的60%；对内存和cpu资源消耗比较低 2、工作在网络4层(传输层),通过vrrp协议转发(仅作分发之用),具体的流量由linux内核处理,因此没有流量的产生。 3、稳定性、可靠性好,自身有完美的热备方案；(如：LVS+Keepalived) 4、应用范围比较广,可以对所有应用做负载均衡；因为他是通过修改网络数据包中的端口号、IP地址来实现负载均衡的，跟上层应用无直接关系。 5、不支持正则处理,不能做动静分离。(只有应用层(即七层)的负载均衡才支持正则处理) 6、支持负载均衡算法：rr(轮循、轮询)、wrr(带权轮循)、lc(最小连接)、wlc(权重最小连接) 7、配置复杂,对网络依赖比较大,稳定性很高。[这里说的配置复杂是跟nginx的负载均衡来做对比] LVS是通过修改数据包中的端口号、IP地址、MAC地址来实现负载均衡。高可用(HA:High Availability)：高度可用，通常是指服务器集群中有主(master)、备(backup)关系，当主出现主故障，自动会由备(backup)来接管任务。 Ngnix： 1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名(server_name)、目录结构(用location、rewrite功能来实现)； 2、Nginx对网络的依赖比较小,理论上nginx负载均衡器能ping通后端的真实web服务器就能进行负载功能； 3、Nginx安装和配置比较简单,测试起来比较方便； 4、也可以承担高的负载压力且稳定,一般能支撑超过1万次(C10K)的并发； 5、对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测。 6、Nginx对请求的异步处理可以帮助节点服务器减轻负载； 7、Nginx仅能支持http、https和Email协议,这样就在适用范围较小。 8、不支持Session的直接保持,但能通过ip_hash来解决。 9、支持负载均衡算法：Round-robin(轮循),Weight-round-robin(带权轮循),Ip-hash(Ip哈希) 10、Nginx还能做Web服务器即Cache功能。 HAProxy： 1、支持两种代理模式：TCP(四层)和HTTP(七层),支持虚拟主机； 2、能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作 3、支持url检测后端的服务器出问题的检测会有很好的帮助。 4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现 5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。 6、HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡。 7、支持负载均衡算法：Round-robin(轮循)、Weight-round-robin(带权轮循)、source(原地址保持)、 RI(请求URL)、rdp-cookie(根据cookie) 8、不能做Web服务器和Cache。 Cookie功能：是由web浏览器提供的功能，主要用来记录用户在网页界面表单中输入的用户名、密码等信息。可以让用户在下次访问网站时不用输入用户名和密码。 1.cookie数据存放在客户的浏览器上，session数据放在服务器上 2.cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session 3.session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE 4.单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。 3/34 5.将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中 Cache的工作原理是保存CPU最常用数据当Cache中保存着CPU要读写的数据时CPU直接访问Cache。由于 Cache的速度与CPU相当CPU就能在零等待状态下迅速地实现数据存取，Cache由标记存储器和数据存储器两个基本部分组成,作用是解决系统中数据读写速度不匹配的问题,cache规模小访问速度快，Cache可以高效地完成DRAM内存和CPU之间的速度匹配。缓冲寄存器又称缓冲器，它分输入缓冲器和输出缓冲器两种。前者的作用是将外设送来的数据暂时存放，以便处理器将它取走；后者的作用是用来暂时存放处理器送往外设的数据。有了数控缓冲器，就可以使高速工作的CPU与慢速工作的外设起协调和缓冲作用，实现数据传送的同步。由于缓冲器接在数据总线上，故必须具有三态输出功能 buffer功能有添加功能，删除功能，替换功能，反转功能三大主流软件负载均衡器适用业务场景： 1、网站建设初期,可以选用Nginx/HAproxy作为反向代理负载均衡(或者流量不大都可以不选用负载均衡 ),因为其配置简单,性能也能满足一般的业务场景。如果考虑到负载均衡器是有单点问题,可以采用Nginx +Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。 2、网站并发达到一定程度之后,为了提高稳定性和转发效率,可以使用LVS、毕竟LVS比Nginx/HAproxy 要更稳定,转发效率也更高。不过维护LVS对维护人员的要求也会更高,投入成本也更大。注：Nginx与Haproxy比较：Nginx支持七层,用户量最大,稳定性比较可靠。Haproxy支持四层和七层,支持更多的负载均衡算法,支持session保存等。具体选型看使用场景,目前来说Haproxy由于弥补了一些Nginx的缺点用户量也不断在提升。衡量一个负载均衡服务器主要考量三个指标:

session rate(会话率) 此项指标非常重要,它决定了一个Load Balancer (负载均衡器)能不能分发所有接受的请求。这项指标通常是由CPU性能决定。测量指标的大小跟传输的每个对象的大小有关,通常用空对象来测试,Session rates 在 100,000 sessions/s 左右,使用 Xeon E5 在 2014测试。
session concurrency(会话并发) 该指标与前一指标相关联。这一指标与服务器内存和系统可以处理的文件描述符(FD:file description) 数量有关。通常每个session占用34KB,即大概3W个session占用1GB内存空间,实际上,socket buffer(套接字缓冲器)也会占用内存空间,2W个session socket占用1GB内存。
data forwarding rate(数据转发率) 这一指标与 session rate 相对立,它的衡量单位通常是 Megabytes/s (MB/s), 或者 Gigabits/s (Gbps)。传输较大的对象有利于该指标的提升,因为较大的对象传输可以减少session建立和关闭浪费的时间。而测量session rate 则在传输小对象时有利于指标提升。haproxy 在2014年使用 Xeon E5 测试成绩为 40 Gbps。 LVS工作原理及流程首先向章文嵩先生致敬 Linux Virtual Server,也就是Linux虚拟服务器，,称LVS 一、LVS 概述 LVS是Linux内核的一部分,因此性能高 Linux虚拟服务器(即分发器或调度器director): 它不真正提供服务,但它接受客户的访问,为整个集群提供一个唯一的入口。虚拟服务器再和真实服务器通信。 4/34 真实服务器(Real Server): 它真正提供服务,集群中每个Real Server可以是一台物理主机,也可以是虚拟机。 LVS相关术语(必记): DS(或DR) ：Director Server调度服务器。指的是前端负载均衡器节点。(相当于餐厅服务员) RS ：Real Server。后端真实的工作服务器。(相当于餐厅的厨师) VIP：Virtual IP虚拟IP，是指向外部直接面向用户请求,作为用户请求的目标的IP地址。(外网IP地址 )(相当于餐厅服务员的左手) DIP：Director Server IP调度服务器IP,主要用于和内部主机通讯的IP地址。(内网IP地址)(相当于餐厅服务员的右手) RIP：Real Server IP,后端服务器的IP地址。 CIP：Client IP,客户端的IP地址。注意：LVS调度器需要有两块网卡，一块是对外(WAN口)的网卡，一块是对内(LAN口)的网卡。客人到餐厅吃饭的点餐流程：食客(Client)－－－>[网卡1：VIP]服务员(DS/DR)[网卡2：DIP]－－－>后厨的厨师(RS) 二、LVS三种模式 VS/NAT：网络地址转换模式, 进站/出站的数据流量经过分发器。NAT模式是通过修改客户请求数据包中的端口号、IP地址来实现负载均衡。 VS/DR ：直接路由模式,只有进站的数据流量经过分发器(数据链路层负载均衡,因为他修改的是目的mac地址) VS/TUN：隧道模式,只有进站的数据流量经过分发器 full-nat : 三、LVS/NAT基本工作原理

LVS的工作过程原理(必须理解记忆)：

当用户向负载均衡调度器（Director Server）发起请求,调度器将请求发往至linux的内核(kernel)空间
PREROUTING链(路由前)首先会接收到用户请求,判断目标IP确定是本机IP,将数据包发往INPUT链
IPVS(ip virtual service)是工作在INPUT链上的,当用户请求到达INPUT时,IPVS会将用户请求和自己已定义好的集群服务(即LVS上用ipvsadm命令定义的负载均衡列表)进行比对,如果用户请求的就是定义的集群服务,那么此时IPVS会强行修改数据包里的目标IP地址及端口,并将新的数据包发往POSTROUTING链(路由后) 5/34
POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器,那么此时通过选路(即路由选择),将数据包最终发送给后端的服务器四、LVS 三种工作模式原理以及优缺点比较 1、NAT模式(VS-NAT) 原理：就是把客户端发来的数据包的IP头的目的地址,在负载均衡器上换成其中一台RS的IP地址,并发至此RS来处理,RS处理完成后把数据交给经过负载均衡器,负载均衡器再把数据包的原IP地址改为自己的IP,将目的地址改为客户端IP地址即可｡期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器｡优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统,只有负载均衡器需要一个合法的IP地址。缺点：扩展性有限。当服务器节点(普通PC服务器)增长过多时,负载均衡器将成为整个系统的瓶颈,因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时,大量的数据包都交汇在负载均衡器那,速度就会变慢！ 2、直接路由模式(VS-DR) 原理：负载均衡器和RS都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有RS对本身这个IP的 ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC(因为IP一致)并将请求分发给这台RS｡这时RS收到这个数据包,处理完成之后,由于IP一致,可以直接将数据返给客户,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上｡优点：和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端。与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。缺点：(不能说缺点,只能说是不足)要求负载均衡器的网卡必须与物理网卡在一个物理段上。 3、IP隧道模式(VS-TUN) 原理：首先要知道,互联网上的大多Internet服务的请求包很短小,而应答包通常很大。那么隧道模式就是,把客户端发来的数据包,封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器｡注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议｡所以,在RS的内核中,必须编译支持IPTUNNEL这个选项优点：负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。缺点：隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation) 协议,服务器可能只局限在部分Linux系统上。三种LVS负载均衡技术的特点归纳以下表： 6/34

点击这里点击这里点击这里点击这里 VS/NAT VS/TUN VS/DR 服务器操作系统　任意支持隧道多数（支持Non-arp）服务器网络私有网络局域网/广域网局域网服务器数目（100M网络） 10~20 100 大于100 服务器网关　负载均衡器自己的路由自己的路由效率一般高最高

LVS命令查ipvsadm由某个rpm包提供：yum provides ipvsadm 查是否安装了：rpm -q ipvsadm 安装：yum install -y ipvsadm

ipvsadm -h 或 man ipvsadm 查命令帮助.man手册中有EXAMPLE例子

ipvsadm v1.27 2008/5/15 (compiled with popt and IPVS v1.2.1) 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 命令选项解释:[蓝字为常用选项] -A --add-service 在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也就是增加一台新的虚拟服务器(VIP)。 -E --edit-service 编辑内核虚拟服务器表中的一条虚拟服务器记录。 -D --delete-service 删除内核虚拟服务器表中的一条虚拟服务器记录。 7/34 -C --clear 清除内核虚拟服务器表中的所有记录。 -R --restore 恢复虚拟服务器规则 -S --save 保存虚拟服务器规则,备份输出为-R 选项可读的格式 -a --add-server 在内核虚拟服务器表的一条记录里添加一条新的真实服务器记录(RIP)。也就是在一个虚拟服务器中增加一台新的真实服务器 -e --edit-server 编辑一条虚拟服务器记录中的某条真实服务器记录 -d --delete-server 删除一条虚拟服务器记录中的某条真实服务器记录 -L|-l --list 显示内核虚拟服务器表 -Z --zero 虚拟服务表计数器清零(清空当前的连接数量等) --set tcp tcpfin udp 设置连接超时值 --start-daemon 启动同步守护进程。他后面可以是master 或backup,用来说明LVS Router 是master 或是backup。在这个功能上也可以采用keepalived 的VRRP 功能。 --stop-daemon 停止同步守护进程 -h --help 显示帮助信息 -p --persistent [timeout] 持久稳固的服务(持久性连接)。这个选项的意思是来自同一个客户的多次请求,将被同一台真实的服务器处理。timeout 的默认值为360 秒。 -t --tcp-service service-address 说明虚拟服务器提供的是tcp 的服务[vip:port] or [real-server-ip:port] -f --fwmark-service fwmark 说明是经过iptables 标记过的服务类型。 -u --udp-service service-address 说明虚拟服务器提供的是udp 的服务[vip:port] or [real-serverip:port] -s --scheduler scheduler 使用的调度算法,有这样几个选项 rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,默认的调度算法是： wlc. -M --netmask netmask persistent granularity mask -r --real-server server-address 真实的服务器[Real-Server:port] -g --gatewaying 指定LVS 的工作模式为直接路由模式(也是LVS 默认的模式) -i --ipip 指定LVS 的工作模式为隧道模式 -m --masquerading 指定LVS 的工作模式为NAT 模式 -w --weight weight 真实服务器的权值 --mcast-interface interface 指定组播的同步接口 -c --connection 显示LVS 目前的连接如：ipvsadm -L -c --timeout 显示tcp tcpfin udp 的timeout 值如：ipvsadm -L --timeout --daemon 显示同步守护进程状态 --stats 显示统计信息 --rate 显示速率信息 --sort 对虚拟服务器和真实服务器排序输出 -n --numeric 输出IP地址和端口的数字形式

ipvsadm实例：man ipvsadm 查看example 1的实例，复制实例中的命令粘贴后得到的结果 ipvsadm -Ln ipvsadm -A -t 207.175.44.110:80 -s rr ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.1:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.2:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.3:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.4:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.5:80 -m ipvsadm -Ln 显示结果如下 8/34

yum install ipvsadm

ipvsadm -A -t 192.168.10.11:80 -s rr

-A --add-service 在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也就是增加一台新的虚拟服务器。 -t --tcp-service service-address 说明虚拟服务器提供的是tcp的服务[vip:port] or [real-serverip:port] -s --scheduler scheduler 使用的调度算法,有这样几个选项 rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,默认的调度算法是： wlc.

ipvsadm -a -t 192.168.10.11:80 -r 172.16.10.12:80 -m

-a --add-server 在内核虚拟服务器表的一条记录里添加一条新的真实服务器记录。也就是在一个虚拟服务器中增加一台新的真实服务器 -r --real-server server-address 真实的服务器[Real-Server:port] -m --masquerading 指定LVS 的工作模式为NAT 模式

ipvsadm -a -t 192.168.10.11:80 -r 172.16.10.13:80 -m

ipvsadm -Ln

ipvsadm -Ln --stats

-L|-l --list 显示内核虚拟服务器表 -n --numeric 输出IP 地址和端口的数字形式 --stats 显示统计信息

保存虚拟服务器表所有记录:

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.11:80 rr -> 172.16.10.12:80 Masq 1 0 0 -> 172.16.10.13:80 Masq 1 0 0

ipvsadm -Sn > /etc/sysconfig/ipvsadm //保存记录

ipvsadm -R < /etc/sysconfig/ipvsadm //恢复保存的记录

注意：ipvsadm 命令配置的LVS集群列表信息是临时有效的，如果想系统重启自动加载这些设置信息，必须将ipvsadm的操作命令写入到开机启动脚本/etc/rc.d/rc.local文件中。抓包： #tcpdump -i ens33 tcp and port 80 -v -nn -i 指定网卡 tcp 抓tcp协议的数据包 port 指定要抓哪个端口的包 -v 显示详细信息 -nn 以数字的形式显示ip和端口 9/34 node11新网卡练习：给node11虚拟机添加一块新的nat模式的网卡，然后做如下操作。给新网卡创建配置文件： ip a 发现多了一块名称为ens37的新网卡设备 cd /etc/sysconfig/network-scripts ls cp -av ifcfg-ens33 ifcfg-ens37 vim ifcfg-ens37 内容如下(红字为要修改的内容) TYPE=Ethernet BOOTPROTO=none DEFROUTE=yes DEVICE=ens37 网卡设备名称 ONBOOT=yes IPADDR=192.168.10.11 PREFIX=24 GATEWAY=192.168.10.2 DNS1=114.114.114.114 DNS2=8.8.8.8 重启网络服务，查看IP地址： systemctl restart network ip a 显示结果中的ens37网卡IP是192.168.10.11，说明新网卡设置OK了开启路由转发： cat /proc/sys/net/ipv4/ip_forward 查看路由转发是否开启，0为关闭，1为开启。 echo 1 > /proc/sys/net/ipv4/ip_forward 临时开启路由转发功能 sysctl -a | grep ip_forward 查内核运行参数

开启永久路由转发： vim /etc/sysctl.conf net.ipv4.ip_forward = 1 立即生效： sysctl -p cat /proc/sys/net/ipv4/ip_forward 方法一(首选)：临时开启路由转发功能，执行如下命令。 cat /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/ip_forward 方法二(备选)：临时开启路由转发功能，执行如下命令。 sysctl -a|grep ip_forward sysctl -w net.ipv4.ip_forward=1 sysctl -a|grep ip_forward 方法三(备选)：临时开启路由转发功能，执行如下命令。首先，vim /etc/sysctl.conf 添加如下内容 10/34 net.ipv4.ip_forward=1 然后，执行sysctl -p让sysctl.conf配置文件中的设置立即生效。最后，验收。sysctl -a|grep ip_forward 或 cat /proc/sys/net/ipv4/ip_forward。 IP负载均衡 LVS本身完全可以说是四层负载均衡,因为他要用端口在网络层通过修改请求目标地址进行负载均衡用户请求数据包到达负载均衡服务器后,负载均衡服务器在操作系统内核进程获取网络数据包,根据负载均衡算法计算到一台真实web服务器,然后将数据目的ip地址修改成这台真实web的ip,不需通过用户进程处理。真实web应用服务器处理完成后,响应数据包回到负载均衡服务器,负载均衡服务器再将数据包源地址修改为自身的ip发送给用户浏览器 IP负载均衡在内核进程完成数据分支,较反向代理负载均衡(在应用程序中分发数据)有更好的处理性能。但是由于所有请求响应都需要经过负载均衡服务器,集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽,对于提供下载服务或者视频服务等需要传输大量数据的网站而言,难以满足需求。能不能让负载均衡服务器只分发请求,而使响应数据从正式物理服务器直接返回给用户呢？数据链路层负载均衡

LVS-NAT原理 1). 当用户请求到达Director Server，,时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP,目标IP为VIP 2). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链 3). IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。此时报文的源IP为CIP,目标IP为RIP 4). POSTROUTING链通过选路,将数据包发送给Real Server 5). Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。此时报文的源IP为 RIP,目标IP为CIP 6). Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。此时 11/34 报文的源IP为VIP,目标IP为CIP 2. LVS-NAT模型的特性 1). RS应该使用私有地址,RS的网关必须指向DIP 2). DIP和RIP必须在同一个网段内 3). 请求和响应报文都需要经过Director Server,高负载场景中,Director Server易成为性能瓶颈 4). 支持端口映射 5). RS可以使用任意操作系统 6). 缺陷：对Director Server压力会比较大,请求和响应都需经过director server VS/NAT模式拓扑： ++++++++++++

Client + eth0: 192.168.10.1 ++++++++++++ | | +++++++++++ VIP eth0网卡: 192.168.11.11
Director + +++++++++++ DIP eth1网卡: 172.16.10.11 | |_____ | | | | ++++++++++++++++ +++++++++++++++
Real Server A + + Real Server B + ++++++++++++++++ +++++++++++++++ eth0: 172.16.11.12 eth0: 172.16.11.13 gateway: 172.16.10.11 gateway: 172.16.10.11 VS/NAT模式数据包走向： ==================================== 1.Client------------------>Director sip: CIP dip: VIP smac: Client_mac dmac: VIP_mac 2.Director--------------->Real Server sip: CIP dip: RIP smac: DIP_mac dmac: RealServer_mac 3.Real Server----------->Director sip: RIP dip: CIP smac: RealServer_mac dmac: DIP_mac 4.Director-------->Client sip: VIP dip: CIP smac: VIP_mac dmac: Client_mac =================配置LVS================ Real Server A & Real Server B: [root@localhost ~]# yum install httpd [root@localhost ~]# route add default gw 172.16.10.11 Director(LVS调度器): [root@localhost ~]# echo 1 > /proc/sys/net/ipv4/ip_forward 12/34 LVS-NAT(DNAT)负载均衡的网络拓扑图： NAT：网络地址转换 DNAT：目标(destination)网络地址转换 SNAT：源(source)网络地址转换 13/34 LVS-NAT 14/34 15/34 16/34 LVS部署脚本 ###编写lvs_nat.sh脚本 mkdir -pv /sh 17/34 vi /sh/lvs_nat.sh #!/bin/bash VIP=192.168.10.11 DIP=192.168.10.11 RIP1=192.168.10.12 RIP2=192.168.10.13 PORT=80 lvs_nat(){ rpm -q ipvsadm && echo "ipvsadm exsits" ||yum install -y ipvsadm &> /dev/null echo 1 > /proc/sys/net/ipv4/ip_forward ipvsadm -C ipvsadm -A -t ${VIP}:${PORT} -s wrr ipvsadm -a -t ${VIP}:${PORT} -r ${RIP1}:${PORT} -m -w 1 ipvsadm -a -t ${VIP}:${PORT} -r ${RIP2}:${PORT} -m -w 1 ipvsadm -Ln --stats } rs_web(){ rpm -q httpd && echo "httpd already installd" || yum install -y httpd curl &> /dev/null route add default gw $DIP systemctl restart httpd systemctl enable httpd web_ip=$(ifconfig ens33 | awk '/netmask/{print $2}') echo $web_ip > /var/www/html/index.html curl $web_ip } case $1 in start) lvs_nat ipvsadm --save ;; stop) ipvsadm -C ipvsadm -Ln ;; rs_web) rs_web ;; status) ipvsadm -ln ;; *) echo "usage : $0 [start|stop|status|rs_web]" ;; esac ###测试脚本的运行 chmod +x /sh/lvs_nat.sh sh /sh/lvs_nat.sh 数据链路层负载均衡 18/34 数据链路层负载均衡顾名思义,数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。这种数据传输方式又称作三角传输模式,负载均衡数据分发过程中不修改IP地址,只修改目的mac地址,通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致,从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的,由于实际处理请求的真实物理服务器IP和数据请求目的IP一致,不需要通过负载均衡服务器进行地址转换,可将相应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称作直接路由方式(DR)。

使用三角传输模式的链路层负载均衡时目前大型网站使用最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)

VS/DR原理和特点

LVS/DR模式的原理: 1). 当用户请求到达Director Server，,时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP,目标IP为VIP 2). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链 3). IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址 4). 由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的 MAC地址,那么此时数据包将会发至Real Server。 5). RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。此时的源IP地址为VIP,目标IP为CIP 6). 响应报文最终送达至客户端
2.LVS-DR模型的特性 1). 保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS 2). RS可以使用私有地址；也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问 3). RS跟Director Server必须在同一个物理网络中 19/34 4). 所有的请求报文经由Director Server,但响应报文必须不能进过Director Server 5). 不支持地址转换,也不支持端口映射，因为DR模型是工作在二层的，二层只处理数据包中的MAC地址 6). RS可以是大多数常见的操作系统 7). RS的网关绝不允许指向DIP(因为我们不允许他经过director) 8). RS上的lo接口配置VIP的IP地址
过程及解决方案： 1). 客户端要找vip访问80端口,因为是在同一个网段,所以发arp广播找vip的mac地址通信 2). 因为有RS上也有vip,我们不能直接让RS上的vip回应客户端的广播,所以设置内核参数arp_ignore的内容为1 将arp_ignore 设置为1,意味着当别人的arp请求过来的时候,如果接收的设备上面没有这个ip,就不做出响应. 默认是0,只要这台机器上面任何一个设备上面有这个ip,就响应arp请求,并发送mac地址 3). 当DR的vip收到这个广播之后,回应mac地址,然后得到客户端发来的80端口请求,再通过lvs分发到一个 RS 4). 那么DR如何分发到一个RS？ dip发出arp广播询问RS的ip地址所对应的mac地址,然后发出一个目标ip为RS_vip,目标mac为 RS_eth0_mac的包到RS 5). RS必须要使用vip把回应包发出去(这样client收到之后一看源地址是vip,他就会相信这是正确的地址发来的包) 6). 那么怎样让RS使用lo的vip而不使用eth0? 设置arp_announce文件的内容为2, 2的意思是使用本机最好的本地IP地址把回应包发出去 7). 最后怎么算是最好的本地IP地址？同一个网段下,使用可变长度子网掩码最长的IP地址被认为是好IP,因为他更精确

VS/DR模式拓扑： DR:direct routing直接路由。

++++++++++++ +-----------> + Client + eth0 192.168.11.10/24 | ++++++++++++ | | | | | ++++++++++++ VIP eth0:0 192.168.11.100/24 | + Director + | ++++++++++++ DIP eth0 192.168.11.11/24 | | +------------------------| --------------------------------+ | | | | ++++++++++++++++++ +++++++++++++++++

Real Server A + + Real Server B + ++++++++++++++++++ +++++++++++++++++ eth0 192.168.11.12/24 eth0 192.168.11.13/24 lo:0 192.168.11.100/32 lo:0 192.168.11.100/32 VS/DR模式数据包走向： =================================== 1.Client-------------------------->Director sip: CIP dip: VIP smac: Client_mac dmac: VIP_mac 20/34 2.Director---------------------->Real Server

Director在给Real Server发包前要广播找Real Server mac *
sip: DIP dip: RIP *
smac: DIP_mac dmac: broadcast *
sip: RIP dip: DIP *
smac: RealServer_mac dmac: DIP_mac *

sip: CIP dip: VIP smac: DIP_mac dmac: RealServer_mac 3.Real Server------------------>Client sip: VIP dip: CIP //这里的VIP是realserver的lo额外添加的那个VIP地址 smac: RealServer_mac dmac: Client_mac LVS-DR =============VS/DR模式配置==================== Real Server A & Real Server B: [root@localhost ~]# yum install httpd [root@localhost ~]# vim lo.sh 脚本内容如下 #!/bin/bash ifconfig lo:1 192.168.11.100 netmask 255.255.255.255 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 ip a 运行脚本(在192.168.11.12上做如下操作)： chmod -v +x lo.sh . lo.sh scp lo.sh root@192.168.11.13:/root/ ssh root@192.168.11.13 '. /root/lo.sh' 远程给192.168.11.13运行lo.sh脚本 Director调度器(node11): [root@localhost ~]# ifconfig ens33:0 192.168.11.100/24 up 给网卡临时设置VIP地址 [root@localhost ~]# ip a [root@localhost ~]# yum install ipvsadm [root@localhost ~]# ipvsadm -Ln [root@localhost ~]# ipvsadm -C [root@localhost ~]# ipvsadm -A -t 192.168.11.100:80 -s wrr [root@localhost ~]# ipvsadm -at 192.168.11.100:80 -r 192.168.11.12:80 -g -w 1 [root@localhost ~]# ipvsadm -at 192.168.11.100:80 -r 192.168.11.13:80 -g -w 3 [root@localhost ~]# ipvsadm -Ln [root@localhost ~]# ipvsadm -Sn > /etc/sysconfig/ipvsadm 保存ipvsadm配置 [root@localhost ~]# curl 192.168.11.12 21/34 [root@localhost ~]# curl 192.168.11.13 访问测试(win7/win10上做)：打开mobaxterm软件，点窗口上的+加号来开启一个cmd命令行界面，执行5次如下命令，看显示的网页信息有何不同 curl 192.168.11.100 保存：

ipvsadm -Sn > /etc/sysconfig/ipvsadm 或 service ipvsadm save (centos 6用service,centos

7不能用) Saving IPVS table to /etc/sysconfig/ipvsadm: [ OK ] 清空(不做)：

ipvsadm -C

查看

ipvsadm -Ln

ipvsadm -Ln --stats 显示连接次数状态信息

ipvsadm -Ln --rate

实时查看(必做)：

watch -n.5 'ipvsadm -Ln -c'

-n.5 是0.5秒刷新一次 -n 5 5秒刷新一次

要解决的问题： 1 .两个http服务器除了有自己的rip以外还要拥有vip 因为：数据包需从realServer返回 ,realServer返回的数据需要源IP为VIP 解决：添加 lo接口(本地环路接口) ,lo:1 vip/32. ifconfig lo:0 192.168.10.100/32 up 2 .当GW(网关)向下广播vip的时候要分发器的vip响应而两个http的vip不要响应因为：realServer的vip有了,接着就是同一个网段中拥有两个vip, 客户端在网关发送arp广播需找vip时需要让realServer不接受响应. 解决： echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore arp_ignore 设置为1,意味着当别人的arp请求过来的时候,如果接收的设备没有这个ip,就不做出响应 (这个ip在lo上,lo接收设备) echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce 使用最好的ip来回应,什么是最好的ip？同一个网段内子网掩码最长的抓包： #tcpdump -i ens33 tcp and port 80 -v -nn -i 指定网卡 tcp 抓tcp协议的数据包 port 指定要抓哪个端口的包 -v 显示详细信息 -nn 以数字的形式显示ip和端口

22/34 LVS部署脚本 ###编写lvs_nat.sh脚本 mkdir -pv /sh vi /sh/lvs_dr.sh #!/bin/bash VIP=192.168.10.10 DIP=192.168.10.11 RIP1=192.168.10.12 RIP2=192.168.10.13 PORT=80 lvs_dr(){ ifconfig ens33:0 $VIP broadcast $VIP netmask 255.255.255.255 up route add -host $VIP dev ens33:0 rpm -q ipvsadm && echo "ipvsadm exsits" ||yum install -y ipvsadm &> /dev/null echo 1 > /proc/sys/net/ipv4/ip_forward ipvsadm -C ipvsadm -A -t ${VIP}:${PORT} -s wrr ipvsadm -a -t ${VIP}:${PORT} -r ${RIP1}:${PORT} -g -w 1 ipvsadm -a -t ${VIP}:${PORT} -r ${RIP2}:${PORT} -g -w 2 ipvsadm -Ln } rs_web(){ ifconfig lo:0 $VIP netmask 255.255.255.255 up route add -host $VIP dev lo:0 rpm -q httpd && echo "httpd already installd" || yum install -y httpd curl &> /dev/null systemctl restart httpd systemctl enable httpd web_ip=$(ifconfig ens33 | awk '/netmask/{print $2}') echo $web_ip > /var/www/html/index.html curl $web_ip echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce sysctl -p } case $1 in start) lvs_dr ipvsadm --save ;; stop) ipvsadm -C ipvsadm -Ln ;; rs_web) rs_web ;; *) echo "usage : $0 [start|stop|rs_web]" ;; esac 23/34 ###测试脚本的运行 chmod +x /sh/lvs_nat.sh sh /sh/lvs_nat.sh HA集群 0 0 0 0 一、高可用集群(High Availability Cluster) 集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。每一个单个的计算机系统都叫集群节点(node)。随着业务的增长,集群通过添加新的节点,满足资源的高可扩展性。计算机硬件和软件易错性不可避免,这样在节点上的服务会不可避免的中断。高可用集群的出现是为保证即使节点失效,而服务能不中断。高可用集群在一组计算机中,采用主备模式,主节点提供服务,备节点等待；一旦,主节点失效,备节点无需人工的无缝取代主节点提供服务,这样保证了服务的不中断。高可用集群软件的主要作用就是实现故障检查和业务切换的自动化,以提供不中断的服务。二、高可用集群(HA)的衡量标准高可用性集群是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均维修时间(MTTR)来度量系统的可维护性。 HA=MTTF/(MTTF+MTTR)*100% HA衡量标准: ◇ 99% 一年宕机时间不超过4天 ◇ 99.9% 一年宕机时间不超过10小时 ◇ 99.99% 一年宕机时间不超过1小时 ◇ 99.999% 一年宕机时间不超过6分钟三、高可用集群的层次结构 24/34

1.信息层(Messaging) 也叫底层基础架构层,主要用于节点之间传递心跳信息,也称为心跳层。节点之间传递心跳信息可以通过广播,组播,单播等方式。心跳信息：集群中每一台服务器都不停的将自己在线的信息通告给集群中的其他主机。心跳信息的传递是基于套接字通信的,通过软件提供服务监听套接字,实现数据发送、请求。必须安装软件,并开启服务,这是实现高可用集群的基础。 2.成员层(Membership) 这层最重要的作用是通过Cluster Consensus Membership Service(CCM)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。 CCM 组件(Cluster Consensus Menbership Service)：承上启下,监听底层接受的心跳信息,当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息,并将结果转递给上层,让上层做出决定采取怎样的措施。CCM 还能够生成一个各节点状态的拓扑结构概览图,以本节点做为视角,保证该节点在特殊情况下能够采取对应的动作。 Messaging & Membership一般由同一软件实现。 25/34 3.资源分配层(Resource Allocation) 也叫资源管理器层,真正实现集群服务的层。包含CRM(集群资源管理器,cluster Resource Manager),CIB(集群信息基库,Cluster Infonation Base),PE(策略引擎,Policy Engine),TE(实施引擎,Transition Engine), LRM(Local Resource Manager,本地资源管理器)。 CRM组件：核心组件,实现资源的分配和管理。每个节点上的CRM都维护一个CIB用来定义资源特定的属性,哪些资源定义在同一个节点上。主节点上的CRM被选举为 DC(Designated Coordinator指定协调员, 主节点挂掉会选出新的DC),成为管理者,它的工作是决策和管理集群中的所有资源。任何DC上会额外运行两个进程,一个叫PE,；一个叫TE。 PE ：定义资源转移的一整套转移方式,但只做策略,并不亲自来参加资源转移的过程,而是让TE来执行自己的策略。 TE : 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。 CIB组件：XML格式的配置文件,工作的时候常驻内存,只有DC才能对CIB进行修改,其他节点上的复制 DC上的CIB而来。集群的所有信息都会反馈在CIB中。 LRM组件：是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。资源：在集群中构成一个完整服务的每一部分都叫资源,都需要配置和管理。以web应用为例：vip是资源,web服务器是资源,存储也是资源。不同的服务的资源也不尽相同,其中存储资源的选择、配置、管理是高可用集群中的难点问题。 4.资源代理层(Resource Agents) 集群资源代理,能够管理本节点上的属于集群资源的某一资源的启动,停止和状态信息的脚本,资源代理分为：LSB(/etc/init.d/*),OCF(比LSB更专业,更加通用)。任何资源代理都要使用同一种风格,接收四个参数：{start|stop|restart|status},每个种资源的代理都要完成这四个参数据的输出。工作机制： PE 根据CIB获取资源的配置信息(集群上的所有信息都会收集到DC的CIB,同步到其它节点),而后做出决策,一旦做得决策就会进行资源的管理。PE借助于本地的CCM通知给其它节点CIB来实现对某些资源管理信息的传递,比如说通告其它CRM要启动某一资源了,收到信息后CRM并不负责启动,转由 LRM(Local Resource Manager本地资源管理)启动,而并发资源又借助于RA(Resource Agent资源代理)实现资源管理。四、高可用集群软件 Messaging and Membership Layer(信息与关系层)： • heartbeat (v1,v2,v3) • corosync • cman • keepalived • ultramokey Cluster Resource Manager Layer(资源管理层,简称:CRM)： • haresource,crm (heartbeat v1/v2) • pacemaker (heartbeat v3/corosync) • rgmanager (cman) 常用组合： • heartbeat v2+haresource(或crm) (一般常用于CentOS 5.X) • heartbeat v3+pacemaker (一般常用于CentOS 6.X) • corosync+pacemaker (现在最常用的组合) • cman + rgmanager (红帽集群套件中的组件,还包括gfs2,clvm) 26/34 • keepalived+lvs (常用于lvs的高可用) 五、补充 1.STONITH(Shoot The Other Node in the Head,"爆头")组件这种机制直接操作电源开关,控制故障节点的电源开关,通过暂时断电又上电的方式,使故障节点重启, 这种方式需要硬件支持。主节点在某一段时间由于某种原因,没传递心跳信息,这个时候集群会选取新的DC,重新分配资源提供服务,如果主节点服务器还没有宕掉,这样就会导致服务器分隔、资源争用,这种情况被称为脑裂(brainsplit)。此时,用户能访问,一旦有写的操作,就会导致文件系统崩溃,损失惨重。为避免这种情况,新的DC一旦产生,第一时间对主节点执行stonith,这种操作叫做资源隔离。

2.资源隔离节点级别：这种就叫STONITH,直接把对方的电源给切断,一般这种主机都是连接到电源交换机上的。资源级别：同样需要依赖一些硬件设备来完成。比如节点通过光纤交换机连接到共享存储,通过把需要踢除出去的节点的光纤接口屏蔽来实现资源隔离。 3.仲裁设备 ping node：两个节点的模式下,一旦其中一个节点发生故障,发生集群分隔以后,无法判定哪个节点不正常,但工作正常的节点一定是可以连到互联网,故正常的节点是可以跟前端路由通信,所以可以把前端路 27/34 由当成第三个节点,如果可以ping通,那就说明自己是正常的,可以将对方隔离掉。 qdisk: RHCS不是使用ping节点来判断,而是使用一个共享存储的设备,节点按照心跳信息频率每隔一个信息频率时间就往磁盘里写一个数据位,如果设备每隔一个心跳时间间隔就更新一次数据位,就说明这个设备处于活动状态的,可以将对方隔离掉。 keepalive keepalived 1.Keepalived 定义 Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案,可以利用其来避免单点故障。一个 LVS服务会有2台服务器运行Keepalived,一台为主服务器(MASTER),一台为备份服务器(BACKUP),但是对外表现为一个虚拟IP,主服务器会发送特定的消息给备份服务器,当备份服务器收不到这个消息的时候,即主服务器宕机的时候, 备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。Keepalived是VRRP 的完美实现,keepalived是集群管理中保证集群高可用的一个服务软件,其功能类似于heartbeat,用来防止单点故障。 2.keepalived工作原理 keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。 keepalived主要有三个模块,分别是core(核心)、check(检测)和vrrp(虚拟路由冗余协议)。core模块为 keepalived的核心,负责主进程的启动、维护以及全局配置文件(keepalived.conf)的加载和解析。check负责健康检查,包括常见的各种检查方式(TCP、脚本检测进程状态等)。vrrp模块是来实现VRRP协议的。 keepalived的常见组合： keepalived+LVS keepalived+nginx keepalived+mysql-proxy keepalived+mycat 28/34 2.VRRP 协议简介虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master(主)和多个backup(备份),master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip),master会发组播(224.?.?.?),当backup收不到vrrp包时就认为master 宕掉了,这时就需要根据VRRP的优先级(priority)来选举一个backup当master。这样的话就可以保证路由器的高可用了。在现实的网络环境中,两台需要通信的主机大多数情况下并没有直接的物理连接。对于这样的情况,它们之间路由怎样选择？主机如何选定到达目的主机的下一跳路由,这个问题通常的解决方法有二种： • 在主机上使用动态路由协议(RIP、OSPF等) • 在主机上配置静态路由很明显,某些环境下在主机上配置动态路由是非常不切实际的,因为管理、维护成本以及是否支持等诸多问题。配置静态路由就变得十分流行,但路由器(或者说默认网关 default gateway)却经常成为单点故障。 VRRP的目的就是为了解决静态路由单点故障问题,VRRP通过一竞选(election)协议来动态的将路由任务交给LAN中虚拟路由器中的某台VRRP路由器。 3.VRRP 工作机制在一个VRRP虚拟路由器中,有多台物理的VRRP路由器,但是这多台的物理的机器并不能同时工作,而是由一台称为MASTER的负责路由工作,其它的都是BACKUP,MASTER并非一成不变,VRRP让每个VRRP路由器参与竞选,最终获胜的就是MASTER。MASTER拥有一些特权,比如,拥有虚拟路由器的IP地址,我们的主机就是用这个IP地址作为静态路由的。拥有特权的MASTER要负责转发发送给网关地址的包和响应ARP请求。 VRRP通过竞选协议来实现虚拟路由器的功能,所有的协议报文都是通过IP多播(multicast)包(多播地址224.0.0.18)形式发送的。虚拟路由器由VRID(范围0-255)和一组IP地址组成,对外表现为一个周知的 MAC地址。所以,在一个虚拟路由器中,不管谁是MASTER,对外都是相同的MAC和IP(称之为VIP)。客户端主 29/34 机并不需要因为MASTER的改变而修改自己的路由配置,对客户端来说,这种主从的切换是透明的。在一个虚拟路由器中,只有作为MASTER的VRRP路由器会一直发送VRRP通告信息(VRRP Advertisement message),BACKUP不会抢占MASTER,除非它的优先级(priority)更高。当MASTER不可用时 (BACKUP收不到通告信息), 多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的(<1s),以保证服务的连续性。由于安全性考虑,VRRP包使用了加密协议进行加密。

4.VRRP 工作流程 (1).初始化：路由器启动时,如果路由器的优先级是255(最高优先级,路由器拥有路由器地址),要发送VRRP通告信息,并发送广播ARP信息通告路由器IP地址对应的 MAC地址为路由虚拟MAC,设置通告信息定时器准备定时发送 VRRP通告信息,转为MASTER状态；否则进入BACKUP状态,设置定时器检查定时检查是否收到MASTER的通告信息。 (2).Master • 设置定时通告定时器； • 用VRRP虚拟MAC地址响应路由器IP地址的ARP请求； • 转发目的MAC是VRRP虚拟MAC的数据包； • 如果是虚拟路由器IP的拥有者,将接受目的地址是虚拟路由器IP的数据包,否则丢弃； • 当收到shutdown的事件时删除定时通告定时器,发送优先权级为0的通告包,转初始化状态； • 如果定时通告定时器超时时,发送VRRP通告信息； • 收到VRRP通告信息时,如果优先权为0,发送VRRP通告信息；否则判断数据的优先级是否高于本机,或相等而且实际IP地址大于本地实际IP,设置定时通告定时器,复位主机超时定时器,转BACKUP状态；否则的话,丢弃该通告包； (3).Backup • 设置主机超时定时器； • 不能响应针对虚拟路由器IP的ARP请求信息； • 丢弃所有目的MAC地址是虚拟路由器MAC地址的数据包； • 不接受目的是虚拟路由器IP的所有数据包； • 当收到shutdown的事件时删除主机超时定时器,转初始化状态； • 主机超时定时器超时的时候,发送VRRP通告信息,广播ARP地址信息,转MASTER状态； • 收到VRRP通告信息时,如果优先权为0,表示进入MASTER选举；否则判断数据的优先级是否高于本机,如果高的话承认MASTER有效,复位主机超时定时器；否则的话,丢弃该通告包； 5.ARP查询处理当内部主机通过ARP查询虚拟路由器IP地址对应的MAC地址时,MASTER路由器回复的MAC地址为虚拟的VRRP的MAC地址,而不是实际网卡的 MAC地址,这样在路由器切换时让内网机器觉察不到；而在路由器重新启动时,不能主动发送本机网卡的实际MAC地址。如果虚拟路由器开启的ARP代理 (proxy_arp)功能, 代理的ARP回应也回应VRRP虚拟MAC地址

keepalived+LVS/DR 30/34 keepalive的详解(必看)：http://outofmemory.cn/wiki/keepalived-configuration keepalived.conf配置文件可以通过man keepalived.conf来查看官方解释 keepalived+LVS-DR模式拓扑软件功能说明： keepalived:实现中间件(代理服务器的高可用)。 LVS:是中间件软件(即代理服务器软件)，是用来实现集群的负载均衡。 +++++++++ +---------------------------> + Client + 192.168.11.1 win7/10 | +++++++++ | ________________|

| | VIP eth0:1 192.168.10.100 ｜ | +++++++++++++++++++++ ++++++++++++++++++++ + | + Director master主 node11 + + Director backup备 node12 + | +++++++++++++++++++++ +++++++++++++++++++++ | DIP 192.168.11.11 ens33网卡 DIP 192.168.11.12 ens33网卡 | |________ | _| | | | | +++++++++++++++++ ++++++++++++++++++ +--------+ RealServer A node13 + + Real Server B node14 + +++++++++++++++++ ++++++++++++++++++ 192.168.11.13/24 192.168.11.14/24 分别在Director master、Director backup 上部署浮动资源(VIP IPVS策略) 测试2个Director在DR模式下都工作正常。测试完成后都撤掉浮动资源。首先：在node11、node12上分别安装keepalived和ipvsadm软件包，并做keepalived相关配置。在Director master上安装配置Keepalived

yum install keepalived ipvsadm -y

cp -av /etc/keepalived/keepalived.conf{,.bak} 备份原始配置文件

vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived global_defs { 全局定义，说明：在实验测试环境中，以下内容可以随便写，但是master和 backup的router_id必须相同 notification_email { 设置通知邮箱 root@localhost 管理员的邮箱地址 } notification_email_from keepalived@localhost 通知邮件的发件人邮箱 smtp_server 127.0.0.1 邮箱服务器IP地址 smtp_connect_timeout 30 邮件服务器连接超时时间为30秒 router_id dr1 路由器ID名称，同一个keepalived高可用集群中master和backup的ID名称必须相同 } vrrp_instance VI_1 { vrrp虚拟路由冗余协议的实例设置 ,实例名称为VI_1 state MASTER 状态，主为MASTER，备为BACKUP状态 31/34 interface ens33 //心跳检测网卡接口，要根据实际情况写网卡接口名，用 ip a查网卡接口名 virtual_router_id 51 //master主和backup备两边必须一样，此处是集群的群号 priority 100 //优先级，MASTER的值必须高于BACKUP的值，类似于现实生活中的竞选的票数 advert_int 1 //检查间隔,单位秒。vrrp的组播地址是224.0.0.18 authentication { 身份认证配置 auth_type PASS //认证类型为密码方式,主备要一致 auth_pass 1111 //认证密码为1111,主备要一致 } virtual_ipaddress { 192.168.11.100 //VIP,可多个IP,每行一个IP地址 192.168.11.111 } } virtual_server 192.168.11.100 80 { //LVS 配置(即调度器的配置)，此行等同于ipvsadm - At 192.168.11.100:80 -s wrr命令 delay_loop 3 //服务论询的时间间隔 lb_algo rr //LVS 调度算法 lb_kind DR // LVS 集群模式 protocol TCP //指定协议为TCP协议 real_server 192.168.11.13 80 { //RS后端真实服务器的IP及端口号，等同于ipvsadm -at 192.168.11.100:80 -r 192.168.11.13:80 -g -w 1命令 weight 1 TCP_CHECK { //RS健康检查，如果RS主机上的80端口业务异常关闭了，用ipvsadm - Ln查不到此RS的IP信息 connect_timeout 3 //连接超时时间为3秒 } } real_server 192.168.11.14 80 { weight 1 TCP_CHECK { connect_timeout 3 } } }

cd /etc/keepalived

scp keepalived.conf 192.168.11.12:/etc/keepalived/ 将配置文件发送给node12的主机

拷贝后,修改配置文件 state BACKUP priority 90 两个Director(调度器)上启动服务，并查看vip地址:

systemctl restart keepalived [centos 7专用命令]

service keepalived restart [centos 6和7通用命令]

ip a 在master上可以看到ens33网卡有192.168.11.100和192.168.11.111这两个VIP地址。而

backup备主机上是没有VIP的。当在master上用systemctl stop keepalived后，备主机上就会有这两个 VIP。

ipvsadm -Ln 查ipvs的集群配置信息

32/34

抓包:

yum install -y tcpdump

tcpdump -i ens33 -nv vrrp

-i 指定网卡 -n 以数字的方式显示(ip,port) -v 显示详细信息 -vv 显示更详细的信息 -w 保存到文件－－－－ keepalived通过vrrp协议进行组播的作用：是为了竞选出由哪台keepalived主机接管业务(使用VIP的)。谁的priority优先级高(即票数多)，谁就有 VIP地址。当master和backup都在运行keepalived服务时： node11(master)发送的组播信息： src：192.168.11.11 dest：224.0.0.18 node12(backup)接收的组播信息： src：192.168.11.11 dest：224.0.0.18 －－－－当node11这台master停止了keepalived服务： node12发送的组播信息： src：192.168.11.12 dest：224.0.0.18 keepalived集群中其他主机接收的组播信息： src：192.168.11.12 dest：224.0.0.18

keepalived+script 通过脚本的执行结果来提高或降低自身的优先级完成VIP的切换(即master和backup之间的切换) keepalived+nginx的代理功能准备工作:在node11和node12主机分别安装好keepalived和nginx(或httpd)软件 yum install -y keepalived ipvsadm 设置keepalived.conf配置文件

vim /etc/keepalived/keepalived.conf

global_defs { notification_email { sysadmin@firewall.loc 33/34 } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id dr1 #vrrp_strict 一定要注释掉此行,否则无法通过VIP地址访问调度器 } vrrp_script down { 定义名称为down的vrrp状态检测脚本 #script "[ -e /tmp/down ] && exit 1 || exit 0" //配置脚本,引号内也可以是脚本的名称 script "netstat -tnlp|grep :80 && exit 0 || exit 1" //通过网络进程端口号 interval 3 //间隔时间为3秒 weight -20 //脚本返回非0,则降低优先级 fall 2 //连续检测2次失败才算真的失败 rise 1 //检测1次成功就算成功 } vrrp_instance VI_1 { 配置名称为VI_1这个vrrp协议的实例,允许多个实例 state MASTER interface ens33 virtual_router_id 51 priority 100 advert_int 1 #nopreempt //不抢占VIP地址 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.11.100 }

track_script { //执行脚本 down } } 如果脚本执行结果为0,并且weight配置的值大于0,则优先级相应的增加(升优先级) 如果脚本执行结果非0,并且weight配置的值小于0,则优先级相应的减少(降优先级) 其他情况,原本配置的优先级不变,即配置文件中priority对应的值。优先级不会不断的提高或者降低可以编写多个检测脚本并为每个检测脚本设置不同的weight(在配置中列出就行) 不管提高优先级还是降低优先级,最终优先级的范围是在[1,254],不会出现优先级小于等于0或者优先级大于等于255的情况－－－测试检验： 1.在node11、node12上启动httpd和keepalived服务。 2.在node11上停止httpd服务，用ip a查VIP信息，会发node11上没有VIP 了 3.在node12上用ip a查VIP信息，会发node12有VIP 了 2.在node11上启动httpd服务，用ip a查VIP信息，会发node11有VIP 34/34