负载均衡-基本介绍

2019-12-09

负载均衡-基本介绍

负载均衡的由来

在前期公司业务量很小的情况下,我们每个服务使用单机既可以完成,但是随着公司的发展业务量的增加,单机已经不能满足同时很多的客户请求了,我们这个时候就需要两台服务器或者更多服务器来完成用户的请求,但是我门需要给客户提供一个统一的入口,然后将用户的请求转发到后段服务器来做处理。
(在公司初期,业务量很少,只需要一个人就能完成了,但是随着业务量的增长,这个人不管在怎么强壮他也不能满足工作的需求了,这个时候我们就多招几个人来处理同样的事情,但是我们需要给它们安排一个领导,所有的任务我们先交给领导,然后由领导来安排工作[负载均衡的入口])

什么是负载均衡

负载均衡就是说:如果在一组计算机节点(或者一组进程)提供相同的服务,那么对服务的请求就应该是均匀的分摊到这些节点上。复杂均衡的前提一定是:“从多个相同的服务器提供单个Internet服务”。
这里的服务是广义的,可以是简单的计算,也可能是数据的读取或者存储。负载均衡也不是新事物,他在我们实际的生活中随处可见。
负载均衡的意义在于,让所有节点以最小的代价、最好的状态对外提供服务,这样系统吞吐量最大、性能更高,对于用户而言请求的时间也更小。而且,负载均衡增强了系统的可靠性,最大化降低了单个节点过载,甚至Crash的概率。不难想象,如果一个重要系统的绝大部分请求都落在同一个节点上,那么这些请求响应时间都很慢,而且万一节点降级或者崩溃,那么所有请求又会转移到下一个节点上,就会造成雪崩。
传统架构:
image.png

负载均衡架构:
image.png

##负载均衡的优点
1,可伸缩性(Scalability),当服务的负载增长时,系统能被扩展来满足需求,且不降低服务器质量(Qos)
2,高可用性(Availability),尽管部分硬件和软件会发生故障,整个系统的服务是能7*24h工作的
3,可管理型(Mamageability),整个系统可能在物理结构上很大,但是应该更容易管理
4,价格有效性(Cost-effectiveness),整个系统实现是经济的、易支付的。

单节点的缺点

1,升级过程繁琐,机器切换会使服务暂时中断,并造成原有计算资源的浪费;
2,越往高端的服务器,所花费的代价越大;
3,一旦该服务器或应用软件失效,会导致整个服务的中断。

负载均衡算法

算法衡量

当我们提到一个负载均衡算法的时候,或者具体的应用场景时,应该考虑一下问题:
* 1,是否意识到不同节点的服务能力是不一样的,比如机器的配置不一样,所处的网络环境不一样;
* 2,是否意识到节点的服务能力是动态变化的,高配置的机器也有可能由于一些突发情况导致处理速度变得很慢;
* 3,是否考虑将同一个客户端,或者说同样的请求分发到同一个处理节点,这对于“有状态”的服务器非常重要,比如我们常说的session保持;
* 4,谁负责负载均衡,即采用什么技术来实现负载均衡器,负载均衡器本身是否称为瓶颈。

我们下面就来非开刨析负载均衡器的算法:

轮询算法(round-robin)

顾名思义轮询就是所有的后端服务节点逐个对外提供服务,这样能做到绝对的均衡。

加权轮询算法(weight round-robin)

在轮询算法的基础上,考虑到机器的差异性,分配给机器不同的权重,能者多劳。注意,这个权重的分配依赖于请求的类型,比如计算密集型,那就考虑CPU、内存;如果是IO密集型,那就考虑磁盘性能。使其中的一个或者几个服务节点向外提供的次数多一些。

随机算法

随机选择一个节点服务,按照概率,只要请求数量足够多,那么也能达到绝对均衡的效果。

加权随机算法

如同加权轮训算法至于轮训算法一样,也是在随机的时候引入不同节点的权重

哈希算法(hash)

根据客户端的IP,或者请求的key,计算出一个hash值,然后对节点数目取模。好处就是,同一个请求能够分配到同样的服务节点,这对于有状态的服务很有必要;

一致性哈希

哈希算法的缺陷也很明显,当节点的数目发生变化的时候,请求会大概率分配到其他的节点,引发一系列问题,比如sticky session。而在某些情况下,比如分布式存储,是绝对的不允许的。
为了解决这个哈希算法的问题,又引入了一致性哈希算法,简单来说,一个物理节点与多个虚拟节点映射,在hash的时候,使用虚拟节点数目而不his物理节点数目。当物理节点变化的时候,虚拟节点的数目无需变化,只涉及到虚拟节点的重新分配。而且调整每个物理节点对应的虚拟节点数目,也就相当于每个物理节点有不同的权重。

最少连接算法(least connection)

以上的诸多算法,要么没有考虑到节点间的差异(轮询,随机,哈希),要么节点间的权重是静态分配的(加权轮询,加权随机,一致性hash)。
考虑这么一种情况,当某台机器出现故障,无法及时处理请求,但是新的请求还是会以一定的概率源源不断的分配到这个节点,造成请求的积压,因此,根据节点的真实负载,动态的调整节点的权重就非常重要,当然,要获得节点的真实负载也不一定是准确的,如何定义负载,负载的收集是否及时,这都是需要考虑的问题。
每个节点当前的连接数目是一个非常容易收集的指标,因此lease connection是最常被人提到的算法。也有一些侧重不同或者更复杂、更客观的指标,比如最小响应时间(least response time)、最小活跃数(least active)等。

负载均衡的工作方式

通过NAT实现虚拟服务器(VS/NAT)

由于 IPv4 中IP 地址空 间 的 日益 紧 张 和安 全 方 面的 原 因, 很 多 网络 使 用 保留 IP地址(10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0)[64, 65,66]。这些地址不在Internet上使用,而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时,就需要采用网络地址转换(NetworkAddress Translation, 以下简称NAT),将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头(目标地址、源地址和端口等)被正确改写后,客户相信它们连接一个IP地址,而不同IP地址的服务器组也认为它们是与客户直接相连的。由此,可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

VS/NAT的体系结构如下图。在一组服务器前有一个调度器,它们是通过Switch/HUB相连接的。这些服务器提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服务器,执行结果是一样的。服务的内容可以复制到每台服务器的本地硬盘上,可以通过网络文件系统(如NFS)共享,也可以通过一个分布式文件系统来提供。
image.png

client通过Virtual IP Address(虚拟服务的IP地址)访问网络服务时,请求报文到达调度器,调度器根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址Virtual IP Address改写成选定的真实提供服务器的I地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送选定的服务器。同时,调度器在Hash表中记录这个连接,当这个连接的下一个报文到达时,从连接hash表中可以得到原选定服务器的地址和端口,并进行同样的改写操作,并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时,调度器将报文的源地址源端口改为virtual IP address 和 相应的端口,再把报文发送给用户。 我们在连接上引入一个状态机,不同的报文会使得连接处于不用的状态,不用的状态有不同的超时值。在TCP连接中,根据标准的TCP有限状态机进行状态迁移;在UDP中,我们只设置一个UDP状态。不同状态的超时值是可以设置的,在缺省情况下,SYN状态的超时为1分钟,ESTABLISHED状态的超时为15分钟,FIN状态的超时为1分钟;UDP状态的超时为5分钟。当连接终止或者超时,调度器将这个连接从连接hash表中删除。
这样,client看到的只是在Virtual IP Address上提供的服务,而服务器集群的结构对用户时透明的,对改写后的报文,应用增量调整CheckSum的算法调整TCP Checksum的值,避免了扫描整个报文来计算checksum的开销。

优缺点

1,NAT技术将请求的报文和响应的报文都需要进行改写,当访问量过大的时候,负载均衡器将会变成瓶颈
2,只需要在负载均衡器上配置一个工网地址即可
3,每台内部的节点服务器的网关地址必须时负载均衡调度器的内网地址
4,NAT模式支持IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致

通过IP隧道实现虚拟服务器(VS/TUN)

VS/NAT的集群系统中,请求和响应的数据报文都需要通过负载调度器,当后端真实服务器的数目在10-20台之间,负载调度器将成为整个集群系统的新瓶颈。大多数internet服务都有这样的特点:请求报文较小而响应报文往往包含大量的数据。如果能将请求和响应分开处理,即在负载调度器中只负责调度请求而响应直接返回给客户,将极大地提高整个集群系统的吞吐量。

IP隧道(ip tunneling)是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。ip隧道技术亦称为IP封装技术(IP encapsulatuon)。IP 隧道主要用于移动主机和虚拟私有网络(virtual private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。

我们利用IP隧道技术将请求报文封装转发给后端服务器,响应报文能从后端服务器直接返回给client。但在这里,后端服务器有一组而非一个,所以我们不可能静态地建立一一对应的隧道,而是动态的选择一台服务器,将请求报文封装和转发给选出的服务器。这样,我们就可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如下图,各个服务将VIP地址配置在自己的IP隧道设备上。
image.png
VS/TUN的工作流程图如下:他的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,动态地选择一台服务器,将请求报文封装在另一个IP报文中,在将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为VIP的报文,服务器发现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。
image.png

image.png

在这里,请求报文的目标地址为VIP,响应报文的源地址为VIP,所以响应报文不需要作任何修改,可以直接返回给客户,客户认为得到正常的服务,而不会知道事那台服务器处理的。
在VS/TUN中,响应报文根据服务器的路由表直接返回给客户,而不经过负载调度器,所以负载调度器只处于从客户到服务器的半连接中,VS/TUN的TCP状态迁移与VS/NAT的不同。我们给出半连接的TCP有状态机,如下图,圈表示状态,箭头表示状态间的转换,箭头上的标识表示当前状态上收到该表示的输入,迁移到下一个状态。VS/TUN的TCP状态迁移事按照半连接的TCP有限状态机进行的。
image.png

通过直接路由实现虚拟服务器(VS/DR)

跟VS/TUN方法相同,VS/DR利用大多数internet服务的非对称特点,负载调度器只负责调度请求,而服务器直接讲响应返回给客户,可以极大的提高整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法类似,但IBM的NetDispatcher是非常昂贵的商品化产品,我们也不知道它内部所使用的机制,其中有些是IBM的专利。
VS/DR的体系结构如下图:调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连,如果通过交换机或者高速的HUB相连。VIP地址为调度器和服务器组共享,调度器配置的VIP对外是可见的,用于接受虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为VIP的网络请求。
image.png

VS/DR的工作流程如下图所示:
image.png

它的连接调度和管理与VS/NAT和NS/TUN中的一样,他的报文转发方法又有不同,将报文直接路由给目标服务器。在VS/DR中,调度器根据各个服务器的负载情况,动态的选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器可能可以收到这个数据帧,从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接发回给客户。

三种工作方式的总结

1,NAT 是通过更改IP包中的源地址来进行代理的
2,TUN 是通过在 package在封装一层 Sip 来实现的
3,DR 是通过更改数据帧中的mac地址来实现的

三种工作模式比较image.png


标题:负载均衡-基本介绍
作者:shoufuzhang
地址:https://www.zhangshoufu.com/articles/2019/12/09/1575878932674.html
名言:The master has failed more times than the beginner has tried.
评论
发表评论