集群的基本概念
随着计算机科学的发展，对计算机的性能要求越来越高，比如在很多流量比较大的门户网站以及科学实验环境中需要海量计算的环境，这时候就迫切需要后端的服务器性能有提升。而对于提升后端服务器性能所采用的方式有两种，其一为提升服务器本身的性能，即向上扩展，通过增加服务器的内存，CPU核心数等来实现；其二就是向外扩展，一台服务器不能完成的任务就使用两台、三台甚至更多。在此，以不同的方式把许多服务器组合起来的服务器组就是集群。
集群的分类
按照集群功能的不同，可以把集群分为以下三类：
LB集群
LB即Load Balancing的首字母缩写，即负载均衡。其主要实现的目的是为了降低后端服务器的压力，通过不同的调度方式把来自客户端的请求发给后端的终端服务器，也就是后端有多台此种集群主要用于高并发请求且请求都类似的环境,如WEB服务。
HA集群
HA（High Availability），即高可用集群，此类集群强调的是可靠性，例如在负载均衡集群实现上，通常会采用一台调度器对客户端的请求作出决策，所以此时若调度器出现故障则会成为整个WEB站点的瓶颈，此时就可以对LB集群做高可用，通过添加多个冗余的调度器来降低其因为单点故障造成的站点整体宕机。
HP集群
HP( high Performance)，即高性能集群，也被称为科学集群，此类集群，该类集群常见于科学计算中，比如，需要计算海量数据时，一台服务器无法胜任就采取多台服务器构建集群来实现，所以此类集群就被称为科学集群。
集群的实现方式
集群的实现方式有多种，从结构上来说可以分为以下几类：
NAT
NAT（Network Addiress Translate）即网络地址转换，使用NAT方式的原理非常简单，通常需要一台单独的服务器作为整个集群服务的“总指挥官”，负责把前端客户端发来的请求报文发送到后端真实服务器上，而现实的方式也就是把请求报文首部的目标地址修改为后端相应真实服务器的地址，然后当后端服务器处理完请求后生成响应报文发给前端调度器，调度器又把响应报文的报文首部的源地址改为自己的，让客户以为响应自己请求的就是自己请求的那台服务器。其基本框架如下图所示：
图1 NAT模型示意图
从其工作原理上来说使用NAT有一下几个特点：
调度器（director）必须有两块网卡，一块网卡配置有公网IP，负责接收前端客户端发送过来的请求。而另一块配置私网IP，负责和后端真实服务器（Real Server）组通信。
由于前端客户端发送过来的请求还需要经过调度器处理，所以可把响应的端口映射为非客户端初始请求服务的端口。
由于不管是客户端发送请求的报文，还是后端真实服务器响应的响应报文都需要调度器的处理，所以调度器性能要求一般非常高，且容易成为整个集群服务器组的瓶颈。
由于后端服务器组只要求能对客户端的请求做出响应即可，所以后端服务器可安装任意操作系统即可。
DR
DR为Director Route的缩写，即直连路由。其工作原理大致为，当前端客户端发送来请求报文时，调度器接收到，并识别出此请求报文所请求的服务是自己管辖服务器所提供的服务，随即把报文再次封装，添加新的报文首部，源地址不变，把目标地址改为调度器随机选取的真实服务器的MAC地址，并广播出去，后端真实服务器接收到该报文后作出响应，响应时，Real Server会使用调度器的VIP，然后把响应报文直接发给客户端，不再经过调度器即可完成。其大体结构如下图所示：
图2 DR模型示意图
根据其工作原理，DR有以下几个特点：
由于调度器要直接与真实服务器通信，所以调度器和后端真实服务器的各个节点必须在同一网络内。
后端节点可使用公网IP，以此方便管理与维护。由于调度器并未修改请求报文的报文首部，而是直接再次封装，所以后端真实服务器可以直接响应给客户端，因此调度器只负责处理前端客户端请求，不负责处理后端响应。
相对NAT来说，由于DR模式是由后端真实服务器直接响应，所以不能完成端口映射。
TUN
TUN为Tunneling的缩写，即隧道技术。其工作原理和NAT模式相似，但是调度器在处理请求报文是是通过二次封装请求报文来实现，封装时使用调度器的地址为源地址，目标地址即为Real Server的地址，当Real Server收到该报文后会把该报文拆分，获得客户端地址，响应时就直接和客户端交互，不会经过Virtual Server。因此，使用隧道技术会大大降低调度器的压力，其工作流程如下图所示：
图 3 TUN模型示意图
TUN主要特点如下：
集群中的节点，即后端真实服务器可以跨越互联网，因此，调度器的位置和真实服务器的位置更加灵活多变。但是跨越互联网却使用更多的公有IP，造成共有IP的大量浪费，在当今共有IP比较紧缺的前提下，跨越互联网的TUN模型并不是明智的选择。
和DR一样，隧道技术可实现端口映射。且调度器只负责处理前端的客户所发请求报文，而响应报文则由真实服务器直接发送给客户端。
由于需要具有隧道技术的Real Server才能响应客户端，所以后端Real Server的操作系统必须为具备隧道技术的操作系统。
Full NAT
正如名字一样，Full NAT模型就是完全地址转换的意思，在NAT模型中，来自客户端的请求会被调度器修改其目标地址，然后转发给后端的真实服务器。而Full NAT不仅会修改其目标地址且会修改其源地址为调度器的地址，然后通过真实服务器处理返回后再经由调度器修改其源地址和目标地址，响应给客户端。其结构模型和NAT基本相似，就不再赘述。
LVS介绍
LVS（ Linux Virtual Server），是由现任阿里巴巴集团副总裁的章文嵩博士发起和领导的，它是基于Linux系统的服务器集群解决方案,其实现目标是创建一个具有良好的扩展性高可靠性高性能和高可用性的体系许多商业的集群产品,比如RedHat的Piranha Turbo Linux公司的Turbo Cluster等,都是基于LVS的核心代码的体系结构，使用LVS架设的服务器集群系统从体系结构上看是透明的,最终用户只会感觉到一个虚拟服务器物理服务器之间可以通过高速的LAN或分布在各地的WAN相连最前端是负载均衡器,它负责将各种服务请求分发给后面的物理服务器,让整个集群表现像一个服务于同一IP地址的虚拟服务器而在Linux中LVS和NetFilter一样分为两个部分，内核中如要支持LVS功能则必须在编译时把ipvs模块编译进内核，而在用户空间则使用管理工具对ipvsadm进行管理。
LVS调度方法介绍
静态方法
仅考虑方法本身，不考虑后端真实服务器的负载情况，包括以下几类：
（1）RR轮叫调度（Round Robin），此类方法适合用于服务器硬件性能一致，且用户请求数据大小相差不大的环境中，采用此类调度方式，可以把用户请求按照顺序平均地分给后端服务器。
（2) WRR加权轮叫调度算法（Weighted Round Robin），使用此类调度算法，可以让调度器根据服务器的性能来对调度的顺序做修改，如在真实环境中有甲乙两台服务器，甲服务器处理数据能力是乙的两倍，我们即可设置把用户请求发两次给甲，而第三次才发给乙。
（3） DH目标地址散列（Destination Hashing）该算法使用客户端请求的目标ip地址作为散列键（Hash Key）从静态分配的散列表中找出该服务器，若服务器链接未超过负载则把请求发到该服务器，若该服务器超过负载则返回空值。
（4） SH源地址散列（Source Hashing）和dh相似，只是sh把源地址作为散列键。
动态方法
调度器不仅要考虑调度方法，还要考虑后端服务器的负载情况。主要包括以下几种：
（1） LC最少链接（Least Connections），此调度算法会对当前后端服务器的链接数量进行计算，把请求发给正处于空闲或者链接客户端数量较少的服务器。
（2）WLC加权最少链接（Weighted Least Connections），和加权轮叫调度算法相一致，此算法会根据服务器性能差异然后加上链接客户端数量加以判断，然后再转发用户请求。
（3）LBLC 基于局部性的最少链接（Locality-Based Least Connections），此种算法根据请求的目标ip地址来找出最近使用的服务器，若该服务器可用，未超过负载，则把该请求发到该服务器；若该服务器不可用或超出负载则选择现在链接最少的服务器，将该请求发到选中的服务器上。
（4） LBLCR 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）：此种算法实现方式和lblc相似，但是lblc针对的是从一个ip到一台服务器的映射，而lblcr则是一个ip到一组服务器的映射，当从调度器客户端发来的请求目标ip曾是此组服务器中一台服务器的ip时，调度器就会判断所控制Real Server中哪一台是“最少链”，然后就把该请求发到该Real server。
（5）SED 最短期望延迟（Shorted Expectation delay），该方法在调度时会根据当前连接数和权重来衡量，通常使用其活动链接数加上1然后乘以256再除以权重，算出来的值进行比较，每个链接发送过来后根据算出来的值，选择其值最大的并发送过去
（6）NQ 永不排队（Never Queue），此方法会根据后端服务器的负载情况，把请求发给空闲的服务器，其算法也是基于WLC，但是当选择的的服务器不空时，就不会发往该服务器。
本来打算做个实例，把基于NAT模型和DR模型的负载均衡集群做出来写在后面，但是感觉太长了，所以将在下一篇博客中实现，有写得不妥的还望指正！
本文出自 “linux-冒泡” 博客，请务必保留此出处http://7703592.blog.51cto.com/7693592/1655782
原文地址：http://7703592.blog.51cto.com/7693592/1655782
