漫漫运维路——集群基础知识

集群的基本概念

随着计算机科学的发展，对计算机的性能要求愈来愈高，好比在不少流量比较大的门户网站以及科学实验环境中须要海量计算的环境，这时候就迫切须要后端的服务器性能有提高。而对于提高后端服务器性能所采用的方式有两种，其一为提高服务器自己的性能，即向上扩展，经过增长服务器的内存，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模型的负载均衡集群作出来写在后面，可是感受太长了，因此将在下一篇博客中实现，有写得不妥的还望指正！