4.html

介绍linux下文件和设备编程

&nbsp;&nbsp;&nbsp; 共享存储的好处是媒体文件的管理人员看到统一的存储空间，使得媒体文件维护工作比较方便。当客户访问不断增加使得整个系统超载时，管理员可以很快地加入新的媒体服务器结点来处理请求。<p>
&nbsp;&nbsp;&nbsp; Real公司以其高压缩比的音频视频格式、Real媒体服务器和媒体播放器RealPlayer而闻名。Real公司正在使用以上结构将由20多台服务器组成的LVS可伸缩Web和媒体集群，为其全球用户提供Web和音频视频服务。Real公司的高级技术主管声称LVS击败所有他们尝试过的商品化负载均衡产品[7]。<p>
5.可伸缩Cache服务<p>
&nbsp;&nbsp;&nbsp; 有效的网络Cache系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是，若Cache服务器超载而不能及时地处理请求，反而会增加响应延时。所以，Cache服务的可伸缩性很重要，当系统负载不断增长时，整个系统能被扩展来提高Cache服务的处理能力。尤其，在主干网上的Cache服务可能需要几个Gbps的吞吐率，单台服务器（例如SUN目前最高端的Enterprise 10000服务器）远不能达到这个吞吐率。可见，通过PC服务器集群实现可伸缩Cache服务是很有效的方法，也是性能价格比最高的方法。<p>
&nbsp;&nbsp;&nbsp; 基于LVS的Cache集群的体系结构如图4所示：第一层是负载调度器，一般采用IP负载均衡技术，可以使得整个系统有较高的吞吐率；第二层是Cache服务器池，一般Cache服务器放置在接近主干Internet连接处，它们可以分布在不同的网络中。调度器可以有多个，放在离客户接近的地方。<p>
&nbsp;&nbsp;&nbsp; IPVS负载调度器一般使用IP隧道方法（即VS/TUN方法，将在以后文章中详细叙述），来架构Cache集群系统，因为Cache服务器可能被放置不同的地方（例如在接近主干Internet连接处），而调度器与Cache服务器池可能不在同一个物理网络中。采用VS/TUN方法，调度器只调度Web Cache请求，而Cache服务器将响应数据直接返回给客户。在请求对象不能在本地命中的情况下，Cache服务器要向源服务器发请求，将结果取回，最后将结果返回给客户；若采用NAT技术的商品化调度器，需要四次进出调度器，完成这个请求。而用VS/TUN方法（或者VS/DR方法），调度器只调度一次请求，其他三次都由Cache服务器直接访问Internet完成。所以，这种方法对Cache集群系统特别有效。<p>
&nbsp;&nbsp;&nbsp; Cache服务器采用本地硬盘来存储可缓存的对象，因为存储可缓存的对象是写操作，且占有一定的比例，通过本地硬盘可以提高I/O的访问速度。Cache服务器间有专用的多播通道（Multicast Channel），通过ICP协议（Internet Cache Protocol）来交互信息。当一台Cache服务器在本地硬盘中未命中当前请求时，它可以通过ICP查询其他Cache服务器是否有请求对象的副本，若存在，则从邻近的Cache服务器取该对象的副本，这样可以进一步提高Cache服务的命中率。<p>
&nbsp;&nbsp;&nbsp; 为150多所大学和地区服务的英国国家JANET Web Cache网在1999年11月用以上LVS结构实现可伸缩的Cache集群[8]，只用了原有50多台相互独立Cache服务器的一半，用户反映网络速度跟夏天一样快（学生放暑假）。可见，通过负载调度可以摸平单台服务器访问的毛刺（Burst），提高整个系统的资源利用率。<p>
6.可伸缩邮件服务<p>
&nbsp;&nbsp;&nbsp; 随着Internet用户不断增长，很多ISP面临他们邮件服务器超载的问题。当邮件服务器不能容纳更多的用户帐号时，有些ISP买更高档的服务器来代替原有的，将原有服务器的信息（如用户邮件）迁移到新服务器是很繁琐的工作，会造成服务的中断；有些ISP设置新的服务器和新的邮件域名，新的邮件用户放置在新的服务器上，如上海电信现在用不同的邮件服务器public1.sta.net.cn、public2.sta.net.cn到public9.sta.net.cn放置用户的邮件帐号，这样静态地将用户分割到不同的服务器上，会造成邮件服务器负载不平衡，系统的资源利用率低，对用户来说邮件的地址比较难记。<p>
&nbsp;&nbsp;&nbsp; 可以利用LVS框架实现高可伸缩、高可用的邮件服务系统。它的体系结构如图5所示：在前端是一个采用IP负载均衡技术的负载调度器；第二层是服务器池，有LDAP（Light-weight Directory Access Protocol）服务器和一组邮件服务器。第三层是数据存储，通过分布式文件系统来存储用户的邮件。集群中各结点是通过高速网络相连接。<p>
&nbsp;&nbsp;&nbsp; 用户的信息如用户名、口令、主目录和邮件容量限额等存储在LDAP服务器中，可以通过HTTPS让管理员进行用户管理。在各个邮件服务器上运行SMTP（Simple Mail Transfer Protocol）、POP3（Post Office Protocol version 3）、IMAP4（Internet Message Access Protocol version 4）和HTTP/HTTPS服务。SMTP接受和转发用户的邮件，SMTP服务进程查询LDAP服务器获得用户信息，再存储邮件。POP3和IMAP4通过LDAP服务器获得用户信息，口令验证后，处理用户的邮件访问请求。这里，需要有机制避免不同服务器上的SMTP、POP3和IMAP4服务进程对用户邮件的读写冲突。HTTP/HTTPS服务是让用户通过浏览器可以访问邮件。<p>
&nbsp;&nbsp;&nbsp; IPVS调度器将SMTP、POP3、IMAP4和HTTP/HTTPS请求流负载较均衡地分发到各邮件服务器上，从上面各服务的处理流程来看，不管请求被发送到哪一台邮件服务器处理，其结果是一样的。这里，将SMTP、POP3、IMAP4和HTTP/HTTPS运行在各个邮件服务器上进行集中调度，有利于提高整个系统的资源利用率。<p>
&nbsp;&nbsp;&nbsp; 系统中可能的瓶颈是LDAP服务器，对LDAP服务中B+树的参数进行优化，再结合高端的服务器，可以获得较高的性能。若分布式文件系统没有多个存储结点间的负载均衡机制，则需要相应的邮件迁移机制来避免邮件访问的倾斜。<p>
&nbsp;&nbsp;&nbsp; 这样，这个集群系统对用户来说就像一个高性能、高可靠的邮件服务器（例如上海电信只要用一个邮件域名public.sta.net.cn就可以）。当邮件用户不断增长时，只要在集群中增加服务器结点和存储结点。用户信息的集中存储使得用户管理变得容易，且集群系统有利于提高资源利用率。<p>
7.小结<p>
&nbsp;&nbsp;&nbsp; 本文给出LVS集群的通用体系结构，并讨论了它的设计原则和相应的特点；最后将LVS集群应用于建立可伸缩的Web、Media、Cache和Mail网络服务，并指出了系统架设时应注意的要点。我们将在后续的文章中详细解释LVS集群的技术、实现和应用。<p>
<br>



<center><A HREF="#Content">[目录]</A></center>
<hr><br><A NAME="I625" ID="I625"></A><center><b><font size=+2>IP负载均衡</font></b></center><br>
本文在分析服务器集群实现虚拟网络服务的相关技术上，详细描述了LVS集群中实现的三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR）的工作原理，以及它们的优缺点。<p>
1.前言<br>
&nbsp;&nbsp;&nbsp; 在前面文章中，讲述了可伸缩网络服务的几种结构，它们都需要一个前端的负载调度器（或者多个进行主从备份）。我们先分析实现虚拟网络服务的主要技术，指出IP负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术中，主要有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation）。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出了通过IP隧道实现虚拟服务器的方法VS/TUN（Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。VS/NAT、VS/TUN和VS/DR技术是LVS集群中实现的三种IP负载均衡技术，我们将在文章中详细描述它们的工作原理和各自的优缺点。<p>
&nbsp;&nbsp;&nbsp; 在以下描述中，我们称客户的socket和服务器的socket之间的数据通讯为连接，无论它们是使用TCP还是UDP协议。下面简述当前用服务器集群实现高可伸缩、高可用网络服务的几种负载调度方法，并列举几个在这方面有代表性的研究项目。<p>
2.实现虚拟服务的相关方法<br>
&nbsp;&nbsp;&nbsp; 在网络服务中，一端是客户程序，另一端是服务程序，在中间可能有代理程序。由此看来，可以在不同的层次上实现多台服务器的负载均衡。用集群解决网络服务性能问题的现有方法主要分为以下四类。<br>
2.1. 基于RR-DNS的解决方法<p>
&nbsp;&nbsp;&nbsp; NCSA的可伸缩的WEB服务器系统就是最早基于RR-DNS（Round-Robin Domain Name System）的原型系统[1,2]。它的结构和工作流程如下图所示：<p>
&nbsp;&nbsp;&nbsp; 有一组WEB服务器，他们通过分布式文件系统AFS(Andrew File System)来共享所有的HTML文档。这组服务器拥有相同的域名（如www.ncsa.uiuc.edu），当用户按照这个域名访问时, RR-DNS服务器会把域名轮流解析到这组服务器的不同IP地址，从而将访问负载分到各台服务器上。<p>
&nbsp;&nbsp;&nbsp; 这种方法带来几个问题。第一，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户就域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到RR-DNS域名服器把这个域名解析到其中一台服务器的IP地址。可见，从用户到RR-DNS间存在多台域名服器，而它们都会缓冲已解析的名字到IP地址的映射,这会导致该域名服器组下所有用户都会访问同一WEB服务器，出现不同WEB服务器间严重的负载不平衡。为了保证在域名服务器中域名到IP地址的映射不被长久缓冲，RR-DNS在域名到IP地址的映射上设置一个TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服器提交请求并进行重新影射。这就涉及到如何设置这个TTL值，若这个值太大，在这个TTL期间，很多请求会被映射到同一台WEB服务器上，同样会导致严重的负载不平衡。若这个值太小，例如是０，会导致本地域名服务器频繁地向RR-DNS提交请求，增加了域名解析的网络流量，同样会使RR-DNS服务器成为系统中一个新的瓶颈。<p>
&nbsp;&nbsp;&nbsp; 第二，用户机器会缓冲从名字到IP地址的映射，而不受TTL值的影响，用户的访问请求会被送到同一台WEB服务器上。由于用户访问请求的突发性和访问方式不同，例如有的人访问一下就离开了，而有的人访问可长达几个小时，所以各台服务器间的负载仍存在倾斜（Skew）而不能控制。假设用户在每个会话中平均请求数为20，负载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说，当TTL值为0时，因为用户访问的突发性也会存在着较严重的负载不平衡。<p>
&nbsp;&nbsp;&nbsp; 第三，系统的可靠性和可维护性差。若一台服务器失效，会导致将域名解析到该服务器的用户看到服务中断，即使用户按“Reload”按钮，也无济于事。系统管理员也不能随时地将一台服务器切出服务进行系统维护，如进行操作系统和应用软件升级，这需要修改RR-DNS服务器中的IP地址列表，把该服务器的IP地址从中划掉，然后等上几天或者更长的时间，等所有域名服器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机不再使用该站点为止。<p>
2.2. 基于客户端的解决方法<p>
&nbsp;&nbsp;&nbsp; 基于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识，进而把以负载均衡的方式将请求发到不同的服务器。例如，Netscape Navigator浏览器访问Netscape的主页时，它会随机地从一百多台服务器中挑选第N台，最后将请求送往wwwN.netscape.com。然而，这不是很好的解决方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻烦，当使用IE等其他浏览器不可避免的要进行RR-DNS解析。<p>
&nbsp;&nbsp;&nbsp; Smart Client[3]是Berkeley做的另一种基于客户端的解决方法。服务提供一个Java Applet在客户方浏览器中运行，Applet向各个服务器发请求来收集服务器的负载等信息，再根据这些信息将客户的请求发到相应的服务器。高可用性也在Applet中实现，当服务器没有响应时，Applet向另一个服务器转发请求。这种方法的透明性不好，Applet向各服务器查询来收集信息会增加额外的网络流量，不具有普遍的适用性。<p>
2.3. 基于应用层负载均衡调度的解决方法<p>
&nbsp;&nbsp;&nbsp; 多台服务器通过高速的互联网络连接成一个集群系统，在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时，请求会提交给作负载均衡调度的应用程序，分析请求，根据各个服务器的负载情况，选出一台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给用户。<p>
&nbsp;&nbsp;&nbsp; 应用层负载均衡调度的典型代表有Zeus负载调度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。Zeus负载调度器是Zeus公司的商业产品，它是在Zeus Web服务器程序改写而成的，采用单进程事件驱动的服务器结构。pWeb就是一个基于Apache 1.1服务器程序改写而成的并行WEB调度程序，当一个HTTP请求到达时，pWeb会选出一个服务器，重写请求并向这个服务器发出改写后的请求，等结果返回后，再将结果转发给客户。Reverse-Proxy利用Apache 1.3.1中的Proxy模块和Rewrite模块实现一个可伸缩WEB服务器，它与pWeb的不同之处在于它要先从Proxy的cache中查找后，若没有这个副本，再选一台服务器，向服务器发送请求，再将服务器返回的结果转发给客户。SWEB是利用HTTP中的redirect错误代码，将客户请求到达一台WEB服务器后，这个WEB服务器根据自己的负载情况，自己处理请求，或者通过redirect错误代码将客户引到另一台WEB服务器，以实现一个可伸缩的WEB服务器。<p>
&nbsp;&nbsp;&nbsp; 基于应用层负载均衡调度的多服务器解决方法也存在一些问题。第一，系统处理开销特别大，致使系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时，调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制；需要进行二次TCP连接，一次是从用户到调度器，另一次是从调度器到真实服务器；需要对请求进行分析和重写。这些处理都需要不小的ＣＰＵ、内存和网络等资源开销，且处理时间长。所构成系统的性能不能接近线性增加的，一般服务器组增至3或4台时，调度器本身可能会成为新的瓶颈。所以，这种基于应用层负载均衡调度的方法的伸缩性极其有限。第二，基于应用层的负载均衡调度器对于不同的应用，需要写不同的调度器。以上几个系统都是基于HTTP协议，若对于FTP、Mail、POP3等应用，都需要重写调度器。<p>
2.4. 基于IP层负载均衡调度的解决方法<p>
&nbsp;&nbsp;&nbsp; 用户通过虚拟IP地址（Virtual IP Address）访问服务时，访问请求的报文会到达负载调度器，由它进行负载均衡调度，从一组真实服务器选出一个，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器时，将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。Berkeley的MagicRouter[8]、Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP等都是使用网络地址转换方法。MagicRouter是在Linux 1.3版本上应用快速报文插入技术，使得进行负载均衡调度的用户进程访问网络设备接近核心空间的速度，降低了上下文切换的处理开销，但并不彻底，它只是研究的原型系统，没有成为有用的系统存活下来。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常昂贵的商品化系统，它们支持部分TCP/UDP协议，有些在ICMP处理上存在问题。<p>
&nbsp;&nbsp;&nbsp; IBM的TCP Router[9]使用修改过的网络地址转换方法在SP/2系统实现可伸缩的WEB服务器。TCP Router修改请求报文的目标地址并把它转发给选出的服务器，服务器能把响应报文的源地址置为TCP Router地址而非自己的地址。这种方法的好处是响应报文可以直接返回给客户，坏处是每台服务器的操作系统内核都需要修改。IBM的NetDispatcher[10]是TCP Router的后继者，它将报文转发给服务器，而服务器在non-ARP的设备配置路由器的地址。这种方法与LVS集群中的VS/DR类似，它具有很高的可伸缩性，但一套在IBM SP/2和NetDispatcher需要上百万美金。总的来说，IBM的技术还挺不错的。<p>
&nbsp;&nbsp;&nbsp; 在贝尔实验室的ONE-IP[11]中，每台服务器都独立的IP地址，但都用IP Alias配置上同一VIP地址，采用路由和广播两种方法分发请求，服务器收到请求后按VIP地址处理请求，并以VIP为源地址返回结果。这种方法也是为了避免回应报文的重写，但是每台服务器用IP Alias配置上同一VIP地址，会导致地址冲突，有些操作系统会出现网络失效。通过广播分发请求，同样需要修改服务器操作系统的源码来过滤报文，使得只有一台服务器处理广播来的请求。<p>
&nbsp;&nbsp;&nbsp; 微软的Windows NT负载均衡服务（Windows NT Load Balancing Service，WLBS）[12]是1998年底收购Valence Research公司获得的，它与ONE-IP中的基于本地过滤方法一样。WLBS作为过滤器运行在网卡驱动程序和TCP/IP协议栈之间，获得目标地址为VIP的报文，它的过滤算法检查报文的源IP地址和端口号，保证只有一台服务器将报文交给上一层处理。但是，当有新结点加入和有结点失效时，所有服务器需要协商一个新的过滤算法，这会导致所有有Session的连接中断。同时，WLBS需要所有的服务器有相同的配置，如网卡速度和处理能力。<p>
3. 通过NAT实现虚拟服务器（VS/NAT）<p>
&nbsp;&nbsp;&nbsp; 由于IPv4中IP地址空间的日益紧张和安全方面的原因，很多网络使用保留IP地址（10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）[64, 65, 66]。这些地址不在Internet上使用，而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时，就需要采用网络地址转换（Network Address Translation, 以下简称NAT），将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信它们连接一个IP地址，而不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。<p>
&nbsp;&nbsp;&nbsp; VS/NAT的体系结构如