Linux 虚拟服务器集群 介绍
负载均衡架构
在负载均衡架构中，Director(dispatcher)负责接收客户端请求，并将请求按照某种算法分发到后台真正提供服务的服务器上，既可以基于硬件（F5）来实现，也可以基于软件来实现，基于软件实现的又分为四层交换：基于IP地址和端口组合起来对服务做重定向（LVS），七层交换：通常指的是反向代理（proxy）,例如 squid 等。而真正提供web服务的服务器称为 Real Server .每个服务器称为一个节点。
Linux Virtual Server
LVS 类似于 iptables 的架构，在内核中有一段代码用于实时监听数据包来源的请求，当数据包到达端口时做一次重定向，这一系列的工作必须在内核中实现，在内核中实现数据包请求处理的代码叫做 ipvs,ipvs仅仅提供了功能框架，还需要自己手动定义是数据对哪个服务的请求，而这种定义需要通过写规则来实现，写规则的工具就称为 ipvsadm 。
LVS目标：使用集群技术和 linux 操作系统实现一个高性能，高可用的服务器。它具有很好的伸缩性 (Scalability)、可靠性(Reliability)和可管理性(Manageability)。
LVS 负载均衡整体架构如上图所示，关于几个 IP 地址的解释：
Virtual IP (VIP) : Director 用来向客户端提供服务的IP地址；
Real IP (RIP) : 集群节点，后台真正提供服务的服务器，所使用的IP地址；
Client computer's IP (CIP) ：公网IP，客户端使用的IP地址.
根据前端的 Director 和后台 Real Server 的通信方式将 LVS分为三类：Network Address Translation （LVS-NAT）、Director routing（LVS-DR）、IP tunneling （LVS-TUN）.
1〉Virtual Server via Network Address Translation（LVS-NAT）
通过网络地址转换，Director 重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的 Real Server；Real Server 的响应报文通过 Director 时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
2〉Virtual Server via Direct Routing（LVS-DR）
通过改写请求报文的 MAC 地址，将请求发送到 Real Server，而 Real Server 将响应直接返回给客户。同 LVS-TUN 技术一样，LVS-DR 技术可极大地提高集群系统的伸缩性。这种方法没有 IP 隧道的开销，对集群中的真实服务器也没有必须支持 IP 隧道协议的要求，但是要求 Director 与 Real Server 都有一块网卡连 在同一物理网段上。
3〉Virtual Server via IP Tunneling（LVS-TUN）
采用 NAT 技术时，由于请求和响应报文都必须经过 Director 地址重写，当客户请求越来越多时，Director 的处理能力将成为瓶颈。为了解决这个问题，Director 把请求报文通过 IP 隧道转发至 Real Server，而 Real Server 将响应直接返回给客户，所以Director 只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 LVS-TUN技术后，集群系统的最大吞吐量可以提高10倍。
分发时所采用的调度算法
1> 固定调度算法
按照某种既定的算法，不考虑实时的连接数予以分配：
（1）Round-robin（RR）轮询：将外部请求按顺序轮流分配到集群中的 Real Server，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载；
（2）Weighted round-robin（WRR）加权轮询：给每台 Real Server 分配一个权重/位列，权重越大，分到的请求数越多；
（3）Destination hashing （DH）目标散列：根据请求的目标 IP 地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。来自于同一个 IP 地址的请求都被重定向到同一台 Real Server 上，保证目标地址不变；
（4）Source hashing（SH）源地址散列：根据请求的源 IP 地址，作为散列键（HashKey）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。Director 必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙，保证原地址不变。
2> 动态调度算法
通过检查服务器上当前连接的活动状态来重新决定下一步调度方式该如何实现：
（1）Lease Connection （LC） 最少连接，哪一个Real Server上的连接数少就将下一个连接请求定向到那台Real Server上去。算法实现：连接数=活动连接数*256+非活动连接数；
（2）Weight Least-Connection（WLC） 加权最少连接，在最少连接的基础上给每台Real Server分配一个权重。算法实现：连接数=（活动连接数*256+非活动连接数）÷权重，是一种比较理想的算法；
（3）Shortest Expected Delay (SED) 最短期望延迟，不再考虑非活动连接数，算法实现：连接数=(活动连接数+1) *256 ÷权重；
（4）Never Queue (NQ) 永不排队算法，对 SED 的改进，当新请求过来的时候不仅要取决于 SED 算法所得到的值，还要取决于 Real Server 上是否有活动连接；
（5）Locality-Based Least-Connection (LBLC) 基于本地状态的最少连接，在DH 算法的基础上还要考虑服务器上的活动连接数；
（6）Locality-Based Least-Connection with Replication Scheduling(LBLCR) 带复制的基于本地的最少连接，是 LBLC 算法的改进。