组建集群面临的问题有很多，下面有三个例子：

问题1：http是无状态的连接，需要借助cookie和session实现客户端追踪，session是基于cookie的id号工作的，当前端代理服务器不能识别客户端是否曾经来过，所以将客户端请求轮询调度给后端多个http服务器进行处理，这样使得每个客户的session不能保持

问题2：应用程序服务器将数据读写请求轮询发送给后端多个数据库服务器，这样使得数据读取和写入紊乱，这时需要数据库的主从复制，当执行写操作时，往单台数据库服务器上写，通过同步同步到其他，执行读操作时，多台数据库服务器可以均摊

问题3：应用程序服务器再前段web服务器和后端数据库服务器之间，它既要处理web服务器发来的动态请求，又要实现发给数据库服务器读写请求时实现分路读写分离调度---这个可以让程序员做程序时对于写操作指定哪个主机，对于读操作时，定义一个简单的轮询机制，还可以在他们之间再加中间调度层，这个中间层还应该能实现拼凑来自各个数据库服务器上的离散的数据。

系统衡量标准：                对于系统运维：
    1.可扩展性                       可用

    2.可用性                         标准化

    3.容量                            自动化

    4.性能

负载均衡调度器：整个业务的请求入口，尽量让它仅处理请求报文，不处理响应报文以减少它的压力

lvs实现基于tcp和udp对服务进行负载均衡调度，四层转发机制

netfilter工作机制：
    PREROUTING --> INPUT
    PREROUTING --> FORWARD --> POSTROUTING
    OUTPUT --> POSTROUTING

DNAT工作方式：PREROUTING---->POSTROUTING

lvs工作机制：(不同于DNAT)

prerouting---->input------>postrouting根据端口判断服务类型后强行将送往内核的请求改道至postrouting链发往后端集群

工具：
    ipvsadm: 用户空间的命令行工具，用于管理集群服务；需要安装
    ipvs: 工作内核中netfilter INPUT钩子上；
支持TCP, UDP, AH, EST, AH_EST, SCTP等诸多协议；


lvs type:
    lvs-nat
    lvs-dr(direct routing)
    lvs-tun(ip tunneling)
    lvs-fullnat

工作模式介绍：
1.Virtual server via NAT（LVS-NAT）
优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，物理服务器可以分配Internet的保留私有地址，只有负载均衡器需要一个合法的IP地址。


缺点：扩展性有限。当服务器节点（普通PC服务器）数据增长到20个或更多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包都需要经过负载 均衡器再生。假使TCP包的平均长度是536字节的话，平均包再生延迟时间大约为60us（在Pentium处理器上计算的，采用更快的处理器将使得这个 延迟时间变短），负载均衡器的最大容许能力为8.93M/s，假定每台物理服务器的平台容许能力为400K/s来计算，负责均衡器能为22台物理服务器计 算。


解决办法：即使是是负载均衡器成为整个系统的瓶颈，如果是这样也有两种方法来解决它。一种是混合处理，另一种是采用Virtual Server via IP tunneling或Virtual Server via direct routing。如果采用混合处理的方法，将需要许多同属单一的RR DNS域。你采用Virtual Server via IP tunneling或Virtual Server via direct routing以获得更好的可扩展性。也可以嵌套使用负载均衡器，在最前端的是VS-Tunneling或VS-Drouting的负载均衡器，然后后面 采用VS-NAT的负载均衡器。


lvs-nat特性：
    多目标的DNAT(iptables)；它通过修改请求报文的目标IP地址(同时可能会修改目标端口)至挑选出某RS的RIP地址实现转发；
    (1) RS应该和DIP应该使用私网地址，且RS的网关要指向DIP；
    (2) 请求和响应报文都要经由director转发；极高负载的场景中，director可能会成为系统瓶颈；
    (3) 支持端口映射；
    (4) RS可以使用任意OS；
    (5) RS的RIP和Director的DIP必须在同一IP网络；

2.Virtual server via IP tunneling（VS-TUN）
我们发现，许多Internet服务（例如WEB服务器）的请求包很短小，而应答包通常很大。

优点：负载均衡器只负责将请求包分发给物理服务器，而物理服务器将应答包直接发给用户。所以，负载均衡器能处理很巨大的请求量，这种方式，一台负载均衡能 为超过100台的物理服务器服务，负载均衡器不再是系统的瓶颈。使用VS-TUN方式，如果你的负载均衡器拥有100M的全双工网卡的话，就能使得整个 Virtual Server能达到1G的吞吐量。


缺点：但是，这种方式需要所有的服务器支持"IP Tunneling"(IP Encapsulation)协议，我仅在Linux系统上实现了这个，如果你能让其它操作系统支持，还在探索之中。


lvs-tun特性：
    不修改请求报文的ip首部，而是通过在原有的ip首部（cip<-->vip）之外，再封装一个ip首部(dip<-->rip)；
    (1) RIP, DIP, VIP全得是公网地址；
    (2) RS的网关的不能指向DIP；
    (3) 请求报文必须经由director调度，但响应报文必须不能经由director；
    (4) 不支持端口映射；
    (5) RS的OS必须支持隧道功能；

 

3.Virtual Server via Direct Routing（VS-DR）
优点：和VS－TUN一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结 构，因此可以使用大多数操作系统做为物理服务器，其中包括：Linux、Solaris 、FreeBSD 、windows、IRIX 6.5；HPUX11等。


不足：要求负载均衡器的网卡必须与物理网卡在一个物理段上。


对于每一个real server，rip配置在物理网卡上，vip配置在lo接口的别名上，由lo接口响应给应用程序服务，要求从哪个接口进来的报文必须从哪个接口出去，应用程序构建成响应报文后传输给lo接口封装上vip，然后发还给通信的接口传回客户端

解决方案：

    1.静态绑定：路由器转发时，将Vip和director的mac地址绑定在一起，但是在director做了备份服务器的情况下不能用
    2.arptables：arp-tables：在real server上拒绝请求VIP的arp地址响应

    3.修改RS主机内核的参数

lvs-dr特性: direct routing
    它通过修改请求报文的目标MAC地址进行转发；
    Director: VIP, DIP
    RSs: RIP, VIP
    (1) 保证前端路由器将目标IP为VIP的请求报文发送给director;

    (2) RS的RIP可以使用私有地址；但也可以使用公网地址；
    (3) RS跟Director必须在同一物理网络中；
    (4) 请求报文经由Director调度，但响应报文一定不能经由Director；
    (5) 不支持端口映射；
    (6) RS可以大多数OS；
    (7) RS的网关不能指向DIP；

以上三种IP负载均衡技术的优缺点比较:
杂项　　　　　　　　　VS/NAT　　　　 VS/TUN　　　　　　VS/DR
服务器操作系统　　　　任意　　　　　　支持隧道　　　　　多数(支持Non-arp )
服务器网络　　　　　　私有网络　　　　局域网/广域网　　局域网
服务器数目(100M网络) 10-20　　　　　　100　　　　　　　多(100)
服务器网关　　　　　　负载均衡器　　　自己的路由　　　　自己的路由
效率　　　　　　　　　一般　　　　　　高　　　　　　　　最高


4.lvs-fullnat特性：
    director通过同时修改请求报文的目标地址和源地址进行转发；
    (1) VIP是公网地址；RIP和DIP是私网地址，二者无须在同一网络中；
    (2) RS接收到的请求报文的源地址为DIP，因此要响应给DIP；
    (3) 请求报文和响应报文都必须经由Director;
    (4) 支持端口映射机制；
    (5) RS可以使用任意OS；

调度算法介绍：
1.轮叫调度（Round Robin）(简称rr)
调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

2.加权轮叫（Weighted Round Robin）（简称wrr)
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

3.最少链接（Least Connections）(LC)  Overhead=Active*256+Inactive  

调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。

4.加权最少链接（Weighted Least Connections）(WLC)  Overhead=(Active*256+Inactive)/weight 计算结果小的接收请求   性能好的服务器权重较大
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

5.基于局部性的最少链接（Locality-Based Least Connections）(LBLC)----相当于动态dh，提高缓存命中率
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近 使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接” 的原则选出一个可用的服务器，将请求发送到该服务器。

6.带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）(LBLCR)
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器 组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台 服务器，将该服务器加入到服务器组中，将缓存复制到该服务器，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程 度。

7.目标地址散列（Destination Hashing）(DH)
“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

8.源地址散列（Source Hashing）(SH)
“源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

9. 最短的期望的延迟（Shortest Expected Delay Scheduling SED）(SED)
基于wlc算法。这个必须举例来说了
ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算
A(1+1)/1
B(1+2)/2
C(1+3)/3
根据运算结果，把连接交给C 。

10.最少队列调度（Never Queue Scheduling NQ）(NQ)
无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要在进行sed运算，相当于所有服务器连接数是0的时候是rr，非0时使用sed


http: stateless
session保持：
    1.session绑定：
        source ip hash
        cookie
    2.session集群：session复制（并发承载能力受限）               
    3.session服务器：提供一台单独的服务器存储session---例如memcached或redis---->基于键值存储