龙空技术网

DNS、硬件、LVS、Nginx该如何搭配?

zw源 172

前言:

而今各位老铁们对“nginx七层模型”可能比较注重,咱们都想要知道一些“nginx七层模型”的相关知识。那么小编同时在网络上汇集了一些对于“nginx七层模型””的相关知识,希望咱们能喜欢,兄弟们一起来学习一下吧!

1、为什么要负载均衡?

系统的扩展可分为纵向(垂直)扩展和横向(水平)扩展。纵向扩展,是从单机的角度通过增加硬件处理能力,比如CPU处理能力,内存容量,磁盘等方面,实现服务器处理能力的提升,不能满足大型分布式系统(网站),大流量,高并发,海量数据的问题。因此需要采用横向扩展的方式,通过添加机器来满足大型网站服务的处理能力。比如:一台机器不能满足,则增加两台或者多台机器,共同承担访问压力。这就是典型的集群和负载均衡架构,如下图:

应用集群:将同一应用部署到多台机器上,组成处理集群,接收负载均衡设备分发的请求,进行处理,并返回相应数据。

负载均衡设备:将用户访问的请求,根据负载均衡算法,分发到集群中的一台处理服务器(一种把网络请求分散到一个服务器集群中的可用服务器上去的设备)。

负载均衡的作用(解决的问题):

1、解决并发压力,提高吞吐量。

2、提供故障转移,检测下游服务器状态,实现高可用。

3、利于横向扩展服务器。

4、安全防护,负载均衡设备上做一些过滤,黑白名单等处理。

2、负载均衡种类2.1 DNS负载均衡

最早的负载均衡技术,利用域名解析实现负载均衡,在DNS服务器,配置多个A记录,这些A记录对应的服务器构成集群。大型网站总是部分使用DNS解析,作为第一级负载均衡。如下图:

优点

1、使用简单:负载均衡工作,交给DNS服务器处理,省掉了负载均衡服务器维护的麻烦。

2、提高性能:可以支持基于地址的域名解析,解析成距离用户最近的服务器地址,可以加快访问速度,改善性能。

缺点

1、可用性差:DNS解析是多级解析,新增/修改DNS后,解析时间较长;解析过程中,用户访问网站将失败。

2、扩展性低:DNS负载均衡的控制权在域名商那里,无法对其做更多的改善和扩展。

3、维护性差:也不能反映服务器的当前运行状态;支持的算法少;不能区分服务器的差异(不能根据系统与服务的状态来判断负载)。

4、更新不及时:DNS缓存可能会保留较长时间。

实践建议

将DNS作为第一级负载均衡,A记录对应着内部负载均衡的IP地址,通过内部负载均衡将请求分发到真实的Web服务器上。

2.2 硬件负载均衡

硬件负载均衡通过单独的硬件设备来实现负载均衡功能,这类设备和路由器、交换机类似。

目前业界典型的硬件负载均衡设备有两款: F5 和 A10 。性能强劲、功能强大,但价格都很昂贵。

优点

1、功能强大:全面支持各层级的负载均衡,支持全面的负载均衡算法,支持全局负载均衡。

2、性能强大:对比一下,软件负载均衡支持到 10 万级并发已经很厉害了,硬件负载均衡可以支持 100 万以上的并发。

3、稳定性高:商用硬件负载均衡,经过了良好的严格测试,经过大规模使用,稳定性高。

4、支持安全防护:硬件均衡设备除具备负载均衡功能外,还具备防火墙、防 DDoS 攻击等安全功能。

缺点

1、价格昂贵:最普通的一台 F5十多万,好一点近百万元。

2、扩展能力差:硬件设备,可以根据业务进行配置,但无法进行扩展和定制。

实践建议

可以在DNS作地理级别负载均衡的情况下,在其下级使用F5或A10作为低级的负载均衡器,之后将流量转发到下级集群,如下图所示。

2.3 软件负载均衡

软件负载均衡,可以在普通的服务器上运行负载均衡软件,实现负载均衡功能。目前常见的有 NginxHAproxyLVS,其中的区别:

Nginx:七层(OSI网络七层模型,第七层应用层)负载均衡,支持 HTTP、E-mail 协议,同时也支持四层负载均衡;HAproxy:支持七层规则的,性能也很不错。OpenStack 默认使用的负载均衡软件就是 HAproxy;LVS:运行在内核态,性能是软件负载均衡中最高的,严格来说工作在第三层网络层,所以更通用一些,适用各种应用服务。

优点

1、易操作:无论是部署还是维护都相对比较简单。

2、便宜:只需要服务器的成本,软件是免费的

3、灵活:4 层和 7 层负载均衡可以根据业务特点进行选择,方便进行扩展和定制功能。

与硬件负载均衡相比的缺点

1、性能一般,一个 Nginx 大约能支撑 5 万并发。

2、功能没有硬件负载均衡那么强大。

3、一般不具备防火墙和防 DDoS 攻击等安全功能。

3、LVS:专注网络更底层,性能更卓越

前面介绍了负载均衡的种类后,可以看到重点应该在软件负载均衡。Nginx大家都应该有所耳闻,工作在应用层,配置方便,所有的流量(相应、请求报文)都会经过代理服务器Nginx,但如果流量较大,势必为成为系统的瓶颈,而工作在传输层和网络层的LVS负载均衡器具有更强的负载均衡能力。概括的来说,它能在网络层就实现路由重定向,之后响应报文会直接通过真实服务器发送给原始的客户端,不走LVS,大大降低了流量;但需要在代理服务器和真实服务器上进行复杂的配置,而且不会有错误检测和重发。

4、DNS+硬件+LVS+Nginx多级负载均衡

前面咱们提到DNS负载均衡的时候就引出了多级负载均衡的概念,LVS像是在硬件负载均衡器和Nginx之间的一种折中的解决方案,由此可以形成一种 DNS —> F5/A10 —> LVS —> Nginx

的负载均衡架构体系了(具体系统具体分析,可以取消任意一层),很像计算机网络的网络层+数据链路层多级架构的模式。

LVS + 多Nginx 的使用中,既可以避免LVS故障检测的短板,又能避免Nginx性能瓶颈问题。同时nginx 还可以作为一个中间环节来减小后端 tomcat 的服务压力,以及做一些业务切换、分流、前置缓存的功能。

5、负载均衡器高可用集群

单点LVS或Nginx仍然可能存在单点故障(可能概率极小),可以根据业务的关键程度,构建负载均衡器集群,LVS自身有双机热备机制(主备架构),Nginx需要额外编写软件来实现主备或主从架构。

6、到底要不要负载均衡?

前面谈论了这么多的负载均衡方案,为什么又回到了第一个问题,做不做负载均衡?或者说,横向扩展真的有必要么?这确实是一个相对的问题,如果只是常规的中小应用,qps根本达不到单机Nginx的峰值5W (可以参考20W用户的应用qps只有十几),即使是大型应用,也得分应用类型,并不是每个应用都要设计成秒杀系统,横向扩展了之后意味着需要投入成倍的管理成本。总之,可以先优化算法,分析系统瓶颈,重构单机应用代码,软件实在无法扩展了之后再考虑扩展硬件,而且现在处于云计算时代,弹性云服务器是很方便进行硬件扩展的,最后的最后,再考虑集群架构。切记,不要一味地为了高吞吐量而采用直接集群、分布式,技术架构要跟着业务能力跑。如果只是个人博客网站,做负载均衡可能只是感动自己。

如若转载,请注明出处:开源字节

标签: #nginx七层模型 #nginxdns配置详解 #关键字过滤nginx #nginx单机并发数 50万 #nginx不保留dns缓存