集群的可扩展性及其分布式体系结构之八--面向连接的负载平衡集群主要问题

缺乏对 Session 的支持

现在的许多网页都是由一些动态网页程序(ASP、JSP、PHP 等)所写成的，其中都会支持Session 的功能，这个功能通过在服务器上面记录客户端的诸如用户身份等会话信息，可以视做是Server 端的cookie。程序员可以把一些重要的资料如登录用户的数据、权限或者是当前购物车的状态等信息存储在Server 端，这样可以避免使用一般客户端cookie 造成的敏感信息容易被获取的安全性问题。服务端session 是由服务器上的cookie文件实现的，当客户端连接的时候，服务器会给客户端一个含有session id 的cookie信息，客户端之后的request 都会附带着这个cookie。Server 则根据这个id 来索引客户端的session。通过这样的方式，保证一些会话级的通信能够顺利进行。

所以对于这样的应用，负载平衡器必需建立一个全局的Hash映射表，记录某个客户端的IP地址和服务器的Session标记的映射关系，在下次客户端的请求到来时，必需要根据请求中 的cookie 来做负载平衡，重定向到原来的server。而面向连接的集群技术因为仅对请求的地址和端口信息进行负载平衡，所以可能会把同一个会话的请求重定向到另一台server，这样就造成了很严重的错误，因为客户端的数据是存放在原来那台server 里的。这样的情况常见于电子商务网站中，例如购物网站需要提供购物车的记录功能，用户在登陆其需要纪录购物车的已购物品状态，如果集群不支持面向会话的调度，无法在不同的连接之间有效的保持会话的信息 ，就会导致会话无法持续。比如，用户会发现已经购买的物品在购物车中找不到，或者是服务器不断提示用户登录等错误。

不支持SSL交换

在电子商务中，为了确保交易时信用卡数据不被盗取，常常会使用SSL 技术做为传送数据的协议，不过SSL 算法必需要花掉许多的计算的时间加密传输的数据。为了减少时间，SSL 提供重复使用同一个session 的功能。为了能够重复使用同一个session，平衡器必需要记录客户端请求中SSL 会话标记和服务器的映射表。这也必需要负载平衡器能够识别请求中的协议内容。

如果均衡器不知道客户端的SSL的会话标识，而那些不带有相关cookie信息的节点无法对该请求进行服务响应（例如，需要验证请求的身份），均衡器错误的把同一个会话的请求转发到不同的服务器上--这直接导致SSL的通信失败。对于一个具备内容均衡的负载平衡系统里来讲，它可以识别出会话标记，把同一个SSL会话的数据转发到同一台服务器。而对于新的SSL会话请求，可以开辟新的连接映射，选择 负载比较轻的主机进行。通过SSL会话Session的复用，最大程度的加快了集群的服务吞吐量和整体性能。

内容分区

对于集群系统而言，可扩展性也包括了对存储的考虑，即文件系统的可扩展性。对于面向连接的交换而言，由于采用了集中式的调度策略，负载平衡器必须无差别的统一看待所有的服务结点，认为节点的所能提供的服务能力和内容是完全一致的。这就要求所有的服务结点使用同一份内容镜像，或者共享一个大容量的磁盘。但是，这样的方式大大限制了服务结点文件系统的可扩展性：

第一，由于所有的节点保存同样的内容，实际上集群的存储容量限制在了一台节点的存储能力上，假设每台节点提供80G的存储空间，10台节点构成的集群也还是只能提供80G的存储能力，无法获得更高的扩充；

第二，内容的同步和一致导致集群内部通信极大的开销。对于非只读的集群系统而言，由于内容的更新可能发生在任何一个节点上，因此需要有一种可靠的、实时的机制来将文件内容的变化同步到所有的其他接点之上。即使使用全局同步内容的做法，也无法解决面向 连接调度的负载平衡集群固有的缺陷。

第三，如果采用集中式存储，又会导致网络磁盘I/O的瓶颈。如果采用集中式的存储服务器，比如NFS文件服务器或者共享RAID、NAS设备等，可以解决服务结点内容不一致的问题，但是这也限制了集群节点的最大数量。对于仅有2～4台节点的集群，使用NAS高速设备共享存储是一个比较经济、简单的解决办法，因为任何一个数据库系统或者文件系统在100M以太网上足以应付少量节点的并发访问请求。但是随着更多的服务结点的加入，集中存储就变成集群系统的瓶颈，同时也消耗了大量的内部带宽。因此，对于可扩展性要求比较高的系统而言，不适合采用集中式存储 。

另外，就目前的技术发展状况，集中式存储的性能价格比会随着存储容量的增加而迅速下降。因此，从性能、成本、可扩展性等角度考虑，不适合使用集中存储来处理集群问题。

如果负载平衡器可以根据数据包中的协议信息（例如URL信息） 得知客户端请求的内容，并对之进行分类处理，把请求正确地导向储存该内容的服务器。如，可以把内容分为html、cgi、gif等，分别存于三个不同的server group，如图一，而不用把整个网站的内容存于同一台server。这样的架构可以提高服务集群的整体。要支持这样的功能，负载平衡器必需要根据request 的URL做负载平衡交换，这也是面向连接集群技术所无法做到的事。

访问的非局部性

Locality（局部性）作为近几十年来贯穿在各个设计层次的核心思想，在处理器、分布式体系结构等领域都有重要体现。集群中一样，为了提高服务节点的缓存命中率和集群的整体吞吐量，有必要考虑集群系统对Locality的支持。

由于均衡器无法识别客户端请求中包含的内容，因此，在大型网络中，由于使用了大量的Cache集群，负载平衡器无法充分的根据请求的页面来定位已经缓存的cache服务器，导致经常性的缓存页面缺失错误发生，而随后缓存服务器对缺失页面将产生的协议请求重定向操作，大大延长了客户端访问网络服务的等待时间，造成Cache集群的吞吐量的下降和客户端的等待时间延长。

因为缓存服务器保存了经常被访问的Web页面文件，而缓存服务器本身针对磁盘I/O性能进行了大量的优化工作，对于缓存集群来说，其模式本身就包含了一个分布式的存储系统，整体上Cache集群的是一个内容（缓存的）集合。而这样的内容分布式存储，要求调度程序能够按照请求的历史记录和请求的类型进行调度，将发往同一个内容的不同客户端的请求交给同一个具有该内容的缓存数据的结点进行服务。最大程度的利用缓存数据。从数据的局部性访问来讲，要求达到尽可能高的局部性和缓存命中率，从而提高整体的吞吐量和缩短客户等待服务的响应时间。

无法进行分离式的调度

多数动态请求本质上都是通过类似CGI的服务来进行的。CGI一般要求Web服务器初始化一个包含参数的执行环境，然后由Web服务器生成一个新进程并在新进程中依客户请求执行相应的CGI程序，可能访问一个后端数据库，再把执行结果动态构造成一个HTML页面返回给客户。因此，动态请求需要更多的CPU资源和更长的等待时间。当然，依赖于不同的CGI程序（如数据库访问或者是一个LDAP目录更新），可能对系统CPU、内存以及I/O资源的占用情况都有所不同。相比于动态请求，静态请求的服务过程要简单许多。Web服务器只是简单地从文件系统中读取客户请求的文件并返回给客户。即静态请求更多地需要系统的I/O能力。而典型的如Apache服务器，更可以绕过磁盘调度，直接从系统的缓存中返回数据。

目前，大多数Web请求都为静态请求，因此加快静态请求的处理速度对于提高Web集群的整体性能是非常重要的。如果服务器既处理静态也处理动态的服务请求，而静态请求和动态请求需要不同的系统资源，则在系统稳定运行时，耗费资源的动态请求将会干扰静态请求的正常处理、降低静态请求的响应速度。假设后端服务器的操作系统以round-robin方式调度进程的执行。令进程时间片大小为q，s为静态请求的平均处理时间，d为动态请求的平均处理时间。设操作系统的进程执行队列里有一个处理静态请求的进程A，n个处理动态请求的进程。如果进程A处于进程执行队列的最后，那么进程A必须等待n×q个时间片后才能使用CPU。已有的研究结果[4]表明s的值为0。01s，d的值为0。1s或若干秒，而q的典型值为0。2s[5]，即s<q<d。显然，n×s<n×q，即当进程A的前面是n个执行静态请求的进程时，要比前面是n个执行动态请求的进程时更早地获取CPU资源，并完成请求。混合式调度策略的另一个缺点是动态请求可能占用大量的系统内存，影响文件系统的缓存机制对内存资源的需求，从而降低静态请求的处理速度。

对于特殊的服务类型而言，例如视频服务器，不但具有静态请求的特性：只读，强调I/O的访问能力；也具有动态的特点：大量占用CPU和网络带宽资源。因此，在这一类的服务器上，如果把视频服务和其它类型的服务混合在一台节点上使用，互相之间相互影响，直接导致该节点的响应能力大大下降。

因此，在大型的复杂的电子商务环境，需要针对性的根据服务的类型将集群节点进行类型上的分区，而为了提高磁盘空间利用率和可扩展性，对同一类型的服务结点 集合还要进行内容上的分区。因此，负载平衡器如果不能具备协议解析的能力，无法从任务调度的根本上支持这样的应用，也就无法有效的针对实际的使用需要定制集群环境，提高集群的整体能力。而仅能使用统一的集中的，采用面向连接的方式对客户端请求进行调度。

关于作者

		林凡，现于厦门大学从事Linux相关的科研工作。于集群技术由很大的兴趣，希望能与志同道合的朋友一起交流。您可以通过电子邮件 iamafan@21cn.com和他联系。

查看本文来源