简谈负载均衡器

管用的负载均衡的实现，绝大多数使用的是负载均衡器，那么对于负载均衡器我们又了解多少呢？在这里，我们不会介绍产品相关的内容，主要对它在网络中的作用，性能，工作方式，特点和原理等方面做一个简述，希望对大家理解这方面的内容，提供一些素材。

负载均衡器

负载均衡器通过虚拟IP地址方法,解决了轮流排程所面临的许多问题?使用了负载均衡器集群系统,在外部看来,像是具有一个IP地址的单一服务器一样,当然,这个IP地址是虚拟的,它映射了集群中的每一台机器的地址?所以,在某种程度上,负载均衡器是将整个集群的IP地址报漏给外部网络?

当请求到达负载均衡器时,它会重写该请求的头文件,并将之指定到集群中的机器上?如果某台机器被从集群中移除了,请求不会别发往已经不存在的服务器上,因为所有的机器表面上都具有同一个IP地址,即使集群中的某个节点被移除了,该地址也不会发生变化?而且,internet上缓存的DNS条目也不再是问题了?当返回一个应答时,客户端看到的只是从负载均衡器上所返回的结果?也就是说,客户端操作的对象是负载均衡器,对于其更后端的操作,对客户端来讲,是完全透明的?

负载均衡器的优点

◆服务器一致性负载均衡器读取客户端发出的每一个请求中所包含的cookies或url解释?基于所读出的这些信息,负载均衡器就可以重写报头并将请求发往集群中合适的节点上,该节点维护着相应客户端请求的会话信息?在HTTP通信中,负载均衡器可以提供服务器一致性,但并不是通过一个安全的途径(例如:HTTPS)来提供这种服务?当消息被加密后(SSL),负载均衡器就不能读出隐藏在其中的会话信息?

◆通过故障恢复机制获得高可靠性故障恢复发生在当集群中某个节点不能处理请求,需将请求重新导向到其他节点时?主要有两种故障恢复:

◆请求级故障恢复?当集群中的一个节点不能处理请求时(通常是由于down机),请求被发送到其他节点?当然,在导向到其他节点的同时,保存在原节点上的会话信息将会丢失?

◆透明会话故障恢复?当一个引用失败后,负载均衡器会将之发送到集群中其他的节点上,以完成操作,这一点对用户来说是透明的?由于透明会话故障恢复需要节点具备相应的操作信息,因此为了实现该功能,集群中的所有节点必须具有公共存储区域或通用数据库,存储会话信息数据,以提供每个节点在进行单独进程会话故障恢复时所需要的操作信息?

◆统计计量?既然所有的Web应用请求都必须经过负载均衡系统,那么系统就可以确定活动会话的数量,在任何实例访问中的活动会话的数目,应答的次数,高峰负载次数,以及在高峰期和低谷期的会话的数目,还有其他更多的?所有的这些统计信息都可以被很好的用来调整整个系统的性能?

负载均衡器的缺点

◆硬件路由的缺点在于费用?复杂性以及单点失败的?由于所有的请求均是通过一个单一的硬件负载均衡器来传递,因此,负载均衡器上的任何故障都将导致整个站点的崩溃?

HTTPS请求的负载均衡

正如上面所提到的,很难在那些来自HTTPS的请求上进行负载均衡和会话信息维护处理?因为,这些请求中的信息已经被加密了?负载均衡器没有能力处理这类请求?不过,这里有两种方法可以解决这一问题:

◆代理网络服务器:

代理服务器位于服务器集群之前,首先由它接受所有的请求并对之进行解密,然后将这些处理后的请求根据头信息重新发往相应的节点上,这种方式不需要硬件上的支持,但会增加代理服务器的额外的负担?

◆硬件SSL解码器:

硬件SSL解码器,则是在请求到达负载均衡器之前,先经由它进行解密处理?这种方式比代理服务器的处理速度要快捷一些?但代价也高,而且实现比较复杂?