本文小编为大家详细介绍“LVS的环境怎么搭建”，内容详细，步骤清晰，细节处理妥当，希望这篇“LVS的环境怎么搭建”文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，目的在于使用集群技术和Linux操作系统实现一个高性能、高可用的服务器。它具有良好的可靠性，可拓展性和可操作性。从而以低廉的成本实现最优的性能。
1. DS：Director Server。指的是前端负载均衡器节点。 2. RS：Real Server。后端真实的工作服务器。 3. VIP：向外部直接面向用户请求，作为用户请求的目标的IP地址。 4. DIP：Director Server IP，主要用于和内部主机通讯的IP地址。 5. RIP：Real Server IP，后端服务器的IP地址。 6. CIP：Client IP，访问客户端的IP地址。
\1. 直接路由模式（DR）
原理：负载均衡器和RS都使用同一个IP对外服务｡但只有DR对ARP请求进行响应，所有RS对本身这个IP的ARP请求保持静默。也就是说，网关会把对这个服务IP的请求全部定向给DR，而DR收到数据包后根据调度算法，找出对应的RS，把目的MAC地址改为RS的MAC（因为IP一致）并将请求分发给这台RS。这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异，处理后直接返回给客户端。由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域，也可以简单的理解为在同一台交换机上。
优点：负载均衡器只是分发请求，应答包通过单独的路由方法返回给客户端。
缺点：要求负载均衡器的网卡必须与物理网卡在一个物理段上。
\2. NAT模式（NAT）
原理：就是把客户端发来的数据包的IP头的目的地址，在负载均衡器上换成其中一台RS的IP地址，并发至此RS来处理，RS处理完成后把数据交给经过负载均衡器，负载均衡器再把数据包的原IP地址改为自己的IP，将目的地址改为客户端IP地址即可。期间，无论是进来的流量,还是出去的流量，都必须经过负载均衡器。
优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统。
缺点：扩展性差。当服务器节点（普通PC服务器）增长过多时，负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器处，导致负载均衡器变慢以至于整个链路变慢。
\3. IP隧道模式（TUN）
原理：隧道模式就是，把客户端发来的数据包，封装一个新的IP头标记(仅目的IP)发给RS，RS收到后，先把数据包的头解开，还原数据包，处理后直接返回给客户端，不需要再经过负载均衡器。注意，由于RS需要对负载均衡器发过来的数据包进行还原，所以说必须支持IPTUNNEL协议。因此，在RS的内核中，必须编译支持IPTUNNEL这个选项。
优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持“IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。
\1. LVS负载均衡的调度算法一（静态）
轮循调度（rr, Round Robin） 调度器通过“轮循”调度算法将外部请求按顺序轮流分配到集群中的真实机器上，它均等的对待每一台服务器，而不管服务器实际的连接数和系统负载。
加权轮循（wrr, Weighted Round Robin） 调度器通过“加权轮循”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态的调整其权值。
目标地址散列（DH, Destination Hashing） “目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
源地址散列（SH, Source Hashing） “源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找到对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
\2. LVS负载均衡的调度算法二（动态）
最少链接（LC, Least Connections） 调度器通过“最少链接”调度算法动态的将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最少连接”调度算法可以较好的均衡负载。 OL(Over Load)=active * 256 + deactive
加权最少链接（WLC, Weighted Least Connections） 在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少连接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态的调整其权值。 OL(Over Load)=(active * 256 + deactive) / weighted
最短的期望延迟（SED, Shortest Expected Delay Scheduling）
最少队列调度（NQ, Never Queue Scheduling） 无需排队。如果有台Real Server的连接数等于0就直接分配过去，不需要再进行SED运算。
基于局部性的最少链接（LBLC, Locality-Based Least Connections） “基于局部性的最少连接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少连接”的原则选出一个可用的服务器，将请求发送到该服务器。
带复制的基于局部性最少链接（LBLCR, Locality-Based Least Connections with Repilcation） “带复制的基于局部性最少连接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最少连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发到该服务器；若服务器超载，则按“最少连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
实验环境：CentOS6.5，关闭iptables/selinux Client: 172.16.1.100 Director Server: eth0 - 192.168.1.100 eth2 - 172.16.1.101 (VIP) RealServer01: 192.168.1.101 RealServer02: 192.168.1.102
1、RS配置：
a. 两台RS的网卡配置中网关均配置为DS的eth0 IP: 192.168.1.100 b. 因为没有做共享存储，只在各自的主页文件中加入不同信息以示区别： RealServer01 # echo "RealServer01" > /var/log/index.html RealServer02 # echo "RealServer02" > /var/log/index.html
2、DS配置：
a) 开启ipv4转发
# vi /etc/sysctl.confnet.ipv4.ip_forward = 1 b) 安装启动ipvsadm# yum install ipvsadm -y# service ipvsadm start
c) 增加规则
# ipvsadm -A -t 172.16.1.101:80 -s rr# ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.101 -m -w 1# ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.102 -m -w 2 d) 查看并保存 [root@director ~]# ipvsadm -L -nIP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.16.1.101:80 rr -> 192.168.1.101:80 Masq 1 0 0 -> 192.168.1.102:80 Masq 2 0 0 [root@director ~]# service ipvsadm saveipvsadm: Saving IPVS table to /etc/sysconfig/ipvsadm: [确定]
e) 在Client测试的结果 rr调度算法结果：
wrr调度算法结果：
# ipvsadm -E -t 172.16.1.101:80 -s wrr
ab命令基本参数：
-n 执行的请求数量 -c 并发请求个数 其它参数： -t 测试所进行的最大秒数 -p 包含了需要POST的数据的文件 -T POST数据所使用的Content-type头信息 -k 启用HTTP KeepAlive功能，即在一个HTTP会话中执行多个请求，默认时，不启用KeepAlive功能
测试案例：
# yum -y install httpd-tools # ab -c 10 -n 10000
# 测试完成进度Benchmarking 172.16.1.101 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Apache/2.2.15 Server Hostname: 172.16.1.101 Server Port: 80 Document Path: /index.html # 请求的资源Document Length: 14 bytes #返回的长度Concurrency Level: 10 # 并发个数Time taken for tests: 0.262 seconds # 总请求时间Complete requests: 1000 # 总请求数Failed requests: 0 # 失败的请求数Write errors: 0 Total transferred: 280840 bytes HTML transferred: 14042 bytes Requests per second: 3816.98 [#/sec] (mean) # 平均每秒的请求数Time per request: 2.620 [ms] (mean) # 平均每个请求消耗的时间Time per request: 0.262 [ms] (mean, across all concurrent requests) Transfer rate: 1046.84 [Kbytes/sec] received # 传输速率Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.4 1 3 Processing: 1 2 0.6 1 7 Waiting: 0 1 0.6 1 4 Total: 1 3 0.8 2 7 Percentage of the requests served within a certain time (ms) 50% 2 # 50%的requests都在2ms内完成 66% 3 75% 3 80% 3 90% 4 95% 4 98% 4 99% 5 100% 7 (longest request)
说明：由于缺乏实际requests，无法模拟其它动态调度算法的效果，暂时记录到这里。
读到这里，这篇“LVS的环境怎么搭建”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
