注意：图里面 "客户IP->路由器"， "路由器-> 调度器" 里面的 "D_IP" 应该写错了，应该是 172.1.1.254
简略实验的架构图:
实验配置要点
【client】
1>--> ip
【router】
1>-->ip
2>-->iptables
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 172.1.1.254
3>--> ip_forward
4 -> testing [测试路由,简单的在director那儿安装个web，看路由能否成功~]
【director】
1--> ip -> (gw) -->指上层的router！
2--->ip_forward
3---->yum install -y ipvsadm
\-> ipvsadm -A -t 172.1.1.254:80 -srr ///rr-->代表轮叫调度!关于调度算法,下面还有介绍! lc->least-connection, dh-->destination hash 等~
ipvsadm -a -t 172.1.1.254:80 -r 10.1.1.12:80 -m //m -->代表 nat架构! "g"代表的是DR架构！
ipvsadm -a -t 172.1.1.254:80 -r 10.1.1.12:80 -m
ipvsadm -a -t 172.1.1.254:80 -r 10.1.1.13:80 -m
ipvsadm -a -t 172.1.1.254:80 -r 10.1.1.14:80 -m
4----> ipvsadm -L -n [用watch 就可以动态监控了]
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.1.1.254:80 rr
-> 10.1.1.12:80 Masq 1 0 3
-> 10.1.1.13:80 Masq 1 0 3
-> 10.1.1.14:80 Masq 1 0 3
ActiveConn---->如果正在下载的话,就会有活动连接!
【real server】
1---> ip -> (gw)
2--->web service
另:需要注意的是, nat架构的缺点分析，经过实验可以验证，当并发量很大的时候，系统会跑得比较慢。几乎性能好一点的服务器，用nat架构，当并发量达到2万的时候，就开始有点慢了。因为nat需要来回地进行IP地址的转换，很耗CPU等资源。所以，继续做了直接路由架构的试验。DR架构利用了数据链路层的MAC地址。在调度器那儿将目的MAC改成了REAL SERVER的MAC，然后又神奇地在REAL SERVER用了“虚拟IP”，于是可以解开链路层传过来IP包，并且能成功地将数据返还给上上层的路由器。关于技术要点以及实验设计图会继续做研究。
调度算法:
[附简单说明, 个人理解! 更多详细信息,可以查阅LVS官方手册或RedHat官方手册]
a. 轮叫调度 (Routing-Robin Scheduling)
\--->循环调度, 以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i=(i+1)mod n,并选出第i台服务器。算法优点: 简洁，无需记录当前的连接状态，它属于无状态调度。该算法容易导致服务器间的负载不均衡。譬如下载服务，当某一台下载结束，它的工作就完成了，它空闲了，但是如果其他几台服务器的下载很忙，而这台闲置的服务器也帮不上忙。它不能平均地分配网络连接。但是由于简单，用来测试还是很好的。
b.加权轮叫调度 (Weighted Round-Robin Scheduling)
\--->权值的作用就不多说了，很多算法有了它就变得神奇了，变得灵活了。在这里，权值的引入可以有效地解决服务器间性能不一的情况。服务器的权值缺省值为1.通过加权值的方法，可以将某些性能很好的服务器得到更多的应用，而让一些老机器以及性能弱一点的就处理少一点的响应。同样，加权轮叫调度也无需记录当前所有连接的状态，所以它也是一种无状态调度。
c.最小连接调度 (Least-Connection Scheduling)
\--->它的核心思想是将最新来的连接请求分配到当前连接数最少的服务器。它是一种动态调度算法，通过服务器当前活跃的连接数 来估计服务器的负载情况。客户端动态刷新和多次访问请求测试，然后通过"shell>watch ipvsadm -L -n"---->ActiveConn列可以看出, 它是根据这个活连接数来权衡的。实验的过程中要注意，将所有服务器的配置最好保持一致，这样才有很好的效果。如Web_Server，如果你将某些的 KeepAlive 关闭而某些打开，明显可以看得出那些打开了 KeepAlive 得到新连接的机会要少很多，因为它的ActiveConn 连接数会保持很多。所以有必要的话，做这个实验的时候将 KeepAlive打开然后关闭，效果会很好。 另外要注意的是，当各个服务器的处理能力不同时，该算法依然不够理想，因为TCP连接处理请求后会进入TIME_WAIT状态，TCP的TIME_WAIT一般为2分钟，此时可能连接已经处理完了，但是它还占用服务器的资源，连接处于TIME_WAIT的状态，而性能低的服务器，忙于处理所收到的连接同时还要不断地接收新的连接。
d.加权最小调度连接 (Weighted Least-Connection Scheduling)
\--->服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
e.基于局部性的最少连接调度 (Locality-Based Least Connections Scheduling)
f.带复制的基于局部性最少连接调度 (Locality-Based Least Connections with Repulication Scheduling)
\--->[只讲到应用，算法本身的说明略]这个的应用得讲到鱿鱼[squid], 代理服务器 [有了代理, 速度快了，因为它可以将apache返回的数据缓存到mem或disk中]。假设一台apache服务器，有多个代理squid. 某一个squid里面的hot_point [热点请求], 多个squid之间可以进行相互复制，这样会更高效地满足大部分用户的连接请求。当然squid需要配置，还得用到autofs，这个实验还有待研究。
g.目标地址散列调度 (Destination Hashing Scheduling)
\--->[只讲到应用，算法本身略]可以将某个客户端的页面请求与某个网页服务器进行绑定。通过使用rr [轮叫]的一个实验，将服务器的访问日志清空，然后客户端请求一个页面然后刷新，然后监控调度器，会看到多个服务器都被访问了，并且返回个客户端的内容都不一样！这样我们就必须考虑到一个问题，关于Cookies和Session。网站设计必须会用到的一个技术就是session技术。用户登录了之后，就可以访问该网站的其他信息了，session有生命周期。如果有必要的话，可以用Cookies保存用户信息到客户端。下次登录可以用到。这样就与我们的调度有了冲突了，因为如果用户访问了不同的web_server之后，由于session是保存在服务器端，用户访问一个网站，还需要用到多台服务器的话，那么session很有可能会过期，如果session技术可以改进，可以指定服务器然后保存会话 [个人idea]，那对调度算法就要求没这么高了。
h.源地址散列调度 (Source Hashing Scheduling)
Appendix
From红帽6官方手册:
Scheduling Algorithms
The structure that the IPVS table takes depends on the scheduling algorithm that the administrator chooses for any given virtual server. To allow for maximum flexibility in the types of services you can cluster and how these services are scheduled, Red Hat Enterprise Linux provides the following scheduling algorithms listed below. For instructions on how to assign scheduling algorithms refer toSection 4.6.1, “The VIRTUAL SERVER Subsection”.Round-Robin Scheduling
- Distributes each request sequentially around the pool of real servers. Using this algorithm, all the real servers are treated as equals without regard to capacity or load. This scheduling model resembles round-robin DNS but is more granular due to the fact that it is network-connection based and not host-based. Load Balancer Add-On round-robin scheduling also does not suffer the imbalances caused by cached DNS queries.
Weighted Round-Robin Scheduling
- Distributes each request sequentially around the pool of real servers but gives more jobs to servers with greater capacity. Capacity is indicated by a user-assigned weight factor, which is then adjusted upward or downward by dynamic load information. Refer to Section 1.3.2, “Server Weight and Scheduling” for more on weighting real servers. Weighted round-robin scheduling is a preferred choice if there are significant differences in the capacity of real servers in the pool. However, if the request load varies dramatically, the more heavily weighted server may answer more than its share of requests.
Least-Connection
- Distributes more requests to real servers with fewer active connections. Because it keeps track of live connections to the real servers through the IPVS table, least-connection is a type of dynamic scheduling algorithm, making it a better choice if there is a high degree of variation in the request load. It is best suited for a real server pool where each member node has roughly the same capacity. If a group of servers have different capabilities, weighted least-connection scheduling is a better choice.
Weighted Least-Connections (default)
- Distributes more requests to servers with fewer active connections relative to their capacities. Capacity is indicated by a user-assigned weight, which is then adjusted upward or downward by dynamic load information. The addition of weighting makes this algorithm ideal when the real server pool contains hardware of varying capacity. Refer toSection 1.3.2, “Server Weight and Scheduling” for more on weighting real servers.
Locality-Based Least-Connection Scheduling
- Distributes more requests to servers with fewer active connections relative to their destination IPs. This algorithm is designed for use in a proxy-cache server cluster. It routes the packets for an IP address to the server for that address unless that server is above its capacity and has a server in its half load, in which case it assigns the IP address to the least loaded real server.
Locality-Based Least-Connection Scheduling with Replication Scheduling
- Distributes more requests to servers with fewer active connections relative to their destination IPs. This algorithm is also designed for use in a proxy-cache server cluster. It differs from Locality-Based Least-Connection Scheduling by mapping the target IP address to a subset of real server nodes. Requests are then routed to the server in this subset with the lowest number of connections. If all the nodes for the destination IP are above capacity, it replicates a new server for that destination IP address by adding the real server with the least connections from the overall pool of real servers to the subset of real servers for that destination IP. The most loaded node is then dropped from the real server subset to prevent over-replication.
Destination Hash Scheduling
- Distributes requests to the pool of real servers by looking up the destination IP in a static hash table. This algorithm is designed for use in a proxy-cache server cluster.
Source Hash Scheduling
- Distributes requests to the pool of real servers by looking up the source IP in a static hash table. This algorithm is designed for LVS routers with multiple firewalls.