在上一篇文章中,介绍了负载均衡服务,常用的负载均衡服务器以及负载均衡服务在公司的应用情况。这一篇文章会对上篇提到的负载均衡服务器进行较为深入的分析,对其主要功能,优缺点,使用场景进行介绍。希望可以起到抛砖引玉的左右,对大家在了解,使用不同的负载均衡服务有所帮助。
LVS
LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个基于Linux的负载均衡服务器。LVS项目在1998年5月由章文嵩博士成立,现在已经得到了极为广泛的应用,国内外有很多网站和组织都在生产环境中使用LVS系统。
LVS是基于Linux内核模块,通过在协议包工作链上对应位置挂载hook代码,来实现对网络包的解析和重写。其工作原理与iptables相同。在Linux2.4之后,LVS打入Linux标准内核,不需要安装额外的软件即可使用。LVS运行于Linux内核之中,用户要通过运行于用户态的工具(ipvsadm)来对LVS进行配置。下图是Linux 数据包协议栈的工作链和LVS的挂载点:
这几个工作链主要是工作时间不同:
NF_IP_PRE_ROUTING:在报文作路由以前执行
NF_IP_FORWARD:在报文转向另一个NIC以前执行
NF_IP_POST_ROUTING:在报文流出以前执行
NF_IP_LOCAL_IN:在流入本地的报文作路由以后执行
NF_IP_LOCAL_OUT:在本地报文做流出路由前执行
对于数据包,LVS的工作流程是:PREROUTING -> LOCAL_IN -> POSTROUTING
对于出去的包(只有NAT有效):PREROUTING -> FORWARD -> POSTROUTING
对于Ping包:PREROUTING -> FORWARD -> POSTROUTING
主要特点:
与应用层的负载均衡不同,LVS运行在内核模式,没有系统调用开销。而只支持四层负载均衡模式,LVS也不用处理复杂的七层协议,因此有着很高的性能。当单臂模式的设计又可以让LVS承载大量流量(与后端对比一般可以达到1:10左右),因此LVS常常被用作整个系统的流量入口。 由于LVS的资源占用很少,在日常的应用中,其瓶颈常在于网络带宽而不是CPU和内存,因此运行在物理机上的LVS一般都会配置万兆或以上的网卡。阿里云的LVS集群就采用了单台LVS配置四个万兆网卡的形式来提高资源利用率和处理能力。
功能介绍:
LVS是一个纯粹的负载均衡服务器,只支持四层负载均衡,支持三种模式,NAT,TUN和DR模式。
NAT模式:工作在TCP层,这时LVS的功能与其他四层负载均衡服务器类似,是通过NAT协议来修改数据包中的Source IP或者Dest IP地址,来实现负载均衡。在NAT模式下,上下行的流量都需要经过LVS,因此LVS的带宽可能成为瓶颈。
TUN模式:工作在IP层:是通过在IP包的基础上再进行一次独立的IP封装,加入额外的IP头,来实现包转发功能,因此TUN协议又叫做IPIP协议。TUN模式是单臂流量,只有上行数据会经过LVS,下行数据则直接通过后端服务器发给用户。为了实现TU模式,后端服务器上需要支持IPIP协议,并绑定一个TUN设备和对应的VIP地址。
DR模式:DR模式工作在二层,是通过直接修改mac帧中的目标mac地址,来实现数据转发功能。因为DR模式走的是mac层的协议,因此需要负载均衡服务和后端服务器在同一个二层(同一个广播域)之中。
总结:使用方面,NAT模式使用最为灵活,对后端无侵入性,但性能也最差。DR模式性能最好,但对网络拓扑结构有要求。而TUN模式可以达到和DR模式相近的性能,但是需要后端对IPIP协议的支持。
优缺点分析
优点:LVS运行简单,性能非常强大(运行在DR或者TUN模式下的一台LVS可以支持后端上百台服务器的需要),而且服务十分稳定(代码很少有改动)。同时,由于直接集成在Linux内核中,使用简单,不需要额外安装。
缺点:模式不够灵活,可配置项少,只支持三种固定模式,很难满足一些自定义的需求。而LVS服务本身也十分简单,没有其他负载均衡服务所带的健康检查等功能,需要其他工具(keepalived,OSPF等)支持。社区不够活跃,代码更新和活跃度不高。
应用场景:
LVS一般是用在网络入口的位置,使用一组高可用的LVS集群后面会再接Haproxy,Nginx,Apache等七层负载均衡服务。对于一些四层的应用,也会在前面直接架设一套LVS,使用LVS的NAT模式进行请求转发和负载均衡。
Nginx/Tengine/Open Resty
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行。Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。
Nginx起源也是web服务器,但是与Apache不同,Nginx采用的是异步模式,epoll模型来实现,与Apache相比,Nginx在性能,资源消耗方面都有很大的提高。Nginx也是为了解决C 10K问题而开发的服务器之一。
主要功能:
作为一个web服务器,可以提供HTTP资源的访问,还可以与php结合,提供动态页面支持。而作为负载均衡服务器,Nginx除了HTTP/HTTPS协议之外,Nginx还支持IMAP/POP3协议,可以作为邮件的代理服务器使用。除了基本的负载均衡功能外,Nginx还支持URL重写,基于Cookie,URL的转发等功能。
Nginx还有良好的扩展性,支持通过lua脚本进行功能扩展,可以根据自己的需要,开发具体的业务逻辑。 Nginx基于多进程模型,首先启动一个master进程,然后fork出多个worker进程(可配置),worker进程通过抢占的方式来处理请求,具体运行架构如下图所示:
Master进程只负责接受连接,不会执行具体的业务逻辑。Worker进程通过抢占的方式从master那里得到请求,处理具体的业务逻辑,包括请求解析,提供http服务,请求转发等。 当重新reload时,Master会根据配置重新启动一组新的worker进程,同时把请求全部转发给新的worker。老的worker不再处理请求,当当前请求处理完毕之后才会退出。因此Nginx可以在运行时无缝加载和reload。
优缺点分析
优点:Nginx基于epoll的异步模型,资源占用很少,在实际测试中,在处理4000并发连接时,内存资源占用也仅仅只有123.63MB。而Nginx对于运维操作也非常友好,支持运行时reload,并且不会丢失用户请求。Nginx的多进程模型可以方便的使用多核资源,同时支持CPU绑定,可以把具体的Nginx worker进程绑定在具体的物理CPU之上。
缺点:Nginx在处理大的post请求时,会将请求先缓存在本地磁盘,当请求很大且并发请求很多时,磁盘性能会成为瓶颈,而且出现过由于硬盘写满导致请求失败的情况。同时,Nginx也不支持会话保持和主动监测,健康检查结果展示也不大优好。
衍生版本
Nginx社区十分活跃,并且在应用中有基于Ningx开发的很多衍生版本,这里就介绍两个版本:Tengine和OpenResty。
Tengine:是阿里基于Nginx开发的衍生版本,补齐了Nginx的短板(Post缓存,主动健康检查,监控页面等),并在此基础上进行了二次开发,对性能和易用性(加入了很多自动配置的选项)进行了优化。
优点:已经在阿里内部得到了广泛的应用,有大量的实践基础和调优经验。性能,稳定性方面有保障。
缺点:直接更改Nginx内核,因此需要通过人工兼容的方式来跟随Nginx主版本升级。
OpenResty:基于Nginx开发的另一个衍生版本,直接加入了很多优质的Nginx模块,从而大大扩展了Nginx本身的功能。与Tengine不同,它没有直接更改Nginx内核,而是通过加入模块的方式来提供功能扩展。
应用场景
Nginx可以直接运行在系统最前面,通过Keepalived实现高可用,作为系统流量的入口使用。也可以对接LVS,Haproxy等四层负载均衡,对流量进行二次分流。
Haproxy:
Haproxy是一个专门的负载均衡服务器,支持四层/七层负载均衡。与Nginx,apache等不同,Haproxy不提供静态资源访问,URL重写等web服务器相关功能。
功能介绍
Haproxy也是基于事件机制的异步模型,但与nginx不同,Haproxy是基于单进程模型,没有提供天然的多进程扩展。虽然可以通过fork进程来实现多进程模型,但是会引起一些问题,因此官方并不推荐这种做法。在实际应用中一般都是把它作为一个单进程负载均衡服务使用。
优缺点分析
优点:可以同时支持四层,七层负载均衡,有很高的性能。支持Seesion Sticky,有良好的监控页面,同时不存在Post缓存问题。
缺点:由于Haproxy是基于但进程模型,在reload时会导致短暂的不可用,同时不支持https。在作为四层四层负载均衡服务器时无法获取原始IP。单进程模型,对多核支持不好(需要多个实例),虽然可以运作在多核模式下,但存在着一些问题。
应用场景:
作为四层负载均衡服务,可以直接接后端服务使用,但由于是采用双臂模式和单进程模型,并不适合作为单独的流量入口。在不需要获取源IP或者对性能要求不是很高的情况下作为四层负载均衡服务器使用。或者作为七层负载均衡服务器,专门处理七层的上传请求。
Apache
Apache 起初由伊利诺伊大学香槟分校的国家超级电脑应用中心(NCSA)开发,是现在互联网中使用最热门和访问量最大的HTTP服务器,同时还可以通过加载模块来完成反向代理功能,但严格来说Apache并不是一个很好的负载均衡服务器,在性能,功能上与较为专业的负载均衡服务相比并无优势,而功能也乏善可陈。但是考虑到Apache的广泛应用以及基于Apache的负载均衡服务在实际的生产环境中还是有不少应用。
功能介绍:
Apache是一个web服务器,通过可以通过加载模块来实现负载均衡服务。作为一个强大的web服务器,Apache在解析HTTP协议有天然的优势,支持基于域名分流,URL分析,URL重写,转发等功能。
Apache支持两种模式的负载均衡:基于mod_proxy模块的一般负载均衡和基于mod_proxy_ajp模块的二进制负载均衡。这两种模式的主要区别在于Apache和后端服务之间的连接方式。一般的负载均衡是采用HTTP协议,使用文本传输,而ajp模式则采用二进制模式,因此性能上会更好。但相对的,AJP模式需要后端服务器的支持,在一般应用时,会通过跟tomcat结合来提供负载均衡服务。
优缺点分析
优点:Apache是应用最广的web服务器,因此在服务应用上面有着天然的优势。而Apache+Tomcat的模式可以满足现在大部分网站对于静态资源和动态资源的需求。而作为一个强大的web服务器,Apache还支持URL重写,URL转发等web服务相关的操作,可以对后端服务提供更多支持。
缺点:作为负载均衡服务器,主要问题是采用的多进程模式,每个连接在处理时都会开独立的线程,当连接请求数据很多时,会有在处理高并发时会有性能隐患。
应用场景:
因为无论从性能还是功能上看,都有更好的选择,因此Apache一般不会单独作为负载均衡服务器使用。一般是采用Apache服务作为静态文件服务器使用的时候,使用AJP模块与后端的Tomcat对接,提供简单的负载均衡支持。
总结
本文对常用的四种负载均衡服务进行了简单的介绍,在之后的文章中,会对具体的负载均衡服务进行更为深入的分析和说明。