① 服务器集群的负载均衡算法有哪些
轮转(Round-Robin)算法
加权轮转(Weighted Round Robin)算法
最小连接数(Least Connections)算法
加权最小连接数(Weighted Least Connections)算法
目的地址哈希散列(Destination Hashing Scheling)算法
源地址哈希散列(Source Hashing Scheling)算法
随机(Random)算法
② 如何实现负载均衡,哪些算法可以实现
1、轮询调度
轮询调度算法就是以轮询的方式依次将请求调度到不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。
2、最小连接调度
最小连接调度算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。
在实际实现过程中,一般会为每台服务器设定一个权重值,这就是加权最小连接
3、 基于局部性的最少链接(LBLC)
基于局部性的最少链接调度(以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中客户请求报文的目标IP地址是变化的。
LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器; 若服务器不存在,或服务器超载或有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。
4、带复制的基于局部性最少链接(LBLCR)
带复制的基于局部性最少链接调度以下简称为LBLCR)算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。
LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载; 当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器数目。
5、目标地址散列调度
目标地址散列调度算法是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。
目标地址散列调度算法先根据请求的目标IP地址,作为散列从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
6、 源地址散列调度
和目标地址散列调度类似,唯一的区别是按照源地址为散列函数的散列键。
③ 负载均衡是怎么做的~
1、服务直接返回:这种安装方式负载均衡的LAN口不使用,WAN口与服务器在同一个网络中,互联网的客户端访问负载均衡的虚IP(VIP),虚IP对应负载均衡机的WAN口,负载均衡根据策略将流量分发到服务器上,服务器直接响应客户端的请求。
2、桥接模式:桥接模式配置简单,不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP(WAN口与LAN口是桥连接),所有的服务器与负载均衡均在同一逻辑网络中。
3、路由模式:路由模式的部署方式,服务器的网关必须设置成负载均衡机的LAN口地址,且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小,能均衡任何下行流量。
(3)如何计算服务器负载均衡扩展阅读
负载均衡的算法:
1、随机算法:Random随机,按权重设置随机概率。在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。
2、哈希算法:一致性哈希一致性Hash,相同参数的请求总是发到同一提供者。当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
3、URL散列:通过管理客户端请求URL信息的散列,将发送至相同URL的请求转发至同一服务器的算法。
参考资料
网络-负载均衡
④ 多台异地服务器如何实现负载均衡
一般用的就用简单的轮询就好了
调度算法
静态方法:仅根据算法本身实现调度;实现起点公平,不管服务器当前处理多少请求,分配的数量一致
动态方法:根据算法及后端RS当前的负载状况实现调度;不管以前分了多少,只看分配的结果是不是公平
静态调度算法(static Sche)(4种):
(1)rr (Round Robin) :轮叫,轮询
说明:轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器,从1开始,直到N(内部服务器个数),然后重新开始循环。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。缺点:是不考虑每台服务器的处理能力。
(2)wrr (Weight Round Robin) :加权轮询(以权重之间的比例实现在各主机之间进行调度)
说明:由于每台服务器的配置、安装的业务应用等不同,其处理能力会不一样。所以,我们根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求。
(3)sh (Source Hashing) : 源地址hash实现会话绑定sessionaffinity
说明:简单的说就是有将同一客户端的请求发给同一个real server,源地址散列调度算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的并且没有超负荷,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标IP地址换成请求的源IP地址。
(4)dh : (Destination Hashing) : 目标地址hash
说明:将同样的请求发送给同一个server,一般用于缓存服务器,简单的说,LB集群后面又加了一层,在LB与realserver之间加了一层缓存服务器,当一个客户端请求一个页面时,LB发给cache1,当第二个客户端请求同样的页面时,LB还是发给cache1,这就是我们所说的,将同样的请求发给同一个server,来提高缓存的命中率。目标地址散列调度算法也是针对目标IP地址的负载均衡,它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
动态调度算法(dynamic Sche)(6种):
(1)lc (Least-Connection Scheling): 最少连接
说明:最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器,最小连接调度是一种动态调度短算法,它通过服务器当前所活跃的连接数来估计服务器的负载均衡,调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1,当连接中止或超时,其连接数减一,在系统实现时,我们也引入当服务器的权值为0时,表示该服务器不可用而不被调度。此算法忽略了服务器的性能问题,有的服务器性能好,有的服务器性能差,通过加权重来区分性能,所以有了下面算法wlc。
简单算法:active*256+inactive (谁的小,挑谁)
(2)wlc (Weighted Least-Connection Scheling):加权最少连接
加权最小连接调度算法是最小连接调度的超集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1,系统管理员可以动态地设置服务器的权限,加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。由于服务器的性能不同,我们给性能相对好的服务器,加大权重,即会接收到更多的请求。
简单算法:(active*256+inactive)/weight(谁的小,挑谁)
(3)sed (shortest expected delay scheling):最少期望延迟
说明:不考虑非活动连接,谁的权重大,我们优先选择权重大的服务器来接收请求,但会出现问题,就是权重比较大的服务器会很忙,但权重相对较小的服务器很闲,甚至会接收不到请求,所以便有了下面的算法nq。
基于wlc算法,简单算法:(active+1)*256/weight (谁的小选谁)
(4).nq (Never Queue Scheling): 永不排队
说明:在上面我们说明了,由于某台服务器的权重较小,比较空闲,甚至接收不到请求,而权重大的服务器会很忙,所此算法是sed改进,就是说不管你的权重多大都会被分配到请求。简单说,无需队列,如果有台real server的连接数为0就直接分配过去,不需要在进行sed运算。
(5).LBLC(Locality-Based Least Connections) :基于局部性的最少连接
说明:基于局部性的最少连接算法是针对请求报文的目标IP地址的负载均衡调度,主要用于Cache集群系统,因为Cache集群中客户请求报文的目标IP地址是变化的,这里假设任何后端服务器都可以处理任何请求,算法的设计目标在服务器的负载基本平衡的情况下,将相同的目标IP地址的请求调度到同一个台服务器,来提高服务器的访问局部性和主存Cache命中率,从而调整整个集群系统的处理能力。
(6).LBLCR(Locality-Based Least Connections with Replication) :基于局部性的带复制功能的最少连接
说明:基于局部性的带复制功能的最少连接调度算法也是针对目标IP地址的负载均衡,该算法根据请求的目标IP地址找出该目标IP地 址对应的服务器组,按“最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按“最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除, 以降低复制的程度。
⑤ U8服务器参数配置中负载均衡如何设置
网络的负载均衡是一种动态均衡技术,通过一些工具实时地分析数据包,掌握网络中的数据流量状况,把任务合理均衡地分配出去。这种技术基于现有网络结构,提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法,加强了网络数据处理能力,提高了网络的灵活性和可用性。
以四台服务器为例实现负载均衡:
安装配置LVS
1. 安装前准备:
(1)首先说明,LVS并不要求集群中的服务器规格划一,相反,可以根据服务器的不同配置和负载状况,调整负载分配策略,充分利用集群环境中的每一台服务器。如下表:
Srv Eth0 Eth0:0 Eth1 Eth1:0
vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254
vsbak 10.0.0.3 192.168.10.102
real1 192.168.10.100
real2 192.168.10.101
其中,10.0.0.2是允许用户访问的IP。
(2)这4台服务器中,vs1作为虚拟服务器(即负载平衡服务器),负责将用户的访问请求转发到集群内部的real1,real2,然后由real1,real2分别处理。
Client为客户端测试机器,可以为任意操作系统。
(3)所有OS为redhat6.2,其中vs1 和vsbak 的核心是2.2.19, 而且patch过ipvs的包, 所有real
server的Subnet mask 都是24位, vs1和vsbak 的10.0.0. 网段是24 位。
2.理解LVS中的相关术语
(1) ipvsadm :ipvsadm是LVS的一个用户界面。在负载均衡器上编译、安装ipvsadm。
(2) 调度算法: LVS的负载均衡器有以下几种调度规则:Round-robin,简称rr;weighted
Round-robin,简称wrr;每个新的连接被轮流指派到每个物理服务器。Least-connected,简称lc;weighted
Least-connected,简称wlc,每个新的连接被分配到负担最小的服务器。
(3) Persistent client
connection,简称pcc,(持续的客户端连接,内核2.2.10版以后才支持)。所有来自同一个IP的客户端将一直连接到同一个物理服务器。超时时间被设置为360秒。Pcc是为https和cookie服务设置的。在这处调度规则下,第一次连接后,所有以后来自相同客户端的连接(包括来自其它端口)将会发送到相同的物理服务器。但这也会带来一个问题,因为大约有25%的Internet
可能具有相同的IP地址。
(4) Persistent port
connection调度算法:在内核2.2.12版以后,pcc功能已从一个调度算法(你可以选择不同的调度算法:rr、wrr、lc、wlc、pcc)演变成为了一个开关选项(你可以让rr、
wrr、lc、wlc具备pcc的属性)。在设置时,如果你没有选择调度算法时,ipvsadm将默认为wlc算法。 在Persistent port
connection(ppc)算法下,连接的指派是基于端口的,例如,来自相同终端的80端口与443端口的请求,将被分配到不同的物理服务器上。不幸的是,如果你需要在的网站上采用cookies时将出问题,因为http是使用80端口,然而cookies需要使用443端口,这种方法下,很可能会出现cookies不正常的情况。
(5)Load Node Feature of Linux Director:让Load balancer 也可以处理users 请求。
(6)IPVS connection synchronization。
(7)ARP Problem of LVS/TUN and LVS/DR:这个问题只在LVS/DR,LVS/TUN 时存在。
3. 配置实例
(1) 需要的软件包和包的安装:
I. piranha-gui-0.4.12-2*.rpm (GUI接口cluster设定工具);
II. piranha-0.4.12-2*.rpm;
III. ipchains-1.3.9-6lp*.rpm (架设NAT)。
取得套件或mount到光盘,进入RPMS目录进行安装:
# rpm -Uvh piranha*
# rpm -Uvh ipchains*
(2) real server群:
真正提供服务的server(如web
server),在NAT形式下是以内部虚拟网域的形式,设定如同一般虚拟网域中Client端使用网域:192.168.10.0/24
架设方式同一般使用虚拟IP之局域网络。
a. 设网卡IP
real1 :192.168.10.100/24
real2 :192.168.10.101/24
b.每台server均将default gateway指向192.168.10.254。
192.168.10.254为该网域唯一对外之信道,设定在virtual server上,使该网域进出均需通过virtual server 。
c.每台server均开启httpd功能供web server服务,可以在各real server上放置不同内容之网页,可由浏览器观察其对各real
server读取网页的情形。
d.每台server都开启rstatd、sshd、rwalld、ruser、rsh、rsync,并且从Vserver上面拿到相同的lvs.conf文件。
(3) virtual server:
作用在导引封包的对外主机,专职负责封包的转送,不提供服务,但因为在NAT型式下必须对进出封包进行改写,所以负担亦重。
a.IP设置:
对外eth0:IP:10.0.0.1 eth0:0 :10.0.0.2
对内eth1:192.168.10.1 eth1:0 :192.168.10.254
NAT形式下仅virtual server有真实IP,real server群则为透过virtual server.
b.设定NAT功能
# echo 1 >; /proc/sys/net/ipv4/ip_forward
# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag
# ipchains -P forward MASQ
c.设定piranha 进入X-window中 (也可以直接编辑/etc/lvs.cf )
a).执行面板系统piranha
b).设定“整体配置”(Global Settings) 主LVS服务器主机IP:10.0.0.2, 选定网络地址翻译(预设) NAT路径名称:
192.168.10.254, NAT 路径装置: eth1:0
c).设定虚拟服务器(Virtual Servers) 添加编辑虚拟服务器部分:(Virtual
Server)名称:(任意取名);应用:http;协议: tcp;连接:80;地址:10.0..0.2;装置:eth0:0; 重入时间:180
(预设);服务延时:10 (预设);加载监控工具:ruptime (预设);调度策略:Weighted least-connections; 持续性:0
(预设); 持续性屏蔽: 255.255.255.255 (预设); 按下激活:实时服务器部分:(Real Servers); 添加编辑:名字:(任意取名);
地址: 192.168.10.100; 权重:1 (预设) 按下激活
另一架real server同上,地址:192.168.10.101。
d). 控制/监控(Controls/Monitoring)
控制:piranha功能的激活与停止,上述内容设定完成后即可按开始键激活piranha.监控器:显示ipvsadm设定之routing table内容
可立即更新或定时更新。
(4)备援主机的设定(HA)
单一virtual server的cluster架构virtual server 负担较大,提供另一主机担任备援,可避免virtual
server的故障而使对外服务工作终止;备份主机随时处于预备状态与virtual server相互侦测
a.备份主机:
eth0: IP 10.0.0.3
eth1: IP 192.168.10.102 同样需安装piranha,ipvsadm,ipchains等套件
b.开启NAT功能(同上面所述)。
c.在virtual server(10.0.0.2)主机上设定。
a).执行piranha冗余度 ;
b).按下“激活冗余度”;
冗余LVS服务器IP: 10.0.0.3;HEARTBEAT间隔(秒数): 2 (预设)
假定在…秒后进入DEAD状态: 5 (预设);HEARTBEAT连接端口: 539 (预设)
c).按下“套用”;
d).至“控制/监控”页,按下“在当前执行层添加PULSE DEAMON” ,按下“开始”;
e).在监控器按下“自动更新”,这样可由窗口中看到ipvsadm所设定的routing table,并且动态显示real
server联机情形,若real server故障,该主机亦会从监视窗口中消失。
d.激活备份主机之pulse daemon (执行# /etc/rc.d/init.d/pulse start)。
至此,HA功能已经激活,备份主机及virtual server由pulse daemon定时相互探询,一但virtual
server故障,备份主机立刻激活代替;至virtual server 正常上线后随即将工作交还virtual server。
LVS测试
经过了上面的配置步骤,现在可以测试LVS了,步骤如下:
1. 分别在vs1,real1,real2上运行/etc/lvs/rc.lvs_dr。注意,real1,real2上面的/etc/lvs
目录是vs2输出的。如果您的NFS配置没有成功,也可以把vs1上/etc/lvs/rc.lvs_dr复制到real1,real2上,然后分别运行。确保real1,real2上面的apache已经启动并且允许telnet。
2. 测试Telnet:从client运行telnet 10.0.0.2,
如果登录后看到如下输出就说明集群已经开始工作了:(假设以guest用户身份登录)
[guest@real1 guest]$——说明已经登录到服务器real1上。
再开启一个telnet窗口,登录后会发现系统提示变为:
[guest@real2 guest]$——说明已经登录到服务器real2上。
3. 测试http:从client运行iexplore http://10.0.0.2
因为在real1 和real2 上面的测试页不同,所以登录几次之后,显示出的页面也会有所不同,这样说明real server 已经在正常工作了。