LVS集群

最新推荐文章于 2024-09-14 16:21:49 发布

nak21

最新推荐文章于 2024-09-14 16:21:49 发布

阅读量174

点赞数

文章标签：服务器网络运维

本文链接：https://blog.csdn.net/nak21/article/details/120957068

版权

LVS简介

Internet 的飞速发展给网络带宽和服务器带来巨大的挑战。从网络技术的发展来看，网络带宽的增长远高于处理器速度和内存访问速度的增长,所以，我们深信越来越多的瓶颈会出现在服务器端。很多研究显示 Gigabit Ethernet 在服务器上很难使得其吞吐率达到 1Gb/s 的原因是协议栈（TCP/IP）和操作系统的低效，以及处理器的低效，这需要对协议的处理方法、操作系统的调度和 IO 的处理作更深入的研究。

比较热门的站点会吸引前所未有的访问流量，曾经的 Yahoo 每天发送6.25亿页面，American Online 的 Web Cache 系统每天处理 50.2 亿个用户访问 Web 的请求，每个请求的平均响应长度为 5.5Kbytes。更不用说现在移动端的放光发热，这样使得很多网络服务因为访问次数爆炸式地增长而不堪重负，不能及时处理用户的请求，导致用户进行长时间的等待，大大降低了服务质量。

所以对于这样的工作环境，对于我们的服务会有这样的一些需求：

可伸缩性（Scalability），当服务的负载增长时，系统能被扩展来满足需求，且不降低服务质量。
高可用性（Availability），尽管部分硬件和软件会发生故障，整个系统的服务必须是每天 24 小时每星期 7天可用的。
可管理性（Manageability），整个系统可能在物理上很大，但应该容易管理。
价格有效性（Cost-effectiveness），整个系统实现是经济的、易支付的。

这样的需求促使了服务器集群的产生，既然单台的服务器一台并不能满足我的需求，高端的又太贵，效果也没有这么理想，由此我们便使用多台服务器同时为我们提供服务，而这样的多台服务器我们称之为服务器集群。

通过高性能网络或局域网互联的服务器集群正成为实现高可伸缩的、高可用网络服务的有效结构。这种松耦合结构的服务器集群系统有下列优点：

性能：网络服务的工作负载通常是大量相互独立的任务，通过一组服务器分而治之，可以获得很高的整体性能。
性价比：组成集群系统的 PC 服务器或 RISC 服务器和标准网络设备因为大规模生产降低成本，价格低，具有最高的性能/价格比。若整体性能随着结点数的增长而接近线性增加，该系统的性能/价格比接近于 PC服务器。所以，这种松耦合结构比紧耦合的多处理器系统具有更好的性能/价格比。
可伸缩性：集群系统中的节点数目可以增长到几千个，乃至上万个，其伸缩性远超过单台超级计算机。
高可用性：在硬件和软件上都有冗余，通过检测软硬件的故障，将故障屏蔽，由存活节点提供服务，可实现高可用性。

Load_Balance

为此在章文嵩博士在 1998 年 5 月成立了 Linux Virtual Server 的自由软件项目，进行 Linux 服务器集群的开发工作，并在网站上发布第一个版本源程序。并且在 Linux2.4 以后的版本中，直接将 LVS 加入内核中，不用再重新自行编译进内核。

负载均衡的方式

由上述的情况我们了解到服务器集群的重要性以及必要性，而实现服务器集群主要就是为了负载均衡（Load Balance），负载均衡就是有两台或者以上的服务器或者站点为我们提供服务，我们将来自客户端的请求靠某种算法尽量平均分摊到这些集群中，从而避免一台服务器因为负载太高而出现故障。

简而言之便是将所有的负载均分到多台服务器中，即使其中某个出现故障，用户也能正常访问，得到服务。

而从早期到现在出现的负载均衡方式有这样的两种：

硬件负载均衡
软件负载均衡

其中硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，由专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，但是相对来说成本较高。而常用的负载均衡器有这样一些：

F5 BIG-IP
Citrix Netscaler
Alteon ACEDirector
Cisco LocalDirector
A10 负载均衡器
梭子鱼负载均衡器

受到了用户的广泛认可，基于简单的 Web 管理界面，实现 4-7 层负载均衡、通用持续性、响应错误处理、SSL 加速、智能 HTTP 压缩、TCP 优化、第 7 层速率整形、内容缓冲、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护等等强大的功能

而更加广泛的则是使用软件的方式来实现负载均衡，实现效果不错，并且不需要成本是很多企业选择的方式。其中常用的方式有：

LVS
Nginx
HAProxy

其中 LVS 主要工作与网络模型中的第四层，而 Nginx 主要工作于第七层，而 HAProxy 是一款提供高可用性、负载均衡以及基于TCP（第四层）和 HTTP（第七层）应用的代理软件，支持虚拟主机。

其中 LVS 抗负载能力强只是工作在网络4层之上仅作分发之用，没有流量的产生，并且工作稳定，自身有完整的双机热备方案，如 LVS+Keepalived和LVS+Heartbeat，在项目实施中用得最多的还是 LVS/DR+Keepalived。

LVS 的组成部分

LVS 集群采用三层结构，三层主要组成部分为：

负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个 IP 地址（我们可称之为虚拟 IP 地址）上的。
服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有 WEB、MAIL、FTP 和 DNS 等。
共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

LVS_struct

在以软件实现的负载均衡的方式有：

基于应用层负载均衡
基于 IP 层负载均衡

其中基于应用层负载均衡：多台服务器通过高速的互联网络连接成一个集群系统，在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时，请求会提交给做负载均衡调度的应用程序，分析请求，根据各个服务器的负载情况，选出一台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给用户。

典型的代表有 Nginx 以及 Apache 的 Rewrite 模块。

应用层的负载均衡实现这样强大的功能也会付出一定的代价：

系统处理开销较大，致使系统的伸缩性有限。
基于应用层的负载均衡调度器对于不同的应用，需要写不同的调度器。

而基于 IP 层负载均衡：用户通过虚拟 IP 地址（Virtual IP Address）访问服务时，访问请求的报文会到达负载调度器，由它进行负载均衡调度，从一组真实服务器选出一个，将报文处理并转发给选定服务器的地址。真实服务器的回应报文经过负载调度器时，将报文的源地址和源端口改为 Virtual IP Address 和相应的端口，再把报文发给用户。

而 IP 的负载技术有以下三种模式：

通过 NAT 实现虚拟服务器（VS/NAT）
通过 IP 隧道实现虚拟服务器（VS/TUN）
通过直接路由实现虚拟服务器（VS/DR）

并且在调度器上配置了 8 种调度算法：

轮叫（Round Robin）：调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
加权轮叫（Weighted Round Robin）：调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
最少链接（Least Connections）：调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
加权最少链接（Weighted Least Connections）：在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
基于局部性的最少链接（Locality-Based Least Connections）："基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标 IP 地址找出该目标 IP 地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务器，将请求发送到该服务器。
带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）："带复制的基于局部性最少链接"调度算法也是针对目标 IP 地址的负载均衡，目前主要用于 Cache 集群系统。它与 LBLC 算法的不同之处是它要维护从一个目标 IP 地址到一组服务器的映射，而 LBLC 算法维护从一个目标 IP 地址到一台服务器的映射。该算法根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
目标地址散列（Destination Hashing）："目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
源地址散列（Source Hashing）："源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

VS/NAT 实现虚拟服务器

由于 IPv4 中 IP 地址空间的日益紧张和安全方面的原因，很多网络使用保留 IP 地址（10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0 和 192.168.0.0/255.255.0.0）。这些地址不在 Internet 上使用，而是专门为内部网络预留的。

当内部网络中的主机要访问 Internet 或被 Internet 访问时，就需要采用网络地址转换（Network Address Translation, 以下简称 NAT），将内部地址转化为 Internet 上可用的外部地址。

NAT 的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信它们连接一个 IP 地址，而不同 IP 地址的服务器组也认为它们是与客户直接相连的。由此，可以用 NAT 方法将不同 IP 地址的并行网络服务变成在一个 IP 地址上的一个虚拟服务。

VS/NAT（Virtual Server via Network Address Translation）实现的虚拟服务器是这样的一个结构，主要经过这样的一些步骤：

LVS-NAT

客户端通过 Internet 向服务器发起请求，而请求的 IP 地址指向的是调度器上对外公布的 IP 地址；（因为它并不是真正处理请求的服务器 IP 地址，所以称之为虚拟 IP 地址，简称为 VIP，Virtual IP Address）
请求报文到达调度器（Load Balancer），调度器根据调度算法从一组真实的服务器（因为他们是真正处理用户请求的服务器，所以称为真实服务器，Real server。其 IP 地址也被称为真实 IP，简称为 RIP）中选出一台当前负载不高的服务器。然后将客户端的请求报文中的目标地址（Load Balancer 的 VIP）和端口通过 iptables 的 NAT 改写为选定服务器的 IP 地址和服务的端口。最后将修改后的报文发送给选出的服务器。同时，调度器在连接Hash 表中记录这个连接；当这个连接的下一个报文到达时，从连接 Hash 表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。
Real Server 接收到报文之后，作出了相应的处理，然后将响应的报文发送给 Load Balancer；
Load Balancer 接收到响应的报文时，将报文的源地址和源端口改为 Virtual IP Address和相应的端口，再把报文发给用户。

这样，客户所看到的只是在 Virtual IP Address 上提供的服务，而服务器集群的结构对用户是透明的。

下面，举个例子来进一步说明 VS/NAT，如图所示：

NAT-eg

VS/NAT 的配置如下表所示，所有到 IP 地址为 205.100.106.2 和端口为 80 的流量都被负载均衡地调度的真实服务器172.16.1.3:80和 172.16.1.4:8080上。目标地址为 205.100.106.2:21 的报文被转移到172.16.1.3:21上。而到其他端口的报文将被拒绝。

|Protocol | Virtual IP Address |Port |Real IP Address |Port| |--------|--------| |TCP |205.100.106.2| 80 |172.16.1.3 | 80| ||||172.16.1.4| 8080| |TCP |205.100.106.2| 21 |172.16.1.3 | 21|

当客户端访问 Web 服务的时候，报文中可能有以下的源地址和目标地址：

SOURCE	DEST
203.100.106.1:3456	205.100.106.2:80

报文到达调度器之后，调度器从调度列表中选出一台服务器，例如是172.16.1.4:8080。该报文会被改写为如下地址，并将它发送给选出的服务器。

SOURCE	DEST
203.100.106.1:3456	172.16.1.4:8080

Real Server 收到修改后的报文之后，做出响应，然后将响应报文返回到调度器，报文如下：

SOURCE	DEST
172.16.1.4:8080	203.100.106.1:3456

响应报文的源地址会被 Load Balacer 改写为虚拟服务的地址，再将报文发送给客户：

SOURCE	DEST
205.100.106.2:80	203.100.106.1:3456

这样，客户认为是从202.103.106.5:80服务得到正确的响应，而不会知道该请求是 Real Server1 还是 Real Server2 处理的。

这便是 VS/NAT 的处理数据包的整个过程，它有这样的一些特点：

集群节点，也就是 Real Server 与 Load Balacer 必须在同一个 IP 网络中
Load Balancer 位于 Real Server 与客户端之间，处理进出的所有通信
RIP 通常是私有地址，仅用于各个集群节点之间的通信。
Real Server 的网关必须指向 Load Balancer
支持端口映射：也就是Real Server 的端口可以自己设定，没有必须是与 Load Balancer 一样

VS/NAT 的优势在于可以做到端口映射，但是 Load Balancer 将可能成为集群的瓶颈。因为所有的出入报文都需要 Load Balancer 处理，请求报文较小不是问题，但是响应报文往往较大，都需要 NAT 转换的话，大流量的时候， Load Balancer 将会处理不过来。一般使用 VS/NAT 的话，处理 Real Server 数量达到 10~20 台左右将是极限，并且效率往往不高。

VS/DR 实现虚拟服务器

在VS/NAT 的集群系统中，请求和响应的数据报文都需要通过负载调度器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数 Internet 服务都有这样的特点：请求报文较短而响应报文往往包含大量的数据。

既然同时处理进出报文会大大地影响效率，增加机器的负载，那么若是仅仅处理进来的报文，即在负载调度器中只负责调度请求,而出去的报文由 Real Server 直接发给客户端这样岂不是高效许多。

VS/DR（Virtual Server via Direct Routing）利用大多数 Internet 服务的非对称特点，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。

VS/DR 实现的虚拟服务器是这样的一个结构，主要经过这样的一些步骤：

DR-sturct

客户端通过 Internet 向服务器发起请求，而请求的 IP 地址指向的是调度器上对外公布的 IP 地址；
请求报文到达调度器（Load Balancer），调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装 IP 报文，而是将数据帧的 MAC 地址改为选出服务器的 MAC 地址，再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的 MAC 地址是选出的服务器，所以服务器肯定可以收到这个数据帧；
Real Server 接收到报文之后，发现报文的目标地址 VIP 是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。

在 VS/DR 中，根据缺省的 TCP/IP 协议栈处理，请求报文的目标地址为 VIP，响应报文的源地址肯定也为VIP，所以响应报文不需要做任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。

这便是 VS/DR 的处理数据包的整个过程，它有这样的一些特点：

集群节点，也就是 Real Server 与 Load Balacer 必须在同一个物理网络中（若是不同网段的话结构将变得复杂）
RIP 通常是私有地址，也可以是公网地址，以便于远程管理与监控。
Load Balancer 仅仅负责处理入站的请求，Real Server 将直接响应客户端
Real Server 的网关不能指向 Load Balancer
不支持端口映射：也就是 Real Server 的端口必须是与 Load Balancer 对外服务的一样

VS/TUN 实现虚拟服务器

VS/DR 限制 Real Server 与 Load Balancer 必须在同一个物理网络中，那若是分散在各地岂不是无法使用？所以有了 VS/TUN（Virtual Server via IP Tunneling）的诞生。

IP 隧道（IP tunneling）是将一个 IP 报文封装在另一个 IP 报文的技术，这可以使得目标为一个 IP 地址的数据报文能被封装和转发到另一个 IP 地址。IP隧道技术亦称为 IP 封装技术（IP encapsulation）。IP 隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的 IP 地址。

我们利用 IP 隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，我们可以利用 IP 隧道的原理将一组服务器上的网络服务组成在一个 IP 地址上的虚拟网络服务。 VS/TUN 的体系结构如图所示，各个服务器将 VIP 地址配置在自己的 IP 隧道设备上。

Tunnel-sturct

它的连接调度和管理与 VS/NAT 中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个 IP 报文中，再将封装后的 IP 报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为 VIP的报文，服务器发现VIP地址被配置在本地的 IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

这便是 VS/TUN 的处理数据包的整个过程，它有这样的一些特点：

集群节点，也就是 Real Server 与 Load Balacer 可以跨越公网
RIP 必须是公网地址。
Load Balancer 仅仅负责处理入站的请求，Real Server 将直接响应客户端
Real Server 的网关不能指向 Load Balancer
不支持端口映射：也就是 Real Server 的端口必须是与 Load Balancer 对外服务的一样

这便是 LVS 所提供的 IP 负载均衡的三种技术，我们可以根据自己的情况做出不同的选择。

LVS/NAT 实现

安装 ipvsadm 工具

首先为了能够使用 IPVS 内核模块，我们将在宿主机中安装 ipvsadm，并尝试能否使用：

# 更新源 
sudo apt-get update

# 安装 ipvsadm 工具
sudo apt-get install ipvsadm

# 尝试使用 ipvsadm
sudo ipvsadm -L

图片描述

2.4.2 创建服务器池成员

使用 docker 创建所需 container，使用以下命令创建：

docker run --privileged --name=RealServer1 -tdi ubuntu
docker run --privileged --name=RealServer2 -tdi ubuntu

命令讲解：

docker run：创建 docker 容器

name 参数：给容器命名，方便区分

tid 参数：分配 tty，能够与之交互

ubuntu：指定容器镜像，这里使用 ubuntu 镜像

此处输入图片的描述

创建命令执行完成后，目前有两个 container：

RealServer1：IP 地址为 192.168.0.2。下文简称 RIP1
RealServer2：IP 地址为 192.168.0.3。下文简称 RIP2

可以通过 ifconfig 命令查看各自的 IP 地址，此处的地址是因为按顺序，且按默认配置创建所导致

2.4.3 配置服务器池成员

RealServer 部署 Nginx 来提供 Web 服务，RealServer1 和 RealServer2 操作步骤相同，此处以 RealServer1 为示例：

首先登录 RealServer1:

# 通过 attach 命令登录 RealServer1
docker attach RealServer1

安装相关工具

apt-get update
apt-get install vim -y 
apt-get install nginx -y
service nginx start

为了区分 RealServer1 和 RealServer2 的 Nginx 响应页面，需要修改默认 nginx 的展示 html 页面。

#进入 RealServer1 container 环境
vi /usr/share/nginx/html/index.html

图片描述

按 i 键插入，按 esc 再输入 :wq 保存退出。

注意若完成了 RealServer1 的配置之后，如果我们不想打开新的终端，可以通过 ctrl+p+q 的组合快捷键脱离当前机器的登录，切勿使用 exit 的方式退出 container，这样的方式关闭服务器的。脱离之后便会返回到 shiyanlou 的 zsh 交互，可以通过 docker attach RealServer2 的命令来登录另一台机器，然后做类似的操作（同上的软件安装操作以及 nginx 启动操作）

接下来就修改 nginx 页面，如下所示：

#在 RealServer2 container 环境
vi /usr/share/nginx/html/index.html

图片描述

完成两台服务器的配置之后，我们通过 service nginx start 启动服务器中 nginx 服务。

至此我们完成两台 Web 服务器的配置，我们可以打开宿主机 firefox 浏览器，地址栏分别输入两个 IP 地址，来检验我们的配置成功：

此处输入图片的描述

2.4.4 配置调度器规则

1.为避免影响实验结果，关闭宿主机环境的 nginx 服务：

sudo service nginx stop

LoadBalancer 的对外 IP 地址为 VIP，即 VIP 地址为 120.26.15.9 （注意，你的 VIP 地址可能和我的不一样，根据自己实际情况来）。对内 IP 称为 RIP，此时 RIP 为 192.168.0.1。

2.开启 LoadBalancer 的内核路由转发：

echo '1' | sudo tee /proc/sys/net/ipv4/ip_forward

查看当前机器内核路由转发开启情况：

cat /proc/sys/net/ipv4/ip_forward

得到的值为 1，说明此机器已开启内核路由转发。进行下一步。

4.使用 ipvsadm 添加 ipvs 规则。定义集群服务：

sudo ipvsadm -A -t 120.26.15.9:80 -s rr         #定义集群服务
sudo ipvsadm -a -t 120.26.15.9:80 -r 192.168.0.2 -m #添加 RealServer1
sudo ipvsadm -a -t 120.26.15.9:80 -r 192.168.0.3 -m #添加 RealServer2
sudo ipvsadm -l                 #查看 ipvs 定义的规则

上面命中 ipvsadm 参数讲解：

# 添加集群服务
-A：添加一个新的集群服务
-t: 使用 TCP 协议
-s: 指定负载均衡调度算法
rr：轮询算法(LVS 实现了 8 种调度算法)
120.26.15.9:80 定义集群服务的 IP 地址（VIP） 和端口

# 添加 Real Server 规则
-a：添加一个新的 RealServer 规则
-t：tcp 协议
-r：指定 RealServer IP 地址
-m：定义为 NAT 
上面命令添加了两个服务器 RealServer1 和 RealServer2

图片描述

2.4.5 测试配置

打开浏览器，输入 VIP 地址：120.26.15.9：

图片描述

可以发现，我们访问 VIP 地址，得到的是 RealServer1 的 Nginx 响应页面。多次刷新页面，页面也会发生变化：

图片描述

因为访问压力比较小，调度算法不会请求切换服务器，可以按住 F5 快速多次刷新查看页面变化效果

以上便实现了 LVS 的 NAT 负载均衡系统。

LVS/DR 搭建

与 NAT 方式相同，我们将通过 docker 来模拟我们的集群环境。

集群系统中，服务器资源可以简单分为两种角色：

一种是 Load Balancer，即负载均衡调度器，位于集群系统的前端，对后端服务器实现负载均衡作用，对外 IP 地址也称为 VIP（虚拟 IP 地址）。
另一种就是后端服务器群，处理由 Load Balancer 发来的请求。

整个集群系统结构：

宿主机环境（默认桌面环境）：充当客户端访问 web 服务
LoadBalancer1 的 container：装有 ipvsadm，充当负载均衡调度器
RealServer1 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员
RealServer2 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

若是我们沿用 NAT 的实验环境，我们需要做环境的清理：

1.首先清除 ipvsadm 的规则：

sudo ipvsadm -C

2.删除之前所创建的 container，虽然都是提供 Web 服务，但是在 DR 模式中需要修改内核参数与创建网卡别名，需要超级权限，所以不能沿用之前的 container：

# 关闭所有的 container
docker stop `docker ps -aq`
# 删除所有的 container
docker rm `docker ps -aq`

3.4.1 安装 ipvsadm 工具

因为在 NAT 实验中我们已安装所以可跳过该步骤，若是新启动的环境请参考 NAT 中的步骤，此处提示务必在宿主机环境中执行 ipvsadm -L 的验证步骤，若是不执行该步骤，在 LoadBalancer 的 container 中我们将无法加载 IPVS 的内核模块。

3.4.2 创建与配置服务器池成员

同样我们使用 docker 来模拟我们的集群环境，创建三台 container：

docker run --privileged --name=LoadBalancer -tid ubuntu
docker run --privileged --name=RealServer1 -tid ubuntu
docker run --privileged --name=RealServer2 -tid ubuntu

其中 --privileged 参数用于给予容器超级权限。

完成我们服务器池成员的创建之后，我们参照 NAT 中配置步骤完成 RealServer 中的：

nginx 与 vim 的安装
默认展示页面的修改
nginx 服务的启动

在完成这样的配置之后我们需要一些额外的操作：

1.修改内核参数

以 RealServer1 为例，登录 container：

执行下列命令：

# 设置只回答目标IP地址是来访网络接口本地地址的ARP查询请求 
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

# 为了保险自己可以查看一下是否成功修改
cat /proc/sys/net/ipv4/conf/lo/arp_ignore

# 设置对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送.
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce

# 使得上面的配置立即生效
sysctl -p

ARP 的内核参数： arp_ignore 部分参数：定义了本机响应 ARP 请求的级别

0 表示目标 IP 是本机的，则响应 ARP 请求。默认为 0

1 如果接收 ARP 请求的网卡 IP 和目标 IP 相同，则响应 ARP 请求

arp_announce 参数：定义了发送 ARP 请求时，源 IP 应该填什么。

0 表示使用任一网络接口上配置的本地 IP 地址，通常就是待发送的 IP 数据包的源 IP 地址。默认为 0

1 尽量避免使用不属于该网络接口(即发送数据包的网络接口)子网的本地地址作为 ARP 请求的源 IP 地址。大致的意思是如果主机包含多个子网，而 IP 数据包的源 IP 地址属于其中一个子网，虽然该 IP 地址不属于本网口的子网，但是也可以作为ARP 请求数据包的发送方 IP。

2 表示忽略 IP 数据包的源 IP 地址，总是选择网络接口所配置的最合适的 IP 地址作为 ARP 请求数据包的源 IP 地址(一般适用于一个网口配置了多个 IP 地址)

2.配置网卡别名

只有目的 IP 是本机器中的一员时才会做相应的处理，所以需要添加网卡别名：

# 配置虚拟IP
ifconfig lo:0 192.168.0.10 broadcast 192.168.0.10 netmask 255.255.255.255 up

# 添加路由，因为本就是相同的网段所以可以不添加该路由
route add -host 192.168.0.10 dev lo:0

service networking restart

图片描述

同两台 Web 服务器中都做该配置，即完成了所有 Web 服务器所需的配置工作。

3.4.3 配置调度器规则

紧接着我们登录 LoadBalancer 机器：

docker attach LoadBalancer

安装 ipvsadm 软件：

apt-get update
apt-get install -y ipvsadm
ipvsadm -L #查看 ipvsadm 能否正常使用

图片描述

创建 eth0 的别名并绑定 VIP 地址，作为集群同时使用：

ifconfig eth0:0 192.168.0.10 netmask 255.255.255.0 up

查看网卡信息：ifconfig

图片描述

在 LoadBalancer 中添加 IPVS 规则：

ipvsadm -A -t 192.168.0.10:80 -s rr         # 定义集群服务
ipvsadm -a -t 192.168.0.10:80 -r 192.168.0.3 -g # 添加 RealServer1
ipvsadm -a -t 192.168.0.10:80 -r 192.168.0.4 -g # 添加 RealServer2
ipvsadm -l                  # 查看 ipvs 定义的规则

ipvsadm 命令参数讲解：

# 添加集群服务
-A：添加一个新的集群服务
-t: 使用 TCP 协议
-s: 指定负载均衡调度算法
rr：轮询算法(LVS 实现了 8 种调度算法)
192.168.0.10:80 定义集群服务的 IP 地址（VIP） 和端口

# 添加 Real Server 规则
-a：添加一个新的 RealServer 规则
-t：tcp 协议
-r：指定 RealServer IP 地址
-g：定义为 DR 模式
上面命令添加了两个集群服务器 RealServer1 和 RealServer2

图片描述