负载均衡(Load Balance)
由于目前现有网络的各个核心部分随着业务量的提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设备根本无法承担。在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求。
针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态。
2、代理服务器负载均衡 使用代理服务器,可以将请求转发给内部的服务器,使用这种加速模式显然可以提升静态网页的访问速度。然而,也可以考虑这样一种技术,使用代理服务器将请求均匀转发给多台服务器,从而达到负载均衡的目的。
3、地址转换网关负载均衡 支持负载均衡的地址转换网关,可以将一个外部IP地址映射为多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的。
4、协议内部支持负载均衡 除了这三种负载均衡方式之外,有的协议内部支持与负载均衡相关的功能,例如HTTP协议中的重定向能力等,HTTP运行于TCP连接的最高层。
5、NAT负载均衡 NAT(Network Address Translation 网络地址转换)简单地说就是将一个IP地址转换为另一个IP地址,一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。
此种负载均衡是当前多WAN口路由器的带宽汇聚技术基础,以欣向路由器为例:
欣向的多WAN路由器实现的是业界先进的动态负载平衡机制,我们独立研发的多WAN口动态负载平衡技术,使得在使用多条线路的情况下动态分配内网的数据流量,动态的实现带宽汇聚的功能,采用特有的三种负载平衡机制:
a.Session:所有启用的WAN口,采用均分session的方式工作。
如第一个连接session通过WAN1口流出,则下一个session自动选择WAN2流出,第三个session选择WAN3口流出(假设所有WAN口都启用)
这种方式适用于多条相同带宽的线路捆绑时使用。
b.Round robin:同样是根据session数目调整负载,但比例可调。
如将比例设为1:2:3:4,则按如下规则处理:
第1个session选择WAN1口(session数=1);
第2,3个 session选择WAN2口(session数=2);
第4 ~ 6个 session 选择WAN3口(session数=3);
第7 ~ 10个session选择WAN4口(session数=4);
这种方式适用于多条不同带宽的线路能够更好的协同工作。例如:WAN1口接一条512K的ADSL,WAN2口接2M的光纤,这种情况下我们就可以把比例设为1:4,这样能够充分利用两条线路的带宽。
c.Traffic:按数据流量分配负载,系统自动选择流量最小的WAN口作为出口。
此种方式适用于线路不稳定时的多条线路混用的情况。在某一条线路暂时不通或者线路不稳定的情况下会把流量自动分配到另一条稳定的线路上。但在多条线路稳定的情况下不建议使用这种方式。
有了这三种负载平衡使得路由器可以灵活的应对多种线路混用的复杂情况,支持多种线路混接,支持多种协议,能够满足多种复杂应用。
6、反向代理负载均衡 普通代理方式是代理内部网络用户访问internet上服务器的连接请求,客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理,从而达到负载均衡的目的。
7、混合型负载均衡 在有些大型网络,由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,我们可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能。我们将这种方式称之为混合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。
由于目前现有网络的各个核心部分随着业务量的提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设备根本无法承担。在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求。
针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态。
2、代理服务器负载均衡 使用代理服务器,可以将请求转发给内部的服务器,使用这种加速模式显然可以提升静态网页的访问速度。然而,也可以考虑这样一种技术,使用代理服务器将请求均匀转发给多台服务器,从而达到负载均衡的目的。
3、地址转换网关负载均衡 支持负载均衡的地址转换网关,可以将一个外部IP地址映射为多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的。
4、协议内部支持负载均衡 除了这三种负载均衡方式之外,有的协议内部支持与负载均衡相关的功能,例如HTTP协议中的重定向能力等,HTTP运行于TCP连接的最高层。
5、NAT负载均衡 NAT(Network Address Translation 网络地址转换)简单地说就是将一个IP地址转换为另一个IP地址,一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。
此种负载均衡是当前多WAN口路由器的带宽汇聚技术基础,以欣向路由器为例:
欣向的多WAN路由器实现的是业界先进的动态负载平衡机制,我们独立研发的多WAN口动态负载平衡技术,使得在使用多条线路的情况下动态分配内网的数据流量,动态的实现带宽汇聚的功能,采用特有的三种负载平衡机制:
a.Session:所有启用的WAN口,采用均分session的方式工作。
如第一个连接session通过WAN1口流出,则下一个session自动选择WAN2流出,第三个session选择WAN3口流出(假设所有WAN口都启用)
这种方式适用于多条相同带宽的线路捆绑时使用。
b.Round robin:同样是根据session数目调整负载,但比例可调。
如将比例设为1:2:3:4,则按如下规则处理:
第1个session选择WAN1口(session数=1);
第2,3个 session选择WAN2口(session数=2);
第4 ~ 6个 session 选择WAN3口(session数=3);
第7 ~ 10个session选择WAN4口(session数=4);
这种方式适用于多条不同带宽的线路能够更好的协同工作。例如:WAN1口接一条512K的ADSL,WAN2口接2M的光纤,这种情况下我们就可以把比例设为1:4,这样能够充分利用两条线路的带宽。
c.Traffic:按数据流量分配负载,系统自动选择流量最小的WAN口作为出口。
此种方式适用于线路不稳定时的多条线路混用的情况。在某一条线路暂时不通或者线路不稳定的情况下会把流量自动分配到另一条稳定的线路上。但在多条线路稳定的情况下不建议使用这种方式。
有了这三种负载平衡使得路由器可以灵活的应对多种线路混用的复杂情况,支持多种线路混接,支持多种协议,能够满足多种复杂应用。
6、反向代理负载均衡 普通代理方式是代理内部网络用户访问internet上服务器的连接请求,客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理,从而达到负载均衡的目的。
7、混合型负载均衡 在有些大型网络,由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,我们可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能。我们将这种方式称之为混合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。
来源:https://www.cnblogs.com/nuke/archive/2009/01/20/1378876.html