我们接着上一章节讲解。
LVS-DR
接下来，我们在作为调度器的服务器上通过 ipvsadm 命令进行以下配置：
ipvsadm -A -t 125.12.12.77:80 -s rr ipvsadm -a -t 125.12.12.77:80 -r 125.12.12.20:80 -g ipvsadm -a -t 125.12.12.77:80 -r 125.12.12.21:80 -g
有了配置 LVS-NAT 的经验后，你应该已经非常熟悉上述配置规则，这里我们仍然使用了 RR 调度策略，有所不同的是，在添加实际服务器的时候，我们使用了-g 选项，这意味着告诉调度器使用直接路由的方式转发数据包。
这时候我们通过 ipvsadm 命令可以看到以下的状态：
s-director:~ # ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 125.12.12.77:80 rr -> 125.12.12.20:80 Route 1 0 0 -> 125.12.12.21:80 Route 1 0 0
需要注意的是，在使用直接路由进行转发的情况下，我们无法修改数据包的目的端口，原因很简单，我们知道这种转发机制工作在数据链路层，所以对于上层的端口信息，它无能为力。
也许你已经感觉到，一旦熟悉了 LVS-NAT 的配置方式后，就可以很容易地将其改进为直接路由方式。
与LVS-NAT 的性能比较
你最关心的时刻到了，我们来对基于直接路由的调度器进行压力测试，同样是针对之前的一系列不同开销的内容。我们照例将测试结果补充到前面的表 2-7 中，但是这次我们去掉了反向代理的那一列，因为我们这里主要关注的是 LVS-DR 和 LVS-NAT的比较，压力测试结果如表 2-9 所示。
表 2-9 实际服务器、LVS-NAT、LVS-DR 分别对于不同内容的压力测试结果
同样，我们将这些数据绘制成对比曲线图，更加直观地观察它们的变化趋势，如图 2-18 所示。
图 2-18 实际服务器、反向代理、LVS-NAT、LVS-DR 分别对于不同内容的压力测试结果对比曲线图
可以看到，LVS-DR 的表现几乎和 LVS-NAT 旗鼓相当，同时，它们都远远超过了基于反向代理的负载均衡系统。那么，相比于 LVS-NAT，LVS-DR 的优势在哪里呢？还记得这种方式的最大特点吗？那就是实际服务器的响应数据包可以不经过调度器而直接发往用户端，如图 2-19 所示，这也是它最大的优势，显然，要让它发挥这种优势，我们希望响应数据包的数量和长度远远大于请求数据包，事实上，大多数 Web 服务正是具备这样的特点，响应和请求并不对称，即便是几十 KB 的网页下载，响应数据包也是请求数据包的很多倍，更不要说大文件的下载。
图 2-19 LVS-DR 的流量走向图
这样一来，大量的响应数据包便可以绕过调度器，避免了 LVS-NAT 中调度器的带宽瓶颈，为此，我们来做一个实验，同样基于刚才的网络结构，但是我们在 WAN 交换机上将调度器（10.12.12.12）和两台实际服务器（125.12.12.20、125.12.12.21）的带宽限制为 10Mbps，但不限制 125.12.12.10 这台服务器，它的带宽保证在 100Mbps，因为我们需要通过它来发起测试，事实上也可以假想它就是网关出口。
接下来，我们对实际服务器、LVS-NAT 和 LVS-DR 分别进行了压力测试，这次被测试的内容是一个大小为 22KB 的静态内容，你可以把它当作一个站点的首页 HTML。
测试结果如表 2-10 所示。
表 2-10 针对 22KB 静态内容的压力测试结果对比
测试服务器吞吐率（reqs/s）数据流量（KB/s）带宽使用量（Kbps）实际服务器 151.751134.449075.52可以看到，对于前两台实际服务器，吞吐率基本相当，但是我们关心的是数据流量，因为这时候显然带宽成为制约吞吐率的瓶颈，从测试结果上看，带宽使用量接近 10Mbps，但实际上不可能达到理论上的 10Mbps，因为还存在交换机和服务器用户进程对数据包的处理时间。
第三行的 LVS-NAT 意味着调度器通过 NAT 方式将请求分散到前两台实际服务器，这里我们对于连接调度器和两台实际服务器的 LAN 交换机并没有限速，仍然是 100Mbps 的全双工模式，但是我们知道，调度器在 WAN 交换机上的出口带宽已经被限制为了 10Mbps。从测试结果上看，LVS-NAT 并没有提高整体吞吐率，它的瓶颈仍然是调度器的带宽。
最后的 LVS-DR 让我们眼前一亮，数据流量几乎翻了一番，吞吐率自然也随之翻倍，现在你知道 LVS-DR 的优势所在了吧。
虽然这个实验中我们只是将带宽限制到了 10Mbps，但是对于 100Mbps 甚至更高的带宽，其本质都是一样的，我们假设一个理想的带宽配置，如图 2-20 所示。
可以看到，即使调度器只有 100Mbps 的带宽，整个集群也可以通过增加大量的实际服务器来达到 1Gbps 的流量，也就是 WAN交换机的出口带宽，这充分体现了 LVS-DR 的强大扩展能力。
图 2-20 LVS-DR 的理想带宽配置
由于测试环境的局限，这里我们无法测试 LVS-DR 究竟可以扩展多少台实际服务器，但可以肯定的是，这时候的瓶颈更多地转移到了 WAN 的出口带宽，相比之下，其他在单机上的问题将显得微不足道，因为你可以增加更多的实际服务器来分散诸如 CPU 和磁盘 I/O 等开销。
另一个关键的因素在于，响应数据包和请求数据包的比例，因为从调度器发出请求数据包的速度也是有上限的，是否能够让这些有限的请求数据包引发最大程度的响应风暴，也影响到整个系统的扩展能力。所以，越是响应数据包远远超过请求数据包的服务（如视频），就越应该降低调度器转移请求的开销，也就越能够提高整体扩展能力，最终也就越依赖于 WAN 出口带宽。来自 LVS 官方站点的早期测试结果也告诉我们，LVS-DR 可以容纳 100 台以上的实际服务器，我想对于某些特定的场景，这样的表现没有任何问题。
转型到DNS-RR
除了性能和扩展性的优势之外，LVS-DR 也非常便于管理，这得益于所有的实际服务器都直接接入 WAN，所以你完全可以直接通过安全 SSH 来登录它们进行各种操作。
而对于 LVS-NAT，你必须登录调度器才可以访问位于 LAN 的实际服务器，这给管理大量的机器带来不便，但这还不算什么，
它也许会给你带来一些安全感。关键问题在于，一旦调度器有朝一日出现故障无法登录，那实际服务器便和你完全隔离了。当然，办法也是有的，你可以让其中某台实际服务器也接入 WAN，作为冗余“跳板机”，或者设置备用调度器，通过 Heartbeat来完成自动故障转移，随后我们会介绍这方面的内容。
当然，闲置一台备用调度器，对于一些普通规模的站点来说，可能并不愿意。幸运的是，对于 LVS-DR，一旦调度器失效，你可以马上将 LVS-DR 切换到 DNS-RR 模式，这几乎只需要增加几条 DNS 记录，将域名解析到多台实际服务器的真实 IP 地址即可。一旦调度器恢复后，你便可以再次修改 DNS 记录，将域名仅指向调度器，切换回 LVS-DR。
总的来说，LVS-DR 非常适合搭建可扩展的负载均衡系统，不论是 Web 服务器还是文件服务器，以及视频服务器，它都拥有出色的表现。但前提是，你必须为实际服务器购买一系列的合法 IP 地址，不过，相比于负载均衡硬件设备，它们还是要便宜得多。
感觉本站内容不错，读后有收获？小额赞助,鼓励网站分享出更好的教程