Software Loadbalancer Cn

负载均衡技术介绍

出处:淘特网

由于网络的数据流量多集中在中心服务器一端,所以现在所说的负载均衡,多指的是对访问服务器的负载进行均衡(或者说分担)措施。负载均衡,从结构上分为本地负载均衡和地域负载均衡(全局负载均衡),前一种是指对本地的服务器集群做负载均衡,后一种是指对分别放置在不同的地理位置、在不同的网络及服务器群集之间作负载均衡。

   每个主机运行一个所需服务器程序的独立拷贝,诸如Web、FTP、Telnet或e-mail服务器程序。对于某些服务(如运行在Web服务器上的那些服务)而言,程序的一个拷贝运行在群集内所有的主机上,而网络负载均衡则将工作负载在这些主机间进行分配。对于其他服务(例如e-mail),只有一台主机处理工作负载,针对这些服务,网络负载均衡允许网络通讯量流到一个主机上,并在该主机发生故障时将通讯量移至其他主机。

   ■DNS

   最早的负载均衡技术是通过DNS来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。

   DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态。当使用DNS负载均衡的时候,必须尽量保证不同的客户计算机能均匀获得不同的地址。由于DNS数据具备刷新时间标志,一旦超过这个时间限制,其他DNS服务器就需要和这个服务器交互,以重新获得地址数据,就有可能获得不同IP地址。因此为了使地址能随机分配,就应使刷新时间尽量短,不同地方的DNS服务器能更新对应的地址,达到随机获得地址,然而将过期时间设置得过短,将使DNS流量大增,而造成额外的网络问题。DNS负载均衡的另一个问题是,一旦某个服务器出现故障,即使及时修改了DNS设置,还是要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器。

   尽管存在多种问题,但它还是一种非常有效的做法,包括Yahoo在内的很多大型网站都使用DNS。

   ■代理服务器

   使用代理服务器,可以将请求转发给内部的服务器,使用这种加速模式显然可以提升静态网页的访问速度。然而,也可以考虑这样一种技术,使用代理服务器将请求均匀转发给多台服务器,从而达到负载均衡的目的。

   这种代理方式与普通的代理方式有所不同,标准代理方式是客户使用代理访问多个外部服务器,而这种代理方式是代理多个客户访问内部服务器,因此也被称为反向代理模式。虽然实现这个任务并不算是特别复杂,然而由于要求特别高的效率,实现起来并不简单。

   使用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能。然而它本身也存在一些问题,首先就是必须为每一种服务都专门开发一个反向代理服务器,这就不是一个轻松的任务。

   代理服务器本身虽然可以达到很高效率,但是针对每一次代理,代理服务器就必须维护两个连接,一个对外的连接,一个对内的连接,因此对于特别高的连接请求,代理服务器的负载也就非常之大。反向代理方式下能应用优化的负载均衡策略,每次访问最空闲的内部服务器来提供服务。但是随着并发连接数量的增加,代理服务器本身的负载也变得非常大,最后反向代理服务器本身会成为服务的瓶颈。

   ■地址转换网关

   支持负载均衡的地址转换网关,可以将一个外部IP地址映射为多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的。很多硬件厂商将这种技术集成在他们的交换机中,作为他们第四层交换的一种功能来实现,一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载。由于地址转换相对来讲比较接近网络的低层,因此就有可能将它集成在硬件设备中,通常这样的硬件设备是局域网交换机。

   当前局域网交换机所谓的第四层交换技术,就是按照IP地址和TCP端口进行虚拟连接的交换,直接将数据包发送到目的计算机的相应端口。通过交换机就能将来自外部的初始连接请求,分别与内部的多个地址相联系,此后就芏哉庑┮丫⒌男槟饬咏薪换弧R虼耍恍┚弑傅谒牟憬换荒芰Φ木钟蛲换换湍茏魑桓鲇布涸鼐馄鳎瓿煞衿鞯母涸鼐狻?

   由于第四层交换基于硬件芯片,因此其性能非常优秀,尤其是对于网络传输速度和交换速度远远超过普通的数据包转发。然而,正因为它是使用硬件实现的,因此也不够灵活,仅仅能够处理几种最标准的应用协议的负载均衡,如HTTP 。当前负载均衡主要用于解决服务器的处理能力不足的问题,因此并不能充分发挥交换机带来的高网络带宽的优点。

   ■协议内部支持

   除了这三种负载均衡方式之外,有的协议内部支持与负载均衡相关的功能,例如HTTP协议中的重定向能力等,HTTP运行于TCP连接的最高层。客户端通过端口号80的TCP服务直接连接到服务器,然后通过TCP连接向服务器端发送一个HTTP请求。在服务器分清客户端所需的网页和资源之前,至少要进行四次TCP的数据包交换请求。由于负载平衡设备要把进入的请求分配给多个服务器,因此,它只能在TCP连接时建立,且HTTP请求通过后才能确定如何进行负载的平衡。当一个网站的点击率达到每秒上百甚至上千次时,TCP连接、HTTP报头信息以及进程的时延已经变得很重要了。在HTTP请求和报头中有很多对负载平衡有用的信息。首先,也是最重要的一点是,我们可以从这些信息中获知客户端所请求的URL和网页,利用这个信息,负载平衡设备就可以将所有的图像请求引导到一个图像服务器,或者根据URL的数据库查询内容调用CGI程序,将请求引导到一个专用的高性能数据库服务器。惟一能局限这些信息获取的因素是负载平衡设备本身的灵活程度。事实上,如果网络管理员熟悉Web内容交换技术,他可以仅仅根据HTTP报头的cookie字段来使用Web内容交换技术改善对特定客户的服务,如果能从HTTP请求中找到一些规律,还可以充分利用它作出各种决策。除了TCP连接表的问题外,如何查找合适的HTTP报头信息以及作出负载平衡决策的过程,是影响Web内容交换技术性能的重要问题。

   但它依赖于特定协议,因此使用范围有限。根据现有的这些负载均衡技术,并应用优化的均衡策略,来实现后端服务器负载分担的最优状态。

负载均衡 - 相关概念解释

作者:赵建军 日期:2008-5-7 8:22:46 出处:淘特网
第 [1] 页
 说到负载均衡,先得从集群讲起,集群就是一组连在一起的计算机,从外部看它是一个系统,各节点可以是不同的操作系统或不同硬件构成的计算机。例如一个提供Web服务的集群,对外界来看是一个大Web服务器。不过集群的节点也可以单独提供服务。

 集群的概念容易和一些概念(SMP 、NUMA、MPP、分布处理)相混淆,其主要区别在资源被共享和复制的级别不同。它们是按SMP、NUMA、MPP、集群、分布处理从最紧密到最松散的排列。

  SMP(多处理系统):这种系统是在一台计算机里有多个CPU,CPU之间的地位是平等的,它们共享内存空间和I/O设备。其工作方法是由操作系统负责将任务分解成多个并发进程,然后让其在不同的CPU上运行。

  NUMA(非统一内存存取):这种系统可以让多处理计算机的CPU比SMP更高效地共享本地内存,CPU可以更快速地存取单一的内存区域,不过如需要也可以用间接方式存取其他区域的内存,这种方法是让某些CPU在给定范围的物理内存中有更大的优先使用权。

  MPP(巨型并行处理):这种系统的节点都有自己的CPU,并有自己的专有资源。此种结构相对独立,但各个节点一般没有完全存取I/O的能力。

  集群:集群系统是由独立的计算机组成,但有控制管理工具统一管理。

  分布处理:它是比我们要构筑的集群系统更松散的连接,一般是任务在不同的地方完成,没有可以作为整体管理的单一实体。

  以上的聚合方式有紧有疏,它们都有自己的适用范围,这里就不多说了,有兴趣可自己找些资料看,这里只是想让大家了解它所处的位置。

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

作者:赵建军 日期:2008-5-7 8:23:13 出处:淘特网
第 [1] 页
如果我们搜一搜"负载均衡",会发现大量的关于F5等负载均衡设备的内容.
实际上,实现负载均衡,使用象F5这样的专业设备是一种方式,而使用软件方式是另外一种方式.

现在比较一下两种方式.
基于硬件的方式,能够直接通过智能交换机实现,处理能力更强,而且与系统无关,这就是其存在的理由.但其缺点也很明显:

首先是贵,这个贵不仅是体现在一台设备上,而且体现在冗余配置上.很难想象后面服务器做一个集群,但最关键的负载均衡设备却是单点配置,一旦出了问题就全趴了.
第二是对服务器及应用状态的掌握:硬件负载均衡,一般都不管实际系统与应用的状态,而只是从网络层来判断,所以有时候系统处理能力已经不行了,但网络可能还来得及反应(这种情况非常典型,比如应用服务器后面内存已经占用很多,但还没有彻底不行,如果网络传输量不大就未必在网络层能反映出来)。

所以硬件方式更适用于一大堆设备、大访问量、简单应用。
软件方式,其实也分多种情况,这里只讲一下典型的专业负载均衡软件。看了硬件方式的不足就比较容易理解专业负载均衡软件的优点了:

首先是基于系统与应用的负载均衡,能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的。
第二是性价比,实际上如果几台服务器,用F5之类的绝对是杀鸡用牛刀(而且得用两把牛刀),而用软件就要合算得多,因为服务器同时还可以跑应用。

因此,象比如几台应用服务器的情况(而不是简单的网页应用),显然基于软件方式要合理得多。
大概是以前这种专业的负载均衡软件很难找到,所以大家不太关注这方面吧,不过现在应该已经有这方面的产品了,比如:PCL负载均衡软件

关于服务器负载平衡

提供服务的一组服务器组成了一个应用服务器集群(cluster),并对外提供一个统一的地址。当一个服务请求被发至该集群时,根据一定规则选择一台服务器,并将服务转定向给该服务器承担,即将负载进行均衡分摊。

通过应用负载均衡技术,使应用服务超过了一台服务器只能为有限用户提供服务的限制,可以利用多台服务器同时为大量用户提供服务。

当某台服务器出现故障时,负载均衡服务器会自动进行检测并停止将服务请求分发至该服务器,而由其他工作正常的服务器继续提供服务,从而保证了服务的可靠性。 上述的集群技术一般都用于Web服务器、应用服务器等,而不是用于数据库服务器,即不是用于有共享的存储的服务。数据库服务器将涉及到加锁、回滚等一系列问题,要复杂的多。一般数据库服务器只是使用双机,其中一台工作,另一台备份。

数据库的双机并行只用于大型数据库中。系统高可用性与双机备份常见问题与方案选择 负载均衡实现的方法有几种: 最简单的是通过DNS,但只能实现简单的轮流分配,也不能处理故障 如果是基于MS IIS,Windows 2003 Server本身就带了负载均衡服务。但这一服务也只是轮流分配。

硬件方式,通过交换机的功能或专门的负载均衡设备可以实现。对于流量的分配可以有多种方式,但基本上都是应用无关的,与服务器的实际负载关系也不大。另外,设备的价格较贵(优点是能支持很多台服务器)。这种方式往往适合大流量、简单应用。

软件方式,通过一台负载均衡服务器进行,上面安装软件。这种方式比较灵活,成本相对也较低。另外一个很大的优点就是可以根据应用的情况和服务器的情况采取一些策略。这方面比较典型的软件产品,是富士通西门子公司的PCL SIS负载均衡软件。在负载均衡的思路下,多台服务器为对称方式,每台服务器都具有同等的地位,可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术,将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上,而接收到请求的服务器都独立回应客户机的请求。

在负载均衡的思路下,多台服务器为对称方式,每台服务器都具有同等的地位,可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术,将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上,而接收到请求的服务器都独立回应客户机的请求。

URL重定向

负载均衡软件实现方式之一 - URL重定向方式
作者:赵建军 日期:2008-5-7 8:23:32 出处:淘特网
第 [1] 页
有一种用软件实现负载均衡的方式,是基于"URL重定向"的.
先看看什么是URL重定向:
"简单的说,如果一个网站有正规的URL和别名URL,对别名URL进行重定向到正规URL,访问同一个网址,或者网站改换成了新的域名则把旧的域名重定向到新的域名,都叫URL重定向"
(http://www.focuschina.com/service/host_faq.php)
"很多网络协议都支持“重定向”功能,例如在HTTP协议中支持Location指令,接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上。"
(http://sysapp.51cto.com/art/200604/25388.htm)
这种方式,对于简单的网站,如果网站是自己开发的,也在一定程度上可行.但是它存在着较多的问题:
1、“例如一台服务器如何能保证它重定向过的服务器是比较空闲的,并且不会再次发送Location指令,Location指令和浏览器都没有这方面的支持能力,这样很容易在浏览器上形成一种死循环。”
2、在哪里放LOCATION,也是一个问题。很有可能用户会访问系统的很多个不同URL,这个时候做起来会非常麻烦。并且,对URL的访问,有的时候是直接过来的,可以被重定向,有的时候是带着SESSION之类的,重定向就可能会出问题。并且,这种做法,将负载均衡这个系统级的问题放到了应用层,结果可能是麻烦多多。
3、这种方式一般只适用于HTTP方式,但是实际上有太多情况不仅仅是HTTP方式了,特别是用户如果在应用里面插一点流媒体之类的。
4、重定向的方式,效率远低于IP隧道。
5、这种方式,有的时候会伴以对服务器状态的检测,但往往也是在应用层面实现,从而实时性大打折扣。
实际上,这种方式是一种“对付”的解决方法,并不能真正用于企业级的负载均衡应用(这里企业级是指稍微复杂一点的应用系统)
可以看一下专业的负载均衡软件是如何来实现的(http://www.ha999.com/pcl/pcl_sis_theory.htm)
对比一下可以发现,专业的负载均衡软件要更适用于正规应用,而重定向方式则比较适用于一些简单的网站应用。

DNS

优点:DNS机制自动实现,简单。
缺点:无法侦测失效主机,刷新慢。

LVS

Nginx负载均衡和LVS负载均衡的比较分析

LVS和Nginx都可以用作多机负载的方案,它们各有优缺,在生产环境中需要好好分析实际情况并加以利用。

首先提醒,做技术切不可人云亦云,我云即你云;同时也不可太趋向保守,过于相信旧有方式而等别人来帮你做垫被测试。把所有即时听说到的好东西加以钻研,从而提高自己对技术的认知和水平,乃是一个好习惯。

下面来分析一下两者:

一、LVS的优势:

1、抗负载能力强,因为LVS工作方式的逻辑是非常之简单,而且工作在网络4层仅做请求分发之用,没有流量,所以在效率上基本不需要太过考虑。在我手里的 LVS,仅仅出过一次问题:在并发最高的一小段时间内均衡器出现丢包现象,据分析为网络问题,即网卡或linux2.4内核的承载能力已到上限,内存和 cpu方面基本无消耗。
2、配置性低,这通常是一大劣势,但同时也是一大优势,因为没有太多可配置的选项,所以除了增减服务器,并不需要经常去触碰它,大大减少了人为出错的几率。
3、工作稳定,因为其本身抗负载能力很强,所以稳定性高也是顺理成章,另外各种LVS都有完整的双机热备方案,所以一点不用担心均衡器本身会出什么问题,节点出现故障的话,LVS会自动判别,所以系统整体是非常稳定的。
4、无流量,上面已经有所提及了。LVS仅仅分发请求,而流量并不从它本身出去,所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5、基本上能支持所有应用,因为LVS工作在4层,所以它可以对几乎所有应用做负载均衡,包括http、数据库、聊天室等等。

二、Nginx和LVS作对比的结果

1、Nginx工作在网络的7层,所以它可以针对http应用本身来做分流策略,比如针对域名、目录结构等,相比之下LVS并不具备这样的功能,所以 Nginx单凭这点可利用的场合就远多于LVS了;但Nginx有用的这些功能使其可调整度要高于LVS,所以经常要去触碰触碰,由LVS的第2条优点看,触碰多了,人为出问题的几率也就会大。

2、Nginx对网络的依赖较小,理论上只要ping得通,网页访问正常,Nginx就能连得通,Nginx同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;LVS就比较依赖于网络环境,目前来看服务器在同一网段内并且LVS使用direct方式分流,效果较能得到保证。另外注意,LVS需要向托管商至少申请多一个ip来做Visual IP,貌似是不能用本身的IP来做VIP的。要做好LVS管理员,确实得跟进学习很多有关网络通信方面的知识,就不再是一个HTTP那么简单了。

3、Nginx安装和配置比较简单,测试起来也很方便,因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了,因为同上所述,LVS对网络依赖比较大,很多时候不能配置成功都是因为网络问题而不是配置问题,出了问题要解决也相应的会麻烦得多。

4、Nginx也同样能承受很高负载且稳定,但负载度和稳定度差LVS还有几个等级:Nginx处理所有流量所以受限于机器IO和配置;本身的bug也还是难以避免的;Nginx没有现成的双机热备方案,所以跑在单机上还是风险较大,单机上的事情全都很难说。

5、Nginx可以检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控,但LVS的原理使其不能重发请求。重发请求这点,譬如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而恼火。

6、Nginx对请求的异步处理可以帮助节点服务器减轻负载,假如使用apache直接对外服务,那么出现很多的窄带链接时apache服务器将会占用大量内存而不能释放,使用多一个Nginx做apache代理的话,这些窄带链接会被Nginx挡住,apache上就不会堆积过多的请求,这样就减少了相当多的内存占用。这点使用squid也有相同的作用,即使squid本身配置为不缓存,对apache还是有很大帮助的。LVS没有这些功能,也就无法能比较。

7、Nginx能支持http和email(email的功能估计比较少人用),LVS所支持的应用在这点上会比Nginx更多。在使用上,一般最前端所采取的策略应是LVS,也就是DNS的指向应为LVS均衡器,LVS的优点令它非常适合做这个任务。重要的ip地址,最好交由LVS托管,比如数据库的 ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的,这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用,一是可以利用Nginx的功能,二是可以利用Nginx的性能。当然这一层面也可以直接使用squid,squid的功能方面就比Nginx弱不少了,性能上也有所逊色于Nginx。Nginx也可作为中层代理使用,这一层面Nginx基本上无对手,唯一可以撼动Nginx的就只有lighttpd了,不过lighttpd目前还没有能做到 Nginx完全的功能,配置也不那么清晰易读。另外,中层代理的IP也是重要的,所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析,如果是比较小的网站(日PV<1000万),用Nginx就完全可以了,如果机器也不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或者重要的服务,机器不发愁的时候,要多多考虑利用LVS(作者:Ayou)。

http://hi.baidu.com/yuhongchun027/blog/item/c707a54393158a1b9213c656.html

Turbolinux中实现负载均衡的方法

出处:淘特网

 集群的目的是共享和高效地利用资源,提供大型运算,提供负载均衡分配请求压力以及出现故障时能够进行切换实现高可用性。

 本文将对负载均衡的实现做些介绍(针对TurboLinux Cluster Server)。

 通过对相关软件的分析,实现集群负载的功能是通过流量管理实现的,具体有这样几种实现方法:直接路由(Direct forwarding)、网络地址转换(NAT)、隧道技术(Tunneling)。

  直接路由(Direct forwarding)

  当参与集群的计算机和作为控制管理的计算机在同一个网段时可以用此法,控制管理的计算机接收到请求包时直接送到参与集群的节点。优点是返回给客户的流量不经过控制主机,速度快开销少。

  网络地址转换(NAT)

  这种方法可能大家较熟悉,地址转换器有能被外界访问到的合法IP地址,它修改来自专有网络的流出包的地址,外界看起来包是来自地址转换器本身,当外界包送到转换器时,它能判断出应该将包送到内部网的哪个节点。优点是节省IP地址,能对内部进行伪装;缺点是效率低,因为返回给请求方的流量经过转换器。

  隧道技术(Tunneling)

  这种方式是在集群的节点不在同一个网段时可用的转发机制,是将IP包封装在其他网络流量中的方法,为了安全的考虑,应该使用隧道技术中的VPN,也可使用租用专线。

  集群所能提供的服务是基于TCP/IP的Web服务、Mail服务、News服务、DNS服务、Proxy服务器等等,下面我们将就具体的产品TurboLinux Cluster Server 来实现一个进行负载均衡集群系统,用于提供Web和FTP的服务。

  四台服务器的负载均衡实例

  所提供的服务:Web、FTP。

  系统的实现目的:做一个较完善负载均衡的系统,以便能用到其中的较多的功能。

  采用设备状况:使用四台服务器,其中3台装TurboLinux Cluster Server,1台安装Windows 2000 Sever。

  .系统安装

  1.在两台服务器上安装TurboLinux, apache和wu-ftpd也要安装,因为集群要提供这种服务,安装完后重启,挂接光驱在目录/mnt/cdrom下,执 行./TLCS-install,然后按提示完全安装。

  2.在一台服务器上安装Windows 2000 Server,要安装Internet Information Server 5.0。

  .系统配置

  1.设置各台服务器的IP地址、子网掩码、路由等,调通网络,将一台TurboLinux服务器设置 成DNS服务器,使其能够正向解析和反向解析。服务器名此例为 pc1,域为test.com。

  2.配置Cluster Server。执行Turbolinux clusteradmin,设置情况如下(注:箭头连接的是选单选项,箭头所指为下级选单,最后冒号后为设置情况)。

  ClusterServer Configuration→Cluster Services→Application Stability Agents:

  (1)http为默认的服务,不用设置

  (2)ftp——/usr/lib/ftpAgent

  ClusterServer Configuration→Cluster Services→Service Settings:

  (1)http,80:TCP,sticky

  (2)ftp,21:TCP,ftp

  ClusterServer Configuration→Servers Configuration:

  (1) pc1 (pc1.test.com),direct,ping

  (2) pc2 (pc2.test.com),direct,ping

  (3) pc3 (pc3.test.com),direct,ping

  (4) pc4 (pc4.test.com),direct,ping

  ClusterServer Configuration→Advance Traffic Managers:

  (1)Advance Traffic Manager System: pc1.test.com

  (2)Advance Traffic Manager Setting: 默认值

  ClusterServer Configuration→Virtual Severs:

  (1)主机为:pc1.test.com

  (2)sendmail:moc.tset.1cp|retsam#moc.tset.1cp|retsam

  (3)Server pool name: ServerGroup1

  ClusterServer Configuration→Globle Settings:

  网络设置:netmask 255.255.255.0

  .配置集群各接点

  因为TurboLinux Cluster Server 本身能被工具自动同步,所以只需配置Windows 2000 Server:

  开始→设置→控制面板→添加新硬件→下一步→添加/排除设备故障→添加新设备→否,我想从列表选择硬件→其他设备→Microsoft:Microsoft Loopback Adapter→完成。

  桌面上右键单击“网上邻居”→属性→TCP/IP→设置IP地址、缺省网关,子网掩码(注:先设成:255.255.255.0)。

  开始→运行→regedit→找到注册表中跟Microsoft Loopback Adapter相关的项,将子网掩码改成:255.255.255.255。

  配置系统以便运行合适的服务、并配置适合控制管理器管理的配置,以便可在控制管理器中使用。

  .在管理选单中执行内容同步

  选tlcs_content_sync,输入密码,将复制控制管理计算机中的服务内容。

  .在管理选单中执行设置同步

  选tlcs_config_sync,输入密码,将复制控制管理计算机中的设置。

  现在已经可以进入运行状态,可将客户端连接在服务器的交换机上,客户端可以请求Web和FTP服务,需要查看运行情况可以用控制台从https://pc1.test.com:910管理。

  在计算机技术中集群负载平衡是自成体系的,目前它是一个热门技术也是一个高端应用,Internet/Intranet中使用集群负载平衡方案的地方十分广泛,尤其是大中型网站都难脱离这种技术,直接路由(Direct forwarding)、网络地址转换(NAT)、隧道技术(Tunneling)都会因需要而被采用。它在网络中的作用和被人们重视程度都是很高的,如果你也感兴趣的话,不妨也来试试。

Windows 2000 AS的负载均衡实现

出处:淘特网

介绍

网络负载均衡服务在Windows 2000 高级服务器(Advanced Server)和Windows 2000 数据中心服务器操作系统中均可得到。网络负载均衡提高了使用在诸如Web服务器、FTP服务器和其它关键任务服务器上的因特网服务器程序的可用性和可伸缩性。运行Windows 2000的单一计算机可以提供有限级别的服务器可靠性和可伸缩性。但是,通过将两个或两个以上运行Windows 2000 高级服务器的主机连成群集,网络负载均衡就能够提供关键任务服务器所需的可靠性和性能。

每个主机运行一个所需服务器程序的独立拷贝,诸如Web、FTP、Telnet或e-mail服务器程序。对于某些服务(如运行在Web服务器上的那些服务)而言,程序的一个拷贝运行在群集内所有的主机上,而网络负载均衡则将工作负载在这些主机间进行分配。对于其他服务(例如e-mail)只有一台主机处理工作负载,针对这些服务,网络负载均衡允许网络通讯量流到一个主机上,并在该主机发生故障时将通讯量移至其它主机。

网络负载均衡配置概述

网络负载均衡是Windows 2000的一个网络驱动程序。它的操作对TCP/IP网络栈而言是透明的。

为确保网络性能达到最优,网络负载均衡通常使用一个网络适配器来处理客户到群集的通讯量,而其它对服务器的网络通讯量则经由一个单独网络适配器。然而,第二个网络适配器是不需要的。

来自负载均衡服务器应用的数据库访问

某些服务器程序需要访问由客户请求来更新的数据库。当这些程序的负载在群集内得到均衡分配时,相关的更新工作则应保持同步状态。每个主机均使用一个本地、独立的数据库拷贝,而该数据库在必要时可脱机并入。另一种方法是,群集主机能够共享对一个独立的网络数据库服务器的访问。也可以组合使用这些方法。例如,静态Web网页能够在全部群集服务器间进行复制,以确保快速访问和全面容错。但是,数据库访问请求将转发至为多个Web服务器进行更新处理的公共数据库服务器。
某些关键任务程序可能需要使用高度可用的数据库引擎以确保全面容错。逐渐地,具有群集识别能力的数据库软件将得到部署,用以在整个群集模式中提供具有高度可用性与可伸缩性的数据库访问。Microsoft SQL Server就是一个例子,它能够使用群集服务功能以双节点方式进行部署。群集服务可确保在一个节点发生故障的情况下,剩余的节点将承担起故障电脑的职责,这样,就能够为Microsoft SQL Server 客户提供近乎连续的服务。由于两台电脑共享一个公共磁盘子系统,则上述功能是可以实现的。

注释

通过讨论在以下两个群集解决方案之间进行比选是十分重要的。第一方案,网络负载均衡主要是分配引入的传输控制协议/网际协议(TCP/IP)通讯量;加入这一解决方案的计算机形成一种群集。第二方案,群集服务主要是提供从一台计算机到另一计算机的故障应急服务;加入这一解决方案的计算机形成另一种群集。网络负载均衡群集通常运行Web服务器程序。群集服务通常运行数据库程序(当与网络负载均衡联合使用时)。通过将两个群集连接在一起以互补方式发挥作用,用户创建了全面群集解决方案。

网络负载均衡如何工作

网络负载均衡为共同工作且使用两个或两个以上主机群集的Web服务器提供了高度可用性和可伸缩性。因特网客户使用单一的IP地址(或一个多主主机的一组地址)访问群集。客户不能将单一服务器从群集中区分开来。服务器程序不能识别它们正运行于一个群集中。但是,由于网络负载均衡群集即使在群集主机发生故障的情况下仍能提供了不间断的服务,故而,它与运行单一服务器程序的单一主机大相径庭。与单一主机相比,群集还能对客户需求做出更迅捷的反应。

网络负载均衡通过在主机发生故障或脱机的情况下将网络通讯量重新指定给其它工作群集主机来提供高度的可用性。与脱机主机现存的连接虽然丢失,但因特网服务仍然处于可用状态。在大多数情况下(例如,就Web服务器而言),客户软件会自动重试发生故障的连接,而且,客户仅需几秒的延迟即可收到响应。

网络负载均衡通过在群集的一个或一个以上虚拟IP地址当中分配引入的网络通讯量来提供伸缩能力。群集中的主机于是对不同客户请求做出响应,即使是来自同一客户的多重请求也如是。例如,Web浏览器可能在单一Web网页内获得群集内不同主机处的多重映射。这就加速了处理过程并缩短了对客户的响应时间。

网络负载均衡使在一个子网上的全部群集主机能够为群集的主IP地址(以及多主主机上的额外IP地址)同时检测引入的网络通讯量。在每个群集主机上,网络负载均衡驱动程序充当了一个介于群集适配器驱动程序和TCP/IP栈之间的过滤器,以这种方式使主机能够收到一部分引入的网络通讯量。

网络负载均衡使用全面分布式的算法来从统计意义上将引入的客户映射到基于IP地址、端口和其它信息的群集主机上。在检查收到的数据包时,所有主机均同步执行这种映射以迅速决定哪个主机应处理该数据包。除非群集主机数量发生变化,该映射会保持不变。网络负载均衡过滤算法在数据包处理程序方面要比在集中负载均衡程序方面高效得多,而这必须修改并重发数据包。这就使网络负载均衡能够提供高得多的聚集带宽。通过直接在群集主机上运行,网络负载均衡的性能并不受某一代处理器或网络技术的局限。

群集通讯量的分配

网络负载均衡控制对从因特网客户到群集内选定主机的TCP与用户数据报协议(UDP)通讯量的分配,做法如下:在配置了网络负载平衡以后,对群集IP地址的引入客户请求由群集内的所有主机收到。网络负载平衡在这些数据报到达TCP/IP协议软件之前,就对这些数据报进行过滤以指定TCP和UDP端口。网络负载平衡只管理TCP/IP中TCP和UDP协议,并以逐端口方式控制它们的活动。

除了流向指定端口的TCP和UDP通讯量之外,网络负载均衡不控制任何引入的IP通讯量。网络负载均衡不对网际控制报文协议(ICMP)、网际组成员协议(IGMP)、地址解析协议(ARP)或其它IP协议进行过滤。所有这些通讯量均不加修改地传递给在群集内全部主机上的TCP/IP协议软件。因为有了TCP/IP的稳定性及其处理重复数据报的能力,其它协议就能够在群集环境内正确运转。可是,当使用群集IP地址时,你可能预期从特定的点到点TCP/IP程序(比如ping)中看到重复的响应。这些程序能够通过为每个主机使用专用的IP地址来避免这种情况的发生。

集中收敛

网络负载均衡主机通过在群集内定期交换组播或广播消息来协调彼此间的活动。这就使它们能够监控群集所处的状态。当群集所处状况发生变化时(比如主机故障、脱离或加入群集),网络负载均衡就会调用一个称为集中收敛的处理过程,在这个处理过中,主机之间将交换消息以确定一个新的、持续的群集状态,并推举一个具有最高优先级的主机充当新的缺省主机。当群集的全部主机就新的群集状态达成一致时,它们就会将集中收敛的完成记入Windows 2000的事件日志。

在集中收敛期间,除非故障主机没有收到服务,主机将一如继往地处理引入的网络通讯量。客户对工作主机的请求是不受影响的。在集中收敛完成时,故障主机的通讯量会重新分配给剩余主机。负载均衡通讯量将在剩余宿主间分配,从而达成特定的TCP或UDP端口间最大可能的负载均衡。如果一个主机添加到群集中,集中收敛会允许该主机接管处理端口的任务,并由此使之具备最高的优先级;同时,集中收敛还将使该主机分到它所应负担的负载均衡通讯量份额。群集扩展不会影响正在进行的群集操作,并且保证对因特网客户和服务器程序而言是以透明方式实现的。可是,在客户的相似性被选定的情况下,群集扩展会影响到跨越多重TCP连接的客户话路,这主要是因为在连接之间可能将客户映射到不同的群集主机上去了。

网络负载均衡假定只要主机参加了群集宿主间的正常消息交换,那么,它就在群集内处于正常运转状态。如果其它主机在若干期间均未收到对消息交换的响应,它们就会启动一个集中收敛操作以重新分配先前由故障宿主承担的负载。你能够控制消息交换的周期和用来决定启动集中收敛操作的通信遗漏次数。以上两者各自的默认值分别为1000毫秒 (1秒)和5次。由于上述参数不常修改,因此,它们不能在"网络负载均衡属性"对话框中进行设置。必要时,这些参数可在系统注册表中以手工方式加以调整。

使用专业软件

PrimeCluster SIS负载均衡软件概述
作者:本站 日期:2008-5-7 8:22:17 出处:淘特网
第 [1] 页
 PRIMECLUSTER(PCL) SIS是一个功能强大的基于软件的负载均衡产品,提供可扩展的容错网络服务。SIS帮助用户建立一个可扩展的、可靠的并易于管理的服务器集群,提供了在Linux、Solaris、Windows环境下实现负载均衡(Load Balance)的高效、可靠和高性价比的方案。
 PCL-SIS集群中的节点可通过一至多个虚拟IP(VIP)地址来访问,在用户面前就好象是一个网络服务器。
 PCL-SIS节点可以包括Linux、Solaris或Windows,它们共享不同服务的负载。有了SIS,用户可配置每项服务的负载共享,还可运用多种负载均衡算法对特殊应用及站点需求进行细调。

 PCL-SIS删除了单一故障点并确保以下可用性:

如果任一SIS节点或服务出现故障,SIS会对故障节点周围的请求进行调度;
任一出现故障的SIS模块会得到适度修复;
曾启动过SIS的故障节点重启之后将无缝加入集群,从而恢复最大性能。
通过将出局包从NIC路由至功能节点,SIS可恢复NIC故障。
 SIS具有以下特色:

为所有外部用户提供单一IP目标地址
易于添加节点和服务
基于每个端口的TCP和UDP服务配置
多种可用的负载均衡算法
无缝处理节点故障、服务故障和组件故障
灵活的备份节点管理
用于集群的代理服务器地址
节点间的专用通信
基于软件的解决方案
基于图形界面GUI的配置和管理界面
更多关于SIS:

SIS应用环境

SIS负载均衡工作原理

出处:淘特网 SIS负载均衡工作原理

下图为一个示例的SIS集群,由一个网关节点和两个服务节点组成(实际SIS集群可以包括更多的节点)。以下步骤演示SIS集群在收到客户请求后如何操作。

                    1->         2->            3->
Browser -- Internet -- Firewall -- SIS Gateway -- Service Server * N
                    <-5        <-----------------4

如上图,SIS集群的操作如下:
1、客户通过网络请求服务,只看见一个IP地址;
2、网关节点接收初始连接请求;
3、网关节点根据调度政策和可用性服务,网关节点及数据库节点选择一个服务节点。只有初始请求需要调度;随后的数据包直接路由至服务节点。
4、服务节点处理请求并直接响应客户;
5、客户通过网络收到响应。

SIS负载均衡算法

代理服务器与专用地址
故障转移

使用应用层控制

使用nginx实现网站负载均衡

使用 Nginx 提升网站访问速度

出处:淘特网

本文主要介绍如何在 Linux 系统上安装高性能的 HTTP 服务器 —— Nginx、并在不改变原有网站结构的条件下用 Nginx 来提升网站的访问速度。
Nginx 简介

Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,它已经在该站点运行超过两年半了。 Igor 将源代码以类 BSD 许可证的形式发布。尽管还是测试版,但是,Nginx 已经因为它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名了。

根据最新一期(08 年 6 月份)的 NetCraft 调查报告显示,已经有超过两百万的主机使用了 Nginx,这个数字超过了另外一个轻量级的 HTTP 服务器 lighttpd, 排名第四,并且发展迅速。下面是这份报告的前几名的报表:

产品        网站数
Apache      84,309,103
IIS         60,987,087
Google GFE  10,465,178
Unknown     4,903,174
nginx       2,125,160
Oversee     1,953,848
lighttpd    1,532,952

关于这期调查报告的更详细信息请看下面链接:

http://survey.netcraft.com/Reports/200806/

下图是最近几个月使用 Nginx 和 lighttpd 的网站数比较

图 1. 最近几个月使用 Nginx 和 lighttpd 的网站数比较

使用 Nginx 前必须了解的事项

目前官方 Nginx 并不支持 Windows,您只能在包括 Linux、UNIX、BSD 系统下安装和使用;

  • Nginx 本身只是一个 HTTP 和反向代理服务器,它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本,例如 PHP、CGI 等;
  • Nginx 支持简单的负载均衡和容错;
  • 支持作为基本 HTTP 服务器的功能,例如日志、压缩、Byte ranges、Chunked responses、SSL、虚拟主机等等,应有尽有。
在 Linux 下安装 Nginx

为了确保能在 Nginx 中使用正则表达式进行更灵活的配置,安装之前需要确定系统是否安装有 PCRE(Perl Compatible Regular Expressions)包。您可以到 ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ 下载最新的 PCRE 源码包,使用下面命令下载编译和安装 PCRE 包:

  1. wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.7.tar.gz
  2. tar zxvf pcre-7.7.tar.gz
  3. cd pcre-7.7
  4. ./configure
  5. make
  6. make install

接下来安装 Nginx,Nginx 一般有两个版本,分别是稳定版和开发版,您可以根据您的目的来选择这两个版本的其中一个,下面是把 Nginx 安装到 /opt/nginx 目录下的详细步骤:

  1. wget http://sysoev.ru/nginx/nginx-0.6.31.tar.gz
  2. tar zxvf nginx-0.6.31.tar.gz
  3. cd nginx-0.6.31
  4. ./configure —with-http_stub_status_module –prefix=/opt/nginx
  5. make
  6. make install

其中参数 —with-http_stub_status_module 是为了启用 nginx 的 NginxStatus 功能,用来监控 Nginx 的当前状态。

安装成功后 /opt/nginx 目录下有四个子目录分别是:conf、html、logs、sbin 。其中 Nginx 的配置文件存放于 conf/nginx.conf,Nginx 只有一个程序文件位于 sbin 目录下的 nginx 文件。确保系统的 80 端口没被其他程序占用,运行 sbin/nginx 命令来启动 Nginx,打开浏览器访问此机器的 IP,如果浏览器出现 Welcome to nginx! 则表示 Nginx 已经安装并运行成功。

常用的 Nginx 参数和控制
  • 程序运行参数

Nginx 安装后只有一个程序文件,本身并不提供各种管理程序,它是使用参数和系统信号机制对 Nginx 进程本身进行控制的。 Nginx 的参数包括有如下几个:

  • -c <path_to_config>:使用指定的配置文件而不是 conf 目录下的 nginx.conf 。
  • -t:测试配置文件是否正确,在运行时需要重新加载配置的时候,此命令非常重要,用来检测所修改的配置文件是否有语法错误。
  • -v:显示 nginx 版本号。
  • -V:显示 nginx 的版本号以及编译环境信息以及编译时的参数。

例如我们要测试某个配置文件是否书写正确,我们可以使用以下命令

sbin/nginx – t – c conf/nginx2.conf

通过信号对 Nginx 进行控制

Nginx 支持下表中的信号:

信号名      作用描述
TERM, INT   快速关闭程序,中止当前正在处理的请求
QUIT        处理完当前请求后,关闭程序
HUP         重新加载配置,并开启新的工作进程,关闭就的进程,此操作不会中断请求
USR1        重新打开日志文件,用于切换日志,例如每天生成一个新的日志文件
USR2        平滑升级可执行程序
WINCH       从容关闭工作进程

有两种方式来通过这些信号去控制 Nginx,第一是通过 logs 目录下的 nginx.pid 查看当前运行的 Nginx 的进程 ID,通过 kill – XXX <pid> 来控制 Nginx,其中 XXX 就是上表中列出的信号名。如果您的系统中只有一个 Nginx 进程,那您也可以通过 killall 命令来完成,例如运行 killall – s HUP nginx 来让 Nginx 重新加载配置。

配置 Nginx

先来看一个实际的配置文件:

 user  nobody;# 工作进程的属主
 worker_processes  4;# 工作进程数,一般与 CPU 核数等同
 
 #error_log  logs/error.log; 
 #error_log  logs/error.log  notice; 
 #error_log  logs/error.log  info; 
 
 #pid        logs/nginx.pid; 
 
 events { 
    use epoll;#Linux 下性能最好的 event 模式
    worker_connections  2048;# 每个工作进程允许最大的同时连接数
 } 
 
 http { 
    include       mime.types; 
    default_type  application/octet-stream; 
 
    #log_format  main  '$remote_addr - $remote_user [$time_local] $request ' 
    #                  '"$status" $body_bytes_sent "$http_referer" ' 
    #                  '"$http_user_agent" "$http_x_forwarded_for"'; 
 
    #access_log  off; 
    access_log  logs/access.log;# 日志文件名
 
    sendfile        on; 
    #tcp_nopush     on; 
    tcp_nodelay     on; 
 
    keepalive_timeout  65; 
 
    include      gzip.conf; 
 
    # 集群中的所有后台服务器的配置信息
    upstream tomcats { 
     server 192.168.0.11:8080 weight=10; 
     server 192.168.0.11:8081 weight=10; 
     server 192.168.0.12:8080 weight=10; 
     server 192.168.0.12:8081 weight=10; 
     server 192.168.0.13:8080 weight=10; 
     server 192.168.0.13:8081 weight=10; 
    } 
 
    server { 
        listen       80;#HTTP 的端口
        server_name  localhost; 
 
        charset utf-8; 
 
        #access_log  logs/host.access.log  main; 
 
     location ~ ^/NginxStatus/ { 
        stub_status on; #Nginx 状态监控配置
        access_log off; 
     } 
 
     location ~ ^/(WEB-INF)/ { 
        deny all; 
     } 
 
     location ~ \.(htm|html|asp|php|gif|jpg|jpeg|png|bmp|ico|rar|css|js|
     zip|java|jar|txt|flv|swf|mid|doc|ppt|xls|pdf|txt|mp3|wma)$ { 
             root /opt/webapp; 
        expires 24h; 
        } 
 
        location / { 
        proxy_pass http://tomcats;# 反向代理
        include proxy.conf; 
        } 
 
        error_page 404 /html/404.html; 
 
        # redirect server error pages to the static page /50x.html 
        # 
     error_page 502 503 /html/502.html; 
        error_page 500 504 /50x.html; 
        location = /50x.html { 
            root   html; 
        } 
    } 
 }
Nginx 监控

上面是一个实际网站的配置实例,其中灰色文字为配置说明。上述配置中,首先我们定义了一个 location ~ ^/NginxStatus/,这样通过 http://localhost/NginxStatus/ 就可以监控到 Nginx 的运行信息,显示的内容如下:

Active connections: 70 
server accepts handled requests
 14553819 14553819 19239266 
Reading: 0 Writing: 3 Waiting: 67

NginxStatus 显示的内容意思如下:

  • active connections – 当前 Nginx 正处理的活动连接数。
  • server accepts handled requests — 总共处理了 14553819 个连接 , 成功创建 14553819 次握手 ( 证明中间没有失败的 ), 总共处理了 19239266 个请求 ( 平均每次握手处理了 1.3 个数据请求 )。
  • reading — nginx 读取到客户端的 Header 信息数。
  • writing — nginx 返回给客户端的 Header 信息数。
  • waiting — 开启 keep-alive 的情况下,这个值等于 active - (reading + writing),意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。
静态文件处理

通过正则表达式,我们可让 Nginx 识别出各种静态文件,例如 images 路径下的所有请求可以写为:

location ~ ^/images/ {
    root /opt/webapp/images;
}

而下面的配置则定义了几种文件类型的请求处理方式。

location ~ \.(htm|html|gif|jpg|jpeg|png|bmp|ico|css|js|txt)$ {
    root /opt/webapp;
    expires 24h;
}

对于例如图片、静态 HTML 文件、js 脚本文件和 css 样式文件等,我们希望 Nginx 直接处理并返回给浏览器,这样可以大大的加快网页浏览时的速度。因此对于这类文件我们需要通过 root 指令来指定文件的存放路径,同时因为这类文件并不常修改,通过 expires 指令来控制其在浏览器的缓存,以减少不必要的请求。 expires 指令可以控制 HTTP 应答中的“ Expires ”和“ Cache-Control ”的头标(起到控制页面缓存的作用)。您可以使用例如以下的格式来书写 Expires:

expires 1 January, 1970, 00:00:01 GMT;
expires 60s;
expires 30m;
expires 24h;
expires 1d;
expires max;
expires off;
动态页面请求处理

Nginx 本身并不支持现在流行的 JSP、ASP、PHP、PERL 等动态页面,但是它可以通过反向代理将请求发送到后端的服务器,例如 Tomcat、Apache、IIS 等来完成动态页面的请求处理。前面的配置示例中,我们首先定义了由 Nginx 直接处理的一些静态文件请求后,其他所有的请求通过 proxy_pass 指令传送给后端的服务器(在上述例子中是 Tomcat)。最简单的 proxy_pass 用法如下:

location / {
    proxy_pass        http://localhost:8080;
    proxy_set_header  X-Real-IP  $remote_addr;
}

这里我们没有使用到集群,而是将请求直接送到运行在 8080 端口的 Tomcat 服务上来完成类似 JSP 和 Servlet 的请求处理。

当页面的访问量非常大的时候,往往需要多个应用服务器来共同承担动态页面的执行操作,这时我们就需要使用集群的架构。 Nginx 通过 upstream 指令来定义一个服务器的集群,最前面那个完整的例子中我们定义了一个名为 tomcats 的集群,这个集群中包括了三台服务器共 6 个 Tomcat 服务。而 proxy_pass 指令的写法变成了:

location / {
    proxy_pass        http://tomcats;
    proxy_set_header  X-Real-IP  $remote_addr;
}

在 Nginx 的集群配置中,Nginx 使用最简单的平均分配规则给集群中的每个节点分配请求。一旦某个节点失效时,或者重新起效时,Nginx 都会非常及时的处理状态的变化,以保证不会影响到用户的访问。

总结

尽管整个程序包只有五百多 K,但麻雀虽小、五脏俱全。 Nginx 官方提供的各种功能模块应有尽有,结合这些模块可以完整各种各样的配置要求,例如:压缩、防盗链、集群、FastCGI、流媒体服务器、Memcached 支持、URL 重写等等,更关键的是 Nginx 拥有 Apache 和其他 HTTP 服务器无法比拟的高性能。您甚至可以在不改变原有网站的架构上,通过在前端引入 Nginx 来提升网站的访问速度。

本文只是简单介绍了 Nginx 的安装以及常见的基本的配置和使用,更多关于 Nginx 的信息请阅读文章后面的参考资源。在这里要非常感谢我的朋友——陈磊(moc.nsm|xinahc#moc.nsm|xinahc),他一直在做 Nginx 的中文 WIKI(http://wiki.codemongers.com/NginxChs),同时也是他介绍给我这么好的一款软件。

如果您的网站是运行在 Linux 下,如果您并没有使用一些非常复杂的而且确定 Nginx 无法完成的功能,那您应该试试 Nginx 。

Nginx 简单的负载均衡配置示例

by 张宴
http://blog.s135.com/post/306/
http://blog.s135.com/post/297/

  www.s135.com 和 blog.s135.com 域名均指向 Nginx 所在的服务器IP。

  用户访问http://www.s135.com ,将其负载均衡到192.168.1.2:80、192.168.1.3:80、192.168.1.4:80、192.168.1.5:80四台服务器。

  用户访问http://blog.s135.com ,将其负载均衡到192.168.1.7服务器的8080、8081、8082端口。

  以下为配置文件nginx.conf:

user  www www;
 
worker_processes 10;
 
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
 
#pid        logs/nginx.pid;
 
#最大文件描述符
worker_rlimit_nofile 51200;
 
events 
{
      use epoll;
 
      worker_connections 51200;
}
 
http 
{
      include       conf/mime.types;
      default_type  application/octet-stream;
 
      keepalive_timeout 120;
 
      tcp_nodelay on;
 
      upstream  www.s135.com  {
              server   192.168.1.2:80;
              server   192.168.1.3:80;
              server   192.168.1.4:80;
              server   192.168.1.5:80;
      }
 
      upstream  blog.s135.com  {
              server   192.168.1.7:8080;
              server   192.168.1.7:8081;
              server   192.168.1.7:8082;
      }
 
      server
      {
              listen  80;
              server_name  www.s135.com;
 
              location / {
                       proxy_pass        http://www.s135.com;
                       proxy_set_header   Host             $host;
                       proxy_set_header   X-Real-IP        $remote_addr;
                       proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
              }
 
              log_format  www_s135_com  '$remote_addr - $remote_user [$time_local] $request '
                                '"$status" $body_bytes_sent "$http_referer" '
                                '"$http_user_agent" "$http_x_forwarded_for"';
              access_log  /data1/logs/www.log  www_s135_com;
      }
 
      server
      {
              listen  80;
              server_name  blog.s135.com;
 
              location / {
                       proxy_pass        http://blog.s135.com;
                       proxy_set_header   Host             $host;
                       proxy_set_header   X-Real-IP        $remote_addr;
                       proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
              }
 
              log_format  blog_s135_com  '$remote_addr - $remote_user [$time_local] $request '
                                '"$status" $body_bytes_sent "$http_referer" '
                                '"$http_user_agent" "$http_x_forwarded_for"';
              access_log  /data1/logs/blog.log  blog_s135_com;
      }
}

  附:Nginx 的安装方法可参照《Nginx 0.5.31 + PHP 5.2.4(FastCGI)搭建可承受3万以上并发连接数,胜过Apache 10倍的Web服务器》]文章的以下段落(仅做负载均衡,无需支持PHP的安装方法):

  二、安装PHP 5.2.4(FastCGI模式)
  4、创建www用户和组,以及其使用的目录:

  三、安装Nginx 0.5.31
  1、安装Nginx所需的pcre库:
  2、安装Nginx
  3、创建Nginx日志目录
  5、启动Nginx

使用nginx实现WEB网站负载均衡

如果你关注过nginx,必定知道nginx这个软件有什么用的,如果你的网站访问量越来越高,一台服务器已经没有办法承受流量压力,那就增多几台服务器来做负载吧。做网站负载可以买硬件设备来实现,比如F5,不过价格就几十万到上百万,够贵,本文介绍做网站负载的软件是免费的,nginx目前好多门户网站与大访问量的网站都在使用做为HTTP服务器,所以nginx是非常优秀的,下面介绍做负载测试吧。

环境:(2台服务器)

第一台:

CPU:Inter(R) Pentium(R) 4 CPU 2.8G
内存:1G
系统:windows 7
IIS: IIS 7
nginx:nginx/Windows-0.8.22
IP:172.10.1.97
环境:本地

第二台:

CPU:Inter(R) Pentium(R) 4 CPU 3.0G
内存:2G
系统:windows Server 2003
IIS: IIS 6
IP:172.10.1.236
环境:远程

说明:

本次测试,软件nginx放在本地(172.10.1.97),也就是说放在域名绑定的那台服务器,这台服务器的IIS不能使用80端口,因为等下nginx软件要使用80这个端口。

下载nginx的地址如下:
nginx下载:http://nginx.net/
本次测试使用的版本下载:nginx/Windows-0.8.22
下载解压到C:,把目录名改成nginx

好,下面进入实践:

第一:IIS Site 1

在本地(172.10.1.97)这台服务器IIS创建一个网站,使用端口为808,如下图:

IIS 网站绑定设置图

第二:IIS Site 2

在远程172.10.1.236的IIS创建一个网站,使用端口为80,如下图:

远程IIS绑定设置图

第三:nginx load balance

好了,以上已经设置好两台服务器的IIS了,下面配置nginx软件来实现网站负载均衡,打开如下文件:

C: ginxconf ginx.conf

1、找到内容server {

在这上面加入如下内容:

upstream  xueit.com {  
  server   172.10.1.97:808;
  server   172.10.1.236:80;
    }
(这是负载切换使用的服务器网站IP)

2、找到location /

location / {
            root   html;
            index  index.html index.htm;
        }

把内容更改如下:

location / {
            proxy_pass http://xueit.co

WEB服务器使用nginx实现网站负载均衡测试实例,关键词是建站经验,站长经验,m;
            proxy_redirect default;
        }

3、找到server {

server {
        listen       80;
        server_name  localhost;

把内容改成如下:

server {
        listen       80;
        server_name  172.10.1.97;

(这是监听访问域名绑定那台服务器80端口的请求)

好,在这里就这么简单配置好了,下面看下以上3步配置的图:

负载配置图

第四:启动nginx

都配置好了,下面启动nginx软件

进入命令提示符CMD,进入c: ginx》,输入nginx命令,如下图:

启动nginx

这时候,系统进程有两个nginx.exe进程,如下图:

系统nginx进程

停止nginx运行输入nginx -s stop 即可

第五:查看下负载效果

经过以上的配置,现在我们看下负载效果:

在本地(172.10.1.97)这服务器打开IE,输入:http://172.10.1.97

第一次打开网站的结果图:

第一次运行网站图

再刷新一下网页,出现的结果图:

再次访问网站图

很好,网站已经负载成功。

经过这次测试,实现网站负载再也不是难事了。也不用购买非常贵的硬件设备了。网上介绍说nginx软件可以处理并发上万,所以绝对是个非常不错的选择。

如果网站访问量非常大,可以专门用一台服务器跑nginx,其它服务器跑网站程序(几台服务器的程序都是一样的),这样负载就没有太大问题,如果再不行,把网站一些栏目做一个2级域名,2级域名同样做负载,这样更厉害了吧。

nginx软件在linux上跑性能比在windows上跑要好,所以做负载可以用linux跑nginx,.net开发的网站放到windows服务器IIS上。

Cookie控制

需要注意Cookie的安全性验证
1. 不再需要F5,为客户节省大量在负载均衡硬件上的投资;
2. 可以实现用户会话,比如电子商务网站的购物篮。而使用F5时,程序会被限制使用会话;
3. 在客户端浏览器上而不是服务端保存用户会话,从而节省巨量服务端内存和会话管理开销,服务器资源可以更充分地应用到业务逻辑上;
4. 降低对服务器硬件配置的要求,比如不再需要更多昂贵的内存,节省投资;
5. 降低对服务器软件配置的要求,比如昂贵的、价值几百万的Weblogic和Websphere服务器可以用免费的Tomcat替代,从而为客户节省大量投资;
6. 非常容易实现的、可自由伸缩的服务器集群,用户会话不需要在不同服务器之间迁移;
7. 比Struts更好用的纯MVC框架,程序员开发程序更容易,软件更易扩展和重用,节省软件开发成本;
8. 可以实现一些特殊应用所需要的永久性会话,而不占用服务器资源。

浅谈用HTML+Java实现服务器负载均衡

【摘 要】本文主要讨论在负载均衡的前提下,探索HTML+Ajax的结合的道路,寻求解决服务器负载均衡的方法。
【关键词】HTML Ajax 负载均衡
  
  在计算机技术飞速发展的今天,一个大企业拥有两台或多台同等配置的服务器的情况已经司空见惯。
  在负载均衡的思路下,多台服务器为对称方式,每台服务器都具有同等的地位,可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术,将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上,而接收到请求的服务器都独立回应客户机的请求。
  提供服务的一组服务器组成了一个应用服务器集群(cluster),并对外提供一个统一的地址。当一个服务请求被发至该集群时,根据一定规则选择一台服务器,并将服务转定向给该服务器承担,即将负载进行均衡分摊。
  通过应用负载均衡技术,使应用服务超过了一台服务器只能为有限用户提供服务的限制,可以利用多台服务器同时为大量用户提供服务。当某台服务器出现故障时,负载均衡服务器会自动进行检测并停止将服务请求分发至该服务器,而由其他工作正常的服务器继续提供服务,从而保证了服务的可靠性。

  上述的集群技术一般都用于Web服务器、应用服务器等,而不是用于数据库服务器,即不是用于有共享的存储的服务。数据库服务器将涉及到加锁、回滚等一系列问题,要复杂的多。一般数据库服务器只是使用双机,其中一台工作,另一台备份。数据库的双机并行只用于大型数据库中。
  常见的负载均衡实现的方法有以下几种:最简单的是通过DNS,但只能实现简单的轮流分配,也不能处理故障。如果是基于MS IIS,Windows 2003 Server本身就带了负载均衡服务。但这一服务也只是轮流分配。 硬件方式,通过交换机的功能或专门的负载均衡设备可以实现。对于流量的分配可以有多种方式,但基本上都是应用无关的,与服务器的实际负载关系也不大。另外,设备的价格较贵(优点是能支持很多台服务器)。这种方式往往适合大流量、简单应用。 软件方式,通过一台负载均衡服务器进行,上面安装软件。这种方式比较灵活,成本相对也较低。另外一个很大的优点就是可以根据应用的情况和服务器的情况采取一些策略。这方面比较典型的软件产品,是富士通西门子公司的PCL SIS负载均衡软件。
  我们所要讨论的所谓负载均衡是除这几种以外的另一种方法,即用大家都比较熟悉的HTML技术和眼下炙手可热的Ajax技术。

HTML

全称HyperText Mark-up Language——超文本标记语言。
  普通的媒体记载信息的形式都是定义一个开头,然后以线性方式或时间的顺序进行到结尾。这种媒体包括电影、录音和录像带等,大多数的书本上的信息也是以这种形式组织的。
  而在 /Music/">音乐激光唱盘,如果你想听第五首曲子就可以选择它并立即播放。这不同于录音带的使用,因为你必须先播放几次录音带你才能知道一首歌从哪里开始。
  超媒体的概念应用于文本后,我们就有了超文本,现在你只要点击一个链接你就会看到新的内容或新的页面。如果你能获取世界上不同计算机上的文档的链接,那么你就可以体会到一个像蜘蛛网一样分布的信息世界,这里充满了交错的链接和网页,这就是我们知道的 /English/">英文的原义是遍布世界的蜘蛛网。在万维网上,网页是存放在众多的 Web服务器里的,这些服务器与国际互联网相连,我们通过浏览器就可以上网浏览这些网页。
  万维网发展非常迅猛的原因之一就是所有的网页都是以同一格式编写的,这种格式或编写的语言就是HTML(Hypertext Markup Language),即超文本标记语言。

Ajax

全称Asynchronous JavaScriptAnd XML——异步JavaScript和XML。
  Ajax不是一项技术。事实上它是几种各自发展的技术的有力集合。Ajax包括:使用XHTML与CSS的标准表现(standards-based presentation); 使用DOM(Document Object Model)进行动态显示与交互; 使用XML and XSLT 进行数据交换与操作; 使用XMLHttpRequest进行异步数据传输; 使用JavaScript将所有这些绑在一起。
  传统的Web应用模型是这样工作的:界面中大部分的用户行为触发一次返回Web服务器的HTTP请求,服务器完成一些处理——接收数据,处理计算,再访问其它的数据库系统,最后返回一个HTML页面到客户端。这是一个老套的模式,自采用超文本作为web使用以来,一直都这样用,但看过《The Elements ofUser Experience》的读者一定知道,是什么限制了Web界面没有桌面软件那么好用。
  技术上,这种方法很有意义。但它并不有助于友好的用户体验。当服务器在做它的事情的时候,用户在做什么?不错,等待。而且是每进行一步操作,就要等待一次。
  很明显,假如我们设计含有WEB表单的应用,我们不会让用户在那里空等(译注:用户提交表单之后,通常会返回一个含有相关信息的页面到客户端)。当加载一个界面时,为什么用户交互每次都要停下来,以等待服务器响应应用请求?为什么用户要经历应用与服务器之间的交互?

Ajax有什么不同?

  Ajax应用通过在客户端与服务端之间引入一个中间层——Ajax引擎(Ajaxengine),改变了WEB交互“start-stop-start-stop”的规律。增加一个层看起来似乎降低了应用的响应性,但事实恰好相反。
  浏览器通过加载一个Ajax引擎,来取代加载一个WEB页。Ajax引擎用JavaScript编写,通常放在一个隐藏的框架中。引擎负责渲染用户界面,帮助用户与服务端通信。Ajax引擎允许用户与应用的交互异步发生,独立于与服务端的通信。
所以,用户不用再盯着空白的浏览器窗口和沙漏光标,等待服务端的响应。
  对于每个用户行为(user action),原本的做法是生成一次HTTP请求;现在变成了对Ajax引擎的一次JavaScript call,响应那些不用返回服务端的用户行为——比如简单的数据验证,在内存中编辑数据甚至是一些导航——都由引擎自己处理。如果引擎需要服务端的响应——比如提交数据以供处理、加载额外的界面代码,或者获得新数据——引擎便会使用XML进行异步请求,而不用停止用户与应用的交互。
  其实,凡是用到Ajax的地方必定用到HTML语言,因为没有了HTML语言Ajax也就失去了它存在的意义。先来看下我们的代码吧:

  Ajax.html 
  <html> 
  <head> 
  <meta http-equiv="Content-Type" content="text/html; charset=GB2312"> 
  <title>index_redirect</title> 
  <script language="javascript"> 
  function redirectPage(){ 
  var now = new Date(); 
  var time = now.getTime(); 
  var flag = times%2;
  var url;//首选url 
  var urlbak;//备用url 
  var errorinfo=1;//定义服务器状态信息,1为正常,0为异常 
  if(flag==0){ 
  url='http://192.168.0.1:8080/index.jsp'; 
  urlbak='http://192.168.1.1:8080/index.jsp'; 
  }else{ 
  url='http://192.168.1.1:8080/index.jsp'; 
  urlbak='http://192.168.0.1:8080/index.jsp'; 
  } 
  try{ 
  varxmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
   xmlhttp.open("GET",url,false); 
   xmlhttp.send(null); 
   }catch(e){ 
   errorinfo=0;//主用Server异常,将服务器状态信息置位0 
   } 
   
   if(errorinfo==1){//主用Server正常 
   window.top.location=url; 
   } else{ 
   window.top.location=urlbak; 
   } 
  </script> 
  </head> 
  <body onload = redirectPage();> 
  </body> 
  </html>

  此页面在用户登录服务器之前,先进行服务器的状态判断。拿当前时间的毫秒数(time = now.getTime();)的奇偶进行控制,如果当前毫秒数为奇数,即times%2=1,页面自动转往'http://192.168.1.1:8080/index.jsp',如果当前毫秒数为偶数,即times%2=0,页面自动转往'http://192.168.0.1:8080/index.jsp',从而达到负载均衡的效果。
  当然,这只是比较乐观的情况。假如当前毫秒数为奇数,而'http://192.168.1.1:8080/index.jsp'这个服务不可用的话,这时我们就可以利用Ajax技术进行判断,
  xmlhttp.open("GET"urlfalse); 
  xmlhttp.send(null); 
  如果响应异常的话,将会抛出异常: 
  catch(e){ 
   errorinfo=0;//主用Server异常,将服务器状态信息置位0 
  }

  此时errorinfo被置为0,从而将用户请求转向'http://192.168.0.1:8080/index.jsp';反之,如果当前毫秒数为偶数,而'http://192.168.0.1:8080/index.jsp'异常的话,errorinfo的值仍然为1,从而将用户的请求转向'http://192.168.1.1:8080/index.jsp'。
进而起到保障只要有一台服务器正常,用户的请求就可以正常响应的目的。
  
  参考文献:
  [1][美]穆西亚诺,[美]肯尼迪著,张洪涛,邢璐译.HTML&XHTML权威指南(第六版).清华大学出版社,2007.
  [2]扎卡斯,姆克皮克,福西特著,徐锋等译.Ajax高级程序设计.人民邮电出版社,2006.

See Also

负载均衡软件硬件实现方案
浅谈用HTML+Ajax实现服务器负载均衡