一、LVS负载均衡结构 二、Nginx的负载结构 三、LVS和Nginx的对比四、负载均衡选型五、在高并发环境中LVS,Nginx的角色
一、LVS负载均衡结构 LVS负载均衡: 针对高可伸缩、高可用网络服务的需求,基于IP层的负载平衡调度解决方法,并在Linux内核中实现了这些方法,将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。IPVS的总体结构主要如下: 客户端访问–IPVS检测负载均衡算法和调度算法–IPVS处理IP包—IPVS根据虚拟服务器与真实服务器链表发往真实服务器(RS)-RS返回数据。 LVS的实现方式: VS/NAT VS/TUN VS/DR
图1
LVS 在生产中的环境:
图2
LVS各种解构的性能分析: LVS本身是基于IP层的负载均衡,可以说是最高效的一个种方式。但基于NAT方式的,往往在流量的环境中会出现性能问题,NAT模式是需要资源最多的模式,其实是TUN模式,TUN模式对系统要求也比较高。 目前来说推荐用DR方式,目前没遇到性能问题。 二、Nginx的负载结构 Nginx的负载均衡是一个基于内容和应用的七层交换负载均衡的实现。 同样Nginx也是一个Http的服务端。 负载均衡主要使用的Nginx的ngx_http_upstream_hash_module模块。 Nginx的负载结构:
图3
Nginx的性能分析: Nginx的负均衡实现比较简单,默认对后端有健康检查的能力。后端机器少的情况下(少于10台)负载均衡能力表现好。
缺点: 所以访问从一个出口出去,容易引起流量浪涌连接失败。后面机器较多时(多于10)无法良好的发挥机器性能。 三、LVS和Nginx的对比 LVS: Nginx: 是基于内容的负载均衡实现,实现模式和LVS的NAT模式相似,但性能比LVS的NAT高。 四、负载均衡的选型原则 LVS=>Nginx=>Cache
对比web1.0和web2.0的解决方案碰到的困难 Web1.0 1、源数据量小,单台squid即可达到很高的命中率。 2、请求量大,用lvs+squid或者dns轮询即可解决问题。 3、squid服务器磁盘IO压力大,用超大内存做cache。
web 2.0 1、数据变化频繁,数据总量大,squid的hast table较大,命中下降。 2、请求量大,种类多,数据源上T是正常现象,squid的Cache更新现象严重。 3、Cache的IO更新严重,致使效率低下 4、基于HASH的URL CACHE,其中一台Cache死掉,必将引起Hash ReHash 5、压力过大导致的hit ratio抖动
负载均衡的选型总结 总结上面问题如果只是简单的负载均衡,难于解决WEB2.0的问题。Nginx可以说是一个完美的方案,但一个大的网站流量不只是一个千兆网卡能挡住的。 五、在高并发环境中LVS、Nginx的角色
图4
Nginx的实现代码: upstream img1{ server 192.168.100.1; server 192.168.100.2; upstream img2{ server 192.168.100.1:81; server 192.168.100.2:82; … location ~ ^/[0-1][0-f]/ { proxy_pass http://img1; location ~ ^/[2-3][0-f]/ { proxy_pass http://img2; … 这种结构的优点: 在后端服务器中模拟url hash的算法来找到内容所在的squid,提高了命中率。 充分发挥机器的性能,架构可扩展性,层次分明。 http://www./dyn/closer.cgi/hadoop/core/
|