几种负载均衡优缺点
近期读 《构建高性能WEB站点(完整版)》这本书，其中有很多技术平时虽然遇到过，但也没有具体记录过程，就此机会做笔录。
一、DNS负载均衡
[well]
最先接触负载之一，如果有自己的DNS服务器，这种方式很好实施的。实现也很简单。增加多个A记录或者使用cname
例如：
| facebook.com. | 2254 | IN | A | 69.63.176.140 |
| facttbook.com. | 2254 | IN | A | 69.63.178.11 |
| facebook.com• | 2254 | IN | A | 69.63.184.142 |
但是问题一般不会有自己的DNS服务，而使用服务商的DNS服务时，缓存太严重还不一定支持多条A记录，记得万维网的DNS服务生效可能有一天时间，这样对业务影向太大。
原文描述：
DNS服务器充当了一个粗放型的済求调度器，这给我们带来了一些遗憾，在这种 情况下，如何让多台实际服务器最大程度地保持比较均衡的负载，是我们筘要持续考虑的 问题。
这里顺便说一下，所谓的“均衡”，不能狭义地理解为分配给所有实际服务器的工作量一 样多，因为有时候，多台服务器的承载能力各不相同，这可能体现在硬件配置、网络带宽 的差异，也可能因为某台服务器身兼多职，我们所说的“均衡”，也就是希望所有服务器 都不要过载，并且能够最大程度地发挥作用。
二、反向代理负载均衡
常用负载技术，还可以根据权重分配real server这个是DNS方式解决 不了，也可以做为缓存使用，
Nginx,作为反向代理服务器， 也就是负载均衡调度器，并为它配置两个后端服务器，如下所示：
upstream backend {
server 10.0.1.200:80;
server 10.0.1.201:80;
}
以上的配置只是这里提到的关键部分，更多的配置你可以查阅Nginx的官方文档，里面有 很详细的介绍。
对反向方式 权重比率非常重要，本文指出独立服务器处理能力的比率是吞吐率最好配置
缺点：对于反向代理本身的处理能力，文章指出：
我们知道反向代理服务器工作在HTTP层面，对于所有HTTP请求都要亲自转发，可谓是 大事小事亲历亲为，这也让我们为它捏了一把冷汗，你也许在怀疑它究竟有多大能耐，能 支撑多少后端服务器，的确，这直接关系到整个系统的扩展能力。
而且，个人感觉，做为反向代理，又接收HTTP还要转发处理 ，其并发处理能力会有折扣。
三、Netfilter/iptables
摘录文章描述：
从Linux 2.4内核开始，其内置的Netfilter模块便肩负起这样的使命，它在内 核中维护着一些数据包过滤表，这些表包含了用于控制数据包过滤的规则。
我们知道，当网络数据包到达服务器的网卡并且进入某个进程的地址空间之前，先要通过 内核缓冲冈，这时候内核中的Netfilter便对数据包有着绝对控制权，它可以修改数据包， 改变路由规则。
既然Netfilter工作在内核中,我们看不见摸不着,那么如何让它按照我们的需要來工作呢？ Linux提供了 iptables，它是工作在用户空间的一个命令行工具，我们可以通过它来对 Netfiltei•的过滤表进行插入、修改或删除等操作，也就是建立了与Netfilter■沟通的桥梁， 告诉它我们的意图。
那么，我们要做的就是让Linux服务器成为连接外部网络和私有网络的路由器，俏这不是 普通的路由器，我们知道路由器的工作是存储转发，除了修改数据包的MAC地址以外， 通常它不会对数据包做其他手脚，而我们要实现的路由器恰恰是要对数据包进行必要的修 改，包括来源地址和端口，或者目标地址和端n。
总之，Linux内核改变数据包命运的惊人能力，决定了我们可以构建强大的负载均衡调度 器，将请求分散到其他实际服务器上。
说到iptables,最多的应用场景就是防火墙了，我几乎为每台Linux服务器都毫不犹豫地 进行iptables防火墙配置，比如以下这段简单的iptables规则：
iptables -F INPUT
iptables -A INPUT -i ethO -p tcp –dport 80 -j ACCEPT iptables -P INPUT DROP
它完成了熏要的任务，那就是告诉内核只允许外部网络通过TCP与这台服务器的80端U 建立连接，这项规则可以很好地用在Web服务器上。
另外，我们还会用iptables来实现本机端口重定向，比如以下的规则.•
iptables -t nat -A PREROUTING -i ethO -p tcp —dport 80 -j REDIRECT —to-port 8000
它将所有从外部网络进入服务器80端U的请求转移到了 8000端口，这有什么意义呢？当 然是隐藏某些服务的实际端口，同时也便于将一个端口快速切换到其他端口的服务上，提 高端口管理的灵活性。
关键的时刻到了，我们将用iptables来实现NAT，在此之前，我们需要执行以下的命令行 操作：
echo 1 > /proc/sys/net/ipv4/ip_forward 这意味着该服务器将被允许转发数据包，这也为它成为NAT服务器提供了可能。
接下来，我们在作为调度器的服务器上执行以下的iptables规则：
iptables -t nat -A PREROUTING -i ethO -p tcp –dport 8001 -j DNAT –to-destination 10.0.1.210:8000
这条规则几乎完成了所有DNAT的实现，它将调度器外网网卡上8001端口接收的所有请 求转发给10.0.1.210这台服务器的8000端口，至于转发的具体过程，前面我们已经详细 介绍过，在此不再赘述。
同样，我们在调度器上执行以下的iptables规则：
iptables -t nat -A PREROUTING -i ethO -p tcp –dport 8002 – j DNAT –to-destination 10.0.1.211:8000
不用多说，这条规则你一定明白了。
这两条规则已经进入了 Netfiltei•的过滤表，我们可以通过iptables命令来查看它们，如下
所示：
s-director:- # iptables -nL -t nat Chain PREROUTING (policy ACCEPT)
Target prot opt source destination
DNAT tcp — 0.0.0.0/0 0.0.0.0/0 tcp <^>t:8001 to:10.0.1.210:8000 DNAT tcp — 0.0.0.0/0 0.0.0.0/0 tcp<^>t:8002 to:10.0.1.211:8000
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
可以看到，转发规则己经存在，但是还缺少一个环节，这至关重要，我们必须将实际服务 器的默认网关设置为NAT服务器，也就是说，NAT服务器必须为实际服务器的网关，否 则，数据包被转发后将一去不返。
添加默认网关非常容易，在实际服务器上执行以下命令行操作： route add default gw 10.0.1.50
现在，查看路由表，刚才的默认网关已经出现了:
s-rs:〜# route Kernel IP routing table Destination Gateway 10.0.1.0 * 125.12.12.0 * link-local * loopback * default 10.0.1.50
现在，我们终于可以通过调度器的800丨和8002端口分别将请求转发到两个实际服务器上， 可是，回想前面的问题，用iptables来实现负载均衡调度器，看起来有点困难，iptab丨es似 乎只能按照我们的规则来干活，没有调度器应该具备的调度能力和调度策略。
接下来，IPVS上场的时刻到了。
四、IPVS/ipvsadm 也可称LVS
IPVS不仅可以实现基于NAT的负载均衡，同时还包括后面要介绍的直接路由和IP隧道 等负载均衡。令人振奋的是，IPVS模块己经内置到Umix2.6.x内核中,这意味着使用Linux 2.6.x内核的服务器将无须重新编译内核就可以直接使用它。
最重要的是了解 LVS的几种调度方式 RR、DR、TUN
LVS-NAT中，我们使用了 RR调度策略，它是一种静态调度策略，当在集群中 实际服务器承载能力相当的环境下，它可以很好地实现均衡调度。同时，LVS也支持带权 重的RR调度，只需要配置实际服务器的weight值即可，当然，这也属于静态调度策略》
除此之外，LVS提供了一系列的动态调度策略，比如最小连接（LC)、带权重的最小连 接(WLC)、最短期望时间延迟（SED)等，它们都可以根据实际服务器的各种实时状态 做出调度决策，可谓是察言观色，全面兼顾。
LVS—DR，不同于NAT机制，直接路由方式下的负载均衡调度器工作在数据链路层（第二层），简 单地说，它通过修改数据包的目标MAC地址，将数据包转发到实际服务器上，并且最重 要的是，实际服务器的响应数据包将直接发送给用户端，而不经过调度器。即配置个虚拟IP （使用IP别名） real server 要在同一WAN网段，文章：LVS-DR非常适合搭建可扩展的负载均衡系统，不论是Web服务器还是文件 服务器，以及视频服务器，它都拥有出色的表现。但前提是，你必须为实际服务器购买一 系列的合法IP地址，不过，相比于负载均衡硬件设备，它们还是要便宜得多。
LVS－TUN，
也称为LVS-TUN。与LVS-DR不同的是，实酥服务器可以和调度器不在同一个 WAN网段，调度器通过IP隧道技术来转发请求到实际服务器，所以实际服务器也必须拥 有合法的IP地址。
基于IP隧道的请求转发机制，简单地说，它是将调度器收到的IP数据包封装在一个新的 IP数据包中，转交给实际服务器，然后实际服务器的响应数据包可以直接到达用户端。
总的来说，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，可以非常有效 地提高集群的扩展能力，但如何选择它们，更多的不是因为性能和扩展性，而是取决于你 的网络部署需要，比如刚才提到的CDN服务需要将实酥服务器部署在不同的IDC，从而必须使用IP隧道技术。
一般大型网站会混合使用上面几种技术，比如先DNS 负载。再LVS－NET，LVS—DR，LVS—TUN中型网站直接nginx反向/DNS就很适合，当然还少不了LVS+keepalived 做到易扩展，强容灾。
[/well]
