硬件负载均衡设备介绍

最常用是F5 与citrix netscaler

负载均衡分全局负载均衡和本地负载均衡。

地负载均衡是指对本地的服务器群做负载均衡,全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。

循环DNS

就是每次解析域名时指向IP loop list 里的下一个IP.

负载均衡路由器

通过某种策略把请求发送到响应最快的server上, 同时可以满足故障转移/故障恢复. 但是负载均衡路由器本身需要维护,通常需要有两个, 来防止单点故障.

例如Alteon 180 和 F5 Network 的 Big-IP

负载均衡可以针对不同的网路层次

链路聚合技术(第二层负载均衡)是将多条物理链路当作一条单一的聚合逻辑链路使用,网络数据流量由聚合逻辑链路中所有物理链路共同承担,由此在逻辑上增大了链路的容量,使其能满足带宽增加的需求.

现在经常使用的是4至7层的负载均衡。

第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址,对每次TCP连接请求动态使用其中一个内部IP地址,达到负载均衡的目的。在第四层交换机中,此种均衡技术得到广泛的应用,一个目标地址是服务器群VIP(虚拟IP,Virtual IP address)连接请求的数据包流经交换机,交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略,在服务器IP和VIP间进行映射,选取服务器群中最好的服务器来处理连接请求。

第七层负载均衡控制应用层服务的内容,提供了一种对访问流量的高层控制方式,适合对HTTP服务器群的应用。第七层负载均衡技术通过检查流经的HTTP报头,根据报头内的信息来执行负载均衡任务。 

第七层负载均衡优点表现在如下几个方面:

1。通过对HTTP报头的检查,可以检测出HTTP400、500和600系列的错误信息,因而能透明地将连接请求重新定向到另一台服务器,避免应用层故障。

2。可根据流经的数据类型(如判断数据包是图像文件、压缩文件或多媒体文件格式等),把数据流量引向相应内容的服务器来处理,增加系统性能。

3。能根据连接请求的类型,如是普通文本、图象等静态文档请求,还是asp、cgi等的动态文档请求,把相应的请求引向相应的服务器来处理,提高系统的性能及安全性。

缺点: 第七层负载均衡受到其所支持的协议限制(一般只有HTTP),这样就限制了它应用的广泛性,并且检查HTTP报头会占用大量的系统资源,势必会影响到系统的性能,在大量连接请求的情况下,负载均衡设备自身容易成为网络整体性能的瓶颈

负载均衡策略:

1.       轮循均衡(Round Robin):每一次来自网络的请求轮流分配给内部中的服务器,从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

2.       权重轮循均衡(Weighted Round Robin):根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求。例如:服务器A的权值被设计成1,B的权值是3,C的权值是6,则服务器A、B、C将分别接受到10%、30%、60%的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率,避免低性能的服务器负载过重。

3.       随机均衡(Random):把来自网络的请求随机分配给内部中的多个服务器。

4.       权重随机均衡(Weighted Random):此种均衡算法类似于权重轮循算法,不过在处理请求分担时是个随机选择的过程。

5.       响应速度均衡(Response Time):负载均衡设备对内部各服务器发出一个探测请求(例如Ping),然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态,但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间,而不是客户端与服务器间的最快响应时间。

6.       最少连接数均衡(Least Connection):客户端的每一次请求服务在服务器停留的时间可能会有较大的差异,随着工作时间加长,如果采用简单的轮循或随机均衡算法,每一台服务器上的连接进程可能会产生极大的不同,并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录,记录当前该服务器正在处理的连接数量,当有新的服务连接请求时,将把当前请求分配给连接数最少的服务器,使均衡更加符合实际情况,负载更加均衡。此种均衡算法适合长时处理的请求服务,如FTP。

7.       处理能力均衡:此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成)最轻的服务器,由于考虑到了内部服务器的处理能力及当前网络运行状况,所以此种均衡算法相对来说更加精确,尤其适合运用到第七层(应用层)负载均衡的情况下。

8.       DNS响应均衡(Flash DNS):在Internet上,无论是HTTP、FTP或是其它的服务请求,客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下,分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求,并在同一时间内把此域名解析成各自相对应服务器的IP地址(即与此负载均衡设备在同一位地理位置的服务器的IP地址)并返回给客户端,则客户端将以最先收到的域名解析IP地址来继续请求服务,而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下,对本地负载均衡是没有意义的。

服务故障的检测方式和能力:

1.       Ping侦测:通过ping的方式检测服务器及网络系统状况,此种方式简单快速,但只能大致检测出网络及服务器上的操作系统是否正常,对服务器上的应用服务检测就无能为力了。

2.       TCP Open侦测:每个服务都会开放某个通过TCP连接,检测服务器上某个TCP端口(如Telnet的23口,HTTP的80口等)是否开放来判断服务是否正常。

3.       HTTP URL侦测:比如向HTTP服务器发出一个对main.html文件的访问请求,如果收到错误信息,则认为服务器出现故障。

链接:http://blog.csdn.net/21aspnet/article/details/6596744

负载均衡的设备类型/硬件配置    

IP应用交换机

    也就是IP链路控制器主要是指可以用来实现无缝地监控多条WAN连接的可用性与性能,以智能地管理到某一站点的双向流量,从而提供出色的容错性和优化的互联网访问,并可以提供可靠的WAN连接,提供企业级互联网连接能力确保将流量导向最佳的链路和ISP,保持为用户提供最高质量的服务和速度,通过强大的经济型链路聚合功能来最大限度提高公司的连接能力投资回报,通过边界网关协议(BGP)消除部署障碍,显著降低多归属网络的部署成本的硬件设备。可为所有基于IP的应用和Web服务提供原来只有Web应用才能享有的流量管理功能。在任何网络环境下,都能通过其功能强大的通用检查引擎(Universal Inspection Engine)和iRules准确、安全、经济高效地创建和提供所有基于IP的应用或Web服务。确保所有IP应用的高可用性和正常运行时间, 创建一个可控的执行点以对所有流量进行前瞻性安全控制, 使服务器和应用能够及时准确地做出响应,无需额外硬件、软件或其它IT资源。

负载均衡器

    是一种采用各种分配算法把网络请求分散到一个服务器集群中的可用服务器上去,通过管理进入的Web数据流量和增加有效的网络带宽,从而使网络访问者获得尽可能最佳的联网体验的硬件设备。负载均衡器有多种多样的形式,除了作为独立意义上的负载均衡器外,有些负载均衡器集成在交换设备中,置于服务器与Internet链接之间,有些则以两块网络适配器将这一功能集成到PC中,一块连接到Internet上,一块连接到后端服务器群的内部网络上。一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。当Web服务器为图像服务、SSL(安全套接层)会话或数据库事务而进行优化时,负载均衡器可以体现特别的价值。


  
 
硬件配置   
   
    
    此参数用来表示负载均衡产品的硬件基本配置,如CPU、内存、硬盘等参数的指标。 

软件与硬件负载均衡的比较 

如果我们搜一搜"负载均衡",会发现大量的关于F5等负载均衡设备的内容. 
实际上,实现负载均衡,使用象F5这样的专业设备是一种方式,而使用软件方式是另外一种方式. 现在比较一下两种方式. 
基于硬件的方式,能够直接通过智能交换机实现,处理能力更强,而且与系统无关,这就是其存在的理由.但其缺点也很明显: 
首先是贵,这个贵不仅是体现在一台设备上,而且体现在冗余配置上.很难想象后面服务器做一个集群,但最关键的负载均衡设备却是单点配置,一旦出了问题就全趴了. 
第二是对服务器及应用状态的掌握:硬件负载均衡,一般都不管实际系统与应用的状态,而只是从网络层来判断,所以有时候系统处理能力已经不行了,但网络可能还来得及反应(这种情况非常典型,比如应用服务器后面内存已经占用很多,但还没有彻底不行,如果网络传输量不大就未必在网络层能反映出来)。 所以硬件方式更适用于一大堆设备、大访问量、简单应用。 
软件方式,其实也分多种情况,这里只讲一下典型的专业负载均衡软件。看了硬件方式的不足就比较容易理解专业负载均衡软件的优点了: 
首先是基于系统与应用的负载均衡,能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的。 
第二是性价比,实际上如果几台服务器,用F5之类的绝对是杀鸡用牛刀(而且得用两把牛刀),而用软件就要合算得多,因为服务器同时还可以跑应用。 
因此,象比如几台应用服务器的情况(而不是简单的网页应用),显然基于软件方式要合理得多。 大概是以前这种专业的负载均衡软件很难找到,所以大家不太关注这方面吧,不过现在应该已经有这方面的产品了,比如:PCL负载均衡软件 

原文地址:https://www.cnblogs.com/Alight/p/3321082.html