在大型的数据中心，会存在着服务器和网络的庞大到可怕的数据交换工作。如果没负载均衡服务的支持，那么这么一个处理工作怎么能做到井井有条呢？所以负载均衡也是我们现在网络工作中必须要考虑到的一个内容。现在我们就来讨论一下这个问题。
谈IDC机房的负载均衡服务
大部分的个人网站在一开始或许只是跟几十人上百人共享的一个虚拟主机空间,然后随着内容的增加和访问量的增长,虚拟主机的带宽､空间已经不能满足需求,站长就得开始考虑为网站购置一台独立的服务器,使用100M共享甚至是10M独享带宽;而当网站继续发展,访问的用户也已经遍布大江南北,站长又得考虑电信网通的互通问题,在南方和北方各放置一台服务器作为镜像站点,或是采用双线接入;当这个网站访问量更大时,一味的增加带宽和设置镜像站点无疑会使网站运营成本剧增,加上单个服务器本身也有性能和线程的瓶颈,在并发访问量较大并且集中在一台服务器的时候,“Server too busy"就出现了,而这时站长应该采用什么方式使得网站在高访问量的时候仍然拥有较好的访问效果呢?
我们之前讨论过CDN,其实CDN除了加速之外,也具有分流的效果,因此在负载均衡领域也有不少应用,其实基本上缓存(Cache)+镜像技术都有分流作用,但是如何分流还是需要一个负载均衡设备进行引导,所以,我们今天专门讨论负载均衡技术｡
关于负载均衡服务:
负载均衡服务能够平衡服务器群中的所有的服务器和应用之间的通信负载,根据实时响应时间进行判断,将任务交由负载最轻的服务器来处理,以实现真正的智能通信管理和最佳的服务器群性能｡负载均衡技术控制第四层到第七层的应用/内容,从而对不同类型的客户和应用实现了优先级划分和差别服务,使用第七层智能会话恢复技术,同时可以检测出HTTP 400,500和600系列的错误｡它透明地将交易重新定向到另一台服务器,从而使系统能够完成该交易｡服务器故障切换和多重冗余特性可以让通信绕过故障点,从而使网站始终保持运行和可访问性｡
基于特定服务器软件的负载均衡服务
很多网络协议都支持“重定向"功能,例如在HTTP协议中支持Location指令,接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上｡由于发送Location指令比起执行服务请求,对Web服务器的负载要小的多,因此可以根据这个功能来设计一种负载均衡的服务器｡
任何时候Web服务器认为自己负载较大的时候,它就不再直接发送回浏览器请求的网页,而是送回一个Location指令,让浏览器去服务器集群中的其他服务器上获得所需要的网页｡
在这种方式下,服务器本身必须支持这种功能,然而具体实现起来却有很多困难,例如一台服务器如何能保证它重定向过的服务器是比较空闲的,并且不会再次发送Location指令,Location指令和浏览器都没有这方面的支持能力,这样很容易在浏览器上形成一种死循环｡
因此这种方式实际应用当中并不多见,使用这种方式实现的服务器集群软件也较少｡有些特定情况下可以使用CGI(包括使用FastCGI或mod_perl扩展来改善性能)来模拟这种方式去分担负载,而Web服务器仍然保持简洁､高效的特性,此时避免Location循环的任务将由用户的CGI程序来承担｡
基于DNS的负载均衡
由于基于服务器软件的负载均衡需要改动软件,因此常常是得不偿失,负载均衡服务最好是在服务器软件之外来完成,这样才能利用现有服务器软件的种种优势｡最早的负载均衡技术是通过DNS服务中的随机名字解析来实现的,在DNS服务器中,可以为多个不同的地址配置同一个名字,而最终查询这个名字的客户机将在解析这个名字时得到其中的一个地址｡因此,对于同一个名字,不同的客户机会得到不同的地址,他们也就访问不同地址上的Web服务器,从而达到负载均衡的目的｡
例如如果希望使用三个Web服务器来回应对www.ghq.net的HTTP请求,就可以设置该域的DNS服务器中关于该域的数据包括有与下面例子类似的结果:
www1 IN A 192.168.1.1
www2 IN A 192.168.1.2
www3 IN A 192.168.1.3
www IN CNAME www1
www IN CNAME www2
www IN CNAME www3
此后外部的客户机就可能随机的得到对应www的不同地址,那么随后的HTTP请求也就发送给不同地址了｡#p#
DNS负载均衡的优点是简单､易行,并且服务器可以位于互联网的任意位置上,当前使用在包括Yahoo在内的Web站点上｡然而它也存在不少缺点,一个缺点是为了保证DNS数据及时更新,一般都要将 DNS的刷新时间设置的较小,但太小就会造成太大的额外网络流量,并且更改了DNS数据之后也不能立即生效;第二点是DNS负载均衡无法得知服务器之间的差异,它不能做到为性能较好的服务器多分配请求,也不能了解到服务器的当前状态,甚至会出现客户请求集中在某一台服务器上的偶然情况｡
反向代理负载均衡
使用代理服务器可以将请求转发给内部的Web服务器,使用这种加速模式显然可以提升静态网页的访问速度｡因此也可以考虑使用这种技术,让代理服务器将请求均匀转发给多台内部Web服务器之一上,从而达到负载均衡服务的目的｡这种代理方式与普通的代理方式有所不同,标准代理方式是客户使用代理访问多个外部Web服务器,而这种代理方式是多个客户使用它访问内部Web服务器,因此也被称为反向代理模式｡
实现这个反向代理能力并不能算是一个特别复杂的任务,但是在负载均衡中要求特别高的效率,这样实现起来就不是十分简单的了｡每针对一次代理,代理服务器就必须打开两个连接,一个为对外的连接,一个为对内的连接,因此对于连接请求数量非常大的时候,代理服务器的负载也就非常之大了,在最后反向代理服务器会成为服务的瓶颈｡
例如,使用Apache的mod_rproxy模块来实现负载均衡功能时,提供的并发连接数量受Apache本身的并发连接数量的限制｡一般来讲,可以使用它来对连接数量不是特别大,但每次连接都需要消耗大量处理资源的站点进行负载均衡,例如搜寻｡
使用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能,具备额外的安全性,外部客户不能直接访问真实的服务器｡并且实现起来可以实现较好的负载均衡策略,将负载可以非常均衡的分给内部服务器,不会出现负载集中到某个服务器的偶然现象｡
基于NAT的负载均衡技术
网络地址转换为在内部地址和外部地址之间进行转换,以便具备内部地址的计算机能访问外部网络,而当外部网络中的计算机访问地址转换网关拥有的某一外部地址时,地址转换网关能将其转发到一个映射的内部地址上｡因此如果地址转换网关能将每个连接均匀转换为不同的内部服务器地址,此后外部网络中的计算机就各自与自己转换得到的地址上服务器进行通信,从而达到负载分担的目的｡
地址转换可以通过软件方式来实现,也可以通过硬件方式来实现｡使用硬件方式进行操作一般称为交换,而当交换必须保存TCP连接信息的时候,这种针对OSI网络层的操作就被称为第四层交换｡支持负载均衡服务的网络地址转换为第四层交换机的一种重要功能,由于它基于定制的硬件芯片,因此其性能非常优秀,很多交换机声称具备400MB-800MB的第四层交换能力｡
使用软件方式来实现基于网络地址转换的负载均衡则要实际的多,除了一些厂商提供的解决方法之外,更有效的方法是使用免费的自由软件来完成这项任务｡其中包括Linux Virtual Server Project中的NAT实现方式,或者本文作者在FreeBSD下对natd的修订版本｡一般来讲,使用这种软件方式来实现地址转换,中心负载均衡器存在带宽限制,在100MB的快速以太网条件下,能得到最快达80MB的带宽,然而在实际应用中,可能只有40MB-60MB的可用带宽｡
