集群、分布式、负载均衡区别

阳光穿透心脏的1/2处 2022-05-19 13:46 190阅读 0赞

## 集群 ##

### 集群的概念 ###

计算机集群通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算**速度和/或可靠性**。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多。  
　　比如单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。一般分为几种：

*  高可用性集群：一般是指当集群中有某个节点失效的情况下，其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线，该过程并不影响整个集群的运行。
 *  负载均衡集群：负载均衡集群运行时，一般通过一个或者多个前端负载均衡器，将工作负载分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性。
 *  高性能计算集群：高性能计算集群采用将计算任务分配到集群的不同计算节点而提高计算能力，因而主要应用在科学计算领域。

## 分布式 ##

集群：同一个业务，部署在多个服务器上。分布式：一个业务分拆成多个子业务，或者本身就是不同的业务，部署在不同的服务器上。  
　　简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个均衡服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成，并且一台服务器垮了，其它的服务器可以顶上来。分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务可能就失败了。

## 负载均衡 ##

### 概念 ###

随着业务量的提高，现有网络的各个核心部分访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。  
　　负载均衡技术通过设置虚拟服务器IP（VIP），将后端多台真实服务器的应用资源虚拟成一台高性能的应用服务器，通过负载均衡算法，将用户的请求转发给后台内网服务器，内网服务器将请求的响应返回给负载平衡器，负载平衡器再将响应发送到用户，这样就向互联网用户隐藏了内网结构，阻止了用户直接访问后台（内网）服务器，使得服务器更加安全，可以阻止对核心网络栈和运行在其它端口服务的攻击。并且负载均衡设备（软件或硬件）会持续的对服务器上的应用状态进行检查，并自动对无效的应用服务器进行隔离，实现了一个简单、扩展性强、可靠性高的应用解决方案，解决了单台服务器处理性能不足，扩展性不够，可靠性较低的问题。  
　　系统的扩展可分为纵向（垂直）扩展和横向（水平）扩展。纵向扩展，是从单机的角度通过增加硬件处理能力，比如CPU处理能力，内存容量，磁盘等方面，实现服务器处理能力的提升，不能满足大型分布式系统（网站），大流量，高并发，海量数据的问题。因此需要采用横向扩展的方式，通过添加机器来满足大型网站服务的处理能力。比如：一台机器不能满足，则增加两台或者多台机器，共同承担访问压力。

**负载平衡最重要的一个应用是利用多台服务器提供单一服务**，这种方案有时也称之为服务器农场。通常，负载平衡主要应用于Web网站，大型的Internet Relay Chat网络，高流量的文件下载网站，NNTP（Network News Transfer Protocol）服务和DNS服务。现在负载平衡器也开始支持数据库服务，称之为数据库负载平衡器。  
　　服务器负载均衡有三大基本Feature：负载均衡算法，健康检查和会话保持，这三个Feature是保证负载均衡正常工作的基本要素。其他一些功能都是在这三个功能之上的一些深化。下面我们具体介绍一下各个功能的作用和原理。  
　　在没有部署负载均衡设备之前，用户直接访问服务器地址（中间或许有在防火墙上将服务器地址映射成别的地址，但本质上还是一对一的访问）。当单台服务器由于性能不足无法处理众多用户的访问时，就要考虑用多台服务器来提供服务，实现的方式就是负载均衡。负载均衡设备的实现原理是把多台服务器的地址映射成一个对外的服务IP（我们通常称之为VIP，关于服务器的映射可以直接将服务器IP映射成VIP地址，也可以将服务器IP:Port映射成VIP:Port，不同的映射方式会采取相应的健康检查，在端口映射时，服务器端口与VIP端口可以不相同）,这个过程对用户端是不可见的，用户实际上不知道服务器是做了负载均衡的，因为他们访问的还是一个目的IP，那么用户的访问到达负载均衡设备后，如何把用户的访问分发到合适的服务器就是负载均衡设备要做的工作了，具体来说用到的就是上述的三大Feature。  
我们来做一个详细的访问流程分析:  
![1156565-20170729153452566-2008499549.png][]

用户(IP:207.17.117.20)访问域名`www.a10networks.com`，首先会通过DNS查询解析出这个域名的公网地址：199.237.202.124，接下来用户207.17.117.20会访问199.237.202.124这个地址，因此数据包会到达负载均衡设备，接下来负载均衡设备会把数据包分发到合适的服务器，看下图：  
![1156565-20170729153552300-85133083.png][]

负载均衡设备在将数据包发给服务器时，数据包是做了一些变化的，如上图所示，数据包到达负载均衡设备之前，源地址是：207.17.117.20，目的地址是：199.237.202.124，当负载均衡设备将数据包转发给选中的服务器时，源地址还是：207.17.117.20，目的地址变为172.16.20.1，我们称这种方式为目的地址NAT(DNAT，目的地址转换)。一般来说，在服务器负载均衡中DNAT是一定要做的（还有另一种模式叫做服务器直接返回-DSR，是不做DNAT的，我们将另行讨论），而源地址根据部署模式的不同，有时候也需要转换成别的地址，我们称之为：源地址NAT(SNAT)，一般来说，旁路模式需要做SNAT，而串接模式不需要，本示意图为串接模式，所以源地址没做NAT。  
　　我们再看服务器的返回包，如下图所示，也经过了IP地址的转换过程，不过应答包中源/目的地址与请求包正好对调，从服务器回来的包源地址为172.16.20.1，目的地址为207.17.117.20，到达负载均衡设备后，负载均衡设备将源地址改为199.237.202.124，然后转发给用户，保证了访问的一致性。  
![1156565-20170729153938753-1253595318.png][]

### 负载均衡算法 ###

一般来说负载均衡设备都会默认支持多种负载均衡分发策略，例如：

*  轮询（RoundRobin）将请求顺序循环地发到每个服务器。当其中某个服务器发生故障，AX就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。
 *  比率（Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生故障，AX就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
 *  优先权（Priority）：给所有服务器分组，给每个组定义优先权，将用户的请求分配给优先级最高的服务器组（在同一组内，采用预先设定的轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器或者指定数量的服务器出现故障，AX将把请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。
 *  最少连接数（LeastConnection）：AX会记录当前每台服务器或者服务端口上的连接数，新的连接将传递给连接数最少的服务器。当其中某个服务器发生故障，AX就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
 *  最快响应时间（Fast Reponse time）：新的连接传递给那些响应最快的服务器。当其中某个服务器发生故障，AX就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
 *  哈希算法( hash): 将客户端的源地址，端口进行哈希运算，根据运算的结果转发给一台服务器进行处理，当其中某个服务器发生故障，就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
 *  基于数据包的内容分发：例如判断HTTP的URL，如果URL中带有.jpg的扩展名，就把数据包转发到指定的服务器。

### 健康检查 ###

健康检查用于检查服务器开放的各种服务的可用状态。负载均衡设备一般会配置各种健康检查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等。Ping属于第三层的健康检查，用于检查服务器IP的连通性，而TCP/UDP属于第四层的健康检查，用于检查服务端口的UP/DOWN，如果要检查的更准确，就要用到基于7层的健康检查，例如创建一个HTTP健康检查，Get一个页面回来，并且检查页面内容是否包含一个指定的字符串，如果包含，则服务是UP的，如果不包含或者取不回页面，就认为该服务器的Web服务是不可用（DOWN）的。比如，负载均衡设备检查到172.16.20.3这台服务器的80端口是DOWN的，负载均衡设备将不把后面的连接转发到这台服务器，而是根据算法将数据包转发到别的服务器。创建健康检查时可以设定检查的间隔时间和尝试次数，例如设定间隔时间为5秒，尝试次数为3，那么负载均衡设备每隔5秒发起一次健康检查，如果检查失败，则尝试3次，如果3次都检查失败，则把该服务标记为DOWN，然后服务器仍然会每隔5秒对DOWN的服务器进行检查，当某个时刻发现该服务器健康检查又成功了，则把该服务器重新标记为UP。健康检查的间隔时间和尝试次数要根据综合情况来设置，原则是既不会对业务产生影响，又不会对负载均衡设备造成较大负担。

### 会话保持 ###

如何保证一个用户的两次http请求转发到同一个服务器，这就要求负载均衡设备配置会话保持。  
　　会话保持用于保持会话的连续性和一致性，由于服务器之间很难做到实时同步用户访问信息，这就要求把用户的前后访问会话保持到一台服务器上来处理。举个例子，用户访问一个电子商务网站，如果用户登录时是由第一台服务器来处理的，但用户购买商品的动作却由第二台服务器来处理，第二台服务器由于不知道用户信息，所以本次购买就不会成功。这种情况就需要会话保持，把用户的操作都通过第一台服务器来处理才能成功。当然并不是所有的访问都需要会话保持，例如服务器提供的是静态页面比如网站的新闻频道，各台服务器都有相同的内容，这种访问就不需要会话保持。  
　　绝大多数的负载均衡产品都支持两类基本的会话保持方式：源/目的地址会话保持和cookie会话保持，另外像hash，URL Persist等也是比较常用的方式，但不是所有设备都支持。基于不同的应用要配置不同的会话保持，否则会引起负载的不均衡甚至访问异常。我们主要分析B/S结构的会话保持。

基于B/S结构的应用：

对于普通B/S结构的应用内容，例如网站的静态页面，可以不用配置任何的会话保持，但是对于一个基于B/S结构尤其是中间件平台的业务系统来说，必须配置会话保持，一般情况下，我们配置源地址会话保持可以满足需求，但是考虑到客户端可能有上述不利于源地址会话保持的环境，采用Cookie会话保持是一个更好的方式。Cookie会话保持会把负载均衡设备选择的Server信息保存在Cookie中发送到客户端，客户端持续访问时，会把该Cookie带来，负载均衡器通过分析Cookie把会话保持到之前选定的服务器。Cookie分为文件Cookie和内存cookie，文件cookie保存在客户端计算机硬盘上，只要该cookie文件不过期，则无论是否重复关闭开放浏览器都能保持到同一台服务器。内存Cookie则是把Cookie信息保存在内存中，Cookie的生存时间从打开浏览器访问开始，关闭浏览器结束。由于现在的浏览器对Cookie都有一定默认的安全设置，有些客户端可能规定不准使用文件Cookie，所以现在的应用程序开发多使用内存Cookie。  
　　然而，内存Cookie也不是万能的，比如浏览器为了安全可能会完全禁用Cookie，这样Cookie会话保持就失去了作用。我们可以通过Session-id来实现会话保持，即将session-id作为url参数或者放在隐藏字段`<input type="hidden">`中，然后分析Session-id进行分发。  
　　另一种方案是：将每一会话信息保存到一个数据库中。由于这个方案会增加数据库的负载，所以这个方案对性能的提高并不好。数据库最好是用来存储会话时间比较长的会话数据。为了避免数据库出现单点故障，并且提高其扩展性，数据库通常会复制到多台服务器上，通过负载均衡器来分发请求到数据库服务器上。  
　　基于源/目的地址会话保持其实不太好用，因为客户可能是通过DHCP，NAT或者Web代理来连接Internet的，其IP地址可能经常变换，这使得这个方案的服务质量无法保障。  
**NAT(Network Address Translation，网络地址转换)**:当在专用网内部的一些主机本来已经分配到了本地IP地址(即仅在本专用网内使用的专用地址)，但现在又想和因特网上的主机通信(并不需要加密)时，可使用NAT方法。这种方法需要在专用网连接到因特网的路由器上安装NAT软件。装有NAT软件的路由器叫做NAT路由器，它至少有一个有效的外部全球IP地址。这样，所有使用本地地址的主机在和外界通信时，都要在NAT路由器上将其本地地址转换成全球IP地址，才能和因特网连接。

### 负载均衡的其他好处 ###

高扩展性

通过添加或减少服务器数量，可以更好的应对高并发请求。

（服务器）健康检查

负载均衡器可以检查后台服务器应用层的健康状况并从服务器池中移除那些出现故障的服务器，提高可靠性。

TCP 连接复用（TCP Connection Reuse）

TCP连接复用技术通过将前端多个客户的HTTP请求复用到后端与服务器建立的一个TCP连接上。这种技术能够大大减小服务器的性能负载，减少与服务器之间新建TCP连接所带来的延时，并最大限度的降低客户端对后端服务器的并发连接数请求，减少服务器的资源占用。  
　　一般情况下，客户端在发送HTTP请求之前需要先与服务器进行TCP三次握手，建立TCP连接，然后发送HTTP请求。服务器收到HTTP请求后进行处理，并将处理的结果发送回客户端，然后客户端和服务器互相发送FIN并在收到FIN的ACK确认后关闭连接。在这种方式下，一个简单的HTTP请求需要十几个TCP数据包才能处理完成。  
　　采用TCP连接复用技术后，客户端（如：ClientA）与负载均衡设备之间进行三次握手并发送HTTP请求。负载均衡设备收到请求后，会检测服务器是否存在空闲的长连接，如果不存在，服务器将建立一个新连接。当HTTP请求响应完成后，客户端则与负载均衡设备协商关闭连接，而负载均衡则保持与服务器之间的这个连接。当有其它客户端（如：ClientB）需要发送HTTP请求时，负载均衡设备会直接向与服务器之间保持的这个空闲连接发送HTTP请求，避免了由于新建TCP连接造成的延时和服务器资源耗费。  
![1156565-20170729163617863-921500266.png][]

在HTTP 1.1中，客户端可以在一个TCP连接中发送多个HTTP请求，这种技术叫做HTTP复用（HTTP Multiplexing）。它与TCP连接复用最根本的区别在于，TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。

HTTP缓存

负载均衡器可以存储静态内容，当用户请求它们时可以直接响应用户而不必再向后台服务器请求。

TCP缓冲

TCP缓冲是为了解决后端服务器网速与客户的前端网络速度不匹配而造成的服务器资源浪费的问题。客户端与负载均衡之间采用的链路具有较高的时延和较低的带宽，而负载均衡与服务器之间采用时延较低和高带宽的局域网连接。由于负载均衡器可以暂存后台服务器对客户的响应数据，再将它们转发给那些响应时间较长网速较慢的客户，如此后台Web服务器就可以释放相应的线程去处理其它任务。

SSL加速

一般情况下，HTTP采用明文的方式在网络上传输，有可能被非法窃听，尤其是用于认证的口令信息等。为了避免出现这样的安全问题，一般采用SSL协议（即：HTTPS）对HTTP协议进行加密，以保证整个传输过程的安全性。在SSL通信中，首先采用非对称密钥技术交换认证信息，并交换服务器和浏览器之间用于加密数据的会话密钥，然后利用该密钥对通信过程中的信息进行加密和解密。  
　　SSL是需要耗费大量CPU资源的一种安全技术。目前，大多数负载均衡设备均采用SSL加速芯片（硬件负载均衡器）进行SSL信息的处理。这种方式比传统的采用服务器的SSL加密方式提供更高的SSL处理性能，从而节省大量的服务器资源，使服务器能够专注于业务请求的处理。另外，采用集中的SSL处理，还能够简化对证书的管理，减少日常管理的工作量。

内容过滤

有些负载均衡器可以按要求修改通过它的数据。

入侵阻止功能

在防火墙保障网络层/传输层安全的基础上，提供应用层安全防范。

### 分类 ###

下面从不同层次讨论负载均衡的实现：

DNS 负载均衡

DNS负责提供域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程中，DNS服务器完成了域名到IP地址的映射，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了负载均衡调度器，将用户的请求分散到多台服务器上。使用dig命令来看下”baidu”的DNS设置：  
![1156565-20170729180402785-629549849.png][]  
　　可见baidu拥有三个A记录。

这种技术的优点是，实现简单、实施容易、成本低、适用于大多数TCP/IP应用，并且DNS服务器可以在所有可用的A记录中寻找离用户最近的一台服务器。但是，其缺点也非常明显，首先这种方案不是真正意义上的负载均衡，DNS服务器将Http请求平均地分配到后台的Web服务器上（或者根据地理位置），而不考虑每个Web服务器当前的负载情况；如果后台的Web服务器的配置和处理能力不同，最慢的Web服务器将成为系统的瓶颈，处理能力强的服务器不能充分发挥作用；其次未考虑容错，如果后台的某台Web服务器出现故障，DNS服务器仍然会把DNS请求分配到这台故障服务器上，导致不能响应客户端。最后一点是致命的，有可能造成相当一部分客户不能享受Web服务，并且由于DNS缓存的原因，所造成的后果要持续相当长一段时间(一般DNS的刷新周期约为24小时)。所以在国外最新的建设中心Web站点方案中，已经很少采用这种方案了。

链路层（OSI 第二层）负载均衡

在通信协议的数据链路层修改mac地址，进行负载均衡。  
　　数据分发时，不修改ip地址（因为还看不到ip地址），只修改目标mac地址，并且配置所有后端服务器虚拟ip和负载均衡器ip地址一致，达到不修改数据包的源地址和目标地址，进行数据分发的目的。  
　　实际处理服务器ip和数据请求目的ip一致，不需要经过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模式（DR模式）。如下图：  
![1156565-20170729184856613-5969974.png][]  
　　性能很好，但是配置复杂，目前应用比较广泛。

传输层（OSI 第四层）负载均衡

传输层是 OSI 第四层，包括 TCP 和 UDP。流行的传输层负载均衡器有 HAProxy（这个也用于应用层负载均衡）和 IPVS。  
　　**主要通过报文中的目标地址和端口**，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。  
　　以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。  
![1156565-20170729182005316-13730666.png][]

应用层（OSI 第七层）负载均衡

应用层是 OSI 第七层。它包括 HTTP、HTTPS 和 WebSockets。一款非常流行又久经考验的应用层负载均衡器就是 Nginx\[恩静埃克斯 = Engine X\]。  
　　所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。注意此时可以看到具体的http请求的完整url，因此可以实现下图所示的分发：  
![1156565-20170729182142441-525235615.png][]

以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才能看到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。那么，为什么还需要七层负载均衡呢？

七层负载均衡的好处，是使得整个网络更"智能化"，比如上面列举的负载均衡的好处，大部分都基于七层负载均衡。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。  
　　另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，通常这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。从技术原理上也可以看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。  
　　现在的七层负载均衡，主要还是着重于应用广泛的HTTP协议，所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 四层负载均衡则对应其他TCP应用，例如基于C/S开发的ERP等系统。

[1156565-20170729153452566-2008499549.png]: /images/20220519/c4158add60bf4e55baa6cec18ff55a7a.png
[1156565-20170729153552300-85133083.png]: /images/20220519/6af4edea712d4ae4880bdd84fec0cb51.png
[1156565-20170729153938753-1253595318.png]: /images/20220519/f217b3faf75c425bb7b5f62c54b9543b.png
[1156565-20170729163617863-921500266.png]: /images/20220519/38419605199a4dd39ab67445adecb92b.png
[1156565-20170729180402785-629549849.png]: /images/20220519/e6a80a4cbabe47a6a1f781cc8d6bf905.png
[1156565-20170729184856613-5969974.png]: /images/20220519/3506f9b2666f43bab9de12626723c440.png
[1156565-20170729182005316-13730666.png]: /images/20220519/7d2ecb3f53f84c9db8b7b509a60874f2.png
[1156565-20170729182142441-525235615.png]: /images/20220519/687215fdc1e04601a0d66ee7de863b2e.png