Load Balance

https://www.youtube.com/watch?v=zHn2G71hoIk https://www.youtube.com/watch?v=bo2kXSF4uhg http://baike.baidu.com/view/6940611.htm http://www.tuicool.com/articles/q6fE3y

http://blog.chinaunix.net/uid-23629988-id-3336519.html

Round robin scheduling - not recommended, unless for small application

one server problem: finite numbers and no downtime

downtime: 停止运转时间(downtime)就是计算机不能运行的时间长度

上图为Load Balance与Server Farm的一个简单的网络拓扑图。 Load Balance上面需要配置一个Virtual Server,拥有一个Virtual IP(VIP)。在TCP/IP协议中,port是用于区分服务的,所以virtual server下面同样要配置virtual port,对应不同的服务,并绑定多个real server的对应port。

其意思就是将负载(工作任务)进行平衡、分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务 (如果一个server down 还有备份的,或者正在maintenance)

负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。需要说明的是:负载均衡设备不是基础网络设备,而是一种性能优化设备。对于网络应用而言,并不是一开始就需要负载均衡,当网络应用的访问量不断增长,单个处理单元无法满足负载需求时,网络应用流量将要出现瓶颈时,负载均衡才会起到作用。

负载均衡有两方面的含义:首先,单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给用户,系统处理能力得到大幅度提高,这就是我们常说的集群(clustering)技术。第二层含义就是:大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间,这主要针对Web服务器、FTP服务器、企业关键应用服务器等网络应用。 通常,负载均衡会根据网络的不同层次(网络七层)来划分。其中,第二层的负载均衡指将多条物理链路当作一条单一的聚合逻辑链路使用,这就是链路聚合(Trunking)技术,它不是一种独立的设备,而是交换机等网络设备的常用技术。现代负载均衡技术通常操作于网络的第四层或第七层,这是针对网络应用的负载均衡技术,它完全脱离于交换机、服务器而成为独立的技术设备。 近几年来,四到七层网络负载均衡首先在电信、移动、银行、大型网站等单位进行了应用,因为其网络流量瓶颈的现象最突出。这也就是为何我们每通一次电话,就会经过负载均衡设备的原因。另外,在很多企业,随着企业关键网络应用业务的发展,负载均衡的应用需求也越来越大。

轮叫调度(Round-Robin Scheduling)

轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。

  在系统实现时,我们引入了一个额外条件,当服务器的权值为零时,表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务(如屏蔽服务器故障和系统维护),同时与其他加权算法保持一致。所以,算法要作相应的改动,它的算法流程如下:

轮叫调度算法流程

轮叫调度算法假设所有服务器处理性能均相同,不管服务器的当前连接数和响应速度。该算法相对简单,不适用于服务器组中处理性能不一的情况,而且当请求服务时间变化比较大时,轮叫调度算法容易导致服务器间的负载不平衡。

虽然Round-Robin DNS方法也是以轮叫调度的方式将一个域名解析到多个IP地址,但轮叫DNS方法的调度粒度是基于每个域名服务器的,域名服务器对域名解析的缓存会妨碍轮叫解析域名生效,这会导致服务器间负载的严重不平衡。这里,IPVS轮叫调度算法的粒度是基于每个连接的,同一用户的不同连接都会被调度到不同的服务器上,所以这种细粒度的轮叫调度要比DNS的轮叫调度优越很多。

在前面的LB的应用网络拓扑中,LB作为服务器的前端设备,也是连接中的中间设备。client和server所有的流量都要经过LB设备。不仅这样,LB设备往往还需要修改数据包的报头,甚至包的内容。而世上没有免费的午餐,这些操作难免会带来一些性能损耗。

DSR模式

那么我们又想使用LB的功能,同时又不愿意有这样的性能下降,这时怎么办?性能的下降是由于所有的数据包都要经过LB设备。那么我们能不能让数据包不经过LB设备呢?这时,就需要让SLB另外一种应用拓扑Direct Server Reply,即DSR模式。顾名思义,DSR模式下,server的response包不会经过LB,直接发往client。而所有的client发送的request数据包,仍然经过LB设备。

使用DSR模式,看上去只有server的response不经过LB设备,只有单边的流量得到了优化。但是在一般的CS应用中,client的request往往比较简单,数据较小较少,而server的response的数据较多较大。一般server response的流量可以占到总流量的80%到90%时,使用DSR模式,可以有效的提高性能,又不损失SLB的灵活性。