服务器负载均衡的作用
随着网站、应用访问量的增加,一台服务器租用已经不能满足应用的需求,而需要多台服务器集群,这时就会用到负载均衡,那么负载均衡优点是什么呢呢,今天南昌壹基比小小喻下面为大家讲解一下:
服务器负载均衡有哪些优点:
• 负载均衡优化了访问请求在服务器组之间的分配,消除了服务器之间的负载不平衡,从而提高了系统的反应速度与总体性能;
• 负载均衡可以对服务器的运行状况进行监控,及时发现运行异常的服务器,并将访问请求转移到其它可以正常工作的服务器上,从而提高服务器组的可靠性采用了负均衡器器以后,可以根据业务量的发展情况灵活增加服务器,系统的扩展能力得到提高,同时简化了管理。
负载均衡器有多种多样的形式,除了作为独立意义上的负载均衡器外,有些负载均衡器集成在交换设备中,置于服务器与Internet链接之间,有些则以两块网络适配器将这一功能集成到PC中,一块连接到Internet上,一块连接到后端服务器群的内部网络上。
一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。当Web服务器为图像服务、SSL(安全套接层)会话或数据库事务而进行优化时,负载均衡器可以体现特别的价值。
当需要进行服务器升级或系统维护时,保证稳定的服务器退出服务以避免服务中断。当选定某台服务器要退出服务后,将不会将任何新的用户分配到该服务器。但是,它可以要该服务器完成对当前用户的服务。从而保证了无中断的优质服务,并且简化了服务器群的管理。
智能的服务器服务恢复:
将重新启动的服务器应用到服务中时,避免新服务器因突然出现的流量冲击导致系统故障是非常重要的。所以,在将新服务器引入服务器群时,将逐渐地增加分配到该服务器的流量,直至达到其完全的处理能力。从而不仅保证用户在服务器退出服务时,同时还保证服务器在启动期间以及应用程序开始时,均能获得不间断服务。
阅读本文前,需熟悉OSI七层参考模型。
常见的负载均衡设备,有F5,Haproxy,lvs, nginx等。
F5是商用硬件负载均衡,性能很好,但是价格昂贵,除了负载均衡,还有应用交换、会话交换、状态监控等众多功能。
F5一般做四层负载均衡,但也支持七层负载均衡。
Haproxy(以下简称ha)是软件负载均衡,开源,一般做七层负载均衡,但也支持四层负载均衡。
Linux Virtual Server(以下简称lvs)是软件负载均衡,开源,二层或四层负载均衡,已集成到linux内核,自身有完备的热备方案(keepalived+lvs),稳定性极强。
nginx也是软件负载均衡,开源,通过反向代理实现负载均衡,是七层负载均衡,性能不如上面的几个。
tips1
有些公司,测试环境用ha/lvs/nginx,生产环境用F5。
tips2
nginx做web服务器时,一般做静态资源服务器和php的web服务器,所以很多公司,会采用F5+nginx或者ha+nginx的架构
tips3
微服务中的ribbon属于客户端负载均衡,上面的几种都是服务端负载均衡
二层负载均衡
在数据链路层通过修改mac地址实现,如lvs的DR模式(直接路由模式)
三层负载均衡
在网络层通过DNAT协议修改目标地址实现
四层负载均衡
用ip+端口实现请求转发
备注:tcp报文里并没有ip,但是四层负载均衡可以用ip+端口,是因为server可以拿到ip
七层负载均衡
通过重新发起http请求实现,即client把请求发给lb,lb把请求代发给server,再把server的响应返回给client,因此七层负载均衡也经常被称为代理,七层负载均衡设备也被称为代理设备。
七层负载均衡常用于内网与外网的通信,比如内网无法直接访问外网,需要通过代理设备代发http请求,这种情况下,代理设备需要配置双网卡,以同时与内外网络通信。
由于需要重发http请求,七层负载均衡性能较差,但是更智能和安全,因为应用层可以获取甚至修改请求的真实内容(即应用数据),比如cookie、url等,可以做一些智能的操作,比如根据cookie/url转发请求,也可以做一些安全操作,比如过滤特定报文、防止SYN Flood攻击等。
使用七层负载均衡时,服务的性能受限于代理设备的网卡带宽。
常见的负载均衡策略,有轮询、加权轮询、ip_hash、cookie、url_hash,根据服务器响应时间转发、根据最少连接转发等等。
备注:nginx可以安装第三方插件,使用第三方实现的策略
轮询:按服务器列表顺序转发请求,轮询是nginx默认的策略,本策略适合服务器配置相当、请求无状态(即不依赖session)的场景
加权轮询:如果不同服务器配置不同,可以为配置高的服务器增加权重
ip_hash:根据ip哈希结果转发,可以实现同一用户持续请求同一服务器(即会话保持),适合有状态(即依赖session)的场景,对png、jpg、js、css等静态资源的请求,不适合使用本策略
cookie:根据特定cookie转发请求,一般也是用于实现会话保持,比如为服务器A、B分别增加service-flag=a、service-flag=b的cookie,后续请求根据cookie转发
可以参考 haproxy实现会话保持
url_hash:根据url哈希结果转发,同一个接口始终请求同一台服务器,一般配合缓存使用,缓存接口返回结果
根据服务器响应时间转发:优先转发到响应时间较快的服务器
根据最少连接转发:优先转发到连接数较少的服务器
F5有一些特有的负载均衡策略:利用从应用程序和服务器收集到的各项性能指标,分析并转发
负载均衡有两个步骤:
1根据什么算法选择真实服务端,即负载均衡策略,如轮询、加权轮询、ip_hash、cookie、url_hash等;
2把请求转发到真实服务器,转发方式有二层到七层负载均衡
keepalived软件一开始是专为lvs设计的,后来加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议)功能,因此,keepalived还可以作为nginx、haproxy、mysql等服务的高可用解决方案。
以nginx为例,为了防止nginx本身由于宕机等原因导致网站不可用,一般会搭两套nginx反向代理,用keepalived提供一个VIP。
一般情况下,VIP只在nginx主节点上工作,如果nginx主节点不可用了,VIP会自动漂移到从节点,自动漂移的原理即VRRP协议。
VIP漂移到从节点后,如果主节点恢复正常了,VIP是否漂移回主节点,取决于当前模式是抢占模式还是非抢占模式。
下图是一张简单的架构图,解释如下:
以上观点纯属个人意见,如果错误,欢迎指出,有些地方写的很简单,是因为我也不懂~
0条评论