目录
[2.1 负载均衡群集（Load Balance Cluster)](#2.1 负载均衡群集（Load Balance Cluster))
[2.2 高可用群集(High Availiablity Cluster)](#2.2 高可用群集(High Availiablity Cluster))
[2.3 高性能运算群集(High Performance Computing Cluster)](#2.3 高性能运算群集(High Performance Computing Cluster))
[5.1 NAT地址转换模式](#5.1 NAT地址转换模式)
[5.2 DR直接路由模式](#5.2 DR直接路由模式)
[5.3 TUNNEL隧道模式](#5.3 TUNNEL隧道模式)
[6.1 静态------仅根据算法本身进行调度](#6.1 静态——仅根据算法本身进行调度)
[6.2 动态：用一个参考值来确定服务器是否忙，这个值越小，代表这个服务器闲，就会优先调度给闲的服务器。](#6.2 动态：用一个参考值来确定服务器是否忙，这个值越小，代表这个服务器闲，就会优先调度给闲的服务器。)
[7、LVS 功能及组织架构](#7、LVS 功能及组织架构)
[7.1 应用于高访问量的业务](#7.1 应用于高访问量的业务)
[7.2 扩展应用程序](#7.2 扩展应用程序)
[7.3 消除单点故障](#7.3 消除单点故障)
一、LVS集群基本介绍
1、什么是集群
Cluster：集群,为解决某个特定问题将多台计算机组合起来形成的单个系统。由多台主机构成，但对外只能表现为一个整体，只提供一个访问入口（域名或者ip地址），相当于一个大型计算机。
2、集群的类型
2.1 负载均衡群集（Load Balance Cluster)
- 提高应用系统的响应能力、尽可能处理更多的访问请求、减少延迟为目标，获得高并发、高负载（LB）的整体性能
- LB的负载分配依赖于主节点的分流算法，将来自客户机的访问请求分担给多个服务器节点，从而缓解整个系统的负载压力。例如，"DNS轮询""反向代理"等
2.2 高可用群集(High Availiablity Cluster)
- 提高应用系统的可靠性、尽可能地减少中断时间为目标，确保服务的连续性，达到高可用（HA）的容错效果
- HA的工作方式包括双工和主从两种模式，双工即所有节点同时在线;主从则只有主节点在线，但当出现故障时从节点能自动切换为主节点。例如，"故障切换" "双机热备" 等
2.3 高性能运算群集(High Performance Computing Cluster)
- 提高应用系统的CPU运算速度、扩展硬件资源和分析能力为目标，获得相当于大型、超级计算机的高性能运算（HPC）能力
- 高性能依赖于"分布式运算"、"并行计算"，通过专用硬件和软件将多个服务器的CPU、内存等资源整合在一起，实现只有大型、超级计算机才具备的计算能力。例如"云计算"、"网格计算"
3、负载均衡集群的结构
第一层，负载调度器（Load Balancer或Director）
访问整个群集系统的唯一入口，对外使用所有服务器共有的VIP地址，也称为群集IP地址。通常会配置主、备两台调度器实现热备份，当主调度器失效以后能够平滑替换至备用调度器，确保高可用性。负载均衡层
第二层，服务器池（Server Pool）
群集所提供的应用服务、由服务器池承担，其中每个节点具有独立的RIP地址（真实IP），只处理调度器分发过来的客户机请求。当某个节点暂时失效时，负载调度器的容错机制会将其隔离，等待错误排除以后再重新纳入服务器池。web应用层
第三层，共享存储（Share Storage）
为服务器池，或者提供NFS共享服务的专用服务器。
4、LVS集群类型中的术语
- VS（代理服务器）：Virtual Server，Director Server(DS), Dispatcher(调度器)，Load Balancer（lvs服务器）
- RS（真实服务器）：Real Server(lvs), upstream server(nginx), backend server(haproxy)（真实服务器）
- CIP：Client IP（客户机IP）
- VIP：Virtual serve IP 代理服务器的外网ip
- DIP：Director IP 代理服务器的内网ip
- RIP：Real server IP 真实服务器的ip地址
5、LVS负载均衡集群的三种工作模式
-
lvs-nat：修改请求报文的目标IP,多目标IP的DNAT
-
lvs-dr：操纵封装新的MAC地址（直接路由）
-
lvs-tun：隧道模式
5.1 NAT地址转换模式
- 都走LVS，调度器有瓶颈
- lvs-nat：本质是多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为某处的RS的RIP和PORT实现转发
（1）RIP和DIP应在同一个IP网络，且应使用私网地址；RS的网关要指向DIP
（2）请求报文和响应报文都必须经由lvs服务器转发，lvs服务器易于成为系统瓶颈
（3）支持端口映射，可修改请求报文的目标PORT
（4）VS必须是Linux系统，RS可以是任意OS系统
5.2 DR直接路由模式
- 最常用！所有主机共享vip地址，不原路返回LVS调度器。web服务器在同一网段
Direct Routing，简称DR模式
采用半开放式的网络结构，与TUN模式的结构类似，但各节点并不是分散在各地，而是与调度器位于同一个物理网络
负载调度器与各节点服务器通过本地网络连接，不需要建立专用的IP隧道
5.3 TUNNEL隧道模式
- 需要买公网地址
IP Tunnel，简称TUN模式；
-
RIP和DIP可以不处于同一物理网络中，RS的网关一般不能指向DIP,且RIP可以和公网通信。也就是说集群节点可以跨互联网实现。DIP, VIP, RIP可以是公网地址。
-
RealServer的通道接口上需要配置VIP地址，以便接收DIP转发过来的数据包，以及作为响应的报文源IP。
-
DIP转发给RealServer时需要借助隧道，隧道外层的IP头部的源IP是DIP，目标IP是RIP，而RealServer响应给客户端的IP头部是根据隧道内层的IP头分析得到的，源IP是VIP，目标IP是CIP
-
请求报文要经由Director，但响应不经由Director,响应由RealServer自己完成
-
不支持端口映射
-
RS的OS须支持隧道功能
工作模式总结和比较：
|---------|--------------|------------------|------------------|
| | NAT | TUN | DR |
| 优点 | 端口转换 | WAN | 性能最好 |
| 缺点 | 性能瓶颈 | 服务器支持隧道模式 | 不支持跨网段 |
| 真实服务器要求 | any | Tunneling | Non-arp device |
| 支持网络 | private（私网） | LAN/WAN（私网/公网） | LAN（私网） |
| 真实服务器数量 | low (10~20) | High (100) | High (100) |
| 真实服务器网关 | lvs内网地址 | Own router（网工定义） | Own router（网工定义） |
6、LVS调度算法
pvs scheduler：根据其调度时是否考虑各RS当前的负载状态
分为两种：
静态方法：不管后端真实服务器的状态。根据自身算法进行调度
动态方法：会根据后端服务器的状态来进行调度
6.1 静态------仅根据算法本身进行调度
1、RR：roundrobin，轮询,较常用
2、WRR：Weighted RR，加权轮询,较常用。先算总权重，再用自己的权重去除以总权重
3、SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定。
4、DH：Destination Hashing；目标地址哈希，第一次轮询调度至RS，后续将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡,如: Web缓存
6.2 动态：用一个参考值来确定服务器是否忙，这个值越小，代表这个服务器闲，就会优先调度给闲的服务器。
- 主要根据每RS当前的负载状态及调度算法进行调度Overhead=value 较小的RS将被调度
1、LC：least connections 适用于长连接应用，最小连接数 ，不考虑权重
Overhead=activeconns*256+inactiveconns
2、WLC：Weighted LC，默认调度方法,较常用 默认调度，加权最小连接数
第一轮不合理，都一样的优先级
Overhead=(activeconns*256+inactiveconns)/weight
3、SED：Shortest Expection Delay，初始连接高权重优先,只检查活动连接,而不考虑非活动连接
Overhead=(activeconns+1)*256/weight
4、NQ：Never Queue，第一轮均匀分配，后续SED
5、LBLC：Locality-Based LC，动态的DH算法，使用场景：根据负载状态实现正向代理,实现Web Cache等，检查后端服务器忙不忙
6、LBLCR：LBLC with Replication，带复制功能的LBLC，解决LBLC负载不均衡问题，从负载重的复制到负载轻的RS,,实现Web Cache等
7、LVS 功能及组织架构
负载均衡的应用场景为高访问量的业务，提高应用程序的可用性和可靠性。
7.1 应用于高访问量的业务
如果您的应用访问量很高，可以通过配置监听规则将流量分发到不同的云服务器 ECS（Elastic Compute Service 弹性计算服务）实例上。此外，可以使用会话保持功能将同一客户端的请求转发到同一台后端ECS
7.2 扩展应用程序
可以根据业务发展的需要，随时添加和移除ECS实例来扩展应用系统的服务能力，适用于各种Web服务器和App服务器。
7.3 消除单点故障
可以在负载均衡实例下添加多台ECS实例。当其中一部分ECS实例发生故障后，负载均衡会自动屏蔽故障的ECS实例，将请求分发给正常运行的ECS实例，保证应用系统仍能正常工作
7.4 同城容灾 （多可用区容灾）
为了提供更加稳定可靠的负载均衡服务，阿里云负载均衡已在各地域部署了多可用区以实现同地域容灾。当主可用区出现机房故障或不可用时，负载均衡仍然有能力在非常短的时间内（如：大约30s中断）切换到另外一个备可用区恢复服务能力；当主可用区恢复时，负载均衡同样会自动切换到主可用区提供服务。使用负载均衡时，您可以将负载均衡实例部署在支持多可用区的地域以实现同城容灾。此外，建议您结合自身的应用需要，综合考虑后端服务器的部署。如果您的每个可用区均至少添加了一台ECS实例，那么此种部署模式下的负载均衡服务的效率是最高的。